ax88796: add superh to kconfig dependencies

ax88796: add superh to kconfig dependencies

[Magnus Damm]

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

Re: ax88796: add superh to kconfig dependencies

[Paul Mundt]

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>

[RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)

[Al Viro]

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?

Re: [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)

[Andrew Morton]

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

Re: [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)

[Ralf Baechle]

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

Re: [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)

[Paul Mundt]

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.

Re: [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)

[Russell King]

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:

Re: [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)

[Russell King]

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:

Re: [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)

[Ben Dooks]

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'

Re: [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)

[Ben Dooks]

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'

Re: [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)

[Ben Dooks]

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'

Re: [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)

[Jeff Garzik]

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

Re: ax88796: add superh to kconfig dependencies

[Jeff Garzik]

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