Re: [PATCH] printk: introduce should_ignore_loglevel()

[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

Re: [PATCH] printk: introduce should_ignore_loglevel()

[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

[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

[PATCH] scsi: ufs: remove unnecessary goto label

[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

[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

Re: [PATCH] orangefs: fix namespace handling

[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

[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

[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 02/14] thermal: sun8i_ths: Add support for the thermal sensor on Allwinner H3

[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;
+   
+   caldata = readl(data->calreg) & 0xfff;
+   

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

[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

[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

[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

[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 05/14] dt-bindings: document SY8106A regulator driver

[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

[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

[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

[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

[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

[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 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[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 06/14] ARM: sun8i: clk: Add clk-factor rate application method

[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 n_start;
+   u8 lock;
 };
 
 

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

[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 08/14] ARM: dts: sun8i: Add thermal sensor node to the sun8i-h3.dtsi

[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

[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

[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 08/14] ARM: dts: sun8i: Add thermal sensor node to the sun8i-h3.dtsi

[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

[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

[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

[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 12/14] ARM: dts: sun8i: Setup CPU operating points for Onrage PI PC

[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

[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

[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 

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

[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 * 1000),
+   .uV_step = (SY8106A_STEP_MV * 1000),
+  

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

[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

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

[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

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

[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

[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

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

[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 
Cc: Nishanth Menon 
Signed-off-by: Guenter Roeck 
---
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().

[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

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

[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)

[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 v3 00/13] Virtually mapped stacks with guard pages (x86, core)

[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
 __visible void 

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

[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] block-dev: enable writeback cgroup support

[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 

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"

[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: [PATCH] hwmon: (emc6w201): trivial fix of spelling mistake "Unknwown" -> "Unknown"

[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

[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

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

[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

[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

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

[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

[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: kernel-4.7 bug in Intel sound and/or ACPI

[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]

[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 5/8] KEYS: Provide software public key query function [ver #2]

[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

[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/2] perf data convert: Include config.h header

[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

[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 1/5] hwmon: (tmp102) Use devm_add_action to register cleanup function

[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 


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: XXX:[2] 0xff
[   34.47877

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

[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 

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

[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

[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] kref: pin objects with dangerously high reference count

[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

[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

[RFC] reference count hardening via kref: another attempt

[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

[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: [linux-sunxi] Re: [PATCH 01/14] ARM: dts: sun8i: Add SID node

[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

[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: [RESEND PATCH v2 1/2] power/cpuidle: enhance the precision of state select

[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

[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 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

[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

[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 07/14] regulator: SY8106A regulator driver

[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,
>>> +   .set_voltage_time_sel = regulator_set_voltage_time_sel,
>>> +   .get_voltage_sel = 

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

[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

[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

[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 03/14] thermal: Add support for sun8i THS on Allwinner H3

[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

[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 v3] Input: synaptics-rmi4: Support regulator supplies

[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

[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

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

[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

[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

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

[kernel test robot]

edd7882bfe250ff6cf7dfbc0d  # 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_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ is

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

[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 

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

[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

[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 1/2] namespaces: don't use from_k*id_munged() with init_user_ns

[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 a/fs/autofs4/inode.c 

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

[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  

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

[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|   2 

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

[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

[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

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

[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

[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

[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 v3] HID: rmi: Make hid-rmi a transport driver for synaptics-rmi4

[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;
 
wait_queue_head_t wait;
 
@@ -115,34 

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

[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

[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

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

[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

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

[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 long *irq_bits)

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

[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!

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

[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!