On Fri, 18 Feb 2011 20:32:10 +0100, Greg KH <greg@xxxxxxxxx> wrote:
Ok, this is a "custom" version of the driver, using a private ioctl,
that is not in the main kernel.org version of the driver. So the
utilities here will not work for you at all without you also running
their versions of the drivers.
That is how the modes are being changed, they are "cheating" :)
Indeed. And the reason these "custom" IOCTLs are not already included is
that they do not match the model currently in the kernel?
So there's not much we can do here, except that I would gladly take a
patch to implement this "properly" in the driver if someone creates it.
But what is the proper way of doing this? The device has a larger
capability than what the infrastructure already provides. I venture to
guess there are three alternatives:
1) Implement the "custom" ION_[S|G]ETMODE.
2) Implement a generic, standard way of setting and getting the UART-mode
of a device
3) Extend the TIOCGRS485/TIOCSRS485 way of doing this.
(I believe Alan was hinting at 3)
Since I have absolutely no idea how other real-world devices does this I'm
not sure which is the "correct" approach here. I have a Edgeport in my
possession and I might have an attempt on 1) - time permitting. 2) should
be the same effort as 1) given that a naming can be decided on... 3) to
me seems a bit restrictive since RS-485 is more than just (e.g.)
full-duplex, terminating DTE (which really is RS-422). Hence, as I
understands it, the current naming/implementation is a bit misleading -
and I can very well be wrong on this. :) (BTW: How can the driver revert
back to RS-232?)
-Frode
--
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
