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

[Tom Rini]

On Tue, May 09, 2023 at 09:09:28AM +0200, Frieder Schrempf wrote:
> 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 <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?
> 
> 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?

Yes, I'd really like to see a PR at least vs -next at this point so
things aren't lost, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230515/2b251692/attachment.sig>