[PATCH v2 0/7] Switch mach-at91 to multiplatform
AT91 is now ready to switch to multiplatform. Do it and clean the remaining mach includes. Changes in v2: - moved the bool for ARCH_AT91 to the top - added a patch to remove the sama5d4 map_io Alexandre Belloni (7): ARM: at91: switch to multiplatform ARM: at91: switch at91_dt_defconfig to multiplatform ARM: at91: remove unused headers ARM: at91: remove useless mach/cpu.h ARM: at91: sama5d4: remove useless map_io ARM: at91: remove SoC headers ARM: at91: remove hardware.h arch/arm/Kconfig | 13 -- arch/arm/configs/at91_dt_defconfig | 5 +- arch/arm/mach-at91/Kconfig | 117 ++--- arch/arm/mach-at91/Makefile| 2 + arch/arm/mach-at91/include/mach/at91_dbgu.h| 63 --- arch/arm/mach-at91/include/mach/at91rm9200.h | 103 arch/arm/mach-at91/include/mach/at91sam9260.h | 129 --- arch/arm/mach-at91/include/mach/at91sam9261.h | 99 --- arch/arm/mach-at91/include/mach/at91sam9263.h | 117 - arch/arm/mach-at91/include/mach/at91sam9_smc.h | 2 - arch/arm/mach-at91/include/mach/at91sam9g45.h | 143 arch/arm/mach-at91/include/mach/at91sam9n12.h | 65 arch/arm/mach-at91/include/mach/at91sam9rl.h | 105 arch/arm/mach-at91/include/mach/at91sam9x5.h | 71 arch/arm/mach-at91/include/mach/cpu.h | 216 arch/arm/mach-at91/include/mach/hardware.h | 134 --- arch/arm/mach-at91/include/mach/sama5d3.h | 86 -- arch/arm/mach-at91/include/mach/sama5d4.h | 33 arch/arm/mach-at91/include/mach/uncompress.h | 218 - arch/arm/mach-at91/pm.c| 12 +- arch/arm/mach-at91/pm_slowclock.S | 1 - arch/arm/mach-at91/sama5.c | 35 22 files changed, 75 insertions(+), 1694 deletions(-) delete mode 100644 arch/arm/mach-at91/include/mach/at91_dbgu.h delete mode 100644 arch/arm/mach-at91/include/mach/at91rm9200.h delete mode 100644 arch/arm/mach-at91/include/mach/at91sam9260.h delete mode 100644 arch/arm/mach-at91/include/mach/at91sam9261.h delete mode 100644 arch/arm/mach-at91/include/mach/at91sam9263.h delete mode 100644 arch/arm/mach-at91/include/mach/at91sam9g45.h delete mode 100644 arch/arm/mach-at91/include/mach/at91sam9n12.h delete mode 100644 arch/arm/mach-at91/include/mach/at91sam9rl.h delete mode 100644 arch/arm/mach-at91/include/mach/at91sam9x5.h delete mode 100644 arch/arm/mach-at91/include/mach/cpu.h delete mode 100644 arch/arm/mach-at91/include/mach/hardware.h delete mode 100644 arch/arm/mach-at91/include/mach/sama5d3.h delete mode 100644 arch/arm/mach-at91/include/mach/sama5d4.h delete mode 100644 arch/arm/mach-at91/include/mach/uncompress.h -- 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/
Re: [PATCH] perf/tui: Change default selection background color to yellow
* Arnaldo Carvalho de Melo a...@infradead.org wrote: Em Thu, Mar 05, 2015 at 11:32:13AM +0100, Ingo Molnar escreveu: Boris reported that 'perf top' is unusable on his default 'black on white' terminal, which uses (eye friendly) light-grey as a background color. The reason is that the TUI cursor for the current selection line uses HE_COLORSET_SELECTED, and that has a default background color of 'lightgrey' - which is a common terminal background choice and thus the colors conflict. Use yellow as the background color instead: that should be an uncommon terminal background, yet it's still ergonomic on both black and white/grey terminals. [ It would be a better solution to straight out detect color collisions and resolve them reasonably by converting them to RGB and calculating color space distances, but I was unable to find proper documentation for SLtt_get_color_object() to recover the current color scheme so I gave up ... Yellow works well enough. ] Thanks, applying. BTW, I started with newt, thinking it would give me good widgets, only to, after having reached its limitations write my own, this time just on, like newt, top of slang's tui libraries, eventually I think I'll move to ncurses or even just use the kernel tty interface directly ;-) LOL! :-) Btw., a related problem: X terminals are pretty high overhead unfortunately, I cringe every time I run 'perf top' on a very fast system: PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 4240 mingo 20 0 1031088 176112 106648 S 5.9 0.3 101:54.30 konsole 1985 root 20 0 649412 194760 157464 S 3.0 0.3 41:49.94 Xorg 2395 mingo 20 0 2283956 526044 127108 S 2.0 0.8 34:40.23 compiz 13258 mingo 20 0 207588 70916 12112 S 1.3 0.1 0:03.01 perf 10%+ of GUI CPU overhead with a refresh every 2 seconds (i.e. only 0.5 fps) - ridiculous! So to fix this I think we eventually want a raw OpenGL client for local system 'perf top' use and such: that would be (by far) the lowest overhead UI interface to run profiling from without disturbing the system, with UI overhead in the ~1% range at most. Raw (no toolkits) OpenGL would also allow us to do a lot of other UI and performance tricks. Would you have any fundamental objections against OpenGL UI clients? Thanks, Ingo -- 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 5/7] ARM: at91: sama5d4: remove useless map_io
All the peripheral remapped at io_map are taken care of by their respective
drivers.
Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
---
arch/arm/mach-at91/sama5.c | 33 -
1 file changed, 33 deletions(-)
diff --git a/arch/arm/mach-at91/sama5.c b/arch/arm/mach-at91/sama5.c
index 26b718a0c235..d7593d572a77 100644
--- a/arch/arm/mach-at91/sama5.c
+++ b/arch/arm/mach-at91/sama5.c
@@ -89,38 +89,6 @@ DT_MACHINE_START(sama5_dt, Atmel SAMA5)
.dt_compat = sama5_dt_board_compat,
MACHINE_END
-static struct map_desc at91_io_desc[] __initdata = {
- {
- .virtual= (unsigned long)AT91_ALT_IO_P2V(SAMA5D4_BASE_MPDDRC),
- .pfn= __phys_to_pfn(SAMA5D4_BASE_MPDDRC),
- .length = SZ_512,
- .type = MT_DEVICE,
- },
- {
- .virtual= (unsigned long)AT91_ALT_IO_P2V(SAMA5D4_BASE_PMC),
- .pfn= __phys_to_pfn(SAMA5D4_BASE_PMC),
- .length = SZ_512,
- .type = MT_DEVICE,
- },
- { /* On sama5d4, we use USART3 as serial console */
- .virtual= (unsigned long)AT91_ALT_IO_P2V(SAMA5D4_BASE_USART3),
- .pfn= __phys_to_pfn(SAMA5D4_BASE_USART3),
- .length = SZ_256,
- .type = MT_DEVICE,
- },
- { /* A bunch of peripheral with fine grained IO space */
- .virtual= (unsigned long)AT91_ALT_IO_P2V(SAMA5D4_BASE_SYS2),
- .pfn= __phys_to_pfn(SAMA5D4_BASE_SYS2),
- .length = SZ_2K,
- .type = MT_DEVICE,
- },
-};
-
-static void __init sama5_alt_map_io(void)
-{
- iotable_init(at91_io_desc, ARRAY_SIZE(at91_io_desc));
-}
-
static const char *sama5_alt_dt_board_compat[] __initconst = {
atmel,sama5d4,
NULL
@@ -128,7 +96,6 @@ static const char *sama5_alt_dt_board_compat[] __initconst =
{
DT_MACHINE_START(sama5_alt_dt, Atmel SAMA5)
/* Maintainer: Atmel */
- .map_io = sama5_alt_map_io,
.init_machine = sama5_dt_device_init,
.dt_compat = sama5_alt_dt_board_compat,
.l2c_aux_mask = ~0UL,
--
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/
Re: [PATCH v2 2/2] livepatch/module: Correctly handle going modules
On Thu, Mar 05, 2015 at 04:45:14PM +0100, Petr Mladek wrote:
Existing live patches are removed from going modules using a notify handler.
There are two problems with the current implementation.
First, new patch could still see the module in the GOING state even after
the notifier has been called. It will try to initialize the related
object structures but the module could disappear at any time. There will
stay mess in the structures. It might even cause an invalid memory access.
Second, if we start supporting patches with semantic changes between function
calls, we would need to apply any new patch even for going modules. Note that
the code from the module could be called even in the GOING state until
mod-exit() finishes. See below for example.
This patch solves the problem by adding boolean flag into struct module.
It is switched when the going module handler is called. It marks the point
when it is safe and we actually have to ignore the going module.
Alternative solutions:
We could add another lock to make the switch to GOING state and mod-exit()
call an atomic operation. But this a nogo. It might cause a dead lock when
some mod-exit() depends on mod-exit() from another module.
We could wait until the GOING module is moved to the UNFORMED state.
But this might take ages when mod-exit() has to wait for something.
We could refuse to load the patch when a module is going but this is
pretty ugly.
Example of the race:
CPU0 CPU1
delete_module() #SYSCALL
try_stop_module()
mod-state = MODULE_STATE_GOING;
mutex_unlock(module_mutex);
klp_register_patch()
klp_enable_patch()
#save place to switch universe
b() # from module that is going
a() # from core (patched)
mod-exit();
Note that the function b() can be called until we call mod-exit().
If we do not apply patch against b() because it is in MODULE_STATE_GOING.
It will call patched a() with modified semantic and things might get wrong.
Signed-off-by: Petr Mladek pmla...@suse.cz
---
include/linux/module.h | 4
kernel/livepatch/core.c | 30 ++
2 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index b653d7c0a05a..c12f93497b74 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -344,6 +344,10 @@ struct module {
unsigned long *ftrace_callsites;
#endif
+#ifdef CONFIG_LIVEPATCH
+ bool klp_gone;
+#endif
+
#ifdef CONFIG_MODULE_UNLOAD
/* What modules depend on me? */
struct list_head source_list;
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index 198f7733604b..0b38357fad0f 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -89,16 +89,32 @@ static bool klp_is_object_loaded(struct klp_object *obj)
/* sets obj-mod if object is not vmlinux and module is found */
static void klp_find_object_module(struct klp_object *obj)
{
+ struct module *mod;
+
if (!klp_is_module(obj))
return;
mutex_lock(module_mutex);
+
+ /*
+ * We do not want to block removal of patched modules and therefore
+ * we do not take a reference here. Instead, the patches are removed
+ * by the going module handler instead.
+ */
Redundant instead.
--
Josh
--
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 6/9] ARM: at91: time: move the system timer driver to drivers/clocksource
On Thu, 2015-03-05 at 16:49 +0100, Alexandre Belloni wrote: diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig index 1c2506f68122..d1d15985a4ec 100644 --- a/drivers/clocksource/Kconfig +++ b/drivers/clocksource/Kconfig @@ -138,6 +138,10 @@ config ATMEL_PIT select CLKSRC_OF if OF def_bool SOC_AT91SAM9 || SOC_SAMA5 +config ATMEL_ST + select CLKSRC_OF if OF + def_bool SOC_AT91RM9200 If you swap these two lines you'll make the set of people that probably only includes me a bit happier. + config CLKSRC_METAG_GENERIC def_bool y if METAG help Thanks, Paul Bolle -- 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] of: Kconfig: Let OF_UNITTEST depend on I2C=y and I2C_MUX=y
On Wed, Mar 4, 2015 at 1:58 PM, Pantelis Antoniou pantelis.anton...@konsulko.com wrote: Hi Arnd, On Mar 4, 2015, at 21:49 , Arnd Bergmann a...@arndb.de wrote: On Wednesday 04 March 2015 16:04:23 Geert Uytterhoeven wrote: - depends on OF_IRQ OF_EARLY_FLATTREE + depends on OF_IRQ OF_EARLY_FLATTREE I2C=y I2C_MUX=y ... I think it would be better to replace #if IS_ENABLED(CONFIG_XXX) by #ifdef CONFIG_XXX in drivers/of/unittest.c instead. Agreed. I came across the same bug and came to the same conclusion as you. How about this: 8 Subject: of: unittest: fix I2C dependency [...] -#if IS_ENABLED(CONFIG_I2C) +#if IS_BUILTIN(CONFIG_I2C) if (selftest(of_selftest_overlay_i2c_init() == 0, i2c init failed\n)) goto out; Patch is fine. I’ll pick it up for the next batch of overlay patches. Do you have other things that need to go into 4.0? If not I'll pick this up. Rob -- 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] do_fork(): Rename 'stack_size' argument to reflect actual use
On Thu, 5 Mar 2015, Alex Dowad wrote:
diff --git a/kernel/fork.c b/kernel/fork.c
index cf65139..b38a2ae 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1186,10 +1186,12 @@ init_task_pid(struct task_struct *task, enum
pid_type type, struct pid *pid)
* It copies the registers, and all the appropriate
* parts of the process environment (as per the clone
* flags). The actual kick-off is left to the caller.
+ *
+ * When copying a kernel thread, 'stack_start' is the function to run.
*/
static struct task_struct *copy_process(unsigned long clone_flags,
unsigned long stack_start,
- unsigned long stack_size,
+ unsigned long kthread_arg,
int __user *child_tidptr,
struct pid *pid,
int trace)
@@ -1401,7 +1403,7 @@ static struct task_struct *copy_process(unsigned
long clone_flags,
retval = copy_io(clone_flags, p);
if (retval)
goto bad_fork_cleanup_namespaces;
- retval = copy_thread(clone_flags, stack_start, stack_size, p);
+ retval = copy_thread(clone_flags, stack_start, kthread_arg, p);
if (retval)
goto bad_fork_cleanup_io;
@@ -1629,8 +1631,8 @@ struct task_struct *fork_idle(int cpu)
* it and waits for it to finish using the VM if required.
*/
long do_fork(unsigned long clone_flags,
- unsigned long stack_start,
- unsigned long stack_size,
+ unsigned long stack_start, /* or function for kthread to run */
+ unsigned long kthread_arg,
int __user *parent_tidptr,
int __user *child_tidptr)
{
Looks fine, but I'm not sure about commenting functional formals. Since
copy_process() and do_fork() can have formals with different meanings,
then why not just rename them arg1 and arg2 respectively and then
define in the comment above the function what the possible combinations
are?
The second argument is *only* ever used for one thing: an argument passed to a
kernel thread. That's why I would like to rename it to kthread_arg. The
previous argument (currently named stack_start) is indeed used for 2
different things: a new stack pointer for a user thread, or a function to be
executed by a kernel thread. Rather than arg1, what would you think of
something like sp_or_fn, or usp_or_fn?
I would recommend exactly arg since it can be used for multiple purposes
and if the formal could ever be used for a third purpose we don't want to
go through another re-naming patch to change it from sp_or_fn or
usp_or_fn.
If that's done, then the comment above the function could define what arg
can represent.
--
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 4/9] power: reset: Add AT91RM9200 reset driver
On 05/03/2015 at 20:49:14 +0100, Paul Bolle wrote :
On Thu, 2015-03-05 at 16:49 +0100, Alexandre Belloni wrote:
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -30,6 +30,13 @@ config POWER_RESET_AT91_RESET
This driver supports restart for Atmel AT91SAM9 and SAMA5
SoCs
+config POWER_RESET_AT91RM9200_RESET
+ bool Atmel AT91RM9200 reset driver
This adds a bool symbol.
+ depends on ARCH_AT91 MFD_SYSCON
+ default SOC_AT91RM9200
+ help
+ This driver supports restart for Atmel AT91RM9200.
+
config POWER_RESET_AXXIA
bool LSI Axxia reset driver
depends on ARCH_AXXIA
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index 11de15bae52e..96e972bbb922 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -1,6 +1,7 @@
obj-$(CONFIG_POWER_RESET_AS3722) += as3722-poweroff.o
obj-$(CONFIG_POWER_RESET_AT91_POWEROFF) += at91-poweroff.o
obj-$(CONFIG_POWER_RESET_AT91_RESET) += at91-reset.o
+obj-$(CONFIG_POWER_RESET_AT91RM9200_RESET) += at91rm9200-reset.o
This objectfile will never be modular.
obj-$(CONFIG_POWER_RESET_AXXIA) += axxia-reset.o
obj-$(CONFIG_POWER_RESET_BRCMSTB) += brcmstb-reboot.o
obj-$(CONFIG_POWER_RESET_GPIO) += gpio-poweroff.o
diff --git a/drivers/power/reset/at91rm9200-reset.c
b/drivers/power/reset/at91rm9200-reset.c
new file mode 100644
index ..b739ac82b9c9
--- /dev/null
+++ b/drivers/power/reset/at91rm9200-reset.c
@@ -0,0 +1,72 @@
+#include linux/module.h
Is this needed?
+static struct platform_driver at91rm9200_reset_driver = {
+ .probe = at91rm9200_reset_probe,
+ .driver = {
+ .name = at91rm9200-reset,
+ .of_match_table = at91rm9200_reset_of_match,
+ },
+};
+module_platform_driver(at91rm9200_reset_driver);
This should, perhaps, be replaced by a wrapper that calls
platform_driver_register(at91rm9200_reset_driver)
while that wrapper is, well, called through
device_initcall()
or something similar. I didn't test this suggestion.
+MODULE_ALIAS(platform:at91rm9200-reset);
+MODULE_AUTHOR(Alexandre Belloni alexandre.bell...@free-electrons.com);
+MODULE_DESCRIPTION(Atmel at91rm9200 System Timer Reset driver);
+MODULE_LICENSE(GPL v2);
All these macros will be, basically, preprocessed away.
Indeed, a lot got cargo culted/copy-pasted. I'll fix it and the
at91-reset driver too.
Thanks!
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
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] mm: pagewalk: prevent positive return value of walk_page_test() from being passed to callers (Re: [PATCH] mm: fix do_mbind return value)
On Thu, 5 Mar 2015, Naoya Horiguchi wrote: walk_page_test() is purely pagewalk's internal stuff, and its positive return values are not intended to be passed to the callers of pagewalk. However, in the current code if the last vma in the do-while loop in walk_page_range() happens to return a positive value, it leaks outside walk_page_range(). So the user visible effect is invalid/unexpected return value (according to the reporter, mbind() causes it.) This patch fixes it simply by reinitializing the return value after checked. Another exposed interface, walk_page_vma(), already returns 0 for such cases so no problem. Fixes: 6f4576e3687b (mempolicy: apply page table walker on queue_pages_range()) Reported-by: Kazutomo Yoshii kazutomo.yos...@gmail.com Signed-off-by: Naoya Horiguchi n-horigu...@ah.jp.nec.com Acked-by: David Rientjes rient...@google.com This is exactly what I had in mind, thanks for fixing it up so fast! -- 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/8] pmem: Initial version of persistent memory driver
For what it's worth, at this moment, I found a license nit. On Thu, 2015-03-05 at 13:55 +0200, Boaz Harrosh wrote: --- /dev/null +++ b/drivers/block/pmem.c @@ -0,0 +1,334 @@ +/* + * Persistent Memory Driver + * Copyright (c) 2014, Intel Corporation. + * Copyright (c) 2014, Boaz Harrosh b...@plexistor.com. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms and conditions of the GNU General Public License, + * version 2, as published by the Free Software Foundation. + * + * This program is distributed in the hope 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. This states the license is GPL v2. +MODULE_LICENSE(GPL); So you probably want MODULE_LICENSE(GPL v2); here. Paul Bolle -- 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] toshiba_acpi: Add Satellite P50W-B to alternative keymap and create new mappings.
On 03/04/2015 07:05 PM, Azael Avalos wrote:
Hi there,
2015-03-04 14:52 GMT-07:00 Joseph Salisbury joseph.salisb...@canonical.com:
...
+ { KE_KEY, 0x140, { KEY_BRIGHTNESSDOWN } },
+ { KE_KEY, 0x141, { KEY_BRIGHTNESSUP } },
...
These two are not neccesary, as they may collide with previous song
and playpause in case Toshiba (or its manufacturers) decide to use
those keys.
If you can, please test the first two patches from the gmane archive [1],
they eliminate the need of the DMI matching list. And it would be great
to have more laptops tested.
[1] http://comments.gmane.org/gmane.linux.drivers.platform.x86.devel/6602
Cheers
Azael
Hi Azael,
There is some positive feedback with the first two patches:
toshiba_acpi: Add Hotkey Event Type function and definitions
toshiba_acpi: Use the Hotkey Event Type function for keymap choosing
$ uname -r
4.0.0-04rc2-generic
$ acpi_listen
video/brightnessdown BRTDN 0087
video/brightnessup BRTUP 0086
video/switchmode VMOD 0080 K
cd/prev CDPREV 0080 K
cd/play CDPLAY 0080 K
cd/next CDNEXT 0080 K
button/volumedown VOLDN 0080 K
button/volumeup VOLUP 0080 K
button/mute MUTE 0080 K
button/mute MUTE 0080 K
button/wlan WLAN 0080 K
button/volumedown VOLDN 0080 K
button/volumeup VOLUP 0080 K
Can you also cc this patch to stable when submitting it to mainline?
All the keys are working and the patch is allot cleaner!
Thanks again,
Joe
--
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] pci: host: xgene: fix incorrectly returned address by map_bus
On Thu, Mar 5, 2015 at 10:38 AM, Bjorn Helgaas bhelg...@google.com wrote:
[+cc Mark]
On Thu, Feb 26, 2015 at 06:21:51PM -0600, Bjorn Helgaas wrote:
On Tue, Feb 17, 2015 at 03:14:00PM -0800, Feng Kan wrote:
The generic accessor functions for pci-xgene uses map_bus
call that returns the base address but did not add the additional
offset.
Signed-off-by: Feng Kan f...@apm.com
---
drivers/pci/host/pci-xgene.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/host/pci-xgene.c b/drivers/pci/host/pci-xgene.c
index aab5547..ee082c0 100644
--- a/drivers/pci/host/pci-xgene.c
+++ b/drivers/pci/host/pci-xgene.c
@@ -127,7 +127,7 @@ static bool xgene_pcie_hide_rc_bars(struct pci_bus
*bus, int offset)
return false;
}
-static int xgene_pcie_map_bus(struct pci_bus *bus, unsigned int devfn,
+static void __iomem *xgene_pcie_map_bus(struct pci_bus *bus, unsigned int
devfn,
int offset)
{
struct xgene_pcie_port *port = bus-sysdata;
@@ -137,7 +137,7 @@ static int xgene_pcie_map_bus(struct pci_bus *bus,
unsigned int devfn,
return NULL;
xgene_pcie_set_rtdid_reg(bus, devfn);
- return xgene_pcie_get_cfg_base(bus);
+ return xgene_pcie_get_cfg_base(bus) + offset;
Where's the locking here? ECAM doesn't need locking because the
bus/dev/fn/offset is all encoded in the MMIO address. But it looks
like X-Gene doesn't work that way and bus/dev/fn is in the RTDID register.
So it seems like X-Gene needs locking that not everybody needs. Are you
relying on higher-level locking somewhere?
Ping, what's going on here? I've gotten at least three patches for this
offset issue, so we need to get it resolved.
If there's no locking problem, I can just apply this and we'll be finished.
Actually, I think Mark's patch is better, because it correctly returns NULL
(failure) if xgene_pcie_get_cfg_base() fails. So please review and ack
that one or explain why this one is better.
But if there *is* a locking problem, we should fix that, too. That should
be a separate patch, so I guess I can apply the one to fix the offset
problem first, and we'll at least be no worse off with respect to locking
than we are today.
There's no locking problem. The config accesses are all within the
pci_lock spinlock and nothing else touches that register.
Rob
--
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] x86/PCI: Fully disable devices before releasing IRQ resource
The IRQ resource for a device is established when pci_enabled_device()
is called on a fully disabled device (ie. enable_cnt == 0). With
commit b4b55cda5874 (x86/PCI: Refine the way to release PCI IRQ
resources) this same IRQ resource is released when the driver is
unbound from the device, regardless of the enable_cnt. This presents
the situation that an ill-behaved driver can now make a device
unusable to subsequent drivers by an imbalance in their use of
pci_enable/disable_device(). It's one thing to break your own device
if you're one of these ill-behaved drivers, but it's a serious
regression for secondary drivers like vfio-pci, which are innocent
of the transgressions of the previous driver.
Resolve by pushing the device to a fully disabled state before
releasing the IRQ resource.
Fixes: b4b55cda5874 (x86/PCI: Refine the way to release PCI IRQ resources)
Signed-off-by: Alex Williamson alex.william...@redhat.com
Cc: Jiang Liu jiang@linux.intel.com
---
arch/x86/pci/common.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 3d2612b..4810194 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -527,8 +527,19 @@ static int pci_irq_notifier(struct notifier_block *nb,
unsigned long action,
if (action != BUS_NOTIFY_UNBOUND_DRIVER)
return NOTIFY_DONE;
- if (pcibios_disable_irq)
+ if (pcibios_disable_irq) {
+ /*
+* Broken drivers may allow a device to be .remove()'d while
+* still enabled. pci_enable_device() will only re-establish
+* dev-irq if the devices is fully disabled. So if we want
+* to release the IRQ, we need to make sure the next driver
+* can re-establish it using pci_enable_device().
+*/
+ while (pci_is_enabled(dev))
+ pci_disable_device(dev);
+
pcibios_disable_irq(dev);
+ }
return NOTIFY_OK;
}
--
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 0/9] Support follow_link in RCU-walk.
On Thu, 5 Mar 2015 06:05:20 + Al Viro v...@zeniv.linux.org.uk wrote:
On Thu, Mar 05, 2015 at 04:21:21PM +1100, NeilBrown wrote:
Hi Al (and others),
I wonder if you could look over this patchset.
It allows RCU-walk to follow symlinks in many common cases,
thus removing a surprising performance hit caused by using symlinks.
The last could of patches make changes to XFS and NFS to support
this but I haven't forwarded to the relevant lists yet.
If/when the early code meets with approval I'll do that.
The first patch almost certainly needs to be changed. I originally
wrote this code when filesystems could see inside nameidata.
It is now opaque so the simplest solution was to provide an
accessor function.
Maybe I should as a 'flags' arg to -follow_link?? Or have
-follow_link and -follow_link_rcu ??
What do you suggest?
Umm... Some observations:
* now -follow_link() can be called in RCU mode, which means
that it can race with fs shutdown; not a problem, except that now it
joins -lookup() et.al. in if some data structure is needed in RCU
case of that, make sure it's not destroyed without an RCU delay somewhere
between the entry into -kill_sb() and destruction.
* highmem pages in symlinks: that BS shouldn't be allowed at
all. Just make sure that at least for those filesystems symlink inodes
get mapping_set_gfp_mask(inode-i_data, GFP_KERNEL) and be done with that.
* are you sure that security_inode_follow_link() is OK to call in
RCU mode?
* what warranties are you giving for the lifetime of strings
passed to nd_set_link()? Right now it's should not be freed until the
matching -put_link(); what happens for RCU mode?
* really nasty one: creat(2) on a dangling symlink. What's to
preserve the last component if you get into that symlink in RCU mode?
TBH, I'm less than fond of passing nameidata to -follow_link() at all,
flags or no flags. We could kill current-link_count and
current-total_link_count, replacing them with one void * current-nameidata
and taking counters into struct nameidata itself. Have places like e.g.
kern_path_locked() do
struct nameidata nd, *saved = set_nameidata(nd);
...
set_nameidata(saved);
with set_nameidata(p) doing this:
old = current-nameidata;
current-nameidata = p;
if (p) {
if (!old) {
p-link_count = 0;
p-total_link_count = 0;
} else {
p-link_count = old-link_count;
p-total_link_count = old-total_link_count;
}
}
return old;
Then nd_set_link() et.al. would use current-nameidata instead of an
explicitly passed pointer and -follow_link() instances wouldn't need
that opaque pointer passed to them at all.
Wow, thanks for the quick response!!!
I'll look into all those issues and get back to you when I have something
coherent to say.
NeilBrown
pgp_fcu9BHu14.pgp
Description: OpenPGP digital signature
Re: [PATCH] f2fs: fix to truncate inline data past EOF
Hi Chao,
On Thu, Mar 05, 2015 at 05:41:32PM +0800, Chao Yu wrote:
Previously if inode is with inline data, we will try to invalid partial inline
data in page #0 when we truncate size of inode in
truncate_partial_data_page().
And then we set page #0 to dirty, after this we can synchronize inode page
with
page #0 at -writepage().
But sometimes we will fail to operate page #0 in truncate_partial_data_page()
due to below reason:
a) if offset is zero, we will skip setting page #0 to dirty.
b) if page #0 is not uptodate, we will fail to update it as it has no mapping
data.
So with following operations, we will meet recent data which should be
truncated.
1.write inline data to file
2.sync first data page to inode page
3.truncate file size to 0
4.truncate file size to max_inline_size
5.echo 1 /proc/sys/vm/drop_caches
6.read file -- meet original inline data which is remained in inode page.
This patch renames truncate_inline_data() to truncate_inline_inode() for code
readability, then intruduces new truncate_inline_data() and use it to truncate
inline data in page #0 and inode page in truncate_partial_data_page() for
fixing.
Signed-off-by: Chao Yu chao2...@samsung.com
---
fs/f2fs/f2fs.h | 1 +
fs/f2fs/file.c | 13 -
fs/f2fs/inline.c | 57
+++-
3 files changed, 61 insertions(+), 10 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 511d6cd..55dbbe7 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1754,6 +1754,7 @@ extern struct kmem_cache *inode_entry_slab;
*/
bool f2fs_may_inline(struct inode *);
void read_inline_data(struct page *, struct page *);
+int truncate_inline_data(struct inode *, u64 from);
int f2fs_read_inline_data(struct inode *, struct page *);
int f2fs_convert_inline_page(struct dnode_of_data *, struct page *);
int f2fs_convert_inline_inode(struct inode *);
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index f1341c7..6c4443e 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -461,6 +461,9 @@ static int truncate_partial_data_page(struct inode
*inode, u64 from)
unsigned offset = from (PAGE_CACHE_SIZE - 1);
struct page *page;
+ if (f2fs_has_inline_data(inode))
+ return 0;
+
if (!offset)
return 0;
@@ -497,14 +500,14 @@ int truncate_blocks(struct inode *inode, u64 from, bool
lock)
if (lock)
f2fs_lock_op(sbi);
- ipage = get_node_page(sbi, inode-i_ino);
- if (IS_ERR(ipage)) {
- err = PTR_ERR(ipage);
+ if (f2fs_has_inline_data(inode)) {
+ err = truncate_inline_data(inode, from);
goto out;
}
- if (f2fs_has_inline_data(inode)) {
- f2fs_put_page(ipage, 1);
+ ipage = get_node_page(sbi, inode-i_ino);
+ if (IS_ERR(ipage)) {
+ err = PTR_ERR(ipage);
goto out;
}
diff --git a/fs/f2fs/inline.c b/fs/f2fs/inline.c
index 4ba9732..a8189c92 100644
--- a/fs/f2fs/inline.c
+++ b/fs/f2fs/inline.c
@@ -50,10 +50,57 @@ void read_inline_data(struct page *page, struct page
*ipage)
SetPageUptodate(page);
}
-static void truncate_inline_data(struct page *ipage)
+static void truncate_inline_inode(struct page *ipage, u64 from)
{
+ void *addr = inline_data_addr(ipage);
+
f2fs_wait_on_page_writeback(ipage, NODE);
- memset(inline_data_addr(ipage), 0, MAX_INLINE_DATA);
+ memset(addr + from, 0, MAX_INLINE_DATA - from);
+}
+
+int truncate_inline_data(struct inode *inode, u64 from)
+{
+ struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
+ struct page *page, *ipage;
+ void *addr;
+ int err = 0;
+
+ /*
+ * we should never truncate inline data past max inline data size,
+ * because we always convert inline inode to normal one before
+ * truncating real data if new size is past max inline data size.
+ */
+ f2fs_bug_on(sbi, from MAX_INLINE_DATA);
+
+ if (from == MAX_INLINE_DATA)
+ return 0;
+
+ page = grab_cache_page(inode-i_mapping, 0);
+ if (!page)
+ return -ENOMEM;
Do we need to grab and read #0 page?
How about checking its cached page after on-disk truncation?
1. page = get_node_page()
2. check_inline
3. truncate_inline_inode
4. f2fs_put_page(ipage)
5. truncate_partial_data_page(inode, from, force)
if (!offset !force)
return 0;
+
+ ipage = get_node_page(sbi, inode-i_ino);
+ if (IS_ERR(ipage)) {
+ err = PTR_ERR(ipage);
+ goto out;
+ }
+
+ if (!f2fs_has_inline_data(inode)) {
+ f2fs_put_page(ipage, 1);
+ goto out;
+ }
+
+ truncate_inline_inode(ipage, from);
+ set_page_dirty(ipage);
+
+ read_inline_data(page, ipage);
+ f2fs_put_page(ipage, 1);
+
+ addr = inline_data_addr(page);
+ memset(addr +
[PATCH 09/21] userfaultfd: prevent khugepaged to merge if userfaultfd is armed
If userfaultfd is armed on a certain vma we can't fill the holes
with zeroes or we'll break the userland on demand paging. The holes if
the userfault is armed, are really missing information (not zeroes)
that the userland has to load from network or elsewhere.
The same issue happens for wrprotected ptes that we can't just convert
into a single writable pmd_trans_huge.
We could however in theory still merge across zeropages if only
VM_UFFD_MISSING is set (so if VM_UFFD_WP is not set)... that could be
slightly improved but it'd be much more complex code for a tiny corner
case.
Signed-off-by: Andrea Arcangeli aarca...@redhat.com
---
mm/huge_memory.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 5374132..8f1b6a5 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2145,7 +2145,8 @@ static int __collapse_huge_page_isolate(struct
vm_area_struct *vma,
_pte++, address += PAGE_SIZE) {
pte_t pteval = *_pte;
if (pte_none(pteval) || is_zero_pfn(pte_pfn(pteval))) {
- if (++none_or_zero = khugepaged_max_ptes_none)
+ if (!userfaultfd_armed(vma)
+ ++none_or_zero = khugepaged_max_ptes_none)
continue;
else
goto out;
@@ -2593,7 +2594,8 @@ static int khugepaged_scan_pmd(struct mm_struct *mm,
_pte++, _address += PAGE_SIZE) {
pte_t pteval = *_pte;
if (pte_none(pteval) || is_zero_pfn(pte_pfn(pteval))) {
- if (++none_or_zero = khugepaged_max_ptes_none)
+ if (!userfaultfd_armed(vma)
+ ++none_or_zero = khugepaged_max_ptes_none)
continue;
else
goto out_unmap;
--
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] virtio_mmio: generation support
virtio_mmio currently lacks generation support which
makes multi-byte field access racy.
Fix by getting the value at offset 0xfc for version 2
devices. Nothing we can do for version 1, so return
generation id 0.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
Pawel, you mentioned you have a working virtio 1.0
hypervisor, can you pls confirm this works correctly?
drivers/virtio/virtio_mmio.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
index 0375456..69b2e4d 100644
--- a/drivers/virtio/virtio_mmio.c
+++ b/drivers/virtio/virtio_mmio.c
@@ -237,6 +237,16 @@ static void vm_set(struct virtio_device *vdev, unsigned
offset,
}
}
+static u32 vm_generation(struct virtio_device *vdev)
+{
+ struct virtio_mmio_device *vm_dev = to_virtio_mmio_device(vdev);
+
+ if (vm_dev-version == 1)
+ return 0;
+ else
+ return readl(vm_dev-base + VIRTIO_MMIO_CONFIG_GENERATION);
+}
+
static u8 vm_get_status(struct virtio_device *vdev)
{
struct virtio_mmio_device *vm_dev = to_virtio_mmio_device(vdev);
@@ -503,6 +513,8 @@ static const char *vm_bus_name(struct virtio_device *vdev)
static const struct virtio_config_ops virtio_mmio_config_ops = {
.get= vm_get,
.set= vm_set,
+ .generation = vm_generation,
+ .get_status = vm_get_status,
.get_status = vm_get_status,
.set_status = vm_set_status,
.reset = vm_reset,
--
MST
--
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] capabilities: Ambient capability set V2
On Mar 5, 2015 10:41 AM, Christoph Lameter c...@linux.com wrote: On Thu, 5 Mar 2015, Serge E. Hallyn wrote: So I'd say drop this change ^ Then the ambient caps get ignored for a executables that have capabilities seton the file? Yes. Those are assumed to already know what they're doing. Do they? What if there is a LD_PRELOAD library that redirects socket calls and that needs raw device access (there are actually a number of software packages like that to reduce the latency of network I/O. See for example Solarflare's software products and the current rsocket libary in OFED. There are cap issues if the rsocket library should be made useful for Ethernet instead of infiniband). Why? Do you foresee cases where a file that has fP set needs capabilities that aren't in its fP? Yes due to the library issues. You can't LD_PRELOAD and fP together. And I'm still unconvinced that ambient caps can ever be safe in conjunction with fP. I'll grill you next week on what you're trying to do that makes you want this :) --Andy It seems more likely that they'll risk misbehaving due to an unexpected set of caps. The userspace driver code in the library wont work since it does not have the caps to access the raw device registers. -- 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: x32 + audit status?
On Mar 5, 2015 10:32 AM, David Drysdale drysd...@google.com wrote:
Hi,
Do we currently expect the audit system to work with x32 syscalls?
I was playing with the audit system for the first time today (on
v4.0-rc2, due to [1]), and it didn't seem to work for me. (Tweaking
ptrace.c like the patch below seemed to help, but I may just have
configured something wrong.)
I know there was a bunch of activity around this area in mid-2014,
but I'm not sure what the final position was...
It's totally broken, and it needs ABI work. I think it should keep
the high syscall numbers, which means that both userspace and the
audit core need to learn how to deal with it.
--Andy
Thanks,
David
[1]: https://lkml.org/lkml/2015/3/4/879
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index e510618b2e91..443932afd9e8 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -1445,7 +1445,7 @@ static void do_audit_syscall_entry(struct
pt_regs *regs, u32 arch)
{
#ifdef CONFIG_X86_64
if (arch == AUDIT_ARCH_X86_64) {
- audit_syscall_entry(regs-orig_ax, regs-di,
+ audit_syscall_entry(regs-orig_ax __SYSCALL_MASK, regs-di,
regs-si, regs-dx, regs-r10);
} else
#endif
--
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/
[REGRESSION in 3.18][PPC] PA Semi fails to boot after: of/base: Fix PowerPC address parsing hack
A bug in ftrace was reported to me that affects ARM and ARM64 but not x86. Looking at the code it appears to affect PowerPC as well. So I booted up my old PA Semi, to give it a try. The last time I booted it was for a 3.17 kernel. Unfortunately, for 4.0-rc2 it crashed with: Unable to handle kernel paging request for data at address 0x Faulting instruction address: 0xc05cef88 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=2 PA Semi PWRficient Modules linked in: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.0.0-rc2-test #50 task: c0003816cb60 ti: c000381a4000 task.ti: c000381a4000 NIP: c05cef88 LR: c007c1a0 CTR: c007c184 REGS: c000381a7a00 TRAP: 0300 Not tainted (4.0.0-rc2-test) MSR: 90009032 SF,HV,EE,ME,IR,DR,RI CR: 2228 XER: DAR: DSISR: 4000 SOFTE: 0 GPR00: c007c1a0 c000381a7c80 c0af4b98 0001 GPR04: 04ba 3d6de000 GPR08: 0100 c000381a4080 GPR12: 24044042 c300 ffed GPR16: c0afb920 c000381a4000 c09ad648 c09ae580 GPR20: c000381a4080 c000381a4000 c000381a4080 c000381a4000 GPR24: c000381a4000 c000381a4000 c0afb880 c000381a4000 GPR28: c09f8790 c000381a4000 c0b02168 NIP [c05cef88] .check_astate+0x28/0x50 LR [c007c1a0] sleep_common+0x14/0x74 Call Trace: [c000381a7c80] [c0afb880] 0xc0afb880 (unreliable) [c000381a7cf0] [c007c1a0] sleep_common+0x14/0x74 [c000381a7d30] [c00130f0] .arch_cpu_idle+0x70/0x160 [c000381a7db0] [c00d6660] .cpu_startup_entry+0x320/0x5a0 [c000381a7ee0] [c0034570] .start_secondary+0x290/0x2c0 [c000381a7f90] [c0008bfc] start_secondary_prolog+0x10/0x14 Instruction dump: 6000 6000 7c0802a6 f8010010 f821ff91 6000 6000 3d220003 39296870 a86d0038 e9290010 7c0004ac 7c004c2c 0c00 4c00012c 5463103a ---[ end trace 40e864a431826b26 ]--- I kicked off a ktest bisect, and it came down to this commit: commit 746c9e9f92dde2789908e51a354ba90a1962a2eb Author: Benjamin Herrenschmidt b...@kernel.crashing.org Date: Fri Nov 14 17:55:03 2014 +1100 of/base: Fix PowerPC address parsing hack When I revert this from v4.0-rc2, I can successfully boot my PA Semi again. -- 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/
Re: [RESEND PATCH] kernel/panic/kexec: fix crash_kexec_post_notifiers option issue in oops path
On Thu, Mar 05, 2015 at 05:19:30PM -0500, Vivek Goyal wrote:
On Wed, Mar 04, 2015 at 05:56:48PM +0900, HATAYAMA Daisuke wrote:
The commit f06e5153f4ae2e2f3b0300f0e260e40cb7fefd45 introduced
crash_kexec_post_notifiers kernel boot option, which toggles
wheather panic() calls crash_kexec() before or after panic_notifiers
and dump kmsg.
The problem is that the commit overlooks panic_on_oops kernel boot
option. If it is enabled, crash_kexec() is called directly without
going through panic() in oops path.
To fix this issue, this patch adds a check to
crash_kexec_post_notifiers in the condition of kexec_should_crash().
Signed-off-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
Acked-by: Baoquan He b...@redhat.com
Tested-by: Hidehiro Kawai hidehiro.kawai...@hitachi.com
---
include/linux/kernel.h | 3 +++
kernel/kexec.c | 2 ++
kernel/panic.c | 2 +-
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 64ce58b..f47379f 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -426,6 +426,9 @@ extern int panic_on_unrecovered_nmi;
extern int panic_on_io_nmi;
extern int panic_on_warn;
extern int sysctl_panic_on_stackoverflow;
+
+extern bool crash_kexec_post_notifiers;
+
/*
* Only to be used by arch init code. If the user over-wrote the default
* CONFIG_PANIC_TIMEOUT, honor it.
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 9a8a01a..0ecf252 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -84,6 +84,8 @@ struct resource crashk_low_res = {
int kexec_should_crash(struct task_struct *p)
{
+ if (crash_kexec_post_notifiers)
+ return 0;
This is little confusing. So if crash_kexec_post_notifiers is set but
panic_on_oops is not set, still we will return?
Should we do this only if panic_on_oops is set? IOW, how about following
if (panic_on_oops crash_kexec_post_notifiers)
return 0;
And then also put a comment explaining the rationale.
Ok, I went through the previous version of patch and discussion there
which says that all the 4 conditions lead to panic. So putting above
code should be fine.
Can you please atleast put a comment here to explain it as it was not
obvious. Just mention that all the checks below lead to panic hence
if user wants to run panic notifiers then don't run crash_kexec() yet.
It will be run after panic notifiers.
Thanks
Vivek
Thanks
Vivek
if (in_interrupt() || !p-pid || is_global_init(p) || panic_on_oops)
return 1;
return 0;
diff --git a/kernel/panic.c b/kernel/panic.c
index 4d8d6f9..6582546 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -32,7 +32,7 @@ static unsigned long tainted_mask;
static int pause_on_oops;
static int pause_on_oops_flag;
static DEFINE_SPINLOCK(pause_on_oops_lock);
-static bool crash_kexec_post_notifiers;
+bool crash_kexec_post_notifiers;
int panic_on_warn __read_mostly;
int panic_timeout = CONFIG_PANIC_TIMEOUT;
--
1.9.3
--
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] apple-gmux: lock iGP IO to protect from vgaarb changes
As GMUX depends on IO for iGP to be enabled and active, lock the IO at
vgaarb level. This should prevent GPU driver for dGPU to disable IO for
iGP while it tries to own legacy VGA IO.
This fixes usage of backlight control combined with closed nvidia
driver on some Apple dual-GPU (intel/nvidia) systems.
On those systems loading nvidia driver disables intel IO decoding,
disabling the gmux backlight controls as a side effect.
Prior to commits moving boot_vga from (optional) efifb to less optional
vgaarb this mis-behavior could be avoided by using right kernel config
(efifb enabled but vgaarb disabled).
This patch explicitly does not try to trigger vgaarb changes in order
to avoid confusing already running graphics drivers. If IO has been
mis-configured by vgaarb gmux will thus fail to probe.
It is expected to load/probe gmux prior to graphics drivers.
Fixes: ce027dac592c0ada241ce0f95ae65856828ac450 # nvidia interaction
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=86121
Reported-by: Petri Hodju petriho...@yahoo.com
Tested-by: Petri Hodju petriho...@yahoo.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Matthew Garrett matthew.garr...@nebula.com
Signed-off-by: Bruno Prémont bonb...@linux-vserver.org
---
Respinning, fixing Darren's nit.
Changes since v1:
- Dropped repeat of gmux in pr_info/pr_err calls
- Mention PCI device we tried to lock IO for in case of error
drivers/platform/x86/apple-gmux.c | 43 ++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/apple-gmux.c
b/drivers/platform/x86/apple-gmux.c
index b9429fb..22da6a3 100644
--- a/drivers/platform/x86/apple-gmux.c
+++ b/drivers/platform/x86/apple-gmux.c
@@ -22,6 +22,7 @@
#include linux/delay.h
#include linux/pci.h
#include linux/vga_switcheroo.h
+#include linux/vgaarb.h
#include acpi/video.h
#include asm/io.h
@@ -31,6 +32,7 @@ struct apple_gmux_data {
bool indexed;
struct mutex index_lock;
+ struct pci_dev *pdev;
struct backlight_device *bdev;
/* switcheroo data */
@@ -415,6 +417,22 @@ static int gmux_resume(struct device *dev)
return 0;
}
+static struct pci_dev *gmux_find_pdev(void)
+{
+ struct pci_dev *pdev = NULL;
+ while ((pdev = pci_get_class(PCI_CLASS_DISPLAY_VGA 8, pdev))) {
+ u16 cmd;
+
+ pci_read_config_word(pdev, PCI_COMMAND, cmd);
+ if (!(cmd PCI_COMMAND_IO))
+ continue;
+
+ return pdev;
+ }
+
+ return NULL;
+}
+
static int gmux_probe(struct pnp_dev *pnp, const struct pnp_device_id *id)
{
struct apple_gmux_data *gmux_data;
@@ -425,6 +443,7 @@ static int gmux_probe(struct pnp_dev *pnp, const struct
pnp_device_id *id)
int ret = -ENXIO;
acpi_status status;
unsigned long long gpe;
+ struct pci_dev *pdev = NULL;
if (apple_gmux_data)
return -EBUSY;
@@ -475,7 +494,7 @@ static int gmux_probe(struct pnp_dev *pnp, const struct
pnp_device_id *id)
ver_minor = (version 16) 0xff;
ver_release = (version 8) 0xff;
} else {
- pr_info(gmux device not present\n);
+ pr_info(gmux device not present or IO disabled\n);
ret = -ENODEV;
goto err_release;
}
@@ -483,6 +502,23 @@ static int gmux_probe(struct pnp_dev *pnp, const struct
pnp_device_id *id)
pr_info(Found gmux version %d.%d.%d [%s]\n, ver_major, ver_minor,
ver_release, (gmux_data-indexed ? indexed : classic));
+ /*
+* Apple systems with gmux are EFI based and normally don't use
+* VGA. In addition changing IO+MEM ownership between IGP and dGPU
+* disables IO/MEM used for backlight control on some systems.
+* Lock IO+MEM to GPU with active IO to prevent switch.
+*/
+ pdev = gmux_find_pdev();
+ if (pdev vga_tryget(pdev,
+ VGA_RSRC_NORMAL_IO | VGA_RSRC_NORMAL_MEM)) {
+ pr_err(IO+MEM vgaarb-locking for PCI:%s failed\n,
+ pci_name(pdev));
+ ret = -EBUSY;
+ goto err_release;
+ } else if (pdev)
+ pr_info(locked IO for PCI:%s\n, pci_name(pdev));
+ gmux_data-pdev = pdev;
+
memset(props, 0, sizeof(props));
props.type = BACKLIGHT_PLATFORM;
props.max_brightness = gmux_read32(gmux_data, GMUX_PORT_MAX_BRIGHTNESS);
@@ -574,6 +609,7 @@ err_enable_gpe:
err_notify:
backlight_device_unregister(bdev);
err_release:
+ pci_dev_put(pdev);
release_region(gmux_data-iostart, gmux_data-iolen);
err_free:
kfree(gmux_data);
@@ -593,6 +629,11 @@ static void gmux_remove(struct pnp_dev *pnp)
gmux_notify_handler);
}
+ if (gmux_data-pdev) {
+
[PATCH v2] HID: wacom: ask for a in-prox report when it was missed
If noone listens to the input device when a tool comes in proximity,
the tablet does not send the in-prox event when a client becomes available.
That means that no events will be sent until the tool is taken out of
proximity.
In this situation, ask for the report WACOM_REPORT_INTUOSREAD which will
read the corresponding feature and generate an in-prox event.
To make some generation of hardware working, we need to unset the
quirk NO_GET set by hid-core because the interfaces are seen as boot
mouse.
We don't schedule this read in a worker while we are in an IO interrupt.
We know that usbhid will do it asynchronously. If this is triggered by
uhid, then this is obviously a client side bug :)
Signed-off-by: Benjamin Tissoires benjamin.tissoi...@redhat.com
---
Change in v2:
- commit message amended (a little)
- unset the flag HID_QUIRK_NO_GET to make the code compatible with Intuos 3 and
4
drivers/hid/wacom_sys.c | 3 +++
drivers/hid/wacom_wac.c | 18 +-
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index 957699f..22cac9d 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -1389,6 +1389,9 @@ static int wacom_probe(struct hid_device *hdev,
hdev-quirks |= HID_QUIRK_NO_INIT_REPORTS;
+ /* hid-core sets this quirk for the boot interface */
+ hdev-quirks = ~HID_QUIRK_NOGET;
+
wacom = kzalloc(sizeof(struct wacom), GFP_KERNEL);
if (!wacom)
return -ENOMEM;
diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index 9ec4545..ff9a7ab 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -430,6 +430,19 @@ exit:
return retval;
}
+static void wacom_intuos_schedule_prox_event(struct wacom_wac *wacom_wac)
+{
+ struct wacom *wacom = container_of(wacom_wac, struct wacom, wacom_wac);
+ struct hid_report *r;
+ struct hid_report_enum *re;
+
+ re = (wacom-hdev-report_enum[HID_FEATURE_REPORT]);
+ r = re-report_id_hash[WACOM_REPORT_INTUOSREAD];
+ if (r) {
+ hid_hw_request(wacom-hdev, r, HID_REQ_GET_REPORT);
+ }
+}
+
static int wacom_intuos_inout(struct wacom_wac *wacom)
{
struct wacom_features *features = wacom-features;
@@ -609,8 +622,11 @@ static int wacom_intuos_inout(struct wacom_wac *wacom)
}
/* don't report other events if we don't know the ID */
- if (!wacom-id[idx])
+ if (!wacom-id[idx]) {
+ /* but reschedule a read of the current tool */
+ wacom_intuos_schedule_prox_event(wacom);
return 1;
+ }
return 0;
}
--
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/
Re: [PATCH v1 3/6] eeprom: Add bindings for simple eeprom framework
+
+For example:
+
+ /* Provider */
+ qfprom: qfprom@0070 {
+ compatible = qcom,qfprom;
+ reg = 0x0070 0x1000;
+ ...
+
+ /* Data cells */
+ tsens_calibration: calib@404 {
+ reg = 0x404 0x10;
+ };
+
+ serial_number: sn {
+ reg = 0x104 0x4, 0x204 0x4, 0x30c 0x4;
+
+ };
+ ...
+ };
+
+= Data consumers =
+Are drivers which consume eeprom data cells.
s/drivers/device nodes/
Thats true, device nodes makes sense.
+
+Required properties:
+
+eeproms: List of phandle and data cell the device might be interested in.
+
+Optional properties:
+
+eeprom-names: List of data cell name strings sorted in the same order
+ as the resets property. Consumers drivers will use
resets?
Opps..
I remember fixing this, I will take care of it in next version.
+ eeprom-names to differentiate between multiple cells,
+ and hence being able to know what these cells are for.
Is this still needed? The sub-node name defines the name. Or you can
use reg-names with-in the sub-node.
Yes, eeprom-names is needed in the consumer nodes, where there are
multiple eeproms cells, its easy to lookup by name rather than
index,which depends on the order of the entries.
reg-names inside the data cells is ok, but I can't think of its use
immediately. May be useful for debug?
--srini
Rob
+
+For example:
+
+ tsens {
+ ...
+ eeproms = tsens_calibration;
+ eeprom-names = calibration;
+ };
--
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] HID: wacom: check for wacom-shared before following the pointer
486b908 (HID: wacom: do not send pen events before touch is up/forced out)
introduces a kernel oops when plugging a tablet without touch.
wacom-shared is null for these devices so this leads to a null pointer
exception.
Change the condition to make it clear that what we need is wacom-shared
not NULL.
Signed-off-by: Benjamin Tissoires benjamin.tissoi...@redhat.com
---
Hi Jiri,
this one should be pulled in 4.0. Or we will have surprised users :)
Cheers,
Benjamin
drivers/hid/wacom_wac.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index ff9a7ab..9739a4c 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -564,11 +564,12 @@ static int wacom_intuos_inout(struct wacom_wac *wacom)
(features-type == CINTIQ !(data[1] 0x40)))
return 1;
- if (features-quirks WACOM_QUIRK_MULTI_INPUT)
+ if (wacom-shared) {
wacom-shared-stylus_in_proximity = true;
- if (wacom-shared-touch_down)
- return 1;
+ if (wacom-shared-touch_down)
+ return 1;
+ }
/* in Range while exiting */
if (((data[1] 0xfe) == 0x20) wacom-reporting_data) {
--
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/
Re: [PATCH] firmware_class: Add firmware filename overrides
On Thu, Mar 5, 2015 at 2:12 PM, Marcel Holtmann mar...@holtmann.org wrote: Hi Dmitry, Specifically this was motivated by a situation where we have one device with a dual-sourced touchscreen. Both use the same driver but have different hardware fw. Our FW updating software therefore, needs to be able to update with the correct FW and detect all this at runtime due to a read-only partition (so moving the firmware binaries around isn't really an option) Here the device has only one touchscreen at a time, but it isn't known until run-time which will be present. So in this case the driver is serving the same function in each situation (running a touchscreen) but may be working with different hardware. Another situation where I've personally wanted this functionality is on a device that uses the same touch driver for both a touchscreen and a touchpad on the same device. If the driver only grabs a copy of FW from, say, /lib/firmware/touch_fw.bin then you either need to move the firmware binaries around on disk to update either device, or have a change like this that allows you to override which filename it loads. The moving option is not viable if you're using a RO filesystem. what is the actual problem here? We have drivers that load multiple firmware files and we have drivers that pick a different firmware depending on some parameters it reads from the device. Seems this is all possible already at the moment with the existing framework. You just need to update the drivers to operate properly. I totally agree, this functionality is not novel. We could have added this feature into the specific driver in question, but then we will have to do the same thing on all the other drivers we might want to do this on. I guess the real problem that this solves is by adding the change here, it allows you to override firmware names for *any* driver without having to duplicate the functionality in each one as they come up. For a specific instance, here at ChromiumOS we have devices that use Atmel, Cypress, Synaptics, and Elan touchpads and touchscreens that all can encounter this issue. The Atmel driver has a similar version of this feature baked into it but the others don't. We could add a fw_filename attribute to each of these drivers, but then it would have to be maintained across (at least) four drivers. what I am hearing here is that you can not query the hardware and figure out which manufacturer it is and with that don't know which firmware you need. Right, the drivers in question (bunch of input drivers such as elan_ts, atmel_mxt_ts, etc) might not be able to determine the proper configuration to load. Factories quite often swap pin-compatible parts and want to use the same image. Also the parts can be swapped out during RMA while keeping the same image. Userspace is able to query magnitude of sources and make an informed decision that it then communicates to the kernel. However if that is the case, then this seems to be something that should be solved with device tree. Why are we making device tree a hard dependency here? device tree is suppose to describe the hardware in your devices. If you can not determinate your hardware by enumeration or other means, then it should be done via device tree. Seems the perfect fit here. And if I do not have device tree? so if you do not have an enumeration method for your hardware, then I assume you most likely have device tree in one form or another. And even if you really don't, nothing is stopping you from adding device tree. We have ACPI (for example) and no, it is not 5.0. Thanks, Dmitry -- 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 1/7] ARM: at91: switch to multiplatform
On Thu, Mar 5, 2015 at 1:17 PM, Alexandre Belloni alexandre.bell...@free-electrons.com wrote: Switch AT91 to multiplatform as all SoCs are properly handled. Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com --- arch/arm/Kconfig| 13 - arch/arm/mach-at91/Kconfig | 117 +++- arch/arm/mach-at91/Makefile | 2 + 3 files changed, 62 insertions(+), 70 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index f6c5b05e8de8..a1d153098001 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -356,19 +356,6 @@ config ARCH_VERSATILE help This enables support for ARM Ltd Versatile board. -config ARCH_AT91 - bool Atmel AT91 - select ARCH_REQUIRE_GPIOLIB - select CLKDEV_LOOKUP - select IRQ_DOMAIN - select PINCTRL - select PINCTRL_AT91 - select SOC_BUS - select USE_OF - help - This enables support for systems based on Atmel - AT91RM9200, AT91SAM9 and SAMA5 processors. - config ARCH_CLPS711X bool Cirrus Logic CLPS711x/EP721x/EP731x-based select ARCH_REQUIRE_GPIOLIB diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig index 7ecde7de69da..1b8525c324c3 100644 --- a/arch/arm/mach-at91/Kconfig +++ b/arch/arm/mach-at91/Kconfig @@ -1,51 +1,22 @@ -if ARCH_AT91 - -config HAVE_AT91_UTMI - bool - -config HAVE_AT91_USB_CLK - bool - -config COMMON_CLK_AT91 - bool - select COMMON_CLK - -config HAVE_AT91_SMD - bool - -config HAVE_AT91_H32MX - bool - -config SOC_SAMA5 +config ARCH_AT91 bool - select ATMEL_AIC5_IRQ + select ARCH_REQUIRE_GPIOLIB select COMMON_CLK_AT91 - select CPU_V7 + select CLKDEV_LOOKUP This is already selected by COMMON_CLK I think. select GENERIC_CLOCKEVENTS This is already selected. - select MEMORY - select ATMEL_SDRAMC - select PHYLIB if NETDEVICES - -menu Atmel AT91 System-on-Chip - -choice - - prompt Core type - -config SOC_SAM_V4_V5 - bool ARM9 AT91SAM9/AT91RM9200 - help - Select this if you are using one of Atmel's AT91SAM9 or - AT91RM9200 SoC. - -config SOC_SAM_V7 - bool Cortex A5 + select IRQ_DOMAIN + select NEED_MACH_IO_H if PCCARD This won't work on multi-platform. + select PINCTRL + select PINCTRL_AT91 + select SOC_BUS + select USE_OF This is already selected. + +menuconfig SOC_SAM_V7 + bool Atmel SAMA5 if ARCH_MULTI_V7 + select ARCH_AT91 help - Select this if you are using one of Atmel's SAMA5D3 SoC. - -endchoice - -comment Atmel AT91 Processor + This enables support for systems based on Atmel + SAMA5D3 or SAMA5D4 SoCs. if SOC_SAM_V7 config SOC_SAMA5D3 @@ -71,25 +42,29 @@ config SOC_SAMA5D4 select HAVE_AT91_H32MX help Select this if you are using one of Atmel's SAMA5D4 family SoC. -endif +endif # SOC_SAM_V7 + + +menuconfig SOC_SAM_V4_V5 + bool Atmel ARM9 AT91SAM9/AT91RM9200 if ARCH_MULTI_V4_V5 + select ARCH_AT91 + help + Select this if you are using one of Atmel's AT91SAM9 or + AT91RM9200 SoC. if SOC_SAM_V4_V5 config SOC_AT91RM9200 - bool AT91RM9200 + bool AT91RM9200 if ARCH_MULTI_V4T select ATMEL_AIC_IRQ - select COMMON_CLK_AT91 select CPU_ARM920T - select GENERIC_CLOCKEVENTS select HAVE_AT91_USB_CLK select MIGHT_HAVE_PCI config SOC_AT91SAM9 - bool AT91SAM9 + bool AT91SAM9 if ARCH_MULTI_V5 select ATMEL_AIC_IRQ select ATMEL_SDRAMC - select COMMON_CLK_AT91 select CPU_ARM926T - select GENERIC_CLOCKEVENTS select HAVE_AT91_SMD select HAVE_AT91_USB_CLK select HAVE_AT91_UTMI @@ -115,6 +90,34 @@ config SOC_AT91SAM9 AT91SAM9XE endif # SOC_SAM_V4_V5 +if ARCH_AT91 + +config HAVE_AT91_UTMI + bool + +config HAVE_AT91_USB_CLK + bool + +config COMMON_CLK_AT91 + bool + select COMMON_CLK This belongs in drivers/clk. + +config HAVE_AT91_SMD + bool + +config HAVE_AT91_H32MX + bool + +config SOC_SAMA5 + bool + select ATMEL_AIC5_IRQ + select CPU_V7 This is not needed. + select MEMORY + select ATMEL_SDRAMC + select PHYLIB if NETDEVICES This belongs with your network driver. + +menu Atmel AT91 common options + comment AT91 Feature Selections config AT91_SLOW_CLOCK @@ -132,12 +135,12 @@ config AT91_SLOW_CLOCK need to be completely re-initialized. config AT91_TIMER_HZ - int Kernel HZ (jiffies per second) - range 32 1024 - depends on ARCH_AT91 - default 128 if SOC_AT91RM9200 - default 100 -
Re: [PATCH 1/8] pmem: Initial version of persistent memory driver
On Mar 5, 2015 3:55 AM, Boaz Harrosh b...@plexistor.com wrote: From: Ross Zwisler ross.zwis...@linux.intel.com PMEM is a new driver That supports any physical contiguous iomem range as a single block device. The driver has support for as many as needed iomem ranges each as its own device. The driver is not only good for NvDIMMs, It is good for any flat memory mapped device. We've used it with NvDIMMs, Kernel reserved DRAM (memmap= on command line), PCIE Battery backed memory cards, VM shared memory, and so on. The API to pmem module a single string parameter named map of the form: map=mapS[,mapS...] where mapS=nn[KMG]$ss[KMG], ormapS=nn[KMG]@ss[KMG], nn=size, ss=offset Just like the Kernel command line map memmap parameters, so anything you did at grub just copy/paste to here. The @ form is exactly the same as the $ form only that at bash prompt we need to escape the $ with \$ so also support the '@' char for convenience. For each specified mapS there will be a device created. [...] + pmem-virt_addr = ioremap_cache(pmem-phys_addr, pmem-size); I think it would be nice to have control over the caching mode. Depending on the application, WT or UC could make more sense. --Andy -- 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/3] drivers:pnp Add support for descendants claiming memory address space
On 2/17/2015 8:41 PM, Jake Oshins wrote: This patch adds some wrapper functions in the pnp layer. The intent is to allow memory address space claims by devices which are descendants (a child or grandchild of) a device which is already part of the pnp layer. This allows a device to make a resource claim that doesn't conflict with its aunts and uncles. How is this going to happen? This is useful in a Hyper-V VM because some paravirtual devices need memory-mapped I/O space, and their aunts and uncles can be PCI devices. Furthermore, the hypervisor expresses the possible memory address combinations for the devices in the VM through the ACPI namespace. The paravirtual devices need to suballocate from the ACPI nodes, and they need to avoid conflicting with choices that the Linux PCI code makes about the PCI devices in the VM. It might seem like this should be done in the platform layer rather than the pnp layer, but the platform layer assumes that the configuration of the devices in the machine are static, or at least expressed by firmware in a static fashion. I'm not sure if I'm following you here. Where exactly do we make that assumption? Yes, some code to support platform device hotplug may be missing, but I'd very much prefer to add it instead of reviving the dead man walking which is the PNP subsystem today. The nature of a Hyper-V VM is that new devices can be added while the machine is running, and the potential configurations for them are expressed as part of the paravirtual communications channel. This much more naturally aligns with the pnp layer. That's debatable. That aside, it would help a lot if you described your design in plain English and added some useful kerneldoc comments to the new functions. Kind regards, 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 1/4] i2c: sunxi: Add Reduced Serial Bus (RSB) support
On Thu, Mar 05, 2015 at 07:40:44PM +0100, Wolfram Sang wrote: I don't have the bandwidth for a full review right now. However, I already wanted to tell you guys that my gut feeling is that this protocol is quite far away from I2C. P2WI was already at the edge. Maybe there is a better place for such custom stuff? I dunno yet. That's unfortunate, especially since it looks closer to SPI than what P2WI even was. SPI? I assume you mean I2C. Can you elaborate your reasoning? Yeah, I obviously meant I2C, sorry. P2WI had no address. It was a single-device bus. However, the way it communicated with the device was very close to I2C, apart from a parity bit instead of the ACK. From that regard, RSB is a multiple device bus, using addresses, just like I2C. The way it communicates is basically the one used by P2WI. So really, it just is more I2C-alike than P2WI has ever been. What would be your suggestion? Let me quote: I don't have the bandwidth for a full review right now... I dunno yet. Good thing that we are not talking about a full review then, but more a philosophical discussion. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [RESEND PATCH] kernel/panic/kexec: fix crash_kexec_post_notifiers option issue in oops path
On Wed, Mar 04, 2015 at 05:56:48PM +0900, HATAYAMA Daisuke wrote:
The commit f06e5153f4ae2e2f3b0300f0e260e40cb7fefd45 introduced
crash_kexec_post_notifiers kernel boot option, which toggles
wheather panic() calls crash_kexec() before or after panic_notifiers
and dump kmsg.
The problem is that the commit overlooks panic_on_oops kernel boot
option. If it is enabled, crash_kexec() is called directly without
going through panic() in oops path.
To fix this issue, this patch adds a check to
crash_kexec_post_notifiers in the condition of kexec_should_crash().
Signed-off-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
Acked-by: Baoquan He b...@redhat.com
Tested-by: Hidehiro Kawai hidehiro.kawai...@hitachi.com
---
include/linux/kernel.h | 3 +++
kernel/kexec.c | 2 ++
kernel/panic.c | 2 +-
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 64ce58b..f47379f 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -426,6 +426,9 @@ extern int panic_on_unrecovered_nmi;
extern int panic_on_io_nmi;
extern int panic_on_warn;
extern int sysctl_panic_on_stackoverflow;
+
+extern bool crash_kexec_post_notifiers;
+
/*
* Only to be used by arch init code. If the user over-wrote the default
* CONFIG_PANIC_TIMEOUT, honor it.
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 9a8a01a..0ecf252 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -84,6 +84,8 @@ struct resource crashk_low_res = {
int kexec_should_crash(struct task_struct *p)
{
+ if (crash_kexec_post_notifiers)
+ return 0;
This is little confusing. So if crash_kexec_post_notifiers is set but
panic_on_oops is not set, still we will return?
Should we do this only if panic_on_oops is set? IOW, how about following
if (panic_on_oops crash_kexec_post_notifiers)
return 0;
And then also put a comment explaining the rationale.
Thanks
Vivek
if (in_interrupt() || !p-pid || is_global_init(p) || panic_on_oops)
return 1;
return 0;
diff --git a/kernel/panic.c b/kernel/panic.c
index 4d8d6f9..6582546 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -32,7 +32,7 @@ static unsigned long tainted_mask;
static int pause_on_oops;
static int pause_on_oops_flag;
static DEFINE_SPINLOCK(pause_on_oops_lock);
-static bool crash_kexec_post_notifiers;
+bool crash_kexec_post_notifiers;
int panic_on_warn __read_mostly;
int panic_timeout = CONFIG_PANIC_TIMEOUT;
--
1.9.3
--
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: Re: [PATCH v2 3/3] efi: Capsule update with user helper interface
On Mar 5, 2015 1:19 AM, Kweh, Hock Leong hock.leong.k...@intel.com wrote: -Original Message- From: Andy Lutomirski [mailto:l...@amacapital.net] Sent: Wednesday, March 04, 2015 4:38 AM On Mon, Mar 2, 2015 at 9:56 PM, Kweh, Hock Leong hock.leong.k...@intel.com wrote: Just to call out that using firmware class auto locate binary feature is limited to locations: - /lib/firmware/updates/ UTS_RELEASE, - /lib/firmware/updates, - /lib/firmware/ UTS_RELEASE, - /lib/firmware and one custom path which inputted during firmware_class module load time or kernel boot up time. It is just not like the user helper interface which allow load the binary at any path/location. This really is not a big deal. User should cope with it. No, it's a big deal, and the user should not cope. The user *should not* be required to have write access to anything in /lib to install a UEFI capsule that they download from their motherboard vendor's website. /lib belongs to the distro, and UEFI capsules do not belong to the distro. In this regard, UEFI capsules are completely unlike your wireless card firmware, your cpu microcode, etc. Imagine systems using NFS root, Atomic-style systems (e.g. ostree), systems that boot off squashfs, etc. They should still be able to load capsules. The basic user interface that should work is: # uefi-load-capsule /path/to/capsule or: # uefi-load-capsule - /path/to/capsule I don't really care how uefi-load-capsule is implemented, as long as it's straightforward, because people will screw it up if it isn't straightforward. Why is it so hard to have a file in sysfs that you write the capsule to using *cat* (not echo) and that will return an error code if cat fails? Is it because you don't know where the end of the capsule is? if so, ioctl is designed for exactly this purpose. TBH, I find this thread kind of ridiculous. The problem that you're trying to solve is extremely simple, the functionality that userspace needs is trivial, and all of these complex proposals for how it should work are an artifact of the fact that the kernel-internal interfaces you're using for it are not well suited to the problem at hand. --Andy Sorry, I may not catch your point correctly. Are you trying to tell that a normal user can perform efi capsule update. But a normal user does not have the right to install or copy the capsule binary into /lib/firmware/. So, there is a need to make this capsule module to allow uploading the capsule binary at any path or location other than /lib/firmware/. Is this what you mean? No. Only root should be able to load capsules, but even root may not be able to write to /lib. --Andy Regards, Wilson -- 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 0/3 v5] e820: Fix handling of NvDIMM chips
On Thu, Mar 5, 2015 at 2:48 PM, H. Peter Anvin h...@zytor.com wrote: Seriously, if type 12 is the de facto standard for NvDIMMs, I think we should add it. The documented ACPI method of using flags was doomed from the start. I think it's a de facto standard that type 12 means nvdimm. I don't think there's any kind of standard as to whether that means that it's permissible to touch that memory or that nvdimm means type 12. I have no problem w/ the resource name saying nvdimm, but I do object to autoloading anything as a result. (There is no type 12 on EFI, nor will there ever be, since there is no e820 at all on EFI.) --Andy -hpa -- Andy Lutomirski AMA Capital Management, LLC -- 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: [PATCHv2 04/10] fbdev: ssd1307fb: Unify init code and obtain hw specific bits from DT
On Sun, Mar 01, 2015 at 11:27:57PM +0100, Thomas Niederprüm wrote: The SSD130X controllers are very similar from the configuration point of view. The configuration registers for the SSD1305/6/7 are bit identical (except the the VHCOM register and the the default values for clock setup register). This patch unifies the init code of the controller and adds hardware specific properties to DT that are needed to correctly initialize the device. The SSD130X can be wired to the OLED panel in various ways. Even for the same controller this wiring can differ from one display module to another and can not be probed by software. The added DT properties reflect these hardware decisions of the display module manufacturer. The 'com-sequential', 'com-lrremap' and 'com-invdir' values define different possibilities for the COM signals pin configuration and readout direction of the video memory. The 'segment-remap' allows the inversion of the memory- to-pin mapping ultimately inverting the order of the controllers output pins. The 'prechargepX' values need to be adapted according the capacitance of the OLEDs pixel cells. So far these hardware specific bits are hard coded in the init code, making the driver usable only for one certain wiring of the controller. This patch makes the driver usable with all possible hardware setups, given a valid hw description in DT. If the values are not set in DT the default values according to the controllers datasheet are assumed. Unfortunately, this is not a reasonable thing to do, even if you fix the existing user, there's still the case where you have an older DT with a newer kernel. Keeping (and documenting) the previous defaults is the only easy way to support this. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH tip/core/rcu 02/20] x86: Use common outgoing-CPU-notification code
On Thu, Mar 05, 2015 at 04:17:59PM -0500, Boris Ostrovsky wrote:
On 03/04/2015 10:25 AM, Paul E. McKenney wrote:
On Wed, Mar 04, 2015 at 09:55:11AM -0500, Boris Ostrovsky wrote:
The simple solution is to stop calling native_cpu_die() above but
I'd like to use common code in native_cpu_die(). I'll see if I can
carve it out without too much damage to x86.
Very good, thank you! I look forward to seeing your patch.
How about something like this, on top of your original 02/20 patch
(this is copy-paste but hopefully it can be applied):
Unfortunately, no joy. :-(
I was able to fix a couple of whitespace problems, but it still didn't
like this hunk: @@ -766,12 +778,6 @@.
Could you please send the patch as an attachment, post it on the web
somewhere, or otherwise get me a clean copy it it?
Thanx, Paul
arch/x86/include/asm/smp.h |1 +
arch/x86/kernel/smpboot.c | 12 +++-
arch/x86/xen/smp.c | 34 --
3 files changed, 32 insertions(+), 15 deletions(-)
diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h
index 8cd27e0..a5cb4f6 100644
--- a/arch/x86/include/asm/smp.h
+++ b/arch/x86/include/asm/smp.h
@@ -155,6 +155,7 @@ void native_smp_prepare_cpus(unsigned int max_cpus);
void native_smp_cpus_done(unsigned int max_cpus);
int native_cpu_up(unsigned int cpunum, struct task_struct *tidle);
int native_cpu_disable(void);
+int common_cpu_die(unsigned int cpu);
void native_cpu_die(unsigned int cpu);
void native_play_dead(void);
void play_dead_common(void);
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index ff24fbd..c8fa349 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1345,8 +1345,10 @@ int native_cpu_disable(void)
return 0;
}
-void native_cpu_die(unsigned int cpu)
+int common_cpu_die(unsigned int cpu)
{
+ int ret = 0;
+
/* We don't do anything here: idle task is faking death itself. */
/* They ack this in play_dead() by setting CPU_DEAD */
@@ -1355,7 +1357,15 @@ void native_cpu_die(unsigned int cpu)
pr_info(CPU %u is now offline\n, cpu);
} else {
pr_err(CPU %u didn't die...\n, cpu);
+ ret = -1;
}
+
+ return ret;
+}
+
+void native_cpu_die(unsigned int cpu)
+{
+ common_cpu_die(cpu);
}
void play_dead_common(void)
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index e2c7389..1c5e760 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -455,7 +455,10 @@ static int xen_cpu_up(unsigned int cpu, struct
task_struct *idle)
xen_setup_timer(cpu);
xen_init_lock_cpu(cpu);
- /* Xen outgoing CPUs need help cleaning up, so -EBUSY is an error. */
+ /*
+ * PV VCPUs are always successfully taken down (see 'while' loop
+ * in xen_cpu_die()), so -EBUSY is an error.
+ */
rc = cpu_check_up_prepare(cpu);
if (rc)
return rc;
@@ -508,12 +511,11 @@ static void xen_cpu_die(unsigned int cpu)
schedule_timeout(HZ/10);
}
- (void)cpu_wait_death(cpu, 5);
- /* FIXME: Are the below calls really safe in case of timeout? */
-
- xen_smp_intr_free(cpu);
- xen_uninit_lock_cpu(cpu);
- xen_teardown_timer(cpu);
+ if (common_cpu_die(cpu) == 0) {
+ xen_smp_intr_free(cpu);
+ xen_uninit_lock_cpu(cpu);
+ xen_teardown_timer(cpu);
+ }
}
static void xen_play_dead(void) /* used only with HOTPLUG_CPU */
@@ -745,6 +747,16 @@ static void __init
xen_hvm_smp_prepare_cpus(unsigned int max_cpus)
static int xen_hvm_cpu_up(unsigned int cpu, struct task_struct *tidle)
{
int rc;
+
+ /*
+ * This can happen if CPU was offlined earlier and
+ * offlining timed out in common_cpu_die().
+ */
+ if (cpu_report_state(cpu) == CPU_DEAD_FROZEN) {
+ xen_smp_intr_free(cpu);
+ xen_uninit_lock_cpu(cpu);
+ }
+
/*
* xen_smp_intr_init() needs to run before native_cpu_up()
* so that IPI vectors are set up on the booting CPU before
@@ -766,12 +778,6 @@ static int xen_hvm_cpu_up(unsigned int cpu,
struct task_struct *tidle)
return rc;
}
-static void xen_hvm_cpu_die(unsigned int cpu)
-{
- xen_cpu_die(cpu);
- native_cpu_die(cpu);
-}
-
void __init xen_hvm_smp_init(void)
{
if (!xen_have_vector_callback)
@@ -779,7 +785,7 @@ void __init xen_hvm_smp_init(void)
smp_ops.smp_prepare_cpus = xen_hvm_smp_prepare_cpus;
smp_ops.smp_send_reschedule = xen_smp_send_reschedule;
smp_ops.cpu_up = xen_hvm_cpu_up;
- smp_ops.cpu_die = xen_hvm_cpu_die;
+ smp_ops.cpu_die = xen_cpu_die;
smp_ops.send_call_func_ipi = xen_smp_send_call_function_ipi;
smp_ops.send_call_func_single_ipi =
xen_smp_send_call_function_single_ipi;
Re: [PATCH] firmware_class: Add firmware filename overrides
Hi Dmitry, Specifically this was motivated by a situation where we have one device with a dual-sourced touchscreen. Both use the same driver but have different hardware fw. Our FW updating software therefore, needs to be able to update with the correct FW and detect all this at runtime due to a read-only partition (so moving the firmware binaries around isn't really an option) Here the device has only one touchscreen at a time, but it isn't known until run-time which will be present. So in this case the driver is serving the same function in each situation (running a touchscreen) but may be working with different hardware. Another situation where I've personally wanted this functionality is on a device that uses the same touch driver for both a touchscreen and a touchpad on the same device. If the driver only grabs a copy of FW from, say, /lib/firmware/touch_fw.bin then you either need to move the firmware binaries around on disk to update either device, or have a change like this that allows you to override which filename it loads. The moving option is not viable if you're using a RO filesystem. what is the actual problem here? We have drivers that load multiple firmware files and we have drivers that pick a different firmware depending on some parameters it reads from the device. Seems this is all possible already at the moment with the existing framework. You just need to update the drivers to operate properly. I totally agree, this functionality is not novel. We could have added this feature into the specific driver in question, but then we will have to do the same thing on all the other drivers we might want to do this on. I guess the real problem that this solves is by adding the change here, it allows you to override firmware names for *any* driver without having to duplicate the functionality in each one as they come up. For a specific instance, here at ChromiumOS we have devices that use Atmel, Cypress, Synaptics, and Elan touchpads and touchscreens that all can encounter this issue. The Atmel driver has a similar version of this feature baked into it but the others don't. We could add a fw_filename attribute to each of these drivers, but then it would have to be maintained across (at least) four drivers. what I am hearing here is that you can not query the hardware and figure out which manufacturer it is and with that don't know which firmware you need. Right, the drivers in question (bunch of input drivers such as elan_ts, atmel_mxt_ts, etc) might not be able to determine the proper configuration to load. Factories quite often swap pin-compatible parts and want to use the same image. Also the parts can be swapped out during RMA while keeping the same image. Userspace is able to query magnitude of sources and make an informed decision that it then communicates to the kernel. However if that is the case, then this seems to be something that should be solved with device tree. Why are we making device tree a hard dependency here? device tree is suppose to describe the hardware in your devices. If you can not determinate your hardware by enumeration or other means, then it should be done via device tree. Seems the perfect fit here. And if I do not have device tree? so if you do not have an enumeration method for your hardware, then I assume you most likely have device tree in one form or another. And even if you really don't, nothing is stopping you from adding device tree. Regards Marcel -- 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: linux-next: build failure after merge of the net-next tree
Hi Dave, On Thu, 05 Mar 2015 00:01:58 -0500 (EST) David Miller da...@davemloft.net wrote: From: Stephen Rothwell s...@canb.auug.org.au Date: Thu, 5 Mar 2015 13:42:47 +1100 From: Stephen Rothwell s...@canb.auug.org.au Date: Thu, 5 Mar 2015 13:37:05 +1100 Subject: [PATCH] mpls: using vzalloc requires including vmalloc.h Fixes this build error: net/mpls/af_mpls.c: In function 'resize_platform_label_table': net/mpls/af_mpls.c:767:4: error: implicit declaration of function 'vzalloc' [-Werror=implicit-function-declaration] labels = vzalloc(size); ^ Fixes: 7720c01f3f59 (mpls: Add a sysctl to control the size of the mpls label table) Signed-off-by: Stephen Rothwell s...@canb.auug.org.au Applied, thanks Stephen. I don't see it in net-next? -- Cheers, Stephen Rothwells...@canb.auug.org.au pgp3EWJFr8oxN.pgp Description: OpenPGP digital signature
Possible lock-less list race in scheduler_ipi()
Hi,
I recently reviewed the scheduler_ipi() code by
coincidence, and noticed that the use of llist.h
in there seemed a bit odd. So I'd like to have
more eyes to help me look into this.
I've been told that there has been issues with
IPIs lately, so here is one possible scenario
I think might be possible:
- scheduler_ipi()
- sched_ttwu_pending()
- llist_del_all()
(grabs the wake_list with xchg())
- raw_spin_lock_irqsave(rq-lock, flags);
- iteration on the llist (owned locally by interrupt handler)
(for each item)
p = llist_entry(llist, struct task_struct, wake_entry);
llist = llist_next(llist);
ttwu_do_activate(rq, p, 0);
- raw_spin_unlock_irqrestore(rq-lock, flags);
ttwu_do_activate() ends up calling
ttwu_activate() and ttwu_do_wakeup(),
I'm worried that ttwu_do_wakeup() might end up
indirectly handing off the task to the following
functions (within another execution context):
- try_to_wake_up()
- ttwu_queue()
- ttwu_queue_remote adds the process to another
wake_list with a cmpxchg()
llist_next() is pretty simple:
static inline struct llist_node *llist_next(struct llist_node *node)
{
return node-next;
}
It is so simple that I wonder if the compiler would be
within its rights to reorder the load of node-next
after some operations within ttwu_do_activate(), thus
causing corruption of this linked-list due to a
concurrent try_to_wake_up() performed by another core.
Am I too paranoid about the possible compiler mishaps
there, or are my concerns justified ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
--
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] MIPS: OCTEON: Use correct CSR to soft reset
On 03/05/2015 07:06 AM, Aleksey Makarov wrote:
From: Chandrakala Chavva ccha...@caviumnetworks.com
This fixes reboot for Octeon III boards
Signed-off-by: Chandrakala Chavva ccha...@caviumnetworks.com
Signed-off-by: Aleksey Makarov aleksey.maka...@auriga.com
Let's make a change to this patch...
---
arch/mips/cavium-octeon/setup.c | 5 -
arch/mips/include/asm/octeon/cvmx.h | 6 +-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/mips/cavium-octeon/setup.c b/arch/mips/cavium-octeon/setup.c
index 01130e9..73348af 100644
--- a/arch/mips/cavium-octeon/setup.c
+++ b/arch/mips/cavium-octeon/setup.c
@@ -416,7 +416,10 @@ static void octeon_restart(char *command)
mb();
while (1)
- cvmx_write_csr(CVMX_CIU_SOFT_RST, 1);
+ if (OCTEON_IS_OCTEON3())
+ cvmx_write_csr(CVMX_RST_SOFT_RST, 1);
+ else
+ cvmx_write_csr(CVMX_CIU_SOFT_RST, 1);
}
diff --git a/arch/mips/include/asm/octeon/cvmx.h
b/arch/mips/include/asm/octeon/cvmx.h
index 33db1c8..fb575d7 100644
--- a/arch/mips/include/asm/octeon/cvmx.h
+++ b/arch/mips/include/asm/octeon/cvmx.h
@@ -66,6 +66,7 @@ enum cvmx_mips_space {
#include asm/octeon/cvmx-led-defs.h
#include asm/octeon/cvmx-mio-defs.h
#include asm/octeon/cvmx-pow-defs.h
+#include asm/octeon/cvmx-rst-defs.h
#include asm/octeon/cvmx-bootinfo.h
#include asm/octeon/cvmx-bootmem.h
@@ -441,7 +442,10 @@ static inline void cvmx_reset_octeon(void)
union cvmx_ciu_soft_rst ciu_soft_rst;
ciu_soft_rst.u64 = 0;
ciu_soft_rst.s.soft_rst = 1;
- cvmx_write_csr(CVMX_CIU_SOFT_RST, ciu_soft_rst.u64);
+ if (OCTEON_IS_OCTEON3())
+ cvmx_write_csr(CVMX_RST_SOFT_RST, ciu_soft_rst.u64);
+ else
+ cvmx_write_csr(CVMX_CIU_SOFT_RST, ciu_soft_rst.u64);
}
cvmx_reset_octeon() is unused in the kernel. So instead of patching it
up, remove it altogether, thus removing a little bit of ugliness from
the world.
David Daney
--
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 2/2] mm: numa: Do not clear PTEs or PMDs for NUMA hinting faults
Dave Chinner reported the following on https://lkml.org/lkml/2015/3/1/226 Across the board the 4.0-rc1 numbers are much slower, and the degradation is far worse when using the large memory footprint configs. Perf points straight at the cause - this is from 4.0-rc1 on the -o bhash=101073 config: - 56.07%56.07% [kernel][k] default_send_IPI_mask_sequence_phys - default_send_IPI_mask_sequence_phys - 99.99% physflat_send_IPI_mask - 99.37% native_send_call_func_ipi smp_call_function_many - native_flush_tlb_others - 99.85% flush_tlb_page ptep_clear_flush try_to_unmap_one rmap_walk try_to_unmap migrate_pages migrate_misplaced_page - handle_mm_fault - 99.73% __do_page_fault trace_do_page_fault do_async_page_fault + async_page_fault 0.63% native_send_call_func_single_ipi generic_exec_single smp_call_function_single This was bisected to commit 4d9424669946 (mm: convert p[te|md]_mknonnuma and remaining page table manipulations) which clears PTEs and PMDs to make them PROT_NONE. This is tidy but tests on some benchmarks indicate that there are many more hinting faults trapped resulting in excessive migration. This is the result for the old autonuma benchmark for example. autonumabench 4.0.0-rc1 4.0.0-rc1 3.19.0 vanillanoclear-v1 vanilla Time User-NUMA01 32883.59 ( 0.00%)27401.21 ( 16.67%) 25695.96 ( 21.86%) Time User-NUMA01_THEADLOCAL 17453.20 ( 0.00%)17491.98 ( -0.22%) 17404.36 ( 0.28%) Time User-NUMA02 2063.70 ( 0.00%) 2059.94 ( 0.18%) 2037.65 ( 1.26%) Time User-NUMA02_SMT983.70 ( 0.00%) 967.95 ( 1.60%) 981.02 ( 0.27%) Time System-NUMA01 602.44 ( 0.00%) 182.16 ( 69.76%) 194.70 ( 67.68%) Time System-NUMA01_THEADLOCAL78.10 ( 0.00%) 84.84 ( -8.63%) 98.52 (-26.15%) Time System-NUMA026.47 ( 0.00%)9.74 (-50.54%) 9.28 (-43.43%) Time System-NUMA02_SMT5.06 ( 0.00%)3.97 ( 21.54%) 3.79 ( 25.10%) Time Elapsed-NUMA01 755.96 ( 0.00%) 602.20 ( 20.34%) 558.84 ( 26.08%) Time Elapsed-NUMA01_THEADLOCAL 382.22 ( 0.00%) 384.98 ( -0.72%) 382.54 ( -0.08%) Time Elapsed-NUMA02 49.38 ( 0.00%) 49.23 ( 0.30%) 49.83 ( -0.91%) Time Elapsed-NUMA02_SMT 47.70 ( 0.00%) 46.82 ( 1.84%) 46.59 ( 2.33%) Time CPU-NUMA014429.00 ( 0.00%) 4580.00 ( -3.41%) 4632.00 ( -4.58%) Time CPU-NUMA01_THEADLOCAL 4586.00 ( 0.00%) 4565.00 ( 0.46%) 4575.00 ( 0.24%) Time CPU-NUMA024191.00 ( 0.00%) 4203.00 ( -0.29%) 4107.00 ( 2.00%) Time CPU-NUMA02_SMT2072.00 ( 0.00%) 2075.00 ( -0.14%) 2113.00 ( -1.98%) Note the system CPU usage with the patch applied and how it's similar to 3.19-vanilla. The NUMA hinting activity is also restored to similar levels. 4.0.0-rc1 4.0.0-rc1 3.19.0 vanillanoclear-v1r13 vanilla NUMA alloc hit 1437560 1241466 1202922 NUMA alloc miss 0 0 0 NUMA interleave hit 0 0 0 NUMA alloc local 1436781 1240849 1200683 NUMA base PTE updates304513172 223926293 222840103 NUMA huge PMD updates 594467 437025 434894 NUMA page range updates 608880276 447683093 445505831 NUMA hint faults733491 598990 601358 NUMA hint local faults 511530 314936 371571 NUMA hint local percent 69 52 61 NUMA pages migrated 26366701 5424102 7073177 Signed-off-by: Mel Gorman mgor...@suse.de --- arch/powerpc/include/asm/pgtable-ppc64.h | 16 arch/x86/include/asm/pgtable.h | 14 ++ include/asm-generic/pgtable.h| 19 +++ mm/huge_memory.c | 19 --- mm/mprotect.c| 5 + 5 files changed, 70 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h index 43e6ad424c7f..bb654c192028 100644 --- a/arch/powerpc/include/asm/pgtable-ppc64.h +++
[RFC PATCH 0/2] Automatic NUMA balancing and PROT_NONE handling followup
Dave Chinner reported a problem due to excessive NUMA balancing activity and bisected it. These are two patches that address two major issues with that series. The first patch is almost certainly unrelated to what he saw due to fact his vmstats showed no huge page activity but the fix is important. The second patch restores performance of one benchmark to similar levels to 3.19-vanilla but it still has to be tested on his workload. While I have a test configuration for his workload, I don't have either the KVM setup or suitable storage to test against. It also needs to be reviewed and tested on ppc64. arch/powerpc/include/asm/pgtable-ppc64.h | 16 arch/x86/include/asm/pgtable.h | 14 ++ include/asm-generic/pgtable.h| 19 +++ mm/huge_memory.c | 23 ++- mm/mprotect.c| 5 + 5 files changed, 72 insertions(+), 5 deletions(-) -- 2.1.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/
Qemu e1000 broken in -rc1 and -rc2
I have a very recent qemu i686 image, using a 3.19.0 kernel and dhclient, which works fine if the host is running a 3.19.0 kernel, but breaks when the host runs 4.0.0-rc1 or -rc2. On those, dhclient does not get an address, so I have no network. There is a message e1000 :00:03.0 eth0: Reset adaptor Before I start trying to bisect this, has anybody already seen, or fixed, it ? ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- 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] KVM: ioapic: Record edge-triggered interrupts delivery status.
On Wed, Dec 24, 2014 at 11:14:29AM +0800, Wincy Van wrote: This patch fixes the bug discussed in https://www.mail-archive.com/kvm@vger.kernel.org/msg109813.html This patch uses a new field named irr_delivered to record the delivery status of edge-triggered interrupts, and clears the delivered interrupts in kvm_get_ioapic. So it has the same effect of commit 0bc830b05c667218d703f2026ec866c49df974fc (KVM: ioapic: clear IRR for edge-triggered interrupts at delivery) while avoids the bug of Windows guests. Signed-off-by: Wincy Van fanwenyi0...@gmail.com Applied, 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 v2] sched, timer: Use atomics for thread_group_cputimer to improve scalability
On Thu, 2015-03-05 at 16:35 +0100, Frederic Weisbecker wrote:
On Mon, Mar 02, 2015 at 10:42:11AM -0800, Jason Low wrote:
+/* Sample thread_group_cputimer values in cputimer, copy results to
times */
+static inline void sample_group_cputimer(struct task_cputime *times,
+struct thread_group_cputimer *cputimer)
+{
+times-utime = atomic64_read(cputimer-utime);
+times-stime = atomic64_read(cputimer-stime);
+times-sum_exec_runtime =
atomic64_read(cputimer-sum_exec_runtime);
So, in the case we are calling that right after setting cputimer-running, I
guess we are fine
because we just updated cputimer with the freshest values.
But if we are reading this a while after, say several ticks further, there is
a chance that
we read stale values since we don't lock anymore.
I don't know if it matters or not, I guess it depends how stale it can be and
how much precision
we expect from posix cpu timers. It probably doesn't matter.
But just in case, atomic64_read_return(cputimer-utime, 0) would make sure
we get the freshest
value because it performs a full barrier, at the cost of more overhead of
course.
(Assuming that is atomic64_add_return :))
Yeah, there aren't any guarantees that we read the freshest value, but
since the lock isn't used to serialize subsequent accesses of
times-utime, ect..., the values can potentially become stale by the
time they get used anyway, even when we have the locking.
So I'm not sure if atomic64_add_return(time, 0) for the reads would
really provide much of a benefit when we factor in the extra overhead.
--
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: [Xen-devel] [PATCHv1] x86: don't schedule when handling #NM exception
On 06/23/2014 06:08 AM, Konrad Rzeszutek Wilk wrote: On Wed, Mar 19, 2014 at 08:02:22AM -0700, H. Peter Anvin wrote: On 03/19/2014 06:21 AM, Konrad Rzeszutek Wilk wrote: The following patch does the always eager allocation. It's a fixup of Suresh's original patch. Hey Peter, I think this is the solution you were looking for? Or are there some other subtle issues that you think lurk around? Ah, I managed to miss it (mostly because it was buried *inside* another email and didn't change the subject line... I really dislike that mode of delivering a patch. Let me roll up some of these patchset and send them as git send-email. Let me see if the issues have been fixed. Still wondering if there is a way we can get away without the boot_func hack... I have to confesss I don't even remember what the 'if the issues have been fixed' is referring to? Hi Konrad... it looks like this got left waiting for you and got forgotten? -hpa -- 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: Oops with tip/x86/fpu
On 03/05/2015 10:42 AM, Borislav Petkov wrote: On Thu, Mar 05, 2015 at 04:13:38PM +0100, Oleg Nesterov wrote: Yes, yes, sure. That is what I meant, sorry for confusion. It might be worth to try with Quentin's patch which fixes the exception tables. I can imagine with wrong exception tables us jumping somewhere in the fields and causing this #GP and XRSTORS being there at rIP but not really causing the #GP itself. Which patch of Quentin's is this that you want to see tested? -- 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 0/5] x86: IA32 emulation cleanups
On 03/03/2015 10:22 PM, Brian Gerst wrote: It looks like most cases can simply be replaced. There are some subtle relations with the x32 ABI though, and that will take some time to sort out. Yes, some aspects of CONFIG_COMPAT is used also by x32. Overall the current Linux kernel handles the case of *more* than two ABIs extremely poorly. It is not the only case of more than two ABIs, either; consider ARM for example. -hpa -- 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 0/3 v5] e820: Fix handling of NvDIMM chips
Seriously, if type 12 is the de facto standard for NvDIMMs, I think we should add it. The documented ACPI method of using flags was doomed from the start. -hpa -- 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] e820: Add the unknown-12 Memory type (DDR3-NvDIMM)
On Thu, Mar 5, 2015 at 12:56 PM, Dan Williams dan.j.willi...@intel.com wrote: On Thu, Mar 5, 2015 at 2:24 AM, Boaz Harrosh b...@plexistor.com wrote: There are multiple vendors of DDR3 NvDIMMs out in the market today. At various stages of development/production. It is estimated that there are already more the 100ds of thousands chips sold to testers and sites. All the BIOS vendors I know of, tagged these chips at e820 table as type-12 memory. Now the ACPI comity, as far as I know, did not yet define a standard type for NvDIMM. Also, as far as I know any NvDIMM standard will only be defined for DDR4. So DDR3 NvDIMM is probably stuck with this none STD type. There's no relation between E820 types and DDR technology revisions. I Wish and call the ACPI comity to Define that NvDIMM is type-12. Also for DDR4 The motivation of this patch is to be able to differentiate this NvDIMM type from a real future unknown-reserved type. In this patch I name type-12 unknown-12. This is because of ACPI politics that refuse to reserve type-12 as DDR3-NvDIMM It's not politics. Setting standards takes time and the platforms in question simply jumped the gun to enable a proof-of-concept. and members keep saying: What if ACPI assigns type-12 for something else in future [And I say: Then just don't. Please?] Once a standard number is assigned, platform firmwares can update type-12 to that number. We might consider a compile time override for these niche/pre-standard systems that can't/won't update, but it's not clear to me that we even need to go that far. I will be shocked if a standard of this form ever appears. Modern systems *don't have e820*. The BIOSes that are using this type 12 hack are awful throwbacks. --Andy -- 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] Fix undefined ioremap_huge_init when CONFIG_MMU is not set
On Fri, 2015-03-06 at 10:41 +1100, Stephen Rothwell wrote: Hi Toshi, On Thu, 5 Mar 2015 08:44:06 -0700 Toshi Kani toshi.k...@hp.com wrote: Fix a build error, undefined reference to ioremap_huge_init, when CONFIG_MMU is not defined on linux-next and -mm tree. lib/ioremap.o is not linked to the kernel when CONFIG_MMU is not defined. Signed-off-by: Toshi Kani toshi.k...@hp.com --- include/linux/io.h |5 +++-- lib/ioremap.c |1 - 2 files changed, 3 insertions(+), 3 deletions(-) Added to my copy of the akpm-current tree today (and so into linux-next). Thanks Stephen! -Toshi -- 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] Fix build errors in asm-generic/pgtable.h
Hi Toshi, On Thu, 5 Mar 2015 09:40:07 -0700 Toshi Kani toshi.k...@hp.com wrote: Fix build errors in pud_set_huge() and pmd_set_huge() in asm-generic/pgtable.h on some architectures in linux-next and -mm trees. C-stype code needs be used under #ifndef __ASSEMBLY__. Signed-off-by: Toshi Kani toshi.k...@hp.com --- include/asm-generic/pgtable.h | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) Added to my copy of the akpm-current tree today (and thus to linux-next). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpFyUyUWGCwl.pgp Description: OpenPGP digital signature
[PATCH 18/21] userfaultfd: UFFDIO_REMAP uABI
This implements the uABI of UFFDIO_REMAP.
Notably one mode bitflag is also forwarded (and in turn known) by the
lowlevel remap_pages method.
Signed-off-by: Andrea Arcangeli aarca...@redhat.com
---
include/uapi/linux/userfaultfd.h | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/userfaultfd.h b/include/uapi/linux/userfaultfd.h
index 61251e6..db6e99a 100644
--- a/include/uapi/linux/userfaultfd.h
+++ b/include/uapi/linux/userfaultfd.h
@@ -19,7 +19,8 @@
#define UFFD_API_RANGE_IOCTLS \
((__u64)1 _UFFDIO_WAKE | \
(__u64)1 _UFFDIO_COPY | \
-(__u64)1 _UFFDIO_ZEROPAGE)
+(__u64)1 _UFFDIO_ZEROPAGE | \
+(__u64)1 _UFFDIO_REMAP)
/*
* Valid ioctl command number range with this API is from 0x00 to
@@ -34,6 +35,7 @@
#define _UFFDIO_WAKE (0x02)
#define _UFFDIO_COPY (0x03)
#define _UFFDIO_ZEROPAGE (0x04)
+#define _UFFDIO_REMAP (0x05)
#define _UFFDIO_API(0x3F)
/* userfaultfd ioctl ids */
@@ -50,6 +52,8 @@
struct uffdio_copy)
#define UFFDIO_ZEROPAGE_IOWR(UFFDIO, _UFFDIO_ZEROPAGE, \
struct uffdio_zeropage)
+#define UFFDIO_REMAP _IOWR(UFFDIO, _UFFDIO_REMAP,\
+ struct uffdio_remap)
/*
* Valid bits below PAGE_SHIFT in the userfault address read through
@@ -122,4 +126,25 @@ struct uffdio_zeropage {
__s64 wake;
};
+struct uffdio_remap {
+ __u64 dst;
+ __u64 src;
+ __u64 len;
+ /*
+* Especially if used to atomically remove memory from the
+* address space the wake on the dst range is not needed.
+*/
+#define UFFDIO_REMAP_MODE_DONTWAKE ((__u64)10)
+#define UFFDIO_REMAP_MODE_ALLOW_SRC_HOLES ((__u64)11)
+ __u64 mode;
+
+ /*
+* remap and wake are written by the ioctl and must be at
+* the end: the copy_from_user will not read the last 16
+* bytes.
+*/
+ __s64 remap;
+ __s64 wake;
+};
+
#endif /* _LINUX_USERFAULTFD_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: [PATCH 2/2] phy: usbphy: Add Broadcom Cygnus USB PHY driver
Hi Arun,
On Tue, Feb 17, 2015 at 11:20:21AM -0800, Arun Ramamurthy wrote:
This driver adds support for USB 2.0 host and device phy
for Broadcom's Cygnus chipset
Mostly nitpicks...
Reviewed-by: Ray Jui r...@broadcom.com
Reviewed-by: Scott Branden sbran...@broadcom.com
Signed-off-by: Arun Ramamurthy arun.ramamur...@broadcom.com
---
drivers/phy/Kconfig | 12 +
drivers/phy/Makefile | 2 +
drivers/phy/phy-bcm-cygnus-usb.c | 491
+++
3 files changed, 505 insertions(+)
create mode 100644 drivers/phy/phy-bcm-cygnus-usb.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index ccad880..c934090 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -277,4 +277,16 @@ config PHY_STIH41X_USB
Enable this to support the USB transceiver that is part of
STMicroelectronics STiH41x SoC series.
+config PHY_BCM_CYGNUS_USB
+ tristate Broadcom Cygnus USB PHY support
+ depends on OF
+ depends on ARCH_BCM_CYGNUS
+ select GENERIC_PHY
+ default ARCH_BCM_CYGNUS
+ help
+ Enable this to support the USB PHY in Broadcom's Cygnus chip.
+ The phys are capable of supporting host mode for all ports
+ and device mode for port 2. The host or device configuration is
+ read from the device tree.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index aa74f96..b235677 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_PHY_BERLIN_USB) += phy-berlin-usb.o
obj-$(CONFIG_PHY_BERLIN_SATA)+= phy-berlin-sata.o
obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) += phy-armada375-usb2.o
obj-$(CONFIG_BCM_KONA_USB2_PHY) += phy-bcm-kona-usb2.o
+obj-$(CONFIG_PHY_BCM_CYGNUS_USB) += phy-bcm-cygnus-usb.o
obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO)+= phy-exynos-dp-video.o
obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
obj-$(CONFIG_PHY_MVEBU_SATA) += phy-mvebu-sata.o
@@ -34,3 +35,4 @@ obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)+=
phy-spear1340-miphy.o
obj-$(CONFIG_PHY_XGENE) += phy-xgene.o
obj-$(CONFIG_PHY_STIH407_USB)+= phy-stih407-usb.o
obj-$(CONFIG_PHY_STIH41X_USB)+= phy-stih41x-usb.o
+
diff --git a/drivers/phy/phy-bcm-cygnus-usb.c
b/drivers/phy/phy-bcm-cygnus-usb.c
new file mode 100644
index 000..e5d3e50
--- /dev/null
+++ b/drivers/phy/phy-bcm-cygnus-usb.c
@@ -0,0 +1,491 @@
+/*
+ * Copyright (C) 2014 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/phy/phy.h
+#include linux/delay.h
+#include linux/regulator/consumer.h
+
+#define CDRU_USBPHY_CLK_RST_SEL_OFFSET 0x11b4
+#define CDRU_USBPHY2_HOST_DEV_SEL_OFFSET 0x11b8
+#define CDRU_SPARE_REG_0_OFFSET 0x1238
+#define CRMU_USB_PHY_AON_CTRL_OFFSET 0x00028
+#define CDRU_USB_DEV_SUSPEND_RESUME_CTRL_OFFSET 0x1210
+#define CDRU_USBPHY_P2_STATUS_OFFSET 0x1200
+
+#define CDRU_USB_DEV_SUSPEND_RESUME_CTRL_DISABLE 0
+#define PHY2_DEV_HOST_CTRL_SEL_DEVICE0
+#define PHY2_DEV_HOST_CTRL_SEL_HOST 1
Do we need these 2? Seems like a boolean for host mode to me.
+#define CDRU_USBPHY_P2_STATUS__USBPHY_ILDO_ON_FLAG 1
+#define CDRU_USBPHY_P2_STATUS__USBPHY_PLL_LOCK 0
+#define CRMU_USBPHY_P0_AFE_CORERDY_VDDC 1
+#define CRMU_USBPHY_P0_RESETB2
+#define CRMU_USBPHY_P1_AFE_CORERDY_VDDC 9
+#define CRMU_USBPHY_P1_RESETB10
+#define CRMU_USBPHY_P2_AFE_CORERDY_VDDC 17
+#define CRMU_USBPHY_P2_RESETB18
+
+#define USB2_IDM_IDM_IO_CONTROL_DIRECT_OFFSET0x0408
+#define USB2_IDM_IDM_IO_CONTROL_DIRECT__clk_enable 0
+#define USB2_IDM_IDM_RESET_CONTROL_OFFSET0x0800
+#define USB2_IDM_IDM_RESET_CONTROL__RESET0
+
+#define PLL_LOCK_RETRY_COUNT 1000
+#define MAX_REGULATOR_NAME_LEN 25
+
+struct bcm_phy_instance;
+
+struct bcm_phy_driver {
+ void __iomem *usbphy_regs;
+ void __iomem *usb2h_idm_regs;
+ void __iomem *usb2d_idm_regs;
+ spinlock_t lock;
+ int num_phys,
[PATCH -next] sensors: fix build of pwm-fan.c when THERMAL=m
From: Randy Dunlap rdun...@infradead.org Fix build errors when CONFIG_THERMAL=m and SENSORS_PWM_FAN=y by restricting SENSORS_PWM_FAN to 'm' when THERMAL=m. drivers/built-in.o: In function `pwm_fan_remove': pwm-fan.c:(.text+0x22ba58): undefined reference to `thermal_cooling_device_unregister' drivers/built-in.o: In function `pwm_fan_probe': pwm-fan.c:(.text+0x22bebb): undefined reference to `thermal_of_cooling_device_register' pwm-fan.c:(.text+0x22bf11): undefined reference to `thermal_cdev_update' Signed-off-by: Randy Dunlap rdun...@infradead.org Cc: Kamil Debski k.deb...@samsung.com --- drivers/hwmon/Kconfig |1 + 1 file changed, 1 insertion(+) --- linux-next-20150305.orig/drivers/hwmon/Kconfig +++ linux-next-20150305/drivers/hwmon/Kconfig @@ -1174,6 +1174,7 @@ source drivers/hwmon/pmbus/Kconfig config SENSORS_PWM_FAN tristate PWM fan depends on (PWM OF) || COMPILE_TEST + depends on THERMAL || THERMAL=n help If you say yes here you get support for fans connected to PWM lines. The driver uses the generic PWM interface, thus it will work on a -- 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] Fix undefined ioremap_huge_init when CONFIG_MMU is not set
Hi Toshi, On Thu, 5 Mar 2015 08:44:06 -0700 Toshi Kani toshi.k...@hp.com wrote: Fix a build error, undefined reference to ioremap_huge_init, when CONFIG_MMU is not defined on linux-next and -mm tree. lib/ioremap.o is not linked to the kernel when CONFIG_MMU is not defined. Signed-off-by: Toshi Kani toshi.k...@hp.com --- include/linux/io.h |5 +++-- lib/ioremap.c |1 - 2 files changed, 3 insertions(+), 3 deletions(-) Added to my copy of the akpm-current tree today (and so into linux-next). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpCjPd9ksOOa.pgp Description: OpenPGP digital signature
Re: linux-next: Tree for Mar 5 (iwlwifi/mvm)
On 03/04/15 19:34, Stephen Rothwell wrote: Hi all, Changes since 20150304: on i386, when IWLWIFI_DEBUGFS is not enabled: ../drivers/net/wireless/iwlwifi/mvm/phy-ctxt.c:179:38: error: 'struct iwl_mvm' has no member named 'dbgfs_rx_phyinfo' ../drivers/net/wireless/iwlwifi/mvm/mac-ctxt.c:1378:30: error: 'struct iwl_mvm_vif' has no member named 'mvm' -- ~Randy -- 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 1/2] mm: thp: Return the correct value for change_huge_pmd
The wrong value is being returned by change_huge_pmd since commit
10c1045f28e8 (mm: numa: avoid unnecessary TLB flushes when setting
NUMA hinting entries) which allows a fallthrough that tries to adjust
non-existent PTEs. This patch corrects it.
Signed-off-by: Mel Gorman mgor...@suse.de
---
mm/huge_memory.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index fc00c8cb5a82..194c0f019774 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1482,6 +1482,7 @@ int change_huge_pmd(struct vm_area_struct *vma, pmd_t
*pmd,
if (__pmd_trans_huge_lock(pmd, vma, ptl) == 1) {
pmd_t entry;
+ ret = 1;
/*
* Avoid trapping faults against the zero page. The read-only
@@ -1490,11 +1491,10 @@ int change_huge_pmd(struct vm_area_struct *vma, pmd_t
*pmd,
*/
if (prot_numa is_huge_zero_pmd(*pmd)) {
spin_unlock(ptl);
- return 0;
+ return ret;
}
if (!prot_numa || !pmd_protnone(*pmd)) {
- ret = 1;
entry = pmdp_get_and_clear_notify(mm, addr, pmd);
entry = pmd_modify(entry, newprot);
ret = HPAGE_PMD_NR;
--
2.1.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: [PATCH v2 5/6] watchdog: at91sam9: request the irq with IRQF_NO_SUSPEND
On Thursday, March 05, 2015 04:32:27 PM Mark Rutland wrote: Hi Rafael, enable_irq_wake() has no effect on IRQF_NO_SUSPEND interrupts, so if the driver uses IRQF_NO_SUSPEND, it does not need to use enable_irq_wake() in addition to that. That's not generally true -- certainly not for irq_chips without the IRQCHIP_SKIP_SET_WAKE flag. Consider systems where the suspended state results in power to the CPU being cut, and we rely on an external piece of logic attached to the irq_chip to detect wakeup IRQs and restore power. In those cases irq_chip::irq_set_wake() must be called to ensure that the wakeup logic is configured. If the wakeup logic is not configured to look out for an IRQ, then when the IRQ is asserted by a device the wakeup logic may not trigger. Thus the CPU power never gets restored, so the CPU cannot handle the interrupt. This is handled in enable_irq_wake() -- either the chip has the IRQCHIP_SKIP_SET_WAKE flag set or chip-irq_set_wake() must succeed. If neither is true enable_irq_wake() will return an error code to indicate we can't use the IRQ for wakeup. Right. I forgot about that part. The request_irq path never results in a call to chip-irq_set_wake(), even with the IRQF_NO_SUSPEND flag. So requesting an irq with IRQF_NO_SUSPEND does not guarantee wakeup; it only guarantees that the CPU can take the interrupt _around_ the suspended state, not necessarily while _in_ the suspended state. Right. Suspended state meaning full suspend here I suppose? Drivers using IRQF_COND_SUSPEND generally should use enable_irq_wake() too in case they end up in a situation without sharing a NO_SUSPEND interrupt, in which case their interrupt handlers won't be called after suspend_device_irqs(), so they need to rely on the core to do the wakeup. I agree that if problematic, it's an existing bug. Given Boris's comments in the other thread this may just a minor semantic issue w.r.t. IRQF_NO_SUSPEND vs IRQF_COND_SUSPEND. It depends on whether or not the watchdog's interrupt handler has to be called immediately after receiving an interrupt (IRQF_NO_SUSPEND is better then) or it can be deferred till the resume_device_irqs() time. We seem to be conflating some related properties: [a] The IRQ will be left unmasked. [b] The IRQ will be handled immediately when taken. [c] The IRQ will wake the system from suspend. Requesting an IRQ with IRQF_NO_SUSPEND guarantees [a,b], but does not guarantee [c]. That's correct. IRQF_NO_SUSPEND does not guarantee that interrupts from that IRQ will have any effect after arch_suspend_disable_irqs() in suspend_enter(). A successful enable_irq_wake() on an IRQ guarantees [a,c], but usually does not give [b] unless the IRQ was requested with IRQF_COND_SUSPEND and happens to be shared with an IRQF_NO_SUSPEND user. That's correct too. It sounds like for this kind of watchdog device we want [a,b,c], even if the IRQ is not shared with an IRQF_NO_SUSPEND user. We can't guarantee that, though. arch_suspend_disable_irqs() disables interrupts on the last working CPU and it won't get any. It may be brought out of a low-power state by a pending interrupt, but it won't act upon that interrupt immediately anyway, only after the arch_suspend_enable_irqs() in suspend_enter(). But then it might as well be deferred until after resume_device_irqs(). 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 v9 16/21] irqchip: Add GICv2 specific ACPI boot support
On Thursday, March 05, 2015 11:53:22 AM Catalin Marinas wrote:
On Wed, Mar 04, 2015 at 11:50:36PM +0100, Rafael J. Wysocki wrote:
On Wednesday, February 25, 2015 04:39:56 PM Hanjun Guo wrote:
[cut]
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index c03d8d1..e27117a 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -557,6 +557,20 @@ static inline int acpi_device_modalias(struct device
*dev,
#endif /* !CONFIG_ACPI */
+#if defined(CONFIG_ACPI) defined(CONFIG_ARM64)
+static inline void acpi_irq_init(void)
+{
+ /*
+ * Hardcode ACPI IRQ chip initialization to GICv2 for now.
+ * Proper irqchip infrastructure will be implemented along with
+ * incoming GICv2m|GICv3|ITS bits.
+ */
+ acpi_gic_init();
+}
+#else
+static inline void acpi_irq_init(void) { }
+#endif
I don't want this in a common header.
I don't like it either. What about adding it to a new header,
linux/acpi_irq.h just for the dummy acpi_irq_init()? This would be
similar to the DT equivalent, of_irq_init() in linux/of_irq.h and at
some point it will gain more macros for declaring interrupt controllers
in the ACPI context.
What we objected to previously was calling acpi_gic_init() directly from
the core irqchip_init() and asked for something similar to the more
generic of_irq_init(). The arm64-specific patch above is clearly a
temporary hack until full support for multiple interrupt controllers is
added (we asked for this several times in the past, but the ARM ACPI
guys thought it's too much hassle ;). I don't fully get it since one of
the platforms they target needs GICv2m support anyway).
Anyway, if we are to keep the temporary hack, I think we could define
something like below (possibly in a new linux/acpi_irq.h which includes
asm/irq.h):
#ifndef acpi_irq_init
static inline void acpi_irq_init(void)
{
}
#endif
And in the arm64 asm/irq.h:
static inline void acpi_irq_init(void)
{
/*
* Hardcode ACPI IRQ chip initialization to GICv2 for now.
* Proper irqchip infrastructure will be implemented along with
* incoming GICv2m|GICv3|ITS bits.
*/
acpi_gic_init();
}
#define acpi_irq_init acpi_irq_init
When the new infrastructure is in place, we can get rid of the #ifndef
and arm64-specific acpi_irq_init().
Well, that sounds much better than the original patch.
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: [RFC 0/6] the big khugepaged redesign
Long mail ahead, sorry for that. TL;DR: THP is still noticeable, but not nearly as bad. On 2015-03-05 17:30:16 +0100, Vlastimil Babka wrote: That however means the workload is based on hugetlbfs and shouldn't trigger THP page fault activity, which is the aim of this patchset. Some more googling made me recall that last LSF/MM, postgresql people mentioned THP issues and pointed at compaction. See http://lwn.net/Articles/591723/ That's exactly where this patchset should help, but I obviously won't be able to measure this before LSF/MM... Just as a reference, this is how some the more extreme profiles looked like in the past: 96.50%postmaster [kernel.kallsyms] [k] _spin_lock_irq | --- _spin_lock_irq | |--99.87%-- compact_zone | compact_zone_order | try_to_compact_pages | __alloc_pages_nodemask | alloc_pages_vma | do_huge_pmd_anonymous_page | handle_mm_fault | __do_page_fault | do_page_fault | page_fault | 0x631d98 --0.13%-- [...] That specific profile is from a rather old kernel as you probably recognize. I'm CCing the psql guys from last year LSF/MM - do you have any insight about psql performance with THPs enabled/disabled on recent kernels, where e.g. compaction is no longer synchronous for THP page faults? So, I've managed to get a machine upgraded to 3.19. 4 x E5-4620, 256GB RAM. First of: It's noticeably harder to trigger problems than it used to be. But, I can still trigger various problems that are much worse with THP enabled than without. There seem to be various different bottlenecks; I can get somewhat different profiles. In a somewhat artificial workload, that tries to simulate what I've seen trigger the problem at a customer, I can quite easily trigger large differences between THP=enable and THP=never. There's two types of tasks running, one purely OLTP, another doing somewhat more complex statements that require a fair amount of process local memory. (ignore the absolute numbers for progress, I just waited for somewhat stable results while doing other stuff) THP off: Task 1 solo: progress: 200.0 s, 391442.0 tps, 0.654 ms lat progress: 201.0 s, 394816.1 tps, 0.683 ms lat progress: 202.0 s, 409722.5 tps, 0.625 ms lat progress: 203.0 s, 384794.9 tps, 0.665 ms lat combined: Task 1: progress: 144.0 s, 25430.4 tps, 10.067 ms lat progress: 145.0 s, 22260.3 tps, 11.500 ms lat progress: 146.0 s, 24089.9 tps, 10.627 ms lat progress: 147.0 s, 25888.8 tps, 9.888 ms lat Task 2: progress: 24.4 s, 30.0 tps, 2134.043 ms lat progress: 26.5 s, 29.8 tps, 2150.487 ms lat progress: 28.4 s, 29.7 tps, 2151.557 ms lat progress: 30.4 s, 28.5 tps, 2245.304 ms lat flat profile: 6.07% postgres postgres[.] heap_form_minimal_tuple 4.36% postgres postgres[.] heap_fill_tuple 4.22% postgres postgres[.] ExecStoreMinimalTuple 4.11% postgres postgres[.] AllocSetAlloc 3.97% postgres postgres[.] advance_aggregates 3.94% postgres postgres[.] advance_transition_function 3.94% postgres postgres[.] ExecMakeTableFunctionResult 3.33% postgres postgres[.] heap_compute_data_size 3.30% postgres postgres[.] MemoryContextReset 3.28% postgres postgres[.] ExecScan 3.04% postgres postgres[.] ExecProject 2.96% postgres postgres[.] generate_series_step_int4 2.94% postgres [kernel.kallsyms] [k] clear_page_c (i.e. most of it postgres, cache miss bound) THP on: Task 1 solo: progress: 140.0 s, 390458.1 tps, 0.656 ms lat progress: 141.0 s, 391174.2 tps, 0.654 ms lat progress: 142.0 s, 394828.8 tps, 0.648 ms lat progress: 143.0 s, 398156.2 tps, 0.643 ms lat Task 1: progress: 179.0 s, 23963.1 tps, 10.683 ms lat progress: 180.0 s, 22712.9 tps, 11.271 ms lat progress: 181.0 s, 21211.4 tps, 12.069 ms lat progress: 182.0 s, 23207.8 tps, 11.031 ms lat Task 2: progress: 28.2 s, 19.1 tps, 3349.747 ms lat progress: 31.0 s, 19.8 tps, 3230.589 ms lat progress: 34.3 s, 21.5 tps, 2979.113 ms lat progress: 37.4 s, 20.9 tps, 3055.143 ms lat flat profile: 21.36% postgres [kernel.kallsyms] [k] pageblock_pfn_to_page 4.93% postgres postgres[.] ExecStoreMinimalTuple 4.02% postgres postgres[.] heap_form_minimal_tuple 3.55% postgres [kernel.kallsyms] [k] clear_page_c 2.85% postgres postgres[.] heap_fill_tuple 2.60% postgres postgres[.] ExecMakeTableFunctionResult 2.57%
Re: [PATCH] genirq: describe IRQF_COND_SUSPEND
On Thursday, March 05, 2015 11:04:11 AM Mark Rutland wrote: On Wed, Mar 04, 2015 at 10:17:29PM +, Alexandre Belloni wrote: tiny tiny nitpick: On 04/03/2015 at 20:00:40 +, Mark Rutland wrote : With certain restrictions it is possible for a wakeup device to share and IRQ with an IRQF_NO_SUSPEND user, and the warnings introduced by ^ an Whoops. Rafael, are you happy to fix that up, or would you like me to resend? Fixed, 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/
[PATCH 0/4] Minimal generic wakeirq helpers
Hi all, Here's an attempt to have Linux generic wakeirq helpers. This allows removing most of the related code from drivers. Currently the drivers all do it in a slightly different way. And may have issues with interrupt re-entrancy and getting the suspend/resume vs runtime_pm wake handling right. This is for wakerirqs that are available for some devices in addition to the regular device interrupts. The seprate always-on wake-up interrupt controller is needed to allow devices and the SoC to enter deeper idle states and still be able to wake-up to events. Some of this was discussed in the kernel/irq context a while back [1]. But it seems that this can be done in drivers/base/power. If somebody has hardware that needs to replay lost device interrupts based on the wake-up interrupts, then additional kernel/irq changes will be needed. This set fixes up three drivers to use the generic wakeirq. Note that eventually the wakeirq handling for these drivers might end up in a bus specific code and could be hidden away from the drivers. Regards, Tony [1] https://lkml.org/lkml/2014/11/13/458 Tony Lindgren (4): PM / Wakeirq: Add minimal device wakeirq helper functions serial: 8250_omap: Move wake-up interrupt to generic wakeirq serial: omap: Switch wake-up interrupt to generic wakeirq mmc: omap_hsmmc: Change wake-up interrupt to use generic wakeirq arch/arm/mach-omap2/Kconfig | 1 + drivers/base/power/Makefile | 1 + drivers/base/power/wakeirq.c| 201 drivers/mmc/host/omap_hsmmc.c | 55 +++--- drivers/tty/serial/8250/8250_omap.c | 67 +++- drivers/tty/serial/omap-serial.c| 38 +++ include/linux/pm_wakeirq.h | 69 + kernel/power/Kconfig| 4 + 8 files changed, 318 insertions(+), 118 deletions(-) create mode 100644 drivers/base/power/wakeirq.c create mode 100644 include/linux/pm_wakeirq.h -- 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/
[PATCH v3 0/1] drivers/bus: fsl-mc object allocator driver
This patch series introduces the object allocator driver for the Freescale Management Complex (fsl-mc) of QorIQ Ls2 SoCs This patch series is dependent on the patch series drivers/bus: Freescale Management Complex bus driver patch series Besides adding the object allocator functionality. CHANGE HISTORY See patch -- 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 v4 2/2] cgroups: add a pids subsystem
Adds a new single-purpose pids subsystem to limit the number of
tasks that can run inside a cgroup. Essentially this is an
implementation of RLIMIT_NPROC that will applies to a cgroup rather than
a process tree.
PIDs are fundamentally a global resource, and it is possible to reach
PID exhaustion inside a cgroup without hitting any reasonable kmemcg
policy. Once you've hit PID exhaustion, you're only in a marginally
better state than OOM. This subsystem allows PID exhaustion inside a
cgroup to be prevented.
Signed-off-by: Aleksa Sarai cyp...@cyphar.com
---
include/linux/cgroup_subsys.h | 4 +
init/Kconfig | 11 ++
kernel/Makefile | 1 +
kernel/cgroup_pids.c | 282 ++
4 files changed, 298 insertions(+)
create mode 100644 kernel/cgroup_pids.c
diff --git a/include/linux/cgroup_subsys.h b/include/linux/cgroup_subsys.h
index e4a96fb..a198822 100644
--- a/include/linux/cgroup_subsys.h
+++ b/include/linux/cgroup_subsys.h
@@ -47,6 +47,10 @@ SUBSYS(net_prio)
SUBSYS(hugetlb)
#endif
+#if IS_ENABLED(CONFIG_CGROUP_PIDS)
+SUBSYS(pids)
+#endif
+
/*
* The following subsystems are not supported on the default hierarchy.
*/
diff --git a/init/Kconfig b/init/Kconfig
index f5dbc6d..88364c9 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1054,6 +1054,17 @@ config CGROUP_HUGETLB
control group is tracked in the third page lru pointer. This means
that we cannot use the controller with huge page less than 3 pages.
+config CGROUP_PIDS
+ bool Process number limiting on cgroups
+ help
+ This options enables the setting of process number limits in the scope
+ of a cgroup. Any attempt to fork more processes than is allowed in the
+ cgroup will fail. PIDs are fundamentally a global resource because it
+ is fairly trivial to reach PID exhaustion before you reach even a
+ conservative kmemcg limit. As a result, it is possible to grind a
+ system to halt without being limited by other cgroup policies. The
pids
+ cgroup subsystem is designed to stop this from happening.
+
config CGROUP_PERF
bool Enable perf_event per-cpu per-container group (cgroup) monitoring
depends on PERF_EVENTS CGROUPS
diff --git a/kernel/Makefile b/kernel/Makefile
index 1408b33..e823592 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_BACKTRACE_SELF_TEST) += backtracetest.o
obj-$(CONFIG_COMPAT) += compat.o
obj-$(CONFIG_CGROUPS) += cgroup.o
obj-$(CONFIG_CGROUP_FREEZER) += cgroup_freezer.o
+obj-$(CONFIG_CGROUP_PIDS) += cgroup_pids.o
obj-$(CONFIG_CPUSETS) += cpuset.o
obj-$(CONFIG_UTS_NS) += utsname.o
obj-$(CONFIG_USER_NS) += user_namespace.o
diff --git a/kernel/cgroup_pids.c b/kernel/cgroup_pids.c
new file mode 100644
index 000..a97fd0e
--- /dev/null
+++ b/kernel/cgroup_pids.c
@@ -0,0 +1,282 @@
+/*
+ * Process number limiting subsys for cgroups.
+ *
+ * Copyright (C) 2015 Aleksa Sarai cyp...@cyphar.com
+ *
+ */
+
+#include linux/kernel.h
+#include linux/atomic.h
+#include linux/cgroup.h
+#include linux/slab.h
+
+#define PIDS_UNLIMITED -1
+
+struct pids {
+ struct pids *parent;
+ struct cgroup_subsys_state css;
+
+ atomic_long_t counter;
+ long limit;
+};
+
+static inline struct pids *css_pids(struct cgroup_subsys_state *css)
+{
+ return css ? container_of(css, struct pids, css) : NULL;
+}
+
+static inline struct pids *task_pids(struct task_struct *task)
+{
+ return css_pids(task_css(task, pids_cgrp_id));
+}
+
+static struct pids *parent_pids(struct pids *pids)
+{
+ return css_pids(pids-css.parent);
+}
+
+static struct cgroup_subsys_state *
+pids_css_alloc(struct cgroup_subsys_state *parent)
+{
+ struct pids *pids;
+
+ pids = kzalloc(sizeof(struct pids), GFP_KERNEL);
+ if (!pids)
+ return ERR_PTR(-ENOMEM);
+
+ return pids-css;
+}
+
+static int pids_css_online(struct cgroup_subsys_state *css)
+{
+ struct pids *pids = css_pids(css);
+ long limit = -1;
+
+ pids-parent = parent_pids(pids);
+ if (pids-parent)
+ limit = pids-parent-limit;
+
+ pids-limit = limit;
+ atomic_long_set(pids-counter, 0);
+ return 0;
+}
+
+static void pids_css_free(struct cgroup_subsys_state *css)
+{
+ kfree(css_pids(css));
+}
+
+/**
+ * pids_cancel - uncharge the local pid count
+ * @pids: the pid cgroup state
+ * @num: the number of pids to cancel
+ *
+ * This function will WARN if the pid count goes under 0,
+ * but will not prevent it.
+ */
+static void pids_cancel(struct pids *pids, int num)
+{
+ long new;
+
+ new = atomic_long_sub_return(num, pids-counter);
+
+ /*
+* A negative count is invalid, but pids_cancel() can't fail.
+* So just emit a WARN.
+*/
+ WARN_ON(new 0);
+}
+
+/**
+ * pids_charge - hierarchically uncharge the pid count
+ * @pids: the pid cgroup
Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id
On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala ga...@codeaurora.org wrote: On Mar 5, 2015, at 1:42 PM, Kevin Hilman khil...@kernel.org wrote: Kumar Gala ga...@codeaurora.org writes: The top level qcom,msm-id and qcom,board-id are utilized by bootloaders on Qualcomm MSM platforms to determine which device tree should be utilized and passed to the kernel. Cc: devicet...@vger.kernel.org Signed-off-by: Kumar Gala ga...@codeaurora.org Is this the special magic that allows qcom bootloaders to take a kernel plus multiple DTBs and figure out which DTB to pass? Kevin yes That's a bummer. Luckily, the solution for upstream is still quite simple: Provide only one devicetree, and it'll be used, right? -Olof -- 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 2/2] perf probe: Allow weak symbols to be probed
Hi Masami, On Thu, Mar 05, 2015 at 12:57:21AM +0900, Masami Hiramatsu wrote: (2015/03/04 22:52), Namhyung Kim wrote: It currently prevents adding probes in weak symbols. But there're cases that given name is an only weak symbol so that we cannot add probe. $ perf probe -x /usr/lib/libc.so.6 -a calloc Failed to find symbol calloc in /usr/lib/libc-2.21.so Error: Failed to add events. $ nm /usr/lib/libc.so.6 | grep calloc 0007b1f0 t __calloc 0007b1f0 T __libc_calloc 0007b1f0 W calloc This change will result in duplicate probes when strong and weak symbols co-exist in a binary. But I think it's not a big problem since probes at the weak symbol will never be hit anyway. Hmm, even on my previous series, I got an error with calloc and waitpid. $ ./perf probe -x /usr/lib64/libc-2.17.so -vvV calloc probe-definition(0): calloc symbol:calloc file:(null) line:0 offset:0 return:0 lazy:(null) 0 arguments Open Debuginfo file: /usr/lib/debug/usr/lib64/libc-2.17.so.debug Searching variables at calloc Failed to find the address of calloc Error: Failed to show vars. Reason: No such file or directory (Code: -2) However, it seems that calloc is loaded as a symbol. $ ./perf probe -x /usr/lib64/libc-2.17.so -V calloc ... symbol__new: __xstat64 0xe7340-0xe7385 symbol__new: calloc 0x80a90-0x80d2a symbol__new: msgget 0xf7940-0xf7961 ... FYI, without these patches, I see the same result (calloc is loaded) I'm bit confused with the English ;-). So you mean that now you *can* probe calloc and waitpid with this patch, right? Thanks, Namhyung -- 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 2/2] pinctrl: mediatek: Adjust mt8173 pinctrl kconfig
Linus, This one make PINCTRL_MT8173 option user selectable and is based on mtk-staging in your tree. If you think this is OK, please applied or squash this into previous change. Thanks. -- ARM64 maintainer doesn't want to add MACH_* for each SoC. Adjust mt8173 pinctrl kconfig entry so user can manually select it. Also make PINCTRL_MT8135 build when COMPILE_TEST is enabled. Signed-off-by: Yingjoe Chen yingjoe.c...@mediatek.com --- drivers/pinctrl/mediatek/Kconfig | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/pinctrl/mediatek/Kconfig b/drivers/pinctrl/mediatek/Kconfig index 49b8649..1472f0e 100644 --- a/drivers/pinctrl/mediatek/Kconfig +++ b/drivers/pinctrl/mediatek/Kconfig @@ -1,4 +1,4 @@ -if ARCH_MEDIATEK +if ARCH_MEDIATEK || COMPILE_TEST config PINCTRL_MTK_COMMON bool @@ -8,11 +8,13 @@ config PINCTRL_MTK_COMMON select OF_GPIO config PINCTRL_MT8135 - def_bool MACH_MT8135 + def_bool MACH_MT8135 || COMPILE_TEST select PINCTRL_MTK_COMMON config PINCTRL_MT8173 - def_bool MACH_MT8173 + bool Mediatek MT8173 pin control + def_bool y + depends on ARM64 || COMPILE_TEST select PINCTRL_MTK_COMMON endif -- 1.8.1.1.dirty -- 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 1/2] arm64: mediatek: Select PINCTRL for Mediatek platform
These 2 patches are fixup for MT8173 pinctrl driver: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/320066.html Arm64 maintainers doesn't want to add MACH_* in Kconfig, this patch is used to replace the first one in that series. Matthias, Can you take this one? -- MediaTek SoC expect to work with a pinctrl driver. Select PINCTRL if ARCH_MEDIATEK is selected. Signed-off-by: Yingjoe Chen yingjoe.c...@mediatek.com --- arch/arm64/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index e627ead..a2ddd3f 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -151,6 +151,7 @@ menu Platform selection config ARCH_MEDIATEK bool Mediatek MT65xx MT81xx ARMv8 SoC select ARM_GIC + select PINCTRL help Support for Mediatek MT65xx MT81xx ARMv8 SoCs -- 1.8.1.1.dirty -- 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/
[V5 PATCH 1/2] ACPI / scan: Add support for ACPI _CLS device matching
Device drivers typically use ACPI _HIDs/_CIDs listed in struct device_driver
acpi_match_table to match devices. However, for generic drivers, we do not
want to list _HID for all supported devices. Also, certain classes of devices
do not have _CID (e.g. SATA, USB). Instead, we can leverage ACPI _CLS,
which specifies PCI-defined class code (i.e. base-class, subclass and
programming interface). This patch adds support for matching ACPI devices using
the _CLS method.
To support loadable module, current design uses _HID or _CID to match device's
modalias. With the new way of matching with _CLS this would requires
modification
to the current ACPI modalias key to include _CLS. This patch appends PCI-defined
class-code to the existing ACPI modalias as following.
acpi:HID:CID1:CID2:..:CIDn:bbsspp:
E.g:
# cat /sys/devices/platform/AMDI0600:00/modalias
acpi:AMDI0600:010601:
where bb is th base-class code, ss is te sub-class code, and pp is the
programming interface code
Since there would not be _HID/_CID in the ACPI matching table of the driver,
this patch adds a field to acpi_device_id to specify the matching _CLS.
static const struct acpi_device_id ahci_acpi_match[] = {
{ , 0, PCI_CLASS_STORAGE_SATA_AHCI },
{},
};
In this case, the corresponded entry in modules.alias file would be:
alias acpi*:010601:* ahci_platform
Signed-off-by: Suravee Suthikulpanit suravee.suthikulpa...@amd.com
---
drivers/acpi/acpica/acutils.h | 3 ++
drivers/acpi/acpica/nsxfname.c| 21 ++--
drivers/acpi/acpica/utids.c | 71 +++
drivers/acpi/scan.c | 17 --
include/acpi/acnames.h| 1 +
include/acpi/actypes.h| 4 ++-
include/linux/mod_devicetable.h | 1 +
scripts/mod/devicetable-offsets.c | 1 +
scripts/mod/file2alias.c | 13 +--
9 files changed, 124 insertions(+), 8 deletions(-)
diff --git a/drivers/acpi/acpica/acutils.h b/drivers/acpi/acpica/acutils.h
index c2f03e8..2aef850 100644
--- a/drivers/acpi/acpica/acutils.h
+++ b/drivers/acpi/acpica/acutils.h
@@ -430,6 +430,9 @@ acpi_status
acpi_ut_execute_CID(struct acpi_namespace_node *device_node,
struct acpi_pnp_device_id_list ** return_cid_list);
+acpi_status
+acpi_ut_execute_CLS(struct acpi_namespace_node *device_node,
+ struct acpi_pnp_device_id **return_id);
/*
* utlock - reader/writer locks
*/
diff --git a/drivers/acpi/acpica/nsxfname.c b/drivers/acpi/acpica/nsxfname.c
index d66c326..590ef06 100644
--- a/drivers/acpi/acpica/nsxfname.c
+++ b/drivers/acpi/acpica/nsxfname.c
@@ -276,11 +276,12 @@ acpi_get_object_info(acpi_handle handle,
struct acpi_pnp_device_id *hid = NULL;
struct acpi_pnp_device_id *uid = NULL;
struct acpi_pnp_device_id *sub = NULL;
+ struct acpi_pnp_device_id *cls = NULL;
char *next_id_string;
acpi_object_type type;
acpi_name name;
u8 param_count = 0;
- u8 valid = 0;
+ u16 valid = 0;
u32 info_size;
u32 i;
acpi_status status;
@@ -320,7 +321,7 @@ acpi_get_object_info(acpi_handle handle,
if ((type == ACPI_TYPE_DEVICE) || (type == ACPI_TYPE_PROCESSOR)) {
/*
* Get extra info for ACPI Device/Processor objects only:
-* Run the Device _HID, _UID, _SUB, and _CID methods.
+* Run the Device _HID, _UID, _SUB, _CID and _CLS methods.
*
* Note: none of these methods are required, so they may or may
* not be present for this device. The Info-Valid bitfield is
used
@@ -351,6 +352,14 @@ acpi_get_object_info(acpi_handle handle,
valid |= ACPI_VALID_SUB;
}
+ /* Execute the Device._CLS method */
+
+ status = acpi_ut_execute_CLS(node, cls);
+ if (ACPI_SUCCESS(status)) {
+ info_size += cls-length;
+ valid |= ACPI_VALID_CLS;
+ }
+
/* Execute the Device._CID method */
status = acpi_ut_execute_CID(node, cid_list);
@@ -468,6 +477,11 @@ acpi_get_object_info(acpi_handle handle,
sub, next_id_string);
}
+ if (cls) {
+ next_id_string = acpi_ns_copy_device_id(info-cls,
+ cls, next_id_string);
+ }
+
if (cid_list) {
info-compatible_id_list.count = cid_list-count;
info-compatible_id_list.list_size = cid_list-list_size;
@@ -507,6 +521,9 @@ cleanup:
if (sub) {
ACPI_FREE(sub);
}
+ if (cls) {
+ ACPI_FREE(cls);
+ }
if (cid_list) {
ACPI_FREE(cid_list);
}
diff --git a/drivers/acpi/acpica/utids.c b/drivers/acpi/acpica/utids.c
index
[V5 PATCH 0/2] Introduce ACPI support for ahci_platform driver
This patch series introduce ACPI support for AHCI platform driver. Existing ACPI support for AHCI assumes the device controller is a PCI device. Since there is no ACPI _CID for generic AHCI controller, the driver could not use it for matching devices. Therefore, this patch introduces a mechanism for drivers to match devices using ACPI _CLS method. _CLS contains PCI-defined class-code. This patch series also modifies ACPI modalias to add class-code to the exisiting format, which currently only uses _HID and _CIDs. This is required to support loadable modules w/ _CLS. This patch series is rebased from and tested with: http://git.linaro.org/leg/acpi/acpi.git acpi-5.1-v9 This topic was discussed earlier here (as part of introducing support for AMD Seattle SATA controller): http://marc.info/?l=linux-arm-kernelm=141083492521584w=2 Changes from V4 (https://lkml.org/lkml/2015/3/2/56) * [1/2] Bug fixed: Reorder the declaration of struct acpi_pnp_device_id cls in the struct acpi_device_info (include/acpi/actypes.h) since compatible_id_list must be last one. * [2/2] Added Acked-by: Tejun Heo t...@kernel.org Changes from V3 (https://lkml.org/lkml/2015/2/8/106) * Instead of introducing new structure acpi_device_cls, add cls into the acpi_device_id, and modify the __acpi_match_device to also match for cls. (per Mika suggestion.) * Add loadable module support, which requires changes in ACPI modalias. (per Mika suggestion.) * Rebased and tested with acpi-5.1-v9 Changes from V2 (https://lkml.org/lkml/2015/1/5/662) * Update with review comment from Rafael in patch 1/2 * Rebased and tested with acpi-5.1-v8 Changes from V1 (https://lkml.org/lkml/2014/12/19/345) * Rebased to 3.19.0-rc2 * Change from acpi_cls in device_driver to acpi_match_cls (Hanjun comment) * Change the matching logic in acpi_driver_match_device() due to the new special PRP0001 _HID. * Simplify the return type of acpi_match_device_cls() to boolean. Changes from RFC (https://lkml.org/lkml/2014/12/17/446) * Remove #ifdef and make non-ACPI version of the acpi_match_device_cls as inline. (per Arnd) * Simplify logic to retrieve and evaluate _CLS handle. (per Hanjun) Suravee Suthikulpanit (2): ACPI / scan: Add support for ACPI _CLS device matching ata: ahci_platform: Add ACPI _CLS matching drivers/acpi/acpica/acutils.h | 3 ++ drivers/acpi/acpica/nsxfname.c| 21 ++-- drivers/acpi/acpica/utids.c | 71 +++ drivers/acpi/scan.c | 17 -- drivers/ata/Kconfig | 2 +- drivers/ata/ahci_platform.c | 9 + include/acpi/acnames.h| 1 + include/acpi/actypes.h| 4 ++- include/linux/mod_devicetable.h | 1 + scripts/mod/devicetable-offsets.c | 1 + scripts/mod/file2alias.c | 13 +-- 11 files changed, 134 insertions(+), 9 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/
Re: [PATCH stable 3.10, 3.12, 3.14] MIPS: Export FP functions used by lose_fpu(1) for KVM
On Thu, Mar 05, 2015 at 04:08:44PM +, James Hogan wrote: [ Upstream commit 3ce465e04bfd8de9956d515d6e9587faac3375dc ] Export the _save_fp asm function used by the lose_fpu(1) macro to GPL modules so that KVM can make use of it when it is built as a module. This fixes the following build error when CONFIG_KVM=m due to commit f798217dfd03 (KVM: MIPS: Don't leak FPU/DSP to guest): ERROR: _save_fp [arch/mips/kvm/kvm.ko] undefined! Signed-off-by: James Hogan james.ho...@imgtec.com Fixes: f798217dfd03 (KVM: MIPS: Don't leak FPU/DSP to guest) Cc: Paolo Bonzini pbonz...@redhat.com Cc: Ralf Baechle r...@linux-mips.org Cc: Paul Burton paul.bur...@imgtec.com Cc: Gleb Natapov g...@kernel.org Cc: k...@vger.kernel.org Cc: linux-m...@linux-mips.org Cc: sta...@vger.kernel.org # 3.10...3.15 Patchwork: https://patchwork.linux-mips.org/patch/9260/ Signed-off-by: Ralf Baechle r...@linux-mips.org [james.ho...@imgtec.com: Only export when CPU_R4K_FPU=y prior to v3.16, so as not to break the Octeon build which excludes FPU support. KVM depends on MIPS32r2 anyway.] Signed-off-by: James Hogan james.ho...@imgtec.com --- Appologies for the previous cavium_octeon_defconfig link breakage. Octeon has the symbol since 3.16, but not before. This backport should do the trick for stable 3.10, 3.12, and 3.14. Build tested with cavium_octeon_defconfig and malta_kvm_defconfig on those stable branches. --- arch/mips/kernel/mips_ksyms.c | 8 1 file changed, 8 insertions(+) Now fixed up, 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: [cgroup] WARNING: CPU: 0 PID: 0 at arch/x86/kernel/cpu/common.c:1439 warn_pre_alternatives()
Hi Vladimir,
On Fri, Mar 06, 2015 at 09:09:37AM +0300, Vladimir Davydov wrote:
Hi,
This bug should have been fixed by [PATCH -next] cpuset: initialize
cpuset a bit early:
http://www.spinics.net/lists/cgroups/msg12599.html
OK, sorry for the late report! I only searched for the full commit id
for possible duplicates, should check the patch subject, too.
Thanks,
Fengguang
On Fri, Mar 06, 2015 at 01:57:58PM +0800, Fengguang Wu wrote:
[0.021989] [ cut here ]
[0.021989] [ cut here ]
[0.022816] WARNING: CPU: 0 PID: 0 at arch/x86/kernel/cpu/common.c:1439
warn_pre_alternatives+0x25/0x2e()
[0.022816] WARNING: CPU: 0 PID: 0 at arch/x86/kernel/cpu/common.c:1439
warn_pre_alternatives+0x25/0x2e()
[0.024000] You're using static_cpu_has before alternatives have run!
[0.024000] You're using static_cpu_has before alternatives have run!
[0.024000] Modules linked in:
[0.024000] Modules linked in:
[0.024000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.0.0-rc1-4-g295458e #455
[0.024000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.0.0-rc1-4-g295458e #455
[0.024000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.7.5-20140531_083030-gandalf 04/01/2014
[0.024000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.7.5-20140531_083030-gandalf 04/01/2014
[0.024000] 0009
[0.024000] 0009 81e03cc8 81e03cc8
81674d02 81674d02 810ca88e 810ca88e
[0.024000] 81e03d18
[0.024000] 81e03d18 81e03d08 81e03d08
81073d6f 81073d6f
[0.024000] 81018f79
[0.024000] 81018f79 81e03e38 81e03e38
0002 0002
[0.024000] Call Trace:
[0.024000] Call Trace:
[0.024000] [81674d02] dump_stack+0xa0/0xd5
[0.024000] [81674d02] dump_stack+0xa0/0xd5
[0.024000] [810ca88e] ? console_unlock+0x496/0x4ef
[0.024000] [810ca88e] ? console_unlock+0x496/0x4ef
[0.024000] [81073d6f] warn_slowpath_common+0xc8/0xf7
[0.024000] [81073d6f] warn_slowpath_common+0xc8/0xf7
[0.024000] [81018f79] ? warn_pre_alternatives+0x25/0x2e
[0.024000] [81018f79] ? warn_pre_alternatives+0x25/0x2e
[0.024000] [81073e6a] warn_slowpath_fmt+0x4f/0x58
[0.024000] [81073e6a] warn_slowpath_fmt+0x4f/0x58
[0.024000] [81680f47] ? native_iret+0x7/0x7
[0.024000] [81680f47] ? native_iret+0x7/0x7
[0.024000] [81018f79] warn_pre_alternatives+0x25/0x2e
[0.024000] [81018f79] warn_pre_alternatives+0x25/0x2e
[0.024000] [81039306] __do_page_fault+0x2b4/0x7c2
[0.024000] [81039306] __do_page_fault+0x2b4/0x7c2
[0.024000] [81039852] do_page_fault+0x3e/0x4a
[0.024000] [81039852] do_page_fault+0x3e/0x4a
[0.024000] [81034109] do_async_page_fault+0x3a/0xb9
[0.024000] [81034109] do_async_page_fault+0x3a/0xb9
[0.024000] [81681a28] async_page_fault+0x28/0x30
[0.024000] [81681a28] async_page_fault+0x28/0x30
[0.024000] [8110d870] ? cpumask_copy+0x2c/0x2f
[0.024000] [8110d870] ? cpumask_copy+0x2c/0x2f
[0.024000] [8110e174] ? cpuset_bind+0x5b/0xc4
[0.024000] [8110e174] ? cpuset_bind+0x5b/0xc4
[0.024000] [8234d780] cgroup_init+0x2fa/0x3d3
[0.024000] [8234d780] cgroup_init+0x2fa/0x3d3
[0.024000] [8232f5fe] start_kernel+0x6ed/0x755
[0.024000] [8232f5fe] start_kernel+0x6ed/0x755
[0.024000] [8232e120] ? early_idt_handlers+0x120/0x120
[0.024000] [8232e120] ? early_idt_handlers+0x120/0x120
[0.024000] [8232e585] x86_64_start_reservations+0x46/0x4f
[0.024000] [8232e585] x86_64_start_reservations+0x46/0x4f
[0.024000] [8232e73e] x86_64_start_kernel+0x1b0/0x1c6
[0.024000] [8232e73e] x86_64_start_kernel+0x1b0/0x1c6
[0.024000] ---[ end trace 37d9a871c47a31bc ]---
[0.024000] ---[ end trace 37d9a871c47a31bc ]---
--
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 1/4] i2c: sunxi: Add Reduced Serial Bus (RSB) support
From that regard, RSB is a multiple device bus, using addresses, just like I2C. The way it communicates is basically the one used by P2WI. I am not keen to allow everything which is a bus and has addresses into the I2C realm. The addresses are 12 bit, whilst I2C has at maximum 10 bit which is rarely used, so mostly 7 bit are used. It has a runtime readdressing mechanism which is not present in standard I2C. And if you look at the protocol with no acks but parities, IMO it doesn't look closer to I2C than to other two wire protocols. So, being in I2C needs more arguments. And while the outcome could be that it really makes sense to add RSB to I2C with I2C_FUNCS_RSB added, it could also be that there is a more suitable place for custom busses in the kernel. Also, the fact that P2WI is in I2C is not an argument IMO. It could have been a mistake to pick it up. So really, it just is more I2C-alike than P2WI has ever been. Because it has addresses? I disagree. Good thing that we are not talking about a full review then, but more a philosophical discussion. Exactly. This is why I wanted to bring this in early. signature.asc Description: Digital signature
Re: [RFC/PATCH 2/2] perf probe: Allow weak symbols to be probed
(2015/03/06 15:15), Namhyung Kim wrote: Hi Masami, On Thu, Mar 05, 2015 at 12:57:21AM +0900, Masami Hiramatsu wrote: (2015/03/04 22:52), Namhyung Kim wrote: It currently prevents adding probes in weak symbols. But there're cases that given name is an only weak symbol so that we cannot add probe. $ perf probe -x /usr/lib/libc.so.6 -a calloc Failed to find symbol calloc in /usr/lib/libc-2.21.so Error: Failed to add events. $ nm /usr/lib/libc.so.6 | grep calloc 0007b1f0 t __calloc 0007b1f0 T __libc_calloc 0007b1f0 W calloc This change will result in duplicate probes when strong and weak symbols co-exist in a binary. But I think it's not a big problem since probes at the weak symbol will never be hit anyway. Hmm, even on my previous series, I got an error with calloc and waitpid. $ ./perf probe -x /usr/lib64/libc-2.17.so -vvV calloc probe-definition(0): calloc symbol:calloc file:(null) line:0 offset:0 return:0 lazy:(null) 0 arguments Open Debuginfo file: /usr/lib/debug/usr/lib64/libc-2.17.so.debug Searching variables at calloc Failed to find the address of calloc Error: Failed to show vars. Reason: No such file or directory (Code: -2) However, it seems that calloc is loaded as a symbol. $ ./perf probe -x /usr/lib64/libc-2.17.so -V calloc ... symbol__new: __xstat64 0xe7340-0xe7385 symbol__new: calloc 0x80a90-0x80d2a symbol__new: msgget 0xf7940-0xf7961 ... FYI, without these patches, I see the same result (calloc is loaded) I'm bit confused with the English ;-). So you mean that now you *can* probe calloc and waitpid with this patch, right? Ah, sorry for confusing you. I meant that I couldn't probe it even with your patch. I'm not sure why, since the calloc symbol is created as above message, but can't find in the map... Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- 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 0/17] crypto: talitos - Add support for SEC1
Le 06/03/2015 01:21, Kim Phillips a écrit : On Thu, 5 Mar 2015 17:46:05 +0100 Christophe Leroy christophe.le...@c-s.fr wrote: [15/17] crypto: talitos - Implementation of SEC1 ... [16/17] crypto: talitos - SEC1 bugs on 0 data hash [17/17] crypto: talitos - Update DT bindings with SEC1 This patchseries doesn't apply, at least on top of Herbert's cryptodev-2.6 tree, as of today: Applying: crypto: talitos - Implementation of SEC1 error: patch failed: drivers/crypto/talitos.c:655 error: drivers/crypto/talitos.c: patch does not apply It was applying ok on linux-next as of yesterday. I will rebase the serie on cryptodev-2.6 Christophe -- 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 v9 02/21] ACPI / processor: Introduce phys_cpuid_t for CPU hardware ID
On 2015/3/5 21:23, Rafael J. Wysocki wrote: On Thu, Mar 5, 2015 at 8:44 AM, Hanjun Guo guohan...@huawei.com wrote: On 2015/3/5 6:29, Rafael J. Wysocki wrote: On Wednesday, February 25, 2015 04:39:42 PM Hanjun Guo wrote: [cut] @@ -190,7 +190,7 @@ int acpi_map_cpuid(int phys_id, u32 acpi_id) if (nr_cpu_ids = 1 acpi_id == 0) return acpi_id; else -return phys_id; +return -1; Can we use a proper error code here? I'm afraid not. In ACPI processor drivers, -1 will be deemed to invalid cpu logical number, if we return error code here, we need to modify multi places of if (cpu_logical_num == -1) to Oh, silly stuff. if (! (cpu_logical_num 0)) too, so for me, I prefer to keep it as -1, but I'm open for suggestions. OK I think we need something like invalid_logical_cpuid() and use it in all of those checks instead of the direct comparisons, but we can make those changes later. OK, I recorded this as one of my TODO list, thanks for the suggestions. Thanks Hanjun -- 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: [v3 24/26] KVM: Update Posted-Interrupts Descriptor when vCPU is blocked
-Original Message-
From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
Sent: Wednesday, March 04, 2015 8:06 PM
To: Wu, Feng
Cc: t...@linutronix.de; mi...@redhat.com; h...@zytor.com; x...@kernel.org;
g...@kernel.org; pbonz...@redhat.com; dw...@infradead.org;
j...@8bytes.org; alex.william...@redhat.com; jiang@linux.intel.com;
eric.au...@linaro.org; linux-kernel@vger.kernel.org;
io...@lists.linux-foundation.org; k...@vger.kernel.org
Subject: Re: [v3 24/26] KVM: Update Posted-Interrupts Descriptor when vCPU
is blocked
On Mon, Mar 02, 2015 at 01:36:51PM +, Wu, Feng wrote:
-Original Message-
From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
Sent: Friday, February 27, 2015 7:41 AM
To: Wu, Feng
Cc: t...@linutronix.de; mi...@redhat.com; h...@zytor.com;
x...@kernel.org;
g...@kernel.org; pbonz...@redhat.com; dw...@infradead.org;
j...@8bytes.org; alex.william...@redhat.com; jiang@linux.intel.com;
eric.au...@linaro.org; linux-kernel@vger.kernel.org;
io...@lists.linux-foundation.org; k...@vger.kernel.org
Subject: Re: [v3 24/26] KVM: Update Posted-Interrupts Descriptor when
vCPU
is blocked
On Fri, Dec 12, 2014 at 11:14:58PM +0800, Feng Wu wrote:
This patch updates the Posted-Interrupts Descriptor when vCPU
is blocked.
pre-block:
- Add the vCPU to the blocked per-CPU list
- Clear 'SN'
- Set 'NV' to POSTED_INTR_WAKEUP_VECTOR
post-block:
- Remove the vCPU from the per-CPU list
Signed-off-by: Feng Wu feng...@intel.com
---
arch/x86/include/asm/kvm_host.h | 2 +
arch/x86/kvm/vmx.c | 96
+
arch/x86/kvm/x86.c | 22 +++---
include/linux/kvm_host.h| 4 ++
virt/kvm/kvm_main.c | 6 +++
5 files changed, 123 insertions(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h
b/arch/x86/include/asm/kvm_host.h
index 13e3e40..32c110a 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -101,6 +101,8 @@ static inline gfn_t gfn_to_index(gfn_t gfn, gfn_t
base_gfn, int level)
#define ASYNC_PF_PER_VCPU 64
+extern void (*wakeup_handler_callback)(void);
+
enum kvm_reg {
VCPU_REGS_RAX = 0,
VCPU_REGS_RCX = 1,
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index bf2e6cd..a1c83a2 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -832,6 +832,13 @@ static DEFINE_PER_CPU(struct vmcs *,
current_vmcs);
static DEFINE_PER_CPU(struct list_head, loaded_vmcss_on_cpu);
static DEFINE_PER_CPU(struct desc_ptr, host_gdt);
+/*
+ * We maintian a per-CPU linked-list of vCPU, so in wakeup_handler() we
+ * can find which vCPU should be waken up.
+ */
+static DEFINE_PER_CPU(struct list_head, blocked_vcpu_on_cpu);
+static DEFINE_PER_CPU(spinlock_t, blocked_vcpu_on_cpu_lock);
+
static unsigned long *vmx_io_bitmap_a;
static unsigned long *vmx_io_bitmap_b;
static unsigned long *vmx_msr_bitmap_legacy;
@@ -1921,6 +1928,7 @@ static void vmx_vcpu_load(struct kvm_vcpu
*vcpu,
int cpu)
struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
struct pi_desc old, new;
unsigned int dest;
+ unsigned long flags;
memset(old, 0, sizeof(old));
memset(new, 0, sizeof(new));
@@ -1942,6 +1950,20 @@ static void vmx_vcpu_load(struct kvm_vcpu
*vcpu, int cpu)
new.nv = POSTED_INTR_VECTOR;
} while (cmpxchg(pi_desc-control, old.control,
new.control) != old.control);
+
+ /*
+* Delete the vCPU from the related wakeup queue
+* if we are resuming from blocked state
+*/
+ if (vcpu-blocked) {
+ vcpu-blocked = false;
+
spin_lock_irqsave(per_cpu(blocked_vcpu_on_cpu_lock,
+ vcpu-wakeup_cpu), flags);
+ list_del(vcpu-blocked_vcpu_list);
+
spin_unlock_irqrestore(per_cpu(blocked_vcpu_on_cpu_lock,
+ vcpu-wakeup_cpu), flags);
+ vcpu-wakeup_cpu = -1;
+ }
}
}
@@ -1950,6 +1972,9 @@ static void vmx_vcpu_put(struct kvm_vcpu
*vcpu)
if (irq_remapping_cap(IRQ_POSTING_CAP)) {
struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
struct pi_desc old, new;
+ unsigned long flags;
+ int cpu;
+ struct cpumask cpu_others_mask;
memset(old, 0, sizeof(old));
memset(new, 0,
[PATCH][v3.18.y][v3.19.y] tg3: Hold tp-lock before calling tg3_halt() from tg3_init_one()
Hello, Please consider including mainline commit d0af71a3573f1217b140c60b66f1a9b335fb058b in the next v3.18.y and v3.19.y stable releases. It was included in the mainline tree as of v4.0-rc1. It has been tested and confirmed to resolve: http://bugs.launchpad.net/bugs/1428111 . This commit fixes a regression introduced going from 3.16 to 3.19, so it may not be needed in earlier than 3.18 stable releases. commit d0af71a3573f1217b140c60b66f1a9b335fb058b Author: Jun'ichi Nomura \(NEC\) j-nom...@ce.jp.nec.com Date: Thu Feb 12 01:26:24 2015 + tg3: Hold tp-lock before calling tg3_halt() from tg3_init_one() Sincerely, Joseph Salisbury -- 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] virtio_mmio: fix endian-ness for mmio
Going over the virtio mmio code, I noticed that it doesn't correctly
return device config values in LE format when using virtio 1.0.
Borrow code from virtio_pci_modern to do this correctly.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
Note: untested: QEMU doesn't support virtio 1.0 for virtio-mmio.
Pawel, could you please confirm this patch makes sense?
drivers/virtio/virtio_mmio.c | 79 +++-
1 file changed, 71 insertions(+), 8 deletions(-)
diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
index cad5698..0375456 100644
--- a/drivers/virtio/virtio_mmio.c
+++ b/drivers/virtio/virtio_mmio.c
@@ -156,22 +156,85 @@ static void vm_get(struct virtio_device *vdev, unsigned
offset,
void *buf, unsigned len)
{
struct virtio_mmio_device *vm_dev = to_virtio_mmio_device(vdev);
- u8 *ptr = buf;
- int i;
+ void __iomem *base = vm_dev-base + VIRTIO_MMIO_CONFIG;
+ u8 b;
+ __le16 w;
+ __le32 l;
- for (i = 0; i len; i++)
- ptr[i] = readb(vm_dev-base + VIRTIO_MMIO_CONFIG + offset + i);
+ if (vm_dev-version == 1) {
+ u8 *ptr = buf;
+ int i;
+
+ for (i = 0; i len; i++)
+ ptr[i] = readb(base + offset + i);
+ return;
+ }
+
+ switch (len) {
+ case 1:
+ b = readb(base + offset);
+ memcpy(buf, b, sizeof b);
+ break;
+ case 2:
+ w = cpu_to_le16(readw(base + offset));
+ memcpy(buf, w, sizeof w);
+ break;
+ case 4:
+ l = cpu_to_le32(readl(base + offset));
+ memcpy(buf, l, sizeof l);
+ break;
+ case 8:
+ l = cpu_to_le32(readl(base + offset));
+ memcpy(buf, l, sizeof l);
+ l = cpu_to_le32(ioread32(base + offset + sizeof l));
+ memcpy(buf + sizeof l, l, sizeof l);
+ break;
+ default:
+ BUG();
+ }
}
static void vm_set(struct virtio_device *vdev, unsigned offset,
const void *buf, unsigned len)
{
struct virtio_mmio_device *vm_dev = to_virtio_mmio_device(vdev);
- const u8 *ptr = buf;
- int i;
+ void __iomem *base = vm_dev-base + VIRTIO_MMIO_CONFIG;
+ u8 b;
+ __le16 w;
+ __le32 l;
- for (i = 0; i len; i++)
- writeb(ptr[i], vm_dev-base + VIRTIO_MMIO_CONFIG + offset + i);
+ if (vm_dev-version == 1) {
+ const u8 *ptr = buf;
+ int i;
+
+ for (i = 0; i len; i++)
+ writeb(ptr[i], base + offset + i);
+
+ return;
+ }
+
+ switch (len) {
+ case 1:
+ memcpy(b, buf, sizeof b);
+ writeb(b, base + offset);
+ break;
+ case 2:
+ memcpy(w, buf, sizeof w);
+ writew(le16_to_cpu(w), base + offset);
+ break;
+ case 4:
+ memcpy(l, buf, sizeof l);
+ writel(le32_to_cpu(l), base + offset);
+ break;
+ case 8:
+ memcpy(l, buf, sizeof l);
+ writel(le32_to_cpu(l), base + offset);
+ memcpy(l, buf + sizeof l, sizeof l);
+ writel(le32_to_cpu(l), base + offset + sizeof l);
+ break;
+ default:
+ BUG();
+ }
}
static u8 vm_get_status(struct virtio_device *vdev)
--
MST
--
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: [PATCHv2 07/10] fbdev: ssd1307fb: Add module parameter to set refresh rate of the display
On Sun, Mar 01, 2015 at 11:28:00PM +0100, Thomas Niederprüm wrote:
This patch adds the module parameter refreshrate to set delay for the
deferred io. The refresh rate is given in units of Hertz. The default
refresh rate is 1 Hz.
Signed-off-by: Thomas Niederprüm nied...@physik.uni-kl.de
---
drivers/video/fbdev/ssd1307fb.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index c7ed287..ea58e87 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -43,6 +43,11 @@
#define SSD1307FB_SET_COM_PINS_CONFIG 0xda
#define SSD1307FB_SET_VCOMH 0xdb
+#define REFRASHRATE 1
+
+static u_int refreshrate = REFRASHRATE;
+module_param(refreshrate, uint, 0);
+
static u_int contrast = 128;
module_param(contrast, uint, S_IRUGO);
@@ -270,11 +275,6 @@ static void ssd1307fb_deferred_io(struct fb_info *info,
ssd1307fb_update_display(info-par);
}
-static struct fb_deferred_io ssd1307fb_defio = {
- .delay = HZ,
- .deferred_io= ssd1307fb_deferred_io,
-};
-
static int ssd1307fb_init(struct ssd1307fb_par *par)
{
int ret;
@@ -475,6 +475,7 @@ static int ssd1307fb_probe(struct i2c_client *client,
{
struct fb_info *info;
struct device_node *node = client-dev.of_node;
+ struct fb_deferred_io *ssd1307fb_defio;
u32 vmem_size;
struct ssd1307fb_par *par;
u8 *vmem;
@@ -544,10 +545,20 @@ static int ssd1307fb_probe(struct i2c_client *client,
goto fb_alloc_error;
}
+ ssd1307fb_defio = devm_kzalloc(client-dev, sizeof(struct
fb_deferred_io), GFP_KERNEL);
+ if (!ssd1307fb_defio) {
+ dev_err(client-dev, Couldn't allocate deferred io.\n);
+ ret = -ENOMEM;
+ goto fb_alloc_error;
+ }
+
+ ssd1307fb_defio-delay = HZ/refreshrate;
a space around the operator.
I'm not so sure this is a good solution, since you might perfectly
want to have an SSD1305 with a refreshrate of 1Hz, and an SSD1306 with
a refreshrate of 20Hz.
Unfortunately, beside sysfs, I don't really have a better suggestion.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [RFC] lib/vsprintf.c: Even faster decimal conversion
On Thu, Mar 05 2015, Tejun Heo t...@kernel.org wrote: On Thu, Mar 05, 2015 at 08:03:33AM -0800, Joe Perches wrote: On Thu, 2015-03-05 at 16:22 +0100, Rasmus Villemoes wrote: I'm assuming the underwhelming response means NAK. Dunno why you assume that, sometimes it just takes awhile for people to look at non-critical, infrequent optimization changes like this. Well, when nobody has responded within a week with even a not obviously insane, I'll look at it after -rcN/next full moon/..., there's usually little hope of ever getting some feedback. Seems sensible enough to me though. I'd like to see how this actually affects larger operations - sth along the line of top consumes D% less CPU cycles w/ N processes - if for nothing else, just to get the sense of scale, That makes sense. I'll see if I can get some reproducible numbers, but I'm afraid the effect drowns in all the syscall overhead. Which would be a valid argument against touching the code. I haven't studied the code but looks sensible enough on a glance, so, FWIW, Looks-sensible-by: Tejun Heo t...@kernel.org Thanks, this was the kind of feedback I was hoping for. Rasmus -- 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] x86/vdso: fix a reference to a non-existing instruction
On Thu, Mar 5, 2015 at 12:13 AM, Jiri Slaby jsl...@suse.cz wrote: .LSTARTFDEDLSI1 says: /* HACK: The dwarf2 unwind routines will subtract 1 from the return address to get an address in the middle of the presumed call instruction. Since we didn't get here via a call, we need to include the nop before the real start to make up for it. */ .long .LSTART_sigreturn-1-. /* PC-relative start address */ But commit 69d0627a7f6e891189124d784d2fa90cae7c449a (x86 vDSO: reorder vdso32 code) from 2.6.25 replaced .org __kernel_vsyscall+32,0x90 by ALIGN right before __kernel_sigreturn. Of course, ALIGN need not generate any nop in there. Esp. gcc5 collapses vclock_gettime.o and int80.o together with no generated nops as ALIGN. In that case kernel does not even link: ld: .eh_frame_hdr table[4] FDE at 0648 overlaps table[5] FDE at 0670. So fix this by adding there at least a single nop and make the function ALIGN possibly with more nops then. Kudos for reporting and diagnosing should go to Richard. Signed-off-by: Jiri Slaby jsl...@suse.cz Reported-by: Richard Biener rguent...@suse.de Cc: sta...@vger.kernel.org Cc: Andy Lutomirski l...@amacapital.net Cc: Thomas Gleixner t...@linutronix.de Cc: Ingo Molnar mi...@redhat.com Cc: H. Peter Anvin h...@zytor.com Cc: x...@kernel.org --- arch/x86/vdso/vdso32/sigreturn.S | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/vdso/vdso32/sigreturn.S b/arch/x86/vdso/vdso32/sigreturn.S index 31776d0efc8c..d7ec4e251c0a 100644 --- a/arch/x86/vdso/vdso32/sigreturn.S +++ b/arch/x86/vdso/vdso32/sigreturn.S @@ -17,6 +17,7 @@ .text .globl __kernel_sigreturn .type __kernel_sigreturn,@function + nop /* this guy is needed for .LSTARTFDEDLSI1 below (watch for HACK) */ ALIGN __kernel_sigreturn: .LSTART_sigreturn: Acked-by: Andy Lutomirski l...@amacapital.net Ingo or Thomas, can you apply this to tip:x86/urgent for this weekend? Are we willing to depend on cfi-capable assemblers for 32-bit? If so, could we rewrite this garbage with .cfi directives? The current code is incomprehensible. --Andy -- 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 1/7] ARM: at91: switch to multiplatform
On 05/03/2015 at 16:50:57 -0600, Rob Herring wrote : -config SOC_SAMA5 +config ARCH_AT91 bool - select ATMEL_AIC5_IRQ + select ARCH_REQUIRE_GPIOLIB select COMMON_CLK_AT91 - select CPU_V7 + select CLKDEV_LOOKUP This is already selected by COMMON_CLK I think. select GENERIC_CLOCKEVENTS This is already selected. I'm just moving options around I didn't add or remove any. That applies to most of your comments. - select MEMORY - select ATMEL_SDRAMC - select PHYLIB if NETDEVICES - -menu Atmel AT91 System-on-Chip - -choice - - prompt Core type - -config SOC_SAM_V4_V5 - bool ARM9 AT91SAM9/AT91RM9200 - help - Select this if you are using one of Atmel's AT91SAM9 or - AT91RM9200 SoC. - -config SOC_SAM_V7 - bool Cortex A5 + select IRQ_DOMAIN + select NEED_MACH_IO_H if PCCARD This won't work on multi-platform. There is a patch removing it that is part of another series. IT will be applied before this patch. + select MEMORY + select ATMEL_SDRAMC + select PHYLIB if NETDEVICES This belongs with your network driver. Probably not, it is there because of the phy fixups. Anyway, it is being removed by another series as we don't like to carry phy fixups. config AT91_TIMER_HZ - int Kernel HZ (jiffies per second) - range 32 1024 - depends on ARCH_AT91 - default 128 if SOC_AT91RM9200 - default 100 - help + int Kernel HZ (jiffies per second) How is this multi-platform compatible. This belongs with the clockevent driver probably. It is not different from what is done for ARCH_EXYNOS4 which is also mutliplatform (and the more annoyingly ARMv7). I propose to restrict that to SOC_AT91RM9200 so that it only affects ARMv4 (and I guess not many people care about those now). I'm not sure it is a good idea to move it to clokevents because of how it is handled in arch/arm/Kconfig. I'll add a patch on top of that to further cleanup the unnecessary options you pointed and moving COMMON_CLK_AT91 to driver/clk. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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/3] crypto: caam_rng: fix rng_unmap_ctx's DMA_UNMAP size problem
On Thu, 5 Mar 2015 10:52:37 +0800 yjin yanjiang@windriver.com wrote: On 2015年03月05日 02:36, Kim Phillips wrote: On Wed, 4 Mar 2015 13:33:22 +0800 yjin yanjiang@windriver.com wrote: On 2015年03月04日 03:31, Kim Phillips wrote: On Tue, 3 Mar 2015 14:50:52 +0800 yanjiang@windriver.com wrote: -dma_unmap_single(jrdev, ctx-sh_desc_dma, DESC_RNG_LEN, - DMA_TO_DEVICE); +dma_unmap_single(jrdev, ctx-sh_desc_dma, +desc_bytes(ctx-sh_desc), DMA_TO_DEVICE); alignment: the 'd' in desc_bytes should fall directly under the 'j' in jrdev. Also, DESC_RNG_LEN should be corrected to (4 * CAAM_CMD_SZ). I can't find the obvious limitation for the RNG descriptor length in Freescale documents, could you point out it? ? rng_create_sh_desc() creates a fixed descriptor of exactly 4 command-lengths. Do you mean that the code itself limits the descriptor length? Not a hardware limitation. the code writes descriptors such that they don't reach h/w limitations. If so, I prefer to dma_unmap with desc_bytes(ctx-sh_desc) as my previous patch, and correct DESC_RNG_LEN to (4 * CAAM_CMD_SZ). please. Kim -- 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/3] crypto: caam: fix some compile warnings
On Thu, 5 Mar 2015 09:12:13 +0200 Cristian Stoica cristian.sto...@freescale.com wrote: On 03/04/2015 08:34 PM, Kim Phillips wrote: I don't see how, e.g., for one, dma_map_sg is I/O TLB implementation-dependent. I'll need some remedial classes on this topic, but for the moment I don't see how this matters for mapping sg chains. Can you share some pointers? I think it's better the driver not depend on whether the dma_map_sg implementation supports chains, but you're welcome to try... Kim -- 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/
GOOD NEWS
Gloria C. Mackenzie Donate $ 2,000,000 00. to you, Email me on:
{mackenziegloria...@gmail.com} for more details
--
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] mm: numa: Do not clear PTEs or PMDs for NUMA hinting faults
On Thu, Mar 5, 2015 at 3:54 PM, Mel Gorman mgor...@suse.de wrote:
if (!prot_numa || !pmd_protnone(*pmd)) {
- entry = pmdp_get_and_clear_notify(mm, addr, pmd);
- entry = pmd_modify(entry, newprot);
+ /*
+* NUMA hinting update can avoid a clear and defer the
+* flush as it is not a functional correctness issue
if
+* access occurs after the update and this avoids
+* spurious faults.
+*/
+ if (prot_numa) {
+ entry = *pmd;
+ entry = pmd_mkprotnone(entry);
+ } else {
+ entry = pmdp_get_and_clear_notify(mm, addr,
+ pmd);
+ entry = pmd_modify(entry, newprot);
+ BUG_ON(pmd_write(entry));
+ }
+
ret = HPAGE_PMD_NR;
set_pmd_at(mm, addr, pmd, entry);
- BUG_ON(pmd_write(entry));
So I don't think this is right, nor is the new pte code.
You cannot just read the old pte entry, change it, and write it back.
That's fundamentally racy, and can drop any concurrent dirty or
accessed bit setting. And there are no locks you can use to protect
against that, since the accessed and dirty bit are set by hardware.
Now, losing the accessed bit doesn't matter - it's a small race, and
not a correctness issue. But potentially losing dirty bits is a data
loss problem.
Did the old prot_numa code do this too? Because if it did, it sounds
like it was just buggy.
Linus
--
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 0/8 v4] ARM OMAP2+ GPMC: fixes and bus children
* Robert ABEL ra...@cit-ec.uni-bielefeld.de [150227 08:00]: These are the changes I proposed in these patch series: [1], [2], [3], [4] rebased to 3.19 as well as new changes for little bugs I noticed while preparing this patch series as well as changes introduced via comments. 1. DEBUG was undefined in source code -- remove offending lines 2. add capability to have busses as children of the GPMC and multiple devices on a bus. See [2] for an example DTS syntax. 3. debug output was unaligned -- align it 4. output for copy-pasting to DTS had erroneous timing outputs and made it hard to copy-paste -- correct timing values, add comments as DTS comments. 5. WAITMONITORINGTIME is expressed as GPMC_CLK cycles for all accesses. GPMCFCLKDIVIDER is used as a divider, so it must always be programmed. 6. GPMCFCLKDIVIDER is calculated according to WAITMONITORINGTIME for asynchronous accesses inside the driver -- asynchronous accesses now completely decoupled from gpmc,sync-clk-ps. 7. WAITMONITORINGTIME was being programmed/shown in GPMC_FCLK cycles instead of GPMC_CLK cycles -- add clock domain information where necessary. 8. Calculated values for WAITMONITORINGTIME and CLKACTIVATIONTIME that were outside the defined range would not raise an error. DEVICESIZE, ATTACHEDDEVICEPAGELENGTH, WAITMONITORINGTIME and CLKACTIVATIONTIME would not be marked as incorrect on DTS output. -- Fix all of these. Thanks for fixing all these issues: Acked-by: Tony Lindgren t...@atomide.com [1]: https://lkml.org/lkml/2015/2/12/495 [2]: https://lkml.org/lkml/2015/2/16/337 [3]: https://lkml.org/lkml/2015/2/24/609 [4]: https://lkml.org/lkml/2015/2/26/387 Robert ABEL (9): ARM OMAP2+ GPMC: don't undef DEBUG ARM OMAP2+ GPMC: add bus children ARM OMAP2+ GPMC: fix debug output alignment ARM OMAP2+ GPMC: change get_gpmc_timing_reg output for DTS ARM OMAP2+ GPMC: always program GPMCFCLKDIVIDER ARM OMAP2+ GPMC: calculate GPMCFCLKDIVIDER based on WAITMONITORINGTIME ARM OMAP2+ GPMC: fix WAITMONITORINGTIME divider bug ARM OMAP2+ GPMC: fix programming/showing reserved timing parameters arch/arm/mach-omap2/gpmc-nand.c| 17 +- arch/arm/mach-omap2/gpmc-onenand.c | 4 +- arch/arm/mach-omap2/usb-tusb6010.c | 4 +- drivers/memory/Makefile| 2 + drivers/memory/omap-gpmc.c | 313 + include/linux/omap-gpmc.h | 2 +- 6 files changed, 265 insertions(+), 77 deletions(-) -- 2.3.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 v3 1/1] staging: fsl-mc: fsl-mc object allocator driver
The fsl-mc object allocator driver manages allocatable fsl-mc objects such as DPBPs, DPMCPs and DPCONs. It provides services to other fsl-mc drivers to allocate/deallocate these types of objects. Signed-off-by: J. German Rivera german.riv...@freescale.com Signed-off-by: Stuart Yoder stuart.yo...@freescale.com --- Changes in v3: - Moved files to drivers/staging: drivers/bus/fsl-mc/dpbp.c - drivers/staging/fsl-mc/bus/dpbp.c drivers/bus/fsl-mc/dpmcp-cmd.h - drivers/staging/fsl-mc/bus/dpmcp-cmd.h drivers/bus/fsl-mc/dpmcp.c - drivers/staging/fsl-mc/bus/dpmcp.c drivers/bus/fsl-mc/dpmcp.h - drivers/staging/fsl-mc/bus/dpmcp.h drivers/bus/fsl-mc/mc-allocator.c - drivers/staging/fsl-mc/bus/mc-allocator.c include/linux/fsl/dpbp-cmd.h - drivers/staging/fsl-mc/include/dpbp-cmd.h include/linux/fsl/dpbp.h - drivers/staging/fsl-mc/include/dpbp.h include/linux/fsl/dpcon-cmd.h - drivers/staging/fsl-mc/include/dpcon-cmd.h - Fixed dev_info message in fsl_mc_allocator_remove() Changes in v2: - Converted MC portal allocator to use DPMCP objects drivers/staging/fsl-mc/bus/Makefile | 6 +- drivers/staging/fsl-mc/bus/dpbp.c | 358 + drivers/staging/fsl-mc/bus/dpmcp-cmd.h | 136 +++ drivers/staging/fsl-mc/bus/dpmcp.c | 308 +++ drivers/staging/fsl-mc/bus/dpmcp.h | 311 +++ drivers/staging/fsl-mc/bus/dprc-driver.c| 104 - drivers/staging/fsl-mc/bus/mc-allocator.c | 569 drivers/staging/fsl-mc/bus/mc-bus.c | 2 +- drivers/staging/fsl-mc/bus/mc-sys.c | 4 + drivers/staging/fsl-mc/include/dpbp-cmd.h | 60 +++ drivers/staging/fsl-mc/include/dpbp.h | 330 drivers/staging/fsl-mc/include/dpcon-cmd.h | 62 +++ drivers/staging/fsl-mc/include/mc-private.h | 61 ++- drivers/staging/fsl-mc/include/mc-sys.h | 6 + drivers/staging/fsl-mc/include/mc.h | 65 15 files changed, 2366 insertions(+), 16 deletions(-) create mode 100644 drivers/staging/fsl-mc/bus/dpbp.c create mode 100644 drivers/staging/fsl-mc/bus/dpmcp-cmd.h create mode 100644 drivers/staging/fsl-mc/bus/dpmcp.c create mode 100644 drivers/staging/fsl-mc/bus/dpmcp.h create mode 100644 drivers/staging/fsl-mc/bus/mc-allocator.c create mode 100644 drivers/staging/fsl-mc/include/dpbp-cmd.h create mode 100644 drivers/staging/fsl-mc/include/dpbp.h create mode 100644 drivers/staging/fsl-mc/include/dpcon-cmd.h diff --git a/drivers/staging/fsl-mc/bus/Makefile b/drivers/staging/fsl-mc/bus/Makefile index 424e58e..bd09fc8 100644 --- a/drivers/staging/fsl-mc/bus/Makefile +++ b/drivers/staging/fsl-mc/bus/Makefile @@ -5,7 +5,8 @@ # # This file is released under the GPLv2 # -obj-$(CONFIG_FSL_MC_BUS) += mc-bus-driver.o +obj-$(CONFIG_FSL_MC_BUS) += mc-bus-driver.o \ + mc-allocator-driver.o mc-bus-driver-objs := mc-bus.o \ mc-sys.o \ @@ -13,3 +14,6 @@ mc-bus-driver-objs := mc-bus.o \ dpmng.o \ dprc-driver.o +mc-allocator-driver-objs := mc-allocator.o \ + dpmcp.o \ + dpbp.o diff --git a/drivers/staging/fsl-mc/bus/dpbp.c b/drivers/staging/fsl-mc/bus/dpbp.c new file mode 100644 index 000..d99ab6d --- /dev/null +++ b/drivers/staging/fsl-mc/bus/dpbp.c @@ -0,0 +1,358 @@ +/* Copyright 2013-2014 Freescale Semiconductor Inc. +* +* Redistribution and use in source and binary forms, with or without +* modification, are permitted provided that the following conditions are met: +* * Redistributions of source code must retain the above copyright +* notice, this list of conditions and the following disclaimer. +* * Redistributions in binary form must reproduce the above copyright +* notice, this list of conditions and the following disclaimer in the +* documentation and/or other materials provided with the distribution. +* * Neither the name of the above-listed copyright holders nor the +* names of any contributors may be used to endorse or promote products +* derived from this software without specific prior written permission. +* +* +* ALTERNATIVELY, this software may be distributed under the terms of the +* GNU General Public License (GPL) as published by the Free Software +* Foundation, either version 2 of that License or (at your option) any +* later version. +* +* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS IS +* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +* ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE +* LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR +* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF +* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS +*
[PATCH] drivers: media: platform: vivid: Fix possible null derefrence
Check for dev_fmt being null before derefrencing it, to assign it
to planes.
Found using Coccinelle.
Signed-off-by: Tapasweni Pathak tapaswenipat...@gmail.com
Acked-by: Julia Lawall julia.law...@lip6.fr
---
drivers/media/platform/vivid/vivid-vid-out.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/vivid/vivid-vid-out.c
b/drivers/media/platform/vivid/vivid-vid-out.c
index 39ff79f..8f081bb 100644
--- a/drivers/media/platform/vivid/vivid-vid-out.c
+++ b/drivers/media/platform/vivid/vivid-vid-out.c
@@ -114,7 +114,7 @@ static int vid_out_buf_prepare(struct vb2_buffer *vb)
{
struct vivid_dev *dev = vb2_get_drv_priv(vb-vb2_queue);
unsigned long size;
- unsigned planes = dev-fmt_out-planes;
+ unsigned planes;
unsigned p;
dprintk(dev, 1, %s\n, __func__);
@@ -122,6 +122,8 @@ static int vid_out_buf_prepare(struct vb2_buffer *vb)
if (WARN_ON(NULL == dev-fmt_out))
return -EINVAL;
+ planes = dev-fmt_out-planes;
+
if (dev-buf_prepare_error) {
/*
* Error injection: test what happens if buf_prepare() returns
--
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/
Re: linux-next: build failure after merge of the net-next tree
Hi Dave, On Thu, 05 Mar 2015 21:01:47 -0500 (EST) David Miller da...@davemloft.net wrote: The perils of working on multiple workstations :-) Pushed out now, sorry about that. No worries. I know what its like as we get older ;-) -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpaINVgkWSBP.pgp Description: OpenPGP digital signature
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi,
On 03/06/2015 03:54 AM, Mark Rutland wrote:
Hi,
+ psci {
+ compatible = arm,psci;
+ method = smc;
+ cpu_off = 0x8402;
+ cpu_on = 0xC403;
+ };
Back at v2 you mentioned that CPU_OFF wasn't working [1].
Do both CPU_ON and CPU_OFF work for all CPUs, including the boot CPU?
The CPU1 ~ CPU7 are well woking about CPU_ON/OFF.
CPU0 (boot CPU) is only well working for CPU_OFF.
But when I try to turn on the CPU0 after CPU_OFF, I failed it.
That's rather worrying. Can you look into what's going on here? I'd
rather not have dts describing things which are known to be broken.
The board dts don't include any node for CPU_ON/OFF.
I don't understand. The CPU_ON and CPU_OFF IDs are in the psci node
quoted above, and all the CPUs had enable-method = psci.
I mean that there are not additional dt node except for 'cpu' and 'psci' node.
When I try to turn on the CPU0 (boot CPU), fail to turn on and lockup happen.
After lockup happen, I cannot use the console.
That sounds like a pretty major bug.
Are you able to investigate with a hardware debugger?
I can't do because there are not any jtag connector.
Do other CPUs eventually log errors regarding the lockup? Or is the
machine completely dead from this point on?
I tested CPU0 on/off. When I turn on the CPU0, I fail it. But, kernel just show
the error log without lockup.
I gave you wrong infromation about CPU0 off.
[test result of CPU0 on/off on Linux 4.0-rc2]
root@localhost:~# echo 0 /sys/devices/system/cpu/cpu0/online
[ 420.965435] IRQ1 no longer affine to CPU0
[ 420.965439] IRQ2 no longer affine to CPU0
[ 4631.194227] CPU0: shutdown
root@localhost:~# echo 1 /sys/devices/system/cpu/cpu0/online
[ 1164.601644] CPU0: failed to come online
-bash: echo: write error: Input/output error
As I experienced, Exynos SoC could not turn off the CPU0 (boot cpu).
I think that we may need the hidden information of Exynos5433 from Exynos5433
architector.
I take it CPUs boot at EL2?
Do the CPUs boot at EL1 or EL2?
Unfortunately, I cannot check the secure firmware for Exynos5433 SoC.
I think that a few SoC provider probably would know it.
I guess I asked the wrong question.
Do CPUs enter the kernel at EL2 or at EL1?
Could you give me a tip how to check the kernel at EL2 or EL1?
Thanks,
Chanwoo Choi
--
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] netlink: drop (int) cast on length arg in NLMSG_OK
From: Mike Frysinger vap...@gentoo.org Date: Thu, 5 Mar 2015 00:47:08 -0500 The NLMSG_OK macro compares three things: - the len arg from the user - a size_t: sizeof(struct nlmsghdr) - an int: sizeof(struct nlmsghdr) casted - an u32: the nlmsghdr-nlmsg_len member When building with -Wsign-compare, this macro triggers a signed compare warning. This is because it compares len to an int, and then compares it to a u32. If len is signed, we get a warning due to the last test. If len is unsigned, we get a warning due to the first test. Like in strace: socketutils.c:145:8: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] Lets drop the int cast on the first sizeof. This way, once the user casts len to an unsigned value, everything shakes out correctly. Signed-off-by: Mike Frysinger vap...@gentoo.org I don't think we can change this. If you get rid of the 'int' cast then code is going to end up with a signed comparison for the first test even if 'len' is signed, and that's a potential security 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/
[PATCH v2 3/6] x86, asm: Change the 32-bit sysenter code to use sp0
The ia32 sysenter code loaded the top of the kernel stack into rsp by loading kernel_stack and then adjusting it. It can be simplified to just read sp0 directly. This requires the addition of a new asm-offsets entry for sp0. Signed-off-by: Andy Lutomirski l...@amacapital.net --- arch/x86/ia32/ia32entry.S| 3 +-- arch/x86/kernel/asm-offsets_64.c | 1 + 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S index ed9746340363..719db63b35c4 100644 --- a/arch/x86/ia32/ia32entry.S +++ b/arch/x86/ia32/ia32entry.S @@ -113,8 +113,7 @@ ENTRY(ia32_sysenter_target) CFI_DEF_CFA rsp,0 CFI_REGISTERrsp,rbp SWAPGS_UNSAFE_STACK - movqPER_CPU_VAR(kernel_stack), %rsp - addq$(KERNEL_STACK_OFFSET),%rsp + movqPER_CPU_VAR(init_tss + TSS_sp0), %rsp /* * No need to follow this irqs on/off section: the syscall * disabled irqs, here we enable it straight after entry: diff --git a/arch/x86/kernel/asm-offsets_64.c b/arch/x86/kernel/asm-offsets_64.c index fdcbb4d27c9f..5ce6f2da8763 100644 --- a/arch/x86/kernel/asm-offsets_64.c +++ b/arch/x86/kernel/asm-offsets_64.c @@ -81,6 +81,7 @@ int main(void) #undef ENTRY OFFSET(TSS_ist, tss_struct, x86_tss.ist); + OFFSET(TSS_sp0, tss_struct, x86_tss.sp0); BLANK(); DEFINE(__NR_syscall_max, sizeof(syscalls_64) - 1); -- 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 0/6] Baby steps toward cleaning up KERNEL_STACK_OFFSET
Denys is right that KERNEL_STACK_OFFSET is a mess. Let's start fixing it. This removes all C code that *reads* kernel_stack. It also fixes the KERNEL_STACK_OFFSET abomination in ia32_sysenter_target. It does not fix the KERNEL_STACK_OFFSET abomination in GET_THREAD_INFO and THREAD_INFO. I think that should be its own patch. It also doesn't change the two syscall targets. To fix them, we should make a decision. Either we should make KERNEL_STACK_OFFSET have the correct nonzero value to save an instruction or we should get rid of kernel_stack entirely. Changes from v1: - Fix missing export. - Fix lguest code. - Add more init_tss naming cleanups (Ingo's suggestion). - Changelog improvements (Ingo). - Improve the check in ist_begin_non_atomic (Denys). Andy Lutomirski (6): x86: Add this_cpu_sp0() to read sp0 for the current cpu x86: Switch all C consumers of kernel_stack to this_cpu_sp0 x86, asm: Change the 32-bit sysenter code to use sp0 x86: Rename init_tss to cpu_tss x86: Remove INIT_TSS and fold the definitions into cpu_tss x86, asm: Rename INIT_TSS_IST to TSS_IST arch/x86/ia32/ia32entry.S | 3 +-- arch/x86/include/asm/processor.h | 27 ++- arch/x86/include/asm/thread_info.h | 3 +-- arch/x86/kernel/asm-offsets_64.c | 1 + arch/x86/kernel/cpu/common.c | 6 +++--- arch/x86/kernel/entry_64.S | 6 +++--- arch/x86/kernel/ioport.c | 2 +- arch/x86/kernel/process.c | 23 +-- arch/x86/kernel/process_32.c | 2 +- arch/x86/kernel/process_64.c | 2 +- arch/x86/kernel/traps.c| 4 ++-- arch/x86/kernel/vm86_32.c | 4 ++-- arch/x86/lguest/boot.c | 1 + arch/x86/power/cpu.c | 2 +- arch/x86/xen/enlighten.c | 1 + 15 files changed, 46 insertions(+), 41 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/6] x86: Switch all C consumers of kernel_stack to this_cpu_sp0
This will make modifying the semantics of kernel_stack easier.
The change to ist_begin_non_atomic() is necessary because sp0 no
longer points to the same THREAD_SIZE-aligned region as rsp; it's
one byte too high for that. At Denys' suggestion, rather than
offsetting it, just check explicitly that we're in the correct range
ending at sp0. This has the added benefit that we no longer assume
that the thread stack is aligned to THREAD_SIZE.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/include/asm/thread_info.h | 3 +--
arch/x86/kernel/traps.c| 4 ++--
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/thread_info.h
b/arch/x86/include/asm/thread_info.h
index 1d4e4f279a32..a2fa1899494e 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -159,8 +159,7 @@ DECLARE_PER_CPU(unsigned long, kernel_stack);
static inline struct thread_info *current_thread_info(void)
{
struct thread_info *ti;
- ti = (void *)(this_cpu_read_stable(kernel_stack) +
- KERNEL_STACK_OFFSET - THREAD_SIZE);
+ ti = (void *)(this_cpu_sp0() - THREAD_SIZE);
return ti;
}
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 42819886be0c..484eb03a3f32 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -174,8 +174,8 @@ void ist_begin_non_atomic(struct pt_regs *regs)
* will catch asm bugs and any attempt to use ist_preempt_enable
* from double_fault.
*/
- BUG_ON(((current_stack_pointer() ^ this_cpu_read_stable(kernel_stack))
-~(THREAD_SIZE - 1)) != 0);
+ BUG_ON((unsigned long)(this_cpu_sp0() - current_stack_pointer()) =
+ THREAD_SIZE);
preempt_count_sub(HARDIRQ_OFFSET);
}
--
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 4/6] x86: Rename init_tss to cpu_tss
It has nothing to do with init -- there's only one tss per cpu.
Other names considered include:
- current_tss: Confusing because we never switch the tss.
- singleton_tss: Too long.
This patch was generated with 's/init_tss/cpu_tss/g'. Followup patches
will fix INIT_TSS and INIT_TSS_IST by hand.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/ia32/ia32entry.S| 2 +-
arch/x86/include/asm/processor.h | 4 ++--
arch/x86/kernel/cpu/common.c | 6 +++---
arch/x86/kernel/entry_64.S | 2 +-
arch/x86/kernel/ioport.c | 2 +-
arch/x86/kernel/process.c| 6 +++---
arch/x86/kernel/process_32.c | 2 +-
arch/x86/kernel/process_64.c | 2 +-
arch/x86/kernel/vm86_32.c| 4 ++--
arch/x86/power/cpu.c | 2 +-
10 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
index 719db63b35c4..ad9efef65a6b 100644
--- a/arch/x86/ia32/ia32entry.S
+++ b/arch/x86/ia32/ia32entry.S
@@ -113,7 +113,7 @@ ENTRY(ia32_sysenter_target)
CFI_DEF_CFA rsp,0
CFI_REGISTERrsp,rbp
SWAPGS_UNSAFE_STACK
- movqPER_CPU_VAR(init_tss + TSS_sp0), %rsp
+ movqPER_CPU_VAR(cpu_tss + TSS_sp0), %rsp
/*
* No need to follow this irqs on/off section: the syscall
* disabled irqs, here we enable it straight after entry:
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 71c3a826a690..117ee65473e2 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -282,7 +282,7 @@ struct tss_struct {
} cacheline_aligned;
-DECLARE_PER_CPU_SHARED_ALIGNED(struct tss_struct, init_tss);
+DECLARE_PER_CPU_SHARED_ALIGNED(struct tss_struct, cpu_tss);
/*
* Save the original ist values for checking stack pointers during debugging
@@ -566,7 +566,7 @@ static inline void native_swapgs(void)
static inline unsigned long this_cpu_sp0(void)
{
- return this_cpu_read_stable(init_tss.x86_tss.sp0);
+ return this_cpu_read_stable(cpu_tss.x86_tss.sp0);
}
#ifdef CONFIG_PARAVIRT
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 2346c95c6ab1..5d0f0cc7ea26 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -979,7 +979,7 @@ static void syscall32_cpu_init(void)
void enable_sep_cpu(void)
{
int cpu = get_cpu();
- struct tss_struct *tss = per_cpu(init_tss, cpu);
+ struct tss_struct *tss = per_cpu(cpu_tss, cpu);
if (!boot_cpu_has(X86_FEATURE_SEP)) {
put_cpu();
@@ -1307,7 +1307,7 @@ void cpu_init(void)
*/
load_ucode_ap();
- t = per_cpu(init_tss, cpu);
+ t = per_cpu(cpu_tss, cpu);
oist = per_cpu(orig_ist, cpu);
#ifdef CONFIG_NUMA
@@ -1391,7 +1391,7 @@ void cpu_init(void)
{
int cpu = smp_processor_id();
struct task_struct *curr = current;
- struct tss_struct *t = per_cpu(init_tss, cpu);
+ struct tss_struct *t = per_cpu(cpu_tss, cpu);
struct thread_struct *thread = curr-thread;
wait_for_master_cpu(cpu);
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 622ce4254893..0c00fd80249a 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -959,7 +959,7 @@ apicinterrupt IRQ_WORK_VECTOR \
/*
* Exception entry points.
*/
-#define INIT_TSS_IST(x) PER_CPU_VAR(init_tss) + (TSS_ist + ((x) - 1) * 8)
+#define INIT_TSS_IST(x) PER_CPU_VAR(cpu_tss) + (TSS_ist + ((x) - 1) * 8)
.macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1
ENTRY(\sym)
diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
index 4ddaf66ea35f..37dae792dbbe 100644
--- a/arch/x86/kernel/ioport.c
+++ b/arch/x86/kernel/ioport.c
@@ -54,7 +54,7 @@ asmlinkage long sys_ioperm(unsigned long from, unsigned long
num, int turn_on)
* because the -io_bitmap_max value must match the bitmap
* contents:
*/
- tss = per_cpu(init_tss, get_cpu());
+ tss = per_cpu(cpu_tss, get_cpu());
if (turn_on)
bitmap_clear(t-io_bitmap_ptr, from, num);
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index ff5c9088b1c5..6f6087349231 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -37,8 +37,8 @@
* section. Since TSS's are completely CPU-local, we want them
* on exact cacheline boundaries, to eliminate cacheline ping-pong.
*/
-__visible DEFINE_PER_CPU_SHARED_ALIGNED(struct tss_struct, init_tss) =
INIT_TSS;
-EXPORT_PER_CPU_SYMBOL_GPL(init_tss);
+__visible DEFINE_PER_CPU_SHARED_ALIGNED(struct tss_struct, cpu_tss) = INIT_TSS;
+EXPORT_PER_CPU_SYMBOL_GPL(cpu_tss);
#ifdef CONFIG_X86_64
static DEFINE_PER_CPU(unsigned char, is_idle);
@@ -110,7 +110,7 @@ void exit_thread(void)
unsigned long *bp = t-io_bitmap_ptr;
if (bp) {
- struct tss_struct *tss = per_cpu(init_tss, get_cpu());
Re: pskb_expand_head: skb_shared BUG
On Mon, Mar 02, 2015 at 11:45:11AM +1100, Chris Dunlop wrote:
Heads up...
We've hit this BUG() in v3.10.70, v3.14.27 and v3.18.7:
net/core/skbuff.c:
1027 int pskb_expand_head(struct sk_buff *skb, int nhead, int ntail,
1028 gfp_t gfp_mask)
1029 {
1030 int i;
1031 u8 *data;
1032 int size = nhead + skb_end_offset(skb) + ntail;
1033 long off;
1034
1035 BUG_ON(nhead 0);
1036
1037 if (skb_shared(skb))
1038 BUG(); BOOM!!!
This appears to be a regression in the 3.10.x stable series:
we've been running for 11 months on v3.10.33 without problem, we
upgraded to v3.14.27 and hit the BUG(), than again on upgrading
to v3.18.7, then again after downgrading to v3.10.70.
Apologies, this was a false alarm.
There was indeed a regression, but it's in the upstream openvswitch code
rather than linux core. (Further details: a sharing of an
otherwise-unshared skb, causing us to hit the BUG() above, introduced in
v2.3, will be fixed in upcoming v2.3.2)
Cheers,
Chris
--
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 0/17] crypto: talitos - Add support for SEC1
On Thu, Mar 05, 2015 at 06:21:01PM -0600, Kim Phillips wrote: On Thu, 5 Mar 2015 17:46:05 +0100 Christophe Leroy christophe.le...@c-s.fr wrote: [15/17] crypto: talitos - Implementation of SEC1 ... [16/17] crypto: talitos - SEC1 bugs on 0 data hash [17/17] crypto: talitos - Update DT bindings with SEC1 This patchseries doesn't apply, at least on top of Herbert's cryptodev-2.6 tree, as of today: Applying: crypto: talitos - Implementation of SEC1 error: patch failed: drivers/crypto/talitos.c:655 error: drivers/crypto/talitos.c: patch does not apply Also the patches are coming in a random order. Please send them one at a time to ensure proper ordering. Thanks, -- Email: Herbert Xu herb...@gondor.apana.org.au 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/
[PATCH v8 3/3] staging: fsl-mc: Device driver for FSL-MC DPRC devices
A DPRC (Data Path Resource Container) is an isolation device
that contains a set of DPAA networking devices to be
assigned to an isolation domain (e.g., a virtual machine).
Signed-off-by: J. German Rivera german.riv...@freescale.com
Signed-off-by: Stuart Yoder stuart.yo...@freescale.com
---
Changes in v8:
- Addressed comments from Greg Kroah-Hartman:
* Moved files to drivers/staging to wait for child drivers of the fsl-mc bus
to be posted upstream:
drivers/bus/fsl-mc/dprc-driver.c -
drivers/staging/fsl-mc/bus/dprc-driver.c
Changes in v7:
- Create fsl_mc_io object in dprc_probe()
Changes in v6:
- Fixed new checkpatch warnings
Changes in v5:
None
Changes in v4:
- Addressed comments from Alex Graf:
* Fixed typo in comment
Changes in v3:
- Addressed comments from Kim Phillips:
* Renamed files:
drivers/bus/fsl-mc/fsl_mc_dprc.c - drivers/bus/fsl-mc/dprc-driver.c
- Addressed comments from Timur Tabi:
* Changed dprc_scan_container() to just return dprc_scan_objects()
* Changed all functions that had goto out/error when no common cleanup
was done, to just have multiple return points.
* Replaced error cleanup boolean flags with multiple exit points.
* REmoved __must_chewck from dprc_scan_*() functions
Changes in v2:
- Addressed comments from Kim Phillips:
* Fix warning in drivers/bus/fsl-mc/fsl_mc_dprc.c:173
* Fixed linker errors when MC bus driver built as module
drivers/staging/fsl-mc/bus/Makefile | 3 +-
drivers/staging/fsl-mc/bus/dprc-driver.c| 384
drivers/staging/fsl-mc/bus/mc-bus.c | 8 +
drivers/staging/fsl-mc/include/mc-private.h | 10 +
4 files changed, 404 insertions(+), 1 deletion(-)
create mode 100644 drivers/staging/fsl-mc/bus/dprc-driver.c
diff --git a/drivers/staging/fsl-mc/bus/Makefile
b/drivers/staging/fsl-mc/bus/Makefile
index decd339..424e58e 100644
--- a/drivers/staging/fsl-mc/bus/Makefile
+++ b/drivers/staging/fsl-mc/bus/Makefile
@@ -10,5 +10,6 @@ obj-$(CONFIG_FSL_MC_BUS) += mc-bus-driver.o
mc-bus-driver-objs := mc-bus.o \
mc-sys.o \
dprc.o \
- dpmng.o
+ dpmng.o \
+ dprc-driver.o
diff --git a/drivers/staging/fsl-mc/bus/dprc-driver.c
b/drivers/staging/fsl-mc/bus/dprc-driver.c
new file mode 100644
index 000..f5d1deb
--- /dev/null
+++ b/drivers/staging/fsl-mc/bus/dprc-driver.c
@@ -0,0 +1,384 @@
+/*
+ * Freescale data path resource container (DPRC) driver
+ *
+ * Copyright (C) 2014 Freescale Semiconductor, Inc.
+ * Author: German Rivera german.riv...@freescale.com
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include ../include/mc-private.h
+#include ../include/mc-sys.h
+#include linux/module.h
+#include linux/slab.h
+#include dprc-cmd.h
+
+struct dprc_child_objs {
+ int child_count;
+ struct dprc_obj_desc *child_array;
+};
+
+static int __fsl_mc_device_remove_if_not_in_mc(struct device *dev, void *data)
+{
+ int i;
+ struct dprc_child_objs *objs;
+ struct fsl_mc_device *mc_dev;
+
+ WARN_ON(!dev);
+ WARN_ON(!data);
+ mc_dev = to_fsl_mc_device(dev);
+ objs = data;
+
+ for (i = 0; i objs-child_count; i++) {
+ struct dprc_obj_desc *obj_desc = objs-child_array[i];
+
+ if (strlen(obj_desc-type) != 0
+ FSL_MC_DEVICE_MATCH(mc_dev, obj_desc))
+ break;
+ }
+
+ if (i == objs-child_count)
+ fsl_mc_device_remove(mc_dev);
+
+ return 0;
+}
+
+static int __fsl_mc_device_remove(struct device *dev, void *data)
+{
+ WARN_ON(!dev);
+ WARN_ON(data);
+ fsl_mc_device_remove(to_fsl_mc_device(dev));
+ return 0;
+}
+
+/**
+ * dprc_remove_devices - Removes devices for objects removed from a DPRC
+ *
+ * @mc_bus_dev: pointer to the fsl-mc device that represents a DPRC object
+ * @obj_desc_array: array of object descriptors for child objects currently
+ * present in the DPRC in the MC.
+ * @num_child_objects_in_mc: number of entries in obj_desc_array
+ *
+ * Synchronizes the state of the Linux bus driver with the actual state of
+ * the MC by removing devices that represent MC objects that have
+ * been dynamically removed in the physical DPRC.
+ */
+static void dprc_remove_devices(struct fsl_mc_device *mc_bus_dev,
+ struct dprc_obj_desc *obj_desc_array,
+ int num_child_objects_in_mc)
+{
+ if (num_child_objects_in_mc != 0) {
+ /*
+* Remove child objects that are in the DPRC in Linux,
+* but not in the MC:
+*/
+ struct dprc_child_objs objs;
+
+ objs.child_count = num_child_objects_in_mc;
+ objs.child_array =
