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  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:   Thu, 16 May 2019 09:56:06 +0300
From:   Vladimir Oltean <>
To:     Russell King - ARM Linux admin <>
Cc:     Florian Fainelli <>,
        Maxime Chevallier <>,
        Andrew Lunn <>,
        Vivien Didelot <>,
        netdev <>,
        "" <>,
        Antoine Tenart <>,
        Heiner Kallweit <>
Subject: Re: dsa: using multi-gbps speeds on CPU port

On Wed, 15 May 2019 at 19:19, Russell King - ARM Linux admin
<> 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:
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to 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:


Powered by blists - more mailing lists