On Tue, 2020-07-14 at 09:02 +0200, Oliver Neukum wrote:
>
> Am Montag, den 13.07.2020, 20:26 +0000 schrieb Joakim Tjernlund:
>
> Good morning,
>
> >
> > OK, but it is strange that init_termios.c_cflag does not take/do
> > anything unless I change order. Perhaps termios should move to
> > probe
> > instead?
>
> Are you saying that the tty layer does not set termios when a new
> tty is created? This looks strange to me and I do not want to paper
> over a wider issue.
Not sure. all I can say that when I was playing with B0 baud, I had
to change order to see any effects of B0.
>
> > Also, the handling of DTR came up. It seems to me that ACM
> > deassert DTR until open time which is fine/good.
>
> ACM does not really control DTR by itself. The earliest time
> we can touch it would be probe. And again setting sane defaults
> for DTR looks like a job for the tty layer.
> acm_set_control() AFAICT does its job correctly.
Yes, so it seems.
>
> > !DTR signals to the other end that ACM is not ready and don't
> > want input but ACM still accepts input if received.
> >
> > Would it make sense to actually enforce DTR locally too?
> > If input is unwanted, don't accept any either.
>
> This looks difficult. Basically we can call acm_set_control()
> which will execute a control request. Yet there is inevitably
> a race between setting such a control line and data getting in
> and between clearing a control signal and data getting into the
> buffer.
> We could stop reading once we are sure the control signal is
> effective, but we have no operation for clearing the buffers
> in the device. We cannot tell whether data in them is stale
> in the sense of being accepted without DTR or newly arrived.
Does this race really matter? There will always be a race, even when
DTR is HW driven. I guess what is really missing is way
to control/clear input buffers.
Some sort of flag to the tty layer would be best/minimize race I think,
maybe DTR_NO_INPUT which could be set at init time.
> Could you make a concrete proposal of how to achieve this
> short of a device reset? The mapping between CDC-ACM and
> a physical RS-232 is only as good as the device makes it.
I am just getting started with USB/ACM and I got here due to odd
USB chip we just started to use so a concrete proposal is a bit too
much for me ATM
> CDC-ACM is only secondarily a serial driver. The common
> association between modems and serial devices is historical,
> not technical.
Yes, ttyUSB seems better suited for this but ATM I don't
have that choice.
Regards
Joakim
