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]

Message-ID: <20210825145232.GI5186@sirena.org.uk>
Date:   Wed, 25 Aug 2021 15:52:32 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:     Daniel Scally <djrscally@...il.com>,
        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

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.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)