> For rk3399 dwc3 usb the wrapper node for only clocks makes no sense, > so restyle the rk3399 usbdrd3_0 node before more new SoC types are > added with the same IP. > > Signed-off-by: Johan Jonker <jbx6244 at gmail.com> > --- > Changed V3: > remove aclk_usb3_rksoc_axi_perf > remove aclk_usb3 > --- > arch/arm64/boot/dts/rockchip/rk3399-ficus.dts | 2 +- > arch/arm64/boot/dts/rockchip/rk3399-firefly.dts | 6 +--- > arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 6 +--- > arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts | 6 +--- > .../boot/dts/rockchip/rk3399-khadas-edge.dtsi | 6 +--- > arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts | 6 +--- > arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi | 4 --- > arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts | 6 +--- > .../boot/dts/rockchip/rk3399-pinebook-pro.dts | 4 --- > .../arm64/boot/dts/rockchip/rk3399-puma-haikou.dts | 4 --- > arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi | 4 --- > arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi | 6 +--- > arch/arm64/boot/dts/rockchip/rk3399-rock960.dts | 2 +- > arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi | 4 --- > arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi | 6 +--- > arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi | 6 +--- > arch/arm64/boot/dts/rockchip/rk3399.dtsi | 37 ++++++++-------------- > .../boot/dts/rockchip/rk3399pro-vmarc-som.dtsi | 4 --- > 18 files changed, 24 insertions(+), 95 deletions(-) This change is problematic since: - compatible = "rockchip,rk3399-dwc3"; + compatible = "rockchip,rk3399-dwc3", "snps,dwc3"; This means that an existing "glue" driver will now attach to the node for the actual DWC3 controller. Not sure what the consequences exactly are on Linux, but on other systems that consume device trees (e.g. U-Boot, OpenBSD) this may break things because only the glue driver attaches. And even if on Linux both the "glue" driver and the "core" driver can share a single device tree node, this will still lead to multiple drivers manipulating the same clocks and resets, which I think is undesirable. You could introduce a new rk3399-specific compatible for the node. But I don't think this device tree binding change is helpful. Cheers, Mark
