From: Mark Brown <broonie@kernel.org>
To: Daniel Scally <djrscally@gmail.com>
Cc: linux-kernel@vger.kernel.org,
platform-driver-x86@vger.kernel.org, hdegoede@redhat.com,
mgross@linux.intel.com, luzmaximilian@gmail.com,
lgirdwood@gmail.com, andy.shevchenko@gmail.com,
laurent.pinchart@ideasonboard.com,
kieran.bingham@ideasonboard.com
Subject: Re: [RFC PATCH 0/2] Add software node support to regulator framework
Date: Mon, 12 Jul 2021 15:15:28 +0100 [thread overview]
Message-ID: <20210712141528.GE4435@sirena.org.uk> (raw)
In-Reply-To: <c95da883-581b-d1f4-4c8a-2162b8b58b64@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]
On Sat, Jul 10, 2021 at 11:48:33PM +0100, Daniel Scally wrote:
> I went with this approach because the ACPI isn't entirely lacking, it
> enumerates the TPS68470 as an i2c device for its driver to bind to
> without a problem which results in the regulator driver registering the
> regulator devices (7 of them for this chip), so I was thinking along the
> lines of repairing the problems with ACPI to give those rdevs the right
> init_data rather than sidestepping it altogether. I could register the
> platform devices for the regulator driver to bind to in a board file
> instead if that's the preferred option...usually this would involve
> using i2c_board_info I think but as ACPI will enumerate the i2c device
> for the chip independently we'd need to handle that somehow to stop them
> racing each other I guess.
Like I said elsewhere it seems a lot easier to just have the I2C driver
set platform data based on parsing DMI information like we do elsewhere.
I really don't see any benefit to introducing an additional layer of
abstraction and binding here, it just seems to be making things more
fragile.
I'm not sure what you mean by "register the platform devices for the
regualtor to bind to" - if the PMIC is an I2C device it's going to need
to be an I2C device, and if the device is enumerated by firmware we'd
need to suppress that firmware enumeration to replace it.
>
>
> I'll take a look and see if I can make it work that way.
>
>
> >> I'm posting this to see if people agree it's a good approach for tackling the
> >> problem; I may be overthinking this and there's a much easier way that I should
> > I don't think I understand what the problem you are trying to solve is
> > so it's hard to say if this is a good approach to solving it.
>
>
> Hope this is a bit clearer now?
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2021-07-12 14:16 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-08 22:42 [RFC PATCH 0/2] Add software node support to regulator framework Daniel Scally
2021-07-08 22:42 ` [RFC PATCH 1/2] regulator: Add support for software node connections Daniel Scally
2021-07-09 17:26 ` Mark Brown
2021-07-08 22:42 ` [RFC PATCH 2/2] platform/surface: Add Surface Go 2 board file Daniel Scally
2021-07-09 17:40 ` Mark Brown
2021-07-09 17:04 ` [RFC PATCH 0/2] Add software node support to regulator framework Mark Brown
2021-07-10 22:48 ` Daniel Scally
2021-07-12 14:15 ` Mark Brown [this message]
2021-07-12 16:55 ` Laurent Pinchart
2021-07-12 17:32 ` Mark Brown
2021-07-11 9:37 ` Andy Shevchenko
2021-07-12 12:42 ` Mark Brown
2021-07-12 13:01 ` Andy Shevchenko
2021-07-12 13:34 ` Mark Brown
2021-07-12 16:08 ` Andy Shevchenko
2021-07-12 17:01 ` Mark Brown
2021-07-12 23:32 ` Daniel Scally
2021-07-13 15:24 ` Mark Brown
2021-07-13 15:42 ` Laurent Pinchart
2021-07-13 16:02 ` Mark Brown
2021-07-13 16:06 ` Laurent Pinchart
2021-07-13 18:24 ` Mark Brown
2021-07-13 15:55 ` Andy Shevchenko
2021-07-13 18:18 ` Mark Brown
2021-07-13 19:46 ` Andy Shevchenko
2021-07-14 16:05 ` Mark Brown
2021-07-14 7:25 ` Laurent Pinchart
2021-07-14 16:59 ` Mark Brown
2021-07-14 17:18 ` Laurent Pinchart
2021-07-14 17:28 ` Mark Brown
2021-07-14 17:41 ` Laurent Pinchart
2021-07-14 19:18 ` Mark Brown
2021-07-14 21:53 ` Laurent Pinchart
2021-07-13 22:06 ` Daniel Scally
2021-07-10 22:28 ` Laurent Pinchart
2021-07-10 22:54 ` Daniel Scally
2021-07-11 16:55 ` Laurent Pinchart
2021-07-12 8:13 ` Daniel Scally
2021-07-12 11:50 ` Laurent Pinchart
2021-07-12 13:23 ` Mark Brown
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=20210712141528.GE4435@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 \
/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