[U-Boot-Users] New and updated patches sent to U-Boot maintainer

[Keith J Outwater]

> Dear Keith,
> 
> in message 
<OF30CE6C3A.DAA104F1-ON072571E6.008079A0-072571E6.00823609 at 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