[PATCH 3/4] input: xpad.rst: proc/bus/usb was renamed to dev/bus/usb

xpad.rst requests a dump of the USB description, as found on the USB character device. When we got rid of usbfs, its location change. Update it. Signed-off-by: Mauro Carvalho Chehab --- Documentation/input/devices/xpad.rst | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 3/4] input: xpad.rst: proc/bus/usb was renamed to dev/bus/usb

xpad.rst requests a dump of the USB description, as found on the USB character device. When we got rid of usbfs, its location change. Update it. Signed-off-by: Mauro Carvalho Chehab --- Documentation/input/devices/xpad.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 2/4] input: xpad.rst: Don't use literal blocks inside footnotes

Unfortunately, Sphinx (or LaTeX) can't handle literal blocks inside footnotes. So, just use normal text for the two literal code-blocks that documents the output of /sys/kernel/debug/usb/devices for xpad devices. Signed-off-by: Mauro Carvalho Chehab ---

[PATCH 1/4] input: xpad.rst: usb/devices is now at /sys/kernel/debug/

The /proc/bus/usb/devices got moved to sysfs. It is now sitting at: /sys/kernel/debug/usb/devices Signed-off-by: Mauro Carvalho Chehab --- Documentation/input/devices/xpad.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

[PATCH 2/4] input: xpad.rst: Don't use literal blocks inside footnotes

Unfortunately, Sphinx (or LaTeX) can't handle literal blocks inside footnotes. So, just use normal text for the two literal code-blocks that documents the output of /sys/kernel/debug/usb/devices for xpad devices. Signed-off-by: Mauro Carvalho Chehab --- Documentation/input/devices/xpad.rst | 51

[PATCH 1/4] input: xpad.rst: usb/devices is now at /sys/kernel/debug/

The /proc/bus/usb/devices got moved to sysfs. It is now sitting at: /sys/kernel/debug/usb/devices Signed-off-by: Mauro Carvalho Chehab --- Documentation/input/devices/xpad.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/input/devices/xpad.rst

Re: [PATCH 1/2] iio: adc: Fix integration time/averaging for INA219/220

On Freitag, 14. April 2017 17:02:33 CEST Jonathan Cameron wrote: > On 12/04/17 04:01, Stefan Brüns wrote: > > INA226/230/231 has integration times per voltage channel and common > > averaging setting for both channels, while the INA219/220 only has a > > combined integration time/averaging setting

Re: [PATCH 1/2] iio: adc: Fix integration time/averaging for INA219/220

On Freitag, 14. April 2017 17:02:33 CEST Jonathan Cameron wrote: > On 12/04/17 04:01, Stefan Brüns wrote: > > INA226/230/231 has integration times per voltage channel and common > > averaging setting for both channels, while the INA219/220 only has a > > combined integration time/averaging setting

Re: [PATCH 1/2] [media] uvcvideo: Refactor teardown of uvc on USB disconnect

Hi Daniel, Thank you for the patch (and the investigation). On Monday 17 Apr 2017 18:52:39 Daniel Axtens wrote: > Currently, disconnecting a USB webcam while it is in use prints out a > number of warnings, such as: > > WARNING: CPU: 2 PID: 3118 at >

Re: [PATCH 1/2] [media] uvcvideo: Refactor teardown of uvc on USB disconnect

Hi Daniel, Thank you for the patch (and the investigation). On Monday 17 Apr 2017 18:52:39 Daniel Axtens wrote: > Currently, disconnecting a USB webcam while it is in use prints out a > number of warnings, such as: > > WARNING: CPU: 2 PID: 3118 at >

[PATCH v3 12/12] arm64: allwinner: a64: enable Wi-Fi for Pine64

The Wi-Fi module of Pine64 is powered via DLDO4 and ELDO1 (the latter one provides I/O voltage). Add device node for it. Although the Wi-Fi module is an external module which should be inserted to a header, according to my personal talk with TL Lim, he does not want this header to be used as

[PATCH v3 12/12] arm64: allwinner: a64: enable Wi-Fi for Pine64

The Wi-Fi module of Pine64 is powered via DLDO4 and ELDO1 (the latter one provides I/O voltage). Add device node for it. Although the Wi-Fi module is an external module which should be inserted to a header, according to my personal talk with TL Lim, he does not want this header to be used as

[PATCH v3 11/12] arm64: allwinner: a64: enable AXP803 regulators for Pine64

Add support of AXP803 regulators in the Pine64 device tree, in order to enable many future functionalities, e.g. Wi-Fi. Signed-off-by: Icenowy Zheng --- .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109 + 1 file changed, 109 insertions(+) diff --git

[PATCH v3 11/12] arm64: allwinner: a64: enable AXP803 regulators for Pine64

Add support of AXP803 regulators in the Pine64 device tree, in order to enable many future functionalities, e.g. Wi-Fi. Signed-off-by: Icenowy Zheng --- .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109 + 1 file changed, 109 insertions(+) diff --git

[PATCH v3 10/12] arm64: allwinner: a64: add DTSI file for AXP803 PMIC

As nearly all A64 boards are using AXP803 PMIC, add a DTSI file for it, like the old DTSI files for AXP20x/22x, for the common parts of the PMIC. Signed-off-by: Icenowy Zheng --- arch/arm64/boot/dts/allwinner/axp803.dtsi | 150 ++ 1 file changed, 150

[PATCH v3 10/12] arm64: allwinner: a64: add DTSI file for AXP803 PMIC

As nearly all A64 boards are using AXP803 PMIC, add a DTSI file for it, like the old DTSI files for AXP20x/22x, for the common parts of the PMIC. Signed-off-by: Icenowy Zheng --- arch/arm64/boot/dts/allwinner/axp803.dtsi | 150 ++ 1 file changed, 150 insertions(+)

[PATCH v3 09/12] mfd: axp20x: add axp20x-regulator cell for AXP803

As axp20x-regulator now supports AXP803, add a cell for it. Signed-off-by: Icenowy Zheng --- Changes in v3: - Make the new cell one-liner. drivers/mfd/axp20x.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c

[PATCH v3 09/12] mfd: axp20x: add axp20x-regulator cell for AXP803

As axp20x-regulator now supports AXP803, add a cell for it. Signed-off-by: Icenowy Zheng --- Changes in v3: - Make the new cell one-liner. drivers/mfd/axp20x.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c index

[PATCH v3 08/12] regulator: axp20x-regulator: add support for AXP803

AXP803 PMIC also have a series of regulators (DCDCs and LDOs) controllable via I2C/RSB bus. Add support for them. Signed-off-by: Icenowy Zheng --- Changes in v2: - Place AXP803 codes before AXP806/809 ones. - Fixed some errors in regulator description. - Reuse AXP803 DLDO2

[PATCH v3 08/12] regulator: axp20x-regulator: add support for AXP803

AXP803 PMIC also have a series of regulators (DCDCs and LDOs) controllable via I2C/RSB bus. Add support for them. Signed-off-by: Icenowy Zheng --- Changes in v2: - Place AXP803 codes before AXP806/809 ones. - Fixed some errors in regulator description. - Reuse AXP803 DLDO2 range for AXP806

[PATCH v3 07/12] dt-bindings: add AXP803's regulator info

AXP803 have the most regulators in currently supported AXP PMICs. Add info for the regulators in the dt-bindings document. Signed-off-by: Icenowy Zheng Acked-by: Rob Herring --- Changes in v3: - Added Rob's ACK. Changes in v2: - Place AXP803 regulators before

[PATCH v3 07/12] dt-bindings: add AXP803's regulator info

AXP803 have the most regulators in currently supported AXP PMICs. Add info for the regulators in the dt-bindings document. Signed-off-by: Icenowy Zheng Acked-by: Rob Herring --- Changes in v3: - Added Rob's ACK. Changes in v2: - Place AXP803 regulators before AXP806/809 ones.

[PATCH v3 05/12] mfd: axp20x: support AXP803 variant

AXP803 is a new PMIC chip produced by X-Powers, usually paired with A64 via RSB bus. The PMIC itself is like AXP288, but with RSB support and dedicated VBUS and ACIN. Add support for it in the axp20x mfd driver. Currently only power key function is supported. Signed-off-by: Icenowy Zheng

[PATCH v3 06/12] arm64: allwinner: a64: add AXP803 node to Pine64 device tree

The Pine64 (including Pine64+) boards have an AXP803 as its main PMIC. Add its device node. Signed-off-by: Icenowy Zheng --- arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 11 +++ 1 file changed, 11 insertions(+) diff --git

[PATCH v3 05/12] mfd: axp20x: support AXP803 variant

AXP803 is a new PMIC chip produced by X-Powers, usually paired with A64 via RSB bus. The PMIC itself is like AXP288, but with RSB support and dedicated VBUS and ACIN. Add support for it in the axp20x mfd driver. Currently only power key function is supported. Signed-off-by: Icenowy Zheng ---

[PATCH v3 06/12] arm64: allwinner: a64: add AXP803 node to Pine64 device tree

The Pine64 (including Pine64+) boards have an AXP803 as its main PMIC. Add its device node. Signed-off-by: Icenowy Zheng --- arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts

[PATCH v3 04/12] dt-bindings: add device tree binding for X-Powers AXP803 PMIC

AXP803 is a PMIC produced by Shenzhen X-Powers, with either I2C or RSB bus. Add a compatible for it. Signed-off-by: Icenowy Zheng Acked-by: Chen-Yu Tsai Acked-by: Rob Herring --- Changes in v3: - Make the compatible one-liner. Changes in v2: -

[PATCH v3 04/12] dt-bindings: add device tree binding for X-Powers AXP803 PMIC

AXP803 is a PMIC produced by Shenzhen X-Powers, with either I2C or RSB bus. Add a compatible for it. Signed-off-by: Icenowy Zheng Acked-by: Chen-Yu Tsai Acked-by: Rob Herring --- Changes in v3: - Make the compatible one-liner. Changes in v2: - Place AXP803 before AXP806/809. - Added Chen-Yu's

[PATCH v3 03/12] dt-bindings: make AXP20X compatible strings one per line

In the binding documentation of AXP20X mfd, the compatible strings used to be listed for three per line, which leads to some mess when trying to add AXP803 compatible string (as we have already AXP806 and AXP809 compatibles, which is after AXP803 in ascending order). Make the compatible strings

[PATCH v3 03/12] dt-bindings: make AXP20X compatible strings one per line

In the binding documentation of AXP20X mfd, the compatible strings used to be listed for three per line, which leads to some mess when trying to add AXP803 compatible string (as we have already AXP806 and AXP809 compatibles, which is after AXP803 in ascending order). Make the compatible strings

[PATCH v3 02/12] arm64: allwinner: a64: add NMI controller on A64

Allwinner A64 SoC features a NMI controller, which is usually connected to the AXP PMIC. Add support for it. Signed-off-by: Icenowy Zheng Acked-by: Chen-Yu Tsai --- Changes in v2: - Added Chen-Yu's ACK. arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 8

[PATCH v3 02/12] arm64: allwinner: a64: add NMI controller on A64

Allwinner A64 SoC features a NMI controller, which is usually connected to the AXP PMIC. Add support for it. Signed-off-by: Icenowy Zheng Acked-by: Chen-Yu Tsai --- Changes in v2: - Added Chen-Yu's ACK. arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 8 1 file changed, 8

[PATCH v3 01/12] arm64: allwinner: a64: enable RSB on A64

Allwinner A64 have a RSB controller like the one on A23/A33 SoCs. Add it and its pinmux. Signed-off-by: Icenowy Zheng Acked-by: Chen-Yu Tsai --- Changes in v2: - Removed bonus properties in pio node. - Added Chen-Yu's ACK.

[PATCH v3 01/12] arm64: allwinner: a64: enable RSB on A64

Allwinner A64 have a RSB controller like the one on A23/A33 SoCs. Add it and its pinmux. Signed-off-by: Icenowy Zheng Acked-by: Chen-Yu Tsai --- Changes in v2: - Removed bonus properties in pio node. - Added Chen-Yu's ACK. arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 19

[PATCH v3 00/12] AXP803 PMIC support for Pine64

The Pine64 (including Pine64+) boards have an AXP803 PMIC, which is a PMIC similar to AXP288, but tweaked to use with Allwinner SoCs rather than Intel tablets (with DCIN and Vbus re-splitted like other AXP PMICs, and RSB bus support added). This patchset adds support for it and enabled it in

[PATCH v3 00/12] AXP803 PMIC support for Pine64

The Pine64 (including Pine64+) boards have an AXP803 PMIC, which is a PMIC similar to AXP288, but tweaked to use with Allwinner SoCs rather than Intel tablets (with DCIN and Vbus re-splitted like other AXP PMICs, and RSB bus support added). This patchset adds support for it and enabled it in

[PATCH] iommu/arm-smmu: Return IOVA in iova_to_phys when SMMU is bypassed

From: Sunil Goutham For software initiated address translation, when domain type is IOMMU_DOMAIN_IDENTITY i.e SMMU is bypassed, mimic HW behavior i.e return the same IOVA as translated address. This patch is an extension to Will Deacon's patchset "Implement SMMU

[PATCH] iommu/arm-smmu: Return IOVA in iova_to_phys when SMMU is bypassed

From: Sunil Goutham For software initiated address translation, when domain type is IOMMU_DOMAIN_IDENTITY i.e SMMU is bypassed, mimic HW behavior i.e return the same IOVA as translated address. This patch is an extension to Will Deacon's patchset "Implement SMMU passthrough using the default

Re: [PATCH 1/4] ftrace: Fix function pid filter on instances

On Mon, 17 Apr 2017 11:44:27 +0900 Namhyung Kim wrote: > When function tracer has a pid filter, it adds a probe to sched_switch > to track if current task can be ignored. The probe checks the > ftrace_ignore_pid from current tr to filter tasks. But it misses to > delete

Re: [PATCH 1/4] ftrace: Fix function pid filter on instances

On Mon, 17 Apr 2017 11:44:27 +0900 Namhyung Kim wrote: > When function tracer has a pid filter, it adds a probe to sched_switch > to track if current task can be ignored. The probe checks the > ftrace_ignore_pid from current tr to filter tasks. But it misses to > delete the probe when removing

Re: [PATCH] x86, kvm: Handle PFNs outside of kernel reach when touching GPTEs

On 04/12/2017 09:16 PM, Sironi, Filippo wrote: Thanks for taking the time and sorry for the delay. On 6. Apr 2017, at 16:22, Radim Krčmář wrote: 2017-04-05 15:07+0200, Filippo Sironi: cmpxchg_gpte() calls get_user_pages_fast() to retrieve the number of pages and the

Re: [PATCH] x86, kvm: Handle PFNs outside of kernel reach when touching GPTEs

On 04/12/2017 09:16 PM, Sironi, Filippo wrote: Thanks for taking the time and sorry for the delay. On 6. Apr 2017, at 16:22, Radim Krčmář wrote: 2017-04-05 15:07+0200, Filippo Sironi: cmpxchg_gpte() calls get_user_pages_fast() to retrieve the number of pages and the respective struct

Re: [PATCH] net: thunderx: Fix set_max_bgx_per_node for 81xx rgx

On Thu, Apr 13, 2017 at 12:55 PM, George Cherian wrote: > Add the PCI_SUBSYS_DEVID_81XX_RGX and use the same to set > the max bgx per node count. > > This fixes the issue intoduced by following commit > 78aacb6f6 net: thunderx: Fix invalid mac addresses for node1

Re: [PATCH] net: thunderx: Fix set_max_bgx_per_node for 81xx rgx

On Thu, Apr 13, 2017 at 12:55 PM, George Cherian wrote: > Add the PCI_SUBSYS_DEVID_81XX_RGX and use the same to set > the max bgx per node count. > > This fixes the issue intoduced by following commit > 78aacb6f6 net: thunderx: Fix invalid mac addresses for node1 interfaces > With this commit the

Re: [PATCH 2/2] powerpc/book3s: mce: Use add_taint_no_warn() in machine_check_early().

On 04/17/2017 04:09 PM, Daniel Axtens wrote: > Hi Mahesh, > >> Fixes: 27ea2c420cad powerpc: Set the correct kernel taint on machine check >> errors. > > I notice this Fixes a commit I introduced. Please could you cc me when > you do this? I am likely to miss it otherwise, especially since I

Re: [PATCH 2/2] powerpc/book3s: mce: Use add_taint_no_warn() in machine_check_early().

On 04/17/2017 04:09 PM, Daniel Axtens wrote: > Hi Mahesh, > >> Fixes: 27ea2c420cad powerpc: Set the correct kernel taint on machine check >> errors. > > I notice this Fixes a commit I introduced. Please could you cc me when > you do this? I am likely to miss it otherwise, especially since I

[PATCH] arm64: allwinner: h5: add support for NanoPi NEO2 board

NanoPi NEO2 is a board with the same size factor with the original NanoPi NEO by FriendlyELEC. It has a H5 instead of H3 on NanoPi NEO, and the ethernet is upgraded to 1Gbps (with external RTL8211E PHY). Add support for this board. Signed-off-by: Icenowy Zheng ---

[PATCH] arm64: allwinner: h5: add support for NanoPi NEO2 board

NanoPi NEO2 is a board with the same size factor with the original NanoPi NEO by FriendlyELEC. It has a H5 instead of H3 on NanoPi NEO, and the ethernet is upgraded to 1Gbps (with external RTL8211E PHY). Add support for this board. Signed-off-by: Icenowy Zheng ---

[PATCH] tools/virtio: fix build breakage

Commit db932ced55cf ("virtio: add context flag to find vqs") added a new 'context' flag to vring_new_virtqueue(), but the corresponding API in tools/virtio/ is not updated causing build errors due to conflicting declarations. Bring code in tools/virtio in sync with that in kernel. I have used

[PATCH] tools/virtio: fix build breakage

Commit db932ced55cf ("virtio: add context flag to find vqs") added a new 'context' flag to vring_new_virtqueue(), but the corresponding API in tools/virtio/ is not updated causing build errors due to conflicting declarations. Bring code in tools/virtio in sync with that in kernel. I have used

Re: [PATCH 1/3] zram: fix operator precedence to get offset

On (04/17/17 19:50), Sergey Senozhatsky wrote: [..] > so in the existing scheme of things, we never care about 'sector' > passed from zram_rw_page(). and this has worked for us for quite > some time. my call would be -- let's drop zram_rw_page() `sector' > calculation. d'oh... s/sector/offset/g

Re: [PATCH 1/3] zram: fix operator precedence to get offset

On (04/17/17 19:50), Sergey Senozhatsky wrote: [..] > so in the existing scheme of things, we never care about 'sector' > passed from zram_rw_page(). and this has worked for us for quite > some time. my call would be -- let's drop zram_rw_page() `sector' > calculation. d'oh... s/sector/offset/g

Re: [PATCH 1/3] zram: fix operator precedence to get offset

Hello Minchan, On (04/17/17 11:14), Minchan Kim wrote: > On Mon, Apr 17, 2017 at 10:54:29AM +0900, Sergey Senozhatsky wrote: > > On (04/17/17 10:21), Sergey Senozhatsky wrote: > > > > However, it should be *fixed* to prevent confusion in future > > > > or may be something like below? can save us

Re: [PATCH 1/3] zram: fix operator precedence to get offset

Hello Minchan, On (04/17/17 11:14), Minchan Kim wrote: > On Mon, Apr 17, 2017 at 10:54:29AM +0900, Sergey Senozhatsky wrote: > > On (04/17/17 10:21), Sergey Senozhatsky wrote: > > > > However, it should be *fixed* to prevent confusion in future > > > > or may be something like below? can save us

Re: cgroup: avoid attaching a cgroup root to two different superblocks

On 2017/4/15 7:32, Andrei Vagin wrote: > On Fri, Apr 14, 2017 at 04:27:37PM -0700, Andrei Vagin wrote: >> Hello, >> >> One of our CRIU tests hangs with this patch. >> >> Steps to reproduce: >> curl -o cgroupns.c >>

Re: cgroup: avoid attaching a cgroup root to two different superblocks

On 2017/4/15 7:32, Andrei Vagin wrote: > On Fri, Apr 14, 2017 at 04:27:37PM -0700, Andrei Vagin wrote: >> Hello, >> >> One of our CRIU tests hangs with this patch. >> >> Steps to reproduce: >> curl -o cgroupns.c >>

Re: [PATCH 2/2] powerpc/book3s: mce: Use add_taint_no_warn() in machine_check_early().

Hi Mahesh, > Fixes: 27ea2c420cad powerpc: Set the correct kernel taint on machine check > errors. I notice this Fixes a commit I introduced. Please could you cc me when you do this? I am likely to miss it otherwise, especially since I have now left IBM. Being cced allows me to provide an Ack

Re: [PATCH 2/2] powerpc/book3s: mce: Use add_taint_no_warn() in machine_check_early().

Hi Mahesh, > Fixes: 27ea2c420cad powerpc: Set the correct kernel taint on machine check > errors. I notice this Fixes a commit I introduced. Please could you cc me when you do this? I am likely to miss it otherwise, especially since I have now left IBM. Being cced allows me to provide an Ack

Re: [PATCH v3 2/2] Input: add support for the STMicroelectronics FingerTip touchscreen

Hi Dmitry, kindly ping, again. Please let me know if there is something I can do. Andi On Fri, Apr 07, 2017 at 06:31:29PM +0900, Andi Shyti wrote: > Hi Dmitry, > > just a kind ping, do you have any comment about this? > > Thanks, > Andi > > On Mon, Mar 27, 2017 at 10:07:43PM +0900, Andi

Re: [PATCH v3 2/2] Input: add support for the STMicroelectronics FingerTip touchscreen

Hi Dmitry, kindly ping, again. Please let me know if there is something I can do. Andi On Fri, Apr 07, 2017 at 06:31:29PM +0900, Andi Shyti wrote: > Hi Dmitry, > > just a kind ping, do you have any comment about this? > > Thanks, > Andi > > On Mon, Mar 27, 2017 at 10:07:43PM +0900, Andi

Re: [PATCH] Revert "arm64: Increase the max granular size"

>> >> Do you have an explanation on the performance variation when >> >> L1_CACHE_BYTES is changed? We'd need to understand how the network >> stack >> >> is affected by L1_CACHE_BYTES, in which context it uses it (is it for >> >> non-coherent DMA?). >> > >> > network

Re: [PATCH] Revert "arm64: Increase the max granular size"

>> >> Do you have an explanation on the performance variation when >> >> L1_CACHE_BYTES is changed? We'd need to understand how the network >> stack >> >> is affected by L1_CACHE_BYTES, in which context it uses it (is it for >> >> non-coherent DMA?). >> > >> > network

[PATCH] ARM: sunxi: h3/h5: fix the compatible of R_CCU

The R_CCU of H3/H5 currently wrongly used A64 R_CCU compatible. Fix it by changing it to the correct H3 compatible. Signed-off-by: Icenowy Zheng --- arch/arm/boot/dts/sunxi-h3-h5.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] ARM: sunxi: h3/h5: fix the compatible of R_CCU

The R_CCU of H3/H5 currently wrongly used A64 R_CCU compatible. Fix it by changing it to the correct H3 compatible. Signed-off-by: Icenowy Zheng --- arch/arm/boot/dts/sunxi-h3-h5.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi

Re: [PATCH v2 2/2] usb: dwc2: add multiple clocks handling

Hi John, I apologize if this was presumptuous, would you like to have a look this series please? On 2017/3/28 21:49, Felipe Balbi wrote: Hi, Heiko Stübner writes: Am Donnerstag, 9. Februar 2017, 10:44:39 CET schrieb Frank Wang: Since dwc2 may have one or more input

Re: [PATCH v2 2/2] usb: dwc2: add multiple clocks handling

Hi John, I apologize if this was presumptuous, would you like to have a look this series please? On 2017/3/28 21:49, Felipe Balbi wrote: Hi, Heiko Stübner writes: Am Donnerstag, 9. Februar 2017, 10:44:39 CET schrieb Frank Wang: Since dwc2 may have one or more input clocks need to manage

Re: [PATCH 3/8] x86/boot/64: Add support of additional page table level during early boot

* Kirill A. Shutemov wrote: > On Tue, Apr 11, 2017 at 07:09:07AM -0700, Andi Kleen wrote: > > > I'll look closer (building proccess it's rather complicated), but my > > > understanding is that VDSO is stand-alone binary and doesn't really links > > > with the rest of the

Re: [PATCH 3/8] x86/boot/64: Add support of additional page table level during early boot

* Kirill A. Shutemov wrote: > On Tue, Apr 11, 2017 at 07:09:07AM -0700, Andi Kleen wrote: > > > I'll look closer (building proccess it's rather complicated), but my > > > understanding is that VDSO is stand-alone binary and doesn't really links > > > with the rest of the kernel, rather included

Re: [PATCH] arm: dma: fix sharing of coherent DMA memory without struct page

On Sun, Apr 16, 2017 at 07:10:21PM -0600, Shuah Khan wrote: > On 04/14/2017 03:46 AM, Russell King - ARM Linux wrote: > > On Fri, Apr 14, 2017 at 09:56:07AM +0200, Marek Szyprowski wrote: > This would be however quite large task, especially taking into account > all current users of

Re: [PATCH] arm: dma: fix sharing of coherent DMA memory without struct page

On Sun, Apr 16, 2017 at 07:10:21PM -0600, Shuah Khan wrote: > On 04/14/2017 03:46 AM, Russell King - ARM Linux wrote: > > On Fri, Apr 14, 2017 at 09:56:07AM +0200, Marek Szyprowski wrote: > This would be however quite large task, especially taking into account > all current users of

[PATCH] Make DMABUF a menuconfig to ease disabling it all

No need to get into the submenu to disable all DMABUF-related config entries Make the selecters also select the new DMABUF menuconfig Signed-off-by: Vincent Legoll --- drivers/dma-buf/Kconfig | 7 --- drivers/gpu/drm/Kconfig | 1 +

[PATCH] Make DMABUF a menuconfig to ease disabling it all

No need to get into the submenu to disable all DMABUF-related config entries Make the selecters also select the new DMABUF menuconfig Signed-off-by: Vincent Legoll --- drivers/dma-buf/Kconfig | 7 --- drivers/gpu/drm/Kconfig | 1 + drivers/gpu/drm/msm/Kconfig | 1 + 3 files

[PATCH] f2fs: introduce __check_rb_tree_consistence

Introduce __check_rb_tree_consistence to check consistence of rb-tree based discard cache in runtime. Signed-off-by: Chao Yu --- fs/f2fs/extent_cache.c | 32 fs/f2fs/f2fs.h | 2 ++ fs/f2fs/segment.c | 15 +-- 3 files

[PATCH] f2fs: introduce __check_rb_tree_consistence

Introduce __check_rb_tree_consistence to check consistence of rb-tree based discard cache in runtime. Signed-off-by: Chao Yu --- fs/f2fs/extent_cache.c | 32 fs/f2fs/f2fs.h | 2 ++ fs/f2fs/segment.c | 15 +-- 3 files changed, 47

Re: [PATCH RFC] Make BCMA a menuconfig to ease disabling it all

Argh, looks like the "--in-reply-to" did not hook it up properly... This was intended as a reply to: http://lkml.iu.edu/hypermail/linux/kernel/1704.1/04654.html Re: [PATCH] Make AMBA a menuconfig to ease disabling it all from (Fri Apr 14 2017 - 08:33:57 EST) Sorry -- Vincent Legoll

Re: [PATCH RFC] Make BCMA a menuconfig to ease disabling it all

Argh, looks like the "--in-reply-to" did not hook it up properly... This was intended as a reply to: http://lkml.iu.edu/hypermail/linux/kernel/1704.1/04654.html Re: [PATCH] Make AMBA a menuconfig to ease disabling it all from (Fri Apr 14 2017 - 08:33:57 EST) Sorry -- Vincent Legoll

[PATCH RFC] Make BCMA a menuconfig to ease disabling it all

Hello, this is more what I wanted to achieve, an easily disableable BCMA menuconfig. This is working as intended on x86_64 defconfig, whereas it is harder to disable for ARCH=arm because of "select"s. But that's less of an issue, as those arch's defconfigs may very well want the feature enbled,

[PATCH] Make BCMA a menuconfig to ease disabling it all

No need to get into the submenu to disable all BCMA-related config entries Signed-off-by: Vincent Legoll --- drivers/bcma/Kconfig | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/bcma/Kconfig b/drivers/bcma/Kconfig index

[PATCH RFC] Make BCMA a menuconfig to ease disabling it all

Hello, this is more what I wanted to achieve, an easily disableable BCMA menuconfig. This is working as intended on x86_64 defconfig, whereas it is harder to disable for ARCH=arm because of "select"s. But that's less of an issue, as those arch's defconfigs may very well want the feature enbled,

[PATCH] Make BCMA a menuconfig to ease disabling it all

No need to get into the submenu to disable all BCMA-related config entries Signed-off-by: Vincent Legoll --- drivers/bcma/Kconfig | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/bcma/Kconfig b/drivers/bcma/Kconfig index b5c48a8..54f81c5 100644 ---

Re: [PATCH 0/6] fujitsu-laptop: LED cleanup

On Fri, Apr 07, 2017 at 03:07:07PM +0200, Micha?? K??pie?? wrote: > This patch series cleans up parts of fujitsu-laptop responsible for > handling LED class devices. It was tested on a Lifebook E744. It > depends on the previous patch series I submitted for fujitsu-laptop and > should be applied

RE: [PATCH] ACPICA: Export mutex functions

Hi, > From: Devel [mailto:devel-boun...@acpica.org] On Behalf Of Zheng, Lv > Sent: Monday, April 17, 2017 5:40 PM > To: Guenter Roeck ; Moore, Robert > Cc: linux-a...@vger.kernel.org; de...@acpica.org; Wysocki, Rafael J > ;

Re: [PATCH 0/6] fujitsu-laptop: LED cleanup

On Fri, Apr 07, 2017 at 03:07:07PM +0200, Micha?? K??pie?? wrote: > This patch series cleans up parts of fujitsu-laptop responsible for > handling LED class devices. It was tested on a Lifebook E744. It > depends on the previous patch series I submitted for fujitsu-laptop and > should be applied

RE: [PATCH] ACPICA: Export mutex functions

Hi, > From: Devel [mailto:devel-boun...@acpica.org] On Behalf Of Zheng, Lv > Sent: Monday, April 17, 2017 5:40 PM > To: Guenter Roeck ; Moore, Robert > Cc: linux-a...@vger.kernel.org; de...@acpica.org; Wysocki, Rafael J > ; > linux-kernel@vger.kernel.org > Subject: Re: [Devel] [PATCH] ACPICA:

Re: [PATCH RFC] ptr_ring: add ptr_ring_unconsume

Hello! On 4/17/2017 2:19 AM, Michael S. Tsirkin wrote: Applications that consume a batch of entries in one go can benefit from ability to return some of them back into the ring. Add an API for that - assuming there's space. If there's no space naturally we can't do this and have to drop

Re: [PATCH RFC] ptr_ring: add ptr_ring_unconsume

Hello! On 4/17/2017 2:19 AM, Michael S. Tsirkin wrote: Applications that consume a batch of entries in one go can benefit from ability to return some of them back into the ring. Add an API for that - assuming there's space. If there's no space naturally we can't do this and have to drop

RE: [PATCH] ACPICA: Export mutex functions

Hi, > From: Guenter Roeck [mailto:li...@roeck-us.net] > Subject: Re: [PATCH] ACPICA: Export mutex functions > > On Wed, Apr 12, 2017 at 03:29:55PM +, Moore, Robert wrote: > > The ACPICA mutex functions are based on the host OS functions, so they > > don't really buy you anything. > You

RE: [PATCH] ACPICA: Export mutex functions

Hi, > From: Guenter Roeck [mailto:li...@roeck-us.net] > Subject: Re: [PATCH] ACPICA: Export mutex functions > > On Wed, Apr 12, 2017 at 03:29:55PM +, Moore, Robert wrote: > > The ACPICA mutex functions are based on the host OS functions, so they > > don't really buy you anything. > You

[PATCH] efi/libstub/arm: Don't use TASK_SIZE when randomising the RT space

As reported by James, Catalin and Mark, commit e69176d68d26 ("ef/libstub/arm/arm64: Randomize the base of the UEFI rt services region") results in a crash in the firmware regardless of whether KASLR is in effect or not, and whether the firmware implements EFI_RNG_PROTOCOL or not. Mark has

[PATCH] efi/libstub/arm: Don't use TASK_SIZE when randomising the RT space

As reported by James, Catalin and Mark, commit e69176d68d26 ("ef/libstub/arm/arm64: Randomize the base of the UEFI rt services region") results in a crash in the firmware regardless of whether KASLR is in effect or not, and whether the firmware implements EFI_RNG_PROTOCOL or not. Mark has

[GIT PULL] EFI fixup for v4.12 queue

Hi all, Please merge this onto the v4.12 EFI queue: it fixes an issue reported with -next where arm64 machines fail to boot due to a premature dereference of the 'current' pointer. The following changes since commit efc491b0f06f65ea588f6591f0bc31db779e0594: ef/libstub: arm/arm64: Randomize

[GIT PULL] EFI fixup for v4.12 queue

Hi all, Please merge this onto the v4.12 EFI queue: it fixes an issue reported with -next where arm64 machines fail to boot due to a premature dereference of the 'current' pointer. The following changes since commit efc491b0f06f65ea588f6591f0bc31db779e0594: ef/libstub: arm/arm64: Randomize

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

On 04/10/2017 12:44 AM, Jiri Olsa wrote: On Sun, Apr 09, 2017 at 07:43:15PM -0700, Jiada Wang wrote: 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

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

On 04/10/2017 12:44 AM, Jiri Olsa wrote: On Sun, Apr 09, 2017 at 07:43:15PM -0700, Jiada Wang wrote: 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

[PATCH] perf/core: Remove redundant get_online_cpus()

SyS_perf_event_open() calls get_online_cpus() and eventually invokes swevent_hlist_get() which does it again. All callchains leading to swevent_hlist_get() originate from SyS_perf_event_open() so the extra protection is redundant. Remove it. Signed-off-by: Thomas Gleixner

[PATCH] perf/core: Remove redundant get_online_cpus()

SyS_perf_event_open() calls get_online_cpus() and eventually invokes swevent_hlist_get() which does it again. All callchains leading to swevent_hlist_get() originate from SyS_perf_event_open() so the extra protection is redundant. Remove it. Signed-off-by: Thomas Gleixner Cc: Peter Zijlstra

[PATCH] [media] atmel-isc: Fix the static checker warning

Initialize the pointer 'fmt' before the start of the loop. Reported-by: Dan Carpenter Signed-off-by: Songjun Wu --- drivers/media/platform/atmel/atmel-isc.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH] [media] atmel-isc: Fix the static checker warning

Initialize the pointer 'fmt' before the start of the loop. Reported-by: Dan Carpenter Signed-off-by: Songjun Wu --- drivers/media/platform/atmel/atmel-isc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/platform/atmel/atmel-isc.c b/drivers/media/platform/atmel/atmel-isc.c

Re: [patch 03/20] padata: Make padata_alloc() static

On Sun, 16 Apr 2017, Jason A. Donenfeld wrote: > I rather like this option of padata, which, since it lives in > kernel/padata.c and linux/padata.h, should be generic and useful for > other components. Seems like the ability to allocate it for a > particular set of worker CPUs and callback CPUs

Re: [patch 03/20] padata: Make padata_alloc() static

On Sun, 16 Apr 2017, Jason A. Donenfeld wrote: > I rather like this option of padata, which, since it lives in > kernel/padata.c and linux/padata.h, should be generic and useful for > other components. Seems like the ability to allocate it for a > particular set of worker CPUs and callback CPUs

<    4   5   6   7   8   9   10   11   >