DT dtc warnings

DT dtc warnings

[Rob Herring]

Hi all,

Below is a current list of ARM boards with more than 40 dtc warnings
when building with W=1. There's a treewide patch in flight to fix some
unit-address warnings[1], so those aren't included here. The list is
grouped by maintainer. AT91, Exynos, and Allwinner continue to be at
the top of the list and have been for some time (though having
multiple boards for an SoC can cause lots of duplicated warnings).

Please help fix these. More checks are being added[2].

Rob

[1] https://patchwork.kernel.org/patch/10112725/
[2] https://www.spinics.net/lists/devicetree-compiler/msg01620.html


77 - arch/arm/boot/dts/prima2-evb.dts

50 - arch/arm/boot/dts/exynos5250-arndale.dts
50 - arch/arm/boot/dts/exynos5250-smdk5250.dts
50 - arch/arm/boot/dts/exynos5250-snow.dts
50 - arch/arm/boot/dts/exynos5250-snow-rev5.dts
50 - arch/arm/boot/dts/exynos5250-spring.dts
71 - arch/arm/boot/dts/exynos5420-arndale-octa.dts
71 - arch/arm/boot/dts/exynos5420-peach-pit.dts
71 - arch/arm/boot/dts/exynos5420-smdk5420.dts
71 - arch/arm/boot/dts/exynos5422-odroidhc1.dts
71 - arch/arm/boot/dts/exynos5422-odroidxu3.dts
71 - arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
71 - arch/arm/boot/dts/exynos5422-odroidxu4.dts
71 - arch/arm/boot/dts/exynos5800-peach-pi.dts

42 - arch/arm/boot/dts/sun5i-gr8-evb.dts
44 - arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
49 - arch/arm/boot/dts/sun7i-a20-icnova-swac.dts
50 - arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
50 - arch/arm/boot/dts/sun7i-a20-m3.dts
51 - arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
51 - arch/arm/boot/dts/sun7i-a20-mk808c.dts
51 - arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts
53 - arch/arm/boot/dts/sun7i-a20-bananapi.dts
53 - arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
53 - arch/arm/boot/dts/sun7i-a20-hummingbird.dts
53 - arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts
53 - arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts
53 - arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts
53 - arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts
54 - arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
54 - arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
55 - arch/arm/boot/dts/sun7i-a20-bananapro.dts
55 - arch/arm/boot/dts/sun7i-a20-cubietruck.dts
55 - arch/arm/boot/dts/sun7i-a20-orangepi.dts
55 - arch/arm/boot/dts/sun7i-a20-pcduino3.dts
55 - arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts
56 - arch/arm/boot/dts/sun7i-a20-orangepi-mini.dts
61 - arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
61 - arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
61 - arch/arm/boot/dts/sun7i-a20-olinuxino-micro-emmc.dts

46 - arch/arm/boot/dts/at91sam9rlek.dts
48 - arch/arm/boot/dts/at91sam9261ek.dts
50 - arch/arm/boot/dts/at91-kizbox.dts
50 - arch/arm/boot/dts/at91-qil_a9260.dts
51 - arch/arm/boot/dts/at91rm9200ek.dts
52 - arch/arm/boot/dts/at91sam9g20ek.dts
52 - arch/arm/boot/dts/at91-sam9_l9260.dts
53 - arch/arm/boot/dts/at91-foxg20.dts
53 - arch/arm/boot/dts/at91sam9260ek.dts
53 - arch/arm/boot/dts/at91sam9g20ek_2mmc.dts
54 - arch/arm/boot/dts/at91sam9263ek.dts
56 - arch/arm/boot/dts/at91sam9n12ek.dts
61 - arch/arm/boot/dts/at91-cosino_mega2560.dts
61 - arch/arm/boot/dts/at91sam9m10g45ek.dts
62 - arch/arm/boot/dts/at91-ariettag25.dts
63 - arch/arm/boot/dts/at91-ariag25.dts
64 - arch/arm/boot/dts/at91-kizboxmini.dts
64 - arch/arm/boot/dts/at91sam9g15ek.dts
65 - arch/arm/boot/dts/at91sam9g25ek.dts
66 - arch/arm/boot/dts/at91sam9g35ek.dts
69 - arch/arm/boot/dts/at91sam9x25ek.dts
70 - arch/arm/boot/dts/at91sam9x35ek.dts
74 - arch/arm/boot/dts/sama5d33ek.dts
75 - arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
75 - arch/arm/boot/dts/at91-sama5d2_xplained.dts
76 - arch/arm/boot/dts/at91-kizbox2.dts
77 - arch/arm/boot/dts/sama5d31ek.dts
80 - arch/arm/boot/dts/sama5d34ek.dts
81 - arch/arm/boot/dts/sama5d35ek.dts
84 - arch/arm/boot/dts/at91-sama5d3_xplained.dts
84 - arch/arm/boot/dts/sama5d36ek_cmp.dts
84 - arch/arm/boot/dts/sama5d36ek.dts
93 - arch/arm/boot/dts/at91-sama5d4ek.dts
93 - arch/arm/boot/dts/at91-sama5d4_xplained.dts
93 - arch/arm/boot/dts/at91-vinco.dts
94 - arch/arm/boot/dts/at91-sama5d4_ma5d4evk.dts
77 - arch/arm/boot/dts/at91-tse850-3.dts

40 - arch/arm/boot/dts/stih410-b2260.dts
43 - arch/arm/boot/dts/stih410-b2120.dts

52 - arch/arm/boot/dts/keystone-k2e-evm.dts
73 - arch/arm/boot/dts/keystone-k2l-evm.dts
97 - arch/arm/boot/dts/keystone-k2hk-evm.dts

Boards with no maintainer:
192 - arch/arm/boot/dts/atlas7-evb.dts
50 - arch/arm/boot/dts/aks-cdu.dts
50 - arch/arm/boot/dts/animeo_ip.dts
50 - arch/arm/boot/dts/ethernut5.dts
50 - arch/arm/boot/dts/evk-pro3.dts
50 - arch/arm/boot/dts/tny_a9260.dts
50 - arch/arm/boot/dts/tny_a9g20.dts
50 - arch/arm/boot/dts/usb_a9260.dts
50 - arch/arm/boot/dts/usb_a9g20.dts
50 - arch/arm/boot/dts/usb_a9g20_lpw.dts
51 - arch/arm/boot/dts/mpa1600.dts
54 - arch/arm/boot/dts/tny_a9263.dts
54 - arch/arm/boot/dts/usb_a9263.dts
60 - arch/arm/boot/dts/pm9g45.dts
75 - arch/arm/boot/dts/ste-nomadik-nhk15.dts
75 - arch/arm/boot/dts/ste-nomadik-s8815.dts
77 - arch/arm/boot/dts/atlas6-evb.dts

DT dtc warnings

[Alexandre Belloni]

Hi Rob,

On 14/12/2017 at 12:21:06 -0600, Rob Herring wrote:
> Hi all,
> 
> Below is a current list of ARM boards with more than 40 dtc warnings
> when building with W=1. There's a treewide patch in flight to fix some
> unit-address warnings[1], so those aren't included here. The list is
> grouped by maintainer. AT91, Exynos, and Allwinner continue to be at
> the top of the list and have been for some time (though having
> multiple boards for an SoC can cause lots of duplicated warnings).
> 
> Please help fix these. More checks are being added[2].
> 

For the at91 ones, IIRC, they are coming from the clock binding and we
will have to break the ABI to fix it. This is not something we wanted to
do before 4.14 but it will happen at some point.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

DT dtc warnings

[Rob Herring]

On Thu, Dec 14, 2017 at 12:36 PM, Alexandre Belloni
<alexandre.belloni@free-electrons.com> wrote:
> Hi Rob,
>
> On 14/12/2017 at 12:21:06 -0600, Rob Herring wrote:
>> Hi all,
>>
>> Below is a current list of ARM boards with more than 40 dtc warnings
>> when building with W=1. There's a treewide patch in flight to fix some
>> unit-address warnings[1], so those aren't included here. The list is
>> grouped by maintainer. AT91, Exynos, and Allwinner continue to be at
>> the top of the list and have been for some time (though having
>> multiple boards for an SoC can cause lots of duplicated warnings).
>>
>> Please help fix these. More checks are being added[2].
>>
>
> For the at91 ones, IIRC, they are coming from the clock binding and we
> will have to break the ABI to fix it. This is not something we wanted to
> do before 4.14 but it will happen at some point.

Looks like they are just missing unit-address. How does adding a
unit-address break the ABI? Though, aren't you planning to change from
a node per clock to clock controller node(s)? If so, then fixing when
doing that is fine.

Rob

DT dtc warnings

[Alexandre Belloni]

On 14/12/2017 at 13:00:07 -0600, Rob Herring wrote:
> On Thu, Dec 14, 2017 at 12:36 PM, Alexandre Belloni
> <alexandre.belloni@free-electrons.com> wrote:
> > Hi Rob,
> >
> > On 14/12/2017 at 12:21:06 -0600, Rob Herring wrote:
> >> Hi all,
> >>
> >> Below is a current list of ARM boards with more than 40 dtc warnings
> >> when building with W=1. There's a treewide patch in flight to fix some
> >> unit-address warnings[1], so those aren't included here. The list is
> >> grouped by maintainer. AT91, Exynos, and Allwinner continue to be at
> >> the top of the list and have been for some time (though having
> >> multiple boards for an SoC can cause lots of duplicated warnings).
> >>
> >> Please help fix these. More checks are being added[2].
> >>
> >
> > For the at91 ones, IIRC, they are coming from the clock binding and we
> > will have to break the ABI to fix it. This is not something we wanted to
> > do before 4.14 but it will happen at some point.
> 
> Looks like they are just missing unit-address. How does adding a
> unit-address break the ABI? Though, aren't you planning to change from
> a node per clock to clock controller node(s)? If so, then fixing when
> doing that is fine.

Adding the unit-address breaks the lookup of the clocks unless you want
to have nodes named prog0 at 0, prog1 at 1, pck0 at 8, etc...

I don't think it is worth the hassle going through all the dtsi to do
that.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

DT dtc warnings

[Krzysztof Kozlowski]

On Thu, Dec 14, 2017 at 7:21 PM, Rob Herring <robh@kernel.org> wrote:
> Hi all,
>
> Below is a current list of ARM boards with more than 40 dtc warnings
> when building with W=1. There's a treewide patch in flight to fix some
> unit-address warnings[1], so those aren't included here. The list is
> grouped by maintainer. AT91, Exynos, and Allwinner continue to be at
> the top of the list and have been for some time (though having
> multiple boards for an SoC can cause lots of duplicated warnings).
>
> Please help fix these. More checks are being added[2].
>
> Rob
>
> [1] https://patchwork.kernel.org/patch/10112725/
> [2] https://www.spinics.net/lists/devicetree-compiler/msg01620.html
>
>
> 77 - arch/arm/boot/dts/prima2-evb.dts
>
> 50 - arch/arm/boot/dts/exynos5250-arndale.dts
> 50 - arch/arm/boot/dts/exynos5250-smdk5250.dts
> 50 - arch/arm/boot/dts/exynos5250-snow.dts
> 50 - arch/arm/boot/dts/exynos5250-snow-rev5.dts
> 50 - arch/arm/boot/dts/exynos5250-spring.dts
> 71 - arch/arm/boot/dts/exynos5420-arndale-octa.dts
> 71 - arch/arm/boot/dts/exynos5420-peach-pit.dts
> 71 - arch/arm/boot/dts/exynos5420-smdk5420.dts
> 71 - arch/arm/boot/dts/exynos5422-odroidhc1.dts
> 71 - arch/arm/boot/dts/exynos5422-odroidxu3.dts
> 71 - arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> 71 - arch/arm/boot/dts/exynos5422-odroidxu4.dts
> 71 - arch/arm/boot/dts/exynos5800-peach-pi.dts
>

Sure, I can take care of this but in such case it would be better if
Mathieu's (+Cc) patch would be split per-subarch maintainer. I can
base my patch on top of his... but there might be conflicts when
applying to my tree.

Different topic - why not enabling these warnings by default?

Best regards,
Krzysztof

DT dtc warnings

[Krzysztof Kozlowski]

On Thu, Dec 14, 2017 at 9:40 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Thu, Dec 14, 2017 at 7:21 PM, Rob Herring <robh@kernel.org> wrote:
>> Hi all,
>>
>> Below is a current list of ARM boards with more than 40 dtc warnings
>> when building with W=1. There's a treewide patch in flight to fix some
>> unit-address warnings[1], so those aren't included here. The list is
>> grouped by maintainer. AT91, Exynos, and Allwinner continue to be at
>> the top of the list and have been for some time (though having
>> multiple boards for an SoC can cause lots of duplicated warnings).
>>
>> Please help fix these. More checks are being added[2].
>>
>> Rob
>>
>> [1] https://patchwork.kernel.org/patch/10112725/
>> [2] https://www.spinics.net/lists/devicetree-compiler/msg01620.html
>>
>>
>> 77 - arch/arm/boot/dts/prima2-evb.dts
>>
>> 50 - arch/arm/boot/dts/exynos5250-arndale.dts
>> 50 - arch/arm/boot/dts/exynos5250-smdk5250.dts
>> 50 - arch/arm/boot/dts/exynos5250-snow.dts
>> 50 - arch/arm/boot/dts/exynos5250-snow-rev5.dts
>> 50 - arch/arm/boot/dts/exynos5250-spring.dts
>> 71 - arch/arm/boot/dts/exynos5420-arndale-octa.dts
>> 71 - arch/arm/boot/dts/exynos5420-peach-pit.dts
>> 71 - arch/arm/boot/dts/exynos5420-smdk5420.dts
>> 71 - arch/arm/boot/dts/exynos5422-odroidhc1.dts
>> 71 - arch/arm/boot/dts/exynos5422-odroidxu3.dts
>> 71 - arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
>> 71 - arch/arm/boot/dts/exynos5422-odroidxu4.dts
>> 71 - arch/arm/boot/dts/exynos5800-peach-pi.dts
>>
>
> Sure, I can take care of this but in such case it would be better if
> Mathieu's (+Cc) patch would be split per-subarch maintainer. I can
> base my patch on top of his... but there might be conflicts when
> applying to my tree.
>
> Different topic - why not enabling these warnings by default?

Can anyone help why this W=1 triggers warning like these:
arch/arm/boot/dts/exynos3250-artik5-eval.dtb: Warning
(simple_bus_reg): Node /soc/syscon-poweroff missing or empty
reg/ranges property
arch/arm/boot/dts/exynos3250-artik5-eval.dtb: Warning
(simple_bus_reg): Node /soc/syscon-reboot missing or empty reg/ranges
property

For a node without unit address?
http://elixir.free-electrons.com/linux/v4.15-rc3/source/arch/arm/boot/dts/exynos-syscon-restart.dtsi

AFAIR, if node does not have unit-address then it should not have
reg/ranges property. Or maybe it is coming from parent's simple-bus?

Best regards,
Krzysztof

DT dtc warnings

[Fabio Estevam]

On Thu, Dec 14, 2017 at 7:01 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:

> Can anyone help why this W=1 triggers warning like these:
> arch/arm/boot/dts/exynos3250-artik5-eval.dtb: Warning
> (simple_bus_reg): Node /soc/syscon-poweroff missing or empty
> reg/ranges property
> arch/arm/boot/dts/exynos3250-artik5-eval.dtb: Warning
> (simple_bus_reg): Node /soc/syscon-reboot missing or empty reg/ranges
> property
>
> For a node without unit address?
> http://elixir.free-electrons.com/linux/v4.15-rc3/source/arch/arm/boot/dts/exynos-syscon-restart.dtsi
>
> AFAIR, if node does not have unit-address then it should not have
> reg/ranges property. Or maybe it is coming from parent's simple-bus?

syscon-poweroff and syscon-reboot should be outside the soc bus.

DT dtc warnings

[Krzysztof Kozlowski]

On Thu, Dec 14, 2017 at 10:13 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Thu, Dec 14, 2017 at 7:01 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
>> Can anyone help why this W=1 triggers warning like these:
>> arch/arm/boot/dts/exynos3250-artik5-eval.dtb: Warning
>> (simple_bus_reg): Node /soc/syscon-poweroff missing or empty
>> reg/ranges property
>> arch/arm/boot/dts/exynos3250-artik5-eval.dtb: Warning
>> (simple_bus_reg): Node /soc/syscon-reboot missing or empty reg/ranges
>> property
>>
>> For a node without unit address?
>> http://elixir.free-electrons.com/linux/v4.15-rc3/source/arch/arm/boot/dts/exynos-syscon-restart.dtsi
>>
>> AFAIR, if node does not have unit-address then it should not have
>> reg/ranges property. Or maybe it is coming from parent's simple-bus?
>
> syscon-poweroff and syscon-reboot should be outside the soc bus.

Thanks for reply!

Isn't this property of a SoC? The registers used by
syscon-poweroff/reboot are part of SoC power management unit. It does
not refer to any externals. Why then it should be put outside of soc?

Best regards,
Krzysztof

DT dtc warnings

[Fabio Estevam]

On Thu, Dec 14, 2017 at 7:19 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:

> Thanks for reply!
>
> Isn't this property of a SoC? The registers used by
> syscon-poweroff/reboot are part of SoC power management unit. It does
> not refer to any externals. Why then it should be put outside of soc?

If these nodes have registers, then they should have a unit address
and reg property.

Regards,

Fabio Estevam

DT dtc warnings

[Krzysztof Kozlowski]

On Fri, Dec 15, 2017 at 12:02 AM, Fabio Estevam <festevam@gmail.com> wrote:
> On Thu, Dec 14, 2017 at 7:19 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
>> Thanks for reply!
>>
>> Isn't this property of a SoC? The registers used by
>> syscon-poweroff/reboot are part of SoC power management unit. It does
>> not refer to any externals. Why then it should be put outside of soc?
>
> If these nodes have registers, then they should have a unit address
> and reg property.

That's the point - they do not have unit address.

Best regards,
Krzysztof

DT dtc warnings

[Alexandre Belloni]

On 15/12/2017 at 08:23:39 +0100, Krzysztof Kozlowski wrote:
> On Fri, Dec 15, 2017 at 12:02 AM, Fabio Estevam <festevam@gmail.com> wrote:
> > On Thu, Dec 14, 2017 at 7:19 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> >> Thanks for reply!
> >>
> >> Isn't this property of a SoC? The registers used by
> >> syscon-poweroff/reboot are part of SoC power management unit. It does
> >> not refer to any externals. Why then it should be put outside of soc?
> >
> > If these nodes have registers, then they should have a unit address
> > and reg property.
> 
> That's the point - they do not have unit address.
> 

Should they be put under the syscon they are using?

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

DT dtc warnings

[Krzysztof Kozlowski]

On Fri, Dec 15, 2017 at 8:29 AM, Alexandre Belloni
<alexandre.belloni@free-electrons.com> wrote:
> On 15/12/2017 at 08:23:39 +0100, Krzysztof Kozlowski wrote:
>> On Fri, Dec 15, 2017 at 12:02 AM, Fabio Estevam <festevam@gmail.com> wrote:
>> > On Thu, Dec 14, 2017 at 7:19 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> >
>> >> Thanks for reply!
>> >>
>> >> Isn't this property of a SoC? The registers used by
>> >> syscon-poweroff/reboot are part of SoC power management unit. It does
>> >> not refer to any externals. Why then it should be put outside of soc?
>> >
>> > If these nodes have registers, then they should have a unit address
>> > and reg property.
>>
>> That's the point - they do not have unit address.
>>
>
> Should they be put under the syscon they are using?

They are not using syscon but regmap provided by such external IP
block (for example this:
http://elixir.free-electrons.com/linux/v4.15-rc3/source/arch/arm/boot/dts/exynos3250.dtsi#L153).
I guess you are proposing something like on imx7s:
http://elixir.free-electrons.com/linux/v4.15-rc3/source/arch/arm/boot/dts/imx7s.dtsi#L539

That makes sense... I am not sure how this would be related to the
warning itself but anyway it looks logically.

Best regards,
Krzysztof

DT dtc warnings

[Rob Herring]

On Fri, Dec 15, 2017 at 1:34 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Fri, Dec 15, 2017 at 8:29 AM, Alexandre Belloni
> <alexandre.belloni@free-electrons.com> wrote:
>> On 15/12/2017 at 08:23:39 +0100, Krzysztof Kozlowski wrote:
>>> On Fri, Dec 15, 2017 at 12:02 AM, Fabio Estevam <festevam@gmail.com> wrote:
>>> > On Thu, Dec 14, 2017 at 7:19 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>> >
>>> >> Thanks for reply!
>>> >>
>>> >> Isn't this property of a SoC? The registers used by
>>> >> syscon-poweroff/reboot are part of SoC power management unit. It does
>>> >> not refer to any externals. Why then it should be put outside of soc?
>>> >
>>> > If these nodes have registers, then they should have a unit address
>>> > and reg property.
>>>
>>> That's the point - they do not have unit address.
>>>
>>
>> Should they be put under the syscon they are using?

+1

> They are not using syscon but regmap provided by such external IP
> block (for example this:
> http://elixir.free-electrons.com/linux/v4.15-rc3/source/arch/arm/boot/dts/exynos3250.dtsi#L153).
> I guess you are proposing something like on imx7s:
> http://elixir.free-electrons.com/linux/v4.15-rc3/source/arch/arm/boot/dts/imx7s.dtsi#L539

Yes, but the regmap property is pointless. It's the parent!

> That makes sense... I am not sure how this would be related to the
> warning itself but anyway it looks logically.

They just have to be under a node that is not a simple-bus.

"soc" nodes with a simple-bus compatible don't really mean everything
in the SoC, but just all (or some part of) the memory mapped space.
There's many board specific settings within those nodes. We don't
really split up top-level things into board and soc levels.

Rob

DT dtc warnings

[Alexandre Belloni]

On 15/12/2017 at 08:34:55 +0100, Krzysztof Kozlowski wrote:
> On Fri, Dec 15, 2017 at 8:29 AM, Alexandre Belloni
> <alexandre.belloni@free-electrons.com> wrote:
> > On 15/12/2017 at 08:23:39 +0100, Krzysztof Kozlowski wrote:
> >> On Fri, Dec 15, 2017 at 12:02 AM, Fabio Estevam <festevam@gmail.com> wrote:
> >> > On Thu, Dec 14, 2017 at 7:19 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >> >
> >> >> Thanks for reply!
> >> >>
> >> >> Isn't this property of a SoC? The registers used by
> >> >> syscon-poweroff/reboot are part of SoC power management unit. It does
> >> >> not refer to any externals. Why then it should be put outside of soc?
> >> >
> >> > If these nodes have registers, then they should have a unit address
> >> > and reg property.
> >>
> >> That's the point - they do not have unit address.
> >>
> >
> > Should they be put under the syscon they are using?
> 
> They are not using syscon but regmap provided by such external IP
> block (for example this:
> http://elixir.free-electrons.com/linux/v4.15-rc3/source/arch/arm/boot/dts/exynos3250.dtsi#L153).
> I guess you are proposing something like on imx7s:
> http://elixir.free-electrons.com/linux/v4.15-rc3/source/arch/arm/boot/dts/imx7s.dtsi#L539
> 

Yeah, exactly.

Another example here:
http://elixir.free-electrons.com/linux/v4.15-rc3/source/arch/arm/boot/dts/gemini.dtsi#L32

It seems your poweroff and reboot bits are in registers that are in the
pmu_system_controller so it makes sense to put them under it. I would
even remove the regmap property and get the regmap from the parent
first. This can easily be done while keeping the ABI backward
compatibility.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

DT dtc warnings

[Rob Herring]

On Thu, Dec 14, 2017 at 2:40 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Thu, Dec 14, 2017 at 7:21 PM, Rob Herring <robh@kernel.org> wrote:
>> Hi all,
>>
>> Below is a current list of ARM boards with more than 40 dtc warnings
>> when building with W=1. There's a treewide patch in flight to fix some
>> unit-address warnings[1], so those aren't included here. The list is
>> grouped by maintainer. AT91, Exynos, and Allwinner continue to be at
>> the top of the list and have been for some time (though having
>> multiple boards for an SoC can cause lots of duplicated warnings).
>>
>> 50 - arch/arm/boot/dts/exynos5250-arndale.dts
>> 50 - arch/arm/boot/dts/exynos5250-smdk5250.dts
>> 50 - arch/arm/boot/dts/exynos5250-snow.dts
>> 50 - arch/arm/boot/dts/exynos5250-snow-rev5.dts
>> 50 - arch/arm/boot/dts/exynos5250-spring.dts
>> 71 - arch/arm/boot/dts/exynos5420-arndale-octa.dts
>> 71 - arch/arm/boot/dts/exynos5420-peach-pit.dts
>> 71 - arch/arm/boot/dts/exynos5420-smdk5420.dts
>> 71 - arch/arm/boot/dts/exynos5422-odroidhc1.dts
>> 71 - arch/arm/boot/dts/exynos5422-odroidxu3.dts
>> 71 - arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
>> 71 - arch/arm/boot/dts/exynos5422-odroidxu4.dts
>> 71 - arch/arm/boot/dts/exynos5800-peach-pi.dts
>>
>
> Sure, I can take care of this but in such case it would be better if
> Mathieu's (+Cc) patch would be split per-subarch maintainer. I can
> base my patch on top of his... but there might be conflicts when
> applying to my tree.
>
> Different topic - why not enabling these warnings by default?

Because the warning police don't like lots of warnings. Neither did
Linus, but he only sees the unittest ones[1]. The ones that are actual
binding errors rather than best practice are on by default.

The plan is to enable once the warnings are all gone.

Rob

[1] https://www.spinics.net/lists/devicetree/msg202057.html

DT dtc warnings

[Santosh Shilimkar]

Hui Rob,

12/14/2017 10:21 AM, Rob Herring wrote:
> Hi all,
> 
> Below is a current list of ARM boards with more than 40 dtc warnings
> when building with W=1. There's a treewide patch in flight to fix some
> unit-address warnings[1], so those aren't included here. The list is
> grouped by maintainer. AT91, Exynos, and Allwinner continue to be at
> the top of the list and have been for some time (though having
> multiple boards for an SoC can cause lots of duplicated warnings).
> 
> Please help fix these. More checks are being added[2].
> 

[...]

> 
> 52 - arch/arm/boot/dts/keystone-k2e-evm.dts
> 73 - arch/arm/boot/dts/keystone-k2l-evm.dts
> 97 - arch/arm/boot/dts/keystone-k2hk-evm.dts
> 
Nishant is going to help me to address keystone ones.

Regards,
Santosh