From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: Tomoya <tomoya-linux@dsn.okisemi.com>,
Wolfgang Grandegger <wg@grandegger.com>,
"David S. Miller" <davem@davemloft.net>,
Wolfram Sang <w.sang@pengutronix.de>,
Christian Pellegrin <chripell@fsfe.org>,
Barry Song <21cnbao@gmail.com>,
Samuel Ortiz <sameo@linux.intel.com>,
socketcan-core@lists.berlios.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, andrew.chih.howe.khor@intel.com,
qi.wang@intel.com, margie.foster@intel.com,
yong.y.wang@intel.com,
Masayuki Ohtake <masa-korg@dsn.okisemi.com>,
kok.howg.ewe@intel.com, joel.clark@intel.com
Subject: Re: [PATCH net-next-2.6 v2] can: Topcliff: PCH_CAN driver: Fix build warnings
Date: Fri, 29 Oct 2010 19:58:23 +0200 [thread overview]
Message-ID: <4CCB0B3F.5050400@pengutronix.de> (raw)
In-Reply-To: <4CCAFA68.2030903@hartkopp.net>
[-- Attachment #1: Type: text/plain, Size: 2851 bytes --]
On 10/29/2010 06:46 PM, Oliver Hartkopp wrote:
> Indeed the access to the data registers does not seem to be endian aware.
>
> See in pch_can_rx_normal():
>
> + cf->can_dlc = get_can_dlc((ioread32(&priv->regs->
> + if1_mcont)) & 0xF);
> + *(u16 *)(cf->data + 0) = ioread16(&priv->regs->
> + if1_dataa1);
> + *(u16 *)(cf->data + 2) = ioread16(&priv->regs->
> + if1_dataa2);
> + *(u16 *)(cf->data + 4) = ioread16(&priv->regs->
> + if1_datab1);
> + *(u16 *)(cf->data + 6) = ioread16(&priv->regs->
> + if1_datab2);
>
> See in pch_xmit():
>
> + /* Copy data to register */
> + if (cf->can_dlc > 0) {
> + u32 data1 = *((u16 *)&cf->data[0]);
> + iowrite32(data1, &priv->regs->if2_dataa1);
> + }
> + if (cf->can_dlc > 2) {
> + u32 data1 = *((u16 *)&cf->data[2]);
> + iowrite32(data1, &priv->regs->if2_dataa2);
> + }
> + if (cf->can_dlc > 4) {
> + u32 data1 = *((u16 *)&cf->data[4]);
> + iowrite32(data1, &priv->regs->if2_datab1);
> + }
> + if (cf->can_dlc > 6) {
> + u32 data1 = *((u16 *)&cf->data[6]);
> + iowrite32(data1, &priv->regs->if2_datab2);
> + }
> +
>
> It's just a question if the driver for an Intel Chipset should/could ignore
> the endian problematic.
>
> If this is intended the driver should only appear in Kconfig depending on X86
> or little endian systems.
>
> Besides this remark, the struct pch_can_regs could also be defined in a way
> that every single CAN payload data byte could be accessed directly to allow
That _should_ work on x86. On the contrary on ARM some registers in SOCs
allow only full 32 bit access.
> e.g. this code in pch_can_rx_normal():
>
> cf->data[0] = ioread8(&priv->regs->if1_data0);
> cf->data[1] = ioread8(&priv->regs->if1_data1);
> cf->data[2] = ioread8(&priv->regs->if1_data2);
> (..)
> cf->data[6] = ioread8(&priv->regs->if1_data6);
> cf->data[7] = ioread8(&priv->regs->if1_data7);
> This is easy to understand and additionally endian aware.
or use this, (as proposed in a earlier mail)
for (i = 0; i < cf->can_dlc; i += 2) {
reg = ioread32(&priv->regs->if1_data[i >> 1]);
*(__be16 *)cf->data[i] = cpu_to_be16(reg);
}
> In opposite to this:
>
> + if (cf->can_dlc > 2) {
> + u32 data1 = *((u16 *)&cf->data[2]);
> + iowrite32(data1, &priv->regs->if2_dataa2);
> + }
>
> Which puts a little? endian u16 into the big endian register layout.
> Sorry i'm just getting curious on this register access implementation.
According to the datasheet the layout is LE.
cheers, Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2010-10-29 17:58 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-29 10:37 [PATCH net-next-2.6 v2] can: Topcliff: PCH_CAN driver: Fix build warnings Tomoya
2010-10-29 12:57 ` Marc Kleine-Budde
2010-10-29 16:23 ` Marc Kleine-Budde
2010-10-29 19:32 ` Wolfgang Grandegger
2010-11-01 11:05 ` Marc Kleine-Budde
2010-11-03 16:15 ` Wolfgang Grandegger
2010-11-12 11:10 ` Tomoya MORINAGA
2010-11-12 11:45 ` Wolfgang Grandegger
2010-11-15 7:39 ` Tomoya MORINAGA
2010-11-15 8:39 ` Tomoya MORINAGA
2010-11-02 10:27 ` Tomoya MORINAGA
2010-11-02 11:03 ` Marc Kleine-Budde
2010-11-15 8:41 ` Tomoya MORINAGA
2010-10-29 16:46 ` Oliver Hartkopp
2010-10-29 17:58 ` Marc Kleine-Budde [this message]
2010-11-09 12:26 ` Tomoya MORINAGA
2010-11-09 14:47 ` Marc Kleine-Budde
2010-11-01 7:15 ` Tomoya MORINAGA
[not found] <005301cb7ffa$5b63cd90$66f8800a@maildom.okisemi.com>
2010-11-09 12:26 ` Tomoya MORINAGA
2010-11-09 12:59 ` Marc Kleine-Budde
2010-11-11 9:56 ` Tomoya MORINAGA
2010-11-11 10:04 ` Marc Kleine-Budde
-- strict thread matches above, loose matches on Subject: below --
2010-10-26 0:04 Tomoya
2010-10-26 17:52 ` David Miller
2010-10-26 17:55 ` David Miller
2010-10-26 18:27 ` Wolfgang Grandegger
2010-10-26 18:52 ` Marc Kleine-Budde
2010-10-27 0:50 ` Tomoya MORINAGA
2010-10-25 2:32 Tomoya
2010-10-25 19:14 ` David Miller
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=4CCB0B3F.5050400@pengutronix.de \
--to=mkl@pengutronix.de \
--cc=21cnbao@gmail.com \
--cc=andrew.chih.howe.khor@intel.com \
--cc=chripell@fsfe.org \
--cc=davem@davemloft.net \
--cc=joel.clark@intel.com \
--cc=kok.howg.ewe@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=margie.foster@intel.com \
--cc=masa-korg@dsn.okisemi.com \
--cc=netdev@vger.kernel.org \
--cc=qi.wang@intel.com \
--cc=sameo@linux.intel.com \
--cc=socketcan-core@lists.berlios.de \
--cc=socketcan@hartkopp.net \
--cc=tomoya-linux@dsn.okisemi.com \
--cc=w.sang@pengutronix.de \
--cc=wg@grandegger.com \
--cc=yong.y.wang@intel.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