On 27/11/2025 14:47, Icenowy Zheng wrote: > 在 2025-11-26星期三的 11:22 +0100，Krzysztof Kozlowski写道： >> On 26/11/2025 10:50, Icenowy Zheng wrote: >>>>> +maintainers: >>>>> + - Icenowy Zheng <[email protected]> >>>>> + >>>>> +properties: >>>>> + $nodename: >>>>> + pattern: "^display@[0-9a-f]+$" >>>>> + >>>>> + compatible: >>>>> + items: >>>>> + - enum: >>>>> + - thead,th1520-dc8200 >>>>> + - const: verisilicon,dc >>>> >>>> I do not see any explanation of exception for generic >>>> compatibles, >>>> maybe >>>> except "self-identification" remark. Rob already pointed this >>>> out, so >>>> be >>>> explicit in commit msg why you are using a generic compatible. >>> >>> Well I only get the meaning of "a SoC specific compatible is >>> required" >>> in his review message. >>> >>> I think my binding now requires both a SoC-specific compatible and >>> a >>> generic compatible, which should be okay to satisfy Rob's original >>> review. >> >> You will get then the same questions for me - what justifies generic >> compatible. You should be on this explicit, because otherwise people >> misinterpret some commits and patches, and they think the generic >> compatible is allowed for them as well. > > I came across a comment on Mali Valhall bindings that says `Mali > Valhall GPU model/revision is fully discoverable`, just after the > compatible string. > > Should I add a comment like this, or should I make things more clear in > the commit message?
Just say in the commit msg in the sentence about "self-identification facility" that therefore you use generic compatible (or "generic compatible is suitable"). Please trim the context when replying. Look below: > >> >>> >>>> >>>>> + >>>>> + reg: >>>>> + maxItems: 1 >>>>> + >>>>> + interrupts: >>>>> + maxItems: 1 >>>>> + >>>>> + clocks: >>>>> + minItems: 4 >>>> >>>> This is not flexible. Device either has or has not these clocks. >>> >>> The existence of all these clocks are verified by diagrams in >>> manuals >> >> So not flexible, then: >> >>> of two different SoCs with DC8200 (T-Head TH1520 and StarFive >>> JH7110). >>> >>> Maybe a explicit `maxItems: 5` is needed here, but as my DT passes >>> dtbs_check, I don't think it's necessary? >> >> No, drop minItems only. >> >>> >>> Or maybe I should drop the flexibility now and use a `minItems: 5` >>> here >>> (and leave DC8000 support as another story)? (The Eswin EIC7700 >>> manual >>> does not have a diagram showing external connections of the DC, >>> like >>> the two SoCs I mentioned above). >> >> You document here only the devices explicitly mentioned in the >> binding. >> You cannot add here constraints or clocks for some device which is >> not >> in the binding and I see only th1520 in the binding. >> >> Best regards, >> Krzysztof > Is all this needed for me? If it is there I will waste time scrolling through it looking for your questions. Think how your patchset and replies are received by reviewer. Best regards, Krzysztof
