[PATCH v2 4/4] iio: adc: mxs-lradc: Remove driver

[Ksenija Stanojevic]

Since the driver has been split into mfd there is no reason for it to
stay, so remove it.

Signed-off-by: Ksenija Stanojevic 
---
Changes in v2:
 - none

 drivers/iio/adc/Kconfig |   14 -
 drivers/iio/adc/Makefile|1 -
 drivers/iio/adc/mxs-lradc.c | 1775 ---
 3 files changed, 1790 deletions(-)
 delete mode 100644 drivers/iio/adc/mxs-lradc.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 4ef3ad1..5aba3fe 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -310,20 +310,6 @@ config MEN_Z188_ADC
  This driver can also be built as a module. If so, the module will be
  called men_z188_adc.
 
-config MXS_LRADC
-tristate "Freescale i.MX23/i.MX28 LRADC"
-depends on (ARCH_MXS || COMPILE_TEST) && HAS_IOMEM
-depends on INPUT
-select STMP_DEVICE
-select IIO_BUFFER
-select IIO_TRIGGERED_BUFFER
-help
-  Say yes here to build support for i.MX23/i.MX28 LRADC convertor
-  built into these chips.
-
-  To compile this driver as a module, choose M here: the
-  module will be called mxs-lradc.
-
 config NAU7802
tristate "Nuvoton NAU7802 ADC driver"
depends on I2C
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 9bb35c4..b2382ab 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -30,7 +30,6 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
 obj-$(CONFIG_MCP3422) += mcp3422.o
 obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
 obj-$(CONFIG_MXS_LRADC_ADC) += mxs-lradc-adc.o
-obj-$(CONFIG_MXS_LRADC) += mxs-lradc.o
 obj-$(CONFIG_NAU7802) += nau7802.o
 obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
 obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
diff --git a/drivers/iio/adc/mxs-lradc.c b/drivers/iio/adc/mxs-lradc.c
deleted file mode 100644
index 33051b8..000
--- a/drivers/iio/adc/mxs-lradc.c
+++ /dev/null
@@ -1,1775 +0,0 @@
-/*
- * Freescale MXS LRADC driver
- *
- * Copyright (c) 2012 DENX Software Engineering, GmbH.
- * Marek Vasut 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#define DRIVER_NAME"mxs-lradc"
-
-#define LRADC_MAX_DELAY_CHANS  4
-#define LRADC_MAX_MAPPED_CHANS 8
-#define LRADC_MAX_TOTAL_CHANS  16
-
-#define LRADC_DELAY_TIMER_HZ   2000
-
-/*
- * Make this runtime configurable if necessary. Currently, if the buffered mode
- * is enabled, the LRADC takes LRADC_DELAY_TIMER_LOOP samples of data before
- * triggering IRQ. The sampling happens every (LRADC_DELAY_TIMER_PER / 2000)
- * seconds. The result is that the samples arrive every 500mS.
- */
-#define LRADC_DELAY_TIMER_PER  200
-#define LRADC_DELAY_TIMER_LOOP 5
-
-/*
- * Once the pen touches the touchscreen, the touchscreen switches from
- * IRQ-driven mode to polling mode to prevent interrupt storm. The polling
- * is realized by worker thread, which is called every 20 or so milliseconds.
- * This gives the touchscreen enough fluency and does not strain the system
- * too much.
- */
-#define LRADC_TS_SAMPLE_DELAY_MS   5
-
-/*
- * The LRADC reads the following amount of samples from each touchscreen
- * channel and the driver then computes average of these.
- */
-#define LRADC_TS_SAMPLE_AMOUNT 4
-
-enum mxs_lradc_id {
-   IMX23_LRADC,
-   IMX28_LRADC,
-};
-
-static const char * const mx23_lradc_irq_names[] = {
-   "mxs-lradc-touchscreen",
-   "mxs-lradc-channel0",
-   "mxs-lradc-channel1",
-   "mxs-lradc-channel2",
-   "mxs-lradc-channel3",
-   "mxs-lradc-channel4",
-   "mxs-lradc-channel5",
-   "mxs-lradc-channel6",
-   "mxs-lradc-channel7",
-};
-
-static const char * const mx28_lradc_irq_names[] = {
-   "mxs-lradc-touchscreen",
-   "mxs-lradc-thresh0",
-   "mxs-lradc-thresh1",
-   "mxs-lradc-channel0",
-   "mxs-lradc-channel1",
-   "mxs-lradc-channel2",
-   "mxs-lradc-channel3",
-   "mxs-lradc-channel4",
-   "mxs-lradc-channel5",
-   "mxs-lradc-channel6",
-   "mxs-lradc-channel7",
-   "mxs-lradc-button0",
-   "mxs-lradc-button1",
-};
-
-struct mxs_lradc_of_config {
-   const int   irq_count;
-   const char * const  *irq_name;

[PATCH v2] thinkpad_acpi: Add support for HKEY version 0x200

[Lyude]

From: Dennis Wassenberg 

Lenovo Thinkpad devices T460, T460s, T460p, T560, X260 use
HKEY version 0x200 without adaptive keyboard.

HKEY version 0x200 has method MHKA with one parameter value.
Passing parameter value 1 will get hotkey_all_mask (the same like
HKEY version 0x100 without parameter). Passing parameter value 2 to
MHKA method will retrieve hotkey_all_adaptive_mask. If 0 is returned in
that case there is no adaptive keyboard available.

Signed-off-by: Dennis Wassenberg 
Signed-off-by: Lyude 
Tested-by: Lyude 
Tested-by: Marco Trevisan 
Acked-by: Henrique de Moraes Holschuh 
---
Changes since v1:
 - Fix all of the indenting issues
 - Add appropriate Tested-by's, Signed-off's, etc.

 drivers/platform/x86/thinkpad_acpi.c | 85 ++--
 1 file changed, 63 insertions(+), 22 deletions(-)

diff --git a/drivers/platform/x86/thinkpad_acpi.c 
b/drivers/platform/x86/thinkpad_acpi.c
index 9255ff3..210ecf5 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -2043,6 +2043,7 @@ static int hotkey_autosleep_ack;
 
 static u32 hotkey_orig_mask;   /* events the BIOS had enabled */
 static u32 hotkey_all_mask;/* all events supported in fw */
+static u32 hotkey_adaptive_all_mask;   /* all adaptive events supported in fw 
*/
 static u32 hotkey_reserved_mask;   /* events better left disabled */
 static u32 hotkey_driver_mask; /* events needed by the driver */
 static u32 hotkey_user_mask;   /* events visible to userspace */
@@ -2742,6 +2743,17 @@ static ssize_t hotkey_all_mask_show(struct device *dev,
 
 static DEVICE_ATTR_RO(hotkey_all_mask);
 
+/* sysfs hotkey all_mask --- */
+static ssize_t hotkey_adaptive_all_mask_show(struct device *dev,
+  struct device_attribute *attr,
+  char *buf)
+{
+   return snprintf(buf, PAGE_SIZE, "0x%08x\n",
+   hotkey_adaptive_all_mask | hotkey_source_mask);
+}
+
+static DEVICE_ATTR_RO(hotkey_adaptive_all_mask);
+
 /* sysfs hotkey recommended_mask --- */
 static ssize_t hotkey_recommended_mask_show(struct device *dev,
struct device_attribute *attr,
@@ -2985,6 +2997,7 @@ static struct attribute *hotkey_attributes[] __initdata = 
{
_attr_wakeup_hotunplug_complete.attr,
_attr_hotkey_mask.attr,
_attr_hotkey_all_mask.attr,
+   _attr_hotkey_adaptive_all_mask.attr,
_attr_hotkey_recommended_mask.attr,
 #ifdef CONFIG_THINKPAD_ACPI_HOTKEY_POLL
_attr_hotkey_source_mask.attr,
@@ -3321,20 +3334,6 @@ static int __init hotkey_init(struct ibm_init_struct 
*iibm)
if (!tp_features.hotkey)
return 1;
 
-   /*
-* Check if we have an adaptive keyboard, like on the
-* Lenovo Carbon X1 2014 (2nd Gen).
-*/
-   if (acpi_evalf(hkey_handle, , "MHKV", "qd")) {
-   if ((hkeyv >> 8) == 2) {
-   tp_features.has_adaptive_kbd = true;
-   res = sysfs_create_group(_pdev->dev.kobj,
-   _kbd_attr_group);
-   if (res)
-   goto err_exit;
-   }
-   }
-
quirks = tpacpi_check_quirks(tpacpi_hotkey_qtable,
 ARRAY_SIZE(tpacpi_hotkey_qtable));
 
@@ -3357,18 +3356,16 @@ static int __init hotkey_init(struct ibm_init_struct 
*iibm)
   A30, R30, R31, T20-22, X20-21, X22-24.  Detected by checking
   for HKEY interface version 0x100 */
if (acpi_evalf(hkey_handle, , "MHKV", "qd")) {
-   if ((hkeyv >> 8) != 1) {
-   pr_err("unknown version of the HKEY interface: 0x%x\n",
-  hkeyv);
-   pr_err("please report this to %s\n", TPACPI_MAIL);
-   } else {
+   vdbg_printk(TPACPI_DBG_INIT | TPACPI_DBG_HKEY,
+   "firmware HKEY interface version: 0x%x\n",
+   hkeyv);
+
+   switch (hkeyv >> 8) {
+   case 1:
/*
 * MHKV 0x100 in A31, R40, R40e,
 * T4x, X31, and later
 */
-   vdbg_printk(TPACPI_DBG_INIT | TPACPI_DBG_HKEY,
-   "firmware HKEY interface version: 0x%x\n",
-   hkeyv);
 
/* Paranoia check AND init hotkey_all_mask */
if (!acpi_evalf(hkey_handle, _all_mask,
@@ -3381,6 +3378,50 @@ static int __init hotkey_init(struct ibm_init_struct 
*iibm)
} else {

[PATCH 05/11] clk: imx: refine the powerup_set bit of clk-pllv3

[Dong Aisheng]

There's a powerdown bit already, so let's change the name of
powerup_set bit to power_invert to reflects the power polarity
to make it less confusing.

Signed-off-by: Dong Aisheng 
---
 drivers/clk/imx/clk-pllv3.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
index eea2b1b3791e..3fdfb6d2cc71 100644
--- a/drivers/clk/imx/clk-pllv3.c
+++ b/drivers/clk/imx/clk-pllv3.c
@@ -29,8 +29,8 @@
  * struct clk_pllv3 - IMX PLL clock version 3
  * @clk_hw: clock source
  * @base:   base address of PLL registers
- * @powerup_set: set POWER bit to power up the PLL
- * @powerdown:   pll powerdown offset bit
+ * @powerdown:  pll powerdown bit offset
+ * @power_invert: set powerdown bit to power up the PLL
  * @div_mask:   mask of divider bits
  * @div_shift:  shift of divider bits
  *
@@ -40,7 +40,7 @@
 struct clk_pllv3 {
struct clk_hw   hw;
void __iomem*base;
-   boolpowerup_set;
+   boolpower_invert;
u32 powerdown;
u32 div_mask;
u32 div_shift;
@@ -55,7 +55,7 @@ static int clk_pllv3_wait_lock(struct clk_pllv3 *pll)
u32 val = readl_relaxed(pll->base) & pll->powerdown;
 
/* No need to wait for lock when pll is not powered up */
-   if ((pll->powerup_set && !val) || (!pll->powerup_set && val))
+   if ((pll->power_invert && !val) || (!pll->power_invert && val))
return 0;
 
/* Wait for PLL to lock */
@@ -76,7 +76,7 @@ static int clk_pllv3_prepare(struct clk_hw *hw)
u32 val;
 
val = readl_relaxed(pll->base);
-   if (pll->powerup_set)
+   if (pll->power_invert)
val |= pll->powerdown;
else
val &= ~pll->powerdown;
@@ -91,7 +91,7 @@ static void clk_pllv3_unprepare(struct clk_hw *hw)
u32 val;
 
val = readl_relaxed(pll->base);
-   if (pll->powerup_set)
+   if (pll->power_invert)
val &= ~pll->powerdown;
else
val |= pll->powerdown;
@@ -326,7 +326,7 @@ struct clk *imx_clk_pllv3(enum imx_pllv3_type type, const 
char *name,
pll->div_shift = 1;
case IMX_PLLV3_USB:
ops = _pllv3_ops;
-   pll->powerup_set = true;
+   pll->power_invert = true;
break;
case IMX_PLLV3_AV:
ops = _pllv3_av_ops;
-- 
1.9.1

[PATCH 04/11] clk: imx: correct dram pll type

[Dong Aisheng]

From: Anson Huang 

DRAM PLL is a audio/video type PLL, need to correct
it to get correct ops of PLL.

Signed-off-by: Anson Huang 
Signed-off-by: Dong Aisheng 
---
 drivers/clk/imx/clk-imx7d.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
index 1cb866773fc0..dc8c3355a66d 100644
--- a/drivers/clk/imx/clk-imx7d.c
+++ b/drivers/clk/imx/clk-imx7d.c
@@ -395,7 +395,7 @@ static void __init imx7d_clocks_init(struct device_node 
*ccm_node)
clks[IMX7D_PLL_VIDEO_MAIN_SRC] = imx_clk_mux("pll_video_main_src", base 
+ 0x130, 14, 2, pll_bypass_src_sel, ARRAY_SIZE(pll_bypass_src_sel));
 
clks[IMX7D_PLL_ARM_MAIN]  = imx_clk_pllv3(IMX_PLLV3_SYS, 
"pll_arm_main", "pll_arm_main_src", base + 0x60, 0x7f);
-   clks[IMX7D_PLL_DRAM_MAIN] = imx_clk_pllv3(IMX_PLLV3_SYS, 
"pll_dram_main", "pll_dram_main_src", base + 0x70, 0x7f);
+   clks[IMX7D_PLL_DRAM_MAIN] = imx_clk_pllv3(IMX_PLLV3_AV, 
"pll_dram_main", "pll_dram_main_src", base + 0x70, 0x7f);
clks[IMX7D_PLL_SYS_MAIN]  = imx_clk_pllv3(IMX_PLLV3_GENERIC, 
"pll_sys_main", "pll_sys_main_src", base + 0xb0, 0x1);
clks[IMX7D_PLL_ENET_MAIN] = imx_clk_pllv3(IMX_PLLV3_ENET_IMX7, 
"pll_enet_main", "pll_enet_main_src", base + 0xe0, 0x0);
clks[IMX7D_PLL_AUDIO_MAIN] = imx_clk_pllv3(IMX_PLLV3_AV, 
"pll_audio_main", "pll_audio_main_src", base + 0xf0, 0x7f);
-- 
1.9.1

[PATCH 02/11] clk: imx: correct AV PLL rate formula

[Dong Aisheng]

From: Anson Huang 

The audio/video PLL's rate calculation is as below in RM:

Fref * (DIV_SELECT + NUM / DENOM), in origin clk-pllv3's
code, below code is used:

(parent_rate * div) + ((parent_rate / mfd) * mfn

as it does NOT consider the float data using div, so below
formula should be used as a decent method:

(parent_rate * div) + ((parent_rate * mfn) / mfd)

and we also need to consider parent_rate * mfd may overflow
a 32 bit value, 64 bit value should be used.

After updating this formula, the dram PLL's rate is
1066MHz, which is correct, while the old formula gets
1056MHz.

[Aisheng: fix clk_pllv3_av_round_rate too]

Signed-off-by: Anson Huang 
Signed-off-by: Dong Aisheng 
---
 drivers/clk/imx/clk-pllv3.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
index 44d294a336f0..eea2b1b3791e 100644
--- a/drivers/clk/imx/clk-pllv3.c
+++ b/drivers/clk/imx/clk-pllv3.c
@@ -218,8 +218,12 @@ static unsigned long clk_pllv3_av_recalc_rate(struct 
clk_hw *hw,
u32 mfn = readl_relaxed(pll->base + PLL_NUM_OFFSET);
u32 mfd = readl_relaxed(pll->base + PLL_DENOM_OFFSET);
u32 div = readl_relaxed(pll->base) & pll->div_mask;
+   u64 temp64 = (u64)parent_rate;
 
-   return (parent_rate * div) + ((parent_rate / mfd) * mfn);
+   temp64 *= mfn;
+   do_div(temp64, mfd);
+
+   return (parent_rate * div) + (u32)temp64;
 }
 
 static long clk_pllv3_av_round_rate(struct clk_hw *hw, unsigned long rate,
@@ -243,7 +247,7 @@ static long clk_pllv3_av_round_rate(struct clk_hw *hw, 
unsigned long rate,
do_div(temp64, parent_rate);
mfn = temp64;
 
-   return parent_rate * div + parent_rate / mfd * mfn;
+   return parent_rate * div + parent_rate * mfn / mfd;
 }
 
 static int clk_pllv3_av_set_rate(struct clk_hw *hw, unsigned long rate,
-- 
1.9.1

[PATCH 11/11] clk: imx7d: fix pll clock parents

[Dong Aisheng]

pllx_bypass_src mux shouldn't be the parent of pllx clock
since it's only valid when when pllx BYPASS bit is set.
Thus it is actually one parent of pllx_bypass only.

Instead, pllx parent should be fixed to osc according to
reference manual.
Other plls have the same issue.

Signed-off-by: Dong Aisheng 
---
 drivers/clk/imx/clk-imx7d.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
index dc8c3355a66d..738a5289b378 100644
--- a/drivers/clk/imx/clk-imx7d.c
+++ b/drivers/clk/imx/clk-imx7d.c
@@ -394,12 +394,12 @@ static void __init imx7d_clocks_init(struct device_node 
*ccm_node)
clks[IMX7D_PLL_AUDIO_MAIN_SRC] = imx_clk_mux("pll_audio_main_src", base 
+ 0xf0, 14, 2, pll_bypass_src_sel, ARRAY_SIZE(pll_bypass_src_sel));
clks[IMX7D_PLL_VIDEO_MAIN_SRC] = imx_clk_mux("pll_video_main_src", base 
+ 0x130, 14, 2, pll_bypass_src_sel, ARRAY_SIZE(pll_bypass_src_sel));
 
-   clks[IMX7D_PLL_ARM_MAIN]  = imx_clk_pllv3(IMX_PLLV3_SYS, 
"pll_arm_main", "pll_arm_main_src", base + 0x60, 0x7f);
-   clks[IMX7D_PLL_DRAM_MAIN] = imx_clk_pllv3(IMX_PLLV3_AV, 
"pll_dram_main", "pll_dram_main_src", base + 0x70, 0x7f);
-   clks[IMX7D_PLL_SYS_MAIN]  = imx_clk_pllv3(IMX_PLLV3_GENERIC, 
"pll_sys_main", "pll_sys_main_src", base + 0xb0, 0x1);
-   clks[IMX7D_PLL_ENET_MAIN] = imx_clk_pllv3(IMX_PLLV3_ENET_IMX7, 
"pll_enet_main", "pll_enet_main_src", base + 0xe0, 0x0);
-   clks[IMX7D_PLL_AUDIO_MAIN] = imx_clk_pllv3(IMX_PLLV3_AV, 
"pll_audio_main", "pll_audio_main_src", base + 0xf0, 0x7f);
-   clks[IMX7D_PLL_VIDEO_MAIN] = imx_clk_pllv3(IMX_PLLV3_AV, 
"pll_video_main", "pll_video_main_src", base + 0x130, 0x7f);
+   clks[IMX7D_PLL_ARM_MAIN]  = imx_clk_pllv3(IMX_PLLV3_SYS, 
"pll_arm_main", "osc", base + 0x60, 0x7f);
+   clks[IMX7D_PLL_DRAM_MAIN] = imx_clk_pllv3(IMX_PLLV3_AV, 
"pll_dram_main", "osc", base + 0x70, 0x7f);
+   clks[IMX7D_PLL_SYS_MAIN]  = imx_clk_pllv3(IMX_PLLV3_GENERIC, 
"pll_sys_main", "osc", base + 0xb0, 0x1);
+   clks[IMX7D_PLL_ENET_MAIN] = imx_clk_pllv3(IMX_PLLV3_ENET_IMX7, 
"pll_enet_main", "osc", base + 0xe0, 0x0);
+   clks[IMX7D_PLL_AUDIO_MAIN] = imx_clk_pllv3(IMX_PLLV3_AV, 
"pll_audio_main", "osc", base + 0xf0, 0x7f);
+   clks[IMX7D_PLL_VIDEO_MAIN] = imx_clk_pllv3(IMX_PLLV3_AV, 
"pll_video_main", "osc", base + 0x130, 0x7f);
 
clks[IMX7D_PLL_ARM_MAIN_BYPASS]  = 
imx_clk_mux_flags("pll_arm_main_bypass", base + 0x60, 16, 1, 
pll_arm_bypass_sel, ARRAY_SIZE(pll_arm_bypass_sel), CLK_SET_RATE_PARENT);
clks[IMX7D_PLL_DRAM_MAIN_BYPASS] = 
imx_clk_mux_flags("pll_dram_main_bypass", base + 0x70, 16, 1, 
pll_dram_bypass_sel, ARRAY_SIZE(pll_dram_bypass_sel), CLK_SET_RATE_PARENT);
-- 
1.9.1

Re: [PATCH] nbd: pass the nbd pointer for flags debugfs

[Jens Axboe]

On 06/08/2016 08:32 AM, Josef Bacik wrote:

We were passing in  for the private data in debugfs_create_file() for the
flags entry.  We expect it to just be nbd, fix this so we get proper output from
this debugfs entry.


Added for this series, thanks Josef.


--
Jens Axboe

Re: [RFC][PATCH 0/6] ion: improved ABI

[Brian Starkey]

Hi Laura,

On Mon, Jun 06, 2016 at 11:23:27AM -0700, Laura Abbott wrote:

The ABI for Ion's ioctl interface are a pain to work with. The heap IDs
are a 32-bit non-discoverable namespace that form part of the ABI. There's
no way to determine what ABI version is in use which leads to problems
if the ABI changes or needs to be updated.

This series is a first approach to give a better ABI for Ion. This includes:

- Following the advice in botching-up-ioctls.txt
- Ioctl for ABI version
- Dynamic assignment of heap ids
- queryable heap ids
- Runtime mapping of heap ids, including fallbacks. This avoids the need to
 encode the fallbacks as an ABI.

I'm most interested in feedback if this ABI is actually an improvement and
usable. The heap id map/query interface seems error prone but I didn't have
a cleaner solution. There aren't any kernel APIs for the new features as the
focus was on a userspace API but I anticipate that following easily once
the userspace API is established.



If I understand it right, the big improvement here is that userspace can
find out what heap IDs are available, and what type of heap they
correspond to? This seems good.

I'm not sure about how userspace is meant to use the usage mappings
though. Who calls ION_IOC_ID_MAP?

(also, map/mapping is pretty overloaded. How about groups/groupings?)

If I assume that the thing calling ION_IOC_ID_MAP is the same thing
doing the allocating, then there doesn't seem to be much need for
creating mappings. The combined mapper/allocator would necessarily need
some knowledge about which types can satisfy which usage, and so could
follow something like this:
 1. The heaps can be queried, finding their IDs and types
 2. A mask of heap IDs can be created which satisfies a "usage", based
on the queried types
 3. Allocation operations can then simply use this constructed mask

On the other hand, if I assume that the thing doing the allocating is
different to the thing doing the usage mapping (i.e. the allocator
doesn't need to know about heap _types_, only usages); then I can't see
a way for the allocator to figure out which usage_id it's meant to
allocate with - which puts it right back to the old problem of opaque
heap IDs (-> opaque usage_ids), except it's worse because they can
change dynamically.

Thanks,
Brian



Thanks,
Laura

P.S. Not to turn this into a bike shedding session but if you have suggestions
for a name for this framework other than Ion I would be interested to hear
them. Too many other things are already named Ion.

Laura Abbott (6):
 staging: android: ion: return error value for ion_device_add_heap
 staging: android: ion: Switch to using an idr to manage heaps
 staging: android: ion: Drop heap type masks
 staging: android: ion: Pull out ion ioctls to a separate file
 staging: android: ion: Add an ioctl for ABI checking
 staging: android: ion: Introduce new ioctls for dynamic heaps

drivers/staging/android/ion/Makefile|   3 +-
drivers/staging/android/ion/ion-ioctl.c | 243 ++
drivers/staging/android/ion/ion.c   | 438 
drivers/staging/android/ion/ion_priv.h  | 109 +++-
drivers/staging/android/uapi/ion.h  | 164 +++-
5 files changed, 728 insertions(+), 229 deletions(-)
create mode 100644 drivers/staging/android/ion/ion-ioctl.c

-- 2.5.5

Re: [PATCH 0/2] qcom: add l2 cache perf events driver

[Neil Leeder]

On 6/6/2016 05:04 AM, Mark Rutland wrote:
> On Fri, Jun 03, 2016 at 05:03:30PM -0400, Neil Leeder wrote:
>> This adds a new dynamic PMU to the Perf Events framework to program
>> and control the L2 cache PMUs in some Qualcomm Technologies SOCs.
>>
>> The driver exports formatting and event information to sysfs so it can
>> be used by the perf user space tools with the syntax:
>> perf stat -e l2cache/event=0x42/
>>
>> One point to note is that there are certain combinations of events
>> which are invalid, and which are detected in event_add().
> 
> Which combinations of events are invalid?
> 
> Please elaborate.
> 
>> Simply having event_add() fail would result in event_sched_in() making
>> it Inactive, treating it as over-allocation of counters, leading to
>> repeated attempts to allocate the events and ending up with a
>> statistical count.  A solution for this situation is to turn the
>> conflicting event off in event_add(). This allows a single error
>> message to be generated, and no recurring attempts to re-add the
>> invalid event. In order for this to work, event_sched_in()
>> needs to detect that event_add() changed the state, and not override it
>> and force it to Inactive.
> 
> For heterogeneous PMUs, we added the pmu::filter_match(event) callback
> for a similar purpose: preventing an event from being scheduled on a
> core which does not support that event, while allowing other events to
> be scheduled.
> 
> So if you truly need to filter events, the infrastructure for doing so
> already exists.
> 
> However, you will need to elaborate on "there are certain combinations
> of events which are invalid".
> 

Qualcomm PMUs have events arranged in a matrix of rows and columns.
Only one event can be enabled from each column at once. So this isn't a
heterogeneous CPU issue, and it doesn't seem to fit into filter_match()
because it is not an absolute restriction that this event can't be
enabled on this cpu, it's related to the other events which have 
already been enabled.

>> This patchset requires:
>> [PATCH] soc: qcom: provide mechanism for drivers to access L2 registers
> 
> A link would be remarkably helpful.

http://archive.arm.linux.org.uk/lurker/message/20160603.205900.1970f20d.en.html

> 
> Better would be to fold that patch into this series, as it's the only
> user, and both are helpful review context for the other.
> 

The L2 PMU driver is the first user of the L2-accessors patch
but it won't be the only one, which is why I kept it separate.

> Thanks,
> Mark.
> 

Neil

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

Re: [PATCH 0/8] TI AM335x TSC/ADC cleanup

[Lee Jones]

On Tue, 31 May 2016, Andrew F. Davis wrote:

> Hello all,
> 
> This series is a group of non-functional changes I would
> like to get in this cycle to prepare some regmap based
> changes I would like to make next cycle. Hopefully the
> churn can be seen as more useful in that case.

Once you've finished spell checking all of your commits, please submit
with the Acks you have collected.

> Andrew F. Davis (8):
>   mfd: ti_am335x_tscadc: Use SIMPLE_DEV_PM_OPS helper macro
>   iio: adc: ti_am335x_adc: use SIMPLE_DEV_PM_OPS helper macro
>   mfd: ti_am335x_tscadc: Remove use of single line functions
>   mfd: ti_am335x_tscadc: Unify variable naming when refrencing
> ti_tscadc_dev
>   mfd: ti_am335x_tscadc: Rename regmap_tscadc to regmap
>   mfd: ti_am335x_tscadc: use variable name for sizeof() operator
>   iio: adc: ti_am335x_adc: use variable names for sizeof() operator
>   Input: ti_am335x_tsc - use variable name for sizeof() operator
> 
>  drivers/iio/adc/ti_am335x_adc.c   |  22 ++---
>  drivers/input/touchscreen/ti_am335x_tsc.c |   2 +-
>  drivers/mfd/ti_am335x_tscadc.c| 135 
> +-
>  include/linux/mfd/ti_am335x_tscadc.h  |   2 +-
>  4 files changed, 64 insertions(+), 97 deletions(-)
> 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 0/5] Hi655x powerkey support for HiKey (v2)

[Lee Jones]

On Fri, 03 Jun 2016, John Stultz wrote:

> This patchset enables the pmic powerkey to function on HiKey.
> 
> I wanted to submit it for some initial review. Feedback would
> be greatly appreciated!
> 
> New in v2:
> * Larger rework to the powerkey driver, integrating feedback
>   from Dmitry
> * Minor dts cleanup suggested by Rob

Looks like I reviewed your RFC instead.

The points are still valid here though.

> Cc: Dmitry Torokhov 
> Cc: Rob Herring 
> Cc: Pawel Moll 
> Cc: Mark Rutland 
> Cc: Ian Campbell 
> Cc: Kumar Gala 
> Cc: Lee Jones 
> Cc: Jorge Ramirez-Ortiz 
> Cc: Wei Xu 
> Cc: Guodong Xu 
> 
> 
> Guodong Xu (1):
>   arm64: dts: Add powerkey info to pmic for hi6220-hikey
> 
> John Stultz (3):
>   dts: bindings: Add binding documentation for hisilicon,hi6552-powerkey
>   hi655x-pmic: Make hi655x pmic logic probe child nodes in the dt
>   hi655x-pmic: Fixup issue with un-acked interrupts
> 
> Jorge Ramirez-Ortiz (1):
>   drivers: input: powerkey for HISI 65xx SoC
> 
>  .../bindings/input/hisilicon,hi6552-powerkey.txt   |  40 ++
>  arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts |   7 +
>  drivers/input/misc/Kconfig |   9 ++
>  drivers/input/misc/Makefile|   1 +
>  drivers/input/misc/hisi_powerkey.c | 155 
> +
>  drivers/mfd/hi655x-pmic.c  |   9 ++
>  6 files changed, 221 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/input/hisilicon,hi6552-powerkey.txt
>  create mode 100644 drivers/input/misc/hisi_powerkey.c
> 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 0/2] *** r8723au: Replace semaphore lock with mutex ***

[Arnd Bergmann]

On Wednesday, June 8, 2016 1:10:53 PM CEST Binoy Jayan wrote:
> These are a set of patches which removes semaphores from:
> 
> drivers/staging/rtl8723au
> 
> These are part of a bigger effort to eliminate all semaphores 
> from the linux kernel.
> 
> They build correctly (individually and as a whole).

Looks good,

Reviewed-by: Arnd Bergmann 

Re: [PATCH v8 2/3] CMDQ: Mediatek CMDQ driver

[Matthias Brugger]

On 08/06/16 14:25, Horng-Shyang Liao wrote:

Hi Matthias,

On Wed, 2016-06-08 at 12:45 +0200, Matthias Brugger wrote:


On 08/06/16 07:40, Horng-Shyang Liao wrote:

Hi Matthias,

On Tue, 2016-06-07 at 18:59 +0200, Matthias Brugger wrote:


On 03/06/16 15:11, Matthias Brugger wrote:




[...]


+
+smp_mb(); /* modify jump before enable thread */
+}
+
+cmdq_thread_writel(thread, task->pa_base +
task->command_size,
+   CMDQ_THR_END_ADDR);
+cmdq_thread_resume(thread);
+}
+list_move_tail(>list_entry, >task_busy_list);
+spin_unlock_irqrestore(>exec_lock, flags);
+}
+
+static void cmdq_handle_error_done(struct cmdq *cmdq,
+   struct cmdq_thread *thread, u32 irq_flag)
+{
+struct cmdq_task *task, *tmp, *curr_task = NULL;
+u32 curr_pa;
+struct cmdq_cb_data cmdq_cb_data;
+bool err;
+
+if (irq_flag & CMDQ_THR_IRQ_ERROR)
+err = true;
+else if (irq_flag & CMDQ_THR_IRQ_DONE)
+err = false;
+else
+return;
+
+curr_pa = cmdq_thread_readl(thread, CMDQ_THR_CURR_ADDR);
+
+list_for_each_entry_safe(task, tmp, >task_busy_list,
+ list_entry) {
+if (curr_pa >= task->pa_base &&
+curr_pa < (task->pa_base + task->command_size))


What are you checking here? It seems as if you make some implcit
assumptions about pa_base and the order of execution of
commands in the
thread. Is it save to do so? Does dma_alloc_coherent give any
guarantees
about dma_handle?


1. Check what is the current running task in this GCE thread.
2. Yes.
3. Yes, CMDQ doesn't use iommu, so physical address is continuous.



Yes, physical addresses might be continous, but AFAIK there is no
guarantee that the dma_handle address is steadily growing, when
calling
dma_alloc_coherent. And if I understand the code correctly, you
use this
assumption to decide if the task picked from task_busy_list is
currently
executing. So I think this mecanism is not working.


I don't use dma_handle address, and just use physical addresses.
 From CPU's point of view, tasks are linked by the busy list.
 From GCE's point of view, tasks are linked by the JUMP command.


In which cases does the HW thread raise an interrupt.
In case of error. When does CMDQ_THR_IRQ_DONE get raised?


GCE will raise interrupt if any task is done or error.
However, GCE is fast, so CPU may get multiple done tasks
when it is running ISR.

In case of error, that GCE thread will pause and raise interrupt.
So, CPU may get multiple done tasks and one error task.



I think we should reimplement the ISR mechanism. Can't we just read
CURR_IRQ_STATUS and THR_IRQ_STATUS in the handler and leave
cmdq_handle_error_done to the thread_fn? You will need to pass
information from the handler to thread_fn, but that shouldn't be an
issue. AFAIK interrupts are disabled in the handler, so we should stay
there as short as possible. Traversing task_busy_list is expensive, so
we need to do it in a thread context.


Actually, our initial implementation is similar to your suggestion,
but display needs CMDQ to return callback function very precisely,
else display will drop frame.
For display, CMDQ interrupt will be raised every 16 ~ 17 ms,
and CMDQ needs to call callback function in ISR.
If we defer callback to workqueue, the time interval may be larger than
32 ms.sometimes.



I think the problem is, that you implemented the workqueue as a ordered
workqueue, so there is no parallel processing. I'm still not sure why
you need the workqueue to be ordered. Can you please explain.


The order should be kept.
Let me use mouse cursor as an example.
If task 1 means move mouse cursor to point A, task 2 means point B,
and task 3 means point C, our expected result is A -> B -> C.
If the order is not kept, the result could become A -> C -> B.



Got it, thanks for the clarification.



I think a way to get rid of the workqueue is to use a timer, which gets
programmed to the time a timeout in the first task in the busy list
would happen. Everytime we update the busy list (e.g. because of task
got finished by the thread), we update the timer. When the timer
triggers, which hopefully won't happen too often, we return timeout on
the busy list elements, until the time is lower then the actual time.

At least with this we can reduce the data structures in this driver and
make it more lightweight.


  From my understanding, your proposed method can handle timeout case.

However, the workqueue is also in charge of releasing tasks.
Do you take releasing tasks into consideration by using the proposed
timer method?
Furthermore, I think the code will become more complex if we also use
timer to implement releasing tasks.



Can't we call
  clk_disable_unprepare(cmdq->clock);
  cmdq_task_release(task);
after invoking the callback?


Do you mean just call these two functions in ISR?
My major concern is dma_free_coherent() and kfree() in
cmdq_task_release(task).

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

[Vladimir Zapolskiy]

Hi Wolfram,

On 08.06.2016 10:56, Wolfram Sang wrote:
> 
>> Changes from v2 to v3:
> 
> This series was odd to review. I am used to that we build stuff on top
> of each other to strive for the best technical solution. I didn't expect
> that you like all of my changes, but at least some of them were obviously
> correct. But since even those were ignored, it really feels like a step
> backwards and thus, the reviewing time a bit wasted :(
> 
> Stuff like 64-bit support and the softdog timer (so people can actually
> test the framework) is completely missing, too. Why not adding those?
> They are easy patches.
> 

I don't object or ignore your work, I'm sorry if this series makes you
feel sad, I'll do all my best for you in v4. I'm sincerely happy that
I found one more independent user of the feature, and I appreciate your
done work and review comments, even downloading, applying and adjusting
the changes took your time, and because I'm pretty sure you don't have
much spare time I value it.

Quite many times when I sent long non-trivial series in the past they
were either deterrent for review and plainly ignored or expectedly
caused too many review comments at once, that's why here in the cover
letter I emphasized :

>> In comparison to v1 and v2 this version does not have quite many
>> important features, because now the goal is to initiate technical
>> review of the simplest possible core change, the fat tail is put
>> aside at the moment.

I hope I managed to collect enough review comments (if Guenter adds
a note to your/my comments to v3 4/6, that would be perfect), and I'll
add your new changes and my cut-off changes to v4 pile.

With best wishes,
Vladimir

Re: [PATCH 3/5] lkdtm: add function for testing .rodata section

[Kees Cook]

On Tue, Jun 7, 2016 at 6:02 PM, Laura Abbott  wrote:
> On 06/07/2016 02:57 PM, Kees Cook wrote:
>>
>> This adds a function that lives in the .rodata section. The section
>> flags are corrected using objcopy since there is no way with gcc to
>> declare section flags in an architecture-agnostic way.
>>
>
> Permit me to be the bearer of bad architecture news once again. With
> arm64 cross compiler (both Fedora 6.1.1 and Linaro 5.1)
>
>   CC  drivers/misc/lkdtm_rodata.o
>   OBJCOPY drivers/misc/lkdtm_rodata_objcopy.o
>   LD  drivers/misc/lkdtm.o
> drivers/misc/lkdtm_rodata_objcopy.o: file not recognized: File format not
> recognized
> scripts/Makefile.build:423: recipe for target 'drivers/misc/lkdtm.o' failed
> make[2]: *** [drivers/misc/lkdtm.o] Error 1
> scripts/Makefile.build:440: recipe for target 'drivers/misc' failed
> make[1]: *** [drivers/misc] Error 2
> Makefile:985: recipe for target 'drivers' failed
> make: *** [drivers] Error 2
>
>
> As far as I can tell this is because arm64 defines OBJCOPYFLAGS and they get
> propagated to objcopy
>
> aarch64-linux-gnu-objcopy -O binary -R .note -R .note.gnu.build-id -R
> .comment
> -S --set-section-flags .text=alloc,readonly
> --rename-section .text=.rodata drivers/misc/lkdtm_rodata.o
> drivers/misc/lkdtm_rodata_objcopy.o
>
> vs x86
>
> objcopy  --set-section-flags .text=alloc,readonly --rename-section
> .text=.rodata
> drivers/misc/lkdtm_rodata.o drivers/misc/lkdtm_rodata_objcopy.o
>
>
> specifically it's the -O binary that seems to break things, the same failure
> happens on x86 as well with the the same commands. It works if I clear out
> the OBJCOPYFLAGS variable first but I don't think that's the correct way to
> fix this.
>
> Thanks,
> Laura
>
>
>> Signed-off-by: Kees Cook 
>> ---
>>  drivers/misc/Makefile   |  7 +++
>>  drivers/misc/lkdtm.h|  6 ++
>>  drivers/misc/lkdtm_core.c   | 24 +---
>>  drivers/misc/lkdtm_rodata.c | 10 ++
>>  4 files changed, 40 insertions(+), 7 deletions(-)
>>  create mode 100644 drivers/misc/lkdtm.h
>>  create mode 100644 drivers/misc/lkdtm_rodata.c
>>
>> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
>> index c3cb6ad8cc37..b2d3d68dfa22 100644
>> --- a/drivers/misc/Makefile
>> +++ b/drivers/misc/Makefile
>> @@ -59,3 +59,10 @@ obj-$(CONFIG_CXL_BASE)   += cxl/
>>  obj-$(CONFIG_PANEL) += panel.o
>>
>>  lkdtm-$(CONFIG_LKDTM)  += lkdtm_core.o
>> +lkdtm-$(CONFIG_LKDTM)  += lkdtm_rodata_objcopy.o
>> +
>> +OBJCOPYFLAGS_lkdtm_rodata_objcopy.o := \
>> +   --set-section-flags .text=alloc,readonly \
>> +   --rename-section .text=.rodata
>> +$(obj)/lkdtm_rodata_objcopy.o: $(obj)/lkdtm_rodata.o
>> +   $(call if_changed,objcopy)

U... How is arm64 injecting those extra flags? OBJCOPYFLAGS is
being set with := here?

In related news I need to figure out how to get my cross-compiler
builds more well scripted...

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [PATCH v10 1/7] regulator: fixed: add support for ACPI interface

[Greg Kroah-Hartman]

On Wed, Jun 08, 2016 at 02:43:27PM +0100, Mark Brown wrote:
> On Tue, Jun 07, 2016 at 09:42:48PM -0700, Greg Kroah-Hartman wrote:
> > On Thu, Jun 02, 2016 at 09:37:23AM +0800, Lu Baolu wrote:
> 
> > > Add support to retrieve fixed voltage configure information through
> > > ACPI interface. This is needed for Intel Bay Trail devices, where a
> > > GPIO is used to control the USB vbus.
> 
> > Can't do anything with this until I get an ack from the "owners" of this
> > file.
> 
> Please allow a reasonable time for review, it's been under a week since
> this was posted.  I would *not* expect this to be applied to another
> tree, please don't do that.

I wouldn't consider it, my response was to the developer of the patch,
sorry for the confusion,

greg k-h

Re: [PATCH] Add .set_antenna callback in ath6kl driver to remove wireless core warns

[Prasun Maiti]

Please tell me if I mention that this code is untested in commit log,
then could you check the code kindly and also help me to fix this type
of warning?

On Wed, Jun 8, 2016 at 9:00 PM, Valo, Kalle  wrote:
> Prasun Maiti  writes:
>
>> I am not sure it works fine. Like ath6kl driver send another cmd to
>> firmare, I have just filled up the cmd buffer with "tx_ant", and
>> "rx_ant" values, then use "ath6kl_wmi_cmd_send()" api to send the cmd
>> buffer to firmware. I have resend the patch as there are some errors
>> in the previous patch. Let me know if any modifications are needed?
>
> I don't take untested code. In some special cases it might be ok to send
> untested code but even then it needs to be clearly stated in the commit
> log that it's untested.
>
> Please resend once you have tested this, I'm dropping this now.
>
> --
> Kalle Valo



-- 
Thanks,
Prasun

Re: [PATCH] ARM: Keystone: Introduce Kconfig option to compile in typical Keystone features

[Arnd Bergmann]

On Wednesday, June 8, 2016 2:47:48 AM CEST Tony Lindgren wrote:
> 
> * Arnd Bergmann  [160607 01:11]:
> > A lot of these options are typical for all ARMv7 machines: AEABI, I2C, NEON,
> > PM, REGULATOR and VFP are things that we probably want to default to enabled
> > whenever we build a MULTI_V7 kernel, some also for V5 or V6, we just
> > need to come up with a good way to do that while (probably for most of
> > them) still allowing them to be disabled with CONFIG_EXPERT. I would
> > feel more comfortable with having an ARCH_MULTIPLATFORM_TYPICAL
> > Kconfig symbol than with the ARCH_OMAP2PLUS_TYPICAL one that ends up
> > turning things on unconditionally whenever you add ARCH_OMAP2PLUS
> > to some other configuration.
> 
> We still need to be careful about not changing the Kconfig option
> name for something like this as it will cause the custom .config files
> to fail unless the default is y. But yeah I agree, it would be nice
> to have some multiarch sane default selects, then also do the platform
> specific selects as needed. Naturally this needs to be kept down to
> minimum ideally limited to silent options.
> 
> So we could have ARCH_MULTIPLATFORM_TYPICAL, then have the old
> ARCH_OMAP2PLUS_TYPICAL select that one. That should keep things
> behaving just fine if the old .config had ARCH_OMAP2PLUS_TYPICAL.

If we make ARCH_MULTIPLATFORM_TYPICAL 'default y', it will be always
enabled in this case, and I think we can drop ARCH_OMAP2PLUS_TYPICAL.

The downside would be any users that want the options we enable there
turned off and have them silently enabled when upgrading the kernel.

> > For I2C_OMAP, MENELAUS and TWL4030, we could just add a
> > 'default ARCH_OMAP3 || ARCH_OMAP4' or whatever is appropriate for
> > each of them. I assume we want to handle TWL6040 the same way, though
> > we currently don't do that. MENELAUS seems to be only needed for
> > omap2420-n8x0.
> 
> We could yeah. TWL4030 is omap2430 to omap3, I don't think we currently
> have any omap3 based ones not using twl4030.. But there certainly
> are tons of usable devices with the Motorola CPCAP PMIC instead.

So should we enable both then?

> Then REGULATOR_FIXED_VOLTAGE we can have platform select like Mark
> seems to prefer. 

Ok

> HIGHMEM too should be platform specific.

I still don't see a good way to handle that, we should certainly not
just 'select' it, because we often want to leave it disabled.

> The original reason for ARCH_OMAP2PLUS_TYPICAL was that if omap2plus
> is selected with that you actually get a bootable system.

I understand. It's just not very scalable to have every platform do
this, in particular if they want to select conflicting options (none
of the ones you select should conflict, but we'd get there eventually).

Arnd

Re: [PATCH 05/10] mm: remove LRU balancing effect of temporary page isolation

[Johannes Weiner]

On Wed, Jun 08, 2016 at 04:39:44PM +0900, Minchan Kim wrote:
> On Mon, Jun 06, 2016 at 03:48:31PM -0400, Johannes Weiner wrote:
> > @@ -832,9 +854,9 @@ static void __pagevec_lru_add_fn(struct page *page, 
> > struct lruvec *lruvec,
> >   * Add the passed pages to the LRU, then drop the caller's refcount
> >   * on them.  Reinitialises the caller's pagevec.
> >   */
> > -void __pagevec_lru_add(struct pagevec *pvec)
> > +void __pagevec_lru_add(struct pagevec *pvec, bool new)
> >  {
> > -   pagevec_lru_move_fn(pvec, __pagevec_lru_add_fn, NULL);
> > +   pagevec_lru_move_fn(pvec, __pagevec_lru_add_fn, (void *)new);
> >  }
> 
> Just trivial:
> 
> 'new' argument would be not clear in this context what does it mean
> so worth to comment it, IMO but no strong opinion.

True, it's a little mysterious. I'll document it.

> Other than that,
> 
> Acked-by: Minchan Kim 

Thanks!

Re: [PATCH 0/2] qcom: add l2 cache perf events driver

[Mark Rutland]

On Wed, Jun 08, 2016 at 11:21:16AM -0400, Neil Leeder wrote:
> 
> 
> On 6/6/2016 05:04 AM, Mark Rutland wrote:
> > On Fri, Jun 03, 2016 at 05:03:30PM -0400, Neil Leeder wrote:
> >> This adds a new dynamic PMU to the Perf Events framework to program
> >> and control the L2 cache PMUs in some Qualcomm Technologies SOCs.
> >>
> >> The driver exports formatting and event information to sysfs so it can
> >> be used by the perf user space tools with the syntax:
> >> perf stat -e l2cache/event=0x42/
> >>
> >> One point to note is that there are certain combinations of events
> >> which are invalid, and which are detected in event_add().
> > 
> > Which combinations of events are invalid?
> > 
> > Please elaborate.
> > 
> >> Simply having event_add() fail would result in event_sched_in() making
> >> it Inactive, treating it as over-allocation of counters, leading to
> >> repeated attempts to allocate the events and ending up with a
> >> statistical count.  A solution for this situation is to turn the
> >> conflicting event off in event_add(). This allows a single error
> >> message to be generated, and no recurring attempts to re-add the
> >> invalid event. In order for this to work, event_sched_in()
> >> needs to detect that event_add() changed the state, and not override it
> >> and force it to Inactive.
> > 
> > For heterogeneous PMUs, we added the pmu::filter_match(event) callback
> > for a similar purpose: preventing an event from being scheduled on a
> > core which does not support that event, while allowing other events to
> > be scheduled.
> > 
> > So if you truly need to filter events, the infrastructure for doing so
> > already exists.
> > 
> > However, you will need to elaborate on "there are certain combinations
> > of events which are invalid".
> > 
> 
> Qualcomm PMUs have events arranged in a matrix of rows and columns.
> Only one event can be enabled from each column at once. So this isn't a
> heterogeneous CPU issue, and it doesn't seem to fit into filter_match()
> because it is not an absolute restriction that this event can't be
> enabled on this cpu, it's related to the other events which have 
> already been enabled.

The above is useful context. Please add (something like) it to the cover
and relevant patches in future postings!

Ok. So if I understand correctly, each counter can only count certain
events (and therefore each event can only go into some counters), rather
than all counters being identical?

So the issue is that there is no _suitable_ counter available for an
event, but there are still counters available for events in general.

This case is somewhat different to the heterogeneous PMU case.

Unfortunately, trying to filter events in this manner can be very
expensive, and allows a malicious user to DoS the system, as Peter
pointed out when I tried to do similar things in this area. Take a look
at [1] and associated replies.

If you can test the availability of a relevant counter very cheaply,
then having a specific return code for the case of no relevant counter
may be more palatable.

> >> This patchset requires:
> >> [PATCH] soc: qcom: provide mechanism for drivers to access L2 registers
> > 
> > A link would be remarkably helpful.
> 
> http://archive.arm.linux.org.uk/lurker/message/20160603.205900.1970f20d.en.html
> 
> > 
> > Better would be to fold that patch into this series, as it's the only
> > user, and both are helpful review context for the other.
> > 
> 
> The L2 PMU driver is the first user of the L2-accessors patch
> but it won't be the only one, which is why I kept it separate.

If other users aren't going to appear in the same merge window, IMO it
would be better to place them in the same series for now. Otherwise,
please have a link in the cover in future postings.

Thanks,
Mark.

[1] 
http://lkml.kernel.org/r/1392054264-23570-5-git-send-email-mark.rutl...@arm.com

[PATCH v2 00/13] regulator: pwm: various improvements

[Boris Brezillon]

Hello,

This patch series series aims at adding two important features to the
pwm-regulator driver.

The first one is the support for 'smooth handover' between the
bootloader and the kernel. This is mainly solving problems we have when
the PWM is controlling a critical regulator (like the one powering the
DDR chip). Currently, when the PWM regulator acquire the PWM device it
assumes it was off and it's safe to change the configuration before
enabling it, which can generate glitches on the PWM signal which in turn
generated glitches on the output voltage.
To solve that we've introduced support for hardware readout to the
PWM framework, so that the PWM regulator driver can adjust the PWM
a probe time and avoid glitches.
Atomic update is also helping in this regard.

Patch 1 is adding convenient helpers (at the PWM level) that will be
used by the PWM regulator driver.
Patches 2 to 7 are preparing everything on the PWM driver side to make
hardware readout available to all platforms using the PWM regulator
driver (rockchip and sti).
Patches 8 to 11 are making use of the atomic update and hardware readout
features to implement this smooth handover.

The second feature we add to the driver is the capability of using
a sub duty_cycle range in continuous mode. By default the regulator
is assuming that min_uV is achieved with a 0% dutycyle and max_uV
with a 100% dutycycle, but this is not necessarily true.
Moreover, in some cases (when the PWM device does not support
polarity inversion), we might have min_uV at 100% and max_uV at 0%.
Hence the addition of new properties to the existing DT bindings.
The feature is added in patch 12 and 13.

Best Regards,

Boris

Changes since v1:
- dropped already applied patches
- added R-b/A-b/T-b tags
- s/readl/readl_relaxed/ in patch 3 (as suggested by Brian)
- fixed pwm-regulator DT binding doc
- added some comments in the code
- replaced pwm_get_state() + if (state.enabled) by if (pwm_is_enabled())

Boris Brezillon (13):
  pwm: Add new helpers to create/manipulate PWM states
  pwm: rockchip: Fix period and duty_cycle approximation
  pwm: rockchip: Add support for hardware readout
  pwm: rockchip: Avoid glitches on already running PWMs
  pwm: rockchip: Add support for atomic update
  pwm: sti: Add support for hardware readout
  pwm: sti: Avoid glitches on already running PWMs
  regulator: pwm: Adjust PWM config at probe time
  regulator: pwm: Switch to the atomic PWM API
  regulator: pwm: Properly initialize the ->state field
  regulator: pwm: Retrieve correct voltage
  regulator: pwm: Support extra continuous mode cases
  regulator: pwm: Document pwm-dutycycle-unit and pwm-dutycycle-range

 .../bindings/regulator/pwm-regulator.txt   |  19 +++
 drivers/pwm/pwm-rockchip.c | 178 +++--
 drivers/pwm/pwm-sti.c  |  52 +-
 drivers/regulator/pwm-regulator.c  | 162 ++-
 include/linux/pwm.h|  81 ++
 5 files changed, 401 insertions(+), 91 deletions(-)

-- 
2.7.4

[PATCH v6 00/11] powerpc/powernv/cpuidle: Add support for POWER ISA v3 idle states

[Shreyas B. Prabhu]

POWER ISA v3 defines a new idle processor core mechanism. In summary,
 a) new instruction named stop is added. This instruction replaces
instructions like nap, sleep, rvwinkle.
 b) new per thread SPR named PSSCR is added which controls the behavior
of stop instruction. 

PSSCR has following key fields
Bits 0:3  - Power-Saving Level Status. This field indicates the
lowest power-saving state the thread entered since stop
instruction was last executed.

Bit 42 - Enable State Loss  
0 - No state is lost irrespective of other fields  
1 - Allows state loss

Bits 44:47 - Power-Saving Level Limit  
This limits the power-saving level that can be entered into.

Bits 60:63 - Requested Level  
Used to specify which power-saving level must be entered on
executing stop instruction

Stop idle states and their properties like name, latency, target
residency, psscr value are exposed via device tree.

This patch series adds support for this new mechanism.

Patches 1-7 are cleanups and code movement.
Patch 8 adds platform specific support for stop and psscr handling.
Patch 9 is a minor cleanup in cpuidle driver.
Patch 10 adds cpuidle driver support.
Patch 11 makes offlined cpu use deepest stop state.

Note: Documentation for the device tree bindings is posted here-
http://patchwork.ozlabs.org/patch/629125/


Changes in v6
=
 - Restore new POWER ISA v3 SPRS when waking up from deep idle

Changes in v5
=
 - Use generic cpuidle constant CPUIDLE_NAME_LEN
 - Fix return code handling for of_property_read_string_array
 - Use DT flags to determine if are using stop instruction, instead of
   cpu_has_feature
 - Removed uncessary cast with names
 - _loop -> stop_loop
 - Added POWERNV_THRESHOLD_LATENCY_NS to filter out idle states with high 
latency

Changes in v4
=
 - Added a patch to use PNV_THREAD_WINKLE macro while requesting for winkle
 - Moved power7_powersave_common rename to more appropriate patch
 - renaming power7_enter_nap_mode to pnv_enter_arch207_idle_mode
 - Added PSSCR layout to Patch 7's commit message
 - Improved / Fixed comments
 - Fixed whitespace error in paca.h
 - Using MAX_POSSIBLE_STOP_STATE macro instead of hardcoding 0xF has
   max possible stop state

Changes in v3
=
 - Rebased on powerpc-next
 - Dropping patch 1 since we are not adding a new file for P9 idle support
 - Improved comments in multiple places
 - Moved GET_PACA from power7_restore_hyp_resource to System Reset
 - Instead of moving few functions from idle_power7 to idle_power_common,
   renaming idle_power7.S to idle_power_common.S
 - Moved HSTATE_HWTHREAD_STATE updation to power_powersave_common
 - Dropped earlier patch 5 which moved few macros from idle_power_common to
   asm/cpuidle.h. 
 - Added a patch to rename reusable power7_* idle functions to pnv_*
 - Added new patch that creates abstraction for saving SPRs before
   entering deep idle states
 - Instead of introducing new file idle_power_stop.S, P9 idle support
   is added to idle_power_common.S using CPU_FTR sections.
 - Fixed r4 reg clobbering in power_stop0

Changes in v2
=
 - Rebased on v4.6-rc6
 - Using CPU_FTR_ARCH_300 bit instead of CPU_FTR_STOP_INST

Cc: Rafael J. Wysocki 
Cc: Daniel Lezcano 
Cc: linux...@vger.kernel.org
Cc: Benjamin Herrenschmidt 
Cc: Michael Ellerman 
Cc: Paul Mackerras 
Cc: Michael Neuling 
Cc: linuxppc-...@lists.ozlabs.org
Cc: Rob Herring 
Cc: Lorenzo Pieralisi 

Shreyas B. Prabhu (11):
  powerpc/powernv: Use PNV_THREAD_WINKLE macro while requesting for
winkle
  powerpc/kvm: make hypervisor state restore a function
  powerpc/powernv: Rename idle_power7.S to idle_power_common.S
  powerpc/powernv: Rename reusable idle functions to hardware agnostic
names
  powerpc/powernv: Make pnv_powersave_common more generic
  powerpc/powernv: abstraction for saving SPRs before entering deep idle
states
  powerpc/powernv: set power_save func after the idle states are
initialized
  powerpc/powernv: Add platform support for stop instruction
  cpuidle/powernv: Use CPUIDLE_STATE_MAX instead of
MAX_POWERNV_IDLE_STATES
  cpuidle/powernv: Add support for POWER ISA v3 idle states
  powerpc/powernv: Use deepest stop state when cpu is offlined

 arch/powerpc/include/asm/cpuidle.h|   2 +
 arch/powerpc/include/asm/kvm_book3s_asm.h |   2 +-
 arch/powerpc/include/asm/machdep.h|   1 +
 arch/powerpc/include/asm/opal-api.h   |  11 +-
 arch/powerpc/include/asm/paca.h   |   2 +
 arch/powerpc/include/asm/ppc-opcode.h |   4 +
 arch/powerpc/include/asm/processor.h  |   1 +
 

Re: [PATCH] kernel/sysrq: reset watchdog on all CPUs while processing sysrq-w

[Andrey Ryabinin]

On 06/08/2016 04:13 PM, Ingo Molnar wrote:
> 
> * Andrey Ryabinin  wrote:
> 
>> Lengthy output of sysrq-w may take a lot of time on slow serial console.
>> Currently we reset NMI-watchdog on the current CPU to avoid softlockup.
>> Sometimes this doesn't work since watchdog might trigger on the other
>> CPU which is waiting for an IPI to proceed.
>>
>> Reset watchdog on all CPUs to prevent spurious softlockup messages.
>>
>> Signed-off-by: Andrey Ryabinin 
>> ---
>>  kernel/sched/core.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index 7f2cae4..c135eee 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -5134,7 +5134,7 @@ void show_state_filter(unsigned long state_filter)
>>   * reset the NMI-timeout, listing all files on a slow
>>   * console might take a lot of time:
>>   */
>> -touch_nmi_watchdog();
>> +touch_all_softlockup_watchdogs();
> 
> So don't we want both?
> 

Indeed, we need both.
I was under the false impression that touch_all_softlockup_watchdogs() will 
reset NMI timeout too

> Thanks,
> 
>   Ingo
> 

Re: [PATCH v3 04/30] staging: unisys: visorbus: remove unused module parameters

[Neil Horman]

On Wed, Jun 08, 2016 at 02:42:08PM +, Binder, David Anthony wrote:
> > -Original Message-
> > From: Neil Horman [mailto:nhor...@redhat.com]
> > Sent: Wednesday, June 08, 2016 9:08 AM
> > To: Binder, David Anthony 
> > Cc: Kershner, David A ; cor...@lwn.net;
> > t...@linutronix.de; mi...@redhat.com; h...@zytor.com;
> > gre...@linuxfoundation.org; Arfvidson, Erik ;
> > Sell, Timothy C ; hof...@osadl.org;
> > dzic...@redhat.com; jes.soren...@redhat.com; Curtin, Alexander Paul
> > ; janani.rvchn...@gmail.com;
> > sudipm.mukher...@gmail.com; pra...@redhat.com;
> > dan.j.willi...@intel.com; linux-kernel@vger.kernel.org; linux-
> > d...@vger.kernel.org; driverdev-de...@linuxdriverproject.org; *S-Par-
> > Maintainer 
> > Subject: Re: [PATCH v3 04/30] staging: unisys: visorbus: remove unused
> > module parameters
> > 
> > On Wed, Jun 08, 2016 at 02:13:47AM +, Binder, David Anthony wrote:
> > > > -Original Message-
> > > > From: Neil Horman [mailto:nhor...@redhat.com]
> > > > Sent: Tuesday, June 07, 2016 9:23 AM
> > > > To: Kershner, David A 
> > > > Cc: cor...@lwn.net; t...@linutronix.de; mi...@redhat.com;
> > > > h...@zytor.com; gre...@linuxfoundation.org; Arfvidson, Erik
> > > > ; Sell, Timothy C
> > ;
> > > > hof...@osadl.org; dzic...@redhat.com; jes.soren...@redhat.com;
> > Curtin,
> > > > Alexander Paul ;
> > > > janani.rvchn...@gmail.com; sudipm.mukher...@gmail.com;
> > > > pra...@redhat.com; Binder, David Anthony ;
> > > > dan.j.willi...@intel.com; linux-kernel@vger.kernel.org; linux-
> > > > d...@vger.kernel.org; driverdev-de...@linuxdriverproject.org; *S-Par-
> > > > Maintainer 
> > > > Subject: Re: [PATCH v3 04/30] staging: unisys: visorbus: remove unused
> > > > module parameters
> > > >
> > > > On Sat, Jun 04, 2016 at 01:27:04PM -0400, David Kershner wrote:
> > > > > From: David Binder 
> > > > >
> > > > > Removes unused module parameters from visorbus_main.c, in
> > response to
> > > > > findings by SonarQube.
> > > > >
> > > > > Signed-off-by: David Binder 
> > > > > Signed-off-by: David Kershner 
> > > > > Reviewed-by: Tim Sell 
> > > > > ---
> > > > >  drivers/staging/unisys/visorbus/visorbus_main.c | 9 +
> > > > >  1 file changed, 1 insertion(+), 8 deletions(-)
> > > > >
> > > > > diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c
> > > > b/drivers/staging/unisys/visorbus/visorbus_main.c
> > > > > index 2ed9628..71bff07 100644
> > > > > --- a/drivers/staging/unisys/visorbus/visorbus_main.c
> > > > > +++ b/drivers/staging/unisys/visorbus/visorbus_main.c
> > > > > @@ -27,10 +27,9 @@
> > > > >  #define MYDRVNAME "visorbus"
> > > > >
> > > > >  /* module parameters */
> > > > > -static int visorbus_debug;
> > > > >  static int visorbus_forcematch;
> > > > >  static int visorbus_forcenomatch;
> > > > > -static int visorbus_debugref;
> > > > > +
> > > > >  #define SERIALLOOPBACKCHANADDR (100 * 1024 * 1024)
> > > > >
> > > > >  /* Display string that is guaranteed to be no longer the 99 
> > > > > characters*/
> > > > > @@ -1332,9 +1331,6 @@ visorbus_exit(void)
> > > > >   remove_bus_type();
> > > > >  }
> > > > >
> > > > > -module_param_named(debug, visorbus_debug, int, S_IRUGO);
> > > > > -MODULE_PARM_DESC(visorbus_debug, "1 to debug");
> > > > > -
> > > > >  module_param_named(forcematch, visorbus_forcematch, int,
> > S_IRUGO);
> > > > >  MODULE_PARM_DESC(visorbus_forcematch,
> > > > >"1 to force a successful dev <--> drv match");
> > > > > @@ -1342,6 +1338,3 @@ MODULE_PARM_DESC(visorbus_forcematch,
> > > > >  module_param_named(forcenomatch, visorbus_forcenomatch, int,
> > > > S_IRUGO);
> > > > >  MODULE_PARM_DESC(visorbus_forcenomatch,
> > > > >"1 to force an UNsuccessful dev <--> drv match");
> > > > > -
> > > > > -module_param_named(debugref, visorbus_debugref, int, S_IRUGO);
> > > > > -MODULE_PARM_DESC(visorbus_debugref, "1 to debug reference
> > > > counting");
> > > >
> > > > visorbus_forcematch and visorbus_forcenomatch appear to be
> > referenced in
> > > > visorbus_match (at least in the HEAD of linus' tree).  If you're going 
> > > > to
> > > > remove
> > > > the module parameters, why not also remove those references and the
> > > > force[no]match variables themselves?
> > > >
> > > > Neil
> > >
> > > We presently use visorbus_forcematch and visorbus_forcenomatch for
> > > debugging purposes, and therefore decided to keep the variables in
> > > the driver.
> > >
> > Ok, thats fine, but this seems like a half measure then.  This patch removes
> > the
> > module option for those features, which means 

Re: [PATCH 1/1] mm/swap.c: flush lru_add pvecs on compound page arrival

[Michal Hocko]

On Wed 08-06-16 16:35:37, Lukasz Odzioba wrote:
> When the application does not exit cleanly (i.e. SIGTERM) we might

I do not see how a SIGTERM would make any difference. But see below.

> end up with some pages in lru_add_pvec, which is ok. With THP
> enabled huge pages may also end up on per cpu lru_add_pvecs.
> In the systems with a lot of processors we end up with quite a lot
> of memory pending for addition to LRU cache - in the worst case
> scenario up to CPUS * PAGE_SIZE * PAGEVEC_SIZE, which on machine
> with 200+CPUs means GBs in practice.

It is 56kB per CPU for normal pages which is not really that bad.
28MB for THP only cache is a lot though.

> We are able to reproduce this problem with the following program:
> 
> void main() {
> {
>   size_t size = 55 * 1000 * 1000; // smaller than  MEM/CPUS
>   void *p = mmap(NULL, size, PROT_READ | PROT_WRITE,
>   MAP_PRIVATE | MAP_ANONYMOUS , -1, 0);
>   if (p != MAP_FAILED)
>   memset(p, 0, size);
>   //munmap(p, size); // uncomment to make the problem go away

Is this really true? Both munmap and exit_mmap do the same
lru_add_drain() which flushes only the local CPU cache so munmap
shouldn't make any difference.

> }
> 
> When we run it it will leave significant amount of memory on pvecs.
> This memory will be not reclaimed if we hit OOM, so when we run
> above program in a loop:
>   $ for i in `seq 100`; do ./a.out; done
> many processes (95% in my case) will be killed by OOM.
> 
> This patch flushes lru_add_pvecs on compound page arrival making
> the problem less severe - kill rate drops to 0%.

I believe this deserves a more explanation. What do you think about the
following.
"
The primary point of the LRU add cache is to save the zone lru_lock
contention with a hope that more pages will belong to the same zone
and so their addition can be batched. The huge page is already a
form of batched addition (it will add 512 worth of memory in one go)
so skipping the batching seems like a safer option when compared to a
potential excess in the caching which can be quite large and much
harder to fix because lru_add_drain_all is way to expensive and
it is not really clear what would be a good moment to call it.
"

Does this sound better?

> 
> Suggested-by: Michal Hocko 
> Tested-by: Lukasz Odzioba 
> Signed-off-by: Lukasz Odzioba 
> ---
>  mm/swap.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/mm/swap.c b/mm/swap.c
> index 9591614..3fe4f18 100644
> --- a/mm/swap.c
> +++ b/mm/swap.c
> @@ -391,9 +391,8 @@ static void __lru_cache_add(struct page *page)
>   struct pagevec *pvec = _cpu_var(lru_add_pvec);
>  
>   get_page(page);
> - if (!pagevec_space(pvec))
> + if (!pagevec_add(pvec, page) || PageCompound(page))
>   __pagevec_lru_add(pvec);
> - pagevec_add(pvec, page);
>   put_cpu_var(lru_add_pvec);
>  }
>  
> -- 
> 1.8.3.1
> 

-- 
Michal Hocko
SUSE Labs

Re: [PATCH] treewide: update my email address

[Joe Perches]

On Wed, 2016-06-08 at 12:56 +0200, Felix Fietkau wrote:
> My n...@openwrt.org address is no longer valid and bounces

Perhaps add an entry to .mailmap too.

[RESEND PATCH 2/3] mtd: nand: Support maximizing ECC when using software BCH

[Boris Brezillon]

Add support for ECC maximization when software BCH with
nand_ooblayout_lp_ops layout is used.
Other cases should be handled by the NAND controller driver.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/nand_base.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index d374129..ca4f53d 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -4224,6 +4224,7 @@ static int nand_set_ecc_soft_ops(struct mtd_info *mtd)
ecc->write_page_raw = nand_write_page_raw;
ecc->read_oob = nand_read_oob_std;
ecc->write_oob = nand_write_oob_std;
+
/*
* Board driver should supply ecc.size and ecc.strength
* values to select how many bits are correctable.
@@ -4246,6 +4247,25 @@ static int nand_set_ecc_soft_ops(struct mtd_info *mtd)
}
 
mtd_set_ooblayout(mtd, _ooblayout_lp_ops);
+
+   }
+
+   /*
+* We can only maximize ECC config when the default layout is
+* used, otherwise we don't know how many bytes can really be
+* used.
+*/
+   if (mtd->ooblayout == _ooblayout_lp_ops &&
+   ecc->options & NAND_ECC_MAXIMIZE) {
+   int steps, bytes;
+
+   /* Always prefer 1k blocks over 512bytes ones */
+   ecc->size = 1024;
+   steps = mtd->writesize / ecc->size;
+
+   /* Reserve 2 bytes for the BBM */
+   bytes = (mtd->oobsize - 2) / steps;
+   ecc->strength = bytes * 8 / fls(8 * ecc->size);
}
 
/* See nand_bch_init() for details. */
-- 
2.7.4

[PATCH] Add .set_antenna callback in ath6kl driver to fix wireless core warns

[Prasun Maiti]

Since add more warnings for inconsistent ops in cfg80211, the wireless
core warns if a driver implements a cfg80211 callback but doesn't
implements the inverse operation. The ath6kl driver implements a cfg80211
.get_antenna operation handler but doesn't have the inverse .set_antenna
callback. So, it makes warning.

To remove this warning, add .set_antenna callback in ath6kl driver and
also send a cmd to firmware with it's values.

Signed-off-by: Prasun Maiti 
---
 drivers/net/wireless/ath/ath6kl/cfg80211.c | 24 
 drivers/net/wireless/ath/ath6kl/wmi.c  | 18 ++
 drivers/net/wireless/ath/ath6kl/wmi.h  |  6 ++
 3 files changed, 48 insertions(+)

diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c 
b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index 4e11ba0..0d51228 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -3231,6 +3231,29 @@ static int ath6kl_mgmt_tx(struct wiphy *wiphy, struct 
wireless_dev *wdev,
wait, buf, len, no_cck);
 }
 
+static int ath6kl_set_antenna(struct wiphy *wiphy,
+   u32 tx_ant, u32 rx_ant)
+{
+   struct ath6kl *ar = wiphy_priv(wiphy);
+   struct ath6kl_vif *vif = NULL;
+
+   vif = ath6kl_vif_first(ar);
+   if (!vif)
+   return -EIO;
+
+   if (!ath6kl_cfg80211_ready(vif))
+   return -EIO;
+
+   if (!tx_ant || !rx_ant)
+   return -EINVAL;
+
+   ar->hw.tx_ant = tx_ant;
+   ar->hw.rx_ant = rx_ant;
+
+   return ath6kl_wmi_set_antenna(ar->wmi, vif->fw_vif_idx,
+   tx_ant, rx_ant);
+}
+
 static int ath6kl_get_antenna(struct wiphy *wiphy,
  u32 *tx_ant, u32 *rx_ant)
 {
@@ -3456,6 +3479,7 @@ static struct cfg80211_ops ath6kl_cfg80211_ops = {
.cancel_remain_on_channel = ath6kl_cancel_remain_on_channel,
.mgmt_tx = ath6kl_mgmt_tx,
.mgmt_frame_register = ath6kl_mgmt_frame_register,
+   .set_antenna = ath6kl_set_antenna,
.get_antenna = ath6kl_get_antenna,
.sched_scan_start = ath6kl_cfg80211_sscan_start,
.sched_scan_stop = ath6kl_cfg80211_sscan_stop,
diff --git a/drivers/net/wireless/ath/ath6kl/wmi.c 
b/drivers/net/wireless/ath/ath6kl/wmi.c
index 631c3a0..3a7b5e9 100644
--- a/drivers/net/wireless/ath/ath6kl/wmi.c
+++ b/drivers/net/wireless/ath/ath6kl/wmi.c
@@ -1605,6 +1605,24 @@ static int ath6kl_wmi_txe_notify_event_rx(struct wmi 
*wmi, u8 *datap, int len,
return 0;
 }
 
+int ath6kl_wmi_set_antenna(struct wmi *wmi, u8 idx,
+ u32 tx_ant, u32 rx_ant)
+{
+   struct sk_buff *skb;
+   struct wmi_set_antenna_cmd *cmd;
+
+   skb = ath6kl_wmi_get_new_buf(sizeof(*cmd));
+   if (!skb)
+   return -ENOMEM;
+
+   cmd = (struct wmi_set_antenna_cmd *) skb->data;
+   cmd->tx_ant = cpu_to_le32(tx_ant);
+   cmd->rx_ant = cpu_to_le32(rx_ant);
+
+   return ath6kl_wmi_cmd_send(wmi, idx, skb, WMI_SET_ANTENNA_CMDID,
+   NO_SYNC_WMIFLAG);
+}
+
 int ath6kl_wmi_set_txe_notify(struct wmi *wmi, u8 idx,
  u32 rate, u32 pkts, u32 intvl)
 {
diff --git a/drivers/net/wireless/ath/ath6kl/wmi.h 
b/drivers/net/wireless/ath/ath6kl/wmi.h
index 3af464a..f2e65b3 100644
--- a/drivers/net/wireless/ath/ath6kl/wmi.h
+++ b/drivers/net/wireless/ath/ath6kl/wmi.h
@@ -642,6 +642,7 @@ enum wmi_cmd_id {
WMI_SET_RECOVERY_TEST_PARAMETER_CMDID, /*0xf094*/
 
WMI_ENABLE_SCHED_SCAN_CMDID,
+   WMI_SET_ANTENNA_CMDID,
 };
 
 enum wmi_mgmt_frame_type {
@@ -2312,6 +2313,11 @@ struct wmi_ap_set_apsd_cmd {
u8 enable;
 } __packed;
 
+struct wmi_set_antenna_cmd {
+   __le32 tx_ant;
+   __le32 rx_ant;
+} __packed;
+
 enum wmi_ap_apsd_buffered_traffic_flags {
WMI_AP_APSD_NO_DELIVERY_FRAMES =  0x1,
 };
-- 
1.9.1

Re: [PATCH 2/2] soc: qcom: add l2 cache perf events driver

[Neil Leeder]

Mark,
Thank you for the detailed review.

On 6/6/2016 05:51 AM, Mark Rutland wrote:
> On Fri, Jun 03, 2016 at 05:03:32PM -0400, Neil Leeder wrote:
>> Adds perf events support for L2 cache PMU.
>>
>> The L2 cache PMU driver is named 'l2cache' and can be used
>> with perf events to profile L2 events such as cache hits
>> and misses.
>>
>> Signed-off-by: Neil Leeder 
>> ---
>>  drivers/soc/qcom/Kconfig   |  10 +
>>  drivers/soc/qcom/Makefile  |   1 +
>>  drivers/soc/qcom/perf_event_l2.c   | 917 
>> +
>>  include/linux/soc/qcom/perf_event_l2.h |  82 +++
>>  4 files changed, 1010 insertions(+)
>>  create mode 100644 drivers/soc/qcom/perf_event_l2.c
>>  create mode 100644 include/linux/soc/qcom/perf_event_l2.h
>>

[...]

>> +++ b/drivers/soc/qcom/perf_event_l2.c
>> @@ -0,0 +1,917 @@
>> +/* Copyright (c) 2015,2016 The Linux Foundation. All rights reserved.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 and
>> + * only version 2 as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +#define pr_fmt(fmt) "l2 perfevents: " fmt
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/*
>> + * The cache is made-up of one or more slices, each slice has its own PMU.
>> + * This structure represents one of the hardware PMUs.
>> + */
> 
> I take it each slice PMU is shared by several CPUs? i.e. there aren't
> per-cpu slice PMU counters.
> 

That is correct.

>> +struct hml2_pmu {
>> +struct list_head entry;
>> +struct perf_event *events[MAX_L2_CTRS];
>> +unsigned long used_mask[BITS_TO_LONGS(MAX_L2_EVENTS)];
> 
> What's the difference between MAX_L2_CTRS and MAX_L2_EVENTS?
> 
> I'm surprised that they are different. What precisely do either
> represent?
> 
> Surely you don't have different events per-slice? Why do you need the
> PMU pointers at the slice level?
> 

Qualcomm PMUs have events arranged in a matrix of rows (codes) and columns 
(groups).
Only one event can be enabled from each group at once.
The upper part of used_mask is used to keep a record of which group has been
used. This is the same mechanism used in armv7
(arch/arm/perf_event_v7.c:krait_event_to_bit()).
So used_mask contains both an indication for a physical counter in use, and also
for the group, which is why it's a different size from MAX_L2_CTRS.

I kept this because it's what's done in armv7. If there's an objection, I can
move the group used_mask to its own bitmap.

>> +unsigned int valid_cpus;
>> +int on_cpu;
>> +u8 cpu[MAX_CPUS_IN_CLUSTER];
> 
> These all look suspicious to me (potentially barring on_cpu)
> 
> Surely this is an uncore PMU? It represents a shared resource, with
> shared counters, so it should be.
> 
> If you need to encode a set of CPUs, use a cpumask.
> 

Agreed. I will use a cpumask.

>> +atomic64_t prev_count[MAX_L2_CTRS];
>> +spinlock_t pmu_lock;
>> +};
>> +
>> +/*
>> + * Aggregate PMU. Implements the core pmu functions and manages
>> + * the hardware PMUs.
>> + */
>> +struct l2cache_pmu {
>> +u32 num_pmus;
>> +struct list_head pmus;
>> +struct pmu pmu;
>> +int num_counters;
>> +};
>> +
>> +#define to_l2cache_pmu(p) (container_of(p, struct l2cache_pmu, pmu))
>> +
>> +static DEFINE_PER_CPU(struct hml2_pmu *, cpu_to_pmu);
>> +static struct l2cache_pmu l2cache_pmu = { 0 };
>> +static int num_cpus_in_cluster;
>> +
>> +static u32 l2_cycle_ctr_idx;
>> +static u32 l2_reset_mask;
>> +static u32 mpidr_affl1_shift;
> 
> Eww. Drivers really shouldn't be messing with the MPIDR. The precise
> values are bound to change between generations of SoCs leaving us with a
> mess.
> 
> The FW should tell us precisely which CPUs device are affine to.
> 

During partial goods processing firmware renumbers the CPUs.
The only association between the CPU numbers the kernel sees and the
physical CPUs & slices is through MPIDR. But see a comment below
where I think I can remove some of the MPIDR handling, including
this variable.

>> +static inline u32 idx_to_reg(u32 idx)
>> +{
>> +u32 bit;
>> +
>> +if (idx == l2_cycle_ctr_idx)
>> +bit = BIT(L2CYCLE_CTR_BIT);
>> +else
>> +bit = BIT(idx);
>> +return bit;
>> +}
> 
> Probably worth giving a _bit suffix on this function. That makes it less
> confusing when it's used later.
> 

OK.

> [...]
> 
>> +static inline void hml2_pmu__enable(void)
>> +{
>> +/* Ensure all programming commands are done before proceeding */
>> +wmb();
>> +

[PATCH] watchdog: drop redundant 'default n' option for WATCHDOG_SYSFS

[Vladimir Zapolskiy]

The option 'default n' and its absence are equal for kbuild,
which makes explicit 'default n' redundant.

Signed-off-by: Vladimir Zapolskiy 
---
 drivers/watchdog/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index b54f26c..8d38cb8 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -48,7 +48,6 @@ config WATCHDOG_NOWAYOUT
 
 config WATCHDOG_SYSFS
bool "Read different watchdog information through sysfs"
-   default n
help
  Say Y here if you want to enable watchdog device status read through
  sysfs attributes.
-- 
2.5.0

Re: [PATCH v5 00/18] Cleanup for populate default bus

[Rob Herring]

+Joerg, Will

On Wed, Jun 1, 2016 at 1:52 AM, Kefeng Wang  wrote:
> This cleanup patchset cantains two parts.
>
> Firstly, introduce a new way to populate the default bus, then, we can
> drop unnecessary calls from the arch code, and do the same thing for
> of_iommu_init() in [1].
>
> Secondly, use helper of_platform_default_populate() in linux/of_platform
> when possible, instead of calling of_platform_populate() with default
> match table, After that, it is possible for driver code build as a module,
> and no need to export of_default_bus_match_table anymore.
>
> This patchset is based on Linux 4.7-rc1, and only test in arm/arm64 qemu
> with defconfig.

This series doesn't apply for me as it appears you had "of: iommu:
make of_iommu_init() postcore_initcall_sync" in your tree. Either we
need to phase these out over 2 releases or someone needs to take them
all (or we leave the minor conflicts for Linus).

Rob

Re: [PATCH v2] udp reuseport: fix packet of same flow hashed to different socket

[Eric Dumazet]

On Wed, 2016-06-08 at 11:40 +0800, Su Xuemin wrote:
> From: "Su, Xuemin" 
> 
> There is a corner case in which udp packets belonging to a same
> flow are hashed to different socket when hslot->count changes from 10
> to 11:

> It's the same case for IPv6, and this patch also fixes that.
> 
> Signed-off-by: Su, Xuemin 
> ---
> The patch v1 does not fix the code in IPv6. Thank Eric Dumazet for
> pointing that.
> And I use this tree to generate this patch, hope it's correct:
>   git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> 

I am not convinced this is the right way to fix the issue.

Fact that you did not change udp4_lib_lookup2() is telling me something.


1) If host has 100 different IP, and 10 sockets bound to 0.0.0.0:53 
2) If we receive datagrams from SRCIP:srcport send to IP{1..100}:53
will all be hashed on same slot.

See the hash used in soreuseport logic as an equivalent of a 4-tuple
hash really, not a 3-tuple one.

I would try instead :

(Looks like we missed this when commit 1223c67c093 ("udp: fix for
unicast RX path optimization") was reviewed/merged.

diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 
d56c0559b477cb96ce78c9b9b7dacc3109594f3a..5847fe48f17d64bee32551e9dd42024a8e65fb10
 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -563,7 +563,7 @@ struct sock *__udp4_lib_lookup(struct net *net, __be32 
saddr,
goto begin;
 
result = udp4_lib_lookup2(net, saddr, sport,
- htonl(INADDR_ANY), hnum, dif,
+ daddr, hnum, dif,
  hslot2, slot2, skb);
}
return result;
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 
2da1896af93496cc58762c67b4cd4b4f42924901..501b5563234d0921eff9f1e50155db76f27b3837
 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -277,7 +277,7 @@ struct sock *__udp6_lib_lookup(struct net *net,
goto begin;
 
result = udp6_lib_lookup2(net, saddr, sport,
- _any, hnum, dif,
+ daddr, hnum, dif,
  hslot2, slot2, skb);
}
return result;

 

Re: [PATCH] arm64: mm: only initialize swiotlb when necessary

[Arnd Bergmann]

On Wednesday, June 8, 2016 1:08:29 PM CEST Catalin Marinas wrote:
> On Wed, Jun 08, 2016 at 03:53:46PM +0800, Jisheng Zhang wrote:
> >  static int __init arm64_dma_init(void)
> >  {
> > + if (swiotlb_force || max_pfn > (arm64_dma_phys_limit >> PAGE_SHIFT))
> > + swiotlb = 1;
> > +
> >   return atomic_pool_init();
> >  }
> 
> So any platform with RAM larger than 4GB would still initialise swiotlb.
> I wouldn't say it's an issue, 64MB is not a significant loss on such
> systems.
> 
> An alternative would be to defer the freeing until we are aware of all
> possible dma masks for the populated devices (e.g. from DT), though I'm
> not sure that's enough, drivers may try to change such masks when
> probed.

Right, this is a hard problem, because you can in theory have odd devices
that require a DMA mask lower than the limit of ZONE_DMA.

In the kernel sources, I find these:

# git grep DMA_BIT_MASK | grep -v 'DMA_BIT_MASK(\(3[2-9]\|[456][0-9]\))'
arch/arm/mach-ixp4xx/common.c:  dev->coherent_dma_mask = 
DMA_BIT_MASK(28); /* 64 MB */
drivers/base/isa.c: isa_dev->dev.coherent_dma_mask = 
DMA_BIT_MASK(24);
drivers/media/pci/sta2x11/sta2x11_vip.c:err = 
dma_set_coherent_mask(>pdev->dev, DMA_BIT_MASK(29));
drivers/media/pci/sta2x11/sta2x11_vip.c:if (dma_set_mask(>dev, 
DMA_BIT_MASK(26))) {
drivers/net/ethernet/broadcom/b44.c:mapping + RX_PKT_BUF_SZ > 
DMA_BIT_MASK(30)) {
drivers/net/ethernet/broadcom/b44.c:mapping + RX_PKT_BUF_SZ > 
DMA_BIT_MASK(30)) {
drivers/net/ethernet/broadcom/b44.c:if 
(dma_mapping_error(bp->sdev->dma_dev, mapping) || mapping + len > 
DMA_BIT_MASK(30)) {
drivers/net/ethernet/broadcom/b44.c:if 
(dma_mapping_error(bp->sdev->dma_dev, mapping) || mapping + len > 
DMA_BIT_MASK(30)) {
drivers/net/ethernet/broadcom/b44.c:rx_ring_dma + size > 
DMA_BIT_MASK(30)) {
drivers/net/ethernet/broadcom/b44.c:tx_ring_dma + size > 
DMA_BIT_MASK(30)) {
drivers/net/ethernet/broadcom/b44.c:if 
(dma_set_mask_and_coherent(sdev->dma_dev, DMA_BIT_MASK(30))) {
drivers/net/wan/wanxl.c:if (pci_set_consistent_dma_mask(pdev, 
DMA_BIT_MASK(28)) ||
drivers/net/wan/wanxl.c:pci_set_dma_mask(pdev, DMA_BIT_MASK(28))) {
drivers/net/wireless/broadcom/b43/dma.c:return DMA_BIT_MASK(30);
drivers/net/wireless/broadcom/b43/dma.c:if (dmamask == DMA_BIT_MASK(30))
drivers/net/wireless/broadcom/b43/dma.c:mask = 
DMA_BIT_MASK(30);
drivers/net/wireless/broadcom/b43legacy/dma.c:  return DMA_BIT_MASK(30);
drivers/net/wireless/broadcom/b43legacy/dma.c:  if (dmamask == DMA_BIT_MASK(30))
drivers/net/wireless/broadcom/b43legacy/dma.c:  mask = 
DMA_BIT_MASK(30);
drivers/parport/parport_pc.c:   ret = dma_coerce_mask_and_coherent(dev, 
DMA_BIT_MASK(24));
drivers/pnp/card.c: card->dev.coherent_dma_mask = DMA_BIT_MASK(24);
drivers/pnp/core.c: dev->dma_mask = DMA_BIT_MASK(24);
drivers/scsi/aacraid/commsup.c: if (((retval = 
pci_set_dma_mask(aac->pdev, DMA_BIT_MASK(31 ||
drivers/scsi/aacraid/commsup.c:   ((retval = 
pci_set_consistent_dma_mask(aac->pdev, DMA_BIT_MASK(31)
drivers/scsi/aacraid/linit.c:   dmamask = DMA_BIT_MASK(31);
drivers/usb/host/ehci-pci.c:
DMA_BIT_MASK(31)) < 0)
include/linux/blkdev.h:#define BLK_BOUNCE_ISA   (DMA_BIT_MASK(24))
sound/pci/ali5451/ali5451.c:if (dma_set_mask(>dev, DMA_BIT_MASK(31)) < 
0 ||
sound/pci/als300.c: if (dma_set_mask(>dev, DMA_BIT_MASK(28)) < 0 ||
sound/pci/als4000.c:if (dma_set_mask(>dev, DMA_BIT_MASK(24)) < 0 ||
sound/pci/azt3328.c:if (dma_set_mask(>dev, DMA_BIT_MASK(24)) < 0 ||
sound/pci/emu10k1/emu10k1x.c:   if (pci_set_dma_mask(pci, DMA_BIT_MASK(28)) < 0 
||
sound/pci/es1938.c: if (dma_set_mask(>dev, DMA_BIT_MASK(24)) < 0 ||
sound/pci/es1968.c: if (dma_set_mask(>dev, DMA_BIT_MASK(28)) < 0 ||
sound/pci/ice1712/ice1712.c:if (dma_set_mask(>dev, DMA_BIT_MASK(28)) < 
0 ||
sound/pci/maestro3.c:   if (dma_set_mask(>dev, DMA_BIT_MASK(28)) < 0 ||
sound/pci/sis7019.c:rc = dma_set_mask(>dev, DMA_BIT_MASK(30));
sound/pci/sonicvibes.c: if (dma_set_mask(>dev, DMA_BIT_MASK(24)) < 0 ||
sound/pci/trident/trident_main.c:   if (dma_set_mask(>dev, 
DMA_BIT_MASK(30)) < 0 ||
sound/pci/trident/trident_main.c:   dma_set_coherent_mask(>dev, 
DMA_BIT_MASK(30)) < 0) {
sound/soc/intel/common/sst-firmware.c:  err = dma_coerce_mask_and_coherent(dev, 
DMA_BIT_MASK(31));
sound/soc/intel/haswell/sst-haswell-dsp.c:  ret = 
dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(31));

Arnd

Re: [PATCH] staging: slicoss: replacement of goto statements

[Greg KH]

On Wed, Jun 08, 2016 at 08:46:06AM -0500, Jaime Arrocha wrote:
> From: Jaime Arrocha 
> 
> Replaced deprecated goto statements.

Since when is 'goto' deprecated?

Were you able to test these changes?

thanks,

greg k-h

Re: [PATCH 0/2] Proper ro_after_init implementation on s390

[Kees Cook]

On Tue, Jun 7, 2016 at 10:41 PM, Heiko Carstens
 wrote:
> On Tue, Jun 07, 2016 at 11:11:17AM -0700, Kees Cook wrote:
>> On Tue, Jun 7, 2016 at 11:07 AM, Heiko Carstens
>>  wrote:
>> > On Tue, Jun 07, 2016 at 08:49:14AM -0700, Kees Cook wrote:
>> >> > Heiko Carstens (2):
>> >> >   vmlinux.lds.h: allow arch specific handling of ro_after_init data 
>> >> > section
>> >> >   s390/mm: add proper __ro_after_init support
>> >> >
>> >> >  arch/s390/include/asm/cache.h |  3 ---
>> >> >  arch/s390/include/asm/sections.h  |  1 +
>> >> >  arch/s390/kernel/vmlinux.lds.S| 12 +++-
>> >> >  arch/s390/mm/init.c   |  7 ---
>> >> >  arch/s390/mm/vmem.c   |  7 +++
>> >> >  include/asm-generic/vmlinux.lds.h | 10 +-
>> >> >  6 files changed, 28 insertions(+), 12 deletions(-)
>> >>
>> >> Awesome! This looks great to me! Have you had a chance to look through
>> >> any of the arch/s390/ __init code for variables that should be marked
>> >> __ro_after_init?
>> >
>> > Not yet, and actually this I'm a bit reluctant to do that, since any wrong
>> > annotation will lead to kernel crashes sooner or later ;)
>> > However I'll look into this as well.
>>
>> Yup, though the good news is it's usually discovered very quickly. :)
>
> Eventually it might make sense to add something like
> DEBUG_SECTION_MISMATCH, which would only report on _write_ accesses from
> non-init sections.
>
> Not sure if this can be done easily and without the need of a new compiler
> feature. The new problem class I'm afraid of is more or less the same that
> we had when non-init code referenced (already freed) initdata objects.

Yeah. I'm hopeful we'll have a gcc plugin to help with this soon.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [PATCH 4/4] mfd: db8500 stop passing around platform data

[Arnd Bergmann]

On Wednesday, June 8, 2016 1:37:12 PM CEST Linus Walleij wrote:
> On Tue, May 10, 2016 at 4:02 PM, Arnd Bergmann  wrote:
> 
> > Except for the constant DB8500_PRCMU_FW_VERSION_OFFSET number, nothing
> > is ever passed through the platform data and used in a driver, so we
> > can simply stop passing it around.
> >
> > Signed-off-by: Arnd Bergmann 
> 
> Reviewed-by: Linus Walleij 
> 
> Do you think it's relevant for Lee to take this or do you want to
> have it in ARM SoC together with the other cleanups (that I
> haven't had time to look at...)?
> 
> In the latter case I need an ACK from Lee to apply it for a pull
> request to ARM SoC.
> 
> The functionality it pertains to is out-of-tree but if we want to
> reintroduce it, it should happen through DT anyway.

I think most of the changes are in mfd, so it would be appropriate
for Lee to take them all, but I could also put them into arm-soc
if he prefers.

Arnd

[PATCH] cifs: check hash calculating succeeded

[Luis de Bethencourt]

calc_lanman_hash() could return -ENOMEM or other errors, we should check
that everything went fine before using the calculated key.

Signed-off-by: Luis de Bethencourt 
---
 fs/cifs/sess.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/cifs/sess.c b/fs/cifs/sess.c
index a42e99c..538d9b5 100644
--- a/fs/cifs/sess.c
+++ b/fs/cifs/sess.c
@@ -710,6 +710,8 @@ sess_auth_lanman(struct sess_data *sess_data)
rc = calc_lanman_hash(ses->password, ses->server->cryptkey,
  ses->server->sec_mode & 
SECMODE_PW_ENCRYPT ?
  true : false, lnm_session_key);
+   if (rc)
+   goto out;
 
memcpy(bcc_ptr, (char *)lnm_session_key, CIFS_AUTH_RESP_SIZE);
bcc_ptr += CIFS_AUTH_RESP_SIZE;
-- 
2.5.1

Re: [PATCH RFC net-next] netvsc: get rid of completion timeouts

[Vitaly Kuznetsov]

Vitaly Kuznetsov  writes:

> I'm hitting 5 second timeout in rndis_filter_set_rss_param() while setting
> RSS parameters for the device. When this happens we end up returning
> -ETIMEDOUT from the function and rndis_filter_device_add() falls back to
> setting
>
>   net_device->max_chn = 1;
> net_device->num_chn = 1;
> net_device->num_sc_offered = 0;
>
> but after a moment the rndis request succeeds and subchannels start to
> appear. netvsc_sc_open() does unconditional nvscdev->num_sc_offered-- and
> it becomes U32_MAX-1. Consequent rndis_filter_device_remove() will hang
> while waiting for all U32_MAX-1 subchannels to appear and this is not
> going to happen.
>
> The immediate issue could be solved by adding num_sc_offered > 0 check to
> netvsc_sc_open() but we're getting out of sync with the host and it's not
> easy to adjust things later, e.g. in this particular case we'll be creating
> queues without a user request for it and races are expected. Same applies
> to other parts of the driver which have the same completion timeout.
>
> Following the trend in drivers/hv/* code I suggest we remove all these
> timeouts completely. As a guest we can always trust the host we're running
> on and if the host screws things up there is no easy way to recover anyway.
>
> Signed-off-by: Vitaly Kuznetsov 

Kbuild test robot reports an unused variable after the patch, I'll fix
this and resend together with a related fix so please don't apply this
RFC to net-next atm.

[skip]

-- 
  Vitaly

Re: [PATCH 3/5] lkdtm: add function for testing .rodata section

[Laura Abbott]

On 06/08/2016 08:46 AM, Kees Cook wrote:

On Tue, Jun 7, 2016 at 6:02 PM, Laura Abbott  wrote:

On 06/07/2016 02:57 PM, Kees Cook wrote:


This adds a function that lives in the .rodata section. The section
flags are corrected using objcopy since there is no way with gcc to
declare section flags in an architecture-agnostic way.



Permit me to be the bearer of bad architecture news once again. With
arm64 cross compiler (both Fedora 6.1.1 and Linaro 5.1)

  CC  drivers/misc/lkdtm_rodata.o
  OBJCOPY drivers/misc/lkdtm_rodata_objcopy.o
  LD  drivers/misc/lkdtm.o
drivers/misc/lkdtm_rodata_objcopy.o: file not recognized: File format not
recognized
scripts/Makefile.build:423: recipe for target 'drivers/misc/lkdtm.o' failed
make[2]: *** [drivers/misc/lkdtm.o] Error 1
scripts/Makefile.build:440: recipe for target 'drivers/misc' failed
make[1]: *** [drivers/misc] Error 2
Makefile:985: recipe for target 'drivers' failed
make: *** [drivers] Error 2


As far as I can tell this is because arm64 defines OBJCOPYFLAGS and they get
propagated to objcopy

aarch64-linux-gnu-objcopy -O binary -R .note -R .note.gnu.build-id -R
.comment
-S --set-section-flags .text=alloc,readonly
--rename-section .text=.rodata drivers/misc/lkdtm_rodata.o
drivers/misc/lkdtm_rodata_objcopy.o

vs x86

objcopy  --set-section-flags .text=alloc,readonly --rename-section
.text=.rodata
drivers/misc/lkdtm_rodata.o drivers/misc/lkdtm_rodata_objcopy.o


specifically it's the -O binary that seems to break things, the same failure
happens on x86 as well with the the same commands. It works if I clear out
the OBJCOPYFLAGS variable first but I don't think that's the correct way to
fix this.

Thanks,
Laura



Signed-off-by: Kees Cook 
---
 drivers/misc/Makefile   |  7 +++
 drivers/misc/lkdtm.h|  6 ++
 drivers/misc/lkdtm_core.c   | 24 +---
 drivers/misc/lkdtm_rodata.c | 10 ++
 4 files changed, 40 insertions(+), 7 deletions(-)
 create mode 100644 drivers/misc/lkdtm.h
 create mode 100644 drivers/misc/lkdtm_rodata.c

diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index c3cb6ad8cc37..b2d3d68dfa22 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -59,3 +59,10 @@ obj-$(CONFIG_CXL_BASE)   += cxl/
 obj-$(CONFIG_PANEL) += panel.o

 lkdtm-$(CONFIG_LKDTM)  += lkdtm_core.o
+lkdtm-$(CONFIG_LKDTM)  += lkdtm_rodata_objcopy.o
+
+OBJCOPYFLAGS_lkdtm_rodata_objcopy.o := \
+   --set-section-flags .text=alloc,readonly \
+   --rename-section .text=.rodata
+$(obj)/lkdtm_rodata_objcopy.o: $(obj)/lkdtm_rodata.o
+   $(call if_changed,objcopy)


U... How is arm64 injecting those extra flags? OBJCOPYFLAGS is
being set with := here?



Looks like intended behavior from scripts/Makefile.lib:

# Objcopy
# ---

quiet_cmd_objcopy = OBJCOPY $@
cmd_objcopy = $(OBJCOPY) $(OBJCOPYFLAGS) $(OBJCOPYFLAGS_$(@F)) $< $@

OBJCOPYFLAGS_$@ is separate from OBJCOPYFLAGS which makes sense for the
original intentions although not what we want here. Some Makefile
wizardry is probably needed.


In related news I need to figure out how to get my cross-compiler
builds more well scripted...

-Kees

[PATCH] md: use a mutex to protect a global list

[Cong Wang]

We saw a list corruption in the list all_detected_devices:

 WARNING: CPU: 16 PID: 226 at lib/list_debug.c:29 __list_add+0x3c/0xa9()
 list_add corruption. next->prev should be prev (880859d58320), but was 
880859ce74c0. (next=81abfdb0).
 Modules linked in: ahci libahci libata sd_mod scsi_mod
 CPU: 16 PID: 226 Comm: kworker/u241:4 Not tainted 4.1.20 #1
 Hardware name: Dell Inc. PowerEdge C6220/04GD66, BIOS 2.2.3 11/07/2013
 Workqueue: events_unbound async_run_entry_fn
   880859a5baf8 81502872 880859a5bb48
  0009 880859a5bb38 810692a5 880859ee8828
  812ad02c 880859d58320 81abfdb0 880859eb90c0
 Call Trace:
  [] dump_stack+0x4d/0x63
  [] warn_slowpath_common+0xa1/0xbb
  [] ? __list_add+0x3c/0xa9
  [] warn_slowpath_fmt+0x46/0x48
  [] __list_add+0x3c/0xa9
  [] md_autodetect_dev+0x41/0x62
  [] rescan_partitions+0x25f/0x29d
  [] ? mutex_lock+0x13/0x31
  [] __blkdev_get+0x1aa/0x3cd
  [] blkdev_get+0x5f/0x294
  [] ? put_device+0x17/0x19
  [] ? disk_put_part+0x12/0x14
  [] add_disk+0x29d/0x407
  [] ? __pm_runtime_use_autosuspend+0x5c/0x64
  [] sd_probe_async+0x115/0x1af [sd_mod]
  [] async_run_entry_fn+0x72/0x12c
  [] process_one_work+0x198/0x2ce
  [] worker_thread+0x1dd/0x2bb
  [] ? cancel_delayed_work_sync+0x15/0x15
  [] ? cancel_delayed_work_sync+0x15/0x15
  [] kthread+0xae/0xb6
  [] ? param_array_set+0x40/0xfa
  [] ? __kthread_parkme+0x61/0x61
  [] ret_from_fork+0x42/0x70
  [] ? __kthread_parkme+0x61/0x61

I suspect it is because there is no lock protecting this
global list, autostart_arrays() is called in ioctl() path
where there is no lock.

Cc: Shaohua Li 
Signed-off-by: Cong Wang 
---
 drivers/md/md.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/md/md.c b/drivers/md/md.c
index 866825f..f2f1912 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -8799,6 +8799,7 @@ EXPORT_SYMBOL(md_reload_sb);
  * at boot time.
  */
 
+static DEFINE_MUTEX(detected_devices_mutex);
 static LIST_HEAD(all_detected_devices);
 struct detected_devices_node {
struct list_head list;
@@ -8812,7 +8813,9 @@ void md_autodetect_dev(dev_t dev)
node_detected_dev = kzalloc(sizeof(*node_detected_dev), GFP_KERNEL);
if (node_detected_dev) {
node_detected_dev->dev = dev;
+   mutex_lock(_devices_mutex);
list_add_tail(_detected_dev->list, _detected_devices);
+   mutex_unlock(_devices_mutex);
} else {
printk(KERN_CRIT "md: md_autodetect_dev: kzalloc failed"
", skipping dev(%d,%d)\n", MAJOR(dev), MINOR(dev));
@@ -8831,6 +8834,7 @@ static void autostart_arrays(int part)
 
printk(KERN_INFO "md: Autodetecting RAID arrays.\n");
 
+   mutex_lock(_devices_mutex);
while (!list_empty(_detected_devices) && i_scanned < INT_MAX) {
i_scanned++;
node_detected_dev = list_entry(all_detected_devices.next,
@@ -8849,6 +8853,7 @@ static void autostart_arrays(int part)
list_add(>same_set, _raid_disks);
i_passed++;
}
+   mutex_unlock(_devices_mutex);
 
printk(KERN_INFO "md: Scanned %d and added %d devices.\n",
i_scanned, i_passed);
-- 
2.1.0

[PATCH v2 05/13] pwm: rockchip: Add support for atomic update

[Boris Brezillon]

Implement the ->apply() function to add support for atomic update.

Signed-off-by: Boris Brezillon 
Tested-by: Heiko Stuebner 
Reviewed-by: Brian Norris 
Tested-by: Brian Norris 
---
 drivers/pwm/pwm-rockchip.c | 84 --
 1 file changed, 43 insertions(+), 41 deletions(-)

diff --git a/drivers/pwm/pwm-rockchip.c b/drivers/pwm/pwm-rockchip.c
index dd8ca86..ef89df1 100644
--- a/drivers/pwm/pwm-rockchip.c
+++ b/drivers/pwm/pwm-rockchip.c
@@ -47,10 +47,12 @@ struct rockchip_pwm_regs {
 struct rockchip_pwm_data {
struct rockchip_pwm_regs regs;
unsigned int prescaler;
+   bool supports_polarity;
const struct pwm_ops *ops;
 
void (*set_enable)(struct pwm_chip *chip,
-  struct pwm_device *pwm, bool enable);
+  struct pwm_device *pwm, bool enable,
+  enum pwm_polarity polarity);
void (*get_state)(struct pwm_chip *chip, struct pwm_device *pwm,
  struct pwm_state *state);
 };
@@ -61,7 +63,8 @@ static inline struct rockchip_pwm_chip 
*to_rockchip_pwm_chip(struct pwm_chip *c)
 }
 
 static void rockchip_pwm_set_enable_v1(struct pwm_chip *chip,
-  struct pwm_device *pwm, bool enable)
+  struct pwm_device *pwm, bool enable,
+  enum pwm_polarity polarity)
 {
struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
u32 enable_conf = PWM_CTRL_OUTPUT_EN | PWM_CTRL_TIMER_EN;
@@ -91,14 +94,15 @@ static void rockchip_pwm_get_state_v1(struct pwm_chip *chip,
 }
 
 static void rockchip_pwm_set_enable_v2(struct pwm_chip *chip,
-  struct pwm_device *pwm, bool enable)
+  struct pwm_device *pwm, bool enable,
+  enum pwm_polarity polarity)
 {
struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
u32 enable_conf = PWM_OUTPUT_LEFT | PWM_LP_DISABLE | PWM_ENABLE |
  PWM_CONTINUOUS;
u32 val;
 
-   if (pwm_get_polarity(pwm) == PWM_POLARITY_INVERSED)
+   if (polarity == PWM_POLARITY_INVERSED)
enable_conf |= PWM_DUTY_NEGATIVE | PWM_INACTIVE_POSITIVE;
else
enable_conf |= PWM_DUTY_POSITIVE | PWM_INACTIVE_NEGATIVE;
@@ -166,7 +170,6 @@ static int rockchip_pwm_config(struct pwm_chip *chip, 
struct pwm_device *pwm,
struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
unsigned long period, duty;
u64 clk_rate, div;
-   int ret;
 
clk_rate = clk_get_rate(pc->clk);
 
@@ -182,69 +185,66 @@ static int rockchip_pwm_config(struct pwm_chip *chip, 
struct pwm_device *pwm,
div = clk_rate * duty_ns;
duty = DIV_ROUND_CLOSEST_ULL(div, pc->data->prescaler * NSEC_PER_SEC);
 
-   ret = clk_enable(pc->clk);
-   if (ret)
-   return ret;
-
writel(period, pc->base + pc->data->regs.period);
writel(duty, pc->base + pc->data->regs.duty);
-   writel(0, pc->base + pc->data->regs.cntr);
-
-   clk_disable(pc->clk);
-
-   return 0;
-}
-
-static int rockchip_pwm_set_polarity(struct pwm_chip *chip,
-struct pwm_device *pwm,
-enum pwm_polarity polarity)
-{
-   /*
-* No action needed here because pwm->polarity will be set by the core
-* and the core will only change polarity when the PWM is not enabled.
-* We'll handle things in set_enable().
-*/
 
return 0;
 }
 
-static int rockchip_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+static int rockchip_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ struct pwm_state *state)
 {
struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
+   struct pwm_state curstate;
+   bool enabled;
int ret;
 
+   pwm_get_state(pwm, );
+   enabled = curstate.enabled;
+
ret = clk_enable(pc->clk);
if (ret)
return ret;
 
-   pc->data->set_enable(chip, pwm, true);
+   if (state->polarity != curstate.polarity && enabled) {
+   pc->data->set_enable(chip, pwm, false, state->polarity);
+   enabled = false;
+   }
 
-   return 0;
-}
+   ret = rockchip_pwm_config(chip, pwm, state->duty_cycle, state->period);
+   if (ret) {
+   if (enabled != curstate.enabled)
+   pc->data->set_enable(chip, pwm, !enabled,
+state->polarity);
 
-static void rockchip_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
-{
-   struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
+   goto out;
+   

[PATCH v2 06/13] pwm: sti: Add support for hardware readout

[Boris Brezillon]

Implement ->get_state() to provide support for initial state retrieval.

Signed-off-by: Boris Brezillon 
---
 drivers/pwm/pwm-sti.c | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/drivers/pwm/pwm-sti.c b/drivers/pwm/pwm-sti.c
index 92abbd5..6300d3e 100644
--- a/drivers/pwm/pwm-sti.c
+++ b/drivers/pwm/pwm-sti.c
@@ -238,6 +238,43 @@ static void sti_pwm_disable(struct pwm_chip *chip, struct 
pwm_device *pwm)
mutex_unlock(>sti_pwm_lock);
 }
 
+static void sti_pwm_get_state(struct pwm_chip *chip,
+ struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+   struct sti_pwm_chip *pc = to_sti_pwmchip(chip);
+   unsigned int regval, prescaler;
+   int ret;
+
+   /* The clock has to be enabled to access PWM registers */
+   ret = clk_enable(pc->clk);
+   if (ret) {
+   dev_err(chip->dev, "Failed to enable PWM clk");
+   return;
+   }
+
+   regmap_field_read(pc->prescale_high, );
+   prescaler = regval << 4;
+   regmap_field_read(pc->prescale_low, );
+   prescaler |= regval;
+   state->period = DIV_ROUND_CLOSEST_ULL((u64)(prescaler + 1) *
+ NSEC_PER_SEC *
+ (pc->cdata->max_pwm_cnt + 1),
+ pc->clk_rate);
+
+   regmap_read(pc->regmap, STI_DS_REG(pwm->hwpwm), );
+   state->duty_cycle = DIV_ROUND_CLOSEST_ULL((u64)(regval + 1) *
+ state->period,
+ pc->cdata->max_pwm_cnt + 1);
+
+   regmap_field_read(pc->pwm_en, );
+   state->enabled = regval;
+
+   state->polarity = PWM_POLARITY_NORMAL;
+
+   clk_disable(pc->clk);
+}
+
 static void sti_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
 {
struct sti_pwm_chip *pc = to_sti_pwmchip(chip);
@@ -249,6 +286,7 @@ static const struct pwm_ops sti_pwm_ops = {
.config = sti_pwm_config,
.enable = sti_pwm_enable,
.disable = sti_pwm_disable,
+   .get_state = sti_pwm_get_state,
.free = sti_pwm_free,
.owner = THIS_MODULE,
 };
-- 
2.7.4

Re: [PATCH 1/8] ARM: dts: at91: animeo_ip: remove leftovers clock definition

[Nicolas Ferre]

Le 08/06/2016 18:41, Alexandre Belloni a écrit :
> The clocks group properties and the clock@0 node have been obsolete for two
> years, remove them.
> 
> Signed-off-by: Alexandre Belloni 

On the whole series:
Acked-by: Nicolas Ferre 

> ---
>  arch/arm/boot/dts/animeo_ip.dts | 9 -
>  1 file changed, 9 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/animeo_ip.dts b/arch/arm/boot/dts/animeo_ip.dts
> index 0962f2fa3f6e..419dd3981edf 100644
> --- a/arch/arm/boot/dts/animeo_ip.dts
> +++ b/arch/arm/boot/dts/animeo_ip.dts
> @@ -32,15 +32,6 @@
>   };
>  
>   clocks {
> - #address-cells = <1>;
> - #size-cells = <1>;
> - ranges;
> -
> - main_clock: clock@0 {
> - compatible = "atmel,osc", "fixed-clock";
> - clock-frequency = <18432000>;
> - };
> -
>   slow_xtal {
>   clock-frequency = <32768>;
>   };
> 


-- 
Nicolas Ferre

Re: [PATCH] hwmon: (tmp401) Add support for TI TMP461

[Andrew F. Davis]

On 06/03/2016 11:41 PM, Guenter Roeck wrote:
> On 05/31/2016 09:27 AM, Andrew F. Davis wrote:
>> Signed-off-by: Andrew F. Davis 
>> ---
>>   Documentation/hwmon/tmp401 | 18 +--
>>   drivers/hwmon/Kconfig  |  2 +-
>>   drivers/hwmon/tmp401.c | 81
>> ++
>>   3 files changed, 92 insertions(+), 9 deletions(-)
>>
>> diff --git a/Documentation/hwmon/tmp401 b/Documentation/hwmon/tmp401
>> index 711f75e..eaa2d3b 100644
>> --- a/Documentation/hwmon/tmp401
>> +++ b/Documentation/hwmon/tmp401
>> @@ -22,6 +22,9 @@ Supported chips:
>>   Prefix: 'tmp435'
>>   Addresses scanned: I2C 0x48 - 0x4f
>>   Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp435.html
>> +  * Texas Instruments TMP461
>> +Prefix: 'tmp461'
>> +Datasheet: http://www.ti.com/product/tmp461
>>
>>   Authors:
>>Hans de Goede 
>> @@ -31,8 +34,8 @@ Description
>>   ---
>>
>>   This driver implements support for Texas Instruments TMP401, TMP411,
>> -TMP431, TMP432 and TMP435 chips. These chips implement one or two remote
>> -and one local temperature sensors. Temperature is measured in degrees
>> +TMP431, TMP432, TMP435, and TMP461 chips. These chips implement one
>> or two
>> +remote and one local temperature sensors. Temperature is measured in
>> degrees
>>   Celsius. Resolution of the remote sensor is 0.0625 degree. Local
>>   sensor resolution can be set to 0.5, 0.25, 0.125 or 0.0625 degree (not
>>   supported by the driver so far, so using the default resolution of 0.5
>> @@ -55,3 +58,14 @@ some additional features.
>>
>>   TMP432 is compatible with TMP401 and TMP431. It supports two external
>>   temperature sensors.
>> +
>> +TMP461 is compatible with TMP401. It supports offset and n-factor
>> correction
>> +that is applied to the remote sensor.
>> +
>> +* Sensor offset values are temperature values
>> +
>> +  Exported via sysfs attribute tempX_offset
>> +
>> +* n-factor correction, values are in raw form as described in the
>> datasheet
>> +
> 
> If you don't mind, I would prefer if you would drop this attribute, at
> least
> for now, for a number of reasons. It should not really be controlled by
> a sysfs
> attribute, but either with devicetree data or platform data. Exposing a raw
> register value through sysfs isn't really desirable; sysfs is supposed
> to provide some kind of abstraction. It enables setting the n-factor,
> but not beta-compensation which is probably equally desirable.
> Last but not least, other chips supported by this driver, as well as
> other chips
> supported by hwmon, also support  n-factor correction and
> beta-compensation.
> If we provide this functionality we should provide it for all chips in a
> generic way. In short, this needs more discussion.
> 

Makes sense, will drop this attribute for now.

> Couple of additional additional comments below.
> 
> Thanks,
> Guenter
> 
> 
>> +  Exported via sysfs attribute tempX_nfactor
>> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
>> index ff94007..c571dcf 100644
>> --- a/drivers/hwmon/Kconfig
>> +++ b/drivers/hwmon/Kconfig
>> @@ -1561,7 +1561,7 @@ config SENSORS_TMP401
>>   depends on I2C
>>   help
>> If you say yes here you get support for Texas Instruments TMP401,
>> -  TMP411, TMP431, TMP432 and TMP435 temperature sensor chips.
>> +  TMP411, TMP431, TMP432, TMP435, and TMP461 temperature sensor
>> chips.
>>
>> This driver can also be built as a module.  If so, the module
>> will be called tmp401.
>> diff --git a/drivers/hwmon/tmp401.c b/drivers/hwmon/tmp401.c
>> index ccf4cff..280065b 100644
>> --- a/drivers/hwmon/tmp401.c
>> +++ b/drivers/hwmon/tmp401.c
>> @@ -47,7 +47,8 @@
>>   static const unsigned short normal_i2c[] = { 0x48, 0x49, 0x4a, 0x4c,
>> 0x4d,
>>   0x4e, 0x4f, I2C_CLIENT_END };
>>
>> -enum chips { tmp401, tmp411, tmp431, tmp432, tmp435 };
>> +enum chips { tmp401, tmp411, tmp431, tmp432, tmp435, tmp461 };
>> +
>>
> Please no double empty lines.
> 

ACK

>>   /*
>>* The TMP401 registers, note some registers have different
>> addresses for
>> @@ -62,31 +63,37 @@ enum chips { tmp401, tmp411, tmp431, tmp432,
>> tmp435 };
>>   #define TMP401_MANUFACTURER_ID_REG0xFE
>>   #define TMP401_DEVICE_ID_REG0xFF
>>
>> -static const u8 TMP401_TEMP_MSB_READ[6][2] = {
>> +static const u8 TMP401_TEMP_MSB_READ[8][2] = {
>>   { 0x00, 0x01 },/* temp */
>>   { 0x06, 0x08 },/* low limit */
>>   { 0x05, 0x07 },/* high limit */
>>   { 0x20, 0x19 },/* therm (crit) limit */
>>   { 0x30, 0x34 },/* lowest */
>>   { 0x32, 0x36 },/* highest */
>> +{ 0, 0x11 },/* offset */
>> +{ 0, 0x23 },/* nfactor */
>>   };
>>
>> -static const u8 TMP401_TEMP_MSB_WRITE[6][2] = {
>> +static const u8 TMP401_TEMP_MSB_WRITE[8][2] = {
>>   { 0, 0 },/* temp (unused) */
>>   { 0x0C, 0x0E },/* low limit */
>>   { 0x0B, 

Re: [PATCH] serial: earlycon: stop abusing console::index

[Peter Hurley]

On 06/03/2016 08:19 AM, Mark Rutland wrote:
> Commit cda64e6824026575 ("serial: earlycon: Fixup earlycon console name
> and index") added code to decompose an earlycon driver name into a
> string prefix and numeric suffix, and place this into console::name and
> console::index, such that we'd get a pretty name out of the core console
> code, which requires a name and index. This is simply to give a
> pretty/useful earlycon driver name in the log messages, and other than
> logging the name and index hold no significance.

The idea was to keep the console_cmdline[] array consistent with the
registered consoles, even though earlycon uses its own matching scheme.
Least surprise and all that.


> However, this is broken for drivers such as "pl011", where the "011"
> suffix gets stripped off, then subsequently restored, printed as a
> decimal, erroneously giving "pl11" in log messages.

Yeah, I saw that.

> Additionally, for
> earlycon drivers without a numeric suffix, "0" is added regardless. Thus
> the code is broken in some cases, and generally inconsistent.

I would like to continue with some kind of naming scheme that preserves
both the command line parameters (uart,uart8250,pl011,etc.) and uniquely
identifies which uart driver is the earlycon.

The current scheme could be fixed easily enough (by just using a single digit).
Or using a separator, ie. uart/0, pl011/0, etc.

Regards,
Peter Hurley


> Instead, this patch changes the earlycon code to consistently register
> "earlycon0", but ensures that the earlycon driver name is logged at
> earlycon_init time. This is obvious, consistent, and sufficient to
> provide the required information to the user.
> 
> With this in place, amongst the first messages from the kernel, the user
> will see something like:
> 
> [0.00] earlycon: earlycon0 (pl011) at MMIO 0x7ff8 
> (options '')
> [0.00] bootconsole [earlycon0] enabled
> 
> Signed-off-by: Mark Rutland 
> Cc: Greg Kroah-Hartman 
> Cc: Jiri Slaby 
> Cc: Leif Lindholm 
> Cc: Peter Hurley 
> Cc: Rob Herring 
> Cc: Will Deacon 
> Cc: linux-ser...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  drivers/tty/serial/earlycon.c | 19 ---
>  1 file changed, 4 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
> index 067783f..2b6622a 100644
> --- a/drivers/tty/serial/earlycon.c
> +++ b/drivers/tty/serial/earlycon.c
> @@ -29,7 +29,7 @@
>  #include 
>  
>  static struct console early_con = {
> - .name = "uart", /* fixed up at earlycon registration */
> + .name = "earlycon",
>   .flags =CON_PRINTBUFFER | CON_BOOT,
>   .index =0,
>  };
> @@ -60,24 +60,13 @@ static void __init earlycon_init(struct earlycon_device 
> *device,
>  {
>   struct console *earlycon = device->con;
>   struct uart_port *port = >port;
> - const char *s;
> - size_t len;
> -
> - /* scan backwards from end of string for first non-numeral */
> - for (s = name + strlen(name);
> -  s > name && s[-1] >= '0' && s[-1] <= '9';
> -  s--)
> - ;
> - if (*s)
> - earlycon->index = simple_strtoul(s, NULL, 10);
> - len = s - name;
> - strlcpy(earlycon->name, name, min(len + 1, sizeof(earlycon->name)));
> +
>   earlycon->data = _console_dev;
>  
>   if (port->iotype == UPIO_MEM || port->iotype == UPIO_MEM16 ||
>   port->iotype == UPIO_MEM32 || port->iotype == UPIO_MEM32BE)
> - pr_info("%s%d at MMIO%s %pa (options '%s')\n",
> - earlycon->name, earlycon->index,
> + pr_info("%s%d (%s) at MMIO%s %pa (options '%s')\n",
> + earlycon->name, earlycon->index, name,
>   (port->iotype == UPIO_MEM) ? "" :
>   (port->iotype == UPIO_MEM16) ? "16" :
>   (port->iotype == UPIO_MEM32) ? "32" : "32be",
> 

[PATCH 08/11] clk: imx6q: fix pll clock parents

[Dong Aisheng]

pllx_bypass_src mux shouldn't be the parent of pllx clock
since it's only valid when when pllx BYPASS bit is set.
Thus it is actually one parent of pllx_bypass only.

Instead, pllx parent should be fixed to osc according to
reference manual.
Other plls have the same issue.

Signed-off-by: Dong Aisheng 
---
 drivers/clk/imx/clk-imx6q.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/imx/clk-imx6q.c b/drivers/clk/imx/clk-imx6q.c
index 02e18182fcb5..89bbfc1be476 100644
--- a/drivers/clk/imx/clk-imx6q.c
+++ b/drivers/clk/imx/clk-imx6q.c
@@ -192,13 +192,13 @@ static void __init imx6q_clocks_init(struct device_node 
*ccm_node)
clk[IMX6QDL_PLL7_BYPASS_SRC] = imx_clk_mux("pll7_bypass_src", base + 
0x20, 14, 2, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
 
/*type   name
parent_namebase div_mask */
-   clk[IMX6QDL_CLK_PLL1] = imx_clk_pllv3(IMX_PLLV3_SYS, "pll1", 
"pll1_bypass_src", base + 0x00, 0x7f);
-   clk[IMX6QDL_CLK_PLL2] = imx_clk_pllv3(IMX_PLLV3_GENERIC, "pll2", 
"pll2_bypass_src", base + 0x30, 0x1);
-   clk[IMX6QDL_CLK_PLL3] = imx_clk_pllv3(IMX_PLLV3_USB, "pll3", 
"pll3_bypass_src", base + 0x10, 0x3);
-   clk[IMX6QDL_CLK_PLL4] = imx_clk_pllv3(IMX_PLLV3_AV,  "pll4", 
"pll4_bypass_src", base + 0x70, 0x7f);
-   clk[IMX6QDL_CLK_PLL5] = imx_clk_pllv3(IMX_PLLV3_AV,  "pll5", 
"pll5_bypass_src", base + 0xa0, 0x7f);
-   clk[IMX6QDL_CLK_PLL6] = imx_clk_pllv3(IMX_PLLV3_ENET,"pll6", 
"pll6_bypass_src", base + 0xe0, 0x3);
-   clk[IMX6QDL_CLK_PLL7] = imx_clk_pllv3(IMX_PLLV3_USB, "pll7", 
"pll7_bypass_src", base + 0x20, 0x3);
+   clk[IMX6QDL_CLK_PLL1] = imx_clk_pllv3(IMX_PLLV3_SYS, "pll1", "osc", 
base + 0x00, 0x7f);
+   clk[IMX6QDL_CLK_PLL2] = imx_clk_pllv3(IMX_PLLV3_GENERIC, "pll2", "osc", 
base + 0x30, 0x1);
+   clk[IMX6QDL_CLK_PLL3] = imx_clk_pllv3(IMX_PLLV3_USB, "pll3", "osc", 
base + 0x10, 0x3);
+   clk[IMX6QDL_CLK_PLL4] = imx_clk_pllv3(IMX_PLLV3_AV,  "pll4", "osc", 
base + 0x70, 0x7f);
+   clk[IMX6QDL_CLK_PLL5] = imx_clk_pllv3(IMX_PLLV3_AV,  "pll5", "osc", 
base + 0xa0, 0x7f);
+   clk[IMX6QDL_CLK_PLL6] = imx_clk_pllv3(IMX_PLLV3_ENET,"pll6", "osc", 
base + 0xe0, 0x3);
+   clk[IMX6QDL_CLK_PLL7] = imx_clk_pllv3(IMX_PLLV3_USB, "pll7", "osc", 
base + 0x20, 0x3);
 
clk[IMX6QDL_PLL1_BYPASS] = imx_clk_mux_flags("pll1_bypass", base + 
0x00, 16, 1, pll1_bypass_sels, ARRAY_SIZE(pll1_bypass_sels), 
CLK_SET_RATE_PARENT);
clk[IMX6QDL_PLL2_BYPASS] = imx_clk_mux_flags("pll2_bypass", base + 
0x30, 16, 1, pll2_bypass_sels, ARRAY_SIZE(pll2_bypass_sels), 
CLK_SET_RATE_PARENT);
-- 
1.9.1

[PATCH 06/11] clk: imx6ul: fix gpt2 clock names

[Dong Aisheng]

fix gpt2 clock names

Signed-off-by: Dong Aisheng 
---
 drivers/clk/imx/clk-imx6ul.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/imx/clk-imx6ul.c b/drivers/clk/imx/clk-imx6ul.c
index 0f1f17a8f3ed..67ae3465dd37 100644
--- a/drivers/clk/imx/clk-imx6ul.c
+++ b/drivers/clk/imx/clk-imx6ul.c
@@ -305,8 +305,8 @@ static void __init imx6ul_clocks_init(struct device_node 
*ccm_node)
clks[IMX6UL_CLK_CAN1_SERIAL]= imx_clk_gate2("can1_serial",  
"can_podf", base + 0x68,16);
clks[IMX6UL_CLK_CAN2_IPG]   = imx_clk_gate2("can2_ipg", "ipg",  
base + 0x68,18);
clks[IMX6UL_CLK_CAN2_SERIAL]= imx_clk_gate2("can2_serial",  
"can_podf", base + 0x68,20);
-   clks[IMX6UL_CLK_GPT2_BUS]   = imx_clk_gate2("gpt_bus",  
"perclk",   base + 0x68,24);
-   clks[IMX6UL_CLK_GPT2_SERIAL]= imx_clk_gate2("gpt_serial",   
"perclk",   base + 0x68,26);
+   clks[IMX6UL_CLK_GPT2_BUS]   = imx_clk_gate2("gpt_bus2", 
"perclk",   base + 0x68,24);
+   clks[IMX6UL_CLK_GPT2_SERIAL]= imx_clk_gate2("gpt_serial2",  
"perclk",   base + 0x68,26);
clks[IMX6UL_CLK_UART2_IPG]  = imx_clk_gate2("uart2_ipg","ipg",  
base + 0x68,28);
clks[IMX6UL_CLK_UART2_SERIAL]   = imx_clk_gate2("uart2_serial", 
"uart_podf",base + 0x68,28);
clks[IMX6UL_CLK_AIPSTZ3]= imx_clk_gate2("aips_tz3", "ahb",  
base + 0x68,30);
-- 
1.9.1

[PATCH 07/11] clk: imx6ul: fix pll clock parents

[Dong Aisheng]

pllx_bypass_src mux shouldn't be the parent of pllx clock
since it's only valid when when pllx BYPASS bit is set.
Thus it is actually one parent of pllx_bypass only.

Instead, pllx parent should be fixed to osc according to
reference manual.
Other plls have the same issue.

e.g. before fix, the pll tree is:
osc  662400  0 0
   pll1_bypass_src   002400  0 0
  pll1   00   79200  0 0
 pll1_bypass 00   79200  0 0
pll1_sys 00   79200  0 0

After the fix, it's:
osc  662400  0 0
   pll1  00   79200  0 0
  pll1_bypass00   79200  0 0
 pll1_sys00   79200  0 0

Signed-off-by: Dong Aisheng 
---
 drivers/clk/imx/clk-imx6ul.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/imx/clk-imx6ul.c b/drivers/clk/imx/clk-imx6ul.c
index 67ae3465dd37..bdf4cf807b78 100644
--- a/drivers/clk/imx/clk-imx6ul.c
+++ b/drivers/clk/imx/clk-imx6ul.c
@@ -130,13 +130,13 @@ static void __init imx6ul_clocks_init(struct device_node 
*ccm_node)
clks[IMX6UL_PLL6_BYPASS_SRC] = imx_clk_mux("pll6_bypass_src", base + 
0xe0, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
clks[IMX6UL_PLL7_BYPASS_SRC] = imx_clk_mux("pll7_bypass_src", base + 
0x20, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
 
-   clks[IMX6UL_CLK_PLL1] = imx_clk_pllv3(IMX_PLLV3_SYS, "pll1", 
"pll1_bypass_src", base + 0x00, 0x7f);
-   clks[IMX6UL_CLK_PLL2] = imx_clk_pllv3(IMX_PLLV3_GENERIC, "pll2", 
"pll2_bypass_src", base + 0x30, 0x1);
-   clks[IMX6UL_CLK_PLL3] = imx_clk_pllv3(IMX_PLLV3_USB, "pll3", 
"pll3_bypass_src", base + 0x10, 0x3);
-   clks[IMX6UL_CLK_PLL4] = imx_clk_pllv3(IMX_PLLV3_AV,  "pll4", 
"pll4_bypass_src", base + 0x70, 0x7f);
-   clks[IMX6UL_CLK_PLL5] = imx_clk_pllv3(IMX_PLLV3_AV,  "pll5", 
"pll5_bypass_src", base + 0xa0, 0x7f);
-   clks[IMX6UL_CLK_PLL6] = imx_clk_pllv3(IMX_PLLV3_ENET,"pll6", 
"pll6_bypass_src", base + 0xe0, 0x3);
-   clks[IMX6UL_CLK_PLL7] = imx_clk_pllv3(IMX_PLLV3_USB, "pll7", 
"pll7_bypass_src", base + 0x20, 0x3);
+   clks[IMX6UL_CLK_PLL1] = imx_clk_pllv3(IMX_PLLV3_SYS, "pll1", "osc", 
base + 0x00, 0x7f);
+   clks[IMX6UL_CLK_PLL2] = imx_clk_pllv3(IMX_PLLV3_GENERIC, "pll2", "osc", 
base + 0x30, 0x1);
+   clks[IMX6UL_CLK_PLL3] = imx_clk_pllv3(IMX_PLLV3_USB, "pll3", "osc", 
base + 0x10, 0x3);
+   clks[IMX6UL_CLK_PLL4] = imx_clk_pllv3(IMX_PLLV3_AV,  "pll4", "osc", 
base + 0x70, 0x7f);
+   clks[IMX6UL_CLK_PLL5] = imx_clk_pllv3(IMX_PLLV3_AV,  "pll5", "osc", 
base + 0xa0, 0x7f);
+   clks[IMX6UL_CLK_PLL6] = imx_clk_pllv3(IMX_PLLV3_ENET,"pll6", "osc", 
base + 0xe0, 0x3);
+   clks[IMX6UL_CLK_PLL7] = imx_clk_pllv3(IMX_PLLV3_USB, "pll7", "osc", 
base + 0x20, 0x3);
 
clks[IMX6UL_PLL1_BYPASS] = imx_clk_mux_flags("pll1_bypass", base + 
0x00, 16, 1, pll1_bypass_sels, ARRAY_SIZE(pll1_bypass_sels), 
CLK_SET_RATE_PARENT);
clks[IMX6UL_PLL2_BYPASS] = imx_clk_mux_flags("pll2_bypass", base + 
0x30, 16, 1, pll2_bypass_sels, ARRAY_SIZE(pll2_bypass_sels), 
CLK_SET_RATE_PARENT);
-- 
1.9.1

Re: [PATCH 2/3] iio: adc: ina3221: Add support for IIO ADC driver for TI INA3221

[Andrew F. Davis]

On 06/07/2016 05:30 PM, Guenter Roeck wrote:
> On Fri, Jun 03, 2016 at 10:17:55AM -0500, Andrew F. Davis wrote:
>> On 06/03/2016 09:14 AM, Laxman Dewangan wrote:
>>>
>>> On Friday 03 June 2016 06:59 PM, Guenter Roeck wrote:
 On 06/03/2016 03:06 AM, Jonathan Cameron wrote:
> On 01/06/16 13:34, Laxman Dewangan wrote:
>> The INA3221 is a three-channel, high-side current and bus voltage
>> monitor
>> with an I2C interface from Texas Instruments. The INA3221 monitors both
>> shunt voltage drops and bus supply voltages in addition to having
>> programmable conversion times and averaging modes for these signals.
>> The INA3221 offers both critical and warning alerts to detect multiple
>> programmable out-of-range conditions for each channel.
>>
>> Add support for INA3221 SW driver via IIO ADC interface. The device is
>> register as iio-device and provides interface for voltage/current
>> and power
>> monitor. Also provide interface for setting oneshot/continuous mode and
>> critical/warning threshold for the shunt voltage drop.
>>
>> Signed-off-by: Laxman Dewangan 
> Hi Laxman,
>
> As ever with any driver lying on the border of IIO and hwmon, please
> include
> a short justification of why you need an IIO driver and also cc the
> hwmon list + maintainers. (cc'd on this reply).
>
> I simply won't take a driver where the hwmon maintainers aren't happy.
> As it stands I'm not seeing obvious reasons in the code for why this
> should be an IIO device.
>

 Me not either.

 I have a hwmon driver for the same chip pending from Andrew Davis (TI)
 which I am just about to accept. We had directed Andrew back in April
 to write a hwmon driver for the chip, which he did.

>>>
>>> Thanks Guenter,  I found the series
>>>
>>> [PATCH v2 0/2] Add support for INA3221 Triple Current/Voltage Monitors
>>> Looks fine to me. I can use the hwmon.
>>>
>>
>> If you search even further back you can see I originally went with an
>> IIO driver as well, comparing the IIO and hwmon version for the simple
>> use cases I needed the hwmod version turned out much simpler, so it was
>> probably the right framework for now.
>>
>>>
>>> However, some of the stuff from my patch are not there which I will add
>>> later once original patch applied:
>>> - Dynamic mode changes for continuous and one-shot from sysfs.
>>> - In one shot, when try to read voltage data, do conversion and then read.
>>>
>>
>> My attempt is rather minimal, to be honest I like your stab at this
>> driver better in some ways, especially relating to DT putting each
>> channel in its own node with labels, I think this is a bit more clean
>> and will be more extendable if/when new multi-channel monitor chips are
>> made.
>>
>>> Not sure whether exporting the following will help or not. Can you
>>> please confirm?
>>> - Oversampling time i.e. average sample
>>> - conversion time for bus voltage and shunt voltage if default is not
>>> suited for system.
>>>
>>>
>>
>> These can always be added as needed, but the DT changes are not as easy.
>> I would like it if this got in this cycle but if you think something
>> will be needed to help your improvements, that can not be added
>> incrementally, it would probably be best to get them into the initial DT
>> binding doc now.
>>
> Andrew,
> 
> with this, the hwmon driver is pretty much on hold. What do you want me to do 
> ?
> Should I wait for DT updates ?
> 

If Laxman would like to commit to making these changes I do not problem
waiting a bit to get this right the first time.

If we don't hear back soon then I'd just take it as is and anything
needing to be fixed can be later.

Andrew

Re: [GIT PULL arm] Use _rcuidle tracepoints to allow tracing from idle

[Paul E. McKenney]

On Wed, Jun 08, 2016 at 03:33:50PM +0200, Ingo Molnar wrote:
> 
> * Paul E. McKenney  wrote:
> 
> > On Thu, May 26, 2016 at 09:26:06AM -0700, Paul E. McKenney wrote:
> > > Hello, Ingo,
> > > 
> > > This series changes a number of event tracepoints to their _rcuidle() form
> > > to allow use from idle without lockdep-RCU complaints, a straightforward
> > > modification that has been successfully applied many times.  These splats
> > > were found in testing by Guenter Roeck and Tony Lindgren, who have
> > > both successfully tested the full series.  Tony asked that I carry these
> > > in -rcu:
> > > 
> > >   http://lkml.kernel.org/g/20160426213630.gv5...@atomide.com
> > > 
> > > These have been posted to LKML, CCing relevant maintainers, who have
> > > not objected to the proposed changes:
> > > 
> > >   http://lkml.kernel.org/g/20160516184844.ga20...@linux.vnet.ibm.com
> > > 
> > > These maintainers are also CCed on this pull request.
> > > 
> > > They have also been subjected to 0day Test Robot and -next testing.
> > 
> > And this time actually including the pull request...  :-/
> > 
> > Thanx, Paul
> > 
> > These changes are available in the git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
> > for-mingo
> > 
> > for you to fetch changes up to e7c38dda94b23965a3eb46ef4656bb8cb921933d:
> > 
> >   arm: Use _rcuidle suffix to allow clk_core_enable() to used from idle 
> > (2016-05-18 11:55:29 -0700)
> > 
> > 
> > Paul E. McKenney (6):
> >   arm: Use _rcuidle tracepoint to allow use from idle
> >   arm: Use _rcuidle for suspend/resume tracepoints
> >   arm: Add _rcuidle tracepoints to allow clk_core_disable() use from 
> > idle
> >   arm: Add _rcuidle suffix to allow rpm_idle() use from idle
> >   arm: Add _rcuidle suffix to allow rpm_resume() to be called from idle
> >   arm: Use _rcuidle suffix to allow clk_core_enable() to used from idle
> > 
> >  arch/arm/kernel/smp.c |  2 +-
> >  arch/arm/mach-omap2/powerdomain.c |  9 +
> >  drivers/base/power/runtime.c  | 14 +++---
> >  drivers/clk/clk.c |  8 
> >  4 files changed, 17 insertions(+), 16 deletions(-)
> 
> Just wondering, wouldn't it be better for Russell to pull/apply, as it 
> appears to 
> be a mostly ARM patch-set?

Fair enough -- I can always repost the patches to their respective
maintainers if you are in any way uncomfortable taking them.  The patches
do not depend on each other.

Thanx, Paul

Re: [PATCH v2] of: iommu: make of_iommu_init() postcore_initcall_sync

[Rob Herring]

On Wed, Jun 1, 2016 at 1:06 AM, Kefeng Wang  wrote:
> The of_iommu_init() is called multiple times by arch code,
> make it postcore_initcall_sync, then we can drop relevant
> calls fully.
>
> Note, the IOMMUs should have a chance to perform some basic
> initialisation before we start adding masters to them. So
> postcore_initcall_sync is good choice, it ensures of_iommu_init()
> called before of_platform_populate.

What ever happened to doing deferred probe for IOMMUs?

Rob

Re: [PATCH 2/3] iio: adc: ina3221: Add support for IIO ADC driver for TI INA3221

[Laxman Dewangan]

On Wednesday 08 June 2016 08:34 PM, Andrew F. Davis wrote:

On 06/07/2016 05:30 PM, Guenter Roeck wrote:

On Fri, Jun 03, 2016 at 10:17:55AM -0500, Andrew F. Davis wrote:

On 06/03/2016 09:14 AM, Laxman Dewangan wrote:

On Friday 03 June 2016 06:59 PM, Guenter Roeck wrote:

On 06/03/2016 03:06 AM, Jonathan Cameron wrote:

On 01/06/16 13:34, Laxman Dewangan wrote:

The INA3221 is a three-channel, high-side current and bus voltage
monitor
with an I2C interface from Texas Instruments. The INA3221 monitors both
shunt voltage drops and bus supply voltages in addition to having
programmable conversion times and averaging modes for these signals.
The INA3221 offers both critical and warning alerts to detect multiple
programmable out-of-range conditions for each channel.

Add support for INA3221 SW driver via IIO ADC interface. The device is
register as iio-device and provides interface for voltage/current
and power
monitor. Also provide interface for setting oneshot/continuous mode and
critical/warning threshold for the shunt voltage drop.

Signed-off-by: Laxman Dewangan 

Hi Laxman,

As ever with any driver lying on the border of IIO and hwmon, please
include
a short justification of why you need an IIO driver and also cc the
hwmon list + maintainers. (cc'd on this reply).

I simply won't take a driver where the hwmon maintainers aren't happy.
As it stands I'm not seeing obvious reasons in the code for why this
should be an IIO device.


Me not either.

I have a hwmon driver for the same chip pending from Andrew Davis (TI)
which I am just about to accept. We had directed Andrew back in April
to write a hwmon driver for the chip, which he did.


Thanks Guenter,  I found the series

[PATCH v2 0/2] Add support for INA3221 Triple Current/Voltage Monitors
Looks fine to me. I can use the hwmon.


If you search even further back you can see I originally went with an
IIO driver as well, comparing the IIO and hwmon version for the simple
use cases I needed the hwmod version turned out much simpler, so it was
probably the right framework for now.


However, some of the stuff from my patch are not there which I will add
later once original patch applied:
- Dynamic mode changes for continuous and one-shot from sysfs.
- In one shot, when try to read voltage data, do conversion and then read.


My attempt is rather minimal, to be honest I like your stab at this
driver better in some ways, especially relating to DT putting each
channel in its own node with labels, I think this is a bit more clean
and will be more extendable if/when new multi-channel monitor chips are
made.


Not sure whether exporting the following will help or not. Can you
please confirm?
- Oversampling time i.e. average sample
- conversion time for bus voltage and shunt voltage if default is not
suited for system.



These can always be added as needed, but the DT changes are not as easy.
I would like it if this got in this cycle but if you think something
will be needed to help your improvements, that can not be added
incrementally, it would probably be best to get them into the initial DT
binding doc now.


Andrew,

with this, the hwmon driver is pretty much on hold. What do you want me to do ?
Should I wait for DT updates ?


If Laxman would like to commit to making these changes I do not problem
waiting a bit to get this right the first time.

If we don't hear back soon then I'd just take it as is and anything
needing to be fixed can be later.




I will be able to post the patch tomorrow.
I think this series can be applied and then on top of it, I will post 
the dt changes and other my changes.


As this is new driver and no one using now, it will be fine to have dt 
changes if everything complete in one cycle.


I will work from the tree on which this applied to post my patches.

Re: [PATCH] Add .set_antenna callback in ath6kl driver to remove wireless core warns

[Ben Greear]

On 06/08/2016 08:46 AM, Prasun Maiti wrote:

Please tell me if I mention that this code is untested in commit log,
then could you check the code kindly and also help me to fix this type
of warning?


In my experience, ath6kl has very fragile and buggy firmware, so I would
not add any new API to it unless you have tested this thoroughly.

Thanks,
Ben



On Wed, Jun 8, 2016 at 9:00 PM, Valo, Kalle  wrote:

Prasun Maiti  writes:


I am not sure it works fine. Like ath6kl driver send another cmd to
firmare, I have just filled up the cmd buffer with "tx_ant", and
"rx_ant" values, then use "ath6kl_wmi_cmd_send()" api to send the cmd
buffer to firmware. I have resend the patch as there are some errors
in the previous patch. Let me know if any modifications are needed?


I don't take untested code. In some special cases it might be ok to send
untested code but even then it needs to be clearly stated in the commit
log that it's untested.

Please resend once you have tested this, I'm dropping this now.

--
Kalle Valo







--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH v3 1/2] Documentation: mfd: LP873X: Add information for the mfd and regulator drivers

[Lee Jones]

On Fri, 13 May 2016, Keerthy wrote:

> Add information for the mfd and regulator drivers.
> 
> Acked-by: Rob Herring 
> Signed-off-by: Keerthy 
> ---
> 
> Changes in v3:
> 
>   * Changed the example node lable to pmic from lp8733.
> 
>  Documentation/devicetree/bindings/mfd/lp873x.txt | 55 
> 
>  1 file changed, 55 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/lp873x.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/lp873x.txt 
> b/Documentation/devicetree/bindings/mfd/lp873x.txt
> new file mode 100644
> index 000..8f3ef0d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/lp873x.txt
> @@ -0,0 +1,55 @@
> +TI LP3943 MFD driver
> +
> +Required properties:
> +  - compatible: "ti,lp8732", "ti,lp8733"
> +  - reg: I2C slave address.
> +
> +For the lp873x regulator properties please refer to:
> +../bindings/regulator/lp873x.txt

What else does the LP3943 consist of apart from regulators?

> +Example:
> +
> +pmic: lp8733@60 {
> + compatible = "ti,lp8733";
> + reg = <0x60>;
> +
> + regulators {
> + lp8733_buck0: buck0 {
> + regulator-name = "lp8733-buck0";
> + regulator-min-microvolt = <80>;
> + regulator-max-microvolt = <140>;
> + regulator-min-microamp = <150>;
> + regulator-max-microamp = <400>;
> + regulator-ramp-delay = <1>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + lp8733_buck1: buck1 {
> + regulator-name = "lp8733-buck1";
> + regulator-min-microvolt = <80>;
> + regulator-max-microvolt = <140>;
> + regulator-min-microamp = <150>;
> + regulator-max-microamp = <400>;
> + regulator-ramp-delay = <1>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + lp8733_ldo0: ldo0 {
> + regulator-name = "lp8733-ldo0";
> + regulator-min-microvolt = <80>;
> + regulator-max-microvolt = <300>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + lp8733_ldo1: ldo1 {
> + regulator-name = "lp8733-ldo1";
> + regulator-min-microvolt = <80>;
> + regulator-max-microvolt = <300>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> + };
> +};

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 3/8] mfd: tps65218: Use mfd_add_devices instead of of_platform_populate

[Lee Jones]

On Wed, 11 May 2016, Keerthy wrote:

> mfd_add_devices enables parsing device tree nodes without compatibles
> for child nodes. Replace of_platform_populate with mfd_add_devices.
> 
> Signed-off-by: Keerthy 
> ---
>  drivers/mfd/tps65218.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
> index f20a531..b8b3a58 100644
> --- a/drivers/mfd/tps65218.c
> +++ b/drivers/mfd/tps65218.c
> @@ -33,6 +33,10 @@
>  
>  #define TPS65218_PASSWORD_REGS_UNLOCK   0x7D
>  
> +static const struct mfd_cell tps65218_cells[] = {
> + { .name = "tps65218-regulator", },
> +};

What other devices does the TPS65218 consist of?

>  /**
>   * tps65218_reg_write: Write a single tps65218 register.
>   *
> @@ -236,8 +240,10 @@ static int tps65218_probe(struct i2c_client *client,
>   if (ret < 0)
>   return ret;
>  
> - ret = of_platform_populate(client->dev.of_node, NULL, NULL,
> ->dev);
> + ret = mfd_add_devices(tps->dev, PLATFORM_DEVID_AUTO, tps65218_cells,
> +   ARRAY_SIZE(tps65218_cells), NULL, 0,
> +   regmap_irq_get_domain(tps->irq_data));
> +
>   if (ret < 0)
>   goto err_irq;
>  

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 1/4] of: Add device tree bindings for Evatronix

[Boris Brezillon]

On Tue, 7 Jun 2016 17:01:41 +0200
Ricard Wanderlof  wrote:

> Hi Boris,
> 
> First of all, thanks for reviewing this.
> 
> On Fri, 3 Jun 2016, Boris Brezillon wrote:
> 
> > > +
> > > +Optional properties:
> > > +- nand-on-flash-bbt: See nand.txt.
> > > +- #address-cells, #size-cells: See partition.txt.
> > > +- evatronix,use-bank-select : Use controller bank select function to 
> > > access
> > > +   multiple chips, rather than chip enable.  
> > 
> > You mean, using a dedicated logic to control the CS lines rather than a
> > GPIO (controlled by the SW using gpio_set_value())?  
> 
> No. In the SoC on which this has been developed, the nand flash controller 
> has dedicated I/O pins for all its functions.
> 
> The controller has the concept of 'banks' vs. 'devices'. Essentially, a 
> 'bank' is a group of multiple chips of the same geometry etc, and the 
> controller can send commands in parallel to all devices in the same bank. 
> In contrast, different 'banks' can have completely different devices, but 
> all devices must be idle before the controller can switch 'banks'.
> 
> The usecase for the former would be to increase performance and the latter 
> case would be if there were for instance one small NAND flash for program 
> storage and a large one for data.
> 
> The IP that the driver was tested on has two available chip selects, and 
> the DT property controls whether they refer to two devices in the same 
> bank vs. two separate banks.

Still don't see how it can be used in real world (or maybe I don't
understand how it works).

Say the CS are both selected at the same time, this means you'll send
the same set of data to the 2 chips, right. I see two use cases for
this:
1/ You have 2 chips connected to the same data bus, CS, RB and CLE/ALE
   lines and you want to mirror data written on chip0 on chip1
2/ You have 2 chips connected to the same CS, RB, CLE/ALE lines, but
   chip0 is using the lower 8bits of the bus, and chip1 is using the
   remaining 8bits. This way you fake an 16bits bus

Both cases are unsafe, because of NAND unreliability. Say you're
writing on a block in chip0 this block in chip1 is bad. One of your
write will succeed, the other one will fail.

Could you give a real use case where this 'bank-select' method is
really usefull (and safe)?
If you can't, then drop this mode for now, and always operate in
'chip-enable' mode.

> 
> > BTW, you seem to support controlling several CS using the same
> > controller, which means you'll have to specify which CS the NAND chip
> > is connected to (see [1]).  
> 
> That is true. The driver as it stands currently only supports a single CS, 
> however, the IP as configured in the SoC in question can handle two CS 
> lines. My plan is to initially provide support for only the single-CS 
> case (there are places in the code where I felt it practical to prepare 
> for the multiple-CS case though).
> 
> As such, I realize that the previously mentioned property 
> (evatronix,use-bank-select) won't really have any meaning in the single-CS 
> case, so perhaps it should be omitted at this point completely, and added 
> in the future when it is really needed?

Yes, but I'd still like to see a proper NAND controller/NAND chip
separation in you binding.

> 
> > > +- evatronix,rb-wired-and: Assume ready/busy signal from all flash chips 
> > > are
> > > +   connected using a wired-AND topology rather than
> > > +   individually.  
> > 
> > Hm, is that really required? If the R/B line is shared among several
> > NAND chips, it should be transparent, you just have to specific which
> > chip is connected to which GPIO (or dedicated R/B pin).  
> 
> For the SoC in question, the wired-and vs individual R/B lines was a 
> choice made during the chip design, which is why I exported this choice as 
> a DT property, as it reflects a hardware choice done outside the IP but 
> inside the SoC.


Okay, maybe it's worth keeping this property if the AND logic is
integrated in the SoC.

> 
> I didn't really want to have the added flexibility (and complexity) of 
> being able to use any R/B line for any connected flash chip. It seems an 
> unnecessary complication for the driver without much gain.

Not really, at least if you properly separate the chip and controller
objects it's quite easy to deal with, and I'll ask you to do this clean
separation anyway (even if you say you only have a single chip per
controller) :P.

> 
> But it would certainly be doable, as the R/B stuff is handled completely 
> in software. One would still need a new property that the child nand nodes 
> can use to select the R/B line (e.g. evatronix,rb-line). (In the 
> configuration we have, as with the CS lines, the R/B line has its own 
> dedicated pin, so it's not a GPIO). So it would still require a DT 
> property to manage it.

Yep. The sunxi_nand driver is using allwinner,rb = .

> 
> Again, this property doesn't really 

Re: [PATCH] Add .set_antenna callback in ath6kl driver to remove wireless core warns

[Ben Greear]

On 06/08/2016 08:56 AM, Prasun Maiti wrote:

Please help me how to test this one?? It will be great to me if you help me.


I do not have time or interest, sorry.  You basically need access to
firmware source to do any useful development on this driver in my opinion,
and I do not have access to that source.

Why are you so concerned about the warning anyway?

Thanks,
Ben



On Wed, Jun 8, 2016 at 9:21 PM, Ben Greear  wrote:

On 06/08/2016 08:46 AM, Prasun Maiti wrote:


Please tell me if I mention that this code is untested in commit log,
then could you check the code kindly and also help me to fix this type
of warning?



In my experience, ath6kl has very fragile and buggy firmware, so I would
not add any new API to it unless you have tested this thoroughly.

Thanks,
Ben



On Wed, Jun 8, 2016 at 9:00 PM, Valo, Kalle 
wrote:


Prasun Maiti  writes:


I am not sure it works fine. Like ath6kl driver send another cmd to
firmare, I have just filled up the cmd buffer with "tx_ant", and
"rx_ant" values, then use "ath6kl_wmi_cmd_send()" api to send the cmd
buffer to firmware. I have resend the patch as there are some errors
in the previous patch. Let me know if any modifications are needed?



I don't take untested code. In some special cases it might be ok to send
untested code but even then it needs to be clearly stated in the commit
log that it's untested.

Please resend once you have tested this, I'm dropping this now.

--
Kalle Valo








--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com








--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH 07/10] mm: base LRU balancing on an explicit cost model

[Johannes Weiner]

On Wed, Jun 08, 2016 at 02:51:37PM +0200, Michal Hocko wrote:
> On Mon 06-06-16 15:48:33, Johannes Weiner wrote:
> > Rename struct zone_reclaim_stat to struct lru_cost, and move from two
> > separate value ratios for the LRU lists to a relative LRU cost metric
> > with a shared denominator.
> 
> I just do not like the too generic `number'. I guess cost or price would
> fit better and look better in the code as well. Up you though...

Yeah, I picked it as a pair, numerator and denominator. But as Minchan
points out, denom is superfluous in the final version of the patch, so
I'm going to remove it and give the numerators better names.

anon_cost and file_cost?

> > Then make everything that affects the cost go through a new
> > lru_note_cost() function.
> 
> Just curious, have you tried to measure just the effect of this change
> without the rest of the series? I do not expect it would show large
> differences because we are not doing SCAN_FRACT most of the time...

Yes, we default to use-once cache and do fractional scanning when that
runs out and we have to go after workingset, which might potentially
cause refault IO. So you need a workload that has little streaming IO.

I haven't tested this patch in isolation, but it shouldn't make much
of a difference, since we continue to balance based on the same input.

> > Signed-off-by: Johannes Weiner 
> 
> Acked-by: Michal Hocko 

Thanks!

Re: [PATCH v2 5/6] dt-bindings: add Sharp LQ123P1JX31 panel binding

[Doug Anderson]

Yakir,

On Wed, Jun 8, 2016 at 4:52 AM, Yakir Yang  wrote:
> The Sharp LQ123P1JX31 is an 12.3" 2400x1600 TFT-LCD panel
> connected using eDP interfaces.
>
> Signed-off-by: Yakir Yang 
> ---
> Changes in v2:
> - Add dt-bindings of Sharp LQ123P1JX31 panel in v2
>
>  .../devicetree/bindings/display/panel/sharp,lq123p1jx31.txt| 7 
> +++
>  1 file changed, 7 insertions(+)

Seems sane to me.

Reviewed-by: Douglas Anderson 

Re: Using DT overlays for adding virtual hardware

[Pantelis Antoniou]

Hi Mark,

> On Jun 8, 2016, at 19:23 , Mark Rutland  wrote:
> 
> On Wed, Jun 08, 2016 at 06:57:37PM +0300, Pantelis Antoniou wrote:
>> Hi Mark,
>> 
>>> On Jun 8, 2016, at 18:17 , Mark Rutland  wrote:
>>> 
>>> On Wed, Jun 08, 2016 at 04:16:32PM +0200, Jan Kiszka wrote:
 Hi all,
 
 already started the discussion off-list with Pantelis, but it's better
 done in public:
 
 I'm currently exploring ways to make Linux recognize dynamically added
 virtual hardware when running under the Jailhouse hypervisor [1]. We
 need to load drivers for inter-partition communication devices that only
 appear after Jailhouse started (which is done from within Linux, i.e.
 long after boot) or when a partition was added later on. Probably, we
 will simply add a virtual PCI host bridge on systems without physical
 PCI and let the IPC device be explored that way (already works on x86).
 Still, that leaves us with hotplug and unplug on hypervisor activation
 and deactivation.
>>> 
>>> If I've understood correctly you want to use overlays to inject the
>>> virtual PCI host bridge?
>>> 
>>> Given that you know precisely what you want to inject, I'm not sure I
>>> see the value of using an overlay. 
>>> 
>>> Is there some reason you can't just create a device without having to go
>>> via an intermediate step? As I understand it, Xen does that for (some)
>>> virtual devices provided to Dom0 and DomU.
>> 
>> As far as I understand it PCI is just one of the cases. You could conceivably
>> inject any kind of virtio device like serial/storage networking etc.
> 
> Sure, but we already have PCI transport for virtio devices, and per the
> above PCI is the transport used on x86, so I assume that the devices we
> really care about are going to be PCI anyhow.
> 

PCI on VMs is a hack, it’s all emulated.

We’re using it as crutch because it’s ubiquitous and is capable
of probing, but it comes with a considerable amount of baggage.
Jailhouse is a particular kind of a hypervisor where it is intended for
safety critical applications and designed to be certified as such.
The less amount of code it contains the better, and much easier to certify. 

>> The question is since overlays exist and do work, why should he do anything 
>> else
>> besides using them?
> 
> For one thing, they only work with DT, and there are ACPI ARM server
> platforms out there, for which people may wish to use jailhouse. Tying
> this to DT is not necessarily the best idea.
> 

I just don’t see how an ACPI based hypervisor can ever be certified for
safety critical applications. It might be possible but it should be
an enormous undertaking; perhaps a subset without AML, but then again
can you even boot an ACPI box without it?

DT is safer since it contains state only.

> To be clear, I'm not arguing *against* overlays as such, just making
> sure that we're not prematurely choosing a solution just becasue it's
> the one we're aware of.
> 
> Thanks,
> Mark.

Regards

— Pantelis

[PATCH v2 07/13] pwm: sti: Avoid glitches on already running PWMs

[Boris Brezillon]

The current logic will disable the PWM clk even if a PWM was left
enabled by the bootloader (because it's controlling a critical device
like a regulator for example).
Keep the PWM clk enabled if at least one PWM is enabled to avoid any
glitches.

Signed-off-by: Boris Brezillon 
---
 drivers/pwm/pwm-sti.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/pwm/pwm-sti.c b/drivers/pwm/pwm-sti.c
index 6300d3e..5bda51d 100644
--- a/drivers/pwm/pwm-sti.c
+++ b/drivers/pwm/pwm-sti.c
@@ -340,7 +340,7 @@ static int sti_pwm_probe(struct platform_device *pdev)
struct sti_pwm_compat_data *cdata;
struct sti_pwm_chip *pc;
struct resource *res;
-   int ret;
+   int i, ret;
 
pc = devm_kzalloc(dev, sizeof(*pc), GFP_KERNEL);
if (!pc)
@@ -391,7 +391,7 @@ static int sti_pwm_probe(struct platform_device *pdev)
return -EINVAL;
}
 
-   ret = clk_prepare(pc->clk);
+   ret = clk_prepare_enable(pc->clk);
if (ret) {
dev_err(dev, "failed to prepare clock\n");
return ret;
@@ -409,6 +409,16 @@ static int sti_pwm_probe(struct platform_device *pdev)
return ret;
}
 
+   /*
+* Keep the PWM clk enabled if some PWMs appear to be up and
+* running.
+*/
+   for (i = 0; i < pc->chip.npwm; i++) {
+   if (pwm_is_enabled(>chip.pwms[i]))
+   clk_enable(pc->clk);
+   }
+   clk_disable(pc->clk);
+
platform_set_drvdata(pdev, pc);
 
return 0;
-- 
2.7.4

Re: 274ad65c9d02 ("drm/radeon: hard reset r600 and newer GPU when hibernating.")

[Borislav Petkov]

On Wed, Jun 08, 2016 at 12:44:12PM -0400, Alex Deucher wrote:
> If the ring and IB tests pass on resume, you should be good to go.

Yap, they do. I pasted that output earlier but here it is again:

[   64.745988] [drm] ring test on 0 succeeded in 1 usecs
[   64.920633] [drm] ring test on 5 succeeded in 1 usecs
[   64.920637] [drm] UVD initialized successfully.
[   64.920652] [drm] ib test on ring 0 succeeded in 0 usecs

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.

[PATCH v6 07/11] powerpc/powernv: set power_save func after the idle states are initialized

[Shreyas B. Prabhu]

pnv_init_idle_states discovers supported idle states from the
device tree and does the required initialization. Set power_save
function pointer only after this initialization is done

Reviewed-by: Gautham R. Shenoy 
Signed-off-by: Shreyas B. Prabhu 
---
- No changes since v1

 arch/powerpc/platforms/powernv/idle.c  | 3 +++
 arch/powerpc/platforms/powernv/setup.c | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/powernv/idle.c 
b/arch/powerpc/platforms/powernv/idle.c
index fcc8b68..fbb09fb 100644
--- a/arch/powerpc/platforms/powernv/idle.c
+++ b/arch/powerpc/platforms/powernv/idle.c
@@ -285,6 +285,9 @@ static int __init pnv_init_idle_states(void)
}
 
pnv_alloc_idle_core_states();
+
+   if (supported_cpuidle_states & OPAL_PM_NAP_ENABLED)
+   ppc_md.power_save = power7_idle;
 out_free:
kfree(flags);
 out:
diff --git a/arch/powerpc/platforms/powernv/setup.c 
b/arch/powerpc/platforms/powernv/setup.c
index ee6430b..8492bbb 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -315,7 +315,7 @@ define_machine(powernv) {
.get_proc_freq  = pnv_get_proc_freq,
.progress   = pnv_progress,
.machine_shutdown   = pnv_shutdown,
-   .power_save = power7_idle,
+   .power_save = NULL,
.calibrate_decr = generic_calibrate_decr,
 #ifdef CONFIG_KEXEC
.kexec_cpu_down = pnv_kexec_cpu_down,
-- 
2.1.4

[PATCH v6 08/11] powerpc/powernv: Add platform support for stop instruction

[Shreyas B. Prabhu]

POWER ISA v3 defines a new idle processor core mechanism. In summary,
 a) new instruction named stop is added. This instruction replaces
instructions like nap, sleep, rvwinkle.
 b) new per thread SPR named Processor Stop Status and Control Register
(PSSCR) is added which controls the behavior of stop instruction.

PSSCR layout:
--
| PLS | /// | SD | ESL | EC | PSLL | /// | TR | MTL | RL |
--
0  4 41   4243   44 4854   5660

PSSCR key fields:
Bits 0:3  - Power-Saving Level Status. This field indicates the lowest
power-saving state the thread entered since stop instruction was last
executed.

Bit 42 - Enable State Loss
0 - No state is lost irrespective of other fields
1 - Allows state loss

Bits 44:47 - Power-Saving Level Limit
This limits the power-saving level that can be entered into.

Bits 60:63 - Requested Level
Used to specify which power-saving level must be entered on executing
stop instruction

This patch adds support for stop instruction and PSSCR handling.

Reviewed-by: Gautham R. Shenoy 
Signed-off-by: Shreyas B. Prabhu 
---
Changes in v6
=
 - Save/restore new P9 SPRs when using deep idle states

Changes in v4:
==
 - Added PSSCR layout to commit message
 - Improved / Fixed comments
 - Fixed whitespace error in paca.h
 - Using MAX_POSSIBLE_STOP_STATE macro instead of hardcoding 0xF as 
   max possible stop state

Changes in v3:
==
 - Instead of introducing new file idle_power_stop.S, P9 idle support
   is added to idle_power_common.S using CPU_FTR sections.
 - Fixed r4 reg clobbering in power_stop0
 - Improved comments

Changes in v2:
==
 - Using CPU_FTR_ARCH_300 bit instead of CPU_FTR_STOP_INST

 arch/powerpc/include/asm/cpuidle.h|   2 +
 arch/powerpc/include/asm/kvm_book3s_asm.h |   2 +-
 arch/powerpc/include/asm/machdep.h|   1 +
 arch/powerpc/include/asm/opal-api.h   |  11 +-
 arch/powerpc/include/asm/paca.h   |   2 +
 arch/powerpc/include/asm/ppc-opcode.h |   4 +
 arch/powerpc/include/asm/processor.h  |   1 +
 arch/powerpc/include/asm/reg.h|  14 +++
 arch/powerpc/kernel/asm-offsets.c |   2 +
 arch/powerpc/kernel/idle_power_common.S   | 175 +++---
 arch/powerpc/platforms/powernv/idle.c |  84 --
 11 files changed, 265 insertions(+), 33 deletions(-)

diff --git a/arch/powerpc/include/asm/cpuidle.h 
b/arch/powerpc/include/asm/cpuidle.h
index d2f99ca..3d7fc06 100644
--- a/arch/powerpc/include/asm/cpuidle.h
+++ b/arch/powerpc/include/asm/cpuidle.h
@@ -13,6 +13,8 @@
 #ifndef __ASSEMBLY__
 extern u32 pnv_fastsleep_workaround_at_entry[];
 extern u32 pnv_fastsleep_workaround_at_exit[];
+
+extern u64 pnv_first_deep_stop_state;
 #endif
 
 #endif
diff --git a/arch/powerpc/include/asm/kvm_book3s_asm.h 
b/arch/powerpc/include/asm/kvm_book3s_asm.h
index 72b6225..d318d43 100644
--- a/arch/powerpc/include/asm/kvm_book3s_asm.h
+++ b/arch/powerpc/include/asm/kvm_book3s_asm.h
@@ -162,7 +162,7 @@ struct kvmppc_book3s_shadow_vcpu {
 
 /* Values for kvm_state */
 #define KVM_HWTHREAD_IN_KERNEL 0
-#define KVM_HWTHREAD_IN_NAP1
+#define KVM_HWTHREAD_IN_IDLE   1
 #define KVM_HWTHREAD_IN_KVM2
 
 #endif /* __ASM_KVM_BOOK3S_ASM_H__ */
diff --git a/arch/powerpc/include/asm/machdep.h 
b/arch/powerpc/include/asm/machdep.h
index 6bdcd0d..ae3b155 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -262,6 +262,7 @@ struct machdep_calls {
 extern void e500_idle(void);
 extern void power4_idle(void);
 extern void power7_idle(void);
+extern void power_stop0(void);
 extern void ppc6xx_idle(void);
 extern void book3e_idle(void);
 
diff --git a/arch/powerpc/include/asm/opal-api.h 
b/arch/powerpc/include/asm/opal-api.h
index 9bb8ddf..7f3f8c6 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -162,13 +162,20 @@
 
 /* Device tree flags */
 
-/* Flags set in power-mgmt nodes in device tree if
- * respective idle states are supported in the platform.
+/*
+ * Flags set in power-mgmt nodes in device tree describing
+ * idle states that are supported in the platform.
  */
+
+#define OPAL_PM_TIMEBASE_STOP  0x0002
+#define OPAL_PM_LOSE_HYP_CONTEXT   0x2000
+#define OPAL_PM_LOSE_FULL_CONTEXT  0x4000
 #define OPAL_PM_NAP_ENABLED0x0001
 #define OPAL_PM_SLEEP_ENABLED  0x0002
 #define OPAL_PM_WINKLE_ENABLED 0x0004
 #define OPAL_PM_SLEEP_ENABLED_ER1  0x0008 /* with workaround */
+#define OPAL_PM_STOP_INST_FAST 0x0010
+#define OPAL_PM_STOP_INST_DEEP 0x0020
 
 /*
  * OPAL_CONFIG_CPU_IDLE_STATE parameters
diff --git 

[PATCH v6 02/11] powerpc/kvm: make hypervisor state restore a function

[Shreyas B. Prabhu]

In the current code, when the thread wakes up in reset vector, some
of the state restore code and check for whether a thread needs to
branch to kvm is duplicated. Reorder the code such that this
duplication is avoided.

At a higher level this is what the change looks like-

Before this patch -
power7_wakeup_tb_loss:
restore hypervisor state
if (thread needed by kvm)
goto kvm_start_guest
restore nvgprs, cr, pc
rfid to process context

power7_wakeup_loss:
restore nvgprs, cr, pc
rfid to process context

reset vector:
if (waking from deep idle states)
goto power7_wakeup_tb_loss
else
if (thread needed by kvm)
goto kvm_start_guest
goto power7_wakeup_loss

After this patch -
power7_wakeup_tb_loss:
restore hypervisor state
return

power7_restore_hyp_resource():
if (waking from deep idle states)
goto power7_wakeup_tb_loss
return

power7_wakeup_loss:
restore nvgprs, cr, pc
rfid to process context

reset vector:
power7_restore_hyp_resource()
if (thread needed by kvm)
goto kvm_start_guest
goto power7_wakeup_loss

Reviewed-by: Paul Mackerras 
Reviewed-by: Gautham R. Shenoy 
Signed-off-by: Shreyas B. Prabhu 
---
- No changes since v3

Changes in v3:
=
- Retaining GET_PACA(r13) in System Reset vector instead of moving it
  to power7_restore_hyp_resource
- Added comments indicating entry conditions for power7_restore_hyp_resource
- Improved comments around return statements

 arch/powerpc/kernel/exceptions-64s.S | 28 ++
 arch/powerpc/kernel/idle_power7.S| 72 +---
 2 files changed, 46 insertions(+), 54 deletions(-)

diff --git a/arch/powerpc/kernel/exceptions-64s.S 
b/arch/powerpc/kernel/exceptions-64s.S
index 4c94406..4a74d6a 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -107,25 +107,9 @@ BEGIN_FTR_SECTION
beq 9f
 
cmpwi   cr3,r13,2
-
-   /*
-* Check if last bit of HSPGR0 is set. This indicates whether we are
-* waking up from winkle.
-*/
GET_PACA(r13)
-   clrldi  r5,r13,63
-   clrrdi  r13,r13,1
-   cmpwi   cr4,r5,1
-   mtspr   SPRN_HSPRG0,r13
+   bl  power7_restore_hyp_resource
 
-   lbz r0,PACA_THREAD_IDLE_STATE(r13)
-   cmpwi   cr2,r0,PNV_THREAD_NAP
-   bgt cr2,8f  /* Either sleep or Winkle */
-
-   /* Waking up from nap should not cause hypervisor state loss */
-   bgt cr3,.
-
-   /* Waking up from nap */
li  r0,PNV_THREAD_RUNNING
stb r0,PACA_THREAD_IDLE_STATE(r13)  /* Clear thread state */
 
@@ -143,13 +127,9 @@ BEGIN_FTR_SECTION
 
/* Return SRR1 from power7_nap() */
mfspr   r3,SPRN_SRR1
-   beq cr3,2f
-   b   power7_wakeup_noloss
-2: b   power7_wakeup_loss
-
-   /* Fast Sleep wakeup on PowerNV */
-8: GET_PACA(r13)
-   b   power7_wakeup_tb_loss
+   blt cr3,2f
+   b   power7_wakeup_loss
+2: b   power7_wakeup_noloss
 
 9:
 END_FTR_SECTION_IFSET(CPU_FTR_HVMODE | CPU_FTR_ARCH_206)
diff --git a/arch/powerpc/kernel/idle_power7.S 
b/arch/powerpc/kernel/idle_power7.S
index 705c867..d5def06 100644
--- a/arch/powerpc/kernel/idle_power7.S
+++ b/arch/powerpc/kernel/idle_power7.S
@@ -276,6 +276,39 @@ ALT_FTR_SECTION_END_NESTED_IFSET(CPU_FTR_ARCH_207S, 66);   
\
 20:nop;
 
 
+/*
+ * Called from reset vector. Check whether we have woken up with
+ * hypervisor state loss. If yes, restore hypervisor state and return
+ * back to reset vector.
+ *
+ * r13 - Contents of HSPRG0
+ * cr3 - set to gt if waking up with partial/complete hypervisor state loss
+ */
+_GLOBAL(power7_restore_hyp_resource)
+   /*
+* Check if last bit of HSPGR0 is set. This indicates whether we are
+* waking up from winkle.
+*/
+   clrldi  r5,r13,63
+   clrrdi  r13,r13,1
+   cmpwi   cr4,r5,1
+   mtspr   SPRN_HSPRG0,r13
+
+   lbz r0,PACA_THREAD_IDLE_STATE(r13)
+   cmpwi   cr2,r0,PNV_THREAD_NAP
+   bgt cr2,power7_wakeup_tb_loss   /* Either sleep or Winkle */
+
+   /*
+* We fall through here if PACA_THREAD_IDLE_STATE shows we are waking
+* up from nap. At this stage CR3 shouldn't contains 'gt' since that
+* indicates we are waking with hypervisor state loss from nap.
+*/
+   bgt cr3,.
+
+   blr /* Return back to System Reset vector from where
+  power7_restore_hyp_resource was invoked */
+
+
 _GLOBAL(power7_wakeup_tb_loss)
ld  r2,PACATOC(r13);
ld  r1,PACAR1(r13)
@@ -284,11 +317,13 @@ _GLOBAL(power7_wakeup_tb_loss)
 * and 

[PATCH v6 01/11] powerpc/powernv: Use PNV_THREAD_WINKLE macro while requesting for winkle

[Shreyas B. Prabhu]

Signed-off-by: Shreyas B. Prabhu 
---
-No changes since v4

Changes in v4
=
- New in v4

 arch/powerpc/kernel/idle_power7.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/idle_power7.S 
b/arch/powerpc/kernel/idle_power7.S
index 470ceeb..705c867 100644
--- a/arch/powerpc/kernel/idle_power7.S
+++ b/arch/powerpc/kernel/idle_power7.S
@@ -252,7 +252,7 @@ _GLOBAL(power7_sleep)
/* No return */
 
 _GLOBAL(power7_winkle)
-   li  r3,3
+   li  r3,PNV_THREAD_WINKLE
li  r4,1
b   power7_powersave_common
/* No return */
-- 
2.1.4

[PATCH v6 10/11] cpuidle/powernv: Add support for POWER ISA v3 idle states

[Shreyas B. Prabhu]

POWER ISA v3 defines a new idle processor core mechanism. In summary,
 a) new instruction named stop is added.
 b) new per thread SPR named PSSCR is added which controls the behavior
of stop instruction.

Supported idle states and value to be written to PSSCR register to enter
any idle state is exposed via ibm,cpu-idle-state-names and
ibm,cpu-idle-state-psscr respectively. To enter an idle state,
platform provided power_stop() needs to be invoked with the appropriate
PSSCR value.

This patch adds support for this new mechanism in cpuidle powernv driver.

Cc: Rafael J. Wysocki 
Cc: Daniel Lezcano 
Cc: Rob Herring 
Cc: Lorenzo Pieralisi 
Cc: linux...@vger.kernel.org
Cc: Michael Ellerman 
Cc: Paul Mackerras 
Cc: linuxppc-...@lists.ozlabs.org
Reviewed-by: Gautham R. Shenoy 
Signed-off-by: Shreyas B. Prabhu 
---
Note: Documentation for the device tree bindings is posted here-
http://patchwork.ozlabs.org/patch/629125/

 - No changes in v6

Changes in v5
=
 - Use generic cpuidle constant CPUIDLE_NAME_LEN
 - Fix return code handling for of_property_read_string_array
 - Use DT flags to determine if are using stop instruction, instead of
   cpu_has_feature
 - Removed uncessary cast with names
 - _loop -> stop_loop
 - Added POWERNV_THRESHOLD_LATENCY_NS to filter out idle states with high 
latency

 drivers/cpuidle/cpuidle-powernv.c | 71 ++-
 1 file changed, 70 insertions(+), 1 deletion(-)

diff --git a/drivers/cpuidle/cpuidle-powernv.c 
b/drivers/cpuidle/cpuidle-powernv.c
index 3a763a8..c74a020 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -20,6 +20,8 @@
 #include 
 #include 
 
+#define POWERNV_THRESHOLD_LATENCY_NS 20
+
 struct cpuidle_driver powernv_idle_driver = {
.name = "powernv_idle",
.owner= THIS_MODULE,
@@ -27,6 +29,9 @@ struct cpuidle_driver powernv_idle_driver = {
 
 static int max_idle_state;
 static struct cpuidle_state *cpuidle_state_table;
+
+static u64 stop_psscr_table[CPUIDLE_STATE_MAX];
+
 static u64 snooze_timeout;
 static bool snooze_timeout_en;
 
@@ -91,6 +96,17 @@ static int fastsleep_loop(struct cpuidle_device *dev,
return index;
 }
 #endif
+
+static int stop_loop(struct cpuidle_device *dev,
+struct cpuidle_driver *drv,
+int index)
+{
+   ppc64_runlatch_off();
+   power_stop(stop_psscr_table[index]);
+   ppc64_runlatch_on();
+   return index;
+}
+
 /*
  * States for dedicated partition case.
  */
@@ -167,6 +183,8 @@ static int powernv_add_idle_states(void)
int nr_idle_states = 1; /* Snooze */
int dt_idle_states;
u32 *latency_ns, *residency_ns, *flags;
+   u64 *psscr_val = NULL;
+   const char *names[CPUIDLE_STATE_MAX];
int i, rc;
 
/* Currently we have snooze statically defined */
@@ -199,12 +217,41 @@ static int powernv_add_idle_states(void)
goto out_free_latency;
}
 
+   rc = of_property_read_string_array(power_mgt,
+  "ibm,cpu-idle-state-names", names,
+  dt_idle_states);
+   if (rc < 0) {
+   pr_warn("cpuidle-powernv: missing ibm,cpu-idle-state-names in 
DT\n");
+   goto out_free_latency;
+   }
+
+   /*
+* If the idle states use stop instruction, probe for psscr values
+* which are necessary to specify required stop level.
+*/
+   if (flags[0] & (OPAL_PM_STOP_INST_FAST | OPAL_PM_STOP_INST_DEEP)) {
+   psscr_val = kcalloc(dt_idle_states, sizeof(*psscr_val),
+   GFP_KERNEL);
+   rc = of_property_read_u64_array(power_mgt,
+   "ibm,cpu-idle-state-psscr",
+   psscr_val, dt_idle_states);
+   if (rc) {
+   pr_warn("cpuidle-powernv: missing 
ibm,cpu-idle-states-psscr in DT\n");
+   goto out_free_psscr;
+   }
+   }
residency_ns = kzalloc(sizeof(*residency_ns) * dt_idle_states, 
GFP_KERNEL);
rc = of_property_read_u32_array(power_mgt,
"ibm,cpu-idle-state-residency-ns", residency_ns, 
dt_idle_states);
 
for (i = 0; i < dt_idle_states; i++) {
-
+   /*
+* If an idle state has exit latency beyond
+* POWERNV_THRESHOLD_LATENCY_NS then don't use it
+* in cpu-idle.
+*/
+   if (latency_ns[i] > POWERNV_THRESHOLD_LATENCY_NS)
+   continue;
/*
 * Cpuidle accepts exit_latency and target_residency in us.
 

[PATCH v6 06/11] powerpc/powernv: abstraction for saving SPRs before entering deep idle states

[Shreyas B. Prabhu]

Create a function for saving SPRs before entering deep idle states.
This function can be reused for POWER9 deep idle states.

Reviewed-by: Gautham R. Shenoy 
Signed-off-by: Shreyas B. Prabhu 
---
 - No changes since v3

Changes in v3:
=
 - Newly added in v3

 arch/powerpc/kernel/idle_power_common.S | 54 +++--
 1 file changed, 32 insertions(+), 22 deletions(-)

diff --git a/arch/powerpc/kernel/idle_power_common.S 
b/arch/powerpc/kernel/idle_power_common.S
index a8397e3..2f909a1 100644
--- a/arch/powerpc/kernel/idle_power_common.S
+++ b/arch/powerpc/kernel/idle_power_common.S
@@ -53,6 +53,36 @@
.text
 
 /*
+ * Used by threads before entering deep idle states. Saves SPRs
+ * in interrupt stack frame
+ */
+save_sprs_to_stack:
+   /*
+* Note all register i.e per-core, per-subcore or per-thread is saved
+* here since any thread in the core might wake up first
+*/
+   mfspr   r3,SPRN_SDR1
+   std r3,_SDR1(r1)
+   mfspr   r3,SPRN_RPR
+   std r3,_RPR(r1)
+   mfspr   r3,SPRN_SPURR
+   std r3,_SPURR(r1)
+   mfspr   r3,SPRN_PURR
+   std r3,_PURR(r1)
+   mfspr   r3,SPRN_TSCR
+   std r3,_TSCR(r1)
+   mfspr   r3,SPRN_DSCR
+   std r3,_DSCR(r1)
+   mfspr   r3,SPRN_AMOR
+   std r3,_AMOR(r1)
+   mfspr   r3,SPRN_WORT
+   std r3,_WORT(r1)
+   mfspr   r3,SPRN_WORC
+   std r3,_WORC(r1)
+
+   blr
+
+/*
  * Used by threads when the lock bit of core_idle_state is set.
  * Threads will spin in HMT_LOW until the lock bit is cleared.
  * r14 - pointer to core_idle_state
@@ -209,28 +239,8 @@ fastsleep_workaround_at_entry:
b   common_enter
 
 enter_winkle:
-   /*
-* Note all register i.e per-core, per-subcore or per-thread is saved
-* here since any thread in the core might wake up first
-*/
-   mfspr   r3,SPRN_SDR1
-   std r3,_SDR1(r1)
-   mfspr   r3,SPRN_RPR
-   std r3,_RPR(r1)
-   mfspr   r3,SPRN_SPURR
-   std r3,_SPURR(r1)
-   mfspr   r3,SPRN_PURR
-   std r3,_PURR(r1)
-   mfspr   r3,SPRN_TSCR
-   std r3,_TSCR(r1)
-   mfspr   r3,SPRN_DSCR
-   std r3,_DSCR(r1)
-   mfspr   r3,SPRN_AMOR
-   std r3,_AMOR(r1)
-   mfspr   r3,SPRN_WORT
-   std r3,_WORT(r1)
-   mfspr   r3,SPRN_WORC
-   std r3,_WORC(r1)
+   bl  save_sprs_to_stack
+
IDLE_STATE_ENTER_SEQ(PPC_WINKLE)
 
 _GLOBAL(power7_idle)
-- 
2.1.4

Re: [RFC PATCH] regulator: introduce boot protection flag

[Mark Brown]

On Mon, May 09, 2016 at 03:05:08PM +0800, WEN Pingbo wrote:

> In some platforms, critical shared regulator is initialized in
> bootloader. But during kernel booting, the driver probing order and
> conflicting operations from other regulator consumers, may set the
> regulator in a undefined state, which will cause serious problem.

> This patch try to add a boot_protection flag in regulator constraints.

This still feels like a short term hack that doesn't belong in an ABI.
It's all very implementation specific and not very robust, it's not
describing the outcome we're looking for but rather a very specific
behaviour which won't work outside of a fairly narrow system
configuration.  The difficulty in coherently explaining what the end of
boot is and what protection means is a big warning sign here.

I think you need to be looking at some combination of getting the
devices you're interested in started up early and more precisely
describing the end result you're trying to achieve.  The issues with
probe deferral do seem related here, it's another symptom of not really
making any decisions about init ordering and so sometimes making bad
ones.

> And regulator core will postpone all operations until all consumers
> have taked their place.

It doesn't, it postpones them until late_initacall().  This is both
after the consumers have loaded if they are built in and before any
consumers built as modules come up.

> The boot_protection flag only work before late_initicall. And as other
> constraints liked, you can specify this flag in a board file, or in
> dts file.

Anything added to the DT ABI needs a binding.

> + /* constraints check has already done */
> + if (rdev->boot_mode)
> + rdev->desc->ops->set_mode(rdev, rdev->boot_mode);

This whole sequence of code ignores errors - that's not great.  We
should at least log them.

> + mutex_unlock(>mutex);
> +
> + if (regulator)
> + regulator_set_voltage(regulator, regulator->min_uV,
> + regulator->max_uV);

That's...  exciting.  There's a couple of issues here.  One is that
this is not operating on the rdev but rather on a consumer regulator
device, the other is that we drop out of the lock before doing the
update which tends to be a warning sign that something fun is going on
and at least an internal function should be used.  These two most likely
come down to the same issue.


signature.asc
Description: PGP signature

Re: [RFC][PATCH 0/5] Functional dependencies between devices

[Rafael J. Wysocki]

On Wed, Jun 8, 2016 at 2:15 PM, Mark Brown  wrote:
> On Thu, Jan 14, 2016 at 02:52:11AM +0100, Rafael J. Wysocki wrote:
>
>> What follows is my prototype implementation of this.  It took some time
>> to develop (much more than I was hoping for), but here it goes at last.
>
> Might be worth posting this outside the thread with CCs to people
> working on system integration like SoC maintainers - I'd completely
> missed this as it was buried and looked like the middle of an old
> discussion.

OK

I can resend it afresh, but need to do some rework due to some changes
that happened in the meantime.

Re: [PATCH] zram: add zpool support

[Dan Streetman]

On Wed, Jun 8, 2016 at 5:39 AM, Geliang Tang  wrote:
> This patch adds zpool support for zram, it will allow us to use both
> the zpool api and directly zsmalloc api in zram.

besides the problems below, this was discussed a while ago and I
believe Minchan is still against it, as nobody has so far shown what
the benefit to zram would be; zram doesn't need the predictability, or
evictability, of zbud or z3fold.

>
> Signed-off-by: Geliang Tang 
> ---
>  drivers/block/zram/zram_drv.c | 97 
> +++
>  drivers/block/zram/zram_drv.h |  5 +++
>  2 files changed, 102 insertions(+)
>
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 9e2a83c..1f90bd0 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -43,6 +43,11 @@ static const char *default_compressor = "lzo";
>  /* Module params (documentation at end) */
>  static unsigned int num_devices = 1;
>
> +#ifdef CONFIG_ZPOOL
> +/* Compressed storage zpool to use */
> +#define ZRAM_ZPOOL_DEFAULT "zsmalloc"
> +#endif

It doesn't make sense for zram to conditionally use zpool; either it
uses it and thus has 'select ZPOOL' in its Kconfig entry, or it
doesn't use it at all.

> +
>  static inline void deprecated_attr_warn(const char *name)
>  {
> pr_warn_once("%d (%s) Attribute %s (and others) will be removed. 
> %s\n",
> @@ -228,7 +233,11 @@ static ssize_t mem_used_total_show(struct device *dev,
> down_read(>init_lock);
> if (init_done(zram)) {
> struct zram_meta *meta = zram->meta;
> +#ifdef CONFIG_ZPOOL
> +   val = zpool_get_total_size(meta->mem_pool) >> PAGE_SHIFT;
> +#else
> val = zs_get_total_pages(meta->mem_pool);
> +#endif
> }
> up_read(>init_lock);
>
> @@ -296,8 +305,14 @@ static ssize_t mem_used_max_store(struct device *dev,
> down_read(>init_lock);
> if (init_done(zram)) {
> struct zram_meta *meta = zram->meta;
> +#ifdef CONFIG_ZPOOL
> +   atomic_long_set(>stats.max_used_pages,
> +   zpool_get_total_size(meta->mem_pool)
> +   >> PAGE_SHIFT);
> +#else
> atomic_long_set(>stats.max_used_pages,
> zs_get_total_pages(meta->mem_pool));
> +#endif
> }
> up_read(>init_lock);
>
> @@ -366,6 +381,18 @@ static ssize_t comp_algorithm_store(struct device *dev,
> return len;
>  }
>
> +#ifdef CONFIG_ZPOOL
> +static void zpool_compact(void *pool)
> +{
> +   zs_compact(pool);
> +}
> +
> +static void zpool_stats(void *pool, struct zs_pool_stats *stats)
> +{
> +   zs_pool_stats(pool, stats);
> +}
> +#endif

first, no.  this obviously makes using zpool in zram completely pointless.

second, did you test this?  the pool you're passing is the zpool, not
the zs_pool.  quite bad things will happen when this code runs.  There
is no way to get the zs_pool from the zpool object (that's the point
of abstraction, of course).

The fact zpool doesn't have these apis (currently) is one of the
reasons against changing zram to use zpool.

> +
>  static ssize_t compact_store(struct device *dev,
> struct device_attribute *attr, const char *buf, size_t len)
>  {
> @@ -379,7 +406,11 @@ static ssize_t compact_store(struct device *dev,
> }
>
> meta = zram->meta;
> +#ifdef CONFIG_ZPOOL
> +   zpool_compact(meta->mem_pool);
> +#else
> zs_compact(meta->mem_pool);
> +#endif
> up_read(>init_lock);
>
> return len;
> @@ -416,8 +447,14 @@ static ssize_t mm_stat_show(struct device *dev,
>
> down_read(>init_lock);
> if (init_done(zram)) {
> +#ifdef CONFIG_ZPOOL
> +   mem_used = zpool_get_total_size(zram->meta->mem_pool)
> +   >> PAGE_SHIFT;
> +   zpool_stats(zram->meta->mem_pool, _stats);
> +#else
> mem_used = zs_get_total_pages(zram->meta->mem_pool);
> zs_pool_stats(zram->meta->mem_pool, _stats);
> +#endif
> }
>
> orig_size = atomic64_read(>stats.pages_stored);
> @@ -490,10 +527,18 @@ static void zram_meta_free(struct zram_meta *meta, u64 
> disksize)
> if (!handle)
> continue;
>
> +#ifdef CONFIG_ZPOOL
> +   zpool_free(meta->mem_pool, handle);
> +#else
> zs_free(meta->mem_pool, handle);
> +#endif
> }
>
> +#ifdef CONFIG_ZPOOL
> +   zpool_destroy_pool(meta->mem_pool);
> +#else
> zs_destroy_pool(meta->mem_pool);
> +#endif
> vfree(meta->table);
> kfree(meta);
>  }
> @@ -513,7 +558,17 @@ static struct zram_meta *zram_meta_alloc(char 
> *pool_name, u64 disksize)
> goto out_error;
> }
>
> +#ifdef CONFIG_ZPOOL
> +   if (!zpool_has_pool(ZRAM_ZPOOL_DEFAULT)) {
> +   pr_err("zpool %s not 

Re: [RESEND PATCH] iommu/rockchip: fix zap cache during device attach

[Heiko Stübner]

Hi Joerg,

Am Mittwoch, 1. Juni 2016, 16:46:10 schrieb John Keeping:
> rk_iommu_command() takes a struct rk_iommu and iterates over the slave
> MMUs, so this is doubly wrong in that we're passing in the wrong pointer
> and talking to MMUs that we shouldn't be.
> 
> Fixes: cd6438c5f844 ("iommu/rockchip: Reconstruct to support multi slaves")
> Cc: sta...@vger.kernel.org
> Signed-off-by: John Keeping 
> Tested-by: Heiko Stuebner 
> Reviewed-by: Heiko Stuebner 

this definitly looks like material for 4.7-rc fixes to me. Could you take a 
look 
and maybe include it?


Thanks
Heiko

> ---
> The original was sent just before the merge window [0].  The only
> changes are to the commit message:
> 
> * add Cc: stable
> * add Heiko's {Tested,Reviewed}-by
> 
> [0] http://article.gmane.org/gmane.linux.kernel.iommu/13556
> 
>  drivers/iommu/rockchip-iommu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
> index c7d6156ff536..25b4627cb57f 100644
> --- a/drivers/iommu/rockchip-iommu.c
> +++ b/drivers/iommu/rockchip-iommu.c
> @@ -815,7 +815,7 @@ static int rk_iommu_attach_device(struct iommu_domain
> *domain, dte_addr = virt_to_phys(rk_domain->dt);
>   for (i = 0; i < iommu->num_mmu; i++) {
>   rk_iommu_write(iommu->bases[i], RK_MMU_DTE_ADDR, dte_addr);
> - rk_iommu_command(iommu->bases[i], RK_MMU_CMD_ZAP_CACHE);
> + rk_iommu_base_command(iommu->bases[i], RK_MMU_CMD_ZAP_CACHE);
>   rk_iommu_write(iommu->bases[i], RK_MMU_INT_MASK, 
> RK_MMU_IRQ_MASK);
>   }

Re: [PATCH 2/2] gpio: Support cascaded GPIO chip lookup for OF

[Pantelis Antoniou]

Hi Rob,

> On Jun 8, 2016, at 18:18 , Rob Herring  wrote:
> 
> On Wed, Jun 8, 2016 at 8:41 AM, Pantelis Antoniou
>  wrote:
>> Hi Rob,
>> 
>>> On Jun 8, 2016, at 00:00 , Rob Herring  wrote:
>>> 
>>> +Mark R
>>> 
>>> On Fri, Jun 3, 2016 at 3:26 PM, Pantelis Antoniou
>>>  wrote:
 In certain cases it makes sense to create cascaded GPIO which
 are not real GPIOs, merely point to the real backend GPIO chip.
>>> 
>>> In what cases? Make it clear what this is for. Connectors of course,
>>> but are there any other use cases you have in mind.
>>> 
>> 
>> Connectors is one obvious use-case. In fact even when there is no
>> connector but there is an obvious interface abstraction point you
>> might want to use it.
>> 
>> For instance a SoC package may have a number of different GPIO
>> controllers (that may or may not use the same IP block). You could
>> abstract all the gpio controllers away in a single GPIO controller
>> block.
> 
> There had better be some good reason besides just wanting to make a
> single virtual controller.
> 

The reason is to forward a gpio reference to a real h/w gpio device
while not having to expose said real gpio device details. 

 In order to support this, cascaded of_xlate lookup need to be
 performed.
 
 For example let's take a connector that we want to abstract
 having two GPIO pins from different GPIO controllers, connector
 pin #0 connected to gpioA controller with offset 10 and gpioB
 with 4.
>>> 
>>> A connector's GPIO number may or may not be related to connector pins.
>>> 
>> 
>> Obviously, this is just an example.
>> 
 In pseudo DT form this is analogous to:
 
   gpioA: gpioa@8 {
   compatible = "foocorp,gpio";
   ...
   };
 
   gpioB: gpiob@80800 {
   compatible = "foocorp,gpio";
   
   };
 
   gpioC: controller_gpio {
   compatible = "cascaded-gpio";
>>> 
>>> This compatible is kind of meaningless. I'd expect this to be a
>>> connector compatible.
>>> 
>> 
>> No, because this gpio patch is completely independent of the
>> existence of a connector.
> 
> My point is that "cascaded-gpio" is not something used to parse the
> binding and will never be an accepted compatible string. I know it is
> an example, but you should make that obvious like foocorp is.
> 

It doesn’t parse the binding; the xlate method of a driver does.  

   gpios = < 10>, < 5>;
>>> 
>>> As we discussed at ELC, I think this should be modeled after
>>> interrupt-map property like this:
>>> 
>>> gpio-map = <0 0 _gpio 10 0>, <1 0 _gpio 5 0>;
>>> gpio-map-mask = <0xff 0>;
>>> 
>>> This is more flexible, a known pattern, and allows remapping of flag cells.
>>> 
>> 
>> It’s just syntactic sugar. It can work either way.
>> 
>>> Also, we will likely have interrupt capable GPIOs, so they are going
>>> to need interrupt-map anyway.
>>> 
>> 
>> Devices that use interrupts usually convert the GPIO to an interrupt and use 
>> it.
>> Since the xlat op will return the real GPIO spec the interrupt conversion 
>> will work.
>> 
>> Bare interrupt lines are sort-of out of fashion nowadays I think. I’m eager 
>> to be
>> proven wrong though with a recent portable expansion board that uses them.
> 
> Uh, no! Practically every gpio controller is also an interrupt
> controller (in DT) and devices pretty much always see just an
> interrupt line. Just go look at all the I2C devices with an interrupt
> line. Unless devices have some special needs to control the gpio, we
> always use interrupts. Expansion boards may be dealing with the GPIO
> simply because that is the only option for userspace drivers.
> 

Looking into a list of 54 capes for the beaglebone I can only find a single
one that uses an interrupt instead of a gpio, and that can easily be converted
to using the gpio.

The IRQ forwarding case is easier than the GPIO one TBH. The IRQ parsing core
can handle complex cases so adding a new one won’t be a big deal. 

> Rob

Regards

— Pantelis

[PATCH v2 5/5] mfd: ti_am335x_tscadc: use variable name for sizeof() operator

[Andrew F. Davis]

Fix the code formatting to use the kernel preferred style
of using the actual variables to determine the size using
the sizeof() operator.

Signed-off-by: Andrew F. Davis 
Acked-by: Lee Jones 
---
 drivers/mfd/ti_am335x_tscadc.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index d30bea5..c8f027b 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -168,8 +168,7 @@ static  int ti_tscadc_probe(struct platform_device 
*pdev)
}
 
/* Allocate memory for device */
-   tscadc = devm_kzalloc(>dev,
-   sizeof(struct ti_tscadc_dev), GFP_KERNEL);
+   tscadc = devm_kzalloc(>dev, sizeof(*tscadc), GFP_KERNEL);
if (!tscadc) {
dev_err(>dev, "failed to allocate memory.\n");
return -ENOMEM;
-- 
2.8.3

[PATCH v2 2/5] mfd: ti_am335x_tscadc: Remove use of single line functions

[Andrew F. Davis]

tscadc_readl and tscadc_writel are single line functions and do not save
use anything, remove these.

Signed-off-by: Andrew F. Davis 
Acked-by: Lee Jones 
---
 drivers/mfd/ti_am335x_tscadc.c | 44 ++
 1 file changed, 15 insertions(+), 29 deletions(-)

diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index 644128b..613f15d 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -27,20 +27,6 @@
 
 #include 
 
-static unsigned int tscadc_readl(struct ti_tscadc_dev *tsadc, unsigned int reg)
-{
-   unsigned int val;
-
-   regmap_read(tsadc->regmap_tscadc, reg, );
-   return val;
-}
-
-static void tscadc_writel(struct ti_tscadc_dev *tsadc, unsigned int reg,
-   unsigned int val)
-{
-   regmap_write(tsadc->regmap_tscadc, reg, val);
-}
-
 static const struct regmap_config tscadc_regmap_config = {
.name = "ti_tscadc",
.reg_bits = 32,
@@ -57,7 +43,7 @@ void am335x_tsc_se_set_cache(struct ti_tscadc_dev *tsadc, u32 
val)
if (tsadc->adc_waiting)
wake_up(>reg_se_wait);
else if (!tsadc->adc_in_use)
-   tscadc_writel(tsadc, REG_SE, tsadc->reg_se_cache);
+   regmap_write(tsadc->regmap_tscadc, REG_SE, tsadc->reg_se_cache);
 
spin_unlock_irqrestore(>reg_lock, flags);
 }
@@ -68,7 +54,7 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev 
*tsadc)
DEFINE_WAIT(wait);
u32 reg;
 
-   reg = tscadc_readl(tsadc, REG_ADCFSM);
+   regmap_read(tsadc->regmap_tscadc, REG_ADCFSM, );
if (reg & SEQ_STATUS) {
tsadc->adc_waiting = true;
prepare_to_wait(>reg_se_wait, ,
@@ -84,7 +70,7 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev 
*tsadc)
 * Sequencer should either be idle or
 * busy applying the charge step.
 */
-   reg = tscadc_readl(tsadc, REG_ADCFSM);
+   regmap_read(tsadc->regmap_tscadc, REG_ADCFSM, );
WARN_ON((reg & SEQ_STATUS) && !(reg & CHARGE_STEP));
tsadc->adc_waiting = false;
}
@@ -96,7 +82,7 @@ void am335x_tsc_se_set_once(struct ti_tscadc_dev *tsadc, u32 
val)
spin_lock_irq(>reg_lock);
am335x_tscadc_need_adc(tsadc);
 
-   tscadc_writel(tsadc, REG_SE, val);
+   regmap_write(tsadc->regmap_tscadc, REG_SE, val);
spin_unlock_irq(>reg_lock);
 }
 EXPORT_SYMBOL_GPL(am335x_tsc_se_set_once);
@@ -107,7 +93,7 @@ void am335x_tsc_se_adc_done(struct ti_tscadc_dev *tsadc)
 
spin_lock_irqsave(>reg_lock, flags);
tsadc->adc_in_use = false;
-   tscadc_writel(tsadc, REG_SE, tsadc->reg_se_cache);
+   regmap_write(tsadc->regmap_tscadc, REG_SE, tsadc->reg_se_cache);
spin_unlock_irqrestore(>reg_lock, flags);
 }
 EXPORT_SYMBOL_GPL(am335x_tsc_se_adc_done);
@@ -118,7 +104,7 @@ void am335x_tsc_se_clr(struct ti_tscadc_dev *tsadc, u32 val)
 
spin_lock_irqsave(>reg_lock, flags);
tsadc->reg_se_cache &= ~val;
-   tscadc_writel(tsadc, REG_SE, tsadc->reg_se_cache);
+   regmap_write(tsadc->regmap_tscadc, REG_SE, tsadc->reg_se_cache);
spin_unlock_irqrestore(>reg_lock, flags);
 }
 EXPORT_SYMBOL_GPL(am335x_tsc_se_clr);
@@ -130,7 +116,7 @@ static void tscadc_idle_config(struct ti_tscadc_dev *config)
idleconfig = STEPCONFIG_YNN | STEPCONFIG_INM_ADCREFM |
STEPCONFIG_INP_ADCREFM | STEPCONFIG_YPN;
 
-   tscadc_writel(config, REG_IDLECONFIG, idleconfig);
+   regmap_write(config->regmap_tscadc, REG_IDLECONFIG, idleconfig);
 }
 
 static int ti_tscadc_probe(struct platform_device *pdev)
@@ -236,11 +222,11 @@ staticint ti_tscadc_probe(struct platform_device 
*pdev)
 
/* TSCADC_CLKDIV needs to be configured to the value minus 1 */
tscadc->clk_div--;
-   tscadc_writel(tscadc, REG_CLKDIV, tscadc->clk_div);
+   regmap_write(tscadc->regmap_tscadc, REG_CLKDIV, tscadc->clk_div);
 
/* Set the control register bits */
ctrl = CNTRLREG_STEPCONFIGWRT | CNTRLREG_STEPID;
-   tscadc_writel(tscadc, REG_CTRL, ctrl);
+   regmap_write(tscadc->regmap_tscadc, REG_CTRL, ctrl);
 
/* Set register bits for Idle Config Mode */
if (tsc_wires > 0) {
@@ -254,7 +240,7 @@ static  int ti_tscadc_probe(struct platform_device 
*pdev)
 
/* Enable the TSC module enable bit */
ctrl |= CNTRLREG_TSCSSENB;
-   tscadc_writel(tscadc, REG_CTRL, ctrl);
+   regmap_write(tscadc->regmap_tscadc, REG_CTRL, ctrl);
 
tscadc->used_cells = 0;
tscadc->tsc_cell = -1;
@@ -300,7 +286,7 @@ static int ti_tscadc_remove(struct platform_device *pdev)
 {
struct ti_tscadc_dev*tscadc = platform_get_drvdata(pdev);
 
-   tscadc_writel(tscadc, REG_SE, 0x00);
+   regmap_write(tscadc->regmap_tscadc, REG_SE, 0x00);
 

Re: [PATCH 2/2] mfd: max77620: Add pre/post irq handler before/after servicing interrupt

[Laxman Dewangan]

Hi Lee,

On Wednesday 08 June 2016 08:11 PM, Lee Jones wrote:

On Fri, 20 May 2016, Laxman Dewangan wrote:


+ * MAX77620 and MAX20024 has the following steps of the interrupt handling
+ * for TOP interrupts:
+ * 1. When interrupt occurs from PMIC, mask the PMIC interrupt by setting 
GLBLM.
+ * 2. Read IRQTOP and service the interrupt.
+ * 3. Once all interrupts has been checked and serviced, the interrupt service
+ *routine un-masks the hardware interrupt line by clearing GLBLM.
+ */
+static int max77620_top_irq_chip_pre_irq_handler(void *irq_drv_data)
+{
+   struct max77620_chip *chip = irq_drv_data;
+   int ret;
+
+   ret = regmap_update_bits(chip->rmap, MAX77620_REG_INTENLBT,
+MAX77620_GLBLM_MASK, MAX77620_GLBLM_MASK);
+   if (ret < 0)
+   dev_err(chip->dev, "Failed to set GLBLM: %d\n", ret);
+
+   return ret;
+}
+
+static int max77620_top_irq_chip_post_irq_handler(void *irq_drv_data)
+{
+   struct max77620_chip *chip = irq_drv_data;
+   int ret;
+
+   ret = regmap_update_bits(chip->rmap, MAX77620_REG_INTENLBT,
+MAX77620_GLBLM_MASK, 0);
+   if (ret < 0)
+   dev_err(chip->dev, "Failed to reset GLBLM: %d\n", ret);
+
+   return ret;
+}

This seems massively over compacted.  All you're effectively doing
here is masking and unmasking the IRQs, which we do almost
ubiquitously with interrupt controllers.  Can't you just call the
functions "max77629_{un}mask_irqs()"?




Actually, per PMIC HW design, we need to toggle this bit on ISRs. Before 
reading the status, need to set 1 and then after handling it need to set 
0. This cannot be done by any other bit toggling or masking/unmasking 
interrupt controller interrupt.


This is hard requirement from the PMIC chip.

Re: [tip:perf/core] perf/x86/intel: Use Intel family macros for core perf events

[Ingo Molnar]

* Vince Weaver  wrote:

> eventually you can get them to send /proc/cpuinfo so you can try to find 
> out what processor they really have, and in that case you can get
> the family/model numbers in plain decimal, and you can easily look up
> if things are supported in the various files.

If only it was that simple! /proc/cpuinfo lists the model number in decimal, 
but 
half of all uses were in hexa, making grepping hard ...

So the real solution would be to print out the engineering model name in 
/proc/cpuinfo as well:

 processor   : 119
 vendor_id   : GenuineIntel
 cpu family  : 6
 model   : 62
 model name  : Intel(R) Xeon(R) CPU E7-4890 v2 @ 2.80GHz
 model string: IvyBridge_X

... or something like that. The string could even be auto-generated from the 
list 
in intel-family.h?

Thanks,

Ingo

[PATCH v2 13/13] regulator: pwm: Document pwm-dutycycle-unit and pwm-dutycycle-range

[Boris Brezillon]

Document the pwm-dutycycle-unit and pwm-dutycycle-range properties.

Signed-off-by: Boris Brezillon 
Acked-by: Brian Norris 
---
 .../devicetree/bindings/regulator/pwm-regulator.txt   | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt 
b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
index ed936f0..9fbc7b1 100644
--- a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
@@ -34,6 +34,18 @@ Only required for Voltage Table Mode:
First cell is voltage in microvolts (uV)
Second cell is duty-cycle in percent (%)
 
+Optional properties for Continuous mode:
+- pwm-dutycycle-unit:  Integer value encoding the duty cycle unit. If not
+   defined, <100> is assumed, meaning that
+   pwm-dutycycle-range contains values expressed in
+   percent.
+
+- pwm-dutycycle-range: Should contain 2 entries. The first entry is encoding
+   the dutycycle for regulator-min-microvolt and the
+   second one the dutycycle for regulator-max-microvolt.
+   Duty cycle values are expressed in pwm-dutycycle-unit.
+   If not defined, <0 100> is assumed.
+
 NB: To be clear, if voltage-table is provided, then the device will be used
 in Voltage Table Mode.  If no voltage-table is provided, then the device will
 be used in Continuous Voltage Mode.
@@ -48,6 +60,13 @@ Continuous Voltage Example:
regulator-min-microvolt = <1016000>;
regulator-max-microvolt = <1114000>;
regulator-name = "vdd_logic";
+   /* unit == per-mille */
+   pwm-dutycycle-unit = <1000>;
+   /*
+* Inverted PWM logic, and the duty cycle range is limited
+* to 30%-70%.
+*/
+   pwm-dutycycle-range <700 300>; /* */
};
 
 Voltage Table Example:
-- 
2.7.4

[PATCH v2 12/13] regulator: pwm: Support extra continuous mode cases

[Boris Brezillon]

The continuous mode allows one to declare a PWM regulator without having
to declare the voltage <-> dutycycle association table. It works fine as
long as your voltage(dutycycle) function is linear, but also has the
following constraints:

- dutycycle for min_uV = 0%
- dutycycle for max_uV = 100%
- dutycycle for min_uV < dutycycle for max_uV

While the linearity constraint is acceptable for now, we sometimes need to
restrict of the PWM range (to limit the maximum/minimum voltage for
example) or have a min_uV_dutycycle > max_uV_dutycycle (this could be
tweaked with PWM polarity, but not all PWMs support inverted polarity).

Add the pwm-dutycycle-range and pwm-dutycycle-unit DT properties to define
such constraints. If those properties are not defined, the PWM regulator
use the default pwm-dutycycle-range = <0 100> and
pwm-dutycycle-unit = <100> values (existing behavior).

Signed-off-by: Boris Brezillon 
Reviewed-by: Brian Norris 
Tested-by: Brian Norris 
---
 drivers/regulator/pwm-regulator.c | 92 +++
 1 file changed, 83 insertions(+), 9 deletions(-)

diff --git a/drivers/regulator/pwm-regulator.c 
b/drivers/regulator/pwm-regulator.c
index c39ecd1..3e8680a 100644
--- a/drivers/regulator/pwm-regulator.c
+++ b/drivers/regulator/pwm-regulator.c
@@ -21,6 +21,12 @@
 #include 
 #include 
 
+struct pwm_continuous_reg_data {
+   unsigned int min_uV_dutycycle;
+   unsigned int max_uV_dutycycle;
+   unsigned int dutycycle_unit;
+};
+
 struct pwm_regulator_data {
/*  Shared */
struct pwm_device *pwm;
@@ -28,6 +34,9 @@ struct pwm_regulator_data {
/* Voltage table */
struct pwm_voltages *duty_cycle_table;
 
+   /* Continuous mode info */
+   struct pwm_continuous_reg_data continuous;
+
/* regulator descriptor */
struct regulator_desc desc;
 
@@ -132,31 +141,79 @@ static int pwm_regulator_is_enabled(struct regulator_dev 
*dev)
 static int pwm_regulator_get_voltage(struct regulator_dev *rdev)
 {
struct pwm_regulator_data *drvdata = rdev_get_drvdata(rdev);
+   unsigned int min_uV_duty = drvdata->continuous.min_uV_dutycycle;
+   unsigned int max_uV_duty = drvdata->continuous.max_uV_dutycycle;
+   unsigned int duty_unit = drvdata->continuous.dutycycle_unit;
int min_uV = rdev->constraints->min_uV;
-   int diff = rdev->constraints->max_uV - min_uV;
+   int max_uV = rdev->constraints->max_uV;
+   int diff_uV = max_uV - min_uV;
struct pwm_state pstate;
+   unsigned int diff_duty;
+   unsigned int voltage;
 
pwm_get_state(drvdata->pwm, );
 
-   return min_uV + pwm_get_relative_duty_cycle(, diff);
+   voltage = pwm_get_relative_duty_cycle(, duty_unit);
+
+   /*
+* The dutycycle for the min_uV voltage might be greater than the
+* one for the max_uV. This is happening when the user needs an
+* inversed polarity, but the PWM device does not support inversing
+* it in hardware.
+*/
+   if (max_uV_duty < min_uV_duty) {
+   voltage = min_uV_duty - voltage;
+   diff_duty = min_uV_duty - max_uV_duty;
+   } else {
+   voltage = voltage - min_uV_duty;
+   diff_duty = max_uV_duty - min_uV_duty;
+   }
+
+   voltage = DIV_ROUND_CLOSEST_ULL((u64)voltage * diff_uV, diff_duty);
+
+   return voltage + min_uV;
 }
 
 static int pwm_regulator_set_voltage(struct regulator_dev *rdev,
-   int min_uV, int max_uV,
-   unsigned *selector)
+int req_min_uV, int req_max_uV,
+unsigned int *selector)
 {
struct pwm_regulator_data *drvdata = rdev_get_drvdata(rdev);
+   unsigned int min_uV_duty = drvdata->continuous.min_uV_dutycycle;
+   unsigned int max_uV_duty = drvdata->continuous.max_uV_dutycycle;
+   unsigned int duty_unit = drvdata->continuous.dutycycle_unit;
unsigned int ramp_delay = rdev->constraints->ramp_delay;
-   unsigned int req_diff = min_uV - rdev->constraints->min_uV;
+   int min_uV = rdev->constraints->min_uV;
+   int max_uV = rdev->constraints->max_uV;
+   int diff_uV = max_uV - min_uV;
struct pwm_state pstate;
-   unsigned int diff;
+   unsigned int diff_duty;
+   unsigned int dutycycle;
int ret;
 
pwm_prepare_new_state(drvdata->pwm, );
-   diff = rdev->constraints->max_uV - rdev->constraints->min_uV;
 
-   /* We pass diff as the scale to get a uV precision. */
-   pwm_set_relative_duty_cycle(, req_diff, diff);
+   /*
+* The dutycycle for the min_uV voltage might be greater than the
+* one for the max_uV. This is happening when the user needs an
+* inversed polarity, but the PWM device does not support inversing
+

[PATCH v2 11/13] regulator: pwm: Retrieve correct voltage

[Boris Brezillon]

The continuous PWM voltage regulator is caching the voltage value in
the ->volt_uV field. While most of the time this value should reflect the
real voltage, sometime it can be sightly different if the PWM device
rounded the set_duty_cycle request.
Moreover, this value is not valid until someone has modified the regulator
output.

Remove the ->volt_uV field and always rely on the PWM state to calculate
the regulator output.

Signed-off-by: Boris Brezillon 
Reviewed-by: Brian Norris 
Tested-by: Brian Norris 
---
Mark,

I know you already added your Tested-by/Acked-by tags on this patch
but this version has slightly change and is now making use of the
pwm_get_relative_duty_cycle() helper instead of manually converting
the absolute duty_cycle value into a relative one.
---
 drivers/regulator/pwm-regulator.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/regulator/pwm-regulator.c 
b/drivers/regulator/pwm-regulator.c
index 8c56e16..c39ecd1 100644
--- a/drivers/regulator/pwm-regulator.c
+++ b/drivers/regulator/pwm-regulator.c
@@ -35,9 +35,6 @@ struct pwm_regulator_data {
struct regulator_ops ops;
 
int state;
-
-   /* Continuous voltage */
-   int volt_uV;
 };
 
 struct pwm_voltages {
@@ -135,8 +132,13 @@ static int pwm_regulator_is_enabled(struct regulator_dev 
*dev)
 static int pwm_regulator_get_voltage(struct regulator_dev *rdev)
 {
struct pwm_regulator_data *drvdata = rdev_get_drvdata(rdev);
+   int min_uV = rdev->constraints->min_uV;
+   int diff = rdev->constraints->max_uV - min_uV;
+   struct pwm_state pstate;
 
-   return drvdata->volt_uV;
+   pwm_get_state(drvdata->pwm, );
+
+   return min_uV + pwm_get_relative_duty_cycle(, diff);
 }
 
 static int pwm_regulator_set_voltage(struct regulator_dev *rdev,
@@ -162,8 +164,6 @@ static int pwm_regulator_set_voltage(struct regulator_dev 
*rdev,
return ret;
}
 
-   drvdata->volt_uV = min_uV;
-
/* Delay required by PWM regulator to settle to the new voltage */
usleep_range(ramp_delay, ramp_delay + 1000);
 
-- 
2.7.4

[PATCH v2 02/13] pwm: rockchip: Fix period and duty_cycle approximation

[Boris Brezillon]

The current implementation always round down the duty and period
values, while it would be better to round them to the closest integer.

These changes are needed in preparation of atomic update support to
prevent a period/duty cycle drift when executing several time the
'pwm_get_state() / modify / pwm_apply_state()' sequence.

Say you have an expected period of 3.333 us and a clk rate of
112.67 MHz -- the clock frequency doesn't divide evenly,
so the period (stashed in nanoseconds) shrinks when we convert to
the register value and back, as follows:

  pwm_apply_state(): register = period * 11267 / 10;
  pwm_get_state(): period = register * 10 / 11267;

or in other words:

  period = period * 11267 / 10 * 10 / 11267;

which yields a sequence like:

   -> 3328
  3328 -> 3319
  3319 -> 3310
  3310 -> 3301
  3301 -> 3292
  3292 -> ... (etc) ...

With this patch, we'd see instead:

  period = div_round_closest(period * 11267, 10) *
   10 / 11267;

which yields a stable sequence:

   -> 3337
  3337 -> 3337
  3337 -> ... (etc) ...

Signed-off-by: Boris Brezillon 
Reviewed-by: Brian Norris 
Tested-by: Brian Norris 
---
 drivers/pwm/pwm-rockchip.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/pwm/pwm-rockchip.c b/drivers/pwm/pwm-rockchip.c
index 7d9cc90..68d72ce 100644
--- a/drivers/pwm/pwm-rockchip.c
+++ b/drivers/pwm/pwm-rockchip.c
@@ -114,12 +114,11 @@ static int rockchip_pwm_config(struct pwm_chip *chip, 
struct pwm_device *pwm,
 * default prescaler value for all practical clock rate values.
 */
div = clk_rate * period_ns;
-   do_div(div, pc->data->prescaler * NSEC_PER_SEC);
-   period = div;
+   period = DIV_ROUND_CLOSEST_ULL(div,
+  pc->data->prescaler * NSEC_PER_SEC);
 
div = clk_rate * duty_ns;
-   do_div(div, pc->data->prescaler * NSEC_PER_SEC);
-   duty = div;
+   duty = DIV_ROUND_CLOSEST_ULL(div, pc->data->prescaler * NSEC_PER_SEC);
 
ret = clk_enable(pc->clk);
if (ret)
-- 
2.7.4

Re: [PATCH 17/23] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32

[Yury Norov]

On Wed, Jun 08, 2016 at 09:34:09AM +0800, zhouchengming wrote:
> On 2016/5/24 8:04, Yury Norov wrote:
> >Here new aarch32 ptrace syscall handler is introsuced to avoid run-time
> >detection of the task type.
> >
> >Signed-off-by: Yury Norov

[...]

> Hello, I found ilp32 will use sys_ptrace, not compat_sys_ptrace. So I write
> a little patch to see if can solve the problem correctly.
> 
> Thanks.
> 
> From f6156236df578bb05c4a17e7f9776ceaf8f7afe6 Mon Sep 17 00:00:00 2001
> From: Zhou Chengming 
> Date: Wed, 8 Jun 2016 09:46:23 +0800
> Subject: [PATCH] ilp32: use compat_sys_ptrace instead of sys_ptrace
> 
> When we analyze a testcase of ptrace that failed on ilp32, we found
> the syscall that the ilp32 uses is sys_ptrace, not compat_sys_ptrace.
> Because in include/uapi/asm-generic/unistd.h it's defined like:
> __SYSCALL(__NR_ptrace, sys_ptrace)
> So we change it to __SC_COMP(__NR_ptrace, sys_ptrace, compat_sys_ptrace),
> let compat tasks use the compat_sys_ptrace.
> 
> Signed-off-by: Zhou Chengming 
> ---
>  include/uapi/asm-generic/unistd.h |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/include/uapi/asm-generic/unistd.h
> b/include/uapi/asm-generic/unistd.h
> index 2862d2e..50ee770 100644
> --- a/include/uapi/asm-generic/unistd.h
> +++ b/include/uapi/asm-generic/unistd.h
> @@ -364,7 +364,7 @@ __SC_WRAP(__NR_syslog, sys_syslog)
> 
>  /* kernel/ptrace.c */
>  #define __NR_ptrace 117
> -__SYSCALL(__NR_ptrace, sys_ptrace)
> +__SC_COMP(__NR_ptrace, sys_ptrace, compat_sys_ptrace)
> 
>  /* kernel/sched/core.c */
>  #define __NR_sched_setparam 118
> -- 
> 1.7.7
> 

Hi Zhou,

Thank you for the catch.

Could you also show the test that is failed for you. It should
probably be sent to LTP maillist.

I'm not sure your fix correct as it affects other architectures that
use standard unistd.h. I think it's better to redirect the syscall in
arch/arm64/kernel/sys_ilp32.c with corresponding definition.

Yury

Re: [PATCH 6/6] ppc: ebpf/jit: Implement JIT compiler for extended BPF

[Naveen N. Rao]

On 2016/06/07 03:56PM, Alexei Starovoitov wrote:
> On Tue, Jun 07, 2016 at 07:02:23PM +0530, Naveen N. Rao wrote:
> > PPC64 eBPF JIT compiler.
> > 
> > Enable with:
> > echo 1 > /proc/sys/net/core/bpf_jit_enable
> > or
> > echo 2 > /proc/sys/net/core/bpf_jit_enable
> > 
> > ... to see the generated JIT code. This can further be processed with
> > tools/net/bpf_jit_disasm.
> > 
> > With CONFIG_TEST_BPF=m and 'modprobe test_bpf':
> > test_bpf: Summary: 305 PASSED, 0 FAILED, [297/297 JIT'ed]
> > 
> > ... on both ppc64 BE and LE.
> 
> Nice. That's even better than on x64 which cannot jit one test:
> test_bpf: #262 BPF_MAXINSNS: Jump, gap, jump, ... jited:0 168 PASS
> which was designed specifically to hit x64 jit pass limit.
> ppc jit has predicatble number of passes and doesn't have this problem
> as expected. Great.

Yes, that's thanks to the clever handling of conditional branches by 
Matt -- we always emit 2 instructions for this reason (encoded in 
PPC_BCC() macro).

> 
> > The details of the approach are documented through various comments in
> > the code.
> > 
> > Cc: Matt Evans 
> > Cc: Denis Kirjanov 
> > Cc: Michael Ellerman 
> > Cc: Paul Mackerras 
> > Cc: Alexei Starovoitov 
> > Cc: Daniel Borkmann 
> > Cc: "David S. Miller" 
> > Cc: Ananth N Mavinakayanahalli 
> > Signed-off-by: Naveen N. Rao 
> > ---
> >  arch/powerpc/Kconfig  |   3 +-
> >  arch/powerpc/include/asm/asm-compat.h |   2 +
> >  arch/powerpc/include/asm/ppc-opcode.h |  20 +-
> >  arch/powerpc/net/Makefile |   4 +
> >  arch/powerpc/net/bpf_jit.h|  53 +-
> >  arch/powerpc/net/bpf_jit64.h  | 102 
> >  arch/powerpc/net/bpf_jit_asm64.S  | 180 +++
> >  arch/powerpc/net/bpf_jit_comp64.c | 956 
> > ++
> >  8 files changed, 1317 insertions(+), 3 deletions(-)
> >  create mode 100644 arch/powerpc/net/bpf_jit64.h
> >  create mode 100644 arch/powerpc/net/bpf_jit_asm64.S
> >  create mode 100644 arch/powerpc/net/bpf_jit_comp64.c
> 
> don't see any issues with the code.
> Thank you for working on this.
> 
> Acked-by: Alexei Starovoitov 

Thanks, Alexei!


Regards,
Naveen

[PATCH 5/7] f2fs: introduce force_lfs mount option

[Jaegeuk Kim]

This mount option is to enable original log-structured filesystem forcefully.
So, there should be no random writes for main area.

Especially, this supports host-managed SMR device.

Signed-off-by: Jaegeuk Kim 
---
 Documentation/filesystems/f2fs.txt |  3 +++
 fs/f2fs/data.c |  2 ++
 fs/f2fs/f2fs.h |  2 ++
 fs/f2fs/file.c |  8 +++-
 fs/f2fs/segment.c  | 20 +++-
 fs/f2fs/segment.h  |  7 +++
 fs/f2fs/super.c| 28 
 7 files changed, 68 insertions(+), 2 deletions(-)

diff --git a/Documentation/filesystems/f2fs.txt 
b/Documentation/filesystems/f2fs.txt
index e1c9f08..3a5ce24 100644
--- a/Documentation/filesystems/f2fs.txt
+++ b/Documentation/filesystems/f2fs.txt
@@ -151,6 +151,9 @@ noinline_data  Disable the inline data feature, 
inline data feature is
enabled by default.
 data_flush Enable data flushing before checkpoint in order to
persist data of regular and symlink.
+mode=%sControl block allocation mode which supports "adaptive"
+   and "lfs". In "lfs" mode, there should be no random
+   writes towards main area.
 
 

 DEBUGFS ENTRIES
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 5f655d0..607ef43 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1710,6 +1710,8 @@ static ssize_t f2fs_direct_IO(struct kiocb *iocb, struct 
iov_iter *iter)
 
if (f2fs_encrypted_inode(inode) && S_ISREG(inode->i_mode))
return 0;
+   if (test_opt(F2FS_I_SB(inode), LFS))
+   return 0;
 
trace_f2fs_direct_IO_enter(inode, offset, count, iov_iter_rw(iter));
 
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index b35b68b..d919294 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -111,6 +111,8 @@ static inline bool time_to_inject(int type)
 #define F2FS_MOUNT_FORCE_FG_GC 0x4000
 #define F2FS_MOUNT_DATA_FLUSH  0x8000
 #define F2FS_MOUNT_FAULT_INJECTION 0x0001
+#define F2FS_MOUNT_ADAPTIVE0x0002
+#define F2FS_MOUNT_LFS 0x0004
 
 #define clear_opt(sbi, option) (sbi->mount_opt.opt &= ~F2FS_MOUNT_##option)
 #define set_opt(sbi, option)   (sbi->mount_opt.opt |= F2FS_MOUNT_##option)
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index e66d223..f1f78fb 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -917,9 +917,15 @@ static int __exchange_data_block(struct inode *inode, 
pgoff_t src,
return full ? truncate_hole(inode, dst, dst + 1) : 0;
 
if (do_replace) {
-   struct page *ipage = get_node_page(sbi, inode->i_ino);
+   struct page *ipage;
struct node_info ni;
 
+   if (test_opt(sbi, LFS)) {
+   ret = -ENOTSUPP;
+   goto err_out;
+   }
+
+   ipage = get_node_page(sbi, inode->i_ino);
if (IS_ERR(ipage)) {
ret = PTR_ERR(ipage);
goto err_out;
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index eff046a..9ff4e30 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -594,6 +594,9 @@ bool discard_next_dnode(struct f2fs_sb_info *sbi, block_t 
blkaddr)
 {
int err = -EOPNOTSUPP;
 
+   if (test_opt(sbi, LFS))
+   return false;
+
if (test_opt(sbi, DISCARD)) {
struct seg_entry *se = get_seg_entry(sbi,
GET_SEGNO(sbi, blkaddr));
@@ -707,6 +710,7 @@ void clear_prefree_segments(struct f2fs_sb_info *sbi, 
struct cp_control *cpc)
struct dirty_seglist_info *dirty_i = DIRTY_I(sbi);
unsigned long *prefree_map = dirty_i->dirty_segmap[PRE];
unsigned int start = 0, end = -1;
+   unsigned int secno, start_segno;
 
mutex_lock(_i->seglist_lock);
 
@@ -726,8 +730,22 @@ void clear_prefree_segments(struct f2fs_sb_info *sbi, 
struct cp_control *cpc)
if (!test_opt(sbi, DISCARD))
continue;
 
-   f2fs_issue_discard(sbi, START_BLOCK(sbi, start),
+   if (!test_opt(sbi, LFS) || sbi->segs_per_sec == 1) {
+   f2fs_issue_discard(sbi, START_BLOCK(sbi, start),
(end - start) << sbi->log_blocks_per_seg);
+   continue;
+   }
+next:
+   secno = GET_SECNO(sbi, start);
+   start_segno = secno * sbi->segs_per_sec;
+   if (!IS_CURSEC(sbi, secno) &&
+   !get_valid_blocks(sbi, start, sbi->segs_per_sec))
+   f2fs_issue_discard(sbi, START_BLOCK(sbi, start_segno),
+   sbi->segs_per_sec << sbi->log_blocks_per_seg);
+
+   

[PATCH 2/3] x86, siginfo: add build-time checks in siginfo compat code

[Dave Hansen]

From: Dave Hansen 

There were at least 3 features added to the __SI_FAULT area of the
siginfo struct that did not make it to the compat siginfo:

1. The si_addr_lsb used in SIGBUS's sent for machine checks
2. The upper/lower bounds for MPX SIGSEGV faults
3. The protection key for pkey faults

There was also some turmoil when I was attempting to add the pkey
field because it needs to be a fixed size on 32 and 64-bit and
not have any alignment constraints.

This patch adds some compile-time checks to the compat code to
make it harder to screw this up.  Basically, the checks are
supposed to trip any time someone changes the siginfo structure.
That sounds bad, but it's what we want.  If someone changes
siginfo, we want them to also be _forced_ to go look at the
compat code.

The details are in the comments.

Signed-off-by: Dave Hansen 
Cc: Tony Luck 
Cc: Borislav Petkov 
Cc: linux-e...@vger.kernel.org
Cc: x...@kernel.org
Cc: Andy Lutomirski 
---

 b/arch/x86/kernel/signal_compat.c |   93 ++
 1 file changed, 93 insertions(+)

diff -puN arch/x86/kernel/signal_compat.c~x86-siginfo-compat-checks 
arch/x86/kernel/signal_compat.c
--- a/arch/x86/kernel/signal_compat.c~x86-siginfo-compat-checks 2016-06-08 
10:23:24.004492838 -0700
+++ b/arch/x86/kernel/signal_compat.c   2016-06-08 10:23:24.007492973 -0700
@@ -1,11 +1,104 @@
 #include 
 #include 
 
+/*
+ * The compat_siginfo_t structure and handing code is very easy
+ * to break in several ways.  It must always be updated when new
+ * updates are made to the main siginfo_t, and
+ * copy_siginfo_to_user32() must be updated when the
+ * (arch-independent) copy_siginfo_to_user() is updated.
+ *
+ * It is also easy to put a new member in the compat_siginfo_t
+ * which has implicit alignment which can move internal structure
+ * alignment around breaking the ABI.  This can happen if you,
+ * for instance, put a plain 64-bit value in there.
+ */
+static inline void signal_compat_build_tests(void)
+{
+   int _sifields_offset = offsetof(compat_siginfo_t, _sifields);
+
+   /*
+* If adding a new si_code, there is probably new data in
+* the siginfo.  Make sure folks bumping the si_code
+* limits also have to look at this code.  Make sure any
+* new fields are handled in copy_siginfo_to_user32()!
+*/
+   BUILD_BUG_ON(NSIGILL  != 8);
+   BUILD_BUG_ON(NSIGFPE  != 8);
+   BUILD_BUG_ON(NSIGSEGV != 4);
+   BUILD_BUG_ON(NSIGBUS  != 5);
+   BUILD_BUG_ON(NSIGTRAP != 4);
+   BUILD_BUG_ON(NSIGCHLD != 6);
+   BUILD_BUG_ON(NSIGSYS  != 1);
+
+   /* This is part of the ABI and can never change in size: */
+   BUILD_BUG_ON(sizeof(compat_siginfo_t) != 128);
+   /*
+* The offsets of all the (unioned) si_fields are fixed
+* in the ABI, of course.  Make sure none of them ever
+* move and are always at the beginning:
+*/
+   BUILD_BUG_ON(offsetof(compat_siginfo_t, _sifields) != 3 * sizeof(int));
+#define CHECK_CSI_OFFSET(name)   BUILD_BUG_ON(_sifields_offset != 
offsetof(compat_siginfo_t, _sifields.name))
+
+/*
+* Ensure that the size of each si_field never changes.
+* If it does, it is a sign that the
+* copy_siginfo_to_user32() code below needs to updated
+* along with the size in the CHECK_SI_SIZE().
+*
+* We repeat this check for both the generic and compat
+* siginfos.
+*
+* Note: it is OK for these to grow as long as the whole
+* structure stays within the padding size (checked
+* above).
+*/
+#define CHECK_CSI_SIZE(name, size) BUILD_BUG_ON(size != 
sizeof(((compat_siginfo_t *)0)->_sifields.name))
+#define CHECK_SI_SIZE(name, size) BUILD_BUG_ON(size != sizeof(((siginfo_t 
*)0)->_sifields.name))
+
+   CHECK_CSI_OFFSET(_kill);
+   CHECK_CSI_SIZE  (_kill, 2*sizeof(int));
+   CHECK_SI_SIZE   (_kill, 2*sizeof(int));
+
+   CHECK_CSI_OFFSET(_timer);
+   CHECK_CSI_SIZE  (_timer, 5*sizeof(int));
+   CHECK_SI_SIZE   (_timer, 6*sizeof(int));
+
+   CHECK_CSI_OFFSET(_rt);
+   CHECK_CSI_SIZE  (_rt, 3*sizeof(int));
+   CHECK_SI_SIZE   (_rt, 4*sizeof(int));
+
+   CHECK_CSI_OFFSET(_sigchld);
+   CHECK_CSI_SIZE  (_sigchld, 5*sizeof(int));
+   CHECK_SI_SIZE   (_sigchld, 8*sizeof(int));
+
+   CHECK_CSI_OFFSET(_sigchld_x32);
+   CHECK_CSI_SIZE  (_sigchld_x32, 7*sizeof(int));
+   /* no _sigchld_x32 in the generic siginfo_t */
+
+   CHECK_CSI_OFFSET(_sigfault);
+   CHECK_CSI_SIZE  (_sigfault, 4*sizeof(int));
+   CHECK_SI_SIZE   (_sigfault, 8*sizeof(int));
+
+   CHECK_CSI_OFFSET(_sigpoll);
+   CHECK_CSI_SIZE  (_sigpoll, 2*sizeof(int));
+   CHECK_SI_SIZE   (_sigpoll, 4*sizeof(int));
+
+   CHECK_CSI_OFFSET(_sigsys);
+   

[PATCH 1/7] f2fs: set mapping error for EIO

[Jaegeuk Kim]

If EIO occurred, we need to set all the mapping to avoid any further IOs.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/data.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index c9d6fe2..30dc448 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1243,7 +1243,7 @@ write:
 
/* we should bypass data pages to proceed the kworkder jobs */
if (unlikely(f2fs_cp_error(sbi))) {
-   SetPageError(page);
+   mapping_set_error(page->mapping, -EIO);
goto out;
}
 
-- 
2.8.3

[PATCH 6/7] f2fs: fix deadlock in add_link failure

[Jaegeuk Kim]

mkdirsync_dirty_inode
 - init_inode_metadata
   - lock_page(node)
   - make_empty_dir
 - filemap_fdatawrite()
  - do_writepages
  - lock_page(data)
  - write_page(data)
   - lock_page(node)
   - f2fs_init_acl
- error
   - truncate_inode_pages
- lock_page(data)

So, we don't need to truncate data pages in this error case, which will
be done by f2fs_evict_inode.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/dir.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index f6ab3c2..4864824 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -450,9 +450,6 @@ struct page *init_inode_metadata(struct inode *inode, 
struct inode *dir,
return page;
 
 put_error:
-   /* truncate empty dir pages */
-   truncate_inode_pages(>i_data, 0);
-
clear_nlink(inode);
update_inode(inode, page);
f2fs_put_page(page, 1);
-- 
2.8.3

[PATCH 0/3] [v2] x86: compat_siginfo fixes and build-time tests

[Dave Hansen]

Changes from v1:
 * lots of style fixups to the MPX selftests.  No
   Functional changes.

---

We have not been updating the x86 compat_siginfo when updating the
generic one.  These patches fix the issue, and then add a bunch
of build-time checks to try to avoid this happening again in the
future (suggested by Ingo).

Re: [PATCH v10 0/8] add i2c driver supported for rk3399

[Heiko Stübner]

Hi Wolfram,

Am Montag, 16. Mai 2016, 21:57:35 schrieb David Wu:
> There are three points differert from others:
>  - new method to caculate i2c timings for rk3399
>  - pclk and function clk are separated at rk3399
>  - add fast-plus mode supported for rk3399

this series looks pretty nice now and it seems most everybody is happy with it 
by now. Do you still have it in your inbox to look at, or should David resend 
it again?


Heiko

> David Wu (8):
>   i2c: rk3x: add documentation to fields in "struct rk3x_i2c"
>   i2c: rk3x: use struct "rk3x_i2c_calced_timings"
>   i2c: rk3x: Remove redundant rk3x_i2c_clean_ipd()
>   i2c: rk3x: Change SoC data to not use array
>   i2c: rk3x: Move spec timing data to "static const" structs
>   dt-bindings: i2c: rk3x: add support for rk3399
>   i2c: rk3x: add i2c support for rk3399 soc
>   i2c: rk3x: support fast-mode plus for rk3399
> 
>  Documentation/devicetree/bindings/i2c/i2c-rk3x.txt |  16 +-
>  drivers/i2c/busses/i2c-rk3x.c  | 498
> + 2 files changed, 434 insertions(+), 80 deletions(-)

[PATCH] nvmem: fix nvmem_cell_read() return type for !CONFIG_NVMEM

[Brian Norris]

With CONFIG_NVMEM, nvmem_cell_read() returns void *. With !CONFIG_NVMEM
it returns char *. Let's make that consistent. Also drop the
incorrect/inconsistent comment about char * above the nvmem_cell_read()
definition.

drivers/thermal/mtk_thermal.c is already working around this by casting
to (u32 *).

Signed-off-by: Brian Norris 
---
 drivers/nvmem/core.c   | 4 ++--
 include/linux/nvmem-consumer.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 965911d9b36a..398ea7f54826 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -981,8 +981,8 @@ static int __nvmem_cell_read(struct nvmem_device *nvmem,
  * @cell: nvmem cell to be read.
  * @len: pointer to length of cell which will be populated on successful read.
  *
- * Return: ERR_PTR() on error or a valid pointer to a char * buffer on success.
- * The buffer should be freed by the consumer with a kfree().
+ * Return: ERR_PTR() on error or a valid pointer to a buffer on success. The
+ * buffer should be freed by the consumer with a kfree().
  */
 void *nvmem_cell_read(struct nvmem_cell *cell, size_t *len)
 {
diff --git a/include/linux/nvmem-consumer.h b/include/linux/nvmem-consumer.h
index 9bb77d3ed6e0..c2256d746543 100644
--- a/include/linux/nvmem-consumer.h
+++ b/include/linux/nvmem-consumer.h
@@ -74,7 +74,7 @@ static inline void nvmem_cell_put(struct nvmem_cell *cell)
 {
 }
 
-static inline char *nvmem_cell_read(struct nvmem_cell *cell, size_t *len)
+static inline void *nvmem_cell_read(struct nvmem_cell *cell, size_t *len)
 {
return ERR_PTR(-ENOSYS);
 }
-- 
2.8.0.rc3.226.g39d4020

Re: 274ad65c9d02 ("drm/radeon: hard reset r600 and newer GPU when hibernating.")

[Borislav Petkov]

On Wed, Jun 08, 2016 at 05:28:53PM +0200, Grigori Goronzy wrote:
> Are you sure it is using accelerated decoding? CPU load should be just 1-2%.

Ha, good point. So with mplayer vo=vdpau, CPU load was at something over 12%.

Doing:

$ mpv --vo=vdpau --hwdec=vdpau $file
 (+) Video --vid=1 (*) (h264)
 (+) Audio --aid=1 --alang=eng (*) (aac)
Trying to use hardware decoding.
AO: [alsa] 48000Hz stereo 2ch float
VO: [vdpau] 1280x720 vdpau
AV: 00:00:50 / 00:02:36 (32%) A-V:  0.000

did bring it down to 5-6ish.

  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
12482 boris 20   0 1026628  74272  47632 S   5.6  0.5   0:02.77 mpv

so I'm guessing this should be using hw accel now...

In any case, output looks fine again too.

Thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.

Re: [PATCH 1/1] mm/swap.c: flush lru_add pvecs on compound page arrival

[Dave Hansen]

On 06/08/2016 09:06 AM, Michal Hocko wrote:
>> > Do we have any statistics that tell us how many pages are sitting the
>> > lru pvecs?  Although this helps the problem overall, don't we still have
>> > a problem with memory being held in such an opaque place?
> Is it really worth bothering when we are talking about 56kB per CPU
> (after this patch)?

That was the logic why we didn't have it up until now: we didn't
*expect* it to get large.  A code change blew it up by 512x, and we had
no instrumentation to tell us where all the memory went.

I guess we don't have any other ways to group pages than compound pages,
and _that_ one is covered now... for one of the 5 classes of pvecs.

Is there a good reason we don't have to touch the other 4 pagevecs, btw?

Re: [PATCH v2] of: iommu: make of_iommu_init() postcore_initcall_sync

[Robin Murphy]

On 08/06/16 16:44, Rob Herring wrote:

On Wed, Jun 1, 2016 at 1:06 AM, Kefeng Wang  wrote:

The of_iommu_init() is called multiple times by arch code,
make it postcore_initcall_sync, then we can drop relevant
calls fully.

Note, the IOMMUs should have a chance to perform some basic
initialisation before we start adding masters to them. So
postcore_initcall_sync is good choice, it ensures of_iommu_init()
called before of_platform_populate.


What ever happened to doing deferred probe for IOMMUs?


Sricharan has been trying to resurrect it recently[1], although the fact 
that we're starting to need more or less the same thing for certain 
interrupt controllers as well (and I'm not sure how immune ACPI IORT is 
to the problem) suggests a more general rethink might be in order. I've 
got a big TODO item hanging over me on that one...


Robin.

[1]:http://thread.gmane.org/gmane.linux.kernel.iommu/13243



Rob

[PATCH v2 1/1] hwmon: (tmp401) Add support for TI TMP461

[Andrew F. Davis]

Signed-off-by: Andrew F. Davis 
---
Changes from v1:
 - Dropped n-factor correction until a generic solution is developed
 - Removed double empty line

 Documentation/hwmon/tmp401 | 14 --
 drivers/hwmon/Kconfig  |  2 +-
 drivers/hwmon/tmp401.c | 35 +--
 3 files changed, 42 insertions(+), 9 deletions(-)

diff --git a/Documentation/hwmon/tmp401 b/Documentation/hwmon/tmp401
index 711f75e..2d9ca42 100644
--- a/Documentation/hwmon/tmp401
+++ b/Documentation/hwmon/tmp401
@@ -22,6 +22,9 @@ Supported chips:
 Prefix: 'tmp435'
 Addresses scanned: I2C 0x48 - 0x4f
 Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp435.html
+  * Texas Instruments TMP461
+Prefix: 'tmp461'
+Datasheet: http://www.ti.com/product/tmp461
 
 Authors:
  Hans de Goede 
@@ -31,8 +34,8 @@ Description
 ---
 
 This driver implements support for Texas Instruments TMP401, TMP411,
-TMP431, TMP432 and TMP435 chips. These chips implement one or two remote
-and one local temperature sensors. Temperature is measured in degrees
+TMP431, TMP432, TMP435, and TMP461 chips. These chips implement one or two
+remote and one local temperature sensors. Temperature is measured in degrees
 Celsius. Resolution of the remote sensor is 0.0625 degree. Local
 sensor resolution can be set to 0.5, 0.25, 0.125 or 0.0625 degree (not
 supported by the driver so far, so using the default resolution of 0.5
@@ -55,3 +58,10 @@ some additional features.
 
 TMP432 is compatible with TMP401 and TMP431. It supports two external
 temperature sensors.
+
+TMP461 is compatible with TMP401. It supports offset correction
+that is applied to the remote sensor.
+
+* Sensor offset values are temperature values
+
+  Exported via sysfs attribute tempX_offset
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index ff94007..c571dcf 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1561,7 +1561,7 @@ config SENSORS_TMP401
depends on I2C
help
  If you say yes here you get support for Texas Instruments TMP401,
- TMP411, TMP431, TMP432 and TMP435 temperature sensor chips.
+ TMP411, TMP431, TMP432, TMP435, and TMP461 temperature sensor chips.
 
  This driver can also be built as a module.  If so, the module
  will be called tmp401.
diff --git a/drivers/hwmon/tmp401.c b/drivers/hwmon/tmp401.c
index ccf4cff..d2c 100644
--- a/drivers/hwmon/tmp401.c
+++ b/drivers/hwmon/tmp401.c
@@ -47,7 +47,7 @@
 static const unsigned short normal_i2c[] = { 0x48, 0x49, 0x4a, 0x4c, 0x4d,
0x4e, 0x4f, I2C_CLIENT_END };
 
-enum chips { tmp401, tmp411, tmp431, tmp432, tmp435 };
+enum chips { tmp401, tmp411, tmp431, tmp432, tmp435, tmp461 };
 
 /*
  * The TMP401 registers, note some registers have different addresses for
@@ -62,31 +62,34 @@ enum chips { tmp401, tmp411, tmp431, tmp432, tmp435 };
 #define TMP401_MANUFACTURER_ID_REG 0xFE
 #define TMP401_DEVICE_ID_REG   0xFF
 
-static const u8 TMP401_TEMP_MSB_READ[6][2] = {
+static const u8 TMP401_TEMP_MSB_READ[7][2] = {
{ 0x00, 0x01 }, /* temp */
{ 0x06, 0x08 }, /* low limit */
{ 0x05, 0x07 }, /* high limit */
{ 0x20, 0x19 }, /* therm (crit) limit */
{ 0x30, 0x34 }, /* lowest */
{ 0x32, 0x36 }, /* highest */
+   { 0, 0x11 },/* offset */
 };
 
-static const u8 TMP401_TEMP_MSB_WRITE[6][2] = {
+static const u8 TMP401_TEMP_MSB_WRITE[7][2] = {
{ 0, 0 },   /* temp (unused) */
{ 0x0C, 0x0E }, /* low limit */
{ 0x0B, 0x0D }, /* high limit */
{ 0x20, 0x19 }, /* therm (crit) limit */
{ 0x30, 0x34 }, /* lowest */
{ 0x32, 0x36 }, /* highest */
+   { 0, 0x11 },/* offset */
 };
 
-static const u8 TMP401_TEMP_LSB[6][2] = {
+static const u8 TMP401_TEMP_LSB[7][2] = {
{ 0x15, 0x10 }, /* temp */
{ 0x17, 0x14 }, /* low limit */
{ 0x16, 0x13 }, /* high limit */
{ 0, 0 },   /* therm (crit) limit (unused) */
{ 0x31, 0x35 }, /* lowest */
{ 0x33, 0x37 }, /* highest */
+   { 0, 0x12 },/* offset */
 };
 
 static const u8 TMP432_TEMP_MSB_READ[4][3] = {
@@ -149,6 +152,7 @@ static const struct i2c_device_id tmp401_id[] = {
{ "tmp431", tmp431 },
{ "tmp432", tmp432 },
{ "tmp435", tmp435 },
+   { "tmp461", tmp461 },
{ }
 };
 MODULE_DEVICE_TABLE(i2c, tmp401_id);
@@ -170,7 +174,7 @@ struct tmp401_data {
/* register values */
u8 status[4];
u8 config;
-   u16 temp[6][3];
+   u16 temp[7][3];
u8 temp_crit_hyst;
 };
 
@@ -613,6 +617,22 @@ static const struct attribute_group tmp432_group = {
 };
 
 /*
+ * Additional features of the TMP461 chip.
+ * The TMP461 temperature offset for the remote channel.
+ */
+static SENSOR_DEVICE_ATTR_2(temp2_offset, S_IWUSR | S_IRUGO, show_temp,
+   store_temp, 6, 1);
+

Re: [PATCH v5 08/11] powerpc/powernv: Add platform support for stop instruction

[Shreyas B Prabhu]

Hi Ben,

Sorry for the delayed response.

On 06/06/2016 03:58 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2016-06-02 at 07:38 -0500, Shreyas B. Prabhu wrote:
>> @@ -61,8 +72,13 @@ save_sprs_to_stack:
>>  * Note all register i.e per-core, per-subcore or per-thread is saved
>>  * here since any thread in the core might wake up first
>>  */
>> +BEGIN_FTR_SECTION
>> +   mfspr   r3,SPRN_PTCR
>> +   std r3,_PTCR(r1)
>> +FTR_SECTION_ELSE
>> mfspr   r3,SPRN_SDR1
>> std r3,_SDR1(r1)
>> +ALT_FTR_SECTION_END_IFSET(CPU_FTR_ARCH_300)
> 
> This is the only new SPR we care about in P9 ?
> 
After reviewing ISA again, I've identified LMRR, LMSER and ASDR also
need to be restored. I've fixed this in v6.

Thanks,
Shreyas

Re: Re: [PATCH] staging: slicoss: replacement of goto statements

[Greg KH]

On Wed, Jun 08, 2016 at 11:28:11AM -0500, Jaime Arrocha wrote:
> 
>  On Wed, 08 Jun 2016 10:49:47 -0500 Greg KH  
> wrote  
> 
>  > On Wed, Jun 08, 2016 at 08:46:06AM -0500, Jaime Arrocha wrote: 
>  > > From: Jaime Arrocha  
>  > >  
>  > > Replaced deprecated goto statements. 
>  >  
>  > Since when is 'goto' deprecated? 
>  >  
>  > Were you able to test these changes? 
>  >  
>  > thanks, 
>  >  
>  > greg k-h 
>  > 
>  > 
> 
> Just wanted to see your stance on this type of changes. The
> documentation says "deprecated by some people".

What documentation?  And what people?

> I didn't test the changes. But it compiled and logically tested
> possible outcomes.
> 
> Not good enough? :)

Nope, sorry, churn for churn's sake isn't acceptable.

greg k-h

[PATCH] ARM: exynos_defconfig add CONFIG_EXYNOS_IOMMU in not set mode

[Shuah Khan]

Add CONFIG_EXYNOS_IOMMU in not set mode to make it easier to enable it.

Signed-off-by: Shuah Khan 
---
 arch/arm/configs/exynos_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/exynos_defconfig 
b/arch/arm/configs/exynos_defconfig
index daf9762..16c2957 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -218,6 +218,7 @@ CONFIG_CROS_EC_CHARDEV=y
 CONFIG_COMMON_CLK_MAX77686=y
 CONFIG_COMMON_CLK_MAX77802=y
 CONFIG_COMMON_CLK_S2MPS11=y
+# CONFIG_EXYNOS_IOMMU is not set
 CONFIG_EXTCON=y
 CONFIG_EXTCON_MAX14577=y
 CONFIG_EXTCON_MAX77693=y
-- 
2.7.4

Re: [RFC][PATCH 2/5] hi655x-pmic: Make hi655x pmic logic probe child nodes in the dt

[John Stultz]

On Wed, Jun 8, 2016 at 7:31 AM, Lee Jones  wrote:
>
> Please use full buffer width.  Wrapping at 50 chars is not necessary.

But then how would you be able to review patches on your phone?! :)


>> --- a/drivers/mfd/hi655x-pmic.c
>> +++ b/drivers/mfd/hi655x-pmic.c
>> @@ -39,6 +39,11 @@ static const struct regmap_irq hi655x_irqs[] = {
>>   { .reg_offset = 0, .mask = RESERVE_INT },
>>  };
>>
>> +static const struct of_device_id of_hi655x_pmic_child_match_tbl[] = {
>> + { .compatible = "hisilicon,hi6552-powerkey", },
>> + { /* end */ }
>> +};
>> +
>>  static const struct regmap_irq_chip hi655x_irq_chip = {
>>   .name = "hi655x-pmic",
>>   .irqs = hi655x_irqs,
>> @@ -122,6 +127,9 @@ static int hi655x_pmic_probe(struct platform_device 
>> *pdev)
>>
>>   platform_set_drvdata(pdev, pmic);
>>
>> + /* populate sub nodes */
>> + of_platform_populate(np, of_hi655x_pmic_child_match_tbl, NULL, dev);
>> +
>
> Oh, holey poop, no!
>
> Please don't mix DT and MFD registration like this.
>
> Drivers should contain either of_platform_populate() or
> mfd_add_devices(), but never both.
>
>>   ret = mfd_add_devices(dev, PLATFORM_DEVID_AUTO, hi655x_pmic_devs,
>> ARRAY_SIZE(hi655x_pmic_devs), NULL, 0, NULL);
>>   if (ret) {


So apologies for my ignorance here. I'm not quite sure I see what the
right thing to do. I tried adding a "hi65xx-powerkey" entry in the
hi655x_pmic_devs, but then mfd_add_devices doesn't seem to provide any
of the irq info from the DT.

The only way I can think to make it work w/o calling to populate
sub-nodes is to pull the powerkey subnode out of the pmic node. It
seems to work, but I'm not sure if it properly describes the hardware
then.  Sorry again for being a bit clueless here.

Thanks for the review!
-john

Re: [PATCH] mmc: core: add auto bkops support

[Alex Lemberg]

Hi Shawn,

Is the intention in this patch to stop using MANUAL_BKOPS for all eMMC5.1+ 
devices, and only use AUTO_BKOPS?
Please see several questions inline.


On 6/6/16, 6:07 AM, "linux-mmc-ow...@vger.kernel.org on behalf of Shawn Lin" 
 wrote:

>JEDEC eMMC v5.1 introduce an autonomously initiated method
>for background operations.
>
>Host that wants to enable the device to perform background
>operations during device idle time, should signal the device
>by setting AUTO_EN in BKOPS_EN field EXT_CSD[163] to 1b. When
>this bit is set, the device may start or stop background operations
>whenever it sees fit, without any notification to the host.
>
>When AUTO_EN bit is set, the host should keep the device power
>active. The host may set or clear this bit at any time based on
>its power constraints or other considerations.
>
>Currently the manual bkops is only be used under the async req
>circumstances and it's a bit complicated to be controlled as the
>perfect method is that we should do some idle monitor just as rpm
>and send HPI each time if receiving rd/wr req. But it will impact
>performance significantly, especially for random iops since the
>weight of executing HPI against r/w small piece of LBAs is
>nonnegligible.
>
>So we now prefer to select the auto one unconditionally if supported
>which makes it as simple as possible. It should really good enough
>for devices to manage its internal policy for bkops rather than the
>host, which makes us believe that we could achieve the best
>performance for all the devices implementing auto bkops and the only
>thing we should do is to disable it when cutting off the power.
>
>Signed-off-by: Shawn Lin 
>---
>
> drivers/mmc/core/core.c  | 127 +--
> drivers/mmc/core/mmc.c   |  30 ++-
> include/linux/mmc/card.h |   1 +
> include/linux/mmc/core.h |   4 +-
> include/linux/mmc/mmc.h  |   1 +
> 5 files changed, 133 insertions(+), 30 deletions(-)
>
>diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
>index e864187..c2e5a66 100644
>--- a/drivers/mmc/core/core.c
>+++ b/drivers/mmc/core/core.c
>@@ -297,24 +297,13 @@ static int mmc_start_request(struct mmc_host *host, 
>struct mmc_request *mrq)
>   return 0;
> }
> 
>-/**
>- *mmc_start_bkops - start BKOPS for supported cards
>- *@card: MMC card to start BKOPS
>- *@form_exception: A flag to indicate if this function was
>- * called due to an exception raised by the card
>- *
>- *Start background operations whenever requested.
>- *When the urgent BKOPS bit is set in a R1 command response
>- *then background operations should be started immediately.
>-*/
>-void mmc_start_bkops(struct mmc_card *card, bool from_exception)
>+static void  mmc_start_man_bkops(struct mmc_card *card,
>+   bool from_exception)
> {
>   int err;
>   int timeout;
>   bool use_busy_signal;
> 
>-  BUG_ON(!card);
>-
>   if (!card->ext_csd.man_bkops_en || mmc_card_doing_bkops(card))
>   return;
> 
>@@ -347,7 +336,7 @@ void mmc_start_bkops(struct mmc_card *card, bool 
>from_exception)
>   EXT_CSD_BKOPS_START, 1, timeout,
>   use_busy_signal, true, false);
>   if (err) {
>-  pr_warn("%s: Error %d starting bkops\n",
>+  pr_warn("%s: Error %d starting manual bkops\n",
>   mmc_hostname(card->host), err);
>   mmc_retune_release(card->host);
>   goto out;
>@@ -365,6 +354,55 @@ void mmc_start_bkops(struct mmc_card *card, bool 
>from_exception)
> out:
>   mmc_release_host(card->host);
> }
>+
>+static void  mmc_start_auto_bkops(struct mmc_card *card)
>+{
>+  int err;
>+
>+  /* If it's already enable auto_bkops, nothing to do */
>+  if (card->ext_csd.auto_bkops_en)
>+  return;
>+
>+  mmc_claim_host(card->host);
>+
>+  mmc_retune_hold(card->host);
>+
>+  err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
>+  EXT_CSD_BKOPS_EN, 2,
>+  card->ext_csd.generic_cmd6_time);
>+  if (err)
>+  pr_warn("%s: Error %d starting auto bkops\n",
>+  mmc_hostname(card->host), err);
>+
>+  card->ext_csd.auto_bkops_en = true;
>+  mmc_card_set_doing_bkops(card);
>+  mmc_retune_release(card->host);
>+  mmc_release_host(card->host);
>+}
>+
>+
>+/**
>+ *mmc_start_bkops - start BKOPS for supported cards
>+ *@card: MMC card to start BKOPS
>+ *@form_exception: A flag to indicate if this function was
>+ * called due to an exception raised by the card
>+ *  @is_auto: A flag to indicate if we should use auto bkops
>+ *
>+ *Start background operations whenever requested.
>+ *When the urgent BKOPS bit is set in a R1 command response
>+ *then background 

Re: [PATCH 5/8] mfd: ti_am335x_tscadc: Rename regmap_tscadc to regmap

[Lee Jones]

On Tue, 31 May 2016, Andrew F. Davis wrote:

> The regmap structuer pointer is named regmap_tscadc, this is not
> consistent with other drivers and is redundant, it also contributes
> to several checkpatch warnings involving long lines. Rename this.

Please spell check all of your subject lines and commit logs *before*
sending.

> Signed-off-by: Andrew F. Davis 
> ---
>  drivers/mfd/ti_am335x_tscadc.c   | 36 
> ++--
>  include/linux/mfd/ti_am335x_tscadc.h |  2 +-
>  2 files changed, 19 insertions(+), 19 deletions(-)

For the patch:
  Acked-by: Lee Jones 
  
> diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
> index 9b293b1..d30bea5 100644
> --- a/drivers/mfd/ti_am335x_tscadc.c
> +++ b/drivers/mfd/ti_am335x_tscadc.c
> @@ -43,7 +43,7 @@ void am335x_tsc_se_set_cache(struct ti_tscadc_dev *tscadc, 
> u32 val)
>   if (tscadc->adc_waiting)
>   wake_up(>reg_se_wait);
>   else if (!tscadc->adc_in_use)
> - regmap_write(tscadc->regmap_tscadc, REG_SE, 
> tscadc->reg_se_cache);
> + regmap_write(tscadc->regmap, REG_SE, tscadc->reg_se_cache);
>  
>   spin_unlock_irqrestore(>reg_lock, flags);
>  }
> @@ -54,7 +54,7 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev 
> *tscadc)
>   DEFINE_WAIT(wait);
>   u32 reg;
>  
> - regmap_read(tscadc->regmap_tscadc, REG_ADCFSM, );
> + regmap_read(tscadc->regmap, REG_ADCFSM, );
>   if (reg & SEQ_STATUS) {
>   tscadc->adc_waiting = true;
>   prepare_to_wait(>reg_se_wait, ,
> @@ -70,7 +70,7 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev 
> *tscadc)
>* Sequencer should either be idle or
>* busy applying the charge step.
>*/
> - regmap_read(tscadc->regmap_tscadc, REG_ADCFSM, );
> + regmap_read(tscadc->regmap, REG_ADCFSM, );
>   WARN_ON((reg & SEQ_STATUS) && !(reg & CHARGE_STEP));
>   tscadc->adc_waiting = false;
>   }
> @@ -82,7 +82,7 @@ void am335x_tsc_se_set_once(struct ti_tscadc_dev *tscadc, 
> u32 val)
>   spin_lock_irq(>reg_lock);
>   am335x_tscadc_need_adc(tscadc);
>  
> - regmap_write(tscadc->regmap_tscadc, REG_SE, val);
> + regmap_write(tscadc->regmap, REG_SE, val);
>   spin_unlock_irq(>reg_lock);
>  }
>  EXPORT_SYMBOL_GPL(am335x_tsc_se_set_once);
> @@ -93,7 +93,7 @@ void am335x_tsc_se_adc_done(struct ti_tscadc_dev *tscadc)
>  
>   spin_lock_irqsave(>reg_lock, flags);
>   tscadc->adc_in_use = false;
> - regmap_write(tscadc->regmap_tscadc, REG_SE, tscadc->reg_se_cache);
> + regmap_write(tscadc->regmap, REG_SE, tscadc->reg_se_cache);
>   spin_unlock_irqrestore(>reg_lock, flags);
>  }
>  EXPORT_SYMBOL_GPL(am335x_tsc_se_adc_done);
> @@ -104,7 +104,7 @@ void am335x_tsc_se_clr(struct ti_tscadc_dev *tscadc, u32 
> val)
>  
>   spin_lock_irqsave(>reg_lock, flags);
>   tscadc->reg_se_cache &= ~val;
> - regmap_write(tscadc->regmap_tscadc, REG_SE, tscadc->reg_se_cache);
> + regmap_write(tscadc->regmap, REG_SE, tscadc->reg_se_cache);
>   spin_unlock_irqrestore(>reg_lock, flags);
>  }
>  EXPORT_SYMBOL_GPL(am335x_tsc_se_clr);
> @@ -116,7 +116,7 @@ static void tscadc_idle_config(struct ti_tscadc_dev 
> *tscadc)
>   idleconfig = STEPCONFIG_YNN | STEPCONFIG_INM_ADCREFM |
>   STEPCONFIG_INP_ADCREFM | STEPCONFIG_YPN;
>  
> - regmap_write(tscadc->regmap_tscadc, REG_IDLECONFIG, idleconfig);
> + regmap_write(tscadc->regmap, REG_IDLECONFIG, idleconfig);
>  }
>  
>  static   int ti_tscadc_probe(struct platform_device *pdev)
> @@ -188,11 +188,11 @@ static  int ti_tscadc_probe(struct platform_device 
> *pdev)
>   if (IS_ERR(tscadc->tscadc_base))
>   return PTR_ERR(tscadc->tscadc_base);
>  
> - tscadc->regmap_tscadc = devm_regmap_init_mmio(>dev,
> + tscadc->regmap = devm_regmap_init_mmio(>dev,
>   tscadc->tscadc_base, _regmap_config);
> - if (IS_ERR(tscadc->regmap_tscadc)) {
> + if (IS_ERR(tscadc->regmap)) {
>   dev_err(>dev, "regmap init failed\n");
> - err = PTR_ERR(tscadc->regmap_tscadc);
> + err = PTR_ERR(tscadc->regmap);
>   goto ret;
>   }
>  
> @@ -222,11 +222,11 @@ static  int ti_tscadc_probe(struct platform_device 
> *pdev)
>  
>   /* TSCADC_CLKDIV needs to be configured to the value minus 1 */
>   tscadc->clk_div--;
> - regmap_write(tscadc->regmap_tscadc, REG_CLKDIV, tscadc->clk_div);
> + regmap_write(tscadc->regmap, REG_CLKDIV, tscadc->clk_div);
>  
>   /* Set the control register bits */
>   ctrl = CNTRLREG_STEPCONFIGWRT | CNTRLREG_STEPID;
> - regmap_write(tscadc->regmap_tscadc, REG_CTRL, ctrl);
> + regmap_write(tscadc->regmap, REG_CTRL, ctrl);
>  
>   /* Set register bits for Idle Config Mode */
>   if (tsc_wires > 0) {
> @@ -240,7 +240,7 @@ static