All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Hsin-Yi Wang <hsinyi@chromium.org>
Cc: Wolfram Sang <wsa@kernel.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	linux-i2c@vger.kernel.org,
	Matthias Brugger <matthias.bgg@gmail.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org,
	Bibby Hsieh <bibby.hsieh@mediatek.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH v16 2/2] i2c: core: support bus regulator controlling in adapter
Date: Mon, 8 Mar 2021 17:16:44 +0000	[thread overview]
Message-ID: <20210308171644.GE4656@sirena.org.uk> (raw)
In-Reply-To: <20210308043607.957156-3-hsinyi@chromium.org>

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

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.

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

WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org>
To: Hsin-Yi Wang <hsinyi@chromium.org>
Cc: Wolfram Sang <wsa@kernel.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	linux-i2c@vger.kernel.org,
	Matthias Brugger <matthias.bgg@gmail.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org,
	Bibby Hsieh <bibby.hsieh@mediatek.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH v16 2/2] i2c: core: support bus regulator controlling in adapter
Date: Mon, 8 Mar 2021 17:16:44 +0000	[thread overview]
Message-ID: <20210308171644.GE4656@sirena.org.uk> (raw)
In-Reply-To: <20210308043607.957156-3-hsinyi@chromium.org>


[-- Attachment #1.1: Type: text/plain, Size: 982 bytes --]

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.

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

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org>
To: Hsin-Yi Wang <hsinyi@chromium.org>
Cc: Wolfram Sang <wsa@kernel.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	linux-i2c@vger.kernel.org,
	Matthias Brugger <matthias.bgg@gmail.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org,
	Bibby Hsieh <bibby.hsieh@mediatek.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH v16 2/2] i2c: core: support bus regulator controlling in adapter
Date: Mon, 8 Mar 2021 17:16:44 +0000	[thread overview]
Message-ID: <20210308171644.GE4656@sirena.org.uk> (raw)
In-Reply-To: <20210308043607.957156-3-hsinyi@chromium.org>


[-- Attachment #1.1: Type: text/plain, Size: 982 bytes --]

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.

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

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-03-08 17:18 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-08  4:36 [PATCH v16 0/2] add power control in i2c Hsin-Yi Wang
2021-03-08  4:36 ` Hsin-Yi Wang
2021-03-08  4:36 ` Hsin-Yi Wang
2021-03-08  4:36 ` [PATCH v16 1/2] dt-binding: i2c: add bus-supply property Hsin-Yi Wang
2021-03-08  4:36   ` Hsin-Yi Wang
2021-03-08  4:36   ` Hsin-Yi Wang
2021-03-08  4:36 ` [PATCH v16 2/2] i2c: core: support bus regulator controlling in adapter Hsin-Yi Wang
2021-03-08  4:36   ` Hsin-Yi Wang
2021-03-08  4:36   ` Hsin-Yi Wang
2021-03-08 17:16   ` Mark Brown [this message]
2021-03-08 17:16     ` Mark Brown
2021-03-08 17:16     ` Mark Brown
2021-03-09 13:34     ` Hsin-Yi Wang
2021-03-09 13:34       ` Hsin-Yi Wang
2021-03-09 13:34       ` Hsin-Yi Wang
2021-04-07  7:30       ` Hsin-Yi Wang
2021-04-07  7:30         ` Hsin-Yi Wang
2021-04-07  7:30         ` Hsin-Yi Wang

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=20210308171644.GE4656@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=bgolaszewski@baylibre.com \
    --cc=bibby.hsieh@mediatek.com \
    --cc=hsinyi@chromium.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=m.szyprowski@samsung.com \
    --cc=matthias.bgg@gmail.com \
    --cc=wsa@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.