Linux Kernel https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.19.16 2022-10-12T07:51:23Z 2022-10-12T07:51:23Z Cristian Marussi cristian.marussi@arm.com 2022-08-17T17:27:27Z urn:sha1:41bf1b0ad95395ec6d5172fb58540323788d9397 [ Upstream commit 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> Signed-off-by: Sasha Levin <sashal@kernel.org> 2022-06-10T16:55:29Z Cristian Marussi cristian.marussi@arm.com 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-04-28T17:22:53Z Cristian Marussi cristian.marussi@arm.com 2022-03-30T15:05:49Z urn:sha1:4c74701b1eb7636eb0cdd66b488b42920105122a Add SCMI v3.1 voltage protocol support for asynchronous VOLTAGE_LEVEL_SET command. Note that, if a voltage domain is advertised to support the asynchronous version of VOLTAGE_LEVEL_SET, the command will be issued asynchronously unless explicitly requested to use the synchronous version by setting the mode to SCMI_VOLTAGE_LEVEL_SET_SYNC when calling voltage_ops->level_set. The SCMI regulator driver level_set invocation has been left unchanged so that it will transparently use the asynchronous version if available. Link: https://lore.kernel.org/r/20220330150551.2573938-21-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:53Z Cristian Marussi cristian.marussi@arm.com 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 cristian.marussi@arm.com 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 cristian.marussi@arm.com 2022-03-30T15:05:35Z urn:sha1:992be5d3c818fcc277db246cb409659ca82abdbe A few protocol operations are available that returns a pointer to an internal character array representing resource name. Make those functions return a const pointer to such array. Link: https://lore.kernel.org/r/20220330150551.2573938-7-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> 2022-02-21T10:36:48Z Cristian Marussi cristian.marussi@arm.com 2022-02-17T13:12:33Z urn:sha1:18f295b758b227857133f680a397a42e83c62f3f An SCMI platform can optionally advertise an enable latency typically associated with a specific clock resource: add support for parsing such optional message field and export such information in the usual publicly accessible clock descriptor. Link: https://lore.kernel.org/r/20220217131234.50328-8-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> 2022-02-21T10:36:48Z Cristian Marussi cristian.marussi@arm.com 2022-02-17T13:12:32Z urn:sha1:b7bd36f2e9430a58aefdc326f8e6653e9b000243 Introduce new _atomic variant for SCMI clock protocol operations related to enable disable operations: when an atomic operation is required the xfer poll_completion flag is set for that transaction. Link: https://lore.kernel.org/r/20220217131234.50328-7-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> 2022-02-21T10:36:48Z Cristian Marussi cristian.marussi@arm.com 2022-02-17T13:12:31Z urn:sha1:05976c5f3bff8f8b5230da4b39f7cd6dfba9943e An SCMI agent can be configured system-wide with a well-defined atomic threshold: only SCMI synchronous command whose latency has been advertised by the SCMI platform to be lower or equal to this configured threshold will be considered for atomic operations, when requested and if supported by the underlying transport at all. Link: https://lore.kernel.org/r/20220217131234.50328-6-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> 2021-12-21T10:59:37Z Cristian Marussi cristian.marussi@arm.com 2021-12-20T19:56:41Z urn:sha1:69255e746890274e887ba36a403019380cde0b48 An SCMI transport can be configured as .atomic_enabled in order to signal to the SCMI core that all its TX path is executed in atomic context and that, when requested, polling mode should be used while waiting for command responses. When a specific platform configuration had properly configured such a transport as .atomic_enabled, the SCMI core will also take care not to sleep in the corresponding RX path while waiting for a response if that specific command transaction was requested as atomic using polling mode. Asynchronous commands should not be used in an atomic context and so a warning is emitted if polling was requested for an asynchronous command. Add also a method to check, from the SCMI drivers, if the underlying SCMI transport is currently configured to support atomic transactions: this will be used by upper layers to determine if atomic requests can be supported at all on this SCMI instance. Link: https://lore.kernel.org/r/20211220195646.44498-7-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>