[PATCH v1 2/2] mtd: spi-nor: add support for Macronix Octal flash

[liao jaime]

Hi Michael


>
> Hi,
>
> >> So the stack die information come from SFDP? Can RWW also be read from
> >> the SFDP tables? Do you have vendor SFDP tables where this information
> >> can come from?
> > For this introduction, it just introduce Macronix EPN naming rules.
> > As I know, rww didn't include JESD216D.
>
> Yes, but you might or might not have proprietary tables in the SFDP,
> which
> might inidicate wether that part has RWW or now. Thus I was asking for
> that
> document above.
Sorry, I don't have proprietary tables in SFDP.
For checking whether RWW feature support, I need to check in datasheet
and EPN.

>
> >> Again "us" as in macronix? but then, there is no trace that this
> >> commit
> >> is comming from macronix.
> > It is relate to Macronix mail issue, so we prefer send patches on
> > gmail.
> > A question, how could I mention the commit is comming from Macronix if
> > I still send patch from gmail?
>
> Yes see my former mail.
Thanks.
>
> >> md5sum is missing and please use either xxd or if not
> >> available, "hexdump -C".
> > Ok, I will update content of SFDP dump with md5sum and
> > using xxd command.
>
> Thanks!
>
> >> > --- a/drivers/mtd/spi-nor/macronix.c
> >> > +++ b/drivers/mtd/spi-nor/macronix.c
> >> > @@ -179,6 +179,33 @@ static const struct flash_info
> >> > macronix_nor_parts[] = {
> >> >       { "mx66u2g45g",  INFO(0xc2253c, 0, 64 * 1024, 4096)
> >> >               NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)
> >> >               FIXUP_FLAGS(SPI_NOR_4B_OPCODES) },
> >> > +     { "mx66uw2g345g", INFO(0xc2843c, 0, 64 * 1024, 4096)
> >>
> >> Please use INFO(0xc2843c, 0, 0, 0)
> > Sorry I didn't get it.
>
> That should come from the SFDP tables.
>
> >> > +             FLAGS(SPI_NOR_RWW)
> >>
> >> Maybe one of your proprietary tables indicate RWW capabilites?
> > As I know, RWW could be got on datasheet only for now.
> > So that follow the existing rule using FLAGS for it.
>
> So you didn't test it? Then I'm inclined to say you should
> drop this flag from this patchset.
>
> >> > +             NO_SFDP_FLAGS(SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_OCTAL_DTR_READ
> >> > | SPI_NOR_OCTAL_DTR_PP)
> >>
> >> No NO_SFDP_FLAGS() for new parts.
> >>
> >> > +             FIXUP_FLAGS(SPI_NOR_4B_OPCODES) },
> >>
> >> You should have a correct "4-Byte Address Instruction Table",
> >> therefore
> >> you don't need the FIXUPS_FLAGS.
> > 4 bytes opcode flag could be get by parsing bfpt.
> > But I think it would be great if ID table include it as well.
> > Because of some flashes in market may not define SFDP table.
>
> Which ones would that be? Are there any new flashes without SFDP
> tables? And even if, it should be added if there is an actual board
> using that flash without SFDP. I'm against just adding flags just
> because "there might be something out there". Ideally, there shouldn't
> be any entry at all.
Agree, I hope all features get from SFDP table and as I know new flash
all support SFDP.
But for RWW, I still need a flag for using.

>
> -michael

Thanks
Jaime