New 'make dtbs_check W=1' warnings

New 'make dtbs_check W=1' warnings

[Arnd Bergmann]

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]+'

New 'make dtbs_check W=1' warnings

[Arnd Bergmann]

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

Re: New 'make dtbs_check W=1' warnings

[Alexandre Belloni]

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

Re: New 'make dtbs_check W=1' warnings

[Alexandre Belloni]

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

Re: New 'make dtbs_check W=1' warnings

[Krzysztof Kozlowski]

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

Re: New 'make dtbs_check W=1' warnings

[Krzysztof Kozlowski]

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

Re: New 'make dtbs_check W=1' warnings

[Linus Walleij]

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

Re: New 'make dtbs_check W=1' warnings

[Linus Walleij]

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

Re: New 'make dtbs_check W=1' warnings

[Linus Walleij]

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

Re: New 'make dtbs_check W=1' warnings

[Rob Herring]

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

Re: New 'make dtbs_check W=1' warnings

[Rob Herring]

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

Re: New 'make dtbs_check W=1' warnings

[Florian Fainelli]

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

Re: New 'make dtbs_check W=1' warnings

[Florian Fainelli]

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

Re: New 'make dtbs_check W=1' warnings

[Rafał Miłecki]

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.

Re: New 'make dtbs_check W=1' warnings

[Rafał Miłecki]

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

Re: New 'make dtbs_check W=1' warnings

[Geert Uytterhoeven]

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

Re: New 'make dtbs_check W=1' warnings

[Geert Uytterhoeven]

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

Re: New 'make dtbs_check W=1' warnings

[Geert Uytterhoeven]

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

Re: New 'make dtbs_check W=1' warnings

[Arnd Bergmann]

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

Re: New 'make dtbs_check W=1' warnings

[Arnd Bergmann]

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

Re: New 'make dtbs_check W=1' warnings

[Bjorn Andersson]

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

Re: New 'make dtbs_check W=1' warnings

[Bjorn Andersson]

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

Re: New 'make dtbs_check W=1' warnings

[Arnd Bergmann]

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

Re: New 'make dtbs_check W=1' warnings

[Arnd Bergmann]

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

Re: New 'make dtbs_check W=1' warnings

[Bjorn Andersson]

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

Re: New 'make dtbs_check W=1' warnings

[Bjorn Andersson]

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

Re: New 'make dtbs_check W=1' warnings

[Mark Brown]

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

Re: New 'make dtbs_check W=1' warnings

[Mark Brown]

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