Re: [PATCH] acpi: apei: clear error status before acknowledging the error

On 7/31/2017 11:44 AM, Baicar, Tyler wrote: On 7/31/2017 11:00 AM, Luck, Tony wrote: On Mon, Jul 31, 2017 at 10:15:27AM -0600, Baicar, Tyler wrote: I think the better thing to do in this case is still send the ack. If ghes_read_estatus() fails, then either we are unable to read the estatus or

Re: [PATCH] acpi: apei: clear error status before acknowledging the error

On 7/31/2017 11:44 AM, Baicar, Tyler wrote: On 7/31/2017 11:00 AM, Luck, Tony wrote: On Mon, Jul 31, 2017 at 10:15:27AM -0600, Baicar, Tyler wrote: I think the better thing to do in this case is still send the ack. If ghes_read_estatus() fails, then either we are unable to read the estatus or

Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

From: Mikael Pettersson Date: Thu, 3 Aug 2017 22:02:57 +0200 > With that in place the kernel booted fine. > When I then ran the `poll' strace test binary, the OOPS was replaced by: > > [ 140.589913] _copy_from_user(fff000123c8dfa7c, (null), 240) res > 240 > [

Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

From: Mikael Pettersson Date: Thu, 3 Aug 2017 22:02:57 +0200 > With that in place the kernel booted fine. > When I then ran the `poll' strace test binary, the OOPS was replaced by: > > [ 140.589913] _copy_from_user(fff000123c8dfa7c, (null), 240) res > 240 > [ 140.753162]

[PATCH] Staging: wilc1000: Fix line over 80 characters

This patch fixes 80 characters limit coding style issue. Signed-off-by: Himanshu Jha --- drivers/staging/wilc1000/linux_wlan.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/wilc1000/linux_wlan.c

[PATCH] Staging: wilc1000: Fix line over 80 characters

This patch fixes 80 characters limit coding style issue. Signed-off-by: Himanshu Jha --- drivers/staging/wilc1000/linux_wlan.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/wilc1000/linux_wlan.c b/drivers/staging/wilc1000/linux_wlan.c index

linux-next: Signed-off-by missing for commit in the crypto tree

Hi all, Commit 9577212cc0e2 ("crypto: hash - add crypto_(un)register_ahashes()") is missing a Signed-off-by from its author. -- Cheers, Stephen Rothwell

linux-next: Signed-off-by missing for commit in the crypto tree

Hi all, Commit 9577212cc0e2 ("crypto: hash - add crypto_(un)register_ahashes()") is missing a Signed-off-by from its author. -- Cheers, Stephen Rothwell

[PATCH] watchdog: constify watchdog_ops and watchdog_info structures

These watchdog_ops and watchdog_info structures are only stored in the ops and info fields of a watchdog_device structure, respectively, which are const. Thus make the watchdog_ops and watchdog_info structures const as well. Done with the help of Coccinelle. The rules for the watchdog_ops case

[PATCH] watchdog: constify watchdog_ops and watchdog_info structures

These watchdog_ops and watchdog_info structures are only stored in the ops and info fields of a watchdog_device structure, respectively, which are const. Thus make the watchdog_ops and watchdog_info structures const as well. Done with the help of Coccinelle. The rules for the watchdog_ops case

Re: [PATCH v2] bitops: Avoid integer overflow in GENMASK(_ULL)

On Thu, 3 Aug 2017 14:20:20 -0700 Matthias Kaehlcke wrote: > GENMASK(_ULL) performs a left-shift of ~0UL(L), which technically > results in an integer overflow. clang raises a warning if the overflow > occurs in a preprocessor expression. That's just irritaing. > Clear the

Re: [PATCH v2] bitops: Avoid integer overflow in GENMASK(_ULL)

On Thu, 3 Aug 2017 14:20:20 -0700 Matthias Kaehlcke wrote: > GENMASK(_ULL) performs a left-shift of ~0UL(L), which technically > results in an integer overflow. clang raises a warning if the overflow > occurs in a preprocessor expression. That's just irritaing. > Clear the low-order bits

Re: [PATCH] soc: integrator: remove unnecessary static in integrator_soc_init()

Hi Linus, On 08/02/2017 06:58 AM, Linus Walleij wrote: On Thu, Jul 20, 2017 at 12:39 AM, Gustavo A. R. Silva wrote: Remove unnecessary static on local variable syscon_regmap. Such variables are initialized before being used, on every execution path throughout the

Re: [PATCH] soc: integrator: remove unnecessary static in integrator_soc_init()

Hi Linus, On 08/02/2017 06:58 AM, Linus Walleij wrote: On Thu, Jul 20, 2017 at 12:39 AM, Gustavo A. R. Silva wrote: Remove unnecessary static on local variable syscon_regmap. Such variables are initialized before being used, on every execution path throughout the functions. So, the static

Re: [PATCH 056/102] PCI: mediatek: explicitly request exclusive reset control

On Wed, Jul 19, 2017 at 05:26:00PM +0200, Philipp Zabel wrote: > Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting > reset lines") started to transition the reset control request API calls > to explicitly state whether the driver needs exclusive or shared reset > control

Re: [PATCH 056/102] PCI: mediatek: explicitly request exclusive reset control

On Wed, Jul 19, 2017 at 05:26:00PM +0200, Philipp Zabel wrote: > Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting > reset lines") started to transition the reset control request API calls > to explicitly state whether the driver needs exclusive or shared reset > control

[GIT PULL] VFIO fixes for v4.13-rc4

Hi Linus, The following changes since commit 520eccdfe187591a51ea9ab4c1a024ae4d0f68d9: Linux 4.13-rc2 (2017-07-23 16:15:17 -0700) are available in the git repository at: git://github.com/awilliam/linux-vfio.git tags/vfio-v4.13-rc4 for you to fetch changes up to

[GIT PULL] VFIO fixes for v4.13-rc4

Hi Linus, The following changes since commit 520eccdfe187591a51ea9ab4c1a024ae4d0f68d9: Linux 4.13-rc2 (2017-07-23 16:15:17 -0700) are available in the git repository at: git://github.com/awilliam/linux-vfio.git tags/vfio-v4.13-rc4 for you to fetch changes up to

Re: [PATCH 054/102] PCI: rockchip: explicitly request exclusive reset control

On Wed, Jul 19, 2017 at 05:25:58PM +0200, Philipp Zabel wrote: > Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting > reset lines") started to transition the reset control request API calls > to explicitly state whether the driver needs exclusive or shared reset > control

Re: [PATCH 054/102] PCI: rockchip: explicitly request exclusive reset control

On Wed, Jul 19, 2017 at 05:25:58PM +0200, Philipp Zabel wrote: > Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting > reset lines") started to transition the reset control request API calls > to explicitly state whether the driver needs exclusive or shared reset > control

Re: [PATCH 053/102] PCI: tegra: explicitly request exclusive reset control

On Wed, Jul 19, 2017 at 05:25:57PM +0200, Philipp Zabel wrote: > Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting > reset lines") started to transition the reset control request API calls > to explicitly state whether the driver needs exclusive or shared reset > control

Re: [PATCH] Drivers: usb: serial: Replace unsigned to unsigned int and fix line over 80 characters

On Fri, Aug 04, 2017 at 02:21:13AM +0530, Himanshu Jha wrote: > This patch fixes the following checkpatch.pl warnings: > > WARNING: Block comments use * on subsequent lines > WARNING: Block comments use a trailing */ on a separate line > WARNING: Prefer 'unsigned int' to bare use of 'unsigned' >

Re: [PATCH 053/102] PCI: tegra: explicitly request exclusive reset control

On Wed, Jul 19, 2017 at 05:25:57PM +0200, Philipp Zabel wrote: > Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting > reset lines") started to transition the reset control request API calls > to explicitly state whether the driver needs exclusive or shared reset > control

Re: [PATCH] Drivers: usb: serial: Replace unsigned to unsigned int and fix line over 80 characters

On Fri, Aug 04, 2017 at 02:21:13AM +0530, Himanshu Jha wrote: > This patch fixes the following checkpatch.pl warnings: > > WARNING: Block comments use * on subsequent lines > WARNING: Block comments use a trailing */ on a separate line > WARNING: Prefer 'unsigned int' to bare use of 'unsigned' >

Re: [PATCH 2/2] i2c: mux: pinctrl: drop the idle_state member

On 08/02/2017 11:19 PM, Peter Rosin wrote: On 2017-08-03 00:50, Stephen Warren wrote: On 08/02/2017 03:25 PM, Peter Rosin wrote: (and muxc->max_adapters == num_names) Well, unless muxc->deselect is true... No, deselect does not affect neither max_adapters nor num_names. They are always

Re: [PATCH 052/102] PCI: imx6: explicitly request exclusive reset control

On Wed, Jul 19, 2017 at 05:25:56PM +0200, Philipp Zabel wrote: > Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting > reset lines") started to transition the reset control request API calls > to explicitly state whether the driver needs exclusive or shared reset > control

Re: [PATCH 2/2] i2c: mux: pinctrl: drop the idle_state member

On 08/02/2017 11:19 PM, Peter Rosin wrote: On 2017-08-03 00:50, Stephen Warren wrote: On 08/02/2017 03:25 PM, Peter Rosin wrote: (and muxc->max_adapters == num_names) Well, unless muxc->deselect is true... No, deselect does not affect neither max_adapters nor num_names. They are always

Re: [PATCH 052/102] PCI: imx6: explicitly request exclusive reset control

On Wed, Jul 19, 2017 at 05:25:56PM +0200, Philipp Zabel wrote: > Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting > reset lines") started to transition the reset control request API calls > to explicitly state whether the driver needs exclusive or shared reset > control

Re: [PATCH 051/102] PCI: dwc: pcie-qcom: explicitly request exclusive reset control

On Wed, Jul 19, 2017 at 05:25:55PM +0200, Philipp Zabel wrote: > Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting > reset lines") started to transition the reset control request API calls > to explicitly state whether the driver needs exclusive or shared reset > control

Re: [PATCH 051/102] PCI: dwc: pcie-qcom: explicitly request exclusive reset control

On Wed, Jul 19, 2017 at 05:25:55PM +0200, Philipp Zabel wrote: > Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting > reset lines") started to transition the reset control request API calls > to explicitly state whether the driver needs exclusive or shared reset > control

Re: [RFT PATCH 0/9] PCI: Remove pci_fixup_irqs()

On Mon, Jul 31, 2017 at 05:37:48PM +0100, Lorenzo Pieralisi wrote: > The pci_fixup_irqs() function allocates IRQs for all PCI devices present > in a system; those PCI devices possibly belong to different PCI bus trees > (and possibly rooted at different host bridges) and may well be enabled > (ie

Re: [RFT PATCH 0/9] PCI: Remove pci_fixup_irqs()

On Mon, Jul 31, 2017 at 05:37:48PM +0100, Lorenzo Pieralisi wrote: > The pci_fixup_irqs() function allocates IRQs for all PCI devices present > in a system; those PCI devices possibly belong to different PCI bus trees > (and possibly rooted at different host bridges) and may well be enabled > (ie

[PATCH] acpi: apei: fix GHES estatus iteration

Currently iterating through the GHES estatus blocks does not take into account the new generic data v3 structure size. This can result in garbage non-standard trace events to be triggered since the loop will not properly iterate through the estatus blocks and not properly terminate. Update the

[PATCH] acpi: apei: fix GHES estatus iteration

Currently iterating through the GHES estatus blocks does not take into account the new generic data v3 structure size. This can result in garbage non-standard trace events to be triggered since the loop will not properly iterate through the estatus blocks and not properly terminate. Update the

Re: [PATCH 2/2] arm64: dts: rockchip: Add support for rk3399 excavator main board

Hi Jacob, [auto build test ERROR on rockchip/for-next] [also build test ERROR on v4.13-rc3 next-20170803] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jacob-Chen/arm64-dts-rockchip-Add

[v5 05/15] mm: don't accessed uninitialized struct pages

In deferred_init_memmap() where all deferred struct pages are initialized we have a check like this: if (page->flags) { VM_BUG_ON(page_zone(page) != zone); goto free_range; } This way we are checking if the current deferred page has already been initialized. It

Re: [PATCH 2/2] arm64: dts: rockchip: Add support for rk3399 excavator main board

Hi Jacob, [auto build test ERROR on rockchip/for-next] [also build test ERROR on v4.13-rc3 next-20170803] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jacob-Chen/arm64-dts-rockchip-Add

[v5 05/15] mm: don't accessed uninitialized struct pages

In deferred_init_memmap() where all deferred struct pages are initialized we have a check like this: if (page->flags) { VM_BUG_ON(page_zone(page) != zone); goto free_range; } This way we are checking if the current deferred page has already been initialized. It

[v5 12/15] mm: explicitly zero pagetable memory

Soon vmemmap_alloc_block() will no longer zero the block, so zero memory at its call sites for everything except struct pages. Struct page memory is zero'd by struct page initialization. Signed-off-by: Pavel Tatashin Reviewed-by: Steven Sistare

[v5 12/15] mm: explicitly zero pagetable memory

Soon vmemmap_alloc_block() will no longer zero the block, so zero memory at its call sites for everything except struct pages. Struct page memory is zero'd by struct page initialization. Signed-off-by: Pavel Tatashin Reviewed-by: Steven Sistare Reviewed-by: Daniel Jordan Reviewed-by: Bob

[v5 14/15] mm: optimize early system hash allocations

Clients can call alloc_large_system_hash() with flag: HASH_ZERO to specify that memory that was allocated for system hash needs to be zeroed, otherwise the memory does not need to be zeroed, and client will initialize it. If memory does not need to be zero'd, call the new

[v5 13/15] mm: stop zeroing memory during allocation in vmemmap

Replace allocators in sprase-vmemmap to use the non-zeroing version. So, we will get the performance improvement by zeroing the memory in parallel when struct pages are zeroed. Signed-off-by: Pavel Tatashin Reviewed-by: Steven Sistare

[v5 14/15] mm: optimize early system hash allocations

Clients can call alloc_large_system_hash() with flag: HASH_ZERO to specify that memory that was allocated for system hash needs to be zeroed, otherwise the memory does not need to be zeroed, and client will initialize it. If memory does not need to be zero'd, call the new

[v5 13/15] mm: stop zeroing memory during allocation in vmemmap

Replace allocators in sprase-vmemmap to use the non-zeroing version. So, we will get the performance improvement by zeroing the memory in parallel when struct pages are zeroed. Signed-off-by: Pavel Tatashin Reviewed-by: Steven Sistare Reviewed-by: Daniel Jordan Reviewed-by: Bob Picco ---

[v5 02/15] x86/mm: setting fields in deferred pages

Without deferred struct page feature (CONFIG_DEFERRED_STRUCT_PAGE_INIT), flags and other fields in "struct page"es are never changed prior to first initializing struct pages by going through __init_single_page(). With deferred struct page feature enabled there is a case where we set some fields

[v5 02/15] x86/mm: setting fields in deferred pages

Without deferred struct page feature (CONFIG_DEFERRED_STRUCT_PAGE_INIT), flags and other fields in "struct page"es are never changed prior to first initializing struct pages by going through __init_single_page(). With deferred struct page feature enabled there is a case where we set some fields

[v5 00/15] complete deferred page initialization

Changelog: v5 - v4 - Fixed build issues reported by kbuild on various configurations v4 - v3 - Rewrote code to zero sturct pages in __init_single_page() as suggested by Michal Hocko - Added code to handle issues related to accessing struct page memory before they are initialized. v3 - v2 -

[v5 00/15] complete deferred page initialization

Changelog: v5 - v4 - Fixed build issues reported by kbuild on various configurations v4 - v3 - Rewrote code to zero sturct pages in __init_single_page() as suggested by Michal Hocko - Added code to handle issues related to accessing struct page memory before they are initialized. v3 - v2 -

[v5 03/15] sparc64/mm: setting fields in deferred pages

Without deferred struct page feature (CONFIG_DEFERRED_STRUCT_PAGE_INIT), flags and other fields in "struct page"es are never changed prior to first initializing struct pages by going through __init_single_page(). With deferred struct page feature enabled there is a case where we set some fields

[v5 15/15] mm: debug for raw alloctor

When CONFIG_DEBUG_VM is enabled, this patch sets all the memory that is returned by memblock_virt_alloc_try_nid_raw() to ones to ensure that no places excpect zeroed memory. Signed-off-by: Pavel Tatashin Reviewed-by: Steven Sistare

[v5 03/15] sparc64/mm: setting fields in deferred pages

Without deferred struct page feature (CONFIG_DEFERRED_STRUCT_PAGE_INIT), flags and other fields in "struct page"es are never changed prior to first initializing struct pages by going through __init_single_page(). With deferred struct page feature enabled there is a case where we set some fields

[v5 15/15] mm: debug for raw alloctor

When CONFIG_DEBUG_VM is enabled, this patch sets all the memory that is returned by memblock_virt_alloc_try_nid_raw() to ones to ensure that no places excpect zeroed memory. Signed-off-by: Pavel Tatashin Reviewed-by: Steven Sistare Reviewed-by: Daniel Jordan Reviewed-by: Bob Picco ---

[v5 01/15] x86/mm: reserve only exiting low pages

Struct pages are initialized by going through __init_single_page(). Since the existing physical memory in memblock is represented in memblock.memory list, struct page for every page from this list goes through __init_single_page(). The second memblock list: memblock.reserved, manages the

[v5 01/15] x86/mm: reserve only exiting low pages

Struct pages are initialized by going through __init_single_page(). Since the existing physical memory in memblock is represented in memblock.memory list, struct page for every page from this list goes through __init_single_page(). The second memblock list: memblock.reserved, manages the

[v5 11/15] arm64/kasan: explicitly zero kasan shadow memory

To optimize the performance of struct page initialization, vmemmap_populate() will no longer zero memory. We must explicitly zero the memory that is allocated by vmemmap_populate() for kasan, as this memory does not go through struct page initialization path. Signed-off-by: Pavel Tatashin

[v5 11/15] arm64/kasan: explicitly zero kasan shadow memory

To optimize the performance of struct page initialization, vmemmap_populate() will no longer zero memory. We must explicitly zero the memory that is allocated by vmemmap_populate() for kasan, as this memory does not go through struct page initialization path. Signed-off-by: Pavel Tatashin

[v5 09/15] sparc64: optimized struct page zeroing

Add an optimized mm_zero_struct_page(), so struct page's are zeroed without calling memset(). We do eight regular stores, thus avoid cost of membar. Signed-off-by: Pavel Tatashin Reviewed-by: Steven Sistare Reviewed-by: Daniel Jordan

[v5 09/15] sparc64: optimized struct page zeroing

Add an optimized mm_zero_struct_page(), so struct page's are zeroed without calling memset(). We do eight regular stores, thus avoid cost of membar. Signed-off-by: Pavel Tatashin Reviewed-by: Steven Sistare Reviewed-by: Daniel Jordan Reviewed-by: Bob Picco ---

[v5 07/15] mm: defining memblock_virt_alloc_try_nid_raw

A new variant of memblock_virt_alloc_* allocations: memblock_virt_alloc_try_nid_raw() - Does not zero the allocated memory - Does not panic if request cannot be satisfied Signed-off-by: Pavel Tatashin Reviewed-by: Steven Sistare

[v5 07/15] mm: defining memblock_virt_alloc_try_nid_raw

A new variant of memblock_virt_alloc_* allocations: memblock_virt_alloc_try_nid_raw() - Does not zero the allocated memory - Does not panic if request cannot be satisfied Signed-off-by: Pavel Tatashin Reviewed-by: Steven Sistare Reviewed-by: Daniel Jordan Reviewed-by: Bob Picco ---

[v5 08/15] mm: zero struct pages during initialization

Add struct page zeroing as a part of initialization of other fields in __init_single_page(). Signed-off-by: Pavel Tatashin Reviewed-by: Steven Sistare Reviewed-by: Daniel Jordan Reviewed-by: Bob Picco

[v5 04/15] mm: discard memblock data later

There is existing use after free bug when deferred struct pages are enabled: The memblock_add() allocates memory for the memory array if more than 128 entries are needed. See comment in e820__memblock_setup(): * The bootstrap memblock region count maximum is 128 entries *

[v5 08/15] mm: zero struct pages during initialization

Add struct page zeroing as a part of initialization of other fields in __init_single_page(). Signed-off-by: Pavel Tatashin Reviewed-by: Steven Sistare Reviewed-by: Daniel Jordan Reviewed-by: Bob Picco --- include/linux/mm.h | 9 + mm/page_alloc.c| 1 + 2 files changed, 10

[v5 04/15] mm: discard memblock data later

There is existing use after free bug when deferred struct pages are enabled: The memblock_add() allocates memory for the memory array if more than 128 entries are needed. See comment in e820__memblock_setup(): * The bootstrap memblock region count maximum is 128 entries *

[v5 06/15] sparc64: simplify vmemmap_populate

Remove duplicating code by using common functions vmemmap_pud_populate and vmemmap_pgd_populate. Signed-off-by: Pavel Tatashin Reviewed-by: Steven Sistare Reviewed-by: Daniel Jordan Reviewed-by: Bob Picco

[v5 06/15] sparc64: simplify vmemmap_populate

Remove duplicating code by using common functions vmemmap_pud_populate and vmemmap_pgd_populate. Signed-off-by: Pavel Tatashin Reviewed-by: Steven Sistare Reviewed-by: Daniel Jordan Reviewed-by: Bob Picco --- arch/sparc/mm/init_64.c | 23 ++- 1 file changed, 6

[v5 10/15] x86/kasan: explicitly zero kasan shadow memory

To optimize the performance of struct page initialization, vmemmap_populate() will no longer zero memory. We must explicitly zero the memory that is allocated by vmemmap_populate() for kasan, as this memory does not go through struct page initialization path. Signed-off-by: Pavel Tatashin

[v5 10/15] x86/kasan: explicitly zero kasan shadow memory

To optimize the performance of struct page initialization, vmemmap_populate() will no longer zero memory. We must explicitly zero the memory that is allocated by vmemmap_populate() for kasan, as this memory does not go through struct page initialization path. Signed-off-by: Pavel Tatashin

Re: [PATCH] userfaultfd_zeropage: return -ENOSPC in case mm has gone

On Thu, Aug 03, 2017 at 08:24:43PM +0300, Mike Rapoport wrote: > Now, seriously, I believe there are not many users of non-cooperative uffd > if at all and it is very unlikely anybody has it in production. > > I'll send a patch with s/ENOSPC/ESRCH in the next few days. Ok. Some more thought on

Re: [PATCH] userfaultfd_zeropage: return -ENOSPC in case mm has gone

On Thu, Aug 03, 2017 at 08:24:43PM +0300, Mike Rapoport wrote: > Now, seriously, I believe there are not many users of non-cooperative uffd > if at all and it is very unlikely anybody has it in production. > > I'll send a patch with s/ENOSPC/ESRCH in the next few days. Ok. Some more thought on

[PATCH v2] bitops: Avoid integer overflow in GENMASK(_ULL)

GENMASK(_ULL) performs a left-shift of ~0UL(L), which technically results in an integer overflow. clang raises a warning if the overflow occurs in a preprocessor expression. Clear the low-order bits through a substraction instead of the left-shift to avoid the overflow. Signed-off-by: Matthias

[PATCH v2] bitops: Avoid integer overflow in GENMASK(_ULL)

GENMASK(_ULL) performs a left-shift of ~0UL(L), which technically results in an integer overflow. clang raises a warning if the overflow occurs in a preprocessor expression. Clear the low-order bits through a substraction instead of the left-shift to avoid the overflow. Signed-off-by: Matthias

Re: [PATCH 1/3] PCI: dwc: Handle host_init failures

On Sat, Jul 15, 2017 at 11:39:45PM -0700, Bjorn Andersson wrote: > In several dwc based drivers host_init can fail, so make sure to > propagate and handle this to avoid continuing operation of a driver or > hardware in an invalid state. > > Signed-off-by: Bjorn Andersson

Re: [PATCH 1/3] PCI: dwc: Handle host_init failures

On Sat, Jul 15, 2017 at 11:39:45PM -0700, Bjorn Andersson wrote: > In several dwc based drivers host_init can fail, so make sure to > propagate and handle this to avoid continuing operation of a driver or > hardware in an invalid state. > > Signed-off-by: Bjorn Andersson Applied patches 1-3 to

Re: [PATCH 0/3] remove rw_page() from brd, pmem and btt

On 08/03/2017 03:13 PM, Ross Zwisler wrote: > On Thu, Aug 03, 2017 at 09:13:15AM +0900, Minchan Kim wrote: >> Hi Ross, >> >> On Wed, Aug 02, 2017 at 04:13:59PM -0600, Ross Zwisler wrote: >>> On Fri, Jul 28, 2017 at 10:31:43AM -0700, Matthew Wilcox wrote: On Fri, Jul 28, 2017 at 10:56:01AM

Re: [PATCH 0/3] remove rw_page() from brd, pmem and btt

On 08/03/2017 03:13 PM, Ross Zwisler wrote: > On Thu, Aug 03, 2017 at 09:13:15AM +0900, Minchan Kim wrote: >> Hi Ross, >> >> On Wed, Aug 02, 2017 at 04:13:59PM -0600, Ross Zwisler wrote: >>> On Fri, Jul 28, 2017 at 10:31:43AM -0700, Matthew Wilcox wrote: On Fri, Jul 28, 2017 at 10:56:01AM

Re: [PATCH 0/3] remove rw_page() from brd, pmem and btt

On Thu, Aug 03, 2017 at 09:13:15AM +0900, Minchan Kim wrote: > Hi Ross, > > On Wed, Aug 02, 2017 at 04:13:59PM -0600, Ross Zwisler wrote: > > On Fri, Jul 28, 2017 at 10:31:43AM -0700, Matthew Wilcox wrote: > > > On Fri, Jul 28, 2017 at 10:56:01AM -0600, Ross Zwisler wrote: > > > > Dan Williams

Re: [PATCH 0/3] remove rw_page() from brd, pmem and btt

On Thu, Aug 03, 2017 at 09:13:15AM +0900, Minchan Kim wrote: > Hi Ross, > > On Wed, Aug 02, 2017 at 04:13:59PM -0600, Ross Zwisler wrote: > > On Fri, Jul 28, 2017 at 10:31:43AM -0700, Matthew Wilcox wrote: > > > On Fri, Jul 28, 2017 at 10:56:01AM -0600, Ross Zwisler wrote: > > > > Dan Williams

Re: [RFC]Add new mdev interface for QoS

On Thu, 3 Aug 2017 20:26:14 +0800 "Gao, Ping A" wrote: > On 2017/8/3 0:58, Alex Williamson wrote: > > On Wed, 2 Aug 2017 21:16:28 +0530 > > Kirti Wankhede wrote: > > > >> On 8/2/2017 6:29 PM, Gao, Ping A wrote: > >>> On 2017/8/2 18:19, Kirti

Re: [RFC]Add new mdev interface for QoS

On Thu, 3 Aug 2017 20:26:14 +0800 "Gao, Ping A" wrote: > On 2017/8/3 0:58, Alex Williamson wrote: > > On Wed, 2 Aug 2017 21:16:28 +0530 > > Kirti Wankhede wrote: > > > >> On 8/2/2017 6:29 PM, Gao, Ping A wrote: > >>> On 2017/8/2 18:19, Kirti Wankhede wrote: > On 8/2/2017 3:56 AM,

Re: [PATCH] Input: elantech - support new touchpad IC and extend elan's touchapd command Origianl ic-body field is not sufficient for upcoming IC, Elan ps/2 driver extend the fomation to support futur

Hi, Something went wrong with your subject line, it also includes the further commit message lines and the signed off line .. Origianl -> Original fomation .. Do you mean information ? On Wed, Aug 02, 2017 at 07:11:41PM +0800, KT Liao wrote: > > --- > drivers/input/mouse/elantech.c | 28

Re: [PATCH] Input: elantech - support new touchpad IC and extend elan's touchapd command Origianl ic-body field is not sufficient for upcoming IC, Elan ps/2 driver extend the fomation to support futur

Hi, Something went wrong with your subject line, it also includes the further commit message lines and the signed off line .. Origianl -> Original fomation .. Do you mean information ? On Wed, Aug 02, 2017 at 07:11:41PM +0800, KT Liao wrote: > > --- > drivers/input/mouse/elantech.c | 28

Re: [PATCH RFC 3/4] arch/sparc: Optimized memcpy, memset, copy_to_user, copy_from_user for M7

David, Thanks for the comments. I am working on addressing your feedback. Comments inline below. On 7/29/2017 4:36 PM, David Miller wrote: From: Babu Moger Date: Thu, 27 Jul 2017 15:57:29 -0600 @@ -600,7 +600,7 @@ niagara_tlb_fixup: be,pt %xcc,

Re: [PATCH RFC 3/4] arch/sparc: Optimized memcpy, memset, copy_to_user, copy_from_user for M7

David, Thanks for the comments. I am working on addressing your feedback. Comments inline below. On 7/29/2017 4:36 PM, David Miller wrote: From: Babu Moger Date: Thu, 27 Jul 2017 15:57:29 -0600 @@ -600,7 +600,7 @@ niagara_tlb_fixup: be,pt %xcc, niagara4_patch nop

[PATCH v3 1/2] timers: Don't wake ktimersoftd on every tick

We recently upgraded from 4.1 to 4.6 and noticed a minor latency regression caused by an additional thread wakeup (ktimersoftd) in interrupt context on every tick. The wakeups are from run_local_timers() raising TIMER_SOFTIRQ. Both TIMER and SCHED softirq coalesced into one ksoftirqd wakeup prior

[PATCH v3 1/2] timers: Don't wake ktimersoftd on every tick

We recently upgraded from 4.1 to 4.6 and noticed a minor latency regression caused by an additional thread wakeup (ktimersoftd) in interrupt context on every tick. The wakeups are from run_local_timers() raising TIMER_SOFTIRQ. Both TIMER and SCHED softirq coalesced into one ksoftirqd wakeup prior

[PATCH v3 2/2] timers: Don't search for expired timers while TIMER_SOFTIRQ is scheduled

This change avoid needlessly searching for more timers in run_local_timers() (hard interrupt context) when they can't fire. For example, when ktimersoftd/run_timer_softirq() is scheduled but preempted due to cpu contention. When it runs, run_timer_softirq() will discover newly expired timers up to

[PATCH v3 2/2] timers: Don't search for expired timers while TIMER_SOFTIRQ is scheduled

This change avoid needlessly searching for more timers in run_local_timers() (hard interrupt context) when they can't fire. For example, when ktimersoftd/run_timer_softirq() is scheduled but preempted due to cpu contention. When it runs, run_timer_softirq() will discover newly expired timers up to

Re: [PATCH v2] timers: Don't wake ktimersoftd on every tick

Thomas, Apologies on the late response. I've been busy last few weeks. On 07/18/2017 04:33 PM, Thomas Gleixner wrote: On Mon, 17 Jul 2017, Haris Okanovic wrote: We recently upgraded from 4.1 to 4.6 and noticed a minor latency regression caused by an additional thread wakeup (ktimersoftd) in

Re: [PATCH v2] timers: Don't wake ktimersoftd on every tick

Thomas, Apologies on the late response. I've been busy last few weeks. On 07/18/2017 04:33 PM, Thomas Gleixner wrote: On Mon, 17 Jul 2017, Haris Okanovic wrote: We recently upgraded from 4.1 to 4.6 and noticed a minor latency regression caused by an additional thread wakeup (ktimersoftd) in

Re: [PATCH v13 4/5] mm: support reporting free page blocks

On Thu, Aug 03, 2017 at 03:20:09PM +, Wang, Wei W wrote: > On Thursday, August 3, 2017 9:51 PM, Michal Hocko: > > As I've said earlier. Start simple optimize incrementally with some numbers > > to > > justify a more subtle code. > > -- > > OK. Let's start with the simple implementation as

Re: [PATCH v13 4/5] mm: support reporting free page blocks

On Thu, Aug 03, 2017 at 03:20:09PM +, Wang, Wei W wrote: > On Thursday, August 3, 2017 9:51 PM, Michal Hocko: > > As I've said earlier. Start simple optimize incrementally with some numbers > > to > > justify a more subtle code. > > -- > > OK. Let's start with the simple implementation as

Re: [PATCH v3 7/7] ima: Support module-style appended signatures for appraisal

Mimi Zohar writes: > On Wed, 2017-08-02 at 18:52 -0400, Mimi Zohar wrote: >> On Wed, 2017-08-02 at 14:42 -0300, Thiago Jung Bauermann wrote: >> > Mimi Zohar writes: > >> > >> @@ -229,8 +251,24 @@ int ima_appraise_measurement(enum ima_hooks

Re: [PATCH v3 7/7] ima: Support module-style appended signatures for appraisal

Mimi Zohar writes: > On Wed, 2017-08-02 at 18:52 -0400, Mimi Zohar wrote: >> On Wed, 2017-08-02 at 14:42 -0300, Thiago Jung Bauermann wrote: >> > Mimi Zohar writes: > >> > >> @@ -229,8 +251,24 @@ int ima_appraise_measurement(enum ima_hooks func, >> > >> goto out; >> > >>

[PATCH] Drivers: usb: serial: Replace unsigned to unsigned int and fix line over 80 characters

This patch fixes the following checkpatch.pl warnings: WARNING: Block comments use * on subsequent lines WARNING: Block comments use a trailing */ on a separate line WARNING: Prefer 'unsigned int' to bare use of 'unsigned' WARNING: Missing a blank line after declarations WARNING: line over 80

[PATCH] Drivers: usb: serial: Replace unsigned to unsigned int and fix line over 80 characters

This patch fixes the following checkpatch.pl warnings: WARNING: Block comments use * on subsequent lines WARNING: Block comments use a trailing */ on a separate line WARNING: Prefer 'unsigned int' to bare use of 'unsigned' WARNING: Missing a blank line after declarations WARNING: line over 80

Re: [PATCH v6 1/3] perf/core: use rb trees for pinned/flexible groups

On 03.08.2017 16:00, Peter Zijlstra wrote: > On Wed, Aug 02, 2017 at 11:13:54AM +0300, Alexey Budankov wrote: >> This patch moves event groups into rb tree sorted by CPU, so that >> multiplexing hrtimer interrupt handler would be able skipping to the current >> CPU's list and ignore groups

Re: [PATCH v6 1/3] perf/core: use rb trees for pinned/flexible groups

On 03.08.2017 16:00, Peter Zijlstra wrote: > On Wed, Aug 02, 2017 at 11:13:54AM +0300, Alexey Budankov wrote: >> This patch moves event groups into rb tree sorted by CPU, so that >> multiplexing hrtimer interrupt handler would be able skipping to the current >> CPU's list and ignore groups

Re: [PATCH 1/3] dt-bindings: add "size" property.

On Thu, Jul 27, 2017 at 10:13:07PM +0530, divagar.mohand...@intel.com wrote: > From: Divagar Mohandass Please improve the subject. Add size to what? > > This adds "size" as optional property for i2c eeproms. > > "size" should be mentioned in byte and it should

Re: [PATCH 1/3] dt-bindings: add "size" property.

On Thu, Jul 27, 2017 at 10:13:07PM +0530, divagar.mohand...@intel.com wrote: > From: Divagar Mohandass Please improve the subject. Add size to what? > > This adds "size" as optional property for i2c eeproms. > > "size" should be mentioned in byte and it should refer > to the eeprom size. This

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