SMSC9730 Autosuspend/Resume Questions

SMSC9730 Autosuspend/Resume Questions

[Frieder Schrempf]

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

[Nisar.Sayed]

Hi Frieder,

> 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

[Frieder Schrempf]

Hi Nisar,

On 22.10.18 09:03, Nisar.Sayed@microchip.com wrote:
> Hi Frieder,
> 
>> 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