Hello.

Alan wrote:

quoted

quoted

Both PCI core and IDE interpret a zero length resource as unassigned.

quoted

  This is not about 0-length resource, this is about 0-address. Look at 
ide_hwif_confiure() in drivers/ide/setup-pci.c...

The discussion I was having was about sl82cxx and handling unassigned
resources. The zero address isn't relevant to that.

    You were following up to the particular error message emitted by the IDE 
core (which you've now deleted), so I corrected you on its reason, that's all.

quoted

   You should know that the IRQ assumption is *not* true even for x86 since 
IRQ0 is and has always been a perfectly valid IRQ (used by PIT).

Please see previous million recyclings of that discussion and Linus
answer.

    When Linus remaps IRQ0 on x86, I'll follow that code as a testament. Until 
this happens, I consider is just an opinion. Forcing every arch but x86 to 
remap IRQ0 is an example of the double standards.

quoted

quoted

Stick a real IDE resource at zero

quoted

quoted

and drivers/ide can't cope.

quoted

   Yeah, I've noticed. Unfortunately, a lot of PPC platforms (at least) are 
doing exactly this...

The checks need pushing upwards and removing from their current place -
the pci layer should check the resource length, the isa pnp should I
believe check for zero address etc.

    So, it's OK to remove the base *address* check in ide_hwif_confiure() 
altogether?

libata makes a similar assumption in ata_resources_present() as someone
(GregKH ???) needs to define what the proper way to encode "resource not
allocated" into the PCI resources should be.

If someone on the PCI list (cc'd) or Greg can give a definitive answer then we can go fix the
offenders now.

    Well, I thought that was IORESOURCE_UNSET...

Alan

WBR, Sergei