Re: [PATCH] printk: introduce should_ignore_loglevel()

2016-06-24 Thread Sergey Senozhatsky
On (06/24/16 18:05), Petr Mladek wrote:
[..]
> > +static bool should_ignore_loglevel(int level)
> > +{
> > +   return (level >= console_loglevel && !ignore_loglevel);
> 
> The patch looks fine. It is nice optimization.
> 
> I was just quite confused by the name of this function. A function
> called should_ignore_loglevel() should not return false when
> ignore_loglevel variable is true.
> 
> I would call it ignore_message() or ignore_message_on_console() or so.

Hello Petr, you are right.

I was thinking about

s/should_ignore_loglevel/suppress_message/g
or s/should_ignore_loglevel/suppress_message_by_level/g
s/should_ignore_loglevel/suppress_message_printing/g

suppress_message_printing() is probably fine.

will it work for you guys?

-ss


[PATCH] scsi: ufs: remove unnecessary goto label

2016-06-24 Thread Tiezhu Yang
When buff_ascii kmalloc failed, there is no need to call kfree,
it should return -ENOMEM directly, this patch fixes it.

Signed-off-by: Tiezhu Yang 
---
 drivers/scsi/ufs/ufshcd.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 8e8989a..f08d41a 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -2137,7 +2137,7 @@ int ufshcd_read_string_desc(struct ufs_hba *hba, int 
desc_index, u8 *buf,
buff_ascii = kmalloc(ascii_len, GFP_KERNEL);
if (!buff_ascii) {
err = -ENOMEM;
-   goto out_free_buff;
+   goto out;
}
 
/*
@@ -2156,7 +2156,6 @@ int ufshcd_read_string_desc(struct ufs_hba *hba, int 
desc_index, u8 *buf,
size - QUERY_DESC_HDR_SIZE);
memcpy(buf + QUERY_DESC_HDR_SIZE, buff_ascii, ascii_len);
buf[QUERY_DESC_LENGTH_OFFSET] = ascii_len + QUERY_DESC_HDR_SIZE;
-out_free_buff:
kfree(buff_ascii);
}
 out:
-- 
1.8.3.1

Re: [PATCH] orangefs: fix namespace handling

2016-06-24 Thread Eric W. Biederman
Jann Horn  writes:

> diff --git a/fs/orangefs/devorangefs-req.c b/fs/orangefs/devorangefs-req.c
> index db170be..a287a66 100644
> --- a/fs/orangefs/devorangefs-req.c
> +++ b/fs/orangefs/devorangefs-req.c
> @@ -116,6 +116,13 @@ static int orangefs_devreq_open(struct inode *inode, 
> struct file *file)
>  {
>   int ret = -EINVAL;
>  
> + /* in order to ensure that the filesystem driver sees correct UIDs */
> + if (file->f_cred->user_ns != _user_ns) {
> + gossip_err("%s: device cannot be opened outside init_user_ns\n",
> +__func__);
> + goto out;
> + }
> +

Not necessarily in this patch but the code should also verify that the
opener is also in the initial pid namespace as pids are transferred in
the upcalls as well.

>   if (!(file->f_flags & O_NONBLOCK)) {
>   gossip_err("%s: device cannot be opened in blocking mode\n",
>  __func__);

Eric


[PATCH v2 02/14] thermal: sun8i_ths: Add support for the thermal sensor on Allwinner H3

2016-06-24 Thread megous
From: Ondrej Jirman 

This patch adds support for the sun8i thermal sensor on
Allwinner H3 SoC.

Signed-off-by: Ondřej Jirman 
---
v2:
- removed incorrect use of SID driver in sun8i_ths
- read calibration data directly from iomem  
- better explanation for the thermal sensor driver
- dt documentation fixes
- dropped unncecessary macros and init code reorganization
- moved resource aquisition from init to probe function
- deassert reset after clock rate is set, not before
- enable irq after all other registers are configured
---
 drivers/thermal/Kconfig |   7 ++
 drivers/thermal/Makefile|   1 +
 drivers/thermal/sun8i_ths.c | 260 
 3 files changed, 268 insertions(+)
 create mode 100644 drivers/thermal/sun8i_ths.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 2d702ca..d3209d9 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -351,6 +351,13 @@ config MTK_THERMAL
  Enable this option if you want to have support for thermal management
  controller present in Mediatek SoCs
 
+config SUN8I_THS
+   tristate "Thermal sensor driver for Allwinner H3"
+   depends on MACH_SUN8I
+   depends on OF
+   help
+ Enable this to support thermal reporting on some newer Allwinner SoCs.
+
 menu "Texas Instruments thermal drivers"
 depends on ARCH_HAS_BANDGAP || COMPILE_TEST
 depends on HAS_IOMEM
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 10b07c1..7261ee8 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -51,3 +51,4 @@ obj-$(CONFIG_TEGRA_SOCTHERM)  += tegra/
 obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
 obj-$(CONFIG_MTK_THERMAL)  += mtk_thermal.o
 obj-$(CONFIG_GENERIC_ADC_THERMAL)  += thermal-generic-adc.o
+obj-$(CONFIG_SUN8I_THS)+= sun8i_ths.o
diff --git a/drivers/thermal/sun8i_ths.c b/drivers/thermal/sun8i_ths.c
new file mode 100644
index 000..9ba0f96
--- /dev/null
+++ b/drivers/thermal/sun8i_ths.c
@@ -0,0 +1,260 @@
+/*
+ * Thermal sensor driver for Allwinner H3 SoC
+ *
+ * Copyright (C) 2016 Ondřej Jirman
+ * Based on the work of Josef Gajdusek 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define THS_H3_CTRL0   0x00
+#define THS_H3_CTRL2   0x40
+#define THS_H3_INT_CTRL0x44
+#define THS_H3_STAT0x48
+#define THS_H3_FILTER  0x70
+#define THS_H3_CDATA   0x74
+#define THS_H3_DATA0x80
+
+#define THS_H3_CTRL0_SENSOR_ACQ0(x) (x)
+#define THS_H3_CTRL2_SENSE_EN   BIT(0)
+#define THS_H3_CTRL2_SENSOR_ACQ1(x) ((x) << 16)
+#define THS_H3_INT_CTRL_DATA_IRQ_EN BIT(8)
+#define THS_H3_INT_CTRL_THERMAL_PER(x)  ((x) << 12)
+#define THS_H3_STAT_DATA_IRQ_STSBIT(8)
+#define THS_H3_FILTER_TYPE(x)   ((x) << 0)
+#define THS_H3_FILTER_ENBIT(2)
+
+#define THS_H3_CLK_IN 4000  /* Hz */
+#define THS_H3_DATA_PERIOD 330  /* ms */
+
+#define THS_H3_FILTER_TYPE_VALUE   2  /* average over 2^(n+1) 
samples */
+#define THS_H3_FILTER_DIV  (1 << (THS_H3_FILTER_TYPE_VALUE 
+ 1))
+#define THS_H3_INT_CTRL_THERMAL_PER_VALUE \
+   (THS_H3_DATA_PERIOD * (THS_H3_CLK_IN / 1000) / THS_H3_FILTER_DIV / 4096 
- 1)
+#define THS_H3_CTRL0_SENSOR_ACQ0_VALUE 0x3f /* 16us */
+#define THS_H3_CTRL2_SENSOR_ACQ1_VALUE 0x3f
+
+struct sun8i_ths_data {
+   struct reset_control *reset;
+   struct clk *clk;
+   struct clk *busclk;
+   void __iomem *regs;
+   void __iomem *calreg;
+   struct thermal_zone_device *tzd;
+   u32 temp;
+};
+
+static int sun8i_ths_get_temp(void *_data, int *out)
+{
+   struct sun8i_ths_data *data = _data;
+
+   if (data->temp == 0)
+   return -EINVAL;
+
+   /* Formula and parameters from the Allwinner 3.4 kernel */
+   *out = 217000 - (int)((data->temp * 100) / 8253);
+   return 0;
+}
+
+static irqreturn_t sun8i_ths_irq_thread(int irq, void *_data)
+{
+   struct sun8i_ths_data *data = _data;
+
+   writel(THS_H3_STAT_DATA_IRQ_STS, data->regs + THS_H3_STAT);
+
+   data->temp = readl(data->regs + THS_H3_DATA);
+   if (data->temp)
+   thermal_zone_device_update(data->tzd);
+
+   return IRQ_HANDLED;
+}
+
+static void sun8i_ths_h3_init(struct sun8i_ths_data *data)
+{
+   u32 caldata;
+   
+   

[PATCH v2 01/14] ARM: clk: sunxi: Add driver for the H3 THS clock

2016-06-24 Thread megous
From: Josef Gajdusek 

This patch adds a driver for the THS clock which is present on the
Allwinner H3.

Signed-off-by: Josef Gajdusek 
---
 Documentation/devicetree/bindings/clock/sunxi.txt |  1 +
 drivers/clk/sunxi/Makefile|  1 +
 drivers/clk/sunxi/clk-h3-ths.c| 98 +++
 3 files changed, 100 insertions(+)
 create mode 100644 drivers/clk/sunxi/clk-h3-ths.c

diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt 
b/Documentation/devicetree/bindings/clock/sunxi.txt
index 8f7619d..5faae05 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -87,6 +87,7 @@ Required properties:
"allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
"allwinner,sun4i-a10-ve-clk" - for the Video Engine clock
"allwinner,sun6i-a31-display-clk" - for the display clocks
+   "allwinner,sun8i-h3-ths-clk" - for THS on H3
 
 Required properties for all clocks:
 - reg : shall be the control register address for the clock.
diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index 39d2044..8e245e3 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -9,6 +9,7 @@ obj-y += clk-a10-mod1.o
 obj-y += clk-a10-pll2.o
 obj-y += clk-a10-ve.o
 obj-y += clk-a20-gmac.o
+obj-y += clk-h3-ths.o
 obj-y += clk-mod0.o
 obj-y += clk-simple-gates.o
 obj-y += clk-sun4i-display.o
diff --git a/drivers/clk/sunxi/clk-h3-ths.c b/drivers/clk/sunxi/clk-h3-ths.c
new file mode 100644
index 000..c1d6d32
--- /dev/null
+++ b/drivers/clk/sunxi/clk-h3-ths.c
@@ -0,0 +1,98 @@
+/*
+ * sun8i THS clock driver
+ *
+ * Copyright (C) 2015 Josef Gajdusek
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define SUN8I_H3_THS_CLK_ENABLE31
+#define SUN8I_H3_THS_CLK_DIVIDER_SHIFT 0
+#define SUN8I_H3_THS_CLK_DIVIDER_WIDTH 2
+
+static DEFINE_SPINLOCK(sun8i_h3_ths_clk_lock);
+
+static const struct clk_div_table sun8i_h3_ths_clk_table[] __initconst = {
+   { .val = 0, .div = 1 },
+   { .val = 1, .div = 2 },
+   { .val = 2, .div = 4 },
+   { .val = 3, .div = 6 },
+   { } /* sentinel */
+};
+
+static void __init sun8i_h3_ths_clk_setup(struct device_node *node)
+{
+   struct clk *clk;
+   struct clk_gate *gate;
+   struct clk_divider *div;
+   const char *parent;
+   const char *clk_name = node->name;
+   void __iomem *reg;
+   int err;
+
+   reg = of_io_request_and_map(node, 0, of_node_full_name(node));
+
+   if (IS_ERR(reg))
+   return;
+
+   gate = kzalloc(sizeof(*gate), GFP_KERNEL);
+   if (!gate)
+   goto err_unmap;
+
+   div = kzalloc(sizeof(*gate), GFP_KERNEL);
+   if (!div)
+   goto err_gate_free;
+
+   of_property_read_string(node, "clock-output-names", _name);
+   parent = of_clk_get_parent_name(node, 0);
+
+   gate->reg = reg;
+   gate->bit_idx = SUN8I_H3_THS_CLK_ENABLE;
+   gate->lock = _h3_ths_clk_lock;
+
+   div->reg = reg;
+   div->shift = SUN8I_H3_THS_CLK_DIVIDER_SHIFT;
+   div->width = SUN8I_H3_THS_CLK_DIVIDER_WIDTH;
+   div->table = sun8i_h3_ths_clk_table;
+   div->lock = _h3_ths_clk_lock;
+
+   clk = clk_register_composite(NULL, clk_name, , 1,
+NULL, NULL,
+>hw, 
_divider_ops,
+>hw, 
_gate_ops,
+
CLK_SET_RATE_PARENT);
+
+   if (IS_ERR(clk))
+   goto err_div_free;
+
+   err = of_clk_add_provider(node, of_clk_src_simple_get, clk);
+   if (err)
+   goto err_unregister_clk;
+
+   return;
+
+err_unregister_clk:
+   clk_unregister(clk);
+err_gate_free:
+   kfree(gate);
+err_div_free:
+   kfree(div);
+err_unmap:
+   iounmap(reg);
+}
+
+CLK_OF_DECLARE(sun8i_h3_ths_clk, "allwinner,sun8i-h3-ths-clk",
+  sun8i_h3_ths_clk_setup);
-- 
2.9.0



[PATCH v2 05/14] dt-bindings: document SY8106A regulator driver

2016-06-24 Thread megous
From: Ondrej Jirman 

This patch adds the binding documentation for the
sy8106a regulator driver.

Signed-off-by: Ondrej Jirman 
---
 .../bindings/regulator/sy8106a-regulator.txt| 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt

diff --git a/Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt 
b/Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt
new file mode 100644
index 000..1e623a34
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt
@@ -0,0 +1,21 @@
+SY8106A Voltage regulator
+
+Required properties:
+- compatible: Must be "silergy,sy8106a"
+- reg: I2C slave address - must be <0x65>
+
+Any property defined as part of the core regulator binding, defined in
+regulator.txt, can also be used.
+
+Example:
+
+   sy8106a {
+   compatible = "silergy,sy8106a";
+   reg = <0x65>;
+   regulator-name = "sy8106a-vdd";
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <140>;
+   regulator-ramp-delay = <200>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
-- 
2.9.0



[PATCH v2 07/14] ARM: dts: sun8i: Use sun8i-h3-pll1-clk for pll1 in H3

2016-06-24 Thread megous
From: Ondrej Jirman 

PLL1 on H3 requires special factors application algorithm,
when the rate is changed. This algorithm was extracted
from the arisc code that handles frequency scaling
in the BSP kernel.

This algorithm is implemented by sun8i-h3-pll1-clk.

Signed-off-by: Ondrej Jirman 
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 4a4926b..b3247f4 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -106,7 +106,7 @@
 
pll1: clk@01c2 {
#clock-cells = <0>;
-   compatible = "allwinner,sun8i-a23-pll1-clk";
+   compatible = "allwinner,sun8i-h3-pll1-clk";
reg = <0x01c2 0x4>;
clocks = <>;
clock-output-names = "pll1";
-- 
2.9.0



[PATCH v2 09/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

2016-06-24 Thread megous
From: Ondrej Jirman 

Add label to the first cpu so that it can be referenced
from derived dts files.

Signed-off-by: Ondrej Jirman 
---
v2
- move clocks/clock-latency to sun8i-h3.dtsi  
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index d3c29cc..56f211e 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -52,7 +52,9 @@
#address-cells = <1>;
#size-cells = <0>;
 
-   cpu@0 {
+   cpu0: cpu@0 {
+   clocks = <>;
+   clock-latency = <244144>; /* 8 32k periods */
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <0>;
-- 
2.9.0



[PATCH v2 06/14] ARM: sun8i: clk: Add clk-factor rate application method

2016-06-24 Thread megous
From: Ondrej Jirman 

PLL1 on H3 requires special factors application algorithm,
when the rate is changed. This algorithm was extracted
from the arisc code that handles frequency scaling
in the BSP kernel.

This commit adds optional apply function to
struct factors_data, that can implement non-trivial
factors application method, when necessary.

Also struct clk_factors_config is extended with position
of the PLL lock flag.

Signed-off-by: Ondrej Jirman 
---
 Documentation/devicetree/bindings/clock/sunxi.txt |  1 +
 drivers/clk/sunxi/clk-factors.c   | 34 +--
 drivers/clk/sunxi/clk-factors.h   | 12 
 drivers/clk/sunxi/clk-sunxi.c | 72 ++-
 4 files changed, 98 insertions(+), 21 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt 
b/Documentation/devicetree/bindings/clock/sunxi.txt
index 5faae05..774500c 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -10,6 +10,7 @@ Required properties:
"allwinner,sun4i-a10-pll1-clk" - for the main PLL clock and PLL4
"allwinner,sun6i-a31-pll1-clk" - for the main PLL clock on A31
"allwinner,sun8i-a23-pll1-clk" - for the main PLL clock on A23
+   "allwinner,sun8i-h3-pll1-clk" - for the main PLL clock on H3
"allwinner,sun4i-a10-pll3-clk" - for the video PLL clock on A10
"allwinner,sun9i-a80-pll4-clk" - for the peripheral PLLs on A80
"allwinner,sun4i-a10-pll5-clk" - for the PLL5 clock
diff --git a/drivers/clk/sunxi/clk-factors.c b/drivers/clk/sunxi/clk-factors.c
index ddefe96..7c165db 100644
--- a/drivers/clk/sunxi/clk-factors.c
+++ b/drivers/clk/sunxi/clk-factors.c
@@ -34,13 +34,6 @@
 
 #define FACTORS_MAX_PARENTS5
 
-#define SETMASK(len, pos)  (((1U << (len)) - 1) << (pos))
-#define CLRMASK(len, pos)  (~(SETMASK(len, pos)))
-#define FACTOR_GET(bit, len, reg)  (((reg) & SETMASK(len, bit)) >> (bit))
-
-#define FACTOR_SET(bit, len, reg, val) \
-   (((reg) & CLRMASK(len, bit)) | (val << (bit)))
-
 static unsigned long clk_factors_recalc_rate(struct clk_hw *hw,
 unsigned long parent_rate)
 {
@@ -150,20 +143,24 @@ static int clk_factors_set_rate(struct clk_hw *hw, 
unsigned long rate,
if (factors->lock)
spin_lock_irqsave(factors->lock, flags);
 
-   /* Fetch the register value */
-   reg = readl(factors->reg);
+   if (factors->apply) {
+   factors->apply(factors, );
+   } else {
+   /* Fetch the register value */
+   reg = readl(factors->reg);
 
-   /* Set up the new factors - macros do not do anything if width is 0 */
-   reg = FACTOR_SET(config->nshift, config->nwidth, reg, req.n);
-   reg = FACTOR_SET(config->kshift, config->kwidth, reg, req.k);
-   reg = FACTOR_SET(config->mshift, config->mwidth, reg, req.m);
-   reg = FACTOR_SET(config->pshift, config->pwidth, reg, req.p);
+   /* Set up the new factors - macros do not do anything if width 
is 0 */
+   reg = FACTOR_SET(config->nshift, config->nwidth, reg, req.n);
+   reg = FACTOR_SET(config->kshift, config->kwidth, reg, req.k);
+   reg = FACTOR_SET(config->mshift, config->mwidth, reg, req.m);
+   reg = FACTOR_SET(config->pshift, config->pwidth, reg, req.p);
 
-   /* Apply them now */
-   writel(reg, factors->reg);
+   /* Apply them now */
+   writel(reg, factors->reg);
 
-   /* delay 500us so pll stabilizes */
-   __delay((rate >> 20) * 500 / 2);
+   /* delay 500us so pll stabilizes */
+   __delay((rate >> 20) * 500 / 2);
+   }
 
if (factors->lock)
spin_unlock_irqrestore(factors->lock, flags);
@@ -213,6 +210,7 @@ struct clk *sunxi_factors_register(struct device_node *node,
factors->config = data->table;
factors->get_factors = data->getter;
factors->recalc = data->recalc;
+   factors->apply = data->apply;
factors->lock = lock;
 
/* Add a gate if this factor clock can be gated */
diff --git a/drivers/clk/sunxi/clk-factors.h b/drivers/clk/sunxi/clk-factors.h
index 1e63c5b..661a45a 100644
--- a/drivers/clk/sunxi/clk-factors.h
+++ b/drivers/clk/sunxi/clk-factors.h
@@ -6,6 +6,13 @@
 
 #define SUNXI_FACTORS_NOT_APPLICABLE   (0)
 
+#define SETMASK(len, pos)  (((1U << (len)) - 1) << (pos))
+#define CLRMASK(len, pos)  (~(SETMASK(len, pos)))
+#define FACTOR_GET(bit, len, reg)  (((reg) & SETMASK(len, bit)) >> (bit))
+
+#define FACTOR_SET(bit, len, reg, val) \
+   (((reg) & CLRMASK(len, bit)) | (val << (bit)))
+
 struct clk_factors_config {
u8 nshift;
u8 nwidth;
@@ -16,6 +23,7 @@ struct clk_factors_config {
u8 pshift;
u8 pwidth;
u8 

[PATCH v2 13/14] ARM: dts: sun8i: Add gpio-regulator used on Orange Pi One

2016-06-24 Thread megous
From: Ondrej Jirman 

Xulong Orange Pi One uses GPIO based regulator that
switches between two voltages: 1.1V and 1.3V. The
regulator is controlled from the PL6 pin.

Signed-off-by: Ondrej Jirman 
---
v2
- add missing pinctrl-names for gpio-regulator
---
 arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
index 0adf932..b1bd6b0 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
@@ -88,6 +88,25 @@
gpios = <_pio 0 3 GPIO_ACTIVE_LOW>;
};
};
+
+   vdd_soc: gpio-regulator {
+   compatible = "regulator-gpio";
+   pinctrl-names = "default";
+   pinctrl-0 = <_reg_r_opc>;
+
+   regulator-name = "soc-vdd-supply";
+   regulator-min-microvolt = <110>;
+   regulator-max-microvolt = <130>;
+   regulator-boot-on;
+   regulator-type = "voltage";
+
+   gpios = <_pio 0 6 GPIO_ACTIVE_HIGH>;
+   states = <110 0x0
+ 130 0x1>;
+
+   startup-delay-us = <10>;
+   enable-active-high;
+   };
 };
 
  {
@@ -131,6 +150,13 @@
allwinner,drive = ;
allwinner,pull = ;
};
+
+   vdd_reg_r_opc: regulator_pins@0 {
+   allwinner,pins = "PL6";
+   allwinner,function = "gpio_out";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
 };
 
  {
-- 
2.9.0



[PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

2016-06-24 Thread megous
From: Ondrej Jirman 

Use Xulong Orange Pi One GPIO based regulator for
passive cooling and thermal management.

Signed-off-by: Ondrej Jirman 
---
 arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 +
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
index b1bd6b0..a38d871 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
@@ -109,6 +109,45 @@
};
 };
 
+ {
+   operating-points = <
+   /* kHzuV */
+   1296000 130
+   120 130
+   624000  110
+   48  110
+   312000  110
+   24  110
+   >;
+   #cooling-cells = <2>;
+   cooling-min-level = <0>;
+   cooling-max-level = <5>;
+   cpu0-supply = <_soc>;
+};
+
+_thermal {
+   cooling-maps {
+   map0 {
+   trip = <_alert0>;
+   cooling-device = < (-1) (-1)>;
+   };
+   };
+
+   trips {
+   cpu_alert0: cpu_alert0 {
+   temperature = <8>;
+   hysteresis = <2000>;
+   type = "passive";
+   };
+
+   cpu_crit: cpu_crit {
+   temperature = <10>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+};
+
  {
status = "okay";
 };
-- 
2.9.0



[PATCH v2 08/14] ARM: dts: sun8i: Add thermal sensor node to the sun8i-h3.dtsi

2016-06-24 Thread megous
From: Ondrej Jirman 

This patch adds nodes for the thermal sensor driver and
the THS clock to the Allwinner sun8i-h3.dtsi file.

Signed-off-by: Ondrej Jirman 
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index b3247f4..d3c29cc 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -77,6 +77,14 @@
};
};
 
+   thermal-zones {
+   cpu_thermal: cpu_thermal {
+   polling-delay-passive = <330>;
+   polling-delay = <1000>;
+   thermal-sensors = < 0>;
+   };
+   };
+
timer {
compatible = "arm,armv7-timer";
interrupts = ,
@@ -239,6 +247,14 @@
 "bus_scr", "bus_ephy", "bus_dbg";
};
 
+   ths_clk: clk@01c20074 {
+   #clock-cells = <0>;
+   compatible = "allwinner,sun8i-h3-ths-clk";
+   reg = <0x01c20074 0x4>;
+   clocks = <>;
+   clock-output-names = "ths";
+   };
+
mmc0_clk: clk@01c20088 {
#clock-cells = <1>;
compatible = "allwinner,sun4i-a10-mmc-clk";
@@ -574,6 +590,18 @@
interrupts = ;
};
 
+   ths: ths@01c25000 {
+   #thermal-sensor-cells = <0>;
+   compatible = "allwinner,sun8i-h3-ths";
+   reg = <0x01c25000 0x400>,
+ <0x01c14234 0x4>;
+   interrupts = ;
+   resets = <_rst 8>;
+   reset-names = "ahb";
+   clocks = <_gates 72>, <_clk>;
+   clock-names = "ahb", "ths";
+   };
+
uart0: serial@01c28000 {
compatible = "snps,dw-apb-uart";
reg = <0x01c28000 0x400>;
-- 
2.9.0



[PATCH v2 11/14] ARM: dts: sun8i: Add sy8106a regulator to Orange Pi PC

2016-06-24 Thread megous
From: Ondrej Jirman 

Add sy8106a regulator to r_twi bus and enable the r_twi bus on
Orange Pi PC. This regulator controls the CPUX voltage.

Signed-off-by: Ondrej Jirman 
---
 arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts 
b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
index daf50b9a6..79f0b49 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
@@ -90,6 +90,20 @@
};
 };
 
+_twi {
+   status = "okay";
+
+   vdd_cpu: regulator@65 {
+   compatible = "silergy,sy8106a";
+   reg = <0x65>;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <140>;
+   regulator-ramp-delay = <200>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+};
+
  {
status = "okay";
 };
-- 
2.9.0



[PATCH v2 10/14] ARM: dts: sun8i: Add r_twi I2C controller

2016-06-24 Thread megous
From: Ondrej Jirman 

H3 SoC contains I2C controller optionally available
on the PL0 and PL1 pins. This patch makes this controller
available.

Signed-off-by: Ondrej Jirman 
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 56f211e..e32f211 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -322,8 +322,9 @@
reg = <0x01f01428 0x4>;
#clock-cells = <1>;
clocks = <>;
-   clock-indices = <0>, <1>;
-   clock-output-names = "apb0_pio", "apb0_ir";
+   clock-indices = <0>, <1>, <6>;
+   clock-output-names = "apb0_pio", "apb0_ir", "apb0_i2c";
+
};
 
ir_clk: ir_clk@01f01454 {
@@ -656,6 +657,20 @@
status = "disabled";
};
 
+   r_twi: i2c@01f02400 {
+   compatible = "allwinner,sun6i-a31-i2c";
+   reg = <0x01f02400 0x400>;
+   interrupts = ;
+   pinctrl-names = "default";
+   pinctrl-0 = <_twi_pins_a>;
+   clocks = <_gates 6>;
+   clock-frequency = <10>;
+   resets = <_reset 6>;
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
gic: interrupt-controller@01c81000 {
compatible = "arm,cortex-a7-gic", "arm,cortex-a15-gic";
reg = <0x01c81000 0x1000>,
@@ -707,6 +722,13 @@
allwinner,drive = ;
allwinner,pull = ;
};
+
+   r_twi_pins_a: r_twi@0 {
+   allwinner,pins = "PL0", "PL1";
+   allwinner,function = "s_twi";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
};
};
 };
-- 
2.9.0



[PATCH v2 12/14] ARM: dts: sun8i: Setup CPU operating points for Onrage PI PC

2016-06-24 Thread megous
From: Ondrej Jirman 

Orange PI PC uses SY8106A regulator for fine grained CPUX voltage
regulation. Setup appropriate operating points for the board.
---
 arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 48 ++
 1 file changed, 48 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts 
b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
index 79f0b49..1b029e9 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
@@ -90,6 +90,54 @@
};
 };
 
+ {
+   operating-points = <
+   /* kHzuV */
+   1512000 140
+   144 140
+   1368000 134
+   1344000 134
+   1296000 134
+   1248000 130
+   1224000 130
+   120 130
+   1104000 120
+   1008000 114
+   96  110
+   648000  110
+   48  110
+   24  110
+   12  110
+   >;
+   #cooling-cells = <2>;
+   cooling-min-level = <0>;
+   cooling-max-level = <14>;
+   cpu0-supply = <_cpu>;
+};
+
+_thermal {
+   cooling-maps {
+   map0 {
+   trip = <_alert0>;
+   cooling-device = < (-1) (-1)>;
+   };
+   };
+
+   trips {
+   cpu_alert0: cpu_alert0 {
+   temperature = <8>;
+   hysteresis = <2000>;
+   type = "passive";
+   };
+
+   cpu_crit: cpu_crit {
+   temperature = <10>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+};
+
 _twi {
status = "okay";
 
-- 
2.9.0



[PATCH v2 03/14] dt-bindings: document sun8i_ths - H3 thermal sensor driver

2016-06-24 Thread megous
From: Ondrej Jirman 

This patch adds the binding documentation for the
sun8i_ths driver. This is a driver for thermal sensor
found in Allwinner H3 SoC.

Signed-off-by: Ondřej Jirman 
---
 .../devicetree/bindings/thermal/sun8i-ths.txt  | 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/thermal/sun8i-ths.txt

diff --git a/Documentation/devicetree/bindings/thermal/sun8i-ths.txt 
b/Documentation/devicetree/bindings/thermal/sun8i-ths.txt
new file mode 100644
index 000..76859d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/sun8i-ths.txt
@@ -0,0 +1,26 @@
+* Thermal sensor driver for Allwinner H3 SoC
+
+Required properties:
+- compatible : "allwinner,sun8i-h3-ths"
+- reg : Address range of the thermal sensor registers and of the calibration
+  data
+- resets : Must contain phandles to reset controls matching the entries
+  of the names
+- reset-names : Must include the name "ahb"
+- clocks : Must contain phandles to clock controls matching the entries
+  of the names
+- clock-names : Must contain "ahb" for the bus gate and "ths" for the THS
+  clock
+
+Example:
+ths: ths@01c25000 {
+   #thermal-sensor-cells = <0>;
+   compatible = "allwinner,sun8i-h3-ths";
+   reg = <0x01c25000 0x400>,
+ <0x01c14234 0x4>;
+   interrupts = ;
+   resets = <_rst 136>;
+   reset-names = "ahb";
+   clocks = <_gates 72>, <_clk>;
+   clock-names = "ahb", "ths";
+};
-- 
2.9.0



[PATCH v2 04/14] regulator: SY8106A regulator driver

2016-06-24 Thread megous
From: Ondrej Jirman 

SY8106A is I2C attached single output voltage regulator
made by Silergy.

Signed-off-by: Ondrej Jirman 
---
v2
- added dt-bindings for the regulator
- changed to use of_device_id for probing
- added initialization failure checks
---
 drivers/regulator/Kconfig |   8 +-
 drivers/regulator/Makefile|   2 +-
 drivers/regulator/sy8106a-regulator.c | 171 ++
 3 files changed, 179 insertions(+), 2 deletions(-)
 create mode 100644 drivers/regulator/sy8106a-regulator.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 144cbf5..93f3fe4f 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -702,6 +702,13 @@ config REGULATOR_STW481X_VMMC
  This driver supports the internal VMMC regulator in the STw481x
  PMIC chips.
 
+config REGULATOR_SY8106A
+   tristate "Silergy SY8106A"
+   depends on I2C && (OF || COMPILE_TEST)
+   select REGMAP_I2C
+   help
+ This driver provides support for SY8106A voltage regulator.
+
 config REGULATOR_TPS51632
tristate "TI TPS51632 Power Regulator"
depends on I2C
@@ -861,4 +868,3 @@ config REGULATOR_WM8994
  WM8994 CODEC.
 
 endif
-
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 85a1d44..e3f720f 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -88,6 +88,7 @@ obj-$(CONFIG_REGULATOR_S2MPS11) += s2mps11.o
 obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
 obj-$(CONFIG_REGULATOR_SKY81452) += sky81452-regulator.o
 obj-$(CONFIG_REGULATOR_STW481X_VMMC) += stw481x-vmmc.o
+obj-$(CONFIG_REGULATOR_SY8106A) += sy8106a-regulator.o
 obj-$(CONFIG_REGULATOR_TI_ABB) += ti-abb-regulator.o
 obj-$(CONFIG_REGULATOR_TPS6105X) += tps6105x-regulator.o
 obj-$(CONFIG_REGULATOR_TPS62360) += tps62360-regulator.o
@@ -111,5 +112,4 @@ obj-$(CONFIG_REGULATOR_WM8350) += wm8350-regulator.o
 obj-$(CONFIG_REGULATOR_WM8400) += wm8400-regulator.o
 obj-$(CONFIG_REGULATOR_WM8994) += wm8994-regulator.o
 
-
 ccflags-$(CONFIG_REGULATOR_DEBUG) += -DDEBUG
diff --git a/drivers/regulator/sy8106a-regulator.c 
b/drivers/regulator/sy8106a-regulator.c
new file mode 100644
index 000..98626bc
--- /dev/null
+++ b/drivers/regulator/sy8106a-regulator.c
@@ -0,0 +1,171 @@
+/*
+ * sy8106a-regulator.c - Regulator device driver for SY8106A
+ *
+ * Copyright (C) 2016  Ondřej Jirman 
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Library General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library 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
+ * Library General Public License for more details.
+ *
+ * You should have received a copy of the GNU Library General Public
+ * License along with this library; if not, write to the
+ * Free Software Foundation, Inc., 51 Franklin St, Fifth Floor,
+ * Boston, MA  02110-1301, USA.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SY8106A_REG_VOUT1_SEL  0x01
+#define SY8106A_REG_VOUT_COM   0x02
+#define SY8106A_REG_VOUT1_SEL_MASK 0x7f
+#define SY8106A_DISABLE_REGBIT(0)
+#define SY8106A_GO_BIT BIT(7)
+
+struct sy8106a {
+   struct regulator_dev *rdev;
+   struct regmap *regmap;
+};
+
+static const struct regmap_config sy8106a_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+};
+
+static int sy8106a_set_voltage_sel(struct regulator_dev *rdev, unsigned sel)
+{
+   /* We use our set_voltage_sel in order to avoid unnecessary I2C chatter,
+* because the regulator_get_voltage_sel_regmap using apply_bit
+* would perform 4 unnecessary transfers instead of one, increasing the
+* chance of error.
+*/
+   return regmap_write(rdev->regmap, rdev->desc->vsel_reg,
+   sel | SY8106A_GO_BIT);
+}
+
+static const struct regulator_ops sy8106a_ops = {
+   .is_enabled = regulator_is_enabled_regmap,
+   .set_voltage_sel = sy8106a_set_voltage_sel,
+   .set_voltage_time_sel = regulator_set_voltage_time_sel,
+   .get_voltage_sel = regulator_get_voltage_sel_regmap,
+   .list_voltage = regulator_list_voltage_linear,
+};
+
+/* Default limits measured in millivolts and milliamps */
+#define SY8106A_MIN_MV 680
+#define SY8106A_MAX_MV 1950
+#define SY8106A_STEP_MV10
+
+static const struct regulator_desc sy8106a_reg = {
+   .name = "SY8106A",
+   .id = 0,
+   .ops = _ops,
+   .type = REGULATOR_VOLTAGE,
+   .n_voltages = ((SY8106A_MAX_MV - SY8106A_MIN_MV) / SY8106A_STEP_MV) + 1,
+   .min_uV = (SY8106A_MIN_MV 

Re: [RFC/PATCH] ftrace: Reduce size of function graph entries

2016-06-24 Thread Namhyung Kim
On Sat, Jun 25, 2016 at 2:29 AM, Steven Rostedt  wrote:
> On Sat, 25 Jun 2016 01:15:34 +0900
> Namhyung Kim  wrote:
>
>> On Fri, Jun 24, 2016 at 12:04:40PM -0400, Steven Rostedt wrote:
>> > On Fri, 24 Jun 2016 15:35:44 +0900
>> > Namhyung Kim  wrote:
>> >
>> >
>> > > > > diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
>> > > > > index dea12a6e413b..35c523ba5c59 100644
>> > > > > --- a/include/linux/ftrace.h
>> > > > > +++ b/include/linux/ftrace.h
>> > > > > @@ -751,25 +751,33 @@ extern void ftrace_init(void);
>> > > > >  static inline void ftrace_init(void) { }
>> > > > >  #endif
>> > > > >
>> > > > > +#ifndef CONFIG_HAVE_64BIT_ALIGNED_ACCESS
>> > > > > +# define FTRACE_ALIGNMENT4
>> > > > > +#else
>> > > > > +# define FTRACE_ALIGNMENT8
>> > > > > +#endif
>> > > >
>>
>> As far as I can see, the ring buffer has following code in ring_buffer.c:
>>
>>   #define RB_ALIGNMENT4U
>>   #define RB_MAX_SMALL_DATA   (RB_ALIGNMENT * RINGBUF_TYPE_DATA_TYPE_LEN_MAX)
>>   #define RB_EVNT_MIN_SIZE8U  /* two 32bit words */
>>
>>   #ifndef CONFIG_HAVE_64BIT_ALIGNED_ACCESS
>>   # define RB_FORCE_8BYTE_ALIGNMENT   0
>>   # define RB_ARCH_ALIGNMENT  RB_ALIGNMENT
>>   #else
>>   # define RB_FORCE_8BYTE_ALIGNMENT   1
>>   # define RB_ARCH_ALIGNMENT  8U
>>   #endif
>>
>>   #define RB_ALIGN_DATA   __aligned(RB_ARCH_ALIGNMENT)
>>
>
> Right, what I meant was that we should just define FTRACE_ALIGNMENT
> unconditionally to 4. If CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set,
> it will add the buffered space regardless.
>
> You already moved "overrun", I don't see anything that would be out of
> alignment if the structure itself is aligned.

In that case if CONFIG_HAVE_64BIT_ALIGNED_ACCESS is set, the ring
buffer is 8-byte aligned but the struct is 4-byte aligned, right? Note
that the function graph tracer saves the data in a local variable (of
the struct) first and copies to the ring buffer later.  Wouldn't it be
a problem?

Thanks,
Namhyung


[RFT PATCH] regmap-i2c: Only use I2C_FUNC_I2C if val_bits == 8

2016-06-24 Thread Guenter Roeck
On chips with a register value size of 16 bits, I2C block reads will
typically not return the expected values. Instead, returned values
are most likely undefined if an operation crosses a register boundary.

This can be observed, for example, with a TMP102 connected to an omap
i2c controller. With this chip, the initial regmap read operation to fill
the register cache looks as follows (debug log from modified kernel).

omap_i2c 4807.i2c: MSG[0]: add=0x0048, len: 1, flags: 0x0
omap_i2c 4807.i2c: [0] 0x00
omap_i2c 4807.i2c: MSG[1]: add=0x0048, len: 8, flags: 0x1
omap_i2c 4807.i2c: [0] 0x23
omap_i2c 4807.i2c: [1] 0xa0
omap_i2c 4807.i2c: [2] 0xff
omap_i2c 4807.i2c: [3] 0xff
omap_i2c 4807.i2c: [4] 0xff
omap_i2c 4807.i2c: [5] 0xff
omap_i2c 4807.i2c: [6] 0xff
omap_i2c 4807.i2c: [7] 0xff

Reported-by: Nishanth Menon <n...@ti.com>
Cc: Nishanth Menon <n...@ti.com>
Signed-off-by: Guenter Roeck <li...@roeck-us.net>
---
Nishanth,

it would be great if you can test this patch, to see if it solves the problem
you had observed. Please note that https://patchwork.kernel.org/patch/9191185/
needs to be applied first (it is available in next-20160624).

 drivers/base/regmap/regmap-i2c.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/base/regmap/regmap-i2c.c b/drivers/base/regmap/regmap-i2c.c
index 4735318f4268..f319e6829816 100644
--- a/drivers/base/regmap/regmap-i2c.c
+++ b/drivers/base/regmap/regmap-i2c.c
@@ -257,7 +257,8 @@ static struct regmap_bus regmap_i2c_smbus_i2c_block = {
 static const struct regmap_bus *regmap_get_i2c_bus(struct i2c_client *i2c,
const struct regmap_config *config)
 {
-   if (i2c_check_functionality(i2c->adapter, I2C_FUNC_I2C))
+   if (config->val_bits == 8 &&
+   i2c_check_functionality(i2c->adapter, I2C_FUNC_I2C))
return _i2c;
else if (config->val_bits == 8 && config->reg_bits == 8 &&
 i2c_check_functionality(i2c->adapter,
-- 
2.5.0



[PATCH] notifier: Fix soft lockup for notifier_call_chain().

2016-06-24 Thread Ding Tianhong
The problem was occurs in my system that a lot of drviers register
its own handler to the notifier call chain for netdev_chain, and
then create 4095 vlan dev for one nic, and add several ipv6 address
on each one of them, just like this:

for i in `seq 1 4095`; do ip link add link eth0 name eth0.$i type vlan id $i; 
done
for i in `seq 1 4095`; do ip -6 addr add 2001::$i dev eth0.$i; done
for i in `seq 1 4095`; do ip -6 addr add 2002::$i dev eth0.$i; done
for i in `seq 1 4095`; do ip -6 addr add 2003::$i dev eth0.$i; done

ifconfig eth0 up
ifconfig eth0 down

then it will halt several seconds, and occurs softlockup:

<0>[ 7620.364058]NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! 
[ifconfig:19186]
<0>[ 7620.364592]Call trace:
<4>[ 7620.364599][] dump_backtrace+0x0/0x220
<4>[ 7620.364603][] show_stack+0x20/0x28
<4>[ 7620.364607][] dump_stack+0x90/0xb0
<4>[ 7620.364612][] watchdog_timer_fn+0x41c/0x460
<4>[ 7620.364617][] __run_hrtimer+0x98/0x2d8
<4>[ 7620.364620][] hrtimer_interrupt+0x110/0x288
<4>[ 7620.364624][] arch_timer_handler_phys+0x38/0x48
<4>[ 7620.364628][] handle_percpu_devid_irq+0x9c/0x190
<4>[ 7620.364632][] generic_handle_irq+0x40/0x58
<4>[ 7620.364635][] __handle_domain_irq+0x68/0xc0
<4>[ 7620.364638][] gic_handle_irq+0xc4/0x1c8
<4>[ 7620.364641]Exception stack(0xffc0309b3640 to 0xffc0309b3770)
<4>[ 7620.364644]3640: 1000  ffc0309b37c0 
ffbfa1019cf8
<4>[ 7620.364647]3660: 8145 ffc0309b3958  
ffbfa1013008
<4>[ 7620.364651]3680: 07f0 ffbfa131b770 ffd08aaadc40 
ffbfa1019cf8
<4>[ 7620.364654]36a0: ffbfa1019cc4 ffd089c2b000 ffd08eff8000 
ffc0309b3958
<4>[ 7620.364656]36c0: ffbfa101c5c0   
ffbfa101c66c
<4>[ 7620.364659]36e0: 7f7f7f7f7f7f7f7f 0030  

<4>[ 7620.364662]3700:   ffc000393d58 
007f794d67b0
<4>[ 7620.364665]3720: 007fe62215d0 ffc0309b3830 ffc00021d8e0 
ffbfa1049b68
<4>[ 7620.364668]3740: ffc000697578 ffc0006974b8 ffc0309b3958 

<4>[ 7620.364670]3760: ffbfa1013008 07f0
<4>[ 7620.364673][] el1_irq+0x80/0x100
<4>[ 7620.364692][] fib6_walk+0x3c/0x70 [ipv6]
<4>[ 7620.364710][] fib6_clean_tree+0x68/0x90 [ipv6]
<4>[ 7620.364727][] __fib6_clean_all+0x88/0xc0 [ipv6]
<4>[ 7620.364746][] fib6_clean_all+0x28/0x30 [ipv6]
<4>[ 7620.364763][] rt6_ifdown+0x64/0x148 [ipv6]
<4>[ 7620.364781][] addrconf_ifdown+0x68/0x540 [ipv6]
<4>[ 7620.364798][] addrconf_notify+0xd0/0x8b8 [ipv6]
<4>[ 7620.364801][] notifier_call_chain+0x5c/0xa0
<4>[ 7620.364804][] raw_notifier_call_chain+0x20/0x28
<4>[ 7620.364809][] call_netdevice_notifiers_info+0x4c/0x80
<4>[ 7620.364812][] dev_close_many+0xd0/0x138
<4>[ 7620.364821][] vlan_device_event+0x4a8/0x6a0 [8021q]
<4>[ 7620.364824][] notifier_call_chain+0x5c/0xa0
<4>[ 7620.364827][] raw_notifier_call_chain+0x20/0x28
<4>[ 7620.364830][] call_netdevice_notifiers_info+0x4c/0x80
<4>[ 7620.364833][] __dev_notify_flags+0xb8/0xe0
<4>[ 7620.364836][] dev_change_flags+0x54/0x68
<4>[ 7620.364840][] devinet_ioctl+0x650/0x700
<4>[ 7620.364843][] inet_ioctl+0xa4/0xc8
<4>[ 7620.364847][] sock_do_ioctl+0x44/0x88
<4>[ 7620.364850][] sock_ioctl+0x23c/0x308
<4>[ 7620.364854][] do_vfs_ioctl+0x48c/0x620
<4>[ 7620.364857][] SyS_ioctl+0x94/0xa8

=cut 
here

It looks that the notifier_call_chain has to deal with too much handler, and 
will not
feed the watchdog until finish the work, so add cond_resched() in the loops to 
fix
this problem, and it will not panic again.

Signed-off-by: Ding Tianhong 
---
 kernel/notifier.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/notifier.c b/kernel/notifier.c
index fd2c9ac..9c30411 100644
--- a/kernel/notifier.c
+++ b/kernel/notifier.c
@@ -92,6 +92,8 @@ static int notifier_call_chain(struct notifier_block **nl,
 #endif
ret = nb->notifier_call(nb, val, v);
 
+   cond_resched();
+
if (nr_calls)
(*nr_calls)++;
 
-- 
1.9.0




Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

2016-06-24 Thread Linus Torvalds
On Fri, Jun 24, 2016 at 2:34 PM, Andy Lutomirski  wrote:
>>
>> So let me get the pure semantic patches done, and then for 4.8 when we
>> do the things that actually change real meaning we'll have a sane
>> base. Ok?
>
> Works for me.  I'll see whether my vmap patches still apply and, if
> needed, rebase and send a v5.

Ok, I'e pushed out the cleanups (and all the pulls that always come in
on Friday afternoon - gaah, I shouldn't have tried doing this on a
Friday).

I'm attaching the current left-over patch that actually changes
things. It's obviously a composite, and includes your "remove
stack_smp_processor_id()" thing etc, so it's not meant to be used
as-is, but it does seem to work.

Interestingly, it seems pretty clean too, removing more lines than it
adds (despite the fact that it adds a new config option), and
generally making things prettier rather than the reverse.

That's always a good sign.

  Linus

This is an attempt at moving the thread_info into the task_struct

 arch/x86/Kconfig   |  1 +
 arch/x86/entry/common.c| 21 +++--
 arch/x86/entry/entry_64.S  |  9 ++---
 arch/x86/include/asm/cpu.h |  1 -
 arch/x86/include/asm/smp.h |  6 --
 arch/x86/include/asm/switch_to.h   |  6 ++
 arch/x86/include/asm/thread_info.h | 37 +++--
 arch/x86/kernel/cpu/common.c   |  2 +-
 arch/x86/kernel/irq_64.c   |  3 +--
 arch/x86/kernel/process.c  |  6 ++
 arch/x86/um/ptrace_32.c|  8 
 include/linux/init_task.h  |  9 +
 include/linux/sched.h  | 18 +++---
 init/Kconfig   |  3 +++
 init/init_task.c   |  7 +--
 15 files changed, 59 insertions(+), 78 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index d9a94da0c29f..f33bc80577c5 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -154,6 +154,7 @@ config X86
select SPARSE_IRQ
select SRCU
select SYSCTL_EXCEPTION_TRACE
+   select THREAD_INFO_IN_TASK
select USER_STACKTRACE_SUPPORT
select VIRT_TO_BUS
select X86_DEV_DMA_OPS  if X86_64
diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
index ec138e538c44..d5feac5f252d 100644
--- a/arch/x86/entry/common.c
+++ b/arch/x86/entry/common.c
@@ -31,13 +31,6 @@
 #define CREATE_TRACE_POINTS
 #include 
 
-static struct thread_info *pt_regs_to_thread_info(struct pt_regs *regs)
-{
-   unsigned long top_of_stack =
-   (unsigned long)(regs + 1) + TOP_OF_KERNEL_STACK_PADDING;
-   return (struct thread_info *)(top_of_stack - THREAD_SIZE);
-}
-
 #ifdef CONFIG_CONTEXT_TRACKING
 /* Called on entry from user mode with IRQs off. */
 __visible void enter_from_user_mode(void)
@@ -78,7 +71,7 @@ static void do_audit_syscall_entry(struct pt_regs *regs, u32 
arch)
  */
 unsigned long syscall_trace_enter_phase1(struct pt_regs *regs, u32 arch)
 {
-   struct thread_info *ti = pt_regs_to_thread_info(regs);
+   struct thread_info *ti = current_thread_info();
unsigned long ret = 0;
u32 work;
 
@@ -156,7 +149,7 @@ unsigned long syscall_trace_enter_phase1(struct pt_regs 
*regs, u32 arch)
 long syscall_trace_enter_phase2(struct pt_regs *regs, u32 arch,
unsigned long phase1_result)
 {
-   struct thread_info *ti = pt_regs_to_thread_info(regs);
+   struct thread_info *ti = current_thread_info();
long ret = 0;
u32 work = ACCESS_ONCE(ti->flags) & _TIF_WORK_SYSCALL_ENTRY;
 
@@ -239,7 +232,7 @@ static void exit_to_usermode_loop(struct pt_regs *regs, u32 
cached_flags)
/* Disable IRQs and retry */
local_irq_disable();
 
-   cached_flags = READ_ONCE(pt_regs_to_thread_info(regs)->flags);
+   cached_flags = READ_ONCE(current_thread_info()->flags);
 
if (!(cached_flags & EXIT_TO_USERMODE_LOOP_FLAGS))
break;
@@ -250,7 +243,7 @@ static void exit_to_usermode_loop(struct pt_regs *regs, u32 
cached_flags)
 /* Called with IRQs disabled. */
 __visible inline void prepare_exit_to_usermode(struct pt_regs *regs)
 {
-   struct thread_info *ti = pt_regs_to_thread_info(regs);
+   struct thread_info *ti = current_thread_info();
u32 cached_flags;
 
if (IS_ENABLED(CONFIG_PROVE_LOCKING) && WARN_ON(!irqs_disabled()))
@@ -309,7 +302,7 @@ static void syscall_slow_exit_work(struct pt_regs *regs, 
u32 cached_flags)
  */
 __visible inline void syscall_return_slowpath(struct pt_regs *regs)
 {
-   struct thread_info *ti = pt_regs_to_thread_info(regs);
+   struct thread_info *ti = current_thread_info();
u32 cached_flags = READ_ONCE(ti->flags);
 
CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
@@ -332,7 +325,7 @@ __visible inline void syscall_return_slowpath(struct 
pt_regs *regs)
 #ifdef CONFIG_X86_64
 

Re: [PATCH] block-dev: enable writeback cgroup support

2016-06-24 Thread Sasha Levin
On 02/01/2016 08:50 PM, Shaohua Li wrote:
> block_dev's .writepages/.writepage already handles
> wbc_init_bio/wbc_account_io. We only set the SB_I_CGROUPWB bit to
> suppport writeback cgroup support.
> 
> Signed-off-by: Shaohua Li <s...@fb.com>

Hey Shaohua,

I'm seeing the following while fuzzing:

[  496.950320] kasan: CONFIG_KASAN_INLINE enabled
[  496.950952] kasan: GPF could be caused by NULL-ptr deref or user memory 
access
[  496.950954] general protection fault:  [#1] PREEMPT SMP KASAN
[  496.950978] Modules linked in:
[  496.951026] CPU: 4 PID: 8535 Comm: syz-executor Tainted: GW   
4.7.0-rc4-next-20160624-sasha-00024-gdee1616 #3132
[  496.951051] task: 8801bb0a9000 ti: 8801b5b7 task.ti: 
8801b5b7
[  496.951406] RIP: bd_mount (fs/block_dev.c:663)
[  496.951423] RSP: 0018:8801b5b77c48  EFLAGS: 00010207
[  496.951437] RAX: dc00 RBX:  RCX: 
[  496.951452] RDX: 000c RSI: aa2dc3e0 RDI: 0067
[  496.951466] RBP: 8801b5b77c58 R08: 8801c45b8008 R09: 
[  496.951522] R10: ed00190c9c00 R11:  R12: abba6360
[  496.951533] R13: 8800c79c92b8 R14: 8800c864e000 R15: 8011
[  496.951545] FS:  7fc253974700() GS:8801d410() 
knlGS:
[  496.951553] CS:  0010 DS:  ES:  CR0: 80050033
[  496.951561] CR2: 006f CR3: 0001b876c000 CR4: 000406a0
[  496.951577] Stack:
[  496.951593]  8801d0af1160 abba6360 8801b5b77c98 
9d831a20
[  496.951607]  24ee 8800c1b1b040 abba6360 
8800c79c92b8
[  496.951622]  8011 fff4 8801b5b77cd8 
9d88bf7a
[  496.951625] Call Trace:
[  496.951660] mount_fs (fs/super.c:1178)
[  496.951682] vfs_kern_mount (fs/namespace.c:949)
[  496.951701] do_mount (fs/namespace.c:2393 fs/namespace.c:2714)
[  496.951733] ? ___slab_alloc (mm/slub.c:2576)
[  496.951751] ? copy_mount_string (fs/namespace.c:2645)
[  496.953177] ? preempt_schedule_irq (./arch/x86/include/asm/bitops.h:311 
include/linux/thread_info.h:92 include/linux/sched.h:3269 
kernel/sched/core.c:3535)
[  496.953447] ? __sanitizer_cov_trace_pc (kernel/kcov.c:72)
[  496.953469] ? copy_mount_options (fs/namespace.c:2622)
[  496.953486] SyS_mount (fs/namespace.c:2908 fs/namespace.c:2883)
[  496.953501] ? copy_mnt_ns (fs/namespace.c:2883)
[  496.953542] do_syscall_64 (arch/x86/entry/common.c:284)
[  496.953560] entry_SYSCALL64_slow_path (arch/x86/entry/entry_64.S:251)
[ 496.953700] Code: a0 d9 73 a7 e8 43 e8 fc ff 48 85 c0 48 89 c3 74 63 e8 86 54 
cf ff 48 8d 7b 68 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 
00 74 05 e8 c6 9b ed ff 4c 8b 63 68 4d 85 e4 75 0e 31
All code

   0:   a0 d9 73 a7 e8 43 e8movabs 0xfffce843e8a773d9,%al
   7:   fc ff
   9:   48 85 c0test   %rax,%rax
   c:   48 89 c3mov%rax,%rbx
   f:   74 63   je 0x74
  11:   e8 86 54 cf ff  callq  0xffcf549c
  16:   48 8d 7b 68 lea0x68(%rbx),%rdi
  1a:   48 b8 00 00 00 00 00movabs $0xdc00,%rax
  21:   fc ff df
  24:   48 89 famov%rdi,%rdx
  27:   48 c1 ea 03 shr$0x3,%rdx
  2b:*  80 3c 02 00 cmpb   $0x0,(%rdx,%rax,1)   <-- 
trapping instruction
  2f:   74 05   je 0x36
  31:   e8 c6 9b ed ff  callq  0xffed9bfc
  36:   4c 8b 63 68 mov0x68(%rbx),%r12
  3a:   4d 85 e4test   %r12,%r12
  3d:   75 0e   jne0x4d
  3f:   31 00   xor%eax,(%rax)

Code starting with the faulting instruction
===
   0:   80 3c 02 00 cmpb   $0x0,(%rdx,%rax,1)
   4:   74 05   je 0xb
   6:   e8 c6 9b ed ff  callq  0xffed9bd1
   b:   4c 8b 63 68 mov0x68(%rbx),%r12
   f:   4d 85 e4test   %r12,%r12
  12:   75 0e   jne0x22
  14:   31 00   xor%eax,(%rax)
[  496.953718] RIP bd_mount (fs/block_dev.c:663)
[  496.953723]  RSP 


Re: [PATCH] hwmon: (emc6w201): trivial fix of spelling mistake "Unknwown" -> "Unknown"

2016-06-24 Thread Guenter Roeck

On 06/24/2016 10:31 AM, Colin King wrote:

From: Colin Ian King 

trivial fix to spelling mistake in dev_dbg message

Signed-off-by: Colin Ian King 
---


Applied to -next.

Thanks,
Guenter




Re: [RFC] reference count hardening via kref: another attempt

2016-06-24 Thread Kees Cook
On Fri, Jun 24, 2016 at 6:13 PM, Jann Horn  wrote:
> I would like to harden the kernel against reference count
> overflow bugs. The commit message of the patch contains
> a short analysis of code size impact, an explanation why I
> want reference count hardening to land in the kernel, and a
> description of the algorithm I'd want to use.
>
> The reason I'm writing a cover letter is that my patch, on
> its own, is pretty useless: My patch only adds hardening to
> struct kref, but nearly all reference counters are
> currently implemented using atomic_t, which is a generic
> atomic number type. For the patch to be useful, I'll have
> to go through the kernel and, for every atomic_t, decide
> whether it is a reference count and, if so, change it
> (together with all accesses to it) to a kref. According to
> a quick grep, there are currently about 2700 atomic_t
> struct members or variables in the kernel, so it's going to
> be a big amount of work, and the resulting patches will be
> gigantic.
>
> Therefore, before I actually spend lots of time on this,
> I'd like to know:
>
>  - Does the reference count hardening in my patch look
>okay, and does it have good chances to get accepted
>when submitted for inclusion in the kernel at a later
>point in time?
>
>  - If I manually go through the kernel and write a
>gigantic atomic_t -> struct kref patch (or a few
>patches coarsely grouped by subsystem), how high is
>the probability that it will get accepted?

My main concern is atomic_t will continue to get misused. While I have
no problem with wrap-checking kref, I think that we need to follow
grsecurity and introduce a new type (in grsec it is
"atomic_unchecked_t", but I think a more descriptive name would be
"atomic_wrap_t") and add them everywhere they're needed, and then
globally protect atomic_t wrapping. kref would gain the protections
automatically, though it would be arch-dependent...

-Kees

>
> (Note: I won't have much time for kernel work in the next
> four months or so - but afterwards, I could probably
> allocate time for getting this done.)
>
> Jann Horn (1):
>   kref: pin objects with dangerously high reference count
>
>  include/linux/kref.h | 39 +--
>  init/Kconfig | 16 
>  kernel/Makefile  |  2 +-
>  kernel/kref.c| 17 +
>  4 files changed, 67 insertions(+), 7 deletions(-)
>  create mode 100644 kernel/kref.c
>
> --
> 2.8.0.rc3.226.g39d4020
>



-- 
Kees Cook
Chrome OS & Brillo Security


[PATCH] perf build: Add libbabeltrace to build-test

2016-06-24 Thread Wang Nan
'make build-test' doesn't test LIBBABELTRACE=1. It misses a building
failure caused by commit 41840d211c51 ("perf config: Move config
declarations from util/cache.h to util/config.h"), breaks bisect.

Add LIBBABELTRACE=1 to build-test.

Signed-off-by: Wang Nan 
Cc: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
---
 tools/perf/tests/make | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/perf/tests/make b/tools/perf/tests/make
index cac15d9..51966d9 100644
--- a/tools/perf/tests/make
+++ b/tools/perf/tests/make
@@ -81,6 +81,7 @@ make_no_libbionic   := NO_LIBBIONIC=1
 make_no_auxtrace:= NO_AUXTRACE=1
 make_no_libbpf := NO_LIBBPF=1
 make_no_libcrypto   := NO_LIBCRYPTO=1
+make_with_babeltrace:= LIBBABELTRACE=1
 make_tags   := tags
 make_cscope := cscope
 make_help   := help
@@ -136,6 +137,7 @@ run += make_no_libaudit
 run += make_no_libbionic
 run += make_no_auxtrace
 run += make_no_libbpf
+run += make_with_babeltrace
 run += make_help
 run += make_doc
 run += make_perf_o
-- 
1.8.3.4



Re: kernel-4.7 bug in Intel sound and/or ACPI

2016-06-24 Thread Wim Osterholt
On Fri, Jun 24, 2016 at 02:09:15AM -0400, Sinan Kaya wrote:
> 
> Can you give it a try?

Whell, I tried to no avail.

Wether it is on 4.6 or 4.7, with or without your previous patch,
I keep getting rejected hunks.
For example, here the line to be deleted is nowhere to be found:

> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index 714ba4d..c2f22c9 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -497,7 +497,7 @@ static int acpi_irq_get_penalty(int irq)
>   int penalty = 0;
>  
>   if (irq < ACPI_MAX_ISA_IRQS)
> - penalty += acpi_isa_irq_penalty[irq];
> + return acpi_isa_irq_penalty[irq];
>  
>   /*
>   * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict


Regards, Wim.


- w...@djo.tudelft.nl -



Re: [PATCH 5/8] KEYS: Provide software public key query function [ver #2]

2016-06-24 Thread Herbert Xu
On Fri, Jun 24, 2016 at 01:06:02PM +0100, David Howells wrote:
> 
> The problem is that if I'm to produce consistency with, say, the TPM
> interface, then I have to deal in wrapped/padded data - leastways as far as I
> can tell from reading the docs.

So the TPM device is accessed through the same interface? Where is
the code for it?

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH 1/2] perf data convert: Include config.h header

2016-06-24 Thread Wangnan (F)

You can add:

Fixes: 41840d211c51 ("perf config: Move config declarations from 
util/cache.h to util/config.h")


Thank you.

On 2016/6/24 20:40, Jiri Olsa wrote:

otherwise some compiler might scream:

   $ make LIBBABELTRACE_DIR=/opt/libbabeltrace/ LIBBABELTRACE=1
 BUILD:   Doing 'make -j4' parallel build
 CC   util/data-convert-bt.o
   util/data-convert-bt.c: In function ‘convert__config’:
   util/data-convert-bt.c:1299:19: error: implicit declaration of function 
‘perf_config_u64’ [-Werror=implicit-function-declaration]
  c->queue_size = perf_config_u64(var, value);
   ...

Link: http://lkml.kernel.org/n/tip-t9dyx71w49dy5tacpdzr5...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
  tools/perf/util/data-convert-bt.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/tools/perf/util/data-convert-bt.c 
b/tools/perf/util/data-convert-bt.c
index 9f53020c3269..5186bb1168af 100644
--- a/tools/perf/util/data-convert-bt.c
+++ b/tools/perf/util/data-convert-bt.c
@@ -26,6 +26,7 @@
  #include "evlist.h"
  #include "evsel.h"
  #include "machine.h"
+#include "config.h"
  
  #define pr_N(n, fmt, ...) \

eprintf(n, debug_data_convert, fmt, ##__VA_ARGS__)





Re: [PATCH 1/5] hwmon: (tmp102) Use devm_add_action to register cleanup function

2016-06-24 Thread Guenter Roeck

On 06/24/2016 11:21 AM, Nishanth Menon wrote:

On 06/24/2016 01:18 PM, Guenter Roeck wrote:

On Fri, Jun 24, 2016 at 01:02:32PM -0500, Nishanth Menon wrote:

On 06/24/2016 11:36 AM, Guenter Roeck wrote:

On Fri, Jun 24, 2016 at 10:23:10AM -0500, Nishanth Menon wrote:

On 06/24/2016 09:54 AM, Guenter Roeck wrote:

On 06/24/2016 07:30 AM, Guenter Roeck wrote:

Hi Nishanth,

On 06/24/2016 07:13 AM, Nishanth Menon wrote:

On 06/23/2016 07:28 PM, Guenter Roeck wrote:

By registering a cleanup function with devm_add_action(), we can
simplify the error path in the probe function and drop the remove
function entirely.

Signed-off-by: Guenter Roeck <li...@roeck-us.net>


I dont seem to have a cover letter to reply to... but anyways..

Before: http://pastebin.ubuntu.com/17801376/
After all 5 patches: http://pastebin.ubuntu.com/17801824/

Fails on beagleboard-X15 with:
[   36.781509] tmp102 0-0048: No cache defaults, reading back from HW
[   36.795940] tmp102 0-0048: unexpected config register value

I have'nt bisected down on the specific patch in the series. Have you had a 
chance to test the series?




Thanks for testing. Yes, I did test it. Maybe different chip revisions, or 
different
initial config register values and I messed up there. Can you send me the output
of i2cdump (word wide) ?



Before 5 patches:

# i2cdump -f 0 0x48 w
  0,8  1,9  2,a  3,b  4,c  5,d  6,e  7,f
00: 7912 b062 004b 0050 c018 e006  


[ ... ]


After 5 patches:

  i2cdump -y 0 0x48 w
  0,8  1,9  2,a  3,b  4,c  5,d  6,e  7,f
00: 5024 a060 004b 0050 c018 e006  


[  ]


I can try and debug the series once I get some spare time, might be
over the weekend or next week.


The register map, at least the initial one, is pretty much the same as mine
and as expected. The configuration register in the second map is messed up,
possible because of a write with wrong endianness.


Got a few mins skipping lunch.. ;)

I did a quick bisect, and it is indeed the patch #5 that breaks.
added http://pastebin.ubuntu.com/17812044/ and got:

tmp102 0-0048: regval = 0x

That was weird. Does'nt look like endian-ness swap thingy

So, did the following hack to see all messages flowing in and out from
0x48 at bus controller driver level: http://pastebin.ubuntu.com/17813093/
/ # dmesg|grep XXX
/ #

Before patch #5 (and on next-20160624):
the same diff gave:
http://pastebin.ubuntu.com/17813303/




I bet the regmap_read() of the configuration register returns 0xa060 (or
0xb062) instead of 0x60a0 / 0x62b0 on your system. If you find the time,
it would be great if you can confirm by printing the register value with
the "unexpected config register value" message (guess I should have left
that in place - I used it during testing ;-).

If that is the case, I'll probably have to drop the regmap changes, at least
for now. It would mean that regmap is broken for chips like the LM75 (ie
for all chips with 16-bit registers) on controllers supporting I2C_FUNC_I2C.


It does look like everything is getting cached out and no actual reads
are actually getting through to the bus controller driver even.


Yes, that is really weird. It also seems to fill the cache with 0x,
which is even more weird.

Ok, looks like converting drivers to regmap isn't a good idea. I'll need
to get a system with an adapter supporting I2C_FUNC_I2C and do some more
testing.


I tested on next-20160624 and used omap2plus_defconfig for the test.



Thanks a lot for the information, and for testing this with your system.



here is more:
http://pastebin.ubuntu.com/17814261/

Looks like return for is_writable etc should probably be true or false



But it is. The result of "reg != TMP102_TEMP_REG" is a boolean. Even
if that was not the case, the function return value is bool, so per
C standard a non-boolean return value would be auto-converted to 0 / 1.


[   32.609935] at24 0-0050: 4096 byte 24c32 EEPROM, writable, 1
bytes/write
[   32.751560] rtc-ds1307 2-006f: SET TIME!
[   32.857593] palmas_pwrbutton
4807.i2c:tps659038@58:tps659038_pwr_button: h/w controlled
shutdown duration=12 s
econds
[   33.047265] rtc-ds1307 2-006f: rtc core: registered mcp7941x as rtc0
[   33.135774] tmp102 0-0048: No cache defaults, reading back from HW
[   33.538655] rtc-ds1307 2-006f: 64 bytes nvram
[   34.202107] omap_rng 4809.rng: _od_fail_runtime_resume: FIXME:
missing hwmod/omap_dev info
[   34.211191] omap_rng 4809.rng: Failed to runtime_get device: -19
[   34.217869] omap_rng 4809.rng: initialization failed.
[   34.229190] omap_rtc 48838000.rtc: rtc core: registered
48838000.rtc as rtc2
[   34.371375] omap_i2c 4807.i2c: XXX MSG[0]: add=0x0048, len: 1,
flags: 0x0
[   34.378893] omap_i2c 4807.i2c: XXX:[0] 0x00
/ # [   34.457000] omap_i2c 4807.i2c: XXX MSG[1]: add=0x0048, len:
8, flags: 0x1
[   34.464476] omap_i2c 4807.i2c: XXX:[0] 0x23
[   34.469255] omap_i2c 4807.i2c: XXX:[1] 0xa0
[   34.473999] omap_i2c 4807.i2c: 

Re: [PATCH] memory:bugxfix panic on cat or write /dev/kmem

2016-06-24 Thread Chenjie (K)



On 2016/6/23 20:42, Michal Hocko wrote:

On Fri 24-06-16 01:30:10, chenj...@huawei.com wrote:

From: chenjie 

cat /dev/kmem and echo > /dev/kmem will lead panic


Writing to /dev/kmem without being extremely careful is a disaster AFAIK
and even reading from the file can lead to unexpected results. Anyway
I am trying to understand what exactly you are trying to fix here. Why
writing to/reading from zero pfn should be any special wrt. any other
potentially dangerous addresses



cat /dev/mem not panic. cat /dev/kmem, just the user's operation for 
nothing.




Signed-off-by: chenjie 
---
  drivers/char/mem.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 71025c2..4bdde28 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -412,6 +412,8 @@ static ssize_t read_kmem(struct file *file, char __user 
*buf,
 * by the kernel or data corruption may occur
 */
kbuf = xlate_dev_kmem_ptr((void *)p);
+   if (!kbuf)
+   return -EFAULT;

if (copy_to_user(buf, kbuf, sz))
return -EFAULT;
@@ -482,6 +484,11 @@ static ssize_t do_write_kmem(unsigned long p, const char 
__user *buf,
 * corruption may occur.
 */
ptr = xlate_dev_kmem_ptr((void *)p);
+   if (!ptr) {
+   if (written)
+   break;
+   return -EFAULT;
+   }

copied = copy_from_user(ptr, buf, sz);
if (copied) {
--
1.8.0

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: mailto:"d...@kvack.org;> em...@kvack.org 






[RFC] kref: pin objects with dangerously high reference count

2016-06-24 Thread Jann Horn
Reference counting is a frequent source of (security) trouble in the
kernel. Here are the three main things that can, as far as I know, go wrong
with it, together with examples of specific bugs:

 - reference count overdecrement: If something (e.g. a normally-unused
   error path) decrements a reference counter more than it was previously
   incremented, this can cause the reference counter to end up lower than
   it was before. This will cause the object to be freed before the last
   reference to the object is gone.
   This bug class is hard to mitigate - it isn't very different from a
   generic use-after-free.
   Vulnerability examples:
 commit 8358b02bf67d ("bpf: fix double-fdput [...]")
   Bug examples where I haven't looked at impact:
 commit 75f0b68b75da ("debugfs: [...]: avoid double fops release")
 commit 121323ae668e ("drivers/perf: [...]: Fix reference count[...]")

 - reference count overincrement: If an error path omits a necessary
   reference count decrement, this can cause the reference counter to end
   up higher than it was before even though no new reference to the object
   was created. If such a bug is triggered around 2^32 times, the (32 bits
   wide) reference counter overflows to a small value. After dropping a
   few references so that exactly 2^32 references remain, the object will
   be freed prematurely.
   This kind of bug can easily occur when mistakes are made while writing
   error handling code.
   Vulnerability examples:
 commit 23567fd052a9 ("KEYS: Fix keyring ref leak [...]")
   Bug examples where I haven't looked at impact:
 commit b10e3e90485e ("debugfs: [...]: free proxy on ->open() failure")
 commit 3ea411c56ef5 ("android: fix reference leak in [...]")
 commit 8ed9e0e1b602 ("Input: turbografx - fix reference counting")

 - simple reference count overflow: If there are over 2^32 legitimate
   references to an object, a 32-bit reference counter can overflow. Since
   this can't happen on 32-bit architectures and normal references require
   at least a pointer, the minimum amount of physical memory required to
   hit this bug class is sizeof(void*) * 2^32 = 32 GiB ~= 34.36 GB.
   One example of a reference count overflow that could be triggered in
   some uncommon configurations on systems with 40GB of RAM is
   commit 92117d8443bc ("bpf: fix refcnt overflow").
   The nasty thing about this bug class is that it doesn't require a "real"
   reference counting bug, and with increasing amounts of physical memory,
   the number of reachable instances of this issue increases. (Probably not
   at 64GB or so; but it might get dangerous around 1TB or so.)

This patch is a first step towards addressing overincrements and simple
overflows, but not overdecrements.

My concerns when choosing an appropriate fix implementation are:

 - memory usage: An easy fix would be to increase the size of refcounts to
   64 bits. However, that would both increase memory usage and mess with
   data structures that have been designed carefully to e.g. fit into a
   single cacheline.
   (Note: Because file descriptor tables can contain lots of struct file
   pointers and are relatively dense, struct file already has a 64-bit
   refcount.)
 - CPU usage: Refcounting is a central, relatively hot piece of kernel
   code, so a fix must not use a lot of CPU time. In particular, additional
   or less deterministic atomic operations should be avoided.
 - complexity: A fix shouldn't involve significant changes in arch-specific
   code.
 - crashiness: While these kinds of bugs currently cause (potentially
   exploitable) crashes and oopsing would be a big improvement over that,
   ideally the system should just keep going without killing anything.
 - impact on non-refcounting code: atomic_t is a generic atomic type, and
   while a lot of code uses it for reference counting, it also has other
   users for whom reference count hardening might mess up things.

Since 2009 or so, PaX had reference count overflow mitigation code. My main
reasons for reinventing the wheel are:

 - PaX adds arch-specific code, both in the atomic_t operations and in
   exception handlers. I'd like to keep the code as
   architecture-independent as possible, especially without adding
   complexity to assembler code, to make it more maintainable and
   auditable.
 - The refcounting hardening from PaX does not handle the "simple reference
   count overflow" case when just the refcounting hardening code is used as
   a standalone patch. (On a system with the full PaX patch, the active
   response code would probably prevent exploitation of this case.)

I think that the biggest disadvantages of my code are:

 - It increases the size of the inline code for kref_get_unless_zero() and,
   if CONFIG_HARDEN_KREF_BIGMEM is enabled, of kref_sub(). (Also of
   kref_put_mutex(), but that method isn't used often.)
 - If CONFIG_HARDEN_KREF_BIGMEM is enabled, its kref_sub() implementation
   always has to do an additional 

[RFC] reference count hardening via kref: another attempt

2016-06-24 Thread Jann Horn
I would like to harden the kernel against reference count
overflow bugs. The commit message of the patch contains
a short analysis of code size impact, an explanation why I
want reference count hardening to land in the kernel, and a
description of the algorithm I'd want to use.

The reason I'm writing a cover letter is that my patch, on
its own, is pretty useless: My patch only adds hardening to
struct kref, but nearly all reference counters are
currently implemented using atomic_t, which is a generic
atomic number type. For the patch to be useful, I'll have
to go through the kernel and, for every atomic_t, decide
whether it is a reference count and, if so, change it
(together with all accesses to it) to a kref. According to
a quick grep, there are currently about 2700 atomic_t
struct members or variables in the kernel, so it's going to
be a big amount of work, and the resulting patches will be
gigantic.

Therefore, before I actually spend lots of time on this,
I'd like to know:

 - Does the reference count hardening in my patch look
   okay, and does it have good chances to get accepted
   when submitted for inclusion in the kernel at a later
   point in time?

 - If I manually go through the kernel and write a
   gigantic atomic_t -> struct kref patch (or a few
   patches coarsely grouped by subsystem), how high is
   the probability that it will get accepted?

(Note: I won't have much time for kernel work in the next
four months or so - but afterwards, I could probably
allocate time for getting this done.)

Jann Horn (1):
  kref: pin objects with dangerously high reference count

 include/linux/kref.h | 39 +--
 init/Kconfig | 16 
 kernel/Makefile  |  2 +-
 kernel/kref.c| 17 +
 4 files changed, 67 insertions(+), 7 deletions(-)
 create mode 100644 kernel/kref.c

-- 
2.8.0.rc3.226.g39d4020



Re: [linux-sunxi] Re: [PATCH 01/14] ARM: dts: sun8i: Add SID node

2016-06-24 Thread Chen-Yu Tsai
Hi,

On Sat, Jun 25, 2016 at 3:58 AM, Ondřej Jirman  wrote:
> Hello,
>
> thank you for the review.
>
> On 24.6.2016 04:41, Chen-Yu Tsai wrote:
>> On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
>>> From: Josef Gajdusek 
>>>
>>> Add a node describing the Security ID memory to the Allwinner H3 .dtsi file.
>>>
>>> Signed-off-by: Josef Gajdusek 
>>> ---
>>>  arch/arm/boot/dts/sun8i-h3.dtsi | 7 +++
>>>  1 file changed, 7 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
>>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> index 4a4926b..172576d 100644
>>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> @@ -389,6 +389,13 @@
>>> #size-cells = <0>;
>>> };
>>>
>>> +   sid: eeprom@01c14000 {
>>> +   compatible = "allwinner,sun4i-a10-sid";
>>
>> This has been discussed before. The hardware is not compatible.
>> The write control registers are at different offsets.
>
> I'm not sure what you mean by write control registers. Code in
> sunxi_sid.c implements only read access to the nvram. Can you pelase
> elaborate?

See 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/388022.html

Also, different compatibles are used for different hardware, regardless
of how close the drivers may be. The driver might only be compatible when
implementing a subset of the possible features. If one were to fully
implement it, they would become incompatible.

To put it another way, the compatible string designates the hardware,
and the driver implements support for that compatible string.

ChenYu

>   Ondrej
>
>>
>> ChenYu
>>
>>> +   reg = <0x01c14000 0x400>;
>>> +   #address-cells = <1>;
>>> +   #size-cells = <1>;
>>> +   };
>>> +
>>> usbphy: phy@01c19400 {
>>> compatible = "allwinner,sun8i-h3-usb-phy";
>>> reg = <0x01c19400 0x2c>,
>>> --
>>> 2.9.0
>>>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


Re: [RESEND PATCH v2 1/2] power/cpuidle: enhance the precision of state select

2016-06-24 Thread Rafael J. Wysocki
On Fri, Jun 17, 2016 at 11:13 AM, Zhaoyang Huang
 wrote:
> In previous version, cpu_pm_enter is invoked

By whom?  Not by the core surely?

> after the governor select the state, which cause the executing time of 
> cpu_pm_enter
> is included in the idle time. Moving it before the state selection.
>
> Signed-off-by: Zhaoyang Huang 
> ---
>  kernel/sched/idle.c |   18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
> index bd12c6c..929da2e 100644
> --- a/kernel/sched/idle.c
> +++ b/kernel/sched/idle.c
> @@ -5,6 +5,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -130,6 +131,7 @@ static void cpuidle_idle_call(void)
> struct cpuidle_device *dev = __this_cpu_read(cpuidle_devices);
> struct cpuidle_driver *drv = cpuidle_get_cpu_driver(dev);
> int next_state, entered_state;
> +   int ret;
>
> /*
>  * Check if the idle task must be rescheduled. If it is the
> @@ -174,12 +176,16 @@ static void cpuidle_idle_call(void)
> /*
>  * Ask the cpuidle framework to choose a convenient idle 
> state.
>  */
> -   next_state = cpuidle_select(drv, dev);
> -   entered_state = call_cpuidle(drv, dev, next_state);
> -   /*
> -* Give the governor an opportunity to reflect on the outcome
> -*/
> -   cpuidle_reflect(dev, entered_state);
> +   ret = cpu_pm_enter();

"To move" usually means "take it away from there and put it here" as
far as kernel patches are concerned, but I only see it added here.

> +   if (!ret) {
> +   next_state = cpuidle_select(drv, dev);
> +   entered_state = call_cpuidle(drv, dev, next_state);
> +   cpu_pm_exit();
> +   /*
> +* Give the governor an opportunity to reflect on the 
> outcome
> +*/
> +   cpuidle_reflect(dev, entered_state);
> +   }
> }
>
>  exit_idle:
> --

No way I will agree to add that notification stuff to the core.

Thanks,
Rafael


Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

2016-06-24 Thread Chen-Yu Tsai
On Sat, Jun 25, 2016 at 6:51 AM, Ondřej Jirman  wrote:
> Hello,
>
> comments below.
>
> On 24.6.2016 05:48, Chen-Yu Tsai wrote:
>> On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
>>> From: Ondrej Jirman 
>>>
>>> Add label to the first cpu so that it can be referenced
>>> from derived dts files.
>>>
>>> Signed-off-by: Ondrej Jirman 
>>> ---
>>>  arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
>>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> index 9938972..82faefc 100644
>>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> @@ -52,7 +52,7 @@
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>>
>>> -   cpu@0 {
>>> +   cpu0: cpu@0 {
>>> compatible = "arm,cortex-a7";
>>> device_type = "cpu";
>>> reg = <0>;
>>
>> Can you also set the cpu clock here? It is part of the SoC
>> and does not belong in the board DTS files.
>
> Do you mean operating-points, or something else? Different SBCs will
> probably require different combinations of operating points just for
> safety's sake, because they have different regulators and [some have
> botched] thermal designs, so it might make sense to customize it for
> differnt boards, and I don't feel adventurous enough setting it for all
> H3 boards out there.

I meant clocks = <...> and clock-latency = <...>.

These 2 are part of the SoC.

The OPP can stay in the board files. It's a pity there's no standard
OPP table for H3 though. :(

ChenYu

>
> Or is this comment related to the missing cpu clock rate message I see
> on every boot?
>
> [0.058912] /cpus/cpu@0 missing clock-frequency property
>
> regards,
>   Ondrej
>
>> Otherwise this one looks good.
>>
>> ChenYu
>>
>>> --
>>> 2.9.0
>>>
>


Re: [PATCH 07/14] regulator: SY8106A regulator driver

2016-06-24 Thread Chen-Yu Tsai
On Sat, Jun 25, 2016 at 8:11 AM, Ondřej Jirman  wrote:
> Hi,
>
> thank you for the review. I've resolved most of the issues. Some more
> comments below.
>
> On 24.6.2016 05:41, Chen-Yu Tsai wrote:
>> On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
>>> From: Ondrej Jirman 
>>>
>>> SY8106A is I2C attached single output voltage regulator
>>> made by Silergy.
>>>
>>> Signed-off-by: Ondrej Jirman 
>>> ---
>>>  drivers/regulator/Kconfig |   8 +-
>>>  drivers/regulator/Makefile|   2 +-
>>>  drivers/regulator/sy8106a-regulator.c | 153 
>>> ++
>>>  3 files changed, 161 insertions(+), 2 deletions(-)
>>>  create mode 100644 drivers/regulator/sy8106a-regulator.c
>>>
>>> diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
>>> index 144cbf5..fc3fae2 100644
>>> --- a/drivers/regulator/Kconfig
>>> +++ b/drivers/regulator/Kconfig
>>> @@ -860,5 +860,11 @@ config REGULATOR_WM8994
>>>   This driver provides support for the voltage regulators on the
>>>   WM8994 CODEC.
>>>
>>> -endif
>>> +config REGULATOR_SY8106A
>>> +   tristate "Silergy SY8106A"
>>> +   depends on I2C
>>
>> Maybe you should also depend on OF since the driver is going to crippled
>> without any constraints set, or (OF || COMPILE_TEST) if you want some
>> compile test coverage.
>>
>>> +   select REGMAP_I2C
>>> +   help
>>> + This driver provides support for the voltage regulator SY8106A.
>>>
>>> +endif
>>> diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
>>> index 85a1d44..f382095 100644
>>> --- a/drivers/regulator/Makefile
>>> +++ b/drivers/regulator/Makefile
>>> @@ -110,6 +110,6 @@ obj-$(CONFIG_REGULATOR_WM831X) += wm831x-ldo.o
>>>  obj-$(CONFIG_REGULATOR_WM8350) += wm8350-regulator.o
>>>  obj-$(CONFIG_REGULATOR_WM8400) += wm8400-regulator.o
>>>  obj-$(CONFIG_REGULATOR_WM8994) += wm8994-regulator.o
>>> -
>>> +obj-$(CONFIG_REGULATOR_SY8106A) += sy8106a-regulator.o
>>
>> Follow the existing ordering in the Makefile.
>>
>>>
>>>  ccflags-$(CONFIG_REGULATOR_DEBUG) += -DDEBUG
>>> diff --git a/drivers/regulator/sy8106a-regulator.c 
>>> b/drivers/regulator/sy8106a-regulator.c
>>> new file mode 100644
>>> index 000..34bd69c
>>> --- /dev/null
>>> +++ b/drivers/regulator/sy8106a-regulator.c
>>> @@ -0,0 +1,153 @@
>>> +/*
>>> + * sy8106a-regulator.c - Regulator device driver for SY8106A
>>> + *
>>> + * Copyright (C) 2016  Ondřej Jirman 
>>> + *
>>> + * This library is free software; you can redistribute it and/or
>>> + * modify it under the terms of the GNU Library General Public
>>> + * License as published by the Free Software Foundation; either
>>> + * version 2 of the License, or (at your option) any later version.
>>> + *
>>> + * This library 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
>>> + * Library General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU Library General Public
>>> + * License along with this library; if not, write to the
>>> + * Free Software Foundation, Inc., 51 Franklin St, Fifth Floor,
>>> + * Boston, MA  02110-1301, USA.
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>
>> Do you need this one?
>>
>>> +#include 
>>> +#include 
>>
>> And this one?
>>
>>> +#include 
>>> +#include 
>>
>> Sort alphabetically please.
>>
>>> +
>>> +#define SY8106A_REG_VOUT1_SEL  0x01
>>> +#define SY8106A_REG_VOUT_COM   0x02
>>> +#define SY8106A_REG_VOUT1_SEL_MASK 0x7f
>>> +#define SY8106A_DISABLE_REG0x01
>>
>> BIT(0) would be clearer.
>>
>>> +
>>> +struct sy8106a {
>>> +   struct regulator_dev *rdev;
>>> +   struct regmap *regmap;
>>> +};
>>> +
>>> +static const struct regmap_config sy8106a_regmap_config = {
>>> +   .reg_bits = 8,
>>> +   .val_bits = 8,
>>> +};
>>> +
>>> +static int sy8106a_set_voltage_sel(struct regulator_dev *rdev, unsigned 
>>> sel)
>>> +{
>>> +   return regmap_update_bits(rdev->regmap, rdev->desc->vsel_reg,
>>> + 0xff, sel | 0x80);
>>
>> Can you use .apply_bit / .apply_reg with regulator_set_voltage_sel_regmap?
>
> I understand the code savings, but I'd rather avoid that, because it
> would involve 2 needless readouts and rewrites of the voltage setting
> register. I'd rather change this to regmap_write, so that the regulator
> only receives writes over I2C, to minimize possibility of bit flip error
> by minimizing the communication over the I2C bus.

OK. It's best to add a comment then, in case someone comes in and refactors it.

>
>>> +}
>>> +
>>> +static const struct regulator_ops sy8106a_ops = {
>>> +   .is_enabled = regulator_is_enabled_regmap,
>>> +   .set_voltage_sel = sy8106a_set_voltage_sel,
>>> +   

Re: [PATCH 03/14] thermal: Add support for sun8i THS on Allwinner H3

2016-06-24 Thread Ondřej Jirman
On 25.6.2016 02:54, Chen-Yu Tsai wrote:
> On Sat, Jun 25, 2016 at 8:35 AM, Ondřej Jirman  wrote:
>> On 24.6.2016 05:09, Chen-Yu Tsai wrote:
 +static int sun8i_ths_h3_init(struct platform_device *pdev,
 +struct sun8i_ths_data *data)
 +{
 +   int ret;
 +   size_t callen;
 +   s32 *caldata;
 +
 +   data->busclk = devm_clk_get(>dev, "ahb");
 +   if (IS_ERR(data->busclk)) {
 +   ret = PTR_ERR(data->busclk);
 +   dev_err(>dev, "failed to get ahb clk: %d\n", ret);
 +   return ret;
 +   }
 +
 +   data->clk = devm_clk_get(>dev, "ths");
 +   if (IS_ERR(data->clk)) {
 +   ret = PTR_ERR(data->clk);
 +   dev_err(>dev, "failed to get ths clk: %d\n", ret);
 +   return ret;
 +   }
 +
 +   data->reset = devm_reset_control_get(>dev, "ahb");
>>>
>>> IIRC with the new shared reset control stuff merged, you are supposed
>>> to specify whether you want a shared or exclusive one when you ask for
>>> it.
>>
>> Here devm_reset_control_get will get the exclusive reference. So this
>> should be ok.
> 
> See https://patchwork.kernel.org/patch/9158691/
> 
> The generic ones might be removed later on. I remember in another thread
> it was asked that new users should use the explicit API, and avoid having
> to be converted.

I see, thank you, I'll change that.

regards,
  Ondrej

> ChenYu
> 
>>
>> regards,
>>   Ondrej
>>
>>>
>>> Regards
>>> ChenYu
>>>
 +MODULE_LICENSE("GPL v2");
 --
 2.9.0

>>



signature.asc
Description: OpenPGP digital signature


Re: [PATCH 03/14] thermal: Add support for sun8i THS on Allwinner H3

2016-06-24 Thread Chen-Yu Tsai
On Sat, Jun 25, 2016 at 8:35 AM, Ondřej Jirman  wrote:
> On 24.6.2016 05:09, Chen-Yu Tsai wrote:
>>> +static int sun8i_ths_h3_init(struct platform_device *pdev,
>>> +struct sun8i_ths_data *data)
>>> +{
>>> +   int ret;
>>> +   size_t callen;
>>> +   s32 *caldata;
>>> +
>>> +   data->busclk = devm_clk_get(>dev, "ahb");
>>> +   if (IS_ERR(data->busclk)) {
>>> +   ret = PTR_ERR(data->busclk);
>>> +   dev_err(>dev, "failed to get ahb clk: %d\n", ret);
>>> +   return ret;
>>> +   }
>>> +
>>> +   data->clk = devm_clk_get(>dev, "ths");
>>> +   if (IS_ERR(data->clk)) {
>>> +   ret = PTR_ERR(data->clk);
>>> +   dev_err(>dev, "failed to get ths clk: %d\n", ret);
>>> +   return ret;
>>> +   }
>>> +
>>> +   data->reset = devm_reset_control_get(>dev, "ahb");
>>
>> IIRC with the new shared reset control stuff merged, you are supposed
>> to specify whether you want a shared or exclusive one when you ask for
>> it.
>
> Here devm_reset_control_get will get the exclusive reference. So this
> should be ok.

See https://patchwork.kernel.org/patch/9158691/

The generic ones might be removed later on. I remember in another thread
it was asked that new users should use the explicit API, and avoid having
to be converted.

ChenYu

>
> regards,
>   Ondrej
>
>>
>> Regards
>> ChenYu
>>
>>> +MODULE_LICENSE("GPL v2");
>>> --
>>> 2.9.0
>>>
>


Re: [PATCH v3] Input: synaptics-rmi4: Support regulator supplies

2016-06-24 Thread Andrew Duggan

On 06/10/2016 10:25 PM, Bjorn Andersson wrote:

From: Bjorn Andersson 

Support the two supplies - vdd and vio - to make it possible to control
power to the Synaptics chip.

Signed-off-by: Bjorn Andersson 
Signed-off-by: Bjorn Andersson 


Reviewed-by: Andrew Duggan 


---
  .../devicetree/bindings/input/rmi4/rmi_i2c.txt |  9 +
  drivers/input/rmi4/rmi_i2c.c   | 41 ++
  2 files changed, 50 insertions(+)

diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt 
b/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
index 95fa715c6046..ec908b91fd90 100644
--- a/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
+++ b/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
@@ -22,6 +22,15 @@ See 
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
  - syna,reset-delay-ms: The number of milliseconds to wait after resetting the
device.
  
+- syna,startup-delay-ms: The number of milliseconds to wait after powering on

+the device.
+
+- vdd-supply: VDD power supply.
+See ../regulator/regulator.txt
+
+- vio-supply: VIO power supply
+See ../regulator/regulator.txt
+
  Function Parameters:
  Parameters specific to RMI functions are contained in child nodes of the rmi 
device
   node. Documentation for the parameters of each function can be found in:
diff --git a/drivers/input/rmi4/rmi_i2c.c b/drivers/input/rmi4/rmi_i2c.c
index a96a326b53bd..71dc6cdde8ac 100644
--- a/drivers/input/rmi4/rmi_i2c.c
+++ b/drivers/input/rmi4/rmi_i2c.c
@@ -11,6 +11,8 @@
  #include 
  #include 
  #include 
+#include 
+#include 
  #include "rmi_driver.h"
  
  #define BUFFER_SIZE_INCREMENT 32

@@ -37,6 +39,9 @@ struct rmi_i2c_xport {
  
  	u8 *tx_buf;

size_t tx_buf_size;
+
+   struct regulator_bulk_data supplies[2];
+   u32 startup_delay;
  };
  
  #define RMI_PAGE_SELECT_REGISTER 0xff

@@ -246,6 +251,24 @@ static int rmi_i2c_probe(struct i2c_client *client,
return -ENODEV;
}
  
+	rmi_i2c->supplies[0].supply = "vdd";

+   rmi_i2c->supplies[1].supply = "vio";
+   retval = devm_regulator_bulk_get(>dev,
+ARRAY_SIZE(rmi_i2c->supplies),
+rmi_i2c->supplies);
+   if (retval < 0)
+   return retval;
+
+   retval = regulator_bulk_enable(ARRAY_SIZE(rmi_i2c->supplies),
+  rmi_i2c->supplies);
+   if (retval < 0)
+   return retval;
+
+   of_property_read_u32(client->dev.of_node, "syna,startup-delay-ms",
+_i2c->startup_delay);
+
+   msleep(rmi_i2c->startup_delay);
+
rmi_i2c->client = client;
mutex_init(_i2c->page_mutex);
  
@@ -286,6 +309,7 @@ static int rmi_i2c_remove(struct i2c_client *client)

struct rmi_i2c_xport *rmi_i2c = i2c_get_clientdata(client);
  
  	rmi_unregister_transport_device(_i2c->xport);

+   regulator_bulk_disable(ARRAY_SIZE(rmi_i2c->supplies), 
rmi_i2c->supplies);
  
  	return 0;

  }
@@ -308,6 +332,9 @@ static int rmi_i2c_suspend(struct device *dev)
dev_warn(dev, "Failed to enable irq for wake: %d\n",
ret);
}
+
+   regulator_bulk_disable(ARRAY_SIZE(rmi_i2c->supplies), 
rmi_i2c->supplies);
+
return ret;
  }
  
@@ -317,6 +344,12 @@ static int rmi_i2c_resume(struct device *dev)

struct rmi_i2c_xport *rmi_i2c = i2c_get_clientdata(client);
int ret;
  
+	ret = regulator_bulk_enable(ARRAY_SIZE(rmi_i2c->supplies), rmi_i2c->supplies);

+   if (ret)
+   return ret;
+
+   msleep(rmi_i2c->startup_delay);
+
enable_irq(rmi_i2c->irq);
if (device_may_wakeup(>dev)) {
ret = disable_irq_wake(rmi_i2c->irq);
@@ -346,6 +379,8 @@ static int rmi_i2c_runtime_suspend(struct device *dev)
  
  	disable_irq(rmi_i2c->irq);
  
+	regulator_bulk_disable(ARRAY_SIZE(rmi_i2c->supplies), rmi_i2c->supplies);

+
return 0;
  }
  
@@ -355,6 +390,12 @@ static int rmi_i2c_runtime_resume(struct device *dev)

struct rmi_i2c_xport *rmi_i2c = i2c_get_clientdata(client);
int ret;
  
+	ret = regulator_bulk_enable(ARRAY_SIZE(rmi_i2c->supplies), rmi_i2c->supplies);

+   if (ret)
+   return ret;
+
+   msleep(rmi_i2c->startup_delay);
+
enable_irq(rmi_i2c->irq);
  
  	ret = rmi_driver_resume(rmi_i2c->xport.rmi_dev);




Re: [PATCH 03/14] thermal: Add support for sun8i THS on Allwinner H3

2016-06-24 Thread Ondřej Jirman
On 24.6.2016 05:09, Chen-Yu Tsai wrote:
>> +static int sun8i_ths_h3_init(struct platform_device *pdev,
>> +struct sun8i_ths_data *data)
>> +{
>> +   int ret;
>> +   size_t callen;
>> +   s32 *caldata;
>> +
>> +   data->busclk = devm_clk_get(>dev, "ahb");
>> +   if (IS_ERR(data->busclk)) {
>> +   ret = PTR_ERR(data->busclk);
>> +   dev_err(>dev, "failed to get ahb clk: %d\n", ret);
>> +   return ret;
>> +   }
>> +
>> +   data->clk = devm_clk_get(>dev, "ths");
>> +   if (IS_ERR(data->clk)) {
>> +   ret = PTR_ERR(data->clk);
>> +   dev_err(>dev, "failed to get ths clk: %d\n", ret);
>> +   return ret;
>> +   }
>> +
>> +   data->reset = devm_reset_control_get(>dev, "ahb");
> 
> IIRC with the new shared reset control stuff merged, you are supposed
> to specify whether you want a shared or exclusive one when you ask for
> it.

Here devm_reset_control_get will get the exclusive reference. So this
should be ok.

regards,
  Ondrej

> 
> Regards
> ChenYu
> 
>> +MODULE_LICENSE("GPL v2");
>> --
>> 2.9.0
>>



signature.asc
Description: OpenPGP digital signature


[perf core] c5dfd78eb7: BUG: unable to handle kernel NULL pointer dereference at 00000c40

2016-06-24 Thread kernel test robot
perf core: Allow setting up max frame stack depth via sysctl
# first bad commit: [c5dfd78eb79851e278b7973031b9ca363da87a7e] perf core: Allow 
setting up max frame stack depth via sysctl
git bisect good c2a218c63ba36946aca5943c0c8ebd3a42e3dc4b  # 08:06910+  
0  perf bench: Remove one more die() call
# extra tests with CONFIG_DEBUG_INFO_REDUCED
git bisect  bad c5dfd78eb79851e278b7973031b9ca363da87a7e  # 08:10  0-  
3  perf core: Allow setting up max frame stack depth via sysctl
# extra tests on HEAD of linux-devel/devel-hourly-2016062414
git bisect  bad e8d665056895dafedd7882bfe250ff6cf7dfbc0d  # 08:10  0- 
53  0day head guard for 'devel-hourly-2016062414'
# extra tests on tree/branch linus/master
git bisect  bad 63c04ee7d3b7c8d8e2726cb7c5f8a5f6fcc1e3b2  # 08:22  0-  
3  Merge tag 'upstream-4.7-rc5' of git://git.infradead.org/linux-ubifs
# extra tests on tree/branch linus/master
git bisect  bad 63c04ee7d3b7c8d8e2726cb7c5f8a5f6fcc1e3b2  # 08:23  0-  
5  Merge tag 'upstream-4.7-rc5' of git://git.infradead.org/linux-ubifs
# extra tests on tree/branch linux-next/master
git bisect  bad 2cf991dfda8b36d2878c249bcdf492366ec24c19  # 08:29 14-  
1  Add linux-next specific files for 20160624


This script may reproduce the error.


#!/bin/bash

kernel=$1
initrd=quantal-core-i386.cgz

wget --no-clobber 
https://github.com/fengguang/reproduce-kernel-bug/raw/master/initrd/$initrd

kvm=(
qemu-system-x86_64
-enable-kvm
-cpu kvm64
-kernel $kernel
-initrd $initrd
-m 300
-smp 2
-device e1000,netdev=net0
-netdev user,id=net0
-boot order=nc
-no-reboot
-watchdog i6300esb
-rtc base=localtime
-serial stdio
-display none
-monitor null 
)

append=(
hung_task_panic=1
earlyprintk=ttyS0,115200
systemd.log_level=err
debug
apic=debug
sysrq_always_enabled
rcupdate.rcu_cpu_stall_timeout=100
panic=-1
softlockup_panic=1
nmi_watchdog=panic
oops=panic
load_ramdisk=2
prompt_ramdisk=0
console=ttyS0,115200
console=tty0
vga=normal
root=/dev/ram0
rw
drbd.minor_count=8
)

"${kvm[@]}" --append "${append[*]}"


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


dmesg-quantal-kbuild-53:20160625075710:i386-randconfig-h0-06242012:4.6.0-rc4-00181-gc5dfd78:1.gz
Description: application/gzip
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.6.0-rc4 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
CONFIG_KERNEL_BZIP2=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_FHANDLE=y
# CONFIG_USELIB is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYS

Re: [PATCH v2 14/15] clk: sunxi-ng: Add H3 clocks

2016-06-24 Thread Michael Turquette
Hi Maxime,

Nice series! Looks really great to me. :-)

Quoting Maxime Ripard (2016-06-07 13:41:53)
> +static SUNXI_CCU_NKMP_WITH_GATE_LOCK(pll_cpux_clk, "pll-cpux",
> +"osc24M", 0x000,
> +8, 5,  /* N */
> +4, 2,  /* K */
> +0, 2,  /* M */
> +16, 2, /* P */
> +BIT(31),   /* gate */
> +BIT(28),   /* lock */
> +0);

I'm more of a fan of expanding the struct with designated initializers
versus macro use, but that's only personal preference.

> +static const char * const ahb2_parents[] = { "ahb1" , "pll-periph0" };
> +static struct ccu_mux ahb2_clk = {
> +   .mux= {
> +   .shift  = 0,
> +   .width  = 1,
> +
> +   .fixed_prediv   = {
> +   .index  = 1,
> +   .div= 2,
> +   },
> +   },
> +
> +   .common = {
> +   .reg= 0x05c,
> +   .features   = CCU_FEATURE_FIXED_PREDIV,
> +   .hw.init= SUNXI_HW_INIT_PARENTS("ahb2",
> +   ahb2_parents,

Note that it's possible to initialize the parent strings here if you
prefer:

.hw.init = &(struct clk_init_data){
   .parent_names = (const char *[]){ "ahb1",
 "pll-periph0" };

Similar to the above, no big deal, just an observation.

> +static struct ccu_common *sun8i_h3_ccu_clks[] = {
> +   [CLK_PLL_CPUX]  = _cpux_clk.common,
> +   [CLK_PLL_AUDIO_BASE]= _audio_base_clk.common,
> +   [CLK_PLL_AUDIO] = _audio_clk.common,

OK, it looks like you followed the qcom clk driver approach here, which
is a nice way to do things. However, as Stephen alluded to in his
response to the cover letter, the clk_hw_* api's are an even more
friendly interface for clock providers. For example, check out the gxbb
clk driver probe:

static int gxbb_clkc_probe(struct platform_device *pdev)
{
void __iomem *clk_base;
int ret, clkid, i;
struct device *dev = >dev;

/*  Generic clocks and PLLs */
clk_base = of_iomap(dev->of_node, 0);
if (!clk_base) {
pr_err("%s: Unable to map clk base\n", __func__);
return -ENXIO;
}

/* Populate base address for PLLs */
for (i = 0; i < ARRAY_SIZE(gxbb_clk_plls); i++)
gxbb_clk_plls[i]->base = clk_base;

/* Populate base address for MPLLs */
for (i = 0; i < ARRAY_SIZE(gxbb_clk_mplls); i++)
gxbb_clk_mplls[i]->base = clk_base;

...

/*
 * register all clks
 */
for (clkid = 0; clkid < NR_CLKS; clkid++) {
ret = devm_clk_hw_register(dev, 
gxbb_hw_onecell_data.hws[clkid]);
if (ret)
goto iounmap;
}

The nice thing about struct ccu_common is that you don't have to walk
the list of clocks for each separate clock type like the above probe
function does. I'm still thinking of the best way to solve this
generically. Maybe add a .base member struct clk_hw? I dunno, and I've
resisted the urge to add stuff to struct clk_hw in the past... But I
really want to minimize this .probe as much as possible, and I do not
want every clock provider driver to be forced to invent something like
struct ccu_common every time. Anyways, that is not a blocker for your
implementation to be merged, but Stephen's question in patch #4 got me
thinking about this again...

The real nice part is the call to devm_clk_hw_register. That uses the
new clk_hw_* apis and struct clk_hw_onecell_data, which is initialized
statically like so:

static struct clk_hw_onecell_data gxbb_hw_onecell_data = {
.hws = {
[CLKID_SYS_PLL]  = _sys_pll.hw,
[CLKID_CPUCLK]= _cpu_clk.hw,
...
},
.num = NR_CLKS,
};

Unfortunately I believe it impossible to replace NR_CLKS with some
ARRAY_SIZE stuff because C. As Stephen mentioned, please use this method
instead.

> diff --git a/include/dt-bindings/clock/sun8i-h3.h 
> b/include/dt-bindings/clock/sun8i-h3.h
> new file mode 100644
> index ..96eced56e7a2
> --- /dev/null
> +++ b/include/dt-bindings/clock/sun8i-h3.h
> @@ -0,0 +1,162 @@
> +#ifndef _DT_BINDINGS_CLK_SUN8I_H3_H_
> +#define _DT_BINDINGS_CLK_SUN8I_H3_H_
> +
> +#define 

[PATCH v2 1/2] namespaces: don't use from_k*id_munged() with init_user_ns

2016-06-24 Thread Jann Horn
For init_user_ns, from_kuid_munged() and from_kgid_munged() are
guaranteed to be identical to from_kuid() and from_kgid(). In
preparation for another patch, change all usages of the _munged
variants that explicitly use init_user_ns to the non-munged ones.

This patch by itself should not have any effect.

Signed-off-by: Jann Horn 
---
 arch/s390/hypfs/inode.c |  4 ++--
 arch/x86/kernel/vm86_32.c   |  2 +-
 drivers/connector/cn_proc.c |  8 
 fs/adfs/super.c |  4 ++--
 fs/autofs4/inode.c  |  4 ++--
 fs/cifs/cifs_spnego.c   |  4 ++--
 fs/cifs/cifsfs.c|  8 
 fs/debugfs/inode.c  |  4 ++--
 fs/devpts/inode.c   |  4 ++--
 fs/ext2/super.c |  4 ++--
 fs/ext4/super.c |  4 ++--
 fs/fat/inode.c  |  4 ++--
 fs/fuse/dev.c   |  4 ++--
 fs/fuse/inode.c |  4 ++--
 fs/hfs/super.c  |  4 ++--
 fs/hfsplus/options.c|  4 ++--
 fs/hpfs/super.c |  4 ++--
 fs/ncpfs/inode.c|  6 +++---
 fs/ntfs/inode.c |  4 ++--
 fs/proc/inode.c |  2 +-
 fs/quota/netlink.c  |  2 +-
 fs/tracefs/inode.c  |  4 ++--
 kernel/cred.c   | 16 
 mm/shmem.c  |  4 ++--
 net/netfilter/nf_log_common.c   |  4 ++--
 net/netfilter/nfnetlink_queue.c |  4 ++--
 net/netfilter/nft_meta.c|  4 ++--
 27 files changed, 62 insertions(+), 62 deletions(-)

diff --git a/arch/s390/hypfs/inode.c b/arch/s390/hypfs/inode.c
index 255c7ee..df0e2f3 100644
--- a/arch/s390/hypfs/inode.c
+++ b/arch/s390/hypfs/inode.c
@@ -259,8 +259,8 @@ static int hypfs_show_options(struct seq_file *s, struct 
dentry *root)
 {
struct hypfs_sb_info *hypfs_info = root->d_sb->s_fs_info;
 
-   seq_printf(s, ",uid=%u", from_kuid_munged(_user_ns, 
hypfs_info->uid));
-   seq_printf(s, ",gid=%u", from_kgid_munged(_user_ns, 
hypfs_info->gid));
+   seq_printf(s, ",uid=%u", from_kuid(_user_ns, hypfs_info->uid));
+   seq_printf(s, ",gid=%u", from_kgid(_user_ns, hypfs_info->gid));
return 0;
 }
 
diff --git a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c
index 3dce1ca..23d8541 100644
--- a/arch/x86/kernel/vm86_32.c
+++ b/arch/x86/kernel/vm86_32.c
@@ -259,7 +259,7 @@ static long do_sys_vm86(struct vm86plus_struct __user 
*user_vm86, bool plus)
 */
pr_info_once("Denied a call to vm86(old) from %s[%d] (uid: %d). 
 Set the vm.mmap_min_addr sysctl to 0 and/or adjust LSM mmap_min_addr policy to 
enable vm86 if you are using a vm86-based DOS emulator.\n",
 current->comm, task_pid_nr(current),
-from_kuid_munged(_user_ns, current_uid()));
+from_kuid(_user_ns, current_uid()));
return -EPERM;
}
 
diff --git a/drivers/connector/cn_proc.c b/drivers/connector/cn_proc.c
index 15d06fc..89c3b6f 100644
--- a/drivers/connector/cn_proc.c
+++ b/drivers/connector/cn_proc.c
@@ -140,11 +140,11 @@ void proc_id_connector(struct task_struct *task, int 
which_id)
rcu_read_lock();
cred = __task_cred(task);
if (which_id == PROC_EVENT_UID) {
-   ev->event_data.id.r.ruid = from_kuid_munged(_user_ns, 
cred->uid);
-   ev->event_data.id.e.euid = from_kuid_munged(_user_ns, 
cred->euid);
+   ev->event_data.id.r.ruid = from_kuid(_user_ns, cred->uid);
+   ev->event_data.id.e.euid = from_kuid(_user_ns, cred->euid);
} else if (which_id == PROC_EVENT_GID) {
-   ev->event_data.id.r.rgid = from_kgid_munged(_user_ns, 
cred->gid);
-   ev->event_data.id.e.egid = from_kgid_munged(_user_ns, 
cred->egid);
+   ev->event_data.id.r.rgid = from_kgid(_user_ns, cred->gid);
+   ev->event_data.id.e.egid = from_kgid(_user_ns, cred->egid);
} else {
rcu_read_unlock();
return;
diff --git a/fs/adfs/super.c b/fs/adfs/super.c
index c9fdfb1..48b9195 100644
--- a/fs/adfs/super.c
+++ b/fs/adfs/super.c
@@ -131,9 +131,9 @@ static int adfs_show_options(struct seq_file *seq, struct 
dentry *root)
struct adfs_sb_info *asb = ADFS_SB(root->d_sb);
 
if (!uid_eq(asb->s_uid, GLOBAL_ROOT_UID))
-   seq_printf(seq, ",uid=%u", from_kuid_munged(_user_ns, 
asb->s_uid));
+   seq_printf(seq, ",uid=%u", from_kuid(_user_ns, 
asb->s_uid));
if (!gid_eq(asb->s_gid, GLOBAL_ROOT_GID))
-   seq_printf(seq, ",gid=%u", from_kgid_munged(_user_ns, 
asb->s_gid));
+   seq_printf(seq, ",gid=%u", from_kgid(_user_ns, 
asb->s_gid));
if (asb->s_owner_mask != ADFS_DEFAULT_OWNER_MASK)
seq_printf(seq, ",ownmask=%o", asb->s_owner_mask);
if (asb->s_other_mask != ADFS_DEFAULT_OTHER_MASK)
diff --git 

[PATCH v2 2/2] namespaces: add transparent user namespaces

2016-06-24 Thread Jann Horn
This allows the admin of a user namespace to mark the namespace as
transparent. All other namespaces, by default, are opaque.

While the current behavior of user namespaces is appropriate for use in
containers, there are many programs that only use user namespaces because
doing so enables them to do other things (e.g. unsharing the mount or
network namespace) that require namespaced capabilities. For them, the
inability to see the real UIDs and GIDs of things from inside the user
namespace can be very annoying.

In a transparent namespace, all UIDs and GIDs that are mapped into its
first opaque ancestor are visible and are not remapped. This means that if
a process e.g. stat()s the real root directory in a namespace, it will
still see it as owned by UID 0.

Traditionally, any UID or GID that was visible in a user namespace was also
mapped into the namespace, giving the namespace admin full access to it.
This patch introduces a distinction: In a transparent namespace, UIDs and
GIDs can be visible without being mapped. Non-mapped, visible UIDs can be
passed from the kernel to userspace, but userspace can't send them back to
the kernel. In order to be able to fully use specific UIDs/GIDs and gain
privileges over them, mappings need to be set up in the usual way -
however, to avoid aliasing problems, only identity mappings are permitted.

v2:
Ensure that all relevant from_k[ug]id callers show up in the patch.
_transparent would be more verbose than _tp, but considering the line
length rule, that's just too long.

Yes, this makes the patch rather large.

Behavior should be the same as in v1, except that I'm not touching orangefs
in this patch because every single use of from_k[ug]id in it is wrong in
some way. (Thanks for making me reread all that stuff, Eric.) I'll write a
separate patch or at least report the issue with more detail later.

(Also, the handling of user namespaces when dealing with signals is
super-ugly and kind of incorrect. That should probably be cleaned up.)

posix_acl_to_xattr would have changed behavior in the v1 patch, but isn't
changed here. Because it's only used with init_user_ns, that won't change
user-visible behavior relative to v1.

This patch was compile-tested with allyesconfig. I also ran a VM with this
patch applied and checked that it still works, but that probably doesn't
mean much.

Signed-off-by: Jann Horn 
---
 arch/alpha/kernel/osf_sys.c   |   4 +-
 arch/arm/kernel/sys_oabi-compat.c |   4 +-
 arch/ia64/kernel/signal.c |   4 +-
 arch/s390/kernel/compat_linux.c   |  26 +++---
 arch/sparc/kernel/sys_sparc32.c   |   4 +-
 arch/x86/ia32/sys_ia32.c  |   4 +-
 drivers/android/binder.c  |   2 +-
 drivers/gpu/drm/drm_info.c|   2 +-
 drivers/gpu/drm/drm_ioctl.c   |   2 +-
 drivers/net/tun.c |   4 +-
 fs/autofs4/dev-ioctl.c|   4 +-
 fs/autofs4/waitq.c|   4 +-
 fs/binfmt_elf.c   |  12 +--
 fs/binfmt_elf_fdpic.c |  12 +--
 fs/compat.c   |   4 +-
 fs/fcntl.c|   4 +-
 fs/ncpfs/ioctl.c  |  12 +--
 fs/posix_acl.c|  11 ++-
 fs/proc/array.c   |  18 ++--
 fs/proc/base.c|  30 +--
 fs/quota/kqid.c   |  12 ++-
 fs/stat.c |  12 +--
 include/linux/uidgid.h|  24 +++--
 include/linux/user_namespace.h|   4 +
 include/net/scm.h |   4 +-
 ipc/mqueue.c  |   2 +-
 ipc/msg.c |   8 +-
 ipc/sem.c |   8 +-
 ipc/shm.c |   8 +-
 ipc/util.c|   8 +-
 kernel/acct.c |   4 +-
 kernel/exit.c |   6 +-
 kernel/groups.c   |   2 +-
 kernel/signal.c   |  16 ++--
 kernel/sys.c  |  24 ++---
 kernel/trace/trace.c  |   2 +-
 kernel/tsacct.c   |   4 +-
 kernel/uid16.c|  22 ++---
 kernel/user.c |   1 +
 kernel/user_namespace.c   | 178 +++---
 net/appletalk/atalk_proc.c|   2 +-
 net/ax25/ax25_uid.c   |   4 +-
 net/bluetooth/af_bluetooth.c  |   2 +-
 net/core/sock.c   |   4 +-
 net/ipv4/inet_diag.c  |   2 +-
 net/ipv4/ping.c   |   2 +-
 net/ipv4/raw.c|   2 +-
 net/ipv4/sysctl_net_ipv4.c|   4 +-
 net/ipv4/tcp_ipv4.c   |   6 +-
 net/ipv4/udp.c|   2 +-
 net/ipv6/datagram.c   |   2 +-
 net/ipv6/ip6_flowlabel.c  |   2 +-
 net/ipv6/tcp_ipv6.c   |   6 +-
 net/ipx/ipx_proc.c|   2 +-
 net/key/af_key.c  |   2 +-
 net/llc/llc_proc.c|   2 +-
 net/netfilter/nfnetlink_log.c |   4 +-
 net/packet/af_packet.c  

Re: [PATCH 2/2] acpi: pmic: intel: initialize result to 0

2016-06-24 Thread Rafael J. Wysocki
On Wednesday, June 22, 2016 05:55:40 PM Heikki Krogerus wrote:
> From: Felipe Balbi 
> 
> Fixes compiler warning.
> 
> Signed-off-by: Felipe Balbi 
> Signed-off-by: Heikki Krogerus 
> ---
>  drivers/acpi/pmic/intel_pmic.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/pmic/intel_pmic.c b/drivers/acpi/pmic/intel_pmic.c
> index 3a3d416..1742718 100644
> --- a/drivers/acpi/pmic/intel_pmic.c
> +++ b/drivers/acpi/pmic/intel_pmic.c
> @@ -215,7 +215,7 @@ static acpi_status intel_pmic_regs_handler(u32 function,
>   void *handler_context, void *region_context)
>  {
>   struct intel_pmic_opregion *opregion = region_context;
> - int result;
> + int result = 0;
>  
>   switch (address) {
>   case 0:

Applied, thanks!



Re: [PATCH v6 0/5] ACPI / processor_idle: Add ACPI v6.0 LPI support

2016-06-24 Thread Rafael J. Wysocki
On Thursday, June 23, 2016 02:42:57 AM Rafael J. Wysocki wrote:
> On Wednesday, June 22, 2016 06:45:15 PM Sudeep Holla wrote:
> > Hi Rafael,
> > 
> > On 14/06/16 15:48, Sudeep Holla wrote:
> > > ACPI 6.0 introduced LPI(Low Power Idle) states that provides an alternate
> > > method to describe processor idle states. It extends the specification
> > > to allow the expression of idle states like C-states selectable by the
> > > OSPM when a processor goes idle, but may affect more than one processor,
> > > and may affect other system components.
> > >
> > > LPI extensions leverages the processor container device(again introduced
> > > in ACPI 6.0) allowing to express which parts of the system are affected
> > > by a given LPI state. It defines the local power states for each node
> > > in a hierarchical processor topology. The OSPM can use _LPI object to
> > > select a local power state for each level of processor hierarchy in the
> > > system. They used to produce a composite power state request that is
> > > presented to the platform by the OSPM.
> > >
> > > Since multiple processors affect the idle state for any non-leaf hierarchy
> > > node, coordination of idle state requests between the processors is
> > > required. ACPI supports two different coordination schemes: Platform
> > > coordinated and  OS initiated.
> > >
> > > This series aims at providing basic and initial support for platform
> > > coordinated LPI states.
> > >
> > 
> > Gentle ping, was hoping to target this series for v4.8
> 
> On my list of things to take care of this week.  But this is a long list ...

Well, there are comments from Lorenzo and Daniel that need addressing,
so can you please do that and resend?

Thanks,
Rafael



[PATCH v3] HID: rmi: Make hid-rmi a transport driver for synaptics-rmi4

2016-06-24 Thread Andrew Duggan
The Synaptics RMI4 driver provides support for RMI4 devices. Instead of
duplicating the RMI4 processing code, make hid-rmi a transport driver
and register it with the Synaptics RMI4 core.

Signed-off-by: Andrew Duggan 
---
In v3 I went ahead and added RMI4_F12 to the Kconfig so we will have it
ready for Precision Touchpad. I also added documentation for xport in
rmi_data.

Also, after thinking about this a bit more I think it makes sense to
enable dribble by default. With dribble disable the device reports
a single lift event. If that report gets dropped for some reason then
that will result in stuck contacts. The downside of dribble packets is that
it increases the amount of interrupts. But, this increase is really not
significant to overall performace. I also don't think it is worth trying
to identify platforms which have issues with dropped reports so that we
can set quirks or maintain a device list to enable dribble only on those
devices.

Andrew

 drivers/hid/Kconfig   |   4 +
 drivers/hid/hid-rmi.c | 963 --
 2 files changed, 142 insertions(+), 825 deletions(-)

diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 4117225..336b79d 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -747,6 +747,10 @@ config HID_SUNPLUS
 config HID_RMI
tristate "Synaptics RMI4 device support"
depends on HID
+   select RMI4_CORE
+   select RMI4_F11
+   select RMI4_F12
+   select RMI4_F30
---help---
Support for Synaptics RMI4 touchpads.
Say Y here if you have a Synaptics RMI4 touchpads over i2c-hid or usbhid
diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
index 9cd2ca3..d2739db 100644
--- a/drivers/hid/hid-rmi.c
+++ b/drivers/hid/hid-rmi.c
@@ -19,6 +19,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include "hid-ids.h"
 
 #define RMI_MOUSE_REPORT_ID0x01 /* Mouse emulation Report */
@@ -33,9 +35,6 @@
 #define RMI_READ_DATA_PENDING  1
 #define RMI_STARTED2
 
-#define RMI_SLEEP_NORMAL   0x0
-#define RMI_SLEEP_DEEP_SLEEP   0x1
-
 /* device flags */
 #define RMI_DEVICE BIT(0)
 #define RMI_DEVICE_HAS_PHYS_BUTTONSBIT(1)
@@ -54,18 +53,10 @@ enum rmi_mode_type {
RMI_MODE_NO_PACKED_ATTN_REPORTS = 2,
 };
 
-struct rmi_function {
-   unsigned page;  /* page of the function */
-   u16 query_base_addr;/* base address for queries */
-   u16 command_base_addr;  /* base address for commands */
-   u16 control_base_addr;  /* base address for controls */
-   u16 data_base_addr; /* base address for datas */
-   unsigned int interrupt_base;/* cross-function interrupt number
-* (uniq in the device)*/
-   unsigned int interrupt_count;   /* number of interrupts */
-   unsigned int report_size;   /* size of a report */
-   unsigned long irq_mask; /* mask of the interrupts
-* (to be applied against ATTN IRQ) */
+/* Structure for storing attn report plus size of valid data in the kfifo */
+struct rmi_attn_report {
+   int size;
+   u8 data[];
 };
 
 /**
@@ -73,6 +64,7 @@ struct rmi_function {
  *
  * @page_mutex: Locks current page to avoid changing pages in unexpected ways.
  * @page: Keeps track of the current virtual page
+ * @xport: transport device to be registered with the RMI4 core.
  *
  * @wait: Used for waiting for read data
  *
@@ -84,26 +76,22 @@ struct rmi_function {
  *
  * @flags: flags for the current device (started, reading, etc...)
  *
- * @f11: placeholder of internal RMI function F11 description
- * @f30: placeholder of internal RMI function F30 description
- *
- * @max_fingers: maximum finger count reported by the device
- * @max_x: maximum x value reported by the device
- * @max_y: maximum y value reported by the device
- *
- * @gpio_led_count: count of GPIOs + LEDs reported by F30
- * @button_count: actual physical buttons count
- * @button_mask: button mask used to decode GPIO ATTN reports
- * @button_state_mask: pull state of the buttons
- *
- * @input: pointer to the kernel input device
- *
  * @reset_work: worker which will be called in case of a mouse report
+ * @attn_work: worker used for processing attention reports
  * @hdev: pointer to the struct hid_device
+ *
+ * @device_flags: flags which describe the device
+ *
+ * @attn_report_fifo: Store attn reports for deferred processing by worker
+ * @attn_report_size: size of an input report plus the size int
+ * @attn_report: buffer for storing the attn report while it is being processes
+ * @in_attn_report: buffer for storing input report plus size before adding it
+ * to the fifo.
  */
 struct rmi_data {
struct mutex page_mutex;
int page;
+   struct rmi_transport_dev xport;
 

[PATCH v2 7/8] Input: synaptics-rmi4: Handle incomplete input data

2016-06-24 Thread Andrew Duggan
Commit 5b65c2a02966 ("HID: rmi: check sanity of the incoming report") added
support for handling incomplete HID reports do to the input data being
corrupted in transit. This patch reimplements this functionality in the
function drivers so they can handle getting less valid data then they
expect.

Signed-off-by: Andrew Duggan 
---
 drivers/input/rmi4/rmi_f11.c | 54 
 drivers/input/rmi4/rmi_f12.c | 23 ++-
 drivers/input/rmi4/rmi_f30.c |  4 
 3 files changed, 61 insertions(+), 20 deletions(-)

diff --git a/drivers/input/rmi4/rmi_f11.c b/drivers/input/rmi4/rmi_f11.c
index 688e604..3fda75b 100644
--- a/drivers/input/rmi4/rmi_f11.c
+++ b/drivers/input/rmi4/rmi_f11.c
@@ -572,31 +572,48 @@ static inline u8 rmi_f11_parse_finger_state(const u8 
*f_state, u8 n_finger)
 
 static void rmi_f11_finger_handler(struct f11_data *f11,
   struct rmi_2d_sensor *sensor,
-  unsigned long *irq_bits, int num_irq_regs)
+  unsigned long *irq_bits, int num_irq_regs,
+  int size)
 {
const u8 *f_state = f11->data.f_state;
u8 finger_state;
u8 i;
+   int abs_fingers;
+   int rel_fingers;
+   int abs_size = sensor->nbr_fingers * RMI_F11_ABS_BYTES;
 
int abs_bits = bitmap_and(f11->result_bits, irq_bits, f11->abs_mask,
  num_irq_regs * 8);
int rel_bits = bitmap_and(f11->result_bits, irq_bits, f11->rel_mask,
  num_irq_regs * 8);
 
-   for (i = 0; i < sensor->nbr_fingers; i++) {
-   /* Possible of having 4 fingers per f_statet register */
-   finger_state = rmi_f11_parse_finger_state(f_state, i);
-   if (finger_state == F11_RESERVED) {
-   pr_err("Invalid finger state[%d]: 0x%02x", i,
-   finger_state);
-   continue;
-   }
+   if (abs_bits) {
+   if (abs_size > size)
+   abs_fingers = size / RMI_F11_ABS_BYTES;
+   else
+   abs_fingers = sensor->nbr_fingers;
+
+   for (i = 0; i < abs_fingers; i++) {
+   /* Possible of having 4 fingers per f_state register */
+   finger_state = rmi_f11_parse_finger_state(f_state, i);
+   if (finger_state == F11_RESERVED) {
+   pr_err("Invalid finger state[%d]: 0x%02x", i,
+   finger_state);
+   continue;
+   }
 
-   if (abs_bits)
rmi_f11_abs_pos_process(f11, sensor, >objs[i],
finger_state, i);
+   }
+   }
+
+   if (rel_bits) {
+   if ((abs_size + sensor->nbr_fingers * RMI_F11_REL_BYTES) > size)
+   rel_fingers = (size - abs_size) / RMI_F11_REL_BYTES;
+   else
+   rel_fingers = sensor->nbr_fingers;
 
-   if (rel_bits)
+   for (i = 0; i < rel_fingers; i++)
rmi_f11_rel_pos_report(f11, i);
}
 
@@ -612,7 +629,7 @@ static void rmi_f11_finger_handler(struct f11_data *f11,
  sensor->nbr_fingers,
  sensor->dmax);
 
-   for (i = 0; i < sensor->nbr_fingers; i++) {
+   for (i = 0; i < abs_fingers; i++) {
finger_state = rmi_f11_parse_finger_state(f_state, i);
if (finger_state == F11_RESERVED)
/* no need to send twice the error */
@@ -1266,10 +1283,19 @@ static int rmi_f11_attention(struct rmi_function *fn, 
unsigned long *irq_bits)
struct f11_data *f11 = dev_get_drvdata(>dev);
u16 data_base_addr = fn->fd.data_base_addr;
int error;
+   int valid_bytes = f11->sensor.pkt_size;
 
if (rmi_dev->xport->attn_data) {
+   /*
+* The valid data in the attention report is less then
+* expected. Only process the complete fingers.
+*/
+   if (f11->sensor.attn_size > rmi_dev->xport->attn_size)
+   valid_bytes = rmi_dev->xport->attn_size;
+   else
+   valid_bytes = f11->sensor.attn_size;
memcpy(f11->sensor.data_pkt, rmi_dev->xport->attn_data,
-   f11->sensor.attn_size);
+   valid_bytes);
rmi_dev->xport->attn_data += f11->sensor.attn_size;
rmi_dev->xport->attn_size -= f11->sensor.attn_size;
} else {
@@ -1281,7 +1307,7 @@ static int rmi_f11_attention(struct rmi_function *fn, 
unsigned 

[PATCH v2 8/8] Input: synaptics-rmi4: Use the RMI_F11_REL_BYTES define in rmi_f11_rel_pos_report

2016-06-24 Thread Andrew Duggan
The size of relative data in F11 is already defined by RMI_F11_REL_BYTES.
Use the define in rmi_f11_rel_pos_report() to be consistent.

Signed-off-by: Andrew Duggan 
---
 drivers/input/rmi4/rmi_f11.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/input/rmi4/rmi_f11.c b/drivers/input/rmi4/rmi_f11.c
index 3fda75b..cce82a1 100644
--- a/drivers/input/rmi4/rmi_f11.c
+++ b/drivers/input/rmi4/rmi_f11.c
@@ -530,8 +530,8 @@ static void rmi_f11_rel_pos_report(struct f11_data *f11, u8 
n_finger)
struct f11_2d_data *data = >data;
s8 x, y;
 
-   x = data->rel_pos[n_finger * 2];
-   y = data->rel_pos[n_finger * 2 + 1];
+   x = data->rel_pos[n_finger * RMI_F11_REL_BYTES];
+   y = data->rel_pos[n_finger * RMI_F11_REL_BYTES + 1];
 
rmi_2d_sensor_rel_report(sensor, x, y);
 }
-- 
2.5.0



Re: [PATCH v4 0/3] acpi/pmic: add opregion driver for Intel BXT WhiskeyCove PMIC

2016-06-24 Thread Rafael J. Wysocki
On Friday, June 24, 2016 10:25:21 AM Aaron Lu wrote:
> On 06/24/2016 08:43 AM, Bin Gao wrote:
> > This series modifies the pen function signature to take bit field
> > and adds a new opregion driver for Intel BXT WhiskeyCove PMIC. It
> > also adds support for PMIC regs operation region.
> 
> Reviewed-by: Aaron Lu 

OK, all [1-3/3] applied, thanks!



[PATCH v2 6/8] Input: synaptics-rmi4: Remove unneeded variable

2016-06-24 Thread Andrew Duggan
Remove the data_base_addr_offset variable in rmi_f11_attention(). The
f11 data is read as a single block so there is no need to store an offset
to the data address.

Signed-off-by: Andrew Duggan 
---
 drivers/input/rmi4/rmi_f11.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/input/rmi4/rmi_f11.c b/drivers/input/rmi4/rmi_f11.c
index e691432..688e604 100644
--- a/drivers/input/rmi4/rmi_f11.c
+++ b/drivers/input/rmi4/rmi_f11.c
@@ -1265,7 +1265,6 @@ static int rmi_f11_attention(struct rmi_function *fn, 
unsigned long *irq_bits)
struct rmi_driver_data *drvdata = dev_get_drvdata(_dev->dev);
struct f11_data *f11 = dev_get_drvdata(>dev);
u16 data_base_addr = fn->fd.data_base_addr;
-   u16 data_base_addr_offset = 0;
int error;
 
if (rmi_dev->xport->attn_data) {
@@ -1275,8 +1274,7 @@ static int rmi_f11_attention(struct rmi_function *fn, 
unsigned long *irq_bits)
rmi_dev->xport->attn_size -= f11->sensor.attn_size;
} else {
error = rmi_read_block(rmi_dev,
-   data_base_addr + data_base_addr_offset,
-   f11->sensor.data_pkt,
+   data_base_addr, f11->sensor.data_pkt,
f11->sensor.pkt_size);
if (error < 0)
return error;
@@ -1284,7 +1282,6 @@ static int rmi_f11_attention(struct rmi_function *fn, 
unsigned long *irq_bits)
 
rmi_f11_finger_handler(f11, >sensor, irq_bits,
drvdata->num_of_irq_regs);
-   data_base_addr_offset += f11->sensor.pkt_size;
 
return 0;
 }
-- 
2.5.0



[PATCH v2 5/8] Input: synaptics-rmi4: Remove pointer to rmi_function in f12_data

2016-06-24 Thread Andrew Duggan
The pointer to struct rmi_function in f12_data is never set and was never
used. The fn pointer is also stored in rmi_2d_sensor which is a member of
f12_data.

Signed-off-by: Andrew Duggan 
---
 drivers/input/rmi4/rmi_f12.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/input/rmi4/rmi_f12.c b/drivers/input/rmi4/rmi_f12.c
index 041a91d..7d66766 100644
--- a/drivers/input/rmi4/rmi_f12.c
+++ b/drivers/input/rmi4/rmi_f12.c
@@ -27,7 +27,6 @@ enum rmi_f12_object_type {
 };
 
 struct f12_data {
-   struct rmi_function *fn;
struct rmi_2d_sensor sensor;
struct rmi_2d_sensor_platform_data sensor_pdata;
bool has_dribble;
-- 
2.5.0



[PATCH v2 4/8] Input: synaptics-rmi4: Add support for controlling dribble packets in F12

2016-06-24 Thread Andrew Duggan
Implements reading and setting the dribble bit in F12's control registers.

Signed-off-by: Andrew Duggan 
---
 drivers/input/rmi4/rmi_f12.c | 74 +++-
 1 file changed, 73 insertions(+), 1 deletion(-)

diff --git a/drivers/input/rmi4/rmi_f12.c b/drivers/input/rmi4/rmi_f12.c
index 8dd3fb5..041a91d 100644
--- a/drivers/input/rmi4/rmi_f12.c
+++ b/drivers/input/rmi4/rmi_f12.c
@@ -30,6 +30,7 @@ struct f12_data {
struct rmi_function *fn;
struct rmi_2d_sensor sensor;
struct rmi_2d_sensor_platform_data sensor_pdata;
+   bool has_dribble;
 
u16 data_addr;
 
@@ -228,12 +229,79 @@ static int rmi_f12_attention(struct rmi_function *fn,
return 0;
 }
 
+static int rmi_f12_write_control_regs(struct rmi_function *fn)
+{
+   int ret;
+   const struct rmi_register_desc_item *item;
+   struct rmi_device *rmi_dev = fn->rmi_dev;
+   struct f12_data *f12 = dev_get_drvdata(>dev);
+   int control_size;
+   char buf[3];
+   u16 control_offset = 0;
+   u8 subpacket_offset = 0;
+
+   if (f12->has_dribble
+   && (f12->sensor.dribble != RMI_REG_STATE_DEFAULT)) {
+   item = rmi_get_register_desc_item(>control_reg_desc, 20);
+   if (item) {
+   control_offset = rmi_register_desc_calc_reg_offset(
+   >control_reg_desc, 20);
+
+   /*
+* The byte containing the EnableDribble bit will be
+* in either byte 0 or byte 2 of control 20. Depending
+* on the existence of subpacket 0. If control 20 is
+* larger then 3 bytes, just read the first 3.
+*/
+   if (item->reg_size >= 3)
+   control_size = 3;
+   else
+   control_size = item->reg_size;
+
+   ret = rmi_read_block(rmi_dev, fn->fd.control_base_addr
+   + control_offset, buf, control_size);
+   if (ret)
+   return ret;
+
+   if (rmi_register_desc_has_subpacket(item, 0))
+   subpacket_offset += 1;
+
+   switch (f12->sensor.dribble) {
+   case RMI_REG_STATE_OFF:
+   buf[subpacket_offset] &= ~BIT(2);
+   break;
+   case RMI_REG_STATE_ON:
+   buf[subpacket_offset] |= BIT(2);
+   break;
+   case RMI_REG_STATE_DEFAULT:
+   default:
+   break;
+   }
+
+   ret = rmi_write_block(rmi_dev,
+   fn->fd.control_base_addr + control_offset,
+   buf, control_size);
+   if (ret)
+   return ret;
+   }
+   }
+
+   return 0;
+
+}
+
 static int rmi_f12_config(struct rmi_function *fn)
 {
struct rmi_driver *drv = fn->rmi_dev->driver;
+   int ret;
 
drv->set_irq_bits(fn->rmi_dev, fn->irq_mask);
 
+   ret = rmi_f12_write_control_regs(fn);
+   if (ret)
+   dev_warn(>dev,
+   "Failed to write F12 control registers: %d\n", ret);
+
return 0;
 }
 
@@ -260,16 +328,19 @@ static int rmi_f12_probe(struct rmi_function *fn)
}
++query_addr;
 
-   if (!(buf & 0x1)) {
+   if (!(buf & BIT(0))) {
dev_err(>dev,
"Behavior of F12 without register descriptors is 
undefined.\n");
return -ENODEV;
}
 
+
f12 = devm_kzalloc(>dev, sizeof(struct f12_data), GFP_KERNEL);
if (!f12)
return -ENOMEM;
 
+   f12->has_dribble = !!(buf & BIT(3));
+
if (fn->dev.of_node) {
ret = rmi_2d_sensor_of_probe(>dev, >sensor_pdata);
if (ret)
@@ -318,6 +389,7 @@ static int rmi_f12_probe(struct rmi_function *fn)
 
sensor->x_mm = f12->sensor_pdata.x_mm;
sensor->y_mm = f12->sensor_pdata.y_mm;
+   sensor->dribble = f12->sensor_pdata.dribble;
 
if (sensor->sensor_type == rmi_sensor_default)
sensor->sensor_type =
-- 
2.5.0



[PATCH v2 3/8] Input: synaptics-rmi4: Add dribble and palm gesture parameters to device tree

2016-06-24 Thread Andrew Duggan
Signed-off-by: Andrew Duggan 
---
 .../devicetree/bindings/input/rmi4/rmi_2d_sensor.txt  |  4 
 drivers/input/rmi4/rmi_2d_sensor.c| 11 +++
 2 files changed, 15 insertions(+)

diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt 
b/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
index f2c30c8..86cb8e3 100644
--- a/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
+++ b/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
@@ -37,6 +37,10 @@ Optional Properties:
disable reporing absolute position data.
 - syna,rezero-wait-ms: Time in miliseconds to wait after issuing a rezero
command.
+- syna,dribble-enable: Enable reporting of dribble packets in the firmware.
+- syna,dribble-disable: Disable reporting of dribble packets in the firmware.
+- syna,palm-detect-enable: Enable reporting the palm detect gesture in the 
firmware.
+- syna,palm-detect-disable: Disable reporting the palm detect gesture in the 
firmware.
 
 
 Example of a RMI4 I2C device with F11:
diff --git a/drivers/input/rmi4/rmi_2d_sensor.c 
b/drivers/input/rmi4/rmi_2d_sensor.c
index e97bd7f..ee26e35 100644
--- a/drivers/input/rmi4/rmi_2d_sensor.c
+++ b/drivers/input/rmi4/rmi_2d_sensor.c
@@ -317,6 +317,17 @@ int rmi_2d_sensor_of_probe(struct device *dev,
 
pdata->rezero_wait = val;
 
+   if (of_property_read_bool(dev->of_node, "syna,dribble-enable"))
+   pdata->dribble = RMI_REG_STATE_ON;
+   else if (of_property_read_bool(dev->of_node, "syna,dribble-disable"))
+   pdata->dribble = RMI_REG_STATE_OFF;
+
+   if (of_property_read_bool(dev->of_node, "syna,palm-detect-enable"))
+   pdata->palm_detect = RMI_REG_STATE_ON;
+   else if (of_property_read_bool(dev->of_node,
+   "syna,palm-detect-disable"))
+   pdata->palm_detect = RMI_REG_STATE_OFF;
+
return 0;
 }
 #else
-- 
2.5.0



[PATCH v2 1/8] Input: synaptics-rmi4: Increment the refcount of the transport dev's of_node

2016-06-24 Thread Andrew Duggan
Increment the refcount for the transport device's of_node before calling
of_find_node_by_name(). Since of_find_node_by_name() assumes the refcount
was incremented by the caller and calls of_node_put() when it is done.

Signed-off-by: Andrew Duggan 
---
 drivers/input/rmi4/rmi_bus.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/input/rmi4/rmi_bus.c b/drivers/input/rmi4/rmi_bus.c
index b368b05..55b5336 100644
--- a/drivers/input/rmi4/rmi_bus.c
+++ b/drivers/input/rmi4/rmi_bus.c
@@ -157,11 +157,12 @@ static int rmi_function_match(struct device *dev, struct 
device_driver *drv)
 static void rmi_function_of_probe(struct rmi_function *fn)
 {
char of_name[9];
+   struct device_node *node = fn->rmi_dev->xport->dev->of_node;
 
snprintf(of_name, sizeof(of_name), "rmi4-f%02x",
fn->fd.function_number);
-   fn->dev.of_node = of_find_node_by_name(
-   fn->rmi_dev->xport->dev->of_node, of_name);
+   of_node_get(node);
+   fn->dev.of_node = of_find_node_by_name(node, of_name);
 }
 #else
 static inline void rmi_function_of_probe(struct rmi_function *fn)
-- 
2.5.0



[PATCH v2 2/8] Input: synaptics-rmi4: Add parameters for dribble packets and palm detect gesture

2016-06-24 Thread Andrew Duggan
The rmi_f11 driver currently disables dribble packets and the palm detect
gesture for all devices. This patch creates a parameter in the 2d sensor
platform data for controlling this functionality on a per device basis.

For more information on dribble packets:
Commit 05ba999fcabb ("HID: rmi: disable dribble packets on Synaptics
touchpads")

For more information on the palm detect gesture:
Commit f097deef59a6 ("HID: rmi: disable palm detect gesture when present")

Signed-off-by: Andrew Duggan 
---
 drivers/input/rmi4/rmi_2d_sensor.h |  2 ++
 drivers/input/rmi4/rmi_f01.c   |  6 +++---
 drivers/input/rmi4/rmi_f11.c   | 32 
 include/linux/rmi.h| 21 +
 4 files changed, 46 insertions(+), 15 deletions(-)

diff --git a/drivers/input/rmi4/rmi_2d_sensor.h 
b/drivers/input/rmi4/rmi_2d_sensor.h
index 77fcdfe..c871bef 100644
--- a/drivers/input/rmi4/rmi_2d_sensor.h
+++ b/drivers/input/rmi4/rmi_2d_sensor.h
@@ -67,6 +67,8 @@ struct rmi_2d_sensor {
u8 report_rel;
u8 x_mm;
u8 y_mm;
+   enum rmi_reg_state dribble;
+   enum rmi_reg_state palm_detect;
 };
 
 int rmi_2d_sensor_of_probe(struct device *dev,
diff --git a/drivers/input/rmi4/rmi_f01.c b/drivers/input/rmi4/rmi_f01.c
index fac81fc..2cfa9f6 100644
--- a/drivers/input/rmi4/rmi_f01.c
+++ b/drivers/input/rmi4/rmi_f01.c
@@ -327,12 +327,12 @@ static int rmi_f01_probe(struct rmi_function *fn)
}
 
switch (pdata->power_management.nosleep) {
-   case RMI_F01_NOSLEEP_DEFAULT:
+   case RMI_REG_STATE_DEFAULT:
break;
-   case RMI_F01_NOSLEEP_OFF:
+   case RMI_REG_STATE_OFF:
f01->device_control.ctrl0 &= ~RMI_F01_CTRL0_NOSLEEP_BIT;
break;
-   case RMI_F01_NOSLEEP_ON:
+   case RMI_REG_STATE_ON:
f01->device_control.ctrl0 |= RMI_F01_CTRL0_NOSLEEP_BIT;
break;
}
diff --git a/drivers/input/rmi4/rmi_f11.c b/drivers/input/rmi4/rmi_f11.c
index ec8a10d..e691432 100644
--- a/drivers/input/rmi4/rmi_f11.c
+++ b/drivers/input/rmi4/rmi_f11.c
@@ -1125,6 +1125,8 @@ static int rmi_f11_initialize(struct rmi_function *fn)
sensor->topbuttonpad = f11->sensor_pdata.topbuttonpad;
sensor->kernel_tracking = f11->sensor_pdata.kernel_tracking;
sensor->dmax = f11->sensor_pdata.dmax;
+   sensor->dribble = f11->sensor_pdata.dribble;
+   sensor->palm_detect = f11->sensor_pdata.palm_detect;
 
if (f11->sens_query.has_physical_props) {
sensor->x_mm = f11->sens_query.x_sensor_size_mm;
@@ -1192,11 +1194,33 @@ static int rmi_f11_initialize(struct rmi_function *fn)
ctrl->ctrl0_11[RMI_F11_DELTA_Y_THRESHOLD] =
sensor->axis_align.delta_y_threshold;
 
-   if (f11->sens_query.has_dribble)
-   ctrl->ctrl0_11[0] = ctrl->ctrl0_11[0] & ~BIT(6);
+   if (f11->sens_query.has_dribble) {
+   switch (sensor->dribble) {
+   case RMI_REG_STATE_OFF:
+   ctrl->ctrl0_11[0] = ctrl->ctrl0_11[0] & ~BIT(6);
+   break;
+   case RMI_REG_STATE_ON:
+   ctrl->ctrl0_11[0] = ctrl->ctrl0_11[0] | BIT(6);
+   break;
+   case RMI_REG_STATE_DEFAULT:
+   default:
+   break;
+   }
+   }
 
-   if (f11->sens_query.has_palm_det)
-   ctrl->ctrl0_11[11] = ctrl->ctrl0_11[11] & ~BIT(0);
+   if (f11->sens_query.has_palm_det) {
+   switch (sensor->palm_detect) {
+   case RMI_REG_STATE_OFF:
+   ctrl->ctrl0_11[11] = ctrl->ctrl0_11[11] & ~BIT(0);
+   break;
+   case RMI_REG_STATE_ON:
+   ctrl->ctrl0_11[11] = ctrl->ctrl0_11[11] & BIT(0);
+   break;
+   case RMI_REG_STATE_DEFAULT:
+   default:
+   break;
+   }
+   }
 
rc = f11_write_control_regs(fn, >sens_query,
   >dev_controls, fn->fd.query_base_addr);
diff --git a/include/linux/rmi.h b/include/linux/rmi.h
index e0aca14..bda72f2 100644
--- a/include/linux/rmi.h
+++ b/include/linux/rmi.h
@@ -99,6 +99,8 @@ struct rmi_2d_sensor_platform_data {
bool topbuttonpad;
bool kernel_tracking;
int dmax;
+   int dribble;
+   int palm_detect;
 };
 
 /**
@@ -116,14 +118,17 @@ struct rmi_f30_data {
bool disable;
 };
 
-/**
- * struct rmi_f01_power - override default power management settings.
- *
+
+/*
+ * Set the state of a register
+ * DEFAULT - use the default value set by the firmware config
+ * OFF - explicitly disable the register
+ * ON - explicitly enable the register
  */
-enum rmi_f01_nosleep {
-   RMI_F01_NOSLEEP_DEFAULT = 0,
-   RMI_F01_NOSLEEP_OFF = 1,
-   RMI_F01_NOSLEEP_ON = 2
+enum 

[PATCH v2 0/8] Input: synaptics-rmi4: Reimplement functionality from hid-rmi

2016-06-24 Thread Andrew Duggan
The majority of this patch is reimplementing some of the functionality
which was initially implemented in hid-rmi and reimplements it in the
core. When hid-rmi is converted into a transport for rmi_core the
functionality of existing touchpads should not change.

Several of these patches address the feedback in the message:
https://lkml.org/lkml/2016/4/12/434

I decided to go ahead and do a respin of this patch series. It includes
changes to the device tree parameters and additional feedback from the
first series. I also split out using the RMI_F11_REL_BYTES define from
patch 7 into its own patch.

Andrew Duggan (8):
  Input: synaptics-rmi4: Increment the refcount of the transport dev's
of_node
  Input: synaptics-rmi4: Add parameters for dribble packets and palm
detect gesture
  Input: synaptics-rmi4: Add dribble and palm gesture parameters to
device tree
  Input: synaptics-rmi4: Add support for controlling dribble packets in
F12
  Input: synaptics-rmi4: Remove pointer to rmi_function in f12_data
  Input: synaptics-rmi4: Remove unneeded variable
  Input: synaptics-rmi4: Handle incomplete input data
  Input: synaptics-rmi4: Use the RMI_F11_REL_BYTES define in
rmi_f11_rel_pos_report

 .../bindings/input/rmi4/rmi_2d_sensor.txt  |  4 +
 drivers/input/rmi4/rmi_2d_sensor.c | 11 +++
 drivers/input/rmi4/rmi_2d_sensor.h |  2 +
 drivers/input/rmi4/rmi_bus.c   |  5 +-
 drivers/input/rmi4/rmi_f01.c   |  6 +-
 drivers/input/rmi4/rmi_f11.c   | 95 +++--
 drivers/input/rmi4/rmi_f12.c   | 98 --
 drivers/input/rmi4/rmi_f30.c   |  4 +
 include/linux/rmi.h| 21 +++--
 9 files changed, 201 insertions(+), 45 deletions(-)

-- 
2.5.0



Re: [PATCH 07/14] regulator: SY8106A regulator driver

2016-06-24 Thread Ondřej Jirman
Hi,

thank you for the review. I've resolved most of the issues. Some more
comments below.

On 24.6.2016 05:41, Chen-Yu Tsai wrote:
> On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
>> From: Ondrej Jirman 
>>
>> SY8106A is I2C attached single output voltage regulator
>> made by Silergy.
>>
>> Signed-off-by: Ondrej Jirman 
>> ---
>>  drivers/regulator/Kconfig |   8 +-
>>  drivers/regulator/Makefile|   2 +-
>>  drivers/regulator/sy8106a-regulator.c | 153 
>> ++
>>  3 files changed, 161 insertions(+), 2 deletions(-)
>>  create mode 100644 drivers/regulator/sy8106a-regulator.c
>>
>> diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
>> index 144cbf5..fc3fae2 100644
>> --- a/drivers/regulator/Kconfig
>> +++ b/drivers/regulator/Kconfig
>> @@ -860,5 +860,11 @@ config REGULATOR_WM8994
>>   This driver provides support for the voltage regulators on the
>>   WM8994 CODEC.
>>
>> -endif
>> +config REGULATOR_SY8106A
>> +   tristate "Silergy SY8106A"
>> +   depends on I2C
> 
> Maybe you should also depend on OF since the driver is going to crippled
> without any constraints set, or (OF || COMPILE_TEST) if you want some
> compile test coverage.
> 
>> +   select REGMAP_I2C
>> +   help
>> + This driver provides support for the voltage regulator SY8106A.
>>
>> +endif
>> diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
>> index 85a1d44..f382095 100644
>> --- a/drivers/regulator/Makefile
>> +++ b/drivers/regulator/Makefile
>> @@ -110,6 +110,6 @@ obj-$(CONFIG_REGULATOR_WM831X) += wm831x-ldo.o
>>  obj-$(CONFIG_REGULATOR_WM8350) += wm8350-regulator.o
>>  obj-$(CONFIG_REGULATOR_WM8400) += wm8400-regulator.o
>>  obj-$(CONFIG_REGULATOR_WM8994) += wm8994-regulator.o
>> -
>> +obj-$(CONFIG_REGULATOR_SY8106A) += sy8106a-regulator.o
> 
> Follow the existing ordering in the Makefile.
> 
>>
>>  ccflags-$(CONFIG_REGULATOR_DEBUG) += -DDEBUG
>> diff --git a/drivers/regulator/sy8106a-regulator.c 
>> b/drivers/regulator/sy8106a-regulator.c
>> new file mode 100644
>> index 000..34bd69c
>> --- /dev/null
>> +++ b/drivers/regulator/sy8106a-regulator.c
>> @@ -0,0 +1,153 @@
>> +/*
>> + * sy8106a-regulator.c - Regulator device driver for SY8106A
>> + *
>> + * Copyright (C) 2016  Ondřej Jirman 
>> + *
>> + * This library is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU Library General Public
>> + * License as published by the Free Software Foundation; either
>> + * version 2 of the License, or (at your option) any later version.
>> + *
>> + * This library 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
>> + * Library General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU Library General Public
>> + * License along with this library; if not, write to the
>> + * Free Software Foundation, Inc., 51 Franklin St, Fifth Floor,
>> + * Boston, MA  02110-1301, USA.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
> 
> Do you need this one?
> 
>> +#include 
>> +#include 
> 
> And this one?
> 
>> +#include 
>> +#include 
> 
> Sort alphabetically please.
> 
>> +
>> +#define SY8106A_REG_VOUT1_SEL  0x01
>> +#define SY8106A_REG_VOUT_COM   0x02
>> +#define SY8106A_REG_VOUT1_SEL_MASK 0x7f
>> +#define SY8106A_DISABLE_REG0x01
> 
> BIT(0) would be clearer.
> 
>> +
>> +struct sy8106a {
>> +   struct regulator_dev *rdev;
>> +   struct regmap *regmap;
>> +};
>> +
>> +static const struct regmap_config sy8106a_regmap_config = {
>> +   .reg_bits = 8,
>> +   .val_bits = 8,
>> +};
>> +
>> +static int sy8106a_set_voltage_sel(struct regulator_dev *rdev, unsigned sel)
>> +{
>> +   return regmap_update_bits(rdev->regmap, rdev->desc->vsel_reg,
>> + 0xff, sel | 0x80);
> 
> Can you use .apply_bit / .apply_reg with regulator_set_voltage_sel_regmap?

I understand the code savings, but I'd rather avoid that, because it
would involve 2 needless readouts and rewrites of the voltage setting
register. I'd rather change this to regmap_write, so that the regulator
only receives writes over I2C, to minimize possibility of bit flip error
by minimizing the communication over the I2C bus.

>> +}
>> +
>> +static const struct regulator_ops sy8106a_ops = {
>> +   .is_enabled = regulator_is_enabled_regmap,
>> +   .set_voltage_sel = sy8106a_set_voltage_sel,
>> +   .set_voltage_time_sel = regulator_set_voltage_time_sel,
>> +   .get_voltage_sel = regulator_get_voltage_sel_regmap,
>> +   .list_voltage = regulator_list_voltage_linear,
>> +};
>> +
>> +/* Default limits measured in millivolts and milliamps */
>> +#define SY8106A_MIN_MV 680
>> 

Re: regression caused by bb6ab52f2bef ("intel_pstate: Do not set utilization update hook too early")

2016-06-24 Thread Rafael J. Wysocki
On Friday, June 17, 2016 04:09:33 PM Jisheng Zhang wrote:
> Dear all,
> 
> If using acpi-cpufreq instead, v4.6, v4.6-rc3, v4.7-rc3 can't reproduce the 
> issue. It seems
> only intel_pstate is impacted.

Which is quite obvious, since the commit your bisection led to was
intel_pstate-specific. :-)

If the issue is what I'm thinking it is, the patch below should help, so
can you please test it?

Thanks,
Rafael

---
From: Rafael J. Wysocki 
Subject: [PATCH] intel_pstate: Do not clear utilization update hooks on policy 
changes

intel_pstate_set_policy() is invoked by the cpufreq core during
driver initialization, on changes of policy attributes (minimim and
maximum frequency, for example) via sysfs and via CPU notifications
from the platform firmware.  On some platforms the latter may occur
relatively often.

Commit bb6ab52f2bef (intel_pstate: Do not set utilization update hook
too early) made intel_pstate_set_policy() clear the CPU's utilization
update hook before updating the policy attributes for it (and set the
hook again after doind that), but that involves invoking
synchronize_sched() and adds overhead to the CPU notifications
mentioned above and to the sched-RCU handling in general.

That extra overhead is arguably not necessary, because updating
policy attributes when the CPU's utilization update hook is active
should not lead to any adverse effects, so drop the clearing of
the hook from intel_pstate_set_policy() and make it check if
the hook has been set already when attempting to set it.

Fixes: bb6ab52f2bef (intel_pstate: Do not set utilization update hook too early)
Reported-by: Jisheng Zhang 
Signed-off-by: Rafael J. Wysocki 
---
 drivers/cpufreq/intel_pstate.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Index: linux-pm/drivers/cpufreq/intel_pstate.c
===
--- linux-pm.orig/drivers/cpufreq/intel_pstate.c
+++ linux-pm/drivers/cpufreq/intel_pstate.c
@@ -1440,6 +1440,9 @@ static void intel_pstate_set_update_util
 {
struct cpudata *cpu = all_cpu_data[cpu_num];
 
+   if (cpu->update_util_set)
+   return;
+
/* Prevent intel_pstate_update_util() from using stale data. */
cpu->sample.time = 0;
cpufreq_add_update_util_hook(cpu_num, >update_util,
@@ -1480,8 +1483,6 @@ static int intel_pstate_set_policy(struc
if (!policy->cpuinfo.max_freq)
return -ENODEV;
 
-   intel_pstate_clear_update_util_hook(policy->cpu);
-
pr_debug("set_policy cpuinfo.max %u policy->max %u\n",
 policy->cpuinfo.max_freq, policy->max);
 



Re: [PATCH] selftests/lib: set printf.sh executable

2016-06-24 Thread Shuah Khan
Hi SeongJae Park,

Thanks for the ping.

On 06/24/2016 05:56 PM, SeongJae Park wrote:
> Shuah,
> 
> 
> May I ask your opinion about this patch?
> 
> 
> Thanks,
> SeongJae Park
> 
> On Sun, Jun 19, 2016 at 2:50 AM, Kees Cook  wrote:
>> On Sat, Jun 18, 2016 at 2:28 AM, SeongJae Park  wrote:
>>> Test for test_printf module fails always because the test program,
>>> printf.sh, has no execution permission.  This commit adds execution
>>> permission to it.
>>>
>>> Signed-off-by: SeongJae Park 
>>
>> Acked-by: Kees Cook 
>>
>> (Is this mode change sufficient, or does the selftest infrastructure
>> need to explicitly set it executable when running?)

This is good and makes it consistent with bitmap.sh the other
shell script in this test suite. I will get this into 4.8-rc1

thanks,
-- Shuah

>>
>> -Kees
>>
>>
>>> ---
>>>  tools/testing/selftests/lib/printf.sh | 0
>>>  1 file changed, 0 insertions(+), 0 deletions(-)
>>>  mode change 100644 => 100755 tools/testing/selftests/lib/printf.sh
>>>
>>> diff --git a/tools/testing/selftests/lib/printf.sh 
>>> b/tools/testing/selftests/lib/printf.sh
>>> old mode 100644
>>> new mode 100755
>>> --
>>> 1.9.1
>>>
>>
>>
>>
>> --
>> Kees Cook
>> Chrome OS & Brillo Security



Re: regression caused by bb6ab52f2bef ("intel_pstate: Do not set utilization update hook too early")

2016-06-24 Thread Rafael J. Wysocki
On Thu, Jun 23, 2016 at 6:07 PM, Doug Smythies  wrote:
> On 2016.06.17 08:32 Jisheng Zhang wrote:
>
>> Second, sorry again for report incorrect commit,
>> I were too tired this morning so I remember the wrong commit.
>> The regression is caused by bb6ab52f2bef ("intel_pstate: Do not
>> set utilization update hook too early"), so I update the email title.
>
> Summary:
>
> Isn't running powertop itself a significant contributor here?

It shouldn't be, because the overhead in question comes from
->setpolicy and powertop itself should not cause it to be invoked that
often.

Thanks,
Rafael


Re: [GIT PULL] phy: for 4.7 -rc cycle

2016-06-24 Thread Greg KH
On Thu, Jun 23, 2016 at 11:32:18AM +0530, Kishon Vijay Abraham I wrote:
> Hi Greg,
> 
> Please find the 2nd pull request for the -rc cycle. This contains minor
> fixes in various phy drivers. I've listed the changes in the tag message.
> Consider merging it in this -rc cyle.
> 
> Please let me know if I have to change something.
> 
> Thanks
> Kishon
> 
> The following changes since commit 31b2a32f708bb33b3f35b03ce3d2cb31f7d1e684:
> 
>   phy: ti-pipe3: Program the DPLL even if it was already locked (2016-06-03 
> 12:06:41 +0530)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git 
> tags/phy-for-4.7-rc5

Pulled and pushed out, thanks.

greg k-h


Re: [PATCH] selftests/lib: set printf.sh executable

2016-06-24 Thread SeongJae Park
Shuah,


May I ask your opinion about this patch?


Thanks,
SeongJae Park

On Sun, Jun 19, 2016 at 2:50 AM, Kees Cook  wrote:
> On Sat, Jun 18, 2016 at 2:28 AM, SeongJae Park  wrote:
>> Test for test_printf module fails always because the test program,
>> printf.sh, has no execution permission.  This commit adds execution
>> permission to it.
>>
>> Signed-off-by: SeongJae Park 
>
> Acked-by: Kees Cook 
>
> (Is this mode change sufficient, or does the selftest infrastructure
> need to explicitly set it executable when running?)
>
> -Kees
>
>
>> ---
>>  tools/testing/selftests/lib/printf.sh | 0
>>  1 file changed, 0 insertions(+), 0 deletions(-)
>>  mode change 100644 => 100755 tools/testing/selftests/lib/printf.sh
>>
>> diff --git a/tools/testing/selftests/lib/printf.sh 
>> b/tools/testing/selftests/lib/printf.sh
>> old mode 100644
>> new mode 100755
>> --
>> 1.9.1
>>
>
>
>
> --
> Kees Cook
> Chrome OS & Brillo Security


Re: [RESEND PATCH 4/8] clk: core: support clocks which requires parents on (part 2)

2016-06-24 Thread Michael Turquette
Hi Dong,

Quoting Dong Aisheng (2016-04-20 02:34:36)
> On Freescale i.MX7D platform, all clocks operations, including
> enable/disable, rate change and re-parent, requires its parent clock on.
> Current clock core can not support it well.
> This patch adding flag CLK_OPS_PARENT_ON to handle this special case in
> clock core that enable its parent clock firstly for each operation and
> disable it later after operation complete.
> 
> The patch part 2 fixes set clock rate and set parent while its parent
> is off. The most special case is for set_parent() operation which requires
> all parents including both old and new one to be enabled at the same time
> during the operation.
> 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Shawn Guo 
> Signed-off-by: Dong Aisheng 
> ---
>  drivers/clk/clk.c | 45 -
>  1 file changed, 28 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 1f054d1a..d6cef61 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -1174,7 +1174,7 @@ static struct clk_core *__clk_set_parent_before(struct 
> clk_core *core,
> struct clk_core *old_parent = core->parent;
>  
> /*
> -* Migrate prepare state between parents and prevent race with
> +* 1. Migrate prepare state between parents and prevent race with
>  * clk_enable().
>  *
>  * If the clock is not prepared, then a race with
> @@ -1189,13 +1189,16 @@ static struct clk_core 
> *__clk_set_parent_before(struct clk_core *core,
>  * hardware and software states.
>  *
>  * See also: Comment for clk_set_parent() below.
> +*
> +* 2. enable parent clocks for CLK_OPS_PARENT_ON clock
>  */
> -   if (core->prepare_count) {
> -   clk_core_prepare(parent);
> -   flags = clk_enable_lock();
> -   clk_core_enable(parent);
> -   clk_core_enable(core);
> -   clk_enable_unlock(flags);
> +   if (core->prepare_count || core->flags & CLK_OPS_PARENT_ON) {
> +   clk_core_prepare_enable(parent);
> +   if (core->prepare_count)
> +   clk_core_enable_lock(core);
> +   else
> +   clk_core_prepare_enable(old_parent);

It took me a few seconds to figure out what I was looking at. The
set_parent stuff is tricky enough already ... I think we should keep the
state machine logic very simple. How about:

/* enable old_parent & parent if CLK_OPS_PARENT_ENABLE is set */
if (core->flags & CLK_OPS_PARENT_ENABLE) {
clk_core_prepare_enable(old_parent);
clk_core_prepare_enable(parent);
}

/* migrate prepare count if > 0 */
if (core->prepare_count) {
clk_core_prepare_enable(parent);
clk_core_enable_lock(core);
}

> +
> }
>  
> /* update the clk tree topology */
> @@ -1210,18 +1213,16 @@ static void __clk_set_parent_after(struct clk_core 
> *core,
>struct clk_core *parent,
>struct clk_core *old_parent)
>  {
> -   unsigned long flags;
> -
> /*
>  * Finish the migration of prepare state and undo the changes done
>  * for preventing a race with clk_enable().
>  */
> -   if (core->prepare_count) {
> -   flags = clk_enable_lock();
> -   clk_core_disable(core);
> -   clk_core_disable(old_parent);
> -   clk_enable_unlock(flags);
> -   clk_core_unprepare(old_parent);
> +   if (core->prepare_count || core->flags & CLK_OPS_PARENT_ON) {
> +   clk_core_disable_unprepare(old_parent);
> +   if (core->prepare_count)
> +   clk_core_disable_lock(core);
> +   else
> +   clk_core_disable_unprepare(parent);

Similarly, a more readable solution is:

/*
 * Finish the migration of prepare state and undo the changes done
 * for preventing a race with clk_enable().
 */
if (core->prepare_count) {
clk_core_disable_lock(core);
clk_core_disable_unprepare(old_parent);

/* re-balance ref counting if CLK_OPS_PARENT_ENABLE is set */
if (core->flags & CLK_OPS_PARENT_ENABLE) {
clk_core_disable_unprepare(parent);
clk_core_disable_unprepare(old_parent);
}

> }
>  }
>  
> @@ -1468,13 +1469,17 @@ static void clk_change_rate(struct clk_core *core)
> unsigned long best_parent_rate = 0;
> bool skip_set_rate = false;
> struct clk_core *old_parent;
> +   struct clk_core *parent = NULL;
>  
> old_rate = core->rate;
>  
> -   if (core->new_parent)
> +

[PATCH] orangefs: fix namespace handling

2016-06-24 Thread Jann Horn
In orangefs_inode_getxattr(), an fsuid is written to dmesg. The kuid is
converted to a userspace uid via from_kuid(current_user_ns(), [...]), but
since dmesg is global, init_user_ns should be used here instead.

In copy_attributes_from_inode(), op_alloc() and fill_default_sys_attrs(),
upcall structures are populated with uids/gids that have been mapped into
the caller's namespace. However, those upcall structures are read by
another process (the userspace filesystem driver), and that process might
be running in another namespace. This effectively lets any user spoof its
uid and gid as seen by the userspace filesystem driver.

To fix the second issue, I just construct the opcall structures with
init_user_ns uids/gids and require the filesystem server to run in the
init namespace. Since orangefs is full of global state anyway (as the error
message in DUMP_DEVICE_ERROR explains, there can only be one userspace
orangefs filesystem driver at once), that shouldn't be a problem.

[
Why does orangefs even exist in the kernel if everything does upcalls into
userspace? What does orangefs do that couldn't be done with the FUSE
interface? If there is no good answer to those questions, I'd prefer to see
orangefs kicked out of the kernel. Can that be done for something that
shipped in a release?

According to commit f7ab093f74bf ("Orangefs: kernel client part 1"), they
even already have a FUSE daemon, and the only rational reason (apart from
"but most of our users report preferring to use our kernel module instead")
given for not wanting to use FUSE is one "in-the-works" feature that could
probably be integated into FUSE instead.
]

This patch has been compile-tested.

Signed-off-by: Jann Horn 
---
 fs/orangefs/devorangefs-req.c | 7 +++
 fs/orangefs/orangefs-cache.c  | 4 ++--
 fs/orangefs/orangefs-kernel.h | 4 ++--
 fs/orangefs/orangefs-utils.c  | 4 ++--
 fs/orangefs/xattr.c   | 4 ++--
 5 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/fs/orangefs/devorangefs-req.c b/fs/orangefs/devorangefs-req.c
index db170be..a287a66 100644
--- a/fs/orangefs/devorangefs-req.c
+++ b/fs/orangefs/devorangefs-req.c
@@ -116,6 +116,13 @@ static int orangefs_devreq_open(struct inode *inode, 
struct file *file)
 {
int ret = -EINVAL;
 
+   /* in order to ensure that the filesystem driver sees correct UIDs */
+   if (file->f_cred->user_ns != _user_ns) {
+   gossip_err("%s: device cannot be opened outside init_user_ns\n",
+  __func__);
+   goto out;
+   }
+
if (!(file->f_flags & O_NONBLOCK)) {
gossip_err("%s: device cannot be opened in blocking mode\n",
   __func__);
diff --git a/fs/orangefs/orangefs-cache.c b/fs/orangefs/orangefs-cache.c
index 900a2e3..b6edbe9 100644
--- a/fs/orangefs/orangefs-cache.c
+++ b/fs/orangefs/orangefs-cache.c
@@ -136,10 +136,10 @@ struct orangefs_kernel_op_s *op_alloc(__s32 type)
 llu(new_op->tag),
 get_opname_string(new_op));
 
-   new_op->upcall.uid = from_kuid(current_user_ns(),
+   new_op->upcall.uid = from_kuid(_user_ns,
   current_fsuid());
 
-   new_op->upcall.gid = from_kgid(current_user_ns(),
+   new_op->upcall.gid = from_kgid(_user_ns,
   current_fsgid());
} else {
gossip_err("op_alloc: kmem_cache_zalloc failed!\n");
diff --git a/fs/orangefs/orangefs-kernel.h b/fs/orangefs/orangefs-kernel.h
index 2281882..a6834d4 100644
--- a/fs/orangefs/orangefs-kernel.h
+++ b/fs/orangefs/orangefs-kernel.h
@@ -600,8 +600,8 @@ int service_operation(struct orangefs_kernel_op_s *op,
 
 #define fill_default_sys_attrs(sys_attr, type, mode)   \
 do {   \
-   sys_attr.owner = from_kuid(current_user_ns(), current_fsuid()); \
-   sys_attr.group = from_kgid(current_user_ns(), current_fsgid()); \
+   sys_attr.owner = from_kuid(_user_ns, current_fsuid()); \
+   sys_attr.group = from_kgid(_user_ns, current_fsgid()); \
sys_attr.perms = ORANGEFS_util_translate_mode(mode);\
sys_attr.mtime = 0; \
sys_attr.atime = 0; \
diff --git a/fs/orangefs/orangefs-utils.c b/fs/orangefs/orangefs-utils.c
index 2d129b5..c5fbc62 100644
--- a/fs/orangefs/orangefs-utils.c
+++ b/fs/orangefs/orangefs-utils.c
@@ -153,12 +153,12 @@ static inline int copy_attributes_from_inode(struct inode 
*inode,
 */
attrs->mask = 0;
if (iattr->ia_valid & ATTR_UID) {
-   attrs->owner = from_kuid(current_user_ns(), iattr->ia_uid);
+   attrs->owner = from_kuid(_user_ns, iattr->ia_uid);
attrs->mask |= ORANGEFS_ATTR_SYS_UID;
  

Re: [RESEND PATCH 3/8] clk: core: support clocks which requires parents on (part 1)

2016-06-24 Thread Michael Turquette
Quoting Dong Aisheng (2016-04-20 02:34:35)
> On Freescale i.MX7D platform, all clocks operations, including
> enable/disable, rate change and re-parent, requires its parent
> clock on. Current clock core can not support it well.
> This patch introduce a new flag CLK_OPS_PARENT_ON to handle this
> special case in clock core that enable its parent clock firstly for
> each operation and disable it later after operation complete.
> 
> The patch part 1 fixes the possible disabling clocks while its parent
> is off during kernel booting phase in clk_disable_unused_subtree().
> 
> Before the completion of kernel booting, clock tree is still not built
> completely, there may be a case that the child clock is on but its
> parent is off which could be caused by either HW initial reset state
> or bootloader initialization.
> 
> Taking bootloader as an example, we may enable all clocks in HW by default.
> And during kernel booting time, the parent clock could be disabled in its
> driver probe due to calling clk_prepare_enable and clk_disable_unprepare.
> Because it's child clock is only enabled in HW while its SW usecount
> in clock tree is still 0, so clk_disable of parent clock will gate
> the parent clock in both HW and SW usecount ultimately. Then there will
> be a child clock is still on in HW but its parent is already off.
> 
> Later in clk_disable_unused(), this clock disable accessing while its
> parent off will cause system hang due to the limitation of HW which
> must require its parent on.
> 
> This patch simply enables the parent clock first before disabling
> if flag CLK_OPS_PARENT_ON is set in clk_disable_unused_subtree().
> This is a simple solution and only affects booting time.
> 
> After kernel booting up the clock tree is already created, there will
> be no case that child is off but its parent is off.
> So no need do this checking for normal clk_disable() later.
> 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Shawn Guo 
> Signed-off-by: Dong Aisheng 
> ---
>  drivers/clk/clk.c| 5 +
>  include/linux/clk-provider.h | 2 ++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 9f944d4..1f054d1a 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -765,6 +765,9 @@ static void clk_disable_unused_subtree(struct clk_core 
> *core)
> hlist_for_each_entry(child, >children, child_node)
> clk_disable_unused_subtree(child);
>  
> +   if (core->flags & CLK_OPS_PARENT_ON)
> +   clk_core_prepare_enable(core->parent);
> +
> flags = clk_enable_lock();
>  
> if (core->enable_count)
> @@ -789,6 +792,8 @@ static void clk_disable_unused_subtree(struct clk_core 
> *core)
>  
>  unlock_out:
> clk_enable_unlock(flags);
> +   if (core->flags & CLK_OPS_PARENT_ON)
> +   clk_core_disable_unprepare(core->parent);
>  }
>  
>  static bool clk_ignore_unused;
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index 15628644..c878f9c 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -33,6 +33,8 @@
>  #define CLK_RECALC_NEW_RATES   BIT(9) /* recalc rates after notifications */
>  #define CLK_SET_RATE_UNGATEBIT(10) /* clock needs to run to set rate */
>  #define CLK_IS_CRITICALBIT(11) /* do not gate, ever */
> +/* parents need on during gate/ungate, set rate and re-parent */
> +#define CLK_OPS_PARENT_ON  BIT(12)

Hi Dong,

In the clk framework we use "enabled" instead of "on". How about
changing the flag to CLK_OPS_PARENT_ENABLE?

Regards,
Mike

>  
>  struct clk;
>  struct clk_hw;
> -- 
> 1.9.1
> 


Re: [PATCH perf/core v12 00/16] perf-probe --cache and SDT support

2016-06-24 Thread Masami Hiramatsu
On Fri, 24 Jun 2016 13:25:20 -0700
Brendan Gregg  wrote:

> On Fri, Jun 24, 2016 at 2:05 AM, Masami Hiramatsu  wrote:
> > Hi,
> >
> > Here is the 12th version of the patchset for probe-cache and
> > initial SDT support.
> >
> > Here is the previous v11: https://lkml.org/lkml/2016/6/14/1041
> >
> > In this version I just rename strlist__for_each to
> > strlist__for_each_entry, and change some patch description.
> >
> 
> I tested it on Node.js (and applied to acme's perf/core), and it works. 
> Thanks!
> 
> # perf script
> node 36750 [006]  3080.761533:
> sdt_node:http__server__request: (da8b0c)
> node 36750 [006]  3081.368771:
> sdt_node:http__server__request: (da8b0c)
> node 36750 [006]  3081.592925:
> sdt_node:http__server__request: (da8b0c)
> node 36750 [006]  3081.976802:
> sdt_node:http__server__request: (da8b0c)
> node 36750 [006]  3082.296709:
> sdt_node:http__server__request: (da8b0c)
> 
> Since it doesn't set the is-enabled semaphore yet, I had to do that
> manually for the probes that use it. I know that will be a latter
> addition.

Yes, I'd like to support it. However, the question is who should enable it.

To enable it from perf, perf must attach the target running processes
and change the semaphore. If we run "perf record -a", it has to check
all the running process and tweak it. Moreover, it may have to hook
the execve syscall.

To enable it from kernel, hooking the target process is easier, since
we already did it in uprobes. However, it means we'll introduce a
special functionality to tweak user binary, and of course it may
need to understand SDT section to find out the semaphore.

So, one possible solution is, adding a semaphore option(like an address)
to uprobe events and enable it via ftrace. On this way, perf just
analyzes SDT and pass the semaphore address to ftrace when defining
a probe, and ftrace set 1 to the semaphre address.

> 
> # perf list | grep sdt
>   sdt_node:http__client__request [Tracepoint event]
>   sdt_node:http__server__request [Tracepoint event]
>   sdt_node:gc__done  [SDT event]
>   sdt_node:gc__start [SDT event]
>   sdt_node:http__client__request [SDT event]
>   sdt_node:http__client__response[SDT event]
>   sdt_node:http__server__request [SDT event]
>   sdt_node:http__server__response[SDT event]
>   sdt_node:net__server__connection   [SDT event]
>   sdt_node:net__stream__end  [SDT event]
> 
> It's also a bit weird to see these listed twice, but I understand
> what's happening. If this continues to prove confusing, I guess later
> on we could change it to exclude listing SDT events that have been
> promoted to Tracepoint events, or not list SDT events in "perf list"
> at all, leaving them for "perf probe --cache --list".

Ah, right. Hmm, at this point, I'd like latter method, since perf
record doesn't support SDT directly yet. So we just need to drop
08/16 and 09/16. It should be implemented with perf-record support.

Thank you!

> 
> Anyway, this is great as is, and thanks again.
> 
> Brendan
> 
> 
> > Thank you,
> >
> > ---
> >
> > Hemant Kumar (1):
> >   perf/sdt: ELF support for SDT
> >
> > Masami Hiramatsu (15):
> >   perf probe: Use cache entry if possible
> >   perf probe: Show all cached probes
> >   perf probe: Remove caches when --cache is given
> >   perf probe: Add group name support
> >   perf buildid-cache: Scan and import user SDT events to probe cache
> >   perf probe: Accept %sdt and %cached event name
> >   perf-list: Show SDT and pre-cached events
> >   perf-list: Skip SDTs placed in invalid binaries
> >   perf: probe-cache: Add for_each_probe_cache_entry() wrapper
> >   perf probe: Allow wildcard for cached events
> >   perf probe: Search SDT/cached event from all probe caches
> >   perf probe: Support @BUILDID or @FILE suffix for SDT events
> >   perf probe: Support a special SDT probe format
> >   perf build: Add sdt feature detection
> >   perf-test: Add a test case for SDT event
> >
> >
> >  tools/perf/Documentation/perf-buildid-cache.txt |3
> >  tools/perf/Documentation/perf-probe.txt |   30 +-
> >  tools/perf/Makefile.perf|3
> >  tools/perf/builtin-list.c   |6
> >  tools/perf/builtin-probe.c  |   31 ++
> >  tools/perf/config/Makefile  |   10 +
> >  tools/perf/tests/Build  |1
> >  tools/perf/tests/builtin-test.c |4
> >  tools/perf/tests/make   |3
> >  tools/perf/tests/sdt.c  |  115 +++
> >  tools/perf/tests/tests.h|1
> 

[PATCH v5 3/3] LSM: Add context interface for proc attrs

2016-06-24 Thread Casey Schaufler
Subject: [PATCH v5 3/3] LSM: Add context interface for proc attrs

(I sent this with the wrong version number. This is the same otherwise)

The /proc/.../attr/current interface is used by all three
Linux security modules (SELinux, Smack and AppArmor) to
report and modify the process security attribute. This is
all fine when there is exactly one of these modules active
and the userspace code knows which it module it is.
It would require a major change to the "current" interface
to provide information about more than one set of process
security attributes. Instead, a "context" attribute is
added, which identifies the security module that the
information applies to. The format is:

lsmname='context-value'

When multiple concurrent modules are supported the
/proc/.../attr/context interface will include the data
for all of the active modules.

lsmname1='context-value1',lsmname2='context-value2'

The module specific subdirectories under attr contain context
entries that report the information for that specific module
in the same format.

Signed-off-by: Casey Schaufler 

---
 Documentation/security/LSM.txt |   8 +++
 fs/proc/base.c |   4 ++
 security/apparmor/lsm.c|  35 +++--
 security/security.c| 108 +
 security/selinux/hooks.c   |  20 +++-
 security/smack/smack_lsm.c |  20 
 6 files changed, 180 insertions(+), 15 deletions(-)

diff --git a/Documentation/security/LSM.txt b/Documentation/security/LSM.txt
index 125c489..af3eb11 100644
--- a/Documentation/security/LSM.txt
+++ b/Documentation/security/LSM.txt
@@ -36,6 +36,14 @@ for SELinux would be in /proc/.../attr/selinux. Using the 
files
 found directly in /proc/.../attr (e.g. current) should be avoided.
 These files remain as legacy interfaces.
 
+The files named "context" in the attr directories contain the
+same information as the "current" files, but formatted to
+identify the module it comes from.
+
+if selinux is the active security module:
+   /proc/self/attr/context could contain selinux='unconfined_t'
+   /proc/self/attr/selinux/context could contain selinux='unconfined_t'
+
 Based on https://lkml.org/lkml/2007/10/26/215,
 a new LSM is accepted into the kernel when its intent (a description of
 what it tries to protect against and in what cases one would expect to
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 182bc28..df94f26 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2532,6 +2532,7 @@ static const struct pid_entry selinux_attr_dir_stuff[] = {
ATTR("selinux", "fscreate", S_IRUGO|S_IWUGO),
ATTR("selinux", "keycreate",S_IRUGO|S_IWUGO),
ATTR("selinux", "sockcreate",   S_IRUGO|S_IWUGO),
+   ATTR("selinux", "context",  S_IRUGO|S_IWUGO),
 };
 LSM_DIR_OPS(selinux);
 #endif
@@ -2539,6 +2540,7 @@ LSM_DIR_OPS(selinux);
 #ifdef CONFIG_SECURITY_SMACK
 static const struct pid_entry smack_attr_dir_stuff[] = {
ATTR("smack", "current",S_IRUGO|S_IWUGO),
+   ATTR("smack", "context",S_IRUGO|S_IWUGO),
 };
 LSM_DIR_OPS(smack);
 #endif
@@ -2548,6 +2550,7 @@ static const struct pid_entry apparmor_attr_dir_stuff[] = 
{
ATTR("apparmor", "current", S_IRUGO|S_IWUGO),
ATTR("apparmor", "prev",S_IRUGO),
ATTR("apparmor", "exec",S_IRUGO|S_IWUGO),
+   ATTR("apparmor", "context", S_IRUGO|S_IWUGO),
 };
 LSM_DIR_OPS(apparmor);
 #endif
@@ -2559,6 +2562,7 @@ static const struct pid_entry attr_dir_stuff[] = {
ATTR(NULL, "fscreate",  S_IRUGO|S_IWUGO),
ATTR(NULL, "keycreate", S_IRUGO|S_IWUGO),
ATTR(NULL, "sockcreate",S_IRUGO|S_IWUGO),
+   ATTR(NULL, "context",   S_IRUGO|S_IWUGO),
 #ifdef CONFIG_SECURITY_SELINUX
DIR("selinux",  S_IRUGO|S_IXUGO,
proc_selinux_attr_dir_inode_ops, proc_selinux_attr_dir_ops),
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index fb0fb03..5cac15f 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -476,9 +476,13 @@ static int apparmor_getprocattr(struct task_struct *task, 
char *name,
const struct cred *cred = get_task_cred(task);
struct aa_task_cxt *cxt = cred_cxt(cred);
struct aa_profile *profile = NULL;
+   char *vp;
+   char *np;
 
if (strcmp(name, "current") == 0)
profile = aa_get_newest_profile(cxt->profile);
+   else if (strcmp(name, "context") == 0)
+   profile = aa_get_newest_profile(cxt->profile);
else if (strcmp(name, "prev") == 0  && cxt->previous)
profile = aa_get_newest_profile(cxt->previous);
else if (strcmp(name, "exec") == 0 && cxt->onexec)
@@ -486,9 +490,29 @@ static int apparmor_getprocattr(struct task_struct *task, 
char *name,
else
error = -EINVAL;
 
-   if (profile)
-   error = 

Re: [PATCH v8 4/4] Input: synaptics-rmi4 - add SMBus support

2016-06-24 Thread Dmitry Torokhov
On Fri, Jun 24, 2016 at 09:19:32AM +0200, Benjamin Tissoires wrote:
> On Jun 23 2016 or thereabouts, Dmitry Torokhov wrote:
> > On Thu, Jun 09, 2016 at 04:53:50PM +0200, Benjamin Tissoires wrote:
> > > +
> > > +static struct i2c_driver rmi_smb_driver = {
> > > + .driver = {
> > > + .owner  = THIS_MODULE,
> > > + .name   = "rmi4_smbus",
> > > + .pm = _smb_pm,
> > > + .resume = rmi_smb_resume,
> > 
> > Why rmi_smb_resume is not part of rmi_smb_pm?
> > 
> 
> This is because rmi_smbus device both have a PS/2 interface and a SMBus
> one. I'll have to check again now that I have a slightly different way
> of binding smbus devices in my tree, but the issue was:
> - having resume part of pm means it will get caught by PM directly
> - the PS/2 node gets also resumed by PM
> - calling PS/2 commands during resume switches the devices back into
>   PS/2 and stops the SMBus communication.
> 
> So it's easier to wait only for the PS/2 PM resume call which will call
> the SMBus resume function when the device is in a proper state.
> 
> I'll send out the updated patch with your comments next week hopefully.

Hmm, I think you will have to walk me through resume process. How do we
tie in PS/2 and I2C on these devices abd have PS/2 code call into this
driver?

Thanks.

-- 
Dmitry


[PATCH v4 3/3] LSM: Add context interface for proc attrs

2016-06-24 Thread Casey Schaufler
Subject: [PATCH v4 3/3] LSM: Add context interface for proc attrs

The /proc/.../attr/current interface is used by all three
Linux security modules (SELinux, Smack and AppArmor) to
report and modify the process security attribute. This is
all fine when there is exactly one of these modules active
and the userspace code knows which it module it is.
It would require a major change to the "current" interface
to provide information about more than one set of process
security attributes. Instead, a "context" attribute is
added, which identifies the security module that the
information applies to. The format is:

lsmname='context-value'

When multiple concurrent modules are supported the
/proc/.../attr/context interface will include the data
for all of the active modules.

lsmname1='context-value1',lsmname2='context-value2'

The module specific subdirectories under attr contain context
entries that report the information for that specific module
in the same format.

Signed-off-by: Casey Schaufler 

---
 Documentation/security/LSM.txt |   8 +++
 fs/proc/base.c |   4 ++
 security/apparmor/lsm.c|  35 +++--
 security/security.c| 108 +
 security/selinux/hooks.c   |  20 +++-
 security/smack/smack_lsm.c |  20 
 6 files changed, 180 insertions(+), 15 deletions(-)

diff --git a/Documentation/security/LSM.txt b/Documentation/security/LSM.txt
index 125c489..af3eb11 100644
--- a/Documentation/security/LSM.txt
+++ b/Documentation/security/LSM.txt
@@ -36,6 +36,14 @@ for SELinux would be in /proc/.../attr/selinux. Using the 
files
 found directly in /proc/.../attr (e.g. current) should be avoided.
 These files remain as legacy interfaces.
 
+The files named "context" in the attr directories contain the
+same information as the "current" files, but formatted to
+identify the module it comes from.
+
+if selinux is the active security module:
+   /proc/self/attr/context could contain selinux='unconfined_t'
+   /proc/self/attr/selinux/context could contain selinux='unconfined_t'
+
 Based on https://lkml.org/lkml/2007/10/26/215,
 a new LSM is accepted into the kernel when its intent (a description of
 what it tries to protect against and in what cases one would expect to
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 182bc28..df94f26 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2532,6 +2532,7 @@ static const struct pid_entry selinux_attr_dir_stuff[] = {
ATTR("selinux", "fscreate", S_IRUGO|S_IWUGO),
ATTR("selinux", "keycreate",S_IRUGO|S_IWUGO),
ATTR("selinux", "sockcreate",   S_IRUGO|S_IWUGO),
+   ATTR("selinux", "context",  S_IRUGO|S_IWUGO),
 };
 LSM_DIR_OPS(selinux);
 #endif
@@ -2539,6 +2540,7 @@ LSM_DIR_OPS(selinux);
 #ifdef CONFIG_SECURITY_SMACK
 static const struct pid_entry smack_attr_dir_stuff[] = {
ATTR("smack", "current",S_IRUGO|S_IWUGO),
+   ATTR("smack", "context",S_IRUGO|S_IWUGO),
 };
 LSM_DIR_OPS(smack);
 #endif
@@ -2548,6 +2550,7 @@ static const struct pid_entry apparmor_attr_dir_stuff[] = 
{
ATTR("apparmor", "current", S_IRUGO|S_IWUGO),
ATTR("apparmor", "prev",S_IRUGO),
ATTR("apparmor", "exec",S_IRUGO|S_IWUGO),
+   ATTR("apparmor", "context", S_IRUGO|S_IWUGO),
 };
 LSM_DIR_OPS(apparmor);
 #endif
@@ -2559,6 +2562,7 @@ static const struct pid_entry attr_dir_stuff[] = {
ATTR(NULL, "fscreate",  S_IRUGO|S_IWUGO),
ATTR(NULL, "keycreate", S_IRUGO|S_IWUGO),
ATTR(NULL, "sockcreate",S_IRUGO|S_IWUGO),
+   ATTR(NULL, "context",   S_IRUGO|S_IWUGO),
 #ifdef CONFIG_SECURITY_SELINUX
DIR("selinux",  S_IRUGO|S_IXUGO,
proc_selinux_attr_dir_inode_ops, proc_selinux_attr_dir_ops),
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index fb0fb03..5cac15f 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -476,9 +476,13 @@ static int apparmor_getprocattr(struct task_struct *task, 
char *name,
const struct cred *cred = get_task_cred(task);
struct aa_task_cxt *cxt = cred_cxt(cred);
struct aa_profile *profile = NULL;
+   char *vp;
+   char *np;
 
if (strcmp(name, "current") == 0)
profile = aa_get_newest_profile(cxt->profile);
+   else if (strcmp(name, "context") == 0)
+   profile = aa_get_newest_profile(cxt->profile);
else if (strcmp(name, "prev") == 0  && cxt->previous)
profile = aa_get_newest_profile(cxt->previous);
else if (strcmp(name, "exec") == 0 && cxt->onexec)
@@ -486,9 +490,29 @@ static int apparmor_getprocattr(struct task_struct *task, 
char *name,
else
error = -EINVAL;
 
-   if (profile)
-   error = aa_getprocattr(profile, value);
+   if (profile == NULL)
+   goto put_out;

[PATCH v5 2/3] LSM: module hierarchy in /proc/.../attr

2016-06-24 Thread Casey Schaufler
Subject: [PATCH v5 2/3] LSM: module hierarchy in /proc/.../attr

Back in 2007 I made what turned out to be a rather serious
mistake in the implementation of the Smack security module.
The SELinux module used an interface in /proc to manipulate
the security context on processes. Rather than use a similar
interface, I used the same interface. The AppArmor team did
likewise. Now /proc/.../attr/current will tell you the
security "context" of the process, but it will be different
depending on the security module you're using. That hasn't
been a problem to date, as you can only have one module
that supports process attributes at a time. We are coming
up on a change to that, where multiple modules with process
attributes can be supported. (Not included here)

This patch provides a subdirectory in /proc/.../attr for
each of the security modules that use the LSM hooks
getprocattr() and setprocattr(). Each of the interfaces
used by a module are presented in the subdirectory. The
old interfaces remain and work the same as before.
User space code can begin migrating to the subdirectory
interfaces in anticipation of the time when what comes
from /proc/self/attr/current might not be what a runtime
wants.

The original implementation is by Kees Cook. The code
has been changed a bit to reflect changes in the direction
of the multiple concurrent module work, to be independent
of it, and to bring it up to date with the current tree.

Signed-off-by: Casey Schaufler 

---
 Documentation/security/LSM.txt | 19 ++---
 fs/proc/base.c | 91 +-
 fs/proc/internal.h |  1 +
 include/linux/security.h   | 15 ---
 security/security.c| 31 --
 5 files changed, 133 insertions(+), 24 deletions(-)

diff --git a/Documentation/security/LSM.txt b/Documentation/security/LSM.txt
index c2683f2..125c489 100644
--- a/Documentation/security/LSM.txt
+++ b/Documentation/security/LSM.txt
@@ -16,11 +16,10 @@ MAC extensions, other extensions can be built using the LSM 
to provide
 specific changes to system operation when these tweaks are not available
 in the core functionality of Linux itself.
 
-Without a specific LSM built into the kernel, the default LSM will be the
-Linux capabilities system. Most LSMs choose to extend the capabilities
-system, building their checks on top of the defined capability hooks.
-For more details on capabilities, see capabilities(7) in the Linux
-man-pages project.
+The Linux capabilities modules will always be included. For more details
+on capabilities, see capabilities(7) in the Linux man-pages project.
+This may be followed by any number of "minor" modules and at most one
+"major" module.
 
 A list of the active security modules can be found by reading
 /sys/kernel/security/lsm. This is a comma separated list, and
@@ -29,6 +28,14 @@ order in which checks are made. The capability module will 
always
 be first, followed by any "minor" modules (e.g. Yama) and then
 the one "major" module (e.g. SELinux) if there is one configured.
 
+Process attributes associated with "major" security modules should
+be accessed and maintained using the special files in the module
+specific subdirectories in /proc/.../attr. The attributes related
+to Smack would be found in /proc/.../attr/smack while the attributes
+for SELinux would be in /proc/.../attr/selinux. Using the files
+found directly in /proc/.../attr (e.g. current) should be avoided.
+These files remain as legacy interfaces.
+
 Based on https://lkml.org/lkml/2007/10/26/215,
 a new LSM is accepted into the kernel when its intent (a description of
 what it tries to protect against and in what cases one would expect to
@@ -38,4 +45,4 @@ that end users and distros can make a more informed decision 
about which
 LSMs suit their requirements.
 
 For extensive documentation on the available LSM hook interfaces, please
-see include/linux/security.h.
+see include/linux/lsm_hooks.h.
diff --git a/fs/proc/base.c b/fs/proc/base.c
index a11eb71..182bc28 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -131,9 +131,13 @@ struct pid_entry {
 #define REG(NAME, MODE, fops)  \
NOD(NAME, (S_IFREG|(MODE)), NULL, , {})
 #define ONE(NAME, MODE, show)  \
-   NOD(NAME, (S_IFREG|(MODE)), \
+   NOD(NAME, (S_IFREG|(MODE)), \
NULL, _single_file_operations, \
{ .proc_show = show } )
+#define ATTR(LSM, NAME, MODE)  \
+   NOD(NAME, (S_IFREG|(MODE)), \
+   NULL, _pid_attr_operations,\
+   { .lsm = LSM })
 
 /*
  * Count the number of hardlinks for the pid_entry table, excluding the .
@@ -2433,7 +2437,7 @@ static ssize_t proc_pid_attr_read(struct file * file, 
char __user * buf,
if (!task)
return -ESRCH;
 
-   length = 

[PATCH v5 1/3] LSM: Add /sys/kernel/security/lsm

2016-06-24 Thread Casey Schaufler
Subject: [PATCH v5 1/3] LSM: Add /sys/kernel/security/lsm

I got tired of having to find indirect ways to 
determine what security modules are active on a system.
I have added /sys/kernel/security/lsm, which contains a
comma separated list of the active security modules. No
more groping around in /proc/filesystems, which won't
help if the module doesn't support its own filesystem.

Signed-off-by: Casey Schaufler 

---
 Documentation/security/LSM.txt |  7 +++
 include/linux/lsm_hooks.h  | 12 
 security/apparmor/lsm.c|  3 ++-
 security/commoncap.c   |  3 ++-
 security/inode.c   | 26 --
 security/loadpin/loadpin.c |  2 +-
 security/security.c| 38 ++
 security/selinux/hooks.c   |  2 +-
 security/smack/smack_lsm.c |  2 +-
 security/tomoyo/tomoyo.c   |  2 +-
 security/yama/yama_lsm.c   |  2 +-
 11 files changed, 82 insertions(+), 17 deletions(-)

diff --git a/Documentation/security/LSM.txt b/Documentation/security/LSM.txt
index 3db7e67..c2683f2 100644
--- a/Documentation/security/LSM.txt
+++ b/Documentation/security/LSM.txt
@@ -22,6 +22,13 @@ system, building their checks on top of the defined 
capability hooks.
 For more details on capabilities, see capabilities(7) in the Linux
 man-pages project.
 
+A list of the active security modules can be found by reading
+/sys/kernel/security/lsm. This is a comma separated list, and
+will always include the capability module. The list reflects the
+order in which checks are made. The capability module will always
+be first, followed by any "minor" modules (e.g. Yama) and then
+the one "major" module (e.g. SELinux) if there is one configured.
+
 Based on https://lkml.org/lkml/2007/10/26/215,
 a new LSM is accepted into the kernel when its intent (a description of
 what it tries to protect against and in what cases one would expect to
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 7ae3976..0bfd441 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -1841,6 +1841,7 @@ struct security_hook_list {
struct list_headlist;
struct list_head*head;
union security_list_options hook;
+   char*lsm;
 };
 
 /*
@@ -1853,15 +1854,10 @@ struct security_hook_list {
{ .head = _hook_heads.HEAD, .hook = { .HEAD = HOOK } }
 
 extern struct security_hook_heads security_hook_heads;
+extern char *lsm_names;
 
-static inline void security_add_hooks(struct security_hook_list *hooks,
- int count)
-{
-   int i;
-
-   for (i = 0; i < count; i++)
-   list_add_tail_rcu([i].list, hooks[i].head);
-}
+extern void security_add_hooks(struct security_hook_list *hooks, int count,
+   char *lsm);
 
 #ifdef CONFIG_SECURITY_SELINUX_DISABLE
 /*
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 2660fbc..fb0fb03 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -880,7 +880,8 @@ static int __init apparmor_init(void)
aa_free_root_ns();
goto alloc_out;
}
-   security_add_hooks(apparmor_hooks, ARRAY_SIZE(apparmor_hooks));
+   security_add_hooks(apparmor_hooks, ARRAY_SIZE(apparmor_hooks),
+   "apparmor");
 
/* Report that AppArmor successfully initialized */
apparmor_initialized = 1;
diff --git a/security/commoncap.c b/security/commoncap.c
index e7fadde..d101734 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -1090,7 +1090,8 @@ struct security_hook_list capability_hooks[] = {
 
 void __init capability_add_hooks(void)
 {
-   security_add_hooks(capability_hooks, ARRAY_SIZE(capability_hooks));
+   security_add_hooks(capability_hooks, ARRAY_SIZE(capability_hooks),
+   "capability");
 }
 
 #endif /* CONFIG_SECURITY */
diff --git a/security/inode.c b/security/inode.c
index 28414b0..235ad82 100644
--- a/security/inode.c
+++ b/security/inode.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static struct vfsmount *mount;
@@ -208,6 +209,21 @@ void securityfs_remove(struct dentry *dentry)
 }
 EXPORT_SYMBOL_GPL(securityfs_remove);
 
+#ifdef CONFIG_SECURITY
+static struct dentry *lsm_dentry;
+static ssize_t lsm_read(struct file *filp, char __user *buf, size_t count,
+   loff_t *ppos)
+{
+   return simple_read_from_buffer(buf, count, ppos, lsm_names,
+   strlen(lsm_names));
+}
+
+static const struct file_operations lsm_ops = {
+   .read = lsm_read,
+   .llseek = generic_file_llseek,
+};
+#endif
+
 static int __init securityfs_init(void)
 {
int retval;
@@ -217,9 +233,15 @@ static int __init securityfs_init(void)
return retval;
 
retval = register_filesystem(_type);

[PATCH v5 0/3] LSM: security module information improvements

2016-06-24 Thread Casey Schaufler
Subject: [PATCH v5 0/3] LSM: security module information improvements

Changes from v4:
Use kasprintf instead of kzalloc() ... sprintf in more places.
More in the documentation.
Separate module information in contexts with ",". (not yet visible)

Changes from v3:
Use kasprintf instead of kzalloc() ... sprintf.

Create interfaces that make it possible to deal with process
attributes in the face of multiple "major" security modules.

Patch 1/3 adds /sys/kernel/security/lsm, which provides
a list of the active security modules on the system.

$ cat /sys/kernel/security/lsm
capability,yama,loadpin,smack

Patch 2/3 adds a subdirectory in /proc/.../attr for each
security module that exports process attribute data. This
allows a program in easily differentiate between the "current"
value for Smack and AppArmor.

$ cat /proc/self/attr/smack/current
System

$ cat /proc/self/attr/apparmor/current
unconfined

Patch 3/3 adds an interface that provides module identified
information that otherwise matches the "current" attr.
This allows a system with multiple modules to provide the
complete security "context" in one place. A (future) system
with both Smack and AppArmor might report:

$ cat /proc/self/attr/context
smack='System',apparmor='unconfined'

Signed-off-by: Casey Schaufler 

---
 Documentation/security/LSM.txt |  34 ++--
 fs/proc/base.c |  95 +++---
 fs/proc/internal.h |   1 +
 include/linux/lsm_hooks.h  |  12 +--
 include/linux/security.h   |  15 ++--
 security/apparmor/lsm.c|  38 +++--
 security/commoncap.c   |   3 +-
 security/inode.c   |  26 +-
 security/loadpin/loadpin.c |   2 +-
 security/security.c| 177 -
 security/selinux/hooks.c   |  22 -
 security/smack/smack_lsm.c |  22 ++---
 security/tomoyo/tomoyo.c   |   2 +-
 security/yama/yama_lsm.c   |   2 +-
 14 files changed, 395 insertions(+), 56 deletions(-)



Re: [PATCH v3 0/9] reduce memory usage by page_owner

2016-06-24 Thread Andrew Morton
On Fri, 17 Jun 2016 16:57:30 +0900 js1...@gmail.com wrote:

> There was a bug reported by Sasha and minor fixes is needed
> so I send v3.
> 
> o fix a bg reported by Sasha (mm/compaction: split freepages
> without holding the zone lock)
> o add code comment for todo list (mm/page_owner: use stackdepot
> to store stacktrace) per Michal
> o add 'inline' keyword (mm/page_alloc: introduce post allocation
> processing on page allocator) per Vlastimil
> o add a patch that clean-up code per Vlastimil

I've gone through v3 patches 2-9 and have plucked out the deltas to
take what-i-had and turn that into what-you-sent.  Patch 1/9 has seen a
lot of competing churn in isolate_freepages_block(), so please review
the current version of that, below.  Between the "===" markers:


static unsigned long isolate_freepages_block(struct compact_control *cc,
unsigned long *start_pfn,
unsigned long end_pfn,
struct list_head *freelist,
bool strict)
{
int nr_scanned = 0, total_isolated = 0;
struct page *cursor, *valid_page = NULL;
unsigned long flags = 0;
bool locked = false;
unsigned long blockpfn = *start_pfn;
unsigned int order;

cursor = pfn_to_page(blockpfn);

/* Isolate free pages. */
for (; blockpfn < end_pfn; blockpfn++, cursor++) {
int isolated;
struct page *page = cursor;

/*
 * Periodically drop the lock (if held) regardless of its
 * contention, to give chance to IRQs. Abort if fatal signal
 * pending or async compaction detects need_resched()
 */
if (!(blockpfn % SWAP_CLUSTER_MAX)
&& compact_unlock_should_abort(>zone->lock, flags,
, cc))
break;

nr_scanned++;
if (!pfn_valid_within(blockpfn))
goto isolate_fail;

if (!valid_page)
valid_page = page;

/*
 * For compound pages such as THP and hugetlbfs, we can save
 * potentially a lot of iterations if we skip them at once.
 * The check is racy, but we can consider only valid values
 * and the only danger is skipping too much.
 */
if (PageCompound(page)) {
unsigned int comp_order = compound_order(page);

if (likely(comp_order < MAX_ORDER)) {
blockpfn += (1UL << comp_order) - 1;
cursor += (1UL << comp_order) - 1;
}

goto isolate_fail;
}

if (!PageBuddy(page))
goto isolate_fail;


/*
 * If we already hold the lock, we can skip some rechecking.
 * Note that if we hold the lock now, checked_pageblock was
 * already set in some previous iteration (or strict is true),
 * so it is correct to skip the suitable migration target
 * recheck as well.
 */
if (!locked) {
/*
 * The zone lock must be held to isolate freepages.
 * Unfortunately this is a very coarse lock and can be
 * heavily contended if there are parallel allocations
 * or parallel compactions. For async compaction do not
 * spin on the lock and we acquire the lock as late as
 * possible.
 */
locked = compact_trylock_irqsave(>zone->lock,
, cc);
if (!locked)
break;

/* Recheck this is a buddy page under lock */
if (!PageBuddy(page))
goto isolate_fail;
}

/* Found a free page, will break it into order-0 pages */
order = page_order(page);
isolated = __isolate_free_page(page, order);
if (!isolated)
break;
set_page_private(page, order);

total_isolated += isolated;
cc->nr_freepages += isolated;
list_add_tail(>lru, freelist);

if (!strict && cc->nr_migratepages <= cc->nr_freepages) {
blockpfn += isolated;
break;
}
/* Advance to the end of split page */

Re: [PATCH v2 06/24] fs: ext4: Use current_time() for inode timestamps

2016-06-24 Thread Deepa Dinamani
>> @@ -3727,6 +3727,7 @@ static int ext4_cross_rename(struct inode *old_dir, 
>> struct dentry *old_dentry,
>> };
>> u8 new_file_type;
>> int retval;
>> +   struct timespec ctime;
>>
>> if ((ext4_encrypted_inode(old_dir) ||
>>  ext4_encrypted_inode(new_dir)) &&
>> @@ -3829,8 +3830,9 @@ static int ext4_cross_rename(struct inode *old_dir, 
>> struct dentry *old_dentry,
>>  * Like most other Unix systems, set the ctime for inodes on a
>>  * rename.
>>  */
>> -   old.inode->i_ctime = ext4_current_time(old.inode);
>> -   new.inode->i_ctime = ext4_current_time(new.inode);
>> +   ctime = current_time(old.inode);
>> +   old.inode->i_ctime = ctime;
>> +   new.inode->i_ctime = ctime;
>> ext4_mark_inode_dirty(handle, old.inode);
>> ext4_mark_inode_dirty(handle, new.inode);
>>
>
> Adding a local variable here looks like it is going to cause us trouble when 
> we
> change the return type of current_time() to timespec64.
>
> I'd write this as
>
> new.inode->i_ctime = old.inode->i_ctime;
>
> instead.

This should be fine.
There are already instances that use local timespecs for inode time assignments.

These can be changed this way:

+   ctime = vfs_time_to_timespec(current_time(old.inode));
+   old.inode->i_ctime = timespec_to_vfs_time(ctime);
+   new.inode->i_ctime = timespec_to_vfs_time(ctime);

This could be a little inefficient, but only temporary.
The local variable can be changed to timespec64 when the macros are deleted.

I'm trying to make minimal changes.

-Deepa


Re: [PATCH] acpi: cppc: Prevent cpc_desc_ptr points to the invalid data

2016-06-24 Thread Rafael J. Wysocki
On Friday, June 24, 2016 09:35:32 AM Hoan Tran wrote:
> On Tue, May 31, 2016 at 12:29 PM, Ashwin Chaugule
>  wrote:
> >
> > On 27 May 2016 at 12:41, Hoan Tran  wrote:
> > > Hi Ashwin,
> >
> > Hi,
> >
> > >
> > > Yes, I saw kernel crash.
> > > As cpc_desc_ptr is not NULL, cppc_cpufreq_init() still can pass then
> > > crash during cppc_get_perf_caps() access CPPC shared memory.
> > >
> > > It's not only "PCC channel request fail" can create this issue but
> > > "acpi_get_psd() fail" also creates it
> > >
> > > Thanks
> > > Hoan
> >
> >
> > Just for future reference. :)
> >
> > https://web.archive.org/web/20080722025748/http://www.zip.com.au/~akpm/linux/patches/stuff/top-posting.txt
> >
> >
> > >
> > > On Fri, May 27, 2016 at 9:10 AM, Ashwin Chaugule
> > >  wrote:
> > >> On 25 May 2016 at 15:09, Hoan Tran  wrote:
> > >>> When CPPC fails to request PCC channel, the CPC data is freed
> > >>> and cpc_desc_ptr points to the invalid data. This change prevents
> > >>> this issue by moving cpc_desc_ptr assignment after PCC channel
> > >>> request.
> > >>>
> > >>> Signed-off-by: Hoan Tran 
> > >>> ---
> > >>>  drivers/acpi/cppc_acpi.c | 6 +++---
> > >>>  1 file changed, 3 insertions(+), 3 deletions(-)
> > >>>
> > >>> diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
> > >>> index 8adac69..85fd8f7 100644
> > >>> --- a/drivers/acpi/cppc_acpi.c
> > >>> +++ b/drivers/acpi/cppc_acpi.c
> > >>> @@ -595,9 +595,6 @@ int acpi_cppc_processor_probe(struct acpi_processor 
> > >>> *pr)
> > >>> /* Store CPU Logical ID */
> > >>> cpc_ptr->cpu_id = pr->id;
> > >>>
> > >>> -   /* Plug it into this CPUs CPC descriptor. */
> > >>> -   per_cpu(cpc_desc_ptr, pr->id) = cpc_ptr;
> > >>> -
> > >>> /* Parse PSD data for this CPU */
> > >>> ret = acpi_get_psd(cpc_ptr, handle);
> > >>> if (ret)
> > >>> @@ -610,6 +607,9 @@ int acpi_cppc_processor_probe(struct acpi_processor 
> > >>> *pr)
> > >>> goto out_free;
> > >>> }
> > >>>
> > >>> +   /* Plug PSD data into this CPUs CPC descriptor. */
> > >>> +   per_cpu(cpc_desc_ptr, pr->id) = cpc_ptr;
> > >>> +
> > >>
> > >> Are you seeing a real problem without this change? I'm missing where
> > >> this pointer is dereferenced if the PCC channel request fails.
> > >>
> >
> > So, after freeing the cpc_ptr, we need to NULL the per-cpu pointer as
> > well. Alternately, not assign it until everything passes and rely on
> > the static declaration, which is the path you've taken here.
> >
> > Acked-by: Ashwin Chaugule 
> 
> Hi Rafael,
> 
> Do you have plan to apply this patch ?

I do now. :-)

I've overlooked the Ashwin's ACK, so thanks for the reminder.

Thanks,
Rafael



mmotm 2016-06-24-15-53 uploaded

2016-06-24 Thread akpm
The mm-of-the-moment snapshot 2016-06-24-15-53 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (4.x
or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.

A git tree which contains the memory management portion of this tree is
maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
by Michal Hocko.  It contains the patches which are between the
"#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
file, http://www.ozlabs.org/~akpm/mmotm/series.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/

To develop on top of mmotm git:

  $ git remote add mmotm 
git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
  $ git remote update mmotm
  $ git checkout -b topic mmotm/master
  
  $ git send-email mmotm/master.. [...]

To rebase a branch with older patches to a new mmotm release:

  $ git remote update mmotm
  $ git rebase --onto mmotm/master  topic




The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is available at

http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/

and use of this tree is similar to
http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.


This mmotm tree contains the following patches against 4.7-rc4:
(patches marked "*" will be included in linux-next)

  origin.patch
* mmoom_reaper-dont-call-mmput_async-without-atomic_inc_not_zero.patch
* oom_reaper-avoid-pointless-atomic_inc_not_zero-usage.patch
* selftests-vm-compaction_test-fix-write-to-restore-nr_hugepages.patch
* tmpfs-dont-undo-fallocate-past-its-last-page.patch
* tree-wide-get-rid-of-__gfp_repeat-for-order-0-allocations-part-i.patch
* x86-get-rid-of-superfluous-__gfp_repeat.patch
* x86-efi-get-rid-of-superfluous-__gfp_repeat.patch
* arm64-get-rid-of-superfluous-__gfp_repeat.patch
* arc-get-rid-of-superfluous-__gfp_repeat.patch
* mips-get-rid-of-superfluous-__gfp_repeat.patch
* nios2-get-rid-of-superfluous-__gfp_repeat.patch
* parisc-get-rid-of-superfluous-__gfp_repeat.patch
* score-get-rid-of-superfluous-__gfp_repeat.patch
* powerpc-get-rid-of-superfluous-__gfp_repeat.patch
* sparc-get-rid-of-superfluous-__gfp_repeat.patch
* s390-get-rid-of-superfluous-__gfp_repeat.patch
* sh-get-rid-of-superfluous-__gfp_repeat.patch
* tile-get-rid-of-superfluous-__gfp_repeat.patch
* unicore32-get-rid-of-superfluous-__gfp_repeat.patch
* jbd2-get-rid-of-superfluous-__gfp_repeat.patch
* maintainers-update-calgary-iommu.patch
* mm-mempool-kasan-dont-poot-mempool-objects-in-quarantine.patch
* mm-slaub-add-__gfp_atomic-to-the-gfp-reclaim-mask.patch
* mailmap-antoine-tenarts-email.patch
* mailmap-boris-brezillons-email.patch
* revert-mm-make-faultaround-produce-old-ptes.patch
* revert-mm-disable-fault-around-on-emulated-access-bit-architecture.patch
* hugetlb-fix-nr_pmds-accounting-with-shared-page-tables.patch
* memcg-mem_cgroup_migrate-may-be-called-with-irq-disabled.patch
* memcg-css_alloc-should-return-an-err_ptr-value-on-error.patch
* mm-swapc-flush-lru-pvecs-on-compound-page-arrival.patch
* mm-hugetlb-clear-compound_mapcount-when-freeing-gigantic-pages.patch
* mm-prevent-kasan-false-positives-in-kmemleak.patch
* mm-compaction-abort-free-scanner-if-split-fails.patch
* ocfs2-disable-bug-assertions-in-reading-blocks.patch
* oom-suspend-fix-oom_reaper-vs-oom_killer_disable-race.patch
* fs-nilfs2-fix-potential-underflow-in-call-to-crc32_le.patch
* tools-vm-slabinfo-fix-spelling-mistake-ocurrences-occurrences.patch
* mm-page_owner-use-stackdepot-to-store-stacktrace-fix.patch
* autofs-dont-stuck-in-a-loop-if-vfs_write-returns-an-error.patch
* init-mainc-fix-initcall_blacklisted-on-ia64-ppc64-and-parisc64.patch
  i-need-old-gcc.patch
  arch-alpha-kernel-systblss-remove-debug-check.patch
* arm-get-rid-of-superfluous-__gfp_repeat.patch
* arm-arch-arm-include-asm-pageh-needs-personalityh.patch
* 

Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

2016-06-24 Thread Ondřej Jirman
Hello,

comments below.

On 24.6.2016 05:48, Chen-Yu Tsai wrote:
> On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
>> From: Ondrej Jirman 
>>
>> Add label to the first cpu so that it can be referenced
>> from derived dts files.
>>
>> Signed-off-by: Ondrej Jirman 
>> ---
>>  arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>> index 9938972..82faefc 100644
>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>> @@ -52,7 +52,7 @@
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> -   cpu@0 {
>> +   cpu0: cpu@0 {
>> compatible = "arm,cortex-a7";
>> device_type = "cpu";
>> reg = <0>;
> 
> Can you also set the cpu clock here? It is part of the SoC
> and does not belong in the board DTS files.

Do you mean operating-points, or something else? Different SBCs will
probably require different combinations of operating points just for
safety's sake, because they have different regulators and [some have
botched] thermal designs, so it might make sense to customize it for
differnt boards, and I don't feel adventurous enough setting it for all
H3 boards out there.

Or is this comment related to the missing cpu clock rate message I see
on every boot?

[0.058912] /cpus/cpu@0 missing clock-frequency property

regards,
  Ondrej

> Otherwise this one looks good.
> 
> ChenYu
> 
>> --
>> 2.9.0
>>



signature.asc
Description: OpenPGP digital signature


[GIT PULL] ACPI fix for v4.7-rc5

2016-06-24 Thread Rafael J. Wysocki
Hi Linus,

Please pull from

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 acpi-4.7-rc5

to receive an ACPI update for v4.7-rc5 with top-most commit
2605b98109100f70398115a473ea190ce93fda5e

 Merge branch 'acpica-fixes'

on top of commit 33688abb2802ff3a230bd2441f765477b94cc89e

 Linux 4.7-rc4

Stable-candidate fix for a deadlock in ACPICA introduced during the
4.5 development cycle by a commit attempting to improve the handling
of AML code that doesn't belong to any namespace objects in a given
definition block (Lv Zheng).

Thanks!

---

Lv Zheng (1):
  ACPICA: Namespace: Fix deadlock triggered by MLC support in
dynamic table loading

---

 drivers/acpi/acpica/exconfig.c | 2 ++
 drivers/acpi/acpica/nsparse.c  | 9 +++--
 2 files changed, 9 insertions(+), 2 deletions(-)


[GIT PULL] Power management fixes for v4.7-rc5

2016-06-24 Thread Rafael J. Wysocki
Hi Linus,

Please pull from

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 pm-4.7-rc5

to receive power management fixes for v4.7-rc5 with top-most commit
e753f3050935ff5a52069fef802bee72ab19c098

 Merge branches 'pm-devfreq-fixes' and 'pm-cpufreq-fixes'

on top of commit 33688abb2802ff3a230bd2441f765477b94cc89e

 Linux 4.7-rc4

Fix for a latent cpufreq driver bug uncovered by a recent ACPICA
change and several fixes for the devfreq framework, including one
fix for an issue introduced recently.

Specifics:

 - Fix a latent initialization issue in the pcc-cpufreq driver
   (incorrect initial value of a structure field) that has been
   uncovered by a recent ACPICA commit (Mike Galbraith).

 - Add a missing notification in an update_devfreq() error code
   path forgotten by a recent devfreq commit (Chanwoo Choi).

 - Fix devfreq device frequency initialization (Lukasz Luba).

 - Fix an incorrect IS_ERR() check in the devfreq framework
   discovered by the Smatch checker (Dan Carpenter).

 - Drop two excessive put_device() calls from the devfreq framework
   (MyungJoo Ham, Cai Zhiyong).

 - Fix a possible memory leak in the devfreq framework and drop an
   unnecessary kfree() invocation from it (MyungJoo Ham).

Thanks!

---

Cai Zhiyong (1):
  PM / devfreq: fix double call put_device

Chanwoo Choi (1):
  PM / devfreq: Send the DEVFREQ_POSTCHANGE notification when
target() is failed

Dan Carpenter (1):
  PM / devfreq: exynos-nocp: Remove incorrect IS_ERR() check

Lukasz Luba (1):
  PM / devfreq: fix initialization of current frequency in last status

Mike Galbraith (1):
  cpufreq: pcc-cpufreq: Fix doorbell.access_width

MyungJoo Ham (3):
  PM / devfreq: devm_kzalloc to have dev pointer more precisely
  PM / devfreq: fix duplicated kfree on devfreq pointer
  PM / devfreq: remove double put_device

---

 drivers/cpufreq/pcc-cpufreq.c   |  2 +-
 drivers/devfreq/devfreq.c   | 27 ++-
 drivers/devfreq/event/exynos-nocp.c |  3 ---
 3 files changed, 15 insertions(+), 17 deletions(-)


Re: [PATCH v6 4/5] arm64: add support for ACPI Low Power Idle(LPI)

2016-06-24 Thread Rafael J. Wysocki
On Friday, June 24, 2016 11:04:07 PM Daniel Lezcano wrote:
> On 06/22/2016 04:17 PM, Lorenzo Pieralisi wrote:
> > Hi Sudeep,
> >
> > On Tue, Jun 14, 2016 at 03:48:38PM +0100, Sudeep Holla wrote:
> >> This patch adds appropriate callbacks to support ACPI Low Power Idle
> >> (LPI) on ARM64.
> >>
> >> Now that arm_enter_idle_state is exactly same in both generic ARM{32,64}
> >> CPUIdle driver and ARM64 backend for ACPI processor idle driver, we can
> >> unify it and move to cpuidle-arm.h header.
> >>
> >> Cc: Lorenzo Pieralisi 
> >> Cc: Mark Rutland 
> >> Cc: Daniel Lezcano 
> >> Cc: "Rafael J. Wysocki" 
> >> Cc: linux-arm-ker...@lists.infradead.org
> >> Signed-off-by: Sudeep Holla 
> >> ---
> >>   arch/arm64/kernel/cpuidle.c   | 17 +
> >>   drivers/cpuidle/cpuidle-arm.c | 23 ++
> >>   drivers/firmware/psci.c   | 56 
> >> +++
> >>   include/linux/cpuidle-arm.h   | 30 +++
> >>   4 files changed, 105 insertions(+), 21 deletions(-)
> >>   create mode 100644 include/linux/cpuidle-arm.h
> >
> > This patch seems fine by me, it would be good if Daniel can have
> > a look too.
> >
> > Some minor comments below.
> >
> > [...]
> >
> >> diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
> >> index 03e04582791c..c6caa863d156 100644
> >> --- a/drivers/firmware/psci.c
> >> +++ b/drivers/firmware/psci.c
> >> @@ -13,6 +13,7 @@
> >>
> >>   #define pr_fmt(fmt) "psci: " fmt
> >>
> >> +#include 
> >>   #include 
> >>   #include 
> >>   #include 
> >> @@ -310,11 +311,66 @@ static int psci_dt_cpu_init_idle(struct device_node 
> >> *cpu_node, int cpu)
> >>return ret;
> >>   }
> >>
> >> +#ifdef CONFIG_ACPI
> >> +#include 
> >> +
> >> +static int __maybe_unused psci_acpi_cpu_init_idle(unsigned int cpu)
> >> +{
> >> +  int i, count;
> >> +  u32 *psci_states;
> >> +  struct acpi_processor *pr;
> >> +  struct acpi_lpi_state *lpi;
> >> +
> >> +  pr = per_cpu(processors, cpu);
> >> +  if (unlikely(!pr || !pr->flags.has_lpi))
> >> +  return -EINVAL;
> >> +
> >> +  /*
> >> +   * If the PSCI cpu_suspend function hook has not been initialized
> >> +   * idle states must not be enabled, so bail out
> >> +   */
> >> +  if (!psci_ops.cpu_suspend)
> >> +  return -EOPNOTSUPP;
> >> +
> >> +  count = pr->power.count - 1;
> >> +  if (count <= 0)
> >> +  return -ENODEV;
> >> +
> >> +  psci_states = kcalloc(count, sizeof(*psci_states), GFP_KERNEL);
> >> +  if (!psci_states)
> >> +  return -ENOMEM;
> >> +
> >> +  for (i = 0; i < count; i++) {
> >> +  u32 state;
> >> +
> >> +  lpi = >power.lpi_states[i + 1];
> >> +  state = lpi->address & 0x;
> 
> Why is needed to mask 'address' ?
> 
> >> +  if (!psci_power_state_is_valid(state)) {
> >> +  pr_warn("Invalid PSCI power state %#x\n", state);
> >> +  kfree(psci_states);
> >> +  return -EINVAL;
> >> +  }
> >> +  psci_states[i] = state;
> >> +  }
> >> +  /* Idle states parsed correctly, initialize per-cpu pointer */
> >> +  per_cpu(psci_power_state, cpu) = psci_states;
> >> +  return 0;
> >
> > Most of the code in this function is FW independent, it would be nice
> > to factor it out and add the respective ACPI/DT helper functions to
> > retrieve idle states count and parameters, we can update it later
> > anyway it is fine by me to leave it as it is.
> >
> >> +}
> >> +#else
> >> +static int __maybe_unused psci_acpi_cpu_init_idle(unsigned int cpu)
> >> +{
> >> +  return -EINVAL;
> >> +}
> >> +#endif
> >> +
> >>   int psci_cpu_init_idle(unsigned int cpu)
> >>   {
> >>struct device_node *cpu_node;
> >>int ret;
> >>
> >> +  if (!acpi_disabled)
> >> +  return psci_acpi_cpu_init_idle(cpu);
> 
> Is it possible the case where there is information in both the DT and in 
> ACPI ?

No, it isn't.

It is either-or, never both at the same time.

Thanks,
Rafael



[PATCH v4 2/2] kbuild: Remove stale asm-generic wrappers

2016-06-24 Thread James Hogan
When a header file is removed from generic-y (often accompanied by the
addition of an arch specific header), the generated wrapper file will
persist, and in some cases may still take precedence over the new arch
header.

For example commit f1fe2d21f4e1 ("MIPS: Add definitions for extended
context") removed ucontext.h from generic-y in arch/mips/include/asm/,
and added an arch/mips/include/uapi/asm/ucontext.h. The continued use of
the wrapper when reusing a dirty build tree resulted in build failures
in arch/mips/kernel/signal.c:

arch/mips/kernel/signal.c: In function ‘sc_to_extcontext’:
arch/mips/kernel/signal.c:142:12: error: ‘struct ucontext’ has no member named 
‘uc_extcontext’
  return >uc_extcontext;
^

Fix by detecting and removing wrapper headers in generated header
directories that do not correspond to a filename in generic-y, genhdr-y,
or the newly introduced generated-y.

Reported-by: Jacek Anaszewski 
Reported-by: Hauke Mehrtens 
Reported-by: Heinrich Schuchardt 
Signed-off-by: James Hogan 
Acked-by: Arnd Bergmann 
Acked-by: Florian Fainelli 
Cc: Michal Marek 
Cc: Arnd Bergmann 
Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: Florian Fainelli 
Cc: linux-kbu...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Cc: linux-m...@linux-mips.org
---
Changes in v4:
- None (resend).

Changes in v3:
- Ensure FORCE actually gets marked .PHONY.

Changes in v2:
- Rewrite a bit, drawing inspiration from Makefile.headersinst.
- Exclude genhdr-y and generated-y (thanks to kbuild test robot).
---
 scripts/Makefile.asm-generic | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/scripts/Makefile.asm-generic b/scripts/Makefile.asm-generic
index 045e0098e962..e4d017d53819 100644
--- a/scripts/Makefile.asm-generic
+++ b/scripts/Makefile.asm-generic
@@ -13,11 +13,26 @@ include scripts/Kbuild.include
 # Create output directory if not already present
 _dummy := $(shell [ -d $(obj) ] || mkdir -p $(obj))
 
+# Stale wrappers when the corresponding files are removed from generic-y
+# need removing.
+generated-y   := $(generic-y) $(genhdr-y) $(generated-y)
+all-files := $(patsubst %, $(obj)/%, $(generated-y))
+old-headers   := $(wildcard $(obj)/*.h)
+unwanted  := $(filter-out $(all-files),$(old-headers))
+
 quiet_cmd_wrap = WRAP$@
 cmd_wrap = echo "\#include " >$@
 
-all: $(patsubst %, $(obj)/%, $(generic-y))
+quiet_cmd_remove = REMOVE  $(unwanted)
+cmd_remove = rm -f $(unwanted)
+
+all: $(patsubst %, $(obj)/%, $(generic-y)) FORCE
+   $(if $(unwanted),$(call cmd,remove),)
@:
 
 $(obj)/%.h:
$(call cmd,wrap)
+
+PHONY += FORCE
+.PHONY: $(PHONY)
+FORCE: ;
-- 
2.4.10



[PATCH v4 1/2] kbuild, x86: Track generated headers with generated-y

2016-06-24 Thread James Hogan
Track generated header files which aren't already in genhdr-y, alongside
generic-y wrappers in the */include/generated/[uapi/]asm/ directories.
Currently only x86 generates extra headers in these directories, for the
purposes of enumerating system calls for different ABIs, and xen
hypercalls.

This will allow the asm-generic wrapper handling code to remove stale
wrappers when files are removed from generic-y, without also removing
these headers which are generated separately.

Reported-by: kbuild test robot 
Signed-off-by: James Hogan 
Acked-by: Arnd Bergmann 
Cc: Michal Marek 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Jonathan Corbet 
Cc: linux-kbu...@vger.kernel.org
Cc: x...@kernel.org
Cc: linux-...@vger.kernel.org
---
Changes in v4:
- None (resend).

Changes in v2:
- New patch (thanks to kbuild test robot).
---
 Documentation/kbuild/makefiles.txt | 14 ++
 arch/x86/include/asm/Kbuild|  6 ++
 2 files changed, 20 insertions(+)

diff --git a/Documentation/kbuild/makefiles.txt 
b/Documentation/kbuild/makefiles.txt
index 13f888a02a3d..385a5ef41c17 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -47,6 +47,7 @@ This document describes the Linux kernel Makefiles.
--- 7.2 genhdr-y
--- 7.3 destination-y
--- 7.4 generic-y
+   --- 7.5 generated-y
 
=== 8 Kbuild Variables
=== 9 Makefile language
@@ -1319,6 +1320,19 @@ See subsequent chapter for the syntax of the Kbuild file.
Example: termios.h
#include 
 
+   --- 7.5 generated-y
+
+   If an architecture generates other header files alongside generic-y
+   wrappers, and not included in genhdr-y, then generated-y specifies
+   them.
+
+   This prevents them being treated as stale asm-generic wrappers and
+   removed.
+
+   Example:
+   #arch/x86/include/asm/Kbuild
+   generated-y += syscalls_32.h
+
 === 8 Kbuild Variables
 
 The top Makefile exports the following variables:
diff --git a/arch/x86/include/asm/Kbuild b/arch/x86/include/asm/Kbuild
index aeac434c9feb..2cfed174e3c9 100644
--- a/arch/x86/include/asm/Kbuild
+++ b/arch/x86/include/asm/Kbuild
@@ -1,5 +1,11 @@
 
 
+generated-y += syscalls_32.h
+generated-y += syscalls_64.h
+generated-y += unistd_32_ia32.h
+generated-y += unistd_64_x32.h
+generated-y += xen-hypercalls.h
+
 genhdr-y += unistd_32.h
 genhdr-y += unistd_64.h
 genhdr-y += unistd_x32.h
-- 
2.4.10



[PATCH v4 0/2] kbuild: Remove stale asm-generic wrappers

2016-06-24 Thread James Hogan
This patchset attempts to fix kbuild to automatically remove stale
asm-generic wrappers, i.e. when files are removed from generic-y and
added directly into arch/*/include/uapi/asm/, but where the existing
wrapper in arch/*/include/generated/asm/ continues to be used.

MIPS was recently burned by this in v4.3 (see patch 2), with continuing
reports of build failures when people upgrade their trees, which go away
after arch/mips/include/generated is removed (or reportedly make
mrproper/distclean). It is particularly irritating during bisection.

Since v2 I've seen other cases of this breaking MIPS build, and testing
on x86_64, starting a build first on v4.0 and then on mainline with this
patchset shows one stale generated header:
  REMOVE  arch/x86/include/generated/asm/scatterlist.h

Changes in v4:
- None (resend on Thomas Gleixner's request).

Changes in v3:
- Ensure FORCE actually gets marked .PHONY.

Changes in v2:
- New patch 1 to add tracking of generated headers that aren't generic-y
  wrappers, via generated-y, particularly for x86 (thanks to kbuild test
  robot).
- Rewrite a bit, drawing inspiration from Makefile.headersinst.
- Exclude genhdr-y and generated-y (thanks to kbuild test robot).

James Hogan (2):
  kbuild, x86: Track generated headers with generated-y
  kbuild: Remove stale asm-generic wrappers

 Documentation/kbuild/makefiles.txt | 14 ++
 arch/x86/include/asm/Kbuild|  6 ++
 scripts/Makefile.asm-generic   | 17 -
 3 files changed, 36 insertions(+), 1 deletion(-)

Cc: Michal Marek 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Jonathan Corbet 
Cc: Arnd Bergmann 
Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: Florian Fainelli 
Cc: Heinrich Schuchardt 
Cc: linux-kbu...@vger.kernel.org
Cc: x...@kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Cc: linux-m...@linux-mips.org
-- 
2.4.10



Re: [linux-sunxi] [PATCH 13/14] ARM: dts: sun8i: Add gpio-regulator used on Orange Pi One

2016-06-24 Thread Ondřej Jirman
Hi Julian,

thank you for the review. You're right. I added the pinctrl client
nodes. Also the patches were split incorrectly, so I fixed that too.

regards,
  Ondrej

On 24.6.2016 04:51, Julian Calaby wrote:
> Hi Ondrej,
> 
> On Fri, Jun 24, 2016 at 5:21 AM,   wrote:
>> From: Ondrej Jirman 
>>
>> Xulong Orange Pi One uses GPIO based regulator that
>> switches between two voltages: 1.1V and 1.3V. The
>> regulator is controlled from the PL6 pin.
>>
>> Signed-off-by: Ondrej Jirman 
>> ---
>>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 26 ++
>>  1 file changed, 26 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
>> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> index 0adf932..ce4ba91 100644
>> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> @@ -88,6 +88,25 @@
>> gpios = <_pio 0 3 GPIO_ACTIVE_LOW>;
>> };
>> };
>> +
>> +   vdd_soc: gpio-regulator {
>> +   compatible = "regulator-gpio";
>> +
>> +   regulator-name = "soc-vdd-supply";
>> +   regulator-min-microvolt = <110>;
>> +   regulator-max-microvolt = <130>;
>> +   regulator-boot-on;
>> +   regulator-type = "voltage";
>> +
>> +   gpios = <_pio 0 6 GPIO_ACTIVE_HIGH>;
>> +   states = <110 0x0
>> + 130 0x1>;
>> +
>> +   startup-delay-us = <10>;
>> +   enable-active-high;
> 
> Don't you need to reference the new pinctl node in this one?
> 
> Thanks,
> 



signature.asc
Description: OpenPGP digital signature


Re: Kernel 4.7rc3 - Performance drop 30-40% for SPECjbb2005 and SPECjvm2008 benchmarks against 4.6 kernel

2016-06-24 Thread Jirka Hladky
Hi Peter,

I have compiled your version of linux kernel and run the SPECjvm2008
tests. Results are fine, performance is at the level of 4.6 kernel.

$ git rev-parse HEAD
02548776ded1185e6e16ad0a475481e982741ee9

Jirka




On Fri, Jun 24, 2016 at 5:54 PM, Peter Zijlstra  wrote:
> On Fri, Jun 24, 2016 at 03:42:26PM +0200, Peter Zijlstra wrote:
>> On Fri, Jun 24, 2016 at 02:44:07PM +0200, Vincent Guittot wrote:
>> > > --- a/kernel/sched/fair.c
>> > > +++ b/kernel/sched/fair.c
>> > > @@ -2484,7 +2484,7 @@ static inline long calc_tg_weight(struct 
>> > > task_group *tg, struct cfs_rq *cfs_rq)
>> > >  */
>> > > tg_weight = atomic_long_read(>load_avg);
>> > > tg_weight -= cfs_rq->tg_load_avg_contrib;
>> > > -   tg_weight += cfs_rq->load.weight;
>> > > +   tg_weight += cfs_rq->avg.load_avg;
>> >
>> > IIUC, you are reverting
>> > commit  fde7d22e01aa (sched/fair: Fix overly small weight for
>> > interactive group entities)
>>
>> Hurm.. looking at that commit again, that seems to wreck
>> effective_load(), since that doesn't compensate.
>>
>> Maybe I'll remove calc_tg_weight and open code its slightly different
>> usages in the two sites.
>
> OK, sorry for not actually posting, but I need to run. Please find the
> two patches in:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git sched/urgent


Re: [PATCH v3 0/6] watchdog: add watchdog pretimeout framework

2016-06-24 Thread Vladimir Zapolskiy
Hi Wolfram, Guenter,

On 24.06.2016 16:45, Guenter Roeck wrote:
> On 06/24/2016 02:46 AM, Wolfram Sang wrote:
>> On Tue, Jun 07, 2016 at 08:38:41PM +0300, Vladimir Zapolskiy wrote:
>>> The change adds a simple watchdog pretimeout framework infrastructure,
>>> its purpose is to allow users to select a desired handling of watchdog
>>> pretimeout events, which may be generated by a watchdog driver.
>>
>> Any news? We'd really like to have it in 4.8, at least the non-sleeping
>> stuff.
>>

I continued to cut the change into smaller pieces, but then in a series
a lot of code copy-paste cases between files appear, so eventually I think
that the essential part should be submitted undivided.

> Kind of cutting it close. v4 would have to be quite clean for this to happen,
> and arrive very soon. I don't think it would be a good idea to rush this in.
> 

Unfortunately the task didn't get enough priority on my end due to
something else, anyway it is not abandoned.

Guenter, some relatively small preliminary parts from Wolfram based
on Robin's work can be included into v4.8 IMHO.

--
With best wishes,
Vladimir


[GIT PULL] bugfixes for 4.7

2016-06-24 Thread J. Bruce Fields
Please pull the following nfsd changes from the nfsd-4.7-2 tag at:

  git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.7-2

--b.


Fix missing server-side permission checks on setting NFS ACLs.


Andreas Gruenbacher (1):
  posix_acl: Add set_posix_acl

Ben Hutchings (1):
  nfsd: check permissions when setting ACLs

 fs/nfsd/nfs2acl.c | 20 ++--
 fs/nfsd/nfs3acl.c | 16 +++-
 fs/nfsd/nfs4acl.c | 16 
 fs/posix_acl.c| 42 +++---
 4 files changed, 48 insertions(+), 46 deletions(-)


Re: [PATCH v2 2/5] input: pmic8xxx-pwrkey: Add support for pm8018 pwrkey

2016-06-24 Thread Dmitry Torokhov
On Fri, Jun 24, 2016 at 11:18:04AM +0200, Neil Armstrong wrote:
> In order to support pwrkey for Qualcomm MDM9615 SoC, add support
> for the pm8018 pwrkey in pmic8xxx-pwrkey.
> 
> Reviewed-by: Bjorn Andersson 
> Signed-off-by: Neil Armstrong 

NAK.

> ---
>  Documentation/devicetree/bindings/input/qcom,pm8xxx-pwrkey.txt | 1 +
>  drivers/input/misc/pmic8xxx-pwrkey.c   | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-pwrkey.txt 
> b/Documentation/devicetree/bindings/input/qcom,pm8xxx-pwrkey.txt
> index 588536c..9e530e2 100644
> --- a/Documentation/devicetree/bindings/input/qcom,pm8xxx-pwrkey.txt
> +++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-pwrkey.txt
> @@ -8,6 +8,7 @@ PROPERTIES
>   Definition: must be one of:
>   "qcom,pm8058-pwrkey"
>   "qcom,pm8921-pwrkey"
> + "qcom,pm8018-pwrkey"
>  
>  - reg:
>   Usage: required
> diff --git a/drivers/input/misc/pmic8xxx-pwrkey.c 
> b/drivers/input/misc/pmic8xxx-pwrkey.c
> index 67aab86..f6f9b87 100644
> --- a/drivers/input/misc/pmic8xxx-pwrkey.c
> +++ b/drivers/input/misc/pmic8xxx-pwrkey.c
> @@ -446,6 +446,7 @@ static int pmic8xxx_pwrkey_remove(struct platform_device 
> *pdev)
>  }
>  
>  static const struct of_device_id pm8xxx_pwr_key_id_table[] = {
> + { .compatible = "qcom,pm8018-pwrkey", .data = _pwrkey_shutdown },
>   { .compatible = "qcom,pm8058-pwrkey", .data = _pwrkey_shutdown },
>   { .compatible = "qcom,pm8921-pwrkey", .data = _pwrkey_shutdown },
>   { }
> -- 
> 1.9.1
> 

-- 
Dmitry


Re: [PATCH 2/4] input: touchscreen: crtouch_ts: Add driver

2016-06-24 Thread Dmitry Torokhov
Hi Anthony,

On Fri, Jun 24, 2016 at 03:44:44PM -0400, Anthony Felice wrote:
> Add driver for the Vybrid Tower CRTouch-based touchscreen. This is
> required for the touchscreen on the TWR-LCD-RGB to work on the Vybrid
> Tower platform.
> 
> There is a known issue with this driver: rarely, SW1 on the TWR-LCD-RGB
> module needs to be pressed in order for the touchscreen to begin
> functioning.

Hmm. Could it be that you want level interrupt and not edge? Or maybe
you want to read state after requesting interrupt?

> 
> Signed-off-by: Anthony Felice 
> ---
>  .../bindings/input/touchscreen/crtouch_ts.txt  |  14 ++
>  drivers/input/touchscreen/Kconfig  |  10 +
>  drivers/input/touchscreen/Makefile |   1 +
>  drivers/input/touchscreen/crtouch_ts.c | 279 
> +
>  4 files changed, 304 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/input/touchscreen/crtouch_ts.txt
>  create mode 100644 drivers/input/touchscreen/crtouch_ts.c
> 
> diff --git 
> a/Documentation/devicetree/bindings/input/touchscreen/crtouch_ts.txt 
> b/Documentation/devicetree/bindings/input/touchscreen/crtouch_ts.txt
> new file mode 100644
> index 000..cfb966c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/touchscreen/crtouch_ts.txt
> @@ -0,0 +1,14 @@
> +* Freescale CRTOUCH based touchscreen
> +
> +Required Properties:
> +- compatible must be fsl,crtouch_ts
> +- reg: I2C address of the touchscreen
> +- irq-gpio: GPIO to use as event IRQ
> +
> +Example:
> +
> + touch: crtouch@49 {
> + compatible = "fsl,crtouch_ts";
> + reg = <0x49>;
> + irq-gpio = < 21 GPIO_ACTIVE_HIGH>;

You are not using it as gpio but only as interrupt source, so please
set it up as regular interrupt and let I2C core set it up for you so
that you will only need to call request_irq(client->irq, ...)

interrupts = < 21 IRQ_TYPE_EDGE_FALLING>;

> + };
> diff --git a/drivers/input/touchscreen/Kconfig 
> b/drivers/input/touchscreen/Kconfig
> index 8ecdc38..799e342 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -1155,4 +1155,14 @@ config TOUCHSCREEN_ROHM_BU21023
> To compile this driver as a module, choose M here: the
> module will be called bu21023_ts.
>  
> +config TOUCHSCREEN_CRTOUCH
> + tristate "Freescale CRTOUCH based touchscreen"
> + depends on I2C
> + help
> +   Say Y here if you have a CRTOUCH based touchscreen
> +   controller.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called crtouch_ts.
> +
>  endif
> diff --git a/drivers/input/touchscreen/Makefile 
> b/drivers/input/touchscreen/Makefile
> index f42975e..8cb0a7a 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -95,3 +95,4 @@ obj-$(CONFIG_TOUCHSCREEN_TPS6507X)  += tps6507x-ts.o
>  obj-$(CONFIG_TOUCHSCREEN_ZFORCE) += zforce_ts.o
>  obj-$(CONFIG_TOUCHSCREEN_COLIBRI_VF50)   += colibri-vf50-ts.o
>  obj-$(CONFIG_TOUCHSCREEN_ROHM_BU21023)   += rohm_bu21023.o
> +obj-$(CONFIG_TOUCHSCREEN_CRTOUCH)+= crtouch_ts.o
> diff --git a/drivers/input/touchscreen/crtouch_ts.c 
> b/drivers/input/touchscreen/crtouch_ts.c
> new file mode 100644
> index 000..bb87a8e
> --- /dev/null
> +++ b/drivers/input/touchscreen/crtouch_ts.c
> @@ -0,0 +1,279 @@
> +/*
> + * Driver for Freescale Semiconductor CRTOUCH - A Resistive and Capacitive
> + * touch device with i2c interface
> + *
> + * Copyright 2012 Freescale Semiconductor, Inc.
> + *
> + * 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Resistive touch sense status registers */
> +#define RES_STA_ERROR0x00
> +#define RES_STA_STATUS1  0x01
> +#define  RES_STA_STATUS2 0x02
> +#define RES_STA_X_MSB0x03
> +#define RES_STA_X_LSB0x04
> +#define RES_STA_Y_MSB0x05
> +#define RES_STA_Y_LSB0x06
> +#define RES_STA_PRES_MSB 0x07
> +#define RES_STA_RRES_LSB 0x08
> +#define RES_STA_FIFO_STATUS  0x09
> +#define RES_STA_FIFO_X_MSB   0x0a
> +#define RES_STA_FIFO_X_LSB   0x0b
> +#define RES_STA_FIFO_Y_MSB   0x0c
> +#define RES_STA_FIFO_Y_LSB   0x0d
> +#define RES_STA_FIFO_PRES_MSB0x0e
> +#define RES_STA_FIFO_PRES_LSB0x0f
> +#define RES_STA_UART_BRATE_MSB   0x10
> +#define RES_STA_UART_BRATE_MID   

Re: [PATCH] mfd: intel-lpss: fix compilation issue if PM_SLEEP is not set

2016-06-24 Thread Vladimir Zapolskiy
On 24.06.2016 11:28, Andy Shevchenko wrote:
> On Fri, 2016-06-24 at 03:11 +0300, Vladimir Zapolskiy wrote:
>> If kernel build configuration has enabled CONFIG_PM and unset
>> CONFIG_PM_SLEEP, then intel-lpss-pci.c and intel-lpss-acpi.c can not
>> be compiled due to a missing INTEL_LPSS_SLEEP_PM_OPS macro
>> declaration:
>>
>>   drivers/mfd/intel-lpss-pci.c:63:8: error: undefined identifier
>> 'INTEL_LPSS_SLEEP_PM_OPS'
>>   drivers/mfd/intel-lpss-pci.c:63:58: error: ‘INTEL_LPSS_SLEEP_PM_OPS’
>> undeclared here (not in a function)
> 
> And may I ask what ancient kernel you are using?
> 
> commit 47b91923ea41288751e83a5b080576085a831333
> Author: Andy Shevchenko 
> Date:   Mon Sep 14 11:32:47 2015 +0300
> 
> mfd: intel-lpss: Fix build error when !CONFIG_PM_SLEEP

The original driver was backported to 4.1

Thanks for the reference to a fixup, I'll backport it as well.

Lee, please ignore this change.

--
With best wishes,
Vladimir


Ignore these, sorry!

2016-06-24 Thread Lyude
Sorry about that; I accidentally did a git send-email with some older
patches leftover in my patch folder. Just ignore this thread

On Fri, 2016-06-24 at 17:45 -0400, Lyude wrote:
> Latest version of:
> 
> https://lists.freedesktop.org/archives/intel-gfx/2016-June/098787.htm
> l
> 
> The only patch that's changed here is 4/4, the rest are just being
> sent so that
> they can be in one thread to make things easier for reviewers
> 
> Lyude (4):
>   drm/i915/vlv: Make intel_crt_reset() per-encoder
>   drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init()
>   drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug()
>   drm/i915: Enable polling when we don't have hpd
> 
>  drivers/gpu/drm/i915/i915_drv.c |   3 +
>  drivers/gpu/drm/i915/i915_drv.h |   5 ++
>  drivers/gpu/drm/i915/intel_crt.c|  28 ++--
>  drivers/gpu/drm/i915/intel_drv.h|   4 +-
>  drivers/gpu/drm/i915/intel_hotplug.c| 117
> 
>  drivers/gpu/drm/i915/intel_runtime_pm.c |   9 +++
>  6 files changed, 148 insertions(+), 18 deletions(-)
> 
-- 

Cheers,
Lyude


[PATCH 1/2 RESEND] drm/radeon: Poll for both connect/disconnect on analog connectors

2016-06-24 Thread Lyude
DRM_CONNECTOR_POLL_CONNECT only enables polling for connections, not
disconnections. Because of this, we end up losing hotplug polling for
analog connectors once they get connected.

Easy way to reproduce:
 - Grab a machine with a radeon GPU and a VGA port
 - Plug a monitor into the VGA port, wait for it to update the connector
   from disconnected to connected
 - Disconnect the monitor on VGA, a hotplug event is never sent for the
   removal of the connector.

Originally, only using DRM_CONNECTOR_POLL_CONNECT might have been a good
idea since doing VGA polling can sometimes result in having to mess with
the DAC voltages to figure out whether or not there's actually something
there since VGA doesn't have HPD. Doing this would have the potential of
showing visible artifacts on the screen every time we ran a poll while a
VGA display was connected. Luckily, radeon_vga_detect() only resorts to
this sort of polling if the poll is forced, and DRM's polling helper
doesn't force it's polls.

Additionally, this removes some assignments to connector->polled that
weren't actually doing anything.

Cc: sta...@vger.kernel.org
Signed-off-by: Lyude 
---
 drivers/gpu/drm/radeon/radeon_connectors.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 81a63d7..b79f3b0 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -2064,7 +2064,6 @@ radeon_add_atom_connector(struct drm_device *dev,
   
RADEON_OUTPUT_CSC_BYPASS);
/* no HPD on analog connectors */
radeon_connector->hpd.hpd = RADEON_HPD_NONE;
-   connector->polled = DRM_CONNECTOR_POLL_CONNECT;
connector->interlace_allowed = true;
connector->doublescan_allowed = true;
break;
@@ -2314,8 +2313,10 @@ radeon_add_atom_connector(struct drm_device *dev,
}
 
if (radeon_connector->hpd.hpd == RADEON_HPD_NONE) {
-   if (i2c_bus->valid)
-   connector->polled = DRM_CONNECTOR_POLL_CONNECT;
+   if (i2c_bus->valid) {
+   connector->polled = DRM_CONNECTOR_POLL_CONNECT |
+   DRM_CONNECTOR_POLL_DISCONNECT;
+   }
} else
connector->polled = DRM_CONNECTOR_POLL_HPD;
 
@@ -2391,7 +2392,6 @@ radeon_add_legacy_connector(struct drm_device *dev,
  1);
/* no HPD on analog connectors */
radeon_connector->hpd.hpd = RADEON_HPD_NONE;
-   connector->polled = DRM_CONNECTOR_POLL_CONNECT;
connector->interlace_allowed = true;
connector->doublescan_allowed = true;
break;
@@ -2476,10 +2476,13 @@ radeon_add_legacy_connector(struct drm_device *dev,
}
 
if (radeon_connector->hpd.hpd == RADEON_HPD_NONE) {
-   if (i2c_bus->valid)
-   connector->polled = DRM_CONNECTOR_POLL_CONNECT;
+   if (i2c_bus->valid) {
+   connector->polled = DRM_CONNECTOR_POLL_CONNECT |
+   DRM_CONNECTOR_POLL_DISCONNECT;
+   }
} else
connector->polled = DRM_CONNECTOR_POLL_HPD;
+
connector->display_info.subpixel_order = subpixel_order;
drm_connector_register(connector);
 }
-- 
2.7.4



[PATCH 2/2 RESEND] drm/amdgpu: Poll for both connect/disconnect on analog connectors

2016-06-24 Thread Lyude
DRM_CONNECTOR_POLL_CONNECT only enables polling for connections, not
disconnections. Because of this, we end up losing hotplug polling for
analog connectors once they get connected.

Easy way to reproduce:
 - Grab a machine with an AMD GPU and a VGA port
 - Plug a monitor into the VGA port, wait for it to update the connector
   from disconnected to connected
 - Disconnect the monitor on VGA, a hotplug event is never sent for the
   removal of the connector.

Originally, only using DRM_CONNECTOR_POLL_CONNECT might have been a good
idea since doing VGA polling can sometimes result in having to mess with
the DAC voltages to figure out whether or not there's actually something
there since VGA doesn't have HPD. Doing this would have the potential of
showing visible artifacts on the screen every time we ran a poll while a
VGA display was connected. Luckily, amdgpu_vga_detect() only resorts to
this sort of polling if the poll is forced, and DRM's polling helper
doesn't force it's polls.

Additionally, this removes some assignments to connector->polled that
weren't actually doing anything.

Cc: sta...@vger.kernel.org
Signed-off-by: Lyude 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index cb07da4..ff0b55a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -1690,7 +1690,6 @@ amdgpu_connector_add(struct amdgpu_device *adev,
   DRM_MODE_SCALE_NONE);
/* no HPD on analog connectors */
amdgpu_connector->hpd.hpd = AMDGPU_HPD_NONE;
-   connector->polled = DRM_CONNECTOR_POLL_CONNECT;
connector->interlace_allowed = true;
connector->doublescan_allowed = true;
break;
@@ -1893,8 +1892,10 @@ amdgpu_connector_add(struct amdgpu_device *adev,
}
 
if (amdgpu_connector->hpd.hpd == AMDGPU_HPD_NONE) {
-   if (i2c_bus->valid)
-   connector->polled = DRM_CONNECTOR_POLL_CONNECT;
+   if (i2c_bus->valid) {
+   connector->polled = DRM_CONNECTOR_POLL_CONNECT |
+   DRM_CONNECTOR_POLL_DISCONNECT;
+   }
} else
connector->polled = DRM_CONNECTOR_POLL_HPD;
 
-- 
2.7.4



Re: [PATCH 1/2] drm/radeon: Poll for both connect/disconnect on analog connectors

2016-06-24 Thread Lyude
Whoops, very sorry about this! I ran git send-email, and it looks like
I had forgotten to remove some other patches in my patches/ folder.
Going to resend this to avoid confusing anyone trying to review this.

On Fri, 2016-06-24 at 17:45 -0400, Lyude wrote:
> DRM_CONNECTOR_POLL_CONNECT only enables polling for connections, not
> disconnections. Because of this, we end up losing hotplug polling for
> analog connectors once they get connected.
> 
> Easy way to reproduce:
>  - Grab a machine with a radeon GPU and a VGA port
>  - Plug a monitor into the VGA port, wait for it to update the
> connector
>    from disconnected to connected
>  - Disconnect the monitor on VGA, a hotplug event is never sent for
> the
>    removal of the connector.
> 
> Originally, only using DRM_CONNECTOR_POLL_CONNECT might have been a
> good
> idea since doing VGA polling can sometimes result in having to mess
> with
> the DAC voltages to figure out whether or not there's actually
> something
> there since VGA doesn't have HPD. Doing this would have the potential
> of
> showing visible artifacts on the screen every time we ran a poll
> while a
> VGA display was connected. Luckily, radeon_vga_detect() only resorts
> to
> this sort of polling if the poll is forced, and DRM's polling helper
> doesn't force it's polls.
> 
> Additionally, this removes some assignments to connector->polled that
> weren't actually doing anything.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Lyude 
> ---
>  drivers/gpu/drm/radeon/radeon_connectors.c | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
> b/drivers/gpu/drm/radeon/radeon_connectors.c
> index 81a63d7..b79f3b0 100644
> --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> @@ -2064,7 +2064,6 @@ radeon_add_atom_connector(struct drm_device
> *dev,
>      RADEON_OU
> TPUT_CSC_BYPASS);
>   /* no HPD on analog connectors */
>   radeon_connector->hpd.hpd = RADEON_HPD_NONE;
> - connector->polled =
> DRM_CONNECTOR_POLL_CONNECT;
>   connector->interlace_allowed = true;
>   connector->doublescan_allowed = true;
>   break;
> @@ -2314,8 +2313,10 @@ radeon_add_atom_connector(struct drm_device
> *dev,
>   }
>  
>   if (radeon_connector->hpd.hpd == RADEON_HPD_NONE) {
> - if (i2c_bus->valid)
> - connector->polled =
> DRM_CONNECTOR_POLL_CONNECT;
> + if (i2c_bus->valid) {
> + connector->polled =
> DRM_CONNECTOR_POLL_CONNECT |
> + DRM_CONNECTOR_POLL_DISCO
> NNECT;
> + }
>   } else
>   connector->polled = DRM_CONNECTOR_POLL_HPD;
>  
> @@ -2391,7 +2392,6 @@ radeon_add_legacy_connector(struct drm_device
> *dev,
>     1);
>   /* no HPD on analog connectors */
>   radeon_connector->hpd.hpd = RADEON_HPD_NONE;
> - connector->polled = DRM_CONNECTOR_POLL_CONNECT;
>   connector->interlace_allowed = true;
>   connector->doublescan_allowed = true;
>   break;
> @@ -2476,10 +2476,13 @@ radeon_add_legacy_connector(struct drm_device
> *dev,
>   }
>  
>   if (radeon_connector->hpd.hpd == RADEON_HPD_NONE) {
> - if (i2c_bus->valid)
> - connector->polled =
> DRM_CONNECTOR_POLL_CONNECT;
> + if (i2c_bus->valid) {
> + connector->polled =
> DRM_CONNECTOR_POLL_CONNECT |
> + DRM_CONNECTOR_POLL_DISCO
> NNECT;
> + }
>   } else
>   connector->polled = DRM_CONNECTOR_POLL_HPD;
> +
>   connector->display_info.subpixel_order = subpixel_order;
>   drm_connector_register(connector);
>  }
-- 

Cheers,
Lyude


Re: [PATCH 03/14] thermal: Add support for sun8i THS on Allwinner H3

2016-06-24 Thread Ondřej Jirman
Thanks, I've incorporated all the suggestions (and more :)), except for
the threaded IRQ, which si expalined below.

regards,
  Ondrej

On 24.6.2016 05:09, Chen-Yu Tsai wrote:
> Hi,
> 
> On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
>> From: Ondrej Jirman 
>>
> 
> The subject could read:
> 
>   thermal: sun8i_ths: Add support for the thermal sensor on Allwinner H3
> 
>> This patch adds support for the sun8i thermal sensor on
>> Allwinner H3 SoC.
>>
>> Signed-off-by: Ondřej Jirman 
>> ---
>>  drivers/thermal/Kconfig |   7 ++
>>  drivers/thermal/Makefile|   1 +
>>  drivers/thermal/sun8i_ths.c | 295 
>> 
>>  3 files changed, 303 insertions(+)
>>  create mode 100644 drivers/thermal/sun8i_ths.c
>>
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index 2d702ca..3de0f8d 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -351,6 +351,13 @@ config MTK_THERMAL
>>   Enable this option if you want to have support for thermal 
>> management
>>   controller present in Mediatek SoCs
>>
>> +config SUN8I_THS
>> +   tristate "sun8i THS driver"
> 
> Explain THS.
> 
>> +   depends on MACH_SUN8I
>> +   depends on OF
>> +   help
>> + Enable this to support thermal reporting on some newer Allwinner 
>> SoCs.
>> +
>>  menu "Texas Instruments thermal drivers"
>>  depends on ARCH_HAS_BANDGAP || COMPILE_TEST
>>  depends on HAS_IOMEM
>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
>> index 10b07c1..7261ee8 100644
>> --- a/drivers/thermal/Makefile
>> +++ b/drivers/thermal/Makefile
>> @@ -51,3 +51,4 @@ obj-$(CONFIG_TEGRA_SOCTHERM)  += tegra/
>>  obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
>>  obj-$(CONFIG_MTK_THERMAL)  += mtk_thermal.o
>>  obj-$(CONFIG_GENERIC_ADC_THERMAL)  += thermal-generic-adc.o
>> +obj-$(CONFIG_SUN8I_THS)+= sun8i_ths.o
>> diff --git a/drivers/thermal/sun8i_ths.c b/drivers/thermal/sun8i_ths.c
>> new file mode 100644
>> index 000..618ccc3
>> --- /dev/null
>> +++ b/drivers/thermal/sun8i_ths.c
>> @@ -0,0 +1,295 @@
>> +/*
>> + * sun8i THS driver
> 
> Explain THS.
> 
>> + *
>> + * Copyright (C) 2016 Ondřej Jirman
>> + * Based on the work of Josef Gajdusek 
>> + *
>> + * This software is licensed under the terms of the GNU General Public
>> + * License version 2, as published by the Free Software Foundation, and
>> + * may be copied, distributed, and modified under those terms.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define THS_H3_CTRL0   0x00
>> +#define THS_H3_CTRL2   0x40
>> +#define THS_H3_INT_CTRL0x44
>> +#define THS_H3_STAT0x48
>> +#define THS_H3_FILTER  0x70
>> +#define THS_H3_CDATA   0x74
>> +#define THS_H3_DATA0x80
>> +
>> +#define THS_H3_CTRL0_SENSOR_ACQ0_OFFS   0
>> +#define THS_H3_CTRL0_SENSOR_ACQ0(x) \
>> +((x) << THS_H3_CTRL0_SENSOR_ACQ0_OFFS)
>> +#define THS_H3_CTRL2_SENSE_EN_OFFS  0
>> +#define THS_H3_CTRL2_SENSE_EN \
>> +BIT(THS_H3_CTRL2_SENSE_EN_OFFS)
>> +#define THS_H3_CTRL2_SENSOR_ACQ1_OFFS   16
>> +#define THS_H3_CTRL2_SENSOR_ACQ1(x) \
>> +((x) << THS_H3_CTRL2_SENSOR_ACQ1_OFFS)
>> +
>> +#define THS_H3_INT_CTRL_DATA_IRQ_EN_OFFS8
>> +#define THS_H3_INT_CTRL_DATA_IRQ_EN \
>> +   BIT(THS_H3_INT_CTRL_DATA_IRQ_EN_OFFS)
>> +#define THS_H3_INT_CTRL_THERMAL_PER_OFFS12
>> +#define THS_H3_INT_CTRL_THERMAL_PER(x) \
>> +   ((x) << THS_H3_INT_CTRL_THERMAL_PER_OFFS)
>> +
>> +#define THS_H3_STAT_DATA_IRQ_STS_OFFS   8
>> +#define THS_H3_STAT_DATA_IRQ_STS \
>> +BIT(THS_H3_STAT_DATA_IRQ_STS_OFFS)
>> +
>> +#define THS_H3_FILTER_TYPE_OFFS 0
>> +#define THS_H3_FILTER_TYPE(x) \
>> +((x) << THS_H3_FILTER_TYPE_OFFS)
>> +#define THS_H3_FILTER_EN_OFFS   2
>> +#define THS_H3_FILTER_EN \
>> +BIT(THS_H3_FILTER_EN_OFFS)
> 
> Is it really necessary to split the lines of all the macros?
> It makes it harder to find and read stuff.
> 
> You're also not using any of the *_OFFS macros in the actual code,
> so just drop them.
> 
>> +
>> +#define THS_H3_CLK_IN 4000  /* Hz */
>> +#define THS_H3_DATA_PERIOD 330  /* ms */
>> +
>> +#define THS_H3_FILTER_TYPE_VALUE   2  /* average over 2^(n+1) 
>> samples */
>> +#define THS_H3_FILTER_DIV  (1 << 
>> (THS_H3_FILTER_TYPE_VALUE + 1))
>> +#define THS_H3_INT_CTRL_THERMAL_PER_VALUE \
>> +   (THS_H3_DATA_PERIOD * (THS_H3_CLK_IN / 1000) / 

Re: [PATCH v9 2/2] Input: synaptics-rmi4 - add SMBus support

2016-06-24 Thread kbuild test robot
Hi,

[auto build test WARNING on wsa/i2c/for-next]
[also build test WARNING on v4.7-rc4 next-20160624]
[cannot apply to input/next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Benjamin-Tissoires/i2c-i801-add-support-of-Host-Notify/20160624-224821
base:   https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux i2c/for-next


coccinelle warnings: (new ones prefixed by >>)

>> drivers/input/rmi4/rmi_smbus.c:448:3-8: No need to set .owner here. The core 
>> will do it.

Please review and possibly fold the followup patch.

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


[PATCH] Input: fix platform_no_drv_owner.cocci warnings

2016-06-24 Thread kbuild test robot
drivers/input/rmi4/rmi_smbus.c:448:3-8: No need to set .owner here. The core 
will do it.

 Remove .owner field if calls are used which set it automatically

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci

CC: Benjamin Tissoires 
Signed-off-by: Fengguang Wu 
---

 rmi_smbus.c |1 -
 1 file changed, 1 deletion(-)

--- a/drivers/input/rmi4/rmi_smbus.c
+++ b/drivers/input/rmi4/rmi_smbus.c
@@ -445,7 +445,6 @@ MODULE_DEVICE_TABLE(i2c, rmi_id);
 
 static struct i2c_driver rmi_smb_driver = {
.driver = {
-   .owner  = THIS_MODULE,
.name   = "rmi4_smbus",
.pm = _smb_pm,
.resume = rmi_smb_resume,


[PATCH v6 1/4] drm/i915/vlv: Make intel_crt_reset() per-encoder

2016-06-24 Thread Lyude
This lets call intel_crt_reset() in contexts where IRQs are disabled and
as such, can't hold the locks required to work with the connectors.

Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä 
Acked-by: Daniel Vetter 
Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/intel_crt.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index e115bcc..dfcd718 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -713,11 +713,11 @@ static int intel_crt_set_property(struct drm_connector 
*connector,
return 0;
 }
 
-static void intel_crt_reset(struct drm_connector *connector)
+static void intel_crt_reset(struct drm_encoder *encoder)
 {
-   struct drm_device *dev = connector->dev;
+   struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   struct intel_crt *crt = intel_attached_crt(connector);
+   struct intel_crt *crt = intel_encoder_to_crt(to_intel_encoder(encoder));
 
if (INTEL_INFO(dev)->gen >= 5) {
u32 adpa;
@@ -739,7 +739,6 @@ static void intel_crt_reset(struct drm_connector *connector)
  */
 
 static const struct drm_connector_funcs intel_crt_connector_funcs = {
-   .reset = intel_crt_reset,
.dpms = drm_atomic_helper_connector_dpms,
.detect = intel_crt_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
@@ -757,6 +756,7 @@ static const struct drm_connector_helper_funcs 
intel_crt_connector_helper_funcs
 };
 
 static const struct drm_encoder_funcs intel_crt_enc_funcs = {
+   .reset = intel_crt_reset,
.destroy = intel_encoder_destroy,
 };
 
@@ -901,5 +901,5 @@ void intel_crt_init(struct drm_device *dev)
dev_priv->fdi_rx_config = I915_READ(FDI_RX_CTL(PIPE_A)) & 
fdi_config;
}
 
-   intel_crt_reset(connector);
+   intel_crt_reset(>base.base);
 }
-- 
2.5.5



[PATCH v6 2/4] drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init()

2016-06-24 Thread Lyude
While VGA hotplugging worked(ish) before, it looks like that was mainly
because we'd unintentionally enable it in
valleyview_crt_detect_hotplug() when we did a force trigger. This
doesn't work reliably enough because whenever the display powerwell on
vlv gets disabled, the values set in VLV_ADPA get cleared and
consequently VGA hotplugging gets disabled. This causes bugs such as one
we found on an Intel NUC, where doing the following sequence of
hotplugs:

  - Disconnect all monitors
  - Connect VGA
  - Disconnect VGA
  - Connect HDMI

Would result in VGA hotplugging becoming disabled, due to the powerwells
getting toggled in the process of connecting HDMI.

Changes since v3:
 - Expose intel_crt_reset() through intel_drv.h and call that in
   vlv_display_power_well_init() instead of
   encoder->base.funcs->reset(>base);

Changes since v2:
 - Use intel_encoder structs instead of drm_encoder structs

Changes since v1:
 - Instead of handling the register writes ourself, we just reuse
   intel_crt_detect()
 - Instead of resetting the ADPA during display IRQ installation, we now
   reset them in vlv_display_power_well_init()

Cc: sta...@vger.kernel.org
Acked-by: Daniel Vetter 
Signed-off-by: Lyude 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_crt.c| 2 +-
 drivers/gpu/drm/i915/intel_drv.h| 2 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c | 7 +++
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index dfcd718..220be7a 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -713,7 +713,7 @@ static int intel_crt_set_property(struct drm_connector 
*connector,
return 0;
 }
 
-static void intel_crt_reset(struct drm_encoder *encoder)
+void intel_crt_reset(struct drm_encoder *encoder)
 {
struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 496c962..dcbfdde 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1075,7 +1075,7 @@ void gen8_irq_power_well_pre_disable(struct 
drm_i915_private *dev_priv,
 
 /* intel_crt.c */
 void intel_crt_init(struct drm_device *dev);
-
+void intel_crt_reset(struct drm_encoder *encoder);
 
 /* intel_ddi.c */
 void intel_ddi_clk_select(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index e856d49..f88ef76 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1065,6 +1065,7 @@ static void vlv_init_display_clock_gating(struct 
drm_i915_private *dev_priv)
 
 static void vlv_display_power_well_init(struct drm_i915_private *dev_priv)
 {
+   struct intel_encoder *encoder;
enum pipe pipe;
 
/*
@@ -1100,6 +1101,12 @@ static void vlv_display_power_well_init(struct 
drm_i915_private *dev_priv)
 
intel_hpd_init(dev_priv);
 
+   /* Re-enable the ADPA, if we have one */
+   for_each_intel_encoder(dev_priv->dev, encoder) {
+   if (encoder->type == INTEL_OUTPUT_ANALOG)
+   intel_crt_reset(>base);
+   }
+
i915_redisable_vga_power_on(dev_priv->dev);
 }
 
-- 
2.5.5



  1   2   3   4   5   6   7   8   >