All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Stone <ahs3 at redhat.com>
To: devel@acpica.org
Subject: Re: [Devel] [PATCH v3 1/9] ACPI: fix all errors reported by cleanpatch.pl in osl.c
Date: Wed, 04 Mar 2015 23:56:15 +0000	[thread overview]
Message-ID: <54F79B9C.1030901@redhat.com> (raw)
In-Reply-To: 1528624.HcuCny6IaW@vostro.rjw.lan

[-- Attachment #1: Type: text/plain, Size: 1866 bytes --]

On 03/04/2015 04:04 PM, Rafael J. Wysocki wrote:
> On Tuesday, February 24, 2015 05:36:17 PM al.stone(a)linaro.org wrote:
>> From: Al Stone <al.stone(a)linaro.org>
>>
>> In preparation for later splitting out some of the arch-dependent code from
>> osl.c, clean up the errors reported by checkpatch.pl.  They fell into these
>> classes:
>>
>>    -- remove the FSF address from the GPL notice
>>    -- "foo * bar" should be "foo *bar" (and the ** variation of same)
>>    -- a return is not a function, so parentheses are not required.
>>
>> Signed-off-by: Al Stone <al.stone(a)linaro.org>
> 
> checkpatch.pl is irrelevant here.  You're trying to make the coding style be
> more consistent with the coding style of the rest of the kernel.
> 
> The warnings from checkpatch.pl are meaningless for the existing code, so
> it should not be used to justify changes in that code.
> 
> Of course, the same applies to patches [2-4/9].
> 
> 

Okay, I'm puzzled.  In the last version of these patches, I asked if I
should clean up osl.c as long as I was creating the new osi.c file.  I
understood the reply to mean it would also be good to correct osl.c [0]
from checkpatch's point of view.  I took that to mean errors (patch [1/9])
and warnings (patches [2-4/9]) -- so that's what I did.  What did I
misunderstand from that reply?

If these changes are objectionable, then I'll drop these from the next
version of the patch set; I'm not hung up on insisting on either of the
kernel's or ACPI's coding style -- I try to adapt as needed.  I only did
the patches because I thought it was helping out with some long-term
maintenance type work.


[0] https://lkml.org/lkml/2015/2/4/749

-- 
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------

WARNING: multiple messages have this Message-ID (diff)
From: Al Stone <ahs3@redhat.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>, al.stone@linaro.org
Cc: lenb@kernel.org, catalin.marinas@arm.com, will.deacon@arm.com,
	robert.moore@intel.com, tony.luck@intel.com,
	fenghua.yu@intel.com, linux-ia64@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	devel@acpica.org, linux-arm-kernel@lists.infradead.org,
	linaro-acpi@lists.linaro.org, linaro-kernel@lists.linaro.org,
	patches@linaro.org
Subject: Re: [PATCH v3 1/9] ACPI: fix all errors reported by cleanpatch.pl in osl.c
Date: Wed, 04 Mar 2015 16:56:12 -0700	[thread overview]
Message-ID: <54F79B9C.1030901@redhat.com> (raw)
In-Reply-To: <1528624.HcuCny6IaW@vostro.rjw.lan>

On 03/04/2015 04:04 PM, Rafael J. Wysocki wrote:
> On Tuesday, February 24, 2015 05:36:17 PM al.stone@linaro.org wrote:
>> From: Al Stone <al.stone@linaro.org>
>>
>> In preparation for later splitting out some of the arch-dependent code from
>> osl.c, clean up the errors reported by checkpatch.pl.  They fell into these
>> classes:
>>
>>    -- remove the FSF address from the GPL notice
>>    -- "foo * bar" should be "foo *bar" (and the ** variation of same)
>>    -- a return is not a function, so parentheses are not required.
>>
>> Signed-off-by: Al Stone <al.stone@linaro.org>
> 
> checkpatch.pl is irrelevant here.  You're trying to make the coding style be
> more consistent with the coding style of the rest of the kernel.
> 
> The warnings from checkpatch.pl are meaningless for the existing code, so
> it should not be used to justify changes in that code.
> 
> Of course, the same applies to patches [2-4/9].
> 
> 

Okay, I'm puzzled.  In the last version of these patches, I asked if I
should clean up osl.c as long as I was creating the new osi.c file.  I
understood the reply to mean it would also be good to correct osl.c [0]
from checkpatch's point of view.  I took that to mean errors (patch [1/9])
and warnings (patches [2-4/9]) -- so that's what I did.  What did I
misunderstand from that reply?

If these changes are objectionable, then I'll drop these from the next
version of the patch set; I'm not hung up on insisting on either of the
kernel's or ACPI's coding style -- I try to adapt as needed.  I only did
the patches because I thought it was helping out with some long-term
maintenance type work.


[0] https://lkml.org/lkml/2015/2/4/749

-- 
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3@redhat.com
-----------------------------------

WARNING: multiple messages have this Message-ID (diff)
From: Al Stone <ahs3@redhat.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>, al.stone@linaro.org
Cc: lenb@kernel.org, catalin.marinas@arm.com, will.deacon@arm.com,
	robert.moore@intel.com, tony.luck@intel.com,
	fenghua.yu@intel.com, linux-ia64@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	devel@acpica.org, linux-arm-kernel@lists.infradead.org,
	linaro-acpi@lists.linaro.org, linaro-kernel@lists.linaro.org,
	patches@linaro.org
Subject: Re: [PATCH v3 1/9] ACPI: fix all errors reported by cleanpatch.pl in osl.c
Date: Wed, 04 Mar 2015 23:56:12 +0000	[thread overview]
Message-ID: <54F79B9C.1030901@redhat.com> (raw)
In-Reply-To: <1528624.HcuCny6IaW@vostro.rjw.lan>

On 03/04/2015 04:04 PM, Rafael J. Wysocki wrote:
> On Tuesday, February 24, 2015 05:36:17 PM al.stone@linaro.org wrote:
>> From: Al Stone <al.stone@linaro.org>
>>
>> In preparation for later splitting out some of the arch-dependent code from
>> osl.c, clean up the errors reported by checkpatch.pl.  They fell into these
>> classes:
>>
>>    -- remove the FSF address from the GPL notice
>>    -- "foo * bar" should be "foo *bar" (and the ** variation of same)
>>    -- a return is not a function, so parentheses are not required.
>>
>> Signed-off-by: Al Stone <al.stone@linaro.org>
> 
> checkpatch.pl is irrelevant here.  You're trying to make the coding style be
> more consistent with the coding style of the rest of the kernel.
> 
> The warnings from checkpatch.pl are meaningless for the existing code, so
> it should not be used to justify changes in that code.
> 
> Of course, the same applies to patches [2-4/9].
> 
> 

Okay, I'm puzzled.  In the last version of these patches, I asked if I
should clean up osl.c as long as I was creating the new osi.c file.  I
understood the reply to mean it would also be good to correct osl.c [0]
from checkpatch's point of view.  I took that to mean errors (patch [1/9])
and warnings (patches [2-4/9]) -- so that's what I did.  What did I
misunderstand from that reply?

If these changes are objectionable, then I'll drop these from the next
version of the patch set; I'm not hung up on insisting on either of the
kernel's or ACPI's coding style -- I try to adapt as needed.  I only did
the patches because I thought it was helping out with some long-term
maintenance type work.


[0] https://lkml.org/lkml/2015/2/4/749

-- 
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3@redhat.com
-----------------------------------

WARNING: multiple messages have this Message-ID (diff)
From: ahs3@redhat.com (Al Stone)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 1/9] ACPI: fix all errors reported by cleanpatch.pl in osl.c
Date: Wed, 04 Mar 2015 16:56:12 -0700	[thread overview]
Message-ID: <54F79B9C.1030901@redhat.com> (raw)
In-Reply-To: <1528624.HcuCny6IaW@vostro.rjw.lan>

On 03/04/2015 04:04 PM, Rafael J. Wysocki wrote:
> On Tuesday, February 24, 2015 05:36:17 PM al.stone at linaro.org wrote:
>> From: Al Stone <al.stone@linaro.org>
>>
>> In preparation for later splitting out some of the arch-dependent code from
>> osl.c, clean up the errors reported by checkpatch.pl.  They fell into these
>> classes:
>>
>>    -- remove the FSF address from the GPL notice
>>    -- "foo * bar" should be "foo *bar" (and the ** variation of same)
>>    -- a return is not a function, so parentheses are not required.
>>
>> Signed-off-by: Al Stone <al.stone@linaro.org>
> 
> checkpatch.pl is irrelevant here.  You're trying to make the coding style be
> more consistent with the coding style of the rest of the kernel.
> 
> The warnings from checkpatch.pl are meaningless for the existing code, so
> it should not be used to justify changes in that code.
> 
> Of course, the same applies to patches [2-4/9].
> 
> 

Okay, I'm puzzled.  In the last version of these patches, I asked if I
should clean up osl.c as long as I was creating the new osi.c file.  I
understood the reply to mean it would also be good to correct osl.c [0]
from checkpatch's point of view.  I took that to mean errors (patch [1/9])
and warnings (patches [2-4/9]) -- so that's what I did.  What did I
misunderstand from that reply?

If these changes are objectionable, then I'll drop these from the next
version of the patch set; I'm not hung up on insisting on either of the
kernel's or ACPI's coding style -- I try to adapt as needed.  I only did
the patches because I thought it was helping out with some long-term
maintenance type work.


[0] https://lkml.org/lkml/2015/2/4/749

-- 
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3 at redhat.com
-----------------------------------

         reply	other threads:[~2015-03-04 23:56 UTC|newest]

Thread overview: 98+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-25  0:36 [PATCH v3 0/9] Start deprecating _OSI on new architectures al.stone
2015-02-25  0:36 ` al.stone at linaro.org
2015-02-25  0:36 ` al.stone
2015-02-25  0:36 ` [PATCH v3 1/9] ACPI: fix all errors reported by cleanpatch.pl in osl.c al.stone
2015-02-25  0:36   ` al.stone at linaro.org
2015-02-25  0:36   ` al.stone
2015-02-25 12:47   ` Hanjun Guo
2015-02-25 12:47     ` Hanjun Guo
2015-02-25 12:47     ` Hanjun Guo
2015-02-25 12:47     ` Hanjun Guo
2015-03-04 22:41   ` Rafael J. Wysocki
2015-03-04 23:04     ` Rafael J. Wysocki
2015-03-04 23:04     ` Rafael J. Wysocki
2015-03-04 23:56     ` Al Stone [this message]
2015-03-04 23:56       ` [Devel] " Al Stone
2015-03-04 23:56       ` Al Stone
2015-03-04 23:56       ` Al Stone
2015-03-05  0:25       ` Rafael J. Wysocki
2015-03-05  0:25         ` Rafael J. Wysocki
2015-03-05  0:25         ` Rafael J. Wysocki
2015-03-05  0:06         ` Al Stone
2015-03-05  0:06           ` [Devel] " Al Stone
2015-03-05  0:06           ` Al Stone
2015-03-05  0:06           ` Al Stone
2015-02-25  0:36 ` [PATCH v3 2/9] ACPI: clear up warnings on use of printk reported by checkpatch.pl al.stone
2015-02-25  0:36   ` al.stone at linaro.org
2015-02-25  0:36   ` al.stone
2015-02-25 12:55   ` Hanjun Guo
2015-02-25 12:55     ` Hanjun Guo
2015-02-25 12:55     ` Hanjun Guo
2015-02-25 12:55     ` Hanjun Guo
2015-02-25 20:56     ` Al Stone
2015-02-25 20:56       ` Al Stone
2015-02-25 20:56       ` Al Stone
2015-02-25 20:56       ` Al Stone
2015-02-25  0:36 ` [PATCH v3 3/9] ACPI: clean up checkpatch warnings for various bits of syntax al.stone
2015-02-25  0:36   ` al.stone at linaro.org
2015-02-25  0:36   ` al.stone
2015-02-25 12:59   ` [Linaro-acpi] " Hanjun Guo
2015-02-25 12:59     ` Hanjun Guo
2015-02-25 12:59     ` Hanjun Guo
2015-02-25 12:59     ` Hanjun Guo
2015-02-25  0:36 ` [PATCH v3 4/9] ACPI: clean up checkpatch warnings for items with possible semantic value al.stone
2015-02-25  0:36   ` al.stone at linaro.org
2015-02-25  0:36   ` al.stone
2015-02-25 13:08   ` [Linaro-acpi] " Hanjun Guo
2015-02-25 13:08     ` Hanjun Guo
2015-02-25 13:08     ` Hanjun Guo
2015-02-25 13:08     ` [Linaro-acpi] [PATCH v3 4/9] ACPI: clean up checkpatch warnings for items with possible semantic Hanjun Guo
2015-02-25 20:57     ` [Linaro-acpi] [PATCH v3 4/9] ACPI: clean up checkpatch warnings for items with possible semantic value Al Stone
2015-02-25 20:57       ` Al Stone
2015-02-25 20:57       ` Al Stone
2015-02-25 20:57       ` [Linaro-acpi] [PATCH v3 4/9] ACPI: clean up checkpatch warnings for items with possible semantic Al Stone
2015-02-25  0:36 ` [PATCH v3 5/9] ACPI: move acpi_os_handler() so it can be made arch-dependent later al.stone
2015-02-25  0:36   ` al.stone at linaro.org
2015-02-25  0:36   ` al.stone
2015-02-25 13:47   ` [Linaro-acpi] " Hanjun Guo
2015-02-25 13:47     ` Hanjun Guo
2015-02-25 13:47     ` Hanjun Guo
2015-02-25  0:36 ` [PATCH v3 6/9] ACPI: move _OSI support functions to allow arch-dependent implementation al.stone
2015-02-25  0:36   ` al.stone at linaro.org
2015-02-25  0:36   ` al.stone
2015-03-04 22:45   ` Rafael J. Wysocki
2015-03-04 23:09     ` Rafael J. Wysocki
2015-03-04 23:09     ` Rafael J. Wysocki
2015-02-25  0:36 ` [PATCH v3 7/9] ACPI: enable arch-specific compilation for _OSI and the blacklist al.stone
2015-02-25  0:36   ` al.stone at linaro.org
2015-02-25  0:36   ` al.stone
2015-03-04 22:48   ` Rafael J. Wysocki
2015-03-04 23:11     ` Rafael J. Wysocki
2015-03-04 23:11     ` Rafael J. Wysocki
2015-02-25  0:36 ` [PATCH v3 8/9] ACPI: arm64: use an arch-specific ACPI _OSI method and ACPI blacklist al.stone
2015-02-25  0:36   ` al.stone at linaro.org
2015-02-25  0:36   ` al.stone
2015-03-02 17:29   ` Will Deacon
2015-03-02 17:29     ` Will Deacon
2015-03-02 17:29     ` Will Deacon
2015-03-02 19:00     ` Al Stone
2015-03-02 19:00       ` Al Stone
2015-03-02 19:00       ` Al Stone
2015-03-04 22:51       ` Rafael J. Wysocki
2015-03-04 23:14         ` Rafael J. Wysocki
2015-03-04 23:14         ` Rafael J. Wysocki
2015-03-05 10:17         ` Will Deacon
2015-03-05 10:17           ` Will Deacon
2015-03-05 10:17           ` Will Deacon
2015-03-05 12:56           ` Rafael J. Wysocki
2015-03-05 12:56             ` Rafael J. Wysocki
2015-03-05 12:56             ` Rafael J. Wysocki
2015-03-04 22:58   ` Rafael J. Wysocki
2015-03-04 23:16     ` Rafael J. Wysocki
2015-03-04 23:16     ` Rafael J. Wysocki
2015-02-25  0:36 ` [PATCH v3 9/9] ACPI: arm64: use "Linux" as ACPI_OS_NAME for _OS on arm64 al.stone
2015-02-25  0:36   ` al.stone at linaro.org
2015-02-25  0:36   ` al.stone
2015-03-04 22:58   ` Rafael J. Wysocki
2015-03-04 23:17     ` Rafael J. Wysocki
2015-03-04 23:17     ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54F79B9C.1030901@redhat.com \
    --to=devel@acpica.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.