[PATCH 7/7] x86: switch the VIA 32-bit DMA quirk to use the struct device flag

Instead of globally disabling > 32bit DMA using the arch_dma_supported hook walk the PCI bus under the actually affected bridge and mark every device with the dma_32bit_limit flag. This also gets rid of the arch_dma_supported hook entirely. Signed-off-by: Christoph Hellwig ---

[PATCH 7/7] x86: switch the VIA 32-bit DMA quirk to use the struct device flag

Instead of globally disabling > 32bit DMA using the arch_dma_supported hook walk the PCI bus under the actually affected bridge and mark every device with the dma_32bit_limit flag. This also gets rid of the arch_dma_supported hook entirely. Signed-off-by: Christoph Hellwig ---

[PATCH] udmabuf: fix odd_ptr_err.cocci warnings

From: kbuild test robot drivers/dma-buf/udmabuf.c:167:6-12: inconsistent IS_ERR and PTR_ERR on line 168. PTR_ERR should access the value just tested by IS_ERR Semantic patch information: There can be false positives in the patch case, where it is the call to IS_ERR

[PATCH] udmabuf: fix odd_ptr_err.cocci warnings

From: kbuild test robot drivers/dma-buf/udmabuf.c:167:6-12: inconsistent IS_ERR and PTR_ERR on line 168. PTR_ERR should access the value just tested by IS_ERR Semantic patch information: There can be false positives in the patch case, where it is the call to IS_ERR that is wrong. Generated

[PATCH v11 3/4] arm64: Implement page table free interfaces

Implement pud_free_pmd_page() and pmd_free_pte_page(). Implementation requires, 1) Clearing off the current pud/pmd entry 2) Invalidate TLB which could have previously valid but not stale entry 3) Freeing of the un-used next level page tables Signed-off-by: Chintan Pandya

[PATCH v11 3/4] arm64: Implement page table free interfaces

Implement pud_free_pmd_page() and pmd_free_pte_page(). Implementation requires, 1) Clearing off the current pud/pmd entry 2) Invalidate TLB which could have previously valid but not stale entry 3) Freeing of the un-used next level page tables Signed-off-by: Chintan Pandya ---

[PATCH v11 2/4] arm64: tlbflush: Introduce __flush_tlb_kernel_pgtable

Add an interface to invalidate intermediate page tables from TLB for kernel. Signed-off-by: Chintan Pandya --- arch/arm64/include/asm/tlbflush.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm64/include/asm/tlbflush.h

[PATCH v11 1/4] ioremap: Update pgtable free interfaces with addr

From: Chintan Pandya The following kernel panic was observed on ARM64 platform due to a stale TLB entry. 1. ioremap with 4K size, a valid pte page table is set. 2. iounmap it, its pte entry is set to 0. 3. ioremap the same address with 2M size, update its pmd entry

[PATCH v11 2/4] arm64: tlbflush: Introduce __flush_tlb_kernel_pgtable

Add an interface to invalidate intermediate page tables from TLB for kernel. Signed-off-by: Chintan Pandya --- arch/arm64/include/asm/tlbflush.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h index

[PATCH v11 1/4] ioremap: Update pgtable free interfaces with addr

From: Chintan Pandya The following kernel panic was observed on ARM64 platform due to a stale TLB entry. 1. ioremap with 4K size, a valid pte page table is set. 2. iounmap it, its pte entry is set to 0. 3. ioremap the same address with 2M size, update its pmd entry with a new value. 4.

[PATCH v11 4/4] Revert "arm64: Enforce BBM for huge IO/VMAP mappings"

This commit 15122ee2c515a ("arm64: Enforce BBM for huge IO/VMAP mappings") is a temporary work-around until the issues with CONFIG_HAVE_ARCH_HUGE_VMAP gets fixed. Revert this change as we have fixes for the issue. Signed-off-by: Chintan Pandya --- arch/arm64/mm/mmu.c |

[PATCH v11 4/4] Revert "arm64: Enforce BBM for huge IO/VMAP mappings"

This commit 15122ee2c515a ("arm64: Enforce BBM for huge IO/VMAP mappings") is a temporary work-around until the issues with CONFIG_HAVE_ARCH_HUGE_VMAP gets fixed. Revert this change as we have fixes for the issue. Signed-off-by: Chintan Pandya --- arch/arm64/mm/mmu.c | 8 1 file

[PATCH v11 0/4] Fix issues with huge mapping in ioremap for ARM64

This series of patches re-bring huge vmap back for arm64. Patch 1/4 has been taken by Toshi in his series of patches by name "[PATCH v3 0/3] fix free pmd/pte page handlings on x86" to avoid merge conflict with this series. Patch 4/4 may conflict with Laura's patch "[PATCHv2] arm64: Make sure

[PATCH v11 0/4] Fix issues with huge mapping in ioremap for ARM64

This series of patches re-bring huge vmap back for arm64. Patch 1/4 has been taken by Toshi in his series of patches by name "[PATCH v3 0/3] fix free pmd/pte page handlings on x86" to avoid merge conflict with this series. Patch 4/4 may conflict with Laura's patch "[PATCHv2] arm64: Make sure

Re: [PATCH v5 01/10] sched/pelt: Move pelt related code in a dedicated file

Hi Vincent, On Friday 25 May 2018 at 15:12:22 (+0200), Vincent Guittot wrote: > We want to track rt_rq's utilization as a part of the estimation of the > whole rq's utilization. This is necessary because rt tasks can steal > utilization to cfs tasks and make them lighter than they are. > As we

Re: [PATCH v5 01/10] sched/pelt: Move pelt related code in a dedicated file

Hi Vincent, On Friday 25 May 2018 at 15:12:22 (+0200), Vincent Guittot wrote: > We want to track rt_rq's utilization as a part of the estimation of the > whole rq's utilization. This is necessary because rt tasks can steal > utilization to cfs tasks and make them lighter than they are. > As we

Re: [PATCH 0/3] Provide more fine grained control over multipathing

On Fri, May 25, 2018 at 04:22:17PM +0200, Johannes Thumshirn wrote: > But Mike's and Hannes' arguments where reasonable as well, we do not > know if there are any existing setups we might break leading to > support calls, which we have to deal with. Personally I don't believe > there are lot's of

Re: [PATCH 0/3] Provide more fine grained control over multipathing

On Fri, May 25, 2018 at 04:22:17PM +0200, Johannes Thumshirn wrote: > But Mike's and Hannes' arguments where reasonable as well, we do not > know if there are any existing setups we might break leading to > support calls, which we have to deal with. Personally I don't believe > there are lot's of

[PATCH v4] usbip: dynamically allocate idev by nports found in sysfs

As the amount of available ports varies by the kernels build configuration. To remove the limitation of the fixed 128 ports we allocate the amount of idevs by using the number we get from the kernel. Signed-off-by: Michael Grzeschik --- v1 -> v2: - reworked memory

[PATCH v4] usbip: dynamically allocate idev by nports found in sysfs

As the amount of available ports varies by the kernels build configuration. To remove the limitation of the fixed 128 ports we allocate the amount of idevs by using the number we get from the kernel. Signed-off-by: Michael Grzeschik --- v1 -> v2: - reworked memory allocation into one calloc call

Re: [PATCH v2 5/5] MAINTAINERS: Add Actions Semi S900 pinctrl entries

On Fri, May 25, 2018 at 02:12:06PM +0200, Linus Walleij wrote: > On Fri, May 25, 2018 at 7:01 AM, Manivannan Sadhasivam > wrote: > > > FYI, I have ordered S700 based Cubieboard and will work on adding support > > for > > that first. I still don't have access to

Re: [PATCH v2 5/5] MAINTAINERS: Add Actions Semi S900 pinctrl entries

On Fri, May 25, 2018 at 02:12:06PM +0200, Linus Walleij wrote: > On Fri, May 25, 2018 at 7:01 AM, Manivannan Sadhasivam > wrote: > > > FYI, I have ordered S700 based Cubieboard and will work on adding support > > for > > that first. I still don't have access to S500 board yet since it is not >

Re: [PATCH V4] mlx4_core: allocate ICM memory in page size chunks

From: Qing Huang Date: Wed, 23 May 2018 16:22:46 -0700 > When a system is under memory presure (high usage with fragments), > the original 256KB ICM chunk allocations will likely trigger kernel > memory management to enter slow path doing memory compact/migration > ops in

Re: [PATCH V4] mlx4_core: allocate ICM memory in page size chunks

From: Qing Huang Date: Wed, 23 May 2018 16:22:46 -0700 > When a system is under memory presure (high usage with fragments), > the original 256KB ICM chunk allocations will likely trigger kernel > memory management to enter slow path doing memory compact/migration > ops in order to complete high

Re: [PATCH 0/3] Provide more fine grained control over multipathing

On Fri, May 25, 2018 at 03:05:35PM +0200, Christoph Hellwig wrote: > On Fri, May 25, 2018 at 02:53:19PM +0200, Johannes Thumshirn wrote: > > Hi, > > > > This patch series aims to provide a more fine grained control over > > nvme's native multipathing, by allowing it to be switched on and off > >

Re: [PATCH 0/3] Provide more fine grained control over multipathing

On Fri, May 25, 2018 at 03:05:35PM +0200, Christoph Hellwig wrote: > On Fri, May 25, 2018 at 02:53:19PM +0200, Johannes Thumshirn wrote: > > Hi, > > > > This patch series aims to provide a more fine grained control over > > nvme's native multipathing, by allowing it to be switched on and off > >

Re: [PATCH] ath10k: transmit queued frames after waking queues

On Fri, May 25, 2018 at 08:50:23AM -0400, Bob Copeland wrote: > On Fri, May 25, 2018 at 02:36:56PM +0200, Niklas Cassel wrote: > > A spin lock does have the advantage of ordering: memory operations issued > > before the spin_unlock_bh() will be completed before the spin_unlock_bh() > > operation

Re: [PATCH] ath10k: transmit queued frames after waking queues

On Fri, May 25, 2018 at 08:50:23AM -0400, Bob Copeland wrote: > On Fri, May 25, 2018 at 02:36:56PM +0200, Niklas Cassel wrote: > > A spin lock does have the advantage of ordering: memory operations issued > > before the spin_unlock_bh() will be completed before the spin_unlock_bh() > > operation

Re: [PATCH v2 1/2] rcu: Update documentation of rcu_read_unlock()

On Fri, May 25, 2018 at 11:05:06AM +0200, Anna-Maria Gleixner wrote: > Since commit b4abf91047cf ("rtmutex: Make wait_lock irq safe") the > explanation in rcu_read_unlock() documentation about irq unsafe rtmutex > wait_lock is no longer valid. > > Remove it to prevent kernel developers reading

Re: [PATCH v2 1/2] rcu: Update documentation of rcu_read_unlock()

On Fri, May 25, 2018 at 11:05:06AM +0200, Anna-Maria Gleixner wrote: > Since commit b4abf91047cf ("rtmutex: Make wait_lock irq safe") the > explanation in rcu_read_unlock() documentation about irq unsafe rtmutex > wait_lock is no longer valid. > > Remove it to prevent kernel developers reading

Re: [PATCH] ARM: dts: imx51-zii-rdu1: Make sure SD1_WP is low

Am Donnerstag, den 24.05.2018, 20:01 -0700 schrieb Andrey Smirnov: > Make sure that MX51_PAD_GPIO1_1 does not remain configure as > ALT0/SD1_WP (it is out of reset). This is needed because of external > pull-up resistor attached to that pad that, when left unchanged, will > drive SD1_WP high

Re: [PATCH] ARM: dts: imx51-zii-rdu1: Make sure SD1_WP is low

Am Donnerstag, den 24.05.2018, 20:01 -0700 schrieb Andrey Smirnov: > Make sure that MX51_PAD_GPIO1_1 does not remain configure as > ALT0/SD1_WP (it is out of reset). This is needed because of external > pull-up resistor attached to that pad that, when left unchanged, will > drive SD1_WP high

KASAN: use-after-free Write in tls_push_record

Hello, syzbot found the following crash on: HEAD commit:13405468f49d bpfilter: don't pass O_CREAT when opening con.. git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=109ad82f80 kernel config: https://syzkaller.appspot.com/x/.config?x=8be0182d69f8d422

KASAN: use-after-free Write in tls_push_record

Hello, syzbot found the following crash on: HEAD commit:13405468f49d bpfilter: don't pass O_CREAT when opening con.. git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=109ad82f80 kernel config: https://syzkaller.appspot.com/x/.config?x=8be0182d69f8d422

Re: [PATCH 4.4 00/92] 4.4.133-stable review

On Thu, May 24, 2018 at 09:47:42PM +0200, Greg Kroah-Hartman wrote: > On Thu, May 24, 2018 at 10:32:08AM -0700, Guenter Roeck wrote: > > On Thu, May 24, 2018 at 11:37:37AM +0200, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 4.4.133 release. > > > There are

Re: [PATCH 4.4 00/92] 4.4.133-stable review

On Thu, May 24, 2018 at 09:47:42PM +0200, Greg Kroah-Hartman wrote: > On Thu, May 24, 2018 at 10:32:08AM -0700, Guenter Roeck wrote: > > On Thu, May 24, 2018 at 11:37:37AM +0200, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 4.4.133 release. > > > There are

Re: [alsa-devel] [RFC/RFT PATCH] ASoC: topology: Improve backwards compatibility with v4 topology files

On Fri, May 25, 2018 at 6:42 AM Shreyas NC wrote: > > > > +struct skl_dfw_v4_pipe { > > > > + u8 pipe_id; > > > > + u8 pipe_priority; > > > > + u16 conn_type:4; > > > > + u16 rsvd:4; > > > > + u16 memory_pages:8; > > > > +} __packed; > > > > + > > > >

Re: [alsa-devel] [RFC/RFT PATCH] ASoC: topology: Improve backwards compatibility with v4 topology files

On Fri, May 25, 2018 at 6:42 AM Shreyas NC wrote: > > > > +struct skl_dfw_v4_pipe { > > > > + u8 pipe_id; > > > > + u8 pipe_priority; > > > > + u16 conn_type:4; > > > > + u16 rsvd:4; > > > > + u16 memory_pages:8; > > > > +} __packed; > > > > + > > > > +struct

[PATCH v3] Add udmabuf misc device

A driver to let userspace turn memfd regions into dma-bufs. Use case: Allows qemu create dmabufs for the vga framebuffer or virtio-gpu ressources. Then they can be passed around to display those guest things on the host. To spice client for classic full framebuffer display, and hopefully some

[PATCH v3] Add udmabuf misc device

A driver to let userspace turn memfd regions into dma-bufs. Use case: Allows qemu create dmabufs for the vga framebuffer or virtio-gpu ressources. Then they can be passed around to display those guest things on the host. To spice client for classic full framebuffer display, and hopefully some

Re: [PATCH v3 6/6] tty/serial: atmel: changed the driver to work under at91-usart mfd

On 05/25/2018 04:35 PM, Richard Genoud wrote: On 25/05/2018 14:17, Radu Pirea wrote: On 05/15/2018 04:14 PM, Richard Genoud wrote: On 15/05/2018 14:47, Radu Pirea wrote: On Mon, 2018-05-14 at 12:57 +0200, Richard Genoud wrote: After your patch, the DMA is not selected anymore:

Re: [PATCH v3 6/6] tty/serial: atmel: changed the driver to work under at91-usart mfd

On 05/25/2018 04:35 PM, Richard Genoud wrote: On 25/05/2018 14:17, Radu Pirea wrote: On 05/15/2018 04:14 PM, Richard Genoud wrote: On 15/05/2018 14:47, Radu Pirea wrote: On Mon, 2018-05-14 at 12:57 +0200, Richard Genoud wrote: After your patch, the DMA is not selected anymore:

Re: [PATCH 0/3] Provide more fine grained control over multipathing

On Fri, May 25, 2018 at 09:58:13AM -0400, Mike Snitzer wrote: > We all basically knew this would be your position. But at this year's > LSF we pretty quickly reached consensus that we do in fact need this. > Except for yourself, Sagi and afaik Martin George: all on the cc were in > attendance and

Re: [PATCH 0/3] Provide more fine grained control over multipathing

On Fri, May 25, 2018 at 09:58:13AM -0400, Mike Snitzer wrote: > We all basically knew this would be your position. But at this year's > LSF we pretty quickly reached consensus that we do in fact need this. > Except for yourself, Sagi and afaik Martin George: all on the cc were in > attendance and

Re: [PATCH 04/12] powerpc: Implement hw_breakpoint_arch_parse()

On Thu, May 24, 2018 at 12:01:52PM +1000, Michael Ellerman wrote: > Frederic Weisbecker writes: > > > diff --git a/arch/powerpc/kernel/hw_breakpoint.c > > b/arch/powerpc/kernel/hw_breakpoint.c > > index 348cac9..fba6527 100644 > > --- a/arch/powerpc/kernel/hw_breakpoint.c >

Re: [PATCH] userfaultfd: prevent non-cooperative events vs mcopy_atomic races

>> But doesn't it race even with regular PF handling, not only the fork? How >> do we handle this race? > > With the regular #PF handing, the faulting thread patiently waits until > page fault is resolved. With fork(), mremap() etc the thread that caused > the event resumes once the uffd message

Re: [PATCH 04/12] powerpc: Implement hw_breakpoint_arch_parse()

On Thu, May 24, 2018 at 12:01:52PM +1000, Michael Ellerman wrote: > Frederic Weisbecker writes: > > > diff --git a/arch/powerpc/kernel/hw_breakpoint.c > > b/arch/powerpc/kernel/hw_breakpoint.c > > index 348cac9..fba6527 100644 > > --- a/arch/powerpc/kernel/hw_breakpoint.c > > +++

Re: [PATCH] userfaultfd: prevent non-cooperative events vs mcopy_atomic races

>> But doesn't it race even with regular PF handling, not only the fork? How >> do we handle this race? > > With the regular #PF handing, the faulting thread patiently waits until > page fault is resolved. With fork(), mremap() etc the thread that caused > the event resumes once the uffd message

Re: [PATCH] Bluetooth: Add a new Realtek 8723DE ID 0bda:b009

Hi Daniel, 2018-05-25 21:25 GMT+08:00 Daniel Drake : > Hi Jian-Hong, > > On Fri, May 25, 2018 at 3:54 AM, Jian-Hong Pan wrote: >> >> Without this patch we cannot turn on the Bluethooth adapter on HP >> 14-bs007la. > > Please correct me if I'm wrong,

Re: [PATCH] Bluetooth: Add a new Realtek 8723DE ID 0bda:b009

Hi Daniel, 2018-05-25 21:25 GMT+08:00 Daniel Drake : > Hi Jian-Hong, > > On Fri, May 25, 2018 at 3:54 AM, Jian-Hong Pan wrote: >> >> Without this patch we cannot turn on the Bluethooth adapter on HP >> 14-bs007la. > > Please correct me if I'm wrong, but it looks like we are still waiting > for

Re: [PATCH v2 10/10] vfio: ccw: Let user wait when busy on IO

On Fri, May 25, 2018 at 12:21:18PM +0200, Pierre Morel wrote: > In the current implementation, we do not want to start a new SSCH > command before the last one ends. > > Currently the user needs to poll on the -EBUSY error to > wait before sending a new request. > > Let's be friendly with global

Re: [PATCH v2 10/10] vfio: ccw: Let user wait when busy on IO

On Fri, May 25, 2018 at 12:21:18PM +0200, Pierre Morel wrote: > In the current implementation, we do not want to start a new SSCH > command before the last one ends. > > Currently the user needs to poll on the -EBUSY error to > wait before sending a new request. > > Let's be friendly with global

[PATCH] PCI: Try to clean up resources via remove if shutdown doesn't exist

It is up to a driver to implement shutdown() callback. If shutdown() callback is not implemented, PCI device can have pending interrupt and even do DMA transactions while the system is going down. If kexec is in use, this can damage the newly booting kexec kernel or even prevent it from booting

[PATCH] PCI: Try to clean up resources via remove if shutdown doesn't exist

It is up to a driver to implement shutdown() callback. If shutdown() callback is not implemented, PCI device can have pending interrupt and even do DMA transactions while the system is going down. If kexec is in use, this can damage the newly booting kexec kernel or even prevent it from booting

Re: [RFT v2 1/4] perf cs-etm: Generate sample for missed packets

Hi Leo, Following the discussions from your reply to this with a simplified patch, this version of the patch works better as you also need to emit a branch sample when handling a CS_ETM_TRACE_ON packet to indicate the end of a block of trace. This patch does not break the output from perf

Re: [RFT v2 1/4] perf cs-etm: Generate sample for missed packets

Hi Leo, Following the discussions from your reply to this with a simplified patch, this version of the patch works better as you also need to emit a branch sample when handling a CS_ETM_TRACE_ON packet to indicate the end of a block of trace. This patch does not break the output from perf

Re: OMAP serial runtime PM and autosuspend (was: Re: [PATCH 4/7] dt-bindings: gnss: add u-blox binding))

On Thu, May 24, 2018 at 06:32:37AM -0700, Tony Lindgren wrote: > * Johan Hovold [180524 09:20]: > > On Mon, May 21, 2018 at 08:48:32AM -0700, Tony Lindgren wrote: > > > Well if you have some better mechanism in mind let's try it out. Short of > > > sprinkling

Re: OMAP serial runtime PM and autosuspend (was: Re: [PATCH 4/7] dt-bindings: gnss: add u-blox binding))

On Thu, May 24, 2018 at 06:32:37AM -0700, Tony Lindgren wrote: > * Johan Hovold [180524 09:20]: > > On Mon, May 21, 2018 at 08:48:32AM -0700, Tony Lindgren wrote: > > > Well if you have some better mechanism in mind let's try it out. Short of > > > sprinkling pm_runtime_force_suspend/resume

Re: Turris Omnia firmware possibilities [Was: Re: led: hw-trigger, global brightness and multi-colored leds]

On Fri, May 25, 2018 at 8:08 AM, Uwe Kleine-König wrote: > Hello Tomas, > > On 05/25/2018 12:08 AM, Tomas Hlavacek wrote: >> But I also have good news: The FW of the MCU is also OSS (see the repo >> in the link (1)). There is a method for flashing the MCU over I2C from >>

Re: Turris Omnia firmware possibilities [Was: Re: led: hw-trigger, global brightness and multi-colored leds]

On Fri, May 25, 2018 at 8:08 AM, Uwe Kleine-König wrote: > Hello Tomas, > > On 05/25/2018 12:08 AM, Tomas Hlavacek wrote: >> But I also have good news: The FW of the MCU is also OSS (see the repo >> in the link (1)). There is a method for flashing the MCU over I2C from >> Linux and there is JTAG

Re: [PATCH 0/3] Provide more fine grained control over multipathing

On Fri, May 25 2018 at 9:05am -0400, Christoph Hellwig wrote: > On Fri, May 25, 2018 at 02:53:19PM +0200, Johannes Thumshirn wrote: > > Hi, > > > > This patch series aims to provide a more fine grained control over > > nvme's native multipathing, by allowing it to be switched on

Re: [PATCH 0/3] Provide more fine grained control over multipathing

On Fri, May 25 2018 at 9:05am -0400, Christoph Hellwig wrote: > On Fri, May 25, 2018 at 02:53:19PM +0200, Johannes Thumshirn wrote: > > Hi, > > > > This patch series aims to provide a more fine grained control over > > nvme's native multipathing, by allowing it to be switched on and off > > on

Re: [PATCH 01/12] perf/breakpoint: Split attribute parse and commit

On Thu, May 24, 2018 at 11:56:01AM +1000, Michael Ellerman wrote: > Frederic Weisbecker writes: > > > diff --git a/kernel/events/hw_breakpoint.c b/kernel/events/hw_breakpoint.c > > index 6e28d28..51320c2 100644 > > --- a/kernel/events/hw_breakpoint.c > > +++

Re: [PATCH 01/12] perf/breakpoint: Split attribute parse and commit

On Thu, May 24, 2018 at 11:56:01AM +1000, Michael Ellerman wrote: > Frederic Weisbecker writes: > > > diff --git a/kernel/events/hw_breakpoint.c b/kernel/events/hw_breakpoint.c > > index 6e28d28..51320c2 100644 > > --- a/kernel/events/hw_breakpoint.c > > +++ b/kernel/events/hw_breakpoint.c > >

Re: [RFT v2 1/4] perf cs-etm: Generate sample for missed packets

Hi Leo, On 23/05/18 14:22, Leo Yan wrote: Hi Rob, On Wed, May 23, 2018 at 12:21:18PM +0100, Robert Walker wrote: Hi Leo, On 22/05/18 10:52, Leo Yan wrote: On Tue, May 22, 2018 at 04:39:20PM +0800, Leo Yan wrote: [...] Rather than the patch I posted in my previous email, I think below new

Re: [RFT v2 1/4] perf cs-etm: Generate sample for missed packets

Hi Leo, On 23/05/18 14:22, Leo Yan wrote: Hi Rob, On Wed, May 23, 2018 at 12:21:18PM +0100, Robert Walker wrote: Hi Leo, On 22/05/18 10:52, Leo Yan wrote: On Tue, May 22, 2018 at 04:39:20PM +0800, Leo Yan wrote: [...] Rather than the patch I posted in my previous email, I think below new

Re: [PATCH] PCI: hv: Do not wait forever on a device that has disappeared

On Wed, May 23, 2018 at 09:12:01PM +, Dexuan Cui wrote: > > Before the guest finishes the device initialization, the device can be > removed anytime by the host, and after that the host won't respond to > the guest's request, so the guest should be prepared to handle this > case. > >

Re: [PATCH] PCI: hv: Do not wait forever on a device that has disappeared

On Wed, May 23, 2018 at 09:12:01PM +, Dexuan Cui wrote: > > Before the guest finishes the device initialization, the device can be > removed anytime by the host, and after that the host won't respond to > the guest's request, so the guest should be prepared to handle this > case. > >

[PATCH 1/2] regmap: add missing prototype for devm_init_slimbus

For some reason the devm variant of slimbus init is not added into the header eventhough this __devm_regmap_init_slimbus() is an exported function. This patch adds this. This also fixes below warning in regmap-slimbus.c regmap-slimbus.c:65:15: warning: symbol '__devm_regmap_init_slimbus' was not

[PATCH 1/2] regmap: add missing prototype for devm_init_slimbus

For some reason the devm variant of slimbus init is not added into the header eventhough this __devm_regmap_init_slimbus() is an exported function. This patch adds this. This also fixes below warning in regmap-slimbus.c regmap-slimbus.c:65:15: warning: symbol '__devm_regmap_init_slimbus' was not

[PATCH 2/2] regmap: slimbus: allow register offsets up to 16 bits

As per SLIMBus specs Value Elements and Information Elements address map ranges from 0x000 - 0xFFF. So allow register addresses up to 16 bits Fixes: 7d6f7fb053ad ("regmap: add SLIMbus support") Signed-off-by: Srinivas Kandagatla ---

[PATCH 2/2] regmap: slimbus: allow register offsets up to 16 bits

As per SLIMBus specs Value Elements and Information Elements address map ranges from 0x000 - 0xFFF. So allow register addresses up to 16 bits Fixes: 7d6f7fb053ad ("regmap: add SLIMbus support") Signed-off-by: Srinivas Kandagatla --- drivers/base/regmap/regmap-slimbus.c | 2 +- 1 file changed,

[PATCH 0/2] regmap: slimbus: minor fixes.

Here are 2 minor fixes for regmap slimbus. Thanks, srini Srinivas Kandagatla (2): regmap: add missing prototype for devm_init_slimbus regmap: slimbus: allow register offsets up to 16 bits drivers/base/regmap/regmap-slimbus.c | 2 +- include/linux/regmap.h | 18

[PATCH 0/2] regmap: slimbus: minor fixes.

Here are 2 minor fixes for regmap slimbus. Thanks, srini Srinivas Kandagatla (2): regmap: add missing prototype for devm_init_slimbus regmap: slimbus: allow register offsets up to 16 bits drivers/base/regmap/regmap-slimbus.c | 2 +- include/linux/regmap.h | 18

Re: KASAN: use-after-free Read in ccid2_hc_tx_packet_recv

syzbot has found a reproducer for the following crash on: HEAD commit:b50694381cfc Merge branch 'stable/for-linus-4.17' of git:/.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=17151cb780 kernel config:

Re: KASAN: use-after-free Read in ccid2_hc_tx_packet_recv

syzbot has found a reproducer for the following crash on: HEAD commit:b50694381cfc Merge branch 'stable/for-linus-4.17' of git:/.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=17151cb780 kernel config:

Re: [PATCH 1/3] nvme: provide a way to disable nvme mpath per subsystem

On Fri, May 25 2018 at 8:53am -0400, Johannes Thumshirn wrote: > Provide a way to disable NVMe native multipathing on a per-subsystem > basis to enable a user to use dm-mpath and nvme native multipathing on > the same host for different nvme devices. > > Signed-off-by:

Re: [PATCH v2] bpf, arm32: Correct check_imm24

On 05/11/2018 05:06 AM, Wang YanQing wrote: > imm24 is signed, so the right range is: > [-(1<<(24 - 1)), (1<<(24 - 1)) - 1] > > Note:this patch also fix a typo. > > Signed-off-by: Wang YanQing Through which tree will this fix be routed? (And the cleanup in "[PATCH v2] bpf,

Re: [PATCH 1/3] nvme: provide a way to disable nvme mpath per subsystem

On Fri, May 25 2018 at 8:53am -0400, Johannes Thumshirn wrote: > Provide a way to disable NVMe native multipathing on a per-subsystem > basis to enable a user to use dm-mpath and nvme native multipathing on > the same host for different nvme devices. > > Signed-off-by: Johannes Thumshirn

Re: [PATCH v2] bpf, arm32: Correct check_imm24

On 05/11/2018 05:06 AM, Wang YanQing wrote: > imm24 is signed, so the right range is: > [-(1<<(24 - 1)), (1<<(24 - 1)) - 1] > > Note:this patch also fix a typo. > > Signed-off-by: Wang YanQing Through which tree will this fix be routed? (And the cleanup in "[PATCH v2] bpf, arm32: Fix

Re: [PATCH v4 00/26] arm64: provide pseudo NMI with GICv3

On 25/05/18 11:40, Julien Thierry wrote: On 25/05/18 11:16, Daniel Thompson wrote: On Fri, May 25, 2018 at 10:49:06AM +0100, Julien Thierry wrote: This series is a continuation of the work started by Daniel [1]. The goal is to use GICv3 interrupt priorities to simulate an NMI. To achieve

Re: [PATCH v4 00/26] arm64: provide pseudo NMI with GICv3

On 25/05/18 11:40, Julien Thierry wrote: On 25/05/18 11:16, Daniel Thompson wrote: On Fri, May 25, 2018 at 10:49:06AM +0100, Julien Thierry wrote: This series is a continuation of the work started by Daniel [1]. The goal is to use GICv3 interrupt priorities to simulate an NMI. To achieve

Re: [alsa-devel] [RFC/RFT PATCH] ASoC: topology: Improve backwards compatibility with v4 topology files

> > > +struct skl_dfw_v4_pipe { > > > + u8 pipe_id; > > > + u8 pipe_priority; > > > + u16 conn_type:4; > > > + u16 rsvd:4; > > > + u16 memory_pages:8; > > > +} __packed; > > > + > > > +struct skl_dfw_v4_module { > > > + char uuid[SKL_UUID_STR_SZ]; > > > + Any reason to not

Re: [alsa-devel] [RFC/RFT PATCH] ASoC: topology: Improve backwards compatibility with v4 topology files

> > > +struct skl_dfw_v4_pipe { > > > + u8 pipe_id; > > > + u8 pipe_priority; > > > + u16 conn_type:4; > > > + u16 rsvd:4; > > > + u16 memory_pages:8; > > > +} __packed; > > > + > > > +struct skl_dfw_v4_module { > > > + char uuid[SKL_UUID_STR_SZ]; > > > + Any reason to not

Re: [PATCH v3 6/6] tty/serial: atmel: changed the driver to work under at91-usart mfd

On 25/05/2018 14:17, Radu Pirea wrote: > > > On 05/15/2018 04:14 PM, Richard Genoud wrote: >> On 15/05/2018 14:47, Radu Pirea wrote: >>> On Mon, 2018-05-14 at 12:57 +0200, Richard Genoud wrote: After your patch, the DMA is not selected anymore: atmel_usart_serial

Re: [PATCH v3 6/6] tty/serial: atmel: changed the driver to work under at91-usart mfd

On 25/05/2018 14:17, Radu Pirea wrote: > > > On 05/15/2018 04:14 PM, Richard Genoud wrote: >> On 15/05/2018 14:47, Radu Pirea wrote: >>> On Mon, 2018-05-14 at 12:57 +0200, Richard Genoud wrote: After your patch, the DMA is not selected anymore: atmel_usart_serial

Re: [alsa-devel] [PATCH v2 1/3] ASoC: topology: Improve backwards compatibility with v4 topology files

Adding Vinod to help review as well.. > Commit dc31e741db49 ("ASoC: topology: ABI - Add the types for BE > DAI") introduced sound topology files version 5. Initially, this > change made the topology code incompatible with v4 topology files. > Backwards compatibility with v4 configuration files was

Re: [alsa-devel] [PATCH v2 1/3] ASoC: topology: Improve backwards compatibility with v4 topology files

Adding Vinod to help review as well.. > Commit dc31e741db49 ("ASoC: topology: ABI - Add the types for BE > DAI") introduced sound topology files version 5. Initially, this > change made the topology code incompatible with v4 topology files. > Backwards compatibility with v4 configuration files was

Re: [PATCH] powerpc/64s: Clear PCR on boot

On Fri, May 18, 2018 at 11:37:42AM +1000, Michael Neuling wrote: > Clear the PCR (Processor Compatibility Register) on boot to ensure we > are not running in a compatibility mode. > > We've seen this cause problems when a crash (and kdump) occurs while > running compat mode guests. The kdump

Re: [PATCH] powerpc/64s: Clear PCR on boot

On Fri, May 18, 2018 at 11:37:42AM +1000, Michael Neuling wrote: > Clear the PCR (Processor Compatibility Register) on boot to ensure we > are not running in a compatibility mode. > > We've seen this cause problems when a crash (and kdump) occurs while > running compat mode guests. The kdump

Re: [PATCH V2] PCI/portdrv: do not disable device on reboot/shutdown

On 5/24/2018 2:35 PM, Bjorn Helgaas wrote: > That sounds like a reasonable idea, and it is definitely another can > of worms. I looked briefly at some of the .shutdown() cases: should we throw it into 4.18 and see what happens? -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an

Re: [PATCH V2] PCI/portdrv: do not disable device on reboot/shutdown

On 5/24/2018 2:35 PM, Bjorn Helgaas wrote: > That sounds like a reasonable idea, and it is definitely another can > of worms. I looked briefly at some of the .shutdown() cases: should we throw it into 4.18 and see what happens? -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an

Re: [PATCH] ath6kl: mark expected switch fall-throughs

Sergei Shtylyov writes: > On 5/25/2018 2:13 AM, Gustavo A. R. Silva wrote: > >> In preparation to enabling -Wimplicit-fallthrough, mark switch cases >> where we are expecting to fall through. >> >> Signed-off-by: Gustavo A. R. Silva >>

Re: [PATCH] ath6kl: mark expected switch fall-throughs

Sergei Shtylyov writes: > On 5/25/2018 2:13 AM, Gustavo A. R. Silva wrote: > >> In preparation to enabling -Wimplicit-fallthrough, mark switch cases >> where we are expecting to fall through. >> >> Signed-off-by: Gustavo A. R. Silva >> --- >> drivers/net/wireless/ath/ath6kl/cfg80211.c | 6

Re: [PATCH] Bluetooth: Add a new Realtek 8723DE ID 0bda:b009

Hi Jian-Hong, On Fri, May 25, 2018 at 3:54 AM, Jian-Hong Pan wrote: > > Without this patch we cannot turn on the Bluethooth adapter on HP > 14-bs007la. Please correct me if I'm wrong, but it looks like we are still waiting for the testing of this patch from our

Re: [PATCH] Bluetooth: Add a new Realtek 8723DE ID 0bda:b009

Hi Jian-Hong, On Fri, May 25, 2018 at 3:54 AM, Jian-Hong Pan wrote: > > Without this patch we cannot turn on the Bluethooth adapter on HP > 14-bs007la. Please correct me if I'm wrong, but it looks like we are still waiting for the testing of this patch from our colleagues in Guatemala. There

Re: [alsa-devel] [RFC/RFT PATCH] ASoC: topology: Improve backwards compatibility with v4 topology files

On Fri, May 25, 2018 at 2:04 AM Lin, Mengdong wrote: > > -Original Message- > > From: alsa-devel-boun...@alsa-project.org [mailto: alsa-devel-bounces@alsa- > > project.org] On Behalf Of Mark Brown > > Sent: Thursday, May 24, 2018 11:12 PM > > On Thu, May 24, 2018

Re: [alsa-devel] [RFC/RFT PATCH] ASoC: topology: Improve backwards compatibility with v4 topology files

On Fri, May 25, 2018 at 2:04 AM Lin, Mengdong wrote: > > -Original Message- > > From: alsa-devel-boun...@alsa-project.org [mailto: alsa-devel-bounces@alsa- > > project.org] On Behalf Of Mark Brown > > Sent: Thursday, May 24, 2018 11:12 PM > > On Thu, May 24, 2018 at 07:55:06AM -0700,

[PATCH v5 04/10] sched/dl: add dl_rq utilization tracking

Similarly to what happens with rt tasks, cfs tasks can be preempted by dl tasks and the cfs's utilization might no longer describes the real utilization level. Current dl bandwidth reflects the requirements to meet deadline when tasks are enqueued but not the current utilization of the dl sched

[PATCH v5 04/10] sched/dl: add dl_rq utilization tracking

Similarly to what happens with rt tasks, cfs tasks can be preempted by dl tasks and the cfs's utilization might no longer describes the real utilization level. Current dl bandwidth reflects the requirements to meet deadline when tasks are enqueued but not the current utilization of the dl sched

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