Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Message-ID: <f68dfd23-ae83-e4d9-cb08-51a097bac06b@gmail.com>
Date:   Sat, 30 Apr 2022 22:19:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.1
Content-Language: en-US
To:     Peter Geis <pgwipeout@gmail.com>, Andrew Lunn <andrew@lunn.ch>
Cc:     "Russell King (Oracle)" <linux@armlinux.org.uk>,
        "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@lists.infradead.org>,
        Linux Kernel Network Developers <netdev@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
References: <20220228233057.1140817-1-pgwipeout@gmail.com>
 <Yh1lboz7VDiuYuZV@shell.armlinux.org.uk>
 <CAMdYzYrNvUUMom4W4uD9yf9LtFK1h5Xw+9GYc54hB5+iqVmJtw@mail.gmail.com>
 <CAMdYzYrFuMw4aj_9L698ZhL7Xqy8=NeXhy9HDz4ug-v3=f4fpw@mail.gmail.com>
 <Ym1bWHNj0p6L9lY8@lunn.ch>
 <CAMdYzYq41TndbJK-=ah31=vECisgRbPmtFYwOLQQ7yn4L=JVYw@mail.gmail.com>
From:   Heiner Kallweit <hkallweit1@gmail.com>
Subject: Re: [PATCH v1] net: phy: fix motorcomm module automatic loading
In-Reply-To: <CAMdYzYq41TndbJK-=ah31=vECisgRbPmtFYwOLQQ7yn4L=JVYw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 30.04.2022 18:31, Peter Geis wrote:
> On Sat, Apr 30, 2022 at 11:52 AM Andrew Lunn <andrew@lunn.ch> wrote:
>>
>>> Good Morning,
>>>
>>> After testing various configurations I found what is actually
>>> happening here. When libphy is built in but the phy drivers are
>>> modules and not available in the initrd, the generic phy driver binds
>>> here. This allows the phy to come up but it is not functional.
>>
>> What MAC are you using?
> 
> Specifically Motorcomm, but I've discovered it can happen with any of
> the phy drivers with the right kconfig.
> 
>>
>> Why is you interface being brought up by the initramfs? Are you using
>> NFS root from within the initramfs?
> 
> This was discovered with embedded programming. It's common to have a
> small initramfs, or forgo an initramfs altogether. Another cause is a
> mismatch in kernel config where phylib is built in because of a
> dependency, but the rest of the phy drivers are modular.
> The key is:
> - phylib is built in
> - ethernet driver is built in
> - the phy driver is a module
> - modules aren't available at probe time (for any reason).
> 
> In this case phylib assumes there is no driver, when the vast majority
> of phys now have device specific drivers.It seems this is an unsafe
> assumption as this means there is now an implicit dependency of the
> device specific phy drivers and phylib. It just so happens to work
> simply because both broadcom and realtek, some of the more common
> phys, have explicit dependencies elsewhere that cause them to be built
> in as well.
> 
Because you mention the realtek phy driver:
Users reported similar issues like you if r8169 MAC driver is built-in
(or r8169 module is in initramfs) but realtek phy driver is not.
There's no direct code dependency between r8169 and realtek phy driver,
therefore initramfs-creating tools sometimes missed to automatically
include the phy driver in initramfs. To mitigate this r8169 has the following:
MODULE_SOFTDEP("pre: realtek");
This isn't strictly needed but some initramfs-creating tools consider
such soft dependencies when checking what should be included in initramfs.
If some other MAC is used with a Realtek PHY, then you may still see the
described issue.
As Andrew wrote: Eventually it's a userspace responsibility to ensure that
all needed modules are included in initramfs.

>>>> What normally happens is that the kernel loads, maybe with the MAC
>> driver and phylib loading, as part of the initramfs. The other modules
>> in the initramfs allow the root filesystem to be found, mounted, and
>> pivoted into it. The MAC driver is then brought up by the initscripts,
>> which causes phylib to request the needed PHY driver modules, it loads
>> and all is good.
>>
>> If you are using NFS root, then the load of the PHY driver happens
>> earlier, inside the initramfs. If this is you situation, maybe the
>> correct fix is to teach the initramfs tools to include the PHY drivers
>> when NFS root is being used?
>>
>>      Andrew