[U-Boot-Users] RFC: miiphy changes

[Ben Warren]

Haavard,

--- Haavard Skinnemoen <hskinnemoen at gmail.com> wrote:

> Don't know what you mean by a "more useful" pointer,
> but I think the
> idea is good. I have an out-of-tree ethernet driver
> supporting
> multiple interfaces, and one of the things I've been
> wondering about
> is how to know which of the two I'm supposed to use
> for the MII stuff.
> 
> Looking at the code again, I suspect the thing
> doesn't even work. Oh well.

I was trying to keep my message short, and left out
some details.  Here's my proposed structure.  I think
you'll agree that the pointer is "more useful"

struct mii_dev {
	struct list_head link;
	char *name;
	int (* read)(struct mii_dev *dev, unsigned char addr,
			unsigned char reg, unsigned short *value);
	int (* write)(struct mii_dev *dev, unsigned char
addr,
			unsigned char reg, unsigned short value);
	int (* read_noninc)(struct mii_dev *dev, unsigned
char addr,
			unsigned char reg, unsigned short *value);
	int (* address)(struct mii_dev *dev, unsigned char
addr,
			unsigned char reg, unsigned short value);
	unsigned char flags;
};


> How about passing a pointer to the associated
> mii_dev, allowing the
> driver to embed the mii_dev into a driver-specific
> struct and use
> container_of() to access the driver-specific data?
> 
> This would of course involve changing the
> declaration of the
> miiphy_register() function to take a 'struct
> mii_dev' instead of all
> of the other parameters, but this would in turn
> allow us to remove
> most of the code from that function, and it would
> allow drivers to
> allocate its 'struct mii_dev' statically or as part
> of a larger
> allocation.
> 
> Ok, maybe it's too intrusive and the out-of-tree
> maintainers will get
> angry, but I have to admit that I don't really care
> that much ;-)
> 
> Haavard
> 

Looks like we're on the same wavelength...

cheers,
Ben