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.
next prev parent 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: linkBe 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.