[PATCH v3 2/2] fs: fsnotify: account fsnotify metadata to kmemcg

A lot of memory can be consumed by the events generated for the huge or unlimited queues if there is either no or slow listener. This can cause system level memory pressure or OOMs. So, it's better to account the fsnotify kmem caches to the memcg of the listener. There are seven fsnotify kmem

Re: [PATCH v2 08/10] gpio: Add gpio driver for Actions OWL S900 SoC

Am 21.02.2018 um 20:13 schrieb Andy Shevchenko: > On Wed, Feb 21, 2018 at 6:00 PM, Manivannan Sadhasivam > wrote: >> Add gpio driver for Actions Semi OWL family S900 SoC. Set of registers >> controlling the gpio shares the same register range with pinctrl block. >> >> GPIO registers are organized

[PATCH v3 1/2] mm: memcg: remote memcg charging for kmem allocations

Introducing the memcg variant for kmalloc and kmem_cache_alloc. For kmem_cache_alloc, the kernel switches the root kmem cache with the memcg specific kmem cache for __GFP_ACCOUNT allocations to charge those allocations to the memcg. However, the memcg to charge is extracted from the current

[PATCH v3 0/2] Directed kmem charging

This patchset introduces memcg variant memory allocation functions. The caller can explicitly pass the memcg to charge for kmem allocations. Currently the kernel, for __GFP_ACCOUNT memory allocation requests, extract the memcg of the current task to charge for the kmem allocation. This patch

[PATCH v3 1/2] mm: memcg: remote memcg charging for kmem allocations

Introducing the memcg variant for kmalloc and kmem_cache_alloc. For kmem_cache_alloc, the kernel switches the root kmem cache with the memcg specific kmem cache for __GFP_ACCOUNT allocations to charge those allocations to the memcg. However, the memcg to charge is extracted from the current

[PATCH v3 0/2] Directed kmem charging

This patchset introduces memcg variant memory allocation functions. The caller can explicitly pass the memcg to charge for kmem allocations. Currently the kernel, for __GFP_ACCOUNT memory allocation requests, extract the memcg of the current task to charge for the kmem allocation. This patch

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On Tue, Feb 20, 2018 at 9:16 AM, Igor Stoppa wrote: > > > On 13/02/18 20:10, Laura Abbott wrote: >> On 02/13/2018 07:20 AM, Igor Stoppa wrote: >>> Why alterations of page properties are not considered a risk and the >>> physmap is? >>> And how would it be easier (i

Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On Tue, Feb 20, 2018 at 9:16 AM, Igor Stoppa wrote: > > > On 13/02/18 20:10, Laura Abbott wrote: >> On 02/13/2018 07:20 AM, Igor Stoppa wrote: >>> Why alterations of page properties are not considered a risk and the >>> physmap is? >>> And how would it be easier (i suppose) to attack the latter?

Re: [PATCH 1/6] genalloc: track beginning of allocations

On Wed, 21 Feb 2018 14:29:06 -0800 Kees Cook wrote: > >> I wonder if this might be more readable by splitting the kernel-doc > >> changes from the bitmap changes? I.e. fix all the kernel-doc in one > >> patch, and in the following, make the bitmap changes. Maybe it's such

Proposal

Hello Greetings to you and everyone around you please did you get my previous email regarding my proposal ? please let me know if we can work together on this. Best Reagrds

Re: [PATCH 1/6] genalloc: track beginning of allocations

On Wed, 21 Feb 2018 14:29:06 -0800 Kees Cook wrote: > >> I wonder if this might be more readable by splitting the kernel-doc > >> changes from the bitmap changes? I.e. fix all the kernel-doc in one > >> patch, and in the following, make the bitmap changes. Maybe it's such > >> a small part that

Proposal

Hello Greetings to you and everyone around you please did you get my previous email regarding my proposal ? please let me know if we can work together on this. Best Reagrds

[PATCH] pcf85063 was not clearing bits correctly in pcf85063_start_clock

Bit clear operation was missing ~ Signed-off-by: Michael McCormick --- drivers/rtc/rtc-pcf85063.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-pcf85063.c b/drivers/rtc/rtc-pcf85063.c index a06dff9..67bc763 100644 ---

[PATCH] pcf85063 was not clearing bits correctly in pcf85063_start_clock

Bit clear operation was missing ~ Signed-off-by: Michael McCormick --- drivers/rtc/rtc-pcf85063.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-pcf85063.c b/drivers/rtc/rtc-pcf85063.c index a06dff9..67bc763 100644 --- a/drivers/rtc/rtc-pcf85063.c +++

Re: linux-next: address change for the contact of the rtc tree

Hello Stephen, On 22/02/2018 at 09:15:31 +1100, Stephen Rothwell wrote: > Hi Alexandre, > > I notcied this commit > > f6dbaad611f9 ("MAINTAINERS: rtc: update my email address") > > in the rtc tree today. Should I update the email address I use for the > rtc tree contact? > Yes, please do.

Re: linux-next: address change for the contact of the rtc tree

Hello Stephen, On 22/02/2018 at 09:15:31 +1100, Stephen Rothwell wrote: > Hi Alexandre, > > I notcied this commit > > f6dbaad611f9 ("MAINTAINERS: rtc: update my email address") > > in the rtc tree today. Should I update the email address I use for the > rtc tree contact? > Yes, please do.

Re: [PATCH] tools/memory-model: update: remove rb-dep, smp_read_barrier_depends, and lockless_dereference

On 2018/02/22 2:15, Alan Stern wrote: > Commit bf28ae562744 ("tools/memory-model: Remove rb-dep, > smp_read_barrier_depends, and lockless_dereference") was accidentally > merged too early, while it was still in RFC form. This patch adds in > the missing pieces. > > Akira pointed out some typos

Re: [PATCH] tools/memory-model: update: remove rb-dep, smp_read_barrier_depends, and lockless_dereference

On 2018/02/22 2:15, Alan Stern wrote: > Commit bf28ae562744 ("tools/memory-model: Remove rb-dep, > smp_read_barrier_depends, and lockless_dereference") was accidentally > merged too early, while it was still in RFC form. This patch adds in > the missing pieces. > > Akira pointed out some typos

Re: [PATCH 1/6] genalloc: track beginning of allocations

On Tue, Feb 20, 2018 at 9:07 AM, Igor Stoppa wrote: > On 13/02/18 01:52, Kees Cook wrote: >> On Mon, Feb 12, 2018 at 8:52 AM, Igor Stoppa wrote: >>> @@ -738,14 +1031,16 @@ EXPORT_SYMBOL(devm_gen_pool_create); >>> >>> #ifdef CONFIG_OF >>> /** >>>

Re: [PATCH 1/6] genalloc: track beginning of allocations

On Tue, Feb 20, 2018 at 9:07 AM, Igor Stoppa wrote: > On 13/02/18 01:52, Kees Cook wrote: >> On Mon, Feb 12, 2018 at 8:52 AM, Igor Stoppa wrote: >>> @@ -738,14 +1031,16 @@ EXPORT_SYMBOL(devm_gen_pool_create); >>> >>> #ifdef CONFIG_OF >>> /** >>> - * of_gen_pool_get - find a pool by phandle

Re: [PATCH 2/6] genalloc: selftest

On Tue, Feb 20, 2018 at 8:59 AM, Igor Stoppa wrote: > > > On 13/02/18 01:50, Kees Cook wrote: >> On Mon, Feb 12, 2018 at 8:52 AM, Igor Stoppa wrote: > > [...] > >>> lib/genalloc-selftest.c | 400 >>>

Re: [PATCH 2/6] genalloc: selftest

On Tue, Feb 20, 2018 at 8:59 AM, Igor Stoppa wrote: > > > On 13/02/18 01:50, Kees Cook wrote: >> On Mon, Feb 12, 2018 at 8:52 AM, Igor Stoppa wrote: > > [...] > >>> lib/genalloc-selftest.c | 400 >>> ++ >> >> Nit: make this test_genalloc.c instead.

[PATCHv2 2/2] selftests: ion: Add simple test with the vgem driver

Ion is designed to be a framework used by other clients who perform operations on the buffer. Use the DRM vgem client as a simple consumer. In conjunction with the dma-buf sync ioctls, this tests the full attach/map path for the system heap. Reviewed-by: Daniel Vetter

[PATCHv2 2/2] selftests: ion: Add simple test with the vgem driver

Ion is designed to be a framework used by other clients who perform operations on the buffer. Use the DRM vgem client as a simple consumer. In conjunction with the dma-buf sync ioctls, this tests the full attach/map path for the system heap. Reviewed-by: Daniel Vetter Signed-off-by: Laura Abbott

[PATCHv2 0/2] Ion unit test with VGEM

Hi, This is v2 of the series to add a unit test to Ion with VGEM. From v1: Ion hasn't had much in the way of unit tests and fixing that is something that needs to happen before it can move out of staging. The difficult part of testing parts of Ion is that it relies on having a kernel driver to

[PATCHv2 0/2] Ion unit test with VGEM

Hi, This is v2 of the series to add a unit test to Ion with VGEM. From v1: Ion hasn't had much in the way of unit tests and fixing that is something that needs to happen before it can move out of staging. The difficult part of testing parts of Ion is that it relies on having a kernel driver to

[PATCHv2 1/2] selftests: ion: Remove some prints

There's no need to print messages each time we alloc and free. Remove them. Signed-off-by: Laura Abbott --- v2: No changes --- tools/testing/selftests/android/ion/ionutils.c | 6 -- 1 file changed, 6 deletions(-) diff --git

[PATCHv2 1/2] selftests: ion: Remove some prints

There's no need to print messages each time we alloc and free. Remove them. Signed-off-by: Laura Abbott --- v2: No changes --- tools/testing/selftests/android/ion/ionutils.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/tools/testing/selftests/android/ion/ionutils.c

[PATCH] net/smc9194: Remove bogus CONFIG_MAC reference

AFAIK the only version of smc9194.c with Mac support is the one in the linux-mac68k CVS repo, which never made it to the mainline. Despite that, from v2.3.45, arch/m68k/config.in listed CONFIG_SMC9194 under CONFIG_MAC. This mistake got carried over into Kconfig in v2.5.55. (See pre-git era

[PATCH] net/smc9194: Remove bogus CONFIG_MAC reference

AFAIK the only version of smc9194.c with Mac support is the one in the linux-mac68k CVS repo, which never made it to the mainline. Despite that, from v2.3.45, arch/m68k/config.in listed CONFIG_SMC9194 under CONFIG_MAC. This mistake got carried over into Kconfig in v2.5.55. (See pre-git era

Re: [PATCH RFC tools/lkmm 10/12] tools/memory-model: Add a S lock-based external-view litmus test

On Wed, Feb 21, 2018 at 02:27:04PM -0500, Alan Stern wrote: > On Wed, 21 Feb 2018, Paul E. McKenney wrote: > > > > > +ISA2+pooncelock+pooncelock+pombonce.litmus > > > > + Tests whether the ordering provided by a lock-protected S litmus > > > > > > Call it an ISA2 litmus test, not an S

Re: [PATCH RFC tools/lkmm 10/12] tools/memory-model: Add a S lock-based external-view litmus test

On Wed, Feb 21, 2018 at 02:27:04PM -0500, Alan Stern wrote: > On Wed, 21 Feb 2018, Paul E. McKenney wrote: > > > > > +ISA2+pooncelock+pooncelock+pombonce.litmus > > > > + Tests whether the ordering provided by a lock-protected S litmus > > > > > > Call it an ISA2 litmus test, not an S

Re: [PATCH 5/6] Pmalloc: self-test

On Tue, Feb 20, 2018 at 8:40 AM, Igor Stoppa wrote: > > On 13/02/18 01:43, Kees Cook wrote: >> On Mon, Feb 12, 2018 at 8:53 AM, Igor Stoppa wrote: > > [...] > >>> +obj-$(CONFIG_PROTECTABLE_MEMORY_SELFTEST) += pmalloc-selftest.o >> >> Nit: self-test

Re: [PATCH 5/6] Pmalloc: self-test

On Tue, Feb 20, 2018 at 8:40 AM, Igor Stoppa wrote: > > On 13/02/18 01:43, Kees Cook wrote: >> On Mon, Feb 12, 2018 at 8:53 AM, Igor Stoppa wrote: > > [...] > >>> +obj-$(CONFIG_PROTECTABLE_MEMORY_SELFTEST) += pmalloc-selftest.o >> >> Nit: self-test modules are traditionally named "test_$thing.o"

Re: arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory)

On Tue, Feb 20, 2018 at 8:28 AM, Igor Stoppa wrote: > > > On 14/02/18 21:29, Kees Cook wrote: >> On Wed, Feb 14, 2018 at 11:06 AM, Laura Abbott wrote: > > [...] > >>> Kernel code should be fine, if it isn't that is a bug that should be >>> fixed.

Re: arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory)

On Tue, Feb 20, 2018 at 8:28 AM, Igor Stoppa wrote: > > > On 14/02/18 21:29, Kees Cook wrote: >> On Wed, Feb 14, 2018 at 11:06 AM, Laura Abbott wrote: > > [...] > >>> Kernel code should be fine, if it isn't that is a bug that should be >>> fixed. Modules yes are not fully protected. The

[PATCH] ARM: mx35_3ds: remove unnecessary USB OTG init flag

The platform-specific init function for the USB OTG port, mx35_3ds_otg_init(), sets the MXC_EHCI_INTERNAL_PHY flag. This flag is applicable only to the host port, not to the OTG port. It's ignored by mx35_initialize_usb_hw() when the OTG port is initialized. Remove the flag to make it clear what

[PATCH] ARM: mx35_3ds: remove unnecessary USB OTG init flag

The platform-specific init function for the USB OTG port, mx35_3ds_otg_init(), sets the MXC_EHCI_INTERNAL_PHY flag. This flag is applicable only to the host port, not to the OTG port. It's ignored by mx35_initialize_usb_hw() when the OTG port is initialized. Remove the flag to make it clear what

Re: [PATCH v4 2/2] leds: Add driver for NCP5623 3-channel I2C LED driver

On Wed, Feb 21, 2018 at 11:46 PM, Florian Vaussard wrote: > The NCP5623 is a 3-channel LED driver from On Semiconductor controlled > through I2C. The PWM of each channel can be independently set with 32 > distinct levels. In addition, the intensity of the current

Re: [PATCH v4 2/2] leds: Add driver for NCP5623 3-channel I2C LED driver

On Wed, Feb 21, 2018 at 11:46 PM, Florian Vaussard wrote: > The NCP5623 is a 3-channel LED driver from On Semiconductor controlled > through I2C. The PWM of each channel can be independently set with 32 > distinct levels. In addition, the intensity of the current source can be > globally set

RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11)

On 18.11.2017 06:14, Kees Cook wrote: > On Fri, Nov 17, 2017 at 5:54 PM, Patrick McLean wrote: >> On 2017-11-17 04:55 PM, Linus Torvalds wrote: >>> On Fri, Nov 17, 2017 at 4:27 PM, Patrick McLean wrote: I am still getting the crash at

RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11)

On 18.11.2017 06:14, Kees Cook wrote: > On Fri, Nov 17, 2017 at 5:54 PM, Patrick McLean wrote: >> On 2017-11-17 04:55 PM, Linus Torvalds wrote: >>> On Fri, Nov 17, 2017 at 4:27 PM, Patrick McLean wrote: I am still getting the crash at d9e12200852d, I figured I would double-check

linux-next: address change for the contact of the rtc tree

Hi Alexandre, I notcied this commit f6dbaad611f9 ("MAINTAINERS: rtc: update my email address") in the rtc tree today. Should I update the email address I use for the rtc tree contact? -- Cheers, Stephen Rothwell pgpvKW1txsq40.pgp Description: OpenPGP digital signature

linux-next: address change for the contact of the rtc tree

Hi Alexandre, I notcied this commit f6dbaad611f9 ("MAINTAINERS: rtc: update my email address") in the rtc tree today. Should I update the email address I use for the rtc tree contact? -- Cheers, Stephen Rothwell pgpvKW1txsq40.pgp Description: OpenPGP digital signature

Re: [PATCH] staging: typec: handle vendor defined part and modify drp toggling flow

On Wed, Feb 21, 2018 at 11:02:23PM +0800, ShuFanLee wrote: > From: ShuFanLee > > Handle vendor defined behavior in tcpci_init, tcpci_set_vconn and export > tcpci_irq. > More operations can be extended in tcpci_data if needed. > According to TCPCI specification, 4.4.5.2

Re: [PATCH] staging: typec: handle vendor defined part and modify drp toggling flow

On Wed, Feb 21, 2018 at 11:02:23PM +0800, ShuFanLee wrote: > From: ShuFanLee > > Handle vendor defined behavior in tcpci_init, tcpci_set_vconn and export > tcpci_irq. > More operations can be extended in tcpci_data if needed. > According to TCPCI specification, 4.4.5.2 ROLE_CONTROL, > TCPC

Re: [PATCH 2/2] selftests/gpio: Fix OUTPUT directory in Makefile

On Wed, Feb 21, 2018 at 11:52 PM, Daniel Díaz wrote: > When simply running `make' from the selftests top dir, this > error shows up: > > cc -O2 -g -std=gnu99 -Wall -I../../../../usr/include/ > -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/uuid >

Re: [PATCH 2/2] selftests/gpio: Fix OUTPUT directory in Makefile

On Wed, Feb 21, 2018 at 11:52 PM, Daniel Díaz wrote: > When simply running `make' from the selftests top dir, this > error shows up: > > cc -O2 -g -std=gnu99 -Wall -I../../../../usr/include/ > -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/uuid > gpio-mockup-chardev.c

Re: [PATCH v2 07/10] drivers: qcom: rpmh: cache sleep/wake state requests

Hi Lina, On Thu, Feb 15, 2018 at 9:35 AM, Lina Iyer wrote: > Active state requests are sent immediately to the mailbox controller, > while sleep and wake state requests are cached in this driver to avoid > taxing the mailbox controller repeatedly. The cached values will be

Re: [PATCH v2 07/10] drivers: qcom: rpmh: cache sleep/wake state requests

Hi Lina, On Thu, Feb 15, 2018 at 9:35 AM, Lina Iyer wrote: > Active state requests are sent immediately to the mailbox controller, > while sleep and wake state requests are cached in this driver to avoid > taxing the mailbox controller repeatedly. The cached values will be sent > to the

Re: [PATCH 1/2] selftests: gpio: restructure Makefile

On Wed, Feb 21, 2018 at 11:52 PM, Daniel Díaz wrote: > From: Fathi Boudra What are you doing here? Why? What is the benefit of it? > Signed-off-by: Fathi Boudra -- With Best Regards, Andy Shevchenko

Re: [PATCH 1/2] selftests: gpio: restructure Makefile

On Wed, Feb 21, 2018 at 11:52 PM, Daniel Díaz wrote: > From: Fathi Boudra What are you doing here? Why? What is the benefit of it? > Signed-off-by: Fathi Boudra -- With Best Regards, Andy Shevchenko

Re: [PATCH v2 1/8] [PATCH 1/8] drivers/peci: Add support for PECI bus driver core

On 2/21/2018 1:51 PM, Andrew Lunn wrote: Is there a real need to do transfers in atomic context, or with interrupts disabled? Actually, no. Generally, this function will be called in sleep-able context so this code is for an exceptional case handling. I'll rewrite this code like below:

Re: [PATCH v2 1/8] [PATCH 1/8] drivers/peci: Add support for PECI bus driver core

On 2/21/2018 1:51 PM, Andrew Lunn wrote: Is there a real need to do transfers in atomic context, or with interrupts disabled? Actually, no. Generally, this function will be called in sleep-able context so this code is for an exceptional case handling. I'll rewrite this code like below:

Re: [PATCH v2 1/2] iio: light: add driver for bh1730fvc chips

On Wed, Feb 21, 2018 at 9:45 PM, Pierre Bourdon wrote: > Ambient light sensor that supports visible light and IR measurements and > configurable gain/integration time. > > Changed in v2: > * Split off DT documentation change into a separate commit. > * Use i2c's probe_new.

Re: [PATCH v2 1/2] iio: light: add driver for bh1730fvc chips

On Wed, Feb 21, 2018 at 9:45 PM, Pierre Bourdon wrote: > Ambient light sensor that supports visible light and IR measurements and > configurable gain/integration time. > > Changed in v2: > * Split off DT documentation change into a separate commit. > * Use i2c's probe_new. Btw, how big the

Re: [PATCH] fs/iomap: fix memory leak on error condition

On Wed, Feb 21, 2018 at 08:41:28PM +, Garry McNulty wrote: > If the call to is_sync_kiocb() fails an error is returned without > freeing dio. Set the return code and jump to out_free_dio. > > Detected by CoverityScan, CID 1429424 ("Resource leak") Coverity is wrong. > Signed-off-by: Garry

Re: [PATCH] fs/iomap: fix memory leak on error condition

On Wed, Feb 21, 2018 at 08:41:28PM +, Garry McNulty wrote: > If the call to is_sync_kiocb() fails an error is returned without > freeing dio. Set the return code and jump to out_free_dio. > > Detected by CoverityScan, CID 1429424 ("Resource leak") Coverity is wrong. > Signed-off-by: Garry

Re: linux-next: Signed-off-by missing for commits in the renesas tree

On Thu, Feb 22, 2018 at 07:53:30AM +1100, Stephen Rothwell wrote: > Hi Simon, > > Commits > > b9f945d06b08 ("arm64: dts: renesas: Add R-Car Salvator-x M3-N support") > 4cc11f95789c ("soc: renesas: rcar-sysc: Add R-Car M3-N support") > > are missing a Signed-off-by from their committer.

Re: linux-next: Signed-off-by missing for commits in the renesas tree

On Thu, Feb 22, 2018 at 07:53:30AM +1100, Stephen Rothwell wrote: > Hi Simon, > > Commits > > b9f945d06b08 ("arm64: dts: renesas: Add R-Car Salvator-x M3-N support") > 4cc11f95789c ("soc: renesas: rcar-sysc: Add R-Car M3-N support") > > are missing a Signed-off-by from their committer.

[PATCH v2 2/2] arm64: cpufeature: Remove redundant "feature" in reports

The word "feature" is repeated in the CPU features reporting. This drops it for improved readability. Before (redundant "feature" word): SMP: Total of 4 processors activated. CPU features: detected feature: 32-bit EL0 Support CPU features: detected feature: Kernel page table isolation (KPTI)

[PATCH v2 2/2] arm64: cpufeature: Remove redundant "feature" in reports

The word "feature" is repeated in the CPU features reporting. This drops it for improved readability. Before (redundant "feature" word): SMP: Total of 4 processors activated. CPU features: detected feature: 32-bit EL0 Support CPU features: detected feature: Kernel page table isolation (KPTI)

Re: [PATCH 5/6] mm, hugetlb: further simplify hugetlb allocation API

On Wed 21-02-18 09:59:40, Mike Kravetz wrote: > On 02/21/2018 02:01 AM, Michal Hocko wrote: > > On Wed 21-02-18 10:55:26, Michal Hocko wrote: > > Hmm, I guess I can see it. Does the following help? > > --- > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > > index 7c204e3d132b..a963f2034dfc 100644 > >

Re: [PATCH 5/6] mm, hugetlb: further simplify hugetlb allocation API

On Wed 21-02-18 09:59:40, Mike Kravetz wrote: > On 02/21/2018 02:01 AM, Michal Hocko wrote: > > On Wed 21-02-18 10:55:26, Michal Hocko wrote: > > Hmm, I guess I can see it. Does the following help? > > --- > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > > index 7c204e3d132b..a963f2034dfc 100644 > >

Re: [PATCH] watchdog/hpwdt: update maintainer information

On Wed, Feb 21, 2018 at 02:22:01AM -0700, Jerry Hoemann wrote: > Signed-off-by: Jerry Hoemann Reviewed-by: Guenter Roeck > --- > MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index

Re: [PATCH] watchdog/hpwdt: update maintainer information

On Wed, Feb 21, 2018 at 02:22:01AM -0700, Jerry Hoemann wrote: > Signed-off-by: Jerry Hoemann Reviewed-by: Guenter Roeck > --- > MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 9a7f76eadae9..98b2ef91487d 100644 > ---

[PATCH 2/2] selftests/gpio: Fix OUTPUT directory in Makefile

When simply running `make' from the selftests top dir, this error shows up: cc -O2 -g -std=gnu99 -Wall -I../../../../usr/include/ -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/uuidgpio-mockup-chardev.c ../../../gpio/gpio-utils.o -lmount -o gpio-mockup-chardev cc: error:

[PATCH 2/2] selftests/gpio: Fix OUTPUT directory in Makefile

When simply running `make' from the selftests top dir, this error shows up: cc -O2 -g -std=gnu99 -Wall -I../../../../usr/include/ -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/uuidgpio-mockup-chardev.c ../../../gpio/gpio-utils.o -lmount -o gpio-mockup-chardev cc: error:

[PATCH 1/2] selftests: gpio: restructure Makefile

From: Fathi Boudra Signed-off-by: Fathi Boudra --- tools/testing/selftests/gpio/Makefile | 36 +-- 1 file changed, 17 insertions(+), 19 deletions(-) diff --git a/tools/testing/selftests/gpio/Makefile

[PATCH 1/2] selftests: gpio: restructure Makefile

From: Fathi Boudra Signed-off-by: Fathi Boudra --- tools/testing/selftests/gpio/Makefile | 36 +-- 1 file changed, 17 insertions(+), 19 deletions(-) diff --git a/tools/testing/selftests/gpio/Makefile b/tools/testing/selftests/gpio/Makefile index

Re: [PATCH v2 1/8] [PATCH 1/8] drivers/peci: Add support for PECI bus driver core

> >Is there a real need to do transfers in atomic context, or with > >interrupts disabled? > > > > Actually, no. Generally, this function will be called in sleep-able context > so this code is for an exceptional case handling. > > I'll rewrite this code like below: > if (in_atomic() ||

Re: [PATCH v2 1/8] [PATCH 1/8] drivers/peci: Add support for PECI bus driver core

> >Is there a real need to do transfers in atomic context, or with > >interrupts disabled? > > > > Actually, no. Generally, this function will be called in sleep-able context > so this code is for an exceptional case handling. > > I'll rewrite this code like below: > if (in_atomic() ||

Re: [PATCH v2 7/8] [PATCH 7/8] drivers/hwmon: Add a generic PECI hwmon client driver

On Wed, Feb 21, 2018 at 01:24:48PM -0800, Jae Hyun Yoo wrote: > Hi Guenter, > > Thanks for sharing your time to review this code. Please check my answers > inline. > > On 2/21/2018 10:26 AM, Guenter Roeck wrote: > >On Wed, Feb 21, 2018 at 08:16:05AM -0800, Jae Hyun Yoo wrote: > >>This commit

Re: [PATCH v2 7/8] [PATCH 7/8] drivers/hwmon: Add a generic PECI hwmon client driver

On Wed, Feb 21, 2018 at 01:24:48PM -0800, Jae Hyun Yoo wrote: > Hi Guenter, > > Thanks for sharing your time to review this code. Please check my answers > inline. > > On 2/21/2018 10:26 AM, Guenter Roeck wrote: > >On Wed, Feb 21, 2018 at 08:16:05AM -0800, Jae Hyun Yoo wrote: > >>This commit

[PATCH v4 0/2] leds: Add driver for NCP5623 3-channel I2C LED driver

Hello Jacek and Pavel, Winter came, then spring, summer and automn went away. Snow came again, and now here is the v4 of the NCP5623 patch... Never too late! This series add a new driver for On Semiconductor NCP5623, a 3-channel I2C LED driver. It is used in our design to drive a RGB LED. The

[PATCH v4 0/2] leds: Add driver for NCP5623 3-channel I2C LED driver

Hello Jacek and Pavel, Winter came, then spring, summer and automn went away. Snow came again, and now here is the v4 of the NCP5623 patch... Never too late! This series add a new driver for On Semiconductor NCP5623, a 3-channel I2C LED driver. It is used in our design to drive a RGB LED. The

[PATCH v4 1/2] leds: ncp5623: Add device tree binding documentation

Add device tree binding documentation for On Semiconductor NCP5623 I2C LED driver. The driver can independently control the PWM of the 3 channels with 32 levels of intensity. The current delivered by the current source can also be controlled. To do so, the led-max-microamp property is used by

[PATCH v4 1/2] leds: ncp5623: Add device tree binding documentation

Add device tree binding documentation for On Semiconductor NCP5623 I2C LED driver. The driver can independently control the PWM of the 3 channels with 32 levels of intensity. The current delivered by the current source can also be controlled. To do so, the led-max-microamp property is used by

[PATCH v4 2/2] leds: Add driver for NCP5623 3-channel I2C LED driver

The NCP5623 is a 3-channel LED driver from On Semiconductor controlled through I2C. The PWM of each channel can be independently set with 32 distinct levels. In addition, the intensity of the current source can be globally set using an external bias resistor fixing the reference current (Iref) and

[PATCH v4 2/2] leds: Add driver for NCP5623 3-channel I2C LED driver

The NCP5623 is a 3-channel LED driver from On Semiconductor controlled through I2C. The PWM of each channel can be independently set with 32 distinct levels. In addition, the intensity of the current source can be globally set using an external bias resistor fixing the reference current (Iref) and

[PATCH] powerpc/time: stop validating rtc_time in .read_time

The RTC core is always calling rtc_valid_tm after the read_time callback. It is not necessary to call it just before returning from the callback. Signed-off-by: Alexandre Belloni --- arch/powerpc/kernel/time.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH] powerpc/time: stop validating rtc_time in .read_time

The RTC core is always calling rtc_valid_tm after the read_time callback. It is not necessary to call it just before returning from the callback. Signed-off-by: Alexandre Belloni --- arch/powerpc/kernel/time.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH] tools/gpio/gpio-event-mon: fix warning

On 21 February 2018 at 15:33, Anders Roxell wrote: > PRIu64 is defined in user space to match libc's uint64_t definition. > However, gpioevent_data structure in the kernel is defined using the > kernel's own __u64 type. > > gpio-event-mon.c: In function ‘monitor_device’:

Re: [PATCH] tools/gpio/gpio-event-mon: fix warning

On 21 February 2018 at 15:33, Anders Roxell wrote: > PRIu64 is defined in user space to match libc's uint64_t definition. > However, gpioevent_data structure in the kernel is defined using the > kernel's own __u64 type. > > gpio-event-mon.c: In function ‘monitor_device’: >

[PATCH 2/3] KVM: nVMX: fix wrong condition for SPEC_CTRL and PRED_CMD MSRs

We need to change the default all-1s bitmap if the MSRs are _not_ intercepted. However, the code was disabling the intercept when it was _enabled_ in the VMCS01. This is not causing bigger trouble, because vmx_vcpu_run checks the VMCS02's MSR bitmap and would do the right thing even if fed

[PATCH 2/3] KVM: nVMX: fix wrong condition for SPEC_CTRL and PRED_CMD MSRs

We need to change the default all-1s bitmap if the MSRs are _not_ intercepted. However, the code was disabling the intercept when it was _enabled_ in the VMCS01. This is not causing bigger trouble, because vmx_vcpu_run checks the VMCS02's MSR bitmap and would do the right thing even if fed

[PATCH 1/3] KVM: x86: use native MSR ops for SPEC_CTRL

Having a paravirt indirect call in the IBRS restore path is not a good idea, since we are trying to protect from speculative execution of bogus indirect branch targets. It is also slower, so use native_wrmsrl on the vmentry path too. Fixes: d28b387fb74da95d69d2615732f50cceb38e9a4d Cc:

[PATCH 1/3] KVM: x86: use native MSR ops for SPEC_CTRL

Having a paravirt indirect call in the IBRS restore path is not a good idea, since we are trying to protect from speculative execution of bogus indirect branch targets. It is also slower, so use native_wrmsrl on the vmentry path too. Fixes: d28b387fb74da95d69d2615732f50cceb38e9a4d Cc:

[PATCH 3/3] KVM: VMX: mark RDMSR path as unlikely

vmx_vcpu_run and svm_vcpu_run are large functions, and this can actually make a substantial cycle difference by keeping the fast path contiguous in memory. Without it, the retpoline guest/retpoline host case is about 50 cycles slower. Cc: x...@kernel.org Cc: Radim Krčmář Cc:

[PATCH 3/3] KVM: VMX: mark RDMSR path as unlikely

vmx_vcpu_run and svm_vcpu_run are large functions, and this can actually make a substantial cycle difference by keeping the fast path contiguous in memory. Without it, the retpoline guest/retpoline host case is about 50 cycles slower. Cc: x...@kernel.org Cc: Radim Krčmář Cc: KarimAllah Ahmed

[PATCH 0/3] x86/pti: KVM: fixes and optimizations for IBRS

Three tiny patches fixing bugs and optimizing the IBRS code. These are all fairly obvious, but they escaped review. They should go in through the x86/pti tree and should apply to both 4.9 and 4.14 trees. Thanks! Paolo Paolo Bonzini (3): KVM: x86: use native MSR ops for SPEC_CTRL KVM:

[PATCH 0/3] x86/pti: KVM: fixes and optimizations for IBRS

Three tiny patches fixing bugs and optimizing the IBRS code. These are all fairly obvious, but they escaped review. They should go in through the x86/pti tree and should apply to both 4.9 and 4.14 trees. Thanks! Paolo Paolo Bonzini (3): KVM: x86: use native MSR ops for SPEC_CTRL KVM:

[PATCH] parisc: time: stop validating rtc_time in .read_time

The RTC core is always calling rtc_valid_tm after the read_time callback. It is not necessary to call it just before returning from the callback. Signed-off-by: Alexandre Belloni --- arch/parisc/kernel/time.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH] parisc: time: stop validating rtc_time in .read_time

The RTC core is always calling rtc_valid_tm after the read_time callback. It is not necessary to call it just before returning from the callback. Signed-off-by: Alexandre Belloni --- arch/parisc/kernel/time.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH 0/5] x86/dumpstack: Cleanups and user opcode bytes Code: section

On Wed, Feb 21, 2018 at 9:54 AM, Borislav Petkov wrote: > > Ok, lemme run it by Linus too as he probably stares at this part of the > output a *lot* :-) Less than I used to, since there are others who are pretty good at decoding them, but yes... > Anyway, here's a 64-bit splat.

Re: [PATCH 0/5] x86/dumpstack: Cleanups and user opcode bytes Code: section

On Wed, Feb 21, 2018 at 9:54 AM, Borislav Petkov wrote: > > Ok, lemme run it by Linus too as he probably stares at this part of the > output a *lot* :-) Less than I used to, since there are others who are pretty good at decoding them, but yes... > Anyway, here's a 64-bit splat. I'm basically

Re: [PATCH 00/23] kconfig: move compiler capability tests to Kconfig

On Wed, Feb 21, 2018 at 09:57:03PM +0900, Masahiro Yamada wrote: > 2018-02-21 19:52 GMT+09:00 Arnd Bergmann : > > On Wed, Feb 21, 2018 at 11:20 AM, Masahiro Yamada > > wrote: > >> 2018-02-21 18:56 GMT+09:00 Arnd Bergmann : > >>> On Wed,

Re: [PATCH 00/23] kconfig: move compiler capability tests to Kconfig

On Wed, Feb 21, 2018 at 09:57:03PM +0900, Masahiro Yamada wrote: > 2018-02-21 19:52 GMT+09:00 Arnd Bergmann : > > On Wed, Feb 21, 2018 at 11:20 AM, Masahiro Yamada > > wrote: > >> 2018-02-21 18:56 GMT+09:00 Arnd Bergmann : > >>> On Wed, Feb 21, 2018 at 8:38 AM, Masahiro Yamada > >>> wrote: >

Re: [PATCH] x86/asm: improve how GEN_*_SUFFIXED_RMWcc() specify clobbers

On Mon, Feb 19, 2018 at 6:49 AM, Jan Beulich wrote: > Commit df3405245a ("x86/asm: Add suffix macro for GEN_*_RMWcc()") > introduced "suffix" RMWcc operations, adding bogus clobber specifiers: > For one, on x86 there's no point explicitly clobbering "cc". In fact, Do you have

Re: [PATCH] x86/asm: improve how GEN_*_SUFFIXED_RMWcc() specify clobbers

On Mon, Feb 19, 2018 at 6:49 AM, Jan Beulich wrote: > Commit df3405245a ("x86/asm: Add suffix macro for GEN_*_RMWcc()") > introduced "suffix" RMWcc operations, adding bogus clobber specifiers: > For one, on x86 there's no point explicitly clobbering "cc". In fact, Do you have more details on

<    2   3   4   5   6   7   8   9   10   11   >