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. Christian A. Ehrhardt (5): usb: typec: ucsi: Clear EVENT_PENDING under PPM lock usb: typec: ucsi: Check for notifications after init usb: typec: ucsi: Ack unsupported commands usb: typec: ucsi_acpi: Refactor and fix DELL quirk usb: typec: ucsi: Clear UCSI_CCI_RESET_COMPLETE before reset drivers/usb/typec/ucsi/ucsi.c | 56 ++++++++++++++++++++-- drivers/usb/typec/ucsi/ucsi_acpi.c | 75 +++++++++++++----------------- 2 files changed, 84 insertions(+), 47 deletions(-) -- 2.40.1
