Fixing ISA device probing

[John Baldwin <jhb@xxxxxxxxxxx>]

The original reason for bringing this up:  ACPI currently bogusly attaches
ACPI-enumerated ISA devices to acpi0 instead of to an ACPI-aware ISA bus
driver.  After talking some with Warner offline we have come up with the
following rough ideas and possible layout.  This would probably be a big
change but hopefully it can be broken down into a few chunks.

Currently we have several types of ISA devices:
- Devices enumerated by the BIOS.  Currently we have two types: those
  enumerated by ACPI and those by the PNPBIOS.  These two sets are
  mutually exclusive.
- PnP ISA devices.
- ISA devices that only the user can tell us about (currently they can
  use hints to tell us).

All ISA busses can have the last two devices, but the first set of devices
are not always present.  Thus it makes sense to possibly have 3 ISA bus
drivers:

- A basic ISA bus which supports PnP ISA devices and hint devices
  (mostly what we have now but without PnPBIOS support)
- A PNPBIOS ISA bus which inherits from the basic ISA bus with the
  addition of PNPBIOS devices.
- An ACPI ISA bus which inherits from the basic ISA bus with the
  addition of ACPI-enumerated ISA devices.

This in itself is not but so hard and perhaps we could do this as the
first step.  However, there are some annoying inconsistencies with our
current hints mechanism.  Namely, we don't support "merging" a hints
device with an otherwise-enumerated device.  For example, if I just
have a single hint for sio0:

hint.sio.0.flags=0x10

That flag should get applied to the sio0 enumerated by either ACPI or the
PNPBIOS.  How can this be done?  Well, first of all, we can determine
whether a hint device can be merged with a BIOS-enumerated ISA device by
checking the resources.

To do this, we can check if the resources of the hint device form a subset
of the resources in the enumerated device?  This should be slightly
stronger than just being a strict subset, however.  For example, in the
case of I/O ports the port in the hint should match the first port in one
of the port resources for the PnP device.  If a resource is not specified
in the hint then it would match the first such device.  Thus, if I give
the port associated with com2 in addition to the 'sio0' hint above as an
sio0 port, then com2 should be attached as com2 and we should merge the
sio0 hint device with the com2 PNPBIOS device.

Next, if the resources do match, we can do a test probe.  This is because
hint devices are hardwired to a driver and unit as opposed to
BIOS-enumerated devices which are not.  For the test probe, we assign the
BIOS-enumerated device the driver and unit of the hint device and then
do our probe.  If the probe succeeds we toss the hint device.  If it fails,
then we change the BIOS-enumerated device back to not having a driver yet
and continue.

We would then iterate through each hint device trying to match it against
any BIOS-enumerated devices that have not already done a successful probe.
Once that is done, the bus driver would probe any remaining unprobed
BIOS-enumerated devices and then let the generic ISA bus handle remaining
PnP and hint devices.

This would give us hardwiring of devices as well as supplying hints to
BIOS-enumerated devices.  Note that I haven't covered applying those to
PnP devices not enumerated by the BIOS.  Presumably, the generic ISA bus
could attempt to do its own hint device merging where appropriate.

Unfortunately, we would need to fix a few things before taking this second
step.  Specifically, device probes need to be just that: probes.  attach
routines should not require that special magic be done in probe for them to
work properly.  For example, to avoid the "sensitive driver" problem we
currently have, when an ISA device probes, if the device being probed has
an HID, then the probe routine should only check to see if the HID matches
or not and then return.  This would allow the test probes during
hint-merging for BIOS-enumerated or PNP devices to work w/o having negative
side effects.

Comments?

-- 

John Baldwin <jhb@xxxxxxxxxxx>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to majordomo@xxxxxxxxxxx
with "unsubscribe freebsd-new-bus" in the body of the message