wireguard-linux/drivers/firmware/arm_scmi, 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: Replace zero-length array with flexible-array member

2020-02-20T17:11:28Z

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 "msg_payload" in scmi_shared_mem structure with flexible-array. Link: https://lore.kernel.org/r/20200211231045.GA13956@embeddedor Signed-off-by: Gustavo A. R. Silva [ rebased the change as files are moved around ] Signed-off-by: Sudeep Holla

firmware: arm_scmi: Make scmi core independent of the transport type

2020-02-10T11:50:51Z

The SCMI specification is fairly independent of the transport protocol, which can be a simple mailbox (already implemented) or anything else. The current Linux implementation however is very much dependent on the mailbox transport layer. This patch makes the SCMI core code (driver.c) independent of the mailbox transport layer and moves all mailbox related code to a new file: mailbox.c and all struct shared_mem related code to a new file: shmem.c. We can now implement more transport protocols to transport SCMI messages. The transport protocols just need to provide struct scmi_transport_ops, with its version of the callbacks to enable exchange of SCMI messages. Signed-off-by: Viresh Kumar Link: https://lore.kernel.org/r/8698a3cec199b8feab35c2339f02dc232bfd773b.1580448239.git.viresh.kumar@linaro.org Signed-off-by: Sudeep Holla

firmware: arm_scmi: Move macros and helpers to common.h

2020-02-10T11:50:47Z

Move message header specific macros and helper routines to common.h as they will be used outside of driver.c in a later commit. Signed-off-by: Viresh Kumar Link: https://lore.kernel.org/r/6615db480370719b0a0241447a5f3feb8eea421f.1580448239.git.viresh.kumar@linaro.org Signed-off-by: Sudeep Holla

firmware: arm_scmi: Update doc style comments

2020-02-10T11:50:41Z

Fix minor formatting issues with the doc style comments. Signed-off-by: Viresh Kumar Link: https://lore.kernel.org/r/1bff7c0d1ad2c8b6eeff9660421f414f8c612eb2.1580448239.git.viresh.kumar@linaro.org Signed-off-by: Sudeep Holla

drivers: firmware: scmi: Extend SCMI transport layer by trace events

2019-12-30T12:34:37Z

The SCMI transport layer communicates via mailboxes and shared memory with firmware running on a microcontroller. It is platform specific how long it takes to pass a SCMI message. The most sensitive requests are coming from CPUFreq subsystem, which might be used by the scheduler. Thus, there is a need to measure these delays and capture anomalies. This change introduces trace events wrapped around transfer code. According to Jim's suggestion a unique transfer_id is to distinguish similar entries which might have the same message id, protocol id and sequence. This is a case then there are some timeouts in transfers. Suggested-by: Jim Quinlan Signed-off-by: Lukasz Luba Signed-off-by: Sudeep Holla

firmware: arm_scmi: Skip protocol initialisation for additional devices

2019-12-24T11:36:26Z

The scmi bus now supports adding multiple devices per protocol, and since scmi_protocol_init is called for each scmi device created, we must avoid allocating protocol private data and initialising the protocol itself if it is already initialised. In order to achieve the same, we can simple replace the idr pointer from protocol initialisation function to a dummy function. Suggested-by: Cristian Marussi Reviewed-by: Cristian Marussi 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: Match scmi device by both name and protocol id

2019-12-24T11:35:49Z

The scmi bus now has support to match the driver with devices not only based on their protocol id but also based on their device name if one is available. This was added to cater the need to support multiple devices and drivers for the same protocol. Let us add the name "genpd" to scmi_device_id table in the driver so that in matches only with device with the same name and protocol id SCMI_PROTOCOL_POWER. Reviewed-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Add versions and identifier attributes using dev_groups

2019-12-24T11:35:49Z

Platform drivers now have the option to have the platform core create and remove any needed sysfs attribute files. Using the same, let's add the scmi firmware and protocol version attributes as well as vendor and sub-vendor identifiers to sysfs. It helps to identify the firmware details from the sysfs entries similar to ARM SCPI implementation. Reviewed-by: Cristian Marussi Signed-off-by: Sudeep Holla