All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Shawn Guo <shawn.guo@freescale.com>
Cc: "Samuel Ortiz" <sameo@linux.intel.com>,
	devicetree-discuss@lists.ozlabs.org, "Liam Girdwood" <lrg@ti.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Shawn Guo" <shawn.guo@linaro.org>,
	"Sascha Hauer" <s.hauer@pengutronix.de>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 1/3] mfd: mc13xxx: add device tree probe support
Date: Wed, 21 Dec 2011 01:37:03 +0000	[thread overview]
Message-ID: <20111221013702.GB15398@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20111221012519.GA5983@S2101-09.ap.freescale.net>

On Wed, Dec 21, 2011 at 09:25:21AM +0800, Shawn Guo wrote:
> On Tue, Dec 20, 2011 at 11:25:27PM +0000, Mark Brown wrote:

> > It's unique but I feel the disadvantages in terms of legibility of the
> > resulting device trees are substantial - we want humans to be able to
> > read and write device trees, preferrably without having to dig out the
> > datasheet for the part.

> Eh, device tree is all about describing hardware.  I do not understand
> what is wrong with looking at hardware manual when writing dts.

For the same reason we define constants for register names and values
when writing drivers - so humans can make sense of what's in front of
them and to reduce the chance of errors when things are being written.

> > So long as the names are reasonably sensible
> > and can be understood in the case of any lack of clarity we should be
> > OK.

> The problem is even if we have the name defined that way, it has to be
> matched to the name used in mc13892 driver somehow, if we want to use
> name as the key to find the regulator defined in mc13892 driver as
> array mc13892_regulators[].

This doesn't seem like a problem - the most obvious thing would just be
to adjust the strings in the code to correspond to what the device tree
binding says.

> > This is the whole reason why I'm saying that you need to define the
> > names used in the binding - if the names are a defined part of the
> > binding then there's nothing driver specific about them.

> Can you please help me understand how this can be achieved with an
> example?  Taking 'mc13892__sw1' as the example, if I read your comment
> before correctly, 'sw1' is the name that you are suggesting.  How this
> name can be nothing driver specific?  After all, we need to find
> regulator MC13892_SW1 defined in mc13892_regulators[] by matching name
> 'sw1' defined by binding and name 'MC13892_SW1' defined by driver
> somehow, if we want to use name to bind the regulator.

Your binding document would say something like "the regulators are bound
using their names as listed below with their enable bits:

  sw1 - SW1 regulator (register X bit Y)

" so in the binding document it would say what strings map onto which
regulators.  Then any driver implementing that binding would pick the
same strings.

WARNING: multiple messages have this Message-ID (diff)
From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 1/3] mfd: mc13xxx: add device tree probe support
Date: Wed, 21 Dec 2011 01:37:03 +0000	[thread overview]
Message-ID: <20111221013702.GB15398@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20111221012519.GA5983@S2101-09.ap.freescale.net>

On Wed, Dec 21, 2011 at 09:25:21AM +0800, Shawn Guo wrote:
> On Tue, Dec 20, 2011 at 11:25:27PM +0000, Mark Brown wrote:

> > It's unique but I feel the disadvantages in terms of legibility of the
> > resulting device trees are substantial - we want humans to be able to
> > read and write device trees, preferrably without having to dig out the
> > datasheet for the part.

> Eh, device tree is all about describing hardware.  I do not understand
> what is wrong with looking at hardware manual when writing dts.

For the same reason we define constants for register names and values
when writing drivers - so humans can make sense of what's in front of
them and to reduce the chance of errors when things are being written.

> > So long as the names are reasonably sensible
> > and can be understood in the case of any lack of clarity we should be
> > OK.

> The problem is even if we have the name defined that way, it has to be
> matched to the name used in mc13892 driver somehow, if we want to use
> name as the key to find the regulator defined in mc13892 driver as
> array mc13892_regulators[].

This doesn't seem like a problem - the most obvious thing would just be
to adjust the strings in the code to correspond to what the device tree
binding says.

> > This is the whole reason why I'm saying that you need to define the
> > names used in the binding - if the names are a defined part of the
> > binding then there's nothing driver specific about them.

> Can you please help me understand how this can be achieved with an
> example?  Taking 'mc13892__sw1' as the example, if I read your comment
> before correctly, 'sw1' is the name that you are suggesting.  How this
> name can be nothing driver specific?  After all, we need to find
> regulator MC13892_SW1 defined in mc13892_regulators[] by matching name
> 'sw1' defined by binding and name 'MC13892_SW1' defined by driver
> somehow, if we want to use name to bind the regulator.

Your binding document would say something like "the regulators are bound
using their names as listed below with their enable bits:

  sw1 - SW1 regulator (register X bit Y)

" so in the binding document it would say what strings map onto which
regulators.  Then any driver implementing that binding would pick the
same strings.

  reply	other threads:[~2011-12-21  1:37 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-12 15:15 [PATCH v3 0/3] Add device tree support for mc13892 regulator driver Shawn Guo
2011-12-12 15:15 ` Shawn Guo
     [not found] ` <1323702958-4831-1-git-send-email-shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2011-12-12 15:15   ` [PATCH v3 1/3] mfd: mc13xxx: add device tree probe support Shawn Guo
2011-12-12 15:15     ` Shawn Guo
     [not found]     ` <1323702958-4831-2-git-send-email-shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2011-12-20  0:57       ` Mark Brown
2011-12-20  0:57         ` Mark Brown
     [not found]         ` <20111220005708.GM2860-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2011-12-20  2:01           ` Shawn Guo
2011-12-20  2:01             ` Shawn Guo
     [not found]             ` <20111220020101.GD5683-+NayF8gZjK2ctlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2011-12-20  1:59               ` Mark Brown
2011-12-20  1:59                 ` Mark Brown
     [not found]                 ` <20111220015931.GX2860-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2011-12-20  3:03                   ` Shawn Guo
2011-12-20  3:03                     ` Shawn Guo
2011-12-20 11:25                     ` Mark Brown
2011-12-20 11:25                       ` Mark Brown
     [not found]                       ` <20111220112510.GL2866-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2011-12-20 13:52                         ` Shawn Guo
2011-12-20 13:52                           ` Shawn Guo
     [not found]                           ` <20111220135251.GB5129-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2011-12-20 14:35                             ` Mark Brown
2011-12-20 14:35                               ` Mark Brown
     [not found]                               ` <20111220143558.GT2866-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2011-12-20 15:31                                 ` Shawn Guo
2011-12-20 15:31                                   ` Shawn Guo
     [not found]                                   ` <20111220153101.GD5348-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2011-12-20 23:25                                     ` Mark Brown
2011-12-20 23:25                                       ` Mark Brown
     [not found]                                       ` <20111220232526.GA6551-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2011-12-21  1:25                                         ` Shawn Guo
2011-12-21  1:25                                           ` Shawn Guo
2011-12-21  1:37                                           ` Mark Brown [this message]
2011-12-21  1:37                                             ` Mark Brown
     [not found]                                             ` <20111221013702.GB15398-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2011-12-21  2:12                                               ` Shawn Guo
2011-12-21  2:12                                                 ` Shawn Guo
2011-12-12 15:15   ` [PATCH v3 2/3] regulator: mc13892: " Shawn Guo
2011-12-12 15:15     ` Shawn Guo
     [not found]     ` <1323702958-4831-3-git-send-email-shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2011-12-19 14:07       ` Shawn Guo
2011-12-19 14:07         ` Shawn Guo
     [not found]         ` <20111219140730.GB5257-+NayF8gZjK2ctlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2011-12-20  0:54           ` Mark Brown
2011-12-20  0:54             ` Mark Brown
     [not found]             ` <20111220005414.GL2860-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2011-12-20  1:37               ` Shawn Guo
2011-12-20  1:37                 ` Shawn Guo
     [not found]                 ` <20111220013711.GC5683-+NayF8gZjK2ctlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2011-12-20  1:34                   ` Mark Brown
2011-12-20  1:34                     ` Mark Brown
     [not found]                     ` <20111220013425.GU2860-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2011-12-20  2:02                       ` Shawn Guo
2011-12-20  2:02                         ` Shawn Guo
2011-12-12 15:15   ` [PATCH v3 3/3] arm/imx: add mc13892 support into imx51-babbage.dts Shawn Guo
2011-12-12 15:15     ` Shawn Guo

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=20111221013702.GB15398@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=lrg@ti.com \
    --cc=s.hauer@pengutronix.de \
    --cc=sameo@linux.intel.com \
    --cc=shawn.guo@freescale.com \
    --cc=shawn.guo@linaro.org \
    --cc=u.kleine-koenig@pengutronix.de \
    /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.