[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2024091156-astronomy-licorice-5569@gregkh>
Date: Wed, 11 Sep 2024 15:37:25 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: "Christian A. Ehrhardt" <lk@...e.de>
Cc: linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
Anurag Bijea <icaliberdev@...il.com>,
Christian Heusel <christian@...sel.eu>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Jameson Thies <jthies@...gle.com>,
Abhishek Pandit-Subedi <abhishekpandit@...omium.org>
Subject: Re: [PATCH v4] usb: typec: ucsi: Fix busy loop on ASUS VivoBooks
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@...il.com>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219108
> Bisected-by: Christian Heusel <christian@...sel.eu>
> Tested-by: Anurag Bijea <icaliberdev@...il.com>
> Fixes: de52aca4d9d5 ("usb: typec: ucsi: Never send a lone connector change ack")
> Cc: stable@...r.kernel.org
> Signed-off-by: Christian A. Ehrhardt <lk@...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
Powered by blists - more mailing lists