platform-driver-x86.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Daniel Scally <djrscally@gmail.com>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Platform Driver <platform-driver-x86@vger.kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Hans de Goede <hdegoede@redhat.com>,
	Mark Gross <mgross@linux.intel.com>,
	Maximilian Luz <luzmaximilian@gmail.com>,
	Kieran Bingham <kieran.bingham@ideasonboard.com>,
	Sakari Ailus <sakari.ailus@iki.fi>
Subject: Re: [RFC PATCH v2 1/3] regulator: core: Add regulator_lookup_list
Date: Wed, 25 Aug 2021 15:52:32 +0100	[thread overview]
Message-ID: <20210825145232.GI5186@sirena.org.uk> (raw)
In-Reply-To: <YSZSOZXxSac307/A@pendragon.ideasonboard.com>

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

On Wed, Aug 25, 2021 at 05:22:49PM +0300, Laurent Pinchart wrote:

> a very large number of regulators, it may not be too bad in practice. If
> I were to maintain the regulator subsystem I'd probably want a
> centralized implementation there, but that's certainly a personal
> preference, at least partly.

We already have some generic platform data for regulators so if it
doesn't want to define anything custom all a driver has to do is forward
that struct on to the core for handling, otherwise it just has to pick
the generic struct out of whatever custom thing it defines.

> On a side note, this RFC looks quite similar to what the GPIO subsystem
> does, which I personally consider nice as differences between regulator
> and GPIO in these areas are confusing for users.

My pushback here is that if all we're doing is providing a mechanism to
match platform data with firmware provided devices we shouldn't be
implementing it per API in the first place, we should have a generic
mechanism for system level quirking to pass platform data to devices
which works with anything - it could also absorb a lot of the DMI based
quirking we have in drivers already which boil down to using a DMI match
to pick some platform data.

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

  reply	other threads:[~2021-08-25 14:53 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-24 23:06 [RFC PATCH v2 0/3] Add regulator_lookup_list and API Daniel Scally
2021-08-24 23:06 ` [RFC PATCH v2 1/3] regulator: core: Add regulator_lookup_list Daniel Scally
2021-08-25 10:33   ` Mark Brown
2021-08-25 11:10     ` Andy Shevchenko
2021-08-25 11:30       ` Mark Brown
2021-08-25 12:26         ` Andy Shevchenko
2021-08-25 13:11           ` Mark Brown
2021-08-25 13:59             ` Laurent Pinchart
2021-08-25 14:03               ` Laurent Pinchart
2021-08-25 14:33                 ` Andy Shevchenko
2021-08-25 14:12               ` Daniel Scally
2021-08-25 14:22                 ` Laurent Pinchart
2021-08-25 14:52                   ` Mark Brown [this message]
2021-08-25 22:09                     ` Daniel Scally
2021-08-26 12:40                       ` Mark Brown
2021-08-25 14:41               ` Mark Brown
2021-08-25 14:48     ` Hans de Goede
2021-08-25 15:27       ` Mark Brown
2021-08-25 15:42         ` Laurent Pinchart
2021-08-25 16:13           ` Mark Brown
2021-08-25 20:25           ` Hans de Goede
2021-08-25 20:40             ` Laurent Pinchart
2021-08-25 21:24               ` Daniel Scally
2021-08-25 21:17       ` Daniel Scally
2021-08-24 23:06 ` [RFC PATCH v2 2/3] Documentation: power: Document regulator_lookup_list Daniel Scally
2021-08-24 23:06 ` [RFC PATCH v2 3/3] platform/surface: Add Surface Go 2 board file Daniel Scally

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210825145232.GI5186@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=andy.shevchenko@gmail.com \
    --cc=djrscally@gmail.com \
    --cc=hdegoede@redhat.com \
    --cc=kieran.bingham@ideasonboard.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luzmaximilian@gmail.com \
    --cc=mgross@linux.intel.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=sakari.ailus@iki.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).