Re: [RFC][PATCH 2.6.12-rc2 3/3] FCC Ethernet PlatformDevice support for 82xx

[Vitaly Bordug <vbordug@ru.mvista.com>]

> 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