Date: Sun, 09 Jul 2006 20:43:29 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: marcel@xcllnt.net Cc: freebsd-acpi@freebsd.org, atkin901@yahoo.com Subject: Re: acpi on msi-9218 (-current) swaps sio0 and sio1 Message-ID: <20060709.204329.-1889954042.imp@bsdimp.com> In-Reply-To: <F7150813-BC0D-454A-A374-BA91D6603E78@xcllnt.net> References: <200607071240.57062.jhb@freebsd.org> <20060709.014658.-460542464.imp@bsdimp.com> <F7150813-BC0D-454A-A374-BA91D6603E78@xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <F7150813-BC0D-454A-A374-BA91D6603E78@xcllnt.net>
Marcel Moolenaar <marcel@xcllnt.net> writes:
: On Jul 9, 2006, at 12:46 AM, M. Warner Losh wrote:
:
: > Finally, there's the redundant specification problem. People want
: > sio0 to attach to this thing in the back of the computer that's
: > labeled COMA, and whose resources are this or that. They know from
: > their computer's documentation that this is COM1, and windows assigns
: > it to COM1. This desire is due in part to it being the way we've
: > always selected sio0. It traditionally has been the serial port at
: > address 0x3f8. There's also the problem that the low level kernel
: > console driver wants to talk to the port by address, while the newbus
: > system wants to talk to it by how it probed. So you get odd
: > cross-threading when these two don't agree. If the cross threading
: > didn't exist, and the right thing happened, users wouldn't care how
: > that happened.
:
: uart(4) has this problem solved already. It seems to me from following
: the various mailing lists that it's probably time to think about phasing
: out sio(4), because problems tend to come up with sio(4) from time to
: time that have already been solved with uart(4).
It solves one tiny sliver of this problem. While there may be other
merit for using uart(4) over sio(4), this one issue isn't it. At the
very least, there'd be a high cost of migration from /dev/ttyd0 to
/dev/ttyu0. Our products were bit by the cuaa0 -> cuad0 changes
between 5.x and 6.x, and that made a lot of people around unhappy.
They'd be even more unhappy if it changed again.
: > ... The third problem could
: > also be solved with hints and some minor adjustments to newbus.
:
: I disagree. It's misusing hints that's causing the cross-threading.
: If hints were to be used for enumeration only and you have a different
: means to select the low-level serial console then cross-threading is
: avoided. This is exactly what uart(4) does. As such, you can even pick
: a port on a multi-I/O PCI card for the low-level serial console
: without causing interference with any of the other problems you
: mentioned. The reason is simply that you select the low-level serial
: console by the one attribute that matters: the I/O address (either
: I/O port or memory mapped I/O).
You are correct for the console issue. But the problem is much bigger
than just the console issue.
My company uses single board computers for its embedded products. The
documentation for the SBC says that this spigot is COM1 or that spigot
is COM2. The hardware folks then design the cables and such for the
individual unit, plug it all together and tell the software folks that
thus and such function is on COM1 and whatsit is on COM2. It is
perceived to be a FreeBSD bug that sio0 isn't COM1 and sio1 isn't
COM2. This is espeically true when we swap out boards as the old one
goes obsolete (which happens far too quickly). We've had some boards
whose tables are such that com1 <-> sio0 and others where com1 <->
sio1. We've avoided this issue by not using ACPI, but we're starting
to find that it's harder to get vendors to fix problems with non-acpi
operation.
There are many valid reasons for wanting to wire the unit number to a
resource.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060709.204329.-1889954042.imp>