[Gta04-owner] GTA04-Kernel 3.17.0
neilb at suse.de
Sun Oct 26 22:50:14 CET 2014
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.
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
The probe function of this platform-device can call new function
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
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 828 bytes
Desc: OpenPGP digital signature
More information about the Gta04-owner