Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 15 Feb 2022 09:34:41 -0600
From:   Bjorn Andersson <bjorn.andersson@linaro.org>
To:     Luca Weiss <luca@z3ntu.xyz>
Cc:     Stephan Gerhold <stephan@gerhold.net>,
        linux-arm-msm@vger.kernel.org,
        ~postmarketos/upstreaming@lists.sr.ht, phone-devel@vger.kernel.org,
        Vladimir Lypak <vladimir.lypak@gmail.com>,
        Konrad Dybcio <konrad.dybcio@somainline.org>,
        Andy Gross <agross@kernel.org>,
        Ohad Ben-Cohen <ohad@wizery.com>,
        Mathieu Poirier <mathieu.poirier@linaro.org>,
        linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org,
        Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Subject: Re: [PATCH 09/15] rpmsg: smd: Drop unnecessary condition for channel
 creation
Message-ID: <YgvIEYOAZTFHN6fb@yoga>
References: <20220112194118.178026-1-luca@z3ntu.xyz>
 <Yfhjil3pfZLa5g3j@builder.lan>
 <2615776.mvXUDI8C0e@g550jk>
 <3503848.e9J7NaK4W3@g550jk>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3503848.e9J7NaK4W3@g550jk>
Precedence: bulk

On Sun 13 Feb 14:51 CST 2022, Luca Weiss wrote:

> Hi Bjorn,
> 
> On Sonntag, 6. Februar 2022 21:17:22 CET Luca Weiss wrote:
> > 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@gmail.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@gmail.com>
> > > > > > > Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> > > > > > > Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.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.a
> > > > > > nd
> > > > > > ersson @linaro.org/
> > > > > > https://lore.kernel.org/linux-arm-msm/20180315181244.8859-1-bjorn.an
> > > > > > de
> > > > > > 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?
> 
> Replying to myself, I went searching but couldn't find anything. If you have 
> some PoC code I'd be happy to try but as I'm not familiar with rpm/smd at all 
> I'd have to read myself into it first.
> 

A quick search didn't turn anything up on my side either.

And while I had suggestions of what could be tried, I don't have any
devices myself that manifest this problem, so I haven't been able to
debug it.

> If Stephans suggestion with the strcmp(channel->name, "rpm_requests") is ok 
> then I'd test this and use that in v2. I'd personally rather not spend too 
> much time on this issue right now as it's blocking msm8953 completely (no 
> regulators = no nothing),
> 

It's been a long time since this problem was initially reported, so I
rather see us land the strcmp() hack to unblock you and others. Then
someone who knows SMD can take a proper look at this.

Regards,
Bjorn

> Regards
> Luca
> 
> > 
> > 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
> 
> 
> 
>