linux-kernel - Re: [RFC PATCH v2 1/3] regulator: core: Add regulator_lookup

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]

Date:   Wed, 25 Aug 2021 23:09:09 +0100
From:   Daniel Scally <djrscally@...il.com>
To:     Mark Brown <broonie@...nel.org>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Hans de Goede <hdegoede@...hat.com>,
        Mark Gross <mgross@...ux.intel.com>,
        Maximilian Luz <luzmaximilian@...il.com>,
        Kieran Bingham <kieran.bingham@...asonboard.com>,
        Sakari Ailus <sakari.ailus@....fi>
Subject: Re: [RFC PATCH v2 1/3] regulator: core: Add regulator_lookup_list

Hi Mark

On 25/08/2021 15:52, Mark Brown wrote:
> On Wed, Aug 25, 2021 at 05:22:49PM +0300, Laurent Pinchart wrote:
>
>> a very large number of regulators, it may not be too bad in practice. If
>> I were to maintain the regulator subsystem I'd probably want a
>> centralized implementation there, but that's certainly a personal
>> preference, at least partly.
> We already have some generic platform data for regulators so if it
> doesn't want to define anything custom all a driver has to do is forward
> that struct on to the core for handling, otherwise it just has to pick
> the generic struct out of whatever custom thing it defines.
>
>> On a side note, this RFC looks quite similar to what the GPIO subsystem
>> does, which I personally consider nice as differences between regulator
>> and GPIO in these areas are confusing for users.
> My pushback here is that if all we're doing is providing a mechanism to
> match platform data with firmware provided devices we shouldn't be
> implementing it per API in the first place, we should have a generic
> mechanism for system level quirking to pass platform data to devices
> which works with anything - it could also absorb a lot of the DMI based
> quirking we have in drivers already which boil down to using a DMI match
> to pick some platform data.


Alright; and what about parsing the platform data into a struct
regulator_init_data then...at the moment that's left up to the
individual regulator drivers. In my mind that's something better left to
core, so rather than finding the right instance of struct
regulator_init_data from the regulator_lookup_list the
regulator_lookup_init_data() function would be finding the right
instance of the struct from cfg->dev->platform_data instead...what are
your thoughts on that?