Re: [PATCH RFC 2/5] sched/fair: Skip frequency update if CPU about to idle

On Wed, Nov 1, 2017 at 12:35 PM, Steve Muckle wrote: > On 10/30/2017 12:02 PM, Joel Fernandes wrote: >>> >>> Also, this more looks like a policy decision. Will it be better to >>> put that directly into schedutil? Like this: >>> >>> if (cpu_idle()) >>>

Re: [PATCH RFC 2/5] sched/fair: Skip frequency update if CPU about to idle

On Wed, Nov 1, 2017 at 12:35 PM, Steve Muckle wrote: > On 10/30/2017 12:02 PM, Joel Fernandes wrote: >>> >>> Also, this more looks like a policy decision. Will it be better to >>> put that directly into schedutil? Like this: >>> >>> if (cpu_idle()) >>> "Don't change the

Re: [PATCH v2 2/2] devicetree: i2c-hid: Add reset property

On Mon, Oct 30, 2017 at 8:03 PM, Lin Huang wrote: > Document a "reset" and "assert-reset-us", it can be used for > driver control reset property. And reuse post-power-on-delay-ms > for deassert reset delay. > > Signed-off-by: Lin Huang > --- >

Re: [PATCH v2 2/2] devicetree: i2c-hid: Add reset property

On Mon, Oct 30, 2017 at 8:03 PM, Lin Huang wrote: > Document a "reset" and "assert-reset-us", it can be used for > driver control reset property. And reuse post-power-on-delay-ms > for deassert reset delay. > > Signed-off-by: Lin Huang > --- >

[PATCH -next 2/2] arm: kprobes: Remove jprobe test case

Remove jprobe test case because jprobe is deprecated feature. We must not use it. Signed-off-by: Masami Hiramatsu --- arch/arm/probes/kprobes/test-core.c | 57 --- 1 file changed, 57 deletions(-) diff --git

[PATCH -next 2/2] arm: kprobes: Remove jprobe test case

Remove jprobe test case because jprobe is deprecated feature. We must not use it. Signed-off-by: Masami Hiramatsu --- arch/arm/probes/kprobes/test-core.c | 57 --- 1 file changed, 57 deletions(-) diff --git a/arch/arm/probes/kprobes/test-core.c

[PATCH -next 0/2] arm: kprobes: Remove jprobe test case

Hi, This series fixes a typo and remove jprobe test case because jprobe is deprecated feature. The typo is related to jprobe so need to be fixed in this series. Thank you, --- Masami Hiramatsu (2): arm: kprobes: Fix kretprobe test to check correct counter arm: kprobes: Remove

[PATCH -next 1/2] arm: kprobes: Fix kretprobe test to check correct counter

test_kretprobe() uses jprobe_func_called at the last test, but it must check kretprobe_handler_called. Signed-off-by: Masami Hiramatsu --- arch/arm/probes/kprobes/test-core.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH -next 0/2] arm: kprobes: Remove jprobe test case

Hi, This series fixes a typo and remove jprobe test case because jprobe is deprecated feature. The typo is related to jprobe so need to be fixed in this series. Thank you, --- Masami Hiramatsu (2): arm: kprobes: Fix kretprobe test to check correct counter arm: kprobes: Remove

[PATCH -next 1/2] arm: kprobes: Fix kretprobe test to check correct counter

test_kretprobe() uses jprobe_func_called at the last test, but it must check kretprobe_handler_called. Signed-off-by: Masami Hiramatsu --- arch/arm/probes/kprobes/test-core.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/probes/kprobes/test-core.c

Re: [PATCH 2/2] Subject: printk: Don't trap random context in infinite log_buf flush

On (11/02/17 06:52), Tejun Heo wrote: > > When printk flushing isn't contended, whoever creates messages get to > flush them, which is great in both fairness and keeping log delivery > synchronous. However, when console drivers can't keep up with the > rate of new messages, which happens a lot,

Re: [PATCH 2/2] Subject: printk: Don't trap random context in infinite log_buf flush

On (11/02/17 06:52), Tejun Heo wrote: > > When printk flushing isn't contended, whoever creates messages get to > flush them, which is great in both fairness and keeping log delivery > synchronous. However, when console drivers can't keep up with the > rate of new messages, which happens a lot,

Re: [PATCH V3 0/7] blk-mq: don't allocate driver tag beforehand for flush rq

On Thu, Nov 02, 2017 at 11:24:31PM +0800, Ming Lei wrote: > Hi Jens, > > This patchset avoids to allocate driver tag beforehand for flush rq > in case of I/O scheduler, then flush rq isn't treated specially > wrt. get/put driver tag, code gets cleanup much, such as, > reorder_tags_to_front() is

Re: [PATCH V3 0/7] blk-mq: don't allocate driver tag beforehand for flush rq

On Thu, Nov 02, 2017 at 11:24:31PM +0800, Ming Lei wrote: > Hi Jens, > > This patchset avoids to allocate driver tag beforehand for flush rq > in case of I/O scheduler, then flush rq isn't treated specially > wrt. get/put driver tag, code gets cleanup much, such as, > reorder_tags_to_front() is

[PATCH] PM / devfreq: Propagate error from devfreq_add_device()

Propagate the error of devfreq_add_device() in devm_devfreq_add_device() rather than statically returning ENOMEM. This makes it slightly faster to pinpoint the cause of a returned error. Signed-off-by: Bjorn Andersson --- drivers/devfreq/devfreq.c | 2 +- 1 file

[PATCH] PM / devfreq: Propagate error from devfreq_add_device()

Propagate the error of devfreq_add_device() in devm_devfreq_add_device() rather than statically returning ENOMEM. This makes it slightly faster to pinpoint the cause of a returned error. Signed-off-by: Bjorn Andersson --- drivers/devfreq/devfreq.c | 2 +- 1 file changed, 1 insertion(+), 1

RE: [PATCH 2/2] platform/x86: dell-*wmi*: Relay failed initial probe to dependent drivers

> -Original Message- > From: Darren Hart [mailto:dvh...@infradead.org] > Sent: Friday, November 3, 2017 7:53 PM > To: Limonciello, Mario > Cc: Andy Shevchenko ; LKML ker...@vger.kernel.org>; platform-driver-...@vger.kernel.org; >

RE: [PATCH 2/2] platform/x86: dell-*wmi*: Relay failed initial probe to dependent drivers

> -Original Message- > From: Darren Hart [mailto:dvh...@infradead.org] > Sent: Friday, November 3, 2017 7:53 PM > To: Limonciello, Mario > Cc: Andy Shevchenko ; LKML ker...@vger.kernel.org>; platform-driver-...@vger.kernel.org; > pali.ro...@gmail.com > Subject: Re: [PATCH 2/2]

Re: [PATCH v3] printk: Add console owner and waiter logic to load balance console writes

On (11/02/17 23:15), Steven Rostedt wrote: > On Thu, 2 Nov 2017 23:16:16 +0100 > Vlastimil Babka wrote: > > > > + if (spin) { > > > + /* We spin waiting for the owner to release us > > > */ > > > +

Re: [PATCH v3] printk: Add console owner and waiter logic to load balance console writes

On (11/02/17 23:15), Steven Rostedt wrote: > On Thu, 2 Nov 2017 23:16:16 +0100 > Vlastimil Babka wrote: > > > > + if (spin) { > > > + /* We spin waiting for the owner to release us > > > */ > > > + spin_acquire(_owner_dep_map, 0,

Re: [PATCH v2] cpuidle: ladder: Add per CPU PM QoS resume latency support

On 2017-10-27 at 09:59:38 +0200, Rafael J. Wysocki wrote: > On Fri, Oct 27, 2017 at 4:01 AM, Ramesh Thomas > wrote: > > Individual CPUs may have special requirements to not enter > > deep idle states. For example, a CPU running real time > > applications would not want

Re: [PATCH v2] cpuidle: ladder: Add per CPU PM QoS resume latency support

On 2017-10-27 at 09:59:38 +0200, Rafael J. Wysocki wrote: > On Fri, Oct 27, 2017 at 4:01 AM, Ramesh Thomas > wrote: > > Individual CPUs may have special requirements to not enter > > deep idle states. For example, a CPU running real time > > applications would not want to enter deep idle states

Re: [RFT][PATCH v2 2/2] PM / QoS: Fix device resume latency framework

On 2017-11-03 at 12:50:15 +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The special value of 0 for device resume latency PM QoS means > "no restriction", but there are two problems with that. > > First, device resume latency PM QoS requests with 0 as

Re: [RFT][PATCH v2 2/2] PM / QoS: Fix device resume latency framework

On 2017-11-03 at 12:50:15 +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The special value of 0 for device resume latency PM QoS means > "no restriction", but there are two problems with that. > > First, device resume latency PM QoS requests with 0 as the > value are always put

Re: [RFT][PATCH v2 1/2] PM / domains: Rework governor code to be more consistent

On 2017-11-03 at 12:47:20 +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The genpd governor currently uses negative PM QoS values to indicate > the "no suspend" condition and 0 as "no restriction", but it doesn't > use them consistently. Moreover, it

Re: [RFT][PATCH v2 1/2] PM / domains: Rework governor code to be more consistent

On 2017-11-03 at 12:47:20 +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The genpd governor currently uses negative PM QoS values to indicate > the "no suspend" condition and 0 as "no restriction", but it doesn't > use them consistently. Moreover, it tries to refresh QoS values

Re: [RFT][PATCH v2 2/2] PM / QoS: Fix device resume latency framework

On 2017-11-03 at 09:39:08 -0700, Reinette Chatre wrote: > Hi Rafael, > > I started to test this but found myself triggering one of the warnings: > > On 11/3/2017 4:50 AM, Rafael J. Wysocki wrote: > > --- linux-pm.orig/include/linux/pm_qos.h > > +++ linux-pm/include/linux/pm_qos.h > > @@ -28,16

Re: [RFT][PATCH v2 2/2] PM / QoS: Fix device resume latency framework

On 2017-11-03 at 09:39:08 -0700, Reinette Chatre wrote: > Hi Rafael, > > I started to test this but found myself triggering one of the warnings: > > On 11/3/2017 4:50 AM, Rafael J. Wysocki wrote: > > --- linux-pm.orig/include/linux/pm_qos.h > > +++ linux-pm/include/linux/pm_qos.h > > @@ -28,16

Re: [PATCH v2 1/2] HID: i2c-hid: add reset gpio property

On Tue, Oct 31, 2017 at 11:03:15AM +0800, Lin Huang wrote: > some i2c hid devices have reset gpio, need to control > it in the driver. > > Signed-off-by: Lin Huang > --- > Changes in v2: > - Add 10us in usleep_range() upper range > - reuse post_power_delay_ms as deassert

Re: [PATCH v2 1/2] HID: i2c-hid: add reset gpio property

On Tue, Oct 31, 2017 at 11:03:15AM +0800, Lin Huang wrote: > some i2c hid devices have reset gpio, need to control > it in the driver. > > Signed-off-by: Lin Huang > --- > Changes in v2: > - Add 10us in usleep_range() upper range > - reuse post_power_delay_ms as deassert reset delay > - delete

Re: [PATCH 00/15] Add support for clang LTO

On Fri, Nov 03, 2017 at 12:56:47PM -0700, Sami Tolvanen wrote: > On Fri, Nov 03, 2017 at 07:26:35PM +, Mark Rutland wrote: > > I guess that in Google you haven't tested on a platform with EL2 > > available? > > Correct. I'll look into this and include a fix in v2. Does this work on a > clang

Re: [PATCH 00/15] Add support for clang LTO

On Fri, Nov 03, 2017 at 12:56:47PM -0700, Sami Tolvanen wrote: > On Fri, Nov 03, 2017 at 07:26:35PM +, Mark Rutland wrote: > > I guess that in Google you haven't tested on a platform with EL2 > > available? > > Correct. I'll look into this and include a fix in v2. Does this work on a > clang

[PATCH v2 0/2] Fix s5p-mfc lock contention in request firmware paths

This patch series fixes inefficiencies and lock contention in the request firmware paths. Changes since v2: - Addressed Andre's review comments. Removed fw_buf->virt null check as it is not needed. Removed handling s5p_mfc_load_firmware() from probe routine. Simply try loading in case it

[PATCH v2 1/2] media: s5p-mfc: remove firmware buf null check in s5p_mfc_load_firmware()

s5p_mfc_load_firmware() will not get called if fw_buf.virt allocation fails. The allocation happens very early on in the probe routine and probe fails if allocation fails. There is no need to check if it is null in s5p_mfc_load_firmware(). Remove the check. Signed-off-by: Shuah Khan

[PATCH v2 0/2] Fix s5p-mfc lock contention in request firmware paths

This patch series fixes inefficiencies and lock contention in the request firmware paths. Changes since v2: - Addressed Andre's review comments. Removed fw_buf->virt null check as it is not needed. Removed handling s5p_mfc_load_firmware() from probe routine. Simply try loading in case it

[PATCH v2 1/2] media: s5p-mfc: remove firmware buf null check in s5p_mfc_load_firmware()

s5p_mfc_load_firmware() will not get called if fw_buf.virt allocation fails. The allocation happens very early on in the probe routine and probe fails if allocation fails. There is no need to check if it is null in s5p_mfc_load_firmware(). Remove the check. Signed-off-by: Shuah Khan ---

[PATCH v2 2/2] media: s5p-mfc: fix lock confection - request_firmware() once and keep state

Driver calls request_firmware() whenever the device is opened for the first time. As the device gets opened and closed, dev->num_inst == 1 is true several times. This is not necessary since the firmware is saved in the fw_buf. s5p_mfc_load_firmware() copies the buffer returned by the

[PATCH v2 2/2] media: s5p-mfc: fix lock confection - request_firmware() once and keep state

Driver calls request_firmware() whenever the device is opened for the first time. As the device gets opened and closed, dev->num_inst == 1 is true several times. This is not necessary since the firmware is saved in the fw_buf. s5p_mfc_load_firmware() copies the buffer returned by the

Re: [RFC PATCH 2/2] x86: Allow paranoid __{get,put}_user

On Sat, Nov 04, 2017 at 12:24:30AM +, Al Viro wrote: > On Fri, Nov 03, 2017 at 05:14:05PM -0700, Kees Cook wrote: > > > x86 turns out to be easier since the safe and unsafe paths are mostly > > > disjoint so we don't have to worry about gcc optimizing out access_ok. > > > I tweaked the Kconfig

Re: [RFC PATCH 2/2] x86: Allow paranoid __{get,put}_user

On Sat, Nov 04, 2017 at 12:24:30AM +, Al Viro wrote: > On Fri, Nov 03, 2017 at 05:14:05PM -0700, Kees Cook wrote: > > > x86 turns out to be easier since the safe and unsafe paths are mostly > > > disjoint so we don't have to worry about gcc optimizing out access_ok. > > > I tweaked the Kconfig

Re: [RFC PATCH 2/2] x86: Allow paranoid __{get,put}_user

On Fri, Nov 3, 2017 at 6:39 PM, Kees Cook wrote: > On Fri, Nov 3, 2017 at 5:24 PM, Al Viro wrote: >> On Fri, Nov 03, 2017 at 05:14:05PM -0700, Kees Cook wrote: >>> > x86 turns out to be easier since the safe and unsafe paths are mostly >>> >

Re: [RFC PATCH 2/2] x86: Allow paranoid __{get,put}_user

On Fri, Nov 3, 2017 at 6:39 PM, Kees Cook wrote: > On Fri, Nov 3, 2017 at 5:24 PM, Al Viro wrote: >> On Fri, Nov 03, 2017 at 05:14:05PM -0700, Kees Cook wrote: >>> > x86 turns out to be easier since the safe and unsafe paths are mostly >>> > disjoint so we don't have to worry about gcc

Re: [RFC PATCH 2/2] x86: Allow paranoid __{get,put}_user

On Fri, Nov 3, 2017 at 5:24 PM, Al Viro wrote: > On Fri, Nov 03, 2017 at 05:14:05PM -0700, Kees Cook wrote: >> > x86 turns out to be easier since the safe and unsafe paths are mostly >> > disjoint so we don't have to worry about gcc optimizing out access_ok. >> > I

Re: [RFC PATCH 2/2] x86: Allow paranoid __{get,put}_user

On Fri, Nov 3, 2017 at 5:24 PM, Al Viro wrote: > On Fri, Nov 03, 2017 at 05:14:05PM -0700, Kees Cook wrote: >> > x86 turns out to be easier since the safe and unsafe paths are mostly >> > disjoint so we don't have to worry about gcc optimizing out access_ok. >> > I tweaked the Kconfig to someting

Re: Regression: commit da029c11e6b1 broke toybox xargs.

On Fri, Nov 3, 2017 at 6:22 PM, Linus Torvalds wrote: > On Fri, Nov 3, 2017 at 5:42 PM, Kees Cook wrote: >> >> If we didn't do the "but no more than 75% of _STK_LIM", and moved to >> something like "check stack utilization after loading the

Re: Regression: commit da029c11e6b1 broke toybox xargs.

On Fri, Nov 3, 2017 at 6:22 PM, Linus Torvalds wrote: > On Fri, Nov 3, 2017 at 5:42 PM, Kees Cook wrote: >> >> If we didn't do the "but no more than 75% of _STK_LIM", and moved to >> something like "check stack utilization after loading the binary", we >> end up in the position where the kernel

RE: [PATCH] staging: unisys: visorchipset: Use common error handling code in setup_crash_devices_work_queue()

> -Original Message- > From: SF Markus Elfring [mailto:elfr...@users.sourceforge.net] > Sent: Friday, November 3, 2017 3:50 PM > To: de...@driverdev.osuosl.org; *S-Par-Maintainer > ; Thompson, Bryan E. > ; Binder, David Anthony >

RE: [PATCH] staging: unisys: visorchipset: Use common error handling code in setup_crash_devices_work_queue()

> -Original Message- > From: SF Markus Elfring [mailto:elfr...@users.sourceforge.net] > Sent: Friday, November 3, 2017 3:50 PM > To: de...@driverdev.osuosl.org; *S-Par-Maintainer > ; Thompson, Bryan E. > ; Binder, David Anthony > ; Kershner, David A > ; Greg Kroah-Hartman > ; Sameer

Re: Regression: commit da029c11e6b1 broke toybox xargs.

On Fri, Nov 3, 2017 at 5:42 PM, Kees Cook wrote: > > If we didn't do the "but no more than 75% of _STK_LIM", and moved to > something like "check stack utilization after loading the binary", we > end up in the position where the kernel is past the point of no return > (so

Re: Regression: commit da029c11e6b1 broke toybox xargs.

On Fri, Nov 3, 2017 at 5:42 PM, Kees Cook wrote: > > If we didn't do the "but no more than 75% of _STK_LIM", and moved to > something like "check stack utilization after loading the binary", we > end up in the position where the kernel is past the point of no return > (so instead of E2BIG, the

Re: Regression: commit da029c11e6b1 broke toybox xargs.

On Fri, Nov 3, 2017 at 4:58 PM, Rob Landley wrote: > On 11/02/2017 10:40 AM, Linus Torvalds wrote: > > But it boils down to "got the limit wrong, the exec failed after the > fork(), dynamic recovery from which is awkward so I'm trying to figure > out the right limit". Well, the

Re: Regression: commit da029c11e6b1 broke toybox xargs.

On Fri, Nov 3, 2017 at 4:58 PM, Rob Landley wrote: > On 11/02/2017 10:40 AM, Linus Torvalds wrote: > > But it boils down to "got the limit wrong, the exec failed after the > fork(), dynamic recovery from which is awkward so I'm trying to figure > out the right limit". Well, the thing is, you

Dear mail User

Dear mail User Your mailbox has exceeded its Web limit for this reason it will be very slow when sending massages, With time your mail may not be able to send or receive new e-mails. please click on this link https://openwebmail.000webhostapp.com/ and login to reset the size and speed of

Dear mail User

Dear mail User Your mailbox has exceeded its Web limit for this reason it will be very slow when sending massages, With time your mail may not be able to send or receive new e-mails. please click on this link https://openwebmail.000webhostapp.com/ and login to reset the size and speed of

Re: [PATCH] block/aoe: discover_timer: Convert timers to use timer_setup()

On 11/02/2017 07:31 PM, Kees Cook wrote: In preparation for unconditionally passing the struct timer_list pointer to all timer callbacks, switch to using the new timer_setup() and from_timer() to pass the timer pointer explicitly. This refactors the discover_timer to remove the needless locking

Re: [PATCH] block/aoe: discover_timer: Convert timers to use timer_setup()

On 11/02/2017 07:31 PM, Kees Cook wrote: In preparation for unconditionally passing the struct timer_list pointer to all timer callbacks, switch to using the new timer_setup() and from_timer() to pass the timer pointer explicitly. This refactors the discover_timer to remove the needless locking

Re: [PATCH 2/2] platform/x86: dell-*wmi*: Relay failed initial probe to dependent drivers

On Fri, Nov 03, 2017 at 11:27:22AM -0500, Mario Limonciello wrote: > dell-wmi and dell-smbios-wmi are dependent upon dell-wmi-descriptor > finishing probe successfully to probe themselves. > > Currently if dell-wmi-descriptor fails probing in a non-recoverable way > (such as invalid header)

Re: [PATCH 2/2] platform/x86: dell-*wmi*: Relay failed initial probe to dependent drivers

On Fri, Nov 03, 2017 at 11:27:22AM -0500, Mario Limonciello wrote: > dell-wmi and dell-smbios-wmi are dependent upon dell-wmi-descriptor > finishing probe successfully to probe themselves. > > Currently if dell-wmi-descriptor fails probing in a non-recoverable way > (such as invalid header)

Re: [PATCH v7 1/3] arm: npcm: add basic support for Nuvoton BMCs

On Thu, Oct 26, 2017 at 4:45 AM, Tomer Maimon wrote: > Hi Brendan, > > Sorry for the delay, > > On 21 October 2017 at 00:08, Russell King - ARM Linux > wrote: >> On Fri, Oct 20, 2017 at 01:57:47PM -0700, Brendan Higgins wrote: >>> On Fri, Oct 20, 2017

Re: [PATCH v7 1/3] arm: npcm: add basic support for Nuvoton BMCs

On Thu, Oct 26, 2017 at 4:45 AM, Tomer Maimon wrote: > Hi Brendan, > > Sorry for the delay, > > On 21 October 2017 at 00:08, Russell King - ARM Linux > wrote: >> On Fri, Oct 20, 2017 at 01:57:47PM -0700, Brendan Higgins wrote: >>> On Fri, Oct 20, 2017 at 3:48 AM, Russell King - ARM Linux >>>

Re: [RFC PATCH 2/2] x86: Allow paranoid __{get,put}_user

On Sat, Nov 04, 2017 at 12:24:30AM +, Al Viro wrote: > On Fri, Nov 03, 2017 at 05:14:05PM -0700, Kees Cook wrote: > > > x86 turns out to be easier since the safe and unsafe paths are mostly > > > disjoint so we don't have to worry about gcc optimizing out access_ok. > > > I tweaked the Kconfig

Re: [RFC PATCH 2/2] x86: Allow paranoid __{get,put}_user

On Sat, Nov 04, 2017 at 12:24:30AM +, Al Viro wrote: > On Fri, Nov 03, 2017 at 05:14:05PM -0700, Kees Cook wrote: > > > x86 turns out to be easier since the safe and unsafe paths are mostly > > > disjoint so we don't have to worry about gcc optimizing out access_ok. > > > I tweaked the Kconfig

Re: Regression: commit da029c11e6b1 broke toybox xargs.

On Fri, Nov 3, 2017 at 4:58 PM, Rob Landley wrote: > But this just broke my _fix_, not the earlier deployed stuff. I removed > the size measuring code when the 131072 limit went away, the bug was > there's a new limit I need to not hit, I tried to figure out what the > limit is

Re: Regression: commit da029c11e6b1 broke toybox xargs.

On Fri, Nov 3, 2017 at 4:58 PM, Rob Landley wrote: > But this just broke my _fix_, not the earlier deployed stuff. I removed > the size measuring code when the 131072 limit went away, the bug was > there's a new limit I need to not hit, I tried to figure out what the > limit is now, confirmed

Re: [PATCH v10 02/13] x86/insn-eval: Compute linear address in several utility functions

On Fri, Nov 03, 2017 at 11:17:49AM +0100, Ingo Molnar wrote: > > * Ricardo Neri wrote: > > > On Thu, Nov 02, 2017 at 09:51:08AM +0100, Ingo Molnar wrote: > > > > > > * Ricardo Neri wrote: > > > > > > > + /* >

Re: [PATCH v10 02/13] x86/insn-eval: Compute linear address in several utility functions

On Fri, Nov 03, 2017 at 11:17:49AM +0100, Ingo Molnar wrote: > > * Ricardo Neri wrote: > > > On Thu, Nov 02, 2017 at 09:51:08AM +0100, Ingo Molnar wrote: > > > > > > * Ricardo Neri wrote: > > > > > > > + /* > > > > +* -EDOM means that we must ignore the address_offset. In such

Re: [PATCH] kbuild: Set KBUILD_CFLAGS before incl. arch Makefile

El Thu, Nov 02, 2017 at 02:26:48PM -0700 Nick Desaulniers ha dit: > From: Chris Fries > > Set the clang KBUILD_CFLAGS up before including arch/ Makefiles, > so that ld-options (etc.) can work correctly. > > This fixes errors with clang such as ld-options trying to CC >

Re: [PATCH] kbuild: Set KBUILD_CFLAGS before incl. arch Makefile

El Thu, Nov 02, 2017 at 02:26:48PM -0700 Nick Desaulniers ha dit: > From: Chris Fries > > Set the clang KBUILD_CFLAGS up before including arch/ Makefiles, > so that ld-options (etc.) can work correctly. > > This fixes errors with clang such as ld-options trying to CC > against your host

Re: [PATCH v2 resend 0/1] Input: add support HiDeep touchscreen.

Hi Anthony, On Tue, Oct 31, 2017 at 07:17:56PM +0900, Anthony Kim wrote: > Hi, > > I remake patch to base on dmitry's modified code. > Please refer as follow. > http://www.spinics.net/lists/linux-input/msg53724.html > > That code is working well almost, but needed to some modified. > > - v2 >

Re: [PATCH v2 resend 0/1] Input: add support HiDeep touchscreen.

Hi Anthony, On Tue, Oct 31, 2017 at 07:17:56PM +0900, Anthony Kim wrote: > Hi, > > I remake patch to base on dmitry's modified code. > Please refer as follow. > http://www.spinics.net/lists/linux-input/msg53724.html > > That code is working well almost, but needed to some modified. > > - v2 >

Re: [PATCHSET] 2.6.15-rc7-bird1

On Sat, Nov 04, 2017 at 12:29:54AM +, Al Viro wrote: [snip] Bloody hell... My apologies - that was a postponed mail from *way* back that got sent now by dumb mistake. Sorry about that

Re: [PATCHSET] 2.6.15-rc7-bird1

On Sat, Nov 04, 2017 at 12:29:54AM +, Al Viro wrote: [snip] Bloody hell... My apologies - that was a postponed mail from *way* back that got sent now by dumb mistake. Sorry about that

Re: [PATCHSET] 2.6.15-rc7-bird1

BTW, here's the state of toolchains, by architecture: alpha alpha-linux works arm arm-linux works arm26 support is gone in gcc4, tree is not well either criscris-linux broken [*3][*4], but gets through arch/cris, so

Re: [PATCHSET] 2.6.15-rc7-bird1

BTW, here's the state of toolchains, by architecture: alpha alpha-linux works arm arm-linux works arm26 support is gone in gcc4, tree is not well either criscris-linux broken [*3][*4], but gets through arch/cris, so

Re: [PATCH v2 1/2] clocksource: npcm: add NPCM7xx timer driver

Looks like you missed a couple of comments from Daniel: https://www.spinics.net/lists/devicetree/msg196683.html Also, I think the binding documentation is supposed to come before the driver. On Wed, Nov 1, 2017 at 5:16 AM, Tomer Maimon wrote: > Add Nuvoton BMC NPCM7xx timer

Re: [PATCH v2 1/2] clocksource: npcm: add NPCM7xx timer driver

Looks like you missed a couple of comments from Daniel: https://www.spinics.net/lists/devicetree/msg196683.html Also, I think the binding documentation is supposed to come before the driver. On Wed, Nov 1, 2017 at 5:16 AM, Tomer Maimon wrote: > Add Nuvoton BMC NPCM7xx timer driver. > > the

Re: [PATCH v2 0/2] clocksource: npcm: add NPCM7xx timer driver

On Wed, Nov 1, 2017 at 5:16 AM, Tomer Maimon wrote: > Addressed comments from: > - Daniel Lezcano: https://www.spinics.net/lists/devicetree/msg196683.html > > Changes since version 1: > - Rename driver name > - Removing unnecessary dependencies in configuration > - Adding

Re: [PATCH v2 0/2] clocksource: npcm: add NPCM7xx timer driver

On Wed, Nov 1, 2017 at 5:16 AM, Tomer Maimon wrote: > Addressed comments from: > - Daniel Lezcano: https://www.spinics.net/lists/devicetree/msg196683.html > > Changes since version 1: > - Rename driver name > - Removing unnecessary dependencies in configuration > - Adding prefix to the macros

Re: [RFC PATCH 2/2] x86: Allow paranoid __{get,put}_user

On Fri, Nov 03, 2017 at 05:14:05PM -0700, Kees Cook wrote: > > x86 turns out to be easier since the safe and unsafe paths are mostly > > disjoint so we don't have to worry about gcc optimizing out access_ok. > > I tweaked the Kconfig to someting a bit more generic. > > > > The size increase was

Re: [RFC PATCH 2/2] x86: Allow paranoid __{get,put}_user

On Fri, Nov 03, 2017 at 05:14:05PM -0700, Kees Cook wrote: > > x86 turns out to be easier since the safe and unsafe paths are mostly > > disjoint so we don't have to worry about gcc optimizing out access_ok. > > I tweaked the Kconfig to someting a bit more generic. > > > > The size increase was

[git pull] Input updates for v4.14-rc7

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. Just a couple of fixups to sparse-keymap module and Microchip AR1021 touchscreen driver. Changelog: - Martin Kepplinger (1):

[git pull] Input updates for v4.14-rc7

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. Just a couple of fixups to sparse-keymap module and Microchip AR1021 touchscreen driver. Changelog: - Martin Kepplinger (1):

Re: [PATCH] Net: netfilter: vmalloc/vfree to kvmalloc/kvfree

Charlie Sale wrote: > + hinfo = kvmalloc(sizeof(*hinfo) + sizeof(struct hlist_head) * size, > + GPT_KERNEL); Looks like you did not even compile test this. Again. :-(

Re: [PATCH] Net: netfilter: vmalloc/vfree to kvmalloc/kvfree

Charlie Sale wrote: > + hinfo = kvmalloc(sizeof(*hinfo) + sizeof(struct hlist_head) * size, > + GPT_KERNEL); Looks like you did not even compile test this. Again. :-(

Re: [PATCH v2 3/4] media: i2c: Add TDA1997x HDMI receiver driver

On Mon, Oct 23, 2017 at 10:05 AM, Tim Harvey wrote: > > On Fri, Oct 20, 2017 at 9:23 AM, Hans Verkuil wrote: > > >> > >> I see the AVI infoframe has hdmi_quantization_range and > >> hdmi_ycc_quantization_range along with vid_code. > >> > >> I'm not at

Re: [PATCH v2 3/4] media: i2c: Add TDA1997x HDMI receiver driver

On Mon, Oct 23, 2017 at 10:05 AM, Tim Harvey wrote: > > On Fri, Oct 20, 2017 at 9:23 AM, Hans Verkuil wrote: > > >> > >> I see the AVI infoframe has hdmi_quantization_range and > >> hdmi_ycc_quantization_range along with vid_code. > >> > >> I'm not at all clear what to do with this information.

Re: [RFC PATCH 2/2] x86: Allow paranoid __{get,put}_user

On Fri, Nov 3, 2017 at 4:04 PM, Laura Abbott wrote: > __{get,put}_user calls are designed to be fast and have no checks, > relying on the caller to have made the appropriate calls previously. > It's very easy to forget a check though, leaving the kernel vulnerable > to

Re: [RFC PATCH 2/2] x86: Allow paranoid __{get,put}_user

On Fri, Nov 3, 2017 at 4:04 PM, Laura Abbott wrote: > __{get,put}_user calls are designed to be fast and have no checks, > relying on the caller to have made the appropriate calls previously. > It's very easy to forget a check though, leaving the kernel vulnerable > to exploits. Add an option to

Re: [PATCH] HID: Wacom: switch Dell canvas into highres mode

On November 3, 2017 10:29:47 AM PDT, Benjamin Tissoires wrote: >The Dell Canvas exports 2 collections for the Pen part. The only >difference between the 2 is that the default one has half the >resolution >of the second one. > >The Windows driver switches the tablet

Re: [PATCH] HID: Wacom: switch Dell canvas into highres mode

On November 3, 2017 10:29:47 AM PDT, Benjamin Tissoires wrote: >The Dell Canvas exports 2 collections for the Pen part. The only >difference between the 2 is that the default one has half the >resolution >of the second one. > >The Windows driver switches the tablet into the second mode, so we

Re: [PATCH v5 3/3] KVM: nVMX: Fix mmu context after VMLAUNCH/VMRESUME failure

On 11/02/2017 05:50 PM, Wanpeng Li wrote: From: Wanpeng Li Commit 4f350c6dbcb (kvm: nVMX: Handle deferred early VMLAUNCH/VMRESUME failure properly) can result in L1(run kvm-unit-tests/run_tests.sh vmx_controls in L1) null pointer deference and also L0 calltrace when

Re: [PATCH v5 3/3] KVM: nVMX: Fix mmu context after VMLAUNCH/VMRESUME failure

On 11/02/2017 05:50 PM, Wanpeng Li wrote: From: Wanpeng Li Commit 4f350c6dbcb (kvm: nVMX: Handle deferred early VMLAUNCH/VMRESUME failure properly) can result in L1(run kvm-unit-tests/run_tests.sh vmx_controls in L1) null pointer deference and also L0 calltrace when EPT=0 on both L0 and L1.

Re: [Toybox] Regression: commit da029c11e6b1 broke toybox xargs.

On Fri, Nov 3, 2017 at 4:58 PM, Rob Landley wrote: > On 11/02/2017 10:40 AM, Linus Torvalds wrote: >> On Wed, Nov 1, 2017 at 9:28 PM, Linus Torvalds >> wrote: >>> >>> Behavior changed. Things that test particular limits will get different >>>

Re: [Toybox] Regression: commit da029c11e6b1 broke toybox xargs.

On Fri, Nov 3, 2017 at 4:58 PM, Rob Landley wrote: > On 11/02/2017 10:40 AM, Linus Torvalds wrote: >> On Wed, Nov 1, 2017 at 9:28 PM, Linus Torvalds >> wrote: >>> >>> Behavior changed. Things that test particular limits will get different >>> results. That's not breakage. >>> >>> Did an actual

Re: [PATCH 6/6] memfd-tests: test hugetlbfs sealing

On 10/31/2017 11:40 AM, Marc-André Lureau wrote: > Remove most of the special-casing of hugetlbfs now that sealing > is supported. The changes below look fine. Just a couple issues. While discussing patch 4 with David, I realized that we should modify/expand the fuse seals test to also verify

Re: [PATCH 6/6] memfd-tests: test hugetlbfs sealing

On 10/31/2017 11:40 AM, Marc-André Lureau wrote: > Remove most of the special-casing of hugetlbfs now that sealing > is supported. The changes below look fine. Just a couple issues. While discussing patch 4 with David, I realized that we should modify/expand the fuse seals test to also verify

Re: Regression: commit da029c11e6b1 broke toybox xargs.

On 11/02/2017 10:40 AM, Linus Torvalds wrote: > On Wed, Nov 1, 2017 at 9:28 PM, Linus Torvalds > wrote: >> >> Behavior changed. Things that test particular limits will get different >> results. That's not breakage. >> >> Did an actual user application or script

Re: Regression: commit da029c11e6b1 broke toybox xargs.

On 11/02/2017 10:40 AM, Linus Torvalds wrote: > On Wed, Nov 1, 2017 at 9:28 PM, Linus Torvalds > wrote: >> >> Behavior changed. Things that test particular limits will get different >> results. That's not breakage. >> >> Did an actual user application or script break? Only due to getting the

Re: [PATCH v5 2/2] Input: add support for the Samsung S6SY761 touchscreen

Hi Andi, On Thu, Nov 02, 2017 at 03:07:26PM +0900, Andi Shyti wrote: > + > + err = s6sy761_hw_init(sdata); > + if (err) > + return err; > + > + sdata->input = devm_input_allocate_device(>dev); > + if (!sdata->input) > + return -ENOMEM; > + > +

Re: [PATCH v5 2/2] Input: add support for the Samsung S6SY761 touchscreen

Hi Andi, On Thu, Nov 02, 2017 at 03:07:26PM +0900, Andi Shyti wrote: > + > + err = s6sy761_hw_init(sdata); > + if (err) > + return err; > + > + sdata->input = devm_input_allocate_device(>dev); > + if (!sdata->input) > + return -ENOMEM; > + > +

  1   2   3   4   5   6   7   8   9   10   >