[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090612103521.GD18682@elf.ucw.cz>
Date: Fri, 12 Jun 2009 12:35:21 +0200
From: Pavel Machek <pavel@....cz>
To: Brian Swetland <swetland@...gle.com>
Cc: Nicolas Pitre <nico@....org>, 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>,
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
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
--
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