drivers/usb/typec/tcpm/tcpci.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-)
Add minimal handling to clear the ALERT.Fault bit which may be set in
case of an over-current or over-voltage detection. At the moment only
the IRQ clear support is added since the TCPC Spec mentions that the
handling of such events is vendor specific.
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
---
drivers/usb/typec/tcpm/tcpci.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c
index a56e31b20c21..d2d5bf7ca618 100644
--- a/drivers/usb/typec/tcpm/tcpci.c
+++ b/drivers/usb/typec/tcpm/tcpci.c
@@ -692,7 +692,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_FAULT;
if (tcpci->controls_vbus)
reg |= TCPC_ALERT_POWER_STATUS;
/* Enable VSAFE0V status interrupt when detecting VSAFE0V is supported */
@@ -720,6 +721,19 @@ irqreturn_t tcpci_irq(struct tcpci *tcpci)
irq_ret = status & tcpci->alert_mask;
process_status:
+ /*
+ * Handle nested fault before clearing the alert status to not
+ * re-trigger a fault alert immediately again.
+ */
+ if (status & TCPC_ALERT_FAULT) {
+ unsigned int fault;
+
+ /* TODO: Add a proper over-current and over-voltage handling */
+ ret = regmap_read(tcpci->regmap, TCPC_FAULT_STATUS, &fault);
+ if (!ret)
+ regmap_write(tcpci->regmap, TCPC_FAULT_STATUS, fault);
+ }
+
/*
* Clear alert status for everything except RX_STATUS, which shouldn't
* be cleared until we have successfully retrieved message.
--
2.47.3
On Fri, Jul 31, 2026 at 10:34:59AM +0200, Marco Felsch wrote:
> Add minimal handling to clear the ALERT.Fault bit which may be set in
> case of an over-current or over-voltage detection. At the moment only
> the IRQ clear support is added since the TCPC Spec mentions that the
> handling of such events is vendor specific.
>
> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
> ---
> drivers/usb/typec/tcpm/tcpci.c | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c
> index a56e31b20c21..d2d5bf7ca618 100644
> --- a/drivers/usb/typec/tcpm/tcpci.c
> +++ b/drivers/usb/typec/tcpm/tcpci.c
> @@ -692,7 +692,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_FAULT;
> if (tcpci->controls_vbus)
> reg |= TCPC_ALERT_POWER_STATUS;
> /* Enable VSAFE0V status interrupt when detecting VSAFE0V is supported */
> @@ -720,6 +721,19 @@ irqreturn_t tcpci_irq(struct tcpci *tcpci)
> irq_ret = status & tcpci->alert_mask;
>
> process_status:
> + /*
> + * Handle nested fault before clearing the alert status to not
> + * re-trigger a fault alert immediately again.
> + */
Shouldn't that explanation in the comment be also in the commit
message? That sounds like the "why" part to me.
> + if (status & TCPC_ALERT_FAULT) {
> + unsigned int fault;
> +
> + /* TODO: Add a proper over-current and over-voltage handling */
> + ret = regmap_read(tcpci->regmap, TCPC_FAULT_STATUS, &fault);
> + if (!ret)
> + regmap_write(tcpci->regmap, TCPC_FAULT_STATUS, fault);
> + }
> +
> /*
> * Clear alert status for everything except RX_STATUS, which shouldn't
> * be cleared until we have successfully retrieved message.
> --
> 2.47.3
--
heikki
On 26-08-05, Heikki Krogerus wrote:
> On Fri, Jul 31, 2026 at 10:34:59AM +0200, Marco Felsch wrote:
> > Add minimal handling to clear the ALERT.Fault bit which may be set in
> > case of an over-current or over-voltage detection. At the moment only
> > the IRQ clear support is added since the TCPC Spec mentions that the
> > handling of such events is vendor specific.
> >
> > Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
> > ---
> > drivers/usb/typec/tcpm/tcpci.c | 16 +++++++++++++++-
> > 1 file changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c
> > index a56e31b20c21..d2d5bf7ca618 100644
> > --- a/drivers/usb/typec/tcpm/tcpci.c
> > +++ b/drivers/usb/typec/tcpm/tcpci.c
> > @@ -692,7 +692,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_FAULT;
> > if (tcpci->controls_vbus)
> > reg |= TCPC_ALERT_POWER_STATUS;
> > /* Enable VSAFE0V status interrupt when detecting VSAFE0V is supported */
> > @@ -720,6 +721,19 @@ irqreturn_t tcpci_irq(struct tcpci *tcpci)
> > irq_ret = status & tcpci->alert_mask;
> >
> > process_status:
> > + /*
> > + * Handle nested fault before clearing the alert status to not
> > + * re-trigger a fault alert immediately again.
> > + */
>
> Shouldn't that explanation in the comment be also in the commit
> message? That sounds like the "why" part to me.
I don't think so, it's just a comment for $dev that this ordering is
important. The commit message clearly states that an over-current or
over-voltage may trigger this.
Regards,
Marco
> > + if (status & TCPC_ALERT_FAULT) {
> > + unsigned int fault;
> > +
> > + /* TODO: Add a proper over-current and over-voltage handling */
> > + ret = regmap_read(tcpci->regmap, TCPC_FAULT_STATUS, &fault);
> > + if (!ret)
> > + regmap_write(tcpci->regmap, TCPC_FAULT_STATUS, fault);
> > + }
> > +
> > /*
> > * Clear alert status for everything except RX_STATUS, which shouldn't
> > * be cleared until we have successfully retrieved message.
> > --
> > 2.47.3
>
> --
> heikki
>
--
#gernperDu
#CallMeByMyFirstName
Pengutronix e.K. | |
Steuerwalder Str. 21 | https://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
On Wed, Aug 05, 2026 at 03:45:20PM +0200, Marco Felsch wrote: > On 26-08-05, Heikki Krogerus wrote: > > On Fri, Jul 31, 2026 at 10:34:59AM +0200, Marco Felsch wrote: > > > Add minimal handling to clear the ALERT.Fault bit which may be set in > > > case of an over-current or over-voltage detection. At the moment only > > > the IRQ clear support is added since the TCPC Spec mentions that the > > > handling of such events is vendor specific. > > > > > > Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> > > > --- > > > drivers/usb/typec/tcpm/tcpci.c | 16 +++++++++++++++- > > > 1 file changed, 15 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c > > > index a56e31b20c21..d2d5bf7ca618 100644 > > > --- a/drivers/usb/typec/tcpm/tcpci.c > > > +++ b/drivers/usb/typec/tcpm/tcpci.c > > > @@ -692,7 +692,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_FAULT; > > > if (tcpci->controls_vbus) > > > reg |= TCPC_ALERT_POWER_STATUS; > > > /* Enable VSAFE0V status interrupt when detecting VSAFE0V is supported */ > > > @@ -720,6 +721,19 @@ irqreturn_t tcpci_irq(struct tcpci *tcpci) > > > irq_ret = status & tcpci->alert_mask; > > > > > > process_status: > > > + /* > > > + * Handle nested fault before clearing the alert status to not > > > + * re-trigger a fault alert immediately again. > > > + */ > > > > Shouldn't that explanation in the comment be also in the commit > > message? That sounds like the "why" part to me. > > I don't think so, it's just a comment for $dev that this ordering is > important. The commit message clearly states that an over-current or > over-voltage may trigger this. Fair enough. Let's wait for Badhri, but FWIW: Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> -- heikki
© 2016 - 2026 Red Hat, Inc.