Hosts the 0x221E linux distro kernel. https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.3.y 2022-08-22T17:01:45Z 2022-08-22T17:01:45Z Cristian Marussi 2022-08-17T17:27:27Z urn:sha1:1ecb7d27b1af6705e9a4e94415b4d8cc8cf2fbfb SCMI protocols abstract and expose a number of protocol specific resources like clocks, sensors and so on. Information about such specific domain resources are generally exposed via an `info_get` protocol operation. Improve the sanity check on these operations where needed. Link: https://lore.kernel.org/r/20220817172731.1185305-3-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> 2022-06-20T09:17:33Z Cristian Marussi 2022-06-16T17:03:47Z urn:sha1:754f04cac362417b157e30d5dc4046b5ec92060c A reply to CLOCK_DESCRIBE_RATES issued against a non rate-discrete clock should be composed of a triplet of rates descriptors (min/max/step) returned all in one reply message. This is not always the case when dealing with some SCMI server deployed in the wild: relax such constraint while maintaining memory safety by checking carefully the returned payload size. While at that cleanup a stale debug printout. Link: https://lore.kernel.org/r/20220616170347.2800771-1-cristian.marussi@arm.com Fixes: 7bc7caafe6b1 ("firmware: arm_scmi: Use common iterators in the clock protocol") Tested-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> 2022-06-10T16:55:29Z Cristian Marussi 2022-06-08T09:55:28Z urn:sha1:4314f9f4f85832b5082f4e38b07b63b11baa538c Commit b260fccaebdc2 ("firmware: arm_scmi: Add SCMI v3.1 protocol extended names support") moved all the name string buffers to use the extended buffer size of 64 instead of the required 16 bytes. While that should be fine if the firmware terminates the string before 16 bytes, there is possibility of copying random data if the name is not NULL terminated by the firmware. SCMI base protocol agent_name/vendor_id/sub_vendor_id are defined by the specification as NULL-terminated ASCII strings up to 16-bytes in length. The underlying buffers and message descriptors are currently bigger than needed; resize them to fit only the strictly needed 16 bytes to avoid any possible leaks when reading data from the firmware. Change the size argument of strlcpy to use SCMI_SHORT_NAME_MAX_SIZE always when dealing with short domain names, so as to limit the possibility that an ill-formed non-NULL terminated short reply from the SCMI platform firmware can leak stale content laying in the underlying transport shared memory area. While at that, convert all strings handling routines to use the preferred strscpy. Link: https://lore.kernel.org/r/20220608095530.497879-1-cristian.marussi@arm.com Fixes: b260fccaebdc2 ("firmware: arm_scmi: Add SCMI v3.1 protocol extended names support") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> 2022-06-06T14:47:04Z Cristian Marussi 2022-05-30T11:52:36Z urn:sha1:d0c94bef70e71e364c0a016b0e92307cd4d1d719 While using SCMI iterators helpers a few local automatic variables are defined but then used only as input for sizeof operators. cppcheck is fooled to complain about this with: | drivers/firmware/arm_scmi/sensors.c:341:48: warning: Variable 'msg' is | not assigned a value. [unassignedVariable] | struct scmi_msg_sensor_list_update_intervals *msg; Even though this is an innocuos warning, since the uninitialized variable is at the end never used in the reported cases, fix these occurences all over SCMI stack to avoid keeping unneeded objects on the stack. Link: https://lore.kernel.org/r/20220530115237.277077-1-cristian.marussi@arm.com Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> 2022-04-28T17:22:53Z Cristian Marussi 2022-03-30T15:05:48Z urn:sha1:7aa75496ea1f38dfd99b93c66f8d9bc525d11efc 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 <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> 2022-04-28T17:22:52Z Cristian Marussi 2022-03-30T15:05:45Z urn:sha1:7bc7caafe6b1e5b882255a42bc1bf112fa87b69b 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 <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> 2022-04-28T17:22:52Z Cristian Marussi 2022-03-30T15:05:41Z urn:sha1:df3576d14a4598534d1a28276ded5ba2545d5e4c 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 <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> 2022-04-28T17:22:52Z Sudeep Holla 2022-04-28T12:29:13Z urn:sha1:7ad6b6ccbafc1faa04ca9d26635bdd5e3e240a69 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 <sudeep.holla@arm.com> 2022-04-28T17:22:52Z Cristian Marussi 2022-03-30T15:05:40Z urn:sha1:b260fccaebdc2c838e62aaef24fedf497f181d10 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 <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> 2022-04-28T17:22:51Z Cristian Marussi 2022-03-30T15:05:38Z urn:sha1:23136bff80a7edbe7b5df2b7c327d6584879930b 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 <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>