Re: [RFC PATCH v2 1/3] regulator: core: Add regulator_lookup_list

[Mark Brown]

On Wed, Aug 25, 2021 at 03:26:37PM +0300, Andy Shevchenko wrote:
> On Wed, Aug 25, 2021 at 2:30 PM Mark Brown <broonie@xxxxxxxxxx> wrote:

> > No, what was proposed for regulator was to duplicate all the the DT
> > binding code in the regulator framework so it parses fwnodes then have
> > an API for encoding fwnodes from C data structures at runtime.  The bit
> > where the data gets joined up with the devices isn't the problem, it's
> > the duplication and fragility introduced by encoding everything into
> > an intermediate representation that has no purpose and passing that
> > around which is the problem.

> The whole exercise with swnode is to minimize the driver intrusion and
> evolving a unified way for (some) of the device properties. V4L2 won't

The practical implementation for regulators was to duplicate a
substantial amount of code in the core in order to give us a less type
safe and more indirect way of passing data from onen C file in the
kernel to another.  This proposal is a lot better in that it uses the
existing init_data and avoids the huge amounts of duplication, it's just
not clear from the changelog why it's doing this in a regulator specific
manner.

*Please* stop trying to force swnodes in everywhere, take on board the
feedback about why the swnode implementation is completely inappropriate
for regulators.  I don't understand why you continue to push this so
hard.  swnodes and fwnodes are a solution to a specific problem, they're
not the answer to every problem out there and having to rehash this
continually is getting in the way of actually discussing practical
workarounds for these poorly implemented ACPI platforms.

> like what you are suggesting exactly because they don't like the idea
> of spreading the board code over the drivers. In some cases it might
> even be not so straightforward and easy.

> Laurent, do I understand correctly the v4l2 expectations?

There will be some cases where swnodes make sense, for example where the
data is going to be read through the fwnode API since the binding is
firmware neutral which I think is the v4l case.  On the other hand
having a direct C representation is a very common way of implementing
DMI quirk tables, and we have things like the regulator API where
there's off the shelf platform data support and we actively don't want
to support fwnode.

Attachment: signature.asc
Description: PGP signature