[GIT PULL] extcon next for v4.12

Dear Greg, This is extcon-next pull request for v4.12. I add detailed description of this pull request on below. Please pull extcon with following updates. Best Regards, Chanwoo Choi The following changes since commit c02ed2e75ef4c74e41e421acb4ef1494671585e8: Linux 4.11-rc4 (2017-03-26

[GIT PULL] extcon next for v4.12

Dear Greg, This is extcon-next pull request for v4.12. I add detailed description of this pull request on below. Please pull extcon with following updates. Best Regards, Chanwoo Choi The following changes since commit c02ed2e75ef4c74e41e421acb4ef1494671585e8: Linux 4.11-rc4 (2017-03-26

Re: [PATCH] cpufreq: imx6q: Fix error handling code

On 09-04-17, 09:33, Christophe JAILLET wrote: > According to the previous error handling code, it is likely that > 'goto out_free_opp' is expected here in order to avoid a memory leak in > error handling path. > > Signed-off-by: Christophe JAILLET > --- >

Re: [PATCH] cpufreq: imx6q: Fix error handling code

On 09-04-17, 09:33, Christophe JAILLET wrote: > According to the previous error handling code, it is likely that > 'goto out_free_opp' is expected here in order to avoid a memory leak in > error handling path. > > Signed-off-by: Christophe JAILLET > --- > drivers/cpufreq/imx6q-cpufreq.c | 2 +-

Re: [PATCH v4 2/3] Broadcom USB DRD Phy driver for Northstar2

Hi, On Wednesday 05 April 2017 07:40 PM, Raviteja Garimella wrote: > Hi Kishon, > > On Wed, Apr 5, 2017 at 7:04 PM, Kishon Vijay Abraham I wrote: >> Hi Ravi, >> >> On Wednesday 05 April 2017 06:30 PM, Raviteja Garimella wrote: >>> Hi Kishon, >>> >>> On Wed, Apr 5, 2017 at 4:30

Re: [PATCH v4 2/3] Broadcom USB DRD Phy driver for Northstar2

Hi, On Wednesday 05 April 2017 07:40 PM, Raviteja Garimella wrote: > Hi Kishon, > > On Wed, Apr 5, 2017 at 7:04 PM, Kishon Vijay Abraham I wrote: >> Hi Ravi, >> >> On Wednesday 05 April 2017 06:30 PM, Raviteja Garimella wrote: >>> Hi Kishon, >>> >>> On Wed, Apr 5, 2017 at 4:30 PM, Kishon Vijay

Re: [PATCH] phy: qcom-qmp: Add dependency on COMMON_CLK

On Friday 07 April 2017 01:37 AM, Vivek Gautam wrote: > The driver uses clock provider interface, and therefore > it fails to build when enabled for COMPILE_TEST, since > COMMON_CLK is not enabled at that time. > So, make PHY_QCOM_QMP depend on COMMON_CLK as well. > > Cc: Fengguang Wu

Re: [PATCH] phy: qcom-qmp: Add dependency on COMMON_CLK

On Friday 07 April 2017 01:37 AM, Vivek Gautam wrote: > The driver uses clock provider interface, and therefore > it fails to build when enabled for COMPILE_TEST, since > COMMON_CLK is not enabled at that time. > So, make PHY_QCOM_QMP depend on COMMON_CLK as well. > > Cc: Fengguang Wu > Cc:

Re: [PATCH 0/2] drm: dw-hdmi: various improvements

Hi, On 04/07/2017 07:49 PM, Romain Perier wrote: This set of patches split the stream handling functions in two parts. It introduces new callbacks that are specific to each variant, one for I2S and one for AHB. Then, as requested by the datasheet for the I2S variant, it adds support for gating

Re: [PATCH 0/2] drm: dw-hdmi: various improvements

Hi, On 04/07/2017 07:49 PM, Romain Perier wrote: This set of patches split the stream handling functions in two parts. It introduces new callbacks that are specific to each variant, one for I2S and one for AHB. Then, as requested by the datasheet for the I2S variant, it adds support for gating

[PATCH] PM / OPP: Use - instead of @ for DT entries

Compiling the DT file with W=1, DTC warns like follows: Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a unit name, but no reg property Fix this by replacing '@' with '-' as the OPP nodes will never have a "reg" property. Reported-by: Masahiro Yamada

[PATCH] PM / OPP: Use - instead of @ for DT entries

Compiling the DT file with W=1, DTC warns like follows: Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a unit name, but no reg property Fix this by replacing '@' with '-' as the OPP nodes will never have a "reg" property. Reported-by: Masahiro Yamada Signed-off-by: Viresh

Re: [PATCH 2/4] drm: Add drm_object lease infrastructure

On 03/04/17 01:31 AM, Keith Packard wrote: > Daniel Vetter writes: > >> I'm also not sure whether we really want sub-leases in v1, that's easy >> to add later on, but for now just complicates stuff. Main compositor >> should be a full master, VR can be the first lease level, we

Re: [PATCH 2/4] drm: Add drm_object lease infrastructure

On 03/04/17 01:31 AM, Keith Packard wrote: > Daniel Vetter writes: > >> I'm also not sure whether we really want sub-leases in v1, that's easy >> to add later on, but for now just complicates stuff. Main compositor >> should be a full master, VR can be the first lease level, we don't >> need

linux-next: build failure after merge of the staging tree

Hi Greg, After merging the staging tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/staging/rtl8723bs/core/rtw_ieee80211.c: In function 'rtw_macaddr_cfg': drivers/staging/rtl8723bs/core/rtw_ieee80211.c:1193:22: error: implicit declaration of function

linux-next: build failure after merge of the staging tree

Hi Greg, After merging the staging tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/staging/rtl8723bs/core/rtw_ieee80211.c: In function 'rtw_macaddr_cfg': drivers/staging/rtl8723bs/core/rtw_ieee80211.c:1193:22: error: implicit declaration of function

Re: [PATCH] phy: qcom-qmp: select COMMON_CLK

Hi, On Monday 10 April 2017 02:45 AM, Jérémy Lefaure wrote: > It is impossible to build Qualcom QMP phy driver without COMMON_CLK > enabled: > CC drivers/phy/phy-qcom-qmp.o > drivers/phy/phy-qcom-qmp.c: In function ‘phy_pipe_clk_register’: > drivers/phy/phy-qcom-qmp.c:932:9: error:

Re: [PATCH] phy: qcom-qmp: select COMMON_CLK

Hi, On Monday 10 April 2017 02:45 AM, Jérémy Lefaure wrote: > It is impossible to build Qualcom QMP phy driver without COMMON_CLK > enabled: > CC drivers/phy/phy-qcom-qmp.o > drivers/phy/phy-qcom-qmp.c: In function ‘phy_pipe_clk_register’: > drivers/phy/phy-qcom-qmp.c:932:9: error:

Re: Recommended notation for OPP to avoid DTC warnings

On 31-03-17, 11:59, Masahiro Yamada wrote: > Hi. > > 2017-02-27 19:55 GMT+09:00 Viresh Kumar : > > On 27-02-17, 10:44, Mark Rutland wrote: > >> On Sun, Feb 26, 2017 at 02:18:03PM +0900, Masahiro Yamada wrote: > >> > Hi. > >> > > >> > > >> >

Re: Recommended notation for OPP to avoid DTC warnings

On 31-03-17, 11:59, Masahiro Yamada wrote: > Hi. > > 2017-02-27 19:55 GMT+09:00 Viresh Kumar : > > On 27-02-17, 10:44, Mark Rutland wrote: > >> On Sun, Feb 26, 2017 at 02:18:03PM +0900, Masahiro Yamada wrote: > >> > Hi. > >> > > >> > > >> > Decumentation/devicetree/bindings/opp/opp.txt > >> >

Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage

On (04/09/17 12:12), Pavel Machek wrote: [..] > > a side note, > > that's rather unclear to me how would "message delayed" really help. > > if your system hard-lockup so badly and there are no printk messages > > even from NMI watchdog, then we won't be able to print that message. > > We are

Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage

On (04/09/17 12:12), Pavel Machek wrote: [..] > > a side note, > > that's rather unclear to me how would "message delayed" really help. > > if your system hard-lockup so badly and there are no printk messages > > even from NMI watchdog, then we won't be able to print that message. > > We are

Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage

Hello Eric, On (04/09/17 13:21), Eric W. Biederman wrote: [..] > It sounds like you are blaming printk when the problem is a very slow > logging device. sure, slow logging device definitely adds up to the problem. if there is no delay in call_console_driver() then printk()->console_unlock() take

Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage

Hello Eric, On (04/09/17 13:21), Eric W. Biederman wrote: [..] > It sounds like you are blaming printk when the problem is a very slow > logging device. sure, slow logging device definitely adds up to the problem. if there is no delay in call_console_driver() then printk()->console_unlock() take

Re: [greybus-dev] [PATCH] staging: greybus: compress return logic

On 25-03-17, 10:50, Arushi Singhal wrote: > Simplify function returns by merging assignment and return. > > Signed-off-by: Arushi Singhal > --- > drivers/staging/greybus/loopback.c | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git

Re: [greybus-dev] [PATCH] staging: greybus: compress return logic

On 25-03-17, 10:50, Arushi Singhal wrote: > Simplify function returns by merging assignment and return. > > Signed-off-by: Arushi Singhal > --- > drivers/staging/greybus/loopback.c | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/drivers/staging/greybus/loopback.c

Re: [PATCH 3/4] drm: Check mode object lease status in all master ioctl paths

Daniel Vetter writes: > I think it'd be good if we could consolidate all the lease checking into > drm_mode_object_find (respectively __drm_mode_object_find). We'd need to > wire up the fpriv to be able to do that, but we could upstream that patch > right away before anything

Re: [PATCH 3/4] drm: Check mode object lease status in all master ioctl paths

Daniel Vetter writes: > I think it'd be good if we could consolidate all the lease checking into > drm_mode_object_find (respectively __drm_mode_object_find). We'd need to > wire up the fpriv to be able to do that, but we could upstream that patch > right away before anything else. That should

[PATCH] drivers/staging/iio: braces {} are not necessary for single statement blocks

Handling checkpatch.pl warning for if block. For single if statement block, braces are not neccessary. Making code consistent with linux kernel coding guidelines. Signed-off-by: Pushkar Jambhlekar --- drivers/staging/iio/accel/adis16203.c | 4 ++-- 1 file changed, 2

[PATCH] drivers/staging/iio: braces {} are not necessary for single statement blocks

Handling checkpatch.pl warning for if block. For single if statement block, braces are not neccessary. Making code consistent with linux kernel coding guidelines. Signed-off-by: Pushkar Jambhlekar --- drivers/staging/iio/accel/adis16203.c | 4 ++-- 1 file changed, 2 insertions(+), 2

Re: [HMM 14/16] mm/hmm/devmem: device memory hotplug using ZONE_DEVICE

On Fri, 2017-04-07 at 12:26 -0400, Jerome Glisse wrote: > On Thu, Apr 06, 2017 at 10:02:55PM -0400, Jerome Glisse wrote: > > On Fri, Apr 07, 2017 at 11:37:34AM +1000, Balbir Singh wrote: > > > On Wed, 2017-04-05 at 16:40 -0400, Jérôme Glisse wrote: > > > > This introduce a simple struct and

Re: [RFC] x86/tboot: add an option to disable iommu force on

On Fri, Apr 07, 2017 at 09:49:52PM +, Sun, Ning wrote: > Hi Shaohua, > > One question, did you still see the network performance penalty when Linux > kernel cmdline intel_iommu was set to off ( intel_iommu=off) ? the boot parameter has no effect, it runs very early and set dmar_disable=1.

Re: [HMM 14/16] mm/hmm/devmem: device memory hotplug using ZONE_DEVICE

On Fri, 2017-04-07 at 12:26 -0400, Jerome Glisse wrote: > On Thu, Apr 06, 2017 at 10:02:55PM -0400, Jerome Glisse wrote: > > On Fri, Apr 07, 2017 at 11:37:34AM +1000, Balbir Singh wrote: > > > On Wed, 2017-04-05 at 16:40 -0400, Jérôme Glisse wrote: > > > > This introduce a simple struct and

Re: [RFC] x86/tboot: add an option to disable iommu force on

On Fri, Apr 07, 2017 at 09:49:52PM +, Sun, Ning wrote: > Hi Shaohua, > > One question, did you still see the network performance penalty when Linux > kernel cmdline intel_iommu was set to off ( intel_iommu=off) ? the boot parameter has no effect, it runs very early and set dmar_disable=1.

[PATCHv3] phy: cpcap-usb: Add CPCAP PMIC USB support

Some Motorola phones like droid 4 use a custom CPCAP PMIC that has a multiplexing USB PHY. This USB PHY can operate at least in four modes using pin multiplexing and two control GPIOS: - Pass through companion PHY for the SoC USB PHY - ULPI PHY for the SoC - Pass through USB for the modem - UART

[PATCHv3] phy: cpcap-usb: Add CPCAP PMIC USB support

Some Motorola phones like droid 4 use a custom CPCAP PMIC that has a multiplexing USB PHY. This USB PHY can operate at least in four modes using pin multiplexing and two control GPIOS: - Pass through companion PHY for the SoC USB PHY - ULPI PHY for the SoC - Pass through USB for the modem - UART

linux-next: manual merge of the kvms390 tree with the kvm, kvm-arm and kvm-ppc trees

Hi all, Today's linux-next merge of the kvms390 tree got a conflict in: include/uapi/linux/kvm.h between commits: a8a3c426772e ("KVM: MIPS: Add VZ & TE capabilities") 578fd61d2d21 ("KVM: MIPS: Add 64BIT capability") 3fe17e682616 ("KVM: arm/arm64: Add ARM user space interrupt signaling

linux-next: manual merge of the kvms390 tree with the kvm, kvm-arm and kvm-ppc trees

Hi all, Today's linux-next merge of the kvms390 tree got a conflict in: include/uapi/linux/kvm.h between commits: a8a3c426772e ("KVM: MIPS: Add VZ & TE capabilities") 578fd61d2d21 ("KVM: MIPS: Add 64BIT capability") 3fe17e682616 ("KVM: arm/arm64: Add ARM user space interrupt signaling

Re: [RFC PATCH 4/4] dt-bindings: Add support for devices with multiple PM domains

On 03/28/2017 07:44 PM, Jon Hunter wrote: > Now that the generic PM domain framework supports consumers that can > control multiple PM domains, update the device-tree binding for generic > PM domains to state that one or more PM domain is permitted for a > device. > > Signed-off-by: Jon Hunter

Re: [RFC PATCH 4/4] dt-bindings: Add support for devices with multiple PM domains

On 03/28/2017 07:44 PM, Jon Hunter wrote: > Now that the generic PM domain framework supports consumers that can > control multiple PM domains, update the device-tree binding for generic > PM domains to state that one or more PM domain is permitted for a > device. > > Signed-off-by: Jon Hunter

linux-next: manual merge of the kvm-ppc tree with the kvm and kvm-arm trees

Hi Paul, Today's linux-next merge of the kvm-ppc tree got a conflict in: include/uapi/linux/kvm.h between commits: a8a3c426772e ("KVM: MIPS: Add VZ & TE capabilities") 578fd61d2d21 ("KVM: MIPS: Add 64BIT capability") 3fe17e682616 ("KVM: arm/arm64: Add ARM user space interrupt signaling

linux-next: manual merge of the kvm-ppc tree with the kvm and kvm-arm trees

Hi Paul, Today's linux-next merge of the kvm-ppc tree got a conflict in: include/uapi/linux/kvm.h between commits: a8a3c426772e ("KVM: MIPS: Add VZ & TE capabilities") 578fd61d2d21 ("KVM: MIPS: Add 64BIT capability") 3fe17e682616 ("KVM: arm/arm64: Add ARM user space interrupt signaling

Re: [RFC PATCH 2/4] PM / Domains: Add support for explicit control of PM domains

Hey Jon, On 03/28/2017 07:44 PM, Jon Hunter wrote: > The current generic PM domain framework (GenDP) only allows a single > PM domain to be associated with a given device. There are several > use-cases for various system-on-chip devices where it is necessary for > a PM domain consumer to control

Re: [RFC PATCH 2/4] PM / Domains: Add support for explicit control of PM domains

Hey Jon, On 03/28/2017 07:44 PM, Jon Hunter wrote: > The current generic PM domain framework (GenDP) only allows a single > PM domain to be associated with a given device. There are several > use-cases for various system-on-chip devices where it is necessary for > a PM domain consumer to control

[PATCH v3 2/2] drivers/serial: Add driver for Aspeed virtual UART

From: Jeremy Kerr This change adds a driver for the 16550-based Aspeed virtual UART device. We use a similar process to the of_serial driver for device probe, but expose some VUART-specific functions through sysfs too. The VUART is two UART 'front ends' connected by their FIFO

[PATCH v3 2/2] drivers/serial: Add driver for Aspeed virtual UART

From: Jeremy Kerr This change adds a driver for the 16550-based Aspeed virtual UART device. We use a similar process to the of_serial driver for device probe, but expose some VUART-specific functions through sysfs too. The VUART is two UART 'front ends' connected by their FIFO (no actual serial

[PATCH v3 0/2] drivers: serial: Aspeed VUART driver

This is v3 of a driver for the Aspeed VUART. This version addresses feedback from Andy and Greg, and includes Rob's ack for the bindings change. The VUART is a serial device on the BMC side of the LPC bus that connects a BMC to it's host processor. We add a flag to the serial core to allow the

[PATCH v3 0/2] drivers: serial: Aspeed VUART driver

This is v3 of a driver for the Aspeed VUART. This version addresses feedback from Andy and Greg, and includes Rob's ack for the bindings change. The VUART is a serial device on the BMC side of the LPC bus that connects a BMC to it's host processor. We add a flag to the serial core to allow the

[PATCH v3 1/2] serial: 8250: Add flag so drivers can avoid THRE probe

The probing of THRE irq behaviour assumes the other end will be reading bytes out of the buffer in order to probe the port at driver init. In some cases the other end cannot be relied upon to read these bytes, so provide a flag for them to skip this step. Bit 19 was chosen as the flags are a int

[PATCH v3 1/2] serial: 8250: Add flag so drivers can avoid THRE probe

The probing of THRE irq behaviour assumes the other end will be reading bytes out of the buffer in order to probe the port at driver init. In some cases the other end cannot be relied upon to read these bytes, so provide a flag for them to skip this step. Bit 19 was chosen as the flags are a int

linux-next: manual merge of the kvm-arm tree with Linus' tree

Hi all, Today's linux-next merge of the kvm-arm tree got conflicts in: virt/kvm/arm/vgic/vgic-v2.c virt/kvm/arm/vgic/vgic.h between commit: 5b0d2cc28058 ("KVM: arm64: Ensure LRs are clear when they should be") from Linus' tree and commits: 328e56647944 ("KVM: arm/arm64: vgic: Defer

linux-next: manual merge of the kvm-arm tree with Linus' tree

Hi all, Today's linux-next merge of the kvm-arm tree got conflicts in: virt/kvm/arm/vgic/vgic-v2.c virt/kvm/arm/vgic/vgic.h between commit: 5b0d2cc28058 ("KVM: arm64: Ensure LRs are clear when they should be") from Linus' tree and commits: 328e56647944 ("KVM: arm/arm64: vgic: Defer

[PATCH v3 1/2] serial: 8250: Add flag so drivers can avoid THRE probe

The probing of THRE irq behaviour assumes the other end will be reading bytes out of the buffer in order to probe the port at driver init. In some cases the other end cannot be relied upon to read these bytes, so provide a flag for them to skip this step. Bit 19 was chosen as the flags are a int

[PATCH v3 1/2] serial: 8250: Add flag so drivers can avoid THRE probe

The probing of THRE irq behaviour assumes the other end will be reading bytes out of the buffer in order to probe the port at driver init. In some cases the other end cannot be relied upon to read these bytes, so provide a flag for them to skip this step. Bit 19 was chosen as the flags are a int

[PATCH v3 0/2] drivers: serial: Aspeed VUART driver

This is v3 of a driver for the Aspeed VUART. This version addresses feedback from Andy and Greg, and includes Rob's ack for the bindings change. The VUART is a serial device on the BMC side of the LPC bus that connects a BMC to it's host processor. We add a flag to the serial core to allow the

[PATCH v3 0/2] drivers: serial: Aspeed VUART driver

This is v3 of a driver for the Aspeed VUART. This version addresses feedback from Andy and Greg, and includes Rob's ack for the bindings change. The VUART is a serial device on the BMC side of the LPC bus that connects a BMC to it's host processor. We add a flag to the serial core to allow the

linux-next: manual merge of the kvm-arm tree with the kvm tree

Hi all, Today's linux-next merge of the kvm-arm tree got conflicts in: Documentation/virtual/kvm/api.txt include/uapi/linux/kvm.h between commits: a8a3c426772e ("KVM: MIPS: Add VZ & TE capabilities") 578fd61d2d21 ("KVM: MIPS: Add 64BIT capability") from the kvm tree and commit:

linux-next: manual merge of the kvm-arm tree with the kvm tree

Hi all, Today's linux-next merge of the kvm-arm tree got conflicts in: Documentation/virtual/kvm/api.txt include/uapi/linux/kvm.h between commits: a8a3c426772e ("KVM: MIPS: Add VZ & TE capabilities") 578fd61d2d21 ("KVM: MIPS: Add 64BIT capability") from the kvm tree and commit:

[PATCH v3] arm64: dts: rk3399: add support for firefly-rk3399 board

Firefly-rk3399 is a bord from T-Firefly, you can find detail about it here: http://en.t-firefly.com/en/firenow/Firefly_RK3399/ This patch add basic node for the board and make it able to bring up. Peripheral works: - usb hub which connect to ehci controller; - UART2 debug - eMMC - PCIe Not

[PATCH v3] arm64: dts: rk3399: add support for firefly-rk3399 board

Firefly-rk3399 is a bord from T-Firefly, you can find detail about it here: http://en.t-firefly.com/en/firenow/Firefly_RK3399/ This patch add basic node for the board and make it able to bring up. Peripheral works: - usb hub which connect to ehci controller; - UART2 debug - eMMC - PCIe Not

Re: WARNING: at arch/x86/kernel/cpu/perf_event_intel_cqm.c:186 __put_rmid+0x28/0x80()

On 2017/3/2 14:55, Xishi Qiu wrote: ping > Hi, I test Trinity, and got the following log. > My OS version is RHEL 7.2, I'm not sure if it has fixed in mainline. > Any comment is welcome. > > [57676.532593] [ cut here ] > [57676.537415] WARNING: at

Re: WARNING: at arch/x86/kernel/cpu/perf_event_intel_cqm.c:186 __put_rmid+0x28/0x80()

On 2017/3/2 14:55, Xishi Qiu wrote: ping > Hi, I test Trinity, and got the following log. > My OS version is RHEL 7.2, I'm not sure if it has fixed in mainline. > Any comment is welcome. > > [57676.532593] [ cut here ] > [57676.537415] WARNING: at

Re: [PATCH v2 1/2] arm64: dts: rk3399: add support for firefly-rk3399 board

Hi Heiko, On 04/08/2017 07:01 AM, Heiko Stuebner wrote: Hi Kever, Am Mittwoch, 5. April 2017, 17:33:19 CEST schrieb Kever Yang: Firefly-rk3399 is a bord from T-Firefly, you can find detail about it here: http://en.t-firefly.com/en/firenow/Firefly_RK3399/ This patch add basic node for the

Re: [PATCH v2 1/2] arm64: dts: rk3399: add support for firefly-rk3399 board

Hi Heiko, On 04/08/2017 07:01 AM, Heiko Stuebner wrote: Hi Kever, Am Mittwoch, 5. April 2017, 17:33:19 CEST schrieb Kever Yang: Firefly-rk3399 is a bord from T-Firefly, you can find detail about it here: http://en.t-firefly.com/en/firenow/Firefly_RK3399/ This patch add basic node for the

linux-next: manual merge of the clockevents tree with the arm-soc tree

Hi Daniel, Today's linux-next merge of the clockevents tree got a conflict in: arch/arm/boot/dts/rk3188.dtsi between commit: 2e1aa605fadd ("ARM: dts: rockchip: fix PPI misconfiguration on Cortex-A9 socs") from the arm-soc tree and commit: 500d0aa918a2 ("ARM: dts: rockchip: disable

linux-next: manual merge of the clockevents tree with the arm-soc tree

Hi Daniel, Today's linux-next merge of the clockevents tree got a conflict in: arch/arm/boot/dts/rk3188.dtsi between commit: 2e1aa605fadd ("ARM: dts: rockchip: fix PPI misconfiguration on Cortex-A9 socs") from the arm-soc tree and commit: 500d0aa918a2 ("ARM: dts: rockchip: disable

Re: [PATCH] Documentation: vm, add hugetlbfs reservation overview

On April 08, 2017 1:43 AM Mike Kravetz wrote: > > Adding a brief overview of hugetlbfs reservation design and implementation > as an aid to those making code modifications in this area. > > Signed-off-by: Mike Kravetz > --- You are doing more than I can double thank

Re: [PATCH] Documentation: vm, add hugetlbfs reservation overview

On April 08, 2017 1:43 AM Mike Kravetz wrote: > > Adding a brief overview of hugetlbfs reservation design and implementation > as an aid to those making code modifications in this area. > > Signed-off-by: Mike Kravetz > --- You are doing more than I can double thank you, Mike:) Acked-by:

Re: [PATCH v2 2/2] drivers/serial: Add driver for Aspeed virtual UART

On Wed, Apr 5, 2017 at 8:24 PM, Andy Shevchenko wrote: > On Wed, Apr 5, 2017 at 7:03 AM, Joel Stanley wrote: > >> + port.port.irq = irq_of_parse_and_map(np, 0); > > Isn't better to get this via platform_get_irq() ? I can't see the benefit. > >>

Re: [PATCH v2 2/2] drivers/serial: Add driver for Aspeed virtual UART

On Wed, Apr 5, 2017 at 8:24 PM, Andy Shevchenko wrote: > On Wed, Apr 5, 2017 at 7:03 AM, Joel Stanley wrote: > >> + port.port.irq = irq_of_parse_and_map(np, 0); > > Isn't better to get this via platform_get_irq() ? I can't see the benefit. > >> + port.port.irqflags = IRQF_SHARED;

[PATCH v4 0/1] fix perf build issue when ARCH=x86_64

From: Jiada Wang Changes from v4: update changlog to describe the reason of build failure replace ARCH with SRCARCH in pmu-events/Build and util/header.c Changes from v3: replace ARCH with SRCARCH in perf Changes from v2: added function purify-arch, transforms both

[PATCH v4 1/1] perf tools: fix perf build with ARCH=x86_64

From: Jiada Wang with commit: 0a943cb10ce78 (tools build: Add HOSTARCH Makefile variable) when build for ARCH=x86_64, ARCH=x86_64 is passed to perf instead of ARCH=x86, so perf package searchs header files from tools/arch/x86_64/include, which doesn't exist. the following

[PATCH v4 0/1] fix perf build issue when ARCH=x86_64

From: Jiada Wang Changes from v4: update changlog to describe the reason of build failure replace ARCH with SRCARCH in pmu-events/Build and util/header.c Changes from v3: replace ARCH with SRCARCH in perf Changes from v2: added function purify-arch, transforms both HOSTARCH and ARCH to

[PATCH v4 1/1] perf tools: fix perf build with ARCH=x86_64

From: Jiada Wang with commit: 0a943cb10ce78 (tools build: Add HOSTARCH Makefile variable) when build for ARCH=x86_64, ARCH=x86_64 is passed to perf instead of ARCH=x86, so perf package searchs header files from tools/arch/x86_64/include, which doesn't exist. the following build failure is seen

Re: [PATCH] Staging: comedidev.h comedi_lrange should be const struct

/Staging-comedidev-h-comedi_lrange-should-be-const-struct/20170409-224503 config: x86_64-allmodconfig compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: make ARCH=x86_64 allmodconfig make ARCH=x86_64 All warnings (new ones prefixed by >>): vim +629 drivers/staging/

Re: [PATCH] Staging: comedidev.h comedi_lrange should be const struct

/Staging-comedidev-h-comedi_lrange-should-be-const-struct/20170409-224503 config: x86_64-allmodconfig compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: make ARCH=x86_64 allmodconfig make ARCH=x86_64 All warnings (new ones prefixed by >>): vim +629 drivers/staging/

Re: [PATCH v3 1/1] perf tools: fix perf build with ARCH=x86_64

Hello Jiri On 04/09/2017 10:27 AM, Jiri Olsa wrote: On Tue, Apr 04, 2017 at 11:25:44PM -0700, jiada_w...@mentor.com wrote: From: Jiada Wang with commit: 0a943cb10ce78 (tools build: Add HOSTARCH Makefile variable) the following build failure is seen when build with

Re: [PATCH v3 1/1] perf tools: fix perf build with ARCH=x86_64

Hello Jiri On 04/09/2017 10:27 AM, Jiri Olsa wrote: On Tue, Apr 04, 2017 at 11:25:44PM -0700, jiada_w...@mentor.com wrote: From: Jiada Wang with commit: 0a943cb10ce78 (tools build: Add HOSTARCH Makefile variable) the following build failure is seen when build with ARCH=x86_64 is that

RE: [PATCH v4 0/9] Renesas RZ/A1 pin and gpio controller

Hi Jacopo, On Wednesday, April 05, 2017, Jacopo Mondi wrote: > v3 -> v4: > - use "pinmux" property in pmx sub-nodes in place of "renesas,pins" > - use pinconf standard properties to set pin mux additional flags > - add "bi-directional" and "output-enable" to pinconf generic properties > - perform

RE: [PATCH v4 0/9] Renesas RZ/A1 pin and gpio controller

Hi Jacopo, On Wednesday, April 05, 2017, Jacopo Mondi wrote: > v3 -> v4: > - use "pinmux" property in pmx sub-nodes in place of "renesas,pins" > - use pinconf standard properties to set pin mux additional flags > - add "bi-directional" and "output-enable" to pinconf generic properties > - perform

Re: [patch 1/3] mm: protect set_page_dirty() from ongoing truncation

On Fri, Dec 05, 2014 at 09:52:44AM -0500, Johannes Weiner wrote: > Tejun, while reviewing the code, spotted the following race condition > between the dirtying and truncation of a page: > > __set_page_dirty_nobuffers() __delete_from_page_cache() > if (TestSetPageDirty(page)) >

Re: [patch 1/3] mm: protect set_page_dirty() from ongoing truncation

On Fri, Dec 05, 2014 at 09:52:44AM -0500, Johannes Weiner wrote: > Tejun, while reviewing the code, spotted the following race condition > between the dirtying and truncation of a page: > > __set_page_dirty_nobuffers() __delete_from_page_cache() > if (TestSetPageDirty(page)) >

[PATCH] NFS: fix usage of mempools.

When passed GFP flags that allow sleeping (such as GFP_NOIO), mempool_alloc() will never return NULL, it will wait until memory is available. This means that we don't need to handle failure, but that we do need to ensure one thread doesn't call mempool_alloc() twice on the one pool without

[PATCH] NFS: fix usage of mempools.

When passed GFP flags that allow sleeping (such as GFP_NOIO), mempool_alloc() will never return NULL, it will wait until memory is available. This means that we don't need to handle failure, but that we do need to ensure one thread doesn't call mempool_alloc() twice on the one pool without

[PATCH] sunrpc: don't check for failure from mempool_alloc()

When mempool_alloc() is allowed to sleep (GFP_NOIO allows sleeping) it cannot fail. So rpc_alloc_task() cannot fail, so rpc_new_task doesn't need to test for failure. Consequently rpc_new_task() cannot fail, so the callers don't need to test. Signed-off-by: NeilBrown ---

[PATCH] sunrpc: don't check for failure from mempool_alloc()

When mempool_alloc() is allowed to sleep (GFP_NOIO allows sleeping) it cannot fail. So rpc_alloc_task() cannot fail, so rpc_new_task doesn't need to test for failure. Consequently rpc_new_task() cannot fail, so the callers don't need to test. Signed-off-by: NeilBrown --- net/sunrpc/clnt.c | 8

[PATCH 09/11] f2fs: Remove __GFP_NOFAIL flag from call to mempool_alloc()

Passing __GFP_NOFAIL to mempool_alloc() is strange because it bypasses the pool functionality provided by the mempool. mempool_alloc() will not fail even without the NOFAIL flag. So remove the flag and allow the pool to be used properly. Signed-off-by: NeilBrown ---

[PATCH 09/11] f2fs: Remove __GFP_NOFAIL flag from call to mempool_alloc()

Passing __GFP_NOFAIL to mempool_alloc() is strange because it bypasses the pool functionality provided by the mempool. mempool_alloc() will not fail even without the NOFAIL flag. So remove the flag and allow the pool to be used properly. Signed-off-by: NeilBrown --- fs/f2fs/data.c | 2 +- 1

[PATCH] virtio_scsi: don't check for failure from mempool_alloc()

mempool_alloc() cannot fail when passed GFP_NOIO or any other gfp setting that is permitted to sleep. So remove this pointless code. Signed-off-by: NeilBrown --- drivers/scsi/virtio_scsi.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/scsi/virtio_scsi.c

[PATCH] virtio_scsi: don't check for failure from mempool_alloc()

mempool_alloc() cannot fail when passed GFP_NOIO or any other gfp setting that is permitted to sleep. So remove this pointless code. Signed-off-by: NeilBrown --- drivers/scsi/virtio_scsi.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/scsi/virtio_scsi.c

Re: [PATCH v2] perf: fix double free at function perf_hpp__reset_output_field

On Sun, Apr 09, 2017 at 07:05:52PM +0200, Jiri Olsa wrote: > On Wed, Apr 05, 2017 at 10:44:22AM +0800, Du, Changbin wrote: > > On Tue, Apr 04, 2017 at 12:51:03PM -0300, Arnaldo Carvalho de Melo wrote: > > > Em Wed, Apr 05, 2017 at 12:34:59AM +0900, Namhyung Kim escreveu: > > > > Hi Arnaldo, > > >

Re: [PATCH v2] perf: fix double free at function perf_hpp__reset_output_field

On Sun, Apr 09, 2017 at 07:05:52PM +0200, Jiri Olsa wrote: > On Wed, Apr 05, 2017 at 10:44:22AM +0800, Du, Changbin wrote: > > On Tue, Apr 04, 2017 at 12:51:03PM -0300, Arnaldo Carvalho de Melo wrote: > > > Em Wed, Apr 05, 2017 at 12:34:59AM +0900, Namhyung Kim escreveu: > > > > Hi Arnaldo, > > >

[PATCH] scsi: ibmvfc: don't check for failure from mempool_alloc()

mempool_alloc() cannot fail when passed GFP_NOIO or any other gfp setting that is permitted to sleep. So remove this pointless code. Signed-off-by: NeilBrown --- drivers/scsi/ibmvscsi/ibmvfc.c | 6 -- 1 file changed, 6 deletions(-) diff --git

[PATCH] scsi: ibmvfc: don't check for failure from mempool_alloc()

mempool_alloc() cannot fail when passed GFP_NOIO or any other gfp setting that is permitted to sleep. So remove this pointless code. Signed-off-by: NeilBrown --- drivers/scsi/ibmvscsi/ibmvfc.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c

[PATCH] dm-verity-fec: don't check for failure from mempool_alloc(GFP_NOIO)

mempool_alloc() cannot fail for GFP_NOIO allocation, so there is no point testing for failure. One place the code tested for failure was passing "0" as the GFP flags. This is most unusually and is probably meant to be GFP_NOIO, so that is changed. Allocation from ->extra_pool and

[PATCH] dm-verity-fec: don't check for failure from mempool_alloc(GFP_NOIO)

mempool_alloc() cannot fail for GFP_NOIO allocation, so there is no point testing for failure. One place the code tested for failure was passing "0" as the GFP flags. This is most unusually and is probably meant to be GFP_NOIO, so that is changed. Allocation from ->extra_pool and

Re: linux-next: build failure after merge of the mfd tree

Hi all, On Tue, 04 Apr 2017 15:31:15 +0300 Andy Shevchenko wrote: > > On Tue, 2017-04-04 at 09:21 +0100, Lee Jones wrote: > > On Tue, 04 Apr 2017, Lee Jones wrote: > > > > > On Tue, 04 Apr 2017, Stephen Rothwell wrote: > > > > > > > After merging the mfd

[PATCH] dm-region-hash: fix strange usage of mempool_alloc.

mempool_alloc() should only be called with GFP_ATOMIC when it is not safe to wait. Passing __GFP_NOFAIL to kmalloc() says that it is safe to wait indefinitely. So this code is inconsistent. Clearly it is OK to wait indefinitely in this code, and mempool_alloc() is able to do that. So just use

Re: linux-next: build failure after merge of the mfd tree

Hi all, On Tue, 04 Apr 2017 15:31:15 +0300 Andy Shevchenko wrote: > > On Tue, 2017-04-04 at 09:21 +0100, Lee Jones wrote: > > On Tue, 04 Apr 2017, Lee Jones wrote: > > > > > On Tue, 04 Apr 2017, Stephen Rothwell wrote: > > > > > > > After merging the mfd tree, today's linux-next build

[PATCH] dm-region-hash: fix strange usage of mempool_alloc.

mempool_alloc() should only be called with GFP_ATOMIC when it is not safe to wait. Passing __GFP_NOFAIL to kmalloc() says that it is safe to wait indefinitely. So this code is inconsistent. Clearly it is OK to wait indefinitely in this code, and mempool_alloc() is able to do that. So just use

  1   2   3   4   5   >