Re: [PATCH] Request only really used I/O ports in w83627hf driver

[Jean Delvare <khali@linux-fr.org>]

Hi Petr,

> my motherboard (Tyan S2885) reports range 295-296 in its PNP hardware
> descriptors, and due to this w83627hf driver fails to load, as it
> requests 290-297 range, which is not subrange of this PNP resource. 
> As hardware monitor chip responds to 295/296 addresses only, there is
> no reason to request full 8 byte I/O.

Another point of view would be: as the physical address of the chip is
0x290-0x297, there is no reason to even think of requesting a different
range. And there is a very valid reason to request the full 8 byte I/O
range: to let the user know that this range is not available for other
devices. Mapping another device to the unused I/O ports of the W83627HF
would not work, right? Also consider that future chips of this family
could use additional ports.

The cause of your trouble is, IMVHO, a buggy BIOS. Ask Tyan to fix their
BIOS to allocate the real I/O range to the W83627HF chip, and you're
done.

http://bugzilla.kernel.org/show_bug.cgi?id=4014

Your fix might come in handy for your own situation, but it looks wrong
in the long run. We are not going to shrink the requested I/O range of
every random driver each time a motherboard manufacturer releases a
buggy BIOS.

If getting the manufacturers to provide fixed BIOSes doesn't seem to be
feasable, then the PNPACPI code certainly needs to be extended to handle
this case transparently. This could be achived using quirks similar to
what we have for PCI, or PNPACPI could simply accept requests of I/O
ranges which include a single PNP range as defined by the BIOS. Note
that everything was working just fine for everyone before PNPACPI was
added to the kernel.

> While I was doing that, I also changed W83781D_*_REG_OFFSET definitions
> from 5/6 to 0/1.  Code is a bit smaller after doing that, and it looks
> better now since we do not allocate full 8 byte range.

I find this change rather confusing myself, and it makes the code
bigger, not smaller.

-- 
Jean Delvare