Date:   Mon, 12 Dec 2022 10:14:49 +0100
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Maxim Kiselev <bigunclemax@...il.com>
Cc:     Thorsten Leemhuis <regressions@...mhuis.info>,
        linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Vignesh Raghavendra <vigneshr@...com>,
        Richard Weinberger <richard@....at>,
        Maxim Kochetkov <fido_max@...ox.ru>,
        Rafał Miłecki <rafal@...ecki.pl>,
        "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>
Subject: Re: nvmem-cells regression after adding 'call
 of_platform_populate() for MTD partitions'

Hi Maxim,

bigunclemax@...il.com wrote on Sun, 11 Dec 2022 11:26:29 +0300:

> >On 10.12.22 10:52, Maxim Kiselev wrote:  
> >>
> >> After applying  
> >
> >This makes me wonder: "applying" as in "applying it to some version that
> >doesn't contain this change normally" or as it "after it was applied to
> >mainline I have the following problem with vanilla kernel version <???>"?  
> 
> Sorry for confusing you, I mean "after it was applied to mainline".
> I have this problem with vanilla kernel version 6.0.
> 
> >>> I faced with a problem that my ethernet device can't be probed because it
> >>> wait when 'nvmem-cells' device will be probed first.  
> >>
> >>FWIW, there is a discussion about a problems that at least to my
> >>untrained eyes looks similar:
> >>https://lore.kernel.org/all/Yyj7wJlqJkCwObRn@lx2k/  
> 
> Yes it looks like the same issue.
> 
> 
> I think the root of the problem was the choice of 'compatible'
> device tree property to mark the mtd partition node as a nvmem provider.
> 
> I'm talking about this part in 'mtd_nvmem_add' function.
> > config.no_of_node = !of_device_is_compatible(node, "nvmem-cells");  
> 
> Maybe we should change the 'compatible' property to something else?

At a first glance I don't get why the compatible would matter so much
here, can you point to some core DT logic that would have an effect? I
mean besides leading to the creation of a cell. IOW, what would be done
differently if the compatible was different?

Can you also dump the device links (if you can reach a prompt) from
sysfs?

In theory there should be a link between ethernet and spi-nor which is
fulfilled when the spi-nor device probes and leads to the creation of
device links. Maybe there is "something else" that the mtd core should
do, because this just works with eeproms (non-mtd cells), so let's find
out.

> сб, 10 дек. 2022 г. в 15:35, Thorsten Leemhuis <regressions@...mhuis.info>:
> >
> > [CCing the regression mailing list, as it should be in the loop for all
> > regressions, as explained in
> > https://docs.kernel.org/admin-guide/reporting-regressions.html ]
> >
> > Hi, this is your Linux kernel regression tracker. Thx for the report.
> >
> > On 10.12.22 10:52, Maxim Kiselev wrote:  
> > >
> > > After applying  
> >
> > This makes me wonder: "applying" as in "applying it to some version that
> > doesn't contain this change normally" or as it "after it was applied to
> > mainline I have the following problem with vanilla kernel version <???>"?
> >  
> > > this commit 'mtd: call of_platform_populate() for MTD
> > > partitions' (bcdf0315),  
> >
> > CCing Rafał, who authored bcdf0315.
> >  
> > > I faced with a problem that my ethernet device can't be probed because it
> > > wait when 'nvmem-cells' device will be probed first.  
> >
> > FWIW, there is a discussion about a problems that at least to my
> > untrained eyes looks similar:
> > https://lore.kernel.org/all/Yyj7wJlqJkCwObRn@lx2k/
> >
> > Rafał, has some progress been made to resolve this?
> >
> > To me it sounds like this might warrant a "revert, and reapply later
> > when the cause for the regression was addressed". Rafał, it seems you
> > suggested something like that, but it doesn't look like that happened
> > for one reason or another. Or am I missing something?
> >
> > Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> >
> > P.S.: As the Linux kernel's regression tracker I deal with a lot of
> > reports and sometimes miss something important when writing mails like
> > this. If that's the case here, don't hesitate to tell me in a public
> > reply, it's in everyone's interest to set the public record straight.
> >  
> > > But there is no such driver which is compatible with 'nvmem-cells' because
> > > 'nvmem-cells' is just a mark used by the 'mtd_nvmem_add' function.
> > >
> > > So this leads to appeating of unresolved dependency for the ethernet device.
> > > And that's why the ethernet device can't be added and probed.
> > >
> > > Here is a part of kernel log when spi flash probe start:
> > >  
> > >> device: 'spi0': device_add
> > >> device: 'spi0.0': device_add
> > >> spi-nor spi0.0: mx66l51235f (65536 Kbytes)
> > >> 7 fixed-partitions partitions found on MTD device spi0.0  
> > >
> > > After 'm25p80' probe 'f1070000.ethernet' linked to 'partition@1' :
> > >  
> > >> device: 'f1010600.spi:m25p80@0:  
> > > partitions:partition@1': device_add  
> > >> device: 'platform:f1010600.spi:m25p80@0:partitions:partition@...platform:f1070000.ethernet': device_add
> > >> devices_kset: Moving f1070000.ethernet to end of list
> > >> platform f1070000.ethernet: Linked as a consumer to f1010600.spi:m25p80@0:partitions:partition@1
> > >> ethernet@...00 Dropping the fwnode link to partition@1  
> > >
> > > And as a result I got `-EPROBE_DEFER` for `f1070000.ethernet`
> > >  
> > >> platform f1070000.ethernet: error -EPROBE_DEFER: supplier f1010600.spi:m25p80@0:partitions:partition@1 not ready  
> > >
> > > Here is a part of my device tree:
> > >
> > >     enet1: ethernet@...00 {
> > >         status = "okay";
> > >         nvmem-cells = <&macaddr>;
> > >         nvmem-cell-names = "mac-address";
> > >         phy-mode = "rgmii";
> > >         phy = <&phy0>;
> > >     };
> > >
> > >     spi@...00 {
> > >         status = "okay";
> > >
> > >         m25p80@0 {
> > >             compatible = "mx66l51235l";
> > >             reg = <0>;
> > >             #address-cells = <1>;
> > >             #size-cells = <1>;
> > >
> > >             partitions {
> > >                 compatible = "fixed-partitions";
> > >                 #address-cells = <1>;
> > >                 #size-cells = <1>;
> > >
> > >                 partition@0 {
> > >                     reg = <0x00000000 0x000080000>;
> > >                     label = "SPI.U_BOOT";
> > >                 };
> > >
> > >                 partition@1 {
> > >                     compatible = "nvmem-cells";
> > >                     reg = <0x000A0000 0x00020000>;
> > >                     label = "SPI.INV_INFO";
> > >                     #address-cells = <1>;
> > >                     #size-cells = <1>;
> > >                     ranges = <0 0x000A0000 0x00020000>;
> > >
> > >                     macaddr: mac@6 {
> > >                         reg = <0x6 0x6>;
> > >                     };
> > >                 };
> > >
> > >             };
> > >         };
> > >     };
> > >
> > > In the example above 'ethernet@...00' requires 'macaddr: mac@6' which is
> > > located inside mtd 'partition@1' of 'm25p80@0' spi flash.  
> >
> > P.P.S.: let me add this to the regression tracking:
> >
> > #regzbot ^introduced bcdf0315
> > #regzbot title mtd: ethernet device can't be probed anymore due to
> > broken nvmem-cells dep
> > #regzbot monitor: https://lore.kernel.org/all/Yyj7wJlqJkCwObRn@lx2k/
> > #regzbot ignore-activity  


Thanks,
Miquèl

Powered by blists - more mailing lists