Re: [PATCH] kernel/resource.c: fix muxed resource handling in __request_region()

On Mon, 22 Feb 2016 13:49:12 +, Alan Cox wrote: > It's not used much, especially nowdays. The use case is basically multi > I/O chips on the ISA/LPC bus with magic shared config register ports. This is precisely a super I/O driver (gpio-f7188x) which, when used with

Re: [PATCH] kernel/resource.c: fix muxed resource handling in __request_region()

On Mon, 22 Feb 2016 13:49:12 +, Alan Cox wrote: > It's not used much, especially nowdays. The use case is basically multi > I/O chips on the ISA/LPC bus with magic shared config register ports. This is precisely a super I/O driver (gpio-f7188x) which, when used with concurrent accesses on an

RE: [PATCH net v2] r8169:fix "rtl_counters_cond == 1 (loop: 1000, delay: 10)" log spam.

> Nits: > > - the tp->TxDescArray test provides the required synchronization: see > rtl8169_{open/close} and their pm_runtime_{get / put}. > > - ioaddr is not really needed : tp->mmio_addr appears only once and it does > not mess the 72..80 cols limit. > > - even if the device can only be

RE: [PATCH net v2] r8169:fix "rtl_counters_cond == 1 (loop: 1000, delay: 10)" log spam.

> Nits: > > - the tp->TxDescArray test provides the required synchronization: see > rtl8169_{open/close} and their pm_runtime_{get / put}. > > - ioaddr is not really needed : tp->mmio_addr appears only once and it does > not mess the 72..80 cols limit. > > - even if the device can only be

Re: [PATCH 06/61] gpio: adp5520: Use devm_gpiochip_add_data() for gpio registration

On 02/22/2016 03:07 PM, Laxman Dewangan wrote: Use devm_gpiochip_add_data() for GPIO registration and remove the call for gpiochip_remove() from error path. Also remove the need of driver callback .remove. Signed-off-by: Laxman Dewangan Acked-by: Michael Hennerich

Re: [PATCH 06/61] gpio: adp5520: Use devm_gpiochip_add_data() for gpio registration

On 02/22/2016 03:07 PM, Laxman Dewangan wrote: Use devm_gpiochip_add_data() for GPIO registration and remove the call for gpiochip_remove() from error path. Also remove the need of driver callback .remove. Signed-off-by: Laxman Dewangan Acked-by: Michael Hennerich Cc: Michael Hennerich

Re: [PATCH 07/61] gpio: adp5588: Use devm_gpiochip_add_data() for gpio registration

On 02/22/2016 03:07 PM, Laxman Dewangan wrote: Use devm_gpiochip_add_data() for GPIO registration and remove the call for gpiochip_remove() from remove callback. Signed-off-by: Laxman Dewangan Acked-by: Michael Hennerich Cc: Michael

Re: [PATCH 07/61] gpio: adp5588: Use devm_gpiochip_add_data() for gpio registration

On 02/22/2016 03:07 PM, Laxman Dewangan wrote: Use devm_gpiochip_add_data() for GPIO registration and remove the call for gpiochip_remove() from remove callback. Signed-off-by: Laxman Dewangan Acked-by: Michael Hennerich Cc: Michael Hennerich --- drivers/gpio/gpio-adp5588.c | 4 +---

Re: [PATCH 3/6] perf, tools, stat: Support metrics in --per-core/socket mode

On Mon, Feb 22, 2016 at 05:52:02PM +0100, Andi Kleen wrote: > On Sun, Feb 21, 2016 at 06:15:35PM +0100, Jiri Olsa wrote: > > On Wed, Feb 17, 2016 at 02:44:02PM -0800, Andi Kleen wrote: > > > > SNIP > > > > > @@ -892,7 +908,10 @@ static void printout(int id, int nr, struct > > > perf_evsel

Re: [PATCH 3/6] perf, tools, stat: Support metrics in --per-core/socket mode

On Mon, Feb 22, 2016 at 05:52:02PM +0100, Andi Kleen wrote: > On Sun, Feb 21, 2016 at 06:15:35PM +0100, Jiri Olsa wrote: > > On Wed, Feb 17, 2016 at 02:44:02PM -0800, Andi Kleen wrote: > > > > SNIP > > > > > @@ -892,7 +908,10 @@ static void printout(int id, int nr, struct > > > perf_evsel

[PATCH v11 1/2] Documentation: bridge: Add documentation for ps8640 DT properties

Add documentation for DT properties supported by ps8640 DSI-eDP converter. Signed-off-by: Jitao Shi Acked-by: Rob Herring Reviewed-by: Philipp Zabel --- Chnages since v10: - set sleep reset pin as GPIO_ACTIVE_LOW ---

[PATCH v11 1/2] Documentation: bridge: Add documentation for ps8640 DT properties

Add documentation for DT properties supported by ps8640 DSI-eDP converter. Signed-off-by: Jitao Shi Acked-by: Rob Herring Reviewed-by: Philipp Zabel --- Chnages since v10: - set sleep reset pin as GPIO_ACTIVE_LOW --- .../devicetree/bindings/display/bridge/ps8640.txt | 43

[PATCH v11 2/2] drm/bridge: Add I2C based driver for ps8640 bridge

This patch adds drm_bridge driver for parade DSI to eDP bridge chip. Signed-off-by: Jitao Shi --- Changes since v10: - Tuning PS8640 reset sleep pins squence The following patches are needed to support dsi host through none dsi bus:

[PATCH v11 2/2] drm/bridge: Add I2C based driver for ps8640 bridge

This patch adds drm_bridge driver for parade DSI to eDP bridge chip. Signed-off-by: Jitao Shi --- Changes since v10: - Tuning PS8640 reset sleep pins squence The following patches are needed to support dsi host through none dsi bus: https://patchwork.kernel.org/patch/8289181/ ("drm/dsi:

[PATCH v3 02/11] tools/lguest: make lguest launcher use X86_SUBARCH_LGUEST explicitly

Be explicit and make use of X86_SUBARCH_LGUEST directly. Signed-off-by: Luis R. Rodriguez --- tools/lguest/lguest.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/lguest/lguest.c b/tools/lguest/lguest.c index 80159e6811c2..ff0aa580c6e1 100644

[PATCH v3 02/11] tools/lguest: make lguest launcher use X86_SUBARCH_LGUEST explicitly

Be explicit and make use of X86_SUBARCH_LGUEST directly. Signed-off-by: Luis R. Rodriguez --- tools/lguest/lguest.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/lguest/lguest.c b/tools/lguest/lguest.c index 80159e6811c2..ff0aa580c6e1 100644 ---

[PATCH v3 2/2] power: ucs1002: Add support for Programmable USB Port Power Controller

The UCS1002-2 provides a USB port power switch for precise control of up to 2.5 amperes continuous current with over-current limit (OCL), dynamic thermal management, latch or auto-recovery (low test current) fault handling, selectable active low or high enable, under- and over-voltage lockout,

[PATCH v3 1/2] devicetree: Add UCS1002 USB Port Power Controller binding

The UCS1002-2 provides a USB port power switch for precise control of up to 2.5 amperes continuous current. You can add support to your board with current binding. Example: ucs1002: ucs1002@57 { compatible = "microchip,ucs1002"; reg = <0x57>; }; Signed-off-by:

[PATCH v3 1/2] devicetree: Add UCS1002 USB Port Power Controller binding

The UCS1002-2 provides a USB port power switch for precise control of up to 2.5 amperes continuous current. You can add support to your board with current binding. Example: ucs1002: ucs1002@57 { compatible = "microchip,ucs1002"; reg = <0x57>; }; Signed-off-by:

[PATCH v3 2/2] power: ucs1002: Add support for Programmable USB Port Power Controller

The UCS1002-2 provides a USB port power switch for precise control of up to 2.5 amperes continuous current with over-current limit (OCL), dynamic thermal management, latch or auto-recovery (low test current) fault handling, selectable active low or high enable, under- and over-voltage lockout,

[PATCH v3 0/2] Add UCS1002 USB Port Power Controller

Dear all, This is the third version of the UCS1002 driver, a Programmable USB Port Power Controller with Charger Emulation. Any comments are welcome. Thanks in advance. Enric Balletbo i Serra (2): devicetree: Add UCS1002 USB Port Power Controller binding power: ucs1002: Add support for

[PATCH v3 0/2] Add UCS1002 USB Port Power Controller

Dear all, This is the third version of the UCS1002 driver, a Programmable USB Port Power Controller with Charger Emulation. Any comments are welcome. Thanks in advance. Enric Balletbo i Serra (2): devicetree: Add UCS1002 USB Port Power Controller binding power: ucs1002: Add support for

[PATCH v3 00/11] x86/init: replace paravirt_enabled() were possible

trivial it'd still be good to get your Acked-by or Reviewed-by. In case anyone needs it these patches are also up on my linux-next tree on the 20160222-remove-pv-enabled-test-02 branch. They're all based on linux-next tag next-20160222. [0] http://kernelnewbies.org/KernelProjects/remove-paravirt

[PATCH v3 00/11] x86/init: replace paravirt_enabled() were possible

trivial it'd still be good to get your Acked-by or Reviewed-by. In case anyone needs it these patches are also up on my linux-next tree on the 20160222-remove-pv-enabled-test-02 branch. They're all based on linux-next tag next-20160222. [0] http://kernelnewbies.org/KernelProjects/remove-paravirt

[PATCH v3 03/11] x86/xen: use X86_SUBARCH_XEN for PV guest boots

The use of subarch should have no current effect on Xen PV guests, as such this should have no current functional effects. Signed-off-by: Luis R. Rodriguez --- arch/x86/xen/enlighten.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/xen/enlighten.c

[PATCH v3 03/11] x86/xen: use X86_SUBARCH_XEN for PV guest boots

The use of subarch should have no current effect on Xen PV guests, as such this should have no current functional effects. Signed-off-by: Luis R. Rodriguez --- arch/x86/xen/enlighten.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index

[PATCH v3 08/11] x86/cpu/intel: replace paravirt_enabled() for f00f work around

Use the harware subarch instead now that they are set. If we want to test removing this work around on Xen we can do so separatley as another independent change, for now we just want to remove paravirt_enabled(). v3: fix 0-day-bot compile error on a randconfig, missing to include

[PATCH v3 07/11] x86/tboot: remove paravirt_enabled()

There is already a check for boot_params.tboot_addr prior to paravirt_enabled() and both Xen and lguest never set this. This check is not needed. Signed-off-by: Luis R. Rodriguez --- arch/x86/kernel/tboot.c | 6 -- 1 file changed, 6 deletions(-) diff --git

[PATCH v3 08/11] x86/cpu/intel: replace paravirt_enabled() for f00f work around

Use the harware subarch instead now that they are set. If we want to test removing this work around on Xen we can do so separatley as another independent change, for now we just want to remove paravirt_enabled(). v3: fix 0-day-bot compile error on a randconfig, missing to include

[PATCH v3 07/11] x86/tboot: remove paravirt_enabled()

There is already a check for boot_params.tboot_addr prior to paravirt_enabled() and both Xen and lguest never set this. This check is not needed. Signed-off-by: Luis R. Rodriguez --- arch/x86/kernel/tboot.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/arch/x86/kernel/tboot.c

[PATCH v3 05/11] tools/lguest: force disable tboot and apm

The paravirt_enabled() check is going away, force disable tboot and apm just in case the kernel file being read might have this set for whatever reason. Signed-off-by: Luis R. Rodriguez --- tools/lguest/lguest.c | 6 ++ 1 file changed, 6 insertions(+) diff --git

[PATCH v3 05/11] tools/lguest: force disable tboot and apm

The paravirt_enabled() check is going away, force disable tboot and apm just in case the kernel file being read might have this set for whatever reason. Signed-off-by: Luis R. Rodriguez --- tools/lguest/lguest.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/tools/lguest/lguest.c

Re: [PATCH v2] mm/slab: re-implement pfmemalloc support

On Mon, Feb 22, 2016 at 11:52:42AM +, Mel Gorman wrote: > On Thu, Feb 11, 2016 at 04:34:47PM +0900, js1...@gmail.com wrote: > > From: Joonsoo Kim > > > > Current implementation of pfmemalloc handling in SLAB has some problems. > > > > Tested-by: Mel Gorman

Re: [PATCH v2] mm/slab: re-implement pfmemalloc support

On Mon, Feb 22, 2016 at 11:52:42AM +, Mel Gorman wrote: > On Thu, Feb 11, 2016 at 04:34:47PM +0900, js1...@gmail.com wrote: > > From: Joonsoo Kim > > > > Current implementation of pfmemalloc handling in SLAB has some problems. > > > > Tested-by: Mel Gorman Thanks for testing! > > The

[PATCH v3 09/11] x86/boot: add BIT() to boot/bitops.h

The boot/bitops.h has guards against including the regular bitops (include/asm-generic/bitops.h), it only implements what we need at early boot. We'll be making use of BIT() later so add it. Users of boot/boot.h must include it prior to asm/setup.h otherwise the guard protection devised against

[PATCH v3 09/11] x86/boot: add BIT() to boot/bitops.h

The boot/bitops.h has guards against including the regular bitops (include/asm-generic/bitops.h), it only implements what we need at early boot. We'll be making use of BIT() later so add it. Users of boot/boot.h must include it prior to asm/setup.h otherwise the guard protection devised against

[PATCH v3 11/11] pnpbios: replace paravirt_enabled() check with subarch checks

Since we are removing paravirt_enabled() replace it with a logical equivalent. Signed-off-by: Luis R. Rodriguez --- drivers/pnp/pnpbios/core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/pnp/pnpbios/core.c b/drivers/pnp/pnpbios/core.c index

[PATCH v3 11/11] pnpbios: replace paravirt_enabled() check with subarch checks

Since we are removing paravirt_enabled() replace it with a logical equivalent. Signed-off-by: Luis R. Rodriguez --- drivers/pnp/pnpbios/core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/pnp/pnpbios/core.c b/drivers/pnp/pnpbios/core.c index

[PATCH v3 10/11] x86/rtc: replace paravirt rtc check with x86 specific solution

We have 4 types of x86 platforms that disable RTC: * Intel MID * Lguest - uses paravirt * Xen dom-U - uses paravirt * x86 on legacy systems annotated with an ACPI legacy flag We can consolidate all of these into a platform specific solution. Signed-off-by: Luis R. Rodriguez

[PATCH v3 10/11] x86/rtc: replace paravirt rtc check with x86 specific solution

We have 4 types of x86 platforms that disable RTC: * Intel MID * Lguest - uses paravirt * Xen dom-U - uses paravirt * x86 on legacy systems annotated with an ACPI legacy flag We can consolidate all of these into a platform specific solution. Signed-off-by: Luis R. Rodriguez ---

[PATCH v3 04/11] x86/init: make ebda depend on PC subarch

This lets us remove its use of paravirt_enabled(). The other subarchs are not needed here given that on 32-bit there is a switch already that negates access to this code on X86_SUBARCH_INTEL_MID, and X86_SUBARCH_CE4100. Both lguest and Xen had paravirt_enabled so that excludes them.

[PATCH v3 04/11] x86/init: make ebda depend on PC subarch

This lets us remove its use of paravirt_enabled(). The other subarchs are not needed here given that on 32-bit there is a switch already that negates access to this code on X86_SUBARCH_INTEL_MID, and X86_SUBARCH_CE4100. Both lguest and Xen had paravirt_enabled so that excludes them.

[PATCH v3 06/11] apm32: remove paravirt_enabled() use

There is already a check for apm_info.bios == 0, the apm_info.bios is set from the boot_params.apm_bios_info. Both Xen and lguest, which are also the only ones that set paravirt_enabled to true) do never set the apm_bios_info, the paravirt_enabled() check is simply not needed. Signed-off-by: Luis

[PATCH v3 06/11] apm32: remove paravirt_enabled() use

There is already a check for apm_info.bios == 0, the apm_info.bios is set from the boot_params.apm_bios_info. Both Xen and lguest, which are also the only ones that set paravirt_enabled to true) do never set the apm_bios_info, the paravirt_enabled() check is simply not needed. Signed-off-by: Luis

[PATCH v3 01/11] x86/boot: enumerate documentation for the x86 hardware_subarch

Although hardware_subarch has been in place since the x86 boot protocol 2.07 it hasn't been used much. Enumerate current possible values to avoid misuses and help with semantics later at boot time should this be used further. v2: fix typos Cc: Andy Shevchenko

[PATCH v3 01/11] x86/boot: enumerate documentation for the x86 hardware_subarch

Although hardware_subarch has been in place since the x86 boot protocol 2.07 it hasn't been used much. Enumerate current possible values to avoid misuses and help with semantics later at boot time should this be used further. v2: fix typos Cc: Andy Shevchenko Signed-off-by: Luis R. Rodriguez

Re: [PATCH v1 8/8] mm: kasan: Initial memory quarantine implementation

On Fri, Feb 19, 2016 at 10:19:48AM +0100, Dmitry Vyukov wrote: > On Fri, Feb 19, 2016 at 3:11 AM, Joonsoo Kim wrote: > > 2016-02-18 23:06 GMT+09:00 Alexander Potapenko : > >> On Mon, Feb 1, 2016 at 3:47 AM, Joonsoo Kim wrote: > >>> On

Re: [PATCH v1 8/8] mm: kasan: Initial memory quarantine implementation

On Fri, Feb 19, 2016 at 10:19:48AM +0100, Dmitry Vyukov wrote: > On Fri, Feb 19, 2016 at 3:11 AM, Joonsoo Kim wrote: > > 2016-02-18 23:06 GMT+09:00 Alexander Potapenko : > >> On Mon, Feb 1, 2016 at 3:47 AM, Joonsoo Kim wrote: > >>> On Wed, Jan 27, 2016 at 07:25:13PM +0100, Alexander Potapenko

[PATCH v3 2/2] mm/page_ref: add tracepoint to track down page reference manipulation

From: Joonsoo Kim CMA allocation should be guaranteed to succeed by definition, but, unfortunately, it would be failed sometimes. It is hard to track down the problem, because it is related to page reference manipulation and we don't have any facility to analyze it. This

[PATCH v3 1/2] mm: introduce page reference manipulation functions

From: Joonsoo Kim Success of CMA allocation largely depends on success of migration and key factor of it is page reference count. Until now, page reference is manipulated by direct calling atomic functions so we cannot follow up who and where manipulate it. Then, it is

[PATCH v3 2/2] mm/page_ref: add tracepoint to track down page reference manipulation

From: Joonsoo Kim CMA allocation should be guaranteed to succeed by definition, but, unfortunately, it would be failed sometimes. It is hard to track down the problem, because it is related to page reference manipulation and we don't have any facility to analyze it. This patch adds tracepoints

[PATCH v3 1/2] mm: introduce page reference manipulation functions

From: Joonsoo Kim Success of CMA allocation largely depends on success of migration and key factor of it is page reference count. Until now, page reference is manipulated by direct calling atomic functions so we cannot follow up who and where manipulate it. Then, it is hard to find actual reason

Re: [RFC/RFT][PATCH 1/1] cpufreq: New governor using utilization data from the scheduler

On 02/22/2016 03:02 PM, Rafael J. Wysocki wrote: >> I guess the first (macro) question is why did you decide to go with a >> complete new governor, where new here is w.r.t. the sched-freq solution. > > Probably the most comprehensive answer to this question is my intro > message:

Re: [RFC/RFT][PATCH 1/1] cpufreq: New governor using utilization data from the scheduler

On 02/22/2016 03:02 PM, Rafael J. Wysocki wrote: >> I guess the first (macro) question is why did you decide to go with a >> complete new governor, where new here is w.r.t. the sched-freq solution. > > Probably the most comprehensive answer to this question is my intro > message:

Re: [PATCH] firmware: set firmware_buf size in fw_get_filesystem_firmware()

On Sat, Feb 20, 2016 at 1:22 AM, Sergey Senozhatsky wrote: > Set firmware_buf->size in fw_get_filesystem_firmware() after > successful kernel_read_file_from_path(), otherwise assign_firmware_buf() > fails. > Acked-by: Bjorn Andersson >

Re: [PATCH] firmware: set firmware_buf size in fw_get_filesystem_firmware()

On Sat, Feb 20, 2016 at 1:22 AM, Sergey Senozhatsky wrote: > Set firmware_buf->size in fw_get_filesystem_firmware() after > successful kernel_read_file_from_path(), otherwise assign_firmware_buf() > fails. > Acked-by: Bjorn Andersson > Signed-off-by: Sergey Senozhatsky > --- >

Re: [PATCH v2 1/2] gpio: designware: switch device node to fwnode

Hi qiujiang, [auto build test ERROR on gpio/for-next] [also build test ERROR on v4.5-rc5 next-20160223] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url:

Re: [PATCH v2 1/2] gpio: designware: switch device node to fwnode

Hi qiujiang, [auto build test ERROR on gpio/for-next] [also build test ERROR on v4.5-rc5 next-20160223] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url:

Re: [PATCH v2 4/4] dmaengine: pxa_dma: fix the maximum requestor line

Vinod Koul writes: > On Mon, Feb 15, 2016 at 09:57:48PM +0100, Robert Jarzmik wrote: >> The current number of requestor lines is limited to 31. This was an >> error of a previous commit, as this number is platform dependent, and is >> actually : >> - for pxa25x: 40

Re: [PATCH v2 4/4] dmaengine: pxa_dma: fix the maximum requestor line

Vinod Koul writes: > On Mon, Feb 15, 2016 at 09:57:48PM +0100, Robert Jarzmik wrote: >> The current number of requestor lines is limited to 31. This was an >> error of a previous commit, as this number is platform dependent, and is >> actually : >> - for pxa25x: 40 requestor lines >> - for

RE: [PATCH] phy: rcar-gen3-usb2: remove HSUSB registers handling

Hi, > Hi, > > On Tuesday 23 February 2016 11:54 AM, Yoshihiro Shimoda wrote: > > Hi Kishon, > > > > Would you review this patch? > > merged it now. Thanks for reminding. Thank you! Best regards, Yoshihiro Shimoda > -Kishon >

RE: [PATCH] phy: rcar-gen3-usb2: remove HSUSB registers handling

Hi, > Hi, > > On Tuesday 23 February 2016 11:54 AM, Yoshihiro Shimoda wrote: > > Hi Kishon, > > > > Would you review this patch? > > merged it now. Thanks for reminding. Thank you! Best regards, Yoshihiro Shimoda > -Kishon >

[PATCH 2/4] dt-bindings: add bindings for rk3399 clock controller

From: Xing Zheng Add devicetree bindings for Rockchip cru which found on Rockchip SoCs. Signed-off-by: Xing Zheng Signed-off-by: Jianqun Xu --- .../bindings/clock/rockchip,rk3399-cru.txt | 82

[PATCH 2/4] dt-bindings: add bindings for rk3399 clock controller

From: Xing Zheng Add devicetree bindings for Rockchip cru which found on Rockchip SoCs. Signed-off-by: Xing Zheng Signed-off-by: Jianqun Xu --- .../bindings/clock/rockchip,rk3399-cru.txt | 82 ++ 1 file changed, 82 insertions(+) create mode 100644

[PATCH 3/4] clk: rockchip: add dt-binding header for rk3399

From: Xing Zheng Add the dt-bindings header for the rk3399, that gets shared between the clock controller and the clock references in the dts. Signed-off-by: Xing Zheng Signed-off-by: Jianqun Xu ---

[PATCH 3/4] clk: rockchip: add dt-binding header for rk3399

From: Xing Zheng Add the dt-bindings header for the rk3399, that gets shared between the clock controller and the clock references in the dts. Signed-off-by: Xing Zheng Signed-off-by: Jianqun Xu --- include/dt-bindings/clock/rk3399-cru.h | 714 + 1 file

[PATCH 1/4] soc: rockchip: add bindings for Rockchip grf

From: Jianqun Xu Add devicetree bindings for Rockchip grf which found on Rockchip SoCs. Signed-off-by: Jianqun Xu --- changes in v2: - add grf.txt (Heiko) .../devicetree/bindings/soc/rockchip/grf.txt | 35 ++ 1 file

[PATCH 1/4] soc: rockchip: add bindings for Rockchip grf

From: Jianqun Xu Add devicetree bindings for Rockchip grf which found on Rockchip SoCs. Signed-off-by: Jianqun Xu --- changes in v2: - add grf.txt (Heiko) .../devicetree/bindings/soc/rockchip/grf.txt | 35 ++ 1 file changed, 35 insertions(+) create mode 100644

[PATCH 0/4] Rockchip: rk3399: Add core dtsi for rk3399

From: Jianqun Xu There is the new SoCs from Rockchip which named rk3399, the patches are added to support them. Jianqun Xu (2): soc: rockchip: add bindings for Rockchip grf ARM64: dts: rockchip: add core dtsi file for rk3399 Xing Zheng (2): dt-bindings: add

[PATCH 4/4] ARM64: dts: rockchip: add core dtsi file for rk3399

From: Jianqun Xu This patch adds core dtsi file for rk3399 found on Rockchip new SoCs rk3399, which integrates dual-core Cortex-A72 and quad-core Cortex-A53 with separately NEON coprocessor. The dtsi file has been tested on rk3399 board with simple boot system, the uart

[PATCH 0/4] Rockchip: rk3399: Add core dtsi for rk3399

From: Jianqun Xu There is the new SoCs from Rockchip which named rk3399, the patches are added to support them. Jianqun Xu (2): soc: rockchip: add bindings for Rockchip grf ARM64: dts: rockchip: add core dtsi file for rk3399 Xing Zheng (2): dt-bindings: add bindings for rk3399 clock

[PATCH 4/4] ARM64: dts: rockchip: add core dtsi file for rk3399

From: Jianqun Xu This patch adds core dtsi file for rk3399 found on Rockchip new SoCs rk3399, which integrates dual-core Cortex-A72 and quad-core Cortex-A53 with separately NEON coprocessor. The dtsi file has been tested on rk3399 board with simple boot system, the uart and spi IPs are same as

Re: [PATCH] arc: get rid of DEVTMPFS dependency on INITRAMFS_SOURCE

On Saturday 20 February 2016 06:35 PM, Alexey Brodkin wrote: > Even though DEVTMPFS is required when our pre-built initramfs > is used it is not the case in general. It is perfectly possible > to use initramfs with device nodes already populated or there > could be other usages, see discussion

Re: [PATCH] arc: get rid of DEVTMPFS dependency on INITRAMFS_SOURCE

On Saturday 20 February 2016 06:35 PM, Alexey Brodkin wrote: > Even though DEVTMPFS is required when our pre-built initramfs > is used it is not the case in general. It is perfectly possible > to use initramfs with device nodes already populated or there > could be other usages, see discussion

[PATCH v2 1/2] gpio: designware: switch device node to fwnode

This patch switch device node to fwnode in dwapb_port_property, so as to apply a unified data structure for DT and ACPI. Acked-by: Mika Westerberg Signed-off-by: qiujiang --- drivers/gpio/gpio-dwapb.c| 36

[PATCH v2 1/2] gpio: designware: switch device node to fwnode

This patch switch device node to fwnode in dwapb_port_property, so as to apply a unified data structure for DT and ACPI. Acked-by: Mika Westerberg Signed-off-by: qiujiang --- drivers/gpio/gpio-dwapb.c| 36

[PATCH v2 0/2] gpio: designware: add gpio-signaled acpi events support

This patchset adds gpio-signaled acpi events support for power button on hisilicon D02 board. The two patches respectively: - switch device_node to unified fwnode handle - adds gpio-signaled acpi events support for power button This patchset is based on

[PATCH v2 0/2] gpio: designware: add gpio-signaled acpi events support

This patchset adds gpio-signaled acpi events support for power button on hisilicon D02 board. The two patches respectively: - switch device_node to unified fwnode handle - adds gpio-signaled acpi events support for power button This patchset is based on

[PATCH v2 2/2] gpio: designware: add gpio-signaled acpi event for power button

This patch modifies the designware gpio controller driver to support the gpio-signaled acpi events. This is used for power button on hisilicon D02 board(an arm64 platform). The corresponding DSDT table is defined as follows: Device(GPI0) { Name(_HID, "HISI0181") Name(_ADR, 0)

[PATCH v2 2/2] gpio: designware: add gpio-signaled acpi event for power button

This patch modifies the designware gpio controller driver to support the gpio-signaled acpi events. This is used for power button on hisilicon D02 board(an arm64 platform). The corresponding DSDT table is defined as follows: Device(GPI0) { Name(_HID, "HISI0181") Name(_ADR, 0)

Re: [PATCH 2/2] ASoC: max9867: fix type of variable containing error codes

2016-02-23 14:45 GMT+08:00 Andrzej Hajda : > value variable can contain error values and is compared with zero. > Its type must be signed. Reviewed-by: Axel Lin

Re: [PATCH 2/2] ASoC: max9867: fix type of variable containing error codes

2016-02-23 14:45 GMT+08:00 Andrzej Hajda : > value variable can contain error values and is compared with zero. > Its type must be signed. Reviewed-by: Axel Lin

Re: [PATCH 8/9] usb: dwc3: Remove impossible check for of_clk_get_parent_count() < 0

Hi, Stephen Boyd writes: > The check for < 0 is impossible now that > of_clk_get_parent_count() returns an unsigned int. Simplify the > code and update the types. > > Cc: Felipe Balbi > Cc: > Signed-off-by: Stephen Boyd

Re: [PATCH 8/9] usb: dwc3: Remove impossible check for of_clk_get_parent_count() < 0

Hi, Stephen Boyd writes: > The check for < 0 is impossible now that > of_clk_get_parent_count() returns an unsigned int. Simplify the > code and update the types. > > Cc: Felipe Balbi > Cc: > Signed-off-by: Stephen Boyd > --- > > Please ack so this can go through clk tree along with patch 1.

[PATCH 1/2] gpio: xgene: fix type of variable containing error codes

ret variable can contain error values and is compared with zero. Its type must be signed. The problem has been detected using coccinelle script scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci Signed-off-by: Andrzej Hajda --- drivers/gpio/gpio-xgene-sb.c | 2 +- 1

[PATCH 1/2] gpio: xgene: fix type of variable containing error codes

ret variable can contain error values and is compared with zero. Its type must be signed. The problem has been detected using coccinelle script scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci Signed-off-by: Andrzej Hajda --- drivers/gpio/gpio-xgene-sb.c | 2 +- 1 file changed, 1

[PATCH 2/2] ASoC: max9867: fix type of variable containing error codes

value variable can contain error values and is compared with zero. Its type must be signed. The problem has been detected using coccinelle script scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci Signed-off-by: Andrzej Hajda --- sound/soc/codecs/max9867.c | 3 ++- 1

[PATCH 2/2] ASoC: max9867: fix type of variable containing error codes

value variable can contain error values and is compared with zero. Its type must be signed. The problem has been detected using coccinelle script scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci Signed-off-by: Andrzej Hajda --- sound/soc/codecs/max9867.c | 3 ++- 1 file changed, 2

Re: [RFC][PATCH 6/7] x86, pkeys: add pkey set/get syscalls

* Dave Hansen wrote: > > From: Dave Hansen > > This establishes two more system calls for protection key management: > > unsigned long pkey_get(int pkey); > int pkey_set(int pkey, unsigned long access_rights); > > The return value

Re: [RFC][PATCH 6/7] x86, pkeys: add pkey set/get syscalls

* Dave Hansen wrote: > > From: Dave Hansen > > This establishes two more system calls for protection key management: > > unsigned long pkey_get(int pkey); > int pkey_set(int pkey, unsigned long access_rights); > > The return value from pkey_get() and the 'access_rights' passed

Re: [RFC][PATCH 7/7] pkeys: add details of system call use to Documentation/

* Dave Hansen wrote: > > From: Dave Hansen > > This spells out all of the pkey-related system calls that we have > and provides some example code fragments to demonstrate how we > expect them to be used. > > Signed-off-by: Dave Hansen

Re: [RFC][PATCH 7/7] pkeys: add details of system call use to Documentation/

* Dave Hansen wrote: > > From: Dave Hansen > > This spells out all of the pkey-related system calls that we have > and provides some example code fragments to demonstrate how we > expect them to be used. > > Signed-off-by: Dave Hansen > Cc: linux-...@vger.kernel.org > Cc:

Re: [PATCH] phy: rcar-gen3-usb2: remove HSUSB registers handling

Hi, On Tuesday 23 February 2016 11:54 AM, Yoshihiro Shimoda wrote: > Hi Kishon, > > Would you review this patch? merged it now. Thanks for reminding. -Kishon > > I checked the latest linux-phy.git / next branch today, > this patch can be applied on the top of branch. > > commit

Re: [PATCH] phy: rcar-gen3-usb2: remove HSUSB registers handling

Hi, On Tuesday 23 February 2016 11:54 AM, Yoshihiro Shimoda wrote: > Hi Kishon, > > Would you review this patch? merged it now. Thanks for reminding. -Kishon > > I checked the latest linux-phy.git / next branch today, > this patch can be applied on the top of branch. > > commit

Re: [LKP] [lkp] [gpio] 3c702e9987: kmsg.user_verbs:couldn't_register_device_number

Linus Walleij writes: > On Mon, Feb 15, 2016 at 3:39 AM, Huang, Ying wrote: >> Michael Welling writes: > >>> Could you run cat /proc/devices? >> >> Sorry, the test mechanism is not flexible enough to run some shell >> command

Re: [LKP] [lkp] [gpio] 3c702e9987: kmsg.user_verbs:couldn't_register_device_number

Linus Walleij writes: > On Mon, Feb 15, 2016 at 3:39 AM, Huang, Ying wrote: >> Michael Welling writes: > >>> Could you run cat /proc/devices? >> >> Sorry, the test mechanism is not flexible enough to run some shell >> command in test system. Could you provide a specialized debug kernel to >>

[PATCH V4 0/4] Transform Fintek PCIE driver from 8250 to MFD

The Fintek F81504/508/512 is a multi-function PCIE devices. IC function list: F81504: Max 2x8 GPIOs and max 4 serial ports port2/3 are multi-function F81508: Max 6x8 GPIOs and max 8 serial ports port2/3 are multi-function, port8/9/10/11 are gpio only F81512: Max 6x8

[PATCH V4 0/4] Transform Fintek PCIE driver from 8250 to MFD

The Fintek F81504/508/512 is a multi-function PCIE devices. IC function list: F81504: Max 2x8 GPIOs and max 4 serial ports port2/3 are multi-function F81508: Max 6x8 GPIOs and max 8 serial ports port2/3 are multi-function, port8/9/10/11 are gpio only F81512: Max 6x8

[PATCH V4 3/4] 8250: 8250_f81504: Add Fintek F81504/508/512 PCIE-to-UART/GPIO UART support

This driver is 8250 driver for F81504/508/512, it'll handle the serial port operation of this device. This module will depend on MFD_FINTEK_F81504_CORE. The serial ports support from 50bps to 1.5Mbps with Linux baudrate define excluding 1.0Mbps due to not support 16MHz clock source. PCI

[PATCH V4 2/4] gpio: gpio-f81504: Add Fintek F81504/508/512 PCIE-to-UART/GPIO GPIOLIB support

This driver is GPIOLIB driver for F81504/508/512, it'll handle the GPIOLIB operation of this device. This module will depend on MFD_FINTEK_F81504_CORE. IC function list: F81504: Max 2x8 GPIOs and max 4 serial ports port2/3 are multi-function F81508: Max 6x8 GPIOs and max 8 serial

  1   2   3   4   5   6   7   8   9   10   >