Fix some issues reported by checkpatch.pl. All of them are
coding style issues, no function changes.
Xiaofei Tan (9):
tty: hvc_console: Fix spaces required around that '='
tty: hvc_console: Fix "foo * bar" should be "foo *bar"
tty: hvc_console: Remove trailing whitespace
tty: hvc_console: Fix issues of code indent should use tabs
tty: hvc_console: Delete spaces prohibited around open parenthesis '('
and ')'
tty: hvc_console: Fix coding style issues of block comments
tty: hvc_console: Add a blank line after declarations
tty: hvc_console: Remove the repeated words 'no' and 'from'
tty: hvc_console: Move open brace { on the previous line
drivers/tty/hvc/hvc_console.c | 37 ++++++++++++++++++++++---------------
1 file changed, 22 insertions(+), 15 deletions(-)
--
2.8.1
Add a blank line after declarations, reported by checkpatch.pl.
Signed-off-by: Xiaofei Tan <[email protected]>
---
drivers/tty/hvc/hvc_console.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index a61cdf0..f31efeb 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -922,6 +922,7 @@ struct hvc_struct *hvc_alloc(uint32_t vtermno, int data,
/* We wait until a driver actually comes along */
if (atomic_inc_not_zero(&hvc_needs_init)) {
int err = hvc_init();
+
if (err)
return ERR_PTR(err);
}
--
2.8.1
Fix spaces required around that '=', reported by checkpatch.pl.
Signed-off-by: Xiaofei Tan <[email protected]>
---
drivers/tty/hvc/hvc_console.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index d0f0253..a1eca9d 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -944,7 +944,7 @@ struct hvc_struct *hvc_alloc(uint32_t vtermno, int data,
* find index to use:
* see if this vterm id matches one registered for console.
*/
- for (i=0; i < MAX_NR_HVC_CONSOLES; i++)
+ for (i = 0; i < MAX_NR_HVC_CONSOLES; i++)
if (vtermnos[i] == hp->vtermno &&
cons_ops[i] == hp->ops)
break;
--
2.8.1
Remove the repeated words 'no' and 'from', reported by checkpatch.pl.
Signed-off-by: Xiaofei Tan <[email protected]>
---
drivers/tty/hvc/hvc_console.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index f31efeb..b6720b0 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -293,7 +293,7 @@ int hvc_instantiate(uint32_t vtermno, int index, const struct hv_ops *ops)
if (vtermnos[index] != -1)
return -1;
- /* make sure no no tty has been registered in this index */
+ /* make sure no tty has been registered in this index */
hp = hvc_get_by_index(index);
if (hp) {
tty_port_put(&hp->port);
@@ -622,7 +622,7 @@ static u32 timeout = MIN_TIMEOUT;
/*
* Maximum number of bytes to get from the console driver if hvc_poll is
* called from driver (and can't sleep). Any more than this and we break
- * and start polling with khvcd. This value was derived from from an OpenBMC
+ * and start polling with khvcd. This value was derived from an OpenBMC
* console with the OPAL driver that results in about 0.25ms interrupts off
* latency.
*/
--
2.8.1
Delete spaces prohibited after that open parenthesis '(' and
before that close parenthesis ')', reported by checkpatch.pl.
Signed-off-by: Xiaofei Tan <[email protected]>
---
drivers/tty/hvc/hvc_console.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 2e5c133..39018e5 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -689,7 +689,7 @@ static int __hvc_poll(struct hvc_struct *hp, bool may_sleep)
spin_unlock_irqrestore(&hp->lock, flags);
tty_hangup(tty);
spin_lock_irqsave(&hp->lock, flags);
- } else if ( n == -EAGAIN ) {
+ } else if (n == -EAGAIN) {
/*
* Some back-ends can only ensure a certain min
* num of bytes read, which may be > 'count'.
--
2.8.1
Remove trailing whitespace, reported by checkpatch.pl.
Signed-off-by: Xiaofei Tan <[email protected]>
---
drivers/tty/hvc/hvc_console.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index ddf07ff..13f63d5 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -204,7 +204,7 @@ static struct tty_driver *hvc_console_device(struct console *c, int *index)
}
static int hvc_console_setup(struct console *co, char *options)
-{
+{
if (co->index < 0 || co->index >= MAX_NR_HVC_CONSOLES)
return -ENODEV;
--
2.8.1
Fix "foo * bar" should be "foo *bar", reported by checkpatch.pl.
Signed-off-by: Xiaofei Tan <[email protected]>
---
drivers/tty/hvc/hvc_console.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index a1eca9d..ddf07ff 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -344,7 +344,7 @@ static int hvc_install(struct tty_driver *driver, struct tty_struct *tty)
* The TTY interface won't be used until after the vio layer has exposed the vty
* adapter to the kernel.
*/
-static int hvc_open(struct tty_struct *tty, struct file * filp)
+static int hvc_open(struct tty_struct *tty, struct file *filp)
{
struct hvc_struct *hp = tty->driver_data;
unsigned long flags;
@@ -386,7 +386,7 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
return rc;
}
-static void hvc_close(struct tty_struct *tty, struct file * filp)
+static void hvc_close(struct tty_struct *tty, struct file *filp)
{
struct hvc_struct *hp = tty->driver_data;
unsigned long flags;
--
2.8.1
Fix issues that open brace { should be on the previous line,
reported by checkpatch.pl.
Signed-off-by: Xiaofei Tan <[email protected]>
---
drivers/tty/hvc/hvc_console.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index b6720b0..b96399e 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -140,8 +140,9 @@ static int hvc_flush(struct hvc_struct *hp)
* static because kmalloc will not work during early console init.
*/
static const struct hv_ops *cons_ops[MAX_NR_HVC_CONSOLES];
-static uint32_t vtermnos[MAX_NR_HVC_CONSOLES] =
- {[0 ... MAX_NR_HVC_CONSOLES - 1] = -1};
+static uint32_t vtermnos[MAX_NR_HVC_CONSOLES] = {
+ [0 ... MAX_NR_HVC_CONSOLES - 1] = -1
+};
/*
* Console APIs, NOT TTY. These APIs are available immediately when
--
2.8.1
Fix issues of code indent should use tabs, reported by checkpatch.pl.
Signed-off-by: Xiaofei Tan <[email protected]>
---
drivers/tty/hvc/hvc_console.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 13f63d5..2e5c133 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -268,7 +268,7 @@ static void hvc_check_console(int index)
if (hvc_console.flags & CON_ENABLED)
return;
- /* If this index is what the user requested, then register
+ /* If this index is what the user requested, then register
* now (setup won't fail at this point). It's ok to just
* call register again if previously .setup failed.
*/
--
2.8.1
Fix coding style issues of block comments, reported by checkpatch.pl.
Besides, add a period at the end of the sentenses.
Signed-off-by: Xiaofei Tan <[email protected]>
---
drivers/tty/hvc/hvc_console.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 39018e5..a61cdf0 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -177,7 +177,8 @@ static void hvc_console_print(struct console *co, const char *b,
r = cons_ops[index]->put_chars(vtermnos[index], c, i);
if (r <= 0) {
/* throw away characters on error
- * but spin in case of -EAGAIN */
+ * but spin in case of -EAGAIN.
+ */
if (r != -EAGAIN) {
i = 0;
} else {
@@ -484,7 +485,8 @@ static int hvc_push(struct hvc_struct *hp)
return 0;
}
/* throw away output on error; this happens when
- there is no session connected to the vterm. */
+ * there is no session connected to the vterm.
+ */
hp->n_outbuf = 0;
} else
hp->n_outbuf -= n;
@@ -707,7 +709,8 @@ static int __hvc_poll(struct hvc_struct *hp, bool may_sleep)
/* XXX should support a sequence */
if (buf[i] == '\x0f') { /* ^O */
/* if ^O is pressed again, reset
- * sysrq_pressed and flip ^O char */
+ * sysrq_pressed and flip ^O char.
+ */
sysrq_pressed = !sysrq_pressed;
if (sysrq_pressed)
continue;
@@ -749,7 +752,8 @@ static int __hvc_poll(struct hvc_struct *hp, bool may_sleep)
if (read_total) {
/* Activity is occurring, so reset the polling backoff value to
- a minimum for performance. */
+ * a minimum for performance.
+ */
timeout = MIN_TIMEOUT;
tty_flip_buffer_push(&hp->port);
@@ -1037,7 +1041,8 @@ static int hvc_init(void)
tty_set_operations(drv, &hvc_ops);
/* Always start the kthread because there can be hotplug vty adapters
- * added later. */
+ * added later.
+ */
hvc_task = kthread_run(khvcd, NULL, "khvcd");
if (IS_ERR(hvc_task)) {
printk(KERN_ERR "Couldn't create kthread for console.\n");
--
2.8.1
On Mon, May 17, 2021 at 02:37:10PM +0800, Xiaofei Tan wrote:
> Fix coding style issues of block comments, reported by checkpatch.pl.
> Besides, add a period at the end of the sentenses.
>
> Signed-off-by: Xiaofei Tan <[email protected]>
> ---
> drivers/tty/hvc/hvc_console.c | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
> index 39018e5..a61cdf0 100644
> --- a/drivers/tty/hvc/hvc_console.c
> +++ b/drivers/tty/hvc/hvc_console.c
> @@ -177,7 +177,8 @@ static void hvc_console_print(struct console *co, const char *b,
> r = cons_ops[index]->put_chars(vtermnos[index], c, i);
> if (r <= 0) {
> /* throw away characters on error
> - * but spin in case of -EAGAIN */
> + * but spin in case of -EAGAIN.
> + */
How is this an improvement? First, the multi-line comment style is
/*
* ...
*/
Second, that sentence is not capitalised so why do add a period?
Third, why are you sending checkpatch.pl cleanups for files outside of
staging?
Unless doing some real changes to the files in question as well this is
mostly just churn and noise that makes it harder to backport fixes and
do code forensics for no real gain.
Greg may disagree, but I don't think we should be encouraging this kind
of patches.
Johan
Hi Johan,
Thanks for reviewing this patch.
On 2021/5/17 22:15, Johan Hovold wrote:
> On Mon, May 17, 2021 at 02:37:10PM +0800, Xiaofei Tan wrote:
>> Fix coding style issues of block comments, reported by checkpatch.pl.
>> Besides, add a period at the end of the sentenses.
>>
>> Signed-off-by: Xiaofei Tan <[email protected]>
>> ---
>> drivers/tty/hvc/hvc_console.c | 15 ++++++++++-----
>> 1 file changed, 10 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
>> index 39018e5..a61cdf0 100644
>> --- a/drivers/tty/hvc/hvc_console.c
>> +++ b/drivers/tty/hvc/hvc_console.c
>> @@ -177,7 +177,8 @@ static void hvc_console_print(struct console *co, const char *b,
>> r = cons_ops[index]->put_chars(vtermnos[index], c, i);
>> if (r <= 0) {
>> /* throw away characters on error
>> - * but spin in case of -EAGAIN */
>> + * but spin in case of -EAGAIN.
>> + */
>
> How is this an improvement? First, the multi-line comment style is
>
> /*
> * ...
> */
>
Yes, mostly we use this style. I can follow it if new version is needed.
BTW, How about add the '/*' check into checkpatch.pl?
> Second, that sentence is not capitalised so why do add a period?
>
How about capitalize the sentence, or just remove the period ?
> Third, why are you sending checkpatch.pl cleanups for files outside of
> staging?
>
I'm sorry, Is this a rule, or kind of tradition? I've never heard of
this before.
> Unless doing some real changes to the files in question as well this is
> mostly just churn and noise that makes it harder to backport fixes and
> do code forensics for no real gain.
>
I'm not sure. But if cleanup patches have made it hard to backport fixes
and do code forensics, then the code quality may not be
good enough.
> Greg may disagree, but I don't think we should be encouraging this kind
> of patches.
>
> Johan
>
> .
>
On Tue, May 18, 2021 at 12:01:22PM +0800, Xiaofei Tan wrote:
> Hi Johan,
>
> Thanks for reviewing this patch.
>
> On 2021/5/17 22:15, Johan Hovold wrote:
> > On Mon, May 17, 2021 at 02:37:10PM +0800, Xiaofei Tan wrote:
> >> Fix coding style issues of block comments, reported by checkpatch.pl.
> >> Besides, add a period at the end of the sentenses.
> >>
> >> Signed-off-by: Xiaofei Tan <[email protected]>
> >> ---
> >> drivers/tty/hvc/hvc_console.c | 15 ++++++++++-----
> >> 1 file changed, 10 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
> >> index 39018e5..a61cdf0 100644
> >> --- a/drivers/tty/hvc/hvc_console.c
> >> +++ b/drivers/tty/hvc/hvc_console.c
> >> @@ -177,7 +177,8 @@ static void hvc_console_print(struct console *co, const char *b,
> >> r = cons_ops[index]->put_chars(vtermnos[index], c, i);
> >> if (r <= 0) {
> >> /* throw away characters on error
> >> - * but spin in case of -EAGAIN */
> >> + * but spin in case of -EAGAIN.
> >> + */
> >
> > How is this an improvement? First, the multi-line comment style is
> >
> > /*
> > * ...
> > */
> >
>
> Yes, mostly we use this style. I can follow it if new version is needed.
This is the preferred style outside of networking.
> BTW, How about add the '/*' check into checkpatch.pl?
Checkpatch already has too many checks IMO and I'm a bit surprised that
it doesn't check this already. Perhaps it's because you used the -f to
run checkpatch on in-kernel code, which you should not.
> > Second, that sentence is not capitalised so why do add a period?
> >
>
> How about capitalize the sentence, or just remove the period ?
How about just leaving this unchanged?
> > Third, why are you sending checkpatch.pl cleanups for files outside of
> > staging?
> >
>
> I'm sorry, Is this a rule, or kind of tradition? I've never heard of
> this before.
Many subsystems reject pure style changes unless you're also doing some
real changes to the code in question. This is a good default rule, even
if some maintainers may occasionally accept churn like this.
You appear to be paid to do kernel work. Why don't you start fixing bugs
or help out reviewing new code instead of sending trivial patches like
this? We can always need another hand.
But if all you you want is to increase your company patch count then
please go work in drivers/staging where most trivial style changes are
currently accepted.
> > Unless doing some real changes to the files in question as well this is
> > mostly just churn and noise that makes it harder to backport fixes and
> > do code forensics for no real gain.
>
> I'm not sure. But if cleanup patches have made it hard to backport fixes
> and do code forensics, then the code quality may not be
> good enough.
No, that has nothing to do with code quality, it's just that you
introduce noise in the logs and do pointless changes of context which
makes it harder to use tools like git blame and makes backporting harder
for no good reason.
Johan
On Thu, May 20, 2021 at 09:21:25PM +0800, Xiaofei Tan wrote:
> > Checkpatch already has too many checks IMO and I'm a bit surprised that
> > it doesn't check this already. Perhaps it's because you used the -f to
> > run checkpatch on in-kernel code, which you should not.
> >
> >>> Second, that sentence is not capitalised so why do add a period?
> >>>
> >>
> >> How about capitalize the sentence, or just remove the period ?
> >
> > How about just leaving this unchanged?
>
> OK
> And I will keep the patch 8/9, and combine space issues into
> one new patch, and remove the others.
Yeah, 8/9 is arguably a fix even if it's for a very minor issue
(repeated words in a comment).
It doesn't look like any of the white space issues are worth fixing,
though. Such pedantry can usually be addressed when the code in question
is being modified for other reasons.
Johan
Hi Johan，
On 2021/5/20 16:21, Johan Hovold wrote:
> On Tue, May 18, 2021 at 12:01:22PM +0800, Xiaofei Tan wrote:
>> Hi Johan,
>>
>> Thanks for reviewing this patch.
>>
>> On 2021/5/17 22:15, Johan Hovold wrote:
>>> On Mon, May 17, 2021 at 02:37:10PM +0800, Xiaofei Tan wrote:
>>>> Fix coding style issues of block comments, reported by checkpatch.pl.
>>>> Besides, add a period at the end of the sentenses.
>>>>
>>>> Signed-off-by: Xiaofei Tan <[email protected]>
>>>> ---
>>>> drivers/tty/hvc/hvc_console.c | 15 ++++++++++-----
>>>> 1 file changed, 10 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
>>>> index 39018e5..a61cdf0 100644
>>>> --- a/drivers/tty/hvc/hvc_console.c
>>>> +++ b/drivers/tty/hvc/hvc_console.c
>>>> @@ -177,7 +177,8 @@ static void hvc_console_print(struct console *co, const char *b,
>>>> r = cons_ops[index]->put_chars(vtermnos[index], c, i);
>>>> if (r <= 0) {
>>>> /* throw away characters on error
>>>> - * but spin in case of -EAGAIN */
>>>> + * but spin in case of -EAGAIN.
>>>> + */
>>>
>>> How is this an improvement? First, the multi-line comment style is
>>>
>>> /*
>>> * ...
>>> */
>>>
>>
>> Yes, mostly we use this style. I can follow it if new version is needed.
>
> This is the preferred style outside of networking.
>
>> BTW, How about add the '/*' check into checkpatch.pl?
>
> Checkpatch already has too many checks IMO and I'm a bit surprised that
> it doesn't check this already. Perhaps it's because you used the -f to
> run checkpatch on in-kernel code, which you should not.
>
>>> Second, that sentence is not capitalised so why do add a period?
>>>
>>
>> How about capitalize the sentence, or just remove the period ?
>
> How about just leaving this unchanged?
>
OK
And I will keep the patch 8/9, and combine space issues into
one new patch, and remove the others.
>>> Third, why are you sending checkpatch.pl cleanups for files outside of
>>> staging?
>>>
>>
>> I'm sorry, Is this a rule, or kind of tradition? I've never heard of
>> this before.
>
> Many subsystems reject pure style changes unless you're also doing some
> real changes to the code in question. This is a good default rule, even
> if some maintainers may occasionally accept churn like this.
>
> You appear to be paid to do kernel work. Why don't you start fixing bugs
> or help out reviewing new code instead of sending trivial patches like
> this? We can always need another hand.
>
> But if all you you want is to increase your company patch count then
> please go work in drivers/staging where most trivial style changes are
> currently accepted.
>
>>> Unless doing some real changes to the files in question as well this is
>>> mostly just churn and noise that makes it harder to backport fixes and
>>> do code forensics for no real gain.
>>
>> I'm not sure. But if cleanup patches have made it hard to backport fixes
>> and do code forensics, then the code quality may not be
>> good enough.
>
> No, that has nothing to do with code quality, it's just that you
> introduce noise in the logs and do pointless changes of context which
> makes it harder to use tools like git blame and makes backporting harder
> for no good reason.
>
> Johan
>
> .
>
On Thu, 2021-05-20 at 10:21 +0200, Johan Hovold wrote:
> On Tue, May 18, 2021 at 12:01:22PM +0800, Xiaofei Tan wrote:
> > On 2021/5/17 22:15, Johan Hovold wrote:
> > > On Mon, May 17, 2021 at 02:37:10PM +0800, Xiaofei Tan wrote:
> > > > Fix coding style issues of block comments, reported by checkpatch.pl.
> > > > Besides, add a period at the end of the sentenses.
[]
> > > > diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
[]
> > > > @@ -177,7 +177,8 @@ static void hvc_console_print(struct console *co, const char *b,
> > > > ? r = cons_ops[index]->put_chars(vtermnos[index], c, i);
> > > > ? if (r <= 0) {
> > > > ? /* throw away characters on error
> > > > - * but spin in case of -EAGAIN */
> > > > + * but spin in case of -EAGAIN.
> > > > + */
> > >
> > > How is this an improvement? First, the multi-line comment style is
> > >
> > > /*
> > > * ...
> > > */
> > >
> >
> > Yes, mostly we use this style. I can follow it if new version is needed.
>
> This is the preferred style outside of networking.
>
> > BTW, How about add the '/*' check into checkpatch.pl?
>
> Checkpatch already has too many checks IMO
I sometimes agree. What checkpatch messages do you think are excessive?
> and I'm a bit surprised that
> it doesn't check this already. Perhaps it's because you used the -f to
> run checkpatch on in-kernel code, which you should not.
Likely not. If it was run on a suggested patch, checkpatch doesn't emit
many messages on unmodified patch context lines. And it shouldn't.
> it's just that you
> introduce noise in the logs and do pointless changes of context which
> makes it harder to use tools like git blame and makes backporting harder
> for no good reason.
Pretty pointless metric IMO. Context changes in comments are mostly harmless.
IMO: backporting of these sorts non-bug fix changes is done _far_ too often.
Hi Johan,
On 2021/5/20 21:52, Johan Hovold wrote:
> On Thu, May 20, 2021 at 09:21:25PM +0800, Xiaofei Tan wrote:
>
>>> Checkpatch already has too many checks IMO and I'm a bit surprised that
>>> it doesn't check this already. Perhaps it's because you used the -f to
>>> run checkpatch on in-kernel code, which you should not.
>>>
>>>>> Second, that sentence is not capitalised so why do add a period?
>>>>>
>>>>
>>>> How about capitalize the sentence, or just remove the period ?
>>>
>>> How about just leaving this unchanged?
>>
>> OK
>> And I will keep the patch 8/9, and combine space issues into
>> one new patch, and remove the others.
>
> Yeah, 8/9 is arguably a fix even if it's for a very minor issue
> (repeated words in a comment).
>
> It doesn't look like any of the white space issues are worth fixing,
> though. Such pedantry can usually be addressed when the code in question
> is being modified for other reasons.
>
OK, it is reasonable. thanks.
> Johan
>
> .
>
On Mon, May 17, 2021 at 02:37:04PM +0800, Xiaofei Tan wrote:
> Fix some issues reported by checkpatch.pl. All of them are
> coding style issues, no function changes.
>
> Xiaofei Tan (9):
> tty: hvc_console: Fix spaces required around that '='
> tty: hvc_console: Fix "foo * bar" should be "foo *bar"
> tty: hvc_console: Remove trailing whitespace
> tty: hvc_console: Fix issues of code indent should use tabs
> tty: hvc_console: Delete spaces prohibited around open parenthesis '('
> and ')'
> tty: hvc_console: Fix coding style issues of block comments
> tty: hvc_console: Add a blank line after declarations
> tty: hvc_console: Remove the repeated words 'no' and 'from'
> tty: hvc_console: Move open brace { on the previous line
>
> drivers/tty/hvc/hvc_console.c | 37 ++++++++++++++++++++++---------------
> 1 file changed, 22 insertions(+), 15 deletions(-)
Do you use this driver? If so, great, I'm sure there are other "real"
issues in it that need some work. But as Johan points out, doing
drive-by checkpatch cleanups on random files that you do not use, isn't
the best thing to do.
If you just want to do this type of work, please do so in
drivers/staging/ as it is most welcome there if you wish to get involved
in kernel work to get experience before doing "real" stuff.
thanks,
g
reg k-h
Hi Greg,
On 2021/5/20 23:11, Greg KH wrote:
> On Mon, May 17, 2021 at 02:37:04PM +0800, Xiaofei Tan wrote:
>> Fix some issues reported by checkpatch.pl. All of them are
>> coding style issues, no function changes.
>>
>> Xiaofei Tan (9):
>> tty: hvc_console: Fix spaces required around that '='
>> tty: hvc_console: Fix "foo * bar" should be "foo *bar"
>> tty: hvc_console: Remove trailing whitespace
>> tty: hvc_console: Fix issues of code indent should use tabs
>> tty: hvc_console: Delete spaces prohibited around open parenthesis '('
>> and ')'
>> tty: hvc_console: Fix coding style issues of block comments
>> tty: hvc_console: Add a blank line after declarations
>> tty: hvc_console: Remove the repeated words 'no' and 'from'
>> tty: hvc_console: Move open brace { on the previous line
>>
>> drivers/tty/hvc/hvc_console.c | 37 ++++++++++++++++++++++---------------
>> 1 file changed, 22 insertions(+), 15 deletions(-)
>
> Do you use this driver?
No, i don't use it.
If so, great, I'm sure there are other "real"
> issues in it that need some work. But as Johan points out, doing
> drive-by checkpatch cleanups on random files that you do not use, isn't
> the best thing to do.
>
Sure
> If you just want to do this type of work, please do so in
> drivers/staging/ as it is most welcome there if you wish to get involved
> in kernel work to get experience before doing "real" stuff.
>
OK, thanks.
> thanks,
> g
> reg k-h
>
> .
>
On Thu, May 20, 2021 at 08:21:39AM -0700, Joe Perches wrote:
> On Thu, 2021-05-20 at 10:21 +0200, Johan Hovold wrote:
> > On Tue, May 18, 2021 at 12:01:22PM +0800, Xiaofei Tan wrote:
> > > On 2021/5/17 22:15, Johan Hovold wrote:
> > > > How is this an improvement? First, the multi-line comment style is
> > > >
> > > > /*
> > > > * ...
> > > > */
> > > >
> > >
> > > Yes, mostly we use this style. I can follow it if new version is needed.
> >
> > This is the preferred style outside of networking.
> >
> > > BTW, How about add the '/*' check into checkpatch.pl?
> >
> > Checkpatch already has too many checks IMO
>
> I sometimes agree. What checkpatch messages do you think are excessive?
The "unsigned" -> "unsigned int" one comes to mind (at least when
running with -f).
Most of the questionable ones are probably hidden behind --subjective,
but due to the unfortunate alias of that switch as --strict, people
don't get the message to use their own judgement and instead think
they'll get a gold star for "full compliance".
So my issue isn't so much which checkpatch itself rather than with how
it is being used and promoted, for example, to introduce aspiring
developers to kernel development in staging.
It's a great tool to run on your own patches before submission (as was
originally intended judging by the apt name), but if I could change
something I'd drop the --strict alias for the --subjective checks and
disable that switch for staging.
Perhaps also add a warning or similar when running with -f on in-tree
code outside of staging.
> > and I'm a bit surprised that
> > it doesn't check this already. Perhaps it's because you used the -f to
> > run checkpatch on in-kernel code, which you should not.
>
> Likely not. If it was run on a suggested patch, checkpatch doesn't emit
> many messages on unmodified patch context lines. And it shouldn't.
Right, but here it appears to have been run using -f on in-tree code.
You could still check for this when adding new comments, and perhaps it
already does.
> > it's just that you
> > introduce noise in the logs and do pointless changes of context which
> > makes it harder to use tools like git blame and makes backporting harder
> > for no good reason.
>
> Pretty pointless metric IMO. Context changes in comments are mostly harmless.
This isn't just about comment changes but the whole array of
white-space shifting and other pendantry. And also reformatted comments
makes it harder to do code forensics.
> IMO: backporting of these sorts non-bug fix changes is done _far_ too often.
I have yet to see AUTOSEL pick up white-space cleanups but there are
certainly a few non-bug-fix patches currently being backported.
Johan