On Sun, 31 Jul 2005, Manuel Lauss wrote:
>
> Linus Torvalds wrote:
>
> >
> > - The SonyPI driver just allocates IO regions in random areas. It's got a
> > list of places to try allocating in, and the 1080 area just happens to
> > be the first on the list, and since it's not used by anything else, it
> > succeeds (never mind that it's on totally the wrong bus).
>
> On three different intel-vaios, I've seen the sonypi device always
> located at ioport 0x1080. Even the windows driver on these models
> always allocates the 0x1080-0x109f io-range for it.
I think that's how the Linux driver IO list was gathered - looking at
where it tends to sit by default.
And the thing is, that would actually be ok too (as I sent in a separate
email to Stelian later) - if the BIOS actually sets it up at 1080, we
could easily just make a PCI quirk that marks that region _early_ in the
bootup sequence as being reserved for SonyPI. That would make any later
PCI allocation requests know to avoid it.
The problem with the current setup is that the SonyPI driver is a
perfectly regular driver, and thus obviously loads _after_ a number of
other drivers, and the PCI setup code in particular. So what has happened
is that we've set up other PCI IO regious without knowing - or caring -
about the SonyPI driver, and then the SonyPI driver comes along and says
"oh, btw, I want that region".
And _that_ cannot work reliably. If you have a specific pre-allocated
region that you want (or must have - some regions are fixed because of
things like ACPI tables or SMM etc that depend on them), then you need to
tell the world about it _before_ it starts allocating anything else,
because otherwise the allocation routines obviously cannot know about that
fixed thing.
So what the sonypi driver does now is wrong, but there are two choices to
do it right: tell the PCI subsystem early (traditionally done as a PCI
quirk in drivers/pci/quirks.c, but you could possibly also make it as a
driver-specific "subsys_initcall()" - but only if your driver is always
compiled in, which sonypi isn't), or then allocate it nicely later.
It's the combination of the two that is bad: "just tell somebody later"
doesn't work. They may say that it's easier to get forgiveness than ask
for permission, but that's not true in kernels. Because if you do
something wrong, the device simply won't _work_, which is exactly what
happened here ;).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
