[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210308171644.GE4656@sirena.org.uk>
Date: Mon, 8 Mar 2021 17:16:44 +0000
From: Mark Brown <broonie@...nel.org>
To: Hsin-Yi Wang <hsinyi@...omium.org>
Cc: Wolfram Sang <wsa@...nel.org>,
Bartosz Golaszewski <bgolaszewski@...libre.com>,
linux-i2c@...r.kernel.org,
Matthias Brugger <matthias.bgg@...il.com>,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org,
Bibby Hsieh <bibby.hsieh@...iatek.com>,
Marek Szyprowski <m.szyprowski@...sung.com>
Subject: Re: [PATCH v16 2/2] i2c: core: support bus regulator controlling in
adapter
On Mon, Mar 08, 2021 at 12:36:07PM +0800, Hsin-Yi Wang wrote:
> + adap->bus_regulator = devm_regulator_get(&adap->dev, "bus");
> + if (IS_ERR(adap->bus_regulator)) {
> + res = PTR_ERR(adap->bus_regulator);
> + goto out_reg;
> + }
Idiomatically supplies should be named as they are by the chip datasheet
rather than just a generic name like this, and I'm guessing that systems
that have supplies like this will often already have something
requesting the supply (eg, it's quite common for consumer drivers to do
this) under that name. I can see this being a useful thing to factor
out into the core but it seems like it'd be better to have it enabled by
having the controllers (or devices) pass a supply name (or possibly
requested regulator) to the core rather than by just hard coding a name
in the core so bindings look as expected.
I do also wonder if it's better to put the feature on the clients rather
than the controller, I don't think it makes much difference though.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists