| Message ID | ZR0P278MB07731B49E8938F98DB2098ABEBA49@ZR0P278MB0773.CHEP278.PROD.OUTLOOK.COM (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | AW: tcpci module in Kernel 5.15.74 with PTN5110 not working correctly | expand |
On Mon, Feb 20, 2023 at 04:45:32PM +0000, Christian Bach wrote: > Hello everyone > > We finally found a solution to the problem we had with the PTN5110 Chip and the Kernel Module tcpci that manages this chip in 5.15.xx Kernel. NXP Patched their Kernel a while ago (https://source.codeaurora.org/external/imx/linux-imx/commit/drivers/usb/typec/tcpm/tcpci.c?h=lf-5.15.y&id=2a263f918b25725e0434afa9ff3b83b1bc18ef74) and we reimplemented the NXP patch for the Kernel 5.15.91. I attached my reworked patch below: > > diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c > index 5340a3a3a81b..0d715e091b78 100644 > --- a/drivers/usb/typec/tcpm/tcpci.c > +++ b/drivers/usb/typec/tcpm/tcpci.c > @@ -628,6 +628,9 @@ static int tcpci_init(struct tcpc_dev *tcpc) > if (ret < 0) > return ret; > > + /* Clear fault condition */ > + regmap_write(tcpci->regmap, TCPC_FAULT_STATUS, 0x80); > + > if (tcpci->controls_vbus) > reg = TCPC_POWER_STATUS_VBUS_PRES; > else > @@ -644,7 +647,8 @@ static int tcpci_init(struct tcpc_dev *tcpc) > > reg = TCPC_ALERT_TX_SUCCESS | TCPC_ALERT_TX_FAILED | > TCPC_ALERT_TX_DISCARDED | TCPC_ALERT_RX_STATUS | > - TCPC_ALERT_RX_HARD_RST | TCPC_ALERT_CC_STATUS; > + TCPC_ALERT_RX_HARD_RST | TCPC_ALERT_CC_STATUS | > + TCPC_ALERT_V_ALARM_LO | TCPC_ALERT_FAULT; > if (tcpci->controls_vbus) > reg |= TCPC_ALERT_POWER_STATUS; > /* Enable VSAFE0V status interrupt when detecting VSAFE0V is supported */ > @@ -728,6 +732,13 @@ irqreturn_t tcpci_irq(struct tcpci *tcpci) > tcpm_vbus_change(tcpci->port); > } > > + /* Clear the fault status anyway */ > + if (status & TCPC_ALERT_FAULT) { > + regmap_read(tcpci->regmap, TCPC_FAULT_STATUS, &raw); > + regmap_write(tcpci->regmap, TCPC_FAULT_STATUS, > + raw | TCPC_FAULT_STATUS_MASK); > + } > + > if (status & TCPC_ALERT_RX_HARD_RST) > tcpm_pd_hard_reset(tcpci->port); > > > > > > > Can you submit this as a real fix so that we can apply it properly? thanks, greg k-h
On 2/20/23 10:54, Greg KH wrote: > On Mon, Feb 20, 2023 at 04:45:32PM +0000, Christian Bach wrote: >> Hello everyone >> >> We finally found a solution to the problem we had with the PTN5110 Chip and the Kernel Module tcpci that manages this chip in 5.15.xx Kernel. NXP Patched their Kernel a while ago (https://source.codeaurora.org/external/imx/linux-imx/commit/drivers/usb/typec/tcpm/tcpci.c?h=lf-5.15.y&id=2a263f918b25725e0434afa9ff3b83b1bc18ef74) and we reimplemented the NXP patch for the Kernel 5.15.91. I attached my reworked patch below: >> >> diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c >> index 5340a3a3a81b..0d715e091b78 100644 >> --- a/drivers/usb/typec/tcpm/tcpci.c >> +++ b/drivers/usb/typec/tcpm/tcpci.c >> @@ -628,6 +628,9 @@ static int tcpci_init(struct tcpc_dev *tcpc) >> if (ret < 0) >> return ret; >> >> + /* Clear fault condition */ >> + regmap_write(tcpci->regmap, TCPC_FAULT_STATUS, 0x80); >> + This should probably clear all fault bits. Also, the specification suggests to clear the fault bits prior to clearing fault alert event. >> if (tcpci->controls_vbus) >> reg = TCPC_POWER_STATUS_VBUS_PRES; >> else >> @@ -644,7 +647,8 @@ static int tcpci_init(struct tcpc_dev *tcpc) >> >> reg = TCPC_ALERT_TX_SUCCESS | TCPC_ALERT_TX_FAILED | >> TCPC_ALERT_TX_DISCARDED | TCPC_ALERT_RX_STATUS | >> - TCPC_ALERT_RX_HARD_RST | TCPC_ALERT_CC_STATUS; >> + TCPC_ALERT_RX_HARD_RST | TCPC_ALERT_CC_STATUS | >> + TCPC_ALERT_V_ALARM_LO | TCPC_ALERT_FAULT; >> if (tcpci->controls_vbus) >> reg |= TCPC_ALERT_POWER_STATUS; >> /* Enable VSAFE0V status interrupt when detecting VSAFE0V is supported */ >> @@ -728,6 +732,13 @@ irqreturn_t tcpci_irq(struct tcpci *tcpci) >> tcpm_vbus_change(tcpci->port); >> } >> >> + /* Clear the fault status anyway */ >> + if (status & TCPC_ALERT_FAULT) { >> + regmap_read(tcpci->regmap, TCPC_FAULT_STATUS, &raw); >> + regmap_write(tcpci->regmap, TCPC_FAULT_STATUS, >> + raw | TCPC_FAULT_STATUS_MASK); TCPC_FAULT_STATUS_MASK is a register address, so this doesn't really make sense. If the idea is to reset all active fault bits, just write 0xff. However, if faults are not really handled, it might be better to set TCPC_FAULT_STATUS_MASK to 0 instead of enabling fault alerts. It would probably be better to actually handle faults, but that may be more complex, and someone would have tho be able to test any changes. Guenter >> + } >> + >> if (status & TCPC_ALERT_RX_HARD_RST) >> tcpm_pd_hard_reset(tcpci->port); >> >> >> >> >> >> >> > > Can you submit this as a real fix so that we can apply it properly? > > thanks, > > greg k-h
diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c index 5340a3a3a81b..0d715e091b78 100644 --- a/drivers/usb/typec/tcpm/tcpci.c +++ b/drivers/usb/typec/tcpm/tcpci.c @@ -628,6 +628,9 @@ static int tcpci_init(struct tcpc_dev *tcpc) if (ret < 0) return ret; + /* Clear fault condition */ + regmap_write(tcpci->regmap, TCPC_FAULT_STATUS, 0x80); + if (tcpci->controls_vbus) reg = TCPC_POWER_STATUS_VBUS_PRES; else @@ -644,7 +647,8 @@ static int tcpci_init(struct tcpc_dev *tcpc) reg = TCPC_ALERT_TX_SUCCESS | TCPC_ALERT_TX_FAILED | TCPC_ALERT_TX_DISCARDED | TCPC_ALERT_RX_STATUS | - TCPC_ALERT_RX_HARD_RST | TCPC_ALERT_CC_STATUS; + TCPC_ALERT_RX_HARD_RST | TCPC_ALERT_CC_STATUS | + TCPC_ALERT_V_ALARM_LO | TCPC_ALERT_FAULT; if (tcpci->controls_vbus) reg |= TCPC_ALERT_POWER_STATUS; /* Enable VSAFE0V status interrupt when detecting VSAFE0V is supported */ @@ -728,6 +732,13 @@ irqreturn_t tcpci_irq(struct tcpci *tcpci) tcpm_vbus_change(tcpci->port); } + /* Clear the fault status anyway */ + if (status & TCPC_ALERT_FAULT) { + regmap_read(tcpci->regmap, TCPC_FAULT_STATUS, &raw); + regmap_write(tcpci->regmap, TCPC_FAULT_STATUS, + raw | TCPC_FAULT_STATUS_MASK); + } + if (status & TCPC_ALERT_RX_HARD_RST) tcpm_pd_hard_reset(tcpci->port);