All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Grant Likely
	<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Linux Kernel list
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Josh Cartwright <joshc-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	Courtney Cavin
	<courtney.cavin-/MT0OVThwyLZJqsBc5GL+g@public.gmane.org>,
	Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
	Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Greg Kroah-Hartman
	<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
Subject: Re: [RFC PATCH 0/3] devicetree, qcomm PMIC: fix node name conflict
Date: Tue, 06 May 2014 19:49:12 -0700	[thread overview]
Message-ID: <53699F28.4070409@gmail.com> (raw)
In-Reply-To: <CAL_JsqL6+i_ED+s6kODsadszefaZUcA7VHCfZ4k4yj62iXsarQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On 5/6/2014 6:32 PM, Rob Herring wrote:
> On Tue, May 6, 2014 at 7:48 PM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> An issue with the path of SPMI nodes under /sys/bus/... was reported in
>> https://lkml.org/lkml/2014/4/23/312.  The symptom is that two different

< snip >

>>
> 
> I think the primary question to ask is there any added benefit to
> having the additional hierarchy of devices. I don't think there is
> much support to have more hierarchy from what I have seen of past
> discussions.

The hierarchy avoids the name space conflict.

It also maps the physical reality better than pretending all devices
are on the platform bus.

It follows the model that non-device tree systems use.  For example,
why should a usb device show up under /sys/bus/platform/ instead of
under /sys/bus/usb/ ?  (I'm not positive this actually happens, but
let me pretend it would.)

> Another approach could be to support having multiple platform bus
> instances. Then drivers can easily create a new instance for each set
> of sub-devices.
> 
> This can be solved in a much less invasive way just in the DT naming
> algorithm. This is slightly different from what I had suggested of
> just dropping the unit address. It keeps the unit address, but adds
> the unique index on untranslate-able addresses. The diff is bigger due
> to refactoring to reduce the indentation levels. It is untested and
> whitespace corrupted:
> 
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index 404d1da..c77dd7a 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -105,23 +105,33 @@ void of_device_make_bus_id(struct device *dev)
>          * For MMIO, get the physical address
>          */
>         reg = of_get_property(node, "reg", NULL);
> -       if (reg) {
> -               if (of_can_translate_address(node)) {
> -                       addr = of_translate_address(node, reg);
> -               } else {
> -                       addrp = of_get_address(node, 0, NULL, NULL);
> -                       if (addrp)
> -                               addr = of_read_number(addrp, 1);
> -                       else
> -                               addr = OF_BAD_ADDR;
> -               }
> -               if (addr != OF_BAD_ADDR) {
> -                       dev_set_name(dev, "%llx.%s",
> -                                    (unsigned long long)addr, node->name);
> -                       return;
> -               }
> +       if (!reg)
> +               goto no_bus_id;
> +
> +       if (of_can_translate_address(node)) {
> +               addr = of_translate_address(node, reg);
> +               if (addr == OF_BAD_ADDR)
> +                       goto no_bus_id;
> +
> +               dev_set_name(dev, "%llx.%s",
> +                            (unsigned long long)addr, node->name);
> +               return;
>         }
> 
> +       addrp = of_get_address(node, 0, NULL, NULL);
> +       if (!addrp)
> +               goto no_bus_id;
> +
> +       addr = of_read_number(addrp, 1);
> +       if (addr == OF_BAD_ADDR)
> +               goto no_bus_id;
> +
> +       magic = atomic_add_return(1, &bus_no_reg_magic);
> +       dev_set_name(dev, "%llx.%s.%d", (unsigned long long)addr,
> +                    node->name, magic - 1);
> +       return;
> +
> +no_bus_id:
>         /*
>          * No BusID, use the node name and add a globally incremented
>          * counter (and pray...)
> 

I think the refactored code is easier to read.  (End of bike shed...)

The result of that patch is an even uglier set of device names.  I would love to get rid of
the bus_no_reg_magic instead of making more extensive use of it.  The new names for the
system that started this discussion are:

$ ls /sys/devices/soc.2/fc4cf000.qcom,spmi/spmi-0/0-00/
100.qcom,revid.19            gpios.21
3100.qcom,pm8x41-adc-usr.20  power
6000.qcom,rtc.18             subsystem
driver                       uevent

$ ls /sys/bus/platform/devices/soc.2/fc4cf000.qcom,spmi/spmi-0/0-00/
100.qcom,revid.19            gpios.21
3100.qcom,pm8x41-adc-usr.20  power
6000.qcom,rtc.18             subsystem
driver                       uevent

$ ls /sys/bus/platform/devices/soc.2/fc4cf000.qcom,spmi/spmi-0/0-01/
b040.pm8xxx-pwm.22      driver                  uevent
d000.pm8xxx-pwm-led.23  power
d800.pm8xxx-wled.24     subsystem

$ ls /sys/bus/platform/devices/soc.2/fc4cf000.qcom,spmi/spmi-0/0-04/
100.qcom,revid.25  power              uevent
driver             subsystem

$ ls /sys/bus/platform/devices/
100.qcom,revid.19              fc4ab000.restart
100.qcom,revid.25              fc4cf000.qcom,spmi
3100.qcom,pm8x41-adc-usr.20    fd484000.hwlock
6000.qcom,rtc.18               fd510000.pinctrl
alarmtimer                     fd8c0000.clock-controller
b040.pm8xxx-pwm.22             gpio_keys.5
cpu-pmu.1                      gpios.21
cpus.0                         iio-thermal.4
d000.pm8xxx-pwm-led.23         pm8841-s1.6
d800.pm8xxx-wled.24            pm8841-s2.7
f9000000.interrupt-controller  pm8941-l3.11
f9011000.smem                  pm8941-l6.12
f9012000.regulator             reg-dummy
f9020000.timer                 regulator-l11.14
f9088000.clock-controller      regulator-l19.15
f9098000.clock-controller      regulator-l20.16
f90a8000.clock-controller      regulator-l22.17
f90b8000.clock-controller      regulator-l9.13
f9824900.sdhc                  regulator-s1.8
f991e000.serial                regulator-s2.9
f9924000.i2c2                  regulator-s3.10
f9928000.i2c6                  regulatory.0
f9bff000.rng                   snd-soc-dummy
fc400000.clock-controller      soc.2
fc4281d0.qcom,mpm              timer.3

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

WARNING: multiple messages have this Message-ID (diff)
From: Frank Rowand <frowand.list@gmail.com>
To: Rob Herring <robherring2@gmail.com>
Cc: Grant Likely <grant.likely@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	Josh Cartwright <joshc@codeaurora.org>,
	Courtney Cavin <courtney.cavin@sonymobile.com>,
	Samuel Ortiz <sameo@linux.intel.com>,
	Lee Jones <lee.jones@linaro.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [RFC PATCH 0/3] devicetree, qcomm PMIC: fix node name conflict
Date: Tue, 06 May 2014 19:49:12 -0700	[thread overview]
Message-ID: <53699F28.4070409@gmail.com> (raw)
In-Reply-To: <CAL_JsqL6+i_ED+s6kODsadszefaZUcA7VHCfZ4k4yj62iXsarQ@mail.gmail.com>

On 5/6/2014 6:32 PM, Rob Herring wrote:
> On Tue, May 6, 2014 at 7:48 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>> An issue with the path of SPMI nodes under /sys/bus/... was reported in
>> https://lkml.org/lkml/2014/4/23/312.  The symptom is that two different

< snip >

>>
> 
> I think the primary question to ask is there any added benefit to
> having the additional hierarchy of devices. I don't think there is
> much support to have more hierarchy from what I have seen of past
> discussions.

The hierarchy avoids the name space conflict.

It also maps the physical reality better than pretending all devices
are on the platform bus.

It follows the model that non-device tree systems use.  For example,
why should a usb device show up under /sys/bus/platform/ instead of
under /sys/bus/usb/ ?  (I'm not positive this actually happens, but
let me pretend it would.)

> Another approach could be to support having multiple platform bus
> instances. Then drivers can easily create a new instance for each set
> of sub-devices.
> 
> This can be solved in a much less invasive way just in the DT naming
> algorithm. This is slightly different from what I had suggested of
> just dropping the unit address. It keeps the unit address, but adds
> the unique index on untranslate-able addresses. The diff is bigger due
> to refactoring to reduce the indentation levels. It is untested and
> whitespace corrupted:
> 
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index 404d1da..c77dd7a 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -105,23 +105,33 @@ void of_device_make_bus_id(struct device *dev)
>          * For MMIO, get the physical address
>          */
>         reg = of_get_property(node, "reg", NULL);
> -       if (reg) {
> -               if (of_can_translate_address(node)) {
> -                       addr = of_translate_address(node, reg);
> -               } else {
> -                       addrp = of_get_address(node, 0, NULL, NULL);
> -                       if (addrp)
> -                               addr = of_read_number(addrp, 1);
> -                       else
> -                               addr = OF_BAD_ADDR;
> -               }
> -               if (addr != OF_BAD_ADDR) {
> -                       dev_set_name(dev, "%llx.%s",
> -                                    (unsigned long long)addr, node->name);
> -                       return;
> -               }
> +       if (!reg)
> +               goto no_bus_id;
> +
> +       if (of_can_translate_address(node)) {
> +               addr = of_translate_address(node, reg);
> +               if (addr == OF_BAD_ADDR)
> +                       goto no_bus_id;
> +
> +               dev_set_name(dev, "%llx.%s",
> +                            (unsigned long long)addr, node->name);
> +               return;
>         }
> 
> +       addrp = of_get_address(node, 0, NULL, NULL);
> +       if (!addrp)
> +               goto no_bus_id;
> +
> +       addr = of_read_number(addrp, 1);
> +       if (addr == OF_BAD_ADDR)
> +               goto no_bus_id;
> +
> +       magic = atomic_add_return(1, &bus_no_reg_magic);
> +       dev_set_name(dev, "%llx.%s.%d", (unsigned long long)addr,
> +                    node->name, magic - 1);
> +       return;
> +
> +no_bus_id:
>         /*
>          * No BusID, use the node name and add a globally incremented
>          * counter (and pray...)
> 

I think the refactored code is easier to read.  (End of bike shed...)

The result of that patch is an even uglier set of device names.  I would love to get rid of
the bus_no_reg_magic instead of making more extensive use of it.  The new names for the
system that started this discussion are:

$ ls /sys/devices/soc.2/fc4cf000.qcom,spmi/spmi-0/0-00/
100.qcom,revid.19            gpios.21
3100.qcom,pm8x41-adc-usr.20  power
6000.qcom,rtc.18             subsystem
driver                       uevent

$ ls /sys/bus/platform/devices/soc.2/fc4cf000.qcom,spmi/spmi-0/0-00/
100.qcom,revid.19            gpios.21
3100.qcom,pm8x41-adc-usr.20  power
6000.qcom,rtc.18             subsystem
driver                       uevent

$ ls /sys/bus/platform/devices/soc.2/fc4cf000.qcom,spmi/spmi-0/0-01/
b040.pm8xxx-pwm.22      driver                  uevent
d000.pm8xxx-pwm-led.23  power
d800.pm8xxx-wled.24     subsystem

$ ls /sys/bus/platform/devices/soc.2/fc4cf000.qcom,spmi/spmi-0/0-04/
100.qcom,revid.25  power              uevent
driver             subsystem

$ ls /sys/bus/platform/devices/
100.qcom,revid.19              fc4ab000.restart
100.qcom,revid.25              fc4cf000.qcom,spmi
3100.qcom,pm8x41-adc-usr.20    fd484000.hwlock
6000.qcom,rtc.18               fd510000.pinctrl
alarmtimer                     fd8c0000.clock-controller
b040.pm8xxx-pwm.22             gpio_keys.5
cpu-pmu.1                      gpios.21
cpus.0                         iio-thermal.4
d000.pm8xxx-pwm-led.23         pm8841-s1.6
d800.pm8xxx-wled.24            pm8841-s2.7
f9000000.interrupt-controller  pm8941-l3.11
f9011000.smem                  pm8941-l6.12
f9012000.regulator             reg-dummy
f9020000.timer                 regulator-l11.14
f9088000.clock-controller      regulator-l19.15
f9098000.clock-controller      regulator-l20.16
f90a8000.clock-controller      regulator-l22.17
f90b8000.clock-controller      regulator-l9.13
f9824900.sdhc                  regulator-s1.8
f991e000.serial                regulator-s2.9
f9924000.i2c2                  regulator-s3.10
f9928000.i2c6                  regulatory.0
f9bff000.rng                   snd-soc-dummy
fc400000.clock-controller      soc.2
fc4281d0.qcom,mpm              timer.3


  parent reply	other threads:[~2014-05-07  2:49 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-07  0:48 [RFC PATCH 0/3] devicetree, qcomm PMIC: fix node name conflict Frank Rowand
2014-05-07  0:48 ` Frank Rowand
2014-05-07  0:52 ` [RFC PATCH 2/3] devicetree: provide hook to allow setting devicetree device name Frank Rowand
     [not found]   ` <536983D0.8090307-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-05-07 15:21     ` Grant Likely
2014-05-07 15:21       ` Grant Likely
2014-05-07  0:53 ` [RFC PATCH 3/3] devicetree, qcomm PMIC: use new hook to make PMIC device names unique Frank Rowand
     [not found] ` <536982E3.10303-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-05-07  0:51   ` [RFC PATCH 1/3] devicetree: set bus type same as parent Frank Rowand
2014-05-07  0:51     ` Frank Rowand
     [not found]     ` <53698380.1060006-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-05-07 15:17       ` Grant Likely
2014-05-07 15:17         ` Grant Likely
2014-05-07  1:32   ` [RFC PATCH 0/3] devicetree, qcomm PMIC: fix node name conflict Rob Herring
2014-05-07  1:32     ` Rob Herring
     [not found]     ` <CAL_JsqL6+i_ED+s6kODsadszefaZUcA7VHCfZ4k4yj62iXsarQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-07  2:49       ` Frank Rowand [this message]
2014-05-07  2:49         ` Frank Rowand
2014-05-07 14:51     ` Grant Likely
2014-05-07 15:12     ` Bjorn Andersson
     [not found]       ` <CAJAp7OiyjefyPMu2p8jTkbfQWYUKeYV62pVTtJ2JOP-6YOOGKA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-07 16:08         ` Rob Herring
2014-05-07 16:08           ` Rob Herring

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=53699F28.4070409@gmail.com \
    --to=frowand.list-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=courtney.cavin-/MT0OVThwyLZJqsBc5GL+g@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
    --cc=joshc-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.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 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.