Skip to contentSkip to conversation

ACPI & Power Management Patches for Linux 3.5-rc4

PATCH In review Len Brown 10 participants 28 messages Jun 30, 2012 – Aug 8, 2012

Subsystems (4)
lore
Share & tools
lore

Len Brown

author reviewer
#0 lore raw

Here are some bug fixes queued for 3.5-rc4 Please let me know if you see troubles with any of them.

thanks,
Len Brown, Intel Open Source Technology Center

author reviewer
#1 lore raw

PATCH 1/8 ACPI sysfs.c strlen fix

From: Pavel Vasilyev <[email protected]>

Current code is ignoring the last character of "enable" and "disable" in comparisons.

https://bugzilla.kernel.org/show_bug.cgi?id=33732

---
 drivers/acpi/sysfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/acpi/sysfs.c +2 -2
index 9f66181..240a244 100644
@@ -173,7 +173,7 @@ static int param_set_trace_state(const char *val, struct kernel_param *kp)
 {
 	int result = 0;
 
-	if (!strncmp(val, "enable", strlen("enable") - 1)) {
+	if (!strncmp(val, "enable", strlen("enable"))) {
 		result = acpi_debug_trace(trace_method_name, trace_debug_level,
 					  trace_debug_layer, 0);
 		if (result)
@@ -181,7 +181,7 @@ static int param_set_trace_state(const char *val, struct kernel_param *kp)
 		goto exit;
 	}
 
-	if (!strncmp(val, "disable", strlen("disable") - 1)) {
+	if (!strncmp(val, "disable", strlen("disable"))) {
 		int name = 0;
 		result = acpi_debug_trace((char *)&name, trace_debug_level,
 					  trace_debug_layer, 0);
Signature · 1 line
1.7.11.1.104.ge7b44f1
#2 lore raw

Re: [linux-pm] [PATCH 1/8] ACPI sysfs.c strlen fix

Quoted 17 lines · Len Brown

From: Pavel Vasilyev <[email protected]>

Current code is ignoring the last character of "enable" and "disable" in comparisons.

https://bugzilla.kernel.org/show_bug.cgi?id=33732

---
 drivers/acpi/sysfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/acpi/sysfs.c +0 -0
index 9f66181..240a244 100644

drivers/acpi/sysfs.c static int param_set_trace_state(const char *val, struct kernel_param *kp) · line 176

Quoted 5 lines
drivers/acpi/sysfs.c +1 -1
@@ -173,7 +173,7 @@ static int param_set_trace_state(const char *val, struct kernel_param *kp)
 {
 	int result = 0;
 
-	if (!strncmp(val, "enable", strlen("enable") - 1)) {
+	if (!strncmp(val, "enable", strlen("enable"))) {

Ironically, this is the less efficient of two possible fixes.

It would have been better to leave the "- 1" in place and change strlen to sizeof. That's probably what the original author had in mind.

Alan Stern

author reviewer
#3 lore raw

PATCH 1/1 ACPI: replace strlen("string") with sizeof("string") -1

...both give the number of chars in the string
without the '\0', as strncmp() wants,
but sizeof() is compile-time.

---
 drivers/acpi/sysfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/acpi/sysfs.c +0 -0
index 240a244..7c3f98b 100644
@@ -173,7 +173,7 @@ static int param_set_trace_state(const char *val,

struct kernel_param *kp)
{
int result = 0;

- if (!strncmp(val, "enable", strlen("enable"))) {
+ if (!strncmp(val, "enable", sizeof("enable") - 1)) {
result = acpi_debug_trace(trace_method_name, trace_debug_level,
trace_debug_layer, 0);
if (result)
@@ -181,7 +181,7 @@ static int param_set_trace_state(const char *val, struct kernel_param *kp)
goto exit;
}

- if (!strncmp(val, "disable", strlen("disable"))) {
+ if (!strncmp(val, "disable", sizeof("disable") - 1)) {
int name = 0;
result = acpi_debug_trace((char *)&name, trace_debug_level,
trace_debug_layer, 0);

Signature · 1 line
1.7.12.rc0
#4 lore raw

Re: [PATCH] ACPI: replace strlen("string") with sizeof("string") -1

Quoted 3 lines · Len Brown

...both give the number of chars in the string
without the '\0', as strncmp() wants,
but sizeof() is compile-time.

I thought gcc optimised strlen("string literal") into a compile time constant too. It does in a little userspace test I just wrote, but I didn't look at its behaviour with the kernel's strlen.

Ian.

#5 lore raw

Re: [PATCH] ACPI: replace strlen("string") with sizeof("string") -1

Quoted 3 lines · Ian Campbell

I thought gcc optimised strlen("string literal") into a compile time constant too. It does in a little userspace test I just wrote, but I didn't look at its behaviour with the kernel's strlen.

It depends whether you use the built-in strlen() or not. AFAIK the kernel does not use the built-in variant.

Signature · 2 lines
Thanks,
//richard
#6 lore raw

Re: [linux-pm] [PATCH] ACPI: replace strlen("string") with sizeof("string") -1

In reply to Len Brown
Quoted 3 lines · Len Brown

...both give the number of chars in the string
without the '\0', as strncmp() wants,
but sizeof() is compile-time.

What about introducing something like streq() to do this automatically? This is ugly....

#define streq(a, b) ... if (_buildin_constant(b)) ...

?

Review

Quoted 2 lines
(quoted diff) +1 -1
-	if (!strncmp(val, "enable", strlen("enable"))) {
+	if (!strncmp(val, "enable", sizeof("enable") - 1)) {

Pavel

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
#7 lore raw

Re: [linux-pm] [PATCH] ACPI: replace strlen("string") with sizeof("string") -1

Quoted 8 lines · Pavel Machek
Quoted 3 lines · Len Brown

...both give the number of chars in the string
without the '\0', as strncmp() wants,
but sizeof() is compile-time.

What about introducing something like streq() to do this automatically? This is ugly....

Quoted 6 lines

#define streq(a, b) ... if (_buildin_constant(b)) ...

?

Review

Quoted 2 lines
(quoted diff) +1 -1
-	if (!strncmp(val, "enable", strlen("enable"))) {
+	if (!strncmp(val, "enable", sizeof("enable") - 1)) {

While you're at it, there's no point using strncmp when you know the length of one of the strings beforehand. Just use memcmp, and don't subtract 1 from the sizeof value.

Alan Stern

#8 lore raw

Re: [linux-pm] [PATCH] ACPI: replace strlen("string") with sizeof("string") -1

06.08.2012 18:36, Alan Stern пишет:

Quoted 12 lines · Pavel Machek
Quoted 11 lines · Len Brown
Quoted 3 lines

...both give the number of chars in the string
without the '\0', as strncmp() wants,
but sizeof() is compile-time.

What about introducing something like streq() to do this automatically? This is ugly....

#define streq(a, b) ... if (_buildin_constant(b)) ...

Quoted 8 lines
Quoted 4 lines

?

Review

Quoted 2 lines
(quoted diff) +1 -1
-	if (!strncmp(val, "enable", strlen("enable"))) {
+	if (!strncmp(val, "enable", sizeof("enable") - 1)) {

While you're at it, there's no point using strncmp when you know the length of one of the strings beforehand. Just use memcmp, and don't subtract 1 from the sizeof value.

http://www.gossamer-threads.com/lists/engine?do=post_attachment;postatt_id=41157;list=linux

:)

Signature · 1 line
                                                         Pavel.
#9 lore raw

Re: [linux-pm] [PATCH] ACPI: replace strlen("string") with sizeof("string") -1

Quoted 15 lines · Pavel Vasilyev

06.08.2012 18:36, Alan Stern пишет:

Quoted 14 lines · Pavel Machek
Quoted 13 lines · Len Brown
Quoted 3 lines

...both give the number of chars in the string
without the '\0', as strncmp() wants,
but sizeof() is compile-time.

What about introducing something like streq() to do this automatically? This is ugly....

#define streq(a, b) ... if (_buildin_constant(b)) ...

?

Quoted 8 lines
Quoted 6 lines
Quoted 2 lines

Review

Quoted 2 lines
(quoted diff) +1 -1
-	if (!strncmp(val, "enable", strlen("enable"))) {
+	if (!strncmp(val, "enable", sizeof("enable") - 1)) {

While you're at it, there's no point using strncmp when you know the length of one of the strings beforehand. Just use memcmp, and don't subtract 1 from the sizeof value.

http://www.gossamer-threads.com/lists/engine?do=post_attachment;postatt_id=41157;list=linux

Interestingly, many (all?) of the changes in that patch are wrong because they don't try to match the terminating '\0'. As a result, they will match against extensions of the target string as well as the target string itself.

Alan Stern

#10 lore raw

Re: [linux-pm] [PATCH] ACPI: replace strlen("string") with sizeof("string") -1

06.08.2012 20:28, Alan Stern пишет:

Quoted 24 lines · Pavel Vasilyev
Quoted 23 lines

06.08.2012 18:36, Alan Stern пишет:

Quoted 20 lines · Pavel Machek
Quoted 9 lines · Len Brown
Quoted 3 lines

...both give the number of chars in the string
without the '\0', as strncmp() wants,
but sizeof() is compile-time.

What about introducing something like streq() to do this automatically? This is ugly....

Quoted 6 lines

#define streq(a, b) ... if (_buildin_constant(b)) ...

?

Review

Quoted 2 lines
(quoted diff) +1 -1
-	if (!strncmp(val, "enable", strlen("enable"))) {
+	if (!strncmp(val, "enable", sizeof("enable") - 1)) {

While you're at it, there's no point using strncmp when you know the length of one of the strings beforehand. Just use memcmp, and don't subtract 1 from the sizeof value.

Quoted 7 lines
Quoted 1 line

http://www.gossamer-threads.com/lists/engine?do=post_attachment;postatt_id=41157;list=linux

Interestingly, many (all?) of the changes in that patch are wrong because they don't try to match the terminating '\0'. As a result, they will match against extensions of the target string as well as the target string itself.

strNcmp compare N bytes - http://lxr.linux.no/#linux+v3.5/lib/string.c#L270
memcmp compare N bytes - http://lxr.linux.no/#linux+v3.5/lib/string.c#L651

Signature · 1 line
                                                         Pavel.
#11 lore raw

Re: [linux-pm] [PATCH] ACPI: replace strlen("string") with sizeof("string") -1

Quoted 10 lines · Pavel Vasilyev
Quoted 7 lines
Quoted 1 line

http://www.gossamer-threads.com/lists/engine?do=post_attachment;postatt_id=41157;list=linux

Interestingly, many (all?) of the changes in that patch are wrong because they don't try to match the terminating '\0'. As a result, they will match against extensions of the target string as well as the target string itself.

strNcmp compare N bytes - http://lxr.linux.no/#linux+v3.5/lib/string.c#L270
memcmp compare N bytes - http://lxr.linux.no/#linux+v3.5/lib/string.c#L651

Yes. So if s contains "abcde" then

memcmp(s, "abc", 3) and strncmp(s, "abc", 3) will both return 0, and memcmp(s, "abc", 4) and strncmp(s, "abc", 4) will both return 1.

Alan Stern

#12 lore raw

RE: [linux-pm] [PATCH] ACPI: replace strlen("string") with sizeof("string") -1

Silly question: when did sizeof("string") get changed to be anything other than the size of the pointer ("string" is, after all, an array of characters)?

Quoted 45 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Alan Stern
Sent: Monday, August 06, 2012 1:00 PM
To: Pavel Vasilyev
Cc: Pavel Machek; Len Brown; [email protected]; [email protected]; [email protected]; Len Brown
Subject: Re: [linux-pm] [PATCH] ACPI: replace strlen("string") with sizeof("string") -1

Quoted 1 line · Pavel Vasilyev
Quoted 1 line
Quoted 1 line

http://www.gossamer-threads.com/lists/engine?do=post_attachmen
t;postatt_id=41157;list=linux

Quoted 3 lines
Quoted 3 lines

Interestingly, many (all?) of the changes in that patch are wrong because they don't try to match the terminating '\0'. As

a result,

Quoted 1 line
Quoted 1 line

they will match against extensions of the target string

as well as the

Quoted 4 lines
Quoted 2 lines

target string itself.

strNcmp compare N bytes -

http://lxr.linux.no/#linux+v3.5/lib/string.c#L270

Quoted 1 line

memcmp compare N bytes -

http://lxr.linux.no/#linux+v3.5/lib/string.c#L651

Yes. So if s contains "abcde" then

	memcmp(s, "abc", 3) and strncmp(s, "abc", 3) will both 

return 0, and
memcmp(s, "abc", 4) and strncmp(s, "abc", 4) will both return 1.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

#13 lore raw

RE: [linux-pm] [PATCH] ACPI: replace strlen("string") with sizeof("string") -1

Quoted 3 lines · Daniel Taylor

Silly question: when did sizeof("string") get changed to be anything other than the size of the pointer ("string" is, after all, an array of characters)?

It is since K&R times that way.
If you do not know the difference between a pointer and an array (and these are vastly different), go learn something new about C.

Bernd

Signature · 2 lines
Bernd Petrovitsch                  Email : [email protected]
                     LUGA : http://www.luga.at
#14 lore raw

RE: [linux-pm] [PATCH] ACPI: replace strlen("string") with sizeof("string") -1

Said it was a silly question.

It's funny.

I've been using "0123456789abcdef"[index] for a long time, so I "know" that "string" is a array of char, but it never occurred to me that "string" would work in sizeof() the same way as

char string[] = { '0', '1', '2', '3', '4', '5', '6', '7',

                  '8', '9', 'a', 'b', 'c', 'd', 'e', 'f', '\0' };

int stringlength = sizeof(string);

Learned something.

Thanks,

Dan

Quoted 27 lines

-----Original Message-----
From: Bernd Petrovitsch [mailto:[email protected]]
Sent: Tuesday, August 07, 2012 6:20 AM
To: Daniel Taylor
Cc: 'Alan Stern'; Pavel Vasilyev; Pavel Machek; Len Brown; [email protected]; [email protected]; [email protected]; Len Brown
Subject: RE: [linux-pm] [PATCH] ACPI: replace strlen("string") with sizeof("string") -1

Quoted 1 line · Daniel Taylor

Silly question: when did sizeof("string") get changed to

be anything

Quoted 2 lines

other than the size of the pointer ("string" is, after all, an array of characters)?

It is since K&R times that way.
If you do not know the difference between a pointer and an array (and these are vastly different), go learn something new about C.

Bernd

Signature · 2 lines
Bernd Petrovitsch                  Email : [email protected]
                     LUGA : http://www.luga.at
#15 lore raw

Re: [linux-pm] [PATCH] ACPI: replace strlen("string") with sizeof("string") -1

In reply to Alan Stern

06.08.2012 23:59, Alan Stern пишет:

Quoted 10 lines · Pavel Vasilyev
Quoted 9 lines
Quoted 8 lines
Quoted 2 lines

http://www.gossamer-threads.com/lists/engine?do=post_attachment;postatt_id=41157;list=linux

Interestingly, many (all?) of the changes in that patch are wrong because they don't try to match the terminating '\0'. As a result, they will match against extensions of the target string as well as the target string itself.

Quoted 7 lines
Quoted 2 lines

strNcmp compare N bytes - http://lxr.linux.no/#linux+v3.5/lib/string.c#L270
memcmp compare N bytes - http://lxr.linux.no/#linux+v3.5/lib/string.c#L651

Yes. So if s contains "abcde" then

memcmp(s, "abc", 3) and strncmp(s, "abc", 3) will both return 0, and memcmp(s, "abc", 4) and strncmp(s, "abc", 4) will both return 1.

No matter what is contained in *s, "abcde" or "abcxxx", are important first N bytes. The second example, you see, a little bit stupid, and devoid of logic. :)

Signature · 5 lines
                                                         Pavel.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#16 lore raw

Re: [linux-pm] [PATCH] ACPI: replace strlen("string") with sizeof("string") -1

Quoted 14 lines · Pavel Vasilyev

06.08.2012 23:59, Alan Stern пишет:

Quoted 13 lines · Pavel Vasilyev
Quoted 11 lines
Quoted 8 lines
Quoted 2 lines

http://www.gossamer-threads.com/lists/engine?do=post_attachment;postatt_id=41157;list=linux

Interestingly, many (all?) of the changes in that patch are wrong because they don't try to match the terminating '\0'. As a result, they will match against extensions of the target string as well as the target string itself.

strNcmp compare N bytes - http://lxr.linux.no/#linux+v3.5/lib/string.c#L270
memcmp compare N bytes - http://lxr.linux.no/#linux+v3.5/lib/string.c#L651

Quoted 8 lines
Quoted 4 lines

Yes. So if s contains "abcde" then

memcmp(s, "abc", 3) and strncmp(s, "abc", 3) will both return 0, and memcmp(s, "abc", 4) and strncmp(s, "abc", 4) will both return 1.

No matter what is contained in *s, "abcde" or "abcxxx", are important first N bytes. The second example, you see, a little bit stupid, and devoid of logic. :)

Maybe yes, maybe no. It all depends on what you want.

For example, if you're looking for "on" or "off", what should you do when the user writes "onoff"? You could accept it as meaning the same as "on", but if you were being careful then you would want to reject it as a meaningless value.

Alan Stern

#17 lore raw

Re: [linux-pm] [PATCH] ACPI: replace strlen("string") with sizeof("string") -1

07.08.2012 21:24, Alan Stern пишет:

Quoted 25 lines · Pavel Vasilyev
Quoted 15 lines

06.08.2012 23:59, Alan Stern пишет:

Quoted 13 lines · Pavel Vasilyev
Quoted 11 lines
Quoted 8 lines
Quoted 2 lines

http://www.gossamer-threads.com/lists/engine?do=post_attachment;postatt_id=41157;list=linux

Interestingly, many (all?) of the changes in that patch are wrong because they don't try to match the terminating '\0'. As a result, they will match against extensions of the target string as well as the target string itself.

strNcmp compare N bytes - http://lxr.linux.no/#linux+v3.5/lib/string.c#L270
memcmp compare N bytes - http://lxr.linux.no/#linux+v3.5/lib/string.c#L651

Quoted 8 lines
Quoted 4 lines

Yes. So if s contains "abcde" then

memcmp(s, "abc", 3) and strncmp(s, "abc", 3) will both return 0, and memcmp(s, "abc", 4) and strncmp(s, "abc", 4) will both return 1.

No matter what is contained in *s, "abcde" or "abcxxx", are important first N bytes. The second example, you see, a little bit stupid, and devoid of logic. :)

Quoted 6 lines

Maybe yes, maybe no. It all depends on what you want.

For example, if you're looking for "on" or "off", what should you do when the user writes "onoff"? You could accept it as meaning the same as "on", but if you were being careful then you would want to reject it as a meaningless value.

The users should't be allowed to think!
There is "on" - the size of 2 bytes, or "off" - 3 bytes, other variations - user error.

We do not create a kernel with artificial intelligence? ;)

Signature · 1 line
                                                         Pavel.
#18 lore raw

Re: [linux-pm] [PATCH] ACPI: replace strlen("string") with sizeof("string") -1

Quoted 17 lines · Pavel Vasilyev
Quoted 9 lines
Quoted 8 lines
Quoted 4 lines

Yes. So if s contains "abcde" then

memcmp(s, "abc", 3) and strncmp(s, "abc", 3) will both return 0, and memcmp(s, "abc", 4) and strncmp(s, "abc", 4) will both return 1.

No matter what is contained in *s, "abcde" or "abcxxx", are important first N bytes. The second example, you see, a little bit stupid, and devoid of logic. :)

Quoted 6 lines

Maybe yes, maybe no. It all depends on what you want.

For example, if you're looking for "on" or "off", what should you do when the user writes "onoff"? You could accept it as meaning the same as "on", but if you were being careful then you would want to reject it as a meaningless value.

Quoted 5 lines

The users should't be allowed to think!
There is "on" - the size of 2 bytes, or "off" - 3 bytes, other variations - user error.

We do not create a kernel with artificial intelligence? ;)

Let me rephrase the previous statement, as it appears you did not understand what I meant.

If the kernel is testing for "on" or "off", what should it do when the user writes "onoff"? The kernel could accept this as meaning the same as "on", but if the kernel was being careful then it should reject "onoff" as a meaningless value. A 2-byte comparison for "on" would accept "onoff" whereas a 3-byte comparison would not.

Alan Stern

#19 lore raw

Re: [PATCH] ACPI: replace strlen("string") with sizeof("string") -1

In reply to Len Brown
Quoted 3 lines · Len Brown

...both give the number of chars in the string
without the '\0', as strncmp() wants,
but sizeof() is compile-time.

Does this actually change anything? The compiler is able to expand strlen at compile time if the argument is a constant, provided that that builtin strlen isn't disabled.

Andreas.

Signature · 3 lines
Andreas Schwab, [email protected]
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
author reviewer
#20 lore raw

PATCH 2/8 ACPI, x86: fix Dell M6600 ACPI reboot regression via DMI

In reply to Len Brown

From: Zhang Rui <[email protected]>

Dell Precision M6600 is known to require PCI reboot, so add it to the reboot blacklist in pci_reboot_dmi_table[].

https://bugzilla.kernel.org/show_bug.cgi?id=42749

---
 arch/x86/kernel/reboot.c | 8 ++++++++
 1 file changed, 8 insertions(+)
arch/x86/kernel/reboot.c +8 -0
index 79c45af..412db57 100644
@@ -451,6 +451,14 @@ static struct dmi_system_id __initdata reboot_dmi_table[] = {
 			DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 990"),
 		},
 	},
+	{	/* Handle problems with rebooting on the Precision M6600. */
+		.callback = set_pci_reboot,
+		.ident = "Dell OptiPlex 990",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "Precision M6600"),
+		},
+	},
 	{ }
 };
 
Signature · 1 line
1.7.11.1.104.ge7b44f1
Acked-by on v1 2/8
#21 lore raw

Re: [PATCH 2/8] ACPI, x86: fix Dell M6600 ACPI reboot regression via DMI

Quoted 5 lines · Len Brown

From: Zhang Rui <[email protected]>

Dell Precision M6600 is known to require PCI reboot, so add it to the reboot blacklist in pci_reboot_dmi_table[].

Quoted 8 lines

https://bugzilla.kernel.org/show_bug.cgi?id=42749

---
 arch/x86/kernel/reboot.c | 8 ++++++++
 1 file changed, 8 insertions(+)

Thanks,

Ingo

author reviewer
#22 lore raw

PATCH 3/8 ACPI: Make acpi_skip_timer_override cover all source_irq==0 cases

In reply to Len Brown

From: Feng Tang <[email protected]>

Currently when acpi_skip_timer_override is set, it only cover the (source_irq == 0 && global_irq == 2) cases. While there is also platform which need use this option and its global_irq is not 2. This patch will extend acpi_skip_timer_override to cover all timer overriding cases as long as the source irq is 0.

This is the first part of a fix to kernel bug bugzilla 40002:
"IRQ 0 assigned to VGA"
https://bugzilla.kernel.org/show_bug.cgi?id=40002

---
 arch/x86/kernel/acpi/boot.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)
arch/x86/kernel/acpi/boot.c +8 -6
index 8afb693..e7c698e 100644
@@ -422,12 +422,14 @@ acpi_parse_int_src_ovr(struct acpi_subtable_header * header,
 		return 0;
 	}
 
-	if (intsrc->source_irq == 0 && intsrc->global_irq == 2) {
+	if (intsrc->source_irq == 0) {
 		if (acpi_skip_timer_override) {
-			printk(PREFIX "BIOS IRQ0 pin2 override ignored.\n");
+			printk(PREFIX "BIOS IRQ0 override ignored.\n");
 			return 0;
 		}
-		if (acpi_fix_pin2_polarity && (intsrc->inti_flags & ACPI_MADT_POLARITY_MASK)) {
+
+		if ((intsrc->global_irq == 2) && acpi_fix_pin2_polarity
+			&& (intsrc->inti_flags & ACPI_MADT_POLARITY_MASK)) {
 			intsrc->inti_flags &= ~ACPI_MADT_POLARITY_MASK;
 			printk(PREFIX "BIOS IRQ0 pin2 override: forcing polarity to high active.\n");
 		}
@@ -1334,7 +1336,7 @@ static int __init dmi_disable_acpi(const struct dmi_system_id *d)
 }
 
 /*
- * Force ignoring BIOS IRQ0 pin2 override
+ * Force ignoring BIOS IRQ0 override
  */
 static int __init dmi_ignore_irq0_timer_override(const struct dmi_system_id *d)
 {
@@ -1344,7 +1346,7 @@ static int __init dmi_ignore_irq0_timer_override(const struct dmi_system_id *d)
 	 */
 	if (!acpi_skip_timer_override) {
 		WARN(1, KERN_ERR "ati_ixp4x0 quirk not complete.\n");
-		pr_notice("%s detected: Ignoring BIOS IRQ0 pin2 override\n",
+		pr_notice("%s detected: Ignoring BIOS IRQ0 override\n",
 			d->ident);
 		acpi_skip_timer_override = 1;
 	}
@@ -1438,7 +1440,7 @@ static struct dmi_system_id __initdata acpi_dmi_table_late[] = {
 	 * is enabled.  This input is incorrectly designated the
 	 * ISA IRQ 0 via an interrupt source override even though
 	 * it is wired to the output of the master 8259A and INTIN0
-	 * is not connected at all.  Force ignoring BIOS IRQ0 pin2
+	 * is not connected at all.  Force ignoring BIOS IRQ0
 	 * override in that cases.
 	 */
 	{
Signature · 1 line
1.7.11.1.104.ge7b44f1
author reviewer
#23 lore raw

PATCH 4/8 ACPI: Remove one board specific WARN when ignoring timer overriding

In reply to Len Brown

From: Feng Tang <[email protected]>

Current WARN msg is only for the ati_ixp4x0 board, while this function is used by mulitple platforms. So this one board specific warning is not appropriate any more.

---
 arch/x86/kernel/acpi/boot.c | 5 -----
 1 file changed, 5 deletions(-)
arch/x86/kernel/acpi/boot.c +0 -5
index e7c698e..3a6afba 100644
@@ -1340,12 +1340,7 @@ static int __init dmi_disable_acpi(const struct dmi_system_id *d)
  */
 static int __init dmi_ignore_irq0_timer_override(const struct dmi_system_id *d)
 {
-	/*
-	 * The ati_ixp4x0_rev() early PCI quirk should have set
-	 * the acpi_skip_timer_override flag already:
-	 */
 	if (!acpi_skip_timer_override) {
-		WARN(1, KERN_ERR "ati_ixp4x0 quirk not complete.\n");
 		pr_notice("%s detected: Ignoring BIOS IRQ0 override\n",
 			d->ident);
 		acpi_skip_timer_override = 1;
Signature · 1 line
1.7.11.1.104.ge7b44f1
author reviewer
#24 lore raw

PATCH 5/8 ACPI: Add a quirk for "AMILO PRO V2030" to ignore the timer overriding

In reply to Len Brown

From: Feng Tang <[email protected]>

This is the 2nd part of fix for kernel bugzilla 40002:
"IRQ 0 assigned to VGA"
https://bugzilla.kernel.org/show_bug.cgi?id=40002

The root cause is the buggy FW, whose ACPI tables assign the GSI 16 to 2 irqs 0 and 16(VGA), and the VGA is the right owner of GSI 16. So add a quirk to ignore the irq0 overriding GSI 16 for the FUJITSU SIEMENS AMILO PRO V2030 platform will solve this issue.

---
 arch/x86/kernel/acpi/boot.c | 8 ++++++++
 1 file changed, 8 insertions(+)
arch/x86/kernel/acpi/boot.c +8 -0
index 3a6afba..b2297e5 100644
@@ -1470,6 +1470,14 @@ static struct dmi_system_id __initdata acpi_dmi_table_late[] = {
 		     DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq 6715b"),
 		     },
 	 },
+	{
+	 .callback = dmi_ignore_irq0_timer_override,
+	 .ident = "FUJITSU SIEMENS",
+	 .matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU SIEMENS"),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "AMILO PRO V2030"),
+		     },
+	 },
 	{}
 };
 
Signature · 1 line
1.7.11.1.104.ge7b44f1
author reviewer
#25 lore raw

PATCH 6/8 ACPI, APEI, Avoid too much error reporting in runtime

In reply to Len Brown

From: Huang Ying <[email protected]>

This patch fixed the following bug.

https://bugzilla.kernel.org/show_bug.cgi?id=43282

This is caused by a firmware bug checking (checking generic address register provided by firmware) in runtime. The checking should be done in address mapping time instead of runtime to avoid too much error reporting in runtime.

---
 drivers/acpi/apei/apei-base.c     | 17 +++++++++++++++--
 drivers/acpi/apei/apei-internal.h |  9 +++++++++
 drivers/acpi/apei/ghes.c          |  6 +++---
 3 files changed, 27 insertions(+), 5 deletions(-)
drivers/acpi/apei/apei-base.c +15 -2
index 5577762..6686b1e 100644
@@ -243,7 +243,7 @@ static int pre_map_gar_callback(struct apei_exec_context *ctx,
 	u8 ins = entry->instruction;
 
 	if (ctx->ins_table[ins].flags & APEI_EXEC_INS_ACCESS_REGISTER)
-		return acpi_os_map_generic_address(&entry->register_region);
+		return apei_map_generic_address(&entry->register_region);
 
 	return 0;
 }
@@ -276,7 +276,7 @@ static int post_unmap_gar_callback(struct apei_exec_context *ctx,
 	u8 ins = entry->instruction;
 
 	if (ctx->ins_table[ins].flags & APEI_EXEC_INS_ACCESS_REGISTER)
-		acpi_os_unmap_generic_address(&entry->register_region);
+		apei_unmap_generic_address(&entry->register_region);
 
 	return 0;
 }
@@ -606,6 +606,19 @@ static int apei_check_gar(struct acpi_generic_address *reg, u64 *paddr,
 	return 0;
 }
 
+int apei_map_generic_address(struct acpi_generic_address *reg)
+{
+	int rc;
+	u32 access_bit_width;
+	u64 address;
+
+	rc = apei_check_gar(reg, &address, &access_bit_width);
+	if (rc)
+		return rc;
+	return acpi_os_map_generic_address(reg);
+}
+EXPORT_SYMBOL_GPL(apei_map_generic_address);
+
 /* read GAR in interrupt (including NMI) or process context */
 int apei_read(u64 *val, struct acpi_generic_address *reg)
 {
drivers/acpi/apei/apei-internal.h +9 -0
index cca240a..f220d64 100644
@@ -7,6 +7,8 @@
 #define APEI_INTERNAL_H
 
 #include <linux/cper.h>
+#include <linux/acpi.h>
+#include <linux/acpi_io.h>
 
 struct apei_exec_context;
 
@@ -68,6 +70,13 @@ static inline int apei_exec_run_optional(struct apei_exec_context *ctx, u8 actio
 /* IP has been set in instruction function */
 #define APEI_EXEC_SET_IP	1
 
+int apei_map_generic_address(struct acpi_generic_address *reg);
+
+static inline void apei_unmap_generic_address(struct acpi_generic_address *reg)
+{
+	acpi_os_unmap_generic_address(reg);
+}
+
 int apei_read(u64 *val, struct acpi_generic_address *reg);
 int apei_write(u64 val, struct acpi_generic_address *reg);
 
drivers/acpi/apei/ghes.c +3 -3
index 9b3cac0..1599566 100644
@@ -301,7 +301,7 @@ static struct ghes *ghes_new(struct acpi_hest_generic *generic)
 	if (!ghes)
 		return ERR_PTR(-ENOMEM);
 	ghes->generic = generic;
-	rc = acpi_os_map_generic_address(&generic->error_status_address);
+	rc = apei_map_generic_address(&generic->error_status_address);
 	if (rc)
 		goto err_free;
 	error_block_length = generic->error_block_length;
@@ -321,7 +321,7 @@ static struct ghes *ghes_new(struct acpi_hest_generic *generic)
 	return ghes;
 
 err_unmap:
-	acpi_os_unmap_generic_address(&generic->error_status_address);
+	apei_unmap_generic_address(&generic->error_status_address);
 err_free:
 	kfree(ghes);
 	return ERR_PTR(rc);
@@ -330,7 +330,7 @@ err_free:
 static void ghes_fini(struct ghes *ghes)
 {
 	kfree(ghes->estatus);
-	acpi_os_unmap_generic_address(&ghes->generic->error_status_address);
+	apei_unmap_generic_address(&ghes->generic->error_status_address);
 }
 
 enum {
Signature · 1 line
1.7.11.1.104.ge7b44f1
author reviewer
#26 lore raw

PATCH 7/8 ACPI video: Still use ACPI backlight control if _DOS doesn't exist

In reply to Len Brown

From: Zhang Rui <[email protected]>

This fixes a regression in 3.4-rc1 caused by commit ea9f8856bd6d4ed45885b06a338f7362cd6c60e5 (ACPI video: Harden video bus adding.)

Some platforms don't have _DOS control method, but the ACPI backlight still works.
We should not invoke _DOS for these platforms.

https://bugzilla.kernel.org/show_bug.cgi?id=43168

---
 drivers/acpi/video.c | 2 ++
 1 file changed, 2 insertions(+)
drivers/acpi/video.c +2 -0
index 9577b6f..4134b30 100644
@@ -558,6 +558,8 @@ acpi_video_bus_DOS(struct acpi_video_bus *video, int bios_flag, int lcd_flag)
 	union acpi_object arg0 = { ACPI_TYPE_INTEGER };
 	struct acpi_object_list args = { 1, &arg0 };
 
+	if (!video->cap._DOS)
+		return 0;
 
 	if (bios_flag < 0 || bios_flag > 3 || lcd_flag < 0 || lcd_flag > 1)
 		return -EINVAL;
Signature · 1 line
1.7.11.1.104.ge7b44f1
author reviewer
#27 lore raw

PATCH 8/8 acpi_pad: fix power_saving thread deadlock

In reply to Len Brown

From: Stuart Hayes <[email protected]>

The acpi_pad driver can get stuck in destroy_power_saving_task() waiting for kthread_stop() to stop a power_saving thread. The problem is that the isolated_cpus_lock mutex is owned when destroy_power_saving_task() calls kthread_stop(), which waits for a power_saving thread to end, and the power_saving thread tries to acquire the isolated_cpus_lock when it calls round_robin_cpu(). This patch fixes the issue by making round_robin_cpu() use its own mutex.

https://bugzilla.kernel.org/show_bug.cgi?id=42981

---
 drivers/acpi/acpi_pad.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/acpi/acpi_pad.c +4 -3
index a43fa1a..1502c502 100644
@@ -36,6 +36,7 @@
 #define ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME "Processor Aggregator"
 #define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
 static DEFINE_MUTEX(isolated_cpus_lock);
+static DEFINE_MUTEX(round_robin_lock);
 
 static unsigned long power_saving_mwait_eax;
 
@@ -107,7 +108,7 @@ static void round_robin_cpu(unsigned int tsk_index)
 	if (!alloc_cpumask_var(&tmp, GFP_KERNEL))
 		return;
 
-	mutex_lock(&isolated_cpus_lock);
+	mutex_lock(&round_robin_lock);
 	cpumask_clear(tmp);
 	for_each_cpu(cpu, pad_busy_cpus)
 		cpumask_or(tmp, tmp, topology_thread_cpumask(cpu));
@@ -116,7 +117,7 @@ static void round_robin_cpu(unsigned int tsk_index)
 	if (cpumask_empty(tmp))
 		cpumask_andnot(tmp, cpu_online_mask, pad_busy_cpus);
 	if (cpumask_empty(tmp)) {
-		mutex_unlock(&isolated_cpus_lock);
+		mutex_unlock(&round_robin_lock);
 		return;
 	}
 	for_each_cpu(cpu, tmp) {
@@ -131,7 +132,7 @@ static void round_robin_cpu(unsigned int tsk_index)
 	tsk_in_cpu[tsk_index] = preferred_cpu;
 	cpumask_set_cpu(preferred_cpu, pad_busy_cpus);
 	cpu_weight[preferred_cpu]++;
-	mutex_unlock(&isolated_cpus_lock);
+	mutex_unlock(&round_robin_lock);
 
 	set_cpus_allowed_ptr(current, cpumask_of(preferred_cpu));
 }
Signature · 1 line
1.7.11.1.104.ge7b44f1