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

["Rafał Miłecki" <zajec5@gmail.com>]

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@milecki.pl>
>>>
>>> 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@milecki.pl>
>>
>> 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@milecki.pl>
> 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