On Thu, Apr 18, 2024 at 02:15:29PM GMT, Coiby Xu wrote:
Hi Baoquan,
On Thu, Sep 28, 2023 at 07:51:01AM +0800, Baoquan He wrote:
Hi Coiby,
On 09/27/23 at 10:34am, Coiby Xu wrote:
Resolves: https://issues.redhat.com/browse/RHEL-7028
Currently, nfs dumping fails on some machines that has a dedicated PHY driver (dealing with the physical layer) or MDIO bus (connecting the MAC to PHY devices) driver. This is because kexec-tools doesn't install dedicated PHY or MDIO driver explicitly and the NIC driver don't specify the dependency on the needed PHY or MDIO driver. So when the dependency
Do you know why the NIC driver don't specify the dependency? In theory, it should be. Is there chance this can be fixed in kernel or the NIC driver at the same time?
Sorry, I lost track of this work. Hangbin told me he can't answer the question if an NIC driver should specify the dependency since it's not his expertise.
So I dug a bit deeper by myself. My conclusion is a NIC driver (MAC driver) shouldn't specify dependency on a specific PHY driver. A MAC driver is for dealing with the Data link layer and a PHY driver is for physical layer. So as long as a MAC driver can talk to the PHY layer via APIs, it doesn't care which PHY driver or device it's talking to. More can be found on https://docs.kernel.org/networking/phy.html. There are even external hot-pluggable PHY devices as seen from https://www.kernel.org/doc/html/latest/networking/sfp-phylink.html
So we shouldn't fix it in NIC or the kernel. Sorry, maybe my commit message is a bit misleading when I said "the NIC driver don't specify the dependency on the needed PHY or MDIO driver".
I have improved the commit msg and sent the patches to https://github.com/rhkdump/kdump-utils/pull/3
So unless a driver e.g. r8169 explicitly depend on a certain PHY driver, we shouldn't specify the dependency in the NIC driver,
commit 11287b693d03830010356339e4ceddf47dee34fa Author: Heiner Kallweit hkallweit1@gmail.com Date: Mon Jan 7 21:49:09 2019 +0100 r8169: load Realtek PHY driver module before r8169 This soft dependency works around an issue where sometimes the genphy driver is used instead of the dedicated PHY driver. The root cause of the issue isn't clear yet. People reported the unloading/re-loading module r8169 helps, and also configuring this soft dependency in the modprobe config files. Important just seems to be that the realtek module is loaded before r8169. Once this has been applied preliminary fix 38af4b903210 ("net: phy: add workaround for issue where PHY driver doesn't bind to the device") will be removed.
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c index 784ae5001656..abb94c543aa2 100644 --- a/drivers/net/ethernet/realtek/r8169.c +++ b/drivers/net/ethernet/realtek/r8169.c @@ -708,6 +708,7 @@ module_param(use_dac, int, 0); MODULE_PARM_DESC(use_dac, "Enable PCI DAC. Unsafe on 32 bit PCI slot."); module_param_named(debug, debug.msg_enable, int, 0); MODULE_PARM_DESC(debug, "Debug verbosity level (0=none, ..., 16=all)"); +MODULE_SOFTDEP("pre: realtek");
-- Best regards, Coiby