Re: [PATCH 0/2] mtd: hyperbus: Add support for Infineon S26Hx-T

[Tudor Ambarus <tudor.ambarus@xxxxxxxxxx>]

Ah, Sergei's email was bouncing, I updated his email address.

Sergei, would you please read the thread? Thanks!

On 22.01.2024 08:11, Tudor Ambarus wrote:
> + Sergei, Geert, Mark & linux-spi
> 
> Hi, Sergei,
> 
> On 23.05.2023 07:22, Tudor Ambarus wrote:
>> Hi, Takahiro, Vignesh,
>>
>>
>> On 07.04.2023 09:11, tkuw584924@xxxxxxxxx wrote:
>>> From: Takahiro Kuwano <Takahiro.Kuwano@xxxxxxxxxxxx>
>>>
>>> This sereis adds support for Infineon S26HL-T/S26HS-T flash family.
>>> https://www.infineon.com/dgdl/Infineon-S26HS01GTGABHM020-DataSheet-v01_00-EN.pdf?fileId=8ac78c8c7f2a768a017f52f2f5182c91
>>>
>>> This family supports two interface modes, SPI mode and Hyperbus mode. The mode
>>> can be switched at rutime. The default mode is selected by ordering option
>>> and non-volatile user configuration. In hyperbus mode, the device is compatible
>>> with S26KL-S/S26KS-S hyperflash family that supports hyperbus only so one of
>>> use cases of S26Hx-T is replacement of (or migration from) S26Kx-S. This patch
>>> set focuses on particular usage that the device is pre-configured as hyperbus
>>> mode for compatibility with S26Kx-S.
>>
>> I'm questioning the overall hyperbus software architecture, not your
>> patches per se. IMO hyperbus framework should have been written on top
>> of SPIMEM and the controllers be placed in drivers/spi/. So I'd first
>> address the SPIMEM adoption before adding/accepting new support. Would
>> love to hear more from Vignesh.
>>
> 
> RPC is the only multi IO SPI controller that's upstreamed and capable of
> dealing with hyperflashes, but there are others which are not upstreamed
> yet (microchip).
> 
> Struct ``struct rpcif_op`` [1] duplicates the contents of ``struct
> spi_mem_op`` [2] which could have been avoided if hyperflash driver was
> extended with SPI MEM support. This way the RPC hyperbus driver, which
> is an SPI controller, could have been moved to drivers/spi.
> 
> Sergei, do you remember why we haven't used SPI MEM for hyberbus since
> the beginning? Was it something that we aimed for in a future patch set?
> 
> Thanks,
> ta
> 
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git/tree/include/memory/renesas-rpc-if.h?h=mtd/for-6.8#n22
> 
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git/tree/include/linux/spi/spi-mem.h?h=mtd/for-6.8#n99
>