[PATCH 4/5] TTY: add __init attribute

Add __init attribute on a function that is only called from other __init functions and that is not inlined, at least with gcc version 4.8.4 on an x86 machine with allyesconfig. Currently, the function is put in the .text.unlikely segment. Declaring it as __init will cause it to be put in the

[PATCH 8/8] arm64: kaslr: increase randomization granularity

Currently, our KASLR implementation randomizes the placement of the core kernel at 2 MB granularity. This is based on the arm64 kernel boot protocol, which mandates that the kernel is loaded TEXT_OFFSET bytes above a 2 MB aligned base address. This requirement is a result of the fact that the

[PATCH 5/5] cmd640: add __init attribute

Add __init attribute on a function that is only called from other __init functions and that is not inlined, at least with gcc version 4.8.4 on an x86 machine with allyesconfig. Currently, the function is put in the .text.unlikely segment. Declaring it as __init will cause it to be put in the

[PATCH 5/5] cmd640: add __init attribute

Add __init attribute on a function that is only called from other __init functions and that is not inlined, at least with gcc version 4.8.4 on an x86 machine with allyesconfig. Currently, the function is put in the .text.unlikely segment. Declaring it as __init will cause it to be put in the

[PATCH 0/8] arm64: kaslr cleanups and improvements

This is a follow up to my series 'arm64: more granular KASLR' [1] that I sent out about six weeks ago. It also partially supersedes [2]. The first patch is an unrelated cleanup that is completely orthogonal (but happens to touch head.S as well) and is arbitrarily listed first. Patches #2 to #5

[PATCH 0/8] arm64: kaslr cleanups and improvements

This is a follow up to my series 'arm64: more granular KASLR' [1] that I sent out about six weeks ago. It also partially supersedes [2]. The first patch is an unrelated cleanup that is completely orthogonal (but happens to touch head.S as well) and is arbitrarily listed first. Patches #2 to #5

[PATCH 3/8] arm64: kernel: perform relocation processing from ID map

Refactor the relocation processing so that the code executes from the ID map while accessing the relocation tables via the virtual mapping. This way, we can use literals containing virtual addresses as before, instead of having to use convoluted absolute expressions. For symmetry with the

[PATCH 3/8] arm64: kernel: perform relocation processing from ID map

Refactor the relocation processing so that the code executes from the ID map while accessing the relocation tables via the virtual mapping. This way, we can use literals containing virtual addresses as before, instead of having to use convoluted absolute expressions. For symmetry with the

[PATCH 1/8] arm64: kernel: don't export local symbols from head.S

This unexports some symbols from head.S that are only used locally. Signed-off-by: Ard Biesheuvel --- arch/arm64/kernel/head.S | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S index

[PATCH 1/8] arm64: kernel: don't export local symbols from head.S

This unexports some symbols from head.S that are only used locally. Signed-off-by: Ard Biesheuvel --- arch/arm64/kernel/head.S | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S index b43417618847..ac27d8d937b2 100644

[RFC PATCH 1/2] s390: livepatch, reorganize TIF bits

From: Jiri Slaby Signed-off-by: Jiri Slaby --- arch/s390/include/asm/thread_info.h | 22 ++ 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/arch/s390/include/asm/thread_info.h b/arch/s390/include/asm/thread_info.h index

[RFC PATCH 1/2] s390: livepatch, reorganize TIF bits

From: Jiri Slaby Signed-off-by: Jiri Slaby --- arch/s390/include/asm/thread_info.h | 22 ++ 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/arch/s390/include/asm/thread_info.h b/arch/s390/include/asm/thread_info.h index 2fffc2c27581..8642c1dab382 100644 ---

[RFC PATCH 0/2] s390/klp: s390 support

So this is something we have in kGraft for a while (though the actual implementation in s390's entry.S differs). The first patch is needed because we want our TIF flag to be part of _TIF_WORK and s390's tm instruction tests only 8-bits. The second patch adds a call to klp_update_task_universe()

[RFC PATCH 0/2] s390/klp: s390 support

So this is something we have in kGraft for a while (though the actual implementation in s390's entry.S differs). The first patch is needed because we want our TIF flag to be part of _TIF_WORK and s390's tm instruction tests only 8-bits. The second patch adds a call to klp_update_task_universe()

[RFC PATCH 2/2] s390/klp: update task universe when exiting kernel

Update a tasks's universe when returning from a system call or user space interrupt, or after handling a signal. This greatly increases the chances of a patch operation succeeding. If a task is I/O bound, it can switch universes when returning from a system call. If a task is CPU bound, it can

[RFC PATCH 2/2] s390/klp: update task universe when exiting kernel

Update a tasks's universe when returning from a system call or user space interrupt, or after handling a signal. This greatly increases the chances of a patch operation succeeding. If a task is I/O bound, it can switch universes when returning from a system call. If a task is CPU bound, it can

Re: [PATCH] mm: __delete_from_page_cache show Bad page if mapped

On 03/01/2016 01:45 AM, Hugh Dickins wrote: > Commit e1534ae95004 ("mm: differentiate page_mapped() from page_mapcount() > for compound pages") changed the famous BUG_ON(page_mapped(page)) in > __delete_from_page_cache() to VM_BUG_ON_PAGE(page_mapped(page)): which > gives us more info when

Re: [PATCH] mm: __delete_from_page_cache show Bad page if mapped

On 03/01/2016 01:45 AM, Hugh Dickins wrote: > Commit e1534ae95004 ("mm: differentiate page_mapped() from page_mapcount() > for compound pages") changed the famous BUG_ON(page_mapped(page)) in > __delete_from_page_cache() to VM_BUG_ON_PAGE(page_mapped(page)): which > gives us more info when

ERROR: "vring_del_virtqueue" [drivers/misc/mic/vop/vop.ko] undefined!

Hi Sudeep, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: c3b46c73264b03000d1e18b22f5caf63332547c9 commit: 8810df37762746657cfe84014a8f30758e8f366a misc: mic: Enable VOP debugfs and driver build date: 10 weeks

Re: [PATCH] tools: Use builtin $(abspath ...) instead of $(shell cd ... && pwd)

On Mon, Apr 18, 2016 at 04:46:53PM +0200, Michal Marek wrote: > On 2016-04-08 11:15, Thierry Reding wrote: > > From: Thierry Reding > > > > Avoid forking off a shell to resolve the absolute path of the output > > directory when make's builtin $(abspath ...) function will do

ERROR: "vring_del_virtqueue" [drivers/misc/mic/vop/vop.ko] undefined!

Hi Sudeep, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: c3b46c73264b03000d1e18b22f5caf63332547c9 commit: 8810df37762746657cfe84014a8f30758e8f366a misc: mic: Enable VOP debugfs and driver build date: 10 weeks

Re: [PATCH] tools: Use builtin $(abspath ...) instead of $(shell cd ... && pwd)

On Mon, Apr 18, 2016 at 04:46:53PM +0200, Michal Marek wrote: > On 2016-04-08 11:15, Thierry Reding wrote: > > From: Thierry Reding > > > > Avoid forking off a shell to resolve the absolute path of the output > > directory when make's builtin $(abspath ...) function will do an > > adequate job.

Re: [PATCH v5 39/50] mtd: nand: omap2: switch to mtd_ooblayout_ops

On Mon, 18 Apr 2016 17:32:49 +0300 Roger Quadros wrote: > Boris, > > On 30/03/16 19:14, Boris Brezillon wrote: > > Implementing the mtd_ooblayout_ops interface is the new way of exposing > > ECC/OOB layout to MTD users. > > > > Signed-off-by: Boris Brezillon

Re: [PATCH v5 39/50] mtd: nand: omap2: switch to mtd_ooblayout_ops

On Mon, 18 Apr 2016 17:32:49 +0300 Roger Quadros wrote: > Boris, > > On 30/03/16 19:14, Boris Brezillon wrote: > > Implementing the mtd_ooblayout_ops interface is the new way of exposing > > ECC/OOB layout to MTD users. > > > > Signed-off-by: Boris Brezillon > > --- > >

Re: [PATCH v2 5/5] iio: gyro: bmg160: use regmap to retrieve struct device

On Sat, 2016-04-16 at 20:24 +0100, Jonathan Cameron wrote: > On 10/04/16 20:08, Alison Schofield wrote: > > > > Driver includes struct regmap and struct device in its global data. > > Remove the struct device and use regmap API to retrieve device > > info. > > > > Patch created using Coccinelle

Re: [PATCH v2 5/5] iio: gyro: bmg160: use regmap to retrieve struct device

On Sat, 2016-04-16 at 20:24 +0100, Jonathan Cameron wrote: > On 10/04/16 20:08, Alison Schofield wrote: > > > > Driver includes struct regmap and struct device in its global data. > > Remove the struct device and use regmap API to retrieve device > > info. > > > > Patch created using Coccinelle

Re: [PATCH v2 1/5] iio: accel: bmc150: use regmap to retrieve struct device

On Sat, 2016-04-16 at 20:20 +0100, Jonathan Cameron wrote: > On 10/04/16 20:05, Alison Schofield wrote: > > > > Driver includes struct regmap and struct device in its global data. > > Remove the struct device and use regmap API to retrieve device > > info. > > > > Patch created using Coccinelle

Re: [PATCH v2 1/5] iio: accel: bmc150: use regmap to retrieve struct device

On Sat, 2016-04-16 at 20:20 +0100, Jonathan Cameron wrote: > On 10/04/16 20:05, Alison Schofield wrote: > > > > Driver includes struct regmap and struct device in its global data. > > Remove the struct device and use regmap API to retrieve device > > info. > > > > Patch created using Coccinelle

[PATCH v5 2/6] perf record: Split output into multiple files via '--switch-output'

Allow 'perf record' to split its output into multiple files. For example: # ~/perf record -a --timestamp-filename --switch-output & [1] 10763 # kill -s SIGUSR2 10763 [ perf record: dump data: Woken up 1 times ] # [ perf record: Dump perf.data.2015122622314468 ] # kill -s SIGUSR2

[PATCH v5 2/6] perf record: Split output into multiple files via '--switch-output'

Allow 'perf record' to split its output into multiple files. For example: # ~/perf record -a --timestamp-filename --switch-output & [1] 10763 # kill -s SIGUSR2 10763 [ perf record: dump data: Woken up 1 times ] # [ perf record: Dump perf.data.2015122622314468 ] # kill -s SIGUSR2

Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

On Mon, 18 Apr 2016 17:39:01 +0300 Roger Quadros wrote: > On 18/04/16 17:10, Boris Brezillon wrote: > > On Mon, 18 Apr 2016 16:48:26 +0300 > > Roger Quadros wrote: > > > >> Boris, > >> > >> On 18/04/16 16:13, Boris Brezillon wrote: > >>> Hi Roger, > >>> > >>> On

Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

On Mon, 18 Apr 2016 17:39:01 +0300 Roger Quadros wrote: > On 18/04/16 17:10, Boris Brezillon wrote: > > On Mon, 18 Apr 2016 16:48:26 +0300 > > Roger Quadros wrote: > > > >> Boris, > >> > >> On 18/04/16 16:13, Boris Brezillon wrote: > >>> Hi Roger, > >>> > >>> On Mon, 18 Apr 2016 15:52:58 +0300

[PATCH v5 6/6] perf record: Generate tracking events for process forked by perf

With 'perf record --switch-output' without -a, record__synthesize() in record__switch_output() won't generate tracking events because there's no thread_map in evlist. Which causes newly created perf.data doesn't contain map and comm information. This patch creates a fake thread_map and directly

[PATCH v5 6/6] perf record: Generate tracking events for process forked by perf

With 'perf record --switch-output' without -a, record__synthesize() in record__switch_output() won't generate tracking events because there's no thread_map in evlist. Which causes newly created perf.data doesn't contain map and comm information. This patch creates a fake thread_map and directly

Re: [PATCHv2] wlcore: spi: add wl18xx support

On Monday 18 April 2016 05:55:51 Reizer, Eyal wrote: > > > > > > - all wilink family needs special init command for entering wspi mode. > > > extra clock cycles should be sent after the spi init command while the > > > cs pin is high. > > > - switch to controling the cs pin from the spi driver

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

Yes, it is. Certainly happened while editing patches (sorry about that), will be fixed on next iteration once I get a bit more feedback. On Mon, Apr 18, 2016 at 7:46 AM, Joerg Roedel wrote: > On Fri, Apr 15, 2016 at 03:03:12PM -0700, Thomas Garnier wrote: >> +#if

Re: [PATCHv2] wlcore: spi: add wl18xx support

On Monday 18 April 2016 05:55:51 Reizer, Eyal wrote: > > > > > > - all wilink family needs special init command for entering wspi mode. > > > extra clock cycles should be sent after the spi init command while the > > > cs pin is high. > > > - switch to controling the cs pin from the spi driver

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

Yes, it is. Certainly happened while editing patches (sorry about that), will be fixed on next iteration once I get a bit more feedback. On Mon, Apr 18, 2016 at 7:46 AM, Joerg Roedel wrote: > On Fri, Apr 15, 2016 at 03:03:12PM -0700, Thomas Garnier wrote: >> +#if defined(CONFIG_KASAN) >> +static

[PATCH v5 4/6] perf record: Disable buildid cache options by default in switch output mode

The cost of buildid cache processing is high: reading all events in output perf.data, opening each elf file to read buildids then copying them into ~/.debug directory. In switch output mode, these heavy works block perf from receiving perf events for too long. Enable no-buildid and

Re: [PATCH] leds: ledtrig-ide-disk: Move ide_blink_delay to ledtrig_ide_activity()

On Mon, 18 Apr 2016 16:40:46 +0200 Jacek Anaszewski wrote: > Parameters delay_on and delay_off of led_trigger_blink_oneshot() > are pointers, to enable blink interval adjustment by LED class drivers > of the controllers that implement hardware blinking. > > Move

[PATCH v5 5/6] perf record: Re-synthesize tracking events after output switching

Tracking events describe kernel and threads. They are generated by reading /proc/kallsyms, /proc/*/maps and /proc/*/task/* during initialization of 'perf record', serialized into event sequences and put at the head of 'perf.data'. In case of output switching, each output file should contain those

[PATCH v5 3/6] perf record: Force enable --timestamp-filename when --switch-output is provided

Without this patch, the last output doesn't have timestamp appended if --timestamp-filename is not explicitly provided. For example: # perf record -a --switch-output & [1] 11224 # kill -s SIGUSR2 11224 [ perf record: dump data: Woken up 1 times ] # [ perf record: Dump

Re: [PATCH] leds: ledtrig-ide-disk: Move ide_blink_delay to ledtrig_ide_activity()

On Mon, 18 Apr 2016 16:40:46 +0200 Jacek Anaszewski wrote: > Parameters delay_on and delay_off of led_trigger_blink_oneshot() > are pointers, to enable blink interval adjustment by LED class drivers > of the controllers that implement hardware blinking. > > Move ide_blink_delay variable to

[PATCH v5 5/6] perf record: Re-synthesize tracking events after output switching

Tracking events describe kernel and threads. They are generated by reading /proc/kallsyms, /proc/*/maps and /proc/*/task/* during initialization of 'perf record', serialized into event sequences and put at the head of 'perf.data'. In case of output switching, each output file should contain those

[PATCH v5 4/6] perf record: Disable buildid cache options by default in switch output mode

The cost of buildid cache processing is high: reading all events in output perf.data, opening each elf file to read buildids then copying them into ~/.debug directory. In switch output mode, these heavy works block perf from receiving perf events for too long. Enable no-buildid and

[PATCH v5 3/6] perf record: Force enable --timestamp-filename when --switch-output is provided

Without this patch, the last output doesn't have timestamp appended if --timestamp-filename is not explicitly provided. For example: # perf record -a --switch-output & [1] 11224 # kill -s SIGUSR2 11224 [ perf record: dump data: Woken up 1 times ] # [ perf record: Dump

[PATCH v5 1/6] perf tools: Derive trigger class from auxtrace_snapshot

Use 'trigger' to model operations which need to be executed when an event (a signal, for example) is observed. States and transits: OFF--(on)--> READY --(toggle)--> TOGGLED ^| | (ready) ||

[PATCH v5 1/6] perf tools: Derive trigger class from auxtrace_snapshot

Use 'trigger' to model operations which need to be executed when an event (a signal, for example) is observed. States and transits: OFF--(on)--> READY --(toggle)--> TOGGLED ^| | (ready) ||

[PATCH v5 0/6] perf tools: Use SIGUSR2 control data dumpping

v4 -> v5: 'PROCESSING' state has only one user. Remove it to reduce confusion. Cc: Wang Nan Cc: Adrian Hunter Cc: He Kuang Cc: Jiri Olsa Cc: Masami Hiramatsu Cc: Namhyung Kim

[PATCH v5 0/6] perf tools: Use SIGUSR2 control data dumpping

v4 -> v5: 'PROCESSING' state has only one user. Remove it to reduce confusion. Cc: Wang Nan Cc: Adrian Hunter Cc: He Kuang Cc: Jiri Olsa Cc: Masami Hiramatsu Cc: Namhyung Kim Cc: Zefan Li Cc: pi3or...@163.com Wang Nan (6): perf tools: Derive trigger class from

Re: [PATCH v8 3/4] perf config: Prepare all default configs

Hi, Namhyung On 04/15/2016 01:42 AM, Taeung Song wrote: Hi, Arnaldo On 04/14/2016 09:19 PM, Arnaldo Carvalho de Melo wrote: Em Thu, Apr 14, 2016 at 04:53:20PM +0900, Taeung Song escreveu: To precisely manage configs, prepare all default perf's configs that contain default section name,

RE: [PATCH V2] net: ethernet: mellanox: correct page conversion

Right, I did not suggest this as a patch but just wanted to pinpoint the problematic issue which is that virt_to_page does not give you the correct pointer to the page. -Original Message- From: Christoph Hellwig [mailto:h...@infradead.org] Sent: Monday, April 18, 2016 9:33 AM To: Eli

Re: [PATCH v8 3/4] perf config: Prepare all default configs

Hi, Namhyung On 04/15/2016 01:42 AM, Taeung Song wrote: Hi, Arnaldo On 04/14/2016 09:19 PM, Arnaldo Carvalho de Melo wrote: Em Thu, Apr 14, 2016 at 04:53:20PM +0900, Taeung Song escreveu: To precisely manage configs, prepare all default perf's configs that contain default section name,

RE: [PATCH V2] net: ethernet: mellanox: correct page conversion

Right, I did not suggest this as a patch but just wanted to pinpoint the problematic issue which is that virt_to_page does not give you the correct pointer to the page. -Original Message- From: Christoph Hellwig [mailto:h...@infradead.org] Sent: Monday, April 18, 2016 9:33 AM To: Eli

Re: [PATCH v2 1/5] phy: Add a driver for simple phy

On Monday 18 April 2016 18:00:19 Kishon Vijay Abraham I wrote: > Hi Arnd, > > On Sunday 17 April 2016 01:20 AM, Arnd Bergmann wrote: > > On Thursday 14 April 2016 11:22:58 Kishon Vijay Abraham I wrote: > >> > >> IMO simple-phy driver should be an independent driver and shouldn't export > >>

Re: [PATCH v2 1/5] phy: Add a driver for simple phy

On Monday 18 April 2016 18:00:19 Kishon Vijay Abraham I wrote: > Hi Arnd, > > On Sunday 17 April 2016 01:20 AM, Arnd Bergmann wrote: > > On Thursday 14 April 2016 11:22:58 Kishon Vijay Abraham I wrote: > >> > >> IMO simple-phy driver should be an independent driver and shouldn't export > >>

Re: [BUG] cgroup/workques/fork: deadlock when moving cgroups

On Fri 2016-04-15 10:38:15, Tejun Heo wrote: > > Anyway, before we go that way, can we at least consider the possibility > > of removing the kworker creation dependency on the global rwsem? AFAIU > > this locking was added because of the pid controller. Do we even care > > about something as

[PATCH] leds: ledtrig-ide-disk: Move ide_blink_delay to ledtrig_ide_activity()

Parameters delay_on and delay_off of led_trigger_blink_oneshot() are pointers, to enable blink interval adjustment by LED class drivers of the controllers that implement hardware blinking. Move ide_blink_delay variable to ledtrig_ide_activity() in order to prevent the situation when adjustment

Re: [BUG] cgroup/workques/fork: deadlock when moving cgroups

On Fri 2016-04-15 10:38:15, Tejun Heo wrote: > > Anyway, before we go that way, can we at least consider the possibility > > of removing the kworker creation dependency on the global rwsem? AFAIU > > this locking was added because of the pid controller. Do we even care > > about something as

[PATCH] leds: ledtrig-ide-disk: Move ide_blink_delay to ledtrig_ide_activity()

Parameters delay_on and delay_off of led_trigger_blink_oneshot() are pointers, to enable blink interval adjustment by LED class drivers of the controllers that implement hardware blinking. Move ide_blink_delay variable to ledtrig_ide_activity() in order to prevent the situation when adjustment

Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

On 18/04/16 17:10, Boris Brezillon wrote: > On Mon, 18 Apr 2016 16:48:26 +0300 > Roger Quadros wrote: > >> Boris, >> >> On 18/04/16 16:13, Boris Brezillon wrote: >>> Hi Roger, >>> >>> On Mon, 18 Apr 2016 15:52:58 +0300 >>> Roger Quadros wrote: >>> On 18/04/16

Re: [PATCH V6 00/13] Support for generic ACPI based PCI host controller

On Monday 18 April 2016 15:33:24 Tomasz Nowicki wrote: > > Of course we can split discussion into the two topics: > 1. ECAM based ACPI host controller - patches [1-10] > 2. Quirks handling and examples. > > IMO, it is very helpful for reviewers to go with one unified patch set > and see the

Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

On 18/04/16 17:10, Boris Brezillon wrote: > On Mon, 18 Apr 2016 16:48:26 +0300 > Roger Quadros wrote: > >> Boris, >> >> On 18/04/16 16:13, Boris Brezillon wrote: >>> Hi Roger, >>> >>> On Mon, 18 Apr 2016 15:52:58 +0300 >>> Roger Quadros wrote: >>> On 18/04/16 15:31, Roger Quadros wrote:

Re: [PATCH V6 00/13] Support for generic ACPI based PCI host controller

On Monday 18 April 2016 15:33:24 Tomasz Nowicki wrote: > > Of course we can split discussion into the two topics: > 1. ECAM based ACPI host controller - patches [1-10] > 2. Quirks handling and examples. > > IMO, it is very helpful for reviewers to go with one unified patch set > and see the

Re: [PATCH] tools: Use builtin $(abspath ...) instead of $(shell cd ... && pwd)

On 2016-04-08 11:15, Thierry Reding wrote: > From: Thierry Reding > > Avoid forking off a shell to resolve the absolute path of the output > directory when make's builtin $(abspath ...) function will do an > adequate job. The abspath function is not available in make 3.80.

Re: [PATCH] tools: Use builtin $(abspath ...) instead of $(shell cd ... && pwd)

On 2016-04-08 11:15, Thierry Reding wrote: > From: Thierry Reding > > Avoid forking off a shell to resolve the absolute path of the output > directory when make's builtin $(abspath ...) function will do an > adequate job. The abspath function is not available in make 3.80. Michal

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On Fri, Apr 15, 2016 at 03:03:12PM -0700, Thomas Garnier wrote: > +#if defined(CONFIG_KASAN) > +static const unsigned long memory_rand_end = KASAN_SHADOW_START; > +#elfif defined(CONFIG_X86_ESPFIX64) > +static const unsigned long memory_rand_end = ESPFIX_BASE_ADDR; > +#elfif defined(CONFIG_EFI) >

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On Fri, Apr 15, 2016 at 03:03:12PM -0700, Thomas Garnier wrote: > +#if defined(CONFIG_KASAN) > +static const unsigned long memory_rand_end = KASAN_SHADOW_START; > +#elfif defined(CONFIG_X86_ESPFIX64) > +static const unsigned long memory_rand_end = ESPFIX_BASE_ADDR; > +#elfif defined(CONFIG_EFI) >

mm: NULL ptr deref in free_pages_and_swap_cache

Hi all, I've hit the following while fuzzing with syzkaller inside a KVM tools guest running the latest -next kernel: [ 326.963405] general protection fault: [#1] PREEMPT SMP KASAN [ 326.963416] Modules linked in: [ 326.963430] CPU: 0 PID: 10488 Comm: syz-executor Not tainted

mm: NULL ptr deref in free_pages_and_swap_cache

Hi all, I've hit the following while fuzzing with syzkaller inside a KVM tools guest running the latest -next kernel: [ 326.963405] general protection fault: [#1] PREEMPT SMP KASAN [ 326.963416] Modules linked in: [ 326.963430] CPU: 0 PID: 10488 Comm: syz-executor Not tainted

Re: [PATCH V6 08/13] PCI: generic, thunder: update to use generic ECAM API

On Monday 18 April 2016 15:03:51 Tomasz Nowicki wrote: > On 16.04.2016 16:36, Jayachandran C wrote: > > On Sat, Apr 16, 2016 at 1:01 PM, Arnd Bergmann wrote: > >> On Saturday 16 April 2016 12:50:13 Jayachandran C wrote: > > The whole pci-thunder-*.c is to support thunder PCI quirks

Re: [PATCH V6 08/13] PCI: generic, thunder: update to use generic ECAM API

On Monday 18 April 2016 15:03:51 Tomasz Nowicki wrote: > On 16.04.2016 16:36, Jayachandran C wrote: > > On Sat, Apr 16, 2016 at 1:01 PM, Arnd Bergmann wrote: > >> On Saturday 16 April 2016 12:50:13 Jayachandran C wrote: > > The whole pci-thunder-*.c is to support thunder PCI quirks since the > >

Re: [PATCH 0/3] v4.4: Revert "PCI: Implement pcibios_alloc_irq() and

On Mon, Apr 18, 2016 at 01:50:15PM +0200, Joerg Roedel wrote: > Hi Bjorn, > > On Fri, Apr 15, 2016 at 10:08:21AM -0500, Bjorn Helgaas wrote: > > I assume you're thinking about doing pci_enable_resources() before > > the core calls the driver's probe method? One question there is how > > we would

Re: [PATCH 0/3] v4.4: Revert "PCI: Implement pcibios_alloc_irq() and

On Mon, Apr 18, 2016 at 01:50:15PM +0200, Joerg Roedel wrote: > Hi Bjorn, > > On Fri, Apr 15, 2016 at 10:08:21AM -0500, Bjorn Helgaas wrote: > > I assume you're thinking about doing pci_enable_resources() before > > the core calls the driver's probe method? One question there is how > > we would

Re: [PATCH] Axi-usb: Add support for 64-bit addressing.

On Monday 18 April 2016 09:29:09 Rob Herring wrote: > > Right, you don't need to know the exact bus width for determining the > register/descriptor set is 32 or 64 bit addesses. I'm fine with a > property for that, but if limiting the actual connected address bits is > needed, then dma-ranges

Re: [PATCH] Axi-usb: Add support for 64-bit addressing.

On Monday 18 April 2016 09:29:09 Rob Herring wrote: > > Right, you don't need to know the exact bus width for determining the > register/descriptor set is 32 or 64 bit addesses. I'm fine with a > property for that, but if limiting the actual connected address bits is > needed, then dma-ranges

Re: [PATCH v4 1/6] perf tools: Derive trigger class from auxtrace_snapshot

On 2016/4/18 22:29, Jiri Olsa wrote: On Mon, Apr 18, 2016 at 10:20:23PM +0800, Wangnan (F) wrote: On 2016/4/18 21:45, Jiri Olsa wrote: On Mon, Apr 18, 2016 at 06:32:08AM +, Wang Nan wrote: Use 'trigger' to model operations which need to be executed when an event (a signal, for example)

Re: [PATCH v4 1/6] perf tools: Derive trigger class from auxtrace_snapshot

On 2016/4/18 22:29, Jiri Olsa wrote: On Mon, Apr 18, 2016 at 10:20:23PM +0800, Wangnan (F) wrote: On 2016/4/18 21:45, Jiri Olsa wrote: On Mon, Apr 18, 2016 at 06:32:08AM +, Wang Nan wrote: Use 'trigger' to model operations which need to be executed when an event (a signal, for example)

Re: [PATCH v5 39/50] mtd: nand: omap2: switch to mtd_ooblayout_ops

Boris, On 30/03/16 19:14, Boris Brezillon wrote: > Implementing the mtd_ooblayout_ops interface is the new way of exposing > ECC/OOB layout to MTD users. > > Signed-off-by: Boris Brezillon > --- > drivers/mtd/nand/omap2.c | 194 >

Re: [PATCH v5 2/4] Documentation: Bindings: Add STM32 DWMAC glue

On 3/22/2016 5:11 PM, Alexandre Torgue wrote: Hi guys, I will fix typo issues (s/vesrion/version and ethernet @). Concerning compatible string. For sure "snps,dwmac-3.50a" string is not used inside glue driver. I perfere to keep it for information but if you really want that I remove it I will

Re: [PATCH v5 2/4] Documentation: Bindings: Add STM32 DWMAC glue

On 3/22/2016 5:11 PM, Alexandre Torgue wrote: Hi guys, I will fix typo issues (s/vesrion/version and ethernet @). Concerning compatible string. For sure "snps,dwmac-3.50a" string is not used inside glue driver. I perfere to keep it for information but if you really want that I remove it I will

Re: [PATCH v5 39/50] mtd: nand: omap2: switch to mtd_ooblayout_ops

Boris, On 30/03/16 19:14, Boris Brezillon wrote: > Implementing the mtd_ooblayout_ops interface is the new way of exposing > ECC/OOB layout to MTD users. > > Signed-off-by: Boris Brezillon > --- > drivers/mtd/nand/omap2.c | 194 > +++ > 1 file

Re: [PATCH v2 07/13] MIPS: mm: Fix MIPS32 36b physical addressing (alchemy, netlogic)

On Mon, Apr 18, 2016 at 11:35 AM, Paul Burton wrote: > There are 2 distinct cases in which a kernel for a MIPS32 CPU > (CONFIG_CPU_MIPS32=y) may use 64 bit physical addresses > (CONFIG_PHYS_ADDR_T_64BIT=y): > > - 36 bit physical addressing as used by RMI Alchemy &

Re: [PATCH v2 07/13] MIPS: mm: Fix MIPS32 36b physical addressing (alchemy, netlogic)

On Mon, Apr 18, 2016 at 11:35 AM, Paul Burton wrote: > There are 2 distinct cases in which a kernel for a MIPS32 CPU > (CONFIG_CPU_MIPS32=y) may use 64 bit physical addresses > (CONFIG_PHYS_ADDR_T_64BIT=y): > > - 36 bit physical addressing as used by RMI Alchemy & Netlogic XLP/XLR > CPUs. >

[PATCH v3 4/5] max44000: Expose ambient sensor scaling

This patch exposes ALSTIM as illuminance_integration_time and ALSPGA as illuminance_scale. Changing ALSTIM also changes the number of bits available in the data register. This is handled inside raw value reading because: * It's very easy to shift a few bits * It allows SCALE and INT_TIME to be

[PATCH v3 4/5] max44000: Expose ambient sensor scaling

This patch exposes ALSTIM as illuminance_integration_time and ALSPGA as illuminance_scale. Changing ALSTIM also changes the number of bits available in the data register. This is handled inside raw value reading because: * It's very easy to shift a few bits * It allows SCALE and INT_TIME to be

[PATCH v3 0/5] Support for max44000 Ambient and Infrared Proximity Sensor

Changes since v2: * Drop reg_defaults from regmap_config * Use REGCACHE_RBTREE * Implement readable/writable/volatile reg with switches * Use test_bit when checking the scan mask * Add _INT_TIME info_mask in patch 4 rather than 2 * Cleaner spacing in max44000_remove Changes since v1: * Remove

[PATCH v3 0/5] Support for max44000 Ambient and Infrared Proximity Sensor

Changes since v2: * Drop reg_defaults from regmap_config * Use REGCACHE_RBTREE * Implement readable/writable/volatile reg with switches * Use test_bit when checking the scan mask * Add _INT_TIME info_mask in patch 4 rather than 2 * Cleaner spacing in max44000_remove Changes since v1: * Remove

Re: [PATCH V2] net: ethernet: mellanox: correct page conversion

On Mon, Apr 18, 2016 at 09:54:47AM +0300, Eli Cohen wrote: > Sinan, > > if we get rid of the part this code: > > if (BITS_PER_LONG == 64) { > struct page **pages; > pages = kmalloc(sizeof *pages * buf->nbufs, gfp); >

Re: [PATCH V2] net: ethernet: mellanox: correct page conversion

On Mon, Apr 18, 2016 at 09:54:47AM +0300, Eli Cohen wrote: > Sinan, > > if we get rid of the part this code: > > if (BITS_PER_LONG == 64) { > struct page **pages; > pages = kmalloc(sizeof *pages * buf->nbufs, gfp); >

[PATCH v3 3/5] max44000: Support controlling LED current output

This is exposed as an output channel with "led" as an extend_name. Other sensors also have support for controlling an external LED. It's not clear that simply exposing an undecorated output channel is the correct approach. Signed-off-by: Crestez Dan Leonard ---

[PATCH v3 3/5] max44000: Support controlling LED current output

This is exposed as an output channel with "led" as an extend_name. Other sensors also have support for controlling an external LED. It's not clear that simply exposing an undecorated output channel is the correct approach. Signed-off-by: Crestez Dan Leonard --- drivers/iio/light/max44000.c |

Re: [PATCH V2] net: ethernet: mellanox: correct page conversion

Sure, this is not the complete patch. As far as I know the problem you're facing with arm is that virt_to_page() does not provide the correct page descriptor so my suggestion will eliminate the need for it. On Mon, Apr 18, 2016 at 09:53:30AM -0400, Sinan Kaya wrote: > On 4/18/2016 2:54 AM, Eli

Re: [PATCH V2] net: ethernet: mellanox: correct page conversion

Sure, this is not the complete patch. As far as I know the problem you're facing with arm is that virt_to_page() does not provide the correct page descriptor so my suggestion will eliminate the need for it. On Mon, Apr 18, 2016 at 09:53:30AM -0400, Sinan Kaya wrote: > On 4/18/2016 2:54 AM, Eli

[PATCH v3 5/5] max44000: Initial triggered buffer support

Signed-off-by: Crestez Dan Leonard --- drivers/iio/light/max44000.c | 62 1 file changed, 62 insertions(+) diff --git a/drivers/iio/light/max44000.c b/drivers/iio/light/max44000.c index c58bb78..b83d47d 100644 ---

[PATCH v3 5/5] max44000: Initial triggered buffer support

Signed-off-by: Crestez Dan Leonard --- drivers/iio/light/max44000.c | 62 1 file changed, 62 insertions(+) diff --git a/drivers/iio/light/max44000.c b/drivers/iio/light/max44000.c index c58bb78..b83d47d 100644 --- a/drivers/iio/light/max44000.c +++

[PATCH v3 1/5] max44000: Initial support

This just adds support for reporting illuminance with default settings. Important default registers are written on probe because the device otherwise lacks a reset function. Signed-off-by: Crestez Dan Leonard --- drivers/iio/light/Kconfig| 11 ++

[PATCH v3 1/5] max44000: Initial support

This just adds support for reporting illuminance with default settings. Important default registers are written on probe because the device otherwise lacks a reset function. Signed-off-by: Crestez Dan Leonard --- drivers/iio/light/Kconfig| 11 ++ drivers/iio/light/Makefile | 1 +

[PATCH v3 2/5] max44000: Initial support for proximity reading

The proximity sensor relies on sending pulses to an external IR led and it is disabled by default on powerup. The driver will enable it with a default power setting. Signed-off-by: Crestez Dan Leonard --- drivers/iio/light/max44000.c | 45

[PATCH v3 2/5] max44000: Initial support for proximity reading

The proximity sensor relies on sending pulses to an external IR led and it is disabled by default on powerup. The driver will enable it with a default power setting. Signed-off-by: Crestez Dan Leonard --- drivers/iio/light/max44000.c | 45 ++-- 1 file

<    4   5   6   7   8   9   10   11   12   13   >