linux-kernel - Re: [PATCH v6] staging: media: atomisp: apply clang-format and fix checkpatch.pl errors

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: <CAKEtaPCibkPWtkRi5xJr8__jzsoPwrrb7LaG3p7_kTK-R5p6gQ@mail.gmail.com>
Date: Sat, 28 Jun 2025 11:16:47 +0800
From: 王良丞 <zaq14760@...il.com>
To: Andy Shevchenko <andriy.shevchenko@...el.com>
Cc: Hans de Goede <hansg@...nel.org>, Mauro Carvalho Chehab <mchehab@...nel.org>, 
	Sakari Ailus <sakari.ailus@...ux.intel.com>, Andy Shevchenko <andy@...nel.org>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Nathan Chancellor <nathan@...nel.org>, 
	Nick Desaulniers <nick.desaulniers+lkml@...il.com>, Bill Wendling <morbo@...gle.com>, 
	Justin Stitt <justinstitt@...gle.com>, linux-media@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-staging@...ts.linux.dev, 
	llvm@...ts.linux.dev
Subject: Re: [PATCH v6] staging: media: atomisp: apply clang-format and fix
 checkpatch.pl errors

Dear Hans, Andy, and all,

Thank you for the detailed feedback.

I understand the patch is too large and unreviewable in its current
form. I also see now that splitting the clang-format changes and the
manual checkpatch.pl ERROR fixes into separate patches would make it
clearer and easier to review. I will also avoid touching any files
under drivers/staging/media/i2c/ and any other parts where future
plans involve rewriting or upstream work.

For the next version (v7), I plan to:

Separate the clang-format automated changes into a standalone patch.

Place the manual checkpatch.pl ERROR fixes into another patch.

Remove any changes in drivers/staging/media/i2c/ and leave those untouched.

Ensure that style changes such as macro alignment or tab changes
respect the existing code style and preferences.

I appreciate your guidance on this and will prepare the updated series
accordingly.

Best regards,
LiangCheng Wang

Andy Shevchenko <andriy.shevchenko@...el.com> 於 2025年6月28日 週六 上午12:18寫道：
>
> On Fri, Jun 27, 2025 at 06:05:08PM +0200, Hans de Goede wrote:
> > On 27-Jun-25 4:56 PM, LiangCheng Wang wrote:
>
> ...
>
> >       for (i = 0; i < count; i++) {
> > -             err = i2c_smbus_write_byte_data(client, reglist[i].reg, reglist[i].val);
> > +             err = i2c_smbus_write_byte_data(client, reglist[i].reg,
> > +                                             reglist[i].val);
> >               if (err) {
> > -                     dev_err(&client->dev, "write error: wrote 0x%x to offset 0x%x error %d",
> >
> > The original line here had a length below 100 chars, so it was fine
> > and log messages are allowed to go over the length limit
>
> Actually I tend to agree with clang-format on this case and that's why:
> until V4L2 becomes less pedantic and fanatic about 80 characters
> limit, the 100 is not applicable for this driver to be moved under
> their umbrella.
>
> > +                     dev_err(&client->dev,
> > +                             "write error: wrote 0x%x to offset 0x%x error %d",
> >                               reglist[i].val, reglist[i].reg, err);
> >                       return err;
> >               }
>
> --
> With Best Regards,
> Andy Shevchenko
>
>