Hi,

>> > Find two batches mt35xu512aba has different SFDP but with same jedec
>> > ID. To make all batches of mt35xu512aba work well and support OCT DTR
>> > mode, back to hardcode the flags.
>> 
>> What are "batches" in this case? A new revision of the same flash chip? Why
>> would they use a different ID then.
>
> Hi Michael,
>
> Yes, seems a new revision of the same flash chip. Anyone from Micron can confirm this?
>
> What's the normal way for vendors to update the SFDP? Seems also need to update/change the ID.

No why would they? It's the same flash, but with new/fixed SFDP.

>> What's wrong with the parsed flags? Both support SFDP, so if you really need to
>> fixup any flags, please use a fixup callback to actually fix them. But first, what
>> will go wrong?
>
> Yes, sorry to lack this information.
>
> For mt35xu512aba chip with label 0DA15 RW303, the SFDP do not support OCT DTR read/write operation, 
> but still has one .fixups = &mt35xu512aba_fixups, in this fix up, it config the OCT DTR read operation, so
> finally read_proto == SNOR_PROTO_8_8_8_DTR, but nor->write_proto == SNOR_PROTO_1_1_1, then has
> no chance to call micron_st_nor_octal_dtr_en(), when there is read operation, use OCT DTR read command
> meet issue.
>
> With this revert patch, I test mt35xu512aba chip with label 0DA15 RW303, OCT DTR mode can work well.
> Also test mt35xu512aba chip with label 4KA17 RW303, OCT DTR mode work find too.

So both support actual octal mode. Then please fix
mt35xu512aba_fixups. IIUC, you can just use
spi_nor_set_pp_settings() there, to fixup the supported PP mode. But
please add it with a comment describe *why* we need that fixup.

-michael