[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YEYEYKqUgnaijOmP@kuha.fi.intel.com>
Date: Mon, 8 Mar 2021 13:02:56 +0200
From: Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To: Badhri Jagan Sridharan <badhri@...gle.com>
Cc: Guenter Roeck <linux@...ck-us.net>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
Kyle Tso <kyletso@...gle.com>, stable@...r.kernel.org
Subject: Re: [PATCH v1] usb: typec: tcpci: Check ROLE_CONTROL while
interpreting CC_STATUS
On Wed, Mar 03, 2021 at 11:09:31PM -0800, Badhri Jagan Sridharan wrote:
> While interpreting CC_STATUS, ROLE_CONTROL has to be read to make
> sure that CC1/CC2 is not forced presenting Rp/Rd.
>
> >From the TCPCI spec:
>
> 4.4.5.2 ROLE_CONTROL (Normative):
> The TCPM shall write B6 (DRP) = 0b and B3..0 (CC1/CC2) if it wishes
> to control the Rp/Rd directly instead of having the TCPC perform
> DRP toggling autonomously. When controlling Rp/Rd directly, the
> TCPM writes to B3..0 (CC1/CC2) each time it wishes to change the
> CC1/CC2 values. This control is used for TCPM-TCPC implementing
> Source or Sink only as well as when a connection has been detected
> via DRP toggling but the TCPM wishes to attempt Try.Src or Try.Snk.
>
> Table 4-22. CC_STATUS Register Definition:
> If (ROLE_CONTROL.CC1 = Rd) or ConnectResult=1)
> 00b: SNK.Open (Below maximum vRa)
> 01b: SNK.Default (Above minimum vRd-Connect)
> 10b: SNK.Power1.5 (Above minimum vRd-Connect) Detects Rp-1.5A
> 11b: SNK.Power3.0 (Above minimum vRd-Connect) Detects Rp-3.0A
>
> If (ROLE_CONTROL.CC2=Rd) or (ConnectResult=1)
> 00b: SNK.Open (Below maximum vRa)
> 01b: SNK.Default (Above minimum vRd-Connect)
> 10b: SNK.Power1.5 (Above minimum vRd-Connect) Detects Rp 1.5A
> 11b: SNK.Power3.0 (Above minimum vRd-Connect) Detects Rp 3.0A
>
> Fixes: 74e656d6b0551 ("staging: typec: Type-C Port Controller
> Interface driver (tcpci)")
> Signed-off-by: Badhri Jagan Sridharan <badhri@...gle.com>
Acked-by: Heikki Krogerus <heikki.krogerus@...ux.intel.com>
> ---
> drivers/usb/typec/tcpm/tcpci.c | 21 ++++++++++++++++++---
> 1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c
> index a27deb0b5f03..027afd7dfdce 100644
> --- a/drivers/usb/typec/tcpm/tcpci.c
> +++ b/drivers/usb/typec/tcpm/tcpci.c
> @@ -24,6 +24,15 @@
> #define AUTO_DISCHARGE_PD_HEADROOM_MV 850
> #define AUTO_DISCHARGE_PPS_HEADROOM_MV 1250
>
> +#define tcpc_presenting_cc1_rd(reg) \
> + (!(TCPC_ROLE_CTRL_DRP & (reg)) && \
> + (((reg) & (TCPC_ROLE_CTRL_CC1_MASK << TCPC_ROLE_CTRL_CC1_SHIFT)) == \
> + (TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC1_SHIFT)))
> +#define tcpc_presenting_cc2_rd(reg) \
> + (!(TCPC_ROLE_CTRL_DRP & (reg)) && \
> + (((reg) & (TCPC_ROLE_CTRL_CC2_MASK << TCPC_ROLE_CTRL_CC2_SHIFT)) == \
> + (TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC2_SHIFT)))
> +
Couldn't you handle that with a single macro by concatenating the CC
line numbers?
> struct tcpci {
> struct device *dev;
>
> @@ -178,19 +187,25 @@ static int tcpci_get_cc(struct tcpc_dev *tcpc,
> enum typec_cc_status *cc1, enum typec_cc_status *cc2)
> {
> struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
> - unsigned int reg;
> + unsigned int reg, role_control;
> int ret;
>
> + ret = regmap_read(tcpci->regmap, TCPC_ROLE_CTRL, &role_control);
> + if (ret < 0)
> + return ret;
> +
> ret = regmap_read(tcpci->regmap, TCPC_CC_STATUS, ®);
> if (ret < 0)
> return ret;
>
> *cc1 = tcpci_to_typec_cc((reg >> TCPC_CC_STATUS_CC1_SHIFT) &
> TCPC_CC_STATUS_CC1_MASK,
> - reg & TCPC_CC_STATUS_TERM);
> + reg & TCPC_CC_STATUS_TERM ||
> + tcpc_presenting_cc1_rd(role_control));
> *cc2 = tcpci_to_typec_cc((reg >> TCPC_CC_STATUS_CC2_SHIFT) &
> TCPC_CC_STATUS_CC2_MASK,
> - reg & TCPC_CC_STATUS_TERM);
> + reg & TCPC_CC_STATUS_TERM ||
> + tcpc_presenting_cc2_rd(role_control));
>
> return 0;
> }
> --
> 2.30.1.766.gb4fecdf3b7-goog
thanks,
--
heikki
Powered by blists - more mailing lists