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
| ||
|
Message-ID: <CAGVrzcYDLksA3gbJFypgp+f3BreMTTD5roHecoKm67M7qExOtg@mail.gmail.com> Date: Sun, 15 Feb 2015 13:05:12 -0800 From: Florian Fainelli <f.fainelli@...il.com> To: Andrew Lunn <andrew@...n.ch> Cc: Guenter Roeck <linux@...ck-us.net>, David Miller <davem@...emloft.net>, netdev <netdev@...r.kernel.org> Subject: Re: [PATCH 0/2] Indirect phy access for mv88e6171 2015-02-15 12:25 GMT-08:00 Andrew Lunn <andrew@...n.ch>: >> I'll try. My primary problem right now is that I run Lennert Buytenhek's >> patch set to support bridging offload (aka hardware bridging) on top of >> the upstream dsa code, and the upstream code now supports a competing / >> alternate means to support bridging/switching offload (NET_SWITCHDEV) >> which doesn't work with dsa (at least not yet). So I'll have to figure >> out if / how I can run your patches with my code base, or how I can add >> add support for NET_SWITCHDEV into dsa. > > We should be adding switchdev support to DSA for hardware > bridging. The concepts in Lennert Buytenhek's should be a good > starting point for this. In fact, there is not much to be implemented in DSA, since we already have everything in place in net-next now: - net_device notifier to learn which ports are leaving/joining the bridge - hook an abstraction for ndo_switch_port_stp_update - hook an abstraction for ndo_fdb_{add,del,dump} > >> Do you know if there are any efforts going on in that direction ? > > Florian has expressed an interest in getting hardware bridging > working. I've no idea if he has looked at it from the perspective of > switchdev. I have some patches that leverage the switchdev-related patches and bring an abstraction to DSA, they should not be fundamentally different at the DSA driver level, since most of the abstraction is done in net/dsa/slave.c, I plan on posting these patches tomorrow once I am back home. I tested these with the bcm_sf2 driver, so testing with Marvell hardware would be more than welcome. Thanks! -- Florian -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists