linux-kernel - Re: [BUG] net: dm9600: false link status

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: <20190627144339.GG31189@lunn.ch>
Date:   Thu, 27 Jun 2019 16:43:39 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Corentin Labbe <clabbe.montjoie@...il.com>
Cc:     jacmet@...site.dk, davem@...emloft.net, netdev@...r.kernel.org,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [BUG] net: dm9600: false link status

On Thu, Jun 27, 2019 at 03:21:37PM +0200, Corentin Labbe wrote:
> Hello
> 
> I own an USB dongle which is a "Davicom DM96xx USB 10/100 Ethernet".
> According to the CHIP_ID, it is a DM9620.
> 
> Since I needed for bringing network to uboot for a board, I have started to create its uboot's driver.
> My uboot driver is based on the dm9600 Linux driver.
> 
> The dongle was working but very very slowy (24Kib/s).
> After some debug i found that the main problem was that it always link to 10Mbit/s Half-duplex. (according to the MAC registers)
> 
> For checking the status of the dongle I have plugged it on a Linux box which give me:
> dm9601 6-2:1.0 enp0s29f0u2: link up, 100Mbps, full-duplex, lpa 0xFFFF
> 
> But in fact the Linux driver is tricked.
> 
> I have added debug of MDIO write/read and got:
> [157550.926974] dm9601 6-2:1.0 (unnamed net_device) (uninitialized): dm9601_mdio_write() phy_id=0x00, loc=0x00, val=0x8000

Writing the reset bit. Ideally you should read back the register and
wait for this bit to clear. Try adding this, and see if this helps, or
you get 0xffff.

> [157550.931962] dm9601 6-2:1.0 (unnamed net_device) (uninitialized): dm9601_mdio_write() phy_id=0x00, loc=0x04, val=0x05e1

Advertisement control register.  

> [157550.951967] dm9601 6-2:1.0 (unnamed net_device) (uninitialized): dm9601_mdio_read() phy_id=0x00, loc=0x00, returns=0xffff

And now things are bad. In theory, the power down bit is set, and some
PHYs don't respond properly when powered down. However, it is unclear
how it got into this state. Did the reset kill it, or setting the
advertisement? Or is the PHY simply not responding at all. The MDIO
data lines have a pull up, so if the device does not respond, reads
give 0xffff.

Maybe also check register 0, bit 7, EXT_PHY. Is it 0, indicating the
internal PHY should be used?

You could also try reading PHY registers 2 and 3 and see if you can
get a valid looking PHY ID. Maybe try that before hitting the reset
bit?

> So it exsists two problem:
> - Linux saying 100Mbps, full-duplex even if it is false.

The driver is using the old mii code, not a phy driver. So i cannot
help too much with linux. But if you can get the MDIO bus working
reliably, it should be possible to move this over to phylib. The
internal PHY appears to have all the standard registers, so the
generic PHY driver has a good chance of working.

     Andrew