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

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1513 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]