[Gta04-owner] [PATCH 00/11] DTS updates for GTA04

Dr. H. Nikolaus Schaller hns at goldelico.com
Tue Jan 6 20:25:02 CET 2015


Hi,

Am 06.01.2015 um 19:58 schrieb NeilBrown <neilb at suse.de>:

> On Mon, 5 Jan 2015 23:24:46 +0100 Belisko Marek <marek.belisko at gmail.com>
> wrote:
> 
>> Hi Neil,
>> 
>> On Mon, Jan 5, 2015 at 8:59 PM, NeilBrown <neilb at suse.de> wrote:
>>> Hi Marek,
>>> the following 11 patches fix some problems and add some enhancements
>>> in the GTA04 DTS file.  They all relate to features that are already
>>> supported by the upstream kernel. The patches apply to Linus'
>>> v3.19-rc2 kernel.
>> Thanks for patches. I did check patches compared to existing in gta04
>> kernel tree and some of patches are already present
>> in that tree. Can you please ad to those patches: Signed-off-by: H.
>> Nikolaus Schaller <hns at goldelico.com>
>> All of them was done by Nikolaus.
> 
> No.  Those patches that I sent you were written by me.
> It is very likely that Nikolaus has written identical patches.

Obviously. Which shows that we waste efforts if you spend time on solving
things that I already have solved quite some time ago (and most likely
vice versa). This is why I personally would prefer that we pile up everything
on a shared gta04-kernel repository. And if bugs are fixed, we do the upstream
process.

The side effect would be that there is a kernel that is *ahead* of linus/master.

And in theory we should be able to get both: 100% feature complete and bug
free and ahead of linus. Then we only have to convince Linus to take all our
changes - and can finish the kernel development (except for testing for regressions).

>  If you would
> rather send the patches that he wrote upstream I am perfectly happy with that.

I would be happy if we both are named as authors - if we came to the same
solution (even if independently) because then it must be the right one.

>> 
>> Here is a list:
>> Patch | git rev in gta04 kernel | Author
>> 001 - 8d932e94 - H. Nikolaus Schaller
>> 002 - 061f0323 - H. Nikolaus Schaller
>> 005 - 061f0323 - H. Nikolaus Schaller
>> 006 - c94de56f - H. Nikolaus Schaller
>> 007 - d26794c0 - H. Nikolaus Schaller
>> 008 - 58f0a3e8 - H. Nikolaus Schaller
> 
> This list very effectively shows what I don't like about this tree.
> 
> Only one of those patches is really ready to go upstream.

It is not intended that these patches are “ready to go upstream”.

>  That is the last
> one (58f0a3e8).  It was written in March 2014 and still hasn't been sent
> upstream.

Maybe it was simply missed because we had focussed on something else.

> All all the rest (except d26794c0 which seems to be in the list by mistake)
> are a mixture of different things with incomplete justification.  So they are
> not ready of sending upstream.

But the tree defines what we want to see long-term in linus/master.

We simply have a different development model. The general problem is that
during development one tries this and that and fixes things here or there. And
sometimes has to revert. Or develops in “steps”.

But Linus wants to see so called “clean” patches (which is ok) which hide much
of this upfront work. In the end he will have an identical tree - just different
history how to get there.

So there must necessarily be some “cleaning stage”.

Now, there are two approaches:
1. the individual developer hides all these deviations and wrong paths from the public and ends up in a set of “clean” patches only
2. all changes are applied and documented to a public tree and at the end of the pipeline there is a “cleaning” process to get well tested and good things upstream

Both approaches are shown to work.

The problem I have with 1. is that it does not allow collaboration (at least I have
no idea how it could work).

Only a single developer can work with this approach because he is either done
(no work left over for anyone else) or intermediate steps are not available (nobody
knows where work is going on). And there is no way for the single developer to
say “hello, I need help here or there” because then the risk is that someone answers
with non-clean patches.

What I wonder is if you are able to write clean patches right from the beginning (i.e.
doing the cleaning process before typing) or if you also reformat/split/change/clean
up patches from time to time.

BR,
Nikolaus


> 
> Thanks,
> NeilBrown
> 
> 
>> 
>> Thanks
>>> 
>>> There is one small change between these and the combined patch I sent
>>> earlier.  In that patch I had made a change to twl4030.dtsi.
>>> Changing that file in this series wasn't really appropriate and on
>>> further investigation it seemed best to configure twl-power entirely
>>> with omap3-gta04.dtsi, much like what omap3-beagle-xm.dts and other
>>> do.
>>> 
>>> If you are able to forward these upstream I would really appreciate
>>> it.
>>> 
>>> Thanks,
>>> NeilBrown
>>> 
>>> 
>>> ---
>>> 
>>> NeilBrown (11):
>>>      ARM: dts: omap3-gta04: Fix backup-battery charging in devicetree file.
>>>      ARM: dts: omap3-gta04: fix 'audio' support in dts file.
>>>      ARM: dts: omap3-gta04: enable power-off for wifi card.
>>>      ARM: dts: omap3-gta04: add support for sdio interrupts.
>>>      ARM: dts: omap3-gta04: enable twl4030 vibra support.
>>>      ARM: dts: omap3-gta04: add gyroscope
>>>      ARM: dts: omap3-gta04: Fix a GPIO line.
>>>      ARM: dts: omap3-gta04: enable power-off using twl4030.
>>>      ARM: dts: omap3-gta04: only power DSS when necessary.
>>>      ARM: dts: omap3-gta04: uart4 is not connected, so mark it "disabled"
>>>      ARM: dts: omap3-gta04: Disable keypad
>>> 
>>> 
>>> arch/arm/boot/dts/omap3-gta04.dtsi |   78 +++++++++++++++++++++++++++++-------
>>> 1 file changed, 63 insertions(+), 15 deletions(-)
>>> 
>>> --
>>> Signature
>>> 
>> 
>> BR,
>> 
>> marek
>> 
> 



More information about the Gta04-owner mailing list