| 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
| ||
|
Date: Fri, 14 Jun 2024 09:33:02 +0200
From: Enguerrand de Ribaucourt <enguerrand.de-ribaucourt@...oirfairelinux.com>
To: Woojung.Huh@...rochip.com
Cc: UNGLinuxDriver@...rochip.com, netdev@...r.kernel.org
Subject: Re: KSZ9897 RMII ports support
Hello Woojung,
I got the network traffic to work again by puting back `phy-mode =
"rmii";` in the MAC dts node, but still without `phy-handle`. So we
found out that the improper phy_id was a configuration issue on my end.
I'm going to submit a v6 of my patches with just the errata fixes, while
changing what has been suggested on v5.
Thanks a lot for your help,
Enguerrand de Ribaucourt
Savoir-faire Linux
On 13/06/2024 18:35, Woojung.Huh@...rochip.com wrote:
> Hi Enguerrand,
>
> Because it is now debugging configuration between i.MX6ULL NIC and KSZ9897,
> I would like to remove netdev@.. from cc if you agree.
>
> As mentioned before, persons who can do hands-on with KSZ switch are out for
> vacation until end of next week. Sorry that support could be limited
> by resources and knowledge at this point even though I try my best.
>
>> RX packets:866 errors:862 dropped:862 overruns:0 frame:0
> I don't know test environment. sw0p1 is the only port connected from switch or not.
> Per this stat, only 4 packets are NOT dropped at sw0p1.
> Because all error count is drop-count (RxDropPackets), suspect that switch packet
> buffer got full and started dropping the incoming packets.
>
> Because there is no RX count on eth0, assume that CPU port KSZ9897 can't send any
> packet out to i.MX6ULL.
>
> Can you please capture (wireshark or tcpdump) over br0 and eth0 and share files with us?
> And, stats from eth0 (i.e., ethtool -S eth0) too?
>
> Because eth0 still shows Tx count increase, guess eth0 thinks link is up and
> sent out some packets to KSZ9897.
>
> Thanks.
> Woojung
>
>> -----Original Message-----
>> From: Enguerrand de Ribaucourt <enguerrand.de-
>> ribaucourt@...oirfairelinux.com>
>> Sent: Thursday, June 13, 2024 10:24 AM
>> To: Woojung Huh - C21699 <Woojung.Huh@...rochip.com>
>> Cc: UNGLinuxDriver <UNGLinuxDriver@...rochip.com>; netdev@...r.kernel.org
>> Subject: Re: KSZ9897 RMII ports support
>>
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
>> content is safe
>>
>> Hello,
>>
>> I've simplified my dts accordingly (see bellow). However, I no longer
>> receive packets on my bridge interface. Interfaces eth0, br0 and
>> external ports properly report link UP and I can see RX counters going
>> up on the external ports interfaces (sw0p*). Yet, ifconfig now reports 0
>> RX packets on eth0 and br0 now, while I see 0 TX packets on sw0p*.
>>
>> ```
>> $ ifconfig
>> br0
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
>>
>> eth0
>> UP BROADCAST RUNNING MULTICAST MTU:1506 Metric:1
>> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:62 errors:0 dropped:0 overruns:0 carrier:0
>>
>> sw0p1
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:866 errors:862 dropped:862 overruns:0 frame:0
>> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>> ```
>>
>> My bridge configuration is based on the dsa documentation:
>> -
>> https://docs.kernel.org/networking/dsa/configuration.html#configuration-
>> with-tagging-support
>>
>> Could you help me understand what's missing to properly exchange packets
>> through my bridge interface with the new RMII configuration?
>>
>> It's possible the previous phy_id being read corresponded to the other
>> SOM's Ethernet's PHY since it used the same MDIO address I had declared
>> in the DTS.
>>
>> Thanks for your support,
>>
>> Enguerrand de Ribaucourt
>> Savoir-faire Linux
>>
>> ```c
>> ethernet@...4000 {
>> compatible = "fsl,imx6ul-fec\0fsl,imx6q-fec";
>> ...
>> /delete-property/ phy-mode;
>> /delete-property/ phy-handle;
>> phandle = <0x0c>;
>> fixed-link {
>> speed = <0x64>;
>> full-duplex;
>> };
>> };
>>
>> spi@...0000 {
>> ksz9897@0 {
>> ports {
>> port@5 {
>> reg = <0x05>;
>> label = "cpu";
>> ethernet = <0x0c>;
>> phy-mode = "rmii";
>> rx-internal-delay-ps = <0x5dc>;
>> fixed-link {
>> speed = <0x64>;
>> full-duplex;
>> };
>> };
>> };
>> };
>> };
>>
>> ethernet@...8000 {
>> status = "disabled";
>> };
>> ```
>>
>> On 07/06/2024 17:39, Woojung.Huh@...rochip.com wrote:
>>> Hi Enguerrand,
>>>
>>> Thanks for creating new thread. Continue from [1].
>>>
>>> You can check SAMA5 + KSZ9477 EVB DTS.
>>> [2] is host MAC side setting and
>>> [3] is host port setting of KSZ switch side.
>>>
>>> Your ethernet@...4000 has phy-handle which is not in [2].
>>> "phy-handle = <0x15>" specifies to "ksz9897port5@1" under "mdio".
>>> I think this is setting you don't need to specify.
>>>
>>> "fixed-link" under "ethernet@...4000" already specified
>>> there is no PHY (fixed phy) for "ethernet@...4000" and it is enough.
>>>
>>> KSZ9897 shares a pin on SDI/SDA/MDIO, no MDIO is active in your setup
>> because
>>> SPI is enable for KSZ switch control access.
>>> I guess "ksz9897port5@1" under "mdio" causes phy scanning on host MDIO bus,
>>> and assume that there is KSZ8081 PHY on the host system (probably on NET1?)
>>>
>>> Please let me know my assessment is not correct. We can continue to debug
>> this issue.
>>>
>>>> ```c
>>>> ethernet@...4000 {
>>>> compatible = "fsl,imx6ul-fec\0fsl,imx6q-fec";
>>>> ...
>>>> phy-mode = "rmii";
>>>> phy-handle = <0x15>;
>>>> fixed-link {
>>>> speed = <0x64>;
>>>> full-duplex;
>>>> };
>>>> };
>>>>
>>>> // MDIO bus is only defined on eth1 but shared with eth2
>>>> ethernet@...8000 {
>>>> ...
>>>> mdio {
>>>> ...
>>>> ksz9897port5@1 {
>>>> compatible = "ethernet-phy-ieee802.3-c22";
>>>> ...
>>>> clock-names = "rmii-ref";
>>>> phandle = <0x15>;
>>>> };
>>>> };
>>>>
>>>> spi@...0000 {
>>>> ...
>>>> ksz9897@0 {
>>>> compatible = "microchip,ksz9897";
>>>> ...
>>>> ports {
>>>> ...
>>>> // GMAC6
>>>> port@5 {
>>>> reg = <0x05>;
>>>> label = "cpu";
>>>> ethernet = <0x0c>;
>>>> phy-mode = "rmii";
>>>> rx-internal-delay-ps = <0x5dc>;
>>>> fixed-link {
>>>> speed = <0x64>;
>>>> full-duplex;
>>>> };
>>>> };
>>>> };
>>>> };
>>>> };
>>>> ```
>>>
>>>
>>> [1]
>> https://lore.kernel.org/netdev/BL0PR11MB2913BABB130DAB1E768810EFE7FB2@BL0PR1
>> 1MB2913.namprd11.prod.outlook.com/
>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-
>> next.git/tree/arch/arm/boot/dts/microchip/at91-sama5d3_ksz9477_evb.dts#n50
>>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-
>> next.git/tree/arch/arm/boot/dts/microchip/at91-sama5d3_ksz9477_evb.dts#n150
>>>
>>>> -----Original Message-----
>>>> From: Enguerrand de Ribaucourt <enguerrand.de-
>>>> ribaucourt@...oirfairelinux.com>
>>>> Sent: Friday, June 7, 2024 9:57 AM
>>>> To: Woojung Huh - C21699 <Woojung.Huh@...rochip.com>; netdev
>>>> <netdev@...r.kernel.org>
>>>> Cc: UNGLinuxDriver <UNGLinuxDriver@...rochip.com>
>>>> Subject: KSZ9897 RMII ports support
>>>>
>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know
>> the
>>>> content is safe
>>>>
>>>> Hello, this is a follow up to:
>>>>
>>>>
>> https://lore.kernel.org/netdev/BL0PR11MB2913BABB130DAB1E768810EFE7FB2@BL0PR1
>>>> 1MB2913.namprd11.prod.outlook.com/
>>>>
>>>> I have submitted patches to support the KSZ9897 RMII port (GMAC6)
>>>> connected to an i.MX6ULL (See above discussion). The current patch
>>>> implements a pseudo PHY-ID because the one emitted by KSZ9897R collides
>>>> with KSZ8081.
>>>>
>>>> Are there other ways to support this RMII connection that we want to
>>>> explore?
>>>>
>>>> Best Regards,
>>>>
>>>> Enguerrand de Ribaucourt
Powered by blists - more mailing lists