Yesterday I muttered that 2.6.9 had a mouse problem, and soon
afterwards I also noticed that my ADSL didnt work.
I just looked at what was wrong, and the reason turns out to be
a correct fix in the pc110pad_init() call of request_region().
Before 2.6.9 the test there was wrong, so that the region was
seen as unavailable and pc110pad.c did not do anything.
In 2.6.9 the test is correct, the region and irq are reserved and my
ethernet card can no longer reserve its irq and ADSL fails.
Moreover, now pc110pad.c does I/O causing my mouse problems.
Easy solution: CONFIG_MOUSE_PC110PAD=n
I write this in some detail in the hope that this inspires somebody
to figure out whether it is possible to probe & detect this PC110.
Andries
On Sun, 7 Nov 2004, Andries Brouwer wrote:
>
> Yesterday I muttered that 2.6.9 had a mouse problem, and soon
> afterwards I also noticed that my ADSL didnt work.
>
> I just looked at what was wrong, and the reason turns out to be
> a correct fix in the pc110pad_init() call of request_region().
>
> Before 2.6.9 the test there was wrong, so that the region was
> seen as unavailable and pc110pad.c did not do anything.
>
> In 2.6.9 the test is correct, the region and irq are reserved and my
> ethernet card can no longer reserve its irq and ADSL fails.
> Moreover, now pc110pad.c does I/O causing my mouse problems.
>
> Easy solution: CONFIG_MOUSE_PC110PAD=n
>
> I write this in some detail in the hope that this inspires somebody
> to figure out whether it is possible to probe & detect this PC110.
Ahh.. Interesting. One improvement might be to make sure that this driver
links in very late in the game, so that if any other drivers have
allocated the IO, at least it won't override that. Also, it might make
sense to say that the dang thing can share interrupts.
But yes, we should probably make sure to make it harder to enable the
driver by mistake, and try to do minimal probing of it. I have no idea how
to probe for the thing, though.
Alan, Vojtech, do you have any register information on this thing? Some
docs to try to realize when it's not there? Or some other way to detect
the IBM PC110 hardware (BIOS strings, something?)
Linus
On Sad, 2004-11-06 at 23:37, Linus Torvalds wrote:
> Ahh.. Interesting. One improvement might be to make sure that this driver
> links in very late in the game, so that if any other drivers have
> allocated the IO, at least it won't override that. Also, it might make
> sense to say that the dang thing can share interrupts.
It can't share interrupts.
> But yes, we should probably make sure to make it harder to enable the
> driver by mistake, and try to do minimal probing of it. I have no idea how
> to probe for the thing, though.
I never found anything.
> Alan, Vojtech, do you have any register information on this thing? Some
> docs to try to realize when it's not there? Or some other way to detect
> the IBM PC110 hardware (BIOS strings, something?)
I have some register info, the driver is done by disassembly of the
PC-DOS
driver IBM shipped with the PC110. It's a pre pci, pre dmi machine so
there aren't any obvious sane ways to probe. Its not something you'd
want to build
in as opposed to modular on any other system but the PC110
On Sun, 7 Nov 2004, Alan Cox wrote:
>
> On Sad, 2004-11-06 at 23:37, Linus Torvalds wrote:
> > Ahh.. Interesting. One improvement might be to make sure that this driver
> > links in very late in the game, so that if any other drivers have
> > allocated the IO, at least it won't override that. Also, it might make
> > sense to say that the dang thing can share interrupts.
>
> It can't share interrupts.
Not if it's there, no. But if the hardware doesn't actually exist on the
machine, and you can't probe for it, it may be better to say "hey, I'll
share interrupts, because I don't know if I actually exist or not" ;)
> > But yes, we should probably make sure to make it harder to enable the
> > driver by mistake, and try to do minimal probing of it. I have no idea how
> > to probe for the thing, though.
>
> I never found anything.
>
> > Alan, Vojtech, do you have any register information on this thing? Some
> > docs to try to realize when it's not there? Or some other way to detect
> > the IBM PC110 hardware (BIOS strings, something?)
>
> I have some register info, the driver is done by disassembly of the
> PC-DOS
> driver IBM shipped with the PC110. It's a pre pci, pre dmi machine so
> there aren't any obvious sane ways to probe. Its not something you'd
> want to build in as opposed to modular on any other system but the PC110
Well, that actually _is_ something we can probe for: "does this machine
have PCI".
IOW, we could have a trivial "if the list of PCI devices is non-empty,
then return immediately" kind of thing, no?
That would mean that (pretty much) anybody loading that driver by mistake
wouldn't get into trouble.
Linus
On Sul, 2004-11-07 at 02:57, Linus Torvalds wrote:
> > driver IBM shipped with the PC110. It's a pre pci, pre dmi machine so
> > there aren't any obvious sane ways to probe. Its not something you'd
> > want to build in as opposed to modular on any other system but the PC110
>
> Well, that actually _is_ something we can probe for: "does this machine
> have PCI".
>
> IOW, we could have a trivial "if the list of PCI devices is non-empty,
> then return immediately" kind of thing, no?
Works for me
On Sun, 7 Nov 2004, Alan Cox wrote:
>
> Works for me
Do you still have the hw somewhere? Does this patch look sane? It compiles
for me, and if CONFIG_PCI isn't enabled the thing should still DTRT (ie
the code all just goes away), but still..
Andries, does this fix your machine with this drievr enabled?
Linus
-----
===== drivers/input/mouse/pc110pad.c 1.10 vs edited =====
--- 1.10/drivers/input/mouse/pc110pad.c 2004-10-09 14:13:56 -07:00
+++ edited/drivers/input/mouse/pc110pad.c 2004-11-07 10:35:45 -08:00
@@ -38,6 +38,7 @@
#include <linux/input.h>
#include <linux/init.h>
#include <linux/interrupt.h>
+#include <linux/pci.h>
#include <asm/io.h>
#include <asm/irq.h>
@@ -107,8 +108,22 @@
return 0;
}
+/*
+ * We try to avoid enabling the hardware if it's not
+ * there, but we don't know how to test. But we do know
+ * that the PC110 is not a PCI system. So if we find any
+ * PCI devices in the machine, we don't have a PC110.
+ */
static int __init pc110pad_init(void)
{
+ struct pci_dev *dev;
+
+ dev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, NULL);
+ if (dev) {
+ pci_dev_put(dev);
+ return -ENOENT;
+ }
+
if (!request_region(pc110pad_io, 4, "pc110pad")) {
printk(KERN_ERR "pc110pad: I/O area %#x-%#x in use.\n",
pc110pad_io, pc110pad_io + 4);
On Sun, Nov 07, 2004 at 10:38:53AM -0800, Linus Torvalds wrote:
> Andries, does this fix your machine with this driver enabled?
Yes, it does.
Andries
On Sul, 2004-11-07 at 18:38, Linus Torvalds wrote:
> Do you still have the hw somewhere? Does this patch look sane? It compiles
I do and it does
Hi!
> > Ahh.. Interesting. One improvement might be to make sure that this driver
> > links in very late in the game, so that if any other drivers have
> > allocated the IO, at least it won't override that. Also, it might make
> > sense to say that the dang thing can share interrupts.
>
> It can't share interrupts.
>
> > But yes, we should probably make sure to make it harder to enable the
> > driver by mistake, and try to do minimal probing of it. I have no idea how
> > to probe for the thing, though.
>
> I never found anything.
Perhaps disable the driver is machine is not intel 486?
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!