From: Sarah Sharp <sarah.a.sharp@linux.intel.com>
To: Keng-Yu Lin <kengyu@canonical.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Intel xhci: Only switch the switchable ports
Date: Thu, 9 Aug 2012 07:24:06 -0700 [thread overview]
Message-ID: <20120809142406.GC14429@xanatos> (raw)
In-Reply-To: <1344504711-10916-1-git-send-email-kengyu@canonical.com>
On Thu, Aug 09, 2012 at 05:31:51PM +0800, Keng-Yu Lin wrote:
> With a previous patch to enable the EHCI/XHCI port switching, it switches
> all the available ports.
>
> The assumption is not correct because the BIOS may expect some ports
> not switchable by the OS.
Why would the BIOS expect some ports to not be switchable? I know that
we internally at Intel had discussed some theoretical reasons why it
might not be good to switch some ports, but when I presented the
original patch with this same code in it to Linux USB mailing list, both
Alan and Greg said, "Why not unconditionally switch ports?" I had no
good examples at the time.
Is this causing issues with some particular BIOS?
> There are two more registers that contains the information of the switchable
> and non-switchable ports.
>
> This patch adds the checking code for the two register so that only the
> switchable ports are altered.
>
> Signed-off-by: Keng-Yu Lin <kengyu@canonical.com>
> ---
> drivers/usb/host/pci-quirks.c | 27 +++++++++++++++++++++++----
> 1 file changed, 23 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> index 833b3c6..89f62f2 100644
> --- a/drivers/usb/host/pci-quirks.c
> +++ b/drivers/usb/host/pci-quirks.c
> @@ -75,7 +75,9 @@
> #define NB_PIF0_PWRDOWN_1 0x01100013
>
> #define USB_INTEL_XUSB2PR 0xD0
> +#define USB_INTEL_USB2PRM 0xD4
> #define USB_INTEL_USB3_PSSEN 0xD8
> +#define USB_INTEL_USB3PRM 0xDC
>
> static struct amd_chipset_info {
> struct pci_dev *nb_dev;
> @@ -772,10 +774,18 @@ void usb_enable_xhci_ports(struct pci_dev *xhci_pdev)
> return;
> }
>
> - ports_available = 0xffffffff;
> + /* Read USB3PRM, the USB 3.0 Port Routing Mask Register
> + * Indicate the ports that can be changed from OS.
> + */
> + pci_read_config_dword(xhci_pdev, USB_INTEL_USB3PRM,
> + &ports_available);
> +
> + dev_dbg(&xhci_pdev->dev, "Configurable ports to enable SuperSpeed: 0x%x\n",
> + ports_available);
> +
> /* Write USB3_PSSEN, the USB 3.0 Port SuperSpeed Enable
> - * Register, to turn on SuperSpeed terminations for all
> - * available ports.
> + * Register, to turn on SuperSpeed terminations for the
> + * switchable ports.
> */
> pci_write_config_dword(xhci_pdev, USB_INTEL_USB3_PSSEN,
> cpu_to_le32(ports_available));
> @@ -785,7 +795,16 @@ void usb_enable_xhci_ports(struct pci_dev *xhci_pdev)
> dev_dbg(&xhci_pdev->dev, "USB 3.0 ports that are now enabled "
> "under xHCI: 0x%x\n", ports_available);
>
> - ports_available = 0xffffffff;
> + /* Read XUSB2PRM, xHCI USB 2.0 Port Routing Mask Register
> + * Indicate the port to be controlled by the EHCI host.
Your code is correct, but your comment is wrong. XUSB2PRM is the USB
2.0 ports that should be controlled by the xHCI host.
> + */
> +
> + pci_read_config_dword(xhci_pdev, USB_INTEL_USB2PRM,
> + &ports_available);
> +
> + dev_dbg(&xhci_pdev->dev, "Configurable ports to hand over the ECHI host:
> + 0x%x\n", ports_available);
Again, this should be "Configurable USB 2.0 ports to hand over to xHCI:"
Also, don't split strings, it makes it hard to grep for them later.
> +
> /* Write XUSB2PR, the xHC USB 2.0 Port Routing Register, to
> * switch the USB 2.0 power and data lines over to the xHCI
> * host.
Sarah Sharp
next prev parent reply other threads:[~2012-08-09 14:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-09 9:31 Keng-Yu Lin
2012-08-09 14:24 ` Sarah Sharp [this message]
2012-08-09 14:44 ` Alan Cox
2012-08-09 16:13 ` Keng-Yu Lin
2012-08-09 19:38 ` Sarah Sharp
2012-08-10 5:11 ` Keng-Yu Lin
2012-08-14 7:14 ` Keng-Yu Lin
2012-08-09 17:39 ` [PATCH v2] " Keng-Yu Lin
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=20120809142406.GC14429@xanatos \
--to=sarah.a.sharp@linux.intel.com \
--cc=gregkh@suse.de \
--cc=kengyu@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome