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

[Michael Walle <michael@walle.cc>]

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.

>> 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.

>> 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.

-michael

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/