Re: [PATCH 2/3] usb: typec: ucsi: Move unregister out of atomic section

[Johan Hovold]

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