Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sun, 25 Jul 2021 12:43:54 +0100
From:   Chris Down <chris@chrisdown.name>
To:     Ma Feng <mafeng.ma@huawei.com>
Cc:     kbuild-all@lists.01.org, linux-kernel@vger.kernel.org,
        Petr Mladek <pmladek@suse.com>
Subject: Re: [printk:for-5.15-printk-index 4/8]
 drivers/media/usb/pvrusb2/pvrusb2-encoder.c:288 pvr2_encoder_cmd() warn:
 inconsistent indenting
Message-ID: <YP1OeodZim+HUL+I@chrisdown.name>
References: <202107250913.OiKJhpRZ-lkp@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <202107250913.OiKJhpRZ-lkp@intel.com>
User-Agent: Mutt/2.1 (4b100969) (2021-06-12)
Precedence: bulk

Hey there,

kernel test robot writes:
>smatch warnings:
>drivers/media/usb/pvrusb2/pvrusb2-encoder.c:288 pvr2_encoder_cmd() warn: inconsistent indenting
>drivers/media/usb/pvrusb2/pvrusb2-hdw.c:1730 pvr2_hdw_set_streaming() warn: inconsistent indenting
>drivers/media/usb/pvrusb2/pvrusb2-hdw.c:3461 pvr2_hdw_cpufw_set_enabled() warn: inconsistent indenting
>drivers/media/usb/pvrusb2/pvrusb2-hdw.c:3501 pvr2_hdw_cpufw_get() warn: inconsistent indenting
>
>vim +288 drivers/media/usb/pvrusb2/pvrusb2-encoder.c
>
>[...]
>1ad371deb9b0be drivers/media/usb/pvrusb2/pvrusb2-encoder.c   Mauro Carvalho Chehab 2017-06-26  191  	LOCK_TAKE(hdw->ctl_lock); while (1) {
>[...]
>11c48e41d5fcc5 drivers/media/usb/pvrusb2/pvrusb2-encoder.c   Ma Feng               2019-12-19  287  	}
>11c48e41d5fcc5 drivers/media/usb/pvrusb2/pvrusb2-encoder.c   Ma Feng               2019-12-19 @288  	LOCK_GIVE(hdw->ctl_lock);

Ok, so it looks like it's complaining that LOCK_TAKE and LOCK_GIVE are somewhat 
unbalanced in indenting. Which... they are. I don't really see what this has to 
do with the printk indexing patchset.

I tried to reproduce myself, but spatch just segfaults when trying to read 
drivers/media/usb/pvrusb2/pvrusb2-encoder.c under CHECK=, before _and_ after...

There is a pr_info user in here, pvr2_trace, which may be related, but honestly 
I'm not seeing how the printk indexing patchset could materially change this, 
and not having a repro is frustrating.

All of the reported places are just LOCK_GIVE, which is just a mutex unlock, 
nothing to do with printk:

     % sed -n 288p drivers/media/usb/pvrusb2/pvrusb2-encoder.c
             LOCK_GIVE(hdw->ctl_lock);
     % sed -n '1730p;3461p;3501p' drivers/media/usb/pvrusb2/pvrusb2-hdw.c
             } while (0); LOCK_GIVE(hdw->big_lock);
             } while (0); LOCK_GIVE(hdw->big_lock);
             } while (0); LOCK_GIVE(hdw->big_lock);

...where...

     #define LOCK_TAKE(x) do { mutex_lock(&x##_mutex); x##_held = !0; } while (0)
     #define LOCK_GIVE(x) do { x##_held = 0; mutex_unlock(&x##_mutex); } while (0)

Ma Feng, looks like you were already cleaning this up, judging by 11c48e41d5 
("media: pvrusb2: Remove unneeded semicolon and add newline"), maybe you have 
some suggestions? I really don't see what it has to do with the printk indexing 
patchset, although if I had a local repro it would help.

Thanks,

Chris

>:::::: The code at line 288 was first introduced by commit
>:::::: 11c48e41d5fcc5b4cf17aa74388be128ca5444f8 media: pvrusb2: Remove unneeded semicolon and add newline
>
>:::::: TO: Ma Feng <mafeng.ma@huawei.com>
>:::::: CC: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
>
>---
>0-DAY CI Kernel Test Service, Intel Corporation
>https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org