| 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
| ||
|
Message-ID: <BL0PR11MB2913CE140EC9B807BD8CBBE2E7C12@BL0PR11MB2913.namprd11.prod.outlook.com>
Date: Thu, 13 Jun 2024 16:35:38 +0000
From: <Woojung.Huh@...rochip.com>
To: <enguerrand.de-ribaucourt@...oirfairelinux.com>
CC: <UNGLinuxDriver@...rochip.com>, <netdev@...r.kernel.org>
Subject: RE: KSZ9897 RMII ports support
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