From: Mark Rutland <mark.rutland@arm.com>
To: Fabio Estevam <festevam@gmail.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
Ashutosh singh <ashuleapyear@gmail.com>,
"kernel@pengutronix.de" <kernel@pengutronix.de>,
Ashutosh singh <ashutosh.s@phytec.in>,
"shawn.guo@linaro.org" <shawn.guo@linaro.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] ARM-i.MX6Q-dts : Added USB_OTG Support
Date: Fri, 24 Jan 2014 15:34:08 +0000 [thread overview]
Message-ID: <20140124153407.GA4758@e106331-lin.cambridge.arm.com> (raw)
In-Reply-To: <CAOMZO5B=2mYWeoj1snSMpDzxHK8H3_DKevuaA4T4bXiV=64vkg@mail.gmail.com>
On Fri, Jan 24, 2014 at 12:15:08PM +0000, Fabio Estevam wrote:
> Hi Mark,
>
> On Fri, Jan 24, 2014 at 9:50 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>
> >> +
> >> + regulators {
> >> + compatible = "simple-bus";
> >
> > This is _not_ a simple bus. It doesn't have the required ranges
> > property.
> >
> > Why do these need to be in a regulators container node? We don't group
> > dma controllers under a dmas node, or uarts under a uarts node.
>
> It seems we have this same issue on several imx6 dts files.
>
> Would the below address your suggestion?
The below patch looks good to me.
In general there seems to be a misunderstanding of the purpose of
simple-bus, as an annotation that children of a node should be probed,
rather than as a representation of a simple bus (which is of the same
type as the parent-bus, which requires no programming, where children
can be used without knowledge of the simple-bus).
There seem to be a lot of cases where simple-bus is used as a fallback
compatible string, when in reality the node's children make no sense
without information from and/or programming of the node with the
simple-bus property. Those cases are completely wrong, and a complete
abuse of simple-bus.
There are other cases where simple-bus nodes are used to group nodes
from a commonly reused block. As long as these have the requisite
ranges, #address-cells, and #size-cells, then they are valid, and make
sense for translating / widening addresses for common groups of
peripherals even if they're not on a different physical bus.
I don't see the point in grouping together nodes in an artificial
container because of their functionality rather than their topology, it
seems to breed confusion.
Cheers,
Mark.
>
> diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-
> index e75e11b..ba35560 100644
> --- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> @@ -15,33 +15,29 @@
> reg = <0x10000000 0x40000000>;
> };
>
> - regulators {
> - compatible = "simple-bus";
> -
> - reg_usb_otg_vbus: usb_otg_vbus {
> - compatible = "regulator-fixed";
> - regulator-name = "usb_otg_vbus";
> - regulator-min-microvolt = <5000000>;
> - regulator-max-microvolt = <5000000>;
> - gpio = <&gpio3 22 0>;
> - enable-active-high;
> - };
> + reg_usb_otg_vbus: regulator@0 {
> + compatible = "regulator-fixed";
> + regulator-name = "usb_otg_vbus";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + gpio = <&gpio3 22 0>;
> + enable-active-high;
> + };
>
> - reg_usb_h1_vbus: usb_h1_vbus {
> - compatible = "regulator-fixed";
> - regulator-name = "usb_h1_vbus";
> - regulator-min-microvolt = <5000000>;
> - regulator-max-microvolt = <5000000>;
> - gpio = <&gpio1 29 0>;
> - enable-active-high;
> - };
> + reg_usb_h1_vbus: regulator@1 {
> + compatible = "regulator-fixed";
> + regulator-name = "usb_h1_vbus";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + gpio = <&gpio1 29 0>;
> + enable-active-high;
> + };
>
> - reg_audio: wm8962_supply {
> - compatible = "regulator-fixed";
> - regulator-name = "wm8962-supply";
> - gpio = <&gpio4 10 0>;
> - enable-active-high;
> - };
> + reg_audio: regulator@2 {
> + compatible = "regulator-fixed";
> + regulator-name = "wm8962-supply";
> + gpio = <&gpio4 10 0>;
> + enable-active-high;
> };
>
> gpio-keys {
>
> If so, I will prepare some patches to update other dts files.
>
> Thanks,
>
> Fabio Estevam
>
next prev parent reply other threads:[~2014-01-24 15:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-24 9:28 [PATCH] ARM-i.MX6Q-dts : Added USB_OTG Support Ashutosh singh
[not found] ` <1390555724-9779-1-git-send-email-ashutosh.s-mS2nBM426Az/PtFMR13I2A@public.gmane.org>
2014-01-24 11:50 ` Mark Rutland
[not found] ` <20140124115005.GG814-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
2014-01-24 12:15 ` Fabio Estevam
2014-01-24 15:34 ` Mark Rutland [this message]
2014-01-24 15:32 ` Shawn Guo
2014-01-24 22:04 ` Sascha Hauer
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=20140124153407.GA4758@e106331-lin.cambridge.arm.com \
--to=mark.rutland@arm.com \
--cc=ashuleapyear@gmail.com \
--cc=ashutosh.s@phytec.in \
--cc=devicetree@vger.kernel.org \
--cc=festevam@gmail.com \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-usb@vger.kernel.org \
--cc=shawn.guo@linaro.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;
as well as URLs for NNTP newsgroup(s).