netdev - Re: DSA support for Marvell 88e6065 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: <20181118201528.GA18518@amd>
Date:   Sun, 18 Nov 2018 21:15:28 +0100
From:   Pavel Machek <pavel@...x.de>
To:     Andrew Lunn <andrew@...n.ch>, pavel@...x.de
Cc:     netdev@...r.kernel.org, f.fainelli@...il.com, buytenh@...vell.com,
        buytenh@...tstofly.org, nico@...vell.com
Subject: Re: DSA support for Marvell 88e6065 switch

HI!

> > > > I'm trying to create support for Marvell 88e6065 switch... and it
> > > > seems like drivers/net/dsa supports everything, but this model.
> > > > 
> > > > Did someone work with this hardware before? Any idea if it would be
> > > > more suitable to support by existing 88e6060 code, or if 88e6xxx code
> > > > should serve as a base?
> > > 
> > > Hi Pavel
> > > 
> > > The 88e6xxx should be extended to support this. I think you will find
> > > a lot of the building blocks are already in the driver. Compare the
> > > various implementations of the functions in the mv88e6xxx_ops to what
> > > the datasheet says for the registers, and pick those that match.
> > 
> > Ok, so I played a bit.
> > 
> > It looks like e6065 has different register layout from those supported
> > by 6xxx, and is quite similar to e6060.
> 
> Hi Pavel
> 
> However, if you look in the mv88e6xxx, there are quite a few functions
> called mv88e6065_foo. Marvell keeps changing the register layout. When
> writing code, we try to name the functions based on which family of
> devices introduced those registers. But we don't have the whole
> history, so we probably have some names wrong.

Let me check... I thought there was only one such function. Ok, I see
two such functions:

mv88e6065_phylink_validate
mv88e6065_port_set_speed

I may need to re-check, but it looked to me like even functions and
registeres labeled 6xxx are different on 6060 and 6065... which means
changes to the code would not be exactly nice and easy.

> > I understand how 88e6xxx code is supposed to work... but I don't
> > understand how e6060 code is supposed to be probed. It does not seem
> > to have device tree support. It seems to be older code, but is way
> > simpler, and seems to be targetted at similar hardware.
> 
> The e6060 code is really old, pretty much abandoned. To make it
> usable, you are going to have to make a lot of changes. Turn it into
> an mdio driver, add device tree, make it use the new dsa2.c API, etc.

If I wanted it to work, what do I need to do? AFAICT phy autoprobing
should just attach it as soon as it is compiled in?

I tried adding nodes in dts trying to make the driver attach, but no
luck so far.

> I still think you should be looking at the mv88e6xxx driver, but maybe
> taking bits of code from the 6060 driver and adding it to the
> mv88e6xxx driver as needed.

e6060 driver is much simpler, which is somehow nice. Let me look
around some more.

Thanks,
								Pavel
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)