From: Tony Lindgren <tony@atomide.com> To: Rob Herring <robherring2@gmail.com> Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>, Kevin Hilman <khilman@kernel.org>, Grant Likely <grant.likely@linaro.org>, Bjorn Helgaas <bhelgaas@google.com>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, Pantelis Antoniou <pantelis.antoniou@konsulko.com>, Wolfram Sang <wsa@the-dreams.de>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Tyler Baker <tyler.baker@linaro.org>, Olof Johansson <olof@lixom.net> Subject: Re: [PATCH 2/2] drivercore: Fix unregistration path of platform devices Date: Tue, 16 Jun 2015 00:58:10 -0700 [thread overview] Message-ID: <20150616075809.GD2740@atomide.com> (raw) In-Reply-To: <CAL_Jsq+RyuiYszWSGF-XSL_fqKNWpR0VjFkJMdnW2QuaKNT-AA@mail.gmail.com> * Rob Herring <robherring2@gmail.com> [150610 07:06]: > > I've looked at some of the failures. Armada 370 looks normal AFAICT, > but the network device evidently does not probe. i.MX6 has no log, but > IIRC it is what failed previously on Grant's last attempt. For OMAP4, > I found the overlapping region here: > > omap4_padconf_core: scm@100000 { > compatible = "ti,omap4-scm-padconf-core", > "simple-bus"; > #address-cells = <1>; > #size-cells = <1>; > ranges = <0 0x100000 0x1000>; > > omap4_pmx_core: pinmux@40 { > compatible = "ti,omap4-padconf", > "pinctrl-single"; > reg = <0x40 0x0196>; > #address-cells = <1>; > #size-cells = <0>; > #interrupt-cells = <1>; > interrupt-controller; > pinctrl-single,register-width = <16>; > pinctrl-single,function-mask = <0x7fff>; > }; > > omap4_padconf_global: omap4_padconf_global@5a0 { > compatible = "syscon"; > reg = <0x5a0 0x170>; > #address-cells = <1>; > #size-cells = <1>; > > pbias_regulator: pbias_regulator { > compatible = "ti,pbias-omap"; > reg = <0x60 0x4>; > > 0x60 is within the pinmux range of 0x40-0x1d6. > > But why is the regulator a sub node here instead of omap4_pmx_core? I don't think the reg entry is in use here as the pbias_regulator uses syscon_regmap_lookup_by_phandle via syscon. > syscon = > <&omap4_padconf_global>; > > This seems to indicate that 0x60 is supposed to be an offset from > 0x5a0. That would require a ranges property in the parent. Is this an > error? Yeah we should add ranges to padconf_global so drivers not using syscon can just do of_ioremap for a dedicated range of registers within the padconf_global. That area has things like PHYs, regulators and clocks. Regards, Tony
WARNING: multiple messages have this Message-ID (diff)
From: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> To: Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Cc: Ricardo Ribalda Delgado <ricardo.ribalda-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Kevin Hilman <khilman-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>, Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>, Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>, Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>, Tyler Baker <tyler.baker-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>, Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org> Subject: Re: [PATCH 2/2] drivercore: Fix unregistration path of platform devices Date: Tue, 16 Jun 2015 00:58:10 -0700 [thread overview] Message-ID: <20150616075809.GD2740@atomide.com> (raw) In-Reply-To: <CAL_Jsq+RyuiYszWSGF-XSL_fqKNWpR0VjFkJMdnW2QuaKNT-AA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> * Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [150610 07:06]: > > I've looked at some of the failures. Armada 370 looks normal AFAICT, > but the network device evidently does not probe. i.MX6 has no log, but > IIRC it is what failed previously on Grant's last attempt. For OMAP4, > I found the overlapping region here: > > omap4_padconf_core: scm@100000 { > compatible = "ti,omap4-scm-padconf-core", > "simple-bus"; > #address-cells = <1>; > #size-cells = <1>; > ranges = <0 0x100000 0x1000>; > > omap4_pmx_core: pinmux@40 { > compatible = "ti,omap4-padconf", > "pinctrl-single"; > reg = <0x40 0x0196>; > #address-cells = <1>; > #size-cells = <0>; > #interrupt-cells = <1>; > interrupt-controller; > pinctrl-single,register-width = <16>; > pinctrl-single,function-mask = <0x7fff>; > }; > > omap4_padconf_global: omap4_padconf_global@5a0 { > compatible = "syscon"; > reg = <0x5a0 0x170>; > #address-cells = <1>; > #size-cells = <1>; > > pbias_regulator: pbias_regulator { > compatible = "ti,pbias-omap"; > reg = <0x60 0x4>; > > 0x60 is within the pinmux range of 0x40-0x1d6. > > But why is the regulator a sub node here instead of omap4_pmx_core? I don't think the reg entry is in use here as the pbias_regulator uses syscon_regmap_lookup_by_phandle via syscon. > syscon = > <&omap4_padconf_global>; > > This seems to indicate that 0x60 is supposed to be an offset from > 0x5a0. That would require a ranges property in the parent. Is this an > error? Yeah we should add ranges to padconf_global so drivers not using syscon can just do of_ioremap for a dedicated range of registers within the padconf_global. That area has things like PHYs, regulators and clocks. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-06-16 7:58 UTC|newest] Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-06-07 14:20 [PATCH 0/2] Fix oops in platform_device resource unregister Grant Likely 2015-06-07 14:20 ` [PATCH 1/2] of/unittest: Show broken behaviour in the platform bus Grant Likely 2015-06-07 14:20 ` Grant Likely 2015-06-08 20:16 ` Rob Herring 2015-06-09 11:05 ` Grant Likely 2015-06-15 16:45 ` Wolfram Sang 2015-06-15 16:45 ` Wolfram Sang 2015-06-07 14:20 ` [PATCH 2/2] drivercore: Fix unregistration path of platform devices Grant Likely 2015-06-07 14:20 ` Grant Likely 2015-06-07 18:13 ` Ricardo Ribalda Delgado 2015-06-08 8:14 ` Pantelis Antoniou 2015-06-08 8:14 ` Pantelis Antoniou 2015-06-08 8:42 ` Ricardo Ribalda Delgado 2015-06-08 18:47 ` Grant Likely 2015-06-08 18:47 ` Grant Likely 2015-06-08 20:09 ` Ricardo Ribalda Delgado 2015-06-08 20:09 ` Ricardo Ribalda Delgado 2015-06-08 20:47 ` Ricardo Ribalda Delgado 2015-06-08 20:47 ` Ricardo Ribalda Delgado 2015-06-09 11:00 ` Grant Likely 2015-06-09 11:00 ` Grant Likely 2015-06-10 0:22 ` Kevin Hilman 2015-06-10 0:22 ` Kevin Hilman 2015-06-10 7:11 ` Ricardo Ribalda Delgado 2015-06-10 14:03 ` Rob Herring 2015-06-16 7:58 ` Tony Lindgren [this message] 2015-06-16 7:58 ` Tony Lindgren 2015-06-10 14:38 ` Kevin Hilman 2015-06-10 14:46 ` Ricardo Ribalda Delgado 2015-06-10 14:46 ` Ricardo Ribalda Delgado 2015-06-10 15:34 ` Greg Kroah-Hartman 2015-06-10 15:40 ` Greg Kroah-Hartman 2015-06-10 17:11 ` Grant Likely 2015-06-10 17:12 ` Pantelis Antoniou 2015-06-10 17:12 ` Pantelis Antoniou 2015-06-10 23:38 ` Wolfram Sang 2015-06-10 23:38 ` Wolfram Sang 2015-06-12 14:00 ` Ricardo Ribalda Delgado 2015-06-12 14:00 ` Ricardo Ribalda Delgado 2015-06-15 16:46 ` Wolfram Sang 2015-06-15 16:46 ` Wolfram Sang 2015-06-23 17:12 ` Ricardo Ribalda Delgado 2015-06-23 17:12 ` Ricardo Ribalda Delgado 2015-07-16 20:33 ` Ricardo Ribalda Delgado 2015-08-22 12:57 ` Ricardo Ribalda Delgado 2015-08-22 12:57 ` Ricardo Ribalda Delgado 2015-08-23 21:52 ` Rob Herring 2015-08-23 21:52 ` Rob Herring 2015-08-23 21:58 ` Ricardo Ribalda Delgado
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=20150616075809.GD2740@atomide.com \ --to=tony@atomide.com \ --cc=bhelgaas@google.com \ --cc=devicetree@vger.kernel.org \ --cc=grant.likely@linaro.org \ --cc=gregkh@linuxfoundation.org \ --cc=khilman@kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=olof@lixom.net \ --cc=pantelis.antoniou@konsulko.com \ --cc=ricardo.ribalda@gmail.com \ --cc=robherring2@gmail.com \ --cc=tyler.baker@linaro.org \ --cc=wsa@the-dreams.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.