On 9.01.2025 10:51 PM, Stephen Boyd wrote: > Quoting Konrad Dybcio (2025-01-09 06:05:14) >> On 8.01.2025 2:28 AM, Stephen Boyd wrote: >>> Document the Qualcomm SC7180 System on a Chip (SoC). This SoC is made up >>> of multiple devices that have their own bindings, therefore this binding >>> is for a "bus" that is the SoC node. >>> >>> TODO: Document all child nodes. This is woefully incomplete but at least >>> shows what is involved with describing an SoC node in dt schema. >> >> I'm not sure I'm a fan, because... >> >> [...] >> >>> + >>> +properties: >>> + compatible: >>> + items: >>> + - const: qcom,soc-sc7180 >>> + - const: simple-bus >>> + >>> + '#address-cells': >>> + const: 2 >>> + >>> + '#size-cells': >>> + const: 2 >>> + >>> + clock-controller@100000: >>> + $ref: /schemas/clock/qcom,gcc-sc7180.yaml# >>> + >>> + watchdog@17c10000: >>> + $ref: /schemas/watchdog/qcom-wdt.yaml# >>> + >>> +required: >>> + - compatible >>> + - '#address-cells' >>> + - '#size-cells' >>> + - clock-controller@100000 >>> + - watchdog@17c10000 >>> + >>> +additionalProperties: false >> >> ..this approach will make any dt node addition under /soc require >> an additional bindings change, which sounds like absolute madness > > We should pretty much know what nodes go under here though, because it's > a chip that exists and doesn't change after the fact. I agree that it > will be annoying during early development when everyone is modifying the > same file to add their node, but that problem also exists with the dts > files today so it doesn't seem like total madness. It's also nice to be > able to look at one file and quickly find all the schemas for the SoC > used, like a table of contents almost or a memory map for the chip. > > One thing that I find annoying is that you have to put the whole soc > node and child nodes in the example. Maybe we can omit the example > because there are so many child nodes. I guess I could get behind both your and my points.. My main worry is the day-1-support-1234-long-patch-series where 5-10% of nodes is likely to need some remodeling, with some hw needing to be re-described in a different way before getting merged. Rebasing that will be an even bigger mess, but I suppose it's doable.. The same stands for the every-now-and-then occasion when we decide that e.g. block X is not really a clock-controller, but rather a power-manager or something.. If someone wants to rely on stable bindings in their non-Linux OS project, requiring constant node names is one more potential point of failure. >> I think additionalProperties: true would be sufficient here, like in >> Documentation/devicetree/bindings/soc/imx/imx8m-soc.yaml >> > > Ok. That binding looks to be for the efuse properties of the SoC node > itself? I was hoping to find another example of this "describe the whole > SoC" sort of binding but that doesn't match. Is there one already out > there? Should I move this binding to bindings/soc/qcom instead of > bindings/bus? I don't think anyone has done that in the past.. maaaaybe Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml gets close with a loose "anything with a @unit-address" as "Peripherals", but that's not what you're looking for.. As for the directory, it seems to be all over the place for other uses of "xyz", "simple-bus": Documentation/devicetree/bindings/arm/arm,realview.yaml Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml Documentation/devicetree/bindings/arm/microchip,sparx5.yaml Documentation/devicetree/bindings/bus/fsl,spba-bus.yaml Documentation/devicetree/bindings/bus/st,stm32-etzpc.yaml Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml Documentation/devicetree/bindings/net/marvell,dfx-server.yaml Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe.yaml Documentation/devicetree/bindings/soc/imx/fsl,aips-bus.yaml Documentation/devicetree/bindings/soc/imx/imx8m-soc.yaml Konrad
