public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: <Tudor.Ambarus@microchip.com>
To: <p.yadav@ti.com>
Cc: <michael@walle.cc>, <broonie@kernel.org>,
	<miquel.raynal@bootlin.com>, <richard@nod.at>, <vigneshr@ti.com>,
	<linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
	<linux-spi@vger.kernel.org>, <Nicolas.Ferre@microchip.com>,
	<zhengxunli@mxic.com.tw>, <jaimeliao@mxic.com.tw>
Subject: Re: [PATCH 0/4] spi-mem: Allow specifying the byte order in DTR mode
Date: Thu, 24 Feb 2022 06:37:21 +0000	[thread overview]
Message-ID: <779069a1-7389-ab70-9f03-81090d0600ba@microchip.com> (raw)
In-Reply-To: <6eb179ec-0b12-de30-829e-83ec6b964f21@microchip.com>

On 2/24/22 08:08, Tudor.Ambarus@microchip.com wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 2/23/22 20:38, Pratyush Yadav wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>
>> Hi Tudor,
>>
>> On 22/02/22 02:43PM, Tudor.Ambarus@microchip.com wrote:
>>> On 2/22/22 16:27, Michael Walle wrote:
>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>>
>>>> Am 2022-02-22 15:23, schrieb Tudor.Ambarus@microchip.com:
>>>>> On 2/22/22 16:13, Michael Walle wrote:
>>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know
>>>>>> the content is safe
>>>>>>
>>>>>> Am 2022-02-22 14:54, schrieb Tudor.Ambarus@microchip.com:
>>>>>>> On 2/21/22 09:44, Michael Walle wrote:
>>>>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you
>>>>>>>> know
>>>>>>>> the content is safe
>>>>>>>>
>>>>>>>> Am 2022-02-18 15:58, schrieb Tudor Ambarus:
>>>>>>>>> Fortunately there are controllers
>>>>>>>>> that can swap back the bytes at runtime, fixing the endiannesses.
>>>>>>>>> Provide
>>>>>>>>> a way for the upper layers to specify the byte order in DTR mode.
>>>>>>>>
>>>>>>>> Are there any patches for the atmel-quadspi yet? What happens if
>>>>>>>
>>>>>>> not public, but will publish them these days.
>>>>>>>
>>>>>>>> the controller doesn't support it? Will there be a software
>>>>>>>> fallback?
>>>>>>>
>>>>>>> no need for a fallback, the controller can ignore
>>>>>>> op->data.dtr_bswap16
>>>>>>> if
>>>>>>> it can't swap bytes.
>>>>>>
>>>>>> I don't understand. If the controller doesn't swap the 16bit values,
>>>>>> you will read the wrong content, no?
>>>>>>
>>>>>
>>>>> In linux no, because macronix swaps bytes on a 2 byte boundary both on
>>>>> reads and on page program. The problem is when you mix 8D-8D-8D mode
>>>>> and
>>>>> 1-1-1 mode along the boot stages. Let's assume you write all boot
>>>>> binaries
>>>>> in 1-1-1 mode. When reaching u-boot if you enable 8D-8D-8D mode, when
>>>>> u-boot
>>>>> will try to get the kernel it will fail, as the flash swaps the bytes
>>>>> compared
>>>>> to what was written with 1-1-1 mode. You write D0 D1 D2 D3 in 1-1-1
>>>>> mode and
>>>>> when reaching u-boot you will read D1 D0 D3 D2 and it will mess the
>>>>> kernel image.
>>>>
>>>> But you have to consider also 3rd parties, like an external programmer
>>>> or
>>>
>>> Why? If you use the same mode when reading and writing, everything is fine.
>>> I'm not sure what's your suggestion here.
>>
>> So our stance here is that we don't care about external programs?>
>> If that is the case then why bother with all this anyway? Since the swap
>> happens at both page program and read, what you write is what you read
>> back. Who cares the order stored in the actual flash memory as long as
>> the data read is correct?
>>
>> If we do care about external programs, then what would happen if the
>> external program writes data in 8D-8D-8D mode _without_ swapping the
>> bytes? This would also cause data corruption. You can't control what
>> they mode they use, and you can't detect it later either.
>>
>> I think there is no winning here. You just have to say that external
>> programs should write in 8D-8D-8D mode or it won't boot.
>>
> 
> How about swapping the bytes just at user request? Maybe with a Kconfig
> option.

Michael has suggested on #irc to always swap the bytes: if the SPI controller
can't do it, to do it in software at SPI NOR level. I don't know what to say
about this, because JEDEC216 just informs the reader I guess:
"Byte order of 16-bit words is swapped when read in 8D-8D-8D mode compared to
1-1-1 mode.", this doesn't look like a hard request. The downside to doing
the swapping in software is performance penalty which will make macronix
users have second thoughts. I don't have a strong opinion, but I lean towards
doing the swap just at user request, regardless if I do it via the SPI controller
or in software.

I would love to hear Macronix's opinion.

Cheers,
ta

> 
>>>
>>>> another OS. So, there has to be *one correct* way of writing/reading
>>>> these
>>>> bytes.
>>>>
>>>
>>>
>>
>> --
>> Regards,
>> Pratyush Yadav
>> Texas Instruments Inc.
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

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

  reply	other threads:[~2022-02-24  6:38 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-18 14:58 [PATCH 0/4] spi-mem: Allow specifying the byte order in DTR mode Tudor Ambarus
2022-02-18 14:58 ` [PATCH 1/4] spi: " Tudor Ambarus
2022-03-02 10:02   ` Pratyush Yadav
2022-03-10  5:31     ` Tudor.Ambarus
2022-03-11 17:47       ` Pratyush Yadav
2022-02-18 14:58 ` [PATCH 2/4] mtd: spi-nor: core: " Tudor Ambarus
2022-02-21  7:36   ` Michael Walle
2022-02-22 14:02     ` Tudor.Ambarus
2022-02-22 14:23       ` Michael Walle
2022-03-02 11:34   ` Pratyush Yadav
2022-03-10  8:54     ` Tudor.Ambarus
2022-02-18 14:58 ` [PATCH 3/4] mtd: spi-nor: sfdp: Get the 8D-8D-8D byte order from BFPT Tudor Ambarus
2022-02-21  7:40   ` Michael Walle
2022-03-02 12:28   ` Pratyush Yadav
2022-02-18 14:59 ` [PATCH 4/4] mtd: spi-nor: core: Introduce SPI_NOR_DTR_BSWAP16 no_sfdp_flag Tudor Ambarus
2022-02-21  7:41   ` Michael Walle
2022-03-02 12:30   ` Pratyush Yadav
2022-03-10  4:42     ` Tudor.Ambarus
2022-02-21  7:44 ` [PATCH 0/4] spi-mem: Allow specifying the byte order in DTR mode Michael Walle
2022-02-22 13:54   ` Tudor.Ambarus
2022-02-22 14:13     ` Michael Walle
2022-02-22 14:23       ` Tudor.Ambarus
2022-02-22 14:27         ` Michael Walle
2022-02-22 14:43           ` Tudor.Ambarus
2022-02-23 18:38             ` Pratyush Yadav
2022-02-24  6:08               ` Tudor.Ambarus
2022-02-24  6:37                 ` Tudor.Ambarus [this message]
2022-02-24  9:37                   ` Michael Walle
2022-02-24 10:27                     ` Tudor.Ambarus
2022-02-25  7:35                       ` zhengxunli
2022-02-24 13:24                     ` Pratyush Yadav
2022-02-24 14:02                       ` Michael Walle
2022-02-24 14:33                         ` Tudor.Ambarus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=779069a1-7389-ab70-9f03-81090d0600ba@microchip.com \
    --to=tudor.ambarus@microchip.com \
    --cc=Nicolas.Ferre@microchip.com \
    --cc=broonie@kernel.org \
    --cc=jaimeliao@mxic.com.tw \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=michael@walle.cc \
    --cc=miquel.raynal@bootlin.com \
    --cc=p.yadav@ti.com \
    --cc=richard@nod.at \
    --cc=vigneshr@ti.com \
    --cc=zhengxunli@mxic.com.tw \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox