[PATCH] serial: DCC(JTAG) serial and console emulation support
dwalker at codeaurora.org
Wed Oct 13 16:47:23 EDT 2010
On Wed, 2010-10-13 at 16:27 -0400, Nicolas Pitre wrote:
> 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?
I don't know exactly why .. Hyok wrote it and I assume there was a good
reason for it, but he's not responding to tell us what it was..
> 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.
That's what I was suggesting to Arng .. We should extend hvc to allow
other major/minor devices.
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
More information about the linux-arm-kernel