linux-kernel - Re: [PATCH v1] usb: core: hub: disable autosuspend for TI TUSB8041

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 16 Dec 2022 10:49:47 -0500
From:   Alan Stern <stern@...land.harvard.edu>
To:     Flavio Suligoi <f.suligoi@...m.it>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Mathias Nyman <mathias.nyman@...ux.intel.com>,
        Kai-Heng Feng <kai.heng.feng@...onical.com>,
        Michael Grzeschik <m.grzeschik@...gutronix.de>,
        Ray Chi <raychi@...gle.com>,
        Bhuvanesh Surachari <Bhuvanesh_Surachari@...tor.com>,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] usb: core: hub: disable autosuspend for TI TUSB8041

On Fri, Dec 16, 2022 at 03:17:17PM +0100, Flavio Suligoi wrote:
> The Texas Instruments TUSB8041 has an autosuspend problem at high
> temperature.
> 
> If there is not USB traffic, after a couple of ms, the device enters in
> autosuspend mode. In this condition the external clock stops working, to
> save energy. When the USB activity turns on, ther hub exits the
> autosuspend state, the clock starts running again and all works fine.
> 
> At ambient temperature all works correctly, but at high temperature,
> when the USB activity turns on, the external clock doesn't restart and
> the hub disappears from the USB bus.
> 
> Disabling the autosuspend mode for this hub solves the issue.
> 
> Signed-off-by: Flavio Suligoi <f.suligoi@...m.it>
> ---
>  drivers/usb/core/hub.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index 77e73fc8d673..b64be35e203f 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -44,6 +44,10 @@
>  #define USB_PRODUCT_USB5534B			0x5534
>  #define USB_VENDOR_CYPRESS			0x04b4
>  #define USB_PRODUCT_CY7C65632			0x6570
> +#define USB_VENDOR_TEXAS_INSTRUMENTS		0x0451
> +#define USB_PRODUCT_TUSB8041_USB3		0x8140
> +#define USB_PRODUCT_TUSB8041_USB2		\
> +	(USB_PRODUCT_TUSB8041_USB3 | ((USB_PRODUCT_TUSB8041_USB3 & 0x00FF) ^ 0x02))

Argh.  Just put the actual hex number here -- people don't want to do 
calculations like this in their head when they are reading code.  (Not 
to mention that the number would occupy only six characters of source 
text whereas your calculation occupies a lot more.)

Otherwise fine.

Alan Stern

>  #define HUB_QUIRK_CHECK_PORT_AUTOSUSPEND	0x01
>  #define HUB_QUIRK_DISABLE_AUTOSUSPEND		0x02
>  
> @@ -5854,6 +5858,16 @@ static const struct usb_device_id hub_id_table[] = {
>        .idVendor = USB_VENDOR_GENESYS_LOGIC,
>        .bInterfaceClass = USB_CLASS_HUB,
>        .driver_info = HUB_QUIRK_CHECK_PORT_AUTOSUSPEND},
> +    { .match_flags = USB_DEVICE_ID_MATCH_VENDOR
> +			| USB_DEVICE_ID_MATCH_PRODUCT,
> +      .idVendor = USB_VENDOR_TEXAS_INSTRUMENTS,
> +      .idProduct = USB_PRODUCT_TUSB8041_USB2,
> +      .driver_info = HUB_QUIRK_DISABLE_AUTOSUSPEND},
> +    { .match_flags = USB_DEVICE_ID_MATCH_VENDOR
> +			| USB_DEVICE_ID_MATCH_PRODUCT,
> +      .idVendor = USB_VENDOR_TEXAS_INSTRUMENTS,
> +      .idProduct = USB_PRODUCT_TUSB8041_USB3,
> +      .driver_info = HUB_QUIRK_DISABLE_AUTOSUSPEND},
>      { .match_flags = USB_DEVICE_ID_MATCH_DEV_CLASS,
>        .bDeviceClass = USB_CLASS_HUB},
>      { .match_flags = USB_DEVICE_ID_MATCH_INT_CLASS,
> -- 
> 2.25.1
>