| 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: Thu, 13 Jun 2024 16:24:27 +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,
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@BL0PR11MB2913.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