Re: [RFC] [PATCH 1/2] Driver to remember ethernet MAC values:maclist

From: Alessandro Zummo
Date: Mon Feb 20 2006 - 08:26:50 EST


On Mon, 20 Feb 2006 14:07:12 +0100
Lennert Buytenhek <buytenh@xxxxxxxxxxxxxx> wrote:

> > you're certainly right on the ixp4xx, but the are other uses
> > for this driver which we are working on.. for example,
> > some Cirrus Logic ARM based chips (ep93xx) have an ethernet device
> > that could benefit from that.

> Many platforms have the same problem (esp. embedded ones), but that
> doesn't mean that maclist is necessarily the best solution.

of course, that's why I wrote "maclist-alike"


> The main problem I see with maclist (correct me if I'm wrong) is that
> there can be multiple devices in the system that need to get their
> MAC address from somewhere, and maclist doesn't make the distinction
> which address belongs to what. The main issue I have with it is that
> it's too general, and that it's lots of code.

you're right, usually the first device will get the first mac
and so on. it is general because it has been coded to be that way
I think.


> I don't think something as complex as maclist is necessary to solve
> the problem. For example, why don't you just have an unsigned char
> ixp4xx_mac_addr[6] in the ixp4xx core code, have the ixp4xx board code
> fill that in, and have the ixp4xx ethernet driver use that?
>
> Or just pass the MAC along in platform device style. What I did in
> drivers/net/ixp2000/ was to have enp2611.c (board-specific code) read
> the MAC from the board, and pass it to ixpdev.c (generic code) in the
> net_device structure.

that perfectly doable, but maybe having one common interface could
be a cleaner solution. your setup is board -> netdriver
while maclist implements board -> storage -> netdriver.

It is absolutely not a requirement, just a commodity.

--

Best regards,

Alessandro Zummo,
Tower Technologies - Turin, Italy

http://www.towertech.it

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/