Re: [PATCH 4/6] dt-bindings: net: bluetooth: Document Qualcomm IPQ5018 Bluetooth controller

[Krzysztof Kozlowski <krzk@kernel.org>]

On 26/06/2026 13:30, Konrad Dybcio wrote:
> On 6/26/26 1:20 PM, George Moussalem wrote:
>> On 6/26/26 14:53, Krzysztof Kozlowski wrote:
>>> On Thu, Jun 25, 2026 at 06:10:08PM +0400, George Moussalem wrote:
>>>> Document the Qualcomm IPQ5018 Bluetooth controller.
>>>>
>>>> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
>>>> ---
> 
> [...]
> 
>>>> +      compatible = "qcom,ipq5018-bt";
>>>> +
>>>> +      qcom,ipc = <&apcs_glb 8 23>;
>>>> +      interrupts = <GIC_SPI 162 IRQ_TYPE_EDGE_RISING>;
>>>
>>> No firmware to load?
>>
>> firmware is loaded by the remoteproc in patch 1
>>
>>>
>>> It feels like remoteproc node split is fake. The property qcom,rproc is
>>> even more supporting that case. Shouldn't this be simply one device -
>>> bluetooth? What sort of two devices do you have exactly? How can I
>>> identify them in the hardware?
>>
>> I wasn't sure how to represent the HW. Should I make this bluetooth node
>> a childnode of the rproc? Essentially, this is the transport layer
>> (using shared memory space and IPC/interrupt).
>>
>> Most QCA BT controllers are also childnodes of a serdev/uart node as
>> they use serdev for transport.
>>
>> From what I understand, it's simply BT firmware running on this
>> dedicated M0 core in the SoC itself connected to an RF.
> 
> Seems like this rhymes with the WPSS remoteproc +ATH1xK_AHB situation
> - the Q6 core power sequences and manages the wireless controller,
> while Linux gets to drive the device as it would if it were connected
> over PCIe/ UART respectively, just with MMIO writes instead.

But the ATH (except the MMIO for remoteproc bringup) are physically
connected over other bus, like PCIe and UART.

What is here?

Best regards,
Krzysztof