All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfgang Grandegger <wg@grandegger.com>
To: Andre Naujoks <nautsch@gmail.com>
Cc: Oliver Hartkopp <socketcan@hartkopp.net>,
	Wolfram Sang <w.sang@pengutronix.de>,
	Linux Netdev List <netdev@vger.kernel.org>
Subject: Re: [PATCH net] mscan: zero accidentally copied register content
Date: Thu, 06 Oct 2011 20:24:14 +0200	[thread overview]
Message-ID: <4E8DF24E.5030606@grandegger.com> (raw)
In-Reply-To: <CAOCMmufQ77Vz4XTSTZTVSMiOA4QtWkZEvWHjGXip5-JK20E=QA@mail.gmail.com>

On 10/06/2011 05:03 PM, Andre Naujoks wrote:
> 2011/10/6 Oliver Hartkopp <socketcan@hartkopp.net>:
>> 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 = &regs->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)

That should be the right byte.

>>
>> 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.
> 
> First things first: Both ways seem to work correctly. At least on the
> MPC5200 I have here.
> 
> But I am with Oliver on this one. The solution looks much simpler and
> endianess errors are not possible. If the few CPU cycles are worth it
> on the other hand, then Wolfgangs version is probably preferable. I
> don't have access to this kind of hardware on a little endian machine
> to test it, though.

Well, copying just the relevant bytes seem much more straight-forward
than removing accidentally copied bytes later-on. You do not need to
care about little endian. The MSCAN is only available on PowerPC SOCs,
which are big endian.

I'm going to test and post a patch tomorrow.

Wolfgang.

  reply	other threads:[~2011-10-06 18:24 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
2011-10-06 15:03           ` Andre Naujoks
2011-10-06 18:24             ` Wolfgang Grandegger [this message]
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=4E8DF24E.5030606@grandegger.com \
    --to=wg@grandegger.com \
    --cc=nautsch@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=socketcan@hartkopp.net \
    --cc=w.sang@pengutronix.de \
    /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.