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] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 13 Aug 2014 12:43:14 -0300
From:	Fabio Estevam <>
To:	Krzysztof Hałasa <>
Cc:	"" <>,
	Ezequiel Garcia <>
Subject: Re: Parent device of MDIO bus

On Wed, Aug 13, 2014 at 10:51 AM, Krzysztof Hałasa <> wrote:
> Hi,
> I noticed a recent change a71e3c37960ce5f9c6a519bc1215e3ba9fa83e75:
>     net: phy: Set the driver when registering an MDIO bus device
>     mdiobus_register() registers a device which is already bound to a driver.
>     Hence, the driver pointer should be set properly in order to track down
>     the driver associated to the MDIO bus.
>     This will be used to allow ethernet driver to pin down a MDIO bus driver,
>     preventing it from being unloaded while the PHY device is running.
> Does this mean an MDIO driver must now be separate from its Ethernet
> driver in order for the latter to be rmmod-able? Otherwise, the Ethernet
> .probe (*_init_one()) calls mdiobus_register() and immediately bumps
> refcount (for both drivers in a common module) forever.
> The other option seems to be moving mdio_register() from Ethernet's
> .probe() to dev->open(). This will make the driver un-rmmod-able when
> the Ethernet device is open (not a big problem and we had it this way
> some time ago). It will be rmmod-able again when all Ethernets are
> closed.
> Or am I missing something?
> What do you think?

This patch has been reverted in mainline.
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists