netdev - Re: [PATCH V5] bgmac: driver for GBit MAC core on BCMA bus

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 8 Jan 2013 12:03:23 +0100
From:	Rafał Miłecki <zajec5@...il.com>
To:	Florian Fainelli <florian@...nwrt.org>
Cc:	netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
	Francois Romieu <romieu@...zoreil.com>,
	Joe Perches <joe@...ches.com>
Subject: Re: [PATCH V5] bgmac: driver for GBit MAC core on BCMA bus

2013/1/8 Florian Fainelli <florian@...nwrt.org>:
> Hello Rafal,
>
> Le 01/08/13 07:34, Rafał Miłecki a écrit :
>
>> BCMA is a Broadcom specific bus with devices AKA cores. All recent BCMA
>> based SoCs have gigabit ethernet provided by the GBit MAC core. This
>> patch adds driver for such a cores registering itself as a netdev. It
>> has been tested on a BCM4706 and BCM4718 chipsets.
>>
>> In the kernel tree there is already b44 driver which has some common
>> things with bgmac, however there are many differences that has led to
>> the decision or writing a new driver:
>> 1) GBit MAC cores appear on BCMA bus (not SSB as in case of b44)
>> 2) There is 64bit DMA engine which differs from 32bit one
>> 3) There is no CAM (Content Addressable Memory) in GBit MAC
>> 4) We have 4 TX queues on GBit MAC devices (instead of 1)
>> 5) Many registers have different addresses/values
>> 6) RX header flags are also different
>>
>> The driver in it's state is functional how, however there is of course
>> place for improvements:
>> 1) Supporting more net_device_ops
>> 2) SUpporting more ethtool_ops
>> 3) Unaligned addressing in DMA
>> 4) Writing separated PHY driver
>
>
> It does not seem like 4) would be too hard to do just right now because your
> PHY functions actually match the semantics of the callbacks you are supposed
> to implement for a separate PHY driver. Doing this would make you use phylib
> in the bgmac driver which is a good thing.
>
> I would be glad if you could do this just now, so we make sure this does not
> get lost.
>
> If David is ok with your v5 patch and wants to merge it just now, I am just
> as happy with that.

Personally I'd like to have it pushed even with limited features, as
long as it doesn't go anything really wrong.

It's harder to maintain whole driver as a patch, harder to make a
changes, harder to track/review them and somehow discouraging the
developer (me). I prefer sending small changes than mini-bomb of 64KB
code each time I want to change 5 lines.
You can always find some small feature that could be implemented with
a low cost and postpone driver inclusion for weeks/months. I'd like to
avoid that.
Apart from that, having driver pushed into some "real" tree makes it
possible for other developers to cooperate (see Nathan who sent fixes
to OpenWRT).

If you're afraid of forgetting anything from the "TODO" list placed in
commit message, we can always create a "TODO" file for the driver. I
don't think we really need that though.

-- 
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