All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Hurley <peter@hurleysoftware.com>
To: "Matwey V. Kornilov" <matwey@sai.msu.ru>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	jslaby@suse.com, linux-serial@vger.kernel.org,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 1/3] tty: Introduce UART_CAP_HW485
Date: Sat, 7 Nov 2015 17:04:43 -0500	[thread overview]
Message-ID: <563E757B.8000900@hurleysoftware.com> (raw)
In-Reply-To: <CAJs94EZWank18fbZKyJzqdEeVLA3zAWvBjK9rxDr1SXTq5P34A@mail.gmail.com>

On 11/07/2015 04:10 PM, Matwey V. Kornilov wrote:
> 2015-11-07 18:32 GMT+03:00 Peter Hurley <peter@hurleysoftware.com>:
>> On 11/07/2015 07:39 AM, Matwey V. Kornilov wrote:
>>> 2015-11-07 15:22 GMT+03:00 Peter Hurley <peter@hurleysoftware.com>:
>>>> On 11/07/2015 05:09 AM, Matwey V. Kornilov wrote:
>>>>> Introduce new capability UART_CAP_HW485 to mark 8250 UARTs which have
>>>>> hardware support of line direction control.
>>>>
>>>> Since capabilities are not exported to user-space, how will user-space
>>>> know if the port only provides emulated 485 (eg., where only HW485 is
>>>> acceptable)?
>>>
>>> I cannot imagine the case when user really has to care about
>>> implementation details.
>>> In both cases the user will be provided with the consistent API
>>> (TIOCGRS485/TIOCSRS485 ioctls) resulting into the same behavior.
>>> Could you please expand your question?
>>
>> Well, the entire serial core is a 'consistent' API but yet we
>> still report to user-space what the port type is. Same with lspci
>> and lsusb.
> 
> Yes, that is correct.
> I mean if you want the knowledge about HW485 be provided to the
> user-space via some ioctl, then I cannot understand what application
> is going to do with it.
> It has single one option: use provided RS485 if it needs RS485, it
> cannot purchase and install other hardware in runtime.
> But I think we could add new read-only flag to struct serial_rs485,
> say SER_RS485_SOFTWARE then user will know that software emulation is
> being used.
> Would it be ok?

Yes, something like that would be fine.

Regards,
Peter Hurley


>>>>> Signed-off-by: Matwey V. Kornilov <matwey@sai.msu.ru>
>>>>> ---
>>>>> Changes since v1:
>>>>>  - Commit message has been wrapped
>>>>>
>>>>>  drivers/tty/serial/8250/8250.h         | 1 +
>>>>>  drivers/tty/serial/8250/8250_fintek.c  | 1 +
>>>>>  drivers/tty/serial/8250/8250_lpc18xx.c | 1 +
>>>>>  drivers/tty/serial/8250/8250_pci.c     | 1 +
>>>>>  4 files changed, 4 insertions(+)
>>>>>
>>>>> diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
>>>>> index d54dcd8..92a4f47 100644
>>>>> --- a/drivers/tty/serial/8250/8250.h
>>>>> +++ b/drivers/tty/serial/8250/8250.h
>>>>> @@ -69,6 +69,7 @@ struct serial8250_config {
>>>>>       unsigned int    flags;
>>>>>  };
>>>>>
>>>>> +#define UART_CAP_HW485       (1 << 7)        /* UART has hardware direction control for RS485 */
>>>>>  #define UART_CAP_FIFO        (1 << 8)        /* UART has FIFO */
>>>>>  #define UART_CAP_EFR (1 << 9)        /* UART has EFR */
>>>>>  #define UART_CAP_SLEEP       (1 << 10)       /* UART has IER sleep */
>>>>> diff --git a/drivers/tty/serial/8250/8250_fintek.c b/drivers/tty/serial/8250/8250_fintek.c
>>>>> index 8947439..f2831a8 100644
>>>>> --- a/drivers/tty/serial/8250/8250_fintek.c
>>>>> +++ b/drivers/tty/serial/8250/8250_fintek.c
>>>>> @@ -208,6 +208,7 @@ fintek_8250_probe(struct pnp_dev *dev, const struct pnp_device_id *dev_id)
>>>>>       uart.port.iobase = pnp_port_start(dev, 0);
>>>>>       uart.port.iotype = UPIO_PORT;
>>>>>       uart.port.rs485_config = fintek_8250_rs485_config;
>>>>> +     uart.capabilities = UART_CAP_HW485;
>>>>>
>>>>>       uart.port.flags |= UPF_SKIP_TEST | UPF_BOOT_AUTOCONF;
>>>>>       if (pnp_irq_flags(dev, 0) & IORESOURCE_IRQ_SHAREABLE)
>>>>> diff --git a/drivers/tty/serial/8250/8250_lpc18xx.c b/drivers/tty/serial/8250/8250_lpc18xx.c
>>>>> index 99cd478..9d30276 100644
>>>>> --- a/drivers/tty/serial/8250/8250_lpc18xx.c
>>>>> +++ b/drivers/tty/serial/8250/8250_lpc18xx.c
>>>>> @@ -175,6 +175,7 @@ static int lpc18xx_serial_probe(struct platform_device *pdev)
>>>>>       uart.port.private_data = data;
>>>>>       uart.port.rs485_config = lpc18xx_rs485_config;
>>>>>       uart.port.serial_out = lpc18xx_uart_serial_out;
>>>>> +     uart.capabilities = UART_CAP_HW485;
>>>>>
>>>>>       uart.dma = &data->dma;
>>>>>       uart.dma->rxconf.src_maxburst = 1;
>>>>> diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
>>>>> index 4097f3f..c7c0ae9 100644
>>>>> --- a/drivers/tty/serial/8250/8250_pci.c
>>>>> +++ b/drivers/tty/serial/8250/8250_pci.c
>>>>> @@ -1599,6 +1599,7 @@ static int pci_fintek_setup(struct serial_private *priv,
>>>>>       port->port.iotype = UPIO_PORT;
>>>>>       port->port.iobase = iobase;
>>>>>       port->port.rs485_config = pci_fintek_rs485_config;
>>>>> +     port->capabilities = UART_CAP_HW485;
>>>>>
>>>>>       data = devm_kzalloc(&pdev->dev, sizeof(u8), GFP_KERNEL);
>>>>>       if (!data)


      reply	other threads:[~2015-11-07 22:04 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-07 10:09 [PATCH v2 1/3] tty: Introduce UART_CAP_HW485 Matwey V. Kornilov
2015-11-07 10:09 ` [PATCH v2 2/3] tty: Implement default fallback serial8250_rs485_config Matwey V. Kornilov
2015-11-07 12:29   ` Peter Hurley
2015-11-07 13:51     ` Matwey V. Kornilov
2015-11-07 14:20       ` Peter Hurley
2015-11-07 10:09 ` [PATCH v2 3/3] tty: Add software emulated RS485 support for 8250 Matwey V. Kornilov
2015-11-07 16:03   ` Peter Hurley
2015-11-08 10:52     ` Matwey V. Kornilov
2015-11-09 14:40       ` Peter Hurley
2015-11-09 15:45         ` Matwey V. Kornilov
2015-11-09 21:30           ` Peter Hurley
2015-11-09 21:43             ` Matwey V. Kornilov
2015-11-09 22:05               ` Peter Hurley
2015-11-10 11:35                 ` Matwey V. Kornilov
2015-11-10 16:12   ` Peter Hurley
2015-11-10 16:25     ` Matwey V. Kornilov
2015-11-10 16:52       ` Peter Hurley
2015-11-12 12:34     ` Matwey V. Kornilov
2015-11-12 13:35       ` Peter Hurley
2015-11-13  8:35         ` Matwey V. Kornilov
2015-11-07 12:22 ` [PATCH v2 1/3] tty: Introduce UART_CAP_HW485 Peter Hurley
2015-11-07 12:39   ` Matwey V. Kornilov
2015-11-07 15:32     ` Peter Hurley
2015-11-07 21:10       ` Matwey V. Kornilov
2015-11-07 22:04         ` Peter Hurley [this message]

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=563E757B.8000900@hurleysoftware.com \
    --to=peter@hurleysoftware.com \
    --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.