On Thu, 12 Nov 2015 17:33:53 +0300 "Matwey V. Kornilov" <matwey@xxxxxxxxxx> wrote: > This flag is supposed to be used by uart drivers using software rs485 direction control. > > Signed-off-by: Matwey V. Kornilov <matwey@xxxxxxxxxx> > --- > include/uapi/linux/serial.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/include/uapi/linux/serial.h b/include/uapi/linux/serial.h > index 25331f9..95b15ca 100644 > --- a/include/uapi/linux/serial.h > +++ b/include/uapi/linux/serial.h > @@ -121,6 +121,9 @@ struct serial_rs485 { > #define SER_RS485_RTS_AFTER_SEND (1 << 2) /* Logical level for > RTS pin after sent*/ > #define SER_RS485_RX_DURING_TX (1 << 4) > +#define SER_RS485_SOFTWARE (1 << 5) /* Software > + implementation is > + being used */ I've only got one question here - why do we need this flag. Why does the application care whether the timer is in the kernel or in the chip. In particular think about cases where some combinations of features require software fallback and others don't. What would the flag indicate then. The patches look nice but I'd strongly favour not having a software flag. It should never matter as the kernel API is the same in all cases and we should therefore discourage application code from trying to know things it doesn't need to worry about. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html