The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Daniel Scally <djrscally@gmail.com>
To: Mark Brown <broonie@kernel.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: 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 23:09:09 +0100	[thread overview]
Message-ID: <bce63128-3dde-f4c6-b0cd-00818293ebc3@gmail.com> (raw)
In-Reply-To: <20210825145232.GI5186@sirena.org.uk>

Hi Mark

On 25/08/2021 15:52, Mark Brown wrote:
> 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.


Alright; and what about parsing the platform data into a struct
regulator_init_data then...at the moment that's left up to the
individual regulator drivers. In my mind that's something better left to
core, so rather than finding the right instance of struct
regulator_init_data from the regulator_lookup_list the
regulator_lookup_init_data() function would be finding the right
instance of the struct from cfg->dev->platform_data instead...what are
your thoughts on that?


  reply	other threads:[~2021-08-25 22:09 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
2021-08-25 22:09                     ` Daniel Scally [this message]
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=bce63128-3dde-f4c6-b0cd-00818293ebc3@gmail.com \
    --to=djrscally@gmail.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=broonie@kernel.org \
    --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