public inbox for netdev@vger.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.

next prev parent 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$(echo .)com \
    --cc=nautsch@gmail$(echo .)com \
    --cc=netdev@vger$(echo .)kernel.org \
    --cc=socketcan@hartkopp$(echo .)net \
    --cc=w.sang@pengutronix$(echo .)de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox