Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753158AbbKLUWQ (ORCPT ); Thu, 12 Nov 2015 15:22:16 -0500 Received: from mail-io0-f174.google.com ([209.85.223.174]:34225 "EHLO mail-io0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752899AbbKLUWO (ORCPT ); Thu, 12 Nov 2015 15:22:14 -0500 Subject: Re: [PATCH v3 2/5] tty: Introduce SER_RS485_SOFTWARE read-only flag for struct serial_rs485 To: One Thousand Gnomes , "Matwey V. Kornilov" 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> Cc: gregkh@linuxfoundation.org, jslaby@suse.com, linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org From: Peter Hurley Message-ID: <5644F4F2.2080408@hurleysoftware.com> Date: Thu, 12 Nov 2015 15:22:10 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151112195707.5e9cb1d8@lxorguk.ukuu.org.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2547 Lines: 57 On 11/12/2015 02:57 PM, One Thousand Gnomes wrote: > 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. I specifically asked for it. I can think of 2 reasons that userspace wants to know: 1. Because the characteristics of the software emulation are unacceptable so the application wants to terminate w/error rather than continue. 2. Because userspace will use different values for h/w vs. s/w. For example, right now, the emulation will raise/lower RTS prematurely when tx ends if the rts-after-send timer is 0. I agree that combination features might be problematic. An illustrative (kernel-space) example is the mess that is dmaengine_pause(). Some DMA implementations provide the means to stop and restart DMA without losing data and some DMA implementations do not. Unfortunately, some advertise they support dmaengine_pause() but only for lossy uses like audio. Because the api hides this, the query interface for pause support is useless. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/