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

On Wed, Aug 05, 2026 at 04:52:15PM +0200, Manivannan Sadhasivam wrote:
> 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/[email protected]/
> > 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/[email protected]/
> > 
> > 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

If I remember previous discussions, SW nodes can be used to provide
additional information about the existing devices. They should not be
used for matching.

> 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/[email protected]
> 
> -- 
> மணிவண்ணன் சதாசிவம்

-- 
With best wishes
Dmitry