mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Lee Jones <lee.jones@linaro.org>
Cc: Laxman Dewangan <ldewangan@nvidia.com>,
	sameo@linux.intel.com, rob.herring@calxeda.com,
	pawel.moll@arm.com, mark.rutland@arm.com, swarren@wwwdotorg.org,
	ijc+devicetree@hellion.org.uk, rob@landley.net,
	devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mfd: core: introduce of_node_name for mfd sub devices
Date: Thu, 19 Sep 2013 12:55:01 +0100	[thread overview]
Message-ID: <20130919115501.GM21013@sirena.org.uk> (raw)
In-Reply-To: <20130919083050.GH16984@lee--X1>

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

On Thu, Sep 19, 2013 at 09:30:50AM +0100, Lee Jones wrote:

> I'm not entirely sure this is what Mark was saying. I think he was
> complaining about the existence of the sub-nodes rather than how the
> MFD Core assigns their of_node. My take is that the chip is really a
> single device which provides different bits of functionality. To break
> that functionality up and disperse the drivers into various subsystems
> is a Linuxisum. By providing each functional block with its own node
> you're describing how we do things in Linux, rather than specifying a
> single node for the AS3722 which would probably be the norm.

Yes, that's exactly what I was thinking of.

> Do the sub-nodes have their own properties? If so, it would be worth
> breaking them up as other OSes could reuse the specifics. If they do,
> then you need so put them in the binding. If they don't, then you do
> not require sub-nodes. The MFD core will ensure the sub-devices are
> probed and there is no requirement for the of_node to be assigned.

You do see some reusable IP blocks (like the regualtors on the wm831x
PMICs for example, they're repeated blocks) which can be reused but
generally they have a register base as part of the binding.  Personally
if it's just a property or two I'd probably just put them on the root
node for the device.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  parent reply	other threads:[~2013-09-19 11:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-19  8:29 Laxman Dewangan
2013-09-19  8:30 ` Lee Jones
2013-09-19  8:57   ` Laxman Dewangan
2013-09-19 11:55   ` Mark Brown [this message]
2013-09-19 12:00     ` Lee Jones
2013-09-19 12:28       ` Laxman Dewangan
2013-09-19 12:22         ` Lee Jones
2013-09-19 12:54           ` Laxman Dewangan
2013-09-23 20:46           ` Stephen Warren
2013-09-24 13:55             ` Lee Jones
2013-09-23 20:50 ` Stephen Warren

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=20130919115501.GM21013@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=ldewangan@nvidia.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=rob.herring@calxeda.com \
    --cc=rob@landley.net \
    --cc=sameo@linux.intel.com \
    --cc=swarren@wwwdotorg.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

all inboxes | Powered by JetHome®