In message 1080925072.4706.13.camel@sabrina.arlut.utexas.edu you wrote:
Here is the fix as you requested. But this begs the question, can our board specific files change at anytime? And not only be changed but be changed into something that does not work?
Actually this can happen any time. It is pretty unlikely, though.
But as maintainer of the U-Boot project I will occasionally decide to check in patches which may effect board specific code, too.
To perform a global clean-up operations, for example to eliminate redundand code and replace it by a common implementation like in this case, I have no other choice but to implement this change everywhere and for every board. Of course we try to test on as many different boards as possible, but we cannot test on all boards.
Although never put down in writing I consider it one of the responsibilities of a board maintainer to check current versions every now and then - and this definitely means more frequently than once every three months.
I can understand changing code in the rest of u-boot and having that break our board code, but I don't see the problem with our own board code using a depreciated method? Maybe just a note in our board code
Experience has shown that it simply does not work to change the im- plementation or to provide new interfaces and simpy hope that all board maintainers will adapt these changes in a resonable time. Others staring with a new port will are guaranteed to pick up such old files as model, and continue to use the old stuff.
The only way to get consistent code is to enforce the change for all boards.
In your case it took nearly 3 months until you even noticed that something was changed.
that a certain method is depreciated would be more appropriate? Is there another reason I am missing?
Guess how many board maintainers will change working code just because there is another way to do it?
Sorry, but in my experience this doesn't work.
I apologize for breaking your board.
Now for your patch:
/* This code does not work, and needs to be fixed at a laterdate */
Do you really want me to check this in? I feel you should spend some more time and fix the code first and submit a new patch then.
Best regards,
Wolfgang Denk