[PATCH v3] mtd: spi-nor: Add support for Cypress cy15x104q

Tim Harvey tharvey at gateworks.com
Thu Nov 5 13:54:37 EST 2020


On Thu, May 28, 2020 at 1:13 AM <Tudor.Ambarus at microchip.com> wrote:
>
> On Friday, April 24, 2020 9:56:26 AM EEST Sascha Hauer wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > The Cypress cy15b104q and cy15v104q are 4Mbit serial SPI F-RAM devices.
> > Add support for them to the spi-nor driver.
> >
> > The actual Device ID of this chip is 7f 7f 7f 7f 7f 7f c2 2c 04. That is
> > six times the continuation code 7f followed by c2 for Ramtron.
> > Unfortunately the chip sends the Device ID in reversed order, so the
> > continuation code is not at the beginning, but instead at the end. Even
> > more unfortunate is that when reading further the chip sends more 7f
> > codes which means we are not even able to count the continuation codes.
> > We can only hope that this reversed Device ID will never match any other
> > devices ID.
> >
> > Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
>
> Collisions are improbable as of now, the solution from above is good
> enough. In case of future collisions one can introduce an INFO9 macro,
> with the downsize that struct flash_info would grow and we have lots of
> flashes. A more elegant solution would be to introduce dedicated
> flash ID tables for each bank in JESP106BA.
>
> Amended commit description with the above text and applied. Thanks.
>

Greetings,

I've got a board with a  CY15B104Q-LHXI on it and I found that it's id
reads as  7f 7f 7f 7f 7f 7f c2 26 08 so it fails the match added above
in a2644d5f36: mtd: spi-nor: Add support for Cypress cy15x104q

I also found a reference in
https://community.cypress.com/docs/DOC-14647 that states "that newer
1.8 V devices have the 9 device ID bytes coming out in the other order
which requires a minor change in the ID entry" which would explain the
situation you encountered.

Adding '{ "cy15x104q",  INFO(0x7f7f7f, 0, 512 * 1024, 1,
SPI_NOR_NO_ERASE) },' works for the part I have.

Would it be wrong to add additional parts with the same name and
different id's? It seems to me duplicate names would break
spi_nor_scan when passed a name but work fine for scanning by id. I
also think that '{ "cy15x104q",  INFO6(0x042cc2, 0x7f7f7f, 512 * 1024,
1, SPI_NOR_NO_ERASE) },' is way too specific for 'cy15x104q' because
it is won't match any of the other identified parts:

CY15B104Q-PZXI     7F7F7F7F7F7FC22C03 51-85075 8-pin PDIP Industrial
CY15B104QN-50SXA   7F7F7F7F7F7FC22C40 001-85261 8-pin SOIC (EIAJ) Automotive
CY15V104QN-50SXI   7F7F7F7F7F7FC22C04 002-18131 8-pin GQFN Industrial
CY15B104QN-20LPXC  7F7F7F7F7F7FC22CA1 002-18131 8-pin GQFN Commercial
CY15B104QN-20LPXI  7F7F7F7F7F7FC22C01 002-18131 8-pin GQFN Industrial
CY15V104QN-20LPXC  7F7F7F7F7F7FC22CA5 002-18131 8-pin GQFN Commercial
CY15V104QN-20LPXI  7F7F7F7F7F7FC22C05 002-18131 8-pin GQFN Industrial
CY15B104QN-50LPXI  7F7F7F7F7F7FC22C00 002-18131 8-pin GQFN Industrial

Best Regards,

Tim



More information about the linux-mtd mailing list