Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH net-next v2 4/8] net: usb: asix: ax88772: add phylib
 support
To:     Heiner Kallweit <hkallweit1@gmail.com>,
        Oleksij Rempel <o.rempel@pengutronix.de>
Cc:     "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>, Andrew Lunn <andrew@lunn.ch>,
        Russell King <linux@armlinux.org.uk>, kernel@pengutronix.de,
        linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
        netdev@vger.kernel.org
From:   Marek Szyprowski <m.szyprowski@samsung.com>
Message-ID: <e868450d-c623-bea9-6325-aca4e8367ad5@samsung.com>
Date:   Fri, 18 Jun 2021 13:11:41 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0)
        Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <b1c48fa1-d406-766e-f8d7-54f76d3acb7c@gmail.com>
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Content-Type: text/plain; charset="utf-8"
CMS-TYPE: 201P
References: <20210607082727.26045-1-o.rempel@pengutronix.de>
        <20210607082727.26045-5-o.rempel@pengutronix.de>
        <CGME20210618083914eucas1p240f88e7064a7bf15b68370b7506d24a9@eucas1p2.samsung.com>
        <15e1bb24-7d67-9d45-54c1-c1c1a0fe444a@samsung.com>
        <20210618101317.55fr5vl5akmtgcf6@pengutronix.de>
        <b1c48fa1-d406-766e-f8d7-54f76d3acb7c@gmail.com>
Precedence: bulk

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@pengutronix.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