[U-Boot-Users] How to patch u-boot?

[Haavard Skinnemoen]

On Mon, 21 Jan 2008 20:36:13 +0100
Harald Welte <laforge at openmoko.org> wrote:

> 2) I have submitted two rounds of our patches (with about one year in
>    between those two instances), and I have the feeling that the
>    interest in even commenting to those patches was quite low.  This is
>    not very encouraging for further submissions.

[...]

> 2) Some of the changes, notably the sd/mmc driver for s3c24xx was
>    rejected by the u-boot list, since it just does what everyone else
>    does: no shared host controller code, just copy+paste the bits that
>    the other sd/mmc controllers do.

Hey, is that the thanks I get for actually commenting at your mmc
driver? I don't recall rejecting anything, nor do I have the power to
do so.

>    While I understand that there is a
>    need for a shared sd/mmc code, putting the burden of creating such
>    code on us is just too much.  With this kind of requirement you will
>    unlikely to see anyone merge another sd/mmc controller driver into
>    u-boot, since everyone evades creating the generic/common code. This
>    is not pure laziness, but inexperience with the code and lack of
>    access to all the different hardware

I did suggest that you move the MMC protocol definitions to a common
header file. That's not a huge task, but you could have said "no, I
don't want to do that right now. Maybe later." and it would have been
perfectly fine. Instead, you said "will do so in the next version of
the patch." But no next version of the patch ever showed up, despite
quite a few comments from others as well.

Of course, it would certainly be nice with a common mmc host controller
layer, but I certainly agree that placing that burden on you is
unreasonable. But IMO _suggesting_ that you do it is completely
different.

Btw, I find the "lack of hardware" argument a bit disturbing. Doing
some cleanups really shouldn't require anyone to have access to all the
affected hardware -- IMO much of the responsibility for testing that
nothing breaks on real hardware lies on the custodians and other users
that actually have access to the affected boards. But a few cross
toolchains are definitely required to verify that it actually compiles
on a handful of configurations before submitting.

Haavard