[PATCH] serial: DCC(JTAG) serial and console emulation support

[Nicolas Pitre]

On Wed, 13 Oct 2010, Daniel Walker wrote:

> On Wed, 2010-10-13 at 15:55 -0400, Nicolas Pitre wrote:
> > > I found it independently actually .. It looks like there's at least two
> > > problems. This jtag driver has a status register which flags when RX is
> > > available, and TX is possible. I'm not sure this status register fits
> > > into the model. The other thing is that we have a ttyJ registered for
> > > this driver, and it would be nice to use that over something like ttyHVC
> > > (I'm not sure if that name is correct, just a guess).
> > 
> > Really?  Is there a compelling reason to perpetuate this serial device 
> > namespace fragmentation nonsense?  Your initial patch even had a config 
> > option to hijack /dev/ttyS0 because of that.
> 
> I'm not sure how to interpret what your saying .. Are you saying we
> should use /dev/hvcX or shouldn't ?

Long ago I fought for a uniform namespace for serial ports and alike 
with dynamically assigned names, just like we do for network interfaces, 
for disks, for USB devices, etc. so we'd stop making this hack that 
everybody is doing in their own trees which is to hijack /dev/ttyS0, or 
perpetuate this proliferation of serial/tty device names. This obviously 
didn't happen, for "legacy" reasons (people insisted on having their 
0x2f8 serial port appear as ttyS1 and not ttyS0).

> the reason I want to use ttyJ is because it was assigned specifically 
> for jtags which, to me, makes things a lot less confusing.

Why did the patch have a config option to use ttyS0 then?

Anyway, given that the hvc layer is there and would simplify the DCC 
driver, I think it is a good idea to leverage it instead of duplicating 
and faking tty handling yet again.  Maybe extending the generic hvc code 
to optionally accept alternate device registration could be considered 
instead if you really want a ttyJ device.


Nicolas