Messages in this thread |  | | From | David Hinds <> | Subject | Re: 1.99.14 & duplicate NE2000 | Date | Sun, 9 Jun 1996 16:31:14 -0700 (PDT) |
| |
> The "reserve=" doesn't do any magic. It just puts a dummy entry (a > placeholder) into the ioport table, which will block all auto-probes > that do a check_region(0x300,0x?). When the ether probe comes up, it > sees that it has a specific i/o given to it, and skips the > check_region() call (this is called "trusting the operator to do > sane things") -- By skipping the check, it doesn't get blocked by > the dummy ioport table entry, and instead overwrites the reserve > ioport entry with its own ioport entry.
Ummm, I don't think this is how request_region() works. A second call to request_region() for an already-allocated region will silently fail: it will not replace the old entry with the new one.
I think it would probably be a good idea for request_region() to return a success/failure indication. I wonder why it doesn't, but I wrote it a long time ago and don't remember what I was thinking at the time. Maybe I did it that way to be compatible with its predecessor, snarf_region().
I had thought that the meaning of "reserve=" was to tell the system to avoid probing for *anything* at certain addresses... like, it was saying that certain addresses specified devices unknown to Linux. But I was just rewriting what was already there, not making it up from scratch. I think if a reserved entry should be replaced as Paul suggests, then there should be a specific test for this situation, so that regions allocated by other drivers cannot be replaced this way.
-- Dave Hinds dhinds@hyper.stanford.edu
|  |