[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACna6rxgwdm0YJqf0fTZFROUjC--aiKUNT=tLOF4XwyMrzjtnA@mail.gmail.com>
Date: Tue, 24 Feb 2015 23:56:28 +0100
From: Rafał Miłecki <zajec5@...il.com>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: "David S. Miller" <davem@...emloft.net>,
Network Development <netdev@...r.kernel.org>,
Jonas Gorski <jogo@...nwrt.org>,
Hauke Mehrtens <hauke@...ke-m.de>,
Felix Fietkau <nbd@...nwrt.org>, Jiri Pirko <jiri@...nulli.us>
Subject: Re: [PATCH] net: phy: b53: switchdev driver for Broadcom BCM53xx switches
On 24 February 2015 at 23:48, Florian Fainelli <f.fainelli@...il.com> wrote:
> On 24/02/15 09:42, Rafał Miłecki wrote:
>> BCM53xx is series of Broadcom Ethernet switches that can be found in
>> various (mostly home) routers.
>> They are quite simple switches with mainly just support for:
>> 1) Tagging incoming packets (PVID)
>> 2) Untagging outgoing packets
>> 3) Forwarding all packets across a single VLAN
>>
>> This driver is split into common code (module) and bus specific code.
>> Right now only PHY (MDIO) support is included, other could follow after
>> accepting this driver. It was successfully tested on BCM4706 SoC with
>> BCM53125.
>>
>> You could notice it's yet another try of submitting b53 driver. This
>> time it was modified to use recently introduced switchdev API which
>> hopefully make it possible to accept it mainline.
>
> This is good as a very basic driver,
Thanks :) That was exactly my point: to get a minimal driver (but
implementing the basic functionality!) accepted and then continue
improving it.
> there is still a bunch of things
> missing that might not be too hard to add to this submission:
>
> - fetching MIB counters through ethtool
> - reporting link state/parameters
> - changing MTU/Jumbo frame support
> - HW bridging support
I agree about missing features. I was already thinking about MIB, it
should be easy to support it with ethtool_ops and get_sset_count +
get_strings. Probably the same for link status. Not sure about HW
bridging.
Would you agree to work on having this basic driver accepted first
(like discussing code location, API usage) and then work on additional
features in separated patches? I think it would simplify the process
and could result in better core review, as people could focus on small
bunch of changes.
--
Rafał
--
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