[GIT PULL] mtd: Fixes for v5.17-rc5

[GIT PULL] mtd: Fixes for v5.17-rc5

[Miquel Raynal]

Hello Linus,

This is a fixes MTD PR for the next -rc.

Thanks,
Miquèl

The following changes since commit e783362eb54cd99b2cac8b3a9aeac942e6f6ac07:

  Linux 5.17-rc1 (2022-01-23 10:12:53 +0200)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git tags/mtd/fixes-for-5.17-rc5

for you to fetch changes up to 36415a7964711822e63695ea67fede63979054d9:

  mtd: rawnand: brcmnand: Fixed incorrect sub-page ECC status (2022-01-31 17:08:56 +0100)

----------------------------------------------------------------
MTD changes:
* Qcom:
  - Don't print error message on -EPROBE_DEFER
  - Fix kernel panic on skipped partition
  - Fix missing free for pparts in cleanup
* phram: Prevent divide by zero bug in phram_setup()

Raw NAND controller changes:
* ingenic: Fix missing put_device in ingenic_ecc_get
* qcom: Fix clock sequencing in qcom_nandc_probe()
* omap2: Prevent invalid configuration and build error
* gpmi: Don't leak PM reference in error path
* brcmnand: Fix incorrect sub-page ECC status

----------------------------------------------------------------
Ansuel Smith (2):
      mtd: parsers: qcom: Fix kernel panic on skipped partition
      mtd: parsers: qcom: Fix missing free for pparts in cleanup

Bryan O'Donoghue (2):
      mtd: rawnand: qcom: Fix clock sequencing in qcom_nandc_probe()
      mtd: parsers: qcom: Don't print error message on -EPROBE_DEFER

Christian Eggers (1):
      mtd: rawnand: gpmi: don't leak PM reference in error path

Dan Carpenter (1):
      mtd: phram: Prevent divide by zero bug in phram_setup()

Miaoqian Lin (1):
      mtd: rawnand: ingenic: Fix missing put_device in ingenic_ecc_get

Roger Quadros (1):
      mtd: rawnand: omap2: Prevent invalid configuration and build error

david regan (1):
      mtd: rawnand: brcmnand: Fixed incorrect sub-page ECC status

 drivers/mtd/devices/phram.c                | 12 ++++++++----
 drivers/mtd/nand/raw/Kconfig               |  3 ++-
 drivers/mtd/nand/raw/brcmnand/brcmnand.c   |  2 +-
 drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c |  3 ++-
 drivers/mtd/nand/raw/ingenic/ingenic_ecc.c |  7 ++++++-
 drivers/mtd/nand/raw/qcom_nandc.c          | 14 ++++++--------
 drivers/mtd/parsers/qcomsmempart.c         | 36 +++++++++++++++++++++++-------------
 7 files changed, 48 insertions(+), 29 deletions(-)

Re: [GIT PULL] mtd: Fixes for v5.17-rc5

[pr-tracker-bot]

The pull request you sent on Fri, 18 Feb 2022 15:36:17 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git tags/mtd/fixes-for-5.17-rc5

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7993e65fdd0fe07beb9f36f998f9bbef2c0ee391

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] mtd: Fixes for v5.17-rc5

[Linus Torvalds]

I'm about to release rc7, and I still don't have the build fix for MTD
that has been pending in the mtd tree since Feb 19.

I'm talking about commit 7cf1de957a98 ("mtd: rawnand: omap2: Actually
prevent invalid configuration and build error"). The lack of which
still causes build errors on at least sparc64, and has since rc4.

This is getting quite frustrating. These are basic errors that fail
some very basic issues, have fixes, and the fixes for some
inexplicable reason aren't actually propagated up.

Why?

                Linus

Re: [GIT PULL] mtd: Fixes for v5.17-rc5

[Miquel Raynal]

Hi Linus,

torvalds@linux-foundation.org wrote on Sun, 6 Mar 2022 12:08:04 -0800:

> I'm about to release rc7, and I still don't have the build fix for MTD
> that has been pending in the mtd tree since Feb 19.
> 
> I'm talking about commit 7cf1de957a98 ("mtd: rawnand: omap2: Actually
> prevent invalid configuration and build error"). The lack of which
> still causes build errors on at least sparc64, and has since rc4.

I have received a robot error triggered because of COMPILE_TEST being
selected in a random config. Yes it should not happen, but no it does
not break sparc64 AFAIK. If it effectively does, then I deeply
apologize but I didn't receive this information myself.

I proposed a fix a month ago but it got rejected because people claimed
"nobody else used that solution until now so let's not try that". So we
went for another fix, which lead to the issue you complain about.

I then received another fix to queue on top of -rc4, which I did,
in a reasonable time frame. But then I had to wait for robots to
tell me if there is still a breakage with another random configuration,
and this may take about a week to happen.

Last week I was fine with the result and finally took the time to send
it to you on Friday. Yes, it could have been earlier. To be short, when
writing a short explanation for this PR, I realized the fix would
increase the kernel size for no reason on several architectures so I
asked if we could consider another way:
https://lore.kernel.org/linux-mtd/6c09de15-1ab2-5ca8-7003-69ff3f7c4dc5@kernel.org/T/#mec7f38108f189f4af5b865011d758a2afa6009c4

Thanks to the discussions we had today, there was actually a
misunderstanding regarding this dependency and the fix can go in as-is.

Should I have sent this fix anyway? I still think retaining the fix
was the good thing to do. Should I have done that earlier? Yes, I could
have saved a week in the best case. Was this fix urgent? I don't think
it was to the point of getting you (and now myself as well) frustrated.

> This is getting quite frustrating. These are basic errors that fail
> some very basic issues,

"select" dependencies are the source of many problems because of the
"I won't propagate the dependency any further" choice. Yes for many
simple situations Kconfig is well shaped but for any non trivial
situation it is not what I would call a "very basic issue".

> have fixes,

Not from my point of view, at least not while I was still in time to
send the fix.

> and the fixes for some inexplicable reason aren't actually propagated up.

The truth is, you personally cannot follow all the patches nor read
all the discussions. I am not blaming anybody for that. I understand
you have to ask. But I would personally appreciate if you could use a
more friendly tone; "getting quite frustrating", "basic errors, "very
basic issues", "inexplicable reason" are all superfluous.

Anyway, I am sorry for the inconvenience, I will provide this fix asap.

Thanks,
Miquèl