[RFC][PATCH] discontiguous vterms

[Hollis Blanchard]

When drivers/char/hvc_console.c was written, OF presented vterm numbers
to us as a pair of [vterm base, number of vterms] via the
/rtas/ibm,termno property. This is no longer the case, and instead we
must use /vdevice/vty nodes.

This patch separates the hvc_struct index from the vterm numbers, so
you can have e.g. hvc0 = vterm 0 and hvc1 = vterm 723. (In fact I've
tested that situation with this patch in a hacked environment.) In
theory the patch is necessary to handle vterms reported by
"/vdevice/vty at N" nodes in the device tree, since there is no guarantee
those vterm numbers will be a contiguous range.

In practice, for us, they probably are contiguous. However,
transforming a list of vty at N nodes (from find_devices()) into [base,
number] in hvc_count() is a bit awkward at best, and could end up
making some assumptions about the order in which OF presents device
nodes to us. Also, this discontiguous functionality might be useful in
other environments (e.g. PPC simulators). So hvc_get_vterms() replaces
hvc_count() to communicate the vterm numbers.

I'd like to check this in, because I believe it will make life easier
in the future when we may actually have multiple vterms (we don't
today). And if you want to talk about hotplugging vterms, I think the
flexibility will help a lot there as well, though it's not certain it
would be needed. Thoughts? hvc_count() is a very quick read for those
of you not familar with the problem I'm describing...

--
Hollis Blanchard
IBM Linux Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hvc-discontig.diff
Type: application/octet-stream
Size: 7004 bytes
Desc: not available
Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20031030/ff196906/attachment.obj