[RFC][PATCH 2.6.12-rc2 3/3] FCC Ethernet PlatformDevice support for 82xx
Vitaly Bordug
vbordug at ru.mvista.com
Thu May 5 22:40:03 EST 2005
> Hi Vitaly
>
> Since I'm also working on this, lets try to merge our work in
> one driver.
>
> A few points regarding my driver.
>
> 1) It currently supports both 8xx FEC, 82xx FCCs.
> 2) It will also support SCC ENETS on both 8xx & 82xx, and
> FECs on coldfire's & 52xx's.
> 3) We should treat the current MII logic as temporary since
> Andy Flemming has a replacement by a MII bus.
>
> Regarding your driver, there are a couple of things it
> does arguably better than mine.
>
> 1) It has more complete platformization.
> 2) Adjustuble ring sizes.
>
> And here are some gripes.
>
> 1) I'm not a proponent of having drivers configuring pins,
> clocks & other things that are properties of each specific board.
> I'd rather have the bootloader or the platform initialization
> handle it once, and have the driver just use these settings.
> Opinions on this matter differ however :).
> 2) There are a number of platform defines that are not needed.
>
> Well, what do you think?
>
The idea itself sounds very good.
So, let's, as a starting point, implement mentioned things
(platformization and dynamic rings) within your driver (if you don't
mind of course).
More specifically, I am going to add necessary platform stuff for 82xx
and 8xx since we have only 8272ads and 885ads to test this on.
Firmware-only board-specific stuff configuration is a good thing, but
IMHO it's impossible to provide a universal bootloader configuration
that will meet all possible requirements, and a person should recompile
or even modify the firmware in such cases. That is why I included clocks
and etc stuff to the platform_data structure, so that in board-specific
headers this values could be redefined if necessary. However I'm not
sure about PIN setup, should it also reside in the platform_data struct,
or in the driver (as it is in my patch).
Another thing we should change in existing code is direct cpm2_immr
usage - the driver should be as isolated from this as possible. Dan
mentioned that the stuff that will offer IOport and likewise access
right way is almost completed so I'm looking forward some details about
it from him.
--
Sincerely,
Vitaly
More information about the Linuxppc-embedded
mailing list