Re: HTC Dream aka. t-mobile g1 support
From: Pavel Machek
Date: Fri Jun 12 2009 - 06:35:42 EST
> >> 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
I guess preserving history is not top priority.
(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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/