#
2441caa8 |
|
22-Feb-2024 |
Pierre Gondois <pierre.gondois@arm.com> |
firmware: arm_scmi: Populate fast channel rate_limit Arm SCMI spec. v3.2, s4.5.3.12 PERFORMANCE_DESCRIBE_FASTCHANNEL defines a per-domain rate_limit for performance requests: """ Rate Limit in microseconds, indicating the minimum time required between successive requests. A value of 0 indicates that this field is not applicable or supported on the platform. """" The field is first defined in SCMI v2.0. Add support to fetch this value and advertise it through a fast_switch_rate_limit() callback. Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
#
8c80c42a |
|
14-Feb-2024 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add support for v3.2 NEGOTIATE_PROTOCOL_VERSION Freshly introduced NEGOTIATE_PROTOCOL_VERSION allows the agent to ascertain upfront if a specific protocol(usually older) version is supported by the platform. It is used by the agent in case the platform has advertised the support of a newer protocol version than the latest version supported by the agent, since backward compatibility cannot be automatically assumed. Emit a warning about possible incompatibility when negotiation was not possible or just print the successfully negotiated protocol. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240214183006.3403207-3-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
637b6d6c |
|
11-Feb-2024 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add a common helper to check if a message is supported A common helper is provided to check if a specific protocol message is supported or not. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240212123233.1230090-3-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
927e1130 |
|
27-Dec-2023 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
firmware: arm_scmi: Convert to platform remove callback returning void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/86165c8ccd0bb47000a29e711102795b36c8df41.1703693980.git.u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
b5efc28a |
|
01-Dec-2023 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add protocol versioning checks Platform and agent supported protocols versions do not necessarily match. When talking to an older SCMI platform, supporting only older protocol versions, the kernel SCMI agent will downgrade the version of the used protocol to match the platform and avoid compatibility issues. In the case where the kernel/OSPM agent happens to communicate with a newer platform which can support newer protocol versions unknown to the agent, and potentially backward incompatible, the agent currently carries on, silently, in a best-effort approach. Note that the SCMI specification doesn't provide means to explicitly detect the protocol versions used by the agents, neither it is required to support multiple, older, protocol versions. Add an explicit protocol version check to let the agent detect when this version mismatch happens and warn the user about this condition. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20231201135858.2367651-1-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
e4e6e8f1 |
|
14-Nov-2023 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add optional flags to extended names helper Some recently added SCMI protocols needs an additional flags parameter to be able to properly configure the command used to query the extended name of a resource. Modify extended_name_get helper accordingly. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20231114145449.3136412-1-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
da405477 |
|
09-Oct-2023 |
Nikunj Kela <quic_nkela@quicinc.com> |
firmware: arm_scmi: Add qcom smc/hvc transport support This change adds the support for SCMI message exchange on Qualcomm virtual platforms. The hypervisor associates an object-id also known as capability-id with each smc/hvc doorbell object. The capability-id is used to identify the doorbell from the VM's capability namespace, similar to a file-descriptor. The hypervisor, in addition to the function-id, expects the capability-id to be passed in x1 register when SMC/HVC call is invoked. The capability-id is allocated by the hypervisor on bootup and is stored in the shmem region by the firmware before starting Linux. Signed-off-by: Nikunj Kela <quic_nkela@quicinc.com> Reviewed-by: Brian Masney <bmasney@redhat.com> Link: https://lore.kernel.org/r/20231009191437.27926-3-quic_nkela@quicinc.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
5b45759c |
|
03-Aug-2023 |
Rob Herring <robh@kernel.org> |
firmware: Explicitly include correct DT includes The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Acked-by: Dinh Nguyen <dinguyen@kernel.org> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Link: https://lore.kernel.org/r/20230803-dt-header-cleanups-for-soc-v2-17-d8de2cc88bff@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
#
5f2ea10a |
|
06-May-2023 |
Nikunj Kela <quic_nkela@quicinc.com> |
firmware: arm_scmi: Augment SMC/HVC to allow optional parameters This change adds support for passing shmem channel address as parameters in smc/hvc call. The address is split into 4KB-page and offset. This is useful when multiple scmi instances are using same smc-id and firmware needs to distinguish among the instances. Signed-off-by: Nikunj Kela <quic_nkela@quicinc.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20230506182428.25343-3-quic_nkela@quicinc.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
b2ccba9e |
|
26-Mar-2023 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Fix xfers allocation on Rx channel Two distinct pools of xfer descriptors are allocated at initialization time: one (Tx) used to provide xfers to track commands and their replies (or delayed replies) and another (Rx) to pick xfers from to be used for processing notifications. Such pools, though, are allocated globally to be used by the whole SCMI instance, they are not allocated per-channel and as such the allocation of notifications xfers cannot be simply skipped if no Rx channel was found for the base protocol common channel, because there could be defined more optional per-protocol dedicated channels that instead support Rx channels. Change the conditional check to skip allocation for the notification pool only if no Rx channel has been detected on any per-channel protocol at all. Fixes: 4ebd8f6dea81 ("firmware: arm_scmi: Add receive buffer support for notifications") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20230326203449.3492948-1-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
d617808e |
|
08-Jul-2022 |
Christophe JAILLET <christophe.jaillet@wanadoo.fr> |
firmware: arm_scmi: Use the bitmap API to allocate bitmaps Use devm_bitmap_zalloc() instead of hand-writing them. It is less verbose and it improves the semantic. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/c073b1607ada34d5bde6ce1009179cf15bbf0da3.1657308593.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
b2b76e97 |
|
23-Feb-2023 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Fix raw coexistence mode behaviour on failure path When SCMI raw coexistence mode is enabled make the core stack probe successfully even when the initial base protocol exchanges with the platform/server failed. This behaviour enables the system to boot with a broken regular SCMI stack but with a fully functional and accessible SCMI raw debugfs interface that can be used to further debug the issue. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20230223152330.2707260-1-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
8ab5059d |
|
23-Jan-2023 |
Dan Carpenter <error27@gmail.com> |
firmware: arm_scmi: Clean up a return statement in scmi_probe The comments say "enabled" where "disabled" is intended. Also it's cleaner to return zero explicitly instead of ret. Signed-off-by: Dan Carpenter <error27@gmail.com> Link: https://lore.kernel.org/r/Y86im5M49p3ePGxj@kili Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
7860701d |
|
17-Jan-2023 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add per-channel raw injection support On a system configured with multiple transport channels, expose a few additional debugfs per-channel entries to allow a user to explicitly select which transport channel to use for the SCMI message injection. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Vincent Guittot <vincent.guittot@linaro.org> Link: https://lore.kernel.org/r/20230118121426.492864-18-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
9c54633e |
|
17-Jan-2023 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add the raw mode co-existence support When the raw support is enabled and configured in co-existence mode the normal SCMI drivers are allowed to register with the SCMI core and operate as usual alongside the raw operations. SCMI normal and raw messages will be kept segregated from each other, but only at the transaction level. Any further possible interference at the protocol layer will have instead to be handled by the user to attain reliable results while using the raw transactions. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Vincent Guittot <vincent.guittot@linaro.org> Link: https://lore.kernel.org/r/20230118121426.492864-17-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
7063887b |
|
17-Jan-2023 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Call raw mode hooks from the core stack Add a few call sites where, if SCMI raw mode access had been enabled in Kconfig, the needed SCMI raw initialization and hooks are called. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Vincent Guittot <vincent.guittot@linaro.org> Link: https://lore.kernel.org/r/20230118121426.492864-16-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
3c3d818a |
|
17-Jan-2023 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add core raw transmission support Add SCMI raw mode support which exposes a userspace interface to allow for bare SCMI command injection and snooping from userspace. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Vincent Guittot <vincent.guittot@linaro.org> Link: https://lore.kernel.org/r/20230118121426.492864-13-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
c3d4aed7 |
|
17-Jan-2023 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Populate a common SCMI debugfs root Create a common SCMI debugfs root directory and populate it with some common SCMI data for each discovered SCMI platform instance if SCMI debugfs is needed by any configured SCMI facility. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Vincent Guittot <vincent.guittot@linaro.org> Link: https://lore.kernel.org/r/20230118121426.492864-11-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
8b2bd711 |
|
17-Jan-2023 |
Cristian Marussi <cristian.marussi@arm.com> |
include: trace: Add platform and channel instance references Add the channel and platform instance indentifier to SCMI message dump traces in order to easily associate message flows to specific transport channels. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Vincent Guittot <vincent.guittot@linaro.org> Link: https://lore.kernel.org/r/20230118121426.492864-9-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
75c86dc7 |
|
17-Jan-2023 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add internal platform/channel identifiers Add a couple of unique identifiers to channel and platform instance descriptors in order to emit more descriptive message dump traces. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Vincent Guittot <vincent.guittot@linaro.org> Link: https://lore.kernel.org/r/20230118121426.492864-8-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
936a2b91 |
|
17-Jan-2023 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Move errors defs and code to common.h Move SCMI error codes definitions and helper to the common.h header together with the delayed response timeout define. No functional change. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Vincent Guittot <vincent.guittot@linaro.org> Link: https://lore.kernel.org/r/20230118121426.492864-7-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
3095a3e2 |
|
17-Jan-2023 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add xfer helpers to provide raw access Add a few SCMI helpers useful to implement SCMI raw access support. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Vincent Guittot <vincent.guittot@linaro.org> Link: https://lore.kernel.org/r/20230118121426.492864-6-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
07cdfc44 |
|
17-Jan-2023 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Refactor scmi_wait_for_message_response Refactor scmi_wait_for_message_response() to use a internal helper to carry out its main duties; while doing that make it accept directly an scmi_desc parameter to interact with the configured transport. No functional change. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Vincent Guittot <vincent.guittot@linaro.org> Link: https://lore.kernel.org/r/20230118121426.492864-4-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
f21c2b0b |
|
17-Jan-2023 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Refactor polling helpers Refactor polling helpers to receive scmi_desc directly as a parameter and move all of them to common.h. No functional change. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Vincent Guittot <vincent.guittot@linaro.org> Link: https://lore.kernel.org/r/20230118121426.492864-3-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
b0e924a9 |
|
17-Jan-2023 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Refactor xfer in-flight registration routines Move the whole xfer in-flight registration process out of scmi_xfer_get and while at that, split the sequence number selection steps from the in-flight registration procedure itself. No functional change. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Vincent Guittot <vincent.guittot@linaro.org> Link: https://lore.kernel.org/r/20230118121426.492864-2-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
37b5be82 |
|
22-Dec-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Split bus and driver into distinct modules Make the SCMI bus on its own as a distinct module initialized at subsys_initcall level when builtin. Keep the SCMI driver core stack, together with any configured transport, in a different module initialized as module_init level. SCMI drivers initialization remain unchanged at module_init level. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20221222185049.737625-10-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
ee5dceda |
|
22-Dec-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Introduce a new lifecycle for protocol devices Protocol devices are created or destroyed depending on the related device request/unrequest events emitted on the scmi_requested_devices_nh notification chain by the SCMI bus and served in the driver by the scmi_device_request_notifier. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20221222185049.737625-9-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
2c3e6744 |
|
22-Dec-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Refactor device create/destroy helpers Refactor SCMI device create/destroy helpers: it is now possible to ask for the creation of all the currently requested devices for a whole protocol, not only for the creation of a single well-defined device. While at that, re-instate uniqueness checks on the creation of SCMI SystemPower devices. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20221222185049.737625-8-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
971fc066 |
|
22-Dec-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Move handle get/set helpers Move handle get/set helpers definitions into driver.c and invoke them through the bus notifier helper. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20221222185049.737625-7-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
d3cd7c52 |
|
22-Dec-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Refactor protocol device creation Move protocol device request helpers from driver.c compilation unit to bus.c, so reducing the cross interactions between driver.c and bus.c. Get rid of old protocol device creation process as a whole from driver.c and remove also stale SCMI system power unicity checks. While at that make such helpers call into scmi_requested_devices_nh notification chain. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20221222185049.737625-6-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
53b8c25d |
|
22-Dec-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add common notifier helpers Add a pair of notifier chains and generic empty notifier callbacks. Currently they are still unused but they will be used to act properly on device request and creation events. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20221222185049.737625-5-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
9115c20a |
|
22-Dec-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Move protocol registration helpers Move protocol registration helpers and logic out of bus.c compilation unit into driver.c. No functional change. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20221222185049.737625-4-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
05a2801d |
|
22-Dec-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Use dedicated devices to initialize channels Refactor channels initialization to use dedicated transport devices instead of using devices borrowed from the SCMI drivers. Initialize all channels, as described in the device tree, upfront during SCMI core stack probe phase and free all of them, including the underlying devices, when the SCMI core is removed. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20221222185049.737625-3-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
7a75b7af |
|
22-Dec-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Simplify chan_available transport operation SCMI transport operation .chan_available determines in a transport specific way if an SCMI channel is still available and to be configured. Such information is derived by analyzing bits of device node in a transport specific way, all it needs is a device node to operate up on, not necessarily a full blown device. Simplify the helper to receive in input a reference to a device_node instead of a device carrying a pointer to such device_node. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20221222185049.737625-2-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
f6ca5059 |
|
22-Dec-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Clear stale xfer->hdr.status Stale error status reported from a previous message transaction must be cleared before starting a new transaction to avoid being confusingly reported in the following SCMI message dump traces. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20221222183823.518856-2-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
be9ba1f7 |
|
28-Oct-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Make Rx chan_setup fail on memory errors SCMI Rx channels are optional and they can fail to be setup when not present but anyway channels setup routines must bail-out on memory errors. Make channels setup, and related probing, fail when memory errors are reported on Rx channels. Fixes: 5c8a47a5a91d ("firmware: arm_scmi: Make scmi core independent of the transport type") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20221028140833.280091-4-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
59172b21 |
|
28-Oct-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Make tx_prepare time out eventually SCMI transports based on shared memory, at start of transmissions, have to wait for the shared Tx channel area to be eventually freed by the SCMI platform before accessing the channel. In fact the channel is owned by the SCMI platform until marked as free by the platform itself and, as such, cannot be used by the agent until relinquished. As a consequence a badly misbehaving SCMI platform firmware could lock the channel indefinitely and make the kernel side SCMI stack loop forever waiting for such channel to be freed, possibly hanging the whole boot sequence. Add a timeout to the existent Tx waiting spin-loop so that, when the system ends up in this situation, the SCMI stack can at least bail-out, nosily warn the user, and abort the transmission. Reported-by: YaxiongTian <iambestgod@outlook.com> Suggested-by: YaxiongTian <iambestgod@outlook.com> Cc: Vincent Guittot <vincent.guittot@linaro.org> Cc: Etienne Carriere <etienne.carriere@linaro.org> Cc: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20221028140833.280091-3-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
fd96fbc8 |
|
28-Oct-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Suppress the driver's bind attributes Suppress the capability to unbind the core SCMI driver since all the SCMI stack protocol drivers depend on it. Fixes: aa4f886f3893 ("firmware: arm_scmi: add basic driver infrastructure for SCMI") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20221028140833.280091-2-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
3f4071cb |
|
28-Oct-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Cleanup the core driver removal callback Platform drivers .remove callbacks are not supposed to fail and report errors. Such errors are indeed ignored by the core platform drivers and the driver unbind process is anyway completed. The SCMI core platform driver as it is now, instead, bails out reporting an error in case of an explicit unbind request. Fix the removal path by adding proper device links between the core SCMI device and the SCMI protocol devices so that a full SCMI stack unbind is triggered when the core driver is removed. The remove process does not bail out anymore on the anomalous conditions triggered by an explicit unbind but the user is still warned. Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20221028140833.280091-1-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
6f9ea4da |
|
04-Jul-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Generalize the fast channel support Generalize existing fast channel support used in the perf protocol and make it available to possibly any protocol refactoring the common code into a couple of new scmi_proto_helpers_ops routines. Make perf protocol use this new infrastructure. No functional change. Link: https://lore.kernel.org/r/20220704102241.2988447-4-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
0316f99c |
|
04-Jul-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add SCMI v3.1 powercap protocol basic support Add support for SCMI v3.1 powercap protocol, with the exception of powercap fast channels, exposing all the new related powercap protocol operations as usual in include/linux/scmi_protocol.h. Link: https://lore.kernel.org/r/20220704102241.2988447-3-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
d9107999 |
|
04-Jul-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add devm_protocol_acquire helper Add a method to get hold of a protocol, causing it to be initialized and its resource accounting updated, without getting access to its operations and handle. Some protocols, like SCMI SystemPower, do not expose any protocol ops to the kernel OSPM agent but still need to be at least initialized. This helper avoids the need to invoke a full devm_get_protocol() only to get the protocol initialized while throwing away unused the protocol ops and handle. Link: https://lore.kernel.org/r/20220704101933.2981635-4-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
a0db3962 |
|
04-Jul-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Support only one single system power device In order to minimize SCMI platform fw-side complexity, only one single SCMI platform should be in charge of SCMI SystemPower protocol communications with the OSPM. Enforce the existence of one single unique device associated with SystemPower protocol across any possible number of SCMI platforms, and warn if a system tries to register different SystemPower devices from multiple platforms. Link: https://lore.kernel.org/r/20220704101933.2981635-2-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
b60e0886 |
|
30-Jun-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Use new SCMI full message tracing Add full message tracing for all transmitted and successfully received SCMI commands, replies and notifications. Link: https://lore.kernel.org/r/20220630173135.2086631-3-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
754f04ca |
|
16-Jun-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Relax CLOCK_DESCRIBE_RATES out-of-spec checks 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>
|
#
c7f8852d |
|
03-May-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Fix late checks on pointer dereference A few dereferences could happen before the iterator pointer argument was checked for NULL, causing the following smatch warnings: drivers/firmware/arm_scmi/driver.c:1214 scmi_iterator_run() warn: variable dereferenced before check 'i' (see line 1210) Fix by moving the checks early and dropping some unneeded local references. No functional change. Link: https://lore.kernel.org/r/20220503121047.3590340-1-cristian.marussi@arm.com Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
36b6ea0f |
|
30-Mar-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add iterators for multi-part commands SCMI specification defines some commands as optionally issued over multiple messages in order to overcome possible limitations in payload size enforced by the configured underlyinng transport. Introduce some common protocol helpers to provide a unified solution for issuing such SCMI multi-part commands. Link: https://lore.kernel.org/r/20220330150551.2573938-14-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
5c873d12 |
|
30-Mar-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Introduce a common SCMI v3.1 .extended_name_get helper Introduce a new set of common protocol operations bound to the protocol handle structure so that can be invoked by the protocol implementation code even when protocols are built as distinct loadable kernel module without the need of exporting new symbols, like already done with scmi_xfer_ops. Add at first, as new common protocol helper, an .extended_name_get helper which will ease implementation and will avoid code duplication when adding new SCMIv3.1 per-protocol _NAME_GET commands. Link: https://lore.kernel.org/r/20220330150551.2573938-11-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
776b6c8a |
|
30-Mar-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Dynamically allocate implemented protocols array Move away from a statically allocated array for holding the current set of protocols implemented by the platform in favour of allocating it dynamically based on the number of protocols effectively advertised by the platform via BASE protocol exchanges. While at that, rectify the BASE_DISCOVER_LIST_PROTOCOLS loop iterations to terminate only when a number of protocols equal to the advertised ones has been received, instead of looping till the platform returns no more protocols descriptors. This new behaviour is better compliant with the specification and it has been tested to work equally well against an SCMI stack running on top of an official SCP firmware on a JUNO board. Link: https://lore.kernel.org/r/20220330150551.2573938-6-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
98f0d68f |
|
24-Feb-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Remove clear channel call on the TX channel On SCMI transports whose channels are based on a shared resource the TX channel area has to be acquired by the agent before placing the desired command into the channel and it will be then relinquished by the platform once the related reply has been made available into the channel. On an RX channel the logic is reversed with the platform acquiring the channel area and the agent reliquishing it once done by calling the scmi_clear_channel() helper. As a consequence, even in case of error, the agent must never try to clear a TX channel from its side: restrict the existing clear channel call on the the reply path only to delayed responses since they are indeed coming from the RX channel. Link: https://lore.kernel.org/r/20220224152404.12877-1-cristian.marussi@arm.com Fixes: e9b21c96181c ("firmware: arm_scmi: Make .clear_channel optional") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
05976c5f |
|
17-Feb-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Support optional system wide atomic-threshold-us 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>
|
#
5a3b7185 |
|
17-Feb-2022 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add atomic mode support to virtio transport Add support for .mark_txdone and .poll_done transport operations to SCMI VirtIO transport as pre-requisites to enable atomic operations. Add a Kernel configuration option to enable SCMI VirtIO transport polling and atomic mode for selected SCMI transactions while leaving it default disabled. Link: https://lore.kernel.org/r/20220217131234.50328-4-cristian.marussi@arm.com Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Igor Skalkin <igor.skalkin@opensynergy.com> Cc: Peter Hilber <peter.hilber@opensynergy.com> Cc: virtualization@lists.linux-foundation.org Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
94d0cd1d |
|
20-Dec-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add new parameter to mark_txdone Add a new xfer parameter to mark_txdone transport operation which enables the SCMI core to optionally pass back into the transport layer a reference to the xfer descriptor that is being handled. Link: https://lore.kernel.org/r/20211220195646.44498-9-cristian.marussi@arm.com Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
69255e74 |
|
20-Dec-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add support for atomic transports 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>
|
#
31d2f803 |
|
20-Dec-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add sync_cmds_completed_on_ret transport flag Add a flag to let the transport signal to the core if its handling of sync command implies that, after .send_message has returned successfully, the requested command can be assumed to be fully and completely executed on SCMI platform side so that any possible response value is already immediately available to be retrieved by a .fetch_response: in other words the polling phase can be skipped in such a case and the response values accessed straight away. Note that all of the above applies only when polling mode of operation was selected by the core: if instead a completion IRQ was found to be available the normal response processing path based on completions will still be followed. Link: https://lore.kernel.org/r/20211220195646.44498-4-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
a690b7e6 |
|
20-Dec-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add configurable polling mode for transports SCMI communications along TX channels can optionally be provided of a completion interrupt; when such interrupt is not available, command transactions should rely on polling, where the SCMI core takes care to repeatedly evaluate the transport-specific .poll_done() function, if available, to determine if and when a request was fully completed or timed out. Such mechanism is already present and working on a single transfer base: SCMI protocols can indeed enable hdr.poll_completion on specific commands ahead of each transfer and cause that transaction to be handled with polling. Introduce a couple of flags to be able to enforce such polling behaviour globally at will: - scmi_desc.force_polling: to statically switch the whole transport to polling mode. - scmi_chan_info.no_completion_irq: to switch a single channel dynamically to polling mode if, at runtime, is determined that no completion interrupt was available for such channel. Link: https://lore.kernel.org/r/20211220195646.44498-2-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
f872af09 |
|
29-Nov-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Use new trace event scmi_xfer_response_wait Use new trace event to mark start of waiting for response section. Link: https://lore.kernel.org/r/20211129191156.29322-6-cristian.marussi@arm.com Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
5a731aeb |
|
29-Nov-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Refactor message response path Refactor code path waiting for message responses into a dedicated helper function. No functional change. Link: https://lore.kernel.org/r/20211129191156.29322-4-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
582730b9 |
|
29-Nov-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Set polling timeout to max_rx_timeout_ms Use transport specific transmission timeout (max_rx_timeout_ms) also for polling transactions. Initially when polling mode was added, it was intended to be used only in scheduler context and hence the choice of 100us for the polling timeout. However the only user for that was dropped for other SCMI concurrency issues, so it shouldn't cause any issue to increase this timeout value now. Link: https://lore.kernel.org/r/20211129191156.29322-3-cristian.marussi@arm.com Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> [sudeep.holla: Updated commit message with historical facts about 100us timeout] Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
d211ddeb |
|
29-Nov-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Perform earlier cinfo lookup call in do_xfer Lookup cinfo data early in do_xfer so as to avoid any further init work on xfer structure in case of error. No functional change. Link: https://lore.kernel.org/r/20211129191156.29322-2-cristian.marussi@arm.com Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
5f90f189 |
|
28-Oct-2021 |
Etienne Carriere <etienne.carriere@linaro.org> |
firmware: arm_scmi: Add optee transport Add a new transport channel to the SCMI firmware interface driver for SCMI message exchange based on optee transport channel. The optee transport is realized by connecting and invoking OP-TEE SCMI service interface PTA. Optee transport support (CONFIG_ARM_SCMI_TRANSPORT_OPTEE) is default enabled when optee driver (CONFIG_OPTEE) is enabled. Effective optee transport is setup upon OP-TEE SCMI service discovery at optee device initialization. For this SCMI UUID is registered to the optee bus for probing. This is done from the link_supplier operator of the SCMI optee transport. The optee transport can use a statically defined shared memory in which case SCMI device tree node defines it using an "arm,scmi-shmem" compatible phandle through property shmem. Alternatively, optee transport allocates the shared memory buffer from the optee driver when no shmem property is defined. The protocol used to exchange SCMI message over that shared memory is negotiated between optee transport driver and the OP-TEE service through capabilities exchange. OP-TEE SCMI service is integrated in OP-TEE since its release tag 3.13.0. The service interface is published in [1]. Link: [1] https://github.com/OP-TEE/optee_os/blob/3.13.0/lib/libutee/include/pta_scmi_client.h Link: https://lore.kernel.org/r/20211028140009.23331-2-etienne.carriere@linaro.org Cc: Cristian Marussi <cristian.marussi@arm.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
1ba603f5 |
|
11-Feb-2022 |
Alyssa Ross <hi@alyssa.is> |
firmware: arm_scmi: Remove space in MODULE_ALIAS name modprobe can't handle spaces in aliases. Get rid of it to fix the issue. Link: https://lore.kernel.org/r/20220211102704.128354-1-sudeep.holla@arm.com Fixes: aa4f886f3893 ("firmware: arm_scmi: add basic driver infrastructure for SCMI") Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Alyssa Ross <hi@alyssa.is> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
c0397c85 |
|
09-Aug-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Use WARN_ON() to check configured transports Use a WARN_ON() when SCMI stack is loaded to check the consistency of configured SCMI transports instead of the current compile-time check BUILD_BUG_ON() to avoid breaking bot-builds on random bad configs. Bail-out early and noisy during SCMI stack initialization if no transport was enabled in configuration since SCMI cannot work without at least one enabled transport and such constraint cannot be enforced in Kconfig due to circular dependency issues. Link: https://lore.kernel.org/r/20210809092245.8730-1-cristian.marussi@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>
|
#
1e7cbfaa |
|
04-Aug-2021 |
Rishabh Bhatnagar <rishabhb@codeaurora.org> |
firmware: arm_scmi: Free mailbox channels if probe fails Mailbox channels for the base protocol are setup during probe. There can be a scenario where probe fails to acquire the base protocol due to a timeout leading to cleaning up of all device managed memory including the scmi_mailbox structure setup during mailbox_chan_setup function. | arm-scmi soc:qcom,scmi: timed out in resp(caller: version_get+0x84/0x140) | arm-scmi soc:qcom,scmi: unable to communicate with SCMI | arm-scmi: probe of soc:qcom,scmi failed with error -110 Now when a message arrives at cpu slightly after the timeout, the mailbox controller will try to call the rx_callback of the client and might end up accessing freed memory. | rx_callback+0x24/0x160 | mbox_chan_received_data+0x44/0x94 | __handle_irq_event_percpu+0xd4/0x240 This patch frees the mailbox channels setup during probe and adds some more error handling in case the probe fails. Link: https://lore.kernel.org/r/1628111999-21595-1-git-send-email-rishabhb@codeaurora.org Tested-by: Cristian Marussi <cristian.marussi@arm.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
46abe13b |
|
03-Aug-2021 |
Igor Skalkin <igor.skalkin@opensynergy.com> |
firmware: arm_scmi: Add virtio transport This transport enables communications with an SCMI platform through virtio; the SCMI platform will be represented by a virtio device. Implement an SCMI virtio driver according to the virtio SCMI device spec [1]. Virtio device id 32 has been reserved for the SCMI device [2]. The virtio transport has one Tx channel (virtio cmdq, A2P channel) and at most one Rx channel (virtio eventq, P2A channel). The following feature bit defined in [1] is not implemented: VIRTIO_SCMI_F_SHARED_MEMORY. The number of messages which can be pending simultaneously is restricted according to the virtqueue capacity negotiated at probing time. As soon as Rx channel message buffers are allocated or have been read out by the arm-scmi driver, feed them back to the virtio device. Since some virtio devices may not have the short response time exhibited by SCMI platforms using other transports, set a generous response timeout. SCMI polling mode is not supported by this virtio transport since deemed meaningless: polling mode operation is offered by the SCMI core to those transports that could not provide a completion interrupt on the TX path, which is never the case for virtio whose core callbacks can easily call into core scmi_rx_callback upon messages reception. [1] https://github.com/oasis-tcs/virtio-spec/blob/master/virtio-scmi.tex [2] https://www.oasis-open.org/committees/ballot.php?id=3496 Link: https://lore.kernel.org/r/20210803131024.40280-16-cristian.marussi@arm.com Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Co-developed-by: Peter Hilber <peter.hilber@opensynergy.com> Co-developed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Igor Skalkin <igor.skalkin@opensynergy.com> [ Peter: Adapted patch for submission to upstream. ] Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com> [ Cristian: simplified driver logic, changed link_supplier and channel available/setup logic, removed dummy callbacks ] Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
13fba878 |
|
03-Aug-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add priv parameter to scmi_rx_callback Add a new opaque void *priv parameter to scmi_rx_callback which can be optionally provided by the transport layer when invoking scmi_rx_callback and that will be passed back to the transport layer in xfer->priv. This can be used by transports that needs to keep track of their specific data structures together with the valid xfers. Link: https://lore.kernel.org/r/20210803131024.40280-15-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
78852812 |
|
03-Aug-2021 |
Peter Hilber <peter.hilber@opensynergy.com> |
firmware: arm_scmi: Add optional link_supplier() transport op Some transports are also effectively registered with other kernel subsystem in order to be properly probed and initialized; as a consequence such kind of transports, and their related devices, might still not have been probed and initialized at the time the main SCMI core driver is probed. Add an optional .link_supplier() transport operation which can be used by the core SCMI stack to dynamically check if the transport is ready and dynamically link its device to the SCMI platform instance device. Link: https://lore.kernel.org/r/20210803131024.40280-13-cristian.marussi@arm.com Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com> [ Cristian: reworded commit message ] Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
c92c3e38 |
|
03-Aug-2021 |
Igor Skalkin <igor.skalkin@opensynergy.com> |
firmware: arm_scmi: Add method to override max message number The maximum number of simultaneously pending messages is a transport specific quantity that is usually described statically in struct scmi_desc. Some transports, though, can calculate such number only at run-time after some initial transport specific setup and probing is completed; moreover the resulting max message numbers could also be different between rx and tx channels. Add an optional get_max_msg() operation so that a transport can report more accurate max message numbers for each channel type. The value in scmi_desc.max_msg is still used as default when transport does not provide any get_max_msg() method. Link: https://lore.kernel.org/r/20210803131024.40280-11-cristian.marussi@arm.com Co-developed-by: Peter Hilber <peter.hilber@opensynergy.com> Co-developed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Igor Skalkin <igor.skalkin@opensynergy.com> [ Peter: Adapted patch for submission to upstream. ] Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com> [ Cristian: refactored how get_max_msg() is used to minimize core changes ] Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
e8419c24 |
|
03-Aug-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Make SCMI transports configurable Add configuration options to be able to select which SCMI transports have to be compiled into the SCMI stack. Mailbox and SMC are by default enabled if their related dependencies are satisfied. While doing that move all SCMI related config options in their own dedicated submenu. Link: https://lore.kernel.org/r/20210803131024.40280-9-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
2930abcf |
|
03-Aug-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Make polling mode optional Add a check for the presence of .poll_done transport operation so that transports that do not need to support polling mode have no need to provide a dummy .poll_done callback either and polling mode can be disabled in the SCMI core for that tranport. Link: https://lore.kernel.org/r/20210803131024.40280-8-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
e9b21c96 |
|
03-Aug-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Make .clear_channel optional Make transport operation .clear_channel optional since some transports do not need it and so avoid to have them implement dummy callbacks. Link: https://lore.kernel.org/r/20210803131024.40280-7-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
ed7c04c1 |
|
03-Aug-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Handle concurrent and out-of-order messages Even though in case of asynchronous commands an SCMI platform is constrained to emit the delayed response message only after the related message response has been sent, the configured underlying transport could still deliver such messages together or in inverted order, causing races due to the concurrent or out-of-order access to the underlying xfer. Introduce a mechanism to grant exclusive access to an xfer in order to properly serialize concurrent accesses to the same xfer originating from multiple correlated messages. Add additional state information to xfer descriptors so as to be able to identify out-of-order message deliveries and act accordingly: - when a delayed response is expected but delivered before the related response, the synchronous response is considered as successfully received and the delayed response processing is carried on as usual. - when/if the missing synchronous response is subsequently received, it is discarded as not congruent with the current state of the xfer, or simply, because the xfer has been already released and so, now, the monotonically increasing sequence number carried by the late response is stale. Link: https://lore.kernel.org/r/20210803131024.40280-6-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
9ca5a183 |
|
03-Aug-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Introduce monotonically increasing tokens Tokens are sequence numbers embedded in the each SCMI message header: they are used to correlate commands with responses (and delayed responses), but their usage and policy of selection is entirely up to the caller (usually the OSPM agent), while they are completely opaque to the callee (i.e. SCMI platform) which merely copies them back from the command into the response message header. This also means that the platform does not, can not and should not enforce any kind of policy on received messages depending on the contained sequence number: platform can perfectly handle concurrent requests carrying the same identifiying token if that should happen. Moreover the platform is not required to produce in-order responses to agent requests, the only constraint in these regards is that in case of an asynchronous message the delayed response must be sent after the immediate response for the synchronous part of the command transaction. Currenly the SCMI stack of the OSPM agent selects a token for the egressing commands picking the lowest possible number which is not already in use by an existing in-flight transaction, which means, in other words, that we immediately reuse any token after its transaction has completed or it has timed out: this policy indeed does simplify management and lookup of tokens and associated xfers. Under the above assumptions and constraints, since there is really no state shared between the agent and the platform to let the platform know when a token and its associated message has timed out, the current policy of early reuse of tokens can easily lead to the situation in which a spurious or late received response (or delayed_response), related to an old stale and timed out transaction, can be wrongly associated to a newer valid in-flight xfer that just happens to have reused the same token. This misbehaviour on such late/spurious responses is more easily exposed on those transports that naturally have an higher level of parallelism in processing multiple concurrent in-flight messages. This commit introduces a new policy of selection of tokens for the OSPM agent: each new command transfer now gets the next available, monotonically increasing token, until tokens are exhausted and the counter rolls over. Such new policy mitigates the above issues with late/spurious responses since the tokens are now reused as late as possible (when they roll back ideally) and so it is much easier to identify such late/spurious responses to stale timed out transactions: this also helps in simplifying the specific transports implementation since stale transport messages can be easily identified and discarded early on in the rx path without the need to cross check their actual state with the core transport layer. This mitigation is even more effective when, as is usually the case, the maximum number of pending messages is capped by the platform to a much lower number than the whole possible range of tokens values (2^10). This internal policy change in the core SCMI transport layer is fully transparent to the specific transports so it has not and should not have any impact on the transports implementation. Link: https://lore.kernel.org/r/20210803131024.40280-5-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
ceac257d |
|
03-Aug-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add optional transport_init/exit support Some SCMI transport could need to perform some transport specific setup before they can be used by the SCMI core transport layer: typically this early setup consists in registering with some other kernel subsystem. Add the optional capability for a transport to provide a couple of init and exit functions that are assured to be called early during the SCMI core initialization phase, well before the SCMI core probing step. [ Peter: Adapted RFC patch by Cristian for submission to upstream. ] Link: https://lore.kernel.org/r/20210803131024.40280-4-cristian.marussi@arm.com Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com> [ Cristian: Fixed scmi_transports_exit point of invocation ] Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
36690325 |
|
03-Aug-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Remove scmi_dump_header_dbg() helper Being a while that we have SCMI trace events in the SCMI stack, remove this debug helper and its call sites. Link: https://lore.kernel.org/r/20210803131024.40280-3-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
63b282f1 |
|
03-Aug-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add support for type handling in common functions Add SCMI type handling to pack/unpack_scmi_header common helper functions. Initialize hdr.type properly when initializing a command xfer. Link: https://lore.kernel.org/r/20210803131024.40280-2-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
bdb8742d |
|
12-Jul-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Fix range check for the maximum number of pending messages SCMI message headers carry a sequence number and such field is sized to allow for MSG_TOKEN_MAX distinct numbers; moreover zero is not really an acceptable maximum number of pending in-flight messages. Fix accordingly the checks performed on the value exported by transports in scmi_desc.max_msg Link: https://lore.kernel.org/r/20210712141833.6628-3-cristian.marussi@arm.com Reported-by: Vincent Guittot <vincent.guittot@linaro.org> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> [sudeep.holla: updated the patch title and error message] Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
b98cf55e |
|
12-Jul-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Fix kernel doc warnings about return values Kernel doc validation script still complains about the following: |No description found for return value of 'scmi_get_protocol_device' |No description found for return value of 'scmi_devm_notifier_register' |No description found for return value of 'scmi_devm_notifier_unregister' Fix adding missing Return kernel-doc statements. Link: https://lore.kernel.org/r/20210712143504.33541-1-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
7a691f16 |
|
07-Jul-2021 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Fix possible scmi_linux_errmap buffer overflow The scmi_linux_errmap buffer access index is supposed to depend on the array size to prevent element out of bounds access. It uses SCMI_ERR_MAX to check bounds but that can mismatch with the array size. It also changes the success into -EIO though scmi_linux_errmap is never used in case of success, it is expected to work for success case too. It is slightly confusing code as the negative of the error code is used as index to the buffer. Fix it by negating it at the start and make it more readable. Link: https://lore.kernel.org/r/20210707135028.1869642-1-sudeep.holla@arm.com Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
61832b35 |
|
08-Jun-2021 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Avoid multiple initialisations of hdr->protocol_id Since the hdr->protocol_id is set from the scmi_protocol_instance handle just before the transfer, there is no need to initialise the same in scmi_xfer_get_init. Remove the unnecessary initialisations. Link: https://lore.kernel.org/r/20210608140140.2042257-1-sudeep.holla@arm.com Tested-by: Cristian Marussi <cristian.marussi@arm.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
e30d91d4 |
|
06-Jun-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Move reinit_completion from scmi_xfer_get to do_xfer Re-using timed out xfers in a loop can lead to issue if completion was not properly reinitialized. Move reinit_completion from scmi_xfer_get to do_xfer to avoid the issue. Link: https://lore.kernel.org/r/20210606221232.33768-3-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> [sudeep.holla: moved reinit_completion instead of adding another one] Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
f1748b1e |
|
08-Jun-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add delayed response status check A successfully received delayed response could anyway report a failure at the protocol layer in the message status field. Add a check also for this error condition. Link: https://lore.kernel.org/r/20210608103056.3388-1-cristian.marussi@arm.com Fixes: 58ecdf03dbb9 ("firmware: arm_scmi: Add support for asynchronous commands and delayed response") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
ab7766b7 |
|
03-Jun-2021 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Fix the build when CONFIG_MAILBOX is not selected 0day CI kernel test robot reported following build error with randconfig aarch64-linux-ld: drivers/firmware/arm_scmi/driver.o:(.rodata+0x1e0): undefined reference to `scmi_mailbox_desc' Fix the error by adding CONFIG_MAILBOX dependency for scmi_mailbox_desc. Link: https://lore.kernel.org/r/20210603072631.1660963-1-sudeep.holla@arm.com Cc: Etienne Carriere <etienne.carriere@linaro.org> Cc: Cristian Marussi <cristian.marussi@arm.com> Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Cristian Marussi <cristian.marussi@arm.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
0cb7af47 |
|
01-Jun-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Reset Rx buffer to max size during async commands During an async commands execution the Rx buffer length is at first set to max_msg_sz when the synchronous part of the command is first sent. However once the synchronous part completes the transport layer waits for the delayed response which will be processed using the same xfer descriptor initially allocated. Since synchronous response received at the end of the xfer will shrink the Rx buffer length to the effective payload response length, it needs to be reset again. Raise the Rx buffer length again to max_msg_sz before fetching the delayed response to ensure full response is read correctly from the shared memory. Link: https://lore.kernel.org/r/20210601102421.26581-2-cristian.marussi@arm.com Fixes: 58ecdf03dbb9 ("firmware: arm_scmi: Add support for asynchronous commands and delayed response") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> [sudeep.holla: moved reset to scmi_handle_response as it could race with do_xfer_with_response] Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
d4f9dddd |
|
15-Mar-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add dynamic scmi devices creation Having added the support for SCMI protocols as modules in order to let vendors extend the SCMI core with their own additions it seems odd to then force SCMI drivers built on top to use a static device table to declare their devices since this way any new SCMI drivers addition would need the core SCMI device table to be updated too. Remove the static core device table and let SCMI drivers to simply declare which device/protocol pair they need at initialization time: the core will then take care to generate such devices dynamically during platform initialization or at module loading time, as long as the requested underlying protocol is defined in the devicetree. Link: https://lore.kernel.org/r/20210316124903.35011-39-cristian.marussi@arm.com Tested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
f5800e0b |
|
15-Mar-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add protocol modularization support Extend SCMI protocols accounting mechanism to address possible module usage and add the support to possibly define new protocols as loadable modules. Keep the standard protocols built into the SCMI core. Link: https://lore.kernel.org/r/20210316124903.35011-38-cristian.marussi@arm.com Tested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
a02d7c93 |
|
15-Mar-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Make notify_priv really private Notification private data is currently accessible via handle->notify_priv, this data was indeed meant to be private to the notification core support and not to be accessible by SCMI drivers. Make it private hiding it inside instance descriptor struct scmi_info and accessible only via dedicated helpers. Link: https://lore.kernel.org/r/20210316124903.35011-36-cristian.marussi@arm.com Tested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
9162afa2 |
|
15-Mar-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Cleanup unused core transfer helper wrappers Remove unused core scmi_xfer wrappers now that we have migrated all protocols to the new interface based on protocol handles. Link: https://lore.kernel.org/r/20210316124903.35011-34-cristian.marussi@arm.com Tested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
f0e73cee |
|
15-Mar-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Make references to handle const Now that all the protocol private variable data have been moved out of struct scmi_handle, mark all of its references as const. Link: https://lore.kernel.org/r/20210316124903.35011-32-cristian.marussi@arm.com Tested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
8d3581c2 |
|
15-Mar-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Port base protocol to new interface Port the SCMI base protocol to new protocol handles based interface. Link: https://lore.kernel.org/r/20210316124903.35011-11-cristian.marussi@arm.com Tested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
3d5d6e84 |
|
15-Mar-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add helper to access protocol revision/version Add an helper to access from a protocol handle, the SCMI version data which is exposed on sysfs. Such helper will be needed by SCMI base protocol initialization once it will be moved to new protocol handles scheme. Link: https://lore.kernel.org/r/20210316124903.35011-10-cristian.marussi@arm.com Tested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
a4a20b09 |
|
15-Mar-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add new protocol handle core transfer ops Add new core SCMI transfer operations based on protocol handles to enable protocols to builds and send their own protocol specific messages. Keep old original scmi_xfer_ operations interface as wrappers around the new interface in order to let coexist old and new interfaces to ease protocol by protocol migration. In order to support such migration the above wrappers and some additional transient code is also introduced in this commit. It will be later removed as a whole once the full migration of protocols and SCMI drivers will have been completed. Link: https://lore.kernel.org/r/20210316124903.35011-9-cristian.marussi@arm.com Tested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
b9f7fd90 |
|
15-Mar-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Convert events registration to protocol handles Convert all refactored events registration routines to use protocol handles. In order to maintain bisectability and to allow protocols and drivers to be later ported to the new protocol handle interface one by one, introduce here also some transient code that will be removed later in order to ease such transition. Link: https://lore.kernel.org/r/20210316124903.35011-8-cristian.marussi@arm.com Tested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
533c7095 |
|
15-Mar-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Refactor events registration Add a new refactored protocol events registration helper and invoke it from the centralized initialization process triggered by get_ops() and friends. Also add a `get_num_sources` as a new optional callback amongst protocol events operations. Finally remove events registration call-sites from within the legacy protocol init routines. Link: https://lore.kernel.org/r/20210316124903.35011-7-cristian.marussi@arm.com Tested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
23934efe |
|
15-Mar-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Introduce devres get/put protocols operations Expose to the SCMI drivers a new devres managed common protocols API based on generic get/put methods and protocol handles. All drivers still keep using the old API, no functional change. Link: https://lore.kernel.org/r/20210316124903.35011-4-cristian.marussi@arm.com Tested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
d7b6cc56 |
|
15-Mar-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Introduce protocol handle definitions Add basic protocol handles definitions and private data helpers. A protocol handle identifies a protocol instance initialized against a specific handle, it embeds all the references to the core SCMI transfer methods that will be needed by a protocol implementation to build and send its own protocol specific messages using common core methods. As such, in the interface, a protocol handle will be passed down from the core to the protocol specific initialization callback at init time. Anyways, at this point only definitions are introduced, all protocols initialization code and SCMI drivers probing is still based on the old interface, so no functional change. Link: https://lore.kernel.org/r/20210316124903.35011-3-cristian.marussi@arm.com Tested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
48dc16e2 |
|
15-Mar-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Extend protocol registration interfaces Extend common protocol registration routines and provide some new generic protocols get/put helpers that can track protocols usage and automatically perform the proper initialization and de-initialization on demand when required. Convert all standard protocols to use this new registration scheme while keeping them all still using the usual initialization logic bound to SCMI devices probing. Link: https://lore.kernel.org/r/20210316124903.35011-2-cristian.marussi@arm.com Tested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
f774117c |
|
09-Mar-2021 |
Jyoti Bhayana <jbhayana@google.com> |
iio/scmi: Adding support for IIO SCMI Based Sensors This change provides ARM SCMI Protocol based IIO device. This driver provides support for Accelerometer and Gyroscope using SCMI Sensor Protocol extensions added in the SCMIv3.0 ARM specification Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Jyoti Bhayana <jbhayana@google.com> Link: https://lore.kernel.org/r/20210212172235.507028-2-jbhayana@google.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20210309231259.78050-2-jbhayana@google.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
a90b6543 |
|
12-Jan-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Fix call site of scmi_notification_exit Call scmi_notification_exit() only when SCMI platform driver instance has been really successfully removed. Link: https://lore.kernel.org/r/20210112191326.29091-1-cristian.marussi@arm.com Fixes: 6b8a69131dc63 ("firmware: arm_scmi: Enable notification core") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> [sudeep.holla: Move the call outside the list mutex locking] Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
ec883819 |
|
19-Nov-2020 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add support to enumerated SCMI voltage domain device Add SCMI voltage domain device name to the core list of supported protocol devices so that it can be enumerated if the firmware supports it. Link: https://lore.kernel.org/r/20201119191051.46363-3-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
2add5cac |
|
19-Nov-2020 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add voltage domain management protocol support SCMI v3.0 introduces voltage domain protocol which provides commands to: - Discover the voltage levels supported by a domain - Get the configuration and voltage level of a domain - Set the configuration and voltage level of a domain Let us add support for the same. Link: https://lore.kernel.org/r/20201119191051.46363-2-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
9724722f |
|
12-Oct-2020 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Add missing Rx size re-initialisation Few commands provide the list of description partially and require to be called consecutively until all the descriptors are fetched completely. In such cases, we don't release the buffers and reuse them for consecutive transmits. However, currently we don't reset the Rx size which will be set as per the response for the last transmit. This may result in incorrect response size being interpretted as the firmware may repond with size greater than the one set but we read only upto the size set by previous response. Let us reset the receive buffer size to max possible in such cases as we don't know the exact size of the response. Link: https://lore.kernel.org/r/20201012141746.32575-1-sudeep.holla@arm.com Fixes: b6f20ff8bd94 ("firmware: arm_scmi: add common infrastructure and support for base protocol") Reported-by: Etienne Carriere <etienne.carriere@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
1eaf18e3 |
|
06-Sep-2020 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Move scmi protocols registration into the driver In preparation to enable building SCMI as a single module, let us move the SCMI protocol registration call into the driver. This enables us to also add unregistration of the SCMI protocols. The main reason for this is to keep it simple instead of maintaining it as separate modules and dealing with all possible initcall races and deferred probe handling. We can move it as separate modules if needed in future. Link: https://lore.kernel.org/r/20200907195046.56615-4-sudeep.holla@arm.com Tested-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
5a2f0a0b |
|
06-Sep-2020 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Move scmi bus init and exit calls into the driver In preparation to enable building scmi as a single module, let us move the scmi bus {de-,}initialisation call into the driver. The main reason for this is to keep it simple instead of maintaining it as separate modules and dealing with all possible initcall races and deferred probe handling. We can move it as separate modules if needed in future. Link: https://lore.kernel.org/r/20200907195046.56615-3-sudeep.holla@arm.com Tested-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
481f6ccf |
|
07-Sep-2020 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Add SCMI device for system power protocol Add SCMI device for system power protocol by just adding the name "syspower" to the list of supported core protocol devices. Link: https://lore.kernel.org/r/20200907174657.32466-3-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
72a5eb9d |
|
10-Jul-2020 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Remove fixed size fields from reports/scmi_event_header Event reports are used to convey information describing events to the registered user-callbacks: they are necessarily derived from the underlying raw SCMI events' messages but they are not meant to expose or directly mirror any of those messages data layout, which belong to the protocol layer. Using fixed size types for report fields, mirroring messages structure, is at odd with this: get rid of them using more generic, equivalent, typing. Substitute scmi_event_header fixed size fields with generic types too and shuffle around fields definitions to minimize implicit padding while adapting involved functions. Link: https://lore.kernel.org/r/20200710133919.39792-3-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
6b8a6913 |
|
01-Jul-2020 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Enable notification core Initialize and enable SCMI notifications core support during bus/driver probe phase, so that protocols can start registering their supported events during their initialization. Link: https://lore.kernel.org/r/20200701155348.52864-5-cristian.marussi@arm.com Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
d7642823 |
|
25-Jun-2020 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Use HAVE_ARM_SMCCC_DISCOVERY instead of ARM_PSCI_FW Commit e5bfb21d98b6 ("firmware: smccc: Add HAVE_ARM_SMCCC_DISCOVERY to identify SMCCC v1.1 and above") introduced new config option to identify the availability of SMCCC discoverability of version and features transparently hiding the indirect dependency on ARM_PSCI_FW. Commit 5a897e3ab429 ("firmware: arm_scmi: fix psci dependency") just worked around the build dependency making SCMI SMC/HVC transport depend on ARM_PSCI_FW at the time. Since it really just relies on SMCCC directly and not on ARM_PSCI_FW, let us move to use CONFIG_HAVE_ARM_SMCCC_DISCOVERY instead of CONFIG_ARM_PSCI_FW. Link: https://lore.kernel.org/r/20200625101937.51939-1-sudeep.holla@arm.com Cc: Peng Fan <peng.fan@nxp.com> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
bad0d73b |
|
09-Jun-2020 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Use signed integer to report transfer status Currently the trace event 'scmi_xfer_end' reports the status of the transfer using the unsigned status field read from the firmware which may not be easy to interpret. It may also miss to emit any timeouts that happen in the driver resulting in emitting garbage in the status field in those scenarios. Let us use signed integer so that error values are emitted out after they are mapped from firmware error formats to standard linux error codes. While at this, also include any timeouts in the driver itself. Link: https://lore.kernel.org/r/20200609134503.55860-1-sudeep.holla@arm.com Cc: Jim Quinlan <james.quinlan@broadcom.com> Cc: Lukasz Luba <lukasz.luba@arm.com> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
5a897e3a |
|
07-May-2020 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: fix psci dependency When CONFIG_ARM_PSCI_FW is disabled but CONFIG_HAVE_ARM_SMCCC is enabled, arm-scmi runs into a link failure: arm-linux-gnueabi-ld: drivers/firmware/arm_scmi/smc.o: in function `smc_send_message': smc.c:(.text+0x200): undefined reference to `arm_smccc_1_1_get_conduit' Change from HAVE_ARM_SMCCC to ARM_PSCI_FW config dependency for now. We rely on PSCI bindings anyways for the conduit and this should be fine. Link: https://lore.kernel.org/r/20200507144905.11397-1-sudeep.holla@arm.com Fixes: 1dc6558062da ("firmware: arm_scmi: Add smc/hvc transport") Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
c5bceb98 |
|
20-Apr-2020 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Fix handling of unexpected delayed responses Upon reception of an unexpected bogus delayed response, clear the channel and bail-out safely. Link: https://lore.kernel.org/r/20200420152315.21008-5-cristian.marussi@arm.com Fixes: 4d09852b6f01 ("firmware: arm_scmi: Add support for notifications message processing") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
d04fb2b2 |
|
20-Apr-2020 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Clear channel for delayed responses Clear channel properly when done processing a delayed response. This will let the platform firmware know that the channel is now free to use it for any new delayed response or notification. Link: https://lore.kernel.org/r/20200420152315.21008-4-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> (sudeep.holla: Updated commit log to reflect that channel is now free for platform to use) Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
b37f5cc8 |
|
20-Apr-2020 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Clear channel on reception of unexpected responses When an unexpected response message is received we currently warn the user and bail-out, ensure to also free the channel by invoking the transport independent operation .clear_channel() Link: https://lore.kernel.org/r/20200420152315.21008-3-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
87dff4e6 |
|
20-Apr-2020 |
Cristian Marussi <cristian.marussi@arm.com> |
firmware: arm_scmi: Rename .clear_notification() transport_ops SCMI transport operation .clear_notification() is indeed a generic method to clear the channel in a transport dependent way, as such it could be a useful helper also in other contexts. Rename such method as .clear_channel(), renaming accordingly also its already existent call-sites. No functional change. Link: https://lore.kernel.org/r/20200420152315.21008-2-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
4d09852b |
|
27-Mar-2020 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Add support for notifications message processing Add the mechanisms to distinguish notifications from delayed responses and command responses. Also add support to properly fetch notification messages upon reception. Notifications processing does not continue any further after the fetch phase. Link: https://lore.kernel.org/r/20200327143438.5382-5-cristian.marussi@arm.com Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> [Reworked/renamed scmi_handle_xfer_delayed_resp()] Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
4ebd8f6d |
|
27-Mar-2020 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Add receive buffer support for notifications With all the plumbing in place, let's just add the separate dedicated receive buffers to handle notifications that can arrive asynchronously from the platform firmware to OS. Also add one check to see if the platform supports any receive channels before allocating the receive buffers: since those buffers are optionally supported though, the whole xfer initialization is also postponed to be able to check for their existence in advance. Link: https://lore.kernel.org/r/20200327143438.5382-2-cristian.marussi@arm.com Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> [Changed parameters in __scmi_xfer_info_init()] Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
1dc65580 |
|
08-Mar-2020 |
Peng Fan <peng.fan@nxp.com> |
firmware: arm_scmi: Add smc/hvc transport Use the value of "arm,smc-id" property from the device tree as the first argument for SMCCC call leaving all the other arguments as zero for now. There is no Rx, only Tx because of smc/hvc not support Rx. Link: https://lore.kernel.org/r/1583673879-20714-3-git-send-email-peng.fan@nxp.com Signed-off-by: Peng Fan <peng.fan@nxp.com> [sudeep.holla: reworded commit log/subject and fixed !HAVE_ARM_SMCCC build] Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
5c8a47a5 |
|
30-Jan-2020 |
Viresh Kumar <viresh.kumar@linaro.org> |
firmware: arm_scmi: Make scmi core independent of the transport type 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 <viresh.kumar@linaro.org> Link: https://lore.kernel.org/r/8698a3cec199b8feab35c2339f02dc232bfd773b.1580448239.git.viresh.kumar@linaro.org Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
c4eb8366 |
|
30-Jan-2020 |
Viresh Kumar <viresh.kumar@linaro.org> |
firmware: arm_scmi: Move macros and helpers to common.h 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 <viresh.kumar@linaro.org> Link: https://lore.kernel.org/r/6615db480370719b0a0241447a5f3feb8eea421f.1580448239.git.viresh.kumar@linaro.org Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
71af05a7 |
|
30-Jan-2020 |
Viresh Kumar <viresh.kumar@linaro.org> |
firmware: arm_scmi: Update doc style comments Fix minor formatting issues with the doc style comments. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://lore.kernel.org/r/1bff7c0d1ad2c8b6eeff9660421f414f8c612eb2.1580448239.git.viresh.kumar@linaro.org Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
729d3530 |
|
17-Dec-2019 |
Lukasz Luba <lukasz.luba@arm.com> |
drivers: firmware: scmi: Extend SCMI transport layer by trace events 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 <james.quinlan@broadcom.com> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
4605e224 |
|
22-Oct-2019 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Add versions and identifier attributes using dev_groups 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 <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
9c5c463f |
|
06-Nov-2019 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Add names to scmi devices created Now that scmi bus provides option to create named scmi device, let us create the default devices with names. This will help to add names for matching to respective drivers and eventually to add multiple devices and drivers per protocol. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
11040889 |
|
06-Nov-2019 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Skip scmi mbox channel setup for addtional devices Now that the scmi bus supports adding multiple devices per protocol, and since scmi_create_protocol_device calls scmi_mbox_chan_setup, we must avoid allocating and initialising the mbox channel if it is already initialised. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
ee7a9c9f |
|
21-Dec-2018 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Add support for multiple device per protocol Currently only one scmi device is created for each protocol enumerated. However, there is requirement to make use of some procotols by multiple kernel subsystems/frameworks. One such example is SCMI PERFORMANCE protocol which can be used by both cpufreq and devfreq drivers. Similarly, SENSOR protocol may be used by hwmon and iio subsystems, and POWER protocol may be used by genpd and regulator drivers. In order to achieve that, let us extend the scmi bus to match based not only protocol id but also the scmi device name if one is available. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
58ecdf03 |
|
08-Jul-2019 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Add support for asynchronous commands and delayed response Messages that are sent to platform, also known as commands and can be: 1. Synchronous commands that block the channel until the requested work has been completed. The platform responds to these commands over the same channel and hence can't be used to send another command until the previous command has completed. 2. Asynchronous commands on the other hand, the platform schedules the requested work to complete later in time and returns almost immediately freeing the channel for new commands. The response indicates the success or failure in the ability to schedule the requested work. When the work has completed, the platform sends an additional delayed response message. Using the same transmit buffer used for sending the asynchronous command even for the delayed response corresponding to it simplifies handling of the delayed response. It's the caller of asynchronous command that is responsible for allocating the completion flag that scmi driver can complete to indicate the arrival of delayed response. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
22d1f761 |
|
08-Jul-2019 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Add mechanism to unpack message headers In order to identify the message type when a response arrives, we need a mechanism to unpack the message header similar to packing. Let's add one. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
38c927fb |
|
08-Jul-2019 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Separate out tx buffer handling and prepare to add rx Currently we pre-allocate transmit buffers only and use the first free slot in that pre-allocated buffer for transmitting any new message that are generally originated from OS to the platform firmware. Notifications or the delayed responses on the other hand are originated from the platform firmware and consumes by the OS. It's better to have separate and dedicated pre-allocated buffers to handle the notifications. We can still use the transmit buffers for the delayed responses. In addition, let's prepare existing scmi_xfer_{get,put} for acquiring and releasing a slot to identify the right(tx/rx) buffers. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
46cc7c28 |
|
08-Jul-2019 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Add receive channel support for notifications With scmi_mbox_chan_setup enabled to identify and setup both Tx and Rx, let's consolidate setting up of both the channels under the function scmi_mbox_txrx_setup. Since some platforms may opt not to support notifications or delayed response, they may not need support for Rx. Hence Rx is optional and failure of setting one up is not considered fatal. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
3748daf7 |
|
08-Jul-2019 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Segregate tx channel handling and prepare to add rx The transmit(Tx) channels are specified as the first entry and the receive(Rx) channels are the second entry as per the device tree bindings. Since we currently just support Tx, index 0 is hardcoded at all required callsites. In order to prepare for adding Rx support, let's remove those hardcoded index and add boolean parameter to identify Tx/Rx channels when setting them up. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
2747a967 |
|
08-Jul-2019 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Reorder some functions to avoid forward declarations Re-shuffling few functions to keep definitions and their usages close. This is also needed to avoid too many unnecessary forward declarations while adding new features(delayed response and notifications). Keeping this separate to avoid mixing up of these trivial change that doesn't affect functionality into the ones that does. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
9dc34d63 |
|
08-Jul-2019 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Check if platform has released shmem before using Sometimes platfom may take too long to respond to the command and OS might timeout before platform transfer the ownership of the shared memory region to the OS with the response. Since the mailbox channel associated with the channel is freed and new commands are dispatch on the same channel, OS needs to wait until it gets back the ownership. If not, either OS may end up overwriting the platform response for the last command(which is fine as OS timed out that command) or platform might overwrite the payload for the next command with the response for the old. The latter is problematic as platform may end up interpretting the response as the payload. In order to avoid such race, let's wait until the OS gets back the ownership before we prepare the shared memory with the payload for the next command. Reported-by: Jim Quinlan <james.quinlan@broadcom.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
5b65af8f |
|
08-Jul-2019 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Use the term 'message' instead of 'command' In preparation to adding support for other two types of messages that SCMI specification mentions, let's replace the term 'command' with the correct term 'message'. As per the specification the messages are of 3 types: commands(synchronous or asynchronous), delayed responses and notifications. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
c29a6289 |
|
08-Jul-2019 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Fix few trivial typos in comments While adding new comments found couple of typos that are better fixed. s/informfation/information/ s/statues/status/ Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
37bbffcb |
|
08-Jul-2019 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: Remove extra check for invalid length message responses scmi_xfer_get_init ensures both transmit and receive buffer lengths are within the maximum limits. If receive buffer length is not supplied by the caller, it's set to the maximum limit value. Receive buffer length is never modified after that. So there's no need for the extra check when receive transmit completion for a command essage. Further, if the response header length is greater than the prescribed receive buffer length, the response buffer is truncated to the latter. Reported-by: Jim Quinlan <james.quinlan@broadcom.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
d9350f21 |
|
22-Mar-2019 |
Aditya Pakki <pakki001@umn.edu> |
firmware: arm_scmi: replace of_match_device->data with of_device_get_match_data() of_match_device can return NULL if no matching device is found though it's highly unlikely to happen in scmi_probe as it's called only if a valid match is found. However we can use of_device_get_match_data() instead of of_match_device()->data to handle NULL pointer checks and return -EINVAL in such a scenario. Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Aditya Pakki <pakki001@umn.edu> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
fa7fe29a |
|
25-Mar-2019 |
Steven Price <steven.price@arm.com> |
firmware: arm_scmi: fix of_node leak in scmi_mailbox_check of_parse_phandle_with_args() requires the caller to call of_node_put() on the returned args->np pointer. Otherwise the reference count will remain incremented. However, in this case, since we don't actually use the returned pointer, we can simply pass in NULL. Fixes: aa4f886f3893f ("firmware: arm_scmi: add basic driver infrastructure for SCMI") Signed-off-by: Steven Price <steven.price@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
632de8f5 |
|
09-May-2018 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: simplify exit path by returning on error Yet another nasty indentation left out during code restructuring. It's must simpler to return on error instead of having unnecessary indentation. Suggested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
8f3397cc |
|
09-May-2018 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: remove unnecessary bitmap_zero kcalloc zeros the memory and it's totally unnecessary to zero the bitmap again using bitmap_zero. This patch just drops the unnecessary use of the bitmap_zero in the context. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
14e297b3 |
|
09-May-2018 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: rename scmi_xfer_{init,get,put} Just after the initial patches were queued, Jonathan Cameron mentioned that scmi_one_xfer_{get_put} were not very clear and suggested to use scmi_xfer_{alloc,free}. While I agree to some extent, the reason not to have alloc/free as these are preallocated buffers and these functions just returns a reference to free slot in that preallocated array. However it was agreed to drop "_one" as it's implicit that we are always dealing with one slot anyways. This patch updates the name accordingly dropping "_one" in both {get,put} functions. Also scmi_one_xfer_init is renamed as scmi_xfer_get_init to reflect the fact that it gets the free slots and then initialise it. Reported-by: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
1baf47c2 |
|
09-May-2018 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: fix kernel-docs documentation There are few missing descriptions for function parameters and structure members along with certain instances where excessive function parameters or structure members are described. This patch fixes all of those warnings. Reported-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
354b2e36 |
|
09-May-2018 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: improve code readability using bitfield accessor macros By using FIELD_{FIT,GET,PREP} and GENMASK macro accessors we can avoid some clumpsy custom shifting and masking macros and also improve the code better readability. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
31c60855 |
|
27-Apr-2018 |
Dan Carpenter <dan.carpenter@oracle.com> |
firmware: arm_scmi: Use after free in scmi_create_protocol_device() We need to return here instead of setting up the freed sdev device as a transport. Fixes: 907b6d14911d ("firmware: arm_scmi: add per-protocol channels support using idr objects") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
907b6d14 |
|
31-Jul-2017 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: add per-protocol channels support using idr objects In order to maintain the channel information per protocol, we need some sort of list or hashtable to hold all this information. IDR provides sparse array mapping of small integer ID numbers onto arbitrary pointers. In this case the arbitrary pointers can be pointers to the channel information. This patch adds support for per-protocol channels using those idr objects. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
fbc4d81a |
|
31-Jul-2017 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: refactor in preparation to support per-protocol channels In order to support per-protocol channels if available, we need to factor out all the mailbox channel information(Tx/Rx payload and channel handle) out of the main SCMI instance information structure. This patch refactors the existing channel information into a separate chan_info structure. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
d4c3751a |
|
20-Jul-2017 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: add support for polling based SCMI transfers It would be useful to have options to perform some SCMI transfers atomically by polling for the completion flag instead of interrupt driven. The SCMI specification has option to disable the interrupt and poll for the completion flag in the shared memory. This patch adds support for polling based SCMI transfers using that option. This might be used for uninterrupted/atomic DVFS operations from the scheduler context. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
bc40081d |
|
06-Jun-2017 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: probe and initialise all the supported protocols Now that we have basic support for all the protocols in the specification, let's probe them individually and initialise them. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
b6f20ff8 |
|
06-Jun-2017 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: add common infrastructure and support for base protocol The base protocol describes the properties of the implementation and provide generic error management. The base protocol provides commands to describe protocol version, discover implementation specific attributes and vendor/sub-vendor identification, list of protocols implemented and the various agents are in the system including OSPM and the platform. It also supports registering for notifications of platform errors. This protocol is mandatory. This patch adds support for the same along with some basic infrastructure to add support for other protocols. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
aa4f886f |
|
28-Mar-2017 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: add basic driver infrastructure for SCMI The SCMI is intended to allow OSPM to manage various functions that are provided by the hardware platform it is running on, including power and performance functions. SCMI provides two levels of abstraction, protocols and transports. Protocols define individual groups of system control and management messages. A protocol specification describes the messages that it supports. Transports describe the method by which protocol messages are communicated between agents and the platform. This patch adds basic infrastructure to manage the message allocation, initialisation, packing/unpacking and shared memory management. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|