Date: Wed, 20 Dec 2000 20:39:42 +0900 From: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp> To: Mike Smith <msmith@freebsd.org> Cc: freebsd-hackers@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: Request for comments: ISA_PNP_SCAN() (long) Message-ID: <200012201139.UAA05261@zodiac.mech.utsunomiya-u.ac.jp> In-Reply-To: Your message of "Wed, 20 Dec 2000 02:24:23 PST." <200012201024.eBKAONQ16277@mass.osd.bsdi.com> References: <200012201024.eBKAONQ16277@mass.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> Um, may be my wording was not appropriate. I didn't mean dynamic or
>> active scanning of devices. Rather, I just wanted to have a routine
>> to enlist PnP device instances hanging from the ISA bus, so that the
>> hinted device will abondan its probe if there is a PnP
>> sibling; no active scanning, probing, poking, or whatever, is
>> involved and inteded.
>
>No, I understand what you're trying to do. It just doesn't work like
>that. You have no idea, for example, whether the PnP ID you find
>somewhere else would actually have been "won" by you or not.
>
>The right solution is to make the probe order correct, then none of the
>rest of this is an issue.
>> How do we supposed to classify PnP devices into two groups?
>
>The disable method should return failure when you try to disable the
>device.
I saw this "callback" hook code. PnP devices created by the "pnp"
driver seem Ok. But PnP devices created by the PnP BIOS driver "pnpbios"
have an empty callback. (Are they all not "disable"able?)
In any case, these callbacks returns "void", and there currently isn't
a way to report success or failure.
I guess there are two of those reasons why the current version of
sys/isa/isa_common.c:isa_probe_children() doesn't work like
the desired scheme you described.
Does the following look like what you would like to have in
isa_probe_children()? (Yes, I ommitted great many details here.)
/* try to disable PnP devices */
for (i = 0; i < nchildren; i++) {
if (!TAILQ_FIRST(&idev->id_configs)) /* skip non-PnP */
continue;
if (idev->id_config_cb) {
idev->id_config_cb(idev->id_config_arg, &config, 0);
if (_succeeded_)
~~~~~~~~~~~~~~~~
device_disable(children[i]);
}
}
/* then probe PnP devices which were not disabled */
for (i = 0; i < nchildren; i++) {
if (!TAILQ_FIRST(&idev->id_configs)) /* skip non-PnP */
continue;
if (!device_is_enabled(children[i]))
continue;
isa_assgin_resources(children[i]);
device_probe_and_attach(children[i]);
}
/* then probe non-PnP devices */
for (i = 0; i < nchildren; i++) {
if (TAILQ_FIRST(&idev->id_configs)) /* skip PnP */
continue;
device_probe_and_attach(children[i]);
}
/* re-enable disabled PnP devices and probe them */
for (i = 0; i < nchildren; i++) {
if (!TAILQ_FIRST(&idev->id_configs)) /* skip non-PnP */
continue;
if (!device_is_enabled(children[i])) {
device_enable(child);
/* isa_assgin_resources() will enable the PnP device */
isa_assgin_resources(children[i]);
device_probe_and_attach(children[i]);
}
}
>> While the above scheme generally sounds good, we will still have a
>> numbering problem, won't we? Hinted devices created by the isahint
>> driver have the unit number 0 (because they are listed as such in
>> /boot/device.hints), then the PnP instance for "foo" will have the
>> unit number 1 when it attaches.
>
>It shouldn't work like this, no. The hinted device should only get the
>unit number if its probe succeeds (but it may not work like this yet, I
>admit).
No, it currently doesn't work that way. Hinted devices have whatever
unit numbers listed in device.hints.
>There may be a need for arbitration for unit numbers at some
>point.
There ought to be.
Kazu
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012201139.UAA05261>