From: Darren Hart <dvhart@infradead.org>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Henrique de Moraes Holschuh <ibm-acpi@hmh.eng.br>,
Bastien Nocera <hadess@hadess.net>,
ibm-acpi-devel@lists.sourceforge.net,
platform-driver-x86@vger.kernel.org,
kernel-janitors@vger.kernel.org,
Stephen Rothwell <sfr@canb.auug.org.au>,
Rafael Wysocki <rjw@rjwysocki.net>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [patch 1/2] thinkpad_acpi: signedness bugs getting current_mode
Date: Sat, 14 Mar 2015 21:06:12 +0000 [thread overview]
Message-ID: <20150314210612.GA26465@fury.dvhart.com> (raw)
In-Reply-To: <20150311093450.GA3564@mwanda>
On Wed, Mar 11, 2015 at 12:34:50PM +0300, Dan Carpenter wrote:
> This needs to be signed for the error handling to work. Valid modes are
> small positive integers.
>
> Fixes: b790ceeb0fd9 ('thinkpad_acpi: Add adaptive_kbd_mode sysfs attr')
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
Question for HPA, Rafael, and Stephen,
I recall discussion at Kernel Summit 2014 about not rebasing or merging patches
when sending to Linus, that he'd prefer to see the history. I recall Stephen
mentioning something similar for linux-next.
That said, I've seen varying behavior among maintainers with respect to fixes
like this one from Dan. This patch fixes a patch that currently only exists in
my for-next and Stephen's linux-next trees.
What is the preference. Do I just queue it up to for-next as is (this is what
I've done for now), or do I roll it into the referred patch causing the error
and credit Dan with the fixup?
Left to my own devices I would prefer not to introduce bugs into the kernel
history if I can help it. That said, I don't want to make extra work for Stephen
or Linus.
What's the prefered best practice here?
> diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
> index 56eaddc..024861d 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -2938,7 +2938,7 @@ static ssize_t adaptive_kbd_mode_show(struct device *dev,
> struct device_attribute *attr,
> char *buf)
> {
> - u32 current_mode;
> + int current_mode;
>
> current_mode = adaptive_keyboard_get_mode();
> if (current_mode < 0)
> @@ -3621,7 +3621,7 @@ static int adaptive_keyboard_get_next_mode(int mode)
>
> static bool adaptive_keyboard_hotkey_notify_hotkey(unsigned int scancode)
> {
> - u32 current_mode = 0;
> + int current_mode = 0;
> int new_mode = 0;
> int keycode;
>
>
--
Darren Hart
Intel Open Source Technology Center
WARNING: multiple messages have this Message-ID (diff)
From: Darren Hart <dvhart@infradead.org>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Henrique de Moraes Holschuh <ibm-acpi@hmh.eng.br>,
Bastien Nocera <hadess@hadess.net>,
ibm-acpi-devel@lists.sourceforge.net,
platform-driver-x86@vger.kernel.org,
kernel-janitors@vger.kernel.org,
Stephen Rothwell <sfr@canb.auug.org.au>,
Rafael Wysocki <rjw@rjwysocki.net>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [patch 1/2] thinkpad_acpi: signedness bugs getting current_mode
Date: Sat, 14 Mar 2015 14:06:12 -0700 [thread overview]
Message-ID: <20150314210612.GA26465@fury.dvhart.com> (raw)
In-Reply-To: <20150311093450.GA3564@mwanda>
On Wed, Mar 11, 2015 at 12:34:50PM +0300, Dan Carpenter wrote:
> This needs to be signed for the error handling to work. Valid modes are
> small positive integers.
>
> Fixes: b790ceeb0fd9 ('thinkpad_acpi: Add adaptive_kbd_mode sysfs attr')
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
Question for HPA, Rafael, and Stephen,
I recall discussion at Kernel Summit 2014 about not rebasing or merging patches
when sending to Linus, that he'd prefer to see the history. I recall Stephen
mentioning something similar for linux-next.
That said, I've seen varying behavior among maintainers with respect to fixes
like this one from Dan. This patch fixes a patch that currently only exists in
my for-next and Stephen's linux-next trees.
What is the preference. Do I just queue it up to for-next as is (this is what
I've done for now), or do I roll it into the referred patch causing the error
and credit Dan with the fixup?
Left to my own devices I would prefer not to introduce bugs into the kernel
history if I can help it. That said, I don't want to make extra work for Stephen
or Linus.
What's the prefered best practice here?
> diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
> index 56eaddc..024861d 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -2938,7 +2938,7 @@ static ssize_t adaptive_kbd_mode_show(struct device *dev,
> struct device_attribute *attr,
> char *buf)
> {
> - u32 current_mode;
> + int current_mode;
>
> current_mode = adaptive_keyboard_get_mode();
> if (current_mode < 0)
> @@ -3621,7 +3621,7 @@ static int adaptive_keyboard_get_next_mode(int mode)
>
> static bool adaptive_keyboard_hotkey_notify_hotkey(unsigned int scancode)
> {
> - u32 current_mode = 0;
> + int current_mode = 0;
> int new_mode = 0;
> int keycode;
>
>
--
Darren Hart
Intel Open Source Technology Center
next prev parent reply other threads:[~2015-03-14 21:06 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-11 9:34 [patch 1/2] thinkpad_acpi: signedness bugs getting current_mode Dan Carpenter
2015-03-11 9:34 ` Dan Carpenter
2015-03-11 10:07 ` Bastien Nocera
2015-03-11 10:07 ` Bastien Nocera
2015-03-11 10:28 ` Henrique de Moraes Holschuh
2015-03-11 10:28 ` Henrique de Moraes Holschuh
2015-03-14 19:03 ` Darren Hart
2015-03-14 19:03 ` Darren Hart
2015-03-14 21:06 ` Darren Hart [this message]
2015-03-14 21:06 ` Darren Hart
2015-03-15 2:46 ` Stephen Rothwell
2015-03-15 2:46 ` Stephen Rothwell
2015-03-15 2:48 ` Stephen Rothwell
2015-03-15 2:48 ` Stephen Rothwell
2015-03-19 3:42 ` Darren Hart
2015-03-19 3:42 ` Darren Hart
2015-03-22 18:58 ` [ibm-acpi-devel] " Henrique de Moraes Holschuh
2015-03-22 18:58 ` Henrique de Moraes Holschuh
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=20150314210612.GA26465@fury.dvhart.com \
--to=dvhart@infradead.org \
--cc=dan.carpenter@oracle.com \
--cc=hadess@hadess.net \
--cc=hpa@zytor.com \
--cc=ibm-acpi-devel@lists.sourceforge.net \
--cc=ibm-acpi@hmh.eng.br \
--cc=kernel-janitors@vger.kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=sfr@canb.auug.org.au \
/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.