When using nvmem, it may be necessary to defer probe until the specific
nvmem driver is loaded to get the proper MAC.

Rosen Penev (2):
  net: ethernet: cortina: use devm to enable clocks
  net: ethernet: cortina: fix nvmem mac addresses

 drivers/net/ethernet/cortina/gemini.c | 25 +++++++------------------
 1 file changed, 7 insertions(+), 18 deletions(-)

--
2.53.0

On Fri, Feb 20, 2026 at 3:20 AM Rosen Penev <rosenp@gmail.com> wrote:

> When using nvmem, it may be necessary to defer probe until the specific
> nvmem driver is loaded to get the proper MAC.
>
> Rosen Penev (2):
>   net: ethernet: cortina: use devm to enable clocks
>   net: ethernet: cortina: fix nvmem mac addresses

Net-next is closed so you will have to resend this:
https://netdev.bots.linux.dev/net-next.html

But I like what I see :)
Reviewed-by: Linus Walleij <linusw@kernel.org>

What I actually most of all want to achieve here is to support loading
the PHY as module, but I suspect that then the ethernet driver has to
be a module as well so modprobe can do its job.

Yours,
Linus Walleij

> What I actually most of all want to achieve here is to support loading
> the PHY as module, but I suspect that then the ethernet driver has to
> be a module as well so modprobe can do its job.

I don't think that is true. You should be able to have a built in MAC
and a modular PHY. phylib will call out to modprobe, passing the ID of
the PHY in order to load the driver. There are some interesting race
conditions when interface open() is called while the PHY module is
still loading, so you end up with genphy. But the race exists
independent of built in vs modular MAC.

	    Andrew