Re: [PATCH] x86/efi-bgrt: remove the check of the version field

On 08/15/16 at 01:56pm, Matt Fleming wrote: > On Tue, 09 Aug, at 01:25:46PM, Icenowy Zheng wrote: > > Some broken firmwares have a wrongly filled version field in BGRT table. > > (See http://wiki.osdev.org/Broken_UEFI_implementations ) > > > > As we know, these firmwares can also provide correct

Re: [PATCH] x86/efi-bgrt: remove the check of the version field

On 08/15/16 at 01:56pm, Matt Fleming wrote: > On Tue, 09 Aug, at 01:25:46PM, Icenowy Zheng wrote: > > Some broken firmwares have a wrongly filled version field in BGRT table. > > (See http://wiki.osdev.org/Broken_UEFI_implementations ) > > > > As we know, these firmwares can also provide correct

Re: [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

On Tue, Aug 16, 2016 at 04:09:19PM -0700, H. Peter Anvin wrote: > On August 16, 2016 10:16:35 AM PDT, Borislav Petkov wrote: > >On Tue, Aug 16, 2016 at 09:59:00AM -0700, H. Peter Anvin wrote: > >> Dang... > > > >Isn't 9.3% improvement a good thing(tm) ? > > Yes, it's huge. The

Re: [lkp] [x86/hweight] 65ea11ec6a: will-it-scale.per_process_ops 9.3% improvement

On Tue, Aug 16, 2016 at 04:09:19PM -0700, H. Peter Anvin wrote: > On August 16, 2016 10:16:35 AM PDT, Borislav Petkov wrote: > >On Tue, Aug 16, 2016 at 09:59:00AM -0700, H. Peter Anvin wrote: > >> Dang... > > > >Isn't 9.3% improvement a good thing(tm) ? > > Yes, it's huge. The only explanation

Re: [PATCH v3 2/5] net: ethernet: ti: davinci_cpdma: fix locking while ctrl_stop

On Tuesday 16 August 2016 04:55 AM, Ivan Khoronzhuk wrote: > The interrupts shouldn't be disabled while receiving skb, but while > ctrl_stop, the channels are stopped and all remaining packets are > handled with netif_receive_skb(): > > lock_irq_save > cpdma_ctlr_stop >cpdma_chan_top

Re: [PATCH v3 2/5] net: ethernet: ti: davinci_cpdma: fix locking while ctrl_stop

On Tuesday 16 August 2016 04:55 AM, Ivan Khoronzhuk wrote: > The interrupts shouldn't be disabled while receiving skb, but while > ctrl_stop, the channels are stopped and all remaining packets are > handled with netif_receive_skb(): > > lock_irq_save > cpdma_ctlr_stop >cpdma_chan_top

Re: [PATCH v5 3/4] drm/bridge: analogix_dp: add the PSR function support

Hi, On 07/24/2016 12:27 PM, Yakir Yang wrote: The full name of PSR is Panel Self Refresh, panel device could refresh itself with the hardware framebuffer in panel, this would make lots of sense to save the power consumption. This patch have exported two symbols for platform driver to implement

Re: [PATCH v5 3/4] drm/bridge: analogix_dp: add the PSR function support

Hi, On 07/24/2016 12:27 PM, Yakir Yang wrote: The full name of PSR is Panel Self Refresh, panel device could refresh itself with the hardware framebuffer in panel, this would make lots of sense to save the power consumption. This patch have exported two symbols for platform driver to implement

Re: [LKP] [lkp] [sctp] a6c2f79287: netperf.Throughput_Mbps -37.2% regression

> The perf-profile data for the two commits are attached(for the case of > prsctp_enable=1, the perf-profile data doesn't get collected for the 0 > case for some reason, I'm checking the problem now). > > The CPU gets much more idle time in the bisected commit a6c2f79287: > > 68.89% 0.70%

Re: [LKP] [lkp] [sctp] a6c2f79287: netperf.Throughput_Mbps -37.2% regression

> The perf-profile data for the two commits are attached(for the case of > prsctp_enable=1, the perf-profile data doesn't get collected for the 0 > case for some reason, I'm checking the problem now). > > The CPU gets much more idle time in the bisected commit a6c2f79287: > > 68.89% 0.70%

Re: [LKP] [lkp] [sctp] a6c2f79287: netperf.Throughput_Mbps -37.2% regression

On 08/17/2016 01:04 PM, Aaron Lu wrote: > On 08/16/2016 05:56 PM, Xin Long wrote: > > I'm testing on Linus' master, can we all use that please? > [git] git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git [mechine] Intel(R) Xeon(R) CPU E5-2690 v2 @

Re: [LKP] [lkp] [sctp] a6c2f79287: netperf.Throughput_Mbps -37.2% regression

On 08/17/2016 01:04 PM, Aaron Lu wrote: > On 08/16/2016 05:56 PM, Xin Long wrote: > > I'm testing on Linus' master, can we all use that please? > [git] git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git [mechine] Intel(R) Xeon(R) CPU E5-2690 v2 @

Re: [LKP] [lkp] [sctp] a6c2f79287: netperf.Throughput_Mbps -37.2% regression

> > For commit a6c2f79287 ("sctp: implement prsctp TTL policy"), no matter > the value of net.sctp.prsctp_enable, the throughput is almost the same: > > net.sctp.prsctp_enable = 0 > { > "netperf.Throughput_Mbps": [ > 2353.311249997 > ] > } > > net.sctp.prsctp_enable = 1 > { >

Re: [LKP] [lkp] [sctp] a6c2f79287: netperf.Throughput_Mbps -37.2% regression

> > For commit a6c2f79287 ("sctp: implement prsctp TTL policy"), no matter > the value of net.sctp.prsctp_enable, the throughput is almost the same: > > net.sctp.prsctp_enable = 0 > { > "netperf.Throughput_Mbps": [ > 2353.311249997 > ] > } > > net.sctp.prsctp_enable = 1 > { >

Re: [PATCH v6 0/5] /dev/random - a new approach

Am Dienstag, 16. August 2016, 15:28:45 CEST schrieb H. Peter Anvin: Hi Peter, > > > > There are two motivations for that: > > > > - the current /dev/random is compliant to NTG.1 from AIS 20/31 which > > requires (in brief words) that entropy comes from auditible noise > > sources. Currently in

Re: [PATCH v6 0/5] /dev/random - a new approach

Am Dienstag, 16. August 2016, 15:28:45 CEST schrieb H. Peter Anvin: Hi Peter, > > > > There are two motivations for that: > > > > - the current /dev/random is compliant to NTG.1 from AIS 20/31 which > > requires (in brief words) that entropy comes from auditible noise > > sources. Currently in

[PATCH v3 1/5] arm: dts: msm8974: Add thermal zones, tsens and qfprom nodes

Add thermal zones, tsens and qfprom nodes Acked-by: Eduardo Valentin Acked-by: Rob Herring Signed-off-by: Rajendra Nayak --- arch/arm/boot/dts/qcom-msm8974.dtsi | 103 1 file changed, 103

[PATCH v3 0/5] dts patches for qcom tsens support

Hey Andy, This is a respin of v2 with some minor fixes pointed out by Rob. Please pull these in for 4.9 Thanks, Rajendra Rajendra Nayak (5): arm: dts: msm8974: Add thermal zones, tsens and qfprom nodes arm: dts: apq8064: Add thermal zones, tsens and qfprom nodes arm: dts: apq8084: Add

[PATCH v3 2/5] arm: dts: apq8064: Add thermal zones, tsens and qfprom nodes

TSENS is part of GCC, hence add TSENS properties as part of GCC node. Also add thermal zones and qfprom nodes. Update GCC bindings doc to mention the possibility of optional TSENS properties that can be part of GCC node. Acked-by: Eduardo Valentin Acked-by: Rob Herring

[PATCH v3 4/5] arm64: dts: msm8916: Add thermal zones, tsens and qfprom nodes

Add thermal zones, tsens and qfprom nodes Acked-by: Eduardo Valentin Acked-by: Rob Herring Signed-off-by: Rajendra Nayak --- arch/arm64/boot/dts/qcom/msm8916.dtsi | 64 +++ 1 file changed, 64

[PATCH v3 1/5] arm: dts: msm8974: Add thermal zones, tsens and qfprom nodes

Add thermal zones, tsens and qfprom nodes Acked-by: Eduardo Valentin Acked-by: Rob Herring Signed-off-by: Rajendra Nayak --- arch/arm/boot/dts/qcom-msm8974.dtsi | 103 1 file changed, 103 insertions(+) diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi

[PATCH v3 0/5] dts patches for qcom tsens support

Hey Andy, This is a respin of v2 with some minor fixes pointed out by Rob. Please pull these in for 4.9 Thanks, Rajendra Rajendra Nayak (5): arm: dts: msm8974: Add thermal zones, tsens and qfprom nodes arm: dts: apq8064: Add thermal zones, tsens and qfprom nodes arm: dts: apq8084: Add

[PATCH v3 2/5] arm: dts: apq8064: Add thermal zones, tsens and qfprom nodes

TSENS is part of GCC, hence add TSENS properties as part of GCC node. Also add thermal zones and qfprom nodes. Update GCC bindings doc to mention the possibility of optional TSENS properties that can be part of GCC node. Acked-by: Eduardo Valentin Acked-by: Rob Herring Signed-off-by: Rajendra

[PATCH v3 4/5] arm64: dts: msm8916: Add thermal zones, tsens and qfprom nodes

Add thermal zones, tsens and qfprom nodes Acked-by: Eduardo Valentin Acked-by: Rob Herring Signed-off-by: Rajendra Nayak --- arch/arm64/boot/dts/qcom/msm8916.dtsi | 64 +++ 1 file changed, 64 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi

[PATCH v3 3/5] arm: dts: apq8084: Add thermal zones, tsens and qfprom nodes

Add thermal zones, tsens and qfprom nodes Acked-by: Eduardo Valentin Acked-by: Rob Herring Signed-off-by: Rajendra Nayak --- arch/arm/boot/dts/qcom-apq8084.dtsi | 103 1 file changed, 103

[PATCH v3 5/5] arm64: dts: msm8996: Add thermal zones, tsens and qfprom nodes

Add thermal zones and tsens node Acked-by: Eduardo Valentin Acked-by: Rob Herring Signed-off-by: Rajendra Nayak --- arch/arm64/boot/dts/qcom/msm8996.dtsi | 92 +++ 1 file changed, 92 insertions(+)

[PATCH v3 5/5] arm64: dts: msm8996: Add thermal zones, tsens and qfprom nodes

Add thermal zones and tsens node Acked-by: Eduardo Valentin Acked-by: Rob Herring Signed-off-by: Rajendra Nayak --- arch/arm64/boot/dts/qcom/msm8996.dtsi | 92 +++ 1 file changed, 92 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi

[PATCH v3 3/5] arm: dts: apq8084: Add thermal zones, tsens and qfprom nodes

Add thermal zones, tsens and qfprom nodes Acked-by: Eduardo Valentin Acked-by: Rob Herring Signed-off-by: Rajendra Nayak --- arch/arm/boot/dts/qcom-apq8084.dtsi | 103 1 file changed, 103 insertions(+) diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi

Re: [PATCH v3 0/7] x86: Rewrite switch_to()

Andy Lutomirski wrote: > > I will be quite surprised if you can measure any effect at all. I've > never seen context switches take fewer than ~2k cycles, and on my > laptop, they take 8k-9k cycles. The scheduler is really, really slow. Indeed, I think I still have a

Re: [PATCH v3 0/7] x86: Rewrite switch_to()

Andy Lutomirski wrote: > > I will be quite surprised if you can measure any effect at all. I've > never seen context switches take fewer than ~2k cycles, and on my > laptop, they take 8k-9k cycles. The scheduler is really, really slow. Indeed, I think I still have a bugzilla entry somewhere

Re: [PATCH v5] spi: spi-ti-qspi: Add DMA support for QSPI mmap read

On Wednesday 17 August 2016 12:12 AM, Mark Brown wrote: > On Tue, Aug 09, 2016 at 06:20:01PM +0530, Vignesh R wrote: >> >> > >> According to this thread[1], converting virtual address >> pointer into scatterlist which is then DMA mapped is unsafe on systems >> with certain cache architecture.

Re: [PATCH v5] spi: spi-ti-qspi: Add DMA support for QSPI mmap read

On Wednesday 17 August 2016 12:12 AM, Mark Brown wrote: > On Tue, Aug 09, 2016 at 06:20:01PM +0530, Vignesh R wrote: >> >> > >> According to this thread[1], converting virtual address >> pointer into scatterlist which is then DMA mapped is unsafe on systems >> with certain cache architecture.

RE: [PATCH v2] Added perf functionality to mmdc driver

> > > > + hrtimer_start(_mmdc->hrtimer, mmdc_timer_period(), > > > > + HRTIMER_MODE_REL_PINNED); > > > > > > Why is a hrtimer necessary? Is this just copy-pasted from CCN, or do > > > you have similar HW issues? > > > > > > Is there no overflow interrupt? > > > > When

RE: [PATCH v2] Added perf functionality to mmdc driver

> > > > + hrtimer_start(_mmdc->hrtimer, mmdc_timer_period(), > > > > + HRTIMER_MODE_REL_PINNED); > > > > > > Why is a hrtimer necessary? Is this just copy-pasted from CCN, or do > > > you have similar HW issues? > > > > > > Is there no overflow interrupt? > > > > When

Re: [PATCH v2] drm/bridge: analogix_dp: Ensure the panel is properly prepared/unprepared

On 08/09/2016 08:05 AM, Yakir Yang wrote: + Archit On 08/09/2016 02:53 AM, Sean Paul wrote: Instead of just preparing the panel on bind, actually prepare/unprepare during modeset/disable. The panel must be prepared in order to read hpd status and edid, so we need to keep state around the

Re: [PATCH v2] drm/bridge: analogix_dp: Ensure the panel is properly prepared/unprepared

On 08/09/2016 08:05 AM, Yakir Yang wrote: + Archit On 08/09/2016 02:53 AM, Sean Paul wrote: Instead of just preparing the panel on bind, actually prepare/unprepare during modeset/disable. The panel must be prepared in order to read hpd status and edid, so we need to keep state around the

Re: [RFC 00/11] THP swap: Delay splitting THP during swapping out

On Tue, Aug 16, 2016 at 07:06:00PM -0700, Huang, Ying wrote: > Hi, Kim, > > Minchan Kim writes: > > > Hello Huang, > > > > On Tue, Aug 09, 2016 at 09:37:42AM -0700, Huang, Ying wrote: > >> From: Huang Ying > >> > >> This patchset is based on 8/4 head

Re: [PATCH] staging: comedi: ni_mio_common: fix AO inttrig backwards compatibility

Sorry for the very belated reply on this. I'm assuming that this was already accepted, but I've been working with this patch for a bit. This fixes the problems I raised in any case. Reviewed-by: Spencer E Olson On Wed, 2016-07-20 at 17:07 +0100, Ian Abbott wrote: > On

Re: [RFC 00/11] THP swap: Delay splitting THP during swapping out

On Tue, Aug 16, 2016 at 07:06:00PM -0700, Huang, Ying wrote: > Hi, Kim, > > Minchan Kim writes: > > > Hello Huang, > > > > On Tue, Aug 09, 2016 at 09:37:42AM -0700, Huang, Ying wrote: > >> From: Huang Ying > >> > >> This patchset is based on 8/4 head of mmotm/master. > >> > >> This is the

Re: [PATCH] staging: comedi: ni_mio_common: fix AO inttrig backwards compatibility

Sorry for the very belated reply on this. I'm assuming that this was already accepted, but I've been working with this patch for a bit. This fixes the problems I raised in any case. Reviewed-by: Spencer E Olson On Wed, 2016-07-20 at 17:07 +0100, Ian Abbott wrote: > On 20/07/16 16:55, Hartley

Re: [LKP] [lkp] [sctp] a6c2f79287: netperf.Throughput_Mbps -37.2% regression

On 08/16/2016 05:56 PM, Xin Long wrote: I'm testing on Linus' master, can we all use that please? >>> >>> [git] git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >>> >>> [mechine] >>> Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz >>> mem 62G (66000220K) >>> >>> [system]

Re: [LKP] [lkp] [sctp] a6c2f79287: netperf.Throughput_Mbps -37.2% regression

On 08/16/2016 05:56 PM, Xin Long wrote: I'm testing on Linus' master, can we all use that please? >>> >>> [git] git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >>> >>> [mechine] >>> Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz >>> mem 62G (66000220K) >>> >>> [system]

Re: [PATCH v2 0/6] kexec_file: Add buffer hand-over for the next kernel

Hello Dave, Am Mittwoch, 17 August 2016, 10:52:26 schrieb Dave Young: > On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote: > > This series applies on top of v5 of the "kexec_file_load implementation > > for PowerPC" patch series (which applies on top of v4.8-rc1): > > > >

Re: [PATCH v2 0/6] kexec_file: Add buffer hand-over for the next kernel

Hello Dave, Am Mittwoch, 17 August 2016, 10:52:26 schrieb Dave Young: > On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote: > > This series applies on top of v5 of the "kexec_file_load implementation > > for PowerPC" patch series (which applies on top of v4.8-rc1): > > > >

perf: rdpmc and PERF_EVENT_IOC_RESET

Hello so using rdpmc() and the mmap page to do fast perf_event reads seems to interact poorly with the PERF_EVENT_IOC_RESET ioctl. >From what I can tell, on reset event->count is set to zero, but event->hw.prev_count is not, so the userpg->offset field ends up negative and weird things

perf: rdpmc and PERF_EVENT_IOC_RESET

Hello so using rdpmc() and the mmap page to do fast perf_event reads seems to interact poorly with the PERF_EVENT_IOC_RESET ioctl. >From what I can tell, on reset event->count is set to zero, but event->hw.prev_count is not, so the userpg->offset field ends up negative and weird things

Re: [PATCH v6 6/8] Documentation: bindings: add dt documentation for rk3399 dmc

ing need to pass to arm trust firmware > +- upthreshold: the upthreshold to simpleondeamnd policy > +- downdifferential: The downdifferential to simpleondeamnd policy > + > +Example: > + ddr_timing: ddr_timing { > + compatible = "rockchip,ddr-timing"; I c

Re: [PATCH v6 6/8] Documentation: bindings: add dt documentation for rk3399 dmc

o arm trust firmware > +- upthreshold: the upthreshold to simpleondeamnd policy > +- downdifferential: The downdifferential to simpleondeamnd policy > + > +Example: > + ddr_timing: ddr_timing { > + compatible = "rockchip,ddr-timing"; I can't find the 'rockc

RE: [PATCH v7 1/2] ACPI / button: Fix an issue that the platform triggered reliable events may not be delivered to the userspace

Hi, Rafael > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J. > Wysocki > Subject: Re: [PATCH v7 1/2] ACPI / button: Fix an issue that the platform > triggered reliable events > may not be delivered to the userspace > > On Tuesday, July

RE: [PATCH v7 1/2] ACPI / button: Fix an issue that the platform triggered reliable events may not be delivered to the userspace

Hi, Rafael > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J. > Wysocki > Subject: Re: [PATCH v7 1/2] ACPI / button: Fix an issue that the platform > triggered reliable events > may not be delivered to the userspace > > On Tuesday, July

RE: [PATCH v4 3/3] tools/power/acpi/acpidbg: Add multi-commands support in batch mode

Hi, Rafael > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Subject: Re: [PATCH v4 3/3] tools/power/acpi/acpidbg: Add multi-commands > support in batch mode > > On Tuesday, July 26, 2016 07:01:45 PM Lv Zheng wrote: > > This patch adds multi-commands support for the batch mode. The same

RE: [PATCH v4 3/3] tools/power/acpi/acpidbg: Add multi-commands support in batch mode

Hi, Rafael > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Subject: Re: [PATCH v4 3/3] tools/power/acpi/acpidbg: Add multi-commands > support in batch mode > > On Tuesday, July 26, 2016 07:01:45 PM Lv Zheng wrote: > > This patch adds multi-commands support for the batch mode. The same

Re: [PATCH] tpm: fix a race condition tpm2_unseal_trusted()

On Tue, Aug 16, 2016 at 10:38:22PM +0300, Jarkko Sakkinen wrote: > Unseal and load operations should be done as an atomic operation. This > commit introduces unlocked tpm_transmit() so that tpm2_unseal_trusted() > can do the locking by itself. > > v2: Introduced an unlocked unseal operation

Re: [PATCH] tpm: fix a race condition tpm2_unseal_trusted()

On Tue, Aug 16, 2016 at 10:38:22PM +0300, Jarkko Sakkinen wrote: > Unseal and load operations should be done as an atomic operation. This > commit introduces unlocked tpm_transmit() so that tpm2_unseal_trusted() > can do the locking by itself. > > v2: Introduced an unlocked unseal operation

linux-next: Tree for Aug 17

Hi all, Changes since 20160816: The net-next tree gained a conflict against the net tree. The kbuild tree gained build warnings for PowerPC, so I reverted a commit. Non-merge commits (relative to Linus' tree): 2406 2530 files changed, 99359 insertions(+), 40525 deletions

linux-next: Tree for Aug 17

Hi all, Changes since 20160816: The net-next tree gained a conflict against the net tree. The kbuild tree gained build warnings for PowerPC, so I reverted a commit. Non-merge commits (relative to Linus' tree): 2406 2530 files changed, 99359 insertions(+), 40525 deletions

[PATCH] ARM: qcom: Cleanup/Remove unnecessary board file

This patch removes the unnecessary board file. The generic machine definition is sufficient for the Qualcomm platforms. Signed-off-by: Andy Gross --- arch/arm/mach-qcom/Makefile | 1 - arch/arm/mach-qcom/board.c | 31 --- 2 files changed, 32

[PATCH] ARM: qcom: Cleanup/Remove unnecessary board file

This patch removes the unnecessary board file. The generic machine definition is sufficient for the Qualcomm platforms. Signed-off-by: Andy Gross --- arch/arm/mach-qcom/Makefile | 1 - arch/arm/mach-qcom/board.c | 31 --- 2 files changed, 32 deletions(-) delete

Re: [PATCH] be2iscsi: Use a more current logging style

On Wed, 2016-08-17 at 09:20 +0530, Jitendra Bhivare wrote: > > > > -Original Message- > > From: Joe Perches [mailto:j...@perches.com] > > Sent: Tuesday, August 16, 2016 3:57 PM > > To: Jitendra Bhivare; Christophe JAILLET; Jayamohan Kallickal; Ketan > Mukadam > > > > Cc: Bart Van Assche;

Re: [PATCH] be2iscsi: Use a more current logging style

On Wed, 2016-08-17 at 09:20 +0530, Jitendra Bhivare wrote: > > > > -Original Message- > > From: Joe Perches [mailto:j...@perches.com] > > Sent: Tuesday, August 16, 2016 3:57 PM > > To: Jitendra Bhivare; Christophe JAILLET; Jayamohan Kallickal; Ketan > Mukadam > > > > Cc: Bart Van Assche;

RE: [PATCH] be2iscsi: Use a more current logging style

> -Original Message- > From: Joe Perches [mailto:j...@perches.com] > Sent: Tuesday, August 16, 2016 3:57 PM > To: Jitendra Bhivare; Christophe JAILLET; Jayamohan Kallickal; Ketan Mukadam > Cc: Bart Van Assche; James E.J. Bottomley; Martin K. Petersen; linux- > s...@vger.kernel.org;

RE: [PATCH] be2iscsi: Use a more current logging style

> -Original Message- > From: Joe Perches [mailto:j...@perches.com] > Sent: Tuesday, August 16, 2016 3:57 PM > To: Jitendra Bhivare; Christophe JAILLET; Jayamohan Kallickal; Ketan Mukadam > Cc: Bart Van Assche; James E.J. Bottomley; Martin K. Petersen; linux- > s...@vger.kernel.org;

Re: [PATCH 0/2] be2iscsi: Logging neatening

On Wed, 2016-08-17 at 01:19 +, Bart Van Assche wrote: > On 08/14/16 10:29, Joe Perches wrote: > > On Sun, 2016-08-14 at 17:09 +, Bart Van Assche wrote: > > > My primary concern is how to enable and disable log messages from user > > > space. [] > > I think you are looking for a system wide

Re: [PATCH 0/2] be2iscsi: Logging neatening

On Wed, 2016-08-17 at 01:19 +, Bart Van Assche wrote: > On 08/14/16 10:29, Joe Perches wrote: > > On Sun, 2016-08-14 at 17:09 +, Bart Van Assche wrote: > > > My primary concern is how to enable and disable log messages from user > > > space. [] > > I think you are looking for a system wide

Re: [PATCH v2 4/5] bug: Provide toggle for BUG on data corruption

On Tue, Aug 16, 2016 at 5:26 PM, Joe Perches wrote: > On Tue, 2016-08-16 at 17:20 -0700, Kees Cook wrote: >> The kernel checks for cases of data structure corruption under some >> CONFIGs (e.g. CONFIG_DEBUG_LIST). When corruption is detected, some >> systems may want to BUG()

Re: [PATCH v2 4/5] bug: Provide toggle for BUG on data corruption

On Tue, Aug 16, 2016 at 5:26 PM, Joe Perches wrote: > On Tue, 2016-08-16 at 17:20 -0700, Kees Cook wrote: >> The kernel checks for cases of data structure corruption under some >> CONFIGs (e.g. CONFIG_DEBUG_LIST). When corruption is detected, some >> systems may want to BUG() immediately instead

Re: [PATCH v2 0/5] bug: Provide toggle for BUG on data corruption

On Tue, Aug 16, 2016 at 5:55 PM, Henrique de Moraes Holschuh wrote: > On Tue, 16 Aug 2016, Kees Cook wrote: >> This adds a CONFIG to trigger BUG()s when the kernel encounters >> unexpected data structure integrity as currently detected with >> CONFIG_DEBUG_LIST. >> >>

Re: [PATCH v2 0/5] bug: Provide toggle for BUG on data corruption

On Tue, Aug 16, 2016 at 5:55 PM, Henrique de Moraes Holschuh wrote: > On Tue, 16 Aug 2016, Kees Cook wrote: >> This adds a CONFIG to trigger BUG()s when the kernel encounters >> unexpected data structure integrity as currently detected with >> CONFIG_DEBUG_LIST. >> >> Specifically list operations

Re: [PATCH] dma-buf: fix kernel-doc warning and typos

Hi Randy, On 17 August 2016 at 05:01, Randy Dunlap wrote: > From: Randy Dunlap > > Fix dma-buf kernel-doc warning and 2 minor typos in > fence_array_create(). > Thanks for your patch, I will queue it up! > Fixes this warning: >

Re: [PATCH] dma-buf: fix kernel-doc warning and typos

Hi Randy, On 17 August 2016 at 05:01, Randy Dunlap wrote: > From: Randy Dunlap > > Fix dma-buf kernel-doc warning and 2 minor typos in > fence_array_create(). > Thanks for your patch, I will queue it up! > Fixes this warning: > ..//drivers/dma-buf/fence-array.c:124: warning: No description

Re: [PATCH v2] clk: max77686: Migrate to clk_hw based OF and registration APIs

Hello Stephen, On 08/16/2016 06:38 PM, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc:

Re: [PATCH v2] clk: max77686: Migrate to clk_hw based OF and registration APIs

Hello Stephen, On 08/16/2016 06:38 PM, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc:

[PATCH v3 0/5] Fixing a set of bugs for ioapic hotplug

On Wed, Aug 17, 2016 8:36 AM Rafael J. Wysocki wrote: > On Wednesday, August 10, 2016 12:01:53 PM Rui Wang wrote: > > A set of patches fixing bugs found while testing IOAPIC hotplug. > > This should have been posted to the x...@kernel.org list too for the benefit > of the maintainers. > > Can

[PATCH v3 0/5] Fixing a set of bugs for ioapic hotplug

On Wed, Aug 17, 2016 8:36 AM Rafael J. Wysocki wrote: > On Wednesday, August 10, 2016 12:01:53 PM Rui Wang wrote: > > A set of patches fixing bugs found while testing IOAPIC hotplug. > > This should have been posted to the x...@kernel.org list too for the benefit > of the maintainers. > > Can

[PATCH] Staging: android: ion: ion_heap.c: fix parenthesis alignment

This fixes the checkpatch.pl "Alignment should match open parenthesis" issues in ion_heap.c. Signed-off-by: Ben LeMasurier --- drivers/staging/android/ion/ion_heap.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git

[PATCH] Staging: android: ion: ion_heap.c: fix parenthesis alignment

This fixes the checkpatch.pl "Alignment should match open parenthesis" issues in ion_heap.c. Signed-off-by: Ben LeMasurier --- drivers/staging/android/ion/ion_heap.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/staging/android/ion/ion_heap.c

Re: [PATCH 17/34] clk: maxgen: Migrate to clk_hw based OF and registration APIs

Hello Stephen, On 08/16/2016 04:06 PM, Stephen Boyd wrote: > On Tue, Jun 7, 2016 at 11:55 AM, Javier Martinez Canillas >>> >>> I tried this patch on top of linux-next and my Peach Pi Chromebook >>> (that has a max77802 chip) failed to boot. Following is the relevant >>> parts from the boot log:

Re: [PATCH 17/34] clk: maxgen: Migrate to clk_hw based OF and registration APIs

Hello Stephen, On 08/16/2016 04:06 PM, Stephen Boyd wrote: > On Tue, Jun 7, 2016 at 11:55 AM, Javier Martinez Canillas >>> >>> I tried this patch on top of linux-next and my Peach Pi Chromebook >>> (that has a max77802 chip) failed to boot. Following is the relevant >>> parts from the boot log:

Re: [PATCH v2] Bluetooth: Add LED triggers for HCI frames tx and rx

On 16 August 2016 at 20:33, Marcel Holtmann wrote: > > Hi Guodong, > > >>> Two LED triggers are added into hci_dev: tx_led and rx_led. Upon ACL/SCO > >>> packets available in tx or rx, the LEDs will blink. > >>> > >>> For each hci registration, two triggers are added into LED

Re: [PATCH v2] Bluetooth: Add LED triggers for HCI frames tx and rx

On 16 August 2016 at 20:33, Marcel Holtmann wrote: > > Hi Guodong, > > >>> Two LED triggers are added into hci_dev: tx_led and rx_led. Upon ACL/SCO > >>> packets available in tx or rx, the LEDs will blink. > >>> > >>> For each hci registration, two triggers are added into LED subsystem: > >>>

Re: [PATCH v2 0/6] kexec_file: Add buffer hand-over for the next kernel

On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote: > Hello, > > This patch series implements a mechanism which allows the kernel to pass > on a buffer to the kernel that will be kexec'd. This buffer is passed > as a segment which is added to the kimage when it is being prepared > by

Re: [PATCH v2 0/6] kexec_file: Add buffer hand-over for the next kernel

On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote: > Hello, > > This patch series implements a mechanism which allows the kernel to pass > on a buffer to the kernel that will be kexec'd. This buffer is passed > as a segment which is added to the kimage when it is being prepared > by

RE: [PATCH v4 2/3] tools/power/acpi/acpidbg: Use new flushing mechanism

Hi, Rafael > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Subject: Re: [PATCH v4 2/3] tools/power/acpi/acpidbg: Use new flushing > mechanism > > On Tuesday, July 26, 2016 07:01:39 PM Lv Zheng wrote: > > This patch converts tools/power/acpi/tools/acpidbg/acpidbg to use the new > >

RE: [PATCH v4 2/3] tools/power/acpi/acpidbg: Use new flushing mechanism

Hi, Rafael > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Subject: Re: [PATCH v4 2/3] tools/power/acpi/acpidbg: Use new flushing > mechanism > > On Tuesday, July 26, 2016 07:01:39 PM Lv Zheng wrote: > > This patch converts tools/power/acpi/tools/acpidbg/acpidbg to use the new > >

RE: [PATCH v4 1/3] ACPI / debugger: Add kernel flushing support

Hi, Rafael > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Subject: Re: [PATCH v4 1/3] ACPI / debugger: Add kernel flushing support > > On Tuesday, July 26, 2016 07:01:33 PM Lv Zheng wrote: > > This patch adds debugger output flushing support in kernel via .ioctl() > > callback. The

RE: [PATCH v4 1/3] ACPI / debugger: Add kernel flushing support

Hi, Rafael > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Subject: Re: [PATCH v4 1/3] ACPI / debugger: Add kernel flushing support > > On Tuesday, July 26, 2016 07:01:33 PM Lv Zheng wrote: > > This patch adds debugger output flushing support in kernel via .ioctl() > > callback. The

Re: [PATCH 2/6] x86/boot: Move compressed kernel to end of decompression buffer

On Tue, Aug 16, 2016 at 12:19:42PM -0700, Yinghai Lu wrote: > On Mon, Aug 15, 2016 at 9:01 PM, Matt Mullins wrote: > > > > This appears to have a negative effect on booting the Intel Edison > > platform, as > > it uses u-boot as its bootloader. u-boot does not copy the

Re: [PATCH 2/6] x86/boot: Move compressed kernel to end of decompression buffer

On Tue, Aug 16, 2016 at 12:19:42PM -0700, Yinghai Lu wrote: > On Mon, Aug 15, 2016 at 9:01 PM, Matt Mullins wrote: > > > > This appears to have a negative effect on booting the Intel Edison > > platform, as > > it uses u-boot as its bootloader. u-boot does not copy the init_size > > parameter

[PATCH v3] sched/cputime: Resync steal time when guest & host lose sync

From: Wanpeng Li Commit: 57430218317e ("sched/cputime: Count actually elapsed irq & softirq time") ... triggered a regression: | An i5 laptop, 4 pCPUs, 4vCPUs for one full dynticks guest, there are four | cpu hog processes(for loop) running in the guest, I

[PATCH v3] sched/cputime: Resync steal time when guest & host lose sync

From: Wanpeng Li Commit: 57430218317e ("sched/cputime: Count actually elapsed irq & softirq time") ... triggered a regression: | An i5 laptop, 4 pCPUs, 4vCPUs for one full dynticks guest, there are four | cpu hog processes(for loop) running in the guest, I hot-unplug the pCPUs | on

Re: [PATCH v2] sched/cputime: Resync steal time when guest & host lose sync

2016-08-17 9:54 GMT+08:00 Rik van Riel : > On Wed, 2016-08-17 at 09:16 +0800, Wanpeng Li wrote: >> >> @@ -694,6 +699,12 @@ static cputime_t get_vtime_delta(struct >> task_struct *tsk) >> unsigned long now = READ_ONCE(jiffies); >> cputime_t delta, other; >> >> + /*

Re: [PATCH v2] sched/cputime: Resync steal time when guest & host lose sync

2016-08-17 9:54 GMT+08:00 Rik van Riel : > On Wed, 2016-08-17 at 09:16 +0800, Wanpeng Li wrote: >> >> @@ -694,6 +699,12 @@ static cputime_t get_vtime_delta(struct >> task_struct *tsk) >> unsigned long now = READ_ONCE(jiffies); >> cputime_t delta, other; >> >> + /* >> + * The

Re: [PATCH v3] sched/cputime: Resync steal time when guest & host lose sync

On Wed, 2016-08-17 at 10:05 +0800, Wanpeng Li wrote: > This patch fix the regression by limiting the account_other_time() > from  > get_vtime_delta() to avoid underflow, and let other three call sites > (account_other_time() and steal_account_process_time()) account > however  > much steal time

Re: [PATCH v3] sched/cputime: Resync steal time when guest & host lose sync

On Wed, 2016-08-17 at 10:05 +0800, Wanpeng Li wrote: > This patch fix the regression by limiting the account_other_time() > from  > get_vtime_delta() to avoid underflow, and let other three call sites > (account_other_time() and steal_account_process_time()) account > however  > much steal time

Re: [RFC 00/11] THP swap: Delay splitting THP during swapping out

Hi, Kim, Minchan Kim writes: > Hello Huang, > > On Tue, Aug 09, 2016 at 09:37:42AM -0700, Huang, Ying wrote: >> From: Huang Ying >> >> This patchset is based on 8/4 head of mmotm/master. >> >> This is the first step for Transparent Huge Page (THP)

Re: [RFC 00/11] THP swap: Delay splitting THP during swapping out

Hi, Kim, Minchan Kim writes: > Hello Huang, > > On Tue, Aug 09, 2016 at 09:37:42AM -0700, Huang, Ying wrote: >> From: Huang Ying >> >> This patchset is based on 8/4 head of mmotm/master. >> >> This is the first step for Transparent Huge Page (THP) swap support. >> The plan is to delaying

Re: [PATCH v5 02/13] kexec_file: Change kexec_add_buffer to take kexec_buf as argument.

On 17/08/16 04:49, Thiago Jung Bauermann wrote: > Am Dienstag, 16 August 2016, 16:15:55 schrieb Balbir Singh: >> On 16/08/16 00:49, Thiago Jung Bauermann wrote: >>> Am Montag, 15 August 2016, 17:30:49 schrieb Balbir Singh: On Thu, Aug 11, 2016 at 08:08:07PM -0300, Thiago Jung Bauermann

Re: [PATCH v5 02/13] kexec_file: Change kexec_add_buffer to take kexec_buf as argument.

On 17/08/16 04:49, Thiago Jung Bauermann wrote: > Am Dienstag, 16 August 2016, 16:15:55 schrieb Balbir Singh: >> On 16/08/16 00:49, Thiago Jung Bauermann wrote: >>> Am Montag, 15 August 2016, 17:30:49 schrieb Balbir Singh: On Thu, Aug 11, 2016 at 08:08:07PM -0300, Thiago Jung Bauermann

Re: [PATCH 3.16 102/305] xfs: xfs_iflush_cluster fails to abort on error

On Tue, Aug 16, 2016 at 08:45:02PM +0100, Ben Hutchings wrote: > On Sun, 2016-08-14 at 09:36 +1000, Dave Chinner wrote: > > On Sat, Aug 13, 2016 at 06:42:51PM +0100, Ben Hutchings wrote: > > > > > > 3.16.37-rc1 review patch.  If anyone has any objections, please let me > > > know. > > > > > >

Re: [PATCH 3.16 102/305] xfs: xfs_iflush_cluster fails to abort on error

On Tue, Aug 16, 2016 at 08:45:02PM +0100, Ben Hutchings wrote: > On Sun, 2016-08-14 at 09:36 +1000, Dave Chinner wrote: > > On Sat, Aug 13, 2016 at 06:42:51PM +0100, Ben Hutchings wrote: > > > > > > 3.16.37-rc1 review patch.  If anyone has any objections, please let me > > > know. > > > > > >

  1   2   3   4   5   6   7   8   9   10   >