netdev - RE: SMSC9730 Autosuspend/Resume Questions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CE371C1263339941885964188A0225FA44571A@CHN-SV-EXMX03.mchp-main.com>
Date:   Mon, 22 Oct 2018 07:03:54 +0000
From:   <Nisar.Sayed@...rochip.com>
To:     <frieder.schrempf@...eet.de>, <steve.glendinning@...well.net>,
        <UNGLinuxDriver@...rochip.com>, <davem@...emloft.net>,
        <netdev@...r.kernel.org>
CC:     <oneukum@...e.com>, <linux-usb@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: RE: SMSC9730 Autosuspend/Resume Questions

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