Re: [PATCH 4.14 00/45] 4.14.42-stable review

On 05/18/2018 02:15 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.42 release. > There are 45 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.14 00/45] 4.14.42-stable review

On 05/18/2018 02:15 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.42 release. > There are 45 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.16 00/55] 4.16.10-stable review

On 05/18/2018 02:14 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.16.10 release. > There are 55 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.16 00/55] 4.16.10-stable review

On 05/18/2018 02:14 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.16.10 release. > There are 55 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [RFC PATCH 09/09] Introduce cache=rdma moutning option

On Fri, May 18, 2018 at 12:00 PM, Long Li via samba-technical wrote: >> Subject: Re: [RFC PATCH 09/09] Introduce cache=rdma moutning option >> >> On Thu, May 17, 2018 at 05:22:14PM -0700, Long Li wrote: >> > From: Long Li >> > >> > When

Re: [RFC PATCH 09/09] Introduce cache=rdma moutning option

On Fri, May 18, 2018 at 12:00 PM, Long Li via samba-technical wrote: >> Subject: Re: [RFC PATCH 09/09] Introduce cache=rdma moutning option >> >> On Thu, May 17, 2018 at 05:22:14PM -0700, Long Li wrote: >> > From: Long Li >> > >> > When cache=rdma is enabled on mount options, CIFS do not

Re: [PATCHv2][SMB3] Add kernel trace support

On Fri, May 18, 2018 at 11:46 AM, Ralph Böhme wrote: > On Thu, May 17, 2018 at 09:36:36PM -0500, Steve French via samba-technical > wrote: >> Patch updated with additional tracepoint locations and some formatting >> improvements. There are some obvious additional tracepoints that

Re: [PATCHv2][SMB3] Add kernel trace support

On Fri, May 18, 2018 at 11:46 AM, Ralph Böhme wrote: > On Thu, May 17, 2018 at 09:36:36PM -0500, Steve French via samba-technical > wrote: >> Patch updated with additional tracepoint locations and some formatting >> improvements. There are some obvious additional tracepoints that could >> be

Re: [PATCH v4] PCI: kirin: Add MSI support

On Thu, May 17, 2018 at 8:46 PM, Lorenzo Pieralisi wrote: > On Wed, May 16, 2018 at 09:21:59AM +0800, Xiaowei Song wrote: >> +static void kirin_pcie_msi_init(struct pcie_port *pp) >> +{ >> + dw_pcie_msi_init(pp); >> +} >> + >> +static void

Re: [PATCH v4] PCI: kirin: Add MSI support

On Thu, May 17, 2018 at 8:46 PM, Lorenzo Pieralisi wrote: > On Wed, May 16, 2018 at 09:21:59AM +0800, Xiaowei Song wrote: >> +static void kirin_pcie_msi_init(struct pcie_port *pp) >> +{ >> + dw_pcie_msi_init(pp); >> +} >> + >> +static void kirin_pcie_enable_interrupts(struct pcie_port *pp)

Re: [PATCH] kernel: sys: fix potential Spectre v1

On Fri, May 18, 2018 at 12:21 PM, Gustavo A. R. Silva wrote: > > > On 05/18/2018 02:04 PM, Gustavo A. R. Silva wrote: >> >> >> >> On 05/15/2018 05:57 PM, Dan Williams wrote: >>> >>> On Tue, May 15, 2018 at 3:29 PM, Thomas Gleixner >>> wrote:

Re: [PATCH] kernel: sys: fix potential Spectre v1

On Fri, May 18, 2018 at 12:21 PM, Gustavo A. R. Silva wrote: > > > On 05/18/2018 02:04 PM, Gustavo A. R. Silva wrote: >> >> >> >> On 05/15/2018 05:57 PM, Dan Williams wrote: >>> >>> On Tue, May 15, 2018 at 3:29 PM, Thomas Gleixner >>> wrote: On Tue, 15 May 2018, Andrew Morton wrote:

Re: [PATCH] usb-storage: Add quirks to make G-Technology "G-Drive" work

On Fri, 18 May 2018, Alexander Kappner wrote: > Further debugging shows that the code that causes the device to hang is in > drivers/scsi/sd.c:2698. So the reason why usb-storage works and UAS does > not is because the device setting both skip_ms_page_3f=1 and > skip_ms_page_8=1 is required.

Re: [PATCH] usb-storage: Add quirks to make G-Technology "G-Drive" work

On Fri, 18 May 2018, Alexander Kappner wrote: > Further debugging shows that the code that causes the device to hang is in > drivers/scsi/sd.c:2698. So the reason why usb-storage works and UAS does > not is because the device setting both skip_ms_page_3f=1 and > skip_ms_page_8=1 is required.

Re: dma_sync_*_for_cpu and direction=TO_DEVICE (was Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation)

On 05/18/2018 10:50 AM, Russell King - ARM Linux wrote: On Fri, May 18, 2018 at 10:20:02AM -0700, Vineet Gupta wrote: I never understood the need for this direction. And if memory serves me right, at that time I was seeing twice the amount of cache flushing ! It's necessary. Take a moment to

Re: dma_sync_*_for_cpu and direction=TO_DEVICE (was Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation)

On 05/18/2018 10:50 AM, Russell King - ARM Linux wrote: On Fri, May 18, 2018 at 10:20:02AM -0700, Vineet Gupta wrote: I never understood the need for this direction. And if memory serves me right, at that time I was seeing twice the amount of cache flushing ! It's necessary. Take a moment to

Re: [PATCH v10 1/2] arch/*: Add CONFIG_ARCH_HAVE_CMPXCHG64

On Tue, 15 May 2018 15:51:20 PDT (-0700), bart.vanass...@wdc.com wrote: The next patch in this series introduces a call to cmpxchg64() in the block layer core for those architectures on which this functionality is available. Make it possible to test whether cmpxchg64() is available by

Re: [PATCH v10 1/2] arch/*: Add CONFIG_ARCH_HAVE_CMPXCHG64

On Tue, 15 May 2018 15:51:20 PDT (-0700), bart.vanass...@wdc.com wrote: The next patch in this series introduces a call to cmpxchg64() in the block layer core for those architectures on which this functionality is available. Make it possible to test whether cmpxchg64() is available by

[PATCH] ring-buffer: Fix typo in comment

Fix typo in the words 'reserved', 'been' Signed-off-by: Vasyl Gomonovych --- include/linux/ring_buffer.h | 2 +- kernel/trace/ring_buffer.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/ring_buffer.h b/include/linux/ring_buffer.h

[PATCH] ring-buffer: Fix typo in comment

Fix typo in the words 'reserved', 'been' Signed-off-by: Vasyl Gomonovych --- include/linux/ring_buffer.h | 2 +- kernel/trace/ring_buffer.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/ring_buffer.h b/include/linux/ring_buffer.h index

Re: [PATCH] selftests: bpf: config: enable NET_SCH_INGRESS for xdp_meta.sh

On 05/18/2018 08:23 PM, Anders Roxell wrote: > When running bpf's selftest test_xdp_meta.sh it fails: > ./test_xdp_meta.sh > Error: Specified qdisc not found. > selftests: test_xdp_meta [FAILED] > > Need to enable CONFIG_NET_SCH_INGRESS and CONFIG_NET_CLS_ACT to get the > test to pass. > >

Re: [PATCH] selftests: bpf: config: enable NET_SCH_INGRESS for xdp_meta.sh

On 05/18/2018 08:23 PM, Anders Roxell wrote: > When running bpf's selftest test_xdp_meta.sh it fails: > ./test_xdp_meta.sh > Error: Specified qdisc not found. > selftests: test_xdp_meta [FAILED] > > Need to enable CONFIG_NET_SCH_INGRESS and CONFIG_NET_CLS_ACT to get the > test to pass. > >

Re: WARNING in __static_key_slow_dec

On Fri, May 18, 2018 at 4:03 AM, DaeRyong Jeong wrote: > We report the crash: WARNING in __static_key_slow_dec > > This crash has been found in v4.8 using RaceFuzzer (a modified > version of Syzkaller), which we describe more at the end of this > report. > Even though v4.8

Re: WARNING in __static_key_slow_dec

On Fri, May 18, 2018 at 4:03 AM, DaeRyong Jeong wrote: > We report the crash: WARNING in __static_key_slow_dec > > This crash has been found in v4.8 using RaceFuzzer (a modified > version of Syzkaller), which we describe more at the end of this > report. > Even though v4.8 is the relatively old

Re: [PATCH] idr: fix invalid ptr dereference on item delete

On Thu, May 10, 2018 at 10:16:34PM +0300, Roman Kagan wrote: > If an IDR contains a single entry at index==0, the underlying radix tree > has a single item in its root node, in which case > __radix_tree_lookup(index!=0) doesn't set its *@nodep argument (in > addition to returning NULL). > >

Re: [PATCH] idr: fix invalid ptr dereference on item delete

On Thu, May 10, 2018 at 10:16:34PM +0300, Roman Kagan wrote: > If an IDR contains a single entry at index==0, the underlying radix tree > has a single item in its root node, in which case > __radix_tree_lookup(index!=0) doesn't set its *@nodep argument (in > addition to returning NULL). > >

Re: [PATCH 03/18] printk: Convert pr_fmt from blank define to KBUILD_MODNAME

On Fri, May 18, 2018 at 12:10 PM, Joe Perches wrote: > On Fri, 2018-05-18 at 10:42 +0200, Petr Mladek wrote: >> On Thu 2018-05-10 08:45:29, Joe Perches wrote: >> [0.00] libftrace: ftrace: allocating 40753 entries in 160 pages >> [0.004008] apic: APIC: Switch to

Re: [PATCH 03/18] printk: Convert pr_fmt from blank define to KBUILD_MODNAME

On Fri, May 18, 2018 at 12:10 PM, Joe Perches wrote: > On Fri, 2018-05-18 at 10:42 +0200, Petr Mladek wrote: >> On Thu 2018-05-10 08:45:29, Joe Perches wrote: >> [0.00] libftrace: ftrace: allocating 40753 entries in 160 pages >> [0.004008] apic: APIC: Switch to symmetric I/O mode

Re: [PATCH 3/6] swiotlb: merge swiotlb_unmap_page and unmap_single

On Tue, May 15, 2018 at 08:05:20PM +0200, Christoph Hellwig wrote: > Signed-off-by: Christoph Hellwig Applied.

Re: [PATCH 3/6] swiotlb: merge swiotlb_unmap_page and unmap_single

On Tue, May 15, 2018 at 08:05:20PM +0200, Christoph Hellwig wrote: > Signed-off-by: Christoph Hellwig Applied.

Re: [PATCH] idr: fix invalid ptr dereference on item delete

On Fri, May 18, 2018 at 10:50:25AM -0700, Matthew Wilcox wrote: > It'd be nice if you cc'd the person who wrote the code you're patching. > You'd get a response a lot quicker than waiting until I happened to > notice the email in a different forum. I sent it to someone called "Matthew Wilcox

Re: [PATCH] idr: fix invalid ptr dereference on item delete

On Fri, May 18, 2018 at 10:50:25AM -0700, Matthew Wilcox wrote: > It'd be nice if you cc'd the person who wrote the code you're patching. > You'd get a response a lot quicker than waiting until I happened to > notice the email in a different forum. I sent it to someone called "Matthew Wilcox ".

Re: [PATCH -vfs] proc: don't maintain sizeof(struct proc_dir_entry)

On Fri, May 18, 2018 at 11:02:13PM +0300, Alexey Dobriyan wrote: > Automatically cap sizeof(struct proc_dir_entry) at 192/128 bytes or > 256/192 bytes if spinlock debugging/lockdep is enabled. > --- a/fs/proc/internal.h > +++ b/fs/proc/internal.h > @@ -61,13 +61,15 @@ struct proc_dir_entry { >

Re: [PATCH -vfs] proc: don't maintain sizeof(struct proc_dir_entry)

On Fri, May 18, 2018 at 11:02:13PM +0300, Alexey Dobriyan wrote: > Automatically cap sizeof(struct proc_dir_entry) at 192/128 bytes or > 256/192 bytes if spinlock debugging/lockdep is enabled. > --- a/fs/proc/internal.h > +++ b/fs/proc/internal.h > @@ -61,13 +61,15 @@ struct proc_dir_entry { >

Re: [PATCH 1/6] swiotlb: remove a pointless comment

On Tue, May 15, 2018 at 08:05:18PM +0200, Christoph Hellwig wrote: > This comments describes an aspect of the map_sg interface that isn't > even exploited by swiotlb. > > Signed-off-by: Christoph Hellwig Applied. > --- > lib/swiotlb.c | 6 -- > 1 file changed, 6 deletions(-) >

Re: [PATCH 1/6] swiotlb: remove a pointless comment

On Tue, May 15, 2018 at 08:05:18PM +0200, Christoph Hellwig wrote: > This comments describes an aspect of the map_sg interface that isn't > even exploited by swiotlb. > > Signed-off-by: Christoph Hellwig Applied. > --- > lib/swiotlb.c | 6 -- > 1 file changed, 6 deletions(-) > > diff

Re: [PATCH 2/6] swiotlb: do not panic on mapping failures

On Tue, May 15, 2018 at 08:05:19PM +0200, Christoph Hellwig wrote: > We now have error handling in map_single/map_page callers (most of them Which ones are missing? Shouldn't we first fix those before we rip this out? > anyway). As swiotlb_tbl_map_single already prints a useful warning > when

Re: [PATCH 2/6] swiotlb: do not panic on mapping failures

On Tue, May 15, 2018 at 08:05:19PM +0200, Christoph Hellwig wrote: > We now have error handling in map_single/map_page callers (most of them Which ones are missing? Shouldn't we first fix those before we rip this out? > anyway). As swiotlb_tbl_map_single already prints a useful warning > when

Re: [PATCH v2 0/2] ti-cpufreq: minor fixes/cleanups

On Friday, May 18, 2018 5:07:12 PM CEST Suman Anna wrote: > On 04/02/2018 11:49 AM, Suman Anna wrote: > > Hi Viresh, > > > > Please find the updated series replacing the previous patch [1] fixing > > couple of issues in the TI CPUFreq driver. I have split up the patches > > as per your comments

Re: [PATCH v2 0/2] ti-cpufreq: minor fixes/cleanups

On Friday, May 18, 2018 5:07:12 PM CEST Suman Anna wrote: > On 04/02/2018 11:49 AM, Suman Anna wrote: > > Hi Viresh, > > > > Please find the updated series replacing the previous patch [1] fixing > > couple of issues in the TI CPUFreq driver. I have split up the patches > > as per your comments

Re: [PATCH v4 3/3] bpf: add selftest for lirc_mode2 type program

On Fri, May 18, 2018 at 7:07 AM, Sean Young wrote: > This is simple test over rc-loopback. > > Signed-off-by: Sean Young Acked-by: Yonghong Song > --- > tools/bpf/bpftool/prog.c | 1 + > tools/include/uapi/linux/bpf.h

Re: [PATCH v4 3/3] bpf: add selftest for lirc_mode2 type program

On Fri, May 18, 2018 at 7:07 AM, Sean Young wrote: > This is simple test over rc-loopback. > > Signed-off-by: Sean Young Acked-by: Yonghong Song > --- > tools/bpf/bpftool/prog.c | 1 + > tools/include/uapi/linux/bpf.h| 53 - >

Re: [PATCH v4 2/3] media: rc: introduce BPF_PROG_LIRC_MODE2

On Fri, May 18, 2018 at 7:07 AM, Sean Young wrote: > Add support for BPF_PROG_LIRC_MODE2. This type of BPF program can call > rc_keydown() to reported decoded IR scancodes, or rc_repeat() to report > that the last key should be repeated. > > The bpf program can be attached to using

Re: [PATCH v4 2/3] media: rc: introduce BPF_PROG_LIRC_MODE2

On Fri, May 18, 2018 at 7:07 AM, Sean Young wrote: > Add support for BPF_PROG_LIRC_MODE2. This type of BPF program can call > rc_keydown() to reported decoded IR scancodes, or rc_repeat() to report > that the last key should be repeated. > > The bpf program can be attached to using the

[PATCH v2 00/11] Clean up Tegra20 cpufreq driver

Hello, Recently Peter Geis (who is working on Tegra30 cpufreq driver) asked me how tegra20-cpufreq driver is getting loaded. After taking a look at the code it became apparent that the drivers code has been rusted a tad and so this series is intended to refresh the drivers code by disallowing

[PATCH v2 00/11] Clean up Tegra20 cpufreq driver

Hello, Recently Peter Geis (who is working on Tegra30 cpufreq driver) asked me how tegra20-cpufreq driver is getting loaded. After taking a look at the code it became apparent that the drivers code has been rusted a tad and so this series is intended to refresh the drivers code by disallowing

[PATCH] objtool: Detect RIP-relative switch table references, part 2

With the following commit: fd35c88b7417 ("objtool: Support GCC 8 switch tables") I added a "can't find switch jump table" warning, to stop covering up silent failures if add_switch_table() can't find anything. That warning found yet another bug in the objtool switch table detection logic.

[PATCH v2 02/11] cpufreq: tegra20: Clean up whitespaces in the code

Remove unneeded blank line and replace whitespaces with a tab in the code for consistency. Signed-off-by: Dmitry Osipenko Acked-by: Viresh Kumar Acked-by: Thierry Reding --- drivers/cpufreq/tegra20-cpufreq.c | 3 +-- 1 file

[PATCH] objtool: Detect RIP-relative switch table references, part 2

With the following commit: fd35c88b7417 ("objtool: Support GCC 8 switch tables") I added a "can't find switch jump table" warning, to stop covering up silent failures if add_switch_table() can't find anything. That warning found yet another bug in the objtool switch table detection logic.

[PATCH v2 02/11] cpufreq: tegra20: Clean up whitespaces in the code

Remove unneeded blank line and replace whitespaces with a tab in the code for consistency. Signed-off-by: Dmitry Osipenko Acked-by: Viresh Kumar Acked-by: Thierry Reding --- drivers/cpufreq/tegra20-cpufreq.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

[PATCH v2 05/11] cpufreq: tegra20: Release clocks properly

Properly put requested clocks in the module init/exit code. Signed-off-by: Dmitry Osipenko Acked-by: Viresh Kumar Acked-by: Thierry Reding --- drivers/cpufreq/tegra20-cpufreq.c | 31 ++- 1 file changed,

[PATCH v2 05/11] cpufreq: tegra20: Release clocks properly

Properly put requested clocks in the module init/exit code. Signed-off-by: Dmitry Osipenko Acked-by: Viresh Kumar Acked-by: Thierry Reding --- drivers/cpufreq/tegra20-cpufreq.c | 31 ++- 1 file changed, 26 insertions(+), 5 deletions(-) diff --git

[PATCH v2 06/11] cpufreq: tegra20: Remove unneeded check in tegra_cpu_init

Remove checking of the CPU number for consistency as it won't ever fail unless there is a severe bug in the cpufreq core. Signed-off-by: Dmitry Osipenko Acked-by: Viresh Kumar Acked-by: Thierry Reding ---

Re: [PATCH v4 3/3] fs: Add aio iopriority support for block_dev

Hi Adam, Thank you for the patch! Yet something to improve: [auto build test ERROR on next-20180516] [cannot apply to linus/master block/for-next v4.17-rc5 v4.17-rc4 v4.17-rc3 v4.17-rc5] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH v2 06/11] cpufreq: tegra20: Remove unneeded check in tegra_cpu_init

Remove checking of the CPU number for consistency as it won't ever fail unless there is a severe bug in the cpufreq core. Signed-off-by: Dmitry Osipenko Acked-by: Viresh Kumar Acked-by: Thierry Reding --- drivers/cpufreq/tegra20-cpufreq.c | 5 - 1 file changed, 5 deletions(-) diff --git

Re: [PATCH v4 3/3] fs: Add aio iopriority support for block_dev

Hi Adam, Thank you for the patch! Yet something to improve: [auto build test ERROR on next-20180516] [cannot apply to linus/master block/for-next v4.17-rc5 v4.17-rc4 v4.17-rc3 v4.17-rc5] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v4 1/3] bpf: bpf_prog_array_copy() should return -ENOENT if exclude_prog not found

On Fri, May 18, 2018 at 7:07 AM, Sean Young wrote: > This makes is it possible for bpf prog detach to return -ENOENT. > > Signed-off-by: Sean Young Acked-by: Yonghong Song

Re: [PATCH v4 1/3] bpf: bpf_prog_array_copy() should return -ENOENT if exclude_prog not found

On Fri, May 18, 2018 at 7:07 AM, Sean Young wrote: > This makes is it possible for bpf prog detach to return -ENOENT. > > Signed-off-by: Sean Young Acked-by: Yonghong Song

[PATCH v2 08/11] cpufreq: tegra20: Remove unneeded variable initialization

Remove unneeded variable initialization solely for consistency. Signed-off-by: Dmitry Osipenko Acked-by: Viresh Kumar Acked-by: Thierry Reding --- drivers/cpufreq/tegra20-cpufreq.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH v2 01/11] cpufreq: tegra20: Change module description

Change module description to be in line with the other Tegra drivers, just for consistency. Signed-off-by: Dmitry Osipenko Acked-by: Viresh Kumar Acked-by: Thierry Reding --- drivers/cpufreq/tegra20-cpufreq.c | 2 +- 1 file

[PATCH v2 09/11] cpufreq: tegra20: Check if this is Tegra20 machine

Don't even try to request the clocks during of module initialization on non-Tegra20 machines (this is the case for a multi-platform kernel) for consistency. Signed-off-by: Dmitry Osipenko Acked-by: Viresh Kumar Acked-by: Thierry Reding

[PATCH v2 08/11] cpufreq: tegra20: Remove unneeded variable initialization

Remove unneeded variable initialization solely for consistency. Signed-off-by: Dmitry Osipenko Acked-by: Viresh Kumar Acked-by: Thierry Reding --- drivers/cpufreq/tegra20-cpufreq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/cpufreq/tegra20-cpufreq.c

[PATCH v2 01/11] cpufreq: tegra20: Change module description

Change module description to be in line with the other Tegra drivers, just for consistency. Signed-off-by: Dmitry Osipenko Acked-by: Viresh Kumar Acked-by: Thierry Reding --- drivers/cpufreq/tegra20-cpufreq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v2 09/11] cpufreq: tegra20: Check if this is Tegra20 machine

Don't even try to request the clocks during of module initialization on non-Tegra20 machines (this is the case for a multi-platform kernel) for consistency. Signed-off-by: Dmitry Osipenko Acked-by: Viresh Kumar Acked-by: Thierry Reding --- drivers/cpufreq/tegra20-cpufreq.c | 4 1 file

[PATCH v2 10/11] cpufreq: tegra20: Allow cpufreq driver to be built as loadable module

Nothing prevents Tegra20 CPUFreq module to be unloaded, hence allow it to be built as a non-builtin kernel module. Signed-off-by: Dmitry Osipenko Acked-by: Viresh Kumar Acked-by: Thierry Reding --- drivers/cpufreq/Kconfig.arm | 2

[PATCH v2 10/11] cpufreq: tegra20: Allow cpufreq driver to be built as loadable module

Nothing prevents Tegra20 CPUFreq module to be unloaded, hence allow it to be built as a non-builtin kernel module. Signed-off-by: Dmitry Osipenko Acked-by: Viresh Kumar Acked-by: Thierry Reding --- drivers/cpufreq/Kconfig.arm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v2 03/11] cpufreq: tegra20: Clean up included headers

Remove unused/unneeded headers and sort them in the alphabet order. Signed-off-by: Dmitry Osipenko Acked-by: Thierry Reding --- drivers/cpufreq/tegra20-cpufreq.c | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git

[PATCH v2 04/11] cpufreq: tegra20: Remove EMC clock usage

The EMC driver has been gone 4 years ago, since the commit a7cbe92cef27 ("ARM: tegra: remove tegra EMC scaling driver"). Remove the EMC clock usage as it does nothing. We may consider re-implementing the EMC scaling later, probably using PM Memory Bandwidth QoS API. Signed-off-by: Dmitry Osipenko

[PATCH v2 03/11] cpufreq: tegra20: Clean up included headers

Remove unused/unneeded headers and sort them in the alphabet order. Signed-off-by: Dmitry Osipenko Acked-by: Thierry Reding --- drivers/cpufreq/tegra20-cpufreq.c | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/cpufreq/tegra20-cpufreq.c

[PATCH v2 04/11] cpufreq: tegra20: Remove EMC clock usage

The EMC driver has been gone 4 years ago, since the commit a7cbe92cef27 ("ARM: tegra: remove tegra EMC scaling driver"). Remove the EMC clock usage as it does nothing. We may consider re-implementing the EMC scaling later, probably using PM Memory Bandwidth QoS API. Signed-off-by: Dmitry Osipenko

[PATCH v2 11/11] cpufreq: tegra20: Wrap cpufreq into platform driver

Currently tegra20-cpufreq kernel module isn't getting autoloaded because there is no device associated with the module, this is one of two patches that resolves the module autoloading. This patch adds a module alias that will associate the tegra20-cpufreq kernel module with the platform device,

[PATCH v2 11/11] cpufreq: tegra20: Wrap cpufreq into platform driver

Currently tegra20-cpufreq kernel module isn't getting autoloaded because there is no device associated with the module, this is one of two patches that resolves the module autoloading. This patch adds a module alias that will associate the tegra20-cpufreq kernel module with the platform device,

[PATCH v2 07/11] cpufreq: tegra20: Remove unnecessary parentheses

Remove unnecessary parentheses as suggested by the checkpatch script. Signed-off-by: Dmitry Osipenko --- drivers/cpufreq/tegra20-cpufreq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/cpufreq/tegra20-cpufreq.c b/drivers/cpufreq/tegra20-cpufreq.c

[PATCH v2 07/11] cpufreq: tegra20: Remove unnecessary parentheses

Remove unnecessary parentheses as suggested by the checkpatch script. Signed-off-by: Dmitry Osipenko --- drivers/cpufreq/tegra20-cpufreq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/cpufreq/tegra20-cpufreq.c b/drivers/cpufreq/tegra20-cpufreq.c index

Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation

On 18.05.2018 15:03, Alexey Brodkin wrote: > But the real fix of my problem is: > >8 > --- a/lib/dma-noncoherent.c > +++ b/lib/dma-noncoherent.c > @@ -35,7 +35,7 @@ static dma_addr_t dma_noncoherent_map_page(struct device

Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation

On 18.05.2018 15:03, Alexey Brodkin wrote: > But the real fix of my problem is: > >8 > --- a/lib/dma-noncoherent.c > +++ b/lib/dma-noncoherent.c > @@ -35,7 +35,7 @@ static dma_addr_t dma_noncoherent_map_page(struct device

Re: [PATCHv8] gpio: Remove VLA from gpiolib

On Fri, May 18, 2018 at 8:53 PM, Laura Abbott wrote: > The new challenge is to remove VLAs from the kernel > (see https://lkml.org/lkml/2018/3/7/621) to eventually > turn on -Wvla. > > Using a kmalloc array is the easy way to fix this but kmalloc is still > more expensive than

Re: [PATCHv8] gpio: Remove VLA from gpiolib

On Fri, May 18, 2018 at 8:53 PM, Laura Abbott wrote: > The new challenge is to remove VLAs from the kernel > (see https://lkml.org/lkml/2018/3/7/621) to eventually > turn on -Wvla. > > Using a kmalloc array is the easy way to fix this but kmalloc is still > more expensive than stack allocation.

Re: `ucsi_acpi: probe of USBC000:00 failed with error -12` on Dell XPS 13 9360/9370

On Fri, May 18, 2018 at 5:15 PM, Greg Kroah-Hartman wrote: > On Fri, May 18, 2018 at 06:08:24PM +0300, Heikki Krogerus wrote: >> >> Rafael, the problem here with these Dell laptops is that a memory page >> that is used as a mailbox for special communication between EC

Re: `ucsi_acpi: probe of USBC000:00 failed with error -12` on Dell XPS 13 9360/9370

On Fri, May 18, 2018 at 5:15 PM, Greg Kroah-Hartman wrote: > On Fri, May 18, 2018 at 06:08:24PM +0300, Heikki Krogerus wrote: >> >> Rafael, the problem here with these Dell laptops is that a memory page >> that is used as a mailbox for special communication between EC FW and >> OS (called UCSI

Re: [PATCH 043/102] mtd: spi-nor: stm32-quadspi: explicitly request exclusive reset control

On Wed, 19 Jul 2017 17:25:47 +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

Re: [PATCH 043/102] mtd: spi-nor: stm32-quadspi: explicitly request exclusive reset control

On Wed, 19 Jul 2017 17:25:47 +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 V2 RFC] mtd: spi-nor: intel: provide a range for poll_timout

On Tue, 14 Feb 2017 11:47:24 +0200 Mika Westerberg wrote: > On Mon, Feb 13, 2017 at 09:13:42AM +0100, Nicholas Mc Guire wrote: > > The overall poll time here is INTEL_SPI_TIMEOUT * 1000 which is > > 5000 * 1000 - so 5seconds and it is coded as a tight loop here

Re: [PATCH V2 RFC] mtd: spi-nor: intel: provide a range for poll_timout

On Tue, 14 Feb 2017 11:47:24 +0200 Mika Westerberg wrote: > On Mon, Feb 13, 2017 at 09:13:42AM +0100, Nicholas Mc Guire wrote: > > The overall poll time here is INTEL_SPI_TIMEOUT * 1000 which is > > 5000 * 1000 - so 5seconds and it is coded as a tight loop here delay_us > > to

[PATCH -vfs] proc: don't maintain sizeof(struct proc_dir_entry)

Automatically cap sizeof(struct proc_dir_entry) at 192/128 bytes or 256/192 bytes if spinlock debugging/lockdep is enabled. Signed-off-by: Alexey Dobriyan --- fs/proc/generic.c |2 +- fs/proc/inode.c|5 +++-- fs/proc/internal.h | 10 ++ 3 files

[PATCH -vfs] proc: don't maintain sizeof(struct proc_dir_entry)

Automatically cap sizeof(struct proc_dir_entry) at 192/128 bytes or 256/192 bytes if spinlock debugging/lockdep is enabled. Signed-off-by: Alexey Dobriyan --- fs/proc/generic.c |2 +- fs/proc/inode.c|5 +++-- fs/proc/internal.h | 10 ++ 3 files changed, 10 insertions(+),

Re: [PATCH] remoteproc: Proxy unvote clk/regs in handover context

On Wed 25 Apr 07:50 PDT 2018, Sibi Sankar wrote: > Introduce interrupt handler for smp2p ready interrupt and > handle start completion. Remove the proxy votes for clocks > and regulators in the handover interrupt context. Disable > wdog and fatal interrupts on remoteproc device stop and >

Re: [PATCH] remoteproc: Proxy unvote clk/regs in handover context

On Wed 25 Apr 07:50 PDT 2018, Sibi Sankar wrote: > Introduce interrupt handler for smp2p ready interrupt and > handle start completion. Remove the proxy votes for clocks > and regulators in the handover interrupt context. Disable > wdog and fatal interrupts on remoteproc device stop and >

Re: dma_sync_*_for_cpu and direction=TO_DEVICE (was Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation)

Hi Russel, On Fri, 2018-05-18 at 18:50 +0100, Russell King - ARM Linux wrote: > It's necessary. Take a moment to think carefully about this: > > dma_map_single(, dir) > > dma_sync_single_for_cpu(, dir) > > dma_sync_single_for_device(, dir) > >

Re: dma_sync_*_for_cpu and direction=TO_DEVICE (was Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation)

Hi Russel, On Fri, 2018-05-18 at 18:50 +0100, Russell King - ARM Linux wrote: > It's necessary. Take a moment to think carefully about this: > > dma_map_single(, dir) > > dma_sync_single_for_cpu(, dir) > > dma_sync_single_for_device(, dir) > >

drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c:1001:52-53: asic_setup: first occurrence line 1004, second occurrence line 1031 (fwd)

The structure has two initializations of the field asic_setup. julia -- Forwarded message -- Date: Sat, 19 May 2018 02:35:04 +0800 From: kbuild test robot To: kbu...@01.org Cc: Julia Lawall Subject:

drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c:1001:52-53: asic_setup: first occurrence line 1004, second occurrence line 1031 (fwd)

The structure has two initializations of the field asic_setup. julia -- Forwarded message -- Date: Sat, 19 May 2018 02:35:04 +0800 From: kbuild test robot To: kbu...@01.org Cc: Julia Lawall Subject: drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c:1001:52-53: asic_setup:

[PATCH] crypto: chtls - fix a missing-check bug

In do_chtls_setsockopt(), the tls crypto info is first copied from the poiner 'optval' in userspace and saved to 'tmp_crypto_info'. Then the 'version' of the crypto info is checked. If the version is not as expected, i.e., TLS_1_2_VERSION, error code -ENOTSUPP is returned to indicate that the

[PATCH] crypto: chtls - fix a missing-check bug

In do_chtls_setsockopt(), the tls crypto info is first copied from the poiner 'optval' in userspace and saved to 'tmp_crypto_info'. Then the 'version' of the crypto info is checked. If the version is not as expected, i.e., TLS_1_2_VERSION, error code -ENOTSUPP is returned to indicate that the

Re: [PATCH v4 3/3] fs: Add aio iopriority support for block_dev

On 5/18/18 9:06 AM, Christoph Hellwig wrote: > Looks fine, although I'd split it into a aio and block_dev patch. > > Also please wire this up for the fs/iomap.c direct I/O code, it should > be essentially the same sniplet as in the block_dev.c code. > Will do.

Re: [PATCH v4 3/3] fs: Add aio iopriority support for block_dev

On 5/18/18 9:06 AM, Christoph Hellwig wrote: > Looks fine, although I'd split it into a aio and block_dev patch. > > Also please wire this up for the fs/iomap.c direct I/O code, it should > be essentially the same sniplet as in the block_dev.c code. > Will do.

Re: [PATCH v4 2/3] fs: Convert kiocb rw_hint from enum to u16

On 5/18/18 9:05 AM, Christoph Hellwig wrote: >> +/* ki_hint changed from enum to u16, make sure rw_hint fits into u16 */ > > I don't think this comment is very useful. > >> +static inline u16 ki_hint_valid(enum rw_hint hint) > > I'd call this ki_hint_validate. > >> +{ >> +if (hint >

Re: [PATCH v4 2/3] fs: Convert kiocb rw_hint from enum to u16

On 5/18/18 9:05 AM, Christoph Hellwig wrote: >> +/* ki_hint changed from enum to u16, make sure rw_hint fits into u16 */ > > I don't think this comment is very useful. > >> +static inline u16 ki_hint_valid(enum rw_hint hint) > > I'd call this ki_hint_validate. > >> +{ >> +if (hint >

Re: [PATCH v7 2/2] PCI: mediatek: Using chained IRQ to setup IRQ handle

On Fri, May 04, 2018 at 01:47:33PM +0800, honghui.zh...@mediatek.com wrote: > From: Honghui Zhang > > Using irq_chip solution to setup IRQs in order to consist > with IRQ framework. > > Signed-off-by: Honghui Zhang > Acked-by: Ryder Lee

Re: [PATCH v7 2/2] PCI: mediatek: Using chained IRQ to setup IRQ handle

On Fri, May 04, 2018 at 01:47:33PM +0800, honghui.zh...@mediatek.com wrote: > From: Honghui Zhang > > Using irq_chip solution to setup IRQs in order to consist > with IRQ framework. > > Signed-off-by: Honghui Zhang > Acked-by: Ryder Lee > --- > drivers/pci/host/pcie-mediatek.c | 206 >

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