| 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: <BL0PR11MB2913957939FE5E262A241B03E7C22@BL0PR11MB2913.namprd11.prod.outlook.com>
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