23 Apr, 2008

2 commits

  • AMD/Spansion use a device id of 0x7e to indicate an extended device is
    present at offset 0xe and 0xf in the query data.

    I've verified with Spansion that all their chips (mfr == 0x01) with an id
    of 0x7e use it to indicate an extended id is present. What's more, there
    are no chips with a NON-extended id that is the same as a different chip's
    extended id. In other words, when the extended ID is present, one can
    replace the normal id with the extended id without losing any information.
    Which is what I've done.

    Signed-off-by: Trent Piepho
    Signed-off-by: David Woodhouse

    Trent Piepho
     
  • Untested, but shouldn't break anything... Makes MTD_XIP arch
    independent. I guess this is why xip_iprefetch() was made for.

    Signed-off-by: Paulius Zaleckas
    Acked-by: Nicolas Pitre
    Signed-off-by: David Woodhouse

    Paulius Zaleckas
     

11 Jan, 2008

1 commit


01 Jul, 2006

1 commit


14 May, 2006

1 commit


30 Nov, 2005

2 commits

  • This patch contains the following possible cleanups:
    - every file should #include the headers containing the prototypes for
    it's global functions
    - make needlessly global functions static

    Signed-off-by: Adrian Bunk
    Signed-off-by: Andrew Morton
    Signed-off-by: Thomas Gleixner

    Adrian Bunk
     
  • Recent models of Intel/Sharp and Spansion CFI flash now have significant
    bits in the upper byte of device ID codes, read via what Spansion calls
    "autoselect" and Intel calls "read device identifier". Currently these
    values are truncated to the low 8 bits in the mtd data structures, as
    all CFI read query info has previously been read one byte at a time.
    Add a new method for reading 16-bit info, currently just manufacturer
    and device codes; datasheets hint at future uses for upper bytes in
    other fields.

    Signed-off-by: Todd Poynor
    Signed-off-by: Thomas Gleixner

    Todd Poynor
     

07 Nov, 2005

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds