lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 19 Oct 2020 16:44:58 +0300 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>, Rob Herring <robh+dt@...nel.org>, Lee Jones <lee.jones@...aro.org>, Mark Brown <broonie@...nel.org>, Maxime Ripard <mripard@...nel.org>, Alexandre Belloni <alexandre.belloni@...tlin.com>, Thierry Reding <treding@...dia.com>, Prashant Malani <pmalani@...omium.org>, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org, Amelie Delaunay <amelie.delaunay@...com> Subject: Re: [PATCH v10 11/15] usb: typec: tcpci_max77759: Fix vbus stuck on upon diconnecting sink On Wed, Oct 07, 2020 at 11:15:52PM -0700, Badhri Jagan Sridharan wrote: > Occasionally, POWER_STATUS.sourcing_vbus takes a while to clear after > writing to MAX_BUCK_BOOST_OP register. This causes vbus to turn back > on while disconnecting the sink. Overcome this issue by writing into > MAX_BUCK_BOOST_OP during frs while sourcing vbu, instead of always > into the register whenever POWER_STATUS.sourcing_vbus is set. > > Signed-off-by: Badhri Jagan Sridharan <badhri@...gle.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@...ux.intel.com> > --- > v9 is the first version of this patch. Added to fix > occasional bug of vbus turning back on when disconnecting the FRS accessory > after disconnect. No changes since v9. > --- > drivers/usb/typec/tcpm/tcpci_maxim.c | 28 ++++++++++++++-------------- > 1 file changed, 14 insertions(+), 14 deletions(-) > > diff --git a/drivers/usb/typec/tcpm/tcpci_maxim.c b/drivers/usb/typec/tcpm/tcpci_maxim.c > index 723d7dd38f75..43dcad95e897 100644 > --- a/drivers/usb/typec/tcpm/tcpci_maxim.c > +++ b/drivers/usb/typec/tcpm/tcpci_maxim.c > @@ -238,23 +238,22 @@ static void process_power_status(struct max_tcpci_chip *chip) > if (ret < 0) > return; > > - if (pwr_status == 0xff) { > + if (pwr_status == 0xff) > max_tcpci_init_regs(chip); > - } else if (pwr_status & TCPC_POWER_STATUS_SOURCING_VBUS) { > + else if (pwr_status & TCPC_POWER_STATUS_SOURCING_VBUS) > tcpm_sourcing_vbus(chip->port); > - /* > - * Alawys re-enable boost here. > - * In normal case, when say an headset is attached, TCPM would > - * have instructed to TCPC to enable boost, so the call is a > - * no-op. > - * But for Fast Role Swap case, Boost turns on autonomously without > - * AP intervention, but, needs AP to enable source mode explicitly > - * for AP to regain control. > - */ > - max_tcpci_set_vbus(chip->tcpci, &chip->data, true, false); > - } else { > + else > tcpm_vbus_change(chip->port); > - } > +} > + > +static void max_tcpci_frs_sourcing_vbus(struct tcpci *tcpci, struct tcpci_data *tdata) > +{ > + /* > + * For Fast Role Swap case, Boost turns on autonomously without > + * AP intervention, but, needs AP to enable source mode explicitly > + * for AP to regain control. > + */ > + max_tcpci_set_vbus(tcpci, tdata, true, false); > } > > static void process_tx(struct max_tcpci_chip *chip, u16 status) > @@ -441,6 +440,7 @@ static int max_tcpci_probe(struct i2c_client *client, const struct i2c_device_id > chip->data.start_drp_toggling = max_tcpci_start_toggling; > chip->data.TX_BUF_BYTE_x_hidden = true; > chip->data.init = tcpci_init; > + chip->data.frs_sourcing_vbus = max_tcpci_frs_sourcing_vbus; > > max_tcpci_init_regs(chip); > chip->tcpci = tcpci_register_port(chip->dev, &chip->data); > -- > 2.28.0.806.g8561365e88-goog -- heikki
Powered by blists - more mailing lists