Re: [GIT PULL REQUEST] watchdog - v4.9 merge window

Hi Linus, It's an old server with only 512Mb RAM. I'm in the progress off replacing it (in another datacenter). Meanwhile I'll restart git-daemon. Sorry, Wim. > On Wed, Oct 12, 2016 at 11:35 AM, Wim Van Sebroeck wrote: > > Hi Linus, > > > > Please pull from 'master' branch of

Re: [PATCH v3 3/6] pwm: imx: support output polarity inversion

Hi Stefan, > On 2016-10-12 15:15, Lukasz Majewski wrote: > > Hi Stefan, > > > >> On 2016-10-07 08:11, Bhuvanchandra DV wrote: > >> > From: Lothar Wassmann > >> > > >> > The i.MX pwm unit on i.MX27 and newer SoCs provides a > >> > configurable output polarity. This

Re: [GIT PULL REQUEST] watchdog - v4.9 merge window

Hi Linus, It's an old server with only 512Mb RAM. I'm in the progress off replacing it (in another datacenter). Meanwhile I'll restart git-daemon. Sorry, Wim. > On Wed, Oct 12, 2016 at 11:35 AM, Wim Van Sebroeck wrote: > > Hi Linus, > > > > Please pull from 'master' branch of > >

Re: [PATCH v3 3/6] pwm: imx: support output polarity inversion

Hi Stefan, > On 2016-10-12 15:15, Lukasz Majewski wrote: > > Hi Stefan, > > > >> On 2016-10-07 08:11, Bhuvanchandra DV wrote: > >> > From: Lothar Wassmann > >> > > >> > The i.MX pwm unit on i.MX27 and newer SoCs provides a > >> > configurable output polarity. This patch adds support to utilize

Re: [PATCH v4 0/3] Broadcom STB AVS CPUfreq driver

On 12-10-16, 15:12, Markus Mayer wrote: > This series contains the CPUfreq driver for Broadcom SoCs that use "AVS > Firmware" for voltage and frequency scaling. All voltage and frequency > transitions are performed by the firmware and are therefore hidden from > Linux. > > The driver provides a

Re: [PATCH v4 0/3] Broadcom STB AVS CPUfreq driver

On 12-10-16, 15:12, Markus Mayer wrote: > This series contains the CPUfreq driver for Broadcom SoCs that use "AVS > Firmware" for voltage and frequency scaling. All voltage and frequency > transitions are performed by the firmware and are therefore hidden from > Linux. > > The driver provides a

Re: [PATCH 3/8] PM / OPP: Manage supply's voltage/current in a separate structure

On 12-10-16, 16:15, Dave Gerlach wrote: > > /** > >+ * struct dev_pm_opp_supply - Power supply voltage/current values > >+ * @u_volt: Target voltage in microvolts corresponding to this OPP > >+ * @u_volt_min: Minimum voltage in microvolts corresponding to thisq OPP > >+ * @u_volt_max:

Re: [PATCH 3/8] PM / OPP: Manage supply's voltage/current in a separate structure

On 12-10-16, 16:15, Dave Gerlach wrote: > > /** > >+ * struct dev_pm_opp_supply - Power supply voltage/current values > >+ * @u_volt: Target voltage in microvolts corresponding to this OPP > >+ * @u_volt_min: Minimum voltage in microvolts corresponding to thisq OPP > >+ * @u_volt_max:

lz4 v lz4hc compression discrepancy

Hi, I'm trying to use the lz4 library in the kernel for compression and I have a case where for a candidate payload worth 16k bytes (attached), the data that is retrieved after compression + decompression is different from the original data when using lz4hc. On the other hand, using the lz4

lz4 v lz4hc compression discrepancy

Hi, I'm trying to use the lz4 library in the kernel for compression and I have a case where for a candidate payload worth 16k bytes (attached), the data that is retrieved after compression + decompression is different from the original data when using lz4hc. On the other hand, using the lz4

[PATCH 3/3] ARM: dts: mt2701: Add mtk-cirq node for mt2701

This commit add mtk-cirq node to mt2701 dtsi. Signed-off-by: Youlin Pei --- arch/arm/boot/dts/mt2701.dtsi | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi index

[PATCH 3/3] ARM: dts: mt2701: Add mtk-cirq node for mt2701

This commit add mtk-cirq node to mt2701 dtsi. Signed-off-by: Youlin Pei --- arch/arm/boot/dts/mt2701.dtsi | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi index 7eab6f4..a314df9 100644 ---

[PATCH 0/3] Add Mediatek CIRQ interrupt controller

In Mediatek SOCs, the CIRQ is a low power interrupt controller designed to works outside MCUSYS which comprises with Cortex-Ax cores,CCI and GIC. The CIRQ controller is integrated in between MCUSYS and interrupt sources as the second level interrupt controller. The external interrupts which

[PATCH 0/3] Add Mediatek CIRQ interrupt controller

In Mediatek SOCs, the CIRQ is a low power interrupt controller designed to works outside MCUSYS which comprises with Cortex-Ax cores,CCI and GIC. The CIRQ controller is integrated in between MCUSYS and interrupt sources as the second level interrupt controller. The external interrupts which

[PATCH 2/3] irqchip: mtk-cirq: Add mediatek mtk-cirq implement

This commit add the mtk-cirq implement for mt2701. Signed-off-by: Youlin Pei --- drivers/irqchip/Makefile |2 +- drivers/irqchip/irq-mtk-cirq.c | 257 2 files changed, 258 insertions(+), 1 deletion(-) create mode

[PATCH 1/3] binding: irqchip: mtk-cirq: Add binding document

This commit adds the device tree binding document for the mediatek cirq. Signed-off-by: Youlin Pei --- base on v4.8-rc1 --- .../interrupt-controller/mediatek,cirq.txt | 30 1 file changed, 30 insertions(+) create mode 100644

[PATCH 2/3] irqchip: mtk-cirq: Add mediatek mtk-cirq implement

This commit add the mtk-cirq implement for mt2701. Signed-off-by: Youlin Pei --- drivers/irqchip/Makefile |2 +- drivers/irqchip/irq-mtk-cirq.c | 257 2 files changed, 258 insertions(+), 1 deletion(-) create mode 100644

[PATCH 1/3] binding: irqchip: mtk-cirq: Add binding document

This commit adds the device tree binding document for the mediatek cirq. Signed-off-by: Youlin Pei --- base on v4.8-rc1 --- .../interrupt-controller/mediatek,cirq.txt | 30 1 file changed, 30 insertions(+) create mode 100644

Re: [PATCH v8 2/2] clocksource: add J-Core timer/clocksource driver

On Wed, Oct 12, 2016 at 11:31:26PM +0200, Daniel Lezcano wrote: > > > I understand the goal is to have one single configuration and everything > > > DT based and it sounds great but what is missing here is just a subarch, > > > not an option to enable/disable the timer. > > > > > > Give a try

Re: [PATCH v8 2/2] clocksource: add J-Core timer/clocksource driver

On Wed, Oct 12, 2016 at 11:31:26PM +0200, Daniel Lezcano wrote: > > > I understand the goal is to have one single configuration and everything > > > DT based and it sounds great but what is missing here is just a subarch, > > > not an option to enable/disable the timer. > > > > > > Give a try

Re: [PATCH] staging: greybus: timesync.c: Fixed WARNING for brace issue

On Thu, Oct 13, 2016 at 1:20 AM, Chase Metzger wrote: > Removed a checkpatch warning for braces on single argument if and else > statement. > > Signed-off-by: Chase Metzger > --- > drivers/staging/greybus/timesync.c | 6 +++--- > 1 file

Re: [PATCH] staging: greybus: timesync.c: Fixed WARNING for brace issue

On Thu, Oct 13, 2016 at 1:20 AM, Chase Metzger wrote: > Removed a checkpatch warning for braces on single argument if and else > statement. > > Signed-off-by: Chase Metzger > --- > drivers/staging/greybus/timesync.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git

[PATCH 10/10] mm: replace access_process_vm() write parameter with gup_flags

This patch removes the write parameter from access_process_vm() and replaces it with a gup_flags parameter as use of this function previously _implied_ FOLL_FORCE, whereas after this patch callers explicitly pass this flag. We make this explicit as use of FOLL_FORCE can result in surprising

[PATCH 10/10] mm: replace access_process_vm() write parameter with gup_flags

This patch removes the write parameter from access_process_vm() and replaces it with a gup_flags parameter as use of this function previously _implied_ FOLL_FORCE, whereas after this patch callers explicitly pass this flag. We make this explicit as use of FOLL_FORCE can result in surprising

[PATCH 06/10] mm: replace get_user_pages() write/force parameters with gup_flags

This patch removes the write and force parameters from get_user_pages() and replaces them with a gup_flags parameter to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo Stoakes

[PATCH 06/10] mm: replace get_user_pages() write/force parameters with gup_flags

This patch removes the write and force parameters from get_user_pages() and replaces them with a gup_flags parameter to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo Stoakes

[PATCH 05/10] mm: replace get_vaddr_frames() write/force parameters with gup_flags

This patch removes the write and force parameters from get_vaddr_frames() and replaces them with a gup_flags parameter to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo Stoakes

[PATCH 05/10] mm: replace get_vaddr_frames() write/force parameters with gup_flags

This patch removes the write and force parameters from get_vaddr_frames() and replaces them with a gup_flags parameter to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo Stoakes

[PATCH 08/10] mm: replace __access_remote_vm() write parameter with gup_flags

This patch removes the write parameter from __access_remote_vm() and replaces it with a gup_flags parameter as use of this function previously _implied_ FOLL_FORCE, whereas after this patch callers explicitly pass this flag. We make this explicit as use of FOLL_FORCE can result in surprising

[PATCH 08/10] mm: replace __access_remote_vm() write parameter with gup_flags

This patch removes the write parameter from __access_remote_vm() and replaces it with a gup_flags parameter as use of this function previously _implied_ FOLL_FORCE, whereas after this patch callers explicitly pass this flag. We make this explicit as use of FOLL_FORCE can result in surprising

[PATCH 09/10] mm: replace access_remote_vm() write parameter with gup_flags

This patch removes the write parameter from access_remote_vm() and replaces it with a gup_flags parameter as use of this function previously _implied_ FOLL_FORCE, whereas after this patch callers explicitly pass this flag. We make this explicit as use of FOLL_FORCE can result in surprising

[PATCH 09/10] mm: replace access_remote_vm() write parameter with gup_flags

This patch removes the write parameter from access_remote_vm() and replaces it with a gup_flags parameter as use of this function previously _implied_ FOLL_FORCE, whereas after this patch callers explicitly pass this flag. We make this explicit as use of FOLL_FORCE can result in surprising

Intel PT: Address filtering not working. (cc me)

Usage: sudo perf record -e intel_pt//u --filter='filter 0x40 / 0x1000 @./a.out' ./a.out 123 a.out is my program (for loop, call using function pointer and use of longjump) and 123 is the argument. Output: [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 1.171

Intel PT: Address filtering not working. (cc me)

Usage: sudo perf record -e intel_pt//u --filter='filter 0x40 / 0x1000 @./a.out' ./a.out 123 a.out is my program (for loop, call using function pointer and use of longjump) and 123 is the argument. Output: [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 1.171

[PATCH v2] z3fold: fix the potential encode bug in encod_handle

From: zhong jiang At present, zhdr->first_num plus bud can exceed the BUDDY_MASK in encode_handle, it will lead to the the caller handle_to_buddy return the error value. The patch fix the issue by changing the BUDDY_MASK to PAGE_MASK, it will be consistent with

[PATCH v2] z3fold: fix the potential encode bug in encod_handle

From: zhong jiang At present, zhdr->first_num plus bud can exceed the BUDDY_MASK in encode_handle, it will lead to the the caller handle_to_buddy return the error value. The patch fix the issue by changing the BUDDY_MASK to PAGE_MASK, it will be consistent with handle_to_z3fold_header. At the

Re: [PATCH] Staging:greybus:arche-apb-ctrl: fixed some coding style issue

On Wed, Oct 12, 2016 at 04:45:54PM +0200, Greg KH wrote: > > You can subscribe to the driverdev mailing list to see what othes are > working on, and you can follow my staging-testing kernel branch in the > staging.git tree. But sometimes you just get unlucky, lots of people > are working on

Re: [PATCH] Staging:greybus:arche-apb-ctrl: fixed some coding style issue

On Wed, Oct 12, 2016 at 04:45:54PM +0200, Greg KH wrote: > > You can subscribe to the driverdev mailing list to see what othes are > working on, and you can follow my staging-testing kernel branch in the > staging.git tree. But sometimes you just get unlucky, lots of people > are working on

Re: [PATCH] staging: android: ion: Make ion_free asynchronous more actively.

On 10/10/2016 07:31 PM, ming.ling wrote: From: Ming Ling So far some ion heaps such as carveout_heap, chunk_heap, system_heap have freed buffers asynchrounously. Freed buffers are placed on a free list and freed from a low priority background thread. If allocations

Re: [PATCH] staging: android: ion: Make ion_free asynchronous more actively.

On 10/10/2016 07:31 PM, ming.ling wrote: From: Ming Ling So far some ion heaps such as carveout_heap, chunk_heap, system_heap have freed buffers asynchrounously. Freed buffers are placed on a free list and freed from a low priority background thread. If allocations from a particular heap fail,

Re: [PATCH] z3fold: fix the potential encode bug in encod_handle

On 2016/10/13 11:33, zhongjiang wrote: > From: zhong jiang > > At present, zhdr->first_num plus bud can exceed the BUDDY_MASK > in encode_handle, it will lead to the the caller handle_to_buddy > return the error value. > > The patch fix the issue by changing the BUDDY_MASK

[PATCH] staging: i4l: pcbit: replace some include asm/*.h with linux/*.h

Fixes the following checkpatch output: ./pcbit/capi.c:39: WARNING: Use #include instead of ./pcbit/capi.c:40: WARNING: Use #include instead of ./pcbit/callbacks.c:25: WARNING: Use #include instead of ./pcbit/layer2.c:39: WARNING: Use #include instead of ./pcbit/drv.c:34: WARNING: Use

Re: [PATCH] z3fold: fix the potential encode bug in encod_handle

On 2016/10/13 11:33, zhongjiang wrote: > From: zhong jiang > > At present, zhdr->first_num plus bud can exceed the BUDDY_MASK > in encode_handle, it will lead to the the caller handle_to_buddy > return the error value. > > The patch fix the issue by changing the BUDDY_MASK to PAGE_MASK, > it will

[PATCH] staging: i4l: pcbit: replace some include asm/*.h with linux/*.h

Fixes the following checkpatch output: ./pcbit/capi.c:39: WARNING: Use #include instead of ./pcbit/capi.c:40: WARNING: Use #include instead of ./pcbit/callbacks.c:25: WARNING: Use #include instead of ./pcbit/layer2.c:39: WARNING: Use #include instead of ./pcbit/drv.c:34: WARNING: Use

[PATCH] acer-wmi: setup accelerometer when machine has appropriate notify event

The accelerometer event relies on on the ACERWMID_EVENT_GUID notify. So, this patch changes the codes to setup accelerometer input device when detected ACERWMID_EVENT_GUID. It avoids that the accel input device created on every acer machines. In addition, patch adds a clearly parsing logic of

[PATCH] acer-wmi: setup accelerometer when machine has appropriate notify event

The accelerometer event relies on on the ACERWMID_EVENT_GUID notify. So, this patch changes the codes to setup accelerometer input device when detected ACERWMID_EVENT_GUID. It avoids that the accel input device created on every acer machines. In addition, patch adds a clearly parsing logic of

Re: [PATCH 1/3] mfd: cros_ec: Add EC console read structures definitions

On Wed, Aug 31, 2016 at 4:45 AM, Lee Jones wrote: > On Tue, 23 Aug 2016, Nicolas Boichat wrote: > >> ec_params_console_read_v1 is used to capture EC logs from kernel, >> and ec_params_get_cmd_versions_v1 is used to probe whether EC >> supports that command. >> >>

Re: [PATCH 1/3] mfd: cros_ec: Add EC console read structures definitions

On Wed, Aug 31, 2016 at 4:45 AM, Lee Jones wrote: > On Tue, 23 Aug 2016, Nicolas Boichat wrote: > >> ec_params_console_read_v1 is used to capture EC logs from kernel, >> and ec_params_get_cmd_versions_v1 is used to probe whether EC >> supports that command. >> >> Signed-off-by: Nicolas Boichat

[PATCH] acer-wmi: only supports AMW0_GUID1 on acer family

The AMW0_GUID1 wmi is not only found on Acer family but also other machines like Lenovo, Fujitsu and Medion. In the past days, acer-wmi driver handled those non-Acer machines by quirks list. But actually acer-wmi driver was loaded on any machines that have AMW0_GUID1. This behavior is strange

[PATCH] acer-wmi: only supports AMW0_GUID1 on acer family

The AMW0_GUID1 wmi is not only found on Acer family but also other machines like Lenovo, Fujitsu and Medion. In the past days, acer-wmi driver handled those non-Acer machines by quirks list. But actually acer-wmi driver was loaded on any machines that have AMW0_GUID1. This behavior is strange

[PATCH] z3fold: fix the potential encode bug in encod_handle

From: zhong jiang At present, zhdr->first_num plus bud can exceed the BUDDY_MASK in encode_handle, it will lead to the the caller handle_to_buddy return the error value. The patch fix the issue by changing the BUDDY_MASK to PAGE_MASK, it will be consistent with

[PATCH] z3fold: fix the potential encode bug in encod_handle

From: zhong jiang At present, zhdr->first_num plus bud can exceed the BUDDY_MASK in encode_handle, it will lead to the the caller handle_to_buddy return the error value. The patch fix the issue by changing the BUDDY_MASK to PAGE_MASK, it will be consistent with handle_to_z3fold_header. At the

Re: [PATCH] ext4: do not advertise encryption support when disabled

On Mon, Oct 10, 2016 at 12:05:31PM -0700, Eric Biggers wrote: > The sysfs file /sys/fs/ext4/features/encryption was present on kernels > compiled with CONFIG_EXT4_FS_ENCRYPTION=n. This was misleading because > such kernels do not actually support ext4 encryption. Therefore, only > provide this

Re: [PATCH] ext4: do not advertise encryption support when disabled

On Mon, Oct 10, 2016 at 12:05:31PM -0700, Eric Biggers wrote: > The sysfs file /sys/fs/ext4/features/encryption was present on kernels > compiled with CONFIG_EXT4_FS_ENCRYPTION=n. This was misleading because > such kernels do not actually support ext4 encryption. Therefore, only > provide this

Re: [PATCH 1/1] jbd2: fix incorrect unlock on j_list_lock

On Wed, Oct 12, 2016 at 04:58:35PM -0600, Andreas Dilger wrote: > On Mar 17, 2015, at 8:08 PM, Taesoo Kim wrote: > > > > When 'jh->b_transaction == transaction' (asserted by below) > > > > J_ASSERT_JH(jh, (jh->b_transaction == transaction || ... > > > >

Re: [PATCH 1/1] jbd2: fix incorrect unlock on j_list_lock

On Wed, Oct 12, 2016 at 04:58:35PM -0600, Andreas Dilger wrote: > On Mar 17, 2015, at 8:08 PM, Taesoo Kim wrote: > > > > When 'jh->b_transaction == transaction' (asserted by below) > > > > J_ASSERT_JH(jh, (jh->b_transaction == transaction || ... > > > > 'journal->j_list_lock' will be

Re: [PATCH] ext4: super.c: Update logging style using PR_CONT

Applied, thanks. - Ted

Re: [PATCH] ext4: super.c: Update logging style using PR_CONT

Applied, thanks. - Ted

Re: [PATCH 3.4 096/125] xen/pciback: Save xen_pci_op commands before processing it

On 2016/10/12 20:59, Konrad Rzeszutek Wilk wrote: > On Wed, Oct 12, 2016 at 08:33:32PM +0800, l...@kernel.org wrote: >> From: Konrad Rzeszutek Wilk >> >> 3.4.113-rc1 review patch. If anyone has any objections, please let me know. > > You also need: > > > commit

Re: [PATCH 3.4 096/125] xen/pciback: Save xen_pci_op commands before processing it

On 2016/10/12 20:59, Konrad Rzeszutek Wilk wrote: > On Wed, Oct 12, 2016 at 08:33:32PM +0800, l...@kernel.org wrote: >> From: Konrad Rzeszutek Wilk >> >> 3.4.113-rc1 review patch. If anyone has any objections, please let me know. > > You also need: > > > commit

[PATCH] usb: ohci-da8xx: Remove code that references mach

Including mach/* is frowned upon in device drivers, so get rid of it. This replaces usb20_clk and code that pokes CFGCHIP2 with a proper phy driver. Signed-off-by: David Lechner Acked-by: Alan Stern --- Greg, This is a resend of the last patch

[PATCH] usb: ohci-da8xx: Remove code that references mach

Including mach/* is frowned upon in device drivers, so get rid of it. This replaces usb20_clk and code that pokes CFGCHIP2 with a proper phy driver. Signed-off-by: David Lechner Acked-by: Alan Stern --- Greg, This is a resend of the last patch from the "[PATCH v6 0/3] da8xx USB PHY platform

Re: [PATCH 3.4 088/125] ser_gigaset: fix deallocation of platform device structure

On 2016/10/12 20:52, Paul Bolle wrote: > Zefan Li, > > On Wed, 2016-10-12 at 20:33 +0800, l...@kernel.org wrote: >> When shutting down the device, the struct ser_cardstate must not be >> kfree()d immediately after the call to platform_device_unregister() >> since the embedded struct

Re: [PATCH 3.4 088/125] ser_gigaset: fix deallocation of platform device structure

On 2016/10/12 20:52, Paul Bolle wrote: > Zefan Li, > > On Wed, 2016-10-12 at 20:33 +0800, l...@kernel.org wrote: >> When shutting down the device, the struct ser_cardstate must not be >> kfree()d immediately after the call to platform_device_unregister() >> since the embedded struct

[PATCH 07/10] mm: replace get_user_pages_remote() write/force parameters with gup_flags

This patch removes the write and force parameters from get_user_pages_remote() and replaces them with a gup_flags parameter to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo

[PATCH 07/10] mm: replace get_user_pages_remote() write/force parameters with gup_flags

This patch removes the write and force parameters from get_user_pages_remote() and replaces them with a gup_flags parameter to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo

Re: [PATCH 3.4 065/125] drm/ttm: Fixed a read/write lock imbalance

On 2016/10/12 21:04, Thomas Hellstrom wrote: > Li, > > IIRC This one goes hand in hand with a vmwgfx (the only user) patch. > Please don't apply until I've figured out whether that patch is also in 3.4. > I'll drop it for now. Thanks!

Re: [PATCH 3.4 081/125] mm, vmstat: allow WQ concurrency to discover memory reclaim doesn't make any progress

On 2016/10/12 21:29, Michal Hocko wrote: > On Wed 12-10-16 20:33:17, l...@kernel.org wrote: >> From: Michal Hocko >> >> 3.4.113-rc1 review patch. If anyone has any objections, please let me know. > > Do not forget to take the follow up fix 564e81a57f97 ("mm, vmstat: fix > wrong

Re: [PATCH 3.4 065/125] drm/ttm: Fixed a read/write lock imbalance

On 2016/10/12 21:04, Thomas Hellstrom wrote: > Li, > > IIRC This one goes hand in hand with a vmwgfx (the only user) patch. > Please don't apply until I've figured out whether that patch is also in 3.4. > I'll drop it for now. Thanks!

Re: [PATCH 3.4 081/125] mm, vmstat: allow WQ concurrency to discover memory reclaim doesn't make any progress

On 2016/10/12 21:29, Michal Hocko wrote: > On Wed 12-10-16 20:33:17, l...@kernel.org wrote: >> From: Michal Hocko >> >> 3.4.113-rc1 review patch. If anyone has any objections, please let me know. > > Do not forget to take the follow up fix 564e81a57f97 ("mm, vmstat: fix > wrong WQ sleep when

[PATCH v2] kvm: x86: remove the misleading comment in vmx_handle_external_intr

Since Paolo has removed irq-enable-operation in vmx_handle_external_intr (KVM: x86: use guest_exit_irqoff), the original comment about the IF bit in rflags is incorrect and stale now, so remove it. Signed-off-by: Longpeng(Mike) --- Hi Radim, Changes since v1: - remove

[PATCH v2] kvm: x86: remove the misleading comment in vmx_handle_external_intr

Since Paolo has removed irq-enable-operation in vmx_handle_external_intr (KVM: x86: use guest_exit_irqoff), the original comment about the IF bit in rflags is incorrect and stale now, so remove it. Signed-off-by: Longpeng(Mike) --- Hi Radim, Changes since v1: - remove this stale comment

linux-next: Tree for Oct 13

Hi all, Please do *not* add any v4.10 material to your linux-next included trees until v4.9-rc1 has been released i.e. the merge window closes. Changes since 20161012: The akpm-current tree still had its build failures for which I applied 2 patches. Non-merge commits (relative to Linus' tree

linux-next: Tree for Oct 13

Hi all, Please do *not* add any v4.10 material to your linux-next included trees until v4.9-rc1 has been released i.e. the merge window closes. Changes since 20161012: The akpm-current tree still had its build failures for which I applied 2 patches. Non-merge commits (relative to Linus' tree

Re: [RFC v2 1/2] sdhci: Add device tree property broken-highspeed

On 10/13/2016 03:40 AM, Zach Brown wrote: > Certain board configurations can make highspeed malfuction due to timing > issues. In these cases a way is needed to force the controller and card > into standard speed even if they otherwise appear to be capable of > highspeed. I'm not sure

Re: [RFC v2 1/2] sdhci: Add device tree property broken-highspeed

On 10/13/2016 03:40 AM, Zach Brown wrote: > Certain board configurations can make highspeed malfuction due to timing > issues. In these cases a way is needed to force the controller and card > into standard speed even if they otherwise appear to be capable of > highspeed. I'm not sure

[PATCH] perf jit: Fix build issue on Ubuntu

From: Anton Blanchard When building on Ubuntu 16.04, I get the following error: Makefile:49: *** the openjdk development package appears to me missing, install and try again. Stop. The problem is that update-java-alternatives has multiple spaces between fields, and cut

[PATCH] perf jit: Fix build issue on Ubuntu

From: Anton Blanchard When building on Ubuntu 16.04, I get the following error: Makefile:49: *** the openjdk development package appears to me missing, install and try again. Stop. The problem is that update-java-alternatives has multiple spaces between fields, and cut treats each space as a

Re: Question: Re: [PATCH] drm/bridge: analogix: protect power when get_modes or detect

On 2016年10月12日 22:51, Sean Paul wrote: On Wed, Oct 12, 2016 at 6:22 AM, Mark yao wrote: I'm not familiar with the analogix driver, maybe use a power reference count would better then direct power on/off analogix_dp. Does anyone has the idea to protect detect and

Re: Question: Re: [PATCH] drm/bridge: analogix: protect power when get_modes or detect

On 2016年10月12日 22:51, Sean Paul wrote: On Wed, Oct 12, 2016 at 6:22 AM, Mark yao wrote: I'm not familiar with the analogix driver, maybe use a power reference count would better then direct power on/off analogix_dp. Does anyone has the idea to protect detect and get_modes context? I'm not

Re: [RFC v2 PATCH] mm/percpu.c: fix panic triggered by BUG_ON() falsely

On 10/13/2016 05:41 AM, Andrew Morton wrote: > On Tue, 11 Oct 2016 22:00:28 +0800 zijun_hu wrote: > >> as shown by pcpu_build_alloc_info(), the number of units within a percpu >> group is educed by rounding up the number of CPUs within the group to >> @upa boundary, therefore,

Re: [RFC v2 PATCH] mm/percpu.c: fix panic triggered by BUG_ON() falsely

On 10/13/2016 05:41 AM, Andrew Morton wrote: > On Tue, 11 Oct 2016 22:00:28 +0800 zijun_hu wrote: > >> as shown by pcpu_build_alloc_info(), the number of units within a percpu >> group is educed by rounding up the number of CPUs within the group to >> @upa boundary, therefore, the number of CPUs

[PATCH v2] drm/bridge: analogix: protect power when get_modes or detect

The drm callback ->detect and ->get_modes seems is not power safe, they may be called when device is power off, do register access on detect or get_modes will cause system die. Here is the path call ->detect before analogix_dp power on [] analogix_dp_detect+0x44/0xdc []

[PATCH v2] drm/bridge: analogix: protect power when get_modes or detect

The drm callback ->detect and ->get_modes seems is not power safe, they may be called when device is power off, do register access on detect or get_modes will cause system die. Here is the path call ->detect before analogix_dp power on [] analogix_dp_detect+0x44/0xdc []

Re: [PATCH v7 2/8] power: add power sequence library

On Wed, Oct 12, 2016 at 12:30:29PM +0200, Heiko Stuebner wrote: > Hi, > > Am Dienstag, 20. September 2016, 11:36:41 CEST schrieb Peter Chen: > > We have an well-known problem that the device needs to do some power > > sequence before it can be recognized by related host, the typical > > example

Re: [PATCH v7 2/8] power: add power sequence library

On Wed, Oct 12, 2016 at 12:30:29PM +0200, Heiko Stuebner wrote: > Hi, > > Am Dienstag, 20. September 2016, 11:36:41 CEST schrieb Peter Chen: > > We have an well-known problem that the device needs to do some power > > sequence before it can be recognized by related host, the typical > > example

Re: [PATCH v6] net: ip, diag -- Add diag interface for raw sockets

From: Cyrill Gorcunov Date: Wed, 12 Oct 2016 09:53:29 +0300 > I can't rename the field, neither a can use union. Remind me again what is wrong with using an anonymous union?

Re: [PATCH v6] net: ip, diag -- Add diag interface for raw sockets

From: Cyrill Gorcunov Date: Wed, 12 Oct 2016 09:53:29 +0300 > I can't rename the field, neither a can use union. Remind me again what is wrong with using an anonymous union?

RE: [PATCH] xen-netback: fix type mismatch warning

> -Original Message- > From: Arnd Bergmann [mailto:a...@arndb.de] > Sent: 12 October 2016 10:54 > To: Wei Liu ; Paul Durrant > Cc: Arnd Bergmann ; David S. Miller > ; David Vrabel ;

RE: [PATCH] xen-netback: fix type mismatch warning

> -Original Message- > From: Arnd Bergmann [mailto:a...@arndb.de] > Sent: 12 October 2016 10:54 > To: Wei Liu ; Paul Durrant > Cc: Arnd Bergmann ; David S. Miller > ; David Vrabel ; xen- > de...@lists.xenproject.org; net...@vger.kernel.org; linux- > ker...@vger.kernel.org > Subject:

Re: [PATCH] sc16is7xx: Drop bogus use of IRQF_ONESHOT

On Mon, 3 Oct 2016 10:14:32 -0500, Julia Cartwright wrote: > The use of IRQF_ONESHOT when registering an interrupt handler with > request_irq() is non-sensical. > ... Disabling the irq when kthread is pending as mentioned here: http://www.spinics.net/lists/linux-rt-users/msg14673.html could be

Re: [PATCH] sc16is7xx: Drop bogus use of IRQF_ONESHOT

On Mon, 3 Oct 2016 10:14:32 -0500, Julia Cartwright wrote: > The use of IRQF_ONESHOT when registering an interrupt handler with > request_irq() is non-sensical. > ... Disabling the irq when kthread is pending as mentioned here: http://www.spinics.net/lists/linux-rt-users/msg14673.html could be

Re: [PATCH 3.4 000/125] 3.4.113-rc1 review

On 2016/10/13 0:56, Guenter Roeck wrote: > On Wed, Oct 12, 2016 at 08:33:20PM +0800, l...@kernel.org wrote: >> From: Zefan Li >> >> This is the start of the stable review cycle for the 3.4.113 release. >> There are 125 patches in this series, all will be posted as a response

Re: [PATCH 3.4 000/125] 3.4.113-rc1 review

On 2016/10/13 0:56, Guenter Roeck wrote: > On Wed, Oct 12, 2016 at 08:33:20PM +0800, l...@kernel.org wrote: >> From: Zefan Li >> >> This is the start of the stable review cycle for the 3.4.113 release. >> There are 125 patches in this series, all will be posted as a response >> to this one. If

Re: [PATCH 3.4 007/125] recordmcount: Fix endianness handling bug for nop_mcount

On 2016/10/12 21:10, Steven Rostedt wrote: > Hi Li, > > What is your plan for EOL of 3.4? I see on kernel.org that the EOL of > 3.4 was suppose to be September 2016 (which has passed). I just gave a > talk yesterday saying it is no longer supported. But I appear to be > mistaken. > I think I'll

Re: [PATCH 3.4 007/125] recordmcount: Fix endianness handling bug for nop_mcount

On 2016/10/12 21:10, Steven Rostedt wrote: > Hi Li, > > What is your plan for EOL of 3.4? I see on kernel.org that the EOL of > 3.4 was suppose to be September 2016 (which has passed). I just gave a > talk yesterday saying it is no longer supported. But I appear to be > mistaken. > I think I'll

Re: [GIT pull] locking fix for 4.9

On Wed, 12 Oct 2016 10:22:59 -0700 Linus Torvalds wrote: > On Wed, Oct 12, 2016 at 1:28 AM, Steven Rostedt wrote: > > > > But I agree. We have lived a long time without the need for this > > warning. I'm not strongly advocating keeping the

Re: [GIT pull] locking fix for 4.9

On Wed, 12 Oct 2016 10:22:59 -0700 Linus Torvalds wrote: > On Wed, Oct 12, 2016 at 1:28 AM, Steven Rostedt wrote: > > > > But I agree. We have lived a long time without the need for this > > warning. I'm not strongly advocating keeping the warning around and > > just disabling it totally. But

Re: [PATCH/RFT 07/12] USB: ohci-da8xx: Request gpios and handle interrupt in the driver

On 10/12/2016 10:01 AM, Axel Haslam wrote: I agree that we should use a regulator for the vbus power. i will make that change. However, im not so sure about using the regulator for the overcurrent handling. There seems to be no other driver doing this, and as you mention, we would need to

Re: [PATCH/RFT 07/12] USB: ohci-da8xx: Request gpios and handle interrupt in the driver

On 10/12/2016 10:01 AM, Axel Haslam wrote: I agree that we should use a regulator for the vbus power. i will make that change. However, im not so sure about using the regulator for the overcurrent handling. There seems to be no other driver doing this, and as you mention, we would need to

  1   2   3   4   5   6   7   8   9   10   >