Re: [RFC PATCH] usb: typec: ucsi: ack connector change after all tasks finish

From: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
To: Christian Ehrhardt <lk@c--e.de>
Cc: heikki.krogerus@linux.intel.com, gregkh@linuxfoundation.org,
	 neil.armstrong@linaro.org, quic_prashk@quicinc.com,
	dmitry.baryshkov@linaro.org,  fabrice.gasnier@foss.st.com,
	saranya.gopal@intel.com, linux-usb@vger.kernel.org,
	 diogo.ivo@tecnico.ulisboa.pt
Subject: Re: [RFC PATCH] usb: typec: ucsi: ack connector change after all tasks finish
Date: Thu, 28 Mar 2024 15:42:40 +0000	[thread overview]
Message-ID: <ynrqweb7hhfkrlvjr6suajq3jpgi4sqexz44qt4chekce7phiw@cyofo73xztdg> (raw)
In-Reply-To: <ZgREDo9tYAmdBcUc@cae.in-ulm.de>

On Wed, Mar 27, 2024 at 05:06:38PM +0100, Christian Ehrhardt wrote:
> 
> Hi,
> 
> thanks for bringing this to my attention.
> 
> On Wed, Mar 27, 2024 at 12:39:04PM +0000, Diogo Ivo wrote:
> > The UCSI specification mentions that when the OPM is notified by the
> > PPM of an asynchronous event it should first send all the commands it
> > needs to get the details of the event and only after acknowledge it by
> > sending ACK_CC_CI with the Connector Change bit set, while the current
> > code sends this ack immediately after scheduling all the partner_tasks.
> > Move this ACK_CC_CI command to the end of all partner_tasks.
> 
> I think this is reading too much into the spec. The only thing we
> really need to know about the event itself is what we get from
> the initial UCSI_GET_CONNECTOR_STATUS command. I was planning to
> send a change that acks the connector change directly along with this.
> 
> All of the problems that I saw in this area were due to the fact
> that the connector change indicator was cleared too late and not
> too early.
> 
> Moreover, it can take quite some time to handle a connector change on
> one connector. This would block any progress on a different connector,
> too.

Yes, this is true. We could move EVENT_PENDING bit into ucsi_connector so
it wouldn't block progress on other connectors but if the interpretation
of the spec is that we don't need to send the connector change ACK_CC_CI
at the very end then I guess it doesn't make much sense.

> > This fixes a problem with some LG Gram laptops where the PPM sometimes
> > notifies the OPM with the Connector Change Indicator field set in the
> > CCI after an ACK_CC_CI command is sent,causing the UCSI stack to check
> > the connector status indefinitely since the EVENT_PENDING bit is already
> > cleared. This causes an interrupt storm and an artificial high load on
> > these platforms.
> 
> If the PPM does this for a connector change ACK_CC_CI command it is
> IMHO violating the spec (unless there is a _new_ event).

Yes, the problem is exactly that the PPM in these laptops is really not
conformant with the spec and moving the command change ACK_CC_CI to the
end circumvented the problems in the PPM. If [1] is the way to go then
we need some sort of quirk for these devices and I'll have to dig
deeper.

> When I saw this type of loops the connector change indicator was set
> in response to an ACK_CC_CI command for a command (sent by a different
> thread for a different connector) between clearing the EVENT_PENDING
> bit and acquiring the PPM lock.
> 
> Can you test if the changes that already are in usb-linus are
> sufficient to fix your issues?

I am seeing these problems when addressing one connector only, so other
threads for other connectors do not play a role here. I have tested the
latest usb-linus with and without your early ack patch set [1] on top
and the issue is still not fixed.

[1]: https://lore.kernel.org/linux-usb/20240327224554.1772525-1-lk@c--e.de/

Best regards,

Diogo