On Fri, Jul 26, 2024 at 07:01:13AM +0100, André Draszik wrote: > Hi, > > On Wed, 2024-07-10 at 07:28 +0100, André Draszik wrote: > > tcpci_maxim currently never triggers the TCPM state machine when CC > > status has not changed due to a contaminant but due to a real > > connection event, i.e. a genuine plug event, meaning the system will > > stay idle and not notify any subscribers. > > > > The reason is that the initial state of the port is 'toggling', which > > causes _max_tcpci_irq() to only drive the contamination part of the > > TCPM state machine (via tcpm_port_clean()). > > > > What should happen instead is that if no contamination was detected, > > the TCPM should be notified of the CC change in this case. > > > > To fix this, we update ...is_contaminant() to also allow its caller to > > determine if more CC processing is required and then call into the TCPM > > as required. > > > > While at it, add a kernel-doc for max_contaminant_is_contaminant(). > > > > Note: the code has an issue where I2C errors during contaminant > > detection also cause the TCPM state machine to not be updated. This > > commit doesn't change this behaviour and should be addressed by > > follow-up commit(s). > > > > Signed-off-by: André Draszik <andre.draszik@xxxxxxxxxx> > > --- > > drivers/usb/typec/tcpm/maxim_contaminant.c | 7 +++++-- > > drivers/usb/typec/tcpm/tcpci_maxim.h | 15 ++++++++++++++- > > drivers/usb/typec/tcpm/tcpci_maxim_core.c | 12 ++++++++---- > > 3 files changed, 27 insertions(+), 7 deletions(-) > > Any comments on this patch? It's the middle of the merge window, nothing we can do until -rc1 is out... thanks, greg k-h
