On Mon, Aug 19, 2024 at 09:45:29AM -0700, Bjorn Andersson wrote:
> On Mon, Aug 19, 2024 at 05:06:58PM +0200, Johan Hovold wrote:
> > On Sun, Aug 18, 2024 at 04:17:38PM -0700, Bjorn Andersson wrote:
> > > Commit 'caa855189104 ("soc: qcom: pmic_glink: Fix race during
> > > initialization")'
> >
> > This commit does not exist, but I think you really meant to refer to
> >
> > 9329933699b3 ("soc: qcom: pmic_glink: Make client-lock non-sleeping")
> >
> > and possibly also
> >
> > 635ce0db8956 ("soc: qcom: pmic_glink: don't traverse clients list without a lock")
> >
> > here.
> >
>
> Yeah, I copy-pasted the wrong SHA1. Prior to commit 9329933699b3 ("soc:
> qcom: pmic_glink: Make client-lock non-sleeping") the PDR notification
> happened from a worker with only mutexes held.
>
> > > moved the pmic_glink client list under a spinlock, as
> > > it is accessed by the rpmsg/glink callback, which in turn is invoked
> > > from IRQ context.
> > >
> > > This means that ucsi_unregister() is now called from IRQ context, which
^^^^^^^^^^^
> > > isn't feasible as it's expecting a sleepable context.
> >
> > But this is not correct as you say above that the callback has always
> > been made in IRQ context. Then this bug has been there since the
> > introduction of the UCSI driver by commit
> >
>
> No, I'm stating that commit 9329933699b3 ("soc: qcom: pmic_glink: Make
> client-lock non-sleeping") was needed because the client list is
> traversed under the separate glink callback, which has always been made
> in IRQ context.
Ok, got it. But then you meant "atomic context", not "IRQ context", in
the paragraph above.
Johan
