Re: Autoselect patches for stable (Was: Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV)

On Mon, Nov 20, 2017 at 01:39:31PM +0100, Daniel Vetter wrote: > Of course our CI is open, so if someone is supremely bored and wants to > backport more stuff for drm/i915, they could do that. But atm it doesn't > happen, and then having to deal with the fallout is not really great (like > I said,

Re: Autoselect patches for stable (Was: Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV)

On Mon, Nov 20, 2017 at 01:39:31PM +0100, Daniel Vetter wrote: > Of course our CI is open, so if someone is supremely bored and wants to > backport more stuff for drm/i915, they could do that. But atm it doesn't > happen, and then having to deal with the fallout is not really great (like > I said,

[PATCH v1] scripts: leaking_addresses.pl: add support for 32-bit kernel addresses

The current leaking_addresses.pl script only supports showing "leaked" 64-bit kernel virtual addresses. This patch adds support for showing "leaked" 32-bit kernel virtual addresses. The way it currently works- once it detects we're running on an i'x'86 platform (where x=3|4|5|6), it takes this

[PATCH v1] scripts: leaking_addresses.pl: add support for 32-bit kernel addresses

The current leaking_addresses.pl script only supports showing "leaked" 64-bit kernel virtual addresses. This patch adds support for showing "leaked" 32-bit kernel virtual addresses. The way it currently works- once it detects we're running on an i'x'86 platform (where x=3|4|5|6), it takes this

Re: [PATCH v2] checkpatch: allow URL >80 chars

On Mon, 2017-11-20 at 22:02 -0800, Joe Perches wrote: > On Mon, 2017-11-20 at 13:40 +0100, Andreas Brauchli wrote: > > Allow URL to exceed the 80 char limit for improved interaction in > > adaption to ongoing but undocumented practice. > > > > $ git grep -E '://\S{77}.*' -- '*.[ch]' > > > > The

Re: [PATCH v2] checkpatch: allow URL >80 chars

On Mon, 2017-11-20 at 22:02 -0800, Joe Perches wrote: > On Mon, 2017-11-20 at 13:40 +0100, Andreas Brauchli wrote: > > Allow URL to exceed the 80 char limit for improved interaction in > > adaption to ongoing but undocumented practice. > > > > $ git grep -E '://\S{77}.*' -- '*.[ch]' > > > > The

Re: [PATCH v2 1/2] PCI: designware-ep: Fix find_first_zero_bit() usage

Hi Lorenzo, On Saturday 18 November 2017 12:13 AM, Lorenzo Pieralisi wrote: > [+Kishon - please CC him next time] > > On Fri, Nov 17, 2017 at 04:00:40PM +0100, Niklas Cassel wrote: >> find_first_zero_bit()'s parameter 'size' is defined in bits, >> not in bytes. >> >> find_first_zero_bit() was

Re: [PATCH v2 1/2] PCI: designware-ep: Fix find_first_zero_bit() usage

Hi Lorenzo, On Saturday 18 November 2017 12:13 AM, Lorenzo Pieralisi wrote: > [+Kishon - please CC him next time] > > On Fri, Nov 17, 2017 at 04:00:40PM +0100, Niklas Cassel wrote: >> find_first_zero_bit()'s parameter 'size' is defined in bits, >> not in bytes. >> >> find_first_zero_bit() was

Re: [PATCH 1/1] mm/cma: fix alloc_contig_range ret code/potential leak

On 11/20/2017 08:39 PM, Mike Kravetz wrote: > If the call __alloc_contig_migrate_range() in alloc_contig_range > returns -EBUSY, processing continues so that test_pages_isolated() > is called where there is a tracepoint to identify the busy pages. > However, it is possible for busy pages to become

Re: [PATCH 1/1] mm/cma: fix alloc_contig_range ret code/potential leak

On 11/20/2017 08:39 PM, Mike Kravetz wrote: > If the call __alloc_contig_migrate_range() in alloc_contig_range > returns -EBUSY, processing continues so that test_pages_isolated() > is called where there is a tracepoint to identify the busy pages. > However, it is possible for busy pages to become

Re: [PATCH 4.13 00/28] 4.13.15-stable review

On Tue, Nov 21, 2017 at 08:23:20AM +0100, Greg Kroah-Hartman wrote: > On Mon, Nov 20, 2017 at 06:13:42AM -0800, Guenter Roeck wrote: > > On 11/19/2017 06:43 AM, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 4.13.15 release. > > > There are 28 patches in this

Re: [PATCH 4.13 00/28] 4.13.15-stable review

On Tue, Nov 21, 2017 at 08:23:20AM +0100, Greg Kroah-Hartman wrote: > On Mon, Nov 20, 2017 at 06:13:42AM -0800, Guenter Roeck wrote: > > On 11/19/2017 06:43 AM, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 4.13.15 release. > > > There are 28 patches in this

Re: [PATCH 4.13 07/28] crypto: brcm - Explicity ACK mailbox message

Nope, this patch breaks the build as it relies on a previous patch that is not in 4.13-stable, so I'm dropping it. If anyone wants it there, well, it really feels like it shouldn't be included in a stable tree anyway... thanks, greg k-h On Sun, Nov 19, 2017 at 03:43:54PM +0100, Greg

Re: [PATCH 4.13 07/28] crypto: brcm - Explicity ACK mailbox message

Nope, this patch breaks the build as it relies on a previous patch that is not in 4.13-stable, so I'm dropping it. If anyone wants it there, well, it really feels like it shouldn't be included in a stable tree anyway... thanks, greg k-h On Sun, Nov 19, 2017 at 03:43:54PM +0100, Greg

Re: [GIT PULL] platform-drivers-x86 for 4.15-1

On Mon, Nov 20, 2017 at 9:06 AM, Darren Hart wrote: > > Back in the 4.2 timeframe, platform-drivers-x86-v4.2-2 specifically, I > started adding my pull request commentary to the tag directly and the > pull requests themselves tended to have little or no information beyond >

Re: [GIT PULL] platform-drivers-x86 for 4.15-1

On Mon, Nov 20, 2017 at 9:06 AM, Darren Hart wrote: > > Back in the 4.2 timeframe, platform-drivers-x86-v4.2-2 specifically, I > started adding my pull request commentary to the tag directly and the > pull requests themselves tended to have little or no information beyond > that. Right - that's

Re: [PATCH 16/16] x86/entry/64: Move the IST stacks into cpu_entry_area

* Andy Lutomirski wrote: > /* May not be marked __init: used by software suspend */ > void syscall_init(void) > { > @@ -1627,7 +1637,7 @@ void cpu_init(void) >* set up and load the per-CPU TSS >*/ > if (!oist->ist[0]) { > - char *estacks =

Re: [PATCH 16/16] x86/entry/64: Move the IST stacks into cpu_entry_area

* Andy Lutomirski wrote: > /* May not be marked __init: used by software suspend */ > void syscall_init(void) > { > @@ -1627,7 +1637,7 @@ void cpu_init(void) >* set up and load the per-CPU TSS >*/ > if (!oist->ist[0]) { > - char *estacks =

Re: [PATCH 00/16] Entry stuff, in decent shape now

* Andy Lutomirski wrote: > This sets up stack switching, including for SYSCALL. I think it's > in decent shape. > > Known issues: > - KASAN is likely to be busted. This could be fixed either by teaching >KASAN that cpu_entry_area contains valid stacks (I have no clue

Re: [PATCH 00/16] Entry stuff, in decent shape now

* Andy Lutomirski wrote: > This sets up stack switching, including for SYSCALL. I think it's > in decent shape. > > Known issues: > - KASAN is likely to be busted. This could be fixed either by teaching >KASAN that cpu_entry_area contains valid stacks (I have no clue how >to go

Re: [PATCH v1] mm: relax deferred struct page requirements

On Thu 16-11-17 20:46:01, Pavel Tatashin wrote: > There is no need to have ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT, > as all the page initialization code is in common code. > > Also, there is no need to depend on MEMORY_HOTPLUG, as initialization code > does not really use hotplug memory

Re: [PATCH v1] mm: relax deferred struct page requirements

On Thu 16-11-17 20:46:01, Pavel Tatashin wrote: > There is no need to have ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT, > as all the page initialization code is in common code. > > Also, there is no need to depend on MEMORY_HOTPLUG, as initialization code > does not really use hotplug memory

Re: [PATCH 4.13 00/28] 4.13.15-stable review

On Mon, Nov 20, 2017 at 06:13:42AM -0800, Guenter Roeck wrote: > On 11/19/2017 06:43 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.13.15 release. > > There are 28 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 4.13 00/28] 4.13.15-stable review

On Mon, Nov 20, 2017 at 06:13:42AM -0800, Guenter Roeck wrote: > On 11/19/2017 06:43 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.13.15 release. > > There are 28 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 4.14 00/31] 4.14.1-stable review

On Mon, Nov 20, 2017 at 02:19:56PM -0700, Shuah Khan wrote: > On 11/19/2017 07:59 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.1 release. > > There are 31 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 4.14 00/31] 4.14.1-stable review

On Mon, Nov 20, 2017 at 02:19:56PM -0700, Shuah Khan wrote: > On 11/19/2017 07:59 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.1 release. > > There are 31 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 11/16] x86/asm/64: Use a percpu trampoline stack for IDT entries

* Andy Lutomirski wrote: > diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c > index 1ea03027a4a9..e4a941be96cf 100644 > --- a/arch/x86/kernel/traps.c > +++ b/arch/x86/kernel/traps.c > -asmlinkage __visible notrace > +asmlinkage __visible notrace

Re: [PATCH 11/16] x86/asm/64: Use a percpu trampoline stack for IDT entries

* Andy Lutomirski wrote: > diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c > index 1ea03027a4a9..e4a941be96cf 100644 > --- a/arch/x86/kernel/traps.c > +++ b/arch/x86/kernel/traps.c > -asmlinkage __visible notrace > +asmlinkage __visible notrace __no_sanitize_address > struct

Re: [PATCH v3] x86/umip: Warn if UMIP-protected instructions are used

* Ricardo Neri wrote: > Print a rate-limited warning when a user space program attempts to execute > any of the instructions that UMIP protects (i.e., SGDT, SIDT, SLDT, STR > and SMSW). > > This is useful because, when CONFIG_X86_INTEL_UMIP is selected

Re: [PATCH v3] x86/umip: Warn if UMIP-protected instructions are used

* Ricardo Neri wrote: > Print a rate-limited warning when a user space program attempts to execute > any of the instructions that UMIP protects (i.e., SGDT, SIDT, SLDT, STR > and SMSW). > > This is useful because, when CONFIG_X86_INTEL_UMIP is selected and > supported by the hardware, user

Re: [PATCH 09/30] x86, kaiser: only populate shadow page tables for userspace

* Thomas Gleixner wrote: > > + */ > > +static inline bool pgd_userspace_access(pgd_t pgd) > > +{ > > + return (pgd.pgd & _PAGE_USER); > > +} Also a nit: the parentheses are superfluous - these aren't macros. Thanks, Ingo

Re: [PATCH 09/30] x86, kaiser: only populate shadow page tables for userspace

* Thomas Gleixner wrote: > > + */ > > +static inline bool pgd_userspace_access(pgd_t pgd) > > +{ > > + return (pgd.pgd & _PAGE_USER); > > +} Also a nit: the parentheses are superfluous - these aren't macros. Thanks, Ingo

Re: [RFC v2] prctl: prctl(PR_SET_IDLE, PR_IDLE_MODE_KILLME), for stateless idle loops

On Mon 20-11-17 20:48:10, Shawn Landden wrote: > On Mon, Nov 20, 2017 at 12:35 AM, Michal Hocko wrote: > > On Fri 17-11-17 20:45:03, Shawn Landden wrote: > >> On Fri, Nov 3, 2017 at 2:09 AM, Michal Hocko wrote: > >> > >> > On Thu 02-11-17 23:35:44, Shawn

Re: [RFC v2] prctl: prctl(PR_SET_IDLE, PR_IDLE_MODE_KILLME), for stateless idle loops

On Mon 20-11-17 20:48:10, Shawn Landden wrote: > On Mon, Nov 20, 2017 at 12:35 AM, Michal Hocko wrote: > > On Fri 17-11-17 20:45:03, Shawn Landden wrote: > >> On Fri, Nov 3, 2017 at 2:09 AM, Michal Hocko wrote: > >> > >> > On Thu 02-11-17 23:35:44, Shawn Landden wrote: > >> > > It is common for

Re: [PATCH v2] mm: show total hugetlb memory consumption in /proc/meminfo

On Mon 20-11-17 16:51:10, Andrew Morton wrote: > On Wed, 15 Nov 2017 23:14:09 + Roman Gushchin wrote: > > > Currently we display some hugepage statistics (total, free, etc) > > in /proc/meminfo, but only for default hugepage size (e.g. 2Mb). > > > > If hugepages of different

Re: [PATCH v2] mm: show total hugetlb memory consumption in /proc/meminfo

On Mon 20-11-17 16:51:10, Andrew Morton wrote: > On Wed, 15 Nov 2017 23:14:09 + Roman Gushchin wrote: > > > Currently we display some hugepage statistics (total, free, etc) > > in /proc/meminfo, but only for default hugepage size (e.g. 2Mb). > > > > If hugepages of different sizes are used

Re: [PATCHv2] drm: adv7511/33: Fix adv7511_cec_init() failure handling

Hi Hans, Thank you for the patch. On Monday, 20 November 2017 22:57:34 EET Hans Verkuil wrote: > If the device tree for a board did not specify a cec clock, then > adv7511_cec_init would return an error, which would cause adv7511_probe() > to fail and thus there is no HDMI output. > > There is

Re: [PATCHv2] drm: adv7511/33: Fix adv7511_cec_init() failure handling

Hi Hans, Thank you for the patch. On Monday, 20 November 2017 22:57:34 EET Hans Verkuil wrote: > If the device tree for a board did not specify a cec clock, then > adv7511_cec_init would return an error, which would cause adv7511_probe() > to fail and thus there is no HDMI output. > > There is

Re: [PATCH] rdma: Add Jason as a co-maintainer

On Tue, Nov 21, 2017 at 07:04:56AM +0200, Leon Romanovsky wrote: > On Mon, Nov 20, 2017 at 11:06:31AM -0700, Jason Gunthorpe wrote: > > On Mon, Nov 20, 2017 at 06:10:16PM +0200, Leon Romanovsky wrote: > > > On Thu, Nov 16, 2017 at 01:44:00PM -0700, Jason Gunthorpe wrote: > > > > As was discussed

Re: [PATCH] rdma: Add Jason as a co-maintainer

On Tue, Nov 21, 2017 at 07:04:56AM +0200, Leon Romanovsky wrote: > On Mon, Nov 20, 2017 at 11:06:31AM -0700, Jason Gunthorpe wrote: > > On Mon, Nov 20, 2017 at 06:10:16PM +0200, Leon Romanovsky wrote: > > > On Thu, Nov 16, 2017 at 01:44:00PM -0700, Jason Gunthorpe wrote: > > > > As was discussed

[PATCH v2 0/4] platform/x86: intel_telemetry: Fix logs and formatting

This patchset fixes https://bugzilla.kernel.org/show_bug.cgi?id=197833, and other issues related to telemetry counters. It also cleans up formatting and removes redundant code. It is rebased on top of the TESTING branch. Code-Review comments have been incorporated. Souvik Kumar Chakravarty (4):

[PATCH v2 0/4] platform/x86: intel_telemetry: Fix logs and formatting

This patchset fixes https://bugzilla.kernel.org/show_bug.cgi?id=197833, and other issues related to telemetry counters. It also cleans up formatting and removes redundant code. It is rebased on top of the TESTING branch. Code-Review comments have been incorporated. Souvik Kumar Chakravarty (4):

[PATCH v1 1/4] platform/x86: intel_pmc_ipc: Add readq API for GCR

Add intel_pmc_gcr_readq API for reading from 64-bit GCR registers. This API will be called from intel_telemetry. Rename intel_pmc_gcr_read to more appropriate intel_pmc_gcr_readl. Signed-off-by: Souvik Kumar Chakravarty --- arch/x86/include/asm/intel_pmc_ipc.h |

[PATCH v1 1/4] platform/x86: intel_pmc_ipc: Add readq API for GCR

Add intel_pmc_gcr_readq API for reading from 64-bit GCR registers. This API will be called from intel_telemetry. Rename intel_pmc_gcr_read to more appropriate intel_pmc_gcr_readl. Signed-off-by: Souvik Kumar Chakravarty --- arch/x86/include/asm/intel_pmc_ipc.h | 10 --

[PATCH v2 3/4] platform/x86: intel_telemetry: Improve S0ix logs

Suspend with shallow wakes is not a useful parameter since the phenomena does not exist on deployed devices and is only a parameter of use during device power-on phase. The field always reads zero. Additionally there are other easier methods to detect it, e.g., if the S0ix counter increments by

[PATCH v2 3/4] platform/x86: intel_telemetry: Improve S0ix logs

Suspend with shallow wakes is not a useful parameter since the phenomena does not exist on deployed devices and is only a parameter of use during device power-on phase. The field always reads zero. Additionally there are other easier methods to detect it, e.g., if the S0ix counter increments by

[PATCH v2 2/4] platform/x86: intel_telemetry: Fix suspend stats

Suspend stats are not reported consistently due to a limitation in the PMC firmware. This limitation causes a delay in updating the s0ix counters and residencies in the telemetry log upon s0ix exit. As a consequence, reading these counters from the suspend-exit notifier may result in zero read.

[PATCH v2 4/4] platform/x86: intel_telemetry: Remove redundancies

This patch removes unnecessary header files and newlines. It also fixes some alignment issues. Signed-off-by: Souvik Kumar Chakravarty --- drivers/platform/x86/intel_telemetry_debugfs.c | 13 +++-- 1 file changed, 3 insertions(+), 10 deletions(-) Changes

[PATCH v2 2/4] platform/x86: intel_telemetry: Fix suspend stats

Suspend stats are not reported consistently due to a limitation in the PMC firmware. This limitation causes a delay in updating the s0ix counters and residencies in the telemetry log upon s0ix exit. As a consequence, reading these counters from the suspend-exit notifier may result in zero read.

[PATCH v2 4/4] platform/x86: intel_telemetry: Remove redundancies

This patch removes unnecessary header files and newlines. It also fixes some alignment issues. Signed-off-by: Souvik Kumar Chakravarty --- drivers/platform/x86/intel_telemetry_debugfs.c | 13 +++-- 1 file changed, 3 insertions(+), 10 deletions(-) Changes since v1: * Consolidated

Re: [PATCH 15/16] x86/irq/64: In the stack overflow warning, print the offending IP

* Andy Lutomirski wrote: > In case something goes wrong with unwind (not unlikely in case of > overflow), print the offending IP where we detected the overflow. I have added a SOB here as well. Thanks, Ingo

Re: [PATCH 15/16] x86/irq/64: In the stack overflow warning, print the offending IP

* Andy Lutomirski wrote: > In case something goes wrong with unwind (not unlikely in case of > overflow), print the offending IP where we detected the overflow. I have added a SOB here as well. Thanks, Ingo

Re: [PATCH 14/16] x86/irq: Remove an old outdated comment about context tracking races

* Andy Lutomirski wrote: > That race has been fixed and code cleaned up for a while now. JFYI, I have added your SOB here, which I assume you just forgot to include. Thanks, Ingo

Re: [PATCH 14/16] x86/irq: Remove an old outdated comment about context tracking races

* Andy Lutomirski wrote: > That race has been fixed and code cleaned up for a while now. JFYI, I have added your SOB here, which I assume you just forgot to include. Thanks, Ingo

Re: RFC: Copying Device Tree File into reserved area of VMLINUX before deployment

On 2017-11-21 00:09, Ulf Samuelsson wrote: On 2017-11-20 22:39, Frank Rowand wrote: Hi Ulf, Rob, On 11/20/17 15:19, Ulf Samuelsson wrote: On 2017-11-20 05:32, Frank Rowand wrote: Hi Ulf, On 11/19/17 23:23, Frank Rowand wrote: adding devicetree list, devicetree maintainers On

Re: RFC: Copying Device Tree File into reserved area of VMLINUX before deployment

On 2017-11-21 00:09, Ulf Samuelsson wrote: On 2017-11-20 22:39, Frank Rowand wrote: Hi Ulf, Rob, On 11/20/17 15:19, Ulf Samuelsson wrote: On 2017-11-20 05:32, Frank Rowand wrote: Hi Ulf, On 11/19/17 23:23, Frank Rowand wrote: adding devicetree list, devicetree maintainers On

Re: [PATCH] ASoC: amd: Add error checking to probe function

On 11/21/2017 10:17 AM, Deucher, Alexander wrote: -Original Message- From: Guenter Roeck [mailto:groe...@gmail.com] On Behalf Of Guenter Roeck Sent: Monday, November 20, 2017 11:28 PM To: Liam Girdwood Cc: Mark Brown; Jaroslav Kysela; Takashi Iwai; alsa-de...@alsa-project.org;

Re: [PATCH] ASoC: amd: Add error checking to probe function

On 11/21/2017 10:17 AM, Deucher, Alexander wrote: -Original Message- From: Guenter Roeck [mailto:groe...@gmail.com] On Behalf Of Guenter Roeck Sent: Monday, November 20, 2017 11:28 PM To: Liam Girdwood Cc: Mark Brown; Jaroslav Kysela; Takashi Iwai; alsa-de...@alsa-project.org;

[PATCH] drivers/fsi: sbefifo: fix call_kern.cocci warnings

Function sbefifo_enq_xfr called inside lock from sbefifo_write_common but uses GFP_KERNEL. Change to GFP_ATOMIC. Generated by: scripts/coccinelle/locks/call_kern.cocci Fixes: 0f8664fbfc9f ("drivers/fsi: sbefifo: Add miscdevice") CC: Edward A. James Signed-off-by: Julia

[PATCH] drivers/fsi: sbefifo: fix call_kern.cocci warnings

Function sbefifo_enq_xfr called inside lock from sbefifo_write_common but uses GFP_KERNEL. Change to GFP_ATOMIC. Generated by: scripts/coccinelle/locks/call_kern.cocci Fixes: 0f8664fbfc9f ("drivers/fsi: sbefifo: Add miscdevice") CC: Edward A. James Signed-off-by: Julia Lawall Signed-off-by:

Re: [PATCH] scsi/eh: fix hang adding ehandler wakeups after decrementing host_busy

Pavel, It turns out that the error handler on our systems was not getting woken up for a different reason... I submitted a patch earlier today that fixes the issue I were seeing (I CCed you on the patch). Before I got my hands on the failing system and was able to root cause it, I was pretty

Re: [PATCH] scsi/eh: fix hang adding ehandler wakeups after decrementing host_busy

Pavel, It turns out that the error handler on our systems was not getting woken up for a different reason... I submitted a patch earlier today that fixes the issue I were seeing (I CCed you on the patch). Before I got my hands on the failing system and was able to root cause it, I was pretty

Re: [PATCH] IB: INFINIBAND should depend on HAS_DMA

On Sun, Nov 19, 2017 at 07:58:30PM +0100, Geert Uytterhoeven wrote: > If NO_DMA=y: > > ERROR: "bad_dma_ops" [net/sunrpc/xprtrdma/rpcrdma.ko] undefined! > ERROR: "bad_dma_ops" [net/smc/smc.ko] undefined! > ERROR: "bad_dma_ops" [net/rds/rds_rdma.ko] undefined! > ERROR: "bad_dma_ops"

Re: [PATCH] IB: INFINIBAND should depend on HAS_DMA

On Sun, Nov 19, 2017 at 07:58:30PM +0100, Geert Uytterhoeven wrote: > If NO_DMA=y: > > ERROR: "bad_dma_ops" [net/sunrpc/xprtrdma/rpcrdma.ko] undefined! > ERROR: "bad_dma_ops" [net/smc/smc.ko] undefined! > ERROR: "bad_dma_ops" [net/rds/rds_rdma.ko] undefined! > ERROR: "bad_dma_ops"

Re: [PATCH v2] checkpatch: allow URL >80 chars

On Mon, 2017-11-20 at 13:40 +0100, Andreas Brauchli wrote: > Allow URL to exceed the 80 char limit for improved interaction in > adaption to ongoing but undocumented practice. > > $ git grep -E '://\S{77}.*' -- '*.[ch]' > > The patch checks that the URL is indeed on its own line in that it >

Re: [PATCH v2] checkpatch: allow URL >80 chars

On Mon, 2017-11-20 at 13:40 +0100, Andreas Brauchli wrote: > Allow URL to exceed the 80 char limit for improved interaction in > adaption to ongoing but undocumented practice. > > $ git grep -E '://\S{77}.*' -- '*.[ch]' > > The patch checks that the URL is indeed on its own line in that it >

Re: [PATCH] proc: fix /proc/*/map_files lookup

On Mon, Nov 20, 2017 at 02:16:14PM -0800, Andrew Morton wrote: > On Tue, 21 Nov 2017 00:27:06 +0300 Alexey Dobriyan > wrote: > > very broken > > # readlink > > '/proc/1/map_files/155a23af39000-55a23b05b000' > > /lib/systemd/systemd > > > >

Re: [PATCH] proc: fix /proc/*/map_files lookup

On Mon, Nov 20, 2017 at 02:16:14PM -0800, Andrew Morton wrote: > On Tue, 21 Nov 2017 00:27:06 +0300 Alexey Dobriyan > wrote: > > very broken > > # readlink > > '/proc/1/map_files/155a23af39000-55a23b05b000' > > /lib/systemd/systemd > > > > Signed-off-by: Alexey

[PATCH v2] platform/x86: Add Acer Wireless Radio Control driver

New Acer laptops in 2018 will have a separate ACPI device for notifications from the airplane mode hotkey. The device name in the DSDT is SMKB and its ACPI _HID is 10251229. For these models, when the airplane mode hotkey (Fn+F3) pressed, a query 0x02 is started in the Embedded Controller, and

[PATCH v2] platform/x86: Add Acer Wireless Radio Control driver

New Acer laptops in 2018 will have a separate ACPI device for notifications from the airplane mode hotkey. The device name in the DSDT is SMKB and its ACPI _HID is 10251229. For these models, when the airplane mode hotkey (Fn+F3) pressed, a query 0x02 is started in the Embedded Controller, and

Re: [RFC v4] It is common for services to be stateless around their main event loop. If a process sets PR_SET_IDLE to PR_IDLE_MODE_KILLME then it signals to the kernel that epoll_wait() and friends ma

On Mon, Nov 20, 2017 at 9:16 PM, Shawn Landden wrote: > See my systemd patch: https://github.com/shawnl/systemd/tree/prctl > > Android uses this memory model for all programs, and having it in the > kernel will enable integration with the page cache (not in this > series).

Re: [RFC v4] It is common for services to be stateless around their main event loop. If a process sets PR_SET_IDLE to PR_IDLE_MODE_KILLME then it signals to the kernel that epoll_wait() and friends ma

On Mon, Nov 20, 2017 at 9:16 PM, Shawn Landden wrote: > See my systemd patch: https://github.com/shawnl/systemd/tree/prctl > > Android uses this memory model for all programs, and having it in the > kernel will enable integration with the page cache (not in this > series). What about having a

[RFC v4] It is common for services to be stateless around their main event loop. If a process sets PR_SET_IDLE to PR_IDLE_MODE_KILLME then it signals to the kernel that epoll_wait() and friends may no

See my systemd patch: https://github.com/shawnl/systemd/tree/prctl Android uses this memory model for all programs, and having it in the kernel will enable integration with the page cache (not in this series). v2 switch to prctl, memcg support v3 use put OOM after constraint checking v4

[RFC v4] It is common for services to be stateless around their main event loop. If a process sets PR_SET_IDLE to PR_IDLE_MODE_KILLME then it signals to the kernel that epoll_wait() and friends may no

See my systemd patch: https://github.com/shawnl/systemd/tree/prctl Android uses this memory model for all programs, and having it in the kernel will enable integration with the page cache (not in this series). v2 switch to prctl, memcg support v3 use put OOM after constraint checking v4

Re: [Patch v7 00/22] CIFS: Implement SMB Direct protocol

Have remerged (to cifs-2.6.git for-next) the first seven in this series - after he incorporated the fixes for the recent feedback on the series to a few (and I cleaned up a few minor checkpatch nits). On Tue, Nov 7, 2017 at 2:54 AM, Long Li wrote: > From: Long Li

Re: [Patch v7 00/22] CIFS: Implement SMB Direct protocol

Have remerged (to cifs-2.6.git for-next) the first seven in this series - after he incorporated the fixes for the recent feedback on the series to a few (and I cleaned up a few minor checkpatch nits). On Tue, Nov 7, 2017 at 2:54 AM, Long Li wrote: > From: Long Li > > Starting with SMB2 dialect

[PATCH v2] staging: fsl-mc: fix mc-portal to use u32 type

According to MC APIs, size of mc-portal in 32bit. Also fsl_create_mc_io() storing 32 bit mc-portal size. " mc_io->portal_size = mc_portal_size;" While "mc_io->portal_size" is u16 type and "mc_portal_size" is u32 type. This patches changes mc_io->portal_size from u16 to u32

[PATCH v2] staging: fsl-mc: fix mc-portal to use u32 type

According to MC APIs, size of mc-portal in 32bit. Also fsl_create_mc_io() storing 32 bit mc-portal size. " mc_io->portal_size = mc_portal_size;" While "mc_io->portal_size" is u16 type and "mc_portal_size" is u32 type. This patches changes mc_io->portal_size from u16 to u32

Re: [PATCH] rdma: Add Jason as a co-maintainer

On Mon, Nov 20, 2017 at 11:06:31AM -0700, Jason Gunthorpe wrote: > On Mon, Nov 20, 2017 at 06:10:16PM +0200, Leon Romanovsky wrote: > > On Thu, Nov 16, 2017 at 01:44:00PM -0700, Jason Gunthorpe wrote: > > > As was discussed in September and October, add Jason along with > > > Doug to have a team

Re: [PATCH] rdma: Add Jason as a co-maintainer

On Mon, Nov 20, 2017 at 11:06:31AM -0700, Jason Gunthorpe wrote: > On Mon, Nov 20, 2017 at 06:10:16PM +0200, Leon Romanovsky wrote: > > On Thu, Nov 16, 2017 at 01:44:00PM -0700, Jason Gunthorpe wrote: > > > As was discussed in September and October, add Jason along with > > > Doug to have a team

[PATCH] staging: fsl-mc: fix mc-portal to use uin32_t type

According to MC APIs, size of mc-portal in 32bit. Also fsl_create_mc_io() storing 32 bit mc-portal size. " mc_io->portal_size = mc_portal_size;" While "mc_io->portal_size" is uin16_t type and "mc_portal_size" is uin32_t type. This patches changes mc_io->portal_size from uin16_t to

[PATCH] staging: fsl-mc: fix mc-portal to use uin32_t type

According to MC APIs, size of mc-portal in 32bit. Also fsl_create_mc_io() storing 32 bit mc-portal size. " mc_io->portal_size = mc_portal_size;" While "mc_io->portal_size" is uin16_t type and "mc_portal_size" is uin32_t type. This patches changes mc_io->portal_size from uin16_t to

Re: [PATCH] 4.4.86-rt99: fix sync breakage between nr_cpus_allowed and cpus_allowed

On Mon, 20 Nov 2017 23:02:07 -0500 Steven Rostedt wrote: > Ideally, I would like to stay close to what upstream -rt does. Would > you be able to backport the 4.11-rt patch? > > I'm currently working on releasing 4.9-rt and 4.4-rt with the latest > backports. I could easily

Re: [PATCH] 4.4.86-rt99: fix sync breakage between nr_cpus_allowed and cpus_allowed

On Mon, 20 Nov 2017 23:02:07 -0500 Steven Rostedt wrote: > Ideally, I would like to stay close to what upstream -rt does. Would > you be able to backport the 4.11-rt patch? > > I'm currently working on releasing 4.9-rt and 4.4-rt with the latest > backports. I could easily add this one too.

Re: [RFC v3] It is common for services to be stateless around their main event loop. If a process sets PR_SET_IDLE to PR_IDLE_MODE_KILLME then it signals to the kernel that epoll_wait() and friends ma

On Mon, Nov 20, 2017 at 8:49 PM, Shawn Landden wrote: > See my systemd patch: https://github.com/shawnl/systemd/tree/prctl > > Android uses this memory model for all programs, and having it in the > kernel will enable integration with the page cache (not in this > series). > >

Re: [RFC v3] It is common for services to be stateless around their main event loop. If a process sets PR_SET_IDLE to PR_IDLE_MODE_KILLME then it signals to the kernel that epoll_wait() and friends ma

On Mon, Nov 20, 2017 at 8:49 PM, Shawn Landden wrote: > See my systemd patch: https://github.com/shawnl/systemd/tree/prctl > > Android uses this memory model for all programs, and having it in the > kernel will enable integration with the page cache (not in this > series). > > v2 > switch to

[RFC v3] It is common for services to be stateless around their main event loop. If a process sets PR_SET_IDLE to PR_IDLE_MODE_KILLME then it signals to the kernel that epoll_wait() and friends may no

See my systemd patch: https://github.com/shawnl/systemd/tree/prctl Android uses this memory model for all programs, and having it in the kernel will enable integration with the page cache (not in this series). v2 switch to prctl, memcg support v3 use put OOM after constraint checking ---

[RFC v3] It is common for services to be stateless around their main event loop. If a process sets PR_SET_IDLE to PR_IDLE_MODE_KILLME then it signals to the kernel that epoll_wait() and friends may no

See my systemd patch: https://github.com/shawnl/systemd/tree/prctl Android uses this memory model for all programs, and having it in the kernel will enable integration with the page cache (not in this series). v2 switch to prctl, memcg support v3 use put OOM after constraint checking ---

Re: [RFC v2] prctl: prctl(PR_SET_IDLE, PR_IDLE_MODE_KILLME), for stateless idle loops

On Mon, Nov 20, 2017 at 12:35 AM, Michal Hocko wrote: > On Fri 17-11-17 20:45:03, Shawn Landden wrote: >> On Fri, Nov 3, 2017 at 2:09 AM, Michal Hocko wrote: >> >> > On Thu 02-11-17 23:35:44, Shawn Landden wrote: >> > > It is common for services to be

Re: [RFC v2] prctl: prctl(PR_SET_IDLE, PR_IDLE_MODE_KILLME), for stateless idle loops

On Mon, Nov 20, 2017 at 12:35 AM, Michal Hocko wrote: > On Fri 17-11-17 20:45:03, Shawn Landden wrote: >> On Fri, Nov 3, 2017 at 2:09 AM, Michal Hocko wrote: >> >> > On Thu 02-11-17 23:35:44, Shawn Landden wrote: >> > > It is common for services to be stateless around their main event loop. >> >

RE: [PATCH] ASoC: amd: Add error checking to probe function

> -Original Message- > From: Guenter Roeck [mailto:groe...@gmail.com] On Behalf Of Guenter > Roeck > Sent: Monday, November 20, 2017 11:28 PM > To: Liam Girdwood > Cc: Mark Brown; Jaroslav Kysela; Takashi Iwai; alsa-de...@alsa-project.org; > linux-kernel@vger.kernel.org; Guenter Roeck;

RE: [PATCH] ASoC: amd: Add error checking to probe function

> -Original Message- > From: Guenter Roeck [mailto:groe...@gmail.com] On Behalf Of Guenter > Roeck > Sent: Monday, November 20, 2017 11:28 PM > To: Liam Girdwood > Cc: Mark Brown; Jaroslav Kysela; Takashi Iwai; alsa-de...@alsa-project.org; > linux-kernel@vger.kernel.org; Guenter Roeck;

Re: [RFC PATCH] blk-throttle: add burst allowance.

On Fri, Nov 17, 2017 at 11:26 AM, Shaohua Li wrote: > On Thu, Nov 16, 2017 at 08:25:58PM -0800, Khazhismel Kumykov wrote: >> On Thu, Nov 16, 2017 at 8:50 AM, Shaohua Li wrote: >> > On Tue, Nov 14, 2017 at 03:10:22PM -0800, Khazhismel Kumykov wrote: >> >> Allows

Re: [RFC PATCH] blk-throttle: add burst allowance.

On Fri, Nov 17, 2017 at 11:26 AM, Shaohua Li wrote: > On Thu, Nov 16, 2017 at 08:25:58PM -0800, Khazhismel Kumykov wrote: >> On Thu, Nov 16, 2017 at 8:50 AM, Shaohua Li wrote: >> > On Tue, Nov 14, 2017 at 03:10:22PM -0800, Khazhismel Kumykov wrote: >> >> Allows configuration additional bytes or

[PATCH] ASoC: amd: Add error checking to probe function

The acp_audio_dma does not perform sufficient error checking in its probe function. This can result in crashes if a critical error path is encountered. Fixes: 7c31335a03b6a ("ASoC: AMD: add AMD ASoC ACP 2.x DMA driver") Cc: Alex Deucher Cc: Dominik Behr

[PATCH] ASoC: amd: Add error checking to probe function

The acp_audio_dma does not perform sufficient error checking in its probe function. This can result in crashes if a critical error path is encountered. Fixes: 7c31335a03b6a ("ASoC: AMD: add AMD ASoC ACP 2.x DMA driver") Cc: Alex Deucher Cc: Dominik Behr Cc: Daniel Kurtz Signed-off-by: Guenter

[PATCH] power: supply: charger-manager: Fix typo in condition

From: Ryosuke Saito Should be discharging_max_duration_ms, not charging_max_duration_ms. Signed-off-by: Ryosuke Saito --- drivers/power/supply/charger-manager.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] power: supply: charger-manager: Fix typo in condition

From: Ryosuke Saito Should be discharging_max_duration_ms, not charging_max_duration_ms. Signed-off-by: Ryosuke Saito --- drivers/power/supply/charger-manager.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/power/supply/charger-manager.c

Re: [PATCH] i40w: Remove garbage at end of INFINIBAND_I40IW Kconfig section

On Sun, Nov 19, 2017 at 07:59:21PM +0100, Geert Uytterhoeven wrote: > Remove leftover garbage (containing Kconfig dependencies for another > symbol?) > > Signed-off-by: Geert Uytterhoeven > --- Acked-by: Shiraz Saleem

Re: [PATCH] i40w: Remove garbage at end of INFINIBAND_I40IW Kconfig section

On Sun, Nov 19, 2017 at 07:59:21PM +0100, Geert Uytterhoeven wrote: > Remove leftover garbage (containing Kconfig dependencies for another > symbol?) > > Signed-off-by: Geert Uytterhoeven > --- Acked-by: Shiraz Saleem

  1   2   3   4   5   6   7   8   9   10   >