Odd 'unable to find transceiver' messages from USB with v3.13-3260-g03d11a0 and later

Odd 'unable to find transceiver' messages from USB with v3.13-3260-g03d11a0 and later

[Josh Boyer]

Hi All,

We've had a report [1] of the USB layer throwing out 'unable to find
transceiver' messages during boot with the 3.14 merge window kernels.
I've seen this on my personal machine as well and included the dmesg
section below.  This does not happen with the 3.13 kernel.

There are only a handful of files in git that have that error, but I
haven't seen anything that immediately strikes me as causing this.
>From the dmesg output it looks like it is spit out right before a host
controller is registered?  USB seems to be still working OK in my
minimal testing, so the error message is confusing.

Thoughts?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1057529

josh

[    1.683368] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.683386] ehci-pci: EHCI PCI platform driver
[    1.684765] unable to find transceiver
[    1.684993] ehci-pci 0000:00:1a.0: EHCI Host Controller
[    1.685772] ehci-pci 0000:00:1a.0: new USB bus registered, assigned
bus number 1
[    1.685847] ehci-pci 0000:00:1a.0: debug port 2
[    1.689837] ehci-pci 0000:00:1a.0: cache line size of 64 is not supported
[    1.689976] ehci-pci 0000:00:1a.0: irq 16, io mem 0xfe707000
[    1.695158] ehci-pci 0000:00:1a.0: USB 2.0 started, EHCI 1.00
[    1.695721] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    1.695722] usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[    1.695724] usb usb1: Product: EHCI Host Controller
[    1.695725] usb usb1: Manufacturer: Linux
3.14.0-0.rc0.git7.1.fc21.x86_64 ehci_hcd
[    1.695726] usb usb1: SerialNumber: 0000:00:1a.0
[    1.697752] hub 1-0:1.0: USB hub found
[    1.697872] hub 1-0:1.0: 2 ports detected
[    1.701620] unable to find transceiver
[    1.701847] ehci-pci 0000:00:1d.0: EHCI Host Controller
[    1.702424] ehci-pci 0000:00:1d.0: new USB bus registered, assigned
bus number 2
[    1.702458] ehci-pci 0000:00:1d.0: debug port 2
[    1.706417] ehci-pci 0000:00:1d.0: cache line size of 64 is not supported
[    1.706538] ehci-pci 0000:00:1d.0: irq 23, io mem 0xfe706000
[    1.712160] ehci-pci 0000:00:1d.0: USB 2.0 started, EHCI 1.00

Re: Odd 'unable to find transceiver' messages from USB with v3.13-3260-g03d11a0 and later

[Felipe Balbi]

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

Hi,

On Fri, Jan 24, 2014 at 08:47:07AM -0500, Josh Boyer wrote:
> We've had a report [1] of the USB layer throwing out 'unable to find
> transceiver' messages during boot with the 3.14 merge window kernels.
> I've seen this on my personal machine as well and included the dmesg
> section below.  This does not happen with the 3.13 kernel.
> 
> There are only a handful of files in git that have that error, but I
> haven't seen anything that immediately strikes me as causing this.
> From the dmesg output it looks like it is spit out right before a host
> controller is registered?  USB seems to be still working OK in my
> minimal testing, so the error message is confusing.
> 
> Thoughts?

looks like it was caused because of this commit:

commit 1ae5799ef63176cc75ec10e545cb65f620a82747
Author: Valentine Barshak <valentine.barshak@cogentembedded.com>
Date:   Wed Dec 4 01:42:22 2013 +0400

    usb: hcd: Initialize USB phy if needed
    
    This adds external USB phy support to USB HCD driver that
    allows to find and initialize external USB phy, bound to
    the HCD, when the HCD is added.
    The usb_add_hcd function returns -EPROBE_DEFER if the USB
    phy, bound to the HCD, is not ready.
    If no USB phy is bound, the HCD is initialized as usual.
    
    Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 7527c8e..d3a9bcd 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2589,6 +2589,24 @@ int usb_add_hcd(struct usb_hcd *hcd,
 	int retval;
 	struct usb_device *rhdev;
 
+	if (IS_ENABLED(CONFIG_USB_PHY) && !hcd->phy) {
+		struct usb_phy *phy = usb_get_phy_dev(hcd->self.controller, 0);
+
+		if (IS_ERR(phy)) {
+			retval = PTR_ERR(phy);
+			if (retval == -EPROBE_DEFER)
+				return retval;
+		} else {
+			retval = usb_phy_init(phy);
+			if (retval) {
+				usb_put_phy(phy);
+				return retval;
+			}
+			hcd->phy = phy;
+			hcd->remove_phy = 1;
+		}
+	}
+
 	dev_info(hcd->self.controller, "%s\n", hcd->product_desc);
 
 	/* Keep old behaviour if authorized_default is not in [0, 1]. */

usb_get_phy_device() will pr_err() when a PHY isn't found. Looks like
that should be pr_debug() since everything still works even without a
PHY.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Odd 'unable to find transceiver' messages from USB with v3.13-3260-g03d11a0 and later

[Josh Boyer]

On Fri, Jan 24, 2014 at 2:08 PM, Felipe Balbi <balbi@ti.com> wrote:
> Hi,
>
> On Fri, Jan 24, 2014 at 08:47:07AM -0500, Josh Boyer wrote:
>> We've had a report [1] of the USB layer throwing out 'unable to find
>> transceiver' messages during boot with the 3.14 merge window kernels.
>> I've seen this on my personal machine as well and included the dmesg
>> section below.  This does not happen with the 3.13 kernel.
>>
>> There are only a handful of files in git that have that error, but I
>> haven't seen anything that immediately strikes me as causing this.
>> From the dmesg output it looks like it is spit out right before a host
>> controller is registered?  USB seems to be still working OK in my
>> minimal testing, so the error message is confusing.
>>
>> Thoughts?
>
> looks like it was caused because of this commit:
>
> commit 1ae5799ef63176cc75ec10e545cb65f620a82747
> Author: Valentine Barshak <valentine.barshak@cogentembedded.com>
> Date:   Wed Dec 4 01:42:22 2013 +0400
>
>     usb: hcd: Initialize USB phy if needed

Yeah, I'm pretty sure my bisect agrees with you.

> usb_get_phy_device() will pr_err() when a PHY isn't found. Looks like
> that should be pr_debug() since everything still works even without a
> PHY.

Seems correct.  Who should write up the patch?

josh