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]

Message-ID: <50EBE8EE.2030902@openwrt.org>
Date:	Tue, 08 Jan 2013 10:37:50 +0100
From:	Florian Fainelli <florian@...nwrt.org>
To:	Rafał Miłecki <zajec5@...il.com>
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

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