[PATCH v2] clk: rockchip: Allow sclk_i2s0 and i2s0_frac to change their parents rate on rk3188

[Alexander Kochetkov]

Allow sclk_i2s0 and i2s0_frac to change their parents rate as
that the upstream dividers are purely there to feed sclk_i2s0

Tested on radxarock-lite.

Signed-off-by: Alexander Kochetkov 

Changes in v2:
Rebased on top of 4.5-rc1 of branch[1]

[1] 
https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/log/?h=v4.6-clk/next

---
 drivers/clk/rockchip/clk-rk3188.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/rockchip/clk-rk3188.c 
b/drivers/clk/rockchip/clk-rk3188.c
index cc1d09d..629c65d 100644
--- a/drivers/clk/rockchip/clk-rk3188.c
+++ b/drivers/clk/rockchip/clk-rk3188.c
@@ -666,7 +666,7 @@ PNAME(mux_hsicphy_p)= { 
"sclk_otgphy0_480m", "sclk_otgphy1_480m",
"gpll", "cpll" };
 
 static struct rockchip_clk_branch rk3188_i2s0_fracmux __initdata =
-   MUX(SCLK_I2S0, "sclk_i2s0", mux_sclk_i2s0_p, 0,
+   MUX(SCLK_I2S0, "sclk_i2s0", mux_sclk_i2s0_p, CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(3), 8, 2, MFLAGS);
 
 static struct rockchip_clk_branch rk3188_clk_branches[] __initdata = {
@@ -722,7 +722,7 @@ static struct rockchip_clk_branch rk3188_clk_branches[] 
__initdata = {
COMPOSITE_NOMUX(0, "i2s0_pre", "i2s_src", 0,
RK2928_CLKSEL_CON(3), 0, 7, DFLAGS,
RK2928_CLKGATE_CON(0), 9, GFLAGS),
-   COMPOSITE_FRACMUX(0, "i2s0_frac", "i2s0_pre", 0,
+   COMPOSITE_FRACMUX(0, "i2s0_frac", "i2s0_pre", CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(7), 0,
RK2928_CLKGATE_CON(0), 10, GFLAGS,
_i2s0_fracmux),
-- 
1.7.9.5

Re: [PATCH v3] Platform: goldfish: goldfish_pipe.c: Add DMA support using managed version

[Greg Kroah-Hartman]

On Sat, Jan 23, 2016 at 02:41:25AM +0530, Shraddha Barke wrote:
> setup_access_params_addr has 2 goals-
> 
> -Initialize the access_params field so that it can be used to send and read
> commands from the device in access_with_param
> -Get a bus address for the allocated memory to transfer to the device.
> 
> Replace the combination of devm_kzalloc and _pa() with dmam_alloc_coherent.
> Coherent mapping guarantees that the device and CPU are in sync.
> 
> Signed-off-by: Shraddha Barke 
> ---
> Changes in v3-
>  Both writel in the same style
> Changes in v2-
>  Updated commit message, use upper_32_bits and lower_32_bits
> 
>  drivers/platform/goldfish/goldfish_pipe.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)

Due to some other changes to this file, this doesn't apply to my
char-misc-testing tree.  Can you refresh it based on that and resend?

thanks,

greg k-h

[PATCH v8 1/6] clk: hisilicon: add CRG driver for hi3519 soc

[Jiancheng Xue]

The CRG(Clock and Reset Generator) block provides clock
and reset signals for other modules in hi3519 soc.

Signed-off-by: Jiancheng Xue 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/clock/hi3519-crg.txt   |  46 +++
This binding file is already acked by Rob Herring.
 drivers/clk/hisilicon/Kconfig  |   7 ++
 drivers/clk/hisilicon/Makefile |   2 +
 drivers/clk/hisilicon/clk-hi3519.c | 133 +
 drivers/clk/hisilicon/clk.c|  23 ++--
 drivers/clk/hisilicon/clk.h|  14 +--
 drivers/clk/hisilicon/reset.c  | 130 
 drivers/clk/hisilicon/reset.h  |  32 +
 include/dt-bindings/clock/hi3519-clock.h   |  40 +++
 9 files changed, 412 insertions(+), 15 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/hi3519-crg.txt
 create mode 100644 drivers/clk/hisilicon/clk-hi3519.c
 create mode 100644 drivers/clk/hisilicon/reset.c
 create mode 100644 drivers/clk/hisilicon/reset.h
 create mode 100644 include/dt-bindings/clock/hi3519-clock.h

diff --git a/Documentation/devicetree/bindings/clock/hi3519-crg.txt 
b/Documentation/devicetree/bindings/clock/hi3519-crg.txt
new file mode 100644
index 000..2d23950
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/hi3519-crg.txt
@@ -0,0 +1,46 @@
+* Hisilicon Hi3519 Clock and Reset Generator(CRG)
+
+The Hi3519 CRG module provides clock and reset signals to various
+controllers within the SoC.
+
+This binding uses the following bindings:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+Documentation/devicetree/bindings/reset/reset.txt
+
+Required Properties:
+
+- compatible: should be one of the following.
+  - "hisilicon,hi3519-crg" - controller compatible with Hi3519 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+  region.
+
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes use this identifier
+to specify the clock which they consume.
+
+All these identifier could be found in .
+
+- #reset-cells: should be 2.
+
+A reset signal can be controlled by writing a bit register in the CRG module.
+The reset specifier consists of two cells. The first cell represents the
+register offset relative to the base address. The second cell represents the
+bit index in the register.
+
+Example: CRG nodes
+CRG: clock-reset-controller@1201 {
+   compatible = "hisilicon,hi3519-crg";
+reg = <0x1201 0x1>;
+#clock-cells = <1>;
+#reset-cells = <2>;
+};
+
+Example: consumer nodes
+i2c0: i2c@1211 {
+   compatible = "hisilicon,hi3519-i2c";
+reg = <0x1211 0x1000>;
+clocks = < HI3519_I2C0_RST>;*/
+resets = < 0xe4 0>;
+};
diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
index e434854..2128899 100644
--- a/drivers/clk/hisilicon/Kconfig
+++ b/drivers/clk/hisilicon/Kconfig
@@ -1,3 +1,10 @@
+config COMMON_CLK_HI3519
+   tristate "Hi3519 Clock Driver"
+   depends on ARCH_HISI
+   default y
+   help
+ Build the clock driver for hi3519.
+
 config COMMON_CLK_HI6220
bool "Hi6220 Clock Driver"
depends on ARCH_HISI || COMPILE_TEST
diff --git a/drivers/clk/hisilicon/Makefile b/drivers/clk/hisilicon/Makefile
index 74dba31..3f57b09 100644
--- a/drivers/clk/hisilicon/Makefile
+++ b/drivers/clk/hisilicon/Makefile
@@ -4,8 +4,10 @@
 
 obj-y  += clk.o clkgate-separated.o clkdivider-hi6220.o
 
+obj-$(CONFIG_RESET_CONTROLLER) += reset.o
 obj-$(CONFIG_ARCH_HI3xxx)  += clk-hi3620.o
 obj-$(CONFIG_ARCH_HIP04)   += clk-hip04.o
 obj-$(CONFIG_ARCH_HIX5HD2) += clk-hix5hd2.o
 obj-$(CONFIG_COMMON_CLK_HI6220)+= clk-hi6220.o
 obj-$(CONFIG_STUB_CLK_HI6220)  += clk-hi6220-stub.o
+obj-$(CONFIG_COMMON_CLK_HI3519)+= clk-hi3519.o
diff --git a/drivers/clk/hisilicon/clk-hi3519.c 
b/drivers/clk/hisilicon/clk-hi3519.c
new file mode 100644
index 000..ed983af
--- /dev/null
+++ b/drivers/clk/hisilicon/clk-hi3519.c
@@ -0,0 +1,133 @@
+/*
+ * Hi3519 Clock Driver
+ *
+ * Copyright (c) 2015-2016 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 

[PATCH v8 4/6] ARM: debug: add hi3519 debug uart

[Jiancheng Xue]

add hi3519 debug uart

Signed-off-by: Jiancheng Xue 
---
 arch/arm/Kconfig.debug | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index c6b6175..edd3fbe 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -260,6 +260,14 @@ choice
  Say Y here if you want kernel low-level debugging support
  on Cortina Gemini based platforms.
 
+   config DEBUG_HI3519_UART
+   bool "Hisilicon HI3519 Debug UART"
+   depends on ARCH_HISI
+   select DEBUG_UART_PL01X
+   help
+ Say Y here if you want kernel low-level debugging support
+ on HI3519 UART.
+
config DEBUG_HI3620_UART
bool "Hisilicon HI3620 Debug UART"
depends on ARCH_HI3xxx
@@ -1451,6 +1459,7 @@ config DEBUG_UART_PHYS
default 0x11002000 if DEBUG_MT8127_UART0
default 0x11006000 if DEBUG_MT6589_UART0
default 0x11009000 if DEBUG_MT8135_UART3
+   default 0x1210 if DEBUG_HI3519_UART
default 0x1600 if DEBUG_INTEGRATOR
default 0x18000300 if DEBUG_BCM_5301X
default 0x1801 if DEBUG_SIRFATLAS7_UART0
@@ -1619,6 +1628,7 @@ config DEBUG_UART_VIRT
default 0xfee2 if DEBUG_NSPIRE_CLASSIC_UART || DEBUG_NSPIRE_CX_UART
default 0xfee82340 if ARCH_IOP13XX
default 0xfef0 if ARCH_IXP4XX && !CPU_BIG_ENDIAN
+   default 0xfef0 if DEBUG_HI3519_UART
default 0xfef3 if ARCH_IXP4XX && CPU_BIG_ENDIAN
default 0xfef36000 if DEBUG_HIGHBANK_UART
default 0xfefb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
-- 
1.9.1

[PATCH v8 0/6] ARM: hisi: Add initial support including clock driver for Hi3519 soc.

[Jiancheng Xue]

Hello,

Hi3519 soc is mainly used for ip camera and sport DV solutions. This patchset 
adds initial support
for Hi3519 soc. It includes clock driver, arch configuration, debug uart 
configuration and device tree.
It has been tested on hi3519 reference board.

Any comments will be appreciated!

Thanks!

Change Log
--
v8:
--Made hi3519 clock driver can be compiled as a module
--Fixed an issue in arch/arm/Kconfig.debug

v7:
--Rebase to v4.5-rc1

v6:
-Change clock driver to a real platform driver

v5:
-Adjust clock and reset controller driver code

v4:
-Rebase to v4.4-rc7
-Divide patches according to Rob's comments
-Add spi nodes in hi3519-demb.dts

v3:
-Rebase to v4.4-rc4
-Adjust according to Arnd's comments
-Remove ARCH_HI3519, using ARCH_HISI directly

v2:
-Rebase to v4.4-rc3
-Put dt-binding doc and header file in a separate patch.
-Delete unused clocks definitions.
-Adjust the ARCH_xxx order in Kconfig file
-Rename ARCH_HI3xxx to ARCH_36xx

Jiancheng Xue (6):
  clk: hisilicon: add CRG driver for hi3519 soc
  ARM: hisi: add compatible string for Hi3519 soc
  ARM: config: hisi: enable CONFIG_RESET_CONTROLLER
  ARM: debug: add hi3519 debug uart
  ARM: dt-bindings: add device tree bindings for Hi3519 sysctrl
  ARM: dts: add dts files for Hi3519

 .../bindings/arm/hisilicon/hi3519-sysctrl.txt  |  14 ++
 .../devicetree/bindings/clock/hi3519-crg.txt   |  46 +
 arch/arm/Kconfig.debug |  10 ++
 arch/arm/boot/dts/Makefile |   2 +
 arch/arm/boot/dts/hi3519-demb.dts  |  42 +
 arch/arm/boot/dts/hi3519.dtsi  | 187 +
 arch/arm/configs/hisi_defconfig|   1 +
 arch/arm/mach-hisi/hisilicon.c |  23 +--
 drivers/clk/hisilicon/Kconfig  |   7 +
 drivers/clk/hisilicon/Makefile |   2 +
 drivers/clk/hisilicon/clk-hi3519.c | 133 +++
 drivers/clk/hisilicon/clk.c|  23 ++-
 drivers/clk/hisilicon/clk.h|  14 +-
 drivers/clk/hisilicon/reset.c  | 130 ++
 drivers/clk/hisilicon/reset.h  |  32 
 include/dt-bindings/clock/hi3519-clock.h   |  40 +
 16 files changed, 672 insertions(+), 34 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/hisilicon/hi3519-sysctrl.txt
 create mode 100644 Documentation/devicetree/bindings/clock/hi3519-crg.txt
 create mode 100644 arch/arm/boot/dts/hi3519-demb.dts
 create mode 100644 arch/arm/boot/dts/hi3519.dtsi
 create mode 100644 drivers/clk/hisilicon/clk-hi3519.c
 create mode 100644 drivers/clk/hisilicon/reset.c
 create mode 100644 drivers/clk/hisilicon/reset.h
 create mode 100644 include/dt-bindings/clock/hi3519-clock.h

-- 
1.9.1

[PATCH v8 3/6] ARM: config: hisi: enable CONFIG_RESET_CONTROLLER

[Jiancheng Xue]

enable CONFIG_RESET_CONTROLLER in hisi_defconfig

Signed-off-by: Jiancheng Xue 
---
 arch/arm/configs/hisi_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/hisi_defconfig b/arch/arm/configs/hisi_defconfig
index b2e340b..ba62c07 100644
--- a/arch/arm/configs/hisi_defconfig
+++ b/arch/arm/configs/hisi_defconfig
@@ -75,6 +75,7 @@ CONFIG_DMADEVICES=y
 CONFIG_DW_DMAC=y
 CONFIG_PL330_DMA=y
 CONFIG_PWM=y
+CONFIG_RESET_CONTROLLER=y
 CONFIG_PHY_HIX5HD2_SATA=y
 CONFIG_EXT4_FS=y
 CONFIG_TMPFS=y
-- 
1.9.1

[PATCH v8 2/6] ARM: hisi: add compatible string for Hi3519 soc

[Jiancheng Xue]

add compatible string for Hi3519 soc.

Signed-off-by: Jiancheng Xue 
---
 arch/arm/mach-hisi/hisilicon.c | 23 ---
 1 file changed, 4 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-hisi/hisilicon.c b/arch/arm/mach-hisi/hisilicon.c
index 8cc6215..00dae89 100644
--- a/arch/arm/mach-hisi/hisilicon.c
+++ b/arch/arm/mach-hisi/hisilicon.c
@@ -54,30 +54,15 @@ DT_MACHINE_START(HI3620, "Hisilicon Hi3620 (Flattened 
Device Tree)")
.dt_compat  = hi3xxx_compat,
 MACHINE_END
 
-static const char *const hix5hd2_compat[] __initconst = {
+static const char *const hisilicon_compat[] __initconst = {
"hisilicon,hix5hd2",
-   NULL,
-};
-
-DT_MACHINE_START(HIX5HD2_DT, "Hisilicon HIX5HD2 (Flattened Device Tree)")
-   .dt_compat  = hix5hd2_compat,
-MACHINE_END
-
-static const char *const hip04_compat[] __initconst = {
"hisilicon,hip04-d01",
-   NULL,
-};
-
-DT_MACHINE_START(HIP04, "Hisilicon HiP04 (Flattened Device Tree)")
-   .dt_compat  = hip04_compat,
-MACHINE_END
-
-static const char *const hip01_compat[] __initconst = {
"hisilicon,hip01",
"hisilicon,hip01-ca9x2",
+   "hisilicon,hi3519",
NULL,
 };
 
-DT_MACHINE_START(HIP01, "Hisilicon HIP01 (Flattened Device Tree)")
-   .dt_compat  = hip01_compat,
+DT_MACHINE_START(HISILICON_DT, "HiSilicon Soc")
+   .dt_compat  = hisilicon_compat,
 MACHINE_END
-- 
1.9.1

[PATCH v8 5/6] ARM: dt-bindings: add device tree bindings for Hi3519 sysctrl

[Jiancheng Xue]

Add device tree bindings for Hi3519 system controller.

Signed-off-by: Jiancheng Xue 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/arm/hisilicon/hi3519-sysctrl.txt   | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/hisilicon/hi3519-sysctrl.txt

diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hi3519-sysctrl.txt 
b/Documentation/devicetree/bindings/arm/hisilicon/hi3519-sysctrl.txt
new file mode 100644
index 000..115c5be
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/hisilicon/hi3519-sysctrl.txt
@@ -0,0 +1,14 @@
+* Hisilicon Hi3519 System Controller Block
+
+This bindings use the following binding:
+Documentation/devicetree/bindings/mfd/syscon.txt
+
+Required properties:
+- compatible: "hisilicon,hi3519-sysctrl".
+- reg: the register region of this block
+
+Examples:
+sysctrl: system-controller@1201 {
+   compatible = "hisilicon,hi3519-sysctrl", "syscon";
+   reg = <0x1201 0x1000>;
+};
-- 
1.9.1

Re: [RFC 3/3] CMDQ: Mediatek CMDQ driver

[Horng-Shyang Liao]

Hi Dan,

Many thanks for your comments and time.
I reply my plan inline.


On Thu, 2016-01-28 at 12:49 +0800, Daniel Kurtz wrote:
> Hi HS,
> 
> Sorry for the delay.  It is hard to find time to review a >3700 line
> driver :-o in detail
> 
> Some review comments inline, although I still do not completely
> understand how all that this driver does and how it works.
> I'll try to find time to go through this driver in detail again next
> time you post it for review.
> 
> On Tue, Jan 19, 2016 at 9:14 PM,   wrote:
> > From: HS Liao 
> >
> > This patch is first version of Mediatek Command Queue(CMDQ) driver. The
> > CMDQ is used to help read/write registers with critical time limitation,
> > such as updating display configuration during the vblank. It controls
> > Global Command Engine (GCE) hardware to achieve this requirement.
> > Currently, CMDQ only supports display related hardwares, but we expect
> > it can be extended to other hardwares for future requirements.
> >
> > Signed-off-by: HS Liao 
> 
> [snip]
> 
> > diff --git a/drivers/soc/mediatek/mtk-cmdq.c 
> > b/drivers/soc/mediatek/mtk-cmdq.c
> > new file mode 100644
> > index 000..7570f00
> > --- /dev/null
> > +++ b/drivers/soc/mediatek/mtk-cmdq.c
> 
> [snip]
> 
> > +/*
> > + * Maximum prefetch buffer size.
> > + * Unit is instructions.
> > + */
> > +#define CMDQ_MAX_PREFETCH_INSTUCTION   240
> 
> INSTRUCTION

will fix

> [snip]
> 
> > +
> > +/* get lsb for subsys encoding in arg_a (range: 0 - 31) */
> > +
> > +enum cmdq_eng {
> > +   CMDQ_ENG_DISP_UFOE = 0,
> > +   CMDQ_ENG_DISP_AAL,
> > +   CMDQ_ENG_DISP_COLOR0,
> > +   CMDQ_ENG_DISP_COLOR1,
> > +   CMDQ_ENG_DISP_RDMA0,
> > +   CMDQ_ENG_DISP_RDMA1,
> > +   CMDQ_ENG_DISP_RDMA2,
> > +   CMDQ_ENG_DISP_WDMA0,
> > +   CMDQ_ENG_DISP_WDMA1,
> > +   CMDQ_ENG_DISP_OVL0,
> > +   CMDQ_ENG_DISP_OVL1,
> > +   CMDQ_ENG_DISP_GAMMA,
> > +   CMDQ_ENG_DISP_DSI0_CMD,
> > +   CMDQ_ENG_DISP_DSI1_CMD,
> 
> Why do these last two have "_CMD" at the end?

will remove

> > +   CMDQ_MAX_ENGINE_COUNT   /* ALWAYS keep at the end */
> > +};
> > +
> > +struct cmdq_command {
> > +   struct cmdq *cqctx;
> > +   u32 scenario;
> > +   /* task priority (NOT HW thread priority) */
> > +   u32 priority;
> > +   /* bit flag of used engines */
> > +   u64 engine_flag;
> > +   /*
> > +* pointer of instruction buffer
> > +* This must point to an 64-bit aligned u32 array
> > +*/
> > +   u32 *va_base;
> 
> All of your "va" and "va_base" should be void *, not u32 *.

will do

> > +   /* size of instruction buffer, in bytes. */
> > +   u32 block_size;
> 
> Better to use size_t for "size in bytes".

will fix

> > +};
> > +
> > +enum cmdq_code {
> > +   /* These are actual HW op code. */
> > +   CMDQ_CODE_MOVE = 0x02,
> > +   CMDQ_CODE_WRITE = 0x04,
> > +   CMDQ_CODE_JUMP = 0x10,
> > +   CMDQ_CODE_WFE = 0x20,   /* wait for event (and clear) */
> > +   CMDQ_CODE_CLEAR_EVENT = 0x21,   /* clear event */
> > +   CMDQ_CODE_EOC = 0x40,   /* end of command */
> > +};
> > +
> > +enum cmdq_task_state {
> > +   TASK_STATE_IDLE,/* free task */
> > +   TASK_STATE_BUSY,/* task running on a thread */
> > +   TASK_STATE_KILLED,  /* task process being killed */
> > +   TASK_STATE_ERROR,   /* task execution error */
> > +   TASK_STATE_DONE,/* task finished */
> > +   TASK_STATE_WAITING, /* allocated but waiting for available 
> > thread */
> > +};
> > +
> > +struct cmdq_cmd_buf {
> > +   atomic_tused;
> > +   void*va;
> > +   dma_addr_t  pa;
> > +};
> > +
> > +struct cmdq_task_cb {
> > +   /* called by isr */
> > +   cmdq_async_flush_cb isr_cb;
> > +   void*isr_data;
> > +   /* called by releasing task */
> > +   cmdq_async_flush_cb done_cb;
> > +   void*done_data;
> > +};
> > +
> > +struct cmdq_task {
> > +   struct cmdq *cqctx;
> > +   struct list_headlist_entry;
> > +
> > +   /* state for task life cycle */
> > +   enum cmdq_task_statetask_state;
> > +   /* virtual address of command buffer */
> > +   u32 *va_base;
> > +   /* physical address of command buffer */
> > +   dma_addr_t  mva_base;
> > +   /* size of allocated command buffer */
> > +   u32 buf_size;
> 
> size_t

will fix

> > +   /* It points to a cmdq_cmd_buf if this task use command buffer 
> > pool. */
> > +   struct cmdq_cmd_buf *cmd_buf;
> > +
> > +   int scenario;
> > +   int priority;
> > +   u64 engine_flag;
> > +   u32   

Re: [PATCH v2] i2c: mt8173: add 4GB mode support in i2c driver.

[Daniel Kurtz]

On Fri, Jan 29, 2016 at 7:06 AM, Liguo Zhang  wrote:
> If 4GB mode is enable, we should add 4gb mode support in i2c driver.
> Set 4GB mode register to support 4GB mode.
>
> Signed-off-by: Liguo Zhang 
> ---
> change in v2:
> Define a static inline funtion mtk_i2c_set_4g_mode() for support 4g mode.
> ---
>  drivers/i2c/busses/i2c-mt65xx.c | 51 
> +
>  1 file changed, 51 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
> index aec8e6c..f5734e6 100644
> --- a/drivers/i2c/busses/i2c-mt65xx.c
> +++ b/drivers/i2c/busses/i2c-mt65xx.c
> @@ -60,6 +60,7 @@
>  #define I2C_DMA_INT_FLAG_NONE  0x
>  #define I2C_DMA_CLR_FLAG   0x
>  #define I2C_DMA_HARD_RST   0x0002
> +#define I2C_DMA_4G_MODE0x0001
>
>  #define I2C_DEFAULT_SPEED  10  /* hz */
>  #define MAX_FS_MODE_SPEED  40
> @@ -88,6 +89,8 @@ enum DMA_REGS_OFFSET {
> OFFSET_RX_MEM_ADDR = 0x20,
> OFFSET_TX_LEN = 0x24,
> OFFSET_RX_LEN = 0x28,
> +   OFFSET_TX_4G_MODE = 0x54,
> +   OFFSET_RX_4G_MODE = 0x58,
>  };
>
>  enum i2c_trans_st_rs {
> @@ -133,6 +136,7 @@ struct mtk_i2c_compatible {
> unsigned char dcm: 1;
> unsigned char auto_restart: 1;
> unsigned char aux_len_reg: 1;
> +   unsigned char support_33bits: 1;
>  };
>
>  struct mtk_i2c {
> @@ -182,6 +186,7 @@ static const struct mtk_i2c_compatible mt6577_compat = {
> .dcm = 1,
> .auto_restart = 0,
> .aux_len_reg = 0,
> +   .support_33bits = 0,
>  };
>
>  static const struct mtk_i2c_compatible mt6589_compat = {
> @@ -190,6 +195,7 @@ static const struct mtk_i2c_compatible mt6589_compat = {
> .dcm = 0,
> .auto_restart = 0,
> .aux_len_reg = 0,
> +   .support_33bits = 0,
>  };
>
>  static const struct mtk_i2c_compatible mt8173_compat = {
> @@ -198,6 +204,7 @@ static const struct mtk_i2c_compatible mt8173_compat = {
> .dcm = 1,
> .auto_restart = 1,
> .aux_len_reg = 1,
> +   .support_33bits = 1,
>  };
>
>  static const struct of_device_id mtk_i2c_of_match[] = {
> @@ -366,6 +373,30 @@ static int mtk_i2c_set_speed(struct mtk_i2c *i2c, 
> unsigned int parent_clk,
> return 0;
>  }
>
> +static inline void mtk_i2c_set_4g_mode(struct mtk_i2c *i2c, dma_addr_t 
> wpaddr,
> +  dma_addr_t rpaddr)
> +{
> +   u32 reg_4g_mode;
> +
> +   if (i2c->op == I2C_MASTER_RD) {
> +   reg_4g_mode = (rpaddr & 0x1ULL) ? I2C_DMA_4G_MODE :
> +  I2C_DMA_CLR_FLAG;\

Sorry, I just meant to inline the computation of reg_4g_mode:

static u32 mtk_i2c_4g_mode(dma_addr_t addr)
{
  return (addr & BIT(33)) ? I2C_DMA_4G_MODE : I2C_DMA_CLR_FLAG;
}


> +   writel(reg_4g_mode, i2c->pdmabase + OFFSET_RX_4G_MODE);
> +   } else if (i2c->op == I2C_MASTER_WR) {
> +   reg_4g_mode = (wpaddr & 0x1ULL) ? I2C_DMA_4G_MODE :
> +  I2C_DMA_CLR_FLAG;
> +   writel(reg_4g_mode, i2c->pdmabase + OFFSET_TX_4G_MODE);
> +   } else {
> +   reg_4g_mode = (wpaddr & 0x1ULL) ? I2C_DMA_4G_MODE :
> +  I2C_DMA_CLR_FLAG;
> +   writel(reg_4g_mode, i2c->pdmabase + OFFSET_TX_4G_MODE);
> +
> +   reg_4g_mode = (rpaddr & 0x1ULL) ? I2C_DMA_4G_MODE :
> +  I2C_DMA_CLR_FLAG;
> +   writel(reg_4g_mode, i2c->pdmabase + OFFSET_RX_4G_MODE);
> +   }
> +}
> +
>  static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
>int num, int left_num)
>  {
> @@ -439,6 +470,10 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, 
> struct i2c_msg *msgs,
> msgs->len, DMA_FROM_DEVICE);
> if (dma_mapping_error(i2c->dev, rpaddr))
> return -ENOMEM;
> +
> +   if (i2c->dev_comp->support_33bits)
> +   mtk_i2c_set_4g_mode(i2c, 0, rpaddr);
> +
> writel((u32)rpaddr, i2c->pdmabase + OFFSET_RX_MEM_ADDR);
> writel(msgs->len, i2c->pdmabase + OFFSET_RX_LEN);
> } else if (i2c->op == I2C_MASTER_WR) {
> @@ -448,6 +483,10 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, 
> struct i2c_msg *msgs,
> msgs->len, DMA_TO_DEVICE);
> if (dma_mapping_error(i2c->dev, wpaddr))
> return -ENOMEM;
> +
> +   if (i2c->dev_comp->support_33bits)
> +   mtk_i2c_set_4g_mode(i2c, wpaddr, 0);
> +
> writel((u32)wpaddr, i2c->pdmabase + OFFSET_TX_MEM_ADDR);
> writel(msgs->len, i2c->pdmabase + OFFSET_TX_LEN);
> } else {
> @@ -465,6 +504,10 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, 
> 

Re: [PATCH RFC] Introduce new security.nscapability xattr

[Serge E. Hallyn]

On Wed, Jan 27, 2016 at 04:36:02PM -0800, Andy Lutomirski wrote:
> On Wed, Jan 27, 2016 at 9:22 AM, Jann Horn  wrote:
> > I think it sounds good from a security perspective.
> 
> I'm a bit late to the game, but I have a question: why should this be
> keyed to the *root* uid of the namespace in particular?  Certainly if
> user foo trusts the cap bits on some file, then user foo might trust
> those caps to be exerted over any namespace that user foo owns, since
> user foo owns the namespace.

...  Tying it to a kuid which represents the userns->owner of any
namespace in which the capability will be honored might be fine
with me.  Is that what you mean?  So if uid 1000 creates a userns
mapping uids 10-20, and 10 in that container puts X=pe
on /bin/foo, uid 101000 in that container runs /bin/foo with privilege
X.  Uid 101000 in someone else's container does not.

Although, if I create two containers and provide them different
uidmaps, it may well be because I want them segragated and want
to minimize the changes of one container breaking out into the
other.  This risks breaking that.

> But another option would be to include a list of uids and gids such
> that the cap bits on the file are trusted by any namespace that maps
> only uids and gids in the list.  After all, the existence of a
> namespace with root user foo that also maps bar and baz along with a
> file with caps set means that, if baz can get to the file and
> permissions are set appropriately, then baz now owns bar (via any
> number of fs-related capabilities).  So maybe bar and baz should have
> to be listed as well.
> 
> But maybe this doesn't matter.
> 
> In any event, at the end of the day, the right answer to all of this
> is to stop using setuid and stop using cap bits too and start using
> privileged daemons or other things that don't use the eternally
> fragile grant-privilege-on-execve mechanisms.

Heh, that's why I wrote a p9auth driver a few years ago, but it
was too early for such a thing.

[lkp] [wext] 6a9a24baba: BUG: spinlock bad magic on CPU#0, swapper/0/1

[kernel test robot]

FYI, we noticed the below changes on

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit 6a9a24baba28599b0bb8453ae6a6a06ad79701a0 ("wext: fix message 
delay/ordering")


[0.821194] e820: reserve RAM buffer [mem 0x167e-0x17ff]
[0.823299] NET: Registered protocol family 23
[0.823299] NET: Registered protocol family 23
[0.824526] BUG: spinlock bad magic on CPU#0, swapper/0/1
[0.824526] BUG: spinlock bad magic on CPU#0, swapper/0/1
[0.826041]  lock: init_net+0xe78/0xf00, .magic: , .owner: 
swapper/0/1, .owner_cpu: 0
[0.826041]  lock: init_net+0xe78/0xf00, .magic: , .owner: 
swapper/0/1, .owner_cpu: 0
[0.828388] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-03435-g6a9a24b #1
[0.828388] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-03435-g6a9a24b #1
[0.830342] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[0.830342] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[0.832868]  886ed7f8
[0.832868]  886ed7f8 8800131b7d88 8800131b7d88 
87eb8f86 87eb8f86 8800131b2040 8800131b2040

[0.835143]  8800131b7da8
[0.835143]  8800131b7da8 87d25897 87d25897 
886ed7f8 886ed7f8 886ed7f8 886ed7f8

[0.837376]  8800131b7dc0
[0.837376]  8800131b7dc0 87d25b10 87d25b10 
0286 0286 8800131b7de0 8800131b7de0

[0.842451] Call Trace:
[0.842451] Call Trace:
[0.843040]  [] dump_stack+0x4b/0x63
[0.843040]  [] dump_stack+0x4b/0x63
[0.844370]  [] spin_dump+0x78/0xbb
[0.844370]  [] spin_dump+0x78/0xbb
[0.845662]  [] do_raw_spin_unlock+0x64/0xba
[0.845662]  [] do_raw_spin_unlock+0x64/0xba
[0.847114]  [] _raw_spin_unlock_irqrestore+0x2c/0x5d
[0.847114]  [] _raw_spin_unlock_irqrestore+0x2c/0x5d
[0.848654]  [] skb_dequeue+0x59/0x67
[0.848654]  [] skb_dequeue+0x59/0x67
[0.849874]  [] wireless_nlevent_flush+0x54/0x8d
[0.849874]  [] wireless_nlevent_flush+0x54/0x8d
[0.851321]  [] wext_netdev_notifier_call+0xe/0x15
[0.851321]  [] wext_netdev_notifier_call+0xe/0x15
[0.853020]  [] register_netdevice_notifier+0x8a/0x1b9
[0.853020]  [] register_netdevice_notifier+0x8a/0x1b9
[0.854689]  [] ? wext_pernet_init+0x4a/0x4a
[0.854689]  [] ? wext_pernet_init+0x4a/0x4a
[0.856159]  [] wireless_nlevent_init+0x10/0x22
[0.856159]  [] wireless_nlevent_init+0x10/0x22
[0.857556]  [] do_one_initcall+0xb3/0x1fa
[0.857556]  [] do_one_initcall+0xb3/0x1fa
[0.858853]  [] ? parse_args+0x26b/0x4c4
[0.858853]  [] ? parse_args+0x26b/0x4c4
[0.860344]  [] kernel_init_freeable+0x10f/0x194
[0.860344]  [] kernel_init_freeable+0x10f/0x194
[0.861889]  [] ? rest_init+0xcc/0xcc
[0.861889]  [] ? rest_init+0xcc/0xcc
[0.863210]  [] kernel_init+0xe/0xde
[0.863210]  [] kernel_init+0xe/0xde
[0.864587]  [] ret_from_fork+0x3f/0x70
[0.864587]  [] ret_from_fork+0x3f/0x70
[0.866178]  [] ? rest_init+0xcc/0xcc
[0.866178]  [] ? rest_init+0xcc/0xcc
[0.867927] HPET: 3 timers in total, 0 timers will be used for per-cpu timer
[0.867927] HPET: 3 timers in total, 0 timers will be used for per-cpu timer
[0.870286] clocksource: Switched to clocksource kvm-clock


Thanks,
Kernel Test Robot
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.4.0 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# 

Re: [PATCH] pinctrl: nomadik: hide unused functions

[Uwe Kleine-König]

Hello Arnd,

On Mon, Jan 25, 2016 at 04:59:09PM +0100, Arnd Bergmann wrote:
> The nomadik pinctrl driver has two functions that are only used
> for debugfs output and are otherwise unused:
> 
> drivers/pinctrl/nomadik/pinctrl-abx500.c:194:12: error: 
> 'abx500_get_pull_updown' defined but not used
> drivers/pinctrl/nomadik/pinctrl-abx500.c:471:12: error: 'abx500_get_mode' 
> defined but not used
> 
> This makes the function definitions conditional to avoid the
> harmless warnings.
> [...]
> +#ifdef CONFIG_DEBUG_FS
>  static int abx500_get_pull_updown(struct abx500_pinctrl *pct, int offset,
> enum abx500_gpio_pull_updown *pull_updown)

an alternative is to mark the functions with __maybe_unused. I just
noticed that Documentation/CodingStyle even mandates to use that instead
of cpp stuff.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Re: [PATCH v5 00/12] MADV_FREE support

[Minchan Kim]

Hello Michael,

On Thu, Jan 28, 2016 at 08:16:25AM +0100, Michael Kerrisk (man-pages) wrote:
> Hello Minchan,
> 
> On 11/30/2015 07:39 AM, Minchan Kim wrote:
> > In v4, Andrew wanted to settle in old basic MADV_FREE and introduces
> > new stuffs(ie, lazyfree LRU, swapless support and lazyfreeness) later
> > so this version doesn't include them.
> > 
> > I have been tested it on mmotm-2015-11-25-17-08 with additional
> > patch[1] from Kirill to prevent BUG_ON which he didn't send to
> > linux-mm yet as formal patch. With it, I couldn't find any
> > problem so far.
> > 
> > Note that this version is based on THP refcount redesign so
> > I needed some modification on MADV_FREE because split_huge_pmd
> > doesn't split a THP page any more and pmd_trans_huge(pmd) is not
> > enough to guarantee the page is not THP page.
> > As well, for MAVD_FREE lazy-split, THP split should respect
> > pmd's dirtiness rather than marking ptes of all subpages dirty
> > unconditionally. Please, review last patch in this patchset.
> 
> Now that MADV_FREE has been merged, would you be willing to write
> patch to the madvise(2) man page that describes the semantics, 
> noes limitations and restrictions, and (ideally) has some sentences
> describing use cases?

I will try next week.
Thanks for the heads up.

> 
> Thanks,
> 
> Michael
> 
> 
> > mm: don't split THP page when syscall is called
> > 
> > [1] https://lkml.org/lkml/2015/11/17/134
> > 
> > git: git://git.kernel.org/pub/scm/linux/kernel/git/minchan/linux.git
> > branch: mm/madv_free-v4.4-rc2-mmotm-2015-11-25-17-08-v5r2
> > 
> > In this stage, I don't think we need to write man page.
> > It could be done after solid policy and implementation.
> > 
> >  * Change from v4
> >* drop lazyfree LRU
> >* drop swapless support
> >* drop lazyfreeness
> >* rebase on recent mmotom with THP refcount redesign
> > 
> >  * Change from v3
> >* some bug fix
> >* code refactoring
> >* lazyfree reclaim logic change
> >* reordering patch
> > 
> >  * Change from v2
> >* vm_lazyfreeness tuning knob
> >* add new LRU list - Johannes, Shaohua
> >* support swapless - Johannes
> > 
> >  * Change from v1
> >* Don't do unnecessary TLB flush - Shaohua
> >* Added Acked-by - Hugh, Michal
> >* Merge deactivate_page and deactivate_file_page
> >* Add pmd_dirty/pmd_mkclean patches for several arches
> >* Add lazy THP split patch
> >* Drop zhangyan...@cn.fujitsu.com - Delivery Failure
> > 
> > Chen Gang (1):
> >   arch: uapi: asm: mman.h: Let MADV_FREE have same value for all
> > architectures
> > 
> > Minchan Kim (11):
> >   mm: support madvise(MADV_FREE)
> >   mm: define MADV_FREE for some arches
> >   mm: free swp_entry in madvise_free
> >   mm: move lazily freed pages to inactive list
> >   mm: mark stable page dirty in KSM
> >   x86: add pmd_[dirty|mkclean] for THP
> >   sparc: add pmd_[dirty|mkclean] for THP
> >   powerpc: add pmd_[dirty|mkclean] for THP
> >   arm: add pmd_mkclean for THP
> >   arm64: add pmd_mkclean for THP
> >   mm: don't split THP page when syscall is called
> > 
> >  arch/alpha/include/uapi/asm/mman.h   |   2 +
> >  arch/arm/include/asm/pgtable-3level.h|   1 +
> >  arch/arm64/include/asm/pgtable.h |   1 +
> >  arch/mips/include/uapi/asm/mman.h|   2 +
> >  arch/parisc/include/uapi/asm/mman.h  |   2 +
> >  arch/powerpc/include/asm/pgtable-ppc64.h |   2 +
> >  arch/sparc/include/asm/pgtable_64.h  |   9 ++
> >  arch/x86/include/asm/pgtable.h   |   5 +
> >  arch/xtensa/include/uapi/asm/mman.h  |   2 +
> >  include/linux/huge_mm.h  |   3 +
> >  include/linux/rmap.h |   1 +
> >  include/linux/swap.h |   1 +
> >  include/linux/vm_event_item.h|   1 +
> >  include/uapi/asm-generic/mman-common.h   |   1 +
> >  mm/huge_memory.c |  87 +-
> >  mm/ksm.c |   6 +
> >  mm/madvise.c | 199 
> > +++
> >  mm/rmap.c|   8 ++
> >  mm/swap.c|  44 +++
> >  mm/swap_state.c  |   5 +-
> >  mm/vmscan.c  |  10 +-
> >  mm/vmstat.c  |   1 +
> >  22 files changed, 383 insertions(+), 10 deletions(-)
> > 
> 
> 
> -- 
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/

[PATCH] drivers/rtc: broken link fix

[Leslie Lau]

In drivers/rtc/rtc-rx8025.c is a broken link that is supposed to
lead to a form allowing users to subscribe to the lm-sensors mailing list.

The link  leads
to a page with a 404 error. I believe the link should be replaced
with .

Signed-off-by: Leslie Lau 
---
 drivers/rtc/rtc-rx8025.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-rx8025.c b/drivers/rtc/rtc-rx8025.c
index bd911ba..85df3b4 100644
--- a/drivers/rtc/rtc-rx8025.c
+++ b/drivers/rtc/rtc-rx8025.c
@@ -7,7 +7,7 @@
  * All rights reserved.
  *
  * Modified by fengjh at rising.com.cn
- * 
+ * 
  * 2006.11
  *
  * Code cleanup by Sergei Poselenov, 
--
2.5.0

Re: [PATCH] zram: export the number of available comp streams

[Minchan Kim]

Hello Sergey,

Sorry to late response. Thesedays, I'm really busy with personal
stuff.

Today, I have thought about this patch and have several questions.
Let's start with simple questions.

On Tue, Jan 26, 2016 at 09:03:59PM +0900, Sergey Senozhatsky wrote:
> I've been asked several very simple questions:
> a) How can I ensure that zram uses (or used) several compression
>streams?

Why does he want to ensure several compression streams?
As you know well, zram handle it dynamically.

If zram cannot allocate more streams, it means the system is
heavily fragmented or memory pressure at that time so there
is no worth to add more stream, I think.

Could you elaborate it more why he want to know it and what
he expect from that?

> b) What is the current number of comp streams (how much memory
>does zram *actually* use for compression streams, if there are
>more than one stream)?

Hmm, in the kernel, there are lots of example subsystem
we cannot know exact memory usage. Why does the user want
to know exact memory usage of zram? What is his concern?

In advance, sorry for slow response.

> 
> zram, indeed, does not provide any info and does not answer
> these questions. Reading from `max_comp_streams' let to estimate
> only theoretical comp streams memory consumption, which assumes
> that zram will allocate max_comp_streams. However, it's possible
> that the real number of compression streams will never reach that
> max value, due to various reasons, e.g. max_comp_streams is too
> high, etc.
> 
> The patch adds `avail_streams' column to the /sys/block/zram/mm_stat
> device file. For a single compression stream backend it's always 1,
> for a multi stream backend - it shows the actual ->avail_strm value.
> 
> The number of allocated compression streams answers several
> questions:
> a) the current `level of concurrency' that the device has
>experienced
> b) the amount of memory used by compression streams (by multiplying
>the `avail_streams' column value, ->buffer size and algorithm's
>specific scratch buffer size; the last are easy to find out,
>unlike `avail_streams').
> 
> Signed-off-by: Sergey Senozhatsky 

Re: [PATCH v8 1/2] drm/rockchip: hdmi: add Innosilicon HDMI support

[Jean-Francois Moine]

On Fri, 29 Jan 2016 14:47:39 +0800
Yakir Yang  wrote:

> The Innosilicon HDMI is a low power HDMI 1.4 transmitter
> IP, and it have been integrated on some rockchip CPUs
> (like RK3036, RK312x).
> 
> Signed-off-by: Yakir Yang 
> ---
> Changes in v8:
> - Don't check whether encoder output format is RGB colorspace, cause driver
>   default configure the output colorspace to RGB. (ZhengYang)
> - Correct the check condition in inno_hdmi_config_video_csc() (ZhengYang)
> - if (data->enc_out_format == data->enc_out_format) {
> + if (data->enc_in_format == data->enc_out_format) {
> 
> Changes in v7:
> - Correct the module licnese statement (Paul)
>  - MODULE_LICENSE("GPL");
>  + MODULE_LICENSE("GPLv2");
> - Start indentation with tabs and fix the misspell in Kconfig (Paul)
> - Carry the lost device-binding document (Heiko)
> 
> Changes in v6:
> - Rebase the Makefile/Kconfig files which add by Chris's rockchip-mipi driver 
> (Caeser)
> 
> Changes in v5:
> - Use hdmi_infoframe helper functions to packed the infoframe (Russell)
> - Remove the unused double wait_for_completion_timeout for ddc transfer 
> (Russell)
> - Remove the unused local variable in "inno_hdmi_i2c_write()" function 
> (Russell)
> 
> Changes in v4:
> - Modify the commit title "drm/rockchip: hdmi: ..." (Mark)
> - Correct the "DKMS" to "DPMS" (Mark)
> - Fix over 80 characters problems (Mark)
> - Remove encoder .prepare/.commit helper functions, and move the vop mode
> configure function into encoder .enable helper functions. (Mark)
> 
> Changes in v3:
> - Use encoder enable/disable function, and remove the encoder DPMS function
> - Keep HDMI PLL power on in standby mode
> 
> Changes in v2:
> - Using DRM atomic helper functions for connector init (Mark)
> - Remove "hdmi->connector.encoder = encoder;" (Mark)
> 
>  drivers/gpu/drm/rockchip/Kconfig |   8 +
>  drivers/gpu/drm/rockchip/Makefile|   1 +
>  drivers/gpu/drm/rockchip/inno_hdmi.c | 939 
> +++
>  drivers/gpu/drm/rockchip/inno_hdmi.h | 362 ++
>  4 files changed, 1310 insertions(+)
>  create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.c
>  create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.h
> 
> diff --git a/drivers/gpu/drm/rockchip/Kconfig 
> b/drivers/gpu/drm/rockchip/Kconfig
> index 8573985..76b3362 100644
> --- a/drivers/gpu/drm/rockchip/Kconfig
> +++ b/drivers/gpu/drm/rockchip/Kconfig
> @@ -35,3 +35,11 @@ config ROCKCHIP_DW_MIPI_DSI
>for the Synopsys DesignWare HDMI driver. If you want to
>enable MIPI DSI on RK3288 based SoC, you should selet this
>option.
> +
> +config ROCKCHIP_INNO_HDMI
> + tristate "Rockchip specific extensions for Innosilicon HDMI"
> + depends on DRM_ROCKCHIP
> + help
> +   This selects support for Rockchip SoC specific extensions
> +   for the Innosilicon HDMI driver. If you want to enable
> +   HDMI on RK3036 based SoC, you should select this option.
> diff --git a/drivers/gpu/drm/rockchip/Makefile 
> b/drivers/gpu/drm/rockchip/Makefile
> index f6a809a..df8fbef 100644
> --- a/drivers/gpu/drm/rockchip/Makefile
> +++ b/drivers/gpu/drm/rockchip/Makefile
> @@ -8,5 +8,6 @@ rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += 
> rockchip_drm_fbdev.o
>  
>  obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
>  obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
> +obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
>  
>  obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_vop_reg.o
> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c 
> b/drivers/gpu/drm/rockchip/inno_hdmi.c
> new file mode 100644
> index 000..c99d88d
> --- /dev/null
> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
> @@ -0,0 +1,939 @@
> +/*
> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
> + *Zheng Yang 
> + *Yakir Yang 
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

This is not needed.

> +
> +#include "rockchip_drm_drv.h"
> +#include "rockchip_drm_vop.h"
> +
> +#include "inno_hdmi.h"
[snip]

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[PATCH] tpm, tpm_crb: fix control area resource mapping

[Jarkko Sakkinen]

Control area does not always fall in the range of memory resource given
by the ACPI object. This patch fixes the issue by ioremapping the
buffers if this is the case.

Fixes: bb76f9ba49 ("tpm_crb: Use devm_ioremap_resource")
Signed-off-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm_crb.c | 36 
 1 file changed, 16 insertions(+), 20 deletions(-)

diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index 8e46e40..a9688c7 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -233,27 +233,23 @@ static int crb_check_resource(struct acpi_resource *ares, 
void *data)
return 1;
 }
 
-static void __iomem *crb_access(struct device *dev, struct crb_priv *priv,
-   u64 start, u32 size)
+static void __iomem *crb_map_res(struct device *dev, struct crb_priv *priv,
+u64 start, u32 size)
 {
-   struct resource tmp = {};
-
-   tmp.start = start;
-   tmp.end = start + size - 1;
-   tmp.flags = IORESOURCE_MEM;
+   struct resource new_res = {
+   .start  = start,
+   .end= size - 1,
+   .flags  = IORESOURCE_MEM,
+   };
 
/* Detect a 64 bit address on a 32 bit system */
-   if (start != tmp.start)
+   if (start != new_res.start)
return ERR_PTR(-EINVAL);
 
-   if (!resource_contains(>res, )) {
-   dev_err(dev,
-   FW_BUG "TPM2 ACPI sub resource %pR is not in the 
device's region of %pR\n",
-   , >res);
-   return ERR_PTR(-EINVAL);
-   }
+   if (!resource_contains(>res, _res))
+   return devm_ioremap_resource(dev, _res);
 
-   return priv->iobase + (tmp.start - priv->res.start);
+   return priv->iobase + (new_res.start - priv->res.start);
 }
 
 static int crb_map_io(struct acpi_device *device, struct crb_priv *priv,
@@ -281,19 +277,19 @@ static int crb_map_io(struct acpi_device *device, struct 
crb_priv *priv,
if (IS_ERR(priv->iobase))
return PTR_ERR(priv->iobase);
 
-   priv->cca = crb_access(dev, priv, buf->control_address, 0x1000);
+   priv->cca = crb_map_res(dev, priv, buf->control_address, 0x1000);
if (IS_ERR(priv->cca))
return PTR_ERR(priv->cca);
 
-   pa = ((u64)ioread32(>cca->cmd_pa_high) << 32) |
-(u64)ioread32(>cca->cmd_pa_low);
-   priv->cmd = crb_access(dev, priv, pa, ioread32(>cca->cmd_size));
+   pa = ((u64) ioread32(>cca->cmd_pa_high) << 32) |
+ (u64) ioread32(>cca->cmd_pa_low);
+   priv->cmd = crb_map_res(dev, priv, pa, ioread32(>cca->cmd_size));
if (IS_ERR(priv->cmd))
return PTR_ERR(priv->cmd);
 
memcpy_fromio(, >cca->rsp_pa, 8);
pa = le64_to_cpu(pa);
-   priv->rsp = crb_access(dev, priv, pa, ioread32(>cca->rsp_size));
+   priv->rsp = crb_map_res(dev, priv, pa, ioread32(>cca->rsp_size));
return PTR_ERR_OR_ZERO(priv->rsp);
 }
 
-- 
2.7.0.rc3

[PATCH v8.1 2/2] dt-bindings: add document for Innosilicon HDMI on Rockchip platform

[Yakir Yang]

Signed-off-by: Yakir Yang 
Acked-by: Rob Herring 
---
Changes in v8.1:
- Remove dumplicate Signed-off which add at the v8 (Mark)
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Add the Acked-by tags from Rob
- Correct the misspell "rk3036-dw-hdmi" (Heiko)

 .../display/rockchip/inno_hdmi-rockchip.txt| 50 ++
 1 file changed, 50 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
new file mode 100644
index 000..8096a29
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
@@ -0,0 +1,50 @@
+Rockchip specific extensions to the Innosilicon HDMI
+
+
+Required properties:
+- compatible:
+   "rockchip,rk3036-inno-hdmi";
+- reg:
+   Physical base address and length of the controller's registers.
+- clocks, clock-names:
+   Phandle to hdmi controller clock, name should be "pclk"
+- interrupts:
+   HDMI interrupt number
+- ports:
+   Contain one port node with endpoint definitions as defined in
+   Documentation/devicetree/bindings/graph.txt.
+- pinctrl-0, pinctrl-name:
+   Switch the iomux of HPD/CEC pins to HDMI function.
+
+Example:
+hdmi: hdmi@20034000 {
+   compatible = "rockchip,rk3036-inno-hdmi";
+   reg = <0x20034000 0x4000>;
+   interrupts = ;
+   clocks = <  PCLK_HDMI>;
+   clock-names = "pclk";
+   pinctrl-names = "default";
+   pinctrl-0 = <_ctl>;
+   status = "disabled";
+
+   hdmi_in: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   hdmi_in_lcdc: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_hdmi>;
+   };
+   };
+};
+
+ {
+   hdmi {
+   hdmi_ctl: hdmi-ctl {
+   rockchip,pins = <1 8  RK_FUNC_1 _pull_none>,
+   <1 9  RK_FUNC_1 _pull_none>,
+   <1 10 RK_FUNC_1 _pull_none>,
+   <1 11 RK_FUNC_1 _pull_none>;
+   };
+   };
+
+};
-- 
1.9.1

Re: [PATCH v4] lib/spinlock_debug.c: prevent a recursive cycle in the debug code

[Sergey Senozhatsky]

On (01/29/16 15:54), Byungchul Park wrote:
> On Fri, Jan 29, 2016 at 09:27:03AM +0900, Sergey Senozhatsky wrote:
> > 
> > well, the stack is surely limited, but on every
> > spin_dump()->spin_lock() recursive call it does another
> > round of
> > 
> > u64 loops = loops_per_jiffy * HZ;
> > 
> > for (i = 0; i < loops; i++) {
> > if (arch_spin_trylock(>raw_lock))
> > return;
> > __delay(1);
> > }
> > 
> > so if you have 1000 spin_dump()->spin_lock() then, well,
> > something has been holding the lock for '1000 * loops_per_jiffy * HZ'.
> 
> Or the printk() is heavily called and the lock is congested.

well, isn't it the case that ticket-based locking assumes at least
some sort of fairness? how many cpus do you have there? you can
have `num_online_cpus() - 1' tasks spinning on the spin lock and
1 owning the spin lock... if your lock is in correct state (no
before/after spinlock debug errors) even most unlucky task should
get the lock eventually...

-ss

[PATCH] Staging: rtl8712: rtl8712_cmd: Fixed a warning.

[Rakhi Sharma]

Warning:Comparisons should place the constant on the right side of the test
Fixed by placing the comparisions constant on right side of the test.

Signed-off-by: Rakhi Sharma 
---
 drivers/staging/rtl8712/rtl8712_cmd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/rtl8712_cmd.c 
b/drivers/staging/rtl8712/rtl8712_cmd.c
index 9b91609..86a9089 100644
--- a/drivers/staging/rtl8712/rtl8712_cmd.c
+++ b/drivers/staging/rtl8712/rtl8712_cmd.c
@@ -293,7 +293,7 @@ u8 r8712_fw_cmd(struct _adapter *pAdapter, u32 cmd)
 
r8712_write32(pAdapter, IOCMD_CTRL_REG, cmd);
msleep(100);
-   while ((0 != r8712_read32(pAdapter, IOCMD_CTRL_REG)) &&
+   while ((r8712_read32(pAdapter, IOCMD_CTRL_REG != 0)) &&
   (pollingcnts > 0)) {
pollingcnts--;
msleep(20);
-- 
1.9.1

[PATCH v2] i2c: mt8173: add 4GB mode support in i2c driver.

[Liguo Zhang]

If 4GB mode is enable, we should add 4gb mode support in i2c driver.
Set 4GB mode register to support 4GB mode.

Signed-off-by: Liguo Zhang 
---
change in v2:
Define a static inline funtion mtk_i2c_set_4g_mode() for support 4g mode.
---
 drivers/i2c/busses/i2c-mt65xx.c | 51 +
 1 file changed, 51 insertions(+)

diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index aec8e6c..f5734e6 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -60,6 +60,7 @@
 #define I2C_DMA_INT_FLAG_NONE  0x
 #define I2C_DMA_CLR_FLAG   0x
 #define I2C_DMA_HARD_RST   0x0002
+#define I2C_DMA_4G_MODE0x0001
 
 #define I2C_DEFAULT_SPEED  10  /* hz */
 #define MAX_FS_MODE_SPEED  40
@@ -88,6 +89,8 @@ enum DMA_REGS_OFFSET {
OFFSET_RX_MEM_ADDR = 0x20,
OFFSET_TX_LEN = 0x24,
OFFSET_RX_LEN = 0x28,
+   OFFSET_TX_4G_MODE = 0x54,
+   OFFSET_RX_4G_MODE = 0x58,
 };
 
 enum i2c_trans_st_rs {
@@ -133,6 +136,7 @@ struct mtk_i2c_compatible {
unsigned char dcm: 1;
unsigned char auto_restart: 1;
unsigned char aux_len_reg: 1;
+   unsigned char support_33bits: 1;
 };
 
 struct mtk_i2c {
@@ -182,6 +186,7 @@ static const struct mtk_i2c_compatible mt6577_compat = {
.dcm = 1,
.auto_restart = 0,
.aux_len_reg = 0,
+   .support_33bits = 0,
 };
 
 static const struct mtk_i2c_compatible mt6589_compat = {
@@ -190,6 +195,7 @@ static const struct mtk_i2c_compatible mt6589_compat = {
.dcm = 0,
.auto_restart = 0,
.aux_len_reg = 0,
+   .support_33bits = 0,
 };
 
 static const struct mtk_i2c_compatible mt8173_compat = {
@@ -198,6 +204,7 @@ static const struct mtk_i2c_compatible mt8173_compat = {
.dcm = 1,
.auto_restart = 1,
.aux_len_reg = 1,
+   .support_33bits = 1,
 };
 
 static const struct of_device_id mtk_i2c_of_match[] = {
@@ -366,6 +373,30 @@ static int mtk_i2c_set_speed(struct mtk_i2c *i2c, unsigned 
int parent_clk,
return 0;
 }
 
+static inline void mtk_i2c_set_4g_mode(struct mtk_i2c *i2c, dma_addr_t wpaddr,
+  dma_addr_t rpaddr)
+{
+   u32 reg_4g_mode;
+
+   if (i2c->op == I2C_MASTER_RD) {
+   reg_4g_mode = (rpaddr & 0x1ULL) ? I2C_DMA_4G_MODE :
+  I2C_DMA_CLR_FLAG;
+   writel(reg_4g_mode, i2c->pdmabase + OFFSET_RX_4G_MODE);
+   } else if (i2c->op == I2C_MASTER_WR) {
+   reg_4g_mode = (wpaddr & 0x1ULL) ? I2C_DMA_4G_MODE :
+  I2C_DMA_CLR_FLAG;
+   writel(reg_4g_mode, i2c->pdmabase + OFFSET_TX_4G_MODE);
+   } else {
+   reg_4g_mode = (wpaddr & 0x1ULL) ? I2C_DMA_4G_MODE :
+  I2C_DMA_CLR_FLAG;
+   writel(reg_4g_mode, i2c->pdmabase + OFFSET_TX_4G_MODE);
+
+   reg_4g_mode = (rpaddr & 0x1ULL) ? I2C_DMA_4G_MODE :
+  I2C_DMA_CLR_FLAG;
+   writel(reg_4g_mode, i2c->pdmabase + OFFSET_RX_4G_MODE);
+   }
+}
+
 static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
   int num, int left_num)
 {
@@ -439,6 +470,10 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct 
i2c_msg *msgs,
msgs->len, DMA_FROM_DEVICE);
if (dma_mapping_error(i2c->dev, rpaddr))
return -ENOMEM;
+
+   if (i2c->dev_comp->support_33bits)
+   mtk_i2c_set_4g_mode(i2c, 0, rpaddr);
+
writel((u32)rpaddr, i2c->pdmabase + OFFSET_RX_MEM_ADDR);
writel(msgs->len, i2c->pdmabase + OFFSET_RX_LEN);
} else if (i2c->op == I2C_MASTER_WR) {
@@ -448,6 +483,10 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct 
i2c_msg *msgs,
msgs->len, DMA_TO_DEVICE);
if (dma_mapping_error(i2c->dev, wpaddr))
return -ENOMEM;
+
+   if (i2c->dev_comp->support_33bits)
+   mtk_i2c_set_4g_mode(i2c, wpaddr, 0);
+
writel((u32)wpaddr, i2c->pdmabase + OFFSET_TX_MEM_ADDR);
writel(msgs->len, i2c->pdmabase + OFFSET_TX_LEN);
} else {
@@ -465,6 +504,10 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct 
i2c_msg *msgs,
 msgs->len, DMA_TO_DEVICE);
return -ENOMEM;
}
+
+   if (i2c->dev_comp->support_33bits)
+   mtk_i2c_set_4g_mode(i2c, wpaddr, rpaddr);
+
writel((u32)wpaddr, i2c->pdmabase + OFFSET_TX_MEM_ADDR);
writel((u32)rpaddr, i2c->pdmabase + OFFSET_RX_MEM_ADDR);
writel(msgs->len, i2c->pdmabase + 

Re: Duplicated module names

[Tomi Valkeinen]

On 29/01/16 07:54, Rusty Russell wrote:
> Lucas De Marchi  writes:
>> Hi!
>>
>> CC'ing Rusty and mailing lists
> 
> Thanks.
> 
>> Rusty and ohers: it looks like both CONFIG_CRC32 and
>> CONFIG_CRYPTO_CRC32 can be compiled as module, and they generate
>> modules with the same name, crc32.  Could that be fixed?
> 
> Gah.  Looks like it's been that way since at least 2014, too.
> 
> I think we could rename it to crypto_crc32, but I don't think it's the
> only one.  Marco, I think depmod should probably FAIL if two modules
> have the same name, which would at least find such problems.
> 
> (BTW is there a nice way to figure out if a config var is a tristate?  These
> are only problematic if both CONFIG_ are tristate.)
> 
> Here's a hacky attempt to look for problems:
> 
> rusty@rusty-Lemur:~/devel/kernel/linux (master)$ KCONFIGS=`find * -name 
> 'Kconfig*'`; for m in `find [b-z]* -name 'Makefile*'`; do sed -n 
> 's,obj-\$(CONFIG.*+= \([a-z0-9_-]\+\.o\)$,'$m' \1,p' <$m | sort -u; done | 
> sort -k 2 | uniq -D -f 1 | while read m obj; do fgrep -w $obj $m /dev/null; 
> done | while read LINE; do conf=`echo $LINE | sed 
> 's/.*\$(CONFIG_\([A-Z0-9_]*\).*/\1/'`; if grep -C2 "^config $conf\$" 
> $KCONFIGS | fgrep -q tristate; then echo $LINE; fi; done
> 
> Here are the results (mildly filtered by me):
> 
> drivers/gpu/drm/i2c/Makefile:obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
> drivers/media/i2c/Makefile:obj-$(CONFIG_VIDEO_ADV7511) += adv7511.o
> 
> drivers/media/platform/coda/Makefile:obj-$(CONFIG_VIDEO_CODA) += coda.o
> fs/coda/Makefile:obj-$(CONFIG_CODA_FS) += coda.o
> 
> drivers/gpu/drm/omapdrm/displays/Makefile:obj-$(CONFIG_DISPLAY_CONNECTOR_ANALOG_TV)
>  += connector-analog-tv.o
> drivers/video/fbdev/omap2/omapfb/displays/Makefile:obj-$(CONFIG_FB_OMAP2_CONNECTOR_ANALOG_TV)
>  += connector-analog-tv.o
> 
> drivers/gpu/drm/omapdrm/displays/Makefile:obj-$(CONFIG_DISPLAY_CONNECTOR_DVI) 
> += connector-dvi.o
> drivers/video/fbdev/omap2/omapfb/displays/Makefile:obj-$(CONFIG_FB_OMAP2_CONNECTOR_DVI)
>  += connector-dvi.o
> 
> drivers/gpu/drm/omapdrm/displays/Makefile:obj-$(CONFIG_DISPLAY_CONNECTOR_HDMI)
>  += connector-hdmi.o
> drivers/video/fbdev/omap2/omapfb/displays/Makefile:obj-$(CONFIG_FB_OMAP2_CONNECTOR_HDMI)
>  += connector-hdmi.o
> 
> crypto/Makefile:obj-$(CONFIG_CRYPTO_CRC32) += crc32.o
> lib/Makefile:obj-$(CONFIG_CRC32) += crc32.o
> 
> drivers/gpu/drm/omapdrm/displays/Makefile:obj-$(CONFIG_DISPLAY_ENCODER_OPA362)
>  += encoder-opa362.o
> drivers/video/fbdev/omap2/omapfb/displays/Makefile:obj-$(CONFIG_FB_OMAP2_ENCODER_OPA362)
>  += encoder-opa362.o
> 
> drivers/gpu/drm/omapdrm/displays/Makefile:obj-$(CONFIG_DISPLAY_ENCODER_TFP410)
>  += encoder-tfp410.o
> drivers/video/fbdev/omap2/omapfb/displays/Makefile:obj-$(CONFIG_FB_OMAP2_ENCODER_TFP410)
>  += encoder-tfp410.o
> 
> drivers/gpu/drm/omapdrm/displays/Makefile:obj-$(CONFIG_DISPLAY_ENCODER_TPD12S015)
>  += encoder-tpd12s015.o
> drivers/video/fbdev/omap2/omapfb/displays/Makefile:obj-$(CONFIG_FB_OMAP2_ENCODER_TPD12S015)
>  += encoder-tpd12s015.o
> 
> drivers/gpu/drm/omapdrm/displays/Makefile:obj-$(CONFIG_DISPLAY_PANEL_DPI) += 
> panel-dpi.o
> drivers/video/fbdev/omap2/omapfb/displays/Makefile:obj-$(CONFIG_FB_OMAP2_PANEL_DPI)
>  += panel-dpi.o
> 
> drivers/gpu/drm/omapdrm/displays/Makefile:obj-$(CONFIG_DISPLAY_PANEL_DSI_CM) 
> += panel-dsi-cm.o
> drivers/video/fbdev/omap2/omapfb/displays/Makefile:obj-$(CONFIG_FB_OMAP2_PANEL_DSI_CM)
>  += panel-dsi-cm.o
> 
> drivers/gpu/drm/omapdrm/displays/Makefile:obj-$(CONFIG_DISPLAY_PANEL_LGPHILIPS_LB035Q02)
>  += panel-lgphilips-lb035q02.o
> drivers/video/fbdev/omap2/omapfb/displays/Makefile:obj-$(CONFIG_FB_OMAP2_PANEL_LGPHILIPS_LB035Q02)
>  += panel-lgphilips-lb035q02.o
> 
> drivers/gpu/drm/omapdrm/displays/Makefile:obj-$(CONFIG_DISPLAY_PANEL_NEC_NL8048HL11)
>  += panel-nec-nl8048hl11.o
> drivers/video/fbdev/omap2/omapfb/displays/Makefile:obj-$(CONFIG_FB_OMAP2_PANEL_NEC_NL8048HL11)
>  += panel-nec-nl8048hl11.o
> 
> drivers/gpu/drm/omapdrm/displays/Makefile:obj-$(CONFIG_DISPLAY_PANEL_SHARP_LS037V7DW01)
>  += panel-sharp-ls037v7dw01.o
> drivers/video/fbdev/omap2/omapfb/displays/Makefile:obj-$(CONFIG_FB_OMAP2_PANEL_SHARP_LS037V7DW01)
>  += panel-sharp-ls037v7dw01.o
> 
> drivers/gpu/drm/omapdrm/displays/Makefile:obj-$(CONFIG_DISPLAY_PANEL_SONY_ACX565AKM)
>  += panel-sony-acx565akm.o
> drivers/video/fbdev/omap2/omapfb/displays/Makefile:obj-$(CONFIG_FB_OMAP2_PANEL_SONY_ACX565AKM)
>  += panel-sony-acx565akm.o
> 
> drivers/gpu/drm/omapdrm/displays/Makefile:obj-$(CONFIG_DISPLAY_PANEL_TPO_TD028TTEC1)
>  += panel-tpo-td028ttec1.o
> drivers/video/fbdev/omap2/omapfb/displays/Makefile:obj-$(CONFIG_FB_OMAP2_PANEL_TPO_TD028TTEC1)
>  += panel-tpo-td028ttec1.o
> 
> drivers/gpu/drm/omapdrm/displays/Makefile:obj-$(CONFIG_DISPLAY_PANEL_TPO_TD043MTEA1)
>  += panel-tpo-td043mtea1.o
> drivers/video/fbdev/omap2/omapfb/displays/Makefile:obj-$(CONFIG_FB_OMAP2_PANEL_TPO_TD043MTEA1)
>  += panel-tpo-td043mtea1.o
> 
> 

Re: [PATCH v4] lib/spinlock_debug.c: prevent a recursive cycle in the debug code

[Byungchul Park]

On Fri, Jan 29, 2016 at 09:27:03AM +0900, Sergey Senozhatsky wrote:
> 
> well, the stack is surely limited, but on every
> spin_dump()->spin_lock() recursive call it does another
> round of
> 
>   u64 loops = loops_per_jiffy * HZ;
> 
>   for (i = 0; i < loops; i++) {
>   if (arch_spin_trylock(>raw_lock))
>   return;
>   __delay(1);
>   }
> 
> so if you have 1000 spin_dump()->spin_lock() then, well,
> something has been holding the lock for '1000 * loops_per_jiffy * HZ'.

Or the printk() is heavily called and the lock is congested.

Re: [PATCH] Staging:speakup:add space around '|'

[Greg KH]

On Sat, Jan 16, 2016 at 06:43:09PM +0530, Bhumika Goyal wrote:
> Fix checkpatch.pl check:CHECK: spaces preferred around that '|'.
> Add spaces around operands to fix these warnings.
> 
> Signed-off-by: Bhumika Goyal 
> ---
>  drivers/staging/speakup/speakup_decext.c | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)

This does not apply to my tree :(

[PATCH v8 2/2] dt-bindings: add document for Innosilicon HDMI on Rockchip platform

[Yakir Yang]

Signed-off-by: Yakir Yang 

Signed-off-by: Yakir Yang 
Acked-by: Rob Herring 
---
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Add the Acked-by tags from Rob
- Correct the misspell "rk3036-dw-hdmi" (Heiko)

 .../display/rockchip/inno_hdmi-rockchip.txt| 50 ++
 1 file changed, 50 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
new file mode 100644
index 000..8096a29
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
@@ -0,0 +1,50 @@
+Rockchip specific extensions to the Innosilicon HDMI
+
+
+Required properties:
+- compatible:
+   "rockchip,rk3036-inno-hdmi";
+- reg:
+   Physical base address and length of the controller's registers.
+- clocks, clock-names:
+   Phandle to hdmi controller clock, name should be "pclk"
+- interrupts:
+   HDMI interrupt number
+- ports:
+   Contain one port node with endpoint definitions as defined in
+   Documentation/devicetree/bindings/graph.txt.
+- pinctrl-0, pinctrl-name:
+   Switch the iomux of HPD/CEC pins to HDMI function.
+
+Example:
+hdmi: hdmi@20034000 {
+   compatible = "rockchip,rk3036-inno-hdmi";
+   reg = <0x20034000 0x4000>;
+   interrupts = ;
+   clocks = <  PCLK_HDMI>;
+   clock-names = "pclk";
+   pinctrl-names = "default";
+   pinctrl-0 = <_ctl>;
+   status = "disabled";
+
+   hdmi_in: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   hdmi_in_lcdc: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_hdmi>;
+   };
+   };
+};
+
+ {
+   hdmi {
+   hdmi_ctl: hdmi-ctl {
+   rockchip,pins = <1 8  RK_FUNC_1 _pull_none>,
+   <1 9  RK_FUNC_1 _pull_none>,
+   <1 10 RK_FUNC_1 _pull_none>,
+   <1 11 RK_FUNC_1 _pull_none>;
+   };
+   };
+
+};
-- 
1.9.1

[PATCH v8 1/2] drm/rockchip: hdmi: add Innosilicon HDMI support

[Yakir Yang]

The Innosilicon HDMI is a low power HDMI 1.4 transmitter
IP, and it have been integrated on some rockchip CPUs
(like RK3036, RK312x).

Signed-off-by: Yakir Yang 
---
Changes in v8:
- Don't check whether encoder output format is RGB colorspace, cause driver
  default configure the output colorspace to RGB. (ZhengYang)
- Correct the check condition in inno_hdmi_config_video_csc() (ZhengYang)
- if (data->enc_out_format == data->enc_out_format) {
+ if (data->enc_in_format == data->enc_out_format) {

Changes in v7:
- Correct the module licnese statement (Paul)
 - MODULE_LICENSE("GPL");
 + MODULE_LICENSE("GPLv2");
- Start indentation with tabs and fix the misspell in Kconfig (Paul)
- Carry the lost device-binding document (Heiko)

Changes in v6:
- Rebase the Makefile/Kconfig files which add by Chris's rockchip-mipi driver 
(Caeser)

Changes in v5:
- Use hdmi_infoframe helper functions to packed the infoframe (Russell)
- Remove the unused double wait_for_completion_timeout for ddc transfer 
(Russell)
- Remove the unused local variable in "inno_hdmi_i2c_write()" function (Russell)

Changes in v4:
- Modify the commit title "drm/rockchip: hdmi: ..." (Mark)
- Correct the "DKMS" to "DPMS" (Mark)
- Fix over 80 characters problems (Mark)
- Remove encoder .prepare/.commit helper functions, and move the vop mode
configure function into encoder .enable helper functions. (Mark)

Changes in v3:
- Use encoder enable/disable function, and remove the encoder DPMS function
- Keep HDMI PLL power on in standby mode

Changes in v2:
- Using DRM atomic helper functions for connector init (Mark)
- Remove "hdmi->connector.encoder = encoder;" (Mark)

 drivers/gpu/drm/rockchip/Kconfig |   8 +
 drivers/gpu/drm/rockchip/Makefile|   1 +
 drivers/gpu/drm/rockchip/inno_hdmi.c | 939 +++
 drivers/gpu/drm/rockchip/inno_hdmi.h | 362 ++
 4 files changed, 1310 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.c
 create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 8573985..76b3362 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -35,3 +35,11 @@ config ROCKCHIP_DW_MIPI_DSI
 for the Synopsys DesignWare HDMI driver. If you want to
 enable MIPI DSI on RK3288 based SoC, you should selet this
 option.
+
+config ROCKCHIP_INNO_HDMI
+   tristate "Rockchip specific extensions for Innosilicon HDMI"
+   depends on DRM_ROCKCHIP
+   help
+ This selects support for Rockchip SoC specific extensions
+ for the Innosilicon HDMI driver. If you want to enable
+ HDMI on RK3036 based SoC, you should select this option.
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index f6a809a..df8fbef 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -8,5 +8,6 @@ rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += 
rockchip_drm_fbdev.o
 
 obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
 obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
+obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
 
 obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_vop_reg.o
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c 
b/drivers/gpu/drm/rockchip/inno_hdmi.c
new file mode 100644
index 000..c99d88d
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -0,0 +1,939 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ *Zheng Yang 
+ *Yakir Yang 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#include "inno_hdmi.h"
+
+#define to_inno_hdmi(x)container_of(x, struct inno_hdmi, x)
+
+struct hdmi_data_info {
+   int vic;
+   bool sink_is_hdmi;
+   bool sink_has_audio;
+   unsigned int enc_in_format;
+   unsigned int enc_out_format;
+   unsigned int colorimetry;
+};
+
+struct inno_hdmi_i2c {
+   struct i2c_adapter adap;
+
+   u8 ddc_addr;
+   u8 segment_addr;
+
+   struct mutex lock;
+   struct completion cmp;
+};
+
+struct inno_hdmi {
+   struct device *dev;
+   struct drm_device *drm_dev;
+
+   int irq;
+   struct clk *pclk;
+   void __iomem *regs;
+
+   struct drm_connectorconnector;
+   struct drm_encoder

Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

[liudongdong (C)]

在 2016/1/13 21:20, Tomasz Nowicki 写道:

From the functionality point of view this series might be split into the

following logic parts:
1. Make MMCONFIG code arch-agnostic which allows all architectures to collect
PCI config regions and used when necessary.
2. Move non-arch specific bits to the core code.
3. Use MMCONFIG code and implement generic ACPI based PCI host controller 
driver.
4. Enable above driver on ARM64

Patches has been built on top of 4.4 and can be found here:
g...@github.com:semihalf-nowicki-tomasz/linux.git (pci-acpi-v3)

NOTE, this patch set depends on Matthew's patches:
http://www.spinics.net/lists/linux-pci/msg45950.html
https://github.com/Vality/linux/tree/pci-fixes

This has been tested on Cavium ThunderX server and QEMU.
Any help in reviewing and testing is very appreciated.

v2 -> v3
- fix legacy IRQ assigning and IO ports registration
- remove reference to arch specific companion device for ia64
- move ACPI PCI host controller driver to pci_root.c
- drop generic domain assignment for x86 and ia64 as I am not
   able to run all necessary test variants
- drop patch which cleaned legacy IRQ assignment since it belongs to
   Mathew's series:
   https://patchwork.ozlabs.org/patch/557504/
- extend MCFG quirk code
- rebased to 4.4


Based on the patchset and add the Hip05 ACPI specific quirks.
Tested on the HiSilicon ARM64 D02 board.
I made a test based on Intel 82599 networking card,it can work ok.
this is the bootup log which contains PCIe host and Intel 82599 networking card 
part.

Tested-by: Dongdong Liu 

EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from command line
EFI stub: Exiting boot services and installing virtual address map...
GMAC ExitBootServicesEvent
SMMU ExitBootServicesEvent
Booting Linux on physical CPU 0x2
Initializing cgroup subsys cpu
Linux version 4.4.0-rc2+ (l00290354@linux-ioko) (gcc version 4.9.3 20150211 
(prerelease) (20150316) ) #194 SMP PREEMPT Thu Jan 28 09:51:15 CST 2016
Boot CPU: AArch64 Processor [411fd071]
earlycon: Early serial console at MMIO32 0x8030 (options '')
bootconsole [uart0] enabled
efi: Getting EFI parameters from FDT:
EFI v2.50 by ARM Versatile Express EFI Jan 13 2016 20:43:10
efi:  SMBIOS=0x7aae  SMBIOS 3.0=0x7aac  ACPI=0x7ab2  ACPI 
2.0=0x7ab20014
cma: Reserved 16 MiB at 0x7e80
ACPI: Early table checksum verification disabled
ACPI: RSDP 0x7AB20014 24 (v02 HISI  )
ACPI: XSDT 0x7AB100E8 6C (v01 HISI   HISI-D02 20140727  
0113)
ACPI: FACP 0x7AA8 00010C (v05 HISI   HISI-D02 20140727 HISI 
0099)
ACPI: Override [DSDT-HISI-D02], this is unsafe: tainting kernel
Disabling lock debugging due to kernel taint
ACPI: DSDT 0x7AA1 Logical table override, new table: 
0xFFC0009CB8B8
ACPI: DSDT 0xFFC0009CB8B8 0015B5 (v01 HISI   HISI-D02 20140727 INTL 
20150619)
ACPI: DBG2 0x7AAA 5A (v00 HISI   HISI-D02 20140727 HISI 
0099)
ACPI: GTDT 0x7AA7 60 (v02 HISI   HISI-D02 20140727 HISI 
0099)
ACPI: APIC 0x7AA6 000564 (v01 HISI   HISI-D02 20140727 HISI 
0099)
ACPI: MCFG 0x7AA5 4C (v01 HISI   HISI-D02 20140727 HISI 
0099)
ACPI: SLIT 0x7AA4 0001BC (v01 HISI   HISI-D02 20140727 HISI 
0099)
ACPI: SPCR 0x7AA3 50 (v02 HISI   HISI-D02 20140727 HISI 
0099)
ACPI: SRAT 0x7AA2 0001B0 (v03 HISI   HISI-D02 20140727 HISI 
0099)
ACPI: IORT 0x7AA0 0001FC (v00 INTEL  TEMPLATE  INTL 
20150619)
psci: probing for conduit method from ACPI.
NOTICE:  [psci_smc_handler]:[349L] PSCI_VERSION CALL
NOTICE:  [psci_version]:[101L] PSCI_MAJOR_VER: 1: PSCI_MINOR_VER: 0

0008;<54
psci: PSCIv1.0 detected in firmware.
psci: Using standard PSCI v0.2 function IDs

0008;<54
psci: MIGRATE_INFO_TYPE not supported.

0008;<54

0008;<54
PERCPU: Embedded 15 pages/cpu @ffd1ffedb000 s24576 r8192 d28672 u61440
Detected PIPT I-cache on CPU0
CPU features: enabling workaround for ARM erratum 832075
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 2063376
Kernel command line: dtb=hip05-d02.dtb console=ttyS0,115200 
earlycon=uart8250,mmio32,0x8030 initrd=filesystem.cpio.gz acpi=force
log_buf_len individual max cpu contribution: 4096 bytes
log_buf_len total cpu_extra contributions: 61440 bytes
log_buf_len min size: 16384 bytes
log_buf_len: 131072 bytes
early log buf free: 12732(77%)
PID hash table entries: 4096 (order: 3, 32768 bytes)
Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
software IO TLB [mem 0x76a0-0x7aa0] (64MB) mapped at 
[ffc076a0-ffc07a9f]
Memory: 8052312K/8384512K available (6074K kernel code, 519K rwdata, 2556K 
rodata, 572K init, 212K bss, 315816K reserved, 16384K cma-reserved)
Virtual kernel memory layout:
vmalloc : 0xff80 - 0xffbdbfff   (   246 GB)
vmemmap : 

[PATCH 0/2] Fix ordering of ftrace + livepatch module notifier callbacks

[Jessica Yu]

As explained here [1], livepatch modules are failing to initialize properly
because the ftrace coming module notifier (which calls
ftrace_module_enable()) runs after the livepatch module notifier (which
enables the patch(es)). Thus livepatch attempts to apply patches to modules
before ftrace_module_enable() is even called for the corresponding
module(s). Separate klp_module_notify() into coming and going notifiers
and tweak the priorities to fix the order in which the ftrace and livepatch
notifiers are called.

Tested the changes with a test livepatch module that patches 9p and nilfs2,
and verified that the issue is fixed.

Patch 1/2 based on the 'for-next' branch in livepatching -
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/livepatching.git

Patch 2/2 based on the 'ftrace/core' branch in linux-trace -
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git

[1] 
http://lkml.kernel.org/g/20160128204033.ga32...@packer-debian-8-amd64.digitalocean.com

Jessica Yu (2):
  livepatch: Implement separate coming and going module notifiers
  ftrace: Adjust priority of ftrace module notifier

 kernel/livepatch/core.c | 128 +++-
 kernel/trace/ftrace.c   |   7 ++-
 2 files changed, 79 insertions(+), 56 deletions(-)

-- 
2.4.3

[PATCH 1/2] livepatch: Implement separate coming and going module notifiers

[Jessica Yu]

Detangle klp_module_notify() into two separate module notifiers
klp_module_notify_{coming,going}() with the appropriate priorities,
so that on module load, the ftrace module notifier will run *before*
the livepatch coming module notifier but *after* the livepatch going
module modifier.

This fixes a notifier ordering issue in which the ftrace module notifier
(and hence ftrace_module_enable()) for COMING modules was being called
after klp_module_notify(), which caused livepatch modules to initialize
incorrectly.

Signed-off-by: Jessica Yu 
---
 kernel/livepatch/core.c | 128 +++-
 1 file changed, 73 insertions(+), 55 deletions(-)

diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index bc2c85c..23f4234 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -866,60 +866,73 @@ int klp_register_patch(struct klp_patch *patch)
 }
 EXPORT_SYMBOL_GPL(klp_register_patch);
 
-static int klp_module_notify_coming(struct klp_patch *patch,
-struct klp_object *obj)
+static int klp_module_notify_coming(struct notifier_block *nb,
+   unsigned long action, void *data)
 {
-   struct module *pmod = patch->mod;
-   struct module *mod = obj->mod;
int ret;
+   struct module *mod = data;
+   struct klp_patch *patch;
+   struct klp_object *obj;
 
-   ret = klp_init_object_loaded(patch, obj);
-   if (ret) {
-   pr_warn("failed to initialize patch '%s' for module '%s' 
(%d)\n",
-   pmod->name, mod->name, ret);
-   return ret;
-   }
-
-   if (patch->state == KLP_DISABLED)
+   if (action != MODULE_STATE_COMING)
return 0;
 
-   pr_notice("applying patch '%s' to loading module '%s'\n",
- pmod->name, mod->name);
+   mutex_lock(_mutex);
 
-   ret = klp_enable_object(obj);
-   if (ret)
-   pr_warn("failed to apply patch '%s' to module '%s' (%d)\n",
-   pmod->name, mod->name, ret);
-   return ret;
-}
+   /*
+* Each module has to know that the notifier has been called.
+* We never know what module will get patched by a new patch.
+*/
+   mod->klp_alive = true;
 
-static void klp_module_notify_going(struct klp_patch *patch,
-   struct klp_object *obj)
-{
-   struct module *pmod = patch->mod;
-   struct module *mod = obj->mod;
+   list_for_each_entry(patch, _patches, list) {
+   klp_for_each_object(patch, obj) {
+   if (!klp_is_module(obj) || strcmp(obj->name, mod->name))
+   continue;
+
+   obj->mod = mod;
 
-   if (patch->state == KLP_DISABLED)
-   goto disabled;
+   ret = klp_init_object_loaded(patch, obj);
+   if (ret) {
+   pr_warn("failed to initialize patch '%s' for 
module '%s' (%d)\n",
+   patch->mod->name, obj->mod->name, ret);
+   goto err;
+   }
 
-   pr_notice("reverting patch '%s' on unloading module '%s'\n",
- pmod->name, mod->name);
+   if (patch->state == KLP_DISABLED)
+   break;
 
-   klp_disable_object(obj);
+   pr_notice("applying patch '%s' to loading module 
'%s'\n",
+ patch->mod->name, obj->mod->name);
 
-disabled:
-   klp_free_object_loaded(obj);
+   ret = klp_enable_object(obj);
+   if (ret)
+   pr_warn("failed to apply patch '%s' to module 
'%s' (%d)\n",
+   patch->mod->name, obj->mod->name, ret);
+err:
+   if (ret) {
+   obj->mod = NULL;
+   pr_warn("patch '%s' is in an inconsistent 
state!\n",
+   patch->mod->name);
+   }
+
+   break;
+   }
+   }
+
+   mutex_unlock(_mutex);
+
+   return 0;
 }
 
-static int klp_module_notify(struct notifier_block *nb, unsigned long action,
-void *data)
+static int klp_module_notify_going(struct notifier_block *nb,
+  unsigned long action, void *data)
 {
-   int ret;
struct module *mod = data;
struct klp_patch *patch;
struct klp_object *obj;
 
-   if (action != MODULE_STATE_COMING && action != MODULE_STATE_GOING)
+   if (action != MODULE_STATE_GOING)
return 0;
 
mutex_lock(_mutex);
@@ -928,27 +941,22 @@ static int klp_module_notify(struct notifier_block *nb, 
unsigned long action,
 * Each module has to know that the notifier has 

[PATCH v8 0/2] Add Rockchip Inno-HDMI driver

[Yakir Yang]

Here are a brief introduction to Innosilicon HDMI IP:
  - Support HDMI 1.4a, HDCP 1.2 and DVI 1.0 standard compliant transmitter
  - Support HDMI1.4 a/b 3D function defined in HDMI 1.4 a/b spec
  - Digital video interface supports a pixel size of 24, 30, 36, 48bits color 
depth in RGB
  - S/PDIF output supports PCM, Dolby Digital, DTS digital audio transmission
(32-192kHz Fs) using IEC60958 and IEC 61937
  - The EDID and CEC function are also supported by Innosilicon HDMI 
Transmitter Controlle

Changes in v8:
- Don't check whether encoder output format is RGB colorspace, cause driver
  default configure the output colorspace to RGB. (ZhengYang)
- Correct the check condition in inno_hdmi_config_video_csc() (ZhengYang)
- if (data->enc_out_format == data->enc_out_format) {
+ if (data->enc_in_format == data->enc_out_format) {

Changes in v7:
- Correct the module licnese statement (Paul)
 - MODULE_LICENSE("GPL");
 + MODULE_LICENSE("GPLv2");
- Start indentation with tabs and fix the misspell in Kconfig (Paul)
- Carry the lost device-binding document (Heiko)

Changes in v6:
- Rebase the Makefile/Kconfig files which add by Chris's rockchip-mipi driver 
(Caeser)

Changes in v5:
- Use hdmi_infoframe helper functions to packed the infoframe (Russell)
- Remove the unused double wait_for_completion_timeout for ddc transfer 
(Russell)
- Remove the unused local variable in "inno_hdmi_i2c_write()" function (Russell)

Changes in v4:
- Modify the commit title "drm/rockchip: hdmi: ..." (Mark)
- Correct the "DKMS" to "DPMS" (Mark)
- Fix over 80 characters problems (Mark)
- Remove encoder .prepare/.commit helper functions, and move the vop mode
configure function into encoder .enable helper functions. (Mark)

Changes in v3:
- Use encoder enable/disable function, and remove the encoder DPMS function
- Keep HDMI PLL power on in standby mode

Changes in v2:
- Using DRM atomic helper functions for connector init (Mark)
- Remove "hdmi->connector.encoder = encoder;" (Mark)
- Add the Acked-by tags from Rob
- Correct the misspell "rk3036-dw-hdmi" (Heiko)

Yakir Yang (2):
  drm/rockchip: hdmi: add Innosilicon HDMI support
  dt-bindings: add document for Innosilicon HDMI on Rockchip platform

 .../display/rockchip/inno_hdmi-rockchip.txt|  50 ++
 drivers/gpu/drm/rockchip/Kconfig   |   8 +
 drivers/gpu/drm/rockchip/Makefile  |   1 +
 drivers/gpu/drm/rockchip/inno_hdmi.c   | 939 +
 drivers/gpu/drm/rockchip/inno_hdmi.h   | 362 
 5 files changed, 1360 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
 create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.c
 create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.h

-- 
1.9.1

[PATCH 2/2] ftrace: Adjust priority of ftrace module notifier

[Jessica Yu]

Adjust the priority of the ftrace module notifier such that it will run
before the livepatch coming module notifier but after the livepatch going
module modifier.

This fixes a notifier ordering issue in which the ftrace module notifier
(and hence ftrace_module_enable()) for COMING modules was being called
after klp_module_notify(), which caused livepatch modules to initialize
incorrectly.

Signed-off-by: Jessica Yu 
---
 kernel/trace/ftrace.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index eca592f..bdd7bfc 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -5067,7 +5067,12 @@ static int ftrace_module_notify(struct notifier_block 
*self,
 
 struct notifier_block ftrace_module_nb = {
.notifier_call = ftrace_module_notify,
-   .priority = INT_MIN,/* Run after anything that can remove kprobes */
+   /*
+* Run after anything that can remove kprobes and
+* after livepatch's going notifier, but run before
+* livepatch's coming notifier.
+*/
+   .priority = INT_MIN+1,
 };
 
 void __init ftrace_init(void)
-- 
2.4.3

Re: [PATCH v4] lib/spinlock_debug.c: prevent a recursive cycle in the debug code

[Sergey Senozhatsky]

On (01/29/16 15:16), Sergey Senozhatsky wrote:
> 
>  http://marc.info/?l=linux-kernel=144976121529901
> 

hm... I don't like that patch. ->reset() loop must be done outside
of zap_locks(). we can have a printk() recursion in CPU1, but console
driver lock may be owned by CPU2 in driver's handle_IRQ(), for example.
stealing its lock CPU1 is not really good. in my kernels I do this from
panic() path only, where I know that things are already bad.

panic()->console_panic_mode()->{for_each_console()->reset(), 
zap_locks()}->console_trelock()->console_unlock().

-ss

Re: [PATCH] Staging: Skein: Moved macros from skein_block.c to header file.

[Greg KH]

On Thu, Dec 17, 2015 at 12:46:14PM +0530, Sudip Mukherjee wrote:
> On Mon, Dec 14, 2015 at 07:08:08PM -0500, Sanidhya Solanki wrote:
> > The original code defined macros in the source code, making it
> > harder to read. Moved them to the header file, as per the TODO file.
> > 
> > Updated the TODO file.
> 
> I think the TODO file should not be updated now. There are still some
> macros in skein_block.c.

I agree, it can't be removed just yet, this patch needs to be redone
before I can take it.

thanks,

greg k-h

Re: [PATCH] emu10k1: correctly handling failed thread creation

[Takashi Iwai]

On Fri, 29 Jan 2016 00:51:37 +0100,
Insu Yun wrote:
> 
> Since kthread_create can be failed, it needs to check 
> whether error occurred and return error code.
> 
> Signed-off-by: Insu Yun 
> ---
>  sound/pci/emu10k1/emu10k1_main.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/sound/pci/emu10k1/emu10k1_main.c 
> b/sound/pci/emu10k1/emu10k1_main.c
> index 28e2f8b..b9eac15 100644
> --- a/sound/pci/emu10k1/emu10k1_main.c
> +++ b/sound/pci/emu10k1/emu10k1_main.c
> @@ -1141,6 +1141,12 @@ static int snd_emu10k1_emu1010_init(struct snd_emu10k1 
> *emu)
>   emu->emu1010.firmware_thread =
>   kthread_create(emu1010_firmware_thread, emu,
>  "emu1010_firmware");
> + if (IS_ERR(emu->emu1010.firmware_thread)) {
> + dev_info(emu->card->dev,
> + "emu1010: Creating thread failed\n");
> + return PTR_ERR(emu->emu1010.firmware_thread);

It needs to NULL-clear emu->emu1010.firmware_thread after this, since
kthread_stop() is called for non-NULL case in the destructor.  Could
you fix it and resubmit?


thanks,

Takashi

> + }
> +
>   wake_up_process(emu->emu1010.firmware_thread);
>   }
>  
> -- 
> 1.9.1
> 
> 

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

[Enric Balletbo Serra]

Hi Rob,

Thanks for the review.

2016-01-29 3:35 GMT+01:00 Rob Herring :
> On Tue, Jan 26, 2016 at 10:12:20AM +0100, Enric Balletbo i Serra wrote:
>> 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>;
>>  microchip,pin-ignore;
>> };
>>
>> Signed-off-by: Enric Balletbo i Serra 
>> ---
>>  .../devicetree/bindings/power/ucs1002.txt  | 47 
>> ++
>>  1 file changed, 47 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/power/ucs1002.txt
>>
>> diff --git a/Documentation/devicetree/bindings/power/ucs1002.txt 
>> b/Documentation/devicetree/bindings/power/ucs1002.txt
>> new file mode 100644
>> index 000..1b89f0a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power/ucs1002.txt
>> @@ -0,0 +1,47 @@
>> +UCS1002-2 Programmable USB Port Power Controller with Charger Emulation 
>> bindings
>> +
>> +Required properties:
>> +- compatible: "microchip,ucs1002"
>> +- reg: integer, the I2C address of the device.
>> +
>> +Required properties (if pin-ignore functionality is not set):
>> +- em-gpios: which GPIO to use for EM_EN pin.
>> +- pwr-gpios: which GPIO to use for PWR_EN pin.
>> +- m1-gpios: which GPIO to use for M1 pin.
>> +- m2-gpios: which GPIO to use for M2 pin.
>> +
>> +Optional properties:
>> +- interrupt-parent: the phandle of the interrupt controller that services
>> +interrupts for this device.
>> +- interrupts: interrupt specifiers for two interrupt sources.
>> +- First interrupt specifier is for A_DET interrupt.
>> +- Second interrupt specifier is for ALERT interrupt.
>> +- microchip,current-limit: integer, maximum current in mA. Note that the 
>> default
>
> mA or ...
>
>> +value is based on the resistor on the COMM_SEL/ILIM pin and this value 
>> cannot
>> +be changed to be higher than hardware set value. Accepted values are: 
>> 50,
>> +90, 100, 120, 150, 180, 200, 250 (uA)
>
> uA?
>
> Either way append units (-microamps)
>

Right, should be  microamps, will change in next version

>> +- microchip,pin-ignore: boolean, if present uses I2C for configuration, 
>> otherwise,
>> +we must provide EM_EN, M1 and M2 gpio mapping.
>
> Wouldn't this be implied by absence of gpio properties?
>

Yes, would you prefer I get rid of this propriety and simply check if
gpio properties are absence or not in the driver ?

In such case I'll do in next version.

>> +
>> +Example (poll):
>> +
>> + ucs1002: ucs1002@57 {
>> + compatible = "microchip,ucs1002";
>> + reg = <0x57>;
>> + microchip,current-limit = <200>;
>> + microchip,pin-ignore;
>> + };
>> +
>> +Example (interrupts + pin control):
>> +
>> + ucs1002: ucs1002@57 {
>> + compatible = "microchip,ucs1002";
>> + reg = <0x57>;
>> + interrupt-parent = <>;
>> + interrupts = <30 0>, <31 0>;
>> + microchip,current-limit = <200>;
>> + em-gpios = < 2 GPIO_ACTIVE_HIGH>;
>> + m1-gpios = < 3 GPIO_ACTIVE_HIGH>;
>> + m2-gpios = < 17 GPIO_ACTIVE_HIGH>;
>> + pwr-gpios = < 19 0>;
>> + };
>> --
>> 2.1.0
>>

Best regards,
Enric

Re: [PATCH v2 2/2] gpio: Add driver for SPI serializers

[Sean Nyekjær]

On 2016-01-25 17:37, Andrew F. Davis wrote:

Add generic parallel-in/serial-out shift register GPIO driver.

This includes SPI compatible devices like SN74165 serial-out shift
registers and the SN65HVS88x series of industrial serializers that can
be read over the SPI bus and used for GPI (General Purpose Input).

Signed-off-by: Andrew F. Davis 
---
  drivers/gpio/Kconfig   |   6 ++
  drivers/gpio/Makefile  |   1 +
  drivers/gpio/gpio-pisosr.c | 188 +
  3 files changed, 195 insertions(+)
  create mode 100644 drivers/gpio/gpio-pisosr.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index c88dd24..bec3489 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -1011,6 +1011,12 @@ config GPIO_MC33880
  SPI driver for Freescale MC33880 high-side/low-side switch.
  This provides GPIO interface supporting inputs and outputs.
  
+config GPIO_PISOSR

+   tristate "Generic parallel-in/serial-out shift register"
+   help
+ GPIO driver for SPI compatible parallel-in/serial-out shift
+ registers. These are input only devices.
+
  endmenu
  
  menu "SPI or I2C GPIO expanders"

diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index ece7d7c..8e4f09f 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -75,6 +75,7 @@ obj-$(CONFIG_GPIO_OMAP)   += gpio-omap.o
  obj-$(CONFIG_GPIO_PCA953X)+= gpio-pca953x.o
  obj-$(CONFIG_GPIO_PCF857X)+= gpio-pcf857x.o
  obj-$(CONFIG_GPIO_PCH)+= gpio-pch.o
+obj-$(CONFIG_GPIO_PISOSR)  += gpio-pisosr.o
  obj-$(CONFIG_GPIO_PL061)  += gpio-pl061.o
  obj-$(CONFIG_GPIO_PXA)+= gpio-pxa.o
  obj-$(CONFIG_GPIO_RC5T583)+= gpio-rc5t583.o
diff --git a/drivers/gpio/gpio-pisosr.c b/drivers/gpio/gpio-pisosr.c
new file mode 100644
index 000..58ea08d
--- /dev/null
+++ b/drivers/gpio/gpio-pisosr.c
@@ -0,0 +1,188 @@
+/*
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
+ * Andrew F. Davis 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License version 2 for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEFAULT_NGPIO 8
+
+/**
+ * struct pisosr_gpio - GPIO driver data
+ * @chip: GPIO controller chip
+ * @spi: SPI device pointer
+ * @buffer: Buffer for device reads
+ * @buffer_size: Size of buffer
+ * @load_gpio: GPIO pin used to load input into device
+ * @lock: Protects read sequences
+ */
+struct pisosr_gpio {
+   struct gpio_chip chip;
+   struct spi_device *spi;
+   u8 *buffer;
+   size_t buffer_size;
+   struct gpio_desc *load_gpio;
+   struct mutex lock;
+};
+
+static int pisosr_gpio_refresh(struct pisosr_gpio *gpio)
+{
+   int ret;
+
+   mutex_lock(>lock);
+
+   if (gpio->load_gpio) {
+   gpiod_set_value(gpio->load_gpio, 1);
+   udelay(1); /* registers load time (~10ns) */
+   gpiod_set_value(gpio->load_gpio, 0);
+   udelay(1); /* registers recovery time (~5ns) */
+   }
+
+   ret = spi_read(gpio->spi, gpio->buffer, gpio->buffer_size);
+   if (ret)
+   return ret;
+
+   mutex_unlock(>lock);
+
+   return 0;
+}
+
+static int pisosr_gpio_get_direction(struct gpio_chip *chip,
+unsigned offset)
+{
+   /* This device always input */
+   return 1;
+}
+
+static int pisosr_gpio_direction_input(struct gpio_chip *chip,
+  unsigned offset)
+{
+   /* This device always input */
+   return 0;
+}
+
+static int pisosr_gpio_direction_output(struct gpio_chip *chip,
+   unsigned offset, int value)
+{
+   /* This device is input only */
+   return -EINVAL;
+}
+
+static int pisosr_gpio_get(struct gpio_chip *chip, unsigned offset)
+{
+   struct pisosr_gpio *gpio = gpiochip_get_data(chip);
+
+   /* Refresh may not always be needed */
+   pisosr_gpio_refresh(gpio);
+
+   return (gpio->buffer[offset / 8] >> (offset % 8)) & 0x1;
+}
+
+static struct gpio_chip template_chip = {
+   .label  = "pisosr-gpio",
+   .owner  = THIS_MODULE,
+   .get_direction  = pisosr_gpio_get_direction,
+   .direction_input= pisosr_gpio_direction_input,
+   .direction_output   = pisosr_gpio_direction_output,
+   .get= pisosr_gpio_get,
+   .base   = -1,
+   .ngpio  = DEFAULT_NGPIO,
+   .can_sleep   

Re: [PATCH] ASoC: fsl: select SND_SOC_FSL_SAI or SND_SOC_FSL_SSI depending on SoC type

[Nicolin Chen]

On Fri, Jan 29, 2016 at 06:59:38AM +0100, Lothar Waßmann wrote:
> Hi,
> 
> On Thu, 28 Jan 2016 23:33:52 +0100 Mark Brown wrote:
> > On Wed, Jan 20, 2016 at 01:30:38PM +0100, Lothar Waßmann wrote:
> > 
> > > - select SND_SOC_FSL_SSI
> > > + select SND_SOC_FSL_SAI if SOC_IMX6UL
> > > + select SND_SOC_FSL_SSI if SOC_IMX6Q || SOC_IMX6SL || SOC_IMX6SX
> > 
> > Does this card not work for older i.MXs (which had the same SSI/AUDMUX
> > combination as the majority of the i.MX6 family) as well?
> >
> Our baseboard contains an SGTL5000 codec which is working with
> i.MX25, i.MX27, i.MX5, i.MX6Q, i.MX6DL with the fsl_ssi and imx-sgtl5000
> + imx-audmux driver, on i.MX28 with the mxs-saif and mxs-sgtl5000 driver
> and on i.MX6UL with the fsl_sai + simple-card driver.

Have you tried fsl-asoc-card to connect SSI/SAI with sgtl5000? If it
works for you directly, I believe things should be easier for you
instead of dealing with Kconfig.

Re: [PATCH] ALSA: hda - Add new GPU codec ID 0x10de0083 to snd-hda

[Takashi Iwai]

On Thu, 28 Jan 2016 23:07:38 +0100,
Aaron Plattner wrote:
> 
> Vendor ID 0x10de0083 is used by a yet-to-be-named GPU chip.
> 
> This chip also has the 2-ch audio swapping bug, so patch_nvhdmi is
> appropriate here.
> 
> Signed-off-by: Aaron Plattner 
> ---
> The hardware guys identified the problem and claim it will be fixed in a 
> future
> chip.

OK, applied now as is.  Thanks.


Takashi

> 
>  sound/pci/hda/patch_hdmi.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> index 426a29a1c19b..1f52b55d77c9 100644
> --- a/sound/pci/hda/patch_hdmi.c
> +++ b/sound/pci/hda/patch_hdmi.c
> @@ -3653,6 +3653,7 @@ HDA_CODEC_ENTRY(0x10de0070, "GPU 70 HDMI/DP",   
> patch_nvhdmi),
>  HDA_CODEC_ENTRY(0x10de0071, "GPU 71 HDMI/DP",patch_nvhdmi),
>  HDA_CODEC_ENTRY(0x10de0072, "GPU 72 HDMI/DP",patch_nvhdmi),
>  HDA_CODEC_ENTRY(0x10de007d, "GPU 7d HDMI/DP",patch_nvhdmi),
> +HDA_CODEC_ENTRY(0x10de0083, "GPU 83 HDMI/DP",patch_nvhdmi),
>  HDA_CODEC_ENTRY(0x10de8001, "MCP73 HDMI",patch_nvhdmi_2ch),
>  HDA_CODEC_ENTRY(0x11069f80, "VX900 HDMI/DP", patch_via_hdmi),
>  HDA_CODEC_ENTRY(0x11069f81, "VX900 HDMI/DP", patch_via_hdmi),
> -- 
> 2.7.0
> 
> 

Re: [PATCH] ASoC: fsl: select SND_SOC_FSL_SAI or SND_SOC_FSL_SSI depending on SoC type

[Nicolin Chen]

On Fri, Jan 29, 2016 at 06:51:33AM +0100, Lothar Waßmann wrote:
> Hi,
> 
> On Thu, 28 Jan 2016 15:08:47 -0800 Nicolin Chen wrote:
> > On Thu, Jan 28, 2016 at 11:33:52PM +0100, Mark Brown wrote:
> > > On Wed, Jan 20, 2016 at 01:30:38PM +0100, Lothar Waßmann wrote:
> > > 
> > > > -   select SND_SOC_FSL_SSI
> > > > +   select SND_SOC_FSL_SAI if SOC_IMX6UL
> > > > +   select SND_SOC_FSL_SSI if SOC_IMX6Q || SOC_IMX6SL || SOC_IMX6SX
> > > 
> > > Does this card not work for older i.MXs (which had the same SSI/AUDMUX
> > > combination as the majority of the i.MX6 family) as well?
> > 
> > It's widely used in older i.MXs according to their DTS files. So
> > it should be safer to just leave SSI over here.
> > 
> Nothing prevents you to enable the SSI driver on any i.MX6 module.

What about i.MX2, 3 and 5 series? Will they still be able to enable
SSI without changing .config file as usual?

> The only change I made is to select the SAI driver instead of the SSI
> driver on i.MX6UL because the i.MX6UL does not have an SSI unit!
> 
> > And I actually doubt the feasibility of running this driver with
> > i.MX6UL as there might not be an AUDMUX on i.MX6UL since it does
> > not have SSI any more while the driver always touches the address
> > space of AUDMUX which may not exist on i.MX6UL.
> >
> #define this driver

Your change is applied to "SND_SOC_IMX_SGTL5000" whose corresponding
driver is the imx-sgtl5000.c file.

> The FSL_SAI driver does not touch the audmux address space in any way.

This imx-sgtl5000 driver does access AUDMUX registers. And I thought
you tried to use this one which made me very confused.

> The simple-card audio driver works perfectly well with the FSL_SAI
> driver on i.MX6UL.

It seems like you are using simple-card while letting the other driver
(imx-sgtl5000) select SAI for you. It doesn't sound so right to me.

Re: [PATCH] Staging: panel: fix the checkpatch issue

[Greg KH]

On Mon, Jan 18, 2016 at 12:40:48AM +0530, SirnamSwetha wrote:
> Fix checkpatch.pl issue:
> 
> WARNING: line over 80 characters
> 
> CHECK: No space is necessary after a cast
> 
> Signed-off-by: SirnamSwetha 
> ---
>  drivers/staging/panel/panel.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)

Sorry, someone sent this before you did :(

Re: [PATCH 1/1] staging: coding style cleanups for staging/panel driver

[Greg KH]

On Sat, Dec 19, 2015 at 12:50:56AM +0530, Bijosh Thykkoottathil wrote:
> From: Bijosh Thykkoottathil 
> 
> This patch fixes coding style errors for staging/panel driver.
> 
> Signed-off-by: Bijosh Thykkoottathil 
> ---
>  drivers/staging/panel/panel.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)

Someone sent this change before you, sorry :(

Re: [PATCH v4] lib/spinlock_debug.c: prevent a recursive cycle in the debug code

[Sergey Senozhatsky]

On (01/28/16 21:48), Peter Hurley wrote:
[..]
> > yes, I proposed to add a ->reset callback to struct console
> > a while ago, and to do a console reset loop in zap_locks()
> 
> What was the patch series title? I'd like to review that.

Thanks.

it was deep in the thread where Jan Kara proposed v1 of his
printk offloading support
"Re: [PATCH 1/7] printk: Hand over printing to console if printing too long"

 http://marc.info/?l=linux-kernel=144976121529901

I never ended up sending this out as a separate patch. my bad.

the panic()->zap_locks() was here (well, not even a patch set):
 http://marc.info/?l=linux-kernel=145260677129044

> That would solve the recursive deadlock from console driver as well
> (at least with CONFIG_DEBUG_SPINLOCK) because the printk() recursion
> would zap the locks including the console driver's lock and
> at least get the last output so that we'd know there was a recursion,
> and fix it.

yes, if printk() has a chance to detect a recursion and invoke zap_locks()
(which is based on logbuf_cpu check). in my other email there is a scenario
when printk() has no such a chance -- because 'logbuf_cpu' is set to UINT_MAX
right before raw_spin_unlock(_lock). and if debug_spin_unlock() detects
a coding error (not even a corruption) (->owner != current, or
->owner_cpu != raw_smp_processor_id()) then things are turning bad quickly.

mail: http://marc.info/?l=linux-kernel=145404023915268

-ss

[PATCH RFC] blk-mq: no need to modify bt->wake_index if someone has updated it

[Wenbo Wang]

If someone else has found active waitqueue and updated
bt->wake_index, do not modify it again. This saves an
atomic read.

Signed-off-by: Wenbo Wang 
CC: linux-bl...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
---
 block/blk-mq-tag.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
index abdbb47..5ed9111 100644
--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
@@ -356,16 +356,15 @@ unsigned int blk_mq_get_tag(struct blk_mq_alloc_data 
*data)
 
 static struct bt_wait_state *bt_wake_ptr(struct blk_mq_bitmap_tags *bt)
 {
-   int i, wake_index;
+   int i, wake_index, orig_wake_index;
 
-   wake_index = atomic_read(>wake_index);
+   orig_wake_index = wake_index = atomic_read(>wake_index);
for (i = 0; i < BT_WAIT_QUEUES; i++) {
struct bt_wait_state *bs = >bs[wake_index];
 
if (waitqueue_active(>wait)) {
-   int o = atomic_read(>wake_index);
-   if (wake_index != o)
-   atomic_cmpxchg(>wake_index, o, wake_index);
+   if (wake_index != orig_wake_index)
+   atomic_cmpxchg(>wake_index, 
orig_wake_index, wake_index);
 
return bs;
}
-- 
1.8.3.1
---
Not seeing too much benifit from this patch, but it makes the logic here more 
clear

Re: [PATCH v4 0/5] pinctrl: mediatek: add pinctrl/GPIO/EINT driver for mt2701

[biao huang]

Hi Linus,
[PATCH v4 1/5] pinctrl: mediatek: fix direction control issue
this patch is also a pinctrl patch, and it seems not merged in
devel-mt2701 branch.

Best Regards!
Yours,
Biao Huang

On Thu, 2016-01-28 at 11:20 +0100, Linus Walleij wrote:
> On Wed, Jan 27, 2016 at 2:24 AM, Biao Huang  wrote:
> 
> > Change in v4:
> > 1. create a sperate patch for direction setting of input-enable/disalbe and 
> > input-schmitt-enable/disable.
> 
> So I've merged the patches affecting drivers/pinctrl on the special
> devel-mt2701 branch, so the ARM SoC people can pull this into
> their tree to resolve dependencies on the pinctrl include
> in include/dt-bindings.
> https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-pinctrl.git/log/?h=devel-mt2701
> 
> The rest of the patches should go into ARM SoC, so they can
> just pull this branch in and apply that stuff on top.
> 
> Allow this a few days, I am also waiting for the add-on patches
> from John Crispin to come in, please include John in the
> feedback loop.
> 
> Yours,
> Linus Walleij

Re: [PATCH] ASoC: fsl: select SND_SOC_FSL_SAI or SND_SOC_FSL_SSI depending on SoC type

[Lothar Waßmann]

Hi,

On Thu, 28 Jan 2016 23:33:52 +0100 Mark Brown wrote:
> On Wed, Jan 20, 2016 at 01:30:38PM +0100, Lothar Waßmann wrote:
> 
> > -   select SND_SOC_FSL_SSI
> > +   select SND_SOC_FSL_SAI if SOC_IMX6UL
> > +   select SND_SOC_FSL_SSI if SOC_IMX6Q || SOC_IMX6SL || SOC_IMX6SX
> 
> Does this card not work for older i.MXs (which had the same SSI/AUDMUX
> combination as the majority of the i.MX6 family) as well?
>
Our baseboard contains an SGTL5000 codec which is working with
i.MX25, i.MX27, i.MX5, i.MX6Q, i.MX6DL with the fsl_ssi and imx-sgtl5000
+ imx-audmux driver, on i.MX28 with the mxs-saif and mxs-sgtl5000 driver
and on i.MX6UL with the fsl_sai + simple-card driver.


Lothar Waßmann

[PATCH] perf build: Remove all condition feature check {C,LD}FLAGS

[Wang Nan]

'make feature-dump' should give a stable result, so even 'NO_SOMETHING=1'
is given (for babeltrace, if LIBBABELTRACE=1 is not given), we should
try to detect those feature and {C,LD}FLAGS. Build or not should be
controled independent.

Signed-off-by: Wang Nan 
Cc: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
Cc: Li Zefan 
---
 tools/perf/config/Makefile | 101 +
 1 file changed, 47 insertions(+), 54 deletions(-)

diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index 511141b..0045a5d 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -61,50 +61,45 @@ endif
 
 ifeq ($(LIBUNWIND_LIBS),)
   NO_LIBUNWIND := 1
-else
-  #
-  # For linking with debug library, run like:
-  #
-  #   make DEBUG=1 LIBUNWIND_DIR=/opt/libunwind/
-  #
-  ifdef LIBUNWIND_DIR
-LIBUNWIND_CFLAGS  = -I$(LIBUNWIND_DIR)/include
-LIBUNWIND_LDFLAGS = -L$(LIBUNWIND_DIR)/lib
-  endif
-  LIBUNWIND_LDFLAGS += $(LIBUNWIND_LIBS)
-
-  # Set per-feature check compilation flags
-  FEATURE_CHECK_CFLAGS-libunwind = $(LIBUNWIND_CFLAGS)
-  FEATURE_CHECK_LDFLAGS-libunwind = $(LIBUNWIND_LDFLAGS)
-  FEATURE_CHECK_CFLAGS-libunwind-debug-frame = $(LIBUNWIND_CFLAGS)
-  FEATURE_CHECK_LDFLAGS-libunwind-debug-frame = $(LIBUNWIND_LDFLAGS)
 endif
+#
+# For linking with debug library, run like:
+#
+#   make DEBUG=1 LIBUNWIND_DIR=/opt/libunwind/
+#
+ifdef LIBUNWIND_DIR
+  LIBUNWIND_CFLAGS  = -I$(LIBUNWIND_DIR)/include
+  LIBUNWIND_LDFLAGS = -L$(LIBUNWIND_DIR)/lib
+endif
+LIBUNWIND_LDFLAGS += $(LIBUNWIND_LIBS)
+
+# Set per-feature check compilation flags
+FEATURE_CHECK_CFLAGS-libunwind = $(LIBUNWIND_CFLAGS)
+FEATURE_CHECK_LDFLAGS-libunwind = $(LIBUNWIND_LDFLAGS)
+FEATURE_CHECK_CFLAGS-libunwind-debug-frame = $(LIBUNWIND_CFLAGS)
+FEATURE_CHECK_LDFLAGS-libunwind-debug-frame = $(LIBUNWIND_LDFLAGS)
 
 ifeq ($(NO_PERF_REGS),0)
   CFLAGS += -DHAVE_PERF_REGS_SUPPORT
 endif
 
-ifndef NO_LIBELF
-  # for linking with debug library, run like:
-  # make DEBUG=1 LIBDW_DIR=/opt/libdw/
-  ifdef LIBDW_DIR
-LIBDW_CFLAGS  := -I$(LIBDW_DIR)/include
-LIBDW_LDFLAGS := -L$(LIBDW_DIR)/lib
-  endif
-  FEATURE_CHECK_CFLAGS-libdw-dwarf-unwind := $(LIBDW_CFLAGS)
-  FEATURE_CHECK_LDFLAGS-libdw-dwarf-unwind := $(LIBDW_LDFLAGS) -ldw
+# for linking with debug library, run like:
+# make DEBUG=1 LIBDW_DIR=/opt/libdw/
+ifdef LIBDW_DIR
+  LIBDW_CFLAGS  := -I$(LIBDW_DIR)/include
+  LIBDW_LDFLAGS := -L$(LIBDW_DIR)/lib
 endif
+FEATURE_CHECK_CFLAGS-libdw-dwarf-unwind := $(LIBDW_CFLAGS)
+FEATURE_CHECK_LDFLAGS-libdw-dwarf-unwind := $(LIBDW_LDFLAGS) -ldw
 
-ifdef LIBBABELTRACE
-  # for linking with debug library, run like:
-  # make DEBUG=1 LIBBABELTRACE_DIR=/opt/libbabeltrace/
-  ifdef LIBBABELTRACE_DIR
-LIBBABELTRACE_CFLAGS  := -I$(LIBBABELTRACE_DIR)/include
-LIBBABELTRACE_LDFLAGS := -L$(LIBBABELTRACE_DIR)/lib
-  endif
-  FEATURE_CHECK_CFLAGS-libbabeltrace := $(LIBBABELTRACE_CFLAGS)
-  FEATURE_CHECK_LDFLAGS-libbabeltrace := $(LIBBABELTRACE_LDFLAGS) 
-lbabeltrace-ctf
+# for linking with debug library, run like:
+# make DEBUG=1 LIBBABELTRACE_DIR=/opt/libbabeltrace/
+ifdef LIBBABELTRACE_DIR
+  LIBBABELTRACE_CFLAGS  := -I$(LIBBABELTRACE_DIR)/include
+  LIBBABELTRACE_LDFLAGS := -L$(LIBBABELTRACE_DIR)/lib
 endif
+FEATURE_CHECK_CFLAGS-libbabeltrace := $(LIBBABELTRACE_CFLAGS)
+FEATURE_CHECK_LDFLAGS-libbabeltrace := $(LIBBABELTRACE_LDFLAGS) 
-lbabeltrace-ctf
 
 FEATURE_CHECK_CFLAGS-bpf = -I. -I$(srctree)/tools/include 
-I$(srctree)/arch/$(ARCH)/include/uapi -I$(srctree)/include/uapi
 # include ARCH specific config
@@ -145,28 +140,26 @@ ifdef PARSER_DEBUG
   $(call detected_var,PARSER_DEBUG_FLEX)
 endif
 
-ifndef NO_LIBPYTHON
-  # Try different combinations to accommodate systems that only have
-  # python[2][-config] in weird combinations but always preferring
-  # python2 and python2-config as per pep-0394. If we catch a
-  # python[-config] in version 3, the version check will kill it.
-  PYTHON2 := $(if $(call get-executable,python2),python2,python)
-  override PYTHON := $(call get-executable-or-default,PYTHON,$(PYTHON2))
-  PYTHON2_CONFIG := \
-$(if $(call 
get-executable,$(PYTHON)-config),$(PYTHON)-config,python-config)
-  override PYTHON_CONFIG := \
-$(call get-executable-or-default,PYTHON_CONFIG,$(PYTHON2_CONFIG))
+# Try different combinations to accommodate systems that only have
+# python[2][-config] in weird combinations but always preferring
+# python2 and python2-config as per pep-0394. If we catch a
+# python[-config] in version 3, the version check will kill it.
+PYTHON2 := $(if $(call get-executable,python2),python2,python)
+override PYTHON := $(call get-executable-or-default,PYTHON,$(PYTHON2))
+PYTHON2_CONFIG := \
+  $(if $(call get-executable,$(PYTHON)-config),$(PYTHON)-config,python-config)
+override PYTHON_CONFIG := \
+  $(call get-executable-or-default,PYTHON_CONFIG,$(PYTHON2_CONFIG))
 
-  PYTHON_CONFIG_SQ := $(call shell-sq,$(PYTHON_CONFIG))
+PYTHON_CONFIG_SQ := $(call 

Re: [PATCH 3.10 00/53] 3.10.96-stable review

[Greg Kroah-Hartman]

On Thu, Jan 28, 2016 at 03:04:19AM -0800, kernelci.org bot wrote:
> stable-queue boot: 53 boots: 1 failed, 52 passed (v3.10.95-53-g3ebc76ed4936)
> 
> Full Boot Summary: 
> https://kernelci.org/boot/all/job/stable-queue/kernel/v3.10.95-53-g3ebc76ed4936/
> Full Build Summary: 
> https://kernelci.org/build/stable-queue/kernel/v3.10.95-53-g3ebc76ed4936/
> 
> Tree: stable-queue
> Branch: local/linux-3.10.y.queue
> Git Describe: v3.10.95-53-g3ebc76ed4936
> Git Commit: 3ebc76ed49369086e6593e41fb7de89f4de5773a
> Git URL: git://server.roeck-us.net/git/linux-stable.git
> Tested: 27 unique boards, 12 SoC families, 16 builds out of 142
> 
> Boot Failure Detected: 
> https://kernelci.org/boot/?v3.10.95-53-g3ebc76ed4936
> 
> arm:
> 
> omap2plus_defconfig:
> omap4-panda: 1 failed lab

I'm guessing this failure is ok :)

thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH 3.10 00/53] 3.10.96-stable review

[Greg Kroah-Hartman]

On Wed, Jan 27, 2016 at 05:59:47PM -0800, Guenter Roeck wrote:
> On 01/27/2016 10:15 AM, Greg Kroah-Hartman wrote:
> >-
> >NOTE:
> >   There are still a lot of pending stable patches in the queue, well
> >   over 400 of them to be specific, so some of your favorite/pet patches
> >   might not be included in these releases.  Please be patient as I dig
> >   out from this backlog over the next few weeks.  If there are specific
> >   patches that you just _must_ have included in a stable release soon,
> >   please let me know.
> >-
> >
> >This is the start of the stable review cycle for the 3.10.96 release.
> >There are 53 patches in this series, all will be posted as a response
> >to this one.  If anyone has any issues with these being applied, please
> >let me know.
> >
> >Responses should be made by Fri Jan 29 18:06:17 UTC 2016.
> >Anything received after that time might be too late.
> 
> Build results:
>   total: 122 pass: 122 fail: 0
> Qemu test results:
>   total: 72 pass: 72 fail: 0
> 
> Details are available at http://kerneltests.org/builders.

Thanks for testing all of these and letting me know.

greg k-h

Duplicated module names

[Rusty Russell]

Lucas De Marchi  writes:
> Hi!
>
> CC'ing Rusty and mailing lists

Thanks.

> Rusty and ohers: it looks like both CONFIG_CRC32 and
> CONFIG_CRYPTO_CRC32 can be compiled as module, and they generate
> modules with the same name, crc32.  Could that be fixed?

Gah.  Looks like it's been that way since at least 2014, too.

I think we could rename it to crypto_crc32, but I don't think it's the
only one.  Marco, I think depmod should probably FAIL if two modules
have the same name, which would at least find such problems.

(BTW is there a nice way to figure out if a config var is a tristate?  These
are only problematic if both CONFIG_ are tristate.)

Here's a hacky attempt to look for problems:

rusty@rusty-Lemur:~/devel/kernel/linux (master)$ KCONFIGS=`find * -name 
'Kconfig*'`; for m in `find [b-z]* -name 'Makefile*'`; do sed -n 
's,obj-\$(CONFIG.*+= \([a-z0-9_-]\+\.o\)$,'$m' \1,p' <$m | sort -u; done | sort 
-k 2 | uniq -D -f 1 | while read m obj; do fgrep -w $obj $m /dev/null; done | 
while read LINE; do conf=`echo $LINE | sed 
's/.*\$(CONFIG_\([A-Z0-9_]*\).*/\1/'`; if grep -C2 "^config $conf\$" $KCONFIGS 
| fgrep -q tristate; then echo $LINE; fi; done

Here are the results (mildly filtered by me):

drivers/gpu/drm/i2c/Makefile:obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
drivers/media/i2c/Makefile:obj-$(CONFIG_VIDEO_ADV7511) += adv7511.o

drivers/media/platform/coda/Makefile:obj-$(CONFIG_VIDEO_CODA) += coda.o
fs/coda/Makefile:obj-$(CONFIG_CODA_FS) += coda.o

drivers/gpu/drm/omapdrm/displays/Makefile:obj-$(CONFIG_DISPLAY_CONNECTOR_ANALOG_TV)
 += connector-analog-tv.o
drivers/video/fbdev/omap2/omapfb/displays/Makefile:obj-$(CONFIG_FB_OMAP2_CONNECTOR_ANALOG_TV)
 += connector-analog-tv.o

drivers/gpu/drm/omapdrm/displays/Makefile:obj-$(CONFIG_DISPLAY_CONNECTOR_DVI) 
+= connector-dvi.o
drivers/video/fbdev/omap2/omapfb/displays/Makefile:obj-$(CONFIG_FB_OMAP2_CONNECTOR_DVI)
 += connector-dvi.o

drivers/gpu/drm/omapdrm/displays/Makefile:obj-$(CONFIG_DISPLAY_CONNECTOR_HDMI) 
+= connector-hdmi.o
drivers/video/fbdev/omap2/omapfb/displays/Makefile:obj-$(CONFIG_FB_OMAP2_CONNECTOR_HDMI)
 += connector-hdmi.o

crypto/Makefile:obj-$(CONFIG_CRYPTO_CRC32) += crc32.o
lib/Makefile:obj-$(CONFIG_CRC32) += crc32.o

drivers/gpu/drm/omapdrm/displays/Makefile:obj-$(CONFIG_DISPLAY_ENCODER_OPA362) 
+= encoder-opa362.o
drivers/video/fbdev/omap2/omapfb/displays/Makefile:obj-$(CONFIG_FB_OMAP2_ENCODER_OPA362)
 += encoder-opa362.o

drivers/gpu/drm/omapdrm/displays/Makefile:obj-$(CONFIG_DISPLAY_ENCODER_TFP410) 
+= encoder-tfp410.o
drivers/video/fbdev/omap2/omapfb/displays/Makefile:obj-$(CONFIG_FB_OMAP2_ENCODER_TFP410)
 += encoder-tfp410.o

drivers/gpu/drm/omapdrm/displays/Makefile:obj-$(CONFIG_DISPLAY_ENCODER_TPD12S015)
 += encoder-tpd12s015.o
drivers/video/fbdev/omap2/omapfb/displays/Makefile:obj-$(CONFIG_FB_OMAP2_ENCODER_TPD12S015)
 += encoder-tpd12s015.o

drivers/gpu/drm/omapdrm/displays/Makefile:obj-$(CONFIG_DISPLAY_PANEL_DPI) += 
panel-dpi.o
drivers/video/fbdev/omap2/omapfb/displays/Makefile:obj-$(CONFIG_FB_OMAP2_PANEL_DPI)
 += panel-dpi.o

drivers/gpu/drm/omapdrm/displays/Makefile:obj-$(CONFIG_DISPLAY_PANEL_DSI_CM) += 
panel-dsi-cm.o
drivers/video/fbdev/omap2/omapfb/displays/Makefile:obj-$(CONFIG_FB_OMAP2_PANEL_DSI_CM)
 += panel-dsi-cm.o

drivers/gpu/drm/omapdrm/displays/Makefile:obj-$(CONFIG_DISPLAY_PANEL_LGPHILIPS_LB035Q02)
 += panel-lgphilips-lb035q02.o
drivers/video/fbdev/omap2/omapfb/displays/Makefile:obj-$(CONFIG_FB_OMAP2_PANEL_LGPHILIPS_LB035Q02)
 += panel-lgphilips-lb035q02.o

drivers/gpu/drm/omapdrm/displays/Makefile:obj-$(CONFIG_DISPLAY_PANEL_NEC_NL8048HL11)
 += panel-nec-nl8048hl11.o
drivers/video/fbdev/omap2/omapfb/displays/Makefile:obj-$(CONFIG_FB_OMAP2_PANEL_NEC_NL8048HL11)
 += panel-nec-nl8048hl11.o

drivers/gpu/drm/omapdrm/displays/Makefile:obj-$(CONFIG_DISPLAY_PANEL_SHARP_LS037V7DW01)
 += panel-sharp-ls037v7dw01.o
drivers/video/fbdev/omap2/omapfb/displays/Makefile:obj-$(CONFIG_FB_OMAP2_PANEL_SHARP_LS037V7DW01)
 += panel-sharp-ls037v7dw01.o

drivers/gpu/drm/omapdrm/displays/Makefile:obj-$(CONFIG_DISPLAY_PANEL_SONY_ACX565AKM)
 += panel-sony-acx565akm.o
drivers/video/fbdev/omap2/omapfb/displays/Makefile:obj-$(CONFIG_FB_OMAP2_PANEL_SONY_ACX565AKM)
 += panel-sony-acx565akm.o

drivers/gpu/drm/omapdrm/displays/Makefile:obj-$(CONFIG_DISPLAY_PANEL_TPO_TD028TTEC1)
 += panel-tpo-td028ttec1.o
drivers/video/fbdev/omap2/omapfb/displays/Makefile:obj-$(CONFIG_FB_OMAP2_PANEL_TPO_TD028TTEC1)
 += panel-tpo-td028ttec1.o

drivers/gpu/drm/omapdrm/displays/Makefile:obj-$(CONFIG_DISPLAY_PANEL_TPO_TD043MTEA1)
 += panel-tpo-td043mtea1.o
drivers/video/fbdev/omap2/omapfb/displays/Makefile:obj-$(CONFIG_FB_OMAP2_PANEL_TPO_TD043MTEA1)
 += panel-tpo-td043mtea1.o

drivers/mtd/onenand/Makefile:obj-$(CONFIG_MTD_ONENAND_SAMSUNG) += samsung.o
drivers/tty/serial/Makefile:obj-$(CONFIG_SERIAL_SAMSUNG) += samsung.o

sound/soc/codecs/Makefile:obj-$(CONFIG_SND_SOC_AC97_CODEC) += snd-soc-ac97.o
sound/soc/samsung/Makefile:obj-$(CONFIG_SND_SAMSUNG_AC97) += 

Re: [PATCH] ASoC: fsl: select SND_SOC_FSL_SAI or SND_SOC_FSL_SSI depending on SoC type

[Lothar Waßmann]

Hi,

On Thu, 28 Jan 2016 15:08:47 -0800 Nicolin Chen wrote:
> On Thu, Jan 28, 2016 at 11:33:52PM +0100, Mark Brown wrote:
> > On Wed, Jan 20, 2016 at 01:30:38PM +0100, Lothar Waßmann wrote:
> > 
> > > - select SND_SOC_FSL_SSI
> > > + select SND_SOC_FSL_SAI if SOC_IMX6UL
> > > + select SND_SOC_FSL_SSI if SOC_IMX6Q || SOC_IMX6SL || SOC_IMX6SX
> > 
> > Does this card not work for older i.MXs (which had the same SSI/AUDMUX
> > combination as the majority of the i.MX6 family) as well?
> 
> It's widely used in older i.MXs according to their DTS files. So
> it should be safer to just leave SSI over here.
> 
Nothing prevents you to enable the SSI driver on any i.MX6 module.
The only change I made is to select the SAI driver instead of the SSI
driver on i.MX6UL because the i.MX6UL does not have an SSI unit!

> And I actually doubt the feasibility of running this driver with
> i.MX6UL as there might not be an AUDMUX on i.MX6UL since it does
> not have SSI any more while the driver always touches the address
> space of AUDMUX which may not exist on i.MX6UL.
>
#define this driver
The FSL_SAI driver does not touch the audmux address space in any way.
The simple-card audio driver works perfectly well with the FSL_SAI
driver on i.MX6UL.


Lothar Waßmann

Re: [PATCH V2 1/4] mfd: f81504-core: Add Fintek F81504/508/512 PCIE-to-UART/GPIO core support

[Peter Hung]

Hi Andy,

Andy Shevchenko 於 2016/1/28 下午 07:55 寫道:

+default y


I'm not sure we have to have this always y. Perhaps
default SERIAL_8250_PCI


Your comment is right, this device major function is serial port.
GPIO maybe not enabled by H/W manufacturer.

I'll set it default with SERIAL_8250_PCI.


+obj-$(CONFIG_MFD_FINTEK_F81504_CORE)   += f81504-core.o


I think '_' is better than '-'. What I saw and usually do is '_' for
regular source modules and '-' for the resulting objects when they have
more than one file.


I used f81504_core.c originally, but I found most of files are named
xxx-ooo.c when I try to modify makefile. Should I change it to
f81504_core.c ??



+#define F81504_DEV_DESC"Fintek F81504/508/512 PCIE-
to-UART core"


Do you need this definition? Is it used more than once?


ok, I'll direct use the string without define.



+static int f81504_port_init(struct pci_dev *dev)
+{
+   size_t i, j;
+   u32 max_port, iobase, gpio_addr;
+   u32 bar_data[3];
+   u16 tmp;
+   u8 config_base, gpio_en, f0h_data, f3h_data;
+   bool is_gpio;
+   struct f81504_pci_private *priv = pci_get_drvdata(dev);


I would suggest to rearrange definition block here (and in the rest of
the functions in entire series) to somehow follow the following pattern

1) assignments go first, especially container_of() based ones;
2) group variables by meaning and put longer lines upper;
3) return value variable, if exists, goes last.

Besides that choose types carefully. If there is known limit for
counters, no need to define wider type than needed. Use proper types
for corresponding values.


I'll try to rearrange the definition blocks.
For the counter issue, some senior recommend me to change count from int
to size_t for performance. In this case, should I use u8 to replace
i & j ? It should be less than 12 & 6.


+
+   /* Init GPIO IO Address */
+   pci_read_config_dword(dev, 0x18, _addr);
+   gpio_addr &= 0xffe0;




+   pci_write_config_byte(dev, F81504_GPIO_IO_LSB_REG, gpio_addr
& 0xff);
+   pci_write_config_byte(dev, F81504_GPIO_IO_MSB_REG,
(gpio_addr >> 8) &
+   0xff);


Could it be written at once as a word?


I tested with writing a word to "F81504_GPIO_IO_LSB_REG", but
it'll failed, so I'll remain it.


+   if (priv) {
+   /* Reinit from resume(), read the previous value
from priv */




+   gpio_en = priv->gpio_en;


I would suggest to move this line down to follow same pattern in else
branch.


The f81504_port_init() will be called probe()/resume().

We'll initialize gpio_en = (f0h | ~f3h) and save it in private data
when probe(), reload gpio_en from private data when resume().

The F81504/508/512 can be used EEPROM to override F0h/F3h on power
on. Some motherboard designer will put the IC on board and want to cost
down EEPROM. They will setting F0/F3h with ASL code, but without EEPROM
, the IC back from resume() will get F0/F3h with 0x00, so we should
save gpio_en when probe(), and restore it when resume().


+
+   /* re-save GPIO IO addr for called by resume() */


re-save -> Re-save
addr -> address


ok


+   priv->gpio_ioaddr = gpio_addr;
+   } else {
+   /* Driver first init */
+   pci_read_config_byte(dev, F81504_GPIO_ENABLE_REG,
_data);
+   pci_read_config_byte(dev, F81504_GPIO_MODE_REG,
_data);
+
+   /* find the max set of GPIOs */


Use one pattern for all comments, like "Capital letter first, and full
words avoiding abbreviations".


ok


+   case FINTEK_F81504: /* 4 ports */
+   /* F81504 max 2 sets of GPIO, others are max 6
sets*/


Space before * is needed.


ok


+   for (i = 0; i < max_port; ++i) {


i++, since it's more usual pattern.


ok


+   /* find every port to check is multi-function port?
*/
+   for (j = 0; j < ARRAY_SIZE(fintek_gpio_mapping);
++j) {
+   if (fintek_gpio_mapping[j] != i || !(gpio_en
& BIT(j)))
+   continue;
+
+   /*
+* This port is multi-function and enabled
as gpio
+* mode. So we'll not configure it as serial
port.
+*/
+   is_gpio = true;
+   break;
+   }


Looks like a separate function.

func()
{
  for () {
if ()
 return X;
  }
  return Y;
}


ok.



+   /* Select 128-byte FIFO and 8x FIFO threshold */
+   pci_write_config_byte(dev, config_base + 0x01,
0x33);
+
+   /* LSB UART */
+   pci_write_config_byte(dev, config_base + 0x04,
+   (u8)(iobase & 0xff));


Redundant explicit casting.


ok


+
+   /* MSB UART */
+   pci_write_config_byte(dev, config_base + 0x05,
+   (u8)((iobase & 0xff00) >> 8));


Ditto.

And 

Re: [PATCH 3.10 00/53] 3.10.96-stable review

[Greg Kroah-Hartman]

On Wed, Jan 27, 2016 at 04:29:35PM -0700, Shuah Khan wrote:
> On 01/27/2016 11:15 AM, Greg Kroah-Hartman wrote:
> > -
> > NOTE:
> >   There are still a lot of pending stable patches in the queue, well
> >   over 400 of them to be specific, so some of your favorite/pet patches
> >   might not be included in these releases.  Please be patient as I dig
> >   out from this backlog over the next few weeks.  If there are specific
> >   patches that you just _must_ have included in a stable release soon,
> >   please let me know.
> > -
> > 
> > This is the start of the stable review cycle for the 3.10.96 release.
> > There are 53 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Fri Jan 29 18:06:17 UTC 2016.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.10.96-rc1.gz
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions,

Thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH v4] lib/spinlock_debug.c: prevent a recursive cycle in the debug code

[Peter Hurley]

On 01/28/2016 09:28 PM, Sergey Senozhatsky wrote:
> On (01/28/16 20:32), Peter Hurley wrote:
> [..]
>> You're assuming that Byungchul's patch is relevant to the recursion
>> he witnessed. There are several paths into spin_dump().
> 
> yes. I was speaking in the context of Byungchul's report.
> 
>> Here's one that doesn't wait at all:
>>
>> vprintk_emit()
>>   console_trylock()
>> down_trylock()
>>   raw_spin_lock_irqsave()
>> ... 
>>   do_raw_spin_lock()
>> debug_spin_lock_before()
>>   SPIN_BUG_ON()
>> spin_bug()
>>spin_dump()
>>  printk()
>>** RINSE AND REPEAT **
> 
> ah, yes, agree.
> 
 Additionally, what if the console_sem is simply corrupted?
 A livelock with no output ever is not very helpful.
>>>
>>> if it's corrupted then this is not a spinlock debug problem.
>>> at all.
>>
>> I don't follow you.
>>
> 
> indeed very misleading, sorry, almost didn't sleep last nigh.
> removing SPIN_BUG_ON entirely is not my logic, not all. printk locks are
> special, I agree. in context of the proposed patch - we can't disable
> spin_dump() for printk locks if they were corrupted. for printk locks it's
> over, nothing will be printed anymore. the only thing that _may be_ will
> help is zap_locks(), but not 100% guaranteed... we can panic the system,
> probably, if printk locks are getting corrupted, but panic() will not do the
> trick in general case, at this point -- console_unlock() takes the 
> logbuf_lock,
> which can be corrupted. apart from that console driver can be in a weird 
> state.
> 
> I sort of proposed to update console_flush_on_panic()  (called from panic())
> function a while ago to do zap_locks(), so in this case declaring BUG() from
> spinlock debug when we see 'bad' printk-related locks will have better
> chances to work out (assuming that console driver(-s) is (are) not against
> us).

Yeah, exactly, something that improves the chances of successful output.


> [..]
>> This was in reference to a problem with spin lock recursion that
>> can't print. The spin lock recursion deadlocks, but you'll never
>> see the diagnostic because the driver is already holding the lock
>> (not from printk() but from some other code).
>>
>> The printk doesn't even need to be directly related to the
>> console driver itself, but some other thing that the console driver
>> depends on while holding the spin lock that it claims for console output.
> 
> aha, ok. yes, this is certainly possible.
> 
>>> this is not a case of printk recursion and it should be handled
>>> just fine. console drivers are called under console_sem only.
>>> logbuf lock is unlocked. vprintk_emit() adds message to the logbuf,
>>> calls console_trylock() (which of course does not lock anything)
>>> and returns back to console_driver code.
>>
>> Not if locks are zapped because printk() recognizes a recursion.
>> Note console driver's locks are not zapped. For example,
> 
> yes, I proposed to add a ->reset callback to struct console
> a while ago, and to do a console reset loop in zap_locks()

What was the patch series title? I'd like to review that.

That would solve the recursive deadlock from console driver as well
(at least with CONFIG_DEBUG_SPINLOCK) because the printk() recursion
would zap the locks including the console driver's lock and
at least get the last output so that we'd know there was a recursion,
and fix it.


> zap_locks:
> ...
>   for_each_console(con)
>   if (con->reset)
>   con->reset(con)
> 
> that would re-init console drivers (locks, etc.).
> 
> 
> IOW, panic() does zap_locks(), zap_locks() zap the locks and
> resets the console drivers. that's sort of what I have in my
> private kernels.
> 
> [..]
>>> the only case when we really have a printk recursion is when
>>> someone calls printk() from within the vprintk_emit() logbuf_lock
>>> area.
>>
>> Not true.
>>
>> A while back, Jan Kara reworked the call site around
>> console_trylock_from_printk(). Hung with no output under unknown
>> conditions [1].
>>
>> Never solved, but obviously means there are unhandled recursions.

I'd still like to enable lockdep for console drivers, but I need a
better plan to debug unknown printk() recursions.


> aha, ok.
> 
>   -ss
> 

Re: [PATCH v4] lib/spinlock_debug.c: prevent a recursive cycle in the debug code

[Sergey Senozhatsky]

On (01/28/16 20:32), Peter Hurley wrote:
[..]
> You're assuming that Byungchul's patch is relevant to the recursion
> he witnessed. There are several paths into spin_dump().

yes. I was speaking in the context of Byungchul's report.

> Here's one that doesn't wait at all:
> 
> vprintk_emit()
>   console_trylock()
> down_trylock()
>   raw_spin_lock_irqsave()
> ... 
>   do_raw_spin_lock()
> debug_spin_lock_before()
>   SPIN_BUG_ON()
> spin_bug()
>spin_dump()
>  printk()
>** RINSE AND REPEAT **

ah, yes, agree.

> >> Additionally, what if the console_sem is simply corrupted?
> >> A livelock with no output ever is not very helpful.
> > 
> > if it's corrupted then this is not a spinlock debug problem.
> > at all.
> 
> I don't follow you.
> 

indeed very misleading, sorry, almost didn't sleep last nigh.
removing SPIN_BUG_ON entirely is not my logic, not all. printk locks are
special, I agree. in context of the proposed patch - we can't disable
spin_dump() for printk locks if they were corrupted. for printk locks it's
over, nothing will be printed anymore. the only thing that _may be_ will
help is zap_locks(), but not 100% guaranteed... we can panic the system,
probably, if printk locks are getting corrupted, but panic() will not do the
trick in general case, at this point -- console_unlock() takes the logbuf_lock,
which can be corrupted. apart from that console driver can be in a weird state.

I sort of proposed to update console_flush_on_panic()  (called from panic())
function a while ago to do zap_locks(), so in this case declaring BUG() from
spinlock debug when we see 'bad' printk-related locks will have better
chances to work out (assuming that console driver(-s) is (are) not against
us).

[..]
> This was in reference to a problem with spin lock recursion that
> can't print. The spin lock recursion deadlocks, but you'll never
> see the diagnostic because the driver is already holding the lock
> (not from printk() but from some other code).
> 
> The printk doesn't even need to be directly related to the
> console driver itself, but some other thing that the console driver
> depends on while holding the spin lock that it claims for console output.

aha, ok. yes, this is certainly possible.

> > this is not a case of printk recursion and it should be handled
> > just fine. console drivers are called under console_sem only.
> > logbuf lock is unlocked. vprintk_emit() adds message to the logbuf,
> > calls console_trylock() (which of course does not lock anything)
> > and returns back to console_driver code.
> 
> Not if locks are zapped because printk() recognizes a recursion.
> Note console driver's locks are not zapped. For example,

yes, I proposed to add a ->reset callback to struct console
a while ago, and to do a console reset loop in zap_locks()

zap_locks:
...
for_each_console(con)
if (con->reset)
con->reset(con)

that would re-init console drivers (locks, etc.).


IOW, panic() does zap_locks(), zap_locks() zap the locks and
resets the console drivers. that's sort of what I have in my
private kernels.

[..]
> > the only case when we really have a printk recursion is when
> > someone calls printk() from within the vprintk_emit() logbuf_lock
> > area.
> 
> Not true.
> 
> A while back, Jan Kara reworked the call site around
> console_trylock_from_printk(). Hung with no output under unknown
> conditions [1].
> 
> Never solved, but obviously means there are unhandled recursions.

aha, ok.

-ss

[PATCH] s390:ftrace: add save_stack_trace_regs()

[Pratyush Anand]

Implement save_stack_trace_regs, so that stacktrace of a kprobe events can
be obtained.

Without this we see following warning:
"save_stack_trace_regs() not implemented yet."
when we execute:
echo stacktrace > /sys/kernel/debug/tracing/trace_options
echo "p kfree" >> /sys/kernel/debug/tracing/kprobe_events
echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable

Reported-by: Chunyu Hu 
Signed-off-by: Pratyush Anand 
---
 arch/s390/kernel/stacktrace.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/s390/kernel/stacktrace.c b/arch/s390/kernel/stacktrace.c
index 1785cd82253c..586da400f931 100644
--- a/arch/s390/kernel/stacktrace.c
+++ b/arch/s390/kernel/stacktrace.c
@@ -94,3 +94,16 @@ void save_stack_trace_tsk(struct task_struct *tsk, struct 
stack_trace *trace)
trace->entries[trace->nr_entries++] = ULONG_MAX;
 }
 EXPORT_SYMBOL_GPL(save_stack_trace_tsk);
+
+void save_stack_trace_regs(struct pt_regs *regs, struct stack_trace *trace)
+{
+   unsigned long sp, low, high;
+
+   sp = kernel_stack_pointer(regs);
+   low = (unsigned long) task_stack_page(current);
+   high = (unsigned long) task_pt_regs(current);
+   save_context_stack(trace, sp, low, high, 0);
+   if (trace->nr_entries < trace->max_entries)
+   trace->entries[trace->nr_entries++] = ULONG_MAX;
+}
+EXPORT_SYMBOL_GPL(save_stack_trace_regs);
-- 
2.5.0

Re: [PATCHv2 2/2] mm/page_poisoning.c: Allow for zero poisoning

[Kees Cook]

On Thu, Jan 28, 2016 at 6:38 PM, Laura Abbott  wrote:
> By default, page poisoning uses a poison value (0xaa) on free. If this
> is changed to 0, the page is not only sanitized but zeroing on alloc
> with __GFP_ZERO can be skipped as well. The tradeoff is that detecting
> corruption from the poisoning is harder to detect. This feature also
> cannot be used with hibernation since pages are not guaranteed to be
> zeroed after hibernation.
>
> Credit to Grsecurity/PaX team for inspiring this work
>
> Signed-off-by: Laura Abbott 
> ---
>  include/linux/mm.h   |  2 ++
>  include/linux/poison.h   |  4 
>  kernel/power/hibernate.c | 17 +
>  mm/Kconfig.debug | 14 ++
>  mm/page_alloc.c  | 11 ++-
>  mm/page_ext.c| 10 --
>  mm/page_poison.c |  7 +--
>  7 files changed, 60 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 966bf0e..59ce0dc 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2177,10 +2177,12 @@ extern int apply_to_page_range(struct mm_struct *mm, 
> unsigned long address,
>  #ifdef CONFIG_PAGE_POISONING
>  extern bool page_poisoning_enabled(void);
>  extern void kernel_poison_pages(struct page *page, int numpages, int enable);
> +extern bool page_is_poisoned(struct page *page);
>  #else
>  static inline bool page_poisoning_enabled(void) { return false; }
>  static inline void kernel_poison_pages(struct page *page, int numpages,
> int enable) { }
> +static inline bool page_is_poisoned(struct page *page) { return false; }
>  #endif
>
>  #ifdef CONFIG_DEBUG_PAGEALLOC
> diff --git a/include/linux/poison.h b/include/linux/poison.h
> index 4a27153..51334ed 100644
> --- a/include/linux/poison.h
> +++ b/include/linux/poison.h
> @@ -30,7 +30,11 @@
>  #define TIMER_ENTRY_STATIC ((void *) 0x300 + POISON_POINTER_DELTA)
>
>  /** mm/debug-pagealloc.c **/
> +#ifdef CONFIG_PAGE_POISONING_ZERO
> +#define PAGE_POISON 0x00
> +#else
>  #define PAGE_POISON 0xaa
> +#endif
>
>  /** mm/page_alloc.c /
>
> diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
> index b7342a2..aa0f26b 100644
> --- a/kernel/power/hibernate.c
> +++ b/kernel/power/hibernate.c
> @@ -1158,6 +1158,22 @@ static int __init kaslr_nohibernate_setup(char *str)
> return nohibernate_setup(str);
>  }
>
> +static int __init page_poison_nohibernate_setup(char *str)
> +{
> +#ifdef CONFIG_PAGE_POISONING_ZERO
> +   /*
> +* The zeroing option for page poison skips the checks on alloc.
> +* since hibernation doesn't save free pages there's no way to
> +* guarantee the pages will still be zeroed.
> +*/
> +   if (!strcmp(str, "on")) {
> +   pr_info("Disabling hibernation due to page poisoning\n");
> +   return nohibernate_setup(str);
> +   }
> +#endif
> +   return 1;
> +}
> +
>  __setup("noresume", noresume_setup);
>  __setup("resume_offset=", resume_offset_setup);
>  __setup("resume=", resume_setup);
> @@ -1166,3 +1182,4 @@ __setup("resumewait", resumewait_setup);
>  __setup("resumedelay=", resumedelay_setup);
>  __setup("nohibernate", nohibernate_setup);
>  __setup("kaslr", kaslr_nohibernate_setup);
> +__setup("page_poison=", page_poison_nohibernate_setup);
> diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug
> index 25c98ae..3d3b954 100644
> --- a/mm/Kconfig.debug
> +++ b/mm/Kconfig.debug
> @@ -48,3 +48,17 @@ config PAGE_POISONING_NO_SANITY
>
>If you are only interested in sanitization, say Y. Otherwise
>say N.
> +
> +config PAGE_POISONING_ZERO
> +   bool "Use zero for poisoning instead of random data"
> +   depends on PAGE_POISONING
> +   ---help---
> +  Instead of using the existing poison value, fill the pages with
> +  zeros. This makes it harder to detect when errors are occurring
> +  due to sanitization but the zeroing at free means that it is
> +  no longer necessary to write zeros when GFP_ZERO is used on
> +  allocation.

May be worth noting the security benefit in this help text.

> +
> +  Enabling page poisoning with this option will disable hibernation

This isn't obvious to me. It looks like you need to both use
CONFIG_PAGE_POISOING_ZERO and put "page_poison=on" on the command line
to enable it?

-Kees

> +
> +  If unsure, say N
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index cc4762a..59bd9dc 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1382,15 +1382,24 @@ static inline int check_new_page(struct page *page)
> return 0;
>  }
>
> +static inline bool free_pages_prezeroed(bool poisoned)
> +{
> +   return IS_ENABLED(CONFIG_PAGE_POISONING_ZERO) &&
> +   page_poisoning_enabled() && poisoned;
> +}
> +
>  static int prep_new_page(struct page *page, unsigned int order, gfp_t 
> gfp_flags,
>   

[PATCH v2] irqchip: gicv3-its: Fix memory leak in its_free_tables()

[Shanker Donthineni]

The current ITS driver has a memory leak in its_free_tables(). It
happens on tear down path of the driver when its_probe() call fails.
its_free_tables() should free the exact number of pages that have
been allocated, not just a single page as current code does.

This patch records the memory size for each ITS_BASERn at the time of
page allocation and uses the same size information when freeing pages
to fix the issue.

Signed-off-by: Shanker Donthineni 
---
 [v1]->[v2]: 
-rebase on tip of 
https://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/its-fixes-4.5=25ffe003bdc24492204e099fca0a467641d0fe1a
-refresh alloc_size value whenever page order changes. 

 drivers/irqchip/irq-gic-v3-its.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 3447549..fc1a34f 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -66,7 +66,10 @@ struct its_node {
unsigned long   phys_base;
struct its_cmd_block*cmd_base;
struct its_cmd_block*cmd_write;
-   void*tables[GITS_BASER_NR_REGS];
+   struct {
+   void*base;
+   u32 size;
+   } tables[GITS_BASER_NR_REGS];
struct its_collection   *collections;
struct list_headits_device_list;
u64 flags;
@@ -807,9 +810,10 @@ static void its_free_tables(struct its_node *its)
int i;
 
for (i = 0; i < GITS_BASER_NR_REGS; i++) {
-   if (its->tables[i]) {
-   free_page((unsigned long)its->tables[i]);
-   its->tables[i] = NULL;
+   if (its->tables[i].base) {
+   free_pages((unsigned long)its->tables[i].base,
+  get_order(its->tables[i].size));
+   its->tables[i].base = NULL;
}
}
 }
@@ -880,6 +884,7 @@ retry_alloc_baser:
if (alloc_pages > GITS_BASER_PAGES_MAX) {
alloc_pages = GITS_BASER_PAGES_MAX;
order = get_order(GITS_BASER_PAGES_MAX * psz);
+   alloc_size = (1 << order) * PAGE_SIZE;
pr_warn("%s: Device Table too large, reduce its page 
order to %u (%u pages)\n",
node_name, order, alloc_pages);
}
@@ -890,7 +895,8 @@ retry_alloc_baser:
goto out_free;
}
 
-   its->tables[i] = base;
+   its->tables[i].base = base;
+   its->tables[i].size = alloc_size;
 
 retry_baser:
val = (virt_to_phys(base)|
-- 
Qualcomm Technologies, Inc. on behalf
of the Qualcomm Innovation Center, Inc.  The Qualcomm Innovation Center, Inc. 
is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

[PATCH v11 0/1] Enable capsule loader interface for efi firmware updating

[Kweh, Hock Leong]

From: "Kweh, Hock Leong" 

Dear maintainers & communities,

This patchset is created on top of Matt's patchset:
1.)https://lkml.org/lkml/2014/10/7/390
"[PATCH 1/2] efi: Move efi_status_to_err() to efi.h"
2.)https://lkml.org/lkml/2014/10/7/391
"[PATCH 2/2] efi: Capsule update support"

It expose a misc char interface for user to upload the capsule binary and
calling efi_capsule_update() API to pass the binary to EFI firmware.

The steps to update efi firmware are:
1.) cat firmware.cap > /dev/efi_capsule_loader
2.) reboot

Any failed upload error message will be returned while doing "cat" through
file operation write() function call.

Tested the code with Intel Quark Galileo GEN1 platform.

Thanks.

---

changelog v11:
* rebase to v4.5-rc1
* correct vocabulary base on Bryan's comments
* Optimise ->pages & ->index code flow base on Matt's comments

changelog v10:
* rebase to v4.4
* added efi runtime services check at efi_capsule_loader_init()
* fixed checkpatch issues
* code clean up base on Borislav's comments

changelog v9:
* squash 2 patches to become 1 patch
* change function param to pass in cap_info instead of file structure
* perform both alloc inside efi_capsule_setup_info()
* change to use multiple exit labels instead of one function call
* further code clean up base on Matt's comments

changelog v8:
* further clean up on kunmap() & efi_free_all_buff_pages()
* design enhanced to support 1st few writes are less than efi header size
* removed support to padding capsule and flag error once the upload size
  bigger than header defined size

changelog v7:
* add successful message printed in dmesg
* shorten the code in efi_capsule_write() by splitting out
  efi_capsule_setup_info() & efi_capsule_submit_update() functions
* design added capability to support multiple file open action
* re-write those comments by following standard format
* design added the "uncomplete" error return through flush() file operation

changelog v6:
* clean up on error handling for better code flow and review
* clean up on pr_err() for critical error only
* design taking care writing block that below PAGE_SIZE
* once error has occurred, design will return -EIO until file close
* document design expectations/scenarios in the code
* change the dynamic allocation cap_info struct to statically allocated

changelog v5:
* changed to new design without leveraging firmware_class API
* use misc_char device interface instead of sysfs
* error return through file Write() function call


Kweh, Hock Leong (1):
  efi: a misc char interface for user to update efi firmware

 drivers/firmware/efi/Kconfig  |9 +
 drivers/firmware/efi/Makefile |1 +
 drivers/firmware/efi/capsule-loader.c |  334 +
 drivers/firmware/efi/capsule.c|1 +
 4 files changed, 345 insertions(+)
 create mode 100644 drivers/firmware/efi/capsule-loader.c

-- 
1.7.9.5

[PATCH v11 1/1] efi: a misc char interface for user to update efi firmware

[Kweh, Hock Leong]

From: "Kweh, Hock Leong" 

Introducing a kernel module to expose capsule loader interface
(misc char device file note) for users to upload capsule binaries.

Example:
cat firmware.bin > /dev/efi_capsule_loader

This patch also export efi_capsule_supported() function symbol for
verifying the submitted capsule header in this kernel module.

Cc: Matt Fleming 
Signed-off-by: Kweh, Hock Leong 
---
 drivers/firmware/efi/Kconfig  |9 +
 drivers/firmware/efi/Makefile |1 +
 drivers/firmware/efi/capsule-loader.c |  334 +
 drivers/firmware/efi/capsule.c|1 +
 4 files changed, 345 insertions(+)
 create mode 100644 drivers/firmware/efi/capsule-loader.c

diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
index e1670d5..73c14af 100644
--- a/drivers/firmware/efi/Kconfig
+++ b/drivers/firmware/efi/Kconfig
@@ -87,6 +87,15 @@ config EFI_RUNTIME_WRAPPERS
 config EFI_ARMSTUB
bool
 
+config EFI_CAPSULE_LOADER
+   tristate "EFI capsule loader"
+   depends on EFI
+   help
+ This option exposes a loader interface "/dev/efi_capsule_loader" for
+ users to load EFI capsules.
+
+ If unsure, say N.
+
 endmenu
 
 config UEFI_CPER
diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
index e4468c7..7d6e1e8 100644
--- a/drivers/firmware/efi/Makefile
+++ b/drivers/firmware/efi/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_EFI_RUNTIME_MAP) += runtime-map.o
 obj-$(CONFIG_EFI_RUNTIME_WRAPPERS) += runtime-wrappers.o
 obj-$(CONFIG_EFI_STUB) += libstub/
 obj-$(CONFIG_EFI_FAKE_MEMMAP)  += fake_mem.o
+obj-$(CONFIG_EFI_CAPSULE_LOADER)   += capsule-loader.o
 
 arm-obj-$(CONFIG_EFI)  := arm-init.o arm-runtime.o
 obj-$(CONFIG_ARM)  += $(arm-obj-y)
diff --git a/drivers/firmware/efi/capsule-loader.c 
b/drivers/firmware/efi/capsule-loader.c
new file mode 100644
index 000..acffd76
--- /dev/null
+++ b/drivers/firmware/efi/capsule-loader.c
@@ -0,0 +1,334 @@
+/*
+ * EFI capsule loader driver.
+ *
+ * Copyright 2015 Intel Corporation
+ *
+ * This file is part of the Linux kernel, and is made available under
+ * the terms of the GNU General Public License version 2.
+ */
+
+#define pr_fmt(fmt) "EFI: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define NO_FURTHER_WRITE_ACTION -1
+
+struct capsule_info {
+   boolheader_obtained;
+   int reset_type;
+   longindex;
+   size_t  count;
+   size_t  total_size;
+   struct page **pages;
+   size_t  page_bytes_remain;
+};
+
+/**
+ * efi_free_all_buff_pages - free all previous allocated buffer pages
+ * @cap_info: pointer to current instance of capsule_info structure
+ *
+ * In addition of freeing buffer pages, it flags NO_FURTHER_WRITE_ACTION
+ * to cease processing data in subsequent write(2) calls until close(2)
+ * is called.
+ **/
+static void efi_free_all_buff_pages(struct capsule_info *cap_info)
+{
+   while (cap_info->index > 0)
+   __free_page(cap_info->pages[--cap_info->index]);
+
+   cap_info->index = NO_FURTHER_WRITE_ACTION;
+}
+
+/**
+ * efi_capsule_setup_info - to obtain the efi capsule header in the binary and
+ * setup capsule_info structure
+ * @cap_info: pointer to current instance of capsule_info structure
+ * @kbuff: a mapped first page buffer pointer
+ * @hdr_bytes: the total received number of bytes for efi header
+ **/
+static ssize_t efi_capsule_setup_info(struct capsule_info *cap_info,
+ void *kbuff, size_t hdr_bytes)
+{
+   int ret;
+   void *temp_page;
+
+   /* Only process data block that is larger than a efi header size */
+   if (hdr_bytes >= sizeof(efi_capsule_header_t)) {
+   /* Reset back to the correct offset of header */
+   efi_capsule_header_t *cap_hdr = kbuff - cap_info->count;
+   size_t pages_needed = ALIGN(cap_hdr->imagesize, PAGE_SIZE) >>
+   PAGE_SHIFT;
+
+   if (pages_needed == 0) {
+   pr_err("%s: pages count invalid\n", __func__);
+   return -EINVAL;
+   }
+
+   /* Check if the capsule binary supported */
+   ret = efi_capsule_supported(cap_hdr->guid, cap_hdr->flags,
+   cap_hdr->imagesize,
+   _info->reset_type);
+   if (ret) {
+   pr_err("%s: efi_capsule_supported() failed\n",
+  __func__);
+   return ret;
+   }
+
+   cap_info->total_size = cap_hdr->imagesize;
+   temp_page = krealloc(cap_info->pages,
+pages_needed * 

Re: [PATCH 3/4] dmaengine: qcom_bam_dma: use correct pipe FIFO size

[Andy Gross]

On Thu, Dec 10, 2015 at 03:18:33PM +0200, Stanimir Varbanov wrote:



> >>> This is just using the #define.  That is ok, but if you use this instead 
> >>> of the
> >>> BAM_P_FIFO_SIZES then you need to fix your comment.  Or actually use the
> >>> register value otherwise looks fine.
> >>
> >> I did not follow your comment, but the intension of the patch is to set
> >> the proper FIFO size in BAM_P_FIFO_SIZES register, i.e. 32K - 8.
> > 
> > Sorry, I mixed up the usage and was thinking there was something you read 
> > out
> > that told you the size.  That's not how it works, unfortunately.  The
> > MAX_DATA_SIZE is fine, but the name is a little misleading.  Perhaps just
> > BAM_FIFO_SIZE?
> 
> OK I can rename BAM_MAX_DATA_SIZE to BAM_FIFO_SIZE, and use it when
> setting BAM_P_FIFO_SIZES register. Is that fine to you?

Yes that's fine with me.

Re: [PATCH v4] lib/spinlock_debug.c: prevent a recursive cycle in the debug code

[Peter Hurley]

On 01/28/2016 04:27 PM, Sergey Senozhatsky wrote:
> On (01/28/16 15:08), Peter Hurley wrote:
> [..]
>>> even if at some level of recursion (nested printk calls)
>>> spin_dump()->__spin_lock_debug()->arch_spin_trylock() acquires the
>>> lock, it returns back with the spin lock unlocked anyway.
>>>
>>> vprintk_emit()
>>>  console_trylock()
>>>   spin_lock()
>>>spin_dump()
>>> vprintk_emit()
>>>  console_trylock()
>>>   spin_lock()
>>>spin_dump()
>>> vprintk_emit()
>>>  console_trylock()
>>>   spin_lock() << OK, got the lock finally
>>
>> The problem is you have postulated a very shallow recursion.
>> This looks much worse if this happens 1000 times, and
>> probably won't recover to output anything.
> 
> well, the stack is surely limited, but on every
> spin_dump()->spin_lock() recursive call it does another
> round of
> 
>   u64 loops = loops_per_jiffy * HZ;
> 
>   for (i = 0; i < loops; i++) {
>   if (arch_spin_trylock(>raw_lock))
>   return;
>   __delay(1);
>   }
> 
> so if you have 1000 spin_dump()->spin_lock() then, well,
> something has been holding the lock for '1000 * loops_per_jiffy * HZ'.
> 
> and in particularly this case that somethign was holding the
> spin lock doing trivial operations like
> 
>   count = sem->count - 1;
>   if (likely(count >= 0))
>   sem->count = count;
> 
> (or a bit more if it was in down()). but still.
> 
> and it's kinda hard to imagine console_sem lock being s
> congested and unfair. on each given point of time in the worst
> case there are `num_online_cpus() - 1' cpus spinning on that spin_lock
> and 1 cpu holding that spinlock. which in Byungchul's case is, what,
> 3 spinning cpus, or 7 spinnign cpus?...


You're assuming that Byungchul's patch is relevant to the recursion
he witnessed. There are several paths into spin_dump().

Here's one that doesn't wait at all:

vprintk_emit()
  console_trylock()
down_trylock()
  raw_spin_lock_irqsave()
... 
  do_raw_spin_lock()
debug_spin_lock_before()
  SPIN_BUG_ON()
spin_bug()
   spin_dump()
 printk()
   ** RINSE AND REPEAT **



>> Additionally, what if the console_sem is simply corrupted?
>> A livelock with no output ever is not very helpful.
> 
> if it's corrupted then this is not a spinlock debug problem.
> at all.

I don't follow you.

The whole point of SPIN_BUG_ON() is to catch problems that should never
happen, but nevertheless, have.

IOW, following your logic, we should remove the SPIN_BUG_ON() because
these situations should not happen.


>> As I wrote earlier, I don't think this is the way to fix
>> recursion problems with printk() [by eliding output].
>>
>> Rather, a way to effectively determine a recursion is in progress,
>> and _at a minimum_ guaranteeing that the recursive output will
>> eventually be output should be the goal.
>>
>> Including dumb recursion like a console driver printing
>> an error :/

This was in reference to a problem with spin lock recursion that
can't print. The spin lock recursion deadlocks, but you'll never
see the diagnostic because the driver is already holding the lock
(not from printk() but from some other code).

The printk doesn't even need to be directly related to the
console driver itself, but some other thing that the console driver
depends on while holding the spin lock that it claims for console output.

Deadlock, no output.

For example,

  serial8250_do_set_termios()
spin_lock_irqsave()  ** claim port lock **
...
serial_port_out(port, UART_LCR, );
  dw8250_serial_out()
dev_err()
  vprintk_emit()
console_trylock()
  call_console_drivers()
serial8250_console_write()
  spin_lock_irqsave()  ** port lock **
  ** DEADLOCK **
 

> this is not a case of printk recursion and it should be handled
> just fine. console drivers are called under console_sem only.
> logbuf lock is unlocked. vprintk_emit() adds message to the logbuf,
> calls console_trylock() (which of course does not lock anything)
> and returns back to console_driver code.

Not if locks are zapped because printk() recognizes a recursion.
Note console driver's locks are not zapped. For example,

vprintk_emit()
   ...
   call_console_drivers()
  /* inside some console driver */
  claim some lock
  printk("%s\n", NULL);  /* you get the idea */
 vprintk_emit()
 logbuf_lock
 vscnprintf()
** oops **
vprintk_emit()
   recursion detected
   zap_locks()
   
  call_console_drivers()
 /* inside same console driver */
 claim same lock
 ** DEADLOCK **

 

> the only case 

[PATCH] intel_th: Show a correct number of masters in debug message

[Chunyan Zhang]

Since both sw_start and sw_end are master indices, the number of
software masters should be sw_end - sw_start + 1, which the current
code gets wrong, calculating one less than the actual value.

With this patch, the correct number of masters would be showed in the
debug message.

Signed-off-by: Chunyan Zhang 
---
 drivers/hwtracing/intel_th/sth.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwtracing/intel_th/sth.c b/drivers/hwtracing/intel_th/sth.c
index 56101c3..28917d7 100644
--- a/drivers/hwtracing/intel_th/sth.c
+++ b/drivers/hwtracing/intel_th/sth.c
@@ -173,7 +173,7 @@ static int intel_th_sw_init(struct sth_device *sth)
sth->stm.sw_start = reg & 0x;
sth->stm.sw_end = reg >> 16;
 
-   sth->sw_nmasters = sth->stm.sw_end - sth->stm.sw_start;
+   sth->sw_nmasters = sth->stm.sw_end - sth->stm.sw_start + 1;
dev_dbg(sth->dev, "sw_start: %x sw_end: %x masters: %x nchannels: %x\n",
sth->stm.sw_start, sth->stm.sw_end, sth->sw_nmasters,
sth->stm.sw_nchannels);
-- 
1.9.1

Re: [PATCH] genirq: fix trigger flags check for shared irqs

[Tomasz Figa]

Hi Thomas,

2016-01-29 5:06 GMT+09:00 Thomas Gleixner :
> On Thu, 28 Jan 2016, Rob Herring wrote:
>> On Thu, Jan 28, 2016 at 5:49 AM, Thomas Gleixner  wrote:
>> > I've cc'ed the author and the device tree folks. Perhaps are they able to
>> > explain what this commit tries to 'fix'.
>>
>> It's certainly not clear what driver was being fixed. I think the
>> intention was to provide the trigger flags from the DT to drivers in a
>> standard, non-DT specific way. The implementation of it certainly
>> seems convoluted. The usecase I can think of is drivers may need the
>> trigger information for cases where the device can support different
>> trigger modes/polarity. The DT says which trigger mode to use and the
>> device and irqchip need to be programmed to match. IIRC, SMSC ethernet
>> chips frequently used on ARM boards do this.
>
> I can see that the driver wants this information, but why would one feed that
> back into request_irq() when the interrupt was already configured by DT.
>

I think Rob already explained the original intention of the patch in
question I sent quite long time ago.

To clarify, I have to add that passing interrupt trigger in resource
flags is not something specific for DT, but it is the general way used
for platform devices and dating times even before DT adoption on ARM
(=== wide spread DT adoption). The key point here is that on pre-DT
systems, the interrupt would not be already configured by DT code and
that's why you have to pass the trigger flags to request_irq().

Best regards,
Tomasz

linux-next: Tree for Jan 29

[Stephen Rothwell]

Hi all,

Changes since 20160128:

The gpio tree gained a build failure so I used the version from
next-20160128.

The aio tree still had a build failure so I used the version from
next-20160111.

I added 2 supplied patches to the akpm-current tree to fix build
problems.

Non-merge commits (relative to Linus' tree): 1575
 1475 files changed, 52644 insertions(+), 19583 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After the
final fixups (if any), I do an x86_64 modules_install followed by builds
for powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc and
sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 239 trees (counting Linus' and 36 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (03c21cb775a3 Merge tag 'for_linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost)
Merging fixes/master (92e963f50fc7 Linux 4.5-rc1)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (74bf8efb5fa6 Linux 4.4-rc7)
Merging arm-current/fixes (03590cb56d5d ARM: wire up copy_file_range() syscall)
Merging m68k-current/for-linus (eb37bc3f85b6 m68k: Provide __phys_to_pfn() and 
__pfn_to_phys())
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-fixes/fixes (2d19fc639516 powerpc/mm: Fixup _HPAGE_CHG_MASK)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (1a40b95374f6 sparc: Fix system call tracing register 
handling.)
Merging net/master (3b9e9488098a Merge branch 'master' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue)
Merging ipsec/master (a8a572a6b5f2 xfrm: dst_entries_init() per-net dst_ops)
Merging ipvs/master (b16c29191dc8 netfilter: nf_conntrack: use safer way to 
lock all buckets)
Merging wireless-drivers/master (f9ead9beef3f Merge tag 
'iwlwifi-for-kalle-2016-01-26_2' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (ca094a484076 mac80211: fix use of uninitialised values 
in RX aggregation)
Merging sound-current/for-linus (7ee96216c31a ALSA: dummy: Disable switching 
timer backend via sysfs)
Merging pci-current/for-linus (c43e4b52cbf2 PCI: iproc: Fix BCMA PCIe bus 
scanning regression)
Merging driver-core.current/driver-core-linus (25cad69f21f5 base/platform: Fix 
platform drivers with no probe callback)
Merging tty.current/tty-linus (f4f9edcf9b52 staging/speakup: Use 
tty_ldisc_ref() for paste kworker)
Merging usb.current/usb-linus (a89a798a010e Merge tag 'usb-serial-4.5-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus)
Merging usb-gadget-fixes/fixes (7d32cdef5356 usb: musb: fail with error when no 
DMA controller set)
Merging usb-serial-fixes/usb-linus (4152b387da81 USB: option: fix Cinterion 
AHxx enumeration)
Merging usb-chipidea-fixes/ci-for-usb-stable (6f51bc340d2a usb: chipidea: imx: 
fix a possible NULL dereference)
Merging staging.current/staging-linus (f744c423cacf Merge tag 
'iio-fixes-for-4.4c' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio 
into staging-linus)
Merging char-misc.current/char-misc-linus (587198ba5206 vmstat: Remove BUG_ON 
from vmstat_update)
Merging input-current/for-linus (d4f1b06d685d Input: vmmouse - fix absolute 
device registration)
Merging crypto-current/master (00420a65fa2b crypto: shash - Fix has_key setting)
Merging ide/master (e04a2bd6d8c9 drivers/ide: make ide-scan-pci.c driver 
explicitly 

linux-next: build warning after merge of the mac80211 tree

[Stephen Rothwell]

Hi Johannes,

After merging the mac80211 tree, today's linux-next build (i386 defconfig)
produced this warning:

In file included from include/net/wext.h:4:0,
 from net/socket.c:97:
include/net/iw_handler.h:446:13: warning: 'wireless_nlevent_flush' defined but 
not used [-Wunused-function]
 static void wireless_nlevent_flush(void) {}
 ^

Introduced by commit

  3730abeab65b ("cfg80211/wext: fix message ordering")

Missing inline :-(

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

Re: [PATCH v4] lib/spinlock_debug.c: prevent a recursive cycle in the debug code

[Sergey Senozhatsky]

On (01/29/16 12:00), Byungchul Park wrote:
[..]
> > it took a while to even find out that you are reporting this issues
> > not against a real H/W, but a qemu. I suppose qemu-arm running on
> > x86_64 box.
> 
> No matter what kind of box I used because I only kept talking about the
> possiblity. It does not depend on a box at all.

well, qemu completely invalidates all of the H/W theories - powered off,
etc. so in a way it's important.


> > on very spin_dump recursive call it waits for the spin_lock and when
> > it eventually grabs it, it does the job that it wanted to do under
> > that spin lock, unlock it and return back. and the only case when it
> > never "return back" is when it never "eventually grabs it".
> 
> Right. I missed it.

hm... we also can hit problems in spin_unlock() path. AND there are chances
that spin_unlock() can explode WITH OUT any memory corruption on sight, but
due to a coding error... a theoretical one:

we do unlock logbuf_lock, and debug_spin_unlock() is performed on a 
locked logbuf_lock spin_lock

static inline void debug_spin_unlock(raw_spinlock_t *lock)
{
SPIN_BUG_ON(lock->magic != SPINLOCK_MAGIC, lock, "bad magic");
SPIN_BUG_ON(!raw_spin_is_locked(lock), lock, "already 
unlocked");
SPIN_BUG_ON(lock->owner != current, lock, "wrong owner");
SPIN_BUG_ON(lock->owner_cpu != raw_smp_processor_id(),
lock, "wrong 
CPU");
lock->owner = SPINLOCK_OWNER_INIT;
lock->owner_cpu = -1;
}

void do_raw_spin_unlock(raw_spinlock_t *lock)
{
debug_spin_unlock(lock);
arch_spin_unlock(>raw_lock);
}

so if there was a coding error (schedule while atomic, or unlock from another
CPU) which resulted in faulty
lock->owner_cpu != raw_smp_processor_id()
OR
lock->owner != current

then this will explode:

printk
 spin_lock
  >> coding error <<
 spin_unlock
  printk
   spin_lock
printk
 spin_lock
  printk
   spin_lock
... boom

vprintk_emit() recursion detection code will not work for logbuf_lock here.
because the only criteria how vprintk_emit() can detect a recursion is via
static `logbuf_cpu' which is set to UINT_MAX right before it
raw_spin_unlock(_lock). so from vprintk_emit() POV the logbuf_lock is
already unlocked. which is not true.


in case of memory corruption I don't think we must care, 'coding error case'
is _probably/may be_ something that can be improved, but I'm not really 100%
sure... and this still doesn't explain your console_sem.lock case.

-ss

Re: [PATCH] Optimize int_sqrt for small values for faster idle

[Rafael J. Wysocki]

On Thursday, January 28, 2016 01:42:45 PM Andi Kleen wrote:
> From: Andi Kleen 
> 
> The menu cpuidle governor does at least two int_sqrt() each time
> we go into idle in get_typical_interval to compute stddev
> 
> int_sqrts take 100-120 cycles each. Short idle latency is important
> for many workloads.
> 
> I instrumented the function on my workstation and most values are
> 16bit only and most others 32bit (50% percentile is 122094,
> 75% is 3699533).
> 
> sqrt is implemented by starting with an initial estimation,
> and then iterating. int_sqrt currently only uses a fixed
> estimating which is good for 64bits worth of input.
> 
> This patch adds some checks at the beginning to start with
> a better estimate for values fitting in 8, 16bit and 32bit.
> This makes int_sqrt between 60+% faster for values in 16bit,
> and still somewhat faster (between 10 and 30%) for larger values
> upto 32bit. Full 64bit is slightly slower.
> 
> This optimizes the short idle calls and does not hurt the
> long sleep (which probably do not care) much.
> 
> An alternative would be a full table drive approach, or
> trying some inverted sqrt optimization, but this simple change
> already seems to have a good payoff.

I'm wondering if you have any numbers on how much of a difference this
makes in practice in terms of energy consumption, performance, latency etc.

Thanks,
Rafael

RE: [RFC PATCH 4/6] iommu/arm-smmu: Add support for IOMMU_DOMAIN_DMA in SMMUv1/SMMUv2 driver

[Anup Patel]

> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: 28 January 2016 22:59
> To: Anup Patel; Catalin Marinas; Joerg Roedel; Will Deacon; Sricharan R; Linux
> IOMMU; Linux ARM Kernel
> Cc: Rob Herring; Pawel Moll; Mark Rutland; Ian Campbell; Kumar Gala; Device
> Tree; Ray Jui; Scott Branden; Vikram Prakash; Linux Kernel; bcm-kernel-
> feedback-list
> Subject: Re: [RFC PATCH 4/6] iommu/arm-smmu: Add support for
> IOMMU_DOMAIN_DMA in SMMUv1/SMMUv2 driver
> 
> On 27/01/16 05:21, Anup Patel wrote:
> > To allow use of large memory (> 4Gb) with 32bit devices we need to use
> > some kind of iommu for such 32bit devices.
> >
> > This patch extends SMMUv1/SMMUv2 driver to support DMA domains which
> > in-turn will allows us to use iommu based DMA mappings for 32bit devices.
> >
> > Signed-off-by: Anup Patel 
> > Reviewed-by: Ray Jui 
> > Reviewed-by: Scott Branden 
> > ---
> >   drivers/iommu/arm-smmu.c | 21 -
> >   1 file changed, 20 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index
> > 9bdf6b2..43424fe 100644
> > --- a/drivers/iommu/arm-smmu.c
> > +++ b/drivers/iommu/arm-smmu.c
> > @@ -29,6 +29,7 @@
> >   #define pr_fmt(fmt) "arm-smmu: " fmt
> >
> >   #include 
> > +#include 
> >   #include 
> >   #include 
> >   #include 
> > @@ -967,7 +968,7 @@ static struct iommu_domain
> *arm_smmu_domain_alloc(unsigned type)
> >   {
> > struct arm_smmu_domain *smmu_domain;
> >
> > -   if (type != IOMMU_DOMAIN_UNMANAGED)
> > +   if (type != IOMMU_DOMAIN_UNMANAGED && type !=
> IOMMU_DOMAIN_DMA)
> > return NULL;
> > /*
> >  * Allocate the domain and initialise some of its data structures.
> > @@ -978,6 +979,12 @@ static struct iommu_domain
> *arm_smmu_domain_alloc(unsigned type)
> > if (!smmu_domain)
> > return NULL;
> >
> > +   if (type == IOMMU_DOMAIN_DMA &&
> > +   iommu_get_dma_cookie(_domain->domain)) {
> > +   kfree(smmu_domain);
> > +   return NULL;
> > +   }
> > +
> > mutex_init(_domain->init_mutex);
> > spin_lock_init(_domain->pgtbl_lock);
> >
> > @@ -992,6 +999,7 @@ static void arm_smmu_domain_free(struct
> iommu_domain *domain)
> >  * Free the domain resources. We assume that all devices have
> >  * already been detached.
> >  */
> > +   iommu_put_dma_cookie(domain);
> > arm_smmu_destroy_domain_context(domain);
> > kfree(smmu_domain);
> >   }
> > @@ -1361,6 +1369,16 @@ static int arm_smmu_init_platform_device(struct
> device *dev,
> > return 0;
> >   }
> >
> > +int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args
> > +*args) {
> > +   /*
> > +* Nothing to do here because SMMU is already aware of all
> > +* MMU masters and their stream IDs using mmu-master attibute
> > +* SMMU DT node.
> > +*/
> 
> ...but on the same hand this will also never get called if there's no "iommus"
> property on the master. Maintaining support for existing users of the "mmu-
> masters" binding is one thing (namely the thing that's been slowing down my
> efforts to clean up the really hacky generic binding support I did all the DMA
> stuff with), but having _both_ bindings in a single DT is something I don't 
> think
> anybody wants to see - is that how you've tested this?

We want to use iommu aware DMA mapping APIs for certain 32bit devices
in our SoC without changing device driver of these 32bit devices
(such as PL330). Currently, to this we have to specifiy "iommus" attribute in
32bit device DT node. If we specify  "iommus" attribute in device DT node then
of_iommu_configure() expects "of_xlate" callback and it will fail if this
callback is not available.

If there is a way use DMA mappings APIs for 32bit devices without having
"of_xlate" in SMMU driver then I would prefer that approach. Suggestions??

> 
> Robin.
> 
> > +   return 0;
> > +}
> > +
> >   static int arm_smmu_add_device(struct device *dev)
> >   {
> > struct iommu_group *group;
> > @@ -1458,6 +1476,7 @@ static struct iommu_ops arm_smmu_ops = {
> > .unmap  = arm_smmu_unmap,
> > .map_sg = default_iommu_map_sg,
> > .iova_to_phys   = arm_smmu_iova_to_phys,
> > +   .of_xlate   = arm_smmu_of_xlate,
> > .add_device = arm_smmu_add_device,
> > .remove_device  = arm_smmu_remove_device,
> > .device_group   = arm_smmu_device_group,
> >
> 

Regards,
Anup

Re: [PATCHv2 2/2] mm/page_poisoning.c: Allow for zero poisoning

[Rafael J. Wysocki]

On Thursday, January 28, 2016 06:38:19 PM Laura Abbott wrote:
> By default, page poisoning uses a poison value (0xaa) on free. If this
> is changed to 0, the page is not only sanitized but zeroing on alloc
> with __GFP_ZERO can be skipped as well. The tradeoff is that detecting
> corruption from the poisoning is harder to detect. This feature also
> cannot be used with hibernation since pages are not guaranteed to be
> zeroed after hibernation.
> 
> Credit to Grsecurity/PaX team for inspiring this work
> 
> Signed-off-by: Laura Abbott 

The hibernation disabling part is fine by me.

Please feel free to add an ACK from me to this if that helps.

Thanks,
Rafael

Re: [PATCH 07/31] Add debugger entry points for NIOS2

[Jeffrey Merkey]

On 1/28/16, Ley Foon Tan  wrote:
> On Fri, Jan 29, 2016 at 3:46 AM, Jeffrey Merkey 
> wrote:
>> This patch series adds an export which can be set by system debuggers to
>> direct the hard lockup and soft lockup detector to trigger a breakpoint
>> exception and enter a debugger if one is active.  It is assumed that if
>> someone sets this variable, then an breakpoint handler of some sort will
>> be actively loaded or registered via the notify die handler chain.
>>
>> This addition is extremely useful for debugging hard and soft lockups
>> real time and quickly from a console debugger.
>>
>> Signed-off-by: Jeffrey Merkey 
>> ---
>>  arch/nios2/include/asm/kdebug.h | 5 +
>>  1 file changed, 5 insertions(+)
>>  create mode 100644 arch/nios2/include/asm/kdebug.h
>>
>> diff --git a/arch/nios2/include/asm/kdebug.h
>> b/arch/nios2/include/asm/kdebug.h
>> new file mode 100644
>> index 000..d5d9957
>> --- /dev/null
>> +++ b/arch/nios2/include/asm/kdebug.h
>> @@ -0,0 +1,5 @@
>> +
>> +static inline void arch_breakpoint(void)
>> +{
>> +   __asm__ __volatile__("trap 30\n");
>> +}
>> --
> Hi Jeffrey
>
> We already have similar function in arch/nios2/include/asm/kgdb.h. Can
> we reuse this?
>
> static inline void arch_kgdb_breakpoint(void)
> {
> __asm__ __volatile__("trap 30\n");
> }
>
> Regards
> Ley Foon
>

Hi Ley,

I actually copied it from there.  As it turns out, since it is being
called from watchdog.c it cannot be dependent on kgdb being compiled
so that function will not work .  I am looking at a better way to do
this by using the BUG() macro instead of this function in all the
arches.  Looks to be a lot cleaner and I can set the includes to
conditionally compile it with a breakpoint instead of the BUG while
loop.

Jeff

[RESEND PATCH v4] x86/PCI: Recognize that Interrupt Line 255 means "not connected"

[Chen Fan]

Per the x86-specific footnote to PCI spec r3.0, sec 6.2.4, the value 255 in
the Interrupt Line register means "unknown" or "no connection."
Previously, when we couldn't derive an IRQ from the _PRT, we fell back to
using the value from Interrupt Line as an IRQ.  It's questionable whether
we should do that at all, but the spec clearly suggests we shouldn't do it
for the value 255 on x86.

Calling request_irq() with IRQ 255 may succeed, but the driver won't
receive any interrupts.  Or, if IRQ 255 is shared with another device, it
may succeed, and the driver's ISR will be called at random times when the
*other* device interrupts.  Or it may fail if another device is using IRQ
255 with incompatible flags.  What we *want* is for request_irq() to fail
predictably so the driver can fall back to polling.

On x86, assume 255 in the Interrupt Line means the INTx line is not
connected.  In that case, set dev->irq to IRQ_NOTCONNECTED so request_irq()
will fail gracefully with -ENOTCONN.

We found this problem on a system where Secure Boot firmware assigned
Interrupt Line 255 to an i801_smbus device and another device was already
using MSI-X IRQ 255.  This was in v3.10, where i801_probe() fails if
request_irq() fails:

  i801_smbus :00:1f.3: enabling device (0140 -> 0143)
  i801_smbus :00:1f.3: can't derive routing for PCI INT C
  i801_smbus :00:1f.3: PCI INT C: no GSI
  genirq: Flags mismatch irq 255. 0080 (i801_smbus) vs.  (megasa)
  CPU: 0 PID: 2487 Comm: kworker/0:1 Not tainted 3.10.0-229.el7.x86_64 #1
  Hardware name: FUJITSU PRIMEQUEST 2800E2/D3736, BIOS PRIMEQUEST 2000 Serie5
  Call Trace:
dump_stack+0x19/0x1b
__setup_irq+0x54a/0x570
request_threaded_irq+0xcc/0x170
i801_probe+0x32f/0x508 [i2c_i801]
local_pci_probe+0x45/0xa0
  i801_smbus :00:1f.3: Failed to allocate irq 255: -16
  i801_smbus: probe of :00:1f.3 failed with error -16

After aeb8a3d16ae0 ("i2c: i801: Check if interrupts are disabled"),
i801_probe() will fall back to polling if request_irq() fails.  But we
still need this patch because request_irq() may succeed or fail depending
on other devices in the system.  If request_irq() fails, i801_smbus will
work by falling back to polling, but if it succeeds, i801_smbus won't work
because it expects interrupts that it may not receive.

Signed-off-by: Chen Fan 
Acked-by: Thomas Gleixner 
Acked-by: Bjorn Helgaas 
---
 drivers/acpi/pci_irq.c| 20 
 include/linux/interrupt.h | 10 ++
 kernel/irq/manage.c   |  9 -
 3 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
index d30184c..dda6d25 100644
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define PREFIX "ACPI: "
 
@@ -387,6 +388,22 @@ static inline int acpi_isa_register_gsi(struct pci_dev 
*dev)
 }
 #endif
 
+static inline bool acpi_pci_irq_valid(struct pci_dev *dev)
+{
+#ifdef CONFIG_X86
+   /*
+* On x86 irq line 0xff means "unknown" or "no connection" (PCI 3.0,
+* Section 6.2.4, footnote on page 223).
+*/
+   if (dev->irq == 0xff) {
+   dev->irq = IRQ_NOTCONNECTED;
+   dev_warn(>dev, "PCI INT not connected\n");
+   return false;
+   }
+#endif
+   return true;
+}
+
 int acpi_pci_irq_enable(struct pci_dev *dev)
 {
struct acpi_prt_entry *entry;
@@ -409,6 +426,9 @@ int acpi_pci_irq_enable(struct pci_dev *dev)
if (pci_has_managed_irq(dev))
return 0;
 
+   if (!acpi_pci_irq_valid(dev))
+   return 0;
+
entry = acpi_pci_irq_lookup(dev, pin);
if (!entry) {
/*
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index cb30edb..12f7da4 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -125,6 +125,16 @@ struct irqaction {
 
 extern irqreturn_t no_action(int cpl, void *dev_id);
 
+/*
+ * If a (PCI) device interrupt is not connected we set dev->irq to
+ * IRQ_NOTCONNECTED. This causes request_irq() to fail with -ENOTCONN, so we
+ * can distingiush that case from other error returns.
+ *
+ * 0x8000 is guaranteed to be outside the available range of interrupts
+ * and easy to distinguish from other possible incorrect values.
+ */
+#define IRQ_NOTCONNECTED   (1U << 31)
+
 extern int __must_check
 request_threaded_irq(unsigned int irq, irq_handler_t handler,
 irq_handler_t thread_fn,
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 8411872..e79e60f 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1609,6 +1609,9 @@ int request_threaded_irq(unsigned int irq, irq_handler_t 
handler,
struct irq_desc *desc;
int retval;
 
+   if (irq == IRQ_NOTCONNECTED)
+   return -ENOTCONN;
+
/*
 * Sanity-check: shared interrupts must pass in a real dev-ID,
 * otherwise 

Re: [PATCH 5/3] mm, vmscan: make zone_reclaimable_pages more precise

[Hillf Danton]

> 
> From: Michal Hocko 
> 
> zone_reclaimable_pages is used in should_reclaim_retry which uses it to
> calculate the target for the watermark check. This means that precise
> numbers are important for the correct decision. zone_reclaimable_pages
> uses zone_page_state which can contain stale data with per-cpu diffs
> not synced yet (the last vmstat_update might have run 1s in the past).
> 
> Use zone_page_state_snapshot in zone_reclaimable_pages instead. None
> of the current callers is in a hot path where getting the precise value
> (which involves per-cpu iteration) would cause an unreasonable overhead.
> 
> Suggested-by: David Rientjes 
> Signed-off-by: Michal Hocko 
> ---

Acked-by: Hillf Danton 

>  mm/vmscan.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 489212252cd6..9145e3f89eab 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -196,21 +196,21 @@ unsigned long zone_reclaimable_pages(struct zone *zone)
>  {
>   unsigned long nr;
> 
> - nr = zone_page_state(zone, NR_ACTIVE_FILE) +
> -  zone_page_state(zone, NR_INACTIVE_FILE) +
> -  zone_page_state(zone, NR_ISOLATED_FILE);
> + nr = zone_page_state_snapshot(zone, NR_ACTIVE_FILE) +
> +  zone_page_state_snapshot(zone, NR_INACTIVE_FILE) +
> +  zone_page_state_snapshot(zone, NR_ISOLATED_FILE);
> 
>   if (get_nr_swap_pages() > 0)
> - nr += zone_page_state(zone, NR_ACTIVE_ANON) +
> -   zone_page_state(zone, NR_INACTIVE_ANON) +
> -   zone_page_state(zone, NR_ISOLATED_ANON);
> + nr += zone_page_state_snapshot(zone, NR_ACTIVE_ANON) +
> +   zone_page_state_snapshot(zone, NR_INACTIVE_ANON) +
> +   zone_page_state_snapshot(zone, NR_ISOLATED_ANON);
> 
>   return nr;
>  }
> 
>  bool zone_reclaimable(struct zone *zone)
>  {
> - return zone_page_state(zone, NR_PAGES_SCANNED) <
> + return zone_page_state_snapshot(zone, NR_PAGES_SCANNED) <
>   zone_reclaimable_pages(zone) * 6;
>  }
> 
> --
> 2.7.0.rc3

RE: [RFC PATCH 5/6] iommu/arm-smmu: Option to treat instruction fetch as data read for SMMUv2

[Anup Patel]

> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: 28 January 2016 22:41
> To: Anup Patel; Catalin Marinas; Joerg Roedel; Will Deacon; Robin Murphy;
> Sricharan R; Linux IOMMU; Linux ARM Kernel
> Cc: Mark Rutland; Device Tree; Scott Branden; Pawel Moll; Ian Campbell; Ray
> Jui; Linux Kernel; Vikram Prakash; Rob Herring; bcm-kernel-feedback-list; 
> Kumar
> Gala
> Subject: Re: [RFC PATCH 5/6] iommu/arm-smmu: Option to treat instruction
> fetch as data read for SMMUv2
> 
> On 27/01/16 05:21, Anup Patel wrote:
> > Currently, the SMMU driver by default provides unprivilege read-write
> > permission in page table entries of stage1 page table. For SMMUv2 with
> > aarch64 long descriptor format, a privilege instruction fetch will
> > generate context fault. To allow privilege instruction fetch from a
> > MMU master we need to treat instruction fetch as data read.
> >
> > This patch adds an optional DT attribute 'smmu-inst-as-data' to treat
> > privilege/unprivilege instruction fetch as data read for SMMUv2.
> 
> What's the use-case for retaining the privilege attribute over the instruction
> attribute? The pagetable code still maps everything with unprivileged
> permissions, and it isn't going to be relevant for the vast majority of 
> devices.
> Conversely, the instruction/data distinction is likely to be useful in a lot 
> more
> cases - there's a veritable class of exploits around tricking a
> DSP/GPU/VPU/whatever into executing malicious firmware/shaders/etc. - and
> the IOMMU API does already have support for that which this change subtly
> undermines: if you override INSTCFG this way, you also need to stop the SMMU
> from claiming to support IOMMU_NOEXEC, because it no longer will.

Currently, there is no provision in IOMMU framework to specify privilege level
of a mapping. I thought in future someone might certainly add such a thing
because theoretically we can have accesses from a microcontroller or
coprocessor going through SMMU and microcontroller or coprocessor can
have two privilege levels.

Now, the list of all possible access types would be:
1. Privileged read
2. Privileged write
3. Privileged instruction fetch
4. Unprivileged read
5. Unprivileged write
6. Unprivileged instruction fetch

If we treat instruction fetch as data read then above would reduce to:
1. Privileged read
2. Privileged write
3. Unprivileged read
4. Unprivileged write

If we treat all privileged access as unprivileged then above would reduce to:
1. Unprivileged read
2. Unprivileged write
3. Unprivileged instruction fetch

The possible access types were reducing more if treated privileged accesses
as unprivileged accesses. This motivated me to prefer "treat instruction
fetch as data read" over "treat privileged access as unprivileged".

I am fine with both approaches. If we envision that IOMMU framework
no use for privileged accesses then we should go with "treat privileged
access as unprivileged" approach. In fact, I was already planning to base
this patchset upon your patchset and remove duplicate changes from
my patchset.

Regards,
Anup

Re: [PATCH v4 1/1] pci: fix unavailable irq number 255 reported by BIOS

[Chen Fan]

On 01/29/2016 11:37 AM, Rafael J. Wysocki wrote:

On Thursday, January 28, 2016 02:57:36 PM Bjorn Helgaas wrote:

Hi Chen,

Thanks a lot for persevering and working this all out!

On Thu, Jan 28, 2016 at 09:35:46AM +0800, Chen Fan wrote:

In our X86 environment, when enable Secure boot, we found an abnormal
phenomenon as following call trace shows. after investigation, we
found the firmware assigned an irq number 255 which means unknown
or no connection in PCI local spec for i801_smbus, meanwhile the
ACPI didn't configure the pci irq routing. and the 255 irq number
was assigned for megasa msix without IRQF_SHARED. then in this case
during i801_smbus probe, the i801_smbus driver would request irq with
bad irq number 255. but the 255 irq number was assigned for memgasa
with MSIX enable. which will cause request_irq fails and result in
the call trace below, here we introduce an IRQ_NOTCONNECTED to identify
the device interrupt is not connected.

i801_smbus :00:1f.3: enabling device (0140 -> 0143)
i801_smbus :00:1f.3: can't derive routing for PCI INT C
i801_smbus :00:1f.3: PCI INT C: no GSI
genirq: Flags mismatch irq 255. 0080 (i801_smbus) vs.  (megasa)
CPU: 0 PID: 2487 Comm: kworker/0:1 Not tainted 3.10.0-229.el7.x86_64 #1
Hardware name: FUJITSU PRIMEQUEST 2800E2/D3736, BIOS PRIMEQUEST 2000 Serie5

Call Trace:
   dump_stack+0x19/0x1b
   __setup_irq+0x54a/0x570
   request_threaded_irq+0xcc/0x170
   i801_probe+0x32f/0x508 [i2c_i801]
   local_pci_probe+0x45/0xa0
i801_smbus :00:1f.3: Failed to allocate irq 255: -16
i801_smbus: probe of :00:1f.3 failed with error -16

Signed-off-by: Chen Fan 
Signed-off-by: Thomas Gleixner 
Cc: Bjorn Helgaas 

Acked-by: Bjorn Helgaas 

Rafael, I assume you'll take this if you think it's ready.

I can do that.


This is a subtle problem and, if I understand correctly, can manifest
intermittently depending on the machine configuration.  For example,
if you got rid of the "megasa" driver, I suspect i801_smbus would not
complain, but it wouldn't work.

I think we might want to consider doing something for non-x86 arches
as well, but we can do that later.  I propose a changelog like the
following.  Please correct anything I got wrong.  I suspect we will be
revisiting this issue eventually, so I'd like to have a good
description.


x86/PCI: Recognize that Interrupt Line 255 means "not connected"

Per the x86-specific footnote to PCI spec r3.0, sec 6.2.4, the value 255 in
the Interrupt Line register means "unknown" or "no connection."
Previously, when we couldn't derive an IRQ from the _PRT, we fell back to
using the value from Interrupt Line as an IRQ.  It's questionable whether
we should do that at all, but the spec clearly suggests we shouldn't do it
for the value 255 on x86.

Calling request_irq() with IRQ 255 may succeed, but the driver won't
receive any interrupts.  Or, if IRQ 255 is shared with another device, it
may succeed, and the driver's ISR will be called at random times when the
*other* device interrupts.  Or it may fail if another device is using IRQ
255 with incompatible flags.  What we *want* is for request_irq() to fail
predictably so the driver can fall back to polling.

On x86, assume 255 in the Interrupt Line means the INTx line is not
connected.  In that case, set dev->irq to IRQ_NOTCONNECTED so request_irq()
will fail gracefully with -ENOTCONN.

We found this problem on a system where Secure Boot firmware assigned
Interrupt Line 255 to an i801_smbus device and another device was already
using MSI-X IRQ 255.  This was in v3.10, where i801_probe() fails if
request_irq() fails:

   i801_smbus :00:1f.3: enabling device (0140 -> 0143)
   i801_smbus :00:1f.3: can't derive routing for PCI INT C
   i801_smbus :00:1f.3: PCI INT C: no GSI
   genirq: Flags mismatch irq 255. 0080 (i801_smbus) vs.  (megasa)
   CPU: 0 PID: 2487 Comm: kworker/0:1 Not tainted 3.10.0-229.el7.x86_64 #1
   Hardware name: FUJITSU PRIMEQUEST 2800E2/D3736, BIOS PRIMEQUEST 2000 Serie5
   Call Trace:
 dump_stack+0x19/0x1b
 __setup_irq+0x54a/0x570
 request_threaded_irq+0xcc/0x170
 i801_probe+0x32f/0x508 [i2c_i801]
 local_pci_probe+0x45/0xa0
   i801_smbus :00:1f.3: Failed to allocate irq 255: -16
   i801_smbus: probe of :00:1f.3 failed with error -16

After aeb8a3d16ae0 ("i2c: i801: Check if interrupts are disabled"),
i801_probe() will fall back to polling if request_irq() fails.  But we
still need this patch because request_irq() may succeed or fail depending
on other devices in the system.  If request_irq() fails, i801_smbus will
work by falling back to polling, but if it succeeds, i801_smbus won't work
because it expects interrupts that it may not receive.

I like this. :-)

Chen, can you please add the changelog as suggested by Bjorn to the patch
and resend?

Sure, Thank all of you.

Chen




Thanks,
Rafael



.

Re: [PATCH v4 1/1] pci: fix unavailable irq number 255 reported by BIOS

[Rafael J. Wysocki]

On Thursday, January 28, 2016 02:57:36 PM Bjorn Helgaas wrote:
> Hi Chen,
> 
> Thanks a lot for persevering and working this all out!
> 
> On Thu, Jan 28, 2016 at 09:35:46AM +0800, Chen Fan wrote:
> > In our X86 environment, when enable Secure boot, we found an abnormal
> > phenomenon as following call trace shows. after investigation, we
> > found the firmware assigned an irq number 255 which means unknown
> > or no connection in PCI local spec for i801_smbus, meanwhile the
> > ACPI didn't configure the pci irq routing. and the 255 irq number
> > was assigned for megasa msix without IRQF_SHARED. then in this case
> > during i801_smbus probe, the i801_smbus driver would request irq with
> > bad irq number 255. but the 255 irq number was assigned for memgasa
> > with MSIX enable. which will cause request_irq fails and result in
> > the call trace below, here we introduce an IRQ_NOTCONNECTED to identify
> > the device interrupt is not connected.
> > 
> > i801_smbus :00:1f.3: enabling device (0140 -> 0143)
> > i801_smbus :00:1f.3: can't derive routing for PCI INT C
> > i801_smbus :00:1f.3: PCI INT C: no GSI
> > genirq: Flags mismatch irq 255. 0080 (i801_smbus) vs.  (megasa)
> > CPU: 0 PID: 2487 Comm: kworker/0:1 Not tainted 3.10.0-229.el7.x86_64 #1
> > Hardware name: FUJITSU PRIMEQUEST 2800E2/D3736, BIOS PRIMEQUEST 2000 Serie5
> > 
> > Call Trace:
> >   dump_stack+0x19/0x1b
> >   __setup_irq+0x54a/0x570
> >   request_threaded_irq+0xcc/0x170
> >   i801_probe+0x32f/0x508 [i2c_i801]
> >   local_pci_probe+0x45/0xa0
> > i801_smbus :00:1f.3: Failed to allocate irq 255: -16
> > i801_smbus: probe of :00:1f.3 failed with error -16
> > 
> > Signed-off-by: Chen Fan 
> > Signed-off-by: Thomas Gleixner 
> > Cc: Bjorn Helgaas 
> 
> Acked-by: Bjorn Helgaas 
> 
> Rafael, I assume you'll take this if you think it's ready.

I can do that.

> This is a subtle problem and, if I understand correctly, can manifest
> intermittently depending on the machine configuration.  For example,
> if you got rid of the "megasa" driver, I suspect i801_smbus would not
> complain, but it wouldn't work.
> 
> I think we might want to consider doing something for non-x86 arches
> as well, but we can do that later.  I propose a changelog like the
> following.  Please correct anything I got wrong.  I suspect we will be
> revisiting this issue eventually, so I'd like to have a good
> description.
> 
> 
> x86/PCI: Recognize that Interrupt Line 255 means "not connected"
> 
> Per the x86-specific footnote to PCI spec r3.0, sec 6.2.4, the value 255 in
> the Interrupt Line register means "unknown" or "no connection."
> Previously, when we couldn't derive an IRQ from the _PRT, we fell back to
> using the value from Interrupt Line as an IRQ.  It's questionable whether
> we should do that at all, but the spec clearly suggests we shouldn't do it
> for the value 255 on x86.
> 
> Calling request_irq() with IRQ 255 may succeed, but the driver won't
> receive any interrupts.  Or, if IRQ 255 is shared with another device, it
> may succeed, and the driver's ISR will be called at random times when the
> *other* device interrupts.  Or it may fail if another device is using IRQ
> 255 with incompatible flags.  What we *want* is for request_irq() to fail
> predictably so the driver can fall back to polling.
> 
> On x86, assume 255 in the Interrupt Line means the INTx line is not
> connected.  In that case, set dev->irq to IRQ_NOTCONNECTED so request_irq()
> will fail gracefully with -ENOTCONN.
> 
> We found this problem on a system where Secure Boot firmware assigned
> Interrupt Line 255 to an i801_smbus device and another device was already
> using MSI-X IRQ 255.  This was in v3.10, where i801_probe() fails if
> request_irq() fails:
> 
>   i801_smbus :00:1f.3: enabling device (0140 -> 0143)
>   i801_smbus :00:1f.3: can't derive routing for PCI INT C
>   i801_smbus :00:1f.3: PCI INT C: no GSI
>   genirq: Flags mismatch irq 255. 0080 (i801_smbus) vs.  (megasa)
>   CPU: 0 PID: 2487 Comm: kworker/0:1 Not tainted 3.10.0-229.el7.x86_64 #1
>   Hardware name: FUJITSU PRIMEQUEST 2800E2/D3736, BIOS PRIMEQUEST 2000 Serie5
>   Call Trace:
> dump_stack+0x19/0x1b
> __setup_irq+0x54a/0x570
> request_threaded_irq+0xcc/0x170
> i801_probe+0x32f/0x508 [i2c_i801]
> local_pci_probe+0x45/0xa0
>   i801_smbus :00:1f.3: Failed to allocate irq 255: -16
>   i801_smbus: probe of :00:1f.3 failed with error -16
> 
> After aeb8a3d16ae0 ("i2c: i801: Check if interrupts are disabled"),
> i801_probe() will fall back to polling if request_irq() fails.  But we
> still need this patch because request_irq() may succeed or fail depending
> on other devices in the system.  If request_irq() fails, i801_smbus will
> work by falling back to polling, but if it succeeds, i801_smbus won't work
> because it expects interrupts that it may not receive.

I like this. :-)

Chen, can you please add the changelog as suggested by Bjorn to 

Re: [PATCH] cpufreq: Fix NULL reference crash while accessing policy->governor_data

[Rafael J. Wysocki]

On Thursday, January 28, 2016 07:45:53 AM Viresh Kumar wrote:
> On 27-01-16, 23:54, Rafael J. Wysocki wrote:
> > So I've applied this, but I'm not sure it is sufficient yet.
> 
> At least, this solves the crash Juri was hitting on a multi cluster
> box.

Yes, it makes the crash go away in his setup.

> > Have you double checked whether or not stuff cannot be reordered by
> > the CPU and/or the compiler and no additional memory barriers are needed?
> 
> I don't think CPU will reorder things before a function call.

It can do that in theory.

First of all, functions may be inlined by the compiler.

Second, even if they aren't, the call instruction only means "take the next
instruction from that other location in memory" to the CPU and the instructions
following the call go into the pipeline along with the ones preceding it and
they may be reordered in the process.

> It can reorder lines,

Not lines, but instructions.

> which CPU thinks aren't related but it can't assume the
> same in this case. We have tons of code like this.

Code that relies on specific ordering of instructions executed by different
CPUs for correctness usually requires memory barriers.

Thanks,
Rafael

Re: [PATCH] Doc: Micrel-ksz90x1.txt: Update the Micrel phy documentation for ksz9031

[Rob Herring]

On Thu, Jan 28, 2016 at 10:49:27AM -0600, dingu...@opensource.altera.com wrote:
> From: Dinh Nguyen 
> 
> Update the Micrel phy documentation for the KSZ9031 PHY to represent how
> the actual values are calculated from the code.
> 
> Signed-off-by: Dinh Nguyen 
> ---
>  .../devicetree/bindings/net/micrel-ksz90x1.txt | 73 
> ++
>  1 file changed, 73 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt 
> b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
> index f9c32ad..9535b2b 100644
> --- a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
> +++ b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
> @@ -36,6 +36,71 @@ KSZ9031:
>value is 0, and the maximum is property-dependent. The increment
>step is 60ps.
>  
> +  The KSZ9031 hardware supports a range of skew values from negative to
> +  positive, where the specific range is property dependent. All values
> +  specified in the devicetree are offset by the minimum value so they
> +  can be represented as positive integers in the devicetree since it's
> +  difficult to represent a negative number in the devictree.

I don't think that is true anymore. dtc should allow negative numbers 
AIUI. That would be much better here.

Rob

[PATCH] mmc: mediatek: make sure clock is enabled when executing ops->card_busy()

[Chaotian Jing]

add pm_runtime_get_sync() before access MSDC_PS register

Signed-off-by: Chaotian Jing 
---
 drivers/mmc/host/mtk-sd.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 82a97ac..a56b16d 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -1054,13 +1054,15 @@ static int msdc_ops_switch_volt(struct mmc_host *mmc, 
struct mmc_ios *ios)
 static int msdc_card_busy(struct mmc_host *mmc)
 {
struct msdc_host *host = mmc_priv(mmc);
-   u32 status = readl(host->base + MSDC_PS);
+   u32 status;
 
-   /* check if any pin between dat[0:3] is low */
-   if (((status >> 16) & 0xf) != 0xf)
-   return 1;
+   pm_runtime_get_sync(host->dev);
+   status = readl(host->base + MSDC_PS);
+   pm_runtime_mark_last_busy(host->dev);
+   pm_runtime_put_autosuspend(host->dev);
 
-   return 0;
+   /* check if any pin between dat[0:3] is low */
+   return !!(((status >> 16) & 0xf) != 0xf);
 }
 
 static void msdc_request_timeout(struct work_struct *work)
-- 
1.8.1.1.dirty

[PATCH V3] netfilter: h323: avoid potential attack

[Zhouyi Zhou]

I think hackers chould build a malicious h323 packet to overflow
the pointer p which will panic during the memcpy(addr, p, len)
For example, he may fabricate a very large taddr->ipAddress.ip;
As suggested by Eric, this module is protected by a lock (nf_h323_lock)
so adding a variable h323_buffer_valid_bytes that would contain
the number of valid bytes would not require to change prototypes of
get_h2x5_addr.

Signed-off-by: Zhouyi Zhou 
Signed-off-by: Eric Dumazet 
Reviewed-by: Sergei Shtylyov  

---
 net/netfilter/nf_conntrack_h323_main.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/net/netfilter/nf_conntrack_h323_main.c 
b/net/netfilter/nf_conntrack_h323_main.c
index 9511af0..65d84bc 100644
--- a/net/netfilter/nf_conntrack_h323_main.c
+++ b/net/netfilter/nf_conntrack_h323_main.c
@@ -110,6 +110,11 @@ int (*nat_q931_hook) (struct sk_buff *skb,
 
 static DEFINE_SPINLOCK(nf_h323_lock);
 static char *h323_buffer;
+static unsigned int h323_buffer_valid_bytes;
+/* check offset overflow and out of range data reference */
+#define CHECK_BOUND(p, n) ((n) > h323_buffer_valid_bytes ||\
+  ((void *)(p) + (n) - (void *)h323_buffer \
+   > h323_buffer_valid_bytes))
 
 static struct nf_conntrack_helper nf_conntrack_helper_h245;
 static struct nf_conntrack_helper nf_conntrack_helper_q931[];
@@ -145,6 +150,7 @@ static int get_tpkt_data(struct sk_buff *skb, unsigned int 
protoff,
 
if (*data == NULL) {/* first TPKT */
/* Get first TPKT pointer */
+   h323_buffer_valid_bytes = tcpdatalen;
tpkt = skb_header_pointer(skb, tcpdataoff, tcpdatalen,
  h323_buffer);
BUG_ON(tpkt == NULL);
@@ -247,6 +253,9 @@ static int get_h245_addr(struct nf_conn *ct, const unsigned 
char *data,
return 0;
}
 
+   if (CHECK_BOUND(p, len + sizeof(__be16)))
+   return 0;
+
memcpy(addr, p, len);
memset((void *)addr + len, 0, sizeof(*addr) - len);
memcpy(port, p + len, sizeof(__be16));
@@ -669,6 +678,9 @@ int get_h225_addr(struct nf_conn *ct, unsigned char *data,
return 0;
}
 
+   if (CHECK_BOUND(p, len + sizeof(__be16)))
+   return 0;
+
memcpy(addr, p, len);
memset((void *)addr + len, 0, sizeof(*addr) - len);
memcpy(port, p + len, sizeof(__be16));
@@ -1248,6 +1260,7 @@ static unsigned char *get_udp_data(struct sk_buff *skb, 
unsigned int protoff,
if (dataoff >= skb->len)
return NULL;
*datalen = skb->len - dataoff;
+   h323_buffer_valid_bytes = *datalen;
return skb_header_pointer(skb, dataoff, *datalen, h323_buffer);
 }
 
-- 
1.9.1

Re: [PATCH RFC 1/3] of: Add vendor prefix for Si-En Technology

[Rob Herring]

On Thu, Jan 28, 2016 at 08:41:05PM +, Stefan Wahren wrote:
> Si-En Technology is a fabless design house which offers
> audio amplifiers, LED drivers and sensors.
> 
> Signed-off-by: Stefan Wahren 
> ---
>  .../devicetree/bindings/vendor-prefixes.txt|1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

Re: [PATCH RFC 2/3] DT: add binding for SN3218 LED driver

[Rob Herring]

On Thu, Jan 28, 2016 at 08:41:06PM +, Stefan Wahren wrote:
> This patch adds the binding for Si-En Technology SN3218
> 18-Channel LED driver.
> 
> Signed-off-by: Stefan Wahren 
> ---
>  .../devicetree/bindings/leds/leds-sn3218.txt   |   41 
> 
>  1 file changed, 41 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/leds/leds-sn3218.txt

One nit, otherwise:

Acked-by: Rob Herring 

> 
> diff --git a/Documentation/devicetree/bindings/leds/leds-sn3218.txt 
> b/Documentation/devicetree/bindings/leds/leds-sn3218.txt
> new file mode 100644
> index 000..bf632df
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/leds-sn3218.txt
> @@ -0,0 +1,41 @@
> +* Si-En Technology - SN3218 18-Channel LED Driver
> +
> +Required properties:
> +- compatible :
> + "si-en,sn3218"
> +- address-cells : must be 1
> +- size-cells : must be 0
> +- reg : I2C slave address, typically 0x54
> +
> +Each led is represented as a sub-node of the si-en,sn3218 device.
> +
> +LED sub-node properties:
> +- label : (optional) see Documentation/devicetree/bindings/leds/common.txt
> +- reg : number of LED line (could be from 0 to 17)
> +- linux,default-trigger : (optional)
> +   see Documentation/devicetree/bindings/leds/common.txt
> +
> +Example:
> +
> +sn3218@54 {
> + compatible = "si-en,sn3218";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x54>;
> +
> + led1@0 {

Just led@X please.

> + label = "led1";
> + reg = <0x0>;
> + };
> +
> + led2@1 {
> + label = "led2";
> + reg = <0x1>;
> + };
> +
> + led3@2 {
> + label = "led3";
> + reg = <0x2>;
> + };
> +};
> +
> -- 
> 1.7.9.5
> 

Re: [PATCH V2 01/11] dt-bindings: ARM: Mediatek: add MT2701/7623 string to the PMIC wrapper doc

[Rob Herring]

On Wed, Jan 20, 2016 at 08:58:53PM +0100, John Crispin wrote:
> Signed-off-by: John Crispin 
> Cc: devicet...@vger.kernel.org
> ---
>  Documentation/devicetree/bindings/soc/mediatek/pwrap.txt |1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

Re: [PATCH 1/2] Documentation: dt: reset: Add syscon reset binding

[Rob Herring]

On Mon, Jan 25, 2016 at 01:02:43PM -0600, Andrew F. Davis wrote:
> Add syscon reset controller binding. This will hook to the reset
> framework and use syscon/regmap to set reset bits. This allows
> reset control of individual SoC subsytems and devices with
> memory-mapped reset registers in a common register memory
> space.
> 
> Signed-off-by: Andrew F. Davis 
> [s-a...@ti.com: revise the binding format]
> Signed-off-by: Suman Anna 
> ---
>  .../devicetree/bindings/reset/syscon-reset.txt | 84 
> ++
>  1 file changed, 84 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/reset/syscon-reset.txt
> 
> diff --git a/Documentation/devicetree/bindings/reset/syscon-reset.txt 
> b/Documentation/devicetree/bindings/reset/syscon-reset.txt
> new file mode 100644
> index 000..466378a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/syscon-reset.txt
> @@ -0,0 +1,84 @@
> +SysCon Reset Controller
> +===
> +
> +Almost all SoCs have hardware modules that require reset control in addition
> +to clock and power control for their functionality. The reset control is
> +typically provided by means of memory-mapped I/O registers. These registers 
> are
> +sometimes a part of a larger register space region implementing various
> +functionalities. This register range is best represented as a syscon node to
> +allow multiple entities to access their relevant registers in the common
> +register space.
> +
> +A SysCon Reset Controller node defines a device that uses a syscon node
> +and provides reset management functionality for various hardware modules
> +present on the SoC.

This may be one of those cases that is too low level to put into DT.

> +
> +SysCon Reset Controller Node
> +
> +Each of the reset provider/controller nodes should have the following
> +properties.
> +
> +Required properties:
> +
> + - compatible: Should be "syscon-reset"
> + - syscon: phandle to the syscon node containing the reset registers
> + - #reset-cells  : Should be 6. Please see the reset consumer node below 
> for
> +  usage details
> +
> +SysCon Reset Consumer Nodes
> +===
> +Each of the reset consumer nodes should have the following properties,
> +in addition to their own properties.
> +
> +Required properties:
> +
> + - resets: A phandle and reset specifier pair, one pair for each reset
> +   signal that affects the device, or that the device manages.
> +   The phandle should point to the syscon node containing the
> +   reset registers, and the reset specifier should have 6
> +   cell-values. The reset specifier contains two similar pairs
> +   of 3 cell-values each, the first of the pair containing the
> +   reset control register information, and the second of the pair
> +   containing the reset status register information. The reset
> +   control and status registers can be same on some devices/SoCs.

What if there are no status bits?

> +
> +   Each of the pairs of 3 cell-values should have the following
> +   values:
> +  Cell #1 : register offset of the reset control/status
> +register from the syscon register base
> +  Cell #2 : bit shift value for the reset in the respective
> +reset control/status register
> +  Cell #3 : polarity of the reset bit. Should be 1 for resets
> +that are asserted when the bit is set, 0 for
> +resets that are asserted when the bit is cleared
> +
> +Please also refer to Documentation/devicetree/bindings/reset/reset.txt for
> +common reset controller usage by consumers.
> +
> +
> +Example:
> +
> +The following example demonstrates a syscon node, the reset controller node
> +using the syscon node, and a consumer (a DSP device) on the TI Keystone 2
> +Hawking SoC.
> +
> +/ {
> + soc {
> + psc: power-sleep-controller@0235 {
> + compatible = "syscon";
> + reg = <0x0235 0x1000>;
> + };
> +
> + pscrst: psc-reset {
> + compatible = "syscon-reset";
> + syscon = <>;
> + #reset-cells = <6>;
> + };

Any reason not to make this a child of psc?

> +
> + dsp0: dsp0 {
> + ...
> + resets = < 0xa3c 8 0 0x83c 8 0>;
> + ...
> + };
> + };
> +};
> -- 
> 2.7.0
> 

[lkp] [pipe] 759c01142a: -51.5% hackbench.throughput

[kernel test robot]

FYI, we noticed the below changes on

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 759c01142a5d0f364a462346168a56de28a80f52 ("pipe: limit the per-user 
amount of pages allocated in pipes")


=
compiler/cpufreq_governor/ipc/kconfig/mode/nr_threads/rootfs/tbox_group/testcase:
  
gcc-4.9/performance/pipe/x86_64-rhel/threads/1600%/debian-x86_64-2015-02-07.cgz/lkp-wsx02/hackbench

commit: 
  558041d8d21b48287224dd0e32cf19563c77607c
  759c01142a5d0f364a462346168a56de28a80f52

558041d8d21b4828 759c01142a5d0f364a46234616 
 -- 
 %stddev %change %stddev
 \  |\  
219967 ±  4% -51.5% 106583 ±  1%  hackbench.throughput
 5.319e+08 ± 11% -19.7%  4.273e+08 ±  0%  
hackbench.time.involuntary_context_switches
   2422668 ±  9% -36.4%1540731 ±  2%  hackbench.time.minor_page_faults
  7127 ± 11%  +9.4%   7800 ±  0%  
hackbench.time.percent_of_cpu_this_job_got
 42924 ±  9% +11.9%  48049 ±  1%  hackbench.time.system_time
  1665 ± 11% -49.3% 844.05 ±  1%  hackbench.time.user_time
534.25 ± 55%+298.5%   2129 ± 67%  numa-meminfo.node3.AnonHugePages
  8581 ± 57% -48.4%   4427 ±  1%  uptime.idle
   5705345 ± 13% +58.8%9061490 ±  5%  softirqs.RCU
279868 ±  8% +20.4% 336916 ±  1%  softirqs.SCHED
 26.75 ± 23%+245.8%  92.50 ± 39%  vmstat.procs.b
  9809 ± 13% -64.7%   3463 ±  7%  vmstat.procs.r
284320 ± 13% -45.9% 153686 ±  1%  vmstat.system.in
114.00 ± 10% -50.9%  56.00 ±  0%  time.file_system_outputs
 5.319e+08 ± 11% -19.7%  4.273e+08 ±  0%  time.involuntary_context_switches
   2422668 ±  9% -36.4%1540731 ±  2%  time.minor_page_faults
  1665 ± 11% -49.3% 844.05 ±  1%  time.user_time
 89.86 ± 10%  +8.9%  97.84 ±  0%  turbostat.%Busy
  2270 ± 10%  +8.9%   2471 ±  0%  turbostat.Avg_MHz
  1.45 ±  8% -52.6%   0.69 ±  9%  turbostat.CPU%c1
  0.17 ± 13% -52.2%   0.08 ± 34%  turbostat.CPU%c3
  8.53 ±116% -83.7%   1.39 ±  3%  turbostat.CPU%c6
  63583716 ± 16% -98.1%1183913 ± 53%  numa-numastat.node0.local_node
  63587769 ± 16% -98.1%1189061 ± 53%  numa-numastat.node0.numa_hit
  69989955 ±  6% -96.8%2239323 ±  8%  numa-numastat.node1.local_node
  69995282 ±  6% -96.8%2244474 ±  8%  numa-numastat.node1.numa_hit
  56620071 ± 22% -97.3%1520012 ± 32%  numa-numastat.node2.local_node
  56625301 ± 22% -97.3%1522594 ± 31%  numa-numastat.node2.numa_hit
  63753303 ± 22% -96.1%2508634 ± 14%  numa-numastat.node3.local_node
  63754612 ± 22% -96.1%2511213 ± 14%  numa-numastat.node3.numa_hit
  32233121 ± 15% -97.4% 830659 ± 60%  numa-vmstat.node0.numa_hit
  32193958 ± 15% -97.5% 790185 ± 63%  numa-vmstat.node0.numa_local
  35020615 ± 10% -96.4%1253289 ±  8%  numa-vmstat.node1.numa_hit
  34968563 ± 10% -96.6%1201078 ±  9%  numa-vmstat.node1.numa_local
  30394713 ± 14% -97.2% 843134 ± 31%  numa-vmstat.node2.numa_hit
  30373607 ± 14% -97.3% 824676 ± 31%  numa-vmstat.node2.numa_local
  32334081 ± 21% -95.5%1469250 ± 16%  numa-vmstat.node3.numa_hit
  32286373 ± 21% -95.6%1420300 ± 16%  numa-vmstat.node3.numa_local
 1.868e+08 ± 11% -51.0%   91569694 ± 13%  cpuidle.C1-NHM.time
   1743049 ± 10% -34.6%1139878 ± 11%  cpuidle.C1-NHM.usage
 1.918e+08 ± 12% -49.7%   96433830 ± 11%  cpuidle.C1E-NHM.time
   1243978 ± 16% -40.7% 738168 ± 12%  cpuidle.C1E-NHM.usage
  70404853 ±  8% -47.4%   37040591 ± 19%  cpuidle.C3-NHM.time
 4.723e+09 ±108% -81.6%  8.672e+08 ±  3%  cpuidle.C6-NHM.time
311666 ± 18% -47.9% 162252 ± 15%  cpuidle.C6-NHM.usage
 2.456e+08 ± 18% -53.2%   1.15e+08 ±  9%  cpuidle.POLL.time
260576 ± 21% -58.6% 107765 ± 17%  cpuidle.POLL.usage
906770 ±  8% -19.4% 730530 ±  5%  proc-vmstat.numa_hint_faults
  2.54e+08 ± 11% -97.1%7464740 ±  4%  proc-vmstat.numa_hit
 2.539e+08 ± 11% -97.1%7449281 ±  4%  proc-vmstat.numa_local
662291 ± 10% -33.4% 441016 ±  5%  proc-vmstat.numa_pages_migrated
   1203460 ±  6% -16.7%1002984 ±  5%  proc-vmstat.numa_pte_updates
   5716982 ± 17% -97.2% 158482 ± 40%  proc-vmstat.pgalloc_dma32
 2.521e+08 ± 11% -96.3%9338972 ±  3%  proc-vmstat.pgalloc_normal
   3627983 ±  4% -26.1%2682860 ±  1%  proc-vmstat.pgfault
 2.576e+08 ± 11% -96.4%9352801 ±  3%  proc-vmstat.pgfree
662291 ± 10% -33.4% 441016 ±  5%  proc-vmstat.pgmigrate_success
 27845 ± 11% -79.8%   5624 ±  1%  slabinfo.kmalloc-1024.active_objs
879.00 ± 11% -79.2% 183.00 ±  1%  slabinfo.kmalloc-1024.active_slabs
 28142 ± 11% -79.1%   

Re: [PATCH] nouveau: need to handle failed allocation

[Ben Skeggs]

On 01/29/2016 10:12 AM, Insu Yun wrote:
> 
> On Thu, Jan 28, 2016 at 7:08 PM, Ilia Mirkin  > wrote:
> 
> On Thu, Jan 28, 2016 at 7:09 PM, Insu Yun  > wrote:
> > drm_property_create_range can be failed in memory pressure.
> > So, it needs to be handled.
> >
> > Signed-off-by: Insu Yun mailto:wuni...@gmail.com>>
> > ---
> >  drivers/gpu/drm/nouveau/nouveau_display.c | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
> b/drivers/gpu/drm/nouveau/nouveau_display.c
> > index 24be27d..26b4902 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> > @@ -443,6 +443,12 @@ nouveau_display_create_properties(struct 
> drm_device *dev)
> > /* -100..+100 */
> > disp->color_vibrance_property =
> > drm_property_create_range(dev, 0, "color vibrance", 0, 
> 200);
> > +
> > +   if (!disp->underscan_hborder_property ||
> > +   !disp->underscan_vborder_property ||
> > +   !disp->vibrant_hue_property ||
> > +   !disp->color_vibrance_property)
> > +   return;
> 
> Aren't we at the end of the function anyways?
> 
> 
> Sorry. it is not perfect patch 
> I found this by my static analyzer.
> I have limited knowledge about this driver.
> I don't want to mass up your driver.
> What I want to do is to tell you there is a bug.
> I think we need to return error to caller.
I'm not so sure we do.  We check for valid pointers for these when
they're actually used, so no OOPS will occur.  Worst case, the driver
still loads correctly with some missing properties.

Ben.

>  
> 
> 
> >  }
> >
> >  int
> > --
> > 1.9.1
> >
> 
> 
> 
> 
> -- 
> Regards
> Insu Yun



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 3/3] param: convert some "on"/"off" users to strtobool

[Michael Ellerman]

On Thu, 2016-01-28 at 06:17 -0800, Kees Cook wrote:

> This changes several users of manual "on"/"off" parsing to use strtobool.

You should probably point out that it's a slight behaviour change for some
users. ie. parameters that previously *only* worked with "on"/"off", can now
also take 0/1/y/n etc.

But I don't think that's a show stopper.


> Signed-off-by: Kees Cook 
> Cc: x...@kernel.org
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: linux-s...@vger.kernel.org
> ---
>  arch/powerpc/kernel/rtasd.c  | 10 +++---
>  arch/powerpc/platforms/pseries/hotplug-cpu.c | 11 +++

Acked-by: Michael Ellerman  (powerpc)


cheers

Re: [PATCH] kexec: unmap reserved pages for each error-return way

[Xunlei Pang]

On 2016/01/28 at 17:02, Dmitry Safonov wrote:
> On 01/28/2016 05:58 AM, Xunlei Pang wrote:
>> Hi Dmitry,
>>  
>> On 2016/01/28 at 03:15, Andrew Morton wrote:
>>> On Wed, 27 Jan 2016 14:48:31 +0300 Dmitry Safonov  
>>> wrote:
>>>
 For allocation of kimage failure or kexec_prepare or load segments
 errors there is no need to keep crashkernel memory mapped.
 It will affect only s390 as map/unmap hook defined only for it.
 As on unmap s390 also changes os_info structure let's check return code
 and add info only on success.

>>> This conflicts (both mechanically and somewhat conceptually) with
>>> Xunlei Pang's "kexec: Introduce a protection mechanism for the
>>> crashkernel reserved memory" and "kexec: provide
>>> arch_kexec_protect(unprotect)_crashkres()".
>>>
>>> http://ozlabs.org/~akpm/mmots/broken-out/kexec-introduce-a-protection-mechanism-for-the-crashkernel-reserved-memory.patch
>>> http://ozlabs.org/~akpm/mmots/broken-out/kexec-introduce-a-protection-mechanism-for-the-crashkernel-reserved-memory-v4.patch
>>>
>>> and
>>>
>>> http://ozlabs.org/~akpm/mmots/broken-out/kexec-provide-arch_kexec_protectunprotect_crashkres.patch
>>> http://ozlabs.org/~akpm/mmots/broken-out/kexec-provide-arch_kexec_protectunprotect_crashkres-v4.patch
>>>
>>> so can we please sort all that out?
>>
>> Ah, I've checked git-log history, they are almost the same idea, can 
>> crash_unmap/map_reserved_pages()
>> be re-implemented using the new  arch_kexec_unprotect/protect_crashkres() on 
>> S390?
> Sorry, didn't fetched akpm before sending.
> Yes, sounds like really right thing to do to have one united arch-helper.

Yeah, as Michael said, "memblock_remove(crash_base, crash_size)" creates a big 
hole in the kernel pgtable.
In order to have one united arch-helper, I guess we can forbid this to let the 
pgtable setup for crash memory,
then we can easily move the logic of crash_map_reserved_pages() to 
arch_kexec_unprotect_crashkres(),  and
move crash_unmap_reserved_pages() to arch_kexec_protect_crashkres(). After that 
crash_map_reserved_pages()
called in crash_shrink_memory() can be safely removed as well.

Regards,
Xunlei

>>
>> Regards,
>> Xunlei
>>
>>> ___
>>> kexec mailing list
>>> ke...@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/kexec
>>
>
>
> -- 
> Regards,
> Dmitry Safonov

RE: [PATCH] cputime: Fix timeval-->cputime conversion

[Zengtao (B)]

> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Thursday, January 28, 2016 7:52 PM
> To: Thomas Gleixner
> Cc: Zengtao (B); LKML; Frederic Weisbecker
> Subject: Re: [PATCH] cputime: Fix timeval-->cputime conversion
> 
> On Thursday 28 January 2016 09:22:04 Thomas Gleixner wrote:
> > Cc'ing Arnd
> >
> > On Thu, 28 Jan 2016, zengtao wrote:
> >
> > > The structure:
> > > struct timeval {
> > >   __kernel_time_t tv_sec; /* seconds */
> > >   __kernel_suseconds_ttv_usec;/* microseconds */
> > > };
> > > both __kernel_time_t and __kernel_suseconds_t are short than u64
> > > when it is 32bit platform, so force u64 conversion here.
> > >
> > > Signed-off-by: zengtao 
> >
> > Reviewed-by: Thomas Gleixner 
> 
> This seems to miss timespec_to_cputime(), which has the same problem,
> so only setitimer() is fixed, but not nanosleep() or timer_settime().
Yes, I have checked the code just now, the timespec_to_cputime() has the 
same problem.I found the origin issue through setitimer().And I think the 
timespec_to_cputime() only affects timer_settime(),by which means it affects 
nanosleep? 

> 
> There should probably be some explanation in which cases this happens,
> my reading is that can only occur on MIPS32 and ARM32 with "Full dynticks
> CPU time accounting" enabled, which is required for CONFIG_NO_HZ_FULL,
> so we need this backported to any kernel that includes
> 31c1fc818715 ("ARM: Kconfig: allow full nohz CPU accounting"), i.e.
> v3.13 or higher, correct?
Yes.
> 
>   Arnd
> 
> > >  include/asm-generic/cputime_nsecs.h | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/include/asm-generic/cputime_nsecs.h
> b/include/asm-generic/cputime_nsecs.h
> > > index 0419485..e2f7ff9 100644
> > > --- a/include/asm-generic/cputime_nsecs.h
> > > +++ b/include/asm-generic/cputime_nsecs.h
> > > @@ -91,7 +91,8 @@ static inline void cputime_to_timespec(const
> cputime_t ct, struct timespec *val)
> > >   */
> > >  static inline cputime_t timeval_to_cputime(const struct timeval *val)
> > >  {
> > > - u64 ret = val->tv_sec * NSEC_PER_SEC + val->tv_usec *
> NSEC_PER_USEC;
> > > + u64 ret = (u64)val->tv_sec * NSEC_PER_SEC +
> > > + val->tv_usec * NSEC_PER_USEC;
> > >   return (__force cputime_t) ret;
> > >  }
> > >  static inline void cputime_to_timeval(const cputime_t ct, struct timeval
> *val)
> > > --
> > > 1.9.1
> > >
> > >

Re: [PATCH 07/31] Add debugger entry points for NIOS2

[Ley Foon Tan]

On Fri, Jan 29, 2016 at 3:46 AM, Jeffrey Merkey  wrote:
> This patch series adds an export which can be set by system debuggers to
> direct the hard lockup and soft lockup detector to trigger a breakpoint
> exception and enter a debugger if one is active.  It is assumed that if
> someone sets this variable, then an breakpoint handler of some sort will
> be actively loaded or registered via the notify die handler chain.
>
> This addition is extremely useful for debugging hard and soft lockups
> real time and quickly from a console debugger.
>
> Signed-off-by: Jeffrey Merkey 
> ---
>  arch/nios2/include/asm/kdebug.h | 5 +
>  1 file changed, 5 insertions(+)
>  create mode 100644 arch/nios2/include/asm/kdebug.h
>
> diff --git a/arch/nios2/include/asm/kdebug.h b/arch/nios2/include/asm/kdebug.h
> new file mode 100644
> index 000..d5d9957
> --- /dev/null
> +++ b/arch/nios2/include/asm/kdebug.h
> @@ -0,0 +1,5 @@
> +
> +static inline void arch_breakpoint(void)
> +{
> +   __asm__ __volatile__("trap 30\n");
> +}
> --
Hi Jeffrey

We already have similar function in arch/nios2/include/asm/kgdb.h. Can
we reuse this?

static inline void arch_kgdb_breakpoint(void)
{
__asm__ __volatile__("trap 30\n");
}

Regards
Ley Foon

Re: [RFC][PATCH] seccomp: add SECCOMP_RET_ACK for non-fatal SIGSYS

[Jeffrey Vander Stoep]

Thanks! This is just what I need.

What are the drawbacks to returning the sigsys before executing the
system call? Otherwise this loses the benefit of properly reporting
registers for argument inspection.

How about SECCOMP_RET_PERMISSIVE? Describes the application rather
than the implementation. Otherwise preference is for
SECCOMP_RET_ALLOW_SIGSYS.

Re: [PATCH] Documentation: rockchip-dw-mshc: add RK3036 dw-mshc description

[Rob Herring]

On Tue, Jan 26, 2016 at 10:34:14AM +0800, Shawn Lin wrote:
> rk3036 dtsi file add dw-mshc compatible "rockchip,rk3036-dw-mshc"
> but didn't add it into rockchip-dw-mshc.txt.
> 
> Signed-off-by: Shawn Lin 
> ---
> 
>  Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

Re: [PATCH v4] lib/spinlock_debug.c: prevent a recursive cycle in the debug code

[Byungchul Park]

On Fri, Jan 29, 2016 at 09:54:06AM +0900, Sergey Senozhatsky wrote:
> because you don't give any details and don't answer any questions.

There are 2 ways to make the kernel better and stabler.

1) Remove the possiblity which make the system go crazy, even though it
would hardly happen since the possiblity is too low.

2) Fix it after facing some problems in practice and debugging it.

I started to write this patch due to the 2nd reason after seeing the
backtrace in gdb. But I lost the data with which I can debug it now,
since I was mis-convinced that it was done. So I could not answer it for
the your questions about memory corruption and cpu off. Sorry for not
informing you these facts in advance. But please remind that I was in
progress by the 1st way.

> it took a while to even find out that you are reporting this issues
> not against a real H/W, but a qemu. I suppose qemu-arm running on
> x86_64 box.

No matter what kind of box I used because I only kept talking about the
possiblity. It does not depend on a box at all.

> 
> now, what else we don't know?
> 
> explain STEP-BY-STEP why do you think spinlock debug code can lockup
> itself. not just "I don't think this is the case, I don't think that
> is the case".

I did explaining the reason in detail even though there's something I
missed. I've never said "I don't think this is the case" on the
description explaining the problem. Anyway, I am not sure about my patch
now, thank to your advice.

> 
> on very spin_dump recursive call it waits for the spin_lock and when
> it eventually grabs it, it does the job that it wanted to do under
> that spin lock, unlock it and return back. and the only case when it
> never "return back" is when it never "eventually grabs it".

Right. I missed it.

> 
> so I still don't see what issue you fix here -- the possibility to
> consume the entire kernel stack doing recursive spin_dump->spin_lock()
> calls because:
>   a) something never unlocks the lock (no matter why.. corruption, HW
> fault, etc.)
> or
>   b) everything was OK, but we attempted to printk() already
> being in a very-very deep callstack, so doing 5 extra
> printk->spin_dump->printk->spin_dump would simply kill it.
> 
> 
> if none of the above. then what you report and fix is simply non
> realistic. spin_dump must eventually unwind the stack back. yes,
> you'll see a lot of dump_stack() and all cpus backtraces done on
> every roollback stack. but you would still see some of them anyway,
> even w/o the spinlock debug code -- because you'd just
> raw_spin_lock_irqsave() on that lock for a very long time; which
> does upset watchdog, etc.

I am not sure now, if it can be fixed by the 1st way, that is, removing
the possiblity which make the system go crazy. There's something I missed.
Now I have to solve this problem by the 2nd way after reproducing it and
debugging it in detail. I still keep trying to reproduce it now.

Anyway. Thank you very much.

Thanks,
Byungchul

> 
> 
> please start explaining the things.
> 
>   -ss

Re: [PATCH 3/3] input: touchscreen: ad7879: add device tree support

[Rob Herring]

On Mon, Jan 25, 2016 at 07:04:37PM -0800, Stefan Agner wrote:
> Add device tree support for the I2C variant of AD7879 (AD7879-1). This
> allows to specify the touchscreen controller as a I2C client node.
> Most of the options available as platform data are also available as
> device tree properties. Exporting the GPIO is currently not possible
> through device tree.
> 
> Signed-off-by: Stefan Agner 
> ---
>  .../bindings/input/touchscreen/ad7879-i2c.txt  | 47 
>  drivers/input/touchscreen/ad7879-i2c.c | 63 
> +-
>  drivers/input/touchscreen/ad7879-spi.c |  3 +-
>  drivers/input/touchscreen/ad7879.c |  2 +-
>  drivers/input/touchscreen/ad7879.h |  1 +
>  5 files changed, 113 insertions(+), 3 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/input/touchscreen/ad7879-i2c.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/input/touchscreen/ad7879-i2c.txt 
> b/Documentation/devicetree/bindings/input/touchscreen/ad7879-i2c.txt
> new file mode 100644
> index 000..bf169a2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/touchscreen/ad7879-i2c.txt
> @@ -0,0 +1,47 @@
> +* Analog Devices AD7879-1/AD7889-1 touchscreen interface (I2C)
> +
> +Required properties:
> +- compatible: must be "adi,ad7879-1"
> +- reg: i2c slave address
> +- interrupt-parent: the phandle for the interrupt controller
> +- interrupts: touch controller interrupt
> +- resistance-plate-x : total resistance of X-plate (for pressure
> +   calculation)
> +- touchscreen-max-pressure   : maximum reported pressure
> +- touchscreen-swapped-x-y: X and Y axis are swapped (boolean)
> +   Swapping is done after inverting the axis
> +Optional properties:
> +- first-conversion-delay : 0-12 in 128us steps (starting with 128us)
> +   13: 2.560ms
> +   14: 3.584ms
> +   15: 4.096ms
> +- acquisition-time   : 0: 2us
> +   1: 4us
> +   2: 8us
> +   3: 16us
> +- median-filter-size : 0: disabled
> +   1: 4 measurements
> +   2: 8 measurements
> +   3: 16 measurements
> +- averaging  : 0: 2 middle values (1 if median disabled)
> +   1: 4 middle values
> +   2: 8 middle values
> +   3: 16 values
> +- conversion-interval:   : 0: convert one time only
> +   1-255: 515us + val * 35us (up to 9.440ms)

These all should be prefixed with "adi,". Also, please state the sizes 
are 8-bit.

> +
> +Example:
> +
> + ad7879@2c {
> + compatible = "adi,ad7879-1";
> + reg = <0x2c>;
> + interrupt-parent = <>;
> + interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
> + resistance-plate-x = <120>;
> + touchscreen-max-pressure = <4096>;
> + first-conversion-delay = /bits/ 8 <3>;
> + acquisition-time = /bits/ 8 <1>;
> + median-filter-size = /bits/ 8 <2>;
> + averaging = /bits/ 8 <1>;
> + conversion-interval = /bits/ 8 <255>;
> + };

Re: [PATCHv2] SCSI: usd ida for host number management

[Martin K. Petersen]

> "Lee" == Lee Duncan  writes:

Lee> Update the SCSI hosts module to use ida to manage its host_no index
Lee> instead of an ATOMIC integer. This means that the SCSI host number
Lee> will now be reclaimable.

Applied to 4.6/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [LKP] [lkp] [locks] 7f3697e24d: +35.1% will-it-scale.per_thread_ops

[Huang, Ying]

Jeff Layton  writes:

> On Fri, 29 Jan 2016 09:32:19 +0800
> kernel test robot  wrote:
>
>> FYI, we noticed the below changes on
>> 
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>> commit 7f3697e24dc3820b10f445a4a7d914fc356012d1 ("locks: fix unlock when 
>> fcntl_setlk races with a close")
>> 
>> 
>> =
>> compiler/cpufreq_governor/kconfig/rootfs/tbox_group/test/testcase:
>>   
>> gcc-4.9/performance/x86_64-rhel/debian-x86_64-2015-02-07.cgz/lkp-snb01/lock1/will-it-scale
>> 
>> commit: 
>>   9189922675ecca0fab38931d86b676e9d79602dc
>>   7f3697e24dc3820b10f445a4a7d914fc356012d1
>> 
>> 9189922675ecca0f 7f3697e24dc3820b10f445a4a7 
>>  -- 
>>  %stddev %change %stddev
>>  \  |\  
>>2376432 ±  0%  +2.1%2427484 ±  0%  will-it-scale.per_process_ops
>> 807889 ±  0% +35.1%1091496 ±  4%  will-it-scale.per_thread_ops
>>  22.08 ±  2% +89.1%  41.75 ±  5%  will-it-scale.time.user_time
>>1238371 ± 14%+100.4%2481345 ± 39%  cpuidle.C1E-SNB.time
>>   3098 ± 57% -66.6%   1035 ±171%  numa-numastat.node1.other_node
>> 379.25 ±  8% -21.4% 298.00 ± 12%  
>> numa-vmstat.node0.nr_alloc_batch
>>  22.08 ±  2% +89.1%  41.75 ±  5%  time.user_time
>>   1795 ±  4%  +7.5%   1930 ±  2%  vmstat.system.cs
>>   0.54 ±  5%+136.9%   1.28 ± 10%  
>> perf-profile.cycles.___might_sleep.__might_sleep.kmem_cache_alloc.locks_alloc_lock.__posix_lock_file
>>   1.65 ± 57%+245.2%   5.70 ± 29%  
>> perf-profile.cycles.__fdget_raw.sys_fcntl.entry_SYSCALL_64_fastpath
>>   1.58 ± 59%+248.3%   5.50 ± 31%  
>> perf-profile.cycles.__fget.__fget_light.__fdget_raw.sys_fcntl.entry_SYSCALL_64_fastpath
>>   1.62 ± 58%+246.3%   5.63 ± 30%  
>> perf-profile.cycles.__fget_light.__fdget_raw.sys_fcntl.entry_SYSCALL_64_fastpath
>>   0.00 ± -1%  +Inf%   5.88 ± 11%  
>> perf-profile.cycles.__memset.locks_alloc_lock.__posix_lock_file.vfs_lock_file.do_lock_file_wait
>>   2.50 ±  2%-100.0%   0.00 ± -1%  
>> perf-profile.cycles.__memset.locks_alloc_lock.__posix_lock_file.vfs_lock_file.fcntl_setlk
>>   1.29 ±  4%+138.8%   3.09 ± 11%  
>> perf-profile.cycles.__memset.locks_alloc_lock.fcntl_setlk.sys_fcntl.entry_SYSCALL_64_fastpath
>>   0.47 ±  9%+144.4%   1.16 ± 11%  
>> perf-profile.cycles.__might_fault.fcntl_setlk.sys_fcntl.entry_SYSCALL_64_fastpath
>>   0.37 ± 12%+140.3%   0.90 ±  9%  
>> perf-profile.cycles.__might_sleep.__might_fault.fcntl_setlk.sys_fcntl.entry_SYSCALL_64_fastpath
>>   0.86 ±  6%+137.7%   2.05 ± 10%  
>> perf-profile.cycles.__might_sleep.kmem_cache_alloc.locks_alloc_lock.__posix_lock_file.vfs_lock_file
>>   0.61 ± 14% +56.8%   0.95 ± 14%  
>> perf-profile.cycles.__might_sleep.kmem_cache_alloc.locks_alloc_lock.fcntl_setlk.sys_fcntl
>>   0.00 ± -1%  +Inf%  39.84 ± 12%  
>> perf-profile.cycles.__posix_lock_file.vfs_lock_file.do_lock_file_wait.fcntl_setlk.sys_fcntl
>>  16.44 ±  3%-100.0%   0.00 ± -1%  
>> perf-profile.cycles.__posix_lock_file.vfs_lock_file.fcntl_setlk.sys_fcntl.entry_SYSCALL_64_fastpath
>>   0.00 ± -1%  +Inf%   1.77 ± 11%  
>> perf-profile.cycles._raw_spin_lock.__posix_lock_file.vfs_lock_file.do_lock_file_wait.fcntl_setlk
>>  59.34 ±  1% -72.4%  16.36 ± 33%  
>> perf-profile.cycles._raw_spin_lock.fcntl_setlk.sys_fcntl.entry_SYSCALL_64_fastpath
>>   0.46 ± 11%+144.9%   1.13 ± 19%  
>> perf-profile.cycles.avc_has_perm.inode_has_perm.file_has_perm.selinux_file_fcntl.security_file_fcntl
>>   0.87 ±  6%+103.2%   1.77 ± 12%  
>> perf-profile.cycles.avc_has_perm.inode_has_perm.file_has_perm.selinux_file_lock.security_file_lock
>>   0.81 ±  4%+135.7%   1.90 ± 10%  
>> perf-profile.cycles.copy_user_generic_string.sys_fcntl.entry_SYSCALL_64_fastpath
>>   0.00 ± -1%  +Inf%  41.86 ± 12%  
>> perf-profile.cycles.do_lock_file_wait.part.29.fcntl_setlk.sys_fcntl.entry_SYSCALL_64_fastpath
>>   0.88 ±  6%+127.8%   2.00 ±  9%  
>> perf-profile.cycles.entry_SYSCALL_64
>>   0.86 ±  4%+122.6%   1.92 ± 12%  
>> perf-profile.cycles.entry_SYSCALL_64_after_swapgs
>>  84.98 ±  0%  -9.1%  77.20 ±  2%  
>> perf-profile.cycles.fcntl_setlk.sys_fcntl.entry_SYSCALL_64_fastpath
>>   0.76 ± 10%+142.1%   1.84 ± 14%  
>> perf-profile.cycles.file_has_perm.selinux_file_fcntl.security_file_fcntl.sys_fcntl.entry_SYSCALL_64_fastpath
>>   1.35 ±  4%+106.3%   2.78 ± 11%  
>> perf-profile.cycles.file_has_perm.selinux_file_lock.security_file_lock.fcntl_setlk.sys_fcntl
>>   0.00 ± -1%  +Inf%   0.89 ± 12%  
>> 

Re: [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS

[Olof Johansson]

On Thu, Jan 28, 2016 at 2:20 PM, Suravee Suthikulanit
 wrote:
> Hi Olof,
>
> On 1/28/2016 3:39 PM, Olof Johansson wrote:
>>
>> Hi Suravee,
>>
>> On Wed, Jan 27, 2016 at 1:11 PM, Suravee Suthikulpanit
>>  wrote:
>>>
>>> From: Suravee Suthikulpanit 
>>>
>>> This patch series contains several updates for the AMD Seattle SOC DTS
>>> files.
>>> It also adds new board files for newer Overdrive and Linaro 96boards
>>> (Husky)
>>> platforms.
>>
>>
>> My Overdrive comes with DT provided by firmware, so there's no need to
>> have a in-kernel-tree DT source.
>
>
> You are correct that the FW comes with DT, and in typical case, you wouldn't
> need this.
>
>> Are you aware of other reasons to have it here? I just foresee
>> divergence and conflicts between the two. It was quite obvious before
>> this update when the FW-provided DT was a lot more complete than what
>> we had in the kernel tree.
>
>
> However, there are still new/updated drivers being developed, and sometimes
> requires new/changes in DT binding. So, the DT that comes with the FW can
> get out of date, and will lack the support for new drivers.

Note that it's expected that the driver will cope with the old DT
contents, i.e. it needs to go with defaults that made sense before the
binding was updated.

It, however, doesn't have to enable new features. In other words,
booting with an old DT needs to continue working. You can't require a
user to update DT to avoid getting driver breakage.

(The opposite is not enforced: Booting with a DT that is newer than
the kernel isn't guaranteed to always work).

> Certain version of the FW allows overriding the DT that comes with the FW.
> So, we are providing the in-kernel DT to allow developers to provide the
> updated device tree for newer kernels. This patch series is bringing the
> in-kernel DT closer to what the latest FW is providing to avoid potential
> conflicts.

I do appreciate keeping the kernel one up to date with what firmware
provides if it's truly needed, but I'd even more prefer that it
wasn't. After all, it's how the ACPI-based booting works (no
overriding table provided with the kernel), so it's a model you should
already be somewhat familiar with. :)

I'm not doing a hard NAK on this, but I would like to get a bit more
understanding of why it's considered needed.


-Olof

Re: [lkp] [locks] 7f3697e24d: +35.1% will-it-scale.per_thread_ops

[Jeff Layton]

On Fri, 29 Jan 2016 09:32:19 +0800
kernel test robot  wrote:

> FYI, we noticed the below changes on
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> commit 7f3697e24dc3820b10f445a4a7d914fc356012d1 ("locks: fix unlock when 
> fcntl_setlk races with a close")
> 
> 
> =
> compiler/cpufreq_governor/kconfig/rootfs/tbox_group/test/testcase:
>   
> gcc-4.9/performance/x86_64-rhel/debian-x86_64-2015-02-07.cgz/lkp-snb01/lock1/will-it-scale
> 
> commit: 
>   9189922675ecca0fab38931d86b676e9d79602dc
>   7f3697e24dc3820b10f445a4a7d914fc356012d1
> 
> 9189922675ecca0f 7f3697e24dc3820b10f445a4a7 
>  -- 
>  %stddev %change %stddev
>  \  |\  
>2376432 ±  0%  +2.1%2427484 ±  0%  will-it-scale.per_process_ops
> 807889 ±  0% +35.1%1091496 ±  4%  will-it-scale.per_thread_ops
>  22.08 ±  2% +89.1%  41.75 ±  5%  will-it-scale.time.user_time
>1238371 ± 14%+100.4%2481345 ± 39%  cpuidle.C1E-SNB.time
>   3098 ± 57% -66.6%   1035 ±171%  numa-numastat.node1.other_node
> 379.25 ±  8% -21.4% 298.00 ± 12%  numa-vmstat.node0.nr_alloc_batch
>  22.08 ±  2% +89.1%  41.75 ±  5%  time.user_time
>   1795 ±  4%  +7.5%   1930 ±  2%  vmstat.system.cs
>   0.54 ±  5%+136.9%   1.28 ± 10%  
> perf-profile.cycles.___might_sleep.__might_sleep.kmem_cache_alloc.locks_alloc_lock.__posix_lock_file
>   1.65 ± 57%+245.2%   5.70 ± 29%  
> perf-profile.cycles.__fdget_raw.sys_fcntl.entry_SYSCALL_64_fastpath
>   1.58 ± 59%+248.3%   5.50 ± 31%  
> perf-profile.cycles.__fget.__fget_light.__fdget_raw.sys_fcntl.entry_SYSCALL_64_fastpath
>   1.62 ± 58%+246.3%   5.63 ± 30%  
> perf-profile.cycles.__fget_light.__fdget_raw.sys_fcntl.entry_SYSCALL_64_fastpath
>   0.00 ± -1%  +Inf%   5.88 ± 11%  
> perf-profile.cycles.__memset.locks_alloc_lock.__posix_lock_file.vfs_lock_file.do_lock_file_wait
>   2.50 ±  2%-100.0%   0.00 ± -1%  
> perf-profile.cycles.__memset.locks_alloc_lock.__posix_lock_file.vfs_lock_file.fcntl_setlk
>   1.29 ±  4%+138.8%   3.09 ± 11%  
> perf-profile.cycles.__memset.locks_alloc_lock.fcntl_setlk.sys_fcntl.entry_SYSCALL_64_fastpath
>   0.47 ±  9%+144.4%   1.16 ± 11%  
> perf-profile.cycles.__might_fault.fcntl_setlk.sys_fcntl.entry_SYSCALL_64_fastpath
>   0.37 ± 12%+140.3%   0.90 ±  9%  
> perf-profile.cycles.__might_sleep.__might_fault.fcntl_setlk.sys_fcntl.entry_SYSCALL_64_fastpath
>   0.86 ±  6%+137.7%   2.05 ± 10%  
> perf-profile.cycles.__might_sleep.kmem_cache_alloc.locks_alloc_lock.__posix_lock_file.vfs_lock_file
>   0.61 ± 14% +56.8%   0.95 ± 14%  
> perf-profile.cycles.__might_sleep.kmem_cache_alloc.locks_alloc_lock.fcntl_setlk.sys_fcntl
>   0.00 ± -1%  +Inf%  39.84 ± 12%  
> perf-profile.cycles.__posix_lock_file.vfs_lock_file.do_lock_file_wait.fcntl_setlk.sys_fcntl
>  16.44 ±  3%-100.0%   0.00 ± -1%  
> perf-profile.cycles.__posix_lock_file.vfs_lock_file.fcntl_setlk.sys_fcntl.entry_SYSCALL_64_fastpath
>   0.00 ± -1%  +Inf%   1.77 ± 11%  
> perf-profile.cycles._raw_spin_lock.__posix_lock_file.vfs_lock_file.do_lock_file_wait.fcntl_setlk
>  59.34 ±  1% -72.4%  16.36 ± 33%  
> perf-profile.cycles._raw_spin_lock.fcntl_setlk.sys_fcntl.entry_SYSCALL_64_fastpath
>   0.46 ± 11%+144.9%   1.13 ± 19%  
> perf-profile.cycles.avc_has_perm.inode_has_perm.file_has_perm.selinux_file_fcntl.security_file_fcntl
>   0.87 ±  6%+103.2%   1.77 ± 12%  
> perf-profile.cycles.avc_has_perm.inode_has_perm.file_has_perm.selinux_file_lock.security_file_lock
>   0.81 ±  4%+135.7%   1.90 ± 10%  
> perf-profile.cycles.copy_user_generic_string.sys_fcntl.entry_SYSCALL_64_fastpath
>   0.00 ± -1%  +Inf%  41.86 ± 12%  
> perf-profile.cycles.do_lock_file_wait.part.29.fcntl_setlk.sys_fcntl.entry_SYSCALL_64_fastpath
>   0.88 ±  6%+127.8%   2.00 ±  9%  
> perf-profile.cycles.entry_SYSCALL_64
>   0.86 ±  4%+122.6%   1.92 ± 12%  
> perf-profile.cycles.entry_SYSCALL_64_after_swapgs
>  84.98 ±  0%  -9.1%  77.20 ±  2%  
> perf-profile.cycles.fcntl_setlk.sys_fcntl.entry_SYSCALL_64_fastpath
>   0.76 ± 10%+142.1%   1.84 ± 14%  
> perf-profile.cycles.file_has_perm.selinux_file_fcntl.security_file_fcntl.sys_fcntl.entry_SYSCALL_64_fastpath
>   1.35 ±  4%+106.3%   2.78 ± 11%  
> perf-profile.cycles.file_has_perm.selinux_file_lock.security_file_lock.fcntl_setlk.sys_fcntl
>   0.00 ± -1%  +Inf%   0.89 ± 12%  
> perf-profile.cycles.flock_to_posix_lock.fcntl_setlk.sys_fcntl.entry_SYSCALL_64_fastpath
>   6.90 ±  4% -48.6%   3.55 ± 27%  
> perf-profile.cycles.fput.entry_SYSCALL_64_fastpath
>   

[PATCHv2 1/2] mm/page_poison.c: Enable PAGE_POISONING as a separate option

[Laura Abbott]

Page poisoning is currently setup as a feature if architectures don't
have architecture debug page_alloc to allow unmapping of pages. It has
uses apart from that though. Clearing of the pages on free provides
an increase in security as it helps to limit the risk of information
leaks. Allow page poisoning to be enabled as a separate option
independent of any other debug feature. Because of how hiberanation
is implemented, the checks on alloc cannot occur if hibernation is
enabled. This option can also be set on !HIBERNATION as well.

Credit to Grsecurity/PaX team for inspiring this work

Signed-off-by: Laura Abbott 
---
 Documentation/kernel-parameters.txt |   5 ++
 include/linux/mm.h  |   9 ++
 mm/Kconfig.debug|  22 -
 mm/Makefile |   2 +-
 mm/debug-pagealloc.c| 137 
 mm/page_alloc.c |   2 +
 mm/page_poison.c| 173 
 7 files changed, 211 insertions(+), 139 deletions(-)
 delete mode 100644 mm/debug-pagealloc.c
 create mode 100644 mm/page_poison.c

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 87d40a7..fdade3d 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2716,6 +2716,11 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
we can turn it on.
on: enable the feature
 
+   page_poison=[KNL] Boot-time parameter changing the state of
+   poisoning on the buddy allocator.
+   off: turn off poisoning
+   on: turn on poisoning
+
panic=  [KNL] Kernel behaviour on panic: delay 
timeout > 0: seconds before rebooting
timeout = 0: wait forever
diff --git a/include/linux/mm.h b/include/linux/mm.h
index f1cd22f..966bf0e 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2174,6 +2174,15 @@ extern int apply_to_page_range(struct mm_struct *mm, 
unsigned long address,
   unsigned long size, pte_fn_t fn, void *data);
 
 
+#ifdef CONFIG_PAGE_POISONING
+extern bool page_poisoning_enabled(void);
+extern void kernel_poison_pages(struct page *page, int numpages, int enable);
+#else
+static inline bool page_poisoning_enabled(void) { return false; }
+static inline void kernel_poison_pages(struct page *page, int numpages,
+   int enable) { }
+#endif
+
 #ifdef CONFIG_DEBUG_PAGEALLOC
 extern bool _debug_pagealloc_enabled;
 extern void __kernel_map_pages(struct page *page, int numpages, int enable);
diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug
index 957d3da..25c98ae 100644
--- a/mm/Kconfig.debug
+++ b/mm/Kconfig.debug
@@ -27,4 +27,24 @@ config DEBUG_PAGEALLOC
  a resume because free pages are not saved to the suspend image.
 
 config PAGE_POISONING
-   bool
+   bool "Poison pages after freeing"
+   select PAGE_EXTENSION
+   select PAGE_POISONING_NO_SANITY if HIBERNATION
+   ---help---
+ Fill the pages with poison patterns after free_pages() and verify
+ the patterns before alloc_pages. The filling of the memory helps
+ reduce the risk of information leaks from freed data. This does
+ have a potential performance impact.
+
+ If unsure, say N
+
+config PAGE_POISONING_NO_SANITY
+   depends on PAGE_POISONING
+   bool "Only poison, don't sanity check"
+   ---help---
+  Skip the sanity checking on alloc, only fill the pages with
+  poison on free. This reduces some of the overhead of the
+  poisoning feature.
+
+  If you are only interested in sanitization, say Y. Otherwise
+  say N.
diff --git a/mm/Makefile b/mm/Makefile
index 2ed4319..cfdd481d 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -48,7 +48,7 @@ obj-$(CONFIG_SPARSEMEM_VMEMMAP) += sparse-vmemmap.o
 obj-$(CONFIG_SLOB) += slob.o
 obj-$(CONFIG_MMU_NOTIFIER) += mmu_notifier.o
 obj-$(CONFIG_KSM) += ksm.o
-obj-$(CONFIG_PAGE_POISONING) += debug-pagealloc.o
+obj-$(CONFIG_PAGE_POISONING) += page_poison.o
 obj-$(CONFIG_SLAB) += slab.o
 obj-$(CONFIG_SLUB) += slub.o
 obj-$(CONFIG_KMEMCHECK) += kmemcheck.o
diff --git a/mm/debug-pagealloc.c b/mm/debug-pagealloc.c
deleted file mode 100644
index 5bf5906..000
--- a/mm/debug-pagealloc.c
+++ /dev/null
@@ -1,137 +0,0 @@
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-static bool page_poisoning_enabled __read_mostly;
-
-static bool need_page_poisoning(void)
-{
-   if (!debug_pagealloc_enabled())
-   return false;
-
-   return true;
-}
-
-static void init_page_poisoning(void)
-{
-   if (!debug_pagealloc_enabled())
-   return;
-
-   page_poisoning_enabled = true;
-}
-
-struct page_ext_operations page_poisoning_ops = 

[PATCHv2 2/2] mm/page_poisoning.c: Allow for zero poisoning

[Laura Abbott]

By default, page poisoning uses a poison value (0xaa) on free. If this
is changed to 0, the page is not only sanitized but zeroing on alloc
with __GFP_ZERO can be skipped as well. The tradeoff is that detecting
corruption from the poisoning is harder to detect. This feature also
cannot be used with hibernation since pages are not guaranteed to be
zeroed after hibernation.

Credit to Grsecurity/PaX team for inspiring this work

Signed-off-by: Laura Abbott 
---
 include/linux/mm.h   |  2 ++
 include/linux/poison.h   |  4 
 kernel/power/hibernate.c | 17 +
 mm/Kconfig.debug | 14 ++
 mm/page_alloc.c  | 11 ++-
 mm/page_ext.c| 10 --
 mm/page_poison.c |  7 +--
 7 files changed, 60 insertions(+), 5 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 966bf0e..59ce0dc 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2177,10 +2177,12 @@ extern int apply_to_page_range(struct mm_struct *mm, 
unsigned long address,
 #ifdef CONFIG_PAGE_POISONING
 extern bool page_poisoning_enabled(void);
 extern void kernel_poison_pages(struct page *page, int numpages, int enable);
+extern bool page_is_poisoned(struct page *page);
 #else
 static inline bool page_poisoning_enabled(void) { return false; }
 static inline void kernel_poison_pages(struct page *page, int numpages,
int enable) { }
+static inline bool page_is_poisoned(struct page *page) { return false; }
 #endif
 
 #ifdef CONFIG_DEBUG_PAGEALLOC
diff --git a/include/linux/poison.h b/include/linux/poison.h
index 4a27153..51334ed 100644
--- a/include/linux/poison.h
+++ b/include/linux/poison.h
@@ -30,7 +30,11 @@
 #define TIMER_ENTRY_STATIC ((void *) 0x300 + POISON_POINTER_DELTA)
 
 /** mm/debug-pagealloc.c **/
+#ifdef CONFIG_PAGE_POISONING_ZERO
+#define PAGE_POISON 0x00
+#else
 #define PAGE_POISON 0xaa
+#endif
 
 /** mm/page_alloc.c /
 
diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index b7342a2..aa0f26b 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -1158,6 +1158,22 @@ static int __init kaslr_nohibernate_setup(char *str)
return nohibernate_setup(str);
 }
 
+static int __init page_poison_nohibernate_setup(char *str)
+{
+#ifdef CONFIG_PAGE_POISONING_ZERO
+   /*
+* The zeroing option for page poison skips the checks on alloc.
+* since hibernation doesn't save free pages there's no way to
+* guarantee the pages will still be zeroed.
+*/
+   if (!strcmp(str, "on")) {
+   pr_info("Disabling hibernation due to page poisoning\n");
+   return nohibernate_setup(str);
+   }
+#endif
+   return 1;
+}
+
 __setup("noresume", noresume_setup);
 __setup("resume_offset=", resume_offset_setup);
 __setup("resume=", resume_setup);
@@ -1166,3 +1182,4 @@ __setup("resumewait", resumewait_setup);
 __setup("resumedelay=", resumedelay_setup);
 __setup("nohibernate", nohibernate_setup);
 __setup("kaslr", kaslr_nohibernate_setup);
+__setup("page_poison=", page_poison_nohibernate_setup);
diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug
index 25c98ae..3d3b954 100644
--- a/mm/Kconfig.debug
+++ b/mm/Kconfig.debug
@@ -48,3 +48,17 @@ config PAGE_POISONING_NO_SANITY
 
   If you are only interested in sanitization, say Y. Otherwise
   say N.
+
+config PAGE_POISONING_ZERO
+   bool "Use zero for poisoning instead of random data"
+   depends on PAGE_POISONING
+   ---help---
+  Instead of using the existing poison value, fill the pages with
+  zeros. This makes it harder to detect when errors are occurring
+  due to sanitization but the zeroing at free means that it is
+  no longer necessary to write zeros when GFP_ZERO is used on
+  allocation.
+
+  Enabling page poisoning with this option will disable hibernation
+
+  If unsure, say N
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index cc4762a..59bd9dc 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1382,15 +1382,24 @@ static inline int check_new_page(struct page *page)
return 0;
 }
 
+static inline bool free_pages_prezeroed(bool poisoned)
+{
+   return IS_ENABLED(CONFIG_PAGE_POISONING_ZERO) &&
+   page_poisoning_enabled() && poisoned;
+}
+
 static int prep_new_page(struct page *page, unsigned int order, gfp_t 
gfp_flags,
int alloc_flags)
 {
int i;
+   bool poisoned = true;
 
for (i = 0; i < (1 << order); i++) {
struct page *p = page + i;
if (unlikely(check_new_page(p)))
return 1;
+   if (poisoned)
+   poisoned &= page_is_poisoned(p);
}
 
set_page_private(page, 0);
@@ -1401,7 +1410,7 @@ static int prep_new_page(struct page *page, unsigned int