linux-kernel - Re: HTC Dream aka. t-mobile g1 support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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/