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  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:	Mon, 2 Jun 2008 14:44:42 -0500
From:	Andy Fleming <afleming@...escale.com>
To:	Kumar Gala <galak@...nel.crashing.org>
Cc:	Jeff Garzik <jeff@...zik.org>, netdev@...r.kernel.org,
	linuxppc-dev@...abs.org
Subject: Re: [PATCH] phylib: Don't allow core of phylib to build as a module


On Jun 2, 2008, at 14:30, Kumar Gala wrote:

>
> On Jun 2, 2008, at 11:39 AM, Jeff Garzik wrote:
>
> If you really think the core of the phylib should be able to be  
> built as a module than we could possibly add function pointers to  
> phy_dev to do the real phy_read()/phy_write() and change phy_read/ 
> _write to look like:
>
> int phy_read(struct phy_device *phydev, u16 regnum) {
> 	return phydev->read(phydev, regnum);
> }

That would be a bit silly, since this is the definition of phy_read():

int phy_read(struct phy_device *phydev, u16 regnum)
{
         int retval;
         struct mii_bus *bus = phydev->bus;

         BUG_ON(in_interrupt());

         mutex_lock(&bus->mdio_lock);
         retval = bus->read(bus, phydev->addr, regnum);
         mutex_unlock(&bus->mdio_lock);

         return retval;
}


We could, of course, move phy_read *out* of the phylib module.  And  
also phy_register_fixup and any other functions needed by board code.

I'm partial to the select-it-if-you-need-it paradigm.

Andy
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists