i386/100831: sio ignores BIOS information about serial ports - bounty offered

[Warner Losh]

> Please see the thread titled "acpi on msi-9218 (-current) swaps sio0 and 
> sio1" on the freebsd-acpi@ list.  John Baldwin's approach is the one I 
> like, where hints can be used to wire device unit numbers to a 
> particular device with a bus-specific string.  For instance, 
> hint.fxp.0.location="0:4:0" would mean a bus/slot/function to PCI and be 
> meaningless to other busses.  Another example: 
> hint.sio.0.location="COMA" would mean a Device node in ACPI named "COMA" 
> would be wired to sio0 and meaningless to other devices.

I have patches that implement the parts of John's ideas that will
actually work.  I have pci wiring working.  I have some ACPI wiring
working, but not all of it.

> As marcel@ pointed out, for serial ports in particular, you want the 
> resource of I/O port as the primary identifier.  So the default hint 
> would be something like hint.sio.0.location="io=0x3f8".

I hate this notation, since the hints functions don't search that
space well.

> Other than some minor logic to allocate device units in newbus, the only 
> change would be to decide on location naming schemes for the relevant 
> bus types.  Something like "io=0x3f8" might always match resources via 
> RIDs and be bus-independent.  I haven't thought much about the best 
> naming scheme but I like the general idea of attaching a named ID to a 
> unit to wire it to a known device, where the name means something to 
> only a particular bus.

The "minor logic" in newbus is actually kicking my ass right now.  I
have stuff in p4 that should implement all the things we need, but the
unit allocation is kicking my butt.  I fear that the only real way is
to subclass isa three times: hints-only, pnp+hint-augment,
acpi+hint-augment.  In the latter two, how does one tell a 'this hint
is for a card that's there' versus a 'this hint is a wiring hint'?
And for the wiring hints, how much of the device matching do you do?
If the I/O matches, but the IRQ doesn't, is that a match?  What about
vice versa?

The main problem right now is that hints are designed either to
populate a bus, or to look up stuff after unit numbers are assigned.
If you want to do something before unit numbers are assigned, it gets
a lot harder.  Many of the ideas that you've suggested require
extensive, and expensive, algorithims to find what the right DWIM is
for this situation.

When a bus adds a device, there are no resources associated with it.
The bus might be in a position to assign specific device names/units
to individual devices at the time it adds it, but not always.  ACPI,
for example, adds the device, then uses that device to parse the
resources.  This means that looking things up in the hints table
before adding them is hard.  It also means that the bus has to
necessarily get into the middle of pre-assigning device/units.

Anyway, like I said, I'll post something when I get the last bit of
the unit matching working.

Warner