Re: [PATCH] driver core: Make it safe to use get_device() if the reference count is zero

On 2017/12/14 15:42, Greg KH wrote: On Thu, Dec 14, 2017 at 11:39:36AM +0800, Jason Yan wrote: Some driviers may have the chance to increase a reference count that has dropped to zero when using get_device() because of their design. Then those drivers are broken :) We have met such a issue

Re: [PATCH] driver core: Make it safe to use get_device() if the reference count is zero

On 2017/12/14 15:42, Greg KH wrote: On Thu, Dec 14, 2017 at 11:39:36AM +0800, Jason Yan wrote: Some driviers may have the chance to increase a reference count that has dropped to zero when using get_device() because of their design. Then those drivers are broken :) We have met such a issue

Re: [PATCH 4.14 000/164] 4.14.6-stable review

On Tue, Dec 12, 2017 at 06:47:33PM -0800, Guenter Roeck wrote: > On 12/12/2017 04:43 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.6 release. > > There are 164 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 4.14 000/164] 4.14.6-stable review

On Tue, Dec 12, 2017 at 06:47:33PM -0800, Guenter Roeck wrote: > On 12/12/2017 04:43 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.6 release. > > There are 164 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 4.9 000/148] 4.9.69-stable review

On Tue, Dec 12, 2017 at 05:30:42PM -0700, Nathan Chancellor wrote: > On Tue, Dec 12, 2017 at 04:22:36PM -0800, Guenter Roeck wrote: > > On 12/12/2017 04:43 AM, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 4.9.69 release. > > > There are 148 patches in this

Re: [PATCH 4.9 000/148] 4.9.69-stable review

On Tue, Dec 12, 2017 at 05:30:42PM -0700, Nathan Chancellor wrote: > On Tue, Dec 12, 2017 at 04:22:36PM -0800, Guenter Roeck wrote: > > On 12/12/2017 04:43 AM, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 4.9.69 release. > > > There are 148 patches in this

Re: [PATCH 4.9 000/148] 4.9.69-stable review

On Wed, Dec 13, 2017 at 05:28:44PM +0530, Naresh Kamboju wrote: > On 12 December 2017 at 18:13, Greg Kroah-Hartman > wrote: > > This is the start of the stable review cycle for the 4.9.69 release. > > There are 148 patches in this series, all will be posted as a

Re: [PATCH 4.9 000/148] 4.9.69-stable review

On Wed, Dec 13, 2017 at 05:28:44PM +0530, Naresh Kamboju wrote: > On 12 December 2017 at 18:13, Greg Kroah-Hartman > wrote: > > This is the start of the stable review cycle for the 4.9.69 release. > > There are 148 patches in this series, all will be posted as a response > > to this one. If

Re: [PATCH] hyperv: make HYPERV a menuconfig to ease disabling it all

On Wed, Dec 13, 2017 at 01:23:38PM -0800, Stephen Hemminger wrote: > On Wed, 13 Dec 2017 09:54:19 +0100 > Vincent Legoll wrote: > > > Hello, > > > > On Sun, Dec 10, 2017 at 6:50 AM, Stephen Hemminger > > wrote: > > > Will this break

Re: [PATCH] hyperv: make HYPERV a menuconfig to ease disabling it all

On Wed, Dec 13, 2017 at 01:23:38PM -0800, Stephen Hemminger wrote: > On Wed, 13 Dec 2017 09:54:19 +0100 > Vincent Legoll wrote: > > > Hello, > > > > On Sun, Dec 10, 2017 at 6:50 AM, Stephen Hemminger > > wrote: > > > Will this break existing configs? > > > > I don't think so. Last time I

Re: [RFC PATCH 4/5] mm, hugetlb: get rid of surplus page accounting tricks

On Wed 13-12-17 16:45:55, Mike Kravetz wrote: > On 12/04/2017 06:01 AM, Michal Hocko wrote: > > From: Michal Hocko > > > > alloc_surplus_huge_page increases the pool size and the number of > > surplus pages opportunistically to prevent from races with the pool size > > change.

Re: [RFC PATCH 4/5] mm, hugetlb: get rid of surplus page accounting tricks

On Wed 13-12-17 16:45:55, Mike Kravetz wrote: > On 12/04/2017 06:01 AM, Michal Hocko wrote: > > From: Michal Hocko > > > > alloc_surplus_huge_page increases the pool size and the number of > > surplus pages opportunistically to prevent from races with the pool size > > change. See d1c3fb1f8f29

[PATCH v8 2/2] mtd: nand: Add support for Arasan NAND Flash Controller

Added the basic driver for Arasan NAND Flash Controller used in Zynq UltraScale+ MPSoC. It supports only Hw ECC and upto 24bit correction. Signed-off-by: Naga Sureshkumar Relli Signed-off-by: Punnaiah Choudary Kalluri --- Changes in v8: - Implemented

[PATCH v8 2/2] mtd: nand: Add support for Arasan NAND Flash Controller

Added the basic driver for Arasan NAND Flash Controller used in Zynq UltraScale+ MPSoC. It supports only Hw ECC and upto 24bit correction. Signed-off-by: Naga Sureshkumar Relli Signed-off-by: Punnaiah Choudary Kalluri --- Changes in v8: - Implemented setup_data_interface hook - fixed

[PATCH v8 0/2] Add support for Arasan NAND Flash controller

This patch series adds the basic driver support for Arasan NAND Flash controller. We are reinitiating the patch series by fixing the comments given by Boris and Rob. Previous Patch reference: https://lkml.org/lkml/2017/1/8/245 Naga Sureshkumar Relli (2): mtd: arasan: Add device tree binding

[PATCH v8 0/2] Add support for Arasan NAND Flash controller

This patch series adds the basic driver support for Arasan NAND Flash controller. We are reinitiating the patch series by fixing the comments given by Boris and Rob. Previous Patch reference: https://lkml.org/lkml/2017/1/8/245 Naga Sureshkumar Relli (2): mtd: arasan: Add device tree binding

[PATCH v8 1/2] mtd: arasan: Add device tree binding documentation

This patch adds the dts binding document for arasan nand flash controller. Signed-off-by: Naga Sureshkumar Relli Signed-off-by: Punnaiah Choudary Kalluri --- Changes in v8: - Updated compatible and clock-names as per Boris comments Changes in v7: -

[PATCH v8 1/2] mtd: arasan: Add device tree binding documentation

This patch adds the dts binding document for arasan nand flash controller. Signed-off-by: Naga Sureshkumar Relli Signed-off-by: Punnaiah Choudary Kalluri --- Changes in v8: - Updated compatible and clock-names as per Boris comments Changes in v7: - Corrected the acronyms those should be in caps

Re: [PATCH] staging: comedi: ni_*

On Wed, Dec 13, 2017 at 6:07 AM, Greg Kroah-Hartman wrote: > On Wed, Dec 13, 2017 at 05:16:13PM +0530, Aniruddha Shastri wrote: >> On Wed, Dec 13, 2017 at 4:20 PM, Greg Kroah-Hartman >> wrote: >> > >> > On Wed, Dec 13, 2017 at 04:01:04AM

Re: [PATCH] staging: comedi: ni_*

On Wed, Dec 13, 2017 at 6:07 AM, Greg Kroah-Hartman wrote: > On Wed, Dec 13, 2017 at 05:16:13PM +0530, Aniruddha Shastri wrote: >> On Wed, Dec 13, 2017 at 4:20 PM, Greg Kroah-Hartman >> wrote: >> > >> > On Wed, Dec 13, 2017 at 04:01:04AM -0600, Aniruddha Shastri wrote: >> > > Fix checkpatch

Re: [PATCH] driver core: Make it safe to use get_device() if the reference count is zero

On Thu, Dec 14, 2017 at 11:39:36AM +0800, Jason Yan wrote: > Some driviers may have the chance to increase a reference count that > has dropped to zero when using get_device() because of their design. Then those drivers are broken :) > We have met such a issue with scsi: >

Re: [PATCH] driver core: Make it safe to use get_device() if the reference count is zero

On Thu, Dec 14, 2017 at 11:39:36AM +0800, Jason Yan wrote: > Some driviers may have the chance to increase a reference count that > has dropped to zero when using get_device() because of their design. Then those drivers are broken :) > We have met such a issue with scsi: >

Re: [PATCH 4/4] scsi: arcmsr: simplify all arcmsr_hbaX_get_config routine by call a new get_adapter_config function

On Thu, 2017-12-14 at 13:13 +0800, kbuild test robot wrote: > Hi Ching, > > Thank you for the patch! Perhaps something to improve: > > [auto build test WARNING on scsi/for-next] > [also build test WARNING on next-20171213] > [cannot apply to v4.15-rc3] > [if your patch

Re: [PATCH 4/4] scsi: arcmsr: simplify all arcmsr_hbaX_get_config routine by call a new get_adapter_config function

On Thu, 2017-12-14 at 13:13 +0800, kbuild test robot wrote: > Hi Ching, > > Thank you for the patch! Perhaps something to improve: > > [auto build test WARNING on scsi/for-next] > [also build test WARNING on next-20171213] > [cannot apply to v4.15-rc3] > [if your patch

Re: [RFC PATCH 3/5] mm, hugetlb: do not rely on overcommit limit during migration

On Wed 13-12-17 15:35:33, Mike Kravetz wrote: > On 12/04/2017 06:01 AM, Michal Hocko wrote: [...] > > Before migration > > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/free_hugepages:0 > > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages:1 > >

Re: [RFC PATCH 3/5] mm, hugetlb: do not rely on overcommit limit during migration

On Wed 13-12-17 15:35:33, Mike Kravetz wrote: > On 12/04/2017 06:01 AM, Michal Hocko wrote: [...] > > Before migration > > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/free_hugepages:0 > > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages:1 > >

Re: [PATCH v6 00/14] soundwire: Add a new SoundWire subsystem

On Thu, Dec 14, 2017 at 11:19:31AM +0530, Vinod Koul wrote: > Changes in v6: > - Add reviewed/acked tags from Philippe, Pierre, Takashi and Greg > - Fix nitpicks from Takashi > - Drop the sysfs patch for now Wait, why drop the sysfs patch entirely? You need those attributes, right? You

Re: [PATCH v6 00/14] soundwire: Add a new SoundWire subsystem

On Thu, Dec 14, 2017 at 11:19:31AM +0530, Vinod Koul wrote: > Changes in v6: > - Add reviewed/acked tags from Philippe, Pierre, Takashi and Greg > - Fix nitpicks from Takashi > - Drop the sysfs patch for now Wait, why drop the sysfs patch entirely? You need those attributes, right? You

Re: [PATCH] Staging: vc04_services: fix brace coding style issues in vchiq_shim.c

Am 13.12.2017 um 21:51 schrieb Tomas Marek: This patch fix brace on next line coding style errors reported by checkpatch. Signed-off-by: Tomas Marek Acked-by: Stefan Wahren Thanks

Re: [PATCH] Staging: vc04_services: fix brace coding style issues in vchiq_shim.c

Am 13.12.2017 um 21:51 schrieb Tomas Marek: This patch fix brace on next line coding style errors reported by checkpatch. Signed-off-by: Tomas Marek Acked-by: Stefan Wahren Thanks

[PATCH v3] staging: comedi: ni_*: Fix style warnings.

Two of these warnings are now line-too-long warnings. I think these warnings are preferable to the ones listed below. The longest line is only 85 chars wide, which is reasonable. Warnings fixed: ni_atmio.c:239: WARNING: Avoid multiple line dereference - prefer 'ni_boards[i].isapnp_id'

[PATCH v3] staging: comedi: ni_*: Fix style warnings.

Two of these warnings are now line-too-long warnings. I think these warnings are preferable to the ones listed below. The longest line is only 85 chars wide, which is reasonable. Warnings fixed: ni_atmio.c:239: WARNING: Avoid multiple line dereference - prefer 'ni_boards[i].isapnp_id'

Re: [RFC V7 2/2] OPP: Allow "opp-hz" and "opp-microvolt" to contain magic values

On 30-11-17, 12:29, Viresh Kumar wrote: > On 29-11-17, 16:50, Stephen Boyd wrote: > > Sorry it still makes zero sense to me. It seems that we're trying > > to make the OPP table parsing generic just for the sake of code > > brevity. > > Not just the code but bindings as well to make sure we don't

Re: [RFC V7 2/2] OPP: Allow "opp-hz" and "opp-microvolt" to contain magic values

On 30-11-17, 12:29, Viresh Kumar wrote: > On 29-11-17, 16:50, Stephen Boyd wrote: > > Sorry it still makes zero sense to me. It seems that we're trying > > to make the OPP table parsing generic just for the sake of code > > brevity. > > Not just the code but bindings as well to make sure we don't

Re: [PATCH v3] Staging: pi433: fix brace coding style issues in pi433_if.c

On Wed, Dec 13, 2017 at 11:31:15AM -0800, Tomas Marek wrote: > On 12/13/2017 03:55 AM, Greg KH wrote: > > > On Sat, Dec 09, 2017 at 12:41:11PM -0800, Tomas Marek wrote: > >> This patch fix several brace on next line, braces not necessary, space > >> around =/<, and space before/after open/close

Re: [PATCH 1/2] mm: NUMA stats code cleanup and enhancement

On Thu 14-12-17 09:40:32, kemi wrote: > > > On 2017年12月12日 16:11, Michal Hocko wrote: > > On Tue 12-12-17 10:05:26, kemi wrote: > >> > >> > >> On 2017年12月08日 16:47, Michal Hocko wrote: > >>> On Fri 08-12-17 16:38:46, kemi wrote: > > > On 2017年11月30日 17:45, Michal Hocko wrote: >

[PATCH] ASoC: sun4i-i2s: Show detailed error when DAI configuration callbacks fail

When any of the DAI hardware configuration callbacks (.hw_param, .set_fmt, .set_sysclk) fails, there is no explanation about why it failed. This is particularly confusing for .hw_param, which covers many parameters of the DAI. Telling the users what parameter isn't supported, and what the

Re: [PATCH v3] Staging: pi433: fix brace coding style issues in pi433_if.c

On Wed, Dec 13, 2017 at 11:31:15AM -0800, Tomas Marek wrote: > On 12/13/2017 03:55 AM, Greg KH wrote: > > > On Sat, Dec 09, 2017 at 12:41:11PM -0800, Tomas Marek wrote: > >> This patch fix several brace on next line, braces not necessary, space > >> around =/<, and space before/after open/close

Re: [PATCH 1/2] mm: NUMA stats code cleanup and enhancement

On Thu 14-12-17 09:40:32, kemi wrote: > > > On 2017年12月12日 16:11, Michal Hocko wrote: > > On Tue 12-12-17 10:05:26, kemi wrote: > >> > >> > >> On 2017年12月08日 16:47, Michal Hocko wrote: > >>> On Fri 08-12-17 16:38:46, kemi wrote: > > > On 2017年11月30日 17:45, Michal Hocko wrote: >

[PATCH] ASoC: sun4i-i2s: Show detailed error when DAI configuration callbacks fail

When any of the DAI hardware configuration callbacks (.hw_param, .set_fmt, .set_sysclk) fails, there is no explanation about why it failed. This is particularly confusing for .hw_param, which covers many parameters of the DAI. Telling the users what parameter isn't supported, and what the

Re: [PATCH] staging: fbtft: replace __ATTR() with DEVICE_ATTR()

On Thu, Dec 14, 2017 at 11:51:17AM +0530, Aishwarya Pant wrote: > On Wed, Dec 13, 2017 at 12:50:00PM +0100, Greg Kroah-Hartman wrote: > > On Mon, Dec 11, 2017 at 03:24:30PM +0530, Aishwarya Pant wrote: > > > This is a clean-up patch which replaces the uses of raw __ATTR(...) > > > macro with the

Re: linux-next: build failure after merge of the staging.current tree

On Thu, Dec 14, 2017 at 05:00:33PM +1100, Stephen Rothwell wrote: > Hi Greg, > > After merging the staging.current tree, today's linux-next build (powerpc > allyesconfig) failed like this: > > drivers/staging/android/ion/ion_cma_heap.c: In function 'ion_cma_allocate': >

Re: [PATCH] staging: fbtft: replace __ATTR() with DEVICE_ATTR()

On Thu, Dec 14, 2017 at 11:51:17AM +0530, Aishwarya Pant wrote: > On Wed, Dec 13, 2017 at 12:50:00PM +0100, Greg Kroah-Hartman wrote: > > On Mon, Dec 11, 2017 at 03:24:30PM +0530, Aishwarya Pant wrote: > > > This is a clean-up patch which replaces the uses of raw __ATTR(...) > > > macro with the

Re: linux-next: build failure after merge of the staging.current tree

On Thu, Dec 14, 2017 at 05:00:33PM +1100, Stephen Rothwell wrote: > Hi Greg, > > After merging the staging.current tree, today's linux-next build (powerpc > allyesconfig) failed like this: > > drivers/staging/android/ion/ion_cma_heap.c: In function 'ion_cma_allocate': >

Re: [PATCH v2] staging: ion: Fix ion_cma_heap allocations

On Wed, Dec 13, 2017 at 01:26:04PM -0800, John Stultz wrote: > In trying to add support for drm_hwcomposer to HiKey, > I've needed to utilize the ION CMA heap, and I've noticed > problems with allocations on newer kernels failing. > > It seems back with 204f672255c2 ("ion: Use CMA APIs

Re: [PATCH v2] staging: ion: Fix ion_cma_heap allocations

On Wed, Dec 13, 2017 at 01:26:04PM -0800, John Stultz wrote: > In trying to add support for drm_hwcomposer to HiKey, > I've needed to utilize the ION CMA heap, and I've noticed > problems with allocations on newer kernels failing. > > It seems back with 204f672255c2 ("ion: Use CMA APIs

Re: [PATCH v2] staging: ion: Fix ion_cma_heap allocations

On Wed, Dec 13, 2017 at 01:26:04PM -0800, John Stultz wrote: > In trying to add support for drm_hwcomposer to HiKey, > I've needed to utilize the ION CMA heap, and I've noticed > problems with allocations on newer kernels failing. > > It seems back with 204f672255c2 ("ion: Use CMA APIs

Re: [PATCH v2] staging: ion: Fix ion_cma_heap allocations

On Wed, Dec 13, 2017 at 01:26:04PM -0800, John Stultz wrote: > In trying to add support for drm_hwcomposer to HiKey, > I've needed to utilize the ION CMA heap, and I've noticed > problems with allocations on newer kernels failing. > > It seems back with 204f672255c2 ("ion: Use CMA APIs

FS: EXT4: should we sync error info in __ext4_grp_locked_error?

Hi, In function __ext4_grp_locked_error, __save_error_info(sb, function, line) is called to save error info in super block block, but does not sync that information to disk to info the subsequence fsck after reboot. The reason, I guess maybe it is in locked state. My question is why not

FS: EXT4: should we sync error info in __ext4_grp_locked_error?

Hi, In function __ext4_grp_locked_error, __save_error_info(sb, function, line) is called to save error info in super block block, but does not sync that information to disk to info the subsequence fsck after reboot. The reason, I guess maybe it is in locked state. My question is why not

Re: [PATCH 2/2] mmap.2: MAP_FIXED updated documentation

On Wed 13-12-17 15:19:00, Kees Cook wrote: > On Wed, Dec 13, 2017 at 6:40 AM, Cyril Hrubis wrote: > > Hi! > >> You selected stupid name for a flag. Everyone and their dog agrees > >> with that. There's even consensus on better name (and everyone agrees > >> it is better than

Re: [PATCH 2/2] mmap.2: MAP_FIXED updated documentation

On Wed 13-12-17 15:19:00, Kees Cook wrote: > On Wed, Dec 13, 2017 at 6:40 AM, Cyril Hrubis wrote: > > Hi! > >> You selected stupid name for a flag. Everyone and their dog agrees > >> with that. There's even consensus on better name (and everyone agrees > >> it is better than .._SAFE). Of course,

linux-next: Tree for Dec 14

Hi all, Changes since 20171213: The staging.current tree gained a build failure for which I reverted a commit. The clk tree lost its build failures. The bpf-next tree lost its build failure. The drm tree gained a conflict against the drm-misc-fixes tree. Non-merge commits (relative to Linus

linux-next: Tree for Dec 14

Hi all, Changes since 20171213: The staging.current tree gained a build failure for which I reverted a commit. The clk tree lost its build failures. The bpf-next tree lost its build failure. The drm tree gained a conflict against the drm-misc-fixes tree. Non-merge commits (relative to Linus

Re: [PATCH v4 00/15] drm/sun4i: Add A83t LVDS support

On Thu, Dec 07, 2017 at 04:58:45PM +0100, Maxime Ripard wrote: > Hi, > > Here is an attempt at supporting the LVDS output in our DRM driver. This > has been tested on the A83T (with DE2), but since everything is basically > in the TCON, it should also be usable on the older SoCs with minor >

Re: [PATCH v4 00/15] drm/sun4i: Add A83t LVDS support

On Thu, Dec 07, 2017 at 04:58:45PM +0100, Maxime Ripard wrote: > Hi, > > Here is an attempt at supporting the LVDS output in our DRM driver. This > has been tested on the A83T (with DE2), but since everything is basically > in the TCON, it should also be usable on the older SoCs with minor >

Re: [PATCH v2] staging: comedi: ni_*: Fix style warnings.

On Thu, 2017-12-14 at 00:27 -0600, Aniruddha Shastri wrote: > Three of these warnings are now line-too-long warnings. I think these > warnings are preferable to the ones listed below. The longest line > is only 87 chars wide, which is reasonable. [] > diff --git

Re: [PATCH v2] staging: comedi: ni_*: Fix style warnings.

On Thu, 2017-12-14 at 00:27 -0600, Aniruddha Shastri wrote: > Three of these warnings are now line-too-long warnings. I think these > warnings are preferable to the ones listed below. The longest line > is only 87 chars wide, which is reasonable. [] > diff --git

Re: [PATCH v9 0/5] Add the ability to do BPF directed error injection

On Wed, 13 Dec 2017 13:57:45 -0500 Josef Bacik wrote: > On Wed, Dec 13, 2017 at 10:07:32AM -0800, Darrick J. Wong wrote: > > On Wed, Dec 13, 2017 at 01:03:57PM -0500, Josef Bacik wrote: > > > On Tue, Dec 12, 2017 at 03:11:50PM -0800, Darrick J. Wong wrote: > > > > On Mon,

Re: [PATCH v9 0/5] Add the ability to do BPF directed error injection

On Wed, 13 Dec 2017 13:57:45 -0500 Josef Bacik wrote: > On Wed, Dec 13, 2017 at 10:07:32AM -0800, Darrick J. Wong wrote: > > On Wed, Dec 13, 2017 at 01:03:57PM -0500, Josef Bacik wrote: > > > On Tue, Dec 12, 2017 at 03:11:50PM -0800, Darrick J. Wong wrote: > > > > On Mon, Dec 11, 2017 at

Re: [PATCH 1/1] KVM/x86: Check input paging mode when cs.l is set

On 2017年12月13日 20:20, Paolo Bonzini wrote: > On 13/12/2017 05:17, Lan Tianyu wrote: >> Reported by syzkaller: >> WARNING: CPU: 0 PID: 27962 at arch/x86/kvm/emulate.c:5631 >> x86_emulate_insn+0x557/0x15f0 [kvm] >> Modules linked in: kvm_intel kvm [last unloaded: kvm] >> CPU: 0 PID:

Re: [PATCH 1/1] KVM/x86: Check input paging mode when cs.l is set

On 2017年12月13日 20:20, Paolo Bonzini wrote: > On 13/12/2017 05:17, Lan Tianyu wrote: >> Reported by syzkaller: >> WARNING: CPU: 0 PID: 27962 at arch/x86/kvm/emulate.c:5631 >> x86_emulate_insn+0x557/0x15f0 [kvm] >> Modules linked in: kvm_intel kvm [last unloaded: kvm] >> CPU: 0 PID:

Re: [PATCH 1/2] mm: Add kernel MMU notifier to manage IOTLB/DEVTLB

Hi, Dave, Dave Hansen writes: > On 12/13/2017 07:38 PM, Lu Baolu wrote: >> 2. When vmalloc/vfree interfaces are called, the page mappings >> for kernel memory might get changed. And current code calls >> flush_tlb_kernel_range() to flush CPU TLBs only. The IOTLB

Re: [PATCH 1/2] mm: Add kernel MMU notifier to manage IOTLB/DEVTLB

Hi, Dave, Dave Hansen writes: > On 12/13/2017 07:38 PM, Lu Baolu wrote: >> 2. When vmalloc/vfree interfaces are called, the page mappings >> for kernel memory might get changed. And current code calls >> flush_tlb_kernel_range() to flush CPU TLBs only. The IOTLB or >> DevTLB will be

[PATCH v2] staging: comedi: ni_*: Fix style warnings.

Three of these warnings are now line-too-long warnings. I think these warnings are preferable to the ones listed below. The longest line is only 87 chars wide, which is reasonable. Warnings fixed: ni_670x.c:212: WARNING: struct comedi_lrange should normally be const ni_atmio.c:239: WARNING:

[PATCH v3] spi: s3c64xx: add SPDX identifier

Replace the original license statement with the SPDX identifier. Signed-off-by: Andi Shyti Reviewed-by: Krzysztof Kozlowski --- Hi, v2 to v3: - move the SPDX identifier on top as a separate comment as per documentation - add Krzysztof's review v1

[PATCH v2] staging: comedi: ni_*: Fix style warnings.

Three of these warnings are now line-too-long warnings. I think these warnings are preferable to the ones listed below. The longest line is only 87 chars wide, which is reasonable. Warnings fixed: ni_670x.c:212: WARNING: struct comedi_lrange should normally be const ni_atmio.c:239: WARNING:

[PATCH v3] spi: s3c64xx: add SPDX identifier

Replace the original license statement with the SPDX identifier. Signed-off-by: Andi Shyti Reviewed-by: Krzysztof Kozlowski --- Hi, v2 to v3: - move the SPDX identifier on top as a separate comment as per documentation - add Krzysztof's review v1 to v2: - keep the original license Andi

Re: [PATCH 1/2] mm: Add kernel MMU notifier to manage IOTLB/DEVTLB

On 12/13/2017 07:38 PM, Lu Baolu wrote: > 2. When vmalloc/vfree interfaces are called, the page mappings > for kernel memory might get changed. And current code calls > flush_tlb_kernel_range() to flush CPU TLBs only. The IOTLB or > DevTLB will be stale compared to that on the cpu for

Re: [PATCH 1/2] mm: Add kernel MMU notifier to manage IOTLB/DEVTLB

On 12/13/2017 07:38 PM, Lu Baolu wrote: > 2. When vmalloc/vfree interfaces are called, the page mappings > for kernel memory might get changed. And current code calls > flush_tlb_kernel_range() to flush CPU TLBs only. The IOTLB or > DevTLB will be stale compared to that on the cpu for

Re: [PATCH] staging: fbtft: replace __ATTR() with DEVICE_ATTR()

On Wed, Dec 13, 2017 at 12:50:00PM +0100, Greg Kroah-Hartman wrote: > On Mon, Dec 11, 2017 at 03:24:30PM +0530, Aishwarya Pant wrote: > > This is a clean-up patch which replaces the uses of raw __ATTR(...) > > macro with the more conventional DEVICE_ATTR(...) for defining device > > attributes. >

Re: [PATCH 1/1] arm: sunxi: Add alternative pins for spi0

On 12/13/2017 05:40 PM, Maxime Ripard wrote: Hi, On Wed, Dec 13, 2017 at 09:44:34AM +0200, Stefan Mavrodiev wrote: Allwinner A10/A13/A20 SoCs have pinmux for spi0 on port C. The patch adds these pins in the respective dts includes. Signed-off-by: Stefan Mavrodiev Do you

Re: [PATCH] staging: fbtft: replace __ATTR() with DEVICE_ATTR()

On Wed, Dec 13, 2017 at 12:50:00PM +0100, Greg Kroah-Hartman wrote: > On Mon, Dec 11, 2017 at 03:24:30PM +0530, Aishwarya Pant wrote: > > This is a clean-up patch which replaces the uses of raw __ATTR(...) > > macro with the more conventional DEVICE_ATTR(...) for defining device > > attributes. >

Re: [PATCH 1/1] arm: sunxi: Add alternative pins for spi0

On 12/13/2017 05:40 PM, Maxime Ripard wrote: Hi, On Wed, Dec 13, 2017 at 09:44:34AM +0200, Stefan Mavrodiev wrote: Allwinner A10/A13/A20 SoCs have pinmux for spi0 on port C. The patch adds these pins in the respective dts includes. Signed-off-by: Stefan Mavrodiev Do you have any boards that

Re: [PATCH v2] spi: s3c64xx: add SPDX identifier

Andi, On Thu, Dec 14, 2017 at 2:31 AM, Andi Shyti wrote: > Hi Philippe, > >> > diff --git a/include/linux/platform_data/spi-s3c64xx.h >> > b/include/linux/platform_data/spi-s3c64xx.h >> > index da79774078a7..8917f38c97c5 100644 >> > ---

Re: [PATCH v2] spi: s3c64xx: add SPDX identifier

Andi, On Thu, Dec 14, 2017 at 2:31 AM, Andi Shyti wrote: > Hi Philippe, > >> > diff --git a/include/linux/platform_data/spi-s3c64xx.h >> > b/include/linux/platform_data/spi-s3c64xx.h >> > index da79774078a7..8917f38c97c5 100644 >> > --- a/include/linux/platform_data/spi-s3c64xx.h >> > +++

[PATCH 2/4 v3] mtd: onenand: samsung: return an error if 'mtd_device_parse_register()' fails

If 'mtd_device_parse_register()' fails, we still return 0 which mean success. Return the error code instead, as done in all the other error handling paths. Signed-off-by: Christophe JAILLET --- Cross-compiled tested-only v2: call 'onenand_release()' to undo

[PATCH 2/4 v3] mtd: onenand: samsung: return an error if 'mtd_device_parse_register()' fails

If 'mtd_device_parse_register()' fails, we still return 0 which mean success. Return the error code instead, as done in all the other error handling paths. Signed-off-by: Christophe JAILLET --- Cross-compiled tested-only v2: call 'onenand_release()' to undo 'onenand_scan()' v3: no change ---

[PATCH 3/4 v3] mtd: onenand: samsung: Remove a useless include

This include is not needed, so remove it. Signed-off-by: Christophe JAILLET --- Cross-compiled tested-only v3: new patch in the serie --- drivers/mtd/onenand/samsung.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/mtd/onenand/samsung.c

Re: [PATCH 1/2] mm: Add kernel MMU notifier to manage IOTLB/DEVTLB

On 2017/12/14 11:38, Lu Baolu wrote: > Hi, > > On 12/14/2017 11:10 AM, Bob Liu wrote: >> On 2017/12/14 9:02, Lu Baolu wrote: From: Huang Ying Shared Virtual Memory (SVM) allows a kernel memory mapping to be shared between CPU and and a device which

[PATCH 3/4 v3] mtd: onenand: samsung: Remove a useless include

This include is not needed, so remove it. Signed-off-by: Christophe JAILLET --- Cross-compiled tested-only v3: new patch in the serie --- drivers/mtd/onenand/samsung.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/mtd/onenand/samsung.c b/drivers/mtd/onenand/samsung.c index

Re: [PATCH 1/2] mm: Add kernel MMU notifier to manage IOTLB/DEVTLB

On 2017/12/14 11:38, Lu Baolu wrote: > Hi, > > On 12/14/2017 11:10 AM, Bob Liu wrote: >> On 2017/12/14 9:02, Lu Baolu wrote: From: Huang Ying Shared Virtual Memory (SVM) allows a kernel memory mapping to be shared between CPU and and a device which requested a supervisor

[PATCH 3/4 v3] mtd: onenand: samsung: Propagate the error returned by 'onenand_scan()'

Propagate the error code returned by 'onenand_scan()' instead of a hard-coded -EFAULT. Signed-off-by: Christophe JAILLET --- Cross-compiled tested-only v3: new patch in the serie --- drivers/mtd/onenand/samsung.c | 5 +++-- 1 file changed, 3 insertions(+), 2

Re: [PATCH V2] block, bfq: remove batches of confusing ifdefs

Hi Jens, do you think this version could be ok? Thanks, Paolo > Il giorno 04 dic 2017, alle ore 11:42, Paolo Valente > ha scritto: > > Commit a33801e8b473 ("block, bfq: move debug blkio stats behind > CONFIG_DEBUG_BLK_CGROUP") introduced two batches of confusing

Re: [PATCH V2] block, bfq: remove batches of confusing ifdefs

Hi Jens, do you think this version could be ok? Thanks, Paolo > Il giorno 04 dic 2017, alle ore 11:42, Paolo Valente > ha scritto: > > Commit a33801e8b473 ("block, bfq: move debug blkio stats behind > CONFIG_DEBUG_BLK_CGROUP") introduced two batches of confusing ifdefs: > one reported in [1],

[PATCH 3/4 v3] mtd: onenand: samsung: Propagate the error returned by 'onenand_scan()'

Propagate the error code returned by 'onenand_scan()' instead of a hard-coded -EFAULT. Signed-off-by: Christophe JAILLET --- Cross-compiled tested-only v3: new patch in the serie --- drivers/mtd/onenand/samsung.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git

[PATCH 1/4 v3] mtd: onenand: samsung: use devm_ function to simplify code and fix some leaks

Convert all error handling code in 's3c_onenand_probe()' to resource-managed alternatives in order to simplify code. This fixes a resource leak if 'platform_get_resource()' fails at line 872. The 'request_irq()' at line 971 was also un-balanced. It is now resource-managed. Signed-off-by:

[PATCH 1/4 v3] mtd: onenand: samsung: use devm_ function to simplify code and fix some leaks

Convert all error handling code in 's3c_onenand_probe()' to resource-managed alternatives in order to simplify code. This fixes a resource leak if 'platform_get_resource()' fails at line 872. The 'request_irq()' at line 971 was also un-balanced. It is now resource-managed. Signed-off-by:

[PATCH 0/4 v3] mtd: onenand: samsung: Simplify code and fix leaks in error handling paths

The first patch converts 's3c_onenand_probe()' to devm_ functions. This fixes a leak in one path (line 872). This also free_irq which was not handled at all. ( I hope I'm correct :) ) The 2nd patch is about an un-handled error code which looks spurious. Not sure if I'm right. The 3rd patch

[PATCH 0/4 v3] mtd: onenand: samsung: Simplify code and fix leaks in error handling paths

The first patch converts 's3c_onenand_probe()' to devm_ functions. This fixes a leak in one path (line 872). This also free_irq which was not handled at all. ( I hope I'm correct :) ) The 2nd patch is about an un-handled error code which looks spurious. Not sure if I'm right. The 3rd patch

linux-next: build failure after merge of the staging.current tree

Hi Greg, After merging the staging.current tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/staging/android/ion/ion_cma_heap.c: In function 'ion_cma_allocate': drivers/staging/android/ion/ion_cma_heap.c:38:14: error: 'CONFIG_CMA_ALIGNMENT' undeclared (first use in

linux-next: build failure after merge of the staging.current tree

Hi Greg, After merging the staging.current tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/staging/android/ion/ion_cma_heap.c: In function 'ion_cma_allocate': drivers/staging/android/ion/ion_cma_heap.c:38:14: error: 'CONFIG_CMA_ALIGNMENT' undeclared (first use in

Re: About the try to remove cross-release feature entirely by Ingo

On Thu, Dec 14, 2017 at 12:07 PM, Theodore Ts'o wrote: > On Wed, Dec 13, 2017 at 04:13:07PM +0900, Byungchul Park wrote: >> >> Therefore, I want to say the fundamental problem >> comes from classification, not cross-release >> specific. > > You keep saying that it is "just" a

Re: About the try to remove cross-release feature entirely by Ingo

On Thu, Dec 14, 2017 at 12:07 PM, Theodore Ts'o wrote: > On Wed, Dec 13, 2017 at 04:13:07PM +0900, Byungchul Park wrote: >> >> Therefore, I want to say the fundamental problem >> comes from classification, not cross-release >> specific. > > You keep saying that it is "just" a matter of

[PATCH v3 2/2] misc: Add Xilinx ZYNQMP VCU logicoreIP init driver

Xilinx ZYNQMP logicoreIP Init driver is based on the new LogiCoreIP design created. This driver provides the processing system and programmable logic isolation. Set the frequency based on the clock information get from the logicoreIP register set. It is put in drivers/misc as there is no

[PATCH v3 1/2] dt-bindings: misc: Add DT bindings to xlnx_vcu driver

Add Device Tree binding document for logicoreIP. This logicoreIP provides the isolation between the processing system and programmable logic. Also provides the clock related information. Signed-off-by: Dhaval Shah --- Chnages since v3: * Use "dt-bindings: misc: ..." for the

[PATCH v3 2/2] misc: Add Xilinx ZYNQMP VCU logicoreIP init driver

Xilinx ZYNQMP logicoreIP Init driver is based on the new LogiCoreIP design created. This driver provides the processing system and programmable logic isolation. Set the frequency based on the clock information get from the logicoreIP register set. It is put in drivers/misc as there is no

[PATCH v3 1/2] dt-bindings: misc: Add DT bindings to xlnx_vcu driver

Add Device Tree binding document for logicoreIP. This logicoreIP provides the isolation between the processing system and programmable logic. Also provides the clock related information. Signed-off-by: Dhaval Shah --- Chnages since v3: * Use "dt-bindings: misc: ..." for the subject. Changes

[PATCH v3 0/2] Documentation and driver of logicoreIP

1st patch provide Device Tree binding document for logicoreIP 2nd patch provide the xlnx_vcu logicoreIP driver, Kconfig changes and Makefile changes for the driver. Dhaval Shah (2): Documentation: devicetree: Add DT bindings to xlnx_vcu driver misc: Add Xilinx ZYNQMP VCU logicoreIP init

[PATCH v3 0/2] Documentation and driver of logicoreIP

1st patch provide Device Tree binding document for logicoreIP 2nd patch provide the xlnx_vcu logicoreIP driver, Kconfig changes and Makefile changes for the driver. Dhaval Shah (2): Documentation: devicetree: Add DT bindings to xlnx_vcu driver misc: Add Xilinx ZYNQMP VCU logicoreIP init

  1   2   3   4   5   6   7   8   9   10   >