On 6/26/26 1:20 PM, George Moussalem wrote:

On 6/26/26 14:53, Krzysztof Kozlowski wrote:

quoted

On Thu, Jun 25, 2026 at 06:10:08PM +0400, George Moussalem wrote:

quoted

Document the Qualcomm IPQ5018 Bluetooth controller.

Signed-off-by: George Moussalem <redacted>
---

[...]

quoted

quoted

+      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

quoted

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.

Konrad