linux-kernel - Re: [RFC PATCH 0/2] Add software node support to regulator framework

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:   Mon, 12 Jul 2021 14:23:12 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Daniel Scally <djrscally@...il.com>
Cc:     Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        linux-kernel@...r.kernel.org, platform-driver-x86@...r.kernel.org,
        hdegoede@...hat.com, mgross@...ux.intel.com,
        luzmaximilian@...il.com, lgirdwood@...il.com,
        andy.shevchenko@...il.com, kieran.bingham@...asonboard.com
Subject: Re: [RFC PATCH 0/2] Add software node support to regulator framework

On Mon, Jul 12, 2021 at 09:13:00AM +0100, Daniel Scally wrote:
> On 11/07/2021 17:55, Laurent Pinchart wrote:

> > If technically feasible, gathering all the data in a single place would
> > be my preference. Whether that should take the form of software nodes in
> > all cases, or be modelled as custom data that the int3472 driver would
> > interpret to create the regulators and clocks is a different (but
> > related) question.

> I'll have to think on that one then; the problem there is that the
> cio2-bridge is just given ACPI HIDs for the sensors as "ok to parse
> this", and of course the INT347A that is being dealt with here should
> already be supported on most Surface platforms via the intel-skl-int3472
> stuff, so once the ov8865 edits are (posted and) accepted and that
> driver is supported my plan would be to add it into the bridge. So we'd
> need a way to exclude Go2 from that if we wanted to define all the
> software nodes parts in a single board file instead.

Why not just do what things like rt5670 do and have the driver probe
for the PMIC use DMI information to set up platform data?  That seems a
lot more straightforward.

So long as people keep building systems that don't fit the ACPI model
using ACPI, and indeed with no firmware description at all for important
bits of the system, it's just a question of which particular kind of
mess we end up with cleaning up after them.  These vendors really should
adopt a standards based approach rather than relying on these DMI hacks.

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