[PATCH] IDE: don't offer IDE_GENERIC on ia64

[PATCH] IDE: don't offer IDE_GENERIC on ia64

[Bjorn Helgaas]

IA64 boxes only have PCI IDE devices, so there's no need to blindly poke
around in I/O port space.  Poking at things that don't exist causes MCAs
on HP ia64 systems.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>

Index: work-vga/drivers/ide/Kconfig
===================================================================
--- work-vga.orig/drivers/ide/Kconfig	2005-08-10 14:57:47.000000000 -0600
+++ work-vga/drivers/ide/Kconfig	2005-08-10 14:58:02.000000000 -0600
@@ -276,6 +276,7 @@
 
 config IDE_GENERIC
 	tristate "generic/default IDE chipset support"
+	depends on !IA64
 	default y
 	help
 	  If unsure, say Y.

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Christoph Hellwig]

On Thu, Aug 11, 2005 at 02:24:43PM -0600, Bjorn Helgaas wrote:
> IA64 boxes only have PCI IDE devices, so there's no need to blindly poke
> around in I/O port space.  Poking at things that don't exist causes MCAs
> on HP ia64 systems.

Maybe it should instead depend on those systems where it is available.
Anything but X86?

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Bjorn Helgaas]

On Thursday 11 August 2005 2:34 pm, Christoph Hellwig wrote:
> On Thu, Aug 11, 2005 at 02:24:43PM -0600, Bjorn Helgaas wrote:
> > IA64 boxes only have PCI IDE devices, so there's no need to blindly poke
> > around in I/O port space.  Poking at things that don't exist causes MCAs
> > on HP ia64 systems.
> 
> Maybe it should instead depend on those systems where it is available.
> Anything but X86?

I'm OK with that, but don't want to be responsible for coming up
with the list of systems where it should be available :-)

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Jan Engelhardt]

>Maybe it should instead depend on those systems where it is available.
>Anything but X86?

x86_64?


Jan Engelhardt
-- 

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Bartlomiej Zolnierkiewicz]

On 8/11/05, Christoph Hellwig <hch@infradead.org> wrote:
> On Thu, Aug 11, 2005 at 02:24:43PM -0600, Bjorn Helgaas wrote:
> > IA64 boxes only have PCI IDE devices, so there's no need to blindly poke
> > around in I/O port space.  Poking at things that don't exist causes MCAs
> > on HP ia64 systems.
> 
> Maybe it should instead depend on those systems where it is available.
> Anything but X86?

Don't forget that arch specific drivers use IDE_GENERIC *indirectly*
to probe for devices.

Bartlomiej

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Alan Cox]

On Maw, 2005-08-16 at 12:02 +0200, Bartlomiej Zolnierkiewicz wrote:
> On 8/11/05, Christoph Hellwig <hch@infradead.org> wrote:
> > On Thu, Aug 11, 2005 at 02:24:43PM -0600, Bjorn Helgaas wrote:
> > > IA64 boxes only have PCI IDE devices, so there's no need to blindly poke
> > > around in I/O port space.  Poking at things that don't exist causes MCAs
> > > on HP ia64 systems.
> > 
> > Maybe it should instead depend on those systems where it is available.
> > Anything but X86?
> 
> Don't forget that arch specific drivers use IDE_GENERIC *indirectly*
> to probe for devices.

Just about everything wants IDE GENERIC. Most of them want the probe
address providing function to simply be "return 0" or the two 'magic'
PCI bus legacy addresses. Probably only ia-32 wants to poke other
addresses and even that now checks for non-PCI first

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Jeff Garzik]

Bjorn Helgaas wrote:
> IA64 boxes only have PCI IDE devices, so there's no need to blindly poke
> around in I/O port space.  Poking at things that don't exist causes MCAs
> on HP ia64 systems.
> 
> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
> 
> Index: work-vga/drivers/ide/Kconfig
> ===================================================================
> --- work-vga.orig/drivers/ide/Kconfig	2005-08-10 14:57:47.000000000 -0600
> +++ work-vga/drivers/ide/Kconfig	2005-08-10 14:58:02.000000000 -0600
> @@ -276,6 +276,7 @@
>  
>  config IDE_GENERIC
>  	tristate "generic/default IDE chipset support"
> +	depends on !IA64


hmmmmmmmmm.  Are you POSITIVE that the legacy IDE ports are never enabled?

In modern Intel chipsets, this still occurs with e.g. combined mode.

	Jeff

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Bjorn Helgaas]

On Thursday 11 August 2005 2:36 pm, Jeff Garzik wrote:
> Bjorn Helgaas wrote:
> > IA64 boxes only have PCI IDE devices, so there's no need to blindly poke
> > around in I/O port space.  Poking at things that don't exist causes MCAs
> > on HP ia64 systems.
> > 
> > Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
> > 
> > Index: work-vga/drivers/ide/Kconfig
> > ===================================================================
> > --- work-vga.orig/drivers/ide/Kconfig	2005-08-10 14:57:47.000000000 -0600
> > +++ work-vga/drivers/ide/Kconfig	2005-08-10 14:58:02.000000000 -0600
> > @@ -276,6 +276,7 @@
> >  
> >  config IDE_GENERIC
> >  	tristate "generic/default IDE chipset support"
> > +	depends on !IA64
> 
> hmmmmmmmmm.  Are you POSITIVE that the legacy IDE ports are never enabled?
> 
> In modern Intel chipsets, this still occurs with e.g. combined mode.

I don't know about combined mode.  If the legacy IDE ports are
enabled, shouldn't they be described via ACPI, and hence usable
via the ide_pnp - PNPACPI - ACPI path?

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Jeff Garzik]

Bjorn Helgaas wrote:
> On Thursday 11 August 2005 2:36 pm, Jeff Garzik wrote:
> 
>>Bjorn Helgaas wrote:
>>
>>>IA64 boxes only have PCI IDE devices, so there's no need to blindly poke
>>>around in I/O port space.  Poking at things that don't exist causes MCAs
>>>on HP ia64 systems.
>>>
>>>Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
>>>
>>>Index: work-vga/drivers/ide/Kconfig
>>>===================================================================
>>>--- work-vga.orig/drivers/ide/Kconfig	2005-08-10 14:57:47.000000000 -0600
>>>+++ work-vga/drivers/ide/Kconfig	2005-08-10 14:58:02.000000000 -0600
>>>@@ -276,6 +276,7 @@
>>> 
>>> config IDE_GENERIC
>>> 	tristate "generic/default IDE chipset support"
>>>+	depends on !IA64
>>
>>hmmmmmmmmm.  Are you POSITIVE that the legacy IDE ports are never enabled?
>>
>>In modern Intel chipsets, this still occurs with e.g. combined mode.
> 
> 
> I don't know about combined mode.  If the legacy IDE ports are
> enabled, shouldn't they be described via ACPI, and hence usable
> via the ide_pnp - PNPACPI - ACPI path?

No idea...  that's more for platform IA64 people to answer :/

	Jeff

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Bjorn Helgaas]

On Thursday 11 August 2005 2:56 pm, Jeff Garzik wrote:
> Bjorn Helgaas wrote:
> > On Thursday 11 August 2005 2:36 pm, Jeff Garzik wrote:
> >>Bjorn Helgaas wrote:
> >>> config IDE_GENERIC
> >>> 	tristate "generic/default IDE chipset support"
> >>>+	depends on !IA64
> >>
> >>hmmmmmmmmm.  Are you POSITIVE that the legacy IDE ports are never enabled?
> >>
> >>In modern Intel chipsets, this still occurs with e.g. combined mode.
> > 
> > I don't know about combined mode.  If the legacy IDE ports are
> > enabled, shouldn't they be described via ACPI, and hence usable
> > via the ide_pnp - PNPACPI - ACPI path?
> 
> No idea...  that's more for platform IA64 people to answer :/

OK, well, I assert that failure to describe an IDE device that
uses legacy ports would be an ACPI defect.

Tony, others, does this change give you any heartburn?  On
the 460GX and 870 boxes I have, IDE is a PCI device.

(I have been told that the SGI ia64 simulator depends on
IDE_GENERIC.  But it really should make the IDE device
appear in PCI (or describe it via ACPI)).

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Jeff Garzik]

On Thu, Aug 11, 2005 at 03:42:07PM -0600, Bjorn Helgaas wrote:
> Tony, others, does this change give you any heartburn?  On
> the 460GX and 870 boxes I have, IDE is a PCI device.
> 
> (I have been told that the SGI ia64 simulator depends on
> IDE_GENERIC.  But it really should make the IDE device
> appear in PCI (or describe it via ACPI)).

I think I was misunderstood.

Have you reviewed the PCI IDE specification?

On modern chipsets, the IDE device appears in PCI -- but often, the first 
four I/O ports will be zeroed out, indicating that the I/O regions are
actually 0x1f0/0x170.

For example:

00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller 
(rev 02) (prog-if 8a [Master SecP PriP])
        Subsystem: Hewlett-Packard Company d530 CMT (DG746A)
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 169
        Region 0: I/O ports at <ignored>
        Region 1: I/O ports at <ignored>
        Region 2: I/O ports at <ignored>
        Region 3: I/O ports at <ignored>
        Region 4: I/O ports at 14c0 [size=16]
        Region 5: Memory at 40000000 (32-bit, non-prefetchable) [size=1K]



Trust me, IDE on PCI is still quite weird.

	Jeff

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Jeff Garzik]

Jeff Garzik wrote:
> 00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller 
> (rev 02) (prog-if 8a [Master SecP PriP])
>         Subsystem: Hewlett-Packard Company d530 CMT (DG746A)
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
> ping- SERR- FastB2B-
>         Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
> - <MAbort- >SERR- <PERR-
>         Latency: 0
>         Interrupt: pin A routed to IRQ 169
>         Region 0: I/O ports at <ignored>
>         Region 1: I/O ports at <ignored>
>         Region 2: I/O ports at <ignored>
>         Region 3: I/O ports at <ignored>
>         Region 4: I/O ports at 14c0 [size=16]
>         Region 5: Memory at 40000000 (32-bit, non-prefetchable) [size=1K]
> 
> 
> 
> Trust me, IDE on PCI is still quite weird.

The above configuration also indicates that the IRQs for the PCI device 
are 14 and 15, _not_ 169.

	Jeff

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Bjorn Helgaas]

On Thursday 11 August 2005 3:56 pm, Jeff Garzik wrote:
> Jeff Garzik wrote:
> > 00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller 
> > (rev 02) (prog-if 8a [Master SecP PriP])
> >         Subsystem: Hewlett-Packard Company d530 CMT (DG746A)
> >         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
> > ping- SERR- FastB2B-
> >         Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
> > - <MAbort- >SERR- <PERR-
> >         Latency: 0
> >         Interrupt: pin A routed to IRQ 169
> >         Region 0: I/O ports at <ignored>
> >         Region 1: I/O ports at <ignored>
> >         Region 2: I/O ports at <ignored>
> >         Region 3: I/O ports at <ignored>
> >         Region 4: I/O ports at 14c0 [size=16]
> >         Region 5: Memory at 40000000 (32-bit, non-prefetchable) [size=1K]
> > 
> > Trust me, IDE on PCI is still quite weird.
> 
> The above configuration also indicates that the IRQs for the PCI device 
> are 14 and 15, _not_ 169.

You deduce this by the absence of SecO and PriO?  I wonder if lspci
should be enhanced to notice this, too.  I assume that the IRQ 169
doesn't correspond to anything in /proc/interrupts.

So the scenario in question (correct me if I'm wrong) is that we
have a PCI IDE device that is handed off in compatibility mode (and
may only work in that mode).  In that case, the PCI *device* still
exists, so shouldn't the IDE PCI code claim that device, notice that
it's in compatibility mode, and use the legacy ports and IRQs if
necessary?

It seems like that all should work even if we don't have IDE_GENERIC.

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Jeff Garzik]

Bjorn Helgaas wrote:
> You deduce this by the absence of SecO and PriO?  I wonder if lspci
> should be enhanced to notice this, too.  I assume that the IRQ 169
> doesn't correspond to anything in /proc/interrupts.

Correct.


> So the scenario in question (correct me if I'm wrong) is that we
> have a PCI IDE device that is handed off in compatibility mode (and
> may only work in that mode).  In that case, the PCI *device* still
> exists, so shouldn't the IDE PCI code claim that device, notice that
> it's in compatibility mode, and use the legacy ports and IRQs if
> necessary?
> 
> It seems like that all should work even if we don't have IDE_GENERIC.

Yes, you're right.  Thinking more, the PCI IDE code should pick that up, 
not the IDE_GENERIC code.

	Jeff

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Alan Cox]

On Iau, 2005-08-11 at 17:07 -0600, Bjorn Helgaas wrote:
> So the scenario in question (correct me if I'm wrong) is that we
> have a PCI IDE device that is handed off in compatibility mode (and
> may only work in that mode).  In that case, the PCI *device* still
> exists, so shouldn't the IDE PCI code claim that device, notice that
> it's in compatibility mode, and use the legacy ports and IRQs if
> necessary?

The PCI IDE code and legacy IDE code both find the device and they
realise its the same device so that it is driven by a suitable driver.
The legacy IDE driver is useful if your platform has an unsupported IDE
controller. It seems ot me the correct fix for IA64 is probably to set
your arch specific probe address function to only probe the standard PCI
legacy ports and to do any other appropriate checks, not to take an axe
to Kconfig. 

Alan

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Maciej W. Rozycki]

On Thu, 11 Aug 2005, Bjorn Helgaas wrote:

> So the scenario in question (correct me if I'm wrong) is that we
> have a PCI IDE device that is handed off in compatibility mode (and
> may only work in that mode).  In that case, the PCI *device* still
> exists, so shouldn't the IDE PCI code claim that device, notice that
> it's in compatibility mode, and use the legacy ports and IRQs if
> necessary?

 You may have a look at how we've solved this for MIPS, where we have a 
mixture of bus arrangements for different platforms, starting from pure 
ISA/EISA ones, ones with PCI and a PCI-(E)ISA bridge, legacy-free PCI ones 
and systems with no Intel-style buses at all, like TURBOchannel ones.  
See "asm-mips/mach-generic/ide.h" for a simple solution that fits all so 
far.  I'm not sure whether the most recent version of the file has been 
merged upstream -- you may have to have look at: 
"http://www.linux-mips.org/cvsweb/linux/include/asm-mips/mach-generic/ide.h" 
instead.

  Maciej

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Jack Steiner]

On Thu, Aug 11, 2005 at 03:42:07PM -0600, Bjorn Helgaas wrote:
> On Thursday 11 August 2005 2:56 pm, Jeff Garzik wrote:
> > Bjorn Helgaas wrote:
> > > On Thursday 11 August 2005 2:36 pm, Jeff Garzik wrote:
> > >>Bjorn Helgaas wrote:
> > >>> config IDE_GENERIC
> > >>> 	tristate "generic/default IDE chipset support"
> > >>>+	depends on !IA64
> > >>
> > >>hmmmmmmmmm.  Are you POSITIVE that the legacy IDE ports are never enabled?
> > >>
> > >>In modern Intel chipsets, this still occurs with e.g. combined mode.
> > > 
> > > I don't know about combined mode.  If the legacy IDE ports are
> > > enabled, shouldn't they be described via ACPI, and hence usable
> > > via the ide_pnp - PNPACPI - ACPI path?
> > 
> > No idea...  that's more for platform IA64 people to answer :/
> 
> OK, well, I assert that failure to describe an IDE device that
> uses legacy ports would be an ACPI defect.
> 
> Tony, others, does this change give you any heartburn?  On
> the 460GX and 870 boxes I have, IDE is a PCI device.
> 
> (I have been told that the SGI ia64 simulator depends on
> IDE_GENERIC.  But it really should make the IDE device
> appear in PCI (or describe it via ACPI)).

Yes - we use IDE_GENERIC for the simulator. ACPI at this point is not an option
for us because (unfortunately) SN is not ACPI compliant. We plan additional
ACPI support in the future but it will take a while to get there.

I'm checking to see if we have any short term alternatives. More later....


-- 
Thanks

Jack Steiner (steiner@sgi.com)          651-683-5302
Principal Engineer                      SGI - Silicon Graphics, Inc.

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Jack Steiner]

(resend with correct cc list).

On Thu, Aug 11, 2005 at 02:24:43PM -0600, Bjorn Helgaas wrote:
> IA64 boxes only have PCI IDE devices, so there's no need to blindly poke
> around in I/O port space.  Poking at things that don't exist causes MCAs
> on HP ia64 systems.

 Hmmmm, can you change the test so that IDE_GENERIC is off by default but
 can still be enabled on IA64. We use the generic IDE driver in our
 simulator environment - yes, it really works.

 Longer term, I'll see if it is feasible to switch to using a PCI device.

> 
> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
> 
> Index: work-vga/drivers/ide/Kconfig
> ===================================================================
> --- work-vga.orig/drivers/ide/Kconfig	2005-08-10 14:57:47.000000000 -0600
> +++ work-vga/drivers/ide/Kconfig	2005-08-10 14:58:02.000000000 -0600
> @@ -276,6 +276,7 @@
>  
>  config IDE_GENERIC
>  	tristate "generic/default IDE chipset support"
> +	depends on !IA64
>  	default y
>  	help
>  	  If unsure, say Y.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Thanks

Jack Steiner (steiner@sgi.com)          651-683-5302
Principal Engineer                      SGI - Silicon Graphics, Inc.

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Alan Cox]

On Iau, 2005-08-11 at 14:24 -0600, Bjorn Helgaas wrote:
> IA64 boxes only have PCI IDE devices, so there's no need to blindly poke
> around in I/O port space.  Poking at things that don't exist causes MCAs
> on HP ia64 systems.
> 
> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>

Nak-by: Alan Cox <alan@redhat.com>

Assuming all IA-64 boxes are PCI or better then you actually want to
edit include/asm-ia64/ide.h and edit ide_default_io_base where someone
years ago cut and pasted x86-32 values so that case 2-5 are removed.
Then you will just probe the compatibility mode PCI addresses for system
IDE channels.

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Bjorn Helgaas]

On Friday 12 August 2005 2:40 am, Alan Cox wrote:
> Assuming all IA-64 boxes are PCI or better then you actually want to
> edit include/asm-ia64/ide.h and edit ide_default_io_base where someone
> years ago cut and pasted x86-32 values so that case 2-5 are removed.
> Then you will just probe the compatibility mode PCI addresses for system
> IDE channels.

Thanks for the pointer.  There shouldn't be anything arch-
specific required for ia64, so I think we can get rid of
just about everything in asm-ia64/ide.h, since everything
we care about will be discovered by PCI IDE.

There's no ia64 reason to limit MAX_HWIFS, so I used
CONFIG_IDE_MAX_HWIFS, resulting in a little more Kconfig
ugliness.  Maybe that should move into linux/ide.h, so
arches only need to define MAX_HWIFS if they have a need
for it?

I noticed that on a box with no devices on ide1, we probed
ide1 twice -- once via ide_setup_pci_device() and again via
ide_generic_init().  This isn't fatal, since the generic probe
uses the I/O ports setup by PCI IDE, but it's unnecessary
and a bit ugly.

I stuck in a "hwif->noprobe = 1" at the point where probe_hwif()
decides the interface isn't present, which prevents the second
probe by ide_generic_init().

Other comments or advice?

Index: work-vga/drivers/ide/Kconfig
===================================================================
--- work-vga.orig/drivers/ide/Kconfig	2005-08-11 15:39:27.000000000 -0600
+++ work-vga/drivers/ide/Kconfig	2005-08-15 12:08:05.000000000 -0600
@@ -52,9 +52,9 @@
 
 if IDE
 
-config IDE_MAX_HWIFS 
+config IDE_MAX_HWIFS
 	int "Max IDE interfaces"
-	depends on ALPHA || SUPERH
+	depends on ALPHA || SUPERH || IA64
 	default 4
 	help
 	  This is the maximum number of IDE hardware interfaces that will
Index: work-vga/include/asm-ia64/ide.h
===================================================================
--- work-vga.orig/include/asm-ia64/ide.h	2005-08-03 16:48:31.000000000 -0600
+++ work-vga/include/asm-ia64/ide.h	2005-08-15 14:29:44.000000000 -0600
@@ -14,58 +14,12 @@
 #ifdef __KERNEL__
 
 #include <linux/config.h>
-
-#include <linux/irq.h>
+#include <asm-generic/ide_iops.h>
 
 #ifndef MAX_HWIFS
-# ifdef CONFIG_PCI
-#define MAX_HWIFS	10
-# else
-#define MAX_HWIFS	6
-# endif
-#endif
-
-#define IDE_ARCH_OBSOLETE_DEFAULTS
-
-static inline int ide_default_irq(unsigned long base)
-{
-	switch (base) {
-	      case 0x1f0: return isa_irq_to_vector(14);
-	      case 0x170: return isa_irq_to_vector(15);
-	      case 0x1e8: return isa_irq_to_vector(11);
-	      case 0x168: return isa_irq_to_vector(10);
-	      case 0x1e0: return isa_irq_to_vector(8);
-	      case 0x160: return isa_irq_to_vector(12);
-	      default:
-		return 0;
-	}
-}
-
-static inline unsigned long ide_default_io_base(int index)
-{
-	switch (index) {
-	      case 0: return 0x1f0;
-	      case 1: return 0x170;
-	      case 2: return 0x1e8;
-	      case 3: return 0x168;
-	      case 4: return 0x1e0;
-	      case 5: return 0x160;
-	      default:
-		return 0;
-	}
-}
-
-#define IDE_ARCH_OBSOLETE_INIT
-#define ide_default_io_ctl(base)	((base) + 0x206) /* obsolete */
-
-#ifdef CONFIG_PCI
-#define ide_init_default_irq(base)	(0)
-#else
-#define ide_init_default_irq(base)	ide_default_irq(base)
+#define MAX_HWIFS	CONFIG_IDE_MAX_HWIFS
 #endif
 
-#include <asm-generic/ide_iops.h>
-
 #endif /* __KERNEL__ */
 
 #endif /* __ASM_IA64_IDE_H */
Index: work-vga/include/linux/ide.h
===================================================================
--- work-vga.orig/include/linux/ide.h	2005-08-03 16:48:32.000000000 -0600
+++ work-vga/include/linux/ide.h	2005-08-15 12:43:38.000000000 -0600
@@ -266,7 +266,7 @@
 
 #include <asm/ide.h>
 
-/* needed on alpha, x86/x86_64, ia64, mips, ppc32 and sh */
+/* needed on alpha, x86/x86_64, mips, ppc32 and sh */
 #ifndef IDE_ARCH_OBSOLETE_DEFAULTS
 # define ide_default_io_base(index)	(0)
 # define ide_default_irq(base)		(0)
Index: work-vga/drivers/ide/ide-probe.c
===================================================================
--- work-vga.orig/drivers/ide/ide-probe.c	2005-08-09 15:09:59.000000000 -0600
+++ work-vga/drivers/ide/ide-probe.c	2005-08-15 14:30:33.000000000 -0600
@@ -852,6 +852,7 @@
 
 	if (!hwif->present) {
 		ide_hwif_release_regions(hwif);
+		hwif->noprobe = 1;
 		return;
 	}
 

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Bartlomiej Zolnierkiewicz]

Hi,

On 8/15/05, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> On Friday 12 August 2005 2:40 am, Alan Cox wrote:
> > Assuming all IA-64 boxes are PCI or better then you actually want to
> > edit include/asm-ia64/ide.h and edit ide_default_io_base where someone
> > years ago cut and pasted x86-32 values so that case 2-5 are removed.
> > Then you will just probe the compatibility mode PCI addresses for system
> > IDE channels.
> 
> Thanks for the pointer.  There shouldn't be anything arch-
> specific required for ia64, so I think we can get rid of
> just about everything in asm-ia64/ide.h, since everything
> we care about will be discovered by PCI IDE.

Agreed but I have few comments:
* is this change OK w.r.t. IA64_HP_SIM?
* removing IDE_ARCH_OBSOLETE_INIT define has some implications,
  * non-functional ide-cs driver (but there is no PCMCIA on IA64?)
  * ordering change for ide-pnp interfaces in case of no IDE devices
    on default IDE PCI ports, (but there aren't any ide-pnp devices on IA64?)
  * non-functional HDIO_REGISTER_HWIF ioctl (ain't really working either)
  are these implication fine with IA64?

> There's no ia64 reason to limit MAX_HWIFS, so I used
> CONFIG_IDE_MAX_HWIFS, resulting in a little more Kconfig
> ugliness.  Maybe that should move into linux/ide.h, so
> arches only need to define MAX_HWIFS if they have a need
> for it?

This changes default default MAX_HWIFS value from
10 (6 in case of !CONFIG_PCI) to 4 which is not desirable.

IMO the best thing for now is to leave MAX_HWIFS alone.

> I noticed that on a box with no devices on ide1, we probed
> ide1 twice -- once via ide_setup_pci_device() and again via
> ide_generic_init().  This isn't fatal, since the generic probe
> uses the I/O ports setup by PCI IDE, but it's unnecessary
> and a bit ugly.
> 
> I stuck in a "hwif->noprobe = 1" at the point where probe_hwif()
> decides the interface isn't present, which prevents the second
> probe by ide_generic_init().

Please separate this change out - it is a nice fix but it affects other
archs/drivers and somebody needs to audit all IDE host drivers that
they set hwif->noprobe = 0 correctly before probing in case of re-using
hwif that was already owned/probed by other driver.

> Other comments or advice?

Please make IDE_GENERIC depend on !IA_64.

Thanks!
Bartlomiej

> Index: work-vga/drivers/ide/Kconfig
> ===================================================================
> --- work-vga.orig/drivers/ide/Kconfig   2005-08-11 15:39:27.000000000 -0600
> +++ work-vga/drivers/ide/Kconfig        2005-08-15 12:08:05.000000000 -0600
> @@ -52,9 +52,9 @@
> 
>  if IDE
> 
> -config IDE_MAX_HWIFS
> +config IDE_MAX_HWIFS
>         int "Max IDE interfaces"
> -       depends on ALPHA || SUPERH
> +       depends on ALPHA || SUPERH || IA64
>         default 4
>         help
>           This is the maximum number of IDE hardware interfaces that will
> Index: work-vga/include/asm-ia64/ide.h
> ===================================================================
> --- work-vga.orig/include/asm-ia64/ide.h        2005-08-03 16:48:31.000000000 -0600
> +++ work-vga/include/asm-ia64/ide.h     2005-08-15 14:29:44.000000000 -0600
> @@ -14,58 +14,12 @@
>  #ifdef __KERNEL__
> 
>  #include <linux/config.h>
> -
> -#include <linux/irq.h>
> +#include <asm-generic/ide_iops.h>
> 
>  #ifndef MAX_HWIFS
> -# ifdef CONFIG_PCI
> -#define MAX_HWIFS      10
> -# else
> -#define MAX_HWIFS      6
> -# endif
> -#endif
> -
> -#define IDE_ARCH_OBSOLETE_DEFAULTS
> -
> -static inline int ide_default_irq(unsigned long base)
> -{
> -       switch (base) {
> -             case 0x1f0: return isa_irq_to_vector(14);
> -             case 0x170: return isa_irq_to_vector(15);
> -             case 0x1e8: return isa_irq_to_vector(11);
> -             case 0x168: return isa_irq_to_vector(10);
> -             case 0x1e0: return isa_irq_to_vector(8);
> -             case 0x160: return isa_irq_to_vector(12);
> -             default:
> -               return 0;
> -       }
> -}
> -
> -static inline unsigned long ide_default_io_base(int index)
> -{
> -       switch (index) {
> -             case 0: return 0x1f0;
> -             case 1: return 0x170;
> -             case 2: return 0x1e8;
> -             case 3: return 0x168;
> -             case 4: return 0x1e0;
> -             case 5: return 0x160;
> -             default:
> -               return 0;
> -       }
> -}
> -
> -#define IDE_ARCH_OBSOLETE_INIT
> -#define ide_default_io_ctl(base)       ((base) + 0x206) /* obsolete */
> -
> -#ifdef CONFIG_PCI
> -#define ide_init_default_irq(base)     (0)
> -#else
> -#define ide_init_default_irq(base)     ide_default_irq(base)
> +#define MAX_HWIFS      CONFIG_IDE_MAX_HWIFS
>  #endif
> 
> -#include <asm-generic/ide_iops.h>
> -
>  #endif /* __KERNEL__ */
> 
>  #endif /* __ASM_IA64_IDE_H */
> Index: work-vga/include/linux/ide.h
> ===================================================================
> --- work-vga.orig/include/linux/ide.h   2005-08-03 16:48:32.000000000 -0600
> +++ work-vga/include/linux/ide.h        2005-08-15 12:43:38.000000000 -0600
> @@ -266,7 +266,7 @@
> 
>  #include <asm/ide.h>
> 
> -/* needed on alpha, x86/x86_64, ia64, mips, ppc32 and sh */
> +/* needed on alpha, x86/x86_64, mips, ppc32 and sh */
>  #ifndef IDE_ARCH_OBSOLETE_DEFAULTS
>  # define ide_default_io_base(index)    (0)
>  # define ide_default_irq(base)         (0)
> Index: work-vga/drivers/ide/ide-probe.c
> ===================================================================
> --- work-vga.orig/drivers/ide/ide-probe.c       2005-08-09 15:09:59.000000000 -0600
> +++ work-vga/drivers/ide/ide-probe.c    2005-08-15 14:30:33.000000000 -0600
> @@ -852,6 +852,7 @@
> 
>         if (!hwif->present) {
>                 ide_hwif_release_regions(hwif);
> +               hwif->noprobe = 1;
>                 return;
>         }

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Bartlomiej Zolnierkiewicz]

On 8/16/05, Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> Hi,
> 
> On 8/15/05, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> > On Friday 12 August 2005 2:40 am, Alan Cox wrote:
> > > Assuming all IA-64 boxes are PCI or better then you actually want to
> > > edit include/asm-ia64/ide.h and edit ide_default_io_base where someone
> > > years ago cut and pasted x86-32 values so that case 2-5 are removed.
> > > Then you will just probe the compatibility mode PCI addresses for system
> > > IDE channels.
> >
> > Thanks for the pointer.  There shouldn't be anything arch-
> > specific required for ia64, so I think we can get rid of
> > just about everything in asm-ia64/ide.h, since everything
> > we care about will be discovered by PCI IDE.
> 
> Agreed but I have few comments:
> * is this change OK w.r.t. IA64_HP_SIM?
> * removing IDE_ARCH_OBSOLETE_INIT define has some implications,
>   * non-functional ide-cs driver (but there is no PCMCIA on IA64?)
>   * ordering change for ide-pnp interfaces in case of no IDE devices
>     on default IDE PCI ports, (but there aren't any ide-pnp devices on IA64?)
>   * non-functional HDIO_REGISTER_HWIF ioctl (ain't really working either)

sorry, should be HDIO_SCAN_HWIF

>   are these implication fine with IA64?

One more thing, if some IDE PCI devices are used on IA64 in compatibility mode
you need to fix the host driver to set hwif->irq since
ide_default_irq() is gone now
(I think especially about piix.c and #ifndef/#endif CONFIG_IA64 that
it contains).

> > Other comments or advice?
> 
> Please make IDE_GENERIC depend on !IA_64.

!IA64 of course

Bartlomiej

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Alan Cox]

On Maw, 2005-08-16 at 11:38 +0200, Bartlomiej Zolnierkiewicz wrote:
> * removing IDE_ARCH_OBSOLETE_INIT define has some implications,
>   * non-functional ide-cs driver (but there is no PCMCIA on IA64?)

IA64 systems can support PCI->Cardbus/PCMCIA cards so they do actually
need this support. They could also do with cardbus IDE support but that
means a whole pile of patches still although the refcounting stuff means
its a lot closer to doable now

>   * ordering change for ide-pnp interfaces in case of no IDE devices
>     on default IDE PCI ports, (but there aren't any ide-pnp devices on IA64?)

No ISAPnP

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Bartlomiej Zolnierkiewicz]

On 8/16/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Maw, 2005-08-16 at 11:38 +0200, Bartlomiej Zolnierkiewicz wrote:
> > * removing IDE_ARCH_OBSOLETE_INIT define has some implications,
> >   * non-functional ide-cs driver (but there is no PCMCIA on IA64?)
> 
> IA64 systems can support PCI->Cardbus/PCMCIA cards so they do actually
> need this support. They could also do with cardbus IDE support but that
> means a whole pile of patches still although the refcounting stuff means
> its a lot closer to doable now

Therefore we need to fix ide-cs driver first to get rid of ide_init_hwif_ports()
which should be trivial unless some PPC32 specific hooks need it
(ide_ppc_md.ide_init_hwif).

> >   * ordering change for ide-pnp interfaces in case of no IDE devices
> >     on default IDE PCI ports, (but there aren't any ide-pnp devices on IA64?)
> 
> No ISAPnP

Excellent!

Bartlomiej

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Matthew Wilcox]

On Tue, Aug 16, 2005 at 01:55:58PM +0100, Alan Cox wrote:
> On Maw, 2005-08-16 at 11:38 +0200, Bartlomiej Zolnierkiewicz wrote:
> > * removing IDE_ARCH_OBSOLETE_INIT define has some implications,
> >   * non-functional ide-cs driver (but there is no PCMCIA on IA64?)
> 
> IA64 systems can support PCI->Cardbus/PCMCIA cards so they do actually
> need this support. They could also do with cardbus IDE support but that
> means a whole pile of patches still although the refcounting stuff means
> its a lot closer to doable now

Then IDE_ARCH_OBSOLETE_INIT needs to be added back for all other
architectures that support PCI too ...

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Bartlomiej Zolnierkiewicz]

On 8/16/05, Matthew Wilcox <matthew@wil.cx> wrote:
> On Tue, Aug 16, 2005 at 01:55:58PM +0100, Alan Cox wrote:
> > On Maw, 2005-08-16 at 11:38 +0200, Bartlomiej Zolnierkiewicz wrote:
> > > * removing IDE_ARCH_OBSOLETE_INIT define has some implications,
> > >   * non-functional ide-cs driver (but there is no PCMCIA on IA64?)
> >
> > IA64 systems can support PCI->Cardbus/PCMCIA cards so they do actually
> > need this support. They could also do with cardbus IDE support but that
> > means a whole pile of patches still although the refcounting stuff means
> > its a lot closer to doable now
> 
> Then IDE_ARCH_OBSOLETE_INIT needs to be added back for all other
> architectures that support PCI too ...

Rather ide-cs needs to be fixed to use ide_std_init_ports() instead of
ide_init_hwif_ports() (please see my reply to Alan).

Bartlomiej

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Bjorn Helgaas]

On Tuesday 16 August 2005 3:38 am, Bartlomiej Zolnierkiewicz wrote:
> On 8/15/05, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> > On Friday 12 August 2005 2:40 am, Alan Cox wrote:
> Agreed but I have few comments:
> * is this change OK w.r.t. IA64_HP_SIM?

Kernels for the HP simulator (ski) use a SCSI model, not IDE,
so they should be OK.

The SGI simulator *does* use IDE, and this will break that.  But
my friends at SGI are looking at exposing the simulated IDE device
via PCI, which should fix it.

> * removing IDE_ARCH_OBSOLETE_INIT define has some implications,
>   * non-functional ide-cs driver (but there is no PCMCIA on IA64?)

PCMCIA might be of theoretical interest, but not important enough
by itself to keep IDE_ARCH_OBSOLETE_INIT, IMHO.  And it sounds like
ide-cs can be fixed fairly easily to not depend on it.

>   * ordering change for ide-pnp interfaces in case of no IDE devices
>     on default IDE PCI ports, (but there aren't any ide-pnp devices on IA64?)

I'm not aware of any ide-pnp devices on IA64, so I don't think this
is a problem for us.  The SGI simulator could use ide-pnp via
PNPACPI, but ordering shouldn't be a problem there.

But it is interesting that PNP IDE devices are discovered *after*
PCI devices.  For serial, we do PNP before PCI, on the theory that
PNP devices are usually built-in and shouldn't move if you just plug
in a new PCI card.

>   * non-functional HDIO_REGISTER_HWIF ioctl (ain't really working either)

HDIO_SCAN_HWIF - I don't know about this one.  How are we supposed to
follow the "new ports shouldn't define IDE_ARCH_OBSOLETE_INIT" injunction
if we lose all this functionality without it?  ia64 is about as close to
a new port as you get :-)

> This changes default default MAX_HWIFS value from
> 10 (6 in case of !CONFIG_PCI) to 4 which is not desirable.
> 
> IMO the best thing for now is to leave MAX_HWIFS alone.

IDE on ia64 is little-used, so I'm OK with leaving it alone, but
I do think it's wrong for an architecture with no real restriction
to specify MAX_HWIFS in ide.h.  Better to have the config option,
and make the default there larger if necessary.

> > I noticed that on a box with no devices on ide1, we probed
> > ide1 twice -- once via ide_setup_pci_device() and again via
> > ide_generic_init().  This isn't fatal, since the generic probe
> > uses the I/O ports setup by PCI IDE, but it's unnecessary
> > and a bit ugly.
> > 
> > I stuck in a "hwif->noprobe = 1" at the point where probe_hwif()
> > decides the interface isn't present, which prevents the second
> > probe by ide_generic_init().
> 
> Please separate this change out - it is a nice fix but it affects other
> archs/drivers and somebody needs to audit all IDE host drivers that
> they set hwif->noprobe = 0 correctly before probing in case of re-using
> hwif that was already owned/probed by other driver.

OK, I'll split this and look into it a bit more.

> Please make IDE_GENERIC depend on !IA_64.

Huh?  The first patch I posted did exactly that, nothing more.  But
Alan pointed out that I should instead clean up asm-ia64/ide.h, which
I think leads to a nicer solution.

Thanks for the detailed comments!

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Bartlomiej Zolnierkiewicz]

On 8/16/05, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> On Tuesday 16 August 2005 3:38 am, Bartlomiej Zolnierkiewicz wrote:
> > On 8/15/05, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> > > On Friday 12 August 2005 2:40 am, Alan Cox wrote:
> > Agreed but I have few comments:
> > * is this change OK w.r.t. IA64_HP_SIM?
> 
> Kernels for the HP simulator (ski) use a SCSI model, not IDE,
> so they should be OK.
> 
> The SGI simulator *does* use IDE, and this will break that.  But
> my friends at SGI are looking at exposing the simulated IDE device
> via PCI, which should fix it.

OK

> > * removing IDE_ARCH_OBSOLETE_INIT define has some implications,
> >   * non-functional ide-cs driver (but there is no PCMCIA on IA64?)
> 
> PCMCIA might be of theoretical interest, but not important enough
> by itself to keep IDE_ARCH_OBSOLETE_INIT, IMHO.  And it sounds like
> ide-cs can be fixed fairly easily to not depend on it.

Yes, ide-cs needs fixing anyway.

> >   * ordering change for ide-pnp interfaces in case of no IDE devices
> >     on default IDE PCI ports, (but there aren't any ide-pnp devices on IA64?)
> 
> I'm not aware of any ide-pnp devices on IA64, so I don't think this
> is a problem for us.  The SGI simulator could use ide-pnp via
> PNPACPI, but ordering shouldn't be a problem there.

OK

> But it is interesting that PNP IDE devices are discovered *after*
> PCI devices.  For serial, we do PNP before PCI, on the theory that
> PNP devices are usually built-in and shouldn't move if you just plug
> in a new PCI card.
> 
> >   * non-functional HDIO_REGISTER_HWIF ioctl (ain't really working either)
> 
> HDIO_SCAN_HWIF - I don't know about this one.  How are we supposed to
> follow the "new ports shouldn't define IDE_ARCH_OBSOLETE_INIT" injunction
> if we lose all this functionality without it?  ia64 is about as close to
> a new port as you get :-)

* new legacy style interfaces cannot be registered from user-space
  (but they still can be using kernel parameter)
* non-working coldplug support
  (I'm working on sysfs interface for that)

> > This changes default default MAX_HWIFS value from
> > 10 (6 in case of !CONFIG_PCI) to 4 which is not desirable.
> >
> > IMO the best thing for now is to leave MAX_HWIFS alone.
> 
> IDE on ia64 is little-used, so I'm OK with leaving it alone, but
> I do think it's wrong for an architecture with no real restriction
> to specify MAX_HWIFS in ide.h.  Better to have the config option,
> and make the default there larger if necessary.
> 
> > > I noticed that on a box with no devices on ide1, we probed
> > > ide1 twice -- once via ide_setup_pci_device() and again via
> > > ide_generic_init().  This isn't fatal, since the generic probe
> > > uses the I/O ports setup by PCI IDE, but it's unnecessary
> > > and a bit ugly.
> > >
> > > I stuck in a "hwif->noprobe = 1" at the point where probe_hwif()
> > > decides the interface isn't present, which prevents the second
> > > probe by ide_generic_init().
> >
> > Please separate this change out - it is a nice fix but it affects other
> > archs/drivers and somebody needs to audit all IDE host drivers that
> > they set hwif->noprobe = 0 correctly before probing in case of re-using
> > hwif that was already owned/probed by other driver.
> 
> OK, I'll split this and look into it a bit more.

Thanks.

> > Please make IDE_GENERIC depend on !IA_64.
> 
> Huh?  The first patch I posted did exactly that, nothing more.  But
> Alan pointed out that I should instead clean up asm-ia64/ide.h, which
> I think leads to a nicer solution.

Both changes are nice :-)

Thanks,
Bartlomiej

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Alan Cox]

> >   * non-functional HDIO_REGISTER_HWIF ioctl (ain't really working either)
> 
> HDIO_SCAN_HWIF - I don't know about this one.  How are we supposed to
> follow the "new ports shouldn't define IDE_ARCH_OBSOLETE_INIT" injunction
> if we lose all this functionality without it?  ia64 is about as close to
> a new port as you get :-)

It allows you to register interfaces from user space.

As to IDE_ARCH_OBOSOLETE_INIT, its a red herring. It's not worth the
trouble to avoid it given the expected short remaining life time of the
old IDE layer. Far better would be to help get the new SATA layer doing
PATA so drivers/ide can be deleted.

> IDE on ia64 is little-used, so I'm OK with leaving it alone, but
> I do think it's wrong for an architecture with no real restriction
> to specify MAX_HWIFS in ide.h.  Better to have the config option,
> and make the default there larger if necessary.

In the ideal world - its a historical inheritance that its not dynamic -
you probably should set it to 10 though - just for plug in IDE cards.

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Bartlomiej Zolnierkiewicz]

On 8/16/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > >   * non-functional HDIO_REGISTER_HWIF ioctl (ain't really working either)
> >
> > HDIO_SCAN_HWIF - I don't know about this one.  How are we supposed to
> > follow the "new ports shouldn't define IDE_ARCH_OBSOLETE_INIT" injunction
> > if we lose all this functionality without it?  ia64 is about as close to
> > a new port as you get :-)
> 
> It allows you to register interfaces from user space.
> 
> As to IDE_ARCH_OBOSOLETE_INIT, its a red herring. It's not worth the
> trouble to avoid it given the expected short remaining life time of the
> old IDE layer. Far better would be to help get the new SATA layer doing
> PATA so drivers/ide can be deleted.

My opinion on this matter differ, I want to:
* finish rewriting IDE code
* deprecate crap
* (later) drop crap and merge rest with libata

I will write precised TODO (w/ status) soon.

IMO this is much better solution as:
* you go from working code into small steps (evolution)
* you don't have to maintain both libata and IDE driver
   for X years (deleting drivers/ide anytime soon is a pipedream)
* as IDE becomes less popular testing gets harder
  (especially when developing new code - you don't
   have previous state)
* it shouldn't be that hard - I have many parts of the stuff
  done (they need some polishing)

Bjorn, thanks for working on this, IDE_ARCH_OBSOLETE_INIT
( -> ide_init_hwif_ports() ) needs to be fixed in order to make REAL
improvements.

Bartlomiej

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Alan Cox]

On Maw, 2005-08-16 at 22:42 +0200, Bartlomiej Zolnierkiewicz wrote:
> IMO this is much better solution as:
> * you go from working code into small steps (evolution)

If there was working code to go from maybe. The IDE core code is far too
broken for that to be the case. The drivers are different matter
although the driver API is fundamentally flawed because it handles speed
changing in a synchronous manner.

> * it shouldn't be that hard - I have many parts of the stuff
>   done (they need some polishing)

Fair enough. Be good to see the core IDE get better whichever path

RE: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Luck, Tony]

>Tony, others, does this change give you any heartburn?  On
>the 460GX and 870 boxes I have, IDE is a PCI device.

No heartburn for me ... as you say IDE is built into one
of the 870 chips.

I don't know whether any non-Intel chipsets provide legacy IDE.

-Tony

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Jeff Garzik]

Luck, Tony wrote:
>>Tony, others, does this change give you any heartburn?  On
>>the 460GX and 870 boxes I have, IDE is a PCI device.
> 
> 
> No heartburn for me ... as you say IDE is built into one
> of the 870 chips.
> 
> I don't know whether any non-Intel chipsets provide legacy IDE.

The question is not about ISA IDE, but more about the PCI IDE 
specification...  See the PCI IDE examples in my other emails.

	Jeff