From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932587AbbKMUDu (ORCPT ); Fri, 13 Nov 2015 15:03:50 -0500 Received: from mail-wm0-f47.google.com ([74.125.82.47]:33899 "EHLO mail-wm0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932436AbbKMUDr (ORCPT ); Fri, 13 Nov 2015 15:03:47 -0500 MIME-Version: 1.0 In-Reply-To: <20151112195707.5e9cb1d8@lxorguk.ukuu.org.uk> References: <1447338836-8785-1-git-send-email-matwey@sai.msu.ru> <1447338836-8785-3-git-send-email-matwey@sai.msu.ru> <20151112195707.5e9cb1d8@lxorguk.ukuu.org.uk> From: "Matwey V. Kornilov" Date: Fri, 13 Nov 2015 23:03:26 +0300 X-Google-Sender-Auth: wnYBjzVltt8rKPyvlaYSqh1GUxo Message-ID: Subject: Re: [PATCH v3 2/5] tty: Introduce SER_RS485_SOFTWARE read-only flag for struct serial_rs485 To: One Thousand Gnomes Cc: Greg KH , jslaby@suse.com, Peter Hurley , linux-kernel , linux-serial@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2015-11-12 22:57 GMT+03:00 One Thousand Gnomes : > On Thu, 12 Nov 2015 17:33:53 +0300 > "Matwey V. Kornilov" wrote: > >> This flag is supposed to be used by uart drivers using software rs485 direction control. >> >> Signed-off-by: Matwey V. Kornilov >> --- >> 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. > Peter asked for it, I respect his experience. Only two lines are required to implement this, so it is easy to add, easy to drop. > 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 > -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382