All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Hurley <peter@hurleysoftware.com>
To: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
	"Matwey V. Kornilov" <matwey@sai.msu.ru>
Cc: gregkh@linuxfoundation.org, jslaby@suse.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
Date: Thu, 12 Nov 2015 15:22:10 -0500	[thread overview]
Message-ID: <5644F4F2.2080408@hurleysoftware.com> (raw)
In-Reply-To: <20151112195707.5e9cb1d8@lxorguk.ukuu.org.uk>

On 11/12/2015 02:57 PM, One Thousand Gnomes wrote:
> On Thu, 12 Nov 2015 17:33:53 +0300
> "Matwey V. Kornilov" <matwey@sai.msu.ru> wrote:
> 
>> This flag is supposed to be used by uart drivers using software rs485 direction control.
>>
>> Signed-off-by: Matwey V. Kornilov <matwey@sai.msu.ru>
>> ---
>>  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

  reply	other threads:[~2015-11-12 20:22 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-12 14:33 [PATCH v3 0/5] tty: Introduce software RS485 direction control support Matwey V. Kornilov
2015-11-12 14:33 ` [PATCH v3 1/5] tty: Introduce UART_CAP_HW485 Matwey V. Kornilov
2015-11-12 14:33 ` [PATCH v3 2/5] tty: Introduce SER_RS485_SOFTWARE read-only flag for struct serial_rs485 Matwey V. Kornilov
2015-11-12 19:57   ` One Thousand Gnomes
2015-11-12 20:22     ` Peter Hurley [this message]
2015-11-13  0:41       ` Andy Shevchenko
2015-11-13  1:11         ` Peter Hurley
2015-11-13  1:26           ` Andy Shevchenko
2015-11-13  1:55             ` Peter Hurley
2015-11-14 15:25       ` One Thousand Gnomes
2015-11-16 19:18         ` Peter Hurley
2015-11-17  8:20           ` Matwey V. Kornilov
2015-11-18 18:33             ` Peter Hurley
2015-11-18 19:39               ` Matwey V. Kornilov
2015-11-18 19:49                 ` Matwey V. Kornilov
2015-12-02 23:20                   ` Peter Hurley
2015-12-03  5:50                     ` Matwey V. Kornilov
2015-12-03 14:41                       ` Peter Hurley
2015-12-03 17:29                         ` Matwey V. Kornilov
2015-12-03 19:45                           ` Peter Hurley
2015-12-04 17:50                             ` Matwey V. Kornilov
2015-11-13 20:03     ` Matwey V. Kornilov
2015-11-12 14:33 ` [PATCH v3 3/5] tty: Implement default fallback serial8250_rs485_config Matwey V. Kornilov
2015-11-12 14:33 ` [PATCH v3 4/5] tty: Move serial8250_stop_rx in front of serial8250_start_tx Matwey V. Kornilov
2015-11-12 14:33 ` [PATCH v3 5/5] tty: Add software emulated RS485 support for 8250 Matwey V. Kornilov
2015-11-12 14:48   ` Andy Shevchenko
2015-11-17  9:24   ` Uwe Kleine-König
2015-11-17 10:25     ` Matwey V. Kornilov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5644F4F2.2080408@hurleysoftware.com \
    --to=peter@hurleysoftware.com \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=matwey@sai.msu.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.