[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4991cd24-c549-4f4c-a7cb-c9f0e331c4bc@linaro.org>
Date: Wed, 10 Sep 2025 16:00:10 +0100
From: Tudor Ambarus <tudor.ambarus@...aro.org>
To: Miquel Raynal <miquel.raynal@...tlin.com>,
"Jakub \"Kuba\" Czapiga" <czapiga@...gle.com>
Cc: Pratyush Yadav <pratyush@...nel.org>, Michael Walle <mwalle@...nel.org>,
Richard Weinberger <richard@....at>, Vignesh Raghavendra <vigneshr@...com>,
linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
Konrad Adamczyk <konrada@...gle.com>, Adeel Arshad <adeel.arshad@...el.com>,
Mika Westerberg <mika.westerberg@...ux.intel.com>
Subject: Re: [PATCH] mtd: spi-nor: core: Check read CR support
On 9/10/25 3:45 PM, Miquel Raynal wrote:
> Hello,
>
> On 10/09/2025 at 16:30:43 +02, "Jakub \"Kuba\" Czapiga" <czapiga@...gle.com> wrote:
>
>> Hi Miquèl,
>>
>> On Wed, Sep 10, 2025 at 2:05 PM Miquel Raynal <miquel.raynal@...tlin.com> wrote:
>>>
>>> Hi Jakub,
>>>
>>>> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
>>>> index ac4b960101cc..79deee3a50d3 100644
>>>> --- a/drivers/mtd/spi-nor/core.c
>>>> +++ b/drivers/mtd/spi-nor/core.c
>>>> @@ -2608,6 +2608,10 @@ static int spi_nor_setup(struct spi_nor *nor,
>>>> }
>>>> }
>>>>
>>>> + /* Some SPI controllers might not support CR read opcode. */
>>>> + if (spi_nor_read_cr(nor, nor->bouncebuf) == -EOPNOTSUPP)
>>>
>>> There is a spi_nor_spimem_check_op() helper which might be better suited
>>> for this purpose?
>>
>> spi_nor_spimem_check_op() works only for spi-mem devices. spi_nor_read_cr()
>> handles both spi-mem and spi-nor controller. Using spi_nor_spimem_check_op()
>> would require adding a variation of spi_nor_read_cr() that would use
>> spi_nor_spimem_check_op() for spi-mem and spi_nor_controller_ops_read_reg()
>> for spi-nor controller.
>> Another way would be to do this check only for the spi-mem as spi-nor
>> controllers seem to be deprecated in favour of spi-mem.
>
> I'll let that choice to SPI NOR maintainers but we've collectively asked
> to switch in favor of the spi memory API for quite some time, I would
> not care too much about compatibility with the two remaining controllers
> that have not yet been converted.
>
That's correct. It's been a few years now since we stopped adding new
support for the SPI NOR controllers, so feel free to ignore that part.
All we did on that front was to make sure we don't break anything.
> But here is a proper illustration why spi-mem rocks and why SPI NOR
> controllers, besides making no sense (because we also have SPI NANDs
> now) have a flacky API as of today's standards.
Right. I'd very much like to see the SPI NOR controllers converted to
spimem or removed altogether.
Cheers,
ta
Powered by blists - more mailing lists