linux-kernel - Re: [RFC PATCH 00/11] input: Synaptics RMI4 Touchscreen Driver

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]

Message-ID: <CACRpkdZs1V3S0gDxZqnq-fzP6SRzTwftuFhG_zwci_MvHbUM6A@mail.gmail.com>
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/