Re: [PATCH] staging: vme_user: fix check alignment should match open parenthesis
From: Alexon Oliveira
Date: Tue Aug 01 2023 - 11:53:41 EST
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