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-next>] [day] [month] [year] [list]
Message-ID: <20220106095003.GA253016@euler>
Date:   Thu, 6 Jan 2022 01:50:03 -0800
From:   Colin Foster <colin.foster@...advantage.com>
To:     netdev@...r.kernel.org
Cc:     Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Vladimir Oltean <olteanv@...il.com>,
        katie.morris@...advantage.com, UNGLinuxDriver@...rochip.com
Subject: ocelot-pcs - qsgmii planning

Hi Alexandre, Vladimir, and those with interest of Ocelot chips,

I'm starting this thread to just touch base before I dive into any PCS
changes for Ocelot. I've appreciated all your guidance, and the only
time I felt I've been led astray is when Alexandre told me it should be
easy :-)

I'm at the point where I'm starting to integrate the additional 4 copper
ports of the VSC7512 reference board. They are 4 ports connected through
a QSGMII bus, to a VSC8514 phy.

The 8514 driver seems to be getting invoked, and running just fine.
Also, I was able to slightly modify (hack*)
drivers/phy/mscc/phy-ocelot-serdes.c to work with my in-development
ocelot-mfd. I believe that is what I need to configure the HSIO
registers.

(*the device_is_mfd info I was using falls apart with the
HSIO/syscon/mfd implementation here, sadly. A new probe function would
easily clean that up, but it is more for me to think about... I digress)

I'm using these device tree settings:

    port@4 {
        reg = <4>;
        label = "swp4";
        status = "okay";
        phy-handle = <&sw_phy4>;
        phy-mode = "qsgmii";
        phys = <&serdes 4 SERDES6G(0)>;
    };
    port@5 {
        reg = <5>;
        label = "swp5";
        status = "okay";
        phy-handle = <&sw_phy5>;
        phy-mode = "qsgmii";
        phys = <&serdes 5 SERDES6G(0)>;
    };
...
    serdes: serdes {
        compatible = "mscc,vsc7514-serdes";
        #phy-cells = <2>;
    };
    mdio1: mdio1 {
        compatible = "mscc,ocelot-miim",
        pinctrl-names = "default";
        pinctrl-0 = <&miim1>;
        #address-cells = <1>;
        #size-cells = <0>;

        sw_phy4: ethernet-phy@4 {
            reg = <0x4>;
        };
    };

[    3.886787] libphy: ocelot_ext MDIO bus: probed
[    5.345891] ocelot-ext-switch ocelot-ext-switch: PHY [ocelot-ext-switch-mii:00] driver [Generic PHY] (irq=POLL)
[    5.357341] ocelot-ext-switch ocelot-ext-switch: configuring for phy/internal link mode
[    5.372525] ocelot-ext-switch ocelot-ext-switch swp1 (uninitialized): PHY [ocelot-ext-switch-mii:01] driver [Generic PHY] (irq=POLL)
[    5.388865] ocelot-ext-switch ocelot-ext-switch swp2 (uninitialized): PHY [ocelot-ext-switch-mii:02] driver [Generic PHY] (irq=POLL)
[    5.405086] ocelot-ext-switch ocelot-ext-switch swp3 (uninitialized): PHY [ocelot-ext-switch-mii:03] driver [Generic PHY] (irq=POLL)
[    6.291876] ocelot-ext-switch ocelot-ext-switch swp4 (uninitialized): PHY [ocelot-miim1-mii:04] driver [Microsemi GE VSC8514 SyncE] (irq=POLL)
[    6.471891] ocelot-ext-switch ocelot-ext-switch swp5 (uninitialized): PHY [ocelot-miim1-mii:05] driver [Microsemi GE VSC8514 SyncE] (irq=POLL)
[    6.651895] ocelot-ext-switch ocelot-ext-switch swp6 (uninitialized): PHY [ocelot-miim1-mii:06] driver [Microsemi GE VSC8514 SyncE] (irq=POLL)
[    6.831879] ocelot-ext-switch ocelot-ext-switch swp7 (uninitialized): PHY [ocelot-miim1-mii:07] driver [Microsemi GE VSC8514 SyncE] (irq=POLL)


It seems like that, along with everything in vsc7514_phylink_mac_config,
should be everything I need for operation of the four ports through the
8512. I've added OCELOT_QUIRK_SGMII_PORTS_MUST_BE_UP - but I'm not sure
that's a quirk I need. Plus the only behavior it currently adds is once
the port is up, it never comes back down.

The current behavior I'm seeing is links and rates get detected, packets
appear to be getting transmitted (ethtool stats) but they aren't, and
nothing is received on either end.

Is there something I'm missing with the device tree? Or is this the
purpose of the PCS driver I'm looking into? I'm getting a feeling that
my configuration is correct, and that I need to add SerDes support for
these ports in phylink_mac_config... I noticed that there's the "SGMII
only for now" comment, and when I look at the reference application for
the 7512 there's a comment "external phy uses QSGMII interface" that
appears to set the SGMII_MODE_ENA bit to 0.


Thank you as always for your time,

Colin Foster.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ