Re: [RESEND PATCH v5] input: pxrc: new driver for PhoenixRC Flight Controller Adapter

On Sun, Feb 18, 2018 at 05:17:46PM +0100, Marcus Folkesson wrote: > This driver let you plug in your RC controller to the adapter and > use it as input device in various RC simulators. > > Signed-off-by: Marcus Folkesson Applied, thank you. > --- > > v5: > - Drop autosuspend support >

Re: [RESEND PATCH 1/6] input: synaptics_usb: fix deadlock in autosuspend

On Wed, Feb 28, 2018 at 02:37:58PM +0100, Marcus Folkesson wrote: > usb_autopm_get_interface() that is called in synusb_open() does an > autoresume if the device is suspended. > > input_dev->mutex used in synusb_resume() is in this case already > taken by the input subsystem and will cause a

what the hell is compat_sys_x86_waitpid() for?

You have COMPAT_SYSCALL_DEFINE3(x86_waitpid, compat_pid_t, pid, unsigned int __user *, stat_addr, int, options) { return compat_sys_wait4(pid, stat_addr, options, NULL); } with COMPAT_SYSCALL_DEFINE4(wait4, compat_pid_t, pid, compat_uint_t __user *,

what the hell is compat_sys_x86_waitpid() for?

You have COMPAT_SYSCALL_DEFINE3(x86_waitpid, compat_pid_t, pid, unsigned int __user *, stat_addr, int, options) { return compat_sys_wait4(pid, stat_addr, options, NULL); } with COMPAT_SYSCALL_DEFINE4(wait4, compat_pid_t, pid, compat_uint_t __user *,

Re: [RFC 2/4] sh: ecovec24: conditionally register backlight device

On 03/18/2018 02:16 AM, Rich Felker wrote: >> Umh, but I’m still using the SH7724 Evovec board. Please don’t >> remove support for that. >> >> The SuperH port of the Linux kernel is still maintained. > > Thanks. At some point it would be nice to remove the board file, but > only once the

Re: [RFC 2/4] sh: ecovec24: conditionally register backlight device

On 03/18/2018 02:16 AM, Rich Felker wrote: >> Umh, but I’m still using the SH7724 Evovec board. Please don’t >> remove support for that. >> >> The SuperH port of the Linux kernel is still maintained. > > Thanks. At some point it would be nice to remove the board file, but > only once the

Re: [PATCH 01/14] Input: atmel_mxt_ts - do not pass suspend mode in platform data

On Fri, Mar 16, 2018 at 08:40:02PM +, Nick Dyer wrote: > On Thu, Mar 15, 2018 at 04:56:21PM -0700, Dmitry Torokhov wrote: > > On Wed, Mar 14, 2018 at 08:51:24PM +, Nick Dyer wrote: > > > On Mon, Mar 12, 2018 at 12:08:54PM -0700, Dmitry Torokhov wrote: > > > > The way we are supposed to put

Re: [PATCH 01/14] Input: atmel_mxt_ts - do not pass suspend mode in platform data

On Fri, Mar 16, 2018 at 08:40:02PM +, Nick Dyer wrote: > On Thu, Mar 15, 2018 at 04:56:21PM -0700, Dmitry Torokhov wrote: > > On Wed, Mar 14, 2018 at 08:51:24PM +, Nick Dyer wrote: > > > On Mon, Mar 12, 2018 at 12:08:54PM -0700, Dmitry Torokhov wrote: > > > > The way we are supposed to put

Re: [RFC 2/4] sh: ecovec24: conditionally register backlight device

On Sat, Mar 17, 2018 at 10:25:16AM +0100, jacopo mondi wrote: > Hi Dmitry, > > On Fri, Mar 16, 2018 at 04:38:00PM -0700, Dmitry Torokhov wrote: > > Hi Jacopo, > > > > On Fri, Mar 16, 2018 at 11:07:48AM +0100, jacopo mondi wrote: > > > Hello Dmitry > > > > > > FYI I am brushing the ecovec board

Re: [RFC 2/4] sh: ecovec24: conditionally register backlight device

On Sat, Mar 17, 2018 at 10:25:16AM +0100, jacopo mondi wrote: > Hi Dmitry, > > On Fri, Mar 16, 2018 at 04:38:00PM -0700, Dmitry Torokhov wrote: > > Hi Jacopo, > > > > On Fri, Mar 16, 2018 at 11:07:48AM +0100, jacopo mondi wrote: > > > Hello Dmitry > > > > > > FYI I am brushing the ecovec board

Re: [RFC 2/4] sh: ecovec24: conditionally register backlight device

On Sat, Mar 17, 2018 at 01:16:31PM -0400, Rich Felker wrote: > On Sat, Mar 17, 2018 at 07:21:17PM +0900, John Paul Adrian Glaubitz wrote: > > > > > > > On Mar 17, 2018, at 6:25 PM, jacopo mondi wrote: > > > > > > Hi Dmitry, > > > > > >> On Fri, Mar 16, 2018 at 04:38:00PM

Re: [RFC 2/4] sh: ecovec24: conditionally register backlight device

On Sat, Mar 17, 2018 at 01:16:31PM -0400, Rich Felker wrote: > On Sat, Mar 17, 2018 at 07:21:17PM +0900, John Paul Adrian Glaubitz wrote: > > > > > > > On Mar 17, 2018, at 6:25 PM, jacopo mondi wrote: > > > > > > Hi Dmitry, > > > > > >> On Fri, Mar 16, 2018 at 04:38:00PM -0700, Dmitry

Re: [PATCH 4.14 024/110] btrfs: use proper endianness accessors for super_copy

Greg Kroah-Hartman wrote... > On Thu, Mar 15, 2018 at 07:55:42PM +0100, Christoph Biedl wrote: > > > commit 3c181c12c431fe33b669410d663beb9cceefcd1b upstream. > > On big-endian systems, this change intruduces severe corruption, > > resulting in complete loss of the data on the used block

Re: [PATCH 4.14 024/110] btrfs: use proper endianness accessors for super_copy

Greg Kroah-Hartman wrote... > On Thu, Mar 15, 2018 at 07:55:42PM +0100, Christoph Biedl wrote: > > > commit 3c181c12c431fe33b669410d663beb9cceefcd1b upstream. > > On big-endian systems, this change intruduces severe corruption, > > resulting in complete loss of the data on the used block

Re: [PATCH v2 16/36] fs: add ksys_dup{,3}() helper; remove in-kernel calls to sys_dup{,3}()

On Fri, Mar 16, 2018 at 01:48:34AM -0700, Christoph Hellwig wrote: > On Thu, Mar 15, 2018 at 08:05:09PM +0100, Dominik Brodowski wrote: > > Using ksys_dup() and ksys_dup3() as helper functions allows us to > > avoid the in-kernel calls to the sys_dup() and sys_dup3() syscalls. > > do_dup/dup3 or

Re: [PATCH v2 00/36] remove in-kernel syscall invocations (part 1)

On Thu, Mar 15, 2018 at 10:02:04PM +0100, Arnd Bergmann wrote: > On Thu, Mar 15, 2018 at 8:04 PM, Dominik Brodowski > wrote: > > Here is a re-spin of the first set of patches which reduce the number of > > syscall invocations from within the kernel; the RFC may be

Re: [PATCH v2 16/36] fs: add ksys_dup{,3}() helper; remove in-kernel calls to sys_dup{,3}()

On Fri, Mar 16, 2018 at 01:48:34AM -0700, Christoph Hellwig wrote: > On Thu, Mar 15, 2018 at 08:05:09PM +0100, Dominik Brodowski wrote: > > Using ksys_dup() and ksys_dup3() as helper functions allows us to > > avoid the in-kernel calls to the sys_dup() and sys_dup3() syscalls. > > do_dup/dup3 or

Re: [PATCH v2 00/36] remove in-kernel syscall invocations (part 1)

On Thu, Mar 15, 2018 at 10:02:04PM +0100, Arnd Bergmann wrote: > On Thu, Mar 15, 2018 at 8:04 PM, Dominik Brodowski > wrote: > > Here is a re-spin of the first set of patches which reduce the number of > > syscall invocations from within the kernel; the RFC may be found at > > > > The rationale

Re: [PATCH v2 17/36] fs: add ksys_chroot() helper; remove-in kernel calls to sys_chroot()

Arnd, Christoph, On Thu, Mar 15, 2018 at 09:44:24PM +0100, Arnd Bergmann wrote: > > diff --git a/drivers/base/devtmpfs.c b/drivers/base/devtmpfs.c > > index 4afb04686c8e..5743f04014ca 100644 > > --- a/drivers/base/devtmpfs.c > > +++ b/drivers/base/devtmpfs.c > > @@ -387,7 +387,7 @@ static int

Re: [PATCH v2 17/36] fs: add ksys_chroot() helper; remove-in kernel calls to sys_chroot()

Arnd, Christoph, On Thu, Mar 15, 2018 at 09:44:24PM +0100, Arnd Bergmann wrote: > > diff --git a/drivers/base/devtmpfs.c b/drivers/base/devtmpfs.c > > index 4afb04686c8e..5743f04014ca 100644 > > --- a/drivers/base/devtmpfs.c > > +++ b/drivers/base/devtmpfs.c > > @@ -387,7 +387,7 @@ static int

Re: [PATCH v2 24/36] fs: add ksys_unlink() wrapper; remove in-kernel calls to sys_unlink()

On Thu, Mar 15, 2018 at 09:21:39PM +0100, Arnd Bergmann wrote: > On Thu, Mar 15, 2018 at 8:05 PM, Dominik Brodowski > wrote: > > Using this wrapper allows us to avoid the in-kernel calls to the > > sys_unlink() syscall. > > > > Cc: Al Viro > >

Re: [PATCH v2 18/36] fs: add ksys_write() helper; remove in-kernel calls to sys_write()

On Fri, Mar 16, 2018 at 01:52:40AM -0700, Christoph Hellwig wrote: > I really don't like this, as this is the wrong level of abstraction. > > > diff --git a/arch/s390/kernel/compat_linux.c > > b/arch/s390/kernel/compat_linux.c > > index 79b7a3438d54..5a9cfde5fc28 100644 > > ---

Re: [PATCH v2 24/36] fs: add ksys_unlink() wrapper; remove in-kernel calls to sys_unlink()

On Thu, Mar 15, 2018 at 09:21:39PM +0100, Arnd Bergmann wrote: > On Thu, Mar 15, 2018 at 8:05 PM, Dominik Brodowski > wrote: > > Using this wrapper allows us to avoid the in-kernel calls to the > > sys_unlink() syscall. > > > > Cc: Al Viro > > Cc: Andrew Morton > > Signed-off-by: Dominik

Re: [PATCH v2 18/36] fs: add ksys_write() helper; remove in-kernel calls to sys_write()

On Fri, Mar 16, 2018 at 01:52:40AM -0700, Christoph Hellwig wrote: > I really don't like this, as this is the wrong level of abstraction. > > > diff --git a/arch/s390/kernel/compat_linux.c > > b/arch/s390/kernel/compat_linux.c > > index 79b7a3438d54..5a9cfde5fc28 100644 > > ---

Re: [PATCH v2 15/36] fs: add ksys_umount() helper; remove in-kernel call to sys_umount()

On Fri, Mar 16, 2018 at 01:47:50AM -0700, Christoph Hellwig wrote: > On Thu, Mar 15, 2018 at 08:05:08PM +0100, Dominik Brodowski wrote: > > Using this helper allows us to avoid the in-kernel call to the sys_umount() > > syscall. > > kern_unmount, please. And make it operate on kernel pointers

Re: [PATCH v2 15/36] fs: add ksys_umount() helper; remove in-kernel call to sys_umount()

On Fri, Mar 16, 2018 at 01:47:50AM -0700, Christoph Hellwig wrote: > On Thu, Mar 15, 2018 at 08:05:08PM +0100, Dominik Brodowski wrote: > > Using this helper allows us to avoid the in-kernel call to the sys_umount() > > syscall. > > kern_unmount, please. And make it operate on kernel pointers

Re: [PATCH v2 03/36] mm: use do_futex() instead of sys_futex() in mm_release()

On Fri, Mar 16, 2018 at 02:44:54PM -0700, Darren Hart wrote: > On Fri, Mar 16, 2018 at 07:03:53PM +, Andy Lutomirski wrote: > > On Fri, Mar 16, 2018 at 6:43 PM, Darren Hart wrote: > > > On Thu, Mar 15, 2018 at 08:04:56PM +0100, Dominik Brodowski wrote: > > >> sys_futex()

Re: [PATCH v2 30/36] fs: add do_linkat() helper and ksys_link() wrapper; remove in-kernel calls to syscall

On Thu, Mar 15, 2018 at 09:30:58PM +0100, Arnd Bergmann wrote: > On Thu, Mar 15, 2018 at 8:05 PM, Dominik Brodowski > wrote: > > > > */ > > -SYSCALL_DEFINE5(linkat, int, olddfd, const char __user *, oldname, > > - int, newdfd, const char __user *,

Re: [PATCH v2 14/36] fs: add ksys_mount() helper; remove in-kernel calls to sys_mount()

Arnd, Christoph, thanks for your review. On the basis of the goal of this patch series, I will stick with the "mindless" conversion for the time being, but add the following caveat to the commit message: In the near future, all callers of ksys_mount() should be converted to call

Re: [PATCH v2 03/36] mm: use do_futex() instead of sys_futex() in mm_release()

On Fri, Mar 16, 2018 at 02:44:54PM -0700, Darren Hart wrote: > On Fri, Mar 16, 2018 at 07:03:53PM +, Andy Lutomirski wrote: > > On Fri, Mar 16, 2018 at 6:43 PM, Darren Hart wrote: > > > On Thu, Mar 15, 2018 at 08:04:56PM +0100, Dominik Brodowski wrote: > > >> sys_futex() is a wrapper to

Re: [PATCH v2 30/36] fs: add do_linkat() helper and ksys_link() wrapper; remove in-kernel calls to syscall

On Thu, Mar 15, 2018 at 09:30:58PM +0100, Arnd Bergmann wrote: > On Thu, Mar 15, 2018 at 8:05 PM, Dominik Brodowski > wrote: > > > > */ > > -SYSCALL_DEFINE5(linkat, int, olddfd, const char __user *, oldname, > > - int, newdfd, const char __user *, newname, int, flags) > > +int

Re: [PATCH v2 14/36] fs: add ksys_mount() helper; remove in-kernel calls to sys_mount()

Arnd, Christoph, thanks for your review. On the basis of the goal of this patch series, I will stick with the "mindless" conversion for the time being, but add the following caveat to the commit message: In the near future, all callers of ksys_mount() should be converted to call

Re: [PATCH v2 02/36] kernel: use kernel_wait4() instead of sys_wait4()

On Fri, Mar 16, 2018 at 04:58:31PM +, Luis R. Rodriguez wrote: > On Thu, Mar 15, 2018 at 08:04:55PM +0100, Dominik Brodowski wrote: > > diff --git a/kernel/umh.c b/kernel/umh.c > > index 18e5fa4b0e71..f4b557cadf08 100644 > > --- a/kernel/umh.c > > +++ b/kernel/umh.c > > @@ -135,7 +135,7 @@

Re: [PATCH v2 02/36] kernel: use kernel_wait4() instead of sys_wait4()

On Fri, Mar 16, 2018 at 04:58:31PM +, Luis R. Rodriguez wrote: > On Thu, Mar 15, 2018 at 08:04:55PM +0100, Dominik Brodowski wrote: > > diff --git a/kernel/umh.c b/kernel/umh.c > > index 18e5fa4b0e71..f4b557cadf08 100644 > > --- a/kernel/umh.c > > +++ b/kernel/umh.c > > @@ -135,7 +135,7 @@

Re: [RFC 2/4] sh: ecovec24: conditionally register backlight device

On Sat, Mar 17, 2018 at 07:21:17PM +0900, John Paul Adrian Glaubitz wrote: > > > > On Mar 17, 2018, at 6:25 PM, jacopo mondi wrote: > > > > Hi Dmitry, > > > >> On Fri, Mar 16, 2018 at 04:38:00PM -0700, Dmitry Torokhov wrote: > >> Hi Jacopo, > >> > >>> On Fri, Mar 16, 2018

Re: [RFC 2/4] sh: ecovec24: conditionally register backlight device

On Sat, Mar 17, 2018 at 07:21:17PM +0900, John Paul Adrian Glaubitz wrote: > > > > On Mar 17, 2018, at 6:25 PM, jacopo mondi wrote: > > > > Hi Dmitry, > > > >> On Fri, Mar 16, 2018 at 04:38:00PM -0700, Dmitry Torokhov wrote: > >> Hi Jacopo, > >> > >>> On Fri, Mar 16, 2018 at 11:07:48AM

Re: [PATCH v2] irqchip/gic-v3: Ensure GICR_CTLR.EnableLPI=0 is observed before enabling

On Sat, 17 Mar 2018 16:11:06 +, Shanker Donthineni wrote: > > Hi Marc, > > On 03/17/2018 08:34 AM, Marc Zyngier wrote: > > On Thu, 15 Mar 2018 09:31:27 -0500 > > Shanker Donthineni wrote: > > > >> The definition of the GICR_CTLR.RWP control bit was expanded to

Re: [PATCH v2] irqchip/gic-v3: Ensure GICR_CTLR.EnableLPI=0 is observed before enabling

On Sat, 17 Mar 2018 16:11:06 +, Shanker Donthineni wrote: > > Hi Marc, > > On 03/17/2018 08:34 AM, Marc Zyngier wrote: > > On Thu, 15 Mar 2018 09:31:27 -0500 > > Shanker Donthineni wrote: > > > >> The definition of the GICR_CTLR.RWP control bit was expanded to indicate > >> status of

[PATCH 2/2] x86, cpuid: allow cpuid_read() to schedule

I noticed high latencies caused by a daemon periodically reading various MSR and cpuid on all cpus. KASAN kernels would see ~10ms latencies simply reading one cpuid. Even without KASAN, sending IPI to CPU in deep sleep state or blocking hard IRQ in a a long section, then waiting for the answer can

[PATCH 1/2] x86, msr: add rdmsr_safe_on_cpu_resched() and use it in msr_read()

I noticed high latencies caused by a daemon periodically reading various MSR on all cpus. KASAN kernels would see ~10ms latencies simply reading one MSR. Even without KASAN, sending IPI to CPU in deep sleep state or blocking hard IRQ in a a long section, then waiting for the answer can consume

[PATCH 2/2] x86, cpuid: allow cpuid_read() to schedule

I noticed high latencies caused by a daemon periodically reading various MSR and cpuid on all cpus. KASAN kernels would see ~10ms latencies simply reading one cpuid. Even without KASAN, sending IPI to CPU in deep sleep state or blocking hard IRQ in a a long section, then waiting for the answer can

[PATCH 1/2] x86, msr: add rdmsr_safe_on_cpu_resched() and use it in msr_read()

I noticed high latencies caused by a daemon periodically reading various MSR on all cpus. KASAN kernels would see ~10ms latencies simply reading one MSR. Even without KASAN, sending IPI to CPU in deep sleep state or blocking hard IRQ in a a long section, then waiting for the answer can consume

[PATCH v2] locks: change POSIX lock ownership on execve when files_struct is displaced

From: Jeff Layton POSIX mandates that open fds and their associated file locks should be preserved across an execve. This works, unless the process is multithreaded at the time that execve is called. In that case, we'll end up unsharing the files_struct but the locks will

[PATCH v2] locks: change POSIX lock ownership on execve when files_struct is displaced

From: Jeff Layton POSIX mandates that open fds and their associated file locks should be preserved across an execve. This works, unless the process is multithreaded at the time that execve is called. In that case, we'll end up unsharing the files_struct but the locks will still have their

[PATCH -mm] proc: test /proc/uptime

The only tests I could come up with for /proc/uptime are: * test that values increase monotonically for 1 second, * bounce around CPUs and test the same thing. Avoid glibc like plague for affinity given patches like this: https://marc.info/?l=linux-kernel=152130031912594=4 Signed-off-by: Alexey

[PATCH -mm] proc: test /proc/uptime

The only tests I could come up with for /proc/uptime are: * test that values increase monotonically for 1 second, * bounce around CPUs and test the same thing. Avoid glibc like plague for affinity given patches like this: https://marc.info/?l=linux-kernel=152130031912594=4 Signed-off-by: Alexey

[PATCH -mm] proc: fixup read test even more

/proc/sysrq-trigger lives on the ground floor so to speak. Signed-off-by: Alexey Dobriyan --- FOLD INTO proc-shotgun-test-read-readdir-readlink-a-little-write-fix.patch tools/testing/selftests/proc/read.c |6 +++--- 1 file changed, 3 insertions(+), 3

[PATCH -mm] proc: fixup read test even more

/proc/sysrq-trigger lives on the ground floor so to speak. Signed-off-by: Alexey Dobriyan --- FOLD INTO proc-shotgun-test-read-readdir-readlink-a-little-write-fix.patch tools/testing/selftests/proc/read.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) ---

[PATCH v3] rbd: Remove VLA usage

As part of the effort to remove VLAs from the kernel[1], this moves the literal values into the stack array calculation instead of using a variable for the sizing. The resulting size can be found from sizeof(buf). [1] https://lkml.org/lkml/2018/3/7/621 Signed-off-by: Kyle Spiers

[PATCH v3] rbd: Remove VLA usage

As part of the effort to remove VLAs from the kernel[1], this moves the literal values into the stack array calculation instead of using a variable for the sizing. The resulting size can be found from sizeof(buf). [1] https://lkml.org/lkml/2018/3/7/621 Signed-off-by: Kyle Spiers ---

RE: [RFT][PATCH v5 0/7] sched/cpuidle: Idle loop rework

On 2018.03.17 Thomas Ilsche wrote: > Over the last week I tested v4+pollv2 and now v5+pollv3. With v5, I > observe a particular idle behavior, that I have not seen before with > v4. On a dual-socket Skylake system the idle power increases from > 74.1 W (system total) to 85.5 W with a 300 HZ build

RE: [RFT][PATCH v5 0/7] sched/cpuidle: Idle loop rework

On 2018.03.17 Thomas Ilsche wrote: > Over the last week I tested v4+pollv2 and now v5+pollv3. With v5, I > observe a particular idle behavior, that I have not seen before with > v4. On a dual-socket Skylake system the idle power increases from > 74.1 W (system total) to 85.5 W with a 300 HZ build

Re: [PATCH v2] irqchip/gic-v3: Ensure GICR_CTLR.EnableLPI=0 is observed before enabling

Hi Marc, On 03/17/2018 08:34 AM, Marc Zyngier wrote: > On Thu, 15 Mar 2018 09:31:27 -0500 > Shanker Donthineni wrote: > >> The definition of the GICR_CTLR.RWP control bit was expanded to indicate >> status of changing GICR_CTLR.EnableLPI from 1 to 0 is being in progress

Re: [PATCH v2] irqchip/gic-v3: Ensure GICR_CTLR.EnableLPI=0 is observed before enabling

Hi Marc, On 03/17/2018 08:34 AM, Marc Zyngier wrote: > On Thu, 15 Mar 2018 09:31:27 -0500 > Shanker Donthineni wrote: > >> The definition of the GICR_CTLR.RWP control bit was expanded to indicate >> status of changing GICR_CTLR.EnableLPI from 1 to 0 is being in progress >> or completed.

Re: [PATCH 1/3] x86, pkeys: do not special case protection key 0

On 03/17/2018 02:12 AM, Thomas Gleixner wrote: >> This is a bit nicer than what Ram proposed because it is simpler >> and removes special-casing for pkey 0. On the other hand, it does >> allow applciations to pkey_free() pkey-0, but that's just a silly >> thing to do, so we are not going to

Re: [PATCH 1/3] x86, pkeys: do not special case protection key 0

On 03/17/2018 02:12 AM, Thomas Gleixner wrote: >> This is a bit nicer than what Ram proposed because it is simpler >> and removes special-casing for pkey 0. On the other hand, it does >> allow applciations to pkey_free() pkey-0, but that's just a silly >> thing to do, so we are not going to

Re: [PATCH v5 07/36] drm/bridge: analogix_dp: Move enable video into config_video()

Hi Archit, Am Mittwoch, 14. März 2018, 06:59:59 CET schrieb Archit Taneja: > On Saturday 10 March 2018 03:52 AM, Enric Balletbo i Serra wrote: > > From: Lin Huang > > > > We need to enable video before analogix_dp_is_video_stream_on(), so > > we can get the right video

Re: [PATCH v5 07/36] drm/bridge: analogix_dp: Move enable video into config_video()

Hi Archit, Am Mittwoch, 14. März 2018, 06:59:59 CET schrieb Archit Taneja: > On Saturday 10 March 2018 03:52 AM, Enric Balletbo i Serra wrote: > > From: Lin Huang > > > > We need to enable video before analogix_dp_is_video_stream_on(), so > > we can get the right video stream status. > > > >

Re: [PATCH] locks: change POSIX lock ownership on execve when files_struct is displaced

On Sat, Mar 17, 2018 at 11:43:28AM -0400, Jeff Layton wrote: > On Sat, 2018-03-17 at 15:05 +, Al Viro wrote: > > On Sat, Mar 17, 2018 at 10:25:20AM -0400, Jeff Layton wrote: > > > From: Jeff Layton > > > > > > POSIX mandates that open fds and their associated file locks

Re: [PATCH] locks: change POSIX lock ownership on execve when files_struct is displaced

On Sat, Mar 17, 2018 at 11:43:28AM -0400, Jeff Layton wrote: > On Sat, 2018-03-17 at 15:05 +, Al Viro wrote: > > On Sat, Mar 17, 2018 at 10:25:20AM -0400, Jeff Layton wrote: > > > From: Jeff Layton > > > > > > POSIX mandates that open fds and their associated file locks should be > > >

[PATCH v3 7/8] gpio: gpio-mm: Implement get_multiple callback

The Diamond Systems GPIO-MM series of devices contain two 82C55A devices, which each feature three 8-bit ports of I/O. Since eight input lines are acquired on a single port input read, the GPIO-MM GPIO driver may improve multiple input reads by utilizing a get_multiple callback. This patch

[PATCH v3 7/8] gpio: gpio-mm: Implement get_multiple callback

The Diamond Systems GPIO-MM series of devices contain two 82C55A devices, which each feature three 8-bit ports of I/O. Since eight input lines are acquired on a single port input read, the GPIO-MM GPIO driver may improve multiple input reads by utilizing a get_multiple callback. This patch

[PATCH v3 8/8] gpio: ws16c48: Implement get_multiple callback

The WinSystems WS16C48 device provides 48 lines of digital I/O accessed via six 8-bit ports. Since eight input lines are acquired on a single port input read, the WS16C48 GPIO driver may improve multiple input reads by utilizing a get_multiple callback. This patch implements the

[PATCH v3 8/8] gpio: ws16c48: Implement get_multiple callback

The WinSystems WS16C48 device provides 48 lines of digital I/O accessed via six 8-bit ports. Since eight input lines are acquired on a single port input read, the WS16C48 GPIO driver may improve multiple input reads by utilizing a get_multiple callback. This patch implements the

[PATCH v3 5/8] gpio: 104-dio-48e: Implement get_multiple callback

The ACCES I/O 104-DIO-48E series of devices contain two Programmable Peripheral Interface (PPI) chips of type 82C55, which each feature three 8-bit ports of I/O. Since eight input lines are acquired on a single port input read, the 104-DIO-48E GPIO driver may improve multiple input reads by

[PATCH v3 5/8] gpio: 104-dio-48e: Implement get_multiple callback

The ACCES I/O 104-DIO-48E series of devices contain two Programmable Peripheral Interface (PPI) chips of type 82C55, which each feature three 8-bit ports of I/O. Since eight input lines are acquired on a single port input read, the 104-DIO-48E GPIO driver may improve multiple input reads by

[PATCH v3 6/8] gpio: 104-idi-48: Implement get_multiple callback

The ACCES I/O 104-IDI-48 series of devices provides 48 optically-isolated inputs accessed via six 8-bit ports. Since eight input lines are acquired on a single port input read, the 104-IDI-48 GPIO driver may improve multiple input reads by utilizing a get_multiple callback. This patch implements

[PATCH v3 6/8] gpio: 104-idi-48: Implement get_multiple callback

The ACCES I/O 104-IDI-48 series of devices provides 48 optically-isolated inputs accessed via six 8-bit ports. Since eight input lines are acquired on a single port input read, the 104-IDI-48 GPIO driver may improve multiple input reads by utilizing a get_multiple callback. This patch implements

[PATCH v3 4/8] gpio: pcie-idio-24: Implement get_multiple/set_multiple callbacks

The ACCES I/O PCIe-IDIO-24 series of devices provides 24 optically-isolated digital I/O accessed via six 8-bit ports. Since eight input lines are acquired on a single port input read -- and similarly eight output lines are set on a single port output write -- the PCIe-IDIO-24 GPIO driver may

[PATCH v3 4/8] gpio: pcie-idio-24: Implement get_multiple/set_multiple callbacks

The ACCES I/O PCIe-IDIO-24 series of devices provides 24 optically-isolated digital I/O accessed via six 8-bit ports. Since eight input lines are acquired on a single port input read -- and similarly eight output lines are set on a single port output write -- the PCIe-IDIO-24 GPIO driver may

[PATCH v3 2/8] gpio: 104-idio-16: Implement get_multiple callback

The ACCES I/O 104-IDIO-16 series of devices provides 16 optically-isolated digital inputs accessed via two 8-bit ports. Since eight input lines are acquired on a single port input read, the 104-IDIO-16 GPIO driver may improve multiple input reads by utilizing a get_multiple callback. This patch

[PATCH v3 3/8] gpio: pci-idio-16: Implement get_multiple callback

The ACCES I/O PCI-IDIO-16 series of devices provides 16 optically-isolated digital inputs accessed via two 8-bit ports. Since eight input lines are acquired on a single port input read, the PCI-IDIO-16 GPIO driver may improve multiple input reads by utilizing a get_multiple callback. This patch

[PATCH v3 2/8] gpio: 104-idio-16: Implement get_multiple callback

The ACCES I/O 104-IDIO-16 series of devices provides 16 optically-isolated digital inputs accessed via two 8-bit ports. Since eight input lines are acquired on a single port input read, the 104-IDIO-16 GPIO driver may improve multiple input reads by utilizing a get_multiple callback. This patch

[PATCH v3 3/8] gpio: pci-idio-16: Implement get_multiple callback

The ACCES I/O PCI-IDIO-16 series of devices provides 16 optically-isolated digital inputs accessed via two 8-bit ports. Since eight input lines are acquired on a single port input read, the PCI-IDIO-16 GPIO driver may improve multiple input reads by utilizing a get_multiple callback. This patch

[PATCH v3 1/8] iio: stx104: Implement get_multiple callback

The Apex Embedded Systems STX104 series of devices provides 4 TTL compatible lines of inputs accessed via a single 4-bit port. Since four input lines are acquired on a single port input read, the STX104 GPIO driver may improve multiple input reads by utilizing a get_multiple callback. This patch

[PATCH v3 1/8] iio: stx104: Implement get_multiple callback

The Apex Embedded Systems STX104 series of devices provides 4 TTL compatible lines of inputs accessed via a single 4-bit port. Since four input lines are acquired on a single port input read, the STX104 GPIO driver may improve multiple input reads by utilizing a get_multiple callback. This patch

[PATCH v3 0/8] Implement get_multiple for ACCES and PC/104 drivers

Changes in v2: - Add missing bitmap.h header includes - Fix typographical error in symbol name for word_mask - Remove const qualifier for ports array This patchset implements get_multiple callbacks for the PC104 GPIO drivers as well as the PCI-IDIO-16 and PCIe-IDIO-24 GPIO drivers. These

[PATCH v3 0/8] Implement get_multiple for ACCES and PC/104 drivers

Changes in v2: - Add missing bitmap.h header includes - Fix typographical error in symbol name for word_mask - Remove const qualifier for ports array This patchset implements get_multiple callbacks for the PC104 GPIO drivers as well as the PCI-IDIO-16 and PCIe-IDIO-24 GPIO drivers. These

Re: [PATCH v2 5/8] gpio: 104-dio-48e: Implement get_multiple callback

-Breathitt-Gray/Implement-get_multiple-for-ACCES-and-PC-104-drivers/20180317-224135 config: i386-randconfig-a0-201810 (attached as .config) compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed

Re: [PATCH v2 5/8] gpio: 104-dio-48e: Implement get_multiple callback

-Breathitt-Gray/Implement-get_multiple-for-ACCES-and-PC-104-drivers/20180317-224135 config: i386-randconfig-a0-201810 (attached as .config) compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed

Re: [PATCH] locks: change POSIX lock ownership on execve when files_struct is displaced

On Sat, 2018-03-17 at 15:05 +, Al Viro wrote: > On Sat, Mar 17, 2018 at 10:25:20AM -0400, Jeff Layton wrote: > > From: Jeff Layton > > > > POSIX mandates that open fds and their associated file locks should be > > preserved across an execve. This works, unless the process

Re: [PATCH] locks: change POSIX lock ownership on execve when files_struct is displaced

On Sat, 2018-03-17 at 15:05 +, Al Viro wrote: > On Sat, Mar 17, 2018 at 10:25:20AM -0400, Jeff Layton wrote: > > From: Jeff Layton > > > > POSIX mandates that open fds and their associated file locks should be > > preserved across an execve. This works, unless the process is > >

Re: [PATCHv2 1/4] gpio: Remove VLA from gpiolib

/Laura-Abbott/VLA-removal-from-the-gpio-subsystem/20180317-210828 config: i386-defconfig (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 All warnings (new ones prefixed by >>): In file in

Re: [PATCHv2 1/4] gpio: Remove VLA from gpiolib

/Laura-Abbott/VLA-removal-from-the-gpio-subsystem/20180317-210828 config: i386-defconfig (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 All warnings (new ones prefixed by >>): In file in

[PATCH v1 2/5] media: staging: tegra-vde: Silence some of checkpatch warnings

Make all strings single line to make them grep'able and add a comment to the memory barrier. Signed-off-by: Dmitry Osipenko --- drivers/staging/media/tegra-vde/tegra-vde.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git

[PATCH v1 3/5] media: staging: tegra-vde: Correct minimum size of U/V planes

Stride of U/V planes must be aligned to 16 bytes (2 macroblocks). This needs to be taken into account, otherwise it is possible to get a silent memory corruption if dmabuf size is less than the size of decoded video frame. Signed-off-by: Dmitry Osipenko ---

[PATCH v1 1/5] media: staging: tegra-vde: Align bitstream size to 16K

I've noticed that decoding fails sometime if size of bitstream buffer isn't aligned to 16K, probably because HW fetches data from memory in a 16K granularity and if the last chunk of data isn't aligned, HW reads garbage data beyond the dmabuf and tries to parse it. Signed-off-by: Dmitry Osipenko

[PATCH v1 2/5] media: staging: tegra-vde: Silence some of checkpatch warnings

Make all strings single line to make them grep'able and add a comment to the memory barrier. Signed-off-by: Dmitry Osipenko --- drivers/staging/media/tegra-vde/tegra-vde.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git

[PATCH v1 3/5] media: staging: tegra-vde: Correct minimum size of U/V planes

Stride of U/V planes must be aligned to 16 bytes (2 macroblocks). This needs to be taken into account, otherwise it is possible to get a silent memory corruption if dmabuf size is less than the size of decoded video frame. Signed-off-by: Dmitry Osipenko ---

[PATCH v1 1/5] media: staging: tegra-vde: Align bitstream size to 16K

I've noticed that decoding fails sometime if size of bitstream buffer isn't aligned to 16K, probably because HW fetches data from memory in a 16K granularity and if the last chunk of data isn't aligned, HW reads garbage data beyond the dmabuf and tries to parse it. Signed-off-by: Dmitry Osipenko

[PATCH v1 4/5] media: staging: tegra-vde: Do not handle spurious interrupts

Do not handle interrupts if we haven't asked for them, potentially that could happen if HW wasn't programmed properly. Signed-off-by: Dmitry Osipenko --- drivers/staging/media/tegra-vde/tegra-vde.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

[PATCH v1 5/5] media: staging: tegra-vde: Correct included header

This is Open Firmware driver, hence 'of_device.h' should be included instead of 'platform_device.h'. Right now OF headers happen to be included indirectly and this may break in the future, so let's correct the header. Signed-off-by: Dmitry Osipenko ---

[PATCH v1 4/5] media: staging: tegra-vde: Do not handle spurious interrupts

Do not handle interrupts if we haven't asked for them, potentially that could happen if HW wasn't programmed properly. Signed-off-by: Dmitry Osipenko --- drivers/staging/media/tegra-vde/tegra-vde.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

[PATCH v1 5/5] media: staging: tegra-vde: Correct included header

This is Open Firmware driver, hence 'of_device.h' should be included instead of 'platform_device.h'. Right now OF headers happen to be included indirectly and this may break in the future, so let's correct the header. Signed-off-by: Dmitry Osipenko ---

[PATCH v1 0/5] Tegra Video Decoder patches for 4.17

Hello media maintainers, I've been postponing sending out these patches for awhile because I was waiting for a review for the Tegra memory controller patches that would allow to reset VDE HW properly and was hoping that they will get into 4.17, but it's getting quite late now and seems 4.18 is

[PATCH v1 0/5] Tegra Video Decoder patches for 4.17

Hello media maintainers, I've been postponing sending out these patches for awhile because I was waiting for a review for the Tegra memory controller patches that would allow to reset VDE HW properly and was hoping that they will get into 4.17, but it's getting quite late now and seems 4.18 is

[PATCH] selftests/x86/ptrace_syscall: Fix for yet more glibc interference

glibc keeps getting cleverer, and my version now turns raise() into more than one syscall. Since the test relies on ptrace seeing an exact set of syscalls, this breaks the test. Replace raise(SIGSTOP) with syscall(SYS_tgkill, ...) to force glibc to get out of our way. Cc: sta...@vger.kernel.org

[PATCH] selftests/x86/ptrace_syscall: Fix for yet more glibc interference

glibc keeps getting cleverer, and my version now turns raise() into more than one syscall. Since the test relies on ptrace seeing an exact set of syscalls, this breaks the test. Replace raise(SIGSTOP) with syscall(SYS_tgkill, ...) to force glibc to get out of our way. Cc: sta...@vger.kernel.org

Re: [PATCH v1 3/3] drm/tegra: dc: Dedicate overlay plane to cursor on older Tegra's

On 16.03.2018 10:36, Daniel Vetter wrote: > On Thu, Mar 15, 2018 at 11:45 AM, Thierry Reding > wrote: >> On Thu, Mar 15, 2018 at 04:00:25AM +0300, Dmitry Osipenko wrote: >>> Older Tegra's do not support RGBA format for the cursor, but instead >>> overlay plane could be

Re: [PATCH v1 3/3] drm/tegra: dc: Dedicate overlay plane to cursor on older Tegra's

On 16.03.2018 10:36, Daniel Vetter wrote: > On Thu, Mar 15, 2018 at 11:45 AM, Thierry Reding > wrote: >> On Thu, Mar 15, 2018 at 04:00:25AM +0300, Dmitry Osipenko wrote: >>> Older Tegra's do not support RGBA format for the cursor, but instead >>> overlay plane could be used for it. Since there is

<    1   2   3   4   5   6   >