linux-kernel - Re: [PATCH v2 9/9] ARM: dts: qcom: msm8226-samsung-matisse-common: Enable modem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z5eNsk5Vvp6BxmJ9@linaro.org>
Date: Mon, 27 Jan 2025 14:44:18 +0100
From: Stephan Gerhold <stephan.gerhold@...aro.org>
To: Luca Weiss <luca@...aweiss.eu>
Cc: ~postmarketos/upstreaming@...ts.sr.ht, phone-devel@...r.kernel.org,
	Bjorn Andersson <andersson@...nel.org>,
	Mathieu Poirier <mathieu.poirier@...aro.org>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Stephan Gerhold <stephan@...hold.net>,
	Konrad Dybcio <konradybcio@...nel.org>,
	Matti Lehtimäki <matti.lehtimaki@...il.com>,
	linux-arm-msm@...r.kernel.org, linux-remoteproc@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 9/9] ARM: dts: qcom: msm8226-samsung-matisse-common:
 Enable modem

On Mon, Jan 27, 2025 at 02:34:08PM +0100, Luca Weiss wrote:
> On maandag 27 januari 2025 10:44:19 Midden-Europese standaardtijd Stephan 
> Gerhold wrote:
> > On Sun, Jan 26, 2025 at 09:57:28PM +0100, Luca Weiss wrote:
> > > From: Matti Lehtimäki <matti.lehtimaki@...il.com>
> > > 
> > > Enable modem remoteproc on samsung,matisse-wifi & matisselte.
> > > 
> > > Signed-off-by: Matti Lehtimäki <matti.lehtimaki@...il.com>
> > > Signed-off-by: Luca Weiss <luca@...aweiss.eu>
> > > ---
> > >  arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-common.dtsi | 7 +++++
> ++
> > >  1 file changed, 7 insertions(+)
> > > 
> > > diff --git a/arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-
> common.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-common.dtsi
> > > index fbd568c7d6b7415d240aa1a2329d07cf9135274c..
> 4155bfb2136022f2a85d69451c34f06ed2a700ac 100644
> > > --- a/arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-common.dtsi
> > > +++ b/arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-common.dtsi
> > > @@ -225,6 +225,13 @@ &blsp1_uart3 {
> > >  	status = "okay";
> > >  };
> > >  
> > > +&modem {
> > > +	mx-supply = <&pm8226_l3>;
> > > +	pll-supply = <&pm8226_l8>;
> > 
> > Hmmmmm, so I was looking at msm8926.dtsi downstream and it seems to
> > override the msm8226.dtsi modem/mss definition [1]:
> > 
> >  1. ext-bhs-reg is dropped
> >  2. vdd_mss-supply is added
> 
> That's the same what I found, and have working with more (currently hacky) 
> patches on msm8926-htc-memul. I decided against introducing it with this 
> series since these patches have been pending for too long and initially when I 
> was doing 8926, I wasn't sure how to make this into a proper patch. Now my 
> idea is to introduce a "static const struct rproc_hexagon_res msm8926_mss" 
> with the compatible qcom,msm8926-mss-pil which has these two differences.
> I think that's a better idea than adding some extra conditionals around to 
> make the mss-supply optional and ext-bhs somehow optional in the driver based 
> on dt.
> 

Yeah, that sounds good. Could add a new qcom-msm8926.dtsi include that
overrides the compatible and /delete-property/ the ext-bhs-reg. Then
just #include that only for matisselte and add the mss-supply there.

> > 
> > This common include seems to cover both apq8026 (matissewifi) and
> > msm8926 (matisselte).
> 
> That's a very good point. I didn't think much about the matisse patches since 
> they were introduced by Matti but yes... Either I add the msm8926 support in 
> the same series already, or we just enable modem for matissewifi for now. I 
> think I'll opt for the latter since the series is already 9 patches long and I 
> don't want to make it too complicated.
> 

Either way is fine for me. I guess I'd personally throw it in one
series, just because it fits well together and it can take quite some
time to get patches applied. :-)

Thanks,
Stephan