Re: [RFC][PATCH 2/3] drm/bridge: adv7511: Add 200ms delay on power-on

On Tue, Nov 22, 2016 at 08:23:38PM +0200, Laurent Pinchart wrote: > Hi John, > > (CC'ing Daniel) > > On Tuesday 22 Nov 2016 10:07:53 John Stultz wrote: > > On Tue, Nov 22, 2016 at 9:38 AM, John Stultz wrote: > > > Interestingly, without the msleep added in this patch,

Re: [RFC][PATCH 2/3] drm/bridge: adv7511: Add 200ms delay on power-on

On Tue, Nov 22, 2016 at 08:23:38PM +0200, Laurent Pinchart wrote: > Hi John, > > (CC'ing Daniel) > > On Tuesday 22 Nov 2016 10:07:53 John Stultz wrote: > > On Tue, Nov 22, 2016 at 9:38 AM, John Stultz wrote: > > > Interestingly, without the msleep added in this patch, removing the > > >

[RFC 1/2] mm: consolidate GFP_NOFAIL checks in the allocator slowpath

From: Michal Hocko Tetsuo Handa has pointed out that 0a0337e0d1d1 ("mm, oom: rework oom detection") has subtly changed semantic for costly high order requests with __GFP_NOFAIL and withtout __GFP_REPEAT and those can fail right now. My code inspection didn't reveal any such

[RFC 1/2] mm: consolidate GFP_NOFAIL checks in the allocator slowpath

From: Michal Hocko Tetsuo Handa has pointed out that 0a0337e0d1d1 ("mm, oom: rework oom detection") has subtly changed semantic for costly high order requests with __GFP_NOFAIL and withtout __GFP_REPEAT and those can fail right now. My code inspection didn't reveal any such users in the tree but

Re: crash by cdc_acm driver in kernels 4.8-rc1/5

On November 23, 2016 1:54:57 AM CET, Wim Osterholt wrote: >On Tue, Nov 22, 2016 at 07:08:30PM +0100, Bjørn Mork wrote: >> > On kernel 4.8.8 this crashes hard and produces over a serial link: >> >> Huh? That device shouldn't ever enter that code path AFAICS. >> Unless

Re: crash by cdc_acm driver in kernels 4.8-rc1/5

On November 23, 2016 1:54:57 AM CET, Wim Osterholt wrote: >On Tue, Nov 22, 2016 at 07:08:30PM +0100, Bjørn Mork wrote: >> > On kernel 4.8.8 this crashes hard and produces over a serial link: >> >> Huh? That device shouldn't ever enter that code path AFAICS. >> Unless you wouldn't happen

Re: [PATCH 1/3] of: base: add support to get machine compatible string

On Tuesday 22 November 2016 09:16 PM, Sudeep Holla wrote: > Hi Sekhar, > > On 22/11/16 15:06, Sekhar Nori wrote: >> Hi Sudeep, >> >> On Tuesday 22 November 2016 04:23 PM, Sudeep Holla wrote: >>> >>> >>> On 22/11/16 10:41, Bartosz Golaszewski wrote: Add a function allowing to retrieve the

Re: [PATCH 1/3] of: base: add support to get machine compatible string

On Tuesday 22 November 2016 09:16 PM, Sudeep Holla wrote: > Hi Sekhar, > > On 22/11/16 15:06, Sekhar Nori wrote: >> Hi Sudeep, >> >> On Tuesday 22 November 2016 04:23 PM, Sudeep Holla wrote: >>> >>> >>> On 22/11/16 10:41, Bartosz Golaszewski wrote: Add a function allowing to retrieve the

Re: Enabling peer to peer device transactions for PCIe devices

On Tue, Nov 22, 2016 at 01:21:03PM -0800, Dan Williams wrote: > On Tue, Nov 22, 2016 at 1:03 PM, Daniel Vetter wrote: > > On Tue, Nov 22, 2016 at 9:35 PM, Serguei Sagalovitch > > wrote: > >> > >> On 2016-11-22 03:10 PM, Daniel Vetter wrote: > >>> >

Re: Enabling peer to peer device transactions for PCIe devices

On Tue, Nov 22, 2016 at 01:21:03PM -0800, Dan Williams wrote: > On Tue, Nov 22, 2016 at 1:03 PM, Daniel Vetter wrote: > > On Tue, Nov 22, 2016 at 9:35 PM, Serguei Sagalovitch > > wrote: > >> > >> On 2016-11-22 03:10 PM, Daniel Vetter wrote: > >>> > >>> On Tue, Nov 22, 2016 at 9:01 PM, Dan

[PATCH] Staging: iio: adc: fix sysfs files modes in ad7192.c

Fixes sysfs entries user/group modes and coding style warnings found by checkpatch.pl tool Signed-off-by: Boyan Vladinov --- drivers/staging/iio/adc/ad7192.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/staging/iio/adc/ad7192.c

[PATCH] Staging: iio: adc: fix sysfs files modes in ad7192.c

Fixes sysfs entries user/group modes and coding style warnings found by checkpatch.pl tool Signed-off-by: Boyan Vladinov --- drivers/staging/iio/adc/ad7192.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/staging/iio/adc/ad7192.c

[PATCH] arm64: dts: exynos: enable hs400 mode for eMMC for TM2

TM2 can support the HS400 mode, but eMMC is working as the lowest mode. This patch added the properties for HS400 and other modes. Signed-off-by: Jaehoon Chung --- arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 3 +++ 1 file changed, 3 insertions(+) diff --git

[PATCH] arm64: dts: exynos: enable hs400 mode for eMMC for TM2

TM2 can support the HS400 mode, but eMMC is working as the lowest mode. This patch added the properties for HS400 and other modes. Signed-off-by: Jaehoon Chung --- arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 3 +++ 1 file changed, 3 insertions(+) diff --git

Re: [PATCH] Add support for disabling Intel PT trace in ftrace

Andi Kleen writes: > +/* > + * Disable the PT trace for debugging purposes. > + */ > +void pt_disable(void) > +{ > + u64 val; > + > + if (!boot_cpu_has(X86_FEATURE_INTEL_PT)) > + return; > + > + rdmsrl_safe(MSR_IA32_RTIT_CTL, ); > + val &=

Re: [PATCH v2] mm: support anonymous stable page

Hi Hugh, On Tue, Nov 22, 2016 at 08:43:54PM -0800, Hugh Dickins wrote: > On Tue, 22 Nov 2016, Minchan Kim wrote: > > On Mon, Nov 21, 2016 at 07:46:28PM -0800, Hugh Dickins wrote: > > > > > > Andrew might ask if we should Cc stable (haha): I think we agree > > > that it's a defect we've been

Re: [PATCH] Add support for disabling Intel PT trace in ftrace

Andi Kleen writes: > +/* > + * Disable the PT trace for debugging purposes. > + */ > +void pt_disable(void) > +{ > + u64 val; > + > + if (!boot_cpu_has(X86_FEATURE_INTEL_PT)) > + return; > + > + rdmsrl_safe(MSR_IA32_RTIT_CTL, ); > + val &= ~RTIT_CTL_TRACEEN; > +

Re: [PATCH v2] mm: support anonymous stable page

Hi Hugh, On Tue, Nov 22, 2016 at 08:43:54PM -0800, Hugh Dickins wrote: > On Tue, 22 Nov 2016, Minchan Kim wrote: > > On Mon, Nov 21, 2016 at 07:46:28PM -0800, Hugh Dickins wrote: > > > > > > Andrew might ask if we should Cc stable (haha): I think we agree > > > that it's a defect we've been

Re: [PATCH v2 2/2] mmc: sdhci-pci: Use ACPI to get max frequency for Intel byt sdio controller sub-vended by NI

On 22/11/16 23:53, Zach Brown wrote: > On NI 9037 boards the max SDIO frequency is limited by trace lengths > and other layout choices. The max SDIO frequency is stored in an ACPI > table. > > The driver reads the ACPI entry MXFQ during sdio_probe_slot and sets the > f_max field of the host. > >

Re: [PATCH v2 2/2] mmc: sdhci-pci: Use ACPI to get max frequency for Intel byt sdio controller sub-vended by NI

On 22/11/16 23:53, Zach Brown wrote: > On NI 9037 boards the max SDIO frequency is limited by trace lengths > and other layout choices. The max SDIO frequency is stored in an ACPI > table. > > The driver reads the ACPI entry MXFQ during sdio_probe_slot and sets the > f_max field of the host. > >

Re: [PATCH] Staging: iio: adc: fix sysfs files modes in ad7192.c

On Tue, Nov 22, 2016 at 11:25:14PM -0800, Boyan Vladinov wrote: > Fixes sysfs entries user/group modes and coding style warnings > found by checkpatch.pl tool > > Signed-off-by: Boyan Vladinov > --- > drivers/staging/iio/adc/ad7192.c | 10 +- > 1 file changed, 5

Re: [PATCH] Staging: iio: adc: fix sysfs files modes in ad7192.c

On Tue, Nov 22, 2016 at 11:25:14PM -0800, Boyan Vladinov wrote: > Fixes sysfs entries user/group modes and coding style warnings > found by checkpatch.pl tool > > Signed-off-by: Boyan Vladinov > --- > drivers/staging/iio/adc/ad7192.c | 10 +- > 1 file changed, 5 insertions(+), 5

Re: [v7] QE: remove PPCisms for QE

On Wed, Sep 28, 2016 at 11:15:31AM +0800, Zhao Qiang wrote: > QE was supported on PowerPC, and dependent on PPC, > Now it is supported on other platforms. so remove PPCisms. > > Signed-off-by: Zhao Qiang > --- Changelog should be something like: soc/fsl/qe: Cleanups and

Re: [v7] QE: remove PPCisms for QE

On Wed, Sep 28, 2016 at 11:15:31AM +0800, Zhao Qiang wrote: > QE was supported on PowerPC, and dependent on PPC, > Now it is supported on other platforms. so remove PPCisms. > > Signed-off-by: Zhao Qiang > --- Changelog should be something like: soc/fsl/qe: Cleanups and portability fixes QE

Re: [PATCHv0 1/1] fbdev: add Intel FPGA FRAME BUFFER driver

Hi, On 16/11/16 11:07, Ong, Hean Loong wrote: > From: Ong Hean Loong > > This patch enables the display port IP driver for > Intel Arria 10 SOCFPGA Golden Hardware > Reference Design (GHRD). > > The driver requires enabling the options such as

Re: [PATCHv0 1/1] fbdev: add Intel FPGA FRAME BUFFER driver

Hi, On 16/11/16 11:07, Ong, Hean Loong wrote: > From: Ong Hean Loong > > This patch enables the display port IP driver for > Intel Arria 10 SOCFPGA Golden Hardware > Reference Design (GHRD). > > The driver requires enabling the options such as > Coheherent Memory

RE: [PATCH V3 1/2] powerpc/mpc85xx: Update TMU device tree node for T1040/T1042

> -Original Message- > From: Scott Wood [mailto:o...@buserror.net] > Sent: Wednesday, November 23, 2016 3:07 PM > To: Troy Jia ; rui.zh...@intel.com; edubez...@gmail.com; > robh...@kernel.org; Scott Wood ; shawn...@kernel.org > Cc:

RE: [PATCH V3 1/2] powerpc/mpc85xx: Update TMU device tree node for T1040/T1042

> -Original Message- > From: Scott Wood [mailto:o...@buserror.net] > Sent: Wednesday, November 23, 2016 3:07 PM > To: Troy Jia ; rui.zh...@intel.com; edubez...@gmail.com; > robh...@kernel.org; Scott Wood ; shawn...@kernel.org > Cc: devicet...@vger.kernel.org;

Re: [PATCH] PCI: Add information about describing PCI in ACPI

On 23 November 2016 at 01:06, Bjorn Helgaas wrote: > On Tue, Nov 22, 2016 at 10:09:50AM +, Ard Biesheuvel wrote: >> On 17 November 2016 at 17:59, Bjorn Helgaas wrote: > >> > +PCI host bridges are PNP0A03 or PNP0A08 devices. Their _CRS should >> >

Re: [PATCH] PCI: Add information about describing PCI in ACPI

On 23 November 2016 at 01:06, Bjorn Helgaas wrote: > On Tue, Nov 22, 2016 at 10:09:50AM +, Ard Biesheuvel wrote: >> On 17 November 2016 at 17:59, Bjorn Helgaas wrote: > >> > +PCI host bridges are PNP0A03 or PNP0A08 devices. Their _CRS should >> > +describe all the address space they

[PATCH] trace: Add documentation for mono and mono_raw trace clocks

mono and mono_raw trace clocks access CLOCK_MONOTONIC and CLOCK_MONOTONIC_RAW clocks for tracing purposes. Add documentation for the same. Signed-off-by: Joel Fernandes --- Steven, I skipped adding docs for boot clock as that patch is still being discussed, but please accept

[PATCH] trace: Add documentation for mono and mono_raw trace clocks

mono and mono_raw trace clocks access CLOCK_MONOTONIC and CLOCK_MONOTONIC_RAW clocks for tracing purposes. Add documentation for the same. Signed-off-by: Joel Fernandes --- Steven, I skipped adding docs for boot clock as that patch is still being discussed, but please accept documentation for

Re: [LKP] [net] 34fad54c25: kernel BUG at include/linux/skbuff.h:1935!

On Tue, Nov 22, 2016 at 10:44 PM, Fengguang Wu wrote: > > On Tue, Nov 22, 2016 at 02:04:42PM -0800, Linus Torvalds wrote: > >> I also noticed that the kernel test robot had screwed up the >> participants list for some reason, and had >> >> "Acked-by: Alexander Duyck

Re: [PATCH V3 1/2] powerpc/mpc85xx: Update TMU device tree node for T1040/T1042

On Tue, 2016-10-25 at 10:15 +0800, Jia Hongtao wrote: > From: Hongtao Jia > > Update #thermal-sensor-cells from 0 to 1 according to the new binding. The > sensor specifier added is the monitoring site ID, and represents the "n" in > TRITSRn and TRATSRn. > > Signed-off-by:

Re: [LKP] [net] 34fad54c25: kernel BUG at include/linux/skbuff.h:1935!

On Tue, Nov 22, 2016 at 10:44 PM, Fengguang Wu wrote: > > On Tue, Nov 22, 2016 at 02:04:42PM -0800, Linus Torvalds wrote: > >> I also noticed that the kernel test robot had screwed up the >> participants list for some reason, and had >> >> "Acked-by: Alexander Duyck , David S. >> Miller" >> >>

Re: [PATCH V3 1/2] powerpc/mpc85xx: Update TMU device tree node for T1040/T1042

On Tue, 2016-10-25 at 10:15 +0800, Jia Hongtao wrote: > From: Hongtao Jia > > Update #thermal-sensor-cells from 0 to 1 according to the new binding. The > sensor specifier added is the monitoring site ID, and represents the "n" in > TRITSRn and TRATSRn. > > Signed-off-by: Jia Hongtao Where

Re: [PATCH] HID: lg: fix noderef.cocci warnings

On Wed, 23 Nov 2016, Fengguang Wu wrote: > On Tue, Nov 22, 2016 at 11:44:34AM +0100, Jiri Kosina wrote: > > On Mon, 21 Nov 2016, Benjamin Tissoires wrote: > > > > > > Generated by: scripts/coccinelle/misc/noderef.cocci > > > > > > > > CC: Benjamin Tissoires > > >

[RFC 0/2] GFP_NOFAIL cleanups

Hi, Tetsuo has noticed [1] that recent changes have changed GFP_NOFAIL semantic for costly order requests. I believe that the primary reason why this happened is that our GFP_NOFAIL checks are too scattered and it is really easy to forget about adding one. That's why I am proposing patch 1 which

[RFC 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

From: Michal Hocko __alloc_pages_may_oom makes sure to skip the OOM killer depending on the allocation request. This includes lowmem requests, costly high order requests and others. For a long time __GFP_NOFAIL acted as an override for all those rules. This is not documented and

Re: [PATCH] HID: lg: fix noderef.cocci warnings

On Wed, 23 Nov 2016, Fengguang Wu wrote: > On Tue, Nov 22, 2016 at 11:44:34AM +0100, Jiri Kosina wrote: > > On Mon, 21 Nov 2016, Benjamin Tissoires wrote: > > > > > > Generated by: scripts/coccinelle/misc/noderef.cocci > > > > > > > > CC: Benjamin Tissoires > > > > Signed-off-by: Fengguang Wu

[RFC 0/2] GFP_NOFAIL cleanups

Hi, Tetsuo has noticed [1] that recent changes have changed GFP_NOFAIL semantic for costly order requests. I believe that the primary reason why this happened is that our GFP_NOFAIL checks are too scattered and it is really easy to forget about adding one. That's why I am proposing patch 1 which

[RFC 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

From: Michal Hocko __alloc_pages_may_oom makes sure to skip the OOM killer depending on the allocation request. This includes lowmem requests, costly high order requests and others. For a long time __GFP_NOFAIL acted as an override for all those rules. This is not documented and it can be quite

Re: 4.8.8 kernel trigger OOM killer repeatedly when I have lots of RAM that should be free

On Wed 23-11-16 14:53:12, Hillf Danton wrote: > On Wednesday, November 23, 2016 2:34 PM Michal Hocko wrote: > > @@ -3161,6 +3161,16 @@ should_compact_retry(struct alloc_context *ac, > > unsigned int order, int alloc_fla > > if (!order || order > PAGE_ALLOC_COSTLY_ORDER) > > return

Re: 4.8.8 kernel trigger OOM killer repeatedly when I have lots of RAM that should be free

On Wed 23-11-16 14:53:12, Hillf Danton wrote: > On Wednesday, November 23, 2016 2:34 PM Michal Hocko wrote: > > @@ -3161,6 +3161,16 @@ should_compact_retry(struct alloc_context *ac, > > unsigned int order, int alloc_fla > > if (!order || order > PAGE_ALLOC_COSTLY_ORDER) > > return

linux-next: Tree for Nov 23

Hi all, Changes since 20161122: The clk tree gained conflicts against the arm-soc tree (resolved today with help). The md tree gained a conflict against the block tree. The kvm-ppc-paulus tree gained a conflict against the powerpc-fixes tree. The kvms390 tree gained a conflict against

Re: 4.8.8 kernel trigger OOM killer repeatedly when I have lots of RAM that should be free

On Wednesday, November 23, 2016 2:34 PM Michal Hocko wrote: > @@ -3161,6 +3161,16 @@ should_compact_retry(struct alloc_context *ac, > unsigned int order, int alloc_fla > if (!order || order > PAGE_ALLOC_COSTLY_ORDER) > return false; > > +#ifdef CONFIG_COMPACTION > + /* >

linux-next: Tree for Nov 23

Hi all, Changes since 20161122: The clk tree gained conflicts against the arm-soc tree (resolved today with help). The md tree gained a conflict against the block tree. The kvm-ppc-paulus tree gained a conflict against the powerpc-fixes tree. The kvms390 tree gained a conflict against

Re: 4.8.8 kernel trigger OOM killer repeatedly when I have lots of RAM that should be free

On Wednesday, November 23, 2016 2:34 PM Michal Hocko wrote: > @@ -3161,6 +3161,16 @@ should_compact_retry(struct alloc_context *ac, > unsigned int order, int alloc_fla > if (!order || order > PAGE_ALLOC_COSTLY_ORDER) > return false; > > +#ifdef CONFIG_COMPACTION > + /* >

Re: [LKP] [net] 34fad54c25: kernel BUG at include/linux/skbuff.h:1935!

Hi Linus, On Tue, Nov 22, 2016 at 02:04:42PM -0800, Linus Torvalds wrote: [snip] I also noticed that the kernel test robot had screwed up the participants list for some reason, and had "Acked-by: Alexander Duyck , David S. Miller" as one of

Re: [LKP] [net] 34fad54c25: kernel BUG at include/linux/skbuff.h:1935!

Hi Linus, On Tue, Nov 22, 2016 at 02:04:42PM -0800, Linus Torvalds wrote: [snip] I also noticed that the kernel test robot had screwed up the participants list for some reason, and had "Acked-by: Alexander Duyck , David S. Miller" as one of the participants. So there's some odd commit

Re: [HMM v13 08/18] mm/hmm: heterogeneous memory management (HMM for short)

On 11/18/2016 11:48 PM, Jérôme Glisse wrote: > HMM provides 3 separate functionality : > - Mirroring: synchronize CPU page table and device page table > - Device memory: allocating struct page for device memory > - Migration: migrating regular memory to device memory > > This patch

Re: [HMM v13 08/18] mm/hmm: heterogeneous memory management (HMM for short)

On 11/18/2016 11:48 PM, Jérôme Glisse wrote: > HMM provides 3 separate functionality : > - Mirroring: synchronize CPU page table and device page table > - Device memory: allocating struct page for device memory > - Migration: migrating regular memory to device memory > > This patch

Re: 4.8.8 kernel trigger OOM killer repeatedly when I have lots of RAM that should be free

On Tue 22-11-16 11:38:47, Linus Torvalds wrote: > On Tue, Nov 22, 2016 at 8:14 AM, Vlastimil Babka wrote: > > > > Thanks a lot for the testing. So what do we do now about 4.8? (4.7 is > > already EOL AFAICS). > > > > - send the patch [1] as 4.8-only stable. > > I think that's the

Re: 4.8.8 kernel trigger OOM killer repeatedly when I have lots of RAM that should be free

On Tue 22-11-16 11:38:47, Linus Torvalds wrote: > On Tue, Nov 22, 2016 at 8:14 AM, Vlastimil Babka wrote: > > > > Thanks a lot for the testing. So what do we do now about 4.8? (4.7 is > > already EOL AFAICS). > > > > - send the patch [1] as 4.8-only stable. > > I think that's the right thing to

Re: [PATCH 0/8] CaitSith LSM module

Tetsuo Handa wrote: > John Johansen wrote: > > > In order to minimize the burden of reviewing, this patchset implements > > > only functionality of checking program execution requests (i.e. execve() > > > system call) using pathnames. I'm planning to add other functionalities > > > after this

Re: [PATCH 0/8] CaitSith LSM module

Tetsuo Handa wrote: > John Johansen wrote: > > > In order to minimize the burden of reviewing, this patchset implements > > > only functionality of checking program execution requests (i.e. execve() > > > system call) using pathnames. I'm planning to add other functionalities > > > after this

Re: sendfile from 9p fs into af_alg

On Tue, Nov 22, 2016 at 08:55:59PM -0800, Alexei Starovoitov wrote: > On Wed, Nov 23, 2016 at 04:46:26AM +, Al Viro wrote: > > On Tue, Nov 22, 2016 at 07:58:29PM -0800, Alexei Starovoitov wrote: > > > Hi Al, > > > > > > it seems the following commit 523ac9afc73a ("switch > > >

Re: sendfile from 9p fs into af_alg

On Tue, Nov 22, 2016 at 08:55:59PM -0800, Alexei Starovoitov wrote: > On Wed, Nov 23, 2016 at 04:46:26AM +, Al Viro wrote: > > On Tue, Nov 22, 2016 at 07:58:29PM -0800, Alexei Starovoitov wrote: > > > Hi Al, > > > > > > it seems the following commit 523ac9afc73a ("switch > > >

Re: [PATCH v16 10/15] clocksource/drivers/arm_arch_timer: Refactor the timer init code to prepare for GTDT

Hi Mark, On 19 November 2016 at 04:03, Mark Rutland wrote: > On Wed, Nov 16, 2016 at 09:49:03PM +0800, fu@linaro.org wrote: >> From: Fu Wei >> >> The patch refactor original memory-mapped timer init code: >> (1) Extract a subfunction for

Re: [PATCH v16 10/15] clocksource/drivers/arm_arch_timer: Refactor the timer init code to prepare for GTDT

Hi Mark, On 19 November 2016 at 04:03, Mark Rutland wrote: > On Wed, Nov 16, 2016 at 09:49:03PM +0800, fu@linaro.org wrote: >> From: Fu Wei >> >> The patch refactor original memory-mapped timer init code: >> (1) Extract a subfunction for detecting a bast time frame: >>

Re: net/can: use-after-free in bcm_rx_thr_flush

On 11/22/2016 06:37 PM, Andrey Konovalov wrote: On Tue, Nov 22, 2016 at 6:29 PM, Oliver Hartkopp wrote: Hi Andrey, thanks for the report. Although I can't see the issue in the code ... Oh, I can see it now m( Will send a patch today. Many thanks, Oliver

Re: net/can: use-after-free in bcm_rx_thr_flush

On 11/22/2016 06:37 PM, Andrey Konovalov wrote: On Tue, Nov 22, 2016 at 6:29 PM, Oliver Hartkopp wrote: Hi Andrey, thanks for the report. Although I can't see the issue in the code ... Oh, I can see it now m( Will send a patch today. Many thanks, Oliver

Re: [PATCH v2 1/5] ARM: memory: da8xx-ddrctl: new driver

On Tuesday 22 November 2016 11:51 PM, Frank Rowand wrote: > Please note that the compatible property might contain several strings, not > just > a single string. So I guess the best thing to do is to use of_property_read_string_index() and print the sting at index 0. Thanks, Sekhar

Re: [PATCH] HID: lg: fix noderef.cocci warnings

On Tue, Nov 22, 2016 at 11:44:34AM +0100, Jiri Kosina wrote: On Mon, 21 Nov 2016, Benjamin Tissoires wrote: > Generated by: scripts/coccinelle/misc/noderef.cocci > > CC: Benjamin Tissoires > Signed-off-by: Fengguang Wu > --- > >

Re: [PATCH v2 1/5] ARM: memory: da8xx-ddrctl: new driver

On Tuesday 22 November 2016 11:51 PM, Frank Rowand wrote: > Please note that the compatible property might contain several strings, not > just > a single string. So I guess the best thing to do is to use of_property_read_string_index() and print the sting at index 0. Thanks, Sekhar

Re: [PATCH] HID: lg: fix noderef.cocci warnings

On Tue, Nov 22, 2016 at 11:44:34AM +0100, Jiri Kosina wrote: On Mon, 21 Nov 2016, Benjamin Tissoires wrote: > Generated by: scripts/coccinelle/misc/noderef.cocci > > CC: Benjamin Tissoires > Signed-off-by: Fengguang Wu > --- > > hid-lg.c |6 -- > 1 file changed, 4 insertions(+), 2

Crypto Fixes for 4.9

Hi Linus: The last push broke algif_hash for all shash implementations, so this is a follow-up to fix that. It also fixes a problem in the crypto scatterwalk that triggers a BUG_ON with certain debugging options due to the new vmalloced-stack code. Please pull from

Crypto Fixes for 4.9

Hi Linus: The last push broke algif_hash for all shash implementations, so this is a follow-up to fix that. It also fixes a problem in the crypto scatterwalk that triggers a BUG_ON with certain debugging options due to the new vmalloced-stack code. Please pull from

Re: [PATCH v2 7/8] perf sched timehist: Add -V/--cpu-visual option

On Tue, Nov 22, 2016 at 03:33:26PM -0300, Arnaldo Carvalho de Melo wrote: > Em Wed, Nov 16, 2016 at 03:06:33PM +0900, Namhyung Kim escreveu: > > From: David Ahern > > > > The -V option provides a visual aid for sched switches by cpu: > > > > $ perf sched timehist -V > >

Re: [PATCH v2 7/8] perf sched timehist: Add -V/--cpu-visual option

On Tue, Nov 22, 2016 at 03:33:26PM -0300, Arnaldo Carvalho de Melo wrote: > Em Wed, Nov 16, 2016 at 03:06:33PM +0900, Namhyung Kim escreveu: > > From: David Ahern > > > > The -V option provides a visual aid for sched switches by cpu: > > > > $ perf sched timehist -V > > time

Re: Locking API testsuite output mangled

Christian Kujau writes: > The "Locking API testsuite" output during bootup (with > CONFIG_DEBUG_LOCKING_API_SELFTESTS=y) on this PowerPC system looks > mangled, possibly related to the recent printk changes (4bcc595ccd80, > "printk: reinstate KERN_CONT for printing

Re: Locking API testsuite output mangled

Christian Kujau writes: > The "Locking API testsuite" output during bootup (with > CONFIG_DEBUG_LOCKING_API_SELFTESTS=y) on this PowerPC system looks > mangled, possibly related to the recent printk changes (4bcc595ccd80, > "printk: reinstate KERN_CONT for printing continuation lines").

[PATCH 1/2] kvm: Move KVM_PPC_PVINFO_FLAGS_EV_IDLE definition next to its structure

The KVM_PPC_PVINFO_FLAGS_EV_IDLE macro defines a bit for use in the flags field of struct kvm_ppc_pvinfo. However, changes since that was introduced have moved it away from that structure definition, which is confusing. Move it back next to the structure it belongs with. Signed-off-by: David

[PATCH 1/2] kvm: Move KVM_PPC_PVINFO_FLAGS_EV_IDLE definition next to its structure

The KVM_PPC_PVINFO_FLAGS_EV_IDLE macro defines a bit for use in the flags field of struct kvm_ppc_pvinfo. However, changes since that was introduced have moved it away from that structure definition, which is confusing. Move it back next to the structure it belongs with. Signed-off-by: David

[PATCH 0/2] Preliminary cleanups for HPT resizing

Hi Paul, I'm still chasing this confusion about the CAS bit to send the real HPT resizing patches. However, in the meantime, here are some preliminary cleanups. These cleanups stand on their own, although I wrote them in the context of writing the HPT resizing code, and are prerequisites for

[PATCH 0/2] Preliminary cleanups for HPT resizing

Hi Paul, I'm still chasing this confusion about the CAS bit to send the real HPT resizing patches. However, in the meantime, here are some preliminary cleanups. These cleanups stand on their own, although I wrote them in the context of writing the HPT resizing code, and are prerequisites for

[PATCH 2/2] powerpc/kvm: Corectly report KVM_CAP_PPC_ALLOC_HTAB

At present KVM on powerpc always reports KVM_CAP_PPC_ALLOC_HTAB as enabled. However, the ioctl() it advertises (KVM_PPC_ALLOCATE_HTAB) only actually works on KVM HV. On KVM PR it will fail with ENOTTY. qemu already has a workaround for this, so it's not breaking things in practice, but it would

[PATCH 2/2] powerpc/kvm: Corectly report KVM_CAP_PPC_ALLOC_HTAB

At present KVM on powerpc always reports KVM_CAP_PPC_ALLOC_HTAB as enabled. However, the ioctl() it advertises (KVM_PPC_ALLOCATE_HTAB) only actually works on KVM HV. On KVM PR it will fail with ENOTTY. qemu already has a workaround for this, so it's not breaking things in practice, but it would

Re: [PATCH V9 1/6] tracing: add a possibility of exporting function trace to other places instead of ring buffer only

Hi Steve, Actually I had been keeping the idea that we would need to export most kinds of traces rather than function trace only to somewhere else, say STM, that's also why I made STM_SOURCE_FTRACE depending on TRACING which was later changed to FUNCTION_TRACER according to you advice. Thanks,

Re: [PATCH V9 1/6] tracing: add a possibility of exporting function trace to other places instead of ring buffer only

Hi Steve, Actually I had been keeping the idea that we would need to export most kinds of traces rather than function trace only to somewhere else, say STM, that's also why I made STM_SOURCE_FTRACE depending on TRACING which was later changed to FUNCTION_TRACER according to you advice. Thanks,

Re: [RESEND PATCH 2/3] ARM: davinci: hawk: Remove vbus and over current gpios

On Tuesday 22 November 2016 09:11 PM, Axel Haslam wrote: > Hi Sekhar > > On Tue, Nov 22, 2016 at 11:37 AM, Sekhar Nori wrote: >> On Monday 21 November 2016 10:23 PM, Axel Haslam wrote: >>> The hawk board VBUS is fixed to a 5v source, and the over >>> current pin is actually not

Re: [RESEND PATCH 2/3] ARM: davinci: hawk: Remove vbus and over current gpios

On Tuesday 22 November 2016 09:11 PM, Axel Haslam wrote: > Hi Sekhar > > On Tue, Nov 22, 2016 at 11:37 AM, Sekhar Nori wrote: >> On Monday 21 November 2016 10:23 PM, Axel Haslam wrote: >>> The hawk board VBUS is fixed to a 5v source, and the over >>> current pin is actually not connected to the

Re: sendfile from 9p fs into af_alg

On Wed, Nov 23, 2016 at 04:46:26AM +, Al Viro wrote: > On Tue, Nov 22, 2016 at 07:58:29PM -0800, Alexei Starovoitov wrote: > > Hi Al, > > > > it seems the following commit 523ac9afc73a ("switch > > default_file_splice_read() to use of pipe-backed iov_iter") > > breaks sendfile from 9p fs

Re: sendfile from 9p fs into af_alg

On Wed, Nov 23, 2016 at 04:46:26AM +, Al Viro wrote: > On Tue, Nov 22, 2016 at 07:58:29PM -0800, Alexei Starovoitov wrote: > > Hi Al, > > > > it seems the following commit 523ac9afc73a ("switch > > default_file_splice_read() to use of pipe-backed iov_iter") > > breaks sendfile from 9p fs

Re: sendfile from 9p fs into af_alg

On Tue, Nov 22, 2016 at 07:58:29PM -0800, Alexei Starovoitov wrote: > Hi Al, > > it seems the following commit 523ac9afc73a ("switch > default_file_splice_read() to use of pipe-backed iov_iter") > breaks sendfile from 9p fs into af_alg socket. > sendfile into af_alg is used by iproute2/tc. > I'm

Re: sendfile from 9p fs into af_alg

On Tue, Nov 22, 2016 at 07:58:29PM -0800, Alexei Starovoitov wrote: > Hi Al, > > it seems the following commit 523ac9afc73a ("switch > default_file_splice_read() to use of pipe-backed iov_iter") > breaks sendfile from 9p fs into af_alg socket. > sendfile into af_alg is used by iproute2/tc. > I'm

Re: [PATCH v2] tools lib traceevent: Add retrieval of preempt count and latency flags

Hi Arnaldo and Steve, On Tue, Nov 22, 2016 at 03:06:24PM -0300, Arnaldo Carvalho de Melo wrote: > Em Tue, Nov 22, 2016 at 11:31:58AM -0500, Steven Rostedt escreveu: > > > > Add a way to retrieve the preempt count as well as the latency flags from a > > pevent_record. > > > > int

Re: [PATCH v2] tools lib traceevent: Add retrieval of preempt count and latency flags

Hi Arnaldo and Steve, On Tue, Nov 22, 2016 at 03:06:24PM -0300, Arnaldo Carvalho de Melo wrote: > Em Tue, Nov 22, 2016 at 11:31:58AM -0500, Steven Rostedt escreveu: > > > > Add a way to retrieve the preempt count as well as the latency flags from a > > pevent_record. > > > > int

Re: [PATCH v2] mm: support anonymous stable page

On Tue, 22 Nov 2016, Minchan Kim wrote: > On Mon, Nov 21, 2016 at 07:46:28PM -0800, Hugh Dickins wrote: > > > > Andrew might ask if we should Cc stable (haha): I think we agree > > that it's a defect we've been aware of ever since stable pages were > > first proposed, but nobody has actually been

Re: [PATCH v2] mm: support anonymous stable page

On Tue, 22 Nov 2016, Minchan Kim wrote: > On Mon, Nov 21, 2016 at 07:46:28PM -0800, Hugh Dickins wrote: > > > > Andrew might ask if we should Cc stable (haha): I think we agree > > that it's a defect we've been aware of ever since stable pages were > > first proposed, but nobody has actually been

linux-next: remove the remoteproc tree?

Hi Ohad, The remoteproc tree (git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git#for-next) has not bee updated for more than a year. Should I remove it from linux-next? Or could it (at least) be cleaned up, please? -- Cheers, Stephen Rothwell

linux-next: remove the remoteproc tree?

Hi Ohad, The remoteproc tree (git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git#for-next) has not bee updated for more than a year. Should I remove it from linux-next? Or could it (at least) be cleaned up, please? -- Cheers, Stephen Rothwell

Re: [PATCH 3/5] thermal: rockchip: fixes invalid temperature case

On Wed, Nov 23, 2016 at 11:03:33AM +0800, Caesar Wang wrote: > 在 2016年11月23日 10:33, Brian Norris 写道: > >IIUC, "too high" should not be interpreted as TSADCV2_DATA_MASK on > >rk3288, should it? That corresponds to -40C, which means you'll be > >triggering the alarm temperature at a very *low*

Re: [PATCH 3/5] thermal: rockchip: fixes invalid temperature case

On Wed, Nov 23, 2016 at 11:03:33AM +0800, Caesar Wang wrote: > 在 2016年11月23日 10:33, Brian Norris 写道: > >IIUC, "too high" should not be interpreted as TSADCV2_DATA_MASK on > >rk3288, should it? That corresponds to -40C, which means you'll be > >triggering the alarm temperature at a very *low*

Re: [fuse-devel] fuse: max_background and congestion_threshold settings

On 11/22/2016 02:45 PM, Nikolaus Rath wrote: On Nov 16 2016, Maxim Patlasov wrote: On 11/16/2016 12:19 PM, Nikolaus Rath wrote: On Nov 16 2016, Maxim Patlasov wrote: On 11/16/2016 11:19 AM, Nikolaus Rath wrote: Hi Maxim, On Nov 15 2016,

Re: [fuse-devel] fuse: max_background and congestion_threshold settings

On 11/22/2016 02:45 PM, Nikolaus Rath wrote: On Nov 16 2016, Maxim Patlasov wrote: On 11/16/2016 12:19 PM, Nikolaus Rath wrote: On Nov 16 2016, Maxim Patlasov wrote: On 11/16/2016 11:19 AM, Nikolaus Rath wrote: Hi Maxim, On Nov 15 2016, Maxim Patlasov wrote: On 11/15/2016 08:18 AM,

Re: linux-next: Tree for Nov 22 (ext4 + dax)

On Wed, Nov 23, 2016 at 04:19:35AM +1100, Stephen Rothwell wrote: > > I don't see why this is happening but I reproduced it multiple times. > > > > fs/built-in.o: In function `ext4_dax_fault': > > file.c:(.text+0x6278b): undefined reference to `dax_iomap_fault' > > file.c:(.text+0x627dc):

Re: linux-next: Tree for Nov 22 (ext4 + dax)

On Wed, Nov 23, 2016 at 04:19:35AM +1100, Stephen Rothwell wrote: > > I don't see why this is happening but I reproduced it multiple times. > > > > fs/built-in.o: In function `ext4_dax_fault': > > file.c:(.text+0x6278b): undefined reference to `dax_iomap_fault' > > file.c:(.text+0x627dc):

Re: [PATCH v4 3/3] dmaengine: sun6i: share the dma driver with sun50i

On Sun, Nov 20, 2016 at 06:45:40PM +0800, Hao Zhang wrote: > Changes the limited buswith to 8 bytes,and add > the test in sun6i_dma_config function > > Accroding to sun6i dma driver, i think ,if the client typo and other grammatical mistakes here.. > doesn't configure the address

Re: [PATCH v4 3/3] dmaengine: sun6i: share the dma driver with sun50i

On Sun, Nov 20, 2016 at 06:45:40PM +0800, Hao Zhang wrote: > Changes the limited buswith to 8 bytes,and add > the test in sun6i_dma_config function > > Accroding to sun6i dma driver, i think ,if the client typo and other grammatical mistakes here.. > doesn't configure the address

  1   2   3   4   5   6   7   8   9   10   >