[PATCH 1/5] mtd/spinand: rework detect procedure for different READ_ID operation

[Mikhail Kshevetskiy]

I can try to resend patches (flash drivers synced with linux-6.1).
Unfortunately I am not sure I will be able to do it after changes in our
mail system.

Mikhail Kshevetskiy

On 18.04.2023 16:48, Michael Nazzareno Trimarchi wrote:
> [External email]
>
>
>
>
>
> Hi Frieder
>
> On Tue, Apr 18, 2023 at 3:46 PM Frieder Schrempf
> <frieder.schrempf at kontron.de> wrote:
>> Hi Michael, Dario,
>>
>> On 28.03.23 09:57, Frieder Schrempf wrote:
>>> Hi Michael,
>>>
>>> On 10.02.23 12:57, Michael Nazzareno Trimarchi wrote:
>>>> Hi
>>>>
>>>> I will review
>>>>
>>>> On Thu, Feb 9, 2023 at 5:52 PM Tom Rini <trini at konsulko.com> wrote:
>>>>> On Thu, Feb 09, 2023 at 10:24:47AM +0100, Frieder Schrempf wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 10.01.23 12:58, Frieder Schrempf wrote:
>>>>>>> From: Mikhail Kshevetskiy <mikhail.kshevetskiy at iopsys.eu>
>>>>>>>
>>>>>>> Currently there are 3 different variants of read_id implementation:
>>>>>>> 1. opcode only. Found in GD5FxGQ4xF.
>>>>>>> 2. opcode + 1 addr byte. Found in GD5GxGQ4xA/E
>>>>>>> 3. opcode + 1 dummy byte. Found in other currently supported chips.
>>>>>>>
>>>>>>> Original implementation was for variant 1 and let detect function
>>>>>>> of chips with variant 2 and 3 to ignore the first byte. This isn't
>>>>>>> robust:
>>>>>>>
>>>>>>> 1. For chips of variant 2, if SPI master doesn't keep MOSI low
>>>>>>> during read, chip will get a random id offset, and the entire id
>>>>>>> buffer will shift by that offset, causing detect failure.
>>>>>>>
>>>>>>> 2. For chips of variant 1, if it happens to get a devid that equals
>>>>>>> to manufacture id of variant 2 or 3 chips, it'll get incorrectly
>>>>>>> detected.
>>>>>>>
>>>>>>> This patch reworks detect procedure to address problems above. New
>>>>>>> logic do detection for all variants separatedly, in 1-2-3 order.
>>>>>>> Since all current detect methods do exactly the same id matching
>>>>>>> procedure, unify them into core.c and remove detect method from
>>>>>>> manufacture_ops.
>>>>>>>
>>>>>>> This is a rework of Chuanhong Guo <gch981213 at gmail.com> patch
>>>>>>> submitted to linux kernel
>>>>>>>
>>>>>>> Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy at iopsys.eu>
>>>>>>> Signed-off-by: Frieder Schrempf <frieder.schrempf at kontron.de>
>>>>>> +Cc: Jagan, Tom
>>>>>>
>>>>>> Who is supposed to pick up these patches? Some of them have been around
>>>>>> for some months (before I resent them).
>>>>>>
>>>>>> There is no maintainer for drivers/mtd/spinand/ and no maintainer for
>>>>>> drivers/mtd/ in general.
>>>>>>
>>>>>> In Patchwork Jagan got assigned, but the get_maintainer.pl script didn't
>>>>>> even add him to Cc, of course.
>>>>>>
>>>>>> Any ideas how to proceed?
>>>>> We don't have anyone dedicated to that area, yes, sadly. I've added
>>>>> Michael and Dario as they've also been doing mtd-but-not-spi work of
>>>>> late to see if they're interested. Or since you've long been working
>>>>> here, would you like to more formally maintain the area? Thanks!
>>>> They can come from our tree. I will try to sort out all my duties weeked
>>> Any news regarding reviewing/picking these patches?
>> Ping!
>>
>> Can you please apply these patches, that have been waiting for so long?
>>
>> Thanks
>> Frieder
> Yes, waiting for Jagan, please way 1 day more
>
> Michael