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

[John Baldwin]

On Sunday 09 July 2006 03:46, M. Warner Losh wrote:
> Sorry to toppost on this.  But I'm curious.  Why are such extensive
> changes needed to newbus when a two-pass device adding scheme would
> work nearly as well in the acpi layer?  Likewise for pci and the 'wire
> this unit to a location' solution.  A minor change to newbus to never
> assign a unit to a hinted device would be all that's needed.
> 
> The big problem that I see with your solution is that sio0 is hinted
> on the isa bus, but not on the acpi bus.  acpi should rightly ignore
> the isa hints.  If someone wants to hint (wire) an ACPI device, that
> someone should wire it on the acpi bus.  Or on whatever other
> bus is appropriate.

The problem is that ACPI enumerates ISA devices just like PNP BIOS.  A
serial port is not an "ACPI device" on an ACPI bus.  It's an ISA device
that the BIOS enumerates because the ISA bus itself is too
dumb/simple/whatever to enumerate itself.  If you look at the actual
device tree in ACPI, it looks like this:

_SB_
 \-- PCI0
      \-- ISA0
           \-- COMA

If we actually followed this in new-bus we'd have:

acpi0
  pcib0
    pci0
      isab0
        isa0
          sio0

However, instead of making an ACPI-aware isa0 (which we have done for pcib0
and pci0 to get PCI interrupt routing to work correctly in ACPI-land) we
attach ISA devices directly to acpi0.

We should treat the ACPI case similar to the PNPBIOS case for enumerating
built-in ISA devices.  In both cases, whatever serial port contains the
resources for 'sio.0' as specified in 'hints' should probe and attach as
'sio0' and take on non-resource hints such as 'flags' to mark the serial
console.

> There's a number of overlapping problems here.
> 
> First, we need some way to enumerate a bus that has no way of doing
> that enumeration for itself.  This used to be ISA bus, but these days
> ISA slots are almost gone, and the need to completely enumerate the
> ISA bus is almost nil because all on-board devices are enumerated by
> the PNPBIOS or ACPI (although I have seen some exceptions on boards
> that we buy for our embedded stuff at work).  Many new busses are
> going to be added to the tree (or existing busses augmented) to do the
> proper hinting because they are not self enumerating.  i2c is one such
> bus that's not self-enumerating (although i2c variants, such as smb,
> do exist that are nearly probeable).
> 
> Next, there's the desire to wire units to locations.  This is done to
> an extent in cam right now, but isn't newbus aware since cam isn't
> newbus aware.  Although a simple problem on its surface, it really is
> an ugly one once you get down into it.  One solution is to use devd to
> configure based on more information than is present at probe time.
> This solves the fxp0 in slot 3 becomes fxp1 when another fxp card is
> inserted in the wrong slot.  If you base your configuration on
> location or attribtues (eg mac address) of the device, then you solve
> the problem in a more generic and scalable way.  The kernel will
> likely never allow you to assign rl0 to 00:0f:b0:fd:ab:39 and rl1 to
> 00:0f:b0:fd:ca:23, for example, since that information isn't present
> until attach time.

The serial console needs to work during boot. :-/
 
> The first problem is totally solved by hints.  I just extended it from
> the one bus in the system that had it (ISA) to the many that will need
> it (i2c, spi, etc).  The second problem is solved by devd
> generically.  A limited subset of it could be solved using hints and a
> lot of goo to add a lot of DWIM to newbus, but guessing at user
> desires has never been a strong suit of unix.  The third problem could
> also be solved with hints and some minor adjustments to newbus.  Each
> bus could solve it differently, and likely should.  But the number of
> busses that need to solve it are small.  ISA + PNPBIOS info is one,
> and ACPI is another.  I'm unaware of others where it is meaningful
> (after all, you'd never think of doing it on the PCI bus, where
> resource allocations fluxuate a lot).

What you are missing here is that ISA is a "special case" of a
non-enumerated bus in that there are side-band methods (PNPBIOS and ACPI)
to enumerate it for you.  ACPI can also provides some of the same stuff for
other non-enumerated bus's such as SMB.

> I've actually given a lot of thought to problem 3, and have a scheme
> worked out in my mind that I think will work well.  I don't think it
> needs to be complicated or even two passes if newbus never assigns a
> unit number to a -1 device that has any hints at all.  We could look
> at devclass creation time and just create the devices that have hints
> easily enough I think.  It would mean gutting the current isahint
> driver, I think, and hoisting its function up into isa proper.  I
> think it would also mean that PNP enumerated busses (ISA PNPBIOS and
> ACPI's system resources) would need have some way of looking up a
> device by its resources, and then for those it gets a 'hit' on, hard
> wiring the device and the unit.  The down side is that it makes it
> harder for things that also live at COMx addresses to have different
> drivers.  Like IrDA ports and the like.

My proposal is to add a method to bus drivers so they can tell new-bus
when to do a hard-wiring operation.  new-bus would by default not hand
out hard-wired unit numbers unless the bus driver agrees to the match.

-- 
John Baldwin