Re: [PATCH v2 4/6] cpufreq: schedutil: update CFS util only if used

On Tue, Jul 4, 2017 at 10:34 AM, Patrick Bellasi wrote: > Currently the utilization of the FAIR class is collected before locking > the policy. Although that should not be a big issue for most cases, we > also don't really know how much latency there can be between the >

Re: [PATCH v2 4/6] cpufreq: schedutil: update CFS util only if used

On Tue, Jul 4, 2017 at 10:34 AM, Patrick Bellasi wrote: > Currently the utilization of the FAIR class is collected before locking > the policy. Although that should not be a big issue for most cases, we > also don't really know how much latency there can be between the > utilization reading and

Re: [RFC v2 3/5] hmem: add heterogeneous memory sysfs support

On 07/06/2017 02:52 PM, Ross Zwisler wrote: [...] > diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile > index b1aacfc..31e3f20 100644 > --- a/drivers/acpi/Makefile > +++ b/drivers/acpi/Makefile > @@ -72,6 +72,7 @@ obj-$(CONFIG_ACPI_PROCESSOR)+= processor.o > obj-$(CONFIG_ACPI)

Re: [RFC v2 3/5] hmem: add heterogeneous memory sysfs support

On 07/06/2017 02:52 PM, Ross Zwisler wrote: [...] > diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile > index b1aacfc..31e3f20 100644 > --- a/drivers/acpi/Makefile > +++ b/drivers/acpi/Makefile > @@ -72,6 +72,7 @@ obj-$(CONFIG_ACPI_PROCESSOR)+= processor.o > obj-$(CONFIG_ACPI)

[PATCH] drm/udl: Make page_flip asynchronous

In page_flip vblank is sent with no delay. Driver does not know when the actual update is present on the display and has no means for getting this information from a device. It is practically impossible to say exactly *when* as there is also i.e. a usb delay. When we are unable to determine when

[PATCH] drm/udl: Make page_flip asynchronous

In page_flip vblank is sent with no delay. Driver does not know when the actual update is present on the display and has no means for getting this information from a device. It is practically impossible to say exactly *when* as there is also i.e. a usb delay. When we are unable to determine when

Re: [RFC][PATCH] exec: Use init rlimits for setuid exec

On Thu, Jul 6, 2017 at 10:39 PM, Linus Torvalds wrote: > On Thu, Jul 6, 2017 at 10:15 PM, Kees Cook wrote: >> >> I always say this backwards. :P Default is top-down (allocate at high >> addresses and work down toward low). With unlimited

Re: [RFC][PATCH] exec: Use init rlimits for setuid exec

On Thu, Jul 6, 2017 at 10:39 PM, Linus Torvalds wrote: > On Thu, Jul 6, 2017 at 10:15 PM, Kees Cook wrote: >> >> I always say this backwards. :P Default is top-down (allocate at high >> addresses and work down toward low). With unlimited stack, allocations >> start at low addresses and work up.

Re: [PATCH v2] ASoC: samsung: i2s: Support more resolution rates

On Fri, Jul 07, 2017 at 10:31:10AM +0900, Jaechul Lee wrote: > This driver can support more frequencies over 96KHz. There are no reasons > to limit the frequency range below 96KHz. If codecs/amps or something else > can't support higher resolution rates, the constraints would be set rates >

Re: [PATCH v2] ASoC: samsung: i2s: Support more resolution rates

On Fri, Jul 07, 2017 at 10:31:10AM +0900, Jaechul Lee wrote: > This driver can support more frequencies over 96KHz. There are no reasons > to limit the frequency range below 96KHz. If codecs/amps or something else > can't support higher resolution rates, the constraints would be set rates >

Re: [RFC][PATCH] exec: Use init rlimits for setuid exec

On Thu, Jul 6, 2017 at 10:36 PM, Andy Lutomirski wrote: > On Thu, Jul 6, 2017 at 10:15 PM, Kees Cook wrote: >> On Thu, Jul 6, 2017 at 10:10 PM, Kees Cook wrote: >>> On Thu, Jul 6, 2017 at 9:48 PM, Andy Lutomirski

Re: [RFC][PATCH] exec: Use init rlimits for setuid exec

On Thu, Jul 6, 2017 at 10:36 PM, Andy Lutomirski wrote: > On Thu, Jul 6, 2017 at 10:15 PM, Kees Cook wrote: >> On Thu, Jul 6, 2017 at 10:10 PM, Kees Cook wrote: >>> On Thu, Jul 6, 2017 at 9:48 PM, Andy Lutomirski wrote: How about a much simpler solution: don't read rlimit at all in

[PATCH] staging: rtl8712: fix "Alignment match open parenthesis"

Fix checkpatch issues: "CHECK: Alignment should match open parenthesis". Signed-off-by: Arushi Singhal --- drivers/staging/rtl8712/mlme_linux.c| 4 ++-- drivers/staging/rtl8712/rtl8712_cmd.c | 2 +- drivers/staging/rtl8712/rtl8712_efuse.c | 2 +- 3 files

[PATCH] staging: rtl8712: fix "Alignment match open parenthesis"

Fix checkpatch issues: "CHECK: Alignment should match open parenthesis". Signed-off-by: Arushi Singhal --- drivers/staging/rtl8712/mlme_linux.c| 4 ++-- drivers/staging/rtl8712/rtl8712_cmd.c | 2 +- drivers/staging/rtl8712/rtl8712_efuse.c | 2 +- 3 files changed, 4 insertions(+), 4

Re: [RFC][PATCH] exec: Use init rlimits for setuid exec

On Thu, Jul 6, 2017 at 10:15 PM, Kees Cook wrote: > > I always say this backwards. :P Default is top-down (allocate at high > addresses and work down toward low). With unlimited stack, allocations > start at low addresses and work up. Here's the results (shown with >

Re: [RFC][PATCH] exec: Use init rlimits for setuid exec

On Thu, Jul 6, 2017 at 10:15 PM, Kees Cook wrote: > > I always say this backwards. :P Default is top-down (allocate at high > addresses and work down toward low). With unlimited stack, allocations > start at low addresses and work up. Here's the results (shown with > randomize_va_space sysctl set

Re: [RFC][PATCH] exec: Use init rlimits for setuid exec

On Thu, Jul 6, 2017 at 10:15 PM, Kees Cook wrote: > On Thu, Jul 6, 2017 at 10:10 PM, Kees Cook wrote: >> On Thu, Jul 6, 2017 at 9:48 PM, Andy Lutomirski wrote: >>> How about a much simpler solution: don't read rlimit at all in >>>

Re: [RFC][PATCH] exec: Use init rlimits for setuid exec

On Thu, Jul 6, 2017 at 10:15 PM, Kees Cook wrote: > On Thu, Jul 6, 2017 at 10:10 PM, Kees Cook wrote: >> On Thu, Jul 6, 2017 at 9:48 PM, Andy Lutomirski wrote: >>> How about a much simpler solution: don't read rlimit at all in >>> copy_strings(), let alone try to enforce it. Instead, just

[PATCH] regulator: qcom_smd: add NULL check on of_match_device() return value

Check return value from call to of_match_device() in order to prevent a NULL pointer dereference. In case of NULL print error message and return. Signed-off-by: Gustavo A. R. Silva --- drivers/regulator/qcom_smd-regulator.c | 5 + 1 file changed, 5 insertions(+)

[PATCH] regulator: qcom_smd: add NULL check on of_match_device() return value

Check return value from call to of_match_device() in order to prevent a NULL pointer dereference. In case of NULL print error message and return. Signed-off-by: Gustavo A. R. Silva --- drivers/regulator/qcom_smd-regulator.c | 5 + 1 file changed, 5 insertions(+) diff --git

Re: [RFC v2 0/5] surface heterogeneous memory performance information

On 07/06/2017 02:52 PM, Ross Zwisler wrote: [...] > > The naming collision between Jerome's "Heterogeneous Memory Management > (HMM)" and this "Heterogeneous Memory (HMEM)" series is unfortunate, but I > was trying to stick with the word "Heterogeneous" because of the naming of > the ACPI 6.2

Re: [RFC v2 0/5] surface heterogeneous memory performance information

On 07/06/2017 02:52 PM, Ross Zwisler wrote: [...] > > The naming collision between Jerome's "Heterogeneous Memory Management > (HMM)" and this "Heterogeneous Memory (HMEM)" series is unfortunate, but I > was trying to stick with the word "Heterogeneous" because of the naming of > the ACPI 6.2

[PATCH] regulator: qcom_rpm-regulator: add NULL check on of_match_device() return value

Check return value from call to of_match_device() in order to prevent a NULL pointer dereference. In case of NULL print error message and return. Signed-off-by: Gustavo A. R. Silva --- drivers/regulator/qcom_rpm-regulator.c | 5 + 1 file changed, 5 insertions(+)

[PATCH] regulator: qcom_rpm-regulator: add NULL check on of_match_device() return value

Check return value from call to of_match_device() in order to prevent a NULL pointer dereference. In case of NULL print error message and return. Signed-off-by: Gustavo A. R. Silva --- drivers/regulator/qcom_rpm-regulator.c | 5 + 1 file changed, 5 insertions(+) diff --git

RE: [PATCH 2/2] net: ethernet: fsl: add phy reset after clk enable option

From: Richard Leitner Sent: Thursday, July 06, 2017 9:06 PM >To: Andy Duan ; robh...@kernel.org; >mark.rutl...@arm.com >Cc: net...@vger.kernel.org; devicet...@vger.kernel.org; linux- >ker...@vger.kernel.org; d...@g0hl1n.net; Richard Leitner

RE: [PATCH 2/2] net: ethernet: fsl: add phy reset after clk enable option

From: Richard Leitner Sent: Thursday, July 06, 2017 9:06 PM >To: Andy Duan ; robh...@kernel.org; >mark.rutl...@arm.com >Cc: net...@vger.kernel.org; devicet...@vger.kernel.org; linux- >ker...@vger.kernel.org; d...@g0hl1n.net; Richard Leitner > >Subject: [PATCH 2/2] net: ethernet: fsl: add phy

Re: [PATCH v2 3/6] cpufreq: schedutil: ensure max frequency while running RT/DL tasks

Hi, On Wed, Jul 5, 2017 at 6:41 AM, Patrick Bellasi wrote: [..] > >> But what about clearing the sched-class's flag from .pick_next_task() >> callback >> when they return NULL ? >> >> What about something like this instead (completely untested), with which we >> don't

Re: [PATCH v2 3/6] cpufreq: schedutil: ensure max frequency while running RT/DL tasks

Hi, On Wed, Jul 5, 2017 at 6:41 AM, Patrick Bellasi wrote: [..] > >> But what about clearing the sched-class's flag from .pick_next_task() >> callback >> when they return NULL ? >> >> What about something like this instead (completely untested), with which we >> don't need the 2/3 patch as

Re: [git pull] vfs.git pile 10

On Thu, Jul 6, 2017 at 2:11 AM, Al Viro wrote: > uaccess str...() dead code removals. Side note: you left a couple of references to strlen_user() still in the tree. None of them *matter* (two comments and one declaration for the function that no longer exists),

Re: [git pull] vfs.git pile 10

On Thu, Jul 6, 2017 at 2:11 AM, Al Viro wrote: > uaccess str...() dead code removals. Side note: you left a couple of references to strlen_user() still in the tree. None of them *matter* (two comments and one declaration for the function that no longer exists), but it just strikes me as

Re: [RFC][PATCH] exec: Use init rlimits for setuid exec

On Thu, Jul 6, 2017 at 10:10 PM, Kees Cook wrote: > On Thu, Jul 6, 2017 at 9:48 PM, Andy Lutomirski wrote: >> How about a much simpler solution: don't read rlimit at all in >> copy_strings(), let alone try to enforce it. Instead, just before the >> point

Re: [RFC][PATCH] exec: Use init rlimits for setuid exec

On Thu, Jul 6, 2017 at 10:10 PM, Kees Cook wrote: > On Thu, Jul 6, 2017 at 9:48 PM, Andy Lutomirski wrote: >> How about a much simpler solution: don't read rlimit at all in >> copy_strings(), let alone try to enforce it. Instead, just before the >> point of no return, check how much stack space

[PATCH] HID: hid-logitech-hidpp: add NULL check on devm_kmemdup() return value

Check return value from call to devm_kmemdup() in order to prevent a NULL pointer dereference. Signed-off-by: Gustavo A. R. Silva --- drivers/hid/hid-logitech-hidpp.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/hid/hid-logitech-hidpp.c

[PATCH] HID: hid-logitech-hidpp: add NULL check on devm_kmemdup() return value

Check return value from call to devm_kmemdup() in order to prevent a NULL pointer dereference. Signed-off-by: Gustavo A. R. Silva --- drivers/hid/hid-logitech-hidpp.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c index

Re: [PATCH] perf report: Fix broken arrow at row 0 in annotate view

Hi Arnaldo, Could this patch be merged? Otherwise the jump arrow is broken when it's displayed at the row 0 in annotate view. Thanks Jin Yao On 6/8/2017 2:01 PM, Jin Yao wrote: When the jump instruction is displayed at the row 0 in annotate view, the arrow is broken. An example: 16.86

Re: [PATCH] perf report: Fix broken arrow at row 0 in annotate view

Hi Arnaldo, Could this patch be merged? Otherwise the jump arrow is broken when it's displayed at the row 0 in annotate view. Thanks Jin Yao On 6/8/2017 2:01 PM, Jin Yao wrote: When the jump instruction is displayed at the row 0 in annotate view, the arrow is broken. An example: 16.86

Re: [RFC][PATCH] exec: Use init rlimits for setuid exec

On Thu, Jul 6, 2017 at 9:48 PM, Andy Lutomirski wrote: > How about a much simpler solution: don't read rlimit at all in > copy_strings(), let alone try to enforce it. Instead, just before the > point of no return, check how much stack space is already used and, if > it's more

Re: [RFC][PATCH] exec: Use init rlimits for setuid exec

On Thu, Jul 6, 2017 at 9:48 PM, Andy Lutomirski wrote: > How about a much simpler solution: don't read rlimit at all in > copy_strings(), let alone try to enforce it. Instead, just before the > point of no return, check how much stack space is already used and, if > it's more than an appropriate

Re: [git pull] vfs.git pile 11

On Thu, Jul 6, 2017 at 2:20 PM, Al Viro wrote: > > Linus, could you hold that one back until tomorrow? I want to tweak the > last commit in there a bit, but I want to give it a local beating first... Ok, dropping this one. All your other branches are merged now.

Re: [git pull] vfs.git pile 11

On Thu, Jul 6, 2017 at 2:20 PM, Al Viro wrote: > > Linus, could you hold that one back until tomorrow? I want to tweak the > last commit in there a bit, but I want to give it a local beating first... Ok, dropping this one. All your other branches are merged now. Linus

Re: [PATCH] PCI: Do not enable extended tags on pre-dated (v1.x) systems

On Wed, Jul 5, 2017 at 9:19 PM, Sinan Kaya wrote: > According to extended tags ECN document, all PCIe receivers are expected > to support extended tags support. It should be safe to enable extended > tags on endpoints without checking compatibility. > > This assumption seems

Re: [RFC][PATCH] exec: Use init rlimits for setuid exec

On Thu, Jul 6, 2017 at 9:48 PM, Andy Lutomirski wrote: > > How about a much simpler solution: don't read rlimit at all in > copy_strings(), let alone try to enforce it. People have historically relied on E2BIG and then splitting things into multiple chunks (ie do the whole

Re: [RFC][PATCH] exec: Use init rlimits for setuid exec

On Thu, Jul 6, 2017 at 9:48 PM, Andy Lutomirski wrote: > > How about a much simpler solution: don't read rlimit at all in > copy_strings(), let alone try to enforce it. People have historically relied on E2BIG and then splitting things into multiple chunks (ie do the whole 'xargs' thing). But I

Re: [PATCH] PCI: Do not enable extended tags on pre-dated (v1.x) systems

On Wed, Jul 5, 2017 at 9:19 PM, Sinan Kaya wrote: > According to extended tags ECN document, all PCIe receivers are expected > to support extended tags support. It should be safe to enable extended > tags on endpoints without checking compatibility. > > This assumption seems to be working fine

[PATCH v4 2/2] perf report: Implement visual marker for macro fusion in annotate

For marking the fused instructions clearly, This patch adds a line before the first instruction of pair and joins it with the arrow of the jump. For example, when je is selected in annotate view, the line before cmpl is displayed and joins the arrow of je. │ ┌──cmpl

[PATCH v4 2/2] perf report: Implement visual marker for macro fusion in annotate

For marking the fused instructions clearly, This patch adds a line before the first instruction of pair and joins it with the arrow of the jump. For example, when je is selected in annotate view, the line before cmpl is displayed and joins the arrow of je. │ ┌──cmpl

[PATCH v4 1/2] perf util: Check for fused instruction

Macro fusion merges two instructions to a single micro-op. Intel core platform performs this hardware optimization under limited circumstances. For example, CMP + JCC can be "fused" and executed /retired together. While with sampling this can result in the sample sometimes being on the JCC and

[PATCH v4 1/2] perf util: Check for fused instruction

Macro fusion merges two instructions to a single micro-op. Intel core platform performs this hardware optimization under limited circumstances. For example, CMP + JCC can be "fused" and executed /retired together. While with sampling this can result in the sample sometimes being on the JCC and

[PATCH v4 0/2] perf report: Implement visual marker for macro fusion in annotate

Macro fusion merges two instructions to a single micro-op. Intel core platform performs this hardware optimization under limited circumstances. For example, CMP + JCC can be "fused" and executed /retired together. While with sampling this can result in the sample sometimes being on the JCC and

[PATCH v4 0/2] perf report: Implement visual marker for macro fusion in annotate

Macro fusion merges two instructions to a single micro-op. Intel core platform performs this hardware optimization under limited circumstances. For example, CMP + JCC can be "fused" and executed /retired together. While with sampling this can result in the sample sometimes being on the JCC and

Re: [PATCH] iio: multiplexer: add NULL check on devm_kzalloc() and devm_kmemdup() return values

On 2017-07-07 06:53, Gustavo A. R. Silva wrote: > Check return values from call to devm_kzalloc() and devm_kmemup() If someone cares enough: s/devm_kmemup/evm_kmemdup/ > in order to prevent a NULL pointer dereference. > > This issue was detected using Coccinelle and the following semantic

Re: [PATCH] iio: multiplexer: add NULL check on devm_kzalloc() and devm_kmemdup() return values

On 2017-07-07 06:53, Gustavo A. R. Silva wrote: > Check return values from call to devm_kzalloc() and devm_kmemup() If someone cares enough: s/devm_kmemup/evm_kmemdup/ > in order to prevent a NULL pointer dereference. > > This issue was detected using Coccinelle and the following semantic

linux-next: Tree for Jul 7

Hi all, Please do not add any v4.14 material to you linux-next included branches until after v4.13-rc1 has been released. Changes since 20170706: The f2fs tree gained a conflict against Linus' tree. The akpm tree lost a patch that turned up elsewhere. Non-merge commits (relative to Linus

linux-next: Tree for Jul 7

Hi all, Please do not add any v4.14 material to you linux-next included branches until after v4.13-rc1 has been released. Changes since 20170706: The f2fs tree gained a conflict against Linus' tree. The akpm tree lost a patch that turned up elsewhere. Non-merge commits (relative to Linus

[PATCH] arcnet: com20020-pci: Fix an error handling path in 'com20020pci_probe()'

If this memory allocation fails, we should go through the error handling path as done everywhere else in this function before returning. Signed-off-by: Christophe JAILLET --- drivers/net/arcnet/com20020-pci.c | 6 -- 1 file changed, 4 insertions(+), 2

[PATCH] arcnet: com20020-pci: Fix an error handling path in 'com20020pci_probe()'

If this memory allocation fails, we should go through the error handling path as done everywhere else in this function before returning. Signed-off-by: Christophe JAILLET --- drivers/net/arcnet/com20020-pci.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git

[PATCH] iio: multiplexer: add NULL check on devm_kzalloc() and devm_kmemdup() return values

Check return values from call to devm_kzalloc() and devm_kmemup() in order to prevent a NULL pointer dereference. This issue was detected using Coccinelle and the following semantic patch: @@ expression x; identifier fld; @@ * x = devm_kzalloc(...); ... when != x == NULL x->fld Cc: Peter

[PATCH] iio: multiplexer: add NULL check on devm_kzalloc() and devm_kmemdup() return values

Check return values from call to devm_kzalloc() and devm_kmemup() in order to prevent a NULL pointer dereference. This issue was detected using Coccinelle and the following semantic patch: @@ expression x; identifier fld; @@ * x = devm_kzalloc(...); ... when != x == NULL x->fld Cc: Peter

Re: [PATCH] iio: multiplexer: add NULL check on devm_kzalloc() return value

Quoting Peter Rosin : On 2017-07-07 06:35, Gustavo A. R. Silva wrote: Hi Peter, Quoting Peter Rosin : On 2017-07-07 00:08, Gustavo A. R. Silva wrote: Check return value from call to devm_kzalloc() in order to prevent a NULL pointer dereference. Right,

Re: [PATCH] iio: multiplexer: add NULL check on devm_kzalloc() return value

Quoting Peter Rosin : On 2017-07-07 06:35, Gustavo A. R. Silva wrote: Hi Peter, Quoting Peter Rosin : On 2017-07-07 00:08, Gustavo A. R. Silva wrote: Check return value from call to devm_kzalloc() in order to prevent a NULL pointer dereference. Right, thanks for finding that one!

Re: [RFC][PATCH] exec: Use init rlimits for setuid exec

On Thu, Jul 6, 2017 at 12:12 PM, Kees Cook wrote: > On Thu, Jul 6, 2017 at 10:52 AM, Linus Torvalds > wrote: >> On Thu, Jul 6, 2017 at 10:29 AM, Kees Cook wrote: (a) minimal: just use our existing default

Re: [RFC][PATCH] exec: Use init rlimits for setuid exec

On Thu, Jul 6, 2017 at 12:12 PM, Kees Cook wrote: > On Thu, Jul 6, 2017 at 10:52 AM, Linus Torvalds > wrote: >> On Thu, Jul 6, 2017 at 10:29 AM, Kees Cook wrote: (a) minimal: just use our existing default stack (and stack _only_) limit value for suid binaries that actually get

Re: [PATCH v2] arm: eBPF JIT compiler

Okay Kees. I will take a look at it. Best, Shubham Bansal On Fri, Jul 7, 2017 at 10:12 AM, Kees Cook wrote: > On Wed, Jul 5, 2017 at 8:49 PM, Shubham Bansal > wrote: >> Hi Kees, >> >> Problem is my ARM machine don't have clang and iproute2

Re: [PATCH v2] arm: eBPF JIT compiler

Okay Kees. I will take a look at it. Best, Shubham Bansal On Fri, Jul 7, 2017 at 10:12 AM, Kees Cook wrote: > On Wed, Jul 5, 2017 at 8:49 PM, Shubham Bansal > wrote: >> Hi Kees, >> >> Problem is my ARM machine don't have clang and iproute2 which is >> keeping me from testing the bpf tail

Re: [PATCH 2/2] serial: earlycon: Make early_con as __initdata

On (07/06/17 11:38), Matt Redfearn wrote: > All early console drivers that may be registered as the earlycon are > marked __init to be placed in the init section. The drivers' code and > data are freed during free_initmem_default() but the early console is > not unregistered in printk_late_init()

Re: [PATCH 2/2] serial: earlycon: Make early_con as __initdata

On (07/06/17 11:38), Matt Redfearn wrote: > All early console drivers that may be registered as the earlycon are > marked __init to be placed in the init section. The drivers' code and > data are freed during free_initmem_default() but the early console is > not unregistered in printk_late_init()

Re: [PATCH] iio: multiplexer: add NULL check on devm_kzalloc() return value

On 2017-07-07 06:35, Gustavo A. R. Silva wrote: > Hi Peter, > > Quoting Peter Rosin : > >> On 2017-07-07 00:08, Gustavo A. R. Silva wrote: >>> Check return value from call to devm_kzalloc() >>> in order to prevent a NULL pointer dereference. >> >> Right, thanks for finding that

Re: [PATCH] iio: multiplexer: add NULL check on devm_kzalloc() return value

On 2017-07-07 06:35, Gustavo A. R. Silva wrote: > Hi Peter, > > Quoting Peter Rosin : > >> On 2017-07-07 00:08, Gustavo A. R. Silva wrote: >>> Check return value from call to devm_kzalloc() >>> in order to prevent a NULL pointer dereference. >> >> Right, thanks for finding that one! There's

Re: [x86/time] 03fa63cc96: ACPI_Error:Table[DMAR]is_not_invalidated_during_early_boot_stage(#/tbxface -#)

Hi Thomas, At 07/07/2017 11:04 AM, Ye Xiaolong wrote: On 07/07, Dou Liyang wrote: Hi xiaolong, Really thanks for your testing. At 07/07/2017 09:54 AM, Ye Xiaolong wrote: On 07/06, Thomas Gleixner wrote: On Thu, 6 Jul 2017, kernel test robot wrote: commit:

Re: [x86/time] 03fa63cc96: ACPI_Error:Table[DMAR]is_not_invalidated_during_early_boot_stage(#/tbxface -#)

Hi Thomas, At 07/07/2017 11:04 AM, Ye Xiaolong wrote: On 07/07, Dou Liyang wrote: Hi xiaolong, Really thanks for your testing. At 07/07/2017 09:54 AM, Ye Xiaolong wrote: On 07/06, Thomas Gleixner wrote: On Thu, 6 Jul 2017, kernel test robot wrote: commit:

Re: [PATCH 1/2] printk: Unconditionally unregister boot consoles if in init section

On (07/06/17 11:38), Matt Redfearn wrote: > Commit 4c30c6f566c0 ("kernel/printk: do not turn off bootconsole in > printk_late_init() if keep_bootcon") added a check on keep_bootcon to > ensure that boot consoles were kept around until the real console is > registered. > This can lead to problems

Re: [PATCH 1/2] printk: Unconditionally unregister boot consoles if in init section

On (07/06/17 11:38), Matt Redfearn wrote: > Commit 4c30c6f566c0 ("kernel/printk: do not turn off bootconsole in > printk_late_init() if keep_bootcon") added a check on keep_bootcon to > ensure that boot consoles were kept around until the real console is > registered. > This can lead to problems

Re: [PATCH v2 2/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter

On Tue, Jul 4, 2017 at 10:34 AM, Patrick Bellasi wrote: > Currently, sg_cpu's flags are set to the value defined by the last call of > the cpufreq_update_util()/cpufreq_update_this_cpu(); for RT/DL classes > this corresponds to the SCHED_CPUFREQ_{RT/DL} flags always being

Re: [PATCH v2 2/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter

On Tue, Jul 4, 2017 at 10:34 AM, Patrick Bellasi wrote: > Currently, sg_cpu's flags are set to the value defined by the last call of > the cpufreq_update_util()/cpufreq_update_this_cpu(); for RT/DL classes > this corresponds to the SCHED_CPUFREQ_{RT/DL} flags always being set. > > When multiple

Re: [PATCH v2] arm: eBPF JIT compiler

On Wed, Jul 5, 2017 at 8:49 PM, Shubham Bansal wrote: > Hi Kees, > > Problem is my ARM machine don't have clang and iproute2 which is > keeping me from testing the bpf tail calls. > > You should do the following to test it,. > > 1. tools/testing/selftests/bpf/ > 2. make

Re: [PATCH v2] arm: eBPF JIT compiler

On Wed, Jul 5, 2017 at 8:49 PM, Shubham Bansal wrote: > Hi Kees, > > Problem is my ARM machine don't have clang and iproute2 which is > keeping me from testing the bpf tail calls. > > You should do the following to test it,. > > 1. tools/testing/selftests/bpf/ > 2. make > 3. sudo ./test_progs > >

Re: [PATCH] iio: multiplexer: add NULL check on devm_kzalloc() return value

Hi Peter, Quoting Peter Rosin : On 2017-07-07 00:08, Gustavo A. R. Silva wrote: Check return value from call to devm_kzalloc() in order to prevent a NULL pointer dereference. Right, thanks for finding that one! There's another one inside the for loop that is just starting

Re: [PATCH] iio: multiplexer: add NULL check on devm_kzalloc() return value

Hi Peter, Quoting Peter Rosin : On 2017-07-07 00:08, Gustavo A. R. Silva wrote: Check return value from call to devm_kzalloc() in order to prevent a NULL pointer dereference. Right, thanks for finding that one! There's another one inside the for loop that is just starting in the context of

Re: [PATCH] target: make device_mutex and device_list static

On Wed, 2017-07-05 at 13:15 -0500, Mike Christie wrote: > On 07/04/2017 03:44 AM, Colin King wrote: > > From: Colin Ian King > > > > Variables device_mutex and device_list static are local to the source, > > so make them static. > > > > Cleans up sparse warnings: > >

Re: [PATCH] target: make device_mutex and device_list static

On Wed, 2017-07-05 at 13:15 -0500, Mike Christie wrote: > On 07/04/2017 03:44 AM, Colin King wrote: > > From: Colin Ian King > > > > Variables device_mutex and device_list static are local to the source, > > so make them static. > > > > Cleans up sparse warnings: > > "symbol 'device_list' was

Re: [PATCH] extcon: int3496: constify acpi_device_id.

On 2017년 07월 07일 01:55, Arvind Yadav wrote: > acpi_device_id are not supposed to change at runtime. All functions > working with acpi_device_id provided by work with > const acpi_device_id. So mark the non-const structs as const. > > File size before: >text data bss dec

Re: [PATCH] extcon: int3496: constify acpi_device_id.

On 2017년 07월 07일 01:55, Arvind Yadav wrote: > acpi_device_id are not supposed to change at runtime. All functions > working with acpi_device_id provided by work with > const acpi_device_id. So mark the non-const structs as const. > > File size before: >text data bss dec

Re: [PATCH] iio: multiplexer: add NULL check on devm_kzalloc() return value

On 2017-07-07 00:08, Gustavo A. R. Silva wrote: > Check return value from call to devm_kzalloc() > in order to prevent a NULL pointer dereference. Right, thanks for finding that one! There's another one inside the for loop that is just starting in the context of this patch. Care to fix checking

Re: [PATCH] iio: multiplexer: add NULL check on devm_kzalloc() return value

On 2017-07-07 00:08, Gustavo A. R. Silva wrote: > Check return value from call to devm_kzalloc() > in order to prevent a NULL pointer dereference. Right, thanks for finding that one! There's another one inside the for loop that is just starting in the context of this patch. Care to fix checking

[PATCH v3 2/3] dt-bindings: cpufreq: move MediaTek cpufreq dt-bindings document to proper place

From: Sean Wang The old place is Documentation/devicetree/bindings/clock/ that would let people hard to find how to use MediaTek cpufreq driver, so moving it to the appropriate place as other cpufreq drivers done would be better. Signed-off-by: Sean Wang

[PATCH v3 0/3] some fixups for MediaTek cpufreq driver

From: Sean Wang Changes since v2: - correct the typo in the binding document Changes since v1: - drop those patches already accepted - refine the commit messages and Kconfig dependency - Kconfig menu entry and file name itself are updated with more generic name to drop

[PATCH v3 2/3] dt-bindings: cpufreq: move MediaTek cpufreq dt-bindings document to proper place

From: Sean Wang The old place is Documentation/devicetree/bindings/clock/ that would let people hard to find how to use MediaTek cpufreq driver, so moving it to the appropriate place as other cpufreq drivers done would be better. Signed-off-by: Sean Wang Acked-by: Viresh Kumar ---

[PATCH v3 0/3] some fixups for MediaTek cpufreq driver

From: Sean Wang Changes since v2: - correct the typo in the binding document Changes since v1: - drop those patches already accepted - refine the commit messages and Kconfig dependency - Kconfig menu entry and file name itself are updated with more generic name to drop "MT8173" since this

[PATCH v3 3/3] dt-bindings: cpufreq: enhance MediaTek cpufreq dt-binding document

From: Sean Wang Update binding document with adding operating-points-v2 as the required property and the cooling level as the optional properties and adding more examples guiding people how to use MediaTek cpufreq driver for MediaTek SoCs. Signed-off-by: Sean Wang

[PATCH v3 1/3] cpufreq: mediatek: Add support of cpufreq to MT2701/MT7623 SoC

From: Sean Wang MT2701/MT7623 is a 32-bit ARMv7 based quad-core (4 * Cortex-A7) with single cluster and this hardware is also compatible with the existing driver through enabling CPU frequency feature with operating-points-v2 bindings. Also, this driver actually supports

[PATCH v3 3/3] dt-bindings: cpufreq: enhance MediaTek cpufreq dt-binding document

From: Sean Wang Update binding document with adding operating-points-v2 as the required property and the cooling level as the optional properties and adding more examples guiding people how to use MediaTek cpufreq driver for MediaTek SoCs. Signed-off-by: Sean Wang Acked-by: Viresh Kumar ---

[PATCH v3 1/3] cpufreq: mediatek: Add support of cpufreq to MT2701/MT7623 SoC

From: Sean Wang MT2701/MT7623 is a 32-bit ARMv7 based quad-core (4 * Cortex-A7) with single cluster and this hardware is also compatible with the existing driver through enabling CPU frequency feature with operating-points-v2 bindings. Also, this driver actually supports all MediaTek SoCs, the

Re: [RFC PATCH v1 3/8] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE

Hi Juri, On Wed, Jul 5, 2017 at 1:59 AM, Juri Lelli wrote: > Worker kthread needs to be able to change frequency for all other > threads. > > Make it special, just under STOP class. > > Signed-off-by: Juri Lelli > Cc: Peter Zijlstra

Re: [RFC PATCH v1 3/8] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE

Hi Juri, On Wed, Jul 5, 2017 at 1:59 AM, Juri Lelli wrote: > Worker kthread needs to be able to change frequency for all other > threads. > > Make it special, just under STOP class. > > Signed-off-by: Juri Lelli > Cc: Peter Zijlstra > Cc: Ingo Molnar > Cc: Rafael J. Wysocki > Cc: Viresh

Re: [PATCH 1/2] genirq: Get the fwnode back for irqchips being probed via ACPI namespace

On 2017/7/6 21:05, Marc Zyngier wrote: > On 06/07/17 10:01, Hanjun Guo wrote: >> Hi Marc, >> >> On 2017/7/6 15:43, Marc Zyngier wrote: >>> On 06/07/17 05:35, Hanjun Guo wrote: From: Hanjun Guo commit d59f6617eef0 (genirq: Allow fwnode to carry name

Re: [PATCH 1/2] genirq: Get the fwnode back for irqchips being probed via ACPI namespace

On 2017/7/6 21:05, Marc Zyngier wrote: > On 06/07/17 10:01, Hanjun Guo wrote: >> Hi Marc, >> >> On 2017/7/6 15:43, Marc Zyngier wrote: >>> On 06/07/17 05:35, Hanjun Guo wrote: From: Hanjun Guo commit d59f6617eef0 (genirq: Allow fwnode to carry name information only) forgot to

Re: Make HWSPINLOCK a menuconfig to ease disabling

On Thu, Jul 06, 2017 at 11:23:50PM +, Linux Kernel wrote: > Make HWSPINLOCK a menuconfig to ease disabling > > So that there's no need to get into the submenu to disable all related > config > entries. Here's how that looks on x86... * * Hardware Spinlock drivers *

Re: Make HWSPINLOCK a menuconfig to ease disabling

On Thu, Jul 06, 2017 at 11:23:50PM +, Linux Kernel wrote: > Make HWSPINLOCK a menuconfig to ease disabling > > So that there's no need to get into the submenu to disable all related > config > entries. Here's how that looks on x86... * * Hardware Spinlock drivers *

Re: [RFC PATCH v1 4/8] sched/cpufreq_schedutil: split utilization signals

Hi Juri, On Wed, Jul 5, 2017 at 1:59 AM, Juri Lelli wrote: > To be able to treat utilization signals of different scheduling classes > in different ways (e.g., CFS signal might be stale while DEADLINE signal > is never stale by design) we need to split sugov_cpu::util signal

Re: [RFC PATCH v1 4/8] sched/cpufreq_schedutil: split utilization signals

Hi Juri, On Wed, Jul 5, 2017 at 1:59 AM, Juri Lelli wrote: > To be able to treat utilization signals of different scheduling classes > in different ways (e.g., CFS signal might be stale while DEADLINE signal > is never stale by design) we need to split sugov_cpu::util signal in two: > util_cfs

  1   2   3   4   5   6   7   8   9   10   >