acpi on msi-9218 (-current) swaps sio0 and sio1

[Takanori Watanabe]

In message <200607071240.57062.jhb at freebsd.org>, John Baldwin $B$5$s$$$o$/(B:
>On Thursday 06 July 2006 16:15, Nate Lawson wrote:
>> > Ahh ok. You must forgive me if I seem dense since this is the first time
>> > I've looked at repairing these types of instruction files.   Are you
>> > saying that the order that they appear in the .asl is important?
>> 
>> Yes, that's what he means.  Move the whole Device (COMA) { ... } section 
>> before COMB if that's what you want.
>> 
>> Ultimate solution is probably to implement _SRS support (set resource) 
>> so that we can reconfigure the devices according to their desired order. 
>>   That's not even on anyone's todo list I think.
>
>That actually wouldn't fix it.  One of the issues here with the backwards com 
>ports is that the serial port ends up on sio0 by default, so if sio0 ends up 
>as COM2, then the kernel ends up switching to a different port for its serial 
>console (or it just uses a different one than the rest of the bootstrap).  
>Since COMA is wired to com1 and COMB is wired to the com2 port on the 
>motherboard, merely swapping the resources around will end up with the same 
>end result: sio0 will be COMB == com2, and sio1 will be COMA == com1.  The 
>real solution is to allow for hints to be used to "wire" unit numbers.  I 
>thought about this on my drive into work today and came up with a rough 
>design:
>
>First, when new-bus goes to probe a device, it currently temporarily assigns 
>it a unit number for each candidate driver.  If new-bus ends up using that 
>driver for the device, the unit number "sticks".  Right now the unit number 
>allocation is rather simple, it just uses the highest unit attached so far + 
>1.  What I would like it to do is start with unit 0 and look for a free unit 
>number each time.  The first test would be if the unit has an assigned device 
>already.  Secondly, for each unit we would see if there were any matching 
>hints for that (driver-name, unit) pair.  If so, then we'd call a method in 
>the parent device (would be a new bus_if.m method called 
>bus_hint_compatible() or something) to determine if this device is compatible 
>with the specified hints and can thus "take over" the hint-specified device 
>or if it should skip this unit number.
>
>The default implementation would for bus_hint_compatible() would be to reject 
>the hint device if it contains any resource hints (irq, port, mem, drq).  
>This would mostly preserve existing behavior for things like the PCI bus (it 
>would also remove the need for the current hack in sio to try to bump up the 
>unit number of PCI sio(4) devices to leave sio0 and sio1 open for COM1 and 
>COM2).  For the ISA and ACPI bus drivers though, they would actually compare 
>the resource hints to see if they were a subset of the resources assigned to 
>the device_t via PnP or ACPI.  For example, they would make sure the IRQ 
>matched if it was assigned, or that the port. mem, and drq resources were 
>contained in at least one of the port, mem, or drq resources that device had. 
> 
>Thus, you could wire sio0 to the default COM1 by specifying 0x3f8 for the 
>port (in fact, our default device.hints file would Just Work(tm) for things 
>like COM ports with this) regardless of the order of COM1 or COM2 in the ASL 
>or PnP BIOS list.

We may want to use _UID resource to wire unit number.
How about tweaking acpi_probe_child function so that attaching by
_UID order?