[U-Boot-Users] [PATCH V2] onenand: fix error: static declaration of 'memcpy' follows non-static declaration

Kyungmin Park kmpark at infradead.org
Tue May 6 09:29:18 CEST 2008


On Fri, May 2, 2008 at 5:22 AM, Wolfgang Denk <wd at denx.de> wrote:
> In message <1209671826-31404-1-git-send-email-plagnioj at jcrosoft.com> you wrote:
>  > by Align with word(16-bit) size
>  > as done in Linux
>  >
>  > in
>  > - onenand_read_bufferram
>  > - onenand_sync_read_bufferram
>  > - onenand_write_bufferram
>
>  This is much more intrusive than the simple rename patch;  I  suggest
>  we  do  the rename now to fix the immediate compile problem, and wait
>  with this more complex patch for the next merge window.
>
>
>  >  static const unsigned char ffchars[] = {
>  >       0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
>  >       0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 16 */
>  > @@ -358,6 +345,17 @@ static int onenand_read_bufferram(struct mtd_info *mtd, int area,
>  >       bufferram = this->base + area;
>  >       bufferram += onenand_bufferram_offset(mtd, area);
>  >
>  > +     if (ONENAND_CHECK_BYTE_ACCESS(count)) {
>  > +             unsigned short word;
>  > +
>  > +             /* Align with word(16-bit) size */
>  > +             count--;
>  > +
>  > +             /* Read word and save byte */
>  > +             word = this->read_word(bufferram + offset + count);
>  > +             buffer[count] = (word & 0xff);
>

No, No,
It doesn't handle the current OneNAND access. Now it received the
4-byte aligned address. So it's not triggered.

The best is #define __ARCH_HAVE_MEMCPY32, 32 bytes aligned memcpy.
or the previous patch memcpy_16 is second one.

Thank you,
Kyungmin Park




More information about the U-Boot mailing list