[PATCH v6 29/37] regulator: scmi: port driver to the new scmi_voltage_proto_ops interface

Cristian Marussi cristian.marussi at arm.com
Wed Feb 3 09:39:15 EST 2021


Hi Mark

On Wed, Feb 03, 2021 at 01:24:32PM +0000, Mark Brown wrote:
> On Tue, Feb 02, 2021 at 10:15:47PM +0000, Cristian Marussi wrote:
> > Port driver to the new SCMI Voltage interface based on protocol handles
> > and common devm_get_ops().
> 
> I have no cover letter or other context for this, what's the story here?

Sorry I've CCed only the relevant patches to the subsystem maintainers.

The whole story is in the series cover-letter here:

https://lore.kernel.org/linux-arm-kernel/20210202221555.41167-1-cristian.marussi@arm.com/

In summary we wanted to ease both protocols modularization in general and1
the implementation of custom vendor custom protocols and drivers (as
allowed by SCMI spec): to do that I reviewed the internals of SCMI protos
handling to centralize resource accounting (so that I can track who is
using which protocol at any time), and I generalized the interface exposed
to the SCMI drivers so that as an example:

handle->voltage_ops->level_set(handle, ...)

becomes:

/*get access to the proto and ops in probe()*/
vops = handle->devm_get_protocol(handle, SCMI_PROTOCOL_VOLTAGE, &ph);

/* use it */
vops->level_set(ph, ...)

This way the interface is unified for all protocols both standard and
custom and if you develop a new custom proto implementation, and driver,
you'll end-up using it in a similar way:

cops = handle->devm_get_protocol(handle, SCMI_PROTOCOL_CUSTOM, &ph);

cops->custom_method(ph, )

without having to add an endless stream of new custom *_ops structs to
the handle struct.

To attain the above, though, there are also a number of internal changes
in the series that are tightly related to the drivers' interface which I
am changing as an example with this patch, so the series contains a bit
of transient code added and removed along the way around the drivers
changes to maintain bisectability throughout all the series.

Apologies to have not included the cover-letter at first to provide
context.

Thanks

Cristian



More information about the linux-arm-kernel mailing list