[PATCH] acpi: apei: clear error status before acknowledging the error

Currently we acknowledge errors before clearing the error status. This could cause a new error to be populated by firmware in-between the error acknowledgment and the error status clearing which would cause the second error's status to be cleared without being handled. So, clear the error status

[PATCH] acpi: apei: clear error status before acknowledging the error

Currently we acknowledge errors before clearing the error status. This could cause a new error to be populated by firmware in-between the error acknowledgment and the error status clearing which would cause the second error's status to be cleared without being handled. So, clear the error status

Re: [RFC v6 21/62] powerpc: introduce execute-only pkey

Ram Pai writes: > --- a/arch/powerpc/mm/pkeys.c > +++ b/arch/powerpc/mm/pkeys.c > @@ -97,3 +97,60 @@ int __arch_set_user_pkey_access(struct task_struct *tsk, > int pkey, > init_iamr(pkey, new_iamr_bits); > return 0; > } > + > +static inline bool

Re: [RFC v6 21/62] powerpc: introduce execute-only pkey

Ram Pai writes: > --- a/arch/powerpc/mm/pkeys.c > +++ b/arch/powerpc/mm/pkeys.c > @@ -97,3 +97,60 @@ int __arch_set_user_pkey_access(struct task_struct *tsk, > int pkey, > init_iamr(pkey, new_iamr_bits); > return 0; > } > + > +static inline bool pkey_allows_readwrite(int pkey) > +{

Re: [PATCH v4 09/12] ASoC: wm9712: add ac97 new bus support

Charles Keepax writes: > On Mon, Jul 24, 2017 at 10:49:25PM +0200, Robert Jarzmik wrote: >> Add support for the new ac97 bus model, where devices are automatically >> discovered on AC-Links. >> >> Signed-off-by: Robert Jarzmik >> --- >> +

Re: [PATCH v4 09/12] ASoC: wm9712: add ac97 new bus support

Charles Keepax writes: > On Mon, Jul 24, 2017 at 10:49:25PM +0200, Robert Jarzmik wrote: >> Add support for the new ac97 bus model, where devices are automatically >> discovered on AC-Links. >> >> Signed-off-by: Robert Jarzmik >> --- >> +} else { >> +wm9712->ac97 =

[PATCH 4/5] mtd: spi-nor: Add driver for Adaptrum Anarion QSPI controller

Add support for the QSPI controller found in Adaptrum Anarion SOCs. This controller is designed specifically to handle SPI NOR chips, and the driver is modeled as such. Because the system is emulated on an FPGA, we don't have a way to test all the hardware adjustemts, so only basic features are

[PATCH 4/5] mtd: spi-nor: Add driver for Adaptrum Anarion QSPI controller

Add support for the QSPI controller found in Adaptrum Anarion SOCs. This controller is designed specifically to handle SPI NOR chips, and the driver is modeled as such. Because the system is emulated on an FPGA, we don't have a way to test all the hardware adjustemts, so only basic features are

[PATCH 3/5] net: stmmac: Add Adaptrum Anarion GMAC glue layer

Before the GMAC on the Anarion chip can be used, the PHY interface selection must be configured with the DWMAC block in reset. This layer covers a block containing only two registers. Although it is possible to model this as a reset controller and use the "resets" property of stmmac, it's much

[PATCH 3/5] net: stmmac: Add Adaptrum Anarion GMAC glue layer

Before the GMAC on the Anarion chip can be used, the PHY interface selection must be configured with the DWMAC block in reset. This layer covers a block containing only two registers. Although it is possible to model this as a reset controller and use the "resets" property of stmmac, it's much

[PATCH 5/5] ARC: DTS: Add device-tree for Anarion-based development board

Signed-off-by: Alexandru Gagniuc --- arch/arc/boot/dts/adaptrum_anarion.dtsi | 107 arch/arc/boot/dts/adaptrum_anarion_fpga.dts | 49 + 2 files changed, 156 insertions(+) create mode 100644

[PATCH 0/5] Initial support for Adaptrum Anarion SOC

We've reached the point where we can boot a basic linux system on the new SOC, and I'm very excited to share the code I've developed in the process. This series includes a new driver for the QSPI controller on the chip, although the flash layout is not specified in the devicetree. The flash

[PATCH 5/5] ARC: DTS: Add device-tree for Anarion-based development board

Signed-off-by: Alexandru Gagniuc --- arch/arc/boot/dts/adaptrum_anarion.dtsi | 107 arch/arc/boot/dts/adaptrum_anarion_fpga.dts | 49 + 2 files changed, 156 insertions(+) create mode 100644 arch/arc/boot/dts/adaptrum_anarion.dtsi create mode 100644

[PATCH 0/5] Initial support for Adaptrum Anarion SOC

We've reached the point where we can boot a basic linux system on the new SOC, and I'm very excited to share the code I've developed in the process. This series includes a new driver for the QSPI controller on the chip, although the flash layout is not specified in the devicetree. The flash

[PATCH 1/5] of: Add vendor prefix for Adaptrum, Inc.

Signed-off-by: Alexandru Gagniuc --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index

[PATCH 2/5] ARC: [plat-anarion] Add early boot workarounds for Anarion SOC

An ARC, the interrupts are enabled globally, rather than per-line, as drivers request it. Thus, we need to make sure that peripherals don't generate any before the respective drivers are probed. The GMAC is infamous for spamming interrupts, so it must be kept in reset until the driver is probed

[PATCH 1/5] of: Add vendor prefix for Adaptrum, Inc.

Signed-off-by: Alexandru Gagniuc --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index daf465be..33ee112 100644 ---

[PATCH 2/5] ARC: [plat-anarion] Add early boot workarounds for Anarion SOC

An ARC, the interrupts are enabled globally, rather than per-line, as drivers request it. Thus, we need to make sure that peripherals don't generate any before the respective drivers are probed. The GMAC is infamous for spamming interrupts, so it must be kept in reset until the driver is probed

Re: [PATCH 3.10] pstore: Make spinlock per zone instead of global

On Fri, Jul 28, 2017 at 02:52:15PM +0800, Leo Yan wrote: > On Fri, Jul 28, 2017 at 06:25:55AM +0200, Willy Tarreau wrote: > > Hi Leo, > > > > There was no upstream commit ID here but I found it in mainline here : > > > > commit 109704492ef637956265ec2eb72ae7b3b39eb6f4 > > Author: Joel

Re: [PATCH 3.10] pstore: Make spinlock per zone instead of global

On Fri, Jul 28, 2017 at 02:52:15PM +0800, Leo Yan wrote: > On Fri, Jul 28, 2017 at 06:25:55AM +0200, Willy Tarreau wrote: > > Hi Leo, > > > > There was no upstream commit ID here but I found it in mainline here : > > > > commit 109704492ef637956265ec2eb72ae7b3b39eb6f4 > > Author: Joel

Re: [RFC PATCH v2 00/38] Nested Virtualization on KVM/ARM

On Fri, Jul 28, 2017 at 4:13 PM, Bandan Das wrote: > Jintack Lim writes: > ... >>> >>> I'll share my experiment setup shortly. >> >> I summarized my experiment setup here. >> >>

Re: [RFC PATCH v2 00/38] Nested Virtualization on KVM/ARM

On Fri, Jul 28, 2017 at 4:13 PM, Bandan Das wrote: > Jintack Lim writes: > ... >>> >>> I'll share my experiment setup shortly. >> >> I summarized my experiment setup here. >> >> https://github.com/columbia/nesting-pub/wiki/Nested-virtualization-on-ARM-setup > > Thanks Jintack! I was able to test

Re: [PATCH] selftests: capabilities: convert error output to TAP13 ksft framework

On 07/28/2017 09:41 AM, Shuah Khan wrote: > On 07/27/2017 08:13 PM, Andy Lutomirski wrote: >> On Thu, Jul 27, 2017 at 1:32 PM, Shuah Khan wrote: >>> On 07/27/2017 12:50 PM, Andy Lutomirski wrote: On Wed, Jul 26, 2017 at 2:18 PM, Shuah Khan

Re: [PATCH] selftests: capabilities: convert error output to TAP13 ksft framework

On 07/28/2017 09:41 AM, Shuah Khan wrote: > On 07/27/2017 08:13 PM, Andy Lutomirski wrote: >> On Thu, Jul 27, 2017 at 1:32 PM, Shuah Khan wrote: >>> On 07/27/2017 12:50 PM, Andy Lutomirski wrote: On Wed, Jul 26, 2017 at 2:18 PM, Shuah Khan wrote: > Convert errx() and err() usage

[PATCH v2] mm: memcontrol: Use int for event/state parameter in several functions

Several functions use an enum type as parameter for an event/state, but are called in some locations with an argument of a different enum type. Adjust the interface of these functions to reality by changing the parameter to int. This fixes a ton of enum-conversion warnings that are generated when

[PATCH v2] mm: memcontrol: Use int for event/state parameter in several functions

Several functions use an enum type as parameter for an event/state, but are called in some locations with an argument of a different enum type. Adjust the interface of these functions to reality by changing the parameter to int. This fixes a ton of enum-conversion warnings that are generated when

Re: [PATCH net-next 4/4] net: dsa: lan9303: MDIO access phy registers directly

> >Since the kernel module license is GPL, EXPORT_SYMBOL_GPL() would seem > >to be appropriate, which can be done as a subsequent patch. > > > >Reviewed-by: Florian Fainelli > > > I have no idea how these legalities work. But for the record, > I give consent to change to

Re: [PATCH net-next 4/4] net: dsa: lan9303: MDIO access phy registers directly

> >Since the kernel module license is GPL, EXPORT_SYMBOL_GPL() would seem > >to be appropriate, which can be done as a subsequent patch. > > > >Reviewed-by: Florian Fainelli > > > I have no idea how these legalities work. But for the record, > I give consent to change to EXPORT_SYMBOL_GPL at any

Re: [PATCH V2 3/4] net-next: dsa: fix flow dissection

> thanks for the feedback. should I add 2 callbacks for each of the 2 > parameters ? Hi John A single callback is better. We don't want to have to peek into the packet twice to determine two values. Andrew

Re: [PATCH V2 3/4] net-next: dsa: fix flow dissection

> thanks for the feedback. should I add 2 callbacks for each of the 2 > parameters ? Hi John A single callback is better. We don't want to have to peek into the packet twice to determine two values. Andrew

Re: [RESEND PATCH 2/6] ipc: mqueue: Replace timespec with timespec64

>> - memcpy(p, abs_timeout, sizeof(struct timespec)); >> + memcpy(p, abs_timeout, sizeof(struct timespec64)); > > Since you're changing this line, how about changing it to the following: > > memcpy(p, abs_timeout, sizeof(*p)); > >> else >> -

Re: [RESEND PATCH 2/6] ipc: mqueue: Replace timespec with timespec64

>> - memcpy(p, abs_timeout, sizeof(struct timespec)); >> + memcpy(p, abs_timeout, sizeof(struct timespec64)); > > Since you're changing this line, how about changing it to the following: > > memcpy(p, abs_timeout, sizeof(*p)); > >> else >> -

Re: [PATCH 0/3] remove rw_page() from brd, pmem and btt

On Fri, 28 Jul 2017 10:31:43 -0700 Matthew Wilcox wrote: > On Fri, Jul 28, 2017 at 10:56:01AM -0600, Ross Zwisler wrote: > > Dan Williams and Christoph Hellwig have recently expressed doubt about > > whether the rw_page() interface made sense for synchronous memory drivers >

Re: [PATCH 0/3] remove rw_page() from brd, pmem and btt

On Fri, 28 Jul 2017 10:31:43 -0700 Matthew Wilcox wrote: > On Fri, Jul 28, 2017 at 10:56:01AM -0600, Ross Zwisler wrote: > > Dan Williams and Christoph Hellwig have recently expressed doubt about > > whether the rw_page() interface made sense for synchronous memory drivers > > [1][2]. It's

[PATCH 02/11] usb: host: max3421-hcd: constify hc_driver structures

The hc_driver structure is only passed as the first argument to usb_create_hcd, which is declared as const. Thus the hc_driver structure itself can be const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/usb/host/max3421-hcd.c |2 +- 1

[PATCH 02/11] usb: host: max3421-hcd: constify hc_driver structures

The hc_driver structure is only passed as the first argument to usb_create_hcd, which is declared as const. Thus the hc_driver structure itself can be const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/usb/host/max3421-hcd.c |2 +- 1 file changed, 1

[PATCH 04/11] usb: host/sl811-hcd: constify hc_driver structures

The hc_driver structure is only passed as the first argument to usb_create_hcd, which is declared as const. Thus the hc_driver structure itself can be const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/usb/host/sl811-hcd.c |2 +- 1 file

[PATCH 04/11] usb: host/sl811-hcd: constify hc_driver structures

The hc_driver structure is only passed as the first argument to usb_create_hcd, which is declared as const. Thus the hc_driver structure itself can be const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/usb/host/sl811-hcd.c |2 +- 1 file changed, 1

[PATCH 03/11] usb: r8a66597-hcd: constify hc_driver structures

The hc_driver structure is only passed as the first argument to usb_create_hcd, which is declared as const. Thus the hc_driver structure itself can be const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/usb/host/r8a66597-hcd.c |2 +- 1

[PATCH 03/11] usb: r8a66597-hcd: constify hc_driver structures

The hc_driver structure is only passed as the first argument to usb_create_hcd, which is declared as const. Thus the hc_driver structure itself can be const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/usb/host/r8a66597-hcd.c |2 +- 1 file changed, 1

[PATCH 01/11] isp1362-hcd: constify hc_driver structures

The hc_driver structure is only passed as the first argument to usb_create_hcd, which is declared as const. Thus the hc_driver structure itself can be const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/usb/host/isp1362-hcd.c |2 +- 1

[PATCH 01/11] isp1362-hcd: constify hc_driver structures

The hc_driver structure is only passed as the first argument to usb_create_hcd, which is declared as const. Thus the hc_driver structure itself can be const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/usb/host/isp1362-hcd.c |2 +- 1 file changed, 1

[PATCH 05/11] usb: host: u132-hcd: constify hc_driver structures

The hc_driver structure is only passed as the first argument to usb_create_hcd, which is declared as const. Thus the hc_driver structure itself can be const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/usb/host/u132-hcd.c |2 +- 1 file

[PATCH 05/11] usb: host: u132-hcd: constify hc_driver structures

The hc_driver structure is only passed as the first argument to usb_create_hcd, which is declared as const. Thus the hc_driver structure itself can be const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/usb/host/u132-hcd.c |2 +- 1 file changed, 1

[PATCH 07/11] isp116x-hcd: constify hc_driver structures

The hc_driver structure is only passed as the first argument to usb_create_hcd, which is declared as const. Thus the hc_driver structure itself can be const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/usb/host/isp116x-hcd.c |2 +- 1

[PATCH 07/11] isp116x-hcd: constify hc_driver structures

The hc_driver structure is only passed as the first argument to usb_create_hcd, which is declared as const. Thus the hc_driver structure itself can be const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/usb/host/isp116x-hcd.c |2 +- 1 file changed, 1

[PATCH 06/11] usb: renesas_usbhs: constify hc_driver structures

The hc_driver structure is only passed as the first argument to usb_create_hcd, which is declared as const. Thus the hc_driver structure itself can be const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/usb/renesas_usbhs/mod_host.c |2 +-

[PATCH 06/11] usb: renesas_usbhs: constify hc_driver structures

The hc_driver structure is only passed as the first argument to usb_create_hcd, which is declared as const. Thus the hc_driver structure itself can be const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/usb/renesas_usbhs/mod_host.c |2 +- 1 file changed, 1

[PATCH 11/11] c67x00-hcd: constify hc_driver structures

The hc_driver structure is only passed as the first argument to usb_create_hcd, which is declared as const. Thus the hc_driver structure itself can be const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/usb/c67x00/c67x00-hcd.c |2 +- 1

[PATCH 11/11] c67x00-hcd: constify hc_driver structures

The hc_driver structure is only passed as the first argument to usb_create_hcd, which is declared as const. Thus the hc_driver structure itself can be const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/usb/c67x00/c67x00-hcd.c |2 +- 1 file changed, 1

[PATCH 08/11] USB: HWA: constify hc_driver structures

The hc_driver structure is only passed as the first argument to usb_create_hcd, which is declared as const. Thus the hc_driver structure itself can be const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/usb/host/hwa-hc.c |2 +- 1 file

[PATCH 08/11] USB: HWA: constify hc_driver structures

The hc_driver structure is only passed as the first argument to usb_create_hcd, which is declared as const. Thus the hc_driver structure itself can be const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/usb/host/hwa-hc.c |2 +- 1 file changed, 1 insertion(+),

[PATCH 09/11] USB: whci-hcd: constify hc_driver structures

The hc_driver structure is only passed as the first argument to usb_create_hcd, which is declared as const. Thus the hc_driver structure itself can be const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/usb/host/whci/hcd.c |2 +- 1 file

[PATCH 09/11] USB: whci-hcd: constify hc_driver structures

The hc_driver structure is only passed as the first argument to usb_create_hcd, which is declared as const. Thus the hc_driver structure itself can be const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/usb/host/whci/hcd.c |2 +- 1 file changed, 1

[PATCH 10/11] greybus: usb: constify hc_driver structures

The hc_driver structure is only passed as the first argument to usb_create_hcd, which is declared as const. Thus the hc_driver structure itself can be const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/staging/greybus/usb.c |2 +- 1

[PATCH 10/11] greybus: usb: constify hc_driver structures

The hc_driver structure is only passed as the first argument to usb_create_hcd, which is declared as const. Thus the hc_driver structure itself can be const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/staging/greybus/usb.c |2 +- 1 file changed, 1

[PATCH 00/11] constify hc_driver structures

The hc_driver structure is only passed as the first argument to usb_create_hcd, which is declared as const. Thus the hc_driver structure itself can be const. Done with the help of Coccinelle. // @r disable optional_qualifier@ identifier i; position p; @@ static struct hc_driver i@p = { ... };

[PATCH 00/11] constify hc_driver structures

The hc_driver structure is only passed as the first argument to usb_create_hcd, which is declared as const. Thus the hc_driver structure itself can be const. Done with the help of Coccinelle. // @r disable optional_qualifier@ identifier i; position p; @@ static struct hc_driver i@p = { ... };

[PATCH v3/resubmit 1/3] staging: gs_fpgaboot: add buffer overflow checks

Four fields in struct fpgaimage are char arrays of length MAX_STR (256). The amount of data read into these buffers is controlled by a length field in the bitstream file read from userspace. If a corrupt or malicious firmware file was supplied, kernel data beyond these buffers can be overwritten

[PATCH v3/resubmit 1/3] staging: gs_fpgaboot: add buffer overflow checks

Four fields in struct fpgaimage are char arrays of length MAX_STR (256). The amount of data read into these buffers is controlled by a length field in the bitstream file read from userspace. If a corrupt or malicious firmware file was supplied, kernel data beyond these buffers can be overwritten

[PATCH v3/resubmit 2/3] staging: gs_fpgaboot: change char to u8

The bitstream storage variables were changed from char to u8 arrays to prevent issues such as negative lengths. This change makes the code compatible with the "data" field in "struct firmware" which is of type u8. Signed-off-by: Jacob von Chorus --- v3: - reduce

[PATCH v3/resubmit 2/3] staging: gs_fpgaboot: change char to u8

The bitstream storage variables were changed from char to u8 arrays to prevent issues such as negative lengths. This change makes the code compatible with the "data" field in "struct firmware" which is of type u8. Signed-off-by: Jacob von Chorus --- v3: - reduce temporary buffer size in

Re: [RESEND PATCH 2/6] ipc: mqueue: Replace timespec with timespec64

On Fri, Jul 28, 2017 at 2:52 PM, Deepa Dinamani wrote: > struct timespec is not y2038 safe. Replace > all uses of timespec by y2038 safe struct timespec64. > > Even though timespec is used here to represent timeouts, > replace these with timespec64 so that it facilitates >

Re: [RESEND PATCH 2/6] ipc: mqueue: Replace timespec with timespec64

On Fri, Jul 28, 2017 at 2:52 PM, Deepa Dinamani wrote: > struct timespec is not y2038 safe. Replace > all uses of timespec by y2038 safe struct timespec64. > > Even though timespec is used here to represent timeouts, > replace these with timespec64 so that it facilitates > in verification by

[PATCH v3/resubmit 3/3] staging: gs_fpgaboot: return valid error codes

The return values on error are modified to be valid error codes. Theses error codes are propagated back to the init function's return. Signed-off-by: Jacob von Chorus --- drivers/staging/gs_fpgaboot/gs_fpgaboot.c | 14 +++--- 1 file changed, 7 insertions(+), 7

[PATCH v3/resubmit 3/3] staging: gs_fpgaboot: return valid error codes

The return values on error are modified to be valid error codes. Theses error codes are propagated back to the init function's return. Signed-off-by: Jacob von Chorus --- drivers/staging/gs_fpgaboot/gs_fpgaboot.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git

Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

On 07/27/2017 11:00 PM, Viresh Kumar wrote: On 27-07-17, 12:55, Saravana Kannan wrote: Yes. Simplifying isn't always about number of lines of code. It's also about abstraction. Having generic scheduler code care about HW details doesn't seem nice. I can argue that even the policy->cpus field

Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

On 07/27/2017 11:00 PM, Viresh Kumar wrote: On 27-07-17, 12:55, Saravana Kannan wrote: Yes. Simplifying isn't always about number of lines of code. It's also about abstraction. Having generic scheduler code care about HW details doesn't seem nice. I can argue that even the policy->cpus field

Re: [RESEND PATCH 2/6] ipc: mqueue: Replace timespec with timespec64

On Fri, Jul 28, 2017 at 4:44 PM, Deepa Dinamani wrote: > On Fri, Jul 28, 2017 at 1:15 PM, Paul Moore wrote: >> On Fri, Jul 28, 2017 at 2:52 PM, Deepa Dinamani >> wrote: >>> struct timespec is not y2038 safe. Replace >>> all

Re: [RESEND PATCH 2/6] ipc: mqueue: Replace timespec with timespec64

On Fri, Jul 28, 2017 at 4:44 PM, Deepa Dinamani wrote: > On Fri, Jul 28, 2017 at 1:15 PM, Paul Moore wrote: >> On Fri, Jul 28, 2017 at 2:52 PM, Deepa Dinamani >> wrote: >>> struct timespec is not y2038 safe. Replace >>> all uses of timespec by y2038 safe struct timespec64. >>> >>> Even though

Re: [RFC v6 27/62] powerpc: helper to validate key-access permissions of a pte

Ram Pai writes: > --- a/arch/powerpc/mm/pkeys.c > +++ b/arch/powerpc/mm/pkeys.c > @@ -201,3 +201,36 @@ int __arch_override_mprotect_pkey(struct vm_area_struct > *vma, int prot, >*/ > return vma_pkey(vma); > } > + > +static bool pkey_access_permitted(int pkey,

Re: [RFC v6 27/62] powerpc: helper to validate key-access permissions of a pte

Ram Pai writes: > --- a/arch/powerpc/mm/pkeys.c > +++ b/arch/powerpc/mm/pkeys.c > @@ -201,3 +201,36 @@ int __arch_override_mprotect_pkey(struct vm_area_struct > *vma, int prot, >*/ > return vma_pkey(vma); > } > + > +static bool pkey_access_permitted(int pkey, bool write, bool

Re: [PATCH v2 1/1] i2c: aspeed: add proper support fo 24xx clock params

Is clk_fractional_divider from include/linux/clk-provider.h appropriate here? On Fri, Jul 28, 2017 at 1:57 PM, Rick Altherr wrote: > Is clk_fractional_divider from include/linux/clk-provider.h appropriate > here? > > On Fri, Jul 28, 2017 at 1:45 PM, Brendan Higgins

Re: [PATCH v2 1/1] i2c: aspeed: add proper support fo 24xx clock params

Is clk_fractional_divider from include/linux/clk-provider.h appropriate here? On Fri, Jul 28, 2017 at 1:57 PM, Rick Altherr wrote: > Is clk_fractional_divider from include/linux/clk-provider.h appropriate > here? > > On Fri, Jul 28, 2017 at 1:45 PM, Brendan Higgins > wrote: >> >> 24xx BMCs have

Re: [PATCH v4] membarrier: expedited private command

On Fri, Jul 28, 2017 at 04:40:40PM -0400, Mathieu Desnoyers wrote: > Implement MEMBARRIER_CMD_PRIVATE_EXPEDITED with IPIs using cpumask built > from all runqueues for which current thread's mm is the same as the > thread calling sys_membarrier. It executes faster than the non-expedited > variant

Re: [PATCH v4] membarrier: expedited private command

On Fri, Jul 28, 2017 at 04:40:40PM -0400, Mathieu Desnoyers wrote: > Implement MEMBARRIER_CMD_PRIVATE_EXPEDITED with IPIs using cpumask built > from all runqueues for which current thread's mm is the same as the > thread calling sys_membarrier. It executes faster than the non-expedited > variant

[PATCH v5 2/6] seccomp: Sysctl to configure actions that are allowed to be logged

Adminstrators can write to this sysctl to set the seccomp actions that are allowed to be logged. Any actions not found in this sysctl will not be logged. For example, all SECCOMP_RET_KILL, SECCOMP_RET_TRAP, and SECCOMP_RET_ERRNO actions would be loggable if "kill trap errno" were written to the

[PATCH v5 2/6] seccomp: Sysctl to configure actions that are allowed to be logged

Adminstrators can write to this sysctl to set the seccomp actions that are allowed to be logged. Any actions not found in this sysctl will not be logged. For example, all SECCOMP_RET_KILL, SECCOMP_RET_TRAP, and SECCOMP_RET_ERRNO actions would be loggable if "kill trap errno" were written to the

[PATCH v5 6/6] seccomp: Selftest for detection of filter flag support

Userspace needs to be able to reliably detect the support of a filter flag. A good way of doing that is by attempting to enter filter mode, with the flag bit(s) in question set, and a NULL pointer for the args parameter of seccomp(2). EFAULT indicates that the flag is valid and EINVAL indicates

[PATCH v5 6/6] seccomp: Selftest for detection of filter flag support

Userspace needs to be able to reliably detect the support of a filter flag. A good way of doing that is by attempting to enter filter mode, with the flag bit(s) in question set, and a NULL pointer for the args parameter of seccomp(2). EFAULT indicates that the flag is valid and EINVAL indicates

[PATCH v5 4/6] seccomp: Operation for checking if an action is available

Userspace code that needs to check if the kernel supports a given action may not be able to use the /proc/sys/kernel/seccomp/actions_avail sysctl. The process may be running in a sandbox and, therefore, sufficient filesystem access may not be available. This patch adds an operation to the

[PATCH v5 4/6] seccomp: Operation for checking if an action is available

Userspace code that needs to check if the kernel supports a given action may not be able to use the /proc/sys/kernel/seccomp/actions_avail sysctl. The process may be running in a sandbox and, therefore, sufficient filesystem access may not be available. This patch adds an operation to the

[PATCH v5 5/6] seccomp: Action to log before allowing

Add a new action, SECCOMP_RET_LOG, that logs a syscall before allowing the syscall. At the implementation level, this action is identical to the existing SECCOMP_RET_ALLOW action. However, it can be very useful when initially developing a seccomp filter for an application. The developer can set

[PATCH v5 5/6] seccomp: Action to log before allowing

Add a new action, SECCOMP_RET_LOG, that logs a syscall before allowing the syscall. At the implementation level, this action is identical to the existing SECCOMP_RET_ALLOW action. However, it can be very useful when initially developing a seccomp filter for an application. The developer can set

[PATCH v5 3/6] seccomp: Filter flag to log all actions except SECCOMP_RET_ALLOW

Add a new filter flag, SECCOMP_FILTER_FLAG_LOG, that enables logging for all actions except for SECCOMP_RET_ALLOW for the given filter. SECCOMP_RET_KILL actions are always logged, when "kill" is in the actions_logged sysctl, and SECCOMP_RET_ALLOW actions are never logged, regardless of this flag.

[PATCH v5 0/6] Improved seccomp logging

This is an update to the previous seccomp logging patch sets. The main difference in this revision compared to the last is that the application now has the ability to request that all actions in a filter, except for RET_ALLOW, should be logged. This is done with a new filter flag. In support of

[PATCH v5 1/6] seccomp: Sysctl to display available actions

This patch creates a read-only sysctl containing an ordered list of seccomp actions that the kernel supports. The ordering, from left to right, is the lowest action value (kill) to the highest action value (allow). Currently, a read of the sysctl file would return "kill trap errno trace allow".

[PATCH v5 3/6] seccomp: Filter flag to log all actions except SECCOMP_RET_ALLOW

Add a new filter flag, SECCOMP_FILTER_FLAG_LOG, that enables logging for all actions except for SECCOMP_RET_ALLOW for the given filter. SECCOMP_RET_KILL actions are always logged, when "kill" is in the actions_logged sysctl, and SECCOMP_RET_ALLOW actions are never logged, regardless of this flag.

[PATCH v5 0/6] Improved seccomp logging

This is an update to the previous seccomp logging patch sets. The main difference in this revision compared to the last is that the application now has the ability to request that all actions in a filter, except for RET_ALLOW, should be logged. This is done with a new filter flag. In support of

[PATCH v5 1/6] seccomp: Sysctl to display available actions

This patch creates a read-only sysctl containing an ordered list of seccomp actions that the kernel supports. The ordering, from left to right, is the lowest action value (kill) to the highest action value (allow). Currently, a read of the sysctl file would return "kill trap errno trace allow".

[PATCH 0/2] iommu/omap: Rework cache functionality with DMA Streaming API

Hi Joerg, This series adapts the OMAP IOMMU driver to use the DMA API to flush the page table/directory table entries from the CPU caches instead of the ARM assembly calls. The patches are baselined on 4.13-rc1. Following is the patch summary: 1. Patch 1 disables the OMAP IOMMU fault interrupts

[PATCH 0/2] iommu/omap: Rework cache functionality with DMA Streaming API

Hi Joerg, This series adapts the OMAP IOMMU driver to use the DMA API to flush the page table/directory table entries from the CPU caches instead of the ARM assembly calls. The patches are baselined on 4.13-rc1. Following is the patch summary: 1. Patch 1 disables the OMAP IOMMU fault interrupts

[PATCH 2/2] iommu/omap: Use DMA-API for performing cache flushes

The OMAP IOMMU driver was using ARM assembly code directly for flushing the MMU page table entries from the caches. This caused MMU faults on OMAP4 (Cortex-A9 based SoCs) as L2 caches were not handled due to the presence of a PL310 L2 Cache Controller. These faults were however not seen on

[PATCH 2/2] iommu/omap: Use DMA-API for performing cache flushes

The OMAP IOMMU driver was using ARM assembly code directly for flushing the MMU page table entries from the caches. This caused MMU faults on OMAP4 (Cortex-A9 based SoCs) as L2 caches were not handled due to the presence of a PL310 L2 Cache Controller. These faults were however not seen on

[PATCH 1/2] iommu/omap: Fix disabling of MMU upon a fault

From: Fernando Guzman Lugo The IOMMU framework lets its client users be notified on a MMU fault and allows them to either handle the interrupt by dynamic reloading of an appropriate TLB/PTE for the offending fault address or to completely restart/recovery the device and its

[PATCH 1/2] iommu/omap: Fix disabling of MMU upon a fault

From: Fernando Guzman Lugo The IOMMU framework lets its client users be notified on a MMU fault and allows them to either handle the interrupt by dynamic reloading of an appropriate TLB/PTE for the offending fault address or to completely restart/recovery the device and its IOMMU. The OMAP

Re: gigantic hugepages vs. movable zones

On 07/26/2017 03:50 AM, Michal Hocko wrote: > Hi, > I've just noticed that alloc_gigantic_page ignores movability of the > gigantic page and it uses any existing zone. Considering that > hugepage_migration_supported only supports 2MB and pgd level hugepages > then 1GB pages are not migratable and

Re: gigantic hugepages vs. movable zones

On 07/26/2017 03:50 AM, Michal Hocko wrote: > Hi, > I've just noticed that alloc_gigantic_page ignores movability of the > gigantic page and it uses any existing zone. Considering that > hugepage_migration_supported only supports 2MB and pgd level hugepages > then 1GB pages are not migratable and

Re: [PATCH v2 4/4] clk: meson: gxbb-aoclk: Add CEC 32k clock

Hi Neil, On Fri, Jul 28, 2017 at 4:09 PM, Neil Armstrong wrote: > On 07/28/2017 12:29 PM, Martin Blumenstingl wrote: >> Hi Neil, >> >> thanks for these patches, CEC support is another good step! > > Hi Martin, > > Thanks for your feedback ! > >> >> On Fri, Jul 28, 2017

Re: [PATCH v2 4/4] clk: meson: gxbb-aoclk: Add CEC 32k clock

Hi Neil, On Fri, Jul 28, 2017 at 4:09 PM, Neil Armstrong wrote: > On 07/28/2017 12:29 PM, Martin Blumenstingl wrote: >> Hi Neil, >> >> thanks for these patches, CEC support is another good step! > > Hi Martin, > > Thanks for your feedback ! > >> >> On Fri, Jul 28, 2017 at 11:53 AM, Neil

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