wireguard-linux/drivers/firmware/arm_scmi/perf.c, branch jd/unified-crypt-queue

firmware: arm_scmi/perf: Replace zero-length array with flexible-array member

2020-02-20T17:12:24Z

The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertenly introduced[3] to the codebase from now on. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Replace the zero-length member "opp" in scmi_msg_resp_perf_describe_levels structure with flexible-array. Link: https://lore.kernel.org/r/20200211231252.GA14830@embeddedor Signed-off-by: Gustavo A. R. Silva Signed-off-by: Sudeep Holla

firmware: arm_scmi: Stash version in protocol init functions

2019-12-24T11:35:49Z

In order to avoid querying the individual protocol versions multiple time with more that one device created for each protocol, we can simple store the copy in the protocol specific private data and use them whenever required. Reviewed-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Fix doorbell ring logic for !CONFIG_64BIT

2019-11-14T11:13:50Z

The logic to ring the scmi performance fastchannel ignores the value read from the doorbell register in case of !CONFIG_64BIT. This bug also shows up as warning with '-Wunused-but-set-variable' gcc flag: drivers/firmware/arm_scmi/perf.c: In function scmi_perf_fc_ring_db: drivers/firmware/arm_scmi/perf.c:323:7: warning: variable val set but not used [-Wunused-but-set-variable] Fix the same by aligning the logic with CONFIG_64BIT as used in the macro SCMI_PERF_FC_RING_DB(). Fixes: 823839571d76 ("firmware: arm_scmi: Make use SCMI v2.0 fastchannel for performance protocol") Reported-by: Hulk Robot Reported-by: Zheng Yongjun Signed-off-by: Sudeep Holla

firmware: arm_scmi: Make use SCMI v2.0 fastchannel for performance protocol

2019-08-12T11:23:01Z

SCMI v2.0 adds support for "FastChannel" which do not use a message header as they are specialized for a single message. Only PERFORMANCE_LIMITS_{SET,GET} and PERFORMANCE_LEVEL_{SET,GET} commands are supported over fastchannels. As they are optional, they need to be discovered by PERFORMANCE_DESCRIBE_FASTCHANNEL command. Further {LIMIT,LEVEL}_SET commands can have optional doorbell support. Add support for making use of these fastchannels. Cc: Ionela Voinescu Cc: Chris Redpath Cc: Quentin Perret Reviewed-by: Peng Fan Signed-off-by: Sudeep Holla

firmware: arm_scmi: Add discovery of SCMI v2.0 performance fastchannels

2019-08-12T11:23:01Z

SCMI v2.0 adds support for "FastChannel", a lightweight unidirectional channel that is dedicated to a single SCMI message type for controlling a specific platform resource. They do not use a message header as they are specialized for a single message. Only PERFORMANCE_LIMITS_{SET,GET} and PERFORMANCE_LEVEL_{SET,GET} commands are supported over fastchannels. As they are optional, they need to be discovered by PERFORMANCE_DESCRIBE_FASTCHANNEL command. Further {LIMIT,LEVEL}_SET commands can have optional doorbell support. Add support for discovery of these fastchannels. Cc: Ionela Voinescu Cc: Chris Redpath Cc: Quentin Perret Reviewed-by: Peng Fan Signed-off-by: Sudeep Holla

firmware: arm_scmi: Use {get,put}_unaligned_le{32,64} accessors

2019-08-12T11:23:01Z

Instead of type-casting the {tx,rx}.buf all over the place while accessing them to read/write __le{32,64} from/to the firmware, let's use the existing {get,put}_unaligned_le{32,64} accessors to hide all the type cast ugliness. Suggested-by: Philipp Zabel Reviewed-by: Philipp Zabel Signed-off-by: Sudeep Holla

firmware: arm_scmi: add a getter for power of performance states

2018-09-10T16:37:06Z

The SCMI protocol can be used to get power estimates from firmware corresponding to each performance state of a device. Although these power costs are already managed by the SCMI firmware driver, they are not exposed to any external subsystem yet. Fix this by adding a new get_power() interface to the exisiting perf_ops defined for the SCMI protocol. Signed-off-by: Quentin Perret Signed-off-by: Sudeep Holla

firmware: arm_scmi: use strlcpy to ensure NULL-terminated strings

2018-09-10T09:08:44Z

Replace all the memcpy() for copying name strings from the firmware with strlcpy() to make sure we are bounded by the source buffer size and we also always have NULL-terminated strings. This is needed to avoid out of bounds accesses if the firmware returns a non-terminated string. Reported-by: Olof Johansson Acked-by: Olof Johansson Signed-off-by: Sudeep Holla

firmware: arm_scmi: fix divide by zero when sustained_perf_level is zero

2018-09-06T16:59:40Z

Firmware can provide zero as values for sustained performance level and corresponding sustained frequency in kHz in order to hide the actual frequencies and provide only abstract values. It may endup with divide by zero scenario resulting in kernel panic. Let's set the multiplication factor to one if either one or both of them (sustained_perf_level and sustained_freq) are set to zero. Fixes: a9e3fbfaa0ff ("firmware: arm_scmi: add initial support for performance protocol") Reported-by: Ionela Voinescu Signed-off-by: Sudeep Holla Signed-off-by: Olof Johansson

firmware: arm_scmi: remove some unnecessary checks

2018-07-09T09:50:20Z

The "pi->dom_info" buffer is allocated in init() and it can't be NULL here. These tests are sort of weird as well because if "pi->dom_info" was NULL but "domain" was non-zero then it would lead to an Oops. Signed-off-by: Dan Carpenter Signed-off-by: Sudeep Holla