Dear Keith,

in message

OF30CE6C3A.DAA104F1-ON072571E6.008079A0-072571E6.00823609@mck.us.ray.com you wrote:

...

...

Can you please update your patches using a current code base? I get

a

...

...

lot of rejects when applying your patches.

OK. I was hoping I could get away with not having to do that. Sorry!

Ummm... no. If new submitted patches throw too many and too big rejects I will not spend the effort for you.

It's not that I was expecting you to do the work - it's that I had not expected U-Boot to have "evolved" so much since the last time I updated my local tree. I just need to figure out how to use cogito/git more effectively.

...

...

• Clean up the Coding style (trailing white space in 65 files, C++ comments, indentation not by tabs, trailing empty lines, etc.)

I'll run all the sources through GNU indent.

I'm not sure if this is a good idea.

Please see the "Coding Standards" section in the README.

I have seen them and will adhere to them. Here are the indent switches I use: indent -kr -i8 -ts8 -sob -l80 -ss -bs -psl -cdb -sc -lc80 -fca -v Perhaps we could all agree on a the correct indent options to use so that all submissions conform to the standard?

...

Perhaps the current git head does not have these statements in the Xilinx code in ./board/xilinx/xilinx_enet, for example. I'll check tonight. My source base does have them, though, but my code is a

little

...

old.

Please don't refer to the existing xilinx code as an example - it contains enough of problems.

This I am beginning to realize. It is a double edged sword. On one hand use of this code saves time and energy and reduces development risk. On the other hand the code is big and verbose.

...

...

• Please clean up the function headers and comments. Something like

this:

...

...

I tend to agree, but this is the Xilinx provided driver code. I can

take

...

not credit for it's quality :)

But you submit it for U-Boot. The Linux kernel folks have a long tradition of rejecting poor code, and I am tempted to do the same here.

...

BTW, Some of this code is already in U-Boot

Yes, and I am angry with myself that I didn't reject this when it was submitted. It just escaped my attention.

...

My plan was to put it into a common location after which anyone else

using

...

the code in ./boards/xilinx could switch over to the code in ./drivers

Is this the only change, i. e. no improvement in the quality of the code?

So far, yes, although I guess I'm going to have to start improving it :)

...

The idea was to use the driver source code as-is to avoid having to re-invent the wheel. I would expect that as more Xilinx FPGA based boards are added, the percentage use of the Xilinx driver code would increase.

We just discussed this in another case: I don;t want to have dead code in U-Boot, and I guess that 90% of what you're adding here is just code bloat and things that are not needed or referenced by any of the supported boards. But given the poor quality of the code it's time-consuming to check even this.

I'd really appreciate if you could spend some efforts on cleaning this up and bringing it into a more readable / usable form.

OK. How about my other patches? I have about 11 submitted.

Regards, Keith