cvs commit: src/sys/sparc64/sparc64 ofw_machdep.c

[Marius Strobl]

On Sun, May 22, 2005 at 01:11:07PM -0700, Marcel Moolenaar wrote:
> On May 22, 2005, at 11:13 AM, Marius Strobl wrote:
> 
> > With the approach uart_cpu_getdev_keyboard() currently takes one
> > can't tell nodes of SCCs/UARTs serving as keyboard controllers and
> > those of PS/2 keyboards apart without also looking at the 'name'
> > property.
> 
> Well, we may improve or actually implement the probe functions. That
> way we poke the hardware to see if it behaves as expected. The probe
> for ns8250-class UARTs is implemented. I don't know if it's good
> enough in its current form or whether it's only good to see if
> something, anything, is out there. The probe functions for the SAB
> and ZS are not implemented yet.
> 

That should also work but it basically accomplishes the same as
checking the 'name' property just with more code. With a different
approach I meant something not involving traversing the OFW device
tree looking for viable targets but something similar to how the
sparc64 uart_cpu_getdev_console() works. E.g. something like
checking whether the 'stdin' instance uses the 'sun-keyboard'
package. Obviously that would however only work when the keyboard
is the chosen input. I think to what extent this really makes a
difference can't be decided until trying to get RS232 keyboards
that were plugged in after the kernel has booted to work. E.g.
the simplest approach would be to check whether 'stdin' is a
RS232 keyboard for getting the low-level console to work. Later
on during device configuration one can simply check whether a
SCC/UART has a 'keyboard' property which would also cover
potential keyboard ports. This however might not fit the system
devices idea and abstraction of uart(4), making again a
uart_cpu_getdev_console() that also identifies potential usage
as keyboard port necessary.

Marius