All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>,
	Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	wg@grandegger.com, linux-can@vger.kernel.org,
	Linux-sh list <linux-sh@vger.kernel.org>,
	Pavel Kiryukhin <vksavl@gmail.com>
Subject: Re: [PATCH v5] can: add Renesas R-Car CAN driver
Date: Fri, 28 Feb 2014 12:05:15 +0000	[thread overview]
Message-ID: <53107B7B.8040800@cogentembedded.com> (raw)
In-Reply-To: <531077AC.7050804@pengutronix.de>

Hello.

On 28-02-2014 15:49, Marc Kleine-Budde wrote:

>>>>> A 32 bit read/modify/write is a standard operation, nothing special, no
>>>>> need to worry about byte swapping or anything like this.

>>>>     Oh, really? 8-)
>>>>     Don't you know that read[bwlq]() assume little-endian memory layout
>>>> and to read from big-endian 32-bit register one normally needs readl_be()?

>>> I assume you are on little endian ARM only (for now).

    That doesn't matter but yes.

>>> If you use a standard 32 bit read, then modify the correct bits in that
>>> 32 bit word and write it back, with the corresponding 32 bit write
>>> everything should be fine. For this usecase you just have yo figure out
>>> which 24 of the 32 bit are the one you have to change and which are the
>>> 8 that must not be modified.

    It seems you can't figure that out yourself. :-)

>>> Looking at the register layout:

>>>> +     u8 bcr[3];      /* Bit Configuration Register */
>>>> +     u8 clkr;        /* Clock Select Register */

>>> I think clkr would be the lowest 8 bit and bcr[] are the upper 24.

>> That would be the outcome on big endian ;-)

> Doh! Yes, correct.
> The point is, just read/modify the correct bits/write, should just work.

    That's what I do. But I completely fail to see the point of reading BCR 
which is completely overwritten. I would like to consider the pointless 
discussion about 32-bit read complete now.

> The driver has to be tested on BE ARM anyways, as this isn't the only 32
> bit reg.

    This is not a 32-bit register but 24- and 8-bit one. I'm afraid we won't 
be able to test on BE soon as the machine we're debugging on is LE only. 
Anyway, for the big-endian configured Superhyway bus the big-endian HPB bus 
the CAN controller resides on shouldn't swap bytes.

> Marc

WBR, Sergei


WARNING: multiple messages have this Message-ID (diff)
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>,
	Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	wg@grandegger.com, linux-can@vger.kernel.org,
	Linux-sh list <linux-sh@vger.kernel.org>,
	Pavel Kiryukhin <vksavl@gmail.com>
Subject: Re: [PATCH v5] can: add Renesas R-Car CAN driver
Date: Fri, 28 Feb 2014 16:05:15 +0400	[thread overview]
Message-ID: <53107B7B.8040800@cogentembedded.com> (raw)
In-Reply-To: <531077AC.7050804@pengutronix.de>

Hello.

On 28-02-2014 15:49, Marc Kleine-Budde wrote:

>>>>> A 32 bit read/modify/write is a standard operation, nothing special, no
>>>>> need to worry about byte swapping or anything like this.

>>>>     Oh, really? 8-)
>>>>     Don't you know that read[bwlq]() assume little-endian memory layout
>>>> and to read from big-endian 32-bit register one normally needs readl_be()?

>>> I assume you are on little endian ARM only (for now).

    That doesn't matter but yes.

>>> If you use a standard 32 bit read, then modify the correct bits in that
>>> 32 bit word and write it back, with the corresponding 32 bit write
>>> everything should be fine. For this usecase you just have yo figure out
>>> which 24 of the 32 bit are the one you have to change and which are the
>>> 8 that must not be modified.

    It seems you can't figure that out yourself. :-)

>>> Looking at the register layout:

>>>> +     u8 bcr[3];      /* Bit Configuration Register */
>>>> +     u8 clkr;        /* Clock Select Register */

>>> I think clkr would be the lowest 8 bit and bcr[] are the upper 24.

>> That would be the outcome on big endian ;-)

> Doh! Yes, correct.
> The point is, just read/modify the correct bits/write, should just work.

    That's what I do. But I completely fail to see the point of reading BCR 
which is completely overwritten. I would like to consider the pointless 
discussion about 32-bit read complete now.

> The driver has to be tested on BE ARM anyways, as this isn't the only 32
> bit reg.

    This is not a 32-bit register but 24- and 8-bit one. I'm afraid we won't 
be able to test on BE soon as the machine we're debugging on is LE only. 
Anyway, for the big-endian configured Superhyway bus the big-endian HPB bus 
the CAN controller resides on shouldn't swap bytes.

> Marc

WBR, Sergei


  reply	other threads:[~2014-02-28 12:05 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-26 20:37 [PATCH v5] can: add Renesas R-Car CAN driver Sergei Shtylyov
2013-12-26 21:37 ` Sergei Shtylyov
2014-01-13 13:46 ` Sergei Shtylyov
2014-01-13 13:46   ` Sergei Shtylyov
2014-01-20  9:18 ` Marc Kleine-Budde
2014-01-20  9:18   ` Marc Kleine-Budde
2014-01-25  0:34   ` Sergei Shtylyov
2014-01-25  1:34     ` Sergei Shtylyov
2014-02-13 12:12     ` Marc Kleine-Budde
2014-02-13 12:12       ` Marc Kleine-Budde
2014-02-20 22:48       ` Sergei Shtylyov
2014-02-20 23:48         ` Sergei Shtylyov
2014-02-28  9:08         ` Marc Kleine-Budde
2014-02-28  9:08           ` Marc Kleine-Budde
2014-02-28 11:16           ` Sergei Shtylyov
2014-02-28 11:16             ` Sergei Shtylyov
2014-02-28 11:37             ` Marc Kleine-Budde
2014-02-28 11:37               ` Marc Kleine-Budde
2014-02-28 11:41               ` Geert Uytterhoeven
2014-02-28 11:41                 ` Geert Uytterhoeven
2014-02-28 11:47                 ` David Laight
2014-02-28 11:47                   ` David Laight
2014-02-28 11:50                   ` Marc Kleine-Budde
2014-02-28 11:50                     ` Marc Kleine-Budde
2014-02-28 12:02                     ` David Laight
2014-02-28 12:02                       ` David Laight
2014-02-28 11:49                 ` Marc Kleine-Budde
2014-02-28 11:49                   ` Marc Kleine-Budde
2014-02-28 12:05                   ` Sergei Shtylyov [this message]
2014-02-28 12:05                     ` Sergei Shtylyov
2014-02-28 12:17                     ` David Laight
2014-02-28 12:17                       ` David Laight
2014-02-28 12:34                       ` Sergei Shtylyov
2014-02-28 12:34                         ` Sergei Shtylyov
2014-01-20 11:43 ` Geert Uytterhoeven
2014-01-20 11:43   ` Geert Uytterhoeven
2014-01-20 11:47   ` Marc Kleine-Budde
2014-01-20 11:47     ` Marc Kleine-Budde
2014-01-20 11:52     ` Geert Uytterhoeven
2014-01-20 11:52       ` Geert Uytterhoeven
2014-01-20 11:58       ` Marc Kleine-Budde
2014-01-20 11:58         ` Marc Kleine-Budde
2014-01-20 12:02         ` Ben Dooks
2014-01-20 12:05           ` Geert Uytterhoeven
2014-01-20 12:05             ` Geert Uytterhoeven
2014-01-20 12:08             ` Marc Kleine-Budde
2014-01-20 12:08               ` Marc Kleine-Budde
2014-01-20 12:05           ` Marc Kleine-Budde
2014-01-20 12:05             ` Marc Kleine-Budde
2014-01-20 12:13           ` David Laight
2014-01-20 12:13             ` David Laight
2014-01-20 12:35             ` Marc Kleine-Budde
2014-01-20 12:35               ` Marc Kleine-Budde
2014-01-20 19:16         ` David Miller
2014-01-20 19:16           ` David Miller
2014-01-20 21:12           ` Sergei Shtylyov
2014-01-20 22:12             ` Sergei Shtylyov
2014-01-20 21:17             ` Marc Kleine-Budde
2014-01-20 21:17               ` Marc Kleine-Budde
2014-01-22 11:52               ` Ben Dooks
2014-01-22 11:54                 ` Geert Uytterhoeven
2014-01-22 11:54                   ` Geert Uytterhoeven
2014-01-22 11:58                 ` David Laight
2014-01-22 11:58                   ` David Laight
2014-01-20 12:12   ` Sergei Shtylyov
2014-01-20 12:12     ` Sergei Shtylyov

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=53107B7B.8040800@cogentembedded.com \
    --to=sergei.shtylyov@cogentembedded.com \
    --cc=geert@linux-m68k.org \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=netdev@vger.kernel.org \
    --cc=vksavl@gmail.com \
    --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.