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 14:10:05 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Daniel Scally <djrscally@...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>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>
Subject: Re: [RFC PATCH v2 1/3] regulator: core: Add regulator_lookup_list

On Wed, Aug 25, 2021 at 1:34 PM Mark Brown <broonie@...nel.org> wrote:
>
> On Wed, Aug 25, 2021 at 12:06:18AM +0100, Daniel Scally wrote:
> > In some situations regulator devices can be enumerated via either
> > devicetree or ACPI and bound to regulator drivers but without any
> > init data being provided in firmware. This leaves their consumers
> > unable to acquire them via regulator_get().
> >
> > To fix the issue, add the ability to register a lookup table to a
> > list within regulator core, which will allow board files to provide
> > init data via matching against the regulator name and device name in
> > the same fashion as the gpiod lookup table.
>
> This is the wrong level to do this I think, this is a generic problem
> that affects all kinds of platform data so if we're not going to scatter
> DMI quirks throughout the drivers like we currently do then we should
> have a way for boards to just store generic platform data for a device
> and then have that platform data joined up with the device later.  This
> could for example also be used by all the laptop audio subsystems which
> need DMI quirk tables in drivers for their components to figure out how
> they're wired up and avoids the need to go through subsystems adding new
> APIs.

What you are describing sounds similar to what we have, i.e. fwnode graph.
That's how v4l2 describes complex connections between devices in the
camera world.

But IIRC you don't like this idea to be present with regulators (as
per v1 of this series).

So, what do you propose then?


--
With Best Regards,
Andy Shevchenko