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:40:53 +0300
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     Hans de Goede <hdegoede@...hat.com>
Cc:     Mark Brown <broonie@...nel.org>,
        Daniel Scally <djrscally@...il.com>,
        linux-kernel@...r.kernel.org, platform-driver-x86@...r.kernel.org,
        Liam Girdwood <lgirdwood@...il.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 Hans,

On Wed, Aug 25, 2021 at 10:25:23PM +0200, Hans de Goede wrote:
> On 8/25/21 5:42 PM, Laurent Pinchart wrote:
> > On Wed, Aug 25, 2021 at 04:27:35PM +0100, Mark Brown wrote:
> >> On Wed, Aug 25, 2021 at 04:48:15PM +0200, Hans de Goede wrote:
> >>
> >>> Daniel, I believe that what Mark wants here is something similar to what
> >>> we already do for the 5v boost converter regulator in the TI bq24190 charger
> >>> chip used on some Cherry Trail devices.
> >>
> >> Yeah, that or something like a generalized version of it which lets a
> >> separate quirk file like they seem to have register the data to insert -
> >> I'd be happy enough with the simple thing too given that it's not
> >> visible to anything, or with DMI quirks in the regulator driver too for
> >> that matter if it's just one or two platforms but there do seem to be
> >> rather a lot of these platforms which need quirks.
> > 
> > Let's also remember that we have to handle not just regulators, but also
> > GPIOs and clocks. And I'm pretty sure there will be more. We could have
> > a mechanism specific to the tps68470 driver to pass platform data from
> > the board file to the driver, and replicate that mechanism in different
> > drivers (for other regulators, clocks and GPIOs), but I really would
> > like to avoid splitting the DMI-conditioned platform data in those
> > drivers directly. I'd like to store all the init data for a given
> > platform in a single "board" file.
> 
> I agree, but so far all the handling for clks/gpios for IPU3 (+ IPU4 (*))
> laptops is done in the drivers/platform/x86/intel/int3472 code and the
> passing of platform_data with regulator init-data would also happen in
> the mfd-cell instantiation code living there. IOW if we just go with
> that then we will already have everything in one place. At least
> for the IPU3 case.

If the GPIOs are also hooked up to the TPS68470 and not to GPIOs of the
SoC, then I suppose that would be fine in this case.

Do you have any plan to work on IPU4 support ? ;-)

> *) IPU4 also used the INT3472 ACPI devices and what we have for discrete
> IO devices seems to match.

-- 
Regards,

Laurent Pinchart