Re: ktest help

On Thu, 6 Apr 2017 13:53:59 -0500 Timur Tabi wrote: > On 04/06/2017 01:50 PM, Steven Rostedt wrote: > > Currently yes, but it shouldn't be hard to add a hook to intervene. I > > just haven't had something that required it yet. > > If I understood Perl, I would add the

Re: ktest help

On Thu, 6 Apr 2017 13:53:59 -0500 Timur Tabi wrote: > On 04/06/2017 01:50 PM, Steven Rostedt wrote: > > Currently yes, but it shouldn't be hard to add a hook to intervene. I > > just haven't had something that required it yet. > > If I understood Perl, I would add the feature myself. > I

Re: [PATCH] mac80211: Fix clang warning about constant operand in logical operation

On Thu, 2017-04-06 at 11:56 -0700, Matthias Kaehlcke wrote: > Clang raises a warning about the expression 'strlen(CONFIG_XXX)' > being > used in a logical operation. Clangs' builtin strlen function resolves > the > expression to a constant at compile time, which causes clang to > generate > a

Re: [PATCH] mac80211: Fix clang warning about constant operand in logical operation

On Thu, 2017-04-06 at 11:56 -0700, Matthias Kaehlcke wrote: > Clang raises a warning about the expression 'strlen(CONFIG_XXX)' > being > used in a logical operation. Clangs' builtin strlen function resolves > the > expression to a constant at compile time, which causes clang to > generate > a

Re: [tpmdd-devel] Regression between Linux 3.16 and 4.8/4.9 on Lenovo X60 with coreboot

On Thu, Apr 06, 2017 at 08:26:22PM +0200, Paul Menzel wrote: > >We added direct ACPI binding to the driver in addition to PNP, so if > >you have an ACPI table it goes down that path and does some additional > >validation of what is in the TPM. The BIOS must provide a > >acpi_dev_resource_memory

Re: [tpmdd-devel] Regression between Linux 3.16 and 4.8/4.9 on Lenovo X60 with coreboot

On Thu, Apr 06, 2017 at 08:26:22PM +0200, Paul Menzel wrote: > >We added direct ACPI binding to the driver in addition to PNP, so if > >you have an ACPI table it goes down that path and does some additional > >validation of what is in the TPM. The BIOS must provide a > >acpi_dev_resource_memory

Re: [PATCH] misc: sgi-xp: Use setup_timer Kernel API instead of

On Sun, Apr 2, 2017 at 10:17 AM, Santosh Kumar Singh wrote: > Replace init_timer function with setup_timer reported by coccinelle > > Signed-off-by: Santosh Kumar Singh Acked-by: Robin Holt

Re: [PATCH] misc: sgi-xp: Use setup_timer Kernel API instead of

On Sun, Apr 2, 2017 at 10:17 AM, Santosh Kumar Singh wrote: > Replace init_timer function with setup_timer reported by coccinelle > > Signed-off-by: Santosh Kumar Singh Acked-by: Robin Holt

Re: [PATCH 2/2] memory: ti-emif-sram: introduce relocatable suspend/resume handlers

On 04/06/2017 02:00 PM, Russell King - ARM Linux wrote: On Wed, Apr 05, 2017 at 09:48:26AM -0500, Dave Gerlach wrote: Russell, On 04/05/2017 09:33 AM, Tony Lindgren wrote: * Russell King - ARM Linux [170405 07:02]: I'm not going to comment on this yet, but I'll instead

Re: [PATCH 2/2] memory: ti-emif-sram: introduce relocatable suspend/resume handlers

On 04/06/2017 02:00 PM, Russell King - ARM Linux wrote: On Wed, Apr 05, 2017 at 09:48:26AM -0500, Dave Gerlach wrote: Russell, On 04/05/2017 09:33 AM, Tony Lindgren wrote: * Russell King - ARM Linux [170405 07:02]: I'm not going to comment on this yet, but I'll instead comment on the newly

Re: [PATCH] misc: sram-exec: Use aligned fncpy instead of memcpy

On Wed, Apr 05, 2017 at 02:22:33PM -0500, Dave Gerlach wrote: > Russell, > On 04/05/2017 02:21 PM, Dave Gerlach wrote: > >Currently the sram-exec functionality, which allows allocation of > >executable memory and provides an API to move code to it, is only > >selected in configs for the ARM

Re: [PATCH] misc: sram-exec: Use aligned fncpy instead of memcpy

On Wed, Apr 05, 2017 at 02:22:33PM -0500, Dave Gerlach wrote: > Russell, > On 04/05/2017 02:21 PM, Dave Gerlach wrote: > >Currently the sram-exec functionality, which allows allocation of > >executable memory and provides an API to move code to it, is only > >selected in configs for the ARM

Re: [PATCH] sparc32: Export vac_cache_size to fix build error

From: Guenter Roeck Date: Sat, 1 Apr 2017 13:47:44 -0700 > sparc32:allmodconfig fails to build with the following error. > > ERROR: "vac_cache_size" [drivers/infiniband/sw/rxe/rdma_rxe.ko] undefined! > > Fixes: cb8864559631 ("infiniband: Fix alignment of mmap cookies ...")

Re: [PATCH] sparc32: Export vac_cache_size to fix build error

From: Guenter Roeck Date: Sat, 1 Apr 2017 13:47:44 -0700 > sparc32:allmodconfig fails to build with the following error. > > ERROR: "vac_cache_size" [drivers/infiniband/sw/rxe/rdma_rxe.ko] undefined! > > Fixes: cb8864559631 ("infiniband: Fix alignment of mmap cookies ...") > Cc: Jason

Re: [PATCH v2] sparc: remove unused wp_works_ok macro

From: Mathias Krause Date: Wed, 5 Apr 2017 21:24:20 +0200 > It's unused for ages, used to be required for ksyms.c back in the v1.1 > times. > > Signed-off-by: Mathias Krause > Acked-by: David S. Miller > --- > Hi Dave, > >

Re: [PATCH v2] sparc: remove unused wp_works_ok macro

From: Mathias Krause Date: Wed, 5 Apr 2017 21:24:20 +0200 > It's unused for ages, used to be required for ksyms.c back in the v1.1 > times. > > Signed-off-by: Mathias Krause > Acked-by: David S. Miller > --- > Hi Dave, > > same patch as v1 but as the tip folks took only the x86 parts, I

Re: [PATCH] sparc64: Fix memory corruption when THP is enabled

From: Nitin Gupta Date: Fri, 31 Mar 2017 15:48:53 -0700 > The memory corruption was happening due to incorrect > TLB/TSB flushing of hugepages. > > Reported-by: David S. Miller > Signed-off-by: Nitin Gupta Applied.

Re: [PATCH] sparc64: Fix memory corruption when THP is enabled

From: Nitin Gupta Date: Fri, 31 Mar 2017 15:48:53 -0700 > The memory corruption was happening due to incorrect > TLB/TSB flushing of hugepages. > > Reported-by: David S. Miller > Signed-off-by: Nitin Gupta Applied.

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

On Thu, Apr 06, 2017 at 01:34:20PM +1000, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the staging tree got conflicts in: > > drivers/staging/media/lirc/lirc_sasem.c > drivers/staging/media/lirc/lirc_sir.c > > between commits: > > e66267161971 ("[media] rc: promote

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

On Thu, Apr 06, 2017 at 01:34:20PM +1000, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the staging tree got conflicts in: > > drivers/staging/media/lirc/lirc_sasem.c > drivers/staging/media/lirc/lirc_sir.c > > between commits: > > e66267161971 ("[media] rc: promote

Re: [PATCH v2] Extend pca9532 device tree support

Hi Pavel, On 04/06/2017 05:50 PM, Pavel Machek wrote: > Hi! > >>> diff --git a/Documentation/devicetree/bindings/leds/leds-pca9532.txt >>> b/Documentation/devicetree/bindings/leds/leds-pca9532.txt >>> index 198f3ba..8374075 100644 >>> ---

Re: [PATCH 2/2] memory: ti-emif-sram: introduce relocatable suspend/resume handlers

On Wed, Apr 05, 2017 at 09:48:26AM -0500, Dave Gerlach wrote: > Russell, > On 04/05/2017 09:33 AM, Tony Lindgren wrote: > >* Russell King - ARM Linux [170405 07:02]: > >>I'm not going to comment on this yet, but I'll instead comment on the > >>newly appeared

Re: [PATCH v2] Extend pca9532 device tree support

Hi Pavel, On 04/06/2017 05:50 PM, Pavel Machek wrote: > Hi! > >>> diff --git a/Documentation/devicetree/bindings/leds/leds-pca9532.txt >>> b/Documentation/devicetree/bindings/leds/leds-pca9532.txt >>> index 198f3ba..8374075 100644 >>> ---

Re: [PATCH 2/2] memory: ti-emif-sram: introduce relocatable suspend/resume handlers

On Wed, Apr 05, 2017 at 09:48:26AM -0500, Dave Gerlach wrote: > Russell, > On 04/05/2017 09:33 AM, Tony Lindgren wrote: > >* Russell King - ARM Linux [170405 07:02]: > >>I'm not going to comment on this yet, but I'll instead comment on the > >>newly appeared sram_exec_copy() stuff. > >> > >>So, a

Re: [tpmdd-devel] Regression between Linux 3.16 and 4.8/4.9 on Lenovo X60 with coreboot

On Thu, Apr 06, 2017 at 10:55:57AM -0600, Jason Gunthorpe wrote: > On Thu, Apr 06, 2017 at 08:18:33AM +0200, Paul Menzel wrote: > > > Indeed, that improves the situation. I still need to pass `force=1` to the > > module to get `/dev/tpm0`. No idea, why it’s not in included in Linux 4.9 > > yet. >

Re: [tpmdd-devel] Regression between Linux 3.16 and 4.8/4.9 on Lenovo X60 with coreboot

On Thu, Apr 06, 2017 at 10:55:57AM -0600, Jason Gunthorpe wrote: > On Thu, Apr 06, 2017 at 08:18:33AM +0200, Paul Menzel wrote: > > > Indeed, that improves the situation. I still need to pass `force=1` to the > > module to get `/dev/tpm0`. No idea, why it’s not in included in Linux 4.9 > > yet. >

[PATCH] scsi: sd: fix warning on min_not_zero use

When calling min_not_zero, both arguments should have the same type. Otherwise the compiler will raise a warning: CC drivers/scsi/sd.o In file included from ./include/linux/list.h:8:0, from ./include/linux/module.h:9, from drivers/scsi/sd.c:35:

[PATCH] scsi: sd: fix warning on min_not_zero use

When calling min_not_zero, both arguments should have the same type. Otherwise the compiler will raise a warning: CC drivers/scsi/sd.o In file included from ./include/linux/list.h:8:0, from ./include/linux/module.h:9, from drivers/scsi/sd.c:35:

Re: [PATCH v4 2/2] iio: Aspeed ADC

On Wed, Apr 5, 2017 at 6:10 PM, Stephen Boyd wrote: > On 04/05, Rick Altherr wrote: >> On Wed, Apr 5, 2017 at 1:27 PM, Stephen Boyd wrote: >> > On 03/23, Rick Altherr wrote: >> >> + >> >> +static int aspeed_adc_probe(struct platform_device *pdev) >> >>

Re: [PATCH v4 2/2] iio: Aspeed ADC

On Wed, Apr 5, 2017 at 6:10 PM, Stephen Boyd wrote: > On 04/05, Rick Altherr wrote: >> On Wed, Apr 5, 2017 at 1:27 PM, Stephen Boyd wrote: >> > On 03/23, Rick Altherr wrote: >> >> + >> >> +static int aspeed_adc_probe(struct platform_device *pdev) >> >> +{ >> >> + struct iio_dev *indio_dev;

[PATCH] mac80211: Fix clang warning about constant operand in logical operation

Clang raises a warning about the expression 'strlen(CONFIG_XXX)' being used in a logical operation. Clangs' builtin strlen function resolves the expression to a constant at compile time, which causes clang to generate a 'constant-logical-operand' warning. Split the if statement in two to avoid

[PATCH] mac80211: Fix clang warning about constant operand in logical operation

Clang raises a warning about the expression 'strlen(CONFIG_XXX)' being used in a logical operation. Clangs' builtin strlen function resolves the expression to a constant at compile time, which causes clang to generate a 'constant-logical-operand' warning. Split the if statement in two to avoid

Applied "regulator: helpers: Add regmap set_soft_start helper" to the regulator tree

The patch regulator: helpers: Add regmap set_soft_start helper has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "regulator: helpers: Add regmap set_soft_start helper" to the regulator tree

The patch regulator: helpers: Add regmap set_soft_start helper has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "ASoC: Add support for Maxim Integrated MAX98927 Amplifier" to the asoc tree

The patch ASoC: Add support for Maxim Integrated MAX98927 Amplifier has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

Applied "ASoC: Add support for Maxim Integrated MAX98927 Amplifier" to the asoc tree

The patch ASoC: Add support for Maxim Integrated MAX98927 Amplifier has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

Applied "ASoC: codec: wm8960: Stop when a matching PLL freq is found" to the asoc tree

The patch ASoC: codec: wm8960: Stop when a matching PLL freq is found has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS

On 04/06/17 14:35, gengdongjiu wrote: > Dear, Laszlo >Thanks for your detailed explanation. > > On 2017/3/29 19:58, Laszlo Ersek wrote: >> (This ought to be one of the longest address lists I've ever seen :) >> Thanks for the CC. I'm glad Shannon is already on the CC list. For good >>

Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS

On 04/06/17 14:35, gengdongjiu wrote: > Dear, Laszlo >Thanks for your detailed explanation. > > On 2017/3/29 19:58, Laszlo Ersek wrote: >> (This ought to be one of the longest address lists I've ever seen :) >> Thanks for the CC. I'm glad Shannon is already on the CC list. For good >>

Applied "ASoC: codec: wm8960: Stop when a matching PLL freq is found" to the asoc tree

The patch ASoC: codec: wm8960: Stop when a matching PLL freq is found has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "regulator: helpers: Add regmap set_pull_down helper" to the regulator tree

The patch regulator: helpers: Add regmap set_pull_down helper has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "regulator: helpers: Add regmap set_pull_down helper" to the regulator tree

The patch regulator: helpers: Add regmap set_pull_down helper has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Re: ktest help

On 04/06/2017 01:50 PM, Steven Rostedt wrote: > Currently yes, but it shouldn't be hard to add a hook to intervene. I > just haven't had something that required it yet. If I understood Perl, I would add the feature myself. -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm

Re: ktest help

On 04/06/2017 01:50 PM, Steven Rostedt wrote: > Currently yes, but it shouldn't be hard to add a hook to intervene. I > just haven't had something that required it yet. If I understood Perl, I would add the feature myself. -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm

Re: [RFC 4/8] regulator: core: Check enabling bypass respects constraints

On Tue, Mar 28, 2017 at 10:49:55PM +0300, Leonard Crestez wrote: > On Tue, 2017-03-28 at 17:47 +0100, Mark Brown wrote: > > To repeat what I said previously the whole point of bypassing is to not > > do regulation and generally the constraints in the unregulated idle case > > are substantially

Re: [RFC 4/8] regulator: core: Check enabling bypass respects constraints

On Tue, Mar 28, 2017 at 10:49:55PM +0300, Leonard Crestez wrote: > On Tue, 2017-03-28 at 17:47 +0100, Mark Brown wrote: > > To repeat what I said previously the whole point of bypassing is to not > > do regulation and generally the constraints in the unregulated idle case > > are substantially

Re: Is it safe for kthreadd to drain_all_pages?

On Thu, 6 Apr 2017, Mel Gorman wrote: > On Wed, Apr 05, 2017 at 01:59:49PM -0700, Hugh Dickins wrote: > > Hi Mel, > > > > I suspect that it's not safe for kthreadd to drain_all_pages(); > > but I haven't studied flush_work() etc, so don't really know what > > I'm talking about: hoping that you

Re: Is it safe for kthreadd to drain_all_pages?

On Thu, 6 Apr 2017, Mel Gorman wrote: > On Wed, Apr 05, 2017 at 01:59:49PM -0700, Hugh Dickins wrote: > > Hi Mel, > > > > I suspect that it's not safe for kthreadd to drain_all_pages(); > > but I haven't studied flush_work() etc, so don't really know what > > I'm talking about: hoping that you

Re: ktest help

On Thu, 6 Apr 2017 13:39:00 -0500 Timur Tabi wrote: > On 04/06/2017 12:05 PM, Steven Rostedt wrote: > >> > Is there a way I can send a "boot" command after ktest connects to the > >> > console? > >> > > > Not currently, but that is something I've been wanting to add for

Re: ktest help

On Thu, 6 Apr 2017 13:39:00 -0500 Timur Tabi wrote: > On 04/06/2017 12:05 PM, Steven Rostedt wrote: > >> > Is there a way I can send a "boot" command after ktest connects to the > >> > console? > >> > > > Not currently, but that is something I've been wanting to add for some > > time. > >

Re: [Patch V2 2/2] x86/mm/numa: remove the numa_nodemask_from_meminfo()

On Thu, Apr 06, 2017 at 09:21:47PM +0300, Kirill A. Shutemov wrote: > > Long story short, something as trivial as this helps here: > > Yep. Works for me. > > Reported-and-tested-by: Kirill A. Shutemov Thanks. Now, I'd really like to have more test coverage and

Re: [Patch V2 2/2] x86/mm/numa: remove the numa_nodemask_from_meminfo()

On Thu, Apr 06, 2017 at 09:21:47PM +0300, Kirill A. Shutemov wrote: > > Long story short, something as trivial as this helps here: > > Yep. Works for me. > > Reported-and-tested-by: Kirill A. Shutemov Thanks. Now, I'd really like to have more test coverage and be sure this "cleanup" doesn't

Re: [PATCH 3/4] tracing: Add stack_tracer_disable/enable() functions

On Thu, 6 Apr 2017 11:12:22 -0700 "Paul E. McKenney" wrote: > On Thu, Apr 06, 2017 at 12:42:40PM -0400, Steven Rostedt wrote: > > From: "Steven Rostedt (VMware)" > > > > There are certain parts of the kernel that can not let stack tracing > >

Re: [PATCH 3/4] tracing: Add stack_tracer_disable/enable() functions

On Thu, 6 Apr 2017 11:12:22 -0700 "Paul E. McKenney" wrote: > On Thu, Apr 06, 2017 at 12:42:40PM -0400, Steven Rostedt wrote: > > From: "Steven Rostedt (VMware)" > > > > There are certain parts of the kernel that can not let stack tracing > > proceed (namely in RCU), because the stack tracer

Re: [PATCH 8/8] x86/mm: Allow to have userspace mappings above 47-bits

Hi Kirill, On 04/06/2017 05:01 PM, Kirill A. Shutemov wrote: On x86, 5-level paging enables 56-bit userspace virtual address space. Not all user space is ready to handle wide addresses. It's known that at least some JIT compilers use higher bits in pointers to encode their information. It

Re: [PATCH 8/8] x86/mm: Allow to have userspace mappings above 47-bits

Hi Kirill, On 04/06/2017 05:01 PM, Kirill A. Shutemov wrote: On x86, 5-level paging enables 56-bit userspace virtual address space. Not all user space is ready to handle wide addresses. It's known that at least some JIT compilers use higher bits in pointers to encode their information. It

Re: [PATCH V10 00/12] IOMMU probe deferral support

On 04/04/17 18:23, Rob Herring wrote: > On Tue, Apr 4, 2017 at 5:18 AM, Sricharan R wrote: >> This series calls the dma ops configuration for the devices >> at a generic place so that it works for all busses. >> The dma_configure_ops for a device is now called during >>

Re: [PATCH V10 00/12] IOMMU probe deferral support

On 04/04/17 18:23, Rob Herring wrote: > On Tue, Apr 4, 2017 at 5:18 AM, Sricharan R wrote: >> This series calls the dma ops configuration for the devices >> at a generic place so that it works for all busses. >> The dma_configure_ops for a device is now called during >> the device_attach callback

Re: [PATCH v2 5/6] drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension

On Thu, Apr 06, 2017 at 07:33:07PM +0100, Kim Phillips wrote: > On Thu, 6 Apr 2017 17:18:15 +0100 > Will Deacon wrote: > > Hi Will, > > > +/* Perf callbacks */ > > +static int arm_spe_pmu_event_init(struct perf_event *event) > > +{ > > + u64 reg; > > + struct

Re: [PATCH v2 5/6] drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension

On Thu, Apr 06, 2017 at 07:33:07PM +0100, Kim Phillips wrote: > On Thu, 6 Apr 2017 17:18:15 +0100 > Will Deacon wrote: > > Hi Will, > > > +/* Perf callbacks */ > > +static int arm_spe_pmu_event_init(struct perf_event *event) > > +{ > > + u64 reg; > > + struct perf_event_attr *attr = >attr;

Hallo,

Hallo, Mein Name ist Brinda Khaled, ich werde gerne mehr über dich wissen, ich möchte nur meine Ansicht mit dir teilen, wenn es dir nichts ausmacht. Ich werde mehr erzählen, wenn ich von dir antworte. Danke und ich warte auf deine Antwort. Brinda

Hallo,

Hallo, Mein Name ist Brinda Khaled, ich werde gerne mehr über dich wissen, ich möchte nur meine Ansicht mit dir teilen, wenn es dir nichts ausmacht. Ich werde mehr erzählen, wenn ich von dir antworte. Danke und ich warte auf deine Antwort. Brinda

Re: ktest help

On 04/06/2017 12:05 PM, Steven Rostedt wrote: >> > Is there a way I can send a "boot" command after ktest connects to the >> > console? >> > > Not currently, but that is something I've been wanting to add for some > time. So are you saying that ktest depends on the target booting from power-on

Re: ktest help

On 04/06/2017 12:05 PM, Steven Rostedt wrote: >> > Is there a way I can send a "boot" command after ktest connects to the >> > console? >> > > Not currently, but that is something I've been wanting to add for some > time. So are you saying that ktest depends on the target booting from power-on

Re: [PATCH] of: change fixup of dma-ranges size to error

On 04/06/17 07:03, Rob Herring wrote: > On Thu, Apr 6, 2017 at 1:18 AM, wrote: >> From: Frank Rowand >> >> of_dma_get_range() has workaround code to fixup a device tree that >> incorrectly specified a mask instead of a size for property >>

Re: [PATCH] of: change fixup of dma-ranges size to error

On 04/06/17 07:03, Rob Herring wrote: > On Thu, Apr 6, 2017 at 1:18 AM, wrote: >> From: Frank Rowand >> >> of_dma_get_range() has workaround code to fixup a device tree that >> incorrectly specified a mask instead of a size for property >> dma-ranges. That device tree was fixed a year ago in

Re: [PATCH] HID: sony: remove redundant check for -ve err

On Mon, 27 Mar 2017, Colin King wrote: > From: Colin Ian King > > err is being checked for failure each time it is being updated > so this err check is totally redundant and can be removed > > Detected with CoverityScan, CID#1420665 ("Logically dead code") > >

Re: [PATCH] HID: sony: remove redundant check for -ve err

On Mon, 27 Mar 2017, Colin King wrote: > From: Colin Ian King > > err is being checked for failure each time it is being updated > so this err check is totally redundant and can be removed > > Detected with CoverityScan, CID#1420665 ("Logically dead code") > > Signed-off-by: Colin Ian King

Re: [PATCH v3 02/19] HID: logitech-hidpp: Add scope to battery

On Thu, 6 Apr 2017, Benjamin Tissoires wrote: > > > Without a scope defined, UPower assumes that the battery provides > > > power to the computer it's connected to, like a laptop battery or a UPS. > > > > > > Tested-by: Peter Hutterer > > > Signed-off-by: Bastien

Re: [PATCH v3 02/19] HID: logitech-hidpp: Add scope to battery

On Thu, 6 Apr 2017, Benjamin Tissoires wrote: > > > Without a scope defined, UPower assumes that the battery provides > > > power to the computer it's connected to, like a laptop battery or a UPS. > > > > > > Tested-by: Peter Hutterer > > > Signed-off-by: Bastien Nocera > > > Signed-off-by:

Re: [PATCH v2 5/6] drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension

On Thu, 6 Apr 2017 17:18:15 +0100 Will Deacon wrote: Hi Will, > +/* Perf callbacks */ > +static int arm_spe_pmu_event_init(struct perf_event *event) > +{ > + u64 reg; > + struct perf_event_attr *attr = >attr; > + struct arm_spe_pmu *spe_pmu =

Re: [PATCH v2 5/6] drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension

On Thu, 6 Apr 2017 17:18:15 +0100 Will Deacon wrote: Hi Will, > +/* Perf callbacks */ > +static int arm_spe_pmu_event_init(struct perf_event *event) > +{ > + u64 reg; > + struct perf_event_attr *attr = >attr; > + struct arm_spe_pmu *spe_pmu = to_spe_pmu(event->pmu); > + > + /*

Re: [PATCH v2] fault-inject: support systematic fault injection

[Let's add linux-api - please always cc this list when adding/modifying user visible interfaces] On Tue 28-03-17 15:01:28, Dmitry Vyukov wrote: > Add /proc/self/task//fail-nth file that allows failing > 0-th, 1-st, 2-nd and so on calls systematically. > Excerpt from the added documentation: I

Re: [PATCH v2] fault-inject: support systematic fault injection

[Let's add linux-api - please always cc this list when adding/modifying user visible interfaces] On Tue 28-03-17 15:01:28, Dmitry Vyukov wrote: > Add /proc/self/task//fail-nth file that allows failing > 0-th, 1-st, 2-nd and so on calls systematically. > Excerpt from the added documentation: I

Re: [tpmdd-devel] Regression between Linux 3.16 and 4.8/4.9 on Lenovo X60 with coreboot

On 2017-04-06 18:55, Jason Gunthorpe wrote: On Thu, Apr 06, 2017 at 08:18:33AM +0200, Paul Menzel wrote: Indeed, that improves the situation. I still need to pass `force=1` to the module to get `/dev/tpm0`. No idea, why it’s not in included in Linux 4.9 yet. Fair point.. Jarkko - could you

Re: [tpmdd-devel] Regression between Linux 3.16 and 4.8/4.9 on Lenovo X60 with coreboot

On 2017-04-06 18:55, Jason Gunthorpe wrote: On Thu, Apr 06, 2017 at 08:18:33AM +0200, Paul Menzel wrote: Indeed, that improves the situation. I still need to pass `force=1` to the module to get `/dev/tpm0`. No idea, why it’s not in included in Linux 4.9 yet. Fair point.. Jarkko - could you

Re: [PATCH 4.4 23/26] power: reset: at91-poweroff: timely shutdown LPDDR memories

On Thu, 2017-04-06 at 20:13 +0200, Alexandre Belloni wrote: > On 06/04/2017 at 18:45:39 +0100, Ben Hutchings wrote: > > On Thu, 2017-04-06 at 10:38 +0200, Greg Kroah-Hartman wrote: > > > 4.4-stable review patch. If anyone has any objections, please let me > > > know. > > > > > >

Re: [PATCH 4.4 23/26] power: reset: at91-poweroff: timely shutdown LPDDR memories

On Thu, 2017-04-06 at 20:13 +0200, Alexandre Belloni wrote: > On 06/04/2017 at 18:45:39 +0100, Ben Hutchings wrote: > > On Thu, 2017-04-06 at 10:38 +0200, Greg Kroah-Hartman wrote: > > > 4.4-stable review patch. If anyone has any objections, please let me > > > know. > > > > > >

Re: [Patch V2 2/2] x86/mm/numa: remove the numa_nodemask_from_meminfo()

On Thu, Apr 06, 2017 at 08:01:13PM +0200, Borislav Petkov wrote: > On Thu, Apr 06, 2017 at 06:42:16PM +0300, Kirill A. Shutemov wrote: > > Config is attached. > > Thanks! > > > Looks like fake numa is the key. > > ... > > > NUMA: Warning: node ids are out of bound, from=0 to=1 distance=20

Re: [Patch V2 2/2] x86/mm/numa: remove the numa_nodemask_from_meminfo()

On Thu, Apr 06, 2017 at 08:01:13PM +0200, Borislav Petkov wrote: > On Thu, Apr 06, 2017 at 06:42:16PM +0300, Kirill A. Shutemov wrote: > > Config is attached. > > Thanks! > > > Looks like fake numa is the key. > > ... > > > NUMA: Warning: node ids are out of bound, from=0 to=1 distance=20

Re: [PATCH v3] regulator: Add driver for voltage controlled regulators

On Fri, Mar 31, 2017 at 01:50:35PM -0700, Matthias Kaehlcke wrote: > +- compatible : must be "vctrl-regulator". > +- regulator-min-microvolt : smallest voltage consumers may set > +- regulator-max-microvolt : largest voltage consumers may set > +- ctrl-regulator: : the name of the

Re: [PATCH v3] regulator: Add driver for voltage controlled regulators

On Fri, Mar 31, 2017 at 01:50:35PM -0700, Matthias Kaehlcke wrote: > +- compatible : must be "vctrl-regulator". > +- regulator-min-microvolt : smallest voltage consumers may set > +- regulator-max-microvolt : largest voltage consumers may set > +- ctrl-regulator: : the name of the

Re: [PATCH 4.4 25/26] blk: Ensure users for current->bio_list can see the full list.

On Thu, 2017-04-06 at 10:38 +0200, Greg Kroah-Hartman wrote: > 4.4-stable review patch. If anyone has any objections, please let me know. > > -- > > From: NeilBrown > > commit f5fe1b51905df7cfe4fdfd85c5fb7bc5b71a094f upstream. > > Commit 79bd99596b73 ("blk:

Re: [PATCH 4.4 25/26] blk: Ensure users for current->bio_list can see the full list.

On Thu, 2017-04-06 at 10:38 +0200, Greg Kroah-Hartman wrote: > 4.4-stable review patch. If anyone has any objections, please let me know. > > -- > > From: NeilBrown > > commit f5fe1b51905df7cfe4fdfd85c5fb7bc5b71a094f upstream. > > Commit 79bd99596b73 ("blk: improve order of

Re: [PATCH 4.4 23/26] power: reset: at91-poweroff: timely shutdown LPDDR memories

On 06/04/2017 at 18:45:39 +0100, Ben Hutchings wrote: > On Thu, 2017-04-06 at 10:38 +0200, Greg Kroah-Hartman wrote: > > 4.4-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: Alexandre Belloni >

Re: [PATCH 4.4 23/26] power: reset: at91-poweroff: timely shutdown LPDDR memories

On 06/04/2017 at 18:45:39 +0100, Ben Hutchings wrote: > On Thu, 2017-04-06 at 10:38 +0200, Greg Kroah-Hartman wrote: > > 4.4-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: Alexandre Belloni > > > > commit

Re: [PATCH 1/4] ftrace: Add use of synchronize_rcu_tasks() with dynamic trampolines

On Thu, 6 Apr 2017 11:05:53 -0700 "Paul E. McKenney" wrote: > On Thu, Apr 06, 2017 at 12:42:38PM -0400, Steven Rostedt wrote: > > From: "Steven Rostedt (VMware)" > > > > The function tracer needs to be more careful than other subsystems when it

Re: [PATCH 1/4] ftrace: Add use of synchronize_rcu_tasks() with dynamic trampolines

On Thu, 6 Apr 2017 11:05:53 -0700 "Paul E. McKenney" wrote: > On Thu, Apr 06, 2017 at 12:42:38PM -0400, Steven Rostedt wrote: > > From: "Steven Rostedt (VMware)" > > > > The function tracer needs to be more careful than other subsystems when it > > comes to freeing data. Especially if that

Re: N900 failure in next-20170321

On Tue 2017-03-21 08:38:52, Tony Lindgren wrote: > * Pavel Machek [170321 06:59]: > > Hi! > > > > Tony asked me to test linux-next from time to time. I did... today I > > moved from next-20170309 to next-20170321. Kernel boots and seems to > > work fine (including audio and X

Re: N900 failure in next-20170321

On Tue 2017-03-21 08:38:52, Tony Lindgren wrote: > * Pavel Machek [170321 06:59]: > > Hi! > > > > Tony asked me to test linux-next from time to time. I did... today I > > moved from next-20170309 to next-20170321. Kernel boots and seems to > > work fine (including audio and X startup), but if I

Re: [PATCH 3/4] tracing: Add stack_tracer_disable/enable() functions

On Thu, Apr 06, 2017 at 12:42:40PM -0400, Steven Rostedt wrote: > From: "Steven Rostedt (VMware)" > > There are certain parts of the kernel that can not let stack tracing > proceed (namely in RCU), because the stack tracer uses RCU, and parts of RCU > internals can not

Re: [PATCH 3/4] tracing: Add stack_tracer_disable/enable() functions

On Thu, Apr 06, 2017 at 12:42:40PM -0400, Steven Rostedt wrote: > From: "Steven Rostedt (VMware)" > > There are certain parts of the kernel that can not let stack tracing > proceed (namely in RCU), because the stack tracer uses RCU, and parts of RCU > internals can not handle having RCU read

Re: [PATCH v23 09/11] acpi/arm64: Add memory-mapped timer support in GTDT driver

Hi Mark, On 7 April 2017 at 01:52, Mark Rutland wrote: > On Fri, Apr 07, 2017 at 01:39:09AM +0800, Fu Wei wrote: >> On 7 April 2017 at 01:24, Mark Rutland wrote: >> > On Fri, Apr 07, 2017 at 12:47:47AM +0800, Fu Wei wrote: >> >> On 6 April 2017 at

Re: [PATCH v23 09/11] acpi/arm64: Add memory-mapped timer support in GTDT driver

Hi Mark, On 7 April 2017 at 01:52, Mark Rutland wrote: > On Fri, Apr 07, 2017 at 01:39:09AM +0800, Fu Wei wrote: >> On 7 April 2017 at 01:24, Mark Rutland wrote: >> > On Fri, Apr 07, 2017 at 12:47:47AM +0800, Fu Wei wrote: >> >> On 6 April 2017 at 02:38, Mark Rutland wrote: >> >> > On Sat, Apr

Re: [PATCH 1/4] ftrace: Add use of synchronize_rcu_tasks() with dynamic trampolines

On Thu, Apr 06, 2017 at 12:42:38PM -0400, Steven Rostedt wrote: > From: "Steven Rostedt (VMware)" > > The function tracer needs to be more careful than other subsystems when it > comes to freeing data. Especially if that data is actually executable code. > When a single

Re: [PATCH 1/4] ftrace: Add use of synchronize_rcu_tasks() with dynamic trampolines

On Thu, Apr 06, 2017 at 12:42:38PM -0400, Steven Rostedt wrote: > From: "Steven Rostedt (VMware)" > > The function tracer needs to be more careful than other subsystems when it > comes to freeing data. Especially if that data is actually executable code. > When a single function is traced, a

[PATCH v3 7/9] ARM: dts: imx6dl-icore: Add touchscreen node

From: Jagan Teki max11801 touchscreen on Engicam iCoreM6 DualLite/Solo module is connected via i2c1, so add max11801: touchscreen@48 on i2c1. Cc: Shawn Guo Cc: Matteo Lisi Cc: Michael Trimarchi

[PATCH v3 7/9] ARM: dts: imx6dl-icore: Add touchscreen node

From: Jagan Teki max11801 touchscreen on Engicam iCoreM6 DualLite/Solo module is connected via i2c1, so add max11801: touchscreen@48 on i2c1. Cc: Shawn Guo Cc: Matteo Lisi Cc: Michael Trimarchi Signed-off-by: Jagan Teki --- Changes for v3,v2: - none arch/arm/boot/dts/imx6dl-icore.dts | 9

[PATCH v3 5/9] ARM: dts: imx6qdl-icore-rqs: Replace to use simple-audio-card

From: Jagan Teki This patch replace fsl,imx-audio-sgtl5000 and use simple-audio-card for Engicam i.CoreM6 RQS QDL platform boards. Cc: Shawn Guo Cc: Matteo Lisi Cc: Michael Trimarchi

[PATCH v3 5/9] ARM: dts: imx6qdl-icore-rqs: Replace to use simple-audio-card

From: Jagan Teki This patch replace fsl,imx-audio-sgtl5000 and use simple-audio-card for Engicam i.CoreM6 RQS QDL platform boards. Cc: Shawn Guo Cc: Matteo Lisi Cc: Michael Trimarchi Signed-off-by: Jagan Teki --- Changes for v3: - Newly added patch arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi

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