On Thu, Jun 27, 2019 at 04:43:39PM +0200, Andrew Lunn wrote: > 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. > I 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? > Always get 0xFFFF before and after Note that the eeprom dump via ethtool -e suffer the same problem. > > 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. > I have investigated more and in fact I dont have a dm9620. I own another diferent dongle in my stock that i never used and fun fact, it has the same VID/PID and the same bug. I opened both dongle and all chips have no marking and got only 4x8 pins. Since dm9620 have 64 pins, my dongles are clearly not such hw. I googled the inscription written on the second case and found a dm9620 clone/counterfeiting named qf9700/sr9700. But thoses chips should have marking (according to some photos on the web), so I probably own a counterfeiting of a clone/counterfeiting. Note that the sr9700 driver is mainline but fail to work with my dongle. At least, now i know that have a chip not designed to work with an external PHY, so all EXTPHY registers could be ignored. My last ressort is to brute force all values until something happen. My simple tries, write 0xsomeval everywhere, lead to something, phy/eeprom return now 0x000y. Probably, this chip doesnt have any PHY... Regards
