[PATCH] ASoC: samsung: i2s: Supported high resolution rates

[Jaechul Lee]

This driver can support more frequencies over 96KHz. There are no reasons
to limit the frequency range below 96KHz. If codecs/amps or something else
can't support high resolution rates, the constraints would be set rates
properly because each drivers have its own limits.

Signed-off-by: Jaechul Lee 
---
 sound/soc/samsung/i2s.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index af3ba4d4ccc5..fc34af6a2c1e 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -50,6 +50,7 @@ struct samsung_i2s_variant_regs {
 
 struct samsung_i2s_dai_data {
u32 quirks;
+   unsigned int rates;
const struct samsung_i2s_variant_regs *i2s_variant_regs;
 };
 
@@ -1076,20 +1077,25 @@ static const struct snd_soc_component_driver 
samsung_i2s_component = {
.name   = "samsung-i2s",
 };
 
-#define SAMSUNG_I2S_RATES  SNDRV_PCM_RATE_8000_96000
-
 #define SAMSUNG_I2S_FMTS   (SNDRV_PCM_FMTBIT_S8 | \
SNDRV_PCM_FMTBIT_S16_LE | \
SNDRV_PCM_FMTBIT_S24_LE)
 
 static struct i2s_dai *i2s_alloc_dai(struct platform_device *pdev, bool sec)
 {
+   const struct samsung_i2s_dai_data *i2s_dai_data;
struct i2s_dai *i2s;
 
i2s = devm_kzalloc(>dev, sizeof(struct i2s_dai), GFP_KERNEL);
if (i2s == NULL)
return NULL;
 
+   if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node)
+   i2s_dai_data = of_device_get_match_data(>dev);
+   else
+   i2s_dai_data = (struct samsung_i2s_dai_data *)
+   platform_get_device_id(pdev)->driver_data;
+
i2s->pdev = pdev;
i2s->pri_dai = NULL;
i2s->sec_dai = NULL;
@@ -1101,13 +1107,13 @@ static struct i2s_dai *i2s_alloc_dai(struct 
platform_device *pdev, bool sec)
i2s->i2s_dai_drv.resume = i2s_resume;
i2s->i2s_dai_drv.playback.channels_min = 1;
i2s->i2s_dai_drv.playback.channels_max = 2;
-   i2s->i2s_dai_drv.playback.rates = SAMSUNG_I2S_RATES;
+   i2s->i2s_dai_drv.playback.rates = i2s_dai_data->rates;
i2s->i2s_dai_drv.playback.formats = SAMSUNG_I2S_FMTS;
 
if (!sec) {
i2s->i2s_dai_drv.capture.channels_min = 1;
i2s->i2s_dai_drv.capture.channels_max = 2;
-   i2s->i2s_dai_drv.capture.rates = SAMSUNG_I2S_RATES;
+   i2s->i2s_dai_drv.capture.rates = i2s_dai_data->rates;
i2s->i2s_dai_drv.capture.formats = SAMSUNG_I2S_FMTS;
}
return i2s;
@@ -1452,29 +1458,34 @@ static const struct samsung_i2s_variant_regs 
i2sv5_i2s1_regs = {
 
 static const struct samsung_i2s_dai_data i2sv3_dai_type = {
.quirks = QUIRK_NO_MUXPSR,
+   .rates = SNDRV_PCM_RATE_8000_96000,
.i2s_variant_regs = _regs,
 };
 
 static const struct samsung_i2s_dai_data i2sv5_dai_type = {
.quirks = QUIRK_PRI_6CHAN | QUIRK_SEC_DAI | QUIRK_NEED_RSTCLR |
QUIRK_SUPPORTS_IDMA,
+   .rates = SNDRV_PCM_RATE_8000_96000,
.i2s_variant_regs = _regs,
 };
 
 static const struct samsung_i2s_dai_data i2sv6_dai_type = {
.quirks = QUIRK_PRI_6CHAN | QUIRK_SEC_DAI | QUIRK_NEED_RSTCLR |
QUIRK_SUPPORTS_TDM | QUIRK_SUPPORTS_IDMA,
+   .rates = SNDRV_PCM_RATE_8000_96000,
.i2s_variant_regs = _regs,
 };
 
 static const struct samsung_i2s_dai_data i2sv7_dai_type = {
.quirks = QUIRK_PRI_6CHAN | QUIRK_SEC_DAI | QUIRK_NEED_RSTCLR |
QUIRK_SUPPORTS_TDM,
+   .rates = SNDRV_PCM_RATE_8000_192000,
.i2s_variant_regs = _regs,
 };
 
 static const struct samsung_i2s_dai_data i2sv5_dai_type_i2s1 = {
.quirks = QUIRK_PRI_6CHAN | QUIRK_NEED_RSTCLR,
+   .rates = SNDRV_PCM_RATE_8000_96000,
.i2s_variant_regs = _i2s1_regs,
 };
 
-- 
2.11.0

[PATCH] ASoC: samsung: i2s: Supported high resolution rates

[Jaechul Lee]

This driver can support more frequencies over 96KHz. There are no reasons
to limit the frequency range below 96KHz. If codecs/amps or something else
can't support high resolution rates, the constraints would be set rates
properly because each drivers have its own limits.

Signed-off-by: Jaechul Lee 
---
 sound/soc/samsung/i2s.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index af3ba4d4ccc5..fc34af6a2c1e 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -50,6 +50,7 @@ struct samsung_i2s_variant_regs {
 
 struct samsung_i2s_dai_data {
u32 quirks;
+   unsigned int rates;
const struct samsung_i2s_variant_regs *i2s_variant_regs;
 };
 
@@ -1076,20 +1077,25 @@ static const struct snd_soc_component_driver 
samsung_i2s_component = {
.name   = "samsung-i2s",
 };
 
-#define SAMSUNG_I2S_RATES  SNDRV_PCM_RATE_8000_96000
-
 #define SAMSUNG_I2S_FMTS   (SNDRV_PCM_FMTBIT_S8 | \
SNDRV_PCM_FMTBIT_S16_LE | \
SNDRV_PCM_FMTBIT_S24_LE)
 
 static struct i2s_dai *i2s_alloc_dai(struct platform_device *pdev, bool sec)
 {
+   const struct samsung_i2s_dai_data *i2s_dai_data;
struct i2s_dai *i2s;
 
i2s = devm_kzalloc(>dev, sizeof(struct i2s_dai), GFP_KERNEL);
if (i2s == NULL)
return NULL;
 
+   if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node)
+   i2s_dai_data = of_device_get_match_data(>dev);
+   else
+   i2s_dai_data = (struct samsung_i2s_dai_data *)
+   platform_get_device_id(pdev)->driver_data;
+
i2s->pdev = pdev;
i2s->pri_dai = NULL;
i2s->sec_dai = NULL;
@@ -1101,13 +1107,13 @@ static struct i2s_dai *i2s_alloc_dai(struct 
platform_device *pdev, bool sec)
i2s->i2s_dai_drv.resume = i2s_resume;
i2s->i2s_dai_drv.playback.channels_min = 1;
i2s->i2s_dai_drv.playback.channels_max = 2;
-   i2s->i2s_dai_drv.playback.rates = SAMSUNG_I2S_RATES;
+   i2s->i2s_dai_drv.playback.rates = i2s_dai_data->rates;
i2s->i2s_dai_drv.playback.formats = SAMSUNG_I2S_FMTS;
 
if (!sec) {
i2s->i2s_dai_drv.capture.channels_min = 1;
i2s->i2s_dai_drv.capture.channels_max = 2;
-   i2s->i2s_dai_drv.capture.rates = SAMSUNG_I2S_RATES;
+   i2s->i2s_dai_drv.capture.rates = i2s_dai_data->rates;
i2s->i2s_dai_drv.capture.formats = SAMSUNG_I2S_FMTS;
}
return i2s;
@@ -1452,29 +1458,34 @@ static const struct samsung_i2s_variant_regs 
i2sv5_i2s1_regs = {
 
 static const struct samsung_i2s_dai_data i2sv3_dai_type = {
.quirks = QUIRK_NO_MUXPSR,
+   .rates = SNDRV_PCM_RATE_8000_96000,
.i2s_variant_regs = _regs,
 };
 
 static const struct samsung_i2s_dai_data i2sv5_dai_type = {
.quirks = QUIRK_PRI_6CHAN | QUIRK_SEC_DAI | QUIRK_NEED_RSTCLR |
QUIRK_SUPPORTS_IDMA,
+   .rates = SNDRV_PCM_RATE_8000_96000,
.i2s_variant_regs = _regs,
 };
 
 static const struct samsung_i2s_dai_data i2sv6_dai_type = {
.quirks = QUIRK_PRI_6CHAN | QUIRK_SEC_DAI | QUIRK_NEED_RSTCLR |
QUIRK_SUPPORTS_TDM | QUIRK_SUPPORTS_IDMA,
+   .rates = SNDRV_PCM_RATE_8000_96000,
.i2s_variant_regs = _regs,
 };
 
 static const struct samsung_i2s_dai_data i2sv7_dai_type = {
.quirks = QUIRK_PRI_6CHAN | QUIRK_SEC_DAI | QUIRK_NEED_RSTCLR |
QUIRK_SUPPORTS_TDM,
+   .rates = SNDRV_PCM_RATE_8000_192000,
.i2s_variant_regs = _regs,
 };
 
 static const struct samsung_i2s_dai_data i2sv5_dai_type_i2s1 = {
.quirks = QUIRK_PRI_6CHAN | QUIRK_NEED_RSTCLR,
+   .rates = SNDRV_PCM_RATE_8000_96000,
.i2s_variant_regs = _i2s1_regs,
 };
 
-- 
2.11.0

Re: [PATCH 1/2] drivers: dma-coherent: Add support for default DMA coherent pool

[kbuild test robot]

Hi George,

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.12]
[cannot apply to next-20170704]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/vitaly_kuzmichev-mentor-com/drivers-dma-coherent-Add-support-for-default-DMA-coherent-pool/20170705-040238
config: i386-randconfig-c0-07051154 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

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

   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/io.h:21,
from drivers//base/dma-coherent.c:5:
   drivers//base/dma-coherent.c: In function 'dev_get_dma_area':
>> drivers//base/dma-coherent.c:28:16: error: 'struct device' has no member 
>> named 'cma_area'
 if (dev && dev->cma_area)
   ^
   include/linux/compiler.h:160:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^
>> drivers//base/dma-coherent.c:28:2: note: in expansion of macro 'if'
 if (dev && dev->cma_area)
 ^
>> drivers//base/dma-coherent.c:28:16: error: 'struct device' has no member 
>> named 'cma_area'
 if (dev && dev->cma_area)
   ^
   include/linux/compiler.h:160:42: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^
>> drivers//base/dma-coherent.c:28:2: note: in expansion of macro 'if'
 if (dev && dev->cma_area)
 ^
>> drivers//base/dma-coherent.c:28:16: error: 'struct device' has no member 
>> named 'cma_area'
 if (dev && dev->cma_area)
   ^
   include/linux/compiler.h:171:16: note: in definition of macro '__trace_if'
  __r = !!(cond); \
   ^
>> drivers//base/dma-coherent.c:28:2: note: in expansion of macro 'if'
 if (dev && dev->cma_area)
 ^

vim +28 drivers//base/dma-coherent.c

 1  /*
 2   * Coherent per-device memory handling.
 3   * Borrowed from i386
 4   */
   > 5  #include 
 6  #include 
 7  #include 
 8  #include 
 9  #include 
10  
11  struct dma_coherent_mem {
12  void*virt_base;
13  dma_addr_t  device_base;
14  unsigned long   pfn_base;
15  int size;
16  int flags;
17  unsigned long   *bitmap;
18  spinlock_t  spinlock;
19  };
20  
21  static struct dma_coherent_mem **dma_coherent_default_area;
22  
23  static inline struct dma_coherent_mem *dev_get_dma_area(struct device 
*dev)
24  {
25  if (dev && dev->dma_mem)
26  return dev->dma_mem;
27  #ifdef CONFIG_CMA
  > 28  if (dev && dev->cma_area)
29  return NULL;
30  #endif
31  return dma_coherent_default_area ? *dma_coherent_default_area : 
NULL;

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


.config.gz
Description: application/gzip

Re: [PATCH 1/2] drivers: dma-coherent: Add support for default DMA coherent pool

[kbuild test robot]

Hi George,

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.12]
[cannot apply to next-20170704]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/vitaly_kuzmichev-mentor-com/drivers-dma-coherent-Add-support-for-default-DMA-coherent-pool/20170705-040238
config: i386-randconfig-c0-07051154 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

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

   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/io.h:21,
from drivers//base/dma-coherent.c:5:
   drivers//base/dma-coherent.c: In function 'dev_get_dma_area':
>> drivers//base/dma-coherent.c:28:16: error: 'struct device' has no member 
>> named 'cma_area'
 if (dev && dev->cma_area)
   ^
   include/linux/compiler.h:160:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^
>> drivers//base/dma-coherent.c:28:2: note: in expansion of macro 'if'
 if (dev && dev->cma_area)
 ^
>> drivers//base/dma-coherent.c:28:16: error: 'struct device' has no member 
>> named 'cma_area'
 if (dev && dev->cma_area)
   ^
   include/linux/compiler.h:160:42: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^
>> drivers//base/dma-coherent.c:28:2: note: in expansion of macro 'if'
 if (dev && dev->cma_area)
 ^
>> drivers//base/dma-coherent.c:28:16: error: 'struct device' has no member 
>> named 'cma_area'
 if (dev && dev->cma_area)
   ^
   include/linux/compiler.h:171:16: note: in definition of macro '__trace_if'
  __r = !!(cond); \
   ^
>> drivers//base/dma-coherent.c:28:2: note: in expansion of macro 'if'
 if (dev && dev->cma_area)
 ^

vim +28 drivers//base/dma-coherent.c

 1  /*
 2   * Coherent per-device memory handling.
 3   * Borrowed from i386
 4   */
   > 5  #include 
 6  #include 
 7  #include 
 8  #include 
 9  #include 
10  
11  struct dma_coherent_mem {
12  void*virt_base;
13  dma_addr_t  device_base;
14  unsigned long   pfn_base;
15  int size;
16  int flags;
17  unsigned long   *bitmap;
18  spinlock_t  spinlock;
19  };
20  
21  static struct dma_coherent_mem **dma_coherent_default_area;
22  
23  static inline struct dma_coherent_mem *dev_get_dma_area(struct device 
*dev)
24  {
25  if (dev && dev->dma_mem)
26  return dev->dma_mem;
27  #ifdef CONFIG_CMA
  > 28  if (dev && dev->cma_area)
29  return NULL;
30  #endif
31  return dma_coherent_default_area ? *dma_coherent_default_area : 
NULL;

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


.config.gz
Description: application/gzip

[PATCH] mfd: Fix potential NULL pointer dereference

[Christophe JAILLET]

if 'max8998_i2c_parse_dt_pdata() fails (when out of memory), a NULL
pointer dereference will occur in the error handling code.

Return directly instead.

Fixes: ee999fb3f17f("mfd: max8998: Add support for Device Tree")
Signed-off-by: Christophe JAILLET 
---
 drivers/mfd/max8998.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/mfd/max8998.c b/drivers/mfd/max8998.c
index 4c33b8063bc3..b1d3f70782d9 100644
--- a/drivers/mfd/max8998.c
+++ b/drivers/mfd/max8998.c
@@ -192,10 +192,8 @@ static int max8998_i2c_probe(struct i2c_client *i2c,
 
if (IS_ENABLED(CONFIG_OF) && i2c->dev.of_node) {
pdata = max8998_i2c_parse_dt_pdata(>dev);
-   if (IS_ERR(pdata)) {
-   ret = PTR_ERR(pdata);
-   goto err;
-   }
+   if (IS_ERR(pdata))
+   return PTR_ERR(pdata);
}
 
i2c_set_clientdata(i2c, max8998);
-- 
2.11.0

[PATCH] mfd: Fix potential NULL pointer dereference

[Christophe JAILLET]

if 'max8998_i2c_parse_dt_pdata() fails (when out of memory), a NULL
pointer dereference will occur in the error handling code.

Return directly instead.

Fixes: ee999fb3f17f("mfd: max8998: Add support for Device Tree")
Signed-off-by: Christophe JAILLET 
---
 drivers/mfd/max8998.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/mfd/max8998.c b/drivers/mfd/max8998.c
index 4c33b8063bc3..b1d3f70782d9 100644
--- a/drivers/mfd/max8998.c
+++ b/drivers/mfd/max8998.c
@@ -192,10 +192,8 @@ static int max8998_i2c_probe(struct i2c_client *i2c,
 
if (IS_ENABLED(CONFIG_OF) && i2c->dev.of_node) {
pdata = max8998_i2c_parse_dt_pdata(>dev);
-   if (IS_ERR(pdata)) {
-   ret = PTR_ERR(pdata);
-   goto err;
-   }
+   if (IS_ERR(pdata))
+   return PTR_ERR(pdata);
}
 
i2c_set_clientdata(i2c, max8998);
-- 
2.11.0

[PATCH v3] ideapad-laptop: Add several models to no_hw_rfkill

[yjx]

From: Yang Jiaxun 

Some Lenovo ideapad models do not have hardware rfkill switches, but
trying to read the rfkill switches through the ideapad-laptop module.
It caused to always reported blocking breaking wifi.

Fix it by adding those models to no_hw_rfkill_list.

Signed-off-by: Yang Jiaxun 
---
 drivers/platform/x86/ideapad-laptop.c | 70 +++
 1 file changed, 70 insertions(+)

diff --git a/drivers/platform/x86/ideapad-laptop.c 
b/drivers/platform/x86/ideapad-laptop.c
index 24ca9fbe31cc..5f4515b88a18 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -869,6 +869,27 @@ static const struct dmi_system_id no_hw_rfkill_list[] = {
},
},
{
+   .ident = "Lenovo V310-14IKB",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo V310-14IKB"),
+   },
+   },
+   {
+   .ident = "Lenovo V310-14ISK",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo V310-14ISK"),
+   },
+   },
+   {
+   .ident = "Lenovo V310-15IKB",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo V310-15IKB"),
+   },
+   },
+   {
.ident = "Lenovo V310-15ISK",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
@@ -876,6 +897,48 @@ static const struct dmi_system_id no_hw_rfkill_list[] = {
},
},
{
+   .ident = "Lenovo ideapad 300-15IBR",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 
300-15IBR"),
+   },
+   },
+   {
+   .ident = "Lenovo ideapad 300-15IKB",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 
300-15IKB"),
+   },
+   },
+   {
+   .ident = "Lenovo ideapad 300S-11IBR",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 
300S-11BR"),
+   },
+   },
+   {
+   .ident = "Lenovo ideapad 310-15ABR",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 
310-15ABR"),
+   },
+   },
+   {
+   .ident = "Lenovo ideapad 310-15IAP",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 
310-15IAP"),
+   },
+   },
+   {
+   .ident = "Lenovo ideapad 310-15ISK",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 
310-15ISK"),
+   },
+   },
+   {
.ident = "Lenovo ideapad 310-15IKB",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
@@ -883,6 +946,13 @@ static const struct dmi_system_id no_hw_rfkill_list[] = {
},
},
{
+   .ident = "Lenovo ideapad Y700-14ISK",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 
Y700-14ISK"),
+   },
+   },
+   {
.ident = "Lenovo ideapad Y700-15ACZ",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
-- 
2.13.2

[PATCH v3] ideapad-laptop: Add several models to no_hw_rfkill

[yjx]

From: Yang Jiaxun 

Some Lenovo ideapad models do not have hardware rfkill switches, but
trying to read the rfkill switches through the ideapad-laptop module.
It caused to always reported blocking breaking wifi.

Fix it by adding those models to no_hw_rfkill_list.

Signed-off-by: Yang Jiaxun 
---
 drivers/platform/x86/ideapad-laptop.c | 70 +++
 1 file changed, 70 insertions(+)

diff --git a/drivers/platform/x86/ideapad-laptop.c 
b/drivers/platform/x86/ideapad-laptop.c
index 24ca9fbe31cc..5f4515b88a18 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -869,6 +869,27 @@ static const struct dmi_system_id no_hw_rfkill_list[] = {
},
},
{
+   .ident = "Lenovo V310-14IKB",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo V310-14IKB"),
+   },
+   },
+   {
+   .ident = "Lenovo V310-14ISK",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo V310-14ISK"),
+   },
+   },
+   {
+   .ident = "Lenovo V310-15IKB",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo V310-15IKB"),
+   },
+   },
+   {
.ident = "Lenovo V310-15ISK",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
@@ -876,6 +897,48 @@ static const struct dmi_system_id no_hw_rfkill_list[] = {
},
},
{
+   .ident = "Lenovo ideapad 300-15IBR",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 
300-15IBR"),
+   },
+   },
+   {
+   .ident = "Lenovo ideapad 300-15IKB",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 
300-15IKB"),
+   },
+   },
+   {
+   .ident = "Lenovo ideapad 300S-11IBR",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 
300S-11BR"),
+   },
+   },
+   {
+   .ident = "Lenovo ideapad 310-15ABR",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 
310-15ABR"),
+   },
+   },
+   {
+   .ident = "Lenovo ideapad 310-15IAP",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 
310-15IAP"),
+   },
+   },
+   {
+   .ident = "Lenovo ideapad 310-15ISK",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 
310-15ISK"),
+   },
+   },
+   {
.ident = "Lenovo ideapad 310-15IKB",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
@@ -883,6 +946,13 @@ static const struct dmi_system_id no_hw_rfkill_list[] = {
},
},
{
+   .ident = "Lenovo ideapad Y700-14ISK",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 
Y700-14ISK"),
+   },
+   },
+   {
.ident = "Lenovo ideapad Y700-15ACZ",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
-- 
2.13.2

[PATCH] hwtracing: coresight: constify attribute_group structures.

[Arvind Yadav]

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work with const
attribute_group. So mark the non-const structs as const.

File size before:
  text data bss dec hex filename
   2573 288 2963157 c55 coresight-etm-perf.o

File size After adding 'const':
   textdata bss dec hex filename
   2613 224 2963133 c3d coresight-etm-perf.o

Signed-off-by: Arvind Yadav 
---
 drivers/hwtracing/coresight/coresight-etm-perf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c 
b/drivers/hwtracing/coresight/coresight-etm-perf.c
index 288a423..e97775d 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -60,7 +60,7 @@ struct etm_event_data {
NULL,
 };
 
-static struct attribute_group etm_pmu_format_group = {
+static const struct attribute_group etm_pmu_format_group = {
.name   = "format",
.attrs  = etm_config_formats_attr,
 };
-- 
1.9.1

[PATCH] hwtracing: coresight: constify attribute_group structures.

[Arvind Yadav]

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work with const
attribute_group. So mark the non-const structs as const.

File size before:
  text data bss dec hex filename
   2573 288 2963157 c55 coresight-etm-perf.o

File size After adding 'const':
   textdata bss dec hex filename
   2613 224 2963133 c3d coresight-etm-perf.o

Signed-off-by: Arvind Yadav 
---
 drivers/hwtracing/coresight/coresight-etm-perf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c 
b/drivers/hwtracing/coresight/coresight-etm-perf.c
index 288a423..e97775d 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -60,7 +60,7 @@ struct etm_event_data {
NULL,
 };
 
-static struct attribute_group etm_pmu_format_group = {
+static const struct attribute_group etm_pmu_format_group = {
.name   = "format",
.attrs  = etm_config_formats_attr,
 };
-- 
1.9.1

[QUESTION] perf annotate: how do we fix the 'total period' feature ?

[Taeung Song]

Hi,

Two problems of perf-annotate were mentioned in recent PATCH reviews
by Milian and Namhyung.

Currently perf-annotate has a '--show-total-period' option
and a 't' key "Toggle total period view" on TUI browser.

However, they actually show the number of samples, not period(Raw number 
of event count of sample).

So it's a different number to the perf report like below.

For example,

  $ perf report --stdio --show-nr-sample --show-total-period -S hex2u64
...
# Overhead   SamplesPeriod  Command  Shared Object
#       ...  .
#
 3.07%36  26484668  perf perf


  $ perf annotate  --stdio --show-total-period -s hex2u64
 Percent |  Source code & Disassembly of perf for cycles:ppp (36 
samples)

-
 :
 :
 :
 :  Disassembly of section .text:
 :
 :  0053ef9e :
 :  hex2u64():
   0 :53ef9e:   push   %rbp
   0 :53ef9f:   mov%rsp,%rbp
   0 :53efa2:   sub$0x30,%rsp
   1 :53efa6:   callq  424810 


   0 :53efab:   mov%rdi,-0x28(%rbp)
   2 :53efaf:   mov%rsi,-0x30(%rbp)
...

Problems:
  1) the total period of perf-annotate is different from perf-report's
  2) perf-annotate only shows the first column as 'Percent'
 (even though the number of samples for each addr are actually printed)

So we need to just rename it ? ('total period' -> 'samples')

Or,
we should enable perf-annotate to support both features for 'periods' 
and 'samples' ?



Thanks,
Taeung

[QUESTION] perf annotate: how do we fix the 'total period' feature ?

[Taeung Song]

Hi,

Two problems of perf-annotate were mentioned in recent PATCH reviews
by Milian and Namhyung.

Currently perf-annotate has a '--show-total-period' option
and a 't' key "Toggle total period view" on TUI browser.

However, they actually show the number of samples, not period(Raw number 
of event count of sample).

So it's a different number to the perf report like below.

For example,

  $ perf report --stdio --show-nr-sample --show-total-period -S hex2u64
...
# Overhead   SamplesPeriod  Command  Shared Object
#       ...  .
#
 3.07%36  26484668  perf perf


  $ perf annotate  --stdio --show-total-period -s hex2u64
 Percent |  Source code & Disassembly of perf for cycles:ppp (36 
samples)

-
 :
 :
 :
 :  Disassembly of section .text:
 :
 :  0053ef9e :
 :  hex2u64():
   0 :53ef9e:   push   %rbp
   0 :53ef9f:   mov%rsp,%rbp
   0 :53efa2:   sub$0x30,%rsp
   1 :53efa6:   callq  424810 


   0 :53efab:   mov%rdi,-0x28(%rbp)
   2 :53efaf:   mov%rsi,-0x30(%rbp)
...

Problems:
  1) the total period of perf-annotate is different from perf-report's
  2) perf-annotate only shows the first column as 'Percent'
 (even though the number of samples for each addr are actually printed)

So we need to just rename it ? ('total period' -> 'samples')

Or,
we should enable perf-annotate to support both features for 'periods' 
and 'samples' ?



Thanks,
Taeung

[PATCH] ideapad-laptop: Add several models to no_hw_rfkill

[Yang Jiaxun]

From 8db74a4eef334f614bf727232e5b88f67f824862 Mon Sep 17 00:00:00 2001
From: Yang Jiaxun 
Date: Tue, 4 Jul 2017 11:28:41 +0800
Subject: [PATCH] ideapad-laptop: Add several models to no_hw_rfkill

Some Lenovo ideapad models do not have hardware rfkill switches, but 
trying to read the rfkill switches through the ideapad-laptop module. It 
caused to always reported blocking breaking wifi.


Fix it by adding those models to no_hw_rfkill list.

Signed-off-by: Yang Jiaxun 
---
 drivers/platform/x86/ideapad-laptop.c | 78 
+--

 1 file changed, 74 insertions(+), 4 deletions(-)

diff --git a/drivers/platform/x86/ideapad-laptop.c 
b/drivers/platform/x86/ideapad-laptop.c

index 527e5d9..3ebc5c7 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -909,17 +909,87 @@ static const struct dmi_system_id 
no_hw_rfkill_list[] = {

 },
 },
 {
+.ident = "Lenovo V310-14IKB",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo V310-14IKB"),
+},
+},
+{
+.ident = "Lenovo V310-14ISK",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo V310-14ISK"),
+},
+},
+{
+.ident = "Lenovo V310-15IKB",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo V310-15IKB"),
+},
+},
+{
 .ident = "Lenovo V310-15ISK",
 .matches = {
-DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
-DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo V310-15ISK"),
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo V310-15ISK"),
+},
+},
+{
+.ident = "Lenovo ideapad 300-15IBR",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 300-15IBR"),
+},
+},
+{
+.ident = "Lenovo ideapad 300-15IKB",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 300-15IKB"),
+},
+},
+{
+.ident = "Lenovo ideapad 300S-11IBR",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 300S-11BR"),
+},
+},
+{
+.ident = "Lenovo ideapad 310-15ABR",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 310-15ABR"),
+},
+},
+{
+.ident = "Lenovo ideapad 310-15IAP",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 310-15IAP"),
+},
+},
+{
+.ident = "Lenovo ideapad 310-15ISK",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 310-15ISK"),
 },
 },
 {
 .ident = "Lenovo ideapad 310-15IKB",
 .matches = {
-DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
-DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 310-15IKB"),
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 310-15IKB"),
+},
+},
+{
+.ident = "Lenovo ideapad Y700-14ISK",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad Y700-14ISK"),
 },
 },
 {
--
2.7.4

[PATCH] ideapad-laptop: Add several models to no_hw_rfkill

[Yang Jiaxun]

From 8db74a4eef334f614bf727232e5b88f67f824862 Mon Sep 17 00:00:00 2001
From: Yang Jiaxun 
Date: Tue, 4 Jul 2017 11:28:41 +0800
Subject: [PATCH] ideapad-laptop: Add several models to no_hw_rfkill

Some Lenovo ideapad models do not have hardware rfkill switches, but 
trying to read the rfkill switches through the ideapad-laptop module. It 
caused to always reported blocking breaking wifi.


Fix it by adding those models to no_hw_rfkill list.

Signed-off-by: Yang Jiaxun 
---
 drivers/platform/x86/ideapad-laptop.c | 78 
+--

 1 file changed, 74 insertions(+), 4 deletions(-)

diff --git a/drivers/platform/x86/ideapad-laptop.c 
b/drivers/platform/x86/ideapad-laptop.c

index 527e5d9..3ebc5c7 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -909,17 +909,87 @@ static const struct dmi_system_id 
no_hw_rfkill_list[] = {

 },
 },
 {
+.ident = "Lenovo V310-14IKB",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo V310-14IKB"),
+},
+},
+{
+.ident = "Lenovo V310-14ISK",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo V310-14ISK"),
+},
+},
+{
+.ident = "Lenovo V310-15IKB",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo V310-15IKB"),
+},
+},
+{
 .ident = "Lenovo V310-15ISK",
 .matches = {
-DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
-DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo V310-15ISK"),
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo V310-15ISK"),
+},
+},
+{
+.ident = "Lenovo ideapad 300-15IBR",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 300-15IBR"),
+},
+},
+{
+.ident = "Lenovo ideapad 300-15IKB",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 300-15IKB"),
+},
+},
+{
+.ident = "Lenovo ideapad 300S-11IBR",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 300S-11BR"),
+},
+},
+{
+.ident = "Lenovo ideapad 310-15ABR",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 310-15ABR"),
+},
+},
+{
+.ident = "Lenovo ideapad 310-15IAP",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 310-15IAP"),
+},
+},
+{
+.ident = "Lenovo ideapad 310-15ISK",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 310-15ISK"),
 },
 },
 {
 .ident = "Lenovo ideapad 310-15IKB",
 .matches = {
-DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
-DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 310-15IKB"),
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 310-15IKB"),
+},
+},
+{
+.ident = "Lenovo ideapad Y700-14ISK",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad Y700-14ISK"),
 },
 },
 {
--
2.7.4

[PATCH v2] ideapad-laptop: Add several models to no_hw_rfkill

[Yang Jiaxun]

From daaa74f5b5f8ecfad4d452af787276f8c43f79b9 Mon Sep 17 00:00:00 2001
From: Yang Jiaxun 
Date: Tue, 4 Jul 2017 13:49:41 +
Subject: [PATCH v2] ideapad-laptop: Add several models to no_hw_rfkill

Some Lenovo ideapad models do not have hardware rfkill switches, but
trying to read the rfkill switches through the ideapad-laptop module.
It caused to always reported blocking breaking wifi.

Fix it by adding those models to no_hw_rfkill_list.

Signed-off-by: Yang Jiaxun 
---
 drivers/platform/x86/ideapad-laptop.c | 70 
+++

 1 file changed, 70 insertions(+)

diff --git a/drivers/platform/x86/ideapad-laptop.c 
b/drivers/platform/x86/ideapad-laptop.c

index 24ca9fbe31cc..5f4515b88a18 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -869,6 +869,27 @@ static const struct dmi_system_id 
no_hw_rfkill_list[] = {

 },
 },
 {
+.ident = "Lenovo V310-14IKB",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo V310-14IKB"),
+},
+},
+{
+.ident = "Lenovo V310-14ISK",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo V310-14ISK"),
+},
+},
+{
+.ident = "Lenovo V310-15IKB",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo V310-15IKB"),
+},
+},
+{
 .ident = "Lenovo V310-15ISK",
 .matches = {
 DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
@@ -876,6 +897,48 @@ static const struct dmi_system_id 
no_hw_rfkill_list[] = {

 },
 },
 {
+.ident = "Lenovo ideapad 300-15IBR",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 300-15IBR"),
+},
+},
+{
+.ident = "Lenovo ideapad 300-15IKB",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 300-15IKB"),
+},
+},
+{
+.ident = "Lenovo ideapad 300S-11IBR",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 300S-11BR"),
+},
+},
+{
+.ident = "Lenovo ideapad 310-15ABR",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 310-15ABR"),
+},
+},
+{
+.ident = "Lenovo ideapad 310-15IAP",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 310-15IAP"),
+},
+},
+{
+.ident = "Lenovo ideapad 310-15ISK",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 310-15ISK"),
+},
+},
+{
 .ident = "Lenovo ideapad 310-15IKB",
 .matches = {
 DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
@@ -883,6 +946,13 @@ static const struct dmi_system_id 
no_hw_rfkill_list[] = {

 },
 },
 {
+.ident = "Lenovo ideapad Y700-14ISK",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad Y700-14ISK"),
+},
+},
+{
 .ident = "Lenovo ideapad Y700-15ACZ",
 .matches = {
 DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
--
2.13.2

[PATCH v2] ideapad-laptop: Add several models to no_hw_rfkill

[Yang Jiaxun]

From daaa74f5b5f8ecfad4d452af787276f8c43f79b9 Mon Sep 17 00:00:00 2001
From: Yang Jiaxun 
Date: Tue, 4 Jul 2017 13:49:41 +
Subject: [PATCH v2] ideapad-laptop: Add several models to no_hw_rfkill

Some Lenovo ideapad models do not have hardware rfkill switches, but
trying to read the rfkill switches through the ideapad-laptop module.
It caused to always reported blocking breaking wifi.

Fix it by adding those models to no_hw_rfkill_list.

Signed-off-by: Yang Jiaxun 
---
 drivers/platform/x86/ideapad-laptop.c | 70 
+++

 1 file changed, 70 insertions(+)

diff --git a/drivers/platform/x86/ideapad-laptop.c 
b/drivers/platform/x86/ideapad-laptop.c

index 24ca9fbe31cc..5f4515b88a18 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -869,6 +869,27 @@ static const struct dmi_system_id 
no_hw_rfkill_list[] = {

 },
 },
 {
+.ident = "Lenovo V310-14IKB",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo V310-14IKB"),
+},
+},
+{
+.ident = "Lenovo V310-14ISK",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo V310-14ISK"),
+},
+},
+{
+.ident = "Lenovo V310-15IKB",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo V310-15IKB"),
+},
+},
+{
 .ident = "Lenovo V310-15ISK",
 .matches = {
 DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
@@ -876,6 +897,48 @@ static const struct dmi_system_id 
no_hw_rfkill_list[] = {

 },
 },
 {
+.ident = "Lenovo ideapad 300-15IBR",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 300-15IBR"),
+},
+},
+{
+.ident = "Lenovo ideapad 300-15IKB",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 300-15IKB"),
+},
+},
+{
+.ident = "Lenovo ideapad 300S-11IBR",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 300S-11BR"),
+},
+},
+{
+.ident = "Lenovo ideapad 310-15ABR",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 310-15ABR"),
+},
+},
+{
+.ident = "Lenovo ideapad 310-15IAP",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 310-15IAP"),
+},
+},
+{
+.ident = "Lenovo ideapad 310-15ISK",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 310-15ISK"),
+},
+},
+{
 .ident = "Lenovo ideapad 310-15IKB",
 .matches = {
 DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
@@ -883,6 +946,13 @@ static const struct dmi_system_id 
no_hw_rfkill_list[] = {

 },
 },
 {
+.ident = "Lenovo ideapad Y700-14ISK",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad Y700-14ISK"),
+},
+},
+{
 .ident = "Lenovo ideapad Y700-15ACZ",
 .matches = {
 DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
--
2.13.2

Re: [PATCH v3] [media] mtk-vcodec: Show mtk driver error without DEBUG definition

[Hirokazu Honda]

Fixing whitespace in the previous patch.

On Wed, Jul 5, 2017 at 2:33 PM, Hirokazu Honda  wrote:
> A driver error message is shown without DEBUG definition
> to find an error and debug easily.
>
> Signed-off-by: Hirokazu Honda 
> ---
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h | 20 +---
>  1 file changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h 
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> index 237e144c194f..c1378c1b402c 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> @@ -32,6 +32,15 @@ extern int mtk_v4l2_dbg_level;
>  extern bool mtk_vcodec_dbg;
>
>
> +#define mtk_v4l2_err(fmt, args...) \
> +   pr_err("[MTK_V4L2][ERROR] %s:%d: " fmt "\n", __func__, __LINE__, \
> +  ##args)
> +
> +#define mtk_vcodec_err(h, fmt, args...)  
>   \
> +   pr_err("[MTK_VCODEC][ERROR][%d]: %s() " fmt "\n",   \
> +  ((struct mtk_vcodec_ctx *)h->ctx)->id, __func__, ##args)
> +
> +
>  #if defined(DEBUG)
>
>  #define mtk_v4l2_debug(level, fmt, args...) \
> @@ -41,11 +50,6 @@ extern bool mtk_vcodec_dbg;
> level, __func__, __LINE__, ##args);  \
> } while (0)
>
> -#define mtk_v4l2_err(fmt, args...)\
> -   pr_err("[MTK_V4L2][ERROR] %s:%d: " fmt "\n", __func__, __LINE__, \
> -  ##args)
> -
> -
>  #define mtk_v4l2_debug_enter()  mtk_v4l2_debug(3, "+")
>  #define mtk_v4l2_debug_leave()  mtk_v4l2_debug(3, "-")
>
> @@ -57,22 +61,16 @@ extern bool mtk_vcodec_dbg;
> __func__, ##args);  \
> } while (0)
>
> -#define mtk_vcodec_err(h, fmt, args...)  
>   \
> -   pr_err("[MTK_VCODEC][ERROR][%d]: %s() " fmt "\n",   \
> -  ((struct mtk_vcodec_ctx *)h->ctx)->id, __func__, ##args)
> -
>  #define mtk_vcodec_debug_enter(h)  mtk_vcodec_debug(h, "+")
>  #define mtk_vcodec_debug_leave(h)  mtk_vcodec_debug(h, "-")
>
>  #else
>
>  #define mtk_v4l2_debug(level, fmt, args...) {}
> -#define mtk_v4l2_err(fmt, args...) {}
>  #define mtk_v4l2_debug_enter() {}
>  #define mtk_v4l2_debug_leave() {}
>
>  #define mtk_vcodec_debug(h, fmt, args...) {}
> -#define mtk_vcodec_err(h, fmt, args...) {}
>  #define mtk_vcodec_debug_enter(h) {}
>  #define mtk_vcodec_debug_leave(h) {}
>
> --
> 2.13.2.725.g09c95d1e9-goog
>

Re: [PATCH v3] [media] mtk-vcodec: Show mtk driver error without DEBUG definition

[Hirokazu Honda]

Fixing whitespace in the previous patch.

On Wed, Jul 5, 2017 at 2:33 PM, Hirokazu Honda  wrote:
> A driver error message is shown without DEBUG definition
> to find an error and debug easily.
>
> Signed-off-by: Hirokazu Honda 
> ---
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h | 20 +---
>  1 file changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h 
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> index 237e144c194f..c1378c1b402c 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> @@ -32,6 +32,15 @@ extern int mtk_v4l2_dbg_level;
>  extern bool mtk_vcodec_dbg;
>
>
> +#define mtk_v4l2_err(fmt, args...) \
> +   pr_err("[MTK_V4L2][ERROR] %s:%d: " fmt "\n", __func__, __LINE__, \
> +  ##args)
> +
> +#define mtk_vcodec_err(h, fmt, args...)  
>   \
> +   pr_err("[MTK_VCODEC][ERROR][%d]: %s() " fmt "\n",   \
> +  ((struct mtk_vcodec_ctx *)h->ctx)->id, __func__, ##args)
> +
> +
>  #if defined(DEBUG)
>
>  #define mtk_v4l2_debug(level, fmt, args...) \
> @@ -41,11 +50,6 @@ extern bool mtk_vcodec_dbg;
> level, __func__, __LINE__, ##args);  \
> } while (0)
>
> -#define mtk_v4l2_err(fmt, args...)\
> -   pr_err("[MTK_V4L2][ERROR] %s:%d: " fmt "\n", __func__, __LINE__, \
> -  ##args)
> -
> -
>  #define mtk_v4l2_debug_enter()  mtk_v4l2_debug(3, "+")
>  #define mtk_v4l2_debug_leave()  mtk_v4l2_debug(3, "-")
>
> @@ -57,22 +61,16 @@ extern bool mtk_vcodec_dbg;
> __func__, ##args);  \
> } while (0)
>
> -#define mtk_vcodec_err(h, fmt, args...)  
>   \
> -   pr_err("[MTK_VCODEC][ERROR][%d]: %s() " fmt "\n",   \
> -  ((struct mtk_vcodec_ctx *)h->ctx)->id, __func__, ##args)
> -
>  #define mtk_vcodec_debug_enter(h)  mtk_vcodec_debug(h, "+")
>  #define mtk_vcodec_debug_leave(h)  mtk_vcodec_debug(h, "-")
>
>  #else
>
>  #define mtk_v4l2_debug(level, fmt, args...) {}
> -#define mtk_v4l2_err(fmt, args...) {}
>  #define mtk_v4l2_debug_enter() {}
>  #define mtk_v4l2_debug_leave() {}
>
>  #define mtk_vcodec_debug(h, fmt, args...) {}
> -#define mtk_vcodec_err(h, fmt, args...) {}
>  #define mtk_vcodec_debug_enter(h) {}
>  #define mtk_vcodec_debug_leave(h) {}
>
> --
> 2.13.2.725.g09c95d1e9-goog
>

[PATCH] hwmon: adt7475: constify attribute_group structures.

[Arvind Yadav]

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work with const
attribute_group. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
  100557032   0   1708742bf drivers/hwmon/adt7475.o

File size After adding 'const':
   textdata bss dec hex filename
  105676520   0   1708742bf drivers/hwmon/adt7475.o

Signed-off-by: Arvind Yadav 
---
 drivers/hwmon/adt7475.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/hwmon/adt7475.c b/drivers/hwmon/adt7475.c
index c803e3c..973f17a 100644
--- a/drivers/hwmon/adt7475.c
+++ b/drivers/hwmon/adt7475.c
@@ -1205,14 +1205,14 @@ static SENSOR_DEVICE_ATTR_2(pwm3_auto_point2_pwm, 
S_IRUGO | S_IWUSR, show_pwm,
NULL
 };
 
-static struct attribute_group adt7475_attr_group = { .attrs = adt7475_attrs };
-static struct attribute_group fan4_attr_group = { .attrs = fan4_attrs };
-static struct attribute_group pwm2_attr_group = { .attrs = pwm2_attrs };
-static struct attribute_group in0_attr_group = { .attrs = in0_attrs };
-static struct attribute_group in3_attr_group = { .attrs = in3_attrs };
-static struct attribute_group in4_attr_group = { .attrs = in4_attrs };
-static struct attribute_group in5_attr_group = { .attrs = in5_attrs };
-static struct attribute_group vid_attr_group = { .attrs = vid_attrs };
+static const struct attribute_group adt7475_attr_group = { .attrs = 
adt7475_attrs };
+static const struct attribute_group fan4_attr_group = { .attrs = fan4_attrs };
+static const struct attribute_group pwm2_attr_group = { .attrs = pwm2_attrs };
+static const struct attribute_group in0_attr_group = { .attrs = in0_attrs };
+static const struct attribute_group in3_attr_group = { .attrs = in3_attrs };
+static const struct attribute_group in4_attr_group = { .attrs = in4_attrs };
+static const struct attribute_group in5_attr_group = { .attrs = in5_attrs };
+static const struct attribute_group vid_attr_group = { .attrs = vid_attrs };
 
 static int adt7475_detect(struct i2c_client *client,
  struct i2c_board_info *info)
-- 
1.9.1

[PATCH] hwmon: adt7475: constify attribute_group structures.

[Arvind Yadav]

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work with const
attribute_group. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
  100557032   0   1708742bf drivers/hwmon/adt7475.o

File size After adding 'const':
   textdata bss dec hex filename
  105676520   0   1708742bf drivers/hwmon/adt7475.o

Signed-off-by: Arvind Yadav 
---
 drivers/hwmon/adt7475.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/hwmon/adt7475.c b/drivers/hwmon/adt7475.c
index c803e3c..973f17a 100644
--- a/drivers/hwmon/adt7475.c
+++ b/drivers/hwmon/adt7475.c
@@ -1205,14 +1205,14 @@ static SENSOR_DEVICE_ATTR_2(pwm3_auto_point2_pwm, 
S_IRUGO | S_IWUSR, show_pwm,
NULL
 };
 
-static struct attribute_group adt7475_attr_group = { .attrs = adt7475_attrs };
-static struct attribute_group fan4_attr_group = { .attrs = fan4_attrs };
-static struct attribute_group pwm2_attr_group = { .attrs = pwm2_attrs };
-static struct attribute_group in0_attr_group = { .attrs = in0_attrs };
-static struct attribute_group in3_attr_group = { .attrs = in3_attrs };
-static struct attribute_group in4_attr_group = { .attrs = in4_attrs };
-static struct attribute_group in5_attr_group = { .attrs = in5_attrs };
-static struct attribute_group vid_attr_group = { .attrs = vid_attrs };
+static const struct attribute_group adt7475_attr_group = { .attrs = 
adt7475_attrs };
+static const struct attribute_group fan4_attr_group = { .attrs = fan4_attrs };
+static const struct attribute_group pwm2_attr_group = { .attrs = pwm2_attrs };
+static const struct attribute_group in0_attr_group = { .attrs = in0_attrs };
+static const struct attribute_group in3_attr_group = { .attrs = in3_attrs };
+static const struct attribute_group in4_attr_group = { .attrs = in4_attrs };
+static const struct attribute_group in5_attr_group = { .attrs = in5_attrs };
+static const struct attribute_group vid_attr_group = { .attrs = vid_attrs };
 
 static int adt7475_detect(struct i2c_client *client,
  struct i2c_board_info *info)
-- 
1.9.1

[PATCH v3] [media] mtk-vcodec: Show mtk driver error without DEBUG definition

[Hirokazu Honda]

A driver error message is shown without DEBUG definition
to find an error and debug easily.

Signed-off-by: Hirokazu Honda 
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
index 237e144c194f..c1378c1b402c 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
@@ -32,6 +32,15 @@ extern int mtk_v4l2_dbg_level;
 extern bool mtk_vcodec_dbg;
 
 
+#define mtk_v4l2_err(fmt, args...) \
+   pr_err("[MTK_V4L2][ERROR] %s:%d: " fmt "\n", __func__, __LINE__, \
+  ##args)
+
+#define mtk_vcodec_err(h, fmt, args...)
\
+   pr_err("[MTK_VCODEC][ERROR][%d]: %s() " fmt "\n",   \
+  ((struct mtk_vcodec_ctx *)h->ctx)->id, __func__, ##args)
+
+
 #if defined(DEBUG)
 
 #define mtk_v4l2_debug(level, fmt, args...) \
@@ -41,11 +50,6 @@ extern bool mtk_vcodec_dbg;
level, __func__, __LINE__, ##args);  \
} while (0)
 
-#define mtk_v4l2_err(fmt, args...)\
-   pr_err("[MTK_V4L2][ERROR] %s:%d: " fmt "\n", __func__, __LINE__, \
-  ##args)
-
-
 #define mtk_v4l2_debug_enter()  mtk_v4l2_debug(3, "+")
 #define mtk_v4l2_debug_leave()  mtk_v4l2_debug(3, "-")
 
@@ -57,22 +61,16 @@ extern bool mtk_vcodec_dbg;
__func__, ##args);  \
} while (0)
 
-#define mtk_vcodec_err(h, fmt, args...)
\
-   pr_err("[MTK_VCODEC][ERROR][%d]: %s() " fmt "\n",   \
-  ((struct mtk_vcodec_ctx *)h->ctx)->id, __func__, ##args)
-
 #define mtk_vcodec_debug_enter(h)  mtk_vcodec_debug(h, "+")
 #define mtk_vcodec_debug_leave(h)  mtk_vcodec_debug(h, "-")
 
 #else
 
 #define mtk_v4l2_debug(level, fmt, args...) {}
-#define mtk_v4l2_err(fmt, args...) {}
 #define mtk_v4l2_debug_enter() {}
 #define mtk_v4l2_debug_leave() {}
 
 #define mtk_vcodec_debug(h, fmt, args...) {}
-#define mtk_vcodec_err(h, fmt, args...) {}
 #define mtk_vcodec_debug_enter(h) {}
 #define mtk_vcodec_debug_leave(h) {}
 
-- 
2.13.2.725.g09c95d1e9-goog

[PATCH v3] [media] mtk-vcodec: Show mtk driver error without DEBUG definition

[Hirokazu Honda]

A driver error message is shown without DEBUG definition
to find an error and debug easily.

Signed-off-by: Hirokazu Honda 
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
index 237e144c194f..c1378c1b402c 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
@@ -32,6 +32,15 @@ extern int mtk_v4l2_dbg_level;
 extern bool mtk_vcodec_dbg;
 
 
+#define mtk_v4l2_err(fmt, args...) \
+   pr_err("[MTK_V4L2][ERROR] %s:%d: " fmt "\n", __func__, __LINE__, \
+  ##args)
+
+#define mtk_vcodec_err(h, fmt, args...)
\
+   pr_err("[MTK_VCODEC][ERROR][%d]: %s() " fmt "\n",   \
+  ((struct mtk_vcodec_ctx *)h->ctx)->id, __func__, ##args)
+
+
 #if defined(DEBUG)
 
 #define mtk_v4l2_debug(level, fmt, args...) \
@@ -41,11 +50,6 @@ extern bool mtk_vcodec_dbg;
level, __func__, __LINE__, ##args);  \
} while (0)
 
-#define mtk_v4l2_err(fmt, args...)\
-   pr_err("[MTK_V4L2][ERROR] %s:%d: " fmt "\n", __func__, __LINE__, \
-  ##args)
-
-
 #define mtk_v4l2_debug_enter()  mtk_v4l2_debug(3, "+")
 #define mtk_v4l2_debug_leave()  mtk_v4l2_debug(3, "-")
 
@@ -57,22 +61,16 @@ extern bool mtk_vcodec_dbg;
__func__, ##args);  \
} while (0)
 
-#define mtk_vcodec_err(h, fmt, args...)
\
-   pr_err("[MTK_VCODEC][ERROR][%d]: %s() " fmt "\n",   \
-  ((struct mtk_vcodec_ctx *)h->ctx)->id, __func__, ##args)
-
 #define mtk_vcodec_debug_enter(h)  mtk_vcodec_debug(h, "+")
 #define mtk_vcodec_debug_leave(h)  mtk_vcodec_debug(h, "-")
 
 #else
 
 #define mtk_v4l2_debug(level, fmt, args...) {}
-#define mtk_v4l2_err(fmt, args...) {}
 #define mtk_v4l2_debug_enter() {}
 #define mtk_v4l2_debug_leave() {}
 
 #define mtk_vcodec_debug(h, fmt, args...) {}
-#define mtk_vcodec_err(h, fmt, args...) {}
 #define mtk_vcodec_debug_enter(h) {}
 #define mtk_vcodec_debug_leave(h) {}
 
-- 
2.13.2.725.g09c95d1e9-goog

linux-next: Tree for Jul 5

[Stephen Rothwell]

Hi all,

Please do not add any v4.14 material to you linux-next included branches
until after v4.13-rc1 has been released.

Changes since 20170704:

Non-merge commits (relative to Linus' tree): 7599
 6571 files changed, 77 insertions(+), 131931 deletions(-)



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

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

Below is a summary of the state of the merge.

I am currently merging 266 trees (counting Linus' and 41 trees of bug
fix patches pending for the current merge release).

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (19964541c231 Merge tag 'armsoc-arm64' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging fixes/master (e691abd0327d s390: fix up for "blk-mq: switch ->queue_rq 
return value to blk_status_t")
Merging kbuild-current/fixes (ad8181060788 kconfig: fix sparse warnings in 
nconfig)
Merging arc-current/for-curr (c0bc126f97fb Linux 4.12-rc7)
Merging arm-current/fixes (9e25ebfe56ec ARM: 8685/1: ensure memblock-limit is 
pmd-aligned)
Merging m68k-current/for-linus (204a2be30a7a m68k: Remove ptrace_signal_deliver)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (d6bd8194e286 powerpc/32: Avoid miscompilation 
w/GCC 4.6.3 - don't inline copy_to/from_user())
Merging sparc/master (dbd2667a4fb9 sparc64: Fix gup_huge_pmd)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (ea23b42739a2 Merge tag 'mlx5-fixes-2017-06-28' of 
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux)
Merging ipsec/master (ca3a1b856636 esp6_offload: Fix IP6CB(skb)->nhoff for ESP 
GRO)
Merging netfilter/master (91af6ba7ff16 netfilter: ebt_nflog: fix unexpected 
truncated packet)
Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (35abcd4f9f30 brcmfmac: fix uninitialized 
warning in brcmf_usb_probe_phase2())
Merging mac80211/master (4b153ca989a9 Merge tag 'mac80211-for-davem-2017-06-16' 
of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211)
Merging sound-current/for-linus (fc18282cdcba ALSA: hda - Fix unbalance of i915 
module refcount)
Merging pci-current/for-linus (98dbf5af4fdd PCI: endpoint: Select CRC32 to fix 
test build error)
Merging driver-core.current/driver-core-linus (650fc870a2ef Merge tag 
'docs-4.13' of git://git.lwn.net/linux)
Merging tty.current/tty-linus (650fc870a2ef Merge tag 'docs-4.13' of 
git://git.lwn.net/linux)
Merging usb.current/usb-linus (dec08194ffec xhci: Limit USB2 port wake support 
for AMD Promontory hosts)
Merging usb-gadget-fixes/fixes (f50b878fed33 USB: gadget: fix GPF in gadgetfs)
Merging usb-serial-fixes/usb-linus (996fab55d864 USB: serial: qcserial: new 
Sierra Wireless EM7305 device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (9605bc46433d phy: qualcomm: phy-qcom-qmp: fix application of 
sizeof to pointer)
Merging staging.current/staging-linus (650fc870a2ef Merge tag 'docs-4.13' of 
git://git.lwn.net/linux)
Merging char-misc.current/char-misc-linus (650fc870a2ef Merge tag 'docs-4.13' 
of git://git.lwn.net/linux)
Merging input-current/for-linus (9768935264c4 Input: synaptics-rmi4 - only read 
the F54 query registers which are used)
Merging crypto-current/master (019d62db54

linux-next: Tree for Jul 5

[Stephen Rothwell]

Hi all,

Please do not add any v4.14 material to you linux-next included branches
until after v4.13-rc1 has been released.

Changes since 20170704:

Non-merge commits (relative to Linus' tree): 7599
 6571 files changed, 77 insertions(+), 131931 deletions(-)



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

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

Below is a summary of the state of the merge.

I am currently merging 266 trees (counting Linus' and 41 trees of bug
fix patches pending for the current merge release).

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (19964541c231 Merge tag 'armsoc-arm64' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging fixes/master (e691abd0327d s390: fix up for "blk-mq: switch ->queue_rq 
return value to blk_status_t")
Merging kbuild-current/fixes (ad8181060788 kconfig: fix sparse warnings in 
nconfig)
Merging arc-current/for-curr (c0bc126f97fb Linux 4.12-rc7)
Merging arm-current/fixes (9e25ebfe56ec ARM: 8685/1: ensure memblock-limit is 
pmd-aligned)
Merging m68k-current/for-linus (204a2be30a7a m68k: Remove ptrace_signal_deliver)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (d6bd8194e286 powerpc/32: Avoid miscompilation 
w/GCC 4.6.3 - don't inline copy_to/from_user())
Merging sparc/master (dbd2667a4fb9 sparc64: Fix gup_huge_pmd)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (ea23b42739a2 Merge tag 'mlx5-fixes-2017-06-28' of 
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux)
Merging ipsec/master (ca3a1b856636 esp6_offload: Fix IP6CB(skb)->nhoff for ESP 
GRO)
Merging netfilter/master (91af6ba7ff16 netfilter: ebt_nflog: fix unexpected 
truncated packet)
Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (35abcd4f9f30 brcmfmac: fix uninitialized 
warning in brcmf_usb_probe_phase2())
Merging mac80211/master (4b153ca989a9 Merge tag 'mac80211-for-davem-2017-06-16' 
of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211)
Merging sound-current/for-linus (fc18282cdcba ALSA: hda - Fix unbalance of i915 
module refcount)
Merging pci-current/for-linus (98dbf5af4fdd PCI: endpoint: Select CRC32 to fix 
test build error)
Merging driver-core.current/driver-core-linus (650fc870a2ef Merge tag 
'docs-4.13' of git://git.lwn.net/linux)
Merging tty.current/tty-linus (650fc870a2ef Merge tag 'docs-4.13' of 
git://git.lwn.net/linux)
Merging usb.current/usb-linus (dec08194ffec xhci: Limit USB2 port wake support 
for AMD Promontory hosts)
Merging usb-gadget-fixes/fixes (f50b878fed33 USB: gadget: fix GPF in gadgetfs)
Merging usb-serial-fixes/usb-linus (996fab55d864 USB: serial: qcserial: new 
Sierra Wireless EM7305 device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (9605bc46433d phy: qualcomm: phy-qcom-qmp: fix application of 
sizeof to pointer)
Merging staging.current/staging-linus (650fc870a2ef Merge tag 'docs-4.13' of 
git://git.lwn.net/linux)
Merging char-misc.current/char-misc-linus (650fc870a2ef Merge tag 'docs-4.13' 
of git://git.lwn.net/linux)
Merging input-current/for-linus (9768935264c4 Input: synaptics-rmi4 - only read 
the F54 query registers which are used)
Merging crypto-current/master (019d62db54

Re: [PATCH 4.9 000/172] 4.9.36-stable review

[Greg Kroah-Hartman]

On Tue, Jul 04, 2017 at 10:02:27PM +0530, Sumit Semwal wrote:
> Hi Greg,
> 
> On 3 July 2017 at 19:03, Greg Kroah-Hartman  
> wrote:
> > This is the start of the stable review cycle for the 4.9.36 release.
> > There are 172 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed Jul  5 13:33:25 UTC 2017.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.36-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.9.y
> > and the diffstat can be found below.
> >
> Built with arm64 defconfig, and boot-tested on hikey. No regressions noted.

Great, thanks for testing and letting me know.

greg k-h

Re: [PATCH 4.9 000/172] 4.9.36-stable review

[Greg Kroah-Hartman]

On Tue, Jul 04, 2017 at 10:02:27PM +0530, Sumit Semwal wrote:
> Hi Greg,
> 
> On 3 July 2017 at 19:03, Greg Kroah-Hartman  
> wrote:
> > This is the start of the stable review cycle for the 4.9.36 release.
> > There are 172 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed Jul  5 13:33:25 UTC 2017.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.36-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.9.y
> > and the diffstat can be found below.
> >
> Built with arm64 defconfig, and boot-tested on hikey. No regressions noted.

Great, thanks for testing and letting me know.

greg k-h

[PATCH] hwmon: adc128d818: constify attribute_group structures.

[Arvind Yadav]

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work with const
attribute_group. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
   23042936   052401478 drivers/hwmon/adc128d818.o

File size After adding 'const':
   textdata bss dec hex filename
   23442872   052161460 drivers/hwmon/adc128d818.o

Signed-off-by: Arvind Yadav 
---
 drivers/hwmon/adc128d818.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwmon/adc128d818.c b/drivers/hwmon/adc128d818.c
index a557b46..bd2ca31 100644
--- a/drivers/hwmon/adc128d818.c
+++ b/drivers/hwmon/adc128d818.c
@@ -384,7 +384,7 @@ static SENSOR_DEVICE_ATTR(temp1_max_hyst, S_IWUSR | S_IRUGO,
NULL
 };
 
-static struct attribute_group adc128_group = {
+static const struct attribute_group adc128_group = {
.attrs = adc128_attrs,
.is_visible = adc128_is_visible,
 };
-- 
1.9.1

[PATCH] hwmon: adc128d818: constify attribute_group structures.

[Arvind Yadav]

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work with const
attribute_group. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
   23042936   052401478 drivers/hwmon/adc128d818.o

File size After adding 'const':
   textdata bss dec hex filename
   23442872   052161460 drivers/hwmon/adc128d818.o

Signed-off-by: Arvind Yadav 
---
 drivers/hwmon/adc128d818.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwmon/adc128d818.c b/drivers/hwmon/adc128d818.c
index a557b46..bd2ca31 100644
--- a/drivers/hwmon/adc128d818.c
+++ b/drivers/hwmon/adc128d818.c
@@ -384,7 +384,7 @@ static SENSOR_DEVICE_ATTR(temp1_max_hyst, S_IWUSR | S_IRUGO,
NULL
 };
 
-static struct attribute_group adc128_group = {
+static const struct attribute_group adc128_group = {
.attrs = adc128_attrs,
.is_visible = adc128_is_visible,
 };
-- 
1.9.1

Re: [PATCH v9 2/3] PCI: Add tango PCIe host bridge support

[Greg Kroah-Hartman]

On Wed, Jul 05, 2017 at 01:59:55AM +0200, Mason wrote:
> Do larger SoC vendors have HW devs working closely with
> Linux devs, to avoid these design bloopers?

Yes they generally do, as they have learned from their prior mistakes :)

good luck!

greg k-h

Re: [PATCH v9 2/3] PCI: Add tango PCIe host bridge support

[Greg Kroah-Hartman]

On Wed, Jul 05, 2017 at 01:59:55AM +0200, Mason wrote:
> Do larger SoC vendors have HW devs working closely with
> Linux devs, to avoid these design bloopers?

Yes they generally do, as they have learned from their prior mistakes :)

good luck!

greg k-h

[PATCH v2] hwmon: nct7802: constify attribute_group structures.

[Arvind Yadav]

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work with const
attribute_group. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
   61619400   0   155613cc9 drivers/hwmon/nct7802.o

File size After adding 'const':
   textdata bss dec hex filename
   64659080   0   155453cb9 drivers/hwmon/nct7802.o

Signed-off-by: Arvind Yadav 
---
Changes in v1:
  Subject was not correct. Now comparing size of nct7802.c

 drivers/hwmon/nct7802.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/hwmon/nct7802.c b/drivers/hwmon/nct7802.c
index 12b94b0..2876c18 100644
--- a/drivers/hwmon/nct7802.c
+++ b/drivers/hwmon/nct7802.c
@@ -704,7 +704,7 @@ static umode_t nct7802_temp_is_visible(struct kobject *kobj,
return attr->mode;
 }
 
-static struct attribute_group nct7802_temp_group = {
+static const struct attribute_group nct7802_temp_group = {
.attrs = nct7802_temp_attrs,
.is_visible = nct7802_temp_is_visible,
 };
@@ -802,7 +802,7 @@ static umode_t nct7802_in_is_visible(struct kobject *kobj,
return attr->mode;
 }
 
-static struct attribute_group nct7802_in_group = {
+static const struct attribute_group nct7802_in_group = {
.attrs = nct7802_in_attrs,
.is_visible = nct7802_in_is_visible,
 };
@@ -880,7 +880,7 @@ static umode_t nct7802_fan_is_visible(struct kobject *kobj,
return attr->mode;
 }
 
-static struct attribute_group nct7802_fan_group = {
+static const struct attribute_group nct7802_fan_group = {
.attrs = nct7802_fan_attrs,
.is_visible = nct7802_fan_is_visible,
 };
@@ -898,7 +898,7 @@ static umode_t nct7802_fan_is_visible(struct kobject *kobj,
NULL
 };
 
-static struct attribute_group nct7802_pwm_group = {
+static const struct attribute_group nct7802_pwm_group = {
.attrs = nct7802_pwm_attrs,
 };
 
@@ -1011,7 +1011,7 @@ static SENSOR_DEVICE_ATTR(pwm3_auto_point4_pwm, S_IRUGO | 
S_IWUSR,
NULL
 };
 
-static struct attribute_group nct7802_auto_point_group = {
+static const struct attribute_group nct7802_auto_point_group = {
.attrs = nct7802_auto_point_attrs,
 };
 
-- 
1.9.1

[PATCH v2] hwmon: nct7802: constify attribute_group structures.

[Arvind Yadav]

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work with const
attribute_group. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
   61619400   0   155613cc9 drivers/hwmon/nct7802.o

File size After adding 'const':
   textdata bss dec hex filename
   64659080   0   155453cb9 drivers/hwmon/nct7802.o

Signed-off-by: Arvind Yadav 
---
Changes in v1:
  Subject was not correct. Now comparing size of nct7802.c

 drivers/hwmon/nct7802.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/hwmon/nct7802.c b/drivers/hwmon/nct7802.c
index 12b94b0..2876c18 100644
--- a/drivers/hwmon/nct7802.c
+++ b/drivers/hwmon/nct7802.c
@@ -704,7 +704,7 @@ static umode_t nct7802_temp_is_visible(struct kobject *kobj,
return attr->mode;
 }
 
-static struct attribute_group nct7802_temp_group = {
+static const struct attribute_group nct7802_temp_group = {
.attrs = nct7802_temp_attrs,
.is_visible = nct7802_temp_is_visible,
 };
@@ -802,7 +802,7 @@ static umode_t nct7802_in_is_visible(struct kobject *kobj,
return attr->mode;
 }
 
-static struct attribute_group nct7802_in_group = {
+static const struct attribute_group nct7802_in_group = {
.attrs = nct7802_in_attrs,
.is_visible = nct7802_in_is_visible,
 };
@@ -880,7 +880,7 @@ static umode_t nct7802_fan_is_visible(struct kobject *kobj,
return attr->mode;
 }
 
-static struct attribute_group nct7802_fan_group = {
+static const struct attribute_group nct7802_fan_group = {
.attrs = nct7802_fan_attrs,
.is_visible = nct7802_fan_is_visible,
 };
@@ -898,7 +898,7 @@ static umode_t nct7802_fan_is_visible(struct kobject *kobj,
NULL
 };
 
-static struct attribute_group nct7802_pwm_group = {
+static const struct attribute_group nct7802_pwm_group = {
.attrs = nct7802_pwm_attrs,
 };
 
@@ -1011,7 +1011,7 @@ static SENSOR_DEVICE_ATTR(pwm3_auto_point4_pwm, S_IRUGO | 
S_IWUSR,
NULL
 };
 
-static struct attribute_group nct7802_auto_point_group = {
+static const struct attribute_group nct7802_auto_point_group = {
.attrs = nct7802_auto_point_attrs,
 };
 
-- 
1.9.1

[PATCH] hwmon: nct7802: constify attribute_group structures.

[Arvind Yadav]

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work with const
attribute_group. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
   6655 304   069591b2f drivers/hwmon/hwmon.o

File size After adding 'const':
   textdata bss dec hex filename
   6703 240   069431b1f drivers/hwmon/hwmon.o

Signed-off-by: Arvind Yadav 
---
 drivers/hwmon/nct7802.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/hwmon/nct7802.c b/drivers/hwmon/nct7802.c
index 12b94b0..2876c18 100644
--- a/drivers/hwmon/nct7802.c
+++ b/drivers/hwmon/nct7802.c
@@ -704,7 +704,7 @@ static umode_t nct7802_temp_is_visible(struct kobject *kobj,
return attr->mode;
 }
 
-static struct attribute_group nct7802_temp_group = {
+static const struct attribute_group nct7802_temp_group = {
.attrs = nct7802_temp_attrs,
.is_visible = nct7802_temp_is_visible,
 };
@@ -802,7 +802,7 @@ static umode_t nct7802_in_is_visible(struct kobject *kobj,
return attr->mode;
 }
 
-static struct attribute_group nct7802_in_group = {
+static const struct attribute_group nct7802_in_group = {
.attrs = nct7802_in_attrs,
.is_visible = nct7802_in_is_visible,
 };
@@ -880,7 +880,7 @@ static umode_t nct7802_fan_is_visible(struct kobject *kobj,
return attr->mode;
 }
 
-static struct attribute_group nct7802_fan_group = {
+static const struct attribute_group nct7802_fan_group = {
.attrs = nct7802_fan_attrs,
.is_visible = nct7802_fan_is_visible,
 };
@@ -898,7 +898,7 @@ static umode_t nct7802_fan_is_visible(struct kobject *kobj,
NULL
 };
 
-static struct attribute_group nct7802_pwm_group = {
+static const struct attribute_group nct7802_pwm_group = {
.attrs = nct7802_pwm_attrs,
 };
 
@@ -1011,7 +1011,7 @@ static SENSOR_DEVICE_ATTR(pwm3_auto_point4_pwm, S_IRUGO | 
S_IWUSR,
NULL
 };
 
-static struct attribute_group nct7802_auto_point_group = {
+static const struct attribute_group nct7802_auto_point_group = {
.attrs = nct7802_auto_point_attrs,
 };
 
-- 
1.9.1

[PATCH] hwmon: nct7802: constify attribute_group structures.

[Arvind Yadav]

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work with const
attribute_group. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
   6655 304   069591b2f drivers/hwmon/hwmon.o

File size After adding 'const':
   textdata bss dec hex filename
   6703 240   069431b1f drivers/hwmon/hwmon.o

Signed-off-by: Arvind Yadav 
---
 drivers/hwmon/nct7802.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/hwmon/nct7802.c b/drivers/hwmon/nct7802.c
index 12b94b0..2876c18 100644
--- a/drivers/hwmon/nct7802.c
+++ b/drivers/hwmon/nct7802.c
@@ -704,7 +704,7 @@ static umode_t nct7802_temp_is_visible(struct kobject *kobj,
return attr->mode;
 }
 
-static struct attribute_group nct7802_temp_group = {
+static const struct attribute_group nct7802_temp_group = {
.attrs = nct7802_temp_attrs,
.is_visible = nct7802_temp_is_visible,
 };
@@ -802,7 +802,7 @@ static umode_t nct7802_in_is_visible(struct kobject *kobj,
return attr->mode;
 }
 
-static struct attribute_group nct7802_in_group = {
+static const struct attribute_group nct7802_in_group = {
.attrs = nct7802_in_attrs,
.is_visible = nct7802_in_is_visible,
 };
@@ -880,7 +880,7 @@ static umode_t nct7802_fan_is_visible(struct kobject *kobj,
return attr->mode;
 }
 
-static struct attribute_group nct7802_fan_group = {
+static const struct attribute_group nct7802_fan_group = {
.attrs = nct7802_fan_attrs,
.is_visible = nct7802_fan_is_visible,
 };
@@ -898,7 +898,7 @@ static umode_t nct7802_fan_is_visible(struct kobject *kobj,
NULL
 };
 
-static struct attribute_group nct7802_pwm_group = {
+static const struct attribute_group nct7802_pwm_group = {
.attrs = nct7802_pwm_attrs,
 };
 
@@ -1011,7 +1011,7 @@ static SENSOR_DEVICE_ATTR(pwm3_auto_point4_pwm, S_IRUGO | 
S_IWUSR,
NULL
 };
 
-static struct attribute_group nct7802_auto_point_group = {
+static const struct attribute_group nct7802_auto_point_group = {
.attrs = nct7802_auto_point_attrs,
 };
 
-- 
1.9.1

Re: [PATCH] thermal: imx: interpret fsl,tempmon-data through nvmem

[Srinivas Kandagatla]

On 19/06/17 14:40, Leonard Crestez wrote:

On imx6sx accessing the ocotp memory area directly is wrong because the
ocotp clock needs to be enabled first. Fix this by reinterpreting the
fsl,tempmon-data phandle as a reference to a nvmem_device and doing all
the read through that.


This looks like a clear workaround to the issue, You should follow NVMEM 
bindings, not add new API to bypass these.


Am against this!


I would expect imx tempmon to use the nvmem cell to refer to the data.
You should probably fix the bindings for imx tempmon driver to address 
this issue.






This clock requirement does not apply to older imx6qdl chips because
there the ocotp access clock (clk_ipg_s) is always enabled.

This is visible by comparing the "System Clocks, Gating, and Override"
tables (OCOTP rows) in the 6DQ and 6SX manuals:
http://www.nxp.com/assets/documents/data/en/reference-manuals/IMX6SXRM.pdf
http://www.nxp.com/assets/documents/data/en/reference-manuals/IMX6DQRM.pdf

This happens to work right now without this patch because the ocotp
clock might be enabled for some other reason. In particular it might be
enabled from the bootloader and it only gets disabled late during boot
in clk_disable_unused, after imx-thermal has completed probing.

If imx-thermal is compiled as a module then the system can hang on
probe.

This makes IMX_THERMAL depend on NVMEM_IMX_OCOTP but that driver seems
be already available for all chips that contain tempmon so it's
acceptable.





Reported-by: Lothar Waßmann 
Signed-off-by: Leonard Crestez 

---

This was reported as a comment to a patch adding tempmon support for
imx6ul (which is very similar to imx6sx). Since it already affects a
supported chip this patch is sent as a separate bugfix.

Link: https://lkml.org/lkml/2017/6/9/578

There are various other ways to fix this problem. The main advantage of
this solution is that it does not add a new binding but rather preserves
compatibility with old DTBs. It also aligns with the idea that
devicetree describes hardware relationships rather than a specific linux
implementation.

An alternative would have been to add a nvmem-cells binding to imx-thermal and
use that if available instead of fsl,tempmon-data. It might not be good to
sidestep the official nvmem bindings, the devicetree people were added so that
they have an opportunity to object.
Not sure why you think nvmem bindings would change in this case, Only 
the tempmon bindings would be fixed to address the issue.




In theory the "thermal grade" is a two-bit quantity and might be a
candidate for using a cell with a "bits" binding. However this causes
the nvmem core to issue reads of length and alignment less than 4 to the
imx-ocotp driver so additional fixes might be required.

This would depend on what sride and wordsize is set in the nvmem provider.


Thanks,
srini


  drivers/nvmem/core.c   | 15 
  drivers/thermal/Kconfig|  2 +-
  drivers/thermal/imx_thermal.c  | 53 ++
  include/linux/nvmem-consumer.h |  6 +
  4 files changed, 55 insertions(+), 21 deletions(-)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 8c830a8..66502ca 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -630,6 +630,21 @@ struct nvmem_device *of_nvmem_device_get(struct 
device_node *np, const char *id)
return __nvmem_device_get(nvmem_np, NULL, NULL);
  }
  EXPORT_SYMBOL_GPL(of_nvmem_device_get);
+
+/**
+ * of_nvmem_device_phandle_get() - Get nvmem device from a given phandle
+ *
+ * @nvmem_np: Device tree node for the nvmem device
+ *
+ * Return: ERR_PTR() on error or a valid pointer to a struct nvmem_device
+ * on success.
+ */
+struct nvmem_device *of_nvmem_device_phandle_get(struct device_node *nvmem_np)
+{
+
+   return __nvmem_device_get(nvmem_np, NULL, NULL);
+}
+EXPORT_SYMBOL_GPL(of_nvmem_device_phandle_get);
  #endif
  
  /**

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index b5b5fac..a427936 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -206,7 +206,7 @@ config HISI_THERMAL
  config IMX_THERMAL
tristate "Temperature sensor driver for Freescale i.MX SoCs"
depends on (ARCH_MXC && CPU_THERMAL) || COMPILE_TEST
-   depends on MFD_SYSCON
+   depends on NVMEM_IMX_OCOTP
depends on OF
help
  Support for Temperature Monitor (TEMPMON) found on Freescale i.MX 
SoCs.
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index fb648a4..1cf35bd 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -24,6 +24,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #define REG_SET		0x4

  #define REG_CLR   0x8
@@ -55,8 +56,8 @@
  #define TEMPSENSE2_PANIC_VALUE_SHIFT  16
  #define TEMPSENSE2_PANIC_VALUE_MASK   0xfff
  
-#define OCOTP_MEM0			0x0480

-#define OCOTP_ANA1 0x04e0

Re: [PATCH] thermal: imx: interpret fsl,tempmon-data through nvmem

[Srinivas Kandagatla]

On 19/06/17 14:40, Leonard Crestez wrote:

On imx6sx accessing the ocotp memory area directly is wrong because the
ocotp clock needs to be enabled first. Fix this by reinterpreting the
fsl,tempmon-data phandle as a reference to a nvmem_device and doing all
the read through that.


This looks like a clear workaround to the issue, You should follow NVMEM 
bindings, not add new API to bypass these.


Am against this!


I would expect imx tempmon to use the nvmem cell to refer to the data.
You should probably fix the bindings for imx tempmon driver to address 
this issue.






This clock requirement does not apply to older imx6qdl chips because
there the ocotp access clock (clk_ipg_s) is always enabled.

This is visible by comparing the "System Clocks, Gating, and Override"
tables (OCOTP rows) in the 6DQ and 6SX manuals:
http://www.nxp.com/assets/documents/data/en/reference-manuals/IMX6SXRM.pdf
http://www.nxp.com/assets/documents/data/en/reference-manuals/IMX6DQRM.pdf

This happens to work right now without this patch because the ocotp
clock might be enabled for some other reason. In particular it might be
enabled from the bootloader and it only gets disabled late during boot
in clk_disable_unused, after imx-thermal has completed probing.

If imx-thermal is compiled as a module then the system can hang on
probe.

This makes IMX_THERMAL depend on NVMEM_IMX_OCOTP but that driver seems
be already available for all chips that contain tempmon so it's
acceptable.





Reported-by: Lothar Waßmann 
Signed-off-by: Leonard Crestez 

---

This was reported as a comment to a patch adding tempmon support for
imx6ul (which is very similar to imx6sx). Since it already affects a
supported chip this patch is sent as a separate bugfix.

Link: https://lkml.org/lkml/2017/6/9/578

There are various other ways to fix this problem. The main advantage of
this solution is that it does not add a new binding but rather preserves
compatibility with old DTBs. It also aligns with the idea that
devicetree describes hardware relationships rather than a specific linux
implementation.

An alternative would have been to add a nvmem-cells binding to imx-thermal and
use that if available instead of fsl,tempmon-data. It might not be good to
sidestep the official nvmem bindings, the devicetree people were added so that
they have an opportunity to object.
Not sure why you think nvmem bindings would change in this case, Only 
the tempmon bindings would be fixed to address the issue.




In theory the "thermal grade" is a two-bit quantity and might be a
candidate for using a cell with a "bits" binding. However this causes
the nvmem core to issue reads of length and alignment less than 4 to the
imx-ocotp driver so additional fixes might be required.

This would depend on what sride and wordsize is set in the nvmem provider.


Thanks,
srini


  drivers/nvmem/core.c   | 15 
  drivers/thermal/Kconfig|  2 +-
  drivers/thermal/imx_thermal.c  | 53 ++
  include/linux/nvmem-consumer.h |  6 +
  4 files changed, 55 insertions(+), 21 deletions(-)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 8c830a8..66502ca 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -630,6 +630,21 @@ struct nvmem_device *of_nvmem_device_get(struct 
device_node *np, const char *id)
return __nvmem_device_get(nvmem_np, NULL, NULL);
  }
  EXPORT_SYMBOL_GPL(of_nvmem_device_get);
+
+/**
+ * of_nvmem_device_phandle_get() - Get nvmem device from a given phandle
+ *
+ * @nvmem_np: Device tree node for the nvmem device
+ *
+ * Return: ERR_PTR() on error or a valid pointer to a struct nvmem_device
+ * on success.
+ */
+struct nvmem_device *of_nvmem_device_phandle_get(struct device_node *nvmem_np)
+{
+
+   return __nvmem_device_get(nvmem_np, NULL, NULL);
+}
+EXPORT_SYMBOL_GPL(of_nvmem_device_phandle_get);
  #endif
  
  /**

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index b5b5fac..a427936 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -206,7 +206,7 @@ config HISI_THERMAL
  config IMX_THERMAL
tristate "Temperature sensor driver for Freescale i.MX SoCs"
depends on (ARCH_MXC && CPU_THERMAL) || COMPILE_TEST
-   depends on MFD_SYSCON
+   depends on NVMEM_IMX_OCOTP
depends on OF
help
  Support for Temperature Monitor (TEMPMON) found on Freescale i.MX 
SoCs.
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index fb648a4..1cf35bd 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -24,6 +24,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #define REG_SET		0x4

  #define REG_CLR   0x8
@@ -55,8 +56,8 @@
  #define TEMPSENSE2_PANIC_VALUE_SHIFT  16
  #define TEMPSENSE2_PANIC_VALUE_MASK   0xfff
  
-#define OCOTP_MEM0			0x0480

-#define OCOTP_ANA1 0x04e0
+#define OCOTP_MEM0_OFFSET  32
+#define 

[GIT PULL] gcc-plugins updates for v4.13-rc1

[Kees Cook]

Hi,

Please pull these gcc-plugins changes for v4.13-rc1. The big part is
the randstruct plugin infrastructure. This is the first of two expected
pull requests for randstruct since there are dependencies in other
trees that would be easier to merge once those have landed. Notably,
the IPC allocation refactoring in -mm, and many trivial merge conflicts
across several trees when applying the __randomize_layout annotation. As
a result, it seemed like I should send this now since it is relatively
self-contained, and once the rest of the trees have landed, send the
annotation patches. I'm expecting the final phase of randstruct (automatic
struct selection) will land for v4.14, but if its other tree dependencies
actually make it for v4.13, I can send that merge request too.

Thanks!

-Kees

The following changes since commit 6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c:

  Linux 4.12 (2017-07-02 16:07:02 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git 
tags/gcc-plugins-v4.13-rc1

for you to fetch changes up to d1185a8c5dd21182012e6dd531b00fd72f4d30cb:

  Merge branch 'merge/randstruct' into for-next/gcc-plugins (2017-07-04 
21:41:31 -0700)


GCC plugin updates:
- typo fix in Kconfig (Jean Delvare)
- randstruct infrastructure


Arnd Bergmann (1):
  ARM: Prepare for randomized task_struct

Jean Delvare (1):
  Fix English in description of GCC_PLUGIN_STRUCTLEAK

Kees Cook (9):
  gcc-plugins: Detail c-common.h location for GCC 4.6
  compiler: Add __designated_init annotation
  gcc-plugins: Add the randstruct plugin
  randstruct: Whitelist struct security_hook_heads cast
  randstruct: Whitelist UNIXCB cast
  randstruct: Whitelist big_key path struct overloading
  randstruct: Whitelist NIU struct page overloading
  Merge branch 'for-next/gcc-plugin-infrastructure' into merge/randstruct
  Merge branch 'merge/randstruct' into for-next/gcc-plugins

 Documentation/dontdiff|2 +
 arch/Kconfig  |   41 +-
 arch/arm/include/asm/assembler.h  |2 +
 arch/arm/kernel/entry-armv.S  |5 +-
 arch/arm/mm/proc-macros.S |   10 +-
 include/linux/compiler-gcc.h  |   13 +
 include/linux/compiler.h  |   12 +
 include/linux/vermagic.h  |9 +-
 scripts/Makefile.gcc-plugins  |4 +
 scripts/gcc-plugins/.gitignore|1 +
 scripts/gcc-plugins/Makefile  |8 +
 scripts/gcc-plugins/gcc-common.h  |   12 +
 scripts/gcc-plugins/gen-random-seed.sh|8 +
 scripts/gcc-plugins/randomize_layout_plugin.c | 1028 +
 14 files changed, 1146 insertions(+), 9 deletions(-)
 create mode 100644 scripts/gcc-plugins/.gitignore
 create mode 100644 scripts/gcc-plugins/gen-random-seed.sh
 create mode 100644 scripts/gcc-plugins/randomize_layout_plugin.c

-- 
Kees Cook
Pixel Security

[GIT PULL] gcc-plugins updates for v4.13-rc1

[Kees Cook]

Hi,

Please pull these gcc-plugins changes for v4.13-rc1. The big part is
the randstruct plugin infrastructure. This is the first of two expected
pull requests for randstruct since there are dependencies in other
trees that would be easier to merge once those have landed. Notably,
the IPC allocation refactoring in -mm, and many trivial merge conflicts
across several trees when applying the __randomize_layout annotation. As
a result, it seemed like I should send this now since it is relatively
self-contained, and once the rest of the trees have landed, send the
annotation patches. I'm expecting the final phase of randstruct (automatic
struct selection) will land for v4.14, but if its other tree dependencies
actually make it for v4.13, I can send that merge request too.

Thanks!

-Kees

The following changes since commit 6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c:

  Linux 4.12 (2017-07-02 16:07:02 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git 
tags/gcc-plugins-v4.13-rc1

for you to fetch changes up to d1185a8c5dd21182012e6dd531b00fd72f4d30cb:

  Merge branch 'merge/randstruct' into for-next/gcc-plugins (2017-07-04 
21:41:31 -0700)


GCC plugin updates:
- typo fix in Kconfig (Jean Delvare)
- randstruct infrastructure


Arnd Bergmann (1):
  ARM: Prepare for randomized task_struct

Jean Delvare (1):
  Fix English in description of GCC_PLUGIN_STRUCTLEAK

Kees Cook (9):
  gcc-plugins: Detail c-common.h location for GCC 4.6
  compiler: Add __designated_init annotation
  gcc-plugins: Add the randstruct plugin
  randstruct: Whitelist struct security_hook_heads cast
  randstruct: Whitelist UNIXCB cast
  randstruct: Whitelist big_key path struct overloading
  randstruct: Whitelist NIU struct page overloading
  Merge branch 'for-next/gcc-plugin-infrastructure' into merge/randstruct
  Merge branch 'merge/randstruct' into for-next/gcc-plugins

 Documentation/dontdiff|2 +
 arch/Kconfig  |   41 +-
 arch/arm/include/asm/assembler.h  |2 +
 arch/arm/kernel/entry-armv.S  |5 +-
 arch/arm/mm/proc-macros.S |   10 +-
 include/linux/compiler-gcc.h  |   13 +
 include/linux/compiler.h  |   12 +
 include/linux/vermagic.h  |9 +-
 scripts/Makefile.gcc-plugins  |4 +
 scripts/gcc-plugins/.gitignore|1 +
 scripts/gcc-plugins/Makefile  |8 +
 scripts/gcc-plugins/gcc-common.h  |   12 +
 scripts/gcc-plugins/gen-random-seed.sh|8 +
 scripts/gcc-plugins/randomize_layout_plugin.c | 1028 +
 14 files changed, 1146 insertions(+), 9 deletions(-)
 create mode 100644 scripts/gcc-plugins/.gitignore
 create mode 100644 scripts/gcc-plugins/gen-random-seed.sh
 create mode 100644 scripts/gcc-plugins/randomize_layout_plugin.c

-- 
Kees Cook
Pixel Security

Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread

[Sergey Senozhatsky]

Hello,

Petr, thanks for commenting/taking a look

On (07/04/17 16:03), Petr Mladek wrote:
> On Fri 2017-06-30 21:42:24, Sergey Senozhatsky wrote:
> > Hello,
> > 
> > On (06/30/17 13:54), Petr Mladek wrote:
> > > > but.
> > > > the opposite possibility is that messages either won't be printed
> > > > soon (until next printk or console_unlock()) or won't be printed
> > > > ever at all (in case of sudden system death). I don't think it's
> > > > a good alternative.
> > > 
> > > I see it like a weighing machine. There is a "guaranteed" output on
> > > one side and a softlockups prevention on the other side. The more
> > > we prevent the softlockups the less we guarantee the output.
> > 
> > I apply a very simple litmus test. if the answer to the question
> > "so we leave console_unlock() and there are pending messages,
> > who and when is going to flush the remaining messages?" is
> > "something sometime in the future" then it's a no-no.
> >
> > "something sometime in the future" is equal to "no one".
> 
> I am afraid that it is hard or even impossible to have offloading
> and be sure that the other side continues. IMHO, there always
> will be a possibility that something could go wrong.
> 
> I think that resisting on keeping the current guarantees might
> force use to keep the current code (status quo).
> 
> Please, let me better explain the problems that I see with
> the current code.
> 
> 
> > > My main unresolved doubts about this patchset are:
> > > 
> > > 1. It gives other processes only very small change to take
> > >over the job. They either need to call console_trylock()
> > >in very small "race" window or they need to call
> > >console_lock(). Where console_lock() only signalizes
> > >that the caller is willing to take the job and puts
> > >him into sleep.
> > 
> > printk_kthread does console_lock().
> 
> But this is not enough. In fact, it makes things worse. Let me
> explain:
> 
> We are talking about flood of messages when we go over
> atomic_print_limit and activate offloading. Let's look
> at it in more details:
> 
> CPU0  CPU1
> 
> 
> console_unlock()
> 
>   // handle atomic_print_limit lines
>   // enable offloading
> 
>   wake_up_process(printk_kthread)
> 
>   // handly many other lines
> 
>   // printk_kthread finally gets CPU
>   // waken in printk_kthread_func()
> 
>   console_lock()
> down()
>   // lock most likely taken by CPU0
>   list_add_tail()
>   schedule()
> 
>// handle one more line
>up_console_sem()
>  list_del()
>  wake_up_process(waiter->task)
> 
>console_trylock()
>// fails because the lock is
>// taken by the waiter
> 
> Regression 1: Nobody flushes the messages to the console until
>   the printk_kthread() is scheduled again, really takes
>   the console_lock(), and calls console_unlock().

yeah, ok. I'm not sure I can fully agree that this is a regression.

this is how the code is meant to work, isn't it?
some other CPU could have slept on console_sem from e.g. tty_open()
by the time CPU0 attempts to re-take the lock, forcing CPU0
  a) to fail to console_trylock()
and
  b) delay flush of the pending messages.

so, sorry, I'm sure I see why this is a regression. the behaviour
is pretty much the same. what am I missing?

... yet, after offloading we leave console_unlock() with the knowledge
that there is a process in console_sem waiting for that lock. which
sounds like something, but at the same... that's pretty much it.
IOW, "so what?". we just know that there is a process in the waiter
list. if we can't be sure that wake_up_process() from up_console_sem()
succeeds, then that knowledge doesn't buy us anything at all. real
guarantees (console_sem owner is running on some CPU are a bit harder
to achieve, given that console_unlock() can schedule).

so I think I'll drop that "wait for a new console_sem owner" thing
after all. not because we still can't agree on it, but because may
be it's not worth it. sorry, it took me so long.


>   The original code flushed the messages
>   all the time until all were flushed. (Except
>   if it was allowed to sleep in console_unlock).

but any console_lock()/console_trylock() call from any other CPU
(fbcon, tty, etc.) prevents complete flush of the pending messages
until that other CPU invokes console_unlock(). we don't introduce
anything new here.

> Regression 2: printk_kthread() takes console_lock() in
>  preemtible context => is allowed to sleep
>  and nobody is able to get console_lock
>  in the meantime => slowdown and risk of
>  lost messages.

do you mean scheduling under console_sem? but this is true for
console_unlock() in general. we already schedule with console_sem,
quite a lot. I can't see how 

Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread

[Sergey Senozhatsky]

Hello,

Petr, thanks for commenting/taking a look

On (07/04/17 16:03), Petr Mladek wrote:
> On Fri 2017-06-30 21:42:24, Sergey Senozhatsky wrote:
> > Hello,
> > 
> > On (06/30/17 13:54), Petr Mladek wrote:
> > > > but.
> > > > the opposite possibility is that messages either won't be printed
> > > > soon (until next printk or console_unlock()) or won't be printed
> > > > ever at all (in case of sudden system death). I don't think it's
> > > > a good alternative.
> > > 
> > > I see it like a weighing machine. There is a "guaranteed" output on
> > > one side and a softlockups prevention on the other side. The more
> > > we prevent the softlockups the less we guarantee the output.
> > 
> > I apply a very simple litmus test. if the answer to the question
> > "so we leave console_unlock() and there are pending messages,
> > who and when is going to flush the remaining messages?" is
> > "something sometime in the future" then it's a no-no.
> >
> > "something sometime in the future" is equal to "no one".
> 
> I am afraid that it is hard or even impossible to have offloading
> and be sure that the other side continues. IMHO, there always
> will be a possibility that something could go wrong.
> 
> I think that resisting on keeping the current guarantees might
> force use to keep the current code (status quo).
> 
> Please, let me better explain the problems that I see with
> the current code.
> 
> 
> > > My main unresolved doubts about this patchset are:
> > > 
> > > 1. It gives other processes only very small change to take
> > >over the job. They either need to call console_trylock()
> > >in very small "race" window or they need to call
> > >console_lock(). Where console_lock() only signalizes
> > >that the caller is willing to take the job and puts
> > >him into sleep.
> > 
> > printk_kthread does console_lock().
> 
> But this is not enough. In fact, it makes things worse. Let me
> explain:
> 
> We are talking about flood of messages when we go over
> atomic_print_limit and activate offloading. Let's look
> at it in more details:
> 
> CPU0  CPU1
> 
> 
> console_unlock()
> 
>   // handle atomic_print_limit lines
>   // enable offloading
> 
>   wake_up_process(printk_kthread)
> 
>   // handly many other lines
> 
>   // printk_kthread finally gets CPU
>   // waken in printk_kthread_func()
> 
>   console_lock()
> down()
>   // lock most likely taken by CPU0
>   list_add_tail()
>   schedule()
> 
>// handle one more line
>up_console_sem()
>  list_del()
>  wake_up_process(waiter->task)
> 
>console_trylock()
>// fails because the lock is
>// taken by the waiter
> 
> Regression 1: Nobody flushes the messages to the console until
>   the printk_kthread() is scheduled again, really takes
>   the console_lock(), and calls console_unlock().

yeah, ok. I'm not sure I can fully agree that this is a regression.

this is how the code is meant to work, isn't it?
some other CPU could have slept on console_sem from e.g. tty_open()
by the time CPU0 attempts to re-take the lock, forcing CPU0
  a) to fail to console_trylock()
and
  b) delay flush of the pending messages.

so, sorry, I'm sure I see why this is a regression. the behaviour
is pretty much the same. what am I missing?

... yet, after offloading we leave console_unlock() with the knowledge
that there is a process in console_sem waiting for that lock. which
sounds like something, but at the same... that's pretty much it.
IOW, "so what?". we just know that there is a process in the waiter
list. if we can't be sure that wake_up_process() from up_console_sem()
succeeds, then that knowledge doesn't buy us anything at all. real
guarantees (console_sem owner is running on some CPU are a bit harder
to achieve, given that console_unlock() can schedule).

so I think I'll drop that "wait for a new console_sem owner" thing
after all. not because we still can't agree on it, but because may
be it's not worth it. sorry, it took me so long.


>   The original code flushed the messages
>   all the time until all were flushed. (Except
>   if it was allowed to sleep in console_unlock).

but any console_lock()/console_trylock() call from any other CPU
(fbcon, tty, etc.) prevents complete flush of the pending messages
until that other CPU invokes console_unlock(). we don't introduce
anything new here.

> Regression 2: printk_kthread() takes console_lock() in
>  preemtible context => is allowed to sleep
>  and nobody is able to get console_lock
>  in the meantime => slowdown and risk of
>  lost messages.

do you mean scheduling under console_sem? but this is true for
console_unlock() in general. we already schedule with console_sem,
quite a lot. I can't see how 

[PATCH] hwmon: constify attribute_group structures.

[Arvind Yadav]

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work with const
attribute_group. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
   6655 304   069591b2f drivers/hwmon/hwmon.o

File size After adding 'const':
   textdata bss dec hex filename
   6703 240   069431b1f drivers/hwmon/hwmon.o

Signed-off-by: Arvind Yadav 
---
 drivers/hwmon/hwmon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c
index dd6e17c..2ac578a 100644
--- a/drivers/hwmon/hwmon.c
+++ b/drivers/hwmon/hwmon.c
@@ -85,7 +85,7 @@ static umode_t hwmon_dev_name_is_visible(struct kobject *kobj,
return attr->mode;
 }
 
-static struct attribute_group hwmon_dev_attr_group = {
+static const struct attribute_group hwmon_dev_attr_group = {
.attrs  = hwmon_dev_attrs,
.is_visible = hwmon_dev_name_is_visible,
 };
-- 
1.9.1

[PATCH] hwmon: constify attribute_group structures.

[Arvind Yadav]

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work with const
attribute_group. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
   6655 304   069591b2f drivers/hwmon/hwmon.o

File size After adding 'const':
   textdata bss dec hex filename
   6703 240   069431b1f drivers/hwmon/hwmon.o

Signed-off-by: Arvind Yadav 
---
 drivers/hwmon/hwmon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c
index dd6e17c..2ac578a 100644
--- a/drivers/hwmon/hwmon.c
+++ b/drivers/hwmon/hwmon.c
@@ -85,7 +85,7 @@ static umode_t hwmon_dev_name_is_visible(struct kobject *kobj,
return attr->mode;
 }
 
-static struct attribute_group hwmon_dev_attr_group = {
+static const struct attribute_group hwmon_dev_attr_group = {
.attrs  = hwmon_dev_attrs,
.is_visible = hwmon_dev_name_is_visible,
 };
-- 
1.9.1

Re: [PATCH v2 1/6] cpufreq: schedutil: ignore sugov kthreads

[Viresh Kumar]

On 04-07-17, 18:34, Patrick Bellasi wrote:
> In system where multiple CPUs shares the same frequency domain a small
> workload on a CPU can still be subject to frequency spikes, generated by
> the activation of the sugov's kthread.
> 
> Since the sugov kthread is a special RT task, which goal is just that to
> activate a frequency transition, it does not make sense for it to bias
> the schedutil's frequency selection policy.
> 
> This patch exploits the information related to the current task to silently
> ignore cpufreq_update_this_cpu() calls, coming from the RT scheduler, while
> the sugov kthread is running.
> 
> Signed-off-by: Patrick Bellasi 
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Rafael J. Wysocki 
> Cc: Viresh Kumar 
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
> 
> ---
> Changes from v1:
> - move check before policy spinlock (JuriL)
> ---
>  kernel/sched/cpufreq_schedutil.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/kernel/sched/cpufreq_schedutil.c 
> b/kernel/sched/cpufreq_schedutil.c
> index c982dd0..eaba6d6 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -218,6 +218,10 @@ static void sugov_update_single(struct update_util_data 
> *hook, u64 time,
>   unsigned int next_f;
>   bool busy;
>  
> + /* Skip updates generated by sugov kthreads */
> + if (unlikely(current == sg_policy->thread))
> + return;
> +
>   sugov_set_iowait_boost(sg_cpu, time, flags);
>   sg_cpu->last_update = time;
>  
> @@ -290,6 +294,10 @@ static void sugov_update_shared(struct update_util_data 
> *hook, u64 time,
>   unsigned long util, max;
>   unsigned int next_f;
>  
> + /* Skip updates generated by sugov kthreads */
> + if (unlikely(current == sg_policy->thread))
> + return;
> +
>   sugov_get_util(, );

Yes we discussed this last time as well (I looked again at those discussions and
am still confused a bit), but wanted to clarify one more time.

After the 2nd patch of this series is applied, why will we still have this
problem? As we concluded it last time, the problem wouldn't happen until the
time the sugov RT thread is running (Hint: work_in_progress). And once the sugov
RT thread is gone, one of the other scheduling classes will take over and should
update the flag pretty quickly.

Are we worried about the time between the sugov RT thread finishes and when the
CFS or IDLE sched class call the util handler again? If yes, then we will still
have that problem for any normal RT/DL task. Isn't it ?

-- 
viresh

Re: [PATCH v2 1/6] cpufreq: schedutil: ignore sugov kthreads

[Viresh Kumar]

On 04-07-17, 18:34, Patrick Bellasi wrote:
> In system where multiple CPUs shares the same frequency domain a small
> workload on a CPU can still be subject to frequency spikes, generated by
> the activation of the sugov's kthread.
> 
> Since the sugov kthread is a special RT task, which goal is just that to
> activate a frequency transition, it does not make sense for it to bias
> the schedutil's frequency selection policy.
> 
> This patch exploits the information related to the current task to silently
> ignore cpufreq_update_this_cpu() calls, coming from the RT scheduler, while
> the sugov kthread is running.
> 
> Signed-off-by: Patrick Bellasi 
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Rafael J. Wysocki 
> Cc: Viresh Kumar 
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
> 
> ---
> Changes from v1:
> - move check before policy spinlock (JuriL)
> ---
>  kernel/sched/cpufreq_schedutil.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/kernel/sched/cpufreq_schedutil.c 
> b/kernel/sched/cpufreq_schedutil.c
> index c982dd0..eaba6d6 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -218,6 +218,10 @@ static void sugov_update_single(struct update_util_data 
> *hook, u64 time,
>   unsigned int next_f;
>   bool busy;
>  
> + /* Skip updates generated by sugov kthreads */
> + if (unlikely(current == sg_policy->thread))
> + return;
> +
>   sugov_set_iowait_boost(sg_cpu, time, flags);
>   sg_cpu->last_update = time;
>  
> @@ -290,6 +294,10 @@ static void sugov_update_shared(struct update_util_data 
> *hook, u64 time,
>   unsigned long util, max;
>   unsigned int next_f;
>  
> + /* Skip updates generated by sugov kthreads */
> + if (unlikely(current == sg_policy->thread))
> + return;
> +
>   sugov_get_util(, );

Yes we discussed this last time as well (I looked again at those discussions and
am still confused a bit), but wanted to clarify one more time.

After the 2nd patch of this series is applied, why will we still have this
problem? As we concluded it last time, the problem wouldn't happen until the
time the sugov RT thread is running (Hint: work_in_progress). And once the sugov
RT thread is gone, one of the other scheduling classes will take over and should
update the flag pretty quickly.

Are we worried about the time between the sugov RT thread finishes and when the
CFS or IDLE sched class call the util handler again? If yes, then we will still
have that problem for any normal RT/DL task. Isn't it ?

-- 
viresh

Re: [PATCH v2 2/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter

[Viresh Kumar]

On 04-07-17, 18:34, Patrick Bellasi wrote:
> diff --git a/include/linux/sched/cpufreq.h b/include/linux/sched/cpufreq.h
> index d2be2cc..36ac8d2 100644
> --- a/include/linux/sched/cpufreq.h
> +++ b/include/linux/sched/cpufreq.h
> @@ -10,6 +10,7 @@
>  #define SCHED_CPUFREQ_RT (1U << 0)
>  #define SCHED_CPUFREQ_DL (1U << 1)
>  #define SCHED_CPUFREQ_IOWAIT (1U << 2)
> +#define SCHED_CPUFREQ_IDLE   (1U << 3)
>  
>  #define SCHED_CPUFREQ_RT_DL  (SCHED_CPUFREQ_RT | SCHED_CPUFREQ_DL)
>  
> diff --git a/kernel/sched/cpufreq_schedutil.c 
> b/kernel/sched/cpufreq_schedutil.c
> index eaba6d6..004ae18 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -304,6 +304,12 @@ static void sugov_update_shared(struct update_util_data 
> *hook, u64 time,
>  
>   sg_cpu->util = util;
>   sg_cpu->max = max;
> +
> + /* CPU is entering IDLE, reset flags without triggering an update */
> + if (unlikely(flags & SCHED_CPUFREQ_IDLE)) {
> + sg_cpu->flags = 0;
> + goto done;
> + }

Why is it important to have the above diff at all ? For example we aren't doing
similar stuff in sugov_update_single() and that will go on and try to change the
frequency if rate_limit_us time is over since last update.

And also why is it important to write 0 to sg_cpu->flags ? What wouldn't work if
we set sg_cpu->flags to SCHED_CPUFREQ_IDLE in this case ? i.e. Just the below
statement should be good for us.

>   sg_cpu->flags = flags;
>  
>   sugov_set_iowait_boost(sg_cpu, time, flags);
> @@ -318,6 +324,7 @@ static void sugov_update_shared(struct update_util_data 
> *hook, u64 time,
>   sugov_update_commit(sg_policy, time, next_f);
>   }
>  
> +done:
>   raw_spin_unlock(_policy->update_lock);
>  }
>  
> diff --git a/kernel/sched/idle_task.c b/kernel/sched/idle_task.c
> index 0c00172..a844c91 100644
> --- a/kernel/sched/idle_task.c
> +++ b/kernel/sched/idle_task.c
> @@ -29,6 +29,10 @@ pick_next_task_idle(struct rq *rq, struct task_struct 
> *prev, struct rq_flags *rf
>   put_prev_task(rq, prev);
>   update_idle_core(rq);
>   schedstat_inc(rq->sched_goidle);
> +
> + /* kick cpufreq (see the comment in kernel/sched/sched.h). */
> + cpufreq_update_this_cpu(rq, SCHED_CPUFREQ_IDLE);
> +

This looks correct.

Can we completely avoid the utilization contribution of the CPUs which have gone
idle? Right now we avoid them with help of (delta_ns > TICK_NSEC). Can we
instead check this SCHED_CPUFREQ_IDLE flag ?

-- 
viresh

Re: [PATCH v2 2/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter

[Viresh Kumar]

On 04-07-17, 18:34, Patrick Bellasi wrote:
> diff --git a/include/linux/sched/cpufreq.h b/include/linux/sched/cpufreq.h
> index d2be2cc..36ac8d2 100644
> --- a/include/linux/sched/cpufreq.h
> +++ b/include/linux/sched/cpufreq.h
> @@ -10,6 +10,7 @@
>  #define SCHED_CPUFREQ_RT (1U << 0)
>  #define SCHED_CPUFREQ_DL (1U << 1)
>  #define SCHED_CPUFREQ_IOWAIT (1U << 2)
> +#define SCHED_CPUFREQ_IDLE   (1U << 3)
>  
>  #define SCHED_CPUFREQ_RT_DL  (SCHED_CPUFREQ_RT | SCHED_CPUFREQ_DL)
>  
> diff --git a/kernel/sched/cpufreq_schedutil.c 
> b/kernel/sched/cpufreq_schedutil.c
> index eaba6d6..004ae18 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -304,6 +304,12 @@ static void sugov_update_shared(struct update_util_data 
> *hook, u64 time,
>  
>   sg_cpu->util = util;
>   sg_cpu->max = max;
> +
> + /* CPU is entering IDLE, reset flags without triggering an update */
> + if (unlikely(flags & SCHED_CPUFREQ_IDLE)) {
> + sg_cpu->flags = 0;
> + goto done;
> + }

Why is it important to have the above diff at all ? For example we aren't doing
similar stuff in sugov_update_single() and that will go on and try to change the
frequency if rate_limit_us time is over since last update.

And also why is it important to write 0 to sg_cpu->flags ? What wouldn't work if
we set sg_cpu->flags to SCHED_CPUFREQ_IDLE in this case ? i.e. Just the below
statement should be good for us.

>   sg_cpu->flags = flags;
>  
>   sugov_set_iowait_boost(sg_cpu, time, flags);
> @@ -318,6 +324,7 @@ static void sugov_update_shared(struct update_util_data 
> *hook, u64 time,
>   sugov_update_commit(sg_policy, time, next_f);
>   }
>  
> +done:
>   raw_spin_unlock(_policy->update_lock);
>  }
>  
> diff --git a/kernel/sched/idle_task.c b/kernel/sched/idle_task.c
> index 0c00172..a844c91 100644
> --- a/kernel/sched/idle_task.c
> +++ b/kernel/sched/idle_task.c
> @@ -29,6 +29,10 @@ pick_next_task_idle(struct rq *rq, struct task_struct 
> *prev, struct rq_flags *rf
>   put_prev_task(rq, prev);
>   update_idle_core(rq);
>   schedstat_inc(rq->sched_goidle);
> +
> + /* kick cpufreq (see the comment in kernel/sched/sched.h). */
> + cpufreq_update_this_cpu(rq, SCHED_CPUFREQ_IDLE);
> +

This looks correct.

Can we completely avoid the utilization contribution of the CPUs which have gone
idle? Right now we avoid them with help of (delta_ns > TICK_NSEC). Can we
instead check this SCHED_CPUFREQ_IDLE flag ?

-- 
viresh

Re: [PATCH] powerpc/mm: fix a hardcode on memory boundary checking

[Anshuman Khandual]

On 01/12/2017 02:39 PM, Rui Teng wrote:
> The offset of hugepage block will not be 16G, if the expected
> page is more than one. Calculate the totol size instead of the
> hardcode value.
> 
> Signed-off-by: Rui Teng 

I have a redundant patch, this one is the original.

Tested-by: Anshuman Khandual 

Re: [PATCH] powerpc/mm: fix a hardcode on memory boundary checking

[Anshuman Khandual]

On 01/12/2017 02:39 PM, Rui Teng wrote:
> The offset of hugepage block will not be 16G, if the expected
> page is more than one. Calculate the totol size instead of the
> hardcode value.
> 
> Signed-off-by: Rui Teng 

I have a redundant patch, this one is the original.

Tested-by: Anshuman Khandual 

Re: [PATCH] powerpc/mm: Implemented default_hugepagesz verification for powerpc

[Anshuman Khandual]

On 07/04/2017 01:35 AM, Victor Aoqui wrote:
> Implemented default hugepage size verification (default_hugepagesz=)
> in order to allow allocation of defined number of pages (hugepages=)
> only for supported hugepage sizes.
> 
> Signed-off-by: Victor Aoqui 
> ---
>  arch/powerpc/mm/hugetlbpage.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
> index a4f33de..464e72e 100644
> --- a/arch/powerpc/mm/hugetlbpage.c
> +++ b/arch/powerpc/mm/hugetlbpage.c
> @@ -797,6 +797,21 @@ static int __init hugepage_setup_sz(char *str)
>  }
>  __setup("hugepagesz=", hugepage_setup_sz);
> 
> +static int __init default_hugepage_setup_sz(char *str)

The function name should be hugetlb_default_size_setup in
sync with the generic function hugetlb_default_setup for the
same parameter default_hugepagesz.

> +{
> +unsigned long long size;
> +
> +size = memparse(str, );
> +
> +if (add_huge_page_size(size) != 0) {

I am little bit confused here. Do we always follow another
'hugepages=' element after 'default_hugepagesz' ? If not,
then we dont have to do 'add_huge_page_size'. But then
that function checks for valid huge page sizes and skips
adding hstate if its already added. So I guess it okay.

> +hugetlb_bad_size();
> +pr_err("Invalid default huge page size specified(%llu)\n", 
> size);

Error message should have 'ppc' some where to indicate that
the arch rejected the size not core MM.

Re: [PATCH] powerpc/mm: Implemented default_hugepagesz verification for powerpc

[Anshuman Khandual]

On 07/04/2017 01:35 AM, Victor Aoqui wrote:
> Implemented default hugepage size verification (default_hugepagesz=)
> in order to allow allocation of defined number of pages (hugepages=)
> only for supported hugepage sizes.
> 
> Signed-off-by: Victor Aoqui 
> ---
>  arch/powerpc/mm/hugetlbpage.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
> index a4f33de..464e72e 100644
> --- a/arch/powerpc/mm/hugetlbpage.c
> +++ b/arch/powerpc/mm/hugetlbpage.c
> @@ -797,6 +797,21 @@ static int __init hugepage_setup_sz(char *str)
>  }
>  __setup("hugepagesz=", hugepage_setup_sz);
> 
> +static int __init default_hugepage_setup_sz(char *str)

The function name should be hugetlb_default_size_setup in
sync with the generic function hugetlb_default_setup for the
same parameter default_hugepagesz.

> +{
> +unsigned long long size;
> +
> +size = memparse(str, );
> +
> +if (add_huge_page_size(size) != 0) {

I am little bit confused here. Do we always follow another
'hugepages=' element after 'default_hugepagesz' ? If not,
then we dont have to do 'add_huge_page_size'. But then
that function checks for valid huge page sizes and skips
adding hstate if its already added. So I guess it okay.

> +hugetlb_bad_size();
> +pr_err("Invalid default huge page size specified(%llu)\n", 
> size);

Error message should have 'ppc' some where to indicate that
the arch rejected the size not core MM.

[GIT PULL] pstore updates for v4.13-rc1

[Kees Cook]

Hi,

Please pull these pstore changes for v4.13-rc1.

Thanks!

-Kees

The following changes since commit 5ed02dbb497422bf225783f46e6eadd237d23d6b:

  Linux 4.12-rc3 (2017-05-28 17:20:53 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git 
tags/pstore-v4.13-rc1

for you to fetch changes up to 0752e4028c003fba1e2b44c4b3cf6a4482e931b6:

  powerpc/nvram: use memdup_user (2017-06-27 17:02:50 -0700)


Various fixes and tweaks for the pstore subsystem. Highlights:
- use memdup_user() instead of open-coded copies (Geliang Tang)
- fix record memory leak during initialization (Douglas Anderson)
- avoid confused compressed record warning (Ankit Kumar)
- prepopulate record timestamp and remove redundant logic from backends


Ankit Kumar (1):
  pstore: Don't warn if data is uncompressed and type is not 
PSTORE_TYPE_DMESG

Douglas Anderson (1):
  pstore: Fix leaked pstore_record in pstore_get_backend_records()

Geliang Tang (2):
  pstore: use memdup_user
  powerpc/nvram: use memdup_user

Kees Cook (5):
  pstore: Avoid potential infinite loop
  efi-pstore: Refactor erase routine
  pstore: Create common record initializer
  pstore: Populate pstore record->time field
  pstore: Fix format string to use %u for record id

 arch/powerpc/kernel/nvram_64.c| 14 +++
 drivers/firmware/efi/efi-pstore.c | 87 +--
 fs/pstore/inode.c | 22 +-
 fs/pstore/internal.h  |  2 +
 fs/pstore/platform.c  | 69 ---
 fs/pstore/pmsg.c  | 10 ++---
 fs/pstore/ram.c   | 16 +++
 include/linux/pstore.h|  5 ++-
 8 files changed, 114 insertions(+), 111 deletions(-)

-- 
Kees Cook
Pixel Security

[GIT PULL] pstore updates for v4.13-rc1

[Kees Cook]

Hi,

Please pull these pstore changes for v4.13-rc1.

Thanks!

-Kees

The following changes since commit 5ed02dbb497422bf225783f46e6eadd237d23d6b:

  Linux 4.12-rc3 (2017-05-28 17:20:53 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git 
tags/pstore-v4.13-rc1

for you to fetch changes up to 0752e4028c003fba1e2b44c4b3cf6a4482e931b6:

  powerpc/nvram: use memdup_user (2017-06-27 17:02:50 -0700)


Various fixes and tweaks for the pstore subsystem. Highlights:
- use memdup_user() instead of open-coded copies (Geliang Tang)
- fix record memory leak during initialization (Douglas Anderson)
- avoid confused compressed record warning (Ankit Kumar)
- prepopulate record timestamp and remove redundant logic from backends


Ankit Kumar (1):
  pstore: Don't warn if data is uncompressed and type is not 
PSTORE_TYPE_DMESG

Douglas Anderson (1):
  pstore: Fix leaked pstore_record in pstore_get_backend_records()

Geliang Tang (2):
  pstore: use memdup_user
  powerpc/nvram: use memdup_user

Kees Cook (5):
  pstore: Avoid potential infinite loop
  efi-pstore: Refactor erase routine
  pstore: Create common record initializer
  pstore: Populate pstore record->time field
  pstore: Fix format string to use %u for record id

 arch/powerpc/kernel/nvram_64.c| 14 +++
 drivers/firmware/efi/efi-pstore.c | 87 +--
 fs/pstore/inode.c | 22 +-
 fs/pstore/internal.h  |  2 +
 fs/pstore/platform.c  | 69 ---
 fs/pstore/pmsg.c  | 10 ++---
 fs/pstore/ram.c   | 16 +++
 include/linux/pstore.h|  5 ++-
 8 files changed, 114 insertions(+), 111 deletions(-)

-- 
Kees Cook
Pixel Security

Re: [PATCH] powerpc/mm: Implemented default_hugepagesz verification for powerpc

[Aneesh Kumar K.V]

On Tuesday 04 July 2017 01:35 AM, Victor Aoqui wrote:

Implemented default hugepage size verification (default_hugepagesz=)
in order to allow allocation of defined number of pages (hugepages=)
only for supported hugepage sizes.

Signed-off-by: Victor Aoqui 
---
  arch/powerpc/mm/hugetlbpage.c | 15 +++
  1 file changed, 15 insertions(+)

diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index a4f33de..464e72e 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -797,6 +797,21 @@ static int __init hugepage_setup_sz(char *str)
  }
  __setup("hugepagesz=", hugepage_setup_sz);

+static int __init default_hugepage_setup_sz(char *str)
+{
+unsigned long long size;
+
+size = memparse(str, );
+
+if (add_huge_page_size(size) != 0) {
+hugetlb_bad_size();
+pr_err("Invalid default huge page size specified(%llu)\n", 
size);
+}
+
+return 1;
+}
+__setup("default_hugepagesz=", default_hugepage_setup_sz);


isn't that a behavior change in what we have now ? . Right now if size 
specified is not supported, we fallback to HPAGE_SIZE.


mm/hugetlb.c

if (!size_to_hstate(default_hstate_size)) {
default_hstate_size = HPAGE_SIZE;
if (!size_to_hstate(default_hstate_size))
hugetlb_add_hstate(HUGETLB_PAGE_ORDER);
}



+
  struct kmem_cache *hugepte_cache;
  static int __init hugetlbpage_init(void)
  {



Even if we want to do this, this should be done in generic code and 
should not be powerpc specific


-aneesh

Re: [PATCH] powerpc/mm: Implemented default_hugepagesz verification for powerpc

[Aneesh Kumar K.V]

On Tuesday 04 July 2017 01:35 AM, Victor Aoqui wrote:

Implemented default hugepage size verification (default_hugepagesz=)
in order to allow allocation of defined number of pages (hugepages=)
only for supported hugepage sizes.

Signed-off-by: Victor Aoqui 
---
  arch/powerpc/mm/hugetlbpage.c | 15 +++
  1 file changed, 15 insertions(+)

diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index a4f33de..464e72e 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -797,6 +797,21 @@ static int __init hugepage_setup_sz(char *str)
  }
  __setup("hugepagesz=", hugepage_setup_sz);

+static int __init default_hugepage_setup_sz(char *str)
+{
+unsigned long long size;
+
+size = memparse(str, );
+
+if (add_huge_page_size(size) != 0) {
+hugetlb_bad_size();
+pr_err("Invalid default huge page size specified(%llu)\n", 
size);
+}
+
+return 1;
+}
+__setup("default_hugepagesz=", default_hugepage_setup_sz);


isn't that a behavior change in what we have now ? . Right now if size 
specified is not supported, we fallback to HPAGE_SIZE.


mm/hugetlb.c

if (!size_to_hstate(default_hstate_size)) {
default_hstate_size = HPAGE_SIZE;
if (!size_to_hstate(default_hstate_size))
hugetlb_add_hstate(HUGETLB_PAGE_ORDER);
}



+
  struct kmem_cache *hugepte_cache;
  static int __init hugetlbpage_init(void)
  {



Even if we want to do this, this should be done in generic code and 
should not be powerpc specific


-aneesh

Re: [PATCH v2 3/3] dt-bindings: cpufreq: enhance MediaTek cpufreq dt-binding document

[Viresh Kumar]

On 05-07-17, 02:55, sean.w...@mediatek.com wrote:
> From: Sean Wang 
> 
> Update binding document with adding operating-points-v2 as the required
> property and the cooling level as the optional properties and adding more
> examples guiding people how to use MediaTek cpufreq driver for MediaTek
> SoCs.
> 
> Signed-off-by: Sean Wang 
> ---
>  .../bindings/cpufreq/cpufreq-mediatek.txt  | 170 
> -
>  1 file changed, 167 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt 
> b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
> index 52b457c..e919ca7 100644
> --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
> @@ -1,4 +1,5 @@
> -Device Tree Clock bindins for CPU DVFS of Mediatek MT8173 SoC
> +Binding for MediaTek's CPUFreq driver
> +=
>  
>  Required properties:
>  - clocks: A list of phandle + clock-specifier pairs for the clocks listed in 
> clock names.
> @@ -9,6 +10,8 @@ Required properties:
> transition and not stable yet.
>   Please refer to 
> Documentation/devicetree/bindings/clk/clock-bindings.txt for
>   generic clock consumer properties.
> +- operating-points-v2: Pleaser refer to 
> Documentation/devicetree/bindings/opp/opp.txt

s/Pleaser/Please

-- 
viresh

Re: [PATCH v2 0/3] some fixups for MediaTek cpufreq driver

[Viresh Kumar]

On 05-07-17, 02:55, sean.w...@mediatek.com wrote:
> From: Sean Wang 
> 
> Changes since v1:
> - drop those patches already accepted
> - refine the commit messages and Kconfig dependency
> - Kconfig menu entry and file name itself are updated with more
> generic name to drop "MT8173" since this driver actually supports
> all MediaTek SoCs.
> - generate patchset again with git format-patch -C -M --thread=shallow
> - fix binding examples by replacing '@' with '-' as the OPP nodes will
> never have a "reg" property.
> 
> Hi,
> 
> The purpose of the series is
> - (patch 1 to 3) to fix up current Mediatek cpufreq driver
> can't work with the latest tree since one required CPU clock muxer missing
> would cause the driver getting the resource fails when driver probe gets
> called.
> - (patch 4) to enable cpufreq feature on MT2701/MT7623 platform.
> - (patch 5 to 6) to update the binding document to reflect
> latest driver logic and add more examples guiding people how to apply for
> Mediatek cpufreq driver.
> 
> Sean Wang (3):
>   cpufreq: mediatek: Add support of cpufreq to MT2701/MT7623 SoC
>   dt-bindings: cpufreq: move MediaTek cpufreq dt-bindings document to
> proper place
>   dt-bindings: cpufreq: enhance MediaTek cpufreq dt-binding document

Just a minor comment on 3/3.

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v2 3/3] dt-bindings: cpufreq: enhance MediaTek cpufreq dt-binding document

[Viresh Kumar]

On 05-07-17, 02:55, sean.w...@mediatek.com wrote:
> From: Sean Wang 
> 
> Update binding document with adding operating-points-v2 as the required
> property and the cooling level as the optional properties and adding more
> examples guiding people how to use MediaTek cpufreq driver for MediaTek
> SoCs.
> 
> Signed-off-by: Sean Wang 
> ---
>  .../bindings/cpufreq/cpufreq-mediatek.txt  | 170 
> -
>  1 file changed, 167 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt 
> b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
> index 52b457c..e919ca7 100644
> --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
> @@ -1,4 +1,5 @@
> -Device Tree Clock bindins for CPU DVFS of Mediatek MT8173 SoC
> +Binding for MediaTek's CPUFreq driver
> +=
>  
>  Required properties:
>  - clocks: A list of phandle + clock-specifier pairs for the clocks listed in 
> clock names.
> @@ -9,6 +10,8 @@ Required properties:
> transition and not stable yet.
>   Please refer to 
> Documentation/devicetree/bindings/clk/clock-bindings.txt for
>   generic clock consumer properties.
> +- operating-points-v2: Pleaser refer to 
> Documentation/devicetree/bindings/opp/opp.txt

s/Pleaser/Please

-- 
viresh

Re: [PATCH v2 0/3] some fixups for MediaTek cpufreq driver

[Viresh Kumar]

On 05-07-17, 02:55, sean.w...@mediatek.com wrote:
> From: Sean Wang 
> 
> Changes since v1:
> - drop those patches already accepted
> - refine the commit messages and Kconfig dependency
> - Kconfig menu entry and file name itself are updated with more
> generic name to drop "MT8173" since this driver actually supports
> all MediaTek SoCs.
> - generate patchset again with git format-patch -C -M --thread=shallow
> - fix binding examples by replacing '@' with '-' as the OPP nodes will
> never have a "reg" property.
> 
> Hi,
> 
> The purpose of the series is
> - (patch 1 to 3) to fix up current Mediatek cpufreq driver
> can't work with the latest tree since one required CPU clock muxer missing
> would cause the driver getting the resource fails when driver probe gets
> called.
> - (patch 4) to enable cpufreq feature on MT2701/MT7623 platform.
> - (patch 5 to 6) to update the binding document to reflect
> latest driver logic and add more examples guiding people how to apply for
> Mediatek cpufreq driver.
> 
> Sean Wang (3):
>   cpufreq: mediatek: Add support of cpufreq to MT2701/MT7623 SoC
>   dt-bindings: cpufreq: move MediaTek cpufreq dt-bindings document to
> proper place
>   dt-bindings: cpufreq: enhance MediaTek cpufreq dt-binding document

Just a minor comment on 3/3.

Acked-by: Viresh Kumar 

-- 
viresh

[PATCH] Revert "f2fs: fix to clean previous mount option when remount_fs"

[Chao Yu]

From: Chao Yu 

Don't clear old mount option before parse new option during ->remount_fs
like other generic filesystems.

This reverts commit 2c8a4366debae30ae37d0688b2bec92d196a.

Signed-off-by: Chao Yu 
---
 fs/f2fs/super.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index f27c141cd8aa..af472f7968d0 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -846,7 +846,6 @@ static int f2fs_remount(struct super_block *sb, int *flags, 
char *data)
clear_sbi_flag(sbi, SBI_NEED_SB_WRITE);
}
 
-   sbi->mount_opt.opt = 0;
default_options(sbi);
 
/* parse mount options */
-- 
2.13.0.90.g1eb437020

[PATCH] Revert "f2fs: fix to clean previous mount option when remount_fs"

[Chao Yu]

From: Chao Yu 

Don't clear old mount option before parse new option during ->remount_fs
like other generic filesystems.

This reverts commit 2c8a4366debae30ae37d0688b2bec92d196a.

Signed-off-by: Chao Yu 
---
 fs/f2fs/super.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index f27c141cd8aa..af472f7968d0 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -846,7 +846,6 @@ static int f2fs_remount(struct super_block *sb, int *flags, 
char *data)
clear_sbi_flag(sbi, SBI_NEED_SB_WRITE);
}
 
-   sbi->mount_opt.opt = 0;
default_options(sbi);
 
/* parse mount options */
-- 
2.13.0.90.g1eb437020

Re: [PATCH v5 3/6] dt-bindings: List devicetree binding for the CCU of Allwinner A20

[Chen-Yu Tsai]

On Wed, Jul 5, 2017 at 4:04 AM, Priit Laes  wrote:
> Allwinner A20 is now driven by sunxi-ng CCU driver.
>
> Add devicetree binding for it.
>
> Acked-by: Rob Herring 
> Signed-off-by: Priit Laes 

Reviewed-by: Chen-Yu Tsai 

Re: [PATCH v5 3/6] dt-bindings: List devicetree binding for the CCU of Allwinner A20

[Chen-Yu Tsai]

On Wed, Jul 5, 2017 at 4:04 AM, Priit Laes  wrote:
> Allwinner A20 is now driven by sunxi-ng CCU driver.
>
> Add devicetree binding for it.
>
> Acked-by: Rob Herring 
> Signed-off-by: Priit Laes 

Reviewed-by: Chen-Yu Tsai 

Re: [PATCH v5 4/6] dt-bindings: List devicetree binding for the CCU of Allwinner A10

[Chen-Yu Tsai]

On Wed, Jul 5, 2017 at 4:04 AM, Priit Laes  wrote:
> Allwinner A10 is now driven by sunxi-ng CCU driver.
>
> Add devicetree binding for it.
>
> Acked-by: Rob Herring 
> Signed-off-by: Priit Laes 

Reviewed-by: Chen-Yu Tsai 

Re: [PATCH v5 1/6] clk: sunxi-ng: div: Add support for fixed post-divider

[Chen-Yu Tsai]

On Wed, Jul 5, 2017 at 4:04 AM, Priit Laes  wrote:
> SATA clock on sun4i/sun7i is of type (parent) / M / 6 where
> 6 is fixed post-divider.
>
> Signed-off-by: Priit Laes 

Reviewed-by: Chen-Yu Tsai 

Re: [PATCH v5 4/6] dt-bindings: List devicetree binding for the CCU of Allwinner A10

[Chen-Yu Tsai]

On Wed, Jul 5, 2017 at 4:04 AM, Priit Laes  wrote:
> Allwinner A10 is now driven by sunxi-ng CCU driver.
>
> Add devicetree binding for it.
>
> Acked-by: Rob Herring 
> Signed-off-by: Priit Laes 

Reviewed-by: Chen-Yu Tsai 

Re: [PATCH v5 1/6] clk: sunxi-ng: div: Add support for fixed post-divider

[Chen-Yu Tsai]

On Wed, Jul 5, 2017 at 4:04 AM, Priit Laes  wrote:
> SATA clock on sun4i/sun7i is of type (parent) / M / 6 where
> 6 is fixed post-divider.
>
> Signed-off-by: Priit Laes 

Reviewed-by: Chen-Yu Tsai 

Re: [PATCH 2/2] f2fs: reuse original mount option in ->remount_fs

[Chao Yu]

On 2017/7/1 15:48, Jaegeuk Kim wrote:
> On 06/29, Chao Yu wrote:
>> From: Chao Yu 
>>
>> Don't clear old mount option before parse new option during ->remount_fs
>> like other generic filesystems.
> 
> So, what happened on your original patch?
> 
> commit 2c8a4366debae30ae37d0688b2bec92d196a
> f2fs: fix to clean previous mount option when remount_fs

I think that patch is wrong, since the manual doesn't describe kernel logic,
so I'd like revert that patch, then f2fs ->remount_fs logic is more like
generic filesystem.

Thanks,

> 
> I think we need to rever the original patch tho.>
> Thanks,
> 
>>
>> Signed-off-by: Chao Yu 
>> ---
>>  fs/f2fs/super.c | 1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
>> index f27c141cd8aa..af472f7968d0 100644
>> --- a/fs/f2fs/super.c
>> +++ b/fs/f2fs/super.c
>> @@ -846,7 +846,6 @@ static int f2fs_remount(struct super_block *sb, int 
>> *flags, char *data)
>>  clear_sbi_flag(sbi, SBI_NEED_SB_WRITE);
>>  }
>>  
>> -sbi->mount_opt.opt = 0;
>>  default_options(sbi);
>>  
>>  /* parse mount options */
>> -- 
>> 2.13.0.90.g1eb437020

Re: [PATCH 2/2] f2fs: reuse original mount option in ->remount_fs

[Chao Yu]

On 2017/7/1 15:48, Jaegeuk Kim wrote:
> On 06/29, Chao Yu wrote:
>> From: Chao Yu 
>>
>> Don't clear old mount option before parse new option during ->remount_fs
>> like other generic filesystems.
> 
> So, what happened on your original patch?
> 
> commit 2c8a4366debae30ae37d0688b2bec92d196a
> f2fs: fix to clean previous mount option when remount_fs

I think that patch is wrong, since the manual doesn't describe kernel logic,
so I'd like revert that patch, then f2fs ->remount_fs logic is more like
generic filesystem.

Thanks,

> 
> I think we need to rever the original patch tho.>
> Thanks,
> 
>>
>> Signed-off-by: Chao Yu 
>> ---
>>  fs/f2fs/super.c | 1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
>> index f27c141cd8aa..af472f7968d0 100644
>> --- a/fs/f2fs/super.c
>> +++ b/fs/f2fs/super.c
>> @@ -846,7 +846,6 @@ static int f2fs_remount(struct super_block *sb, int 
>> *flags, char *data)
>>  clear_sbi_flag(sbi, SBI_NEED_SB_WRITE);
>>  }
>>  
>> -sbi->mount_opt.opt = 0;
>>  default_options(sbi);
>>  
>>  /* parse mount options */
>> -- 
>> 2.13.0.90.g1eb437020

[PATCH] cpufreq: speedstep: remove unnecessary static in speedstep_detect_chipset()

[Gustavo A. R. Silva]

Remove unnecessary static on local variable hostbridge.
Such variable is initialized before being used,
on every execution path throughout the function.
The static has no benefit and, removing it reduces
the code size.

This issue was detected using Coccinelle and the following semantic patch:

@bad exists@
position p;
identifier x;
type T;
@@

static T x@p;
...
x = <+...x...+>

@@
identifier x;
expression e;
type T;
position p != bad.p;
@@

-static
 T x@p;
 ... when != x
 when strict
?x = e;

In the following log you can see the difference in the code size. Also,
there is a significant difference in the bss segment. This log is the
output of the size command, before and after the code change:

before:
   textdata bss dec hex filename
   50843392 2568732221c drivers/cpufreq/speedstep-ich.o

after:
   textdata bss dec hex filename
   50623304 1928558216e drivers/cpufreq/speedstep-ich.o

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/cpufreq/speedstep-ich.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/speedstep-ich.c b/drivers/cpufreq/speedstep-ich.c
index b86953a..0412a24 100644
--- a/drivers/cpufreq/speedstep-ich.c
+++ b/drivers/cpufreq/speedstep-ich.c
@@ -207,7 +207,7 @@ static unsigned int speedstep_detect_chipset(void)
 * 8100 which use a pretty old revision of the 82815
 * host bridge. Abort on these systems.
 */
-   static struct pci_dev *hostbridge;
+   struct pci_dev *hostbridge;
 
hostbridge  = pci_get_subsys(PCI_VENDOR_ID_INTEL,
  PCI_DEVICE_ID_INTEL_82815_MC,
-- 
2.5.0

[PATCH] cpufreq: speedstep: remove unnecessary static in speedstep_detect_chipset()

[Gustavo A. R. Silva]

Remove unnecessary static on local variable hostbridge.
Such variable is initialized before being used,
on every execution path throughout the function.
The static has no benefit and, removing it reduces
the code size.

This issue was detected using Coccinelle and the following semantic patch:

@bad exists@
position p;
identifier x;
type T;
@@

static T x@p;
...
x = <+...x...+>

@@
identifier x;
expression e;
type T;
position p != bad.p;
@@

-static
 T x@p;
 ... when != x
 when strict
?x = e;

In the following log you can see the difference in the code size. Also,
there is a significant difference in the bss segment. This log is the
output of the size command, before and after the code change:

before:
   textdata bss dec hex filename
   50843392 2568732221c drivers/cpufreq/speedstep-ich.o

after:
   textdata bss dec hex filename
   50623304 1928558216e drivers/cpufreq/speedstep-ich.o

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/cpufreq/speedstep-ich.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/speedstep-ich.c b/drivers/cpufreq/speedstep-ich.c
index b86953a..0412a24 100644
--- a/drivers/cpufreq/speedstep-ich.c
+++ b/drivers/cpufreq/speedstep-ich.c
@@ -207,7 +207,7 @@ static unsigned int speedstep_detect_chipset(void)
 * 8100 which use a pretty old revision of the 82815
 * host bridge. Abort on these systems.
 */
-   static struct pci_dev *hostbridge;
+   struct pci_dev *hostbridge;
 
hostbridge  = pci_get_subsys(PCI_VENDOR_ID_INTEL,
  PCI_DEVICE_ID_INTEL_82815_MC,
-- 
2.5.0

Re: [PATCH] cpufreq: speedstep: remove unnecessary static in speedstep_detect_chipset()

[Viresh Kumar]

+ Dominic,

On 04-07-17, 22:09, Gustavo A. R. Silva wrote:
> Remove unnecessary static on local variable hostbridge.
> Such variable is initialized before being used,
> on every execution path throughout the function.
> The static has no benefit and, removing it reduces
> the code size.
> 
> This issue was detected using Coccinelle and the following semantic patch:
> 
> @bad exists@
> position p;
> identifier x;
> type T;
> @@
> 
> static T x@p;
> ...
> x = <+...x...+>
> 
> @@
> identifier x;
> expression e;
> type T;
> position p != bad.p;
> @@
> 
> -static
>  T x@p;
>  ... when != x
>  when strict
> ?x = e;
> 
> In the following log you can see the difference in the code size. Also,
> there is a significant difference in the bss segment. This log is the
> output of the size command, before and after the code change:
> 
> before:
>textdata bss dec hex filename
>50843392 2568732221c drivers/cpufreq/speedstep-ich.o
> 
> after:
>textdata bss dec hex filename
>50623304 1928558216e drivers/cpufreq/speedstep-ich.o
> 
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/cpufreq/speedstep-ich.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/speedstep-ich.c b/drivers/cpufreq/speedstep-ich.c
> index b86953a..0412a24 100644
> --- a/drivers/cpufreq/speedstep-ich.c
> +++ b/drivers/cpufreq/speedstep-ich.c
> @@ -207,7 +207,7 @@ static unsigned int speedstep_detect_chipset(void)
>* 8100 which use a pretty old revision of the 82815
>* host bridge. Abort on these systems.
>*/
> - static struct pci_dev *hostbridge;
> + struct pci_dev *hostbridge;

This was added way back Sep'02 by Dominic (@Dominic: I hope you are the same
Dominic with a different email id) and I don't think we need it to be static
here. Anyway, Dominic can respond on that.

commit 1673f3b404bd ("[PATCH] CPUfreq i386 drivers update")

(Note: You can find it in history kernel git repo, not the current one).

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH] cpufreq: speedstep: remove unnecessary static in speedstep_detect_chipset()

[Viresh Kumar]

+ Dominic,

On 04-07-17, 22:09, Gustavo A. R. Silva wrote:
> Remove unnecessary static on local variable hostbridge.
> Such variable is initialized before being used,
> on every execution path throughout the function.
> The static has no benefit and, removing it reduces
> the code size.
> 
> This issue was detected using Coccinelle and the following semantic patch:
> 
> @bad exists@
> position p;
> identifier x;
> type T;
> @@
> 
> static T x@p;
> ...
> x = <+...x...+>
> 
> @@
> identifier x;
> expression e;
> type T;
> position p != bad.p;
> @@
> 
> -static
>  T x@p;
>  ... when != x
>  when strict
> ?x = e;
> 
> In the following log you can see the difference in the code size. Also,
> there is a significant difference in the bss segment. This log is the
> output of the size command, before and after the code change:
> 
> before:
>textdata bss dec hex filename
>50843392 2568732221c drivers/cpufreq/speedstep-ich.o
> 
> after:
>textdata bss dec hex filename
>50623304 1928558216e drivers/cpufreq/speedstep-ich.o
> 
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/cpufreq/speedstep-ich.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/speedstep-ich.c b/drivers/cpufreq/speedstep-ich.c
> index b86953a..0412a24 100644
> --- a/drivers/cpufreq/speedstep-ich.c
> +++ b/drivers/cpufreq/speedstep-ich.c
> @@ -207,7 +207,7 @@ static unsigned int speedstep_detect_chipset(void)
>* 8100 which use a pretty old revision of the 82815
>* host bridge. Abort on these systems.
>*/
> - static struct pci_dev *hostbridge;
> + struct pci_dev *hostbridge;

This was added way back Sep'02 by Dominic (@Dominic: I hope you are the same
Dominic with a different email id) and I don't think we need it to be static
here. Anyway, Dominic can respond on that.

commit 1673f3b404bd ("[PATCH] CPUfreq i386 drivers update")

(Note: You can find it in history kernel git repo, not the current one).

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v4 2/2] PCI: iproc: add device shutdown for PCI RC

[Ray Jui]

Hi Oza,

It looks like you missed my comments during the internal review. See my 
comments inline below.



On 7/4/2017 8:08 PM, Oza Pawandeep wrote:

PERST must be asserted around ~500ms before the reboot is applied.

During soft reset (e.g., "reboot" from Linux) on some iproc based SOCs
LCPLL clock and PERST both goes off simultaneously.
This will cause certain Endpoints Intel NVMe not get detected, upon
next boot sequence.

This is specifically happening with Intel P3700 400GB series.
Endpoint is expecting the clock for some amount of time after PERST is
asserted, which is not happening in Stingray (iproc based SOC).
This causes NVMe to behave in undefined way.

On the contrary Intel x86 boards, will have ref clock running, so we
do not see this behavior there.

Besides, PCI spec does not stipulate about such timings.
In-fact it does not tell us, whether PCIe device should consider
refclk to be available or not to be.

It is completely up to vendor to design their EP the way they want
with respect to ref clock availability.

500ms is just based on the observation and taken as safe margin.
This patch adds platform shutdown where it should be
called in device_shutdown while reboot command is issued.
So in sequence first Endpoint Shutdown (e.g. nvme_shutdown)
followed by RC shutdown, which issues safe PERST assertion.

Signed-off-by: Oza Pawandeep 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 

diff --git a/drivers/pci/host/pcie-iproc-platform.c 
b/drivers/pci/host/pcie-iproc-platform.c
index 90d2bdd..9512960 100644
--- a/drivers/pci/host/pcie-iproc-platform.c
+++ b/drivers/pci/host/pcie-iproc-platform.c
@@ -131,6 +131,13 @@ static int iproc_pcie_pltfm_remove(struct platform_device 
*pdev)
return iproc_pcie_remove(pcie);
  }
  
+static void iproc_pcie_pltfm_shutdown(struct platform_device *pdev)

+{
+   struct iproc_pcie *pcie = platform_get_drvdata(pdev);
+
+   iproc_pcie_shutdown(pcie);
+}
+
  static struct platform_driver iproc_pcie_pltfm_driver = {
.driver = {
.name = "iproc-pcie",
@@ -138,6 +145,7 @@ static int iproc_pcie_pltfm_remove(struct platform_device 
*pdev)
},
.probe = iproc_pcie_pltfm_probe,
.remove = iproc_pcie_pltfm_remove,
+   .shutdown = iproc_pcie_pltfm_shutdown,
  };
  module_platform_driver(iproc_pcie_pltfm_driver);
  
diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c

index b0abcd7..d1bcdc9 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -616,32 +616,40 @@ static int iproc_pcie_config_write32(struct pci_bus *bus, 
unsigned int devfn,
.write = iproc_pcie_config_write32,
  };
  
-static void iproc_pcie_reset(struct iproc_pcie *pcie)

+static void iproc_pcie_perst_ctrl(struct iproc_pcie *pcie, bool assert)
  {
u32 val;
  
  	/*

-* PAXC and the internal emulated endpoint device downstream should not
-* be reset.  If firmware has been loaded on the endpoint device at an
-* earlier boot stage, reset here causes issues.
+* The internal emulated endpoints (such as PAXC) device downstream
+* should not be reset. If firmware has been loaded on the endpoint
+* device at an earlier boot stage, reset here causes issues.
 */


Why is the above comment modified? Is it even related to this patch that
implements the shutdown routine for PAXB? In addition, the original
comment is more correct. The new comment by stating the "internal
emulated endpoints (such as PAXC)" is wrong. PAXC is not an endpoint.
PAXC is the root complex interface. The endpoint is Nitro.

Thanks,

Ray

if (pcie->ep_is_internal)
return;
  
-	/*

-* Select perst_b signal as reset source. Put the device into reset,
-* and then bring it out of reset
-*/
-   val = iproc_pcie_read_reg(pcie, IPROC_PCIE_CLK_CTRL);
-   val &= ~EP_PERST_SOURCE_SELECT & ~EP_MODE_SURVIVE_PERST &
-   ~RC_PCIE_RST_OUTPUT;
-   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
-   udelay(250);
-
-   val |= RC_PCIE_RST_OUTPUT;
-   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
-   msleep(100);
+   if (assert) {
+   val = iproc_pcie_read_reg(pcie, IPROC_PCIE_CLK_CTRL);
+   val &= ~EP_PERST_SOURCE_SELECT & ~EP_MODE_SURVIVE_PERST &
+   ~RC_PCIE_RST_OUTPUT;
+   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
+   udelay(250);
+   } else {
+   val = iproc_pcie_read_reg(pcie, IPROC_PCIE_CLK_CTRL);
+   val |= RC_PCIE_RST_OUTPUT;
+   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
+   msleep(100);
+   }
+}
+
+int iproc_pcie_shutdown(struct iproc_pcie *pcie)
+{
+   iproc_pcie_perst_ctrl(pcie, true);
+   msleep(500);
+
+   return 0;
  }

Re: [PATCH v4 2/2] PCI: iproc: add device shutdown for PCI RC

[Ray Jui]

Hi Oza,

It looks like you missed my comments during the internal review. See my 
comments inline below.



On 7/4/2017 8:08 PM, Oza Pawandeep wrote:

PERST must be asserted around ~500ms before the reboot is applied.

During soft reset (e.g., "reboot" from Linux) on some iproc based SOCs
LCPLL clock and PERST both goes off simultaneously.
This will cause certain Endpoints Intel NVMe not get detected, upon
next boot sequence.

This is specifically happening with Intel P3700 400GB series.
Endpoint is expecting the clock for some amount of time after PERST is
asserted, which is not happening in Stingray (iproc based SOC).
This causes NVMe to behave in undefined way.

On the contrary Intel x86 boards, will have ref clock running, so we
do not see this behavior there.

Besides, PCI spec does not stipulate about such timings.
In-fact it does not tell us, whether PCIe device should consider
refclk to be available or not to be.

It is completely up to vendor to design their EP the way they want
with respect to ref clock availability.

500ms is just based on the observation and taken as safe margin.
This patch adds platform shutdown where it should be
called in device_shutdown while reboot command is issued.
So in sequence first Endpoint Shutdown (e.g. nvme_shutdown)
followed by RC shutdown, which issues safe PERST assertion.

Signed-off-by: Oza Pawandeep 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 

diff --git a/drivers/pci/host/pcie-iproc-platform.c 
b/drivers/pci/host/pcie-iproc-platform.c
index 90d2bdd..9512960 100644
--- a/drivers/pci/host/pcie-iproc-platform.c
+++ b/drivers/pci/host/pcie-iproc-platform.c
@@ -131,6 +131,13 @@ static int iproc_pcie_pltfm_remove(struct platform_device 
*pdev)
return iproc_pcie_remove(pcie);
  }
  
+static void iproc_pcie_pltfm_shutdown(struct platform_device *pdev)

+{
+   struct iproc_pcie *pcie = platform_get_drvdata(pdev);
+
+   iproc_pcie_shutdown(pcie);
+}
+
  static struct platform_driver iproc_pcie_pltfm_driver = {
.driver = {
.name = "iproc-pcie",
@@ -138,6 +145,7 @@ static int iproc_pcie_pltfm_remove(struct platform_device 
*pdev)
},
.probe = iproc_pcie_pltfm_probe,
.remove = iproc_pcie_pltfm_remove,
+   .shutdown = iproc_pcie_pltfm_shutdown,
  };
  module_platform_driver(iproc_pcie_pltfm_driver);
  
diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c

index b0abcd7..d1bcdc9 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -616,32 +616,40 @@ static int iproc_pcie_config_write32(struct pci_bus *bus, 
unsigned int devfn,
.write = iproc_pcie_config_write32,
  };
  
-static void iproc_pcie_reset(struct iproc_pcie *pcie)

+static void iproc_pcie_perst_ctrl(struct iproc_pcie *pcie, bool assert)
  {
u32 val;
  
  	/*

-* PAXC and the internal emulated endpoint device downstream should not
-* be reset.  If firmware has been loaded on the endpoint device at an
-* earlier boot stage, reset here causes issues.
+* The internal emulated endpoints (such as PAXC) device downstream
+* should not be reset. If firmware has been loaded on the endpoint
+* device at an earlier boot stage, reset here causes issues.
 */


Why is the above comment modified? Is it even related to this patch that
implements the shutdown routine for PAXB? In addition, the original
comment is more correct. The new comment by stating the "internal
emulated endpoints (such as PAXC)" is wrong. PAXC is not an endpoint.
PAXC is the root complex interface. The endpoint is Nitro.

Thanks,

Ray

if (pcie->ep_is_internal)
return;
  
-	/*

-* Select perst_b signal as reset source. Put the device into reset,
-* and then bring it out of reset
-*/
-   val = iproc_pcie_read_reg(pcie, IPROC_PCIE_CLK_CTRL);
-   val &= ~EP_PERST_SOURCE_SELECT & ~EP_MODE_SURVIVE_PERST &
-   ~RC_PCIE_RST_OUTPUT;
-   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
-   udelay(250);
-
-   val |= RC_PCIE_RST_OUTPUT;
-   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
-   msleep(100);
+   if (assert) {
+   val = iproc_pcie_read_reg(pcie, IPROC_PCIE_CLK_CTRL);
+   val &= ~EP_PERST_SOURCE_SELECT & ~EP_MODE_SURVIVE_PERST &
+   ~RC_PCIE_RST_OUTPUT;
+   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
+   udelay(250);
+   } else {
+   val = iproc_pcie_read_reg(pcie, IPROC_PCIE_CLK_CTRL);
+   val |= RC_PCIE_RST_OUTPUT;
+   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
+   msleep(100);
+   }
+}
+
+int iproc_pcie_shutdown(struct iproc_pcie *pcie)
+{
+   iproc_pcie_perst_ctrl(pcie, true);
+   msleep(500);
+
+   return 0;
  }
+EXPORT_SYMBOL(iproc_pcie_shutdown);
  
  static int iproc_pcie_check_link(struct 

[PATCH v3] perf sort: only insert overhead && overhead_children when no overhead* field given

[changbin . du]

From: Changbin Du 

If we always insert 'overhead' and 'overhead_children' as sort keys,
this make it impossible to sort as overhead (which displayed as Self)
first.Ths will be a problem if the data is collected with call-graph
enabled. Then we never can sort the result as self-overhead on this
data. And sometimes the data is hard to collect.

> perf record -ag
> perf report -s overhead,sym

Samples: 7K of event 'cycles', Event count (approx.): 865138253
  Children  Self  Symbol
  +   26.41% 0.00%  [k] verify_cpu
  +   26.37% 0.04%  [k] cpu_startup_entry
  +   25.93% 0.27%  [k] do_idle
  +   19.88% 0.00%  [k] start_secondary
  

I intend to sort as 'Self', but actually it sort as 'Children'.

This patch fix this by only insert overhead && overhead_children
when no overhead* field given.

Signed-off-by: Changbin Du 
---
v3: Add comment in code from Jiri
v2: Add the example in commit message.

---
 tools/perf/util/sort.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 8b327c9..9e087fb 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -2635,6 +2635,13 @@ static char *setup_overhead(char *keys)
if (sort__mode == SORT_MODE__DIFF)
return keys;
 
+   /**
+* User already stated overhead within -s option,
+* do not mangle with that.
+*/
+   if (strstr(keys, "overhead"))
+   return keys;
+
keys = prefix_if_not_in("overhead", keys);
 
if (symbol_conf.cumulate_callchain)
-- 
2.7.4

[PATCH v3] perf sort: only insert overhead && overhead_children when no overhead* field given

[changbin . du]

From: Changbin Du 

If we always insert 'overhead' and 'overhead_children' as sort keys,
this make it impossible to sort as overhead (which displayed as Self)
first.Ths will be a problem if the data is collected with call-graph
enabled. Then we never can sort the result as self-overhead on this
data. And sometimes the data is hard to collect.

> perf record -ag
> perf report -s overhead,sym

Samples: 7K of event 'cycles', Event count (approx.): 865138253
  Children  Self  Symbol
  +   26.41% 0.00%  [k] verify_cpu
  +   26.37% 0.04%  [k] cpu_startup_entry
  +   25.93% 0.27%  [k] do_idle
  +   19.88% 0.00%  [k] start_secondary
  

I intend to sort as 'Self', but actually it sort as 'Children'.

This patch fix this by only insert overhead && overhead_children
when no overhead* field given.

Signed-off-by: Changbin Du 
---
v3: Add comment in code from Jiri
v2: Add the example in commit message.

---
 tools/perf/util/sort.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 8b327c9..9e087fb 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -2635,6 +2635,13 @@ static char *setup_overhead(char *keys)
if (sort__mode == SORT_MODE__DIFF)
return keys;
 
+   /**
+* User already stated overhead within -s option,
+* do not mangle with that.
+*/
+   if (strstr(keys, "overhead"))
+   return keys;
+
keys = prefix_if_not_in("overhead", keys);
 
if (symbol_conf.cumulate_callchain)
-- 
2.7.4

[PATCH v2] btrfs: Correct assignment of pos

[Goldwyn Rodrigues]

From: Goldwyn Rodrigues 

Assigning pos for usage early messes up in append mode, where
the pos is re-assigned in generic_write_checks(). Assign
pos later to get the correct position to write from iocb->ki_pos.

Since check_can_nocow also uses the value of pos, we shift
generic_write_checks() before check_can_nocow(). Checks with
IOCB_DIRECT are present in generic_write_checks(), so checking
for IOCB_NOWAIT is enough.

Also, put locking sequence in the fast path.

Changes since v1:
 - Moved pos higher up to encompass check_can_nocow() call.

Fixes: edf064e7c6fe ("btrfs: nowait aio support")
Signed-off-by: Goldwyn Rodrigues 
---
 fs/btrfs/file.c | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index 59e2dccdf75b..ad53832838b5 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -1875,16 +1875,25 @@ static ssize_t btrfs_file_write_iter(struct kiocb *iocb,
ssize_t num_written = 0;
bool sync = (file->f_flags & O_DSYNC) || IS_SYNC(file->f_mapping->host);
ssize_t err;
-   loff_t pos = iocb->ki_pos;
+   loff_t pos;
size_t count = iov_iter_count(from);
loff_t oldsize;
int clean_page = 0;
 
-   if ((iocb->ki_flags & IOCB_NOWAIT) &&
-   (iocb->ki_flags & IOCB_DIRECT)) {
-   /* Don't sleep on inode rwsem */
-   if (!inode_trylock(inode))
+   if (!inode_trylock(inode)) {
+   if (iocb->ki_flags & IOCB_NOWAIT)
return -EAGAIN;
+   inode_lock(inode);
+   }
+
+   err = generic_write_checks(iocb, from);
+   if (err <= 0) {
+   inode_unlock(inode);
+   return err;
+   }
+
+   pos = iocb->ki_pos;
+   if (iocb->ki_flags & IOCB_NOWAIT) {
/*
 * We will allocate space in case nodatacow is not set,
 * so bail
@@ -1895,13 +1904,6 @@ static ssize_t btrfs_file_write_iter(struct kiocb *iocb,
inode_unlock(inode);
return -EAGAIN;
}
-   } else
-   inode_lock(inode);
-
-   err = generic_write_checks(iocb, from);
-   if (err <= 0) {
-   inode_unlock(inode);
-   return err;
}
 
current->backing_dev_info = inode_to_bdi(inode);
-- 
2.12.0

[PATCH v2] btrfs: Correct assignment of pos

[Goldwyn Rodrigues]

From: Goldwyn Rodrigues 

Assigning pos for usage early messes up in append mode, where
the pos is re-assigned in generic_write_checks(). Assign
pos later to get the correct position to write from iocb->ki_pos.

Since check_can_nocow also uses the value of pos, we shift
generic_write_checks() before check_can_nocow(). Checks with
IOCB_DIRECT are present in generic_write_checks(), so checking
for IOCB_NOWAIT is enough.

Also, put locking sequence in the fast path.

Changes since v1:
 - Moved pos higher up to encompass check_can_nocow() call.

Fixes: edf064e7c6fe ("btrfs: nowait aio support")
Signed-off-by: Goldwyn Rodrigues 
---
 fs/btrfs/file.c | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index 59e2dccdf75b..ad53832838b5 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -1875,16 +1875,25 @@ static ssize_t btrfs_file_write_iter(struct kiocb *iocb,
ssize_t num_written = 0;
bool sync = (file->f_flags & O_DSYNC) || IS_SYNC(file->f_mapping->host);
ssize_t err;
-   loff_t pos = iocb->ki_pos;
+   loff_t pos;
size_t count = iov_iter_count(from);
loff_t oldsize;
int clean_page = 0;
 
-   if ((iocb->ki_flags & IOCB_NOWAIT) &&
-   (iocb->ki_flags & IOCB_DIRECT)) {
-   /* Don't sleep on inode rwsem */
-   if (!inode_trylock(inode))
+   if (!inode_trylock(inode)) {
+   if (iocb->ki_flags & IOCB_NOWAIT)
return -EAGAIN;
+   inode_lock(inode);
+   }
+
+   err = generic_write_checks(iocb, from);
+   if (err <= 0) {
+   inode_unlock(inode);
+   return err;
+   }
+
+   pos = iocb->ki_pos;
+   if (iocb->ki_flags & IOCB_NOWAIT) {
/*
 * We will allocate space in case nodatacow is not set,
 * so bail
@@ -1895,13 +1904,6 @@ static ssize_t btrfs_file_write_iter(struct kiocb *iocb,
inode_unlock(inode);
return -EAGAIN;
}
-   } else
-   inode_lock(inode);
-
-   err = generic_write_checks(iocb, from);
-   if (err <= 0) {
-   inode_unlock(inode);
-   return err;
}
 
current->backing_dev_info = inode_to_bdi(inode);
-- 
2.12.0

Re: [f2fs-dev] [PATCH 1/2] f2fs: avoid deadlock caused by lock order of page and lock_op

[Jaegeuk Kim]

On 07/05, Chao Yu wrote:
> On 2017/7/1 22:27, Jaegeuk Kim wrote:
> > On 07/01, Chao Yu wrote:
> >> On 2017/7/1 15:28, Jaegeuk Kim wrote:
> >>> On 06/26, Chao Yu wrote:
>  Hi Jaegeuk,
> 
>  On 2017/6/26 22:54, Jaegeuk Kim wrote:
> > Hi Chao,
> >
> > On 06/26, Chao Yu wrote:
> >> Hi Jaegeuk,
> >>
> >> On 2017/6/25 0:25, Jaegeuk Kim wrote:
> >>> - punch_hole
> >>>  - fill_zero
> >>>   - f2fs_lock_op
> >>>   - get_new_data_page
> >>>- lock_page
> >>>
> >>> - f2fs_write_data_pages
> >>>  - lock_page
> >>>  - do_write_data_page
> >>>   - f2fs_lock_op
> >>
> >> Good catch!
> >>
> >> With this implementation, page writeback can fail due to concurrent 
> >> checkpoint,
> >> this will make fsync/atomic_commit which trigger synchronous write 
> >> failed randomly.
> >>
> >> How about unifying the lock order in punch_hole as one in writepages 
> >> for regular
> >> inode? We can add one more parameter in get_new_data_page to indicate 
> >> whether
> >> callee needs to lock cp_rwsem.
> >
> > Currently, there would be some places to keep cp_rwsem -> page.lock, 
> > which seems
> > not simple to change the lock order with page.lock -> cp_rwsem. IMO, we 
> > can retry
> > flushing data in f2fs_sync_file, once it gets -EAGAIN.
> >
> > Any thoughts?
> 
>  What about adding inode_lock in f2fs_sync_file to exclude other
>  foreground operation which have reversed lock order? Atomic_commit is OK
>  since it has inode_lock in its path.
> >>>
> >>> I have concerned about performance regression, if we do that.
> >>
> >> I think fsync vs write or fsync vs fsync scenarios are unusual, so is
> >> there any usecase?
> > 
> > Well, that'd be common to call multiple fsync calls at the same time.
> > Like dbench or tiotest?
> 
> Do you have test numbers of dbench/tiotest with inode:lock in fsync?

No, do we need?

> 
> Thanks,
> 
> > 
> >>
> >> Thanks,
> >>
> >>>
> 
>  Thanks,
> 
> >
> >>
> >> Thanks,
> >>
> >>>
> >>> Signed-off-by: Jaegeuk Kim 
> >>> ---
> >>>  fs/f2fs/data.c | 5 +++--
> >>>  1 file changed, 3 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> >>> index 7d3af48d34a9..9141bd19a902 100644
> >>> --- a/fs/f2fs/data.c
> >>> +++ b/fs/f2fs/data.c
> >>> @@ -1404,8 +1404,9 @@ int do_write_data_page(struct f2fs_io_info *fio)
> >>>   }
> >>>   }
> >>>  
> >>> - if (fio->need_lock == LOCK_REQ)
> >>> - f2fs_lock_op(fio->sbi);
> >>> + /* Deadlock due to between page->lock and f2fs_lock_op */
> >>> + if (fio->need_lock == LOCK_REQ && !f2fs_trylock_op(fio->sbi))
> >>> + return -EAGAIN;
> >>>  
> >>>   err = get_dnode_of_data(, page->index, LOOKUP_NODE);
> >>>   if (err)
> >>>
> >
> > --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > Linux-f2fs-devel mailing list
> > linux-f2fs-de...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> >

Re: [f2fs-dev] [PATCH 1/2] f2fs: avoid deadlock caused by lock order of page and lock_op

[Jaegeuk Kim]

On 07/05, Chao Yu wrote:
> On 2017/7/1 22:27, Jaegeuk Kim wrote:
> > On 07/01, Chao Yu wrote:
> >> On 2017/7/1 15:28, Jaegeuk Kim wrote:
> >>> On 06/26, Chao Yu wrote:
>  Hi Jaegeuk,
> 
>  On 2017/6/26 22:54, Jaegeuk Kim wrote:
> > Hi Chao,
> >
> > On 06/26, Chao Yu wrote:
> >> Hi Jaegeuk,
> >>
> >> On 2017/6/25 0:25, Jaegeuk Kim wrote:
> >>> - punch_hole
> >>>  - fill_zero
> >>>   - f2fs_lock_op
> >>>   - get_new_data_page
> >>>- lock_page
> >>>
> >>> - f2fs_write_data_pages
> >>>  - lock_page
> >>>  - do_write_data_page
> >>>   - f2fs_lock_op
> >>
> >> Good catch!
> >>
> >> With this implementation, page writeback can fail due to concurrent 
> >> checkpoint,
> >> this will make fsync/atomic_commit which trigger synchronous write 
> >> failed randomly.
> >>
> >> How about unifying the lock order in punch_hole as one in writepages 
> >> for regular
> >> inode? We can add one more parameter in get_new_data_page to indicate 
> >> whether
> >> callee needs to lock cp_rwsem.
> >
> > Currently, there would be some places to keep cp_rwsem -> page.lock, 
> > which seems
> > not simple to change the lock order with page.lock -> cp_rwsem. IMO, we 
> > can retry
> > flushing data in f2fs_sync_file, once it gets -EAGAIN.
> >
> > Any thoughts?
> 
>  What about adding inode_lock in f2fs_sync_file to exclude other
>  foreground operation which have reversed lock order? Atomic_commit is OK
>  since it has inode_lock in its path.
> >>>
> >>> I have concerned about performance regression, if we do that.
> >>
> >> I think fsync vs write or fsync vs fsync scenarios are unusual, so is
> >> there any usecase?
> > 
> > Well, that'd be common to call multiple fsync calls at the same time.
> > Like dbench or tiotest?
> 
> Do you have test numbers of dbench/tiotest with inode:lock in fsync?

No, do we need?

> 
> Thanks,
> 
> > 
> >>
> >> Thanks,
> >>
> >>>
> 
>  Thanks,
> 
> >
> >>
> >> Thanks,
> >>
> >>>
> >>> Signed-off-by: Jaegeuk Kim 
> >>> ---
> >>>  fs/f2fs/data.c | 5 +++--
> >>>  1 file changed, 3 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> >>> index 7d3af48d34a9..9141bd19a902 100644
> >>> --- a/fs/f2fs/data.c
> >>> +++ b/fs/f2fs/data.c
> >>> @@ -1404,8 +1404,9 @@ int do_write_data_page(struct f2fs_io_info *fio)
> >>>   }
> >>>   }
> >>>  
> >>> - if (fio->need_lock == LOCK_REQ)
> >>> - f2fs_lock_op(fio->sbi);
> >>> + /* Deadlock due to between page->lock and f2fs_lock_op */
> >>> + if (fio->need_lock == LOCK_REQ && !f2fs_trylock_op(fio->sbi))
> >>> + return -EAGAIN;
> >>>  
> >>>   err = get_dnode_of_data(, page->index, LOOKUP_NODE);
> >>>   if (err)
> >>>
> >
> > --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > Linux-f2fs-devel mailing list
> > linux-f2fs-de...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> >

Re: [PATCH][RFC] x86: Fix the irq affinity in fixup_cpus

[Chen Yu]

On Tue, Jul 04, 2017 at 10:50:33AM +0200, Thomas Gleixner wrote:
> On Mon, 3 Jul 2017, Chen Yu wrote:
> > On Sun, Jun 04, 2017 at 10:04:53PM +0200, Thomas Gleixner wrote:
> > > After looking at the callsites, it's safe to change
> > > irq_set_affinity_locked() so that it uses the direct affinity setter
> > > function when force == true.
> > > 
> > Sorry it took me sometime to understand this point(this is why I did not 
> > reply
> > to you at the first time :-)
> > I thought the defination of the word 'safe' here means, we should
> > not adjust the irq affinity in the process context if the ISR is
> > still running, otherwise there might be a race condition.
> > 
> > Currently, there are four drivers would set the force flag to true(AKA,
> > invoking irq_force_affinity()).
> > 
> > 1. exynos4_mct_starting_cpu()
> >The irq affinity is set before the clockevent is registered,
> >so there would be no interrupt triggered when adjusting
> >the irq affinity in the process context. Safe.
> > 
> > 2. sirfsoc_local_timer_starting_cpu()
> >The same as above. Safe.
> > 
> > 3. arm_perf_starting_cpu()
> >During cpu offline, the pmu interrupt(non percpu pmu interrupt)
> >might be migrated to other online cpus. Then once the same cpu
> >is put online, the interrupt will be set back to this cpu again
> >by invoking irq_force_affinity(), but currently the pmu interrupt
> >might be still running on other cpus, so it would be unsafe to adjust
> >its irq affinity in the process context?
> 
> No, that's not an issue. The ability to move interrupts in process context,
> or better said in any context, has nothing to do with a concurrent
> interrupt. The normal mechanics for most architectures/interrupt
> controllers is just to program the new affinity setting which will take
> effect with the next delivered interrupt.
> 
> We just have these ill designed hardware implementations which do not allow
> that. They require to change the interrupt affinity at the point when the
> interrupt is handled on the original target CPU. But that's hard to achieve
> when the CPU is about to go offline, because we might wait forever for an
> interrupt to be raised. So in that case we need to forcefully move them
> away and take the risk of colliding with an actual interrupt being raised
> in hardware concurrently which has the potential to confuse the interrupt
> chip.
>
Thanks for the detailed explaination! Got it.
> > 4. sunhv_migrate_hvcons_irq()
> >The cpu who encountered a panic needs to migrate the hvcons irq to the
> >current alive cpu, and send ipi to stop other cpus. So at the time to
> >adjust the irq affinity for the hvcons, the interrupt of the latter might
> >be running and it might be unsafe to adjust the irq affinity in the
> >process context?
> 
> None of these are related to that problem. All of these architectures can
> move interrupts in process context unconditionally. It's also not relevant
> which callsites invoke irq_set_affinity_locked() with force=true.
> 
Okay.
> The point is whether we can change the semantics of irq_set_affinity_locked()
> without breaking something.
> 
Yes, this might change the semantics of force flag.
> But please answer my other mail in that thread [1] first before we start
> about changing anything in that area. The affinity related changes are in
> Linus tree now, so please retest against that as well.
Okay, I'll switch to that thread.
Here's the test result for affinity:
# uname -r
4.12.0+
# cat /proc/irq/32/smp_affinity
,8000
# echo 0 > /sys/devices/system/cpu/cpu31/online 
# cat /proc/irq/32/smp_affinity
,
Looks like cpu31 is till included in the irq mask.

Thanks,
Yu
> 
> Thanks,
> 
>   tglx
> 
> [1] http://lkml.kernel.org/r/alpine.DEB.2.20.1706282036330.1890@nanos
> 
> 

Re: [PATCH][RFC] x86: Fix the irq affinity in fixup_cpus

[Chen Yu]

On Tue, Jul 04, 2017 at 10:50:33AM +0200, Thomas Gleixner wrote:
> On Mon, 3 Jul 2017, Chen Yu wrote:
> > On Sun, Jun 04, 2017 at 10:04:53PM +0200, Thomas Gleixner wrote:
> > > After looking at the callsites, it's safe to change
> > > irq_set_affinity_locked() so that it uses the direct affinity setter
> > > function when force == true.
> > > 
> > Sorry it took me sometime to understand this point(this is why I did not 
> > reply
> > to you at the first time :-)
> > I thought the defination of the word 'safe' here means, we should
> > not adjust the irq affinity in the process context if the ISR is
> > still running, otherwise there might be a race condition.
> > 
> > Currently, there are four drivers would set the force flag to true(AKA,
> > invoking irq_force_affinity()).
> > 
> > 1. exynos4_mct_starting_cpu()
> >The irq affinity is set before the clockevent is registered,
> >so there would be no interrupt triggered when adjusting
> >the irq affinity in the process context. Safe.
> > 
> > 2. sirfsoc_local_timer_starting_cpu()
> >The same as above. Safe.
> > 
> > 3. arm_perf_starting_cpu()
> >During cpu offline, the pmu interrupt(non percpu pmu interrupt)
> >might be migrated to other online cpus. Then once the same cpu
> >is put online, the interrupt will be set back to this cpu again
> >by invoking irq_force_affinity(), but currently the pmu interrupt
> >might be still running on other cpus, so it would be unsafe to adjust
> >its irq affinity in the process context?
> 
> No, that's not an issue. The ability to move interrupts in process context,
> or better said in any context, has nothing to do with a concurrent
> interrupt. The normal mechanics for most architectures/interrupt
> controllers is just to program the new affinity setting which will take
> effect with the next delivered interrupt.
> 
> We just have these ill designed hardware implementations which do not allow
> that. They require to change the interrupt affinity at the point when the
> interrupt is handled on the original target CPU. But that's hard to achieve
> when the CPU is about to go offline, because we might wait forever for an
> interrupt to be raised. So in that case we need to forcefully move them
> away and take the risk of colliding with an actual interrupt being raised
> in hardware concurrently which has the potential to confuse the interrupt
> chip.
>
Thanks for the detailed explaination! Got it.
> > 4. sunhv_migrate_hvcons_irq()
> >The cpu who encountered a panic needs to migrate the hvcons irq to the
> >current alive cpu, and send ipi to stop other cpus. So at the time to
> >adjust the irq affinity for the hvcons, the interrupt of the latter might
> >be running and it might be unsafe to adjust the irq affinity in the
> >process context?
> 
> None of these are related to that problem. All of these architectures can
> move interrupts in process context unconditionally. It's also not relevant
> which callsites invoke irq_set_affinity_locked() with force=true.
> 
Okay.
> The point is whether we can change the semantics of irq_set_affinity_locked()
> without breaking something.
> 
Yes, this might change the semantics of force flag.
> But please answer my other mail in that thread [1] first before we start
> about changing anything in that area. The affinity related changes are in
> Linus tree now, so please retest against that as well.
Okay, I'll switch to that thread.
Here's the test result for affinity:
# uname -r
4.12.0+
# cat /proc/irq/32/smp_affinity
,8000
# echo 0 > /sys/devices/system/cpu/cpu31/online 
# cat /proc/irq/32/smp_affinity
,
Looks like cpu31 is till included in the irq mask.

Thanks,
Yu
> 
> Thanks,
> 
>   tglx
> 
> [1] http://lkml.kernel.org/r/alpine.DEB.2.20.1706282036330.1890@nanos
> 
> 

Re: [PATCH 4/5] mm/memcontrol: allow to uncharge page without using page->lru field

[Balbir Singh]

On Tue, Jul 4, 2017 at 10:51 PM, Michal Hocko  wrote:
> On Mon 03-07-17 17:14:14, Jérôme Glisse wrote:
>> HMM pages (private or public device pages) are ZONE_DEVICE page and
>> thus you can not use page->lru fields of those pages. This patch
>> re-arrange the uncharge to allow single page to be uncharge without
>> modifying the lru field of the struct page.
>>
>> There is no change to memcontrol logic, it is the same as it was
>> before this patch.
>
> What is the memcg semantic of the memory? Why is it even charged? AFAIR
> this is not a reclaimable memory. If yes how are we going to deal with
> memory limits? What should happen if go OOM? Does killing an process
> actually help to release that memory? Isn't it pinned by a device?
>
> For the patch itself. It is quite ugly but I haven't spotted anything
> obviously wrong with it. It is the memcg semantic with this class of
> memory which makes me worried.
>

This is the HMM CDM case. Memory is normally malloc'd and then
migrated to ZONE_DEVICE or vice-versa. One of the things we did
discuss was seeing ZONE_DEVICE memory in user page tables.

Balbir Singh.

Re: [PATCH 4/5] mm/memcontrol: allow to uncharge page without using page->lru field

[Balbir Singh]

On Tue, Jul 4, 2017 at 10:51 PM, Michal Hocko  wrote:
> On Mon 03-07-17 17:14:14, Jérôme Glisse wrote:
>> HMM pages (private or public device pages) are ZONE_DEVICE page and
>> thus you can not use page->lru fields of those pages. This patch
>> re-arrange the uncharge to allow single page to be uncharge without
>> modifying the lru field of the struct page.
>>
>> There is no change to memcontrol logic, it is the same as it was
>> before this patch.
>
> What is the memcg semantic of the memory? Why is it even charged? AFAIR
> this is not a reclaimable memory. If yes how are we going to deal with
> memory limits? What should happen if go OOM? Does killing an process
> actually help to release that memory? Isn't it pinned by a device?
>
> For the patch itself. It is quite ugly but I haven't spotted anything
> obviously wrong with it. It is the memcg semantic with this class of
> memory which makes me worried.
>

This is the HMM CDM case. Memory is normally malloc'd and then
migrated to ZONE_DEVICE or vice-versa. One of the things we did
discuss was seeing ZONE_DEVICE memory in user page tables.

Balbir Singh.

Re: [PATCH] arm64: traps: disable irq in die()

[qiaozhou]

On 2017年07月05日 01:17, Will Deacon wrote:

On Wed, Jun 28, 2017 at 05:04:12PM +0800, Qiao Zhou wrote:

In current die(), the irq is disabled for __die() handle, not
including the possible panic() handling. Since the log in __die()
can take several hundreds ms, new irq might come and interrupt
current die().

If the process calling die() holds some critical resource, and some
other process scheduled later also needs it, then it would deadlock.
The first panic will not be executed.

So here disable irq for the whole flow of die().

Could you give an example of this going wrong, please?

OK. I'll add one piece of  log at the bottom and add some descriptions.



Signed-off-by: Qiao Zhou 
---
  arch/arm64/kernel/traps.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 0805b44..b12bf0f 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -274,10 +274,13 @@ static DEFINE_RAW_SPINLOCK(die_lock);
  void die(const char *str, struct pt_regs *regs, int err)
  {
int ret;
+   unsigned long flags;
+
+   local_irq_save(flags);
  
  	oops_enter();
  
-	raw_spin_lock_irq(_lock);

+   raw_spin_lock(_lock);

Can we instead move the taking of the die_lock before oops_enter, or does
that break something else?
It's OK to move. I just didn't want to change the original place for 
taking the lock.



console_verbose();
bust_spinlocks(1);
ret = __die(str, err, regs);
@@ -287,13 +290,16 @@ void die(const char *str, struct pt_regs *regs, int err)
  
  	bust_spinlocks(0);

add_taint(TAINT_DIE, LOCKDEP_NOW_UNRELIABLE);
-   raw_spin_unlock_irq(_lock);
+   raw_spin_unlock(_lock);
oops_exit();
  
  	if (in_interrupt())

panic("Fatal exception in interrupt");
if (panic_on_oops)
panic("Fatal exception");
+
+   local_irq_restore(flags);

We could also move the unlock_irq down here.

You're right.


Will
Here is the sample log. The sequence is: core0 exception -> core0 exec 
die -> core0 interrupted -> core9 detect hardlockup on core0, set core0 
pc to 0 -> core0 exception again. The last exception shows the complete 
stack.


In the first exception(5716.xx), core0 holds rq->lock and tries to 
activate_task, and didn't release the lock yet. In the second exception, 
the stack shows core0 tries to get the same rq->lock in scheduler_tick, 
but can never get it. So hardlockup is detected.


[ 5716.045688] c0 0 (swapper/0) Unable to handle kernel paging request 
at virtual address f9b5eed015b5

[ 5716.055132] c0 0 (swapper/0) pgd = ffc0a9415000
[ 5716.060024] c0 0 (swapper/0) [f9b5eed015b5] 
*pgd=, *pud=
[ 5716.067038] c0 0 (swapper/0) Internal error: Oops: 9644 [#1] 
PREEMPT SMP
[ 5716.074096] c0 0 (swapper/0) Modules linked in: snd_soc_asr_88pm860 
snd_soc_asr snd_soc_88pm88x_headset snd_soc_88pm860 nanohub_aipc adsp
[ 5716.085108] c0 0 (swapper/0) CPU: 0 PID: 0 Comm: swapper/0 Tainted: 
GB   4.4.35+ #1

[ 5716.093821] c0 0 (swapper/0) Hardware name: ASR AQUILA EVB (DT)
[ 5716.099764] c0 0 (swapper/0) task: ff8008e56cc0 ti: 
ff8008e4 task.ti: ff8008e4

[ 5716.108752] c0 0 (swapper/0) PC is at dequeue_rt_stack+0x64/0x2c0
[ 5716.114871] c0 0 (swapper/0) LR is at dequeue_rt_stack+0x50/0x2c0
[ 5716.120977] c0 0 (swapper/0) pc : [] lr : 
[] pstate: 21c5

[ 5716.129863] c0 0 (swapper/0) sp : ffc0fded2db0
[ 5716.134667] c0 0 (swapper/0) x29: ffc0fded2db0 x28: 0002
[ 5716.140012] c0 0 (swapper/0) x27: ff8008c2d000 x26: 
[ 5716.145359] c0 0 (swapper/0) x25: ff8008e49028 x24: 01c0
[ 5716.150706] c0 0 (swapper/0) x23: ffc0fded9280 x22: 0001
[ 5716.156052] c0 0 (swapper/0) x21: 0064 x20: ffc0fded93e8
[ 5716.161400] c0 0 (swapper/0) x19: ffc0eed092e8 x18: 
[ 5716.166748] c0 0 (swapper/0) x17:  x16: 
[ 5716.172095] c0 0 (swapper/0) x15:  x14: 
[ 5716.177442] c0 0 (swapper/0) x13:  x12: 34d5d91d
[ 5716.182789] c0 0 (swapper/0) x11:  x10: 1000
[ 5716.188137] c0 0 (swapper/0) x9 : ff8008083800 x8 : ff8008e46ff0
[ 5716.193484] c0 0 (swapper/0) x7 :  x6 : 001aa6db7e28
[ 5716.198830] c0 0 (swapper/0) x5 : 0015 x4 : 0532dde29330
[ 5716.204178] c0 0 (swapper/0) x3 : ff80080e7060 x2 : 0005
[ 5716.209525] c0 0 (swapper/0) x1 : 3d77eed0f7f5 x0 : f9b5eed015ad
[ 5716.214881] c0 0 (swapper/0)
   SP: 0xffc0fded2d30:

[...]   // printing stack/call trace of core0.

[ 5716.700455] c0 0 (swapper/0) [] 
dequeue_rt_stack+0x64/0x2c0
[ 5716.707616] c0 0 (swapper/0) [] 
enqueue_task_rt+0x4c/0xf8

[ 5716.714604] c0 0 (swapper/0) [] 

Re: [PATCH] arm64: traps: disable irq in die()

[qiaozhou]

On 2017年07月05日 01:17, Will Deacon wrote:

On Wed, Jun 28, 2017 at 05:04:12PM +0800, Qiao Zhou wrote:

In current die(), the irq is disabled for __die() handle, not
including the possible panic() handling. Since the log in __die()
can take several hundreds ms, new irq might come and interrupt
current die().

If the process calling die() holds some critical resource, and some
other process scheduled later also needs it, then it would deadlock.
The first panic will not be executed.

So here disable irq for the whole flow of die().

Could you give an example of this going wrong, please?

OK. I'll add one piece of  log at the bottom and add some descriptions.



Signed-off-by: Qiao Zhou 
---
  arch/arm64/kernel/traps.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 0805b44..b12bf0f 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -274,10 +274,13 @@ static DEFINE_RAW_SPINLOCK(die_lock);
  void die(const char *str, struct pt_regs *regs, int err)
  {
int ret;
+   unsigned long flags;
+
+   local_irq_save(flags);
  
  	oops_enter();
  
-	raw_spin_lock_irq(_lock);

+   raw_spin_lock(_lock);

Can we instead move the taking of the die_lock before oops_enter, or does
that break something else?
It's OK to move. I just didn't want to change the original place for 
taking the lock.



console_verbose();
bust_spinlocks(1);
ret = __die(str, err, regs);
@@ -287,13 +290,16 @@ void die(const char *str, struct pt_regs *regs, int err)
  
  	bust_spinlocks(0);

add_taint(TAINT_DIE, LOCKDEP_NOW_UNRELIABLE);
-   raw_spin_unlock_irq(_lock);
+   raw_spin_unlock(_lock);
oops_exit();
  
  	if (in_interrupt())

panic("Fatal exception in interrupt");
if (panic_on_oops)
panic("Fatal exception");
+
+   local_irq_restore(flags);

We could also move the unlock_irq down here.

You're right.


Will
Here is the sample log. The sequence is: core0 exception -> core0 exec 
die -> core0 interrupted -> core9 detect hardlockup on core0, set core0 
pc to 0 -> core0 exception again. The last exception shows the complete 
stack.


In the first exception(5716.xx), core0 holds rq->lock and tries to 
activate_task, and didn't release the lock yet. In the second exception, 
the stack shows core0 tries to get the same rq->lock in scheduler_tick, 
but can never get it. So hardlockup is detected.


[ 5716.045688] c0 0 (swapper/0) Unable to handle kernel paging request 
at virtual address f9b5eed015b5

[ 5716.055132] c0 0 (swapper/0) pgd = ffc0a9415000
[ 5716.060024] c0 0 (swapper/0) [f9b5eed015b5] 
*pgd=, *pud=
[ 5716.067038] c0 0 (swapper/0) Internal error: Oops: 9644 [#1] 
PREEMPT SMP
[ 5716.074096] c0 0 (swapper/0) Modules linked in: snd_soc_asr_88pm860 
snd_soc_asr snd_soc_88pm88x_headset snd_soc_88pm860 nanohub_aipc adsp
[ 5716.085108] c0 0 (swapper/0) CPU: 0 PID: 0 Comm: swapper/0 Tainted: 
GB   4.4.35+ #1

[ 5716.093821] c0 0 (swapper/0) Hardware name: ASR AQUILA EVB (DT)
[ 5716.099764] c0 0 (swapper/0) task: ff8008e56cc0 ti: 
ff8008e4 task.ti: ff8008e4

[ 5716.108752] c0 0 (swapper/0) PC is at dequeue_rt_stack+0x64/0x2c0
[ 5716.114871] c0 0 (swapper/0) LR is at dequeue_rt_stack+0x50/0x2c0
[ 5716.120977] c0 0 (swapper/0) pc : [] lr : 
[] pstate: 21c5

[ 5716.129863] c0 0 (swapper/0) sp : ffc0fded2db0
[ 5716.134667] c0 0 (swapper/0) x29: ffc0fded2db0 x28: 0002
[ 5716.140012] c0 0 (swapper/0) x27: ff8008c2d000 x26: 
[ 5716.145359] c0 0 (swapper/0) x25: ff8008e49028 x24: 01c0
[ 5716.150706] c0 0 (swapper/0) x23: ffc0fded9280 x22: 0001
[ 5716.156052] c0 0 (swapper/0) x21: 0064 x20: ffc0fded93e8
[ 5716.161400] c0 0 (swapper/0) x19: ffc0eed092e8 x18: 
[ 5716.166748] c0 0 (swapper/0) x17:  x16: 
[ 5716.172095] c0 0 (swapper/0) x15:  x14: 
[ 5716.177442] c0 0 (swapper/0) x13:  x12: 34d5d91d
[ 5716.182789] c0 0 (swapper/0) x11:  x10: 1000
[ 5716.188137] c0 0 (swapper/0) x9 : ff8008083800 x8 : ff8008e46ff0
[ 5716.193484] c0 0 (swapper/0) x7 :  x6 : 001aa6db7e28
[ 5716.198830] c0 0 (swapper/0) x5 : 0015 x4 : 0532dde29330
[ 5716.204178] c0 0 (swapper/0) x3 : ff80080e7060 x2 : 0005
[ 5716.209525] c0 0 (swapper/0) x1 : 3d77eed0f7f5 x0 : f9b5eed015ad
[ 5716.214881] c0 0 (swapper/0)
   SP: 0xffc0fded2d30:

[...]   // printing stack/call trace of core0.

[ 5716.700455] c0 0 (swapper/0) [] 
dequeue_rt_stack+0x64/0x2c0
[ 5716.707616] c0 0 (swapper/0) [] 
enqueue_task_rt+0x4c/0xf8

[ 5716.714604] c0 0 (swapper/0) [] activate_task+0x78/0xbc
[ 5716.721418] 

RE: [PATCH] arm64: dts: ls1046a: Add dis_rxdet_inp3_quirk property to USB3 node

[Ran Wang]

Hello Sir,
How is the review result of this patch. I am waiting for it be merged, 
thanks.

BR
Ran

-Original Message-
From: Ran Wang [mailto:ran.wan...@nxp.com] 
Sent: Friday, June 02, 2017 10:30 AM
To: Rob Herring ; Mark Rutland ; 
Catalin Marinas ; Will Deacon 
Cc: Shawn Guo ; Andy Tang ; Horia 
Geantă ; Marc Zyngier ; Mihai 
Emilian Bantea ; Jia Hongtao ; Scott 
Wood ; Gang Liu ; york sun 
; open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS 
; moderated list:ARM64 PORT (AARCH64 ARCHITECTURE) 
; open list 
; Ran Wang 
Subject: [PATCH] arm64: dts: ls1046a: Add dis_rxdet_inp3_quirk property to USB3 
node

Add "dis_rxdet_inp3_quirk" boolean property to USB3 node. This property is used 
to disable rx detection in P3 PHY mode.

Signed-off-by: Ran Wang 
---
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index f4b8b7e..9137280 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -567,6 +567,7 @@
interrupts = ;
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
+   snps,dis_rxdet_inp3_quirk;
};
 
usb1: usb@300 {
@@ -575,6 +576,7 @@
interrupts = ;
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
+   snps,dis_rxdet_inp3_quirk;
};
 
usb2: usb@310 {
@@ -583,6 +585,7 @@
interrupts = ;
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
+   snps,dis_rxdet_inp3_quirk;
};
 
sata: sata@320 {
--
2.1.0.27.g96db324

RE: [PATCH] arm64: dts: ls1046a: Add dis_rxdet_inp3_quirk property to USB3 node

[Ran Wang]

Hello Sir,
How is the review result of this patch. I am waiting for it be merged, 
thanks.

BR
Ran

-Original Message-
From: Ran Wang [mailto:ran.wan...@nxp.com] 
Sent: Friday, June 02, 2017 10:30 AM
To: Rob Herring ; Mark Rutland ; 
Catalin Marinas ; Will Deacon 
Cc: Shawn Guo ; Andy Tang ; Horia 
Geantă ; Marc Zyngier ; Mihai 
Emilian Bantea ; Jia Hongtao ; Scott 
Wood ; Gang Liu ; york sun 
; open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS 
; moderated list:ARM64 PORT (AARCH64 ARCHITECTURE) 
; open list 
; Ran Wang 
Subject: [PATCH] arm64: dts: ls1046a: Add dis_rxdet_inp3_quirk property to USB3 
node

Add "dis_rxdet_inp3_quirk" boolean property to USB3 node. This property is used 
to disable rx detection in P3 PHY mode.

Signed-off-by: Ran Wang 
---
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index f4b8b7e..9137280 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -567,6 +567,7 @@
interrupts = ;
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
+   snps,dis_rxdet_inp3_quirk;
};
 
usb1: usb@300 {
@@ -575,6 +576,7 @@
interrupts = ;
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
+   snps,dis_rxdet_inp3_quirk;
};
 
usb2: usb@310 {
@@ -583,6 +585,7 @@
interrupts = ;
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
+   snps,dis_rxdet_inp3_quirk;
};
 
sata: sata@320 {
--
2.1.0.27.g96db324

[PATCH] soc: versatile: remove unnecessary static in realview_soc_probe()

[Gustavo A. R. Silva]

Remove unnecessary static on local variable syscon_regmap.
Such variable is initialized before being used,
on every execution path throughout the function.
The static has no benefit and, removing it reduces
the code size.

This issue was detected using Coccinelle and the following semantic patch:

@bad exists@
position p;
identifier x;
type T;
@@

static T x@p;
...
x = <+...x...+>

@@
identifier x;
expression e;
type T;
position p != bad.p;
@@

-static
 T x@p;
 ... when != x
 when strict
?x = e;

In the following log you can see the difference in the code size. Also,
there is a significant difference in then bss segment. This log is the
output of the size command, before and after the code change:

before:
   textdata bss dec hex filename
   33392104 128557115c3 drivers/soc/versatile/soc-realview.o

after:
   textdata bss dec hex filename
   33212048  6454331539 drivers/soc/versatile/soc-realview.o

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/soc/versatile/soc-realview.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/versatile/soc-realview.c 
b/drivers/soc/versatile/soc-realview.c
index 282e371..caf698e 100644
--- a/drivers/soc/versatile/soc-realview.c
+++ b/drivers/soc/versatile/soc-realview.c
@@ -85,7 +85,7 @@ static struct device_attribute realview_build_attr =
 
 static int realview_soc_probe(struct platform_device *pdev)
 {
-   static struct regmap *syscon_regmap;
+   struct regmap *syscon_regmap;
struct soc_device *soc_dev;
struct soc_device_attribute *soc_dev_attr;
struct device_node *np = pdev->dev.of_node;
-- 
2.5.0

[PATCH] soc: versatile: remove unnecessary static in realview_soc_probe()

[Gustavo A. R. Silva]

Remove unnecessary static on local variable syscon_regmap.
Such variable is initialized before being used,
on every execution path throughout the function.
The static has no benefit and, removing it reduces
the code size.

This issue was detected using Coccinelle and the following semantic patch:

@bad exists@
position p;
identifier x;
type T;
@@

static T x@p;
...
x = <+...x...+>

@@
identifier x;
expression e;
type T;
position p != bad.p;
@@

-static
 T x@p;
 ... when != x
 when strict
?x = e;

In the following log you can see the difference in the code size. Also,
there is a significant difference in then bss segment. This log is the
output of the size command, before and after the code change:

before:
   textdata bss dec hex filename
   33392104 128557115c3 drivers/soc/versatile/soc-realview.o

after:
   textdata bss dec hex filename
   33212048  6454331539 drivers/soc/versatile/soc-realview.o

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/soc/versatile/soc-realview.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/versatile/soc-realview.c 
b/drivers/soc/versatile/soc-realview.c
index 282e371..caf698e 100644
--- a/drivers/soc/versatile/soc-realview.c
+++ b/drivers/soc/versatile/soc-realview.c
@@ -85,7 +85,7 @@ static struct device_attribute realview_build_attr =
 
 static int realview_soc_probe(struct platform_device *pdev)
 {
-   static struct regmap *syscon_regmap;
+   struct regmap *syscon_regmap;
struct soc_device *soc_dev;
struct soc_device_attribute *soc_dev_attr;
struct device_node *np = pdev->dev.of_node;
-- 
2.5.0

[PATCH] arm64: dts: ls1012a: add USB host controller nodes

[Ran Wang]

LS1012A has one USB 3.0(DWC3) controller and
one USB 2.0 controller.

Signed-off-by: Ran Wang 
---
 arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
index b497ac1..8aa2dcf 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
@@ -411,6 +411,23 @@
 < 4 3>;
};
 
+   usb0: usb3@2f0 {
+   compatible = "snps,dwc3";
+   reg = <0x0 0x2f0 0x0 0x1>;
+   interrupts = <0 60 0x4>;
+   dr_mode = "host";
+   snps,quirk-frame-length-adjustment = <0x20>;
+   snps,dis_rxdet_inp3_quirk;
+   };
+
+   usb1: usb2@860 {
+   compatible = "fsl-usb2-dr-v2.5", "fsl-usb2-dr";
+   reg = <0x0 0x860 0x0 0x1000>;
+   interrupts = <0 139 0x4>;
+   dr_mode = "host";
+   phy_type = "ulpi";
+   };
+
sata: sata@320 {
compatible = "fsl,ls1012a-ahci", "fsl,ls1043a-ahci";
reg = <0x0 0x320 0x0 0x1>,
-- 
2.1.0.27.g96db324

[PATCH] arm64: dts: ls1012a: add USB host controller nodes

[Ran Wang]

LS1012A has one USB 3.0(DWC3) controller and
one USB 2.0 controller.

Signed-off-by: Ran Wang 
---
 arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
index b497ac1..8aa2dcf 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
@@ -411,6 +411,23 @@
 < 4 3>;
};
 
+   usb0: usb3@2f0 {
+   compatible = "snps,dwc3";
+   reg = <0x0 0x2f0 0x0 0x1>;
+   interrupts = <0 60 0x4>;
+   dr_mode = "host";
+   snps,quirk-frame-length-adjustment = <0x20>;
+   snps,dis_rxdet_inp3_quirk;
+   };
+
+   usb1: usb2@860 {
+   compatible = "fsl-usb2-dr-v2.5", "fsl-usb2-dr";
+   reg = <0x0 0x860 0x0 0x1000>;
+   interrupts = <0 139 0x4>;
+   dr_mode = "host";
+   phy_type = "ulpi";
+   };
+
sata: sata@320 {
compatible = "fsl,ls1012a-ahci", "fsl,ls1043a-ahci";
reg = <0x0 0x320 0x0 0x1>,
-- 
2.1.0.27.g96db324

[PATCH v4 1/2] PCI: iproc: Retry request when CRS returned from EP

[Oza Pawandeep]

For Configuration Requests only, following reset it is possible for a
device to terminate the request but indicate that it is temporarily unable
to process the Request, but will be able to process the Request in the
future – in this case, the Configuration Request Retry Status 100 (CRS)
Completion Status is used.

As per PCI spec, CRS Software Visibility only affects config read of the
Vendor ID, for config write or any other config read the Root must
automatically re-issue configuration request again as a new request.
Iproc based PCIe RC (hw) does not retry request on its own.

As a result of the fact, PCIe RC driver (sw) should take care of CRS.
This patch fixes the problem, and attempts to read config space again in
case of PCIe code forwarding the CRS back to CPU.
It implements iproc_pcie_config_read which gets called for Stingray,
Otherwise it falls back to PCI generic APIs.

Signed-off-by: Oza Pawandeep 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 

diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index 0f39bd2..b0abcd7 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -68,6 +68,9 @@
 #define APB_ERR_EN_SHIFT 0
 #define APB_ERR_EN   BIT(APB_ERR_EN_SHIFT)
 
+#define CFG_RETRY_STATUS 0x0001
+#define CFG_RETRY_STATUS_TIMEOUT_US  50 /* 500 milli-seconds. */
+
 /* derive the enum index of the outbound/inbound mapping registers */
 #define MAP_REG(base_reg, index)  ((base_reg) + (index) * 2)
 
@@ -448,6 +451,55 @@ static inline void iproc_pcie_apb_err_disable(struct 
pci_bus *bus,
}
 }
 
+static int iproc_pcie_cfg_retry(void __iomem *cfg_data_p)
+{
+   int timeout = CFG_RETRY_STATUS_TIMEOUT_US;
+   unsigned int ret;
+
+   /*
+* As per PCI spec, CRS Software Visibility only
+* affects config read of the Vendor ID.
+* For config write or any other config read the Root must
+* automatically re-issue configuration request again as a
+* new request. Iproc based PCIe RC (hw) does not retry
+* request on its own, so handle it here.
+*/
+   do {
+   ret = readl(cfg_data_p);
+   if (ret == CFG_RETRY_STATUS)
+   udelay(1);
+   else
+   return PCIBIOS_SUCCESSFUL;
+   } while (timeout--);
+
+   return PCIBIOS_DEVICE_NOT_FOUND;
+}
+
+static void __iomem *iproc_pcie_map_ep_cfg_reg(struct iproc_pcie *pcie,
+  unsigned int busno,
+  unsigned int slot,
+  unsigned int fn,
+  int where)
+{
+   u16 offset;
+   u32 val;
+
+   /* EP device access */
+   val = (busno << CFG_ADDR_BUS_NUM_SHIFT) |
+   (slot << CFG_ADDR_DEV_NUM_SHIFT) |
+   (fn << CFG_ADDR_FUNC_NUM_SHIFT) |
+   (where & CFG_ADDR_REG_NUM_MASK) |
+   (1 & CFG_ADDR_CFG_TYPE_MASK);
+
+   iproc_pcie_write_reg(pcie, IPROC_PCIE_CFG_ADDR, val);
+   offset = iproc_pcie_reg_offset(pcie, IPROC_PCIE_CFG_DATA);
+
+   if (iproc_pcie_reg_is_invalid(offset))
+   return NULL;
+
+   return (pcie->base + offset);
+}
+
 /**
  * Note access to the configuration registers are protected at the higher layer
  * by 'pci_lock' in drivers/pci/access.c
@@ -499,13 +551,48 @@ static void __iomem *iproc_pcie_map_cfg_bus(struct 
pci_bus *bus,
return (pcie->base + offset);
 }
 
+static int iproc_pcie_config_read(struct pci_bus *bus, unsigned int devfn,
+   int where, int size, u32 *val)
+{
+   struct iproc_pcie *pcie = iproc_data(bus);
+   unsigned int slot = PCI_SLOT(devfn);
+   unsigned int fn = PCI_FUNC(devfn);
+   unsigned int busno = bus->number;
+   void __iomem *cfg_data_p;
+   int ret;
+
+   /* root complex access. */
+   if (busno == 0)
+   return pci_generic_config_read32(bus, devfn, where, size, val);
+
+   cfg_data_p = iproc_pcie_map_ep_cfg_reg(pcie, busno, slot, fn, where);
+
+   if (!cfg_data_p)
+   return PCIBIOS_DEVICE_NOT_FOUND;
+
+   ret = iproc_pcie_cfg_retry(cfg_data_p);
+   if (ret)
+   return ret;
+
+   *val = readl(cfg_data_p);
+
+   if (size <= 2)
+   *val = (*val >> (8 * (where & 3))) & ((1 << (size * 8)) - 1);
+
+   return PCIBIOS_SUCCESSFUL;
+}
+
 static int iproc_pcie_config_read32(struct pci_bus *bus, unsigned int devfn,
int where, int size, u32 *val)
 {
int ret;
+   struct iproc_pcie *pcie = iproc_data(bus);
 
iproc_pcie_apb_err_disable(bus, true);
-   ret = pci_generic_config_read32(bus, devfn, where, size, val);
+   if (pcie->type == 

[PATCH v4 2/2] PCI: iproc: add device shutdown for PCI RC

[Oza Pawandeep]

PERST must be asserted around ~500ms before the reboot is applied.

During soft reset (e.g., "reboot" from Linux) on some iproc based SOCs
LCPLL clock and PERST both goes off simultaneously.
This will cause certain Endpoints Intel NVMe not get detected, upon
next boot sequence.

This is specifically happening with Intel P3700 400GB series.
Endpoint is expecting the clock for some amount of time after PERST is
asserted, which is not happening in Stingray (iproc based SOC).
This causes NVMe to behave in undefined way.

On the contrary Intel x86 boards, will have ref clock running, so we
do not see this behavior there.

Besides, PCI spec does not stipulate about such timings.
In-fact it does not tell us, whether PCIe device should consider
refclk to be available or not to be.

It is completely up to vendor to design their EP the way they want
with respect to ref clock availability.

500ms is just based on the observation and taken as safe margin.
This patch adds platform shutdown where it should be
called in device_shutdown while reboot command is issued.
So in sequence first Endpoint Shutdown (e.g. nvme_shutdown)
followed by RC shutdown, which issues safe PERST assertion.

Signed-off-by: Oza Pawandeep 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 

diff --git a/drivers/pci/host/pcie-iproc-platform.c 
b/drivers/pci/host/pcie-iproc-platform.c
index 90d2bdd..9512960 100644
--- a/drivers/pci/host/pcie-iproc-platform.c
+++ b/drivers/pci/host/pcie-iproc-platform.c
@@ -131,6 +131,13 @@ static int iproc_pcie_pltfm_remove(struct platform_device 
*pdev)
return iproc_pcie_remove(pcie);
 }
 
+static void iproc_pcie_pltfm_shutdown(struct platform_device *pdev)
+{
+   struct iproc_pcie *pcie = platform_get_drvdata(pdev);
+
+   iproc_pcie_shutdown(pcie);
+}
+
 static struct platform_driver iproc_pcie_pltfm_driver = {
.driver = {
.name = "iproc-pcie",
@@ -138,6 +145,7 @@ static int iproc_pcie_pltfm_remove(struct platform_device 
*pdev)
},
.probe = iproc_pcie_pltfm_probe,
.remove = iproc_pcie_pltfm_remove,
+   .shutdown = iproc_pcie_pltfm_shutdown,
 };
 module_platform_driver(iproc_pcie_pltfm_driver);
 
diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index b0abcd7..d1bcdc9 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -616,32 +616,40 @@ static int iproc_pcie_config_write32(struct pci_bus *bus, 
unsigned int devfn,
.write = iproc_pcie_config_write32,
 };
 
-static void iproc_pcie_reset(struct iproc_pcie *pcie)
+static void iproc_pcie_perst_ctrl(struct iproc_pcie *pcie, bool assert)
 {
u32 val;
 
/*
-* PAXC and the internal emulated endpoint device downstream should not
-* be reset.  If firmware has been loaded on the endpoint device at an
-* earlier boot stage, reset here causes issues.
+* The internal emulated endpoints (such as PAXC) device downstream
+* should not be reset. If firmware has been loaded on the endpoint
+* device at an earlier boot stage, reset here causes issues.
 */
if (pcie->ep_is_internal)
return;
 
-   /*
-* Select perst_b signal as reset source. Put the device into reset,
-* and then bring it out of reset
-*/
-   val = iproc_pcie_read_reg(pcie, IPROC_PCIE_CLK_CTRL);
-   val &= ~EP_PERST_SOURCE_SELECT & ~EP_MODE_SURVIVE_PERST &
-   ~RC_PCIE_RST_OUTPUT;
-   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
-   udelay(250);
-
-   val |= RC_PCIE_RST_OUTPUT;
-   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
-   msleep(100);
+   if (assert) {
+   val = iproc_pcie_read_reg(pcie, IPROC_PCIE_CLK_CTRL);
+   val &= ~EP_PERST_SOURCE_SELECT & ~EP_MODE_SURVIVE_PERST &
+   ~RC_PCIE_RST_OUTPUT;
+   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
+   udelay(250);
+   } else {
+   val = iproc_pcie_read_reg(pcie, IPROC_PCIE_CLK_CTRL);
+   val |= RC_PCIE_RST_OUTPUT;
+   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
+   msleep(100);
+   }
+}
+
+int iproc_pcie_shutdown(struct iproc_pcie *pcie)
+{
+   iproc_pcie_perst_ctrl(pcie, true);
+   msleep(500);
+
+   return 0;
 }
+EXPORT_SYMBOL(iproc_pcie_shutdown);
 
 static int iproc_pcie_check_link(struct iproc_pcie *pcie, struct pci_bus *bus)
 {
@@ -1318,7 +1326,8 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct 
list_head *res)
goto err_exit_phy;
}
 
-   iproc_pcie_reset(pcie);
+   iproc_pcie_perst_ctrl(pcie, true);
+   iproc_pcie_perst_ctrl(pcie, false);
 
if (pcie->need_ob_cfg) {
ret = iproc_pcie_map_ranges(pcie, res);
diff --git a/drivers/pci/host/pcie-iproc.h 

[PATCH v4 1/2] PCI: iproc: Retry request when CRS returned from EP

[Oza Pawandeep]

For Configuration Requests only, following reset it is possible for a
device to terminate the request but indicate that it is temporarily unable
to process the Request, but will be able to process the Request in the
future – in this case, the Configuration Request Retry Status 100 (CRS)
Completion Status is used.

As per PCI spec, CRS Software Visibility only affects config read of the
Vendor ID, for config write or any other config read the Root must
automatically re-issue configuration request again as a new request.
Iproc based PCIe RC (hw) does not retry request on its own.

As a result of the fact, PCIe RC driver (sw) should take care of CRS.
This patch fixes the problem, and attempts to read config space again in
case of PCIe code forwarding the CRS back to CPU.
It implements iproc_pcie_config_read which gets called for Stingray,
Otherwise it falls back to PCI generic APIs.

Signed-off-by: Oza Pawandeep 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 

diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index 0f39bd2..b0abcd7 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -68,6 +68,9 @@
 #define APB_ERR_EN_SHIFT 0
 #define APB_ERR_EN   BIT(APB_ERR_EN_SHIFT)
 
+#define CFG_RETRY_STATUS 0x0001
+#define CFG_RETRY_STATUS_TIMEOUT_US  50 /* 500 milli-seconds. */
+
 /* derive the enum index of the outbound/inbound mapping registers */
 #define MAP_REG(base_reg, index)  ((base_reg) + (index) * 2)
 
@@ -448,6 +451,55 @@ static inline void iproc_pcie_apb_err_disable(struct 
pci_bus *bus,
}
 }
 
+static int iproc_pcie_cfg_retry(void __iomem *cfg_data_p)
+{
+   int timeout = CFG_RETRY_STATUS_TIMEOUT_US;
+   unsigned int ret;
+
+   /*
+* As per PCI spec, CRS Software Visibility only
+* affects config read of the Vendor ID.
+* For config write or any other config read the Root must
+* automatically re-issue configuration request again as a
+* new request. Iproc based PCIe RC (hw) does not retry
+* request on its own, so handle it here.
+*/
+   do {
+   ret = readl(cfg_data_p);
+   if (ret == CFG_RETRY_STATUS)
+   udelay(1);
+   else
+   return PCIBIOS_SUCCESSFUL;
+   } while (timeout--);
+
+   return PCIBIOS_DEVICE_NOT_FOUND;
+}
+
+static void __iomem *iproc_pcie_map_ep_cfg_reg(struct iproc_pcie *pcie,
+  unsigned int busno,
+  unsigned int slot,
+  unsigned int fn,
+  int where)
+{
+   u16 offset;
+   u32 val;
+
+   /* EP device access */
+   val = (busno << CFG_ADDR_BUS_NUM_SHIFT) |
+   (slot << CFG_ADDR_DEV_NUM_SHIFT) |
+   (fn << CFG_ADDR_FUNC_NUM_SHIFT) |
+   (where & CFG_ADDR_REG_NUM_MASK) |
+   (1 & CFG_ADDR_CFG_TYPE_MASK);
+
+   iproc_pcie_write_reg(pcie, IPROC_PCIE_CFG_ADDR, val);
+   offset = iproc_pcie_reg_offset(pcie, IPROC_PCIE_CFG_DATA);
+
+   if (iproc_pcie_reg_is_invalid(offset))
+   return NULL;
+
+   return (pcie->base + offset);
+}
+
 /**
  * Note access to the configuration registers are protected at the higher layer
  * by 'pci_lock' in drivers/pci/access.c
@@ -499,13 +551,48 @@ static void __iomem *iproc_pcie_map_cfg_bus(struct 
pci_bus *bus,
return (pcie->base + offset);
 }
 
+static int iproc_pcie_config_read(struct pci_bus *bus, unsigned int devfn,
+   int where, int size, u32 *val)
+{
+   struct iproc_pcie *pcie = iproc_data(bus);
+   unsigned int slot = PCI_SLOT(devfn);
+   unsigned int fn = PCI_FUNC(devfn);
+   unsigned int busno = bus->number;
+   void __iomem *cfg_data_p;
+   int ret;
+
+   /* root complex access. */
+   if (busno == 0)
+   return pci_generic_config_read32(bus, devfn, where, size, val);
+
+   cfg_data_p = iproc_pcie_map_ep_cfg_reg(pcie, busno, slot, fn, where);
+
+   if (!cfg_data_p)
+   return PCIBIOS_DEVICE_NOT_FOUND;
+
+   ret = iproc_pcie_cfg_retry(cfg_data_p);
+   if (ret)
+   return ret;
+
+   *val = readl(cfg_data_p);
+
+   if (size <= 2)
+   *val = (*val >> (8 * (where & 3))) & ((1 << (size * 8)) - 1);
+
+   return PCIBIOS_SUCCESSFUL;
+}
+
 static int iproc_pcie_config_read32(struct pci_bus *bus, unsigned int devfn,
int where, int size, u32 *val)
 {
int ret;
+   struct iproc_pcie *pcie = iproc_data(bus);
 
iproc_pcie_apb_err_disable(bus, true);
-   ret = pci_generic_config_read32(bus, devfn, where, size, val);
+   if (pcie->type == IPROC_PCIE_PAXB_V2)
+   ret = iproc_pcie_config_read(bus, devfn, 

[PATCH v4 2/2] PCI: iproc: add device shutdown for PCI RC

[Oza Pawandeep]

PERST must be asserted around ~500ms before the reboot is applied.

During soft reset (e.g., "reboot" from Linux) on some iproc based SOCs
LCPLL clock and PERST both goes off simultaneously.
This will cause certain Endpoints Intel NVMe not get detected, upon
next boot sequence.

This is specifically happening with Intel P3700 400GB series.
Endpoint is expecting the clock for some amount of time after PERST is
asserted, which is not happening in Stingray (iproc based SOC).
This causes NVMe to behave in undefined way.

On the contrary Intel x86 boards, will have ref clock running, so we
do not see this behavior there.

Besides, PCI spec does not stipulate about such timings.
In-fact it does not tell us, whether PCIe device should consider
refclk to be available or not to be.

It is completely up to vendor to design their EP the way they want
with respect to ref clock availability.

500ms is just based on the observation and taken as safe margin.
This patch adds platform shutdown where it should be
called in device_shutdown while reboot command is issued.
So in sequence first Endpoint Shutdown (e.g. nvme_shutdown)
followed by RC shutdown, which issues safe PERST assertion.

Signed-off-by: Oza Pawandeep 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 

diff --git a/drivers/pci/host/pcie-iproc-platform.c 
b/drivers/pci/host/pcie-iproc-platform.c
index 90d2bdd..9512960 100644
--- a/drivers/pci/host/pcie-iproc-platform.c
+++ b/drivers/pci/host/pcie-iproc-platform.c
@@ -131,6 +131,13 @@ static int iproc_pcie_pltfm_remove(struct platform_device 
*pdev)
return iproc_pcie_remove(pcie);
 }
 
+static void iproc_pcie_pltfm_shutdown(struct platform_device *pdev)
+{
+   struct iproc_pcie *pcie = platform_get_drvdata(pdev);
+
+   iproc_pcie_shutdown(pcie);
+}
+
 static struct platform_driver iproc_pcie_pltfm_driver = {
.driver = {
.name = "iproc-pcie",
@@ -138,6 +145,7 @@ static int iproc_pcie_pltfm_remove(struct platform_device 
*pdev)
},
.probe = iproc_pcie_pltfm_probe,
.remove = iproc_pcie_pltfm_remove,
+   .shutdown = iproc_pcie_pltfm_shutdown,
 };
 module_platform_driver(iproc_pcie_pltfm_driver);
 
diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index b0abcd7..d1bcdc9 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -616,32 +616,40 @@ static int iproc_pcie_config_write32(struct pci_bus *bus, 
unsigned int devfn,
.write = iproc_pcie_config_write32,
 };
 
-static void iproc_pcie_reset(struct iproc_pcie *pcie)
+static void iproc_pcie_perst_ctrl(struct iproc_pcie *pcie, bool assert)
 {
u32 val;
 
/*
-* PAXC and the internal emulated endpoint device downstream should not
-* be reset.  If firmware has been loaded on the endpoint device at an
-* earlier boot stage, reset here causes issues.
+* The internal emulated endpoints (such as PAXC) device downstream
+* should not be reset. If firmware has been loaded on the endpoint
+* device at an earlier boot stage, reset here causes issues.
 */
if (pcie->ep_is_internal)
return;
 
-   /*
-* Select perst_b signal as reset source. Put the device into reset,
-* and then bring it out of reset
-*/
-   val = iproc_pcie_read_reg(pcie, IPROC_PCIE_CLK_CTRL);
-   val &= ~EP_PERST_SOURCE_SELECT & ~EP_MODE_SURVIVE_PERST &
-   ~RC_PCIE_RST_OUTPUT;
-   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
-   udelay(250);
-
-   val |= RC_PCIE_RST_OUTPUT;
-   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
-   msleep(100);
+   if (assert) {
+   val = iproc_pcie_read_reg(pcie, IPROC_PCIE_CLK_CTRL);
+   val &= ~EP_PERST_SOURCE_SELECT & ~EP_MODE_SURVIVE_PERST &
+   ~RC_PCIE_RST_OUTPUT;
+   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
+   udelay(250);
+   } else {
+   val = iproc_pcie_read_reg(pcie, IPROC_PCIE_CLK_CTRL);
+   val |= RC_PCIE_RST_OUTPUT;
+   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
+   msleep(100);
+   }
+}
+
+int iproc_pcie_shutdown(struct iproc_pcie *pcie)
+{
+   iproc_pcie_perst_ctrl(pcie, true);
+   msleep(500);
+
+   return 0;
 }
+EXPORT_SYMBOL(iproc_pcie_shutdown);
 
 static int iproc_pcie_check_link(struct iproc_pcie *pcie, struct pci_bus *bus)
 {
@@ -1318,7 +1326,8 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct 
list_head *res)
goto err_exit_phy;
}
 
-   iproc_pcie_reset(pcie);
+   iproc_pcie_perst_ctrl(pcie, true);
+   iproc_pcie_perst_ctrl(pcie, false);
 
if (pcie->need_ob_cfg) {
ret = iproc_pcie_map_ranges(pcie, res);
diff --git a/drivers/pci/host/pcie-iproc.h b/drivers/pci/host/pcie-iproc.h
index 0bbe2ea..a6b55ce 100644
--- 

[PATCH v4 0/2] PCI: iproc: SOC specific fixes

[Oza Pawandeep]

PCI: iproc: Retry request when CRS returned from EP
Above patch adds support for CRS in PCI RC driver, otherwise if not
handled at lower level, the user space PMD (poll mode drivers) can
timeout.

PCI: iproc: add device shutdown for PCI RC
This fixes the issue where certian PCI endpoints are not getting
detected on Stingray SOC after reboot.


Changes Since v4:
Bjorn's comments addressed.

Changes Since v3:
[re-send]

Changes Since v2:
Fix compilation errors for pcie-iproc-platform.ko which was caught by
kbuild.

Oza Pawandeep (2):
  PCI: iproc: Retry request when CRS returned from EP
  PCI: iproc: add device shutdown for PCI RC

 drivers/pci/host/pcie-iproc-platform.c |   8 ++
 drivers/pci/host/pcie-iproc.c  | 134 -
 drivers/pci/host/pcie-iproc.h  |   1 +
 3 files changed, 124 insertions(+), 19 deletions(-)

-- 
1.9.1

[PATCH v4 0/2] PCI: iproc: SOC specific fixes

[Oza Pawandeep]

PCI: iproc: Retry request when CRS returned from EP
Above patch adds support for CRS in PCI RC driver, otherwise if not
handled at lower level, the user space PMD (poll mode drivers) can
timeout.

PCI: iproc: add device shutdown for PCI RC
This fixes the issue where certian PCI endpoints are not getting
detected on Stingray SOC after reboot.


Changes Since v4:
Bjorn's comments addressed.

Changes Since v3:
[re-send]

Changes Since v2:
Fix compilation errors for pcie-iproc-platform.ko which was caught by
kbuild.

Oza Pawandeep (2):
  PCI: iproc: Retry request when CRS returned from EP
  PCI: iproc: add device shutdown for PCI RC

 drivers/pci/host/pcie-iproc-platform.c |   8 ++
 drivers/pci/host/pcie-iproc.c  | 134 -
 drivers/pci/host/pcie-iproc.h  |   1 +
 3 files changed, 124 insertions(+), 19 deletions(-)

-- 
1.9.1

Re: [PATCH v2] perf sort: only insert overhead && overhead_children when no overhead* field given

[Du, Changbin]

On Thu, Jun 29, 2017 at 05:22:52PM +0200, Jiri Olsa wrote:
> > > --- a/tools/perf/util/sort.c
> > > +++ b/tools/perf/util/sort.c
> > > @@ -2635,6 +2635,9 @@ static char *setup_overhead(char *keys)
> > >   if (sort__mode == SORT_MODE__DIFF)
> > >   return keys;
> > >  
> > > + if (strstr(keys, "overhead"))
> > > + return keys;
> > > +
> 
> ah ok, I think it's right.. basically you're forcing
> precedence of the -s option over the --children option
> 
> you could have your example working by running:
>   $ perf report -s overhead,sym --no-children
> 
Thanks for the knowledge.

> please state something like:
> 
> /*
>  * User already stated overhead within -s option,
>  * do not mangle with that.
>  */
> 
I'll add this as comment around the change for v3.

> thanks,
> jirka

-- 
Thanks,
Changbin Du


signature.asc
Description: PGP signature

Re: [PATCH v2] perf sort: only insert overhead && overhead_children when no overhead* field given

[Du, Changbin]

On Thu, Jun 29, 2017 at 05:22:52PM +0200, Jiri Olsa wrote:
> > > --- a/tools/perf/util/sort.c
> > > +++ b/tools/perf/util/sort.c
> > > @@ -2635,6 +2635,9 @@ static char *setup_overhead(char *keys)
> > >   if (sort__mode == SORT_MODE__DIFF)
> > >   return keys;
> > >  
> > > + if (strstr(keys, "overhead"))
> > > + return keys;
> > > +
> 
> ah ok, I think it's right.. basically you're forcing
> precedence of the -s option over the --children option
> 
> you could have your example working by running:
>   $ perf report -s overhead,sym --no-children
> 
Thanks for the knowledge.

> please state something like:
> 
> /*
>  * User already stated overhead within -s option,
>  * do not mangle with that.
>  */
> 
I'll add this as comment around the change for v3.

> thanks,
> jirka

-- 
Thanks,
Changbin Du


signature.asc
Description: PGP signature