[U-Boot] [PATCH 3/3 V2] dm9000: rework dm9000 to support multiple devices

[Joe Hershberger]

Hi Andrew,

On Mon, Oct 20, 2014 at 6:47 PM, Tom Rini <trini at ti.com> wrote:
> On Mon, Oct 20, 2014 at 08:16:59PM +0000, Andrew Ruder wrote:
>> On 10/20/2014 03:00 PM, Tom Rini wrote:
>> > So, on new platforms we call dm9000_initialize with the right IO/DATA
>> > locations for the given device, yes?  I think I'd rather update everyone
>> > else to call things the right and new way, rather than work-around
>> > supporting both.
>>
>> The expectation is that new platforms would move over to
>> dm9000_initialize_ex(), dm9000_initialize() just being a shim to use
>> what used to be #define'd in the board config.h for backwards
>> compatibility with older boards.
>>
>> There's really 3 options that I fought with:
>>
>> 1.) Change dm9000_initialize() to dm9000_initialize(x, y, z).  PATCH #3
>> then also includes changes to all of the various boards.
>>
>> 2.) Add dm9000_initialize_ex(x, y, z), make dm9000_initialize() call
>> dm9000_initiailize_ex(x, y, z).  No boards need to change.  This is what
>> I chose.
>>
>> 3.) Hybrid approach, do #2, make another patch (#4) that moves
>> everything over to dm9000_initialize_ex(x, y, z) while renaming it to
>> dm9000_initialize(x, y, z).  Seems more round-about than #1 with the
>> same end-result, but sometimes I feel like it is a little easier to
>> review the meat of this change (#3) without it also dealing with tons of
>> board churn.
>>
>> Thoughts?
>
> How about step 1 is checkpatch re-formatting only, step 2 is
> dm9000_initalize(x, y, z) but y/z aren't used, step 3 is passing around
> 'dev' and step 4 is the rest of the changes (so that y/z are used, if I
> follow all of the logic right).  This splits the whitespace/etc churn
> out from everything else, then makes it easy enough to review that
> boards are converted right to the new logic.

What ever became of this series?

Thanks,
-Joe