* New 'make dtbs_check W=1' warnings @ 2021-04-08 15:08 ` Arnd Bergmann 0 siblings, 0 replies; 28+ messages in thread From: Arnd Bergmann @ 2021-04-08 15:08 UTC (permalink / raw) To: DTML, Rob Herring Cc: Linus Walleij, Alexandre Belloni, Alexandre Torgue, Kevin Hilman, Linux Kernel Mailing List, Linux ARM, Tony Lindgren, Shawn Guo, Matthias Brugger, Bjorn Andersson, Geert Uytterhoeven, Nishanth Menon, Tero Kristo, SoC Team, Krzysztof Kozlowski, Gregory Clement, Florian Fainelli Greetings to all Arm platform maintainers, I've just gone through the DT merges I've received so far and, with a little help from Rob, managed to run 'make dtbs_check W=1' before and after, to see what warnings we get. The good news is that the number of warnings is going down, but unfortunately there is still an unmanageable amount of remaining warnings, and some new ones crept in. I'm still working on my tooling for this, to catch these better, but ideally I think we should try to not introduce new warnings. I think some platforms are already clean, and I did not see any new warnings for mvebu, samsung and broadcom. There were a lot of warnings from .dtsi files, and I probably did an incomplete job at deduplicating those. See below for the other platforms, and the new warnings that I found. If these are valid, please send a fixup before the merge window, and let me know if you have ideas for how we should handle these in the future. For this merge window, I don't think any of them are show-stoppers (Rob, let me know if you disagree), but in the long run we may want to gradually enforce a rule about not merging changes that introduce any new warnings, in order to have a chance of cleaning up the existing ones. Arnd arch/arm/boot/dts/ste-href520-tvk.dt.yaml: accelerometer@19: interrupts: [[18, 1], [19, 1]] is too long arch/arm/boot/dts/ste-hrefprev60-tvk.dt.yaml: gyroscope@68: interrupts-extended: [[22, 0, 1], [21, 31, 1]] is too long arch/arm/boot/dts/ste-hrefv60plus-tvk.dt.yaml: gyroscope@68: interrupts-extended: [[25, 0, 1], [24, 31, 1]] is too long arch/arm/boot/dts/ste-hrefv60plus-tvk.dt.yaml: accelerometer@1c: interrupts: [[18, 1], [19, 1]] is too long arch/arm/boot/dts/omap5-cm-t54.dt.yaml: gpmc@50000000: 'clocks' is a dependency of 'clock-names' arch/arm/boot/dts/omap5-igep0050.dt.yaml: gpmc@50000000: 'clocks' is a dependency of 'clock-names' arch/arm/boot/dts/omap5-sbc-t54.dt.yaml: gpmc@50000000: 'clocks' is a dependency of 'clock-names' arch/arm/boot/dts/omap5-uevm.dt.yaml: gpmc@50000000: 'clocks' is a dependency of 'clock-names' arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dt.yaml: pin-controller@50002000: 'ltdc' does not match any of the regexes: '-[0-9]*$', '^gpio@[0-9a-f]*$', 'pinctrl-[0-9]+' arch/arm/boot/dts/at91-sama5d2_ptc_ek.dt.yaml: /: 'etm@73C000' does not match any of the regexes: '@(0|[1-9a-f][0-9a-f]*)$', '^[^@]+$', 'pinctrl-[0-9]+' arch/arm/boot/dts/at91-kizbox3-hs.dt.yaml: /: 'etm@73C000' does not match any of the regexes: '@(0|[1-9a-f][0-9a-f]*)$', '^[^@]+$', 'pinctrl-[0-9]+' amlogic/meson-gxl-s905d-mecool-kii-pro.dts:31.19-42.4: Warning (avoid_unnecessary_addr_size): /gpio-keys-polled: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property amlogic/meson-gxl-s905d-mecool-kii-pro.dts:37.12-41.5: Warning (unit_address_vs_reg): /gpio-keys-polled/button@0: node has a unit name, but no reg or ranges property amlogic/meson-gxm-mecool-kiii-pro.dts:36.19-47.4: Warning (avoid_unnecessary_addr_size): /gpio-keys-polled: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property amlogic/meson-gxm-mecool-kiii-pro.dts:42.12-46.5: Warning (unit_address_vs_reg): /gpio-keys-polled/button@0: node has a unit name, but no reg or ranges property amlogic/meson-gxm-minix-neo-u9h.dts:42.19-53.4: Warning (avoid_unnecessary_addr_size): /gpio-keys-polled: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property amlogic/meson-gxm-minix-neo-u9h.dts:48.12-52.5: Warning (unit_address_vs_reg): /gpio-keys-polled/button@0: node has a unit name, but no reg or ranges property amlogic/meson-gxl-s805x-p241.dt.yaml: serial@84c0: 'uart-has-rtscts' does not match any of the regexes: 'pinctrl-[0-9]+' amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: audio-controller@5400: 'sound-name-prefix' does not match any of the regexes: 'pinctrl-[0-9]+' amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: audio-controller@c8832000: 'AVDD-supply', 'sound-name-prefix' do not match any f the regexes: 'pinctrl-[0-9]+' amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: bluetooth: clock-names: ['lpo'] is too short amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: bluetooth: clock-names:0: 'txco' was expected amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: bluetooth: clocks: [[23]] is too short amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: bus@c8834000: eth-phy-mux: {'type': 'object'} is not allowed for {'compatible': ['mdio-mux-mmioreg', 'mdio-mux'], '#address-cells': [[1]], '#size-cells': [[0]], 'reg': [[0, 1372, 0, 4]], 'mux-mask': [[4294967295]], 'mdio-parent-bus': [[35]], 'mdio@e40908ff': {'reg': [[3825797375]], '#address-cells': [[1]], '#size-cells': [[0]], 'ethernet-phy@8': {'compatible': ['ethernet-phy-id0181.4400'], 'interrupts': [[0, 9, 4]], 'reg': [[8]], 'max-speed': [[100]], 'phandle': [[36]]}}, 'mdio@2009087f': {'reg': [[537462911]], '#address-cells': [[1]], '#size-cells': [[0]]}} amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: bus@c8834000: rng: {'type': 'object'} is not allowed for {'compatible': ['amlogic,meson-rng'], 'reg': [[0, 0, 0, 4]], 'clocks': [[3, 25]], 'clock-names': ['core']} amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: hdmi-tx@c883a000: 'sound-name-prefix' does not match any of the regexes: pinctrl-[0-9]+' amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: ir@580: linux,rc-map-name:0: 'rc-mecool-kii-pro' is not one of ['rc-adstech-dvb-t-ci', 'rc-alink-dtu-m', 'rc-anysee', 'rc-apac-viewcomp',..., 'rc-zx-irdec'] amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: leds: 'blue' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: serial@84c0: 'bluetooth', 'uart-has-rtscts' do not match any of the regexes: 'pinctrl-0-9]+' amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: 'assigned-clock-parents', 'assigned-clock-rates', 'assigned-clocks' do not atch any of the regexes: '^dai-link-[0-9]+$', 'pinctrl-[0-9]+' amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: 'clocks' is a dependency of 'assigned-clocks' amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: audio-routing: ['AU2 INL', 'ACODEC LOLP', 'AU2 INR', 'ACODEC LORP', AU2 INL', 'ACODEC LOLN', 'AU2 INR', 'ACODEC LORN', 'Lineout', 'AU2 OUTL', 'Lineout', 'AU2 OUTR'] is too long amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: dai-link-0:sound-dai:0: [63, 0, 0] is too long amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: dai-link-0:sound-dai:0:1: missing phandle tag in 0 amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: dai-link-0:sound-dai:0:2: missing phandle tag in 0 amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: dai-link-1:sound-dai:0: [63, 0, 1] is too long amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: dai-link-1:sound-dai:0:1: missing phandle tag in 0 amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: dai-link-1:sound-dai:0:2: missing phandle tag in 1 amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: vpu@d0100000: 'amlogic,canvas' does not match any of the regexes: 'pinctrl-[0-9]+' freescale/imx8-ss-audio.dtsi:16.33-21.4: Warning (simple_bus_reg): /bus@59000000/clock-audio-ipg: missing or empty reg/ranges property freescale/imx8-ss-conn.dtsi:16.31-21.4: Warning (simple_bus_reg): /bus@5b000000/clock-conn-axi: missing or empty reg/ranges property freescale/imx8-ss-conn.dtsi:23.31-28.4: Warning (simple_bus_reg): /bus@5b000000/clock-conn-ahb: missing or empty reg/ranges property freescale/imx8-ss-conn.dtsi:30.31-35.4: Warning (simple_bus_reg): /bus@5b000000/clock-conn-ipg: missing or empty reg/ranges property freescale/imx8-ss-dma.dtsi:16.29-21.4: Warning (simple_bus_reg): /bus@5a000000/clock-dma-ipg: missing or empty reg/ranges property freescale/imx8-ss-lsio.dtsi:16.31-21.4: Warning (simple_bus_reg): /bus@5d000000/clock-lsio-mem: missing or empty reg/ranges property freescale/imx8-ss-lsio.dtsi:23.31-28.4: Warning (simple_bus_reg): /bus@5d000000/clock-lsio-bus: missing or empty reg/ranges property freescale/fsl-lx2160a-clearfog-cx.dt.yaml: ethernet@7: 'sfp' does not match any of the regexes: 'pinctrl-[0-9]+' freescale/fsl-lx2160a-clearfog-cx.dt.yaml: ethernet@8: 'sfp' does not match any of the regexes: 'pinctrl-[0-9]+' freescale/fsl-lx2160a-clearfog-cx.dt.yaml: ethernet@9: 'sfp' does not match any of the regexes: 'pinctrl-[0-9]+' freescale/fsl-lx2160a-clearfog-cx.dt.yaml: ethernet@a: 'sfp' does not match any of the regexes: 'pinctrl-[0-9]+' freescale/fsl-lx2160a-honeycomb.dt.yaml: power-controller@1e34040: '#power-domain-cells' is a required property mediatek/mt8183-pumpkin.dts:35.36-39.5: Warning (unit_address_vs_reg): /reserved-memory/scp_mem_region: node has a reg or ranges property, but no unit name mediatek/mt8183-pumpkin.dts:58.8-64.4: Warning (unit_address_vs_reg): /ntc@0: node has a unit name, but no reg or ranges property mediatek/mt8183.dtsi:1106.26-1112.6: Warning (unit_address_format): /soc/t-phy@11f40000/usb-phy@0700: unit name should not have leading 0s mediatek/mt8183.dtsi:1234.22-1246.5: Warning (avoid_unnecessary_addr_size): /soc/dsi@14014000: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property mediatek/mt8183.dtsi:676.17-795.5: Warning (simple_bus_reg): /soc/thermal-zones: missing or empty reg/ranges property mediatek/mt8183.dtsi:684.30-688.8: Warning (unit_address_vs_reg): /soc/thermal-zones/cpu_thermal/trips/trip-point@0: node has a unit name, but no reg or ranges property mediatek/mt8183-evb.dt.yaml: soc: thermal-zones: {'type': 'object'} is not allowed for {'cpu_thermal': {'polling-delay-passive': [[100]], 'polling-delay': [[500]], 'thermal-sensors': [[41, 0]... 'pinctrl-[0-9]+' mediatek/mt8183-kukui-jacuzzi-damu.dt.yaml: anx7625@58: '#address-cells', '#size-cells', 'panel_flags', 'port@0', 'port@1' do not match any of the regexes: 'pinctrl-[0-9]+' mediatek/mt8183-kukui-jacuzzi-damu.dt.yaml: anx7625@58: 'ports' is a required property mediatek/mt8183-kukui-jacuzzi-damu.dt.yaml: cros_ec: 'mtk,rpmsg-name' does not match any of the regexes: '^#.*', ... qcom/sc7180.dtsi:1204.21-1220.6: Warning (avoid_unnecessary_addr_size): /soc@0/geniqup@ac0000/i2c@a8c000: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property qcom/sc7180.dtsi:965.21-981.6: Warning (avoid_unnecessary_addr_size): /soc@0/geniqup@8c0000/i2c@890000: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property qcom/sdm845.dtsi:3912.23-4045.5: Warning (simple_bus_reg): /soc@0/camss@a00000: simple-bus unit address format error, expected "acb3000" qcom/sdm845.dtsi:4041.10-4044.6: Warning (graph_child_address): /soc@0/camss@a00000/ports: graph node has single child node 'port@0', #address-cells/#size-cells are not necessary qcom/sdm845.dtsi:4102.32-4129.5: Warning (simple_bus_reg): /soc@0/dsi-opp-table: missing or empty reg/ranges property ti/k3-am64-main.dtsi:376.40-385.4: Warning (simple_bus_reg): /bus@f4000/interrupt-controller0: missing or empty reg/ranges property ti/k3-am64-main.dtsi:45.13-135.4: Warning (simple_bus_reg): /bus@f4000/dmss: missing or empty reg/ranges property ti/k3-am64-mcu.dtsi:77.39-86.4: Warning (simple_bus_reg): /bus@f4000/bus@4000000/interrupt-controller1: missing or empty reg/ranges property qcom/msm8916-samsung-a5u-eur.dt.yaml: spmi@200f000: reg: [[33615872, 4096], [37748736, 4194304], [46137344, 4194304], [58720256, 2097152], [33595392, 8448]] is too long qcom/sc7180-trogdor-lazor-r0.dt.yaml: gmu@506a000: compatible:0: 'qcom,adreno-gmu-618.0' is not one of ['qcom,adreno-gmu-630.2'] qcom/sc7180-trogdor-lazor-r1-kb.dt.yaml: memory@80900000: 'device_type' is a required property qcom/sdm850-lenovo-yoga-c630.dt.yaml: memory@97b00000: 'device_type' is a required property renesas/r8a774a1-beacon-rzg2m-kit.dt.yaml: csi2@feaa0000: ports: 'port@0' is a required property renesas/r8a779a0-falcon.dt.yaml: thermal-zones: 'sensor-thermal1', 'sensor-thermal2', 'sensor-thermal3', 'sensor-thermal4', 'sensor-thermal5' do not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-]{1,12}-thermal$', 'pinctrl-[0-9]+' renesas/r8a779a0-falcon.dt.yaml: timer@e61e0000: compatible:0: 'renesas,tmu-r8a779a0' is not one of ['renesas,tmu-r8a7740', 'renesas,tmu-r8a774a1', 'renesas,tmu-r8a774b1', 'renesas,tmu-r8a774c0', 'renesas,tmu-r8a774e1', 'renesas,tmu-r8a7778', 'renesas,tmu-r8a7779', 'renesas,tmu-r8a7795', 'renesas,tmu-r8a7796', 'renesas,tmu-r8a77961', 'renesas,tmu-r8a77965', 'renesas,tmu-r8a77970', 'renesas,tmu-r8a77980', 'renesas,tmu-r8a77990', 'renesas,tmu-r8a77995'] rockchip/rk3399-khadas-edge-v.dt.yaml: usb@fe800000: #address-cells:0:0: 1 was expected ti/k3-am642-evm.dt.yaml: bus@4000000: interrupt-controller1: {'type': 'object'} is not allowed for {'compatible': ['ti,sci-intr'], 'ti,intr-trigger-type': [[1]], 'interrupt-controller': True, 'interrupt-parent': [[1]], '#interrupt-cells': [[1]], 'ti,sci': [[4]], 'ti,sci-dev-id': [[5]], 'ti,interrupt-ranges': [[0, 104, 4]], 'phandle': [[5]]} ti/k3-am642-evm.dt.yaml: bus@f4000: dmss: {'type': 'object'} is not allowed for {'compatible': ['simple-mfd'], '#address-cells': [[2]], '#size-cells': [[2]], 'dma-ranges': True, 'ranges': 'phandle': [[7]]}} ti/k3-am642-evm.dt.yaml: bus@f4000: interrupt-controller0: {'type': 'object'} is not allowed for {'compatible': ['ti,sci-intr'], 'ti,intr-trigger-type': [[1]], 'interrupt-controller': True, 'interrupt-parent': [[1]], '#interrupt-cells': [[1]], 'ti,sci': [[4]], 'ti,sci-dev-id': [[3]], 'ti,interrupt-ranges': [[0, 32, 16]], 'phandle': [[15]]} ti/k3-am642-evm.dt.yaml: flash@0: 'cdns,read-delay', 'cdns,tchsh-ns', 'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not match any of the regexes: '^partition@', 'pinctrl-[0-9]+' ti/k3-am642-sk.dt.yaml: bus@4000000: interrupt-controller1: {'type': 'object'} is not allowed for {'compatible': ['ti,sci-intr'], 'ti,intr-trigger-type': [[1]], ... ti/k3-am642-sk.dt.yaml: bus@f4000: dmss: {'type': 'object'} is not allowed for {'compatible': ['simple-mfd'], ... ti/k3-am642-sk.dt.yaml: bus@f4000: interrupt-controller0: {'type': 'object'} is not allowed for {'compatible': ['ti,sci-intr'], 'ti,intr-trigger-type': [[1]], 'interrupt-controller': True, 'interrupt-parent': [[1]], '#interrupt-cells': [[1]], 'ti,sci': [[4]], 'ti,sci-dev-id': [[3]], 'ti,interrupt-ranges': [[0, 32, 16]], 'phandle': [[11]]} ti/k3-am642-sk.dt.yaml: flash@0: 'cdns,read-delay', 'cdns,tchsh-ns', 'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not match any of the regexes: '^partition@', 'pinctrl-[0-9]+' ti/k3-j7200-common-proc-board.dt.yaml: flash@0: 'cdns,read-delay', 'cdns,tchsh-ns', 'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not match any of the regexes: '^partition@', 'pinctrl-[0-9]+' ^ permalink raw reply [flat|nested] 28+ messages in thread
* New 'make dtbs_check W=1' warnings @ 2021-04-08 15:08 ` Arnd Bergmann 0 siblings, 0 replies; 28+ messages in thread From: Arnd Bergmann @ 2021-04-08 15:08 UTC (permalink / raw) To: DTML, Rob Herring Cc: Linus Walleij, Alexandre Belloni, Alexandre Torgue, Kevin Hilman, Linux Kernel Mailing List, Linux ARM, Tony Lindgren, Shawn Guo, Matthias Brugger, Bjorn Andersson, Geert Uytterhoeven, Nishanth Menon, Tero Kristo, SoC Team, Krzysztof Kozlowski, Gregory Clement, Florian Fainelli Greetings to all Arm platform maintainers, I've just gone through the DT merges I've received so far and, with a little help from Rob, managed to run 'make dtbs_check W=1' before and after, to see what warnings we get. The good news is that the number of warnings is going down, but unfortunately there is still an unmanageable amount of remaining warnings, and some new ones crept in. I'm still working on my tooling for this, to catch these better, but ideally I think we should try to not introduce new warnings. I think some platforms are already clean, and I did not see any new warnings for mvebu, samsung and broadcom. There were a lot of warnings from .dtsi files, and I probably did an incomplete job at deduplicating those. See below for the other platforms, and the new warnings that I found. If these are valid, please send a fixup before the merge window, and let me know if you have ideas for how we should handle these in the future. For this merge window, I don't think any of them are show-stoppers (Rob, let me know if you disagree), but in the long run we may want to gradually enforce a rule about not merging changes that introduce any new warnings, in order to have a chance of cleaning up the existing ones. Arnd arch/arm/boot/dts/ste-href520-tvk.dt.yaml: accelerometer@19: interrupts: [[18, 1], [19, 1]] is too long arch/arm/boot/dts/ste-hrefprev60-tvk.dt.yaml: gyroscope@68: interrupts-extended: [[22, 0, 1], [21, 31, 1]] is too long arch/arm/boot/dts/ste-hrefv60plus-tvk.dt.yaml: gyroscope@68: interrupts-extended: [[25, 0, 1], [24, 31, 1]] is too long arch/arm/boot/dts/ste-hrefv60plus-tvk.dt.yaml: accelerometer@1c: interrupts: [[18, 1], [19, 1]] is too long arch/arm/boot/dts/omap5-cm-t54.dt.yaml: gpmc@50000000: 'clocks' is a dependency of 'clock-names' arch/arm/boot/dts/omap5-igep0050.dt.yaml: gpmc@50000000: 'clocks' is a dependency of 'clock-names' arch/arm/boot/dts/omap5-sbc-t54.dt.yaml: gpmc@50000000: 'clocks' is a dependency of 'clock-names' arch/arm/boot/dts/omap5-uevm.dt.yaml: gpmc@50000000: 'clocks' is a dependency of 'clock-names' arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dt.yaml: pin-controller@50002000: 'ltdc' does not match any of the regexes: '-[0-9]*$', '^gpio@[0-9a-f]*$', 'pinctrl-[0-9]+' arch/arm/boot/dts/at91-sama5d2_ptc_ek.dt.yaml: /: 'etm@73C000' does not match any of the regexes: '@(0|[1-9a-f][0-9a-f]*)$', '^[^@]+$', 'pinctrl-[0-9]+' arch/arm/boot/dts/at91-kizbox3-hs.dt.yaml: /: 'etm@73C000' does not match any of the regexes: '@(0|[1-9a-f][0-9a-f]*)$', '^[^@]+$', 'pinctrl-[0-9]+' amlogic/meson-gxl-s905d-mecool-kii-pro.dts:31.19-42.4: Warning (avoid_unnecessary_addr_size): /gpio-keys-polled: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property amlogic/meson-gxl-s905d-mecool-kii-pro.dts:37.12-41.5: Warning (unit_address_vs_reg): /gpio-keys-polled/button@0: node has a unit name, but no reg or ranges property amlogic/meson-gxm-mecool-kiii-pro.dts:36.19-47.4: Warning (avoid_unnecessary_addr_size): /gpio-keys-polled: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property amlogic/meson-gxm-mecool-kiii-pro.dts:42.12-46.5: Warning (unit_address_vs_reg): /gpio-keys-polled/button@0: node has a unit name, but no reg or ranges property amlogic/meson-gxm-minix-neo-u9h.dts:42.19-53.4: Warning (avoid_unnecessary_addr_size): /gpio-keys-polled: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property amlogic/meson-gxm-minix-neo-u9h.dts:48.12-52.5: Warning (unit_address_vs_reg): /gpio-keys-polled/button@0: node has a unit name, but no reg or ranges property amlogic/meson-gxl-s805x-p241.dt.yaml: serial@84c0: 'uart-has-rtscts' does not match any of the regexes: 'pinctrl-[0-9]+' amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: audio-controller@5400: 'sound-name-prefix' does not match any of the regexes: 'pinctrl-[0-9]+' amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: audio-controller@c8832000: 'AVDD-supply', 'sound-name-prefix' do not match any f the regexes: 'pinctrl-[0-9]+' amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: bluetooth: clock-names: ['lpo'] is too short amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: bluetooth: clock-names:0: 'txco' was expected amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: bluetooth: clocks: [[23]] is too short amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: bus@c8834000: eth-phy-mux: {'type': 'object'} is not allowed for {'compatible': ['mdio-mux-mmioreg', 'mdio-mux'], '#address-cells': [[1]], '#size-cells': [[0]], 'reg': [[0, 1372, 0, 4]], 'mux-mask': [[4294967295]], 'mdio-parent-bus': [[35]], 'mdio@e40908ff': {'reg': [[3825797375]], '#address-cells': [[1]], '#size-cells': [[0]], 'ethernet-phy@8': {'compatible': ['ethernet-phy-id0181.4400'], 'interrupts': [[0, 9, 4]], 'reg': [[8]], 'max-speed': [[100]], 'phandle': [[36]]}}, 'mdio@2009087f': {'reg': [[537462911]], '#address-cells': [[1]], '#size-cells': [[0]]}} amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: bus@c8834000: rng: {'type': 'object'} is not allowed for {'compatible': ['amlogic,meson-rng'], 'reg': [[0, 0, 0, 4]], 'clocks': [[3, 25]], 'clock-names': ['core']} amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: hdmi-tx@c883a000: 'sound-name-prefix' does not match any of the regexes: pinctrl-[0-9]+' amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: ir@580: linux,rc-map-name:0: 'rc-mecool-kii-pro' is not one of ['rc-adstech-dvb-t-ci', 'rc-alink-dtu-m', 'rc-anysee', 'rc-apac-viewcomp',..., 'rc-zx-irdec'] amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: leds: 'blue' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: serial@84c0: 'bluetooth', 'uart-has-rtscts' do not match any of the regexes: 'pinctrl-0-9]+' amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: 'assigned-clock-parents', 'assigned-clock-rates', 'assigned-clocks' do not atch any of the regexes: '^dai-link-[0-9]+$', 'pinctrl-[0-9]+' amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: 'clocks' is a dependency of 'assigned-clocks' amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: audio-routing: ['AU2 INL', 'ACODEC LOLP', 'AU2 INR', 'ACODEC LORP', AU2 INL', 'ACODEC LOLN', 'AU2 INR', 'ACODEC LORN', 'Lineout', 'AU2 OUTL', 'Lineout', 'AU2 OUTR'] is too long amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: dai-link-0:sound-dai:0: [63, 0, 0] is too long amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: dai-link-0:sound-dai:0:1: missing phandle tag in 0 amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: dai-link-0:sound-dai:0:2: missing phandle tag in 0 amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: dai-link-1:sound-dai:0: [63, 0, 1] is too long amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: dai-link-1:sound-dai:0:1: missing phandle tag in 0 amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: dai-link-1:sound-dai:0:2: missing phandle tag in 1 amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: vpu@d0100000: 'amlogic,canvas' does not match any of the regexes: 'pinctrl-[0-9]+' freescale/imx8-ss-audio.dtsi:16.33-21.4: Warning (simple_bus_reg): /bus@59000000/clock-audio-ipg: missing or empty reg/ranges property freescale/imx8-ss-conn.dtsi:16.31-21.4: Warning (simple_bus_reg): /bus@5b000000/clock-conn-axi: missing or empty reg/ranges property freescale/imx8-ss-conn.dtsi:23.31-28.4: Warning (simple_bus_reg): /bus@5b000000/clock-conn-ahb: missing or empty reg/ranges property freescale/imx8-ss-conn.dtsi:30.31-35.4: Warning (simple_bus_reg): /bus@5b000000/clock-conn-ipg: missing or empty reg/ranges property freescale/imx8-ss-dma.dtsi:16.29-21.4: Warning (simple_bus_reg): /bus@5a000000/clock-dma-ipg: missing or empty reg/ranges property freescale/imx8-ss-lsio.dtsi:16.31-21.4: Warning (simple_bus_reg): /bus@5d000000/clock-lsio-mem: missing or empty reg/ranges property freescale/imx8-ss-lsio.dtsi:23.31-28.4: Warning (simple_bus_reg): /bus@5d000000/clock-lsio-bus: missing or empty reg/ranges property freescale/fsl-lx2160a-clearfog-cx.dt.yaml: ethernet@7: 'sfp' does not match any of the regexes: 'pinctrl-[0-9]+' freescale/fsl-lx2160a-clearfog-cx.dt.yaml: ethernet@8: 'sfp' does not match any of the regexes: 'pinctrl-[0-9]+' freescale/fsl-lx2160a-clearfog-cx.dt.yaml: ethernet@9: 'sfp' does not match any of the regexes: 'pinctrl-[0-9]+' freescale/fsl-lx2160a-clearfog-cx.dt.yaml: ethernet@a: 'sfp' does not match any of the regexes: 'pinctrl-[0-9]+' freescale/fsl-lx2160a-honeycomb.dt.yaml: power-controller@1e34040: '#power-domain-cells' is a required property mediatek/mt8183-pumpkin.dts:35.36-39.5: Warning (unit_address_vs_reg): /reserved-memory/scp_mem_region: node has a reg or ranges property, but no unit name mediatek/mt8183-pumpkin.dts:58.8-64.4: Warning (unit_address_vs_reg): /ntc@0: node has a unit name, but no reg or ranges property mediatek/mt8183.dtsi:1106.26-1112.6: Warning (unit_address_format): /soc/t-phy@11f40000/usb-phy@0700: unit name should not have leading 0s mediatek/mt8183.dtsi:1234.22-1246.5: Warning (avoid_unnecessary_addr_size): /soc/dsi@14014000: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property mediatek/mt8183.dtsi:676.17-795.5: Warning (simple_bus_reg): /soc/thermal-zones: missing or empty reg/ranges property mediatek/mt8183.dtsi:684.30-688.8: Warning (unit_address_vs_reg): /soc/thermal-zones/cpu_thermal/trips/trip-point@0: node has a unit name, but no reg or ranges property mediatek/mt8183-evb.dt.yaml: soc: thermal-zones: {'type': 'object'} is not allowed for {'cpu_thermal': {'polling-delay-passive': [[100]], 'polling-delay': [[500]], 'thermal-sensors': [[41, 0]... 'pinctrl-[0-9]+' mediatek/mt8183-kukui-jacuzzi-damu.dt.yaml: anx7625@58: '#address-cells', '#size-cells', 'panel_flags', 'port@0', 'port@1' do not match any of the regexes: 'pinctrl-[0-9]+' mediatek/mt8183-kukui-jacuzzi-damu.dt.yaml: anx7625@58: 'ports' is a required property mediatek/mt8183-kukui-jacuzzi-damu.dt.yaml: cros_ec: 'mtk,rpmsg-name' does not match any of the regexes: '^#.*', ... qcom/sc7180.dtsi:1204.21-1220.6: Warning (avoid_unnecessary_addr_size): /soc@0/geniqup@ac0000/i2c@a8c000: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property qcom/sc7180.dtsi:965.21-981.6: Warning (avoid_unnecessary_addr_size): /soc@0/geniqup@8c0000/i2c@890000: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property qcom/sdm845.dtsi:3912.23-4045.5: Warning (simple_bus_reg): /soc@0/camss@a00000: simple-bus unit address format error, expected "acb3000" qcom/sdm845.dtsi:4041.10-4044.6: Warning (graph_child_address): /soc@0/camss@a00000/ports: graph node has single child node 'port@0', #address-cells/#size-cells are not necessary qcom/sdm845.dtsi:4102.32-4129.5: Warning (simple_bus_reg): /soc@0/dsi-opp-table: missing or empty reg/ranges property ti/k3-am64-main.dtsi:376.40-385.4: Warning (simple_bus_reg): /bus@f4000/interrupt-controller0: missing or empty reg/ranges property ti/k3-am64-main.dtsi:45.13-135.4: Warning (simple_bus_reg): /bus@f4000/dmss: missing or empty reg/ranges property ti/k3-am64-mcu.dtsi:77.39-86.4: Warning (simple_bus_reg): /bus@f4000/bus@4000000/interrupt-controller1: missing or empty reg/ranges property qcom/msm8916-samsung-a5u-eur.dt.yaml: spmi@200f000: reg: [[33615872, 4096], [37748736, 4194304], [46137344, 4194304], [58720256, 2097152], [33595392, 8448]] is too long qcom/sc7180-trogdor-lazor-r0.dt.yaml: gmu@506a000: compatible:0: 'qcom,adreno-gmu-618.0' is not one of ['qcom,adreno-gmu-630.2'] qcom/sc7180-trogdor-lazor-r1-kb.dt.yaml: memory@80900000: 'device_type' is a required property qcom/sdm850-lenovo-yoga-c630.dt.yaml: memory@97b00000: 'device_type' is a required property renesas/r8a774a1-beacon-rzg2m-kit.dt.yaml: csi2@feaa0000: ports: 'port@0' is a required property renesas/r8a779a0-falcon.dt.yaml: thermal-zones: 'sensor-thermal1', 'sensor-thermal2', 'sensor-thermal3', 'sensor-thermal4', 'sensor-thermal5' do not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-]{1,12}-thermal$', 'pinctrl-[0-9]+' renesas/r8a779a0-falcon.dt.yaml: timer@e61e0000: compatible:0: 'renesas,tmu-r8a779a0' is not one of ['renesas,tmu-r8a7740', 'renesas,tmu-r8a774a1', 'renesas,tmu-r8a774b1', 'renesas,tmu-r8a774c0', 'renesas,tmu-r8a774e1', 'renesas,tmu-r8a7778', 'renesas,tmu-r8a7779', 'renesas,tmu-r8a7795', 'renesas,tmu-r8a7796', 'renesas,tmu-r8a77961', 'renesas,tmu-r8a77965', 'renesas,tmu-r8a77970', 'renesas,tmu-r8a77980', 'renesas,tmu-r8a77990', 'renesas,tmu-r8a77995'] rockchip/rk3399-khadas-edge-v.dt.yaml: usb@fe800000: #address-cells:0:0: 1 was expected ti/k3-am642-evm.dt.yaml: bus@4000000: interrupt-controller1: {'type': 'object'} is not allowed for {'compatible': ['ti,sci-intr'], 'ti,intr-trigger-type': [[1]], 'interrupt-controller': True, 'interrupt-parent': [[1]], '#interrupt-cells': [[1]], 'ti,sci': [[4]], 'ti,sci-dev-id': [[5]], 'ti,interrupt-ranges': [[0, 104, 4]], 'phandle': [[5]]} ti/k3-am642-evm.dt.yaml: bus@f4000: dmss: {'type': 'object'} is not allowed for {'compatible': ['simple-mfd'], '#address-cells': [[2]], '#size-cells': [[2]], 'dma-ranges': True, 'ranges': 'phandle': [[7]]}} ti/k3-am642-evm.dt.yaml: bus@f4000: interrupt-controller0: {'type': 'object'} is not allowed for {'compatible': ['ti,sci-intr'], 'ti,intr-trigger-type': [[1]], 'interrupt-controller': True, 'interrupt-parent': [[1]], '#interrupt-cells': [[1]], 'ti,sci': [[4]], 'ti,sci-dev-id': [[3]], 'ti,interrupt-ranges': [[0, 32, 16]], 'phandle': [[15]]} ti/k3-am642-evm.dt.yaml: flash@0: 'cdns,read-delay', 'cdns,tchsh-ns', 'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not match any of the regexes: '^partition@', 'pinctrl-[0-9]+' ti/k3-am642-sk.dt.yaml: bus@4000000: interrupt-controller1: {'type': 'object'} is not allowed for {'compatible': ['ti,sci-intr'], 'ti,intr-trigger-type': [[1]], ... ti/k3-am642-sk.dt.yaml: bus@f4000: dmss: {'type': 'object'} is not allowed for {'compatible': ['simple-mfd'], ... ti/k3-am642-sk.dt.yaml: bus@f4000: interrupt-controller0: {'type': 'object'} is not allowed for {'compatible': ['ti,sci-intr'], 'ti,intr-trigger-type': [[1]], 'interrupt-controller': True, 'interrupt-parent': [[1]], '#interrupt-cells': [[1]], 'ti,sci': [[4]], 'ti,sci-dev-id': [[3]], 'ti,interrupt-ranges': [[0, 32, 16]], 'phandle': [[11]]} ti/k3-am642-sk.dt.yaml: flash@0: 'cdns,read-delay', 'cdns,tchsh-ns', 'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not match any of the regexes: '^partition@', 'pinctrl-[0-9]+' ti/k3-j7200-common-proc-board.dt.yaml: flash@0: 'cdns,read-delay', 'cdns,tchsh-ns', 'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not match any of the regexes: '^partition@', 'pinctrl-[0-9]+' _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: New 'make dtbs_check W=1' warnings @ 2021-04-08 15:25 ` Alexandre Belloni 0 siblings, 0 replies; 28+ messages in thread From: Alexandre Belloni @ 2021-04-08 15:25 UTC (permalink / raw) To: Arnd Bergmann Cc: DTML, Rob Herring, Linus Walleij, Alexandre Torgue, Kevin Hilman, Linux Kernel Mailing List, Linux ARM, Tony Lindgren, Shawn Guo, Matthias Brugger, Bjorn Andersson, Geert Uytterhoeven, Nishanth Menon, Tero Kristo, SoC Team, Krzysztof Kozlowski, Gregory Clement, Florian Fainelli Hi, On 08/04/2021 17:08:26+0200, Arnd Bergmann wrote: > arch/arm/boot/dts/at91-sama5d2_ptc_ek.dt.yaml: /: 'etm@73C000' does > not match any of the regexes: '@(0|[1-9a-f][0-9a-f]*)$', '^[^@]+$', > 'pinctrl-[0-9]+' > arch/arm/boot/dts/at91-kizbox3-hs.dt.yaml: /: 'etm@73C000' does not > match any of the regexes: '@(0|[1-9a-f][0-9a-f]*)$', '^[^@]+$', > 'pinctrl-[0-9]+' > This was introduced by 4d930c421e3b ("ARM: dts: at91: sama5d2: add ETB and ETM unit name"), trying to fix another warning. I guess this is because Documentation/devicetree/bindings/arm/coresight.txt is not yaml yet. -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: New 'make dtbs_check W=1' warnings @ 2021-04-08 15:25 ` Alexandre Belloni 0 siblings, 0 replies; 28+ messages in thread From: Alexandre Belloni @ 2021-04-08 15:25 UTC (permalink / raw) To: Arnd Bergmann Cc: DTML, Rob Herring, Linus Walleij, Alexandre Torgue, Kevin Hilman, Linux Kernel Mailing List, Linux ARM, Tony Lindgren, Shawn Guo, Matthias Brugger, Bjorn Andersson, Geert Uytterhoeven, Nishanth Menon, Tero Kristo, SoC Team, Krzysztof Kozlowski, Gregory Clement, Florian Fainelli Hi, On 08/04/2021 17:08:26+0200, Arnd Bergmann wrote: > arch/arm/boot/dts/at91-sama5d2_ptc_ek.dt.yaml: /: 'etm@73C000' does > not match any of the regexes: '@(0|[1-9a-f][0-9a-f]*)$', '^[^@]+$', > 'pinctrl-[0-9]+' > arch/arm/boot/dts/at91-kizbox3-hs.dt.yaml: /: 'etm@73C000' does not > match any of the regexes: '@(0|[1-9a-f][0-9a-f]*)$', '^[^@]+$', > 'pinctrl-[0-9]+' > This was introduced by 4d930c421e3b ("ARM: dts: at91: sama5d2: add ETB and ETM unit name"), trying to fix another warning. I guess this is because Documentation/devicetree/bindings/arm/coresight.txt is not yaml yet. -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: New 'make dtbs_check W=1' warnings @ 2021-04-08 23:59 ` Rob Herring 0 siblings, 0 replies; 28+ messages in thread From: Rob Herring @ 2021-04-08 23:59 UTC (permalink / raw) To: Alexandre Belloni Cc: Arnd Bergmann, DTML, Linus Walleij, Alexandre Torgue, Kevin Hilman, Linux Kernel Mailing List, Linux ARM, Tony Lindgren, Shawn Guo, Matthias Brugger, Bjorn Andersson, Geert Uytterhoeven, Nishanth Menon, Tero Kristo, SoC Team, Krzysztof Kozlowski, Gregory Clement, Florian Fainelli On Thu, Apr 8, 2021 at 10:25 AM Alexandre Belloni <alexandre.belloni@bootlin.com> wrote: > > Hi, > > On 08/04/2021 17:08:26+0200, Arnd Bergmann wrote: > > arch/arm/boot/dts/at91-sama5d2_ptc_ek.dt.yaml: /: 'etm@73C000' does > > not match any of the regexes: '@(0|[1-9a-f][0-9a-f]*)$', '^[^@]+$', > > 'pinctrl-[0-9]+' > > arch/arm/boot/dts/at91-kizbox3-hs.dt.yaml: /: 'etm@73C000' does not > > match any of the regexes: '@(0|[1-9a-f][0-9a-f]*)$', '^[^@]+$', > > 'pinctrl-[0-9]+' > > > > This was introduced by 4d930c421e3b ("ARM: dts: at91: sama5d2: add ETB > and ETM unit name"), trying to fix another warning. > > I guess this is because > Documentation/devicetree/bindings/arm/coresight.txt is not yaml yet. No, I believe it's from the uppercase hex. Rob ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: New 'make dtbs_check W=1' warnings @ 2021-04-08 23:59 ` Rob Herring 0 siblings, 0 replies; 28+ messages in thread From: Rob Herring @ 2021-04-08 23:59 UTC (permalink / raw) To: Alexandre Belloni Cc: Arnd Bergmann, DTML, Linus Walleij, Alexandre Torgue, Kevin Hilman, Linux Kernel Mailing List, Linux ARM, Tony Lindgren, Shawn Guo, Matthias Brugger, Bjorn Andersson, Geert Uytterhoeven, Nishanth Menon, Tero Kristo, SoC Team, Krzysztof Kozlowski, Gregory Clement, Florian Fainelli On Thu, Apr 8, 2021 at 10:25 AM Alexandre Belloni <alexandre.belloni@bootlin.com> wrote: > > Hi, > > On 08/04/2021 17:08:26+0200, Arnd Bergmann wrote: > > arch/arm/boot/dts/at91-sama5d2_ptc_ek.dt.yaml: /: 'etm@73C000' does > > not match any of the regexes: '@(0|[1-9a-f][0-9a-f]*)$', '^[^@]+$', > > 'pinctrl-[0-9]+' > > arch/arm/boot/dts/at91-kizbox3-hs.dt.yaml: /: 'etm@73C000' does not > > match any of the regexes: '@(0|[1-9a-f][0-9a-f]*)$', '^[^@]+$', > > 'pinctrl-[0-9]+' > > > > This was introduced by 4d930c421e3b ("ARM: dts: at91: sama5d2: add ETB > and ETM unit name"), trying to fix another warning. > > I guess this is because > Documentation/devicetree/bindings/arm/coresight.txt is not yaml yet. No, I believe it's from the uppercase hex. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: New 'make dtbs_check W=1' warnings @ 2021-04-08 19:25 ` Krzysztof Kozlowski 0 siblings, 0 replies; 28+ messages in thread From: Krzysztof Kozlowski @ 2021-04-08 19:25 UTC (permalink / raw) To: Arnd Bergmann, DTML, Rob Herring Cc: Linus Walleij, Alexandre Belloni, Alexandre Torgue, Kevin Hilman, Linux Kernel Mailing List, Linux ARM, Tony Lindgren, Shawn Guo, Matthias Brugger, Bjorn Andersson, Geert Uytterhoeven, Nishanth Menon, Tero Kristo, SoC Team, Gregory Clement, Florian Fainelli On 08/04/2021 17:08, Arnd Bergmann wrote: > Greetings to all Arm platform maintainers, > > I've just gone through the DT merges I've received so far and, with a > little help from Rob, > managed to run 'make dtbs_check W=1' before and after, to see what > warnings we get. > The good news is that the number of warnings is going down, but > unfortunately there > is still an unmanageable amount of remaining warnings, and some new > ones crept in. > > I'm still working on my tooling for this, to catch these better, but > ideally I think we should > try to not introduce new warnings. I think some platforms are already > clean, and I did > not see any new warnings for mvebu, samsung and broadcom. There were a lot of > warnings from .dtsi files, and I probably did an incomplete job at > deduplicating those. > > See below for the other platforms, and the new warnings that I found. > If these are > valid, please send a fixup before the merge window, and let me know if > you have ideas > for how we should handle these in the future. > > For this merge window, I don't think any of them are show-stoppers (Rob, let me > know if you disagree), but in the long run we may want to gradually enforce > a rule about not merging changes that introduce any new warnings, in order to > have a chance of cleaning up the existing ones. +1 for such rule, although the best would be to get a report about new warnings on posted patches or shortly after applying, e.g. via 0-day kbuild robot. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: New 'make dtbs_check W=1' warnings @ 2021-04-08 19:25 ` Krzysztof Kozlowski 0 siblings, 0 replies; 28+ messages in thread From: Krzysztof Kozlowski @ 2021-04-08 19:25 UTC (permalink / raw) To: Arnd Bergmann, DTML, Rob Herring Cc: Linus Walleij, Alexandre Belloni, Alexandre Torgue, Kevin Hilman, Linux Kernel Mailing List, Linux ARM, Tony Lindgren, Shawn Guo, Matthias Brugger, Bjorn Andersson, Geert Uytterhoeven, Nishanth Menon, Tero Kristo, SoC Team, Gregory Clement, Florian Fainelli On 08/04/2021 17:08, Arnd Bergmann wrote: > Greetings to all Arm platform maintainers, > > I've just gone through the DT merges I've received so far and, with a > little help from Rob, > managed to run 'make dtbs_check W=1' before and after, to see what > warnings we get. > The good news is that the number of warnings is going down, but > unfortunately there > is still an unmanageable amount of remaining warnings, and some new > ones crept in. > > I'm still working on my tooling for this, to catch these better, but > ideally I think we should > try to not introduce new warnings. I think some platforms are already > clean, and I did > not see any new warnings for mvebu, samsung and broadcom. There were a lot of > warnings from .dtsi files, and I probably did an incomplete job at > deduplicating those. > > See below for the other platforms, and the new warnings that I found. > If these are > valid, please send a fixup before the merge window, and let me know if > you have ideas > for how we should handle these in the future. > > For this merge window, I don't think any of them are show-stoppers (Rob, let me > know if you disagree), but in the long run we may want to gradually enforce > a rule about not merging changes that introduce any new warnings, in order to > have a chance of cleaning up the existing ones. +1 for such rule, although the best would be to get a report about new warnings on posted patches or shortly after applying, e.g. via 0-day kbuild robot. Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: New 'make dtbs_check W=1' warnings 2021-04-08 15:08 ` Arnd Bergmann (?) @ 2021-04-08 22:11 ` Linus Walleij -1 siblings, 0 replies; 28+ messages in thread From: Linus Walleij @ 2021-04-08 22:11 UTC (permalink / raw) To: Arnd Bergmann, Jonathan Cameron Cc: DTML, Rob Herring, Linus Walleij, Alexandre Belloni, Alexandre Torgue, Kevin Hilman, Linux Kernel Mailing List, Linux ARM, Tony Lindgren, Shawn Guo, Matthias Brugger, Bjorn Andersson, Geert Uytterhoeven, Nishanth Menon, Tero Kristo, SoC Team, Krzysztof Kozlowski, Gregory Clement, Florian Fainelli On Thu, Apr 8, 2021 at 5:08 PM Arnd Bergmann <arnd@kernel.org> wrote: > arch/arm/boot/dts/ste-href520-tvk.dt.yaml: accelerometer@19: > interrupts: [[18, 1], [19, 1]] is too long > arch/arm/boot/dts/ste-hrefprev60-tvk.dt.yaml: gyroscope@68: > interrupts-extended: [[22, 0, 1], [21, 31, 1]] is too long > arch/arm/boot/dts/ste-hrefv60plus-tvk.dt.yaml: gyroscope@68: > interrupts-extended: [[25, 0, 1], [24, 31, 1]] is too long > arch/arm/boot/dts/ste-hrefv60plus-tvk.dt.yaml: accelerometer@1c: > interrupts: [[18, 1], [19, 1]] is too long These warnings are all because the bindings in Documentation/devicetree/bindings/iio/st,st-sensors.yaml are slightly incorrect. Several sensors have more than 1 IRQ. I was working on a refined version of the bindings but got sidetracked. https://lore.kernel.org/linux-iio/20210104093343.2134410-1-linus.walleij@linaro.org/ I'll try to get to it. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: New 'make dtbs_check W=1' warnings @ 2021-04-08 22:11 ` Linus Walleij 0 siblings, 0 replies; 28+ messages in thread From: Linus Walleij @ 2021-04-08 22:11 UTC (permalink / raw) To: Arnd Bergmann, Jonathan Cameron Cc: DTML, Rob Herring, Linus Walleij, Alexandre Belloni, Alexandre Torgue, Kevin Hilman, Linux Kernel Mailing List, Linux ARM, Tony Lindgren, Shawn Guo, Matthias Brugger, Bjorn Andersson, Geert Uytterhoeven, Nishanth Menon, Tero Kristo, SoC Team, Krzysztof Kozlowski, Gregory Clement, Florian Fainelli On Thu, Apr 8, 2021 at 5:08 PM Arnd Bergmann <arnd@kernel.org> wrote: > arch/arm/boot/dts/ste-href520-tvk.dt.yaml: accelerometer@19: > interrupts: [[18, 1], [19, 1]] is too long > arch/arm/boot/dts/ste-hrefprev60-tvk.dt.yaml: gyroscope@68: > interrupts-extended: [[22, 0, 1], [21, 31, 1]] is too long > arch/arm/boot/dts/ste-hrefv60plus-tvk.dt.yaml: gyroscope@68: > interrupts-extended: [[25, 0, 1], [24, 31, 1]] is too long > arch/arm/boot/dts/ste-hrefv60plus-tvk.dt.yaml: accelerometer@1c: > interrupts: [[18, 1], [19, 1]] is too long These warnings are all because the bindings in Documentation/devicetree/bindings/iio/st,st-sensors.yaml are slightly incorrect. Several sensors have more than 1 IRQ. I was working on a refined version of the bindings but got sidetracked. https://lore.kernel.org/linux-iio/20210104093343.2134410-1-linus.walleij@linaro.org/ I'll try to get to it. Yours, Linus Walleij _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: New 'make dtbs_check W=1' warnings @ 2021-04-08 22:11 ` Linus Walleij 0 siblings, 0 replies; 28+ messages in thread From: Linus Walleij @ 2021-04-08 22:11 UTC (permalink / raw) To: Arnd Bergmann, Jonathan Cameron Cc: DTML, Rob Herring, Linus Walleij, Alexandre Belloni, Alexandre Torgue, Kevin Hilman, Linux Kernel Mailing List, Linux ARM, Tony Lindgren, Shawn Guo, Matthias Brugger, Bjorn Andersson, Geert Uytterhoeven, Nishanth Menon, Tero Kristo, SoC Team, Krzysztof Kozlowski, Gregory Clement, Florian Fainelli On Thu, Apr 8, 2021 at 5:08 PM Arnd Bergmann <arnd@kernel.org> wrote: > arch/arm/boot/dts/ste-href520-tvk.dt.yaml: accelerometer@19: > interrupts: [[18, 1], [19, 1]] is too long > arch/arm/boot/dts/ste-hrefprev60-tvk.dt.yaml: gyroscope@68: > interrupts-extended: [[22, 0, 1], [21, 31, 1]] is too long > arch/arm/boot/dts/ste-hrefv60plus-tvk.dt.yaml: gyroscope@68: > interrupts-extended: [[25, 0, 1], [24, 31, 1]] is too long > arch/arm/boot/dts/ste-hrefv60plus-tvk.dt.yaml: accelerometer@1c: > interrupts: [[18, 1], [19, 1]] is too long These warnings are all because the bindings in Documentation/devicetree/bindings/iio/st,st-sensors.yaml are slightly incorrect. Several sensors have more than 1 IRQ. I was working on a refined version of the bindings but got sidetracked. https://lore.kernel.org/linux-iio/20210104093343.2134410-1-linus.walleij@linaro.org/ I'll try to get to it. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: New 'make dtbs_check W=1' warnings @ 2021-04-09 3:37 ` Florian Fainelli 0 siblings, 0 replies; 28+ messages in thread From: Florian Fainelli @ 2021-04-09 3:37 UTC (permalink / raw) To: Arnd Bergmann, DTML, Rob Herring, Rafał Miłecki Cc: Linus Walleij, Alexandre Belloni, Alexandre Torgue, Kevin Hilman, Linux Kernel Mailing List, Linux ARM, Tony Lindgren, Shawn Guo, Matthias Brugger, Bjorn Andersson, Geert Uytterhoeven, Nishanth Menon, Tero Kristo, SoC Team, Krzysztof Kozlowski, Gregory Clement On 4/8/2021 8:08 AM, Arnd Bergmann wrote: > Greetings to all Arm platform maintainers, > > I've just gone through the DT merges I've received so far and, with a > little help from Rob, > managed to run 'make dtbs_check W=1' before and after, to see what > warnings we get. > The good news is that the number of warnings is going down, but > unfortunately there > is still an unmanageable amount of remaining warnings, and some new > ones crept in. > > I'm still working on my tooling for this, to catch these better, but > ideally I think we should > try to not introduce new warnings. I think some platforms are already > clean, and I did > not see any new warnings for mvebu, samsung and broadcom. There were a lot of > warnings from .dtsi files, and I probably did an incomplete job at > deduplicating those. There are definitively a ton of warnings for Broacom DTS files, a number of those warnings exist because the bindings were not converted to YAML. Rafal, do you think you could help me with taking care of the BCM5301X/4908 warnings? -- Florian ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: New 'make dtbs_check W=1' warnings @ 2021-04-09 3:37 ` Florian Fainelli 0 siblings, 0 replies; 28+ messages in thread From: Florian Fainelli @ 2021-04-09 3:37 UTC (permalink / raw) To: Arnd Bergmann, DTML, Rob Herring, Rafał Miłecki Cc: Linus Walleij, Alexandre Belloni, Alexandre Torgue, Kevin Hilman, Linux Kernel Mailing List, Linux ARM, Tony Lindgren, Shawn Guo, Matthias Brugger, Bjorn Andersson, Geert Uytterhoeven, Nishanth Menon, Tero Kristo, SoC Team, Krzysztof Kozlowski, Gregory Clement On 4/8/2021 8:08 AM, Arnd Bergmann wrote: > Greetings to all Arm platform maintainers, > > I've just gone through the DT merges I've received so far and, with a > little help from Rob, > managed to run 'make dtbs_check W=1' before and after, to see what > warnings we get. > The good news is that the number of warnings is going down, but > unfortunately there > is still an unmanageable amount of remaining warnings, and some new > ones crept in. > > I'm still working on my tooling for this, to catch these better, but > ideally I think we should > try to not introduce new warnings. I think some platforms are already > clean, and I did > not see any new warnings for mvebu, samsung and broadcom. There were a lot of > warnings from .dtsi files, and I probably did an incomplete job at > deduplicating those. There are definitively a ton of warnings for Broacom DTS files, a number of those warnings exist because the bindings were not converted to YAML. Rafal, do you think you could help me with taking care of the BCM5301X/4908 warnings? -- Florian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: New 'make dtbs_check W=1' warnings @ 2021-04-09 5:27 ` Rafał Miłecki 0 siblings, 0 replies; 28+ messages in thread From: Rafał Miłecki @ 2021-04-09 5:27 UTC (permalink / raw) To: Florian Fainelli Cc: Arnd Bergmann, DTML, Rob Herring, Linus Walleij, Alexandre Belloni, Alexandre Torgue, Kevin Hilman, Linux Kernel Mailing List, Linux ARM, Tony Lindgren, Shawn Guo, Matthias Brugger, Bjorn Andersson, Geert Uytterhoeven, Nishanth Menon, Tero Kristo, SoC Team, Krzysztof Kozlowski, Gregory Clement On 2021-04-09 05:37, Florian Fainelli wrote: > On 4/8/2021 8:08 AM, Arnd Bergmann wrote: >> Greetings to all Arm platform maintainers, >> >> I've just gone through the DT merges I've received so far and, with a >> little help from Rob, >> managed to run 'make dtbs_check W=1' before and after, to see what >> warnings we get. >> The good news is that the number of warnings is going down, but >> unfortunately there >> is still an unmanageable amount of remaining warnings, and some new >> ones crept in. >> >> I'm still working on my tooling for this, to catch these better, but >> ideally I think we should >> try to not introduce new warnings. I think some platforms are already >> clean, and I did >> not see any new warnings for mvebu, samsung and broadcom. There were a >> lot of >> warnings from .dtsi files, and I probably did an incomplete job at >> deduplicating those. > > There are definitively a ton of warnings for Broacom DTS files, a > number > of those warnings exist because the bindings were not converted to > YAML. > Rafal, do you think you could help me with taking care of the > BCM5301X/4908 warnings? Sure, I got rid of one or two warnings already, I'll keep working on that. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: New 'make dtbs_check W=1' warnings @ 2021-04-09 5:27 ` Rafał Miłecki 0 siblings, 0 replies; 28+ messages in thread From: Rafał Miłecki @ 2021-04-09 5:27 UTC (permalink / raw) To: Florian Fainelli Cc: Arnd Bergmann, DTML, Rob Herring, Linus Walleij, Alexandre Belloni, Alexandre Torgue, Kevin Hilman, Linux Kernel Mailing List, Linux ARM, Tony Lindgren, Shawn Guo, Matthias Brugger, Bjorn Andersson, Geert Uytterhoeven, Nishanth Menon, Tero Kristo, SoC Team, Krzysztof Kozlowski, Gregory Clement On 2021-04-09 05:37, Florian Fainelli wrote: > On 4/8/2021 8:08 AM, Arnd Bergmann wrote: >> Greetings to all Arm platform maintainers, >> >> I've just gone through the DT merges I've received so far and, with a >> little help from Rob, >> managed to run 'make dtbs_check W=1' before and after, to see what >> warnings we get. >> The good news is that the number of warnings is going down, but >> unfortunately there >> is still an unmanageable amount of remaining warnings, and some new >> ones crept in. >> >> I'm still working on my tooling for this, to catch these better, but >> ideally I think we should >> try to not introduce new warnings. I think some platforms are already >> clean, and I did >> not see any new warnings for mvebu, samsung and broadcom. There were a >> lot of >> warnings from .dtsi files, and I probably did an incomplete job at >> deduplicating those. > > There are definitively a ton of warnings for Broacom DTS files, a > number > of those warnings exist because the bindings were not converted to > YAML. > Rafal, do you think you could help me with taking care of the > BCM5301X/4908 warnings? Sure, I got rid of one or two warnings already, I'll keep working on that. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: New 'make dtbs_check W=1' warnings 2021-04-08 15:08 ` Arnd Bergmann (?) @ 2021-04-12 11:32 ` Geert Uytterhoeven -1 siblings, 0 replies; 28+ messages in thread From: Geert Uytterhoeven @ 2021-04-12 11:32 UTC (permalink / raw) To: Arnd Bergmann Cc: DTML, Rob Herring, Linus Walleij, Alexandre Belloni, Alexandre Torgue, Kevin Hilman, Linux Kernel Mailing List, Linux ARM, Tony Lindgren, Shawn Guo, Matthias Brugger, Bjorn Andersson, Nishanth Menon, Tero Kristo, SoC Team, Krzysztof Kozlowski, Gregory Clement, Florian Fainelli Hi Arnd, On Thu, Apr 8, 2021 at 5:08 PM Arnd Bergmann <arnd@kernel.org> wrote: > I've just gone through the DT merges I've received so far and, with a > little help from Rob, > managed to run 'make dtbs_check W=1' before and after, to see what > warnings we get. > The good news is that the number of warnings is going down, but > unfortunately there > is still an unmanageable amount of remaining warnings, and some new > ones crept in. > > I'm still working on my tooling for this, to catch these better, but > ideally I think we should > try to not introduce new warnings. I think some platforms are already > clean, and I did > not see any new warnings for mvebu, samsung and broadcom. There were a lot of > warnings from .dtsi files, and I probably did an incomplete job at > deduplicating those. Thanks for running these checks! > See below for the other platforms, and the new warnings that I found. > If these are > valid, please send a fixup before the merge window, and let me know if > you have ideas > for how we should handle these in the future. > > For this merge window, I don't think any of them are show-stoppers (Rob, let me > know if you disagree), but in the long run we may want to gradually enforce > a rule about not merging changes that introduce any new warnings, in order to > have a chance of cleaning up the existing ones. This may not be as simple as it sounds, as DT binding updates typically follow a different path than DTS(i) updates. DT bindings updates may be picked up by a subsystem maintainer, by Rob, or by the platform maintainer. For trivial updates (e.g. adding a compatible value, and sometimes extending a limit), a DTS(i) update may be accepted by the platform maintainer before the corresponding DT binding update. The latter may even be merged one or more kernel revisions later, especially when involving subsystems that are not traditionally rooted into platforms using DT. Of course we could mention any expected warning regressions in our pull requests for soc. > renesas/r8a774a1-beacon-rzg2m-kit.dt.yaml: csi2@feaa0000: ports: > 'port@0' is a required property [...] I've replied to these as a response to your PR reply, see https://lore.kernel.org/linux-renesas-soc/CAMuHMdWHLnXgBSjP7VKUdx-YNr9rSKFkE5Ge5q_tarU6HP9Lhw@mail.gmail.com/ Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: New 'make dtbs_check W=1' warnings @ 2021-04-12 11:32 ` Geert Uytterhoeven 0 siblings, 0 replies; 28+ messages in thread From: Geert Uytterhoeven @ 2021-04-12 11:32 UTC (permalink / raw) To: Arnd Bergmann Cc: DTML, Rob Herring, Linus Walleij, Alexandre Belloni, Alexandre Torgue, Kevin Hilman, Linux Kernel Mailing List, Linux ARM, Tony Lindgren, Shawn Guo, Matthias Brugger, Bjorn Andersson, Nishanth Menon, Tero Kristo, SoC Team, Krzysztof Kozlowski, Gregory Clement, Florian Fainelli Hi Arnd, On Thu, Apr 8, 2021 at 5:08 PM Arnd Bergmann <arnd@kernel.org> wrote: > I've just gone through the DT merges I've received so far and, with a > little help from Rob, > managed to run 'make dtbs_check W=1' before and after, to see what > warnings we get. > The good news is that the number of warnings is going down, but > unfortunately there > is still an unmanageable amount of remaining warnings, and some new > ones crept in. > > I'm still working on my tooling for this, to catch these better, but > ideally I think we should > try to not introduce new warnings. I think some platforms are already > clean, and I did > not see any new warnings for mvebu, samsung and broadcom. There were a lot of > warnings from .dtsi files, and I probably did an incomplete job at > deduplicating those. Thanks for running these checks! > See below for the other platforms, and the new warnings that I found. > If these are > valid, please send a fixup before the merge window, and let me know if > you have ideas > for how we should handle these in the future. > > For this merge window, I don't think any of them are show-stoppers (Rob, let me > know if you disagree), but in the long run we may want to gradually enforce > a rule about not merging changes that introduce any new warnings, in order to > have a chance of cleaning up the existing ones. This may not be as simple as it sounds, as DT binding updates typically follow a different path than DTS(i) updates. DT bindings updates may be picked up by a subsystem maintainer, by Rob, or by the platform maintainer. For trivial updates (e.g. adding a compatible value, and sometimes extending a limit), a DTS(i) update may be accepted by the platform maintainer before the corresponding DT binding update. The latter may even be merged one or more kernel revisions later, especially when involving subsystems that are not traditionally rooted into platforms using DT. Of course we could mention any expected warning regressions in our pull requests for soc. > renesas/r8a774a1-beacon-rzg2m-kit.dt.yaml: csi2@feaa0000: ports: > 'port@0' is a required property [...] I've replied to these as a response to your PR reply, see https://lore.kernel.org/linux-renesas-soc/CAMuHMdWHLnXgBSjP7VKUdx-YNr9rSKFkE5Ge5q_tarU6HP9Lhw@mail.gmail.com/ Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: New 'make dtbs_check W=1' warnings @ 2021-04-12 11:32 ` Geert Uytterhoeven 0 siblings, 0 replies; 28+ messages in thread From: Geert Uytterhoeven @ 2021-04-12 11:32 UTC (permalink / raw) To: Arnd Bergmann Cc: DTML, Rob Herring, Linus Walleij, Alexandre Belloni, Alexandre Torgue, Kevin Hilman, Linux Kernel Mailing List, Linux ARM, Tony Lindgren, Shawn Guo, Matthias Brugger, Bjorn Andersson, Nishanth Menon, Tero Kristo, SoC Team, Krzysztof Kozlowski, Gregory Clement, Florian Fainelli Hi Arnd, On Thu, Apr 8, 2021 at 5:08 PM Arnd Bergmann <arnd@kernel.org> wrote: > I've just gone through the DT merges I've received so far and, with a > little help from Rob, > managed to run 'make dtbs_check W=1' before and after, to see what > warnings we get. > The good news is that the number of warnings is going down, but > unfortunately there > is still an unmanageable amount of remaining warnings, and some new > ones crept in. > > I'm still working on my tooling for this, to catch these better, but > ideally I think we should > try to not introduce new warnings. I think some platforms are already > clean, and I did > not see any new warnings for mvebu, samsung and broadcom. There were a lot of > warnings from .dtsi files, and I probably did an incomplete job at > deduplicating those. Thanks for running these checks! > See below for the other platforms, and the new warnings that I found. > If these are > valid, please send a fixup before the merge window, and let me know if > you have ideas > for how we should handle these in the future. > > For this merge window, I don't think any of them are show-stoppers (Rob, let me > know if you disagree), but in the long run we may want to gradually enforce > a rule about not merging changes that introduce any new warnings, in order to > have a chance of cleaning up the existing ones. This may not be as simple as it sounds, as DT binding updates typically follow a different path than DTS(i) updates. DT bindings updates may be picked up by a subsystem maintainer, by Rob, or by the platform maintainer. For trivial updates (e.g. adding a compatible value, and sometimes extending a limit), a DTS(i) update may be accepted by the platform maintainer before the corresponding DT binding update. The latter may even be merged one or more kernel revisions later, especially when involving subsystems that are not traditionally rooted into platforms using DT. Of course we could mention any expected warning regressions in our pull requests for soc. > renesas/r8a774a1-beacon-rzg2m-kit.dt.yaml: csi2@feaa0000: ports: > 'port@0' is a required property [...] I've replied to these as a response to your PR reply, see https://lore.kernel.org/linux-renesas-soc/CAMuHMdWHLnXgBSjP7VKUdx-YNr9rSKFkE5Ge5q_tarU6HP9Lhw@mail.gmail.com/ Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: New 'make dtbs_check W=1' warnings @ 2021-04-12 13:14 ` Arnd Bergmann 0 siblings, 0 replies; 28+ messages in thread From: Arnd Bergmann @ 2021-04-12 13:14 UTC (permalink / raw) To: Geert Uytterhoeven Cc: DTML, Rob Herring, Linus Walleij, Alexandre Belloni, Alexandre Torgue, Kevin Hilman, Linux Kernel Mailing List, Linux ARM, Tony Lindgren, Shawn Guo, Matthias Brugger, Bjorn Andersson, Nishanth Menon, Tero Kristo, SoC Team, Krzysztof Kozlowski, Gregory Clement, Florian Fainelli On Mon, Apr 12, 2021 at 1:32 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Thu, Apr 8, 2021 at 5:08 PM Arnd Bergmann <arnd@kernel.org> wrote: > > > > For this merge window, I don't think any of them are show-stoppers (Rob, let me > > know if you disagree), but in the long run we may want to gradually enforce > > a rule about not merging changes that introduce any new warnings, in order to > > have a chance of cleaning up the existing ones. > > This may not be as simple as it sounds, as DT binding updates typically > follow a different path than DTS(i) updates. DT bindings updates may be > picked up by a subsystem maintainer, by Rob, or by the platform > maintainer. I checked out the bindings from linux-next, which seems to have covered most of these. Sometimes it pays off to be lazy and merge them after everyone else. > For trivial updates (e.g. adding a compatible value, and sometimes > extending a limit), a DTS(i) update may be accepted by the platform > maintainer before the corresponding DT binding update. The latter may > even be merged one or more kernel revisions later, especially when > involving subsystems that are not traditionally rooted into platforms > using DT. > > Of course we could mention any expected warning regressions in our pull > requests for soc. Right, that would certainly help. Some maintainers send all binding updates both to the driver maintainers and to the soc tree, along with the other changes that only go into one tree. That is of course also more work on your side, but it solves the problem entirely. > > renesas/r8a774a1-beacon-rzg2m-kit.dt.yaml: csi2@feaa0000: ports: > > 'port@0' is a required property > > [...] > > I've replied to these as a response to your PR reply, see > https://lore.kernel.org/linux-renesas-soc/CAMuHMdWHLnXgBSjP7VKUdx-YNr9rSKFkE5Ge5q_tarU6HP9Lhw@mail.gmail.com/ Ok, thanks. Arnd ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: New 'make dtbs_check W=1' warnings @ 2021-04-12 13:14 ` Arnd Bergmann 0 siblings, 0 replies; 28+ messages in thread From: Arnd Bergmann @ 2021-04-12 13:14 UTC (permalink / raw) To: Geert Uytterhoeven Cc: DTML, Rob Herring, Linus Walleij, Alexandre Belloni, Alexandre Torgue, Kevin Hilman, Linux Kernel Mailing List, Linux ARM, Tony Lindgren, Shawn Guo, Matthias Brugger, Bjorn Andersson, Nishanth Menon, Tero Kristo, SoC Team, Krzysztof Kozlowski, Gregory Clement, Florian Fainelli On Mon, Apr 12, 2021 at 1:32 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Thu, Apr 8, 2021 at 5:08 PM Arnd Bergmann <arnd@kernel.org> wrote: > > > > For this merge window, I don't think any of them are show-stoppers (Rob, let me > > know if you disagree), but in the long run we may want to gradually enforce > > a rule about not merging changes that introduce any new warnings, in order to > > have a chance of cleaning up the existing ones. > > This may not be as simple as it sounds, as DT binding updates typically > follow a different path than DTS(i) updates. DT bindings updates may be > picked up by a subsystem maintainer, by Rob, or by the platform > maintainer. I checked out the bindings from linux-next, which seems to have covered most of these. Sometimes it pays off to be lazy and merge them after everyone else. > For trivial updates (e.g. adding a compatible value, and sometimes > extending a limit), a DTS(i) update may be accepted by the platform > maintainer before the corresponding DT binding update. The latter may > even be merged one or more kernel revisions later, especially when > involving subsystems that are not traditionally rooted into platforms > using DT. > > Of course we could mention any expected warning regressions in our pull > requests for soc. Right, that would certainly help. Some maintainers send all binding updates both to the driver maintainers and to the soc tree, along with the other changes that only go into one tree. That is of course also more work on your side, but it solves the problem entirely. > > renesas/r8a774a1-beacon-rzg2m-kit.dt.yaml: csi2@feaa0000: ports: > > 'port@0' is a required property > > [...] > > I've replied to these as a response to your PR reply, see > https://lore.kernel.org/linux-renesas-soc/CAMuHMdWHLnXgBSjP7VKUdx-YNr9rSKFkE5Ge5q_tarU6HP9Lhw@mail.gmail.com/ Ok, thanks. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: New 'make dtbs_check W=1' warnings @ 2021-04-12 16:01 ` Bjorn Andersson 0 siblings, 0 replies; 28+ messages in thread From: Bjorn Andersson @ 2021-04-12 16:01 UTC (permalink / raw) To: Arnd Bergmann Cc: Geert Uytterhoeven, DTML, Rob Herring, Linus Walleij, Alexandre Belloni, Alexandre Torgue, Kevin Hilman, Linux Kernel Mailing List, Linux ARM, Tony Lindgren, Shawn Guo, Matthias Brugger, Nishanth Menon, Tero Kristo, SoC Team, Krzysztof Kozlowski, Gregory Clement, Florian Fainelli On Mon 12 Apr 08:14 CDT 2021, Arnd Bergmann wrote: > On Mon, Apr 12, 2021 at 1:32 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > On Thu, Apr 8, 2021 at 5:08 PM Arnd Bergmann <arnd@kernel.org> wrote: > > > > > > > For this merge window, I don't think any of them are show-stoppers (Rob, let me > > > know if you disagree), but in the long run we may want to gradually enforce > > > a rule about not merging changes that introduce any new warnings, in order to > > > have a chance of cleaning up the existing ones. > > > > This may not be as simple as it sounds, as DT binding updates typically > > follow a different path than DTS(i) updates. DT bindings updates may be > > picked up by a subsystem maintainer, by Rob, or by the platform > > maintainer. > > I checked out the bindings from linux-next, which seems to have covered > most of these. Sometimes it pays off to be lazy and merge them after > everyone else. > > > For trivial updates (e.g. adding a compatible value, and sometimes > > extending a limit), a DTS(i) update may be accepted by the platform > > maintainer before the corresponding DT binding update. The latter may > > even be merged one or more kernel revisions later, especially when > > involving subsystems that are not traditionally rooted into platforms > > using DT. > > > > Of course we could mention any expected warning regressions in our pull > > requests for soc. > > Right, that would certainly help. Some maintainers send all binding > updates both to the driver maintainers and to the soc tree, along > with the other changes that only go into one tree. That is of course > also more work on your side, but it solves the problem entirely. > So the same binding patch is picked up both in the driver and soc tree? I was expecting that to cause (harmless) conflicts when things arrive in Linus' merge queue? Or are you saying people go the length to create immutable branches for each binding? I'm curious because it's fairly often that we introduce clocks, interconnects etc where the macros from the dt bindings includes aren't available for another release (so we use numerical constants and then go back and fix them up later). Regards, Bjorn > > > renesas/r8a774a1-beacon-rzg2m-kit.dt.yaml: csi2@feaa0000: ports: > > > 'port@0' is a required property > > > > [...] > > > > I've replied to these as a response to your PR reply, see > > https://lore.kernel.org/linux-renesas-soc/CAMuHMdWHLnXgBSjP7VKUdx-YNr9rSKFkE5Ge5q_tarU6HP9Lhw@mail.gmail.com/ > > Ok, thanks. > > Arnd ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: New 'make dtbs_check W=1' warnings @ 2021-04-12 16:01 ` Bjorn Andersson 0 siblings, 0 replies; 28+ messages in thread From: Bjorn Andersson @ 2021-04-12 16:01 UTC (permalink / raw) To: Arnd Bergmann Cc: Geert Uytterhoeven, DTML, Rob Herring, Linus Walleij, Alexandre Belloni, Alexandre Torgue, Kevin Hilman, Linux Kernel Mailing List, Linux ARM, Tony Lindgren, Shawn Guo, Matthias Brugger, Nishanth Menon, Tero Kristo, SoC Team, Krzysztof Kozlowski, Gregory Clement, Florian Fainelli On Mon 12 Apr 08:14 CDT 2021, Arnd Bergmann wrote: > On Mon, Apr 12, 2021 at 1:32 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > On Thu, Apr 8, 2021 at 5:08 PM Arnd Bergmann <arnd@kernel.org> wrote: > > > > > > > For this merge window, I don't think any of them are show-stoppers (Rob, let me > > > know if you disagree), but in the long run we may want to gradually enforce > > > a rule about not merging changes that introduce any new warnings, in order to > > > have a chance of cleaning up the existing ones. > > > > This may not be as simple as it sounds, as DT binding updates typically > > follow a different path than DTS(i) updates. DT bindings updates may be > > picked up by a subsystem maintainer, by Rob, or by the platform > > maintainer. > > I checked out the bindings from linux-next, which seems to have covered > most of these. Sometimes it pays off to be lazy and merge them after > everyone else. > > > For trivial updates (e.g. adding a compatible value, and sometimes > > extending a limit), a DTS(i) update may be accepted by the platform > > maintainer before the corresponding DT binding update. The latter may > > even be merged one or more kernel revisions later, especially when > > involving subsystems that are not traditionally rooted into platforms > > using DT. > > > > Of course we could mention any expected warning regressions in our pull > > requests for soc. > > Right, that would certainly help. Some maintainers send all binding > updates both to the driver maintainers and to the soc tree, along > with the other changes that only go into one tree. That is of course > also more work on your side, but it solves the problem entirely. > So the same binding patch is picked up both in the driver and soc tree? I was expecting that to cause (harmless) conflicts when things arrive in Linus' merge queue? Or are you saying people go the length to create immutable branches for each binding? I'm curious because it's fairly often that we introduce clocks, interconnects etc where the macros from the dt bindings includes aren't available for another release (so we use numerical constants and then go back and fix them up later). Regards, Bjorn > > > renesas/r8a774a1-beacon-rzg2m-kit.dt.yaml: csi2@feaa0000: ports: > > > 'port@0' is a required property > > > > [...] > > > > I've replied to these as a response to your PR reply, see > > https://lore.kernel.org/linux-renesas-soc/CAMuHMdWHLnXgBSjP7VKUdx-YNr9rSKFkE5Ge5q_tarU6HP9Lhw@mail.gmail.com/ > > Ok, thanks. > > Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: New 'make dtbs_check W=1' warnings @ 2021-04-12 18:52 ` Arnd Bergmann 0 siblings, 0 replies; 28+ messages in thread From: Arnd Bergmann @ 2021-04-12 18:52 UTC (permalink / raw) To: Bjorn Andersson Cc: Geert Uytterhoeven, DTML, Rob Herring, Linus Walleij, Alexandre Belloni, Alexandre Torgue, Kevin Hilman, Linux Kernel Mailing List, Linux ARM, Tony Lindgren, Shawn Guo, Matthias Brugger, Nishanth Menon, Tero Kristo, SoC Team, Krzysztof Kozlowski, Gregory Clement, Florian Fainelli On Mon, Apr 12, 2021 at 6:01 PM Bjorn Andersson <bjorn.andersson@linaro.org> wrote: > On Mon 12 Apr 08:14 CDT 2021, Arnd Bergmann wrote: > > On Mon, Apr 12, 2021 at 1:32 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > On Thu, Apr 8, 2021 at 5:08 PM Arnd Bergmann <arnd@kernel.org> wrote: > > So the same binding patch is picked up both in the driver and soc tree? > I was expecting that to cause (harmless) conflicts when things arrive in > Linus' merge queue? > > Or are you saying people go the length to create immutable branches for > each binding? I think it's usually one immutable branch for all the bindings of a given merge window. This avoids the merge conflicts, and you can add further bindings on the same branch before sending it off to the soc tree. > I'm curious because it's fairly often that we introduce clocks, > interconnects etc where the macros from the dt bindings includes aren't > available for another release (so we use numerical constants and then go > back and fix them up later). Ah right, it is particularly bad for platforms that don't have a regular layout in these blocks and need to define a new constant every time another clock/reset/pin/... is discovered in the downstream sources. I was mainly referring to the simpler problem of defining a binding document for a device once, and then merging the nodes. Arnd ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: New 'make dtbs_check W=1' warnings @ 2021-04-12 18:52 ` Arnd Bergmann 0 siblings, 0 replies; 28+ messages in thread From: Arnd Bergmann @ 2021-04-12 18:52 UTC (permalink / raw) To: Bjorn Andersson Cc: Geert Uytterhoeven, DTML, Rob Herring, Linus Walleij, Alexandre Belloni, Alexandre Torgue, Kevin Hilman, Linux Kernel Mailing List, Linux ARM, Tony Lindgren, Shawn Guo, Matthias Brugger, Nishanth Menon, Tero Kristo, SoC Team, Krzysztof Kozlowski, Gregory Clement, Florian Fainelli On Mon, Apr 12, 2021 at 6:01 PM Bjorn Andersson <bjorn.andersson@linaro.org> wrote: > On Mon 12 Apr 08:14 CDT 2021, Arnd Bergmann wrote: > > On Mon, Apr 12, 2021 at 1:32 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > On Thu, Apr 8, 2021 at 5:08 PM Arnd Bergmann <arnd@kernel.org> wrote: > > So the same binding patch is picked up both in the driver and soc tree? > I was expecting that to cause (harmless) conflicts when things arrive in > Linus' merge queue? > > Or are you saying people go the length to create immutable branches for > each binding? I think it's usually one immutable branch for all the bindings of a given merge window. This avoids the merge conflicts, and you can add further bindings on the same branch before sending it off to the soc tree. > I'm curious because it's fairly often that we introduce clocks, > interconnects etc where the macros from the dt bindings includes aren't > available for another release (so we use numerical constants and then go > back and fix them up later). Ah right, it is particularly bad for platforms that don't have a regular layout in these blocks and need to define a new constant every time another clock/reset/pin/... is discovered in the downstream sources. I was mainly referring to the simpler problem of defining a binding document for a device once, and then merging the nodes. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: New 'make dtbs_check W=1' warnings @ 2021-04-13 2:36 ` Bjorn Andersson 0 siblings, 0 replies; 28+ messages in thread From: Bjorn Andersson @ 2021-04-13 2:36 UTC (permalink / raw) To: Arnd Bergmann Cc: Geert Uytterhoeven, DTML, Rob Herring, Linus Walleij, Alexandre Belloni, Alexandre Torgue, Kevin Hilman, Linux Kernel Mailing List, Linux ARM, Tony Lindgren, Shawn Guo, Matthias Brugger, Nishanth Menon, Tero Kristo, SoC Team, Krzysztof Kozlowski, Gregory Clement, Florian Fainelli On Mon 12 Apr 13:52 CDT 2021, Arnd Bergmann wrote: > On Mon, Apr 12, 2021 at 6:01 PM Bjorn Andersson > <bjorn.andersson@linaro.org> wrote: > > On Mon 12 Apr 08:14 CDT 2021, Arnd Bergmann wrote: > > > On Mon, Apr 12, 2021 at 1:32 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > > On Thu, Apr 8, 2021 at 5:08 PM Arnd Bergmann <arnd@kernel.org> wrote: > > > > So the same binding patch is picked up both in the driver and soc tree? > > I was expecting that to cause (harmless) conflicts when things arrive in > > Linus' merge queue? > > > > Or are you saying people go the length to create immutable branches for > > each binding? > > I think it's usually one immutable branch for all the bindings of a given > merge window. This avoids the merge conflicts, and you can add further > bindings on the same branch before sending it off to the soc tree. > That would be convenient to have, but the binding changes we depend on in a given window (in particular if dtbs_check is expected to pass) is scattered over a wide range of maintainer trees. > > I'm curious because it's fairly often that we introduce clocks, > > interconnects etc where the macros from the dt bindings includes aren't > > available for another release (so we use numerical constants and then go > > back and fix them up later). > > Ah right, it is particularly bad for platforms that don't have a regular > layout in these blocks and need to define a new constant every time > another clock/reset/pin/... is discovered in the downstream sources. > Even blocks following some standardized layout has this problem, because each platform will have it's own (often similar) set of clocks/resets/pins. And going back to dtbs_check, you will continue to see the warnings about missing compatibles, because most of the case they won't end up in the soc tree. > I was mainly referring to the simpler problem of defining a binding > document for a device once, and then merging the nodes. > I'm sure we all love the hardware that's simple to translate to a DT binding, unfortunately though we're dealing with complex SoCs. Regards, Bjorn ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: New 'make dtbs_check W=1' warnings @ 2021-04-13 2:36 ` Bjorn Andersson 0 siblings, 0 replies; 28+ messages in thread From: Bjorn Andersson @ 2021-04-13 2:36 UTC (permalink / raw) To: Arnd Bergmann Cc: Geert Uytterhoeven, DTML, Rob Herring, Linus Walleij, Alexandre Belloni, Alexandre Torgue, Kevin Hilman, Linux Kernel Mailing List, Linux ARM, Tony Lindgren, Shawn Guo, Matthias Brugger, Nishanth Menon, Tero Kristo, SoC Team, Krzysztof Kozlowski, Gregory Clement, Florian Fainelli On Mon 12 Apr 13:52 CDT 2021, Arnd Bergmann wrote: > On Mon, Apr 12, 2021 at 6:01 PM Bjorn Andersson > <bjorn.andersson@linaro.org> wrote: > > On Mon 12 Apr 08:14 CDT 2021, Arnd Bergmann wrote: > > > On Mon, Apr 12, 2021 at 1:32 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > > On Thu, Apr 8, 2021 at 5:08 PM Arnd Bergmann <arnd@kernel.org> wrote: > > > > So the same binding patch is picked up both in the driver and soc tree? > > I was expecting that to cause (harmless) conflicts when things arrive in > > Linus' merge queue? > > > > Or are you saying people go the length to create immutable branches for > > each binding? > > I think it's usually one immutable branch for all the bindings of a given > merge window. This avoids the merge conflicts, and you can add further > bindings on the same branch before sending it off to the soc tree. > That would be convenient to have, but the binding changes we depend on in a given window (in particular if dtbs_check is expected to pass) is scattered over a wide range of maintainer trees. > > I'm curious because it's fairly often that we introduce clocks, > > interconnects etc where the macros from the dt bindings includes aren't > > available for another release (so we use numerical constants and then go > > back and fix them up later). > > Ah right, it is particularly bad for platforms that don't have a regular > layout in these blocks and need to define a new constant every time > another clock/reset/pin/... is discovered in the downstream sources. > Even blocks following some standardized layout has this problem, because each platform will have it's own (often similar) set of clocks/resets/pins. And going back to dtbs_check, you will continue to see the warnings about missing compatibles, because most of the case they won't end up in the soc tree. > I was mainly referring to the simpler problem of defining a binding > document for a device once, and then merging the nodes. > I'm sure we all love the hardware that's simple to translate to a DT binding, unfortunately though we're dealing with complex SoCs. Regards, Bjorn _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: New 'make dtbs_check W=1' warnings @ 2021-04-13 9:55 ` Mark Brown 0 siblings, 0 replies; 28+ messages in thread From: Mark Brown @ 2021-04-13 9:55 UTC (permalink / raw) To: Arnd Bergmann Cc: Bjorn Andersson, Geert Uytterhoeven, DTML, Rob Herring, Linus Walleij, Alexandre Belloni, Alexandre Torgue, Kevin Hilman, Linux Kernel Mailing List, Linux ARM, Tony Lindgren, Shawn Guo, Matthias Brugger, Nishanth Menon, Tero Kristo, SoC Team, Krzysztof Kozlowski, Gregory Clement, Florian Fainelli [-- Attachment #1: Type: text/plain, Size: 808 bytes --] On Mon, Apr 12, 2021 at 08:52:37PM +0200, Arnd Bergmann wrote: > On Mon, Apr 12, 2021 at 6:01 PM Bjorn Andersson > > On Mon 12 Apr 08:14 CDT 2021, Arnd Bergmann wrote: > > So the same binding patch is picked up both in the driver and soc tree? > > I was expecting that to cause (harmless) conflicts when things arrive in > > Linus' merge queue? > > Or are you saying people go the length to create immutable branches for > > each binding? > I think it's usually one immutable branch for all the bindings of a given > merge window. This avoids the merge conflicts, and you can add further > bindings on the same branch before sending it off to the soc tree. Even with a single branch for everything having to split serieses into multiple branches seems like a pain, it'll break my automation for example. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: New 'make dtbs_check W=1' warnings @ 2021-04-13 9:55 ` Mark Brown 0 siblings, 0 replies; 28+ messages in thread From: Mark Brown @ 2021-04-13 9:55 UTC (permalink / raw) To: Arnd Bergmann Cc: Bjorn Andersson, Geert Uytterhoeven, DTML, Rob Herring, Linus Walleij, Alexandre Belloni, Alexandre Torgue, Kevin Hilman, Linux Kernel Mailing List, Linux ARM, Tony Lindgren, Shawn Guo, Matthias Brugger, Nishanth Menon, Tero Kristo, SoC Team, Krzysztof Kozlowski, Gregory Clement, Florian Fainelli [-- Attachment #1.1: Type: text/plain, Size: 808 bytes --] On Mon, Apr 12, 2021 at 08:52:37PM +0200, Arnd Bergmann wrote: > On Mon, Apr 12, 2021 at 6:01 PM Bjorn Andersson > > On Mon 12 Apr 08:14 CDT 2021, Arnd Bergmann wrote: > > So the same binding patch is picked up both in the driver and soc tree? > > I was expecting that to cause (harmless) conflicts when things arrive in > > Linus' merge queue? > > Or are you saying people go the length to create immutable branches for > > each binding? > I think it's usually one immutable branch for all the bindings of a given > merge window. This avoids the merge conflicts, and you can add further > bindings on the same branch before sending it off to the soc tree. Even with a single branch for everything having to split serieses into multiple branches seems like a pain, it'll break my automation for example. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2021-04-13 9:57 UTC | newest] Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-04-08 15:08 New 'make dtbs_check W=1' warnings Arnd Bergmann 2021-04-08 15:08 ` Arnd Bergmann 2021-04-08 15:25 ` Alexandre Belloni 2021-04-08 15:25 ` Alexandre Belloni 2021-04-08 23:59 ` Rob Herring 2021-04-08 23:59 ` Rob Herring 2021-04-08 19:25 ` Krzysztof Kozlowski 2021-04-08 19:25 ` Krzysztof Kozlowski 2021-04-08 22:11 ` Linus Walleij 2021-04-08 22:11 ` Linus Walleij 2021-04-08 22:11 ` Linus Walleij 2021-04-09 3:37 ` Florian Fainelli 2021-04-09 3:37 ` Florian Fainelli 2021-04-09 5:27 ` Rafał Miłecki 2021-04-09 5:27 ` Rafał Miłecki 2021-04-12 11:32 ` Geert Uytterhoeven 2021-04-12 11:32 ` Geert Uytterhoeven 2021-04-12 11:32 ` Geert Uytterhoeven 2021-04-12 13:14 ` Arnd Bergmann 2021-04-12 13:14 ` Arnd Bergmann 2021-04-12 16:01 ` Bjorn Andersson 2021-04-12 16:01 ` Bjorn Andersson 2021-04-12 18:52 ` Arnd Bergmann 2021-04-12 18:52 ` Arnd Bergmann 2021-04-13 2:36 ` Bjorn Andersson 2021-04-13 2:36 ` Bjorn Andersson 2021-04-13 9:55 ` Mark Brown 2021-04-13 9:55 ` Mark Brown
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.