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: Thu, 05 Mar 2015 00:06:17 +0000 [thread overview]
Message-ID: <54F79DF6.60204@redhat.com> (raw)
In-Reply-To: 3363575.FHEZ9Qjrf1@vostro.rjw.lan
[-- Attachment #1: Type: text/plain, Size: 2685 bytes --]
On 03/04/2015 05:25 PM, Rafael J. Wysocki wrote:
> On Wednesday, March 04, 2015 04:56:12 PM Al Stone wrote:
>> 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.
>
> The changes are basically OK, but the justification is bogus to me.
> "I'm making the chagne, because checkpatch.pl told me so" is a pretty bad
> explanation in my view. It is much better to say "This file does not
> adhere to the general kernel coding style and since I'm going to split it
> into pieces and I want those pieces to follow the coding style more closely,
> make changes as follows."
>
> So this is more about the changelogs (and subjects) than the code changes
> themselves.
Aha. That makes much more sense to me. Sorry if I was being a bit dense;
I'll rev these for the next version so it's far clearer. Thanks for being
patient :).
--
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>
Cc: al.stone@linaro.org, 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 17:06:14 -0700 [thread overview]
Message-ID: <54F79DF6.60204@redhat.com> (raw)
In-Reply-To: <3363575.FHEZ9Qjrf1@vostro.rjw.lan>
On 03/04/2015 05:25 PM, Rafael J. Wysocki wrote:
> On Wednesday, March 04, 2015 04:56:12 PM Al Stone wrote:
>> 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.
>
> The changes are basically OK, but the justification is bogus to me.
> "I'm making the chagne, because checkpatch.pl told me so" is a pretty bad
> explanation in my view. It is much better to say "This file does not
> adhere to the general kernel coding style and since I'm going to split it
> into pieces and I want those pieces to follow the coding style more closely,
> make changes as follows."
>
> So this is more about the changelogs (and subjects) than the code changes
> themselves.
Aha. That makes much more sense to me. Sorry if I was being a bit dense;
I'll rev these for the next version so it's far clearer. Thanks for being
patient :).
--
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>
Cc: al.stone@linaro.org, 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: Thu, 05 Mar 2015 00:06:14 +0000 [thread overview]
Message-ID: <54F79DF6.60204@redhat.com> (raw)
In-Reply-To: <3363575.FHEZ9Qjrf1@vostro.rjw.lan>
On 03/04/2015 05:25 PM, Rafael J. Wysocki wrote:
> On Wednesday, March 04, 2015 04:56:12 PM Al Stone wrote:
>> 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.
>
> The changes are basically OK, but the justification is bogus to me.
> "I'm making the chagne, because checkpatch.pl told me so" is a pretty bad
> explanation in my view. It is much better to say "This file does not
> adhere to the general kernel coding style and since I'm going to split it
> into pieces and I want those pieces to follow the coding style more closely,
> make changes as follows."
>
> So this is more about the changelogs (and subjects) than the code changes
> themselves.
Aha. That makes much more sense to me. Sorry if I was being a bit dense;
I'll rev these for the next version so it's far clearer. Thanks for being
patient :).
--
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 17:06:14 -0700 [thread overview]
Message-ID: <54F79DF6.60204@redhat.com> (raw)
In-Reply-To: <3363575.FHEZ9Qjrf1@vostro.rjw.lan>
On 03/04/2015 05:25 PM, Rafael J. Wysocki wrote:
> On Wednesday, March 04, 2015 04:56:12 PM Al Stone wrote:
>> 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.
>
> The changes are basically OK, but the justification is bogus to me.
> "I'm making the chagne, because checkpatch.pl told me so" is a pretty bad
> explanation in my view. It is much better to say "This file does not
> adhere to the general kernel coding style and since I'm going to split it
> into pieces and I want those pieces to follow the coding style more closely,
> make changes as follows."
>
> So this is more about the changelogs (and subjects) than the code changes
> themselves.
Aha. That makes much more sense to me. Sorry if I was being a bit dense;
I'll rev these for the next version so it's far clearer. Thanks for being
patient :).
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3 at redhat.com
-----------------------------------
next prev reply other threads:[~2015-03-05 0:06 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
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 [this message]
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=54F79DF6.60204@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.