Re: [PATCH] staging: vme_user: fix check alignment should match open parenthesis

[Alexon Oliveira]

On Fri, Jul 28, 2023 at 08:59:12PM +0300, Dan Carpenter wrote:
> On Fri, Jul 28, 2023 at 02:43:12PM -0300, Alexon Oliveira wrote:
> > On Fri, Jul 28, 2023 at 08:24:56AM +0300, Dan Carpenter wrote:
> > > On Thu, Jul 27, 2023 at 02:37:54PM -0300, Alexon Oliveira wrote:
> > > > > 
> > > > > I would have thought you would get a "line is too long" warning, that
> > > > > didn't happen?
> > > > $ pwd
> > > > /home/alolivei/git/kernels/staging
> > > > $ perl scripts/checkpatch.pl --strict -f drivers/staging/vme_user/vme_bridge.h | grep -i parenthesis
> > > > $ 
> > > > Nope. I didn't get any of that. Check it out:
> > > 
> > > Heh.  The warning is there but you used grep to remove it.
> > > 
> > 
> > I only used grep so as not to pollute my answer with too long
> > output, but you can validate the full output by running the following:
> > 
> > curl -ks https://people.redhat.com/alolivei/kernel/evidence
> > 
> > You'll see there's no warning related to this patch.
> 
> I checked before I emailed you...  The warning is there in your URL as
> well.
> 
> CHECK: line length of 121 exceeds 100 columns
> #133: FILE: drivers/staging/vme_user/vme_bridge.h:133:
> +	int (*slave_set)(struct vme_slave_resource *, int, unsigned long long, unsigned long long, dma_addr_t, u32, u32);
> 

It took me some time to finally understand your observation and now I
get it. I was able to identify these same new warnings. Thank you for
your patience in explaining that out to me.

> > As I mentioned, there are other warnings that were already there before
> > I submitted the patch, and I didn't touch them (yet).
> 
> No, these warnings are new.  Here are the relevant lines from the diff.
> Originally it was short and now it's a bajillion characters long.
> 
> -       int (*slave_set)(struct vme_slave_resource *, int, unsigned long long,
> -               unsigned long long, dma_addr_t, u32, u32);
> +       int (*slave_set)(struct vme_slave_resource *, int, unsigned long long, unsigned long long, dma_addr_t, u32, u32);
> 

You're correct (as so Greg). I've already applied the necessary fixes to
that and I'm submitting a v2 patch with these changes. Again, thank you
for your feedback and help.

> regards,
> dan carpenter
> 

Thank you.

Alexon Oliveira