HTC Dream aka. t-mobile g1 support

Pavel Machek

unread,

Jun 10, 2009, 6:40:13 AM6/10/09

to

Hi!

Is there patch for Dream support for 2.6.30 somewhere? The best I
could find is linux-msm tree, which is ... quite a big diff against
2.6.24:

Is all of it neccessary for dream or are parts such as board-halibut
parts of some other support? Do I have wrong tree entirely?
Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Ian Molton

unread,

Jun 10, 2009, 7:20:14 AM6/10/09

to

Pavel Machek wrote:
> Hi!
>
> Is there patch for Dream support for 2.6.30 somewhere? The best I
> could find is linux-msm tree, which is ... quite a big diff against
> 2.6.24

You could look at JesusFreaks blog if you havent already.

Keep me updated on this as I have a Dream and will definately be wanting
to 'roll my own' (debian userspace on SD, chroot android)

-Ian

Pavel Machek

unread,

Jun 10, 2009, 7:50:13 AM6/10/09

to

On Wed 2009-06-10 12:13:10, Ian Molton wrote:
> Pavel Machek wrote:
>> Hi!
>>
>> Is there patch for Dream support for 2.6.30 somewhere? The best I
>> could find is linux-msm tree, which is ... quite a big diff against
>> 2.6.24
>
> You could look at JesusFreaks blog if you havent already.

I know about his blog, but can't see any patches. Should I look
harder? (Any urls?)

> Keep me updated on this as I have a Dream and will definately be wanting
> to 'roll my own' (debian userspace on SD, chroot android)

If you get that to work, do tell me. I'd like to run debian on root,
too.

Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Ian Molton

unread,

Jun 10, 2009, 8:10:16 AM6/10/09

to

Pavel Machek wrote:
> On Wed 2009-06-10 12:13:10, Ian Molton wrote:

> I know about his blog, but can't see any patches. Should I look
> harder? (Any urls?)

I think I have the 2.6.27 (IIRC) sources from JF. I got them from his
blog - they were buried inside an archive.

JF is on #android on freenode (or was recently)

Imm running a JF kernel on mine right now - seems to have full sensor
support. Everything works.

>> Keep me updated on this as I have a Dream and will definately be wanting
>> to 'roll my own' (debian userspace on SD, chroot android)
>
> If you get that to work, do tell me. I'd like to run debian on root,
> too.

Will do :)

Brian Swetland

unread,

Jun 10, 2009, 1:50:09 PM6/10/09

to

On Wed, Jun 10, 2009 at 3:31 AM, Pavel Machek<pa...@ucw.cz> wrote:
> Hi!
>
> Is there patch for Dream support for 2.6.30 somewhere? The best I
> could find is linux-msm tree, which is ... quite a big diff against
> 2.6.24:

Our current working tree (for the donut branch) is against 2.6.29:
http://android.git.kernel.org/?p=kernel/msm.git;a=shortlog;h=refs/heads/android-msm-2.6.29

The cupcake/1.5 system update (latest production kernel) was against 2.6.27:
http://android.git.kernel.org/?p=kernel/msm.git;a=shortlog;h=refs/heads/android-msm-2.6.27

> Is all of it neccessary for dream or are parts such as board-halibut
> parts of some other support? Do I have wrong tree entirely?

Most of it is necessary. board-halibut is a qualcomm reference
design. board-sapphire is HTC Magic. board-trout is G1/ADP1.
arch/arm/config/msm_defconfig is how we configure the kernel we ship
which supports all three.

The ti wifi driver is enormous and in its own repository:
http://android.git.kernel.org/?p=platform/system/wlan/ti.git;a=shortlog;h=refs/heads/cupcake

Brian

Bob Copeland

unread,

Jun 10, 2009, 4:00:21 PM6/10/09

to

On Wed, Jun 10, 2009 at 1:43 PM, Brian Swetland<swet...@google.com> wrote:
> The ti wifi driver is enormous and in its own repository:
> http://android.git.kernel.org/?p=platform/system/wlan/ti.git;a=shortlog;h=refs/heads/cupcake

For wifi, there's a patch to add sdio support to the soon-to-be-upstream
wl12xx. It works, but that's about all for now. Patch is at
http://bobcopeland.com/android_wifi.html, though the linux-wireless list
is the official location for any future discussion / updates.

--
Bob Copeland %% www.bobcopeland.com

Russell King - ARM Linux

unread,

Jun 10, 2009, 4:00:22 PM6/10/09

to

On Wed, Jun 10, 2009 at 12:31:31PM +0200, Pavel Machek wrote:
> Is there patch for Dream support for 2.6.30 somewhere? The best I
> could find is linux-msm tree, which is ... quite a big diff against
> 2.6.24:

In short not as far as I know, and I'm very disappointed with the state
of affairs with google.

Basically, the situation surrounding msm can be described as severely
wanting - bear in mind that it's been over a year since we last heard
anything from the msm guys as far as code submissions go.

Personally, I think we should delete the entire codeset which was
submitted into mainline - it's next to useless and all the time that
folk sit on their hands not maintaining it, it's just not worth having
it anywhere near mainline.

Gary Thomas

unread,

Jun 10, 2009, 4:10:13 PM6/10/09

to

Brian Swetland wrote:
> On Wed, Jun 10, 2009 at 3:31 AM, Pavel Machek<pa...@ucw.cz> wrote:
>> Hi!
>>
>> Is there patch for Dream support for 2.6.30 somewhere? The best I
>> could find is linux-msm tree, which is ... quite a big diff against
>> 2.6.24:
>
> Our current working tree (for the donut branch) is against 2.6.29:
> http://android.git.kernel.org/?p=kernel/msm.git;a=shortlog;h=refs/heads/android-msm-2.6.29

How do I turn this URL into a 'repo init' command? The boilerplate on
the web view just doesn't explain it to me.

Thanks

--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------

Brian Swetland

unread,

Jun 10, 2009, 4:20:12 PM6/10/09

to

On Wed, Jun 10, 2009 at 12:58 PM, Gary Thomas<ga...@mlbassoc.com> wrote:
> Brian Swetland wrote:
>> On Wed, Jun 10, 2009 at 3:31 AM, Pavel Machek<pa...@ucw.cz> wrote:
>>> Hi!
>>>
>>> Is there patch for Dream support for 2.6.30 somewhere? The best I
>>> could find is linux-msm tree, which is ... quite a big diff against
>>> 2.6.24:
>>
>> Our current working tree (for the donut branch) is against 2.6.29:
>> http://android.git.kernel.org/?p=kernel/msm.git;a=shortlog;h=refs/heads/android-msm-2.6.29
>
> How do I turn this URL into a 'repo init' command? The boilerplate on
> the web view just doesn't explain it to me.

Not sure on the repo details, but if you want to check the kernel code
out using git, you can:

% git clone git://android.git.kernel.org/kernel/msm.git
% cd msm
% git checkout -b android-msm-2.6.29 origin/android-msm-2.6.29

Brian

Brian Swetland

unread,

Jun 10, 2009, 4:30:12 PM6/10/09

to

On Wed, Jun 10, 2009 at 12:48 PM, Russell King - ARM
Linux<li...@arm.linux.org.uk> wrote:
> On Wed, Jun 10, 2009 at 12:31:31PM +0200, Pavel Machek wrote:
>> Is there patch for Dream support for 2.6.30 somewhere? The best I
>> could find is linux-msm tree, which is ... quite a big diff against
>> 2.6.24:
>
> In short not as far as I know, and I'm very disappointed with the state
> of affairs with google.
>
> Basically, the situation surrounding msm can be described as severely
> wanting - bear in mind that it's been over a year since we last heard
> anything from the msm guys as far as code submissions go.
>
> Personally, I think we should delete the entire codeset which was
> submitted into mainline - it's next to useless and all the time that
> folk sit on their hands not maintaining it, it's just not worth having
> it anywhere near mainline.

I'd love to find an effective way to get more of the msm support
cleaned up (as necessary) and into the mainline. We're bringing our
work forward and rebasing to keep tracking the latest released kernel,
and working on getting core bits we need that other stuff depends on
in -- look at the thread on linux-pm where the wakelock/suspendblocker
framework has been reviewed, revised, resent repeatedly, etc.

The msm7k unfortunately requires a lot of infrastructure to work given
that the baseband (a black box to us) controls much of the world.
Last time around when I tried submitting some of the core ipc support
to talk to it on the lakml, there seemed to be uncertainty about who
even would review that.

We've definitely dropped the ball as far as interacting with folks on
the lakml on this, but I do wonder if there's a better option than
"delete it all."

We have full support for MSM7201A, including fully functional power
management, working on a number of commercially shipping devices that
we'd absolutely love to get into mainline. Rebasing and bringing this
stuff forward all the time is a lot of work and certainly not the
optimal way to do it. Getting it in a couple pieces at a time is slow
going, but it seemed to cause frustration with just the small number
of things we were looking for review/approval for...

Brian

Brian Swetland

unread,

Jun 10, 2009, 5:10:14 PM6/10/09

to

On Wed, Jun 10, 2009 at 1:47 PM, Stefan
Schmidt<ste...@datenfreihafen.org> wrote:
> Hello.

>
> On Wed, 2009-06-10 at 13:24, Brian Swetland wrote:
>>
>> We have full support for MSM7201A, including fully functional power
>> management, working on a number of commercially shipping devices that
>> we'd absolutely love to get into mainline.
>

> A bit offtopic here. (subject change). Is it expected that the android kernel
> team will also work on systems that use the MSM6K modems with different SoC's? I
> have soem systems here that use an msm6281 on a dual port ram chip with non msm
> SoC's. I wonder how difficult it would be to adaept the existing msm smd driver
> to such a setup.

We only have documentation, support, and permission to do work on 7k
and 8k family devices at this point. I don't know anything about the
6k family, and how similar (or not) the shared memory interface would
be, so unfortunately I can't provide much help there.

Daniel Walker

unread,

Jun 10, 2009, 5:10:15 PM6/10/09

to

On Wed, 2009-06-10 at 13:24 -0700, Brian Swetland wrote:
> On Wed, Jun 10, 2009 at 12:48 PM, Russell King - ARM
> Linux<li...@arm.linux.org.uk> wrote:
> > On Wed, Jun 10, 2009 at 12:31:31PM +0200, Pavel Machek wrote:
> >> Is there patch for Dream support for 2.6.30 somewhere? The best I
> >> could find is linux-msm tree, which is ... quite a big diff against
> >> 2.6.24:
> >
> > In short not as far as I know, and I'm very disappointed with the state
> > of affairs with google.
> >
> > Basically, the situation surrounding msm can be described as severely
> > wanting - bear in mind that it's been over a year since we last heard
> > anything from the msm guys as far as code submissions go.
> >
> > Personally, I think we should delete the entire codeset which was
> > submitted into mainline - it's next to useless and all the time that
> > folk sit on their hands not maintaining it, it's just not worth having
> > it anywhere near mainline.
>
> I'd love to find an effective way to get more of the msm support
> cleaned up (as necessary) and into the mainline. We're bringing our
> work forward and rebasing to keep tracking the latest released kernel,
> and working on getting core bits we need that other stuff depends on
> in -- look at the thread on linux-pm where the wakelock/suspendblocker
> framework has been reviewed, revised, resent repeatedly, etc.

I assume you guys would accept community submitted clean up patches
right? Is there someone maintaining the MSM changes, you maybe?

> The msm7k unfortunately requires a lot of infrastructure to work given
> that the baseband (a black box to us) controls much of the world.
> Last time around when I tried submitting some of the core ipc support
> to talk to it on the lakml, there seemed to be uncertainty about who
> even would review that.

Typically you send stuff to LKML (or other mailing list) for review,
it's not like only one person would be reviewing the code.

Daniel

Marek Vasut

unread,

Jun 10, 2009, 5:30:14 PM6/10/09

to

On Wednesday 10 of June 2009 23:08:36 Brian Swetland wrote:
> On Wed, Jun 10, 2009 at 1:47 PM, Stefan
>
> Schmidt<ste...@datenfreihafen.org> wrote:
> > Hello.
> >
> > On Wed, 2009-06-10 at 13:24, Brian Swetland wrote:
> >> We have full support for MSM7201A, including fully functional power
> >> management, working on a number of commercially shipping devices that
> >> we'd absolutely love to get into mainline.
> >
> > A bit offtopic here. (subject change). Is it expected that the android
> > kernel team will also work on systems that use the MSM6K modems with
> > different SoC's? I have soem systems here that use an msm6281 on a dual
> > port ram chip with non msm SoC's. I wonder how difficult it would be to
> > adaept the existing msm smd driver to such a setup.
>
> We only have documentation, support, and permission to do work on 7k
> and 8k family devices at this point. I don't know anything about the
> 6k family, and how similar (or not) the shared memory interface would
> be, so unfortunately I can't provide much help there.

Palm Pre apparently uses MSM68xx as a baseband chip, otherwise is omap3 based.
The device is out, selling, but I haven't seen any kernel patches from them
yet. I hope they release them in a few weeks (even though they should have
been out already).
>
> Brian
>
> -------------------------------------------------------------------
> List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
> FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
> Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php

Stefan Schmidt

unread,

Jun 10, 2009, 5:30:09 PM6/10/09

to

Hello.

On Wed, 2009-06-10 at 14:08, Brian Swetland wrote:
> On Wed, Jun 10, 2009 at 1:47 PM, Stefan
> Schmidt<ste...@datenfreihafen.org> wrote:
> >
> > On Wed, 2009-06-10 at 13:24, Brian Swetland wrote:
> >>
> >> We have full support for MSM7201A, including fully functional power
> >> management, working on a number of commercially shipping devices that
> >> we'd absolutely love to get into mainline.
> >
> > A bit offtopic here. (subject change). Is it expected that the android kernel
> > team will also work on systems that use the MSM6K modems with different SoC's? I
> > have soem systems here that use an msm6281 on a dual port ram chip with non msm
> > SoC's. I wonder how difficult it would be to adaept the existing msm smd driver
> > to such a setup.
>
> We only have documentation, support, and permission to do work on 7k
> and 8k family devices at this point. I don't know anything about the
> 6k family, and how similar (or not) the shared memory interface would
> be, so unfortunately I can't provide much help there.

To bad. Thanks for the answer.

regards
Stefan Schmidt

Pavel Machek

unread,

Jun 10, 2009, 5:40:13 PM6/10/09

to

On Wed 2009-06-10 23:28:39, Marek Vasut wrote:
> On Wednesday 10 of June 2009 23:08:36 Brian Swetland wrote:
> > On Wed, Jun 10, 2009 at 1:47 PM, Stefan
> >
> > Schmidt<ste...@datenfreihafen.org> wrote:
> > > Hello.
> > >
> > > On Wed, 2009-06-10 at 13:24, Brian Swetland wrote:
> > >> We have full support for MSM7201A, including fully functional power
> > >> management, working on a number of commercially shipping devices that
> > >> we'd absolutely love to get into mainline.
> > >
> > > A bit offtopic here. (subject change). Is it expected that the android
> > > kernel team will also work on systems that use the MSM6K modems with
> > > different SoC's? I have soem systems here that use an msm6281 on a dual
> > > port ram chip with non msm SoC's. I wonder how difficult it would be to
> > > adaept the existing msm smd driver to such a setup.
> >
> > We only have documentation, support, and permission to do work on 7k
> > and 8k family devices at this point. I don't know anything about the
> > 6k family, and how similar (or not) the shared memory interface would
> > be, so unfortunately I can't provide much help there.
>
> Palm Pre apparently uses MSM68xx as a baseband chip, otherwise is omap3 based.
> The device is out, selling, but I haven't seen any kernel patches from them
> yet. I hope they release them in a few weeks (even though they should have
> been out already).

If you can get your hands on Palm Pre, it should come with
GPL-required sources or offer for source code... if it does not, talk
to Harald Welte (gpl-violations.org)....

(If you _do_ get your hands on Palm Pre, tell me, I'd like to see the
device :-), can show you some androids/openmokos :-).
Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Stefan Schmidt

unread,

Jun 10, 2009, 5:40:14 PM6/10/09

to

Hello.

On Wed, 2009-06-10 at 13:24, Brian Swetland wrote:
>

> We have full support for MSM7201A, including fully functional power
> management, working on a number of commercially shipping devices that
> we'd absolutely love to get into mainline.

A bit offtopic here. (subject change). Is it expected that the android kernel

team will also work on systems that use the MSM6K modems with different SoC's? I
have soem systems here that use an msm6281 on a dual port ram chip with non msm
SoC's. I wonder how difficult it would be to adaept the existing msm smd driver
to such a setup.

regards
Stefan Schmidt

Pavel Machek

unread,

Jun 10, 2009, 5:40:16 PM6/10/09

to

Hi!

> > On Wed, Jun 10, 2009 at 12:31:31PM +0200, Pavel Machek wrote:
> >> Is there patch for Dream support for 2.6.30 somewhere? The best I
> >> could find is linux-msm tree, which is ... quite a big diff against
> >> 2.6.24:
> >
> > In short not as far as I know, and I'm very disappointed with the state
> > of affairs with google.
> >
> > Basically, the situation surrounding msm can be described as severely
> > wanting - bear in mind that it's been over a year since we last heard
> > anything from the msm guys as far as code submissions go.
> >
> > Personally, I think we should delete the entire codeset which was
> > submitted into mainline - it's next to useless and all the time that
> > folk sit on their hands not maintaining it, it's just not worth having
> > it anywhere near mainline.
>
> I'd love to find an effective way to get more of the msm support
> cleaned up (as necessary) and into the mainline. We're bringing our
> work forward and rebasing to keep tracking the latest released kernel,
> and working on getting core bits we need that other stuff depends on
> in -- look at the thread on linux-pm where the wakelock/suspendblocker
> framework has been reviewed, revised, resent repeatedly, etc.

I guess wakelocks should be removed from first version of drivers for merge.

> The msm7k unfortunately requires a lot of infrastructure to work given
> that the baseband (a black box to us) controls much of the world.
> Last time around when I tried submitting some of the core ipc support
> to talk to it on the lakml, there seemed to be uncertainty about who
> even would review that.

Try again, then :-). [Merging to drivers/staging is _very_ easy, and
even that is good first step.]

Actually, mailing patches so that people do not have to do git pull +
diff is very good zeroth step :-).

> We have full support for MSM7201A, including fully functional power
> management, working on a number of commercially shipping devices that
> we'd absolutely love to get into mainline. Rebasing and bringing this
> stuff forward all the time is a lot of work and certainly not the
> optimal way to do it. Getting it in a couple pieces at a time is slow
> going, but it seemed to cause frustration with just the small number
> of things we were looking for review/approval for...

I have some experience with patch merging, lets see if I can
help... It would be good to merge it upstream before the hw is
obsolete...

Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Brian Swetland

unread,

Jun 10, 2009, 6:00:16 PM6/10/09

to

On Wed, Jun 10, 2009 at 2:37 PM, Pavel Machek<pa...@ucw.cz> wrote:
>> I'd love to find an effective way to get more of the msm support
>> cleaned up (as necessary) and into the mainline. We're bringing our
>> work forward and rebasing to keep tracking the latest released kernel,
>> and working on getting core bits we need that other stuff depends on
>> in -- look at the thread on linux-pm where the wakelock/suspendblocker
>> framework has been reviewed, revised, resent repeatedly, etc.
>
> I guess wakelocks should be removed from first version of drivers for merge.

It'd be nice to get that sorted out first, but it does seem like it's
going to take a while to get there, so yeah, guess we'd have to go a
step at a time.

>> The msm7k unfortunately requires a lot of infrastructure to work given
>> that the baseband (a black box to us) controls much of the world.
>> Last time around when I tried submitting some of the core ipc support
>> to talk to it on the lakml, there seemed to be uncertainty about who
>> even would review that.
>
> Try again, then :-). [Merging to drivers/staging is _very_ easy, and
> even that is good first step.]

Is there something equivalent for arch code? The bulk of our msm7k
support is under arch/arm/mach-msm/... though if there are sane places
to split out bigger chunks like the qdsp5/qdsp6 support, etc, we're
open to suggestion.

I'm not sure the smd (shared memory driver / virtual serial channels)
that everything else depends on makes sense outside of mach-msm, given
it's all very specific to the baseband and firmware that runs on it.
Basically there's a stack:

smsm -- "shared memory state machine" (used for power collapse coordination)
smd -- "shared memory driver" (virtual serial channels, 8k bidirectional fifos)
rpcrouter/oncrpc -- rpc transport layer used for audio, audio routing, etc

These are linux implementations of protocols the baseband speaks.

Other stuff then stacks on smd (rmnet -- virtual ethernet, at control
channels, etc) and oncrpc (dsp control, rtc, gps, some media control).

> Actually, mailing patches so that people do not have to do git pull +
> diff is very good zeroth step :-).

We've tried to do both in the past -- setup a patchset that's pullable
for those who want to pull and get send-email 'em out to the list.

>> We have full support for MSM7201A, including fully functional power
>> management, working on a number of commercially shipping devices that
>> we'd absolutely love to get into mainline. Rebasing and bringing this
>> stuff forward all the time is a lot of work and certainly not the
>> optimal way to do it. Getting it in a couple pieces at a time is slow
>> going, but it seemed to cause frustration with just the small number
>> of things we were looking for review/approval for...
>
> I have some experience with patch merging, lets see if I can
> help... It would be good to merge it upstream before the hw is
> obsolete...

Conveniently a lot of the peripherals are used in later generation 7k
and 8k SoCs, so this stuff should actually be useful for new hardware
for a while. 7201A based products are still shipping new this year
(HTC Magic, for example).

Help is certainly appreciated.

I think we're probably due for another round of flattening and
cleaning up against 2.6.30 or 31 and seeing what survives review and
what we can do to get the mainline msm code closer to fully
functional.

Brian

Stefan Schmidt

unread,

Jun 10, 2009, 6:20:06 PM6/10/09

to

Hello.

They have the licence inside and offer source on request on the letter. I wrote
them a mail some hours ago and they state that all source will be on
http://opensource.palm.com/ within two weeks.

regards
Stefan Schmidt

Pavel Machek

unread,

Jun 10, 2009, 6:30:17 PM6/10/09

to

Hi!

Ok, Harald asked for Palm Pre source code in blog entry, so it is fair
to cc him :-).

> > > Palm Pre apparently uses MSM68xx as a baseband chip, otherwise is omap3 based.
> > > The device is out, selling, but I haven't seen any kernel patches from them
> > > yet. I hope they release them in a few weeks (even though they should have
> > > been out already).
> >
> > If you can get your hands on Palm Pre, it should come with
> > GPL-required sources or offer for source code... if it does not, talk
> > to Harald Welte (gpl-violations.org)....
>
> They have the licence inside and offer source on request on the letter. I wrote
> them a mail some hours ago and they state that all source will be on
> http://opensource.palm.com/ within two weeks.

Ugh, nice approach to GPL :-(.

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Valdis.K...@vt.edu

unread,

Jun 11, 2009, 12:10:09 AM6/11/09

to

On Thu, 11 Jun 2009 00:19:40 +0200, Pavel Machek said:
> > They have the licence inside and offer source on request on the letter. I wrote
> > them a mail some hours ago and they state that all source will be on
> > http://opensource.palm.com/ within two weeks.
>
> Ugh, nice approach to GPL :-(.

On the other hand, it's far from the worst GPL abuse we've seen. It sounds
like they're at least *trying* to DTRT, and they're at least complying with the
letter of the license, and *mostly* the spirit...

David Miller

unread,

Jun 11, 2009, 3:10:18 AM6/11/09

to

From: Russell King - ARM Linux <li...@arm.linux.org.uk>
Date: Wed, 10 Jun 2009 20:48:52 +0100

> In short not as far as I know, and I'm very disappointed with the state
> of affairs with google.

And of course, this whole android situation has absolutely nothing to
do with how much of a pain in that ass you are to deal with as ARM
maintainer.

Absolutely nothing, right?

:-(

Russell King - ARM Linux

unread,

Jun 11, 2009, 3:20:12 AM6/11/09

to

On Thu, Jun 11, 2009 at 12:02:19AM -0700, David Miller wrote:
> From: Russell King - ARM Linux <li...@arm.linux.org.uk>
> Date: Wed, 10 Jun 2009 20:48:52 +0100
>
> > In short not as far as I know, and I'm very disappointed with the state
> > of affairs with google.
>
> And of course, this whole android situation has absolutely nothing to
> do with how much of a pain in that ass you are to deal with as ARM
> maintainer.
>
> Absolutely nothing, right?

It's a shame you don't talk to Andrew Morton more - he'll tell you
exactly what the issue is here.

You've already demonstrated that you're a total idiot over the device
tree stuff, and now you're just continuing that approach. Now stop
poking for idiotic nose in where its only function is to make trouble
and crawl back under whatever rock you came from.

Kalle Valo

unread,

Jun 11, 2009, 3:30:09 AM6/11/09

to

Bob Copeland <m...@bobcopeland.com> writes:

> On Wed, Jun 10, 2009 at 1:43 PM, Brian Swetland<swet...@google.com> wrote:
>> The ti wifi driver is enormous and in its own repository:
>> http://android.git.kernel.org/?p=platform/system/wlan/ti.git;a=shortlog;h=refs/heads/cupcake
>
> For wifi, there's a patch to add sdio support to the soon-to-be-upstream
> wl12xx. It works, but that's about all for now. Patch is at
> http://bobcopeland.com/android_wifi.html, though the linux-wireless list
> is the official location for any future discussion / updates.

wl12xx is in net-next-2.6 tree currently and it should go to 2.6.31:

http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=tree;f=drivers/net/wireless/wl12xx;h=06a34fea0223c161c7b21a6bc226b5882dcd39c8;hb=HEAD

--
Kalle Valo

Pavel Machek

unread,

Jun 11, 2009, 3:40:12 AM6/11/09

to

On Thu 2009-06-11 00:02:19, David Miller wrote:
> From: Russell King - ARM Linux <li...@arm.linux.org.uk>
> Date: Wed, 10 Jun 2009 20:48:52 +0100
>
> > In short not as far as I know, and I'm very disappointed with the state
> > of affairs with google.
>
> And of course, this whole android situation has absolutely nothing to
> do with how much of a pain in that ass you are to deal with as ARM
> maintainer.

Well, linux-arm-devel being subscribers-only and patch management
system that needs special headers certainly does not help here :-(.
Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Pavel Machek

unread,

Jun 11, 2009, 4:00:11 AM6/11/09

to

"Far from the worst" is exact. Yes, it could be worse. Question is how
they'll respond to those letters. I suspect they will just wait 14
days and then send CD...

Pavel Machek

unread,

Jun 11, 2009, 4:20:28 AM6/11/09

to

On Wed 2009-06-10 10:43:53, Brian Swetland wrote:
> On Wed, Jun 10, 2009 at 3:31 AM, Pavel Machek<pa...@ucw.cz> wrote:
> > Hi!
> >
> > Is there patch for Dream support for 2.6.30 somewhere? The best I
> > could find is linux-msm tree, which is ... quite a big diff against
> > 2.6.24:
>
> Our current working tree (for the donut branch) is against 2.6.29:
> http://android.git.kernel.org/?p=kernel/msm.git;a=shortlog;h=refs/heads/android-msm-2.6.29
>

Strange, I attempted downloading this overnight (285MB!) by

git clone --template=/data/l/clean-cg/ git://android.git.kernel.org/kernel/msm.git

....and got 2.6.27 sources. Aha,

git checkout -b android-msm-2.6.29 origin/android-msm-2.6.29

Helped. Thanks!

> The cupcake/1.5 system update (latest production kernel) was against 2.6.27:
> http://android.git.kernel.org/?p=kernel/msm.git;a=shortlog;h=refs/heads/android-msm-2.6.27
>
> > Is all of it neccessary for dream or are parts such as board-halibut
> > parts of some other support? Do I have wrong tree entirely?
>
> Most of it is necessary. board-halibut is a qualcomm reference
> design. board-sapphire is HTC Magic. board-trout is G1/ADP1.
> arch/arm/config/msm_defconfig is how we configure the kernel we ship
> which supports all three.

Ok, could we get the boards renamed? g1 is known as dream, having
trout+dream+g1+adp1 names for same piece of hardware is unnice.

Hmm, perhaps this would be useful to apply?

---

Inform people about board codenames, and add how-to download latest
sources.

Signed-off-by: Pavel Machek <pa...@ucw.cz>

diff --git a/Documentation/android.txt b/Documentation/android.txt
index 72a62af..a2ad1dc 100644
--- a/Documentation/android.txt
+++ b/Documentation/android.txt
@@ -14,6 +14,13 @@ CONTENTS:
1.3 Recommended enabled config options
2. Contact

+0. Getting sources:
+-----------------
+
+git clone --template=/path/to/linux-git/for/speedup/ git://android.git.kernel.org/kernel/msm.git
+git checkout -b android-msm-2.6.29 origin/android-msm-2.6.29
+
+(280MB+ download!)

1. Android
==========
@@ -26,6 +33,8 @@ To see a working defconfig look at msm_defconfig or goldfish_defconfig
which can be found at http://android.git.kernel.org in kernel/common.git
and kernel/msm.git

+msm_defconfig should work on qualcomm reference design, HTC Magic and G1/ADP1.
+

1.1 Required enabled config options
-----------------------------------
@@ -113,6 +122,14 @@ LOG_BUF_SHIFT=17
SERIAL_CORE
SERIAL_CORE_CONSOLE

+1.4 Board code names
+
+board-halibut is a qualcomm reference design. board-sapphire is HTC
+Magic. board-trout is G1/ADP1.
+
+
+
+

2. Contact
==========

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Pavel Machek

unread,

Jun 11, 2009, 4:30:16 AM6/11/09

to

On Wed 2009-06-10 14:55:52, Brian Swetland wrote:
> On Wed, Jun 10, 2009 at 2:37 PM, Pavel Machek<pa...@ucw.cz> wrote:
> >> I'd love to find an effective way to get more of the msm support
> >> cleaned up (as necessary) and into the mainline. �We're bringing our
> >> work forward and rebasing to keep tracking the latest released kernel,
> >> and working on getting core bits we need that other stuff depends on
> >> in -- look at the thread on linux-pm where the wakelock/suspendblocker
> >> framework has been reviewed, revised, resent repeatedly, etc.
> >
> > I guess wakelocks should be removed from first version of drivers for merge.
>
> It'd be nice to get that sorted out first, but it does seem like it's
> going to take a while to get there, so yeah, guess we'd have to go a
> step at a time.

Merging drivers is (/should be) easy. Merging core features take a
while.

> >> The msm7k unfortunately requires a lot of infrastructure to work given
> >> that the baseband (a black box to us) controls much of the world.
> >> Last time around when I tried submitting some of the core ipc support
> >> to talk to it on the lakml, there seemed to be uncertainty about who
> >> even would review that.
> >
> > Try again, then :-). [Merging to drivers/staging is _very_ easy, and
> > even that is good first step.]
>
> Is there something equivalent for arch code? The bulk of our msm7k
> support is under arch/arm/mach-msm/... though if there are sane places
> to split out bigger chunks like the qdsp5/qdsp6 support, etc, we're
> open to suggestion.

drivers/staging already contains stuff such a filesystems. Putting
arch-specific drivers there should be okay.

> I'm not sure the smd (shared memory driver / virtual serial channels)
> that everything else depends on makes sense outside of mach-msm, given
> it's all very specific to the baseband and firmware that runs on it.

Well, it is still a driver for your baseband chip, right?

...drivers/staging is _not_ final place for your code. When the code
is good enough, it should move. But it is place where stuff like TI
wifi driver would be acceptable.

> Basically there's a stack:
>
> smsm -- "shared memory state machine" (used for power collapse coordination)
> smd -- "shared memory driver" (virtual serial channels, 8k bidirectional fifos)
> rpcrouter/oncrpc -- rpc transport layer used for audio, audio routing, etc
>
> These are linux implementations of protocols the baseband speaks.
>
> Other stuff then stacks on smd (rmnet -- virtual ethernet, at control
> channels, etc) and oncrpc (dsp control, rtc, gps, some media control).

Is it all neccessary for boot? Getting it booting with display should
be the first goal... GPS/RTC/... can come later.

> > Actually, mailing patches so that people do not have to do git pull +
> > diff is very good zeroth step :-).
>
> We've tried to do both in the past -- setup a patchset that's pullable
> for those who want to pull and get send-email 'em out to the list.

Yeah, you need to repeat it like each two weeks to get attention.

> >> We have full support for MSM7201A, including fully functional power
> >> management, working on a number of commercially shipping devices that
> >> we'd absolutely love to get into mainline. �Rebasing and bringing this
> >> stuff forward all the time is a lot of work and certainly not the
> >> optimal way to do it. �Getting it in a couple pieces at a time is slow
> >> going, but it seemed to cause frustration with just the small number
> >> of things we were looking for review/approval for...
> >
> > I have some experience with patch merging, lets see if I can
> > help... It would be good to merge it upstream before the hw is
> > obsolete...
>
> Conveniently a lot of the peripherals are used in later generation 7k
> and 8k SoCs, so this stuff should actually be useful for new hardware
> for a while. 7201A based products are still shipping new this year
> (HTC Magic, for example).

Good.

> I think we're probably due for another round of flattening and
> cleaning up against 2.6.30 or 31 and seeing what survives review and
> what we can do to get the mainline msm code closer to fully
> functional.

Yes, please.

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Brian Swetland

unread,

Jun 11, 2009, 4:30:16 AM6/11/09

to

On Thu, Jun 11, 2009 at 1:10 AM, Pavel Machek<pa...@ucw.cz> wrote:
> On Wed 2009-06-10 10:43:53, Brian Swetland wrote:
>>
>> Our current working tree (for the donut branch) is against 2.6.29:
>> http://android.git.kernel.org/?p=kernel/msm.git;a=shortlog;h=refs/heads/android-msm-2.6.29
>
> Strange, I attempted downloading this overnight (285MB!)

Hm. I think if you add this as a remote to an existing repository
containing the kernel (these trees are based on v2.6.27 and v2.6.29
respectively) it should only pull the deltas (which aren't that
enormous).

>> The cupcake/1.5 system update (latest production kernel) was against 2.6.27:
>> http://android.git.kernel.org/?p=kernel/msm.git;a=shortlog;h=refs/heads/android-msm-2.6.27
>>
>> > Is all of it neccessary for dream or are parts such as board-halibut
>> > parts of some other support? Do I have wrong tree entirely?
>>
>> Most of it is necessary. board-halibut is a qualcomm reference
>> design. board-sapphire is HTC Magic. board-trout is G1/ADP1.
>> arch/arm/config/msm_defconfig is how we configure the kernel we ship
>> which supports all three.
>
> Ok, could we get the boards renamed? g1 is known as dream, having
> trout+dream+g1+adp1 names for same piece of hardware is unnice.

It's hard to have a single name since carriers tend to use different
names in different markets. We often start work on kernel support
long before a product is announced, so we've been using the fish names
to allow us to register board names with the ARM machine registry
early on and not use bogus internal-only machine IDs.

> Hmm, perhaps this would be useful to apply?

I didn't realize we had an android.txt already under Documentation.
Expanding it with more details sounds good to me.

halibut - Qualcomm SURF 7201A
trout - HTC Dream, Android ADP1, T-Mobile G1
sapphire - HTC Sapphire, HTC Magic

There may be some other names used by other carriers or in other regions.

Brian

Brian Swetland

unread,

Jun 11, 2009, 4:50:14 AM6/11/09

to

On Thu, Jun 11, 2009 at 1:25 AM, Pavel Machek<pa...@ucw.cz> wrote:
> On Wed 2009-06-10 14:55:52, Brian Swetland wrote:
>> I'm not sure the smd (shared memory driver / virtual serial channels)
>> that everything else depends on makes sense outside of mach-msm, given
>> it's all very specific to the baseband and firmware that runs on it.
>
> Well, it is still a driver for your baseband chip, right?

Yes -- what I meant is more "does it belong under arch/arm/mach-msm/"
(given that it's very specific to that architecture and unlikely to
ever be useful elsewhere) or "does it belong somewhere else" (because
it's a pretty big pile of code compared to other stuff like
gpio/interrupt/etc stuff that tends to live under arch/arm/mach-*/).

> ...drivers/staging is _not_ final place for your code. When the code
> is good enough, it should move. But it is place where stuff like TI
> wifi driver would be acceptable.

Interesting -- reading up more on staging now. I know that Greg KH
has been pulling some of the "generic" android drivers into staging
(Thanks, Greg!), but hadn't really looked at the rationale behind
staging in general.

Sounds like packing up the serial, sdio, nand, framebuffer, etc
drivers for submission into staging might make sense. We can do the
obvious stuff like make sure they're checkpatch clean and reasonably
tidy first.

In order to actually have the peripherals work, though, we'd need to
add to board-*.c, devices.c, etc so that the platform devices are
defined so the platform drivers (which almost all of these are) are
actually probed.

>> Basically there's a stack:
>>
>> smsm -- "shared memory state machine" (used for power collapse coordination)
>> smd -- "shared memory driver" (virtual serial channels, 8k bidirectional fifos)
>> rpcrouter/oncrpc -- rpc transport layer used for audio, audio routing, etc
>>
>> These are linux implementations of protocols the baseband speaks.
>>
>> Other stuff then stacks on smd (rmnet -- virtual ethernet, at control
>> channels, etc) and oncrpc (dsp control, rtc, gps, some media control).
>
> Is it all neccessary for boot? Getting it booting with display should
> be the first goal... GPS/RTC/... can come later.

The lowest layer IPC (proc_comm) is used for clock/power control and
is already in mainline, and that gets the clk_* framework functional
and allows most of the peripheral drivers to work, thankfully. Things
like the serial driver, framebuffer, sdio, nand controller, etc all
should be happy without additional core architecture support.

Thanks,

Brian

Mark Brown

unread,

Jun 11, 2009, 5:40:06 AM6/11/09

to

On Wed, Jun 10, 2009 at 01:24:42PM -0700, Brian Swetland wrote:

> The msm7k unfortunately requires a lot of infrastructure to work given
> that the baseband (a black box to us) controls much of the world.
> Last time around when I tried submitting some of the core ipc support
> to talk to it on the lakml, there seemed to be uncertainty about who
> even would review that.

Perhaps you might find common cause with the OMAP guys? They've got
similar issues to resolve with things like the DSPs on OMAPs.

> We have full support for MSM7201A, including fully functional power
> management, working on a number of commercially shipping devices that
> we'd absolutely love to get into mainline. Rebasing and bringing this
> stuff forward all the time is a lot of work and certainly not the
> optimal way to do it. Getting it in a couple pieces at a time is slow
> going, but it seemed to cause frustration with just the small number
> of things we were looking for review/approval for...

Is there more driver stuff which you could get upstream? I'd have
expected that it should be easier to get drivers in than the more
invasive changes like wakelocks.

Mark Brown

unread,

Jun 11, 2009, 6:10:14 AM6/11/09

to

On Thu, Jun 11, 2009 at 09:37:40AM +0200, Pavel Machek wrote:

> Well, linux-arm-devel being subscribers-only and patch management
> system that needs special headers certainly does not help here :-(.

For the more actively developed subarchitectures code actually flows in
via git these days - the subarchitecture maintainers send pull requests.

Russell King - ARM Linux

unread,

Jun 11, 2009, 6:40:06 AM6/11/09

to

On Thu, Jun 11, 2009 at 09:37:40AM +0200, Pavel Machek wrote:

> On Thu 2009-06-11 00:02:19, David Miller wrote:
> > From: Russell King - ARM Linux <li...@arm.linux.org.uk>
> > Date: Wed, 10 Jun 2009 20:48:52 +0100
> >
> > > In short not as far as I know, and I'm very disappointed with the state
> > > of affairs with google.
> >
> > And of course, this whole android situation has absolutely nothing to
> > do with how much of a pain in that ass you are to deal with as ARM
> > maintainer.
>
> Well, linux-arm-devel being subscribers-only and patch management
> system that needs special headers certainly does not help here :-(.

That's got nothing to do with it. You're just using that as an excuse
to bash me with.

The real problem with android is that their efforts to mainline the code
are very sparse - I seem to recollect that there were two attempts about
a year or more apart, the first of which was relatively painless and the
second which was more problematical (partly caused because they'd left
it soo long since the last submission.)

Around the time of their second submission, someone who used to be more
active in the ARM community started making accusations against Google
for "throwing their code over the wall and disappearing" and "claiming
that their code is on kernel.org now". They went on to say (and I'm
quoting) "i don't think they give a shit about what you or i have to
say about it".

Having dealt with Brian's kernel submissions and provided feedback on
them, I took issue with those comments because that wasn't how I (or even
akpm) saw the situation. The result of that was the person making those
accusations fell out with me.

However, as a result of the complete lack of effort to update patches
as a result of feedback coupled with my lack of bandwidth to review
complex code implementing things like cross-bridge APIs (eg, ARM <->
DSP communications channels), Brian basically gave up trying to get
stuff into mainline.

Now, ask yourself this question: why should I have to be the one to
review things like ARM <-> DSP communication channel code? Hint: I
don't want to because I know nothing about the subject. Where should
I send these people to get such code reviewed? No idea, there seems
to be no one _anywhere_ who would seem to be interested in it.

Andrew tried to resolve this review problem by getting some co-operation
between various members of the ARM community - so that two or three
people with large code bases would do mutual reviews and gain from
each others efforts. The result of that was... precisely nothing. No
interest in lifting a finger to help someone else.

So, to go pointing blame at various things you don't like is not only
naieve but down right idiotic and stupid. I suggest you stop your
personal (and as demonstrated in other emails to me over your Zaurus
problems) persistent rmk bashing agenda and wake up to reality.

And now think whether you are part of the problem - when you load me up
with your Zaurus problems, a platform which I know precisely zilch about,
and I have to waste time fighting tooth and nail to get you to talk to
people who might be able to help you.

David Miller

unread,

Jun 11, 2009, 6:50:15 AM6/11/09

to

From: David Miller <da...@davemloft.net>
Date: Thu, 11 Jun 2009 03:44:21 -0700 (PDT)

> It's not like this was stated on a public mailing list or on some
> public web site. It was IRC for heaven's sake.

And BTW something you said in the same IRC arena shortly
thereafterwards:

<rmk> in hind sight, xxxxxxx was effectively right when he said on here a while ago
<rmk> 22:34 <xxxxxx> jejb: google also just pretty much threw their ARM code over the wall and disappeared

There you are quoting this person, the same way you are quoting him
here and demeaning him in this very email thread.

And yet there you are agreeing with him.

You're such a hypocrite Russell.

David Miller

unread,

Jun 11, 2009, 6:50:15 AM6/11/09

to

From: Russell King - ARM Linux <li...@arm.linux.org.uk>

Date: Thu, 11 Jun 2009 11:34:57 +0100

> Around the time of their second submission, someone who used to be more
> active in the ARM community started making accusations against Google
> for "throwing their code over the wall and disappearing" and "claiming
> that their code is on kernel.org now". They went on to say (and I'm
> quoting) "i don't think they give a shit about what you or i have to
> say about it".
>
> Having dealt with Brian's kernel submissions and provided feedback on
> them, I took issue with those comments because that wasn't how I (or even
> akpm) saw the situation. The result of that was the person making those
> accusations fell out with me.

You should give full disclosure and say where and in what context
those statements were made.

They were made in IRC and people say all kinds of random things on IRC
when they're in a foul mood, are piss drunk, or simply got up on the
wrong side of the bed that day.

It's not like this was stated on a public mailing list or on some
public web site. It was IRC for heaven's sake.

And then then YOU took it to private email with various people.

And it's a certainty that you're volatile way of interacting with
people does nothing to help in situations like that. I can just
imagine how you handled discussing things with that person at that
moment in time, and how things likely escalated because of your
attitude problem.

Russell King - ARM Linux

unread,

Jun 11, 2009, 7:00:19 AM6/11/09

to

On Thu, Jun 11, 2009 at 03:44:21AM -0700, David Miller wrote:
> From: Russell King - ARM Linux <li...@arm.linux.org.uk>
> Date: Thu, 11 Jun 2009 11:34:57 +0100
> > Around the time of their second submission, someone who used to be more
> > active in the ARM community started making accusations against Google
> > for "throwing their code over the wall and disappearing" and "claiming
> > that their code is on kernel.org now". They went on to say (and I'm
> > quoting) "i don't think they give a shit about what you or i have to
> > say about it".
> >
> > Having dealt with Brian's kernel submissions and provided feedback on
> > them, I took issue with those comments because that wasn't how I (or even
> > akpm) saw the situation. The result of that was the person making those
> > accusations fell out with me.
>
> You should give full disclosure and say where and in what context
> those statements were made.

Yes, the bits I paraphrased above in quotes were from IRC, and I have
no problem saying so. What I don't want to do is to quote precisely
what was said or provide the identity of the person making those
statements on a public mailing list (certainly not without permission.)

> And then then YOU took it to private email with various people.

No, you are just totally wrong there. It was ALREADY in private
*constructive* email between Andrew and myself at the time the comments
were made, with Andrew trying to find a solution to allow review of the
code to take place.

Now, you can carry on blaming me for the android situation in your own
world of lies, or you can wake up to reality and find out some reliable
facts from someone like Andrew Morton before continuing to assign blame
and malace. Which will it be?

David Miller

unread,

Jun 11, 2009, 7:10:17 AM6/11/09

to

From: Russell King - ARM Linux <li...@arm.linux.org.uk>

Date: Thu, 11 Jun 2009 11:55:51 +0100

> Now, you can carry on blaming me for the android situation in your own
> world of lies, or you can wake up to reality and find out some reliable
> facts from someone like Andrew Morton before continuing to assign blame
> and malace. Which will it be?

Oh Russell, I had an extensive discussion with Andrew when this
whole situation happened.

And I was pissed as hell because this person was one of my best
networking contributors so I knew that you're judgments and assesments
of him were not representative of him as a person nor as a developer.

And therefore I told Andrew how much I disagreed with what you were
doing and how the way you generally handle things is generally
upsetting to me.

He definitely did not flat out dismiss the things I was saying
nor my opinions in this matter.

Russell King - ARM Linux

unread,

Jun 11, 2009, 7:10:19 AM6/11/09

to

On Thu, Jun 11, 2009 at 03:47:32AM -0700, David Miller wrote:
> From: David Miller <da...@davemloft.net>
> Date: Thu, 11 Jun 2009 03:44:21 -0700 (PDT)
>
> > It's not like this was stated on a public mailing list or on some
> > public web site. It was IRC for heaven's sake.
>
> And BTW something you said in the same IRC arena shortly
> thereafterwards:
>
> <rmk> in hind sight, xxxxxxx was effectively right when he said on here a while ago
> <rmk> 22:34 <xxxxxx> jejb: google also just pretty much threw their ARM code over the wall and disappeared
>
> There you are quoting this person, the same way you are quoting him
> here and demeaning him in this very email thread.
>
> And yet there you are agreeing with him.
>
> You're such a hypocrite Russell.

I'm sorry, that's the precise same channel and network which those
comments were first made by the person who made them.

And now read precisely what I said rather than twisting it to your own
agenda.

Particularly the bit where I wrote "in hind sight". There's lots of
things everyone would do differently if they knew what happens in the
future. Unfortunately, we live in a causal universe where we can't
predict with certaintly what will happen.

At the time the comments were first made, Brian _was_ making an effort,
and the comments seemed to be unfounded accusations.

Brian Swetland

unread,

Jun 11, 2009, 7:20:07 AM6/11/09

to

On Thu, Jun 11, 2009 at 3:34 AM, Russell King - ARM
Linux<li...@arm.linux.org.uk> wrote:
>
> However, as a result of the complete lack of effort to update patches
> as a result of feedback coupled with my lack of bandwidth to review
> complex code implementing things like cross-bridge APIs (eg, ARM <->
> DSP communications channels), Brian basically gave up trying to get
> stuff into mainline.

Well, "gave up" feels a little final to me. We still would like to
get stuff upstream. I will admit to finding the process discouraging
at times, but a larger part of it is just finding the time to sit
down, tidy up the current state of our world against the tip-of-tree
on mainline, and push out another round of patches. I'm hoping to
find some larger windows of time to devote to this later this year.

Since we also have to maintain a stable, shippable tree for products
going out the door and to provide baseline support for the platform,
we end up having to maintain multiple trees -- it's obviously not
realistic to expect that we're going to get 30000-50000 lines of new
code reviewed quickly, but we do need all the functionality there to
actually support shipping devices. When time gets tight (more often
than I like), the towards-mainline stuff gets backburnered.
Obviously, we suffer for this in that we end up having more to rebase
every time we move forward, so it would be to our benefit to get
better at pushing this stuff upstream and reduce the delta between
mainline and our tree.

> Now, ask yourself this question: why should I have to be the one to
> review things like ARM <-> DSP communication channel code? Hint: I
> don't want to because I know nothing about the subject. Where should
> I send these people to get such code reviewed? No idea, there seems
> to be no one _anywhere_ who would seem to be interested in it.

The drivers/staging system looks like it has some potential to help
here. Greg has been scooping our generic code into there recently,
and I know Arve's seen patches for binder issues go by, etc. It feels
(if I'm understanding the intent) a bit more like the model I'm more
used to (get a relatively clean piece of code that is functional
checked in, and then refine it).

> Andrew tried to resolve this review problem by getting some co-operation
> between various members of the ARM community - so that two or three
> people with large code bases would do mutual reviews and gain from
> each others efforts. The result of that was... precisely nothing. No
> interest in lifting a finger to help someone else.

I think Andrew's idea is a good one, but we just haven't had the time
to try to sort this out. I'll have to see what we can do here.
Recently, we've been involved in omap3 work as well and have been
interacting more with folks in the omap kernel community as a result.

Brian

Pavel Machek

unread,

Jun 11, 2009, 7:20:10 AM6/11/09

to

On Thu 2009-06-11 11:34:57, Russell King - ARM Linux wrote:
> On Thu, Jun 11, 2009 at 09:37:40AM +0200, Pavel Machek wrote:
> > On Thu 2009-06-11 00:02:19, David Miller wrote:
> > > From: Russell King - ARM Linux <li...@arm.linux.org.uk>
> > > Date: Wed, 10 Jun 2009 20:48:52 +0100
> > >
> > > > In short not as far as I know, and I'm very disappointed with the state
> > > > of affairs with google.
> > >
> > > And of course, this whole android situation has absolutely nothing to
> > > do with how much of a pain in that ass you are to deal with as ARM
> > > maintainer.
> >
> > Well, linux-arm-devel being subscribers-only and patch management
> > system that needs special headers certainly does not help here :-(.
>
> That's got nothing to do with it. You're just using that as an excuse
> to bash me with.

I believe it has something to do with it. linux-arm is effectively a
walled garden, away from lkml. Getting patches to linux-arm is more
interesting exercise than getting them to linux-i386. For trivial
patches, it matters.

> However, as a result of the complete lack of effort to update patches
> as a result of feedback coupled with my lack of bandwidth to review
> complex code implementing things like cross-bridge APIs (eg, ARM <->
> DSP communications channels), Brian basically gave up trying to get
> stuff into mainline.

> Now, ask yourself this question: why should I have to be the one to
> review things like ARM <-> DSP communication channel code? Hint: I
> don't want to because I know nothing about the subject. Where should
> I send these people to get such code reviewed? No idea, there seems
> to be no one _anywhere_ who would seem to be interested in it.

I guess the patches should just go to lkml. If

1) they don't mess up common code

2) google is willing to maintain them

3) they look mostly okay to interested parties on lkml

... I guess they should just go in. Maybe they should go into
drivers/dsp or drivers/mfd or something if you are not comfortable
having them in arch/arm.

They can certianly go to drivers/staging...

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Pavel Machek

unread,

Jun 11, 2009, 7:20:13 AM6/11/09

to

On Thu 2009-06-11 01:27:43, Brian Swetland wrote:
> On Thu, Jun 11, 2009 at 1:10 AM, Pavel Machek<pa...@ucw.cz> wrote:
> > On Wed 2009-06-10 10:43:53, Brian Swetland wrote:
> >>
> >> Our current working tree (for the donut branch) is against 2.6.29:
> >> http://android.git.kernel.org/?p=kernel/msm.git;a=shortlog;h=refs/heads/android-msm-2.6.29
> >
> > Strange, I attempted downloading this overnight (285MB!)
>
> Hm. I think if you add this as a remote to an existing repository
> containing the kernel (these trees are based on v2.6.27 and v2.6.29
> respectively) it should only pull the deltas (which aren't that
> enormous).

I tried pulling deltas (by specifying --template=...), that was
285MB. Maybe I screwed something up.

Anyway, now I have a tree, and yes it compiles. (After some
"interesting" questions; perhaps defconfig should be updated?)

Unfortunately, upon fastboot boot uImage, it hangs with black screen
and backlight on. I _think_ I got config right, most "interesting"
question was

AMSS modem firmware version
1. 6.2.10 (MSM_AMSS_VERSION_6210)
2. 6.2.20 (MSM_AMSS_VERSION_6220)
> 3. 6.2.20 + New ADSP (MSM_AMSS_VERSION_6225)
4. 6.3.50 (MSM_AMSS_VERSION_6350) (NEW)

...and I just selected "3" being default. No help available :-(. I
have cupcake installed, and I believe I installed radio update
required for cupcake. Can someone help? (And write Kconfig help text?
:-).

> > Ok, could we get the boards renamed? g1 is known as dream, having
> > trout+dream+g1+adp1 names for same piece of hardware is unnice.
>
> It's hard to have a single name since carriers tend to use different
> names in different markets. We often start work on kernel support
> long before a product is announced, so we've been using the fish names
> to allow us to register board names with the ARM machine registry
> early on and not use bogus internal-only machine IDs.

I know naming stuff is hard. But dream/g1/adp1 are both recognized by
outside people. I don't think "trout" has similar level of
recognition.

Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

David Miller

unread,

Jun 11, 2009, 7:20:12 AM6/11/09

to

From: Russell King - ARM Linux <li...@arm.linux.org.uk>

Date: Thu, 11 Jun 2009 12:05:39 +0100

> On Thu, Jun 11, 2009 at 03:47:32AM -0700, David Miller wrote:
>> <rmk> in hind sight, xxxxxxx was effectively right when he said on here a while ago
>> <rmk> 22:34 <xxxxxx> jejb: google also just pretty much threw their ARM code over the wall and disappeared

...

> I'm sorry, that's the precise same channel and network which those
> comments were first made by the person who made them.
>
> And now read precisely what I said rather than twisting it to your own
> agenda.

You're the one who can't read.

The words "was" and "when" were used, which indicate a point in time
(not only for the statement but also when it applies).

You didn't say "his comments back then actually do apply now".
But it may be convenient for you to portray things this way.

Russell, if you only knew how people speak of you in private....

Russell King - ARM Linux

unread,

Jun 11, 2009, 7:20:14 AM6/11/09

to

On Thu, Jun 11, 2009 at 04:12:39AM -0700, Brian Swetland wrote:
> I think Andrew's idea is a good one, but we just haven't had the time
> to try to sort this out. I'll have to see what we can do here.
> Recently, we've been involved in omap3 work as well and have been
> interacting more with folks in the omap kernel community as a result.

Brian,

Can you clear up this thread, which seems to be descending into absurdness.

David Miller seems to be of the opinion that I was rude or otherwise
insulting to you. Was this the case?

Was the only problem you had interacting with me to do with the time it
takes to receive feedback on patches which you'd submitted and getting
them merged? I believe that caused you to question several times whether
you were doing things in the right way.

Thanks.

Brian Swetland

unread,

Jun 11, 2009, 7:30:23 AM6/11/09

to

On Thu, Jun 11, 2009 at 4:09 AM, Pavel Machek<pa...@ucw.cz> wrote:
>
> Anyway, now I have a tree, and yes it compiles. (After some
> "interesting" questions; perhaps defconfig should be updated?)
>
> Unfortunately, upon fastboot boot uImage, it hangs with black screen
> and backlight on.

You'll need to fastboot boot arch/arm/boot/zImage ramdisk.img

Extracting the ramdisk.img from the boot.img in the boot partition on
an existing device is a pain. If you happen to have a cupcake
userspace built from source that ramdisk.img should be suitable. If
not, I'll try to dig up a suitable ramdisk image tomorrow -- it's just
init, init.rc, and adb, but it is necessary to boot.

> I _think_ I got config right, most "interesting"
> question was
>
> AMSS modem firmware version
> 1. 6.2.10 (MSM_AMSS_VERSION_6210)
> 2. 6.2.20 (MSM_AMSS_VERSION_6220)
>> 3. 6.2.20 + New ADSP (MSM_AMSS_VERSION_6225)
> 4. 6.3.50 (MSM_AMSS_VERSION_6350) (NEW)
>
> ...and I just selected "3" being default. No help available :-(. I
> have cupcake installed, and I believe I installed radio update
> required for cupcake. Can someone help? (And write Kconfig help text?
> :-).

This is correct. The shipping dream/sapphire devices are using AMSS
6.2.20+patches, which is option 3.

I'll look over the Kconfig text and see what we can do here. The
problem is that the baseband firmware (AMSS) changes some of the rpc
interfaces incompatibly between versions, and different generations of
the same hardware could be shipping with somewhat different baseband
firmware. 6210 and 6220 are completely obsolete (never used in
anything in production) and we should drop them to avoid confusion.

>> > Ok, could we get the boards renamed? g1 is known as dream, having
>> > trout+dream+g1+adp1 names for same piece of hardware is unnice.
>>
>> It's hard to have a single name since carriers tend to use different
>> names in different markets. We often start work on kernel support
>> long before a product is announced, so we've been using the fish names
>> to allow us to register board names with the ARM machine registry
>> early on and not use bogus internal-only machine IDs.
>
> I know naming stuff is hard. But dream/g1/adp1 are both recognized by
> outside people. I don't think "trout" has similar level of
> recognition.

Would better descriptions in Kconfig help here? That's a lot easier
and less disruptive than renaming the machine types (and the userspace
android world, for good or ill uses the machine name to identify the
hardware version for some hardware specific configuration stuff at
runtime).

Brian

David Miller

unread,

Jun 11, 2009, 7:30:25 AM6/11/09

to

From: Russell King - ARM Linux <li...@arm.linux.org.uk>

Date: Thu, 11 Jun 2009 12:18:22 +0100

> Can you clear up this thread, which seems to be descending into absurdness.
>
> David Miller seems to be of the opinion that I was rude or otherwise
> insulting to you. Was this the case?

Getting one selected person's opinion is not indicative of your
general behavior towards people and how you tend to handle ARM
maintainence specifically.

Alan Cox

unread,

Jun 11, 2009, 7:40:15 AM6/11/09

to

> Now, ask yourself this question: why should I have to be the one to
> review things like ARM <-> DSP communication channel code? Hint: I

Because you claim to be ARM maintainer and you force all the ARM stuff to
go via you ?

We have the -next tree these days so if you cut ARM back to common core
shared ARM code and all the platform people had their own maintainer (at
least those who are competent to do so which is a fair share of them)
then you could resolve any collisions in -next. There will probably be a
few explosions on the way because code developed under such a tight
control model tends to have poor separation in places nobody thought
about but they'll fix pretty fast.

If you don't want to be reviewing some of the stuff then restructure
things so that they don't go through you and you are not the gatekeeper
for them.

Alan

Pavel Machek

unread,

Jun 11, 2009, 7:50:12 AM6/11/09

to

On Thu 2009-06-11 04:24:03, Brian Swetland wrote:
> On Thu, Jun 11, 2009 at 4:09 AM, Pavel Machek<pa...@ucw.cz> wrote:
> >
> > Anyway, now I have a tree, and yes it compiles. (After some
> > "interesting" questions; perhaps defconfig should be updated?)
> >
> > Unfortunately, upon fastboot boot uImage, it hangs with black screen
> > and backlight on.
>
> You'll need to fastboot boot arch/arm/boot/zImage ramdisk.img

Aha, fastboot implies that ramdisk is optional.. apparently it is not.

> Extracting the ramdisk.img from the boot.img in the boot partition on
> an existing device is a pain. If you happen to have a cupcake
> userspace built from source that ramdisk.img should be suitable. If
> not, I'll try to dig up a suitable ramdisk image tomorrow -- it's just
> init, init.rc, and adb, but it is necessary to boot.

I tried using ramdisk.img from sdk:

root@amd:/data/l/android# ./fastboot boot
/data/l/linux-msm/arch/arm/boot/uImage
/data/l/android/sdk/platforms/android-1.5/images/ramdisk.img
creating boot image...
creating boot image - 1884160 bytes
downloading 'boot.img'... OKAY
booting... OKAY
root@amd:/data/l/android# ls -al
/data/l/android/sdk/platforms/android-1.5/images/ramdisk.img
-rw-rw-rw- 1 pavel pavel 145785 May 15 03:13
/data/l/android/sdk/platforms/android-1.5/images/ramdisk.img

...no luck :-(.

> > I _think_ I got config right, most "interesting"
> > question was
> >
> > AMSS modem firmware version
> > �1. 6.2.10 (MSM_AMSS_VERSION_6210)
> > �2. 6.2.20 (MSM_AMSS_VERSION_6220)
> >> 3. 6.2.20 + New ADSP (MSM_AMSS_VERSION_6225)
> > �4. 6.3.50 (MSM_AMSS_VERSION_6350) (NEW)
> >
> > ...and I just selected "3" being default. No help available :-(. I
> > have cupcake installed, and I believe I installed radio update
> > required for cupcake. Can someone help? (And write Kconfig help text?
> > :-).
>
> This is correct. The shipping dream/sapphire devices are using AMSS
> 6.2.20+patches, which is option 3.
>
> I'll look over the Kconfig text and see what we can do here. The
> problem is that the baseband firmware (AMSS) changes some of the rpc
> interfaces incompatibly between versions, and different generations of
> the same hardware could be shipping with somewhat different baseband
> firmware. 6210 and 6220 are completely obsolete (never used in
> anything in production) and we should drop them to avoid confusion.

Or at least add (obsolete) to kconfig help or something.

> >> > Ok, could we get the boards renamed? g1 is known as dream, having
> >> > trout+dream+g1+adp1 names for same piece of hardware is unnice.
> >>
> >> It's hard to have a single name since carriers tend to use different
> >> names in different markets. �We often start work on kernel support
> >> long before a product is announced, so we've been using the fish names
> >> to allow us to register board names with the ARM machine registry
> >> early on and not use bogus internal-only machine IDs.
> >
> > I know naming stuff is hard. But dream/g1/adp1 are both recognized by
> > outside people. I don't think "trout" has similar level of
> > recognition.
>
> Would better descriptions in Kconfig help here? That's a lot easier
> and less disruptive than renaming the machine types (and the userspace
> android world, for good or ill uses the machine name to identify the
> hardware version for some hardware specific configuration stuff at
> runtime).

Better Kconfig description would certainly be nice. Renaming
board-trout* to board-dream* would be also nice (and should be doable
without any intrusive changes...?)

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Russell King - ARM Linux

unread,

Jun 11, 2009, 7:50:11 AM6/11/09

to

On Thu, Jun 11, 2009 at 04:22:26AM -0700, David Miller wrote:
> From: Russell King - ARM Linux <li...@arm.linux.org.uk>
> Date: Thu, 11 Jun 2009 12:18:22 +0100
>
> > Can you clear up this thread, which seems to be descending into absurdness.
> >
> > David Miller seems to be of the opinion that I was rude or otherwise
> > insulting to you. Was this the case?
>
> Getting one selected person's opinion is not indicative of your
> general behavior towards people and how you tend to handle ARM
> maintainence specifically.

I can not keep up with the number of patches that need to be reviewed
and ultimately merged. I know this, and I freely admit it, and I have
done so on many occasions.

I also admit that there are those whom I don't get on with, to varying
degrees. This I am ashamed about, and I try to avoid future occurances
repeating themselves by various measures, some of which have not had
the desired outcome.

I think that's all public knowledge.

However, what I'm trying to point out, and you're going out of your way
to twist, is that only the former is an issue where Brian is concerned.
Brian has now replied and we finally have the issue out in the open.

So, can you now drop the shovel (please avoid your foot) and start
dealing with the facts?

Thanks.

Brian Swetland

unread,

Jun 11, 2009, 7:50:15 AM6/11/09

to

On Thu, Jun 11, 2009 at 4:18 AM, Russell King - ARM
Linux<li...@arm.linux.org.uk> wrote:
> On Thu, Jun 11, 2009 at 04:12:39AM -0700, Brian Swetland wrote:
>> I think Andrew's idea is a good one, but we just haven't had the time
>> to try to sort this out. I'll have to see what we can do here.
>> Recently, we've been involved in omap3 work as well and have been
>> interacting more with folks in the omap kernel community as a result.
>
> Brian,
>
> Can you clear up this thread, which seems to be descending into absurdness.

I've been trying to stay out of the non-practical side of things and
focus on what can be done to improve the process...

> David Miller seems to be of the opinion that I was rude or otherwise
> insulting to you. Was this the case?

I've never felt that you were being rude or insulting. The quality of
the feedback I've gotten on patches from you has been very high. I
was a little frustrated with the last round of msm_serial.c review
which seemed to involve changing directions a couple times, but these
things happen.

> Was the only problem you had interacting with me to do with the time it
> takes to receive feedback on patches which you'd submitted and getting
> them merged? I believe that caused you to question several times whether
> you were doing things in the right way.

The turnaround time on review is the biggest source of frustration --
I try not to get too bent out of shape about this as it's a lot of
code to ask somebody to review and you're obviously pretty busy at the
best of times.

The last time around I was trying to push out patches in little bursts
(5-10 at a time). Not sure if that was too much or too little or so
on. Since I tend to have time to work on cleanup for mainline when I
get downtime between projects/deadlines, I often end up with a big
pile of stuff and a fairly short amount of time in which I can react
to review. I try to turn stuff around quickly in the face of
feedback.

In my ideal world (and I realize this doesn't really fit with the
general review model for the kernel), I'd love to get the baseline
mach-msm stuff (which doesn't impact stuff outside of that
architecture) that is stable and shipping in quite a few devices in
without completely gutting and rebuilding it, and then refine it from
there.

Brian

Brian Swetland

unread,

Jun 11, 2009, 8:00:29 AM6/11/09

to

On Thu, Jun 11, 2009 at 4:48 AM, Pavel Machek<pa...@ucw.cz> wrote:
>>
>> You'll need to fastboot boot arch/arm/boot/zImage ramdisk.img
>
> Aha, fastboot implies that ramdisk is optional.. apparently it is not.

Well, it *is* optional -- but the kernel as we build it needs an
initrd to do much that's visible. Could probably enable fb console
and provide a commandline that points console there (-c "kernel
commandline" argument to fastboot).

>> Extracting the ramdisk.img from the boot.img in the boot partition on
>> an existing device is a pain. If you happen to have a cupcake
>> userspace built from source that ramdisk.img should be suitable. If
>> not, I'll try to dig up a suitable ramdisk image tomorrow -- it's just
>> init, init.rc, and adb, but it is necessary to boot.
>
> I tried using ramdisk.img from sdk:
>
> root@amd:/data/l/android# ./fastboot boot
> /data/l/linux-msm/arch/arm/boot/uImage
> /data/l/android/sdk/platforms/android-1.5/images/ramdisk.img
>

> ...no luck :-(.

Is a uImage compatible with zImage (if the bootloader copies it to
0x10008000 and jumps there will it start?)

> Better Kconfig description would certainly be nice. Renaming
> board-trout* to board-dream* would be also nice (and should be doable
> without any intrusive changes...?)

Ah, I see. Yes, renaming the files would be easy to do and that's
totally reasonable. I thought you wanted the machine type name
changed.

Brian

David Miller

unread,

Jun 11, 2009, 8:10:25 AM6/11/09

to

From: Russell King - ARM Linux <li...@arm.linux.org.uk>

Date: Thu, 11 Jun 2009 12:49:12 +0100

> I can not keep up with the number of patches that need to be
> reviewed and ultimately merged. I know this, and I freely admit it,
> and I have done so on many occasions.

Then split up the responsibilities to other people instead of being
the choke point. Controlling everything isn't so important.

Or, alternatively, experiment with tools that could potentially make
you more efficient (patchwork has worked wonders for me).

Anything other than simply leaving things as they are...

Russell King - ARM Linux

unread,

Jun 11, 2009, 8:40:09 AM6/11/09

to

On Thu, Jun 11, 2009 at 05:00:30AM -0700, David Miller wrote:
> From: Russell King - ARM Linux <li...@arm.linux.org.uk>
> Date: Thu, 11 Jun 2009 12:49:12 +0100
>
> > I can not keep up with the number of patches that need to be
> > reviewed and ultimately merged. I know this, and I freely admit it,
> > and I have done so on many occasions.
>
> Then split up the responsibilities to other people instead of being
> the choke point. Controlling everything isn't so important.

Don't you think that I've been trying to get other people to be more
involved?

- I've been pushing people to send patches to the relevent mailing
list(s) and maintainer(s) for years.

- I've been pushing people to send their ARM patches to the ARM
mailing list rather than directly into the patch system for review
(it even has a comment telling people this) so that others can get
involved in reviewing them, and sharing that work load.

Do you think either have been anywhere near successful?

For the most part, the answer is no. People concentrate on their own
areas, and won't look at someone with a new class of platforms (eg,
the STMP or W90x900 stuff).

I'd absolutely love it if the review load could be shared, but for the
most part it just doesn't happen. Everyone's far too busy with their
own stuff to help out (and that's a reason that they'll give if tackled
head on about it.)

As I've already said, akpm tried to setup a mutual review between
several ARM folk, but as far as I'm aware, it has so far been
unsuccessful (exactly why I don't know.)

So to somehow level an accusation at me that I'm tightly controlling this
stuff is way off the mark. I've been trying to get greater participation
but it's just not happening.

> Or, alternatively, experiment with tools that could potentially make
> you more efficient (patchwork has worked wonders for me).

If patchwork can replace what my patch system does for me (which is
basically to help ensure that patches don't get lost which need
applying - that's different from logging every single patch) then
I'll gladly look at it. It will mean that some of the sanity checks
on the patch content, which happen automatically with the patch system,
will need to be done manually.

If patchwork just gathers up every patch which has ever been seen on
a mailing list, then stuff will get lost at a higher rate than today
and it will have a negative impact.

Bob Copeland

unread,

Jun 11, 2009, 8:50:10 AM6/11/09

to

On Thu, Jun 11, 2009 at 7:09 AM, Pavel Machek<pa...@ucw.cz> wrote:
> Anyway, now I have a tree, and yes it compiles. (After some
> "interesting" questions; perhaps defconfig should be updated?)

> ...and I just selected "3" being default. No help available :-(. I

> have cupcake installed, and I believe I installed radio update
> required for cupcake. Can someone help?

I can send you my .config if you want, I have it working.

Note you need the latest userland because the initrd details changed
a bit (e.g. a 2.6.29 kernel will not work on the 1.1 userland, but
will work on 1.5, something to do with mounting the filesystems, I
can't remember exactly from my serial traces.)

--
Bob Copeland %% www.bobcopeland.com

Alan Cox

unread,

Jun 11, 2009, 9:00:26 AM6/11/09

to

> For the most part, the answer is no. People concentrate on their own
> areas, and won't look at someone with a new class of platforms (eg,
> the STMP or W90x900 stuff).

That would appear to be rational behaviour on their part.

> As I've already said, akpm tried to setup a mutual review between
> several ARM folk, but as far as I'm aware, it has so far been
> unsuccessful (exactly why I don't know.)

Because its not rational economic behaviour on their part ?

> If patchwork just gathers up every patch which has ever been seen on
> a mailing list, then stuff will get lost at a higher rate than today
> and it will have a negative impact.

Stop trying to stand in the middle of the motorway and directing traffic.
You will get run over if you do that even if you are the best person on
the planet at that job.

The problem is perfectly sortable with a bit of experimenting. This is a
first suggestion - it might not work but it can't make things much worse
and if the current system doesn't work the first process to fix it is to
change things.

Make your tree the core ARM code only, any other patches you don't
accept. Aggressively push stuff out to platform code, and if people want
to change core code "because our platform is different" make them extract
it into the platform layer not carry it in the core bits.

Nominate a bunch of people for the main ARM platforms. What they put into
their platform specific trees goes direct from them to -next and if they
trash their own platform thats their problem (and they can come to you
for advice ;))

Leave it to the platform people to push their driver code through the
right channels.

You may be ten times better than them at the job, but there are a hundred
of them.

Each of the teams now has an economic focus that is in accord with what
they need to do "Get our platform working well", and as a secondary
effect if one of the teams accidentally messes up another they've both
got economic incentives to fix their shared problem. For core code
issues you can just follow Linus usual approach of "I'll merge this when
you've all stopped fighting and agreed a solution" (again you'll note
this creates the correct incentives).

Which all in all might give you a bit more time to go gliding rather than
running around like a lunatic trying to herd cats.

Alan

Pavel Machek

unread,

Jun 11, 2009, 9:10:12 AM6/11/09

to

On Thu 2009-06-11 08:45:36, Bob Copeland wrote:
> On Thu, Jun 11, 2009 at 7:09 AM, Pavel Machek<pa...@ucw.cz> wrote:
> > Anyway, now I have a tree, and yes it compiles. (After some
> > "interesting" questions; perhaps defconfig should be updated?)
>
> > ...and I just selected "3" being default. No help available :-(. I
> > have cupcake installed, and I believe I installed radio update
> > required for cupcake. Can someone help?
>
> I can send you my .config if you want, I have it working.

That would be cool...

> Note you need the latest userland because the initrd details changed
> a bit (e.g. a 2.6.29 kernel will not work on the 1.1 userland, but
> will work on 1.5, something to do with mounting the filesystems, I
> can't remember exactly from my serial traces.)

I do have cupcake userland (from JF)... When I change command line
options or try to boot zImage, it hangs with rainbow screen.

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Russell King - ARM Linux

unread,

Jun 11, 2009, 9:20:09 AM6/11/09

to

On Thu, Jun 11, 2009 at 01:54:42PM +0100, Alan Cox wrote:
> Make your tree the core ARM code only, any other patches you don't
> accept. Aggressively push stuff out to platform code, and if people want
> to change core code "because our platform is different" make them extract
> it into the platform layer not carry it in the core bits.

I'm all for giving this a try after this merge window is over.

Brian Swetland

unread,

Jun 11, 2009, 9:20:11 AM6/11/09

to

On Thu, Jun 11, 2009 at 5:54 AM, Alan Cox<al...@lxorguk.ukuu.org.uk> wrote:
>
> Make your tree the core ARM code only, any other patches you don't
> accept. Aggressively push stuff out to platform code, and if people want
> to change core code "because our platform is different" make them extract
> it into the platform layer not carry it in the core bits.
>
> Nominate a bunch of people for the main ARM platforms. What they put into
> their platform specific trees goes direct from them to -next and if they
> trash their own platform thats their problem (and they can come to you
> for advice ;))
>
> Leave it to the platform people to push their driver code through the
> right channels.

This would seem to address a lot of the scalability issues, and from
what I can tell, it's pretty hard for somebody mucking stuff up in
arch/arm/mach-something/... to break arch/arm/mach-otherthing/...

I'd be thrilled to get the msm stuff in to the main tree and deal with
patches submitted against it (and the android stuff in staging seems
to show that people will start submitting patches against things if
it's in the mainline -- for example the binder patches that have
turned up, etc).

As far as what we're maintaining in the android-msm tree, there's:
generic android drivers -- most of which are already in staging thanks to Greg
arch/arm/mach-msm/... -- 7k (and soon 8k) SoC support
various msm drivers -- could be submitted via drivers/staging and the
usual review process
a couple small generic arm patches -- stuff that we should be
discussing in lakml
some generic linux patches -- Arve's pretty good about sending these
to lkml as they happen

Brian

Pavel Machek

unread,

Jun 11, 2009, 9:30:21 AM6/11/09

to

On Thu 2009-06-11 13:38:52, Russell King - ARM Linux wrote:
> On Thu, Jun 11, 2009 at 05:00:30AM -0700, David Miller wrote:
> > From: Russell King - ARM Linux <li...@arm.linux.org.uk>
> > Date: Thu, 11 Jun 2009 12:49:12 +0100
> >
> > > I can not keep up with the number of patches that need to be
> > > reviewed and ultimately merged. I know this, and I freely admit it,
> > > and I have done so on many occasions.
> >
> > Then split up the responsibilities to other people instead of being
> > the choke point. Controlling everything isn't so important.
>
> Don't you think that I've been trying to get other people to be more
> involved?
>
> - I've been pushing people to send patches to the relevent mailing
> list(s) and maintainer(s) for years.

The patch system is actively harmful here, because you either send the
system for discussion, or for inclusion. Picking the patches from the
mailing list when there are no significant comments (as done on lkml)
seems to work better.

> If patchwork can replace what my patch system does for me (which is
> basically to help ensure that patches don't get lost which need
> applying - that's different from logging every single patch) then
> I'll gladly look at it. It will mean that some of the sanity checks
> on the patch content, which happen automatically with the patch system,
> will need to be done manually.
>
> If patchwork just gathers up every patch which has ever been seen on
> a mailing list, then stuff will get lost at a higher rate than today
> and it will have a negative impact.

I believe you are concentrating on "patch loss rate" a bit too
much. lkml does have higher "patch loss rate", still it seems
better/nicer/easier to work with.

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Tony Lindgren

unread,

Jun 11, 2009, 9:30:23 AM6/11/09

to

* Alan Cox <al...@lxorguk.ukuu.org.uk> [090611 05:54]:

> > For the most part, the answer is no. People concentrate on their own
> > areas, and won't look at someone with a new class of platforms (eg,
> > the STMP or W90x900 stuff).
>
> That would appear to be rational behaviour on their part.
>
> > As I've already said, akpm tried to setup a mutual review between
> > several ARM folk, but as far as I'm aware, it has so far been
> > unsuccessful (exactly why I don't know.)
>
> Because its not rational economic behaviour on their part ?
>
> > If patchwork just gathers up every patch which has ever been seen on
> > a mailing list, then stuff will get lost at a higher rate than today
> > and it will have a negative impact.

Just to comment on the patchwork, we've been using p.k.o for the omap
stuff for few months. It helps for sure as I can now nuke my omap inbox
on regular basis without losing patches :)

But even just for the omap code, we need several people dealing with them,
otherwise there's just too many patches floating around.

So in order to use patchwork for arm patches, it would have to be
distributed to many people to make any use of it like Alan is suggesting.
Otherwise it just fills up with tons of patches.

> Stop trying to stand in the middle of the motorway and directing traffic.
> You will get run over if you do that even if you are the best person on
> the planet at that job.
>
> The problem is perfectly sortable with a bit of experimenting. This is a
> first suggestion - it might not work but it can't make things much worse
> and if the current system doesn't work the first process to fix it is to
> change things.
>
> Make your tree the core ARM code only, any other patches you don't
> accept. Aggressively push stuff out to platform code, and if people want
> to change core code "because our platform is different" make them extract
> it into the platform layer not carry it in the core bits.
>
> Nominate a bunch of people for the main ARM platforms. What they put into
> their platform specific trees goes direct from them to -next and if they
> trash their own platform thats their problem (and they can come to you
> for advice ;))

We've done this for two merge windows now for omap patches where the
patches have been posted to linux-arm-kernel, then they go into the
for-next tree, and then Russell merges them in.

It has worked OK, although Russell had some comments about having hard
time keeping track on what he had reviewed already.

> Leave it to the platform people to push their driver code through the
> right channels.
>
> You may be ten times better than them at the job, but there are a hundred
> of them.

Some code Russell of course wants to review more carefully, like the omap
clock code that Russell has contributed heavily on.

But in general, I believe Alan's approach would help to distribute the
merging, and scale it up.

> Each of the teams now has an economic focus that is in accord with what
> they need to do "Get our platform working well", and as a secondary
> effect if one of the teams accidentally messes up another they've both
> got economic incentives to fix their shared problem. For core code
> issues you can just follow Linus usual approach of "I'll merge this when
> you've all stopped fighting and agreed a solution" (again you'll note
> this creates the correct incentives).
>
> Which all in all might give you a bit more time to go gliding rather than
> running around like a lunatic trying to herd cats.

Of course we'd still like to get Russell's comments too on the code where
possible :)

Tony

Russell King - ARM Linux

unread,

Jun 11, 2009, 9:30:25 AM6/11/09

to

On Thu, Jun 11, 2009 at 01:54:42PM +0100, Alan Cox wrote:

> Leave it to the platform people to push their driver code through the
> right channels.

I should point out that that has been entirely the case since switching
over to BK, and later git. I do not merge other driver code into my
tree unless the subsystem maintainer wants me to do so, in which case I
do give it a quick review. Sometimes I give people a quick review on
the way to directing them to the right places.

I do hope you don't think I still run that unmanagable -rmk tree that
was around when you did the -ac series kernels. I gave that up as a
bad approach a very long time ago.

Alan Cox

unread,

Jun 11, 2009, 9:40:09 AM6/11/09

to

> I do hope you don't think I still run that unmanagable -rmk tree that
> was around when you did the -ac series kernels. I gave that up as a
> bad approach a very long time ago.

No I didn't think that. You'd either have expired by now or be found
screaming in a small room with soft walls if you did ;)

Russell King - ARM Linux

unread,

Jun 11, 2009, 9:40:11 AM6/11/09

to

On Thu, Jun 11, 2009 at 06:21:35AM -0700, Tony Lindgren wrote:
> We've done this for two merge windows now for omap patches where the
> patches have been posted to linux-arm-kernel, then they go into the
> for-next tree, and then Russell merges them in.
>
> It has worked OK, although Russell had some comments about having hard
> time keeping track on what he had reviewed already.

Yes, as I understand it, there was a closed room discussion between
several folk about how you'd handle sending your next round of patches
to me.

What you apparantly decided (and I'm saying this from how it appeared
on the receiving end and sort-of had it confirmed by Kevin in conference)
is that you'd send a patch set for me to review, I'd review it, and then
you'd merge it within your git tree into a branch for me. You'd then do
the same thing with the next patch set, and so forth.

Eventually, near the merge window, you sent a pull request for the
entire lot, by which time I looked at the list of changes and wondered
whether that encompassed everything you'd asked me to review, or whether
it contained extra stuff, or whether it was for something quite different,
or what.

So by separating the review from the merge by weeks or even months, it
created additional problems.

Russell King - ARM Linux

unread,

Jun 11, 2009, 10:10:13 AM6/11/09

to

On Thu, Jun 11, 2009 at 07:00:39AM -0700, Tony Lindgren wrote:
> You suggested pulling each set as they get reviewed into some omap branch
> in your tree, do you want to try that the next merge window?

If we're following Alan's suggestion, then as I see it you're entirely
responsible for tracking what's in OMAP, getting it into linux-next and
(I guess) ultimately sending Linus a pull request for it during the
merge window. I just become someone who can put their oar into reviewing
OMAP patches as and when.

So the question is: do you want to give this a go?

Tony Lindgren

unread,

Jun 11, 2009, 10:10:15 AM6/11/09

to

* Russell King - ARM Linux <li...@arm.linux.org.uk> [090611 06:38]:

> On Thu, Jun 11, 2009 at 06:21:35AM -0700, Tony Lindgren wrote:
> > We've done this for two merge windows now for omap patches where the
> > patches have been posted to linux-arm-kernel, then they go into the
> > for-next tree, and then Russell merges them in.
> >
> > It has worked OK, although Russell had some comments about having hard
> > time keeping track on what he had reviewed already.
>
> Yes, as I understand it, there was a closed room discussion between
> several folk about how you'd handle sending your next round of patches
> to me.

Yes, this was to coordinate the merge conflicts that we knew were going
to happen.

> What you apparantly decided (and I'm saying this from how it appeared
> on the receiving end and sort-of had it confirmed by Kevin in conference)
> is that you'd send a patch set for me to review, I'd review it, and then
> you'd merge it within your git tree into a branch for me. You'd then do
> the same thing with the next patch set, and so forth.
>
> Eventually, near the merge window, you sent a pull request for the
> entire lot, by which time I looked at the list of changes and wondered
> whether that encompassed everything you'd asked me to review, or whether
> it contained extra stuff, or whether it was for something quite different,
> or what.

Hmm, well it was what was posted to the list, and I kept piling it up
into for-next as the patchsets got reviewed.

> So by separating the review from the merge by weeks or even months, it
> created additional problems.

Yeah this can be a problem as at that point you have to pull or check
the patches again if you don't trust people to send you the stuff that got
posted earlier.

You suggested pulling each set as they get reviewed into some omap branch
in your tree, do you want to try that the next merge window?

What I can easily see happening with this approach is that we end up waiting
1 - 2 weeks between each set before you pull, which can make merging painfully
slow as we may have let's say five 10 patch sets to merge.

Also, what do we do with the sets that you don't have time to review or
don't want to review?

Regards,

Tony

Alex Riesen

unread,

Jun 11, 2009, 10:40:11 AM6/11/09

to

2009/6/11 Pavel Machek <pa...@ucw.cz>:
>
> Strange, I attempted downloading this overnight (285MB!) by
>
> git clone --template=/data/l/clean-cg/ git://android.git.kernel.org/kernel/msm.git
>

I believe you need --reference, not --template. No wonder you had to download
complete repository anew.

Pavel Machek

unread,

Jun 11, 2009, 10:50:14 AM6/11/09

to

Hi!

> What you apparantly decided (and I'm saying this from how it appeared
> on the receiving end and sort-of had it confirmed by Kevin in conference)
> is that you'd send a patch set for me to review, I'd review it, and then
> you'd merge it within your git tree into a branch for me. You'd then do
> the same thing with the next patch set, and so forth.
>
> Eventually, near the merge window, you sent a pull request for the
> entire lot, by which time I looked at the list of changes and wondered
> whether that encompassed everything you'd asked me to review, or whether
> it contained extra stuff, or whether it was for something quite different,
> or what.

Well, usually Acked-by: and Reviewed-by: tags solve that, no?

If it has my acked-by: it is okay and can be applied. Otherwise I did
not review it before and need to check it...

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Pavel Machek

unread,

Jun 11, 2009, 11:00:11 AM6/11/09

to

On Thu 2009-06-11 04:53:10, Brian Swetland wrote:
> On Thu, Jun 11, 2009 at 4:48 AM, Pavel Machek<pa...@ucw.cz> wrote:
> >>
> >> You'll need to fastboot boot arch/arm/boot/zImage ramdisk.img
> >
> > Aha, fastboot implies that ramdisk is optional.. apparently it is not.
>
> Well, it *is* optional -- but the kernel as we build it needs an
> initrd to do much that's visible. Could probably enable fb console
> and provide a commandline that points console there (-c "kernel
> commandline" argument to fastboot).

I tried that without much luck. Also... defconfig has mem=64M. Is
that correct?

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Pavel Machek

unread,

Jun 11, 2009, 11:00:13 AM6/11/09

to

On Thu 2009-06-11 16:33:36, Alex Riesen wrote:
> 2009/6/11 Pavel Machek <pa...@ucw.cz>:
> >
> > Strange, I attempted downloading this overnight (285MB!) by
> >
> > git clone �--template=/data/l/clean-cg/ git://android.git.kernel.org/kernel/msm.git
> >
>
> I believe you need --reference, not --template. No wonder you had to download
> complete repository anew.

Oops, right. My ISP hates me...
Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Pavel Machek

unread,

Jun 11, 2009, 11:00:18 AM6/11/09

to

On Thu 2009-06-11 04:53:10, Brian Swetland wrote:

> On Thu, Jun 11, 2009 at 4:48 AM, Pavel Machek<pa...@ucw.cz> wrote:
> >>
> >> You'll need to fastboot boot arch/arm/boot/zImage ramdisk.img
> >
> > Aha, fastboot implies that ramdisk is optional.. apparently it is not.
>
> Well, it *is* optional -- but the kernel as we build it needs an
> initrd to do much that's visible. Could probably enable fb console
> and provide a commandline that points console there (-c "kernel
> commandline" argument to fastboot).

Ok... but still no success. For some reason it seems to work better if
I use uImage (at least I get blank screen) than zImage (fastboot just
hangs).

> >> Extracting the ramdisk.img from the boot.img in the boot partition on
> >> an existing device is a pain. �If you happen to have a cupcake
> >> userspace built from source that ramdisk.img should be suitable. �If
> >> not, I'll try to dig up a suitable ramdisk image tomorrow -- it's just
> >> init, init.rc, and adb, but it is necessary to boot.
> >
> > I tried using ramdisk.img from sdk:
> >
> > root@amd:/data/l/android# ./fastboot boot
> > /data/l/linux-msm/arch/arm/boot/uImage
> > /data/l/android/sdk/platforms/android-1.5/images/ramdisk.img
> >
> > ...no luck :-(.
>
> Is a uImage compatible with zImage (if the bootloader copies it to
> 0x10008000 and jumps there will it start?)

No idea :-(. (And thanks for ramdisk.img; it is different from what I
have, but results seem same).

> > Better Kconfig description would certainly be nice. Renaming
> > board-trout* to board-dream* would be also nice (and should be doable
> > without any intrusive changes...?)
>
> Ah, I see. Yes, renaming the files would be easy to do and that's
> totally reasonable. I thought you wanted the machine type name
> changed.

Good.
Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Joe Perches

unread,

Jun 11, 2009, 11:20:12 AM6/11/09

to

On Thu, 2009-06-11 at 13:38 +0100, Russell King - ARM Linux wrote:
> On Thu, Jun 11, 2009 at 05:00:30AM -0700, David Miller wrote:
> > From: Russell King - ARM Linux <li...@arm.linux.org.uk>
> > Date: Thu, 11 Jun 2009 12:49:12 +0100
> >
> > > I can not keep up with the number of patches that need to be
> > > reviewed and ultimately merged. I know this, and I freely admit it,
> > > and I have done so on many occasions.
> >
> > Then split up the responsibilities to other people instead of being
> > the choke point. Controlling everything isn't so important.
>
> Don't you think that I've been trying to get other people to be more
> involved?
>
> - I've been pushing people to send patches to the relevent mailing
> list(s) and maintainer(s) for years.
>
> - I've been pushing people to send their ARM patches to the ARM
> mailing list rather than directly into the patch system for review
> (it even has a comment telling people this) so that others can get
> involved in reviewing them, and sharing that work load.
>
> Do you think either have been anywhere near successful?

[]

> I've been trying to get greater participation
> but it's just not happening.

I suggest you stop using subscriber-only mailing lists and
use linu...@vger.kernel.org.

Russell King - ARM Linux

unread,

Jun 11, 2009, 11:40:08 AM6/11/09

to

On Thu, Jun 11, 2009 at 08:15:10AM -0700, Joe Perches wrote:
> On Thu, 2009-06-11 at 13:38 +0100, Russell King - ARM Linux wrote:
> > Don't you think that I've been trying to get other people to be more
> > involved?
> >
> > - I've been pushing people to send patches to the relevent mailing
> > list(s) and maintainer(s) for years.
> >
> > - I've been pushing people to send their ARM patches to the ARM
> > mailing list rather than directly into the patch system for review
> > (it even has a comment telling people this) so that others can get
> > involved in reviewing them, and sharing that work load.
> >
> > Do you think either have been anywhere near successful?
> []
> > I've been trying to get greater participation
> > but it's just not happening.
>
> I suggest you stop using subscriber-only mailing lists and
> use linu...@vger.kernel.org.

It's difficult to see how that helps, given that these lists have
1800+ subscribers already on them. If 1800 subscribers can't do it,
are you expecting (maybe) another 100 to magically provide the answer?

Joe Perches

unread,

Jun 11, 2009, 12:00:16 PM6/11/09

to

On Thu, 2009-06-11 at 16:39 +0100, Russell King - ARM Linux wrote:
> On Thu, Jun 11, 2009 at 08:15:10AM -0700, Joe Perches wrote:
> > I suggest you stop using subscriber-only mailing lists and
> > use linu...@vger.kernel.org.
> It's difficult to see how that helps, given that these lists have
> 1800+ subscribers already on them. If 1800 subscribers can't do it,
> are you expecting (maybe) another 100 to magically provide the answer?

There aren't large numbers of ARM posters.

You've simply put up an unnecessary roadblock to
getting patches for review.

Alan Cox

unread,

Jun 11, 2009, 12:00:23 PM6/11/09

to

> - I wait few days and if no comments, pile them into for-next
>
> - I send a pull request to you to keep things coordinated for arm

You don't even need that - you can decouple that further and there are
good reasons to do so to some extent.

> - If you want something merged earlier, you let know and send pull
> request
>
> I'm flexible, and willing to try other things if that helps you.
> But I think we (as arm community) should coordinate the arm patches
> ourselves. So I'd rather see you pull in stuff and send it to
> Linus rather than bug Linus with a pull request for stuff that
> he may not care too much about.

The sooner its in next the sooner its really visible. Whether Russell
pulls your tree for the final merge and resends it on or you do it
directly is fairly irrelevant to the final merge but you maximise
exposure if linux-next is directly pulling your trees and adding them
after the arm tree somewhere. If you get collisions Stephen will just
drop your tree while you fix it. Similarly if you end up with an overlap
where your patches end up in both trees git will figure it out itself.

Alan

Russell King - ARM Linux

unread,

Jun 11, 2009, 12:00:25 PM6/11/09

to

On Thu, Jun 11, 2009 at 03:21:17PM +0200, Pavel Machek wrote:
> On Thu 2009-06-11 13:38:52, Russell King - ARM Linux wrote:
> > On Thu, Jun 11, 2009 at 05:00:30AM -0700, David Miller wrote:
> > > From: Russell King - ARM Linux <li...@arm.linux.org.uk>
> > > Date: Thu, 11 Jun 2009 12:49:12 +0100
> > >
> > > > I can not keep up with the number of patches that need to be
> > > > reviewed and ultimately merged. I know this, and I freely admit it,
> > > > and I have done so on many occasions.
> > >
> > > Then split up the responsibilities to other people instead of being
> > > the choke point. Controlling everything isn't so important.
> >
> > Don't you think that I've been trying to get other people to be more
> > involved?
> >
> > - I've been pushing people to send patches to the relevent mailing
> > list(s) and maintainer(s) for years.
>
> The patch system is actively harmful here, because you either send the
> system for discussion, or for inclusion. Picking the patches from the
> mailing list when there are no significant comments (as done on lkml)
> seems to work better.

That's your view - I used to do the "picking patches from the mailing
list" thing, and the result was that patches got dropped at an alarming
rate.

That's exactly why I created the patch system - to provide a solution
for that problem.

That problem still exists today - I still operate with email in a way
which means if I don't deal with something as soon as I see it, it gets
filed away and almost never looked at again - even if I re-mark the
message as 'New'. That means if it's inconvenient to apply a patch
(because the machine with the git trees on is powered down) then the
patch tends to get lost.

Hey, I'm useless with email, there's nothing new there. I know this
so I created a way to solve it.

With the patch system, it remains visible to me without the clutter of
lots of other email, and therefore stands a much better chance of being
applied.

It is just rather unfortunate that since the patch system was written,
a different kind of patch format was invented which isn't compatible
with the patch system, and it doesn't cope well with this other format.

But hey, if you want me to drop lots of patches, then sure just send
them by email. Just expect to nag me a lot more about applying your
patch.

Tony Lindgren

unread,

Jun 11, 2009, 12:10:10 PM6/11/09

to

On Thu, Jun 11, 2009 at 03:06:24PM +0100, Russell King - ARM Linux wrote:
> On Thu, Jun 11, 2009 at 07:00:39AM -0700, Tony Lindgren wrote:
> > You suggested pulling each set as they get reviewed into some omap branch
> > in your tree, do you want to try that the next merge window?
>
> If we're following Alan's suggestion, then as I see it you're entirely
> responsible for tracking what's in OMAP, getting it into linux-next and
> (I guess) ultimately sending Linus a pull request for it during the
> merge window. I just become someone who can put their oar into reviewing
> OMAP patches as and when.
>
> So the question is: do you want to give this a go?

How about this:

- We post patches for review to the related lists like always

- You and others ack nak as usual

- If you want more time to look at something, you reply with a comment

- I wait few days and if no comments, pile them into for-next

- I send a pull request to you to keep things coordinated for arm

- If you want something merged earlier, you let know and send pull
request

I'm flexible, and willing to try other things if that helps you.
But I think we (as arm community) should coordinate the arm patches
ourselves. So I'd rather see you pull in stuff and send it to
Linus rather than bug Linus with a pull request for stuff that
he may not care too much about.

Cheers,

Tony

Russell King - ARM Linux

unread,

Jun 11, 2009, 12:10:13 PM6/11/09

to

On Thu, Jun 11, 2009 at 08:53:00AM -0700, Joe Perches wrote:
> On Thu, 2009-06-11 at 16:39 +0100, Russell King - ARM Linux wrote:
> > On Thu, Jun 11, 2009 at 08:15:10AM -0700, Joe Perches wrote:
> > > I suggest you stop using subscriber-only mailing lists and
> > > use linu...@vger.kernel.org.
> > It's difficult to see how that helps, given that these lists have
> > 1800+ subscribers already on them. If 1800 subscribers can't do it,
> > are you expecting (maybe) another 100 to magically provide the answer?
>
> There aren't large numbers of ARM posters.
>
> You've simply put up an unnecessary roadblock to
> getting patches for review.

I simply disagree with your assessment of the situation. Yes, there are
a few people who refuse to subscribe to such lists, but I maintain that's
a fairly small proportion.

I'd also point out that most of the people in this thread aren't
subscribed to this list, yet they're posting freely to it. Some of the
people posting to it will get a moderation message for a couple of times
and then no more. As I've said in the past, unlike most subscriber only
lists, these lists aren't strictly subscriber only. Eg, Alan has been
able to post to the lists for ages without being a subscriber.

Russell King - ARM Linux

unread,

Jun 11, 2009, 12:10:14 PM6/11/09

to

On Thu, Jun 11, 2009 at 04:47:35PM +0200, Pavel Machek wrote:
> Well, usually Acked-by: and Reviewed-by: tags solve that, no?
>
> If it has my acked-by: it is okay and can be applied. Otherwise I did
> not review it before and need to check it...

It would be nice if git pull messages included that information, but
they don't. The only way to get at that from a pull message is to
pull the tree and then check it, or track down whatever random gitweb
URL corresponds with the tree and check it there.

Kevin Hilman

unread,

Jun 11, 2009, 12:30:18 PM6/11/09

to

Russell King - ARM Linux <li...@arm.linux.org.uk> writes:

> On Thu, Jun 11, 2009 at 01:54:42PM +0100, Alan Cox wrote:
>> Make your tree the core ARM code only, any other patches you don't
>> accept. Aggressively push stuff out to platform code, and if people want
>> to change core code "because our platform is different" make them extract
>> it into the platform layer not carry it in the core bits.
>
> I'm all for giving this a try after this merge window is over.

Speaking as maintainer of one ARM subarch (davinci) and active
contributor to another (OMAP), I would gladly give this a try as well.

Kevin

Bartlomiej Zolnierkiewicz

unread,

Jun 11, 2009, 12:40:10 PM6/11/09

to

On Thursday 11 June 2009 18:08:50 Russell King - ARM Linux wrote:
> On Thu, Jun 11, 2009 at 08:53:00AM -0700, Joe Perches wrote:
> > On Thu, 2009-06-11 at 16:39 +0100, Russell King - ARM Linux wrote:
> > > On Thu, Jun 11, 2009 at 08:15:10AM -0700, Joe Perches wrote:
> > > > I suggest you stop using subscriber-only mailing lists and
> > > > use linu...@vger.kernel.org.
> > > It's difficult to see how that helps, given that these lists have
> > > 1800+ subscribers already on them. If 1800 subscribers can't do it,
> > > are you expecting (maybe) another 100 to magically provide the answer?
> >
> > There aren't large numbers of ARM posters.
> >
> > You've simply put up an unnecessary roadblock to
> > getting patches for review.
>
> I simply disagree with your assessment of the situation. Yes, there are
> a few people who refuse to subscribe to such lists, but I maintain that's
> a fairly small proportion.
>
> I'd also point out that most of the people in this thread aren't
> subscribed to this list, yet they're posting freely to it. Some of the
> people posting to it will get a moderation message for a couple of times
> and then no more. As I've said in the past, unlike most subscriber only

Interesting.

Here is the typical moderation message I was getting:

On Tuesday 17 February 2009 14:08:44 linux-arm-ke...@lists.arm.linux.org.uk wrote:
> Your request to the Linux-arm-kernel mailing list
>
> Posting of your message titled "Re: [PATCH 3/3 v3] AT91:
> initialize Compact Flash on AT91SAM9263 cpu"
>
> has been rejected by the list moderator. The moderator gave the
> following reason for rejecting your request:
>
> "No reason given"
>
> Any questions or comments should be directed to the list administrator
> at:
>
> linux-arm-k...@lists.arm.linux.org.uk

"No reason given" part was just lovely..

After getting a couple of such messages I decided to stay as far away from
linux-arm-kernel list as possible..

Before interacting with linux-arm-kernel list I really thought that people
exaggerated the issue and that their complains were unfounded..

Russell King - ARM Linux

unread,

Jun 11, 2009, 12:50:10 PM6/11/09

to

On Thu, Jun 11, 2009 at 06:37:21PM +0200, Bartlomiej Zolnierkiewicz wrote:
> "No reason given" part was just lovely..
>
> After getting a couple of such messages I decided to stay as far away from
> linux-arm-kernel list as possible..
>
> Before interacting with linux-arm-kernel list I really thought that people
> exaggerated the issue and that their complains were unfounded..

I wish people told me about this - it's certainly not my policy nor
indeed the policy which should be applied to the list. I'll find out
what's going on when my co-list admin returns from his vacation.

Thanks for bringing it to my attention.

Nicolas Pitre

unread,

Jun 11, 2009, 1:00:13 PM6/11/09

to

On Thu, 11 Jun 2009, Kevin Hilman wrote:

> Russell King - ARM Linux <li...@arm.linux.org.uk> writes:
>
> > On Thu, Jun 11, 2009 at 01:54:42PM +0100, Alan Cox wrote:
> >> Make your tree the core ARM code only, any other patches you don't
> >> accept. Aggressively push stuff out to platform code, and if people want
> >> to change core code "because our platform is different" make them extract
> >> it into the platform layer not carry it in the core bits.
> >
> > I'm all for giving this a try after this merge window is over.
>
> Speaking as maintainer of one ARM subarch (davinci) and active
> contributor to another (OMAP), I would gladly give this a try as well.

Speaking as maintainer of a couple other ARM subarchs (Orion, Kirkwood,
MV78xx0, ...) I would gladly accept full responsibility (and blame) for
them as well. I think Russell could avoid astraining to himself full
review for every patch concerning those that I send his way, and merely
look at the diffstat to be sure I'm not crapping onto the core ARM code.
Linus certainly doesn't do much more than that on his end already.

It's been a couple merge windows now that RMK started accepting git pull
requests from a couple people in addition to his patch system, and that
has worked pretty well overall.

Nicolas

Ben Dooks

unread,

Jun 11, 2009, 1:20:08 PM6/11/09

to

On Thu, Jun 11, 2009 at 09:37:40AM +0200, Pavel Machek wrote:
> On Thu 2009-06-11 00:02:19, David Miller wrote:
> > From: Russell King - ARM Linux <li...@arm.linux.org.uk>
> > Date: Wed, 10 Jun 2009 20:48:52 +0100
> >
> > > In short not as far as I know, and I'm very disappointed with the state
> > > of affairs with google.
> >
> > And of course, this whole android situation has absolutely nothing to
> > do with how much of a pain in that ass you are to deal with as ARM
> > maintainer.
>
> Well, linux-arm-devel being subscribers-only and patch management
> system that needs special headers certainly does not help here :-(.

And subscribing to a mailing list is so hard to do?

I'd point out that the patch tracker has been around for a long time,
and has done a great job of keep track of patches. The couple of extra
(well documented) lines is worth it to give extra data about how the
patch was created.

--
Ben (b...@fluff.org, http://www.fluff.org/)

'a smiley only costs 4 bytes'

Nicolas Pitre

unread,

Jun 11, 2009, 1:40:07 PM6/11/09

to

On Thu, 11 Jun 2009, Russell King - ARM Linux wrote:

> On Thu, Jun 11, 2009 at 07:00:39AM -0700, Tony Lindgren wrote:
> > You suggested pulling each set as they get reviewed into some omap branch
> > in your tree, do you want to try that the next merge window?
>
> If we're following Alan's suggestion, then as I see it you're entirely
> responsible for tracking what's in OMAP, getting it into linux-next and
> (I guess) ultimately sending Linus a pull request for it during the
> merge window. I just become someone who can put their oar into reviewing
> OMAP patches as and when.

I don't see things exactly that way.

linux-next is a fully automated "let's dump everything together and see
what is going to explode" kind of tree. There is no patch review except
from those who see their code being dammaged by the blast. And it is
automated in the sense that git pull operations are done automatically,
even if someone deals with the merge conflicts manually afterwards. My
tree can be pulled into linux-next directly or through your tree, or
even through both paths in parallel and git will deal with it just fine.
And at the end of the day the linux-next tree is tossed in the garbage
bin anyway.

I think that you, as the ARM maintainer, should continue gathering all
the ARM subarchitectures into a coherent ARM tree and arbitrate
conflicts when they occur. You should especially keep a tight control
on the very core ARM code. But everything under arch/arm/mach-* you
should let people maintaining those have control of that themselves and
free yourself from that responsibility as much as possible. The current
directory structure is quite indicative of where the boundaries are
already. This way, if I make a mess of arch/arm/mach-orion5x/* then you
just need to pass the blame straight to me.

Nicolas

Marek Vasut

unread,

Jun 11, 2009, 2:00:12 PM6/11/09

to

On Thursday 11 of June 2009 09:02:19 David Miller wrote:
> From: Russell King - ARM Linux <li...@arm.linux.org.uk>
> Date: Wed, 10 Jun 2009 20:48:52 +0100
>
> > In short not as far as I know, and I'm very disappointed with the state
> > of affairs with google.
>
> And of course, this whole android situation has absolutely nothing to
> do with how much of a pain in that ass you are to deal with as ARM
> maintainer.

I had no problems with Russell yet, he always helped me with merging my
patches ... hmm
>
> Absolutely nothing, right?
>
> :-(
>
> -------------------------------------------------------------------
> List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
> FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
> Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php

Sam Ravnborg

unread,

Jun 11, 2009, 2:30:19 PM6/11/09

to

On Thu, Jun 11, 2009 at 08:15:10AM -0700, Joe Perches wrote:

> On Thu, 2009-06-11 at 13:38 +0100, Russell King - ARM Linux wrote:
> > On Thu, Jun 11, 2009 at 05:00:30AM -0700, David Miller wrote:
> > > From: Russell King - ARM Linux <li...@arm.linux.org.uk>
> > > Date: Thu, 11 Jun 2009 12:49:12 +0100
> > >
> > > > I can not keep up with the number of patches that need to be
> > > > reviewed and ultimately merged. I know this, and I freely admit it,
> > > > and I have done so on many occasions.
> > >
> > > Then split up the responsibilities to other people instead of being
> > > the choke point. Controlling everything isn't so important.
> >
> > Don't you think that I've been trying to get other people to be more
> > involved?
> >
> > - I've been pushing people to send patches to the relevent mailing
> > list(s) and maintainer(s) for years.
> >
> > - I've been pushing people to send their ARM patches to the ARM
> > mailing list rather than directly into the patch system for review
> > (it even has a comment telling people this) so that others can get
> > involved in reviewing them, and sharing that work load.
> >
> > Do you think either have been anywhere near successful?
> []
> > I've been trying to get greater participation
> > but it's just not happening.
>
> I suggest you stop using subscriber-only mailing lists and
> use linu...@vger.kernel.org.

This is main point here is to offload Russell.
One way to offload Russell is to have competent people reviewing platform
code for ARM. This is best done by other platform people.
Me and you - we can helpt. But the people where we need higher
involvement are already on the list.

Sam

Ryan Mallon

unread,

Jun 11, 2009, 5:30:13 PM6/11/09

to

Nicolas Pitre wrote:
> On Thu, 11 Jun 2009, Russell King - ARM Linux wrote:
>
> I think that you, as the ARM maintainer, should continue gathering all
> the ARM subarchitectures into a coherent ARM tree and arbitrate
> conflicts when they occur. You should especially keep a tight control
> on the very core ARM code. But everything under arch/arm/mach-* you
> should let people maintaining those have control of that themselves and
> free yourself from that responsibility as much as possible. The current
> directory structure is quite indicative of where the boundaries are
> already. This way, if I make a mess of arch/arm/mach-orion5x/* then you
> just need to pass the blame straight to me.
>

That works okay for the more popular sub-architectures like pxa, etc,
where there are a lot of people to review code and sort out issues
between themselves. However, for the architecture I do most of my work
on, ep93xx, there are basically two of us, Hartley and myself, doing
active work.

It seems a bit dodgy if all the patches to ep93xx are written by one of
us and acked by the other with no input from anybody else. It would be
very easy for the ep93xx code to become and complete mess, and lack any
coherency with the other sub-archs. I prefer having Russell, or somebody
else, at least have a glance at the patches before they get applied.

~Ryan

--
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon Unit 5, Amuri Park
Phone: +64 3 3779127 404 Barbadoes St
Fax: +64 3 3779135 PO Box 13 889
Email: ry...@bluewatersys.com Christchurch, 8013
Web: http://www.bluewatersys.com New Zealand
Freecall Australia 1800 148 751 USA 1800 261 2934

H Hartley Sweeten

unread,

Jun 11, 2009, 5:50:06 PM6/11/09

to

On Thursday, June 11, 2009 2:23 PM, Ryan Mallon wrote:
> Nicolas Pitre wrote:
> > On Thu, 11 Jun 2009, Russell King - ARM Linux wrote:
> >
> > I think that you, as the ARM maintainer, should continue gathering all
> > the ARM subarchitectures into a coherent ARM tree and arbitrate
> > conflicts when they occur. You should especially keep a tight control
> > on the very core ARM code. But everything under arch/arm/mach-* you
> > should let people maintaining those have control of that themselves and
> > free yourself from that responsibility as much as possible. The current
> > directory structure is quite indicative of where the boundaries are
> > already. This way, if I make a mess of arch/arm/mach-orion5x/* then you
> > just need to pass the blame straight to me.
> >
>
> That works okay for the more popular sub-architectures like pxa, etc,
> where there are a lot of people to review code and sort out issues
> between themselves. However, for the architecture I do most of my work
> on, ep93xx, there are basically two of us, Hartley and myself, doing
> active work.
>
> It seems a bit dodgy if all the patches to ep93xx are written by one of
> us and acked by the other with no input from anybody else. It would be
> very easy for the ep93xx code to become and complete mess, and lack any
> coherency with the other sub-archs. I prefer having Russell, or somebody
> else, at least have a glance at the patches before they get applied.

I agree with Ryan.

I review everything Ryan (or others) submit for ep93xx and add my Sign-off-by
or Tested-by as appropriate, I don't think I have every actually added an
Acked-by to any patch (I could be wrong). Ryan does similar for my patches.

Before anything actually gets applied I am much more comfortable with an ok
from Russell and then going through his patch system. The third party makes
sure that we don't do anything silly (or stupid).

Regards,
Hartley

FUJITA Tomonori

unread,

Jun 11, 2009, 9:20:10 PM6/11/09

to

On Thu, 11 Jun 2009 17:42:18 +0100
Russell King - ARM Linux <li...@arm.linux.org.uk> wrote:

> On Thu, Jun 11, 2009 at 06:37:21PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > "No reason given" part was just lovely..
> >
> > After getting a couple of such messages I decided to stay as far away from
> > linux-arm-kernel list as possible..
> >
> > Before interacting with linux-arm-kernel list I really thought that people
> > exaggerated the issue and that their complains were unfounded..
>
> I wish people told me about this - it's certainly not my policy nor
> indeed the policy which should be applied to the list. I'll find out
> what's going on when my co-list admin returns from his vacation.
>
> Thanks for bringing it to my attention.

Here's another example that I got (this mail was about a patch that
touches arm code):

==
On Tue, 12 May 2009 09:49:58 +0100
linux-arm-ke...@lists.arm.linux.org.uk wrote:

> Your request to the Linux-arm-kernel mailing list
>

> Posting of your message titled "Re: [PATCH] remove DMA_nBIT_MASK
> macro"

>
> has been rejected by the list moderator. The moderator gave the
> following reason for rejecting your request:
>

> "Non-members are not allowed to post messages to this list. You have
> to subscribe before you're allowed to post. "

>
> Any questions or comments should be directed to the list administrator
> at:
>
> linux-arm-k...@lists.arm.linux.org.uk
>
>

Jamie Lokier

unread,

Jun 11, 2009, 9:30:15 PM6/11/09

to

Russell King - ARM Linux wrote:

> On Thu, Jun 11, 2009 at 06:37:21PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > "No reason given" part was just lovely..
> >
> > After getting a couple of such messages I decided to stay as far away from
> > linux-arm-kernel list as possible..
> >
> > Before interacting with linux-arm-kernel list I really thought that people
> > exaggerated the issue and that their complains were unfounded..
>
> I wish people told me about this - it's certainly not my policy nor
> indeed the policy which should be applied to the list. I'll find out
> what's going on when my co-list admin returns from his vacation.
>
> Thanks for bringing it to my attention.

Before I subscribed to linux-arm-kernel, I had quite a few moderation
messages just because I responded to threads which included
linux-arm-kernel in the addresses, but were cross-posted (by others)
to say linux-kernel, uclinux-dev or linux-embedded.

I got moderation messages, and found them slightly annoying because
I'd put effort into my replies, and presumed that some people involved
in the thread wouldn't see them. Possibly the important people.

That's the main reason I subscribed to linux-arm-kernel - just so I
know people can see replies to threads that I'm responding to on other
lists.

I do actually work on ARM kernels too, so don't unsubscribe me for that :-)

When I did subscribe to linux-arm-kernel, I got a message telling me I
was being considered... Months went by, and it didn't subscribe me.
That was annoying. I presumed I'd been rejected.

I tried again a few months later, and this time the subscription
approval process was relatively quick at a week or so. I was
beginning to think I'd be silently rejected again, therefore delighted
to be counted among the Special Ones allowed to subscribe :-)

Other Linux mailing lists subscribe quickly with an automated
confirmation process, which is more useful.

-- Jamie

Jamie Lokier

unread,

Jun 11, 2009, 9:30:16 PM6/11/09

to

Russell King - ARM Linux wrote:
> I still operate with email in a way
> which means if I don't deal with something as soon as I see it, it gets
> filed away and almost never looked at again - even if I re-mark the
> message as 'New'. That means if it's inconvenient to apply a patch
> (because the machine with the git trees on is powered down) then the
> patch tends to get lost.

Same here. Can't keep up, never enough time to go back through old
'New' mails.

> But hey, if you want me to drop lots of patches, then sure just send
> them by email. Just expect to nag me a lot more about applying your
> patch.

Thanks for mentioning this. With the huge number of patches sent to
the mailing list these days, I was getting the impression sending to
the list was the thing to do.

-- Jamie

Ryan Mallon

unread,

Jun 11, 2009, 9:30:15 PM6/11/09

to

Nicolas Pitre wrote:

> On Fri, 12 Jun 2009, Ryan Mallon wrote:
>
>> Nicolas Pitre wrote:
>>> On Thu, 11 Jun 2009, Russell King - ARM Linux wrote:
>>>
>>> I think that you, as the ARM maintainer, should continue gathering all
>>> the ARM subarchitectures into a coherent ARM tree and arbitrate
>>> conflicts when they occur. You should especially keep a tight control
>>> on the very core ARM code. But everything under arch/arm/mach-* you
>>> should let people maintaining those have control of that themselves and
>>> free yourself from that responsibility as much as possible. The current
>>> directory structure is quite indicative of where the boundaries are
>>> already. This way, if I make a mess of arch/arm/mach-orion5x/* then you
>>> just need to pass the blame straight to me.
>>>
>> That works okay for the more popular sub-architectures like pxa, etc,
>> where there are a lot of people to review code and sort out issues
>> between themselves. However, for the architecture I do most of my work
>> on, ep93xx, there are basically two of us, Hartley and myself, doing
>> active work.
>>
>> It seems a bit dodgy if all the patches to ep93xx are written by one of
>> us and acked by the other with no input from anybody else. It would be
>> very easy for the ep93xx code to become and complete mess, and lack any
>> coherency with the other sub-archs. I prefer having Russell, or somebody
>> else, at least have a glance at the patches before they get applied.
>

> This is all fine. If you prefer some external help to judge your
> patches that's OK. In fact I'm not advocating for people to stop
> posting their patches to linux-arm-kernel at all. It is a good thing
> for patches to be aired on the mailing list for everyone to see and
> comment.
>
> However if you start gathering more developers around the ep93xx then
> someone should take charge and be responsible for it. And this must not
> necessarily be Russell as his cycles are not infinite.

Thats my point though: In the meantime, it falls on Russell by default
to be the one to verify all the patches going through. I think the same
is true for new architectures, if nobody else has the interest/hardware
besides those posting the patches, then who is meant to do the
reviewing/acking?

Nicolas Pitre

unread,

Jun 11, 2009, 9:30:16 PM6/11/09

to

On Fri, 12 Jun 2009, Ryan Mallon wrote:

> Nicolas Pitre wrote:
> > On Thu, 11 Jun 2009, Russell King - ARM Linux wrote:
> >
> > I think that you, as the ARM maintainer, should continue gathering all
> > the ARM subarchitectures into a coherent ARM tree and arbitrate
> > conflicts when they occur. You should especially keep a tight control
> > on the very core ARM code. But everything under arch/arm/mach-* you
> > should let people maintaining those have control of that themselves and
> > free yourself from that responsibility as much as possible. The current
> > directory structure is quite indicative of where the boundaries are
> > already. This way, if I make a mess of arch/arm/mach-orion5x/* then you
> > just need to pass the blame straight to me.
> >
>
> That works okay for the more popular sub-architectures like pxa, etc,
> where there are a lot of people to review code and sort out issues
> between themselves. However, for the architecture I do most of my work
> on, ep93xx, there are basically two of us, Hartley and myself, doing
> active work.
>
> It seems a bit dodgy if all the patches to ep93xx are written by one of
> us and acked by the other with no input from anybody else. It would be
> very easy for the ep93xx code to become and complete mess, and lack any
> coherency with the other sub-archs. I prefer having Russell, or somebody
> else, at least have a glance at the patches before they get applied.

This is all fine. If you prefer some external help to judge your

patches that's OK. In fact I'm not advocating for people to stop
posting their patches to linux-arm-kernel at all. It is a good thing
for patches to be aired on the mailing list for everyone to see and
comment.

However if you start gathering more developers around the ep93xx then
someone should take charge and be responsible for it. And this must not
necessarily be Russell as his cycles are not infinite.

Nicolas

Ryan Mallon

unread,

Jun 11, 2009, 9:40:11 PM6/11/09

to

Russell King - ARM Linux wrote:

> On Thu, Jun 11, 2009 at 05:00:30AM -0700, David Miller wrote:
>> From: Russell King - ARM Linux <li...@arm.linux.org.uk>
>> Date: Thu, 11 Jun 2009 12:49:12 +0100
>>
>>> I can not keep up with the number of patches that need to be
>>> reviewed and ultimately merged. I know this, and I freely admit it,
>>> and I have done so on many occasions.
>> Then split up the responsibilities to other people instead of being
>> the choke point. Controlling everything isn't so important.
>
> Don't you think that I've been trying to get other people to be more
> involved?
>
> - I've been pushing people to send patches to the relevent mailing
> list(s) and maintainer(s) for years.
>
> - I've been pushing people to send their ARM patches to the ARM
> mailing list rather than directly into the patch system for review
> (it even has a comment telling people this) so that others can get
> involved in reviewing them, and sharing that work load.
>
> Do you think either have been anywhere near successful?
>

> For the most part, the answer is no. People concentrate on their own
> areas, and won't look at someone with a new class of platforms (eg,
> the STMP or W90x900 stuff).
>
> I'd absolutely love it if the review load could be shared, but for the
> most part it just doesn't happen. Everyone's far too busy with their
> own stuff to help out (and that's a reason that they'll give if tackled
> head on about it.)

Question on this: I occasionally review patches where I have the
knowledge or interest. Most of the time however, I do not have the
hardware needed to actually test the patches, and so my reviews are
simply coding style, etc. I don't want to add my acked-by to something I
can't test, or am not at reasonably confident is okay (ie haven't
tested, but know the hardware well enough to be satisfied the patch is
okay by reading it).

The problem I see for developers I do reviews for, is that they post a
patch, I do a code review, the post an update looking for an acked-by,
and the best I can say is "looks okay to me, but get someone else to ack
it". Whats the best approach here? Should I just add my Reviewed-by tag,
or should can/should I ack patches where I think the code is okay, but
can't test.

~Ryan

--
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon Unit 5, Amuri Park
Phone: +64 3 3779127 404 Barbadoes St
Fax: +64 3 3779135 PO Box 13 889
Email: ry...@bluewatersys.com Christchurch, 8013
Web: http://www.bluewatersys.com New Zealand
Freecall Australia 1800 148 751 USA 1800 261 2934

Nicolas Pitre

unread,

Jun 11, 2009, 10:00:11 PM6/11/09

to

On Fri, 12 Jun 2009, Ryan Mallon wrote:

> Nicolas Pitre wrote:
> > This is all fine. If you prefer some external help to judge your
> > patches that's OK. In fact I'm not advocating for people to stop
> > posting their patches to linux-arm-kernel at all. It is a good thing
> > for patches to be aired on the mailing list for everyone to see and
> > comment.
> >
> > However if you start gathering more developers around the ep93xx then
> > someone should take charge and be responsible for it. And this must not
> > necessarily be Russell as his cycles are not infinite.
>
> Thats my point though: In the meantime, it falls on Russell by default
> to be the one to verify all the patches going through. I think the same
> is true for new architectures, if nobody else has the interest/hardware
> besides those posting the patches, then who is meant to do the
> reviewing/acking?

I think that, at some point, if nobody else has the interest/hardware,
then you are on your own. Just make sure that your code respects the
kernel coding style, has no obvious API misuses, and that it does not
affect anyone else. At that point if you can convince people that your
code is actually useful and that you'll be around to quickly respond
if/when issues are reported then it should just be merged.

Nicolas

Brian Swetland

unread,

Jun 11, 2009, 10:20:07 PM6/11/09

to

On Thu, Jun 11, 2009 at 6:51 PM, Nicolas Pitre<ni...@cam.org> wrote:
> On Fri, 12 Jun 2009, Ryan Mallon wrote:
>> Nicolas Pitre wrote:
>>
>> Thats my point though: In the meantime, it falls on Russell by default
>> to be the one to verify all the patches going through. I think the same
>> is true for new architectures, if nobody else has the interest/hardware
>> besides those posting the patches, then who is meant to do the
>> reviewing/acking?
>
> I think that, at some point, if nobody else has the interest/hardware,
> then you are on your own. Just make sure that your code respects the
> kernel coding style, has no obvious API misuses, and that it does not
> affect anyone else. At that point if you can convince people that your
> code is actually useful and that you'll be around to quickly respond
> if/when issues are reported then it should just be merged.

My hope with the msm support is to get buildable, bootable (we're
there now), style-clean (we probably have stuff that needs help yet,
though I think we're improving) support for the platform in the tree
so people can actually build mainline for things like HTC Dream /
Sapphire, Qualcomm's SURF boards, etc.

At that point, I think we'll get more people looking at, testing, and
hopefully contributing and reviewing patches in that domain -- I know
there are a lot of folks out there hacking on ADP1 (the unlocked dev
phone) or "rooted" G1s, and some of them tinker with things at the
kernel level.

From a practical standpoint, some questions about trying to get a
bunch of msm stuff cleaned up possibly for 2.6.31:
- would having some ifdefs around code using wakelock support be
acceptable for the time being? The wakelock/suspendblock review does
seem to be making progress on linux-pm if not super quickly, and I'd
rather maintain some ifdefs than maintain two different versions of
drivers while it's getting sorted out.
- from where we are now, with .30 about to be wrapped up, what's the
reasonable timeline for putting together a patch series for mach-msm
and for drivers/staging/msm7k or the like? When should I be sending
what to where? Presumably to lakml at the least?
- is it essential to completely flatten down to single patches for new
drivers? We do have history including contributions from Qualcomm,
HTC, etc, which would be nice to preserve in some cases, but if that's
impractical, we can do a complete rebase and flatten on top of tip of
tree.

I'd love review/feedback on things -- I think, to Alan's original
suggestion, I just would like to avoid ending up in a holding pattern
on getting support for these SoCs and devices into mainline
(especially if we can do it without breaking anybody else). I do
understand if there aren't a lot of people interested in wading
through the frightening realm of AMSS/QDSP remote interfaces...

Thanks,

Brian

Alan Cox

unread,

Jun 12, 2009, 3:50:13 AM6/12/09

to

> Thats my point though: In the meantime, it falls on Russell by default
> to be the one to verify all the patches going through. I think the same

No it doesn't

> is true for new architectures, if nobody else has the interest/hardware
> besides those posting the patches, then who is meant to do the
> reviewing/acking?

If nobody else is interested then you can do the reviewing/acking because
clearly nobody else cares if you make a mistake. And if they do then
they'll be motivated to add resources to assist you ;)

Alan

Ian Molton

unread,

Jun 12, 2009, 6:30:16 AM6/12/09

to

Brian Swetland wrote:
>
> - would having some ifdefs around code using wakelock support be
> acceptable for the time being? The wakelock/suspendblock review does
> seem to be making progress on linux-pm if not super quickly, and I'd
> rather maintain some ifdefs than maintain two different versions of
> drivers while it's getting sorted out.

Personally, I'd say no.

Use git - create a version with them dropped and then you can create a
wakelock-dev branch on top of that with your new stuff in, which can be
rebased should the underlying branch move on (or get merged with mainline).

Its a problem that wouldnt exist if the original drivers had been
submitted long ago...

Tony Lindgren

unread,

Jun 12, 2009, 6:30:17 AM6/12/09

to

* Nicolas Pitre <ni...@cam.org> [090611 10:30]:

This is what I was thinking too.

Tony

Pavel Machek

unread,

Jun 12, 2009, 6:40:08 AM6/12/09

to

Hi!

> >> Thats my point though: In the meantime, it falls on Russell by default
> >> to be the one to verify all the patches going through. I think the same
> >> is true for new architectures, if nobody else has the interest/hardware
> >> besides those posting the patches, then who is meant to do the
> >> reviewing/acking?
> >
> > I think that, at some point, if nobody else has the interest/hardware,
> > then you are on your own. �Just make sure that your code respects the
> > kernel coding style, has no obvious API misuses, and that it does not
> > affect anyone else. �At that point if you can convince people that your
> > code is actually useful and that you'll be around to quickly respond
> > if/when issues are reported then it should just be merged.
>
> My hope with the msm support is to get buildable, bootable (we're
> there now), style-clean (we probably have stuff that needs help yet,

I still can't get it to boot :-(.

> At that point, I think we'll get more people looking at, testing, and
> hopefully contributing and reviewing patches in that domain -- I know
> there are a lot of folks out there hacking on ADP1 (the unlocked dev
> phone) or "rooted" G1s, and some of them tinker with things at the
> kernel level.
>
> >From a practical standpoint, some questions about trying to get a
> bunch of msm stuff cleaned up possibly for 2.6.31:
> - would having some ifdefs around code using wakelock support be
> acceptable for the time being? The wakelock/suspendblock review does
> seem to be making progress on linux-pm if not super quickly, and I'd
> rather maintain some ifdefs than maintain two different versions of
> drivers while it's getting sorted out.

#ifdefs are too ugly, I'm afraid. And there will be need for for
second tree, at least temporarily.

> - from where we are now, with .30 about to be wrapped up, what's the
> reasonable timeline for putting together a patch series for mach-msm
> and for drivers/staging/msm7k or the like? When should I be sending
> what to where? Presumably to lakml at the least?

Well, I guess "start ASAP and maybe we can make it into .32".

> - is it essential to completely flatten down to single patches for new
> drivers? We do have history including contributions from Qualcomm,
> HTC, etc, which would be nice to preserve in some cases, but if that's
> impractical, we can do a complete rebase and flatten on top of tip of
> tree.

I guess preserving history is not top priority.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Brian Swetland

unread,

Jun 12, 2009, 6:50:07 AM6/12/09

to

On Fri, Jun 12, 2009 at 3:35 AM, Pavel Machek<pa...@ucw.cz> wrote:
>>
>> My hope with the msm support is to get buildable, bootable (we're
>> there now), style-clean (we probably have stuff that needs help yet,
>
> I still can't get it to boot :-(.

I think the cupcake userspace and the latest 2.6.29 kernel aren't
getting along. I'm putting together instructions for building a
minimal userspace (what we call tiny android -- and what I use for
bringup and kernel testing), and once I've had a chance to verify that
everything works end-to-end with the latest kernel, donut branch, and
have verified this on ADP1, I'll send an update. Probably some time
over the weekend.

Brian