On Mon, 2024-04-29 at 12:49 -0700, Kees Cook wrote:
> On Mon, Apr 29, 2024 at 06:39:28PM +, Justin Stitt wrote:
> > I am going to quote Lee Jones who has been doing some snprintf ->
> > scnprintf refactorings:
> >
> > "There is a general misunderstanding amongst engineers that
> >
On Mon, 2024-04-15 at 16:10 +, Abhinav Jain wrote:
> Add a pr_err() to print the add device error in find_device_iter()
[]
> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
[]
> @@ -885,7 +885,8 @@ static int find_device_iter(struct pci_dev *dev, void
> *data)
> /*
On Thu, 2024-04-11 at 22:01 +0200, Christophe JAILLET wrote:
> Le 08/04/2024 à 22:53, Justin Stitt a écrit :
> > I am going to quote Lee Jones who has been doing some snprintf ->
> > scnprintf refactorings:
> >
> > "There is a general misunderstanding amongst engineers that
> > {v}snprintf()
On Tue, 2024-04-02 at 22:43 +, Nicolas Devos wrote:
> This commit fixes following checkpatch warning:
> WARNING: Missing or malformed SPDX-License-Identifier tag
NAK without specific agreement from Intel.
The existing license in the file is neither GPL nor MIT
>
> Signed-off-by: Nicolas
On Fri, 2024-02-23 at 10:38 +, Lee Jones wrote:
> On Wed, 21 Feb 2024, Joe Perches wrote:
>
> > On Wed, 2024-02-21 at 22:11 +, Justin Stitt wrote:
> > > I am going to quote Lee Jones who has been doing some snprintf ->
> > > scnprintf refactorings:
On Wed, 2024-02-21 at 22:11 +, Justin Stitt wrote:
> I am going to quote Lee Jones who has been doing some snprintf ->
> scnprintf refactorings:
>
> "There is a general misunderstanding amongst engineers that
> {v}snprintf() returns the length of the data *actually* encoded into the
>
On Fri, 2024-02-09 at 22:56 -0800, Kees Cook wrote:
> On Thu, Feb 08, 2024 at 05:49:12PM +, Lee Jones wrote:
> > On Thu, 08 Feb 2024, Bart Van Assche wrote:
> >
> > > On 2/8/24 00:44, Lee Jones wrote:
> > > > Cc: Andre Hedrick
> > >
> > > Please take a look at
On Mon, 2024-01-08 at 11:24 +0100, Jocelyn Falempe wrote:
> Hi checkpatch maintainers,
>
> This patch gives me the following checkpatch error:
>
> ERROR: Macros with complex values should be enclosed in parentheses
> #30: FILE: include/drm/drm_plane.h:959:
> +#define
On Sun, 2023-12-17 at 13:24 +, Jonathan Cameron wrote:
> On Mon, 11 Dec 2023 22:30:12 -0800
> Joe Perches wrote:
>
> > On Tue, 2023-12-12 at 00:42 +, Justin Stitt wrote:
> > > We're doing some needless string copies when trying to assign the proper
> > >
On Tue, 2023-12-12 at 00:42 +, Justin Stitt wrote:
> We're doing some needless string copies when trying to assign the proper
> `prop` string. We can make `prop` a const char* and simply assign to
> string literals.
trivia:
I would have updated it like this moving the
various declarations
On Wed, 2023-12-06 at 18:23 +0200, Nikolai Kondrashov wrote:
> On 12/6/23 10:12, David Gow wrote:
> > I'm pretty happy with this personally, though I definitely think we
> > need the support for tests which aren't just executable scripts (e.g.
> > the docs in patch 6).
> >
> > The
On Tue, 2023-12-05 at 11:59 -0700, Jonathan Corbet wrote:
> Nikolai Kondrashov writes:
>
> > Introduce a new tag, 'Tested-with:', documented in the
> > Documentation/process/submitting-patches.rst file.
[]
> I have to ask whether we *really* need to introduce yet another tag for
> this. How are
On Tue, 2023-12-05 at 20:02 +0200, Nikolai Kondrashov wrote:
> Require the entry values to not contain the '@' character, so they could
> be distinguished from emails (always) output by get_maintainer.pl.
Why is this useful?
Why the need to distinguish?
On Tue, 2023-12-05 at 20:02 +0200, Nikolai Kondrashov wrote:
> Do not die, but only warn when scripts/get_maintainer.pl is asked to
> retrieve information about a missing file.
>
> This allows scripts/checkpatch.pl to query MAINTAINERS while processing
> patches which are removing files.
Why is
On Thu, 2023-11-30 at 10:39 +0800, Baoquan He wrote:
> Replace pr_debug() with the newly added kexec_dprintk() in kexec_file
> loading related codes.
trivia:
> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
[]
> @@ -551,9 +551,12 @@ int crash_prepare_elf64_headers(struct crash_mem *mem,
On Thu, 2023-11-30 at 10:39 +0800, Baoquan He wrote:
> Replace pr_debug() with the newly added kexec_dprintk() in kexec_file
> loading related codes.
trivia:
> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
[]
> @@ -551,9 +551,12 @@ int crash_prepare_elf64_headers(struct crash_mem *mem,
On Fri, 2023-11-24 at 11:36 +0800, Baoquan He wrote:
> Replace pr_debug() with the newly added kexec_dprintk() in kexec_file
> loading related codes.
trivia for pr_debug -> kexec_dprintk conversions for
the entire patch set:
> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
[]
> @@ -551,9
On Fri, 2023-11-24 at 11:36 +0800, Baoquan He wrote:
> Replace pr_debug() with the newly added kexec_dprintk() in kexec_file
> loading related codes.
trivia for pr_debug -> kexec_dprintk conversions for
the entire patch set:
> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
[]
> @@ -551,9
On Wed, 2023-11-15 at 15:49 +, David Howells wrote:
> Fix some checkpatch complaints in the new iov_iter kunit tests:
>
> (1) Some lines had eight spaces instead of a tab at the start.
>
> (2) Checkpatch doesn't like (void*)(unsigned long)0xnULL, so switch to
> using
On Wed, 2023-11-15 at 19:43 +0200, Nikolai Kondrashov wrote:
> Introduce a new 'V:' ("Verify") field to MAINTAINERS. The field accepts
> a name of a test suite which is required to be executed for each
> contribution to the subsystem.
Perhaps this is simply too much overhead
process requirements
On Tue, 2023-11-14 at 23:32 +0800, Baoquan He wrote:
> When specifying 'kexec -c -d', kexec_load interface will print loading
> information, e.g the regions where kernel/initrd/purgatory/cmdline
> are put, the memmap passed to 2nd kernel taken as system RAM ranges,
> and printing all contents of
On Tue, 2023-11-14 at 23:32 +0800, Baoquan He wrote:
> When specifying 'kexec -c -d', kexec_load interface will print loading
> information, e.g the regions where kernel/initrd/purgatory/cmdline
> are put, the memmap passed to 2nd kernel taken as system RAM ranges,
> and printing all contents of
On 2023-10-27 12:40, Justin Stitt wrote:
Yeah you can push it but it's not really a standalone so perhaps I'll
just steal the diff and
wrap into v3?
Fine by me.
No need for my sign off.
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
On 2023-10-27 12:40, Justin Stitt wrote:
Yeah you can push it but it's not really a standalone so perhaps I'll
just steal the diff and
wrap into v3?
Fine by me.
No need for my sign off.
On Thu, 2023-10-26 at 21:56 +, Justin Stitt wrote:
> Add some warnings for using ethtool_sprintf() where a simple
> ethtool_puts() would suffice.
[]
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -7011,6 +7011,25 @@ sub process {
>"Prefer
On Thu, 2023-10-26 at 21:56 +, Justin Stitt wrote:
> Add some warnings for using ethtool_sprintf() where a simple
> ethtool_puts() would suffice.
[]
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -7011,6 +7011,25 @@ sub process {
>"Prefer
On Thu, 2023-10-26 at 10:49 -0700, Kees Cook wrote:
> On Thu, Oct 26, 2023 at 09:33:17AM -0700, Joe Perches wrote:
> > On Thu, 2023-10-26 at 08:47 -0700, Kees Cook wrote:
> > > On Wed, Oct 25, 2023 at 11:40:31PM +, Justin Stitt wrote:
> > > > @replace_
On Thu, 2023-10-26 at 10:49 -0700, Kees Cook wrote:
> On Thu, Oct 26, 2023 at 09:33:17AM -0700, Joe Perches wrote:
> > On Thu, 2023-10-26 at 08:47 -0700, Kees Cook wrote:
> > > On Wed, Oct 25, 2023 at 11:40:31PM +, Justin Stitt wrote:
> > > > @replace_
On Wed, 2023-10-25 at 23:40 +, Justin Stitt wrote:
> Add some warnings for using ethtool_sprintf() where a simple
> ethtool_puts() would suffice.
Hi again Justin.
After I read patch 1/3 I don't object at all.
spatch/cocci will always be a better option than checkpatch
for conversions like
On Wed, 2023-10-25 at 23:40 +, Justin Stitt wrote:
> Add some warnings for using ethtool_sprintf() where a simple
> ethtool_puts() would suffice.
Hi again Justin.
After I read patch 1/3 I don't object at all.
spatch/cocci will always be a better option than checkpatch
for conversions like
On Thu, 2023-10-26 at 08:47 -0700, Kees Cook wrote:
> On Wed, Oct 25, 2023 at 11:40:31PM +, Justin Stitt wrote:
> > @replace_2_args@
> > identifier BUF;
> > expression VAR;
> > @@
> >
> > - ethtool_sprintf
> > + ethtool_puts
> > (, VAR)
>
> I think cocci will do a better
On Thu, 2023-10-26 at 08:47 -0700, Kees Cook wrote:
> On Wed, Oct 25, 2023 at 11:40:31PM +, Justin Stitt wrote:
> > @replace_2_args@
> > identifier BUF;
> > expression VAR;
> > @@
> >
> > - ethtool_sprintf
> > + ethtool_puts
> > (, VAR)
>
> I think cocci will do a better
On Thu, 2023-10-26 at 16:48 +0200, Louis Peens wrote:
> On Wed, Oct 25, 2023 at 11:40:33PM +, Justin Stitt wrote:
> > This patch converts some basic cases of ethtool_sprintf() to
> > ethtool_puts().
[30k of quoted content]
> Thanks Justin. From my perspective the series looks good, though
On Wed, 2023-10-25 at 23:40 +, Justin Stitt wrote:
> This patch converts some basic cases of ethtool_sprintf() to
> ethtool_puts().
>
> The conversions are used in cases where ethtool_sprintf() was being used
> with just two arguments:
> > ethtool_sprintf(, buffer[i].name);
OK.
> or
On Wed, 2023-10-25 at 23:40 +, Justin Stitt wrote:
> This patch converts some basic cases of ethtool_sprintf() to
> ethtool_puts().
>
> The conversions are used in cases where ethtool_sprintf() was being used
> with just two arguments:
> > ethtool_sprintf(, buffer[i].name);
OK.
> or
On Wed, 2023-10-25 at 23:40 +, Justin Stitt wrote:
> Add some warnings for using ethtool_sprintf() where a simple
> ethtool_puts() would suffice.
>
> The two cases are:
>
> 1) Use ethtool_sprintf() with just two arguments:
> > ethtool_sprintf(, driver[i].name);
OK.
> or
> 2) Use
On Wed, 2023-10-25 at 23:40 +, Justin Stitt wrote:
> Add some warnings for using ethtool_sprintf() where a simple
> ethtool_puts() would suffice.
>
> The two cases are:
>
> 1) Use ethtool_sprintf() with just two arguments:
> > ethtool_sprintf(, driver[i].name);
OK.
> or
> 2) Use
On Fri, 2023-09-29 at 11:07 +0900, Justin Stitt wrote:
> On Fri, Sep 29, 2023 at 12:52 AM Nick Desaulniers
> wrote:
> >
> > On Wed, Sep 27, 2023 at 11:09 PM Joe Perches wrote:
> > >
> > > On Thu, 2023-09-28 at 14:31 +0900, Justin Stitt wrote:
> > >
On Thu, 2023-09-28 at 14:31 +0900, Justin Stitt wrote:
> On Thu, Sep 28, 2023 at 2:01 PM Joe Perches wrote:
> >
> > On Thu, 2023-09-28 at 04:23 +, Justin Stitt wrote:
> > > Changes in v2:
> > > - remove formatting pass (thanks Joe) (but seriou
On Thu, 2023-09-28 at 14:03 +0900, Justin Stitt wrote:
> On Thu, Sep 28, 2023 at 1:46 PM Joe Perches wrote:
> >
> > On Thu, 2023-09-28 at 04:23 +, Justin Stitt wrote:
> > > Add the "D:" type which behaves the same as "K:" but will only match
> &
On Thu, 2023-09-28 at 04:23 +, Justin Stitt wrote:
> Changes in v2:
> - remove formatting pass (thanks Joe) (but seriously the formatting is
> bad, is there opportunity to get a formatting pass in here at some
> point?)
Why? What is it that makes you believe the formatting is bad?
On Thu, 2023-09-28 at 04:23 +, Justin Stitt wrote:
> Let's get the ball rolling with some changes from K to D.
>
> Ultimately, if it turns out that 100% of K users want to change to D
> then really the behavior of K could just be changed.
Given my suggestion to 1/2, this would be
On Thu, 2023-09-28 at 04:23 +, Justin Stitt wrote:
> Add the "D:" type which behaves the same as "K:" but will only match
> content present in a patch file.
>
> To illustrate:
>
> Imagine this entry in MAINTAINERS:
>
> NEW REPUBLIC
> M: Han Solo
> W: https://www.jointheresistance.org
> D:
On Wed, 2023-09-27 at 09:15 -0700, Kees Cook wrote:
> On Wed, Sep 27, 2023 at 03:19:16AM +, Justin Stitt wrote:
> > Add the "D:" type which behaves the same as "K:" but will only match
> > content present in a patch file.
> >
> > To illustrate:
> >
> > Imagine this entry in MAINTAINERS:
> >
On Wed, 2023-09-27 at 03:19 +, Justin Stitt wrote:
> Add the "D:" type which behaves the same as "K:" but will only match
> content present in a patch file.
Likely it'd be less aggravating just to document
that K: is only for patches and add a !$file test.
On Wed, 2023-09-27 at 03:19 +, Justin Stitt wrote:
> I'm a first time contributor to get_maintainer.pl and the formatting is
> suspicious. I am not sure if there is a particular reason it is the way
> it is but I let my editor format it and submitted the diff here in this
> patch.
Capital
On Wed, 2023-09-27 at 03:19 +, Justin Stitt wrote:
> Document what "D:" does.
>
> This is more or less the same as what "K:" does but only works for patch
> files.
Nack. I'd rather just add a !$file test to K: patterns.
On Tue, 2023-09-12 at 11:04 -0600, Gustavo A. R. Silva wrote:
> vmalloc() and vzalloc() functions have now 2-factor multiplication
> argument forms vmalloc_array() and vcalloc(), correspondingly.
> Add alloc-with-multiplies checks for these new functions.
>
> Link:
On Tue, 2023-08-01 at 17:35 -0600, Jim Cromie wrote:
> Reword the warning to complain about line length 1st, since thats
> whats actually tested.
[]
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -3272,7 +3272,7 @@ sub process {
> # A
seems sensible, thanks.
Assuming Linus approves the use of "Closes:"
Acked-by: Joe Perches
> As detailed in the first patch, this "Closes:" tag is used for a bit of
> time, mainly by DRM and MPTCP subsystems. It is used by some bug
> trackers to automate the clo
ything.
I believe it's merely a new capability.
> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/373
> Signed-off-by: Matthieu Baerts
> ---
> v3:
> - split into 2 patches: the previous one adds a list with all the
>"link" tags. This one only
On Fri, 2023-03-24 at 19:52 +0100, Matthieu Baerts wrote:
> As a follow-up of the previous patch modifying the documentation to
> allow using the "Closes:" tag, checkpatch.pl is updated accordingly.
>
> checkpatch.pl now mentions the "Closes:" tag between brackets to express
> the fact it should
On Fri, 2023-03-03 at 15:35 -0500, Harry Wentland wrote:
> Actually I was wrong. Too many similar-looking snippets in this
> function made me look at the wrong thing. This change is fine and
> Reviewed-by: Harry Wentland
On Fri, 2023-03-03 at 15:35 -0500, Harry Wentland wrote:
> Actually I was wrong. Too many similar-looking snippets in this
> function made me look at the wrong thing. This change is fine and
> Reviewed-by: Harry Wentland
On Sat, 2023-02-18 at 10:15 +0100, Christophe Leroy wrote:
> Many places have:
>
> if (ppc.md_progress)
> ppc.md_progress();
>
> Use ppc_md_progress() instead.
>
> Note that checkpatch complains about using function names,
> but this is not a function taking format strings,
On Sun, 2023-01-15 at 15:30 +0530, Deepak R Varma wrote:
> The if / else block code has same effect irrespective of the logical
> evaluation. Hence, simply the implementation by removing the unnecessary
> conditional evaluation. While at it, also fix the long line checkpatch
> complaint. Issue
On Sun, 2023-01-15 at 15:30 +0530, Deepak R Varma wrote:
> The if / else block code has same effect irrespective of the logical
> evaluation. Hence, simply the implementation by removing the unnecessary
> conditional evaluation. While at it, also fix the long line checkpatch
> complaint. Issue
On Fri, 2022-10-14 at 09:54 -0400, Sasha Levin wrote:
> From: ye xingchen
>
> [ Upstream commit c814bf958926ff45a9c1e899bd001006ab6cfbae ]
>
> Use timersub() function to simplify the code.
Why should a code simplification be backported?
>
> Reported-by: Zeal Robot
> Signed-off-by: ye
On Wed, 2022-10-12 at 21:29 +, David Laight wrote:
> From: Joe Perches
> > Sent: 12 October 2022 20:17
> >
> > On Wed, 2022-10-05 at 23:48 +0200, Jason A. Donenfeld wrote:
> > > The prandom_u32() function has been a deprecated inline wrapper around
> > >
On Wed, 2022-10-12 at 21:29 +, David Laight wrote:
> From: Joe Perches
> > Sent: 12 October 2022 20:17
> >
> > On Wed, 2022-10-05 at 23:48 +0200, Jason A. Donenfeld wrote:
> > > The prandom_u32() function has been a deprecated inline wrapper around
> > >
On Wed, 2022-10-12 at 21:29 +, David Laight wrote:
> From: Joe Perches
> > Sent: 12 October 2022 20:17
> >
> > On Wed, 2022-10-05 at 23:48 +0200, Jason A. Donenfeld wrote:
> > > The prandom_u32() function has been a deprecated inline wrapper around
> > >
On Wed, 2022-10-12 at 21:29 +, David Laight wrote:
> From: Joe Perches
> > Sent: 12 October 2022 20:17
> >
> > On Wed, 2022-10-05 at 23:48 +0200, Jason A. Donenfeld wrote:
> > > The prandom_u32() function has been a deprecated inline wrapper around
> > >
On Wed, 2022-10-05 at 23:48 +0200, Jason A. Donenfeld wrote:
> The prandom_u32() function has been a deprecated inline wrapper around
> get_random_u32() for several releases now, and compiles down to the
> exact same code. Replace the deprecated wrapper with a direct call to
> the real function.
On Wed, 2022-10-05 at 23:48 +0200, Jason A. Donenfeld wrote:
> The prandom_u32() function has been a deprecated inline wrapper around
> get_random_u32() for several releases now, and compiles down to the
> exact same code. Replace the deprecated wrapper with a direct call to
> the real function.
On Wed, 2022-10-05 at 23:48 +0200, Jason A. Donenfeld wrote:
> The prandom_u32() function has been a deprecated inline wrapper around
> get_random_u32() for several releases now, and compiles down to the
> exact same code. Replace the deprecated wrapper with a direct call to
> the real function.
On Wed, 2022-10-05 at 23:48 +0200, Jason A. Donenfeld wrote:
> The prandom_u32() function has been a deprecated inline wrapper around
> get_random_u32() for several releases now, and compiles down to the
> exact same code. Replace the deprecated wrapper with a direct call to
> the real function.
> >
> > > > Use upper letters as below:
> >
> > For microseconds (and other -seconds) the common practice (I assume
> > historically) is to use upper letters, indeed. But for current it's
> > more natural to use small letters for unit multiplier as it's
On Thu, 2022-09-22 at 19:05 -0700, John Hubbard wrote:
> On 9/20/22 05:23, David Hildenbrand wrote:
> > checkpatch does not point out that VM_BUG_ON() and friends should be
> > avoided, however, Linus notes:
> >
> > VM_BUG_ON() has the exact same semantics as BUG_ON. It is literally
> >
On Mon, 2022-09-05 at 11:49 +0300, Jani Nikula wrote:
> On Mon, 05 Sep 2022, Jani Nikula wrote:
> > On Mon, 05 Sep 2022, Jingyu Wang wrote:
> > > Fix everything checkpatch.pl complained about in drm_print.h
>
> [...]
>
> > > static inline void
> > > -drm_vprintf(struct drm_printer *p, const
On Tue, 2022-08-30 at 14:49 -0700, Suren Baghdasaryan wrote:
> From: Kent Overstreet
>
> This patch adds per-error-site error codes, with error strings that
> include their file and line number.
>
> To use, change code that returns an error, e.g.
> return -ENOMEM;
> to
> return
On Wed, 2022-08-24 at 18:31 +0200, David Hildenbrand wrote:
> checkpatch does not point out that VM_BUG_ON() and friends should be
> avoided, however, Linus notes:
>
> VM_BUG_ON() has the exact same semantics as BUG_ON. It is literally
> no different, the only difference is "we can make
On Mon, 2022-08-01 at 11:23 -0700, Christoph Hellwig wrote:
> On Mon, Aug 01, 2022 at 05:22:02PM +0800, studentxs...@163.com wrote:
> > From: Xie Shaowen
> >
> > replace kmalloc with f2fs_kmalloc to keep f2fs code consistency.
>
> For that removing f2fs_kmalloc entirely would be way better.
On Tue, 2022-07-26 at 15:55 +, Vishnu Dasa wrote:
> > On Jul 26, 2022, at 8:10 AM, Greg KH > On Mon, Jul 25, 2022 at 06:29:25PM +, Vishnu Dasa wrote:
> > > > On Jul 25, 2022, at 11:05 AM, Greg KH
> > > > wrote:
> > > > On Mon, Jul 25, 2022 at 09:32:46AM -0700, vd...@vmware.com wrote:
>
On Mon, 2022-07-25 at 09:57 -0400, William Breathitt Gray wrote:
> On Mon, Jul 25, 2022 at 06:52:15AM -0700, Joe Perches wrote:
> > On Fri, 2022-07-22 at 07:45 +0800, Baoquan He wrote:
> > > The fix is done with below command:
> > > sed -i "s/the the /the /g"
On Mon, 2022-07-25 at 09:57 -0400, William Breathitt Gray wrote:
> On Mon, Jul 25, 2022 at 06:52:15AM -0700, Joe Perches wrote:
> > On Fri, 2022-07-22 at 07:45 +0800, Baoquan He wrote:
> > > The fix is done with below command:
> > > sed -i "s/the the /the /g"
On Fri, 2022-07-22 at 07:45 +0800, Baoquan He wrote:
> On 07/21/22 at 11:40am, Randy Dunlap wrote:
> > On 7/21/22 11:36, Jonathan Corbet wrote:
> > > "Slark Xiao" writes:
> > > > May I know the maintainer of one subsystem could merge the changes
> > > > contains lots of subsystem? I also know
On Fri, 2022-07-22 at 07:45 +0800, Baoquan He wrote:
> On 07/21/22 at 11:40am, Randy Dunlap wrote:
> > On 7/21/22 11:36, Jonathan Corbet wrote:
> > > "Slark Xiao" writes:
> > > > May I know the maintainer of one subsystem could merge the changes
> > > > contains lots of subsystem? I also know
On Fri, 2022-07-15 at 17:35 -0400, Rodrigo Vivi wrote:
> On Wed, Jul 13, 2022 at 09:12:12AM +0100, Mauro Carvalho Chehab wrote:
> > This file is licensed with MIT license. Change its license text
> > to use SPDX.
> >
> > Signed-off-by: Mauro Carvalho Chehab
>
> Reviewed-by: Rodrigo Vivi
On Fri, 2022-07-15 at 17:35 -0400, Rodrigo Vivi wrote:
> On Wed, Jul 13, 2022 at 09:12:12AM +0100, Mauro Carvalho Chehab wrote:
> > This file is licensed with MIT license. Change its license text
> > to use SPDX.
> >
> > Signed-off-by: Mauro Carvalho Chehab
>
> Reviewed-by: Rodrigo Vivi
On Thu, 2022-06-30 at 02:50 +0200, Jason A. Donenfeld wrote:
> On Wed, Jun 29, 2022 at 05:36:57PM -0700, Joe Perches wrote:
> > > > +static ssize_t pm_userspace_autosleeper_show(struct kobject *kobj,
> > > > + struct kobj
On Wed, 2022-06-29 at 16:19 -0700, Kalesh Singh wrote:
> On Wed, Jun 29, 2022 at 4:02 PM Jason A. Donenfeld wrote:
> > On Wed, Jun 29, 2022 at 03:26:33PM -0700, Kalesh Singh wrote:
> > > Thanks for taking a look. I'm concerned holding the sys/power/state
> > > open would have unintentional side
On Sat, 2022-06-25 at 19:00 -0700, David Reaver wrote:
> Fix alignment of this line of code with the previous parenthesis, as
> suggested by checkpatch.pl:
[]
> diff --git a/drivers/staging/fbtft/fb_tinylcd.c
> b/drivers/staging/fbtft/fb_tinylcd.c
[]
> @@ -38,7 +38,7 @@ static int
On Wed, 2022-06-22 at 09:52 +0800, Zhang Jiaming wrote:
> There is a typo in comments. Change 'neeed' to 'need'.
[]
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
[]
> @@ -280,7 +280,7 @@ nvkm_vmm_unref_ptes(struct nvkm_vmm_iter *it,
On Wed, 2022-06-22 at 09:52 +0800, Zhang Jiaming wrote:
> There is a typo in comments. Change 'neeed' to 'need'.
[]
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
[]
> @@ -280,7 +280,7 @@ nvkm_vmm_unref_ptes(struct nvkm_vmm_iter *it,
On Sat, 2022-05-28 at 18:03 +0200, Konrad Dybcio wrote:
> Leading spaces are not something checkpatch likes, and it says so when
> they are present. Use tabs consistently to indent function body and
> unwrap a 83-char-long line, as 100 is cool nowadays.
unassociated trivia:
> diff --git
On Sat, 2022-05-28 at 18:03 +0200, Konrad Dybcio wrote:
> Leading spaces are not something checkpatch likes, and it says so when
> they are present. Use tabs consistently to indent function body and
> unwrap a 83-char-long line, as 100 is cool nowadays.
unassociated trivia:
> diff --git
ove
> "#undef flush_workqueue", suggested by Joe Perches .
On Sun, 2022-04-24 at 16:54 -0400, Mikulas Patocka wrote:
> This patch changes the function hex_to_bin so that it contains no branches
> and no memory accesses.
[]
> +++ linux-2.6/lib/hexdump.c 2022-04-24 18:51:20.0 +0200
[]
> + * the next line is similar to the previous one, but we need
On Sun, 2022-04-24 at 17:25 +0800, Wan Jiabing wrote:
> Use if and else instead of if(A) and if (!A).
[]
> diff --git a/drivers/tty/hvc/hvc_opal.c b/drivers/tty/hvc/hvc_opal.c
[]
> @@ -344,14 +344,15 @@ void __init hvc_opal_init_early(void)
> opal =
On Sat, 2022-04-16 at 13:48 -0700, Tom Rix wrote:
> On 4/16/22 11:33 AM, Joe Perches wrote:
> > On Sat, 2022-04-16 at 13:23 -0400, Tom Rix wrote:
> > > In insert_mappable_node(), the parameter node is
> > > cleared late in node's use with memset.
> > > insert_ma
On Sat, 2022-04-16 at 13:48 -0700, Tom Rix wrote:
> On 4/16/22 11:33 AM, Joe Perches wrote:
> > On Sat, 2022-04-16 at 13:23 -0400, Tom Rix wrote:
> > > In insert_mappable_node(), the parameter node is
> > > cleared late in node's use with memset.
> > > insert_ma
On Sat, 2022-04-16 at 13:23 -0400, Tom Rix wrote:
> In insert_mappable_node(), the parameter node is
> cleared late in node's use with memset.
> insert_mappable_node() is a singleton, called only
> from i915_gem_gtt_prepare() which itself is only
> called by i915_gem_gtt_pread() and
>
On Sat, 2022-04-16 at 13:23 -0400, Tom Rix wrote:
> In insert_mappable_node(), the parameter node is
> cleared late in node's use with memset.
> insert_mappable_node() is a singleton, called only
> from i915_gem_gtt_prepare() which itself is only
> called by i915_gem_gtt_pread() and
>
On Sat, 2022-03-26 at 19:27 +0100, Mauro Carvalho Chehab wrote:
> Em Sat, 26 Mar 2022 19:24:54 +0100
> Mauro Carvalho Chehab escreveu:
>
> > Em Sat, 26 Mar 2022 17:59:03 +0100
> > Benjamin Stürz escreveu:
> >
> > > This replaces comments with C99's designated
> > > initializers because the
On Sat, 2022-03-26 at 17:58 +0100, Benjamin Stürz wrote:
> This replaces comments with C99's designated
> initializers because the kernel supports them now.
[]
> diff --git a/arch/arm/mach-s3c/bast-irq.c b/arch/arm/mach-s3c/bast-irq.c
[]
> @@ -29,22 +29,22 @@
> * the irq is not implemented
> */
On Sat, 2022-03-12 at 07:26 -0800, Harshit Mogalapalli wrote:
> kvcalloc is same as kvmalloc_array + __GFP_ZERO.
[]
> diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
[]
> @@ -308,9 +308,8 @@ v3d_lookup_bos(struct drm_device *dev,
> return -EINVAL;
> }
On Mon, 2022-02-28 at 14:24 +0300, Dan Carpenter wrote:
> a multi-line indent gets curly braces for readability even though
> it's not required by C. And then both sides would get curly braces.
That's more your personal preference than a coding style guideline.
On Fri, 2022-02-25 at 12:23 +0100, Jerome Pouiller wrote:
> From: Jérôme Pouiller
>
> A few comments were not yet formatted on 100 columns.
IMO, none of these changes are necessary or good changes.
80 columns is preferred.
Really comments should most always use 80 columns, and
only
On Mon, 2022-02-28 at 14:24 +0300, Dan Carpenter wrote:
> a multi-line indent gets curly braces for readability even though
> it's not required by C. And then both sides would get curly braces.
That's more your personal preference than a coding style guideline.
On Mon, 2022-02-28 at 14:24 +0300, Dan Carpenter wrote:
> a multi-line indent gets curly braces for readability even though
> it's not required by C. And then both sides would get curly braces.
That's more your personal preference than a coding style guideline.
1 - 100 of 25400 matches
Mail list logo
