Introduce the LP5036/30/24/18/12/9 RGB LED driver.
The difference in these parts are the number of
LED outputs where the:
LP5036 can control 36 LEDs
LP5030 can control 30 LEDs
LP5024 can control 24 LEDs
LP5018 can control 18 LEDs
LP5012 can control 12 LEDs
LP5009 can control 9 LEDs
The device
Add the multicolor brightness call back to support the multicolor
framework. This function allows setting the brightness across
grouped LED channels in a single call.
Acked-by: Pavel Machek
Acked-by: Jacek Anaszewski
Signed-off-by: Dan Murphy
---
drivers/leds/Kconfig | 1 +
Add a new color ID that is declared as MULTICOLOR as with the
multicolor framework declaring a definitive color is not accurate
as the node can contain multiple colors.
Signed-off-by: Dan Murphy
---
drivers/leds/led-core.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Hi Thomas, Paul,
On Fri, Jun 12, 2020 at 03:55:00PM +0200, Thomas Gleixner wrote:
> The idea of conditionally calling into rcu_irq_enter() only when RCU is
> not watching turned out to be not completely thought through.
>
> Paul noticed occasional premature end of grace periods in RCU torture
>
Add DT bindings for the LEDs multicolor class framework.
Add multicolor ID to the color ID list for device tree bindings.
CC: Rob Herring
Acked-by: Pavel Machek
Acked-by: Jacek Anaszewski
Signed-off-by: Dan Murphy
---
.../bindings/leds/leds-class-multicolor.yaml | 37 +++
Convert the LED class registration calls to the LED devm_*
registration calls.
Acked-by: Jacek Anaszewski
Acked-by: Pavel Machek
Signed-off-by: Dan Murphy
---
drivers/leds/leds-lp5521.c| 9 +++--
drivers/leds/leds-lp5523.c| 9 +++--
drivers/leds/leds-lp5562.c
Fix the checkpatch warnings for the use of the file permission macros.
In converting the file permissions to the DEVICE_ATTR_XX macros the
call back function names needed to be updated within the code.
This means that the lp55xx_ needed to be dropped in the name to keep in
harmony with the ABI
On Sun, 14 Jun 2020 09:01:54 +0200
Oscar Carter wrote:
> In an effort to enable -Wcast-function-type in the top-level Makefile to
> support Control Flow Integrity builds, remove all the function callback
> casts.
>
> To do this, use the ftrace_ops_list_func function as a wrapper when the
> arch
Introduce the bindings for the Texas Instruments LP5036, LP5030, LP5024,
LP5018, LP5012 and LP5009 RGB LED device driver. The LP5036/30/24/18/12/9
can control RGB LEDs individually or as part of a control bank group.
These devices have the ability to adjust the mixing control for the RGB
LEDs to
Add the multicolor brightness call back to support the multicolor
framework. This call back allows setting brightness on grouped channels
in a single function.
Acked-by: Pavel Machek
Acked-by: Jacek Anaszewski
Signed-off-by: Dan Murphy
---
drivers/leds/Kconfig | 1 +
Hello
This is the multi color LED framework. This framework presents clustered
colored LEDs into an array and allows the user space to adjust the brightness
of the cluster using a single file write. The individual colored LEDs
intensities are controlled via a single file that is an array of
Introduce a multicolor class that groups colored LEDs
within a LED node.
The multi color class groups monochrome LEDs and allows controlling two
aspects of the final combined color: hue and lightness. The former is
controlled via the intensity file and the latter is controlled
via brightness
Add the reg property to each channel node. This update is
to accommodate the multicolor framework. In addition to the
accommodation this allows the LEDs to be placed on any channel
and allow designs to skip channels as opposed to requiring
sequential order.
Signed-off-by: Dan Murphy
CC: Linus
Add multicolor framework support for the lp55xx family.
Acked-by: Pavel Machek
Acked-by: Jacek Anaszewski
Signed-off-by: Dan Murphy
---
drivers/leds/Kconfig | 1 +
drivers/leds/leds-lp5521.c| 14 +-
drivers/leds/leds-lp5523.c| 14 +-
Add the reg property to each channel node. This update is
to accommodate the multicolor framework. In addition to the
accommodation this allows the LEDs to be placed on any channel
and allow designs to skip channels as opposed to requiring
sequential order.
Acked-by: Pavel Machek
Hi, Peter,
On Mon, Jun 15, 2020 at 09:09:28PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 15, 2020 at 11:55:29AM -0700, Fenghua Yu wrote:
>
> > Or do you suggest to add a random new flag in struct thread_info instead
> > of a TIF flag?
>
> Why thread_info? What's wrong with something simple like
Hi Syed,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on 444fc5cde64330661bf59944c43844e7d4c2ccd8]
url:
https://github.com/0day-ci/linux/commits/Syed-Nayyar-Waris/Introduce-the-for_each_set_clump-macro/20200615-205729
base
On Mon, Jun 15, 2020 at 04:51:32PM +0800, Jason Yan wrote:
> This is an effort to eliminate the uninitialized_var() macro[1].
>
> The use of this macro is the wrong solution because it forces off ANY
> analysis by the compiler for a given variable. It even masks "unused
> variable" warnings.
>
>
On Mon, Jun 01, 2020 at 08:15:17AM -0700, Randy Dunlap wrote:
> Hi,
>
> Sorry I didn't respond to v31 with this so that it could
> have been fixed in v32.
v32 was just a quick update to v31 (did both within maybe 2h window).
>
> On 6/1/20 12:52 AM, Jarkko Sakkinen wrote:
> > diff --git
From: Wang Qing
Date: Mon, 15 Jun 2020 17:02:23 +0800
> Use kobj_to_dev() instead of container_of()
>
> Signed-off-by: Wang Qing
Applied, thanks.
From: Geliang Tang
Date: Mon, 15 Jun 2020 16:34:28 +0800
> Use list_first_entry_or_null to simplify the code.
>
> Signed-off-by: Geliang Tang
Applied, thanks.
From: Colin King
Date: Mon, 15 Jun 2020 09:29:11 +0100
> From: Colin Ian King
>
> There is a spelling mistake in a comment. Fix it.
>
> Signed-off-by: Colin Ian King
Applied, thanks.
From: Geliang Tang
Date: Mon, 15 Jun 2020 16:28:03 +0800
> We have defined MPTCP_PM_ADDR_MAX in pm_netlink.c, so drop this duplicate
> macro.
>
> Fixes: 1b1c7a0ef7f3 ("mptcp: Add path manager interface")
> Signed-off-by: Geliang Tang
> ---
> Changes in v2:
> - change Subject from "mptcp:
On Mon, Jun 15, 2020 at 10:14:04AM -0700, Paul E. McKenney wrote:
> On Mon, Jun 15, 2020 at 06:24:27PM +0200, Peter Zijlstra wrote:
> > On Mon, Jun 15, 2020 at 05:55:13PM +0200, Peter Zijlstra wrote:
> > > On Mon, Jun 15, 2020 at 05:49:05PM +0200, Peter Zijlstra wrote:
> > > > @@ -983,13 +993,17
On Mon, 15 Jun 2020 20:48:11 +0200,
Shuah Khan wrote:
>
> I am seeing the following problem on my system. I haven't started debug
> yet. Is this a known issue?
Yes, the recent fix by David should paper over it:
Hi Rikard,
On Mon, 8 Jun 2020 at 23:18, Rikard Falkeborn
wrote:
>
> When calling the GENMASK and GENMASK_ULL macros with zero lower bit and
> an unsigned unknown high bit, some gcc versions warn due to the
> comparisons of the high and low bit in GENMASK_INPUT_CHECK.
>
> To silence the warnings,
On Mon, Jun 15, 2020 at 09:11:58PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 15, 2020 at 10:21:49AM -0700, Paul E. McKenney wrote:
> > On Mon, Jun 15, 2020 at 06:40:48PM +0200, Peter Zijlstra wrote:
>
> > > Thanks! I've got 16*TREE03 running since this morning, so far so nothing
> > > :/
> > >
Hi all,
On Thu, 11 Jun 2020 at 10:11, Joerg Roedel wrote:
>
> From: Joerg Roedel
>
> The patch introducing the struct was probably never compile tested,
> because it sets a handler with a wrong function signature. Wrap the
> handler into a functions with the correct signature to fix the build.
> From: linux-hyperv-ow...@vger.kernel.org
> On Behalf Of Dexuan Cui
> Sent: Monday, June 15, 2020 10:42 AM
> > >
> > > Hi hch,
> > > The patch is merged into the mainine recently, but unluckily we noticed
> > > a warning with CONFIG_DEBUG_WX=y
> > >
> > > Should we revert this patch, or figure
On Mon, Jun 15, 2020 at 11:48 AM Shuah Khan wrote:
>
> I am seeing the following problem on my system. I haven't started debug
> yet. Is this a known issue?
>
> [9.791309] BUG: unable to handle page fault for address:
> b1e78165d000
> [9.791328] #PF: supervisor write access in kernel
On Mon, 15 Jun 2020, Shuah Khan wrote:
> I am seeing the following problem on my system. I haven't started debug
> yet. Is this a known issue?
>
> [9.791309] BUG: unable to handle page fault for address: b1e78165d000
> [9.791328] #PF: supervisor write access in kernel mode
> [
-20200615
i386 randconfig-a002-20200615
i386 randconfig-a001-20200615
i386 randconfig-a004-20200615
i386 randconfig-a005-20200615
i386 randconfig-a003-20200615
x86_64 randconfig-a015-20200615
x86_64
On Mon, Jun 15, 2020 at 2:47 PM Arnd Bergmann wrote:
>
> On Mon, Jun 15, 2020 at 4:48 PM Brian Gerst wrote:
> > On Mon, Jun 15, 2020 at 10:13 AM Christoph Hellwig wrote:
> > > On Mon, Jun 15, 2020 at 03:31:35PM +0200, Arnd Bergmann wrote:
>
> > >
> > > I'd rather keep it in common code as that
On Mon, Jun 15, 2020 at 10:06:20AM -0700, Andy Lutomirski wrote:
> On Mon, Jun 15, 2020 at 7:50 AM Peter Zijlstra wrote:
> Hmm. IMO you're making two changes here, and this is fiddly enough
> that it might be worth separating them for bisection purposes.
Sure, can do.
> > ---
> >
> > diff
This patch series adds partial read support via a new call
request_partial_firmware_into_buf.
Such support is needed when the whole file is not needed and/or
only a smaller portion of the file will fit into allocated memory
at any one time.
In order to accept the enhanced API it has been requested
Add FIRMWARE_PARTIAL_READ support for integrity
measurement on partial reads of firmware files.
Signed-off-by: Scott Branden
---
security/integrity/ima/ima_main.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/security/integrity/ima/ima_main.c
Add maintainer entry for new Broadcom VK Driver
Signed-off-by: Scott Branden
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 83078661cd2b..ce29c7d0b228 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3657,6 +3657,13 @@ L:
On Thu, Jun 04, 2020 at 04:16:31AM -0700, Stephen Boyd wrote:
> Quoting Sandeep Maheswaram (Temp) (2020-06-04 02:43:09)
> >
> > On 6/3/2020 11:06 PM, Stephen Boyd wrote:
> > > Quoting Sandeep Maheswaram (2020-03-31 22:15:43)
> > >> diff --git a/drivers/usb/dwc3/dwc3-qcom.c
On 6/15/2020 12:09 PM, Robin Murphy wrote:
> On 2020-06-08 12:41, Lukas Wunner wrote:
>> On Mon, Jun 08, 2020 at 12:11:11PM +0100, Robin Murphy wrote:
>>> And all in code that has at least one obvious inefficiency left on
>>> the table either way.
>>
>> Care to submit a patch to overcome that
Add firmware tests for partial file reads of
request_partial_firmware_into_buf.
Signed-off-by: Scott Branden
---
.../selftests/firmware/fw_filesystem.sh | 80 +++
1 file changed, 80 insertions(+)
diff --git a/tools/testing/selftests/firmware/fw_filesystem.sh
Add additional hooks to test_firmware to pass in support
for partial file read using request_firmware_into_buf.
buf_size: size of buffer to request firmware into
partial: indicates that a partial file request is being made
file_offset: to indicate offset into file to request
Signed-off-by: Scott
Add Broadcom VK driver offload engine.
This driver interfaces to the VK PCIe offload engine to perform
should offload functions as video transcoding on multiple streams
in parallel. VK device is booted from files loaded using
request_firmware_into_buf mechanism. After booted card status is
Add user space api for bcm-vk driver.
Signed-off-by: Scott Branden
---
include/uapi/linux/misc/bcm_vk.h | 99
1 file changed, 99 insertions(+)
create mode 100644 include/uapi/linux/misc/bcm_vk.h
diff --git a/include/uapi/linux/misc/bcm_vk.h
Add request_partial_firmware_into_buf to allow for portions
of firmware file to be read into a buffer. Necessary where firmware
needs to be loaded in portions from file in memory constrained systems.
Signed-off-by: Scott Branden
---
drivers/base/firmware_loader/firmware.h | 5 ++
Add kernel_pread_file* support to kernel to allow for partial read
of files with an offset into the file.
Signed-off-by: Scott Branden
---
fs/exec.c | 93 ++
include/linux/fs.h | 15
2 files changed, 85 insertions(+), 23 deletions(-)
On Mon, Jun 15, 2020 at 5:56 AM Borislav Petkov wrote:
>
> On Mon, Jun 15, 2020 at 06:14:03PM +0530, Vaibhav Jain wrote:
> > 'seq_buf' provides a very useful abstraction for writing to a string
> > buffer without needing to worry about it over-flowing. However even
> > though the API has been
On Thu, Jun 04, 2020 at 01:29:44PM -0700, Nick Desaulniers wrote:
> On Thu, Jun 4, 2020 at 1:20 PM Kees Cook wrote:
> >
> > On Thu, Jun 04, 2020 at 12:29:17PM -0700, Nick Desaulniers wrote:
> > > On Wed, Jun 3, 2020 at 4:32 PM Kees Cook wrote:
> > > >
> > > > Using uninitialized_var() is
On Mon, Jun 15, 2020 at 08:40:41PM +0200, Peter Zijlstra wrote:
> > @@ -186,8 +187,10 @@ int cpuidle_enter_s2idle(struct cpuidle_driver *drv,
> > struct cpuidle_device *dev)
> > * be frozen safely.
> > */
> > index = find_deepest_state(drv, dev, U64_MAX, 0, true);
> > - if (index
The following commit has been merged into the x86/cleanups branch of tip:
Commit-ID: 1068ed4547adf6123504d9623ebd1ffcdd616101
Gitweb:
https://git.kernel.org/tip/1068ed4547adf6123504d9623ebd1ffcdd616101
Author:Borislav Petkov
AuthorDate:Mon, 08 Jun 2020 16:19:49 +02:00
> -Original Message-
> From: Paolo Bonzini
>
> On 10/06/20 19:43, Bird, Tim wrote:
> >>> (rc=$?; \
> >>> if [ $rc -eq $skip_rc ]; then \
> >>> - echo "not ok $test_num $TEST_HDR_MSG # SKIP"
> >>> + echo "ok $test_num
The following commit has been merged into the x86/cleanups branch of tip:
Commit-ID: 28b60197b573cd0b2d8f0ded56a5441c6147af14
Gitweb:
https://git.kernel.org/tip/28b60197b573cd0b2d8f0ded56a5441c6147af14
Author:Borislav Petkov
AuthorDate:Thu, 04 Jun 2020 12:50:44 +02:00
el/rcu/tree.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- linux-next-20200615.orig/kernel/rcu/tree.c
+++ linux-next-20200615/kernel/rcu/tree.c
@@ -944,7 +944,6 @@ void __rcu_irq_enter_check_tick(void)
/**
* rcu_nmi_enter - inform RCU of entry to NMI context
- * @ir
The following commit has been merged into the x86/cleanups branch of tip:
Commit-ID: fbd5969d1ff2598143d6a6fbc9491a9e40ab9b82
Gitweb:
https://git.kernel.org/tip/fbd5969d1ff2598143d6a6fbc9491a9e40ab9b82
Author:Borislav Petkov
AuthorDate:Thu, 04 Jun 2020 12:38:39 +02:00
On Mon, Jun 15, 2020 at 06:31:58PM +0100, Robin Murphy wrote:
> Now that I've been inclined to go and look up the documentation, are we sure
> this so-very-contentious check is even correct? From my reading of things
> we're checking whether the RXR interrupt function is *enabled*, which still
>
Greg Kroah-Hartman
Cc: linux-ser...@vger.kernel.org
---
drivers/tty/serial/serial_core.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- linux-next-20200615.orig/drivers/tty/serial/serial_core.c
+++ linux-next-20200615/drivers/tty/serial/serial_core.c
@@ -3289,8 +3289,7 @@ EXP
On Mon, 2020-06-15 at 15:11 -0400, Steven Rostedt wrote:
> On Sat, 13 Jun 2020 00:23:18 +0900
> Masami Hiramatsu wrote:
[]
> > diff --git a/fs/proc/bootconfig.c b/fs/proc/bootconfig.c
[]
> > @@ -27,6 +27,7 @@ static int __init copy_xbc_key_value_list(char *dst,
> > size_t size)
> > {
> >
ument to the
block_bio_complete tracepoint")
Signed-off-by: Randy Dunlap
Cc: Christoph Hellwig
Cc: Jens Axboe
---
include/trace/events/block.h |1 -
1 file changed, 1 deletion(-)
--- linux-next-20200615.orig/include/trace/events/block.h
+++ linux-next-20200615/include/trace/even
On Mon, 15 Jun 2020 21:40:38 +1000
Herbert Xu wrote:
> Thanks for investigating. I now realise that this was sent against
> my first patch which did have this problem, which was fixed in my
> second patch. Sorry for the false alarm.
Which is why it is recommended that new patches start their
On Sat, 13 Jun 2020 00:23:35 +0900
Masami Hiramatsu wrote:
> Fix bootconfig to return 0 if succeeded to show the bootconfig
> in initrd. Without this fix, "bootconfig INITRD" command
> returns !0 even if the command succeeded to show the bootconfig.
>
> Fixes: 950313ebf79c ("tools: bootconfig:
On Sat, 13 Jun 2020 00:23:18 +0900
Masami Hiramatsu wrote:
> Fix /proc/bootconfig to show the correctly choose the
> double or single quotes according to the value.
>
> If a bootconfig value includes a double quote character,
> we must use single-quotes to quote that value.
>
> Fixes:
Hello Catalin, Will,
On Tue, Jun 2, 2020 at 10:54 AM Bhupesh Sharma wrote:
>
> Hello,
>
> On Thu, May 14, 2020 at 12:22 AM Bhupesh Sharma wrote:
> >
> > Apologies for the delayed update. Its been quite some time since I
> > posted the last version (v5), but I have been really caught up in some
On Mon, Jun 15, 2020 at 10:21:49AM -0700, Paul E. McKenney wrote:
> On Mon, Jun 15, 2020 at 06:40:48PM +0200, Peter Zijlstra wrote:
> > Thanks! I've got 16*TREE03 running since this morning, so far so nothing :/
> > (FWIW that's 16/9 times overcommit, idle time fluctuates around 10%).
>
> My
On Mon, Jun 15, 2020 at 12:33 AM Jann Horn wrote:
>
> So in summary I guess the test was just really slow up until now
> because it was hitting a slowpath that you wouldn't hit during normal
> usage? At least for vmsplice(), writing uninitialized pages doesn't
> really make a whole lot of
On 2020-06-08 12:41, Lukas Wunner wrote:
On Mon, Jun 08, 2020 at 12:11:11PM +0100, Robin Murphy wrote:
And all in code that has at least one obvious inefficiency left on
the table either way.
Care to submit a patch to overcome that inefficiency?
I'll have a quick go, but without any way to
On Mon, Jun 15, 2020 at 11:55:29AM -0700, Fenghua Yu wrote:
> Or do you suggest to add a random new flag in struct thread_info instead
> of a TIF flag?
Why thread_info? What's wrong with something simple like the below. It
takes a bit from the 'strictly current' flags word.
diff --git
Kees,
Thanks for the great feedback. See comments inline below.
> -Original Message-
> From: Kees Cook
>
> On Wed, Jun 10, 2020 at 06:11:06PM +, Bird, Tim wrote:
> > The kernel test result format consists of 5 major elements,
> > 4 of which are line-based:
> > * the output
On Sun, 2020-06-14 at 21:51 +0800, Zhixu Zhao wrote:
> Fix a coding alignment issue found by checkpatch.pl.
Another option would be to use a temporary for
gasket_dev->bar_data[bar_num]
Something like:
---
drivers/staging/gasket/gasket_core.c | 29 ++---
1 file changed,
Mark,
This block is used on multiple Broadcom SoCs and would like to get
comments from all who deal with iProc and have touched this file as
well.
Please copy :
Florian Fainelli
Rayagonda Kokatanur
and
bcm-kernel-feedback-l...@broadcom.com (maintainer:BROADCOM SPI DRIVER)
Kamal
On Mon, Jun
On Sat, Jun 13, 2020 at 12:29 PM Rafael J. Wysocki wrote:
[,,]
> > While I agree that this is still somewhat suboptimal, improving this
> > would require more changes in the OSL code.
>
> After writing the above I started to think about the extra changes needed
> to improve that and I realized
On 6/15/20 13:35, Denis Efremov wrote:
>
>
> On 6/15/20 9:23 PM, Kees Cook wrote:
>> On Mon, Jun 15, 2020 at 01:20:45PM +0300, Denis Efremov wrote:
>>> Detect an opencoded expression that is used before or after
>>> array_size()/array3_size()/struct_size() to compute the same size.
>>>
>>>
On Mon, Jun 15, 2020 at 8:43 PM Marco Elver wrote:
>
> Unconditionally add -fno-stack-protector to KCOV's compiler options, as
> all supported compilers support the option. This saves a compiler
> invocation to determine if the option is supported.
>
> Because Clang does not support
The driver function tg3_io_error_detected() calls napi_disable twice,
without an intervening napi_enable, when the number of EEH errors exceeds
eeh_max_freezes, resulting in an indefinite sleep while holding rtnl_lock.
The function is called once with the PCI state pci_channel_io_frozen and
then
On Mon, Jun 15, 2020 at 08:33:25PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 15, 2020 at 10:14:04AM -0700, Paul E. McKenney wrote:
>
> > This merge window has been quite the trainwreck, hasn't it? :-/
>
> Keeps life interesting I suppose..
;-) ;-) ;-)
On Tue, Jun 09, 2020 at 01:45:53PM +0100, Kieran Bingham wrote:
> I wouldn't normally go through spelling fixes, but I caught sight of
> this typo twice, and then foolishly grepped the tree for it, and saw how
> pervasive it was.
>
> so here I am ... fixing a typo globally... but with an addition
Hi, Peter,
On Mon, Jun 15, 2020 at 08:31:16PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 15, 2020 at 11:12:59AM -0700, Fenghua Yu wrote:
> > > I don't get why you need a rdmsr here, or why not having one would
> > > require a TIF flag. Is that because this MSR is XSAVE/XRSTOR managed?
> >
> > My
> From: Chen Yu
> Sent: Thursday, May 21, 2020 10:59 AM
> To: Kirsher, Jeffrey T ; David S. Miller
> ; Jakub Kicinski ; Kok, Auke-jan H
> ; Jeff Garzik
> Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Brown, Len ; Rafael J. Wysocki
> ; Shevchenko,
I am seeing the following problem on my system. I haven't started debug
yet. Is this a known issue?
[9.791309] BUG: unable to handle page fault for address:
b1e78165d000
[9.791328] #PF: supervisor write access in kernel mode
[9.791330] #PF: error_code(0x000b) - reserved bit
On Mon, Jun 15, 2020 at 11:23:44AM -0700, Nick Desaulniers wrote:
> On Mon, Jun 15, 2020 at 11:21 AM Kees Cook wrote:
> >
> > On Mon, Jun 15, 2020 at 11:12:32AM -0700, Sami Tolvanen wrote:
> > > Commit 8c0637e950d6 ("keys: Make the KEY_NEED_* perms an enum rather than
> > > a mask") changed the
On Mon, Jun 15, 2020 at 4:48 PM Brian Gerst wrote:
> On Mon, Jun 15, 2020 at 10:13 AM Christoph Hellwig wrote:
> > On Mon, Jun 15, 2020 at 03:31:35PM +0200, Arnd Bergmann wrote:
> >
> > I'd rather keep it in common code as that allows all the low-level
> > exec stuff to be marked static, and
On Mon, Jun 15, 2020 at 11:07 AM Nick Desaulniers
wrote:
>
> On Mon, Jun 15, 2020 at 10:59 AM 'Eric Dumazet' via Clang Built Linux
> wrote:
> >
> > On Mon, Jun 15, 2020 at 10:54 AM Eric Dumazet wrote:
> > >
> > > On Mon, Jun 15, 2020 at 10:44 AM Nick Desaulniers
> > > wrote:
> > > >
> > > > On
On Mon, Jun 15, 2020 at 11:34:48AM -0700, Matt Helsley wrote:
> On Fri, Jun 12, 2020 at 04:30:35PM +0200, Peter Zijlstra wrote:
> > With there being multiple ways to change the ELF data, let's more
> > concisely track modification.
> >
> > Signed-off-by: Peter Zijlstra (Intel)
>
> Would it make
On Mon, Jun 15, 2020 at 05:45:28PM +, Bird, Tim wrote:
> Personally, as a human I find the space prefix a bit easier to read.
> However, I think that in "normal" kernel log output it is unusual for
> a line to be prefixed with a hash (#), so this might be easier to
> both visually distinguish
Unconditionally add -fno-stack-protector to KCOV's compiler options, as
all supported compilers support the option. This saves a compiler
invocation to determine if the option is supported.
Because Clang does not support -fno-conserve-stack, and
-fno-stack-protector was wrapped in the same
On Mon, Jun 15, 2020 at 06:31:50PM +, Luck, Tony wrote:
> > In general, this should say something along the lines that /proc/cpuinfo
> > shows features which the kernel supports.
> >
> > "For a full list of CPUID flags which the CPU supports, use
> > tools/arch/x86/tools/cpuid/cpuid"
> >
> >
From: Youquan Song
Skylake has a mode where the system administrator can use a BIOS setup
option to request that the memory controller report uncorrected errors
found by the patrol scrubber as corrected. This results in them being
signalled using CMCI, which is less disruptive than a machine
On Tue, Jun 16, 2020 at 01:36:11AM +0800, Chen Yu wrote:
> Suspend to idle was found to not work on Goldmont CPU recently.
> And the issue was triggered due to:
>
> 1. On Goldmont the CPU in idle can only be woken up via IPIs,
>not POLL mode:
>Commit 08e237fa56a1 ("x86/cpu: Add workaround
On 6/15/20 2:07 PM, Dan Carpenter wrote:
On Mon, Apr 13, 2020 at 05:15:49PM -0400, Waiman Long wrote:
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 23c7500eea7d..c08bc7eb20bd 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -1707,17 +1707,17 @@ void *krealloc(const void *p,
On Thu, Jun 04, 2020 at 03:39:02PM +0100, Colin King wrote:
> From: Colin Ian King
>
> The assignment to resp.response_length is never read since it is being
> updated again on the next statement. The assignment is redundant so
> removed it.
>
> Addresses-Coverity: ("Unused value")
>
On Mon, Jun 15, 2020 at 01:30:42PM -0300, Vitor Massaru Iha wrote:
> On Fri, 2020-06-12 at 15:36 -0700, Kees Cook wrote:
> > Why drop the __initconst?
>
> I removed __initconst because of these warnings below, as it is used
> for the kernel during the module initialization, and I do not use the
>
On 6/15/20 11:31 AM, Luck, Tony wrote:
>> In general, this should say something along the lines that /proc/cpuinfo
>> shows features which the kernel supports.
>>
>> "For a full list of CPUID flags which the CPU supports, use
>> tools/arch/x86/tools/cpuid/cpuid"
>>
>> :-)
> Dave Hansen had
On 6/15/20 9:23 PM, Kees Cook wrote:
> On Mon, Jun 15, 2020 at 01:20:45PM +0300, Denis Efremov wrote:
>> Detect an opencoded expression that is used before or after
>> array_size()/array3_size()/struct_size() to compute the same size.
>>
>> Cc: Kees Cook
>> Signed-off-by: Denis Efremov
>
>
On Fri, Jun 12, 2020 at 04:30:35PM +0200, Peter Zijlstra wrote:
> With there being multiple ways to change the ELF data, let's more
> concisely track modification.
>
> Signed-off-by: Peter Zijlstra (Intel)
Would it make sense to set the relocation section's "changed" flag in
addition to the elf
On Mon, Jun 15, 2020 at 10:14:04AM -0700, Paul E. McKenney wrote:
> This merge window has been quite the trainwreck, hasn't it? :-/
Keeps life interesting I suppose..
On Mon, Jun 15, 2020 at 8:25 PM Mel Gorman wrote:
>
> On Mon, Jun 15, 2020 at 07:26:38PM +0300, Amir Goldstein wrote:
> > On Mon, Jun 15, 2020 at 3:14 PM Mel Gorman
> > wrote:
> > >
> > > Changelog since v1
> > > o Updated changelog
> >
> > Slipped to commit message
> >
>
> It's habit, it's the
On Mon, Jun 15, 2020 at 11:12:59AM -0700, Fenghua Yu wrote:
> > I don't get why you need a rdmsr here, or why not having one would
> > require a TIF flag. Is that because this MSR is XSAVE/XRSTOR managed?
>
> My concern is TIF flags are precious (only 3 slots available). Defining
> a new TIF flag
On Mon, Jun 15, 2020 at 11:19:21AM -0700, Raj, Ashok wrote:
> On Mon, Jun 15, 2020 at 06:03:57PM +0200, Peter Zijlstra wrote:
> >
> > I don't get why you need a rdmsr here, or why not having one would
> > require a TIF flag. Is that because this MSR is XSAVE/XRSTOR managed?
> >
> > > > > +
> In general, this should say something along the lines that /proc/cpuinfo
> shows features which the kernel supports.
>
> "For a full list of CPUID flags which the CPU supports, use
> tools/arch/x86/tools/cpuid/cpuid"
>
> :-)
Dave Hansen had suggested (offline) that we add a cpuid tool to the
Hi Steven,
> On Jun 5, 2020, at 3:02 PM, Steven Rostedt wrote:
>
> On Fri, 5 Jun 2020 21:58:48 +
> Song Liu wrote:
>
>>
>> How does this work in your tests?
>
> I started it, but got distracted by other work. It did not crash with
> the little testing I did do. I wanted to also look at
On Sat, Jun 13, 2020 at 12:26:09AM -0700, Sargun Dhillon wrote:
> This introduces an extensibility mechanism to receive seccomp
> notifications. It uses read(2), as opposed to using an ioctl. The listener
> must be first configured to write the notification via the
> SECCOMP_IOCTL_NOTIF_CONFIG
On Tue, Jun 02, 2020 at 07:48:22PM +0530, Sumit Garg wrote:
> diff --git a/security/keys/Kconfig b/security/keys/Kconfig
> index 47c0415..22632c6 100644
> --- a/security/keys/Kconfig
> +++ b/security/keys/Kconfig
> @@ -72,17 +72,26 @@ config BIG_KEYS
>
> config TRUSTED_KEYS
> tristate
401 - 500 of 1560 matches
Mail list logo
