Re: [PATCH] mtd: spi-nor: Fix 3-or-4 address byte mode logic

From: Pratyush Yadav <p.yadav@ti.com>
To: <Tudor.Ambarus@microchip.com>
Cc: <bert@biot.com>, <miquel.raynal@bootlin.com>, <richard@nod.at>,
	<vigneshr@ti.com>, <linux-mtd@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mtd: spi-nor: Fix 3-or-4 address byte mode logic
Date: Tue, 6 Oct 2020 17:10:24 +0530	[thread overview]
Message-ID: <20201006114022.cwc6mnpboeuzrezd@ti.com> (raw)
In-Reply-To: <73a258f3-45dd-1354-d5fd-904d5e372d2c@microchip.com>

On 06/10/20 11:19AM, Tudor.Ambarus@microchip.com wrote:
> On 10/6/20 2:03 PM, Tudor Ambarus - M18064 wrote:
> > On 10/1/20 9:34 AM, Pratyush Yadav wrote:
> >> So using an address width of 4 here is not necessarily the right thing
> >> to do. This change would break SMPT parsing for all flashes that use
> >> 3-byte addressing by default because SMPT parsing can involve register
> >> reads/writes. One such device is the Cypress S28HS flash. In fact, this
> >> was what prompted me to write the patch [0].
> > 
> > Do you refer to spi_nor_get_map_in_use()?
> 
> oh, I see. If addr width is set via the SMPT_CMD_ADDRESS_LEN_USE_CURRENT,
> case, and if the flash comes in 4 byte address mode from a bootloader,
> then setting addr_width to 3 in case BFPT_DWORD1_ADDRESS_BYTES_3_OR_4,
> will break the reading of the map.

Yes it will but that is not the problem I was trying to solve. The 
problem is simply that nor->addr_width is 0 without the
BFPT_DWORD1_ADDRESS_BYTES_3_OR_4 case that I added, since BFPT parsing 
won't touch it at all. And so SMPT_CMD_ADDRESS_LEN_USE_CURRENT results 
in the command using an op.addr.nbytes == 0 for the register read even 
though op.addr.val is set correctly. This means the controller skips the 
address phase and the register read fails.

Defaulting to 3 for the BFPT_DWORD1_ADDRESS_BYTES_3_OR_4 case means 
op.addr.nbytes is correctly set to 3 and register read works correctly 
and SMPT parsing correctly detects the current configuration.

If the address width is set to 4 by the bootloader then we have the same 
problem in some ways as the 8D boot problem where we have no way of 
easily detecting which mode is being used. I did not try to solve that 
problem with this change.

> If the Address Mode bit is volatile, maybe we can reset the flash to
> its power on state immediately after identification. For the NV bits,
> we have the same recurring problem.

Yes, the U-Boot xSPI series I sent does this somewhat. It issues a soft 
reset before handing control over to the kernel, so the kernel sees the 
flash in PoR state. This also helps when U-Boot uses the flash in 8D 
mode.

-- 
Regards,
Pratyush Yadav
Texas Instruments India