On Tue, Dec 01, 2020 at 08:14:07AM +0100, Jiri Slaby wrote: > On 30. 11. 20, 22:22, Mychaela Falconia wrote: > > 2) For situations in which the luxury of a custom USB ID is not > > available, e.g., a situation where the device that does not tolerate > > automatic DTR/RTS assertion on open is a physical RS-232 device that > > can be connected to "any" serial port, the new sysfs attribute comes > > to the rescue. > > > > Johan's patch comments say that the new flag can also be brought out > > to termios in the future, similarly to HUPCL, > > The difference to other control flags is that open raises DTR/RTS in any > case (i.e. including O_NONBLOCK) -- provided baud rate is set (and it is > for casual serials). That means you cannot open a port to configure it > (using e.g. setserial) without actually raising the DTR/RTS. Right, but depending on the application this may be ok (e.g. reset and initialise on first open after boot, which may have triggered a reset anyway). If control over first open is needed, the sysfs interface provides that out-of-band. > > but I question the > > usefulness of doing so, as it is a chicken and egg problem: one needs > > to open the tty device in order to do termios ioctls on it, and if > > that initial open triggers DTR/RTS hardware actions, then the end user > > is still screwed. If Johan or someone else can see a potential use > > case for manipulating this new flag via termios (as opposed to sysfs > > or USB-ID-based driver quirks), perhaps you could elaborate on it? > > We would need to (ab)use another open flag (e.g. O_DIRECT). I am not > biased to either of solutions. Forgot to mention that using open-flags would prevent using standard utilities like cat, echo and terminal programs. So for that reason a termios and/or sysfs interface is also preferred. Johan
