From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753018AbbKLUqx (ORCPT ); Thu, 12 Nov 2015 15:46:53 -0500 Received: from lxorguk.ukuu.org.uk ([81.2.110.251]:54819 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752005AbbKLUqv (ORCPT ); Thu, 12 Nov 2015 15:46:51 -0500 X-Greylist: delayed 2959 seconds by postgrey-1.27 at vger.kernel.org; Thu, 12 Nov 2015 15:46:50 EST Date: Thu, 12 Nov 2015 19:57:07 +0000 From: One Thousand Gnomes To: "Matwey V. Kornilov" Cc: gregkh@linuxfoundation.org, jslaby@suse.com, peter@hurleysoftware.com, linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org Subject: Re: [PATCH v3 2/5] tty: Introduce SER_RS485_SOFTWARE read-only flag for struct serial_rs485 Message-ID: <20151112195707.5e9cb1d8@lxorguk.ukuu.org.uk> In-Reply-To: <1447338836-8785-3-git-send-email-matwey@sai.msu.ru> References: <1447338836-8785-1-git-send-email-matwey@sai.msu.ru> <1447338836-8785-3-git-send-email-matwey@sai.msu.ru> Organization: Intel Corporation X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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