Re: [PATCH v2 6/6] arm64: dts: qcom: rb3gen2: add Industrial BT UART overlay

[Rahul Samana]

On 31-07-2026 18:20, Konrad Dybcio wrote:
> On 7/31/26 8:53 AM, Rahul Samana wrote:
>>
>>
>> On 29-07-2026 18:01, Konrad Dybcio wrote:
>>> On 7/27/26 5:45 PM, Rahul Samana wrote:
>>>> The reworked RB3 Gen 2 Industrial mezzanine keeps the common Industrial
>>>> mezzanine hardware description but routes QCC2072 Bluetooth over UART4
>>>> instead of the default Bluetooth-over-USB path.
>>>>
>>>> Build this variant by applying the common Industrial mezzanine overlay
>>>> first, followed by the BT UART overlay. The overlay models the M.2 E-key
>>>> connector graph endpoints for PCIe and UART, and disables the on-board
>>>> WCN6750 PMU and UART7 path so the M.2 QCC2072 Bluetooth controller can be
>>>> used instead.
>>>
>>> So is the onboard module disabled? Can we not just use two in parallel?
>>>
>>
>> The Industrial mezzanine variants do not support the on-board WCN6750
>> wireless path. The common Industrial mezzanine overlay already disables
>> the on-board Wi-Fi node.
> 
> What does 'do not support' it mean here? They are physically present
> as part of the SoM, so unless the lanes are somehow diverted away,
> why is it not?
> 
> Konrad

Hi Konrad,

The WCN6750 module is physically present on the SoM. What I meant is that
the current Industrial mezzanine devicetree already disables the on-board
Wi-Fi path, and this BT UART variant followed the same board-level policy
for the on-board Bluetooth UART/PMU path.

For the endpoint labels, I can move the UART endpoint to the SoC DTSI,
kodiak.dtsi, as uart4_ep.

For the PCIe endpoint, the PCIe path to the M.2 QCC2072 device is not the
PCIe0 root port in kodiak.dtsi. In the composed devicetree, it is
behind the Industrial mezzanine PCIe switch, under:

    /soc@0/pcie@1c00000/pcie@0/pcie@0,0/pcie@2,0


So placing pcie0_port0_ep in kodiak.dtsi would not describe the actual
topology.

I tried adding a generic label/endpoint to that downstream port in the
Industrial mezzanine overlay and referencing it from the BT UART overlay.
However, when the overlays are compiled separately and then composed, that
label is not available while applying the BT UART overlay, so the composed
DTB build fails with FDT_ERR_NOTFOUND.

Could you please suggest how you would prefer the PCIe endpoint to be
modelled for this case?

Regards,
Rahul