[Gta04-owner] GTA04-Kernel 3.17.0

[NeilBrown]

On Sun, 26 Oct 2014 13:22:03 +0100 "Dr. H. Nikolaus Schaller"
<hns at goldelico.com> wrote:

> > I've also added a proof-of-concept for a new approach to managing devices
> > attached via UART.
> 
> Please can you describe how it works in detail? We are currently discussing on
> LKML (and you are on CC:) to upstream the “old” approach and it would be nice
> for that discussion if we knew it.

There a comments in the commit, and the code is fairly simple, however:

 Any uart in devicetree can have a child device listed.
e.g.
&uart1 {
	bluetooth {
		compatible = "tty,regulator";
		vdd-supply = <&vaux4>;
	};
};

That device is probed as a platform-device.  The resulting device is attached
to the driver-model tree as a child of the tty device (itself a child of the
uart device).

The probe function of this platform-device can call new function
tty_set_slave():

	err = tty_set_slave(pdev->dev.parent, &pdev->dev, &tty_reg_ops);

"tty_reg_ops" is a struct of function pointers so that the tty can tell the
driver when interesting things happen.
Currently there is just an 'open' and a 'close'.  I expect to add "receive"
or similar so a driver for the GPS can know when data is being received.

As I said, this is just a proof-of-concept.  I'll very likely change the
exact behaviour and possibly even the names of 'open' and 'close' before I am
happy with it.  At the very least I need to add some locking.

Then we can see if Mark Rutland and others can be made to be happy.



> While I really appreciate what you have done, I am not happy at all how we
> coordinate work in our small community.

I guess we see things quite differently.  In terms of kernel development, I
don't see us as a small community, but as a small part of a big community -
the kernel community.  Or maybe as a small part of several communities:
devicetree, omap, mmc, tty, .....

> 
> In fact: we do not coordinate it at all (or don’t use the existing tools).

*The* way to co-ordinate in kernel development is to get code upstream.
I very much appreciate the work you and Marek have been doing in getting
things upstream - it helps me a lot.  Thanks.

> 
> Even where a bug tracker exists: http://projects.goldelico.com/p/gta04-kernel/issues
> and is just waiting to be used (someone can be registered to be the “owner” of the
> issue and everyone else knows that there is already someone working on it).

I hate bug-trackers - sorry.
They do have a place in commercial settings - they can be used to track
things that no-one wants to work on.  And then be used as leverage to force
people to do particular work.

But in the GTA04 world, I just work on what I want to work on, and I don't
need an issue tracker to remind me.  If someone has a problem I expect them
to post about it to the list (which they do).  If it interests me, I'll look
at it.  If not, not.


> So you expect us to go through your patches and find out what is duplicate and
> what is really new.

I don't expect you do to anything.  I'm just letting you know as a courtesy.
As I said, I plan to push these things upstream.
For the omap3-gta04.dts patches I would certainly negotiate with Marek.
For the little bug-fixes in a couple of input drivers I would just send them
to the input maintainer.  The MMC patches to the MMC maintainer.  etc.
I'll Cc all the patches to this list if you like (in fact I will now unless
someone asks me not to).

> 
> Our process is only coming from the other side of the street. We are not building
> up something ion top of mainline, but tracking mainline and reducing the differences.
> 
> The question I have is: what is bad with this approach?
> 
> Currently we have approx, 131 different upstreamable files between gta04-3.18.rc1
> and linus/v3.18-rc1 (some diffs are not even GTA04 related but for the Pyra handheld).
> If you want I can generate the list.

I can generate lists too.  Your tree (As of commit d10f2ada5789e5e4 on Oct
9th) has 911 non-merge commits that are separate from mainline.
Some of them are nice clean patches, some of them a reverts of other patches,
some are temporary hacks, some are (as you say) for devices that I don't care
about.

My goal has always been to have mainline Linux running on my phone.  I
haven't got there yet, but the number of commits of difference is getting
smaller. Using your kernel would (in my mind) be a step in the wrong
direction.

It is probably just a different development model.  You seem to just
accumulate stuff in your tree, occasionally send things upstream, then
resolve conflicts when changes appear in upstream.

I don't like to work like that.  I like to keep a well defined set of patches
on-top of mainline.  I go back and revise the patches when I find problems
(stgit is good for that).  So when I send a patch upstream, it is exactly a
patch that I have been testing against as-pure-as-possible mainline code.

> 
> And the goal and process of the GTA04 project is to get this number up by fixing the
> remaining bugs and getting it down by upstreaming things that work.
> 
> So I am quite reluctant to go through your tree and look for useful things we could
> integrate. And might have to invest a lot of time until they can be merged without conflicts.
> 
> Rather I invite you to provide patches against our 3.18-rc1 (or rc2 on Monday) that include
> your experiences and knowledge (which both is very welcome).

I'll be sending patches upstream.  With luck they'll get in 3.19-rc1, and you
will get them when you pull that in.

When the patches for powering on/off bluetooth and gps are ready, I'll
certainly include you when I post them for discussion.

> 
> Sorry if I am a little upset and apologise if I did understand something wrong.

No problem.  We do certainly have different perspectives on some things, but
I'm sure we can still work together productively.

NeilBrown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: OpenPGP digital signature
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20141027/338b537b/attachment-0001.asc>