[PATCH 1/1] I2C: designware: fix IO timeout issue for AMD controller

2015-11-04 Thread Xiangliang Yu
Because of some hardware limitation, AMD I2C controller can't
trigger next interrupt if interrupt status has been changed
after clearing interrupt status bits. Then, I2C will lost
interrupt and IO timeout.

According to hardware design, this patch implements a workaround
to disable i2c controller interrupt after clearing interrupt bits
when entering ISR and to enable i2c interrupt before exiting ISR.

To reduce the performance impacts on other vendors, use unlikely
function to check flag in ISR.

Signed-off-by: Xiangliang Yu 
---
 drivers/i2c/busses/i2c-designware-core.c| 6 ++
 drivers/i2c/busses/i2c-designware-core.h| 1 +
 drivers/i2c/busses/i2c-designware-platdrv.c | 4 
 3 files changed, 11 insertions(+)

diff --git a/drivers/i2c/busses/i2c-designware-core.c 
b/drivers/i2c/busses/i2c-designware-core.c
index 7441cdc..04e7b65 100644
--- a/drivers/i2c/busses/i2c-designware-core.c
+++ b/drivers/i2c/busses/i2c-designware-core.c
@@ -783,6 +783,9 @@ irqreturn_t i2c_dw_isr(int this_irq, void *dev_id)
 
stat = i2c_dw_read_clear_intrbits(dev);
 
+   if (unlikely(dev->accessor_flags & ACCESS_INTR_MASK))
+   i2c_dw_disable_int(dev);
+
if (stat & DW_IC_INTR_TX_ABRT) {
dev->cmd_err |= DW_IC_ERR_TX_ABRT;
dev->status = STATUS_IDLE;
@@ -811,6 +814,9 @@ tx_aborted:
if ((stat & (DW_IC_INTR_TX_ABRT | DW_IC_INTR_STOP_DET)) || dev->msg_err)
complete(>cmd_complete);
 
+   if (unlikely(dev->accessor_flags & ACCESS_INTR_MASK))
+   dw_writel(dev, DW_IC_INTR_DEFAULT_MASK, DW_IC_INTR_MASK);
+
return IRQ_HANDLED;
 }
 EXPORT_SYMBOL_GPL(i2c_dw_isr);
diff --git a/drivers/i2c/busses/i2c-designware-core.h 
b/drivers/i2c/busses/i2c-designware-core.h
index 9630222..808ef6a 100644
--- a/drivers/i2c/busses/i2c-designware-core.h
+++ b/drivers/i2c/busses/i2c-designware-core.h
@@ -111,6 +111,7 @@ struct dw_i2c_dev {
 
 #define ACCESS_SWAP0x0001
 #define ACCESS_16BIT   0x0002
+#define ACCESS_INTR_MASK   0x0004
 
 extern u32 dw_readl(struct dw_i2c_dev *dev, int offset);
 extern void dw_writel(struct dw_i2c_dev *dev, u32 b, int offset);
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c 
b/drivers/i2c/busses/i2c-designware-platdrv.c
index 472b882..0c59357 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -251,6 +251,10 @@ static int dw_i2c_probe(struct platform_device *pdev)
dev->rx_fifo_depth = ((param1 >> 8)  & 0xff) + 1;
dev->adapter.nr = pdev->id;
}
+
+   if (!strncmp(pdev->name, "AMD0010", 7))
+   dev->accessor_flags |= ACCESS_INTR_MASK;
+
r = i2c_dw_init(dev);
if (r)
return r;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] crypto: sun4i-ss: add missing statesize

2015-11-04 Thread LABBE Corentin
sun4i-ss implementaton of md5/sha1 is via ahash algorithms.
A recent change make impossible to load them without giving statesize.
This patch specifiy statesize for sha1 and md5.

Signed-off-by: LABBE Corentin 
Cc: sta...@vger.kernel.org
---
 drivers/crypto/sunxi-ss/sun4i-ss-core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-core.c 
b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
index eab6fe2..107cd2a 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
@@ -39,6 +39,7 @@ static struct sun4i_ss_alg_template ss_algs[] = {
.import = sun4i_hash_import_md5,
.halg = {
.digestsize = MD5_DIGEST_SIZE,
+   .statesize = sizeof(struct md5_state),
.base = {
.cra_name = "md5",
.cra_driver_name = "md5-sun4i-ss",
@@ -66,6 +67,7 @@ static struct sun4i_ss_alg_template ss_algs[] = {
.import = sun4i_hash_import_sha1,
.halg = {
.digestsize = SHA1_DIGEST_SIZE,
+   .statesize = sizeof(struct sha1_state),
.base = {
.cra_name = "sha1",
.cra_driver_name = "sha1-sun4i-ss",
-- 
2.4.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] ARM: at91/dt: sama5d4: change watchdog compatible

2015-11-04 Thread Wenyou Yang
Change the watchdog compatible to "atmel,sama5d4-wdt" to support
SAMA5D4 watchdog driver.

Signed-off-by: Wenyou Yang 
---

 arch/arm/boot/dts/sama5d4.dtsi |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi
index 15bbaf6..2193637 100644
--- a/arch/arm/boot/dts/sama5d4.dtsi
+++ b/arch/arm/boot/dts/sama5d4.dtsi
@@ -1300,7 +1300,7 @@
};
 
watchdog@fc068640 {
-   compatible = "atmel,at91sam9260-wdt";
+   compatible = "atmel,sama5d4-wdt";
reg = <0xfc068640 0x10>;
clocks = <>;
status = "disabled";
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 2/2] arm64: Allow changing of attributes outside of modules

2015-11-04 Thread Ard Biesheuvel
On 3 November 2015 at 22:48, Laura Abbott  wrote:
>
> Currently, the set_memory_* functions that are implemented for arm64
> are restricted to module addresses only. This was mostly done
> because arm64 maps normal zone memory with larger page sizes to
> improve TLB performance. This has the side effect though of making it
> difficult to adjust attributes at the PAGE_SIZE granularity. There are
> an increasing number of use cases related to security where it is
> necessary to change the attributes of kernel memory. Add functionality
> to the page attribute changing code under a Kconfig to let systems
> designers decide if they want to make the trade off of security for TLB
> pressure.
>
> Signed-off-by: Laura Abbott 
> ---
>  arch/arm64/Kconfig.debug | 11 +++
>  arch/arm64/mm/mm.h   |  3 ++
>  arch/arm64/mm/mmu.c  |  2 +-
>  arch/arm64/mm/pageattr.c | 74 
> 
>  4 files changed, 84 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug
> index d6285ef..abc6922 100644
> --- a/arch/arm64/Kconfig.debug
> +++ b/arch/arm64/Kconfig.debug
> @@ -89,6 +89,17 @@ config DEBUG_ALIGN_RODATA
>
>   If in doubt, say N
>
> +config DEBUG_CHANGE_PAGEATTR

I don't think this belongs in Kconfig.debug, and I don't think this
should default to off.

We know we currently have no users of set_memory_xx() in arch/arm64
that operate on linear mapping addresses, so we will not introduce any
performance regressions by adding this functionality now. By putting
this feature behind a debug option, every newly introduced call
set_memory_xx() that operates on linear or vmalloc() addresses needs
to deal with -EINVAL (or depend on DEBUG_CHANGE_PAGEATTR), or it may
error out at runtime if the feature is not enabled.

> +   bool "Allow all kernel memory to have attributes changed"
> +   help
> + If this option is selected, APIs that change page attributes
> + (RW <-> RO, X <-> NX) will be valid for all memory mapped in
> + the kernel space. The trade off is that there may be increased
> + TLB pressure from finer grained page mapping. Turn on this option
> + if performance is more important than security
> +

This is backwards

> + If in doubt, say N
> +
>  source "drivers/hwtracing/coresight/Kconfig"
>
>  endmenu

[...]

> diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
> index e47ed1c..48a4ce9 100644
> --- a/arch/arm64/mm/pageattr.c
> +++ b/arch/arm64/mm/pageattr.c

[...]

> @@ -45,17 +108,18 @@ static int change_memory_common(unsigned long addr, int 
> numpages,
> int ret;
> struct page_change_data data;
>
> +   if (addr < PAGE_OFFSET && !is_vmalloc_addr((void *)addr))
> +   return -EINVAL;
> +

Doesn't this exclude the module area?

> if (!IS_ALIGNED(addr, PAGE_SIZE)) {
> start &= PAGE_MASK;
> end = start + size;
> WARN_ON_ONCE(1);
> }
>
> -   if (start < MODULES_VADDR || start >= MODULES_END)
> -   return -EINVAL;
> -
> -   if (end < MODULES_VADDR || end >= MODULES_END)
> -   return -EINVAL;
> +   ret = check_address(addr);
> +   if (ret)
> +   return ret;
>
> data.set_mask = set_mask;
> data.clear_mask = clear_mask;
> --
> 2.4.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] ARM: at91/dt: sama5d2: add watchdog node

2015-11-04 Thread Wenyou Yang
Add watchdog node to support SAMA5D4 watchdog.

Signed-off-by: Wenyou Yang 
---

 arch/arm/boot/dts/at91-sama5d2_xplained.dts |4 
 arch/arm/boot/dts/sama5d2.dtsi  |7 +++
 2 files changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts 
b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index e07c2b2..de3ef02 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -181,6 +181,10 @@
};
};
 
+   watchdog@f8048040 {
+   status = "okay";
+   };
+
uart3: serial@fc008000 {
pinctrl-names = "default";
pinctrl-0 = <_uart3_default>;
diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index c1f0cba..c29ff70 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -929,6 +929,13 @@
clocks = <>;
};
 
+   watchdog@f8048040 {
+   compatible = "atmel,sama5d4-wdt";
+   reg = <0xf8048040 0x10>;
+   interrupts = <4 IRQ_TYPE_LEVEL_HIGH 7>;
+   status = "disabled";
+   };
+
sckc@f8048050 {
compatible = "atmel,at91sam9x5-sckc";
reg = <0xf8048050 0x4>;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] ARM: at91/sama5_defconfig: enable watchdog driver

2015-11-04 Thread Wenyou Yang
Enabel AT91SAM9X / AT91CAP9 watchdog and SAMA5D4 watchdog.

Signed-off-by: Wenyou Yang 
---

 arch/arm/configs/sama5_defconfig |3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/sama5_defconfig b/arch/arm/configs/sama5_defconfig
index a0c57ac..963daae 100644
--- a/arch/arm/configs/sama5_defconfig
+++ b/arch/arm/configs/sama5_defconfig
@@ -130,6 +130,9 @@ CONFIG_POWER_SUPPLY=y
 CONFIG_POWER_RESET=y
 # CONFIG_HWMON is not set
 CONFIG_SSB=m
+CONFIG_WATCHDOG=y
+CONFIG_AT91SAM9X_WATCHDOG=y
+CONFIG_SAMA5D4_WATCHDOG=y
 CONFIG_MFD_ATMEL_FLEXCOM=y
 CONFIG_REGULATOR=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v7 6/6] ARM: dts: enable smp for rk3036

2015-11-04 Thread Xing Zheng
Enable smp for rk3036, and add the smp sram name for adapting.

---

Changes in v7:
Signed-off-by: Xing Zheng 
Reviewed-by: Heiko Stuebner 

 arch/arm/boot/dts/rk3036.dtsi |5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index 380fe10..61b40dd 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -75,6 +75,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+   enable-method = "rockchip,rk3036-smp";
 
cpu0: cpu@f00 {
device_type = "cpu";
@@ -157,6 +158,10 @@
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x1008 0x2000>;
+   smp-sram@0 {
+   compatible = "rockchip,rk3066-smp-sram";
+   reg = <0x00 0x10>;
+   };
};
 
cru: clock-controller@2000 {
-- 
1.7.9.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v7 5/6] ARM: dts: rockchip: add core rk3036 dts

2015-11-04 Thread Xing Zheng
Initial release for rk3036, node definitions rk3036 sdk board.

Signed-off-by: Xing Zheng 
Reviewed-by: Heiko Stuebner 
---

Changes in v7: None

 arch/arm/boot/dts/Makefile   |1 +
 arch/arm/boot/dts/rk3036-evb.dts |   64 +
 arch/arm/boot/dts/rk3036.dtsi|  547 ++
 3 files changed, 612 insertions(+)
 create mode 100644 arch/arm/boot/dts/rk3036-evb.dts
 create mode 100644 arch/arm/boot/dts/rk3036.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 30bbc37..87c8752 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -512,6 +512,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
 dtb-$(CONFIG_ARCH_REALVIEW) += \
arm-realview-pb1176.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += \
+   rk3036-evb.dtb \
rk3066a-bqcurie2.dtb \
rk3066a-marsboard.dtb \
rk3066a-rayeager.dtb \
diff --git a/arch/arm/boot/dts/rk3036-evb.dts b/arch/arm/boot/dts/rk3036-evb.dts
new file mode 100644
index 000..28a0336
--- /dev/null
+++ b/arch/arm/boot/dts/rk3036-evb.dts
@@ -0,0 +1,64 @@
+/*
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file 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 file 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.
+ *
+ *  Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "rk3036.dtsi"
+
+/ {
+   model = "Rockchip RK3036 Evaluation board";
+   compatible = "rockchip,rk3036-evb", "rockchip,rk3036";
+};
+
+ {
+   status = "okay";
+
+   hym8563: hym8563@51 {
+   compatible = "haoyu,hym8563";
+   reg = <0x51>;
+   #clock-cells = <0>;
+   clock-frequency = <32768>;
+   clock-output-names = "xin32k";
+   };
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
new file mode 100644
index 000..380fe10
--- /dev/null
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -0,0 +1,547 @@
+/*
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file 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 file 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * 

[PATCH v7 4/6] clk: rockchip: add clock controller for rk3036

2015-11-04 Thread Xing Zheng
Add the clock tree definition for the new rk3036 SoC.

Signed-off-by: Xing Zheng 
Reviewed-by: Heiko Stuebner 
---

Changes in v7: None

 drivers/clk/rockchip/Makefile |1 +
 drivers/clk/rockchip/clk-rk3036.c |  478 +
 drivers/clk/rockchip/clk.h|9 +-
 3 files changed, 487 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/rockchip/clk-rk3036.c

diff --git a/drivers/clk/rockchip/Makefile b/drivers/clk/rockchip/Makefile
index b27edd6..d599829 100644
--- a/drivers/clk/rockchip/Makefile
+++ b/drivers/clk/rockchip/Makefile
@@ -10,6 +10,7 @@ obj-y += clk-inverter.o
 obj-y  += clk-mmc-phase.o
 obj-$(CONFIG_RESET_CONTROLLER) += softrst.o
 
+obj-y  += clk-rk3036.o
 obj-y  += clk-rk3188.o
 obj-y  += clk-rk3288.o
 obj-y  += clk-rk3368.o
diff --git a/drivers/clk/rockchip/clk-rk3036.c 
b/drivers/clk/rockchip/clk-rk3036.c
new file mode 100644
index 000..75553af
--- /dev/null
+++ b/drivers/clk/rockchip/clk-rk3036.c
@@ -0,0 +1,478 @@
+/*
+ * Copyright (c) 2014 MundoReader S.L.
+ * Author: Heiko Stuebner 
+ *
+ * Copyright (c) 2015 Rockchip Electronics Co. Ltd.
+ * Author: Xing Zheng 
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "clk.h"
+
+#define RK3036_GRF_SOC_STATUS0 0x14c
+
+enum rk3036_plls {
+   apll, dpll, gpll,
+};
+
+static struct rockchip_pll_rate_table rk3036_pll_rates[] = {
+   /* _mhz, _refdiv, _fbdiv, _postdiv1, _postdiv2, _dsmpd, _frac */
+   RK3036_PLL_RATE(160800, 1, 67, 1, 1, 1, 0),
+   RK3036_PLL_RATE(158400, 1, 66, 1, 1, 1, 0),
+   RK3036_PLL_RATE(156000, 1, 65, 1, 1, 1, 0),
+   RK3036_PLL_RATE(153600, 1, 64, 1, 1, 1, 0),
+   RK3036_PLL_RATE(151200, 1, 63, 1, 1, 1, 0),
+   RK3036_PLL_RATE(148800, 1, 62, 1, 1, 1, 0),
+   RK3036_PLL_RATE(146400, 1, 61, 1, 1, 1, 0),
+   RK3036_PLL_RATE(144000, 1, 60, 1, 1, 1, 0),
+   RK3036_PLL_RATE(141600, 1, 59, 1, 1, 1, 0),
+   RK3036_PLL_RATE(139200, 1, 58, 1, 1, 1, 0),
+   RK3036_PLL_RATE(136800, 1, 57, 1, 1, 1, 0),
+   RK3036_PLL_RATE(134400, 1, 56, 1, 1, 1, 0),
+   RK3036_PLL_RATE(132000, 1, 55, 1, 1, 1, 0),
+   RK3036_PLL_RATE(129600, 1, 54, 1, 1, 1, 0),
+   RK3036_PLL_RATE(127200, 1, 53, 1, 1, 1, 0),
+   RK3036_PLL_RATE(124800, 1, 52, 1, 1, 1, 0),
+   RK3036_PLL_RATE(12, 1, 50, 1, 1, 1, 0),
+   RK3036_PLL_RATE(118800, 2, 99, 1, 1, 1, 0),
+   RK3036_PLL_RATE(110400, 1, 46, 1, 1, 1, 0),
+   RK3036_PLL_RATE(11, 12, 550, 1, 1, 1, 0),
+   RK3036_PLL_RATE(100800, 1, 84, 2, 1, 1, 0),
+   RK3036_PLL_RATE(10, 6, 500, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 98400, 1, 82, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 96000, 1, 80, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 93600, 1, 78, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 91200, 1, 76, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 9, 4, 300, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 88800, 1, 74, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 86400, 1, 72, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 84000, 1, 70, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 81600, 1, 68, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 8, 6, 400, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 7, 6, 350, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 69600, 1, 58, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 6, 1, 75, 3, 1, 1, 0),
+   RK3036_PLL_RATE( 59400, 2, 99, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 50400, 1, 63, 3, 1, 1, 0),
+   RK3036_PLL_RATE( 5, 6, 250, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 40800, 1, 68, 2, 2, 1, 0),
+   RK3036_PLL_RATE( 31200, 1, 52, 2, 2, 1, 0),
+   RK3036_PLL_RATE( 21600, 1, 72, 4, 2, 1, 0),
+   RK3036_PLL_RATE(  9600, 1, 64, 4, 4, 1, 0),
+   { /* sentinel */ },
+};
+
+#define RK3036_DIV_CPU_MASK0x1f
+#define RK3036_DIV_CPU_SHIFT   8
+
+#define RK3036_DIV_PERI_MASK   0xf
+#define RK3036_DIV_PERI_SHIFT  0
+#define RK3036_DIV_ACLK_MASK   0x7
+#define RK3036_DIV_ACLK_SHIFT  4
+#define RK3036_DIV_HCLK_MASK   0x3
+#define RK3036_DIV_HCLK_SHIFT  8
+#define RK3036_DIV_PCLK_MASK   0x7
+#define RK3036_DIV_PCLK_SHIFT  12
+
+#define RK3036_CLKSEL1(_core_periph_div)   
\
+   {   
\
+   .reg = 

[PATCH v7 2/6] clk: rockchip: add dt-binding header for rk3036

2015-11-04 Thread Xing Zheng
Add the dt-bindings header for the rk3036, that gets shared between
the clock controller and the clock references in the dts.


Signed-off-by: Xing Zheng 
Reviewed-by: Heiko Stuebner 
---

Changes in v7: None

 include/dt-bindings/clock/rk3036-cru.h |  193 
 1 file changed, 193 insertions(+)
 create mode 100644 include/dt-bindings/clock/rk3036-cru.h

diff --git a/include/dt-bindings/clock/rk3036-cru.h 
b/include/dt-bindings/clock/rk3036-cru.h
new file mode 100644
index 000..a2763a6
--- /dev/null
+++ b/include/dt-bindings/clock/rk3036-cru.h
@@ -0,0 +1,193 @@
+/*
+ * Copyright (c) 2015 Rockchip Electronics Co. Ltd.
+ * Author: Xing Zheng 
+ *
+ * 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.
+ */
+
+#ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3036_H
+#define _DT_BINDINGS_CLK_ROCKCHIP_RK3036_H
+
+/* core clocks */
+#define PLL_APLL   1
+#define PLL_DPLL   2
+#define PLL_GPLL   3
+#define ARMCLK 4
+
+/* sclk gates (special clocks) */
+#define SCLK_GPU   64
+#define SCLK_SPI   65
+#define SCLK_SDMMC 68
+#define SCLK_SDIO  69
+#define SCLK_EMMC  71
+#define SCLK_NANDC 76
+#define SCLK_UART0 77
+#define SCLK_UART1 78
+#define SCLK_UART2 79
+#define SCLK_I2S   82
+#define SCLK_SPDIF 83
+#define SCLK_TIMER085
+#define SCLK_TIMER186
+#define SCLK_TIMER287
+#define SCLK_TIMER388
+#define SCLK_OTGPHY0   93
+#define SCLK_LCDC  100
+#define SCLK_HDMI  109
+#define SCLK_HEVC  111
+#define SCLK_I2S_OUT   113
+#define SCLK_SDMMC_DRV 114
+#define SCLK_SDIO_DRV  115
+#define SCLK_EMMC_DRV  117
+#define SCLK_SDMMC_SAMPLE  118
+#define SCLK_SDIO_SAMPLE   119
+#define SCLK_EMMC_SAMPLE   121
+#define SCLK_PVTM_CORE  123
+#define SCLK_PVTM_GPU   124
+#define SCLK_PVTM_VIDEO 125
+#define SCLK_MAC   151
+#define SCLK_MACREF152
+#define SCLK_SFC   160
+
+/* aclk gates */
+#define ACLK_DMAC2 194
+#define ACLK_LCDC  197
+#define ACLK_VIO   203
+#define ACLK_VCODEC208
+#define ACLK_CPU   209
+#define ACLK_PERI  210
+
+/* pclk gates */
+#define PCLK_GPIO0 320
+#define PCLK_GPIO1 321
+#define PCLK_GPIO2 322
+#define PCLK_GRF   329
+#define PCLK_I2C0  332
+#define PCLK_I2C1  333
+#define PCLK_I2C2  334
+#define PCLK_SPI   338
+#define PCLK_UART0 341
+#define PCLK_UART1 342
+#define PCLK_UART2 343
+#define PCLK_PWM   350
+#define PCLK_TIMER 353
+#define PCLK_HDMI  360
+#define PCLK_CPU   362
+#define PCLK_PERI  363
+#define PCLK_DDRUPCTL  364
+#define PCLK_WDT   368
+#define PCLK_ACODEC369
+
+/* hclk gates */
+#define HCLK_OTG0  449
+#define HCLK_OTG1  450
+#define HCLK_NANDC 453
+#define HCLK_SDMMC 456
+#define HCLK_SDIO  457
+#define HCLK_EMMC  459
+#define HCLK_I2S   462
+#define HCLK_LCDC  465
+#define HCLK_ROM   467
+#define HCLK_VIO_BUS   472
+#define HCLK_VCODEC476
+#define HCLK_CPU   477
+#define HCLK_PERI  478
+
+#define CLK_NR_CLKS(HCLK_PERI + 1)
+
+/* soft-reset indices */
+#define SRST_CORE0 0
+#define SRST_CORE1 1
+#define SRST_CORE0_DBG 4
+#define SRST_CORE1_DBG 5
+#define SRST_CORE0_POR 8
+#define SRST_CORE1_POR 9
+#define SRST_L2C   12
+#define SRST_TOPDBG13
+#define SRST_STRC_SYS_A14
+#define SRST_PD_CORE_NIU   15
+
+#define SRST_TIMER216
+#define SRST_CPUSYS_H  17
+#define SRST_AHB2APB_H 19
+#define SRST_TIMER320
+#define SRST_INTMEM21
+#define SRST_ROM   22
+#define SRST_PERI_NIU  23
+#define SRST_I2S   24
+#define SRST_DDR_PLL   25
+#define SRST_GPU_DLL   26
+#define SRST_TIMER027
+#define SRST_TIMER128
+#define SRST_CORE_DLL  29
+#define SRST_EFUSE_P   30
+#define SRST_ACODEC_P

[PATCH v7 3/6] clk: rockchip: add new pll-type for rk3036 and similar socs

2015-11-04 Thread Xing Zheng
The rk3036's pll and clock are different with base on the rk3066(rk3188,
rk3288, rk3368 use it), there are different adjust foctors and control
registers, so these should be independent and separate from the series
of rk3066s.

Signed-off-by: Xing Zheng 
Reviewed-by: Heiko Stuebner 
---

Changes in v7: None

 drivers/clk/rockchip/clk-pll.c |  249 +++-
 drivers/clk/rockchip/clk.h |   23 
 2 files changed, 271 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/rockchip/clk-pll.c b/drivers/clk/rockchip/clk-pll.c
index 4881eb8..83ba1e9 100644
--- a/drivers/clk/rockchip/clk-pll.c
+++ b/drivers/clk/rockchip/clk-pll.c
@@ -2,6 +2,9 @@
  * Copyright (c) 2014 MundoReader S.L.
  * Author: Heiko Stuebner 
  *
+ * Copyright (c) 2015 Rockchip Electronics Co. Ltd.
+ * Author: Xing Zheng 
+ *
  * 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
@@ -19,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "clk.h"
 
 #define PLL_MODE_MASK  0x3
@@ -108,6 +112,243 @@ static int rockchip_pll_wait_lock(struct rockchip_clk_pll 
*pll)
 }
 
 /**
+ * PLL used in RK3036
+ */
+
+#define RK3036_PLLCON(i)   (i * 0x4)
+#define RK3036_PLLCON0_FBDIV_MASK  0xfff
+#define RK3036_PLLCON0_FBDIV_SHIFT 0
+#define RK3036_PLLCON0_POSTDIV1_MASK   0x7
+#define RK3036_PLLCON0_POSTDIV1_SHIFT  12
+#define RK3036_PLLCON1_REFDIV_MASK 0x3f
+#define RK3036_PLLCON1_REFDIV_SHIFT0
+#define RK3036_PLLCON1_POSTDIV2_MASK   0x7
+#define RK3036_PLLCON1_POSTDIV2_SHIFT  6
+#define RK3036_PLLCON1_DSMPD_MASK  0x1
+#define RK3036_PLLCON1_DSMPD_SHIFT 12
+#define RK3036_PLLCON2_FRAC_MASK   0xff
+#define RK3036_PLLCON2_FRAC_SHIFT  0
+
+#define RK3036_PLLCON1_PWRDOWN (1 << 13)
+
+static void rockchip_rk3036_pll_get_params(struct rockchip_clk_pll *pll,
+   struct rockchip_pll_rate_table *rate)
+{
+   u32 pllcon;
+
+   pllcon = readl_relaxed(pll->reg_base + RK3036_PLLCON(0));
+   rate->fbdiv = ((pllcon >> RK3036_PLLCON0_FBDIV_SHIFT) & 
RK3036_PLLCON0_FBDIV_MASK);
+   rate->postdiv1 = ((pllcon >> RK3036_PLLCON0_POSTDIV1_SHIFT) & 
RK3036_PLLCON0_POSTDIV1_MASK);
+
+   pllcon = readl_relaxed(pll->reg_base + RK3036_PLLCON(1));
+   rate->refdiv = ((pllcon >> RK3036_PLLCON1_REFDIV_SHIFT) & 
RK3036_PLLCON1_REFDIV_MASK);
+   rate->postdiv2 = ((pllcon >> RK3036_PLLCON1_POSTDIV2_SHIFT) & 
RK3036_PLLCON1_POSTDIV2_MASK);
+   rate->dsmpd = ((pllcon >> RK3036_PLLCON1_DSMPD_SHIFT) & 
RK3036_PLLCON1_DSMPD_MASK);
+
+   pllcon = readl_relaxed(pll->reg_base + RK3036_PLLCON(2));
+   rate->frac = ((pllcon >> RK3036_PLLCON2_FRAC_SHIFT) & 
RK3036_PLLCON2_FRAC_MASK);
+}
+
+static unsigned long rockchip_rk3036_pll_recalc_rate(struct clk_hw *hw,
+unsigned long prate)
+{
+   struct rockchip_clk_pll *pll = to_rockchip_clk_pll(hw);
+   struct rockchip_pll_rate_table cur;
+   u64 rate64 = prate;
+
+   rockchip_rk3036_pll_get_params(pll, );
+
+   rate64 *= cur.fbdiv;
+   do_div(rate64, cur.refdiv);
+
+   if (cur.dsmpd == 0) {
+   /* fractional mode */
+   u64 frac_rate64 = prate * cur.frac;
+
+   do_div(frac_rate64, cur.refdiv);
+   rate64 += frac_rate64 >> 24;
+   }
+
+   do_div(rate64, cur.postdiv1);
+   do_div(rate64, cur.postdiv2);
+
+   return (unsigned long)rate64;
+}
+
+static int rockchip_rk3036_pll_set_params(struct rockchip_clk_pll *pll,
+   const struct rockchip_pll_rate_table *rate)
+{
+   const struct clk_ops *pll_mux_ops = pll->pll_mux_ops;
+   struct clk_mux *pll_mux = >pll_mux;
+   struct rockchip_pll_rate_table cur;
+   u32 pllcon;
+   int rate_change_remuxed = 0;
+   int cur_parent;
+   int ret;
+
+   pr_debug("%s: rate settings for %lu fbdiv: %d, postdiv1: %d, refdiv: 
%d, postdiv2: %d, dsmpd: %d, frac: %d\n",
+   __func__, rate->rate, rate->fbdiv, rate->postdiv1, rate->refdiv,
+   rate->postdiv2, rate->dsmpd, rate->frac);
+
+   rockchip_rk3036_pll_get_params(pll, );
+   cur.rate = 0;
+
+   cur_parent = pll_mux_ops->get_parent(_mux->hw);
+   if (cur_parent == PLL_MODE_NORM) {
+   pll_mux_ops->set_parent(_mux->hw, PLL_MODE_SLOW);
+   rate_change_remuxed = 1;
+   }
+
+   /* update pll values */
+   writel_relaxed(HIWORD_UPDATE(rate->fbdiv, RK3036_PLLCON0_FBDIV_MASK,
+ RK3036_PLLCON0_FBDIV_SHIFT) |
+  HIWORD_UPDATE(rate->postdiv1, 
RK3036_PLLCON0_POSTDIV1_MASK,
+ 

[PATCH v7 1/6] dt-bindings: add documentation of rk3036 clock controller

2015-11-04 Thread Xing Zheng
Add the devicetree binding for the cru on the rk3036 which quite similar
structured as previous clock controllers.


Signed-off-by: Xing Zheng 
Reviewed-by: Heiko Stuebner 
Acked-by: Rob Herring 
---

Changes in v7: None

 .../bindings/clock/rockchip,rk3036-cru.txt |   56 
 1 file changed, 56 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt

diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt 
b/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
new file mode 100644
index 000..ace0599
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
@@ -0,0 +1,56 @@
+* Rockchip RK3036 Clock and Reset Unit
+
+The RK3036 clock controller generates and supplies clock to various
+controllers within the SoC and also implements a reset controller for SoC
+peripherals.
+
+Required Properties:
+
+- compatible: should be "rockchip,rk3036-cru"
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- #clock-cells: should be 1.
+- #reset-cells: should be 1.
+
+Optional Properties:
+
+- rockchip,grf: phandle to the syscon managing the "general register files"
+  If missing pll rates are not changeable, due to the missing pll lock status.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. All available clocks are defined as
+preprocessor macros in the dt-bindings/clock/rk3036-cru.h headers and can be
+used in device tree sources. Similar macros exist for the reset sources in
+these files.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It is expected
+that they are defined using standard clock bindings with following
+clock-output-names:
+ - "xin24m" - crystal input - required,
+ - "ext_i2s" - external I2S clock - optional,
+ - "ext_gmac" - external GMAC clock - optional
+
+Example: Clock controller node:
+
+   cru: cru@2000 {
+   compatible = "rockchip,rk3036-cru";
+   reg = <0x2000 0x1000>;
+   rockchip,grf = <>;
+
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   };
+
+Example: UART controller node that consumes the clock generated by the clock
+  controller:
+
+   uart0: serial@2006 {
+   compatible = "snps,dw-apb-uart";
+   reg = <0x2006 0x100>;
+   interrupts = ;
+   reg-shift = <2>;
+   reg-io-width = <4>;
+   clocks = < SCLK_UART0>;
+   };
-- 
1.7.9.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v7 0/6] Build and support rk3036 SoC platform

2015-11-04 Thread Xing Zheng

Hi,
  We need to support rk3036 soc platform via upstream, there are
some primary parts for the initial release of minimum system: dts,
clk-pll, smp, and clock tree for rk3036, and additional, we can use
these startup and run to init processs.

Thanks.

Changed in v7:
- removed the patch "make sure timer5 is enabled on rk3036 platforms" (applied)
- removed the patch "add support smp for rk3036" (applied)

Changed in v6:
- add hardware timer in dtsi and some the aliases of basic modules

Changed in v5:
- don't use clk_ APIs in the pll init-callback

Changed in v4:
- add some basic IP modules on rk3036.dtsi
- optimized supporting smp codes

Changed in v3:
- optimized some codes based on v2
- removed the patch "initial set time for rtc-hym8563" (useless)
- removed the patch "pinctrl" (approved)

Changed in v2:
- based on v1, add clock controller documentation
- enable timer5 startup
- add smp for cpu1
- initial set time for rtc-hym8563

Changes in v1:
- add dts, pinctrl and clock tree for rk3036 soc platform

The patchset (6):
6) ARM: dts: enable smp for rk3036
5) ARM: dts: rockchip: add core rk3036 dts
4) clk: rockchip: add clock controller for rk3036
3) clk: rockchip: add new pll-type for rk3036 and similar socs
2) clk: rockchip: add dt-binding header for rk3036
1) dt-bindings: add documentation of rk3036 clock controller


Changes in v7:
Signed-off-by: Xing Zheng 
Reviewed-by: Heiko Stuebner 

Xing Zheng (6):
  dt-bindings: add documentation of rk3036 clock controller
  clk: rockchip: add dt-binding header for rk3036
  clk: rockchip: add new pll-type for rk3036 and similar socs
  clk: rockchip: add clock controller for rk3036
  ARM: dts: rockchip: add core rk3036 dts
  ARM: dts: enable smp for rk3036

 .../bindings/clock/rockchip,rk3036-cru.txt |   56 ++
 arch/arm/boot/dts/Makefile |1 +
 arch/arm/boot/dts/rk3036-evb.dts   |   64 +++
 arch/arm/boot/dts/rk3036.dtsi  |  552 
 drivers/clk/rockchip/Makefile  |1 +
 drivers/clk/rockchip/clk-pll.c |  249 -
 drivers/clk/rockchip/clk-rk3036.c  |  478 +
 drivers/clk/rockchip/clk.h |   32 +-
 include/dt-bindings/clock/rk3036-cru.h |  193 +++
 9 files changed, 1624 insertions(+), 2 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
 create mode 100644 arch/arm/boot/dts/rk3036-evb.dts
 create mode 100644 arch/arm/boot/dts/rk3036.dtsi
 create mode 100644 drivers/clk/rockchip/clk-rk3036.c
 create mode 100644 include/dt-bindings/clock/rk3036-cru.h

-- 
1.7.9.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 0/4] dm verity: add support for error correction

2015-11-04 Thread Milan Broz
On 11/05/2015 03:02 AM, Sami Tolvanen wrote:
> This patch set adds error correction support to dm-verity, which
> makes it possible to recover from data corruption in exchange of
> increased space overhead.
> 
> The feature is implemented as part of dm-verity to take advantage
> of the existing hash tree to improve performance and locate known
> erasures.

Hi,

could you please elaborate why is all this needed? To extend support
of some faulty flash chips?

Do you have some statistics that there are really such correctable errors
in real devices?

Anyway, I really do not understand layer separation here. Either we have
cryptographically strong data integrity checking or we have
error-correction. Are we sure this combination does not create some unintended
gap in integrity checking? Why the integrity check should even try to do some
error correction if there is an intentional integrity attack?

IMO if you need an error correction, this should be placed as a separate
layer below the crypto integrity check, the same as RAID operates.

The second question - why are you writing another separate tool
for maintenance for dm-verity when there is veritysetup?

Milan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH TRIVIAL] README: cosmetic fixes

2015-11-04 Thread Diego Viola
Signed-off-by: Diego Viola 
---
 README | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/README b/README
index a326a6a..e1df543 100644
--- a/README
+++ b/README
@@ -59,7 +59,7 @@ DOCUMENTATION:
 INSTALLING the kernel source:
 
  - If you install the full sources, put the kernel tarball in a
-   directory where you have permissions (eg. your home directory) and
+   directory where you have permissions (e.g. your home directory) and
unpack it:
 
  xz -cd linux-4.X.tar.xz | tar xvf -
@@ -125,7 +125,7 @@ BUILD directory for the kernel:
 
When compiling the kernel, all output files will per default be
stored together with the kernel source code.
-   Using the option "make O=output/dir" allow you to specify an alternate
+   Using the option "make O=output/dir" allows you to specify an alternate
place for the output files (including .config).
Example:
 
@@ -159,9 +159,9 @@ CONFIGURING the kernel:
 
  "make nconfig" Enhanced text based color menus.
 
- "make xconfig" X windows (Qt) based configuration tool.
+ "make xconfig" Qt based configuration tool.
 
- "make gconfig" X windows (GTK+) based configuration tool.
+ "make gconfig" GTK+ based configuration tool.
 
  "make oldconfig"   Default all questions based on the contents of
 your existing ./.config file and asking about
@@ -268,8 +268,8 @@ COMPILING the kernel:
Normally, the kernel build system runs in a fairly quiet mode (but not
totally silent).  However, sometimes you or other kernel developers need
to see compile, link, or other commands exactly as they are executed.
-   For this, use "verbose" build mode.  This is done by inserting
-   "V=1" in the "make" command.  E.g.:
+   For this, use "verbose" build mode.  This is done by passing
+   "V=1" to the "make" command, e.g.
 
  make V=1 all
 
@@ -300,7 +300,7 @@ COMPILING the kernel:
kernel image file is usually /vmlinuz, /boot/vmlinuz, /bzImage or
/boot/bzImage.  To use the new kernel, save a copy of the old image
and copy the new image over the old one.  Then, you MUST RERUN LILO
-   to update the loading map!! If you don't, you won't be able to boot
+   to update the loading map! If you don't, you won't be able to boot
the new kernel image.
 
Reinstalling LILO is usually a matter of running /sbin/lilo. 
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v2 02/10] tty: xuartps: Use spinlock to serialize HW access

2015-11-04 Thread Soren Brinkmann
Instead of disabling the IRQ, use the spin lock to serialize accesses to
the HW. This protects the driver from interference of non-IRQ callbacks
with each other and makes the driver more consistent in its
serialization method.

Signed-off-by: Soren Brinkmann 
---
v2:
 - remove unused variable
---
 drivers/tty/serial/xilinx_uartps.c | 18 ++
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/tty/serial/xilinx_uartps.c 
b/drivers/tty/serial/xilinx_uartps.c
index 50d4082d2354..2c98c357d9a0 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -945,12 +945,10 @@ static void cdns_uart_set_mctrl(struct uart_port *port, 
unsigned int mctrl)
 #ifdef CONFIG_CONSOLE_POLL
 static int cdns_uart_poll_get_char(struct uart_port *port)
 {
-   u32 imr;
int c;
+   unsigned long flags;
 
-   /* Disable all interrupts */
-   imr = readl(port->membase + CDNS_UART_IMR_OFFSET);
-   writel(imr, port->membase + CDNS_UART_IDR_OFFSET);
+   spin_lock_irqsave(>lock, flags);
 
/* Check if FIFO is empty */
if (readl(port->membase + CDNS_UART_SR_OFFSET) & CDNS_UART_SR_RXEMPTY)
@@ -959,19 +957,16 @@ static int cdns_uart_poll_get_char(struct uart_port *port)
c = (unsigned char) readl(
port->membase + CDNS_UART_FIFO_OFFSET);
 
-   /* Enable interrupts */
-   writel(imr, port->membase + CDNS_UART_IER_OFFSET);
+   spin_unlock_irqrestore(>lock, flags);
 
return c;
 }
 
 static void cdns_uart_poll_put_char(struct uart_port *port, unsigned char c)
 {
-   u32 imr;
+   unsigned long flags;
 
-   /* Disable all interrupts */
-   imr = readl(port->membase + CDNS_UART_IMR_OFFSET);
-   writel(imr, port->membase + CDNS_UART_IDR_OFFSET);
+   spin_lock_irqsave(>lock, flags);
 
/* Wait until FIFO is empty */
while (!(readl(port->membase + CDNS_UART_SR_OFFSET) &
@@ -986,8 +981,7 @@ static void cdns_uart_poll_put_char(struct uart_port *port, 
unsigned char c)
CDNS_UART_SR_TXEMPTY))
cpu_relax();
 
-   /* Enable interrupts */
-   writel(imr, port->membase + CDNS_UART_IER_OFFSET);
+   spin_unlock_irqrestore(>lock, flags);
 
return;
 }
-- 
2.6.2.3.ga463a5b

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v2 09/10] tty: xuartps: Only handle RX IRQs when RX is enabled

2015-11-04 Thread Soren Brinkmann
Ignore RX-related interrupts if RX is not enabled.

Signed-off-by: Soren Brinkmann 
---
 drivers/tty/serial/xilinx_uartps.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/xilinx_uartps.c 
b/drivers/tty/serial/xilinx_uartps.c
index aa1176e6661a..413229661f5d 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -161,6 +161,7 @@ MODULE_PARM_DESC(rx_timeout, "Rx timeout, 1-255");
  * @pclk:  APB clock
  * @baud:  Current baud rate
  * @clk_rate_change_nb:Notifier block for clock changes
+ * @flags: Driver flags
  */
 struct cdns_uart {
struct uart_port*port;
@@ -168,7 +169,11 @@ struct cdns_uart {
struct clk  *pclk;
unsigned intbaud;
struct notifier_block   clk_rate_change_nb;
+   u32 flags;
 };
+
+#define CDNS_FLAG_RX_ENABLED   BIT(0)
+
 #define to_cdns_uart(_nb) container_of(_nb, struct cdns_uart, \
clk_rate_change_nb);
 
@@ -262,6 +267,7 @@ static void cdns_uart_handle_rx(struct uart_port *port, 
unsigned int isrstatus)
 static irqreturn_t cdns_uart_isr(int irq, void *dev_id)
 {
struct uart_port *port = (struct uart_port *)dev_id;
+   struct cdns_uart *cdns_uart = port->private_data;
unsigned long flags;
unsigned int isrstatus, numbytes;
 
@@ -272,7 +278,8 @@ static irqreturn_t cdns_uart_isr(int irq, void *dev_id)
 */
isrstatus = readl(port->membase + CDNS_UART_ISR_OFFSET);
 
-   cdns_uart_handle_rx(port, isrstatus);
+   if (cdns_uart->flags & CDNS_FLAG_RX_ENABLED)
+   cdns_uart_handle_rx(port, isrstatus);
 
/* Dispatch an appropriate handler */
if ((isrstatus & CDNS_UART_IXR_TXEMPTY) == CDNS_UART_IXR_TXEMPTY) {
@@ -576,11 +583,13 @@ static void cdns_uart_stop_tx(struct uart_port *port)
 static void cdns_uart_stop_rx(struct uart_port *port)
 {
unsigned int regval;
+   struct cdns_uart *cdns_uart = port->private_data;
 
regval = readl(port->membase + CDNS_UART_CR_OFFSET);
regval |= CDNS_UART_CR_RX_DIS;
/* Disable the receiver */
writel(regval, port->membase + CDNS_UART_CR_OFFSET);
+   cdns_uart->flags &= ~CDNS_FLAG_RX_ENABLED;
 }
 
 /**
@@ -761,6 +770,7 @@ static int cdns_uart_startup(struct uart_port *port)
 {
unsigned long flags;
unsigned int retval = 0, status = 0;
+   struct cdns_uart *cdns_uart = port->private_data;
 
retval = request_irq(port->irq, cdns_uart_isr, 0, CDNS_UART_NAME,
(void *)port);
@@ -787,6 +797,7 @@ static int cdns_uart_startup(struct uart_port *port)
status &= CDNS_UART_CR_RX_DIS;
status |= CDNS_UART_CR_RX_EN;
writel(status, port->membase + CDNS_UART_CR_OFFSET);
+   cdns_uart->flags |= CDNS_FLAG_RX_ENABLED;
 
/* Set the Mode Register with normal mode,8 data bits,1 stop bit,
 * no parity.
@@ -830,6 +841,7 @@ static void cdns_uart_shutdown(struct uart_port *port)
 {
int status;
unsigned long flags;
+   struct cdns_uart *cdns_uart = port->private_data;
 
spin_lock_irqsave(>lock, flags);
 
@@ -841,6 +853,7 @@ static void cdns_uart_shutdown(struct uart_port *port)
/* Disable the TX and RX */
writel(CDNS_UART_CR_TX_DIS | CDNS_UART_CR_RX_DIS,
port->membase + CDNS_UART_CR_OFFSET);
+   cdns_uart->flags &= ~CDNS_FLAG_RX_ENABLED;
 
spin_unlock_irqrestore(>lock, flags);
 
-- 
2.6.2.3.ga463a5b

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v2 01/10] tty: xuartps: Beautify read-modify writes

2015-11-04 Thread Soren Brinkmann
Non-functional, formatting changes to ease reading the code.

Signed-off-by: Soren Brinkmann 
---
 drivers/tty/serial/xilinx_uartps.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/tty/serial/xilinx_uartps.c 
b/drivers/tty/serial/xilinx_uartps.c
index 009e0dbc12d2..50d4082d2354 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -515,12 +515,14 @@ static void cdns_uart_start_tx(struct uart_port *port)
if (uart_circ_empty(>state->xmit) || uart_tx_stopped(port))
return;
 
-   status = readl(port->membase + CDNS_UART_CR_OFFSET);
-   /* Set the TX enable bit and clear the TX disable bit to enable the
+   /*
+* Set the TX enable bit and clear the TX disable bit to enable the
 * transmitter.
 */
-   writel((status & ~CDNS_UART_CR_TX_DIS) | CDNS_UART_CR_TX_EN,
-   port->membase + CDNS_UART_CR_OFFSET);
+   status = readl(port->membase + CDNS_UART_CR_OFFSET);
+   status &= ~CDNS_UART_CR_TX_DIS;
+   status |= CDNS_UART_CR_TX_EN;
+   writel(status, port->membase + CDNS_UART_CR_OFFSET);
 
while (numbytes-- && ((readl(port->membase + CDNS_UART_SR_OFFSET) &
CDNS_UART_SR_TXFULL)) != CDNS_UART_SR_TXFULL) {
@@ -1123,8 +1125,9 @@ static void cdns_uart_console_write(struct console *co, 
const char *s,
 * clear the TX disable bit to enable the transmitter.
 */
ctrl = readl(port->membase + CDNS_UART_CR_OFFSET);
-   writel((ctrl & ~CDNS_UART_CR_TX_DIS) | CDNS_UART_CR_TX_EN,
-   port->membase + CDNS_UART_CR_OFFSET);
+   ctrl &= ~CDNS_UART_CR_TX_DIS;
+   ctrl |= CDNS_UART_CR_TX_EN;
+   writel(ctrl, port->membase + CDNS_UART_CR_OFFSET);
 
uart_console_write(port, s, count, cdns_uart_console_putchar);
cdns_uart_console_wait_tx(port);
-- 
2.6.2.3.ga463a5b

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v2 03/10] tty: xuartps: Always enable transmitter in start_tx

2015-11-04 Thread Soren Brinkmann
start_tx must start transmitting characters. Regardless of the state of
the circular buffer, always enable the transmitter hardware.

Signed-off-by: Soren Brinkmann 
---
 drivers/tty/serial/xilinx_uartps.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/serial/xilinx_uartps.c 
b/drivers/tty/serial/xilinx_uartps.c
index 2c98c357d9a0..df6778d17949 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -512,9 +512,6 @@ static void cdns_uart_start_tx(struct uart_port *port)
 {
unsigned int status, numbytes = port->fifosize;
 
-   if (uart_circ_empty(>state->xmit) || uart_tx_stopped(port))
-   return;
-
/*
 * Set the TX enable bit and clear the TX disable bit to enable the
 * transmitter.
@@ -524,6 +521,9 @@ static void cdns_uart_start_tx(struct uart_port *port)
status |= CDNS_UART_CR_TX_EN;
writel(status, port->membase + CDNS_UART_CR_OFFSET);
 
+   if (uart_circ_empty(>state->xmit) || uart_tx_stopped(port))
+   return;
+
while (numbytes-- && ((readl(port->membase + CDNS_UART_SR_OFFSET) &
CDNS_UART_SR_TXFULL)) != CDNS_UART_SR_TXFULL) {
/* Break if no more data available in the UART buffer */
-- 
2.6.2.3.ga463a5b

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v2 07/10] tty: xuartps: Acquire port lock for shutdown

2015-11-04 Thread Soren Brinkmann
Shutting down the UART port can happen while console operations are in
progress. Holding the port lock serializes these operations and avoids
the UART HW to be disabled in the middle of console prints.

Signed-off-by: Soren Brinkmann 
---
 drivers/tty/serial/xilinx_uartps.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/tty/serial/xilinx_uartps.c 
b/drivers/tty/serial/xilinx_uartps.c
index 5efd1b9d220f..7fd226d65496 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -823,6 +823,9 @@ static int cdns_uart_startup(struct uart_port *port)
 static void cdns_uart_shutdown(struct uart_port *port)
 {
int status;
+   unsigned long flags;
+
+   spin_lock_irqsave(>lock, flags);
 
/* Disable interrupts */
status = readl(port->membase + CDNS_UART_IMR_OFFSET);
@@ -832,6 +835,9 @@ static void cdns_uart_shutdown(struct uart_port *port)
/* Disable the TX and RX */
writel(CDNS_UART_CR_TX_DIS | CDNS_UART_CR_RX_DIS,
port->membase + CDNS_UART_CR_OFFSET);
+
+   spin_unlock_irqrestore(>lock, flags);
+
free_irq(port->irq, port);
 }
 
-- 
2.6.2.3.ga463a5b

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v2 04/10] tty: xuartps: Clear interrupt status register in shutdown

2015-11-04 Thread Soren Brinkmann
When shutting down the UART, clear the interrupt status register.

Signed-off-by: Soren Brinkmann 
---
 drivers/tty/serial/xilinx_uartps.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/tty/serial/xilinx_uartps.c 
b/drivers/tty/serial/xilinx_uartps.c
index df6778d17949..b7fc30639292 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -825,6 +825,7 @@ static void cdns_uart_shutdown(struct uart_port *port)
/* Disable interrupts */
status = readl(port->membase + CDNS_UART_IMR_OFFSET);
writel(status, port->membase + CDNS_UART_IDR_OFFSET);
+   writel(0x, port->membase + CDNS_UART_ISR_OFFSET);
 
/* Disable the TX and RX */
writel(CDNS_UART_CR_TX_DIS | CDNS_UART_CR_RX_DIS,
-- 
2.6.2.3.ga463a5b

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v2 00/10] tty: xuartps: Fix lock ups

2015-11-04 Thread Soren Brinkmann
Hi,

this is v2, hopefully without any build issues. The changes are the same
as before, just the warning reported by kbuild test robot about unused
variables have been fixed. And, I added one more patch with some
cleanup/refactoring.

I recently found my system locking up under some conditions. I dug
through the code a bit and the result is this collections of various
changes. Some of it may not be required and has just been created out of
half-baked theories and re-reading the documentation. The actual failing
scenarios seem to be:
 - RX IRQ conditions are handled while the receiver is disabled, leaving
   the driver in an infinite loop
 - console_put_char seems to be interrupted by uart_shutdown disabling
   the transmitter while/just before printing

I.e. overall I tried to serialize all operations using the port lock to
avoid such interaction.

Sören

Sören Brinkmann (10):
  tty: xuartps: Beautify read-modify writes
  tty: xuartps: Use spinlock to serialize HW access
  tty: xuartps: Always enable transmitter in start_tx
  tty: xuartps: Clear interrupt status register in shutdown
  tty: xuartps: Improve startup function
  tty: xuartps: Keep lock for whole ISR
  tty: xuartps: Acquire port lock for shutdown
  tty: xuartps: Move RX path into helper function
  tty: xuartps: Only handle RX IRQs when RX is enabled
  tty: xuartps: Cleanup: Reformat if-else

 drivers/tty/serial/xilinx_uartps.c | 247 -
 1 file changed, 136 insertions(+), 111 deletions(-)

-- 
2.6.2.3.ga463a5b

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v2 06/10] tty: xuartps: Keep lock for whole ISR

2015-11-04 Thread Soren Brinkmann
The RX path in the interrupt handler released a lock unnecessarily.

Signed-off-by: Soren Brinkmann 
---
 drivers/tty/serial/xilinx_uartps.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/tty/serial/xilinx_uartps.c 
b/drivers/tty/serial/xilinx_uartps.c
index 167e0f4bcf7a..5efd1b9d220f 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -265,9 +265,7 @@ static irqreturn_t cdns_uart_isr(int irq, void *dev_id)
uart_insert_char(port, isrstatus, CDNS_UART_IXR_OVERRUN,
data, status);
}
-   spin_unlock(>lock);
tty_flip_buffer_push(>state->port);
-   spin_lock(>lock);
}
 
/* Dispatch an appropriate handler */
-- 
2.6.2.3.ga463a5b

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v2 10/10] tty: xuartps: Cleanup: Reformat if-else

2015-11-04 Thread Soren Brinkmann
Convert an if-else into the more common early return on error, reducing
the indent level of the happy path.

Signed-off-by: Soren Brinkmann 
---
v2:
 - added this patch
---
 drivers/tty/serial/xilinx_uartps.c | 124 ++---
 1 file changed, 62 insertions(+), 62 deletions(-)

diff --git a/drivers/tty/serial/xilinx_uartps.c 
b/drivers/tty/serial/xilinx_uartps.c
index 413229661f5d..aed8a31f3399 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -203,58 +203,55 @@ static void cdns_uart_handle_rx(struct uart_port *port, 
unsigned int isrstatus)
isrstatus &= port->read_status_mask;
isrstatus &= ~port->ignore_status_mask;
 
-   if ((isrstatus & CDNS_UART_IXR_TOUT) ||
-   (isrstatus & CDNS_UART_IXR_RXTRIG)) {
-   /* Receive Timeout Interrupt */
-   while (!(readl(port->membase + CDNS_UART_SR_OFFSET) &
-   CDNS_UART_SR_RXEMPTY)) {
-   u32 data;
-   char status = TTY_NORMAL;
-
-   data = readl(port->membase + CDNS_UART_FIFO_OFFSET);
-
-   /* Non-NULL byte after BREAK is garbage (99%) */
-   if (data && (port->read_status_mask &
-   CDNS_UART_IXR_BRK)) {
-   port->read_status_mask &= ~CDNS_UART_IXR_BRK;
-   port->icount.brk++;
-   if (uart_handle_break(port))
-   continue;
-   }
+   if (!(isrstatus & (CDNS_UART_IXR_TOUT | CDNS_UART_IXR_RXTRIG)))
+   return;
+
+   while (!(readl(port->membase + CDNS_UART_SR_OFFSET) &
+   CDNS_UART_SR_RXEMPTY)) {
+   u32 data;
+   char status = TTY_NORMAL;
+
+   data = readl(port->membase + CDNS_UART_FIFO_OFFSET);
+
+   /* Non-NULL byte after BREAK is garbage (99%) */
+   if (data && (port->read_status_mask & CDNS_UART_IXR_BRK)) {
+   port->read_status_mask &= ~CDNS_UART_IXR_BRK;
+   port->icount.brk++;
+   if (uart_handle_break(port))
+   continue;
+   }
 
 #ifdef SUPPORT_SYSRQ
-   /*
-* uart_handle_sysrq_char() doesn't work if
-* spinlocked, for some reason
-*/
-if (port->sysrq) {
-   spin_unlock(>lock);
-   if (uart_handle_sysrq_char(port,
-   (unsigned char)data)) {
-   spin_lock(>lock);
-   continue;
-   }
+   /*
+* uart_handle_sysrq_char() doesn't work if
+* spinlocked, for some reason
+*/
+if (port->sysrq) {
+   spin_unlock(>lock);
+   if (uart_handle_sysrq_char(port, data)) {
spin_lock(>lock);
+   continue;
}
+   spin_lock(>lock);
+   }
 #endif
 
-   port->icount.rx++;
-
-   if (isrstatus & CDNS_UART_IXR_PARITY) {
-   port->icount.parity++;
-   status = TTY_PARITY;
-   } else if (isrstatus & CDNS_UART_IXR_FRAMING) {
-   port->icount.frame++;
-   status = TTY_FRAME;
-   } else if (isrstatus & CDNS_UART_IXR_OVERRUN) {
-   port->icount.overrun++;
-   }
+   port->icount.rx++;
 
-   uart_insert_char(port, isrstatus, CDNS_UART_IXR_OVERRUN,
-data, status);
+   if (isrstatus & CDNS_UART_IXR_PARITY) {
+   port->icount.parity++;
+   status = TTY_PARITY;
+   } else if (isrstatus & CDNS_UART_IXR_FRAMING) {
+   port->icount.frame++;
+   status = TTY_FRAME;
+   } else if (isrstatus & CDNS_UART_IXR_OVERRUN) {
+   port->icount.overrun++;
}
-   tty_flip_buffer_push(>state->port);
+
+   uart_insert_char(port, isrstatus, CDNS_UART_IXR_OVERRUN,
+data, status);
}
+   tty_flip_buffer_push(>state->port);
 }
 
 /**
@@ -1431,27 +1428,30 @@ static int cdns_uart_probe(struct platform_device *pdev)
dev_err(>dev, "Cannot get uart_port structure\n");
rc = -ENODEV;
   

[PATCH v2 05/10] tty: xuartps: Improve startup function

2015-11-04 Thread Soren Brinkmann
The startup function is supposed to initialize the UART for receiving.
Hence, don't enable the TX part. Also, protect HW accesses with the port
lock.

Signed-off-by: Soren Brinkmann 
---
 drivers/tty/serial/xilinx_uartps.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/tty/serial/xilinx_uartps.c 
b/drivers/tty/serial/xilinx_uartps.c
index b7fc30639292..167e0f4bcf7a 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -755,6 +755,7 @@ static void cdns_uart_set_termios(struct uart_port *port,
  */
 static int cdns_uart_startup(struct uart_port *port)
 {
+   unsigned long flags;
unsigned int retval = 0, status = 0;
 
retval = request_irq(port->irq, cdns_uart_isr, 0, CDNS_UART_NAME,
@@ -762,6 +763,8 @@ static int cdns_uart_startup(struct uart_port *port)
if (retval)
return retval;
 
+   spin_lock_irqsave(>lock, flags);
+
/* Disable the TX and RX */
writel(CDNS_UART_CR_TX_DIS | CDNS_UART_CR_RX_DIS,
port->membase + CDNS_UART_CR_OFFSET);
@@ -772,15 +775,14 @@ static int cdns_uart_startup(struct uart_port *port)
writel(CDNS_UART_CR_TXRST | CDNS_UART_CR_RXRST,
port->membase + CDNS_UART_CR_OFFSET);
 
-   status = readl(port->membase + CDNS_UART_CR_OFFSET);
-
-   /* Clear the RX disable and TX disable bits and then set the TX enable
-* bit and RX enable bit to enable the transmitter and receiver.
+   /*
+* Clear the RX disable bit and then set the RX enable bit to enable
+* the receiver.
 */
-   writel((status & ~(CDNS_UART_CR_TX_DIS | CDNS_UART_CR_RX_DIS))
-   | (CDNS_UART_CR_TX_EN | CDNS_UART_CR_RX_EN |
-   CDNS_UART_CR_STOPBRK),
-   port->membase + CDNS_UART_CR_OFFSET);
+   status = readl(port->membase + CDNS_UART_CR_OFFSET);
+   status &= CDNS_UART_CR_RX_DIS;
+   status |= CDNS_UART_CR_RX_EN;
+   writel(status, port->membase + CDNS_UART_CR_OFFSET);
 
/* Set the Mode Register with normal mode,8 data bits,1 stop bit,
 * no parity.
@@ -811,6 +813,8 @@ static int cdns_uart_startup(struct uart_port *port)
CDNS_UART_IXR_RXTRIG | CDNS_UART_IXR_TOUT,
port->membase + CDNS_UART_IER_OFFSET);
 
+   spin_unlock_irqrestore(>lock, flags);
+
return retval;
 }
 
-- 
2.6.2.3.ga463a5b

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v2 08/10] tty: xuartps: Move RX path into helper function

2015-11-04 Thread Soren Brinkmann
Move RX-related IRQ handling into a helper function.

Signed-off-by: Soren Brinkmann 
---
 drivers/tty/serial/xilinx_uartps.c | 50 +-
 1 file changed, 28 insertions(+), 22 deletions(-)

diff --git a/drivers/tty/serial/xilinx_uartps.c 
b/drivers/tty/serial/xilinx_uartps.c
index 7fd226d65496..aa1176e6661a 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -172,28 +172,8 @@ struct cdns_uart {
 #define to_cdns_uart(_nb) container_of(_nb, struct cdns_uart, \
clk_rate_change_nb);
 
-/**
- * cdns_uart_isr - Interrupt handler
- * @irq: Irq number
- * @dev_id: Id of the port
- *
- * Return: IRQHANDLED
- */
-static irqreturn_t cdns_uart_isr(int irq, void *dev_id)
+static void cdns_uart_handle_rx(struct uart_port *port, unsigned int isrstatus)
 {
-   struct uart_port *port = (struct uart_port *)dev_id;
-   unsigned long flags;
-   unsigned int isrstatus, numbytes;
-   unsigned int data;
-   char status = TTY_NORMAL;
-
-   spin_lock_irqsave(>lock, flags);
-
-   /* Read the interrupt status register to determine which
-* interrupt(s) is/are active.
-*/
-   isrstatus = readl(port->membase + CDNS_UART_ISR_OFFSET);
-
/*
 * There is no hardware break detection, so we interpret framing
 * error with all-zeros data as a break sequence. Most of the time,
@@ -223,6 +203,9 @@ static irqreturn_t cdns_uart_isr(int irq, void *dev_id)
/* Receive Timeout Interrupt */
while (!(readl(port->membase + CDNS_UART_SR_OFFSET) &
CDNS_UART_SR_RXEMPTY)) {
+   u32 data;
+   char status = TTY_NORMAL;
+
data = readl(port->membase + CDNS_UART_FIFO_OFFSET);
 
/* Non-NULL byte after BREAK is garbage (99%) */
@@ -263,10 +246,33 @@ static irqreturn_t cdns_uart_isr(int irq, void *dev_id)
}
 
uart_insert_char(port, isrstatus, CDNS_UART_IXR_OVERRUN,
-   data, status);
+data, status);
}
tty_flip_buffer_push(>state->port);
}
+}
+
+/**
+ * cdns_uart_isr - Interrupt handler
+ * @irq: Irq number
+ * @dev_id: Id of the port
+ *
+ * Return: IRQHANDLED
+ */
+static irqreturn_t cdns_uart_isr(int irq, void *dev_id)
+{
+   struct uart_port *port = (struct uart_port *)dev_id;
+   unsigned long flags;
+   unsigned int isrstatus, numbytes;
+
+   spin_lock_irqsave(>lock, flags);
+
+   /* Read the interrupt status register to determine which
+* interrupt(s) is/are active.
+*/
+   isrstatus = readl(port->membase + CDNS_UART_ISR_OFFSET);
+
+   cdns_uart_handle_rx(port, isrstatus);
 
/* Dispatch an appropriate handler */
if ((isrstatus & CDNS_UART_IXR_TXEMPTY) == CDNS_UART_IXR_TXEMPTY) {
-- 
2.6.2.3.ga463a5b

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2 1/2] MAINTAINERS: Add missing git repository and directory for devfreq

2015-11-04 Thread MyungJoo Ham
>   
>  This patch adds the missing git repository infomation and directory for
> devfreq. When using get_maintainer.pl, the result should include the
> correct maintainer information.
> 
> Suggested-by: Joe Perches 
> [cw00.chio: Add missing directory for devfreq]
> Signed-off-by: Chanwoo Choi 
> ---
>  MAINTAINERS | 3 +++
>  1 file changed, 3 insertions(+)

Thanks.


Signed-off-by: MyungJoo Ham 


> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index bd18978d5ad3..7de31f44a48d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3337,8 +3337,11 @@ DEVICE FREQUENCY (DEVFREQ)
>  M:   MyungJoo Ham 
>  M:   Kyungmin Park 
>  L:   linux...@vger.kernel.org
> +T:   git git://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git
>  S:   Maintained
>  F:   drivers/devfreq/
> +F:   include/linux/devfreq.h
> +F:   Documentation/devicetree/bindings/devfreq/
>  
>  DEVICE NUMBER REGISTRY
>  M:   Torben Mathiasen 
> -- 
> 1.9.1


Re: [patch 02/14] x86/apic: Implement single target IPI function for x2apic_cluster

2015-11-04 Thread Ingo Molnar

* Thomas Gleixner  wrote:

> From: Linus Torvalds 
> 
> [ tglx: Split it out from the patch which provides the new callback
>   and wrapped it into local_irq_save/restore ]
> 
> Signed-off-by: Linus Torvalds 
> Signed-off-by: Thomas Gleixner 
> ---
>  arch/x86/kernel/apic/x2apic_cluster.c |   12 
>  1 file changed, 12 insertions(+)
> 
> Index: linux/arch/x86/kernel/apic/x2apic_cluster.c
> ===
> --- linux.orig/arch/x86/kernel/apic/x2apic_cluster.c
> +++ linux/arch/x86/kernel/apic/x2apic_cluster.c
> @@ -23,6 +23,17 @@ static inline u32 x2apic_cluster(int cpu
>   return per_cpu(x86_cpu_to_logical_apicid, cpu) >> 16;
>  }
>  
> +static void x2apic_send_IPI(int cpu, int vector)
> +{
> + u32 dest = per_cpu(x86_cpu_to_logical_apicid, cpu);
> + unsigned long flags;
> +
> + x2apic_wrmsr_fence();
> + local_irq_save(flags);
> + __x2apic_send_IPI_dest(dest, vector, APIC_DEST_LOGICAL);
> + local_irq_restore(flags);
> +}

So the series looks good to me:

  Reviewed-by: Ingo Molnar 

but in the above sequence I think we can do even better: we don't need the 
local_irq_save()/restore() I think.

The reason, this is how __x2apic_send_IPI_dest() looks like:

unsigned long cfg = __prepare_ICR(0, vector, dest);
native_x2apic_icr_write(cfg, apicid);

__prepare_ICR(), which is a confusing misnomer as it does not prepare anything 
about the ICR register, it just pre-calculates some values, is obviously 
interrupt-safe:

static inline unsigned int __prepare_ICR(unsigned int shortcut, int vector,
 unsigned int dest)
{
unsigned int icr = shortcut | dest;

switch (vector) {
default:
icr |= APIC_DM_FIXED | vector;
break;
case NMI_VECTOR:
icr |= APIC_DM_NMI;
break;
}
return icr;
}

and native_x2apic_icr_write() is a single WRMSR:

static inline void native_x2apic_icr_write(u32 low, u32 id)
{
wrmsrl(APIC_BASE_MSR + (APIC_ICR >> 4), ((__u64) id) << 32 | low);
}

which is interrupt-safe as well.

So we can save another 10-20 cycles of CLI/POPF overhead from this hotpath.

I'd do it as a patch on top, to keep the series simpler - something like the 
below. (Completely untested: may the Force be with you.)

Thanks,

Ingo

Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/apic/x2apic_cluster.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/x86/kernel/apic/x2apic_cluster.c 
b/arch/x86/kernel/apic/x2apic_cluster.c
index 3329dab47efc..aca8b75c1552 100644
--- a/arch/x86/kernel/apic/x2apic_cluster.c
+++ b/arch/x86/kernel/apic/x2apic_cluster.c
@@ -26,12 +26,9 @@ static inline u32 x2apic_cluster(int cpu)
 static void x2apic_send_IPI(int cpu, int vector)
 {
u32 dest = per_cpu(x86_cpu_to_logical_apicid, cpu);
-   unsigned long flags;
 
x2apic_wrmsr_fence();
-   local_irq_save(flags);
__x2apic_send_IPI_dest(dest, vector, APIC_DEST_LOGICAL);
-   local_irq_restore(flags);
 }
 
 static void
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 3/4] scsi: fix compiler warning for sg

2015-11-04 Thread kbuild test robot
Hi Sinan,

[auto build test ERROR on: scsi/for-next]
[also build test ERROR on: v4.3 next-20151105]

url:
https://github.com/0day-ci/linux/commits/Sinan-Kaya/scsi-mpt2sas-try-64-bit-DMA-when-32-bit-DMA-fails/20151105-125248
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next
config: arm-mv78xx0_defconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

>> ERROR: "__aeabi_uldivmod" [drivers/scsi/sg.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


Re: [PATCH 1/2] arm64: Get existing page protections in split_pmd

2015-11-04 Thread Ard Biesheuvel
Hi Laura,

On 3 November 2015 at 22:48, Laura Abbott  wrote:
>
> Rather than always putting the least restrictived permissions

restrictive

> (PAGE_KERNEL_EXEC) when spliting a pmd into pages, use
> the existing permissions from the pmd for the page.
>
> Signed-off-by: Laura Abbott 
> ---
>  arch/arm64/mm/mmu.c | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 9211b85..ff41efa 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -75,14 +75,13 @@ static void __init *early_alloc(unsigned long sz)
>  static void split_pmd(pmd_t *pmd, pte_t *pte)
>  {
> unsigned long pfn = pmd_pfn(*pmd);
> +   unsigned long addr = pfn << PAGE_SHIFT;
> +   pgprot_t prot = __pgprot(pmd_val(*pmd) ^ addr) | PTE_TYPE_PAGE;

pgprot_t is a struct type when STRICT_MM_TYPECHECKS is in effect, so
__pgprot() should cover the entire expression.

With the above fixed:
Reviewed-by: Ard Biesheuvel 

Thanks,

> +
> int i = 0;
>
> do {
> -   /*
> -* Need to have the least restrictive permissions available
> -* permissions will be fixed up later
> -*/
> -   set_pte(pte, pfn_pte(pfn, PAGE_KERNEL_EXEC));
> +   set_pte(pte, pfn_pte(pfn, prot));
> pfn++;
> } while (pte++, i++, i < PTRS_PER_PTE);
>  }
> --
> 2.4.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [GIT PULL] char/misc driver patches for 4.4-rc1

2015-11-04 Thread Linus Torvalds
On Wed, Nov 4, 2015 at 2:19 PM, Greg KH  wrote:
>
> Here is the big char/misc driver update for 4.4-rc1.  Lots of different
> driver and subsystem updates, hwtracing being the largest with the
> addition of some new platforms that are now supported.

Hmm. So if you answer 'N' to "System Trace Module devices", it will
still ask you about the dummy STM driver, and it will still ask you
about doing a console over STM devices.

That seems a bit disingenuous, no?

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] pinctrl: remove redundant if conditional from Kconfig

2015-11-04 Thread Masahiro Yamada
The whole menu is guarded by

  menu "Pin controllers"
  depends on PINCTRL
  ...
  endmenu

The if conditional outside of it is redundant.

Signed-off-by: Masahiro Yamada 
---

 drivers/pinctrl/Kconfig | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index b422e4e..312c78b 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -5,8 +5,6 @@
 config PINCTRL
bool
 
-if PINCTRL
-
 menu "Pin controllers"
depends on PINCTRL
 
@@ -274,5 +272,3 @@ config PINCTRL_TB10X
select GPIOLIB
 
 endmenu
-
-endif
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] reset: check return value of reset_controller_register()

2015-11-04 Thread Sören Brinkmann
On Thu, 2015-11-05 at 02:54PM +0900, Masahiro Yamada wrote:
> Currently, reset_controller_register() always return 0, but it would
> be better to check its return code.
> 
> Signed-off-by: Masahiro Yamada 
Acked-by: Sören Brinkmann 

Sören
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [patch 02/14] x86/apic: Implement single target IPI function for x2apic_cluster

2015-11-04 Thread Linus Torvalds
On Wed, Nov 4, 2015 at 10:38 PM, Ingo Molnar  wrote:
>
> but in the above sequence I think we can do even better: we don't need the
> local_irq_save()/restore() I think.

Right. Thomas added that one to my patch.

I don't think he realized just *how* trivial sending a single IPI is
with the x2apic, and just how horribly nasty the mask case is in
comparison (and how nasty it is that we historically turn a the single
ipi into a mask).

  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v4 4/6] reset: sunxi: Add Allwinner H3 bus resets

2015-11-04 Thread Jean-Francois Moine
On Wed, 4 Nov 2015 08:30:14 -0800
Maxime Ripard  wrote:

> Hi Arnd,
> 
> On Fri, Oct 30, 2015 at 09:27:03AM +0100, Arnd Bergmann wrote:
> > On Tuesday 27 October 2015 17:50:24 Jens Kuske wrote:
> > > 
> > > +static int sun8i_h3_bus_reset_xlate(struct reset_controller_dev *rcdev,
> > > +   const struct of_phandle_args 
> > > *reset_spec)
> > > +{
> > > +   unsigned int index = reset_spec->args[0];
> > > +
> > > +   if (index < 96)
> > > +   return index;
> > > +   else if (index < 128)
> > > +   return index + 32;
> > > +   else if (index < 160)
> > > +   return index + 64;
> > > +   else
> > > +   return -EINVAL;
> > > +}
> > > +
> > > 
> > 
> > This looks like you are doing something wrong and should either
> > put the actual number into DT,
> 
> This is the actual number, except that there's some useless registers
> in between. Allwinner documents it like that:
> 
> 0x0   Reset 0
> 0x4   Reset 1
> 0xc   Reset 2
> 
> So we have to adjust the offset to account with the blank register in
> between (0x8).
> 
> > or use a two-cell representation, with the first cell indicating the
> > block (0, 1 or 2), and the second cell the index.
> 
> And the missing register is not a block either.
> 
> That would also imply either changing the bindings of that driver (and
> all the current DTS that are using it), or introducing a whole new
> driver just to deal with some extraordinary offset calculation.

In the H3, the holes are not used, but what would occur if these holes
would be used for some other purpose in future SoCs? Double mapping?

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2 2/2] MAINTAINERS: Add devfreq-event entry

2015-11-04 Thread MyungJoo Ham
>   
>  This patch adds the devfreq-event[1] entry to review the patches
> as just supporter. Patches will be picked up by Myungjoo Ham on
> devfreq git repository.
> [1] https://lkml.org/lkml/2015/1/25/573
> 
> Signed-off-by: Chanwoo Choi 



Signed-off-by: MyungJoo Ham 

> ---
>  MAINTAINERS | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7de31f44a48d..3d7e4077567b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3343,6 +3343,16 @@ F: drivers/devfreq/
>  F:   include/linux/devfreq.h
>  F:   Documentation/devicetree/bindings/devfreq/
>  
> +DEVICE FREQUENCY EVENT (DEVFREQ-EVENT)
> +M:   Chanwoo Choi 
> +L:   linux...@vger.kernel.org
> +T:   git git://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git
> +S:   Supported
> +F:   drivers/devfreq/event/
> +F:   drivers/devfreq/devfreq-event.c
> +F:   include/linux/devfreq-event.h
> +F:   Documentation/devicetree/bindings/devfreq/event/
> +
>  DEVICE NUMBER REGISTRY
>  M:   Torben Mathiasen 
>  W:   http://lanana.org/docs/device-list/index.html
> -- 
> 1.9.1


Re: [PATCH 3/9] perf, tools, stat: Abstract stat metrics printing

2015-11-04 Thread Jiri Olsa
On Thu, Nov 05, 2015 at 03:43:07AM +0100, Andi Kleen wrote:
> On Wed, Nov 04, 2015 at 09:42:48AM +0100, Jiri Olsa wrote:
> > On Mon, Nov 02, 2015 at 05:50:22PM -0800, Andi Kleen wrote:
> > 
> > SNIP
> > 
> > >   evsel->attr.type == PERF_TYPE_HW_CACHE &&
> > >   evsel->attr.config ==  ( PERF_COUNT_HW_CACHE_L1D |
> > >   ((PERF_COUNT_HW_CACHE_OP_READ) << 8) |
> > > - ((PERF_COUNT_HW_CACHE_RESULT_MISS) << 
> > > 16)) &&
> > > - runtime_l1_dcache_stats[ctx][cpu].n != 0) {
> > > - print_l1_dcache_misses(out, cpu, evsel, avg);
> > > +  ((PERF_COUNT_HW_CACHE_RESULT_MISS) << 
> > > 16))) {
> > > + if (runtime_l1_dcache_stats[ctx][cpu].n != 0)
> > > + print_l1_dcache_misses(cpu, evsel, avg, out);
> > > + else
> > > + print_metric(ctxp, NULL, NULL, "of all L1-dcache hits", 
> > > 0);
> > 
> > hum, what's the reason for all those else cases
> > ending up printing nothing?
> > 
> > we have one metric per line anyway right?
> 
> There can be stuff after the metric, need to print spaces then to get
> the correct indentation.

what stuff?

jirka

> 
> Also it's needed for the metrics only patch (posted separately) so
> that it can catch all column headers, even if some are missing initially.
> 
> -Andi
> 
> -- 
> a...@linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] perf tools: Change FEATURE-DUMP to FEATURE-DUMP.libbpf for lib bpf

2015-11-04 Thread Yunlong Song
Commit ed63f34c026e9a60d17fa750ecdfe3f600d49393 ("perf tools: Make perf
depend on libbpf") dynamically creates FEATURE-DUMP.libbpf during the
perf building, but the .gitignore under tools/lib/bpf/ mistakes
FEATURE-DUMP.libbpf for FEATURE-DUMP. Besides, the Makefile under
tools/lib/bpf/ also mistakes FEATURE-DUMP.libbpf for FEATURE-DUMP, which
causes that "make clean" will leave (or say create) FEATURE-DUMP.libbpf
rather than remove FEATURE-DUMP.libbpf file.

Signed-off-by: Yunlong Song 
---
 tools/lib/bpf/.gitignore | 2 +-
 tools/lib/bpf/Makefile   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/lib/bpf/.gitignore b/tools/lib/bpf/.gitignore
index 812aeed..f81e549 100644
--- a/tools/lib/bpf/.gitignore
+++ b/tools/lib/bpf/.gitignore
@@ -1,2 +1,2 @@
 libbpf_version.h
-FEATURE-DUMP
+FEATURE-DUMP.libbpf
diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
index fc9af57..a3caaf3 100644
--- a/tools/lib/bpf/Makefile
+++ b/tools/lib/bpf/Makefile
@@ -180,7 +180,7 @@ config-clean:
 clean:
$(call QUIET_CLEAN, libbpf) $(RM) *.o *~ $(TARGETS) *.a *.so 
$(VERSION_FILES) .*.d \
$(RM) LIBBPF-CFLAGS
-   $(call QUIET_CLEAN, core-gen) $(RM) $(OUTPUT)FEATURE-DUMP
+   $(call QUIET_CLEAN, core-gen) $(RM) $(OUTPUT)FEATURE-DUMP.libbpf
 
 
 
-- 
1.8.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 3/4] scsi: fix compiler warning for sg

2015-11-04 Thread kbuild test robot
Hi Sinan,

[auto build test ERROR on: scsi/for-next]
[also build test ERROR on: v4.3 next-20151105]

url:
https://github.com/0day-ci/linux/commits/Sinan-Kaya/scsi-mpt2sas-try-64-bit-DMA-when-32-bit-DMA-fails/20151105-125248
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next
config: powerpc-mpc8610_hpcd_defconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `sg_ioctl':
>> drivers/scsi/sg.c:897: undefined reference to `__umoddi3'
>> drivers/scsi/sg.c:897: undefined reference to `__udivdi3'
>> drivers/scsi/sg.c:897: undefined reference to `__udivdi3'

vim +897 drivers/scsi/sg.c

^1da177e Linus Torvalds  2005-04-16  891return 
sfp->timeout_user;
^1da177e Linus Torvalds  2005-04-16  892case SG_SET_FORCE_LOW_DMA:
^1da177e Linus Torvalds  2005-04-16  893result = get_user(val, 
ip);
^1da177e Linus Torvalds  2005-04-16  894if (result)
^1da177e Linus Torvalds  2005-04-16  895return result;
^1da177e Linus Torvalds  2005-04-16  896if (val) {
^1da177e Linus Torvalds  2005-04-16 @897sfp->low_dma = 
1;
^1da177e Linus Torvalds  2005-04-16  898if ((0 == 
sfp->low_dma) && (0 == sg_res_in_use(sfp))) {
^1da177e Linus Torvalds  2005-04-16  899val = 
(int) sfp->reserve.bufflen;
95e159d6 Hannes Reinecke 2014-06-25  900
sg_remove_scat(sfp, >reserve);

:: The code at line 897 was first introduced by commit
:: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2

:: TO: Linus Torvalds 
:: CC: Linus Torvalds 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


[PATCH] ARM: uniphier: select PINCTRL

2015-11-04 Thread Masahiro Yamada
The UniPhier SoCs support pinctrl drivers.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-uniphier/Kconfig b/arch/arm/mach-uniphier/Kconfig
index b640458..82dddee 100644
--- a/arch/arm/mach-uniphier/Kconfig
+++ b/arch/arm/mach-uniphier/Kconfig
@@ -6,6 +6,7 @@ config ARCH_UNIPHIER
select ARM_GIC
select HAVE_ARM_SCU
select HAVE_ARM_TWD if SMP
+   select PINCTRL
help
  Support for UniPhier SoC family developed by Socionext Inc.
  (formerly, System LSI Business Division of Panasonic Corporation)
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: i.MX6: Increasing VPU frequency

2015-11-04 Thread Jon Nettleton
On Thu, Nov 5, 2015 at 7:43 AM, Jean-Michel Hautbois
 wrote:
>
> Le 5 nov. 2015 05:23, "Jon Nettleton"  a écrit :
>>
>> On Wed, Nov 4, 2015 at 8:33 PM, Jean-Michel Hautbois
>>  wrote:
>> > 2015-11-04 18:04 GMT+01:00 Jon Nettleton :
>> >> On Wed, Nov 4, 2015 at 5:52 PM, Jean-Michel Hautbois
>> >>  wrote:
>> >>> Hi !
>> >>>
>> >>> I can see in FSL kernel that VPU is configurable to 352M (it defaults
>> >>> at 264MHz in mainline I think).
>> >>> In the TRM, it is even specified at 352MHz as a default frequency,
>> >>> with a maximum of 540MHz.
>> >>>
>> >>> Would it be possible to allow this clock rating modification if, for
>> >>> instance, we select a performance governor in cpufreq, or if a coda
>> >>> encoder is started with 1080p for instance ?
>> >>> If so, then how is it doable properly ?
>> >>
>> >> For some reason the FSL kernel configures the VPU to run at 352Mhz in
>> >> a very odd way that requires limiting the min cpu-frequency to 792Mhz.
>> >> It also requires clocking down a bunch of devices on pll2_pfd2_396m to
>> >> 352Mhz.
>> >>
>> >> The simple solution to this is to instead parent the VPU to
>> >> pll2_pfd0_352m which is unused.  I have found by default it is stable
>> >> decoding but unstable encoding at 352Mhz, most likely due to the
>> >> voltage changes needed that limiting the min cpu-freq to 792Mhz
>> >> provides.  However everything seems to work quite reliably clocking
>> >> that pfd to 327Mhz, which still gives a boost of almost 24%
>> >>
>> >> In my testing the performance gain in then going from 327 to 352 is
>> >> minimal.  Generally I think you hit AXI bus limitations rather than
>> >> VPU performance.
>> >
>> > Interesting.
>> > So you propose to add something like the following in
>> > drivers/clk/imx/clk-imx6q.cdrivers/clk/imx/clk-imx6q.c :
>> > imx_clk_set_rate(clk[IMX6QDL_CLK_PLL2_PFD0_352M], 32700);
>> > imx_clk_set_parent(clk[IMX6QDL_CLK_VPU_AXI_SEL],
>> > clk[IMX6QDL_CLK_PLL2_PFD0_352M]);
>> >
>> > This should end up with a fastest VPU (in fact ~25% boost is good).
>> > Is it the correct way to do it ?
>> > Should it be done in coda instead ? And only when needed ?
>>
>> That is how I have done it.  I was going to implement dvfs for the vpu
>> but found that this change really added minimal power and thermal
>> overhead.  Without looking it up I believe I only saw a 10-20mA rise
>> in power usage and virtually no thermal differences.
>
> OK so it could even be integrated mainline... Should it be driven by DT
> maybe?
> Is it OK to have VPU at 327MHz and CPU at 396MHz?
>

This can certainly be changed per device via device-tree.  It does run
fine with the cpu at 396MHz, that limitation was previously imposed
due to the clock parent that was being used when the VPU was clocked
to 352MHz.  There have been hints in commits that higher cpu core
voltage is needed, but I have not found any instability so don't
believe this is the case.  Obviously the more people that we can have
test this change the better.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC PATCHv3 3/4] x86/pci: Initial commit for new VMD device driver

2015-11-04 Thread Jiang Liu


On 2015/11/4 23:14, Thomas Gleixner wrote:
> On Wed, 4 Nov 2015, Keith Busch wrote:
> 
>> On Tue, Nov 03, 2015 at 12:42:02PM +0100, Thomas Gleixner wrote:
>>> On Tue, 3 Nov 2015, Keith Busch wrote:
>> +msi_irqdomain = pci_msi_create_irq_domain(NULL, 
>> _chained_msi_domain_info,
>> +  vmd_irqdomain);
>>>
>>> But that parent limitation does not matter simply because your
>>> msi_irqdomain does not follow down the hierarchy in the allocation
>>> path.
>>>
>>> So we can avoid the vmd_irqdomain creation completely. It's just
>>> wasting memory and has no value at all. Creating the msi domain with a
>>> NULL parent is possible.
>>
>> I'm having trouble following the hierarchy and didn't understand the
>> connection between the parent and msi comain. It's still new to me,
>> but I don't think a NULL parent is allowable with msi domains:
>>
>>  pci_msi_setup_msi_irqs()
>>   pci_msi_domain_alloc_irqs()
>>msi_domain_alloc_irqs()
>> __irq_domain_alloc_irqs()
>>  irq_domain_alloc_irqs_recursive()
>>   msi_domain_alloc()
>>irq_domain_alloc_irqs_parent()
>>
>> The last call returns -ENOSYS since there parent is NULL. Was the
>> intension to allow no parent, or do I still need to allocate one to
>> achieve the desired chaining?
> 
> Hmm, seems I missed that part. But that's a fixable problem. Jiang?
Hi Keith,
Could you please try the attached patch?
Thanks!
Gerry

> 
> Thanks,
> 
>   tglx
>  
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
>From 6db1568564f8edee626d1c168b22ed5502abc6eb Mon Sep 17 00:00:00 2001
From: Liu Jiang 
Date: Thu, 5 Nov 2015 11:25:07 +0800
Subject: [PATCH] msi: Relax msi_domain_alloc() to support parentless MSI
 irqdomains

Previously msi_domain_alloc() assumes MSI irqdomains always have parent
irqdomains, but that's not true for the new Intel VMD devices. So relax
msi_domain_alloc() to support parentless MSI irqdomains.

Signed-off-by: Jiang Liu 
Signed-off-by: Liu Jiang 
---
 kernel/irq/msi.c |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
index 7e6512b9dc1f..e4d3d707efff 100644
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -109,9 +109,11 @@ static int msi_domain_alloc(struct irq_domain *domain, unsigned int virq,
 	if (irq_find_mapping(domain, hwirq) > 0)
 		return -EEXIST;
 
-	ret = irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, arg);
-	if (ret < 0)
-		return ret;
+	if (domain->parent) {
+		ret = irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, arg);
+		if (ret < 0)
+			return ret;
+	}
 
 	for (i = 0; i < nr_irqs; i++) {
 		ret = ops->msi_init(domain, info, virq + i, hwirq + i, arg);
-- 
1.7.10.4



Re: [PATCH v2 2/5] spi: spi-ti-qspi: add mmap mode read support

2015-11-04 Thread Vignesh R


On 11/04/2015 08:11 PM, Mark Brown wrote:
> On Tue, Nov 03, 2015 at 03:36:11PM +0530, Vignesh R wrote:
> 
>> +ti_qspi_enable_memory_map(spi);
>> +ti_qspi_setup_mmap_read(spi, read_opcode, addr_width,
>> +dummy_bytes);
>> +memcpy_fromio(buf, qspi->mmap_base + from, len);
>> +*retlen = len;
>> +ti_qspi_disable_memory_map(spi);
> 
> We'll be constantly enabling and disabling memory mapping with this.
> I'm not sure that's a meaningful cost given that it doesn't actually
> remap anything but rather just switches hardware modes, we can always
> optimise it later if it is.
> 

Hmm, I will move the ti_qspi_disable_memory_map() call to
ti_qspi_start_transfer_one(), so that mmap mode is disabled only when
normal SPI bus transfer is requested. Further, "mmap_enabled" status
flag can be used to determine whether mode switch is required or not.
This should help to overcome enabling and disabling memory mapping
between successive mmap read requests.

-- 
Regards
Vignesh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [BUG] linux 4.3 - intel graphics card driver keeps oopsing

2015-11-04 Thread Ian Kumlien
After a few hours the machine started to spontaneously reboot.

It's back to running 4.2.5 - which works fine.

(I don't know if these messages are actually reaching lkml since it's
not showing up in the index on marc.info)

On 4 November 2015 at 10:24, Ian Kumlien  wrote:
> Hi,
>
> This happened when i booted linux 4.3 on a old intel machine.
>
> Please note, it's named before "twilight" was known and it's name is
> inspired by "twilight zone" since it's actually a firewall ;)
>
>   PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
>  1666 root  20   0   0  0  0 R  16,5  0,0  28:19.19 
> kworker/0:2
>  5297 root  20   0   28168   6200   4236 S   6,6  0,3  10:45.31 syslog-ng
> 7 root  20   0   0  0  0 S   0,7  0,0   0:36.32
> rcu_sched
>
> All this cpu usage seems to be required to constantly log OOPSes, like
> the ones listed below, is this known?
>
> ---
> Nov  4 10:18:55 twilight kernel: [ cut here ]
> Nov  4 10:18:55 twilight kernel: WARNING: CPU: 0 PID: 1666 at
> drivers/gpu/drm/drm_atomic.c:491 drm_atomic_check_only+0x457/0x570()
> Nov  4 10:18:55 twilight kernel: Modules linked in: tun uas
> Nov  4 10:18:55 twilight kernel: CPU: 0 PID: 1666 Comm: kworker/0:2
> Tainted: GW   4.3.0 #86
> Nov  4 10:18:55 twilight kernel: Hardware name: MICRO-STAR
> INTERNATIONAL CO., LTD MS-9632/MS-9632, BIOS 6.00 PG 05/16/2007
> Nov  4 10:18:55 twilight kernel: Workqueue: events output_poll_execute
> Nov  4 10:18:55 twilight kernel:  c13b856d  c10788b1
> c14aa787 01eb f6250800 
> Nov  4 10:18:55 twilight kernel: f549e948 f549e938 c107894d 0009
>  c14aa787 0002 f6315400
> Nov  4 10:18:55 twilight kernel: e0ebe600 f6315400 e0ebe600 f6315400
>  e0ebe600 c14aa8ab f6250800
> Nov  4 10:18:55 twilight kernel: Call Trace:
> Nov  4 10:18:55 twilight kernel: [] ? dump_stack+0x3e/0x51
> Nov  4 10:18:55 twilight kernel: [] ? warn_slowpath_common+0x71/0xa0
> Nov  4 10:18:55 twilight kernel: [] ?
> drm_atomic_check_only+0x457/0x570
> Nov  4 10:18:55 twilight kernel: [] ? warn_slowpath_null+0xd/0x10
> Nov  4 10:18:55 twilight kernel: [] ?
> drm_atomic_check_only+0x457/0x570
> Nov  4 10:18:55 twilight kernel: [] ? drm_atomic_commit+0xb/0x50
> Nov  4 10:18:55 twilight kernel: [] ?
> intel_get_load_detect_pipe+0x37d/0x530
> Nov  4 10:18:55 twilight kernel: [] ? intel_tv_detect+0xfb/0x540
> Nov  4 10:18:55 twilight kernel: [] ?
> drm_helper_probe_single_connector_modes_merge_bits+0x293/0x490
> Nov  4 10:18:55 twilight kernel: [] ? kobject_uevent_env+0xd7/0x470
> Nov  4 10:18:55 twilight kernel: [] ?
> drm_helper_probe_single_connector_modes+0x7/0x10
> Nov  4 10:18:55 twilight kernel: [] ?
> drm_fb_helper_probe_connector_modes.isra.5+0x3c/0x60
> Nov  4 10:18:55 twilight kernel: [] ?
> drm_fb_helper_hotplug_event+0x44/0xc0
> Nov  4 10:18:55 twilight kernel: [] ?
> drm_kms_helper_hotplug_event+0x19/0x20
> Nov  4 10:18:55 twilight kernel: [] ? 
> output_poll_execute+0x161/0x1a0
> Nov  4 10:18:55 twilight kernel: [] ? process_one_work+0xef/0x2b0
> Nov  4 10:18:55 twilight kernel: [] ? worker_thread+0x18a/0x400
> Nov  4 10:18:55 twilight kernel: [] ? process_one_work+0x2b0/0x2b0
> Nov  4 10:18:55 twilight kernel: [] ? kthread+0x98/0xb0
> Nov  4 10:18:55 twilight kernel: [] ? 
> ret_from_kernel_thread+0x21/0x30
> Nov  4 10:18:55 twilight kernel: [] ?
> kthread_create_on_node+0x100/0x100
> Nov  4 10:18:55 twilight kernel: ---[ end trace 2c368f52bd242123 ]---
> Nov  4 10:18:55 twilight kernel: [ cut here ]
> Nov  4 10:18:55 twilight kernel: WARNING: CPU: 0 PID: 1666 at
> drivers/gpu/drm/i915/intel_display.c:1389
> assert_planes_disabled+0xdf/0x120()
> Nov  4 10:18:55 twilight kernel: plane A assertion failure, should be
> off on pipe A but is still active
> Nov  4 10:18:55 twilight kernel: Modules linked in: tun uas
> Nov  4 10:18:55 twilight kernel: CPU: 0 PID: 1666 Comm: kworker/0:2
> Tainted: GW   4.3.0 #86
> Nov  4 10:18:55 twilight kernel: Hardware name: MICRO-STAR
> INTERNATIONAL CO., LTD MS-9632/MS-9632, BIOS 6.00 PG 05/16/2007
> Nov  4 10:18:55 twilight kernel: Workqueue: events output_poll_execute
> Nov  4 10:18:55 twilight kernel:  c13b856d f5bcfd90 c10788b1
> c14f165f 056d f590 0041
> Nov  4 10:18:55 twilight kernel:  0041 c1078906 0009
> f5bcfd90 c1ba0294 f5bcfda8 c14f165f
> Nov  4 10:18:55 twilight kernel: c1ba0010 056d c1ba0294 0041
> 0041 f590  
> Nov  4 10:18:55 twilight kernel: Call Trace:
> Nov  4 10:18:55 twilight kernel: [] ? dump_stack+0x3e/0x51
> Nov  4 10:18:55 twilight kernel: [] ? warn_slowpath_common+0x71/0xa0
> Nov  4 10:18:55 twilight kernel: [] ?
> assert_planes_disabled+0xdf/0x120
> Nov  4 10:18:55 twilight kernel: [] ? warn_slowpath_fmt+0x26/0x30
> Nov  4 10:18:55 twilight kernel: [] ?
> assert_planes_disabled+0xdf/0x120
> Nov  4 10:18:55 twilight kernel: [] ? 

RE: [PATCH] ARM:dma-mapping: Handle DMA_BIDIRECTIONAL in _dma_page_cpu_to_dev()

2015-11-04 Thread Sharma, Sanjeev
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] 
Sent: Wednesday, November 04, 2015 4:24 PM
To: Will Deacon
Cc: Sharma, Sanjeev; m.szyprow...@samsung.com; 
linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ARM:dma-mapping: Handle DMA_BIDIRECTIONAL in 
_dma_page_cpu_to_dev()

On Wed, Nov 04, 2015 at 10:39:13AM +, Will Deacon wrote:
> On Wed, Nov 04, 2015 at 03:26:48PM +0530, Sanjeev Sharma wrote:
> > _dma_page_cpu_to_dev() treat DMA_BIDIRECTIONAL similar to 
> > DMA_TO_DEVICE which means that destination buffer is device 
> > memory,means cpu may have written some data to source buffer and 
> > data may be in cache line.For cleaner operation we need to call 
> > outer_flush_range() which will clean and invalidate outer cache lines.
> 
> Why isn't the clean sufficient in this case? We're mapping the buffer 
> to the device, so we clean the dirty lines in the CPU caches and make 
> them visible to the device. If the CPU later wants to read the buffer 
> (i.e. after the device has DMA'd into it), you'll need to map the 
> buffer to the CPU, which will perform the invalidation of the CPU caches.

Indeed.  bidirectional mode is already handled prefectly well by this code.  No 
patches are required.

Thanks Russell & Will for providing input.

Let's assume , CPU don't read the buffer then there could be the problem 
correct ? IMO, to handle every use case outer_flush_range can be used ?
If still it doesn't make sense to use flush on bidirectional mappings, then 
FIXME comment should be removed from the function to avoid any
Confusion.

(I never received the original email.)

--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according 
to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [PATCH cgroup/for-4.4-fixes] cgroup: fix cftype->file_offset handling

2015-11-04 Thread Johannes Weiner
On Thu, Nov 05, 2015 at 12:12:24AM -0500, Tejun Heo wrote:
> 6f60eade2433 ("cgroup: generalize obtaining the handles of and
> notifying cgroup files") introduced cftype->file_offset so that the
> handles for per-css file instances can be recorded.  These handles
> then can be used, for example, to generate file modified
> notifications.
> 
> Unfortunately, it made the wrong assumption that files are created
> once for a given css and removed on its destruction.  Due to the
> dependencies among subsystems, a css may be hidden from userland and
> then later shown again.  This is implemented by removing and
> re-creating the affected files, so the associated kernfs_node for a
> given cgroup file may change over time.  This incorrect assumption led
> to the corruption of css->files lists.
>
> Reimplement cftype->file_offset handling so that cgroup_file->kn is
> protected by a lock and updated as files are created and destroyed.
> This also makes keeping them on per-cgroup list unnecessary.
> 
> Signed-off-by: Tejun Heo 
> Reported-by: James Sedgwick 
> Fixes: 6f60eade2433 ("cgroup: generalize obtaining the handles of and 
> notifying cgroup files")

Kudos to whoever debugged this.

Acked-by: Johannes Weiner 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] reset: check return value of reset_controller_register()

2015-11-04 Thread Masahiro Yamada
Currently, reset_controller_register() always return 0, but it would
be better to check its return code.

Signed-off-by: Masahiro Yamada 
---

 drivers/reset/reset-berlin.c  | 4 +---
 drivers/reset/reset-socfpga.c | 3 +--
 drivers/reset/reset-sunxi.c   | 3 +--
 drivers/reset/reset-zynq.c| 3 +--
 4 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/reset/reset-berlin.c b/drivers/reset/reset-berlin.c
index 3c922d3..970b1ad 100644
--- a/drivers/reset/reset-berlin.c
+++ b/drivers/reset/reset-berlin.c
@@ -87,9 +87,7 @@ static int berlin2_reset_probe(struct platform_device *pdev)
priv->rcdev.of_reset_n_cells = 2;
priv->rcdev.of_xlate = berlin_reset_xlate;
 
-   reset_controller_register(>rcdev);
-
-   return 0;
+   return reset_controller_register(>rcdev);
 }
 
 static const struct of_device_id berlin_reset_dt_match[] = {
diff --git a/drivers/reset/reset-socfpga.c b/drivers/reset/reset-socfpga.c
index 1a6c5d6..b7d773d 100644
--- a/drivers/reset/reset-socfpga.c
+++ b/drivers/reset/reset-socfpga.c
@@ -133,9 +133,8 @@ static int socfpga_reset_probe(struct platform_device *pdev)
data->rcdev.nr_resets = NR_BANKS * BITS_PER_LONG;
data->rcdev.ops = _reset_ops;
data->rcdev.of_node = pdev->dev.of_node;
-   reset_controller_register(>rcdev);
 
-   return 0;
+   return reset_controller_register(>rcdev);
 }
 
 static int socfpga_reset_remove(struct platform_device *pdev)
diff --git a/drivers/reset/reset-sunxi.c b/drivers/reset/reset-sunxi.c
index 3d95c87..29ed39d 100644
--- a/drivers/reset/reset-sunxi.c
+++ b/drivers/reset/reset-sunxi.c
@@ -108,9 +108,8 @@ static int sunxi_reset_init(struct device_node *np)
data->rcdev.nr_resets = size * 32;
data->rcdev.ops = _reset_ops;
data->rcdev.of_node = np;
-   reset_controller_register(>rcdev);
 
-   return 0;
+   return reset_controller_register(>rcdev);
 
 err_alloc:
kfree(data);
diff --git a/drivers/reset/reset-zynq.c b/drivers/reset/reset-zynq.c
index 89318a5..c6b3cd8 100644
--- a/drivers/reset/reset-zynq.c
+++ b/drivers/reset/reset-zynq.c
@@ -121,9 +121,8 @@ static int zynq_reset_probe(struct platform_device *pdev)
priv->rcdev.nr_resets = resource_size(res) / 4 * BITS_PER_LONG;
priv->rcdev.ops = _reset_ops;
priv->rcdev.of_node = pdev->dev.of_node;
-   reset_controller_register(>rcdev);
 
-   return 0;
+   return reset_controller_register(>rcdev);
 }
 
 static int zynq_reset_remove(struct platform_device *pdev)
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


linux-next: Tree for Nov 5

2015-11-04 Thread Stephen Rothwell
Hi all,

Please do *not* add any material intended for v4.5 to your linux-next
included branches until after v4.4-rc1 has been released.

Changes since 20151104:

The battery tree still had its build failure so I used the version from
next-20150925.

The mailbox tree lost its build failure.

The ftrace tree gained a conflict against Linus' tree.

The thermal-soc tree gained a build failure for which I reverted a commit.

Non-merge commits (relative to Linus' tree): 8191
 6528 files changed, 271774 insertions(+), 156784 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), it is also built with powerpc allnoconfig
(32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final
link) and pseries_le_defconfig and i386, sparc, sparc64 and arm defconfig.

Below is a summary of the state of the merge.

I am currently merging 229 trees (counting Linus' and 35 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 (1b1050cdc5cd Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging fixes/master (25cb62b76430 Linux 4.3-rc5)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (049e6dde7e57 Linux 4.3-rc4)
Merging arm-current/fixes (38850d786a79 ARM: 8449/1: fix bug in vdsomunge 
swab32 macro)
Merging m68k-current/for-linus (95bc06ef049b m68k/defconfig: Update defconfigs 
for v4.3-rc1)
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 (977bf062bba3 powerpc/dma: dma_set_coherent_mask() 
should not be GPL only)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (52708d690b8b sparc64: Fix numa distance values)
Merging net/master (1b1050cdc5cd Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging ipsec/master (a8a572a6b5f2 xfrm: dst_entries_init() per-net dst_ops)
Merging ipvs/master (6ece90f9a13e netfilter: fix Kconfig dependencies for 
nf_dup_ipv{4,6})
Merging sound-current/for-linus (c932b98c1e47 ALSA: hda - Apply pin fixup for 
HP ProBook 6550b)
Merging pci-current/for-linus (1266963170f5 PCI: Prevent out of bounds access 
in numa_node override)
Merging wireless-drivers/master (de28a05ee28e Merge tag 
'iwlwifi-for-kalle-2015-10-05' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging driver-core.current/driver-core-linus (9ffecb102835 Linux 4.3-rc3)
Merging tty.current/tty-linus (f235f664a8af fbcon: initialize blink interval 
before calling fb_set_par)
Merging usb.current/usb-linus (32b88194f71d Linux 4.3-rc7)
Merging usb-gadget-fixes/fixes (25cb62b76430 Linux 4.3-rc5)
Merging usb-serial-fixes/usb-linus (32b88194f71d Linux 4.3-rc7)
Merging usb-chipidea-fixes/ci-for-usb-stable (f256896afdb6 usb: chipidea: otg: 
gadget module load and unload support)
Merging staging.current/staging-linus (32b88194f71d Linux 4.3-rc7)
Merging char-misc.current/char-misc-linus (25cb62b76430 Linux 4.3-rc5)
Merging input-current/for-linus (84a73014d86f Merge branch 'next' into 
for-linus)
Merging crypto-current/master (4afa5f961792 crypto: algif_hash - Only export 
and import on sockets with data)
Merging ide/master (1b1050cdc5cd Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put_addr())
Merging vfio-fixes/for-linus (4bc94d5dc95d vfio: Fix lockdep issue)
Merging kselftest-fixes/fixes (ae7858180510 selftests: exec: revert t

[PATCH RESEND 0/4] SMP support for Broadcom NSP

2015-11-04 Thread Kapil Hali
Hi,

This series adds SMP support for Broadcom's Northstar Plus SoC.

There are similar SMP enablement methods for many ARMv7 bsed SoCs.
BCM NSP SoC, has a typical such mechanism - after power-on, the
secondary core is held in a standby state, primary core provides a
startup address for the secondary core and wakes it up. Booting of
the secondary core is serialized using pen_release global variable.

The startup address is programmed at a special register location
which is defined in the device tree using a "secondary-boot-reg"
property in a node whose "enable-method" property matches.

The first patch adds cpu-enable-method in the device tree bindings
documentation. It also updates ARM CPU device tree documentation
with Broadcom Northstar Plus CPU details.

The second patch adds SMP support to the BCM NSP device tree file.

The third patch, enables SMP on BCM NSP. It also consolidates
common SMP handling between BCM NSP and BCM Kona.

The final patch, enables SMP on BCM 4708 and this patch is pulled
in from Jon Mason's patch from the mailing list.

This patch series is constructed based on Linux v4.3-rc2.

The source code is available at GITHUB:
https://github.com/Broadcom/cygnus-linux/tree/nsp-smp-v1

Jon Mason (1):
  ARM: BCM: Add SMP support for Broadcom 4708

Kapil Hali (3):
  dt-bindings: add SMP enable-method for Broadcom NSP
  ARM: dts: add SMP support for Broadcom NSP
  ARM: BCM: Add SMP support for Broadcom NSP

 .../bindings/arm/bcm/brcm,nsp-cpu-method.txt   |  36 ++
 Documentation/devicetree/bindings/arm/cpus.txt |   1 +
 arch/arm/boot/dts/bcm-nsp.dtsi |  33 +++--
 arch/arm/boot/dts/bcm4708.dtsi |   2 +
 arch/arm/mach-bcm/Kconfig  |   3 +
 arch/arm/mach-bcm/Makefile |  11 +-
 arch/arm/mach-bcm/bcm_nsp.h|  19 +++
 arch/arm/mach-bcm/headsmp.S|  37 ++
 arch/arm/mach-bcm/{kona_smp.c => platsmp.c}| 142 +++--
 9 files changed, 261 insertions(+), 23 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
 create mode 100644 arch/arm/mach-bcm/bcm_nsp.h
 create mode 100644 arch/arm/mach-bcm/headsmp.S
 rename arch/arm/mach-bcm/{kona_smp.c => platsmp.c} (63%)

-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH RESEND 2/4] ARM: dts: add SMP support for Broadcom NSP

2015-11-04 Thread Kapil Hali
Add device tree changes required for providing SMP support
for Broadcom Northstar Plus SoC.

Signed-off-by: Kapil Hali 
---
 arch/arm/boot/dts/bcm-nsp.dtsi | 33 +
 1 file changed, 21 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index 58aca27..d1875d9 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -40,24 +40,33 @@
model = "Broadcom Northstar Plus SoC";
interrupt-parent = <>;
 
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   enable-method = "brcm,bcm-nsp-smp";
+   secondary-boot-reg = <0x042c>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a9";
+   next-level-cache = <>;
+   reg = <0x0>;
+   };
+
+   cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a9";
+   next-level-cache = <>;
+   reg = <0x1>;
+   };
+   };
+
mpcore {
compatible = "simple-bus";
ranges = <0x 0x1902 0x3000>;
#address-cells = <1>;
#size-cells = <1>;
 
-   cpus {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   cpu@0 {
-   device_type = "cpu";
-   compatible = "arm,cortex-a9";
-   next-level-cache = <>;
-   reg = <0x0>;
-   };
-   };
-
L2: l2-cache {
compatible = "arm,pl310-cache";
reg = <0x2000 0x1000>;
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH RESEND 1/4] dt-bindings: add SMP enable-method for Broadcom NSP

2015-11-04 Thread Kapil Hali
Add a compatible string "brcm,bcm-nsp-smp" for Broadcom's
Northstar Plus CPU to the 32-bit ARM CPU device tree binding
documentation file and create a new binding documentation for
Northstar Plus CPU pen-release mechanism.

Signed-off-by: Kapil Hali 
---
 .../bindings/arm/bcm/brcm,nsp-cpu-method.txt   | 36 ++
 Documentation/devicetree/bindings/arm/cpus.txt |  1 +
 2 files changed, 37 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt

diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt 
b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
new file mode 100644
index 000..8506da7
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
@@ -0,0 +1,36 @@
+Broadcom Northstar Plus SoC CPU Enable Method
+-
+This binding defines the enable method used for starting secondary
+CPUs in the following Broadcom SoCs:
+  BCM58522, BCM58525, BCM58535, BCM58622, BCM58623, BCM58625, BCM88312
+
+The enable method is specified by defining the following required
+properties in the "cpus" device tree node:
+  - enable-method = "brcm,bcm-nsp-smp";
+  - secondary-boot-reg = <...>;
+
+The secondary-boot-reg property is a u32 value that specifies the
+physical address of the register used to request the ROM holding pen
+code release a secondary CPU.
+
+Example:
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   enable-method = "brcm,bcm-nsp-smp";
+   secondary-boot-reg = <0x042c>;
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a9";
+   next-level-cache = <>;
+   reg = <0>;
+   };
+
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a9";
+   next-level-cache = <>;
+   reg = <1>;
+   };
+   };
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt 
b/Documentation/devicetree/bindings/arm/cpus.txt
index 91e6e5c..6abe3f3 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -191,6 +191,7 @@ nodes to be present and contain the properties described 
below.
"allwinner,sun8i-a23"
"arm,psci"
"brcm,brahma-b15"
+   "brcm,bcm-nsp-smp"
"marvell,armada-375-smp"
"marvell,armada-380-smp"
"marvell,armada-390-smp"
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH RESEND 4/4] ARM: BCM: Add SMP support for Broadcom 4708

2015-11-04 Thread Kapil Hali
From: Jon Mason 

Add SMP support for Broadcom's 4708 SoCs.

Signed-off-by: Jon Mason 
Acked-by: Hauke Mehrtens 
Tested-by: Hauke Mehrtens 
Signed-off-by: Kapil Hali 
---
 arch/arm/boot/dts/bcm4708.dtsi | 2 ++
 arch/arm/mach-bcm/Kconfig  | 1 +
 arch/arm/mach-bcm/Makefile | 3 +++
 3 files changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/bcm4708.dtsi b/arch/arm/boot/dts/bcm4708.dtsi
index 31141e8..22a41df 100644
--- a/arch/arm/boot/dts/bcm4708.dtsi
+++ b/arch/arm/boot/dts/bcm4708.dtsi
@@ -15,6 +15,8 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+   enable-method = "brcm,bcm-nsp-smp";
+   secondary-boot-reg = <0x0400>;
 
cpu@0 {
device_type = "cpu";
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 2e9dbb5..4fc8fa3 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -54,6 +54,7 @@ config ARCH_BCM_NSP
 config ARCH_BCM_5301X
bool "Broadcom BCM470X / BCM5301X ARM SoC" if ARCH_MULTI_V7
select ARCH_BCM_IPROC
+   select HAVE_SMP
help
  Support for Broadcom BCM470X and BCM5301X SoCs with ARM CPU cores.
 
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index 36a4ca30..3ca1cf1 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -43,6 +43,9 @@ obj-$(CONFIG_ARCH_BCM2835)+= board_bcm2835.o
 
 # BCM5301X
 obj-$(CONFIG_ARCH_BCM_5301X)   += bcm_5301x.o
+ifeq ($(CONFIG_ARCH_BCM_5301X),y)
+obj-$(CONFIG_SMP)  += headsmp.o platsmp.o
+endif
 
 # BCM63XXx
 ifeq ($(CONFIG_ARCH_BCM_63XX),y)
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH RESEND 3/4] ARM: BCM: Add SMP support for Broadcom NSP

2015-11-04 Thread Kapil Hali
Add SMP support for Broadcom's Northstar Plus SoC,
cpu enable method and pen_release procedures. This
changes also consolidates iProc family's - BCM NSP
and BCM Kona, SMP handling in a common file.

Northstar Plus SoC is based on ARM Cortex-A9
revision r3p0 which requires configuration for ARM
Errata 764369 for SMP. This change adds the needed
configuration option.

Signed-off-by: Kapil Hali 
---
 arch/arm/mach-bcm/Kconfig   |   2 +
 arch/arm/mach-bcm/Makefile  |   8 +-
 arch/arm/mach-bcm/bcm_nsp.h |  19 
 arch/arm/mach-bcm/headsmp.S |  37 
 arch/arm/mach-bcm/{kona_smp.c => platsmp.c} | 142 ++--
 5 files changed, 197 insertions(+), 11 deletions(-)
 create mode 100644 arch/arm/mach-bcm/bcm_nsp.h
 create mode 100644 arch/arm/mach-bcm/headsmp.S
 rename arch/arm/mach-bcm/{kona_smp.c => platsmp.c} (63%)

diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 1679fa4..2e9dbb5 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -40,6 +40,8 @@ config ARCH_BCM_NSP
select ARCH_BCM_IPROC
select ARM_ERRATA_754322
select ARM_ERRATA_775420
+   select ARM_ERRATA_764369 if SMP
+   select HAVE_SMP
help
  Support for Broadcom Northstar Plus SoC.
  Broadcom Northstar Plus family of SoCs are used for switching control
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index 892261f..36a4ca30 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -14,7 +14,11 @@
 obj-$(CONFIG_ARCH_BCM_CYGNUS) +=  bcm_cygnus.o
 
 # Northstar Plus
-obj-$(CONFIG_ARCH_BCM_NSP) += bcm_nsp.o
+obj-$(CONFIG_ARCH_BCM_NSP) += bcm_nsp.o
+
+ifeq ($(CONFIG_ARCH_BCM_NSP),y)
+obj-$(CONFIG_SMP)  += headsmp.o platsmp.o
+endif
 
 # BCM281XX
 obj-$(CONFIG_ARCH_BCM_281XX)   += board_bcm281xx.o
@@ -23,7 +27,7 @@ obj-$(CONFIG_ARCH_BCM_281XX)  += board_bcm281xx.o
 obj-$(CONFIG_ARCH_BCM_21664)   += board_bcm21664.o
 
 # BCM281XX and BCM21664 SMP support
-obj-$(CONFIG_ARCH_BCM_MOBILE_SMP) += kona_smp.o
+obj-$(CONFIG_ARCH_BCM_MOBILE_SMP) += platsmp.o
 
 # BCM281XX and BCM21664 L2 cache control
 obj-$(CONFIG_ARCH_BCM_MOBILE_L2_CACHE) += kona_l2_cache.o
diff --git a/arch/arm/mach-bcm/bcm_nsp.h b/arch/arm/mach-bcm/bcm_nsp.h
new file mode 100644
index 000..58e1e80
--- /dev/null
+++ b/arch/arm/mach-bcm/bcm_nsp.h
@@ -0,0 +1,19 @@
+/*
+ * Copyright (C) 2015 Broadcom Corporation
+ *
+ * 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __BCM_NSP_H
+#define __BCM_NSP_H
+
+extern void nsp_secondary_startup(void);
+
+#endif /* __BCM_NSP_H */
diff --git a/arch/arm/mach-bcm/headsmp.S b/arch/arm/mach-bcm/headsmp.S
new file mode 100644
index 000..0da13b2
--- /dev/null
+++ b/arch/arm/mach-bcm/headsmp.S
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2015 Broadcom Corporation
+ *
+ * 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+
+/*
+ * iProc specific entry point for secondary CPUs.  This provides
+ * a "holding pen" into which all secondary cores are held until
+ * we are ready for them to initialise.
+ */
+ENTRY(nsp_secondary_startup)
+   mrc p15, 0, r0, c0, c0, 5
+   and r0, r0, #15
+   adr r4, 1f
+   ldmia   r4, {r5, r6}
+   sub r4, r4, r5
+   add r6, r6, r4
+pen:   ldr r7, [r6]
+   cmp r7, r0
+   bne pen
+
+   bsecondary_startup
+
+1: .long   .
+   .long   pen_release
+
+ENDPROC(nsp_secondary_startup)
diff --git a/arch/arm/mach-bcm/kona_smp.c b/arch/arm/mach-bcm/platsmp.c
similarity index 63%
rename from arch/arm/mach-bcm/kona_smp.c
rename to arch/arm/mach-bcm/platsmp.c
index 66a0465..619030e 100644
--- a/arch/arm/mach-bcm/kona_smp.c
+++ b/arch/arm/mach-bcm/platsmp.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2014 Broadcom Corporation
+ * Copyright (C) 2014-2015 Broadcom Corporation
  * Copyright 2014 Linaro Limited
  *
  * This program is free software; you can redistribute it and/or
@@ -12,16 +12,23 @@
  * GNU General Public License for more details.
  */
 
-#include 
+#include 
+#include 
 #include 
+#include 
 #include 
+#include 
 

[PATCH] spi: mediatek: single device does not require cs_gpios

2015-11-04 Thread Nicolas Boichat
When only one device is present, it is not necessary to specify
cs_gpios, as the CS line can be controlled by the hardware
module.

Without this patch, older device tree bindings used before
37457607 "spi: mediatek: mt8173 spi multiple devices support"
would cause a panic on boot. This fixes the crash, and
re-introduces backward compatibility.

Signed-off-by: Nicolas Boichat 
---

Applies on top of broonie/spi.git topic/mtk. Thanks!

 drivers/spi/spi-mt65xx.c | 26 ++
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c
index 563954a..f694031 100644
--- a/drivers/spi/spi-mt65xx.c
+++ b/drivers/spi/spi-mt65xx.c
@@ -410,7 +410,7 @@ static int mtk_spi_setup(struct spi_device *spi)
if (!spi->controller_data)
spi->controller_data = (void *)_default_chip_info;
 
-   if (mdata->dev_comp->need_pad_sel)
+   if (mdata->dev_comp->need_pad_sel && spi->cs_gpio >= 0)
gpio_direction_output(spi->cs_gpio, !(spi->mode & SPI_CS_HIGH));
 
return 0;
@@ -632,13 +632,23 @@ static int mtk_spi_probe(struct platform_device *pdev)
goto err_put_master;
}
 
-   for (i = 0; i < master->num_chipselect; i++) {
-   ret = devm_gpio_request(>dev, master->cs_gpios[i],
-   dev_name(>dev));
-   if (ret) {
-   dev_err(>dev,
-   "can't get CS GPIO %i\n", i);
-   goto err_put_master;
+   if (!master->cs_gpios && master->num_chipselect > 1) {
+   dev_err(>dev,
+   "cs_gpios not specified and num_chipselect > 
1\n");
+   ret = -EINVAL;
+   goto err_put_master;
+   }
+
+   if (master->cs_gpios) {
+   for (i = 0; i < master->num_chipselect; i++) {
+   ret = devm_gpio_request(>dev,
+   master->cs_gpios[i],
+   dev_name(>dev));
+   if (ret) {
+   dev_err(>dev,
+   "can't get CS GPIO %i\n", i);
+   goto err_put_master;
+   }
}
}
}
-- 
2.6.0.rc2.230.g3dd15c0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] alarmtimer: fix unexpected rtc interrupt when system resume

2015-11-04 Thread kbuild test robot
Hi zhuo-hao,

[auto build test WARNING on: tip/timers/core]
[also build test WARNING on: v4.3 next-20151104]

url:
https://github.com/0day-ci/linux/commits/zhuo-hao-lee-intel-com/alarmtimer-fix-unexpected-rtc-interrupt-when-system-resume/20151105-124811
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> kernel/time/alarmtimer.c:280:20: sparse: incompatible types in conditional 
>> expression (different base types)
   kernel/time/alarmtimer.c: In function 'alarmtimer_resume':
   kernel/time/alarmtimer.c:280:9: error: void value not ignored as it ought to 
be
 return rtc ? rtc_timer_cancel(rtc, ) : 0;
^
   kernel/time/alarmtimer.c:281:1: warning: control reaches end of non-void 
function [-Wreturn-type]
}
^

vim +280 kernel/time/alarmtimer.c

   264  rtc_read_time(rtc, );
   265  now = rtc_tm_to_ktime(tm);
   266  now = ktime_add(now, min);
   267  
   268  /* Set alarm, if in the past reject suspend briefly to handle */
   269  ret = rtc_timer_start(rtc, , now, ktime_set(0, 0));
   270  if (ret < 0)
   271  __pm_wakeup_event(ws, MSEC_PER_SEC);
   272  return ret;
   273  }
   274  
   275  static int alarmtimer_resume(struct device *dev)
   276  {
   277  struct rtc_device *rtc;
   278  
   279  rtc = alarmtimer_get_rtcdev();
 > 280  return rtc ? rtc_timer_cancel(rtc, ) : 0;
   281  }
   282  
   283  #else
   284  static int alarmtimer_suspend(struct device *dev)
   285  {
   286  return 0;
   287  }
   288  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v2] alarmtimer: fix unexpected rtc interrupt when system resume from S3

2015-11-04 Thread zhuo-hao . lee
From: zhuo-hao 

Before the system go to suspend (S3), if user create a timer with clockid
CLOCK_REALTIME_ALARM/CLOCK_BOOTTIME_ALARM and set a "large" timeout value
to this timer. The function alarmtimer_suspend will be called to setup
a timeout value to RTC timer to avoid the system sleep over time. However,
if the system wakeup early than RTC timeout, the RTC timer will not be cleared.
And this will cause the hpet_rtc_interrupt come unexpectedly until the RTC
timeout. To fix this problem, just adding alarmtimer_resume to cancel the
RTC timer.

Signed-off-by: Zhuo-hao Lee 
---
 kernel/time/alarmtimer.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/kernel/time/alarmtimer.c b/kernel/time/alarmtimer.c
index 7fbba63..e840ed8 100644
--- a/kernel/time/alarmtimer.c
+++ b/kernel/time/alarmtimer.c
@@ -271,11 +271,27 @@ static int alarmtimer_suspend(struct device *dev)
__pm_wakeup_event(ws, MSEC_PER_SEC);
return ret;
 }
+
+static int alarmtimer_resume(struct device *dev)
+{
+   struct rtc_device *rtc;
+
+   rtc = alarmtimer_get_rtcdev();
+   if (rtc)
+   rtc_timer_cancel(rtc, );
+   return 0;
+}
+
 #else
 static int alarmtimer_suspend(struct device *dev)
 {
return 0;
 }
+
+static int alarmtimer_resume(struct device *dev)
+{
+   return 0;
+}
 #endif
 
 static void alarmtimer_freezerset(ktime_t absexp, enum alarmtimer_type type)
@@ -800,6 +816,7 @@ out:
 /* Suspend hook structures */
 static const struct dev_pm_ops alarmtimer_pm_ops = {
.suspend = alarmtimer_suspend,
+   .resume = alarmtimer_resume,
 };
 
 static struct platform_driver alarmtimer_driver = {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2 2/2] drm/panel: Add Sharp LS043T1LE01 MIPI DSI panel

2015-11-04 Thread Archit Taneja



On 10/31/2015 04:04 AM, Bjorn Andersson wrote:

From: Werner Johansson 

This adds support for the Sharp panel found on the Qualcomm
Snapdragon 800 Dragonboard (APQ8074)

Signed-off-by: Werner Johansson 
Signed-off-by: Bjorn Andersson 


Reviewed-by: Archit Taneja 


---

Change since v1:
- Dropped -vid suffix from compatible

  drivers/gpu/drm/panel/Kconfig   |   9 +
  drivers/gpu/drm/panel/Makefile  |   1 +
  drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 387 
  3 files changed, 397 insertions(+)
  create mode 100644 drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 7d4704b1292b..da3b9c7889c4 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -51,4 +51,13 @@ config DRM_PANEL_SHARP_LQ101R1SX01
  To compile this driver as a module, choose M here: the module
  will be called panel-sharp-lq101r1sx01.

+config DRM_PANEL_SHARP_LS043T1LE01
+   tristate "Sharp LS043T1LE01 qHD video mode panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for Sharp LS043T1LE01 qHD
+ (540x960) DSI panel as found on the Qualcomm APQ8074 Dragonboard
+
  endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index d0f016dd7ddb..53de90aa49cd 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
  obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
  obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
  obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
+obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
diff --git a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c 
b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
new file mode 100644
index ..3aeb0bda4947
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
@@ -0,0 +1,387 @@
+/*
+ * Copyright (C) 2015 Red Hat
+ * Copyright (C) 2015 Sony Mobile Communications Inc.
+ * Author: Werner Johansson 
+ *
+ * Based on AUO panel driver by Rob Clark 
+ *
+ * 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 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 
+#include 
+
+#include 
+
+struct sharp_nt_panel {
+   struct drm_panel base;
+   struct mipi_dsi_device *dsi;
+
+   struct backlight_device *backlight;
+   struct regulator *supply;
+   struct gpio_desc *reset_gpio;
+
+   bool prepared;
+   bool enabled;
+
+   const struct drm_display_mode *mode;
+};
+
+static inline struct sharp_nt_panel *to_sharp_nt_panel(struct drm_panel *panel)
+{
+   return container_of(panel, struct sharp_nt_panel, base);
+}
+
+static int sharp_nt_panel_init(struct sharp_nt_panel *sharp_nt)
+{
+   struct mipi_dsi_device *dsi = sharp_nt->dsi;
+   int ret;
+
+   dsi->mode_flags |= MIPI_DSI_MODE_LPM;
+
+   ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
+   if (ret < 0)
+   return ret;
+
+   msleep(120);
+
+   /* Novatek two-lane operation */
+   ret = mipi_dsi_dcs_write(dsi, 0xae, (u8[]){ 0x03 }, 1);
+   if (ret < 0)
+   return ret;
+
+   /* Set both MCU and RGB I/F to 24bpp */
+   ret = mipi_dsi_dcs_set_pixel_format(dsi, MIPI_DCS_PIXEL_FMT_24BIT |
+   (MIPI_DCS_PIXEL_FMT_24BIT << 4));
+   if (ret < 0)
+   return ret;
+
+   return 0;
+}
+
+static int sharp_nt_panel_on(struct sharp_nt_panel *sharp_nt)
+{
+   struct mipi_dsi_device *dsi = sharp_nt->dsi;
+   int ret;
+
+   dsi->mode_flags |= MIPI_DSI_MODE_LPM;
+
+   ret = mipi_dsi_dcs_set_display_on(dsi);
+   if (ret < 0)
+   return ret;
+
+   return 0;
+}
+
+static int sharp_nt_panel_off(struct sharp_nt_panel *sharp_nt)
+{
+   struct mipi_dsi_device *dsi = sharp_nt->dsi;
+   int ret;
+
+   dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
+
+   ret = mipi_dsi_dcs_set_display_off(dsi);
+   if (ret < 0)
+   return ret;
+
+   ret = mipi_dsi_dcs_enter_sleep_mode(dsi);
+   if (ret < 0)
+   return ret;
+
+   return 0;
+}
+
+
+static int 

Re: [PATCH 1/2] arm64: dts: exynos7: Add pmic s2mps15 device tree node

2015-11-04 Thread Krzysztof Kozlowski
On 05.11.2015 14:37, Alim Akhtar wrote:
> Hi Krzysztof
> 
> On 11/02/2015 07:22 PM, Krzysztof Kozlowski wrote:
>> 2015-11-02 22:01 GMT+09:00 Alim Akhtar :
>
>arch/arm64/boot/dts/exynos/exynos7-espresso.dts |  349
> +++
>1 file changed, 349 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> index 838a3626dac1..8ce04a0ec928 100644
> --- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> @@ -53,6 +53,355 @@
>   status = "okay";
>};
>
> +_4 {
> +   samsung,i2c-sda-delay = <100>;
> +   samsung,i2c-max-bus-freq = <20>;
> +   status = "okay";
> +
> +   s2mps15_pmic@66 {
> +   compatible = "samsung,s2mps15-pmic";
> +   reg = <0x66>;
> +   interrupts = <2 0>;
> +   interrupt-parent = <>;
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_irq>;
> +   wakeup-source;
> +
> +   s2mps15_osc: clocks {
> +   compatible = "samsung,s2mps13-clk";
> +   #clock-cells = <1>;
> +   clock-output-names = "s2mps13_ap",
> "s2mps13_cp",
> +   "s2mps13_bt";
> +   };


 Don't you want to use one of these clocks for s3c-rtc ( node)?

>>> yes, you are right, rtc on this board is currently broken, mainly
>>> because of
>>> the introduction of rtc_src clock in the s3c-rtc driver.
>>> That is on my do list next. will take a look.
>>>
>>> Are you suggesting to remove this -clk node now and add along with rtc
>>> changes? I feel this should go in along with this patch.
>>
>> Just add it in consecutive patch in this series. You added here some
>> providers (clock and regulators) without consumers. This of course
>> looks good as a way of providing full description of the board but:
>> 1. For regulators always on: may be meaningless for kernel. Kernel
>> does not use it. Existence of regulator subnode will fulfill driver's
>> needs for probe.
>> 2. For clocks: actually will disable these clocks because of lack of
>> consumers... which is fine but probably not what you wanted.
>>
>> The standard approach is to add such providers when they are needed -
>> there are some consumers using them.
>>
> OK. for now will keep the pmic clock added as clock will be in disabled
> state, so it wont harm.
> - will keep system related regulator like supply to arm,mif,int etc ..
> will remove supplies to other peripherals IPs. Hope thats fine.

You don't have to remove other regulators (these without consumers).
Describe in DT all of regulators but:
1. Add to some of them consumers;
2. Disable these which are not needed (by not marking always-enabled).

Just like for all other boards.

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 3/4] scsi: fix compiler warning for sg

2015-11-04 Thread kbuild test robot
Hi Sinan,

[auto build test ERROR on: scsi/for-next]
[also build test ERROR on: v4.3 next-20151104]

url:
https://github.com/0day-ci/linux/commits/Sinan-Kaya/scsi-mpt2sas-try-64-bit-DMA-when-32-bit-DMA-fails/20151105-125248
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next
config: i386-defconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `sg_ioctl':
>> sg.c:(.text+0x1b680b): undefined reference to `__umoddi3'
>> sg.c:(.text+0x1b6829): undefined reference to `__udivdi3'
   sg.c:(.text+0x1b6849): undefined reference to `__udivdi3'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


Re: [PATCH 3/4] dm verity: add support for forward error correction

2015-11-04 Thread kbuild test robot
Hi Sami,

[auto build test ERROR on: dm/for-next]
[also build test ERROR on: v4.3 next-20151104]

url:
https://github.com/0day-ci/linux/commits/Sami-Tolvanen/dm-verity-clean-up-duplicate-hashing-code/20151105-124458
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git 
for-next
config: i386-randconfig-a0-201544 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/md/dm-verity.c: In function 'verity_fec_decode_rs8':
>> drivers/md/dm-verity.c:569:9: error: implicit declaration of function 
>> 'decode_rs8' [-Werror=implicit-function-declaration]
 return decode_rs8(io->rs, data, par, v->fec_rsn, NULL, neras,
^
   cc1: some warnings being treated as errors

vim +/decode_rs8 +569 drivers/md/dm-verity.c

   563  int i;
   564  uint16_t par[v->fec_roots];
   565  
   566  for (i = 0; i < v->fec_roots; i++)
   567  par[i] = fec[i];
   568  
 > 569  return decode_rs8(io->rs, data, par, v->fec_rsn, NULL, neras,
   570io->erasures, 0, NULL);
   571  }
   572  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


Re: [PATCH 1/2] arm64: dts: exynos7: Add pmic s2mps15 device tree node

2015-11-04 Thread Alim Akhtar

Hi Krzysztof

On 11/02/2015 07:22 PM, Krzysztof Kozlowski wrote:

2015-11-02 22:01 GMT+09:00 Alim Akhtar :


   arch/arm64/boot/dts/exynos/exynos7-espresso.dts |  349
+++
   1 file changed, 349 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
index 838a3626dac1..8ce04a0ec928 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
+++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
@@ -53,6 +53,355 @@
  status = "okay";
   };

+_4 {
+   samsung,i2c-sda-delay = <100>;
+   samsung,i2c-max-bus-freq = <20>;
+   status = "okay";
+
+   s2mps15_pmic@66 {
+   compatible = "samsung,s2mps15-pmic";
+   reg = <0x66>;
+   interrupts = <2 0>;
+   interrupt-parent = <>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_irq>;
+   wakeup-source;
+
+   s2mps15_osc: clocks {
+   compatible = "samsung,s2mps13-clk";
+   #clock-cells = <1>;
+   clock-output-names = "s2mps13_ap", "s2mps13_cp",
+   "s2mps13_bt";
+   };



Don't you want to use one of these clocks for s3c-rtc ( node)?


yes, you are right, rtc on this board is currently broken, mainly because of
the introduction of rtc_src clock in the s3c-rtc driver.
That is on my do list next. will take a look.

Are you suggesting to remove this -clk node now and add along with rtc
changes? I feel this should go in along with this patch.


Just add it in consecutive patch in this series. You added here some
providers (clock and regulators) without consumers. This of course
looks good as a way of providing full description of the board but:
1. For regulators always on: may be meaningless for kernel. Kernel
does not use it. Existence of regulator subnode will fulfill driver's
needs for probe.
2. For clocks: actually will disable these clocks because of lack of
consumers... which is fine but probably not what you wanted.

The standard approach is to add such providers when they are needed -
there are some consumers using them.

OK. for now will keep the pmic clock added as clock will be in disabled 
state, so it wont harm.

- will keep system related regulator like supply to arm,mif,int etc ..
will remove supplies to other peripherals IPs. Hope thats fine.


+
+   regulators {
+   ldo1_reg: LDO1 {
+   regulator-name = "vdd_ldo1";
+   regulator-min-microvolt = <50>;
+   regulator-max-microvolt = <90>;
+   regulator-always-on;
+   regulator-enable-ramp-delay = <125>;
+   };


(...)


+
+   buck10_reg: BUCK10 {
+   regulator-name = "vdd_buck10";
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <300>;
+   regulator-boot-on;
+   regulator-always-on;
+   regulator-ramp-delay = <25000>;
+   regulator-enable-ramp-delay = <250>;
+   };



All of these ldo3 and bucks in vendor tree for Espresso board have
ramp delay of 12000. Also they don't have enable-ramp-delay set and
voltages sometimes differ. I don't have S2MPS15 datasheet so I don't
know what is the true value... I'll leave it up to you but it looks
suspicious.


These values generally comes from our board design team, so I cann't really
comment on that, it may vary from board revision etc.
I will check if we have any updated version of recommended value and update
accordingly.


Okay, just pointing the difference. I cannot verify them.




+   };
+   };
+};



What will be the benefit of defining all of these regulators if they
are always on and without consumers? No one will disable them, no one
will change the voltage. Please provide some consumers.


As many drivers are not yet enabled in arm64 defconfig, that is one of the
reason why we are not seeing many consumer for these nodes.


That is not a problem. Please send a patch changing the defconfig.
Usually defconfig (for armv7 this would be exynos and multi_v7) should
provide bootable and working environment for all of our supported
boards.


This is the ground work being done for enabling those. If you insist will
try to reduce what is being used now. Moreover this was used to verify
functionality of pmic driver as well.


Actually as a verification I think even adding simple node
"regulators" is sufficient - driver will add all regulators anyway.
However seeing all regulators described for particular board is
good... but lack of consumers is disturbing because this may mean that
it was 

Re: [PATCH v3 4/7] ARCH: EXYNOS: split up exynos4 SoC specific PMU data

2015-11-04 Thread Pankaj Dubey



On Tuesday 03 November 2015 07:26 AM, Krzysztof Kozlowski wrote:

On 26.10.2015 21:55, Pankaj Dubey wrote:

This patch splits up mach-exynos/pmu.c file, and moves exynos4210,
exynos4412 and exynos4212 PMU configuration data and functions handing
data into a common exynos4 SoC specific PMU file mach-exynos/exynos4-pmu.c.

Signed-off-by: Pankaj Dubey 
---
  arch/arm/mach-exynos/Makefile  |   2 +-
  arch/arm/mach-exynos/exynos-pmu.h  |   3 +
  arch/arm/mach-exynos/exynos4-pmu.c | 223 +
  arch/arm/mach-exynos/pmu.c | 207 --
  4 files changed, 227 insertions(+), 208 deletions(-)
  create mode 100644 arch/arm/mach-exynos/exynos4-pmu.c




Reviewed-by: Krzysztof Kozlowski 



Thanks,

Pankaj Dubey


Best regards,
Krzysztof



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH net v2] bpf: fix trivial comment typo

2015-11-04 Thread David Miller
From: Matthew Fernandez 
Date: Thu, 5 Nov 2015 11:09:52 +1100

> bpf: fix trivial comment typo
> 
> Signed-off-by: Matthew Fernandez 

This does not apply.  It looks like your email client has
corrupted the patch.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v3 3/7] ARCH: EXYNOS: split up exynos3250 SoC specific PMU data

2015-11-04 Thread Pankaj Dubey

Hi Krzysztof,

On Tuesday 03 November 2015 07:25 AM, Krzysztof Kozlowski wrote:

On 26.10.2015 21:55, Pankaj Dubey wrote:

This patch splits up mach-exynos/pmu.c file, and moves exynos3250 PMU
configuration data and functions handing those data into exynos3250
SoC specific PMU file mach-exynos/exynos3250-pmu.c.

Signed-off-by: Pankaj Dubey 
---
  arch/arm/mach-exynos/Makefile |   2 +-
  arch/arm/mach-exynos/exynos-pmu.h |  47 +
  arch/arm/mach-exynos/exynos3250-pmu.c | 175 +++
  arch/arm/mach-exynos/pmu.c| 189 +-
  4 files changed, 224 insertions(+), 189 deletions(-)
  create mode 100644 arch/arm/mach-exynos/exynos-pmu.h
  create mode 100644 arch/arm/mach-exynos/exynos3250-pmu.c

diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index 2f30676..e869f86 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -9,7 +9,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) += 
-I$(srctree)/$(src)/include -I$(srctree)

  # Core

-obj-$(CONFIG_ARCH_EXYNOS)  += exynos.o pmu.o exynos-smc.o firmware.o
+obj-$(CONFIG_ARCH_EXYNOS)  += exynos.o pmu.o exynos-smc.o firmware.o 
exynos3250-pmu.o

  obj-$(CONFIG_EXYNOS_CPU_SUSPEND) += pm.o sleep.o
  obj-$(CONFIG_PM_SLEEP)+= suspend.o
diff --git a/arch/arm/mach-exynos/exynos-pmu.h 
b/arch/arm/mach-exynos/exynos-pmu.h
new file mode 100644
index 000..2da4964
--- /dev/null
+++ b/arch/arm/mach-exynos/exynos-pmu.h
@@ -0,0 +1,47 @@
+/*
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Header for EXYNOS PMU Driver support
+ *
+ * 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.
+ */
+
+#ifndef __EXYNOSPMU_H
+#define __EXYNOSPMU_H


__EXYNOS_PMU_H
(and rename it in last patch)



OK.


+
+#include 
+
+#define PMU_TABLE_END  (-1U)
+
+extern void __iomem *pmu_base_addr;
+
+struct exynos_pmu_conf {
+   unsigned int offset;
+   u8 val[NUM_SYS_POWERDOWN];
+};
+
+struct exynos_pmu_data {
+   const struct exynos_pmu_conf *pmu_config;
+   const struct exynos_pmu_conf *pmu_config_extra;
+
+   void (*pmu_init)(void);
+   void (*powerdown_conf)(enum sys_powerdown);
+   void (*powerdown_conf_extra)(enum sys_powerdown);
+};
+
+static inline void pmu_raw_writel(u32 val, u32 offset)
+{
+   writel_relaxed(val, pmu_base_addr + offset);
+}
+
+static inline u32 pmu_raw_readl(u32 offset)
+{
+   return readl_relaxed(pmu_base_addr + offset);
+}


These shouldn't be static inlines in header because you will duplicate
it in each compiled object. Leave optimizations to compiler.



OK. Thanks for review.

Thanks,
Pankaj Dubey

Rest looks good,
Krzysztof



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v3 5/7] ARCH: EXYNOS: split up exynos5250 SoC specific PMU data

2015-11-04 Thread Pankaj Dubey



On Tuesday 03 November 2015 07:37 AM, Krzysztof Kozlowski wrote:

On 26.10.2015 21:55, Pankaj Dubey wrote:

This patch splits up mach-exynos/pmu.c file, and moves exynos5250,
PMU configuration data and functions handing data into exynos5250
SoC specific PMU file mach-exynos/exynos5250-pmu.c.

Signed-off-by: Pankaj Dubey 
---
  arch/arm/mach-exynos/Makefile |   4 +-
  arch/arm/mach-exynos/exynos-pmu.h |   1 +
  arch/arm/mach-exynos/exynos5250-pmu.c | 196 ++
  arch/arm/mach-exynos/pmu.c| 180 ---
  4 files changed, 200 insertions(+), 181 deletions(-)
  create mode 100644 arch/arm/mach-exynos/exynos5250-pmu.c



Reviewed-by: Krzysztof Kozlowski 



Thanks.

Pankaj Dubey


Best regards,
Krzysztof


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v3 6/7] ARCH: EXYNOS: split up exynos5420 SoC specific PMU data

2015-11-04 Thread Pankaj Dubey

Hi Krzysztof,

On Tuesday 03 November 2015 07:40 AM, Krzysztof Kozlowski wrote:

On 26.10.2015 21:55, Pankaj Dubey wrote:

This patch splits up mach-exynos/pmu.c file, and moves exynos5420,
PMU configuration data and functions handing data into exynos5420
SoC specific PMU file mach-exynos/exynos5420-pmu.c.

Signed-off-by: Pankaj Dubey 
---
  arch/arm/mach-exynos/Makefile |   2 +-
  arch/arm/mach-exynos/exynos-pmu.h |   1 +
  arch/arm/mach-exynos/exynos5420-pmu.c | 280 ++
  arch/arm/mach-exynos/pmu.c| 263 ---
  4 files changed, 282 insertions(+), 264 deletions(-)
  create mode 100644 arch/arm/mach-exynos/exynos5420-pmu.c



This should be rebased on:
ARM: EXYNOS: Constify local exynos_pmu_data structure
https://lkml.org/lkml/2015/10/28/917

After merge window I can provide you a tag for that.



OK will do this. Or I will cherry pick this patch from patchwork, and 
will rebase next version on top of it.






diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index bfb23a5..2d58063 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -11,7 +11,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) += 
-I$(srctree)/$(src)/include -I$(srctree)

  obj-$(CONFIG_ARCH_EXYNOS) += exynos.o pmu.o exynos-smc.o firmware.o \
exynos3250-pmu.o exynos4-pmu.o \
-   exynos5250-pmu.o
+   exynos5250-pmu.o exynos5420-pmu.o

  obj-$(CONFIG_EXYNOS_CPU_SUSPEND) += pm.o sleep.o
  obj-$(CONFIG_PM_SLEEP)+= suspend.o
diff --git a/arch/arm/mach-exynos/exynos-pmu.h 
b/arch/arm/mach-exynos/exynos-pmu.h
index 98c6bf3..4d53b68 100644
--- a/arch/arm/mach-exynos/exynos-pmu.h
+++ b/arch/arm/mach-exynos/exynos-pmu.h
@@ -48,4 +48,5 @@ extern const struct exynos_pmu_data exynos4210_pmu_data;
  extern const struct exynos_pmu_data exynos4212_pmu_data;
  extern const struct exynos_pmu_data exynos4412_pmu_data;
  extern const struct exynos_pmu_data exynos5250_pmu_data;
+extern const struct exynos_pmu_data exynos5420_pmu_data;
  #endif /* __EXYNOSPMU_H */
diff --git a/arch/arm/mach-exynos/exynos5420-pmu.c 
b/arch/arm/mach-exynos/exynos5420-pmu.c
new file mode 100644
index 000..5810afe
--- /dev/null
+++ b/arch/arm/mach-exynos/exynos5420-pmu.c
@@ -0,0 +1,280 @@
+/*
+ * Copyright (c) 2011-2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * EXYNOS5420 - CPU PMU (Power Management Unit) support
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+
+#include "exynos-pmu.h"
+
+static struct exynos_pmu_conf exynos5420_pmu_config[] = {
+   /* { .offset = offset, .val = { AFTR, LPA, SLEEP } */
+   { EXYNOS5_ARM_CORE0_SYS_PWR_REG,{ 0x0, 0x0, 0x0} },
+   { EXYNOS5_DIS_IRQ_ARM_CORE0_LOCAL_SYS_PWR_REG,  { 0x0, 0x0, 0x0} },
+   { EXYNOS5_DIS_IRQ_ARM_CORE0_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5_ARM_CORE1_SYS_PWR_REG,{ 0x0, 0x0, 0x0} },
+   { EXYNOS5_DIS_IRQ_ARM_CORE1_LOCAL_SYS_PWR_REG,  { 0x0, 0x0, 0x0} },
+   { EXYNOS5_DIS_IRQ_ARM_CORE1_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_ARM_CORE2_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_DIS_IRQ_ARM_CORE2_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_DIS_IRQ_ARM_CORE2_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_ARM_CORE3_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_DIS_IRQ_ARM_CORE3_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_DIS_IRQ_ARM_CORE3_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_KFC_CORE0_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE0_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE0_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_KFC_CORE1_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE1_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE1_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_KFC_CORE2_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE2_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE2_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_KFC_CORE3_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE3_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE3_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5_ISP_ARM_SYS_PWR_REG,  { 0x1, 0x0, 0x0} },
+   { EXYNOS5_DIS_IRQ_ISP_ARM_LOCAL_SYS_PWR_REG,{ 0x1, 0x0, 0x0} },
+   { 

Re: [PATCH v3 7/7] drivers: soc: Add support for Exynos PMU driver

2015-11-04 Thread Pankaj Dubey

Hi Krzysztof,

On Tuesday 03 November 2015 07:52 AM, Krzysztof Kozlowski wrote:

On 26.10.2015 21:55, Pankaj Dubey wrote:

This patch moves Exynos PMU driver implementation from "arm/mach-exynos"
to "drivers/soc/samsung". This driver is mainly used for setting misc
bits of register from PMU IP of Exynos SoC which will be required to
configure before Suspend/Resume. Currently all these settings are done
in "arch/arm/mach-exynos/pmu.c" but moving ahead for ARM64 based SoC
support, there is a need of this PMU driver in driver/* folder.

This driver uses existing DT binding information and there should
be no functionality change in the supported platforms.

Signed-off-by: Amit Daniel Kachhap 
Signed-off-by: Pankaj Dubey 
---
  arch/arm/mach-exynos/Kconfig   | 1 +
  arch/arm/mach-exynos/Makefile  | 4 +---
  drivers/soc/samsung/Kconfig| 4 
  drivers/soc/samsung/Makefile   | 4 
  arch/arm/mach-exynos/pmu.c => drivers/soc/samsung/exynos-pmu.c | 0
  {arch/arm/mach-exynos => drivers/soc/samsung}/exynos-pmu.h | 0
  {arch/arm/mach-exynos => drivers/soc/samsung}/exynos3250-pmu.c | 0
  {arch/arm/mach-exynos => drivers/soc/samsung}/exynos4-pmu.c| 0
  {arch/arm/mach-exynos => drivers/soc/samsung}/exynos5250-pmu.c | 0
  {arch/arm/mach-exynos => drivers/soc/samsung}/exynos5420-pmu.c | 0
  10 files changed, 10 insertions(+), 3 deletions(-)
  rename arch/arm/mach-exynos/pmu.c => drivers/soc/samsung/exynos-pmu.c (100%)
  rename {arch/arm/mach-exynos => drivers/soc/samsung}/exynos-pmu.h (100%)
  rename {arch/arm/mach-exynos => drivers/soc/samsung}/exynos3250-pmu.c (100%)
  rename {arch/arm/mach-exynos => drivers/soc/samsung}/exynos4-pmu.c (100%)
  rename {arch/arm/mach-exynos => drivers/soc/samsung}/exynos5250-pmu.c (100%)
  rename {arch/arm/mach-exynos => drivers/soc/samsung}/exynos5420-pmu.c (100%)





1. Please reorder the exynos_sys_powerdown_conf() to be after the
statics. I am thinking also about adding EXPORT_SYMBOL... but maybe this
would be over-thinking.



I could not understand your point of reordering, will you please explain 
this.



2. I think the proper location of everything is drivers/power/reset/.
Although I don't have strong opinion.



There has been discussion about the proper location for this driver, 
initial attempt was done in "drivers/mfd" folder but then we realized 
that this driver is not exactly fitting in MFD category.
There was suggestion from Catalin Marinas [1], [2] to move it to 
"drivers/power" or a more suitable place other than mfd. As I received 
comments from Bartlomiej [3] and other members also (sorry I could not 
produce all links as it was quite more than a year back), I feel driver 
is very much SoC specific and hence decided to move it here.


1: https://lkml.org/lkml/2014/4/28/879
2: 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/252018.html
3: 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/244690.html



3. Please cc linux-pm and arm-soc guys (Arnd, Olof, Kevin) on next
iteration.



Ok will keep them in CC in next revision.

Thanks,
Pankaj Dubey


Best regards,
Krzysztof


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] net: stmmac: remove unneeded phy_iface variable

2015-11-04 Thread David Miller
From: LABBE Corentin 
Date: Wed,  4 Nov 2015 21:08:12 +0100

> The variable phy_iface is double-initialized and finally is not necessary
> at all.
> 
> Reported-by: coverity (CID 1271141)
> Signed-off-by: LABBE Corentin 

The value is used in two locations, so having it computed once in a
variable is useful.

Please just eliminate the double assignment.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v3 2/7] ARM: EXYNOS: Move pmu specific headers under "linux/soc/samsung"

2015-11-04 Thread Pankaj Dubey



On Tuesday 03 November 2015 07:16 AM, Krzysztof Kozlowski wrote:

On 26.10.2015 21:55, Pankaj Dubey wrote:

Moving Exynos PMU specific header file into "include/linux/soc/samsung"
thus updated affected files under "mach-exynos" to use new location of
these header files.

Signed-off-by: Amit Daniel Kachhap 
Signed-off-by: Pankaj Dubey 
---
  arch/arm/mach-exynos/exynos.c | 2 +-
  arch/arm/mach-exynos/mcpm-exynos.c| 2 +-
  arch/arm/mach-exynos/platsmp.c| 2 +-
  arch/arm/mach-exynos/pm.c | 4 ++--
  arch/arm/mach-exynos/pmu.c| 6 +++---
  arch/arm/mach-exynos/suspend.c| 4 ++--
  {arch/arm/mach-exynos => include/linux/soc/samsung}/exynos-pmu.h  | 2 +-
  .../regs-pmu.h => include/linux/soc/samsung/exynos-regs-pmu.h | 8 
  8 files changed, 15 insertions(+), 15 deletions(-)
  rename {arch/arm/mach-exynos => include/linux/soc/samsung}/exynos-pmu.h (90%)
  rename arch/arm/mach-exynos/regs-pmu.h => 
include/linux/soc/samsung/exynos-regs-pmu.h (99%)
diff --git a/arch/arm/mach-exynos/exynos-pmu.h 
b/include/linux/soc/samsung/exynos-pmu.h
similarity index 90%
rename from arch/arm/mach-exynos/exynos-pmu.h
rename to include/linux/soc/samsung/exynos-pmu.h
index a2ab0d5..50dd0aa 100644
--- a/arch/arm/mach-exynos/exynos-pmu.h
+++ b/include/linux/soc/samsung/exynos-pmu.h
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.


No changes in file, don't touch the copyright date.

Instead please update the header-inclusion guard:
__SOC_EXYNOS_PMU_H
or maybe even (because you added exynos-pmu.h in next patch):
__LINUX_SOC_EXYNOS_PMU_H



OK.




   *http://www.samsung.com
   *
   * Header for EXYNOS PMU Driver support
diff --git a/arch/arm/mach-exynos/regs-pmu.h 
b/include/linux/soc/samsung/exynos-regs-pmu.h
similarity index 99%
rename from arch/arm/mach-exynos/regs-pmu.h
rename to include/linux/soc/samsung/exynos-regs-pmu.h
index 5e4f4c2..3a5b7ff 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/include/linux/soc/samsung/exynos-regs-pmu.h
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2010-2012 Samsung Electronics Co., Ltd.
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
   *http://www.samsung.com
   *
   * EXYNOS - Power management unit definition
@@ -9,8 +9,8 @@
   * published by the Free Software Foundation.
  */

-#ifndef __ASM_ARCH_REGS_PMU_H
-#define __ASM_ARCH_REGS_PMU_H __FILE__
+#ifndef __EXYNOS_REGS_PMU_H
+#define __EXYNOS_REGS_PMU_H __FILE__

  #define S5P_CENTRAL_SEQ_CONFIGURATION 0x0200

@@ -690,4 +690,4 @@
 | EXYNOS5420_KFC_USE_STANDBY_WFI2  \
 | EXYNOS5420_KFC_USE_STANDBY_WFI3)

-#endif /* __ASM_ARCH_REGS_PMU_H */
+#endif /* __EXYNOS_REGS_PMU_H */



ditto, copyright may stay but please add SOC prefix to define.



OK. Thanks for review.

Thanks,
Pankaj Dubey

Best regards,
Krzysztof



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v3 1/7] ARM: EXYNOS: removing redundant code from regs-pmu.h

2015-11-04 Thread Pankaj Dubey



On Tuesday 03 November 2015 07:07 AM, Krzysztof Kozlowski wrote:

On 26.10.2015 21:55, Pankaj Dubey wrote:

commit 6ec4f8d0d91f ("ARM: EXYNOS: add generic function to calculate
cpu number") introduced exynos_pmu_cpunr to be used by multi-cluster SoC's
e.g Exynos5420, but it's no more used in the codebase and hence removing
this part of code.

Signed-off-by: Pankaj Dubey 
---
  arch/arm/mach-exynos/pmu.c  | 1 +
  arch/arm/mach-exynos/regs-pmu.h | 9 -
  2 files changed, 1 insertion(+), 9 deletions(-)



Reviewed-by: Krzysztof Kozlowski 



Thanks for review.

Pankaj

Best regards,
Krzysztof




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v3 0/7] samsung: pmu: split up SoC specific PMU data

2015-11-04 Thread Pankaj Dubey

Hi Krzysztof,

On Tuesday 03 November 2015 07:36 AM, Krzysztof Kozlowski wrote:

On 26.10.2015 21:55, Pankaj Dubey wrote:

This patch series is a part of continuation work from following series
[1] and [2].

1: exynos: Move pmu driver to driver/soc folder and add exynos7 support
http://www.spinics.net/lists/linux-samsung-soc/msg39797.html from Amit 
Daniel Kacchap
2: soc: samsung: pmu: split up SoC specific PMU data
https://lkml.org/lkml/2015/1/7/12 from me



+Cc Bartlomiej,

There were some concerns for previous versions of this patchset. I
cannot find all of them (e.g. Bartlomiej's are not present on lkml.org
anymore) so I am not sure if they were addressed properly.



Yes. If I recall correctly he has following main concerns:
1: To convert exynos-pmu to a proper platform driver before moving out 
of arch/arm/mach-exynos. This is already addressed.


2: Do we really need common driver for both ARM and ARM64? I feel yes, 
as at least I can see that driver's basic structure will be reused. As 
in case of PMU driver most of lines of code is data part (register 
offset and its values in different mode), that part will be kept in 
separate file e.g. exynos7-pmu.c or exynos-pmu.c.

There has been already one attempt of submission for exynos7 PMU driver at:

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/305418.html

3: He had a concern that in case of ARM64 build most of ARM related code 
will be present in binary which will be dead code, that can be addressed 
by excluding ARM based SoC exynos-pmu.c file in Makefile.

It has been taken care in v3 7/7 patch in drivers/soc/samsung/Makefile.


I like the approach, it helps in reviewing the patch.


Thanks. This was a review comment from Kukjin, to separate data part of 
all SoC and move them to respective files, same as we do for clock files 
of each SoC.




I wonder - after adding this for ARM64 how much of duplicated code this
approach reduce?



It will reduce in duplication driver structure, which will be same.


Best regards,
Krzysztof


Here is another attempt for the same, in this series I am splitting up SoC
specific PMU configuration data into mach-exynos folder itself, before moving
all of them under drivers/soc/samsung/. Also instead of making all changes in
single patch it has been broken into SoC specific patches to avoid large size
of patch. With this approach there will not be unwanted big churns just after
adding exynos-pmu under drivers/soc/samsung.

All these patches are just refactoring to keep minimal changes while moving
exynos-pmu driver under drivers/soc/samsung/. Support for exynos7 PMU can be 
added
on top of it, in such a manner that for ARM64 build, ARM related SoC's PMU will 
not
get compiled and thus unnecessary increasing kernel image size.

I have tested on Peach-Pi (Exynos5880) based chromebook for boot
and S2R functionality.

These patches have been prepared on top of Kukjin Kim's for-next

Changes since v2:
  - Removed Amit's Samsung id as it's no more valid.
  - Rebased on latest kgene tree.
  - Removed redundant code from regs-pmu.h


Pankaj Dubey (7):
   ARM: EXYNOS: removing redundant code from regs-pmu.h
   ARM: EXYNOS: Move pmu specific headers under "linux/soc/samsung"
   ARCH: EXYNOS: split up exynos3250 SoC specific PMU data
   ARCH: EXYNOS: split up exynos4 SoC specific PMU data
   ARCH: EXYNOS: split up exynos5250 SoC specific PMU data
   ARCH: EXYNOS: split up exynos5420 SoC specific PMU data
   drivers: soc: Add support for Exynos PMU driver

  arch/arm/mach-exynos/Kconfig   |1 +
  arch/arm/mach-exynos/Makefile  |2 +-
  arch/arm/mach-exynos/exynos.c  |2 +-
  arch/arm/mach-exynos/mcpm-exynos.c |2 +-
  arch/arm/mach-exynos/platsmp.c |2 +-
  arch/arm/mach-exynos/pm.c  |4 +-
  arch/arm/mach-exynos/pmu.c | 1004 
  arch/arm/mach-exynos/suspend.c |4 +-
  drivers/soc/samsung/Kconfig|4 +
  drivers/soc/samsung/Makefile   |4 +
  drivers/soc/samsung/exynos-pmu.c   |  168 
  drivers/soc/samsung/exynos-pmu.h   |   52 +
  drivers/soc/samsung/exynos3250-pmu.c   |  175 
  drivers/soc/samsung/exynos4-pmu.c  |  223 +
  drivers/soc/samsung/exynos5250-pmu.c   |  196 
  drivers/soc/samsung/exynos5420-pmu.c   |  280 ++
  .../linux/soc/samsung}/exynos-pmu.h|2 +-
  .../linux/soc/samsung/exynos-regs-pmu.h|   17 +-
  18 files changed, 1116 insertions(+), 1026 deletions(-)
  delete mode 100644 arch/arm/mach-exynos/pmu.c
  create mode 100644 drivers/soc/samsung/exynos-pmu.c
  create mode 100644 drivers/soc/samsung/exynos-pmu.h
  create mode 100644 drivers/soc/samsung/exynos3250-pmu.c
  create mode 100644 

Re: [PATCH RESEND] tracing: Make tracing work when debugfs is not compiled or initialized.

2015-11-04 Thread Jiaxing Wang
On Wed, Nov 04, 2015 at 10:03:39AM -0500, Steven Rostedt wrote:
> On Wed,  4 Nov 2015 09:11:18 +0800
> Jiaxing Wang  wrote:
> 
> > Currently tracing_init_dentry() returns -ENODEV when debugfs is not
> > initialized, which causes tracefs not populated with tracing files and
> > directories, so we will get an empty directory even after we manually
> > mount tracefs.
> > 
> > We can make tracing_init_dentry() return NULL as long as tracefs
> > is initialized and get a populated tracefs.
> > 
> > We also need to make global_trace.dir not NULL in order to pass the checks
> > in tracing_get_dentry() and add_tracer_options().
> > 
> > Also added stub debugfs_create_automount() for when debugfs is not
> > configured in.
> > 
> > Signed-off-by: Jiaxing Wang 
> > ---
> >  include/linux/debugfs.h |  8 
> >  kernel/trace/Kconfig|  1 -
> >  kernel/trace/trace.c| 29 +
> >  3 files changed, 25 insertions(+), 13 deletions(-)
> > 
> > diff --git a/include/linux/debugfs.h b/include/linux/debugfs.h
> > index 9beb636..b42ef88 100644
> > --- a/include/linux/debugfs.h
> > +++ b/include/linux/debugfs.h
> > @@ -160,6 +160,14 @@ static inline struct dentry 
> > *debugfs_create_symlink(const char *name,
> > return ERR_PTR(-ENODEV);
> >  }
> >  
> > +static inline struct dentry *debugfs_create_automount(const char *name,
> > +   struct dentry *parent,
> > +   struct vfsmount *(*f)(void *),
> > +   void *data)
> > +{
> > +   return ERR_PTR(-ENODEV);
> > +}
> 
> This part needs an Acked-by from Greg KH.
> 
> > +
> >  static inline void debugfs_remove(struct dentry *dentry)
> >  { }
> >  
> > diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> > index 1153c43..59f6377f 100644
> > --- a/kernel/trace/Kconfig
> > +++ b/kernel/trace/Kconfig
> > @@ -95,7 +95,6 @@ config RING_BUFFER_ALLOW_SWAP
> >  
> >  config TRACING
> > bool
> > -   select DEBUG_FS
> > select RING_BUFFER
> > select STACKTRACE if STACKTRACE_SUPPORT
> > select TRACEPOINTS
> > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> > index 6e79408..6dd064e 100644
> > --- a/kernel/trace/trace.c
> > +++ b/kernel/trace/trace.c
> > @@ -6706,6 +6706,8 @@ static struct vfsmount *trace_automount(void *ingore)
> > return mnt;
> >  }
> >  
> > +#define TRACE_TOP_DIR_ENTRY((struct dentry *)1)
> > +
> >  /**
> >   * tracing_init_dentry - initialize top level trace array
> >   *
> > @@ -6716,27 +6718,30 @@ static struct vfsmount *trace_automount(void 
> > *ingore)
> >  struct dentry *tracing_init_dentry(void)
> >  {
> > struct trace_array *tr = _trace;
> > +   struct dentry *traced;
> >  
> > /* The top level trace array uses  NULL as parent */
> > if (tr->dir)
> > return NULL;
> >  
> > -   if (WARN_ON(!debugfs_initialized()))
> > +   if (WARN_ON(!tracefs_initialized()))
> > return ERR_PTR(-ENODEV);
> >  
> > -   /*
> > -* As there may still be users that expect the tracing
> > -* files to exist in debugfs/tracing, we must automount
> > -* the tracefs file system there, so older tools still
> > -* work with the newer kerenl.
> > -*/
> > -   tr->dir = debugfs_create_automount("tracing", NULL,
> > -  trace_automount, NULL);
> > -   if (!tr->dir) {
> > -   pr_warn_once("Could not create debugfs directory 'tracing'\n");
> > -   return ERR_PTR(-ENOMEM);
> > +   if (debugfs_initialized()) {
> > +   /*
> > +* As there may still be users that expect the tracing
> > +* files to exist in debugfs/tracing, we must automount
> > +* the tracefs file system there, so older tools still
> > +* work with the newer kerenl.
> > +*/
> > +   traced = debugfs_create_automount("tracing", NULL,
> > +  trace_automount, NULL);
> > +   if (!traced)
> > +   pr_warn_once("Could not create debugfs directory 
> > 'tracing'\n");
> 
> This should return a warning, and please keep the tr->dir instead of
> this new traced variable.
Do you mean return ERR_PTR(-ENOMEM); when debugfs_create_automount()
return NULL?
As long as tracefs is initialized, we can make tracing_init_dentry() return
NULL even if the debugfs automount point is not created(), and tracefs can
still be populated. If tracing_init_dentry() returns error in this case,
the caller of tracing_init_dentry() will not populate tracefs.
> 
> > }
> >  
> > +   tr->dir = TRACE_TOP_DIR_ENTRY;
> > +
> 
> Also, no need to add this, because if debugfs is not initialize, then
> tr->dir would be ERR_PTR(-ENODEV), which still works as tr->dir is not
> NULL.
If we accept debugfs_create_automount() return NULL, tr->dir can still
be NULL if we do tr->dir = debugfs_create_automount().
> 
> -- Steve
> 
> > return NULL;
> >  }
> >  
> 
--
To 

[PATCH v2 8/9] arm64: dts: Add main Thermal info to rk3368.dtsi

2015-11-04 Thread Caesar Wang
This patch add the thermal needed info on RK3368.
Meanwhile, support the trips to throttle for thermal.

Signed-off-by: Caesar Wang 

---

Changes in v2:
- fix a copy wrong name.
Series-changes: 1
- support the opt gpio pinctrl state

Changes in v1: None

 arch/arm64/boot/dts/rockchip/rk3368.dtsi | 36 
 1 file changed, 36 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index cc093a4..83a2bd2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -45,6 +45,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
compatible = "rockchip,rk3368";
@@ -123,6 +124,8 @@
reg = <0x0 0x0>;
cpu-idle-states = <_sleep>;
enable-method = "psci";
+
+   #cooling-cells = <2>; /* min followed by max */
};
 
cpu_l1: cpu@1 {
@@ -155,6 +158,8 @@
reg = <0x0 0x100>;
cpu-idle-states = <_sleep>;
enable-method = "psci";
+
+   #cooling-cells = <2>; /* min followed by max */
};
 
cpu_b1: cpu@101 {
@@ -404,6 +409,27 @@
status = "disabled";
};
 
+   thermal-zones {
+   #include "rk3368-thermal.dtsi"
+   };
+
+   tsadc: tsadc@ff28 {
+   compatible = "rockchip,rk3368-tsadc";
+   reg = <0x0 0xff28 0x0 0x100>;
+   interrupts = ;
+   clocks = < SCLK_TSADC>, < PCLK_TSADC>;
+   clock-names = "tsadc", "apb_pclk";
+   resets = < SRST_TSADC>;
+   reset-names = "tsadc-apb";
+   pinctrl-names = "init", "default", "sleep";
+   pinctrl-0 = <_gpio>;
+   pinctrl-1 = <_out>;
+   pinctrl-2 = <_gpio>;
+   #thermal-sensor-cells = <1>;
+   rockchip,hw-tshut-temp = <95000>;
+   status = "disabled";
+   };
+
gmac: ethernet@ff29 {
compatible = "rockchip,rk3368-gmac";
reg = <0x0 0xff29 0x0 0x1>;
@@ -829,6 +855,16 @@
};
};
 
+   tsadc {
+   otp_gpio: otp-gpio {
+   rockchip,pins = <0 10 RK_FUNC_GPIO 
_pull_none>;
+   };
+
+   otp_out: otp-out {
+   rockchip,pins = <0 10 RK_FUNC_1 
_pull_none>;
+   };
+   };
+
uart0 {
uart0_xfer: uart0-xfer {
rockchip,pins = <2 24 RK_FUNC_1 _pull_up>,
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v2 6/9] thermal: rockchip: Support the RK3368 SoCs in thermal drivers

2015-11-04 Thread Caesar Wang
The RK3368 SoCs support to 2 channel TS-ADC, the temperature criteria
of each channel can be configurable.

The system has two Temperature Sensors, channel 0 is for CPU,
and channel 1 is for GPU.

Signed-off-by: Caesar Wang 
---

Changes in v2:
- remove some unused, completed on other patchs.

Changes in v1: None

 drivers/thermal/rockchip_thermal.c | 72 ++
 1 file changed, 72 insertions(+)

diff --git a/drivers/thermal/rockchip_thermal.c 
b/drivers/thermal/rockchip_thermal.c
index 9df027f..47a8873 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -1,6 +1,9 @@
 /*
  * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
  *
+ * Copyright (c) 2015, Fuzhou Rockchip Electronics Co., Ltd
+ * Caesar Wang 
+ *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms and conditions of the GNU General Public License,
  * version 2, as published by the Free Software Foundation.
@@ -152,6 +155,8 @@ struct rockchip_thermal_data {
 #define TSADCV2_INT_PD_CLEAR_MASK  ~BIT(8)
 
 #define TSADCV2_DATA_MASK  0xfff
+#define TSADCV3_DATA_MASK  0x3ff
+
 #define TSADCV2_HIGHT_INT_DEBOUNCE_COUNT   4
 #define TSADCV2_HIGHT_TSHUT_DEBOUNCE_COUNT 4
 #define TSADCV2_AUTO_PERIOD_TIME   250 /* msec */
@@ -200,6 +205,45 @@ static const struct tsadc_table v2_code_table[] = {
{3421, 125000},
 };
 
+static const struct tsadc_table v3_code_table[] = {
+   {0, -4},
+   {106, -4},
+   {108, -35000},
+   {110, -3},
+   {112, -25000},
+   {114, -2},
+   {116, -15000},
+   {118, -1},
+   {120, -5000},
+   {122, 0},
+   {124, 5000},
+   {126, 1},
+   {128, 15000},
+   {130, 2},
+   {132, 25000},
+   {134, 3},
+   {136, 35000},
+   {138, 4},
+   {140, 45000},
+   {142, 5},
+   {144, 55000},
+   {146, 6},
+   {148, 65000},
+   {150, 7},
+   {152, 75000},
+   {154, 8},
+   {156, 85000},
+   {158, 9},
+   {160, 95000},
+   {162, 10},
+   {163, 105000},
+   {165, 11},
+   {167, 115000},
+   {169, 12},
+   {171, 125000},
+   {TSADCV3_DATA_MASK, 125000},
+};
+
 static u32 rk_tsadcv2_temp_to_code(struct chip_tsadc_table table,
   long temp)
 {
@@ -408,11 +452,39 @@ static const struct rockchip_tsadc_chip rk3288_tsadc_data 
= {
},
 };
 
+static const struct rockchip_tsadc_chip rk3368_tsadc_data = {
+   .chn_id[SENSOR_CPU] = 0, /* cpu sensor is channel 0 */
+   .chn_id[SENSOR_GPU] = 1, /* gpu sensor is channel 1 */
+   .chn_num = 2, /* two channels for tsadc */
+
+   .tshut_mode = TSHUT_MODE_GPIO, /* default TSHUT via GPIO give PMIC */
+   .tshut_polarity = TSHUT_LOW_ACTIVE, /* default TSHUT LOW ACTIVE */
+   .tshut_temp = 95000,
+
+   .initialize = rk_tsadcv2_initialize,
+   .irq_ack = rk_tsadcv2_irq_ack,
+   .control = rk_tsadcv2_control,
+   .get_temp = rk_tsadcv2_get_temp,
+   .set_tshut_temp = rk_tsadcv2_tshut_temp,
+   .set_tshut_mode = rk_tsadcv2_tshut_mode,
+
+   .table = {
+   .id = v3_code_table,
+   .length = ARRAY_SIZE(v3_code_table),
+   .data_mask = TSADCV3_DATA_MASK,
+   .flag = ADC_DECREMENT,
+   },
+};
+
 static const struct of_device_id of_rockchip_thermal_match[] = {
{
.compatible = "rockchip,rk3288-tsadc",
.data = (void *)_tsadc_data,
},
+   {
+   .compatible = "rockchip,rk3368-tsadc",
+   .data = (void *)_tsadc_data,
+   },
{ /* end */ },
 };
 MODULE_DEVICE_TABLE(of, of_rockchip_thermal_match);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v2 9/9] arm64: dts: Enable the Thermal on R88 board

2015-11-04 Thread Caesar Wang
This patch enable the TS-ADC.

When a thermal temperature is invoked use the CRU to reset the chip
on R88 board. TSHUT is low active on this board.

Signed-off-by: Caesar Wang 

---

Changes in v2: None
Changes in v1: None

 arch/arm64/boot/dts/rockchip/rk3368-r88.dts | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368-r88.dts 
b/arch/arm64/boot/dts/rockchip/rk3368-r88.dts
index 401a812..7684426a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-r88.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3368-r88.dts
@@ -336,6 +336,12 @@
status = "okay";
 };
 
+ {
+   rockchip,hw-tshut-mode = <0>; /* tshut mode 0:CRU 1:GPIO */
+   rockchip,hw-tshut-polarity = <0>; /* tshut polarity 0:LOW 1:HIGH */
+   status = "okay";
+}
+
  {
status = "okay";
 };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v2 5/9] thermal: rockchip: Add the flag for adc value increment or decrement

2015-11-04 Thread Caesar Wang
The conversion table has the adc value and temperature.
In fact, the adc value only has the increment or decrement mode in
conversion table.

Moment, we can add the flag to be better support the *code_to_temp*
for differenr SoCs.

Signed-off-by: Caesar Wang 
---

Changes in v2: None
Changes in v1: None

 drivers/thermal/rockchip_thermal.c | 64 ++
 1 file changed, 51 insertions(+), 13 deletions(-)

diff --git a/drivers/thermal/rockchip_thermal.c 
b/drivers/thermal/rockchip_thermal.c
index e828f18..9df027f 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -53,6 +53,16 @@ enum sensor_id {
 };
 
 /**
+* The conversion table has the adc value and temperature.
+* ADC_DECREMENT is the adc value decremnet.(e.g. v2_code_table)
+* ADC_INCREMNET is the adc value incremnet.(e.g. v3_code_table)
+*/
+enum adc_flag {
+   ADC_DECREMENT = 0,
+   ADC_INCREMENT,
+};
+
+/**
  * The max sensors is two in rockchip SoCs.
  * Two sensors: CPU and GPU sensor.
  */
@@ -66,6 +76,9 @@ struct chip_tsadc_table {
 
/* that analogic mask data */
unsigned long data_mask;
+
+   /* adc value is increment or decrement */
+   unsigned int flag;
 };
 
 struct rockchip_tsadc_chip {
@@ -223,19 +236,43 @@ static int rk_tsadcv2_code_to_temp(struct 
chip_tsadc_table table, u32 code,
 
WARN_ON(table.length < 2);
 
-   code &= table.data_mask;
-   if (code < table.id[high].code)
+   switch (table.flag) {
+   case ADC_DECREMENT:
+   code &= table.data_mask;
+   if (code < table.id[high].code)
return -EAGAIN; /* Incorrect reading */
 
-   while (low <= high) {
-   if (code >= table.id[mid].code &&
-   code < table.id[mid - 1].code)
-   break;
-   else if (code < table.id[mid].code)
-   low = mid + 1;
-   else
-   high = mid - 1;
-   mid = (low + high) / 2;
+   while (low <= high) {
+   if (code >= table.id[mid].code &&
+   code < table.id[mid - 1].code)
+   break;
+   else if (code < table.id[mid].code)
+   low = mid + 1;
+   else
+   high = mid - 1;
+
+   mid = (low + high) / 2;
+   }
+   break;
+   case ADC_INCREMENT:
+   code &= table.data_mask;
+   if (code < table.id[low].code)
+   return -EAGAIN; /* Incorrect reading */
+
+   while (low <= high) {
+   if (code >= table.id[mid - 1].code &&
+   code < table.id[mid].code)
+   break;
+   else if (code > table.id[mid].code)
+   low = mid + 1;
+   else
+   high = mid - 1;
+
+   mid = (low + high) / 2;
+   }
+   break;
+   default:
+   pr_err("Invalid the table conversion\n");
}
 
/*
@@ -245,8 +282,8 @@ static int rk_tsadcv2_code_to_temp(struct chip_tsadc_table 
table, u32 code,
 * to produce less granular result.
 */
num = table.id[mid].temp - v2_code_table[mid - 1].temp;
-   num *= table.id[mid - 1].code - code;
-   denom = table.id[mid - 1].code - table.id[mid].code;
+   num *= abs(table.id[mid - 1].code - code);
+   denom = abs(table.id[mid - 1].code - table.id[mid].code);
*temp = table.id[mid - 1].temp + (num / denom);
 
return 0;
@@ -367,6 +404,7 @@ static const struct rockchip_tsadc_chip rk3288_tsadc_data = 
{
.id = v2_code_table,
.length = ARRAY_SIZE(v2_code_table),
.data_mask = TSADCV2_DATA_MASK,
+   .flag = ADC_DECREMENT,
},
 };
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v2 4/9] thermal: rockchip: improve the conversion function

2015-11-04 Thread Caesar Wang
We should make the conversion table in as a parameter since the different
SoCs have the different conversionion table.

Signed-off-by: Caesar Wang 
---

Changes in v2:
- make the conversion table in as a parameter both code_to_temp
  and temp_to_code function.
Series-changes: 1
- As Dmitry comment, make the conversion table in as a parameter.

Changes in v1: None

 drivers/thermal/rockchip_thermal.c | 82 +-
 1 file changed, 55 insertions(+), 27 deletions(-)

diff --git a/drivers/thermal/rockchip_thermal.c 
b/drivers/thermal/rockchip_thermal.c
index bdf7063..e828f18 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -58,6 +58,16 @@ enum sensor_id {
  */
 #define SOC_MAX_SENSORS2
 
+struct chip_tsadc_table {
+   const struct tsadc_table *id;
+
+   /* the array table size*/
+   unsigned int length;
+
+   /* that analogic mask data */
+   unsigned long data_mask;
+};
+
 struct rockchip_tsadc_chip {
/* The sensor id of chip correspond to the ADC channel */
int chn_id[SOC_MAX_SENSORS];
@@ -74,9 +84,14 @@ struct rockchip_tsadc_chip {
void (*control)(void __iomem *reg, bool on);
 
/* Per-sensor methods */
-   int (*get_temp)(int chn, void __iomem *reg, int *temp);
-   void (*set_tshut_temp)(int chn, void __iomem *reg, long temp);
+   int (*get_temp)(struct chip_tsadc_table table,
+   int chn, void __iomem *reg, int *temp);
+   void (*set_tshut_temp)(struct chip_tsadc_table table,
+  int chn, void __iomem *reg, long temp);
void (*set_tshut_mode)(int chn, void __iomem *reg, enum tshut_mode m);
+
+   /* Per-table methods */
+   struct chip_tsadc_table table;
 };
 
 struct rockchip_thermal_sensor {
@@ -172,21 +187,22 @@ static const struct tsadc_table v2_code_table[] = {
{3421, 125000},
 };
 
-static u32 rk_tsadcv2_temp_to_code(long temp)
+static u32 rk_tsadcv2_temp_to_code(struct chip_tsadc_table table,
+  long temp)
 {
int high, low, mid;
 
low = 0;
-   high = ARRAY_SIZE(v2_code_table) - 1;
+   high = table.length - 1;
mid = (high + low) / 2;
 
-   if (temp < v2_code_table[low].temp || temp > v2_code_table[high].temp)
+   if (temp < table.id[low].temp || temp > table.id[high].temp)
return 0;
 
while (low <= high) {
-   if (temp == v2_code_table[mid].temp)
-   return v2_code_table[mid].code;
-   else if (temp < v2_code_table[mid].temp)
+   if (temp == table.id[mid].temp)
+   return table.id[mid].code;
+   else if (temp < table.id[mid].temp)
high = mid - 1;
else
low = mid + 1;
@@ -196,25 +212,26 @@ static u32 rk_tsadcv2_temp_to_code(long temp)
return 0;
 }
 
-static int rk_tsadcv2_code_to_temp(u32 code, int *temp)
+static int rk_tsadcv2_code_to_temp(struct chip_tsadc_table table, u32 code,
+  int *temp)
 {
unsigned int low = 1;
-   unsigned int high = ARRAY_SIZE(v2_code_table) - 1;
+   unsigned int high = table.length - 1;
unsigned int mid = (low + high) / 2;
unsigned int num;
unsigned long denom;
 
-   BUILD_BUG_ON(ARRAY_SIZE(v2_code_table) < 2);
+   WARN_ON(table.length < 2);
 
-   code &= TSADCV2_DATA_MASK;
-   if (code < v2_code_table[high].code)
+   code &= table.data_mask;
+   if (code < table.id[high].code)
return -EAGAIN; /* Incorrect reading */
 
while (low <= high) {
-   if (code >= v2_code_table[mid].code &&
-   code < v2_code_table[mid - 1].code)
+   if (code >= table.id[mid].code &&
+   code < table.id[mid - 1].code)
break;
-   else if (code < v2_code_table[mid].code)
+   else if (code < table.id[mid].code)
low = mid + 1;
else
high = mid - 1;
@@ -227,10 +244,10 @@ static int rk_tsadcv2_code_to_temp(u32 code, int *temp)
 * temperature between 2 table entries is linear and interpolate
 * to produce less granular result.
 */
-   num = v2_code_table[mid].temp - v2_code_table[mid - 1].temp;
-   num *= v2_code_table[mid - 1].code - code;
-   denom = v2_code_table[mid - 1].code - v2_code_table[mid].code;
-   *temp = v2_code_table[mid - 1].temp + (num / denom);
+   num = table.id[mid].temp - v2_code_table[mid - 1].temp;
+   num *= table.id[mid - 1].code - code;
+   denom = table.id[mid - 1].code - table.id[mid].code;
+   *temp = table.id[mid - 1].temp + (num / denom);
 
return 0;
 }
@@ -290,20 +307,22 @@ static void rk_tsadcv2_control(void __iomem *regs, bool 
enable)

[PATCH v2 7/9] arm64: dts: Add the thermal data found on RK3368

2015-11-04 Thread Caesar Wang
This patchset add the thermal for RK3368 dts,
Since the two CPU clusters, with four CPU core for each cluster,
One cluster is optimized for high-performance(big cluster) and the othe
is optimized for low power(little cluster).

This patch adds the second order for thermal throttle, and the critical
temperature for thermal over-tempeature protection on Software.

Signed-off-by: Caesar Wang 
---

Changes in v2: None
Changes in v1: None

 arch/arm64/boot/dts/rockchip/rk3368-thermal.dtsi | 112 +++
 1 file changed, 112 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3368-thermal.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rk3368-thermal.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3368-thermal.dtsi
new file mode 100644
index 000..a10010f
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3368-thermal.dtsi
@@ -0,0 +1,112 @@
+/*
+ * Device Tree Source for RK3368 SoC thermal
+ *
+ * Copyright (c) 2015, Fuzhou Rockchip Electronics Co., Ltd
+ * Caesar Wang 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file 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 file 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+
+cpu_thermal: cpu_thermal {
+   polling-delay-passive = <100>; /* milliseconds */
+   polling-delay = <5000>; /* milliseconds */
+
+   thermal-sensors = < 0>;
+
+   trips {
+   cpu_alert0: cpu_alert0 {
+   temperature = <75000>; /* millicelsius */
+   hysteresis = <2000>; /* millicelsius */
+   type = "passive";
+   };
+   cpu_alert1: cpu_alert1 {
+   temperature = <8>; /* millicelsius */
+   hysteresis = <2000>; /* millicelsius */
+   type = "passive";
+   };
+   cpu_crit: cpu_crit {
+   temperature = <95000>; /* millicelsius */
+   hysteresis = <2000>; /* millicelsius */
+   type = "critical";
+   };
+   };
+
+   cooling-maps {
+   map0 {
+   trip = <_alert0>;
+   cooling-device =
+   <_b0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+   };
+   map1 {
+   trip = <_alert1>;
+   cooling-device =
+   <_l0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+   };
+   };
+};
+
+gpu_thermal: gpu_thermal {
+   polling-delay-passive = <100>; /* milliseconds */
+   polling-delay = <5000>; /* milliseconds */
+
+   thermal-sensors = < 1>;
+
+   trips {
+   gpu_alert0: gpu_alert0 {
+   temperature = <8>; /* millicelsius */
+   hysteresis = <2000>; /* millicelsius */
+   type = "passive";
+   };
+   gpu_crit: gpu_crit {
+   temperature = <115>; /* millicelsius */
+   hysteresis = <2000>; /* millicelsius */
+   type = "critical";
+   };
+   };
+
+   

[PATCH v2 2/9] thermal: rockchip: better to compatible the driver for different SoCs

2015-11-04 Thread Caesar Wang
The current driver is default to register the two thermal sensors
in probe since some SoCs maybe only have one sensor for thermal.

In some cases, the channel 0 is not always the cpu or gpu sensor.
So add the channel can be configured for sensors.

Signed-off-by: Caesar Wang 
---

Changes in v2: None
Changes in v1:
- add a new patch for thermal driver to support more SoCs.

 drivers/thermal/rockchip_thermal.c | 86 +-
 1 file changed, 48 insertions(+), 38 deletions(-)

diff --git a/drivers/thermal/rockchip_thermal.c 
b/drivers/thermal/rockchip_thermal.c
index 2b58870..075d18e 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -44,15 +44,25 @@ enum tshut_polarity {
 };
 
 /**
- * The system has three Temperature Sensors.  channel 0 is reserved,
- * channel 1 is for CPU, and channel 2 is for GPU.
+ * The system has two Temperature Sensors.
+ * sensor0 is for CPU, and sensor1 is for GPU.
  */
 enum sensor_id {
-   SENSOR_CPU = 1,
+   SENSOR_CPU = 0,
SENSOR_GPU,
 };
 
+/**
+ * The max sensors is two in rockchip SoCs.
+ * Two sensors: CPU and GPU sensor.
+ */
+#define SOC_MAX_SENSORS2
+
 struct rockchip_tsadc_chip {
+   /* The sensor id of chip correspond to the ADC channel */
+   int chn_id[SOC_MAX_SENSORS];
+   int chn_num;
+
/* The hardware-controlled tshut property */
long tshut_temp;
enum tshut_mode tshut_mode;
@@ -72,17 +82,15 @@ struct rockchip_tsadc_chip {
 struct rockchip_thermal_sensor {
struct rockchip_thermal_data *thermal;
struct thermal_zone_device *tzd;
-   enum sensor_id id;
+   int id;
 };
 
-#define NUM_SENSORS2 /* Ignore unused sensor 0 */
-
 struct rockchip_thermal_data {
const struct rockchip_tsadc_chip *chip;
struct platform_device *pdev;
struct reset_control *reset;
 
-   struct rockchip_thermal_sensor sensors[NUM_SENSORS];
+   struct rockchip_thermal_sensor sensors[SOC_MAX_SENSORS];
 
struct clk *clk;
struct clk *pclk;
@@ -94,7 +102,7 @@ struct rockchip_thermal_data {
enum tshut_polarity tshut_polarity;
 };
 
-/* TSADC V2 Sensor info define: */
+/* TSADC Sensor info define: */
 #define TSADCV2_AUTO_CON   0x04
 #define TSADCV2_INT_EN 0x08
 #define TSADCV2_INT_PD 0x0c
@@ -317,6 +325,10 @@ static void rk_tsadcv2_tshut_mode(int chn, void __iomem 
*regs,
 }
 
 static const struct rockchip_tsadc_chip rk3288_tsadc_data = {
+   .chn_id[SENSOR_CPU] = 1, /* cpu sensor is channel 1 */
+   .chn_id[SENSOR_GPU] = 2, /* gpu sensor is channel 2 */
+   .chn_num = 2, /* two channels for tsadc */
+
.tshut_mode = TSHUT_MODE_GPIO, /* default TSHUT via GPIO give PMIC */
.tshut_polarity = TSHUT_LOW_ACTIVE, /* default TSHUT LOW ACTIVE */
.tshut_temp = 95000,
@@ -356,7 +368,7 @@ static irqreturn_t rockchip_thermal_alarm_irq_thread(int 
irq, void *dev)
 
thermal->chip->irq_ack(thermal->regs);
 
-   for (i = 0; i < ARRAY_SIZE(thermal->sensors); i++)
+   for (i = 0; i < thermal->chip->chn_num; i++)
thermal_zone_device_update(thermal->sensors[i].tzd);
 
return IRQ_HANDLED;
@@ -441,7 +453,7 @@ static int
 rockchip_thermal_register_sensor(struct platform_device *pdev,
 struct rockchip_thermal_data *thermal,
 struct rockchip_thermal_sensor *sensor,
-enum sensor_id id)
+int id)
 {
const struct rockchip_tsadc_chip *tsadc = thermal->chip;
int error;
@@ -480,7 +492,7 @@ static int rockchip_thermal_probe(struct platform_device 
*pdev)
const struct of_device_id *match;
struct resource *res;
int irq;
-   int i;
+   int i, j;
int error;
 
match = of_match_node(of_rockchip_thermal_match, np);
@@ -555,22 +567,19 @@ static int rockchip_thermal_probe(struct platform_device 
*pdev)
 
thermal->chip->initialize(thermal->regs, thermal->tshut_polarity);
 
-   error = rockchip_thermal_register_sensor(pdev, thermal,
->sensors[0],
-SENSOR_CPU);
-   if (error) {
-   dev_err(>dev,
-   "failed to register CPU thermal sensor: %d\n", error);
-   goto err_disable_pclk;
-   }
-
-   error = rockchip_thermal_register_sensor(pdev, thermal,
->sensors[1],
-SENSOR_GPU);
-   if (error) {
-   dev_err(>dev,
-   "failed to register GPU thermal sensor: %d\n", error);
-   goto err_unregister_cpu_sensor;
+   for (i = 0; i < thermal->chip->chn_num; i++) {
+   error = 

[PATCH v2 1/9] dt-bindings: rockchip-thermal: Support the RK3368 SoCs compatible

2015-11-04 Thread Caesar Wang
This patchset attempts to new compatible for thermal founding
on RK3368 SoCs.

Signed-off-by: Caesar Wang 
---

Changes in v2: None
Changes in v1:
- %s/thermal/rockchip-thermal in subject.

 Documentation/devicetree/bindings/thermal/rockchip-thermal.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt 
b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
index b38200d..0dfa60d 100644
--- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
@@ -1,7 +1,9 @@
 * Temperature Sensor ADC (TSADC) on rockchip SoCs
 
 Required properties:
-- compatible : "rockchip,rk3288-tsadc"
+- compatible : should be "rockchip,-tsadc"
+   "rockchip,rk3288-tsadc": found on RK3288 SoCs
+   "rockchip,rk3368-tsadc": found on RK3368 SoCs
 - reg : physical base address of the controller and length of memory mapped
region.
 - interrupts : The interrupt number to the cpu. The interrupt specifier format
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v2 3/9] thermal: rockchip: trivial: fix typo in commit

2015-11-04 Thread Caesar Wang
Signed-off-by: Caesar Wang 
---

Changes in v2:
- As Eduardo comments on patch v1, split in smaller changes.

Changes in v1: None

 drivers/thermal/rockchip_thermal.c | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/thermal/rockchip_thermal.c 
b/drivers/thermal/rockchip_thermal.c
index 075d18e..bdf7063 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -236,15 +236,19 @@ static int rk_tsadcv2_code_to_temp(u32 code, int *temp)
 }
 
 /**
- * rk_tsadcv2_initialize - initialize TASDC Controller
- * (1) Set TSADCV2_AUTO_PERIOD, configure the interleave between
- * every two accessing of TSADC in normal operation.
- * (2) Set TSADCV2_AUTO_PERIOD_HT, configure the interleave between
- * every two accessing of TSADC after the temperature is higher
- * than COM_SHUT or COM_INT.
- * (3) Set TSADCV2_HIGH_INT_DEBOUNCE and TSADC_HIGHT_TSHUT_DEBOUNCE,
- * if the temperature is higher than COMP_INT or COMP_SHUT for
- * "debounce" times, TSADC controller will generate interrupt or TSHUT.
+ * rk_tsadcv2_initialize - initialize TASDC Controller.
+ *
+ * (1) Set TSADC_V2_AUTO_PERIOD:
+ * Configure the interleave between every two accessing of
+ * TSADC in normal operation.
+ *
+ * (2) Set TSADCV2_AUTO_PERIOD_HT:
+ * Configure the interleave between every two accessing of
+ * TSADC after the temperature is higher than COM_SHUT or COM_INT.
+ *
+ * (3) Set TSADCV2_HIGH_INT_DEBOUNCE and TSADC_HIGHT_TSHUT_DEBOUNCE:
+ * If the temperature is higher than COMP_INT or COMP_SHUT for
+ * "debounce" times, TSADC controller will generate interrupt or TSHUT.
  */
 static void rk_tsadcv2_initialize(void __iomem *regs,
  enum tshut_polarity tshut_polarity)
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v2 0/9] Better compatible for the rockchip thermal and support RK3368 SoCs

2015-11-04 Thread Caesar Wang
This series patchs are working for RK3368 on Rockchip platform.

@Heiko,
The PATCH [5/6] is working based on big/littel cluster cpufreq
added. Anyway, the PATCH [5/6] also work for next kernel.

@Eduardo,
This patchset are based on linus master branch.
Note: Need add the following thermal patchs for thermal driver before apply
this series patchs.

1) thermal: rockchip: fix handling of invalid readings
(https://patchwork.kernel.org/patch/6973101/)

2) thermal: rockhip: fix setting thermal shutdown polarity
(https://patchwork.kernel.org/patch/6973131/)

3) dt-bindings: rockchip-thermal: Add the pinctrl states in this document
(https://patchwork.kernel.org/patch/7472021/)

4) thermal: rockchip: support the sleep pinctrl state to avoid glitches in s2r
(https://patchwork.kernel.org/patch/7472051/)

I'm glad these patchs have merged in thermal-soc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git

the git log oneline my local branch as follows:
3e2c90b arm64: dts: Enable the Thermal on R88 board
a33ee26 arm64: dts: Add main Thermal info to rk3368.dtsi
fc051c9 arm64: dts: Add the thermal data found on RK3368
d6e7126 thermal: rockchip: Support the RK3368 SoCs in thermal drivers
d16eb7f thermal: rockchip: Add the flag for adc value increment or decrement
acc3ead thermal: rockchip: improve the conversion function
f295e0b thermal: rockchip: trivial: fix typo in commit
2291fc3 thermal: rockchip: better to compatible the driver for different SoCs
e18e646 dt-bindings: rockchip-thermal: Support the RK3368 SoCs compatible

29eb0c7 thermal: rockchip: support the sleep pinctrl state to avoid glitches in 
s2r
cf2100b dt-bindings: rockchip-thermal: Add the pinctrl states in this document
38e287b0 thermal: rockhip: fix setting thermal shutdown polarity
ddee4a2 thermal: rockchip: fix handling of invalid readings
8a28d67 Merge tag 'powerpc-4.3-6' of
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
977bf06 powerpc/dma: dma_set_coherent_mask() should not be GPL only
a22c4d7 block: re-add discard_granularity and alignment checks
23d8827 Merge branch 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm
3d0aa36 Merge branch 'for-linus' of git://git.kernel.dk/linux-block
dc5bc3f Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
9e17f90 Merge tag 'fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux
174fd8d blkcg: fix incorrect read/write sync/async stat accounting
858e904 Merge tag 'iommu-fixes-v4.3-rc7' of
..


This series are tested on RK3368 board.

while true;do ls >/dev/null; done&

while true; do grep "" /sys/class/thermal/thermal_zone[0-1]/temp; sleep .5; 
done &

You can get the temperature form sensors.
/sys/class/thermal/thermal_zone0/temp:27500
/sys/class/thermal/thermal_zone1/temp:3
/sys/class/thermal/thermal_zone0/temp:3
/sys/class/thermal/thermal_zone1/temp:3
/sys/class/thermal/thermal_zone0/temp:27500
/sys/class/thermal/thermal_zone1/temp:3
/sys/class/thermal/thermal_zone0/temp:3
/sys/class/thermal/thermal_zone1/temp:3
/sys/class/thermal/thermal_zone0/temp:25000
/sys/class/thermal/thermal_zone1/temp:3
/sys/class/thermal/thermal_zone0/temp:32500
/sys/class/thermal/thermal_zone1/temp:3
/sys/class/thermal/thermal_zone0/temp:3
/sys/class/thermal/thermal_zone1/temp:3
/sys/class/thermal/thermal_zone0/temp:22500
/sys/class/thermal/thermal_zone1/temp:32500
/sys/class/thermal/thermal_zone0/temp:25000
/sys/class/thermal/thermal_zone1/temp:3
/sys/class/thermal/thermal_zone0/temp:25000
/sys/class/thermal/thermal_zone1/temp:3
/sys/class/thermal/thermal_zone0/temp:22500
/sys/class/thermal/thermal_zone1/temp:3
/sys/class/thermal/thermal_zone0/temp:3
/sys/class/thermal/thermal_zone1/temp:32500
/sys/class/thermal/thermal_zone1/temp:32500
/sys/class/thermal/thermal_zone0/temp:32500


Changes in v2:
- As Eduardo comments on patch v1, split in smaller changes.
- make the conversion table in as a parameter both code_to_temp
  and temp_to_code function.
Series-changes: 1
- As Dmitry comment, make the conversion table in as a parameter.
- remove some unused, completed on other patchs.
- fix a copy wrong name.
Series-changes: 1
- support the opt gpio pinctrl state

Changes in v1:
- %s/thermal/rockchip-thermal in subject.
- add a new patch for thermal driver to support more SoCs.

Caesar Wang (9):
  dt-bindings: rockchip-thermal: Support the RK3368 SoCs compatible
  thermal: rockchip: better to compatible the driver for different SoCs
  thermal: rockchip: trivial: fix typo in commit
  thermal: rockchip: improve the conversion function
  thermal: rockchip: Add the flag for adc value increment or decrement
  thermal: rockchip: Support the RK3368 SoCs in thermal drivers
  arm64: dts: Add the thermal data found on RK3368
  arm64: dts: Add main Thermal info to rk3368.dtsi
  arm64: dts: Enable the Thermal on R88 board

 

Re: [PATCH v4 04/11] lsm: inode_pre_setxattr hook

2015-11-04 Thread John Johansen
On 10/14/2015 05:41 AM, Lukasz Pawelczyk wrote:
> Add a new LSM hook called before inode's setxattr. It is required for
> LSM to be able to reliably replace the xattr's value to be set to
> filesystem in __vfs_setxattr_noperm(). Useful for mapped values, like in
> the upcoming Smack namespace patches.
> 
> Signed-off-by: Lukasz Pawelczyk 
> Acked-by: Serge Hallyn 
Acked-by: John Johansen 

> ---
>  fs/xattr.c| 10 ++
>  include/linux/lsm_hooks.h |  9 +
>  include/linux/security.h  | 10 ++
>  security/security.c   | 12 
>  4 files changed, 41 insertions(+)
> 
> diff --git a/fs/xattr.c b/fs/xattr.c
> index 072fee1..cbc8d19 100644
> --- a/fs/xattr.c
> +++ b/fs/xattr.c
> @@ -100,12 +100,22 @@ int __vfs_setxattr_noperm(struct dentry *dentry, const 
> char *name,
>   if (issec)
>   inode->i_flags &= ~S_NOSEC;
>   if (inode->i_op->setxattr) {
> + bool alloc = false;
> +
> + error = security_inode_pre_setxattr(dentry, name, ,
> + , flags, );
> + if (error)
> + return error;
> +
>   error = inode->i_op->setxattr(dentry, name, value, size, flags);
>   if (!error) {
>   fsnotify_xattr(dentry);
>   security_inode_post_setxattr(dentry, name, value,
>size, flags);
>   }
> +
> + if (alloc)
> + kfree(value);
>   } else if (issec) {
>   const char *suffix = name + XATTR_SECURITY_PREFIX_LEN;
>   error = security_inode_setsecurity(inode, suffix, value,
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index 4f16640..85bfdde 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -349,6 +349,11 @@
>   *   Check permission before setting the extended attributes
>   *   @value identified by @name for @dentry.
>   *   Return 0 if permission is granted.
> + * @inode_pre_setxattr:
> + *   Be able to do some operation before setting the @value identified
> + *   by @name on the filesystem. Replacing the @value and its @size is
> + *   possible. Useful for mapped values. Set @alloc to true if @value
> + *   needs to be kfreed afterwards.
>   * @inode_post_setxattr:
>   *   Update inode security field after successful setxattr operation.
>   *   @value identified by @name for @dentry.
> @@ -1448,6 +1453,9 @@ union security_list_options {
>   int (*inode_getattr)(const struct path *path);
>   int (*inode_setxattr)(struct dentry *dentry, const char *name,
>   const void *value, size_t size, int flags);
> + int (*inode_pre_setxattr)(struct dentry *dentry, const char *name,
> +   const void **value, size_t *size,
> +   int flags, bool *alloc);
>   void (*inode_post_setxattr)(struct dentry *dentry, const char *name,
>   const void *value, size_t size,
>   int flags);
> @@ -1730,6 +1738,7 @@ struct security_hook_heads {
>   struct list_head inode_setattr;
>   struct list_head inode_getattr;
>   struct list_head inode_setxattr;
> + struct list_head inode_pre_setxattr;
>   struct list_head inode_post_setxattr;
>   struct list_head inode_getxattr;
>   struct list_head inode_listxattr;
> diff --git a/include/linux/security.h b/include/linux/security.h
> index 12bd011..4de4865 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -263,6 +263,9 @@ int security_inode_setattr(struct dentry *dentry, struct 
> iattr *attr);
>  int security_inode_getattr(const struct path *path);
>  int security_inode_setxattr(struct dentry *dentry, const char *name,
>   const void *value, size_t size, int flags);
> +int security_inode_pre_setxattr(struct dentry *dentry, const char *name,
> + const void **value, size_t *size, int flags,
> + bool *alloc);
>  void security_inode_post_setxattr(struct dentry *dentry, const char *name,
> const void *value, size_t size, int flags);
>  int security_inode_getxattr(struct dentry *dentry, const char *name);
> @@ -691,6 +694,13 @@ static inline int security_inode_setxattr(struct dentry 
> *dentry,
>   return cap_inode_setxattr(dentry, name, value, size, flags);
>  }
>  
> +static inline int security_inode_pre_setxattr(struct dentry *dentry,
> + const char *name, const void **value,
> + size_t *size, int flags, bool *alloc)
> +{
> + return 0;
> +}
> +
>  static inline void security_inode_post_setxattr(struct dentry *dentry,
>   const char *name, const void *value, size_t size, int flags)
>  { }
> diff --git 

Re: [PATCH] PCI: pciehp: Always protect pciehp_disable_slot() with hotplug mutex

2015-11-04 Thread Guenter Roeck

On 11/04/2015 06:59 PM, Rajat Jain wrote:

Geez... I wonder how did I miss it. Thanks for fixing this.
Looks good to me.


Hi Rajat,

easy to miss. I only found it accidentally.

Thanks a lot for the review!

Guenter


Reviewed-by: Rajat Jain mailto:rajatxj...@gmail.com>>

On Sun, Nov 1, 2015 at 1:58 PM, Guenter Roeck mailto:li...@roeck-us.net>> wrote:

When called from pciehp_sysfs_disable_slot(), the call to
pciehp_disable_slot() was not protected by the hotplug mutex.

Cc: Rajat Jain mailto:rajatxj...@gmail.com>>
Signed-off-by: Guenter Roeck mailto:li...@roeck-us.net>>
---
  drivers/pci/hotplug/pciehp_ctrl.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/pci/hotplug/pciehp_ctrl.c 
b/drivers/pci/hotplug/pciehp_ctrl.c
index 4c8f4cde6854..880978b6d534 100644
--- a/drivers/pci/hotplug/pciehp_ctrl.c
+++ b/drivers/pci/hotplug/pciehp_ctrl.c
@@ -511,7 +511,9 @@ int pciehp_sysfs_disable_slot(struct slot *p_slot)
 case STATIC_STATE:
 p_slot->state = POWEROFF_STATE;
 mutex_unlock(_slot->lock);
+   mutex_lock(_slot->hotplug_lock);
 retval = pciehp_disable_slot(p_slot);
+   mutex_unlock(_slot->hotplug_lock);
 mutex_lock(_slot->lock);
 p_slot->state = STATIC_STATE;
 break;
--
2.1.4




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [Linaro-acpi] [PATCH v8 5/5] Watchdog: introduce ARM SBSA watchdog driver

2015-11-04 Thread Guenter Roeck

On 11/04/2015 05:59 PM, Timur Tabi wrote:

On Tue, Oct 27, 2015 at 11:06 AM,   wrote:

+static irqreturn_t sbsa_gwdt_interrupt(int irq, void *dev_id)
+{
+   struct sbsa_gwdt *gwdt = (struct sbsa_gwdt *)dev_id;
+   struct watchdog_device *wdd = >wdd;
+
+   /* We don't use pretimeout, trigger WS1 now */
+   if (!wdd->pretimeout)
+   sbsa_gwdt_set_wcv(wdd, 0);


So I'm still concerned about the fact this driver depends on an
interrupt handler in order to properly program the hardware.  Unlike
some other devices, the SBSA watchdog does not need assistance to
reset on a timeout -- it is a "fire and forget" device.  What happens
if there is a hard lockup, and interrupts no longer work?

Keep in mind that 99% of watchdog daemons will not enable the
pre-timeout feature because it's new.


Same here, really.

I would feel much more comfortable if the driver would just use the standard
watchdog timeout and live with (worst case) 20 seconds timeout for now.
This limitation will be gone once the infrastructure is in place to handle
such short timeouts in the watchdog core. Until then, I would argue that the
system designers asked for it if they really select the highest possible
clock rate.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH cgroup/for-4.4-fixes] cgroup: fix cftype->file_offset handling

2015-11-04 Thread Tejun Heo
6f60eade2433 ("cgroup: generalize obtaining the handles of and
notifying cgroup files") introduced cftype->file_offset so that the
handles for per-css file instances can be recorded.  These handles
then can be used, for example, to generate file modified
notifications.

Unfortunately, it made the wrong assumption that files are created
once for a given css and removed on its destruction.  Due to the
dependencies among subsystems, a css may be hidden from userland and
then later shown again.  This is implemented by removing and
re-creating the affected files, so the associated kernfs_node for a
given cgroup file may change over time.  This incorrect assumption led
to the corruption of css->files lists.

Reimplement cftype->file_offset handling so that cgroup_file->kn is
protected by a lock and updated as files are created and destroyed.
This also makes keeping them on per-cgroup list unnecessary.

Signed-off-by: Tejun Heo 
Reported-by: James Sedgwick 
Fixes: 6f60eade2433 ("cgroup: generalize obtaining the handles of and notifying 
cgroup files")
---
 include/linux/cgroup-defs.h |4 
 include/linux/cgroup.h  |   14 +-
 kernel/cgroup.c |   42 ++
 3 files changed, 35 insertions(+), 25 deletions(-)

--- a/include/linux/cgroup-defs.h
+++ b/include/linux/cgroup-defs.h
@@ -90,7 +90,6 @@ enum {
  */
 struct cgroup_file {
/* do not access any fields from outside cgroup core */
-   struct list_head node;  /* anchored at css->files */
struct kernfs_node *kn;
 };
 
@@ -134,9 +133,6 @@ struct cgroup_subsys_state {
 */
u64 serial_nr;
 
-   /* all cgroup_files associated with this css */
-   struct list_head files;
-
/* percpu_ref killing and RCU release */
struct rcu_head rcu_head;
struct work_struct destroy_work;
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -88,6 +88,7 @@ int cgroup_transfer_tasks(struct cgroup
 int cgroup_add_dfl_cftypes(struct cgroup_subsys *ss, struct cftype *cfts);
 int cgroup_add_legacy_cftypes(struct cgroup_subsys *ss, struct cftype *cfts);
 int cgroup_rm_cftypes(struct cftype *cfts);
+void cgroup_file_notify(struct cgroup_file *cfile);
 
 char *task_cgroup_path(struct task_struct *task, char *buf, size_t buflen);
 int cgroupstats_build(struct cgroupstats *stats, struct dentry *dentry);
@@ -516,19 +517,6 @@ static inline void pr_cont_cgroup_path(s
pr_cont_kernfs_path(cgrp->kn);
 }
 
-/**
- * cgroup_file_notify - generate a file modified event for a cgroup_file
- * @cfile: target cgroup_file
- *
- * @cfile must have been obtained by setting cftype->file_offset.
- */
-static inline void cgroup_file_notify(struct cgroup_file *cfile)
-{
-   /* might not have been created due to one of the CFTYPE selector flags 
*/
-   if (cfile->kn)
-   kernfs_notify(cfile->kn);
-}
-
 #else /* !CONFIG_CGROUPS */
 
 struct cgroup_subsys_state;
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -98,6 +98,12 @@ static DEFINE_SPINLOCK(css_set_lock);
 static DEFINE_SPINLOCK(cgroup_idr_lock);
 
 /*
+ * Protects cgroup_file->kn for !self csses.  It synchronizes notifications
+ * against file removal/re-creation across css hiding.
+ */
+static DEFINE_SPINLOCK(cgroup_file_kn_lock);
+
+/*
  * Protects cgroup_subsys->release_agent_path.  Modifying it also requires
  * cgroup_mutex.  Reading requires either cgroup_mutex or this spinlock.
  */
@@ -1393,6 +1399,16 @@ static void cgroup_rm_file(struct cgroup
char name[CGROUP_FILE_NAME_MAX];
 
lockdep_assert_held(_mutex);
+
+   if (cft->file_offset) {
+   struct cgroup_subsys_state *css = cgroup_css(cgrp, cft->ss);
+   struct cgroup_file *cfile = (void *)css + cft->file_offset;
+
+   spin_lock_irq(_file_kn_lock);
+   cfile->kn = NULL;
+   spin_unlock_irq(_file_kn_lock);
+   }
+
kernfs_remove_by_name(cgrp->kn, cgroup_file_name(cgrp, cft, name));
 }
 
@@ -1856,7 +1872,6 @@ static void init_cgroup_housekeeping(str
 
INIT_LIST_HEAD(>self.sibling);
INIT_LIST_HEAD(>self.children);
-   INIT_LIST_HEAD(>self.files);
INIT_LIST_HEAD(>cset_links);
INIT_LIST_HEAD(>pidlists);
mutex_init(>pidlist_mutex);
@@ -3313,9 +3328,9 @@ static int cgroup_add_file(struct cgroup
if (cft->file_offset) {
struct cgroup_file *cfile = (void *)css + cft->file_offset;
 
-   kernfs_get(kn);
+   spin_lock_irq(_file_kn_lock);
cfile->kn = kn;
-   list_add(>node, >files);
+   spin_unlock_irq(_file_kn_lock);
}
 
return 0;
@@ -3553,6 +3568,22 @@ int cgroup_add_legacy_cftypes(struct cgr
 }
 
 /**
+ * cgroup_file_notify - generate a file modified event for a cgroup_file
+ * @cfile: target cgroup_file
+ *
+ * @cfile must have been obtained by setting cftype->file_offset.
+ */
+void 

Re: [PATCH v1 11/20] ARC: [plat-eznps] Add eznps platform

2015-11-04 Thread Vineet Gupta
On Saturday 31 October 2015 06:45 PM, Noam Camus wrote:
> From: Noam Camus 
> 
> This platform include boards:
>   Hardware Emulator (HE)
>   Simulator based upon nSIM.
> 
> Signed-off-by: Noam Camus 
> ---
>  MAINTAINERS |6 +
>  arch/arc/plat-eznps/Kconfig |   34 
>  arch/arc/plat-eznps/Makefile|7 +
>  arch/arc/plat-eznps/entry.S |   76 +
>  arch/arc/plat-eznps/include/plat/ctop.h |  264 
> +++
>  arch/arc/plat-eznps/include/plat/mtm.h  |   60 +++
>  arch/arc/plat-eznps/include/plat/smp.h  |   27 +++
>  arch/arc/plat-eznps/mtm.c   |  152 ++
>  arch/arc/plat-eznps/platform.c  |   40 +
>  arch/arc/plat-eznps/smp.c   |  160 +++
>  10 files changed, 826 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arc/plat-eznps/Kconfig
>  create mode 100644 arch/arc/plat-eznps/Makefile
>  create mode 100644 arch/arc/plat-eznps/entry.S
>  create mode 100644 arch/arc/plat-eznps/include/plat/ctop.h
>  create mode 100644 arch/arc/plat-eznps/include/plat/mtm.h
>  create mode 100644 arch/arc/plat-eznps/include/plat/smp.h
>  create mode 100644 arch/arc/plat-eznps/mtm.c
>  create mode 100644 arch/arc/plat-eznps/platform.c
>  create mode 100644 arch/arc/plat-eznps/smp.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 08adb4a..c63ca18 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4171,6 +4171,12 @@ S: Maintained
>  F:   drivers/video/fbdev/exynos/exynos_mipi*
>  F:   include/video/exynos_mipi*
>  
> +EZchip NPS platform support
> +M:   Noam Camus 
> +S:   Supported
> +F:   arch/arc/plat-eznps
> +F:   arch/arc/boot/dts/eznps.dts
> +
>  F71805F HARDWARE MONITORING DRIVER
>  M:   Jean Delvare 
>  L:   lm-sens...@lm-sensors.org
> diff --git a/arch/arc/plat-eznps/Kconfig b/arch/arc/plat-eznps/Kconfig
> new file mode 100644
> index 000..510354f
> --- /dev/null
> +++ b/arch/arc/plat-eznps/Kconfig
> @@ -0,0 +1,34 @@
> +#
> +# For a description of the syntax of this configuration file,
> +# see Documentation/kbuild/kconfig-language.txt.
> +#
> +
> +menuconfig ARC_PLAT_EZNPS
> + bool "\"EZchip\" ARC dev platform"
> + select ARC_HAS_COH_CACHES if SMP
> + select CPU_BIG_ENDIAN
> + select CLKSRC_OF
> + select EZCHIP_NPS_MANAGEMENT_ENET if ETHERNET
> + help
> +   Support for EZchip development platforms,
> +   based on ARC700 cores.
> +   We handle few flavours:
> + - Hardware Emulator AKA HE which is FPGA based chasis
> + - Simulator based on MetaWare nSIM
> + - NPS400 chip based on ASIC
> +
> +config EZNPS_MTM_EXT
> + bool "ARC-EZchip MTM Extensions"
> + select CPUMASK_OFFSTACK
> + depends on ARC_PLAT_EZNPS && SMP
> + default y
> + help
> +   Here we add new hierarchy for CPUs topology.
> +   We got:
> + Core
> + Thread
> +   At the new thread level each CPU represent one HW thread.
> +   At highest hierarchy each core contain 16 threads,
> +   any of them seem like CPU from Linux point of view.
> +   All threads within same core share the execution unit of the
> +   core and HW scheduler round robin between them.
> diff --git a/arch/arc/plat-eznps/Makefile b/arch/arc/plat-eznps/Makefile
> new file mode 100644
> index 000..21091b1
> --- /dev/null
> +++ b/arch/arc/plat-eznps/Makefile
> @@ -0,0 +1,7 @@
> +#
> +# Makefile for the linux kernel.
> +#
> +
> +obj-y := entry.o platform.o
> +obj-$(CONFIG_SMP) += smp.o
> +obj-$(CONFIG_EZNPS_MTM_EXT) += mtm.o
> diff --git a/arch/arc/plat-eznps/entry.S b/arch/arc/plat-eznps/entry.S
> new file mode 100644
> index 000..a3dec3e
> --- /dev/null
> +++ b/arch/arc/plat-eznps/entry.S
> @@ -0,0 +1,76 @@
> +/***
> +
> +  EZNPS CPU startup Code
> +  Copyright(c) 2012 EZchip Technologies.
> +
> +  This program is free software; you can redistribute it and/or modify it
> +  under the terms and conditions of the GNU General Public License,
> +  version 2, as published by the Free Software Foundation.
> +
> +  This program is distributed in the hope 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.
> +
> +  The full GNU General Public License is included in this distribution in
> +  the file called "COPYING".
> +
> +***/
> +#include 
> +#include 
> +#include 
> +#include 
> +
> + .cpu A7
> +
> + .section .text, "ax",@progbits
> + .align 1024 ; HW requierment for restart first PC
> +
> +ENTRY(res_service)
> +#ifdef CONFIG_EZNPS_MTM_EXT
> + ; For HW thread != 0 there is no work.
> + lr  r3, [CTOP_AUX_THREAD_ID]
> + cmp r3, 0
> + 

Re: [PATCH] bpf: add mod default A and X test cases

2015-11-04 Thread David Miller
From: Yang Shi 
Date: Wed,  4 Nov 2015 11:36:37 -0800

> When running "mod X" operation, if X is 0 the filter has to be halt.
> Add new test cases to cover A = A mod X if X is 0, and A = A mod 1.
> 
> CC: Xi Wang 
> CC: Zi Shen Lim 
> Signed-off-by: Yang Shi 

Applied, thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] __div64_32: implement division by multiplication for 32-bit arches

2015-11-04 Thread Nicolas Pitre
On Thu, 5 Nov 2015, Vineet Gupta wrote:

> On Thursday 05 November 2015 05:18 AM, Nicolas Pitre wrote:
> > On Wed, 4 Nov 2015, Nicolas Pitre wrote:
> >
> >> On Fri, 30 Oct 2015, Måns Rullgård wrote:
> >>
> >>> Nicolas Pitre  writes:
> >>>
>  I'm going to do it anyway given that I already have it for ARM.  It'll 
>  be opt-in, so if your arch doesn't provide it then the current C 
>  implementation will be used by default.
> >>> Great.  I'll try it out on MIPS once you've posted the patch.
> >> You should have seen the patches by now.
> >>
> >> I've put them along with a bunch of do_div() usage fixes here:
> >>
> >>   http://git.linaro.org/people/nicolas.pitre/linux.git
> > More precisely:
> >
> >   http://git.linaro.org/people/nicolas.pitre/linux.git div64
> 
> Hi Nico,
> 
> While we are current on the topic I was wondering about another optimization 
> in
> this area.
> The slowpath __div64_32() generates both quotient and remainder. The more 
> general
> use case in kernel only cares about quotient.
> 
> git grep "\sdo_div(" |  wc -l
> 841
> git grep "=\sdo_div(" |  wc -l
> 116
> 
> Is it possible to optimize the code, if remainder was *not* needed 
> explicitly. I
> understand that the hand divide will still need some sort of running tally of
> remainder but can the code be any better in this case. That way we can 
> introduce
> another API do_div_norem() and start proliferating it for the cases where
> remainder is not used.

I don't think you'll be able to optimize the code much.  If you look at 
the division loop, you always have the current remainder to process as 
you say, so when you can't substract from the remainder anymore you 
simply return that value.  And on ARM we simply tell the calling code 
about which register contains the remainder if it wants it.  Therefore 
on ARM the code would be exactly the same in either cases.


Nicolas

Re: [PATCH] alarmtimer: fix unexpected rtc interrupt when system resume

2015-11-04 Thread kbuild test robot
Hi zhuo-hao,

[auto build test ERROR on: tip/timers/core]
[also build test ERROR on: v4.3 next-20151104]

url:
https://github.com/0day-ci/linux/commits/zhuo-hao-lee-intel-com/alarmtimer-fix-unexpected-rtc-interrupt-when-system-resume/20151105-124811
config: i386-randconfig-x009-11010709 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   kernel/time/alarmtimer.c: In function 'alarmtimer_resume':
>> kernel/time/alarmtimer.c:280:9: error: void value not ignored as it ought to 
>> be
 return rtc ? rtc_timer_cancel(rtc, ) : 0;
^
>> kernel/time/alarmtimer.c:281:1: warning: control reaches end of non-void 
>> function [-Wreturn-type]
}
^

vim +280 kernel/time/alarmtimer.c

   274  
   275  static int alarmtimer_resume(struct device *dev)
   276  {
   277  struct rtc_device *rtc;
   278  
   279  rtc = alarmtimer_get_rtcdev();
 > 280  return rtc ? rtc_timer_cancel(rtc, ) : 0;
 > 281  }
   282  
   283  #else
   284  static int alarmtimer_suspend(struct device *dev)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


linux-next: build failure after merge of the thermal-soc tree

2015-11-04 Thread Stephen Rothwell
Hi Eduardo,

After merging the thermal-soc tree, today's linux-next build (powerpc
allyesconfig) failed like this:

drivers/thermal/rockchip_thermal.c: In function 'rockchip_thermal_suspend':
drivers/thermal/rockchip_thermal.c:641:2: error: implicit declaration of 
function 'pinctrl_pm_select_sleep_state' [-Werror=implicit-function-declaration]
  pinctrl_pm_select_sleep_state(dev);
  ^
drivers/thermal/rockchip_thermal.c: In function 'rockchip_thermal_resume':
drivers/thermal/rockchip_thermal.c:679:2: error: implicit declaration of 
function 'pinctrl_pm_select_default_state' 
[-Werror=implicit-function-declaration]
  pinctrl_pm_select_default_state(dev);
  ^

Caused by commit

  7e38a5b1daa1 ("thermal: rockchip: support the sleep pinctrl state to avoid 
glitches")

Probably just a missing include file.

I have reverted that commit for today.



-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] bnxt_en: add VXLAN dependency

2015-11-04 Thread David Miller
From: Arnd Bergmann 
Date: Wed, 04 Nov 2015 16:00:32 +0100

> VXLAN may be a loadable module, and this driver cannot be built-in
> in that case, or we get a link error:
> 
> drivers/built-in.o: In function `__bnxt_open_nic':
> drivers/net/ethernet/broadcom/bnxt/bnxt.c:4581: undefined reference to 
> `vxlan_get_rx_port'
> 
> This adds a Kconfig dependency that ensures that either VXLAN is
> disabled (which the driver handles correctly), or we depend on
> VXLAN itself and disallow built-in compilation when VXLAN is
> a module.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v1 3/6] thermal: rockchip: Support the RK3368 SoCs in thermal driver

2015-11-04 Thread Caesar Wang

Hello Eduardo,

Thanks your comments.

在 2015年11月04日 01:48, Eduardo Valentin 写道:

Hello Caesar,

On Thu, Oct 29, 2015 at 03:14:15PM +0800, Caesar Wang wrote:

The RK3368 SoCs support to 2 channel TS-ADC, the temperature criteria
of each channel can be configurable.

The system has two Temperature Sensors, channel 0 is for CPU,
and channel 1 is for GPU.

Please improve your patch description. I dont think this patch only
adds the support for RK3368.

I see, for example, at least two other (maybe dependencies of the
new chip support) changes:

- conversion function improvement
- tshut value/temperature configuration

Could you please split this patch in smaller changes?


Okay, Done.

That's on my local oneline.
92ffb82 thermal: rockchip: Support the RK3368 SoCs in thermal drivers
e4f5e61 thermal: rockchip: Add the flag for adc value increment or decrement
b599a6b thermal: rockchip: improve the conversion function
d629c52 thermal: rockchip: trivial: fix typo in commit

I will send these in next version.


Signed-off-by: Caesar Wang 

---

Changes in v1:
- As Dmitry comment, make the conversion table in as a parameter.


Are you sure that this version implements this suggestion?



  drivers/thermal/rockchip_thermal.c | 183 -
  1 file changed, 158 insertions(+), 25 deletions(-)

diff --git a/drivers/thermal/rockchip_thermal.c 
b/drivers/thermal/rockchip_thermal.c
index f96c151..4748a8e 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -1,6 +1,9 @@
  /*
   * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
   *
+ * Copyright (c) 2015, Fuzhou Rockchip Electronics Co., Ltd
+ * Caesar Wang 
+ *
   * This program is free software; you can redistribute it and/or modify it
   * under the terms and conditions of the GNU General Public License,
   * version 2, as published by the Free Software Foundation.
@@ -75,8 +78,12 @@ struct rockchip_tsadc_chip {
  
  	/* Per-sensor methods */

int (*get_temp)(int chn, void __iomem *reg, int *temp);
-   void (*set_tshut_temp)(int chn, void __iomem *reg, long temp);
+   void (*set_tshut_value)(int chn, void __iomem *reg, u32 value);

Do you have any explanation why do you need to change from temp to
value? Can you include this in your patch description?


Okay,  I think that's *not* really needed.
I have removed this change.


void (*set_tshut_mode)(int chn, void __iomem *reg, enum tshut_mode m);
+
+   /* Per-table methods */
+   const struct tsadc_table *table;
+   int table_num;
  };
  
  struct rockchip_thermal_sensor {

@@ -102,7 +109,7 @@ struct rockchip_thermal_data {
enum tshut_polarity tshut_polarity;
  };
  
-/* TSADC V2 Sensor info define: */

+/* TSADC Sensor info define: */
  #define TSADCV2_AUTO_CON  0x04
  #define TSADCV2_INT_EN0x08
  #define TSADCV2_INT_PD0x0c
@@ -124,6 +131,8 @@ struct rockchip_thermal_data {
  #define TSADCV2_INT_PD_CLEAR_MASK ~BIT(8)
  
  #define TSADCV2_DATA_MASK			0xfff

+#define TSADCV3_DATA_MASK  0x3ff
+
  #define TSADCV2_HIGHT_INT_DEBOUNCE_COUNT  4
  #define TSADCV2_HIGHT_TSHUT_DEBOUNCE_COUNT4
  #define TSADCV2_AUTO_PERIOD_TIME  250 /* msec */
@@ -172,21 +181,62 @@ static const struct tsadc_table v2_code_table[] = {
{3421, 125000},
  };
  
-static u32 rk_tsadcv2_temp_to_code(long temp)

+static const struct tsadc_table v3_code_table[] = {
+   {0, -4},
+   {106, -4},
+   {108, -35000},
+   {110, -3},
+   {112, -25000},
+   {114, -2},
+   {116, -15000},
+   {118, -1},
+   {120, -5000},
+   {122, 0},
+   {124, 5000},
+   {126, 1},
+   {128, 15000},
+   {130, 2},
+   {132, 25000},
+   {134, 3},
+   {136, 35000},
+   {138, 4},
+   {140, 45000},
+   {142, 5},
+   {144, 55000},
+   {146, 6},
+   {148, 65000},
+   {150, 7},
+   {152, 75000},
+   {154, 8},
+   {156, 85000},
+   {158, 9},
+   {160, 95000},
+   {162, 10},
+   {163, 105000},
+   {165, 11},
+   {167, 115000},
+   {169, 12},
+   {171, 125000},
+   {TSADCV3_DATA_MASK, 125000},
+};
+
+static u32 rk_tsadcv2_temp_to_code(const struct rockchip_tsadc_chip *chip,
+  long temp)
  {

This function receives the chip structure as parameter...


Okay, we should do the table as a parameter.


+   const struct tsadc_table *table = chip->table;
int high, low, mid;
  
  	low = 0;

-   high = ARRAY_SIZE(v2_code_table) - 1;
+   high = chip->table_num - 1;
mid = (high + low) / 2;
  
-	if (temp < v2_code_table[low].temp || temp > v2_code_table[high].temp)

+   if (temp < table[low].temp || temp > table[high].temp)
return 0;
  
  	while (low <= high) 

[PATCH 2/4] scsi: mpt3sas: try 64 bit DMA when 32 bit DMA fails

2015-11-04 Thread Sinan Kaya
Current code gives up when 32 bit DMA is not supported.
This patch tests 64 bit support before bailing out in
such conditions.

Signed-off-by: Sinan Kaya 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index d4f1dcd..6dc391c 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -1535,9 +1535,29 @@ _base_config_dma_addressing(struct MPT3SAS_ADAPTER *ioc, 
struct pci_dev *pdev)
ioc->base_add_sg_single = &_base_add_sg_single_32;
ioc->sge_size = sizeof(Mpi2SGESimple32_t);
ioc->dma_mask = 32;
-   } else
+   } else {
+   /* Try 64 bit, 32 bit failed */
+   consistent_dma_mask = DMA_BIT_MASK(64);
+   if (sizeof(dma_addr_t) > 4) {
+   const uint64_t required_mask =
+   dma_get_required_mask(>dev);
+   int consistent_mask =
+   pci_set_consistent_dma_mask(pdev,
+   consistent_dma_mask);
+
+   if ((required_mask > DMA_BIT_MASK(32)) &&
+   !pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) &&
+   !consistent_mask) {
+   ioc->base_add_sg_single =
+   &_base_add_sg_single_64;
+   ioc->sge_size = sizeof(Mpi2SGESimple64_t);
+   ioc->dma_mask = 64;
+   goto out;
+   }
+   }
return -ENODEV;
 
+   }
  out:
si_meminfo();
pr_info(MPT3SAS_FMT
-- 
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 4/4] scsi: mptxsas: offload IRQ execution

2015-11-04 Thread Sinan Kaya
The mpt2sas and mpt3sas drivers are spinning
forever in their IRQ handlers if there is a lot
of job queued up by the PCIe card. This handler is
causing spikes for the rest of the system and
sluggish behavior.

Marking all MSI interrupts as non-shared and
moving the MSI interrupts to thread context.
This relexes the rest of the system execution.

Signed-off-by: Sinan Kaya 
---
 drivers/scsi/mpt2sas/mpt2sas_base.c | 13 +
 drivers/scsi/mpt3sas/mpt3sas_base.c | 14 ++
 2 files changed, 19 insertions(+), 8 deletions(-)
 mode change 100644 => 100755 drivers/scsi/mpt3sas/mpt3sas_base.c

diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c 
b/drivers/scsi/mpt2sas/mpt2sas_base.c
index c61c82a..ee2aead 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.c
@@ -1359,14 +1359,19 @@ _base_request_irq(struct MPT2SAS_ADAPTER *ioc, u8 
index, u32 vector)
cpumask_clear(reply_q->affinity_hint);
 
atomic_set(_q->busy, 0);
-   if (ioc->msix_enable)
+   if (ioc->msix_enable) {
snprintf(reply_q->name, MPT_NAME_LENGTH, "%s%d-msix%d",
MPT2SAS_DRIVER_NAME, ioc->id, index);
-   else
+   r = request_threaded_irq(vector, NULL, _base_interrupt,
+IRQF_TRIGGER_RISING | IRQF_ONESHOT,
+reply_q->name, reply_q);
+   }
+   else {
snprintf(reply_q->name, MPT_NAME_LENGTH, "%s%d",
MPT2SAS_DRIVER_NAME, ioc->id);
-   r = request_irq(vector, _base_interrupt, IRQF_SHARED, reply_q->name,
-   reply_q);
+   r = request_irq(vector, _base_interrupt, IRQF_SHARED,
+   reply_q->name, reply_q);
+   }
if (r) {
printk(MPT2SAS_ERR_FMT "unable to allocate interrupt %d!\n",
reply_q->name, vector);
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
old mode 100644
new mode 100755
index 6dc391c..c29f359
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -1661,14 +1661,20 @@ _base_request_irq(struct MPT3SAS_ADAPTER *ioc, u8 
index, u32 vector)
cpumask_clear(reply_q->affinity_hint);
 
atomic_set(_q->busy, 0);
-   if (ioc->msix_enable)
+   if (ioc->msix_enable) {
snprintf(reply_q->name, MPT_NAME_LENGTH, "%s%d-msix%d",
MPT3SAS_DRIVER_NAME, ioc->id, index);
-   else
+
+   r = request_threaded_irq(vector, NULL, _base_interrupt,
+IRQF_TRIGGER_RISING | IRQF_ONESHOT,
+reply_q->name, reply_q);
+   }
+   else {
snprintf(reply_q->name, MPT_NAME_LENGTH, "%s%d",
MPT3SAS_DRIVER_NAME, ioc->id);
-   r = request_irq(vector, _base_interrupt, IRQF_SHARED, reply_q->name,
-   reply_q);
+   r = request_irq(vector, _base_interrupt, IRQF_SHARED,
+   reply_q->name, reply_q);
+   }
if (r) {
pr_err(MPT3SAS_FMT "unable to allocate interrupt %d!\n",
reply_q->name, vector);
-- 
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3/4] scsi: fix compiler warning for sg

2015-11-04 Thread Sinan Kaya
The MULDIV macro has been designed for small
numbers. It emits an overflow warning on 64 bit
systems. This patch places type casts in the
parameters to fix the compiler warning.

Signed-off-by: Sinan Kaya 
---
 drivers/scsi/sg.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 9d7b7db..eb2739d 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -88,7 +88,10 @@ static void sg_proc_cleanup(void);
  * Of course an overflow is inavoidable if the result of muldiv doesn't fit
  * in 32 bits.
  */
-#define MULDIV(X,MUL,DIV) X % DIV) * MUL) / DIV) + ((X / DIV) * MUL))
+static inline u64 MULDIV(u64 X, u32 MUL, u32 DIV)
+{
+   return X % DIV) * MUL) / DIV) + ((X / DIV) * MUL));
+}
 
 #define SG_DEFAULT_TIMEOUT MULDIV(SG_DEFAULT_TIMEOUT_USER, HZ, USER_HZ)
 
-- 
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 1/4] scsi: mpt2sas: try 64 bit DMA when 32 bit DMA fails

2015-11-04 Thread Sinan Kaya
Current code gives up when 32 bit DMA is not supported.
This patch tests 64 bit support before bailing out in
such conditions.

Signed-off-by: Sinan Kaya 
---
 drivers/scsi/mpt2sas/mpt2sas_base.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c 
b/drivers/scsi/mpt2sas/mpt2sas_base.c
index c167911..c61c82a 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.c
@@ -1217,8 +1217,27 @@ _base_config_dma_addressing(struct MPT2SAS_ADAPTER *ioc, 
struct pci_dev *pdev)
ioc->base_add_sg_single = &_base_add_sg_single_32;
ioc->sge_size = sizeof(Mpi2SGESimple32_t);
ioc->dma_mask = 32;
-   } else
+   } else {
+   /* Try 64 bit, 32 bit failed */
+   consistent_dma_mask = DMA_BIT_MASK(64);
+
+   if (sizeof(dma_addr_t) > 4) {
+   const uint64_t required_mask =
+   dma_get_required_mask(>dev);
+   if ((required_mask > DMA_BIT_MASK(32)) &&
+   !pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) &&
+   !pci_set_consistent_dma_mask(pdev,
+   consistent_dma_mask)) {
+   ioc->base_add_sg_single =
+   &_base_add_sg_single_64;
+   ioc->sge_size = sizeof(Mpi2SGESimple64_t);
+   ioc->dma_mask = 64;
+   goto out;
+   }
+   }
+
return -ENODEV;
+   }
 
  out:
si_meminfo();
-- 
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] arm64: bpf: fix mod-by-zero case

2015-11-04 Thread Zi Shen Lim
Turns out in the case of modulo by zero in a BPF program:
A = A % X;  (X == 0)
the expected behavior is to terminate with return value 0.

The bug in JIT is exposed by a new test case [1].

[1] https://lkml.org/lkml/2015/11/4/499

Signed-off-by: Zi Shen Lim 
Reported-by: Yang Shi 
Reported-by: Xi Wang 
CC: Alexei Starovoitov 
CC: Catalin Marinas 
Fixes: e54bcde3d69d ("arm64: eBPF JIT compiler")
Cc:  # 3.18+
---
This patch applies on top of "arm64: bpf: fix fiv-by-zero case" [2].

[2] https://lkml.org/lkml/2015/11/4/25

 arch/arm64/net/bpf_jit_comp.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
index 9ae6f23..6217f80 100644
--- a/arch/arm64/net/bpf_jit_comp.c
+++ b/arch/arm64/net/bpf_jit_comp.c
@@ -269,6 +269,8 @@ static int build_insn(const struct bpf_insn *insn, struct 
jit_ctx *ctx)
break;
case BPF_ALU | BPF_DIV | BPF_X:
case BPF_ALU64 | BPF_DIV | BPF_X:
+   case BPF_ALU | BPF_MOD | BPF_X:
+   case BPF_ALU64 | BPF_MOD | BPF_X:
{
const u8 r0 = bpf2a64[BPF_REG_0];
 
@@ -281,16 +283,19 @@ static int build_insn(const struct bpf_insn *insn, struct 
jit_ctx *ctx)
check_imm26(jmp_offset);
emit(A64_B(jmp_offset), ctx);
/* else */
-   emit(A64_UDIV(is64, dst, dst, src), ctx);
+   switch (BPF_OP(code)) {
+   case BPF_DIV:
+   emit(A64_UDIV(is64, dst, dst, src), ctx);
+   break;
+   case BPF_MOD:
+   ctx->tmp_used = 1;
+   emit(A64_UDIV(is64, tmp, dst, src), ctx);
+   emit(A64_MUL(is64, tmp, tmp, src), ctx);
+   emit(A64_SUB(is64, dst, dst, tmp), ctx);
+   break;
+   }
break;
}
-   case BPF_ALU | BPF_MOD | BPF_X:
-   case BPF_ALU64 | BPF_MOD | BPF_X:
-   ctx->tmp_used = 1;
-   emit(A64_UDIV(is64, tmp, dst, src), ctx);
-   emit(A64_MUL(is64, tmp, tmp, src), ctx);
-   emit(A64_SUB(is64, dst, dst, tmp), ctx);
-   break;
case BPF_ALU | BPF_LSH | BPF_X:
case BPF_ALU64 | BPF_LSH | BPF_X:
emit(A64_LSLV(is64, dst, dst, src), ctx);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: piping core dump to a program escapes container

2015-11-04 Thread Shayan Pooya
On Sun, Nov 1, 2015 at 12:25 PM, Richard Weinberger
 wrote:
> On Sat, Oct 24, 2015 at 11:54 PM, Shayan Pooya  wrote:
>> I noticed the following core_pattern behavior in my linux box while
>> running docker containers. I am not sure if it is bug, but it is
>> inconsistent and not documented.
>>
>> If the core_pattern is set on the host, the containers will observe
>> and use the pattern for dumping cores (there is no per cgroup
>> core_pattern). According to core(5) for setting core_pattern one can:
>>
>> 1. echo "/tmp/cores/core.%e.%p" > /proc/sys/kernel/core_pattern
>> 2. echo "|/bin/custom_core /tmp/cores/ %e %p " > 
>> /proc/sys/kernel/core_pattern
>>
>> The former pattern evaluates the /tmp/cores path in the container's
>> filesystem namespace. Which means, the host does not see a core file
>> in /tmp/cores.
>>
>> However, the latter evaluates the /bin/custom_core path in the global
>> filesystem namespace. Moreover, if /bin/core decides to write the core
>> to a path (/tmp/cores in this case as shown by the arg to
>> custom_core), the path will be evaluated in the global filesystem
>> namespace as well.
>>
>> The latter behaviour is counter-intuitive and error-prone as the
>> container can fill up the core-file directory which it does not have
>> direct access to (which means the core is also not accessible for
>> debugging if someone only has access to the container).
>>
>> Currently, I work around this issue by detecting that the process is
>> crashing from a container (by comparing the namespace pid to the
>> global pid) and refuse to dump the core if it is from a container.
>
> IMHO this is another example of the question whether a container should
> be a full blown Linux system or not.

I'd like to use containers as a way for separating concerns (IMHO this
is a popular use case for the containers, e.g. redhat's openshift).
The processes running inside a namespace should be that namespace's
problem.

> In your opinion containers should own core_pattern and be able to install
> their own dump helpers.

Well, it is not just my opinion. That's the default behaviour for when
you don't use a pipe in the core_pattern. The reason I'd say it is a
bug is because the two options are not consistent.

> Currently this is not the case as this is setting is only writable by
> the global root.
> Others might argue that containers are not a full virtual Linux with
> all features and
> an administrator may want to collect cores from all containers.

I agree there are some value in the admin getting a notification if
they choose to. The problem is that there is no clean mechanism for
the admin to send the core dump back to the namespace of the process.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2015-11-04 Thread Joonsoo Kim
On Tue, Sep 22, 2015 at 07:59:48PM +0200, Robert Richter wrote:
> From: Tirumalesh Chalamarla 
> 
> Increase the standard cacheline size to avoid having locks in the same
> cacheline.
> 
> Cavium's ThunderX core implements cache lines of 128 byte size. With
> current granulare size of 64 bytes (L1_CACHE_SHIFT=6) two locks could
> share the same cache line leading a performance degradation.
> Increasing the size fixes that.

Beside, slab-side bug, I don't think this argument is valid.
Even if this change is applied, statically allocated spinlock could
share the same cache line.

If two locks should not share the same cache line, you'd better to use
compiler attribute such as cacheline_aligned_in_smp in appropriate
place.

Thanks.

> 
> Increasing the size has no negative impact to cache invalidation on
> systems with a smaller cache line. There is an impact on memory usage,
> but that's not too important for arm64 use cases.
> 
> Signed-off-by: Tirumalesh Chalamarla 
> Signed-off-by: Robert Richter 
> ---
>  arch/arm64/include/asm/cache.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/include/asm/cache.h b/arch/arm64/include/asm/cache.h
> index bde449936e2f..5082b30bc2c0 100644
> --- a/arch/arm64/include/asm/cache.h
> +++ b/arch/arm64/include/asm/cache.h
> @@ -18,7 +18,7 @@
>  
>  #include 
>  
> -#define L1_CACHE_SHIFT   6
> +#define L1_CACHE_SHIFT   7
>  #define L1_CACHE_BYTES   (1 << L1_CACHE_SHIFT)
>  
>  /*
> -- 
> 2.1.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


  1   2   3   4   5   6   7   8   9   10   >