[RFC PATCH 2/2] kbuild: Cache a few more calls to the compiler

These are a few stragglers that I left out of the original patch to cache calls to the C compiler ("kbuild: Add a cache for generated variables") because they bleed out into the main Makefile and thus uglify things a little bit. The idea is the same here, though. Signed-off-by: Douglas Anderson

[RFC PATCH 2/2] kbuild: Cache a few more calls to the compiler

These are a few stragglers that I left out of the original patch to cache calls to the C compiler ("kbuild: Add a cache for generated variables") because they bleed out into the main Makefile and thus uglify things a little bit. The idea is the same here, though. Signed-off-by: Douglas Anderson

[RFC PATCH 1/2] kbuild: Add a cache for generated variables

While timing a "no-op" build of the kernel (incrementally building the kernel even though nothing changed) in the Chrome OS build system I found that it was much slower than I expected. Digging into things a bit, I found that quite a bit of the time was spent invoking the C compiler even though

[RFC PATCH 0/2] kbuild: Cache exploratory calls to the compiler

This two-patch series attempts to speed incremental builds of the kernel up by a bit. How much of a speedup you get depends a lot on your environment, specifically the speed of your workstation and how fast it takes to invoke the compiler. In the Chrome OS build environment you get a really big

[RFC PATCH 1/2] kbuild: Add a cache for generated variables

While timing a "no-op" build of the kernel (incrementally building the kernel even though nothing changed) in the Chrome OS build system I found that it was much slower than I expected. Digging into things a bit, I found that quite a bit of the time was spent invoking the C compiler even though

[RFC PATCH 0/2] kbuild: Cache exploratory calls to the compiler

This two-patch series attempts to speed incremental builds of the kernel up by a bit. How much of a speedup you get depends a lot on your environment, specifically the speed of your workstation and how fast it takes to invoke the compiler. In the Chrome OS build environment you get a really big

[PATCH v4 for 4.14 1/3] membarrier: Provide register expedited private command

Provide a new command allowing processes to register their intent to use the private expedited command. This allows PowerPC to skip the full memory barrier in switch_mm(), and only issue the barrier when scheduling into a task belonging to a process that has registered to use expedited private.

[PATCH v4 for 4.14 1/3] membarrier: Provide register expedited private command

Provide a new command allowing processes to register their intent to use the private expedited command. This allows PowerPC to skip the full memory barrier in switch_mm(), and only issue the barrier when scheduling into a task belonging to a process that has registered to use expedited private.

[PATCH for 4.14 2/3] membarrier: selftest: Test private expedited cmd

Test the new MEMBARRIER_CMD_PRIVATE_EXPEDITED and MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED commands. Add checks expecting specific error values on system calls expected to fail. Signed-off-by: Mathieu Desnoyers CC: Peter Zijlstra CC: Paul

[PATCH net] net: dsa: mv88e6xxx: lock mutex when freeing IRQs

mv88e6xxx_g2_irq_free locks the registers mutex, but not mv88e6xxx_g1_irq_free, which results in a stack trace from assert_reg_lock when unloading the mv88e6xxx module. Fix this. Fixes: 3460a5770ce9 ("net: dsa: mv88e6xxx: Mask g1 interrupts and free interrupt") Signed-off-by: Vivien Didelot

[PATCH for 4.14 2/3] membarrier: selftest: Test private expedited cmd

Test the new MEMBARRIER_CMD_PRIVATE_EXPEDITED and MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED commands. Add checks expecting specific error values on system calls expected to fail. Signed-off-by: Mathieu Desnoyers CC: Peter Zijlstra CC: Paul E. McKenney CC: Boqun Feng CC: Andrew Hunter CC:

[PATCH net] net: dsa: mv88e6xxx: lock mutex when freeing IRQs

mv88e6xxx_g2_irq_free locks the registers mutex, but not mv88e6xxx_g1_irq_free, which results in a stack trace from assert_reg_lock when unloading the mv88e6xxx module. Fix this. Fixes: 3460a5770ce9 ("net: dsa: mv88e6xxx: Mask g1 interrupts and free interrupt") Signed-off-by: Vivien Didelot ---

Re: [PATCH v3 2/2] staging: ion: create one device entry per heap

On 09/25/2017 11:56 PM, Greg KH wrote: On Tue, Sep 26, 2017 at 07:09:14AM +0200, Daniel Vetter wrote: On Mon, Sep 25, 2017 at 11:26:27AM -0700, Laura Abbott wrote: On 09/20/2017 01:45 AM, Benjamin Gaignard wrote: Instead a getting one common device "/dev/ion" for all the heaps this patch

[PATCH v4 for 4.14 3/3] membarrier: Document scheduler barrier requirements

Document the membarrier requirement on having a full memory barrier in __schedule() after coming from user-space, before storing to rq->curr. It is provided by smp_mb__after_spinlock() in __schedule(). Document that membarrier requires a full barrier on transition from kernel thread to userspace

Re: [PATCH v3 2/2] staging: ion: create one device entry per heap

On 09/25/2017 11:56 PM, Greg KH wrote: On Tue, Sep 26, 2017 at 07:09:14AM +0200, Daniel Vetter wrote: On Mon, Sep 25, 2017 at 11:26:27AM -0700, Laura Abbott wrote: On 09/20/2017 01:45 AM, Benjamin Gaignard wrote: Instead a getting one common device "/dev/ion" for all the heaps this patch

[PATCH v4 for 4.14 3/3] membarrier: Document scheduler barrier requirements

Document the membarrier requirement on having a full memory barrier in __schedule() after coming from user-space, before storing to rq->curr. It is provided by smp_mb__after_spinlock() in __schedule(). Document that membarrier requires a full barrier on transition from kernel thread to userspace

Re: [PATCH 1/2] pinctrl: Allow a device to indicate when to force a state

On 09/26/2017 07:16 AM, Charles Keepax wrote: > On Fri, Sep 22, 2017 at 09:57:22AM -0700, Florian Fainelli wrote: >> On 09/22/2017 06:20 AM, Charles Keepax wrote: >>> On Fri, Sep 22, 2017 at 01:55:22PM +0200, Linus Walleij wrote: On Thu, Sep 21, 2017 at 3:04 AM, Florian Fainelli

Re: [PATCH 1/2] pinctrl: Allow a device to indicate when to force a state

On 09/26/2017 07:16 AM, Charles Keepax wrote: > On Fri, Sep 22, 2017 at 09:57:22AM -0700, Florian Fainelli wrote: >> On 09/22/2017 06:20 AM, Charles Keepax wrote: >>> On Fri, Sep 22, 2017 at 01:55:22PM +0200, Linus Walleij wrote: On Thu, Sep 21, 2017 at 3:04 AM, Florian Fainelli wrote:

Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

Michal, On Tue, Sep 26, 2017 at 02:54:48PM +0200, Michal Simek wrote: > Hi, > > On 25.9.2017 18:11, Moritz Fischer wrote: > > Hi Michal, > > > > On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote: > >> Hi Moritz > >> > >> sorry for delay. > > > > No problem. > > > >> > >> On

I need your help to transfer my inheritance fund which i inheritances from my late father reply me for more details if you are willingness to help me,

Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

Michal, On Tue, Sep 26, 2017 at 02:54:48PM +0200, Michal Simek wrote: > Hi, > > On 25.9.2017 18:11, Moritz Fischer wrote: > > Hi Michal, > > > > On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote: > >> Hi Moritz > >> > >> sorry for delay. > > > > No problem. > > > >> > >> On

I need your help to transfer my inheritance fund which i inheritances from my late father reply me for more details if you are willingness to help me,

Re: [PATCH v4 3/4] ARM: dts: stm32: Add MDMA support for STM32H743 SoC

On Fri, Aug 25, 2017 at 04:31:05PM +0200, Pierre-Yves MORDRET wrote: > This patch adds MDMA support for STM32H743 SoC. Need ACK from ARM folks > > Signed-off-by: Pierre-Yves MORDRET > --- > Version history: > v4: > v3: > * None > v2: > *

Re: [PATCH v4 3/4] ARM: dts: stm32: Add MDMA support for STM32H743 SoC

On Fri, Aug 25, 2017 at 04:31:05PM +0200, Pierre-Yves MORDRET wrote: > This patch adds MDMA support for STM32H743 SoC. Need ACK from ARM folks > > Signed-off-by: Pierre-Yves MORDRET > --- > Version history: > v4: > v3: > * None > v2: > * Add MDMA support in DT for

Re: [PATCH] [media] clk-kona-setup: Delete two error messages for a failed memory allocation in parent_process()

On 09/26/2017 08:05 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Tue, 26 Sep 2017 16:54:20 +0200 > > Omit extra messages for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle software. > >

Re: [PATCH] [media] clk-kona-setup: Delete two error messages for a failed memory allocation in parent_process()

On 09/26/2017 08:05 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Tue, 26 Sep 2017 16:54:20 +0200 > > Omit extra messages for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring Can you

Re: [PATCH v2 00/16] Thunderbolt networking

On Mon, 2017-09-25 at 14:07 +0300, Mika Westerberg wrote: > Hi all, > > In addition of tunneling PCIe, Display Port and USB traffic, > Thunderbolt > allows connecting two hosts (domains) over a Thunderbolt cable. It is > possible to tunnel arbitrary data packets over such connection using >

[PATCH] thermal: enable broadcom menu for arm64 bcm2835

From: Allen Wild Moving the bcm2835 thermal driver to the broadcom directory prevented it from getting enabled for arm64 builds, since the broadcom directory is only available when 32-bit specific ARCH_BCM is set. Fix this by enabling the Broadcom menu for ARCH_BCM or

Re: [PATCH v2 00/16] Thunderbolt networking

On Mon, 2017-09-25 at 14:07 +0300, Mika Westerberg wrote: > Hi all, > > In addition of tunneling PCIe, Display Port and USB traffic, > Thunderbolt > allows connecting two hosts (domains) over a Thunderbolt cable. It is > possible to tunnel arbitrary data packets over such connection using >

[PATCH] thermal: enable broadcom menu for arm64 bcm2835

From: Allen Wild Moving the bcm2835 thermal driver to the broadcom directory prevented it from getting enabled for arm64 builds, since the broadcom directory is only available when 32-bit specific ARCH_BCM is set. Fix this by enabling the Broadcom menu for ARCH_BCM or ARCH_BCM2835. Fixes:

Re: [PATCH 4.4 50/53] ntb_transport: fix qp count bug

On 26/09/17 10:32 AM, Ben Hutchings wrote: In 4.4-stable, it doesn't, so this patch doesn't fix anything. It looks like 4.4 would need a backport of: Yup, look like the Fixes tag should have been b17faba0 instead of cb827ee. In which case it doesn't apply to 4.4. Thanks, Logan

Re: [PATCH 4.4 50/53] ntb_transport: fix qp count bug

On 26/09/17 10:32 AM, Ben Hutchings wrote: In 4.4-stable, it doesn't, so this patch doesn't fix anything. It looks like 4.4 would need a backport of: Yup, look like the Fixes tag should have been b17faba0 instead of cb827ee. In which case it doesn't apply to 4.4. Thanks, Logan

Re: [PATCH] net: stmmac: Meet alignment requirements for DMA

From: Matt Redfearn Date: Tue, 26 Sep 2017 14:57:39 +0100 > Since the MIPS architecture requires software cache management, > performing a dma_map_single(TO_DEVICE) will writeback and invalidate > the cachelines for the required region. To comply with (our >

Re: [PATCH] dmaengine: pl330: fix descriptor allocation fail

On Fri, Sep 08, 2017 at 01:00:26PM +0300, Alexander Kochetkov wrote: > Thread A calls pl330_get_desc() to get descriptor. If DMAC descriptor > pool is empty pl330_get_desc() allocates new descriptor using add_desc() > and then get newly allocated descriptor using pluck_desc(). > It is possible

Re: [PATCH] net: stmmac: Meet alignment requirements for DMA

From: Matt Redfearn Date: Tue, 26 Sep 2017 14:57:39 +0100 > Since the MIPS architecture requires software cache management, > performing a dma_map_single(TO_DEVICE) will writeback and invalidate > the cachelines for the required region. To comply with (our > interpretation of) the DMA API

Re: [PATCH] dmaengine: pl330: fix descriptor allocation fail

On Fri, Sep 08, 2017 at 01:00:26PM +0300, Alexander Kochetkov wrote: > Thread A calls pl330_get_desc() to get descriptor. If DMAC descriptor > pool is empty pl330_get_desc() allocates new descriptor using add_desc() > and then get newly allocated descriptor using pluck_desc(). > It is possible

Re: ARM64: kernel panics in DABT in sys_msync path

Yury, Richard, On Tue, Sep 26, 2017 at 08:23:35AM -0600, Ruigrok, Richard wrote: > On 9/26/2017 4:23 AM, Will Deacon wrote: > > On Mon, Sep 25, 2017 at 01:54:57PM -0600, Ruigrok, Richard wrote: > >> I also found this issue with kernels from 4.11 through 4.13. In my tests, > >> I > >> found that

Re: [PATCH v2 4/5] dmaengine: zynqmp_ps_pcie: Adding PS PCIe platform DMA driver

On Fri, Sep 08, 2017 at 05:53:07PM +0530, Ravi Shankar Jonnalagadda wrote: > Platform driver handles transactions for PCIe EP DMA and Root DMA > > Signed-off-by: Ravi Shankar Jonnalagadda > Signed-off-by: RaviKiran Gummaluri > --- >

Re: [PATCH 1/7] xfs: always use DAX if mount option is used

On Tue, Sep 26, 2017 at 04:37:43PM +0200, Christoph Hellwig wrote: > On Tue, Sep 26, 2017 at 09:09:57PM +1000, Dave Chinner wrote: > > Well, quite frankly, I never wanted the mount option for XFS. It was > > supposed to be for initial testing only, then we'd /always/ use the > > the inode flags.

Re: ARM64: kernel panics in DABT in sys_msync path

Yury, Richard, On Tue, Sep 26, 2017 at 08:23:35AM -0600, Ruigrok, Richard wrote: > On 9/26/2017 4:23 AM, Will Deacon wrote: > > On Mon, Sep 25, 2017 at 01:54:57PM -0600, Ruigrok, Richard wrote: > >> I also found this issue with kernels from 4.11 through 4.13. In my tests, > >> I > >> found that

Re: [PATCH v2 4/5] dmaengine: zynqmp_ps_pcie: Adding PS PCIe platform DMA driver

On Fri, Sep 08, 2017 at 05:53:07PM +0530, Ravi Shankar Jonnalagadda wrote: > Platform driver handles transactions for PCIe EP DMA and Root DMA > > Signed-off-by: Ravi Shankar Jonnalagadda > Signed-off-by: RaviKiran Gummaluri > --- > drivers/dma/xilinx/ps_pcie_platform.c | 3055 >

Re: [PATCH 1/7] xfs: always use DAX if mount option is used

On Tue, Sep 26, 2017 at 04:37:43PM +0200, Christoph Hellwig wrote: > On Tue, Sep 26, 2017 at 09:09:57PM +1000, Dave Chinner wrote: > > Well, quite frankly, I never wanted the mount option for XFS. It was > > supposed to be for initial testing only, then we'd /always/ use the > > the inode flags.

Re: DMA error when sg->offset value is greater than PAGE_SIZE in Intel IOMMU

| From: Robin Murphy | Sent: Tuesday, September 26, 2017 7:22 AM | | On 26/09/17 13:21, Harsh Jain wrote: | > Find attached new set of log. After repeated tries it panics. | | Thanks, that makes things a bit clearer - looks like fixing the physical | address/pteval

Re: DMA error when sg->offset value is greater than PAGE_SIZE in Intel IOMMU

| From: Robin Murphy | Sent: Tuesday, September 26, 2017 7:22 AM | | On 26/09/17 13:21, Harsh Jain wrote: | > Find attached new set of log. After repeated tries it panics. | | Thanks, that makes things a bit clearer - looks like fixing the physical | address/pteval calculation to not be off by a

Re: [PATCH] percpu: make this_cpu_generic_read() atomic w.r.t. interrupts

Hi, On Tue, Sep 26, 2017 at 01:47:27AM -0500, Christopher Lameter wrote: > On Mon, 25 Sep 2017, Tejun Heo wrote: > > On Mon, Sep 25, 2017 at 04:33:02PM +0100, Mark Rutland wrote: > > > Unfortunately, the generic this_cpu_read(), which is intended to be > > > irq-safe, is not: > > > > > > #define

Re: [PATCH] percpu: make this_cpu_generic_read() atomic w.r.t. interrupts

Hi, On Tue, Sep 26, 2017 at 01:47:27AM -0500, Christopher Lameter wrote: > On Mon, 25 Sep 2017, Tejun Heo wrote: > > On Mon, Sep 25, 2017 at 04:33:02PM +0100, Mark Rutland wrote: > > > Unfortunately, the generic this_cpu_read(), which is intended to be > > > irq-safe, is not: > > > > > > #define

Re: DMA error when sg->offset value is greater than PAGE_SIZE in Intel IOMMU

Oops..minor typo.. VTD_PAGE_SHIFT instead of VTD_PAGE_MASK On Tue, Sep 26, 2017 at 07:34:41AM -0700, Ashok Raj wrote: > On Tue, Sep 26, 2017 at 03:22:47PM +0100, Robin Murphy wrote: > > diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c > > index 6784a05dd6b2..d7f7def81613

Re: [PATCH v2 3/5] dmaengine: zynqmp_ps_pcie: Adding PS PCIe DMA driver

On Fri, Sep 08, 2017 at 05:53:05PM +0530, Ravi Shankar Jonnalagadda wrote: > Adding support for ZynqmMP PS PCIe EP driver. > Adding support for ZynqmMP PS PCIe Root DMA driver. /s/Adding/Add/ Please descibe the dmaengines here so people can know what to expect. > Modifying Kconfig and Makefile

Re: DMA error when sg->offset value is greater than PAGE_SIZE in Intel IOMMU

Oops..minor typo.. VTD_PAGE_SHIFT instead of VTD_PAGE_MASK On Tue, Sep 26, 2017 at 07:34:41AM -0700, Ashok Raj wrote: > On Tue, Sep 26, 2017 at 03:22:47PM +0100, Robin Murphy wrote: > > diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c > > index 6784a05dd6b2..d7f7def81613

Re: [PATCH v2 3/5] dmaengine: zynqmp_ps_pcie: Adding PS PCIe DMA driver

On Fri, Sep 08, 2017 at 05:53:05PM +0530, Ravi Shankar Jonnalagadda wrote: > Adding support for ZynqmMP PS PCIe EP driver. > Adding support for ZynqmMP PS PCIe Root DMA driver. /s/Adding/Add/ Please descibe the dmaengines here so people can know what to expect. > Modifying Kconfig and Makefile

Re: [v8 0/4] cgroup-aware OOM killer

On Tue, Sep 26, 2017 at 03:30:40PM +0200, Michal Hocko wrote: > On Tue 26-09-17 13:13:00, Roman Gushchin wrote: > > On Tue, Sep 26, 2017 at 01:21:34PM +0200, Michal Hocko wrote: > > > On Tue 26-09-17 11:59:25, Roman Gushchin wrote: > > > > On Mon, Sep 25, 2017 at 10:25:21PM +0200, Michal Hocko

Re: [v8 0/4] cgroup-aware OOM killer

On Tue, Sep 26, 2017 at 03:30:40PM +0200, Michal Hocko wrote: > On Tue 26-09-17 13:13:00, Roman Gushchin wrote: > > On Tue, Sep 26, 2017 at 01:21:34PM +0200, Michal Hocko wrote: > > > On Tue 26-09-17 11:59:25, Roman Gushchin wrote: > > > > On Mon, Sep 25, 2017 at 10:25:21PM +0200, Michal Hocko

Re: DMA error when sg->offset value is greater than PAGE_SIZE in Intel IOMMU

On Tue, Sep 26, 2017 at 03:22:47PM +0100, Robin Murphy wrote: > diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c > index 6784a05dd6b2..d7f7def81613 100644 > --- a/drivers/iommu/intel-iommu.c > +++ b/drivers/iommu/intel-iommu.c > @@ -2254,10 +2254,12 @@ static int

Re: DMA error when sg->offset value is greater than PAGE_SIZE in Intel IOMMU

On Tue, Sep 26, 2017 at 03:22:47PM +0100, Robin Murphy wrote: > diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c > index 6784a05dd6b2..d7f7def81613 100644 > --- a/drivers/iommu/intel-iommu.c > +++ b/drivers/iommu/intel-iommu.c > @@ -2254,10 +2254,12 @@ static int

Re: [PATCH 2/7] xfs: validate bdev support for DAX inode flag

On Tue, Sep 26, 2017 at 08:36:50AM +0200, Christoph Hellwig wrote: > On Mon, Sep 25, 2017 at 05:13:59PM -0600, Ross Zwisler wrote: > > Currently only the blocksize is checked, but we should really be calling > > bdev_dax_supported() which also tests to make sure we can get a > > struct dax_device

Re: [PATCH 2/7] xfs: validate bdev support for DAX inode flag

On Tue, Sep 26, 2017 at 08:36:50AM +0200, Christoph Hellwig wrote: > On Mon, Sep 25, 2017 at 05:13:59PM -0600, Ross Zwisler wrote: > > Currently only the blocksize is checked, but we should really be calling > > bdev_dax_supported() which also tests to make sure we can get a > > struct dax_device

Re: [PATCH] KVM: VMX: check match table

On Mon, Sep 25, 2017 at 09:25:38PM -0700, Nick Desaulniers wrote: > Fixes the warning: > arch/x86/kvm/vmx.c:64:32: warning: variable 'vmx_cpu_id' is not needed > and will not be emitted [-Wunneeded-internal-declaration]`` > > Other callers of MODULE_DEVICE_TABLE() seem to check their second >

Re: [PATCH] KVM: VMX: check match table

On Mon, Sep 25, 2017 at 09:25:38PM -0700, Nick Desaulniers wrote: > Fixes the warning: > arch/x86/kvm/vmx.c:64:32: warning: variable 'vmx_cpu_id' is not needed > and will not be emitted [-Wunneeded-internal-declaration]`` > > Other callers of MODULE_DEVICE_TABLE() seem to check their second >

[PATCH] x86/apic: Do not use smp_processor_id() in preemptible code

From: Borislav Petkov Call stack is: check_preemption_disabled ? x2apic_prepare_cpu x2apic_dead_cpu cpuhp_invoke_callback ? cpuhp_kick_ap_work ? cpumask_next _cpu_down freeze_secondary_cpus hibernation_snapshot ... i.e., box is doing suspend-to-disk.

[PATCH] x86/apic: Do not use smp_processor_id() in preemptible code

From: Borislav Petkov Call stack is: check_preemption_disabled ? x2apic_prepare_cpu x2apic_dead_cpu cpuhp_invoke_callback ? cpuhp_kick_ap_work ? cpumask_next _cpu_down freeze_secondary_cpus hibernation_snapshot ... i.e., box is doing suspend-to-disk. Signed-off-by:

[PATCH] irq/irq_sim: implement irq_sim_baseirq()

Some users need to access the base of the allocated interrupt range. Although this can be calculated manually, it's more elegant to expose an interface for that. Signed-off-by: Bartosz Golaszewski --- When porting the iio_dummy_evgen to using irq_sim I needed to manually calculate

[PATCH] irq/irq_sim: implement irq_sim_baseirq()

Some users need to access the base of the allocated interrupt range. Although this can be calculated manually, it's more elegant to expose an interface for that. Signed-off-by: Bartosz Golaszewski --- When porting the iio_dummy_evgen to using irq_sim I needed to manually calculate the base

Re: [PATCH 1/6] f2fs: support issuing/waiting discard in range

On 09/19, Chao Yu wrote: > From: Chao Yu > > Fstrim intends to trim invalid blocks of filesystem only with specified > range and granularity, but actually, it will issue all previous cached > discard commands which may be out-of-range and be with unmatched > granularity, it's

Re: [PATCH 1/6] f2fs: support issuing/waiting discard in range

On 09/19, Chao Yu wrote: > From: Chao Yu > > Fstrim intends to trim invalid blocks of filesystem only with specified > range and granularity, but actually, it will issue all previous cached > discard commands which may be out-of-range and be with unmatched > granularity, it's unneeded. > > In

Re: [PATCH v2] p54: don't unregister leds when they are not initialized

On Tuesday, September 26, 2017 5:11:33 PM CEST Andrey Konovalov wrote: > ieee80211_register_hw() in p54_register_common() may fail and leds won't > get initialized. Currently p54_unregister_common() doesn't check that and > always calls p54_unregister_leds(). The fix is to check priv->registered >

Re: [PATCH v2] p54: don't unregister leds when they are not initialized

On Tuesday, September 26, 2017 5:11:33 PM CEST Andrey Konovalov wrote: > ieee80211_register_hw() in p54_register_common() may fail and leds won't > get initialized. Currently p54_unregister_common() doesn't check that and > always calls p54_unregister_leds(). The fix is to check priv->registered >

Re: [PATCH v5 REPOST 1/6] hw_random: place mutex around read functions and buffers.

On Tue, Sep 26, 2017 at 02:36:57AM -0400, Pankaj Gupta wrote: > > > > > A bit late to a party, but: > > > > On Mon, Dec 8, 2014 at 12:50 AM, Amos Kong wrote: > > > From: Rusty Russell > > > > > > There's currently a big lock around everything, and it

Re: [PATCH v5 REPOST 1/6] hw_random: place mutex around read functions and buffers.

On Tue, Sep 26, 2017 at 02:36:57AM -0400, Pankaj Gupta wrote: > > > > > A bit late to a party, but: > > > > On Mon, Dec 8, 2014 at 12:50 AM, Amos Kong wrote: > > > From: Rusty Russell > > > > > > There's currently a big lock around everything, and it means that we > > > can't query sysfs (eg

Re: [PATCH v1 0/4] Enable LBR for the guest

> On the other side, it seems that the (guest) kernel driver also works > without > the above being supported, should we change it to report error and stop > using the PMU features when the check of the above two fails (at > intel_pmu_init())? You could add the extra check for the LBR code yes,

Re: [PATCH v5 1/6] timekeeper: introduce extended clocksource reading callback

On 26/09/2017 00:00, Thomas Gleixner wrote: >> + * @read_with_stamp:saves cycles value (got from timekeeper) and >> cycles >> + * stamp (got from hardware counter value and used by >> + * timekeeper to calculate the cycles value) to >> + *

Re: [PATCH v1 0/4] Enable LBR for the guest

> On the other side, it seems that the (guest) kernel driver also works > without > the above being supported, should we change it to report error and stop > using the PMU features when the check of the above two fails (at > intel_pmu_init())? You could add the extra check for the LBR code yes,

Re: [PATCH v5 1/6] timekeeper: introduce extended clocksource reading callback

On 26/09/2017 00:00, Thomas Gleixner wrote: >> + * @read_with_stamp:saves cycles value (got from timekeeper) and >> cycles >> + * stamp (got from hardware counter value and used by >> + * timekeeper to calculate the cycles value) to >> + *

Re: [PATCH 1/6] [media] tda8261: Use common error handling code in tda8261_set_params()

>> @@ -129,18 +129,18 @@ static int tda8261_set_params(struct dvb_frontend *fe) >> >> /* Set params */ >> err = tda8261_write(state, buf); >> -if (err < 0) { >> -pr_err("%s: I/O Error\n", __func__); >> -return err; >> -} >> +err =

Re: [PATCH 3/5] dmaengine: Support for querying maximum trasnfer length (of an SG element)

On Fri, Sep 22, 2017 at 12:39:38PM +0300, Peter Ujfalusi wrote: > > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > > On 2017-09-21 20:14, Vinod Koul wrote: > > On Tue, Sep 12, 2017 at 01:44:22PM +0300, Peter

Re: [PATCH 1/6] [media] tda8261: Use common error handling code in tda8261_set_params()

>> @@ -129,18 +129,18 @@ static int tda8261_set_params(struct dvb_frontend *fe) >> >> /* Set params */ >> err = tda8261_write(state, buf); >> -if (err < 0) { >> -pr_err("%s: I/O Error\n", __func__); >> -return err; >> -} >> +err =

Re: [PATCH 3/5] dmaengine: Support for querying maximum trasnfer length (of an SG element)

On Fri, Sep 22, 2017 at 12:39:38PM +0300, Peter Ujfalusi wrote: > > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > > On 2017-09-21 20:14, Vinod Koul wrote: > > On Tue, Sep 12, 2017 at 01:44:22PM +0300, Peter

[PATCH] iio: dummy: evgen: use irq_sim

Switch to using the recently added interrupt simulator for dummy irqs. Signed-off-by: Bartosz Golaszewski --- bloat-o-meter output: add/remove: 0/3 grow/shrink: 1/5 up/down: 12/-540 (-528) function old new delta iio_dummy_evgen_get_irq

[PATCH] iio: dummy: evgen: use irq_sim

Switch to using the recently added interrupt simulator for dummy irqs. Signed-off-by: Bartosz Golaszewski --- bloat-o-meter output: add/remove: 0/3 grow/shrink: 1/5 up/down: 12/-540 (-528) function old new delta iio_dummy_evgen_get_irq

Re: [PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN

On 09/26/2017 09:47 AM, Arnd Bergmann wrote: > On Mon, Sep 25, 2017 at 11:32 PM, Arnd Bergmann wrote: >> On Mon, Sep 25, 2017 at 7:41 AM, David Laight >> wrote: >>> From: Arnd Bergmann Sent: 22 September 2017 22:29 >>> ... It seems that this

Re: [PATCH] [media] clk-kona-setup: Delete two error messages for a failed memory allocation in parent_process()

Thanks for cleanup. On 17-09-26 08:05 AM, SF Markus Elfring wrote: From: Markus Elfring Date: Tue, 26 Sep 2017 16:54:20 +0200 Omit extra messages for a memory allocation failure in this function. This issue was detected by using the Coccinelle software.

Re: [PATCH] [media] clk-kona-setup: Delete two error messages for a failed memory allocation in parent_process()

Thanks for cleanup. On 17-09-26 08:05 AM, SF Markus Elfring wrote: From: Markus Elfring Date: Tue, 26 Sep 2017 16:54:20 +0200 Omit extra messages for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring

Re: [PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN

On 09/26/2017 09:47 AM, Arnd Bergmann wrote: > On Mon, Sep 25, 2017 at 11:32 PM, Arnd Bergmann wrote: >> On Mon, Sep 25, 2017 at 7:41 AM, David Laight >> wrote: >>> From: Arnd Bergmann Sent: 22 September 2017 22:29 >>> ... It seems that this is triggered in part by using strlcpy(),

Re: [RESEND PATCH v5 4/4] ARM: configs: stm32: Add DMAMUX support in STM32 defconfig

On Fri, Sep 22, 2017 at 09:31:32AM +0200, Pierre-Yves MORDRET wrote: > This patch adds DMAMUX support in STM32 defconfig file Need ACK from ARM folks on this. > > Signed-off-by: M'boumba Cedric Madianga > Signed-off-by: Pierre-Yves MORDRET

Re: [RESEND PATCH v5 4/4] ARM: configs: stm32: Add DMAMUX support in STM32 defconfig

On Fri, Sep 22, 2017 at 09:31:32AM +0200, Pierre-Yves MORDRET wrote: > This patch adds DMAMUX support in STM32 defconfig file Need ACK from ARM folks on this. > > Signed-off-by: M'boumba Cedric Madianga > Signed-off-by: Pierre-Yves MORDRET > --- > Version history: > v5: > v4: >

[PATCH v5 06/10] drivers base/arch_topology: allow inlining cpu-invariant accounting support

Allow inlining of topology_get_cpu_scale() into the task scheduler fast path (e.g. __update_load_avg_se()) by coding it as a static inline function in the arch topology header file. Cc: Greg Kroah-Hartman Cc: Juri Lelli Signed-off-by: Dietmar

[PATCH v5 09/10] arm64: wire frequency-invariant accounting support up to the task scheduler

Commit dfbca41f3479 ("sched: Optimize freq invariant accounting") changed the wiring which now has to be done by associating arch_scale_freq_capacity with the actual implementation provided by the architecture. Define arch_scale_freq_capacity to use the arch_topology "driver" function

[PATCH v5 10/10] arm64: wire cpu-invariant accounting support up to the task scheduler

Commit 8cd5601c5060 ("sched/fair: Convert arch_scale_cpu_capacity() from weak function to #define") changed the wiring which now has to be done by associating arch_scale_cpu_capacity with the actual implementation provided by the architecture. Define arch_scale_cpu_capacity to use the

[PATCH v5 08/10] arm: wire cpu-invariant accounting support up to the task scheduler

Commit 8cd5601c5060 ("sched/fair: Convert arch_scale_cpu_capacity() from weak function to #define") changed the wiring which now has to be done by associating arch_scale_cpu_capacity with the actual implementation provided by the architecture. Define arch_scale_cpu_capacity to use the

[PATCH v5 05/10] drivers base/arch_topology: provide frequency-invariant accounting support

Implements the arch-specific (arm and arm64) frequency-invariance setter function arch_set_freq_scale() which provides the following frequency scaling factor: current_freq(cpu) << SCHED_CAPACITY_SHIFT / max_supported_freq(cpu) One possible consumer of the frequency-invariance getter function

[PATCH v5 03/10] cpufreq: arm_big_little: invoke frequency-invariance setter function

Call the frequency-invariance setter function arch_set_freq_scale() if the new frequency has been successfully set which is indicated by bL_cpufreq_set_rate() returning 0. Cc: Rafael J. Wysocki Cc: Viresh Kumar Cc: Sudeep Holla

[PATCH v5 07/10] arm: wire frequency-invariant accounting support up to the task scheduler

Commit dfbca41f3479 ("sched: Optimize freq invariant accounting") changed the wiring which now has to be done by associating arch_scale_freq_capacity with the actual implementation provided by the architecture. Define arch_scale_freq_capacity to use the arch_topology "driver" function

[PATCH v5 06/10] drivers base/arch_topology: allow inlining cpu-invariant accounting support

Allow inlining of topology_get_cpu_scale() into the task scheduler fast path (e.g. __update_load_avg_se()) by coding it as a static inline function in the arch topology header file. Cc: Greg Kroah-Hartman Cc: Juri Lelli Signed-off-by: Dietmar Eggemann Acked-by: Viresh Kumar ---

[PATCH v5 09/10] arm64: wire frequency-invariant accounting support up to the task scheduler

Commit dfbca41f3479 ("sched: Optimize freq invariant accounting") changed the wiring which now has to be done by associating arch_scale_freq_capacity with the actual implementation provided by the architecture. Define arch_scale_freq_capacity to use the arch_topology "driver" function

[PATCH v5 10/10] arm64: wire cpu-invariant accounting support up to the task scheduler

Commit 8cd5601c5060 ("sched/fair: Convert arch_scale_cpu_capacity() from weak function to #define") changed the wiring which now has to be done by associating arch_scale_cpu_capacity with the actual implementation provided by the architecture. Define arch_scale_cpu_capacity to use the

[PATCH v5 08/10] arm: wire cpu-invariant accounting support up to the task scheduler

Commit 8cd5601c5060 ("sched/fair: Convert arch_scale_cpu_capacity() from weak function to #define") changed the wiring which now has to be done by associating arch_scale_cpu_capacity with the actual implementation provided by the architecture. Define arch_scale_cpu_capacity to use the

[PATCH v5 05/10] drivers base/arch_topology: provide frequency-invariant accounting support

Implements the arch-specific (arm and arm64) frequency-invariance setter function arch_set_freq_scale() which provides the following frequency scaling factor: current_freq(cpu) << SCHED_CAPACITY_SHIFT / max_supported_freq(cpu) One possible consumer of the frequency-invariance getter function

[PATCH v5 03/10] cpufreq: arm_big_little: invoke frequency-invariance setter function

Call the frequency-invariance setter function arch_set_freq_scale() if the new frequency has been successfully set which is indicated by bL_cpufreq_set_rate() returning 0. Cc: Rafael J. Wysocki Cc: Viresh Kumar Cc: Sudeep Holla Signed-off-by: Dietmar Eggemann Acked-by: Viresh Kumar ---

[PATCH v5 07/10] arm: wire frequency-invariant accounting support up to the task scheduler

Commit dfbca41f3479 ("sched: Optimize freq invariant accounting") changed the wiring which now has to be done by associating arch_scale_freq_capacity with the actual implementation provided by the architecture. Define arch_scale_freq_capacity to use the arch_topology "driver" function

[PATCH v5 04/10] cpufreq: dt: invoke frequency-invariance setter function

Call the frequency-invariance setter function arch_set_freq_scale() if the new frequency has been successfully set which is indicated by dev_pm_opp_set_rate() returning 0. Cc: Rafael J. Wysocki Cc: Viresh Kumar Signed-off-by: Dietmar Eggemann

[PATCH v5 04/10] cpufreq: dt: invoke frequency-invariance setter function

Call the frequency-invariance setter function arch_set_freq_scale() if the new frequency has been successfully set which is indicated by dev_pm_opp_set_rate() returning 0. Cc: Rafael J. Wysocki Cc: Viresh Kumar Signed-off-by: Dietmar Eggemann Acked-by: Viresh Kumar ---

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