Re: [PATCH v2] usb: Quiet down false peer failure messages

2015-12-03 Thread Dan Williams
On Thu, Dec 3, 2015 at 2:26 PM, Don Zickus  wrote:
> My recent Intel box is spewing these messages:
>
> xhci_hcd :00:14.0: xHCI Host Controller
> xhci_hcd :00:14.0: new USB bus registered, assigned bus number 2
> usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
> usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> usb usb2: Product: xHCI Host Controller
> usb usb2: Manufacturer: Linux 4.3.0+ xhci-hcd
> usb usb2: SerialNumber: :00:14.0
> hub 2-0:1.0: USB hub found
> hub 2-0:1.0: 6 ports detected
> usb: failed to peer usb2-port2 and usb1-port1 by location (usb2-port2:none) 
> (usb1-port1:usb2-port1)
> usb usb2-port2: failed to peer to usb1-port1 (-16)
> usb: port power management may be unreliable
> usb: failed to peer usb2-port3 and usb1-port1 by location (usb2-port3:none) 
> (usb1-port1:usb2-port1)
> usb usb2-port3: failed to peer to usb1-port1 (-16)
> usb: failed to peer usb2-port5 and usb1-port1 by location (usb2-port5:none) 
> (usb1-port1:usb2-port1)
> usb usb2-port5: failed to peer to usb1-port1 (-16)
> usb: failed to peer usb2-port6 and usb1-port1 by location (usb2-port6:none) 
> (usb1-port1:usb2-port1)
> usb usb2-port6: failed to peer to usb1-port1 (-16)
>
> Diving into the acpi tables, I noticed the EHCI hub has 12 ports while the 
> XHCI
> hub has 8 ports.  Most of those ports are of connect type USB_PORT_NOT_USED
> (including port 1 of the EHCI hub).
>
> Further the unused ports have location data initialized to 0x8000.
>
> Now each unused port on the xhci hub walks the port list and finds a matching
> peer with port1 of the EHCI hub because the zero'd out group id bits falsely 
> match.
> After port1 of the XHCI hub, each following matching peer will generate the
> above warning.
>
> These warnings seem to be harmless for this scenario as I don't think it
> matters that unused ports could not create a peer link.
>
> The attached patch utilizes that assumption and just turns the pr_warn into
> pr_debug to quiet things down.
>
> Tested on my Intel box.
>
> Signed-off-by: Don Zickus 

Acked-by: Dan Williams 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2] usb: Quiet down false peer failure messages

2015-12-03 Thread Don Zickus
My recent Intel box is spewing these messages:

xhci_hcd :00:14.0: xHCI Host Controller
xhci_hcd :00:14.0: new USB bus registered, assigned bus number 2
usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: xHCI Host Controller
usb usb2: Manufacturer: Linux 4.3.0+ xhci-hcd
usb usb2: SerialNumber: :00:14.0
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 6 ports detected
usb: failed to peer usb2-port2 and usb1-port1 by location (usb2-port2:none) 
(usb1-port1:usb2-port1)
usb usb2-port2: failed to peer to usb1-port1 (-16)
usb: port power management may be unreliable
usb: failed to peer usb2-port3 and usb1-port1 by location (usb2-port3:none) 
(usb1-port1:usb2-port1)
usb usb2-port3: failed to peer to usb1-port1 (-16)
usb: failed to peer usb2-port5 and usb1-port1 by location (usb2-port5:none) 
(usb1-port1:usb2-port1)
usb usb2-port5: failed to peer to usb1-port1 (-16)
usb: failed to peer usb2-port6 and usb1-port1 by location (usb2-port6:none) 
(usb1-port1:usb2-port1)
usb usb2-port6: failed to peer to usb1-port1 (-16)

Diving into the acpi tables, I noticed the EHCI hub has 12 ports while the XHCI
hub has 8 ports.  Most of those ports are of connect type USB_PORT_NOT_USED
(including port 1 of the EHCI hub).

Further the unused ports have location data initialized to 0x8000.

Now each unused port on the xhci hub walks the port list and finds a matching
peer with port1 of the EHCI hub because the zero'd out group id bits falsely 
match.
After port1 of the XHCI hub, each following matching peer will generate the
above warning.

These warnings seem to be harmless for this scenario as I don't think it
matters that unused ports could not create a peer link.

The attached patch utilizes that assumption and just turns the pr_warn into
pr_debug to quiet things down.

Tested on my Intel box.

Signed-off-by: Don Zickus 
---
v2: modified patch to just quiet down the warns instead of skipping the ports

---
 drivers/usb/core/port.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
index 2106183..5487fe3 100644
--- a/drivers/usb/core/port.c
+++ b/drivers/usb/core/port.c
@@ -206,7 +206,7 @@ static int link_peers(struct usb_port *left, struct 
usb_port *right)
else
method = "default";
 
-   pr_warn("usb: failed to peer %s and %s by %s (%s:%s) (%s:%s)\n",
+   pr_debug("usb: failed to peer %s and %s by %s (%s:%s) 
(%s:%s)\n",
dev_name(>dev), dev_name(>dev), method,
dev_name(>dev),
lpeer ? dev_name(>dev) : "none",
@@ -265,7 +265,7 @@ static void link_peers_report(struct usb_port *left, struct 
usb_port *right)
if (rc == 0) {
dev_dbg(>dev, "peered to %s\n", dev_name(>dev));
} else {
-   dev_warn(>dev, "failed to peer to %s (%d)\n",
+   dev_dbg(>dev, "failed to peer to %s (%d)\n",
dev_name(>dev), rc);
pr_warn_once("usb: port power management may be unreliable\n");
usb_port_block_power_off = 1;
-- 
1.8.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html