Messages in this thread | | | Date | Wed, 4 May 2022 15:40:55 +0200 | Subject | Re: Regression? [PATCH 1/2] mtd: call of_platform_populate() for MTD partitions | From | 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@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
| |