Re: ttyACM: disabled by hub (EMI?), re-enabling... Causes garbage chars & disconnect

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2020-05-27 at 17:41 +0200, Joakim Tjernlund wrote:
> On Wed, 2020-05-27 at 15:16 +0200, Joakim Tjernlund wrote:
> > On Wed, 2020-05-27 at 12:41 +0200, Oliver Neukum wrote:
> > > Am Mittwoch, den 27.05.2020, 09:40 +0000 schrieb Joakim Tjernlund:
> > > > On Wed, 2020-05-27 at 10:38 +0200, Oliver Neukum 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.
> > > > > 
> > > > > 
> > > > > Am Dienstag, den 26.05.2020, 17:19 +0000 schrieb Joakim Tjernlund:
> > > > > > This "u-boot SPL" is the first thing u-boot writes and somehow this is remembered, I assume, by cdc_acm
> > > > > > and gets echoed back when I open ttyACM0
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > that makes sense, but it is not something that we could really
> > > > > change in CDC-ACM, I am afraid.
> > > > 
> > > > Why not? CDC-ACM should echo back anything it has received before open of ttyACM
> > > 
> > > Well, there is an inherent race condition with loading the module I am
> > > afraid. By default cdc-acm should actually echo. You can set the
> > > DISABLE_ECHO echo quirk for your device if you want to get rid of it.
> > > 
> > > Is CDC-ACM violating some standard with respect to echoing? Changing
> > > defaults really hurts users, no matter what you do.

I can see that when I open the tty, a USB read is performed and then echoed back.
Should an open really do that?
If so, an flag to open(2), telling it to drop the input buffer would be really handy.

 Jocke




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux