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 > <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>>>>> >>>>>>> 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 <[email protected]> patch >>>>>>> submitted to linux kernel >>>>>>> >>>>>>> Signed-off-by: Mikhail Kshevetskiy <[email protected]> >>>>>>> Signed-off-by: Frieder Schrempf <[email protected]> >>>>>> +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
