netdev - Re: DSA driver kernel extension for dsa mv88e6190 switch

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGAf8LyQpi_R-A2Zx72bJhSBqnFo-r=KCnfVCTD9N8cNNtbhrQ@mail.gmail.com>
Date:   Thu, 26 Sep 2019 15:23:48 +0200
From:   Zoran Stojsavljevic <zoran.stojsavljevic@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org
Subject: Re: DSA driver kernel extension for dsa mv88e6190 switch

Hello Andrew,

I would like to thank you for the reply.

I do not know if this is the right place to post such the questions,
but my best guess is: yes.

Since till now I did not make any success to make (using DSA driver)
make mv88e6190 single switch to work with any kernel.org. :-(

I did ugly workaround as kernel dsa patch, which allowed me to
introduce TXC and RXC clock skews between I.MX6 and mv88e6190 (MAC to
MAC layer over rgmii).

And, yes, switch is working in dummy state (as you correctly described
it), passing traffic everywhere (flooding).

i.MX6 has a silicon bug, which does not allow skew configuration on
its side. PCB is out of consideration, so this ugly patch makes switch
to apply these two delays.Then, in dummy state, everything works.
_______

My DTS mv88e6190 configuration, which I adopted for the custom board I
am working on, could be seen here:
https://pastebin.com/xpXQYNRX

But on another note... I am wondering if I am setting correct kernel
configuration for it?!

Here is the part of the configuration I made while going through maze
of posts from google search results:

      Switch (and switch-ish) device support @ Networking
support->Networking options
      Distributed Switch Architecture @ Networking support->Networking options
      Tag driver for Marvell switches using DSA headers @ Networking
support->Networking options->Distributed Switch Architecture
      Tag driver for Marvell switches using EtherType DSA headers @
Networking support->Networking options->Distributed Switch
Architecture
      Marvell 88E6xxx Ethernet switch fabric support @ Device
Drivers->Network device support->Distributed Switch Architecture
drivers
      Switch Global 2 Registers support @ Device Drivers->Network
device support->Distributed Switch Architecture drivers->Marvell
88E6xxx Ethernet switch fabric support
      Freescale devices @ Device Drivers->Network device
support->Ethernet driver support
      FEC ethernet controller (of ColdFire and some i.MX CPUs) @
Device Drivers->Network device support->Ethernet driver
support->Freescale devices
      Marvell devices @ Device Drivers->Network device
support->Ethernet driver support
      Marvell MDIO interface support @ Device Drivers->Network device
support->Ethernet driver support->Marvell devices
      MDIO Bus/PHY emulation with fixed speed/link PHYs @ Device
Drivers->Network device support->PHY Device support and infrastructure

(Do we need Marvell PHYs option as =y ? I do not think so - should be:
is not set)

What possibly I made wrong here (this does not work - I could not get
through the switch, and seems that MDIO works (from the logic
analyzer), but addresses some 0x1B/0x1C ports, which should NOT be
addressed, according to the the DTS configuration shown)?

Thank you,
Zoran
_______

On Thu, Sep 26, 2019 at 1:10 AM Andrew Lunn <andrew@...n.ch> wrote:
>
> > We have the configuration problem with the Marvell 88E6190 switch.
> > What the our problem is... Is the switch is NOT configured with the
> > EEPROM (24C512), which does not exist on the board.
>
> That is pretty normal. If there is a EEPROM, i generally recommend it
> is left empty. We want Linux to configure the switch, and if it finds
> it already partially configured, things can get confused.
>
> > It is put in autoconfig by HW straps (NOCPU mode).
>
> So dumb switch mode. All ports are switched between each other.
>
> > Once the MDIO command, issued to
> > probe the switch and read the make of it, the switch jumps out of the
> > autoconfig mode.
>
> Correct. Dumb switch mode is dangerous. There is no STP, etc.
> Depending on what you have in device tree, the ports are either
> configured down, or separated.
>
> > There are some commands issued from the DSA to
> > configure the switch (to apply to switch TXC and RXC RGMII delays -
> > RGMII-ID mode), but this is not enough to make it work properly.
>
> Define 'work properly'. How are you configuring the interfaces?  Do
> you remember to bring the master interface up? Are you adding the
> interfaces to a bridge?
>
>    Andrew