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

On 31-07-2026 21:19, Konrad Dybcio wrote:
> On 7/31/26 4:48 PM, Rahul Samana wrote:
>>
>>
>> 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.
> 
> I only noticed this now - are there 2 variants of the industrial
> mezz being sold concurrently? Is the already-in-kernel one some
> sort of a prototype SKU? i.e. should we support both?
> 
>>>>>>
>>>>>> 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.
> 
> Okay, and do we know why that's the case in the first place?
> 
>> For the endpoint labels, I can move the UART endpoint to the SoC DTSI,
>> kodiak.dtsi, as uart4_ep.
> 
> Please do
> 
>> 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.
> 
> Yes, that was an omission from my side
> 
> 
>> 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.
> 
> I think this generic description is simply not achievable today without
> a bigger plan in place
> 
> Konrad

Hi Konrad, Dmitry,

Yes, both Industrial Kit variants need to be supported.

The default Industrial Kit uses the common Industrial mezzanine hardware
description and continues to use the existing Bluetooth-over-USB path. The
reworked Industrial Kit variant keeps the rest of the Industrial mezzanine
hardware the same, but routes Bluetooth over UART4 instead.

That is why this series models the reworked variant by applying the base RB3
Gen 2 DTB first, then the common Industrial mezzanine overlay, and finally
the BT UART overlay.

For the WCN6750 disablement reason, I will re-check the board/SKU details
and come back with the exact reason instead of assuming it only from the
current devicetree state.

For v3, I will move the UART endpoint to the SoC DTSI, kodiak.dtsi, as
uart4_ep.

For the PCIe endpoint, the exact PCIe node is introduced by the Industrial
mezzanine overlay, and a second overlay cannot reference a label introduced
there. So the clean label-and-patch model suggested earlier is not buildable
with the current two-overlay setup.

The PCIe graph endpoint is needed for the pwrseq-pcie-m2 provider to
associate the enumerated QCC2072 PCI function with the M.2 connector. Given
that, would the nested patching style from v1 be acceptable as an interim
solution for this variant despite the concern Dmitry raised?

I am open to other suggestions if there is a better way to model this within
the current overlay structure.

Thanks,
Rahul