On Tue, Nov 17, 2015 at 1:00 PM, Don Zickus <dzickus@xxxxxxxxxx> wrote: > My recent Intel box is spewing these messages: > > xhci_hcd 0000:00:14.0: xHCI Host Controller > xhci_hcd 0000: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: 0000: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 0x80000000. > > 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 skips the > find_and_link_peer setup if a port is determined to be unused. This further > assumes that port's status will never change. > > Tested on my Intel box. > > Signed-off-by: Don Zickus <dzickus@xxxxxxxxxx> > --- > drivers/usb/core/port.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c > index 2106183..3a8f84a 100644 > --- a/drivers/usb/core/port.c > +++ b/drivers/usb/core/port.c > @@ -353,6 +353,13 @@ static void find_and_link_peer(struct usb_hub *hub, int port1) > struct usb_hub *peer_hub; > > /* > + * Un-used ports have zero'd out data that can create a false > + * peer in-use failure. > + */ > + if (port_dev->connect_type == USB_PORT_NOT_USED) > + return; > + > + /* > * If location data is available then we can only peer this port > * by a location match, not the default peer (lest we create a > * situation where we need to go back and undo a default peering Looks reasonable, but it may hide real errors in the ACPI tables. How about just changing the dev_warn() in link_peers_report() to dev_dbg? We'll still get the pr_warn_once() to get the notification that something went wrong, but won't continue to spam the logs if the user does not care about peer port power management. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
