All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
To: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
Cc: stern@rowland.harvard.edu, gregkh@linuxfoundation.org,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] usb: ohci: Default to per-port over-current protection
Date: Sun, 27 Dec 2020 12:22:34 +0100	[thread overview]
Message-ID: <X+huemxT9XOeDi5E@aptenodytes> (raw)
In-Reply-To: <20200910212512.16670-1-hamish.martin@alliedtelesis.co.nz>

[-- Attachment #1: Type: text/plain, Size: 4490 bytes --]

Hi,

On Fri 11 Sep 20, 09:25, Hamish Martin wrote:
> Some integrated OHCI controller hubs do not expose all ports of the hub
> to pins on the SoC. In some cases the unconnected ports generate
> spurious over-current events. For example the Broadcom 56060/Ranger 2 SoC
> contains a nominally 3 port hub but only the first port is wired.
> 
> Default behaviour for ohci-platform driver is to use global over-current
> protection mode (AKA "ganged"). This leads to the spurious over-current
> events affecting all ports in the hub.
> 
> We now alter the default to use per-port over-current protection.

This specific patch lead to breaking OHCI on my mom's laptop (whom was about
to buy a new one thinking the hardware had failed). I get no OHCI interrupt at
all and no USB 1 device is ever detected.

I haven't really found a reasonable explanation about why that is, but here
are some notes I was able to collect:
- The issue showed up on 5.8,18 and 5.9.15, which don't include the patch
  from this series that sets distrust_firmware = false; This results in the NPS
  bit being set via OHCI_QUIRK_HUB_POWER.
- Adding val &= ~RH_A_PSM; (as was done before this change) solves the issue
  which is weird because the bit is supposed to be inactive when NPS is set;
- Setting ohci_hcd.distrust_firmware=0 in the cmdline results in not setting
  the NPS bit and also solves the issue;
- The initial value of the register at function entry is 0x1001104 (PSM bit
  is set, NPS is unset);
- The OHCI controller is the following:
00:03.0 USB controller: Silicon Integrated Systems [SiS] USB 1.1 Controller (rev 0f) (prog-if 10 [OHCI])
	Subsystem: ASUSTeK Computer Inc. Device 1aa7

Does that make any sense to you?

I really wonder what a proper fix could be and here are some suggestions:
- Adding a specific quirk to clear the PSM bit for this hardware which seems to
  consider the bit regardless of NPS;
- Adding the patch that sets distrust_firmware = false to stable branches;

What do you think?

Cheers,

Paul

> This patch results in the following configuration changes depending
> on quirks:
> - For quirk OHCI_QUIRK_SUPERIO no changes. These systems remain set up
>   for ganged power switching and no over-current protection.
> - For quirk OHCI_QUIRK_AMD756 or OHCI_QUIRK_HUB_POWER power switching
>   remains at none, while over-current protection is now guaranteed to be
>   set to per-port rather than the previous behaviour where it was either
>   none or global over-current protection depending on the value at
>   function entry.
> 
> Suggested-by: Alan Stern <stern@rowland.harvard.edu>
> Signed-off-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
> ---
> 
> Notes:
>     Changes in v2:
>     - remove clearing of RH_A_PSM in OHCI_QUIRK_HUB_POWER block.
> 
>  drivers/usb/host/ohci-hcd.c | 16 ++++++++++------
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
> index dd37e77dae00..2845ea328a06 100644
> --- a/drivers/usb/host/ohci-hcd.c
> +++ b/drivers/usb/host/ohci-hcd.c
> @@ -673,20 +673,24 @@ static int ohci_run (struct ohci_hcd *ohci)
>  
>  	/* handle root hub init quirks ... */
>  	val = roothub_a (ohci);
> -	val &= ~(RH_A_PSM | RH_A_OCPM);
> +	/* Configure for per-port over-current protection by default */
> +	val &= ~RH_A_NOCP;
> +	val |= RH_A_OCPM;
>  	if (ohci->flags & OHCI_QUIRK_SUPERIO) {
> -		/* NSC 87560 and maybe others */
> +		/* NSC 87560 and maybe others.
> +		 * Ganged power switching, no over-current protection.
> +		 */
>  		val |= RH_A_NOCP;
> -		val &= ~(RH_A_POTPGT | RH_A_NPS);
> -		ohci_writel (ohci, val, &ohci->regs->roothub.a);
> +		val &= ~(RH_A_POTPGT | RH_A_NPS | RH_A_PSM | RH_A_OCPM);
>  	} else if ((ohci->flags & OHCI_QUIRK_AMD756) ||
>  			(ohci->flags & OHCI_QUIRK_HUB_POWER)) {
>  		/* hub power always on; required for AMD-756 and some
> -		 * Mac platforms.  ganged overcurrent reporting, if any.
> +		 * Mac platforms.
>  		 */
>  		val |= RH_A_NPS;
> -		ohci_writel (ohci, val, &ohci->regs->roothub.a);
>  	}
> +	ohci_writel(ohci, val, &ohci->regs->roothub.a);
> +
>  	ohci_writel (ohci, RH_HS_LPSC, &ohci->regs->roothub.status);
>  	ohci_writel (ohci, (val & RH_A_NPS) ? 0 : RH_B_PPCM,
>  						&ohci->regs->roothub.b);
> -- 
> 2.28.0
> 

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2020-12-27 11:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-10 21:25 [PATCH v2 1/2] usb: ohci: Default to per-port over-current protection Hamish Martin
2020-09-10 21:25 ` [PATCH v2 2/2] usb: ohci: Make distrust_firmware param default to false Hamish Martin
2020-09-11 15:17   ` Alan Stern
2020-09-11 15:17 ` [PATCH v2 1/2] usb: ohci: Default to per-port over-current protection Alan Stern
2020-12-27 11:22 ` Paul Kocialkowski [this message]
2021-01-09 21:26   ` Alan Stern
2021-01-19  1:09     ` Hamish Martin
2021-01-19 15:51       ` Request to apply commit c4005a8f65ed to the -stable kernels Alan Stern
2021-01-19 18:11         ` Greg KH
2021-01-20 10:50       ` [PATCH v2 1/2] usb: ohci: Default to per-port over-current protection paul.kocialkowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=X+huemxT9XOeDi5E@aptenodytes \
    --to=paul.kocialkowski@bootlin.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hamish.martin@alliedtelesis.co.nz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.