Re: [PATCH v2 1/6] dt-bindings: bluetooth: qca: add QCC2072

[Krzysztof Kozlowski]

On 05/08/2026 16:12, Manivannan Sadhasivam wrote:
> On Wed, Aug 05, 2026 at 02:33:51PM +0200, Krzysztof Kozlowski wrote:
>> DT is not representation of internal device driver instantiation mechanism.
>>
> 
> Here, the driver is just creating compatible for a real device. What difference
> does it make if the BT node was defined statically in the DT vs created
> dynamically? Both nodes do represent a real BT device, not driver's own
> representation. And by the time the node was created, the device is physically
> attached to the system.

What stops this power sequencing drivers, after more driver patches, the
best if being part of some bigger series, to add properties like
"linux,name-of-driver-to-bind" or whatever other SW properties?

This is what happened in that linked thread:
https://lore.kernel.org/all/20260326-pci-m2-e-v7-8-43324a7866e6@xxxxxxxxxxxxxxxx/
The driver code is adding children under other nodes (references by
graph) and it is nowhere documented. Maybe bindings of these other nodes
allow it, maybe not. How do you even validate that?

So answering your question - yes, there is a difference because:
1. DTS we validate but whatever you add to driver code we do not and we
cannot,
2. DTS represents hardware but whatever you do in your driver code
represents who knows what (maybe hardware, maybe not, can represent
anything)

And if you claim "I add hardware in the driver!", I respond - maybe
true, maybe not, but look at this crap:
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=687bfbba5a1cb15cee51519c210141ed1c4b0ec7

Since we DISALLOWED venus-decoder and venus-encoder DT nodes, what did
Bryan do? Squeezed via driver code fake disallowed nodes and even gave
them compatibles not looking like compatibles, so any regex won't work.

This power sequencing work here has the same problem of sneaking ABI,
which I pointed out here:
https://lore.kernel.org/all/9cc5af16-d95e-4f10-8b4a-5e29c136079c@xxxxxxxxxx/

Look at above patch - nothing documents that ABI. The same as Bryan's
fake venus-decoder and encore (not only fake but actually rejected). And
to avoid ABI-check tools (or incoming tools), this power sequencing code
does not even call a "compatible" a "compatible". No, it calls it
"driver_data" nicely avoiding detection.

This is terrible practice and I feel like allowing this patch is silent
acknowledgment or agreement of such practice.

It's about basic ABI principles - if you have DT ABI, it must be both
clear in the drivers code and in DT bindings, instead of obfuscated
calling a compatible driver data. If you don't, then this is not DT ABI
and you are not allowed to use OF code to instantiate drivers. Use SW
nodes or KHO-style whatever else is there.

Best regards,
Krzysztof