| Message ID | 20240906065853.637205-1-lk@c--e.de (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v4] usb: typec: ucsi: Fix busy loop on ASUS VivoBooks | expand |
On Fri, Sep 06, 2024 at 08:58:53AM +0200, Christian A. Ehrhardt wrote: > If the busy indicator is set, all other fields in CCI should be > clear according to the spec. However, some UCSI implementations do > not follow this rule and report bogus data in CCI along with the > busy indicator. Ignore the contents of CCI if the busy indicator is > set. > > If a command timeout is hit it is possible that the EVENT_PENDING > bit is cleared while connector work is still scheduled which can > cause the EVENT_PENDING bit to go out of sync with scheduled connector > work. Check and set the EVENT_PENDING bit on entry to > ucsi_handle_connector_change() to fix this. > > Finally, check UCSI_CCI_BUSY before the return code of ->sync_control. > This ensures that the command is cancelled even if ->sync_control > returns an error (most likely -ETIMEDOUT). > > Reported-by: Anurag Bijea <icaliberdev@gmail.com> > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219108 > Bisected-by: Christian Heusel <christian@heusel.eu> > Tested-by: Anurag Bijea <icaliberdev@gmail.com> > Fixes: de52aca4d9d5 ("usb: typec: ucsi: Never send a lone connector change ack") > Cc: stable@vger.kernel.org > Signed-off-by: Christian A. Ehrhardt <lk@c--e.de> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> > --- > drivers/usb/typec/ucsi/ucsi.c | 18 ++++++++++++------ > 1 file changed, 12 insertions(+), 6 deletions(-) > > diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c > index 4039851551c1..d6d61606bbcf 100644 > --- a/drivers/usb/typec/ucsi/ucsi.c > +++ b/drivers/usb/typec/ucsi/ucsi.c > @@ -38,6 +38,10 @@ > > void ucsi_notify_common(struct ucsi *ucsi, u32 cci) > { > + /* Ignore bogus data in CCI if busy indicator is set. */ > + if (cci & UCSI_CCI_BUSY) > + return; > + > if (UCSI_CCI_CONNECTOR(cci)) > ucsi_connector_change(ucsi, UCSI_CCI_CONNECTOR(cci)); > > @@ -107,15 +111,13 @@ static int ucsi_run_command(struct ucsi *ucsi, u64 command, u32 *cci, > size = clamp(size, 0, 16); > > ret = ucsi->ops->sync_control(ucsi, command); > - if (ret) > - return ret; > - > - ret = ucsi->ops->read_cci(ucsi, cci); > - if (ret) > - return ret; > + if (ucsi->ops->read_cci(ucsi, cci)) > + return -EIO; > > if (*cci & UCSI_CCI_BUSY) > return -EBUSY; > + if (ret) > + return ret; > > if (!(*cci & UCSI_CCI_COMMAND_COMPLETE)) > return -EIO; > @@ -1249,6 +1251,10 @@ static void ucsi_handle_connector_change(struct work_struct *work) > > mutex_lock(&con->lock); > > + if (!test_and_set_bit(EVENT_PENDING, &ucsi->flags)) > + dev_err_once(ucsi->dev, "%s entered without EVENT_PENDING\n", > + __func__); > + > command = UCSI_GET_CONNECTOR_STATUS | UCSI_CONNECTOR_NUMBER(con->num); > > ret = ucsi_send_command_common(ucsi, command, &con->status, > -- > 2.43.0
On Fri, Sep 06, 2024 at 08:58:53AM +0200, Christian A. Ehrhardt wrote: > If the busy indicator is set, all other fields in CCI should be > clear according to the spec. However, some UCSI implementations do > not follow this rule and report bogus data in CCI along with the > busy indicator. Ignore the contents of CCI if the busy indicator is > set. > > If a command timeout is hit it is possible that the EVENT_PENDING > bit is cleared while connector work is still scheduled which can > cause the EVENT_PENDING bit to go out of sync with scheduled connector > work. Check and set the EVENT_PENDING bit on entry to > ucsi_handle_connector_change() to fix this. > > Finally, check UCSI_CCI_BUSY before the return code of ->sync_control. > This ensures that the command is cancelled even if ->sync_control > returns an error (most likely -ETIMEDOUT). > > Reported-by: Anurag Bijea <icaliberdev@gmail.com> > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219108 > Bisected-by: Christian Heusel <christian@heusel.eu> > Tested-by: Anurag Bijea <icaliberdev@gmail.com> > Fixes: de52aca4d9d5 ("usb: typec: ucsi: Never send a lone connector change ack") > Cc: stable@vger.kernel.org > Signed-off-by: Christian A. Ehrhardt <lk@c--e.de> > --- > drivers/usb/typec/ucsi/ucsi.c | 18 ++++++++++++------ > 1 file changed, 12 insertions(+), 6 deletions(-) Does not apply to my usb-next branch :( Can you rebase and resend this? Or wait until -rc1 is out and rebase and resend then? thanks, greg k-h
Hi, On Wed, Sep 11, 2024 at 03:37:25PM +0200, Greg Kroah-Hartman wrote: > On Fri, Sep 06, 2024 at 08:58:53AM +0200, Christian A. Ehrhardt wrote: > > If the busy indicator is set, all other fields in CCI should be > > clear according to the spec. However, some UCSI implementations do > > not follow this rule and report bogus data in CCI along with the > > busy indicator. Ignore the contents of CCI if the busy indicator is > > set. > > > > If a command timeout is hit it is possible that the EVENT_PENDING > > bit is cleared while connector work is still scheduled which can > > cause the EVENT_PENDING bit to go out of sync with scheduled connector > > work. Check and set the EVENT_PENDING bit on entry to > > ucsi_handle_connector_change() to fix this. > > > > Finally, check UCSI_CCI_BUSY before the return code of ->sync_control. > > This ensures that the command is cancelled even if ->sync_control > > returns an error (most likely -ETIMEDOUT). > > > > Reported-by: Anurag Bijea <icaliberdev@gmail.com> > > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219108 > > Bisected-by: Christian Heusel <christian@heusel.eu> > > Tested-by: Anurag Bijea <icaliberdev@gmail.com> > > Fixes: de52aca4d9d5 ("usb: typec: ucsi: Never send a lone connector change ack") > > Cc: stable@vger.kernel.org > > Signed-off-by: Christian A. Ehrhardt <lk@c--e.de> > > --- > > drivers/usb/typec/ucsi/ucsi.c | 18 ++++++++++++------ > > 1 file changed, 12 insertions(+), 6 deletions(-) > > Does not apply to my usb-next branch :( > > Can you rebase and resend this? Or wait until -rc1 is out and rebase > and resend then? I sent a v5 rebased onto usb-next. Best regards, Christian
On Thu, 12 Sept 2024 at 09:08, Christian A. Ehrhardt <lk@c--e.de> wrote: > > > Hi, > > On Wed, Sep 11, 2024 at 03:37:25PM +0200, Greg Kroah-Hartman wrote: > > On Fri, Sep 06, 2024 at 08:58:53AM +0200, Christian A. Ehrhardt wrote: > > > If the busy indicator is set, all other fields in CCI should be > > > clear according to the spec. However, some UCSI implementations do > > > not follow this rule and report bogus data in CCI along with the > > > busy indicator. Ignore the contents of CCI if the busy indicator is > > > set. > > > > > > If a command timeout is hit it is possible that the EVENT_PENDING > > > bit is cleared while connector work is still scheduled which can > > > cause the EVENT_PENDING bit to go out of sync with scheduled connector > > > work. Check and set the EVENT_PENDING bit on entry to > > > ucsi_handle_connector_change() to fix this. > > > > > > Finally, check UCSI_CCI_BUSY before the return code of ->sync_control. > > > This ensures that the command is cancelled even if ->sync_control > > > returns an error (most likely -ETIMEDOUT). > > > > > > Reported-by: Anurag Bijea <icaliberdev@gmail.com> > > > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219108 > > > Bisected-by: Christian Heusel <christian@heusel.eu> > > > Tested-by: Anurag Bijea <icaliberdev@gmail.com> > > > Fixes: de52aca4d9d5 ("usb: typec: ucsi: Never send a lone connector change ack") > > > Cc: stable@vger.kernel.org > > > Signed-off-by: Christian A. Ehrhardt <lk@c--e.de> > > > --- > > > drivers/usb/typec/ucsi/ucsi.c | 18 ++++++++++++------ > > > 1 file changed, 12 insertions(+), 6 deletions(-) > > > > Does not apply to my usb-next branch :( > > > > Can you rebase and resend this? Or wait until -rc1 is out and rebase > > and resend then? > > I sent a v5 rebased onto usb-next. Note, it wasn't marked as v5, it didn't contain a changelog, etc. Please consider using the `b4` tool to send patches. It automates versioning, changelog generation, etc. > > Best regards, > Christian
On Thu, Sep 12, 2024 at 09:21:39AM +0300, Dmitry Baryshkov wrote: > On Thu, 12 Sept 2024 at 09:08, Christian A. Ehrhardt <lk@c--e.de> wrote: > > > > > > Hi, > > > > On Wed, Sep 11, 2024 at 03:37:25PM +0200, Greg Kroah-Hartman wrote: > > > On Fri, Sep 06, 2024 at 08:58:53AM +0200, Christian A. Ehrhardt wrote: > > > > If the busy indicator is set, all other fields in CCI should be > > > > clear according to the spec. However, some UCSI implementations do > > > > not follow this rule and report bogus data in CCI along with the > > > > busy indicator. Ignore the contents of CCI if the busy indicator is > > > > set. > > > > > > > > If a command timeout is hit it is possible that the EVENT_PENDING > > > > bit is cleared while connector work is still scheduled which can > > > > cause the EVENT_PENDING bit to go out of sync with scheduled connector > > > > work. Check and set the EVENT_PENDING bit on entry to > > > > ucsi_handle_connector_change() to fix this. > > > > > > > > Finally, check UCSI_CCI_BUSY before the return code of ->sync_control. > > > > This ensures that the command is cancelled even if ->sync_control > > > > returns an error (most likely -ETIMEDOUT). > > > > > > > > Reported-by: Anurag Bijea <icaliberdev@gmail.com> > > > > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219108 > > > > Bisected-by: Christian Heusel <christian@heusel.eu> > > > > Tested-by: Anurag Bijea <icaliberdev@gmail.com> > > > > Fixes: de52aca4d9d5 ("usb: typec: ucsi: Never send a lone connector change ack") > > > > Cc: stable@vger.kernel.org > > > > Signed-off-by: Christian A. Ehrhardt <lk@c--e.de> > > > > --- > > > > drivers/usb/typec/ucsi/ucsi.c | 18 ++++++++++++------ > > > > 1 file changed, 12 insertions(+), 6 deletions(-) > > > > > > Does not apply to my usb-next branch :( > > > > > > Can you rebase and resend this? Or wait until -rc1 is out and rebase > > > and resend then? > > > > I sent a v5 rebased onto usb-next. > > Note, it wasn't marked as v5, it didn't contain a changelog, etc. > Please consider using the `b4` tool to send patches. It automates > versioning, changelog generation, etc. Yes, this needs to be properly marked as such, my patch-bot already noticed that :(
diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c index 4039851551c1..d6d61606bbcf 100644 --- a/drivers/usb/typec/ucsi/ucsi.c +++ b/drivers/usb/typec/ucsi/ucsi.c @@ -38,6 +38,10 @@ void ucsi_notify_common(struct ucsi *ucsi, u32 cci) { + /* Ignore bogus data in CCI if busy indicator is set. */ + if (cci & UCSI_CCI_BUSY) + return; + if (UCSI_CCI_CONNECTOR(cci)) ucsi_connector_change(ucsi, UCSI_CCI_CONNECTOR(cci)); @@ -107,15 +111,13 @@ static int ucsi_run_command(struct ucsi *ucsi, u64 command, u32 *cci, size = clamp(size, 0, 16); ret = ucsi->ops->sync_control(ucsi, command); - if (ret) - return ret; - - ret = ucsi->ops->read_cci(ucsi, cci); - if (ret) - return ret; + if (ucsi->ops->read_cci(ucsi, cci)) + return -EIO; if (*cci & UCSI_CCI_BUSY) return -EBUSY; + if (ret) + return ret; if (!(*cci & UCSI_CCI_COMMAND_COMPLETE)) return -EIO; @@ -1249,6 +1251,10 @@ static void ucsi_handle_connector_change(struct work_struct *work) mutex_lock(&con->lock); + if (!test_and_set_bit(EVENT_PENDING, &ucsi->flags)) + dev_err_once(ucsi->dev, "%s entered without EVENT_PENDING\n", + __func__); + command = UCSI_GET_CONNECTOR_STATUS | UCSI_CONNECTOR_NUMBER(con->num); ret = ucsi_send_command_common(ucsi, command, &con->status,