From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/4] sunxi: nand: Add basic sunxi NAND driver with DMA support
Date: Thu, 16 Jul 2015 17:12:15 -0500 [thread overview]
Message-ID: <1437084735.2993.178.camel@freescale.com> (raw)
In-Reply-To: <201507170006.29312.marex@denx.de>
On Fri, 2015-07-17 at 00:06 +0200, Marek Vasut wrote:
> On Thursday, July 16, 2015 at 11:36:08 PM, Scott Wood wrote:
> > On Thu, 2015-07-16 at 23:26 +0200, Marek Vasut wrote:
> > > On Thursday, July 16, 2015 at 11:15:58 PM, Scott Wood wrote:
> > >
> > > [...]
> > >
> > > > > +/* temporary buffer in internal ram */
> > > > > +#ifdef CONFIG_SPL_BUILD
> > > > > +/* in SPL temporary buffer cannot be @ 0x0 */
> > > > > +unsigned char temp_buf[SPL_WRITE_SIZE] __aligned(0x10)
> > > > > __section(".text#"); +#else
> > > > > +/* put temporary buffer @ 0x0 */
> > > > > +unsigned char *temp_buf = (unsigned char *)0x0;
> > > > > +#endif
> > > >
> > > > If 0x0 is the address of an SRAM, its address should be symbolically
> > > > defined. Also consider mapping it to a different virtual address, to
> > > > avoid potential compiler mischief.
> > >
> > > The DMA I believe accesses it via PA anyway, so mapping it elsewhere
> > > would only confuse everyone who's hacking on the driver. Just my 5 cents
> > > ;-)
> >
> > Hey, if it wakes people up to the fact that they ought to be using
> > virt_to_phys() (or better yet, something that distinguishes DMA addresses
> > from physical), great! :-)
>
> Not really useful here, but whatever.
>
> > And yes, people go on to do the same "everything is u32" crap in
> > non-platform- specific files. Just look at drivers/block/ahci.c.
>
> Errr, this file is platform specific.
(I'm assuming that by "this file" you mean the sunxi file, not the ahci file.)
The point is that establishing good habits everywhere reduces the likelihood
of the bad habits migrating to places where things break.
And no, I don't seriously expect my suggestion of remapping the virtual
address to be implemented, but GCC has been known to do all sorts of weird
stuff when it thinks it knows a NULL pointer is being dereferenced.
-Scott
next prev parent reply other threads:[~2015-07-16 22:12 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-16 11:25 [U-Boot] [PATCH 0/4] sunxi: nand: Basic NAND driver with SPL support Piotr Zierhoffer
2015-07-16 11:25 ` [U-Boot] [PATCH 1/4] sunxi: nand: Add basic sunxi NAND driver with DMA support Piotr Zierhoffer
2015-07-16 21:15 ` Scott Wood
2015-07-16 21:26 ` Marek Vasut
2015-07-16 21:36 ` Scott Wood
2015-07-16 22:06 ` Marek Vasut
2015-07-16 22:12 ` Scott Wood [this message]
2015-07-16 22:13 ` Marek Vasut
2015-07-17 14:39 ` Piotr Zierhoffer
2015-07-16 11:25 ` [U-Boot] [PATCH 2/4] sunxi: nand: Add board configuration options Piotr Zierhoffer
2015-07-16 11:25 ` [U-Boot] [PATCH 3/4] sunxi: nand: Add a20_nandread command to load image from NAND in SPL Piotr Zierhoffer
2015-07-16 21:20 ` Scott Wood
2015-07-17 14:25 ` Piotr Zierhoffer
2015-07-16 11:25 ` [U-Boot] [PATCH 4/4] sunxi: nand: Add information to sunxi that it was run " Piotr Zierhoffer
2015-07-20 12:37 ` [U-Boot] [PATCH v2 0/3] sunxi: nand: Basic NAND driver for SPL Piotr Zierhoffer
2015-07-20 12:37 ` [U-Boot] [PATCH v2 1/3] sunxi: nand: Add basic sunxi NAND driver for SPL with DMA support Piotr Zierhoffer
2015-07-20 16:13 ` Boris Brezillon
2015-07-22 11:27 ` Piotr Zierhoffer
2015-07-22 11:53 ` Boris Brezillon
2015-07-22 13:48 ` Piotr Zierhoffer
2015-07-20 12:37 ` [U-Boot] [PATCH v2 2/3] sunxi: nand: Add board configuration options Piotr Zierhoffer
2015-07-20 12:37 ` [U-Boot] [PATCH v2 3/3] sunxi: nand: Add information to sunxi that it was run from NAND in SPL Piotr Zierhoffer
2015-07-20 15:05 ` [U-Boot] [PATCH v2 0/3] sunxi: nand: Basic NAND driver for SPL Boris Brezillon
2015-07-20 16:03 ` Piotr Zierhoffer
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=1437084735.2993.178.camel@freescale.com \
--to=scottwood@freescale.com \
--cc=u-boot@lists.denx.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox