lkml.org 
[lkml]   [1996]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: 1.99.14 & duplicate NE2000
Date
> 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


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.062 / U:4.808 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site