Re: [PATCH v2 0/5] mtd: spi-nor: Add support for Octal 8D-8D-8D mode

Boris Brezillon
2020-04-28T06:34:29Z

On Tue, 28 Apr 2020 14:14:31 +0800
masonccyang@mxic.com.tw wrote:

> Hi Pratyush,
>
> > > On Tue, 21 Apr 2020 14:39:42 +0800
> > > Mason Yang <masonccyang@mxic.com.tw> wrote:
> > >
> > > > Hello,
> > > >
> > > > This is repost of patchset from Boris Brezillon's
> > > > [RFC,00/18] mtd: spi-nor: Proposal for 8-8-8 mode support [1].
> > >
> > > I only quickly went through the patches you sent and saying it's a
> > > repost of the RFC is a bit of a lie. You completely ignored the state
> > > tracking I was trying to do to avoid leaving the flash in 8D mode when
> > > suspending/resetting the board, and I think that part is crucial. If I
> > > remember correctly, we already had this discussion so I must say I'm a
> > > bit disappointed.
> > >
> > > Can you sync with Pratyush? I think his series [1] is better in that
> it
> > > tries to restore the flash in single-SPI mode before suspend (it's
> > > missing the shutdown case, but that can be easily added I think). Of
> > > course that'd be even better to have proper state tracking at the SPI
> > > NOR level.
> >
> > Hi Mason,
> >
> > I posted a re-roll of my series here [0]. Could you please base your
> > changes on top of it? Let me know if the series is missing something you
>
> > need.
> >
> > [0]
> https://lore.kernel.org/linux-mtd/20200424184410.8578-1-p.yadav@ti.com/
>
>
> Our mx25uw51245g supports BFPT DWORD-18,19 and 20 data and xSPI profile
> 1.0,
> and it comply with BFPT DWORD-19, octal mode enable sequences by write CFG
> Reg2
> with instruction 0x72. Therefore, I can't apply your patches.
>
> I quickly went through your patches but can't reply them in each your
> patches.

Why?!! Aren't you registered to the MTD mailing list? Sorry but having
reviews outside of the original thread is far from ideal. Please find a
way to reply to the original patchset.

>
> i.e,.
> 1) [v4,03/16] spi: spi-mem: allow specifying a command's extension
>
> - u8 opcode;
> + u16 opcode;
>
> big/little Endian issue, right?

There's no endianness issue since it's SPI controller responsibility to
interpret this field.

> why not just u8 ext_opcode;

Because I see the ext_ext_code comimg, and it's also more consistent
with the addr field if we use an u16 and a number of cmd cycles.

> No any impact for exist code and actually only xSPI device use extension
> command.

And extending the opcode field to an u16 has no impact either.