From: Oliver Hartkopp <socketcan@hartkopp.net>
To: Wolfgang Grandegger <wg@grandegger.com>
Cc: Wolfram Sang <w.sang@pengutronix.de>,
Linux Netdev List <netdev@vger.kernel.org>,
Andre Naujoks <nautsch@gmail.com>
Subject: Re: [PATCH net] mscan: zero accidentally copied register content
Date: Thu, 06 Oct 2011 16:33:24 +0200 [thread overview]
Message-ID: <4E8DBC34.80607@hartkopp.net> (raw)
In-Reply-To: <4E8D7065.8040905@grandegger.com>
On 10/06/11 11:09, Wolfgang Grandegger wrote:
> On 10/06/2011 09:02 AM, Oliver Hartkopp wrote:
>>
>> I think if one would like to rework the 16bit register access (which is used
>> in the rx path /and/ in the tx path also) this should go via net-next after
>> some discussion and testing.
>
> Why do you want to change 16-bit accesses in general? They are faster
> than two 8 bit accesses.
>
>> IMHO this fix is small and clear and especially not risky. I wonder if
>> reworking the 16 bit register access is worth the effort?
>
> I would prefer:
>
> if (!(frame->can_id & CAN_RTR_FLAG)) {
> void __iomem *data = ®s->rx.dsr1_0;
> u16 *payload = (u16 *)frame->data;
>
> for (i = 0; i < frame->can_dlc / 2; i++) {
> *payload++ = in_be16(data);
> data += 2 + _MSCAN_RESERVED_DSR_SIZE;
> }
> /* copy remaining byte */
> if (frame->can_dlc & 1)
> frame->data[frame->can_dlc - 1] = in_8(data);
> }
Besides the fact that Andre is going to test this idea from Wolfgang now, are
you really sure that it must be
in_8(data)
and not
in_8(data+1)
???
And that data definitely points to the right place?
I would prefer to be really cautious with these big endian 16 bit registers!
Therefore my fix with
+ /* zero accidentally copied register content at odd DLCs */
+ if (frame->can_dlc & 1)
+ frame->data[frame->can_dlc] = 0;
only repairing the result looks much more defensive to me.
Regards,
Oliver
next prev parent reply other threads:[~2011-10-06 14:33 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-05 15:34 [PATCH net] mscan: zero accidentally copied register content Oliver Hartkopp
2011-10-05 15:51 ` Wolfram Sang
2011-10-05 16:10 ` Oliver Hartkopp
2011-10-06 7:02 ` Oliver Hartkopp
2011-10-06 9:09 ` Wolfgang Grandegger
2011-10-06 9:24 ` Wolfram Sang
2011-10-06 14:01 ` Oliver Hartkopp
2011-10-06 14:09 ` Wolfram Sang
2011-10-06 14:14 ` Andre Naujoks
2011-10-06 14:33 ` Oliver Hartkopp [this message]
2011-10-06 15:03 ` Andre Naujoks
2011-10-06 18:24 ` Wolfgang Grandegger
2011-10-10 16:38 ` Oliver Hartkopp
2011-10-06 18:25 ` Marc Kleine-Budde
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=4E8DBC34.80607@hartkopp.net \
--to=socketcan@hartkopp.net \
--cc=nautsch@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=w.sang@pengutronix.de \
--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 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.