linux-kernel - Re: [PATCH v6 29/37] regulator: scmi: port driver to the new scmi_voltage_proto

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210203143915.GE8355@e120937-lin>
Date:   Wed, 3 Feb 2021 14:39:15 +0000
From:   Cristian Marussi <cristian.marussi@....com>
To:     Mark Brown <broonie@...nel.org>
Cc:     linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        sudeep.holla@....com, lukasz.luba@....com,
        james.quinlan@...adcom.com, Jonathan.Cameron@...wei.com,
        f.fainelli@...il.com, etienne.carriere@...aro.org,
        thara.gopinath@...aro.org, vincent.guittot@...aro.org,
        souvik.chakravarty@....com
Subject: Re: [PATCH v6 29/37] regulator: scmi: port driver to the new
 scmi_voltage_proto_ops interface

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