[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e868450d-c623-bea9-6325-aca4e8367ad5@samsung.com>
Date: Fri, 18 Jun 2021 13:11:41 +0200
From: Marek Szyprowski <m.szyprowski@...sung.com>
To: Heiner Kallweit <hkallweit1@...il.com>,
Oleksij Rempel <o.rempel@...gutronix.de>
Cc: "David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>,
Russell King <linux@...linux.org.uk>, kernel@...gutronix.de,
linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: [PATCH net-next v2 4/8] net: usb: asix: ax88772: add phylib
support
Hi Heiner,
On 18.06.2021 13:04, Heiner Kallweit wrote:
> On 18.06.2021 12:13, Oleksij Rempel wrote:
>> thank you for your feedback.
>>
>> On Fri, Jun 18, 2021 at 10:39:12AM +0200, Marek Szyprowski wrote:
>>> On 07.06.2021 10:27, Oleksij Rempel wrote:
>>>> To be able to use ax88772 with external PHYs and use advantage of
>>>> existing PHY drivers, we need to port at least ax88772 part of asix
>>>> driver to the phylib framework.
>>>>
>>>> Signed-off-by: Oleksij Rempel <o.rempel@...gutronix.de>
>>> I found one more issue with this patch. On one of my test boards
>>> (Samsung Exynos5250 SoC based Arndale) system fails to establish network
>>> connection just after starting the kernel when the driver is build-in.
>>>
> If you build in the MAC driver, do you also build in the PHY driver?
> If the PHY driver is still a module this could explain why genphy
> driver is used.
> And your dmesg filtering suppresses the phy_attached_info() output
> that would tell us the truth.
Here is a bit more complete log:
# dmesg | grep -i Asix
[ 2.412966] usbcore: registered new interface driver asix
[ 4.620094] usb 1-3.2.4: Manufacturer: ASIX Elec. Corp.
[ 4.641797] asix 1-3.2.4:1.0 (unnamed net_device) (uninitialized):
invalid hw address, using random
[ 5.657009] libphy: Asix MDIO Bus: probed
[ 5.750584] Asix Electronics AX88772A usb-001:004:10: attached PHY
driver (mii_bus:phy_addr=usb-001:004:10, irq=POLL)
[ 5.763908] asix 1-3.2.4:1.0 eth0: register 'asix' at
usb-12110000.usb-3.2.4, ASIX AX88772 USB 2.0 Ethernet, fe:a5:29:e2:97:3e
[ 9.090270] asix 1-3.2.4:1.0 eth0: Link is Up - 100Mbps/Full - flow
control off
This seems to be something different than missing PHY driver.
>>> --->8---
>>> # dmesg | grep asix
>>> [ 2.761928] usbcore: registered new interface driver asix
>>> [ 5.003110] asix 1-3.2.4:1.0 (unnamed net_device) (uninitialized):
>>> invalid hw address, using random
>>> [ 6.065400] asix 1-3.2.4:1.0 eth0: register 'asix' at
>>> usb-12110000.usb-3.2.4, ASIX AX88772 USB 2.0 Ethernet, 7a:9b:9a:f2:94:8e
>>> [ 14.043868] asix 1-3.2.4:1.0 eth0: Link is Up - 100Mbps/Full - flow
>>> control off
>>> # ping -c2 host
>>> PING host (192.168.100.1) 56(84) bytes of data.
>>> From 192.168.100.20 icmp_seq=1 Destination Host Unreachable
>>> From 192.168.100.20 icmp_seq=2 Destination Host Unreachable
>>>
>>> --- host ping statistics ---
>>> 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 59ms
>>> --->8---
>> Hm... it looks like different chip variant. My is registered as
>> "ASIX AX88772B USB", yours is "ASIX AX88772 USB 2.0" - "B" is the
>> difference. Can you please tell me more about this adapter and if possible open
>> tell the real part name.
>>
>> I can imagine that this adapter may using generic PHY driver.
>> Can you please confirm it by dmesg | grep PHY?
>> In my case i'll get:
>> Asix Electronics AX88772C usb-001:003:10: attached PHY driver (mii_bus:phy_addr=usb-001:003:10, irq=POLL)
>>
>> If you have a different PHY, can you please send me the PHY id:
>> cat /sys/bus/mdio_bus/devices/usb-001\:003\:10/phy_id
>>
>> Your usb path will probably be different.
>>
>>> Calling ifup eth0 && ifdown eth0 fixes the network status:
>>>
>>> --->8---
>>> # ifdown eth0 && ifup eth0
>>> [ 60.474929] asix 1-3.2.4:1.0 eth0: Link is Down
>>> [ 60.623516] asix 1-3.2.4:1.0 eth0: Link is Down
>>> [ 62.774304] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>> [ 62.786354] asix 1-3.2.4:1.0 eth0: Link is Up - 100Mbps/Full - flow
>>> control off
>>> # ping -c2 host
>>> PING host (192.168.100.1) 56(84) bytes of data.
>>> 64 bytes from host (192.168.100.1): icmp_seq=1 ttl=64 time=1.25 ms
>>> 64 bytes from host (192.168.100.1): icmp_seq=2 ttl=64 time=0.853 ms
>>>
>>> --- host ping statistics ---
>>> 2 packets transmitted, 2 received, 0% packet loss, time 3ms
>>> rtt min/avg/max/mdev = 0.853/1.053/1.254/0.203 ms
>>> --->8---
>>>
>>> When driver is loaded as a module (and without any other modules, so
>>> this is not a dependency issue), the connection is established properly
>>> just after the boot:
>>>
>>> --->8---
>>> # dmesg | grep asix
>>> [ 13.633284] asix 1-3.2.4:1.0 (unnamed net_device) (uninitialized):
>>> invalid hw address, using random
>>> [ 15.390350] asix 1-3.2.4:1.0 eth0: register 'asix' at
>>> usb-12110000.usb-3.2.4, ASIX AX88772 USB 2.0 Ethernet, 3a:51:11:08:aa:ea
>>> [ 15.414052] usbcore: registered new interface driver asix
>>> [ 15.832564] asix 1-3.2.4:1.0 eth0: Link is Down
>>> [ 18.053747] asix 1-3.2.4:1.0 eth0: Link is Up - 100Mbps/Full - flow
>>> control off
>>> # ping -c2 host
>>> PING host (192.168.100.1) 56(84) bytes of data.
>>> 64 bytes from host (192.168.100.1): icmp_seq=1 ttl=64 time=0.545 ms
>>> 64 bytes from host (192.168.100.1): icmp_seq=2 ttl=64 time=0.742 ms
>>>
>>> --- host ping statistics ---
>>> 2 packets transmitted, 2 received, 0% packet loss, time 3ms
>>> rtt min/avg/max/mdev = 0.545/0.643/0.742/0.101 ms
>>>
>>> --->8---
>>>
>>> Let me know if I can make any other tests that would help fixing this issue.
>>> [...]
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Powered by blists - more mailing lists