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
