[PATCH 1/2] Input: nspire-keypad: Delete an error message for a failed memory allocation in nspire_keypad_probe()

From: Markus Elfring Date: Sat, 27 Jan 2018 10:33:37 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH 1/2] Input: nspire-keypad: Delete an error message for a failed memory allocation in nspire_keypad_probe()

From: Markus Elfring Date: Sat, 27 Jan 2018 10:33:37 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/input/keyboard/nspire-keypad.c | 4 +--- 1 file changed, 1

[PATCH 0/2] Input: nspire-keypad: Adjustments for nspire_keypad_probe()

From: Markus Elfring Date: Sat, 27 Jan 2018 10:48:28 +0100 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an error message for a failed memory allocation Improve a size determination

[PATCH 0/2] Input: nspire-keypad: Adjustments for nspire_keypad_probe()

From: Markus Elfring Date: Sat, 27 Jan 2018 10:48:28 +0100 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an error message for a failed memory allocation Improve a size determination drivers/input/keyboard/nspire-keypad.c | 7

[PATCH 8/8] staging: pi433: fix CamelCase for DIONumber

Fixes checkpatch warnings: CHECK: Avoid CamelCase: Signed-off-by: Valentin Vidic --- drivers/staging/pi433/rf69.c | 4 ++-- drivers/staging/pi433/rf69.h | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/pi433/rf69.c

[PATCH 7/8] staging: pi433: fix CamelCase for regValue

Local variable storing the new value for dio register so replace with dio_value. Update regaddr to dio_addr to match. Fixes checkpatch warnings: CHECK: Avoid CamelCase: Signed-off-by: Valentin Vidic --- drivers/staging/pi433/rf69.c | 24

[PATCH 7/8] staging: pi433: fix CamelCase for regValue

Local variable storing the new value for dio register so replace with dio_value. Update regaddr to dio_addr to match. Fixes checkpatch warnings: CHECK: Avoid CamelCase: Signed-off-by: Valentin Vidic --- drivers/staging/pi433/rf69.c | 24 1 file changed, 12

[PATCH 8/8] staging: pi433: fix CamelCase for DIONumber

Fixes checkpatch warnings: CHECK: Avoid CamelCase: Signed-off-by: Valentin Vidic --- drivers/staging/pi433/rf69.c | 4 ++-- drivers/staging/pi433/rf69.h | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c index

[PATCH 6/8] staging: pi433: fix CamelCase for newValue

Local variable storing the new value for bandwidth register so replace with bandwidth. Fixes checkpatch warnings: CHECK: Avoid CamelCase: Signed-off-by: Valentin Vidic --- drivers/staging/pi433/rf69.c | 16 1 file changed, 8 insertions(+), 8

[PATCH 6/8] staging: pi433: fix CamelCase for newValue

Local variable storing the new value for bandwidth register so replace with bandwidth. Fixes checkpatch warnings: CHECK: Avoid CamelCase: Signed-off-by: Valentin Vidic --- drivers/staging/pi433/rf69.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git

[PATCH 5/8] staging: pi433: fix CamelCase for currentValue

Local variable storing the value for modulation register so replace with modulation_reg. Fixes checkpatch warnings: CHECK: Avoid CamelCase: Signed-off-by: Valentin Vidic --- drivers/staging/pi433/rf69.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)

[PATCH 5/8] staging: pi433: fix CamelCase for currentValue

Local variable storing the value for modulation register so replace with modulation_reg. Fixes checkpatch warnings: CHECK: Avoid CamelCase: Signed-off-by: Valentin Vidic --- drivers/staging/pi433/rf69.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

[PATCH 1/2] f2fs: enhance scalibility of {d,id,did,x}node disk layout

Scalibility of non-inode disk layout is very bad, it's hard to add or reuse any fields in current structure, so, for new feature like node checksum which wants to add 4 bytes field in node structure, the bad scaliblity becomes a obstacle for its implementation. In order to enhance scalibility, we

[PATCH 1/2] f2fs: enhance scalibility of {d,id,did,x}node disk layout

Scalibility of non-inode disk layout is very bad, it's hard to add or reuse any fields in current structure, so, for new feature like node checksum which wants to add 4 bytes field in node structure, the bad scaliblity becomes a obstacle for its implementation. In order to enhance scalibility, we

[PATCH 4/8] staging: pi433: fix CamelCase for Ohm identifiers

Fixes checkpatch warnings: CHECK: Avoid CamelCase: CHECK: Avoid CamelCase: Signed-off-by: Valentin Vidic --- drivers/staging/pi433/Documentation/pi433.txt | 4 ++-- drivers/staging/pi433/pi433_if.c | 2 +- drivers/staging/pi433/rf69.c

[PATCH 3/8] staging: pi433: fix CamelCase for antennaImpedance

Fixes checkpatch warnings: CHECK: Avoid CamelCase: Signed-off-by: Valentin Vidic --- drivers/staging/pi433/Documentation/pi433.txt | 2 +- drivers/staging/pi433/pi433_if.h | 2 +- drivers/staging/pi433/rf69.c | 4 ++--

[PATCH 4/8] staging: pi433: fix CamelCase for Ohm identifiers

Fixes checkpatch warnings: CHECK: Avoid CamelCase: CHECK: Avoid CamelCase: Signed-off-by: Valentin Vidic --- drivers/staging/pi433/Documentation/pi433.txt | 4 ++-- drivers/staging/pi433/pi433_if.c | 2 +- drivers/staging/pi433/rf69.c | 4 ++--

[PATCH 3/8] staging: pi433: fix CamelCase for antennaImpedance

Fixes checkpatch warnings: CHECK: Avoid CamelCase: Signed-off-by: Valentin Vidic --- drivers/staging/pi433/Documentation/pi433.txt | 2 +- drivers/staging/pi433/pi433_if.h | 2 +- drivers/staging/pi433/rf69.c | 4 ++-- drivers/staging/pi433/rf69.h

[PATCH 1/8] staging: pi433: fix CamelCase for syncValues

Fixes checkpatch warnings: CHECK: Avoid CamelCase: Signed-off-by: Valentin Vidic --- drivers/staging/pi433/rf69.c | 18 +- drivers/staging/pi433/rf69.h | 2 +- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git

[PATCH 2/2] f2fs: support {d,id,did,x}node checksum

This patch adds to support {d,id,did,x}node checksum in kernel side. Signed-off-by: Chao Yu --- fs/f2fs/f2fs.h | 15 +++- fs/f2fs/inode.c | 98 +++-- fs/f2fs/node.c | 2 +- fs/f2fs/segment.c |

[PATCH 2/2] f2fs: support {d,id,did,x}node checksum

This patch adds to support {d,id,did,x}node checksum in kernel side. Signed-off-by: Chao Yu --- fs/f2fs/f2fs.h | 15 +++- fs/f2fs/inode.c | 98 +++-- fs/f2fs/node.c | 2 +- fs/f2fs/segment.c | 2 +-

[PATCH 1/8] staging: pi433: fix CamelCase for syncValues

Fixes checkpatch warnings: CHECK: Avoid CamelCase: Signed-off-by: Valentin Vidic --- drivers/staging/pi433/rf69.c | 18 +- drivers/staging/pi433/rf69.h | 2 +- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/staging/pi433/rf69.c

[PATCH 2/8] staging: pi433: fix CamelCase for powerLevel

Fixes checkpatch warnings: CHECK: Avoid CamelCase: Signed-off-by: Valentin Vidic --- drivers/staging/pi433/rf69.c | 8 drivers/staging/pi433/rf69.h | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/staging/pi433/rf69.c

[PATCH 2/8] staging: pi433: fix CamelCase for powerLevel

Fixes checkpatch warnings: CHECK: Avoid CamelCase: Signed-off-by: Valentin Vidic --- drivers/staging/pi433/rf69.c | 8 drivers/staging/pi433/rf69.h | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c

Re: [PATCH v3] perf/trace : Fix repetitious traces of perf on tracepoint

Hi, Milian On 2018/1/16 22:33, Milian Wolff wrote: perf script print the same wakeup_new event multiple times. These events which trigger this issue all specify a target process. commit e6dab5ffab59 ("perf/trace: Add ability to set a target task for events") has designed a method to trace

Re: [PATCH v3] perf/trace : Fix repetitious traces of perf on tracepoint

Hi, Milian On 2018/1/16 22:33, Milian Wolff wrote: perf script print the same wakeup_new event multiple times. These events which trigger this issue all specify a target process. commit e6dab5ffab59 ("perf/trace: Add ability to set a target task for events") has designed a method to trace

Re: [PATCH] x86/cpufeatures: Cleanup AMD speculation feature bits

On Sat, Jan 27, 2018 at 09:27:48AM +, David Woodhouse wrote: > http://david.woodhou.se/cleanup-feature-bits.patch on top of my full > tree? @@ -223,7 +223,7 @@ static inline void indirect_branch_prediction_barrier(void) "movl %[val], %%eax\n\t"

Re: [PATCH v2 2/5] powerpc/32: Fix hugepage allocation on 8xx at hint address

"Aneesh Kumar K.V" writes: > Christophe Leroy writes: > >> On the 8xx, the page size is set in the PMD entry and applies to >> all pages of the page table pointed by the said PMD entry. >> ... >> diff --git

Re: [PATCH v2 2/5] powerpc/32: Fix hugepage allocation on 8xx at hint address

"Aneesh Kumar K.V" writes: > Christophe Leroy writes: > >> On the 8xx, the page size is set in the PMD entry and applies to >> all pages of the page table pointed by the said PMD entry. >> ... >> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c >> index

Re: [PATCH] x86/cpufeatures: Cleanup AMD speculation feature bits

On Sat, Jan 27, 2018 at 09:27:48AM +, David Woodhouse wrote: > http://david.woodhou.se/cleanup-feature-bits.patch on top of my full > tree? @@ -223,7 +223,7 @@ static inline void indirect_branch_prediction_barrier(void) "movl %[val], %%eax\n\t"

CMA allocation failure

Hello, I enabled CMA global area to be 8GB. Immediately after boot, I'm able to allocate the really big contiguous chunks of memory (about 8GB). But several minutes after the boot, there is some degradation in an ability of CMA to allocate contiguous memory buffers: [ 2333.037004] cma:

CMA allocation failure

Hello, I enabled CMA global area to be 8GB. Immediately after boot, I'm able to allocate the really big contiguous chunks of memory (about 8GB). But several minutes after the boot, there is some degradation in an ability of CMA to allocate contiguous memory buffers: [ 2333.037004] cma:

Re: [RFC PATCH V5 5/5] workqueue: introduce a way to set workqueue's scheduler

On Sat, 2018-01-27 at 13:15 +0800, Wen Yang wrote: > When pinning RT threads to specific cores using CPU affinity, the > kworkers on the same CPU would starve, which may lead to some kind > of priority inversion. In that case, the RT threads would also > suffer high performance impact. ... >

Re: [RFC PATCH V5 5/5] workqueue: introduce a way to set workqueue's scheduler

On Sat, 2018-01-27 at 13:15 +0800, Wen Yang wrote: > When pinning RT threads to specific cores using CPU affinity, the > kworkers on the same CPU would starve, which may lead to some kind > of priority inversion. In that case, the RT threads would also > suffer high performance impact. ... >

[PATCH 1/2] f2fs: restrict inline_xattr_size configuration

This patch limits to enable inline_xattr_size mount option only if both extra_attr and flexible_inline_xattr feature is on in current image. Signed-off-by: Chao Yu --- fs/f2fs/super.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/fs/f2fs/super.c

[PATCH 1/2] f2fs: restrict inline_xattr_size configuration

This patch limits to enable inline_xattr_size mount option only if both extra_attr and flexible_inline_xattr feature is on in current image. Signed-off-by: Chao Yu --- fs/f2fs/super.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c index

[PATCH 2/2] f2fs: fix to check extent cache in f2fs_drop_extent_tree

If noextent_cache mount option is on, we will never initialize extent tree in inode, but still we're going to access it in f2fs_drop_extent_tree, result in kernel panic as below: BUG: unable to handle kernel NULL pointer dereference at 0038 IP: _raw_write_lock+0xc/0x30 Call Trace:

[PATCH 2/2] f2fs: fix to check extent cache in f2fs_drop_extent_tree

If noextent_cache mount option is on, we will never initialize extent tree in inode, but still we're going to access it in f2fs_drop_extent_tree, result in kernel panic as below: BUG: unable to handle kernel NULL pointer dereference at 0038 IP: _raw_write_lock+0xc/0x30 Call Trace:

Re: [PATCH] x86/cpufeatures: Cleanup AMD speculation feature bits

http://david.woodhou.se/cleanup-feature-bits.patch on top of my full tree? I'll rework that into the series instead of as a patch on top... smime.p7s Description: S/MIME cryptographic signature

Re: [PATCH] x86/cpufeatures: Cleanup AMD speculation feature bits

http://david.woodhou.se/cleanup-feature-bits.patch on top of my full tree? I'll rework that into the series instead of as a patch on top... smime.p7s Description: S/MIME cryptographic signature

Re: [PATCH v2 12/13] ocxl: Documentation

Frederic Barrat writes: > Le 25/01/2018 à 14:17, Greg KH a écrit : >> On Tue, Jan 23, 2018 at 12:31:47PM +0100, Frederic Barrat wrote: >>> ocxl.rst gives a quick, high-level view of opencapi. >>> >>> Update ioctl-number.txt to reflect ioctl numbers being used by the

Re: [PATCH v2 12/13] ocxl: Documentation

Frederic Barrat writes: > Le 25/01/2018 à 14:17, Greg KH a écrit : >> On Tue, Jan 23, 2018 at 12:31:47PM +0100, Frederic Barrat wrote: >>> ocxl.rst gives a quick, high-level view of opencapi. >>> >>> Update ioctl-number.txt to reflect ioctl numbers being used by the >>> ocxl driver >>> >>>

Re: [PATCH v2 1/2] x86/retpoline: Simplify vmexit_fill_RSB()

On Fri, Jan 26, 2018 at 11:20:39PM -0500, Konrad Rzeszutek Wilk wrote: > BOINK? > > Really? There's always someone who's bound to get offended, right? So I better change it to something boring, yes? -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the

Re: [PATCH v2 1/2] x86/retpoline: Simplify vmexit_fill_RSB()

On Fri, Jan 26, 2018 at 11:20:39PM -0500, Konrad Rzeszutek Wilk wrote: > BOINK? > > Really? There's always someone who's bound to get offended, right? So I better change it to something boring, yes? -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the

[PATCH v2 1/3] KVM: nVMX: Eliminate vmcs02 pool

From: Jim Mattson The potential performance advantages of a vmcs02 pool have never been realized. To simplify the code, eliminate the pool. Instead, a single vmcs02 is allocated per VCPU when the VCPU enters VMX operation. Signed-off-by: Jim Mattson

[PATCH v2 1/3] KVM: nVMX: Eliminate vmcs02 pool

From: Jim Mattson The potential performance advantages of a vmcs02 pool have never been realized. To simplify the code, eliminate the pool. Instead, a single vmcs02 is allocated per VCPU when the VCPU enters VMX operation. Signed-off-by: Jim Mattson Signed-off-by: Mark Kanda Reviewed-by:

[PATCH v2 3/3] KVM: VMX: make MSR bitmaps per-VCPU

Place the MSR bitmap in struct loaded_vmcs, and update it in place every time the x2apic or APICv state can change. This is rare and the loop can handle 64 MSRs per iteration, in a similar fashion as nested_vmx_prepare_msr_bitmap. This prepares for choosing, on a per-VM basis, whether to

[PATCH v2 3/3] KVM: VMX: make MSR bitmaps per-VCPU

Place the MSR bitmap in struct loaded_vmcs, and update it in place every time the x2apic or APICv state can change. This is rare and the loop can handle 64 MSRs per iteration, in a similar fashion as nested_vmx_prepare_msr_bitmap. This prepares for choosing, on a per-VM basis, whether to

[PATCH v2 2/3] KVM: VMX: introduce alloc_loaded_vmcs

Group together the calls to alloc_vmcs and loaded_vmcs_init. Soon we'll also allocate an MSR bitmap there. Signed-off-by: Paolo Bonzini --- arch/x86/kvm/vmx.c | 36 ++-- 1 file changed, 22 insertions(+), 14 deletions(-) diff --git

[PATCH v2 0/3] Per-VCPU MSR bitmaps patches - topic branch for x86/pti

David and others, the following changes since commit ba804bb4b72e57374b5f567b783aa0298fba0ce6: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2018-01-26 09:03:16 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/kvm.git msr-bitmaps for

[PATCH v2 2/3] KVM: VMX: introduce alloc_loaded_vmcs

Group together the calls to alloc_vmcs and loaded_vmcs_init. Soon we'll also allocate an MSR bitmap there. Signed-off-by: Paolo Bonzini --- arch/x86/kvm/vmx.c | 36 ++-- 1 file changed, 22 insertions(+), 14 deletions(-) diff --git a/arch/x86/kvm/vmx.c

[PATCH v2 0/3] Per-VCPU MSR bitmaps patches - topic branch for x86/pti

David and others, the following changes since commit ba804bb4b72e57374b5f567b783aa0298fba0ce6: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2018-01-26 09:03:16 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/kvm.git msr-bitmaps for

Re: [PATCH] x86/cpufeatures: Cleanup AMD speculation feature bits

On Fri, 2018-01-26 at 17:14 -0600, Tom Lendacky wrote: > On 1/26/2018 4:10 PM, Borislav Petkov wrote: > > > > On Fri, Jan 26, 2018 at 09:59:44PM +, David Woodhouse wrote: > > > > > > If we wanted to do this kind of thing, we'd do it the other way round. > > > Turn the *Intel* feature into

Re: [PATCH] x86/cpufeatures: Cleanup AMD speculation feature bits

On Fri, 2018-01-26 at 17:14 -0600, Tom Lendacky wrote: > On 1/26/2018 4:10 PM, Borislav Petkov wrote: > > > > On Fri, Jan 26, 2018 at 09:59:44PM +, David Woodhouse wrote: > > > > > > If we wanted to do this kind of thing, we'd do it the other way round. > > > Turn the *Intel* feature into

Re: [PATCH 0/3] Per-VCPU MSR bitmaps patches - topic branch for x86/pti

On 26/01/2018 23:51, Paolo Bonzini wrote: > David and others, > > the following changes since commit ba804bb4b72e57374b5f567b783aa0298fba0ce6: > > Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2018-01-26 > 09:03:16 -0800) > > are available in the git repository at: > >

Re: [PATCH 0/3] Per-VCPU MSR bitmaps patches - topic branch for x86/pti

On 26/01/2018 23:51, Paolo Bonzini wrote: > David and others, > > the following changes since commit ba804bb4b72e57374b5f567b783aa0298fba0ce6: > > Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2018-01-26 > 09:03:16 -0800) > > are available in the git repository at: > >

Re: [RFC PATCH 0/2] check I2C device id for pca984x chips

On 2018-01-26 17:33, Adrian Fiergolski wrote: > Hi Peter, > > Sorry for the late reply. No problem. > Yes, it's true I have one of the chip. However, my yocto based build system > depends on https://github.com/Xilinx/linux-xlnx and it's in version > 4.9.0-xilinx-v2017.3. > Apparently, there

Re: [RFC PATCH 0/2] check I2C device id for pca984x chips

On 2018-01-26 17:33, Adrian Fiergolski wrote: > Hi Peter, > > Sorry for the late reply. No problem. > Yes, it's true I have one of the chip. However, my yocto based build system > depends on https://github.com/Xilinx/linux-xlnx and it's in version > 4.9.0-xilinx-v2017.3. > Apparently, there

[PATCH] usb: musb: fix enumeration after resume

On dm3730 there are enumeration problems after resume. Investigation led to the cause that the MUSB_POWER_SOFTCONN bit is not set. If it was set before suspend (because it was enabled via musb_pullup()), it is set in musb_restore_context() so the pullup is enabled. But then musb_start() is called

[PATCH] usb: musb: fix enumeration after resume

On dm3730 there are enumeration problems after resume. Investigation led to the cause that the MUSB_POWER_SOFTCONN bit is not set. If it was set before suspend (because it was enabled via musb_pullup()), it is set in musb_restore_context() so the pullup is enabled. But then musb_start() is called

Re: [lkp-robot] [x86/kasan] def0e7b54d: Kernel_panic-not_syncing:memblock_virt_alloc_try_nid:Failed_to_allocate#by tes_align=#nid=#from=#max_addr=

On Sat, 27 Jan 2018, kernel test robot wrote: > Hi, Andrey > > Is this panic log expected with your commit? Yes it is. It says that there is not enough memroy to run with KASAN. If you revert it the machine will die with a NULL pointer dereference at some other place w/o telling you what the

Re: [lkp-robot] [x86/kasan] def0e7b54d: Kernel_panic-not_syncing:memblock_virt_alloc_try_nid:Failed_to_allocate#by tes_align=#nid=#from=#max_addr=

On Sat, 27 Jan 2018, kernel test robot wrote: > Hi, Andrey > > Is this panic log expected with your commit? Yes it is. It says that there is not enough memroy to run with KASAN. If you revert it the machine will die with a NULL pointer dereference at some other place w/o telling you what the

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On Fri, Jan 26, 2018 at 09:19:09AM -0800, Linus Torvalds wrote: > But did we do that "disable stuffing with SMEP"? I'm not seeing it. In > my tree, it's only conditional on X86_FEATURE_RETPOLINE. Or rather, enable stuffing on !SMEP: + if ((!boot_cpu_has(X86_FEATURE_PTI) && +

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On Fri, Jan 26, 2018 at 09:19:09AM -0800, Linus Torvalds wrote: > But did we do that "disable stuffing with SMEP"? I'm not seeing it. In > my tree, it's only conditional on X86_FEATURE_RETPOLINE. Or rather, enable stuffing on !SMEP: + if ((!boot_cpu_has(X86_FEATURE_PTI) && +

[PATCH v2] block: paride: on26: Replace mdelay with msleep in on26_test_port

on26_test_port() is never called from atomic context. It has no direct callers and it is called only via function pointer "->test_port" that is only used in pi_probe_unit(): drivers/block/paride/paride.c:322: max = pi->proto->test_port(pi); That gets called only from pi_init(), called from

[PATCH v2] block: paride: on26: Replace mdelay with msleep in on26_test_port

on26_test_port() is never called from atomic context. It has no direct callers and it is called only via function pointer "->test_port" that is only used in pi_probe_unit(): drivers/block/paride/paride.c:322: max = pi->proto->test_port(pi); That gets called only from pi_init(), called from

Re: [PATCH v3 1/2] iio: adc: driver for ti adc081s/adc101s/adc121s

On 01/26/2018 07:43 PM, Andy Shevchenko wrote: On Fri, Jan 26, 2018 at 8:25 PM, Lars-Peter Clausen wrote: On 01/26/2018 07:19 PM, Andy Shevchenko wrote: On Sun, Jan 14, 2018 at 10:32 PM, Milan Stevanovic wrote: Add Linux device driver for

Re: [PATCH v3 1/2] iio: adc: driver for ti adc081s/adc101s/adc121s

On 01/26/2018 07:43 PM, Andy Shevchenko wrote: On Fri, Jan 26, 2018 at 8:25 PM, Lars-Peter Clausen wrote: On 01/26/2018 07:19 PM, Andy Shevchenko wrote: On Sun, Jan 14, 2018 at 10:32 PM, Milan Stevanovic wrote: Add Linux device driver for TI single-channel CMOS 8/10/12-bit

Re: [PATCH v2 1/6] resource: Extend the PPC32 reserved memory hack

On Wed, Jan 24, 2018 at 12:23:05PM +1100, Michael Ellerman wrote: > Jonathan Neuschäfer writes: [...] > > Do you have any pointer on how to implement discontiguous memory > > support? CONFIG_ARCH_SPARSEMEM_ENABLE seems relevant. > > I'm not really sure what the key

Re: [PATCH v2 1/6] resource: Extend the PPC32 reserved memory hack

On Wed, Jan 24, 2018 at 12:23:05PM +1100, Michael Ellerman wrote: > Jonathan Neuschäfer writes: [...] > > Do you have any pointer on how to implement discontiguous memory > > support? CONFIG_ARCH_SPARSEMEM_ENABLE seems relevant. > > I'm not really sure what the key impediment to it working is. >

[lkp-robot] [x86/kasan] def0e7b54d: Kernel_panic-not_syncing:memblock_virt_alloc_try_nid:Failed_to_allocate#bytes_align=#nid=#from=#max_addr=

Hi, Andrey Is this panic log expected with your commit? FYI, we noticed the following commit (built with gcc-7): commit: def0e7b54d63bae120302a4957c272107563ad04 ("x86/kasan: Panic if there is not enough memory to boot") https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git x86/pti in

[lkp-robot] [x86/kasan] def0e7b54d: Kernel_panic-not_syncing:memblock_virt_alloc_try_nid:Failed_to_allocate#bytes_align=#nid=#from=#max_addr=

Hi, Andrey Is this panic log expected with your commit? FYI, we noticed the following commit (built with gcc-7): commit: def0e7b54d63bae120302a4957c272107563ad04 ("x86/kasan: Panic if there is not enough memory to boot") https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git x86/pti in

<    1   2   3   4