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 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.