[2.6 patch] PCMCIA mustn't select HAVE_IDE

[2.6 patch] PCMCIA mustn't select HAVE_IDE

[Adrian Bunk]

It's plain wrong for PCMCIA to select HAVE_IDE that implies e.g. the 
availability of an asm/ide.h

Signed-off-by: Adrian Bunk <bunk@kernel.org>

---
9cdb66112488bc0c6e1d528444d3ba30d5b0487f diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig
index 8b22281..519b4ff 100644
--- a/drivers/pcmcia/Kconfig
+++ b/drivers/pcmcia/Kconfig
@@ -38,7 +38,6 @@ config PCMCIA_DEBUG
 config PCMCIA
 	tristate "16-bit PCMCIA support"
 	select CRC32
-	select HAVE_IDE
 	default y
 	---help---
 	   This option enables support for 16-bit PCMCIA cards. Most older

Re: [2.6 patch] PCMCIA mustn't select HAVE_IDE

[Sam Ravnborg]

On Mon, Apr 14, 2008 at 05:16:59PM +0300, Adrian Bunk wrote:
> It's plain wrong for PCMCIA to select HAVE_IDE that implies e.g. the 
> availability of an asm/ide.h
> 
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
> 
> ---
> 9cdb66112488bc0c6e1d528444d3ba30d5b0487f diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig
> index 8b22281..519b4ff 100644
> --- a/drivers/pcmcia/Kconfig
> +++ b/drivers/pcmcia/Kconfig
> @@ -38,7 +38,6 @@ config PCMCIA_DEBUG
>  config PCMCIA
>  	tristate "16-bit PCMCIA support"
>  	select CRC32
> -	select HAVE_IDE
>  	default y

I did this when introducing HAVE_IDE.
But I do not recall why and the rationale for removing it
seems fine to me.

So patch looks good - but I have not investigated in detail.

	Sam

Re: [2.6 patch] PCMCIA mustn't select HAVE_IDE

[Bartlomiej Zolnierkiewicz]

On Monday 14 April 2008, Sam Ravnborg wrote:
> On Mon, Apr 14, 2008 at 05:16:59PM +0300, Adrian Bunk wrote:
> > It's plain wrong for PCMCIA to select HAVE_IDE that implies e.g. the 
> > availability of an asm/ide.h
> > 
> > Signed-off-by: Adrian Bunk <bunk@kernel.org>
> > 
> > ---
> > 9cdb66112488bc0c6e1d528444d3ba30d5b0487f diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig
> > index 8b22281..519b4ff 100644
> > --- a/drivers/pcmcia/Kconfig
> > +++ b/drivers/pcmcia/Kconfig
> > @@ -38,7 +38,6 @@ config PCMCIA_DEBUG
> >  config PCMCIA
> >  	tristate "16-bit PCMCIA support"
> >  	select CRC32
> > -	select HAVE_IDE
> >  	default y
> 
> I did this when introducing HAVE_IDE.
> But I do not recall why and the rationale for removing it
> seems fine to me.

IIRC it was needed for some arm platforms which don't select HAVE_IDE
explicetely but I don't know if this is still the case, pinging Russell.

> So patch looks good - but I have not investigated in detail.
> 
> 	Sam

Re: [2.6 patch] PCMCIA mustn't select HAVE_IDE

[Adrian Bunk]

On Tue, Apr 15, 2008 at 10:15:34PM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Monday 14 April 2008, Sam Ravnborg wrote:
> > On Mon, Apr 14, 2008 at 05:16:59PM +0300, Adrian Bunk wrote:
> > > It's plain wrong for PCMCIA to select HAVE_IDE that implies e.g. the 
> > > availability of an asm/ide.h
> > > 
> > > Signed-off-by: Adrian Bunk <bunk@kernel.org>
> > > 
> > > ---
> > > 9cdb66112488bc0c6e1d528444d3ba30d5b0487f diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig
> > > index 8b22281..519b4ff 100644
> > > --- a/drivers/pcmcia/Kconfig
> > > +++ b/drivers/pcmcia/Kconfig
> > > @@ -38,7 +38,6 @@ config PCMCIA_DEBUG
> > >  config PCMCIA
> > >  	tristate "16-bit PCMCIA support"
> > >  	select CRC32
> > > -	select HAVE_IDE
> > >  	default y
> > 
> > I did this when introducing HAVE_IDE.
> > But I do not recall why and the rationale for removing it
> > seems fine to me.
> 
> IIRC it was needed for some arm platforms which don't select HAVE_IDE
> explicetely but I don't know if this is still the case, pinging Russell.

It's definitely bogus since it can cause compile breakage on 
architectures like avr32.

And whatever it should have fixed should be fixed properly.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] PCMCIA mustn't select HAVE_IDE

[Russell King]

On Wed, Apr 16, 2008 at 12:23:26AM +0300, Adrian Bunk wrote:
> On Tue, Apr 15, 2008 at 10:15:34PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > On Monday 14 April 2008, Sam Ravnborg wrote:
> > > On Mon, Apr 14, 2008 at 05:16:59PM +0300, Adrian Bunk wrote:
> > > > It's plain wrong for PCMCIA to select HAVE_IDE that implies e.g. the 
> > > > availability of an asm/ide.h
> > > > 
> > > > Signed-off-by: Adrian Bunk <bunk@kernel.org>
> > > > 
> > > > ---
> > > > 9cdb66112488bc0c6e1d528444d3ba30d5b0487f diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig
> > > > index 8b22281..519b4ff 100644
> > > > --- a/drivers/pcmcia/Kconfig
> > > > +++ b/drivers/pcmcia/Kconfig
> > > > @@ -38,7 +38,6 @@ config PCMCIA_DEBUG
> > > >  config PCMCIA
> > > >  	tristate "16-bit PCMCIA support"
> > > >  	select CRC32
> > > > -	select HAVE_IDE
> > > >  	default y
> > > 
> > > I did this when introducing HAVE_IDE.
> > > But I do not recall why and the rationale for removing it
> > > seems fine to me.
> > 
> > IIRC it was needed for some arm platforms which don't select HAVE_IDE
> > explicetely but I don't know if this is still the case, pinging Russell.
> 
> It's definitely bogus since it can cause compile breakage on 
> architectures like avr32.
> 
> And whatever it should have fixed should be fixed properly.

I'd suggest backing out the entire change which introduced HAVE_IDE then -
rather than doing it piecemeal and bringing up questions about it which
are unanswerable (which is the case of Bart's question of me.)

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

Re: [2.6 patch] PCMCIA mustn't select HAVE_IDE

[Russell King]

On Tue, Apr 15, 2008 at 10:28:22PM +0100, Russell King wrote:
> On Wed, Apr 16, 2008 at 12:23:26AM +0300, Adrian Bunk wrote:
> > On Tue, Apr 15, 2008 at 10:15:34PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > On Monday 14 April 2008, Sam Ravnborg wrote:
> > > > On Mon, Apr 14, 2008 at 05:16:59PM +0300, Adrian Bunk wrote:
> > > > > It's plain wrong for PCMCIA to select HAVE_IDE that implies e.g. the 
> > > > > availability of an asm/ide.h
> > > > > 
> > > > > Signed-off-by: Adrian Bunk <bunk@kernel.org>
> > > > > 
> > > > > ---
> > > > > 9cdb66112488bc0c6e1d528444d3ba30d5b0487f diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig
> > > > > index 8b22281..519b4ff 100644
> > > > > --- a/drivers/pcmcia/Kconfig
> > > > > +++ b/drivers/pcmcia/Kconfig
> > > > > @@ -38,7 +38,6 @@ config PCMCIA_DEBUG
> > > > >  config PCMCIA
> > > > >  	tristate "16-bit PCMCIA support"
> > > > >  	select CRC32
> > > > > -	select HAVE_IDE
> > > > >  	default y
> > > > 
> > > > I did this when introducing HAVE_IDE.
> > > > But I do not recall why and the rationale for removing it
> > > > seems fine to me.
> > > 
> > > IIRC it was needed for some arm platforms which don't select HAVE_IDE
> > > explicetely but I don't know if this is still the case, pinging Russell.
> > 
> > It's definitely bogus since it can cause compile breakage on 
> > architectures like avr32.
> > 
> > And whatever it should have fixed should be fixed properly.
> 
> I'd suggest backing out the entire change which introduced HAVE_IDE then -
> rather than doing it piecemeal and bringing up questions about it which
> are unanswerable (which is the case of Bart's question of me.)

Looking back at the original change:

-if PCMCIA || ARCH_CLPS7500 || ARCH_IOP32X || ARCH_IOP33X || ARCH_IXP4XX \
-       || ARCH_L7200 || ARCH_LH7A40X || ARCH_PXA || ARCH_RPC \
-       || ARCH_S3C2410 || ARCH_SA1100 || ARCH_SHARK || FOOTBRIDGE \
-       || ARCH_IXP23XX
 source "drivers/ide/Kconfig"
-endif

was what was done to ARM's Kconfig.  So, if we're going to be doing
anything with the 'select HAVE_IDE', it should be:

 config PCMCIA
        tristate "16-bit PCMCIA support"
        select CRC32
-	select HAVE_IDE
+	select HAVE_IDE if ARM

Or, as I've already said, we revert all of the HAVE_IDE change, and ARM
continues avoiding drivers/Kconfig.

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

Re: [2.6 patch] PCMCIA mustn't select HAVE_IDE

[Adrian Bunk]

On Tue, Apr 15, 2008 at 10:42:03PM +0100, Russell King wrote:
> On Tue, Apr 15, 2008 at 10:28:22PM +0100, Russell King wrote:
> > On Wed, Apr 16, 2008 at 12:23:26AM +0300, Adrian Bunk wrote:
> > > On Tue, Apr 15, 2008 at 10:15:34PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > On Monday 14 April 2008, Sam Ravnborg wrote:
> > > > > On Mon, Apr 14, 2008 at 05:16:59PM +0300, Adrian Bunk wrote:
> > > > > > It's plain wrong for PCMCIA to select HAVE_IDE that implies e.g. the 
> > > > > > availability of an asm/ide.h
> > > > > > 
> > > > > > Signed-off-by: Adrian Bunk <bunk@kernel.org>
> > > > > > 
> > > > > > ---
> > > > > > 9cdb66112488bc0c6e1d528444d3ba30d5b0487f diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig
> > > > > > index 8b22281..519b4ff 100644
> > > > > > --- a/drivers/pcmcia/Kconfig
> > > > > > +++ b/drivers/pcmcia/Kconfig
> > > > > > @@ -38,7 +38,6 @@ config PCMCIA_DEBUG
> > > > > >  config PCMCIA
> > > > > >  	tristate "16-bit PCMCIA support"
> > > > > >  	select CRC32
> > > > > > -	select HAVE_IDE
> > > > > >  	default y
> > > > > 
> > > > > I did this when introducing HAVE_IDE.
> > > > > But I do not recall why and the rationale for removing it
> > > > > seems fine to me.
> > > > 
> > > > IIRC it was needed for some arm platforms which don't select HAVE_IDE
> > > > explicetely but I don't know if this is still the case, pinging Russell.
> > > 
> > > It's definitely bogus since it can cause compile breakage on 
> > > architectures like avr32.
> > > 
> > > And whatever it should have fixed should be fixed properly.
> > 
> > I'd suggest backing out the entire change which introduced HAVE_IDE then -
> > rather than doing it piecemeal and bringing up questions about it which
> > are unanswerable (which is the case of Bart's question of me.)
> 
> Looking back at the original change:
> 
> -if PCMCIA || ARCH_CLPS7500 || ARCH_IOP32X || ARCH_IOP33X || ARCH_IXP4XX \
> -       || ARCH_L7200 || ARCH_LH7A40X || ARCH_PXA || ARCH_RPC \
> -       || ARCH_S3C2410 || ARCH_SA1100 || ARCH_SHARK || FOOTBRIDGE \
> -       || ARCH_IXP23XX
>  source "drivers/ide/Kconfig"
> -endif
> 
> was what was done to ARM's Kconfig.  So, if we're going to be doing
> anything with the 'select HAVE_IDE', it should be:
> 
>  config PCMCIA
>         tristate "16-bit PCMCIA support"
>         select CRC32
> -	select HAVE_IDE
> +	select HAVE_IDE if ARM
>...

The commit that added the PCMCIA dependency was:

commit bb011b8e8eded247cb71cb6d10e47517aacbd542
Author: David Brownell <david-b@net.rmk.(none)>
Date:   Sun Jun 12 23:26:05 2005 +0100

    [PATCH] ARM: 2709/1: Systems with PCMCIA should also see IDE options (for CompactFlash memories)
    
    Patch from David Brownell
    
    The ARM generic Kconfig filters out IDE options ... except for
    an error prone ARMload of special cases.
    This adds one general case to the systems that will offer IDE options:
    kernels with PCMCIA support, which probably want to use IDE to access
    CompactFlash cards.  This might allow many (most?) of the other cases
    to disappear, for systems that only see IDE hardware through CF cards.
    Right now this one patch is used to gate access to CF cards, including
    MicroDrives, for both omap_cf and at91_cf drivers.
    
    Signed-off-by: David Brownell
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>



We could simply always select HAVE_IDE on arm instead of manually 
setting which platforms could possibly get IDE support (e.g. are there
any boards with PCI slots for which HAVE_IDE is currently not 
selected?).

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] PCMCIA mustn't select HAVE_IDE

[Russell King]

On Wed, Apr 16, 2008 at 12:52:23AM +0300, Adrian Bunk wrote:
> On Tue, Apr 15, 2008 at 10:42:03PM +0100, Russell King wrote:
> > On Tue, Apr 15, 2008 at 10:28:22PM +0100, Russell King wrote:
> > > On Wed, Apr 16, 2008 at 12:23:26AM +0300, Adrian Bunk wrote:
> > > > On Tue, Apr 15, 2008 at 10:15:34PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > > On Monday 14 April 2008, Sam Ravnborg wrote:
> > > > > > On Mon, Apr 14, 2008 at 05:16:59PM +0300, Adrian Bunk wrote:
> > > > > > > It's plain wrong for PCMCIA to select HAVE_IDE that implies e.g. the 
> > > > > > > availability of an asm/ide.h
> > > > > > > 
> > > > > > > Signed-off-by: Adrian Bunk <bunk@kernel.org>
> > > > > > > 
> > > > > > > ---
> > > > > > > 9cdb66112488bc0c6e1d528444d3ba30d5b0487f diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig
> > > > > > > index 8b22281..519b4ff 100644
> > > > > > > --- a/drivers/pcmcia/Kconfig
> > > > > > > +++ b/drivers/pcmcia/Kconfig
> > > > > > > @@ -38,7 +38,6 @@ config PCMCIA_DEBUG
> > > > > > >  config PCMCIA
> > > > > > >  	tristate "16-bit PCMCIA support"
> > > > > > >  	select CRC32
> > > > > > > -	select HAVE_IDE
> > > > > > >  	default y
> > > > > > 
> > > > > > I did this when introducing HAVE_IDE.
> > > > > > But I do not recall why and the rationale for removing it
> > > > > > seems fine to me.
> > > > > 
> > > > > IIRC it was needed for some arm platforms which don't select HAVE_IDE
> > > > > explicetely but I don't know if this is still the case, pinging Russell.
> > > > 
> > > > It's definitely bogus since it can cause compile breakage on 
> > > > architectures like avr32.
> > > > 
> > > > And whatever it should have fixed should be fixed properly.
> > > 
> > > I'd suggest backing out the entire change which introduced HAVE_IDE then -
> > > rather than doing it piecemeal and bringing up questions about it which
> > > are unanswerable (which is the case of Bart's question of me.)
> > 
> > Looking back at the original change:
> > 
> > -if PCMCIA || ARCH_CLPS7500 || ARCH_IOP32X || ARCH_IOP33X || ARCH_IXP4XX \
> > -       || ARCH_L7200 || ARCH_LH7A40X || ARCH_PXA || ARCH_RPC \
> > -       || ARCH_S3C2410 || ARCH_SA1100 || ARCH_SHARK || FOOTBRIDGE \
> > -       || ARCH_IXP23XX
> >  source "drivers/ide/Kconfig"
> > -endif
> > 
> > was what was done to ARM's Kconfig.  So, if we're going to be doing
> > anything with the 'select HAVE_IDE', it should be:
> > 
> >  config PCMCIA
> >         tristate "16-bit PCMCIA support"
> >         select CRC32
> > -	select HAVE_IDE
> > +	select HAVE_IDE if ARM
> >...
> 
> The commit that added the PCMCIA dependency was:
> 
> commit bb011b8e8eded247cb71cb6d10e47517aacbd542
> Author: David Brownell <david-b@net.rmk.(none)>
> Date:   Sun Jun 12 23:26:05 2005 +0100

Did you look at the patch?

-if ARCH_CLPS7500 || ARCH_IOP3XX || ARCH_IXP4XX || ARCH_L7200 || ARCH_LH7A40X || ARCH_PXA || ARCH_RPC || ARCH_S3C2410 || ARCH_SA1100 || ARCH_SHARK || FOOTBRIDGE
+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

So this is a only impacting ARM wrt. PCMCIA, and given that ARM supplies
an asm/ide.h, it's _entirely_ reasonable that if a platform has PCMCIA
then it supports IDE.

> We could simply always select HAVE_IDE on arm instead of manually 
> setting which platforms could possibly get IDE support (e.g. are there
> any boards with PCI slots for which HAVE_IDE is currently not 
> selected?).

You could, if there was a demand for it.  As no one has added that,
I conclude that its less common for people to stick an IDE controller
into a PCI backplane.

In fact, there are only three classes of ARM platforms which have PCI
selected but not HAVE_IDE - IOP13xx, IXP2000, and Orion.  I suspect
the only reason they don't select it because they now use the ATA code
rather than the old IDE code - that's certainly true of Orion.

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

Re: [2.6 patch] PCMCIA mustn't select HAVE_IDE

[Adrian Bunk]

On Tue, Apr 15, 2008 at 11:03:45PM +0100, Russell King wrote:
> On Wed, Apr 16, 2008 at 12:52:23AM +0300, Adrian Bunk wrote:
>...
> So this is a only impacting ARM wrt. PCMCIA, and given that ARM supplies
> an asm/ide.h, it's _entirely_ reasonable that if a platform has PCMCIA
> then it supports IDE.
> 
> > We could simply always select HAVE_IDE on arm instead of manually 
> > setting which platforms could possibly get IDE support (e.g. are there
> > any boards with PCI slots for which HAVE_IDE is currently not 
> > selected?).
> 
> You could, if there was a demand for it.  As no one has added that,
> I conclude that its less common for people to stick an IDE controller
> into a PCI backplane.

People can always enable code for stuff they don't use.

But instead of having 14 ARM platforms plus PCMCIA (which is offered 
unconditionally on all ARM platforms...) select HAVE_IDE it's simpler
to select it once for all ARM platforms.

> In fact, there are only three classes of ARM platforms which have PCI
> selected but not HAVE_IDE - IOP13xx, IXP2000, and Orion.  I suspect
> the only reason they don't select it because they now use the ATA code
> rather than the old IDE code - that's certainly true of Orion.

The libata options are offered unconditionally on all platforms...

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] PCMCIA mustn't select HAVE_IDE

[Russell King]

On Wed, Apr 16, 2008 at 01:10:02AM +0300, Adrian Bunk wrote:
> On Tue, Apr 15, 2008 at 11:03:45PM +0100, Russell King wrote:
> > On Wed, Apr 16, 2008 at 12:52:23AM +0300, Adrian Bunk wrote:
> >...
> > So this is a only impacting ARM wrt. PCMCIA, and given that ARM supplies
> > an asm/ide.h, it's _entirely_ reasonable that if a platform has PCMCIA
> > then it supports IDE.
> > 
> > > We could simply always select HAVE_IDE on arm instead of manually 
> > > setting which platforms could possibly get IDE support (e.g. are there
> > > any boards with PCI slots for which HAVE_IDE is currently not 
> > > selected?).
> > 
> > You could, if there was a demand for it.  As no one has added that,
> > I conclude that its less common for people to stick an IDE controller
> > into a PCI backplane.
> 
> People can always enable code for stuff they don't use.
> 
> But instead of having 14 ARM platforms plus PCMCIA (which is offered 
> unconditionally on all ARM platforms...) select HAVE_IDE it's simpler
> to select it once for all ARM platforms.

That would seem logical, but Bart objects to that idea.

However, consider that we're gradually transitioning over to being
exclusively libata only.

> > In fact, there are only three classes of ARM platforms which have PCI
> > selected but not HAVE_IDE - IOP13xx, IXP2000, and Orion.  I suspect
> > the only reason they don't select it because they now use the ATA code
> > rather than the old IDE code - that's certainly true of Orion.
> 
> The libata options are offered unconditionally on all platforms...

It wasn't *my* choice to restrict IDE on ARM.  See Bart for that
decision.

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

Re: [2.6 patch] PCMCIA mustn't select HAVE_IDE

[Bartlomiej Zolnierkiewicz]

On Wednesday 16 April 2008, Russell King wrote:
> On Wed, Apr 16, 2008 at 01:10:02AM +0300, Adrian Bunk wrote:
> > On Tue, Apr 15, 2008 at 11:03:45PM +0100, Russell King wrote:
> > > On Wed, Apr 16, 2008 at 12:52:23AM +0300, Adrian Bunk wrote:
> > >...
> > > So this is a only impacting ARM wrt. PCMCIA, and given that ARM supplies
> > > an asm/ide.h, it's _entirely_ reasonable that if a platform has PCMCIA
> > > then it supports IDE.
> > > 
> > > > We could simply always select HAVE_IDE on arm instead of manually 
> > > > setting which platforms could possibly get IDE support (e.g. are there
> > > > any boards with PCI slots for which HAVE_IDE is currently not 
> > > > selected?).
> > > 
> > > You could, if there was a demand for it.  As no one has added that,
> > > I conclude that its less common for people to stick an IDE controller
> > > into a PCI backplane.
> > 
> > People can always enable code for stuff they don't use.
> > 
> > But instead of having 14 ARM platforms plus PCMCIA (which is offered 
> > unconditionally on all ARM platforms...) select HAVE_IDE it's simpler
> > to select it once for all ARM platforms.

Please send me a patch doing this, it should be safe for current IDE tree.

> That would seem logical, but Bart objects to that idea.

I don't remember the background but I think it was needed because of badly
perplexed ide_init_hwif_ports() and friends in <asm/ide.h> vs <linux/ide.h>
(almost all this stuff is gone in IDE tree for 2.6.26)...

Ok, I found the patch:

http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=4b3b8ee5db374b76608537e061f2efd90e21179d

[ tglx's history tree since it is from May 2004. ]

> However, consider that we're gradually transitioning over to being
> exclusively libata only.
> 
> > > In fact, there are only three classes of ARM platforms which have PCI
> > > selected but not HAVE_IDE - IOP13xx, IXP2000, and Orion.  I suspect
> > > the only reason they don't select it because they now use the ATA code
> > > rather than the old IDE code - that's certainly true of Orion.
> > 
> > The libata options are offered unconditionally on all platforms...
> 
> It wasn't *my* choice to restrict IDE on ARM.  See Bart for that
> decision.

It could be that I did the poor job of explaining things back then
but I also didn't like the fact that I needed to restrict the IDE
choice on ARM - the change in question was _necessary_ to start
converting IDE drivers to become real, independent, modular host
drivers and as a preparation for adding proper warm-plug support.

Thanks,
Bart

[2.6 patch] ARM: always select HAVE_IDE

[Adrian Bunk]

On Wed, Apr 16, 2008 at 01:26:10AM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 16 April 2008, Russell King wrote:
> > On Wed, Apr 16, 2008 at 01:10:02AM +0300, Adrian Bunk wrote:
> > > On Tue, Apr 15, 2008 at 11:03:45PM +0100, Russell King wrote:
> > > > On Wed, Apr 16, 2008 at 12:52:23AM +0300, Adrian Bunk wrote:
> > > >...
> > > > So this is a only impacting ARM wrt. PCMCIA, and given that ARM supplies
> > > > an asm/ide.h, it's _entirely_ reasonable that if a platform has PCMCIA
> > > > then it supports IDE.
> > > > 
> > > > > We could simply always select HAVE_IDE on arm instead of manually 
> > > > > setting which platforms could possibly get IDE support (e.g. are there
> > > > > any boards with PCI slots for which HAVE_IDE is currently not 
> > > > > selected?).
> > > > 
> > > > You could, if there was a demand for it.  As no one has added that,
> > > > I conclude that its less common for people to stick an IDE controller
> > > > into a PCI backplane.
> > > 
> > > People can always enable code for stuff they don't use.
> > > 
> > > But instead of having 14 ARM platforms plus PCMCIA (which is offered 
> > > unconditionally on all ARM platforms...) select HAVE_IDE it's simpler
> > > to select it once for all ARM platforms.
> 
> Please send me a patch doing this, it should be safe for current IDE tree.
> 
> > That would seem logical, but Bart objects to that idea.
> 
> I don't remember the background but I think it was needed because of badly
> perplexed ide_init_hwif_ports() and friends in <asm/ide.h> vs <linux/ide.h>
> (almost all this stuff is gone in IDE tree for 2.6.26)...
> 
> Ok, I found the patch:
> 
> http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=4b3b8ee5db374b76608537e061f2efd90e21179d
> 
> [ tglx's history tree since it is from May 2004. ]
> 
> > However, consider that we're gradually transitioning over to being
> > exclusively libata only.
> > 
> > > > In fact, there are only three classes of ARM platforms which have PCI
> > > > selected but not HAVE_IDE - IOP13xx, IXP2000, and Orion.  I suspect
> > > > the only reason they don't select it because they now use the ATA code
> > > > rather than the old IDE code - that's certainly true of Orion.
> > > 
> > > The libata options are offered unconditionally on all platforms...
> > 
> > It wasn't *my* choice to restrict IDE on ARM.  See Bart for that
> > decision.
> 
> It could be that I did the poor job of explaining things back then
> but I also didn't like the fact that I needed to restrict the IDE
> choice on ARM - the change in question was _necessary_ to start
> converting IDE drivers to become real, independent, modular host
> drivers and as a preparation for adding proper warm-plug support.

Any objections against the patch below?

> Thanks,
> Bart

cu
Adrian


<--  snip  -->


It's plain wrong for PCMCIA to select HAVE_IDE that implies e.g. the
availability of an asm/ide.h

It turns out this was done for ARM, and we can simply always select 
HAVE_IDE on ARM instead of manually tracking which platforms might 
possible have an IDE controller directly or indirectly.

Signed-off-by: Adrian Bunk <bunk@kernel.org>

---

 arch/arm/Kconfig       |   15 +--------------
 drivers/pcmcia/Kconfig |    1 -
 2 files changed, 1 insertion(+), 15 deletions(-)

40d8b054ee277ee1d66e4379621e26d18926ed9d diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4039a13..6808136 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -8,6 +8,7 @@ mainmenu "Linux Kernel Configuration"
 config ARM
 	bool
 	default y
+	select HAVE_IDE
 	select RTC_LIB
 	select SYS_SUPPORTS_APM_EMULATION
 	select HAVE_OPROFILE
@@ -223,7 +224,6 @@ config ARCH_CLPS7500
 	select TIMER_ACORN
 	select ISA
 	select NO_IOPORT
-	select HAVE_IDE
 	help
 	  Support for the Cirrus Logic PS7500FE system-on-a-chip.
 
@@ -236,7 +236,6 @@ config ARCH_CO285
 	bool "Co-EBSA285"
 	select FOOTBRIDGE
 	select FOOTBRIDGE_ADDIN
-	select HAVE_IDE
 	help
 	  Support for Intel's EBSA285 companion chip.
 
@@ -261,7 +260,6 @@ config ARCH_EP93XX
 config ARCH_FOOTBRIDGE
 	bool "FootBridge"
 	select FOOTBRIDGE
-	select HAVE_IDE
 	help
 	  Support for systems based on the DC21285 companion chip
 	  ("FootBridge"), such as the Simtec CATS and the Rebel NetWinder.
@@ -300,7 +298,6 @@ config ARCH_IOP32X
 	depends on MMU
 	select PLAT_IOP
 	select PCI
-	select HAVE_IDE
 	help
 	  Support for Intel's 80219 and IOP32X (XScale) family of
 	  processors.
@@ -310,14 +307,12 @@ config ARCH_IOP33X
 	depends on MMU
 	select PLAT_IOP
 	select PCI
-	select HAVE_IDE
 	help
 	  Support for Intel's IOP33X (XScale) family of processors.
 
 config ARCH_IXP23XX
  	bool "IXP23XX-based"
 	depends on MMU
-	select HAVE_IDE
  	select PCI
 	help
 	  Support for Intel's IXP23xx (XScale) family of processors.
@@ -335,14 +330,12 @@ config ARCH_IXP4XX
 	select GENERIC_GPIO
 	select GENERIC_TIME
 	select GENERIC_CLOCKEVENTS
-	select HAVE_IDE
 	help
 	  Support for Intel's IXP4XX (XScale) family of processors.
 
 config ARCH_L7200
 	bool "LinkUp-L7200"
 	select FIQ
-	select HAVE_IDE
 	help
 	  Say Y here if you intend to run this kernel on a LinkUp Systems
 	  L7200 Software Development Board which uses an ARM720T processor.
@@ -397,7 +390,6 @@ config ARCH_PXA
 	depends on MMU
 	select ARCH_MTD_XIP
 	select GENERIC_GPIO
-	select HAVE_IDE
 	select HAVE_GPIO_LIB
 	select GENERIC_TIME
 	select GENERIC_CLOCKEVENTS
@@ -413,7 +405,6 @@ config ARCH_RPC
 	select ARCH_MAY_HAVE_PC_FDC
 	select ISA_DMA_API
 	select NO_IOPORT
-	select HAVE_IDE
 	help
 	  On the Acorn Risc-PC, Linux can support the internal IDE disk and
 	  CD-ROM interface, serial and parallel port, and the floppy drive.
@@ -425,14 +416,12 @@ config ARCH_SA1100
 	select ARCH_MTD_XIP
 	select GENERIC_GPIO
 	select GENERIC_TIME
-	select HAVE_IDE
 	help
 	  Support for StrongARM 11x0 based boards.
 
 config ARCH_S3C2410
 	bool "Samsung S3C2410, S3C2412, S3C2413, S3C2440, S3C2442, S3C2443"
 	select GENERIC_GPIO
-	select HAVE_IDE
 	help
 	  Samsung S3C2410X CPU based systems, such as the Simtec Electronics
 	  BAST (<http://www.simtec.co.uk/products/EB110ITX/>), the IPAQ 1940 or
@@ -440,7 +429,6 @@ config ARCH_S3C2410
 
 config ARCH_SHARK
 	bool "Shark"
-	select HAVE_IDE
 	select ISA
 	select ISA_DMA
 	select PCI
@@ -450,7 +438,6 @@ config ARCH_SHARK
 
 config ARCH_LH7A40X
 	bool "Sharp LH7A40X"
-	select HAVE_IDE
 	help
 	  Say Y here for systems based on one of the Sharp LH7A40X
 	  System on a Chip processors.  These CPUs include an ARM922T
diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig
index 8b22281..519b4ff 100644
--- a/drivers/pcmcia/Kconfig
+++ b/drivers/pcmcia/Kconfig
@@ -38,7 +38,6 @@ config PCMCIA_DEBUG
 config PCMCIA
 	tristate "16-bit PCMCIA support"
 	select CRC32
-	select HAVE_IDE
 	default y
 	---help---
 	   This option enables support for 16-bit PCMCIA cards. Most older

Re: [2.6 patch] ARM: always select HAVE_IDE

[Russell King]

On Thu, Apr 17, 2008 at 12:37:53PM +0300, Adrian Bunk wrote:
> Any objections against the patch below?

Let's look at the rest of the situation surrounding HAVE_IDE first.
It's something of a mess:

avr32, m68knommu, ppc, s390 and v850 do not have asm/ide.h

avr32, m68knommu, ppc, v850 all set HAVE_IDE, arch/s390/Kconfig contains
no reference.

avr32 supports PATA (which is IDE).

Everything else provides an asm/ide.h and sets HAVE_IDE.

So:

Q1. Do avr32, m68knommu, ppc, v850 have IDE support or do they not?
Q2. Should avr32, m68knommu, ppc, v850 supply an asm/ide.h header?
Q3. Is it worth supporting HAVE_IDE for all kernel architectures when
    its just one (s390) which supports neither IDE nor ATA - or would
    something more generic covering both be appropriate.

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

Re: [2.6 patch] ARM: always select HAVE_IDE

[Adrian Bunk]

On Thu, Apr 17, 2008 at 10:59:16AM +0100, Russell King wrote:
> On Thu, Apr 17, 2008 at 12:37:53PM +0300, Adrian Bunk wrote:
> > Any objections against the patch below?
> 
> Let's look at the rest of the situation surrounding HAVE_IDE first.
> It's something of a mess:
> 
> avr32, m68knommu, ppc, s390 and v850 do not have asm/ide.h
> 
> avr32, m68knommu, ppc, v850 all set HAVE_IDE, arch/s390/Kconfig contains
> no reference.
> 
> avr32 supports PATA (which is IDE).
> 
> Everything else provides an asm/ide.h and sets HAVE_IDE.
> 
> So:
> 
> Q1. Do avr32, m68knommu, ppc, v850 have IDE support or do they not?

avr32 is fixed in 2.6.25 (no more HAVE_IDE)
m68knommu I'll check
ppc arch will be removed in 2 months
v850 arch is completely hosed, and I'm already trying to get it removed

> Q2. Should avr32, m68knommu, ppc, v850 supply an asm/ide.h header?
> Q3. Is it worth supporting HAVE_IDE for all kernel architectures when
>     its just one (s390) which supports neither IDE nor ATA - or would
>     something more generic covering both be appropriate.
> 
> -- 
> Russell King

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] ARM: always select HAVE_IDE

[Russell King]

On Thu, Apr 17, 2008 at 01:48:36PM +0300, Adrian Bunk wrote:
> On Thu, Apr 17, 2008 at 10:59:16AM +0100, Russell King wrote:
> > On Thu, Apr 17, 2008 at 12:37:53PM +0300, Adrian Bunk wrote:
> > > Any objections against the patch below?
> > 
> > Let's look at the rest of the situation surrounding HAVE_IDE first.
> > It's something of a mess:
> > 
> > avr32, m68knommu, ppc, s390 and v850 do not have asm/ide.h
> > 
> > avr32, m68knommu, ppc, v850 all set HAVE_IDE, arch/s390/Kconfig contains
> > no reference.
> > 
> > avr32 supports PATA (which is IDE).
> > 
> > Everything else provides an asm/ide.h and sets HAVE_IDE.
> > 
> > So:
> > 
> > Q1. Do avr32, m68knommu, ppc, v850 have IDE support or do they not?
> 
> avr32 is fixed in 2.6.25 (no more HAVE_IDE)

avr32 has ATA, so the only reason it doesn't actually use IDE is because
they're using libata entirely.  This is NO different from the situation
on ARM - some machine classes use entirely libata, others use IDE, and
some others are trying to give up IDE in favour of libata.

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

Re: [2.6 patch] ARM: always select HAVE_IDE

[Adrian Bunk]

On Thu, Apr 17, 2008 at 12:00:05PM +0100, Russell King wrote:
> On Thu, Apr 17, 2008 at 01:48:36PM +0300, Adrian Bunk wrote:
> > On Thu, Apr 17, 2008 at 10:59:16AM +0100, Russell King wrote:
> > > On Thu, Apr 17, 2008 at 12:37:53PM +0300, Adrian Bunk wrote:
> > > > Any objections against the patch below?
> > > 
> > > Let's look at the rest of the situation surrounding HAVE_IDE first.
> > > It's something of a mess:
> > > 
> > > avr32, m68knommu, ppc, s390 and v850 do not have asm/ide.h
> > > 
> > > avr32, m68knommu, ppc, v850 all set HAVE_IDE, arch/s390/Kconfig contains
> > > no reference.
> > > 
> > > avr32 supports PATA (which is IDE).
> > > 
> > > Everything else provides an asm/ide.h and sets HAVE_IDE.
> > > 
> > > So:
> > > 
> > > Q1. Do avr32, m68knommu, ppc, v850 have IDE support or do they not?
> > 
> > avr32 is fixed in 2.6.25 (no more HAVE_IDE)
> 
> avr32 has ATA, so the only reason it doesn't actually use IDE is because
> they're using libata entirely.  This is NO different from the situation
> on ARM - some machine classes use entirely libata, others use IDE, and
> some others are trying to give up IDE in favour of libata.

You have a point that one might argue that avr32 should also select 
HAVE_IDE and get an asm/ide.h .

The main difference between avr32 and arm is that on arm there are a 
bunch of platforms that actually want to use drivers/ide/ at the moment, 
and the fine-grained select's we have at the moment don't bring any real 
gain.

I do actually not care much how this gets resolved (we could even 
ditch HAVE_IDE and provide asm/ide.h on all architectures) if there's 
general agreement that this is the way to go.

> Russell King

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] ARM: always select HAVE_IDE

[Russell King]

On Thu, Apr 17, 2008 at 04:25:07PM +0300, Adrian Bunk wrote:
> You have a point that one might argue that avr32 should also select 
> HAVE_IDE and get an asm/ide.h .
> 
> The main difference between avr32 and arm is that on arm there are a 
> bunch of platforms that actually want to use drivers/ide/ at the moment, 
> and the fine-grained select's we have at the moment don't bring any real 
> gain.
> 
> I do actually not care much how this gets resolved (we could even 
> ditch HAVE_IDE and provide asm/ide.h on all architectures) if there's 
> general agreement that this is the way to go.

That is probably a more correct approach.

Consider that if you do have PCMCIA, then you can plug a CF card in and,
therefore, you have an IDE interface in the system.  So, selecting
HAVE_IDE if PCMCIA is enabled is entirely reasonable.  What isn't so
reasonable is not providing asm/ide.h if your architecture has the
possibility of supporting PCMCIA.

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

Re: [2.6 patch] ARM: always select HAVE_IDE

[Bartlomiej Zolnierkiewicz]

On Thursday 17 April 2008, Adrian Bunk wrote:
> On Thu, Apr 17, 2008 at 12:00:05PM +0100, Russell King wrote:
> > On Thu, Apr 17, 2008 at 01:48:36PM +0300, Adrian Bunk wrote:
> > > On Thu, Apr 17, 2008 at 10:59:16AM +0100, Russell King wrote:
> > > > On Thu, Apr 17, 2008 at 12:37:53PM +0300, Adrian Bunk wrote:
> > > > > Any objections against the patch below?
> > > > 
> > > > Let's look at the rest of the situation surrounding HAVE_IDE first.
> > > > It's something of a mess:
> > > > 
> > > > avr32, m68knommu, ppc, s390 and v850 do not have asm/ide.h
> > > > 
> > > > avr32, m68knommu, ppc, v850 all set HAVE_IDE, arch/s390/Kconfig contains
> > > > no reference.
> > > > 
> > > > avr32 supports PATA (which is IDE).
> > > > 
> > > > Everything else provides an asm/ide.h and sets HAVE_IDE.
> > > > 
> > > > So:
> > > > 
> > > > Q1. Do avr32, m68knommu, ppc, v850 have IDE support or do they not?
> > > 
> > > avr32 is fixed in 2.6.25 (no more HAVE_IDE)
> > 
> > avr32 has ATA, so the only reason it doesn't actually use IDE is because
> > they're using libata entirely.  This is NO different from the situation
> > on ARM - some machine classes use entirely libata, others use IDE, and
> > some others are trying to give up IDE in favour of libata.
> 
> You have a point that one might argue that avr32 should also select 
> HAVE_IDE and get an asm/ide.h .
> 
> The main difference between avr32 and arm is that on arm there are a 
> bunch of platforms that actually want to use drivers/ide/ at the moment, 
> and the fine-grained select's we have at the moment don't bring any real 
> gain.
> 
> I do actually not care much how this gets resolved (we could even 
> ditch HAVE_IDE and provide asm/ide.h on all architectures) if there's 
> general agreement that this is the way to go.

Seems like a way to go now that all crazy IDE core code vs arch code
inter-dependiences have been fixed (the ideal solution would be to ditch
asm/ide.h completely but this requires some more time/work).

Thanks,
Bart

Re: [2.6 patch] ARM: always select HAVE_IDE

[Sam Ravnborg]

> > 
> > I do actually not care much how this gets resolved (we could even 
> > ditch HAVE_IDE and provide asm/ide.h on all architectures) if there's 
> > general agreement that this is the way to go.
> 
> Seems like a way to go now that all crazy IDE core code vs arch code
> inter-dependiences have been fixed (the ideal solution would be to ditch
> asm/ide.h completely but this requires some more time/work).

I invented HAVE_IDE in the past to make it trivial for arm to
use drivers/Kconfig.
And that incentive are not broken by your suggestion so fine with me.

But I really do not know about s390. They were the only one
without IDE in the past.

	Sam

Re: [2.6 patch] ARM: always select HAVE_IDE

[Bartlomiej Zolnierkiewicz]

On Sunday 27 April 2008, Sam Ravnborg wrote:
> > > 
> > > I do actually not care much how this gets resolved (we could even 
> > > ditch HAVE_IDE and provide asm/ide.h on all architectures) if there's 
> > > general agreement that this is the way to go.
> > 
> > Seems like a way to go now that all crazy IDE core code vs arch code
> > inter-dependiences have been fixed (the ideal solution would be to ditch
> > asm/ide.h completely but this requires some more time/work).
> 
> I invented HAVE_IDE in the past to make it trivial for arm to
> use drivers/Kconfig.
> And that incentive are not broken by your suggestion so fine with me.

Cool.

> But I really do not know about s390. They were the only one
> without IDE in the past.

They don't seem to support neither PCI nor ISA so I think that we
should just special case them (== make IDE depend on BLOCK && !S390).

Thanks,
Bart

Re: [2.6 patch] ARM: always select HAVE_IDE

[Matthew Wilcox]

On Thu, Apr 17, 2008 at 01:48:36PM +0300, Adrian Bunk wrote:
> avr32 is fixed in 2.6.25 (no more HAVE_IDE)
> m68knommu I'll check
> ppc arch will be removed in 2 months

More pertinently, builds using ARCH=ppc will use asm-powerpc via a nasty
nasty temporary hack ;-)

> v850 arch is completely hosed, and I'm already trying to get it removed

Oh good.  There's a couple of things I've noticd about it recently that
are broken and was trying to summon the enthusiasm for doing a proper
bug report.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: [2.6 patch] ARM: always select HAVE_IDE

[Bartlomiej Zolnierkiewicz]

On Thursday 17 April 2008, Adrian Bunk wrote:
> On Wed, Apr 16, 2008 at 01:26:10AM +0200, Bartlomiej Zolnierkiewicz wrote:
> > On Wednesday 16 April 2008, Russell King wrote:
> > > On Wed, Apr 16, 2008 at 01:10:02AM +0300, Adrian Bunk wrote:
> > > > On Tue, Apr 15, 2008 at 11:03:45PM +0100, Russell King wrote:
> > > > > On Wed, Apr 16, 2008 at 12:52:23AM +0300, Adrian Bunk wrote:
> > > > >...
> > > > > So this is a only impacting ARM wrt. PCMCIA, and given that ARM supplies
> > > > > an asm/ide.h, it's _entirely_ reasonable that if a platform has PCMCIA
> > > > > then it supports IDE.
> > > > > 
> > > > > > We could simply always select HAVE_IDE on arm instead of manually 
> > > > > > setting which platforms could possibly get IDE support (e.g. are there
> > > > > > any boards with PCI slots for which HAVE_IDE is currently not 
> > > > > > selected?).
> > > > > 
> > > > > You could, if there was a demand for it.  As no one has added that,
> > > > > I conclude that its less common for people to stick an IDE controller
> > > > > into a PCI backplane.
> > > > 
> > > > People can always enable code for stuff they don't use.
> > > > 
> > > > But instead of having 14 ARM platforms plus PCMCIA (which is offered 
> > > > unconditionally on all ARM platforms...) select HAVE_IDE it's simpler
> > > > to select it once for all ARM platforms.
> > 
> > Please send me a patch doing this, it should be safe for current IDE tree.
> > 
> > > That would seem logical, but Bart objects to that idea.
> > 
> > I don't remember the background but I think it was needed because of badly
> > perplexed ide_init_hwif_ports() and friends in <asm/ide.h> vs <linux/ide.h>
> > (almost all this stuff is gone in IDE tree for 2.6.26)...
> > 
> > Ok, I found the patch:
> > 
> > http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=4b3b8ee5db374b76608537e061f2efd90e21179d
> > 
> > [ tglx's history tree since it is from May 2004. ]
> > 
> > > However, consider that we're gradually transitioning over to being
> > > exclusively libata only.
> > > 
> > > > > In fact, there are only three classes of ARM platforms which have PCI
> > > > > selected but not HAVE_IDE - IOP13xx, IXP2000, and Orion.  I suspect
> > > > > the only reason they don't select it because they now use the ATA code
> > > > > rather than the old IDE code - that's certainly true of Orion.
> > > > 
> > > > The libata options are offered unconditionally on all platforms...
> > > 
> > > It wasn't *my* choice to restrict IDE on ARM.  See Bart for that
> > > decision.
> > 
> > It could be that I did the poor job of explaining things back then
> > but I also didn't like the fact that I needed to restrict the IDE
> > choice on ARM - the change in question was _necessary_ to start
> > converting IDE drivers to become real, independent, modular host
> > drivers and as a preparation for adding proper warm-plug support.
> 
> Any objections against the patch below?
> 
> > Thanks,
> > Bart
> 
> cu
> Adrian
> 
> 
> <--  snip  -->
> 
> 
> It's plain wrong for PCMCIA to select HAVE_IDE that implies e.g. the
> availability of an asm/ide.h
> 
> It turns out this was done for ARM, and we can simply always select 
> HAVE_IDE on ARM instead of manually tracking which platforms might 
> possible have an IDE controller directly or indirectly.
> 
> Signed-off-by: Adrian Bunk <bunk@kernel.org>

thanks, applied

[ Russell: I plan to put it into next IDE update, please ping me if you
  prefer to merge it through ARM tree ]

Re: [2.6 patch] PCMCIA mustn't select HAVE_IDE

[Russell King]

On Tue, Apr 15, 2008 at 10:15:34PM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Monday 14 April 2008, Sam Ravnborg wrote:
> > On Mon, Apr 14, 2008 at 05:16:59PM +0300, Adrian Bunk wrote:
> > > It's plain wrong for PCMCIA to select HAVE_IDE that implies e.g. the 
> > > availability of an asm/ide.h
> > > 
> > > Signed-off-by: Adrian Bunk <bunk@kernel.org>
> > > 
> > > ---
> > > 9cdb66112488bc0c6e1d528444d3ba30d5b0487f diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig
> > > index 8b22281..519b4ff 100644
> > > --- a/drivers/pcmcia/Kconfig
> > > +++ b/drivers/pcmcia/Kconfig
> > > @@ -38,7 +38,6 @@ config PCMCIA_DEBUG
> > >  config PCMCIA
> > >  	tristate "16-bit PCMCIA support"
> > >  	select CRC32
> > > -	select HAVE_IDE
> > >  	default y
> > 
> > I did this when introducing HAVE_IDE.
> > But I do not recall why and the rationale for removing it
> > seems fine to me.
> 
> IIRC it was needed for some arm platforms which don't select HAVE_IDE
> explicetely but I don't know if this is still the case, pinging Russell.

If that is so then it is so - the only way to find out is work out
why we ended up with HAVE_IDE and what it was transformed from.

To just ask me whether it's still the case, I've absolutely no idea -
there's no way in hell for me to be able to track these kinds of
dependencies.

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