Thread (3 messages) 3 messages, 2 authors, 2008-09-30

Re: [PATCH 3/3] phylib: give mdio buses a device tree presence

From: Lennert Buytenhek <hidden>
Date: 2008-09-30 03:04:20

On Mon, Sep 29, 2008 at 05:45:01PM -0500, Andy Fleming wrote:
quoted
Introduce the mdio_bus class, and give each 'struct mii_bus' its own
'struct device', so that mii_bus objects are represented in the device
tree and can be found by querying the device tree.

Signed-off-by: Lennert Buytenhek <redacted>
---
drivers/net/phy/mdio_bus.c |   74 +++++++++++++++++++++++++++++++++++ 
++++++--
include/linux/phy.h        |    8 +++++
2 files changed, 78 insertions(+), 4 deletions(-)
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index d206691..f9c27ac 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -43,11 +43,35 @@
*/
struct mii_bus *mdiobus_alloc(void)
{
-	return kzalloc(sizeof(struct mii_bus), GFP_KERNEL);
+	struct mii_bus *bus;
+
+	bus = kzalloc(sizeof(*bus), GFP_KERNEL);
+	if (bus != NULL)
+		bus->state = MDIOBUS_ALLOCATED;
+
+	return bus;
}
EXPORT_SYMBOL(mdiobus_alloc);
Do we really need all this state tracking?  Doesn't the device layer  
do this for us?  I looked through other driver subsystems, and I  
didn't see anything like this.  Can we rearchitect this so that we're  
not having to track allocation/registration state?
I modeled it after struct net_device's state tracking.  It's "necessary"
for one case, which is mdiobus_alloc() + mdiobus_free() without an
intervening mdiobus_register/unregister() pair (e.g. what happens when
the mii bus driver's setup function encounters an error halfway through
and frees the mii bus without ever registering it).  In that case, we
need to just call kfree() instead of put_device(), since the embedded
struct device will never have been registered.  struct net_device has
this same issue, and deals with it in the same way.

Also, MDIOBUS_ALLOCATED starts at 1 to make sure that any users not
using mdiobus_alloc() (i.e. ones that still embed a struct mii_bus in
one of their own structs) are caught and dealt with.  But that part
isn't really necessary.  Some of the other states aren't strictly
necessary either, but are just there to make sure you call stuff in
the right order.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help