From: Adam Belay <ambx1@neo.rr.com>
To: "Ruslan U. Zakirov" <cubic@wildrose.miee.ru>
Cc: greg@kroah.com, linux-kernel@vger.kernel.org
Subject: Re: [2.5.54][PATCH] SB16 convertation to new PnP layer.
Date: Thu, 9 Jan 2003 15:26:54 +0000 [thread overview]
Message-ID: <20030109152654.GC17701@neo.rr.com> (raw)
In-Reply-To: <59522031471.20030109183512@wr.miee.ru>
On Thu, Jan 09, 2003 at 06:35:12PM +0300, Ruslan U. Zakirov wrote:
> 1) As I've understood we need to free all reserved resources when
> remove function called, am I right?
Yes, all resources must be freed or the device will not work if it is
attached to the driver a second time. This is becuase the driver will
think the device is busy when actually the resources were just never
freed from the previous session. Also the resources must be freed to
safetly disable the device.
> 2) Who decide card is accessible at some time or not?
This is determined by both the pnp layer and the driver model. Becuase a
card is a group of devices the individual devices must also not be matched
to more than one driver. PnP Card Services have a few bugs in this area,
all of which have been resolved in the patch I released last week. Greg,
could you please forward that to Linus.
> 3) And the last, where is the place of ISA not PnP cards in the device
> lists? As I think, they are fit with PnP bus, but their resources
> static(not configurable) or it's just lays under ALSA, apears in
> /proc/asound only and ALSA internals?
Currently the pnp layer does not support legacy non PnP devices. I plan
to add support for them soon. This support should achieve two objectives.
1.) Reserve resources used by the legacy devices
a.) if the resources match an existing pnp devices, bind to that
device
b.) if they conflict but do not match exactly return an error
c.) otherwise reserve the resources and prevent pnp devices from
using them.
2.) Represent these legacy devices in sysfs. Maybe the current legacy dir
could be used or I may have to create "pnp_legacy". Needs more research.
Regards,
Adam
next prev parent reply other threads:[~2003-01-09 20:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-08 17:20 [2.5.54][PATCH] SB16 convertation to new PnP layer Ruslan U. Zakirov
2003-01-08 16:09 ` Adam Belay
2003-01-09 12:43 ` Ruslan U. Zakirov
2003-01-09 15:35 ` Ruslan U. Zakirov
2003-01-09 15:26 ` Adam Belay [this message]
2003-01-09 21:39 ` Ruslan U. Zakirov
2003-01-08 18:51 ` Zwane Mwaikambo
2003-01-08 23:06 ` Ruslan U. Zakirov
-- strict thread matches above, loose matches on Subject: below --
2003-01-10 4:56 Shawn Starr
2003-01-10 8:17 ` Ruslan U. Zakirov
2003-01-10 16:04 ` Shawn Starr
2003-01-10 16:28 ` Zwane Mwaikambo
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=20030109152654.GC17701@neo.rr.com \
--to=ambx1@neo.rr.com \
--cc=cubic@wildrose.miee.ru \
--cc=greg@kroah.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