mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Brian Swetland <swetland@google.com>
To: Bryan Wu <bryan.wu@canonical.com>
Cc: Greg KH <gregkh@suse.de>, Eric Miao <eric.miao@canonical.com>,
	kernel-team@lists.ubuntu.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Staging: Android logger: fix compiling error
Date: Wed, 28 Oct 2009 19:22:28 -0700	[thread overview]
Message-ID: <a55d774e0910281922l2c84f7d5tdda6666878ece78a@mail.gmail.com> (raw)
In-Reply-To: <4AE8F604.2090005@canonical.com>

On Wed, Oct 28, 2009 at 6:55 PM, Bryan Wu <bryan.wu@canonical.com> wrote:
>>> But now, it is hard for us to do that without a workable Android drivers
>>> in mainline.
>>
>> Then push on Google to get them cleaned up and fixed!  Or do it
>> yourself, all I need is a developer to take ownership of the code.
>
> I'm doing a task which is trying to merge Android patches to Ubuntu kernel
> and mainline, not only the Android drivers but also the ARM port code which
> is not in mainline.
>
> But since Android kernel is 2.6.29 and ours or mainline is 2.6.31+, you know
> it needs much more effort without Google's help.
>
> And for sure, I'm very happy to help this out.

We (Google) definitely want to get back in sync with mainline (as I've
mentioned earlier in this or a related thread), and we're planning on
snapping up our kernel trees to 2.6.32+ once we get past various
deadlines in the near future.  Obviously action speaks louder than
words here, and I understand Greg's frustration at the slow pace so
far and appreciate his efforts to encourage us to stop dropping the
ball.

Probably the two biggest pain points for general driver support are
wakelocks (which we were making some progress on getting cleaned up on
the linux-pm list -- Arve will be respinning those patchsets for
review again before long) and some of the gpio support.  Otherwise,
most of the drivers don't have a lot of dependencies on new core
kernel infrastructure and many effectively stand alone.  For some of
the qualcomm chipsets, there is a fair bit of layering needed for
functions owned by the modem or dsp cores -- smem / smd / rpc / etc.

Brian

  reply	other threads:[~2009-10-29  2:22 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-23 16:52 Bryan Wu
2009-10-27  4:40 ` Eric Miao
2009-10-27  4:42   ` Bryan Wu
2009-10-27 14:05   ` Greg KH
2009-10-29  1:01     ` Bryan Wu
2009-10-29  1:04       ` Greg KH
2009-10-29  1:11         ` Bryan Wu
2009-10-29  1:17           ` Greg KH
2009-10-29  1:27             ` Bryan Wu
2009-10-29  1:28               ` Greg KH
2009-10-29  1:55                 ` Bryan Wu
2009-10-29  2:22                   ` Brian Swetland [this message]
2009-10-30 14:08                   ` Pavel Machek
2009-11-01 16:40                     ` Bryan Wu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a55d774e0910281922l2c84f7d5tdda6666878ece78a@mail.gmail.com \
    --to=swetland@google.com \
    --cc=bryan.wu@canonical.com \
    --cc=eric.miao@canonical.com \
    --cc=gregkh@suse.de \
    --cc=kernel-team@lists.ubuntu.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®