On Mon, Nov 30, 2015 at 12:57:17PM -0800, Dan Williams wrote: > On Tue, Nov 17, 2015 at 1:00 PM, Don Zickus <dzic...@redhat.com> 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 <dzic...@redhat.com> > > --- > > 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.
Ok. Sounds fair. Curious, I couldn't figure out from the specs if this was valid or not, or if my Intel pre-production machine has an early firmware on it that might resolve this issue later.. Cheers, Don -- 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
