From: Andreas Werner <andreas.werner@men.de>
To: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>
Cc: Wolfgang Grandegger <wg@grandegger.com>,
Andreas Werner <andreas.werner@men.de>, <mkl@pengutronix.de>,
<linux-can@vger.kernel.org>, <netdev@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <davem@davemloft.net>,
<jthumshirn@suse.de>, <andy@wernerandy.de>,
<michael.miehling@men.de>
Subject: Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver
Date: Mon, 8 Aug 2016 16:12:39 +0200 [thread overview]
Message-ID: <20160808141239.GB1733@awelinux> (raw)
In-Reply-To: <20160808130633.GC12298@airbook.newtec.eu>
On Mon, Aug 08, 2016 at 03:06:33PM +0200, Kurt Van Dijck wrote:
>
> --- Original message ---
> > Date: Mon, 8 Aug 2016 14:28:39 +0200
> > From: Wolfgang Grandegger <wg@grandegger.com>
> >
> [...]
> > >>>+
> > >>>+ if (!(cf->can_id & CAN_RTR_FLAG)) {
> > >>>+ writel(data[0], &cf_buf->data[0]);
> > >>>+ writel(data[1], &cf_buf->data[1]);
> > >>
> > >>Why do you not check cf->can_dlc here as well. And is the extra copy
> > >>necessary.
> > >>
> > >
> > >Yes, I agree with you. The extra copy could be also avoided.
> > >
> > >>>+
> > >>>+ stats->tx_bytes += cf->can_dlc;
> > >>>+ }
> > >>
> > >>If I look to other drivers, they write the data even in case of RTR.
> > >>
> > >
> > >But why?
> > >
> > >A RTR does not have any data, therefore there is no need to write the data.
> > >Only the length is required as the request size.
> >
> > Yes; I'm wondering as well.
> >
> > >
> > >If there is a reason behind writing the data of a RTR frame, I can
> > >change that, but for now there is no reason.
> >
> > Yep.
>
> I _think_ that copying the data without checking the RTR bit clearly
> avoids a condition and might produce faster code on some machines.
> In any case, it reads easier.
> I'm not sure how that interacts with caches etc etc.
>
> On the other hand, giving unused data is a bad habit that may reveal
> security information on some places, so better avoid it.
>
> Kurt
Hi Kurt,
thanks for your comment.
In my opinion, I really prever to NOT copying such data if the RTR flag ist set.
Regards
Andy
next prev parent reply other threads:[~2016-08-08 14:12 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-26 9:16 [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver Andreas Werner
2016-08-08 3:58 ` Benjamin Poirier
2016-08-08 7:26 ` Andreas Werner
2016-08-09 3:23 ` Benjamin Poirier
2016-08-09 6:11 ` Andreas Werner
2016-08-08 9:27 ` Wolfgang Grandegger
2016-08-08 11:39 ` Andreas Werner
2016-08-08 12:28 ` Wolfgang Grandegger
2016-08-08 13:06 ` Kurt Van Dijck
2016-08-08 14:12 ` Andreas Werner [this message]
2016-08-08 14:05 ` Andreas Werner
2016-08-08 14:35 ` Wolfgang Grandegger
2016-08-09 6:10 ` Andreas Werner
2016-08-09 11:54 ` Wolfgang Grandegger
2016-08-10 20:28 ` Oliver Hartkopp
2016-08-11 7:14 ` Andreas Werner
2016-08-11 8:45 ` Oliver Hartkopp
2016-08-11 8:58 ` Andreas Werner
2016-08-11 11:46 ` Oliver Hartkopp
2016-08-09 9:35 ` Ramesh Shanmugasundaram
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=20160808141239.GB1733@awelinux \
--to=andreas.werner@men.de \
--cc=andy@wernerandy.de \
--cc=davem@davemloft.net \
--cc=dev.kurt@vandijck-laurijssen.be \
--cc=jthumshirn@suse.de \
--cc=linux-can@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.miehling@men.de \
--cc=mkl@pengutronix.de \
--cc=netdev@vger.kernel.org \
--cc=wg@grandegger.com \
/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