Re: Support for configurable PCIe endpoint

On 08/18/2016 07:25 AM, Kishon Vijay Abraham I wrote: > Hi, > > On Wednesday 17 August 2016 03:19 PM, Mingkai Hu wrote: >> >>> -Original Message- >>> From: Kishon Vijay Abraham I [mailto:kis...@ti.com] >>> Sent: Thursday, August 04, 2016 6:02 PM >>> To: Joao Pinto

Re: Support for configurable PCIe endpoint

On 08/18/2016 07:25 AM, Kishon Vijay Abraham I wrote: > Hi, > > On Wednesday 17 August 2016 03:19 PM, Mingkai Hu wrote: >> >>> -Original Message- >>> From: Kishon Vijay Abraham I [mailto:kis...@ti.com] >>> Sent: Thursday, August 04, 2016 6:02 PM >>> To: Joao Pinto ; bhelg...@google.com;

Re: [PATCH] thp: reduce usage of huge zero page's atomic counter

On 08/30/2016 12:44 PM, Anshuman Khandual wrote: > On 08/30/2016 09:09 AM, Andrew Morton wrote: >> On Tue, 30 Aug 2016 11:09:15 +0800 Aaron Lu wrote: >> > Case used for test on Haswell EP: > usemem -n 72 --readonly -j 0x20 100G > Which spawns 72 processes and

Re: [PATCH] thp: reduce usage of huge zero page's atomic counter

On 08/30/2016 12:44 PM, Anshuman Khandual wrote: > On 08/30/2016 09:09 AM, Andrew Morton wrote: >> On Tue, 30 Aug 2016 11:09:15 +0800 Aaron Lu wrote: >> > Case used for test on Haswell EP: > usemem -n 72 --readonly -j 0x20 100G > Which spawns 72 processes and each will mmap 100G

Re: [PATCH] thp: reduce usage of huge zero page's atomic counter

On 08/30/2016 11:39 AM, Andrew Morton wrote: > On Tue, 30 Aug 2016 11:09:15 +0800 Aaron Lu wrote: > Case used for test on Haswell EP: usemem -n 72 --readonly -j 0x20 100G Which spawns 72 processes and each will mmap 100G anonymous space and then do

Re: [PATCH] thp: reduce usage of huge zero page's atomic counter

On 08/30/2016 11:39 AM, Andrew Morton wrote: > On Tue, 30 Aug 2016 11:09:15 +0800 Aaron Lu wrote: > Case used for test on Haswell EP: usemem -n 72 --readonly -j 0x20 100G Which spawns 72 processes and each will mmap 100G anonymous space and then do read only access to

[PATCH v9 1/2] ASoC: sun4i-codec: Distinguish sun4i from sun7i

This distinguishes sun4i from sun7i. It is necessary because they use different registers for the audio mixer. --- sound/soc/sunxi/sun4i-codec.c | 44 +-- 1 file changed, 34 insertions(+), 10 deletions(-) diff --git a/sound/soc/sunxi/sun4i-codec.c

[PATCH v9 2/2] Add mixer controls: Line-In, FM-In, Mic 2, Capture Source, Differential Line-In.

Note: Mic1 Capture Volume is in a different register on A20 than on A10. Note: Mic2 Capture Volume is in a different register on A20 than on A10. --- sound/soc/sunxi/sun4i-codec.c | 256 ++ 1 file changed, 236 insertions(+), 20 deletions(-) diff --git

[PATCH v9 0/2] sun4i-codec: Add Line-In, FM-In, Mic 2, Capture Source, Differential Line-In

This patch adds support for some mixer controls: - Line-In - FM-In - Mic 2 - Capture Source - Differential Line-In v9 changes compared to v8 are: - added Line Differential Capture Switch. - split Capture Source into Left Capture Select, Right Capture Select. - added Line Capture Volume.

[PATCH v9 1/2] ASoC: sun4i-codec: Distinguish sun4i from sun7i

This distinguishes sun4i from sun7i. It is necessary because they use different registers for the audio mixer. --- sound/soc/sunxi/sun4i-codec.c | 44 +-- 1 file changed, 34 insertions(+), 10 deletions(-) diff --git a/sound/soc/sunxi/sun4i-codec.c

[PATCH v9 2/2] Add mixer controls: Line-In, FM-In, Mic 2, Capture Source, Differential Line-In.

Note: Mic1 Capture Volume is in a different register on A20 than on A10. Note: Mic2 Capture Volume is in a different register on A20 than on A10. --- sound/soc/sunxi/sun4i-codec.c | 256 ++ 1 file changed, 236 insertions(+), 20 deletions(-) diff --git

[PATCH v9 0/2] sun4i-codec: Add Line-In, FM-In, Mic 2, Capture Source, Differential Line-In

This patch adds support for some mixer controls: - Line-In - FM-In - Mic 2 - Capture Source - Differential Line-In v9 changes compared to v8 are: - added Line Differential Capture Switch. - split Capture Source into Left Capture Select, Right Capture Select. - added Line Capture Volume.

[patch v3.18+ regression fix] sched: Further improve spurious CPU_IDLE active migrations

43f4d666 partially cured spurious migrations, but when there are completely idle groups on a lightly loaded processor, and there is a buddy pair occupying the busiest group, we will not attempt to migrate due to select_idle_sibling() buddy placement, leaving the busiest queue with one task. We

[patch v3.18+ regression fix] sched: Further improve spurious CPU_IDLE active migrations

43f4d666 partially cured spurious migrations, but when there are completely idle groups on a lightly loaded processor, and there is a buddy pair occupying the busiest group, we will not attempt to migrate due to select_idle_sibling() buddy placement, leaving the busiest queue with one task. We

Re: [PATCH] ALSA: hda - Enable subwoofer on Dell Inspiron 7559

On Tue, 30 Aug 2016 07:27:41 +0200, Kai-Heng Feng wrote: > > The subwoofer on Inspiron 7559 does not work originally. > Applying a pin fixup can make it work. > > Signed-off-by: Kai-Heng Feng > --- > sound/pci/hda/patch_realtek.c | 11 +++ > 1 file changed,

Re: [PATCH] ALSA: hda - Enable subwoofer on Dell Inspiron 7559

On Tue, 30 Aug 2016 07:27:41 +0200, Kai-Heng Feng wrote: > > The subwoofer on Inspiron 7559 does not work originally. > Applying a pin fixup can make it work. > > Signed-off-by: Kai-Heng Feng > --- > sound/pci/hda/patch_realtek.c | 11 +++ > 1 file changed, 11 insertions(+) > > diff

[PATCH] ALSA: hda - Enable subwoofer on Dell Inspiron 7559

The subwoofer on Inspiron 7559 does not work originally. Applying a pin fixup can make it work. Signed-off-by: Kai-Heng Feng --- sound/pci/hda/patch_realtek.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c

[PATCH] ALSA: hda - Enable subwoofer on Dell Inspiron 7559

The subwoofer on Inspiron 7559 does not work originally. Applying a pin fixup can make it work. Signed-off-by: Kai-Heng Feng --- sound/pci/hda/patch_realtek.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index

Re: [PATCH v2 2/2] vfio: add virtio pci quirk

On Mon, Aug 29, 2016 at 10:53:04PM -0600, Alex Williamson wrote: > On Mon, 29 Aug 2016 21:52:20 -0600 > Alex Williamson wrote: > > > On Mon, 29 Aug 2016 21:23:25 -0600 > > Alex Williamson wrote: > > > > > On Tue, 30 Aug 2016 05:27:17

Re: [PATCH v2 2/2] vfio: add virtio pci quirk

On Mon, Aug 29, 2016 at 10:53:04PM -0600, Alex Williamson wrote: > On Mon, 29 Aug 2016 21:52:20 -0600 > Alex Williamson wrote: > > > On Mon, 29 Aug 2016 21:23:25 -0600 > > Alex Williamson wrote: > > > > > On Tue, 30 Aug 2016 05:27:17 +0300 > > > "Michael S. Tsirkin" wrote: > > > > > > >

Re: [PATCH] thp: reduce usage of huge zero page's atomic counter

On Tue, 30 Aug 2016 10:44:21 +0530 Anshuman Khandual wrote: > On 08/30/2016 04:20 AM, Andrew Morton wrote: > > On Mon, 29 Aug 2016 14:31:20 +0800 Aaron Lu wrote: > > > >> > > >> > The global zero page is used to satisfy an anonymous read

Re: [PATCH] thp: reduce usage of huge zero page's atomic counter

On Tue, 30 Aug 2016 10:44:21 +0530 Anshuman Khandual wrote: > On 08/30/2016 04:20 AM, Andrew Morton wrote: > > On Mon, 29 Aug 2016 14:31:20 +0800 Aaron Lu wrote: > > > >> > > >> > The global zero page is used to satisfy an anonymous read fault. If > >> > THP(Transparent HugePage) is enabled

Re: [Patch v4 9/9] arm64: Update device tree for Layerscape SoCs

On Mon, Aug 29, 2016 at 02:39:21PM -0700, Olof Johansson wrote: > DT changes need to go through arm-soc. It's how we've been operating > for several years now. Ok ok, we've wasted enough time with this. So you guys pick up this one, I'll take the rest. Thanks. -- Regards/Gruss, Boris.

Re: [Patch v4 9/9] arm64: Update device tree for Layerscape SoCs

On Mon, Aug 29, 2016 at 02:39:21PM -0700, Olof Johansson wrote: > DT changes need to go through arm-soc. It's how we've been operating > for several years now. Ok ok, we've wasted enough time with this. So you guys pick up this one, I'll take the rest. Thanks. -- Regards/Gruss, Boris.

Re: [PATCH] thp: reduce usage of huge zero page's atomic counter

On 08/30/2016 04:20 AM, Andrew Morton wrote: > On Mon, 29 Aug 2016 14:31:20 +0800 Aaron Lu wrote: > >> > >> > The global zero page is used to satisfy an anonymous read fault. If >> > THP(Transparent HugePage) is enabled then the global huge zero page is >> > used. >> > The

Re: [PATCH] thp: reduce usage of huge zero page's atomic counter

On 08/30/2016 04:20 AM, Andrew Morton wrote: > On Mon, 29 Aug 2016 14:31:20 +0800 Aaron Lu wrote: > >> > >> > The global zero page is used to satisfy an anonymous read fault. If >> > THP(Transparent HugePage) is enabled then the global huge zero page is >> > used. >> > The global huge zero

Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422

Hi All Adding Vivek Gautam. On 29 August 2016 at 16:35, Michael Niewöhner wrote: > Hi Mathias, > On Mo, 2016-08-29 at 13:59 +0300, Mathias Nyman wrote: >> On 29.08.2016 10:28, Felipe Balbi wrote: >> > >> > >> > Hi, >> > >> > Michael Niewöhner writes:

Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422

Hi All Adding Vivek Gautam. On 29 August 2016 at 16:35, Michael Niewöhner wrote: > Hi Mathias, > On Mo, 2016-08-29 at 13:59 +0300, Mathias Nyman wrote: >> On 29.08.2016 10:28, Felipe Balbi wrote: >> > >> > >> > Hi, >> > >> > Michael Niewöhner writes: >> > > >> > > [1.] One line summary of the

Re: [PATCH] thp: reduce usage of huge zero page's atomic counter

On Tue, 30 Aug 2016 10:14:25 +0530 Anshuman Khandual wrote: > On 08/30/2016 09:09 AM, Andrew Morton wrote: > > On Tue, 30 Aug 2016 11:09:15 +0800 Aaron Lu wrote: > > > Case used for test on Haswell EP: > usemem -n 72 --readonly -j

Re: [PATCH] thp: reduce usage of huge zero page's atomic counter

On Tue, 30 Aug 2016 10:14:25 +0530 Anshuman Khandual wrote: > On 08/30/2016 09:09 AM, Andrew Morton wrote: > > On Tue, 30 Aug 2016 11:09:15 +0800 Aaron Lu wrote: > > > Case used for test on Haswell EP: > usemem -n 72 --readonly -j 0x20 100G > Which spawns 72 processes and

Re: [PATCH v2 2/2] vfio: add virtio pci quirk

On Mon, 29 Aug 2016 21:52:20 -0600 Alex Williamson wrote: > On Mon, 29 Aug 2016 21:23:25 -0600 > Alex Williamson wrote: > > > On Tue, 30 Aug 2016 05:27:17 +0300 > > "Michael S. Tsirkin" wrote: > > > > > Modern virtio

Re: [PATCH v2 2/2] vfio: add virtio pci quirk

On Mon, 29 Aug 2016 21:52:20 -0600 Alex Williamson wrote: > On Mon, 29 Aug 2016 21:23:25 -0600 > Alex Williamson wrote: > > > On Tue, 30 Aug 2016 05:27:17 +0300 > > "Michael S. Tsirkin" wrote: > > > > > Modern virtio pci devices can set VIRTIO_F_IOMMU_PLATFORM > > > to signal they are safe

Re: [PATCH] pwm: pwm-tipwmss: Remove all pm_runtime gets and puts from the driver

On Monday 08 August 2016 03:39 PM, Vignesh R wrote: > From: Jyri Sarha > > Remove all pm_runtime gets and puts, and dummy pm_ops, from the > pwm-tipwmss driver as there is no direct hardware access. The runtime PM > needs to be enabled, so that the runtime PM framework takes

Re: [PATCH] pwm: pwm-tipwmss: Remove all pm_runtime gets and puts from the driver

On Monday 08 August 2016 03:39 PM, Vignesh R wrote: > From: Jyri Sarha > > Remove all pm_runtime gets and puts, and dummy pm_ops, from the > pwm-tipwmss driver as there is no direct hardware access. The runtime PM > needs to be enabled, so that the runtime PM framework takes care of >

Re: [PATCH] thp: reduce usage of huge zero page's atomic counter

On 08/30/2016 09:09 AM, Andrew Morton wrote: > On Tue, 30 Aug 2016 11:09:15 +0800 Aaron Lu wrote: > Case used for test on Haswell EP: usemem -n 72 --readonly -j 0x20 100G Which spawns 72 processes and each will mmap 100G anonymous space and then do

Re: [PATCH] thp: reduce usage of huge zero page's atomic counter

On 08/30/2016 09:09 AM, Andrew Morton wrote: > On Tue, 30 Aug 2016 11:09:15 +0800 Aaron Lu wrote: > Case used for test on Haswell EP: usemem -n 72 --readonly -j 0x20 100G Which spawns 72 processes and each will mmap 100G anonymous space and then do read only access to

[ima] 8078f3035b: BUG: spinlock bad magic on CPU#1, swapper/0/1

FYI, we noticed the following commit: https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git next-restore-kexec commit 8078f3035b9dc488ed4e896635f491cdd79e9239 ("ima: store the builtin/custom template definitions in a list") in testcase: boot on test machine:

[ima] 8078f3035b: BUG: spinlock bad magic on CPU#1, swapper/0/1

FYI, we noticed the following commit: https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git next-restore-kexec commit 8078f3035b9dc488ed4e896635f491cdd79e9239 ("ima: store the builtin/custom template definitions in a list") in testcase: boot on test machine:

[ima] ee47739931: BUG: spinlock bad magic on CPU#0, swapper/0/1

FYI, we noticed the following commit: https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git next-restore-kexec commit ee47739931a22b314879daedba9299c2834a05e1 ("ima: store the builtin/custom template definitions in a list") in testcase: boot on test machine:

[ima] ee47739931: BUG: spinlock bad magic on CPU#0, swapper/0/1

FYI, we noticed the following commit: https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git next-restore-kexec commit ee47739931a22b314879daedba9299c2834a05e1 ("ima: store the builtin/custom template definitions in a list") in testcase: boot on test machine:

{standard input}:199: Error: unknown opcode

Hi Rich, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: b8927721ae9d5ac0582d29d7b8c267d465ad5f00 commit: b4214e41b7152b1964a3421a40251d202ae2d2c0 sh: add SMP support for J2 date: 4 weeks ago config:

{standard input}:199: Error: unknown opcode

Hi Rich, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: b8927721ae9d5ac0582d29d7b8c267d465ad5f00 commit: b4214e41b7152b1964a3421a40251d202ae2d2c0 sh: add SMP support for J2 date: 4 weeks ago config:

[PATCH] generic: Add the exception case checking routine for ppi interrupt

From: Ma Jun During system booting, if the interrupt which has no action registered is triggered, it would cause system panic when try to access the action member. Signed-off-by: Ma Jun --- kernel/irq/chip.c | 20 1 files

[PATCH] generic: Add the exception case checking routine for ppi interrupt

From: Ma Jun During system booting, if the interrupt which has no action registered is triggered, it would cause system panic when try to access the action member. Signed-off-by: Ma Jun --- kernel/irq/chip.c | 20 1 files changed, 16 insertions(+), 4 deletions(-) diff

Re: [PATCH v2 2/2] vfio: add virtio pci quirk

On Mon, Aug 29, 2016 at 09:52:20PM -0600, Alex Williamson wrote: > On Mon, 29 Aug 2016 21:23:25 -0600 > Alex Williamson wrote: > > > On Tue, 30 Aug 2016 05:27:17 +0300 > > "Michael S. Tsirkin" wrote: > > > > > Modern virtio pci devices can set

Re: [PATCH v2 2/2] vfio: add virtio pci quirk

On Mon, Aug 29, 2016 at 09:52:20PM -0600, Alex Williamson wrote: > On Mon, 29 Aug 2016 21:23:25 -0600 > Alex Williamson wrote: > > > On Tue, 30 Aug 2016 05:27:17 +0300 > > "Michael S. Tsirkin" wrote: > > > > > Modern virtio pci devices can set VIRTIO_F_IOMMU_PLATFORM > > > to signal they are

[PATCH] [bugfix] replace unnessary ldax with common ldr

Signed-off-by: Kenneth Lee --- arch/arm64/include/asm/spinlock.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/include/asm/spinlock.h b/arch/arm64/include/asm/spinlock.h index c85e96d..3334c4f 100644 ---

[PATCH] [bugfix] replace unnessary ldax with common ldr

Signed-off-by: Kenneth Lee --- arch/arm64/include/asm/spinlock.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/include/asm/spinlock.h b/arch/arm64/include/asm/spinlock.h index c85e96d..3334c4f 100644 --- a/arch/arm64/include/asm/spinlock.h +++

Re: [PATCH v2 2/2] vfio: add virtio pci quirk

On Mon, 29 Aug 2016 21:23:25 -0600 Alex Williamson wrote: > On Tue, 30 Aug 2016 05:27:17 +0300 > "Michael S. Tsirkin" wrote: > > > Modern virtio pci devices can set VIRTIO_F_IOMMU_PLATFORM > > to signal they are safe to use with an IOMMU. > > > >

Re: [PATCH v2 2/2] vfio: add virtio pci quirk

On Mon, 29 Aug 2016 21:23:25 -0600 Alex Williamson wrote: > On Tue, 30 Aug 2016 05:27:17 +0300 > "Michael S. Tsirkin" wrote: > > > Modern virtio pci devices can set VIRTIO_F_IOMMU_PLATFORM > > to signal they are safe to use with an IOMMU. > > > > Without this bit, exposing the device to

[PATCH v2] arm64: KVM: Save four instructions in __guest_enter/exit()

We are doing an unnecessary stack push/pop operation when restoring the guest registers x0-x18 in __guest_enter(). This patch saves the two instructions by using x18 as a base register. No need to store the vcpu context pointer in stack because it is redundant, the same information is available in

[PATCH v2] arm64: KVM: Save four instructions in __guest_enter/exit()

We are doing an unnecessary stack push/pop operation when restoring the guest registers x0-x18 in __guest_enter(). This patch saves the two instructions by using x18 as a base register. No need to store the vcpu context pointer in stack because it is redundant, the same information is available in

Re: [Qemu-devel] [PATCH v2 0/2] vfio: blacklist legacy virtio devices

On Tue, Aug 30, 2016 at 11:16:25AM +0800, Jason Wang wrote: > > > On 2016年08月30日 10:27, Michael S. Tsirkin wrote: > > Legacy virtio devices always bypassed an IOMMU, so using them with vfio was > > never safe. > > And it actually won't work since GPA is assumed in the device. So I'm not > sure

Re: [Qemu-devel] [PATCH v2 0/2] vfio: blacklist legacy virtio devices

On Tue, Aug 30, 2016 at 11:16:25AM +0800, Jason Wang wrote: > > > On 2016年08月30日 10:27, Michael S. Tsirkin wrote: > > Legacy virtio devices always bypassed an IOMMU, so using them with vfio was > > never safe. > > And it actually won't work since GPA is assumed in the device. So I'm not > sure

Re: [PATCH v2 2/2] vfio: add virtio pci quirk

On Mon, Aug 29, 2016 at 09:23:25PM -0600, Alex Williamson wrote: > On Tue, 30 Aug 2016 05:27:17 +0300 > "Michael S. Tsirkin" wrote: > > > Modern virtio pci devices can set VIRTIO_F_IOMMU_PLATFORM > > to signal they are safe to use with an IOMMU. > > > > Without this bit,

Re: [PATCH v2 2/2] vfio: add virtio pci quirk

On Mon, Aug 29, 2016 at 09:23:25PM -0600, Alex Williamson wrote: > On Tue, 30 Aug 2016 05:27:17 +0300 > "Michael S. Tsirkin" wrote: > > > Modern virtio pci devices can set VIRTIO_F_IOMMU_PLATFORM > > to signal they are safe to use with an IOMMU. > > > > Without this bit, exposing the device to

Re: [PATCH] tpm: fix invalid constant expressions in tpm.h

On Tue, Aug 30, 2016 at 04:28:17AM +0300, Jarkko Sakkinen wrote: > The enums tpm_capabilities and tpm_sub_capabilities do not contain legit > constant expressions. This commit makes cap_id a separate parameter > in I wonder if this is a bug in sparse? the macro uses gcc magic to expand to a

Re: [PATCH] tpm: fix invalid constant expressions in tpm.h

On Tue, Aug 30, 2016 at 04:28:17AM +0300, Jarkko Sakkinen wrote: > The enums tpm_capabilities and tpm_sub_capabilities do not contain legit > constant expressions. This commit makes cap_id a separate parameter > in I wonder if this is a bug in sparse? the macro uses gcc magic to expand to a

Re: [PATCH] thp: reduce usage of huge zero page's atomic counter

On Tue, 30 Aug 2016 11:09:15 +0800 Aaron Lu wrote: > >> Case used for test on Haswell EP: > >> usemem -n 72 --readonly -j 0x20 100G > >> Which spawns 72 processes and each will mmap 100G anonymous space and > >> then do read only access to that space sequentially with a

Re: [PATCH] thp: reduce usage of huge zero page's atomic counter

On Tue, 30 Aug 2016 11:09:15 +0800 Aaron Lu wrote: > >> Case used for test on Haswell EP: > >> usemem -n 72 --readonly -j 0x20 100G > >> Which spawns 72 processes and each will mmap 100G anonymous space and > >> then do read only access to that space sequentially with a step of 2MB. > >> >

Re: [PATCH v3 1/2] input: misc: Add generic input driver to read encoded GPIO lines

On Mon, Aug 29, 2016 at 09:50:28AM +0530, Vignesh R wrote: > > > On Thursday 25 August 2016 10:26 PM, Dmitry Torokhov wrote: > > On Wed, Aug 24, 2016 at 01:28:58PM +0530, Vignesh R wrote: > >> Add a driver to read group of GPIO lines and provide its status as a > >> numerical value as input

Re: [PATCH v3 1/2] input: misc: Add generic input driver to read encoded GPIO lines

On Mon, Aug 29, 2016 at 09:50:28AM +0530, Vignesh R wrote: > > > On Thursday 25 August 2016 10:26 PM, Dmitry Torokhov wrote: > > On Wed, Aug 24, 2016 at 01:28:58PM +0530, Vignesh R wrote: > >> Add a driver to read group of GPIO lines and provide its status as a > >> numerical value as input

Re: [PATCH v2 2/2] vfio: add virtio pci quirk

On Tue, 30 Aug 2016 05:27:17 +0300 "Michael S. Tsirkin" wrote: > Modern virtio pci devices can set VIRTIO_F_IOMMU_PLATFORM > to signal they are safe to use with an IOMMU. > > Without this bit, exposing the device to userspace is unsafe, so probe > and fail VFIO initialization

Re: [PATCH v2 2/2] vfio: add virtio pci quirk

On Tue, 30 Aug 2016 05:27:17 +0300 "Michael S. Tsirkin" wrote: > Modern virtio pci devices can set VIRTIO_F_IOMMU_PLATFORM > to signal they are safe to use with an IOMMU. > > Without this bit, exposing the device to userspace is unsafe, so probe > and fail VFIO initialization unless noiommu is

Re: [Qemu-devel] [PATCH v2 0/2] vfio: blacklist legacy virtio devices

On 2016年08月30日 10:27, Michael S. Tsirkin wrote: Legacy virtio devices always bypassed an IOMMU, so using them with vfio was never safe. And it actually won't work since GPA is assumed in the device. So I'm not sure this is must since we should get a IOMMU fault in this case. This adds

Re: [Qemu-devel] [PATCH v2 0/2] vfio: blacklist legacy virtio devices

On 2016年08月30日 10:27, Michael S. Tsirkin wrote: Legacy virtio devices always bypassed an IOMMU, so using them with vfio was never safe. And it actually won't work since GPA is assumed in the device. So I'm not sure this is must since we should get a IOMMU fault in this case. This adds

Re: [PATCH] thp: reduce usage of huge zero page's atomic counter

On 08/30/2016 06:50 AM, Andrew Morton wrote: > On Mon, 29 Aug 2016 14:31:20 +0800 Aaron Lu wrote: > >> >> The global zero page is used to satisfy an anonymous read fault. If >> THP(Transparent HugePage) is enabled then the global huge zero page is used. >> The global huge

Re: [PATCH] thp: reduce usage of huge zero page's atomic counter

On 08/30/2016 06:50 AM, Andrew Morton wrote: > On Mon, 29 Aug 2016 14:31:20 +0800 Aaron Lu wrote: > >> >> The global zero page is used to satisfy an anonymous read fault. If >> THP(Transparent HugePage) is enabled then the global huge zero page is used. >> The global huge zero page uses an

Re: [PATCH v2] pwm-regulator: Add support for a fixed delay after duty cycle changes

Hi, On Fri, Aug 26, 2016 at 5:20 PM, Matthias Kaehlcke wrote: > A change of the duty cycle doesn't necessarily cause an inmediate switch > to the target voltage. The voltage change may be gradual and complete > with a certain delay. This change introduces the device tree

Re: [PATCH v2] pwm-regulator: Add support for a fixed delay after duty cycle changes

Hi, On Fri, Aug 26, 2016 at 5:20 PM, Matthias Kaehlcke wrote: > A change of the duty cycle doesn't necessarily cause an inmediate switch > to the target voltage. The voltage change may be gradual and complete > with a certain delay. This change introduces the device tree properties >

Re: [PATCH v1 00/10] Optimize sched avgs computation and implement flat util hierarchy

On Wed, Aug 24, 2016 at 09:54:35AM +0100, Morten Rasmussen wrote: > As Dietmar mentioned already, the 'disconnect' is a feature of the PELT > rewrite. Paul and Ben's original implementation had full propagation up > and down the hierarchy. IIRC, one of the key points of the rewrite was > more

Re: [PATCH v1 00/10] Optimize sched avgs computation and implement flat util hierarchy

On Wed, Aug 24, 2016 at 09:54:35AM +0100, Morten Rasmussen wrote: > As Dietmar mentioned already, the 'disconnect' is a feature of the PELT > rewrite. Paul and Ben's original implementation had full propagation up > and down the hierarchy. IIRC, one of the key points of the rewrite was > more

Re: xfstests xfs fuzzers fail with DAX

On Mon, Aug 29, 2016 at 06:50:05PM -0700, Dan Williams wrote: > [ Adding Darrick on the off chance that this triggers an "aha, of > course it does!" ] Aha! Of course it does!!! :) > Darrick these corruption tests you added to xfstests last year all > fail the same way with DAX enabled. They

Re: xfstests xfs fuzzers fail with DAX

On Mon, Aug 29, 2016 at 06:50:05PM -0700, Dan Williams wrote: > [ Adding Darrick on the off chance that this triggers an "aha, of > course it does!" ] Aha! Of course it does!!! :) > Darrick these corruption tests you added to xfstests last year all > fail the same way with DAX enabled. They

Re: [LKP] [lkp] [f2fs] ec795418c4: fsmark.files_per_sec -36.3% regression

Hello, On Sat, Aug 27, 2016 at 10:13:34AM +0800, Fengguang Wu wrote: > Hi Jaegeuk, > > > > >> > - [lkp] [f2fs] b93f771286: aim7.jobs-per-min -81.2% regression > > > >> > > > > >> > The disk is 4 12G ram disk, and setup RAID0 on them via mdadm. The > > > >> > steps for aim7 is, > > > >> > > > >

Re: [LKP] [lkp] [f2fs] ec795418c4: fsmark.files_per_sec -36.3% regression

Hello, On Sat, Aug 27, 2016 at 10:13:34AM +0800, Fengguang Wu wrote: > Hi Jaegeuk, > > > > >> > - [lkp] [f2fs] b93f771286: aim7.jobs-per-min -81.2% regression > > > >> > > > > >> > The disk is 4 12G ram disk, and setup RAID0 on them via mdadm. The > > > >> > steps for aim7 is, > > > >> > > > >

Re: [PATCH net-next 0/6] perf, bpf: add support for bpf in sw/hw perf_events

On Mon, Aug 29, 2016 at 5:19 AM, Peter Zijlstra wrote: > > On Fri, Aug 26, 2016 at 07:31:18PM -0700, Alexei Starovoitov wrote: > > Hi Peter, Dave, > > > > this patch set is a follow up to the discussion: > > https://lkml.org/lkml/2016/8/4/304 > > It turned out to be simpler

Re: [PATCH net-next 0/6] perf, bpf: add support for bpf in sw/hw perf_events

On Mon, Aug 29, 2016 at 5:19 AM, Peter Zijlstra wrote: > > On Fri, Aug 26, 2016 at 07:31:18PM -0700, Alexei Starovoitov wrote: > > Hi Peter, Dave, > > > > this patch set is a follow up to the discussion: > > https://lkml.org/lkml/2016/8/4/304 > > It turned out to be simpler than what we

[PATCH v2 2/2] vfio: add virtio pci quirk

Modern virtio pci devices can set VIRTIO_F_IOMMU_PLATFORM to signal they are safe to use with an IOMMU. Without this bit, exposing the device to userspace is unsafe, so probe and fail VFIO initialization unless noiommu is enabled. Signed-off-by: Michael S. Tsirkin ---

[PATCH v2 1/2] vfio: report group noiommu status

When using vfio, callers might want to know whether device is added to a regular group or an non-iommu group. Report this status from vfio_is_noiommu_group_dev. Signed-off-by: Michael S. Tsirkin --- include/linux/vfio.h | 2 ++ drivers/vfio/vfio.c | 12 2 files

[PATCH v2 0/2] vfio: blacklist legacy virtio devices

Legacy virtio devices always bypassed an IOMMU, so using them with vfio was never safe. This adds a quirk detecting these and disabling VFIO unless the noiommu mode is used. At the moment, this only applies to virtio-pci devices. The patch might make sense on stable as well. Michael S. Tsirkin

[PATCH v2 2/2] vfio: add virtio pci quirk

Modern virtio pci devices can set VIRTIO_F_IOMMU_PLATFORM to signal they are safe to use with an IOMMU. Without this bit, exposing the device to userspace is unsafe, so probe and fail VFIO initialization unless noiommu is enabled. Signed-off-by: Michael S. Tsirkin ---

[PATCH v2 1/2] vfio: report group noiommu status

When using vfio, callers might want to know whether device is added to a regular group or an non-iommu group. Report this status from vfio_is_noiommu_group_dev. Signed-off-by: Michael S. Tsirkin --- include/linux/vfio.h | 2 ++ drivers/vfio/vfio.c | 12 2 files changed, 14

[PATCH v2 0/2] vfio: blacklist legacy virtio devices

Legacy virtio devices always bypassed an IOMMU, so using them with vfio was never safe. This adds a quirk detecting these and disabling VFIO unless the noiommu mode is used. At the moment, this only applies to virtio-pci devices. The patch might make sense on stable as well. Michael S. Tsirkin

Re: [PATCH 2/2] f2fs: add roll-forward recovery process for encrypted dentry

On Tue, Aug 30, 2016 at 12:06:09AM +0800, Chao Yu wrote: > Hi all, > > On 2016/8/29 11:27, Shuoran Liu wrote: > > Add roll-forward recovery process for encrypted dentry, so the first fsync > > issued to an encrypted file does not need writing checkpoint. > > > > This improves the performance of

Re: [PATCH 2/2] f2fs: add roll-forward recovery process for encrypted dentry

On Tue, Aug 30, 2016 at 12:06:09AM +0800, Chao Yu wrote: > Hi all, > > On 2016/8/29 11:27, Shuoran Liu wrote: > > Add roll-forward recovery process for encrypted dentry, so the first fsync > > issued to an encrypted file does not need writing checkpoint. > > > > This improves the performance of

[PATCH] f2fs: fix lost xattrs of directories

This patch enhances the xattr consistency of dirs from suddern power-cuts. Possible scenario would be: 1. dir->setxattr used by per-file encryption 2. file->setxattr goes into inline_xattr 3. file->fsync In that case, we should do checkpoint for #1. Otherwise we'd lose dir's key information for

[PATCH] f2fs: fix lost xattrs of directories

This patch enhances the xattr consistency of dirs from suddern power-cuts. Possible scenario would be: 1. dir->setxattr used by per-file encryption 2. file->setxattr goes into inline_xattr 3. file->fsync In that case, we should do checkpoint for #1. Otherwise we'd lose dir's key information for

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Mon, Aug 29, 2016 at 03:16:52PM +, Mathieu Desnoyers wrote: > - On Aug 27, 2016, at 12:22 AM, Josh Triplett j...@joshtriplett.org wrote: > > > On Thu, Aug 25, 2016 at 05:56:25PM +, Ben Maurer wrote: > >> rseq opens up a whole world of algorithms to userspace – algorithms > >> that

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Mon, Aug 29, 2016 at 03:16:52PM +, Mathieu Desnoyers wrote: > - On Aug 27, 2016, at 12:22 AM, Josh Triplett j...@joshtriplett.org wrote: > > > On Thu, Aug 25, 2016 at 05:56:25PM +, Ben Maurer wrote: > >> rseq opens up a whole world of algorithms to userspace – algorithms > >> that

[GIT PULL] hwmon fixes for v4.8-rc5

Hi Linus, Please pull hwmon fixes for Linux v4.8-rc5 from signed tag: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git hwmon-for-linus-v4.8-rc5 Thanks, Guenter -- The following changes since commit fa8410b355251fd30341662a40ac6b22d3e38468: Linux 4.8-rc3

[GIT PULL] hwmon fixes for v4.8-rc5

Hi Linus, Please pull hwmon fixes for Linux v4.8-rc5 from signed tag: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git hwmon-for-linus-v4.8-rc5 Thanks, Guenter -- The following changes since commit fa8410b355251fd30341662a40ac6b22d3e38468: Linux 4.8-rc3

Re: [PATCH v9 0/2] sun4i-codec: Add Line-In, FM-In, Mic 2, Capture Source, Differential Line-In

On Tue, Aug 30, 2016 at 2:03 AM, Danny Milosavljevic wrote: > Hi Maxime, > > On Sat, 27 Aug 2016 14:02:51 +0200 > Maxime Ripard wrote: > >> Please send your patches using send-email. > > If you are referring to "git send-email", I did

Re: [PATCH v9 0/2] sun4i-codec: Add Line-In, FM-In, Mic 2, Capture Source, Differential Line-In

On Tue, Aug 30, 2016 at 2:03 AM, Danny Milosavljevic wrote: > Hi Maxime, > > On Sat, 27 Aug 2016 14:02:51 +0200 > Maxime Ripard wrote: > >> Please send your patches using send-email. > > If you are referring to "git send-email", I did send the patch series using > that (with almost the same

Re: 4.8-rc4 spews "BUG: sleeping function called from invalid context at fs/dcache.c:757"

On Tue, 2016-08-30 at 09:37 +0800, Ian Kent wrote: > On Mon, 2016-08-29 at 16:18 +0100, Al Viro wrote: > > On Mon, Aug 29, 2016 at 04:35:46PM +0200, Takashi Iwai wrote: > > > > > [] dput+0x46/0x400 > > ... which should not be called in atomic contexts > > > [] follow_down_one+0x27/0x60 >

Re: 4.8-rc4 spews "BUG: sleeping function called from invalid context at fs/dcache.c:757"

On Tue, 2016-08-30 at 09:37 +0800, Ian Kent wrote: > On Mon, 2016-08-29 at 16:18 +0100, Al Viro wrote: > > On Mon, Aug 29, 2016 at 04:35:46PM +0200, Takashi Iwai wrote: > > > > > [] dput+0x46/0x400 > > ... which should not be called in atomic contexts > > > [] follow_down_one+0x27/0x60 >

Re: xfstests xfs fuzzers fail with DAX

[ Adding Darrick on the off chance that this triggers an "aha, of course it does!" ] Darrick these corruption tests you added to xfstests last year all fail the same way with DAX enabled. They spew: "pwrite64: Structure needs cleaning" ...reports that are cleaned up by running without "-o

Re: xfstests xfs fuzzers fail with DAX

[ Adding Darrick on the off chance that this triggers an "aha, of course it does!" ] Darrick these corruption tests you added to xfstests last year all fail the same way with DAX enabled. They spew: "pwrite64: Structure needs cleaning" ...reports that are cleaned up by running without "-o

Re: [PATCH] ftrace: Access ret_stack->subtime only in the function profiler

Hi Steve, On Mon, Aug 29, 2016 at 04:07:00PM -0400, Steven Rostedt wrote: > On Mon, 29 Aug 2016 12:05:18 +0900 > Namhyung Kim wrote: > > > The subtime is used only for function profiler with function graph > > tracer enabled. Move the definition of subtime under > >

Re: [PATCH] ftrace: Access ret_stack->subtime only in the function profiler

Hi Steve, On Mon, Aug 29, 2016 at 04:07:00PM -0400, Steven Rostedt wrote: > On Mon, 29 Aug 2016 12:05:18 +0900 > Namhyung Kim wrote: > > > The subtime is used only for function profiler with function graph > > tracer enabled. Move the definition of subtime under > > CONFIG_FUNCTION_PROFILER to

  1   2   3   4   5   6   7   8   9   10   >