Message-ID: <a55d774e0906111916y2f49e5a9q362e12b52fb5414a@mail.gmail.com>
Date:	Thu, 11 Jun 2009 19:16:29 -0700
From:	Brian Swetland <swetland@...gle.com>
To:	Nicolas Pitre <nico@....org>
Cc:	Ryan Mallon <ryan@...ewatersys.com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Tony Lindgren <tony@...mide.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	David Miller <davem@...emloft.net>, pavel@....cz,
	lkml <linux-kernel@...r.kernel.org>,
	linux-arm-kernel@...ts.arm.linux.org.uk, san@...roid.com,
	rlove@...gle.com
Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu, Jun 11, 2009 at 6:51 PM, Nicolas Pitre<nico@....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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists