[PATCH] Blackfin: Use setup_timer
Use the timer API function setup_timer instead of structure field assignments to initialize a timer. A simplified version of the Coccinelle semantic patch that performs this transformation is as follows: @change@ expression e1, e2, a; @@ -init_timer(); +setup_timer(, a, 0UL); ... when != a = e2 -e1.function = a; Signed-off-by: Vaishali Thakkar --- arch/blackfin/kernel/nmi.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/blackfin/kernel/nmi.c b/arch/blackfin/kernel/nmi.c index 9919d29..64dd717 100644 --- a/arch/blackfin/kernel/nmi.c +++ b/arch/blackfin/kernel/nmi.c @@ -179,8 +179,7 @@ static int __init init_nmi_wdt(void) nmi_wdt_start(); nmi_active = true; - init_timer(); - ntimer.function = nmi_wdt_timer; + setup_timer(, nmi_wdt_timer, 0UL); ntimer.expires = jiffies + NMI_CHECK_TIMEOUT; add_timer(); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Drivers: block: Use setup_timer
Use the timer API function setup_timer instead of structure field
assignments to initialize a timer.
A simplified version of the Coccinelle semantic patch that performs
this transformation is as follows:
@change@
expression e1, e2, a;
@@
-init_timer();
+setup_timer(, a, 0UL);
... when != a = e2
-e1.function = a;
Signed-off-by: Vaishali Thakkar
---
drivers/block/umem.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/block/umem.c b/drivers/block/umem.c
index 4cf81b5..cd999a1 100644
--- a/drivers/block/umem.c
+++ b/drivers/block/umem.c
@@ -738,8 +738,7 @@ static void check_all_batteries(unsigned long ptr)
static void init_battery_timer(void)
{
- init_timer(_timer);
- battery_timer.function = check_all_batteries;
+ setup_timer(_timer, check_all_batteries, 0UL);
battery_timer.expires = jiffies + (HZ * 60);
add_timer(_timer);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH non-pretimeout 4/7] Watchdog: introduce ARM SBSA watchdog driver
On 06/10/2015 10:44 PM, Fu Wei wrote: Hi Guenter, On 11 June 2015 at 13:33, Guenter Roeck wrote: On 06/10/2015 10:47 AM, fu@linaro.org wrote: From: Fu Wei This driver bases on linux kernel watchdog framework. It supports getting timeout from parameter and FDT at the driver init stage. The first timeout period expires, the interrupt routine got another timeout period to run panic for saving system context. Signed-off-by: Fu Wei --- drivers/watchdog/Kconfig | 11 ++ drivers/watchdog/Makefile| 1 + drivers/watchdog/sbsa_gwdt.c | 383 +++ 3 files changed, 395 insertions(+) create mode 100644 drivers/watchdog/sbsa_gwdt.c diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index e5e7c55..554f18a 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -152,6 +152,17 @@ config ARM_SP805_WATCHDOG ARM Primecell SP805 Watchdog timer. This will reboot your system when the timeout is reached. +config ARM_SBSA_WATCHDOG + tristate "ARM SBSA Generic Watchdog" + depends on ARM64 + depends on ARM_ARCH_TIMER + select WATCHDOG_CORE + help + ARM SBSA Generic Watchdog. This watchdog has two Watchdog timeouts. + The first timeout will trigger a panic; the second timeout will + trigger a system reset. + More details: ARM DEN0029B - Server Base System Architecture (SBSA) + config AT91RM9200_WATCHDOG tristate "AT91RM9200 watchdog" depends on SOC_AT91RM9200 && MFD_SYSCON diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile index 5c19294..471f1b7c 100644 --- a/drivers/watchdog/Makefile +++ b/drivers/watchdog/Makefile @@ -30,6 +30,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o # ARM Architecture obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o +obj-$(CONFIG_ARM_SBSA_WATCHDOG) += sbsa_gwdt.o obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o obj-$(CONFIG_CADENCE_WATCHDOG) += cadence_wdt.o diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c new file mode 100644 index 000..1ddc10f --- /dev/null +++ b/drivers/watchdog/sbsa_gwdt.c @@ -0,0 +1,383 @@ +/* + * SBSA(Server Base System Architecture) Generic Watchdog driver + * + * Copyright (c) 2015, Linaro Ltd. + * Author: Fu Wei + * Suravee Suthikulpanit + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License 2 as published + * by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * Note: This SBSA Generic watchdog has two stage timeouts, + * When the first timeout occurs, WS0(SPI or LPI) is triggered, + * the second timeout period(as long as the first timeout period) starts. + * In WS0 interrupt routine, panic() will be called for collecting + * crashdown info. + * If system can not recover from WS0 interrupt routine, then second + * timeout occurs, WS1(reset or higher level interrupt) is triggered. + * The two timeout period can be set by WOR(32bit). + * WOR gives a maximum watch period of around 10s at the maximum + * system counter frequency. + * The System Counter shall run at maximum of 400MHz. + * + * But If we need a larger timeout period, this driver will programme WCV + * directly. That can support more than 10s timeout at the maximum + * system counter frequency. + * More details: ARM DEN0029B - Server Base System Architecture (SBSA) + * + * SBSA GWDT:|---WOR(or WCV)---WS0---WOR(or WCV)---WS1 + * |-timeout-WS0-timeout-WS1 If we use WCV at all, I would like to see something like * SBSA GWDT:|---WOR(or WCV)---WS0WOR--WS1 * |-timeout-WS0-WS1 * panic hw reset where WOR would be used up to its maximum, to be replaced by WCV (but kept at maximum) if the selected timeout is larger than the maximum timeout selectable with WOR. Would this be possible ? for this part |-timeout-WS0, I am doing this way in non-pretimeout version. but for WS0-WS1, do you mean WOR would always be used up to its maximum??? yes I don't see any variable attached on it. So I would like to confirm what is this value min(timeout, max_wor_timeout) Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
SMP inline macros
Hi, Do we need to enable " CONFIG_INLINE_SPIN_LOCK" when CONFIG_SMP is enabled. What the impact when it is enabled and disabled? What is the relation between " CONFIG_INLINE_SPIN_LOCK" and CONFIG_PREMPT? Thanks Kals -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] atm: idt77105: Use setup_timer
From: Vaishali Thakkar Date: Wed, 10 Jun 2015 11:10:05 +0530 > Use the timer API function setup_timer instead of structure field > assignments to initialize a timer. > > A simplified version of the Coccinelle semantic patch that performs > this transformation is as follows: > > @change@ > expression e1, e2, a; > @@ > > -init_timer(); > +setup_timer(, a, 0UL); > ... when != a = e2 > -e1.function = a; > > Signed-off-by: Vaishali Thakkar Applied to net-next, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH non-pretimeout 4/7] Watchdog: introduce ARM SBSA watchdog driver
Hi Guenter, On 11 June 2015 at 13:33, Guenter Roeck wrote: > On 06/10/2015 10:47 AM, fu@linaro.org wrote: >> >> From: Fu Wei >> >> This driver bases on linux kernel watchdog framework. >> It supports getting timeout from parameter and FDT >> at the driver init stage. >> The first timeout period expires, the interrupt routine >> got another timeout period to run panic for saving >> system context. >> >> Signed-off-by: Fu Wei >> --- >> drivers/watchdog/Kconfig | 11 ++ >> drivers/watchdog/Makefile| 1 + >> drivers/watchdog/sbsa_gwdt.c | 383 >> +++ >> 3 files changed, 395 insertions(+) >> create mode 100644 drivers/watchdog/sbsa_gwdt.c >> >> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig >> index e5e7c55..554f18a 100644 >> --- a/drivers/watchdog/Kconfig >> +++ b/drivers/watchdog/Kconfig >> @@ -152,6 +152,17 @@ config ARM_SP805_WATCHDOG >> ARM Primecell SP805 Watchdog timer. This will reboot your system >> when >> the timeout is reached. >> >> +config ARM_SBSA_WATCHDOG >> + tristate "ARM SBSA Generic Watchdog" >> + depends on ARM64 >> + depends on ARM_ARCH_TIMER >> + select WATCHDOG_CORE >> + help >> + ARM SBSA Generic Watchdog. This watchdog has two Watchdog >> timeouts. >> + The first timeout will trigger a panic; the second timeout will >> + trigger a system reset. >> + More details: ARM DEN0029B - Server Base System Architecture >> (SBSA) >> + >> config AT91RM9200_WATCHDOG >> tristate "AT91RM9200 watchdog" >> depends on SOC_AT91RM9200 && MFD_SYSCON >> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile >> index 5c19294..471f1b7c 100644 >> --- a/drivers/watchdog/Makefile >> +++ b/drivers/watchdog/Makefile >> @@ -30,6 +30,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o >> >> # ARM Architecture >> obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o >> +obj-$(CONFIG_ARM_SBSA_WATCHDOG) += sbsa_gwdt.o >> obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o >> obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o >> obj-$(CONFIG_CADENCE_WATCHDOG) += cadence_wdt.o >> diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c >> new file mode 100644 >> index 000..1ddc10f >> --- /dev/null >> +++ b/drivers/watchdog/sbsa_gwdt.c >> @@ -0,0 +1,383 @@ >> +/* >> + * SBSA(Server Base System Architecture) Generic Watchdog driver >> + * >> + * Copyright (c) 2015, Linaro Ltd. >> + * Author: Fu Wei >> + * Suravee Suthikulpanit >> + * >> + * This program is free software; you can redistribute it and/or modify >> + * it under the terms of the GNU General Public License 2 as published >> + * by the Free Software Foundation. >> + * >> + * This program is distributed in the hope that it will be useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + * >> + * Note: This SBSA Generic watchdog has two stage timeouts, >> + * When the first timeout occurs, WS0(SPI or LPI) is triggered, >> + * the second timeout period(as long as the first timeout period) >> starts. >> + * In WS0 interrupt routine, panic() will be called for collecting >> + * crashdown info. >> + * If system can not recover from WS0 interrupt routine, then >> second >> + * timeout occurs, WS1(reset or higher level interrupt) is >> triggered. >> + * The two timeout period can be set by WOR(32bit). >> + * WOR gives a maximum watch period of around 10s at the maximum >> + * system counter frequency. >> + * The System Counter shall run at maximum of 400MHz. >> + * >> + * But If we need a larger timeout period, this driver will >> programme WCV >> + * directly. That can support more than 10s timeout at the maximum >> + * system counter frequency. >> + * More details: ARM DEN0029B - Server Base System Architecture >> (SBSA) >> + * >> + * SBSA GWDT:|---WOR(or WCV)---WS0---WOR(or WCV)---WS1 >> + * |-timeout-WS0-timeout-WS1 > > > If we use WCV at all, I would like to see something like > > * SBSA GWDT:|---WOR(or WCV)---WS0WOR--WS1 > * |-timeout-WS0-WS1 > * panic hw reset > > where WOR would be used up to its maximum, to be replaced by WCV > (but kept at maximum) if the selected timeout is larger than the > maximum timeout selectable with WOR. Would this be possible ? for this part |-timeout-WS0, I am doing this way in non-pretimeout version. but for WS0-WS1, do you mean WOR would always be used up to its maximum??? I don't see any variable attached on it. So I would like to confirm what is this value > > Guenter > -- Best regards, Fu Wei Software Engineer
[RFC PATCH] ACPI / EC: Fix an issue caused by the serialized _Qxx evaluations.
It is proven that Windows evaluates _Qxx handlers in a parallel way. This
patch follows this fact, changes _Qxx evaluations to be queued up on the
NOTIFY queue as its behavior is proven to be quite different from the
_Lxx/_Exx handlers, and convert the NOTIFY queue into the parallel style.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=94411
Reported-and-tested-by: Gabriele Mazzotta
Signed-off-by: Lv Zheng
---
drivers/acpi/ec.c |5 ++---
drivers/acpi/osl.c | 20 ++--
2 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 9d4761d..30f582f 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -1023,9 +1023,8 @@ static int acpi_ec_query(struct acpi_ec *ec, u8 *data)
handler = acpi_ec_get_query_handler(handler);
ec_dbg_evt("Query(0x%02x) scheduled",
handler->query_bit);
- status = acpi_os_execute((handler->func) ?
- OSL_NOTIFY_HANDLER : OSL_GPE_HANDLER,
- acpi_ec_run, handler);
+ status = acpi_os_execute(OSL_NOTIFY_HANDLER,
+acpi_ec_run, handler);
if (ACPI_FAILURE(status))
result = -EBUSY;
break;
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index db14a66..c354754 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -1159,20 +1159,20 @@ acpi_status acpi_os_execute(acpi_execute_type type,
if (type == OSL_NOTIFY_HANDLER) {
queue = kacpi_notify_wq;
INIT_WORK(>work, acpi_os_execute_deferred);
+ ret = queue_work(queue, >work);
} else {
queue = kacpid_wq;
INIT_WORK(>work, acpi_os_execute_deferred);
+ /*
+* On some machines, a software-initiated SMI causes
+* corruption unless the SMI runs on CPU 0. An SMI can be
+* initiated by any AML, but typically it's done in
+* GPE-related methods that are run via workqueues, so we
+* can avoid the known corruption cases by always queueing
+* on CPU 0.
+*/
+ ret = queue_work_on(0, queue, >work);
}
-
- /*
-* On some machines, a software-initiated SMI causes corruption unless
-* the SMI runs on CPU 0. An SMI can be initiated by any AML, but
-* typically it's done in GPE-related methods that are run via
-* workqueues, so we can avoid the known corruption cases by always
-* queueing on CPU 0.
-*/
- ret = queue_work_on(0, queue, >work);
-
if (!ret) {
printk(KERN_ERR PREFIX
"Call to queue_work() failed.\n");
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/2] Fixup lustre ll_getname
From: Oleg Drokin Some time ago Al Viro noticed that lustre ll_getname is broken. At the time a patch was submitted to convert lustre to use exported getname, that was rejected by hch on the grounds that filesystem code sould not really be reimplementing their own lookups which kind of made sense back then. But upon further investigation it seems that ll_getname is used in a different way, it only gets a single path name component that is then shiped to the server for some operations. Going through VFS here to do proper lookups is not really all that good of an idea since dcache pollution is undesired at the very least. So these two patches drop one of the ll_getname users that could be done in another way and fix up ll_getname to only allocate a single pathname component buffer and properly check copy from userspace return value. Please consider. Oleg Drokin (2): staging/lustre/llite: remove LL_IOC_REMOVE_ENTRY handler staging/lustre/llite: fix ll_getname .../lustre/lustre/include/lustre/lustre_user.h | 1 - drivers/staging/lustre/lustre/llite/dir.c | 50 ++ 2 files changed, 13 insertions(+), 38 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] staging/lustre/llite: fix ll_getname user buffer copy
From: Oleg Drokin
strncpy_from_user could return negative values on error,
so need to take those into account.
Since ll_getname is used to get a single component name from userspace
to transfer to server as-is, there's no need to allocate 4k buffer
as done by __getname. Allocate NAME_MAX+1 buffer instead to ensure
we have enough for a null terminated max valid length buffer.
This was discovered by Al Viro in https://lkml.org/lkml/2015/4/11/243
Signed-off-by: Oleg Drokin
---
drivers/staging/lustre/lustre/llite/dir.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/dir.c
b/drivers/staging/lustre/lustre/llite/dir.c
index 87a042c..50d685b 100644
--- a/drivers/staging/lustre/lustre/llite/dir.c
+++ b/drivers/staging/lustre/lustre/llite/dir.c
@@ -1213,29 +1213,34 @@ out:
return rc;
}
-static char *
-ll_getname(const char __user *filename)
+/* This function tries to get a single name component,
+ * to send to the server. No actual path traversal involved,
+ * so we limit to NAME_MAX */
+static char *ll_getname(const char __user *filename)
{
int ret = 0, len;
- char *tmp = __getname();
+ char *tmp;
+ tmp = kzalloc(NAME_MAX + 1, GFP_KERNEL);
if (!tmp)
return ERR_PTR(-ENOMEM);
- len = strncpy_from_user(tmp, filename, PATH_MAX);
- if (len == 0)
+ len = strncpy_from_user(tmp, filename, NAME_MAX + 1);
+ if (len < 0)
+ ret = len;
+ else if (len == 0)
ret = -ENOENT;
- else if (len > PATH_MAX)
+ else if (len > NAME_MAX && tmp[NAME_MAX] != 0)
ret = -ENAMETOOLONG;
if (ret) {
- __putname(tmp);
+ kfree(tmp);
tmp = ERR_PTR(ret);
}
return tmp;
}
-#define ll_putname(filename) __putname(filename)
+#define ll_putname(filename) kfree(filename)
static long ll_dir_ioctl(struct file *file, unsigned int cmd, unsigned long
arg)
{
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] staging/lustre/llite: remove LL_IOC_REMOVE_ENTRY handler
From: Oleg Drokin
It uses getname in unsafe manner and since it's to deal with corrupted
or inconsistent filesystem, we are probably better to deal with
it from lfsck anyway.
Signed-off-by: Oleg Drokin
---
.../lustre/lustre/include/lustre/lustre_user.h | 1 -
drivers/staging/lustre/lustre/llite/dir.c | 29 --
2 files changed, 30 deletions(-)
diff --git a/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
b/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
index 89794fd..e095ada 100644
--- a/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
+++ b/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
@@ -243,7 +243,6 @@ struct ost_id {
#define LL_IOC_LMV_SETSTRIPE _IOWR('f', 240, struct lmv_user_md)
#define LL_IOC_LMV_GETSTRIPE _IOWR('f', 241, struct lmv_user_md)
-#define LL_IOC_REMOVE_ENTRY_IOWR('f', 242, __u64)
#define LL_IOC_SET_LEASE _IOWR('f', 243, long)
#define LL_IOC_GET_LEASE _IO('f', 244)
#define LL_IOC_HSM_IMPORT _IOWR('f', 245, struct hsm_user_import)
diff --git a/drivers/staging/lustre/lustre/llite/dir.c
b/drivers/staging/lustre/lustre/llite/dir.c
index 4b0de8d..87a042c 100644
--- a/drivers/staging/lustre/lustre/llite/dir.c
+++ b/drivers/staging/lustre/lustre/llite/dir.c
@@ -1436,35 +1436,6 @@ free_lmv:
kfree(tmp);
return rc;
}
- case LL_IOC_REMOVE_ENTRY: {
- char*filename = NULL;
- int namelen = 0;
- int rc;
-
- /* Here is a little hack to avoid sending REINT_RMENTRY to
-* unsupported server, which might crash the server(LU-2730),
-* Because both LVB_TYPE and REINT_RMENTRY will be supported
-* on 2.4, we use OBD_CONNECT_LVB_TYPE to detect whether the
-* server will support REINT_RMENTRY XXX*/
- if (!(exp_connect_flags(sbi->ll_md_exp) & OBD_CONNECT_LVB_TYPE))
- return -ENOTSUPP;
-
- filename = ll_getname((const char *)arg);
- if (IS_ERR(filename))
- return PTR_ERR(filename);
-
- namelen = strlen(filename);
- if (namelen < 1) {
- rc = -EINVAL;
- goto out_rmdir;
- }
-
- rc = ll_rmdir_entry(inode, filename, namelen);
-out_rmdir:
- if (filename)
- ll_putname(filename);
- return rc;
- }
case LL_IOC_LOV_SWAP_LAYOUTS:
return -EPERM;
case LL_IOC_OBD_STATFS:
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: iop32x: Use setup_timer
Use the timer API function setup_timer instead of structure field
assignments to initialize a timer.
A simplified version of the Coccinelle semantic patch that performs
this transformation is as follows:
@change@
expression e1, e2, a;
@@
-init_timer();
+setup_timer(, a, 0UL);
... when != a = e2
-e1.function = a;
Signed-off-by: Vaishali Thakkar
---
arch/arm/mach-iop32x/n2100.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/mach-iop32x/n2100.c b/arch/arm/mach-iop32x/n2100.c
index c1cd80e..4a64a11 100644
--- a/arch/arm/mach-iop32x/n2100.c
+++ b/arch/arm/mach-iop32x/n2100.c
@@ -336,8 +336,7 @@ static int __init n2100_request_gpios(void)
pr_err("could not set power GPIO as input\n");
}
/* Set up power button poll timer */
- init_timer(_button_poll_timer);
- power_button_poll_timer.function = power_button_poll;
+ setup_timer(_button_poll_timer, power_button_poll, 0UL);
power_button_poll_timer.expires = jiffies + (HZ / 10);
add_timer(_button_poll_timer);
return 0;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH non-pretimeout 4/7] Watchdog: introduce ARM SBSA watchdog driver
On 06/10/2015 10:47 AM, fu@linaro.org wrote: From: Fu Wei This driver bases on linux kernel watchdog framework. It supports getting timeout from parameter and FDT at the driver init stage. The first timeout period expires, the interrupt routine got another timeout period to run panic for saving system context. Signed-off-by: Fu Wei --- drivers/watchdog/Kconfig | 11 ++ drivers/watchdog/Makefile| 1 + drivers/watchdog/sbsa_gwdt.c | 383 +++ 3 files changed, 395 insertions(+) create mode 100644 drivers/watchdog/sbsa_gwdt.c diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index e5e7c55..554f18a 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -152,6 +152,17 @@ config ARM_SP805_WATCHDOG ARM Primecell SP805 Watchdog timer. This will reboot your system when the timeout is reached. +config ARM_SBSA_WATCHDOG + tristate "ARM SBSA Generic Watchdog" + depends on ARM64 + depends on ARM_ARCH_TIMER + select WATCHDOG_CORE + help + ARM SBSA Generic Watchdog. This watchdog has two Watchdog timeouts. + The first timeout will trigger a panic; the second timeout will + trigger a system reset. + More details: ARM DEN0029B - Server Base System Architecture (SBSA) + config AT91RM9200_WATCHDOG tristate "AT91RM9200 watchdog" depends on SOC_AT91RM9200 && MFD_SYSCON diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile index 5c19294..471f1b7c 100644 --- a/drivers/watchdog/Makefile +++ b/drivers/watchdog/Makefile @@ -30,6 +30,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o # ARM Architecture obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o +obj-$(CONFIG_ARM_SBSA_WATCHDOG) += sbsa_gwdt.o obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o obj-$(CONFIG_CADENCE_WATCHDOG) += cadence_wdt.o diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c new file mode 100644 index 000..1ddc10f --- /dev/null +++ b/drivers/watchdog/sbsa_gwdt.c @@ -0,0 +1,383 @@ +/* + * SBSA(Server Base System Architecture) Generic Watchdog driver + * + * Copyright (c) 2015, Linaro Ltd. + * Author: Fu Wei + * Suravee Suthikulpanit + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License 2 as published + * by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * Note: This SBSA Generic watchdog has two stage timeouts, + * When the first timeout occurs, WS0(SPI or LPI) is triggered, + * the second timeout period(as long as the first timeout period) starts. + * In WS0 interrupt routine, panic() will be called for collecting + * crashdown info. + * If system can not recover from WS0 interrupt routine, then second + * timeout occurs, WS1(reset or higher level interrupt) is triggered. + * The two timeout period can be set by WOR(32bit). + * WOR gives a maximum watch period of around 10s at the maximum + * system counter frequency. + * The System Counter shall run at maximum of 400MHz. + * + * But If we need a larger timeout period, this driver will programme WCV + * directly. That can support more than 10s timeout at the maximum + * system counter frequency. + * More details: ARM DEN0029B - Server Base System Architecture (SBSA) + * + * SBSA GWDT:|---WOR(or WCV)---WS0---WOR(or WCV)---WS1 + * |-timeout-WS0-timeout-WS1 If we use WCV at all, I would like to see something like * SBSA GWDT:|---WOR(or WCV)---WS0WOR--WS1 * |-timeout-WS0-WS1 * panic hw reset where WOR would be used up to its maximum, to be replaced by WCV (but kept at maximum) if the selected timeout is larger than the maximum timeout selectable with WOR. Would this be possible ? Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 5/7] Watchdog: introduce ARM SBSA watchdog driver
Hi Guenter On 11 June 2015 at 13:13, Guenter Roeck wrote: > On 06/10/2015 08:45 PM, Timur Tabi wrote: >> >> Fu Wei wrote: >>> >>> Could you suggest a good way to use WS0, so we can follow SBSA spec? >> >> >> To avoid the timeout/2 problem, WS0 calls panic, which is the "real" >> timeout/reset. WS1 is then a "backup" that is ignored by the driver. That >> is, the driver doesn't do anything with WS1 and it doesn't tell the kernel >> about WS1. >> >> I know you don't like the idea of WS1 as a backup timeout, but this is one >> way to solve the problem. >> > This is what I would do. If so, Please check the non-pretimeout version. Thanks > > Guenter > -- Best regards, Fu Wei Software Engineer Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch Ph: +86 21 61221326(direct) Ph: +86 186 2020 4684 (mobile) Room 1512, Regus One Corporate Avenue,Level 15, One Corporate Avenue,222 Hubin Road,Huangpu District, Shanghai,China 200021 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 5/7] Watchdog: introduce ARM SBSA watchdog driver
On 11 June 2015 at 11:45, Timur Tabi wrote: > Fu Wei wrote: >> >> Could you suggest a good way to use WS0, so we can follow SBSA spec? > > > To avoid the timeout/2 problem, WS0 calls panic, which is the "real" > timeout/reset. WS1 is then a "backup" that is ignored by the driver. That > is, the driver doesn't do anything with WS1 and it doesn't tell the kernel > about WS1. could you suggestion : (1) how to config the time from WS0 to WS1 without touching timeout. (2) if we don't config the time from WS0 to WS1, what is the better time for ALL server and ALL situation > > I know you don't like the idea of WS1 as a backup timeout, but this is one > way to solve the problem. It is not "I don't like" WS1 is not a backup in SBSA spec. Page 21 ： "The initial signal is typically wired to an interrupt and alerts the system. " If this is the backup, it should say "reset the system" > > > -- > Sent by an employee of the Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of the > Code Aurora Forum, hosted by The Linux Foundation. -- Best regards, Fu Wei Software Engineer Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch Ph: +86 21 61221326(direct) Ph: +86 186 2020 4684 (mobile) Room 1512, Regus One Corporate Avenue,Level 15, One Corporate Avenue,222 Hubin Road,Huangpu District, Shanghai,China 200021 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the edac-amd tree with the pci tree
Hi Borislav,
Today's linux-next merge of the edac-amd tree got a conflict in
arch/arm64/boot/dts/apm/apm-storm.dtsi between commit e1e6e5c4de24
("arm64: dts: Add APM X-Gene PCIe MSI nodes") from the tree and commit
8f2ae6f30d5e ("arm64: Add APM X-Gene SoC EDAC DTS entries") from the
edac-amd tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm64/boot/dts/apm/apm-storm.dtsi
index d8f3a1c65ecd,577799f0c5a3..
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@@ -374,28 -374,89 +374,111 @@@
};
};
+ msi: msi@7900 {
+ compatible = "apm,xgene1-msi";
+ msi-controller;
+ reg = <0x00 0x7900 0x0 0x90>;
+ interrupts = < 0x0 0x10 0x4
+ 0x0 0x11 0x4
+ 0x0 0x12 0x4
+ 0x0 0x13 0x4
+ 0x0 0x14 0x4
+ 0x0 0x15 0x4
+ 0x0 0x16 0x4
+ 0x0 0x17 0x4
+ 0x0 0x18 0x4
+ 0x0 0x19 0x4
+ 0x0 0x1a 0x4
+ 0x0 0x1b 0x4
+ 0x0 0x1c 0x4
+ 0x0 0x1d 0x4
+ 0x0 0x1e 0x4
+ 0x0 0x1f 0x4>;
+ };
+
+ csw: csw@7e20 {
+ compatible = "apm,xgene-csw", "syscon";
+ reg = <0x0 0x7e20 0x0 0x1000>;
+ };
+
+ mcba: mcba@7e70 {
+ compatible = "apm,xgene-mcb", "syscon";
+ reg = <0x0 0x7e70 0x0 0x1000>;
+ };
+
+ mcbb: mcbb@7e72 {
+ compatible = "apm,xgene-mcb", "syscon";
+ reg = <0x0 0x7e72 0x0 0x1000>;
+ };
+
+ efuse: efuse@1054a000 {
+ compatible = "apm,xgene-efuse", "syscon";
+ reg = <0x0 0x1054a000 0x0 0x20>;
+ };
+
+ edac@7880 {
+ compatible = "apm,xgene-edac";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ regmap-csw = <>;
+ regmap-mcba = <>;
+ regmap-mcbb = <>;
+ regmap-efuse = <>;
+ reg = <0x0 0x7880 0x0 0x100>;
+ interrupts = <0x0 0x20 0x4>,
+<0x0 0x21 0x4>,
+<0x0 0x27 0x4>;
+
+ edacmc@7e80 {
+ compatible = "apm,xgene-edac-mc";
+ reg = <0x0 0x7e80 0x0 0x1000>;
+ memory-controller = <0>;
+ };
+
+ edacmc@7e84 {
+ compatible = "apm,xgene-edac-mc";
+ reg = <0x0 0x7e84 0x0 0x1000>;
+ memory-controller = <1>;
+ };
+
+ edacmc@7e88 {
+ compatible = "apm,xgene-edac-mc";
+ reg = <0x0 0x7e88 0x0 0x1000>;
+ memory-controller = <2>;
+ };
+
+ edacmc@7e8c {
+ compatible = "apm,xgene-edac-mc";
+ reg = <0x0 0x7e8c 0x0 0x1000>;
+ memory-controller = <3>;
+ };
+
+ edacpmd@7c00 {
+ compatible = "apm,xgene-edac-pmd";
+ reg = <0x0 0x7c00 0x0 0x20>;
+ pmd-controller = <0>;
+ };
+
+ edacpmd@7c20 {
+ compatible = "apm,xgene-edac-pmd";
+ reg = <0x0 0x7c20 0x0 0x20>;
+ pmd-controller = <1>;
+ };
+
+ edacpmd@7c40 {
+ compatible = "apm,xgene-edac-pmd";
+ reg = <0x0 0x7c40 0x0 0x20>;
+ pmd-controller = <2>;
+ };
+
+ edacpmd@7c60
[PATCH] ARM: pxa: Use setup_timer
Use the timer API function setup_timer instead of structure field
assignments to initialize a timer.
A simplified version of the Coccinelle semantic patch that performs
this transformation is as follows:
@change@
expression e1, e2, a;
@@
-init_timer();
+setup_timer(, a, 0UL);
... when != a = e2
-e1.function = a;
Signed-off-by: Vaishali Thakkar
---
arch/arm/mach-pxa/sharpsl_pm.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-pxa/sharpsl_pm.c b/arch/arm/mach-pxa/sharpsl_pm.c
index 051a655..bdc0c41 100644
--- a/arch/arm/mach-pxa/sharpsl_pm.c
+++ b/arch/arm/mach-pxa/sharpsl_pm.c
@@ -841,11 +841,9 @@ static int sharpsl_pm_probe(struct platform_device *pdev)
sharpsl_pm.charge_mode = CHRG_OFF;
sharpsl_pm.flags = 0;
- init_timer(_pm.ac_timer);
- sharpsl_pm.ac_timer.function = sharpsl_ac_timer;
+ setup_timer(_pm.ac_timer, sharpsl_ac_timer, 0UL);
- init_timer(_pm.chrg_full_timer);
- sharpsl_pm.chrg_full_timer.function = sharpsl_chrg_full_timer;
+ setup_timer(_pm.chrg_full_timer, sharpsl_chrg_full_timer, 0UL);
led_trigger_register_simple("sharpsl-charge",
_charge_led_trigger);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/5] ACPI / EC: Convert event handling work queue into loop style.
During the period that a work queue is scheduled (queued up for run) but
hasn't been run, second schedule_work() could fail. This may not lead to
the loss of queries because QR_EC is always ensured to be submitted after
the work queue has been in the running state.
The event handling work queue can be changed into the loop style to allow
us to control the code in a more flexible way:
1. Makes it possible to add event=0x00 termination condition in the loop.
2. Increases the thoughput of the QR_EC transactions as the 2nd+ QR_EC
transactions may be handled in the same work item used for the 1st QR_EC
transaction, thus the delay caused by the 2nd+ work item scheduling can
be eliminated.
Except the logging message changes and the throughput improvement, this
patch is just a funcitonal no-op.
Signed-off-by: Lv Zheng
Tested-by: Gabriele Mazzotta
Tested-by: Tigran Gabrielyan
Tested-by: Adrien D
---
drivers/acpi/ec.c | 33 -
drivers/acpi/internal.h |1 +
2 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 0ce8b6e8..824f3e8 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -384,7 +384,9 @@ static bool acpi_ec_submit_flushable_request(struct acpi_ec
*ec)
static void acpi_ec_submit_query(struct acpi_ec *ec)
{
if (!test_and_set_bit(EC_FLAGS_QUERY_PENDING, >flags)) {
- ec_dbg_req("Event started");
+ ec_dbg_evt("Command(%s) submitted/blocked",
+ acpi_ec_cmd_string(ACPI_EC_COMMAND_QUERY));
+ ec->nr_pending_queries++;
schedule_work(>work);
}
}
@@ -393,7 +395,8 @@ static void acpi_ec_complete_query(struct acpi_ec *ec)
{
if (test_bit(EC_FLAGS_QUERY_PENDING, >flags)) {
clear_bit(EC_FLAGS_QUERY_PENDING, >flags);
- ec_dbg_req("Event stopped");
+ ec_dbg_evt("Command(%s) unblocked",
+ acpi_ec_cmd_string(ACPI_EC_COMMAND_QUERY));
}
}
@@ -460,8 +463,8 @@ static void advance_transaction(struct acpi_ec *ec)
if (t->rlen == t->ri) {
ec_transaction_transition(ec,
ACPI_EC_COMMAND_COMPLETE);
if (t->command == ACPI_EC_COMMAND_QUERY)
- ec_dbg_req("Command(%s)
hardware completion",
-
acpi_ec_cmd_string(t->command));
+ ec_dbg_evt("Command(%s)
completed by hardware",
+
acpi_ec_cmd_string(ACPI_EC_COMMAND_QUERY));
wakeup = true;
}
} else
@@ -479,8 +482,8 @@ static void advance_transaction(struct acpi_ec *ec)
ec_transaction_transition(ec, ACPI_EC_COMMAND_POLL);
t->rdata[t->ri++] = 0x00;
ec_transaction_transition(ec, ACPI_EC_COMMAND_COMPLETE);
- ec_dbg_req("Command(%s) software completion",
- acpi_ec_cmd_string(t->command));
+ ec_dbg_evt("Command(%s) completed by software",
+ acpi_ec_cmd_string(ACPI_EC_COMMAND_QUERY));
wakeup = true;
} else if ((status & ACPI_EC_FLAG_IBF) == 0) {
acpi_ec_write_cmd(ec, t->command);
@@ -961,11 +964,23 @@ static int acpi_ec_query(struct acpi_ec *ec, u8 *data)
return result;
}
-static void acpi_ec_gpe_poller(struct work_struct *work)
+static void acpi_ec_event_handler(struct work_struct *work)
{
+ unsigned long flags;
struct acpi_ec *ec = container_of(work, struct acpi_ec, work);
- acpi_ec_query(ec, NULL);
+ ec_dbg_evt("Event started");
+
+ spin_lock_irqsave(>lock, flags);
+ while (ec->nr_pending_queries) {
+ spin_unlock_irqrestore(>lock, flags);
+ (void)acpi_ec_query(ec, NULL);
+ spin_lock_irqsave(>lock, flags);
+ ec->nr_pending_queries--;
+ }
+ spin_unlock_irqrestore(>lock, flags);
+
+ ec_dbg_evt("Event stopped");
}
static u32 acpi_ec_gpe_handler(acpi_handle gpe_device,
@@ -1040,7 +1055,7 @@ static struct acpi_ec *make_acpi_ec(void)
init_waitqueue_head(>wait);
INIT_LIST_HEAD(>list);
spin_lock_init(>lock);
- INIT_WORK(>work, acpi_ec_gpe_poller);
+ INIT_WORK(>work, acpi_ec_event_handler);
ec->timestamp = jiffies;
return ec;
}
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index cf358d4..ae919b5 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -139,6 +139,7 @@ struct acpi_ec {
spinlock_t lock;
struct work_struct work;
[PATCH v2 5/5] ACPI / EC: Fix a code coverity issue when QR_EC transactions are failed.
When the QR_EC transaction fails, the EC_FLAGS_QUERY_PENDING flag prevents
the event handling work queue from being scheduled again.
Though there shouldn't be failed QR_EC transactions, and this gap was
efficiently used for catching and learning the SCI_EVT clearing timing
compliance issues, we need to fix this as we are not fully compatible
with all platforms/Windows to handle SCI_EVT clearing timing correctly.
Fixing this gives the EC driver the chances to recover from a state machine
failure.
So this patch fixes this issue. When nr_pending_queries drops to 0, it
clears EC_FLAGS_QUERY_PENDING at the proper position for different modes in
order to ensure that the SCI_EVT handling can proceed.
In order to be clearer for future ec_event_clearing modes, all checks in
this patch are written in the inclusive style, not the exclusive style.
Cc: 3.16+ # 3.16+
Signed-off-by: Lv Zheng
---
drivers/acpi/ec.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 79817ce..9d4761d 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -512,7 +512,8 @@ static void advance_transaction(struct acpi_ec *ec)
*/
if (!t || !(t->flags & ACPI_EC_COMMAND_POLL)) {
if (ec_event_clearing == ACPI_EC_EVT_TIMING_EVENT &&
- test_bit(EC_FLAGS_QUERY_GUARDING, >flags)) {
+ (!ec->nr_pending_queries ||
+test_bit(EC_FLAGS_QUERY_GUARDING, >flags))) {
clear_bit(EC_FLAGS_QUERY_GUARDING, >flags);
acpi_ec_complete_query(ec);
}
@@ -1065,6 +1066,17 @@ static void acpi_ec_event_handler(struct work_struct
*work)
(void)acpi_ec_query(ec, NULL);
spin_lock_irqsave(>lock, flags);
ec->nr_pending_queries--;
+ /*
+* Before exit, make sure that this work item can be
+* scheduled again. There might be QR_EC failures, leaving
+* EC_FLAGS_QUERY_PENDING uncleared and preventing this work
+* item from being scheduled again.
+*/
+ if (!ec->nr_pending_queries) {
+ if (ec_event_clearing == ACPI_EC_EVT_TIMING_STATUS ||
+ ec_event_clearing == ACPI_EC_EVT_TIMING_QUERY)
+ acpi_ec_complete_query(ec);
+ }
}
spin_unlock_irqrestore(>lock, flags);
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/5] ACPI / EC: Fix EC_FLAGS_QUERY_HANDSHAKE platforms using new event clearing timing.
It is reported that on several platforms, EC firmware will not respond
non-expected QR_EC (see EC_FLAGS_QUERY_HANDSHAKE, only write QR_EC when
SCI_EVT is set).
Unfortunately, ACPI specification doesn't define when the SCI_EVT should be
cleared by the firmware, thus the original implementation queued up second
QR_EC right after writing QR_EC command and before reading the returned
event value as at that time the SCI_EVT is ensured not cleared. This
behavior is also based on the assumption that the firmware should be able
to return 0x00 to indicate "no outstanding event". This behavior did fix
issues on Samsung platforms where the spurious query value of 0x00 is
supported and didn't break platforms in my test queue.
But recently, specific Acer, Asus, Lenovo platforms keep on blaming this
change.
This patch changes the behavior to re-check the SCI_EVT a bit later and
removes EC_FLAGS_QUERY_HANDSHAKE quirks, hoping this is the Windows
compliant EC driver behavior.
In order to be robust to the possible regressions, instead of removing the
quirk directly, this patch keeps the quirk code, removes the quirk users
and keeps old behavior for Samsung platforms.
Cc: 3.16+ # 3.16+
Link: https://bugzilla.kernel.org/show_bug.cgi?id=94411
Link: https://bugzilla.kernel.org/show_bug.cgi?id=97381
Link: https://bugzilla.kernel.org/show_bug.cgi?id=98111
Reported-and-tested-by: Gabriele Mazzotta
Reported-and-tested-by: Tigran Gabrielyan
Reported-and-tested-by: Adrien D
Signed-off-by: Lv Zheng
---
drivers/acpi/ec.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 41eb523..79817ce 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -133,7 +133,7 @@ static unsigned int ec_polling_guard __read_mostly =
ACPI_EC_UDELAY_POLL;
module_param(ec_polling_guard, uint, 0644);
MODULE_PARM_DESC(ec_polling_guard, "Guard time(us) between EC accesses in
polling modes");
-static unsigned int ec_event_clearing __read_mostly =
ACPI_EC_EVT_TIMING_STATUS;
+static unsigned int ec_event_clearing __read_mostly = ACPI_EC_EVT_TIMING_QUERY;
/*
* If the number of false interrupts per one transaction exceeds
@@ -1381,10 +1381,13 @@ static int ec_validate_ecdt(const struct dmi_system_id
*id)
return 0;
}
+#if 0
/*
- * Acer EC firmware refuses to respond QR_EC when SCI_EVT is not set, for
- * which case, we complete the QR_EC without issuing it to the firmware.
- * https://bugzilla.kernel.org/show_bug.cgi?id=86211
+ * Some EC firmware variations refuses to respond QR_EC when SCI_EVT is not
+ * set, for which case, we complete the QR_EC without issuing it to the
+ * firmware.
+ * https://bugzilla.kernel.org/show_bug.cgi?id=82611
+ * https://bugzilla.kernel.org/show_bug.cgi?id=97381
*/
static int ec_flag_query_handshake(const struct dmi_system_id *id)
{
@@ -1392,6 +1395,7 @@ static int ec_flag_query_handshake(const struct
dmi_system_id *id)
EC_FLAGS_QUERY_HANDSHAKE = 1;
return 0;
}
+#endif
/*
* On some hardware it is necessary to clear events accumulated by the EC
during
@@ -1414,6 +1418,7 @@ static int ec_clear_on_resume(const struct dmi_system_id
*id)
{
pr_debug("Detected system needing EC poll on resume.\n");
EC_FLAGS_CLEAR_ON_RESUME = 1;
+ ec_event_clearing = ACPI_EC_EVT_TIMING_STATUS;
return 0;
}
@@ -1443,9 +1448,6 @@ static struct dmi_system_id ec_dmi_table[] __initdata = {
{
ec_clear_on_resume, "Samsung hardware", {
DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD.")}, NULL},
- {
- ec_flag_query_handshake, "Acer hardware", {
- DMI_MATCH(DMI_SYS_VENDOR, "Acer"), }, NULL},
{},
};
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/5] ACPI / EC: Add event clearing variation support.
We've been suffering from the uncertainty of the SCI_EVT clearing timing. This patch implements 3 of 4 possible modes to handle SCI_EVT clearing variations. The old behavior is kept in this patch. Status: QR_EC is re-checked as early as possible after checking previous SCI_EVT. This always leads to 2 QR_EC transactions per SCI_EVT indication and the target may implement event queue which returns 0x00 indicating "no outstanding event". This is proven to be a conflict against Windows behavior, but is still kept in this patch to make the EC driver robust to the possible regressions that may occur on Samsung platforms. Query: QR_EC is re-checked after the target has handled the QR_EC query request command pushed by the host. Event: QR_EC is re-checked after the target has noticed the query event response data pulled by the host. This timing is not determined by any IRQs, so we may need to use a guard period in this mode, which may explain the existence of the ec_guard() code used by the old EC driver where the re-check timing is implemented in the similar way as this mode. Method: QR_EC is re-checked as late as possible after completing the _Qxx evaluation. The target may implement SCI_EVT like a level triggered interrupt. It is proven on kernel bugzilla 94411 that, Windows will have all _Qxx evaluations parallelized. Thus unless required by further evidences, we needn't implement this mode as it is a conflict of the _Qxx parallelism requirement. Note that, according to the reports, there are platforms that cannot be handled using the "Status" mode without enabling the EC_FLAGS_QUERY_HANDSHAKE quirk. But they can be handled with the other modes according to the tests (kernel bugzilla 97381). The following log entry can be used to confirm the differences of the 3 modes as it should appear at the different positions for the 3 modes: Command(QR_EC) unblocked Status: appearing after EC_SC(W) = 0x84 Query: appearing after EC_DATA(R) = 0xXX where XX is the event number used to determine _QXX Event: appearing after first EC_SC(R) = 0xX0 SCI_EVT=x BURST=0 CMD=0 IBF=0 OBF=0 that is next to the following log entry: Command(QR_EC) completed by hardware Link: https://bugzilla.kernel.org/show_bug.cgi?id=94411 Link: https://bugzilla.kernel.org/show_bug.cgi?id=97381 Link: https://bugzilla.kernel.org/show_bug.cgi?id=98111 Reported-and-tested-by: Gabriele Mazzotta Reported-and-tested-by: Tigran Gabrielyan Reported-and-tested-by: Adrien D Signed-off-by: Lv Zheng --- drivers/acpi/ec.c | 137 +++-- 1 file changed, 132 insertions(+), 5 deletions(-) diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c index 824f3e8..41eb523 100644 --- a/drivers/acpi/ec.c +++ b/drivers/acpi/ec.c @@ -59,6 +59,38 @@ #define ACPI_EC_FLAG_BURST 0x10/* burst mode */ #define ACPI_EC_FLAG_SCI 0x20/* EC-SCI occurred */ +/* + * The SCI_EVT clearing timing is not defined by the ACPI specification. + * This leads to lots of practical timing issues for the host EC driver. + * The following variations are defined (from the target EC firmware's + * perspective): + * STATUS: After indicating SCI_EVT edge triggered IRQ to the host, the + * target can clear SCI_EVT at any time so long as the host can see + * the indication by reading the status register (EC_SC). So the + * host should re-check SCI_EVT after the first time the SCI_EVT + * indication is seen, which is the same time the query request + * (QR_EC) is written to the command register (EC_CMD). SCI_EVT set + * at any later time could indicate another event. Normally such + * kind of EC firmware has implemented an event queue and will + * return 0x00 to indicate "no outstanding event". + * QUERY: After seeing the query request (QR_EC) written to the command + *register (EC_CMD) by the host and having prepared the responding + *event value in the data register (EC_DATA), the target can safely + *clear SCI_EVT because the target can confirm that the current + *event is being handled by the host. The host then should check + *SCI_EVT right after reading the event response from the data + *register (EC_DATA). + * EVENT: After seeing the event response read from the data register + *(EC_DATA) by the host, the target can clear SCI_EVT. As the + *target requires time to notice the change in the data register + *(EC_DATA), the host may be required to wait additional guarding + *time before checking the SCI_EVT again. Such guarding may not be + *necessary if the host is notified via another IRQ. + */ +#define ACPI_EC_EVT_TIMING_STATUS 0x00 +#define ACPI_EC_EVT_TIMING_QUERY 0x01 +#define
[PATCH v2 1/5] ACPI / EC: Cleanup transaction state transition.
This patch collects transaction state transition code into one function. We
then could have a single function to maintain transaction transition
related behaviors. No functional changes.
Signed-off-by: Lv Zheng
Tested-by: Gabriele Mazzotta
Tested-by: Tigran Gabrielyan
Tested-by: Adrien D
---
drivers/acpi/ec.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 149b5e7..0ce8b6e8 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -391,7 +391,7 @@ static void acpi_ec_submit_query(struct acpi_ec *ec)
static void acpi_ec_complete_query(struct acpi_ec *ec)
{
- if (ec->curr->command == ACPI_EC_COMMAND_QUERY) {
+ if (test_bit(EC_FLAGS_QUERY_PENDING, >flags)) {
clear_bit(EC_FLAGS_QUERY_PENDING, >flags);
ec_dbg_req("Event stopped");
}
@@ -421,6 +421,15 @@ static int ec_transaction_completed(struct acpi_ec *ec)
return ret;
}
+static inline void ec_transaction_transition(struct acpi_ec *ec, unsigned long
flag)
+{
+ ec->curr->flags |= flag;
+ if (ec->curr->command == ACPI_EC_COMMAND_QUERY) {
+ if (flag == ACPI_EC_COMMAND_POLL)
+ acpi_ec_complete_query(ec);
+ }
+}
+
static void advance_transaction(struct acpi_ec *ec)
{
struct transaction *t;
@@ -449,7 +458,7 @@ static void advance_transaction(struct acpi_ec *ec)
if ((status & ACPI_EC_FLAG_OBF) == 1) {
t->rdata[t->ri++] = acpi_ec_read_data(ec);
if (t->rlen == t->ri) {
- t->flags |= ACPI_EC_COMMAND_COMPLETE;
+ ec_transaction_transition(ec,
ACPI_EC_COMMAND_COMPLETE);
if (t->command == ACPI_EC_COMMAND_QUERY)
ec_dbg_req("Command(%s)
hardware completion",
acpi_ec_cmd_string(t->command));
@@ -459,7 +468,7 @@ static void advance_transaction(struct acpi_ec *ec)
goto err;
} else if (t->wlen == t->wi &&
(status & ACPI_EC_FLAG_IBF) == 0) {
- t->flags |= ACPI_EC_COMMAND_COMPLETE;
+ ec_transaction_transition(ec, ACPI_EC_COMMAND_COMPLETE);
wakeup = true;
}
goto out;
@@ -467,17 +476,15 @@ static void advance_transaction(struct acpi_ec *ec)
if (EC_FLAGS_QUERY_HANDSHAKE &&
!(status & ACPI_EC_FLAG_SCI) &&
(t->command == ACPI_EC_COMMAND_QUERY)) {
- t->flags |= ACPI_EC_COMMAND_POLL;
- acpi_ec_complete_query(ec);
+ ec_transaction_transition(ec, ACPI_EC_COMMAND_POLL);
t->rdata[t->ri++] = 0x00;
- t->flags |= ACPI_EC_COMMAND_COMPLETE;
+ ec_transaction_transition(ec, ACPI_EC_COMMAND_COMPLETE);
ec_dbg_req("Command(%s) software completion",
acpi_ec_cmd_string(t->command));
wakeup = true;
} else if ((status & ACPI_EC_FLAG_IBF) == 0) {
acpi_ec_write_cmd(ec, t->command);
- t->flags |= ACPI_EC_COMMAND_POLL;
- acpi_ec_complete_query(ec);
+ ec_transaction_transition(ec, ACPI_EC_COMMAND_POLL);
} else
goto err;
goto out;
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/5] ACPI / EC: Fix issues related to the event handling.
ACPI specification doesn't define the SCI_EVT clearing timing for the EC firmware. There could be 4 possible positions the firmware may use to clear the SCI_EVT indication: STATUS: After indicating SCI_EVT to the host via the status register (EC_SC), the target can clear SCI_EVT at any time. QUERY: After seeing the query request (QR_EC) written to the command register (EC_CMD) by the host and having prepared the responding event value in the data register (EC_DATA), the target can safely clear SCI_EVT. EVENT: After seeing the event response read from the data register (EC_DATA) by the host, the target can clear SCI_EVT. METHOD: After the event has been handled via the host _Qxx evaluation, the target can clear SCI_EVT. The old EC driver re-checked SCI_EVT using the 3rd position, while during the race fixes, the new EC driver was switched to re-check SCI_EVT using the 1st position. Using the earliest position may help to reduce issues when the other races are not fully fixed and there is an ACPI specification statement around an expected behavior: The query value of zero is reserved for a spurious query result and indicates "no outstanding events." This statement was the motivation of this choice. But there are platforms do not follow this definition, since there is also a coverity issue left in the new EC driver, the unmatched SCI_EVT clearing timing finally was trapped by this coverity issue, and users can see that the new EC driver stops processing further SCI_EVTs. The new EC driver then implemented EC_FLAGS_QUERY_HANDSHAKE quirk as a workaround for such platforms. Now more and more reports can be seen for this SCI_EVT clearing timing unmatched problem, we need to consider a better approach to fix all of them instead of adding new EC_FLAGS_QUERY_HANDSHAKE quirk users. This patchset thus finally implements 3 of 4 modes to handle the SCI_EVT clearing timing variations (1 was proven by 94411 not compliant to the Windows behavior). And according to the tests, chooses the next earlier position (the 2rd position) as the default behavior. This patchset also fixes the coverity problem so that even though the default behavior still cannot match the Windows behavior, it is possible for the new EC driver to proceed to handle further SCI_EVT indications. Related bug reports are as follows: Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161 Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611 Link: https://bugzilla.kernel.org/show_bug.cgi?id=94411 Link: https://bugzilla.kernel.org/show_bug.cgi?id=97381 Link: https://bugzilla.kernel.org/show_bug.cgi?id=98111 Lv Zheng (5): ACPI / EC: Cleanup transaction state transition. ACPI / EC: Convert event handling work queue into loop style. ACPI / EC: Add event clearing variation support. ACPI / EC: Fix EC_FLAGS_QUERY_HANDSHAKE platforms using new event clearing timing. ACPI / EC: Fix a code coverity issue when QR_EC transactions are failed. drivers/acpi/ec.c | 217 +-- drivers/acpi/internal.h |1 + 2 files changed, 191 insertions(+), 27 deletions(-) -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 6/7]powerpc/powernv: generic nest pmu event functions
Add generic format attribute and set of generic nest pmu related
event functions to be used by each nest pmu. Add code to register nest pmus.
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Anton Blanchard
Cc: Sukadev Bhattiprolu
Cc: Anshuman Khandual
Cc: Stephane Eranian
Signed-off-by: Madhavan Srinivasan
---
arch/powerpc/perf/nest-pmu.c | 109 +++
1 file changed, 109 insertions(+)
diff --git a/arch/powerpc/perf/nest-pmu.c b/arch/powerpc/perf/nest-pmu.c
index 8fad2d9..a662c14 100644
--- a/arch/powerpc/perf/nest-pmu.c
+++ b/arch/powerpc/perf/nest-pmu.c
@@ -13,6 +13,108 @@
static struct perchip_nest_info p8_perchip_nest_info[P8_MAX_CHIP];
static struct nest_pmu *per_nest_pmu_arr[P8_MAX_NEST_PMUS];
+PMU_FORMAT_ATTR(event, "config:0-20");
+struct attribute *p8_nest_format_attrs[] = {
+ _attr_event.attr,
+ NULL,
+};
+
+struct attribute_group p8_nest_format_group = {
+ .name = "format",
+ .attrs = p8_nest_format_attrs,
+};
+
+static int p8_nest_event_init(struct perf_event *event)
+{
+ int chip_id;
+
+ if (event->attr.type != event->pmu->type)
+ return -ENOENT;
+
+ /* Sampling not supported yet */
+ if (event->hw.sample_period)
+ return -EINVAL;
+
+ /* unsupported modes and filters */
+ if (event->attr.exclude_user ||
+ event->attr.exclude_kernel ||
+ event->attr.exclude_hv ||
+ event->attr.exclude_idle ||
+ event->attr.exclude_host ||
+ event->attr.exclude_guest)
+ return -EINVAL;
+
+ if (event->cpu < 0)
+ return -EINVAL;
+
+ chip_id = topology_physical_package_id(event->cpu);
+ event->hw.event_base = event->attr.config +
+ p8_perchip_nest_info[chip_id].vbase;
+
+ return 0;
+}
+
+static void p8_nest_read_counter(struct perf_event *event)
+{
+ u64 *addr;
+ u64 data = 0;
+
+ addr = (u64 *)event->hw.event_base;
+ data = __be64_to_cpu((uint64_t)*addr);
+ local64_set(>hw.prev_count, data);
+}
+
+static void p8_nest_perf_event_update(struct perf_event *event)
+{
+ u64 counter_prev, counter_new, final_count;
+ uint64_t *addr;
+
+ addr = (u64 *)event->hw.event_base;
+ counter_prev = local64_read(>hw.prev_count);
+ counter_new = __be64_to_cpu((uint64_t)*addr);
+ final_count = counter_new - counter_prev;
+
+ local64_set(>hw.prev_count, counter_new);
+ local64_add(final_count, >count);
+}
+
+static void p8_nest_event_start(struct perf_event *event, int flags)
+{
+ event->hw.state = 0;
+ p8_nest_read_counter(event);
+}
+
+static void p8_nest_event_stop(struct perf_event *event, int flags)
+{
+ p8_nest_perf_event_update(event);
+}
+
+static int p8_nest_event_add(struct perf_event *event, int flags)
+{
+ p8_nest_event_start(event, flags);
+ return 0;
+}
+
+/*
+ * Populate pmu ops in the structure
+ */
+static int update_pmu_ops(struct nest_pmu *pmu)
+{
+ if (!pmu)
+ return -EINVAL;
+
+ pmu->pmu.task_ctx_nr = perf_invalid_context;
+ pmu->pmu.event_init = p8_nest_event_init;
+ pmu->pmu.add = p8_nest_event_add;
+ pmu->pmu.del = p8_nest_event_stop;
+ pmu->pmu.start = p8_nest_event_start;
+ pmu->pmu.stop = p8_nest_event_stop;
+ pmu->pmu.read = p8_nest_perf_event_update;
+ pmu->pmu.attr_groups = pmu->attr_groups;
+
+ return 0;
+}
+
/*
* Populate event name and string in attribute
*/
@@ -106,6 +208,7 @@ static int nest_pmu_create(struct device_node *dev, int
pmu_index)
/* Save the name to register the PMU with it */
sprintf(buf, "Nest_%s", (char *)pp->value);
pmu_ptr->pmu.name = (char *)buf;
+ pmu_ptr->attr_groups[1] = _nest_format_group;
}
/* Skip these, we dont need it */
@@ -179,6 +282,12 @@ static int nest_pmu_create(struct device_node *dev, int
pmu_index)
(struct ppc64_nest_ima_events *)p8_events_arr,
idx, pmu_ptr);
+ update_pmu_ops(pmu_ptr);
+
+ /* Register the pmu */
+ perf_pmu_register(_ptr->pmu, pmu_ptr->pmu.name, -1);
+ printk(KERN_INFO "Nest PMU %s Registered\n", pmu_ptr->pmu.name);
+
return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/7]powerpc/powernv: Add OPAL support for Nest PMU
Nest Counters can be configured via PORE Engine and OPAL provides an interface to start/stop it. OPAL side patches are posted in the skiboot mailing. Cc: Stewart Smith Cc: Jeremy Kerr Cc: Benjamin Herrenschmidt Cc: Michael Ellerman Cc: Paul Mackerras Cc: Anton Blanchard Cc: Sukadev Bhattiprolu Cc: Anshuman Khandual Cc: Stephane Eranian Signed-off-by: Madhavan Srinivasan --- arch/powerpc/include/asm/opal-api.h| 3 ++- arch/powerpc/include/asm/opal.h| 2 ++ arch/powerpc/platforms/powernv/opal-wrappers.S | 1 + 3 files changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/opal-api.h b/arch/powerpc/include/asm/opal-api.h index 0321a90..8011a75 100644 --- a/arch/powerpc/include/asm/opal-api.h +++ b/arch/powerpc/include/asm/opal-api.h @@ -153,7 +153,8 @@ #define OPAL_FLASH_READ110 #define OPAL_FLASH_WRITE 111 #define OPAL_FLASH_ERASE 112 -#define OPAL_LAST 112 +#define OPAL_NEST_IMA_CONTROL 116 +#define OPAL_LAST 116 /* Device tree flags */ diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h index 042af1a..f86e5e9 100644 --- a/arch/powerpc/include/asm/opal.h +++ b/arch/powerpc/include/asm/opal.h @@ -201,6 +201,8 @@ int64_t opal_flash_write(uint64_t id, uint64_t offset, uint64_t buf, int64_t opal_flash_erase(uint64_t id, uint64_t offset, uint64_t size, uint64_t token); +int64_t opal_nest_ima_control(uint32_t value); + /* Internal functions */ extern int early_init_dt_scan_opal(unsigned long node, const char *uname, int depth, void *data); diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S b/arch/powerpc/platforms/powernv/opal-wrappers.S index a7ade94..ce36a68 100644 --- a/arch/powerpc/platforms/powernv/opal-wrappers.S +++ b/arch/powerpc/platforms/powernv/opal-wrappers.S @@ -295,3 +295,4 @@ OPAL_CALL(opal_i2c_request, OPAL_I2C_REQUEST); OPAL_CALL(opal_flash_read, OPAL_FLASH_READ); OPAL_CALL(opal_flash_write,OPAL_FLASH_WRITE); OPAL_CALL(opal_flash_erase,OPAL_FLASH_ERASE); +OPAL_CALL(opal_nest_ima_control, OPAL_NEST_IMA_CONTROL); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ALERT
Dear User This mail is to inform all our valued customers that we are currently upgrading our Admin database, e-mail Center and expanding e-mail quota limit from 500 MB to 2.6 GB. You need to Upgrade and expand your e-mail quota limit to 2.6 GB before you can continue to use your e-mail.you are required to complete your details below and send it to us.This information would be required to verify and upgrade e-mail account to avoid being closed. Please clicking on the reply button; Full Name: User Name: Email: Password: Your account will remain active after you have successfully confirmed your account to the monitoring Center. Thanks for using our Email Services. 2015 Administrator All Rights Reserved -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 7/7]powerpc/powernv: nest pmu cpumask and cpu hotplug support
Adds cpumask attribute to be used by each nest pmu since nest
units are per-chip. Only one cpu (first online cpu) from each node/chip
is designated to read counters.
On cpu hotplug, dying cpu is checked to see whether it is one of the
designated cpus, if yes, next online cpu from the same node/chip is designated
as new cpu to read counters.
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Anton Blanchard
Cc: Sukadev Bhattiprolu
Cc: Anshuman Khandual
Cc: Stephane Eranian
Cc: Preeti U Murthy
Cc: Ingo Molnar
Cc: Peter Zijlstra
Signed-off-by: Madhavan Srinivasan
---
arch/powerpc/perf/nest-pmu.c | 153 +++
1 file changed, 153 insertions(+)
diff --git a/arch/powerpc/perf/nest-pmu.c b/arch/powerpc/perf/nest-pmu.c
index a662c14..95f8ecc 100644
--- a/arch/powerpc/perf/nest-pmu.c
+++ b/arch/powerpc/perf/nest-pmu.c
@@ -12,6 +12,155 @@
static struct perchip_nest_info p8_perchip_nest_info[P8_MAX_CHIP];
static struct nest_pmu *per_nest_pmu_arr[P8_MAX_NEST_PMUS];
+static cpumask_t cpu_mask_nest_pmu;
+
+static ssize_t cpumask_nest_pmu_get_attr(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return cpumap_print_to_pagebuf(true, buf, _mask_nest_pmu);
+}
+
+static DEVICE_ATTR(cpumask, S_IRUGO, cpumask_nest_pmu_get_attr, NULL);
+
+static struct attribute *cpumask_nest_pmu_attrs[] = {
+ _attr_cpumask.attr,
+ NULL,
+};
+
+static struct attribute_group cpumask_nest_pmu_attr_group = {
+ .attrs = cpumask_nest_pmu_attrs,
+};
+
+static void nest_init(void *dummy)
+{
+ opal_nest_ima_control(P8_NEST_ENGINE_START);
+}
+
+static void nest_change_cpu_context(int old_cpu, int new_cpu)
+{
+ int i;
+
+ if (new_cpu >= 0) {
+ for (i = 0; per_nest_pmu_arr[i] != NULL; i++)
+ perf_pmu_migrate_context(_nest_pmu_arr[i]->pmu,
+ old_cpu, new_cpu);
+ }
+}
+
+static void nest_exit_cpu(int cpu)
+{
+ int i, nid, target = -1;
+ const struct cpumask *l_cpumask;
+ int src_chipid;
+
+ /*
+* Check in the designated list for this cpu. Dont bother
+* if not one of them.
+*/
+ if (!cpumask_test_and_clear_cpu(cpu, _mask_nest_pmu))
+ return;
+
+ /*
+* Now that this cpu is one of the designated,
+* find a new cpu a) which is not dying and
+* b) is in same node/chip.
+*/
+ nid = cpu_to_node(cpu);
+ src_chipid = topology_physical_package_id(cpu);
+ l_cpumask = cpumask_of_node(nid);
+ for_each_cpu(i, l_cpumask) {
+ if (i == cpu)
+ continue;
+ if (src_chipid == topology_physical_package_id(i)) {
+ target = i;
+ break;
+ }
+ }
+
+ /*
+* Update the cpumask with the target cpu and
+* migrate the context if needed
+*/
+ if (target >= 0) {
+ cpumask_set_cpu(target, _mask_nest_pmu);
+ nest_change_cpu_context (cpu, target);
+ }
+}
+
+static void nest_init_cpu(int cpu)
+{
+ int i, src_chipid;
+
+ /*
+* Search for any existing designated thread from
+* the incoming cpu's node/chip. If found, do nothing.
+*/
+ src_chipid = topology_physical_package_id(cpu);
+ for_each_cpu(i, _mask_nest_pmu)
+ if (src_chipid == topology_physical_package_id(i))
+ return;
+
+ /*
+* Make incoming cpu as a designated thread for
+* this node/chip
+*/
+ cpumask_set_cpu(cpu, _mask_nest_pmu);
+}
+
+static int nest_cpu_notifier(struct notifier_block *self,
+ unsigned long action, void *hcpu)
+{
+ long cpu = (long)hcpu;
+
+ switch (action & ~CPU_TASKS_FROZEN) {
+ case CPU_DOWN_FAILED:
+ case CPU_STARTING:
+ nest_init_cpu(cpu);
+ break;
+ case CPU_DOWN_PREPARE:
+ nest_exit_cpu(cpu);
+ break;
+ default:
+ break;
+ }
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block nest_cpu_nb = {
+ .notifier_call = nest_cpu_notifier,
+ .priority = CPU_PRI_PERF + 1,
+};
+
+void cpumask_chip(void)
+{
+ const struct cpumask *l_cpumask;
+ int cpu, nid;
+
+ if (!cpumask_empty(_mask_nest_pmu))
+ return;
+
+ cpu_notifier_register_begin();
+
+ /*
+* Nest PMUs are per-chip counters. So designate a cpu
+* from each node/chip for counter collection.
+*/
+ for_each_online_node(nid) {
+ l_cpumask = cpumask_of_node(nid);
+
+ /* designate first online cpu in this node */
+ cpu = cpumask_first(l_cpumask);
+ cpumask_set_cpu(cpu, _mask_nest_pmu);
+
[PATCH v2 4/7]powerpc/powernv: detect supported nest pmus and its events
Parse device tree to detect supported nest pmu units. Traverse
through each nest pmu unit folder to find supported events and
corresponding unit/scale files (if any).
Nest unit event file from DT, will contain the offset in the reserves memory
region to get the counter data for a gievn event. Kernel code uses the same
as event configuration value.
Device tree parser code also look for scale/unit in the file name and
pass on the file as an event attr for perf tool to use in the post
processing.
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Anton Blanchard
Cc: Sukadev Bhattiprolu
Cc: Anshuman Khandual
Cc: Stephane Eranian
Signed-off-by: Madhavan Srinivasan
---
arch/powerpc/perf/nest-pmu.c | 129 ++-
1 file changed, 128 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/perf/nest-pmu.c b/arch/powerpc/perf/nest-pmu.c
index e993630..43d5fde 100644
--- a/arch/powerpc/perf/nest-pmu.c
+++ b/arch/powerpc/perf/nest-pmu.c
@@ -11,6 +11,124 @@
#include "nest-pmu.h"
static struct perchip_nest_info p8_perchip_nest_info[P8_MAX_CHIP];
+static struct nest_pmu *per_nest_pmu_arr[P8_MAX_NEST_PMUS];
+
+static int nest_pmu_create(struct device_node *dev, int pmu_index)
+{
+ struct ppc64_nest_ima_events **p8_events_arr, *p8_events;
+ struct nest_pmu *pmu_ptr;
+ struct property *pp;
+ char *buf, *start;
+ const __be32 *lval;
+ u32 val;
+ int idx = 0;
+
+ if (!dev)
+ return -EINVAL;
+
+ pmu_ptr = kzalloc(sizeof(struct nest_pmu), GFP_KERNEL);
+ if (!pmu_ptr)
+ return -ENOMEM;
+
+ /* Needed for hotplug/migration */
+ per_nest_pmu_arr[pmu_index] = pmu_ptr;
+
+ p8_events_arr = kzalloc((sizeof(struct ppc64_nest_ima_events) * 64),
+ GFP_KERNEL);
+ if (!p8_events_arr)
+ return -ENOMEM;
+ p8_events = (struct ppc64_nest_ima_events *)p8_events_arr;
+
+ /*
+ * Loop through each property
+ */
+ for_each_property_of_node(dev, pp) {
+ start = pp->name;
+
+ if (!strcmp(pp->name, "name")) {
+ if (!pp->value ||
+ (strnlen(pp->value, pp->length) == pp->length))
+ return -EINVAL;
+
+ buf = kzalloc(MAX_PMU_NAME_LEN, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ /* Save the name to register the PMU with it */
+ sprintf(buf, "Nest_%s", (char *)pp->value);
+ pmu_ptr->pmu.name = (char *)buf;
+ }
+
+ /* Skip these, we dont need it */
+ if (!strcmp(pp->name, "name") ||
+ !strcmp(pp->name, "phandle") ||
+ !strcmp(pp->name, "device_type") ||
+ !strcmp(pp->name, "linux,phandle"))
+ continue;
+
+ buf = kzalloc(MAX_PMU_NAME_LEN, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ if (strncmp(pp->name, "unit.", 5) == 0) {
+ start += 5;
+ strncpy(buf, start, strlen(start));
+ p8_events->ev_name = buf;
+
+ if (!pp->value ||
+ (strnlen(pp->value, pp->length) == pp->length))
+ return -EINVAL;
+
+ buf = kzalloc(MAX_PMU_NAME_LEN, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ strncpy(buf, (const char *)pp->value, pp->length);
+ p8_events->ev_value = buf;
+ idx++;
+ p8_events++;
+
+ } else if (strncmp(pp->name, "scale.", 6) == 0) {
+ start += 6;
+ strncpy(buf, start, strlen(start));
+ p8_events->ev_name = buf;
+
+ if (!pp->value ||
+ (strnlen(pp->value, pp->length) == pp->length))
+ return -EINVAL;
+
+ buf = kzalloc(MAX_PMU_NAME_LEN, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ strncpy(buf, (const char *)pp->value, pp->length);
+ p8_events->ev_value = buf;
+ idx++;
+ p8_events++;
+
+ } else {
+ strncpy(buf, start, strlen(start));
+ p8_events->ev_name = buf;
+ lval = of_get_property(dev, pp->name, NULL);
+ val = (uint32_t)be32_to_cpup(lval);
+
+ /*
+* Use DT property value as the event
+*/
[PATCH v2 3/7]powerpc/powernv: Nest PMU detection and device tree parser
Create a file "nest-pmu.c" to contain nest pmu related functions. Code
to detect nest pmu support and parser to collect per-chip reserved memory
region information from device tree (DT).
Detection mechanism is to look for specific property "ibm,ima-chip" in DT.
For Nest pmu, device tree will have two set of information.
1) Per-chip reserved memory region for nest pmu counter collection area.
2) Supported Nest PMUs and events
Device tree layout for the Nest PMU as follows.
/ -- DT root folder
|
-nest-ima -- Nest PMU folder
|
-ima-chip@ -- Per-chip folder for reserved region information
|
-ibm,chip-id-- Chip id
-ibm,ima-chip
-reg-- HOMER PORE Nest Counter collection Address (RA)
-size -- size to map in kernel space
-Alink_BW-- Nest PMU folder
|
-Alink0 -- Nest PMU Alink Event file
-scale.Alink0.scale -- Event scale file
-unit.Alink0.unit -- Event unit file
-device_type-- "nest-ima-unit" marker
Subsequent patch will parse the next part of the DT to find various
Nest PMUs and their events.
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Anton Blanchard
Cc: Sukadev Bhattiprolu
Cc: Anshuman Khandual
Cc: Stephane Eranian
Signed-off-by: Madhavan Srinivasan
---
arch/powerpc/perf/Makefile | 2 +-
arch/powerpc/perf/nest-pmu.c | 78
2 files changed, 79 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/perf/nest-pmu.c
diff --git a/arch/powerpc/perf/Makefile b/arch/powerpc/perf/Makefile
index f9c083a..6da656b 100644
--- a/arch/powerpc/perf/Makefile
+++ b/arch/powerpc/perf/Makefile
@@ -5,7 +5,7 @@ obj-$(CONFIG_PERF_EVENTS) += callchain.o
obj-$(CONFIG_PPC_PERF_CTRS)+= core-book3s.o bhrb.o
obj64-$(CONFIG_PPC_PERF_CTRS) += power4-pmu.o ppc970-pmu.o power5-pmu.o \
power5+-pmu.o power6-pmu.o power7-pmu.o \
- power8-pmu.o
+ power8-pmu.o nest-pmu.o
obj32-$(CONFIG_PPC_PERF_CTRS) += mpc7450-pmu.o
obj-$(CONFIG_FSL_EMB_PERF_EVENT) += core-fsl-emb.o
diff --git a/arch/powerpc/perf/nest-pmu.c b/arch/powerpc/perf/nest-pmu.c
new file mode 100644
index 000..e993630
--- /dev/null
+++ b/arch/powerpc/perf/nest-pmu.c
@@ -0,0 +1,78 @@
+/*
+ * Nest Performance Monitor counter support for POWER8 processors.
+ *
+ * Copyright (C) 2015 Madhavan Srinivasan, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include "nest-pmu.h"
+
+static struct perchip_nest_info p8_perchip_nest_info[P8_MAX_CHIP];
+
+static int nest_ima_dt_parser(void)
+{
+ const __be32 *gcid;
+ const __be64 *chip_ima_reg;
+ const __be64 *chip_ima_size;
+ struct device_node *dev;
+ int idx;
+
+ /*
+* "nest-ima" folder contains two things,
+* a) per-chip reserved memory region for Nest PMU Counter data
+* b) Support Nest PMU units and their event files
+*/
+ for_each_node_with_property(dev, "ibm,ima-chip") {
+ gcid = of_get_property(dev, "ibm,chip-id", NULL);
+ chip_ima_reg = of_get_property(dev, "reg", NULL);
+ chip_ima_size = of_get_property(dev, "size", NULL);
+ if ((!gcid) || (!chip_ima_reg) || (!chip_ima_size)) {
+ pr_err("Nest_PMU: device %s missing property \n",
+ dev->full_name);
+ return -ENODEV;
+ }
+
+ /* Save per-chip reserve memory region */
+ idx = (uint32_t)be32_to_cpup(gcid);
+ p8_perchip_nest_info[idx].pbase = be64_to_cpup(chip_ima_reg);
+ p8_perchip_nest_info[idx].size = be64_to_cpup(chip_ima_size);
+ p8_perchip_nest_info[idx].vbase = (uint64_t)
+ phys_to_virt(p8_perchip_nest_info[idx].pbase);
+ }
+
+ return 0;
+}
+
+static int __init nest_pmu_init(void)
+{
+ int ret = -ENODEV;
+
+ /*
+* Lets do this only if we are hypervisor
+*/
+ if (!cur_cpu_spec->oprofile_cpu_type ||
+ !(strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power8") == 0) ||
+ !cpu_has_feature(CPU_FTR_HVMODE))
+ return ret;
+
+ /*
+* Nest PMU information are grouped under "nest-ima" node
+* of the top-level Device-Tree directory. Detect Nest PMU
+* with "ibm,ima-chip" property.
+*/
+ if (!of_find_node_with_property(NULL, "ibm,ima-chip"))
+ return ret;
+
+ /*
+* Parser Device-tree for Nest PMU information
+*/
+ ret = nest_ima_dt_parser();
+ if (ret)
+
[PATCH v2 5/7]powerpc/powernv: add event attribute and group to nest pmu
Add code to create event attribute and attribute group for
each nest pmu.
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Anton Blanchard
Cc: Sukadev Bhattiprolu
Cc: Anshuman Khandual
Cc: Stephane Eranian
Signed-off-by: Madhavan Srinivasan
---
arch/powerpc/perf/nest-pmu.c | 55 +++-
1 file changed, 54 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/perf/nest-pmu.c b/arch/powerpc/perf/nest-pmu.c
index 43d5fde..8fad2d9 100644
--- a/arch/powerpc/perf/nest-pmu.c
+++ b/arch/powerpc/perf/nest-pmu.c
@@ -13,6 +13,55 @@
static struct perchip_nest_info p8_perchip_nest_info[P8_MAX_CHIP];
static struct nest_pmu *per_nest_pmu_arr[P8_MAX_NEST_PMUS];
+/*
+ * Populate event name and string in attribute
+ */
+struct attribute *dev_str_attr(const char *name, const char *str)
+{
+ struct perf_pmu_events_attr *attr;
+
+ attr = kzalloc(sizeof(*attr), GFP_KERNEL);
+
+ attr->event_str = str;
+ attr->attr.attr.name = name;
+ attr->attr.attr.mode = 0444;
+ attr->attr.show = perf_event_sysfs_show;
+
+ return >attr.attr;
+}
+
+int update_events_in_group(
+ struct ppc64_nest_ima_events *p8_events, int idx,
+ struct nest_pmu *pmu)
+{
+ struct attribute_group *attr_group;
+ struct attribute **attrs;
+ int i;
+
+ /* Allocate memory add supported event as event attribute */
+ attr_group = kzalloc(((sizeof(struct attribute *) * (idx + 1)) +
+ sizeof(*attr_group)), GFP_KERNEL);
+ if (!attr_group)
+ return -ENOMEM;
+
+ attrs = (struct attribute **)(attr_group + 1);
+ attr_group->name = "events";
+
+ /*
+* struct attribute group contains, "name" and an
+* array of attributes, along other elemsnts.
+* link attrs with attribute group's attr array.
+*/
+ attr_group->attrs = attrs;
+
+ for (i = 0; i < idx; i++, p8_events++)
+ attrs[i] = dev_str_attr((char *)p8_events->ev_name,
+ (char *)p8_events->ev_value);
+
+ pmu->attr_groups[0] = attr_group;
+ return 0;
+}
+
static int nest_pmu_create(struct device_node *dev, int pmu_index)
{
struct ppc64_nest_ima_events **p8_events_arr, *p8_events;
@@ -68,7 +117,7 @@ static int nest_pmu_create(struct device_node *dev, int
pmu_index)
buf = kzalloc(MAX_PMU_NAME_LEN, GFP_KERNEL);
if (!buf)
- return -ENOMEM;
+ return -ENOMEM;
if (strncmp(pp->name, "unit.", 5) == 0) {
start += 5;
@@ -126,6 +175,10 @@ static int nest_pmu_create(struct device_node *dev, int
pmu_index)
}
}
+ update_events_in_group(
+ (struct ppc64_nest_ima_events *)p8_events_arr,
+ idx, pmu_ptr);
+
return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/7]powerpc/powernv: Data structure and macros definition
Create new header file "nest-pmu.h" to add the data structures
and macros needed for the nest pmu support.
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Anton Blanchard
Cc: Sukadev Bhattiprolu
Cc: Anshuman Khandual
Cc: Stephane Eranian
Signed-off-by: Madhavan Srinivasan
---
arch/powerpc/perf/nest-pmu.h | 53
1 file changed, 53 insertions(+)
create mode 100644 arch/powerpc/perf/nest-pmu.h
diff --git a/arch/powerpc/perf/nest-pmu.h b/arch/powerpc/perf/nest-pmu.h
new file mode 100644
index 000..ebe7689
--- /dev/null
+++ b/arch/powerpc/perf/nest-pmu.h
@@ -0,0 +1,53 @@
+/*
+ * Nest Performance Monitor counter support for POWER8 processors.
+ *
+ * Copyright (C) 2015 Madhavan Srinivasan, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define P8_MAX_CHIP32
+#define MAX_PMU_NAME_LEN 256
+#define MAX_EVENTS_SUPPORTED256
+#define P8_NEST_ENGINE_START 1
+#define P8_NEST_ENGINE_STOP0
+#define P8_MAX_NEST_PMUS 32
+
+/*
+ * Structure to hold per chip specific memory address
+ * information for nest pmus. Nest Counter data are exported
+ * in per-chip reserved memory region by the PORE Engine.
+ */
+struct perchip_nest_info {
+ uint32_t chip_id;
+ uint64_t pbase;
+ uint64_t vbase;
+ uint32_t size;
+};
+
+/*
+ * Place holder for nest pmu events and values.
+ */
+struct ppc64_nest_ima_events {
+ const char *ev_name;
+ const char *ev_value;
+};
+
+/*
+ * Device tree parser code detects nest pmu support and
+ * registers new nest pmus. This structure will
+ * hold the pmu functions and attrs for each nest pmu and
+ * will be referenced at the time of pmu registration.
+ */
+struct nest_pmu {
+ struct pmu pmu;
+ const struct attribute_group *attr_groups[4];
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/7]powerpc/powernv: Nest Instrumentation support
This patchset enables Nest Instrumentation support on powerpc. POWER8 has per-chip Nest Intrumentation which provides various per-chip metrics like memory, powerbus, Xlink and Alink bandwidth. Nest Instrumentation provides an interface (via PORE Engine) to configure and move the nest counter data to memory. From kernel side, OPAL Call interface is used to activate/deactivate PORE Engine for nest data collection. OPAL at boot, detects the feature, initializes it and pass on the nest units and other related information such as memory region, events supported so on, to kernel via device-tree. Kernel code then, parses the device-tree for nest pmu support and registers nest pmu with the events available. PORE Engine collects and accumulate nest counter data in per-chip reserved memory region, hence device-tree also exports per-chip nest accumulation memory region. And individual event offset are used as event configuration values. Here is sample perf usage to explain the interface. #./perf list iTLB-load-misses [Hardware cache event] Nest_Alink_BW/Alink0/ [Kernel PMU event] Nest_Alink_BW/Alink1/ [Kernel PMU event] Nest_Alink_BW/Alink2/ [Kernel PMU event] Nest_MCS_Read_BW/MCS_00/ [Kernel PMU event] Nest_MCS_Read_BW/MCS_01/ [Kernel PMU event] Nest_MCS_Read_BW/MCS_02/ [Kernel PMU event] Nest_MCS_Read_BW/MCS_03/ [Kernel PMU event] Nest_MCS_Write_BW/MCS_00/ [Kernel PMU event] Nest_MCS_Write_BW/MCS_01/ [Kernel PMU event] Nest_MCS_Write_BW/MCS_02/ [Kernel PMU event] Nest_MCS_Write_BW/MCS_03/ [Kernel PMU event] Nest_PowerBus_BW/External/ [Kernel PMU event] Nest_PowerBus_BW/Internal/ [Kernel PMU event] Nest_Xlink_BW/Xlink0/ [Kernel PMU event] Nest_Xlink_BW/Xlink1/ [Kernel PMU event] Nest_Xlink_BW/Xlink2/ [Kernel PMU event] rNNN [Raw hardware event descriptor] cpu/t1=v1[,t2=v2,t3 ...]/modifier [Raw hardware event descriptor] . # ./perf stat -e 'Nest_Xlink_BW/Xlink1/' -a -A sleep 1 Performance counter stats for 'system wide': CPU0 15,913.18 MiB Nest_Xlink_BW/Xlink1/ CPU3211,955.88 MiB Nest_Xlink_BW/Xlink1/ CPU6411,042.43 MiB Nest_Xlink_BW/Xlink1/ CPU9614,065.27 MiB Nest_Xlink_BW/Xlink1/ 1.001062038 seconds time elapsed # ./perf stat -e 'Nest_Alink_BW/Alink0/,Nest_Alink_BW/Alink1/,Nest_Alink_BW/Alink2/' -a -A -I 1000 sleep 5 Performance counter stats for 'system wide': CPU0 0.00 MiB Nest_Alink_BW/Alink0/ (100.00%) CPU32 0.00 MiB Nest_Alink_BW/Alink0/ (100.00%) CPU64 0.00 MiB Nest_Alink_BW/Alink0/ (100.00%) CPU96 0.00 MiB Nest_Alink_BW/Alink0/ (100.00%) CPU0 1,430.43 MiB Nest_Alink_BW/Alink1/ (100.00%) CPU32 320.99 MiB Nest_Alink_BW/Alink1/ (100.00%) CPU64 3,443.83 MiB Nest_Alink_BW/Alink1/ (100.00%) CPU96 1,904.41 MiB Nest_Alink_BW/Alink1/ (100.00%) CPU0 2,856.85 MiB Nest_Alink_BW/Alink2/ CPU32 7.50 MiB Nest_Alink_BW/Alink2/ CPU64 4,034.29 MiB Nest_Alink_BW/Alink2/ CPU96 288.49 MiB Nest_Alink_BW/Alink2/ . OPAL side patches are posted in the skiboot mailing list. Changelog from v1: 1) No logic changes, re-ordered patches make each patch compile without errors 2) Added comments based on the review feedback. 3) removed perf_event_del function and replaced it with perf_event_stop. 4) Moved Nest feature detection code out of parser function. 5) Optimized functions and removed some variables. 6) squashed the makefile changes, instead of the separate patch 7) squashed the cpumask and hotplug patches as single patch 8) Added cpu checks in nest_change_cpu_context and nest_exit_cpu functions 9) Made changes to commit messages. Changelog from RFC: 1) Removed "uncore" code and made each Nest Unit a separate PMU. 2) Removed uncore type abstraction and uncore related functions. 3) Added simple cpumask function since these are per-chip counters 4) Redesigned device-tree parser based on the latest platform enablement code 5) Made changes to commit message Thanks to intput from Daniel
Re: [PATCH] RDMA/ocrdma: fix double free on pd
On Fri, 2015-06-05 at 15:47 +0100, Colin King wrote:
> From: Colin Ian King
>
> A reorganisation of the PD allocation and deallocation in commit
> 9ba1377daa ("RDMA/ocrdma: Move PD resource management to driver.")
> introduced a double free on pd, as detected by static analysis by
> smatch:
>
> drivers/infiniband/hw/ocrdma/ocrdma_verbs.c:682 ocrdma_alloc_pd()
> error: double free of 'pd'^
>
> The original call to ocrdma_mbx_dealloc_pd() (which does not kfree
> pd) was replaced with a call to _ocrdma_dealloc_pd() (which does
> kfree pd). The kfree following this call causes the double free,
> so just remove it to fix the problem.
>
> Fixes: 9ba1377daa ("RDMA/ocrdma: Move PD resource management to driver.")
> Signed-off-by: Colin Ian King
> ---
> drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> index 9dcb660..219f212 100644
> --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> @@ -679,7 +679,6 @@ err:
> ocrdma_release_ucontext_pd(uctx);
> } else {
> status = _ocrdma_dealloc_pd(dev, pd);
> - kfree(pd);
> }
> exit:
> return ERR_PTR(status);
Thanks, applied.
--
Doug Ledford
GPG KeyID: 0E572FDD
signature.asc
Description: This is a digitally signed message part
Re: [PATCH v4 5/7] Watchdog: introduce ARM SBSA watchdog driver
On 06/10/2015 08:45 PM, Timur Tabi wrote: Fu Wei wrote: Could you suggest a good way to use WS0, so we can follow SBSA spec? To avoid the timeout/2 problem, WS0 calls panic, which is the "real" timeout/reset. WS1 is then a "backup" that is ignored by the driver. That is, the driver doesn't do anything with WS1 and it doesn't tell the kernel about WS1. I know you don't like the idea of WS1 as a backup timeout, but this is one way to solve the problem. This is what I would do. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1 linux-next] ath5k: use swap() in ath5k_hw_get_median_noise_floor()
> On 10 June 2015 at 22:29 Julia Lawall wrote:
>
>
>
>
> On Wed, 10 Jun 2015, Fabian Frederick wrote:
>
> >
> >
> > > On 10 June 2015 at 21:52 Joe Perches wrote:
> > >
> > >
> > > On Wed, 2015-06-10 at 18:33 +0200, Fabian Frederick wrote:
> > > > Use kernel.h macro definition.
> > > >
> > > > Thanks to Julia Lawall for Coccinelle scripting support.
> > > []
> > > > diff --git a/drivers/net/wireless/ath/ath5k/phy.c
> > > > b/drivers/net/wireless/ath/ath5k/phy.c
> > > []
> > > > @@ -1566,17 +1566,13 @@ static s16
> > > > ath5k_hw_get_median_noise_floor(struct ath5k_hw *ah)
> > > > {
> > > > s16 sort[ATH5K_NF_CAL_HIST_MAX];
> > > > - s16 tmp;
> > > > int i, j;
> > > >
> > > > memcpy(sort, ah->ah_nfcal_hist.nfval, sizeof(sort));
> > > > for (i = 0; i < ATH5K_NF_CAL_HIST_MAX - 1; i++) {
> > > > for (j = 1; j < ATH5K_NF_CAL_HIST_MAX - i; j++) {
> > > > - if (sort[j] > sort[j - 1]) {
> > > > - tmp = sort[j];
> > > > - sort[j] = sort[j - 1];
> > > > - sort[j - 1] = tmp;
> > > > - }
> > > > + if (sort[j] > sort[j - 1])
> > > > + swap(sort[j], sort[j]);
> > >
> > > swap(a, a) doesn't look useful.
> > Thanks a lot Joe, I'll fix this one :)
>
> How did it come out like that?
>
> julia
I used script for detection only and made updates manually.
I guess I was distracted by [j - 1] on line above.
It was based on linux-next; if maintainers prefer another branch, I'll
send the right version on top of it.
Regards,
Fabian
>
> >
> > Regards,
> > Fabian
> > >
> > >
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Audio crackles with 4.1-rc1
At Thu, 11 Jun 2015 01:12:36 +0300, Mihai Donțu wrote: > > On Wed, 10 Jun 2015 20:23:01 +0200 Takashi Iwai wrote: > > From: Takashi Iwai > > Subject: [PATCH] ALSA: hda - Reduce click noise at power up > > > > Some machines suffer from click noises at power up with the recent > > kernels, and this seems triggered at the power transition and the > > immediate verb executions. As a workaround, put a short delay (10ms) > > right after the D0 transition. > > > > There are a few places that have the same kind of delays, especially > > in the resume path. I guess they can be removed (or reduced) after > > this patch. But, since the delay is relatively small, let's do it > > later as a cleanup. > > > > Reported-by: Mihai Donțu > > Signed-off-by: Takashi Iwai > > --- > > sound/pci/hda/hda_codec.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c > > index b7782212dd64..38f5509ee52f 100644 > > --- a/sound/pci/hda/hda_codec.c > > +++ b/sound/pci/hda/hda_codec.c > > @@ -3077,6 +3077,9 @@ static unsigned int hda_set_power_state(struct > > hda_codec *codec, > > break; > > } > > > > + if (power_state == AC_PWRST_D0) > > + msleep(10); > > + > > return state; > > } > > > > I take back my previous observations. I was at work and did not have > access to headphones (one of those days). Now I'm at home, it's 1 AM, > very quiet, and I notice the following: > > * on speakers: the click reproduces but with _very_ low amplitude; >msleep(100) is unnoticeable, but msleep(10) is, barely; > * on headphones: the moment I plug them I hear a loud static sound >(like an old, untuned AM radio). If I play something, the static >disappears. If I pause, the static returns after ~15s. OK, then the patch is no-go. We need a bit deeper analysis. About the headphone problem: don't you get the same issue with 4.0.x? Please take alsa-info.sh outputs on both 4.0.x and 4.1 before and after plugging the headphone, and attach the outputs. (Run the script with --no-upload option.) thanks, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] bna: remove obsolete use of EXTRA_CFLAGS
From: Jiri Slaby Date: Tue, 9 Jun 2015 14:24:43 +0200 > EXTRA_CFLAGS should be used on the command line only. > > Since EXTRA_CFLAGS here add only a non-existant path to compiler > include paths (by -I), remove EXTRA_CFLAGS completely. > > Signed-off-by: Jiri Slaby Applied to net-next, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/3] Dell Airplane Mode Switch driver
On Mon, Jun 08, 2015 at 09:30:36AM +0200, Pali Rohár wrote: > On Sunday 07 June 2015 21:12:38 Darren Hart wrote: > > On Sat, Jun 06, 2015 at 10:23:27AM +0200, Pali Rohár wrote: > > > This patch series add new acpi Dell Airplane Mode Switch driver (DELLABCE > > > and > > > DELRBTN acpi devices). It provides radio HW switch events (together with > > > current > > > state of radio devices) and export them via rfkill interface. These > > > events are > > > also used in dell-laptop driver instead i8042 filter hook function (when > > > acpi > > > device is available). > > > > > > In v2 was added support for laptops which have toggle button instead HW > > > slider > > > switch. For that I reused code done by Alex Hung. > > > > > > v3 is just cleanup. > > > > > > In v4 was fixed dependency problems. > > > > Please be more specific in the future. You want people that haven't looked > > at > > this for a couple of weeks to be able to quickly identify what changed and > > confirm they agree. You want people to review your code, you want to reduce > > the > > barrier to do so. Easy to do while it's fresh in your mind. > > > > Thanks for the update, I have these qeueud to testing. > > > > I wrote more details into individual patches above diffstat lines. But > if you want detailed description also to cover letter email, I can do > that in the future... The individual patches is better. It's typical to leave the entire changelog after the ---, and not just the current version. I found what I was actually looking for was in the v4 changelog. It's not a huge deal, but if the goal is to get people (and not just me) to review the code, we want to make it as easy for them as possible to get the necessary context to start reviewing. No doubt certain maintainer may feel differently. -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arch/ia64: Use setup_timer
Use the timer API function setup_timer instead of structure field
assignments to initialize a timer.
A simplified version of the Coccinelle semantic patch that performs
this transformation is as follows:
@change@
expression e1, e2, a;
@@
-init_timer();
+setup_timer(, a, 0UL);
... when != a = e2
-e1.function = a;
Signed-off-by: Vaishali Thakkar
---
arch/ia64/kernel/mca.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/ia64/kernel/mca.c b/arch/ia64/kernel/mca.c
index dd5801e..2889412 100644
--- a/arch/ia64/kernel/mca.c
+++ b/arch/ia64/kernel/mca.c
@@ -2117,8 +2117,7 @@ ia64_mca_late_init(void)
register_hotcpu_notifier(_cpu_notifier);
/* Setup the CMCI/P vector and handler */
- init_timer(_poll_timer);
- cmc_poll_timer.function = ia64_mca_cmc_poll;
+ setup_timer(_poll_timer, ia64_mca_cmc_poll, 0UL);
/* Unmask/enable the vector */
cmc_polling_enabled = 0;
@@ -2129,8 +2128,7 @@ ia64_mca_late_init(void)
#ifdef CONFIG_ACPI
/* Setup the CPEI/P vector and handler */
cpe_vector = acpi_request_vector(ACPI_INTERRUPT_CPEI);
- init_timer(_poll_timer);
- cpe_poll_timer.function = ia64_mca_cpe_poll;
+ setup_timer(_poll_timer, ia64_mca_cpe_poll, 0UL);
{
unsigned int irq;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH kernel v12.2] powerpc/powernv: Fix crash when CONFIG_IOMMU_API is off
The code introduced in
"[PATCH kernel v12 17/34]
powerpc/spapr: vfio: Switch from iommu_table to new iommu_table_group"
checks if an IOMMU group was registered for the specific
table group which is not true when CONFIG_IOMMU_API is off as
iommu_register_group() is a stub in this case.
This replaces BUG_ON with WARN_ON and removes the check as it is a wrong
place for it anyway.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/platforms/powernv/pci.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci.c
b/arch/powerpc/platforms/powernv/pci.c
index 4b4c583..429498e 100644
--- a/arch/powerpc/platforms/powernv/pci.c
+++ b/arch/powerpc/platforms/powernv/pci.c
@@ -622,9 +622,8 @@ long pnv_pci_link_table_and_group(int node, int num,
{
struct iommu_table_group_link *tgl = NULL;
- BUG_ON(!tbl);
- BUG_ON(!table_group);
- BUG_ON(!table_group->group);
+ if (WARN_ON(!tbl || !table_group))
+ return -EINVAL;
tgl = kzalloc_node(sizeof(struct iommu_table_group_link), GFP_KERNEL,
node);
--
2.4.0.rc3.8.gfb3e7d5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 09/18] kthread: Make it easier to correctly sleep in iterant kthreads
On Wed, 10 Jun 2015, Steven Rostedt wrote: > > Right, and I had not considered that, but it turns out the hung_task > > detector checks p->state == TASK_UNINTERRUPTIBLE, so TASK_IDLE is indeed > > safe from that. > > Also, I would assume that TASK_IDLE only makes sense for kernel > threads, I wonder if we should add an assertion in schedule that > triggers if a task is scheduling with TASK_IDLE and is not a kernel > thread (has its own mm?) For the sake of completnes -- testing for !task_struct->mm is not a correct test to find out whether given entity is a kernel thread; kernel threads are free to temporarily adopt user struct mm via use_mm() (usually for handling AIO on behalf of a particular struct mm). The correct check is to look at PF_KTHREAD flag in task_struct->flags. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] inherited events not signalling parent on overflow
On Fri, 29 May 2015, Ingo Molnar wrote: > * Vince Weaver wrote: > > If we inherit events, we inherit the signal state but not the fasync state, > > so > > overflows in inherited children will never trigger the signal handler. > > > > Signed-off-by: Vince Weaver > > > > diff --git a/kernel/events/core.c b/kernel/events/core.c > > index 1a3bf48..7df4cf5 100644 > > --- a/kernel/events/core.c > > +++ b/kernel/events/core.c > > @@ -8626,6 +8630,8 @@ inherit_event(struct perf_event *parent_event, > > child_event->overflow_handler_context > > = parent_event->overflow_handler_context; > > > > + child_event->fasync = parent_event->fasync; > > + > > /* > > * Precalculate sample_data sizes > > */ This patch, while it does work well enough to enable self-monitored-sampling of OpenMP programs, falls apart under fuzzing. You end up with lots of [25592.289382] kill_fasync: bad magic number in fasync_struct! warnings and eventually I managed to lock up the system that way. > Btw., if we do this (sensible looking) ABI fix, could we make it a new attr > bit, > so that PAPI can essentially query the kernel whether this gets propagated > properly? > > That way old kernels 'intentionally' don't inherit the fasync handler and > tooling > can deterministically make use of this 'feature' on new kernels. That would be useful. PAPI typically has to guess about feature support (for workarounds) by using the kernel version number as a reference, and this falls apart on kernels such as RHEL which backport a lot of perf_event fixes/functionality. Vince -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 01/10] x86/asm: Add FP_SAVE/RESTORE frame pointer macros
On Wed, 10 Jun 2015, Pavel Machek wrote: > > diff --git a/arch/x86/include/asm/func.h b/arch/x86/include/asm/func.h > > new file mode 100644 > > index 000..4d62782 > > --- /dev/null > > +++ b/arch/x86/include/asm/func.h > > @@ -0,0 +1,24 @@ > > +#ifndef _ASM_X86_FUNC_H > > +#define _ASM_X86_FUNC_H > > + > > +#include > > +#include > > + > > +/* > > + * These are frame pointer save and restore macros. They should be used by > > + * every callable non-leaf asm function. > > + */ > > +.macro FP_SAVE name > > + .if CONFIG_FRAME_POINTER > > + push %_ASM_BP > > + _ASM_MOV %_ASM_SP, %_ASM_BP > > + .endif > > +.endm > > Hmm. This will not compile when included into .c file. Should it have > other extension than .h? (Or can the macros be done in different way? We have quite a few of .h headers in the kernel already which are supposed to be included only by .S files, so what exactly is the problem you are seeing here? -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arm64: fix bug for reloading FPSIMD state after CPU hotplug.
From: Janet Liu
Now FPSIMD don't handle HOTPLUG_CPU. This introduces bug after cpu down/up
process.
After cpu down/up process, the FPSMID hardware register is default value, not
any
process's fpsimd context. when CPU_DEAD set cpu's fpsimd_state to NULL, it will
force
to load the fpsimd context for the thread, to avoid the chance to skip to load
the context.
If process A is the last user process on CPU N before cpu down, and the first
user process
on the same CPU N after cpu up, A's fpsimd_state.cpu is the current cpu id,
and per_cpu(fpsimd_last_state) points A's fpsimd_state, so kernel will not
reload the
context during it return to user space.
Signed-off-by: Janet Liu
Signed-off-by: Xiongshan An
Signed-off-by: Chunyan Zhang
---
arch/arm64/kernel/fpsimd.c | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 3dca156..35ef3a2 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -296,6 +297,36 @@ static void fpsimd_pm_init(void)
static inline void fpsimd_pm_init(void) { }
#endif /* CONFIG_CPU_PM */
+#ifdef CONFIG_HOTPLUG_CPU
+static int fpsimd_cpu_hotplug_notifier(struct notifier_block *nfb,
+ unsigned long action,
+ void *hcpu)
+{
+ int cpu = (long)hcpu;
+
+ switch (action & ~CPU_TASKS_FROZEN) {
+ case CPU_DEAD:
+ per_cpu(fpsimd_last_state, cpu) = NULL;
+ break;
+ default:
+ break;
+ }
+ return NOTIFY_OK;
+}
+
+static struct notifier_block fpsimd_cpu_hotplug_notifier_block = {
+ .notifier_call = fpsimd_cpu_hotplug_notifier,
+};
+
+static inline void fpsimd_hotplug_init(void)
+{
+ register_cpu_notifier(_cpu_hotplug_notifier_block);
+}
+
+#else
+static inline void fpsimd_hotplug_init(void) { }
+#endif
+
/*
* FP/SIMD support code initialisation.
*/
@@ -315,6 +346,7 @@ static int __init fpsimd_init(void)
elf_hwcap |= HWCAP_ASIMD;
fpsimd_pm_init();
+ fpsimd_hotplug_init();
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arm64: kernel thread don't need to save fpsimd context.
From: Janet Liu
kernel thread's default fpsimd state is zero. When fork a thread, if parent is
kernel thread,
and save hardware context to parent's fpsimd state, but this hardware context
is user
process's context, because kernel thread don't use fpsimd, it will not
introduce issue,
it add a little cost.
Signed-off-by: Janet Liu
Signed-off-by: Chunyan Zhang
---
arch/arm64/kernel/process.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index c6b1f3b..2a46732 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -243,7 +243,8 @@ void release_thread(struct task_struct *dead_task)
int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src)
{
- fpsimd_preserve_current_state();
+ if (current->mm)
+ fpsimd_preserve_current_state();
*dst = *src;
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -stable] block: fix ext_dev_lock lockdep report
=
[ INFO: inconsistent lock state ]
4.1.0-rc7+ #217 Tainted: G O
-
inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
swapper/6/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
(ext_devt_lock){+.?...}, at: [] blk_free_devt+0x3c/0x70
{SOFTIRQ-ON-W} state was registered at:
[] __lock_acquire+0x461/0x1e70
[] lock_acquire+0xb7/0x290
[] _raw_spin_lock+0x38/0x50
[] blk_alloc_devt+0x6d/0xd0 <-- take the lock in process
context
[..]
[] __lock_acquire+0x3fe/0x1e70
[] ? __lock_acquire+0xe5d/0x1e70
[] lock_acquire+0xb7/0x290
[] ? blk_free_devt+0x3c/0x70
[] _raw_spin_lock+0x38/0x50
[] ? blk_free_devt+0x3c/0x70
[] blk_free_devt+0x3c/0x70<-- take the lock in softirq
[] part_release+0x1c/0x50
[] device_release+0x36/0xb0
[] kobject_cleanup+0x7b/0x1a0
[] kobject_put+0x30/0x70
[] put_device+0x17/0x20
[] delete_partition_rcu_cb+0x16c/0x180
[] ? read_dev_sector+0xa0/0xa0
[] rcu_process_callbacks+0x2ff/0xa90
[] ? rcu_process_callbacks+0x2bf/0xa90
[] __do_softirq+0xde/0x600
Neil sees this in his tests and it also triggers on pmem driver unbind
for the libnvdimm tests. This fix is on top of an initial fix by Keith
for incorrect usage of mutex_lock() in this path: 2da78092dda1 "block:
Fix dev_t minor allocation lifetime". Both this and 2da78092dda1 are
candidates for -stable.
Fixes: 2da78092dda1 ("block: Fix dev_t minor allocation lifetime")
Cc:
Cc: Keith Busch
Reported-by: NeilBrown
Signed-off-by: Dan Williams
---
Note that 2da78092dda1 had "Cc: sta...@kernel.org" instead of @vger.kernel.org.
block/genhd.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/block/genhd.c b/block/genhd.c
index 666e11b83983..ea982eadaf63 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -422,9 +422,9 @@ int blk_alloc_devt(struct hd_struct *part, dev_t *devt)
/* allocate ext devt */
idr_preload(GFP_KERNEL);
- spin_lock(_devt_lock);
+ spin_lock_bh(_devt_lock);
idx = idr_alloc(_devt_idr, part, 0, NR_EXT_DEVT, GFP_NOWAIT);
- spin_unlock(_devt_lock);
+ spin_unlock_bh(_devt_lock);
idr_preload_end();
if (idx < 0)
@@ -449,9 +449,9 @@ void blk_free_devt(dev_t devt)
return;
if (MAJOR(devt) == BLOCK_EXT_MAJOR) {
- spin_lock(_devt_lock);
+ spin_lock_bh(_devt_lock);
idr_remove(_devt_idr, blk_mangle_minor(MINOR(devt)));
- spin_unlock(_devt_lock);
+ spin_unlock_bh(_devt_lock);
}
}
@@ -690,13 +690,13 @@ struct gendisk *get_gendisk(dev_t devt, int *partno)
} else {
struct hd_struct *part;
- spin_lock(_devt_lock);
+ spin_lock_bh(_devt_lock);
part = idr_find(_devt_idr, blk_mangle_minor(MINOR(devt)));
if (part && get_disk(part_to_disk(part))) {
*partno = part->partno;
disk = part_to_disk(part);
}
- spin_unlock(_devt_lock);
+ spin_unlock_bh(_devt_lock);
}
return disk;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 5/7] Watchdog: introduce ARM SBSA watchdog driver
Fu Wei wrote: Could you suggest a good way to use WS0, so we can follow SBSA spec? To avoid the timeout/2 problem, WS0 calls panic, which is the "real" timeout/reset. WS1 is then a "backup" that is ignored by the driver. That is, the driver doesn't do anything with WS1 and it doesn't tell the kernel about WS1. I know you don't like the idea of WS1 as a backup timeout, but this is one way to solve the problem. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the block tree with the powerpc-mpe tree
Hi Jens,
Today's linux-next merge of the block tree got a conflict in
MAINTAINERS between commit a14ab6b6e0ad ("powerpc/cell: Drop
cbe-oss-dev mailing list from MAINTAINERS") from the powerpc-mpe tree
and commit 3715a5d014e1 ("MAINTAINERS: Update ps3vram block driver")
from the block tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc MAINTAINERS
index b09702c197ca,b327ac39e951..
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@@ -8018,7 -7853,9 +8019,8 @@@ F: sound/ppc/snd_ps3
PS3VRAM DRIVER
M:Jim Paris
+ M:Geoff Levand
L:linuxppc-...@lists.ozlabs.org
-L:cbe-oss-...@lists.ozlabs.org
S:Maintained
F:drivers/block/ps3vram.c
pgp3beDQjrbOd.pgp
Description: OpenPGP digital signature
Re: [PATCH v7 00/10] tracing: 'hist' triggers
Hi Tom,
I tried to play with this patchset, and it worked greatly. Thanks for
your work!
But I found that it doesn't handle string fields properly so I can see
failure on accessing 'filename' field in sched_process_exec event.
Below is my fix for that.. Can you take a look at it?
Thanks,
Namhyung
>From e0442e9aec9740e4f20931ff10545f07c8d6d346 Mon Sep 17 00:00:00 2001
From: Namhyung Kim
Date: Thu, 11 Jun 2015 11:48:41 +0900
Subject: [PATCH] tracing: Support string type key properly
The string in a trace event is usually recorded as dynamic array which
is variable length. But current hist code only support fixed length
array so it cannot support most strings.
This patch fixes it by checking filter_type of the field and get
proper pointer with it. With this, it can get a histogram of exec()
based on filenames like below:
# cd /sys/kernel/tracing/events/sched/sched_process_exec
# cat 'hist:key=filename' > trigger
# ps
PID TTY TIME CMD
1 ? 00:00:00 init
29 ? 00:00:00 sh
38 ? 00:00:00 ps
# ls
enable filter format hist id trigger
# cat hist
# trigger info: hist:keys=filename:vals=hitcount:sort=hitcount:size=2048
[active]
{ filename: /usr/bin/ps } hitcount: 1
{ filename: /usr/bin/ls } hitcount: 1
{ filename: /usr/bin/cat} hitcount: 1
Totals:
Hits: 3
Entries: 3
Dropped: 0
Cc: Tom Zanussi
Cc: Masami Hiramatsu
Signed-off-by: Namhyung Kim
---
kernel/trace/trace_events_hist.c | 47 +---
1 file changed, 44 insertions(+), 3 deletions(-)
diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
index 5ea18956497d..d5edf9fa5aea 100644
--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c
@@ -52,6 +52,22 @@ static u64 hist_field_string(struct hist_field *hist_field,
void *event)
return (u64)addr;
}
+static u64 hist_field_dynstring(struct hist_field *hist_field, void *event)
+{
+ u32 str_item = *(u32 *)(event + hist_field->field->offset);
+ int str_loc = str_item & 0x;
+ char *addr = (char *)(event + str_loc);
+
+ return (u64)addr;
+}
+
+static u64 hist_field_pstring(struct hist_field *hist_field, void *event)
+{
+ char **addr = (char **)(event + hist_field->field->offset);
+
+ return (u64)*addr;
+}
+
#define DEFINE_HIST_FIELD_FN(type) \
static u64 hist_field_##type(struct hist_field *hist_field, void *event)\
{ \
@@ -330,7 +346,13 @@ static struct hist_field *create_hist_field(struct
ftrace_event_field *field,
if (is_string_field(field)) {
flags |= HIST_FIELD_STRING;
- hist_field->fn = hist_field_string;
+
+ if (field->filter_type == FILTER_STATIC_STRING)
+ hist_field->fn = hist_field_string;
+ else if (field->filter_type == FILTER_DYN_STRING)
+ hist_field->fn = hist_field_dynstring;
+ else
+ hist_field->fn = hist_field_pstring;
} else {
hist_field->fn = select_value_fn(field->size,
field->is_signed);
@@ -485,7 +507,10 @@ static int create_key_field(struct hist_trigger_data
*hist_data,
goto out;
}
- key_size = field->size;
+ if (is_string_field(field)) /* should be last key field */
+ key_size = HIST_KEY_SIZE_MAX - key_offset;
+ else
+ key_size = field->size;
}
hist_data->fields[key_idx] = create_hist_field(field, flags);
@@ -791,8 +816,24 @@ static void event_hist_trigger(struct event_trigger_data
*data, void *rec)
key = (void *)_contents;
if (hist_data->n_keys > 1) {
+ /* ensure NULL-termination */
+ size_t size = key_field->size - 1;
+
+ if (key_field->flags & HIST_FIELD_STRING) {
+ struct ftrace_event_field *field;
+
+ field = key_field->field;
+ if (field->filter_type ==
FILTER_DYN_STRING)
+ size = *(u32 *)(rec +
field->offset) >> 16;
+ else if (field->filter_type ==
FILTER_PTR_STRING)
+ size = strlen(key);
+
+ if (size > key_field->size - 1)
+ size = key_field->size - 1;
+ }
+
Re: [PATCH v4 5/7] Watchdog: introduce ARM SBSA watchdog driver
On 11 June 2015 at 08:22, Timur Tabi wrote: > Fu Wei wrote: >> >> If we make the first stage timeout is timeout/2, this violates the >> definition of timeout. > > > The documentation says that the hardware needs to reset after the timeout > expires. yes , you are absolutely on this. Great thanks for point out this. my patch is doing this way: trigger WS1 at the timeout expires Before that, using pretimeout for WS0 as an warning. > If you program the hardware to timeout/2, the driver can ignore > WS0 and allow WS1 to reset the hardware. That conforms to the > documentation. yes, technically we can do nothing in WS0, and just wait for WS1. So SBSA watchdog become a one stage timeout watchdog, right? So if user want the WS0 warning, How to make driver know that, and do something in WS0 routine? I think by this way, two stage timeouts, WS0 "alert" will be meaningless. Could you suggest a good way to use WS0, so we can follow SBSA spec? > > -- > Sent by an employee of the Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of the > Code Aurora Forum, hosted by The Linux Foundation. -- Best regards, Fu Wei Software Engineer Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch Ph: +86 21 61221326(direct) Ph: +86 186 2020 4684 (mobile) Room 1512, Regus One Corporate Avenue,Level 15, One Corporate Avenue,222 Hubin Road,Huangpu District, Shanghai,China 200021 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] serial: sprd: check for NULL after calling devm_clk_get
From: Fernando Guzman Lugo In platforms which does not use CLK framework (HAVE_CLK not set), the clk_* functions return NULL instead of an error. This patch handles that scenario. Signed-off-by: Fernando Guzman Lugo Signed-off-by: Chunyan Zhang --- drivers/tty/serial/sprd_serial.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/sprd_serial.c b/drivers/tty/serial/sprd_serial.c index 582d272..3866516 100644 --- a/drivers/tty/serial/sprd_serial.c +++ b/drivers/tty/serial/sprd_serial.c @@ -716,7 +716,7 @@ static int sprd_probe(struct platform_device *pdev) up->flags = UPF_BOOT_AUTOCONF; clk = devm_clk_get(>dev, NULL); - if (!IS_ERR(clk)) + if (!IS_ERR_OR_NULL(clk)) up->uartclk = clk_get_rate(clk); res = platform_get_resource(pdev, IORESOURCE_MEM, 0); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Cluster-devel] [PATCH] dlm: remove unnecessary error check
Bob Peterson wrote:
>
> - Original Message -
>
>
>
>> We don't need the redundant logic since send_message always returns 0.
>>
>> Signed-off-by: Guoqing Jiang
>> ---
>> fs/dlm/lock.c | 10 ++
>> 1 file changed, 2 insertions(+), 8 deletions(-)
>>
>> diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c
>> index 35502d4..6fc3de9 100644
>> --- a/fs/dlm/lock.c
>> +++ b/fs/dlm/lock.c
>> @@ -3656,10 +3656,7 @@ static int send_common(struct dlm_rsb *r, struct
>> dlm_lkb *lkb, int mstype)
>>
>> send_args(r, lkb, ms);
>>
>> -error = send_message(mh, ms);
>> -if (error)
>> -goto fail;
>> -return 0;
>> +return send_message(mh, ms);
>>
>
> Hi Guoqing,
>
> Sorry, I was momentarily confused. I think you misunderstood what I was
> saying.
> What I meant was: Instead of doing:
>
> + return send_message(mh, ms);
> ...where send_message returns 0, it might be better to have:
>
> static void send_message(struct dlm_mhandle *mh, struct dlm_message *ms)
> {
> dlm_message_out(ms);
> dlm_lowcomms_commit_buffer(mh);
> }
>
> ...And in send_common, do (in both places):
> + send_message(mh, ms);
> + return 0;
>
> Since it's so short, it might even be better to code send_message as a macro,
> or at least an "inline" function.
>
>
Hi Bob,
Got it, thanks. It is a better solution but it is not a bug fix or
similar thing, so maybe just leave it as it is.
Regards,
Guoqing
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.18 000/178] 3.18.15-review
On 06/09/2015 01:17 PM, Kevin Hilman wrote: > Hi Sasha, > > On Mon, Jun 8, 2015 at 6:39 AM, Sasha Levin wrote: >> This is the start of the stable review cycle for the 3.18.15 release. >> There are 178 patches in this series, all will be posted as a response >> to this one. If anyone has any issues with these being applied, please >> let me know. > > We've started build/boot testing your 3.18 stable queue with the > automated build/boot tools at the kernelci.org project. We'll soon be > sending automated reports to this list for your stable queue (and > other stable trees.) Until we have the email reports automated, below > is the report for this review series which has a whole pile of build > failures across x86, arm and arm64. > > Kevin Thanks for the report(s)! I've fixed the issues and re-pushed. Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: futex_wait() can DoS the tick
On Wed, 2015-06-10 at 20:59 +0200, Thomas Gleixner wrote: > On Wed, 10 Jun 2015, Mike Galbraith wrote: > > > On Wed, 2015-06-10 at 17:12 +0200, Thomas Gleixner wrote: > > > > > Some more information about your symptoms in form of configuration, > > > extra patches, kernel traces etc. would be appreciated. > > > > homer:~/tmp # perf record -C 3 -eirq:*,irq_vectors:local* -- sleep 10 > > [ perf record: Woken up 2 times to write data ] > > [ perf record: Captured and wrote 1380.507 MB perf.data (19530595 samples) ] > > homer:~/tmp # perf script | grep irq_vectors:local_timer > > ksoftirqd/319 [003] 5586.564238: irq_vectors:local_timer_entry: > > vector=239 > > ksoftirqd/319 [003] 5586.564239: irq_vectors:local_timer_exit: > > vector=239 > > ksoftirqd/319 [003] 5586.568238: irq_vectors:local_timer_entry: > > vector=239 > > ksoftirqd/319 [003] 5586.568239: irq_vectors:local_timer_exit: > > vector=239 > > ksoftirqd/319 [003] 5586.632218: irq_vectors:local_timer_entry: > > vector=239 > > That gap is odd. Can you fire up the function tracer please? Well, trying to do that like so... trace-cmd record -M 8 -p function -e irq:* -e irq_vectors:local* -e timer:hrtimer* -- sleep 1 ..capture takes much more than a second... LOC: 248161 226536 42091 38892 Local timer interrupts LOC: 248381 226783 42092 38901 Local timer interrupts LOC: 248668 227038 42092 38903 Local timer interrupts LOC: 248963 227277 42092 38904 Local timer interrupts LOC: 249214 227515 42092 38905 Local timer interrupts LOC: 249486 227732 42092 38905 Local timer interrupts LOC: 249720 227961 42092 38905 Local timer interrupts LOC: 249996 228200 42092 38906 Local timer interrupts LOC: 250215 228450 42092 38906 Local timer interrupts LOC: 250489 228704 42092 38906 Local timer interrupts LOC: 250729 228952 42099 38964 Local timer interrupts LOC: 250951 229141 42100 39215 Local timer interrupts LOC: 251168 229374 42119 39468 Local timer interrupts LOC: 251426 229641 42131 39719 Local timer interrupts LOC: 251652 229868 42131 39970 Local timer interrupts LOC: 251881 230141 42132 40220 Local timer interrupts LOC: 252131 230371 42132 40471 Local timer interrupts LOC: 252361 230646 42133 40721 Local timer interrupts LOC: 252611 230875 42133 40972 Local timer interrupts LOC: 252866 231149 42137 41222 Local timer interrupts LOC: 253103 231386 42153 41450 Local timer interrupts ...but more importantly, when it gets cranked up.. homer:~/tmp # trace-cmd report > report homer:~/tmp # grep local_timer_entry report|wc -l 252 ...it scares the problem away. (4 cpus because I fired up cpuset shield, isolates 2-3, takes 4-7 down) -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1] usb: dwc2: gadget: fix a memory use-after-free bug
On 5/28/2015 10:22 PM, Yunzhi Li wrote: > When s3c_hsotg_handle_unaligned_buf_complete() hs_req->req.buf > already destroyed, in s3c_hsotg_unmap_dma(), it touches > hs_req->req.dma again, so s3c_hsotg_unmap_dma() should be called > before s3c_hsotg_handle_unaligned_buf_complete(). Otherwise, it > will cause a bad_page BUG, when allocate this memory page next > time. > > This bug led to the following crash: > > BUG: Bad page state in process swapper/0 pfn:2bdbc > [ 26.820440] page:eed76780 count:0 mapcount:0 mapping: (null) index:0x0 > [ 26.854710] page flags: 0x200(arch_1) > [ 26.885836] page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set > [ 26.919179] bad because of flags: > [ 26.948917] page flags: 0x200(arch_1) > [ 26.979100] Modules linked in: > [ 27.008401] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W3.14.0 #17 > [ 27.041816] [] (unwind_backtrace) from [] > (show_stack+0x20/0x24) > [ 27.076108] [] (show_stack) from [] > (dump_stack+0x70/0x8c) > [ 27.110246] [] (dump_stack) from [] > (bad_page+0xfc/0x12c) > [ 27.143958] [] (bad_page) from [] > (get_page_from_freelist+0x3e4/0x50c) > [ 27.179298] [] (get_page_from_freelist) from [] > (__alloc_pages_nodemask) > [ 27.216296] [] (__alloc_pages_nodemask) from [] > (__get_free_pages+0x20/) > [ 27.252326] [] (__get_free_pages) from [] > (kmalloc_order_trace+0x34/0xa) > [ 27.288295] [] (kmalloc_order_trace) from [] > (__kmalloc+0x40/0x1ac) > [ 27.323751] [] (__kmalloc) from [] > (s3c_hsotg_ep_queue.isra.12+0x7c/0x1) > [ 27.359937] [] (s3c_hsotg_ep_queue.isra.12) from [] > (s3c_hsotg_ep_queue) > [ 27.397478] [] (s3c_hsotg_ep_queue_lock) from [] > (rx_submit+0xfc/0x164) > [ 27.433619] [] (rx_submit) from [] > (rx_complete+0x22c/0x230) > [ 27.468872] [] (rx_complete) from [] > (s3c_hsotg_complete_request+0xfc/0) > [ 27.506240] [] (s3c_hsotg_complete_request) from [] > (s3c_hsotg_handle_o) > [ 27.545401] [] (s3c_hsotg_handle_outdone) from [] > (s3c_hsotg_epint+0x2c) > [ 27.583689] [] (s3c_hsotg_epint) from [] > (s3c_hsotg_irq+0x1dc/0x4ac) > [ 27.621041] [] (s3c_hsotg_irq) from [] > (handle_irq_event_percpu+0x70/0x) > [ 27.659066] [] (handle_irq_event_percpu) from [] > (handle_irq_event+0x4c) > [ 27.697322] [] (handle_irq_event) from [] > (handle_fasteoi_irq+0xc8/0x11) > [ 27.735451] [] (handle_fasteoi_irq) from [] > (generic_handle_irq+0x30/0x) > [ 27.773918] [] (generic_handle_irq) from [] > (__handle_domain_irq+0x84/0) > [ 27.812018] [] (__handle_domain_irq) from [] > (gic_handle_irq+0x48/0x6c) > [ 27.849695] [] (gic_handle_irq) from [] > (__irq_svc+0x40/0x50) > [ 27.886907] Exception stack(0xc0d01ee0 to 0xc0d01f28) > > Signed-off-by: Yunzhi Li > > --- > > drivers/usb/dwc2/gadget.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c > index 6a30887..8070602 100644 > --- a/drivers/usb/dwc2/gadget.c > +++ b/drivers/usb/dwc2/gadget.c > @@ -1389,14 +1389,14 @@ static void s3c_hsotg_complete_request(struct > dwc2_hsotg *hsotg, > if (hs_req->req.status == -EINPROGRESS) > hs_req->req.status = result; > > + if (using_dma(hsotg)) > + s3c_hsotg_unmap_dma(hsotg, hs_ep, hs_req); > + > s3c_hsotg_handle_unaligned_buf_complete(hsotg, hs_ep, hs_req); > > hs_ep->req = NULL; > list_del_init(_req->queue); > > - if (using_dma(hsotg)) > - s3c_hsotg_unmap_dma(hsotg, hs_ep, hs_req); > - > /* >* call the complete request with the locks off, just in case the >* request tries to queue more work for this endpoint. > Acked-by: John Youn John -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] The same content in the comment appear twice.
From: gongzhaogang Delect the extra content in the comment. return_object - Where to put method's return value (if any). If NULL, no value is returned. --- drivers/acpi/acpica/nseval.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/acpi/acpica/nseval.c b/drivers/acpi/acpica/nseval.c index 7bcc68f..82e2eef 100644 --- a/drivers/acpi/acpica/nseval.c +++ b/drivers/acpi/acpica/nseval.c @@ -69,8 +69,6 @@ acpi_ns_exec_module_code(union acpi_operand_object *method_obj, * return_object - Where to put method's return value (if *any). If NULL, no value is returned. * parameter_type - Type of Parameter list - * return_object - Where to put method's return value (if - *any). If NULL, no value is returned. * flags - ACPI_IGNORE_RETURN_VALUE to delete return * * RETURN: Status -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: at91/dt: sama5d4: fix dma conf for aes, sha and tdes nodes
Nicolas Ferre writes:
> Le 08/06/2015 15:55, Ludovic Desroches a écrit :
>> The xdmac channel configuration is done in one cell not two. This error
>> prevents from probing devices correctly.
>>
>> Signed-off-by: Ludovic Desroches
>> Fixes: 83906783b766 ("ARM: at91/dt: sama5d4: add aes, sha and tdes nodes")
>> Cc: sta...@vger.kernel.org # 4.1
>
> Acked-by: Nicolas Ferre
>
> Arnd, Olof, Kevin,
>
> This patch is a fix concerning material that had been added to 4.1, so
> it's not exactly a regression.
>
> So, as we missed the last train to 4.1, I'd like to queue it for 4.2 but
> it's the only patch I have on top of my previous DT pull-request
> (at91-dt4, not taken by you, yet).
>
> So, should I build another pull-request (at91-dt5) or can you take this
> single patch when you pull the at91-dt4 material?
I've applied it to next/dt after pulling your dt4 series.
> BTW, here is the link to patchwork if it's easier:
> https://patchwork.kernel.org/patch/6565591/
Yes, that's helpful. I'm a big fan of 'pwclient git-am', and patchwork
collects acks automatically as well. :)
Thanks,
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/params.c: make use of unused but set variable
Hey, Louis. On Wed, Jun 10, 2015 at 11:05:21AM -0600, Louis Langholtz wrote: > The underlying code for sysfs_create_file does call WARN to warn about > any errors. So it's not like the code is totally silent anyway. Then the > unused Not any errors. It triggers warning on missing ops and dup file names. The former is a pretty fundamental usage error and we've had too many of the latter unhandled despite of __must_check. > but set variable in params.c (that's set to its return value) can be removed > (and the compiler warning resolved). Incidentally, I do think it'd be helpful > to comment document this behavior of using WARN so that callers can > more readily recognize (and be assured that) they won't need to call WARN > (unless callers want to add __FILE__ and __LINE__ info to the printk output). > > Having functions marked __must_check seems to make more sense when > their return values are *always* necessary for calling code to have any > business calling them. Like when there's one or more future calls to functions > that have to be made (or not made) for the given resource (the kobject) that > depend on that function's return value (such that the return value state is > always a later conditional). That doesn't appear to be the case however for > sysfs_create_file(). I don't know. Sounds like a weird rule. We had __must_check, still had certain error types unhandled so people added explicit WARN to force people to look into those issues and that means __must_check should go away? Sure, if it warns on all errors and can return void then there's nothing to discuss but that's not the case. Here, an error return indicates userland visible behavior difference. I'd venture to say that the return value is pretty darn important. ... > Adding __must_check probably made it easier for developers to identify calling > code that was depending on success from these functions. At the same time, > it's not true (at least currently) that these return values always need to I don't know. The "always" rule you're speaking of seems too arbitrary and rigid to me. Always is a tricky word and tying oneself to things like that usually doesn't lead to healthy trade-offs. I don't think removing __must_check would be a disaster but at the same time these terminal sysfs functions look like the perfect candidates for such annotations where error returns indicate subtle but visible behavior differences visible to userland while not affecting in-kernel operations at all and thus can be easily ignored. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Now check the account informations that belongs to you
Pay Pal Dear Member, We have faced some problems with your Pay Pal account Please Update your informations within 24h, If you drop this email your account will be desactivated soon. To update your billing information, [+] Click on This Link To Remove This Limitation : http://Security.PayPal.secure.update.support.Information.cgi-bin.primaria-parau.ro Past the link below to open a new secure browser window. Confirm that you're the owner of the account, and follow the instructions. Thank you, Support -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/36] HMM: introduce heterogeneous memory management v3.
On Wed, 10 Jun 2015, Jerome Glisse wrote: > [...] > > Like said, just ignore current code it is utterly broken in so many way > when it comes to lifetime. I screw that part badly when reworking the > patchset, i was focusing on other part. > > I fixed that in my tree, i am waiting for more review on other part as > anyway the lifetime thing is easy to rework/fix. > > http://cgit.freedesktop.org/~glisse/linux/log/?h=hmm > Ok, I'm working through the other patches so I'll check the updates out once I've made it through. My primary interest in this discussion is making sure we know the plan for mirror and device lifetimes. > > So to confirm, on all file operations from user space the driver is > > expected to check that current->mm matches the mm associated with the > > struct file's hmm_mirror? > > Well you might have a valid usecase for that, just be aware that > anything your driver do with the hmm_mirror will actually impact > the mm of the parent. Which i assume is not what you want. > > I would actualy thought that what you want is having a way to find > hmm_mirror using both device file & mm as a key. Otherwise you can > not really use HMM with process that like to fork themself. Which > is a valid usecase to me. For instance process start using HMM > through your driver, decide to fork itself and to also use HMM > through your driver inside its child. Agreed, that sounds reasonable, and the use case is valid. I was digging into this to make sure we don't prevent that. > > > > On file->release the driver still ought to call hmm_mirror_unregister > > regardless of whether the mms match, otherwise we'll never tear down the > > mirror. That means we're not saved from the race condition because > > hmm_mirror_unregister can happen in one thread while hmm_notifier_release > > might be happening in another thread. > > Again there is no race the mirror list is the synchronization point and > it is protected by a lock. So either hmm_mirror_unregister() wins or the > other thread hmm_notifier_release() Yes, I agree. That's not the race I'm worried about. I'm worried about a race on the device lifetime, but in order to hit that one first hmm_notifier_release must take the lock and remove the mirror from the list before hmm_mirror_unregister does it. That's why I brought it up. > > You unregister as soon as you want, it is up to your driver to do it, > i do not enforce anything. The only thing i enforce is that you can > not unregister the hmm device driver before all mirror are unregistered > and free. > > So yes for device driver you want to unregister when device file is > close (which happens when the process exit). Sounds good. > > There is no race here, the mirror struct will only be freed once as again > the list is a synchronization point. Whoever remove the mirror from the > list is responsible to drop the list reference. > > In the fixed code the only thing that will happen twice is the ->release() > callback. Even that can be work around to garanty it is call only once. > > Anyway i do not see anyrace here. > The mirror lifetime is fine. The problem I see is with the device lifetime on a multi-core system. Imagine this sequence: - On CPU1 the mm associated with the mirror is going down - On CPU2 the driver unregisters the mirror then the device When this happens, the last device mutex_unlock on CPU1 is the only thing preventing the free of the device in CPU2. That doesn't work, as described in this thread: https://lkml.org/lkml/2013/12/2/997 Here's the full sequence again with mutex_unlock split apart. Hopefully this shows the device_unregister problem more clearly: CPU1 (mm release) CPU2 (driver) -- -- hmm_notifier_release down_write(>rwsem); hlist_del_init(>mlist); up_write(>rwsem); // CPU1 thread is preempted or // something hmm_mirror_unregister hmm_mirror_kill down_write(>rwsem); // mirror removed by CPU1 already // so hlist_unhashed returns 1 up_write(>rwsem); hmm_mirror_unref(); // Mirror ref now 1 // CPU2 thread is preempted or // something // CPU1 thread is scheduled hmm_mirror_unref(); // Mirror ref now 0, cleanup hmm_mirror_destroy() mutex_lock(>mutex); list_del_init(>dlist); device->ops->release(mirror); kfree(mirror); // CPU2 thread is scheduled, now // both CPU1 and CPU2 are running hmm_device_unregister
[PATCH v2] net, swap: Remove a warning and clarify why sk_mem_reclaim is required when deactivating swap
From: Mel Gorman Jeff Layton reported the following; [ 74.232485] [ cut here ] [ 74.233354] WARNING: CPU: 2 PID: 754 at net/core/sock.c:364 sk_clear_memalloc+0x51/0x80() [ 74.234790] Modules linked in: cts rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache xfs libcrc32c snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device nfsd snd_pcm snd_timer snd e1000 ppdev parport_pc joydev parport pvpanic soundcore floppy serio_raw i2c_piix4 pcspkr nfs_acl lockd virtio_balloon acpi_cpufreq auth_rpcgss grace sunrpc qxl drm_kms_helper ttm drm virtio_console virtio_blk virtio_pci ata_generic virtio_ring pata_acpi virtio [ 74.243599] CPU: 2 PID: 754 Comm: swapoff Not tainted 4.1.0-rc6+ #5 [ 74.244635] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 74.245546] 79e69e31 8800d066bde8 8179263d [ 74.246786] 8800d066be28 8109e6fa [ 74.248175] 880118d48000 8800d58f5c08 880036e380a8 [ 74.249483] Call Trace: [ 74.249872] [] dump_stack+0x45/0x57 [ 74.250703] [] warn_slowpath_common+0x8a/0xc0 [ 74.251655] [] warn_slowpath_null+0x1a/0x20 [ 74.252585] [] sk_clear_memalloc+0x51/0x80 [ 74.253519] [] xs_disable_swap+0x42/0x80 [sunrpc] [ 74.254537] [] rpc_clnt_swap_deactivate+0x7e/0xc0 [sunrpc] [ 74.255610] [] nfs_swap_deactivate+0x27/0x30 [nfs] [ 74.256582] [] destroy_swap_extents+0x74/0x80 [ 74.257496] [] SyS_swapoff+0x222/0x5c0 [ 74.258318] [] ? syscall_trace_leave+0xc7/0x140 [ 74.259253] [] system_call_fastpath+0x12/0x71 [ 74.260158] ---[ end trace 2530722966429f10 ]--- The warning in question was unnecessary but with Jeff's series the rules are also clearer. This patch removes the warning and updates the comment to explain why sk_mem_reclaim() may still be called. [jlayton: remove if (sk->sk_forward_alloc) conditional. As Leon points out that it's not needed.] Cc: Leon Romanovsky Signed-off-by: Mel Gorman Signed-off-by: Jeff Layton --- net/core/sock.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/net/core/sock.c b/net/core/sock.c index 292f42228bfb..469d6039c7f5 100644 --- a/net/core/sock.c +++ b/net/core/sock.c @@ -354,15 +354,12 @@ void sk_clear_memalloc(struct sock *sk) /* * SOCK_MEMALLOC is allowed to ignore rmem limits to ensure forward -* progress of swapping. However, if SOCK_MEMALLOC is cleared while -* it has rmem allocations there is a risk that the user of the -* socket cannot make forward progress due to exceeding the rmem -* limits. By rights, sk_clear_memalloc() should only be called -* on sockets being torn down but warn and reset the accounting if -* that assumption breaks. +* progress of swapping. SOCK_MEMALLOC may be cleared while +* it has rmem allocations due to the last swapfile being deactivated +* but there is a risk that the socket is unusable due to exceeding +* the rmem limits. Reclaim the reserves and obey rmem limits again. */ - if (WARN_ON(sk->sk_forward_alloc)) - sk_mem_reclaim(sk); + sk_mem_reclaim(sk); } EXPORT_SYMBOL_GPL(sk_clear_memalloc); -- 2.4.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 4/5] mm/zpool: allow NULL `zpool' pointer in zpool_destroy_pool()
On Wed, Jun 10, 2015 at 8:59 PM, Sergey Senozhatsky wrote: > On (06/10/15 17:48), Joe Perches wrote: > [..] >> > > > For consistency, tweak zpool_destroy_pool() and NULL-check the >> > > > pointer there. >> > > > >> > > > Proposed by Andrew Morton. >> > > > >> > > > Signed-off-by: Sergey Senozhatsky >> > > > Reported-by: Andrew Morton >> > > > LKML-reference: https://lkml.org/lkml/2015/6/8/583 >> > > >> > > Acked-by: Dan Streetman >> > >> > Thanks. >> > >> > Shall we ask Joe to add zpool_destroy_pool() to the >> > "$func(NULL) is safe and this check is probably not required" list? >> >> [] >> >> Is it really worth it? >> >> There isn't any use of zpool_destroy_pool preceded by an if >> There is one and only one use of zpool_destroy_pool. >> > > Yes, that's why I asked. I don't think that zpool_destroy_pool() > will gain any significant amount of users soon (well, who knows), > so I'm fine with keeping it out of checkpatch checks. Just checked > your opinion. I really doubt if zpool will be used by anyone other than zswap anytime soon. > > -ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 4/5] mm/zpool: allow NULL `zpool' pointer in zpool_destroy_pool()
On (06/10/15 17:48), Joe Perches wrote: [..] > > > > For consistency, tweak zpool_destroy_pool() and NULL-check the > > > > pointer there. > > > > > > > > Proposed by Andrew Morton. > > > > > > > > Signed-off-by: Sergey Senozhatsky > > > > Reported-by: Andrew Morton > > > > LKML-reference: https://lkml.org/lkml/2015/6/8/583 > > > > > > Acked-by: Dan Streetman > > > > Thanks. > > > > Shall we ask Joe to add zpool_destroy_pool() to the > > "$func(NULL) is safe and this check is probably not required" list? > > [] > > Is it really worth it? > > There isn't any use of zpool_destroy_pool preceded by an if > There is one and only one use of zpool_destroy_pool. > Yes, that's why I asked. I don't think that zpool_destroy_pool() will gain any significant amount of users soon (well, who knows), so I'm fine with keeping it out of checkpatch checks. Just checked your opinion. -ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ACPI / enumeration: Document the rules regarding the PRP0001 device ID
From: Rafael J. Wysocki Document how the ACPI device enumeration code uses the special PRP0001 device ID. Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/enumeration.txt | 49 + 1 file changed, 49 insertions(+) Index: linux-pm/Documentation/acpi/enumeration.txt === --- linux-pm.orig/Documentation/acpi/enumeration.txt +++ linux-pm/Documentation/acpi/enumeration.txt @@ -359,3 +359,52 @@ the id should be set like: The ACPI id "XYZ0001" is then used to lookup an ACPI device directly under the MFD device and if found, that ACPI companion device is bound to the resulting child platform device. + +Device Tree namespace link device ID + +The Device Tree protocol uses device indentification based on the "compatible" +property whose value is a string or an array of strings recognized as device +identifiers by drivers and the driver core. The set of all those strings may be +regarded as a device indentification namespace analogous to the ACPI/PNP device +ID namespace. Consequently, in principle it should not be necessary to allocate +a new (and arguably redundant) ACPI/PNP device ID for a devices with an existing +identification string in the Device Tree (DT) namespace, especially if that ID +is only needed to indicate that a given device is compatible with another one, +presumably having a matching driver in the kernel already. + +In ACPI, the device identification object called _CID (Compatible ID) is used to +list the IDs of devices the given one is compatible with, but those IDs must +belong to one of the namespaces prescribed by the ACPI specification (see +Section 6.1.2 of ACPI 6.0 for details) and the DT namespace is not one of them. +Moreover, the specification mandates that either a _HID or an _ADR identificaion +object be present for all ACPI objects representing devices (Section 6.1 of ACPI +6.0). For non-enumerable bus types that object must be _HID and its value must +be a device ID from one of the namespaces prescribed by the specification too. + +The special DT namespace link device ID, PRP0001, provides a means to use the +existing DT-compatible device identification in ACPI and to satisfy the above +requirements following from the ACPI specification at the same time. Namely, +if PRP0001 is returned by _HID, the ACPI subsystem will look for the +"compatible" property in the device object's _DSD and will use the value of that +property to identify the corresponding device in analogy with the original DT +device identification algorithm. If the "compatible" propoerty is not present +or its value is not valid, the device will not be enumerated by the ACPI +subsystem. Otherwise, it will be enumerated automatically as a platform device +and the identification strings from the "compatible" property value will be used +to find a driver for the device along with the device IDs listed by _CID (if +present). + +Analogously, if PRP0001 is present in the list of device IDs returned by _CID, +the identification strings listed by the "compatible" property value (if present +and valid) will be used to look for a driver matching the device, but in that +case their relative priority with respect to the other device IDs listed by +_HID and _CID depends on the position of PRP0001 in the _CID return package. +Specifically, the device IDs returned by _HID and preceding PRP0001 in the _CID +return package will be checked first. Also in that case the bus type the device +will be enumerated to depends on the device ID returned by _HID. + +It is valid to define device objects with a _HID returning PRP0001 and without +the "compatible" property in the _DSD or a _CID as long as one of their +ancestors provides a _DSD with a valid "compatible" property. Such device +objects are then simply regarded as additional "blocks" providing hierarchical +configuration information to the driver of the composite ancestor device. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] staging: lustre/lustre/llite: get rid of incorrect type warning
On Mon, Jun 08, 2015 at 04:01:57PM -0700, Tolga Ceylan wrote: > In dir.c and llite_lib.c, sparse reports multiple warnings messages > due to different address spaces. This patch resolves these warnings > by adding the tag __user for username addresses. > > Signed-off-by: Tolga Ceylan Are you sure all of these are correct? The kernel/user api for lustre is a complex beast, and just casting away the pointer types isn't usually the proper thing to do in order to resolve the issues here. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 4/5] mm/zpool: allow NULL `zpool' pointer in zpool_destroy_pool()
On Thu, 2015-06-11 at 08:58 +0900, Sergey Senozhatsky wrote: > On (06/10/15 16:59), Dan Streetman wrote: > > On Tue, Jun 9, 2015 at 8:04 AM, Sergey Senozhatsky > > wrote: > > > zpool_destroy_pool() does not tolerate a NULL zpool pointer > > > argument and performs a NULL-pointer dereference. Although > > > there is only one zpool_destroy_pool() user (as of 4.1), > > > still update it to be coherent with the corresponding > > > destroy() functions of the remainig pool-allocators (slab, > > > mempool, etc.), which now allow NULL pool-pointers. > > > > > > For consistency, tweak zpool_destroy_pool() and NULL-check the > > > pointer there. > > > > > > Proposed by Andrew Morton. > > > > > > Signed-off-by: Sergey Senozhatsky > > > Reported-by: Andrew Morton > > > LKML-reference: https://lkml.org/lkml/2015/6/8/583 > > > > Acked-by: Dan Streetman > > Thanks. > > Shall we ask Joe to add zpool_destroy_pool() to the > "$func(NULL) is safe and this check is probably not required" list? [] Is it really worth it? There isn't any use of zpool_destroy_pool preceded by an if There is one and only one use of zpool_destroy_pool. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Dear Friend,
Dear Friend, Manager in my Department in Bank of Africa (B.O.A) Burkina Faso. I bring forth a business proposal in the tune of Ten Million Five Hundred Thousand United State Dollars Only.($10.500.000 USD) to be transferred to an offshore account with your assistance as the next of kin to the Inheritance funds. If you are capable of involving and partaking in this transaction, let me know by replying me back so that I will send you the Details. I don't want the money to go into our Government treasurer account as an abGood-day, I know this proposal will meet you in good condition; I am account andon fund. So this is the reason why I contacted you so that the Bank can release the money to you as the next of kin to the deceased customer. Please I will like you to keep this proposal as a top secret and delete it if you are not interested. Upon the receipt of your reply! I will give you the full details on how the business will be executed and also note that you will have 40% of the above mentioned sum if you agree to handle this business with me. I will give you all the vital information about this transaction as soon as I receive your reply, kindly fill your information bellow. 1. Name in full:___ 2. Address:___ 3. Nationality:___ 4. Age:___ 5. Sex:___ 6. Occupation:___ 7. Marital status:___ 8. Phone:___ 9. Fax:___ Regards, Mr.Ali john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio / ACPI: Return -EPROBE_DEFER if the gpiochip was not found
On Wed, Jun 10, 2015 at 9:05 PM, Mika Westerberg
wrote:
> If a driver requests a GPIO described in its _CRS but the GPIO host
> controller (gpiochip) driver providing the GPIO has not been loaded yet
> acpi_get_gpiod() returns -ENODEV which causes the calling driver to fail.
>
> If the gpiochip driver is loaded afterwards the driver requesting the GPIO
> will not notice this.
>
> Better approach is to return -EPROBE_DEFER in such case. Then when the
> gpiochip driver appears the driver requesting the GPIO will be probed
> again. This also aligns ACPI GPIO lookup code closer to DT as it does
> pretty much the same when no gpiochip driver was found.
>
> Reported-by: Tobias Diedrich
> Signed-off-by: Mika Westerberg
> ---
> drivers/gpio/gpiolib-acpi.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c
> index 19b99d0c2bf0..b49006c81a7f 100644
> --- a/drivers/gpio/gpiolib-acpi.c
> +++ b/drivers/gpio/gpiolib-acpi.c
> @@ -114,10 +114,11 @@ static inline int
> acpi_gpiochip_pin_to_gpio_offset(struct gpio_chip *chip,
> * @path: ACPI GPIO controller full path name, (e.g. "\\_SB.GPO1")
> * @pin: ACPI GPIO pin number (0-based, controller-relative)
> *
> - * Returns GPIO descriptor to use with Linux generic GPIO API, or ERR_PTR
> - * error value
> + * Return: GPIO descriptor to use with Linux generic GPIO API, or ERR_PTR
> + * error value. Specifically returns %-EPROBE_DEFER if the referenced GPIO
> + * controller does not have gpiochip registered at the moment. This is to
> + * support probe deferral.
> */
> -
api_get_gpiod() is called in preprobe stage, we still have chance to
probe the device.
Reviewed-by: Amos Kong
> static struct gpio_desc *acpi_get_gpiod(char *path, int pin)
> {
> struct gpio_chip *chip;
> @@ -131,7 +132,7 @@ static struct gpio_desc *acpi_get_gpiod(char *path, int
> pin)
>
> chip = gpiochip_find(handle, acpi_gpiochip_find);
> if (!chip)
> - return ERR_PTR(-ENODEV);
> + return ERR_PTR(-EPROBE_DEFER);
>
> offset = acpi_gpiochip_pin_to_gpio_offset(chip, pin);
> if (offset < 0)
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] oom: always panic on OOM when panic_on_oom is configured
On Wed, 10 Jun 2015, Michal Hocko wrote:
> > Not necessarily. We pin a lot of memory with get_user_pages() and
> > short-circuit it by checking for fatal_signal_pending() specifically for
> > oom conditions. This was done over six years ago by commit 4779280d1ea4
> > ("mm: make get_user_pages() interruptible"). When such a process is
> > faulting in memory, and it is killed by userspace as a result of an oom
> > condition, it needs to be able to allocate (TIF_MEMDIE set by the oom
> > killer due to SIGKILL), return to __get_user_pages(), abort, handle the
> > signal, and exit.
> >
> > I can't possibly make that any more clear.
>
> Are you even reading what I've written? I will ask for the last
> time. What exactly prevents other allocation to trigger to oom path and
> panic the system before the killed task has a chance to terminate?
>
If there are other threads that call into the oom killer that are not in
the exit path or have a SIGKILL to handle, then the machine panics.
That's the purpose of panic_on_oom: the kernel has no way to free memory
without killing a process, so the admin has chosen to panic rather than
wait for memory to become available, which may never happen.
This is how panic_on_oom has always worked.
> > Your patch causes that to instead panic the system if panic_on_oom is set.
> > It's inappropriate and userspace breakage. The fact that I don't
> > personally use panic_on_oom is completely and utterly irrelevant.
> >
> > There is absolutely nothing wrong with a process that has been killed
> > either directly by userspace or as part of a group exit, or a process that
> > is already in the exit path and needs to allocate memory to be able to
> > free its memory, to get access to memory reserves. That's not an oom
> > condition, that's memory reserves. Panic_on_oom has nothing to do with
> > this scenario whatsoever.
>
> It very much has and I have presented arguments about that which you
> didn't bother to comment on. TIF_MEMDIE is not a magic which will help a
> task to exit in all cases. It is a heuristic and it can fail.
> panic_on_oops is a hand break when things go wrong and you want to
> reduce your unresponsive time (read failover part in the documentation).
>
Threads that have been oom killed and have TIF_MEMDIE set should exit.
It's certainly a problem if they do not, since the oom killer relies on it
and will defer forever until it does exit. (We don't actually require
that the thread fully exit, we just require that its memory is freed.) If
you're trying to address the issue that Tetsuo Handa brought up (strange,
because you seemed to not want Tetsuo to talk), then that needs to be
handled in a way that makes forward progress. I suggested three methods
for doing that in this thread that can be pursued to do that, but
panicking the system is not one of them.
> > Panic_on_oom is not panic_when_reclaim_fails.
>
> OOM is when all other reclaim attempts fail. Jeez we are in
> out_of_memory how can this be potentially unclear to you? Yes oom killer
> path might use heuristics to reduce the impact of the OOM condition but
> once we are in this path _we_are_OOM_.
>
Hmm, not exactly. You can't make the same argument for GFP_ATOMIC
allocations, for instance, where we don't have the ability to reclaim.
They get access to a memory reserve so they may succeed in this context.
In the case your patch is short-circuiting, a GFP_KERNEL allocation can
fail to reclaim and then you've decided to panic rather than give an
exiting thread access to memory reserves. It's unnecessary.
(I personally don't care what you do or do not label "oom", I only care
about panic vs. no-panic when the kernel has the ability to allow the
allocation to succeed and make forward progress.)
Let me be clear: the issue that Tetsuo brings up is very real and serious.
It exists for system memory as well as memcg. Trying to address it with
panic_on_oom is absurd. It may be difficult to address, and require
substantial VM work to fix, but panicking is not a solution and would lead
to arbitrary machines in a very large fleet rebooting. There's nothing
the userspace programmer could have done differently to prevent it, this
is solely a kernel issue.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] x86/crash: Allocate enough low memory when crashkernel=high
On 06/10/15 at 10:48am, Yinghai Lu wrote: > On Wed, Jun 10, 2015 at 12:04 AM, Baoquan He wrote: > > > > In fact in this case, it doesn't matter how much memory the system has > > since most of them is above 4G and only 72M is reserved for dma/swiotlb > > in kdump kernel. And it doesn't matter much how many pci/pcie cards the > > system has since it matters how greedy those devices expects dma > > allocation. > > > > Before Joerg posted this patchset v1, our customer complained about > > this too. That means this is not individual case. I think it makes sense > > to increase the default low-memory to make kdump succeed, it's > > definitely better than letting user get a failed kdump and then know > > they need specify more low-memory manually. If user clearly know their > > system doesn't need so much low-memory, specifying crashkernel=xx,low > > works for them. > > Now intel 4socket or 8socket system mostly have [2G,4G) for mmio low. > also I saw one system had [1.5G, 4G) for mmio. Really? How does it work supporting so many pcie devices but with so little DMA32 space? Do they support dma above 4G, or hw iommu is default? Surely for both tight low-memory is not a worry. > > So under 4G low ram is tight, with changing default to 256M is just lazy > and punishing the other system that does not need that. > those systems do not need to have "crashkernel=xx,low" before. OK. Seems defaulting to whom is controversial. Defaulting to 72M kdump on some systems will die. Defaulting to 256M some special systems will be tight on dma/dma32 memory, does their kdump die? If not I vote for 256M. 256M is from Joerg's experimental data, I remember he said his machine need around 200M, then why not 256M. Otherwise it need be increased sooner or later. > > should have other smart way to detect and update the default value. > even dmi blacklist way is better than just changing default value. I am not sure about this. All systems expecting more low-memory need be checked out? > > Thanks > > Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trivial: report backend_cra_name when allocation fails
On Wed, Jun 10, 2015 at 10:27:47PM +0900, Sergey Senozhatsky wrote: > Hello, > > A trivial patch. > > My wifi stopped working recently, and the error message was not too > informative (at least to me): > > kernel: wlp2s0: authenticate with 64:e5:99:74:dc:44 > kernel: wlp2s0: send auth to 64:e5:99:74:dc:44 (try 1/3) > kernel: wlp2s0: authenticated > kernel: wlp2s0: associate with 64:e5:99:74:dc:44 (try 1/3) > kernel: wlp2s0: RX AssocResp from 64:e5:99:74:dc:44 (capab=0x411 status=0 > aid=1) > kernel: wlp2s0: associated > kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wlp2s0: link becomes ready > dhclient[355]: DHCPREQUEST on wlp2s0 to 255.255.255.255 port 67 > kernel: DRBG: could not allocate digest TFM handle > kernel: wlp2s0: deauthenticating from 64:e5:99:74:dc:44 by local choice > (Reason: 1=UNSPECIFIED) > kernel: cfg80211: Calling CRDA to update world regulatory domain > > > an update error message > DRBG: could not allocate digest TFM handle: hmac(sha256) > > is slightly more helpful (didn't have sha256 config enabled). Thanks. And I'll make sure drbg select sha256 so that this doesn't happen. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 5/7] Watchdog: introduce ARM SBSA watchdog driver
Fu Wei wrote: If we make the first stage timeout is timeout/2, this violates the definition of timeout. The documentation says that the hardware needs to reset after the timeout expires. If you program the hardware to timeout/2, the driver can ignore WS0 and allow WS1 to reset the hardware. That conforms to the documentation. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio / ACPI: Return -EPROBE_DEFER if the gpiochip was not found
Rafael J. Wysocki wrote: > On Wednesday, June 10, 2015 04:05:05 PM Mika Westerberg wrote: > > If a driver requests a GPIO described in its _CRS but the GPIO host > > controller (gpiochip) driver providing the GPIO has not been loaded yet > > acpi_get_gpiod() returns -ENODEV which causes the calling driver to fail. > > > > If the gpiochip driver is loaded afterwards the driver requesting the GPIO > > will not notice this. > > > > Better approach is to return -EPROBE_DEFER in such case. Then when the > > gpiochip driver appears the driver requesting the GPIO will be probed > > again. This also aligns ACPI GPIO lookup code closer to DT as it does > > pretty much the same when no gpiochip driver was found. > > > > Reported-by: Tobias Diedrich > > Signed-off-by: Mika Westerberg > > Makes sense to me. > > Acked-by: Rafael J. Wysocki Signed-off-by: Tobias Diedrich -- Tobias PGP: http://8ef7ddba.uguu.de -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] gpio / ACPI: Add label to the gpio request
In create_gpio_led only the legacy pass propagates the label by passing it into
devm_gpio_request_one.
On the newer devicetree/acpi path the label is lost as far as the GPIO
subsystem goes (it is only retained as name in struct gpio_led.
Amend devm_get_gpiod_from_child to also pass the label into the GPIO layer, so
it will show up in /sys/kernel/debug/gpio, so instead of:
GPIOs 288-511, platform/PRP0001:00, AMD SBX00:
gpio-477 (? ) out hi
gpio-478 (? ) out lo
gpio-479 (? ) out hi
we get the much nicer output:
GPIOs 288-511, platform/PRP0001:00, AMD SBX00:
gpio-477 (led1) out hi
gpio-478 (led2) out lo
gpio-479 (led3) out hi
Signed-off-by: Tobias Diedrich
---
drivers/gpio/devres.c | 6 +-
drivers/gpio/gpiolib.c| 6 --
include/linux/gpio/consumer.h | 3 ++-
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpio/devres.c b/drivers/gpio/devres.c
index 07ba823..089db97 100644
--- a/drivers/gpio/devres.c
+++ b/drivers/gpio/devres.c
@@ -103,13 +103,17 @@ struct gpio_desc *__must_check
__devm_gpiod_get_index(struct device *dev,
{
struct gpio_desc **dr;
struct gpio_desc *desc;
+ const char *label = NULL;
dr = devres_alloc(devm_gpiod_release, sizeof(struct gpio_desc *),
GFP_KERNEL);
if (!dr)
return ERR_PTR(-ENOMEM);
- desc = gpiod_get_index(dev, con_id, idx, flags);
+ if (fwnode_property_present(child, "label"))
+ fwnode_property_read_string(child, "label", );
+
+ desc = gpiod_get_index(dev, con_id, idx, flags, label);
if (IS_ERR(desc)) {
devres_free(dr);
return desc;
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 6bc612b..fb2be68 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -2017,6 +2017,7 @@ EXPORT_SYMBOL_GPL(__gpiod_get_index);
* fwnode_get_named_gpiod - obtain a GPIO from firmware node
* @fwnode:handle of the firmware node
* @propname: name of the firmware property representing the GPIO
+ * @label: optional label for the GPIO
*
* This function can be used for drivers that get their configuration
* from firmware.
@@ -2028,7 +2029,8 @@ EXPORT_SYMBOL_GPL(__gpiod_get_index);
* In case of error an ERR_PTR() is returned.
*/
struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
-const char *propname)
+const char *propname,
+const char *label)
{
struct gpio_desc *desc = ERR_PTR(-ENODEV);
bool active_low = false;
@@ -2056,7 +2058,7 @@ struct gpio_desc *fwnode_get_named_gpiod(struct
fwnode_handle *fwnode,
if (IS_ERR(desc))
return desc;
- ret = gpiod_request(desc, NULL);
+ ret = gpiod_request(desc, label);
if (ret)
return ERR_PTR(ret);
diff --git a/include/linux/gpio/consumer.h b/include/linux/gpio/consumer.h
index 3a7c9ff..ef7d322 100644
--- a/include/linux/gpio/consumer.h
+++ b/include/linux/gpio/consumer.h
@@ -134,7 +134,8 @@ int desc_to_gpio(const struct gpio_desc *desc);
struct fwnode_handle;
struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
-const char *propname);
+const char *propname,
+const char *label);
struct gpio_desc *devm_get_gpiod_from_child(struct device *dev,
const char *con_id,
struct fwnode_handle *child);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] at91: dt for 4.2 #4
Nicolas Ferre writes: > Arnd, Olof, Kevin, > > Another batch of DT changes for 4.2. The bulk of it is the move to stdout-path > for our cosonle. > As usual, the material is based on previous at91-dt3 that you already have. > > Thanks, best regards, > > The following changes since commit f80737082c210fae8ce15ad5d615da381889d5e9: > > ARM: at91/dt: remove useless usb clock (2015-05-22 11:11:33 +0200) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git > tags/at91-dt4 > > for you to fetch changes up to ea25525ce0d195724fead07fe6562fe478a3bf6f: > > ARM: at91/dt: sama5d4ek: mci0 uses slot 0 (2015-06-04 11:49:12 +0200) > > > Fourth batch of DT changes for 4.2: > - rtc node for at91sam9rl/at91sam9rlek > - move to stdout-path for console on kizbox and all Atmel's boards > - Addition of the Acme Systems' Arietta G25 > - two little fixes for Kizbox and sama5d4ek > > Applied to next/dt, Thanks, Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 1/2] arm: fix non-section-aligned low memory mapping
On Wed, Jun 10, 2015 at 11:40:59PM +0100, Russell King - ARM Linux wrote: > On Thu, Jun 11, 2015 at 02:59:32AM +0800, Min-Hua Chen wrote: > > In current design, the memblock.current_limit is set to > > a section-aligned value in sanity_check_meminfo(). > > > > However, the section-aligned memblock may become non-section-aligned > > after arm_memblock_init(). For example, the first section-aligned > > memblock is 0x-0x0100 and sanity_check_meminfo sets > > current_limit to 0x0100. After arm_memblock_init, two memory blocks > > [0x00c0 - 0x00d0] and [0x00ff - 0x0100] are reserved > > by memblock_reserve() and make the original memory block > > [0x-0x0100] becomes: > > There isn't a problem with memblock_reserve(). That just marks the > memory as reserved, it doesn't steal the memory from the lowmem > mappings - in fact, it is still expected that reserved memory > claimed in this way will be mapped. > > Somehow, I don't think this is what you're doing though, because you > go on to describe a problem which can only happen if you steal memory > after arm_memblock_init() has returned. Yes, your are right. The probelm is not caused by memblock_reserve(). It's caused by the memory reserving code in early_init_fdt_scan_reserved_mem(), which is in arm_memblock_init(). The memory reserving code in of_of_reserved_mem.c allows the reserved memory blocks to have a "no-map" property. When a reserved-memory is marked "no-map", the mapping will be removed by memblock_remove() like arm_memblock_steal() does. > Don't do this. There is a specific point in the boot sequence where you > are permitted to steal memory, which is done inside arm_memblock_init(). > Stealing outside of that is not permitted. > > arm_memblock_steal() is written to BUG_ON() if you attempt to do this > outside of the permissible code paths. > > -- > FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up > according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 4/5] mm/zpool: allow NULL `zpool' pointer in zpool_destroy_pool()
On (06/10/15 16:59), Dan Streetman wrote:
> On Tue, Jun 9, 2015 at 8:04 AM, Sergey Senozhatsky
> wrote:
> > zpool_destroy_pool() does not tolerate a NULL zpool pointer
> > argument and performs a NULL-pointer dereference. Although
> > there is only one zpool_destroy_pool() user (as of 4.1),
> > still update it to be coherent with the corresponding
> > destroy() functions of the remainig pool-allocators (slab,
> > mempool, etc.), which now allow NULL pool-pointers.
> >
> > For consistency, tweak zpool_destroy_pool() and NULL-check the
> > pointer there.
> >
> > Proposed by Andrew Morton.
> >
> > Signed-off-by: Sergey Senozhatsky
> > Reported-by: Andrew Morton
> > LKML-reference: https://lkml.org/lkml/2015/6/8/583
>
> Acked-by: Dan Streetman
Thanks.
Shall we ask Joe to add zpool_destroy_pool() to the
"$func(NULL) is safe and this check is probably not required" list?
-ss
> > ---
> > mm/zpool.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/mm/zpool.c b/mm/zpool.c
> > index bacdab6..2f59b90 100644
> > --- a/mm/zpool.c
> > +++ b/mm/zpool.c
> > @@ -202,6 +202,9 @@ struct zpool *zpool_create_pool(char *type, char *name,
> > gfp_t gfp,
> > */
> > void zpool_destroy_pool(struct zpool *zpool)
> > {
> > + if (unlikely(!zpool))
> > + return;
> > +
> > pr_info("destroying pool type %s\n", zpool->type);
> >
> > spin_lock(_lock);
> > --
> > 2.4.3.368.g7974889
> >
> > --
> > To unsubscribe, send a message with 'unsubscribe linux-mm' in
> > the body to majord...@kvack.org. For more info on Linux MM,
> > see: http://www.linux-mm.org/ .
> > Don't email: mailto:"d...@kvack.org;> em...@kvack.org
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 RESEND] mailbox: add ACPI support for mailbox framework
On Wednesday, April 29, 2015 08:22:37 AM Jassi Brar wrote: > On Wed, Apr 22, 2015 at 7:34 AM, Rafael J. Wysocki wrote: > > On Tuesday, April 21, 2015 04:53:14 PM Jassi Brar wrote: > >> On Tue, Apr 21, 2015 at 6:28 AM, Feng Kan wrote: > >> > > >> > Just want to ping this. I haven't gotten any response from mailbox > >> > maintainer for this > >> > patch or any of my other mailbox patches. > >> > > >> Sorry I had been busy and still need to have a critical look at the > >> new api. It would sooth my nerves to see an ACK from some acpi god. > > > > I'm far from one, but I'll be looking at this is detail next week if > > that helps (this week I'm traveling). > > > No, you are one on my list :) Your review from acpi perspective will > be greatly helpful. The code changes look reasonable to me, but it would be good to point to the DT property definition this is supposed to follow in the changelog (ie. where exactly this is defined for DT). The "mboxes" _DSD property will need to be registered at some point in the future too when the infrastructure for that is ready. -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ia64: remove paravirt code
On Wed, Jun 10, 2015 at 3:11 PM, Tony Luck wrote: > On Tue, Jun 2, 2015 at 11:42 AM, Luis R. Rodriguez > wrote: >> From: "Luis R. Rodriguez" >> >> All the ia64 pvops code is now dead code since both >> xen and kvm support have been ripped out [0] [1]. Just >> that no one had troubled to rip this stuff out. The only >> useful remaining pieces were the old pvops docs but that >> was recently also generalized and moved out from ia64 [2]. >> >> This has been run time tested on an ia64 Madison system. >> >> [0] 003f7de625890 "KVM: ia64: remove" since v3.19-rc1 >> [1] d52eefb47d4eb "ia64/xen: Remove Xen support for ia64" since v3.14-rc1 >> [2] "virtual: Documentation: simplify and generalize paravirt_ops.txt" >> >> Signed-off-by: Luis R. Rodriguez >> --- >> I've build and run time tested this against linux-next tag next-20150529. >> The build will fail if you've enabled the LKDTM (Linux Kernel Dump Test >> Tool Module) enabled on SLE11 ia64 builds, a fix for which I've just >> posted [3]. >> >> [3] https://marc.info/?l=linux-kernel=143327018731361=2 > > > So this builds cleanly on all my test configurations, and boots on > the one machine that I tried it on - good job. Thanks! > But I'm wondering how much of this was auto-generated (and > so perhaps free from typos) and how much was done by hand? I did this work to help study alternatives to how pvops was implemented on other architectures, so I studied the patches that introduced the code meticulously and then used my editor / editor regexps to make substitutions as needed and shift code as needed. Compile testing found some minor typos, which were easy to fix. > It isn't a full revert of the patch series that added paravirt ... you > simplified macros like: > #define MOV_TO_KR(kr, reg, clob0, clob1) \ > - mov IA64_KR(kr) = reg \ > - CLOBBER(clob0) \ > - CLOBBER(clob1) > + mov IA64_KR(kr) = reg > > but didn't remove them completely. Right, this IMHO was not necessary at this point but I can understand if you want that. I think that could be done as a separate patch too though and perhaps done through a machine, not human and manually. > So what can I do to validate this 4000+ line patch? Can I compare > disassembled ".o" files pre/post patch somehow to be sure this doesn't > have some small typo errors somewhere? Its quite a huge chunk of code removed, I doubt that .o files would remain intact after this, but I could be wrong. I think run time validation and examination of the code changes, understanding of the code changes is necessary, but also likely just as run time tests. Is there no ia64 regression test suite? I don't see ia64 getting much love anyway these days so would it not hurt to merge and spin through linux-next for a while and if no issues are reported make it fly in? Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/10] x86/intel_rdt: Implement scheduling support for Intel RDT
Adds support for IA32_PQR_ASSOC MSR writes during task scheduling. For
Cache Allocation, MSR write would let the task fill in the cache
'subset' represented by the cgroup's cache_mask.
The high 32 bits in the per processor MSR IA32_PQR_ASSOC represents the
CLOSid. During context switch kernel implements this by writing the
CLOSid of the cgroup to which the task belongs to the CPU's
IA32_PQR_ASSOC MSR.
This patch also implements a common software cache for IA32_PQR_MSR(RMID
0:9, CLOSId 32:63) to be used by both Cache monitoring(CMT) and
Cache allocation. CMT updates the RMID where as cache_alloc updates the
CLOSid in the software cache. During scheduling when the new
RMID/CLOSid value is different from the cached values, IA32_PQR_MSR is
updated. Since the measured rdmsr latency for IA32_PQR_MSR is very
high(~250 cycles) this software cache is necessary to avoid reading the
MSR to compare the current CLOSid value.
The following considerations are done for the PQR MSR write so that it
minimally impacts scheduler hot path:
- This path does not exist on any non-intel platforms.
- On Intel platforms, this would not exist by default unless CGROUP_RDT
is enabled.
- remains a no-op when CGROUP_RDT is enabled and intel SKU does not
support the feature.
- When feature is available and enabled, never does MSR write till the
user manually creates a cgroup directory *and* assigns a cache_mask
different from root cgroup directory. Since the child node inherits
the parents cache mask , by cgroup creation there is no scheduling hot
path impact from the new cgroup.
- MSR write is only done when there is a task with different Closid is
scheduled on the CPU. Typically if the task groups are bound to be
scheduled on a set of CPUs , the number of MSR writes is greatly
reduced.
- A per CPU cache of CLOSids is maintained to do the check so that we
dont have to do a rdmsr which actually costs a lot of cycles.
- For cgroup directories having same cache_mask the CLOSids are reused.
This minimizes the number of CLOSids used and hence reduces the MSR
write frequency.
Signed-off-by: Vikas Shivappa
---
Minor changes as per feedback from Thomas:
- added a comment where we call schedule in code only when RDT is
enabled.
- Reordered the local declarations to follow convention in
intel_cqm_xchg_rmid
arch/x86/include/asm/intel_rdt.h | 45 ++
arch/x86/include/asm/rdt_common.h | 25 +
arch/x86/include/asm/switch_to.h | 3 ++
arch/x86/kernel/cpu/intel_rdt.c| 17 +++
arch/x86/kernel/cpu/perf_event_intel_cqm.c | 26 ++---
5 files changed, 93 insertions(+), 23 deletions(-)
create mode 100644 arch/x86/include/asm/rdt_common.h
diff --git a/arch/x86/include/asm/intel_rdt.h b/arch/x86/include/asm/intel_rdt.h
index 3ad426c..78df3d7 100644
--- a/arch/x86/include/asm/intel_rdt.h
+++ b/arch/x86/include/asm/intel_rdt.h
@@ -4,10 +4,16 @@
#ifdef CONFIG_CGROUP_RDT
#include
+#include
+
#define MAX_CBM_LENGTH 32
#define IA32_L3_CBM_BASE 0xc90
#define CBM_FROM_INDEX(x) (IA32_L3_CBM_BASE + x)
+DECLARE_PER_CPU(struct intel_pqr_state, pqr_state);
+extern struct static_key rdt_enable_key;
+extern void __intel_rdt_sched_in(void);
+
struct rdt_subsys_info {
unsigned long *closmap;
};
@@ -35,5 +41,44 @@ static inline struct intel_rdt *parent_rdt(struct intel_rdt
*ir)
return css_rdt(ir->css.parent);
}
+/*
+ * Return rdt group to which this task belongs.
+ */
+static inline struct intel_rdt *task_rdt(struct task_struct *task)
+{
+ return css_rdt(task_css(task, intel_rdt_cgrp_id));
+}
+
+/*
+ * intel_rdt_sched_in() - Writes the task's CLOSid to IA32_PQR_MSR
+ *
+ * Following considerations are made so that this has minimal impact
+ * on scheduler hot path:
+ * - This will stay as no-op unless we are running on an Intel SKU
+ * which supports L3 cache allocation.
+ * - When support is present and enabled, does not do any
+ * IA32_PQR_MSR writes until the user starts really using the feature
+ * ie creates a rdt cgroup directory and assigns a cache_mask thats
+ * different from the root cgroup's cache_mask.
+ * - Caches the per cpu CLOSid values and does the MSR write only
+ * when a task with a different CLOSid is scheduled in. That
+ * means the task belongs to a different cgroup.
+ * - Closids are allocated so that different cgroup directories
+ * with same cache_mask gets the same CLOSid. This minimizes CLOSids
+ * used and reduces MSR write frequency.
+ */
+static inline void intel_rdt_sched_in(void)
+{
+ /*
+* Call the schedule in code only when RDT is enabled.
+*/
+ if (static_key_false(_enable_key))
+ __intel_rdt_sched_in();
+}
+
+#else
+
+static inline void intel_rdt_sched_in(void) {}
+
#endif
#endif
diff --git a/arch/x86/include/asm/rdt_common.h
b/arch/x86/include/asm/rdt_common.h
new file
Re: [PATCH 2/2] drivercore: Fix unregistration path of platform devices
> >> This patch from Grant needs to be applied: > >> > >> [PATCH 2/2] drivercore: Fix unregistration path of platform devices > > > > I need some acks before I apply anything else as this is a total mess. > > Yes please. Rob, Pantelis, Wolfram. Can you test my patch and provides acks? Ah, this is the mail I forgot to write yesterday, sorry. I am on travel and can not test before Monday, I am afraid. Will that do? Thanks a lot for working on this, though! Much appreciated. signature.asc Description: Digital signature
Re: [PATCH] crypto/drbg: report backend_cra_name when allocation fails
On (06/10/15 17:09), Stephan Mueller wrote: > Hi Sergey, > > >Be more verbose and also report ->backend_cra_name when > >crypto_alloc_shash() or crypto_alloc_cipher() fail in > >drbg_init_hash_kernel() or drbg_init_sym_kernel() > >correspondingly. > > > >Example > > DRBG: could not allocate digest TFM handle: hmac(sha256) > > > >Signed-off-by: Sergey Senozhatsky > > Headscratch -- the Kconfig should have HMAC selected for compilation. When > HMAC is available (regardless whether it is a module or not), it is pulled in > by the kernel crypto API. Thus, there should not have been the error that > HMAC > is missing. > > Can you send your .config file, please? > Hi Stephan, sure, will post it later (as soon as I get back to my laptop). -ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/15] Kill off set_irq_flags
Rob Herring writes: > On Tue, Jun 9, 2015 at 3:28 PM, Russell King - ARM Linux > wrote: >> On Tue, Jun 09, 2015 at 01:26:26PM -0500, Rob Herring wrote: >>> This series converts all users of ARM specific set_irq_flags to use >>> common genirq functions. In many cases where irqdomains are used, the >>> set_irq_flags calls were redundant, so I've removed them. >>> >>> This is not intended for 4.2, but if any subsystem maintainers want to >>> pick up their subsystem's change that is fine. All but the last 2 >>> patches stand on their own. Any new drivers going into 4.2 may need a >>> similar change, but I'm sure people are told not to use set_irq_flags in >>> reviews. ;) >> >> So what are you doing about the initial state of IRQs on legacy ARM where >> IRQs start off being un-requestable, and need the set_irq_flags() to make >> them requestable. I think you could be introducing a massive regression >> by making this change. > > None of that changes. The initial state is set by ARCH_IRQ_INIT_FLAGS > which I've not changed: > > #define ARCH_IRQ_INIT_FLAGS (IRQ_NOREQUEST | IRQ_NOPROBE) > >> Unless you can prove that this isn't the case, you shouldn't be removing >> this stuff, especially not from legacy platforms. > > set_irq_flags() only does a translation from custom ARM IRQF_* flags > to standard flags and then calls irq_modify_status(). This only > removes the translation and users set/clear standard flags directly. > It is a straight-forward removal of a wrapper function. > > I *would* like to get rid of ARCH_IRQ_INIT_FLAGS and have the same > defaults across arches, but yes that would likely cause regressions. For some reason, I don't have 00/15 in my inbox or list folders, so replying here... I gave this series a spin through the kernelci.org build/boot bot where it was booted on ~20 different ARM SoC families and mulitple different defconfigs, and there were no boot failures, so it at least passes a basic boot sanity check. If you think it's appropriate, feel free to add : Tested-by: Kevin Hilman Kevin [1] http://kernelci.org/boot/all/job/khilman/kernel/v4.1-rc7-15-g64b9a5c929f7/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpufreq, Fix overflow in busy_scaled due to long delay
On Wednesday, June 10, 2015 09:18:45 AM Prarit Bhargava wrote:
> I looked into switching to div64_s64() instead of the 32-bit version in
> div_fp(), however, this would result in sample_ratio and core_busy returning
> 0 which is something we don't want.
>
> P.
>
> ---8<---
>
> The kernel may delay interrupts for a long time which can result in timers
> being delayed. If this occurs the intel_pstate driver will crash with
> a divide by zero error:
>
> divide error: [#1] SMP
> Modules linked in: btrfs zlib_deflate raid6_pq xor msdos ext4 mbcache jbd2
> binfmt_misc arc4 md4 nls_utf8 cifs dns_resolver tcp_lp bnep bluetooth rfkill
> fuse dm_service_time iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi
> nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ftp ip6t_rpfilter
> ip6t_REJECT ipt_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc
> ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6
> nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter
> ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat
> nf_conntrack iptable_mangle iptable_security iptable_raw iptable_filter
> ip_tables intel_powerclamp coretemp vfat fat kvm_intel iTCO_wdt
> iTCO_vendor_support ipmi_devintf sr_mod kvm crct10dif_pclmul
> crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel cdc_ether lrw
> usbnet cdrom mii gf128mul glue_helper ablk_helper cryptd lpc_ich mfd_core
> pcspkr sb_edac edac_core ipmi_si ipmi_msghandler ioatdma wmi shpchp acpi_pad
> nfsd auth_rpcgss nfs_acl lockd uinput dm_multipath sunrpc xfs libcrc32c
> usb_storage sd_mod crc_t10dif crct10dif_common ixgbe mgag200 syscopyarea
> sysfillrect sysimgblt mdio drm_kms_helper ttm igb drm ptp pps_core dca
> i2c_algo_bit megaraid_sas i2c_core dm_mirror dm_region_hash dm_log dm_mod
> CPU: 113 PID: 0 Comm: swapper/113 Tainted: GW --
> 3.10.0-229.1.2.el7.x86_64 #1
> Hardware name: IBM x3950 X6 -[3837AC2]-/00FN827, BIOS -[A8E112BUS-1.00]-
> 08/27/2014
> task: 880fe8abe660 ti: 880fe8ae4000 task.ti: 880fe8ae4000
> RIP: 0010:[] []
> intel_pstate_timer_func+0x179/0x3d0
> RSP: 0018:883fff4e3db8 EFLAGS: 00010206
> RAX: 2710 RBX: 883fe6965100 RCX:
> RDX: RSI: 0010 RDI: 2e53632d
> RBP: 883fff4e3e20 R08: 000e6f69a5a125c0 R09: 883fe84ec001
> R10: 0002 R11: 0005 R12: 49f5
> R13: 00271000 R14: 49f5 R15: 0246
> FS: () GS:883fff4e() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 7f7668601000 CR3: 0190a000 CR4: 001407e0
> DR0: DR1: DR2:
> DR3: DR6: 0ff0 DR7: 0400
> Stack:
> 883fff4e3e58 81099dc1 0086 0071
> 883fff4f3680 0071 fbdc8a965e33afee 810b69dd
> 883fe84ec000 883fe6965108 0100 814a9100
> Call Trace:
>
>
> [] ? run_posix_cpu_timers+0x51/0x840
> [] ? trigger_load_balance+0x5d/0x200
> [] ? pid_param_set+0x130/0x130
> [] call_timer_fn+0x36/0x110
> [] ? pid_param_set+0x130/0x130
> [] run_timer_softirq+0x21f/0x320
> [] __do_softirq+0xef/0x280
> [] call_softirq+0x1c/0x30
> [] do_softirq+0x65/0xa0
> [] irq_exit+0x115/0x120
> [] smp_apic_timer_interrupt+0x45/0x60
> [] apic_timer_interrupt+0x6d/0x80
>
>
> [] ? cpuidle_enter_state+0x52/0xc0
> [] ? cpuidle_enter_state+0x48/0xc0
> [] cpuidle_idle_call+0xc5/0x200
> [] arch_cpu_idle+0xe/0x30
> [] cpu_startup_entry+0xf1/0x290
> [] start_secondary+0x1ba/0x230
> Code: 42 0f 00 45 89 e6 48 01 c2 43 8d 44 6d 00 39 d0 73 26 49 c1 e5 08 89 d2
> 4d 63 f4 49 63 c5 48 c1 e2 08 48 c1 e0 08 48 63 ca 48 99 <48> f7 f9 48 98 4c
> 0f af f0 49 c1 ee 08 8b 43 78 c1 e0 08 44 29
> RIP [] intel_pstate_timer_func+0x179/0x3d0
> RSP
>
> The kernel values for cpudata for CPU 113 were:
>
> struct cpudata {
> cpu = 113,
> timer = {
> entry = {
> next = 0x0,
> prev = 0xdead00200200
> },
> expires = 8357799745,
> base = 0x883fe84ec001,
> function = 0x814a9100 ,
> data = 18446612406765768960,
>
> i_gain = 0,
> d_gain = 0,
> deadband = 0,
> last_err = 22489
> },
> last_sample_time = {
> tv64 = 4063132438017305
> },
> prev_aperf = 287326796397463,
> prev_mperf = 251427432090198,
> sample = {
> core_pct_busy = 23081,
> aperf = 2937407,
> mperf = 3257884,
> freq = 2524484,
> time = {
> tv64 = 4063149215234118
> }
> }
> }
>
> which results in the time between samples = last_sample_time - sample.time
> = 4063149215234118 - 4063132438017305 = 16777216813 which is 16.777 seconds.
>
> The duration between reads of the APERF and MPERF registers overflowed a s32
> sized integer
Re: [PATCH] gpio / ACPI: Return -EPROBE_DEFER if the gpiochip was not found
On Wednesday, June 10, 2015 04:05:05 PM Mika Westerberg wrote:
> If a driver requests a GPIO described in its _CRS but the GPIO host
> controller (gpiochip) driver providing the GPIO has not been loaded yet
> acpi_get_gpiod() returns -ENODEV which causes the calling driver to fail.
>
> If the gpiochip driver is loaded afterwards the driver requesting the GPIO
> will not notice this.
>
> Better approach is to return -EPROBE_DEFER in such case. Then when the
> gpiochip driver appears the driver requesting the GPIO will be probed
> again. This also aligns ACPI GPIO lookup code closer to DT as it does
> pretty much the same when no gpiochip driver was found.
>
> Reported-by: Tobias Diedrich
> Signed-off-by: Mika Westerberg
Makes sense to me.
Acked-by: Rafael J. Wysocki
> ---
> drivers/gpio/gpiolib-acpi.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c
> index 19b99d0c2bf0..b49006c81a7f 100644
> --- a/drivers/gpio/gpiolib-acpi.c
> +++ b/drivers/gpio/gpiolib-acpi.c
> @@ -114,10 +114,11 @@ static inline int
> acpi_gpiochip_pin_to_gpio_offset(struct gpio_chip *chip,
> * @path:ACPI GPIO controller full path name, (e.g. "\\_SB.GPO1")
> * @pin: ACPI GPIO pin number (0-based, controller-relative)
> *
> - * Returns GPIO descriptor to use with Linux generic GPIO API, or ERR_PTR
> - * error value
> + * Return: GPIO descriptor to use with Linux generic GPIO API, or ERR_PTR
> + * error value. Specifically returns %-EPROBE_DEFER if the referenced GPIO
> + * controller does not have gpiochip registered at the moment. This is to
> + * support probe deferral.
> */
> -
> static struct gpio_desc *acpi_get_gpiod(char *path, int pin)
> {
> struct gpio_chip *chip;
> @@ -131,7 +132,7 @@ static struct gpio_desc *acpi_get_gpiod(char *path, int
> pin)
>
> chip = gpiochip_find(handle, acpi_gpiochip_find);
> if (!chip)
> - return ERR_PTR(-ENODEV);
> + return ERR_PTR(-EPROBE_DEFER);
>
> offset = acpi_gpiochip_pin_to_gpio_offset(chip, pin);
> if (offset < 0)
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/8] ACPI / PM: Attach ACPI power domain only once
On Monday, June 01, 2015 05:47:56 PM Andy Shevchenko wrote:
> From: Mika Westerberg
>
> Some devices, like MFD subdevices, share a single ACPI companion device so
> that they are able to access their resources and children. However,
> currently all these subdevices are attached to the ACPI power domain and
> this might cause that the power methods for the companion device get called
> more than once.
>
> In order to solve this we attach the ACPI power domain only to the first
> physical device that is bound to the ACPI companion device. In case of MFD
> devices, this is the parent MFD device itself.
>
> Signed-off-by: Mika Westerberg
> Signed-off-by: Andy Shevchenko
Acked-by: Rafael J. Wysocki
> ---
> drivers/acpi/device_pm.c | 8
> drivers/acpi/internal.h | 2 ++
> drivers/acpi/scan.c | 46 ++
> 3 files changed, 40 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
> index 735db11..7d0c7e9 100644
> --- a/drivers/acpi/device_pm.c
> +++ b/drivers/acpi/device_pm.c
> @@ -1103,6 +1103,14 @@ int acpi_dev_pm_attach(struct device *dev, bool
> power_on)
> if (dev->pm_domain)
> return -EEXIST;
>
> + /*
> + * Only attach the power domain to the first device if the
> + * companion is shared by multiple. This is to prevent doing power
> + * management twice.
> + */
> + if (!acpi_device_is_first_physical_node(adev, dev))
> + return -EBUSY;
> +
> acpi_add_pm_notifier(adev, dev, acpi_pm_notify_work_func);
> dev->pm_domain = _general_pm_domain;
> if (power_on) {
> diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
> index ba4a61e..c26a951 100644
> --- a/drivers/acpi/internal.h
> +++ b/drivers/acpi/internal.h
> @@ -96,6 +96,8 @@ void acpi_device_add_finalize(struct acpi_device *device);
> void acpi_free_pnp_ids(struct acpi_device_pnp *pnp);
> bool acpi_device_is_present(struct acpi_device *adev);
> bool acpi_device_is_battery(struct acpi_device *adev);
> +bool acpi_device_is_first_physical_node(struct acpi_device *adev,
> + const struct device *dev);
>
> /* --
>Power Resource
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 03141aa..37f8f74 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -223,6 +223,35 @@ static int create_of_modalias(struct acpi_device
> *acpi_dev, char *modalias,
> return len;
> }
>
> +/**
> + * acpi_device_is_first_physical_node - Is given dev first physical node
> + * @adev: ACPI companion device
> + * @dev: Physical device to check
> + *
> + * Function checks if given @dev is the first physical devices attached to
> + * the ACPI companion device. This distinction is needed in some cases
> + * where the same companion device is shared between many physical devices.
> + *
> + * Note that the caller have to provide valid @adev pointer.
> + */
> +bool acpi_device_is_first_physical_node(struct acpi_device *adev,
> + const struct device *dev)
> +{
> + bool ret = false;
> +
> + mutex_lock(>physical_node_lock);
> + if (!list_empty(>physical_node_list)) {
> + const struct acpi_device_physical_node *node;
> +
> + node = list_first_entry(>physical_node_list,
> + struct acpi_device_physical_node, node);
> + ret = node->dev == dev;
> + }
> + mutex_unlock(>physical_node_lock);
> +
> + return ret;
> +}
> +
> /*
> * acpi_companion_match() - Can we match via ACPI companion device
> * @dev: Device in question
> @@ -247,7 +276,6 @@ static int create_of_modalias(struct acpi_device
> *acpi_dev, char *modalias,
> static struct acpi_device *acpi_companion_match(const struct device *dev)
> {
> struct acpi_device *adev;
> - struct mutex *physical_node_lock;
>
> adev = ACPI_COMPANION(dev);
> if (!adev)
> @@ -256,21 +284,7 @@ static struct acpi_device *acpi_companion_match(const
> struct device *dev)
> if (list_empty(>pnp.ids))
> return NULL;
>
> - physical_node_lock = >physical_node_lock;
> - mutex_lock(physical_node_lock);
> - if (list_empty(>physical_node_list)) {
> - adev = NULL;
> - } else {
> - const struct acpi_device_physical_node *node;
> -
> - node = list_first_entry(>physical_node_list,
> - struct acpi_device_physical_node, node);
> - if (node->dev != dev)
> - adev = NULL;
> - }
> - mutex_unlock(physical_node_lock);
> -
> - return adev;
> + return acpi_device_is_first_physical_node(adev, dev) ? adev : NULL;
> }
>
> static int __acpi_device_uevent_modalias(struct acpi_device *adev,
>
--
I
Re: [PATCH v3 3/8] Driver core: wakeup the parent device before trying probe
On Wednesday, June 10, 2015 12:43:15 PM Andy Shevchenko wrote:
> On Wed, 2015-06-10 at 02:08 +0200, Rafael J. Wysocki wrote:
> > On Tuesday, June 09, 2015 01:42:00 AM Rafael J. Wysocki wrote:
> > > On Monday, June 01, 2015 05:47:57 PM Andy Shevchenko wrote:
> > > > From: Heikki Krogerus
> > > >
> > > > If the parent is still suspended when driver probe is
> > > > attempted, the result may be failure.
> > > >
> > > > For example, if the parent is a PCI MFD device that has been
> > > > suspended when we try to probe our device, any register
> > > > reads will return 0x.
> > > >
> > > > To fix the problem, making sure the parent is always awake
> > > > before attempting driver probe.
> > > >
> > > > Signed-off-by: Heikki Krogerus
> > > > Signed-off-by: Andy Shevchenko
> > > > ---
> > > > drivers/base/dd.c | 8
> > > > 1 file changed, 8 insertions(+)
> > > >
> > > > diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> > > > index e843fdb..cfbeff3 100644
> > > > --- a/drivers/base/dd.c
> > > > +++ b/drivers/base/dd.c
> > > > @@ -399,6 +399,8 @@ EXPORT_SYMBOL_GPL(wait_for_device_probe);
> > > > *
> > > > * This function must be called with @dev lock held. When called for a
> > > > * USB interface, @dev->parent lock must be held as well.
> > > > + *
> > > > + * If device has a parent it will be powered on during device's
> > > > probe().
> > > > */
> > > > int driver_probe_device(struct device_driver *drv, struct device *dev)
> > > > {
> > > > @@ -410,10 +412,16 @@ int driver_probe_device(struct device_driver
> > > > *drv, struct device *dev)
> > > > pr_debug("bus: '%s': %s: matched device %s with driver %s\n",
> > > > drv->bus->name, __func__, dev_name(dev), drv->name);
> > > >
> > > > + if (dev->parent)
> > > > + pm_runtime_get_sync(dev->parent);
> > > > +
> > >
> > > For some bus types that will resume and suspend the parent for many times
> > > in
> > > a row in device_attach() until an appropriate driver is found. Would it
> > > be
> > > more efficient to call it once before the bus_for_each_drv() loop in
> > > there?
> >
> > Actually, something like the below should work too (the bumping up of the
> > parent's usage counter before the loop will keep it in the runtime-active
> > state throughout the loop).
> >
>
> Thanks for the patch! We are going to test this soon.
>
> By the way, can you give your Ack for patches 1 and 2 if there is no
> objection?
OK
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/8] PM / QoS: Make it possible to expose device latency tolerance to userspace
On Monday, June 01, 2015 05:47:55 PM Andy Shevchenko wrote:
> From: Mika Westerberg
>
> Typically when a device is created the bus core it belongs to (for example
> PCI) does not know if the device supports things like latency tolerance.
> This is left to the driver that binds to the device in question. However,
> at that time the device has already been created and there is no way to set
> its dev->power.set_latency_tolerance anymore.
>
> So follow what has been done for other PM QoS attributes as well and allow
> drivers to expose and hide latency tolerance from userspace, if the device
> supports it.
>
> Signed-off-by: Mika Westerberg
> Signed-off-by: Andy Shevchenko
Acked-by: Rafael J. Wysocki
> ---
> drivers/base/power/power.h | 2 ++
> drivers/base/power/qos.c | 37 +
> drivers/base/power/sysfs.c | 11 +++
> include/linux/pm_qos.h | 5 +
> 4 files changed, 55 insertions(+)
>
> diff --git a/drivers/base/power/power.h b/drivers/base/power/power.h
> index b6b8a27..0e62fb2 100644
> --- a/drivers/base/power/power.h
> +++ b/drivers/base/power/power.h
> @@ -33,6 +33,8 @@ extern int pm_qos_sysfs_add_resume_latency(struct device
> *dev);
> extern void pm_qos_sysfs_remove_resume_latency(struct device *dev);
> extern int pm_qos_sysfs_add_flags(struct device *dev);
> extern void pm_qos_sysfs_remove_flags(struct device *dev);
> +extern int pm_qos_sysfs_add_latency_tolerance(struct device *dev);
> +extern void pm_qos_sysfs_remove_latency_tolerance(struct device *dev);
>
> #else /* CONFIG_PM */
>
> diff --git a/drivers/base/power/qos.c b/drivers/base/power/qos.c
> index e56d538..7f3646e 100644
> --- a/drivers/base/power/qos.c
> +++ b/drivers/base/power/qos.c
> @@ -883,3 +883,40 @@ int dev_pm_qos_update_user_latency_tolerance(struct
> device *dev, s32 val)
> mutex_unlock(_pm_qos_mtx);
> return ret;
> }
> +
> +/**
> + * dev_pm_qos_expose_latency_tolerance - Expose latency tolerance to
> userspace
> + * @dev: Device whose latency tolerance to expose
> + */
> +int dev_pm_qos_expose_latency_tolerance(struct device *dev)
> +{
> + int ret;
> +
> + if (!dev->power.set_latency_tolerance)
> + return -EINVAL;
> +
> + mutex_lock(_pm_qos_sysfs_mtx);
> + ret = pm_qos_sysfs_add_latency_tolerance(dev);
> + mutex_unlock(_pm_qos_sysfs_mtx);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(dev_pm_qos_expose_latency_tolerance);
> +
> +/**
> + * dev_pm_qos_hide_latency_tolerance - Hide latency tolerance from userspace
> + * @dev: Device whose latency tolerance to hide
> + */
> +void dev_pm_qos_hide_latency_tolerance(struct device *dev)
> +{
> + mutex_lock(_pm_qos_sysfs_mtx);
> + pm_qos_sysfs_remove_latency_tolerance(dev);
> + mutex_unlock(_pm_qos_sysfs_mtx);
> +
> + /* Remove the request from user space now */
> + pm_runtime_get_sync(dev);
> + dev_pm_qos_update_user_latency_tolerance(dev,
> + PM_QOS_LATENCY_TOLERANCE_NO_CONSTRAINT);
> + pm_runtime_put(dev);
> +}
> +EXPORT_SYMBOL_GPL(dev_pm_qos_hide_latency_tolerance);
> diff --git a/drivers/base/power/sysfs.c b/drivers/base/power/sysfs.c
> index d2be3f9..a7b4679 100644
> --- a/drivers/base/power/sysfs.c
> +++ b/drivers/base/power/sysfs.c
> @@ -738,6 +738,17 @@ void pm_qos_sysfs_remove_flags(struct device *dev)
> sysfs_unmerge_group(>kobj, _qos_flags_attr_group);
> }
>
> +int pm_qos_sysfs_add_latency_tolerance(struct device *dev)
> +{
> + return sysfs_merge_group(>kobj,
> + _qos_latency_tolerance_attr_group);
> +}
> +
> +void pm_qos_sysfs_remove_latency_tolerance(struct device *dev)
> +{
> + sysfs_unmerge_group(>kobj, _qos_latency_tolerance_attr_group);
> +}
> +
> void rpm_sysfs_remove(struct device *dev)
> {
> sysfs_unmerge_group(>kobj, _runtime_attr_group);
> diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
> index 7b3ae0c..0f65d36 100644
> --- a/include/linux/pm_qos.h
> +++ b/include/linux/pm_qos.h
> @@ -161,6 +161,8 @@ void dev_pm_qos_hide_flags(struct device *dev);
> int dev_pm_qos_update_flags(struct device *dev, s32 mask, bool set);
> s32 dev_pm_qos_get_user_latency_tolerance(struct device *dev);
> int dev_pm_qos_update_user_latency_tolerance(struct device *dev, s32 val);
> +int dev_pm_qos_expose_latency_tolerance(struct device *dev);
> +void dev_pm_qos_hide_latency_tolerance(struct device *dev);
>
> static inline s32 dev_pm_qos_requested_resume_latency(struct device *dev)
> {
> @@ -229,6 +231,9 @@ static inline s32
> dev_pm_qos_get_user_latency_tolerance(struct device *dev)
> { return PM_QOS_LATENCY_TOLERANCE_NO_CONSTRAINT; }
> static inline int dev_pm_qos_update_user_latency_tolerance(struct device
> *dev, s32 val)
> { return 0; }
> +static inline int dev_pm_qos_expose_latency_tolerance(struct device *dev)
> + { return 0; }
> +static inline void
Re: [PATCH v5] ARM: smp: Only expose /sys/.../cpuX/online if hotpluggable
On 06/10/2015 03:57 PM, Russell King - ARM Linux wrote: > diff --git a/arch/arm/mach-shmobile/common.h b/arch/arm/mach-shmobile/common.h > index 476092b86c6e..f2c4bf437ea7 100644 > --- a/arch/arm/mach-shmobile/common.h > +++ b/arch/arm/mach-shmobile/common.h > @@ -13,7 +13,8 @@ extern void shmobile_smp_boot(void); > extern void shmobile_smp_sleep(void); > extern void shmobile_smp_hook(unsigned int cpu, unsigned long fn, > unsigned long arg); > -extern int shmobile_smp_cpu_disable(unsigned int cpu); > +extern bool shmobile_smp_cpu_can_disable(unsigned int cpu); > +extern void shmobile_invalidate_start(void); > > which your original patch did not include. The tree I'm applying to > (-rc1) contains: > > extern int shmobile_smp_cpu_disable(unsigned int cpu); > extern void shmobile_invalidate_start(void); > > there. Hence git quite rightfully declines to apply the patch. > Thanks. Fixed. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2 RESEND] power: reset: Add syscon poweroff device node for APM X-Gene platform
On Wed, Jun 10, 2015 at 12:13 PM, Dann Frazier
wrote:
> On Tue, Jun 9, 2015 at 9:31 AM, Dann Frazier
> wrote:
>> On Mon, Jun 8, 2015 at 10:34 PM, Tai Tri Nguyen wrote:
>>> Hi Dann,
>>>
>>> On Mon, Jun 8, 2015 at 8:44 PM, Dann Frazier
>>> wrote:
On Tue, Jun 2, 2015 at 1:19 PM, Tai Nguyen wrote:
> This patch adds syscon poweroff device node to support poweroff feature
> on APM X-Gene Mustang platform
hey Tai,
The reboot changes work just fine for me, but poweroff does not:
[ OK ] Reached target Final Step.
Starting Power-Off...
reboot: Power down
Unable to poweroff system
Kernel panic - not syncing: Attempted to kill init! exitcode=0x
CPU: 0 PID: 1 Comm: systemd-shutdow Tainted: GW 4.1.0-rc7+ #1
Hardware name: APM X-Gene Mustang board (DT)
Call trace:
[] dump_backtrace+0x0/0x11c
[] show_stack+0x10/0x1c
[] dump_stack+0x88/0xc8
[] panic+0xe0/0x220
[] do_exit+0x990/0x994
[] SyS_reboot+0x14c/0x208
---[ end Kernel panic - not syncing: Attempted to kill init!
exitcode=0x
-dann
>>>
>>> Thanks for testing my patches.
>>> On APM X-Gene Mustang platform, power off circuit is controlled by firmware.
>>> It requires a firmware update to support power off feature.
>>> May I ask what firmware version you're running on?
>>
>> Sure, 1.15.12.
>
> Tai worked with me offline. For reference, this requires an updated
> SlimPro firmware in addition to the u-boot update. Verified it works
> for me after the update, so:
>
> Tested-by: dann frazier
Looks good.
Acked-by: Moritz Fischer
>
>> -dann
>>
>>> Tai
>>>
>>>
> Signed-off-by: Tai Nguyen
> ---
> arch/arm64/boot/dts/apm/apm-mustang.dts | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/apm/apm-mustang.dts
> b/arch/arm64/boot/dts/apm/apm-mustang.dts
> index 83578e7..910d561 100644
> --- a/arch/arm64/boot/dts/apm/apm-mustang.dts
> +++ b/arch/arm64/boot/dts/apm/apm-mustang.dts
> @@ -23,6 +23,18 @@
> device_type = "memory";
> reg = < 0x1 0x 0x0 0x8000 >; /* Updated by
> bootloader */
> };
> +
> + poweroff_mbox: poweroff_mbox@10548000 {
> + compatible = "syscon";
> + reg = <0x0 0x10548000 0x0 0x30>;
> + };
> +
> + poweroff: poweroff@10548010 {
> + compatible = "syscon-poweroff";
> + regmap = <_mbox>;
> + offset = <0x10>;
> + mask = <0x1>;
> + };
> };
>
> {
> --
> 1.7.9.5
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>>>
>>>
>>> --
>>> Tai
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] ARM: smp: Only expose /sys/.../cpuX/online if hotpluggable
On Tue, Jun 09, 2015 at 12:08:28PM -0700, Stephen Boyd wrote: > On 04/13/2015 06:42 AM, Russell King - ARM Linux wrote: > > On Fri, Apr 10, 2015 at 03:33:11PM -0700, Stephen Boyd wrote: > >> Writes to /sys/.../cpuX/online fail if we determine the platform > >> doesn't support hotplug for that CPU. Furthermore, if the cpu_die > >> op isn't specified the system hangs when we try to offline a CPU > >> and it comes right back online unexpectedly. Let's figure this > >> stuff out before we make the sysfs nodes so that the online file > >> doesn't even exist if it isn't (at least sometimes) possible to > >> hotplug the CPU. > >> > >> Add a new 'cpu_can_disable' op and repoint all 'cpu_disable' > >> implementations at it because all implementers use the op to > >> indicate if a CPU can be hotplugged or not in a static fashion. > >> With PSCI we may need to add a 'cpu_disable' op so that the > >> secure OS can be migrated off the CPU we're trying to hotplug. > >> In this case, the 'cpu_can_disable' op will indicate that all > >> CPUs are hotpluggable by returning true, but the 'cpu_disable' op > >> will make a PSCI migration call and occasionally fail, denying > >> the hotplug of a CPU. This shouldn't be any worse than x86 where > >> we may indicate that all CPUs are hotpluggable but occasionally > >> we can't offline a CPU due to check_irq_vectors_for_cpu_disable() > >> failing to find a CPU to move vectors to. > >> > >> Cc: Mark Rutland > >> Cc: Nicolas Pitre > >> Cc: Dave Martin > >> Acked-by: Simon Horman [shmobile portion] > >> Tested-by: Simon Horman > >> Cc: Magnus Damm > >> Cc: > >> Cc: Tyler Baker > >> Cc: Geert Uytterhoeven > >> Signed-off-by: Stephen Boyd > > Let's see some more acks for this... > > > > Nobody else has acked this so far. Shall I put it in the patch tracker > now? Or is there someone more specific we need an ack from? The version you've put in the patch tracker is not the version you posted. It contains this change: diff --git a/arch/arm/mach-shmobile/common.h b/arch/arm/mach-shmobile/common.h index 476092b86c6e..f2c4bf437ea7 100644 --- a/arch/arm/mach-shmobile/common.h +++ b/arch/arm/mach-shmobile/common.h @@ -13,7 +13,8 @@ extern void shmobile_smp_boot(void); extern void shmobile_smp_sleep(void); extern void shmobile_smp_hook(unsigned int cpu, unsigned long fn, unsigned long arg); -extern int shmobile_smp_cpu_disable(unsigned int cpu); +extern bool shmobile_smp_cpu_can_disable(unsigned int cpu); +extern void shmobile_invalidate_start(void); which your original patch did not include. The tree I'm applying to (-rc1) contains: extern int shmobile_smp_cpu_disable(unsigned int cpu); extern void shmobile_invalidate_start(void); there. Hence git quite rightfully declines to apply the patch. Please fix. Thanks. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression in 3.10.80 vs. 3.10.79
On Tuesday, June 09, 2015 04:51:35 PM Roland Dreier wrote:
> On Tue, Jun 9, 2015 at 4:43 PM, Roland Dreier wrote:
> > I understand that the change here fixed another regression, but I'm
> > wondering if there's a way to make everyone happy here? I can provide
> > debugging info from my system as required...
>
> Maybe sent my mail too quickly, as I have some thoughts after looking
> at the code.
>
> From the link order, drivers/acpi init wll be called before
> drivers/pnp init, right? In my case, the acpi resources ("ACPI
> PM1a_EVT_BLK") etc are under a pnp bus. But if acpi requests the
> resources first, then pnp can't request the enclosing range.
>
> Is the right fix to make sure the pnp init happens before acpi
> requests resources?
I need to have a deeper look at things.
Can you please file a bug at bugzilla.kernel.org to track this and attach
the output of acpidump from the affected system in there?
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: socfpga: add smp_ops.cpu_kill to make kexec/kdump available
On 06/10/2015 02:47 AM, Hiraku Toyooka wrote: > Kexec_load syscall in ARM requires that machine-specific code > has the smp_ops.cpu_kill() before loading kernel image. > This patch adds the cpu_kill(), as a result, kexec reboot and > kernel crash dump become available in mach-socfpga. > > Signed-off-by: Hiraku Toyooka > Cc: Dinh Nguyen > Cc: Russell King > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-kernel@vger.kernel.org > --- > arch/arm/mach-socfpga/platsmp.c | 12 > 1 file changed, 12 insertions(+) > Applied! Thanks, Dinh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] irqchip: exynos-combiner: Save IRQ enable set on suspend
> "Javier" == Javier Martinez Canillas > writes: Javier> The Exynos interrupt combiner IP looses its state when the SoC s/looses/loses/ Peter C -- Dr Peter Chubb peter.chubb AT nicta.com.au http://www.ssrg.nicta.com.au Software Systems Research Group/NICTA -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI / init: Switch over platform to the ACPI mode later
On Wednesday, June 10, 2015 10:06:40 AM Hanjun Guo wrote: > On 06/10/2015 07:48 AM, Rafael J. Wysocki wrote: > > On Wednesday, June 03, 2015 11:13:57 AM Toshi Kani wrote: > >> On Sat, 2015-05-30 at 14:21 +0200, Rafael J. Wysocki wrote: > >>> From: Rafael J. Wysocki > >>> > >>> Commit 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before > >>> timekeeping_init()" moved the ACPI subsystem initialization, > >>> including the ACPI mode enabling, to an earlier point in the > >>> initialization sequence, to allow the timekeeping subsystem > >>> use ACPI early. Unfortunately, that resulted in boot regressions > >>> on some systems and the early ACPI initialization was moved toward > >>> its original position in the kernel initialization code by commit > >>> c4e1acbb35e4 "ACPI / init: Invoke early ACPI initialization later". > >>> > >>> However, that turns out to be insufficient, as boot is still broken > >>> on the Tyan S8812 mainboard. > >>> > >>> To fix that issue, split the ACPI early initialization code into > >>> two pieces so the majority of it still located in acpi_early_init() > >>> and the part switching over the platform into the ACPI mode goes into > >>> a new function, acpi_subsystem_init(), executed at the original early > >>> ACPI initialization spot. > >>> > >>> That fixes the Tyan S8812 boot problem, but still allows ACPI > >>> tables to be loaded earlier which is useful to the EFI code in > >>> efi_enter_virtual_mode(). > >>> > >>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=97141 > >>> Reported-and-tested-by: Marius Tolzmann > >>> Signed-off-by: Rafael J. Wysocki > >> > >> Can you add comments to acpi_early_init() and acpi_subsystem_init() to > >> clarify what ACPI features are enabled at each phase, and what > >> dependency they have in the boot sequence? (The same goes to > >> early_acpi_boot_init() and acpi_boot_init().) > > > > OK, update follows. > > > > --- > > From: Rafael J. Wysocki > > Subject: ACPI / init: Switch over platform to the ACPI mode later > > > > Commit 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before > > timekeeping_init()" moved the ACPI subsystem initialization, > > including the ACPI mode enabling, to an earlier point in the > > initialization sequence, to allow the timekeeping subsystem > > use ACPI early. Unfortunately, that resulted in boot regressions > > on some systems and the early ACPI initialization was moved toward > > its original position in the kernel initialization code by commit > > c4e1acbb35e4 "ACPI / init: Invoke early ACPI initialization later". > > > > However, that turns out to be insufficient, as boot is still broken > > on the Tyan S8812 mainboard. > > > > To fix that issue, split the ACPI early initialization code into > > two pieces so the majority of it still located in acpi_early_init() > > and the part switching over the platform into the ACPI mode goes into > > a new function, acpi_subsystem_init(), executed at the original early > > ACPI initialization spot. > > > > That fixes the Tyan S8812 boot problem, but still allows ACPI > > tables to be loaded earlier which is useful to the EFI code in > > efi_enter_virtual_mode(). > > > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=97141 > > Fixes: 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before > > timekeeping_init()" > > Reported-and-tested-by: Marius Tolzmann > > Signed-off-by: Rafael J. Wysocki > > Acked-by: Toshi Kani > > --- > > drivers/acpi/bus.c | 56 > > +-- > > include/linux/acpi.h |2 + > > init/main.c |1 > > 3 files changed, 44 insertions(+), 15 deletions(-) > > > > Index: linux-pm/drivers/acpi/bus.c > > === > > --- linux-pm.orig/drivers/acpi/bus.c > > +++ linux-pm/drivers/acpi/bus.c > > @@ -470,6 +470,16 @@ static int __init acpi_bus_init_irq(void > > return 0; > > } > > > > +/** > > + * acpi_early_init - Initialize ACPICA and populate the ACPI namespace. > > + * > > + * The ACPI tables are accessible after this, but the handling of events > > has not > > Maybe we need to explicitly say that it's DSDT/SSDT, because static > tables such as FADT and MADT are accessible in the very early stage > of boot (in setup_arch()). Well, it never says that none of the tables are accessible earlier. > Other than that, > > Reviewed-by: Hanjun Guo Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: clustered MD
On Wed, 10 Jun 2015 16:07:44 -0500 David Teigland wrote: > On Thu, Jun 11, 2015 at 06:31:31AM +1000, Neil Brown wrote: > > What is your interest in this? I'm always happy for open discussion and > > varied input, but it would help to know to what extent you are a stake > > holder? > > Using the dlm correctly is non-trivial and should be reviewed. > If the dlm is misused, some part of that may fall in my lap, if > only so far as having to debug problems to distinguish between dlm > bugs or md-cluster bugs. This has been learned the hard way. > > I have yet to find time to look up the previous review discussion. > I will be more than happy if I find the dlm usage has already been > thoroughly reviewed. The DLM usage is the part that I am least comfortable with and I would certainly welcome review. There was a recent discussion of some issue that I haven't had a chance to go over yet, but apart from that it has mostly just been a few developers trying to figure out what we need and how that can be implemented. There are (as I recall) two main aspects of the DLM usage. One is fairly idiomatic locking of the multiple write-intend bitmaps. Each bitmap can be "active" or "idle". When "idle" all bits are clear. When "active", one node will usually have an exclusive lock. If/when that node dies, all other nodes must find out and at least one takes remedial action. Once the remedial action is taken the bitmap becomes idle. In that state a new node can claim it. When that happens all other nodes must find out so they transition to the "watching an active bitmap" state. This seems to fit well with the shared/exclusive reclaimable locks of DLM. The other usage is to provide synchronous broadcast message passing between nodes. When one nodes makes a configuration change it needs to tell all other nodes and wait for them to acknowledge before the change (such as adding a spare) is committed. There is a small collections of locks which represent different states in a broadcast/acknowledge protocol. This is the part I'm least confident of, but it seems to make sense and seems to work. Separately: > Reading those messages again I see what you mean, they don't sound very > nice, so sorry about that. I'll repeat the one positive note, which is > that the brief things I've noticed make it look much better than the dm > approach from several years ago. Thanks :-) In part this effort is a response to "clvm" - which is a completely adequate solution of clustering when you just need volume management (growing and shrinking and striping volumes) but doesn't extend very well to RAID. Look forward to any review comments you find time for:-) Thanks, NeilBrown -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: rtl8192u: ieee80211: Fix sparse endianness warnings ieee80211_softmac.c
Fix the following endinness warnings detected by sparse:
drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:669:34: warning:
incorrect type in assignment (different base types)
drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:669:34:expected
restricted __le16 [usertype] duration_id
drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:669:34:got int
drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:679:33: warning:
incorrect type in assignment (different base types)
drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:679:33:expected
restricted __le16 [usertype] algorithm
drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:679:33:got int
drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:1090:32: warning:
incorrect type in assignment (different base types)
drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:1090:32:expected
restricted __le16 [usertype] duration_id
drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:1090:32:got int
drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:1109:30: warning:
incorrect type in assignment (different base types)
drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:1109:30:expected
restricted __le16 [usertype] listen_interval
drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:1109:30:got int
drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:3130:24: warning:
incorrect type in assignment (different base types)
drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:3130:24:expected
restricted __le16 [usertype] reason
drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:3130:24:got unsigned
char [unsigned] [usertype] asRsn
Signed-off-by: Gaston Gonzalez
---
drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
index b00f5fd..5fbade4 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
@@ -666,7 +666,7 @@ inline struct sk_buff *ieee80211_authentication_req(struct
ieee80211_network *be
else
auth->header.frame_ctl = cpu_to_le16(IEEE80211_STYPE_AUTH);
- auth->header.duration_id = 0x013a; //FIXME
+ auth->header.duration_id = cpu_to_le16(0x013a);
memcpy(auth->header.addr1, beacon->bssid, ETH_ALEN);
memcpy(auth->header.addr2, ieee->dev->dev_addr, ETH_ALEN);
@@ -676,7 +676,7 @@ inline struct sk_buff *ieee80211_authentication_req(struct
ieee80211_network *be
if(ieee->auth_mode == 0)
auth->algorithm = WLAN_AUTH_OPEN;
else if(ieee->auth_mode == 1)
- auth->algorithm = WLAN_AUTH_SHARED_KEY;
+ auth->algorithm = cpu_to_le16(WLAN_AUTH_SHARED_KEY);
else if(ieee->auth_mode == 2)
auth->algorithm = WLAN_AUTH_OPEN;//0x80;
printk("=>%s():auth->algorithm is
%d\n",__func__,auth->algorithm);
@@ -1087,7 +1087,7 @@ inline struct sk_buff *ieee80211_association_req(struct
ieee80211_network *beaco
hdr->header.frame_ctl = IEEE80211_STYPE_ASSOC_REQ;
- hdr->header.duration_id= 37; //FIXME
+ hdr->header.duration_id = cpu_to_le16(37);
memcpy(hdr->header.addr1, beacon->bssid, ETH_ALEN);
memcpy(hdr->header.addr2, ieee->dev->dev_addr, ETH_ALEN);
memcpy(hdr->header.addr3, beacon->bssid, ETH_ALEN);
@@ -1106,7 +1106,7 @@ inline struct sk_buff *ieee80211_association_req(struct
ieee80211_network *beaco
if (wmm_info_len) //QOS
hdr->capability |= cpu_to_le16(WLAN_CAPABILITY_QOS);
- hdr->listen_interval = 0xa; //FIXME
+ hdr->listen_interval = cpu_to_le16(0xa);
hdr->info_element[0].id = MFIE_TYPE_SSID;
@@ -3127,7 +3127,7 @@ inline struct sk_buff *ieee80211_disassociate_skb(
memcpy(disass->header.addr2, ieee->dev->dev_addr, ETH_ALEN);
memcpy(disass->header.addr3, beacon->bssid, ETH_ALEN);
- disass->reason = asRsn;
+ disass->reason = cpu_to_le16(asRsn);
return skb;
}
--
2.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Question about HighPoint RocketRAID 642L SCSI driver conflict with Linux AHCI driver
On Thu, 4 Jun 2015 13:05:49 +0800 "linux" wrote: > Dear Tejun Heo, > > This is HighPoint Linux Team. We found Linux AHCI driver since kernel 3.16 > has added ID (0x06421103) to support RocketRAID 642L which is not what we > expected. If we want to load HighPoint RR642L RAID version Linux SCSI > driver, it becomes conflict each other. This affects our customers who need > to use our RAID version driver stack. If your stack existed in full open source form upstream we might be able to add it the supported raid formats, which would make life even easier for your customers. > Hence, this is to ask Linux how to solve this conflict with AHCI driver? > and why Linux wants to add RR642L ID (0x06421103) into AHCI driver? So that users can use the hardware with the standard kernel AHCI drivers because they are best freely available and integrated driver available. > Is there > any way to prevent this in the future? Apart from having your customers reconfigure their kernel or carefully set stuff up at boot time, no. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 2/2] arm: use max_lowmem_limit in find_limit()
On Thu, Jun 11, 2015 at 02:59:33AM +0800, Min-Hua Chen wrote: > In commit: 1c2f87c22566cd057bc8cde10c37ae9da1a1bb76, the max_low is > set by memblock_get_current_limit(). However memblock.current_limit > can be changed by memblock_set_current_limit() any point before > find_limits(). > > It's better to use arm_lowmem_limit to be max_lowmem in two ways: > First, arm_lowmem_limit cannot be changed by a public API. Second, the > high_memory is set by arm_lowmem_limit and is a natural limit of > low memory area in bootmem_init(). > > Signed-off-by: Min-Hua Chen NAK, this is a known build breaker. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 1/2] arm: fix non-section-aligned low memory mapping
On Thu, Jun 11, 2015 at 02:59:32AM +0800, Min-Hua Chen wrote: > In current design, the memblock.current_limit is set to > a section-aligned value in sanity_check_meminfo(). > > However, the section-aligned memblock may become non-section-aligned > after arm_memblock_init(). For example, the first section-aligned > memblock is 0x-0x0100 and sanity_check_meminfo sets > current_limit to 0x0100. After arm_memblock_init, two memory blocks > [0x00c0 - 0x00d0] and [0x00ff - 0x0100] are reserved > by memblock_reserve() and make the original memory block > [0x-0x0100] becomes: There isn't a problem with memblock_reserve(). That just marks the memory as reserved, it doesn't steal the memory from the lowmem mappings - in fact, it is still expected that reserved memory claimed in this way will be mapped. Somehow, I don't think this is what you're doing though, because you go on to describe a problem which can only happen if you steal memory after arm_memblock_init() has returned. Don't do this. There is a specific point in the boot sequence where you are permitted to steal memory, which is done inside arm_memblock_init(). Stealing outside of that is not permitted. arm_memblock_steal() is written to BUG_ON() if you attempt to do this outside of the permissible code paths. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/asm/entry/32, selftests: Add test_syscall_vdso test
On Wed, 10 Jun 2015 22:15:58 +0200
Denys Vlasenko wrote:
> On 06/10/2015 10:00 PM, Kees Cook wrote:
> >> + printf("[SKIP]\tAT_SYSINFO not supplied, can't test\n");
> >> + exit(0); /* this is not a test failure */
> >
> > Why is that not a test failure? It would mean it didn't actually test
> > anything, which seems like a failure to me.
>
> Are you objecting to comment wording, or to exiting with 0?
>
> I exit with 0 because no bug was detected.
I believe there's a way to exit with "not supported". That's what the
ftrace tests do.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
