[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54ED024B.9090605@gmail.com>
Date: Tue, 24 Feb 2015 14:59:23 -0800
From: Florian Fainelli <f.fainelli@...il.com>
To: Rafał Miłecki <zajec5@...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/02/15 14:56, Rafał Miłecki wrote:
> 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.
I would prefer if you could give me the time to implement that:
http://www.spinics.net/lists/netdev/msg295942.html
such that you would get a lot of the network device creation, operations
etc.. for free, with your driver still being a phy_driver ultimately.
But I have no strong objections either.
--
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