lkml.org 
[lkml]   [2022]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Fwd: nvmem-cells regression after adding 'call of_platform_populate() for MTD partitions'
>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?

сб, 10 дек. 2022 г. в 15:35, Thorsten Leemhuis <regressions@leemhuis.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@1--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@70000 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@70000 {
> > status = "okay";
> > nvmem-cells = <&macaddr>;
> > nvmem-cell-names = "mac-address";
> > phy-mode = "rgmii";
> > phy = <&phy0>;
> > };
> >
> > spi@10600 {
> > 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@70000' 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

\
 
 \ /
  Last update: 2022-12-11 09:28    [W:0.101 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site