* Re: [RFC 00/72] Organize/Move of the Ethernet drivers in drivers/net/
From: Bill Fink @ 2011-06-26 7:54 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev
In-Reply-To: <1309010363-22750-1-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, 25 Jun 2011, Jeff Kirsher wrote:
> The following series is the first attempt to organize the drivers/net
> directory. This process was started a year ago, and the emphasis was
> on making the drivers/net/ easier to maintain and to group similar
> drivers into the appropriate sub-directory.
>
> The next steps are to move all the FIDDI drivers into drivers/net/fiddi,
> and like so. In addition, look at splitting the PS3 driver so that the
> wireless portion can be moved into /drivers/net/wireless.
That should be FDDI, not FIDDI.
-Bill
^ permalink raw reply
* Re: [RFC 26/72] arm: Move the ARM/ACORN drivers
From: Joe Perches @ 2011-06-26 6:38 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: Arnd Bergmann, Russell King - ARM Linux, davem@davemloft.net,
netdev@vger.kernel.org, Sriram, Vinay Hegde, Cyril Chemparathy,
Wan ZongShun, Lennert Buytenhek, Krzysztof Halasa, Anant Gole,
Chaithrika U S
In-Reply-To: <1309025217.2454.89.camel@jtkirshe-mobl>
On Sat, 2011-06-25 at 11:06 -0700, Jeff Kirsher wrote:
> On Sat, 2011-06-25 at 09:59 -0700, Arnd Bergmann wrote:
> > Jeff created a drivers/net/ethernet/8390/ directory for all of those,
> > which sounds sensible to me, but apparently he missed some of the
> > nonobvious ones.
> I was trying to keep the drivers that use the 8390 common files grouped
> together.
Please move a2065, ariadne and zorro8390 too.
> I know that there are other instances like this (for instance drivers
> derived from the lance.c driver) yet these derived drivers do not use
> the common files that other lance drivers use. Because they are
> derived, yet do not use the common code, should they still be grouped
> together?
IMO, yes.
^ permalink raw reply
* Re: [RFC 20/72] pasemic_mac*: Move the PA Semi driver
From: Olof Johansson @ 2011-06-26 1:34 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev
In-Reply-To: <1309010363-22750-21-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, Jun 25, 2011 at 6:58 AM, Jeff Kirsher
<jeffrey.t.kirsher@intel.com> wrote:
> Move the PA Semi driver into drivers/net/ethernet/ and make the
> necessary Kconfig and Makefile changes.
>
> CC: Olof Johansson <olof@lixom.net>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: Olof Johansson <olof@lixom.net>
^ permalink raw reply
* Re: [RFC 18/72] ehea/ibm*: Move the IBM drivers
From: Benjamin Herrenschmidt @ 2011-06-26 0:37 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Oliver Hartkopp, Jeff Kirsher, davem, netdev, Christoph Raisch,
Alfred Arnold, Santiago Leon
In-Reply-To: <201106251704.22561.arnd@arndb.de>
On Sat, 2011-06-25 at 17:04 +0200, Arnd Bergmann wrote:
> You can probably rename to just emac now, since the "old" emac driver
> has been gone for some time.
>
> The "new" part of the name does not refer to the hardware, just to
> the driver.
Right. Agreed.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] net, llc: Avoid undefined behaviour in llc_conn_ac_inc_vr_by_1()
From: Jesper Juhl @ 2011-06-26 0:01 UTC (permalink / raw)
To: David Miller; +Cc: acme, netdev, linux-kernel
In-Reply-To: <20110625.170445.957364657527336185.davem@davemloft.net>
On Sat, 25 Jun 2011, David Miller wrote:
> From: Jesper Juhl <jj@chaosbits.net>
> Date: Sun, 26 Jun 2011 00:11:12 +0200 (CEST)
>
> > Introduce a sequence point (;) between two writes to llc_sk(sk)->vR in
> > net/llc/llc_c_ac.c:llc_conn_ac_inc_vr_by_1() so that the order in
> > which the writes happen become well defined.
> >
> > While the code may work fine now it may break at any time with a
> > different compiler, a new version of current compiler or even just a
> > different optimization level of the current compiler. Much better to
> > clearly express what's intended in a way that guarantees the result.
> >
> > Signed-off-by: Jesper Juhl <jj@chaosbits.net>
>
> How about fixing the macro so that it doesn't have side effects
> like this?
>
> That's much better than a 6 line (improperly formatted, BTW) comment
> every time someone tried to use that macros with an lvalue that isn't
> a local variable.
Sure, that's also a way to go - better probably.
I just thought that I would fix up the one call site I found that was
problematic...
But gimme a couple of days (I don't have much free time) and I'll cook up
a different patch.
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply
* Re: [PATCH] net, llc: Avoid undefined behaviour in llc_conn_ac_inc_vr_by_1()
From: David Miller @ 2011-06-26 0:04 UTC (permalink / raw)
To: jj; +Cc: acme, netdev, linux-kernel
In-Reply-To: <alpine.LNX.2.00.1106260009530.23991@swampdragon.chaosbits.net>
From: Jesper Juhl <jj@chaosbits.net>
Date: Sun, 26 Jun 2011 00:11:12 +0200 (CEST)
> Introduce a sequence point (;) between two writes to llc_sk(sk)->vR in
> net/llc/llc_c_ac.c:llc_conn_ac_inc_vr_by_1() so that the order in
> which the writes happen become well defined.
>
> While the code may work fine now it may break at any time with a
> different compiler, a new version of current compiler or even just a
> different optimization level of the current compiler. Much better to
> clearly express what's intended in a way that guarantees the result.
>
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
How about fixing the macro so that it doesn't have side effects
like this?
That's much better than a 6 line (improperly formatted, BTW) comment
every time someone tried to use that macros with an lvalue that isn't
a local variable.
^ permalink raw reply
* Re: [RFC 11/72] cassini/niu/sun*: Move the Sun drivers
From: David Miller @ 2011-06-25 23:56 UTC (permalink / raw)
To: socketcan; +Cc: jeffrey.t.kirsher, netdev, sammy, asun, benh
In-Reply-To: <4E05F4D3.9020407@hartkopp.net>
From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Sat, 25 Jun 2011 16:46:43 +0200
> On 25.06.2011 15:58, Jeff Kirsher wrote:
>> Moves the Sun drivers into drivers/net/ethernet/sun/ and make
>> the necessary Kconfig and Makefile changes.
>>
>
> (..)
>
>> ---
>> MAINTAINERS | 1 +
>> drivers/net/Kconfig | 75 ----------------------
>> drivers/net/Makefile | 11 +---
>> drivers/net/ethernet/Kconfig | 1 +
>> drivers/net/ethernet/Makefile | 1 +
>> drivers/net/ethernet/sun/Kconfig | 91 +++++++++++++++++++++++++++
>> drivers/net/ethernet/sun/Makefile | 12 ++++
>> drivers/net/{ => ethernet/sun}/cassini.c | 0
>> drivers/net/{ => ethernet/sun}/cassini.h | 0
>> drivers/net/{ => ethernet/sun}/niu.c | 0
>> drivers/net/{ => ethernet/sun}/niu.h | 0
>> drivers/net/{ => ethernet/sun}/sun3_82586.c | 0
>> drivers/net/{ => ethernet/sun}/sun3_82586.h | 0
>
> s/sun3_// in filenames?
It's a special instance of the chip which only ever
appears on the motherboard of m68k based sun3 systems.
The sun3 prefix is absolutely appropriate.
^ permalink raw reply
* [PATCH] net, llc: Avoid undefined behaviour in llc_conn_ac_inc_vr_by_1()
From: Jesper Juhl @ 2011-06-25 22:11 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo; +Cc: David S. Miller, netdev, linux-kernel
Introduce a sequence point (;) between two writes to llc_sk(sk)->vR in
net/llc/llc_c_ac.c:llc_conn_ac_inc_vr_by_1() so that the order in
which the writes happen become well defined.
While the code may work fine now it may break at any time with a
different compiler, a new version of current compiler or even just a
different optimization level of the current compiler. Much better to
clearly express what's intended in a way that guarantees the result.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
net/llc/llc_c_ac.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/net/llc/llc_c_ac.c b/net/llc/llc_c_ac.c
index ea225bd..e535ca4 100644
--- a/net/llc/llc_c_ac.c
+++ b/net/llc/llc_c_ac.c
@@ -1296,7 +1296,14 @@ int llc_conn_ac_set_vr_0(struct sock *sk, struct sk_buff *skb)
int llc_conn_ac_inc_vr_by_1(struct sock *sk, struct sk_buff *skb)
{
- llc_sk(sk)->vR = PDU_GET_NEXT_Vr(llc_sk(sk)->vR);
+ /* Do not consolidate this on one line. Since the PDU_GET_NEXT_Vr
+ macro increments its argument which is the same as what we are
+ writing to, then we'll have two writes to the same variable
+ without an intervening sequence point, which leads to the
+ situation where we can't really know what gets stored as the
+ result since the compiler is free to do those in any order. */
+ const u8 new_vr = PDU_GET_NEXT_Vr(llc_sk(sk)->vR);
+ llc_sk(sk)->vR = new_vr;
return 0;
}
--
1.7.5.2
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* Re: RFT: virtio_net: limit xmit polling
From: Roopa Prabhu @ 2011-06-25 19:44 UTC (permalink / raw)
To: Roopa Prabhu, Tom Lendacky, Michael S. Tsirkin
Cc: Krishna Kumar2, habanero, lguest, Shirley Ma, kvm, Carsten Otte,
linux-s390, Heiko Carstens, linux-kernel, virtualization, steved,
Christian Borntraeger, netdev, Martin Schwidefsky, linux390
In-Reply-To: <CA29D629.2C9B1%roprabhu@cisco.com>
[-- Attachment #1.1: Type: text/plain, Size: 3019 bytes --]
Here are the results I am getting with a Cisco 10G VIC adapter.
All tests are from the guest to an external host.
virtio-net-limit-xmit-polling/base:
TCP_STREAM: 8089Mbps
TCP_MAERTS: 9334Mbps
virtio-net-limit-xmit-polling/v0
TCP_STREAM: 8004Mbps
TCP_MAERTS: 9338Mbps
virtio-net-limit-xmit-polling/v1
TCP_STREAM: 8028Mbps
TCP_MAERTS: 9339Mbps
virtio-net-limit-xmit-polling/v2
TCP_STREAM: 8045Mbps
TCP_MAERTS: 9337Mbps
For the TCP_STREAM tests I don¹t get consistent results.
Every run gives me slightly different results. But its always between
7900Mbps to 8100Mbps.
But I also see this with the base kernel so its not related to these
patches.
Thanks,
Roopa
On 6/24/11 5:50 AM, "Roopa Prabhu" <roprabhu@cisco.com> wrote:
> Michael,
>
> I am testing this too.
> I have finished one round of testing. But am running it again just to
> confirm.
> This time I will see if I can collect some exit stats too. Will post results
> sometime this weekend.
> I am just doing TCP_STREAM and TCP_MAERTS from guest to remote host.
>
> Thanks,
> Roopa
>
>
> On 6/21/11 8:23 AM, "Tom Lendacky" <tahm@linux.vnet.ibm.com> wrote:
>
>> On Sunday, June 19, 2011 05:27:00 AM Michael S. Tsirkin wrote:
>>> > OK, different people seem to test different trees. In the hope to get
>>> > everyone on the same page, I created several variants of this patch so
>>> > they can be compared. Whoever's interested, please check out the
>>> > following, and tell me how these compare:
>>
>> I'm in the process of testing these patches. Base and v0 are complete
>> and v1 is near complete with v2 to follow. I'm testing with a variety
>> of TCP_RR and TCP_STREAM/TCP_MAERTS tests involving local guest-to-guest
>> tests and remote host-to-guest tests. I'll post the results in the next
>> day or two when the tests finish.
>>
>> Thanks,
>> Tom
>>
>>> >
>>> > kernel:
>>> >
>>> > git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git
>>> >
>>> > virtio-net-limit-xmit-polling/base - this is net-next baseline to test
>>> > against virtio-net-limit-xmit-polling/v0 - fixes checks on out of capacity
>>> > virtio-net-limit-xmit-polling/v1 - previous revision of the patch
>>> > this does xmit,free,xmit,2*free,free
>>> > virtio-net-limit-xmit-polling/v2 - new revision of the patch
>>> > this does free,xmit,2*free,free
>>> >
>>> > There's also this on top:
>>> > virtio-net-limit-xmit-polling/v3 -> don't delay avail index update
>>> > I don't think it's important to test this one, yet
>>> >
>>> > Userspace to use: event index work is not yet merged upstream
>>> > so the revision to use is still this:
>>> > git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu-kvm.git
>>> > virtio-net-event-idx-v3
>>
>
>
> _______________________________________________
> Virtualization mailing list
> Virtualization@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/virtualization
[-- Attachment #1.2: Type: text/html, Size: 4335 bytes --]
[-- Attachment #2: Type: text/plain, Size: 184 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC 59/72] r6040: Move the RDC driver
From: Florian Fainelli @ 2011-06-25 18:59 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, Sten Wang, Daniel Gimpelevich
In-Reply-To: <1309010363-22750-60-git-send-email-jeffrey.t.kirsher@intel.com>
Hello Jeff,
On Saturday 25 June 2011 15:59:10 Jeff Kirsher wrote:
> Move the RDC driver into drivers/net/ethernet/ and make the
> necessary Kconfig and Makefile changes.
>
> CC: Sten Wang <sten.wang@rdc.com.tw>
> CC: Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>
> CC: Florian Fainelli <florian@openwrt.org>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> MAINTAINERS | 2 +-
> drivers/net/Kconfig | 13 -------------
> drivers/net/Makefile | 1 -
> drivers/net/ethernet/Kconfig | 14 ++++++++++++++
> drivers/net/ethernet/Makefile | 1 +
> drivers/net/{ => ethernet}/r6040.c | 0
> 6 files changed, 16 insertions(+), 15 deletions(-)
> rename drivers/net/{ => ethernet}/r6040.c (100%)
Why not move this to drivers/net/ethernet/rdc/r6040.c?
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9ddb715..f1f555d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5258,7 +5258,7 @@ RDC R6040 FAST ETHERNET DRIVER
> M: Florian Fainelli <florian@openwrt.org>
> L: netdev@vger.kernel.org
> S: Maintained
> -F: drivers/net/r6040.c
> +F: drivers/net/ethernet/r6040.c
>
> RDS - RELIABLE DATAGRAM SOCKETS
> M: Andy Grover <andy.grover@oracle.com>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 82da415..463e4cf 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -404,19 +404,6 @@ config FEALNX
> Say Y here to support the Myson MTD-800 family of PCI-based Ethernet
> cards. <http://www.myson.com.tw/>
>
> -config R6040
> - tristate "RDC R6040 Fast Ethernet Adapter support"
> - depends on NET_PCI && PCI
> - select CRC32
> - select MII
> - select PHYLIB
> - help
> - This is a driver for the R6040 Fast Ethernet MACs found in the
> - the RDC R-321x System-on-chips.
> -
> - To compile this driver as a module, choose M here: the module
> - will be called r6040. This is recommended.
> -
> config NET_POCKET
> bool "Pocket and portable adapters"
> depends on PARPORT
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index b7e875a..f57a0be 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -16,7 +16,6 @@ obj-$(CONFIG_PLIP) += plip.o
>
> obj-$(CONFIG_ROADRUNNER) += rrunner.o
>
> -obj-$(CONFIG_R6040) += r6040.o
> obj-$(CONFIG_ISERIES_VETH) += iseries_veth.o
> obj-$(CONFIG_FEALNX) += fealnx.o
> obj-$(CONFIG_SKFP) += skfp/
> diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
> index f5eb70e..3c10879 100644
> --- a/drivers/net/ethernet/Kconfig
> +++ b/drivers/net/ethernet/Kconfig
> @@ -98,6 +98,20 @@ config PASEMI_MAC
> source "drivers/net/ethernet/qlogic/Kconfig"
> source "drivers/net/ethernet/racal/Kconfig"
> source "drivers/net/ethernet/radisys/Kconfig"
> +
> +config R6040
> + tristate "RDC R6040 Fast Ethernet Adapter support"
> + depends on PCI
> + select CRC32
> + select MII
> + select PHYLIB
> + ---help---
> + This is a driver for the R6040 Fast Ethernet MACs found in the
> + the RDC R-321x System-on-chips.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called r6040. This is recommended.
> +
> source "drivers/net/ethernet/realtek/Kconfig"
>
> config S6GMAC
> diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
> index 2ccb194..537631b 100644
> --- a/drivers/net/ethernet/Makefile
> +++ b/drivers/net/ethernet/Makefile
> @@ -41,6 +41,7 @@ obj-$(CONFIG_PASEMI_MAC) += pasemi_mac.o
> pasemi_mac_ethtool.o obj-$(CONFIG_NET_VENDOR_QLOGIC) += qlogic/
> obj-$(CONFIG_NET_VENDOR_RACAL) += racal/
> obj-$(CONFIG_NET_VENDOR_RADISYS) += radisys/
> +obj-$(CONFIG_R6040) += r6040.o
> obj-$(CONFIG_NET_VENDOR_REALTEK) += realtek/
> obj-$(CONFIG_S6GMAC) += s6gmac.o
> obj-$(CONFIG_NET_VENDOR_SIS) += sis/
> diff --git a/drivers/net/r6040.c b/drivers/net/ethernet/r6040.c
> similarity index 100%
> rename from drivers/net/r6040.c
> rename to drivers/net/ethernet/r6040.c
--
Florian
^ permalink raw reply
* Re: [RFC 26/72] arm: Move the ARM/ACORN drivers
From: Arnd Bergmann @ 2011-06-25 18:22 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: Russell King - ARM Linux, davem@davemloft.net,
netdev@vger.kernel.org, Sriram, Vinay Hegde, Cyril Chemparathy,
Wan ZongShun, Lennert Buytenhek, Krzysztof Halasa, Anant Gole,
Chaithrika U S
In-Reply-To: <1309025217.2454.89.camel@jtkirshe-mobl>
On Saturday 25 June 2011, Jeff Kirsher wrote:
> On Sat, 2011-06-25 at 09:59 -0700, Arnd Bergmann wrote:
> > > More interestingly, if you have one of the 8390 clones, which
> > directory
> > > do you look in? And shouldn't etherh.c live along side 8390's files
> > > as etherh is 8390-derived?
> >
> > Jeff created a drivers/net/ethernet/8390/ directory for all of those,
> > which sounds sensible to me, but apparently he missed some of the
> > nonobvious ones.
>
> I was trying to keep the drivers that use the 8390 common files grouped
> together.
>
> I know that there are other instances like this (for instance drivers
> derived from the lance.c driver) yet these derived drivers do not use
> the common files that other lance drivers use. Because they are
> derived, yet do not use the common code, should they still be grouped
> together? Just a question, I am fine with the idea.
Generally, I'd say yes, but it's not a strong preference.
In other subsystems, we group similar stuff together like that as well,
as a reminder that it should better use the common infrastructure, so
that someone copying the odd implementation has a better chance of
noticing the mistake early.
Arnd
^ permalink raw reply
* Re: [RFC 30/72] atl*: Move the Atheros drivers
From: Chris Snook @ 2011-06-25 18:16 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, Jay Cliburn
In-Reply-To: <1309010363-22750-31-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, Jun 25, 2011 at 9:58 AM, Jeff Kirsher
<jeffrey.t.kirsher@intel.com> wrote:
> Move the Atheros drivers into drivers/net/ethernet/atheros/ and
> make the necessary Kconfig and Makefile changes.
>
> CC: Jay Cliburn <jcliburn@gmail.com>
> CC: Chris Snook <chris.snook@gmail.com>
> CC: Jie Yang <jie.yang@atheros.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
I'm fine with this as long as the other ethernet maintainers are fine
with the whole series. I don't want to be making changes like this
unless it's to a new standard that's applied consistently.
-- Chris
^ permalink raw reply
* Re: [RFC 54/72] au1000_eth/mipsnet/tc35815: Move the MIPS drivers
From: Jeff Kirsher @ 2011-06-25 18:11 UTC (permalink / raw)
To: Ralf Baechle
Cc: davem@davemloft.net, netdev@vger.kernel.org, Matt Porter,
Herbert Valerio Riedel, MontaVista Software, Kyle McMartin,
Helge Deller, James E.J. Bottomley, linux-parisc@vger.kernel.org,
Sam Creasey, Geert Uytterhoeven, linux-m68k@vger.kernel.org
In-Reply-To: <20110625161353.GA20976@linux-mips.org>
[-- Attachment #1: Type: text/plain, Size: 869 bytes --]
On Sat, 2011-06-25 at 09:13 -0700, Ralf Baechle wrote:
> On Sat, Jun 25, 2011 at 06:59:05AM -0700, Jeff Kirsher wrote:
>
> > Move the MIPS drivers into drivers/net/ethernet/mips/ and
> > make the necessary Kconfig and Makefile changes.
>
> NAck.
>
> sni_82596.c is a driver for the same chip but used in particular
> Siemens-
> Nixdorf systems. Lasi_82596 is an Intel NIC being used in PARISC
> systems.
> Not a good reason th throw PA-RISC drivers into the same directory
> after
> all PA-RISC has no relation to MIPS at all. So maybe they should go
> into
> drivers/net/ethernet/i82596 or drivers/net/ethernet/intel. And
> wherever
> they go, both drivers #include lib82596.c which your patch did not
> move
> around.
My bad, I had grouped these drivers because they both used lib82596.c
and had thought I had moved that file as well.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [RFC 26/72] arm: Move the ARM/ACORN drivers
From: Jeff Kirsher @ 2011-06-25 18:06 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Russell King - ARM Linux, davem@davemloft.net,
netdev@vger.kernel.org, Sriram, Vinay Hegde, Cyril Chemparathy,
Wan ZongShun, Lennert Buytenhek, Krzysztof Halasa, Anant Gole,
Chaithrika U S
In-Reply-To: <201106251859.38963.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 831 bytes --]
On Sat, 2011-06-25 at 09:59 -0700, Arnd Bergmann wrote:
> > More interestingly, if you have one of the 8390 clones, which
> directory
> > do you look in? And shouldn't etherh.c live along side 8390's files
> > as etherh is 8390-derived?
>
> Jeff created a drivers/net/ethernet/8390/ directory for all of those,
> which sounds sensible to me, but apparently he missed some of the
> nonobvious ones.
I was trying to keep the drivers that use the 8390 common files grouped
together.
I know that there are other instances like this (for instance drivers
derived from the lance.c driver) yet these derived drivers do not use
the common files that other lance drivers use. Because they are
derived, yet do not use the common code, should they still be grouped
together? Just a question, I am fine with the idea.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [RFC 26/72] arm: Move the ARM/ACORN drivers
From: Jeff Kirsher @ 2011-06-25 18:02 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Russell King - ARM Linux, davem@davemloft.net,
netdev@vger.kernel.org, Sriram, Vinay Hegde, Cyril Chemparathy,
Wan ZongShun, Lennert Buytenhek, Krzysztof Halasa, Anant Gole,
Chaithrika U S
In-Reply-To: <201106251859.38963.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]
On Sat, 2011-06-25 at 09:59 -0700, Arnd Bergmann wrote:
>
> > ether1 is 82586, so presumably that should be Intel subdirectory.
>
> Yes, according to the new layout, it should at least live together
> with the other 82586-based drivers (eexpress.c, ni52.c, sun3_82586.c),
> which could be either a directory for all of these, or the
> generic intel directory.
My personal preference is that these drivers that were not created by
Intel or maintained by Intel, not be in the Intel sub-directory.
While many of the drivers were organized in a layout that matches
drivers/net/ethernet/<company>, I tried to organize the drivers in the
most logical way possible (i.e. 8390/ all the drivers that used the 8390
shared files).
I do like all the suggestions made, except for the suggestion to move
eexpress.c, eepro.c, sun3_82596.c, etc. in to the intel sub-directory.
I am open to suggestions on a way to better to organize these drivers
that use an Intel part but were created and maintained by someone else.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH] NET: AX88796: Tighten up Kconfig dependencies
From: Ralf Baechle @ 2011-06-25 18:00 UTC (permalink / raw)
To: David S. Miller, Eric Miao, Russell King, Ben Dooks, Paul Mundt,
J
Cc: netdev, linux-mips, linux-kernel, linux-arm-kernel, linux-sh
In def47c5095d53814512bb0c62ec02dfdec769db1 the AX88796 driver got
restricted to just be build for ARM and MIPS on the sole merrit that it
was written for some ARM sytems and the driver had the missfortune to
just build on MIPS, so MIPS was throw into the dependency for a good
measure. Later 8687991a734a67f1638782c968f46fff0f94bb1f added SH but
only one in-tree SH system actually has an AX88796.
Tighten up dependencies by using an auxilliary config sysmbol
HAS_NET_AX88796 which is selected only by the platforms that actually
have or may have an AX88796. This also means the driver won't be built
anymore for any MIPS platform.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
---
arch/arm/mach-pxa/Kconfig | 2 ++
arch/arm/mach-s3c2410/Kconfig | 1 +
arch/arm/mach-s3c2440/Kconfig | 1 +
arch/sh/boards/Kconfig | 1 +
drivers/net/Kconfig | 5 ++++-
5 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
index cd19309..37ce06f 100644
--- a/arch/arm/mach-pxa/Kconfig
+++ b/arch/arm/mach-pxa/Kconfig
@@ -247,11 +247,13 @@ config MACH_COLIBRI300
select PXA3xx
select CPU_PXA300
select CPU_PXA310
+ select HAS_NET_AX88796
config MACH_COLIBRI320
bool "Toradex Colibri PXA320"
select PXA3xx
select CPU_PXA320
+ select HAS_NET_AX88796
config MACH_COLIBRI_EVALBOARD
bool "Toradex Colibri Evaluation Carrier Board support"
diff --git a/arch/arm/mach-s3c2410/Kconfig b/arch/arm/mach-s3c2410/Kconfig
index 7245a55..d665f92 100644
--- a/arch/arm/mach-s3c2410/Kconfig
+++ b/arch/arm/mach-s3c2410/Kconfig
@@ -122,6 +122,7 @@ config ARCH_BAST
select S3C_DEV_HWMON
select S3C_DEV_USB_HOST
select S3C_DEV_NAND
+ select HAS_NET_AX88796
help
Say Y here if you are using the Simtec Electronics EB2410ITX
development board (also known as BAST)
diff --git a/arch/arm/mach-s3c2440/Kconfig b/arch/arm/mach-s3c2440/Kconfig
index 50825a3..7ddbd22 100644
--- a/arch/arm/mach-s3c2440/Kconfig
+++ b/arch/arm/mach-s3c2440/Kconfig
@@ -86,6 +86,7 @@ config MACH_ANUBIS
select S3C24XX_GPIO_EXTRA64
select S3C2440_XTAL_12000000
select S3C_DEV_USB_HOST
+ select HAS_NET_AX88796
help
Say Y here if you are using the Simtec Electronics ANUBIS
development system
diff --git a/arch/sh/boards/Kconfig b/arch/sh/boards/Kconfig
index d893411..f23f332 100644
--- a/arch/sh/boards/Kconfig
+++ b/arch/sh/boards/Kconfig
@@ -162,6 +162,7 @@ config SH_HIGHLANDER
depends on CPU_SUBTYPE_SH7780 || CPU_SUBTYPE_SH7785
select SYS_SUPPORTS_PCI
select IO_TRAPPED if MMU
+ select HAS_NET_AX88796
config SH_SH7757LCR
bool "SH7757LCR"
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index be25e92..85d18c4 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -237,13 +237,16 @@ source "drivers/net/arm/Kconfig"
config AX88796
tristate "ASIX AX88796 NE2000 clone support"
- depends on ARM || MIPS || SUPERH
+ depends on HAS_NET_AX88796
select PHYLIB
select MDIO_BITBANG
help
AX88796 driver, using platform bus to provide
chip detection and resources
+config HAS_NET_AX88796
+ bool
+
config AX88796_93CX6
bool "ASIX AX88796 external 93CX6 eeprom support"
depends on AX88796
^ permalink raw reply related
* RE: [RFC 24/72] *sonic/natsemi/ns83829: Move the National Semi-conductor drivers
From: Marc Gauthier @ 2011-06-25 17:21 UTC (permalink / raw)
To: Jeff Kirsher, davem@davemloft.net
Cc: netdev@vger.kernel.org, Thomas Bogendoerfer, Harald Welte,
Tim Hockin, linux-ns83820@kvack.org, Kevin Chea, Marc Gauthier,
Chris Zankel
In-Reply-To: <1309010363-22750-25-git-send-email-jeffrey.t.kirsher@intel.com>
Jeff Kirsher wrote:
> Move the National Semi-conductor drivers into
> drivers/net/ethernet/natsemi/
> and make the necessary Kconfig and Makefile changes. Also
> moved the 8390
> (National Semi-conductor) devices as a sub-menu of National
> Semi-conductor devices.
>
> CC: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> CC: Harald Welte <laforge@gnumonks.org>
> CC: Tim Hockin <thockin@hockin.org>
> CC: <linux-ns83820@kvack.org>
> CC: Kevin Chea <kchea@yahoo.com>
> CC: Marc Gauthier <marc@linux-xtensa.org>
> CC: Chris Zankel <chris@zankel.net>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> ---
Acked-by: Marc Gauthier <marc@tensilica.com>
-Marc
> MAINTAINERS | 4 +-
> drivers/net/Kconfig | 47
> ------------------ drivers/net/Makefile |
> 6 -- drivers/net/ethernet/8390/Kconfig | 7 ++-
> drivers/net/ethernet/Kconfig | 3 +-
> drivers/net/ethernet/Makefile | 1 +
> drivers/net/ethernet/natsemi/Kconfig | 63
> ++++++++++++++++++++++++ drivers/net/ethernet/natsemi/Makefile
> | 9 +++ drivers/net/{ => ethernet/natsemi}/jazzsonic.c | 0
> drivers/net/{ => ethernet/natsemi}/macsonic.c | 0
> drivers/net/{ => ethernet/natsemi}/natsemi.c | 0
> drivers/net/{ => ethernet/natsemi}/ns83820.c | 0
> drivers/net/{ => ethernet/natsemi}/sonic.c | 0
> drivers/net/{ => ethernet/natsemi}/sonic.h | 0
> drivers/net/{ => ethernet/natsemi}/xtsonic.c | 0
> 15 files changed, 81 insertions(+), 59 deletions(-)
> create mode 100644 drivers/net/ethernet/natsemi/Kconfig
> create mode 100644 drivers/net/ethernet/natsemi/Makefile
> rename drivers/net/{ => ethernet/natsemi}/jazzsonic.c (100%)
> rename drivers/net/{ => ethernet/natsemi}/macsonic.c (100%)
> rename drivers/net/{ => ethernet/natsemi}/natsemi.c (100%)
> rename drivers/net/{ => ethernet/natsemi}/ns83820.c (100%)
> rename drivers/net/{ => ethernet/natsemi}/sonic.c (100%)
> rename drivers/net/{ => ethernet/natsemi}/sonic.h (100%)
> rename drivers/net/{ => ethernet/natsemi}/xtsonic.c (100%)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 6f822c6..76e60e4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4281,7 +4281,7 @@ F: drivers/net/ethernet/myricom/myri10ge/
> NATSEMI ETHERNET DRIVER (DP8381x)
> M: Tim Hockin <thockin@hockin.org>
> S: Maintained
> -F: drivers/net/natsemi.c
> +F: drivers/net/ethernet/natsemi/natsemi.c
>
> NATIVE INSTRUMENTS USB SOUND INTERFACE DRIVER
> M: Daniel Mack <zonque@gmail.com>
> @@ -5852,7 +5852,7 @@ SONIC NETWORK DRIVER
> M: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> L: netdev@vger.kernel.org S: Maintained
> -F: drivers/net/sonic.*
> +F: drivers/net/ethernet/natsemi/sonic.*
>
> SONICS SILICON BACKPLANE DRIVER (SSB)
> M: Michael Buesch <mb@bu3sch.de>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 56c963a..305b8b9 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -258,19 +258,6 @@ config A2065
> To compile this driver as a module, choose M here: the module
> will be called a2065.
>
> -config MACSONIC
> - tristate "Macintosh SONIC based ethernet (onboard,
> NuBus, LC, CS)"
> - depends on MAC
> - ---help---
> - Support for NatSemi SONIC based Ethernet devices.
> This includes
> - the onboard Ethernet in many Quadras as well as some LC-PDS,
> - a few Nubus and all known Comm Slot Ethernet cards.
> If you have
> - one of these say Y and read the Ethernet-HOWTO, available from
> - <http://www.tldp.org/docs.html#howto>.
> -
> - To compile this driver as a module, choose M here.
> This module will
> - be called macsonic.
> -
> config MVME16x_NET
> tristate "MVME16x Ethernet support"
> depends on MVME16x
> @@ -310,19 +297,6 @@ config KORINA
> If you have a Mikrotik RouterBoard 500 or IDT RC32434
> based system say Y. Otherwise say N.
>
> -config MIPS_JAZZ_SONIC
> - tristate "MIPS JAZZ onboard SONIC Ethernet support"
> - depends on MACH_JAZZ
> - help
> - This is the driver for the onboard card of MIPS Magnum 4000,
> - Acer PICA, Olivetti M700-10 and a few other identical
> OEM systems.
> -
> -config XTENSA_XT2000_SONIC
> - tristate "Xtensa XT2000 onboard SONIC Ethernet support"
> - depends on XTENSA_PLATFORM_XT2000
> - help
> - This is the driver for the onboard card of the Xtensa
> XT2000 board.
> -
> config MIPS_AU1X00_ENET
> tristate "MIPS AU1000 Ethernet support"
> depends on MIPS_ALCHEMY
> @@ -789,17 +763,6 @@ config FEALNX
> Say Y here to support the Myson MTD-800 family of
> PCI-based Ethernet
> cards. <http://www.myson.com.tw/>
>
> -config NATSEMI
> - tristate "National Semiconductor DP8381x series PCI
> Ethernet support"
> - depends on NET_PCI && PCI
> - select CRC32
> - help
> - This driver is for the National Semiconductor DP83810 series,
> - which is used in cards from PureData, NetGear, Linksys
> - and others, including the 83815 chip.
> - More specific information and updates are available from
> - <http://www.scyld.com/network/natsemi.html>.
> -
> config 8139CP
> tristate "RealTek RTL-8139 C+ PCI Fast Ethernet Adapter
> support (EXPERIMENTAL)"
> depends on NET_PCI && PCI && EXPERIMENTAL
> @@ -1220,16 +1183,6 @@ config IP1000
>
> source "drivers/net/ixp2000/Kconfig"
>
> -config NS83820
> - tristate "National Semiconductor DP83820 support"
> - depends on PCI
> - help
> - This is a driver for the National Semiconductor DP83820 series
> - of gigabit ethernet MACs. Cards using this chipset include
> - the D-Link DGE-500T, PureData's PDP8023Z-TG, SMC's SMC9462TX,
> - SOHO-GA2000T, SOHO-GA2500T. The driver supports the use of
> - zero copy.
> -
> config HAMACHI
> tristate "Packet Engines Hamachi GNIC-II support" depends on PCI
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index 9ac99cd..04d7613 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -45,8 +45,6 @@ obj-$(CONFIG_SIS900) += sis900.o
> obj-$(CONFIG_R6040) += r6040.o
> obj-$(CONFIG_YELLOWFIN) += yellowfin.o
> obj-$(CONFIG_ISERIES_VETH) += iseries_veth.o
> -obj-$(CONFIG_NATSEMI) += natsemi.o
> -obj-$(CONFIG_NS83820) += ns83820.o
> obj-$(CONFIG_FEALNX) += fealnx.o
> spidernet-y += spider_net.o spider_net_ethtool.o
> obj-$(CONFIG_SPIDER_NET) += spidernet.o ethernet/sun/sungem_phy.o
> @@ -141,13 +139,11 @@ obj-$(CONFIG_LP486E) += lp486e.o
> obj-$(CONFIG_ETH16I) += eth16i.o
> obj-$(CONFIG_EQUALIZER) += eql.o
> obj-$(CONFIG_KORINA) += korina.o
> -obj-$(CONFIG_MIPS_JAZZ_SONIC) += jazzsonic.o
> obj-$(CONFIG_MIPS_AU1X00_ENET) += au1000_eth.o
> obj-$(CONFIG_MIPS_SIM_NET) += mipsnet.o
> obj-$(CONFIG_SGI_IOC3_ETH) += ioc3-eth.o
> obj-$(CONFIG_A2065) += a2065.o
> obj-$(CONFIG_ARIADNE) += ariadne.o
> -obj-$(CONFIG_MACSONIC) += macsonic.o
> obj-$(CONFIG_TUN) += tun.o
> obj-$(CONFIG_VETH) += veth.o
> obj-$(CONFIG_NET_NETX) += netx-eth.o
> @@ -163,8 +159,6 @@ obj-$(CONFIG_ETHOC) += ethoc.o
> obj-$(CONFIG_GRETH) += greth.o
> obj-$(CONFIG_LANTIQ_ETOP) += lantiq_etop.o
>
> -obj-$(CONFIG_XTENSA_XT2000_SONIC) += xtsonic.o
> -
> obj-$(CONFIG_DNET) += dnet.o
> obj-$(CONFIG_MACB) += macb.o
> obj-$(CONFIG_S6GMAC) += s6gmac.o
> diff --git a/drivers/net/ethernet/8390/Kconfig
> b/drivers/net/ethernet/8390/Kconfig
> index db03f52..0d82137 100644
> --- a/drivers/net/ethernet/8390/Kconfig
> +++ b/drivers/net/ethernet/8390/Kconfig
> @@ -4,9 +4,10 @@
>
> config NET_VENDOR_8390
> bool "National Semi-conductor 8390 devices"
> - depends on AMIGA_PCMCIA || PCI || SUPERH || ISA || MCA
>>> EISA || \
> - MAC || M32R || MACH_TX49XX || MCA_LEGACY ||
> H8300 || \
> - ARM || MIPS || ZORRO || PCMCIA || EXPERIMENTAL
> + depends on NET_VENDOR_NATSEMI && (AMIGA_PCMCIA || PCI
>>> SUPERH || \
> + ISA || MCA || EISA || MAC || M32R || MACH_TX49XX || \
> + MCA_LEGACY || H8300 || ARM || MIPS || ZORRO
>>> PCMCIA || \
> + EXPERIMENTAL)
> ---help---
> If you have a network (Ethernet) card belonging to
> this class, say Y
> and read the Ethernet-HOWTO, available from
> diff --git a/drivers/net/ethernet/Kconfig
> b/drivers/net/ethernet/Kconfig
> index 28b473b..704e664 100644
> --- a/drivers/net/ethernet/Kconfig
> +++ b/drivers/net/ethernet/Kconfig
> @@ -12,7 +12,6 @@ menuconfig ETHERNET
> if ETHERNET
>
> source "drivers/net/ethernet/3com/Kconfig"
> -source "drivers/net/ethernet/8390/Kconfig"
> source "drivers/net/ethernet/amd/Kconfig"
> source "drivers/net/ethernet/apple/Kconfig"
> source "drivers/net/ethernet/broadcom/Kconfig"
> @@ -25,6 +24,8 @@ source "drivers/net/ethernet/ibm/Kconfig"
> source "drivers/net/ethernet/intel/Kconfig"
> source "drivers/net/ethernet/mellanox/Kconfig"
> source "drivers/net/ethernet/myricom/Kconfig"
> +source "drivers/net/ethernet/natsemi/Kconfig"
> +source "drivers/net/ethernet/8390/Kconfig"
>
> config PASEMI_MAC
> tristate "PA Semi 1/10Gbit MAC"
> diff --git a/drivers/net/ethernet/Makefile
> b/drivers/net/ethernet/Makefile
> index 40dded7..e5c02d9 100644
> --- a/drivers/net/ethernet/Makefile
> +++ b/drivers/net/ethernet/Makefile
> @@ -16,6 +16,7 @@ obj-$(CONFIG_NET_VENDOR_IBM) += ibm/
> obj-$(CONFIG_NET_VENDOR_INTEL) += intel/
> obj-$(CONFIG_NET_VENDOR_MELLANOX) += mellanox/
> obj-$(CONFIG_NET_VENDOR_MYRI) += myricom/
> +obj-$(CONFIG_NET_VENDOR_NATSEMI) += natsemi/
> obj-$(CONFIG_PASEMI_MAC) += pasemi_mac.o pasemi_mac_ethtool.o
> obj-$(CONFIG_NET_VENDOR_QLOGIC) += qlogic/
> obj-$(CONFIG_NET_VENDOR_RACAL) += racal/
> diff --git a/drivers/net/ethernet/natsemi/Kconfig
> b/drivers/net/ethernet/natsemi/Kconfig
> new file mode 100644
> index 0000000..dc1852b
> --- /dev/null
> +++ b/drivers/net/ethernet/natsemi/Kconfig
> @@ -0,0 +1,63 @@
> +#
> +# National Semi-conductor device configuration
> +#
> +
> +config NET_VENDOR_NATSEMI
> + bool "National Semi-conductor devices"
> + depends on MAC || MACH_JAZZ || PCI || XTENSA_PLATFORM_XT2000
> + ---help--- + If you have a network (Ethernet) card belonging to
> this class, say Y
> + and read the Ethernet-HOWTO, available from
> + <http://www.tldp.org/docs.html#howto>.
> +
> + Note that the answer to this question doesn't
> directly affect the
> + kernel: saying N will just cause the configurator to skip all
> + the questions about National Semi-conductor devices.
> If you say Y,
> + you will be asked for your specific card in the
> following questions.
> +
> +config MACSONIC
> + tristate "Macintosh SONIC based ethernet (onboard,
> NuBus, LC, CS)"
> + depends on NET_VENDOR_NATSEMI && MAC
> + ---help---
> + Support for NatSemi SONIC based Ethernet devices.
> This includes
> + the onboard Ethernet in many Quadras as well as some LC-PDS,
> + a few Nubus and all known Comm Slot Ethernet cards.
> If you have
> + one of these say Y and read the Ethernet-HOWTO, available from
> + <http://www.tldp.org/docs.html#howto>.
> +
> + To compile this driver as a module, choose M here.
> This module will
> + be called macsonic.
> +
> +config MIPS_JAZZ_SONIC
> + tristate "MIPS JAZZ onboard SONIC Ethernet support"
> + depends on NET_VENDOR_NATSEMI && MACH_JAZZ
> + ---help---
> + This is the driver for the onboard card of MIPS Magnum 4000,
> + Acer PICA, Olivetti M700-10 and a few other identical
> OEM systems.
> +
> +config NATSEMI
> + tristate "National Semiconductor DP8381x series PCI
> Ethernet support"
> + depends on NET_VENDOR_NATSEMI && PCI
> + select CRC32
> + ---help---
> + This driver is for the National Semiconductor DP83810 series,
> + which is used in cards from PureData, NetGear, Linksys
> + and others, including the 83815 chip.
> + More specific information and updates are available from
> + <http://www.scyld.com/network/natsemi.html>.
> +
> +config NS83820
> + tristate "National Semiconductor DP83820 support"
> + depends on NET_VENDOR_NATSEMI && PCI
> + ---help---
> + This is a driver for the National Semiconductor DP83820 series
> + of gigabit ethernet MACs. Cards using this chipset include
> + the D-Link DGE-500T, PureData's PDP8023Z-TG, SMC's SMC9462TX,
> + SOHO-GA2000T, SOHO-GA2500T. The driver supports the use of +
> zero copy. +
> +config XTENSA_XT2000_SONIC
> + tristate "Xtensa XT2000 onboard SONIC Ethernet support"
> + depends on NET_VENDOR_NATSEMI && XTENSA_PLATFORM_XT2000 + ---help---
> + This is the driver for the onboard card of the Xtensa
> XT2000 board.
> diff --git a/drivers/net/ethernet/natsemi/Makefile
> b/drivers/net/ethernet/natsemi/Makefile
> new file mode 100644
> index 0000000..764c532
> --- /dev/null
> +++ b/drivers/net/ethernet/natsemi/Makefile
> @@ -0,0 +1,9 @@
> +#
> +# Makefile for the National Semi-conductor Sonic devices. +#
> +
> +obj-$(CONFIG_MACSONIC) += macsonic.o
> +obj-$(CONFIG_MIPS_JAZZ_SONIC) += jazzsonic.o
> +obj-$(CONFIG_NATSEMI) += natsemi.o
> +obj-$(CONFIG_NS83820) += ns83820.o
> +obj-$(CONFIG_XTENSA_XT2000_SONIC) += xtsonic.o
> diff --git a/drivers/net/jazzsonic.c
> b/drivers/net/ethernet/natsemi/jazzsonic.c
> similarity index 100%
> rename from drivers/net/jazzsonic.c
> rename to drivers/net/ethernet/natsemi/jazzsonic.c
> diff --git a/drivers/net/macsonic.c
> b/drivers/net/ethernet/natsemi/macsonic.c
> similarity index 100%
> rename from drivers/net/macsonic.c
> rename to drivers/net/ethernet/natsemi/macsonic.c
> diff --git a/drivers/net/natsemi.c
> b/drivers/net/ethernet/natsemi/natsemi.c
> similarity index 100%
> rename from drivers/net/natsemi.c
> rename to drivers/net/ethernet/natsemi/natsemi.c
> diff --git a/drivers/net/ns83820.c
> b/drivers/net/ethernet/natsemi/ns83820.c
> similarity index 100%
> rename from drivers/net/ns83820.c
> rename to drivers/net/ethernet/natsemi/ns83820.c
> diff --git a/drivers/net/sonic.c
> b/drivers/net/ethernet/natsemi/sonic.c
> similarity index 100%
> rename from drivers/net/sonic.c
> rename to drivers/net/ethernet/natsemi/sonic.c
> diff --git a/drivers/net/sonic.h
> b/drivers/net/ethernet/natsemi/sonic.h
> similarity index 100%
> rename from drivers/net/sonic.h
> rename to drivers/net/ethernet/natsemi/sonic.h
> diff --git a/drivers/net/xtsonic.c
> b/drivers/net/ethernet/natsemi/xtsonic.c
> similarity index 100%
> rename from drivers/net/xtsonic.c
> rename to drivers/net/ethernet/natsemi/xtsonic.c
^ permalink raw reply
* Re: [RFC 26/72] arm: Move the ARM/ACORN drivers
From: Arnd Bergmann @ 2011-06-25 16:59 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Jeff Kirsher, davem, netdev, Sriram, Vinay Hegde,
Cyril Chemparathy, Wan ZongShun, Lennert Buytenhek,
Krzysztof Halasa, Anant Gole, Chaithrika U S
In-Reply-To: <20110625161227.GJ23234@n2100.arm.linux.org.uk>
On Saturday 25 June 2011, Russell King - ARM Linux wrote:
>
> How do you deal with NE2K or 8390 stuff, where you have a design which
> has been cloned by many different manufacturers? Who's do you decide
> to put it in?
>
> More interestingly, if you have one of the 8390 clones, which directory
> do you look in? And shouldn't etherh.c live along side 8390's files
> as etherh is 8390-derived?
Jeff created a drivers/net/ethernet/8390/ directory for all of those,
which sounds sensible to me, but apparently he missed some of the
nonobvious ones.
> ether1 is 82586, so presumably that should be Intel subdirectory.
Yes, according to the new layout, it should at least live together
with the other 82586-based drivers (eexpress.c, ni52.c, sun3_82586.c),
which could be either a directory for all of these, or the
generic intel directory.
> ether3 is SEEQ8005, so that should be in the SEEQ subdirectory.
Same here, it can be grouped together with sqiseeq.c (SEEQ8003)
and seeq8005.c.
I don't really care about these old ones too much though. Nobody
will spend the effort to clean up and merge these ancient drivers
any more, and it's also very unlikely that we want to add support
for new boards with these. For the soc vendor specific ones,
I think we should decide on the new location based on how easy it
is to spot duplicates, e.g. to avoid adding an AVR32 copy of the
at91 ethernet driver.
For reference (since you probably didn't see the full 72 patch
series on netdev), some of the related driver moves suggested
by Jeff are:
drivers/net/{ => ethernet/8390}/*8390*.c | 0
drivers/net/{ => ethernet/amd}/*lance.c | 0
drivers/net/{ => ethernet/atmel}/macb.c | 0
drivers/net/{ => ethernet/micrel}/ks8842.c | 0
drivers/net/{ => ethernet/micrel}/ks8851.c | 0
drivers/net/{ => ethernet/ti}/cpmac.c | 0
drivers/net/{ => ethernet/ti}/tlan.c | 0
drivers/net/{ => ethernet/isa}/eexpress.c | 0
drivers/net/{ => ethernet/sun}/sun3_82586.c | 0
drivers/net/{ => ethernet/isa}/seeq8005.c | 0
drivers/net/{ => ethernet/sgi}/sgiseeq.c | 0
Arnd
^ permalink raw reply
* [PATCH] NET: TC35815: Only build driver on Toshiba eval boards.
From: Ralf Baechle @ 2011-06-25 16:54 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-mips, Atsushi Nemoto
That's the only place where the TC35815 is known to be used.
Ralf
drivers/net/Kconfig | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index be25e92..2b4ebfb 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1516,7 +1516,8 @@ config CS89x0_NONISA_IRQ
config TC35815
tristate "TOSHIBA TC35815 Ethernet support"
- depends on NET_PCI && PCI && MIPS
+ depends on NET_PCI && PCI && MACH_TXX9
+ default y
select PHYLIB
config E100
^ permalink raw reply related
* Re: [RFC 42/72] 82586.c/fec*: Move the Motorola drivers
From: Arnd Bergmann @ 2011-06-25 16:53 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, Dan Malek, Sylvain Munaut, Richard Hirst
In-Reply-To: <1309010363-22750-43-git-send-email-jeffrey.t.kirsher@intel.com>
On Saturday 25 June 2011, Jeff Kirsher wrote:
> Move the Motorola drivers into drivers/net/ethernet/motorola/ and
> make the necessary Kconfig and Makefile changes
>
> CC: Dan Malek <dmalek@jlc.net>
> CC: Sylvain Munaut <tnt@246tNt.com>
> CC: Richard Hirst <richard@sleepie.demon.co.uk>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> drivers/net/Kconfig | 69 ---------------
> drivers/net/Makefile | 9 --
> drivers/net/ethernet/Kconfig | 1 +
> drivers/net/ethernet/Makefile | 1 +
> drivers/net/{ => ethernet/motorola}/82596.c | 0
> drivers/net/ethernet/motorola/Kconfig | 88 ++++++++++++++++++++
> drivers/net/ethernet/motorola/Makefile | 13 +++
> drivers/net/{ => ethernet/motorola}/fec.c | 0
> drivers/net/{ => ethernet/motorola}/fec.h | 0
> drivers/net/{ => ethernet/motorola}/fec_mpc52xx.c | 0
> drivers/net/{ => ethernet/motorola}/fec_mpc52xx.h | 0
> .../net/{ => ethernet/motorola}/fec_mpc52xx_phy.c | 0
> 12 files changed, 103 insertions(+), 78 deletions(-)
The part of Motorola that made these originally is now known as
Freescale, so put these together with the other freescale parts.
Arnd
^ permalink raw reply
* Re: [AX25] inconsistent lock state
From: Ralf Baechle DL5RB @ 2011-06-25 16:39 UTC (permalink / raw)
To: f6bvp; +Cc: Arnd Bergmann, linux-kernel, Linux Netdev List, linux-hams
In-Reply-To: <4E06040B.7040309@free.fr>
On Sat, Jun 25, 2011 at 05:51:39PM +0200, f6bvp wrote:
> I applied the patch and since then I could not reproduce the
> inconsistent lock state.
> Thus mkiss patch fixed it.
I also think the patch is the right thing, so
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Ralf
^ permalink raw reply
* Re: [RFC 34/72] skge/sky2: Move the SysKonnect Ethernet drivers
From: Stephen Hemminger @ 2011-06-25 16:26 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Jeff Kirsher, davem, netdev
In-Reply-To: <201106251649.13877.arnd@arndb.de>
On Sat, 25 Jun 2011 16:49:13 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> On Saturday 25 June 2011, Jeff Kirsher wrote:
> > Move the SysKonnect Ethernet drivers into drivers/net/ethernet/syskonnect/
> > and make the necessary Kconfig and Makefile changes.
> >
> > CC: Stephen Hemminger <shemminger@linux-foundation.org>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > ---
> > MAINTAINERS | 3 +-
> > drivers/net/Kconfig | 58 --------------------
> > drivers/net/Makefile | 2 -
> > drivers/net/ethernet/Kconfig | 1 +
> > drivers/net/ethernet/Makefile | 1 +
> > drivers/net/ethernet/syskonnect/Kconfig | 74 ++++++++++++++++++++++++++
> > drivers/net/ethernet/syskonnect/Makefile | 6 ++
> > drivers/net/{ => ethernet/syskonnect}/skge.c | 0
> > drivers/net/{ => ethernet/syskonnect}/skge.h | 0
> > drivers/net/{ => ethernet/syskonnect}/sky2.c | 0
> > drivers/net/{ => ethernet/syskonnect}/sky2.h | 0
>
> Shouldn't these live together with the other Marvell drivers?
yes put them under Marvell.
^ permalink raw reply
* Re: [RFC 52/72] ps3_gelic*: Move the Sony (PS3) drivers
From: Geoff Levand @ 2011-06-25 16:25 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev
In-Reply-To: <1309010363-22750-53-git-send-email-jeffrey.t.kirsher@intel.com>
Hi Jeff,
On 06/25/2011 06:59 AM, Jeff Kirsher wrote:
> Move the Sony drivers into drivers/net/ethernet/sony/ and
> make the necessary Kconfig and Makefile changes.
This looks OK, but as Arnd mentioned, it makes sense to put these
with the toshiba spider_net drivers.
> TODO: separate the wired and wireless drivers and relocate the wireless
> dirver into drivers/net/wireless/
I'm not sure if it makes sense to split this into separate drivers.
The PS3 doesn't have separate wireless and Ethernet devices. The wireless
hardware is hooked up to the gelic Ethernet controller, and VLAN tags are
used to route the packets. The wireless support is more or less
an extension of the base gelic device.
A little more info on it is here:
http://www.kernel.org/pub/linux/kernel/people/geoff/cell/ps3-linux-docs/ps3-linux-docs-latest/LinuxKernelOverview.html
Let me know what you think.
-Geoff
^ permalink raw reply
* Re: [RFC 54/72] au1000_eth/mipsnet/tc35815: Move the MIPS drivers
From: Ralf Baechle @ 2011-06-25 16:13 UTC (permalink / raw)
To: Jeff Kirsher
Cc: davem, netdev, Matt Porter, Herbert Valerio Riedel,
MontaVista Software, Kyle McMartin, Helge Deller,
James E.J. Bottomley, linux-parisc, Sam Creasey,
Geert Uytterhoeven, linux-m68k
In-Reply-To: <1309010363-22750-55-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, Jun 25, 2011 at 06:59:05AM -0700, Jeff Kirsher wrote:
> Move the MIPS drivers into drivers/net/ethernet/mips/ and
> make the necessary Kconfig and Makefile changes.
NAck.
sni_82596.c is a driver for the same chip but used in particular Siemens-
Nixdorf systems. Lasi_82596 is an Intel NIC being used in PARISC systems.
Not a good reason th throw PA-RISC drivers into the same directory after
all PA-RISC has no relation to MIPS at all. So maybe they should go into
drivers/net/ethernet/i82596 or drivers/net/ethernet/intel. And wherever
they go, both drivers #include lib82596.c which your patch did not move
around.
It seems that lp486e should probably go into the same directory and I
suspect ni52 and sun3_82586 are close enough that they should also in
the faint hope that somebody will factor out the common code.
MIPSnet is a driver for the emulated network card of MIPSsim, a software
simulator by MIPS Technologies and the only net thingy in your patch that
truely is "MIPS".
The remaining happen to be used by particular systems that happen to be
based on a MIPS processor but there is no technial communality. MIPS is
a processor architecture - not a system architecture and grouping things
by processor architecture hasn't worked so well imho for other things in
the past, see for example sound.
If we're already moving things around maybe au1000_net.[ch] can be renamed
to alchemy.[ch].
Your patch moves the Makefile and Kconfig bits of lantiq_etop but doesn't
move the actual lantiq_etop.c driver.
> +++ b/drivers/net/ethernet/mips/Kconfig
> @@ -0,0 +1,61 @@
> +#
> +# MIPS device configuration
> +#
> +
> +config NET_MIPS
> + bool "MIPS/PS-RISC devices"
It's speeled PA-RISC.
Ralf
^ permalink raw reply
* Re: [RFC 26/72] arm: Move the ARM/ACORN drivers
From: Russell King - ARM Linux @ 2011-06-25 16:12 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jeff Kirsher, davem, netdev, Sriram, Vinay Hegde,
Cyril Chemparathy, Wan ZongShun, Lennert Buytenhek,
Krzysztof Halasa, Anant Gole, Chaithrika U S
In-Reply-To: <201106251803.53416.arnd@arndb.de>
On Sat, Jun 25, 2011 at 06:03:53PM +0200, Arnd Bergmann wrote:
> On Saturday 25 June 2011, Russell King - ARM Linux wrote:
> > On Sat, Jun 25, 2011 at 04:48:03PM +0200, Arnd Bergmann wrote:
> > > On Saturday 25 June 2011, Jeff Kirsher wrote:
> > > > Move the ARM/ACORN drivers into drivers/net/ethernet/arm/ and make the
> > > > necessary Kconfig and Makefile changes.
> > > > There were 4 drivers (TI Davinci & ftmac100) not in the
> > > > drivers/net/arm/ which should have been since they are only supported
> > > > under ARM, so they were added to the new directory structure.
> > > >
> > > > NOTE: There are no "maintainers" for the TI Davinci drivers, so I am
> > > > CC'ing the last 3 major contributors from TI.
> > >
> > > It doesn't seem logical to group drivers that are used on ARM under
> > > the architecture when the hardware is not actually made by ARM Ltd.
> >
> > ARM doesn't make any silicon hardware itself, so by that argument it
> > shouldn't be in a directory called 'arm' at all.
> >
> > However, what the 'arm' in drivers/net/arm is referring to is that
> > the drivers are solely used with stuff associated with arch/arm, not
> > that there's any connection with ARM Ltd.
>
> Yes, I understand that about the current state, but Jeff's series
> of patches moves all network drivers around to directories based on
> manufacturer, so it's going to be less logical after all the other
> drivers are moved, especially when he already creates drivers
> for AMD, TI, atmel, cirrus and micrel.
How do you deal with NE2K or 8390 stuff, where you have a design which
has been cloned by many different manufacturers? Who's do you decide
to put it in?
More interestingly, if you have one of the 8390 clones, which directory
do you look in? And shouldn't etherh.c live along side 8390's files
as etherh is 8390-derived?
ether1 is 82586, so presumably that should be Intel subdirectory.
ether3 is SEEQ8005, so that should be in the SEEQ subdirectory.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox