[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMRc=MefTjz=h6jzE5vE-yaHnyM601Ts8XYZqEYnOsidfQEavA@mail.gmail.com>
Date: Wed, 11 Sep 2024 13:41:58 +0200
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: Elliot Berman <quic_eberman@...cinc.com>, Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konradybcio@...nel.org>, Andrew Halaney <ahalaney@...hat.com>,
Rudraksha Gupta <guptarud@...il.com>,
"Linux regression tracking (Thorsten Leemhuis)" <regressions@...mhuis.info>, linux-arm-msm@...r.kernel.org,
linux-kernel@...r.kernel.org,
Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH 2/2] firmware: qcom: scm: fall back to kcalloc() for no
SCM device bound
On Tue, Sep 10, 2024 at 1:06 PM Dmitry Baryshkov
<dmitry.baryshkov@...aro.org> wrote:
>
> >
> > I'm a little concerned about this check. I didn't think making SCM calls
> > without the SCM device probed was possible until this report. We do
> > worry about that in the downstream kernel. So, I'm not sure if this
> > scenario is currently possible in the upstream kernel.
>
> MSM8960 and MSM8660 don't have SCM devices. For MSM8960 it should be
> trivial to get it, c&p from apq8064 should. For MSM8660 it might be a
> bit harder. But even if we add such nodes, we shouldn't break existing
> DT files.
>
I'm wondering about how to approach an eventual refactoring and I'm
thinking that for platforms that are known to have DTs out there
without the node, we could exceptionally instantiate the SCM device
when the module is loaded? And then modify the driver to require the
provider to have an actual struct device attached.
Bart
Powered by blists - more mailing lists