SMSC9730 Autosuspend/Resume Questions

3 messages, 2 authors, 2018-10-22 · open the first message on its own page

SMSC9730 Autosuspend/Resume Questions

From: Frieder Schrempf <hidden>
Date: 2018-10-17 15:21:28

Hi,

I recently tested a board with SMSC9730 connected via USB HSIC to an 
i.MX6S SOC. I used these patches on top of v4.14-rc8 for the USB HSIC 
support: [1].

When I turned on autosuspend, the smsc95xx stopped in the middle of the 
suspending routine and 
/sys/bus/usb/devices/usb3/3-1/power/runtime_status reported "suspending" 
forever.

With some debug logs I found out, that the last line of code that was 
executed is [2], after that I didn't get any further messages.

Then I applied the following diff and the suspend/resume started to work 
reliably:
@@ -1382,10 +1385,11 @@ static int smsc95xx_link_ok_nopm(struct usbnet *dev)
         ret = smsc95xx_mdio_read_nopm(dev->net, mii->phy_id, MII_BMSR);
         if (ret < 0)
                 return ret;
-
+       /*
         ret = smsc95xx_mdio_read_nopm(dev->net, mii->phy_id, MII_BMSR);
         if (ret < 0)
                 return ret;
+       */

         return !!(ret & BMSR_LSTATUS);
  }
So it seems like the dummy read, that is commented with "first, a dummy 
read, needed to latch some MII phys" causes problems in my setup. Do you 
have an idea what could be the reason? Is this a proper fix?

Thanks,
Frieder

[1] https://patchwork.kernel.org/cover/10643089/
[2] 
https://github.com/torvalds/linux/blob/bab5c80b211035739997ebd361a679fa85b39465/drivers/net/usb/smsc95xx.c#L1382

RE: SMSC9730 Autosuspend/Resume Questions

From: <hidden>
Date: 2018-10-22 07:03:58

Hi Frieder,
quoted hunk
Hi,

I recently tested a board with SMSC9730 connected via USB HSIC to an
i.MX6S SOC. I used these patches on top of v4.14-rc8 for the USB HSIC
support: [1].

When I turned on autosuspend, the smsc95xx stopped in the middle of the
suspending routine and /sys/bus/usb/devices/usb3/3-
1/power/runtime_status reported "suspending"
forever.

With some debug logs I found out, that the last line of code that was
executed is [2], after that I didn't get any further messages.

Then I applied the following diff and the suspend/resume started to work
reliably:
@@ -1382,10 +1385,11 @@ static int smsc95xx_link_ok_nopm(struct usbnet
*dev)
         ret = smsc95xx_mdio_read_nopm(dev->net, mii->phy_id, MII_BMSR);
         if (ret < 0)
                 return ret;
-
+       /*
         ret = smsc95xx_mdio_read_nopm(dev->net, mii->phy_id, MII_BMSR);
         if (ret < 0)
                 return ret;
+       */

         return !!(ret & BMSR_LSTATUS);
  }

So it seems like the dummy read, that is commented with "first, a dummy
read, needed to latch some MII phys" causes problems in my setup. Do you
have an idea what could be the reason? Is this a proper fix?
 
Link status bit is latch low register and needs to be read twice. You may get wrong Link status with this fix.

- Nisar

Re: SMSC9730 Autosuspend/Resume Questions

From: Frieder Schrempf <hidden>
Date: 2018-10-22 07:15:08

Hi Nisar,

On 22.10.18 09:03, Nisar.Sayed@microchip.com wrote:
Hi Frieder,
quoted
Hi,

I recently tested a board with SMSC9730 connected via USB HSIC to an
i.MX6S SOC. I used these patches on top of v4.14-rc8 for the USB HSIC
support: [1].

When I turned on autosuspend, the smsc95xx stopped in the middle of the
suspending routine and /sys/bus/usb/devices/usb3/3-
1/power/runtime_status reported "suspending"
forever.

With some debug logs I found out, that the last line of code that was
executed is [2], after that I didn't get any further messages.

Then I applied the following diff and the suspend/resume started to work
reliably:
@@ -1382,10 +1385,11 @@ static int smsc95xx_link_ok_nopm(struct usbnet
*dev)
          ret = smsc95xx_mdio_read_nopm(dev->net, mii->phy_id, MII_BMSR);
          if (ret < 0)
                  return ret;
-
+       /*
          ret = smsc95xx_mdio_read_nopm(dev->net, mii->phy_id, MII_BMSR);
          if (ret < 0)
                  return ret;
+       */

          return !!(ret & BMSR_LSTATUS);
   }

So it seems like the dummy read, that is commented with "first, a dummy
read, needed to latch some MII phys" causes problems in my setup. Do you
have an idea what could be the reason? Is this a proper fix?
  
Link status bit is latch low register and needs to be read twice. You may get wrong Link status with this fix.
Ok, thanks for the information. I guess I'll have to do some more 
debugging to find out why the second read fails in my case.

Frieder
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help