netdev - Re: [RFC net-next] net: phy: Allow splitting MDIO bus/device support from PHYs

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]

Date:   Tue, 7 Feb 2017 00:19:27 +0000
From:   Russell King - ARM Linux <linux@...linux.org.uk>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, andrew@...n.ch
Subject: Re: [RFC net-next] net: phy: Allow splitting MDIO bus/device support
 from PHYs

On Mon, Feb 06, 2017 at 04:01:27PM -0800, Florian Fainelli wrote:
> On 01/30/2017 07:29 PM, Florian Fainelli wrote:
> > Introduce a new configuration symbol: MDIO_DEVICE which allows building
> > the MDIO devices and bus code, without pulling in the entire Ethernet
> > PHY library and devices code.
> > 
> > PHYLIB nows select MDIO_DEVICE and the relevant Makefile files are
> > updated to reflect that.
> > 
> > Signed-off-by: Florian Fainelli <f.fainelli@...il.com>
> 
> Andrew, Russell, does that seem sensible to you, shall I re-submit this
> as a proper patch?

I think the only comment I have is that I'd recommend that mdio_bus
and mdio_device end up as one module rather than two for these reasons:

1. they're each relatively small on their own
2. their functionality is tightly related
3. I wonder about the safety of having mdio_device_release() in a
   separate module from the bus_type stuff.

as far as (3) goes, there isn't a good way to ensure that the last
device has been released, and bus_type's (even though they normally
end up as static data) are refcounted objects just like devices, so
I wonder whether allowing driver model bus stuff to be removable is
a good idea.

To that end, I'd add a module_init() for mdio_bus_init() but remove
mdio_bus_exit() entirely, which should mean that the module loader
considers the module non-removable.

Lastly, as this is becoming (a) separate module(s), MODULE_LICENSE()
as an absolute minimum will be required.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.