linux-kernel - Re: [PATCH 09/15] rpmsg: smd: Drop unnecessary condition for channel creation

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: <2615776.mvXUDI8C0e@g550jk>
Date:   Sun, 06 Feb 2022 21:17:22 +0100
From:   Luca Weiss <luca@...tu.xyz>
To:     Stephan Gerhold <stephan@...hold.net>,
        Bjorn Andersson <bjorn.andersson@...aro.org>
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>,
        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

Hi Bjorn,

On Montag, 31. Jänner 2022 23:32:42 CET Bjorn Andersson wrote:
> On Sun 16 Jan 10:30 CST 2022, Stephan Gerhold wrote:
> > 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.and
> > > > ersson @linaro.org/
> > > > https://lore.kernel.org/linux-arm-msm/20180315181244.8859-1-bjorn.ande
> > > > rsson
> > > > @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.
> 
> Last time this came up I asked if someone could test if the RPM is stuck
> in the state machine trying to close the channel and as such we could
> kick it by making sure that we "ack" the closing of the channel and
> hence it would come back up again.
> 
> But I don't remember seeing any outcome of this.

Do you have a link to this or should I go digging in the archives?

Regards
Luca

> 
> > Many solutions are possible though so at the end it is mostly up to
> > Bjorn to decide I think. :)
> 
> I would prefer to get an answer to above question, but if that doesn't
> work (or look like crap) I'm willing to take your suggestion of skipping
> the continue for the rpm_requests channel. Obviously with a comment
> above describing why we're carrying that special case.
> 
> Regards,
> Bjorn