linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Simon Arlott <simon@fire.lp0.eu>
Cc: devicetree@vger.kernel.org, Liam Girdwood <lgirdwood@gmail.com>,
	Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>,
	linux-kernel@vger.kernel.org,
	Florian Fainelli <f.fainelli@gmail.com>,
	Jonas Gorski <jogo@openwrt.org>
Subject: Re: [PATCH 1/2] regulator: Add brcm,bcm63xx-regulator device tree binding
Date: Thu, 3 Dec 2015 00:06:31 +0000	[thread overview]
Message-ID: <20151203000631.GM1929@sirena.org.uk> (raw)
In-Reply-To: <565F53FC.5080309@simon.arlott.org.uk>

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

On Wed, Dec 02, 2015 at 08:26:36PM +0000, Simon Arlott wrote:
> On 02/12/15 12:53, Mark Brown wrote:

> > This is the sort of thing you can pick up from the SoC compatible
> > strings.  As things stand there is zero content in this driver that
> > relates to this SoC.

> There's always going to be very little content in the driver that
> relates to this SoC, given that a single bit flip enables/disables
> power.

> All other device tree drivers allow a register address to be specified
> for the device, how is an offset in the regmap any different?

It's not that it's an offset in regmap, it's that you're trying to make
a device driver with literally *no* content that is specific to the
actual device.  If you're making a driver for a specific device like
this it should know at least something about how to control the device
from the compatible string.  If you're making a generic driver it should
not make reference to specific devices.

In general I would prefer to have a driver with a SoC specific
compatible string and the data tables in the kernel, that way we keep
the device trees stable and our ABI more robust.

> >> The mask is used as there's one bit per regulator in the register, but
> >> there's more than one way to express this in the DT:

> > I wouldn't expect to see it in the device tree at all for a device
> > specific driver.

> If there isn't an individual entry in DT for each regulator, how is it
> supposed to work? There's no #regulator-cells property.

There could be one if it would help, but we do normally manage to do
this without - look at how other regulator drivers work.

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

  reply	other threads:[~2015-12-03  0:06 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-28 21:13 [PATCH 1/2] regulator: Add regmap support to regulator-fixed device tree binding Simon Arlott
2015-11-28 21:14 ` [PATCH 2/2] regulator: fixed: Add support for regmap Simon Arlott
2015-11-30 12:10 ` [PATCH 1/2] regulator: Add regmap support to regulator-fixed device tree binding Mark Brown
2015-11-30 20:30   ` [PATCH 1/2] regulator: Add brcm,bcm63xx-regulator " Simon Arlott
2015-11-30 20:30     ` [PATCH 2/2] regulator: bcm63xx: Add BCM63xx fixed regulator device Simon Arlott
2015-11-30 20:38       ` [PATCH (v2) " Simon Arlott
2015-12-01 15:11         ` Mark Brown
2015-12-01 22:16     ` [PATCH 1/2] regulator: Add brcm,bcm63xx-regulator device tree binding Mark Brown
2015-12-02 12:45       ` Simon Arlott
2015-12-02 12:53         ` Mark Brown
2015-12-02 20:26           ` Simon Arlott
2015-12-03  0:06             ` Mark Brown [this message]
2015-12-03  8:14               ` Simon Arlott
2015-12-03 15:05                 ` Mark Brown
2015-12-03 23:38                   ` Simon Arlott
2015-12-03 23:45                     ` Mark Brown
2015-12-03 23:51                       ` Simon Arlott
2015-12-04 11:00                         ` Mark Brown
2015-12-04 12:26                           ` Simon Arlott
2015-12-04 14:31                             ` 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=20151203000631.GM1929@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=jogo@openwrt.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=simon@fire.lp0.eu \
    /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).