From: James Bottomley <James.Bottomley@steeleye.com>
To: linux-kernel@vger.kernel.org
Cc: alan@lxorguk.ukuu.org.uk, mochel@osdl.org
Subject: Re: PnP Model
Date: 03 Feb 2003 10:31:53 -0500 [thread overview]
Message-ID: <1044286316.1777.30.camel@mulgrave> (raw)
> I agree. A lot of drivers should be able to use one model for
> everything including "enable_device" stuff. Right not its all a bit
> too detailed
Actually, while we're on the subject of PnP-ISA, I was wondering if we
could also migrate straight ISA to the device model probing (The 3c509
now looks a bit of a mess because it's got probes for EISA and MCA,
needs probes for PNP-ISA and still has to use Space.c for ISA).
If we just had a bus matching function that always matched and the
device probe would do its usual port etc. probe and return success if it
found a device or fail if it didn't, that would move ISA over reasonably
effectively. The only nasty is multiple cards: here the probe routine
would have to detect the extra cards, allocate struct devices for them
and then catch them again when they come back in through the driver
probe routine (this will work today because all probes are single
threaded on the bus semaphore, obviously it will fail if probes ever
become multi-threaded).
The last issue is probably that we'd like the ISA probes to be run after
all the rest of the busses so that all resources in use in the system
have a good chance of being claimed and the ISA memory poking should
have the least potential for doing damage---this would require a change
in the way the device model works, I think, wouldn't it?
James
next reply other threads:[~2003-02-03 15:22 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-03 15:31 James Bottomley [this message]
2003-02-03 16:41 ` PnP Model Alan Cox
2003-02-04 16:45 ` James Bottomley
-- strict thread matches above, loose matches on Subject: below --
2003-02-04 19:53 PnP model Grover, Andrew
2003-02-04 22:56 ` Alan Cox
2003-02-06 18:49 ` Adam Belay
2003-02-04 19:25 Grover, Andrew
2003-02-04 19:40 ` John Bradford
2003-02-02 20:36 [PATCH][RFC] Resource Management Improvements (1/4) Adam Belay
2003-02-03 13:55 ` PnP model Jaroslav Kysela
2003-02-03 15:45 ` Alan Cox
2003-02-03 20:43 ` Adam Belay
2003-02-04 9:46 ` Russell King
2003-02-04 10:18 ` Jaroslav Kysela
2003-02-04 10:49 ` Russell King
2003-02-05 21:34 ` Adam Belay
2003-02-07 8:56 ` Jaroslav Kysela
2003-02-04 10:40 ` Jaroslav Kysela
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1044286316.1777.30.camel@mulgrave \
--to=james.bottomley@steeleye.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox