On Fri, 2020-07-10 at 12:36 +0200, Greg KH wrote:
On Fri, Jul 10, 2020 at 10:16:33AM +0000, Joakim Tjernlund wrote:
On Fri, 2020-07-10 at 11:54 +0200, Johan Hovold wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
On Fri, Jul 10, 2020 at 11:35:18AM +0200, Joakim Tjernlund wrote:
BO will disable USB input until the device opens. This will avoid garbage chars waiting flood the TTY. This mimics a real UART device better. For initial termios to reach USB core, USB driver has to be registered before TTY driver.
Signed-off-by: Joakim Tjernlund joakim.tjernlund@infinera.com Cc: stable@vger.kernel.org
I hope this change makes sense to you, if so I belive ttyUSB could do the same.
No, this doesn't make sense. B0 is used to hang up an already open tty.
This is at module init so there is no tty yet. acm_probe() will later set: acm->line.dwDTERate = cpu_to_le32(9600); acm->line.bDataBits = 8; acm_set_line(acm, &acm->line);
Furthermore, this change only affects the initial terminal settings and won't have any effect the next time you open the same port.
hmm, it is not ideal but acm_probe() will later set: acm->line.dwDTERate = cpu_to_le32(9600); acm->line.bDataBits = 8; acm_set_line(acm, &acm->line);
But, would it not make sense to not accept input until TTY is opened ? That would be more inline with a real RS232, would it not?
You can't keep the chip in the usb-to-serial device from accepting data before you do anything with it, that requires firmware to not do this. Are you sure your firmware is correct?
No, I don't thin it is correct. I am working both ends here :)
Why not fix your firmware so that it doesn't transmit before DTR is asserted during open()?
I would but it is not my firmware, it is a ready made USB to UART chip. will talk to the manufacturer though.
What chip is this?
Microchip USB5734
thanks,
greg k-h