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
| ||
|
Date: Mon, 27 Aug 2012 17:12:11 -0700 From: Linus Walleij <linus.walleij@...aro.org> To: Christopher Heiny <cheiny@...aptics.com> Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>, Jean Delvare <khali@...ux-fr.org>, Linux Kernel <linux-kernel@...r.kernel.org>, Linux Input <linux-input@...r.kernel.org>, Allie Xiong <axiong@...aptics.com>, William Manson <wmanson@...aptics.com>, Peichen Chang <peichen.chang@...aptics.com>, Joerie de Gram <j.de.gram@...il.com>, Wolfram Sang <w.sang@...gutronix.de>, Mathieu Poirier <mathieu.poirier@...aro.org>, Linus Walleij <linus.walleij@...ricsson.com>, Naveen Kumar Gaddipati <naveen.gaddipati@...ricsson.com> Subject: Re: [RFC PATCH 00/11] input: Synaptics RMI4 Touchscreen Driver On Mon, Aug 27, 2012 at 4:20 PM, Christopher Heiny <cheiny@...aptics.com> wrote: > EARLY_SUSPEND/LATE_RESUME and other power management stuff. We're caught in > a bind here. Most of our customers are using some flavor of Android. They > have the expectation that our driver will (a) support the Android power > management model, and (b) be contributed into the mainline kernel without > change. Yes, I know these are contradictory requirements, given that > Android specific features are not in the mainline. > > With the upcoming rebase of the code to more modern kernels, we'll be able > to eliminate a bunch of those dependencies. But the only way to eliminate > them entirely would be to maintain mainline and Android versions of the > driver, which would drain resources from developing core features and fixing > bugs. So for now we've got a single code base. When we finally submit a > patch and the only response is "everything is fine but that Android stuff", > we'll probably change that policy within 48 hours (to include time needed > for celebration and subsequent hangover recovery :-) ). I'd suggest you rebase and test them with Android and the android hooks all over the place, but when you send it out to community, remove these #ifdef sections. This way the delta between what's in the mainline kernel and what you're maintaining internally will ideally be reduced to a few Android-enablement patches. But it's all up to the subsystem maintainer, so I'd ask Dmitry about this. By the way, this patch set has come a long way, and I would suggest to try merging core support and touch to begin with, so you have the core in place, then you can work on individual function drivers one at a time. This would make the patch bombs a bit smaller. Yours, Linus Walleij -- 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