On 18/05/2020 07:17, Manivannan Sadhasivam wrote: > On 0518, Amit Tomer wrote: >> Hi, >> >>> I recommend reading the DT spec, chapter 2.3.1 "compatible": >>> https://github.com/devicetree-org/devicetree-specification/releases/download/v0.3/devicetree-specification-v0.3.pdf >> >> My point is more about, DT validation is not happy about this situation. >> For instance when I run dt-validate, do see following: >> >> /home/amit/work/kernel_work/linux/arch/arm64/boot/dts/actions/s700-cubieboard7.dt.yaml: >> mmc@e0210000: compatible: Additional items are not allowed >> ('actions,s700-mmc' was unexpected) >> >> and I am not sure if this is because DT and driver has different >> number of compatible strings. This has nothing to do with the driver or the actual .dts(i), that's purely a binding issue. > Yeah, the DT YAML validation tool doesn't allow this. And there were patches > removing the additional compatible from DTS. There are tons of examples of how this is done in the .yaml bindings: properties: compatible: oneOf: - const: actions,owl-mmc - items: - const: action,s700-mmc - const: actions,owl-mmc Adding more alternatives would replace the lines after items: - enum - action,s700-mmc - action,s900-mmc - const: actions,owl-mmc > I don't know if the DT fallback is discouraged or not. I don't know if there is an "official" statement on this, but last thing I heard, adding SoC specific compatibles to generic fallback strings was encouraged. Hence my proposal, to add one. > Anyway, is enough investigation done to justify that we need SoC specific tweaks > in the driver? I think I did look into the downstream code for s700/s500 while > upstreaming this driver and convinced myself that the same driver could be > reused without modifications. It wouldn't be the first time some tiny incompatibility would be discovered later, also there is always the chance of a hardware errata. So better safe than sorry. Cheers, Andre.
