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

bus: Make remove callback return void

2021-07-21T09:53:42Z

The driver core ignores the return value of this callback because there is only little it can do when a device disappears. This is the final bit of a long lasting cleanup quest where several buses were converted to also return void from their remove callback. Additionally some resource leaks were fixed that were caused by drivers returning an error code in the expectation that the driver won't go away. With struct bus_type::remove returning void it's prevented that newly implemented buses return an ignored error code and so don't anticipate wrong expectations for driver authors. Reviewed-by: Tom Rix (For fpga) Reviewed-by: Mathieu Poirier Reviewed-by: Cornelia Huck (For drivers/s390 and drivers/vfio) Acked-by: Russell King (Oracle) (For ARM, Amba and related parts) Acked-by: Mark Brown Acked-by: Chen-Yu Tsai (for sunxi-rsb) Acked-by: Pali Rohár Acked-by: Mauro Carvalho Chehab (for media) Acked-by: Hans de Goede (For drivers/platform) Acked-by: Alexandre Belloni Acked-By: Vinod Koul Acked-by: Juergen Gross (For xen) Acked-by: Lee Jones (For mfd) Acked-by: Johannes Thumshirn (For mcb) Acked-by: Johan Hovold Acked-by: Srinivas Kandagatla (For slimbus) Acked-by: Kirti Wankhede (For vfio) Acked-by: Maximilian Luz Acked-by: Heikki Krogerus (For ulpi and typec) Acked-by: Samuel Iglesias Gonsálvez (For ipack) Acked-by: Geoff Levand (For ps3) Acked-by: Yehezkel Bernat (For thunderbolt) Acked-by: Alexander Shishkin (For intel_th) Acked-by: Dominik Brodowski (For pcmcia) Acked-by: Rafael J. Wysocki (For ACPI) Acked-by: Bjorn Andersson (rpmsg and apr) Acked-by: Srinivas Pandruvada (For intel-ish-hid) Acked-by: Dan Williams (For CXL, DAX, and NVDIMM) Acked-by: William Breathitt Gray (For isa) Acked-by: Stefan Richter (For firewire) Acked-by: Benjamin Tissoires (For hid) Acked-by: Thorsten Scherer (For siox) Acked-by: Sven Van Asbroeck (For anybuss) Acked-by: Ulf Hansson (For MMC) Acked-by: Wolfram Sang # for I2C Acked-by: Sudeep Holla Acked-by: Geert Uytterhoeven Acked-by: Dmitry Torokhov Acked-by: Finn Thain Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20210713193522.1770306-6-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman

firmware: arm_scmi: Ensure drivers provide a probe function

2021-07-12T13:16:19Z

The bus probe callback calls the driver callback without further checking. Better be safe than sorry and refuse registration of a driver without a probe function to prevent a NULL pointer exception. Link: https://lore.kernel.org/r/20210624095059.4010157-2-sudeep.holla@arm.com Fixes: 933c504424a2 ("firmware: arm_scmi: add scmi protocol bus to enumerate protocol devices") Reported-by: Uwe Kleine-König Tested-by: Cristian Marussi Reviewed-by: Cristian Marussi Acked-by: Uwe Kleine-König Signed-off-by: Sudeep Holla

firmware: arm_scmi: Simplify device probe function on the bus

2021-07-12T13:16:18Z

When the driver core calls the probe callback it already checked that the devices match, so there is no need to call the match callback again. Link: https://lore.kernel.org/r/20210624095059.4010157-1-sudeep.holla@arm.com Suggested-by: Uwe Kleine-König Tested-by: Cristian Marussi Reviewed-by: Cristian Marussi Acked-by: Uwe Kleine-König Signed-off-by: Sudeep Holla

firmware: arm_scmi: Add dynamic scmi devices creation

2021-03-30T15:35:16Z

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 Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Add protocol modularization support

2021-03-30T15:35:16Z

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 Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Cleanup legacy protocol init code

2021-03-30T15:35:15Z

Now that all protocols and drivers have been ported to the new interface based on protocol handles and get/put operations, remove all the legacy transient initialization code. Link: https://lore.kernel.org/r/20210316124903.35011-33-cristian.marussi@arm.com Tested-by: Florian Fainelli Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Extend protocol registration interfaces

2021-03-29T08:40:47Z

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 Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Move scmi bus init and exit calls into the driver

2020-09-14T06:30:48Z

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 Signed-off-by: Sudeep Holla

firmware: arm_scmi: Skip protocol initialisation for additional devices

2019-12-24T11:36:26Z

The scmi bus now supports adding multiple devices per protocol, and since scmi_protocol_init is called for each scmi device created, we must avoid allocating protocol private data and initialising the protocol itself if it is already initialised. In order to achieve the same, we can simple replace the idr pointer from protocol initialisation function to a dummy function. Suggested-by: Cristian Marussi Reviewed-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Add support for multiple device per protocol

2019-12-24T11:35:48Z

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 Signed-off-by: Sudeep Holla