From: Dalon L Westergreen <dalon.westergreen@linux.intel.com>
To: thor.thayer@linux.intel.com,
Atsushi Nemoto <atsushi.nemoto@sord.co.jp>,
netdev@vger.kernel.org
Cc: Tomonori Sakita <tomonori.sakita@sord.co.jp>
Subject: Re: [PATCH] net: altera_tse: fix msgdma_tx_completion on non-zero fill_level case
Date: Wed, 23 Jan 2019 14:47:06 -0800 [thread overview]
Message-ID: <49028e9cdf59afe3d4184b9eee36f0d2406c8bdb.camel@linux.intel.com> (raw)
In-Reply-To: <d624692a-83d8-a74a-b9bd-d9cff79f362d@linux.intel.com>
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
>
next prev parent reply other threads:[~2019-01-23 22:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2019-01-24 5:05 ` Atsushi Nemoto
2019-01-24 14:57 ` Dalon L Westergreen
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=49028e9cdf59afe3d4184b9eee36f0d2406c8bdb.camel@linux.intel.com \
--to=dalon.westergreen@linux.intel.com \
--cc=atsushi.nemoto@sord.co.jp \
--cc=netdev@vger.kernel.org \
--cc=thor.thayer@linux.intel.com \
--cc=tomonori.sakita@sord.co.jp \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox