Hi,
What about this patch which removes ARM dependency for dm9000 ethernet
controller driver ?
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index f15f909..4af63dd 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -856,7 +856,7 @@ config SMC9194
config DM9000
tristate "DM9000 support"
- depends on ARM && NET_ETHERNET
+ depends on NET_ETHERNET
select CRC32
select MII
---help---
My platform based on MIPS cpu used it...
Thanks
--
Franck
On Wed, Nov 30, 2005 at 05:21:35PM +0100, Franck wrote:
> Hi,
>
> What about this patch which removes ARM dependency for dm9000 ethernet
> controller driver ?
>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index f15f909..4af63dd 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -856,7 +856,7 @@ config SMC9194
>
> config DM9000
> tristate "DM9000 support"
> - depends on ARM && NET_ETHERNET
> + depends on NET_ETHERNET
> select CRC32
> select MII
> ---help---
>
> My platform based on MIPS cpu used it...
Maybe that should be (ARM || MIPS) && NET_ETHERNET ?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
2005/11/30, Russell King <[email protected]>:
> On Wed, Nov 30, 2005 at 05:21:35PM +0100, Franck wrote:
> > Hi,
> >
> > What about this patch which removes ARM dependency for dm9000 ethernet
> > controller driver ?
> >
> Maybe that should be (ARM || MIPS) && NET_ETHERNET ?
>
Well, if this dependency means "it has only be tested on ARM and
MIPS", then you're probably right. But if it means "this controller
must be run with an ARM or MIPS cpu" then I don't see why setting such
restriction. What do you think ?
thanks
--
Franck
On Wed, Nov 30, 2005 at 05:45:33PM +0100, Franck wrote:
> 2005/11/30, Russell King <[email protected]>:
> > On Wed, Nov 30, 2005 at 05:21:35PM +0100, Franck wrote:
> > > Hi,
> > >
> > > What about this patch which removes ARM dependency for dm9000 ethernet
> > > controller driver ?
> > >
> > Maybe that should be (ARM || MIPS) && NET_ETHERNET ?
> >
>
> Well, if this dependency means "it has only be tested on ARM and
> MIPS", then you're probably right. But if it means "this controller
> must be run with an ARM or MIPS cpu" then I don't see why setting such
> restriction. What do you think ?
If other CPUs use this then fine, but I find that having config options
needlessly available to all architectures is annoying - especially when
they are never used.
Eg, would you ever expect to see a DM9000 ethernet device on an x86
machine? Probably not - there's far better PCI solutions now.
So until someone says "I want to use this on such and such arch" I
think it's better to keep it dependent on those we know are likely
to support it.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
2005/11/30, Russell King <[email protected]>:
>
> If other CPUs use this then fine, but I find that having config options
> needlessly available to all architectures is annoying - especially when
> they are never used.
>
> Eg, would you ever expect to see a DM9000 ethernet device on an x86
> machine? Probably not - there's far better PCI solutions now.
>
> So until someone says "I want to use this on such and such arch" I
> think it's better to keep it dependent on those we know are likely
> to support it.
>
That makes sens, specially if it's going to be used only by few arch.
I'll resend a new patch.
Thanks
--
Franck
On Wed, 2005-11-30 at 16:55 +0000, Russell King wrote:
> So until someone says "I want to use this on such and such arch" I
> think it's better to keep it dependent on those we know are likely
> to support it.
I disagree; unless there's a reason why it _shouldn't_ work on a given
architecture, it should be possible to enable it there.
I believe I've seen FR-V boards with dm9000 too.
--
dwmw2
On Wed, Nov 30, 2005 at 06:14:42PM +0000, David Woodhouse wrote:
> On Wed, 2005-11-30 at 16:55 +0000, Russell King wrote:
> > So until someone says "I want to use this on such and such arch" I
> > think it's better to keep it dependent on those we know are likely
> > to support it.
>
> I disagree; unless there's a reason why it _shouldn't_ work on a given
> architecture, it should be possible to enable it there.
We agree to disagree. For example, in all probability, ARM will never
see a TPM chip, yet it's offered for selection. Given that, does it
really make sense to offer it for ARM?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
From: Russell King <[email protected]>
Date: Wed, 30 Nov 2005 16:55:47 +0000
> If other CPUs use this then fine, but I find that having config options
> needlessly available to all architectures is annoying - especially when
> they are never used.
>
> Eg, would you ever expect to see a DM9000 ethernet device on an x86
> machine? Probably not - there's far better PCI solutions now.
If I, for example, make changes across the tree to SKB handling, I'd
like to be able to build as many drivers as possible and fix up the
compile warnings and build failures before _you_ get to see them.
That's why it's a good idea to make drivers available to as many
platforms as possible, even if the hardware isn't necessarily
used there.
2005/11/30, David S. Miller <[email protected]>:
> From: Russell King <[email protected]>
> Date: Wed, 30 Nov 2005 16:55:47 +0000
>
> > If other CPUs use this then fine, but I find that having config options
> > needlessly available to all architectures is annoying - especially when
> > they are never used.
> >
> > Eg, would you ever expect to see a DM9000 ethernet device on an x86
> > machine? Probably not - there's far better PCI solutions now.
>
> If I, for example, make changes across the tree to SKB handling, I'd
> like to be able to build as many drivers as possible and fix up the
> compile warnings and build failures before _you_ get to see them.
>
> That's why it's a good idea to make drivers available to as many
> platforms as possible, even if the hardware isn't necessarily
> used there.
>
this would mean that we should change almost all ethernet driver deps ?
thanks
--
Franck
On Wed, 2005-11-30 at 19:02 +0000, Russell King wrote:
> We agree to disagree. For example, in all probability, ARM will never
> see a TPM chip, yet it's offered for selection. Given that, does it
> really make sense to offer it for ARM?
You speak of _probability_. Yes, it makes sense to offer it as an
_option_ for ARM. It just doesn't make sense to put it in the defconfig
for any of the existing platforms.
Nobody expects 'allyesconfig' to be something you'd actually want to
_use_.
--
dwmw2
On Thu, Dec 01, 2005 at 08:36:39AM +0000, David Woodhouse wrote:
> On Wed, 2005-11-30 at 19:02 +0000, Russell King wrote:
> > We agree to disagree. For example, in all probability, ARM will never
> > see a TPM chip, yet it's offered for selection. Given that, does it
> > really make sense to offer it for ARM?
>
> You speak of _probability_. Yes, it makes sense to offer it as an
> _option_ for ARM. It just doesn't make sense to put it in the defconfig
> for any of the existing platforms.
>
> Nobody expects 'allyesconfig' to be something you'd actually want to
> _use_.
In which case why do we restrict floppy to only those machines which
could have floppy? Why do we restrict IDE to only those platforms
which may have IDE?
Hint: there's already a precident established for *not* offering
configuration options which are pointless.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
From: Russell King <[email protected]>
Date: Thu, 1 Dec 2005 09:41:11 +0000
> In which case why do we restrict floppy to only those machines which
> could have floppy? Why do we restrict IDE to only those platforms
> which may have IDE?
These two examples require platform level support via
an asm/*.h header file.
Whereas the driver's we are talking about use portable
interfaces that should be available across the board.
So, bad example.
On Thu, Dec 01, 2005 at 01:51:15AM -0800, David S. Miller wrote:
> From: Russell King <[email protected]>
> Date: Thu, 1 Dec 2005 09:41:11 +0000
>
> > In which case why do we restrict floppy to only those machines which
> > could have floppy? Why do we restrict IDE to only those platforms
> > which may have IDE?
>
> These two examples require platform level support via
> an asm/*.h header file.
>
> Whereas the driver's we are talking about use portable
> interfaces that should be available across the board.
>
> So, bad example.
Not in the IDE case. Bart restricted IDE to a smaller number of ARM
platforms, plus any that had PCMCIA. There is no such restriction
in the asm-arm/*.h header files.
if PCMCIA || ARCH_CLPS7500 || ARCH_IOP3XX || ARCH_IXP4XX \
|| ARCH_L7200 || ARCH_LH7A40X || ARCH_PXA || ARCH_RPC \
|| ARCH_S3C2410 || ARCH_SA1100 || ARCH_SHARK || FOOTBRIDGE
source "drivers/ide/Kconfig"
endif
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On 12/1/05, Russell King <[email protected]> wrote:
> On Thu, Dec 01, 2005 at 01:51:15AM -0800, David S. Miller wrote:
> > From: Russell King <[email protected]>
> > Date: Thu, 1 Dec 2005 09:41:11 +0000
> >
> > > In which case why do we restrict floppy to only those machines which
> > > could have floppy? Why do we restrict IDE to only those platforms
> > > which may have IDE?
> >
> > These two examples require platform level support via
> > an asm/*.h header file.
> >
> > Whereas the driver's we are talking about use portable
> > interfaces that should be available across the board.
> >
> > So, bad example.
>
> Not in the IDE case. Bart restricted IDE to a smaller number of ARM
> platforms, plus any that had PCMCIA. There is no such restriction
> in the asm-arm/*.h header files.
When I did this change there was such restriction in asm-arm/mach-*/ide.h
files (some platforms just lacked ide.h making IDE build break for them).
IDE is a bad example anyway because of legacy ordering issues etc etc.
> if PCMCIA || ARCH_CLPS7500 || ARCH_IOP3XX || ARCH_IXP4XX \
> || ARCH_L7200 || ARCH_LH7A40X || ARCH_PXA || ARCH_RPC \
> || ARCH_S3C2410 || ARCH_SA1100 || ARCH_SHARK || FOOTBRIDGE
> source "drivers/ide/Kconfig"
> endif
On Thu, Dec 01, 2005 at 09:41:11AM +0000, Russell King wrote:
> In which case why do we restrict floppy to only those machines which
> could have floppy?
Because the floopy drivers needs asm/floppy.h and wouldn't build on others.
> Why do we restrict IDE to only those platforms
> which may have IDE?
Dito with asm/ide.h
these are very old drivers where people weren't used to abstractions that
would allow to write them platform-independent. For any driver that doesn't
have an actual platform depency making it conditional is a bad idea.
On Thu, Dec 01, 2005 at 12:11:24PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On 12/1/05, Russell King <[email protected]> wrote:
> > On Thu, Dec 01, 2005 at 01:51:15AM -0800, David S. Miller wrote:
> > > So, bad example.
> >
> > Not in the IDE case. Bart restricted IDE to a smaller number of ARM
> > platforms, plus any that had PCMCIA. There is no such restriction
> > in the asm-arm/*.h header files.
>
> When I did this change there was such restriction in asm-arm/mach-*/ide.h
> files (some platforms just lacked ide.h making IDE build break for them).
>
> IDE is a bad example anyway because of legacy ordering issues etc etc.
Okay. Given the general concensus in this thread, can this be removed
now?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On 12/1/05, Russell King <[email protected]> wrote:
> On Thu, Dec 01, 2005 at 12:11:24PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > On 12/1/05, Russell King <[email protected]> wrote:
> > > On Thu, Dec 01, 2005 at 01:51:15AM -0800, David S. Miller wrote:
> > > > So, bad example.
> > >
> > > Not in the IDE case. Bart restricted IDE to a smaller number of ARM
> > > platforms, plus any that had PCMCIA. There is no such restriction
> > > in the asm-arm/*.h header files.
> >
> > When I did this change there was such restriction in asm-arm/mach-*/ide.h
> > files (some platforms just lacked ide.h making IDE build break for them).
> >
> > IDE is a bad example anyway because of legacy ordering issues etc etc.
>
> Okay. Given the general concensus in this thread, can this be removed
> now?
No, I didn't say that I agree with DaveM. :)
For IDE keeping restriction makes it much easier to maintain
(i.e. to answer questions like "why is this ugly hack needed?").
Bartlomiej
On Wed, 30 Nov 2005, Russell King wrote:
> So until someone says "I want to use this on such and such arch" I
> think it's better to keep it dependent on those we know are likely
> to support it.
I use DM9000 on SH-4.
--
Matan Ziv-Av. [email protected]