All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: 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.