linux-kernel - Re: [PATCH v3] arm64: dts: freescale: imx93-phycore-som: Delay the phy reset by a gpio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <739f93d0-4cb4-4f1a-8792-84502d4beefe@lunn.ch>
Date: Mon, 2 Jun 2025 14:26:48 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Christoph Stoidner <C.Stoidner@...tec.de>
Cc: Stefan Wahren <wahrenst@....net>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Pengutronix Kernel Team <kernel@...gutronix.de>,
	Fabio Estevam <festevam@...il.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"imx@...ts.linux.dev" <imx@...ts.linux.dev>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"upstream@...ts.phytec.de" <upstream@...ts.phytec.de>
Subject: Re: [PATCH v3] arm64: dts: freescale: imx93-phycore-som: Delay the
 phy reset by a gpio

> > I agree it is long enough, but i'm also surprised how slow the kernel
> > was. Are you using a fixed IP address, or dhcp?
> 
> I use a fixed IP address.
> 
> But isn't the bringup of ethernet+phy interface one of the last things
> that happens during the kernel boot-up?

Mounting the rootfs is somewhat towards the end of the core
kernel. But if you have an initramfs, there can be modules loaded both
before and afterwards, and once the rootfs has been mounted, yet more
modules can be loaded.

> However, what timing would you expect?

I've seen interfaces configured up from deep within
register_netdev(). I don't remember the exact configuration, but i
thought it was NFS root. It might be in combination with initramfs. If
you have the Ethernet driver as a module in the initramfs, and are
using the "rootwait" option, it could be that you are already past the
point it would first mount the rootfs, and with every new device
popping into existence it is trying to see if the just created device
allows it to do the mount. At that point, register_netdev() is going
to trigger actions.

	Andrew