Re: [PATCH v2 1/3] dt-bindings: iio: adc: stm32: add support for diff channels

On Wed, Oct 25, 2017 at 11:27:43AM +0200, Fabrice Gasnier wrote: > STM32H7 ADC channels may be configured either as single-ended or > differential. > Add 'st,adc-diff-channels' property to support differential channels. > Differential channels are defined as a pair of positive and negative >

Re: [PATCH v2 1/3] dt-bindings: iio: adc: stm32: add support for diff channels

On Wed, Oct 25, 2017 at 11:27:43AM +0200, Fabrice Gasnier wrote: > STM32H7 ADC channels may be configured either as single-ended or > differential. > Add 'st,adc-diff-channels' property to support differential channels. > Differential channels are defined as a pair of positive and negative >

Re: [PATCH v2 3/9] dt-bindings: interrupt-controllers: add compatible string for stm32h7

On Wed, Oct 25, 2017 at 07:10:59PM +0200, Ludovic Barre wrote: > From: Ludovic Barre > > This patch updates stm32-exti documentation with stm32h7-exti > compatible string. > > Signed-off-by: Ludovic Barre > --- >

Re: [PATCH v2 3/9] dt-bindings: interrupt-controllers: add compatible string for stm32h7

On Wed, Oct 25, 2017 at 07:10:59PM +0200, Ludovic Barre wrote: > From: Ludovic Barre > > This patch updates stm32-exti documentation with stm32h7-exti > compatible string. > > Signed-off-by: Ludovic Barre > --- > .../devicetree/bindings/interrupt-controller/st,stm32-exti.txt| 4 >

[PATCH v5 06/26] KVM: arm/arm64: vITS: Add MSI translation helpers

The whole MSI injection process is fairly monolithic. An MSI write gets turned into an injected LPI in one swift go. But this is actually a more fine-grained process: - First, a virtual ITS gets selected using the doorbell address - Then the DevID/EventID pair gets translated into an LPI -

[PATCH v5 06/26] KVM: arm/arm64: vITS: Add MSI translation helpers

The whole MSI injection process is fairly monolithic. An MSI write gets turned into an injected LPI in one swift go. But this is actually a more fine-grained process: - First, a virtual ITS gets selected using the doorbell address - Then the DevID/EventID pair gets translated into an LPI -

Re: [PATCH 3/3] dt-bindings: timer: Add andestech atcpit100 timer binding doc

On Wed, Oct 25, 2017 at 01:12:13PM +0800, rick wrote: Commit msg? > Signed-off-by: rick > Signed-off-by: rick Need a full name. > Signed-off-by: Greentime Hu S-o-b should be in chronological order of who touched the code. And

Re: [PATCH 3/3] dt-bindings: timer: Add andestech atcpit100 timer binding doc

On Wed, Oct 25, 2017 at 01:12:13PM +0800, rick wrote: Commit msg? > Signed-off-by: rick > Signed-off-by: rick Need a full name. > Signed-off-by: Greentime Hu S-o-b should be in chronological order of who touched the code. And the sender should be last. > --- >

Re: [tip:sched/core] sched/isolation: Document the isolcpus= flags

2017-10-27 15:58 UTC+02:00, Peter Zijlstra : > On Fri, Oct 27, 2017 at 05:06:25AM -0700, tip-bot for Frederic Weisbecker > wrote: >> +isolcpus= [KNL,SMP] Isolate a given set of CPUs from disturbance. >> +Format: [flag-list,] >> + >> +

Re: [tip:sched/core] sched/isolation: Document the isolcpus= flags

2017-10-27 15:58 UTC+02:00, Peter Zijlstra : > On Fri, Oct 27, 2017 at 05:06:25AM -0700, tip-bot for Frederic Weisbecker > wrote: >> +isolcpus= [KNL,SMP] Isolate a given set of CPUs from disturbance. >> +Format: [flag-list,] >> + >> +Specify one or

[PATCH v5 04/26] KVM: arm: Select ARM_GIC_V3 and ARM_GIC_V3_ITS

The GICv4 support introduces a hard dependency between the KVM core and the ITS infrastructure. arm64 already selects it at the architecture level, but 32bit doesn't. In order to avoid littering the kernel with #ifdefs, let's just select the whole of the GICv3 suport code. You know you want it.

[PATCH v5 09/26] KVM: arm/arm64: GICv4: Add init/teardown of the per-VM vPE irq domain

In order to control the GICv4 view of virtual CPUs, we rely on an irqdomain allocated for that purpose. Let's add a couple of helpers to that effect. At the same time, the vgic data structures gain new fields to track all this... erm... wonderful stuff. The way we hook into the vgic init is

[PATCH v5 04/26] KVM: arm: Select ARM_GIC_V3 and ARM_GIC_V3_ITS

The GICv4 support introduces a hard dependency between the KVM core and the ITS infrastructure. arm64 already selects it at the architecture level, but 32bit doesn't. In order to avoid littering the kernel with #ifdefs, let's just select the whole of the GICv3 suport code. You know you want it.

[PATCH v5 09/26] KVM: arm/arm64: GICv4: Add init/teardown of the per-VM vPE irq domain

In order to control the GICv4 view of virtual CPUs, we rely on an irqdomain allocated for that purpose. Let's add a couple of helpers to that effect. At the same time, the vgic data structures gain new fields to track all this... erm... wonderful stuff. The way we hook into the vgic init is

[PATCH v5 08/26] KVM: arm/arm64: GICv4: Add property field and per-VM predicate

Add a new has_gicv4 field in the global VGIC state that indicates whether the HW is GICv4 capable, as a per-VM predicate indicating if there is a possibility for a VM to support direct injection (the above being true and the VM having an ITS). Reviewed-by: Christoffer Dall

[PATCH v5 08/26] KVM: arm/arm64: GICv4: Add property field and per-VM predicate

Add a new has_gicv4 field in the global VGIC state that indicates whether the HW is GICv4 capable, as a per-VM predicate indicating if there is a possibility for a VM to support direct injection (the above being true and the VM having an ITS). Reviewed-by: Christoffer Dall Signed-off-by: Marc

[PATCH v5 10/26] KVM: arm/arm64: GICv4: Wire mapping/unmapping of VLPIs in VFIO irq bypass

Let's use the irq bypass mechanism introduced for platform device interrupts to intercept the virtual PCIe endpoint configuration and establish our LPI->VLPI mapping. Reviewed-by: Christoffer Dall Signed-off-by: Marc Zyngier ---

[PATCH v5 10/26] KVM: arm/arm64: GICv4: Wire mapping/unmapping of VLPIs in VFIO irq bypass

Let's use the irq bypass mechanism introduced for platform device interrupts to intercept the virtual PCIe endpoint configuration and establish our LPI->VLPI mapping. Reviewed-by: Christoffer Dall Signed-off-by: Marc Zyngier --- include/kvm/arm_vgic.h | 8 virt/kvm/arm/arm.c

Re: [PATCH 03/14] VFS: Implement a filesystem superblock creation/configuration context [ver #6]

Miklos Szeredi wrote: > Also, how about moving calls to vfs_parse_fs_option() into filesystem > code? Even those options are not generic, some filesystem wants > this, some that. It's just a historical accident that those are set > with MS_FOO and not "foo". Filesystems

Re: [PATCH 03/14] VFS: Implement a filesystem superblock creation/configuration context [ver #6]

Miklos Szeredi wrote: > Also, how about moving calls to vfs_parse_fs_option() into filesystem > code? Even those options are not generic, some filesystem wants > this, some that. It's just a historical accident that those are set > with MS_FOO and not "foo". Filesystems that don't have any

[PATCH v5 13/26] KVM: arm/arm64: GICv4: Propagate affinity changes to the physical ITS

When the guest issues an affinity change, we need to tell the physical ITS that we're now targetting a new vcpu. This is done by extracting the current mapping, updating the target, and reapplying the mapping. Reviewed-by: Christoffer Dall Signed-off-by: Marc

[PATCH v5 13/26] KVM: arm/arm64: GICv4: Propagate affinity changes to the physical ITS

When the guest issues an affinity change, we need to tell the physical ITS that we're now targetting a new vcpu. This is done by extracting the current mapping, updating the target, and reapplying the mapping. Reviewed-by: Christoffer Dall Signed-off-by: Marc Zyngier ---

[PATCH v5 14/26] KVM: arm/arm64: GICv4: Handle CLEAR applied to a VLPI

Handling CLEAR is pretty easy. Just ask the ITS driver to clear the corresponding pending bit (which will turn into a CLEAR command on the physical side). Acked-by: Christoffer Dall Signed-off-by: Marc Zyngier --- virt/kvm/arm/vgic/vgic-its.c | 4 1

[PATCH v5 14/26] KVM: arm/arm64: GICv4: Handle CLEAR applied to a VLPI

Handling CLEAR is pretty easy. Just ask the ITS driver to clear the corresponding pending bit (which will turn into a CLEAR command on the physical side). Acked-by: Christoffer Dall Signed-off-by: Marc Zyngier --- virt/kvm/arm/vgic/vgic-its.c | 4 1 file changed, 4 insertions(+) diff

Re: [PATCH 3/5] staging: fsl-dpaa2/eth: Don't account SWA in tx_data_offset

On Fri, Oct 27, 2017 at 02:31:22PM +, Bogdan Purcareata wrote: > > -Original Message- > > From: Dan Carpenter [mailto:dan.carpen...@oracle.com] > > Sent: Friday, October 27, 2017 5:27 PM > > To: Bogdan Purcareata > > Cc: Ruxandra Ioana Radulescu

Re: [PATCH 3/5] staging: fsl-dpaa2/eth: Don't account SWA in tx_data_offset

On Fri, Oct 27, 2017 at 02:31:22PM +, Bogdan Purcareata wrote: > > -Original Message- > > From: Dan Carpenter [mailto:dan.carpen...@oracle.com] > > Sent: Friday, October 27, 2017 5:27 PM > > To: Bogdan Purcareata > > Cc: Ruxandra Ioana Radulescu ; > > gre...@linuxfoundation.org;

Re: [PATCH net] net: stmmac: First Queue must always be in DCB mode

From: Jose Abreu Date: Thu, 26 Oct 2017 10:07:12 +0100 > According to DWMAC databook the first queue operating mode > must always be in DCB. > > As MTL_QUEUE_DCB = 1, we need to always set the first queue > operating mode to DCB otherwise driver will think that queue >

Re: [PATCH net] net: stmmac: First Queue must always be in DCB mode

From: Jose Abreu Date: Thu, 26 Oct 2017 10:07:12 +0100 > According to DWMAC databook the first queue operating mode > must always be in DCB. > > As MTL_QUEUE_DCB = 1, we need to always set the first queue > operating mode to DCB otherwise driver will think that queue > is in AVB mode (because

Re: [PATCH 1/2] dt-bindings: add binding for A64 DE2 CCU with SRAM section

在 2017-10-16 20:09，Maxime Ripard 写道： On Mon, Oct 16, 2017 at 05:41:10PM +0800, icen...@aosc.io wrote: 在 2017-10-16 17:11，Maxime Ripard 写道： > On Sat, Oct 14, 2017 at 08:29:24PM +0800, Icenowy Zheng wrote: > > A64's Display Engine 2.0 needs a section of SRAM (SRAM C) to be > > claimed. > > Why?

[PATCH v5 16/26] KVM: arm/arm64: GICv4: Propagate property updates to VLPIs

Upon updating a property, we propagate it all the way to the physical ITS, and ask for an INV command to be executed there. Acked-by: Christoffer Dall Signed-off-by: Marc Zyngier --- virt/kvm/arm/vgic/vgic-its.c | 3 +++ 1 file changed, 3 insertions(+)

[PATCH v5 16/26] KVM: arm/arm64: GICv4: Propagate property updates to VLPIs

Upon updating a property, we propagate it all the way to the physical ITS, and ask for an INV command to be executed there. Acked-by: Christoffer Dall Signed-off-by: Marc Zyngier --- virt/kvm/arm/vgic/vgic-its.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

Re: [PATCH 1/2] dt-bindings: add binding for A64 DE2 CCU with SRAM section

在 2017-10-16 20:09，Maxime Ripard 写道： On Mon, Oct 16, 2017 at 05:41:10PM +0800, icen...@aosc.io wrote: 在 2017-10-16 17:11，Maxime Ripard 写道： > On Sat, Oct 14, 2017 at 08:29:24PM +0800, Icenowy Zheng wrote: > > A64's Display Engine 2.0 needs a section of SRAM (SRAM C) to be > > claimed. > > Why?

[PATCH v5 18/26] KVM: arm/arm64: GICv4: Use pending_last as a scheduling hint

When a vPE exits, the pending_last flag is set when there are pending VLPIs stored in the pending table. Similarily, we set this flag when a doorbell interrupt fires, as it indicates the same condition. Let's update kvm_vgic_vcpu_pending_irq() to account for that flag as well, making a vcpu

[PATCH v5 18/26] KVM: arm/arm64: GICv4: Use pending_last as a scheduling hint

When a vPE exits, the pending_last flag is set when there are pending VLPIs stored in the pending table. Similarily, we set this flag when a doorbell interrupt fires, as it indicates the same condition. Let's update kvm_vgic_vcpu_pending_irq() to account for that flag as well, making a vcpu

[PATCH v5 19/26] KVM: arm/arm64: GICv4: Add doorbell interrupt handling

When a vPE is not running, a VLPI being made pending results in a doorbell interrupt being delivered. Let's handle this interrupt and update the pending_last flag that indicates that VLPIs are pending. The corresponding vcpu is also kicked into action. Special care is taken to prevent the

[PATCH v5 19/26] KVM: arm/arm64: GICv4: Add doorbell interrupt handling

When a vPE is not running, a VLPI being made pending results in a doorbell interrupt being delivered. Let's handle this interrupt and update the pending_last flag that indicates that VLPIs are pending. The corresponding vcpu is also kicked into action. Special care is taken to prevent the

[PATCH v5 23/26] KVM: arm/arm64: GICv4: Prevent a VM using GICv4 from being saved

The GICv4 architecture doesn't make it easy for save/restore to work, as it doesn't give any guarantee that the pending state is written into the pending table. So let's not take any chance, and let's return an error if we encounter any LPI that has the HW bit set. In order for userspace to

[PATCH v5 23/26] KVM: arm/arm64: GICv4: Prevent a VM using GICv4 from being saved

The GICv4 architecture doesn't make it easy for save/restore to work, as it doesn't give any guarantee that the pending state is written into the pending table. So let's not take any chance, and let's return an error if we encounter any LPI that has the HW bit set. In order for userspace to

[PATCH v5 21/26] KVM: arm/arm64: GICv4: Hook vPE scheduling into vgic flush/sync

The redistributor needs to be told which vPE is about to be run, and tells us whether there is any pending VLPI on exit. Let's add the scheduling calls to the vgic flush/sync functions, allowing the VLPIs to be delivered to the guest. Reviewed-by: Christoffer Dall

[PATCH v5 21/26] KVM: arm/arm64: GICv4: Hook vPE scheduling into vgic flush/sync

The redistributor needs to be told which vPE is about to be run, and tells us whether there is any pending VLPI on exit. Let's add the scheduling calls to the vgic flush/sync functions, allowing the VLPIs to be delivered to the guest. Reviewed-by: Christoffer Dall Signed-off-by: Marc Zyngier

[PATCH v5 25/26] KVM: arm/arm64: GICv4: Enable VLPI support

All it takes is the has_v4 flag to be set in gic_kvm_info as well as "kvm-arm.vgic_v4_enable=1" being passed on the command line for GICv4 to be enabled in KVM. Acked-by: Christoffer Dall Signed-off-by: Marc Zyngier ---

RE: [PATCH 3/5] staging: fsl-dpaa2/eth: Don't account SWA in tx_data_offset

> -Original Message- > From: Dan Carpenter [mailto:dan.carpen...@oracle.com] > Sent: Friday, October 27, 2017 5:27 PM > To: Bogdan Purcareata > Cc: Ruxandra Ioana Radulescu ; > gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;

RE: [PATCH 3/5] staging: fsl-dpaa2/eth: Don't account SWA in tx_data_offset

> -Original Message- > From: Dan Carpenter [mailto:dan.carpen...@oracle.com] > Sent: Friday, October 27, 2017 5:27 PM > To: Bogdan Purcareata > Cc: Ruxandra Ioana Radulescu ; > gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > de...@driverdev.osuosl.org > Subject: Re: [PATCH

[PATCH v5 25/26] KVM: arm/arm64: GICv4: Enable VLPI support

All it takes is the has_v4 flag to be set in gic_kvm_info as well as "kvm-arm.vgic_v4_enable=1" being passed on the command line for GICv4 to be enabled in KVM. Acked-by: Christoffer Dall Signed-off-by: Marc Zyngier --- Documentation/admin-guide/kernel-parameters.txt | 4

Re: [PATCH 4/5] staging: fsl-dpaa2/eth: Change RX buffer alignment

On Fri, Oct 27, 2017 at 02:11:35PM +, Bogdan Purcareata wrote: > @@ -93,10 +100,10 @@ > * buffers large enough to allow building an skb around them and also account > * for alignment restrictions > */ > -#define DPAA2_ETH_BUF_RAW_SIZE \ > +#define DPAA2_ETH_BUF_RAW_SIZE(priv) \ >

Re: [PATCH 4/5] staging: fsl-dpaa2/eth: Change RX buffer alignment

On Fri, Oct 27, 2017 at 02:11:35PM +, Bogdan Purcareata wrote: > @@ -93,10 +100,10 @@ > * buffers large enough to allow building an skb around them and also account > * for alignment restrictions > */ > -#define DPAA2_ETH_BUF_RAW_SIZE \ > +#define DPAA2_ETH_BUF_RAW_SIZE(priv) \ >

Re: [PATCH v2 net-next 0/2] net: dsa: lan9303: Learn addresses on CPU port when bridged

From: Egil Hjelmeland Date: Thu, 26 Oct 2017 11:00:47 +0200 > When CPU transmit directly to port using tag, the LAN9303 does not > learn MAC addresses received on the CPU port into the ALR table. > ALR learning is performed only when transmitting using ALR lookup. > >

Re: [PATCH v2 net-next 0/2] net: dsa: lan9303: Learn addresses on CPU port when bridged

From: Egil Hjelmeland Date: Thu, 26 Oct 2017 11:00:47 +0200 > When CPU transmit directly to port using tag, the LAN9303 does not > learn MAC addresses received on the CPU port into the ALR table. > ALR learning is performed only when transmitting using ALR lookup. > > Solution: > If the two

[PATCH v5 24/26] KVM: arm/arm64: GICv4: Prevent userspace from changing doorbell affinity

We so far allocate the doorbell interrupts without taking any special measure regarding the affinity of these interrupts. We simply move them around as required when the vcpu gets scheduled on a different CPU. But that's counting without userspace (and the evil irqbalance) that can try and move

[PATCH v5 24/26] KVM: arm/arm64: GICv4: Prevent userspace from changing doorbell affinity

We so far allocate the doorbell interrupts without taking any special measure regarding the affinity of these interrupts. We simply move them around as required when the vcpu gets scheduled on a different CPU. But that's counting without userspace (and the evil irqbalance) that can try and move

Re: PROBLEM: Remapping hugepages mappings causes kernel to return EINVAL

On 10/24/2017 09:41 AM, C.Wehrmeyer wrote: > On 2017-10-23 20:02, Michal Hocko wrote: >> On Mon 23-10-17 19:52:27, C.Wehrmeyer wrote: >> [...] or you can mmap a larger block and munmap the initial unaligned part. >>> >>> And how is that supposed to be transparent? When I hear

Re: PROBLEM: Remapping hugepages mappings causes kernel to return EINVAL

On 10/24/2017 09:41 AM, C.Wehrmeyer wrote: > On 2017-10-23 20:02, Michal Hocko wrote: >> On Mon 23-10-17 19:52:27, C.Wehrmeyer wrote: >> [...] or you can mmap a larger block and munmap the initial unaligned part. >>> >>> And how is that supposed to be transparent? When I hear

[PATCH v5 26/26] KVM: arm/arm64: GICv4: Theory of operations

Yet another braindump so I can free some cells... Acked-by: Christoffer Dall Signed-off-by: Marc Zyngier --- virt/kvm/arm/vgic/vgic-v4.c | 67 + 1 file changed, 67 insertions(+) diff --git

[PATCH v5 26/26] KVM: arm/arm64: GICv4: Theory of operations

Yet another braindump so I can free some cells... Acked-by: Christoffer Dall Signed-off-by: Marc Zyngier --- virt/kvm/arm/vgic/vgic-v4.c | 67 + 1 file changed, 67 insertions(+) diff --git a/virt/kvm/arm/vgic/vgic-v4.c b/virt/kvm/arm/vgic/vgic-v4.c

[PATCH v5 22/26] KVM: arm/arm64: GICv4: Enable virtual cpuif if VLPIs can be delivered

In order for VLPIs to be delivered to the guest, we must make sure that the cpuif is always enabled, irrespective of the presence of virtual interrupt in the LRs. Acked-by: Christoffer Dall Signed-off-by: Marc Zyngier --- virt/kvm/arm/hyp/vgic-v3-sr.c |

[PATCH v5 20/26] KVM: arm/arm64: GICv4: Use the doorbell interrupt as an unblocking source

The doorbell interrupt is only useful if the vcpu is blocked on WFI. In all other cases, recieving a doorbell interrupt is just a waste of cycles. So let's only enable the doorbell if a vcpu is getting blocked, and disable it when it is unblocked. This is very similar to what we're doing for the

[PATCH v5 22/26] KVM: arm/arm64: GICv4: Enable virtual cpuif if VLPIs can be delivered

In order for VLPIs to be delivered to the guest, we must make sure that the cpuif is always enabled, irrespective of the presence of virtual interrupt in the LRs. Acked-by: Christoffer Dall Signed-off-by: Marc Zyngier --- virt/kvm/arm/hyp/vgic-v3-sr.c | 9 ++--- 1 file changed, 6

[PATCH v5 20/26] KVM: arm/arm64: GICv4: Use the doorbell interrupt as an unblocking source

The doorbell interrupt is only useful if the vcpu is blocked on WFI. In all other cases, recieving a doorbell interrupt is just a waste of cycles. So let's only enable the doorbell if a vcpu is getting blocked, and disable it when it is unblocked. This is very similar to what we're doing for the

[PATCH v5 15/26] KVM: arm/arm64: GICv4: Handle MOVALL applied to a vPE

The current implementation of MOVALL doesn't allow us to call into the core ITS code as we hold a number of spinlocks. Let's try a method used in other parts of the code, were we copy the intids of the candicate interrupts, and then do whatever we need to do with them outside of the critical

[PATCH v5 17/26] KVM: arm/arm64: GICv4: Handle INVALL applied to a vPE

Since when updating the properties one LPI at a time, there is no need to perform an INV each time we read one. Instead, we rely on the final VINVALL that gets sent to the ITS to do the work. Acked-by: Christoffer Dall Signed-off-by: Marc Zyngier ---

[PATCH v5 15/26] KVM: arm/arm64: GICv4: Handle MOVALL applied to a vPE

The current implementation of MOVALL doesn't allow us to call into the core ITS code as we hold a number of spinlocks. Let's try a method used in other parts of the code, were we copy the intids of the candicate interrupts, and then do whatever we need to do with them outside of the critical

[PATCH v5 17/26] KVM: arm/arm64: GICv4: Handle INVALL applied to a vPE

Since when updating the properties one LPI at a time, there is no need to perform an INV each time we read one. Instead, we rely on the final VINVALL that gets sent to the ITS to do the work. Acked-by: Christoffer Dall Signed-off-by: Marc Zyngier --- virt/kvm/arm/vgic/vgic-its.c | 15

[PATCH v5 11/26] KVM: arm/arm64: GICv4: Handle INT command applied to a VLPI

If the guest issues an INT command targetting a VLPI, let's call into the irq_set_irqchip_state() helper to make it pending on the physical side. This works just as well if userspace decides to inject an interrupt using the normal userspace API... Acked-by: Christoffer Dall

[PATCH v5 07/26] KVM: arm/arm64: vITS: Add a helper to update the affinity of an LPI

In order help integrating the vITS code with GICv4, let's add a new helper that deals with updating the affinity of an LPI, which will later be augmented with super duper extra GICv4 goodness. Reviewed-by: Christoffer Dall Signed-off-by: Marc Zyngier

[PATCH v5 05/26] KVM: arm/arm64: vgic: Move kvm_vgic_destroy call around

The way we call kvm_vgic_destroy is a bit bizarre. We call it *after* having freed the vcpus, which sort of defeats the point of cleaning up things before that point. Let's move kvm_vgic_destroy towards the beginning of kvm_arch_destroy_vm, which seems more sensible. Acked-by: Christoffer Dall

[PATCH v5 12/26] KVM: arm/arm64: GICv4: Unmap VLPI when freeing an LPI

When freeing an LPI (on a DISCARD command, for example), we need to unmap the VLPI down to the physical ITS level. Acked-by: Christoffer Dall Signed-off-by: Marc Zyngier --- virt/kvm/arm/vgic/vgic-its.c | 6 +- 1 file changed, 5 insertions(+), 1

[PATCH v5 12/26] KVM: arm/arm64: GICv4: Unmap VLPI when freeing an LPI

When freeing an LPI (on a DISCARD command, for example), we need to unmap the VLPI down to the physical ITS level. Acked-by: Christoffer Dall Signed-off-by: Marc Zyngier --- virt/kvm/arm/vgic/vgic-its.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git

[PATCH v5 11/26] KVM: arm/arm64: GICv4: Handle INT command applied to a VLPI

If the guest issues an INT command targetting a VLPI, let's call into the irq_set_irqchip_state() helper to make it pending on the physical side. This works just as well if userspace decides to inject an interrupt using the normal userspace API... Acked-by: Christoffer Dall Signed-off-by: Marc

[PATCH v5 07/26] KVM: arm/arm64: vITS: Add a helper to update the affinity of an LPI

In order help integrating the vITS code with GICv4, let's add a new helper that deals with updating the affinity of an LPI, which will later be augmented with super duper extra GICv4 goodness. Reviewed-by: Christoffer Dall Signed-off-by: Marc Zyngier --- virt/kvm/arm/vgic/vgic-its.c | 20

[PATCH v5 05/26] KVM: arm/arm64: vgic: Move kvm_vgic_destroy call around

The way we call kvm_vgic_destroy is a bit bizarre. We call it *after* having freed the vcpus, which sort of defeats the point of cleaning up things before that point. Let's move kvm_vgic_destroy towards the beginning of kvm_arch_destroy_vm, which seems more sensible. Acked-by: Christoffer Dall

[PATCH v5 01/26] irqchip/gic-v3-its: Setup VLPI properties at map time

So far, we require the hypervisor to update the VLPI properties once the the VLPI mapping has been established. While this makes it easy for the ITS driver, it creates a window where an incoming interrupt can be delivered with an unknown set of properties. Not very nice. Instead, let's add a

[PATCH v5 01/26] irqchip/gic-v3-its: Setup VLPI properties at map time

So far, we require the hypervisor to update the VLPI properties once the the VLPI mapping has been established. While this makes it easy for the ITS driver, it creates a window where an incoming interrupt can be delivered with an unknown set of properties. Not very nice. Instead, let's add a

[PATCH v5 00/26] KVM/ARM: Add support for GICv4

This series implements full support for GICv4 in KVM, bringing direct injection of MSIs to arm and arm64, assuming you have the right hardware (which is quite unlikely). To get an idea of the design, I'd recommend you start with commit 7954907bedaf as well as patch #26, which try to shed some

[PATCH v5 00/26] KVM/ARM: Add support for GICv4

This series implements full support for GICv4 in KVM, bringing direct injection of MSIs to arm and arm64, assuming you have the right hardware (which is quite unlikely). To get an idea of the design, I'd recommend you start with commit 7954907bedaf as well as patch #26, which try to shed some

Re: [PATCH 3/5] staging: fsl-dpaa2/eth: Don't account SWA in tx_data_offset

On Fri, Oct 27, 2017 at 02:11:34PM +, Bogdan Purcareata wrote: > When configuring the Tx buffer layout, the software annotation size is > mentioned, and MC accounts for it when configuring the frame > tx_data_offset. No need to handle it in the driver as well. > The impact is that we

Re: [PATCH 3/5] staging: fsl-dpaa2/eth: Don't account SWA in tx_data_offset

On Fri, Oct 27, 2017 at 02:11:34PM +, Bogdan Purcareata wrote: > When configuring the Tx buffer layout, the software annotation size is > mentioned, and MC accounts for it when configuring the frame > tx_data_offset. No need to handle it in the driver as well. > The impact is that we

Re: [PATCH net] net: stmmac: dwc-qos-eth: Fix typo in DT bindings parsing

From: Jose Abreu Date: Thu, 26 Oct 2017 09:51:33 +0100 > According to DT bindings documentation we are expecting a > property called "snps,read-requests" but we are parsing > instead a property called "read,read-requests". > > This is clearly a typo. Fix it. > >

Re: [PATCH net] net: stmmac: dwc-qos-eth: Fix typo in DT bindings parsing

From: Jose Abreu Date: Thu, 26 Oct 2017 09:51:33 +0100 > According to DT bindings documentation we are expecting a > property called "snps,read-requests" but we are parsing > instead a property called "read,read-requests". > > This is clearly a typo. Fix it. > > Signed-off-by: Jose Abreu

Re: [PATCH] staging: ccree: Fix indentation in ssi_buffer_mgr.c

On Fri, 2017-10-27 at 11:32 +0300, Dan Carpenter wrote: > On Thu, Oct 26, 2017 at 06:53:42PM -0700, Stephen Brennan wrote: > > In particular, fixes some over-indented if statement bodies as well as a > > couple lines indented with spaces. checkpatch.pl now reports no warnings > > on this file

Re: [PATCH] staging: ccree: Fix indentation in ssi_buffer_mgr.c

On Fri, 2017-10-27 at 11:32 +0300, Dan Carpenter wrote: > On Thu, Oct 26, 2017 at 06:53:42PM -0700, Stephen Brennan wrote: > > In particular, fixes some over-indented if statement bodies as well as a > > couple lines indented with spaces. checkpatch.pl now reports no warnings > > on this file

Re: [PATCH v9 3/7] mailbox: qcom: Move the apcs struct into a separate header

Hi Bjorn, Thanks for reviewing! On 10/26/2017 07:28 AM, Bjorn Andersson wrote: > On Thu 21 Sep 09:49 PDT 2017, Georgi Djakov wrote: > >> Move the structure shared by the APCS IPC device and its subdevices >> into a separate header file. >> > > As you're creating the apcs regmap with

Re: [PATCH v9 3/7] mailbox: qcom: Move the apcs struct into a separate header

Hi Bjorn, Thanks for reviewing! On 10/26/2017 07:28 AM, Bjorn Andersson wrote: > On Thu 21 Sep 09:49 PDT 2017, Georgi Djakov wrote: > >> Move the structure shared by the APCS IPC device and its subdevices >> into a separate header file. >> > > As you're creating the apcs regmap with

Re: [PATCH] perf: Fix header.size for namespace events

On Fri, Oct 27, 2017 at 09:43:11AM +0200, Jiri Olsa wrote: > Reset header size for namespace events, otherwise > it only gets bigger in ctx iterations. > > Cc: Hari Bathini > Link: http://lkml.kernel.org/n/tip-nlo4gonz9d4guyb8153uk...@git.kernel.org > Signed-off-by:

Re: [PATCH] perf: Fix header.size for namespace events

On Fri, Oct 27, 2017 at 09:43:11AM +0200, Jiri Olsa wrote: > Reset header size for namespace events, otherwise > it only gets bigger in ctx iterations. > > Cc: Hari Bathini > Link: http://lkml.kernel.org/n/tip-nlo4gonz9d4guyb8153uk...@git.kernel.org > Signed-off-by: Jiri Olsa Fixes:

Re: [PATCH] kprobes, x86/alternatives: use text_mutex to protect smp_alt_modules

On Fri, Oct 27, 2017 at 02:33:48PM +0200, Borislav Petkov wrote: > On Fri, Oct 27, 2017 at 07:42:45PM +0800, zhouchengming wrote: > > This is a real bug happened on one of our machines, below is the calltrace. > > We can see the trigger is at alternatives_text_reserved+0x20/0x80, and > > encounter

Re: [PATCH] kprobes, x86/alternatives: use text_mutex to protect smp_alt_modules

On Fri, Oct 27, 2017 at 02:33:48PM +0200, Borislav Petkov wrote: > On Fri, Oct 27, 2017 at 07:42:45PM +0800, zhouchengming wrote: > > This is a real bug happened on one of our machines, below is the calltrace. > > We can see the trigger is at alternatives_text_reserved+0x20/0x80, and > > encounter

[PATCH 4/5] staging: fsl-dpaa2/eth: Change RX buffer alignment

The WRIOP hardware block v1.0.0 (found on LS2080A board) requires data in RX buffers to be aligned to 256B, but newer revisions (e.g. on LS2088A, LS1088A) only require 64B alignment. Check WRIOP version and decide at runtime which alignment requirement to configure for ingress buffers.

[PATCH 4/5] staging: fsl-dpaa2/eth: Change RX buffer alignment

The WRIOP hardware block v1.0.0 (found on LS2080A board) requires data in RX buffers to be aligned to 256B, but newer revisions (e.g. on LS2088A, LS1088A) only require 64B alignment. Check WRIOP version and decide at runtime which alignment requirement to configure for ingress buffers.

[PATCH 5/5] staging: fsl-dpaa2/eth: Extra headroom in RX buffers

The needed headroom that we ask the stack to reserve for us in TX skbs is larger than the headroom available in RX frames, which leads to skb reallocations in forwarding scenarios involving two DPNI interfaces. Configure the hardware to reserve some extra space in the RX frame headroom to avoid

[PATCH 5/5] staging: fsl-dpaa2/eth: Extra headroom in RX buffers

The needed headroom that we ask the stack to reserve for us in TX skbs is larger than the headroom available in RX frames, which leads to skb reallocations in forwarding scenarios involving two DPNI interfaces. Configure the hardware to reserve some extra space in the RX frame headroom to avoid

[PATCH 2/5] staging: fsl-dpaa2/eth: Split function

From: Ioana Radulescu Since setup_dpni() became a bit too long, move the buffer layout configuration to a separate function. Signed-off-by: Ioana Radulescu Signed-off-by: Bogdan Purcareata ---

[PATCH 2/5] staging: fsl-dpaa2/eth: Split function

From: Ioana Radulescu Since setup_dpni() became a bit too long, move the buffer layout configuration to a separate function. Signed-off-by: Ioana Radulescu Signed-off-by: Bogdan Purcareata --- drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c | 79 +++--- 1 file changed, 45

[PATCH 3/5] staging: fsl-dpaa2/eth: Don't account SWA in tx_data_offset

When configuring the Tx buffer layout, the software annotation size is mentioned, and MC accounts for it when configuring the frame tx_data_offset. No need to handle it in the driver as well. Signed-off-by: Bogdan Purcareata ---

[PATCH 3/5] staging: fsl-dpaa2/eth: Don't account SWA in tx_data_offset

When configuring the Tx buffer layout, the software annotation size is mentioned, and MC accounts for it when configuring the frame tx_data_offset. No need to handle it in the driver as well. Signed-off-by: Bogdan Purcareata --- drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c | 3 --- 1 file

[PATCH 1/5] staging: fsl-dpaa2/eth: Label cleanup

From: Ioana Radulescu Clean up goto labels in a couple of functions, by removing/renaming redundant ones. Signed-off-by: Ioana Radulescu Signed-off-by: Bogdan Purcareata ---

[PATCH 1/5] staging: fsl-dpaa2/eth: Label cleanup

From: Ioana Radulescu Clean up goto labels in a couple of functions, by removing/renaming redundant ones. Signed-off-by: Ioana Radulescu Signed-off-by: Bogdan Purcareata --- drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c | 35 +++--- 1 file changed, 15 insertions(+), 20

[PATCH 0/5] staging: fsl-dpaa2/eth: Frame buffer work

This patchset does some refactoring in the frame buffer area, in order for it to be in line with firmware (MC) configuration. Patches 1 - 2 do some label cleanup and move the buffer layout setup to a dedicated function. Patch 3 updates tx_data_offset - the offset for Tx frame buffers - to not

[PATCH 0/5] staging: fsl-dpaa2/eth: Frame buffer work

This patchset does some refactoring in the frame buffer area, in order for it to be in line with firmware (MC) configuration. Patches 1 - 2 do some label cleanup and move the buffer layout setup to a dedicated function. Patch 3 updates tx_data_offset - the offset for Tx frame buffers - to not

Re: general protection fault in n_tty_receive_buf_common

On 10/27/2017, 11:24 AM, Dmitry Vyukov wrote: > On Fri, Oct 27, 2017 at 11:22 AM, syzbot > > wrote: >> Hello, >> >> syzkaller hit the following crash on >> 623ce3456671ea842c0ebda79c38655c8c04af74 >>

Re: general protection fault in n_tty_receive_buf_common

On 10/27/2017, 11:24 AM, Dmitry Vyukov wrote: > On Fri, Oct 27, 2017 at 11:22 AM, syzbot > > wrote: >> Hello, >> >> syzkaller hit the following crash on >> 623ce3456671ea842c0ebda79c38655c8c04af74 >> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master >> compiler: gcc (GCC)

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