[OpenWrt-Devel] [PATCH 3/3] b53: create slave devices for ports

Alexandru Ardelean ardeleanalex at gmail.com
Thu May 21 04:06:45 EDT 2015


Seems this discussion has stalled a bit.
I guess it would be reasonable to ask: what could I do to help to get this
moving both here and on LKML ?
I'll go ahead and say that I do not monitor LKML much since I haven't found
a model (that suits me well) for monitoring discussions without getting my
inbox too full.
That also means I'm not up to date with general stuff, so if just get
corrected (or updated) here, that would make me happy too.

I've been reading up on this talk:
http://thread.gmane.org/gmane.linux.network/351503

At the moment we're updating the b53-swconfig version internally, and I
haven't managed to find the time to re-implement the changes from my
initial patchset (which I submitted).
If this gets accepted upstream, then I'd prefer to update it there.
Normally I don't mind to implement stuff multiple times (b53 in swconfig,
and then b53 in the kernel when that gets accepted) but my time constraints
don't allow me now to be so flexible at this time.


On Tue, Mar 10, 2015 at 2:24 PM, Jonas Gorski <jogo at openwrt.org> wrote:

> On Sat, Feb 28, 2015 at 9:22 AM, Rafał Miłecki <zajec5 at gmail.com> wrote:
> > On 26 February 2015 at 19:24, Florian Fainelli <f.fainelli at gmail.com>
> wrote:
> >> On 25/02/15 07:24, Alexandru Ardelean wrote:
> >>> Feature implemented and tested on BCM53128.
> >>>
> >>> Slave devices logic copied from the Linux kernel from Marvell's DSA
> >>> driver ( linux/net/dsa/ ).
> >>> Also the logic for the Broadcom tag processing has been copied from
> there.
> >>
> >> There are different efforts here going on, and I would like to at least
> >> 3 different people (you, Rafal and myself) can converge to an identical
> >> solution that fits everybody here.
> >
> > I agree. I think we should focus on getting this cleared and accepted
> > upstream. I don't think I want to keep adding features like port
> > interfaces to swconfig.
>
> I agree with this, as it also has the potential of breaking switches
> because of different header formats used.
>
>
> Jonas
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20150521/de816b7c/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


More information about the openwrt-devel mailing list