linux-kernel - Re: [PATCH v10] staging: fbtft: add tearing signal detect

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: <3f7b25d21c10a4dc7da5d507d6d6a6a5bc93447b.camel@perches.com>
Date:   Wed, 27 Jan 2021 09:42:56 -0800
From:   Joe Perches <joe@...ches.com>
To:     Dan Carpenter <dan.carpenter@...cle.com>,
        Greg KH <gregkh@...uxfoundation.org>
Cc:     carlis <zhangxuezhi3@...il.com>,
        Andy Whitcroft <apw@...onical.com>, devel@...verdev.osuosl.org,
        linux-fbdev@...r.kernel.org, mh12gx2825@...il.com,
        oliver.graute@...oconnector.com, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, sbrivio@...hat.com,
        colin.king@...onical.com, zhangxuezhi1@...ong.com
Subject: Re: [PATCH v10] staging: fbtft: add tearing signal detect

On Wed, 2021-01-27 at 17:49 +0300, Dan Carpenter wrote:
> On Wed, Jan 27, 2021 at 03:25:20PM +0100, Greg KH wrote:

> > Andy and Joe, there's something wrong here that is missing the fact that
> > a line is being indented with spaces and not tabs in the patch
> > at https://lore.kernel.org/r/1611754972-151016-1-git-send-email-zhangxuezhi3@gmail.com
> > 
> > Any ideas what broke?
> 
>     /*Tearing Effect Line On*/
> 
> Comments are the exception to the "no spaces at the start of a line"
> rule.  I was expecting that the kbuild-bot would send a Smatch warning
> for inconsistent indenting, but comments are not counted there either.
> 
> I'm sort of surprised that we don't have checkpatch rule about the
> missing space characters.  It should be: "/* Tearing Effect Line On */".

You could always write your own rule...

checkpatch doesn't care if a comment looks like

    /********************/
or
    /*foobarfoobarfoobar*/