On 2/13/26 3:31 PM, Dmitry Baryshkov wrote: > On Tue, Jan 20, 2026 at 03:39:44PM +0100, Konrad Dybcio wrote: >> On 1/16/26 3:50 PM, Luca Weiss wrote: >>> Add a node for the WCN6750 WiFi found with the Milos SoC. >>> >>> Signed-off-by: Luca Weiss <[email protected]> >>> --- >>> arch/arm64/boot/dts/qcom/milos.dtsi | 46 >>> +++++++++++++++++++++++++++++++++++++ >>> 1 file changed, 46 insertions(+) >>> >>> diff --git a/arch/arm64/boot/dts/qcom/milos.dtsi >>> b/arch/arm64/boot/dts/qcom/milos.dtsi >>> index 024e1c9992fe..80feb3e9d3e2 100644 >>> --- a/arch/arm64/boot/dts/qcom/milos.dtsi >>> +++ b/arch/arm64/boot/dts/qcom/milos.dtsi >>> @@ -2043,6 +2043,52 @@ gic_its: msi-controller@17140000 { >>> }; >>> }; >>> >>> + wifi: wifi@17110040 { >>> + compatible = "qcom,wcn6750-wifi"; >>> + reg = <0x0 0x17110040 0x0 0x0>; >> >> This reg doesn't.. sound.. very.. good.. >> >> The size being 0 is of course wrong, but perhaps more interestingly >> the base address is a register within the GIC.. >> >>> + iommus = <&apps_smmu 0x1400 0x1>; >> >> And this is a PCIe stream >> >> But I see kodiak has the exact same setup.. >> >> After digging a little into the driver, that 'reg' is apparently >> indeed consumed, as a base for PCI MSIs.. I feel like there should be >> some better way to express this.. non-everyday setup > > I wonder, why are we using it directly instead of relying on GIC? I > guess it is because we need to map MSI registers over the PCIe IOMMU and > then let the other side write to them. How is it being handled in the > normal PCIe case?
Looking at the recent r3g2 patches with the second switch enabled on PCIe1, it seems not to be an issue there Konrad
