linux-kernel - Re: [RFC PATCH 1/1] input/touchscreen: Synaptics 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 for Android: free password hash cracker in your pocket

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

Message-ID: <20100308083605.GC14856@core.coreip.homeip.net>
Date:	Mon, 8 Mar 2010 00:36:06 -0800
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Christopher Heiny <cheiny@...aptics.com>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>,
	Allie Xiong <axiong@...aptics.com>,
	William Manson <WManson@...aptics.com>
Subject: Re: [RFC PATCH 1/1] input/touchscreen: Synaptics Touchscreen Driver

On Thu, Mar 04, 2010 at 05:16:09PM -0800, Christopher Heiny wrote:
> On 03/02/2010 01:12 AM, Dmitry Torokhov wrote:
> >Hi Christofer,
> >
> >I assume that since you sent it with git-send-email it was your
> >corporate mail server that murdered all identation and whitespace.
> >Please try sending next version using alternative server, like gmail or
> >maybe your personal account. On the off chance that the formatting used
> >in the driver was preserved intact - please remember that kernel uses
> >hard tabs for identation (8 chars, no expanding). Camel-casing is also
> >frowned upon.
> 
> Actually, the strange indenting/whitespace is due to a day-long struggle
> with checkpatch.pl to get it to accept something - anything - without
> complaining.  Personally I thought the formatting that checkpatch
> finally accepted was kind of strange, but went with it.
> 
> We'll update to 8-space hard tabs only, and ignore any future
> checkpatch complaints in that department.

Umm, generally speaking checkpatch is "telling the truth" and if you run
it aginst most of the krenle code you shold get very few complaints. The
only thing I tend to ignore is the 80 column limit (which I think is
being liften in recent version).

Also, while you are at it - consider using dev_xxx() for printing
messages when you have 'struct device *' available and pr_xxx() when you
do not have it instead of using "naked" printks.

Thanks.

-- 
Dmitry
--
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/