On Wed, Mar 20, 2024 at 08:39:21AM +0100, Christian A. Ehrhardt wrote: > Fix various races in UCSI code: > - The EVENT_PENDING bit should be cleared under the PPM lock to > avoid spurious re-checking of the connector status. > - The initial connector change notification during init may be > lost which can cause a stuck UCSI controller. Observed by me > and others during resume or after module reload. > - Unsupported commands must be ACKed. This was uncovered by the > recent change from Jameson Thies that did sent unsupported commands. > - The DELL quirk still isn't quite complete and I've found a more > elegant way to handle this. A connector change ack _is_ accepted > on affected systems if it is bundled with a command ack. > - If we do two consecutive resets or the controller is already > reset at boog the second reset might complete early because the > reset complete bit is already set. ucsi_ccg.c has a work around > for this but it looks like an more general issue to me. > > NOTE: > As a result of these individual fixes we could think about the > question if there are additional cases where we send some type > of command to the PPM while the bit that indicates its completion > is already set in CCI. And in fact there is one more case where > this can happen: The ack command that clears the connector change > is sent directly after the ack command for the previous command. > It might be possible to simply ack the connector change along with > the first command ucsi_handle_connector_change() and not at the > end. AFAICS the connector lock should protect us from races that > might arise out of this. That sounds good to me. thanks, -- heikki
