From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: linux-mtd@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Subject: Re: [PATCH 1/2] mtd mxc_nand: use 32bit copy functions
Date: Fri, 29 Jun 2012 14:34:24 +0300 [thread overview]
Message-ID: <1340969664.3070.162.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <20120525145901.GS30400@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]
On Fri, 2012-05-25 at 16:59 +0200, Sascha Hauer wrote:
> > WARNING:LONG_LINE: line over 80 characters
> > #103: FILE: drivers/mtd/nand/mxc_nand.c:276:
> > +static void memcpy32_fromio(void *trg, const volatile void __iomem *src, size_t size)
> >
> > WARNING:VOLATILE: Use of volatile is usually wrong: see Documentation/volatile-considered-harmful.txt
> > #103: FILE: drivers/mtd/nand/mxc_nand.c:276:
> > +static void memcpy32_fromio(void *trg, const volatile void __iomem *src, size_t size)
>
> This makes me wonder a bit, I basically copied the prototype from
> the _memcpy_*_io template from arch/arm/kernel/io.c. Should they
> be wrong?
Well, this is arch-specific code. In there we may make various
assumptions about CPU not doing re-ordering. You are changing generic
code, you should not do assumptions like this.
How about adding these functions to arch/arm/kernel/io.c instead?
> otoh I also wondered why there were volatiles in arch/arm/kernel/io.c
> in the first place ;)
Not sure, probably in that file we assume that the memory is
strongly-ordered.
--
Best Regards,
Artem Bityutskiy
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: artem.bityutskiy@linux.intel.com (Artem Bityutskiy)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] mtd mxc_nand: use 32bit copy functions
Date: Fri, 29 Jun 2012 14:34:24 +0300 [thread overview]
Message-ID: <1340969664.3070.162.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <20120525145901.GS30400@pengutronix.de>
On Fri, 2012-05-25 at 16:59 +0200, Sascha Hauer wrote:
> > WARNING:LONG_LINE: line over 80 characters
> > #103: FILE: drivers/mtd/nand/mxc_nand.c:276:
> > +static void memcpy32_fromio(void *trg, const volatile void __iomem *src, size_t size)
> >
> > WARNING:VOLATILE: Use of volatile is usually wrong: see Documentation/volatile-considered-harmful.txt
> > #103: FILE: drivers/mtd/nand/mxc_nand.c:276:
> > +static void memcpy32_fromio(void *trg, const volatile void __iomem *src, size_t size)
>
> This makes me wonder a bit, I basically copied the prototype from
> the _memcpy_*_io template from arch/arm/kernel/io.c. Should they
> be wrong?
Well, this is arch-specific code. In there we may make various
assumptions about CPU not doing re-ordering. You are changing generic
code, you should not do assumptions like this.
How about adding these functions to arch/arm/kernel/io.c instead?
> otoh I also wondered why there were volatiles in arch/arm/kernel/io.c
> in the first place ;)
Not sure, probably in that file we assume that the memory is
strongly-ordered.
--
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120629/942ccb1a/attachment.sig>
next prev parent reply other threads:[~2012-06-29 11:34 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-25 14:22 [PATCH 1/2] mtd mxc_nand: use 32bit copy functions Sascha Hauer
2012-05-25 14:22 ` Sascha Hauer
2012-05-25 14:22 ` [PATCH 2/2] mtd mxc_nand: move ecc strengh setup before nand_scan_tail Sascha Hauer
2012-05-25 14:22 ` Sascha Hauer
2012-05-25 16:29 ` Mike Dunn
2012-05-25 16:29 ` Mike Dunn
2012-05-25 16:55 ` Artem Bityutskiy
2012-05-25 16:55 ` Artem Bityutskiy
2012-05-25 14:58 ` [PATCH 1/2] mtd mxc_nand: use 32bit copy functions Artem Bityutskiy
2012-05-25 14:58 ` Artem Bityutskiy
2012-05-25 14:59 ` Sascha Hauer
2012-05-25 14:59 ` Sascha Hauer
2012-06-29 11:34 ` Artem Bityutskiy [this message]
2012-06-29 11:34 ` Artem Bityutskiy
2012-06-27 17:52 ` Uwe Kleine-König
2012-06-27 17:52 ` Uwe Kleine-König
2012-06-29 11:25 ` Artem Bityutskiy
2012-06-29 11:25 ` Artem Bityutskiy
2012-06-29 11:28 ` Uwe Kleine-König
2012-06-29 11:28 ` Uwe Kleine-König
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=1340969664.3070.162.camel@sauron.fi.intel.com \
--to=artem.bityutskiy@linux.intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=s.hauer@pengutronix.de \
--cc=u.kleine-koenig@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.