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@xxxxxxx/ Best regards, Diogo
