| 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: Tue, 9 Mar 2021 21:55:28 +0000
From: "Wyse, Chris" <cwyse@...oga.com>
To: "andrew@...n.ch" <andrew@...n.ch>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"drichards@...inj.com" <drichards@...inj.com>
Subject: Re: DSA
On Tue, 2021-03-09 at 17:46 +0100, Andrew Lunn wrote:
>
> > I have a board that uses the Intel i210, and I'd like it be the DSA
> > master. I'm looking for suggestions on how to proceed.
> >
> > My configuration is an Intel E3950 CPU running Linux 4.19.62,
>
> Hi Chris
>
> That is old. Can you update to 5.10.22? If you plan submitting any
> kernel patches, you will need to be using net-next.
First -- thanks for the quick response. I'm not as quick as you...
Anyway, yes - the kernel is old. I can't update it right now, but
we're planning a new version that would use a current kernel.
>
> > using
> > UEFI/ACPI. The board has a Xilinx FPGA that supports SFP & QSFP
> > devices. The SFP ports use the standard SFP driver & phylink. The
> > QSFP ports use a modified version of the SFP driver.
>
> Rusell King has some currently out of tree patches for QSFP. Since he
> wrote the SFP code, you should talk to him, see what is needed to get
> his changes merged.
That's great information. We searched all over for QSFP support, but
ended up writing our own. I'll get in touch with Rusell.
>
> > It also includes an interface to an Intel i210 ethernet.
> >
> > We use device tree overlays to load the information for the devices
> > supported by the FPGA, then load an MFD FPGA driver that
> instantiates
> > platform drivers for each of those devices. One of the drivers
> that
> > gets loaded is a DSA driver that has the SFP & QSFP devices as its
> > slaves. The intent is to use the Intel i210 on the master port of
> the
> > DSA driver.
>
> So the switch is inside the FPGA? What is the control path for this
> switch? The biggest problem with i210 is its MDIO bus. MDIO is often
> used to control an Ethernet switch. But if your switch is inside the
> FPGA, i guess you are not using MDIO?
>
Yes, the switch is inside the FPGA. The i210 is connected to the CPU
via a PCIe bus. It's connected to a PHY which is connected to a
modified EMACLite IP module in the FPGA which only supports MDIO, and
to a custom MAC implemented in the FPGA. The FPGA logic directs
packets to the appropriate ports of the switch, adding and removing
tags as appropriate. The switch contains multiple MACs, which are
connected to SFPs and QSFPs (not shown).
Assuming the drawing below doesn't get corrupted with line breaks, it
is a pretty good representation of our system.
+-----------------------------+
| |
| | | +-----------+ | +--------+
| |P| | | MDI | |BroadCom|
| |C+-----+ i210 +------+->| PHY |
| |I| | | | | |
| |e| +-----------+ | +-+----+-+
| | | | | |
| |B| +----------+-----+ | | |
| |u| |DSA Driver| | | | | MDIO Only
| |s+-----+ TAG | CPU | | | +-------------+
| | | | Protocol | | | | |
| | | +----------+-+-+-+ | | |
| |P| | | |
+-----------------------+C+---+ | |
|I| | |
|e| | |
| | | SGMII |
|B| +-----+ |
|u| | |
|s| | |
| | v v
+-----------------+-----+-+------+--+----------+-+------------+----+
| | PCIe Control | |Custom MAC| | EMAC Lite | |
| +---------+ | Block | |(No MDIO) | | IP Module | |
| |Switch | +-+------------+ +-+--------+ +------------+ |
| |Registers+------+ | ^ |
| +---------+ | | |
| +---------------+ | |
| | | |
| | +-------+ +----------+-----+
| | | | | |
| | +-----+-----+ | | MAC |
| | | Map & Add | | | |
| F P G A | | Port Tags |<--------+ +-----+
| | +-----------+ | | |
| | | Switch | MAC |
| | +-----------+ | | |
| +--->| Del & Map +-------->| +-----+
| | Port Tags | | | |
| +-----------+ | | MAC |
| | | |
| +----------+-----+
| |
+------------------------------------------------------------------+
> > At first glance, I believe I need to complete these tasks:
> > 1. Create a device tree node for the i210, providing information
> on
> > the already loaded driver, that can be used by the DSA driver.
> > 2. Obtain or update a i210 driver that will work with DSA
>
> Take a look at arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
>
> &pcie {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_pcie>;
> reset-gpio = <&gpio7 12 GPIO_ACTIVE_LOW>;
> status = "okay";
>
> host@0 {
> reg = <0 0 0 0 0>;
>
> #address-cells = <3>;
> #size-cells = <2>;
>
> i210: i210@0 {
> reg = <0 0 0 0 0>;
> };
> };
> };
>
I'll look at this, but one thing I see initially is that there are
references to other nodes that are not present in our device tree
overlay. The overlay solely supports the IP modules in the FPGA. Both
of our PCIe buses are handled via the ACPI table. I'm not sure how to
handle something that already has an ACPI node.
Definitely a bit lost on how to proceed with the combination of ACPI &
device tree.
> So this is an i210 on the PCIe bus of an IMX6.
>
> It never made it into mailine, but we did have a setup where instead
> of using the FEC Ethernet controller inside the IMX6, we used the
> i210
> as the master. The usual phandle to this i210 just worked. The switch
> was managed via MDIO from the FEC, or bit banging.
>
> So assuming you switch control is not via the i210 MDIO bus, with the
> correct DT, it should 'just work'.
>
> Andrew
--
Chris Wyse
Embedded Software Development
(203) 888-7914 ext 203
Canoga Perkins
100 Bank St,
Seymour, CT 06483
________________________________
Canoga Perkins
20600 Prairie Street
Chatsworth, CA 91311
(818) 718-6300
This e-mail and any attached document(s) is confidential and is intended only for the review of the party to whom it is addressed. If you have received this transmission in error, please notify the sender immediately and discard the original message and any attachment(s).
Powered by blists - more mailing lists