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: <3779260.mvXUDI8C0e@lucaweiss.eu>
Date: Mon, 27 Jan 2025 14:27:40 +0100
From: Luca Weiss <luca@...aweiss.eu>
To: Stephan Gerhold <stephan.gerhold@...aro.org>
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 7/9] ARM: dts: qcom: msm8226: Add modem remoteproc node

On maandag 27 januari 2025 10:19:21 Midden-Europese standaardtijd Stephan 
Gerhold wrote:
> On Sun, Jan 26, 2025 at 09:57:26PM +0100, Luca Weiss wrote:
> > Add a node for the modem remoteproc found on MSM8226.
> > 
> > For the apq8026 smartwatches, delete the modem reserved-memory again
> > since they have very little RAM in the first place anyways, and all of
> > these devices don't have functional modem firmware anyways - these
> > watches don't even have GPS.
> > 
> > Co-developed-by: Matti Lehtimäki <matti.lehtimaki@...il.com>
> > Signed-off-by: Matti Lehtimäki <matti.lehtimaki@...il.com>
> > Signed-off-by: Luca Weiss <luca@...aweiss.eu>
> > ---
> >  .../boot/dts/qcom/qcom-apq8026-asus-sparrow.dts    |  7 ++
> >  .../boot/dts/qcom/qcom-apq8026-huawei-sturgeon.dts |  7 ++
> >  arch/arm/boot/dts/qcom/qcom-apq8026-lg-lenok.dts   |  7 ++
> >  .../dts/qcom/qcom-apq8026-samsung-milletwifi.dts   |  2 +
> >  .../qcom/qcom-msm8226-samsung-matisse-common.dtsi  |  6 +-
> >  arch/arm/boot/dts/qcom/qcom-msm8226.dtsi           | 80 +++++++++++++++++
+++++
> >  arch/arm/boot/dts/qcom/qcom-msm8926-htc-memul.dts  |  2 +
> >  7 files changed, 109 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm/boot/dts/qcom/qcom-apq8026-asus-sparrow.dts b/arch/
arm/boot/dts/qcom/qcom-apq8026-asus-sparrow.dts
> > index 
a2ca456012f1a070afc2805ae71ddbf6f5aac607..816b61ea504ee80d86dd4ccd1a15db687f6a91ff 
100644
> > --- a/arch/arm/boot/dts/qcom/qcom-apq8026-asus-sparrow.dts
> > +++ b/arch/arm/boot/dts/qcom/qcom-apq8026-asus-sparrow.dts
> > @@ -9,6 +9,8 @@
> >  #include "pm8226.dtsi"
> >  
> >  /delete-node/ &adsp_region;
> > +/delete-node/ &mba_region;
> > +/delete-node/ &mpss_region;
> >  
> >  / {
> >  	model = "ASUS ZenWatch 2";
> > @@ -82,6 +84,11 @@ bluetooth {
> >  	};
> >  };
> >  
> > +/* No (useful) modem on this device */
> > +&modem {
> > +	/delete-property/ memory-region;
> > +};
> 
> Rather than putting /delete-node/ and /delete-property/ on all devices
> that do not need/use the modem, I think it would be cleaner if you make
> the remoteproc related reserved-memory status = "disabled" by default
> and enable it only where necessary together with the modem. The &modem
> itself is status = "disabled" by default, so it makes sense to use the
> same for the reserved memory as well. See e.g. the existing usage of
> this pattern for &mpss_mem/&wcnss_mem/&venus_mem/&mba_mem in
> msm8916.dtsi. Then you can drop the /delete-property/ here.

That's a good point, I didn't realize you can disable a reserved-memory node 
like that. And since often even APQ variants have useful modem firmware (e.g. 
GPS) I didn't find something quickly I guess.

> 
> It would be even nicer to use the dynamic allocation
> (size/alignment/alloc-ranges instead of reg), but I'm skeptical if this
> will work properly on such an old platform...

IIRC I've read in msm8974 docs that dynamic allocation should be possible, I 
can give it a try some day, both on 8974 and 8226.

Regards
Luca

> 
> Thanks,
> Stephan
> 





Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ