diff mbox

[2/3] serial: 8250_omap: check how many bytes were injected

Message ID 1439568064-7907-2-git-send-email-bigeasy@linutronix.de (mailing list archive)
State New, archived
Headers show

Commit Message

Sebastian Andrzej Siewior Aug. 14, 2015, 4:01 p.m. UTC
The function tty_insert_flip_string() returns an int and as such it
might fail. So the result is that I kindly asked to insert 48 bytes and
the function only insterted 32.
I have no idea what to do with the remaining 16 so I think dropping them
is the only option. I also increase the buf_overrun counter so userpace
has a clue that we lost bytes.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
 drivers/tty/serial/8250/8250_omap.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

Comments

Sekhar Nori Aug. 26, 2015, 9:38 a.m. UTC | #1
On Friday 14 August 2015 09:31 PM, Sebastian Andrzej Siewior wrote:
> The function tty_insert_flip_string() returns an int and as such it
> might fail. So the result is that I kindly asked to insert 48 bytes and
> the function only insterted 32.
> I have no idea what to do with the remaining 16 so I think dropping them
> is the only option. I also increase the buf_overrun counter so userpace
> has a clue that we lost bytes.
> 
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>

Tested with wilink BT module on TI's DRA7 EVM.

Tested-by: Sekhar Nori <nsekhar@ti.com>

Thanks,
Sekhar

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Peter Hurley Aug. 26, 2015, 12:44 p.m. UTC | #2
On 08/14/2015 12:01 PM, Sebastian Andrzej Siewior wrote:
> The function tty_insert_flip_string() returns an int and as such it
> might fail. So the result is that I kindly asked to insert 48 bytes and
> the function only insterted 32.
> I have no idea what to do with the remaining 16 so I think dropping them
> is the only option. I also increase the buf_overrun counter so userpace
> has a clue that we lost bytes.

No objection to the patch but I'm curious whether this is something you've
actually observed and under what circumstances.

Regards,
Peter Hurley


> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
>  drivers/tty/serial/8250/8250_omap.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
> index 2ac63c8bd946..933f7ef2c004 100644
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
> @@ -738,6 +738,7 @@ static void __dma_rx_do_complete(struct uart_8250_port *p, bool error)
>  	struct dma_tx_state     state;
>  	int                     count;
>  	unsigned long		flags;
> +	int			ret;
>  
>  	dma_sync_single_for_cpu(dma->rxchan->device->dev, dma->rx_addr,
>  				dma->rx_size, DMA_FROM_DEVICE);
> @@ -753,8 +754,10 @@ static void __dma_rx_do_complete(struct uart_8250_port *p, bool error)
>  
>  	count = dma->rx_size - state.residue;
>  
> -	tty_insert_flip_string(tty_port, dma->rx_buf, count);
> -	p->port.icount.rx += count;
> +	ret = tty_insert_flip_string(tty_port, dma->rx_buf, count);
> +
> +	p->port.icount.rx += ret;
> +	p->port.icount.buf_overrun += count - ret;
>  unlock:
>  	spin_unlock_irqrestore(&priv->rx_dma_lock, flags);
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sekhar Nori Aug. 26, 2015, 1:01 p.m. UTC | #3
On Wednesday 26 August 2015 06:14 PM, Peter Hurley wrote:
> On 08/14/2015 12:01 PM, Sebastian Andrzej Siewior wrote:
>> The function tty_insert_flip_string() returns an int and as such it
>> might fail. So the result is that I kindly asked to insert 48 bytes and
>> the function only insterted 32.
>> I have no idea what to do with the remaining 16 so I think dropping them
>> is the only option. I also increase the buf_overrun counter so userpace
>> has a clue that we lost bytes.
> 
> No objection to the patch but I'm curious whether this is something you've
> actually observed and under what circumstances.

This was observed while doing a UART internal loopback test at 3Mbaud on
TI's DRA7 EVM.

Thanks,
Sekhar

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
index 2ac63c8bd946..933f7ef2c004 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -738,6 +738,7 @@  static void __dma_rx_do_complete(struct uart_8250_port *p, bool error)
 	struct dma_tx_state     state;
 	int                     count;
 	unsigned long		flags;
+	int			ret;
 
 	dma_sync_single_for_cpu(dma->rxchan->device->dev, dma->rx_addr,
 				dma->rx_size, DMA_FROM_DEVICE);
@@ -753,8 +754,10 @@  static void __dma_rx_do_complete(struct uart_8250_port *p, bool error)
 
 	count = dma->rx_size - state.residue;
 
-	tty_insert_flip_string(tty_port, dma->rx_buf, count);
-	p->port.icount.rx += count;
+	ret = tty_insert_flip_string(tty_port, dma->rx_buf, count);
+
+	p->port.icount.rx += ret;
+	p->port.icount.buf_overrun += count - ret;
 unlock:
 	spin_unlock_irqrestore(&priv->rx_dma_lock, flags);