[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+h21hp5aX00jtj5bSkig1jGY8JHAsKwGp+584jbOw3k82Z5KA@mail.gmail.com>
Date: Thu, 16 May 2019 09:56:06 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc: Florian Fainelli <f.fainelli@...il.com>,
Maxime Chevallier <maxime.chevallier@...tlin.com>,
Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...il.com>,
netdev <netdev@...r.kernel.org>,
"thomas.petazzoni@...tlin.com" <thomas.petazzoni@...tlin.com>,
Antoine Tenart <antoine.tenart@...tlin.com>,
Heiner Kallweit <hkallweit1@...il.com>
Subject: Re: dsa: using multi-gbps speeds on CPU port
On Wed, 15 May 2019 at 19:19, Russell King - ARM Linux admin
<linux@...linux.org.uk> wrote:
>
> On Wed, May 15, 2019 at 09:09:26AM -0700, Florian Fainelli wrote:
> > Vladimir mentioned a few weeks ago that he is considering adding support
> > for PHYLIB and PHYLINK to run without a net_device instance, you two
> > should probably coordinate with each other and make sure both of your
> > requirements (which are likely the same) get addressed.
>
> I don't see how that's sane unless we just replace the "netdevice" in
> there with an opaque "void *" and lose the typechecking.
>
> That then means we'd need to eradicate all the messages therein, since
> we can't use netdev_*() functions to print.
>
> Then there's the patches I still have, that were rejected, and have had
> no progress to get SFP working on 88x3310 - I'm just not bothering to
> push them due to the rejection, and the lack of any ideas how to
> approach this problem. So we have the Macchiatobin which has now been
> around for quite some time with SFP+ slots that are not particularly
> functional with mainline kernels (but hey, I don't care, because they
> work for me, because I have the patches that work!)
>
> You all know where that is, I've tried pointing it out several times...
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
I'm unfortunately not up to speed yet on what has been tried so far,
but I do plan to start prototyping the idea soon and I'll probably
find your patches then.
My basic idea is to interface a Raspberry Pi-like board to a dumb
"switch evaluation board" which has only the Ethernet ports and the
SPI/whatever control interface exposed. The DSA CPU/master port combo
in this case would go through a Cat5 cable, which is not going to pan
out very well currently because both the RPi-side PHY and the switch
board-side PHY need some massaging from their respective drivers. Both
PHYs are C22.
A rough idea of what I'm actually planning to do at:
https://www.spinics.net/lists/netdev/msg569087.html
-Vladimir
Powered by blists - more mailing lists