Hi, > > There are historical reasons for a lot of things, but that's not > > necessarily a reason to continue taking shortcuts. > > But on second thought, I think your approach here makes sense. If > usbserial ever gains generic IXON support, we'd just fall back to the > line-discipline implementation whenever the control characters do no > match.
Which wouldn't preclude indicating lack of support while the support is lacking?! I mean, unless there is a good reason to pretend ... (And if anything, the usb serial framework could use that indication to recognize the lack of support in a given driver for a given configuration, while with the current code there is no way to determine when a generic/software implementation would have to be enabled?!) > bools), and mention why you implemented things the way you did in the > commit message. Not sure what to mention there?! I mean, for the IXON/!IXANY/^S/^Q case, I implemented things the way I did because that makes the hardware behave the way that a serial interface should behave when IXON/!IXANY/^S/^Q is configured, obviously. For all other cases, I have no clue why the behaviour is the way it is, as I am just preserving existing behaviour that was decided by others before me and the reasons for which are unknown to me. Regards, Florian -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
