netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* ax88796: add superh to kconfig dependencies
@ 2007-11-08  7:31 Magnus Damm
  2007-11-08  8:12 ` Paul Mundt
                   ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Magnus Damm @ 2007-11-08  7:31 UTC (permalink / raw)
  To: netdev; +Cc: Magnus Damm, lethal, ben-linux, akpm, jeff

ax88796: add superh to kconfig dependencies

This patch adds sh architecture support to the ax88796 kconfig.

Signed-off-by: Magnus Damm <damm@igel.co.jp>
---

 This patch was posted about a month ago but never picked up:
 http://www.mail-archive.com/netdev@vger.kernel.org/msg50018.html
 The rest of the sh support is already included in rc1. Please apply.

 drivers/net/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- 0002/drivers/net/Kconfig
+++ work/drivers/net/Kconfig	2007-10-09 19:37:27.000000000 +0900
@@ -218,7 +218,7 @@ source "drivers/net/arm/Kconfig"
 
 config AX88796
 	tristate "ASIX AX88796 NE2000 clone support"
-	depends on ARM || MIPS
+	depends on ARM || MIPS || SUPERH
 	select CRC32
 	select MII
 	help

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: ax88796: add superh to kconfig dependencies
  2007-11-08  7:31 ax88796: add superh to kconfig dependencies Magnus Damm
@ 2007-11-08  8:12 ` Paul Mundt
  2007-11-08  8:18 ` [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies) Al Viro
  2007-11-08 17:47 ` ax88796: add superh to kconfig dependencies Jeff Garzik
  2 siblings, 0 replies; 11+ messages in thread
From: Paul Mundt @ 2007-11-08  8:12 UTC (permalink / raw)
  To: Magnus Damm; +Cc: netdev, ben-linux, akpm, jeff

On Thu, Nov 08, 2007 at 04:31:05PM +0900, Magnus Damm wrote:
> ax88796: add superh to kconfig dependencies
> 
> This patch adds sh architecture support to the ax88796 kconfig.
> 
> Signed-off-by: Magnus Damm <damm@igel.co.jp>
> ---
> 
>  This patch was posted about a month ago but never picked up:
>  http://www.mail-archive.com/netdev@vger.kernel.org/msg50018.html
>  The rest of the sh support is already included in rc1. Please apply.
> 
And as per:

	http://www.mail-archive.com/netdev@vger.kernel.org/msg50027.html

Still-acked-by: Paul Mundt <lethal@linux-sh.org>

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)
  2007-11-08  7:31 ax88796: add superh to kconfig dependencies Magnus Damm
  2007-11-08  8:12 ` Paul Mundt
@ 2007-11-08  8:18 ` Al Viro
  2007-11-08  9:02   ` Andrew Morton
                     ` (2 more replies)
  2007-11-08 17:47 ` ax88796: add superh to kconfig dependencies Jeff Garzik
  2 siblings, 3 replies; 11+ messages in thread
From: Al Viro @ 2007-11-08  8:18 UTC (permalink / raw)
  To: Magnus Damm; +Cc: netdev, lethal, ben-linux, akpm, jeff, linux-arch

On Thu, Nov 08, 2007 at 04:31:05PM +0900, Magnus Damm wrote:
>  config AX88796
>  	tristate "ASIX AX88796 NE2000 clone support"
> -	depends on ARM || MIPS
> +	depends on ARM || MIPS || SUPERH

You know, that really sucks more and more.  How about doing the following:
	a) making it depend on PLAT_HAS_AX88796
	b) adding selects for all subarchitectures that have the corresponding
platform device
and setting that as a uniform policy for platform drivers?  For things like
SM501 we would do
config MFD_SM501
	depends on PCI || PLAT_HAS_SM501
etc.

Seriously, folks, we are getting shitloads of platform drivers with no
dependencies whatsoever, needed on a handful of targets and occasionally
failing to build on unrelated architectures.  Moreover, having a list
of architectures in dependencies for each of those suckers is a PITA
from the conflict POV.  Not to mention platform drivers that fall into
the mainline kernel with not a single platform device for them, etc.

Comments?

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)
  2007-11-08  8:18 ` [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies) Al Viro
@ 2007-11-08  9:02   ` Andrew Morton
  2007-11-09  9:26   ` Ralf Baechle
  2007-11-09 12:06   ` Ben Dooks
  2 siblings, 0 replies; 11+ messages in thread
From: Andrew Morton @ 2007-11-08  9:02 UTC (permalink / raw)
  To: Al Viro; +Cc: magnus.damm, netdev, lethal, ben-linux, jeff, linux-arch

> On Thu, 8 Nov 2007 08:18:54 +0000 Al Viro <viro@ftp.linux.org.uk> wrote:
> On Thu, Nov 08, 2007 at 04:31:05PM +0900, Magnus Damm wrote:
> >  config AX88796
> >  	tristate "ASIX AX88796 NE2000 clone support"
> > -	depends on ARM || MIPS
> > +	depends on ARM || MIPS || SUPERH
> 
> You know, that really sucks more and more.  How about doing the following:
> 	a) making it depend on PLAT_HAS_AX88796
> 	b) adding selects for all subarchitectures that have the corresponding
> platform device
> and setting that as a uniform policy for platform drivers?

Yup, but we should be religious about the naming conventions.  ARCH_HAS_
and PLAT_HAS_ followed by the exact name of the thus-enabled config option.

>  For things like
> SM501 we would do
> config MFD_SM501
> 	depends on PCI || PLAT_HAS_SM501
> etc.

See, bug.  That should be PLAT_HAS_MFD_SM501

> Seriously, folks, we are getting shitloads of platform drivers with no
> dependencies whatsoever, needed on a handful of targets and occasionally
> failing to build on unrelated architectures.  Moreover, having a list
> of architectures in dependencies for each of those suckers is a PITA
> from the conflict POV.  Not to mention platform drivers that fall into
> the mainline kernel with not a single platform device for them, etc.
> 
> Comments?

grep PPC drivers/*/Kconfig and weep.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: ax88796: add superh to kconfig dependencies
  2007-11-08  7:31 ax88796: add superh to kconfig dependencies Magnus Damm
  2007-11-08  8:12 ` Paul Mundt
  2007-11-08  8:18 ` [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies) Al Viro
@ 2007-11-08 17:47 ` Jeff Garzik
  2 siblings, 0 replies; 11+ messages in thread
From: Jeff Garzik @ 2007-11-08 17:47 UTC (permalink / raw)
  To: Magnus Damm; +Cc: netdev, lethal, ben-linux, akpm

On Thu, Nov 08, 2007 at 04:31:05PM +0900, Magnus Damm wrote:
> ax88796: add superh to kconfig dependencies
> 
> This patch adds sh architecture support to the ax88796 kconfig.
> 
> Signed-off-by: Magnus Damm <damm@igel.co.jp>
> ---
> 
>  This patch was posted about a month ago but never picked up:
>  http://www.mail-archive.com/netdev@vger.kernel.org/msg50018.html
>  The rest of the sh support is already included in rc1. Please apply.
> 
>  drivers/net/Kconfig |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)
  2007-11-08  8:18 ` [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies) Al Viro
  2007-11-08  9:02   ` Andrew Morton
@ 2007-11-09  9:26   ` Ralf Baechle
  2007-11-09  9:40     ` Paul Mundt
  2007-11-09 12:06   ` Ben Dooks
  2 siblings, 1 reply; 11+ messages in thread
From: Ralf Baechle @ 2007-11-09  9:26 UTC (permalink / raw)
  To: Al Viro; +Cc: Magnus Damm, netdev, lethal, ben-linux, akpm, jeff, linux-arch

On Thu, Nov 08, 2007 at 08:18:54AM +0000, Al Viro wrote:

> On Thu, Nov 08, 2007 at 04:31:05PM +0900, Magnus Damm wrote:
> >  config AX88796
> >  	tristate "ASIX AX88796 NE2000 clone support"
> > -	depends on ARM || MIPS
> > +	depends on ARM || MIPS || SUPERH
> 
> You know, that really sucks more and more.  How about doing the following:
> 	a) making it depend on PLAT_HAS_AX88796
> 	b) adding selects for all subarchitectures that have the corresponding
> platform device
> and setting that as a uniform policy for platform drivers?  For things like
> SM501 we would do
> config MFD_SM501
> 	depends on PCI || PLAT_HAS_SM501
> etc.
> 
> Seriously, folks, we are getting shitloads of platform drivers with no
> dependencies whatsoever, needed on a handful of targets and occasionally
> failing to build on unrelated architectures.  Moreover, having a list
> of architectures in dependencies for each of those suckers is a PITA
> from the conflict POV.  Not to mention platform drivers that fall into
> the mainline kernel with not a single platform device for them, etc.
> 
> Comments?

commit def47c5095d53814512bb0c62ec02dfdec769db1
Author: Jeff Garzik <jeff@garzik.org>
Date:   Tue Jul 10 14:06:48 2007 -0400

    [netdrvr] Fix dependencies for ax88796 ne2k clone driver
    
    It needs writesb(), not available on all platforms.
    
    Signed-off-by: Jeff Garzik <jeff@garzik.org>

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index a3bef22..a64c2fb 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -199,6 +199,7 @@ source "drivers/net/arm/Kconfig"
 
 config AX88796
        tristate "ASIX AX88796 NE2000 clone support"
+       depends on ARM || MIPS
        select CRC32
        select MII
        help


If writesb() is not an official API then maybe the answer should have been
to either add that API to other architectures or fix the driver.

I guess this incident means I need to go through all Kconfig* files to
see what bogus architecture dependencies on MIPS or !MIPS exist ...

  Ralf

^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)
  2007-11-09  9:26   ` Ralf Baechle
@ 2007-11-09  9:40     ` Paul Mundt
  2007-11-09 12:02       ` Russell King
  2007-11-09 12:08       ` Ben Dooks
  0 siblings, 2 replies; 11+ messages in thread
From: Paul Mundt @ 2007-11-09  9:40 UTC (permalink / raw)
  To: Ralf Baechle
  Cc: Al Viro, Magnus Damm, netdev, ben-linux, akpm, jeff, linux-arch

On Fri, Nov 09, 2007 at 09:26:52AM +0000, Ralf Baechle wrote:
> If writesb() is not an official API then maybe the answer should have been
> to either add that API to other architectures or fix the driver.
> 
> I guess this incident means I need to go through all Kconfig* files to
> see what bogus architecture dependencies on MIPS or !MIPS exist ...
> 
While writesb() isn't an official API, the iowriteX_rep() interfaces
theoretically are. Tidying up the driver for iomap is probably a better
option.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)
  2007-11-09  9:40     ` Paul Mundt
@ 2007-11-09 12:02       ` Russell King
  2007-11-09 12:08       ` Ben Dooks
  1 sibling, 0 replies; 11+ messages in thread
From: Russell King @ 2007-11-09 12:02 UTC (permalink / raw)
  To: Paul Mundt, Ralf Baechle, Al Viro, Magnus Damm, netdev, ben-linux

On Fri, Nov 09, 2007 at 06:40:23PM +0900, Paul Mundt wrote:
> On Fri, Nov 09, 2007 at 09:26:52AM +0000, Ralf Baechle wrote:
> > If writesb() is not an official API then maybe the answer should have been
> > to either add that API to other architectures or fix the driver.
> > 
> > I guess this incident means I need to go through all Kconfig* files to
> > see what bogus architecture dependencies on MIPS or !MIPS exist ...
> > 
> While writesb() isn't an official API, the iowriteX_rep() interfaces
> theoretically are. Tidying up the driver for iomap is probably a better
> option.

writesb() predates iowriteX_rep() interfaces by quite a number of years,
though if you're using writesb(), converting over to iowriteX_rep() is
really a no-brainer.

writesb() is effectively what mmio_outsb() is, and exists to do what
outsb() does but for peripherals mapped using ioremap on ARM rather
than trying to emulate them via the legacy x86 IO interfaces.

Note that it would've been far better that whoever invented mmio_outsb()
looked around and noticed that some of us already have an implementation
called writesb()... but time has proven that folk seem to be blinkered
to anything not x86.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)
  2007-11-08  8:18 ` [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies) Al Viro
  2007-11-08  9:02   ` Andrew Morton
  2007-11-09  9:26   ` Ralf Baechle
@ 2007-11-09 12:06   ` Ben Dooks
  2007-11-10  3:12     ` Jeff Garzik
  2 siblings, 1 reply; 11+ messages in thread
From: Ben Dooks @ 2007-11-09 12:06 UTC (permalink / raw)
  To: Al Viro; +Cc: Magnus Damm, netdev, lethal, ben-linux, akpm, jeff, linux-arch

On Thu, Nov 08, 2007 at 08:18:54AM +0000, Al Viro wrote:
> On Thu, Nov 08, 2007 at 04:31:05PM +0900, Magnus Damm wrote:
> >  config AX88796
> >  	tristate "ASIX AX88796 NE2000 clone support"
> > -	depends on ARM || MIPS
> > +	depends on ARM || MIPS || SUPERH
> 
> You know, that really sucks more and more.  How about doing the following:
> 	a) making it depend on PLAT_HAS_AX88796
> 	b) adding selects for all subarchitectures that have the corresponding
> platform device
> and setting that as a uniform policy for platform drivers?  For things like
> SM501 we would do
> config MFD_SM501
> 	depends on PCI || PLAT_HAS_SM501
> etc.

The PLAT_HAS_xxx method is nice, and I would like it applied to other places
in the kernel (see libata arugment below), and would have acked
this patch if it hadn't already been applied by Jeff.

The only reservation is that this doesn't show up the posibilty
of having the driver in the menuconfig, but anyone adding new
board support (should) be bright enough to look through the
Kconfig scripts before deciding they need to write an entirely
new driver.

I would note you may want to do PLAT_HAS_NET_AX88796 as there is
entirely a posibility of confusing this with the simple parallel
port driver which a board may not have support for.

> Seriously, folks, we are getting shitloads of platform drivers with no
> dependencies whatsoever, needed on a handful of targets and occasionally
> failing to build on unrelated architectures.  Moreover, having a list
> of architectures in dependencies for each of those suckers is a PITA
> from the conflict POV.  Not to mention platform drivers that fall into
> the mainline kernel with not a single platform device for them, etc.

There is a general problem with chicken-vs-egg here, how do you submit
support for a machine's platform device without the platform device
being there (and vice-versa) with seperate maintainers for network
and machine support?

One of my colleagues has passed along comments you made about a pair
of the simtec drivers (simtec-i2c and simtec-ide) which have been
added, but have no current users as patches have been stalled either
in submission process, or awaiting for an resolution. In the case
of simtec-ide, I would like to replace it with platform-ata, but
the libata maintainers seem wholy un-interested in
PLAT_HAS_PLATFORM_ATA or similar.

-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)
  2007-11-09  9:40     ` Paul Mundt
  2007-11-09 12:02       ` Russell King
@ 2007-11-09 12:08       ` Ben Dooks
  1 sibling, 0 replies; 11+ messages in thread
From: Ben Dooks @ 2007-11-09 12:08 UTC (permalink / raw)
  To: Paul Mundt, Ralf Baechle, Al Viro, Magnus Damm, netdev, ben-linux

On Fri, Nov 09, 2007 at 06:40:23PM +0900, Paul Mundt wrote:
> On Fri, Nov 09, 2007 at 09:26:52AM +0000, Ralf Baechle wrote:
> > If writesb() is not an official API then maybe the answer should have been
> > to either add that API to other architectures or fix the driver.
> > 
> > I guess this incident means I need to go through all Kconfig* files to
> > see what bogus architecture dependencies on MIPS or !MIPS exist ...
> > 
> While writesb() isn't an official API, the iowriteX_rep() interfaces
> theoretically are. Tidying up the driver for iomap is probably a better
> option.

If anyone else isn't interested in doing this, and there are
no objections to having it done, then I would be willing to
look at moving to the iowrite interfaces.

The only other way would be to add an 8/16bit configuration
to drop the use of writesb, as I belive most people connect
these devices in 16bit mode.

-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)
  2007-11-09 12:06   ` Ben Dooks
@ 2007-11-10  3:12     ` Jeff Garzik
  0 siblings, 0 replies; 11+ messages in thread
From: Jeff Garzik @ 2007-11-10  3:12 UTC (permalink / raw)
  To: Ben Dooks
  Cc: Al Viro, Magnus Damm, netdev, lethal, ben-linux, akpm, linux-arch

Ben Dooks wrote:
> in submission process, or awaiting for an resolution. In the case
> of simtec-ide, I would like to replace it with platform-ata, but
> the libata maintainers seem wholy un-interested in
> PLAT_HAS_PLATFORM_ATA or similar.


I've either missed or forgotten your patch/proposal, want to repost to 
linux-ide?

I want to spread libata to the far corner of the globe, and am quite 
interested in supporting all architectures.

	Jeff



^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2007-11-10  3:12 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-11-08  7:31 ax88796: add superh to kconfig dependencies Magnus Damm
2007-11-08  8:12 ` Paul Mundt
2007-11-08  8:18 ` [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies) Al Viro
2007-11-08  9:02   ` Andrew Morton
2007-11-09  9:26   ` Ralf Baechle
2007-11-09  9:40     ` Paul Mundt
2007-11-09 12:02       ` Russell King
2007-11-09 12:08       ` Ben Dooks
2007-11-09 12:06   ` Ben Dooks
2007-11-10  3:12     ` Jeff Garzik
2007-11-08 17:47 ` ax88796: add superh to kconfig dependencies Jeff Garzik

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).