Re: [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek

On Thu, Mar 29, 2018 at 03:15:54PM +0200, Andreas Gruenbacher wrote: > > For all I know, Neil's latest plan is to get rhashtable_walk_peek > replaced and removed because it is unfixable. This patch removes the > one and only user. His latest patch makes rhashtable_walk_peek stable in the face of

Re: [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek

On Thu, Mar 29, 2018 at 03:15:54PM +0200, Andreas Gruenbacher wrote: > > For all I know, Neil's latest plan is to get rhashtable_walk_peek > replaced and removed because it is unfixable. This patch removes the > one and only user. His latest patch makes rhashtable_walk_peek stable in the face of

Re: [PATCH v7 05/14] ext4, dax: introduce ext4_dax_aops

On Wed 21-03-18 15:57:37, Dan Williams wrote: > In preparation for the dax implementation to start associating dax pages > to inodes via page->mapping, we need to provide a 'struct > address_space_operations' instance for dax. Otherwise, direct-I/O > triggers incorrect page cache assumptions and

Re: [PATCH v7 05/14] ext4, dax: introduce ext4_dax_aops

On Wed 21-03-18 15:57:37, Dan Williams wrote: > In preparation for the dax implementation to start associating dax pages > to inodes via page->mapping, we need to provide a 'struct > address_space_operations' instance for dax. Otherwise, direct-I/O > triggers incorrect page cache assumptions and

Re: [RFC PATCH for 4.17 02/21] rseq: Introduce restartable sequences system call (v12)

- On Mar 29, 2018, at 10:23 AM, Peter Zijlstra pet...@infradead.org wrote: > On Thu, Mar 29, 2018 at 09:54:01AM -0400, Mathieu Desnoyers wrote: >> Let's say we disallow system calls from rseq critical sections. A few points >> arise: >> >> - We still need to allow traps (page faults,

Re: [RFC PATCH for 4.17 02/21] rseq: Introduce restartable sequences system call (v12)

- On Mar 29, 2018, at 10:23 AM, Peter Zijlstra pet...@infradead.org wrote: > On Thu, Mar 29, 2018 at 09:54:01AM -0400, Mathieu Desnoyers wrote: >> Let's say we disallow system calls from rseq critical sections. A few points >> arise: >> >> - We still need to allow traps (page faults,

[PATCH] kbuild: use -fmacro-prefix-map to make __FILE__ a relative path

The __FILE__ macro is used everywhere in the kernel to locate the file path printing the log message. The biggest users of this macro are WARN_ON() and friends. If the kernel is built out of tree, this could be a long absolute path, like this: WARNING: CPU: 1 PID: 1 at

[PATCH] cw1200: fix spelling mistake: "Mailformed" -> "Malformed"

From: Colin Ian King Trivial fix to spelling mistake in wiphy_warn warning message text Signed-off-by: Colin Ian King --- drivers/net/wireless/st/cw1200/txrx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] kbuild: use -fmacro-prefix-map to make __FILE__ a relative path

The __FILE__ macro is used everywhere in the kernel to locate the file path printing the log message. The biggest users of this macro are WARN_ON() and friends. If the kernel is built out of tree, this could be a long absolute path, like this: WARNING: CPU: 1 PID: 1 at

[PATCH] cw1200: fix spelling mistake: "Mailformed" -> "Malformed"

From: Colin Ian King Trivial fix to spelling mistake in wiphy_warn warning message text Signed-off-by: Colin Ian King --- drivers/net/wireless/st/cw1200/txrx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/st/cw1200/txrx.c

Re: [PATCH] crypto: cavium: zip: Remove unnecessary parentheses

On Wed, Mar 28, 2018 at 11:41 PM, Joe Perches wrote: > > On Wed, 2018-03-28 at 23:27, Varsha Rao wrote: > > This patch fixes the clang warning of extraneous parentheses, with the > > following coccinelle script. > > > > @@ > > identifier i; > > constant c; > > @@ > > ( > > -((i == c)) > > +i == c

Re: [PATCH] crypto: cavium: zip: Remove unnecessary parentheses

On Wed, Mar 28, 2018 at 11:41 PM, Joe Perches wrote: > > On Wed, 2018-03-28 at 23:27, Varsha Rao wrote: > > This patch fixes the clang warning of extraneous parentheses, with the > > following coccinelle script. > > > > @@ > > identifier i; > > constant c; > > @@ > > ( > > -((i == c)) > > +i == c

Re: [PATCH v7 04/14] xfs, dax: introduce xfs_dax_aops

On Wed 21-03-18 15:57:32, Dan Williams wrote: > In preparation for the dax implementation to start associating dax pages > to inodes via page->mapping, we need to provide a 'struct > address_space_operations' instance for dax. Otherwise, direct-I/O > triggers incorrect page cache assumptions and

Re: [PATCH v7 04/14] xfs, dax: introduce xfs_dax_aops

On Wed 21-03-18 15:57:32, Dan Williams wrote: > In preparation for the dax implementation to start associating dax pages > to inodes via page->mapping, we need to provide a 'struct > address_space_operations' instance for dax. Otherwise, direct-I/O > triggers incorrect page cache assumptions and

Re: [RESEND PATCH v2 4/8] mfd: stm32-timers: add support for dmas

On 03/29/2018 04:31 PM, Lee Jones wrote: > On Thu, 29 Mar 2018, Fabrice Gasnier wrote: > >> On 03/29/2018 02:59 PM, Lee Jones wrote: >>> On Wed, 28 Mar 2018, Fabrice Gasnier wrote: >>> On 03/28/2018 05:22 PM, Lee Jones wrote: > On Wed, 14 Feb 2018, Fabrice Gasnier wrote: > >>

Re: [RESEND PATCH v2 4/8] mfd: stm32-timers: add support for dmas

On 03/29/2018 04:31 PM, Lee Jones wrote: > On Thu, 29 Mar 2018, Fabrice Gasnier wrote: > >> On 03/29/2018 02:59 PM, Lee Jones wrote: >>> On Wed, 28 Mar 2018, Fabrice Gasnier wrote: >>> On 03/28/2018 05:22 PM, Lee Jones wrote: > On Wed, 14 Feb 2018, Fabrice Gasnier wrote: > >>

[PATCH v2 1/4] virt: vbox: Move declarations of vboxguest private functions to private header

Move the declarations of functions from vboxguest_utils.c which are only meant for vboxguest internal use from include/linux/vbox_utils.h to drivers/virt/vboxguest/vboxguest_core.h. Cc: sta...@vger.kernel.org Signed-off-by: Hans de Goede ---

[PATCH v2 1/4] virt: vbox: Move declarations of vboxguest private functions to private header

Move the declarations of functions from vboxguest_utils.c which are only meant for vboxguest internal use from include/linux/vbox_utils.h to drivers/virt/vboxguest/vboxguest_core.h. Cc: sta...@vger.kernel.org Signed-off-by: Hans de Goede --- drivers/virt/vboxguest/vboxguest_core.h | 8

Re: [PATCH 4.4 009/134] PCI/MSI: Stop disabling MSI/MSI-X in pci_device_shutdown()

On Mon, 2018-03-19 at 19:04 +0100, Greg Kroah-Hartman wrote: > 4.4-stable review patch.  If anyone has any objections, please let me know. > > -- > > From: Prarit Bhargava > > > [ Upstream commit fda78d7a0ead144f4b2cdb582dcba47911f4952c ] [...] > The MSI

Re: [PATCH 4.4 009/134] PCI/MSI: Stop disabling MSI/MSI-X in pci_device_shutdown()

On Mon, 2018-03-19 at 19:04 +0100, Greg Kroah-Hartman wrote: > 4.4-stable review patch.  If anyone has any objections, please let me know. > > -- > > From: Prarit Bhargava > > > [ Upstream commit fda78d7a0ead144f4b2cdb582dcba47911f4952c ] [...] > The MSI disabling code was

Re: [PATCH v7 03/14] block, dax: remove dead code in blkdev_writepages()

On Wed 21-03-18 15:57:27, Dan Williams wrote: > Block device inodes never have S_DAX set, so kill the check for DAX and > diversion to dax_writeback_mapping_range(). > > Cc: Jeff Moyer > Cc: Ross Zwisler > Cc: Matthew Wilcox

Re: [PATCH v7 03/14] block, dax: remove dead code in blkdev_writepages()

On Wed 21-03-18 15:57:27, Dan Williams wrote: > Block device inodes never have S_DAX set, so kill the check for DAX and > diversion to dax_writeback_mapping_range(). > > Cc: Jeff Moyer > Cc: Ross Zwisler > Cc: Matthew Wilcox > Cc: Jan Kara > Cc: Dave Chinner > Reviewed-by: Christoph Hellwig

[PATCH v2 3/4] virt: vbox: Use __get_free_pages instead of kmalloc for DMA32 memory

It is not possible to get DMA32 zone memory through kmalloc, causing the vboxguest driver to malfunction due to getting memory above 4G which the PCI device cannot handle. This commit changes the kmalloc calls where the 4G limit matters to using __get_free_pages() fixing vboxguest not working on

[PATCH v2 3/4] virt: vbox: Use __get_free_pages instead of kmalloc for DMA32 memory

It is not possible to get DMA32 zone memory through kmalloc, causing the vboxguest driver to malfunction due to getting memory above 4G which the PCI device cannot handle. This commit changes the kmalloc calls where the 4G limit matters to using __get_free_pages() fixing vboxguest not working on

[PATCH v2 4/4] virt: vbox: Log an error when we fail to get the host version

This was the only error path during probe without a message being logged about what went wrong, this fixes this. Signed-off-by: Hans de Goede --- drivers/virt/vboxguest/vboxguest_core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git

[PATCH v2 4/4] virt: vbox: Log an error when we fail to get the host version

This was the only error path during probe without a message being logged about what went wrong, this fixes this. Signed-off-by: Hans de Goede --- drivers/virt/vboxguest/vboxguest_core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git

[PATCH v2 2/4] virt: vbox: Add vbg_req_free() helper function

This is a preparation patch for fixing issues on x86_64 virtual-machines with more then 4G of RAM, atm we pass __GFP_DMA32 to kmalloc, but kmalloc does not honor that, so we need to switch to get_pages, which means we will not be able to use kfree to free memory allocated with vbg_alloc_req.

[PATCH v2 2/4] virt: vbox: Add vbg_req_free() helper function

This is a preparation patch for fixing issues on x86_64 virtual-machines with more then 4G of RAM, atm we pass __GFP_DMA32 to kmalloc, but kmalloc does not honor that, so we need to switch to get_pages, which means we will not be able to use kfree to free memory allocated with vbg_alloc_req.

Re: [PATCH v7 02/14] fs, dax: prepare for dax-specific address_space_operations

On Wed 21-03-18 15:57:21, Dan Williams wrote: > In preparation for the dax implementation to start associating dax pages > to inodes via page->mapping, we need to provide a 'struct > address_space_operations' instance for dax. Define some generic VFS aops > helpers for dax. These noop

Re: [PATCH v7 02/14] fs, dax: prepare for dax-specific address_space_operations

On Wed 21-03-18 15:57:21, Dan Williams wrote: > In preparation for the dax implementation to start associating dax pages > to inodes via page->mapping, we need to provide a 'struct > address_space_operations' instance for dax. Define some generic VFS aops > helpers for dax. These noop

Re: [PATCH] efi/cper: Remove the INDENT_SP silliness

On 29 March 2018 at 16:14, Borislav Petkov wrote: > From: Borislav Petkov > > A separate define just to print a space character is silly and > completely unneeded. Remove it. > > Signed-off-by: Borislav Petkov > Cc: Ard Biesheuvel

Re: [PATCH] efi/cper: Remove the INDENT_SP silliness

On 29 March 2018 at 16:14, Borislav Petkov wrote: > From: Borislav Petkov > > A separate define just to print a space character is silly and > completely unneeded. Remove it. > > Signed-off-by: Borislav Petkov > Cc: Ard Biesheuvel > Cc: linux-...@vger.kernel.org Acked-by: Ard Biesheuvel

Re: [PATCH v4 1/2] locking/rwsem: Add DEBUG_RWSEMS to look for lock/unlock mismatches

On 03/29/2018 11:01 AM, Davidlohr Bueso wrote: > On Thu, 29 Mar 2018, Waiman Long wrote: > >> Because it checks the owner field which is present only if >> RWSEM_SPIN_ON_OWNER is defined. Mutex is different in the sense that the >> owner field is always there no matter if MUTEX_SPIN_ON_OWNER is

Re: [PATCH v4 1/2] locking/rwsem: Add DEBUG_RWSEMS to look for lock/unlock mismatches

On 03/29/2018 11:01 AM, Davidlohr Bueso wrote: > On Thu, 29 Mar 2018, Waiman Long wrote: > >> Because it checks the owner field which is present only if >> RWSEM_SPIN_ON_OWNER is defined. Mutex is different in the sense that the >> owner field is always there no matter if MUTEX_SPIN_ON_OWNER is

Re: [PATCH v4 1/2] locking/rwsem: Add DEBUG_RWSEMS to look for lock/unlock mismatches

On Thu, 29 Mar 2018, Waiman Long wrote: Because it checks the owner field which is present only if RWSEM_SPIN_ON_OWNER is defined. Mutex is different in the sense that the owner field is always there no matter if MUTEX_SPIN_ON_OWNER is set or not. Ah right; that's after Peter's mutex rewrite

Re: [PATCH v4 1/2] locking/rwsem: Add DEBUG_RWSEMS to look for lock/unlock mismatches

On Thu, 29 Mar 2018, Waiman Long wrote: Because it checks the owner field which is present only if RWSEM_SPIN_ON_OWNER is defined. Mutex is different in the sense that the owner field is always there no matter if MUTEX_SPIN_ON_OWNER is set or not. Ah right; that's after Peter's mutex rewrite

Re: [PATCH] vsprintf: Make "null" pointer dereference more robust

On Fri 2018-03-02 16:17:34, Andy Shevchenko wrote: > On Fri, 2018-03-02 at 13:53 +0100, Petr Mladek wrote: > > %p has many modifiers where the pointer is dereferenced. An invalid > > pointer might cause kernel to crash silently. > > > > Note that printk() formats the string under logbuf_lock. Any

Re: [PATCH] vsprintf: Make "null" pointer dereference more robust

On Fri 2018-03-02 16:17:34, Andy Shevchenko wrote: > On Fri, 2018-03-02 at 13:53 +0100, Petr Mladek wrote: > > %p has many modifiers where the pointer is dereferenced. An invalid > > pointer might cause kernel to crash silently. > > > > Note that printk() formats the string under logbuf_lock. Any

Re: [PATCH v3 0/6] clocksource: rework Atmel TCB timer driver

Hei hei, Am Donnerstag, 29. März 2018, 10:01:26 CEST schrieb Alexander Dahl: > This is the result: > > INTNAME RATE MAX > 17 [vel timer@fffa] 1837 Ints/s (max: 1912) > 26 [ vel eth0] 3 Ints/s (max:11) Above was with

Re: [PATCH v3 0/6] clocksource: rework Atmel TCB timer driver

Hei hei, Am Donnerstag, 29. März 2018, 10:01:26 CEST schrieb Alexander Dahl: > This is the result: > > INTNAME RATE MAX > 17 [vel timer@fffa] 1837 Ints/s (max: 1912) > 26 [ vel eth0] 3 Ints/s (max:11) Above was with

[PATCH v4] x86: i8237: Register based on FADT legacy boot flag

From: Rajneesh Bhardwaj >From Skylake onwards, the platform controller hub (Sunrisepoint PCH) does not support legacy DMA operations to IO ports 81h-83h, 87h, 89h-8Bh, 8Fh. Currently this driver registers as syscore ops and its resume function is called on every

[PATCH v4] x86: i8237: Register based on FADT legacy boot flag

From: Rajneesh Bhardwaj >From Skylake onwards, the platform controller hub (Sunrisepoint PCH) does not support legacy DMA operations to IO ports 81h-83h, 87h, 89h-8Bh, 8Fh. Currently this driver registers as syscore ops and its resume function is called on every resume from S3. On Skylake and

[PATCH v4 3/3] perf script: extend misc field decoding with switch out event type

Append 'p' sign to 'S' tag designating the type of context switch out event so 'Sp' means preemption context switch. Documentation is extended to cover new presentation changes. perf script --show-switch-events -F +misc -I -i perf.data: hdparm 4073 [004] U 762.198265:

[PATCH v4 3/3] perf script: extend misc field decoding with switch out event type

Append 'p' sign to 'S' tag designating the type of context switch out event so 'Sp' means preemption context switch. Documentation is extended to cover new presentation changes. perf script --show-switch-events -F +misc -I -i perf.data: hdparm 4073 [004] U 762.198265:

[PATCH v4 2/3] perf report: extend raw dump (-D) out with switch out event type

Print additional 'preempt' tag for PERF_RECORD_SWITCH[_CPU_WIDE] OUT records when event header misc field contains PERF_RECORD_MISC_SWITCH_OUT_PREEMPT bit set designating preemption context switch out event: tools/perf/perf report -D -i perf.data | grep _SWITCH 0 768361415226 0x27f076 [0x28]:

[PATCH v4 2/3] perf report: extend raw dump (-D) out with switch out event type

Print additional 'preempt' tag for PERF_RECORD_SWITCH[_CPU_WIDE] OUT records when event header misc field contains PERF_RECORD_MISC_SWITCH_OUT_PREEMPT bit set designating preemption context switch out event: tools/perf/perf report -D -i perf.data | grep _SWITCH 0 768361415226 0x27f076 [0x28]:

Re: [PATCH] media: i2c: tvp5150: fix color burst lock instability on some hardware

Em Thu, 29 Mar 2018 19:04:35 +0430 Nasser escreveu: > On Tue, Mar 27, 2018 at 02:59:21AM +0430, Nasser wrote: > Hi Mauro, > > Thank you for taking time to review my patch. > > May be I should rephrase the commit message to something like: > Use the default

Re: [PATCH] media: i2c: tvp5150: fix color burst lock instability on some hardware

Em Thu, 29 Mar 2018 19:04:35 +0430 Nasser escreveu: > On Tue, Mar 27, 2018 at 02:59:21AM +0430, Nasser wrote: > Hi Mauro, > > Thank you for taking time to review my patch. > > May be I should rephrase the commit message to something like: > Use the default register values as suggested in

[PATCH v4 1/3] perf/core: store context switch out type into Perf trace

Store preempting context switch out event into Perf trace as a part of PERF_RECORD_SWITCH[_CPU_WIDE] record. Percentage of preempting and non-preempting context switches help understanding the nature of workloads (CPU or IO bound) that are running on a machine; The event is treated as

[PATCH v4 1/3] perf/core: store context switch out type into Perf trace

Store preempting context switch out event into Perf trace as a part of PERF_RECORD_SWITCH[_CPU_WIDE] record. Percentage of preempting and non-preempting context switches help understanding the nature of workloads (CPU or IO bound) that are running on a machine; The event is treated as

[PATCH 2/2] MIPS: memset.S: Fix return of __clear_user from Lpartial_fixup

The __clear_user function is defined to return the number of bytes that could not be cleared. From the underlying memset / bzero implementation this means setting register a2 to that number on return. Currently if a page fault is triggered within the memset_partial block, the value loaded into a2

[PATCH 2/2] MIPS: memset.S: Fix return of __clear_user from Lpartial_fixup

The __clear_user function is defined to return the number of bytes that could not be cleared. From the underlying memset / bzero implementation this means setting register a2 to that number on return. Currently if a page fault is triggered within the memset_partial block, the value loaded into a2

[tip:perf/core] perf/x86/pt, coresight: Clean up address filter structure

Commit-ID: 6ed70cf342de03c7b11cd4eb032705faeb29d284 Gitweb: https://git.kernel.org/tip/6ed70cf342de03c7b11cd4eb032705faeb29d284 Author: Alexander Shishkin AuthorDate: Thu, 29 Mar 2018 15:06:48 +0300 Committer: Ingo Molnar

[tip:perf/core] perf/x86/pt, coresight: Clean up address filter structure

Commit-ID: 6ed70cf342de03c7b11cd4eb032705faeb29d284 Gitweb: https://git.kernel.org/tip/6ed70cf342de03c7b11cd4eb032705faeb29d284 Author: Alexander Shishkin AuthorDate: Thu, 29 Mar 2018 15:06:48 +0300 Committer: Ingo Molnar CommitDate: Thu, 29 Mar 2018 16:07:22 +0200 perf/x86/pt,

Re: [PATCH] time: export nsec_to_clock_t

On 三, 2018-03-28 at 16:11 +0200, Arnd Bergmann wrote: > nsec_to_clock_t was traditionally used only in the core kernel, now > we > have a sysfs file that needs it from a loadable module, causing a > link-time error: > > ERROR: "nsec_to_clock_t" [drivers/thermal/thermal_sys.ko] undefined! > >

Re: [PATCH] time: export nsec_to_clock_t

On 三, 2018-03-28 at 16:11 +0200, Arnd Bergmann wrote: > nsec_to_clock_t was traditionally used only in the core kernel, now > we > have a sysfs file that needs it from a loadable module, causing a > link-time error: > > ERROR: "nsec_to_clock_t" [drivers/thermal/thermal_sys.ko] undefined! > >

Re: [PATCH net-next 3/8] net: mscc: Add MDIO driver

> > It sounds like the correct fix is for get_phy_id() to look at the > > error code for mdiobus_read(bus, addr, MII_PHYSID1). If it is EIO and > > maybe ENODEV, set *phy_id to 0x and return. The scan code > > should then do the correct thing. > > > > That could work indeed. Do you want

Re: [PATCH net-next 3/8] net: mscc: Add MDIO driver

> > It sounds like the correct fix is for get_phy_id() to look at the > > error code for mdiobus_read(bus, addr, MII_PHYSID1). If it is EIO and > > maybe ENODEV, set *phy_id to 0x and return. The scan code > > should then do the correct thing. > > > > That could work indeed. Do you want

Re: [net-next,v2,01/10] soc: ti: K2G: enhancement to support QMSS in NSS

On 03/28/2018 03:01 PM, Grygorii Strashko wrote: > Hi Murali, > >> >> +enum qmss_version { >> +QMSS, >> +QMSS_LITE, > > QMSS_66AK2G > OK. >> +}; >> + >> struct knav_device { >> struct device *dev; >> unsigned

Re: [net-next,v2,01/10] soc: ti: K2G: enhancement to support QMSS in NSS

On 03/28/2018 03:01 PM, Grygorii Strashko wrote: > Hi Murali, > >> >> +enum qmss_version { >> +QMSS, >> +QMSS_LITE, > > QMSS_66AK2G > OK. >> +}; >> + >> struct knav_device { >> struct device *dev; >> unsigned

Re: [PATCH v3] x86,sched: allow topologies where NUMA nodes share an LLC

On Thu, Mar 29, 2018 at 07:37:29AM -0700, Dave Hansen wrote: > On 03/29/2018 06:47 AM, Peter Zijlstra wrote: > > Further I think Dave argued that we should not change the llc-size, > > because while SNC presents a subset of the cache to local CPUs, for > > remote data the whole cache is still

Re: [PATCH v3] x86,sched: allow topologies where NUMA nodes share an LLC

On Thu, Mar 29, 2018 at 07:37:29AM -0700, Dave Hansen wrote: > On 03/29/2018 06:47 AM, Peter Zijlstra wrote: > > Further I think Dave argued that we should not change the llc-size, > > because while SNC presents a subset of the cache to local CPUs, for > > remote data the whole cache is still

Re: [PATCH v4 1/2] locking/rwsem: Add DEBUG_RWSEMS to look for lock/unlock mismatches

On 03/28/2018 09:32 PM, Davidlohr Bueso wrote: > On Wed, 28 Mar 2018, Waiman Long wrote: > >> +config DEBUG_RWSEMS >> +bool "RW Semaphore debugging: basic checks" >> +depends on DEBUG_KERNEL && RWSEM_SPIN_ON_OWNER > > Why depend on RWSEM_SPIN_ON_OWNER? Doesn't everyone benefit from this? >

Re: [PATCH v4 1/2] locking/rwsem: Add DEBUG_RWSEMS to look for lock/unlock mismatches

On 03/28/2018 09:32 PM, Davidlohr Bueso wrote: > On Wed, 28 Mar 2018, Waiman Long wrote: > >> +config DEBUG_RWSEMS >> +bool "RW Semaphore debugging: basic checks" >> +depends on DEBUG_KERNEL && RWSEM_SPIN_ON_OWNER > > Why depend on RWSEM_SPIN_ON_OWNER? Doesn't everyone benefit from this? >

[RESEND PATCH] Add pixel clock support to OV5640 camera sensor

Some of the camera subsystems like camss in Qualcommm MSM chipsets require pixel clock support in camera sensor drivers for proper functioning. So, add a default pixel clock rate of 96MHz to OV5640 camera sensor driver. According to the datasheet, 96MHz can be used as a pixel clock rate for most

Re: [PATCH 000/109] remove in-kernel calls to syscalls

On Thu, Mar 29, 2018 at 02:46:44PM +, David Laight wrote: > From: Dominik Brodowski > > Sent: 29 March 2018 15:42 > > On Thu, Mar 29, 2018 at 07:20:27AM -0700, Matthew Wilcox wrote: > > > On Thu, Mar 29, 2018 at 01:22:37PM +0200, Dominik Brodowski wrote: > > > > At least on 64-bit x86, it will

[RESEND PATCH] Add pixel clock support to OV5640 camera sensor

Some of the camera subsystems like camss in Qualcommm MSM chipsets require pixel clock support in camera sensor drivers for proper functioning. So, add a default pixel clock rate of 96MHz to OV5640 camera sensor driver. According to the datasheet, 96MHz can be used as a pixel clock rate for most

Re: [PATCH 000/109] remove in-kernel calls to syscalls

On Thu, Mar 29, 2018 at 02:46:44PM +, David Laight wrote: > From: Dominik Brodowski > > Sent: 29 March 2018 15:42 > > On Thu, Mar 29, 2018 at 07:20:27AM -0700, Matthew Wilcox wrote: > > > On Thu, Mar 29, 2018 at 01:22:37PM +0200, Dominik Brodowski wrote: > > > > At least on 64-bit x86, it will

[RESEND PATCH] media: i2c: ov5640: Add pixel clock support

Some of the camera subsystems like camss in Qualcommm MSM chipsets require pixel clock support in camera sensor drivers. So, this commit adds a default pixel clock rate of 96MHz to OV5640 camera sensor driver. According to the datasheet, 96MHz can be used as a pixel clock rate for most of the

[RESEND PATCH] media: i2c: ov5640: Add pixel clock support

Some of the camera subsystems like camss in Qualcommm MSM chipsets require pixel clock support in camera sensor drivers. So, this commit adds a default pixel clock rate of 96MHz to OV5640 camera sensor driver. According to the datasheet, 96MHz can be used as a pixel clock rate for most of the

[PATCH v4 0/3] perf/core: expose thread context switch out event type to user space

Implement preempting context switch out event as a part of PERF_RECORD_SWITCH[_CPU_WIDE] record. The event is treated as preemption one when task->state value of the thread being switched out is TASK_RUNNING; Percentage of preempting and non-preempting context switches help understanding the

[PATCH v4 0/3] perf/core: expose thread context switch out event type to user space

Implement preempting context switch out event as a part of PERF_RECORD_SWITCH[_CPU_WIDE] record. The event is treated as preemption one when task->state value of the thread being switched out is TASK_RUNNING; Percentage of preempting and non-preempting context switches help understanding the

Re: [PATCH net-next 3/8] net: mscc: Add MDIO driver

On 29/03/2018 at 16:40:41 +0200, Andrew Lunn wrote: > > > > + for (i = 0; i < PHY_MAX_ADDR; i++) { > > > > + if (mscc_miim_read(bus, i, MII_PHYSID1) < 0) > > > > + bus->phy_mask |= BIT(i); > > > > + } > > > > > > Why do this? Especially so for the

Re: [PATCH net-next 3/8] net: mscc: Add MDIO driver

On 29/03/2018 at 16:40:41 +0200, Andrew Lunn wrote: > > > > + for (i = 0; i < PHY_MAX_ADDR; i++) { > > > > + if (mscc_miim_read(bus, i, MII_PHYSID1) < 0) > > > > + bus->phy_mask |= BIT(i); > > > > + } > > > > > > Why do this? Especially so for the

Re: [PATCH 10/10] softirq: Remove __ARCH_SET_SOFTIRQ_PENDING

On Thu, 29 Mar 2018 16:07:49 +0200 Frederic Weisbecker wrote: > On Thu, Mar 29, 2018 at 04:01:11PM +0200, Peter Zijlstra wrote: > > On Thu, Mar 29, 2018 at 03:47:46PM +0200, Frederic Weisbecker wrote: > > > On Thu, Mar 29, 2018 at 09:16:19AM +0200, Peter Zijlstra wrote:

Re: [PATCH 10/10] softirq: Remove __ARCH_SET_SOFTIRQ_PENDING

On Thu, 29 Mar 2018 16:07:49 +0200 Frederic Weisbecker wrote: > On Thu, Mar 29, 2018 at 04:01:11PM +0200, Peter Zijlstra wrote: > > On Thu, Mar 29, 2018 at 03:47:46PM +0200, Frederic Weisbecker wrote: > > > On Thu, Mar 29, 2018 at 09:16:19AM +0200, Peter Zijlstra wrote: > > > > On Thu, Mar

Re: [PATCH v3] vsprintf: Prevent crash when dereferencing invalid pointers

On Fri 2018-03-16 20:19:35, Andy Shevchenko wrote: > On Thu, 2018-03-15 at 16:26 +0100, Petr Mladek wrote: > > On Thu 2018-03-15 15:09:03, Andy Shevchenko wrote: > > > On Wed, 2018-03-14 at 15:09 +0100, Petr Mladek wrote: > > > > We already prevent crash when dereferencing some obviously broken >

Re: [PATCH v3] vsprintf: Prevent crash when dereferencing invalid pointers

On Fri 2018-03-16 20:19:35, Andy Shevchenko wrote: > On Thu, 2018-03-15 at 16:26 +0100, Petr Mladek wrote: > > On Thu 2018-03-15 15:09:03, Andy Shevchenko wrote: > > > On Wed, 2018-03-14 at 15:09 +0100, Petr Mladek wrote: > > > > We already prevent crash when dereferencing some obviously broken >

Re: [PATCH v4 7/8] clocksource: Add a new timer-ingenic driver

Le mer. 28 mars 2018 à 18:25, Daniel Lezcano a écrit : On 28/03/2018 17:15, Paul Cercueil wrote: Le 2018-03-24 07:26, Daniel Lezcano a écrit : On 18/03/2018 00:29, Paul Cercueil wrote: This driver will use the TCU (Timer Counter Unit) present on the Ingenic

Re: [PATCH v4 7/8] clocksource: Add a new timer-ingenic driver

Le mer. 28 mars 2018 à 18:25, Daniel Lezcano a écrit : On 28/03/2018 17:15, Paul Cercueil wrote: Le 2018-03-24 07:26, Daniel Lezcano a écrit : On 18/03/2018 00:29, Paul Cercueil wrote: This driver will use the TCU (Timer Counter Unit) present on the Ingenic JZ47xx SoCs to provide the

aacraid code passes GFP_DMA32 to kmalloc this will not work

Hi All, Since I made the same mistake myself I've done a quick grep for GFP_DMA32 in the kernel and drivers/scsi/aacraid/commctrl.c came up as a result of this grep, it does: p = kmalloc(sg_count[i], GFP_KERNEL|GFP_DMA32); But kmalloc always returns memory from

aacraid code passes GFP_DMA32 to kmalloc this will not work

Hi All, Since I made the same mistake myself I've done a quick grep for GFP_DMA32 in the kernel and drivers/scsi/aacraid/commctrl.c came up as a result of this grep, it does: p = kmalloc(sg_count[i], GFP_KERNEL|GFP_DMA32); But kmalloc always returns memory from

[PATCH v5 2/2] mfd: rk808: Add restart functionality

When using Rockchip SoCs with rk805/808/818 PMICs, restarts are realized by setting the reset registers in the "Clock and Reset Unit". Now, the driver can trigger a restart in the PMIC. Like the shutdown function, the restart is bound to an independent "rockchip,system-reset-controller"

[PATCH v5 2/2] mfd: rk808: Add restart functionality

When using Rockchip SoCs with rk805/808/818 PMICs, restarts are realized by setting the reset registers in the "Clock and Reset Unit". Now, the driver can trigger a restart in the PMIC. Like the shutdown function, the restart is bound to an independent "rockchip,system-reset-controller"

[PATCH v5 1/2] mfd: rk808: Refactor shutdown functions

Since all three shutdown functions have almost the same code, all logic from the shutdown functions can be refactored to a new function "rk808_update_bits", which can update a register by a given address and bitmask. Signed-off-by: Daniel Schultz --- Changes: v2:

[PATCH v5 1/2] mfd: rk808: Refactor shutdown functions

Since all three shutdown functions have almost the same code, all logic from the shutdown functions can be refactored to a new function "rk808_update_bits", which can update a register by a given address and bitmask. Signed-off-by: Daniel Schultz --- Changes: v2: Re-submit with

Re: [net-next,v2,01/10] soc: ti: K2G: enhancement to support QMSS in NSS

Hi Grygorii, Thanks for reviewing this! On 03/28/2018 03:01 PM, Grygorii Strashko wrote: > Hi Murali, > > On 03/27/2018 11:31 AM, Murali Karicheri wrote: >> Navigator Subsystem (NSS) available on K2G SoC has a cut down >> version of QMSS with less number of queues, internal linking ram >> with

Re: [net-next,v2,01/10] soc: ti: K2G: enhancement to support QMSS in NSS

Hi Grygorii, Thanks for reviewing this! On 03/28/2018 03:01 PM, Grygorii Strashko wrote: > Hi Murali, > > On 03/27/2018 11:31 AM, Murali Karicheri wrote: >> Navigator Subsystem (NSS) available on K2G SoC has a cut down >> version of QMSS with less number of queues, internal linking ram >> with

RE: [PATCH 000/109] remove in-kernel calls to syscalls

From: Dominik Brodowski > Sent: 29 March 2018 15:42 > On Thu, Mar 29, 2018 at 07:20:27AM -0700, Matthew Wilcox wrote: > > On Thu, Mar 29, 2018 at 01:22:37PM +0200, Dominik Brodowski wrote: > > > At least on 64-bit x86, it will likely be a hard requirement from v4.17 > > > onwards to not call

RE: [PATCH 000/109] remove in-kernel calls to syscalls

From: Dominik Brodowski > Sent: 29 March 2018 15:42 > On Thu, Mar 29, 2018 at 07:20:27AM -0700, Matthew Wilcox wrote: > > On Thu, Mar 29, 2018 at 01:22:37PM +0200, Dominik Brodowski wrote: > > > At least on 64-bit x86, it will likely be a hard requirement from v4.17 > > > onwards to not call

Re: [PATCH] mfd: dt-bindings: Add PMIC reset property

Hi Rob, On 03/18/2018 01:52 PM, Rob Herring wrote: On Thu, Mar 15, 2018 at 11:58:50AM +0100, Daniel Schultz wrote: Add documentation about a new rk808 devicetree property, which can enable resets by the PMIC. The subject needs to be more specific that this is for Rockchip PMIC.

Re: [PATCH] mfd: dt-bindings: Add PMIC reset property

Hi Rob, On 03/18/2018 01:52 PM, Rob Herring wrote: On Thu, Mar 15, 2018 at 11:58:50AM +0100, Daniel Schultz wrote: Add documentation about a new rk808 devicetree property, which can enable resets by the PMIC. The subject needs to be more specific that this is for Rockchip PMIC.

[PATCH v2] mfd: dt-bindings: Add rk808 PMIC reset property

Add documentation about a new rk808 devicetree property. This can enable the rk805/rk808/rk818 PMIC reset, instead of using soft resets from the Control and Reset Module. Signed-off-by: Daniel Schultz --- Changes: v2: Changed commit message

[PATCH v2] mfd: dt-bindings: Add rk808 PMIC reset property

Add documentation about a new rk808 devicetree property. This can enable the rk805/rk808/rk818 PMIC reset, instead of using soft resets from the Control and Reset Module. Signed-off-by: Daniel Schultz --- Changes: v2: Changed commit message

Re: [PATCH net] vhost: validate log when IOTLB is enabled

On Thu, Mar 29, 2018 at 04:00:04PM +0800, Jason Wang wrote: > Vq log_base is the userspace address of bitmap which has nothing to do > with IOTLB. So it needs to be validated unconditionally otherwise we > may try use 0 as log_base which may lead to pin pages that will lead > unexpected result

Re: [PATCH net] vhost: validate log when IOTLB is enabled

On Thu, Mar 29, 2018 at 04:00:04PM +0800, Jason Wang wrote: > Vq log_base is the userspace address of bitmap which has nothing to do > with IOTLB. So it needs to be validated unconditionally otherwise we > may try use 0 as log_base which may lead to pin pages that will lead > unexpected result

[PATCH] cpufreq: schedutil: Prevent unnecessary mutex unlock

This patch prevents the mutex global_tunables_lock from being unlocked before being locked. This mutex is not locked if the function sugov_kthread_create fails. Signed-off-by: Jules Maselbas --- kernel/sched/cpufreq_schedutil.c | 3 +-- 1 file changed, 1 insertion(+), 2

[PATCH] cpufreq: schedutil: Prevent unnecessary mutex unlock

This patch prevents the mutex global_tunables_lock from being unlocked before being locked. This mutex is not locked if the function sugov_kthread_create fails. Signed-off-by: Jules Maselbas --- kernel/sched/cpufreq_schedutil.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff

Re: [PATCH 000/109] remove in-kernel calls to syscalls

On Thu, Mar 29, 2018 at 07:20:27AM -0700, Matthew Wilcox wrote: > On Thu, Mar 29, 2018 at 01:22:37PM +0200, Dominik Brodowski wrote: > > At least on 64-bit x86, it will likely be a hard requirement from v4.17 > > onwards to not call system call functions in the kernel: It is better to > > use use

Re: [PATCH 000/109] remove in-kernel calls to syscalls

On Thu, Mar 29, 2018 at 07:20:27AM -0700, Matthew Wilcox wrote: > On Thu, Mar 29, 2018 at 01:22:37PM +0200, Dominik Brodowski wrote: > > At least on 64-bit x86, it will likely be a hard requirement from v4.17 > > onwards to not call system call functions in the kernel: It is better to > > use use

<    7   8   9   10   11   12   13   14   15   16   >