Hi,
On Mon, Jul 08, 2024 at 01:25:10PM GMT, Krzysztof Kozlowski wrote:
> On 07/07/2024 16:08, Jonathan Cameron wrote:
> >>>>> We were very well aware that not documenting this was going
> >>>>> to generate a warning so
> >>>>
> >>>> You *CANNOT* have undocumented compatibles.
> >>>
> >>> Why not? This corner case is a valid reason for that to be allowed.
> >>> You cannot use that compatible with DT bindings. Absolutely. The
> >>> compatible has other uses...
> >>
> >> Okay. With that approach what stops anyone from submitting DTS using
> >> that compatible (claiming there is a driver for that compatible)?
> >
> > That's a good point. Perhaps we should just add a check for this?
> > Easy to add a check on the firmware type. This is a rare enough case that
> > just doing it in the driver seems fine to me (rather than more general
> > infrastructure).
>
> Another point of slippery slope:
> 1. We accept such undocumented compatible in OF device id for ACPI
> (PRP0001).
> 2. Out-of-tree DTS uses it.
> 3. Whatever we decide to do now with that compatible, we have
> undocumented ABI exposed and used by users.
>
> That's the answer why we cannot have undocumented compatibles: because
> we do not want to have implicit ABI. We want explicit ABI, which is:
> 1. Clearly documented,
> 2. Reviewed/accepted explicitly.
Regarding implicit ABI, I would be much more worried about things
like this commit: 7b458a4c5d7302947556e12c83cfe4da769665d0 ("usb:
typec: Add typec_port_register_altmodes()"). It's not referenced
in the commit message, but IIRC Rob Herring ACK'd the approach
taken by Hans. I understand that it will become quite hard to get
things upstream when having to synchronize ACPI and DT first. But
it does mean vendors can (and actually did in this case) start
(ab)using the properties with DT making use of the implcit ABI.
Note that in case of Type-C there is now a proper upstream DT ABI. I
just wanted to point out that I totally understand the line of
thought Jonathan followed and demonstrate how one can have
undocumented properties (admittedly not a compatible in this case).
Greetings,
-- Sebastian
Attachment:
signature.asc
Description: PGP signature
