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

[Manivannan Sadhasivam]

On Wed, Aug 05, 2026 at 04:36:31PM +0200, Krzysztof Kozlowski wrote:
> 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 the concern is validating the properties that get added dynamically and I get
that. How about inserting an overlay for the BT node instead of creating the
node on the fly? Like, drivers/misc/lan966x_pci.dtso

This way, the overlay would be validated against a binding and the driver would
just be inserting it.

> 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.
> 

I did propose using SW nodes initially, but then it got changed to
OF_DYNAMIC with review from Andy. But honestly, Andy only mentioned 'DT
Overlay' [1], and I was the one decided to use OF_DYNAMIC.

- Mani

[1] https://lore.kernel.org/all/aWSwgRiEkT9unYw9@xxxxxxxxxxxxxxxxxx

-- 
மணிவண்ணன் சதாசிவம்