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

Boris Brezillon
2020-05-05T09:44:50Z

On Tue, 5 May 2020 17:31:45 +0800
masonccyang@mxic.com.tw wrote:

> > > > > I quickly went through your patches but can't reply them in each
> your
> > > > > patches.
> > > > >
> > > > > i.e,.
> > > > > 1) [v4,03/16] spi: spi-mem: allow specifying a command's extension
> > > > >
> > > > > - u8 opcode;
> > > > > + u16 opcode;
> > > > >
> > > > > big/little Endian issue, right?
> > > > > why not just u8 ext_opcode;
> > > > > No any impact for exist code and actually only xSPI device use
> > > extension
> > > > > command.
> > > >
> > > > Boris already explained the reasoning behind it.
> > >
> > > yup, I got his point and please make sure CPU data access.
> > >
> > > i.e,.
> > > Fix endianness of the BFPT DWORDs and xSPI in sfdp.c
> > >
> > > and your patch,
> > > + ext = spi_nor_get_cmd_ext(nor, op);
> > > + op->cmd.opcode = (op->cmd.opcode <<
> 8) |
> > > ext;
> > > + op->cmd.nbytes = 2;
> > >
> > > I think maybe using u8 opcode[2] could avoid endianness.
> >
> > Again, thanks Boris for answering this. FWIW, I don't see anything wrong
>
> > with his suggestion.
> >
> > To clarify a bit more, the idea is that we transmit the opcode MSB
> > first, just we do for the address. Assume we want to issue the command
> > 0x05. In 1S mode, we set cmd.opcode to 0x05. Here cmd.nbytes == 1. Treat
>
> > is as a 1-byte value, so the MSB is the same as the LSB. We directly
> > send 0x5 on the bus.
>
> There are many SPI controllers driver use "op->cmd.opcode" directly,
> so is spi-mxic.c.
>
> i.e,.
> ret = mxic_spi_data_xfer(mxic, &op->cmd.opcode, NULL, op->cmd.nbytes);

Just because you do it doesn't mean it's right. And most controllers use
the opcode value, they don't dereference the pointer as you do here.

>
> >
> > If cmd.nbytes == 2, then the opcode would be 0x05FA (assuming extension
> > is invert of command). So we send the MSB (0x05) first, and LSB (0xFA)
> > next.
>
> My platform is Xilinx Zynq platform which CPU is ARMv7 processor.
>
> In 1-1-1 mode, it's OK to send 1 byte command by u16 opcode but
> in 8D-8D-8D mode, I need to patch
>
> i.e.,
> op->cmd.opcode = op->cmd.opcode | (ext << 8);
>
> rather than your patch.

Seriously, how hard is it to extract each byte from the u16 if your
controller needs to pass things in a different order? I mean, that's
already how it's done for the address cycle, so why is it a problem
here? This sounds like bikeshedding to me. If the order is properly
documented in the kernel doc, I see no problem having it grouped in one
u16, with the first cmd cycle placed in the MSB and the second one in
the LSB.