Re: standard_io_resources[]

[Andrzej Krzysztofowicz <ankry@pg.gda.pl>]

"Tomasz Sterna wrote:"
> I couldn't find a maintainer of the code, so I'm writing here.
> 
> In kernel 2.4.1 in arch/i386/kernel/setup.c there is:
> 
> --- arch/i386/kernel/setup.c
> struct resource standard_io_resources[] = {
>         { "dma1", 0x00, 0x1f, IORESOURCE_BUSY },
>         { "pic1", 0x20, 0x3f, IORESOURCE_BUSY },
>         { "timer", 0x40, 0x5f, IORESOURCE_BUSY },
>         { "keyboard", 0x60, 0x6f, IORESOURCE_BUSY },
>         { "dma page reg", 0x80, 0x8f, IORESOURCE_BUSY },
>         { "pic2", 0xa0, 0xbf, IORESOURCE_BUSY },
>         { "dma2", 0xc0, 0xdf, IORESOURCE_BUSY },
>         { "fpu", 0xf0, 0xff, IORESOURCE_BUSY }
> };
> ---
> 
> which fix-allocate some io-resources.
> What is the reason for that?
> Isn't that a job of the device drivers?
> 
> In KGI we have our own keyboard driver which tries to allocate the 
> kayboard I/O range for itself, and when it does io_check_region() it 
> fails. What should I do?

There are more problems. Eg. ali14xx (old IDE interface, mostly used on
i486-bazed systems) sometimes uses 0x074, 0x0f4 or 0x034 ports for IDE
configuration. It cannot be evidenced as all the ports mentioned here are
claimed to be used by other subsystem.

But there's another problem here: probing port 0x34 on Intel VX/HX/TX/LX/BX
chipset based systems causes system hang (interrupts are masked) as these
chipsets do not completely decode 0x34 I/O address (ie. 0x34 == 0x20 for
them)

So, the ports are used in some hardware configurations, are not used (some
of them) in others. But there is no simple way to distinguish these cases.
:(

-- 
=======================================================================
  Andrzej M. Krzysztofowicz               ankry@mif.pg.gda.pl
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Technical University of Gdansk