Re: [PATCH] arm64: dts: qcom: shikra: Add BAM-DMUX support

[Vishnu Santhosh]

On 11-06-2026 02:25 pm, Stephan Gerhold wrote:
> On Thu, Jun 11, 2026 at 02:11:59PM +0530, Vishnu Santhosh wrote:
> > +	bam_dmux: bam-dmux {
> > +		compatible = "qcom,bam-dmux";
> > +
> > +		interrupts-extended = <&modem_smsm 1 IRQ_TYPE_EDGE_BOTH>,
> > +				      <&modem_smsm 11 IRQ_TYPE_EDGE_BOTH>;
> > +		interrupt-names = "pc",
> > +				  "pc-ack";
> > +
> > +		qcom,smem-states = <&apps_smsm 1>,
> > +				   <&apps_smsm 11>;
> > +		qcom,smem-state-names = "pc",
> > +					"pc-ack";
> > +
> > +		dmas = <&bam_dmux_dma 4>, <&bam_dmux_dma 5>;
> > +		dma-names = "tx", "rx";
> > +	};
> This should be a child node of the modem remoteproc. See msm8916.dtsi
> for example.

Thanks for the context! We actually referenced msm8916.dtsi during 
bring-up and initially placed bam-dmux as a
remoteproc child. We then hit the issue that the driver was not probing 
at all. After some digging, we realized
that qcom_q6v5_mss.c (used by msm8916) explicitly calls 
of_platform_device_create() for its qcom,bam-dmux child,
but qcom_q6v5_pas.c which Shikra uses has no such logic, so the platform 
device was never created.

There was a prior attempt to fix this generically by adding 
of_platform_populate() to qcom_q6v5.c
(https://lore.kernel.org/all/20251223123227.1317244-3-gaurav.kohli@xxxxxxxxxxxxxxxx/), 
but it was blocked
because GLINK/SMD edge child nodes would also get spurious platform 
devices registered for them.
That series remains unresolved at v1.

Since your driver already manages modem lifecycle independently via SMSM 
state bits without remoteproc dependency,
we moved it to the root level where of_platform_populate() picks it up 
at boot, and everything worked.

Would love to get your suggestion on whether this approach is welcomed, 
since it needs zero driver changes.

Thanks,
Vishnu