----- "Mike Frysinger" vapier@gentoo.org wrote:

On Thursday, August 25, 2011 01:10:30 Ajay Bhargav wrote:

...

----- "Mike Frysinger" vapier@gentoo.org wrote:

...

On Wednesday, August 24, 2011 09:07:18 Ajay Bhargav wrote:

...

• /* Read mac from env if available */
• eth_getenv_enetaddr("ethaddr", dev->enetaddr);

you shouldnt need to do this. the higher layers will take care

of

...

...

this for you when you set write_hwaddr

I do not have a hardware storage for MAC on my controller.

write_hwaddr

...

is not needed for me.

ok, but you should not be touching dev->enetaddr in your registration

function. the main net/eth.c:eth_initialize() takes care of this for you.

...

...

...

+int armada100_fec_initialize() +{ ...

• darmdfec->regs = (void *) ARMD1_FEC_BASE;
  

make the reg base a parameter to armada100_fec_initialize()

This driver is for Armada100 series and base address is same for the whole series, so i did not feel passing it as a parameter. Can you please tell me if there is any specific reason for the same?

drivers should be written for the IP they control, not for specific SoCs or boards. and what people often start off with "this SoC only has one MAC so screw multi-instance" quite frequently turns into "this next SoC supports multiple MACs!".

i'm not familiar with the Armada100, or the MAC IP that is in that SoC, but this story repeats itself constantly in the SoC world because people focus on the one specific SoC they have in their hand and not the bigger picture. simply witness the ARM hell that Linux is currently in and is being cleaned up through the Linaro organization. -mike

Hi Mike,

I got your point.. Thanks for clearing this. I will make sure that this kind of problem does not happen in my case :)

Regards, Ajay