From: Jeff Muizelaar <muizelaar@rogers.com>
To: Adam Belay <ambx1@neo.rr.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
greg@kroah.com, Jeff Garzik <jgarzik@pobox.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/4] NE2000 driver updates
Date: Wed, 14 May 2003 23:01:51 -0400 [thread overview]
Message-ID: <3EC3031F.1030306@rogers.com> (raw)
In-Reply-To: <20030514215134.GA32285@neo.rr.com>
Adam Belay wrote:
>On Tue, May 13, 2003 at 10:01:12PM -0400, Jeff Muizelaar wrote:
>
>
>
>Hi Jeff,
>
>I agree that an isa interface with sysfs would be useful. This patch looks like
>a great start. I'm considering the following aditional changes...
>
>1.) Perhaps the contents of /drivers/eisa and /drivers/isa should be held in the
>same directory. Comments?
>
Maybe. Though, eisa is still a sane bus, where we get ids and slot
numbers etc. The isa code is pretty much a free for all.
>2.) Some collaboration between isapnp, eisa, and isa would be nice. This is
>because all three of these interfaces could potentially be detecting the same
>devices, resulting in nasty conflicts.
>
Yes, agreed. Probably the easiest way to this is something like an
isa_reserve_(region/resources) that checks if either eisa or pnp know
about anything at the place where we are going to probe. This keeps isa
autoprobe from blindly stealing everything it can get it's hands on, and
lets the higher level buses have priority over it.
This also brings up the question of whether something from eisa/pnp
should also be registered on the isa bus.
>3.) A sysfs interface that would export isa information would be useful.
>
>4.) Perhaps the isa drivers could match against the name of the legacy probing
>driver or maybe the system should be designed to not use device_ids at all.
>
>
Yeah, basically all we need is something that says "this is my device,
give it to me later".
>
>Also a few things to consider...
>
>Is isa limited to one dma, one irq, and one ioport? I haven't seen more then
>this anywere but it would be nice to know for registration purposes.
>
>What is the best action to take if a legacy probing technique detects an area
>that conflicts with a previous legacy probe from another driver. At the very
>least, it would be nice if isa was aware of such things.
>
Right now, it is basically first come, first serve. request_region keeps
people from stepping on each other toes. So, once a driver finds a
region it likes it keeps it and nobody else can touch it. I think it is
probably best to keep it this way.
-Jeff
next prev parent reply other threads:[~2003-05-15 2:49 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-01 16:53 [PATCH 0/4] NE2000 driver updates Jeff Muizelaar
2003-05-01 16:58 ` [PATCH 1/4] " Jeff Muizelaar
2003-05-01 16:59 ` [PATCH 2/4] " Jeff Muizelaar
2003-05-01 16:59 ` [PATCH 3/4] " Jeff Muizelaar
2003-05-01 17:08 ` Jeff Muizelaar
2003-05-01 17:47 ` [PATCH 4/4] " Jeff Muizelaar
2003-05-01 19:23 ` [PATCH 0/4] " Alan Cox
2003-05-01 23:29 ` Jeff Muizelaar
2003-05-02 14:01 ` Alan Cox
2003-05-02 15:57 ` Jeff Garzik
2003-05-02 15:24 ` Alan Cox
2003-05-02 16:29 ` Riley Williams
2003-05-14 2:01 ` Jeff Muizelaar
2003-05-14 21:51 ` Adam Belay
2003-05-15 3:01 ` Jeff Muizelaar [this message]
[not found] <BKEGKPICNAKILKJKMHCACEOMCPAA.Riley@Williams.Name>
2003-05-14 11:02 ` Alan Cox
2003-05-14 23:11 ` Jeff Muizelaar
2003-05-14 22:46 ` Jeff Muizelaar
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=3EC3031F.1030306@rogers.com \
--to=muizelaar@rogers.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=ambx1@neo.rr.com \
--cc=greg@kroah.com \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.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