On Tue, Jun 27, 2017 at 02:08:51PM +0200, Oliver Neukum wrote:
> Am Dienstag, den 27.06.2017, 19:43 +1000 schrieb Stuart Longland:
> > Maybe a good start would be a "standard" option (referring to the
> > physical signalling standard, TTL/RS-232/RS-422/RS-485), that lists the
> > available standards when read and shows the "selected" standard in
> > brackets (like the 'trigger' option of the LEDs sysfs interface)… so for
> > this case:
> >
> > # cat /sys/class/tty/ttyUSB0/standard
> > [rs232] rs422 rs485 rs485fd
> >
> > and to select 4-wire ("full duplex") RS-485, one does:
> > # echo rs485fd > /sys/class/tty/ttyUSB0/standard
>
> This looks like something that people will put into udev.
> So the switch will be done via udev, but the user not necessarily
> started via udev. Looks like a race to me.
Sure, but since changing the electrical interface arguably should be a
privileged operation, using an ioctl for this would not solve the race
when the interface is changed from an init-script and a non-privileged
application opens the port.
We also have the easy device-tree case, where such parameters could be
parsed at probe and all would be good. This could be used to handle some
semi-static cases involving USB devices eventually too.
So this is mostly an issue for systems not using OF and for hot-plugging,
where udev could race with the application.
The latter could of course always check that the desired mode has been
set before opening the port, but then I guess we're in some sense back
at encoding the physical setup in the application.
> And what do you if the interface is already opened and the sysfs
> interface is used?
Refuse switching mode and returning -EBUSY?
Johan
--
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
