[PATCH v2 2/5] iio: dac: add support for stm32 DAC

Add support for STMicroelectronics STM32 DAC. It's a 12-bit, voltage output digital-to-analog converter. It has two output channels, each with its own converter. It supports 8 bits or 12bits left/right aligned data format. Only 12bits right-aligned is used here. It has built-in noise or triangle

[PATCH v2 2/5] iio: dac: add support for stm32 DAC

Add support for STMicroelectronics STM32 DAC. It's a 12-bit, voltage output digital-to-analog converter. It has two output channels, each with its own converter. It supports 8 bits or 12bits left/right aligned data format. Only 12bits right-aligned is used here. It has built-in noise or triangle

Re: [PATCH 1/1] gpio: core: Decouple open drain/source flag with active low/high

On Thu, Apr 6, 2017 at 4:35 PM, Laxman Dewangan wrote: > Currently, the GPIO interface is said to Open Drain if it is Single > Ended and active LOW. Similarly, it is said as Open Source if it is > Single Ended and active HIGH. > > The active HIGH/LOW is used in the interface

Re: [PATCH 1/1] gpio: core: Decouple open drain/source flag with active low/high

On Thu, Apr 6, 2017 at 4:35 PM, Laxman Dewangan wrote: > Currently, the GPIO interface is said to Open Drain if it is Single > Ended and active LOW. Similarly, it is said as Open Source if it is > Single Ended and active HIGH. > > The active HIGH/LOW is used in the interface for setting the pin >

Re: [PATCH] arm64: xen: Implement EFI reset_system callback

Hi Julien, On Thu, Apr 06, 2017 at 04:39:13PM +0100, Julien Grall wrote: > Hi Daniel, > > On 06/04/17 16:20, Daniel Kiper wrote: > >On Thu, Apr 06, 2017 at 04:38:24PM +0200, Juergen Gross wrote: > >>On 06/04/17 16:27, Daniel Kiper wrote: > >>>On Thu, Apr 06, 2017 at 09:32:32AM +0100, Julien Grall

Re: [PATCH] arm64: xen: Implement EFI reset_system callback

Hi Julien, On Thu, Apr 06, 2017 at 04:39:13PM +0100, Julien Grall wrote: > Hi Daniel, > > On 06/04/17 16:20, Daniel Kiper wrote: > >On Thu, Apr 06, 2017 at 04:38:24PM +0200, Juergen Gross wrote: > >>On 06/04/17 16:27, Daniel Kiper wrote: > >>>On Thu, Apr 06, 2017 at 09:32:32AM +0100, Julien Grall

Re: [RFC 6/8] nvmet: Be careful about using iomem accesses when dealing with p2pmem

On 05/04/17 11:33 PM, Sagi Grimberg wrote: > >>> Note that the nvme completion queues are still on the host memory, so >>> this means we have lost the ordering between data and completions as >>> they go to different pcie targets. >> >> Hmm, in this simple up/down case with a switch, I think it

Re: [RFC 6/8] nvmet: Be careful about using iomem accesses when dealing with p2pmem

On 05/04/17 11:33 PM, Sagi Grimberg wrote: > >>> Note that the nvme completion queues are still on the host memory, so >>> this means we have lost the ordering between data and completions as >>> they go to different pcie targets. >> >> Hmm, in this simple up/down case with a switch, I think it

Re: [PATCH] [media] imx: csi: retain current field order and colorimetry setting as default

On Thu, 2017-04-06 at 17:43 +0200, Hans Verkuil wrote: > On 04/06/2017 04:54 PM, Philipp Zabel wrote: > > On Thu, 2017-04-06 at 16:20 +0200, Hans Verkuil wrote: > >> On 04/06/2017 03:55 PM, Philipp Zabel wrote: > >>> If the the field order is set to ANY in set_fmt, choose the currently > >>> set

Re: [PATCH] [media] imx: csi: retain current field order and colorimetry setting as default

On Thu, 2017-04-06 at 17:43 +0200, Hans Verkuil wrote: > On 04/06/2017 04:54 PM, Philipp Zabel wrote: > > On Thu, 2017-04-06 at 16:20 +0200, Hans Verkuil wrote: > >> On 04/06/2017 03:55 PM, Philipp Zabel wrote: > >>> If the the field order is set to ANY in set_fmt, choose the currently > >>> set

Re: [PATCH 1/5] bh: Prevent panic on invalid BHs

Christoph Hellwig writes: > This look ok, but how did you manage to trigger this case? # testcases # TEST1 # Via bug in fallocate truncate -l 1G img losetup /dev/loop img mkfs.ext4 -qF /dev/loop0 mkdir m mount /dev/loop0 m # command above truncate bdevs pagecache xfs_io -c

Re: [PATCH 1/5] bh: Prevent panic on invalid BHs

Christoph Hellwig writes: > This look ok, but how did you manage to trigger this case? # testcases # TEST1 # Via bug in fallocate truncate -l 1G img losetup /dev/loop img mkfs.ext4 -qF /dev/loop0 mkdir m mount /dev/loop0 m # command above truncate bdevs pagecache xfs_io -c "falloc -k 0 32G"

Re: [PATCH] x86/vdso: ensure vdso32_enabled gets set to valid values only

On Wed, Apr 5, 2017 at 1:36 PM, Mathias Krause wrote: > If either via kernel command line 'vdso32=' or via 'sysctl abi.vsyscall32' > vdso32_enabled gets set to a value below 0 or above 1, load_vdso32() won't > map the vDSO but ARCH_DLINFO_IA32 would still pass an

Re: [PATCH] x86/vdso: ensure vdso32_enabled gets set to valid values only

On Wed, Apr 5, 2017 at 1:36 PM, Mathias Krause wrote: > If either via kernel command line 'vdso32=' or via 'sysctl abi.vsyscall32' > vdso32_enabled gets set to a value below 0 or above 1, load_vdso32() won't > map the vDSO but ARCH_DLINFO_IA32 would still pass an AT_SYSINFO_EHDR > auxiliary

[PATCH] drm/virtio: don't leak bo on drm_gem_object_init failure

Reported-by: 李强 Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/virtio/virtgpu_object.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c b/drivers/gpu/drm/virtio/virtgpu_object.c index

[PATCH] drm/virtio: don't leak bo on drm_gem_object_init failure

Reported-by: 李强 Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/virtio/virtgpu_object.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c b/drivers/gpu/drm/virtio/virtgpu_object.c index 1483dae..6f66b73 100644 ---

Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Wed, Apr 5, 2017 at 5:14 PM, Kees Cook wrote: > On Wed, Apr 5, 2017 at 4:57 PM, Andy Lutomirski wrote: >> On Wed, Mar 29, 2017 at 6:41 PM, Kees Cook wrote: >>> On Wed, Mar 29, 2017 at 3:38 PM, Andy Lutomirski

Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Wed, Apr 5, 2017 at 5:14 PM, Kees Cook wrote: > On Wed, Apr 5, 2017 at 4:57 PM, Andy Lutomirski wrote: >> On Wed, Mar 29, 2017 at 6:41 PM, Kees Cook wrote: >>> On Wed, Mar 29, 2017 at 3:38 PM, Andy Lutomirski >>> wrote: On Wed, Mar 29, 2017 at 11:15 AM, Kees Cook wrote: > Based

[PATCH v2] MIPS: Malta: Fix i8259 irqchip setup

Since commit 4cfffcfa5106 ("irqchip/mips-gic: Fix local interrupts"), the gic driver has been allocating virq's for local interrupts during its initialisation. Unfortunately on Malta platforms, these are the first IRQs to be allocated and so are allocated virqs 1-3. The i8259 driver uses a legacy

[PATCH v2] MIPS: Malta: Fix i8259 irqchip setup

Since commit 4cfffcfa5106 ("irqchip/mips-gic: Fix local interrupts"), the gic driver has been allocating virq's for local interrupts during its initialisation. Unfortunately on Malta platforms, these are the first IRQs to be allocated and so are allocated virqs 1-3. The i8259 driver uses a legacy

Re: [PATCH -v6 05/13] futex: Change locking rules

On Thu, 2017-04-06 at 14:28 +0200, Peter Zijlstra wrote: > On Wed, Apr 05, 2017 at 02:18:43PM -0700, Darren Hart wrote: > > On Wed, Mar 22, 2017 at 11:35:52AM +0100, Peter Zijlstra wrote: > > > @@ -1336,6 +1418,7 @@ static int wake_futex_pi(u32 __user *uad > > > > > > if

Re: [PATCH -v6 05/13] futex: Change locking rules

On Thu, 2017-04-06 at 14:28 +0200, Peter Zijlstra wrote: > On Wed, Apr 05, 2017 at 02:18:43PM -0700, Darren Hart wrote: > > On Wed, Mar 22, 2017 at 11:35:52AM +0100, Peter Zijlstra wrote: > > > @@ -1336,6 +1418,7 @@ static int wake_futex_pi(u32 __user *uad > > > > > > if

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Thu, Apr 06, 2017 at 12:52:13PM +0530, Imran Khan wrote: > On 4/5/2017 10:13 AM, Imran Khan wrote: > >> We may have to revisit this logic and consider L1_CACHE_BYTES the > >> _minimum_ of cache line sizes in arm64 systems supported by the kernel. > >> Do you have any benchmarks on Cavium boards

Re: [PATCH] Revert "arm64: Increase the max granular size"

On Thu, Apr 06, 2017 at 12:52:13PM +0530, Imran Khan wrote: > On 4/5/2017 10:13 AM, Imran Khan wrote: > >> We may have to revisit this logic and consider L1_CACHE_BYTES the > >> _minimum_ of cache line sizes in arm64 systems supported by the kernel. > >> Do you have any benchmarks on Cavium boards

Re: [PATCH v4] tools/perf: Allow user probes on versioned symbols

On 04/06/2017 09:36 AM, Arnaldo Carvalho de Melo wrote: Em Wed, Apr 05, 2017 at 10:30:03PM -0500, Paul Clarke escreveu: Symbol versioning, as in glibc, results in symbols being defined as: @[@] (Note that "@@" identifies a default symbol, if the symbol name is repeated.) perf is currently

Re: [PATCH v4] tools/perf: Allow user probes on versioned symbols

On 04/06/2017 09:36 AM, Arnaldo Carvalho de Melo wrote: Em Wed, Apr 05, 2017 at 10:30:03PM -0500, Paul Clarke escreveu: Symbol versioning, as in glibc, results in symbols being defined as: @[@] (Note that "@@" identifies a default symbol, if the symbol name is repeated.) perf is currently

Re: [PATCH 7/8] x86: Enable 5-level paging support

On 06/04/17 17:24, Kirill A. Shutemov wrote: > On Thu, Apr 06, 2017 at 04:52:11PM +0200, Juergen Gross wrote: >> On 06/04/17 16:01, Kirill A. Shutemov wrote: >>> Most of things are in place and we can enable support of 5-level paging. >>> >>> Enabling XEN with 5-level paging requires more work.

Re: [PATCH 7/8] x86: Enable 5-level paging support

On 06/04/17 17:24, Kirill A. Shutemov wrote: > On Thu, Apr 06, 2017 at 04:52:11PM +0200, Juergen Gross wrote: >> On 06/04/17 16:01, Kirill A. Shutemov wrote: >>> Most of things are in place and we can enable support of 5-level paging. >>> >>> Enabling XEN with 5-level paging requires more work.

Re: scope of cred_guard_mutex.

On 04/03, Eric W. Biederman wrote: > > Oleg Nesterov writes: > > >> I reviewed the code and cred_guard_mutex needs to cover what it covers. > > > > I strongly, strongly disagree. Its scope is unnecessary huge, we should > > narrow > > it in any case, even if the current code was

Re: scope of cred_guard_mutex.

On 04/03, Eric W. Biederman wrote: > > Oleg Nesterov writes: > > >> I reviewed the code and cred_guard_mutex needs to cover what it covers. > > > > I strongly, strongly disagree. Its scope is unnecessary huge, we should > > narrow > > it in any case, even if the current code was not bugy. But

Re: [PATCH] arm64: xen: Implement EFI reset_system callback

[Adding the EFI maintainers] Tl;DR: Xen's EFI wrappery doesn't implement reset_system, so when invoked on arm64 we get a NULL dereference. On Thu, Apr 06, 2017 at 04:39:13PM +0100, Julien Grall wrote: > On 06/04/17 16:20, Daniel Kiper wrote: > >On Thu, Apr 06, 2017 at 04:38:24PM +0200, Juergen

Re: [PATCH] arm64: xen: Implement EFI reset_system callback

[Adding the EFI maintainers] Tl;DR: Xen's EFI wrappery doesn't implement reset_system, so when invoked on arm64 we get a NULL dereference. On Thu, Apr 06, 2017 at 04:39:13PM +0100, Julien Grall wrote: > On 06/04/17 16:20, Daniel Kiper wrote: > >On Thu, Apr 06, 2017 at 04:38:24PM +0200, Juergen

Re: [RFC 3/8] nvmet: Use p2pmem in nvme target

Hey Sagi, On 05/04/17 11:47 PM, Sagi Grimberg wrote: > Because the user can get it wrong, and its our job to do what we can in > order to prevent the user from screwing itself. Well, "screwing" themselves seems a bit strong. It wouldn't be much different from a lot of other tunables in the

Re: [RFC 3/8] nvmet: Use p2pmem in nvme target

Hey Sagi, On 05/04/17 11:47 PM, Sagi Grimberg wrote: > Because the user can get it wrong, and its our job to do what we can in > order to prevent the user from screwing itself. Well, "screwing" themselves seems a bit strong. It wouldn't be much different from a lot of other tunables in the

[GIT PULL] ring-buffer: Fix return value check in test_ringbuffer()

Linus, Wei Yongjun fixed a long standing bug in the ring buffer startup test. If for some unknown reason, the kthread that is created fails to be created, the return from kthread_create() is an PTR_ERR and not a NULL. The test incorrectly checks for NULL instead of an error. Please pull the

[GIT PULL] ring-buffer: Fix return value check in test_ringbuffer()

Linus, Wei Yongjun fixed a long standing bug in the ring buffer startup test. If for some unknown reason, the kthread that is created fails to be created, the return from kthread_create() is an PTR_ERR and not a NULL. The test incorrectly checks for NULL instead of an error. Please pull the

Re: [PATCH 5/5] block: truncate page cache only when necessary on fallocate

Christoph Hellwig writes: > why? because it is not good thing to truncate page cache and fiew lines later realize that feature is not supported !blk_queue_discard(q) and return ENOTSUPP. Event more: if mode == FALLOC_FL_KEEP_SIZE then we do nothing and return ENOTSUPP

Re: [PATCH 5/5] block: truncate page cache only when necessary on fallocate

Christoph Hellwig writes: > why? because it is not good thing to truncate page cache and fiew lines later realize that feature is not supported !blk_queue_discard(q) and return ENOTSUPP. Event more: if mode == FALLOC_FL_KEEP_SIZE then we do nothing and return ENOTSUPP unconditionally. IMHO

Re: [PATCH v2] Extend pca9532 device tree support

Hi! > > diff --git a/Documentation/devicetree/bindings/leds/leds-pca9532.txt > > b/Documentation/devicetree/bindings/leds/leds-pca9532.txt > > index 198f3ba..8374075 100644 > > --- a/Documentation/devicetree/bindings/leds/leds-pca9532.txt > > +++

Re: [PATCH v2] Extend pca9532 device tree support

Hi! > > diff --git a/Documentation/devicetree/bindings/leds/leds-pca9532.txt > > b/Documentation/devicetree/bindings/leds/leds-pca9532.txt > > index 198f3ba..8374075 100644 > > --- a/Documentation/devicetree/bindings/leds/leds-pca9532.txt > > +++

Re: [RFC][PATCH v2 5/5] signal: Don't allow accessing signal_struct by old threads after exec

On 04/05, Eric W. Biederman wrote: > > Oleg Nesterov writes: > > >> --- a/kernel/signal.c > >> +++ b/kernel/signal.c > >> @@ -995,6 +995,10 @@ static int __send_signal(int sig, struct siginfo > >> *info, struct task_struct *t, > >>from_ancestor_ns || (info ==

Re: [RFC][PATCH v2 5/5] signal: Don't allow accessing signal_struct by old threads after exec

On 04/05, Eric W. Biederman wrote: > > Oleg Nesterov writes: > > >> --- a/kernel/signal.c > >> +++ b/kernel/signal.c > >> @@ -995,6 +995,10 @@ static int __send_signal(int sig, struct siginfo > >> *info, struct task_struct *t, > >>from_ancestor_ns || (info ==

Re: [PATCH 0/6] mm: make movable onlining suck less

On Thu, Apr 06, 2017 at 05:41:28PM +0200, Michal Hocko wrote: On Thu 06-04-17 10:24:49, Reza Arbab wrote: On Thu, Apr 06, 2017 at 03:08:46PM +0200, Michal Hocko wrote: >OK, so after recent change mostly driven by testing from Reza Arbab >(thanks again) I believe I am getting to a working state

Re: [PATCH 0/6] mm: make movable onlining suck less

On Thu, Apr 06, 2017 at 05:41:28PM +0200, Michal Hocko wrote: On Thu 06-04-17 10:24:49, Reza Arbab wrote: On Thu, Apr 06, 2017 at 03:08:46PM +0200, Michal Hocko wrote: >OK, so after recent change mostly driven by testing from Reza Arbab >(thanks again) I believe I am getting to a working state

Re: [PATCH] [media] imx: csi: retain current field order and colorimetry setting as default

On 04/06/2017 04:54 PM, Philipp Zabel wrote: > On Thu, 2017-04-06 at 16:20 +0200, Hans Verkuil wrote: >> On 04/06/2017 03:55 PM, Philipp Zabel wrote: >>> If the the field order is set to ANY in set_fmt, choose the currently >>> set field order. If the colorspace is set to DEFAULT, choose the

Re: [PATCH] [media] imx: csi: retain current field order and colorimetry setting as default

On 04/06/2017 04:54 PM, Philipp Zabel wrote: > On Thu, 2017-04-06 at 16:20 +0200, Hans Verkuil wrote: >> On 04/06/2017 03:55 PM, Philipp Zabel wrote: >>> If the the field order is set to ANY in set_fmt, choose the currently >>> set field order. If the colorspace is set to DEFAULT, choose the

Re: [PATCH 5/5] block: truncate page cache only when necessary on fallocate

why? On Thu, Apr 06, 2017 at 04:02:49PM +0400, Dmitry Monakhov wrote: > Signed-off-by: Dmitry Monakhov > --- > fs/block_dev.c | 9 - > 1 file changed, 4 insertions(+), 5 deletions(-) > > diff --git a/fs/block_dev.c b/fs/block_dev.c > index 2eca00e..f4b13e1 100644

Re: [PATCH 5/5] block: truncate page cache only when necessary on fallocate

why? On Thu, Apr 06, 2017 at 04:02:49PM +0400, Dmitry Monakhov wrote: > Signed-off-by: Dmitry Monakhov > --- > fs/block_dev.c | 9 - > 1 file changed, 4 insertions(+), 5 deletions(-) > > diff --git a/fs/block_dev.c b/fs/block_dev.c > index 2eca00e..f4b13e1 100644 > --- a/fs/block_dev.c

Re: [PATCH 1/5] bh: Prevent panic on invalid BHs

This look ok, but how did you manage to trigger this case? I think we might have a deeper problem here.

Re: [PATCH 1/5] bh: Prevent panic on invalid BHs

This look ok, but how did you manage to trigger this case? I think we might have a deeper problem here.

Re: [Patch V2 2/2] x86/mm/numa: remove the numa_nodemask_from_meminfo()

On Thu, Apr 06, 2017 at 04:59:37PM +0200, Borislav Petkov wrote: > On Thu, Apr 06, 2017 at 03:44:59PM +0300, Kirill A. Shutemov wrote: > > I've got the crash below on master/tip. Reveting the patch helps. > > > > > >

Re: [Patch V2 2/2] x86/mm/numa: remove the numa_nodemask_from_meminfo()

On Thu, Apr 06, 2017 at 04:59:37PM +0200, Borislav Petkov wrote: > On Thu, Apr 06, 2017 at 03:44:59PM +0300, Kirill A. Shutemov wrote: > > I've got the crash below on master/tip. Reveting the patch helps. > > > > > >

Re: [PATCH 0/6] mm: make movable onlining suck less

On Thu 06-04-17 10:24:49, Reza Arbab wrote: > On Thu, Apr 06, 2017 at 03:08:46PM +0200, Michal Hocko wrote: > >OK, so after recent change mostly driven by testing from Reza Arbab > >(thanks again) I believe I am getting to a working state finally. All I > >currently have is > >in

Re: [PATCH 0/6] mm: make movable onlining suck less

On Thu 06-04-17 10:24:49, Reza Arbab wrote: > On Thu, Apr 06, 2017 at 03:08:46PM +0200, Michal Hocko wrote: > >OK, so after recent change mostly driven by testing from Reza Arbab > >(thanks again) I believe I am getting to a working state finally. All I > >currently have is > >in

Re: [PATCH] arm64: xen: Implement EFI reset_system callback

Hi Daniel, On 06/04/17 16:20, Daniel Kiper wrote: On Thu, Apr 06, 2017 at 04:38:24PM +0200, Juergen Gross wrote: On 06/04/17 16:27, Daniel Kiper wrote: On Thu, Apr 06, 2017 at 09:32:32AM +0100, Julien Grall wrote: Hi Juergen, On 06/04/17 07:23, Juergen Gross wrote: On 05/04/17 21:49, Boris

Re: [PATCH] arm64: xen: Implement EFI reset_system callback

Hi Daniel, On 06/04/17 16:20, Daniel Kiper wrote: On Thu, Apr 06, 2017 at 04:38:24PM +0200, Juergen Gross wrote: On 06/04/17 16:27, Daniel Kiper wrote: On Thu, Apr 06, 2017 at 09:32:32AM +0100, Julien Grall wrote: Hi Juergen, On 06/04/17 07:23, Juergen Gross wrote: On 05/04/17 21:49, Boris

Re: [PATCH v6] vfio error recovery: kernel support

On Thu, 6 Apr 2017 16:53:44 +0800 Cao jin wrote: > On 04/06/2017 06:36 AM, Michael S. Tsirkin wrote: > > On Wed, Apr 05, 2017 at 04:19:10PM -0600, Alex Williamson wrote: > >> On Thu, 6 Apr 2017 00:50:22 +0300 > >> "Michael S. Tsirkin" wrote: > >> >

Re: [PATCH v6] vfio error recovery: kernel support

On Thu, 6 Apr 2017 16:53:44 +0800 Cao jin wrote: > On 04/06/2017 06:36 AM, Michael S. Tsirkin wrote: > > On Wed, Apr 05, 2017 at 04:19:10PM -0600, Alex Williamson wrote: > >> On Thu, 6 Apr 2017 00:50:22 +0300 > >> "Michael S. Tsirkin" wrote: > >> > >>> On Wed, Apr 05, 2017 at 01:38:22PM

Re: [PATCH v6] vfio error recovery: kernel support

On Thu, 6 Apr 2017 16:49:35 +0800 Cao jin wrote: > On 04/06/2017 05:56 AM, Michael S. Tsirkin wrote: > > On Wed, Apr 05, 2017 at 04:54:33PM +0800, Cao jin wrote: > >> Apparently, I don't have experience to induce non-fatal error, device > >> error is more of a chance

Re: [PATCH v6] vfio error recovery: kernel support

On Thu, 6 Apr 2017 16:49:35 +0800 Cao jin wrote: > On 04/06/2017 05:56 AM, Michael S. Tsirkin wrote: > > On Wed, Apr 05, 2017 at 04:54:33PM +0800, Cao jin wrote: > >> Apparently, I don't have experience to induce non-fatal error, device > >> error is more of a chance related with the

Re: [PATCH] staging: android: ashmem: lseek failed due to no FMODE_LSEEK.

On 04/06/2017 07:30 AM, zhangshuxia...@gmail.com wrote: From: zhangshuxiao vfs_llseek will check whether the file mode has FMODE_LSEEK, no return failure. But ashmem can be lseek, so add FMODE_LSEEK to ashmem file. Signed-off-by: Shuxiao Zhang

Re: [PATCH] staging: android: ashmem: lseek failed due to no FMODE_LSEEK.

On 04/06/2017 07:30 AM, zhangshuxia...@gmail.com wrote: From: zhangshuxiao vfs_llseek will check whether the file mode has FMODE_LSEEK, no return failure. But ashmem can be lseek, so add FMODE_LSEEK to ashmem file. Signed-off-by: Shuxiao Zhang Tested-by: Greg Hackmann ---

Re: [RFC][PATCH] spin loop arch primitives for busy waiting

On Thu, 6 Apr 2017 15:13:53 +0100 Will Deacon wrote: > Hi Nick, > > On Thu, Apr 06, 2017 at 10:59:58AM +1000, Nicholas Piggin wrote: > > On Wed, 05 Apr 2017 07:01:57 -0700 (PDT) > > David Miller wrote: > > > > > From: Nicholas Piggin

Re: [RFC][PATCH] spin loop arch primitives for busy waiting

On Thu, 6 Apr 2017 15:13:53 +0100 Will Deacon wrote: > Hi Nick, > > On Thu, Apr 06, 2017 at 10:59:58AM +1000, Nicholas Piggin wrote: > > On Wed, 05 Apr 2017 07:01:57 -0700 (PDT) > > David Miller wrote: > > > > > From: Nicholas Piggin > > > Date: Tue, 4 Apr 2017 13:02:33 +1000 > > > > >

Re: [PATCH] [media] imx: csi: retain current field order and colorimetry setting as default

On Thu, 2017-04-06 at 16:10 +0100, Russell King - ARM Linux wrote: > On Thu, Apr 06, 2017 at 05:01:52PM +0200, Philipp Zabel wrote: > > On Thu, 2017-04-06 at 15:05 +0100, Russell King - ARM Linux wrote: > > > On Thu, Apr 06, 2017 at 03:55:29PM +0200, Philipp Zabel wrote: > > > > + > > > > +

Re: [PATCH V3 3/4] pwm: tegra: Add DT binding details to configure pin in suspends/resume

On 06/04/17 15:21, Laxman Dewangan wrote: > In some of NVIDIA Tegra's platform, PWM controller is used to > control the PWM controlled regulators. PWM signal is connected to > the VID pin of the regulator where duty cycle of PWM signal decide > the voltage level of the regulator output. > > The

Re: [PATCH] [media] imx: csi: retain current field order and colorimetry setting as default

On Thu, 2017-04-06 at 16:10 +0100, Russell King - ARM Linux wrote: > On Thu, Apr 06, 2017 at 05:01:52PM +0200, Philipp Zabel wrote: > > On Thu, 2017-04-06 at 15:05 +0100, Russell King - ARM Linux wrote: > > > On Thu, Apr 06, 2017 at 03:55:29PM +0200, Philipp Zabel wrote: > > > > + > > > > +

Re: [PATCH V3 3/4] pwm: tegra: Add DT binding details to configure pin in suspends/resume

On 06/04/17 15:21, Laxman Dewangan wrote: > In some of NVIDIA Tegra's platform, PWM controller is used to > control the PWM controlled regulators. PWM signal is connected to > the VID pin of the regulator where duty cycle of PWM signal decide > the voltage level of the regulator output. > > The

Re: [PATCH 0/6] mm: make movable onlining suck less

On Thu, Apr 06, 2017 at 03:08:46PM +0200, Michal Hocko wrote: OK, so after recent change mostly driven by testing from Reza Arbab (thanks again) I believe I am getting to a working state finally. All I currently have is in git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git tree

Re: [PATCH 0/6] mm: make movable onlining suck less

On Thu, Apr 06, 2017 at 03:08:46PM +0200, Michal Hocko wrote: OK, so after recent change mostly driven by testing from Reza Arbab (thanks again) I believe I am getting to a working state finally. All I currently have is in git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git tree

Re: [PATCH 7/8] x86: Enable 5-level paging support

On Thu, Apr 06, 2017 at 04:52:11PM +0200, Juergen Gross wrote: > On 06/04/17 16:01, Kirill A. Shutemov wrote: > > Most of things are in place and we can enable support of 5-level paging. > > > > Enabling XEN with 5-level paging requires more work. The patch makes XEN > > dependent on !X86_5LEVEL.

Re: [PATCH 7/8] x86: Enable 5-level paging support

On Thu, Apr 06, 2017 at 04:52:11PM +0200, Juergen Gross wrote: > On 06/04/17 16:01, Kirill A. Shutemov wrote: > > Most of things are in place and we can enable support of 5-level paging. > > > > Enabling XEN with 5-level paging requires more work. The patch makes XEN > > dependent on !X86_5LEVEL.

Re: [PATCH] arm64: xen: Implement EFI reset_system callback

On Thu, Apr 06, 2017 at 04:38:24PM +0200, Juergen Gross wrote: > On 06/04/17 16:27, Daniel Kiper wrote: > > On Thu, Apr 06, 2017 at 09:32:32AM +0100, Julien Grall wrote: > >> Hi Juergen, > >> > >> On 06/04/17 07:23, Juergen Gross wrote: > >>> On 05/04/17 21:49, Boris Ostrovsky wrote: > On

Re: [PATCH] arm64: xen: Implement EFI reset_system callback

On Thu, Apr 06, 2017 at 04:38:24PM +0200, Juergen Gross wrote: > On 06/04/17 16:27, Daniel Kiper wrote: > > On Thu, Apr 06, 2017 at 09:32:32AM +0100, Julien Grall wrote: > >> Hi Juergen, > >> > >> On 06/04/17 07:23, Juergen Gross wrote: > >>> On 05/04/17 21:49, Boris Ostrovsky wrote: > On

Re: [PATCH v6 1/6] platform/x86: intel_pmc_ipc: fix gcr offset

On Wed, Apr 05, 2017 at 03:54:19PM -0700, Kuppuswamy Sathyanarayanan wrote: > According to Broxton APL PMC spec, gcr mem region starts > at offset 0x1000 from ipc mem base address. In this driver, > PLAT_RESOURCE_GCR_OFFSET macro defines the offset of GCR > memory region from IPC mem region. So we

Re: [PATCH v6 1/6] platform/x86: intel_pmc_ipc: fix gcr offset

On Wed, Apr 05, 2017 at 03:54:19PM -0700, Kuppuswamy Sathyanarayanan wrote: > According to Broxton APL PMC spec, gcr mem region starts > at offset 0x1000 from ipc mem base address. In this driver, > PLAT_RESOURCE_GCR_OFFSET macro defines the offset of GCR > memory region from IPC mem region. So we

Re: [PATCH] [media] imx: csi: retain current field order and colorimetry setting as default

On Thu, 2017-04-06 at 16:20 +0200, Hans Verkuil wrote: > On 04/06/2017 03:55 PM, Philipp Zabel wrote: > > If the the field order is set to ANY in set_fmt, choose the currently > > set field order. If the colorspace is set to DEFAULT, choose the current > > colorspace. If any of xfer_func,

Re: [PATCH] [media] imx: csi: retain current field order and colorimetry setting as default

On Thu, 2017-04-06 at 16:20 +0200, Hans Verkuil wrote: > On 04/06/2017 03:55 PM, Philipp Zabel wrote: > > If the the field order is set to ANY in set_fmt, choose the currently > > set field order. If the colorspace is set to DEFAULT, choose the current > > colorspace. If any of xfer_func,

Re: [PATCH V4 4/4] pwm: tegra: Add support to configure pin state in suspends/resume

On 06/04/17 15:21, Laxman Dewangan wrote: > In some of NVIDIA Tegra's platform, PWM controller is used to > control the PWM controlled regulators. PWM signal is connected to > the VID pin of the regulator where duty cycle of PWM signal decide > the voltage level of the regulator output. > > The

Re: [PATCH V4 4/4] pwm: tegra: Add support to configure pin state in suspends/resume

On 06/04/17 15:21, Laxman Dewangan wrote: > In some of NVIDIA Tegra's platform, PWM controller is used to > control the PWM controlled regulators. PWM signal is connected to > the VID pin of the regulator where duty cycle of PWM signal decide > the voltage level of the regulator output. > > The

Re: [RFC][PATCH] spin loop arch primitives for busy waiting

On Thu, Apr 6, 2017 at 7:13 AM, Will Deacon wrote: > > We've wrapped this up in the arm64 code as __cmpwait, and we use that > to build smp_cond_load_acquire. It would be nice to use the same machinery > for the conditional spinning here, unless you anticipate that we're only

Re: [RFC][PATCH] spin loop arch primitives for busy waiting

On Thu, Apr 6, 2017 at 7:13 AM, Will Deacon wrote: > > We've wrapped this up in the arm64 code as __cmpwait, and we use that > to build smp_cond_load_acquire. It would be nice to use the same machinery > for the conditional spinning here, unless you anticipate that we're only > going to be

Re: [PATCH] [media] imx: csi: retain current field order and colorimetry setting as default

On Thu, Apr 06, 2017 at 05:01:52PM +0200, Philipp Zabel wrote: > On Thu, 2017-04-06 at 15:05 +0100, Russell King - ARM Linux wrote: > > On Thu, Apr 06, 2017 at 03:55:29PM +0200, Philipp Zabel wrote: > > > + > > > + /* Retain current field setting as default */ > > > + if (sdformat->format.field ==

Re: [PATCH] [media] imx: csi: retain current field order and colorimetry setting as default

On Thu, Apr 06, 2017 at 05:01:52PM +0200, Philipp Zabel wrote: > On Thu, 2017-04-06 at 15:05 +0100, Russell King - ARM Linux wrote: > > On Thu, Apr 06, 2017 at 03:55:29PM +0200, Philipp Zabel wrote: > > > + > > > + /* Retain current field setting as default */ > > > + if (sdformat->format.field ==

Re: [PATCH] [media] imx: csi: retain current field order and colorimetry setting as default

On Thu, 2017-04-06 at 15:05 +0100, Russell King - ARM Linux wrote: > On Thu, Apr 06, 2017 at 03:55:29PM +0200, Philipp Zabel wrote: > > + > > + /* Retain current field setting as default */ > > + if (sdformat->format.field == V4L2_FIELD_ANY) > > + sdformat->format.field = fmt->field;

Re: [PATCH] [media] imx: csi: retain current field order and colorimetry setting as default

On Thu, 2017-04-06 at 15:05 +0100, Russell King - ARM Linux wrote: > On Thu, Apr 06, 2017 at 03:55:29PM +0200, Philipp Zabel wrote: > > + > > + /* Retain current field setting as default */ > > + if (sdformat->format.field == V4L2_FIELD_ANY) > > + sdformat->format.field = fmt->field;

Re: [Patch V2 2/2] x86/mm/numa: remove the numa_nodemask_from_meminfo()

On Thu, Apr 06, 2017 at 03:44:59PM +0300, Kirill A. Shutemov wrote: > I've got the crash below on master/tip. Reveting the patch helps. > > > UBSAN: Undefined behaviour in /home/kas/linux/la57/mm/sparse.c:336:9 >

Re: [Patch V2 2/2] x86/mm/numa: remove the numa_nodemask_from_meminfo()

On Thu, Apr 06, 2017 at 03:44:59PM +0300, Kirill A. Shutemov wrote: > I've got the crash below on master/tip. Reveting the patch helps. > > > UBSAN: Undefined behaviour in /home/kas/linux/la57/mm/sparse.c:336:9 >

Re: [BUG] stack tracing causes: kernel/module.c:271 module_assert_mutex_or_preempt

On Thu, Apr 06, 2017 at 10:14:25AM -0400, Steven Rostedt wrote: > On Wed, 5 Apr 2017 21:15:15 -0700 > "Paul E. McKenney" wrote: > \> > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c > > > index 8efd9fe..28e3019 100644 > > > --- a/kernel/trace/ftrace.c > > >

Re: [BUG] stack tracing causes: kernel/module.c:271 module_assert_mutex_or_preempt

On Thu, Apr 06, 2017 at 10:14:25AM -0400, Steven Rostedt wrote: > On Wed, 5 Apr 2017 21:15:15 -0700 > "Paul E. McKenney" wrote: > \> > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c > > > index 8efd9fe..28e3019 100644 > > > --- a/kernel/trace/ftrace.c > > > +++ b/kernel/trace/ftrace.c

[PATCH -mm 5/5] fault-inject: add /proc//fail-nth

fail-nth interface is only created in /proc/self/task//. This change also adds it in /proc//. This makes shell based tool a bit simpler. $ bash -c "builtin echo 100 > /proc/self/fail-nth && exec ls /" Cc: Dmitry Vyukov Signed-off-by: Akinobu Mita

[PATCH -mm 5/5] fault-inject: add /proc//fail-nth

fail-nth interface is only created in /proc/self/task//. This change also adds it in /proc//. This makes shell based tool a bit simpler. $ bash -c "builtin echo 100 > /proc/self/fail-nth && exec ls /" Cc: Dmitry Vyukov Signed-off-by: Akinobu Mita ---

[PATCH -mm 1/5] fault-inject: automatically detect the number base for fail-nth write interface

Automatically detect the number base to use when writing to fail-nth file instead of always parsing as a decimal number. Cc: Dmitry Vyukov Signed-off-by: Akinobu Mita --- fs/proc/base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH -mm 1/5] fault-inject: automatically detect the number base for fail-nth write interface

Automatically detect the number base to use when writing to fail-nth file instead of always parsing as a decimal number. Cc: Dmitry Vyukov Signed-off-by: Akinobu Mita --- fs/proc/base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/proc/base.c b/fs/proc/base.c index

[PATCH -mm 4/5] fault-inject: simplify access check for fail-nth

The fail-nth file is created with 0666 and the access is permitted if and only if the task is current. This file is owned by the currnet user. So we can create it with 0644 and allow the owner to write it. This enables to watch the status of task->fail_nth from another processes. Cc: Dmitry

[PATCH -mm 4/5] fault-inject: simplify access check for fail-nth

The fail-nth file is created with 0666 and the access is permitted if and only if the task is current. This file is owned by the currnet user. So we can create it with 0644 and allow the owner to write it. This enables to watch the status of task->fail_nth from another processes. Cc: Dmitry

[PATCH -mm 2/5] fault-inject: parse as natural 1-based value for fail-nth write interface

The value written to fail-nth file is parsed as 0-based. Parsing as one-based is more natural to understand and it enables to cancel the previous setup by simply writing '0'. This change also convert task->fail_nth from signed to unsigned int. Cc: Dmitry Vyukov

[PATCH -mm 3/5] fault-inject: make fail-nth read/write interface symmetric

The read interface for fail-nth looks a bit odd. Read from this file returns "N..." or "Y..." (this makes me surprise when cat this file). Because there is no EOF condition. The first character indicates current->fail_nth is zero or not, and then current->fail_nth is reset to zero. Just

[PATCH -mm 2/5] fault-inject: parse as natural 1-based value for fail-nth write interface

The value written to fail-nth file is parsed as 0-based. Parsing as one-based is more natural to understand and it enables to cancel the previous setup by simply writing '0'. This change also convert task->fail_nth from signed to unsigned int. Cc: Dmitry Vyukov Signed-off-by: Akinobu Mita ---

[PATCH -mm 3/5] fault-inject: make fail-nth read/write interface symmetric

The read interface for fail-nth looks a bit odd. Read from this file returns "N..." or "Y..." (this makes me surprise when cat this file). Because there is no EOF condition. The first character indicates current->fail_nth is zero or not, and then current->fail_nth is reset to zero. Just

<    3   4   5   6   7   8   9   10   11   12   >