| Message ID | 20220122012736.2725994-2-sjg@chromium.org |
|---|---|
| State | Superseded |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | Fix compiler warnings for 32-bit ARM | expand |
On Fri, Jan 21, 2022 at 06:27:33PM -0700, Simon Glass wrote: > From: Joe Perches <joe@perches.com> > > Allow prefixing typical strings with L for wide strings and u for > unicode strings. > > Signed-off-by: Joe Perches <joe@perches.com> > Signed-off-by: Simon Glass <sjg@chromium.org> > --- > This was found on LKML: > > https://lore.kernel.org/lkml/1508280192.6530.31.camel@perches.com/T/ > > It likely wasn't applied because it did not show up in patchwork > correctly, due to the patch being inline: > > https://lore.kernel.org/patchwork/patch/842121/ > > In any case, it needed rebasing and updating to support 'u'. > > I sent this upstream: > > https://lore.kernel.org/patchwork/patch/1470668/ And this is now: commit d2af5aa6c036d3fd2c1ff3379ffe3e6805929952 Author: Joe Perches <joe@perches.com> Date: Tue Sep 7 19:59:51 2021 -0700 checkpatch: support wide strings Allow prefixing typical strings with L for wide strings and u for unicode strings. upstream and in v5.16. Time for a direct resync again?
Hi Tom, On Sun, 23 Jan 2022 at 07:54, Tom Rini <trini@konsulko.com> wrote: > > On Fri, Jan 21, 2022 at 06:27:33PM -0700, Simon Glass wrote: > > > From: Joe Perches <joe@perches.com> > > > > Allow prefixing typical strings with L for wide strings and u for > > unicode strings. > > > > Signed-off-by: Joe Perches <joe@perches.com> > > Signed-off-by: Simon Glass <sjg@chromium.org> > > --- > > This was found on LKML: > > > > https://lore.kernel.org/lkml/1508280192.6530.31.camel@perches.com/T/ > > > > It likely wasn't applied because it did not show up in patchwork > > correctly, due to the patch being inline: > > > > https://lore.kernel.org/patchwork/patch/842121/ > > > > In any case, it needed rebasing and updating to support 'u'. > > > > I sent this upstream: > > > > https://lore.kernel.org/patchwork/patch/1470668/ > > And this is now: > commit d2af5aa6c036d3fd2c1ff3379ffe3e6805929952 > Author: Joe Perches <joe@perches.com> > Date: Tue Sep 7 19:59:51 2021 -0700 > > checkpatch: support wide strings > > Allow prefixing typical strings with L for wide strings and u for unicode > strings. > > upstream and in v5.16. Time for a direct resync again? How about taking this patch so this long-standing series can go in and I can forget about it? If you like I can do a patch to resync checkpatch. Do you think we should try to send the U-Boot things upstream? Regards, Simon
On Sun, Jan 23, 2022 at 09:03:16AM -0700, Simon Glass wrote: > Hi Tom, > > On Sun, 23 Jan 2022 at 07:54, Tom Rini <trini@konsulko.com> wrote: > > > > On Fri, Jan 21, 2022 at 06:27:33PM -0700, Simon Glass wrote: > > > > > From: Joe Perches <joe@perches.com> > > > > > > Allow prefixing typical strings with L for wide strings and u for > > > unicode strings. > > > > > > Signed-off-by: Joe Perches <joe@perches.com> > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > > --- > > > This was found on LKML: > > > > > > https://lore.kernel.org/lkml/1508280192.6530.31.camel@perches.com/T/ > > > > > > It likely wasn't applied because it did not show up in patchwork > > > correctly, due to the patch being inline: > > > > > > https://lore.kernel.org/patchwork/patch/842121/ > > > > > > In any case, it needed rebasing and updating to support 'u'. > > > > > > I sent this upstream: > > > > > > https://lore.kernel.org/patchwork/patch/1470668/ > > > > And this is now: > > commit d2af5aa6c036d3fd2c1ff3379ffe3e6805929952 > > Author: Joe Perches <joe@perches.com> > > Date: Tue Sep 7 19:59:51 2021 -0700 > > > > checkpatch: support wide strings > > > > Allow prefixing typical strings with L for wide strings and u for unicode > > strings. > > > > upstream and in v5.16. Time for a direct resync again? > > How about taking this patch so this long-standing series can go in and > I can forget about it? > > If you like I can do a patch to resync checkpatch. Do you think we > should try to send the U-Boot things upstream? A re-sync should be easy now that (almost?) all of the U-Boot stuff is in one hunk and I would rather see a re-sync than backporting individual changes.
On Sun, 2022-01-23 at 09:03 -0700, Simon Glass wrote: > Do you think we > should try to send the U-Boot things upstream? No idea. What are the U-Boot things that could or should be generic ? https://source.denx.de/u-boot/u-boot/-/commits/master/scripts/checkpatch.pl
On Sun, Jan 23, 2022 at 08:10:37AM -0800, Joe Perches wrote: > On Sun, 2022-01-23 at 09:03 -0700, Simon Glass wrote: > > > Do you think we > > should try to send the U-Boot things upstream? > > No idea. What are the U-Boot things that could or should be generic ? > > https://source.denx.de/u-boot/u-boot/-/commits/master/scripts/checkpatch.pl Honestly? I think we got everything that was generic pushed upstream first these days and it's just U-Boot centric checks in the u_boot_* functions.
On Sun, 2022-01-23 at 11:19 -0500, Tom Rini wrote: > On Sun, Jan 23, 2022 at 08:10:37AM -0800, Joe Perches wrote: > > On Sun, 2022-01-23 at 09:03 -0700, Simon Glass wrote: > > > > > Do you think we > > > should try to send the U-Boot things upstream? > > > > No idea. What are the U-Boot things that could or should be generic ? > > > > https://source.denx.de/u-boot/u-boot/-/commits/master/scripts/checkpatch.pl > > Honestly? Do you honestly think I normally look at or care about u-boot ? > I think we got everything that was generic pushed upstream > first these days and it's just U-Boot centric checks in the u_boot_* > functions. Fine by me.
Hi Joe, On Sun, 23 Jan 2022 at 09:27, Joe Perches <joe@perches.com> wrote: > > On Sun, 2022-01-23 at 11:19 -0500, Tom Rini wrote: > > On Sun, Jan 23, 2022 at 08:10:37AM -0800, Joe Perches wrote: > > > On Sun, 2022-01-23 at 09:03 -0700, Simon Glass wrote: > > > > > > > Do you think we > > > > should try to send the U-Boot things upstream? > > > > > > No idea. What are the U-Boot things that could or should be generic ? > > > > > > https://source.denx.de/u-boot/u-boot/-/commits/master/scripts/checkpatch.pl > > > > Honestly? > > Do you honestly think I normally look at or care about u-boot ? > > > I think we got everything that was generic pushed upstream > > first these days and it's just U-Boot centric checks in the u_boot_* > > functions. > > Fine by me. > It is just one perl function enabled by a --u-boot flag, so if you don't mind, it would be convenient to upstream it. Regards, Simon
On Sun, 2022-01-23 at 13:12 -0700, Simon Glass wrote: > Hi Joe, > > On Sun, 23 Jan 2022 at 09:27, Joe Perches <joe@perches.com> wrote: > > > > On Sun, 2022-01-23 at 11:19 -0500, Tom Rini wrote: > > > On Sun, Jan 23, 2022 at 08:10:37AM -0800, Joe Perches wrote: > > > > On Sun, 2022-01-23 at 09:03 -0700, Simon Glass wrote: > > > > > > > > > Do you think we > > > > > should try to send the U-Boot things upstream? > > > > > > > > No idea. What are the U-Boot things that could or should be generic ? > > > > > > > > https://source.denx.de/u-boot/u-boot/-/commits/master/scripts/checkpatch.pl > > > > > > Honestly? > > > > Do you honestly think I normally look at or care about u-boot ? > > > > > I think we got everything that was generic pushed upstream > > > first these days and it's just U-Boot centric checks in the u_boot_* > > > functions. > > > > Fine by me. > > > > It is just one perl function enabled by a --u-boot flag, so if you > don't mind, it would be convenient to upstream it. You could send a patch for review.
Hi Joe, On Mon, 24 Jan 2022 at 18:04, Joe Perches <joe@perches.com> wrote: > > On Sun, 2022-01-23 at 13:12 -0700, Simon Glass wrote: > > Hi Joe, > > > > On Sun, 23 Jan 2022 at 09:27, Joe Perches <joe@perches.com> wrote: > > > > > > On Sun, 2022-01-23 at 11:19 -0500, Tom Rini wrote: > > > > On Sun, Jan 23, 2022 at 08:10:37AM -0800, Joe Perches wrote: > > > > > On Sun, 2022-01-23 at 09:03 -0700, Simon Glass wrote: > > > > > > > > > > > Do you think we > > > > > > should try to send the U-Boot things upstream? > > > > > > > > > > No idea. What are the U-Boot things that could or should be generic ? > > > > > > > > > > https://source.denx.de/u-boot/u-boot/-/commits/master/scripts/checkpatch.pl > > > > > > > > Honestly? > > > > > > Do you honestly think I normally look at or care about u-boot ? > > > > > > > I think we got everything that was generic pushed upstream > > > > first these days and it's just U-Boot centric checks in the u_boot_* > > > > functions. > > > > > > Fine by me. > > > > > > > It is just one perl function enabled by a --u-boot flag, so if you > > don't mind, it would be convenient to upstream it. > > You could send a patch for review. > OK I sent it to lkml and cc'd you. I cannot find where it appears on patchwork though. Regards, Simon
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index cf59e2bb705..c1307f4361c 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -504,7 +504,7 @@ our $Binary = qr{(?i)0b[01]+$Int_type?}; our $Hex = qr{(?i)0x[0-9a-f]+$Int_type?}; our $Int = qr{[0-9]+$Int_type?}; our $Octal = qr{0[0-7]+$Int_type?}; -our $String = qr{"[X\t]*"}; +our $String = qr{(?:\b[Lu])?"[X\t]*"}; our $Float_hex = qr{(?i)0x[0-9a-f]+p-?[0-9]+[fl]?}; our $Float_dec = qr{(?i)(?:[0-9]+\.[0-9]*|[0-9]*\.[0-9]+)(?:e-?[0-9]+)?[fl]?}; our $Float_int = qr{(?i)[0-9]+e-?[0-9]+[fl]?}; @@ -6242,7 +6242,8 @@ sub process { } # concatenated string without spaces between elements - if ($line =~ /$String[A-Za-z0-9_]/ || $line =~ /[A-Za-z0-9_]$String/) { + if ($line =~ /$String[A-Z_]/ || + ($line =~ /([A-Za-z0-9_]+)$String/ && $1 !~ /^[Lu]$/)) { if (CHK("CONCATENATED_STRING", "Concatenated strings should use spaces between elements\n" . $herecurr) && $fix) { @@ -6255,7 +6256,7 @@ sub process { } # uncoalesced string fragments - if ($line =~ /$String\s*"/) { + if ($line =~ /$String\s*[Lu]?"/) { if (WARN("STRING_FRAGMENTS", "Consecutive strings are generally better as a single string\n" . $herecurr) && $fix) {