[PATCH 6.6.y] mtd: spi-nor: macronix: Add post_sfdp fixups for Quad Input Page Program

[Cheng Ming Lin]

Hi Michael,

Michael Walle <mwalle at kernel.org> 於 2026年7月2日週四 下午2:44寫道：
>
> On Thu Jul 2, 2026 at 4:13 AM CEST, Cheng Ming Lin wrote:
> > Hi Sasha,
> >
> > Sasha Levin <sashal at kernel.org> 於 2026年7月2日週四 上午8:38寫道：
> >>
> >> I can't take this series for 6.6.y: patch 2 adds flash_info entries
> >> with a NULL .name, and 6.6's spi_nor_match_name() has no NULL guard
> >> (only added upstream in ac5bfa968b60), so the legacy probe-by-name
> >> path can oops at boot.
> >
> > Thank you for pointing this out and catching the potential issue.
> >
> > I have verified this, and you are absolutely right. The issue stems from
> > the strcmp(name, manufacturers[i]->parts[j].name) evaluation within the
> > legacy probe path. Since 6.6.y lacks the null guard, passing a NULL .name
> > will result in a null pointer dereference in strcmp() and cause a kernel
> > oops during boot.
> >
> > I will add the .name to the new flash entries and submit a v2 series.
>
> No, please backport the needed patches. The reason is that the name
> shouldn't become something an application relies on (it is also
> exposed via sysfs).
>
> For all people not too involved: we are dropping the name for new
> flash additions, because it is almost always wrong, due to flash id
> reuse among almost all flash vendors.

Thank you for the clarification regarding the upstream policy on dropping
flash names. That makes perfect sense given the ID reuse issues.

Unfortunately, our emails crossed paths, and I had already submitted the
v2 series (which adds the .name back) just before seeing your message.
Please disregard the v2 submission.

To follow your guidance, I will prepare a v3 series.
My plan is to:

1. Backport commit ac5bfa968b60 ("mtd: spi-nor: fix flash probing") as the
first patch in the v3 series to resolve the NULL pointer dereference issue
in 6.6.y.

2. Send my flash addition patches (without the .name field, using comments
instead) as the subsequent patches in the series.

Does this structure for the v3 series look good to you?

>
> -michael
>
> >
> >>
> >> Please send a v2 that either names the new entries or backports
> >> ac5bfa968b60 first.
> >>
> >> The 6.12.y series is queued, thanks.
> >>
> >> --
> >> Thanks,
> >> Sasha
> >
> > Thanks,
> > Cheng Ming Lin
>

Thanks,
Cheng Ming Lin