Re: [PATCH] iommu/vt-d: reduce extra first level entry in iommu->domains

On Wed, May 25, 2016 at 11:17:49AM +0100, Robin Murphy wrote: >On 25/05/16 00:06, Wei Yang wrote: >>Hi, Joerg >> >>Not sure whether you think this calculation is correct. >> >>If I missed something for this " + 1" in your formula, I am glad to hear your >>explanation. So that I could learn

Re: [PATCH] iommu/vt-d: reduce extra first level entry in iommu->domains

On Wed, May 25, 2016 at 11:17:49AM +0100, Robin Murphy wrote: >On 25/05/16 00:06, Wei Yang wrote: >>Hi, Joerg >> >>Not sure whether you think this calculation is correct. >> >>If I missed something for this " + 1" in your formula, I am glad to hear your >>explanation. So that I could learn

Re: [PATCH 00/10]block-throttle: add low/high limit

Sorry for the late reply. On Wed, May 18, 2016 at 03:29:55PM -0400, Vivek Goyal wrote: > On Fri, May 13, 2016 at 03:59:50PM -0700, Shaohua Li wrote: > > On Fri, May 13, 2016 at 03:12:45PM -0400, Vivek Goyal wrote: > > > On Tue, May 10, 2016 at 05:16:30PM -0700, Shaohua Li wrote: > > > > Hi, > > >

Re: [PATCH 00/10]block-throttle: add low/high limit

Sorry for the late reply. On Wed, May 18, 2016 at 03:29:55PM -0400, Vivek Goyal wrote: > On Fri, May 13, 2016 at 03:59:50PM -0700, Shaohua Li wrote: > > On Fri, May 13, 2016 at 03:12:45PM -0400, Vivek Goyal wrote: > > > On Tue, May 10, 2016 at 05:16:30PM -0700, Shaohua Li wrote: > > > > Hi, > > >

Re: Builtin microcode does nothing..

On Wed, May 25, 2016 at 11:29:03PM +0200, Gabriel C wrote: > initrd + buitl-in intel ucode won't boot here. It hangs on grub 'Loading > initrd image'.. That's with my patches? Can I have the .config please so that I can reproduce? With initrd you mean, you supply an initrd with the micrcode

Re: Builtin microcode does nothing..

On Wed, May 25, 2016 at 11:29:03PM +0200, Gabriel C wrote: > initrd + buitl-in intel ucode won't boot here. It hangs on grub 'Loading > initrd image'.. That's with my patches? Can I have the .config please so that I can reproduce? With initrd you mean, you supply an initrd with the micrcode

[PATCH 09/10] perf evlist: Choose correct reading direction according to evlist->backward

From: Wang Nan Now we have evlist->backward to indicate the mmap direction. Make perf_evlist__mmap_read() choose right direction automatically. Signed-off-by: Wang Nan Cc: He Kuang Cc: Jiri Olsa Cc: Masami

[PATCH 08/10] perf evlist: Check 'base' pointer before checking refcnt when put a mmap

From: Wang Nan evlist->mmap[i]->refcnt could be 0 if an evlist has no evsel or if all evsels don't match the evlist during mmap. For example, when all evsels are overwritable but the evlist itself is normal. To avoid crashing, perf should check 'base' pointer before checking

[PATCH 09/10] perf evlist: Choose correct reading direction according to evlist->backward

From: Wang Nan Now we have evlist->backward to indicate the mmap direction. Make perf_evlist__mmap_read() choose right direction automatically. Signed-off-by: Wang Nan Cc: He Kuang Cc: Jiri Olsa Cc: Masami Hiramatsu Cc: Namhyung Kim Cc: Zefan Li Cc: pi3or...@163.com Link:

[PATCH 08/10] perf evlist: Check 'base' pointer before checking refcnt when put a mmap

From: Wang Nan evlist->mmap[i]->refcnt could be 0 if an evlist has no evsel or if all evsels don't match the evlist during mmap. For example, when all evsels are overwritable but the evlist itself is normal. To avoid crashing, perf should check 'base' pointer before checking refcnt, and raise

[PATCH 01/10] perf symbols: Check kptr_restrict for root

From: Wang Nan If kptr_restrict is set to 2, even root is not allowed to see pointers. This patch checks kptr_restrict even if euid == 0. For root, report error if kptr_restrict is 2. Signed-off-by: Wang Nan Tested-by: Arnaldo Carvalho de Melo

[PATCH 01/10] perf symbols: Check kptr_restrict for root

From: Wang Nan If kptr_restrict is set to 2, even root is not allowed to see pointers. This patch checks kptr_restrict even if euid == 0. For root, report error if kptr_restrict is 2. Signed-off-by: Wang Nan Tested-by: Arnaldo Carvalho de Melo Cc: Zefan Li Cc: pi3or...@163.com Link:

Re: [PATCH v9] fs: clear file privilege bits when mmap writing

On Thu, Jan 14, 2016 at 9:55 PM, Konstantin Khlebnikov wrote: > On Fri, Jan 15, 2016 at 12:22 AM, Kees Cook wrote: >> Normally, when a user can modify a file that has setuid or setgid bits, >> those bits are cleared when they are not the file owner or a

Re: [PATCH v9] fs: clear file privilege bits when mmap writing

On Thu, Jan 14, 2016 at 9:55 PM, Konstantin Khlebnikov wrote: > On Fri, Jan 15, 2016 at 12:22 AM, Kees Cook wrote: >> Normally, when a user can modify a file that has setuid or setgid bits, >> those bits are cleared when they are not the file owner or a member >> of the group. This is enforced

[PATCH 02/10] perf record: Fix crash when kptr is restricted

From: Wang Nan Before this patch, a simple 'perf record' could fail if kptr_restrict is set to 1 (for normal user) or 2 (for root): # perf record ls WARNING: Kernel address maps (/proc/{kallsyms,modules}) are restricted, check /proc/sys/kernel/kptr_restrict.

[PATCH 02/10] perf record: Fix crash when kptr is restricted

From: Wang Nan Before this patch, a simple 'perf record' could fail if kptr_restrict is set to 1 (for normal user) or 2 (for root): # perf record ls WARNING: Kernel address maps (/proc/{kallsyms,modules}) are restricted, check /proc/sys/kernel/kptr_restrict. Samples in kernel functions

[GIT PULL 00/10] perf/core improvements and fixes

/git/acme/linux.git tags/perf-core-for-mingo-20160525 for you to fetch changes up to 83e1e314baf9a1424bf2f50953ed7d50612763c4: tools: Pass arg to fdarray__filter's call back function (2016-05-25 17:27:25 -0300) perf/core

[PATCH 10/10] tools: Pass arg to fdarray__filter's call back function

From: Wang Nan Before this patch there's no way to pass arguments to fdarray__filter's call back function. This improvement will be used by 'perf record' to support unmapping ring buffer for both main evlist and overwrite evlist. Without this patch there's no way to track

[PATCH 05/10] perf tools: Per event max-stack settings

From: Arnaldo Carvalho de Melo The tooling counterpart, now it is possible to do: # perf record -e sched:sched_switch/max-stack=10/ -e cycles/call-graph=dwarf,max-stack=4/ -e cpu-cycles/call-graph=dwarf,max-stack=1024/ usleep 1 [ perf record: Woken up 1 times to write

[GIT PULL 00/10] perf/core improvements and fixes

/git/acme/linux.git tags/perf-core-for-mingo-20160525 for you to fetch changes up to 83e1e314baf9a1424bf2f50953ed7d50612763c4: tools: Pass arg to fdarray__filter's call back function (2016-05-25 17:27:25 -0300) perf/core

[PATCH 10/10] tools: Pass arg to fdarray__filter's call back function

From: Wang Nan Before this patch there's no way to pass arguments to fdarray__filter's call back function. This improvement will be used by 'perf record' to support unmapping ring buffer for both main evlist and overwrite evlist. Without this patch there's no way to track overwrite evlist from

[PATCH 05/10] perf tools: Per event max-stack settings

From: Arnaldo Carvalho de Melo The tooling counterpart, now it is possible to do: # perf record -e sched:sched_switch/max-stack=10/ -e cycles/call-graph=dwarf,max-stack=4/ -e cpu-cycles/call-graph=dwarf,max-stack=1024/ usleep 1 [ perf record: Woken up 1 times to write data ] [ perf

[PATCH 04/10] perf core: Per event callchain limit

From: Arnaldo Carvalho de Melo Additionally to being able to control the system wide maximum depth via /proc/sys/kernel/perf_event_max_stack, now we are able to ask for different depths per event, using perf_event_attr.sample_max_stack for that. This uses an u16 hole at the end

[PATCH 06/10] perf record: Robustify perf_event__synth_time_conv()

From: Wang Nan It is possible that all events in an evlist are overwritable. perf_event__synth_time_conv() should not crash in this case. record__pick_pc() is used to check avaliability. Signed-off-by: Wang Nan Cc: Jiri Olsa Cc:

[PATCH 04/10] perf core: Per event callchain limit

From: Arnaldo Carvalho de Melo Additionally to being able to control the system wide maximum depth via /proc/sys/kernel/perf_event_max_stack, now we are able to ask for different depths per event, using perf_event_attr.sample_max_stack for that. This uses an u16 hole at the end of

[PATCH 06/10] perf record: Robustify perf_event__synth_time_conv()

From: Wang Nan It is possible that all events in an evlist are overwritable. perf_event__synth_time_conv() should not crash in this case. record__pick_pc() is used to check avaliability. Signed-off-by: Wang Nan Cc: Jiri Olsa Cc: Masami Hiramatsu Cc: Namhyung Kim Cc: Zefan Li Cc:

[PATCH 03/10] perf thread: Adopt get_main_thread from db-export.c

From: Andi Kleen Move the get_main_thread function from db-export.c to thread.c so that it can be used elsewhere. Signed-off-by: Andi Kleen Cc: Jiri Olsa Link:

[PATCH 03/10] perf thread: Adopt get_main_thread from db-export.c

From: Andi Kleen Move the get_main_thread function from db-export.c to thread.c so that it can be used elsewhere. Signed-off-by: Andi Kleen Cc: Jiri Olsa Link: http://lkml.kernel.org/r/1464051145-19968-2-git-send-email-a...@firstfloor.org [ Removed leftover bits from db-export.h ]

[PATCH 07/10] perf evlist: Don't poll and mmap overwritable events

From: Wang Nan There's no need to receive events from overwritable ring buffer. Instead, perf should make them run in background until some external event of interest takes place. This patch makes ignores normal events from overwrite evlists. Overwritable events must be

[PATCH 07/10] perf evlist: Don't poll and mmap overwritable events

From: Wang Nan There's no need to receive events from overwritable ring buffer. Instead, perf should make them run in background until some external event of interest takes place. This patch makes ignores normal events from overwrite evlists. Overwritable events must be mapped readonly and

Re: [GIT PULL] y2038 changes for vfs

On Wed, May 25, 2016 at 06:03:19PM +0200, Arnd Bergmann wrote: > On Tuesday, May 24, 2016 3:23:39 PM CEST Linus Torvalds wrote: > > On Tue, May 24, 2016 at 1:11 PM, Arnd Bergmann wrote: > > > The following changes since commit > > > bf16200689118d19de1b8d2a3c314fc21f5dc7bb: > > >

Re: [GIT PULL] y2038 changes for vfs

On Wed, May 25, 2016 at 06:03:19PM +0200, Arnd Bergmann wrote: > On Tuesday, May 24, 2016 3:23:39 PM CEST Linus Torvalds wrote: > > On Tue, May 24, 2016 at 1:11 PM, Arnd Bergmann wrote: > > > The following changes since commit > > > bf16200689118d19de1b8d2a3c314fc21f5dc7bb: > > > > > > Linux

Re: Builtin microcode does nothing..

On 25.05.2016 11:31, Borislav Petkov wrote: On Sat, May 21, 2016 at 09:51:18AM +0200, Borislav Petkov wrote: I'll ping you once I'm done testing here. Ok, I've just uploaded a branch, it passes testing here. http://git.kernel.org/cgit/linux/kernel/git/bp/bp.git, branch tip-microcode I

Re: Builtin microcode does nothing..

On 25.05.2016 11:31, Borislav Petkov wrote: On Sat, May 21, 2016 at 09:51:18AM +0200, Borislav Petkov wrote: I'll ping you once I'm done testing here. Ok, I've just uploaded a branch, it passes testing here. http://git.kernel.org/cgit/linux/kernel/git/bp/bp.git, branch tip-microcode I

Re: [PATCH 01/23] all: syscall wrappers: add documentation

From: Arnd Bergmann Date: Wed, 25 May 2016 23:01:06 +0200 > On Wednesday, May 25, 2016 1:50:39 PM CEST David Miller wrote: >> From: Arnd Bergmann >> Date: Wed, 25 May 2016 22:47:33 +0200 >> >> > If we use the normal calling conventions, we could remove these

Re: [PATCH 01/23] all: syscall wrappers: add documentation

From: Arnd Bergmann Date: Wed, 25 May 2016 23:01:06 +0200 > On Wednesday, May 25, 2016 1:50:39 PM CEST David Miller wrote: >> From: Arnd Bergmann >> Date: Wed, 25 May 2016 22:47:33 +0200 >> >> > If we use the normal calling conventions, we could remove these overrides >> > along with the

[PATCH] mm: use early_pfn_to_nid in register_page_bootmem_info_node

register_page_bootmem_info_node() is invoked in mem_init(), so it will be called before page_alloc_init_late() if CONFIG_DEFERRED_STRUCT_PAGE_INIT is enabled. But, pfn_to_nid() depends on memmap which won't be fully setup until page_alloc_init_late() is done, so replace pfn_to_nid() by

[PATCH] mm: use early_pfn_to_nid in register_page_bootmem_info_node

register_page_bootmem_info_node() is invoked in mem_init(), so it will be called before page_alloc_init_late() if CONFIG_DEFERRED_STRUCT_PAGE_INIT is enabled. But, pfn_to_nid() depends on memmap which won't be fully setup until page_alloc_init_late() is done, so replace pfn_to_nid() by

[RFC/PATCH 1/2] doc: bindings: Add bindings documentation for mtd otp nvmem

This commit adds documentation describing the bindings for exposing mtd flash otp regions as nvmem providers via devicetree. Signed-off-by: Moritz Fischer --- .../devicetree/bindings/mtd/otp-nvmem.txt | 62 ++ 1 file changed, 62

[RFC/PATCH 1/2] doc: bindings: Add bindings documentation for mtd otp nvmem

This commit adds documentation describing the bindings for exposing mtd flash otp regions as nvmem providers via devicetree. Signed-off-by: Moritz Fischer --- .../devicetree/bindings/mtd/otp-nvmem.txt | 62 ++ 1 file changed, 62 insertions(+) create mode 100644

[RFC/PATCH 2/2] mtd: otp: Expose mtd flash otp regions as nvmem providers

This commit introduces support for exposing otp regions in mtd flash devices as nvmem providers, allowing them to provide information such as serial numbers, calibration data or product ids. Cc: David Woodhouse Cc: Brian Norris Cc: Boris

[RFC/PATCH 2/2] mtd: otp: Expose mtd flash otp regions as nvmem providers

This commit introduces support for exposing otp regions in mtd flash devices as nvmem providers, allowing them to provide information such as serial numbers, calibration data or product ids. Cc: David Woodhouse Cc: Brian Norris Cc: Boris Brezillon Signed-off-by: Moritz Fischer ---

[RFC/PATCH 0/2] Adding support to expose mtd flash otp regions via nvmem

Hi all, attached series allows exporting mtd flash otp regions via nvmem. This is my first stab and still needs cleanup, but I wanted to get some general feedback on whether this can conceptually work. In an earlier conversation with Boris (in Cc) he suggested (I think), something similar to

[RFC/PATCH 0/2] Adding support to expose mtd flash otp regions via nvmem

Hi all, attached series allows exporting mtd flash otp regions via nvmem. This is my first stab and still needs cleanup, but I wanted to get some general feedback on whether this can conceptually work. In an earlier conversation with Boris (in Cc) he suggested (I think), something similar to

Re: [PATCHv4] support for AD5820 camera auto-focus coil

Hi Pavel, Thanks for your continued work on this! :-) Some quite minor comments below. I think we're good then. On Tue, May 24, 2016 at 11:17:46AM +0200, Pavel Machek wrote: > This adds support for AD5820 autofocus coil, found for example in > Nokia N900 smartphone. > > Signed-off-by: Pavel

Re: [PATCHv4] support for AD5820 camera auto-focus coil

Hi Pavel, Thanks for your continued work on this! :-) Some quite minor comments below. I think we're good then. On Tue, May 24, 2016 at 11:17:46AM +0200, Pavel Machek wrote: > This adds support for AD5820 autofocus coil, found for example in > Nokia N900 smartphone. > > Signed-off-by: Pavel

Re: [PATCH 2/5] asus-wmi: Create quirk for airplane_mode LED

On Wed, May 25, 2016 at 09:13:23AM +0200, Corentin Chary wrote: > On Mon, Feb 8, 2016 at 6:05 PM, João Paulo Rechi Vita > wrote: > > Some Asus laptops that have an "airplane mode" indicator LED, also have > > the WMI WLAN user bit set, and the following bits in their DSDT: > >

Re: [PATCH 2/5] asus-wmi: Create quirk for airplane_mode LED

On Wed, May 25, 2016 at 09:13:23AM +0200, Corentin Chary wrote: > On Mon, Feb 8, 2016 at 6:05 PM, João Paulo Rechi Vita > wrote: > > Some Asus laptops that have an "airplane mode" indicator LED, also have > > the WMI WLAN user bit set, and the following bits in their DSDT: > > > > Scope (_SB) >

Re: [PATCHv8 00/32] THP-enabled tmpfs/shmem using compound pages

On Wed, May 25, 2016 at 05:11:03PM -0400, neha agarwal wrote: > On Wed, May 25, 2016 at 4:03 PM, Kirill A. Shutemov > wrote: > > > On Wed, May 25, 2016 at 03:11:55PM -0400, neha agarwal wrote: > > > Hi All, > > > > > > I have been testing Hugh's and Kirill's huge tmpfs

Re: [PATCHv8 00/32] THP-enabled tmpfs/shmem using compound pages

On Wed, May 25, 2016 at 05:11:03PM -0400, neha agarwal wrote: > On Wed, May 25, 2016 at 4:03 PM, Kirill A. Shutemov > wrote: > > > On Wed, May 25, 2016 at 03:11:55PM -0400, neha agarwal wrote: > > > Hi All, > > > > > > I have been testing Hugh's and Kirill's huge tmpfs patch sets with > > >

Re: [PATCH] workqueue: Fix an object aliasing bug with `work_data_bits'

On Wed, 25 May 2016, Tejun Heo wrote: > > Fix an aliasing issue causing a MIPS port build error: > > > > In file included from include/linux/srcu.h:34:0, > > from include/linux/notifier.h:15, > > from ./arch/mips/include/asm/uprobes.h:9, > >

Re: [PATCH] workqueue: Fix an object aliasing bug with `work_data_bits'

On Wed, 25 May 2016, Tejun Heo wrote: > > Fix an aliasing issue causing a MIPS port build error: > > > > In file included from include/linux/srcu.h:34:0, > > from include/linux/notifier.h:15, > > from ./arch/mips/include/asm/uprobes.h:9, > >

Re: [PATCH v4] dell-rbtn: Ignore ACPI notifications if device is suspended

On Wed, May 25, 2016 at 10:47:03PM +0200, Gabriele Mazzotta wrote: > On 25/05/2016 22:36, Pali Rohár wrote: > > On Wednesday 25 May 2016 22:28:47 Darren Hart wrote: > >> On Tue, May 24, 2016 at 10:53:08PM +0200, Gabriele Mazzotta wrote: > >>> Some BIOSes unconditionally send an ACPI notification

Re: [PATCH v4] dell-rbtn: Ignore ACPI notifications if device is suspended

On Wed, May 25, 2016 at 10:47:03PM +0200, Gabriele Mazzotta wrote: > On 25/05/2016 22:36, Pali Rohár wrote: > > On Wednesday 25 May 2016 22:28:47 Darren Hart wrote: > >> On Tue, May 24, 2016 at 10:53:08PM +0200, Gabriele Mazzotta wrote: > >>> Some BIOSes unconditionally send an ACPI notification

Re: [Patch v5 5/8] firmware: qcom: scm: Convert to streaming DMA APIS

On 25 May 2016 at 15:50, Kevin Hilman wrote: > Andy Gross writes: > >> On Mon, May 23, 2016 at 04:02:06PM -0500, Andy Gross wrote: >>> On 23 May 2016 at 14:26, Kevin Hilman wrote: >>> > Hi Andy, >>> > >>> > On Thu, May 12, 2016 at

Re: [Patch v5 5/8] firmware: qcom: scm: Convert to streaming DMA APIS

On 25 May 2016 at 15:50, Kevin Hilman wrote: > Andy Gross writes: > >> On Mon, May 23, 2016 at 04:02:06PM -0500, Andy Gross wrote: >>> On 23 May 2016 at 14:26, Kevin Hilman wrote: >>> > Hi Andy, >>> > >>> > On Thu, May 12, 2016 at 8:46 PM, Andy Gross wrote: >>> >> This patch converts the

Re: [PATCH] brcmfmac: fix setting AP channel with new firmwares

On 24-05-16 11:09, Rafał Miłecki wrote: > Firmware for new chipsets is based on a new major version of code > internally maintained at Broadcom. E.g. brcmfmac4366b-pcie.bin (used for > BCM4366B1) is based on 10.10.69.3309 while brcmfmac43602-pcie.ap.bin was > based on 7.35.177.56. > > Currently

Re: [PATCH] brcmfmac: fix setting AP channel with new firmwares

On 24-05-16 11:09, Rafał Miłecki wrote: > Firmware for new chipsets is based on a new major version of code > internally maintained at Broadcom. E.g. brcmfmac4366b-pcie.bin (used for > BCM4366B1) is based on 10.10.69.3309 while brcmfmac43602-pcie.ap.bin was > based on 7.35.177.56. > > Currently

Re: [PATCHv8 00/32] THP-enabled tmpfs/shmem using compound pages

On Wed, May 25, 2016 at 03:11:55PM -0400, neha agarwal wrote: > Hi All, > > I have been testing Hugh's and Kirill's huge tmpfs patch sets with > Cassandra (NoSQL database). I am seeing significant performance gap between > these two implementations (~30%). Hugh's implementation performs better >

Re: [PATCHv8 00/32] THP-enabled tmpfs/shmem using compound pages

On Wed, May 25, 2016 at 03:11:55PM -0400, neha agarwal wrote: > Hi All, > > I have been testing Hugh's and Kirill's huge tmpfs patch sets with > Cassandra (NoSQL database). I am seeing significant performance gap between > these two implementations (~30%). Hugh's implementation performs better >

Re: [PATCH V2] brcmfmac: print error if p2p_ifadd firmware command fails

On 24-05-16 23:05, Rafał Miłecki wrote: > This is helpful for debugging, without this all I was getting from "iw" > command on device with BCM43602 was: >> command failed: Too many open files in system (-23) > > Signed-off-by: Rafał Miłecki > --- > V2: s/in/if/ in commit

Re: [PATCH V2] brcmfmac: print error if p2p_ifadd firmware command fails

On 24-05-16 23:05, Rafał Miłecki wrote: > This is helpful for debugging, without this all I was getting from "iw" > command on device with BCM43602 was: >> command failed: Too many open files in system (-23) > > Signed-off-by: Rafał Miłecki > --- > V2: s/in/if/ in commit message > --- >

Re: [PATCH v6] platform:x86: Add PMC Driver for Intel Core SoC

On Wed, May 25, 2016 at 11:37:21PM +0300, Andy Shevchenko wrote: > On Wed, May 25, 2016 at 11:13 PM, Darren Hart wrote: > > On Wed, May 25, 2016 at 11:14:52PM +0530, Rajneesh Bhardwaj wrote: > > > Hi Rajneesh, > > > > Unfortunately during my build test, this introduced a

Re: [PATCH v6] platform:x86: Add PMC Driver for Intel Core SoC

On Wed, May 25, 2016 at 11:37:21PM +0300, Andy Shevchenko wrote: > On Wed, May 25, 2016 at 11:13 PM, Darren Hart wrote: > > On Wed, May 25, 2016 at 11:14:52PM +0530, Rajneesh Bhardwaj wrote: > > > Hi Rajneesh, > > > > Unfortunately during my build test, this introduced a new warning to the > >

Re: [PATCH 01/23] all: syscall wrappers: add documentation

On Wednesday, May 25, 2016 1:50:39 PM CEST David Miller wrote: > From: Arnd Bergmann > Date: Wed, 25 May 2016 22:47:33 +0200 > > > If we use the normal calling conventions, we could remove these overrides > > along with the respective special-case handling in glibc. None of them >

Re: [PATCH 01/23] all: syscall wrappers: add documentation

On Wednesday, May 25, 2016 1:50:39 PM CEST David Miller wrote: > From: Arnd Bergmann > Date: Wed, 25 May 2016 22:47:33 +0200 > > > If we use the normal calling conventions, we could remove these overrides > > along with the respective special-case handling in glibc. None of them > > look

Re: [PATCH] efi: fix for_each_efi_memory_desc_in_map() for empty memmaps

On Wed, 2016-05-25 at 21:48 +0100, Matt Fleming wrote: > (Cc'ing Mark, the original author) > > On Wed, 25 May, at 04:36:55PM, Vitaly Kuznetsov wrote: > > > > Commit 78ce248faa3c ("efi: Iterate over efi.memmap in > > for_each_efi_memory_desc()") introduced a regression for systems booted > >

Re: [PATCH v6 00/20] kthread: Use kthread worker API more widely

On Wed, May 11, 2016 at 6:52 AM, Petr Mladek wrote: > Tejun, may I add your ack for some of the patches, please? > Or do you want to wait for the resend? When you repost, I'll explicitly ack the patches. Thanks! -- tejun

Re: [PATCH] efi: fix for_each_efi_memory_desc_in_map() for empty memmaps

On Wed, 2016-05-25 at 21:48 +0100, Matt Fleming wrote: > (Cc'ing Mark, the original author) > > On Wed, 25 May, at 04:36:55PM, Vitaly Kuznetsov wrote: > > > > Commit 78ce248faa3c ("efi: Iterate over efi.memmap in > > for_each_efi_memory_desc()") introduced a regression for systems booted > >

Re: [PATCH v6 00/20] kthread: Use kthread worker API more widely

On Wed, May 11, 2016 at 6:52 AM, Petr Mladek wrote: > Tejun, may I add your ack for some of the patches, please? > Or do you want to wait for the resend? When you repost, I'll explicitly ack the patches. Thanks! -- tejun

Re: [PATCH] workqueue: Fix an object aliasing bug with `work_data_bits'

On Tue, May 17, 2016 at 12:04:33PM +0100, Maciej W. Rozycki wrote: > Fix an aliasing issue causing a MIPS port build error: > > In file included from include/linux/srcu.h:34:0, > from include/linux/notifier.h:15, > from ./arch/mips/include/asm/uprobes.h:9, >

Re: [PATCH] workqueue: Fix an object aliasing bug with `work_data_bits'

On Tue, May 17, 2016 at 12:04:33PM +0100, Maciej W. Rozycki wrote: > Fix an aliasing issue causing a MIPS port build error: > > In file included from include/linux/srcu.h:34:0, > from include/linux/notifier.h:15, > from ./arch/mips/include/asm/uprobes.h:9, >

Re: [PATCH v6] platform:x86: Add PMC Driver for Intel Core SoC

On Wed, May 25, 2016 at 11:13 PM, Darren Hart wrote: > On Wed, May 25, 2016 at 11:14:52PM +0530, Rajneesh Bhardwaj wrote: > Hi Rajneesh, > > Unfortunately during my build test, this introduced a new warning to the > build: > > drivers/platform/x86/intel_pmc_core.c:201:19:

Re: [PATCH v6] platform:x86: Add PMC Driver for Intel Core SoC

On Wed, May 25, 2016 at 11:13 PM, Darren Hart wrote: > On Wed, May 25, 2016 at 11:14:52PM +0530, Rajneesh Bhardwaj wrote: > Hi Rajneesh, > > Unfortunately during my build test, this introduced a new warning to the > build: > > drivers/platform/x86/intel_pmc_core.c:201:19: warning:

[GIT PULL] Additional ACPI update for v4.7-rc1

Hi Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ acpi-4.7-rc1-more to receive an additional ACPI update for v4.7-rc1 with top-most commit 0cc4b48149ff6948dd82a039ad55cdbec49107f7 Merge branch 'acpi-battery' on top of commit

Re: [Patch v5 5/8] firmware: qcom: scm: Convert to streaming DMA APIS

Andy Gross writes: > On Mon, May 23, 2016 at 04:02:06PM -0500, Andy Gross wrote: >> On 23 May 2016 at 14:26, Kevin Hilman wrote: >> > Hi Andy, >> > >> > On Thu, May 12, 2016 at 8:46 PM, Andy Gross wrote: >> >> This patch

[GIT PULL] Additional ACPI update for v4.7-rc1

Hi Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ acpi-4.7-rc1-more to receive an additional ACPI update for v4.7-rc1 with top-most commit 0cc4b48149ff6948dd82a039ad55cdbec49107f7 Merge branch 'acpi-battery' on top of commit

Re: [Patch v5 5/8] firmware: qcom: scm: Convert to streaming DMA APIS

Andy Gross writes: > On Mon, May 23, 2016 at 04:02:06PM -0500, Andy Gross wrote: >> On 23 May 2016 at 14:26, Kevin Hilman wrote: >> > Hi Andy, >> > >> > On Thu, May 12, 2016 at 8:46 PM, Andy Gross wrote: >> >> This patch converts the Qualcomm SCM driver to use the streaming DMA APIs >> >> for

Re: [PATCH v7 0/5] Make cpuid <-> nodeid mapping persistent

On Mon, May 23, 2016 at 03:02:14PM +0800, Zhu Guihua wrote: > We tried to do that. You can see our patch at > http://www.gossamer-threads.com/lists/linux/kernel/2116748 > > But maintainer thought, we should establish persistent cpuid<->nodeid > relationship, > there is no need to change the map.

Re: [PATCH 01/23] all: syscall wrappers: add documentation

From: Arnd Bergmann Date: Wed, 25 May 2016 22:47:33 +0200 > If we use the normal calling conventions, we could remove these overrides > along with the respective special-case handling in glibc. None of them > look particularly performance-sensitive, but I could be wrong there.

Re: [PATCH v7 0/5] Make cpuid <-> nodeid mapping persistent

On Mon, May 23, 2016 at 03:02:14PM +0800, Zhu Guihua wrote: > We tried to do that. You can see our patch at > http://www.gossamer-threads.com/lists/linux/kernel/2116748 > > But maintainer thought, we should establish persistent cpuid<->nodeid > relationship, > there is no need to change the map.

Re: [PATCH 01/23] all: syscall wrappers: add documentation

From: Arnd Bergmann Date: Wed, 25 May 2016 22:47:33 +0200 > If we use the normal calling conventions, we could remove these overrides > along with the respective special-case handling in glibc. None of them > look particularly performance-sensitive, but I could be wrong there. You could set the

[GIT PULL] More power management updates for v4.7-rc1

Hi Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm-4.7-rc1-more to receive more power management updates for v4.7-rc1 with top-most commit 4c2628cd7580bc4f4a4994925cf366185ecc37a5 Merge branches 'pm-cpufreq', 'pm-cpuidle' and 'pm-core' on top

[GIT PULL] More power management updates for v4.7-rc1

Hi Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm-4.7-rc1-more to receive more power management updates for v4.7-rc1 with top-most commit 4c2628cd7580bc4f4a4994925cf366185ecc37a5 Merge branches 'pm-cpufreq', 'pm-cpuidle' and 'pm-core' on top

Re: [PATCH 01/23] all: syscall wrappers: add documentation

On Wednesday, May 25, 2016 1:21:45 PM CEST David Miller wrote: > From: Yury Norov > Date: Wed, 25 May 2016 23:03:27 +0300 > > > On Wed, May 25, 2016 at 12:30:17PM -0700, David Miller wrote: > >> From: Yury Norov > >> Date: Tue, 24 May 2016

Re: [PATCH 01/23] all: syscall wrappers: add documentation

On Wednesday, May 25, 2016 1:21:45 PM CEST David Miller wrote: > From: Yury Norov > Date: Wed, 25 May 2016 23:03:27 +0300 > > > On Wed, May 25, 2016 at 12:30:17PM -0700, David Miller wrote: > >> From: Yury Norov > >> Date: Tue, 24 May 2016 03:04:30 +0300 > >> > >> > +To clear that top halves,

Re: [PATCH] efi: fix for_each_efi_memory_desc_in_map() for empty memmaps

(Cc'ing Mark, the original author) On Wed, 25 May, at 04:36:55PM, Vitaly Kuznetsov wrote: > Commit 78ce248faa3c ("efi: Iterate over efi.memmap in > for_each_efi_memory_desc()") introduced a regression for systems booted > with 'noefi' kernel option. In particular, I observe early kernel hang in >

Re: [PATCH] efi: fix for_each_efi_memory_desc_in_map() for empty memmaps

(Cc'ing Mark, the original author) On Wed, 25 May, at 04:36:55PM, Vitaly Kuznetsov wrote: > Commit 78ce248faa3c ("efi: Iterate over efi.memmap in > for_each_efi_memory_desc()") introduced a regression for systems booted > with 'noefi' kernel option. In particular, I observe early kernel hang in >

Re: [PATCH v4] dell-rbtn: Ignore ACPI notifications if device is suspended

On 25/05/2016 22:36, Pali Rohár wrote: > On Wednesday 25 May 2016 22:28:47 Darren Hart wrote: >> On Tue, May 24, 2016 at 10:53:08PM +0200, Gabriele Mazzotta wrote: >>> Some BIOSes unconditionally send an ACPI notification to RBTN when >>> the system is resuming from suspend. This makes dell-rbtn

Re: [PATCH v4] dell-rbtn: Ignore ACPI notifications if device is suspended

On 25/05/2016 22:36, Pali Rohár wrote: > On Wednesday 25 May 2016 22:28:47 Darren Hart wrote: >> On Tue, May 24, 2016 at 10:53:08PM +0200, Gabriele Mazzotta wrote: >>> Some BIOSes unconditionally send an ACPI notification to RBTN when >>> the system is resuming from suspend. This makes dell-rbtn

Re: [PATCH] PCI/ASPM: fix reverse ASPM L0s assignment of upstream and downstream

On 5/25/2016 2:33 PM, Bjorn Helgaas wrote: > It looks like the code enforces this by clearing bits in > link->aspm_capable (effectively pretending L0s or L1 are unsupported) > if the latency is too high. Yes, this is what I was referring to. I think what Linux does is the right thing. -- Sinan

Re: [PATCH] PCI/ASPM: fix reverse ASPM L0s assignment of upstream and downstream

On 5/25/2016 2:33 PM, Bjorn Helgaas wrote: > It looks like the code enforces this by clearing bits in > link->aspm_capable (effectively pretending L0s or L1 are unsupported) > if the latency is too high. Yes, this is what I was referring to. I think what Linux does is the right thing. -- Sinan

[PATCH] remoteproc: Fix potential race condition in rproc_add

rproc_add adds the newly created remoteproc to a list for use by rproc_get_by_phandle and then does some additional processing to finish adding the remoteproc. This leaves a small window of time in which the rproc is available in the list but not yet fully initialized, so if another driver comes

[PATCH] remoteproc: Fix potential race condition in rproc_add

rproc_add adds the newly created remoteproc to a list for use by rproc_get_by_phandle and then does some additional processing to finish adding the remoteproc. This leaves a small window of time in which the rproc is available in the list but not yet fully initialized, so if another driver comes

Re: [PATCH v4] dell-rbtn: Ignore ACPI notifications if device is suspended

On Wednesday 25 May 2016 22:28:47 Darren Hart wrote: > On Tue, May 24, 2016 at 10:53:08PM +0200, Gabriele Mazzotta wrote: > > Some BIOSes unconditionally send an ACPI notification to RBTN when > > the system is resuming from suspend. This makes dell-rbtn send an > > input event to userspace as if

Re: [PATCH v4] dell-rbtn: Ignore ACPI notifications if device is suspended

On Wednesday 25 May 2016 22:28:47 Darren Hart wrote: > On Tue, May 24, 2016 at 10:53:08PM +0200, Gabriele Mazzotta wrote: > > Some BIOSes unconditionally send an ACPI notification to RBTN when > > the system is resuming from suspend. This makes dell-rbtn send an > > input event to userspace as if

Re: [PATCH v4] dell-rbtn: Ignore ACPI notifications if device is suspended

On Tue, May 24, 2016 at 10:53:08PM +0200, Gabriele Mazzotta wrote: > Some BIOSes unconditionally send an ACPI notification to RBTN when the > system is resuming from suspend. This makes dell-rbtn send an input > event to userspace as if a function key was pressed. Prevent this by > ignoring all

Re: [PATCH v4] dell-rbtn: Ignore ACPI notifications if device is suspended

On Tue, May 24, 2016 at 10:53:08PM +0200, Gabriele Mazzotta wrote: > Some BIOSes unconditionally send an ACPI notification to RBTN when the > system is resuming from suspend. This makes dell-rbtn send an input > event to userspace as if a function key was pressed. Prevent this by > ignoring all

Re: [PATCH 18/23] arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Tuesday, May 24, 2016 3:04:47 AM CEST Yury Norov wrote: > +static unsigned long compat_sys_mmap2(compat_uptr_t addr, compat_size_t len, > + int prot, int flags, int fd, off_t pgoff) > +{ > + if (pgoff & (~PAGE_MASK >> 12)) > + return -EINVAL; > + > + return

Re: [PATCH 18/23] arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Tuesday, May 24, 2016 3:04:47 AM CEST Yury Norov wrote: > +static unsigned long compat_sys_mmap2(compat_uptr_t addr, compat_size_t len, > + int prot, int flags, int fd, off_t pgoff) > +{ > + if (pgoff & (~PAGE_MASK >> 12)) > + return -EINVAL; > + > + return

<    1   2   3   4   5   6   7   8   9   10   >