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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YeRILypv8ajssNae@gerhold.net>
Date:   Sun, 16 Jan 2022 17:30:39 +0100
From:   Stephan Gerhold <stephan@...hold.net>
To:     Luca Weiss <luca@...tu.xyz>
Cc:     linux-arm-msm@...r.kernel.org,
        ~postmarketos/upstreaming@...ts.sr.ht, phone-devel@...r.kernel.org,
        Vladimir Lypak <vladimir.lypak@...il.com>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Ohad Ben-Cohen <ohad@...ery.com>,
        Mathieu Poirier <mathieu.poirier@...aro.org>,
        linux-remoteproc@...r.kernel.org, linux-kernel@...r.kernel.org,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Subject: Re: [PATCH 09/15] rpmsg: smd: Drop unnecessary condition for channel
 creation

On Sun, Jan 16, 2022 at 05:08:29PM +0100, Luca Weiss wrote:
> On Mittwoch, 12. Jänner 2022 22:39:53 CET Stephan Gerhold wrote:
> > On Wed, Jan 12, 2022 at 08:40:58PM +0100, Luca Weiss wrote:
> > > From: Vladimir Lypak <vladimir.lypak@...il.com>
> > > 
> > > RPM Firmware on variety of newer SoCs such as MSM8917 (also likely
> > > MSM8937, MSM8940, MSM8952), MSM8953 and on some MSM8916 devices) doesn't
> > > initiate opening of the SMD channel if it was previously opened by
> > > bootloader. This doesn't allow probing of smd-rpm driver on such devices
> > > because there is a check that requires RPM this behaviour.
> > > 
> > > Signed-off-by: Vladimir Lypak <vladimir.lypak@...il.com>
> > > Signed-off-by: Luca Weiss <luca@...tu.xyz>
> > > Reviewed-by: Konrad Dybcio <konrad.dybcio@...ainline.org>
> > 
> > This is effectively a "Revert "Revert "rpmsg: smd: Create device for all
> > channels""":
> > 
> > https://lore.kernel.org/linux-arm-msm/20171212235857.10432-3-bjorn.andersson
> > @linaro.org/
> > https://lore.kernel.org/linux-arm-msm/20180315181244.8859-1-bjorn.andersson
> > @linaro.org/
> > 
> > Won't this cause the same regression reported by Srinivas again?
> > 
> 
> Do you have any suggestion on another way to solve this? Without this commit 
> the regulators just won't probe at all, I haven't looked very deep into it 
> though given this patch solves it.
> 
> I guess worst case it'll become a devicetree property to enable this quirk?
> 

My spontaneous suggestion would be to skip the check only for the
"rpm_requests" channel, e.g. something like

	if (remote_state != SMD_CHANNEL_OPENING &&
	    remote_state != SMD_CHANNEL_OPENED &&
	    strcmp(channel->name, "rpm_requests")
		continue;

This will avoid changing the behavior for anything but the RPM channel.
I don't think anything else is affected by the same problem (since the
bootloader or earlier firmware should not make use of any other channel).
Also, we definitely *always* want to open the channel to the RPM because
otherwise almost everything breaks.

Many solutions are possible though so at the end it is mostly up to
Bjorn to decide I think. :)

Thanks,
Stephan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ