Re: Regression? [PATCH 1/2] mtd: call of_platform_populate() for MTD partitions

[Rafał Miłecki]

On 25.04.2022 03:20, Daniel Golle wrote:
> On Mon, Apr 11, 2022 at 11:00:32AM +0200, Miquel Raynal wrote:
> > On Wed, 2022-04-06 at 14:32:24 UTC, =?utf-8?b?UmFmYcWCIE1pxYJlY2tp?= wrote:
> > > From: Rafał Miłecki <rafal@xxxxxxxxxx>
> > >
> > > Until this change MTD subsystem supported handling partitions only with
> > > MTD partitions parsers. That's a specific / limited API designed around
> > > partitions.
> > >
> > > Some MTD partitions may however require different handling. They may
> > > contain specific data that needs to be parsed and somehow extracted. For
> > > that purpose MTD subsystem should allow binding of standard platform
> > > drivers.
> > >
> > > An example can be U-Boot (sub)partition with environment variables.
> > > There exist a "u-boot,env" DT binding for MTD (sub)partition that
> > > requires an NVMEM driver.
> > >
> > > Ref: 5db1c2dbc04c ("dt-bindings: nvmem: add U-Boot environment variables binding")
> > > Signed-off-by: Rafał Miłecki <rafal@xxxxxxxxxx>
> >
> > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git mtd/next, thanks.
>
> I'm trying to use next-20220422 and noticed a few new oops'es.
> Turns out it could be a problem with this commit according to
>
> [daniel@box linux.git]$ git bisect good
> 68471517e883902cdff6ea399d043b17f803b1a8 is the first bad commit
> commit 68471517e883902cdff6ea399d043b17f803b1a8
> Author: Rafał Miłecki <rafal@xxxxxxxxxx>
> Date:   Wed Apr 6 16:32:24 2022 +0200
>
>      mtd: call of_platform_populate() for MTD partitions
> [...]
> ---
>
> So when ever there is at least one 'compatible' node for any of the
> mtd partitions I get the oops messages below. It doesn't really matter
> what the compatible string is, "nvmem-cells" as well as "denx,fit"
> (used for OpenWrt mtdsplit not even present in linux-next, so just a
> dead hint in DTS) make the kernel to oops.
>
> Despite the messages being shown, both accessing MTD partitions and
> also eth0 MAC address populated via NVMEM seem to work without
> problems (at least looks like it on first sight).
>
> Find the full device tree here:
>
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/mediatek/dts/mt7622-ubnt-unifi-6-lr-ubootmod.dts

I found it! It used to happen (before dropping patch) with:
# CONFIG_MTD_PARTITIONED_MASTER is not set

I'll work on V2 which doesn't require
CONFIG_MTD_PARTITIONED_MASTER=y