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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 14 Jun 2024 13:29:40 +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,

Glad that the issue is resolved.
Will ask to close the ticket too with log of email thread.

Best regards
Woojung

> -----Original Message-----
> From: Enguerrand de Ribaucourt <enguerrand.de-
> ribaucourt@...oirfairelinux.com>
> Sent: Friday, June 14, 2024 3:33 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 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

Powered by Openwall GNU/*/Linux Powered by OpenVZ