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

Konrad Dybcio <[email protected]>
Newsgroups org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-bluetooth,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel,org.kernel.vger.linux-pci,org.kernel.vger.linux-pm
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.