On Tue, Aug 17, 2010 at 11:04:17AM -0400, Alan Stern wrote:
> I disagree with Dave's suggestion. Both of you should keep in mind
> that even when the DTR/RTS lines aren't needed for hardware flow
> control, they might be needed for some other device-specific type of
> signalling. I guess it would be okay for the driver to raise them
> automatically when hardware flow control is disabled and when the port
> is first opened, but the driver certainly should _not_ force them on
> all the time, under any circumstances.
Ok, then we have a problem understanding what the
FTDI_SIO_SET_MODEM_CTRL_REQUEST command does, or the macros
{set,clear}_mctrl(), respectively.
The whole issue came up because my hardware (which does not use DTR/RTS
and leaves the pins unconnected on the chip) would not work anymore
unless I call clear_mctrl() in the non-CRTSCTS case of set_termios(),
that's all.
I need to call it there in order to make the chip ignore its hardware
flow control lines, or not call the equivalent of set_mctrl() in the
first place; ie, revert Alan's patch 4175f3e31 ("tty_port: If we are
opened non blocking we still need to raise the carrier").
That tells me that {set,clear}_mctrl() don't actually force any line
states but simply control the chip's pin functions. Because otherwise,
it shouldn't matter and I wouldn't have noticed anything. Correct?
But I might be missing the obvious now, as I stared at it for too long.
Can anyone with a deeper understanding of the protocol help out here?
Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
