* [PATCH] net: altera_tse: fix msgdma_tx_completion on non-zero fill_level case
@ 2019-01-21 8:29 Atsushi Nemoto
2019-01-22 17:20 ` Thor Thayer
0 siblings, 1 reply; 5+ messages in thread
From: Atsushi Nemoto @ 2019-01-21 8:29 UTC (permalink / raw)
To: Thor Thayer, netdev; +Cc: Tomonori Sakita
From: Tomonori Sakita <tomonori.sakita@sord.co.jp>
If fill_level was not zero and status was not BUSY,
result of "tx_prod - tx_cons - inuse" might be zero.
Subtracting 1 unconditionally results invalid negative return value
on this case.
The subtraction is not needed if fill_level was not zero.
Signed-off-by: Tomonori Sakita <tomonori.sakita@sord.co.jp>
Signed-off-by: Atsushi Nemoto <atsushi.nemoto@sord.co.jp>
---
drivers/net/ethernet/altera/altera_msgdma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/altera/altera_msgdma.c b/drivers/net/ethernet/altera/altera_msgdma.c
index 0fb986b..3df73d3 100644
--- a/drivers/net/ethernet/altera/altera_msgdma.c
+++ b/drivers/net/ethernet/altera/altera_msgdma.c
@@ -145,7 +145,7 @@ u32 msgdma_tx_completions(struct altera_tse_private *priv)
& 0xffff;
if (inuse) { /* Tx FIFO is not empty */
- ready = priv->tx_prod - priv->tx_cons - inuse - 1;
+ ready = priv->tx_prod - priv->tx_cons - inuse;
} else {
/* Check for buffered last packet */
status = csrrd32(priv->tx_dma_csr, msgdma_csroffs(status));
--
2.1.4
^ permalink raw reply related [flat|nested] 5+ messages in thread* Re: [PATCH] net: altera_tse: fix msgdma_tx_completion on non-zero fill_level case
2019-01-21 8:29 [PATCH] net: altera_tse: fix msgdma_tx_completion on non-zero fill_level case Atsushi Nemoto
@ 2019-01-22 17:20 ` Thor Thayer
2019-01-23 22:47 ` Dalon L Westergreen
0 siblings, 1 reply; 5+ messages in thread
From: Thor Thayer @ 2019-01-22 17:20 UTC (permalink / raw)
To: Atsushi Nemoto, netdev; +Cc: Tomonori Sakita, Dalon Westergreen
On 1/21/19 2:29 AM, Atsushi Nemoto wrote:
> From: Tomonori Sakita <tomonori.sakita@sord.co.jp>
>
> If fill_level was not zero and status was not BUSY,
> result of "tx_prod - tx_cons - inuse" might be zero.
> Subtracting 1 unconditionally results invalid negative return value
> on this case.
> The subtraction is not needed if fill_level was not zero.
>
> Signed-off-by: Tomonori Sakita <tomonori.sakita@sord.co.jp>
> Signed-off-by: Atsushi Nemoto <atsushi.nemoto@sord.co.jp>
> ---
> drivers/net/ethernet/altera/altera_msgdma.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/altera/altera_msgdma.c b/drivers/net/ethernet/altera/altera_msgdma.c
> index 0fb986b..3df73d3 100644
> --- a/drivers/net/ethernet/altera/altera_msgdma.c
> +++ b/drivers/net/ethernet/altera/altera_msgdma.c
> @@ -145,7 +145,7 @@ u32 msgdma_tx_completions(struct altera_tse_private *priv)
> & 0xffff;
>
> if (inuse) { /* Tx FIFO is not empty */
> - ready = priv->tx_prod - priv->tx_cons - inuse - 1;
> + ready = priv->tx_prod - priv->tx_cons - inuse;
> } else {
> /* Check for buffered last packet */
> status = csrrd32(priv->tx_dma_csr, msgdma_csroffs(status));
>
I'm adding Dalon who has done a lot of work on msgdma. I'd like to get
his comments.
Thanks,
Thor
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH] net: altera_tse: fix msgdma_tx_completion on non-zero fill_level case
2019-01-22 17:20 ` Thor Thayer
@ 2019-01-23 22:47 ` Dalon L Westergreen
2019-01-24 5:05 ` Atsushi Nemoto
0 siblings, 1 reply; 5+ messages in thread
From: Dalon L Westergreen @ 2019-01-23 22:47 UTC (permalink / raw)
To: thor.thayer, Atsushi Nemoto, netdev; +Cc: Tomonori Sakita
On Tue, 2019-01-22 at 11:20 -0600, Thor Thayer wrote:
> On 1/21/19 2:29 AM, Atsushi Nemoto wrote:
> > From: Tomonori Sakita <tomonori.sakita@sord.co.jp>
> >
> > If fill_level was not zero and status was not BUSY,
> > result of "tx_prod - tx_cons - inuse" might be zero.
> > Subtracting 1 unconditionally results invalid negative return value
> > on this case.
> > The subtraction is not needed if fill_level was not zero.
> >
> > Signed-off-by: Tomonori Sakita <tomonori.sakita@sord.co.jp>
> > Signed-off-by: Atsushi Nemoto <atsushi.nemoto@sord.co.jp>
> > ---
> > drivers/net/ethernet/altera/altera_msgdma.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/altera/altera_msgdma.c
> > b/drivers/net/ethernet/altera/altera_msgdma.c
> > index 0fb986b..3df73d3 100644
> > --- a/drivers/net/ethernet/altera/altera_msgdma.c
> > +++ b/drivers/net/ethernet/altera/altera_msgdma.c
> > @@ -145,7 +145,7 @@ u32 msgdma_tx_completions(struct altera_tse_private
> > *priv)
> > & 0xffff;
> >
> > if (inuse) { /* Tx FIFO is not empty */
> > - ready = priv->tx_prod - priv->tx_cons - inuse - 1;
> > + ready = priv->tx_prod - priv->tx_cons - inuse;
dont think my last email went through..
I am not sure about this. This register indicates the number of entries
still to be processed by the dma. the -1 is intended to represent the
decriptor currently being processed. If ready is
priv->tx_prod - priv->tx_cons - inuse couldn't you end up processing 1
too many packets? IE: ready is 1 greater then the actual completed
packets?
I do agree that we should not be returning a negative value, but i dont
think i agree removing the -1 is the answer. perhaps just check that ready
is greater than 0?
--dalon
> > } else {
> > /* Check for buffered last packet */
> > status = csrrd32(priv->tx_dma_csr, msgdma_csroffs(status));
> >
>
> I'm adding Dalon who has done a lot of work on msgdma. I'd like to get
> his comments.
>
> Thanks,
>
> Thor
>
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH] net: altera_tse: fix msgdma_tx_completion on non-zero fill_level case
2019-01-23 22:47 ` Dalon L Westergreen
@ 2019-01-24 5:05 ` Atsushi Nemoto
2019-01-24 14:57 ` Dalon L Westergreen
0 siblings, 1 reply; 5+ messages in thread
From: Atsushi Nemoto @ 2019-01-24 5:05 UTC (permalink / raw)
To: dalon.westergreen; +Cc: thor.thayer, netdev, tomonori.sakita
On Wed, 23 Jan 2019 14:47:06 -0800, Dalon L Westergreen <dalon.westergreen@linux.intel.com> wrote:
>> > if (inuse) { /* Tx FIFO is not empty */
>> > - ready = priv->tx_prod - priv->tx_cons - inuse - 1;
>> > + ready = priv->tx_prod - priv->tx_cons - inuse;
> dont think my last email went through..
>
> I am not sure about this. This register indicates the number of entries
> still to be processed by the dma. the -1 is intended to represent the
> decriptor currently being processed. If ready is
> priv->tx_prod - priv->tx_cons - inuse couldn't you end up processing 1
> too many packets? IE: ready is 1 greater then the actual completed
> packets?
>
> I do agree that we should not be returning a negative value, but i dont
> think i agree removing the -1 is the answer. perhaps just check that ready
> is greater than 0?
Thank you for review.
I agree with you. It would be OK returning a possibly off-by-one
value unless it is not an negative value.
Then, how about this instead?
--- a/drivers/net/ethernet/altera/altera_msgdma.c
+++ b/drivers/net/ethernet/altera/altera_msgdma.c
@@ -145,7 +145,8 @@ u32 msgdma_tx_completions(struct altera_tse_private *priv)
& 0xffff;
if (inuse) { /* Tx FIFO is not empty */
- ready = priv->tx_prod - priv->tx_cons - inuse - 1;
+ ready = max_t(int,
+ priv->tx_prod - priv->tx_cons - inuse - 1, 0);
} else {
/* Check for buffered last packet */
status = csrrd32(priv->tx_dma_csr, msgdma_csroffs(status));
--
If it was OK, I will post an updated patch.
---
Atsushi Nemoto
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH] net: altera_tse: fix msgdma_tx_completion on non-zero fill_level case
2019-01-24 5:05 ` Atsushi Nemoto
@ 2019-01-24 14:57 ` Dalon L Westergreen
0 siblings, 0 replies; 5+ messages in thread
From: Dalon L Westergreen @ 2019-01-24 14:57 UTC (permalink / raw)
To: Atsushi Nemoto; +Cc: thor.thayer, netdev, tomonori.sakita
On Thu, 2019-01-24 at 14:05 +0900, Atsushi Nemoto wrote:
> On Wed, 23 Jan 2019 14:47:06 -0800, Dalon L Westergreen <
> dalon.westergreen@linux.intel.com> wrote:
> > > > if (inuse) { /* Tx FIFO is not empty */
> > > > - ready = priv->tx_prod - priv->tx_cons - inuse - 1;
> > > > + ready = priv->tx_prod - priv->tx_cons - inuse;
> > dont think my last email went through..
> >
> > I am not sure about this. This register indicates the number of entries
> > still to be processed by the dma. the -1 is intended to represent the
> > decriptor currently being processed. If ready is
> > priv->tx_prod - priv->tx_cons - inuse couldn't you end up processing 1
> > too many packets? IE: ready is 1 greater then the actual completed
> > packets?
> >
> > I do agree that we should not be returning a negative value, but i dont
> > think i agree removing the -1 is the answer. perhaps just check that ready
> > is greater than 0?
>
> Thank you for review.
>
> I agree with you. It would be OK returning a possibly off-by-one
> value unless it is not an negative value.
>
> Then, how about this instead?
>
This works for me. thanks.
> --- a/drivers/net/ethernet/altera/altera_msgdma.c
> +++ b/drivers/net/ethernet/altera/altera_msgdma.c
> @@ -145,7 +145,8 @@ u32 msgdma_tx_completions(struct altera_tse_private *priv)
> & 0xffff;
>
> if (inuse) { /* Tx FIFO is not empty */
> - ready = priv->tx_prod - priv->tx_cons - inuse - 1;
> + ready = max_t(int,
> + priv->tx_prod - priv->tx_cons - inuse - 1, 0);
> } else {
> /* Check for buffered last packet */
> status = csrrd32(priv->tx_dma_csr, msgdma_csroffs(status));
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-01-24 14:57 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-01-21 8:29 [PATCH] net: altera_tse: fix msgdma_tx_completion on non-zero fill_level case Atsushi Nemoto
2019-01-22 17:20 ` Thor Thayer
2019-01-23 22:47 ` Dalon L Westergreen
2019-01-24 5:05 ` Atsushi Nemoto
2019-01-24 14:57 ` Dalon L Westergreen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox