Re: [PATCH v1 2/2] wmi: use generic UUID library

On Thu, Apr 07, 2016 at 08:00:55PM +0300, Andy Shevchenko wrote: > Instead of opencoding let's use generic UUID library functions here. > > Cc: Darren Hart > Signed-off-by: Andy Shevchenko > --- > drivers/platform/x86/wmi.c | 104 >

Re: [PATCH v1 2/2] wmi: use generic UUID library

On Thu, Apr 07, 2016 at 08:00:55PM +0300, Andy Shevchenko wrote: > Instead of opencoding let's use generic UUID library functions here. > > Cc: Darren Hart > Signed-off-by: Andy Shevchenko > --- > drivers/platform/x86/wmi.c | 104 > ++--- > 1 file

Re: [PATCH] cpufreq: Abort cpufreq_update_current_freq() for cpufreq_suspended set

On 10 April 2016 at 09:38, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Since governor operations are generally skipped if cpufreq_suspended > is set, cpufreq_start_governor() should do nothing in that case. > > That function is called in

Re: [PATCH] cpufreq: Abort cpufreq_update_current_freq() for cpufreq_suspended set

On 10 April 2016 at 09:38, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Since governor operations are generally skipped if cpufreq_suspended > is set, cpufreq_start_governor() should do nothing in that case. > > That function is called in the cpufreq_online() path, and may also > be

[PATCH] intel_pstate: Avoid getting stuck in high P-states when idle

From: Rafael J. Wysocki Jörg Otte reports that commit a4675fbc4a7a (cpufreq: intel_pstate: Replace timers with utilization update callbacks) caused the CPUs in his Haswell-based system to stay in the very high frequency region even if the system is completely idle.

[PATCH] intel_pstate: Avoid getting stuck in high P-states when idle

From: Rafael J. Wysocki Jörg Otte reports that commit a4675fbc4a7a (cpufreq: intel_pstate: Replace timers with utilization update callbacks) caused the CPUs in his Haswell-based system to stay in the very high frequency region even if the system is completely idle. That turns out to be an

[PATCH] cpufreq: Abort cpufreq_update_current_freq() for cpufreq_suspended set

From: Rafael J. Wysocki Since governor operations are generally skipped if cpufreq_suspended is set, cpufreq_start_governor() should do nothing in that case. That function is called in the cpufreq_online() path, and may also be called from cpufreq_offline() in some

[PATCH] cpufreq: Abort cpufreq_update_current_freq() for cpufreq_suspended set

From: Rafael J. Wysocki Since governor operations are generally skipped if cpufreq_suspended is set, cpufreq_start_governor() should do nothing in that case. That function is called in the cpufreq_online() path, and may also be called from cpufreq_offline() in some cases, which are invoked by

Re: [PATCH] cpufreq: Skip all governor-related actions for cpufreq_suspended set

On Sun, Apr 10, 2016 at 5:16 AM, Viresh Kumar wrote: > On 08-04-16, 23:54, Rafael J. Wysocki wrote: >> From: Rafael J. Wysocki >> Subject: [PATCH] cpufreq: Skip all governor-related actions for >> cpufreq_suspended set >> >> Since governor

Re: [PATCH] cpufreq: Skip all governor-related actions for cpufreq_suspended set

On Sun, Apr 10, 2016 at 5:16 AM, Viresh Kumar wrote: > On 08-04-16, 23:54, Rafael J. Wysocki wrote: >> From: Rafael J. Wysocki >> Subject: [PATCH] cpufreq: Skip all governor-related actions for >> cpufreq_suspended set >> >> Since governor operations are generally skipped if cpufreq_suspended

Re: [regression] cross core scheduling frequency drop bisected to 0c313cb20732

On Sat, Apr 9, 2016 at 6:39 PM, Mike Galbraith wrote: > > Hm, setting gov=performance, and taking the average of 3 30 second > interval PkgWatt samples as pipe-test runs.. > > 714KHz/28.03Ws = 25.46 > 877KHz/30.28Ws = 28.96 > > ..for pipe-test, the tradeoff look a bit

Re: [regression] cross core scheduling frequency drop bisected to 0c313cb20732

On Sat, Apr 9, 2016 at 6:39 PM, Mike Galbraith wrote: > > Hm, setting gov=performance, and taking the average of 3 30 second > interval PkgWatt samples as pipe-test runs.. > > 714KHz/28.03Ws = 25.46 > 877KHz/30.28Ws = 28.96 > > ..for pipe-test, the tradeoff look a bit more like red than green.

[PATCH 1/2] tty: Remove unused TTY_NUMBER() macro

TTY_NUMBER() has been unused since v2.5.71; removed by "[PATCH] callout removal: callout is gone". Signed-off-by: Peter Hurley --- drivers/tty/tty_io.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c index

[PATCH 2/2] tty: Remove stale parameter comment

noctty was removed as a parameter by commit 216513411937586 ("tty: Consolidate noctty check in tty_open()"). Signed-off-by: Peter Hurley --- drivers/tty/tty_io.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c index

[PATCH 1/2] tty: Remove unused TTY_NUMBER() macro

TTY_NUMBER() has been unused since v2.5.71; removed by "[PATCH] callout removal: callout is gone". Signed-off-by: Peter Hurley --- drivers/tty/tty_io.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c index 320dc4d..3cdd63b 100644 ---

[PATCH 2/2] tty: Remove stale parameter comment

noctty was removed as a parameter by commit 216513411937586 ("tty: Consolidate noctty check in tty_open()"). Signed-off-by: Peter Hurley --- drivers/tty/tty_io.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c index 3cdd63b..50979be 100644 ---

Re: [PATCH 2/2] asus-laptop: remove unused variable

On Thu, Apr 07, 2016 at 11:20:01PM +0300, Giedrius Statkevičius wrote: > `out' was assigned value but it was never used so remove it > > Signed-off-by: Giedrius Statkevičius > --- > drivers/platform/x86/asus-laptop.c | 3 --- > 1 file changed, 3 deletions(-) >

Re: [PATCH 2/2] asus-laptop: remove unused variable

On Thu, Apr 07, 2016 at 11:20:01PM +0300, Giedrius Statkevičius wrote: > `out' was assigned value but it was never used so remove it > > Signed-off-by: Giedrius Statkevičius > --- > drivers/platform/x86/asus-laptop.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git

Re: [PATCH] cpufreq: Skip all governor-related actions for cpufreq_suspended set

On 08-04-16, 23:54, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > Subject: [PATCH] cpufreq: Skip all governor-related actions for > cpufreq_suspended set > > Since governor operations are generally skipped if cpufreq_suspended > is set, do nothing at all in

Re: [PATCH] cpufreq: Skip all governor-related actions for cpufreq_suspended set

On 08-04-16, 23:54, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > Subject: [PATCH] cpufreq: Skip all governor-related actions for > cpufreq_suspended set > > Since governor operations are generally skipped if cpufreq_suspended > is set, do nothing at all in cpufreq_start_governor() in

Re: [PATCH] nilfs2: constify nilfs_sc_operations structures

On Sat, 9 Apr 2016 10:28:23 +0200, Julia Lawall wrote: > The nilfs_sc_operations structures are never modified, so declare them > as const. > > Done with the help of Coccinelle. > > Signed-off-by: Julia Lawall > Applied, thanks. Ryusuke Konishi > --- >

Re: [PATCH] nilfs2: constify nilfs_sc_operations structures

On Sat, 9 Apr 2016 10:28:23 +0200, Julia Lawall wrote: > The nilfs_sc_operations structures are never modified, so declare them > as const. > > Done with the help of Coccinelle. > > Signed-off-by: Julia Lawall > Applied, thanks. Ryusuke Konishi > --- > fs/nilfs2/segment.c | 10

RE: [PATCH v2] gpio: pca953x: add PCAL9535 interrupt support for Galileo Gen2

Thanks Linus. I think the below patch(in fixes branch) should be merged into devel branch too, since the below patch is depended by this one in devel branch. commit 9b8e3ec34318663affced3c14d960e78d760dd9a Author: Yong Li Date: Wed Mar 30 14:49:14 2016 +0800 gpio:

RE: [PATCH v2] gpio: pca953x: add PCAL9535 interrupt support for Galileo Gen2

Thanks Linus. I think the below patch(in fixes branch) should be merged into devel branch too, since the below patch is depended by this one in devel branch. commit 9b8e3ec34318663affced3c14d960e78d760dd9a Author: Yong Li Date: Wed Mar 30 14:49:14 2016 +0800 gpio: pca953x: Use correct

Re: [PATCH] platform:x86 decouple telemetry driver from the optional IPC resources

On Thu, Mar 31, 2016 at 02:28:09PM -0500, Aubrey Li wrote: > Currently the optional IPC resources prevent telemetry driver from > probing if these resources are not in ACPI table. This patch decouples > telemetry driver from these optional resources, so that telemetry driver > has dependency only

Re: [PATCH] platform:x86 decouple telemetry driver from the optional IPC resources

On Thu, Mar 31, 2016 at 02:28:09PM -0500, Aubrey Li wrote: > Currently the optional IPC resources prevent telemetry driver from > probing if these resources are not in ACPI table. This patch decouples > telemetry driver from these optional resources, so that telemetry driver > has dependency only

Re: [PATCH] Don't audit SECCOMP_KILL/RET_ERRNO when syscall auditing is disabled

> What kernel version are you using? I believe we fixed that in Linux > 4.5 with the following: This is 4.6-rc2. > > commit 96368701e1c89057bbf39222e965161c68a85b4b > From: Paul Moore > Date: Wed, 13 Jan 2016 10:18:55 -0400 (09:18 -0500) > > audit: force seccomp

Re: [PATCH] Don't audit SECCOMP_KILL/RET_ERRNO when syscall auditing is disabled

> What kernel version are you using? I believe we fixed that in Linux > 4.5 with the following: This is 4.6-rc2. > > commit 96368701e1c89057bbf39222e965161c68a85b4b > From: Paul Moore > Date: Wed, 13 Jan 2016 10:18:55 -0400 (09:18 -0500) > > audit: force seccomp event logging to honor

Re: [PATCH] intel_menlow: set cdev after null device check to avoid null pointer dereference

On Tue, Mar 29, 2016 at 03:13:43PM +0200, Rafael Wysocki wrote: > On Monday, March 28, 2016 11:18:05 AM Darren Hart wrote: > > On Mon, Mar 28, 2016 at 05:18:39PM +0100, Colin King wrote: > > > From: Colin Ian King > > > > > > intel_menlow_memory_remove sanity checks to

Re: [PATCH] intel_menlow: set cdev after null device check to avoid null pointer dereference

On Tue, Mar 29, 2016 at 03:13:43PM +0200, Rafael Wysocki wrote: > On Monday, March 28, 2016 11:18:05 AM Darren Hart wrote: > > On Mon, Mar 28, 2016 at 05:18:39PM +0100, Colin King wrote: > > > From: Colin Ian King > > > > > > intel_menlow_memory_remove sanity checks to see if device is null, >

Re: [PATCH] fujitsu-laptop: Support radio LED

On Thu, Mar 24, 2016 at 10:05:14PM +1030, Jonathan Woithe wrote: > This is a quick reply with preliminary information. I'll follow up in the > next few days with further details. > > On Tue, Mar 22, 2016 at 02:30:51PM +0100, Micha?? K??pie?? wrote: > > > > As for detecting whether the LED is

Re: [PATCH] fujitsu-laptop: Support radio LED

On Thu, Mar 24, 2016 at 10:05:14PM +1030, Jonathan Woithe wrote: > This is a quick reply with preliminary information. I'll follow up in the > next few days with further details. > > On Tue, Mar 22, 2016 at 02:30:51PM +0100, Micha?? K??pie?? wrote: > > > > As for detecting whether the LED is

Re: [GIT PULL] ext4 bug fixes for 4.6

Theodore Ts'o wrote: > The following changes since commit 243d50678583100855862bc084b8b307eea67f68: > > Merge branch 'overlayfs-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs (2016-03-22 > 13:11:15 -0700) > n> are available in the git repository at: > >

Re: [GIT PULL] ext4 bug fixes for 4.6

Theodore Ts'o wrote: > The following changes since commit 243d50678583100855862bc084b8b307eea67f68: > > Merge branch 'overlayfs-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs (2016-03-22 > 13:11:15 -0700) > n> are available in the git repository at: > >

OFFICIAL COMPLAINT AGAINST THE SINGAPORE GOVERNMENT FOR ALLEGEDLY FALSIFYING TEO EN MING'S MEDICAL RECORDS

Dear Sir/Madam, Please refer to the following letter (PDF format), addressed to the United Nations Human Rights Council, for more information and details about my predicament. The letter was dated 10th October 2014 Friday. Link:

OFFICIAL COMPLAINT AGAINST THE SINGAPORE GOVERNMENT FOR ALLEGEDLY FALSIFYING TEO EN MING'S MEDICAL RECORDS

Dear Sir/Madam, Please refer to the following letter (PDF format), addressed to the United Nations Human Rights Council, for more information and details about my predicament. The letter was dated 10th October 2014 Friday. Link:

Subtle Denial of Medical Treatment by the Singapore Government for Mr. Teo En Ming (Zhang Enming)

Dear Sir/Madam, Please refer to the following letter (PDF format), addressed to the United Nations Human Rights Council, for more information and details about my predicament. The letter was dated 14th March 2015 Saturday. Link:

Subtle Denial of Medical Treatment by the Singapore Government for Mr. Teo En Ming (Zhang Enming)

Dear Sir/Madam, Please refer to the following letter (PDF format), addressed to the United Nations Human Rights Council, for more information and details about my predicament. The letter was dated 14th March 2015 Saturday. Link:

Re: [PATCH v2 1/2] lib: lz4: fixed zram with lz4 on big endian machines

On (04/09/16 22:05), Rui Salvaterra wrote: > Note that the 64-bit preprocessor test is not a cleanup, it's part of > the fix, since those identifiers are bogus (for example, __ppc64__ > isn't defined anywhere else in the kernel, which means we'd fall into > the 32-bit definitions on ppc64). good

Re: [PATCH v2 1/2] lib: lz4: fixed zram with lz4 on big endian machines

On (04/09/16 22:05), Rui Salvaterra wrote: > Note that the 64-bit preprocessor test is not a cleanup, it's part of > the fix, since those identifiers are bogus (for example, __ppc64__ > isn't defined anywhere else in the kernel, which means we'd fall into > the 32-bit definitions on ppc64). good

Re: [PATCH v2 2/2] lib: lz4: cleanup unaligned access efficiency detection

On (04/09/16 22:05), Rui Salvaterra wrote: > These identifiers are bogus. The interested architectures should define > HAVE_EFFICIENT_UNALIGNED_ACCESS whenever relevant to do so. If this > isn't true for some arch, it should be fixed in the arch definition. yes, besides

Re: [PATCH v2 2/2] lib: lz4: cleanup unaligned access efficiency detection

On (04/09/16 22:05), Rui Salvaterra wrote: > These identifiers are bogus. The interested architectures should define > HAVE_EFFICIENT_UNALIGNED_ACCESS whenever relevant to do so. If this > isn't true for some arch, it should be fixed in the arch definition. yes, besides

Re: [PATCH] Don't audit SECCOMP_KILL/RET_ERRNO when syscall auditing is disabled

On Sat, Apr 9, 2016 at 11:07 AM, Andi Kleen wrote: > From: Andi Kleen > > When I run chrome on my opensuse system every time I open > a new tab the system log is spammed with: > > audit[16857]: SECCOMP auid=1000 uid=1000 gid=100 ses=1 pid=16857 >

Re: [PATCH] Don't audit SECCOMP_KILL/RET_ERRNO when syscall auditing is disabled

On Sat, Apr 9, 2016 at 11:07 AM, Andi Kleen wrote: > From: Andi Kleen > > When I run chrome on my opensuse system every time I open > a new tab the system log is spammed with: > > audit[16857]: SECCOMP auid=1000 uid=1000 gid=100 ses=1 pid=16857 > comm="chrome" exe="/opt/google/chrome/chrome"

[PATCH 4/8] tty: Replace ASYNC_CHECK_CD and update atomically

Replace ASYNC_CHECK_CD bit in the tty_port::flags field with TTY_PORT_CHECK_CD bit in the tty_port::iflags field. Introduce helpers tty_port_set_check_carrier() and tty_port_check_carrier() to abstract the atomic bit ops. Signed-off-by: Peter Hurley ---

[PATCH 1/8] tty: Define ASYNC_ replacement bits

Prepare for relocating kernel private state bits out of tty_port::flags field; tty_port::flags field is not atomic and can become corrupted by concurrent updates. It also suffers from the complication of sharing in a userspace-visible field which must be masked. Define new tty_port::iflags field

[PATCH 7/8] tty: mxser: Remove unused ASYNC_SHARE_IRQ flag

ASYNC*_SHARE_IRQ is no longer used; remove. Signed-off-by: Peter Hurley --- drivers/tty/mxser.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/tty/mxser.c b/drivers/tty/mxser.c index 7e8c27b..98d2bd1 100644 --- a/drivers/tty/mxser.c +++

[PATCH 3/8] tty: Replace ASYNC_NORMAL_ACTIVE bit and update atomically

Replace ASYNC_NORMAL_ACTIVE bit in the tty_port::flags field with TTY_PORT_ACTIVE bit in the tty_port::iflags field. Introduce helpers tty_port_set_active() and tty_port_active() to abstract atomic bit ops. Extract state changes from port lock sections, as this usage is broken and confused; the

[PATCH 1/8] tty: Define ASYNC_ replacement bits

Prepare for relocating kernel private state bits out of tty_port::flags field; tty_port::flags field is not atomic and can become corrupted by concurrent updates. It also suffers from the complication of sharing in a userspace-visible field which must be masked. Define new tty_port::iflags field

[PATCH 7/8] tty: mxser: Remove unused ASYNC_SHARE_IRQ flag

ASYNC*_SHARE_IRQ is no longer used; remove. Signed-off-by: Peter Hurley --- drivers/tty/mxser.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/tty/mxser.c b/drivers/tty/mxser.c index 7e8c27b..98d2bd1 100644 --- a/drivers/tty/mxser.c +++ b/drivers/tty/mxser.c @@ -2392,7 +2392,6 @@

[PATCH 3/8] tty: Replace ASYNC_NORMAL_ACTIVE bit and update atomically

Replace ASYNC_NORMAL_ACTIVE bit in the tty_port::flags field with TTY_PORT_ACTIVE bit in the tty_port::iflags field. Introduce helpers tty_port_set_active() and tty_port_active() to abstract atomic bit ops. Extract state changes from port lock sections, as this usage is broken and confused; the

[PATCH 4/8] tty: Replace ASYNC_CHECK_CD and update atomically

Replace ASYNC_CHECK_CD bit in the tty_port::flags field with TTY_PORT_CHECK_CD bit in the tty_port::iflags field. Introduce helpers tty_port_set_check_carrier() and tty_port_check_carrier() to abstract the atomic bit ops. Signed-off-by: Peter Hurley --- drivers/char/pcmcia/synclink_cs.c | 8

[PATCH 8/8] tty: core: Undefine ASYNC_* flags superceded by TTY_PORT* flags

Purposefully break out-of-tree driver compiles using kernel ASYNC_* bits which have been superceded by TTY_PORT* flags and their respective helper functions. Signed-off-by: Peter Hurley --- include/uapi/linux/tty_flags.h | 4 1 file changed, 4 insertions(+) diff

[PATCH 0/8] Replace kernel-defined ASYNC_ bits

As outlined in my January email ("RFC: out-of-tree tty driver breakage"), the tty/serial core uses 5 bits in the tty_port.flags field to manage state. They are: ASYNCB_INITIALIZED ASYNCB_SUSPENDED ASYNCB_NORMAL_ACTIVE ASYNCB_CTS_FLOW ASYNCB_CHECK_CD (NB: ASYNC_CLOSING was recently removed)

[PATCH 6/8] tty: Replace ASYNC_INITIALIZED bit and update atomically

Replace ASYNC_INITIALIZED bit in the tty_port::flags field with TTY_PORT_INITIALIZED bit in the tty_port::iflags field. Introduce helpers tty_port_set_initialized() and tty_port_initialized() to abstract atomic bit ops. Note: the transforms for test_and_set_bit() and test_and_clear_bit() are

[PATCH 8/8] tty: core: Undefine ASYNC_* flags superceded by TTY_PORT* flags

Purposefully break out-of-tree driver compiles using kernel ASYNC_* bits which have been superceded by TTY_PORT* flags and their respective helper functions. Signed-off-by: Peter Hurley --- include/uapi/linux/tty_flags.h | 4 1 file changed, 4 insertions(+) diff --git

[PATCH 0/8] Replace kernel-defined ASYNC_ bits

As outlined in my January email ("RFC: out-of-tree tty driver breakage"), the tty/serial core uses 5 bits in the tty_port.flags field to manage state. They are: ASYNCB_INITIALIZED ASYNCB_SUSPENDED ASYNCB_NORMAL_ACTIVE ASYNCB_CTS_FLOW ASYNCB_CHECK_CD (NB: ASYNC_CLOSING was recently removed)

[PATCH 6/8] tty: Replace ASYNC_INITIALIZED bit and update atomically

Replace ASYNC_INITIALIZED bit in the tty_port::flags field with TTY_PORT_INITIALIZED bit in the tty_port::iflags field. Introduce helpers tty_port_set_initialized() and tty_port_initialized() to abstract atomic bit ops. Note: the transforms for test_and_set_bit() and test_and_clear_bit() are

[PATCH 5/8] tty: Replace ASYNC_SUSPENDED bit and update atomically

Replace ASYNC_SUSPENDED bit in the tty_port::flags field with TTY_PORT_SUSPENDED bit in the tty_port::iflags field. Introduce helpers tty_port_set_suspended() and tty_port_suspended() to abstract atomic bit ops. Signed-off-by: Peter Hurley ---

[PATCH 2/8] tty: Replace ASYNC_CTS_FLOW bit and update atomically

Replace ASYNC_CTS_FLOW bit in the tty_port::flags field with TTY_PORT_CTS_FLOW bit in the tty_port::iflags field. Add tty_port_set_cts_flow() helper to abstract the atomic bit ops. Signed-off-by: Peter Hurley --- drivers/char/pcmcia/synclink_cs.c | 5 +

[PATCH 5/8] tty: Replace ASYNC_SUSPENDED bit and update atomically

Replace ASYNC_SUSPENDED bit in the tty_port::flags field with TTY_PORT_SUSPENDED bit in the tty_port::iflags field. Introduce helpers tty_port_set_suspended() and tty_port_suspended() to abstract atomic bit ops. Signed-off-by: Peter Hurley --- drivers/s390/char/con3215.c | 12 ++--

[PATCH 2/8] tty: Replace ASYNC_CTS_FLOW bit and update atomically

Replace ASYNC_CTS_FLOW bit in the tty_port::flags field with TTY_PORT_CTS_FLOW bit in the tty_port::iflags field. Add tty_port_set_cts_flow() helper to abstract the atomic bit ops. Signed-off-by: Peter Hurley --- drivers/char/pcmcia/synclink_cs.c | 5 + drivers/tty/amiserial.c

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On Sat, Apr 9, 2016 at 5:16 PM, Linus Torvalds wrote: > On Sat, Apr 9, 2016 at 5:06 PM, H. Peter Anvin wrote: >> >> Fixing the default permissions is trivial, of course. The intent from the >> beginning was to make a ptmx -> pts/ptmx, but user

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On Sat, Apr 9, 2016 at 5:16 PM, Linus Torvalds wrote: > On Sat, Apr 9, 2016 at 5:06 PM, H. Peter Anvin wrote: >> >> Fixing the default permissions is trivial, of course. The intent from the >> beginning was to make a ptmx -> pts/ptmx, but user space never did... > > That wasn't my point. > >

Re: [PATCH v2] x86/hpet: Reduce HPET counter read contention

On Fri, 8 Apr 2016, Waiman Long wrote: > This patch attempts to reduce HPET read contention by using the fact > that if more than one task are trying to access HPET at the same time, > it will be more efficient if one task in the group reads the HPET > counter and shares it with the rest of the

Re: [PATCH v2] x86/hpet: Reduce HPET counter read contention

On Fri, 8 Apr 2016, Waiman Long wrote: > This patch attempts to reduce HPET read contention by using the fact > that if more than one task are trying to access HPET at the same time, > it will be more efficient if one task in the group reads the HPET > counter and shares it with the rest of the

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On Sat, Apr 9, 2016 at 5:06 PM, H. Peter Anvin wrote: > > Fixing the default permissions is trivial, of course. The intent from the > beginning was to make a ptmx -> pts/ptmx, but user space never did... That wasn't my point. Because the permissions have never been usable, I

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On Sat, Apr 9, 2016 at 5:06 PM, H. Peter Anvin wrote: > > Fixing the default permissions is trivial, of course. The intent from the > beginning was to make a ptmx -> pts/ptmx, but user space never did... That wasn't my point. Because the permissions have never been usable, I pretty much

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On April 9, 2016 5:01:27 PM PDT, Linus Torvalds wrote: >On Sat, Apr 9, 2016 at 3:37 PM, H. Peter Anvin wrote: >> >> On the flipside, if we were to allow ourselves to break userspace, at >this point I would suggest making /dev/pts/ptmx have a

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On April 9, 2016 5:01:27 PM PDT, Linus Torvalds wrote: >On Sat, Apr 9, 2016 at 3:37 PM, H. Peter Anvin wrote: >> >> On the flipside, if we were to allow ourselves to break userspace, at >this point I would suggest making /dev/pts/ptmx have a different device >number and make the legacy

[PATCH] tty: Replace TTY_THROTTLED bit tests with tty_throttled()

Abstract TTY_THROTTLED bit tests with tty_throttled(). Signed-off-by: Peter Hurley --- drivers/char/pcmcia/synclink_cs.c | 2 +- drivers/mmc/card/sdio_uart.c | 2 +- drivers/net/usb/hso.c | 2 +- drivers/staging/fwserial/fwserial.c|

[PATCH] tty: Replace TTY_THROTTLED bit tests with tty_throttled()

Abstract TTY_THROTTLED bit tests with tty_throttled(). Signed-off-by: Peter Hurley --- drivers/char/pcmcia/synclink_cs.c | 2 +- drivers/mmc/card/sdio_uart.c | 2 +- drivers/net/usb/hso.c | 2 +- drivers/staging/fwserial/fwserial.c| 2 +-

[PATCH] tty: Replace TTY_IO_ERROR bit tests with tty_io_error()

Abstract TTY_IO_ERROR status test treewide with tty_io_error(). NB: tty->flags uses atomic bit ops; replace non-atomic bit test with test_bit(). Signed-off-by: Peter Hurley --- v3: redo of an earlier patch titled "tty: Use test_bit() with tty->flags" v2: rebase

[PATCH] tty: Replace TTY_IO_ERROR bit tests with tty_io_error()

Abstract TTY_IO_ERROR status test treewide with tty_io_error(). NB: tty->flags uses atomic bit ops; replace non-atomic bit test with test_bit(). Signed-off-by: Peter Hurley --- v3: redo of an earlier patch titled "tty: Use test_bit() with tty->flags" v2: rebase arch/ia64/hp/sim/simserial.c

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On Sat, Apr 9, 2016 at 3:37 PM, H. Peter Anvin wrote: > > On the flipside, if we were to allow ourselves to break userspace, at this > point I would suggest making /dev/pts/ptmx have a different device number and > make the legacy /dev/ptmx print a warning message, after which

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On Sat, Apr 9, 2016 at 3:37 PM, H. Peter Anvin wrote: > > On the flipside, if we were to allow ourselves to break userspace, at this > point I would suggest making /dev/pts/ptmx have a different device number and > make the legacy /dev/ptmx print a warning message, after which it can at >

Re: [PATCH 2/6] ARM: xen: Register with kernel restart handler

On Sat, 9 Apr 2016, Stefano Stabellini wrote: > On Fri, 8 Apr 2016, Guenter Roeck wrote: > > Register with kernel restart handler instead of setting arm_pm_restart > > directly. > > > > Select a high priority of 192 to ensure that default restart handlers > > are replaced if Xen is running. > >

Re: [PATCH 2/6] ARM: xen: Register with kernel restart handler

On Sat, 9 Apr 2016, Stefano Stabellini wrote: > On Fri, 8 Apr 2016, Guenter Roeck wrote: > > Register with kernel restart handler instead of setting arm_pm_restart > > directly. > > > > Select a high priority of 192 to ensure that default restart handlers > > are replaced if Xen is running. > >

Re: [PATCH 2/6] ARM: xen: Register with kernel restart handler

On Fri, 8 Apr 2016, Guenter Roeck wrote: > Register with kernel restart handler instead of setting arm_pm_restart > directly. > > Select a high priority of 192 to ensure that default restart handlers > are replaced if Xen is running. > > Signed-off-by: Guenter Roeck

Re: [PATCH 2/6] ARM: xen: Register with kernel restart handler

On Fri, 8 Apr 2016, Guenter Roeck wrote: > Register with kernel restart handler instead of setting arm_pm_restart > directly. > > Select a high priority of 192 to ensure that default restart handlers > are replaced if Xen is running. > > Signed-off-by: Guenter Roeck Reviewed-by: Stefano

Re: [PATCH] x86/vdso: Remove direct HPET access through the vDSO

On Thu, 7 Apr 2016, Andy Lutomirski wrote: > Allowing user code to map the HPET is problematic. HPET > implementations are notoriously buggy, and there are probably many > machines on which even MMIO reads from bogus HPET addresses are > problematic. > > We have a report that the Dell Precision

Re: [PATCH] x86/vdso: Remove direct HPET access through the vDSO

On Thu, 7 Apr 2016, Andy Lutomirski wrote: > Allowing user code to map the HPET is problematic. HPET > implementations are notoriously buggy, and there are probably many > machines on which even MMIO reads from bogus HPET addresses are > problematic. > > We have a report that the Dell Precision

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On April 9, 2016 7:45:46 AM PDT, ebied...@xmission.com wrote: >"H. Peter Anvin" writes: > >> On April 9, 2016 6:09:09 AM PDT, One Thousand Gnomes > wrote: >>> If anyone has a better idea on how userspace should connect the >>>master pty file

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On April 9, 2016 7:45:46 AM PDT, ebied...@xmission.com wrote: >"H. Peter Anvin" writes: > >> On April 9, 2016 6:09:09 AM PDT, One Thousand Gnomes > wrote: >>> If anyone has a better idea on how userspace should connect the >>>master pty file descriptor the slave file descriptor, I would

Re: [RFC 0/4] NFC: pn533: support for pn532 via I2C

Hi Michael, On Fri, Mar 25, 2016 at 03:46:50PM +0100, Michael Thalmeier wrote: > Michael Thalmeier (4): > NFC: pn533: Send ATR_REQ only if NFC_PROTO_NFC_DEP bit is set in > poll_protocols > NFC: pn533: fix deadlock when socket is closed while processing > command > NFC: pn533:

Re: [RFC 4/4] NFC: pn533: add I2C phy driver

Hi Michael, On Fri, Mar 25, 2016 at 03:46:54PM +0100, Michael Thalmeier wrote: > This adds the I2C phy interface for the pn533 driver. This way the driver can > be used to interact with I2C connected pn532. > > Signed-off-by: Michael Thalmeier > --- >

Re: [RFC 0/4] NFC: pn533: support for pn532 via I2C

Hi Michael, On Fri, Mar 25, 2016 at 03:46:50PM +0100, Michael Thalmeier wrote: > Michael Thalmeier (4): > NFC: pn533: Send ATR_REQ only if NFC_PROTO_NFC_DEP bit is set in > poll_protocols > NFC: pn533: fix deadlock when socket is closed while processing > command > NFC: pn533:

Re: [RFC 4/4] NFC: pn533: add I2C phy driver

Hi Michael, On Fri, Mar 25, 2016 at 03:46:54PM +0100, Michael Thalmeier wrote: > This adds the I2C phy interface for the pn533 driver. This way the driver can > be used to interact with I2C connected pn532. > > Signed-off-by: Michael Thalmeier > --- > drivers/nfc/pn533/Kconfig | 11 ++ >

[PATCH v2 1/2] lib: lz4: fixed zram with lz4 on big endian machines

Based on Sergey's test patch [1], this fixes zram with lz4 compression on big endian cpus. Note that the 64-bit preprocessor test is not a cleanup, it's part of the fix, since those identifiers are bogus (for example, __ppc64__ isn't defined anywhere else in the kernel, which means we'd fall into

[PATCH v2 1/2] lib: lz4: fixed zram with lz4 on big endian machines

Based on Sergey's test patch [1], this fixes zram with lz4 compression on big endian cpus. Note that the 64-bit preprocessor test is not a cleanup, it's part of the fix, since those identifiers are bogus (for example, __ppc64__ isn't defined anywhere else in the kernel, which means we'd fall into

[PATCH v2 2/2] lib: lz4: cleanup unaligned access efficiency detection

These identifiers are bogus. The interested architectures should define HAVE_EFFICIENT_UNALIGNED_ACCESS whenever relevant to do so. If this isn't true for some arch, it should be fixed in the arch definition. Signed-off-by: Rui Salvaterra --- lib/lz4/lz4defs.h | 4 +--- 1

[PATCH v2 0/2] lib: lz4: fix for big endian and cleanup

v2: - Addressed GregKH's review and comments. Hi, The first patch fixes zram with lz4 compression on ppc64 (and big endian architectures with efficient unaligned access), the second is just a cleanup. Thanks, Rui Rui Salvaterra (2): lib: lz4: fixed zram with lz4 on big endian

[PATCH v2 2/2] lib: lz4: cleanup unaligned access efficiency detection

These identifiers are bogus. The interested architectures should define HAVE_EFFICIENT_UNALIGNED_ACCESS whenever relevant to do so. If this isn't true for some arch, it should be fixed in the arch definition. Signed-off-by: Rui Salvaterra --- lib/lz4/lz4defs.h | 4 +--- 1 file changed, 1

[PATCH v2 0/2] lib: lz4: fix for big endian and cleanup

v2: - Addressed GregKH's review and comments. Hi, The first patch fixes zram with lz4 compression on ppc64 (and big endian architectures with efficient unaligned access), the second is just a cleanup. Thanks, Rui Rui Salvaterra (2): lib: lz4: fixed zram with lz4 on big endian

[PATCH 6/6] cifs: don't bother with kmap on read_pages side

just do ITER_BVEC recvmsg Signed-off-by: Al Viro --- fs/cifs/cifsproto.h | 7 +++--- fs/cifs/connect.c | 65 - fs/cifs/file.c | 53 ++- 3 files changed, 55 insertions(+),

[PATCH 5/6] cifs_readv_receive: use cifs_read_from_socket()

Signed-off-by: Al Viro --- fs/cifs/cifssmb.c | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c index 76fcb50..3da077a 100644 --- a/fs/cifs/cifssmb.c +++ b/fs/cifs/cifssmb.c @@ -1447,10 +1447,8 @@

[PATCH 5/6] cifs_readv_receive: use cifs_read_from_socket()

Signed-off-by: Al Viro --- fs/cifs/cifssmb.c | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c index 76fcb50..3da077a 100644 --- a/fs/cifs/cifssmb.c +++ b/fs/cifs/cifssmb.c @@ -1447,10 +1447,8 @@ cifs_readv_receive(struct

[PATCH 6/6] cifs: don't bother with kmap on read_pages side

just do ITER_BVEC recvmsg Signed-off-by: Al Viro --- fs/cifs/cifsproto.h | 7 +++--- fs/cifs/connect.c | 65 - fs/cifs/file.c | 53 ++- 3 files changed, 55 insertions(+), 70 deletions(-) diff

[PATCH 3/6] cifs: quit playing games with draining iovecs

... and use ITER_BVEC for the page part of request to send Signed-off-by: Al Viro --- fs/cifs/cifsproto.h | 2 - fs/cifs/transport.c | 141 +++- 2 files changed, 41 insertions(+), 102 deletions(-) diff --git

[PATCH 4/6] cifs: no need to wank with copying and advancing iovec on recvmsg side either

Signed-off-by: Al Viro --- fs/cifs/cifsglob.h | 2 -- fs/cifs/connect.c | 72 -- 2 files changed, 5 insertions(+), 69 deletions(-) diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h index d21da9f..df03c5e 100644

  1   2   3   >