Re: [PATCH v5 1/6] pinctrl: qcom: Add ipq8074 pinctrl driver

On Thu, Jun 08, 2017 at 11:13:56AM +0530, Varadarajan Narayanan wrote: > Add initial pinctrl driver to support pin configuration with > pinctrl framework for ipq8074. > > Signed-off-by: Manoharan Vijaya Raghavan > Signed-off-by: Varadarajan Narayanan

Re: [PATCH v5 1/6] pinctrl: qcom: Add ipq8074 pinctrl driver

On Thu, Jun 08, 2017 at 11:13:56AM +0530, Varadarajan Narayanan wrote: > Add initial pinctrl driver to support pin configuration with > pinctrl framework for ipq8074. > > Signed-off-by: Manoharan Vijaya Raghavan > Signed-off-by: Varadarajan Narayanan > --- >

Re: [PATCH v2 0/1] Add Trusted Path Execution as a stackable LSM

> So actually in this LSM it's not so much full paths that are trusted, > rather it checks that the directory containing the program is only > writable by root and that the program itself is only writable by root. > > For example, consider the following: > > /user/ with permissions drwxr-xr-x

[PATCH] kernel/kprobes: Add test to validate pt_regs

Add a test to verify that the registers passed in pt_regs on kprobe (trap), optprobe (jump) and kprobe_on_ftrace (ftrace_caller) are accurate. The tests are exercized if KPROBES_SANITY_TEST is enabled. Implemented for powerpc64. Other architectures will have to implement the relevant arch_*

Re: [PATCH v2 0/1] Add Trusted Path Execution as a stackable LSM

> So actually in this LSM it's not so much full paths that are trusted, > rather it checks that the directory containing the program is only > writable by root and that the program itself is only writable by root. > > For example, consider the following: > > /user/ with permissions drwxr-xr-x

[PATCH] kernel/kprobes: Add test to validate pt_regs

Add a test to verify that the registers passed in pt_regs on kprobe (trap), optprobe (jump) and kprobe_on_ftrace (ftrace_caller) are accurate. The tests are exercized if KPROBES_SANITY_TEST is enabled. Implemented for powerpc64. Other architectures will have to implement the relevant arch_*

Re: [PATCH v3 13/17] ASoC: madera: Add DT bindings for Cirrus Logic Madera codecs

On Fri, Jun 02, 2017 at 04:03:06PM +0100, Richard Fitzgerald wrote: > The Cirrus Logic Madera codecs are a family of related codecs with > extensive digital and analogue I/O, digital mixing and routing, > signal processing and programmable DSPs. > > Signed-off-by: Richard Fitzgerald

Re: [PATCH v3 13/17] ASoC: madera: Add DT bindings for Cirrus Logic Madera codecs

On Fri, Jun 02, 2017 at 04:03:06PM +0100, Richard Fitzgerald wrote: > The Cirrus Logic Madera codecs are a family of related codecs with > extensive digital and analogue I/O, digital mixing and routing, > signal processing and programmable DSPs. > > Signed-off-by: Richard Fitzgerald > --- >

Re: [PATCH v2] um: add dummy ioremap and iounmap functions

Am 08.06.2017 um 20:53 schrieb Logan Gunthorpe: > Any thoughts on this? My patches for the other architectures are already > in linux-next. um is the only one that remains. IMHO an ifdef in scatterlist code does not hurt. It is equally ugly than mocking ioremap for UML. So, I'm puzzled. Arnd,

Re: [PATCH v2] um: add dummy ioremap and iounmap functions

Am 08.06.2017 um 20:53 schrieb Logan Gunthorpe: > Any thoughts on this? My patches for the other architectures are already > in linux-next. um is the only one that remains. IMHO an ifdef in scatterlist code does not hurt. It is equally ugly than mocking ioremap for UML. So, I'm puzzled. Arnd,

Re: [PATCH 3/3] power: supply: Add support MAX1721x battery monitor

Hi Alex, On Thu, Jun 08, 2017 at 08:44:35PM +0300, Alex A. Mihaylov wrote: > 08.06.17 15:48, Sebastian Reichel wrote: > > On Fri, Jun 02, 2017 at 10:06:29AM +0300, Alex A. Mihaylov wrote: > > > diff --git a/drivers/power/supply/max1721x_battery.c > > > b/drivers/power/supply/max1721x_battery.c >

Re: [PATCH 3/3] power: supply: Add support MAX1721x battery monitor

Hi Alex, On Thu, Jun 08, 2017 at 08:44:35PM +0300, Alex A. Mihaylov wrote: > 08.06.17 15:48, Sebastian Reichel wrote: > > On Fri, Jun 02, 2017 at 10:06:29AM +0300, Alex A. Mihaylov wrote: > > > diff --git a/drivers/power/supply/max1721x_battery.c > > > b/drivers/power/supply/max1721x_battery.c >

Re: [PATCH v3 10/17] pinctrl: madera: Add DT bindings for Cirrus Logic Madera codecs

On Fri, Jun 02, 2017 at 04:03:03PM +0100, Richard Fitzgerald wrote: > This is the binding description of the pinctrl driver for Cirru Logic > Madera codecs. The binding uses the generic pinctrl binding so the main > purpose here is to describe the device-specific names for groups and > functions.

Re: [PATCH v3 10/17] pinctrl: madera: Add DT bindings for Cirrus Logic Madera codecs

On Fri, Jun 02, 2017 at 04:03:03PM +0100, Richard Fitzgerald wrote: > This is the binding description of the pinctrl driver for Cirru Logic > Madera codecs. The binding uses the generic pinctrl binding so the main > purpose here is to describe the device-specific names for groups and > functions.

Re: [PATCH v3 02/17] mfd: madera: Add DT bindings for Cirrus Logic Madera codecs

On Fri, Jun 02, 2017 at 04:02:55PM +0100, Richard Fitzgerald wrote: > Specification of the bindings for the parent MFD driver component > of the Cirrus Logic Madera codec drivers. > > Note that although the interrupt controller and GPIO are child > drivers their required bindings are trivial,

Re: [PATCH v3 02/17] mfd: madera: Add DT bindings for Cirrus Logic Madera codecs

On Fri, Jun 02, 2017 at 04:02:55PM +0100, Richard Fitzgerald wrote: > Specification of the bindings for the parent MFD driver component > of the Cirrus Logic Madera codec drivers. > > Note that although the interrupt controller and GPIO are child > drivers their required bindings are trivial,

[PATCH] nohz: Fix spurious warning when hrtimer and clockevent get out of sync

On Wed, Jun 07, 2017 at 09:36:45PM +, Levin, Alexander (Sasha Levin) wrote: > On Wed, Jun 07, 2017 at 04:14:03PM +0200, Frederic Weisbecker wrote: > > On Wed, Jun 07, 2017 at 04:17:41AM +, Levin, Alexander (Sasha Levin) > > wrote: > > > > Thanks Sasha! > > > > > > > > I couldn't

[PATCH] nohz: Fix spurious warning when hrtimer and clockevent get out of sync

On Wed, Jun 07, 2017 at 09:36:45PM +, Levin, Alexander (Sasha Levin) wrote: > On Wed, Jun 07, 2017 at 04:14:03PM +0200, Frederic Weisbecker wrote: > > On Wed, Jun 07, 2017 at 04:17:41AM +, Levin, Alexander (Sasha Levin) > > wrote: > > > > Thanks Sasha! > > > > > > > > I couldn't

[PATCH net-next 1/7] net: dsa: mv88e6xxx: provide printing macros

The mv88e6xxx driver accesses a port's netdev mostly for printing. This is bad for 2 reasons: DSA and CPU ports do not have a netdev pointer; it doesn't give us a correct picture of why a DSA driver might need to access a port's netdev. Introduce mv88e6xxx_{dbg,err,warn} macros to print messages

[PATCH net-next 1/7] net: dsa: mv88e6xxx: provide printing macros

The mv88e6xxx driver accesses a port's netdev mostly for printing. This is bad for 2 reasons: DSA and CPU ports do not have a netdev pointer; it doesn't give us a correct picture of why a DSA driver might need to access a port's netdev. Introduce mv88e6xxx_{dbg,err,warn} macros to print messages

[PATCH net-next 2/7] net: dsa: mv88e6xxx: add egress mode enumeration

As for the frame mode, add a mv88e6xxx_egress_mode enumeration instead of a 16-bit register mask. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.c | 11 ++- drivers/net/dsa/mv88e6xxx/chip.h | 7 +++

[PATCH net-next 2/7] net: dsa: mv88e6xxx: add egress mode enumeration

As for the frame mode, add a mv88e6xxx_egress_mode enumeration instead of a 16-bit register mask. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.c | 11 ++- drivers/net/dsa/mv88e6xxx/chip.h | 7 +++ drivers/net/dsa/mv88e6xxx/port.c | 20 ++--

[PATCH net-next 5/7] net: dsa: mv88e6xxx: rework pause limit operation

All Marvell chips supporting Pause frames limiting use 1-byte value for input and output. Old chips have both bytes adjacent in a 16-bit register. New ones have an indirect table using 8-bit data. The mv88e6xxx library functions (such as in port.c) must not contain driver logic, but only generic

[PATCH net-next 5/7] net: dsa: mv88e6xxx: rework pause limit operation

All Marvell chips supporting Pause frames limiting use 1-byte value for input and output. Old chips have both bytes adjacent in a 16-bit register. New ones have an indirect table using 8-bit data. The mv88e6xxx library functions (such as in port.c) must not contain driver logic, but only generic

[PATCH net-next 6/7] net: dsa: mv88e6xxx: rework jumbo size operation

Marvell chips have a Jumbo Mode to set the maximum frame size (MTU). The mv88e6xxx_ops structure is meant to contain generic functionalities, no driver logic. Change port_jumbo_config to port_set_jumbo_size setting the mode from a given maximum size value. There is no functional changes since we

[PATCH net-next 6/7] net: dsa: mv88e6xxx: rework jumbo size operation

Marvell chips have a Jumbo Mode to set the maximum frame size (MTU). The mv88e6xxx_ops structure is meant to contain generic functionalities, no driver logic. Change port_jumbo_config to port_set_jumbo_size setting the mode from a given maximum size value. There is no functional changes since we

[PATCH net-next 7/7] net: dsa: mv88e6xxx: prefix PHY macros

Prefix the PHY_* macros with a Marvell specific MV88E6XXX_ prefix. There is no functional changes. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/phy.c | 11 ++- drivers/net/dsa/mv88e6xxx/phy.h | 4 ++-- 2 files changed, 8

[PATCH net-next 7/7] net: dsa: mv88e6xxx: prefix PHY macros

Prefix the PHY_* macros with a Marvell specific MV88E6XXX_ prefix. There is no functional changes. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/phy.c | 11 ++- drivers/net/dsa/mv88e6xxx/phy.h | 4 ++-- 2 files changed, 8 insertions(+), 7 deletions(-) diff --git

Re: [RFC PATCH net-next 3/5] bpf/verifier: feed pointer-to-unknown-scalar casts into scalar ALU path

On 08/06/17 19:41, Alexei Starovoitov wrote: > On Thu, Jun 08, 2017 at 06:12:39PM +0100, Edward Cree wrote: >> On 08/06/17 17:50, Alexei Starovoitov wrote: >>> On Thu, Jun 08, 2017 at 04:25:39PM +0100, Edward Cree wrote: On 08/06/17 03:35, Alexei Starovoitov wrote: > such large back and

Re: [RFC PATCH net-next 3/5] bpf/verifier: feed pointer-to-unknown-scalar casts into scalar ALU path

On 08/06/17 19:41, Alexei Starovoitov wrote: > On Thu, Jun 08, 2017 at 06:12:39PM +0100, Edward Cree wrote: >> On 08/06/17 17:50, Alexei Starovoitov wrote: >>> On Thu, Jun 08, 2017 at 04:25:39PM +0100, Edward Cree wrote: On 08/06/17 03:35, Alexei Starovoitov wrote: > such large back and

[PATCH net-next 4/7] net: dsa: mv88e6xxx: do not prefix ops with g1

The mv88e6xxx_ops describe functionalities, regardless their locations (which can be Global1, Global2, or whatever register set.) Rename the g1_set_cpu_port and g1_set_egress_port ops to set_cpu_port and set_egress_port. No functional changes. Signed-off-by: Vivien Didelot

[PATCH net-next 4/7] net: dsa: mv88e6xxx: do not prefix ops with g1

The mv88e6xxx_ops describe functionalities, regardless their locations (which can be Global1, Global2, or whatever register set.) Rename the g1_set_cpu_port and g1_set_egress_port ops to set_cpu_port and set_egress_port. No functional changes. Signed-off-by: Vivien Didelot ---

[PATCH net-next 0/7] net: dsa: mv88e6xxx: ops cosmetics

This patchset brings no functional changes. It is a first step in a bigger cosmetics change to the driver. It provides macros and polishes data types and chip operations. The next patchs will only prefix and document the port registers macros. Vivien Didelot (7): net: dsa: mv88e6xxx: provide

[PATCH net-next 0/7] net: dsa: mv88e6xxx: ops cosmetics

This patchset brings no functional changes. It is a first step in a bigger cosmetics change to the driver. It provides macros and polishes data types and chip operations. The next patchs will only prefix and document the port registers macros. Vivien Didelot (7): net: dsa: mv88e6xxx: provide

Re: New vger mailing list request - linux-firmware

On Thu, Jun 8, 2017 at 11:09 AM, David Miller wrote: > From: "Luis R. Rodriguez" > Date: Thu, 8 Jun 2017 18:19:42 +0200 > >> On Thu, Jun 08, 2017 at 02:53:22PM +0300, Kalle Valo wrote: >>> "Luis R. Rodriguez" writes: >>> >>> > Dear vger

Re: New vger mailing list request - linux-firmware

On Thu, Jun 8, 2017 at 11:09 AM, David Miller wrote: > From: "Luis R. Rodriguez" > Date: Thu, 8 Jun 2017 18:19:42 +0200 > >> On Thu, Jun 08, 2017 at 02:53:22PM +0300, Kalle Valo wrote: >>> "Luis R. Rodriguez" writes: >>> >>> > Dear vger postmaster, >>> > >>> > I think its time for a

[PATCH net-next 3/7] net: dsa: mv88e6xxx: use bridge state values

Reuse the BR_STATE_* values to abstract a port STP state value. This provides shorter names and better control over the DSA switch operation call. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.c | 23 ++-

[PATCH net-next 3/7] net: dsa: mv88e6xxx: use bridge state values

Reuse the BR_STATE_* values to abstract a port STP state value. This provides shorter names and better control over the DSA switch operation call. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.c | 23 ++- drivers/net/dsa/mv88e6xxx/port.c | 20

RE: [PATCH v3] tpm: Enable CLKRUN protocol for Braswell systems

> -Original Message- > From: Alan Cox [mailto:gno...@lxorguk.ukuu.org.uk] > Sent: Thursday, June 8, 2017 11:23 AM > To: Shaikh, Azhar > Cc: jarkko.sakki...@linux.intel.com; jguntho...@obsidianresearch.com; > tpmdd-de...@lists.sourceforge.net;

RE: [PATCH v3] tpm: Enable CLKRUN protocol for Braswell systems

> -Original Message- > From: Alan Cox [mailto:gno...@lxorguk.ukuu.org.uk] > Sent: Thursday, June 8, 2017 11:23 AM > To: Shaikh, Azhar > Cc: jarkko.sakki...@linux.intel.com; jguntho...@obsidianresearch.com; > tpmdd-de...@lists.sourceforge.net; linux-kernel@vger.kernel.org; linux- >

Re: [PATCH 1/3 v2] time: Fix clock->read(clock) race around clocksource changes

On Sun, Jun 4, 2017 at 11:52 AM, Thomas Gleixner wrote: > On Wed, 31 May 2017, John Stultz wrote: >> >> The one exception where this helper isn't necessary is for the >> fast-timekepers which use their own locking and update logic >> to the tkr structures. > > That's simply

Re: [PATCH 1/3 v2] time: Fix clock->read(clock) race around clocksource changes

On Sun, Jun 4, 2017 at 11:52 AM, Thomas Gleixner wrote: > On Wed, 31 May 2017, John Stultz wrote: >> >> The one exception where this helper isn't necessary is for the >> fast-timekepers which use their own locking and update logic >> to the tkr structures. > > That's simply wrong. The fast time

Re: [PATCH] nvmem: core: add managed version of nvmem_register

Am 08.06.2017 um 08:26 schrieb Srinivas Kandagatla: > > > On 07/06/17 22:55, Heiner Kallweit wrote: >> Am 07.06.2017 um 18:19 schrieb Srinivas Kandagatla: >>> >>> On 04/06/17 12:06, Heiner Kallweit wrote: Add a device-managed version of nvmem_register. Signed-off-by: Heiner

Re: [PATCH] nvmem: core: add managed version of nvmem_register

Am 08.06.2017 um 08:26 schrieb Srinivas Kandagatla: > > > On 07/06/17 22:55, Heiner Kallweit wrote: >> Am 07.06.2017 um 18:19 schrieb Srinivas Kandagatla: >>> >>> On 04/06/17 12:06, Heiner Kallweit wrote: Add a device-managed version of nvmem_register. Signed-off-by: Heiner

Re: [PATCH v2 0/1] Add Trusted Path Execution as a stackable LSM

On 6/8/17 2:37 PM, Alan Cox wrote: >> http://phrack.org/issues/52/6.html#article >> >> | A trusted path is one that is inside a root owned directory that >> | is not group or world writable. /bin, /usr/bin, /usr/local/bin, are >> | (under normal circumstances) considered trusted. Any non-root >>

Re: [PATCH v2 0/1] Add Trusted Path Execution as a stackable LSM

On 6/8/17 2:37 PM, Alan Cox wrote: >> http://phrack.org/issues/52/6.html#article >> >> | A trusted path is one that is inside a root owned directory that >> | is not group or world writable. /bin, /usr/bin, /usr/local/bin, are >> | (under normal circumstances) considered trusted. Any non-root >>

Re: [PATCH v2 11/11] ARC: [plat-eznps] Handle memory error as an exception

On 06/08/2017 11:23 AM, Noam Camus wrote: *> From:* Vineet Gupta *> Sent:* Thursday, June 8, 2017 7:38 PM >> >> With simulator we just turn this configuration on, so we redirect the Legacy >> Synopsys L2 ISR from nSIM into machine check. >> This way we end up

Re: [PATCH v2 11/11] ARC: [plat-eznps] Handle memory error as an exception

On 06/08/2017 11:23 AM, Noam Camus wrote: *> From:* Vineet Gupta *> Sent:* Thursday, June 8, 2017 7:38 PM >> >> With simulator we just turn this configuration on, so we redirect the Legacy >> Synopsys L2 ISR from nSIM into machine check. >> This way we end up just like with silicon  >This

Re: [PATCH v2] um: add dummy ioremap and iounmap functions

Any thoughts on this? My patches for the other architectures are already in linux-next. um is the only one that remains. Thanks, Logan On 27/05/17 12:15 PM, Logan Gunthorpe wrote: > Hi, > > On 27/05/17 12:08 PM, Geert Uytterhoeven wrote: >> Still, those code patch could be protected by #ifdef

Re: [PATCH v2] um: add dummy ioremap and iounmap functions

Any thoughts on this? My patches for the other architectures are already in linux-next. um is the only one that remains. Thanks, Logan On 27/05/17 12:15 PM, Logan Gunthorpe wrote: > Hi, > > On 27/05/17 12:08 PM, Geert Uytterhoeven wrote: >> Still, those code patch could be protected by #ifdef

[PATCH net-next] net: ethernet: ti: cpdma: do not enable host error misc irq

CPSW driver does not handle this interrupt, so there are no reasons to enable it in hardware. Signed-off-by: Grygorii Strashko --- no changes, just resubmitting with proper subj line. drivers/net/ethernet/ti/davinci_cpdma.c | 5 + 1 file changed, 1 insertion(+), 4

[PATCH net-next] net: ethernet: ti: cpdma: do not enable host error misc irq

CPSW driver does not handle this interrupt, so there are no reasons to enable it in hardware. Signed-off-by: Grygorii Strashko --- no changes, just resubmitting with proper subj line. drivers/net/ethernet/ti/davinci_cpdma.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git

[PATCH net-next] net: ethernet: ti: cpsw: enable HWTSTAMP_FILTER_PTP_V1_L4_EVENT filter

CPSW driver supports PTP v1 messages, but for unknown reasons this filter is not advertised. As result, ./tools/testing/selftests/networking/timestamping/timestamping utility can't be used for testing of CPSW RX timestamping with option SOF_TIMESTAMPING_RX_HARDWARE, because it uses

[PATCH net-next] net: ethernet: ti: cpsw: enable HWTSTAMP_FILTER_PTP_V1_L4_EVENT filter

CPSW driver supports PTP v1 messages, but for unknown reasons this filter is not advertised. As result, ./tools/testing/selftests/networking/timestamping/timestamping utility can't be used for testing of CPSW RX timestamping with option SOF_TIMESTAMPING_RX_HARDWARE, because it uses

Re: [PATCH v3] tpm: Enable CLKRUN protocol for Braswell systems

> For that purpose all that should be required is strong ordering of the > outb relative to the other TPM commands at the LPC interface FIFO. I > also think the wmb is not needed because outb is already defined to be > strongly in order with respect to writel/readl ? That's my assumption but

Re: [PATCH v3] tpm: Enable CLKRUN protocol for Braswell systems

> For that purpose all that should be required is strong ordering of the > outb relative to the other TPM commands at the LPC interface FIFO. I > also think the wmb is not needed because outb is already defined to be > strongly in order with respect to writel/readl ? That's my assumption but

Re: [PATCH v1 04/25] lib/vsprintf: Print time and date in human readable format via %pt

On Thu, Jun 8, 2017 at 9:41 PM, Alexandre Belloni wrote: > On 08/06/2017 at 20:57:05 +0300, Andy Shevchenko wrote: >> On Thu, Jun 8, 2017 at 6:05 PM, Alexandre Belloni >> wrote: >> > I understand this may not fit your

Re: [PATCH v1 04/25] lib/vsprintf: Print time and date in human readable format via %pt

On Thu, Jun 8, 2017 at 9:41 PM, Alexandre Belloni wrote: > On 08/06/2017 at 20:57:05 +0300, Andy Shevchenko wrote: >> On Thu, Jun 8, 2017 at 6:05 PM, Alexandre Belloni >> wrote: >> > I understand this may not fit your debugging needs but what about pretty >> > printing time64_t and using

Re: [PATCH v5 0/9] locking/rwsem: Enable reader optimistic spinning

Hi, Got the following tip-bit about this patch performance impact. Cheers, Longman Greeting, FYI, we noticed a 125.4% improvement of will-it-scale.per_thread_ops due to commit: commit: a150752454e4aea37a44d7eb5baf5a538bcad6fc

Re: [PATCH v5 0/9] locking/rwsem: Enable reader optimistic spinning

Hi, Got the following tip-bit about this patch performance impact. Cheers, Longman Greeting, FYI, we noticed a 125.4% improvement of will-it-scale.per_thread_ops due to commit: commit: a150752454e4aea37a44d7eb5baf5a538bcad6fc

Re: [PATCH v1 04/25] lib/vsprintf: Print time and date in human readable format via %pt

On 08/06/2017 at 20:57:05 +0300, Andy Shevchenko wrote: > On Thu, Jun 8, 2017 at 6:05 PM, Alexandre Belloni > wrote: > > On 08/06/2017 at 17:55:12 +0300, Andy Shevchenko wrote: > >> On Thu, Jun 8, 2017 at 5:49 PM, Arnd Bergmann wrote: > >> >

Re: [PATCH v1 04/25] lib/vsprintf: Print time and date in human readable format via %pt

On 08/06/2017 at 20:57:05 +0300, Andy Shevchenko wrote: > On Thu, Jun 8, 2017 at 6:05 PM, Alexandre Belloni > wrote: > > On 08/06/2017 at 17:55:12 +0300, Andy Shevchenko wrote: > >> On Thu, Jun 8, 2017 at 5:49 PM, Arnd Bergmann wrote: > >> > On Thu, Jun 8, 2017 at 3:47 PM, Andy Shevchenko > >> >

Re: [RFC PATCH net-next 3/5] bpf/verifier: feed pointer-to-unknown-scalar casts into scalar ALU path

On Thu, Jun 08, 2017 at 06:12:39PM +0100, Edward Cree wrote: > On 08/06/17 17:50, Alexei Starovoitov wrote: > > On Thu, Jun 08, 2017 at 04:25:39PM +0100, Edward Cree wrote: > >> On 08/06/17 03:35, Alexei Starovoitov wrote: > >>> such large back and forth move doesn't help reviewing. > >>> may be

Re: [RFC PATCH net-next 3/5] bpf/verifier: feed pointer-to-unknown-scalar casts into scalar ALU path

On Thu, Jun 08, 2017 at 06:12:39PM +0100, Edward Cree wrote: > On 08/06/17 17:50, Alexei Starovoitov wrote: > > On Thu, Jun 08, 2017 at 04:25:39PM +0100, Edward Cree wrote: > >> On 08/06/17 03:35, Alexei Starovoitov wrote: > >>> such large back and forth move doesn't help reviewing. > >>> may be

Re: [PATCH v3] tpm: Enable CLKRUN protocol for Braswell systems

On Thu, Jun 08, 2017 at 07:22:59PM +0100, Alan Cox wrote: > > > > + outb(0x80, 0xCC); > > > > + > > > > + /* Make sure the above write is completed */ > > > > + wmb(); > > > > > > Why the wmb(). It doesn't do what the comment says! Also this code is x86 > > > specific > > > >

Re: [PATCH v3] tpm: Enable CLKRUN protocol for Braswell systems

On Thu, Jun 08, 2017 at 07:22:59PM +0100, Alan Cox wrote: > > > > + outb(0x80, 0xCC); > > > > + > > > > + /* Make sure the above write is completed */ > > > > + wmb(); > > > > > > Why the wmb(). It doesn't do what the comment says! Also this code is x86 > > > specific > > > >

Re: [PATCH v7 21/26] x86: Add emulation code for UMIP instructions

On Fri, May 05, 2017 at 11:17:19AM -0700, Ricardo Neri wrote: > The feature User-Mode Instruction Prevention present in recent Intel > processor prevents a group of instructions from being executed with > CPL > 0. Otherwise, a general protection fault is issued. This is one of the best opening

Re: [PATCH v7 21/26] x86: Add emulation code for UMIP instructions

On Fri, May 05, 2017 at 11:17:19AM -0700, Ricardo Neri wrote: > The feature User-Mode Instruction Prevention present in recent Intel > processor prevents a group of instructions from being executed with > CPL > 0. Otherwise, a general protection fault is issued. This is one of the best opening

Re: [PATCH v1 06/25] rtc: Switch to use %pt

On Thu, Jun 8, 2017 at 5:00 PM, Greg Kroah-Hartman wrote: > On Thu, Jun 08, 2017 at 04:47:52PM +0300, Andy Shevchenko wrote: >> Use %pt instead of open coded variant to print content of >> struct rtc_time in human readable format. >> >> Arnd Bergmann >

Re: [PATCH v1 06/25] rtc: Switch to use %pt

On Thu, Jun 8, 2017 at 5:00 PM, Greg Kroah-Hartman wrote: > On Thu, Jun 08, 2017 at 04:47:52PM +0300, Andy Shevchenko wrote: >> Use %pt instead of open coded variant to print content of >> struct rtc_time in human readable format. >> >> Arnd Bergmann > > Cc: ? Yep! Fixed locally, will be in

[PATCH v2 2/2] acpi/nfit: Issue Start ARS to retrieve existing records

ACPI 6.2 defines in section 9.20.7.2 that the OSPM may call a Start ARS with Flags Bit [1] set upon receiving the 0x81 notification. Upon receiving the notification, the OSPM may decide to issue a Start ARS with Flags Bit [1] set to prepare for the retrieval of existing records and issue

[PATCH v2 0/2] NVDIMM memory error notification support

ACPI 6.2 defines a new ACPI notification value to NVDIMM Root Device. This allows BIOS to inform the OS that new uncorrectable memory error is detected during run-time. This patch-set adds support of this notification, which starts ARS and updates badblocks information to prevent the OS from

[PATCH v2 2/2] acpi/nfit: Issue Start ARS to retrieve existing records

ACPI 6.2 defines in section 9.20.7.2 that the OSPM may call a Start ARS with Flags Bit [1] set upon receiving the 0x81 notification. Upon receiving the notification, the OSPM may decide to issue a Start ARS with Flags Bit [1] set to prepare for the retrieval of existing records and issue

[PATCH v2 0/2] NVDIMM memory error notification support

ACPI 6.2 defines a new ACPI notification value to NVDIMM Root Device. This allows BIOS to inform the OS that new uncorrectable memory error is detected during run-time. This patch-set adds support of this notification, which starts ARS and updates badblocks information to prevent the OS from

[PATCH v2 1/2] acpi/nfit: Add support of NVDIMM memory error notification in ACPI 6.2

ACPI 6.2 defines a new ACPI notification value to NVDIMM Root Device in Table 5-169. 0x81 Unconsumed Uncorrectable Memory Error Detected Used to pro-actively notify OSPM of uncorrectable memory errors detected (for example a memory scrubbing engine that continuously scans the

[PATCH v2 1/2] acpi/nfit: Add support of NVDIMM memory error notification in ACPI 6.2

ACPI 6.2 defines a new ACPI notification value to NVDIMM Root Device in Table 5-169. 0x81 Unconsumed Uncorrectable Memory Error Detected Used to pro-actively notify OSPM of uncorrectable memory errors detected (for example a memory scrubbing engine that continuously scans the

Re: [PATCH v2 0/1] Add Trusted Path Execution as a stackable LSM

> http://phrack.org/issues/52/6.html#article > > | A trusted path is one that is inside a root owned directory that > | is not group or world writable. /bin, /usr/bin, /usr/local/bin, are > | (under normal circumstances) considered trusted. Any non-root > | users home directory is not trusted,

Re: [PATCH v2 0/1] Add Trusted Path Execution as a stackable LSM

> http://phrack.org/issues/52/6.html#article > > | A trusted path is one that is inside a root owned directory that > | is not group or world writable. /bin, /usr/bin, /usr/local/bin, are > | (under normal circumstances) considered trusted. Any non-root > | users home directory is not trusted,

Re: [PATCH RFC 0/3] Improve stability of system clock

On Thu, Jun 8, 2017 at 9:17 AM, Miroslav Lichvar wrote: > On Fri, May 19, 2017 at 05:35:38PM -0700, John Stultz wrote: >> >> On Wed, May 17, 2017 at 10:22 AM, Miroslav Lichvar >> >> wrote: >> >> > Is there a better way to run the timekeeping code in an

Re: [PATCH RFC 0/3] Improve stability of system clock

On Thu, Jun 8, 2017 at 9:17 AM, Miroslav Lichvar wrote: > On Fri, May 19, 2017 at 05:35:38PM -0700, John Stultz wrote: >> >> On Wed, May 17, 2017 at 10:22 AM, Miroslav Lichvar >> >> wrote: >> >> > Is there a better way to run the timekeeping code in an userspace >> >> > application? I suspect

Re: [RFC PATCH 2/3] Implement sysfs based cpuinfo for x86 cpus.

On Thu, Jun 08, 2017 at 06:56:14PM +0200, Felix Schnizlein wrote: > A few entries have been omitted, due to already existing information in > sysfs: > > - microcode -> /sys/devices/system/cpu/cpu*/microcode/version > - cache -> /sys/devices/system/cpu/cpu*/cache/index*/size > - core_id ->

Re: [RFC PATCH 2/3] Implement sysfs based cpuinfo for x86 cpus.

On Thu, Jun 08, 2017 at 06:56:14PM +0200, Felix Schnizlein wrote: > A few entries have been omitted, due to already existing information in > sysfs: > > - microcode -> /sys/devices/system/cpu/cpu*/microcode/version > - cache -> /sys/devices/system/cpu/cpu*/cache/index*/size > - core_id ->

Re: [RFC PATCH 1/3] Add sysfs based cpuinfo structure.

On Thu, Jun 08, 2017 at 06:56:13PM +0200, Felix Schnizlein wrote: > Create a new sysfs attribute group called 'cpuinfo' for each > online cpu. The cleaned up cpuinfo shows up in a sysfs > subdirectory here: /sys/devices/system/cpu/cpu*/cpuinfo. > > Define preprocessor macros (CPUINFO_DEFINE_* and

Re: [RFC PATCH 1/3] Add sysfs based cpuinfo structure.

On Thu, Jun 08, 2017 at 06:56:13PM +0200, Felix Schnizlein wrote: > Create a new sysfs attribute group called 'cpuinfo' for each > online cpu. The cleaned up cpuinfo shows up in a sysfs > subdirectory here: /sys/devices/system/cpu/cpu*/cpuinfo. > > Define preprocessor macros (CPUINFO_DEFINE_* and

Re: [PATCH] Add support of NVDIMM memory error notification in ACPI 6.2

On Thu, 2017-06-08 at 11:37 -0600, Toshi Kani wrote: > On Thu, 2017-06-08 at 10:34 -0700, Dan Williams wrote: > > On Thu, Jun 8, 2017 at 10:30 AM, Linda Knippers > .c > > om> wrote: > > [..] > > > Wasn't Dan concerned about how the OS can know whether the FW > > > supports

Re: [PATCH] Add support of NVDIMM memory error notification in ACPI 6.2

On Thu, 2017-06-08 at 11:37 -0600, Toshi Kani wrote: > On Thu, 2017-06-08 at 10:34 -0700, Dan Williams wrote: > > On Thu, Jun 8, 2017 at 10:30 AM, Linda Knippers > .c > > om> wrote: > > [..] > > > Wasn't Dan concerned about how the OS can know whether the FW > > > supports that bit in the Start

Re: [RFC PATCH 3/3] Add deprecation warning to cpuinfo proc

On Thu, Jun 08, 2017 at 06:56:15PM +0200, Felix Schnizlein wrote: > Enable deprecation warning if the kernel was compiled with sysfs cpuinfo. > > Signed-off-by: Thomas Renninger > --- > fs/proc/cpuinfo.c | 4 > 1 file changed, 4 insertions(+) > > diff --git

Re: [RFC PATCH 3/3] Add deprecation warning to cpuinfo proc

On Thu, Jun 08, 2017 at 06:56:15PM +0200, Felix Schnizlein wrote: > Enable deprecation warning if the kernel was compiled with sysfs cpuinfo. > > Signed-off-by: Thomas Renninger > --- > fs/proc/cpuinfo.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/fs/proc/cpuinfo.c

Re: [RFC PATCH 2/3] Implement sysfs based cpuinfo for x86 cpus.

On Thu, Jun 08, 2017 at 06:56:14PM +0200, Felix Schnizlein wrote: > A few entries have been omitted, due to already existing information in > sysfs: > > - microcode -> /sys/devices/system/cpu/cpu*/microcode/version > - cache -> /sys/devices/system/cpu/cpu*/cache/index*/size > - core_id ->

Re: [RFC PATCH 2/3] Implement sysfs based cpuinfo for x86 cpus.

On Thu, Jun 08, 2017 at 06:56:14PM +0200, Felix Schnizlein wrote: > A few entries have been omitted, due to already existing information in > sysfs: > > - microcode -> /sys/devices/system/cpu/cpu*/microcode/version > - cache -> /sys/devices/system/cpu/cpu*/cache/index*/size > - core_id ->

Re: [RFC PATCH 1/3] Add sysfs based cpuinfo structure.

On Thu, Jun 08, 2017 at 06:56:13PM +0200, Felix Schnizlein wrote: > Create a new sysfs attribute group called 'cpuinfo' for each > online cpu. The cleaned up cpuinfo shows up in a sysfs > subdirectory here: /sys/devices/system/cpu/cpu*/cpuinfo. > > Define preprocessor macros (CPUINFO_DEFINE_* and

Re: [RFC PATCH 1/3] Add sysfs based cpuinfo structure.

On Thu, Jun 08, 2017 at 06:56:13PM +0200, Felix Schnizlein wrote: > Create a new sysfs attribute group called 'cpuinfo' for each > online cpu. The cleaned up cpuinfo shows up in a sysfs > subdirectory here: /sys/devices/system/cpu/cpu*/cpuinfo. > > Define preprocessor macros (CPUINFO_DEFINE_* and

Re: [PATCH v1 0/4] coresight: support panic dump functionality

On 3 June 2017 at 08:42, Leo Yan wrote: > ### Introduction ### Good day Leo, > > Embedded Trace Buffer (ETB) provides on-chip storage of trace data, > usually has buffer size from 2KB to 8KB. These data has been used for > profiling and this has been well implemented in

Re: [PATCH v1 0/4] coresight: support panic dump functionality

On 3 June 2017 at 08:42, Leo Yan wrote: > ### Introduction ### Good day Leo, > > Embedded Trace Buffer (ETB) provides on-chip storage of trace data, > usually has buffer size from 2KB to 8KB. These data has been used for > profiling and this has been well implemented in coresight driver. > >

Re: [PATCH v3] tpm: Enable CLKRUN protocol for Braswell systems

> > > + outb(0x80, 0xCC); > > > + > > > + /* Make sure the above write is completed */ > > > + wmb(); > > > > Why the wmb(). It doesn't do what the comment says! Also this code is x86 > > specific > > > > > > Memory barrier to enforce the order so that the outb() is completed, which >

Re: [PATCH v3] tpm: Enable CLKRUN protocol for Braswell systems

> > > + outb(0x80, 0xCC); > > > + > > > + /* Make sure the above write is completed */ > > > + wmb(); > > > > Why the wmb(). It doesn't do what the comment says! Also this code is x86 > > specific > > > > > > Memory barrier to enforce the order so that the outb() is completed, which >

Re: [PATCH] platform/x86/acer-wmi: Detect RF Button capability

On Thu, Jun 8, 2017 at 5:50 PM, joeyli wrote: > On Tue, Jun 06, 2017 at 01:07:22PM -0700, João Paulo Rechi Vita wrote: >> Signed-off-by: João Paulo Rechi Vita > > Please feel free to add: > Reviewed-by: "Lee, Chun-Yi"

Re: [PATCH] platform/x86/acer-wmi: Detect RF Button capability

On Thu, Jun 8, 2017 at 5:50 PM, joeyli wrote: > On Tue, Jun 06, 2017 at 01:07:22PM -0700, João Paulo Rechi Vita wrote: >> Signed-off-by: João Paulo Rechi Vita > > Please feel free to add: > Reviewed-by: "Lee, Chun-Yi" Patchwork by some reason doesn't recognize this tag (presumably it

Resend [PATCH] powerpc/hotplug-mem: Fix aa_index match bug for hotplug

When adding or removing memory, the aa_index (affinity value) for the memblock must also be converted to match the endianness of the rest of the 'ibm,dynamic-memory' property. Otherwise, subsequent retrieval of the attribute will likely lead to non-existent nodes, followed by using the default

Resend [PATCH] powerpc/hotplug-mem: Fix aa_index match bug for hotplug

When adding or removing memory, the aa_index (affinity value) for the memblock must also be converted to match the endianness of the rest of the 'ibm,dynamic-memory' property. Otherwise, subsequent retrieval of the attribute will likely lead to non-existent nodes, followed by using the default

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