[PATCH 2/2] xhci: Apply broken streams quirk to Etron EJ188 xHCI host

[PATCH 2/2] xhci: Apply broken streams quirk to Etron EJ188 xHCI host

[Kuangyi Chiang]

As described in commit 8f873c1ff4ca ("xhci: Blacklist using streams on the
Etron EJ168 controller"), EJ188 have the same issue as EJ168, where Streams
do not work reliable on EJ188. So apply XHCI_BROKEN_STREAMS quirk to EJ188
as well.

Signed-off-by: Kuangyi Chiang <ki.chiang65@gmail.com>
---
 drivers/usb/host/xhci-pci.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index a0beb41..5591e6d 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -242,6 +242,7 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
 	if (pdev->vendor == PCI_VENDOR_ID_ETRON &&
 			pdev->device == PCI_DEVICE_ID_EJ188) {
 		xhci->quirks |= XHCI_RESET_ON_RESUME;
+		xhci->quirks |= XHCI_BROKEN_STREAMS;
 	}
 	if (pdev->vendor == PCI_VENDOR_ID_RENESAS &&
 	    pdev->device == 0x0014) {
-- 
2.25.1

[PATCH 1/2] xhci: Apply reset resume quirk to Etron EJ188 xHCI host

[Kuangyi Chiang]

As described in commit c877b3b2ad5c ("xhci: Add reset on resume quirk for
asrock p67 host"), EJ188 have the same issue as EJ168, where completely
dies on resume. So apply XHCI_RESET_ON_RESUME quirk to EJ188 as well.

Signed-off-by: Kuangyi Chiang <ki.chiang65@gmail.com>
---
 drivers/usb/host/xhci-pci.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index ef513c2..a0beb41 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -31,6 +31,7 @@
 
 #define PCI_VENDOR_ID_ETRON		0x1b6f
 #define PCI_DEVICE_ID_EJ168		0x7023
+#define PCI_DEVICE_ID_EJ188		0x7052
 
 #define PCI_DEVICE_ID_INTEL_LYNXPOINT_XHCI	0x8c31
 #define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI	0x9c31
@@ -238,6 +239,10 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
 		xhci->quirks |= XHCI_TRUST_TX_LENGTH;
 		xhci->quirks |= XHCI_BROKEN_STREAMS;
 	}
+	if (pdev->vendor == PCI_VENDOR_ID_ETRON &&
+			pdev->device == PCI_DEVICE_ID_EJ188) {
+		xhci->quirks |= XHCI_RESET_ON_RESUME;
+	}
 	if (pdev->vendor == PCI_VENDOR_ID_RENESAS &&
 	    pdev->device == 0x0014) {
 		xhci->quirks |= XHCI_TRUST_TX_LENGTH;
-- 
2.25.1

Re: [PATCH 1/2] xhci: Apply reset resume quirk to Etron EJ188 xHCI host

[Greg KH]

On Wed, May 22, 2024 at 10:39:18AM +0800, Kuangyi Chiang wrote:
> As described in commit c877b3b2ad5c ("xhci: Add reset on resume quirk for
> asrock p67 host"), EJ188 have the same issue as EJ168, where completely
> dies on resume. So apply XHCI_RESET_ON_RESUME quirk to EJ188 as well.
> 
> Signed-off-by: Kuangyi Chiang <ki.chiang65@gmail.com>
> ---
>  drivers/usb/host/xhci-pci.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index ef513c2..a0beb41 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -31,6 +31,7 @@
>  
>  #define PCI_VENDOR_ID_ETRON		0x1b6f
>  #define PCI_DEVICE_ID_EJ168		0x7023
> +#define PCI_DEVICE_ID_EJ188		0x7052
>  
>  #define PCI_DEVICE_ID_INTEL_LYNXPOINT_XHCI	0x8c31
>  #define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI	0x9c31
> @@ -238,6 +239,10 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
>  		xhci->quirks |= XHCI_TRUST_TX_LENGTH;
>  		xhci->quirks |= XHCI_BROKEN_STREAMS;
>  	}
> +	if (pdev->vendor == PCI_VENDOR_ID_ETRON &&
> +			pdev->device == PCI_DEVICE_ID_EJ188) {
> +		xhci->quirks |= XHCI_RESET_ON_RESUME;
> +	}

Same question as on other patch, should this be backported to older
kernels too?

thanks,

greg k-h

Re: [PATCH 1/2] xhci: Apply reset resume quirk to Etron EJ188 xHCI host

[蔣光益]

Hi Greg,

Greg KH <gregkh@linuxfoundation.org> 於 2024年5月22日 週三 下午12:36寫道：
>
> On Wed, May 22, 2024 at 10:39:18AM +0800, Kuangyi Chiang wrote:
> > As described in commit c877b3b2ad5c ("xhci: Add reset on resume quirk for
> > asrock p67 host"), EJ188 have the same issue as EJ168, where completely
> > dies on resume. So apply XHCI_RESET_ON_RESUME quirk to EJ188 as well.
> >
> > Signed-off-by: Kuangyi Chiang <ki.chiang65@gmail.com>
> > ---
> >  drivers/usb/host/xhci-pci.c | 5 +++++
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> > index ef513c2..a0beb41 100644
> > --- a/drivers/usb/host/xhci-pci.c
> > +++ b/drivers/usb/host/xhci-pci.c
> > @@ -31,6 +31,7 @@
> >
> >  #define PCI_VENDOR_ID_ETRON          0x1b6f
> >  #define PCI_DEVICE_ID_EJ168          0x7023
> > +#define PCI_DEVICE_ID_EJ188          0x7052
> >
> >  #define PCI_DEVICE_ID_INTEL_LYNXPOINT_XHCI   0x8c31
> >  #define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI        0x9c31
> > @@ -238,6 +239,10 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
> >               xhci->quirks |= XHCI_TRUST_TX_LENGTH;
> >               xhci->quirks |= XHCI_BROKEN_STREAMS;
> >       }
> > +     if (pdev->vendor == PCI_VENDOR_ID_ETRON &&
> > +                     pdev->device == PCI_DEVICE_ID_EJ188) {
> > +             xhci->quirks |= XHCI_RESET_ON_RESUME;
> > +     }
>
> Same question as on other patch, should this be backported to older
> kernels too?
>
> thanks,
>
> greg k-h

Sorry, I'm new to this.
These patches have been tested in the stable 4.19 kernel, so they
should be backported to stable kernels as old as 4.19, right?

Thanks,
Kuangyi Chiang

Re: [PATCH 1/2] xhci: Apply reset resume quirk to Etron EJ188 xHCI host

[Greg KH]

On Thu, May 23, 2024 at 01:33:00PM +0800, 蔣光益 wrote:
> Hi Greg,
> 
> Greg KH <gregkh@linuxfoundation.org> 於 2024年5月22日 週三 下午12:36寫道：
> >
> > On Wed, May 22, 2024 at 10:39:18AM +0800, Kuangyi Chiang wrote:
> > > As described in commit c877b3b2ad5c ("xhci: Add reset on resume quirk for
> > > asrock p67 host"), EJ188 have the same issue as EJ168, where completely
> > > dies on resume. So apply XHCI_RESET_ON_RESUME quirk to EJ188 as well.
> > >
> > > Signed-off-by: Kuangyi Chiang <ki.chiang65@gmail.com>
> > > ---
> > >  drivers/usb/host/xhci-pci.c | 5 +++++
> > >  1 file changed, 5 insertions(+)
> > >
> > > diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> > > index ef513c2..a0beb41 100644
> > > --- a/drivers/usb/host/xhci-pci.c
> > > +++ b/drivers/usb/host/xhci-pci.c
> > > @@ -31,6 +31,7 @@
> > >
> > >  #define PCI_VENDOR_ID_ETRON          0x1b6f
> > >  #define PCI_DEVICE_ID_EJ168          0x7023
> > > +#define PCI_DEVICE_ID_EJ188          0x7052
> > >
> > >  #define PCI_DEVICE_ID_INTEL_LYNXPOINT_XHCI   0x8c31
> > >  #define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI        0x9c31
> > > @@ -238,6 +239,10 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
> > >               xhci->quirks |= XHCI_TRUST_TX_LENGTH;
> > >               xhci->quirks |= XHCI_BROKEN_STREAMS;
> > >       }
> > > +     if (pdev->vendor == PCI_VENDOR_ID_ETRON &&
> > > +                     pdev->device == PCI_DEVICE_ID_EJ188) {
> > > +             xhci->quirks |= XHCI_RESET_ON_RESUME;
> > > +     }
> >
> > Same question as on other patch, should this be backported to older
> > kernels too?
> >
> > thanks,
> >
> > greg k-h
> 
> Sorry, I'm new to this.
> These patches have been tested in the stable 4.19 kernel, so they
> should be backported to stable kernels as old as 4.19, right?

Great, please put the proper Fixes: and Cc: stable tags on the commit
when resending these.  Also, they need to be made against the latest
release, not an old 4.19 kernel, as we can't go back in time to only
apply it to there.

thanks,

greg k-h

Re: [PATCH 2/2] xhci: Apply broken streams quirk to Etron EJ188 xHCI host

[Greg KH]

On Wed, May 22, 2024 at 10:39:17AM +0800, Kuangyi Chiang wrote:
> As described in commit 8f873c1ff4ca ("xhci: Blacklist using streams on the
> Etron EJ168 controller"), EJ188 have the same issue as EJ168, where Streams
> do not work reliable on EJ188. So apply XHCI_BROKEN_STREAMS quirk to EJ188
> as well.
> 
> Signed-off-by: Kuangyi Chiang <ki.chiang65@gmail.com>
> ---
>  drivers/usb/host/xhci-pci.c | 1 +
>  1 file changed, 1 insertion(+)

Should this go to stable kernels, if so, how far back?

thanks,

greg k-h