* 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
* 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@public.gmane.org Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org 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: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 0 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@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org 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 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 0 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@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org 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: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 19:21 ` Alexandre Belloni 0 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@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org 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 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 20:40 ` Krzysztof Kozlowski 0 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@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, 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 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 21:01 ` Krzysztof Kozlowski 0 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@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, 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: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 0 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@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, 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: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 0 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@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, 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 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 0 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@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, 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-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 0 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@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, 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: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 0 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@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, 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: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 0 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@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, 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 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 18:52 ` Rob Herring 0 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@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, 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 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
* Re: 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: 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@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, 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-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:02 ` Rob Herring 0 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@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, 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 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:50 ` Santosh Shilimkar 0 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@public.gmane.org Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, 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
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 2017-12-14 18:36 ` Alexandre Belloni 2017-12-14 18:36 ` Alexandre Belloni 2017-12-14 19:00 ` Rob Herring 2017-12-14 19:00 ` Rob Herring 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 2017-12-14 21:01 ` Krzysztof Kozlowski 2017-12-14 21:01 ` Krzysztof Kozlowski 2017-12-14 21:13 ` Fabio Estevam 2017-12-14 21:13 ` Fabio Estevam 2017-12-14 21:19 ` Krzysztof Kozlowski 2017-12-14 21:19 ` Krzysztof Kozlowski 2017-12-14 23:02 ` Fabio Estevam 2017-12-14 23:02 ` Fabio Estevam 2017-12-15 7:23 ` Krzysztof Kozlowski 2017-12-15 7:23 ` Krzysztof Kozlowski 2017-12-15 7:29 ` Alexandre Belloni 2017-12-15 7:29 ` Alexandre Belloni 2017-12-15 7:34 ` Krzysztof Kozlowski 2017-12-15 7:34 ` Krzysztof Kozlowski 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.