Re: Moxa UPort 1150 and RS-422/485… what's the "proper" way to switch modes

Re: Moxa UPort 1150 and RS-422/485… what's the "proper" way to switch modes

[Johan Hovold]

[ +CC: Alan and linux-usb ]

On Fri, Jun 23, 2017 at 09:44:31AM +1000, Stuart Longland wrote:
> Hi all,
> 
> A silly question: I have a Moxa UPort 1150 USB serial interface that I
> am trying to coax into either RS-422 or 4-wire RS-485 mode.  Internally,
> this is a TI USB 3410 device, and works with the ti_usb_3410_5052 module.
> 
> Moxa have a (poorly maintained as usual) driver for these devices, and I
> see reference to things like RS-485 in the TI driver.  Moxa's driver did
> a kludge where they used `setserial` to control the mode, and used the
> device "port" number to set that mode.  I do not think it wise to try
> and replicate that same kludge, as I understand that parameter is for
> configuring the I/O port (e.g. 0x3f8 for /dev/ttyS0 on older
> IBM-compatibles).

Agreed, and that's why we have rejected this interface when support for
Moxa devices have been added.

> Now, *some* versions of `stty` allegedly have an "rs485" option: mine
> (in coreutils 8.25) does not.  I suspect this is 2-wire RS-485, which
> won't do here, as my RX and TX are on different RS-485 pairs.

Neither does mine, I think that's some out-of-tree support for the
TIOCSRS485 ioctl mentioned below.

> What's the "proper" way to configure such ports for RS-422 and/or 4-wire
> RS-485?  Is there an example driver in the tree that I can use as a
> guide to porting Moxa's mode-switch code over to the ti_usb_3410_5052
> driver?

I'm afraid not. We have the TIOCSRS485 ioctl, but that doesn't really
fit here (currently) as we're not just enabling 2-wire-rs485 style
signalling (using RTS to control the tranceiver), but are also
configuring the electrical interface (e.g. which pins on the DB9
connector are being used for which functions).

This question is raised every now and then; typically when a new
driver is being merged (e.g. mxuport or when support for your device was
added), but we have yet to decide on the proper interface.

Extending the TIOCSRS485 ioctl has been discussed, and one alternative
could be a sysfs-based interface as this would typically be something
you'd want to configure at boot and before opening the device (and
toggling DTR).

Either way, we need do determine the right level of abstraction as some
of the related properties are fairly device dependent (master/slave
mode, terminating resistors, auto direction, echo, etc).

For the record, note that we do have the mxser driver, and a few more
old drivers, implementing custom ioctls for this, but we really should
not be adding more of those.

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Moxa UPort 1150 and RS-422/485… what's the "proper" way to switch modes

[Stuart Longland]

[-- Attachment #1.1: Type: text/plain, Size: 3642 bytes --]

On 27/06/17 19:04, Johan Hovold wrote:
>> What's the "proper" way to configure such ports for RS-422 and/or 4-wire
>> RS-485?  Is there an example driver in the tree that I can use as a
>> guide to porting Moxa's mode-switch code over to the ti_usb_3410_5052
>> driver?
> 
> I'm afraid not. We have the TIOCSRS485 ioctl, but that doesn't really
> fit here (currently) as we're not just enabling 2-wire-rs485 style
> signalling (using RTS to control the tranceiver), but are also
> configuring the electrical interface (e.g. which pins on the DB9
> connector are being used for which functions).
> 
> This question is raised every now and then; typically when a new
> driver is being merged (e.g. mxuport or when support for your device was
> added), but we have yet to decide on the proper interface.
> 
> Extending the TIOCSRS485 ioctl has been discussed, and one alternative
> could be a sysfs-based interface as this would typically be something
> you'd want to configure at boot and before opening the device (and
> toggling DTR).

I did consider sysfs this morning… this would make a lot of sense.
These things being USB, it is possible that a udev trigger could put it
in the appropriate mode when they are plugged in.  Sounds a much better
option than re-purposing other fields.

> Either way, we need do determine the right level of abstraction as some
> of the related properties are fairly device dependent (master/slave
> mode, terminating resistors, auto direction, echo, etc).
> 
> For the record, note that we do have the mxser driver, and a few more
> old drivers, implementing custom ioctls for this, but we really should
> not be adding more of those.

Yeah, I won't be adding ioctls… it makes the interface too
hardware-specific.  If anything, the ioctls might be a hint to what
enumerated properties to expose on sysfs, then the ioctl interface can
be gradually phased out.

I'll have a look at mxser.  At this point I'm thinking gathering a
listing of what devices support what configuration options would be
worthwhile.  I know the UPort 1150 supports 2-wire RS-485, 4-wire
RS-485, RS-422 and RS-232… the UPort 1100 drops support for RS-232… I
don't think either offer termination resistance options.

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

A hypothetical dongle that supports pin re-mapping might have
properties: rxd, txd, rts, cts, dtr, dsr, cd, ri, gnd (for RS-232; maybe
a, b and gnd for RS-485 or txa, txb, rxa, rxb, gnd for
RS-422/full-duplex-RS-485) that gives the pin numbers/labels:

cd: [1] 2 3 4 5 6 7 8 9
rx: 1 [2] 3 4 5 6 7 8 9
tx: 1 2 [3] 4 5 6 7 8 9
… etc …

and termination resistance (separate options for RX and TX) might be a
selection of off, and the available resistances. (e.g. "50", "75",
"120", "1k" … whatever the device supports.)

I'm open to ideas here, I'm not sure how many configurable serial
interfaces there are out there (USB or otherwise), so if people watching
the list can provide some examples of these devices, this will be a big
help.

Regards,
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Moxa UPort 1150 and RS-422/485… what's the "proper" way to switch modes

[Oliver Neukum]

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.
And what do you if the interface is already opened and the sysfs
interface is used?

	Regards
		Oliver

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Moxa UPort 1150 and RS-422/485… what's the "proper" way to switch modes

[Stuart Longland]

[-- Attachment #1.1: Type: text/plain, Size: 1862 bytes --]

On 27/06/17 22:08, 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.

It is a race, but unless a daemon is watching for the very moment that a
particular serial interface appears, it's one that init scripts are very
likely to win.

Short of having a flag that blocks reads/writes until a given sysfs file
is written to say "I'm ready, go ahead"… there aren't that many options
I can think of.

> And what do you if the interface is already opened and the sysfs
> interface is used?

We return -EBUSY?  If the interface is open, there isn't a lot we can
do, the user either puts up with unpredictable behaviour or we refuse
the switch.

By unpredictable behaviour: if the device is well behaved, there might
be a small signal level glitch… but I'd expect serial devices to be
tolerant of that kind of step change in signal.  (Think hot-plugging
serial links.)

This beats the official Moxa solution: their Windows driver wants a
reboot of the entire machine to switch between serial standards.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Moxa UPort 1150 and RS-422/485… what's the "proper" way to switch modes

[Oliver Neukum]

Am Mittwoch, den 28.06.2017, 08:07 +1000 schrieb Stuart Longland:

Hi,

> >> 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.
> 
> It is a race, but unless a daemon is watching for the very moment that a
> particular serial interface appears, it's one that init scripts are very
> likely to win.

That is precisely what a demon might do.

> Short of having a flag that blocks reads/writes until a given sysfs file
> is written to say "I'm ready, go ahead"… there aren't that many options
> I can think of.

1) module option
2) ioctl

	Regards
		Oliver

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Moxa UPort 1150 and RS-422/485… what's the "proper" way to switch modes

[Greg KH]

On Wed, Jun 28, 2017 at 11:19:09AM +0200, Oliver Neukum wrote:
> Am Mittwoch, den 28.06.2017, 08:07 +1000 schrieb Stuart Longland:
> 
> Hi,
> 
> > >> 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.
> > 
> > It is a race, but unless a daemon is watching for the very moment that a
> > particular serial interface appears, it's one that init scripts are very
> > likely to win.
> 
> That is precisely what a demon might do.
> 
> > Short of having a flag that blocks reads/writes until a given sysfs file
> > is written to say "I'm ready, go ahead"… there aren't that many options
> > I can think of.
> 
> 1) module option

No, just no, sorry.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Moxa UPort 1150 and RS-422/485… what's the "proper" way to switch modes

[Oliver Neukum]

Am Mittwoch, den 28.06.2017, 14:01 +0200 schrieb Greg KH:
> On Wed, Jun 28, 2017 at 11:19:09AM +0200, Oliver Neukum wrote:
> > 
> > Am Mittwoch, den 28.06.2017, 08:07 +1000 schrieb Stuart Longland:
> > 
> > Hi,
> > 
> > > 
> > > > 
> > > > > 
> > > > > 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.
> > > 
> > > It is a race, but unless a daemon is watching for the very moment that a
> > > particular serial interface appears, it's one that init scripts are very
> > > likely to win.
> > 
> > That is precisely what a demon might do.
> > 
> > > 
> > > Short of having a flag that blocks reads/writes until a given sysfs file
> > > is written to say "I'm ready, go ahead"… there aren't that many options
> > > I can think of.
> > 
> > 1) module option
> 
> No, just no, sorry.
> 
Hi,

I am sorry, but this is just ideological an answer. This is rather
specialized hardware, so it will need a system specifically configured
for this task. No distro will configure this on the fly.

	Regards
		Oliver

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Moxa UPort 1150 and RS-422/485… what's the "proper" way to switch modes

[Bjørn Mork]

Oliver Neukum <oneukum-IBi9RG/b67k@public.gmane.org> writes:
> Am Mittwoch, den 28.06.2017, 14:01 +0200 schrieb Greg KH:
>> On Wed, Jun 28, 2017 at 11:19:09AM +0200, Oliver Neukum wrote:
>> > 
>> > 1) module option
>> 
>> No, just no, sorry.
>
> I am sorry, but this is just ideological an answer. This is rather
> specialized hardware, so it will need a system specifically configured
> for this task. No distro will configure this on the fly.

Using two identical adapters in different modes is at least
theoretically possible, isn't it?



Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Moxa UPort 1150 and RS-422/485… what's the "proper" way to switch modes

[Johan Hovold]

On Wed, Jun 28, 2017 at 08:07:54AM +1000, Stuart Longland wrote:

> This beats the official Moxa solution: their Windows driver wants a
> reboot of the entire machine to switch between serial standards.

Interesting approach.

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Moxa UPort 1150 and RS-422/485… what's the "proper" way to switch modes

[Johan Hovold]

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Moxa UPort 1150 and RS-422/485… what's the "proper" way to switch modes

[Alan Cox]

So IMHO there are two cases

1. The configuration is fixed in the hardware - in which case we should
automatically set it in kernel, or from device tree.

2. The configuration is soft - in which case you need an ioctl you can
use on the port to change it - irrespective of whether sysfs also handles
it. For simple permissions reasons and also to avoid races you need that
ioctl.

We intentionally have lots of spare space left to extend the RS485 ioctl,
and we have termiox which contains even more room and historically in
other Unixen dealt with all sorts of weird and wonderful parameters used
on stuff like synchronous ports.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Moxa UPort 1150 and RS-422/485… what's the "proper" way to switch modes

[Johan Hovold]

On Thu, Jun 29, 2017 at 08:50:32PM +0100, Alan Cox wrote:
> So IMHO there are two cases
> 
> 1. The configuration is fixed in the hardware - in which case we should
> automatically set it in kernel, or from device tree.

Right.

> 2. The configuration is soft - in which case you need an ioctl you can
> use on the port to change it - irrespective of whether sysfs also handles
> it. For simple permissions reasons and also to avoid races you need that
> ioctl.

Ok, but if we are going to extend and use the RS485 ioctl for this, I
think we should just stick to that and not add a sysfs-interface as
well.

I'll take a closer look at this.

> We intentionally have lots of spare space left to extend the RS485 ioctl,
> and we have termiox which contains even more room and historically in
> other Unixen dealt with all sorts of weird and wonderful parameters used
> on stuff like synchronous ports.

Yes, your foresight when adding (generalising) that ioctl might come in
handy now. :)

Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Moxa UPort 1150 and RS-422/485… what's the "proper" way to switch modes

[Johan Hovold]

On Tue, Jun 27, 2017 at 07:43:28PM +1000, Stuart Longland wrote:
> On 27/06/17 19:04, Johan Hovold wrote:
> >> What's the "proper" way to configure such ports for RS-422 and/or 4-wire
> >> RS-485?  Is there an example driver in the tree that I can use as a
> >> guide to porting Moxa's mode-switch code over to the ti_usb_3410_5052
> >> driver?
> > 
> > I'm afraid not. We have the TIOCSRS485 ioctl, but that doesn't really
> > fit here (currently) as we're not just enabling 2-wire-rs485 style
> > signalling (using RTS to control the tranceiver), but are also
> > configuring the electrical interface (e.g. which pins on the DB9
> > connector are being used for which functions).
> > 
> > This question is raised every now and then; typically when a new
> > driver is being merged (e.g. mxuport or when support for your device was
> > added), but we have yet to decide on the proper interface.
> > 
> > Extending the TIOCSRS485 ioctl has been discussed, and one alternative
> > could be a sysfs-based interface as this would typically be something
> > you'd want to configure at boot and before opening the device (and
> > toggling DTR).
> 
> I did consider sysfs this morning… this would make a lot of sense.
> These things being USB, it is possible that a udev trigger could put it
> in the appropriate mode when they are plugged in.  Sounds a much better
> option than re-purposing other fields.

Unless there are too many attributes to set at least, otherwise a single
ioctl might still be still be more convenient. Note that there is room
for extending the TIOCSRS485 ioctl.

> > Either way, we need do determine the right level of abstraction as some
> > of the related properties are fairly device dependent (master/slave
> > mode, terminating resistors, auto direction, echo, etc).
> > 
> > For the record, note that we do have the mxser driver, and a few more
> > old drivers, implementing custom ioctls for this, but we really should
> > not be adding more of those.
> 
> Yeah, I won't be adding ioctls… it makes the interface too
> hardware-specific.  If anything, the ioctls might be a hint to what
> enumerated properties to expose on sysfs, then the ioctl interface can
> be gradually phased out.
> 
> I'll have a look at mxser.  At this point I'm thinking gathering a
> listing of what devices support what configuration options would be
> worthwhile.  I know the UPort 1150 supports 2-wire RS-485, 4-wire
> RS-485, RS-422 and RS-232… the UPort 1100 drops support for RS-232… I
> don't think either offer termination resistance options.

There are more Moxa devices with rs485-support, including those managed
by the mxuport driver. Some Edgeport devices apparently support some of
those more exotic settings like termination, see

	https://marc.info/?l=linux-usb&m=129798628514104&w=2

The above thread also has some discussion about extending the TIOCSRS485
ioctl.

Other USB serial devices that have some support for rs485 include cp210x
(using a gpio pin to control the tranceiver), and some Fintek devices.

Also note that the vendor driver for UPort 1150 treats rs422 and
rs485-4w the same and really only has three distinct modes (rs232, and
rs485 with receiver enabled or disabled).

> 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

Yeah, I once suggested something like this for Moxa, but I think we need
to at least consider the various parameters available first if we are to
come up with a generic interface.

> and to select 4-wire ("full duplex") RS-485, one does:
> # echo rs485fd > /sys/class/tty/ttyUSB0/standard
> 
> A hypothetical dongle that supports pin re-mapping might have
> properties: rxd, txd, rts, cts, dtr, dsr, cd, ri, gnd (for RS-232; maybe
> a, b and gnd for RS-485 or txa, txb, rxa, rxb, gnd for
> RS-422/full-duplex-RS-485) that gives the pin numbers/labels:
> 
> cd: [1] 2 3 4 5 6 7 8 9
> rx: 1 [2] 3 4 5 6 7 8 9
> tx: 1 2 [3] 4 5 6 7 8 9
> … etc …

This I think might be taking it too far at this stage though. :)

> and termination resistance (separate options for RX and TX) might be a
> selection of off, and the available resistances. (e.g. "50", "75",
> "120", "1k" … whatever the device supports.)

A binary setting here might suffice.

> I'm open to ideas here, I'm not sure how many configurable serial
> interfaces there are out there (USB or otherwise), so if people watching
> the list can provide some examples of these devices, this will be a big
> help.

I mention a few above, and there are some old ones like rocket and mxser
that have a custom ioctl for this.

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] USB: serial: ti_usb_3410_5052: Port uart_mode from io_ti.

[Stuart Longland]

This introduces the `uart_mode` sysfs attribute as seen in the `io_ti`
USB serial driver, allowing this USB serial interface to be switched
between RS-232, 2-wire RS-485 and 4-wire RS-485.

/sys/class/tty/ttyUSB${num}/device/uart takes a single integer:

	0:	RS-232 mode (default for RS-232-compatible dongles)
	1:	RS-485 2w mode (default for RS-485-only dongles)
	2:	RS-485 4w mode / RS-422 mode

Write this *before* opening your serial device.

This has been successfully tested on a Moxa UPort 1150 in 4-wire RS-485
mode.

Signed-off-by: Stuart Longland <stuartl-EoQOJlg3kTYQrrorzV6ljw@public.gmane.org>
---
 drivers/usb/serial/ti_usb_3410_5052.c | 48 +++++++++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)

diff --git a/drivers/usb/serial/ti_usb_3410_5052.c b/drivers/usb/serial/ti_usb_3410_5052.c
index 8fc3854e5e69..fb30d7ff32d7 100644
--- a/drivers/usb/serial/ti_usb_3410_5052.c
+++ b/drivers/usb/serial/ti_usb_3410_5052.c
@@ -514,6 +514,46 @@ MODULE_DEVICE_TABLE(usb, ti_id_table_combined);
 
 module_usb_serial_driver(serial_drivers, ti_id_table_combined);
 
+/* Sysfs Attributes */
+
+static ssize_t uart_mode_show(struct device *dev,
+	struct device_attribute *attr, char *buf)
+{
+	struct usb_serial_port *port = to_usb_serial_port(dev);
+	struct ti_port *tport = usb_get_serial_port_data(port);
+
+	return sprintf(buf, "%d\n", tport->tp_uart_mode);
+}
+
+static ssize_t uart_mode_store(struct device *dev,
+	struct device_attribute *attr, const char *valbuf, size_t count)
+{
+	struct usb_serial_port *port = to_usb_serial_port(dev);
+	struct ti_port *tport = usb_get_serial_port_data(port);
+	unsigned int v = simple_strtoul(valbuf, NULL, 0);
+
+	dev_dbg(dev, "%s: setting uart_mode = %d\n", __func__, v);
+
+	if (v < 256)
+		tport->tp_uart_mode = v;
+	else
+		dev_err(dev, "%s - uart_mode %d is invalid\n", __func__, v);
+
+	return count;
+}
+static DEVICE_ATTR_RW(uart_mode);
+
+static int ti_create_sysfs_attrs(struct usb_serial_port *port)
+{
+	return device_create_file(&port->dev, &dev_attr_uart_mode);
+}
+
+static int ti_remove_sysfs_attrs(struct usb_serial_port *port)
+{
+	device_remove_file(&port->dev, &dev_attr_uart_mode);
+	return 0;
+}
+
 static int ti_startup(struct usb_serial *serial)
 {
 	struct ti_device *tdev;
@@ -607,6 +647,7 @@ static void ti_release(struct usb_serial *serial)
 static int ti_port_probe(struct usb_serial_port *port)
 {
 	struct ti_port *tport;
+	int status;
 
 	tport = kzalloc(sizeof(*tport), GFP_KERNEL);
 	if (!tport)
@@ -628,6 +669,12 @@ static int ti_port_probe(struct usb_serial_port *port)
 
 	usb_set_serial_port_data(port, tport);
 
+	status = ti_create_sysfs_attrs(port);
+	if (status) {
+		kfree(tport);
+		return status;
+	}
+
 	port->port.drain_delay = 3;
 
 	return 0;
@@ -638,6 +685,7 @@ static int ti_port_remove(struct usb_serial_port *port)
 	struct ti_port *tport;
 
 	tport = usb_get_serial_port_data(port);
+	ti_remove_sysfs_attrs(port);
 	kfree(tport);
 
 	return 0;
-- 
2.13.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] USB: serial: ti_usb_3410_5052: Port uart_mode from io_ti.

[Stuart Longland]

[-- Attachment #1.1: Type: text/plain, Size: 961 bytes --]

Hi all,

On 18/08/17 12:56, Stuart Longland wrote:
> This introduces the `uart_mode` sysfs attribute as seen in the `io_ti`
> USB serial driver, allowing this USB serial interface to be switched
> between RS-232, 2-wire RS-485 and 4-wire RS-485.
> 
> /sys/class/tty/ttyUSB${num}/device/uart takes a single integer:
… and of course, I meant 'uart_mode' here, not 'uart'.

> 
> 	0:	RS-232 mode (default for RS-232-compatible dongles)
> 	1:	RS-485 2w mode (default for RS-485-only dongles)
> 	2:	RS-485 4w mode / RS-422 mode

This is of course, not a very elegant solution, but it gets me out of a
bind for now and at least gets the RS-485 functionality of this USB
serial dongle working.

Long term, I think the earlier ideas of expanding the RS-485 related
ioctls should be pursued.  I'm open to ideas here.

Regards,
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] USB: serial: ti_usb_3410_5052: Port uart_mode from io_ti.

[Maksim Salau]

Hi Stuart,

> This introduces the `uart_mode` sysfs attribute as seen in the `io_ti`
> USB serial driver, allowing this USB serial interface to be switched
> between RS-232, 2-wire RS-485 and 4-wire RS-485.

Recently I've discovered a blog post by Greg Kroah-Hartman on sysfs files [1].
I believe this information will help you to create the new file in a better way.

[1] http://kroah.com/log/blog/2013/06/26/how-to-create-a-sysfs-file-correctly/

Best regards,
Maksim.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] USB: serial: ti_usb_3410_5052: Port uart_mode from io_ti.

[Stuart Longland]

Hi Maksim,
On 20/08/17 06:40, Maksim Salau wrote:
>> This introduces the `uart_mode` sysfs attribute as seen in the `io_ti`
>> USB serial driver, allowing this USB serial interface to be switched
>> between RS-232, 2-wire RS-485 and 4-wire RS-485.
> 
> Recently I've discovered a blog post by Greg Kroah-Hartman on sysfs files [1].
> I believe this information will help you to create the new file in a better way.
> 
> [1] http://kroah.com/log/blog/2013/06/26/how-to-create-a-sysfs-file-correctly/

I'll definitely look into that… however I think the long-term plan in
this case is to expand the RS-485 IOCTL once some research is done into
what settings it should include.

I personally would like to see a sysfs interface in addition to enable
the possibility of udev rules configuring a port prior to its use,
however others have indicated that may result in a race condition.  A
dual-interface (ioctl + sysfs) would give us the best of both worlds,
and that link sounds like an ideal way of doing the sysfs part.
-- 
Stuart Longland
Systems Engineer
     _ ___
\  /|_) |                           T: +61 7 3535 9619
 \/ | \ |     38b Douglas Street    F: +61 7 3535 9699
   SYSTEMS    Milton QLD 4064       http://www.vrt.com.au
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] USB: serial: ti_usb_3410_5052: Port uart_mode from io_ti.

[Greg KH]

On Fri, Aug 18, 2017 at 12:56:59PM +1000, Stuart Longland wrote:
> This introduces the `uart_mode` sysfs attribute as seen in the `io_ti`
> USB serial driver, allowing this USB serial interface to be switched
> between RS-232, 2-wire RS-485 and 4-wire RS-485.
> 
> /sys/class/tty/ttyUSB${num}/device/uart takes a single integer:
> 
> 	0:	RS-232 mode (default for RS-232-compatible dongles)
> 	1:	RS-485 2w mode (default for RS-485-only dongles)
> 	2:	RS-485 4w mode / RS-422 mode
> 
> Write this *before* opening your serial device.

Please don't create random driver-specific sysfs files for something as
generic as this type of userspace api.

Also, you didn't create a Documentation/ABI/ file describing this, so
even if I wanted to take it, I couldn't :)

Anyway, work on a "real" solution for this for all serial devices
please.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html