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

[Krzysztof Kozlowski]

On 07/08/2026 11:40, Dmitry Baryshkov wrote:
> 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/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
> 
> 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.

Yeah, matching is via standard driver name for example like MFD is doing
for platform bus.

This is not that different than MFD.

Best regards,
Krzysztof