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]
Date:   Sat, 28 Sep 2019 01:00:43 +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,

> You should not need any kernel patches for switch side RGMII
> delays. rgmii-id in the DT for the switch CPU port should be enough.
> Some of the vf610-zii platforms use it.

It should, but it does NOT work. IT is clearly stated in port.c, in f-n:
static int mv88e6xxx_port_set_rgmii_delay(struct mv88e6xxx_chip *chip, int port,
                                          phy_interface_t mode)

The logic analyser shows MDIO write to register 0x01, which is 0x6003.
Seems the correct value.

But, at the very end, ethtool shows that this clock skew is NOT
inserted. I see on RX side CRC errors. Every ethernet frame while
pinging.

I see another interesting fact, the dmesg, which you could see here:
https://pastebin.com/igXS6eXe

[    1.182273] DEBUG INFO! <- addr: 0x00 reg: 0x03 val: 0x1901
[    1.187888] mv88e6085 2188000.ethernet-1:00: switch 0x1900
detected: Marvell 88E6190, revision 1
[    1.219804] random: fast init done
[    1.225334] libphy: mv88e6xxx SMI: probed
[    1.232709] fec 2188000.ethernet eth0: registered PHC device 0

[    1.547946] DEBUG INFO! <- addr: 0x00 reg: 0x03 val: 0x1901
[    1.553542] mv88e6085 2188000.ethernet-1:00: switch 0x1900
detected: Marvell 88E6190, revision 1
[    1.555432]  mmcblk1: p1
[    1.598106] libphy: mv88e6xxx SMI: probed
[    1.740362] DSA: tree 0 setup

There are two distinct accesses while driver configures the switch. Why???

I was not able to explain this to me... Or find explanation using google?!

> gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>; is wrong. It probably
> should be reset-gpios. The rest looks O.K.

I will follow the advise, but I do not think this is an obstacle.

> Please show me the configuration steps you are doing? How are you
> configuring the FEC and the switch interfaces?

Forgive me for my ignorance, but I have no idea what you have asked me for?

Did you ask me to attach .config file? If not, could you, please,
explain to me more concrete, what did you ask for? Some example would
be perfect!

Thank you,
Zoran
_______

On Thu, Sep 26, 2019 at 3:39 PM Andrew Lunn <andrew@...n.ch> wrote:
>
> On Thu, Sep 26, 2019 at 03:23:48PM +0200, Zoran Stojsavljevic wrote:
> > 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).
>
> You should not need any kernel patches for switch side RGMII
> delays. rgmii-id in the DT for the switch CPU port should be enough.
> Some of the vf610-zii platforms use it.
>
> > My DTS mv88e6190 configuration, which I adopted for the custom board I
> > am working on, could be seen here:
> > https://pastebin.com/xpXQYNRX
>
> So you have the FEC using rgmii-id. Which you say does not work?  So
> why not use plain rgmii. What you have in port@0 looks correct.
>
> gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>; is wrong. It probably should be
> reset-gpios. The rest looks O.K.
>
>
> > 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)
>
> Yes you do. The PHYs inside the switch are Marvell.
>
> > 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)?
>
> 0x1b is global1, and 0x1c is global2. These are registers shared by
> all ports.
>
> Please show me the configuration steps you are doing? How are you
> configuring the FEC and the switch interfaces?
>
>     Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ