All of lore.kernel.org
 help / color / mirror / Atom feed
* DT dtc warnings
@ 2017-12-14 18:21 ` Rob Herring
  0 siblings, 0 replies; 32+ messages in thread
From: Rob Herring @ 2017-12-14 18:21 UTC (permalink / raw)
  To: Barry Song, Kukjin Kim, Krzysztof Kozlowski, Maxime Ripard,
	Chen-Yu Tsai, Nicolas Ferre, Alexandre Belloni, Patrice Chotard,
	Peter Rosin, Santosh Shilimkar, arm-DgEjT+Ai2ygdnm+yROfE0A
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA

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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* DT dtc warnings
@ 2017-12-14 18:21 ` Rob Herring
  0 siblings, 0 replies; 32+ messages in thread
From: Rob Herring @ 2017-12-14 18:21 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Re: DT dtc warnings
  2017-12-14 18:21 ` Rob Herring
@ 2017-12-14 18:36     ` Alexandre Belloni
  -1 siblings, 0 replies; 32+ messages in thread
From: Alexandre Belloni @ 2017-12-14 18:36 UTC (permalink / raw)
  To: Rob Herring
  Cc: Barry Song, Kukjin Kim, Krzysztof Kozlowski, Maxime Ripard,
	Chen-Yu Tsai, Nicolas Ferre, Patrice Chotard, Peter Rosin,
	Santosh Shilimkar, arm-DgEjT+Ai2ygdnm+yROfE0A,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA

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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* DT dtc warnings
@ 2017-12-14 18:36     ` Alexandre Belloni
  0 siblings, 0 replies; 32+ messages in thread
From: Alexandre Belloni @ 2017-12-14 18:36 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Re: DT dtc warnings
  2017-12-14 18:36     ` Alexandre Belloni
@ 2017-12-14 19:00         ` Rob Herring
  -1 siblings, 0 replies; 32+ messages in thread
From: Rob Herring @ 2017-12-14 19:00 UTC (permalink / raw)
  To: Alexandre Belloni
  Cc: Barry Song, Kukjin Kim, Krzysztof Kozlowski, Maxime Ripard,
	Chen-Yu Tsai, Nicolas Ferre, Patrice Chotard, Peter Rosin,
	Santosh Shilimkar, arm-DgEjT+Ai2ygdnm+yROfE0A,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA

On Thu, Dec 14, 2017 at 12:36 PM, Alexandre Belloni
<alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> 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
--
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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* DT dtc warnings
@ 2017-12-14 19:00         ` Rob Herring
  0 siblings, 0 replies; 32+ messages in thread
From: Rob Herring @ 2017-12-14 19:00 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Re: DT dtc warnings
  2017-12-14 19:00         ` Rob Herring
@ 2017-12-14 19:21             ` Alexandre Belloni
  -1 siblings, 0 replies; 32+ messages in thread
From: Alexandre Belloni @ 2017-12-14 19:21 UTC (permalink / raw)
  To: Rob Herring
  Cc: Barry Song, Kukjin Kim, Krzysztof Kozlowski, Maxime Ripard,
	Chen-Yu Tsai, Nicolas Ferre, Patrice Chotard, Peter Rosin,
	Santosh Shilimkar, arm-DgEjT+Ai2ygdnm+yROfE0A,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA

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-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> 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@0, prog1@1, pck0@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
--
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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* DT dtc warnings
@ 2017-12-14 19:21             ` Alexandre Belloni
  0 siblings, 0 replies; 32+ messages in thread
From: Alexandre Belloni @ 2017-12-14 19:21 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Re: DT dtc warnings
  2017-12-14 18:21 ` Rob Herring
@ 2017-12-14 20:40     ` Krzysztof Kozlowski
  -1 siblings, 0 replies; 32+ messages in thread
From: Krzysztof Kozlowski @ 2017-12-14 20:40 UTC (permalink / raw)
  To: Rob Herring
  Cc: Barry Song, Kukjin Kim, Maxime Ripard, Chen-Yu Tsai,
	Nicolas Ferre, Alexandre Belloni, Patrice Chotard, Peter Rosin,
	Santosh Shilimkar, arm-DgEjT+Ai2ygdnm+yROfE0A,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Mathieu Malaterre

On Thu, Dec 14, 2017 at 7:21 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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
--
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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* DT dtc warnings
@ 2017-12-14 20:40     ` Krzysztof Kozlowski
  0 siblings, 0 replies; 32+ messages in thread
From: Krzysztof Kozlowski @ 2017-12-14 20:40 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Re: DT dtc warnings
  2017-12-14 18:21 ` Rob Herring
@ 2017-12-14 20:50     ` Santosh Shilimkar
  -1 siblings, 0 replies; 32+ messages in thread
From: Santosh Shilimkar @ 2017-12-14 20:50 UTC (permalink / raw)
  To: Rob Herring, Barry Song, Kukjin Kim, Krzysztof Kozlowski,
	Maxime Ripard, Chen-Yu Tsai, Nicolas Ferre, Alexandre Belloni,
	Patrice Chotard, Peter Rosin, Santosh Shilimkar,
	arm-DgEjT+Ai2ygdnm+yROfE0A
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Nishanth Menon

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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* DT dtc warnings
@ 2017-12-14 20:50     ` Santosh Shilimkar
  0 siblings, 0 replies; 32+ messages in thread
From: Santosh Shilimkar @ 2017-12-14 20:50 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Re: DT dtc warnings
  2017-12-14 20:40     ` Krzysztof Kozlowski
@ 2017-12-14 21:01         ` Krzysztof Kozlowski
  -1 siblings, 0 replies; 32+ messages in thread
From: Krzysztof Kozlowski @ 2017-12-14 21:01 UTC (permalink / raw)
  To: Rob Herring
  Cc: Barry Song, Kukjin Kim, Maxime Ripard, Chen-Yu Tsai,
	Nicolas Ferre, Alexandre Belloni, Patrice Chotard, Peter Rosin,
	Santosh Shilimkar, arm-DgEjT+Ai2ygdnm+yROfE0A,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Mathieu Malaterre

On Thu, Dec 14, 2017 at 9:40 PM, Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Thu, Dec 14, 2017 at 7:21 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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
--
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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* DT dtc warnings
@ 2017-12-14 21:01         ` Krzysztof Kozlowski
  0 siblings, 0 replies; 32+ messages in thread
From: Krzysztof Kozlowski @ 2017-12-14 21:01 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Re: DT dtc warnings
  2017-12-14 20:40     ` Krzysztof Kozlowski
@ 2017-12-14 21:02         ` Rob Herring
  -1 siblings, 0 replies; 32+ messages in thread
From: Rob Herring @ 2017-12-14 21:02 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: Barry Song, Kukjin Kim, Maxime Ripard, Chen-Yu Tsai,
	Nicolas Ferre, Alexandre Belloni, Patrice Chotard, Peter Rosin,
	Santosh Shilimkar, arm-DgEjT+Ai2ygdnm+yROfE0A,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Mathieu Malaterre

On Thu, Dec 14, 2017 at 2:40 PM, Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Thu, Dec 14, 2017 at 7:21 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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
--
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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* DT dtc warnings
@ 2017-12-14 21:02         ` Rob Herring
  0 siblings, 0 replies; 32+ messages in thread
From: Rob Herring @ 2017-12-14 21:02 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Re: DT dtc warnings
  2017-12-14 21:01         ` Krzysztof Kozlowski
@ 2017-12-14 21:13             ` Fabio Estevam
  -1 siblings, 0 replies; 32+ messages in thread
From: Fabio Estevam @ 2017-12-14 21:13 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: Rob Herring, Barry Song, Kukjin Kim, Maxime Ripard, Chen-Yu Tsai,
	Nicolas Ferre, Alexandre Belloni, Patrice Chotard, Peter Rosin,
	Santosh Shilimkar, arm-DgEjT+Ai2ygdnm+yROfE0A,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Mathieu Malaterre

On Thu, Dec 14, 2017 at 7:01 PM, Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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.
--
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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* DT dtc warnings
@ 2017-12-14 21:13             ` Fabio Estevam
  0 siblings, 0 replies; 32+ messages in thread
From: Fabio Estevam @ 2017-12-14 21:13 UTC (permalink / raw)
  To: linux-arm-kernel

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.

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Re: DT dtc warnings
  2017-12-14 21:13             ` Fabio Estevam
@ 2017-12-14 21:19                 ` Krzysztof Kozlowski
  -1 siblings, 0 replies; 32+ messages in thread
From: Krzysztof Kozlowski @ 2017-12-14 21:19 UTC (permalink / raw)
  To: Fabio Estevam
  Cc: Rob Herring, Barry Song, Kukjin Kim, Maxime Ripard, Chen-Yu Tsai,
	Nicolas Ferre, Alexandre Belloni, Patrice Chotard, Peter Rosin,
	Santosh Shilimkar, arm-DgEjT+Ai2ygdnm+yROfE0A,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Mathieu Malaterre

On Thu, Dec 14, 2017 at 10:13 PM, Fabio Estevam <festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Dec 14, 2017 at 7:01 PM, Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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
--
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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* DT dtc warnings
@ 2017-12-14 21:19                 ` Krzysztof Kozlowski
  0 siblings, 0 replies; 32+ messages in thread
From: Krzysztof Kozlowski @ 2017-12-14 21:19 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Re: DT dtc warnings
  2017-12-14 21:19                 ` Krzysztof Kozlowski
@ 2017-12-14 23:02                     ` Fabio Estevam
  -1 siblings, 0 replies; 32+ messages in thread
From: Fabio Estevam @ 2017-12-14 23:02 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: Rob Herring, Barry Song, Kukjin Kim, Maxime Ripard, Chen-Yu Tsai,
	Nicolas Ferre, Alexandre Belloni, Patrice Chotard, Peter Rosin,
	Santosh Shilimkar, arm-DgEjT+Ai2ygdnm+yROfE0A,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Mathieu Malaterre

On Thu, Dec 14, 2017 at 7:19 PM, Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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
--
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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* DT dtc warnings
@ 2017-12-14 23:02                     ` Fabio Estevam
  0 siblings, 0 replies; 32+ messages in thread
From: Fabio Estevam @ 2017-12-14 23:02 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Re: DT dtc warnings
  2017-12-14 23:02                     ` Fabio Estevam
@ 2017-12-15  7:23                         ` Krzysztof Kozlowski
  -1 siblings, 0 replies; 32+ messages in thread
From: Krzysztof Kozlowski @ 2017-12-15  7:23 UTC (permalink / raw)
  To: Fabio Estevam
  Cc: Rob Herring, Barry Song, Kukjin Kim, Maxime Ripard, Chen-Yu Tsai,
	Nicolas Ferre, Alexandre Belloni, Patrice Chotard, Peter Rosin,
	Santosh Shilimkar, arm-DgEjT+Ai2ygdnm+yROfE0A,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Mathieu Malaterre

On Fri, Dec 15, 2017 at 12:02 AM, Fabio Estevam <festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Dec 14, 2017 at 7:19 PM, Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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
--
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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* DT dtc warnings
@ 2017-12-15  7:23                         ` Krzysztof Kozlowski
  0 siblings, 0 replies; 32+ messages in thread
From: Krzysztof Kozlowski @ 2017-12-15  7:23 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Re: DT dtc warnings
  2017-12-15  7:23                         ` Krzysztof Kozlowski
@ 2017-12-15  7:29                             ` Alexandre Belloni
  -1 siblings, 0 replies; 32+ messages in thread
From: Alexandre Belloni @ 2017-12-15  7:29 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: Fabio Estevam, Rob Herring, Barry Song, Kukjin Kim,
	Maxime Ripard, Chen-Yu Tsai, Nicolas Ferre, Patrice Chotard,
	Peter Rosin, Santosh Shilimkar, arm-DgEjT+Ai2ygdnm+yROfE0A,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Mathieu Malaterre

On 15/12/2017 at 08:23:39 +0100, Krzysztof Kozlowski wrote:
> On Fri, Dec 15, 2017 at 12:02 AM, Fabio Estevam <festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Thu, Dec 14, 2017 at 7:19 PM, Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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
--
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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* DT dtc warnings
@ 2017-12-15  7:29                             ` Alexandre Belloni
  0 siblings, 0 replies; 32+ messages in thread
From: Alexandre Belloni @ 2017-12-15  7:29 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Re: DT dtc warnings
  2017-12-15  7:29                             ` Alexandre Belloni
@ 2017-12-15  7:34                                 ` Krzysztof Kozlowski
  -1 siblings, 0 replies; 32+ messages in thread
From: Krzysztof Kozlowski @ 2017-12-15  7:34 UTC (permalink / raw)
  To: Alexandre Belloni
  Cc: Fabio Estevam, Rob Herring, Barry Song, Kukjin Kim,
	Maxime Ripard, Chen-Yu Tsai, Nicolas Ferre, Patrice Chotard,
	Peter Rosin, Santosh Shilimkar, arm-DgEjT+Ai2ygdnm+yROfE0A,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Mathieu Malaterre

On Fri, Dec 15, 2017 at 8:29 AM, Alexandre Belloni
<alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > On Thu, Dec 14, 2017 at 7:19 PM, Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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
--
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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* DT dtc warnings
@ 2017-12-15  7:34                                 ` Krzysztof Kozlowski
  0 siblings, 0 replies; 32+ messages in thread
From: Krzysztof Kozlowski @ 2017-12-15  7:34 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Re: DT dtc warnings
  2017-12-15  7:34                                 ` Krzysztof Kozlowski
@ 2017-12-15 18:52                                     ` Rob Herring
  -1 siblings, 0 replies; 32+ messages in thread
From: Rob Herring @ 2017-12-15 18:52 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: Alexandre Belloni, Fabio Estevam, Barry Song, Kukjin Kim,
	Maxime Ripard, Chen-Yu Tsai, Nicolas Ferre, Patrice Chotard,
	Peter Rosin, Santosh Shilimkar, arm-DgEjT+Ai2ygdnm+yROfE0A,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Mathieu Malaterre

On Fri, Dec 15, 2017 at 1:34 AM, Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Fri, Dec 15, 2017 at 8:29 AM, Alexandre Belloni
> <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> > On Thu, Dec 14, 2017 at 7:19 PM, Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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
--
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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* DT dtc warnings
@ 2017-12-15 18:52                                     ` Rob Herring
  0 siblings, 0 replies; 32+ messages in thread
From: Rob Herring @ 2017-12-15 18:52 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Re: DT dtc warnings
  2017-12-15  7:34                                 ` Krzysztof Kozlowski
@ 2017-12-15 19:21                                     ` Alexandre Belloni
  -1 siblings, 0 replies; 32+ messages in thread
From: Alexandre Belloni @ 2017-12-15 19:21 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: Fabio Estevam, Rob Herring, Barry Song, Kukjin Kim,
	Maxime Ripard, Chen-Yu Tsai, Nicolas Ferre, Patrice Chotard,
	Peter Rosin, Santosh Shilimkar, arm-DgEjT+Ai2ygdnm+yROfE0A,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Mathieu Malaterre

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-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> > On Thu, Dec 14, 2017 at 7:19 PM, Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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
--
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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* DT dtc warnings
@ 2017-12-15 19:21                                     ` Alexandre Belloni
  0 siblings, 0 replies; 32+ messages in thread
From: Alexandre Belloni @ 2017-12-15 19:21 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 32+ messages in thread
end of thread, other threads:[~2017-12-15 19:21 UTC | newest]

Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-14 18:21 DT dtc warnings Rob Herring
2017-12-14 18:21 ` Rob Herring
     [not found] ` <CAL_JsqJKCzjx3zNigu_0T=Ku=_P2SQEjTx=uVbvr_QxJQR7kYg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-12-14 18:36   ` Alexandre Belloni
2017-12-14 18:36     ` Alexandre Belloni
     [not found]     ` <20171214183642.GF2559-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org>
2017-12-14 19:00       ` Rob Herring
2017-12-14 19:00         ` Rob Herring
     [not found]         ` <CAL_JsqKqiyCb8s9cyM-LdZv+hyMjv2ZpfGZmyy9_+Wrd7-qF8g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-12-14 19:21           ` Alexandre Belloni
2017-12-14 19:21             ` Alexandre Belloni
2017-12-14 20:40   ` Krzysztof Kozlowski
2017-12-14 20:40     ` Krzysztof Kozlowski
     [not found]     ` <CAJKOXPc7M3jeV_hNBBRJKGs3vtNzdrGbW_YETw2n0fXxhqjZ_g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-12-14 21:01       ` Krzysztof Kozlowski
2017-12-14 21:01         ` Krzysztof Kozlowski
     [not found]         ` <CAJKOXPfCDT+7wPkz3g6AiKgLvFp4rnicYQgYn8A_yaPe4YhD5A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-12-14 21:13           ` Fabio Estevam
2017-12-14 21:13             ` Fabio Estevam
     [not found]             ` <CAOMZO5BGX1U90bGrff42rZKKOSQK3NB=-k_4BX04Tsi=yX0Odg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-12-14 21:19               ` Krzysztof Kozlowski
2017-12-14 21:19                 ` Krzysztof Kozlowski
     [not found]                 ` <CAJKOXPea5nx+i+vWJcMGqct1=gP5OHbDSAzqTCBYr1RvFW-1gw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-12-14 23:02                   ` Fabio Estevam
2017-12-14 23:02                     ` Fabio Estevam
     [not found]                     ` <CAOMZO5CKPhQwdkYBeu74k=RYBxGhVf13nnrzHXUhq8LWk8yBSg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-12-15  7:23                       ` Krzysztof Kozlowski
2017-12-15  7:23                         ` Krzysztof Kozlowski
     [not found]                         ` <CAJKOXPeqm-KRnuc7uUena=iH+rYLzSVSCb-uSbLB4SdRGqLRtw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-12-15  7:29                           ` Alexandre Belloni
2017-12-15  7:29                             ` Alexandre Belloni
     [not found]                             ` <20171215072921.GJ2559-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org>
2017-12-15  7:34                               ` Krzysztof Kozlowski
2017-12-15  7:34                                 ` Krzysztof Kozlowski
     [not found]                                 ` <CAJKOXPcf_zf3X8i9xVpK_BSvnR-78otwmaiOERDYTT2tC3VC2A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-12-15 18:52                                   ` Rob Herring
2017-12-15 18:52                                     ` Rob Herring
2017-12-15 19:21                                   ` Alexandre Belloni
2017-12-15 19:21                                     ` Alexandre Belloni
2017-12-14 21:02       ` Rob Herring
2017-12-14 21:02         ` Rob Herring
2017-12-14 20:50   ` Santosh Shilimkar
2017-12-14 20:50     ` Santosh Shilimkar

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.