Hi Michael, hi Dario, On 18.04.23 15:46, Frieder Schrempf 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?
I still can't see this applied anywhere. You already told me to take care of it multiple times. Can you please get it done? Thanks Frieder
