linux-dev/drivers/firmware/arm_scmi/clock.c, branch linus/master

firmware: arm_scmi: Add SCMI v3.1 clock notifications

2022-04-28T17:22:53Z

Add SCMI v3.1 clock pre and post notifications. Link: https://lore.kernel.org/r/20220330150551.2573938-20-cristian.marussi@arm.com Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Use common iterators in the clock protocol

2022-04-28T17:22:52Z

Make SCMI clock protocol use the common iterator protocol helpers for issuing the multi-part commands. Link: https://lore.kernel.org/r/20220330150551.2573938-17-cristian.marussi@arm.com Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Parse clock_enable_latency conditionally

2022-04-28T17:22:52Z

The clock_enable_latency field in CLOCK_ATTRIBUTES response message has been added only since SCMI v3.1. Use the advertised SCMI clock protocol version as a proper condition check for parsing it, instead of the bare message length lookup. Link: https://lore.kernel.org/r/20220330150551.2573938-13-cristian.marussi@arm.com Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Set clock latency to U32_MAX if it is not supported

2022-04-28T17:22:52Z

As per the spec, the clock_enable_delay is the worst case latency incurred by the platform to enable the clock. The value of 0 indicates that the platform doesn't support the same and must be considered as maximum latency for practical purposes. Currently the value of 0 is assigned as is and is propogated to the clock framework which can assume that the clock can support atomic enable operation. Link: https://lore.kernel.org/r/20220428122913.1654821-1-sudeep.holla@arm.com Fixes: 18f295b758b2 ("firmware: arm_scmi: Add support for clock_enable_latency") Signed-off-by: Sudeep Holla

firmware: arm_scmi: Add SCMI v3.1 protocol extended names support

2022-04-28T17:22:52Z

Using the common protocol helper implementation add support for all new SCMIv3.1 extended names commands related to all protocols with the exception of SENSOR_AXIS_GET_NAME. Link: https://lore.kernel.org/r/20220330150551.2573938-12-cristian.marussi@arm.com Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Split protocol specific definitions in a dedicated header

2022-04-28T17:22:51Z

Move some SCMI protocol specific definitions from common.h into a the new dedicated protocols.h header so that SCMI protocols core code can include only what it needs; this is going to be useful to avoid the risk of growing indefinitely the dimension of common.h, especially when introducing some common protocols helper functions. Header common.h will continue to be included by SCMI core and transport layers. Link: https://lore.kernel.org/r/20220330150551.2573938-10-cristian.marussi@arm.com Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Remove unneeded NULL termination of clk name

2022-04-28T17:22:51Z

The string array 'name' inside struct scmi_clock_info holds the clock name which was successfully retrieved by querying the SCMI platform, unless the related underlying SCMI command failed. Anyway, such scmi_clock_info structure is allocated using devm_kcalloc() which in turn internally appends a __GFP_ZERO flag to its invocation: as a consequence the string 'name' field does not need to be zeroed when we fail to get the clock name via SCMI, it is already NULL terminated. Remove unneeded explicit NULL termination. Link: https://lore.kernel.org/r/20220330150551.2573938-9-cristian.marussi@arm.com Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Check CLOCK_RATE_SET_COMPLETE async response

2022-04-28T17:22:51Z

When CLOCK_RATE_SET command is issued in asynchronous mode the delayed response CLOCK_RATE_SET_COMPLETE comes back once the SCMI platform has effectively operated the requested change: such delayed response carries also the clock ID and the final clock rate that has been set. As an aid to debug issues, check that the clock ID in the delayed response matches the expected one and debug print the rate value. Link: https://lore.kernel.org/r/20220330150551.2573938-8-cristian.marussi@arm.com Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Make protocols initialisation fail on basic errors

2022-04-28T09:47:19Z

Bail out of protocol initialisation routine early when basic information about protocol version and attributes could not be retrieved. Failing to act this way can lead to a successfully initialized SCMI protocol which is in fact not fully functional. Link: https://lore.kernel.org/r/20220330150551.2573938-3-cristian.marussi@arm.com Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla

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

2022-04-04T22:06:37Z

There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays Link: https://lore.kernel.org/r/20220401075537.2407376-1-lv.ruyi@zte.com.cn Reported-by: Zeal Robot Signed-off-by: Lv Ruyi Signed-off-by: Sudeep Holla