[PATCH 6/8] ASoC: simple-card: add tdm slot supports

[Xiubo Li]

For some CPU/CODEC DAI devices the tdm slot maybe needed. This patch
adds the tdm slot supporting for simple-card driver.

The style of the tdm slot in DT:

For instance:

simple-tdm-slot = 0xffc 0xffc 2 0;

Signed-off-by: Xiubo Li li.xi...@freescale.com
---

The VF610 Tower and VF610 LS1 platforms' SPDIF will depend on this patch.


 include/sound/simple_card.h |  8 ++
 sound/soc/generic/simple-card.c | 61 +
 2 files changed, 64 insertions(+), 5 deletions(-)

diff --git a/include/sound/simple_card.h b/include/sound/simple_card.h
index e1ac996..cfc5b66 100644
--- a/include/sound/simple_card.h
+++ b/include/sound/simple_card.h
@@ -14,10 +14,18 @@
 
 #include sound/soc.h
 
+struct asoc_simple_tdm_slot {
+   unsigned int tx_mask;
+   unsigned int rx_mask;
+   int slots;
+   int slot_width;
+};
+
 struct asoc_simple_dai {
const char *name;
unsigned int fmt;
unsigned int sysclk;
+   struct asoc_simple_tdm_slot *tdm;
 };
 
 struct asoc_simple_card_info {
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 546b93d..d067e0a 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -32,7 +32,7 @@ static int __asoc_simple_card_dai_init(struct snd_soc_dai 
*dai,
ret = snd_soc_dai_set_fmt(dai, set-fmt);
if (ret  ret != -ENOTSUPP) {
dev_err(dai-dev, simple-card: set_fmt error\n);
-   return ret;
+   goto err;
}
}
 
@@ -40,10 +40,22 @@ static int __asoc_simple_card_dai_init(struct snd_soc_dai 
*dai,
ret = snd_soc_dai_set_sysclk(dai, 0, set-sysclk, 0);
if (ret  ret != -ENOTSUPP) {
dev_err(dai-dev, simple-card: set_sysclk error\n);
-   return ret;
+   goto err;
+   }
+   }
+
+   if (set-tdm) {
+   ret = snd_soc_dai_set_tdm_slot(dai, set-tdm-tx_mask,
+   set-tdm-rx_mask,
+   set-tdm-slots,
+   set-tdm-slot_width);
+   if (ret  ret != -ENOTSUPP) {
+   dev_err(dai-dev, simple-card: set_tdm_slot error\n);
+   goto err;
}
}
 
+err:
return ret;
 }
 
@@ -67,11 +79,43 @@ static int asoc_simple_card_dai_init(struct 
snd_soc_pcm_runtime *rtd)
 }
 
 static int
+asoc_simple_card_of_parse_tdm_slot(struct device_node *np,
+  struct device *dev,
+  struct asoc_simple_dai *dai,
+  const char *propname)
+{
+   struct asoc_simple_tdm_slot *tdm;
+   u32 out_value[4];
+   int ret;
+
+   if (!of_property_read_bool(np, propname))
+   return 0;
+
+   tdm = devm_kzalloc(dev, sizeof(*tdm), GFP_KERNEL);
+   if (!tdm)
+   return -ENOMEM;
+
+   ret = of_property_read_u32_array(np, propname, out_value, 4);
+   if (ret)
+   return ret;
+
+   tdm-tx_mask = out_value[0];
+   tdm-rx_mask = out_value[1];
+   tdm-slots = out_value[2];
+   tdm-slot_width = out_value[3];
+
+   dai-tdm = tdm;
+
+   return 0;
+}
+
+static int
 asoc_simple_card_sub_parse_of(struct device_node *np,
  unsigned int daifmt,
  struct asoc_simple_dai *dai,
  const struct device_node **p_node,
- const char **name)
+ const char **name,
+ struct device *dev)
 {
struct device_node *node;
struct clk *clk;
@@ -91,6 +135,11 @@ asoc_simple_card_sub_parse_of(struct device_node *np,
if (ret  0)
goto parse_error;
 
+   /* parse tdm_slot */
+   ret = asoc_simple_card_of_parse_tdm_slot(np, dev, dai, tdm-slot);
+   if (ret  0)
+   goto parse_error;
+
/*
 * bitclock-inversion, frame-inversion
 * bitclock-master,frame-master
@@ -162,7 +211,8 @@ static int asoc_simple_card_parse_of(struct device_node 
*node,
ret = asoc_simple_card_sub_parse_of(np, priv-daifmt,
  priv-cpu_dai,
  dai_link-cpu_of_node,
- dai_link-cpu_dai_name);
+ dai_link-cpu_dai_name,
+ dev);
if (ret  0)
return ret;
 
@@ -173,7 +223,8 @@ static int asoc_simple_card_parse_of(struct device_node 
*node,
ret = asoc_simple_card_sub_parse_of(np, priv-daifmt,
 

[PATCH 8/8] ASoC: simple-card: add off-codec widgets supports.

[Xiubo Li]

Signed-off-by: Xiubo Li li.xi...@freescale.com
---
 sound/soc/generic/simple-card.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index d067e0a..4b7ef4d 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -196,6 +196,14 @@ static int asoc_simple_card_parse_of(struct device_node 
*node,
priv-daifmt = snd_soc_of_parse_daifmt(node, simple-audio-card,) 
(SND_SOC_DAIFMT_FORMAT_MASK | SND_SOC_DAIFMT_INV_MASK);
 
+   /* off-codec widgets */
+   if (of_property_read_bool(node, simple-audio-card,widgets)) {
+   ret = snd_soc_of_parse_audio_simple_widgets(priv-snd_card,
+   simple-audio-card,widgets);
+   if (ret)
+   return ret;
+   }
+
/* DAPM routes */
if (of_property_read_bool(node, simple-audio-card,routing)) {
ret = snd_soc_of_parse_audio_routing(priv-snd_card,
-- 
1.8.4


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

Re: [PATCH] numa, mem-hotplug: Fix stack overflow in numa when seting kernel nodes to unhotpluggable.

[Andrew Morton]

On Thu, 23 Jan 2014 13:49:28 +0800 Tang Chen tangc...@cn.fujitsu.com wrote:

 Dave found that the kernel will hang during boot. This is because
 the nodemask_t type stack variable numa_kernel_nodes is large enough
 to overflow the stack.
 
 This doesn't always happen. According to Dave, this happened once
 in about five boots. The backtrace is like the following:
 
 dump_stack
 panic
 ? numa_clear_kernel_node_hotplug
 __stack_chk_fail
 numa_clear_kernel_node_hotplug
 ? memblock_search_pfn_nid
 ? __early_pfn_to_nid
 numa_init
 x86_numa_init
 initmem_init
 setup_arch
 start_kernel
 
 This patch fix this problem by defining numa_kernel_nodes as a
 static global variable in __initdata area.
 
 ...

 --- a/arch/x86/mm/numa.c
 +++ b/arch/x86/mm/numa.c
 @@ -562,10 +562,10 @@ static void __init numa_init_array(void)
   }
  }
  
 +static nodemask_t numa_kernel_nodes __initdata;
  static void __init numa_clear_kernel_node_hotplug(void)
  {
   int i, nid;
 - nodemask_t numa_kernel_nodes;
   unsigned long start, end;
   struct memblock_type *type = memblock.reserved;

Seems odd.  The maximum size of a nodemask_t is 128 bytes, isn't it? 
If so, what the heck have we done in there to consume so much stack?

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

[PATCH Resend 7/8] ASoC: add snd_soc_of_parse_audio_simple_widgets for DeviceTree

[Xiubo Li]

This patch adds snd_soc_of_parse_audio_simple_widgets() and supports
below style of widgets name on DT.

wname-prefix[ individual name]
wname-prefix includes: Mic, Line, Hp, Spk...

For instance:
simple-audio-widgets =
Mic Jack, Line In Jack,
Hp Jack, Spk Ext,
Line Out Jack;

Signed-off-by: Xiubo Li li.xi...@freescale.com
---

Add :
  widgets[i].name = wname;

And this will use the widget name from DT node.




 include/sound/soc.h  |  2 ++
 sound/soc/soc-core.c | 63 
 2 files changed, 65 insertions(+)

diff --git a/include/sound/soc.h b/include/sound/soc.h
index 9a00147..465dc6e 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -1173,6 +1173,8 @@ void snd_soc_util_exit(void);
 
 int snd_soc_of_parse_card_name(struct snd_soc_card *card,
   const char *propname);
+int snd_soc_of_parse_audio_simple_widgets(struct snd_soc_card *card,
+ const char *propname);
 int snd_soc_of_parse_audio_routing(struct snd_soc_card *card,
   const char *propname);
 unsigned int snd_soc_of_parse_daifmt(struct device_node *np,
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 393ff06..9c8a686 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -4417,6 +4417,69 @@ int snd_soc_of_parse_card_name(struct snd_soc_card *card,
 }
 EXPORT_SYMBOL_GPL(snd_soc_of_parse_card_name);
 
+static struct snd_soc_dapm_widget simple_widgets[] = {
+   SND_SOC_DAPM_MIC(Mic, NULL),
+   SND_SOC_DAPM_LINE(Line, NULL),
+   SND_SOC_DAPM_HP(Hp, NULL),
+   SND_SOC_DAPM_SPK(Spk, NULL),
+};
+
+int snd_soc_of_parse_audio_simple_widgets(struct snd_soc_card *card,
+ const char *propname)
+{
+   struct device_node *np = card-dev-of_node;
+   struct snd_soc_dapm_widget *widgets;
+   const char *wname;
+   int i, j, cnt, ret;
+
+   cnt = of_property_count_strings(np, propname);
+   if (cnt = 0) {
+   dev_err(card-dev,
+   ASoC: Property '%s' does not exist or 
+   length is zero\n, propname);
+   return -EINVAL;
+   }
+
+   widgets = devm_kcalloc(card-dev, cnt, sizeof(*widgets), GFP_KERNEL);
+   if (!widgets) {
+   dev_err(card-dev,
+   ASoC: Could not allocate DAPM widgets table\n);
+   return -ENOMEM;
+   }
+
+   for (i = 0; i  cnt; i++) {
+   ret = of_property_read_string_index(np, propname, i, wname);
+   if (ret) {
+   dev_err(card-dev,
+   ASoC: Property '%s' index %d could not be 
+   read: %d\n, propname, i, ret);
+   return -EINVAL;
+   }
+
+   for (j = 0; j  ARRAY_SIZE(simple_widgets); j++) {
+   if (!strncmp(wname, simple_widgets[j].name,
+strlen(simple_widgets[j].name))) {
+   widgets[i] = simple_widgets[j];
+   widgets[i].name = wname;
+   break;
+   }
+   }
+
+   if (j = ARRAY_SIZE(simple_widgets)) {
+   dev_err(card-dev,
+   ASoC: DAPM widget : '%s' is not supported\n,
+   wname);
+   return -EINVAL;
+   }
+   }
+
+   card-dapm_widgets = widgets;
+   card-num_dapm_widgets = cnt;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(snd_soc_of_parse_audio_simple_widgets);
+
 int snd_soc_of_parse_audio_routing(struct snd_soc_card *card,
   const char *propname)
 {
-- 
1.8.4


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

[PATCH 1/8] ASoC: fsl: Add VF610 soc audio card Kconfig

[Xiubo Li]

Signed-off-by: Xiubo Li li.xi...@freescale.com
---
 sound/soc/fsl/Kconfig | 24 
 1 file changed, 24 insertions(+)

diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 324988d..bc1fa9c 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -219,3 +219,27 @@ config SND_SOC_IMX_MC13783
select SND_SOC_IMX_PCM_DMA
 
 endif # SND_IMX_SOC
+
+menuconfig SND_VF610_SOC
+   tristate SoC Audio for Freescale VF610 CPUs
+   select DMA_ENGINE
+   help
+ Say Y or M if you want to add support for codecs attached to
+ the VF610 CPUs.
+
+ This will enable Freeacale SAI and SGTL5000 codec, and an extra
+ TWR-AUDIO-SGTL sub-board is needed for SGTL5000.
+
+if SND_VF610_SOC
+
+config SND_SOC_VF610_SGTL5000
+   tristate SoC Audio support for VF610 boards with SGTL5000
+   depends on OF  I2C
+   select SND_SOC_FSL_SAI
+   select SND_SOC_SGTL5000
+   select SND_SIMPLE_CARD
+   help
+ Say Y if you want to add support for SoC audio on an VF610 board with
+ a SGTL5000 codec and a SAI.
+
+endif #SND_VF610_SOC
-- 
1.8.4


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

[PATCH 0/8] New and Resend the old patches

[Xiubo Li]

New and Resend the old patches basing the newest code version.

And this patch series has been tested based the VF610 Tower board.




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

[PATCH Resend 2/8] ASoC: simple-card: fix __asoc_simple_card_dai_init

[Xiubo Li]

If the CPU/CODEC DAI set_sysclk() is not support, the -ENOTSUPP will returnd.
Here do the check like set_fmt().

Signed-off-by: Xiubo Li li.xi...@freescale.com
---



The VF610 Tower and VF610 LS1 platforms' ESAI and SPDIF will depend on this
patch too.




 sound/soc/generic/simple-card.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 6443c87..3b8c9a2 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -31,16 +31,21 @@ static int __asoc_simple_card_dai_init(struct snd_soc_dai 
*dai,
 
daifmt |= set-fmt;
 
-   if (daifmt)
+   if (daifmt) {
ret = snd_soc_dai_set_fmt(dai, daifmt);
-
-   if (ret == -ENOTSUPP) {
-   dev_dbg(dai-dev, ASoC: set_fmt is not supported\n);
-   ret = 0;
+   if (ret  ret != -ENOTSUPP) {
+   dev_err(dai-dev, simple-card: set_fmt error\n);
+   return ret;
+   }
}
 
-   if (!ret  set-sysclk)
+   if (set-sysclk) {
ret = snd_soc_dai_set_sysclk(dai, 0, set-sysclk, 0);
+   if (ret  ret != -ENOTSUPP) {
+   dev_err(dai-dev, simple-card: set_sysclk error\n);
+   return ret;
+   }
+   }
 
return ret;
 }
-- 
1.8.4


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

[PATCH Resend 3/8] ASoC: simple-card: simplify the daifmt code

[Xiubo Li]

In the asoc_simple_card_parse_of() will parse the device node's CPU/CODEC
DAI commone fmts, and then in asoc_simple_card_sub_parse_of() will parse
the CPU/CODEC DAI's sub-node fmts, so we can combine the info-daifmt and
info-set.fmt in asoc_simple_card_sub_parse_of() not while just before
_set_fmt().

And this will be more easy to add new functions, such as supporting
_set_tdm_slot(), etc.

Signed-off-by: Xiubo Li li.xi...@freescale.com
---
 sound/soc/generic/simple-card.c | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 3b8c9a2..f38e56e 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -24,15 +24,12 @@ struct simple_card_data {
 };
 
 static int __asoc_simple_card_dai_init(struct snd_soc_dai *dai,
-  struct asoc_simple_dai *set,
-  unsigned int daifmt)
+  struct asoc_simple_dai *set)
 {
int ret = 0;
 
-   daifmt |= set-fmt;
-
-   if (daifmt) {
-   ret = snd_soc_dai_set_fmt(dai, daifmt);
+   if (set-fmt) {
+   ret = snd_soc_dai_set_fmt(dai, set-fmt);
if (ret  ret != -ENOTSUPP) {
dev_err(dai-dev, simple-card: set_fmt error\n);
return ret;
@@ -56,14 +53,13 @@ static int asoc_simple_card_dai_init(struct 
snd_soc_pcm_runtime *rtd)
snd_soc_card_get_drvdata(rtd-card);
struct snd_soc_dai *codec = rtd-codec_dai;
struct snd_soc_dai *cpu = rtd-cpu_dai;
-   unsigned int daifmt = priv-daifmt;
int ret;
 
-   ret = __asoc_simple_card_dai_init(codec, priv-codec_dai, daifmt);
+   ret = __asoc_simple_card_dai_init(codec, priv-codec_dai);
if (ret  0)
return ret;
 
-   ret = __asoc_simple_card_dai_init(cpu, priv-cpu_dai, daifmt);
+   ret = __asoc_simple_card_dai_init(cpu, priv-cpu_dai);
if (ret  0)
return ret;
 
@@ -72,6 +68,7 @@ static int asoc_simple_card_dai_init(struct 
snd_soc_pcm_runtime *rtd)
 
 static int
 asoc_simple_card_sub_parse_of(struct device_node *np,
+ unsigned int daifmt,
  struct asoc_simple_dai *dai,
  const struct device_node **p_node,
  const char **name)
@@ -100,6 +97,7 @@ asoc_simple_card_sub_parse_of(struct device_node *np,
 * and specific format if it has
 */
dai-fmt = snd_soc_of_parse_daifmt(np, NULL);
+   dai-fmt |= daifmt;
 
/*
 * dai-sysclk come from
@@ -158,7 +156,7 @@ static int asoc_simple_card_parse_of(struct device_node 
*node,
ret = -EINVAL;
np = of_get_child_by_name(node, simple-audio-card,cpu);
if (np)
-   ret = asoc_simple_card_sub_parse_of(np,
+   ret = asoc_simple_card_sub_parse_of(np, priv-daifmt,
  priv-cpu_dai,
  dai_link-cpu_of_node,
  dai_link-cpu_dai_name);
@@ -169,7 +167,7 @@ static int asoc_simple_card_parse_of(struct device_node 
*node,
ret = -EINVAL;
np = of_get_child_by_name(node, simple-audio-card,codec);
if (np)
-   ret = asoc_simple_card_sub_parse_of(np,
+   ret = asoc_simple_card_sub_parse_of(np, priv-daifmt,
  priv-codec_dai,
  dai_link-codec_of_node,
  dai_link-codec_dai_name);
-- 
1.8.4


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

Re: [PATCH] numa, mem-hotplug: Fix stack overflow in numa when seting kernel nodes to unhotpluggable.

[David Rientjes]

On Thu, 23 Jan 2014, Tang Chen wrote:

 Dave found that the kernel will hang during boot. This is because
 the nodemask_t type stack variable numa_kernel_nodes is large enough
 to overflow the stack.
 
 This doesn't always happen. According to Dave, this happened once
 in about five boots. The backtrace is like the following:
 
 dump_stack
 panic
 ? numa_clear_kernel_node_hotplug
 __stack_chk_fail
 numa_clear_kernel_node_hotplug
 ? memblock_search_pfn_nid
 ? __early_pfn_to_nid
 numa_init
 x86_numa_init
 initmem_init
 setup_arch
 start_kernel
 
 This patch fix this problem by defining numa_kernel_nodes as a
 static global variable in __initdata area.
 
 Reported-by: Dave Jones da...@redhat.com
 Signed-off-by: Tang Chen tangc...@cn.fujitsu.com
 Tested-by: Gu Zheng guz.f...@cn.fujitsu.com

I guess it depends on what Dave's CONFIG_NODES_SHIFT is?

 ---
  arch/x86/mm/numa.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
 index 81b2750..ebefeb7 100644
 --- a/arch/x86/mm/numa.c
 +++ b/arch/x86/mm/numa.c
 @@ -562,10 +562,10 @@ static void __init numa_init_array(void)
   }
  }
  
 +static nodemask_t numa_kernel_nodes __initdata;
  static void __init numa_clear_kernel_node_hotplug(void)
  {
   int i, nid;
 - nodemask_t numa_kernel_nodes;
   unsigned long start, end;
   struct memblock_type *type = memblock.reserved;
  

Isn't this also a bugfix since you never initialize numa_kernel_nodes when 
it's allocated on the stack with NODE_MASK_NONE?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Bug 67651] Bisected: Lots of fragmented mmaps cause gimp to fail in 3.12 after exceeding vm_max_map_count

[Andrew Morton]

On Thu, 23 Jan 2014 09:59:06 +0400 Cyrill Gorcunov gorcu...@gmail.com wrote:

 On Wed, Jan 22, 2014 at 02:45:53PM -0800, Andy Lutomirski wrote:
   
   Thus when user space application track memory changes now it can 
   detect if
   vma area is renewed.
  
  Presumably some path is failing to set VM_SOFTDIRTY, thus preventing mms
  from being merged.
  
  That being said, this could cause vma blowups for programs that are
  actually using this thing.
 
 Hi Andy, indeed, this could happen. The easiest way is to ignore softdirty bit
 when we're trying to merge vmas and set it one new merged. I think this should
 be correct. Once I finish I'll send the patch.

Hang on.  We think the problem is that gimp is generating vmas which
*should* be merged, but for unknown reasons they differ in
VM_SOFTDIRTY, yes?

Shouldn't we work out where we're forgetting to set VM_SOFTDIRTY? 
Putting bandaids over this error when we come to trying to merge the
vmas sounds very wrong?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] (xen) stable/for-linus-3.14-rc0-tag

[Linus Torvalds]

On Wed, Jan 22, 2014 at 11:36 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:

  46 files changed, 3379 insertions(+), 2117 deletions(-)

Please fix your script to detect renames - add '-M' to your git diff
--stat line (and '--summary' too, for that matter)

The correct statistics are actually

 45 files changed, 1952 insertions(+), 690 deletions(-)
 rename drivers/xen/{events.c = events/events_base.c} (70%)

as rename detection would have shown.

(Rename detection isn't the default for git, because the resulting
diffs aren't applicable by old broken versions of patch. Some day I
might ask Junio to consider making it the default, but in the name of
interoperability that day is years from now.. GNU patch actually does
understand rename diffs, but other tools like diffstat etc still
don't)

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

Re: Arndale Timer Interrupt Question

[Mj Embd]

On 1/10/14, Tomasz Figa t.f...@samsung.com wrote:
 Hi,

 On 09.01.2014 13:52, Bartlomiej Zolnierkiewicz wrote:

 added linux-samsung-soc to cc:,
 it is a better suited list for this question

 On Thursday, January 09, 2014 10:30:56 AM Mj Embd wrote:
 I am a bit confused on the interrupt number for CNTVIRQ..CNTHPIRQ. Can
 you please help here.

 As per the exynos5 public manual
 What is the difference between  CPU_nCNTHPIRQ[0] and CNTHPIRQ.

 I'm not sure if this is really what I think it is, but looking at the
 manual, CPU_nCNTHPIRQ[0] and [1] SPI ports and CNTHPIRQ PPI port seem to
 be the same signals, with the difference that the first two are shared
 interrupts connected through the combiner, while the last one is a
 per-processor interrupt, directly connected to GIC PPI port, allowing
 each CPU to get its own CNTHPIRQ signal ([0] for CPU 0 and [1] for CPU 1).

So while registering the IRQ which one has to be used Core0:26/33 Core1:26/54 ?

 Best regards,
 Tomasz


 While the later has an interrupt ID 26, the former is part of a group
 with combined interrupt id as 33 for core 0 and 54 for core 1.

 For a timer interrupt which goes to PL2, which id should be used 26 or
 33 for core 0 ?

 Please clear this confusion.

 Many Thanks

 --
 To unsubscribe from this list: send the line unsubscribe
 linux-samsung-soc in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html




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

[PATCH 5/8] ASoC: core: set_tdm_slot() will return -ENOTSUPP if no operation provided

[Xiubo Li]

Make it easier for generic code to work with set_tdm_slot() by distinguishing
between the operation not being supported and an error as is done.

Signed-off-by: Xiubo Li li.xi...@freescale.com
---
 sound/soc/soc-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index fe1df50..393ff06 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -3626,7 +3626,7 @@ int snd_soc_dai_set_tdm_slot(struct snd_soc_dai *dai,
return dai-driver-ops-set_tdm_slot(dai, tx_mask, rx_mask,
slots, slot_width);
else
-   return -EINVAL;
+   return -ENOTSUPP;
 }
 EXPORT_SYMBOL_GPL(snd_soc_dai_set_tdm_slot);
 
-- 
1.8.4


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

Re: [PATCH 6/8] ASoC: simple-card: add tdm slot supports

[David Rientjes]

On Thu, 23 Jan 2014, Xiubo Li wrote:

 diff --git a/include/sound/simple_card.h b/include/sound/simple_card.h
 index e1ac996..cfc5b66 100644
 --- a/include/sound/simple_card.h
 +++ b/include/sound/simple_card.h
 @@ -14,10 +14,18 @@
  
  #include sound/soc.h
  
 +struct asoc_simple_tdm_slot {
 + unsigned int tx_mask;
 + unsigned int rx_mask;
 + int slots;
 + int slot_width;
 +};
 +
  struct asoc_simple_dai {
   const char *name;
   unsigned int fmt;
   unsigned int sysclk;
 + struct asoc_simple_tdm_slot *tdm;
  };
  
  struct asoc_simple_card_info {
 diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
 index 546b93d..d067e0a 100644
 --- a/sound/soc/generic/simple-card.c
 +++ b/sound/soc/generic/simple-card.c
 @@ -32,7 +32,7 @@ static int __asoc_simple_card_dai_init(struct snd_soc_dai 
 *dai,
   ret = snd_soc_dai_set_fmt(dai, set-fmt);
   if (ret  ret != -ENOTSUPP) {
   dev_err(dai-dev, simple-card: set_fmt error\n);
 - return ret;
 + goto err;
   }
   }
  
 @@ -40,10 +40,22 @@ static int __asoc_simple_card_dai_init(struct snd_soc_dai 
 *dai,
   ret = snd_soc_dai_set_sysclk(dai, 0, set-sysclk, 0);
   if (ret  ret != -ENOTSUPP) {
   dev_err(dai-dev, simple-card: set_sysclk error\n);
 - return ret;
 + goto err;
 + }
 + }
 +
 + if (set-tdm) {
 + ret = snd_soc_dai_set_tdm_slot(dai, set-tdm-tx_mask,
 + set-tdm-rx_mask,
 + set-tdm-slots,
 + set-tdm-slot_width);
 + if (ret  ret != -ENOTSUPP) {
 + dev_err(dai-dev, simple-card: set_tdm_slot error\n);
 + goto err;
   }
   }
  
 +err:
   return ret;
  }
  
 @@ -67,11 +79,43 @@ static int asoc_simple_card_dai_init(struct 
 snd_soc_pcm_runtime *rtd)
  }
  
  static int
 +asoc_simple_card_of_parse_tdm_slot(struct device_node *np,
 +struct device *dev,
 +struct asoc_simple_dai *dai,
 +const char *propname)
 +{
 + struct asoc_simple_tdm_slot *tdm;
 + u32 out_value[4];
 + int ret;
 +
 + if (!of_property_read_bool(np, propname))
 + return 0;
 +
 + tdm = devm_kzalloc(dev, sizeof(*tdm), GFP_KERNEL);
 + if (!tdm)
 + return -ENOMEM;
 +
 + ret = of_property_read_u32_array(np, propname, out_value, 4);
 + if (ret)
 + return ret;

Looks like a memory leak?

 +
 + tdm-tx_mask = out_value[0];
 + tdm-rx_mask = out_value[1];
 + tdm-slots = out_value[2];
 + tdm-slot_width = out_value[3];
 +
 + dai-tdm = tdm;
 +
 + return 0;
 +}
 +
 +static int
  asoc_simple_card_sub_parse_of(struct device_node *np,
 unsigned int daifmt,
 struct asoc_simple_dai *dai,
 const struct device_node **p_node,
 -   const char **name)
 +   const char **name,
 +   struct device *dev)
  {
   struct device_node *node;
   struct clk *clk;
 @@ -91,6 +135,11 @@ asoc_simple_card_sub_parse_of(struct device_node *np,
   if (ret  0)
   goto parse_error;
  
 + /* parse tdm_slot */
 + ret = asoc_simple_card_of_parse_tdm_slot(np, dev, dai, tdm-slot);
 + if (ret  0)
 + goto parse_error;
 +
   /*
* bitclock-inversion, frame-inversion
* bitclock-master,frame-master
 @@ -162,7 +211,8 @@ static int asoc_simple_card_parse_of(struct device_node 
 *node,
   ret = asoc_simple_card_sub_parse_of(np, priv-daifmt,
 priv-cpu_dai,
 dai_link-cpu_of_node,
 -   dai_link-cpu_dai_name);
 +   dai_link-cpu_dai_name,
 +   dev);
   if (ret  0)
   return ret;
  
 @@ -173,7 +223,8 @@ static int asoc_simple_card_parse_of(struct device_node 
 *node,
   ret = asoc_simple_card_sub_parse_of(np, priv-daifmt,
 priv-codec_dai,
 dai_link-codec_of_node,
 -   dai_link-codec_dai_name);
 +   dai_link-codec_dai_name,
 +   dev);
   if (ret  0)
   return ret;
  
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org

Re: [PATCH] numa, mem-hotplug: Fix stack overflow in numa when seting kernel nodes to unhotpluggable.

[Dave Jones]

On Wed, Jan 22, 2014 at 10:06:14PM -0800, David Rientjes wrote:
  On Thu, 23 Jan 2014, Tang Chen wrote:
  
   Dave found that the kernel will hang during boot. This is because
   the nodemask_t type stack variable numa_kernel_nodes is large enough
   to overflow the stack.
   
   This doesn't always happen. According to Dave, this happened once
   in about five boots. The backtrace is like the following:
   
   dump_stack
   panic
   ? numa_clear_kernel_node_hotplug
   __stack_chk_fail
   numa_clear_kernel_node_hotplug
   ? memblock_search_pfn_nid
   ? __early_pfn_to_nid
   numa_init
   x86_numa_init
   initmem_init
   setup_arch
   start_kernel
   
   This patch fix this problem by defining numa_kernel_nodes as a
   static global variable in __initdata area.
   
   Reported-by: Dave Jones da...@redhat.com
   Signed-off-by: Tang Chen tangc...@cn.fujitsu.com
   Tested-by: Gu Zheng guz.f...@cn.fujitsu.com
  
  I guess it depends on what Dave's CONFIG_NODES_SHIFT is?

It's 10, because I had MAXSMP set.

So, MAX_NUMNODES = 1  10

And the bitmask is made of longs. 1024 of them.

How does this work ?

Dave

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

Re: [PATCH] numa, mem-hotplug: Fix stack overflow in numa when seting kernel nodes to unhotpluggable.

[David Rientjes]

On Thu, 23 Jan 2014, Dave Jones wrote:

 It's 10, because I had MAXSMP set.
 
 So, MAX_NUMNODES = 1  10
 
 And the bitmask is made of longs. 1024 of them.
 
 How does this work ?
 

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

linux-next: Tree for Jan 23

[Stephen Rothwell]

Hi all,

This tree fails (more than usual) the powerpc allyesconfig build.

Changes since 20140122:

Removed trees: sh, sh-current

Dropped tree: imx-mxs (complex merge conflicts against the arm tree)

The powerpc tree still had its build failure.

The arm-soc tree gained a conflict against Linus' tree.

The userns tree gained a conflict against the mips tree.

The init tree lost one of its patches.

Non-merge commits (relative to Linus' tree): 6876
 7279 files changed, 331484 insertions(+), 151447 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 as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final
link) and i386, sparc, sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

I am currently merging 208 trees (counting Linus' and 28 trees of patches
pending for Linus' tree).

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

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

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

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (df32e43a54d0 Merge branch 'akpm' (incoming from Andrew))
Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator)
Merging kbuild-current/rc-fixes (19514fc665ff arm, kbuild: make make install 
not depend on vmlinux)
Merging arc-current/for-curr (7e22e91102c6 Linux 3.13-rc8)
Merging arm-current/fixes (b25f3e1c3584 ARM: 7938/1: OMAP4/highbank: Flush L2 
cache before disabling)
Merging m68k-current/for-linus (56931d73697c m68k/mac: Make SCC reset work more 
reliably)
Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2)
Merging powerpc-merge/merge (b3084f4db3ae powerpc/thp: Fix crash on mremap)
Merging sparc/master (ef350bb7c5e0 Merge tag 'ext4_for_linus_stable' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4)
Merging net/master (7d0d46da750a Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging ipsec/master (965cdea82569 dccp: catch failed request_module call in 
dccp_probe init)
Merging sound-current/for-linus (2387083157b8 ALSA: hda - Apply +5dB output amp 
on ASUS Zenbook UX31A)
Merging pci-current/for-linus (f0b75693cbb2 MAINTAINERS: Add DesignWare, i.MX6, 
Armada, R-Car PCI host maintainers)
Merging wireless/master (2eff7c791a18 Merge tag 'nfc-fixes-3.13-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-fixes)
Merging driver-core.current/driver-core-linus (413541dd66d5 Linux 3.13-rc5)
Merging tty.current/tty-linus (413541dd66d5 Linux 3.13-rc5)
Merging usb.current/usb-linus (413541dd66d5 Linux 3.13-rc5)
Merging staging.current/staging-linus (413541dd66d5 Linux 3.13-rc5)
Merging char-misc.current/char-misc-linus (802eee95bde7 Linux 3.13-rc6)
Merging input-current/for-linus (8e2f2325b73f Input: xpad - add new USB IDs for 
Logitech F310 and F710)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding discard 
stripe)
Merging crypto-current/master (efb753b8e013 crypto: ixp4xx - Fix kernel compile 
error)
Merging ide/master (c2f7d1e103ef ide: pmac: remove unnecessary 
pci_set_drvdata())
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (6f041e99fc7b of: Fix NULL 
dereference in unflatten_and_copy())
Merging rr-fixes/fixes (7122c3e9154b scripts/link-vmlinux.sh: only filter 
kernel symbols for arm)
Merging mfd-fixes/master (73beb63d290f mfd: rtsx_pcr: Disable interrupts before 
cancelling delayed works)
Merging vfio-fixes/for-linus (239a87020b26 Merge branch 
'for-joerg/arm-smmu

Re: [Bug 67651] Bisected: Lots of fragmented mmaps cause gimp to fail in 3.12 after exceeding vm_max_map_count

[Cyrill Gorcunov]

On Wed, Jan 22, 2014 at 10:09:10PM -0800, Andrew Morton wrote:
   
   That being said, this could cause vma blowups for programs that are
   actually using this thing.
  
  Hi Andy, indeed, this could happen. The easiest way is to ignore softdirty 
  bit
  when we're trying to merge vmas and set it one new merged. I think this 
  should
  be correct. Once I finish I'll send the patch.
 
 Hang on.  We think the problem is that gimp is generating vmas which
 *should* be merged, but for unknown reasons they differ in
 VM_SOFTDIRTY, yes?

Yes. One place where I forgot to set softdirty bit is setup_arg_pages. But
it called once on elf load, so it can't cause such effect (but should be
fixed too). Also there is do_brk where vmasoftdirty is missed too :/

Another problem is the potential scenario when we have a bunch of vmas
and clear vma-softdirty bit on them, then we try to map new one, flags
won't match and instead of extending old vma the new one will be created.
I think (if only I'm not missing something) that vma-softdirty should
be ignored in such case (ie inside is_mergeable_vma) and once vma extended
it should be marked as dirty one. Again, I need to think and test more.

 Shouldn't we work out where we're forgetting to set VM_SOFTDIRTY? 
 Putting bandaids over this error when we come to trying to merge the
 vmas sounds very wrong?

I'm looking into this as well.

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

Re: [PATCH v2] mm/zswap: Check all pool pages instead of one pool pages

[Cai Liu]

Hello Minchan

2014/1/23 Minchan Kim minc...@kernel.org:
 Hello Cai,

 On Thu, Jan 23, 2014 at 09:38:41AM +0800, Cai Liu wrote:
 Hello Dan

 2014/1/22 Dan Streetman ddstr...@ieee.org:
  On Wed, Jan 22, 2014 at 7:16 AM, Cai Liu liucai@gmail.com wrote:
  Hello Minchan
 
 
  2014/1/22 Minchan Kim minc...@kernel.org
 
  Hello Cai,
 
  On Tue, Jan 21, 2014 at 09:52:25PM +0800, Cai Liu wrote:
   Hello Minchan
  
   2014/1/21 Minchan Kim minc...@kernel.org:
Hello,
   
On Tue, Jan 21, 2014 at 02:35:07PM +0800, Cai Liu wrote:
2014/1/21 Minchan Kim minc...@kernel.org:
 Please check your MUA and don't break thread.

 On Tue, Jan 21, 2014 at 11:07:42AM +0800, Cai Liu wrote:
 Thanks for your review.

 2014/1/21 Minchan Kim minc...@kernel.org:
  Hello Cai,
 
  On Mon, Jan 20, 2014 at 03:50:18PM +0800, Cai Liu wrote:
  zswap can support multiple swapfiles. So we need to check
  all zbud pool pages in zswap.
 
  Version 2:
* add *total_zbud_pages* in zbud to record all the pages in 
  pools
* move the updating of pool pages statistics to
  alloc_zbud_page/free_zbud_page to hide the details
 
  Signed-off-by: Cai Liu cai@samsung.com
  ---
   include/linux/zbud.h |2 +-
   mm/zbud.c|   44 
  
   mm/zswap.c   |4 ++--
   3 files changed, 35 insertions(+), 15 deletions(-)
 
  diff --git a/include/linux/zbud.h b/include/linux/zbud.h
  index 2571a5c..1dbc13e 100644
  --- a/include/linux/zbud.h
  +++ b/include/linux/zbud.h
  @@ -17,6 +17,6 @@ void zbud_free(struct zbud_pool *pool, 
  unsigned long handle);
   int zbud_reclaim_page(struct zbud_pool *pool, unsigned int 
  retries);
   void *zbud_map(struct zbud_pool *pool, unsigned long handle);
   void zbud_unmap(struct zbud_pool *pool, unsigned long 
  handle);
  -u64 zbud_get_pool_size(struct zbud_pool *pool);
  +u64 zbud_get_pool_size(void);
 
   #endif /* _ZBUD_H_ */
  diff --git a/mm/zbud.c b/mm/zbud.c
  index 9451361..711aaf4 100644
  --- a/mm/zbud.c
  +++ b/mm/zbud.c
  @@ -52,6 +52,13 @@
   #include linux/spinlock.h
   #include linux/zbud.h
 
  +/*
  +* statistics
  +**/
  +
  +/* zbud pages in all pools */
  +static u64 total_zbud_pages;
  +
   /*
* Structures
   */
  @@ -142,10 +149,28 @@ static struct zbud_header 
  *init_zbud_page(struct page *page)
return zhdr;
   }
 
  +static struct page *alloc_zbud_page(struct zbud_pool *pool, 
  gfp_t gfp)
  +{
  + struct page *page;
  +
  + page = alloc_page(gfp);
  +
  + if (page) {
  + pool-pages_nr++;
  + total_zbud_pages++;
 
  Who protect race?

 Yes, here the pool-pages_nr and also the total_zbud_pages are 
 not protected.
 I will re-do it.

 I will change *total_zbud_pages* to atomic type.

 Wait, it doesn't make sense. Now, you assume zbud allocator would 
 be used
 for only zswap. It's true until now but we couldn't make sure it 
 in future.
 If other user start to use zbud allocator, total_zbud_pages would 
 be pointless.
   
Yes, you are right.  ZBUD is a common module. So in this patch 
calculate the
zswap pool size in zbud is not suitable.
   

 Another concern is that what's your scenario for above two swap?
 How often we need to call zbud_get_pool_size?
 In previous your patch, you reduced the number of call so IIRC,
 we only called it in zswap_is_full and for debugfs.
   
zbud_get_pool_size() is called frequently when adding/freeing zswap
entry happen in zswap . This is why in this patch I added a counter 
in zbud,
and then in zswap the iteration of zswap_list to calculate the pool 
size will
not be needed.
   
We can remove updating zswap_pool_pages in zswap_frontswap_store and
zswap_free_entry as I said. So zswap_is_full is only hot spot.
Do you think it's still big overhead? Why? Maybe locking to prevent
destroying? Then, we can use RCU to minimize the overhead as I 
mentioned.
  
   I get your point. Yes, In my previous patch, zswap_is_full() was the
   only path to call
   zbud_get_pool_size(). And your suggestion on patch v1 to remove the 
   unnecessary
   iteration will reduce the overhead further.
  
   So adding the calculating of all the pool size in zswap.c is better.
  
   
 Of course, it would need some lock or refcount to prevent destroy
 of zswap_tree in parallel with zswap_frontswap_invalidate_area but
 zswap_is_full doesn't need to be exact so RCU would be good fit.

 Most important point is that now zswap 

Re: [PATCH] numa, mem-hotplug: Fix stack overflow in numa when seting kernel nodes to unhotpluggable.

[Tang Chen]

On 01/23/2014 02:13 PM, Dave Jones wrote:

On Wed, Jan 22, 2014 at 10:06:14PM -0800, David Rientjes wrote:
On Thu, 23 Jan 2014, Tang Chen wrote:
  

..

  
I guess it depends on what Dave's CONFIG_NODES_SHIFT is?

It's 10, because I had MAXSMP set.

So, MAX_NUMNODES = 1  10

And the bitmask is made of longs. 1024 of them.

How does this work ?


I have the same config with you.

Would you please try it for me ?  Does it work on your box ?

I cannot reproduce this problem on the latest kernel.
But I can reproduce it on 3.10.

Thanks



Dave

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



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

[PATCH] arm: vt8500: Fix gpio mux setup in vt8500_init()

[Tony Prisk]

With the switch to a pinctrl driver, and the dropping of the gpio driver,
the code in vt8500_init now always fails, and drops back to LEGACY mode.

Update the gpio mux init code, and removing the #ifdef's and the LEGACY
mode fallback.

Signed-off-by: Tony Prisk li...@prisktech.co.nz
---
 arch/arm/mach-vt8500/vt8500.c |   91 ++---
 1 file changed, 30 insertions(+), 61 deletions(-)

diff --git a/arch/arm/mach-vt8500/vt8500.c b/arch/arm/mach-vt8500/vt8500.c
index 4a73464..fe5243e 100644
--- a/arch/arm/mach-vt8500/vt8500.c
+++ b/arch/arm/mach-vt8500/vt8500.c
@@ -32,9 +32,6 @@
 #include linux/of_irq.h
 #include linux/of_platform.h
 
-#define LEGACY_GPIO_BASE   0xD811
-#define LEGACY_PMC_BASE0xD813
-
 /* Registers in GPIO Controller */
 #define VT8500_GPIO_MUX_REG0x200
 
@@ -75,89 +72,61 @@ static void vt8500_power_off(void)
 void __init vt8500_init(void)
 {
struct device_node *np;
-#if defined(CONFIG_FB_VT8500) || defined(CONFIG_FB_WM8505)
struct device_node *fb;
-   void __iomem *gpio_base;
-#endif
+   void __iomem *base;
 
-#ifdef CONFIG_FB_VT8500
fb = of_find_compatible_node(NULL, NULL, via,vt8500-fb);
if (fb) {
-   np = of_find_compatible_node(NULL, NULL, via,vt8500-gpio);
-   if (np) {
-   gpio_base = of_iomap(np, 0);
-
-   if (!gpio_base)
-   pr_err(%s: of_iomap(gpio_mux) failed\n,
-   __func__);
+   np = of_find_compatible_node(NULL, NULL, via,vt8500-pinctrl);
+   if (!np) {
+   pr_err(pinctrl node required for framebuffer\n);
+   BUG();
+   }
 
-   of_node_put(np);
+   base = of_iomap(np, 0);
+   if (base) {
+   writel(readl(base + VT8500_GPIO_MUX_REG) | 1,
+  base + VT8500_GPIO_MUX_REG);
+   iounmap(base);
} else {
-   gpio_base = ioremap(LEGACY_GPIO_BASE, 0x1000);
-   if (!gpio_base)
-   pr_err(%s: ioremap(legacy_gpio_mux) failed\n,
-   __func__);
+   pr_err(%s: of_iomap(gpio_mux) failed\n, __func__);
}
-   if (gpio_base) {
-   writel(readl(gpio_base + VT8500_GPIO_MUX_REG) | 1,
-   gpio_base + VT8500_GPIO_MUX_REG);
-   iounmap(gpio_base);
-   } else
-   pr_err(%s: Could not remap GPIO mux\n, __func__);
 
+   of_node_put(np);
of_node_put(fb);
}
-#endif
 
-#ifdef CONFIG_FB_WM8505
fb = of_find_compatible_node(NULL, NULL, wm,wm8505-fb);
if (fb) {
-   np = of_find_compatible_node(NULL, NULL, wm,wm8505-gpio);
-   if (!np)
-   np = of_find_compatible_node(NULL, NULL,
-   wm,wm8650-gpio);
-   if (np) {
-   gpio_base = of_iomap(np, 0);
-
-   if (!gpio_base)
-   pr_err(%s: of_iomap(gpio_mux) failed\n,
-   __func__);
-
-   of_node_put(np);
+   np = of_find_compatible_node(NULL, NULL, wm,prizm-pinctrl);
+   if (!np) {
+   pr_err(pinctrl node required for framebuffer\n);
+   BUG();
+   }
+
+   base = of_iomap(np, 0);
+   if (base) {
+   writel(readl(base + VT8500_GPIO_MUX_REG) |
+  0x8000, base + VT8500_GPIO_MUX_REG);
+   iounmap(base);
} else {
-   gpio_base = ioremap(LEGACY_GPIO_BASE, 0x1000);
-   if (!gpio_base)
-   pr_err(%s: ioremap(legacy_gpio_mux) failed\n,
-   __func__);
+   pr_err(%s: of_iomap(gpio_mux) failed\n, __func__);
}
-   if (gpio_base) {
-   writel(readl(gpio_base + VT8500_GPIO_MUX_REG) |
-   0x8000, gpio_base + VT8500_GPIO_MUX_REG);
-   iounmap(gpio_base);
-   } else
-   pr_err(%s: Could not remap GPIO mux\n, __func__);
 
+   of_node_put(np);
of_node_put(fb);
}
-#endif
 
np = of_find_compatible_node(NULL, NULL, via,vt8500-pmc);
if (np) {
pmc_base = of_iomap(np, 0);
-
-   if (!pmc_base)
-   

RE: [PATCH 6/8] ASoC: simple-card: add tdm slot supports

[li.xi...@freescale.com]

Hi David,

Firstly thanks for your comment.

  +asoc_simple_card_of_parse_tdm_slot(struct device_node *np,
  +  struct device *dev,
  +  struct asoc_simple_dai *dai,
  +  const char *propname)
  +{
  +   struct asoc_simple_tdm_slot *tdm;
  +   u32 out_value[4];
  +   int ret;
  +
  +   if (!of_property_read_bool(np, propname))
  +   return 0;
  +
  +   tdm = devm_kzalloc(dev, sizeof(*tdm), GFP_KERNEL);
  +   if (!tdm)
  +   return -ENOMEM;
  +
  +   ret = of_property_read_u32_array(np, propname, out_value, 4);
  +   if (ret)
  +   return ret;
 
 Looks like a memory leak?


Using devm_ and this will be called by _probe().

Please see the Documentation/driver-model/devres.txt for detail about
devres.

 
  +
  +   tdm-tx_mask = out_value[0];
  +   tdm-rx_mask = out_value[1];
  +   tdm-slots = out_value[2];
  +   tdm-slot_width = out_value[3];
  +
  +   dai-tdm = tdm;
  +
  +   return 0;
  +}
  +

Thanks,

Best Regards,
Xiubo

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

Re: linux-next: Tree for Jan 23

[Stephen Rothwell]

Hi Paul,

On Thu, 23 Jan 2014 17:21:09 +1100 Stephen Rothwell s...@canb.auug.org.au 
wrote:

 Changes since 20140122:
 
 The init tree lost one of its patches.

It turns out that I merged yesterday's version of the init tree again
today (so the fixes that went in do not appear).  Sorry about that, I
will try to do better tomorrow.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpusXTO0yRHC.pgp
Description: PGP signature

[PATCH] serial: vt8500: Add missing binding document for arch-vt8500 serial driver.

[Tony Prisk]

The binding document for the vt8500/wm8xxx SoC UART driver is missing.
This patch adds the binding document.

Signed-off-by: Tony Prisk li...@prisktech.co.nz
---
 .../devicetree/bindings/serial/vt8500-uart.txt |   26 
 1 file changed, 26 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/serial/vt8500-uart.txt

diff --git a/Documentation/devicetree/bindings/serial/vt8500-uart.txt 
b/Documentation/devicetree/bindings/serial/vt8500-uart.txt
new file mode 100644
index 000..795c393
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/vt8500-uart.txt
@@ -0,0 +1,26 @@
+* VIA VT8500 and WonderMedia WM8xxx UART Controller
+
+Required properties:
+- compatible: should be via,vt8500-uart
+
+- reg: base physical address of the controller and length of memory mapped
+   region.
+
+- interrupts: hardware interrupt number
+
+- clocks: shall be the input parent clock phandle for the clock. This should
+   be the 24Mhz reference clock.
+
+Aliases may be defined to ensure the correct ordering of the uarts.
+
+Example:
+   aliases {
+   serial0 = uart0;
+   };
+
+   uart0: serial@d820 {
+   compatible = via,vt8500-uart;
+   reg = 0xd820 0x1040;
+   interrupts = 32;
+   clocks = clkuart0;
+   };
-- 
1.7.9.5

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

[PATCH] vt8500: pinctrl: Change devicetree data parsing

[Tony Prisk]

Due to an assumption in the VT8500 pinctrl driver, the value passed
from devicetree for 'wm,pull' was not explicitly translated before
being passed to pinconf.

With changes to 'enum pin_config_param', PIN_CONFIG_BIAS_PULL_(UP/DOWN)
no longer map 1-to-1 with the expected values in devicetree.

This patch adds a small translation between the devicetree values (0..2)
and the enum pin_config_param equivalent values.

Signed-off-by: Tony Prisk li...@prisktech.co.nz
---
 drivers/pinctrl/vt8500/pinctrl-wmt.c |   11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/pinctrl/vt8500/pinctrl-wmt.c 
b/drivers/pinctrl/vt8500/pinctrl-wmt.c
index 39aec08..fa4fdbd 100644
--- a/drivers/pinctrl/vt8500/pinctrl-wmt.c
+++ b/drivers/pinctrl/vt8500/pinctrl-wmt.c
@@ -276,6 +276,17 @@ static int wmt_pctl_dt_node_to_map_pull(struct 
wmt_pinctrl_data *data,
if (!configs)
return -ENOMEM;
 
+   switch (pull) {
+   case 0:
+   pull = PIN_CONFIG_BIAS_DISABLE;
+   break;
+   case 1:
+   pull = PIN_CONFIG_BIAS_PULL_DOWN;
+   break;
+   case 2:
+   pull = PIN_CONFIG_BIAS_PULL_UP;
+   break;
+   }
configs[0] = pull;
 
map-type = PIN_MAP_TYPE_CONFIGS_PIN;
-- 
1.7.9.5

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

[PATCH] MAINTAINERS: vt8500: Update maintained files for arch/vt8500

[Tony Prisk]

Removed maintainership of the ehci-platform.c and uhci-platform.c
drivers. These drivers are not solely used by arch-vt8500 anymore,
and are captured under Alan Stern's 'USB EHCI DRIVER' and
'USB UHCI DRIVER' wildcards.

Add maintainership for the VT8500's clock, irq and pinctrl drivers
which were added/migrated quite some time ago.

Signed-off-by: Tony Prisk li...@prisktech.co.nz
---
 MAINTAINERS |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6a6e4ac..ac26897 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1341,14 +1341,15 @@ M:  Tony Prisk li...@prisktech.co.nz
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
 F: arch/arm/mach-vt8500/
+F: drivers/clk/clk-vt8500.c
 F: drivers/clocksource/vt8500_timer.c
 F: drivers/i2c/busses/i2c-wmt.c
+F: drivers/irqchip/irq-vt8500.c
 F: drivers/mmc/host/wmt-sdmmc.c
+F: drivers/pinctrl/vt8500/
 F: drivers/pwm/pwm-vt8500.c
 F: drivers/rtc/rtc-vt8500.c
 F: drivers/tty/serial/vt8500_serial.c
-F: drivers/usb/host/ehci-platform.c
-F: drivers/usb/host/uhci-platform.c
 F: drivers/video/vt8500lcdfb.*
 F: drivers/video/wm8505fb*
 F: drivers/video/wmt_ge_rops.*
-- 
1.7.9.5

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

Re: [PATCH 2/2] sched: add statistic for rq-max_idle_balance_cost

[Alex Shi]

On 01/23/2014 02:10 AM, Jason Low wrote:
   P64(avg_idle);
   +   P64(max_idle_balance_cost);
#endif
   P(ttwu_count);
  
  Not also the per-sd value in sd_alloc_ctl_domain_table() ?
 Yeah, tracking the sd-max_newidle_lb_cost can also be useful.
 
 

Thanks for suggestion!

I thought the sd-max_newidle_lb_cost keep changing. But yes, it's
still meaningful. 
BTW, in the pandaboard ES, sd balance cost is about 1~2ms.

---

From d37e712b623fb6776d0caba8e4bd06460e26b84e Mon Sep 17 00:00:00 2001
From: Alex Shi alex@linaro.org
Date: Tue, 21 Jan 2014 13:28:55 +0800
Subject: [PATCH] sched: add statistic for newidle load balance cost

Tracking rq-max_idle_balance_cost and sd-max_newidle_lb_cost
It's useful to track these values in debug mode.

Signed-off-by: Alex Shi alex@linaro.org
---
 kernel/sched/core.c  | 7 +--
 kernel/sched/debug.c | 1 +
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index c3f3824..a046bc3 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4293,7 +4293,7 @@ set_table_entry(struct ctl_table *entry,
 static struct ctl_table *
 sd_alloc_ctl_domain_table(struct sched_domain *sd)
 {
-   struct ctl_table *table = sd_alloc_ctl_entry(8);
+   struct ctl_table *table = sd_alloc_ctl_entry(9);
 
if (table == NULL)
return NULL;
@@ -4313,7 +4313,10 @@ sd_alloc_ctl_domain_table(struct sched_domain *sd)
sizeof(int), 0644, proc_dointvec_minmax);
set_table_entry(table[6], name, sd-name,
CORENAME_MAX_SIZE, 0444, proc_dostring);
-   /* table[7] is terminator */
+   set_table_entry(table[7], max_newidle_lb_cost,
+   sd-max_newidle_lb_cost,
+   sizeof(long), 0644, proc_doulongvec_minmax);
+   /* table[8] is terminator */
 
return table;
 }
diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index 1e43e70..9ecd861 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -315,6 +315,7 @@ do {
\
P(sched_goidle);
 #ifdef CONFIG_SMP
P64(avg_idle);
+   P64(max_idle_balance_cost);
 #endif
 
P(ttwu_count);
-- 
1.8.1.2

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

Re: [PATCH Resend 2/8] ASoC: simple-card: fix __asoc_simple_card_dai_init

[Jean-Francois Moine]

On Thu, 23 Jan 2014 13:02:44 +0800
Xiubo Li li.xi...@freescale.com wrote:

 If the CPU/CODEC DAI set_sysclk() is not support, the -ENOTSUPP will returnd.
 Here do the check like set_fmt().
 
 Signed-off-by: Xiubo Li li.xi...@freescale.com
 ---
 
 
 
 The VF610 Tower and VF610 LS1 platforms' ESAI and SPDIF will depend on this
 patch too.
 
 
 
 
  sound/soc/generic/simple-card.c | 17 +++--
  1 file changed, 11 insertions(+), 6 deletions(-)
 
 diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
 index 6443c87..3b8c9a2 100644
 --- a/sound/soc/generic/simple-card.c
 +++ b/sound/soc/generic/simple-card.c
 @@ -31,16 +31,21 @@ static int __asoc_simple_card_dai_init(struct snd_soc_dai 
 *dai,
  
   daifmt |= set-fmt;
  
 - if (daifmt)
 + if (daifmt) {
   ret = snd_soc_dai_set_fmt(dai, daifmt);
 -
 - if (ret == -ENOTSUPP) {
 - dev_dbg(dai-dev, ASoC: set_fmt is not supported\n);
 - ret = 0;
 + if (ret  ret != -ENOTSUPP) {
 + dev_err(dai-dev, simple-card: set_fmt error\n);
 + return ret;
 + }
   }
  
 - if (!ret  set-sysclk)
 + if (set-sysclk) {
   ret = snd_soc_dai_set_sysclk(dai, 0, set-sysclk, 0);
 + if (ret  ret != -ENOTSUPP) {
 + dev_err(dai-dev, simple-card: set_sysclk error\n);
 + return ret;
 + }
 + }
  
   return ret;

Sorry: you must return 0 here

  }

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

[PATCH 1/1] suspend: make sync() on suspend-to-RAM optional

[Len Brown]

From: Len Brown len.br...@intel.com

Linux suspend-to-RAM was unreliable when first developed,
and so sys_sync() was invoked inside the kernel at the
start of every suspend flow.

Today, many devices are invoking suspend with
high reliability and high frequency, and they don't
want to be forced to pay for sync on every suspend.

So here we make it optional.
De-select CONFIG_PM_SLEEP_SYNC to delete the call entirely.
or keep CONFIG_PM_SLEEP and you can now clear the
sys/power/sleep_sync attribte to disable the sync
from user-space.

As we have had this call for a long time,
the default remains to keep the call, and to
invoke it on every suspend.

Signed-off-by: Len Brown len.br...@intel.com
---
 kernel/power/Kconfig   |  8 
 kernel/power/main.c| 33 +
 kernel/power/power.h   |  1 +
 kernel/power/suspend.c | 10 +++---
 4 files changed, 49 insertions(+), 3 deletions(-)

diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 2fac9cc..d2927ce 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -102,6 +102,14 @@ config PM_SLEEP_SMP
depends on PM_SLEEP
select HOTPLUG_CPU
 
+config PM_SLEEP_SYNC
+   bool Suspend to RAM starts with in-kernel call to sync()
+   default y
+   depends on PM_SLEEP
+   ---help---
+   Build a call to sync() into the Linux kernel suspend to RAM flow.
+   The sync can still be skipped by clearing /sys/power/sleep_sync.
+
 config PM_AUTOSLEEP
bool Opportunistic sleep
depends on PM_SLEEP
diff --git a/kernel/power/main.c b/kernel/power/main.c
index 1d1bf63..1102871 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -71,6 +71,36 @@ static ssize_t pm_async_store(struct kobject *kobj, struct 
kobj_attribute *attr,
 
 power_attr(pm_async);
 
+#ifdef CONFIG_PM_SLEEP_SYNC
+
+/* If set, sync file systems at start of suspend flow */
+int pm_sleep_sync_enabled = 1;
+
+static ssize_t pm_sleep_sync_show(struct kobject *kobj, struct kobj_attribute 
*attr,
+char *buf)
+{
+   return sprintf(buf, %d\n, pm_sleep_sync_enabled);
+}
+
+static ssize_t pm_sleep_sync_store(struct kobject *kobj, struct kobj_attribute 
*attr,
+ const char *buf, size_t n)
+{
+   unsigned long val;
+
+   if (kstrtoul(buf, 10, val))
+   return -EINVAL;
+
+   if (val  1)
+   return -EINVAL;
+
+   pm_sleep_sync_enabled = val;
+   return n;
+}
+
+power_attr(pm_sleep_sync);
+
+#endif /* CONFIG_PM_SLEEP_SYNC */
+
 #ifdef CONFIG_PM_DEBUG
 int pm_test_level = TEST_NONE;
 
@@ -592,6 +622,9 @@ static struct attribute * g[] = {
 #ifdef CONFIG_PM_SLEEP
pm_async_attr.attr,
wakeup_count_attr.attr,
+#ifdef CONFIG_PM_SLEEP_SYNC
+   pm_sleep_sync_attr.attr,
+#endif
 #ifdef CONFIG_PM_AUTOSLEEP
autosleep_attr.attr,
 #endif
diff --git a/kernel/power/power.h b/kernel/power/power.h
index 7d4b7ff..dca60a7 100644
--- a/kernel/power/power.h
+++ b/kernel/power/power.h
@@ -200,6 +200,7 @@ static inline void suspend_test_finish(const char *label) {}
 #ifdef CONFIG_PM_SLEEP
 /* kernel/power/main.c */
 extern int pm_notifier_call_chain(unsigned long val);
+extern int pm_sleep_sync_enabled;
 #endif
 
 #ifdef CONFIG_HIGHMEM
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 62ee437..2fb2f51 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -333,9 +333,13 @@ static int enter_state(suspend_state_t state)
if (state == PM_SUSPEND_FREEZE)
freeze_begin();
 
-   printk(KERN_INFO PM: Syncing filesystems ... );
-   sys_sync();
-   printk(done.\n);
+#ifdef CONFIG_PM_SLEEP_SYNC
+   if (pm_sleep_sync_enabled) {
+   printk(KERN_INFO PM: Syncing filesystems ... );
+   sys_sync();
+   printk(done.\n);
+   }
+#endif /* CONFIG_PM_SLEEP_SYNC */
 
pr_debug(PM: Preparing system for %s sleep\n, pm_states[state]);
error = suspend_prepare(state);
-- 
1.8.3.2

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

Re: [PATCH v2 1/4] pinctrl: st: Add Interrupt support.

[Linus Walleij]

On Thu, Jan 16, 2014 at 4:36 PM,  srinivas.kandaga...@st.com wrote:

 From: Srinivas Kandagatla srinivas.kandaga...@st.com

 This patch add interrupt support to the pincontroller driver.

 ST Pincontroller GPIO bank can have one of the two possible types of
 interrupt-wirings.

 First type is via irqmux, single interrupt is used by multiple gpio
 banks. This reduces number of overall interrupts numbers required. All
 these banks belong to a single pincontroller.
   _
  | | [gpio-bank (n)]
  | | [gpio-bank (n + 1)]
 [irqN]-- | irq-mux | [gpio-bank (n + 2)]
  | | [gpio-bank (...  )]
  |_| [gpio-bank (n + 7)]

 Second type has a dedicated interrupt per gpio bank.

 [irqN] [gpio-bank (n)]

 Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com

I've applied this patch so that it won't just sit idle.
Besides you've done a real good job on it Srinivas.

It'll be for v3.15 though and I'm still waiting to see if
the device tree people say something about it.

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

RE: [PATCH Resend 2/8] ASoC: simple-card: fix __asoc_simple_card_dai_init

[li.xi...@freescale.com]

  diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-
 card.c
  index 6443c87..3b8c9a2 100644
  --- a/sound/soc/generic/simple-card.c
  +++ b/sound/soc/generic/simple-card.c
  @@ -31,16 +31,21 @@ static int __asoc_simple_card_dai_init(struct
 snd_soc_dai *dai,
 
  daifmt |= set-fmt;
 
  -   if (daifmt)
  +   if (daifmt) {
  ret = snd_soc_dai_set_fmt(dai, daifmt);
  -
  -   if (ret == -ENOTSUPP) {
  -   dev_dbg(dai-dev, ASoC: set_fmt is not supported\n);
  -   ret = 0;
  +   if (ret  ret != -ENOTSUPP) {
  +   dev_err(dai-dev, simple-card: set_fmt error\n);
  +   return ret;
  +   }
  }
 
  -   if (!ret  set-sysclk)
  +   if (set-sysclk) {
  ret = snd_soc_dai_set_sysclk(dai, 0, set-sysclk, 0);
  +   if (ret  ret != -ENOTSUPP) {
  +   dev_err(dai-dev, simple-card: set_sysclk error\n);
  +   return ret;
  +   }
  +   }
 
  return ret;
 
 Sorry: you must return 0 here
 

Yes, the ret maybe -ENOTSUPP.

I will revise it.

Thanks,

Best Regards,
Xiubo

Re: [Bug 67651] Bisected: Lots of fragmented mmaps cause gimp to fail in 3.12 after exceeding vm_max_map_count

[Mel Gorman]

On Wed, Jan 22, 2014 at 11:52:15AM -0800, Andrew Morton wrote:
 On Wed, 22 Jan 2014 19:08:16 + Mel Gorman mgor...@suse.de wrote:
 
  X-related junk is there was because I was using a headless server and
  xinit directly to launch gimp to reproduce the bug.
 
 I've never done this.  Can you share the magic recipe for running an X
 app in this way?
 

The relevant part of the test script is

# Build a wrapper script to launch gimp
cat  gimp-launch.sh  EOF
/usr/bin/gimp -i -b (mmtests-open-image \$FILENAME\) -b (gimp-quit 0)  
$LOGDIR_RESULTS/gimp-out.1 21
echo \$?  gimp-exit-code
EOF
chmod u+x gimp-launch.sh

$TIME_CMD xinit ./gimp-launch.sh 2 $LOGDIR_RESULTS/time.1
RETVAL=`cat gimp-exit-code`

It's clumsy because the application would start with no window manager
and looking at it again, it probably was not even necessary because of
the -i switch in gimp.

Previously when I needed to automate an X app I configured the machine to
login automatically, exported the DISPLAY variable in the test script and
used wmctrl to detect if an application had a window displayed yet.

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

Re: [PATCH 1/1] suspend: make sync() on suspend-to-RAM optional

[Zhang Rui]

On Thu, 2014-01-23 at 02:11 -0500, Len Brown wrote:
 From: Len Brown len.br...@intel.com
 
 Linux suspend-to-RAM was unreliable when first developed,
 and so sys_sync() was invoked inside the kernel at the
 start of every suspend flow.
 
 Today, many devices are invoking suspend with
 high reliability and high frequency, and they don't
 want to be forced to pay for sync on every suspend.
 
 So here we make it optional.
 De-select CONFIG_PM_SLEEP_SYNC to delete the call entirely.
 or keep CONFIG_PM_SLEEP and you can now clear the
 sys/power/sleep_sync attribte to disable the sync
 from user-space.
 
 As we have had this call for a long time,
 the default remains to keep the call, and to
 invoke it on every suspend.
 
 Signed-off-by: Len Brown len.br...@intel.com
 ---
  kernel/power/Kconfig   |  8 
  kernel/power/main.c| 33 +
  kernel/power/power.h   |  1 +
  kernel/power/suspend.c | 10 +++---
  4 files changed, 49 insertions(+), 3 deletions(-)
 
 diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
 index 2fac9cc..d2927ce 100644
 --- a/kernel/power/Kconfig
 +++ b/kernel/power/Kconfig
 @@ -102,6 +102,14 @@ config PM_SLEEP_SMP
   depends on PM_SLEEP
   select HOTPLUG_CPU
  
 +config PM_SLEEP_SYNC
 + bool Suspend to RAM starts with in-kernel call to sync()
 + default y
 + depends on PM_SLEEP

this is actually a suspend specific feature, and it should depends on
SUSPEND instead?

thanks,
rui
 + ---help---
 + Build a call to sync() into the Linux kernel suspend to RAM flow.
 + The sync can still be skipped by clearing /sys/power/sleep_sync.
 +
  config PM_AUTOSLEEP
   bool Opportunistic sleep
   depends on PM_SLEEP
 diff --git a/kernel/power/main.c b/kernel/power/main.c
 index 1d1bf63..1102871 100644
 --- a/kernel/power/main.c
 +++ b/kernel/power/main.c
 @@ -71,6 +71,36 @@ static ssize_t pm_async_store(struct kobject *kobj, struct 
 kobj_attribute *attr,
  
  power_attr(pm_async);
  
 +#ifdef CONFIG_PM_SLEEP_SYNC
 +
 +/* If set, sync file systems at start of suspend flow */
 +int pm_sleep_sync_enabled = 1;
 +
 +static ssize_t pm_sleep_sync_show(struct kobject *kobj, struct 
 kobj_attribute *attr,
 +  char *buf)
 +{
 + return sprintf(buf, %d\n, pm_sleep_sync_enabled);
 +}
 +
 +static ssize_t pm_sleep_sync_store(struct kobject *kobj, struct 
 kobj_attribute *attr,
 +   const char *buf, size_t n)
 +{
 + unsigned long val;
 +
 + if (kstrtoul(buf, 10, val))
 + return -EINVAL;
 +
 + if (val  1)
 + return -EINVAL;
 +
 + pm_sleep_sync_enabled = val;
 + return n;
 +}
 +
 +power_attr(pm_sleep_sync);
 +
 +#endif /* CONFIG_PM_SLEEP_SYNC */
 +
  #ifdef CONFIG_PM_DEBUG
  int pm_test_level = TEST_NONE;
  
 @@ -592,6 +622,9 @@ static struct attribute * g[] = {
  #ifdef CONFIG_PM_SLEEP
   pm_async_attr.attr,
   wakeup_count_attr.attr,
 +#ifdef CONFIG_PM_SLEEP_SYNC
 + pm_sleep_sync_attr.attr,
 +#endif
  #ifdef CONFIG_PM_AUTOSLEEP
   autosleep_attr.attr,
  #endif
 diff --git a/kernel/power/power.h b/kernel/power/power.h
 index 7d4b7ff..dca60a7 100644
 --- a/kernel/power/power.h
 +++ b/kernel/power/power.h
 @@ -200,6 +200,7 @@ static inline void suspend_test_finish(const char *label) 
 {}
  #ifdef CONFIG_PM_SLEEP
  /* kernel/power/main.c */
  extern int pm_notifier_call_chain(unsigned long val);
 +extern int pm_sleep_sync_enabled;
  #endif
  
  #ifdef CONFIG_HIGHMEM
 diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
 index 62ee437..2fb2f51 100644
 --- a/kernel/power/suspend.c
 +++ b/kernel/power/suspend.c
 @@ -333,9 +333,13 @@ static int enter_state(suspend_state_t state)
   if (state == PM_SUSPEND_FREEZE)
   freeze_begin();
  
 - printk(KERN_INFO PM: Syncing filesystems ... );
 - sys_sync();
 - printk(done.\n);
 +#ifdef CONFIG_PM_SLEEP_SYNC
 + if (pm_sleep_sync_enabled) {
 + printk(KERN_INFO PM: Syncing filesystems ... );
 + sys_sync();
 + printk(done.\n);
 + }
 +#endif /* CONFIG_PM_SLEEP_SYNC */
  
   pr_debug(PM: Preparing system for %s sleep\n, pm_states[state]);
   error = suspend_prepare(state);


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

Re: [PATCH v2 2/4] pinctrl: st: Add software edge trigger interrupt support.

[Linus Walleij]

On Thu, Jan 16, 2014 at 4:37 PM,  srinivas.kandaga...@st.com wrote:

 ST pin controller does not have hardware support for detecting edge
 triggered interrupts, It only has level triggering support.
 This patch attempts to fake up edge triggers from hw level trigger
 support in software.

(...)


 +/*
 + * Edge triggers are not supported at hardware level, it is supported by
 + * software by exploiting the level trigger support in hardware.
 + * Software uses a virtual register (EDGE_CONF) for edge trigger 
 configuration
 + * of each gpio pin in a GPIO bank.

(...)

 +/*
 + * As edge triggers are not supported at hardware level, it is supported by
 + * software by exploiting the level trigger support in hardware.

(...)

All this is quite hard to understand. Maybe it's just because
it's hard overall. Edge triggers are not supported by hardware
so we use the hardware edge trigger support?

That is a bit oxymoronic...

 + * Steps for detection raising edge interrupt in software.
 + *
 + * Step 1: CONFIGURE pin to detect level LOW interrupts.
 + *
 + * Step 2: DETECT level LOW interrupt and in irqmux/gpio bank interrupt 
 handler,
 + * if the value of pin is low, then CONFIGURE pin for level HIGH interrupt.
 + * IGNORE calling the actual interrupt handler for the pin at this stage.
 + *
 + * Step 3: DETECT level HIGH interrupt and in irqmux/gpio-bank interrupt 
 handler
 + * if the value of pin is HIGH, CONFIGURE pin for level LOW interrupt and 
 then
 + * DISPATCH the interrupt to the interrupt handler of the pin.

But I do understand this, that's VERY clever and may be something
that can be exploited on other hardware as well some day.

So patch applied.

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

Re: [PATCH v2 3/4] ARM:STi: STiH416: Add interrupt support for pin controller

[Linus Walleij]

On Thu, Jan 16, 2014 at 4:37 PM,  srinivas.kandaga...@st.com wrote:

 From: Srinivas Kandagatla srinivas.kandaga...@st.com

 This patch adds interrupt support for STiH416 pin controllers.

 Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com

Acked-by: Linus Walleij linus.wall...@linaro.org

Please merge this through the ARM SoC tree with the rest of
your device tree stuff.

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

How to identify different ip tunnels

[zhuyj]

Hi, Maintainers

We want to identify different ip tunnels.

For example, we use “ip tunnel add xxx” command in linux to create an 
ipv4/6 tunnel interface,then,we can receive a RTM_NEWLINK message from 
linux for the new tunnel interface.
We will parse the struct ifinfomsg message and get the ifi-ifi_type 
attribute. We need to do somethings depend on the tunnel type here.

I checked the linux source code and list all the tunnel types here:

#define ARPHRD_TUNNEL 768 /* IPIP tunnel */
#define ARPHRD_TUNNEL6 769 /* IP6IP6 tunnel */
#define ARPHRD_SIT 776 /* sit0 device - IPv6-in-IPv4 */
#define ARPHRD_IPGRE 778 /* GRE over IP */

It means that the linux will report the new link for any ipv4/6 tunnel 
interface with type only within these four types. However, We need more 
tunnel types for ipv4/6 tunnel.
For example, 4IN4/6IN4/6TO4/GRE/ISATAP for ipv4 tunnel and 
4IN6/6IN6/IPIN6 for ipv6 tunnel.


Here are the result that we have got:

Actual Tunnel type ifi-ifi_type
4IN4 768
GRE4 778
6IN4/6TO4/ISATAP 776
4IN6/6IN6/IPIN6 769

So, we can NOT distinguish the actual tunnel type via ifi_type attribute 
except the GRE4 and 4IN4 tunnel. However we need the actual type. That 
is our question.


BTW, for the 6IN4 and 6TO4 tunnel, Can we distinguish them before the 
interface ip address configured? Because we need to do different things 
for them when we received the new link message and the tunnel has NOT 
any ip address in this time.


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

Re: [PATCH v2 4/4] ARM:STi: STiH415: Add interrupt support for pin controller

[Linus Walleij]

On Thu, Jan 16, 2014 at 4:37 PM,  srinivas.kandaga...@st.com wrote:

 From: Srinivas Kandagatla srinivas.kandaga...@st.com

 This patch adds interrupt support for STiH415 pin controllers.

 Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com

Acked-by: Linus Walleij linus.wall...@linaro.org

Merge this through ARM SoC.

 +   reg = 0xfe61f080 0x4;
 +   reg-names   = irqmux;

Aha so that is how it looks when you handle the separate
mux reg, well I can't think of anything better and this works
fine for me.

The alternative would be to have a syscon thing using regmap
such as drivers/mfd/syscon.c but I really cannot decide
between these two design patterns for odd registers.

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

Re: [PATCH v2] gpio: intel-mid: comments cleanup

[Linus Walleij]

On Fri, Jan 17, 2014 at 4:30 PM, David Cohen
david.a.co...@linux.intel.com wrote:

 This is a simple cleanup on gpio-intel-mid.c's header comments.

 Signed-off-by: David Cohen david.a.co...@linux.intel.com

Applied, but I changed it like this:

 - * Copyright (c) 2008, 2009, 2013, Intel Corporation.
 + * Copyright (c) 2014 Intel Corporation.

To- Copyright (c) 2008-2014

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

Re: [PATCH v2 2/2] regulator: s5m8767: Document new bindings for Buck9 GPIO control

[Krzysztof Kozlowski]

On Wed, 2014-01-22 at 19:49 +, Mark Brown wrote:
 On Wed, Jan 22, 2014 at 05:07:28PM +0100, Krzysztof Kozlowski wrote:
  Add documentation for new bindings for controlling (enable/disable) the
  Buck9 Converter by GPIO (BUCK9EN).
 
 Your CC list for this is *very* large...
Hmmm... The get_maintainers produces such long list for any change in
Documentation/devicetree/bindings... I'll stop using it for this.

 
  +   - s5m8767,pmic-ext-control-enable: regulator can be enabled/disabled
  +   by GPIO (valid only for buck9).
  +   - s5m8767,pmic-ext-control-gpio: GPIO specifier for one GPIO
  +   controlling this regulator (valid only for buck9).
  +   This property is required when 
  's5m8767,pmic-ext-control-enable' is specified.
 
 In what situation might the GPIO be present but not usable - can't we
 just use the presence of the GPIO property?  Also GPIO properties are
 supposed to be always -gpios.
Remove the s5m8767,pmic-ext-control-enable and use only
s5m8767,pmic-ext-control-gpios? Sure, that makes sense. Thanks for
idea.


Best regards,
Krzysztof

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

Re: [PATCH 1/1] iMX gpio: Allow reading back of pin status if configured as gpio output

[Linus Walleij]

On Fri, Jan 17, 2014 at 11:27 PM, Waibel Georg
georg.wai...@sensor-technik.de wrote:

 Seems there is no need for my patch at all.

I'm holding this off until you've made up your mind about
whether it's needed or not...

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

Re: [PATCHv2 2/2] pwm: imx: support polarity inversion

[Lothar Waßmann]

Hi,

Sascha Hauer wrote:
 On Thu, Jan 16, 2014 at 09:06:25AM +0100, Lothar Waßmann wrote:
  The i.MX PWM controller supports inverting the polarity of the PWM
  output. Make this feature available in the pxm-imx driver.
  
  Signed-off-by: Lothar Waßmann l...@karo-electronics.de
  ---
   Documentation/devicetree/bindings/pwm/imx-pwm.txt |5 +-
   drivers/pwm/pwm-imx.c |   42 
  +
   2 files changed, 45 insertions(+), 2 deletions(-)
  
  diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt 
  b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
  index b50d7a6d..d0b04b5 100644
  --- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
  +++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
  @@ -3,8 +3,9 @@ Freescale i.MX PWM controller
   Required properties:
   - compatible: should be fsl,soc-pwm
   - reg: physical base address and length of the controller's registers
  -- #pwm-cells: should be 2. See pwm.txt in this directory for a description 
  of
  -  the cells format.
  +- #pwm-cells: may be 2 for backwards compatibility or 3 to support
  +  switching the output polarity. See pwm.txt in this directory for a
  +  description of the cells format.
   - interrupts: The interrupt for the pwm controller
   
   Example:
  diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
  index 3b00a82..05461bb 100644
  --- a/drivers/pwm/pwm-imx.c
  +++ b/drivers/pwm/pwm-imx.c
  @@ -36,6 +36,7 @@
   #define MX3_PWMCR_DOZEEN   (1  24)
   #define MX3_PWMCR_WAITEN   (1  23)
   #define MX3_PWMCR_DBGEN(1  22)
  +#define MX3_PWMCR_POUTC(1  18)
   #define MX3_PWMCR_CLKSRC_IPG_HIGH  (2  16)
   #define MX3_PWMCR_CLKSRC_IPG   (1  16)
   #define MX3_PWMCR_EN   (1  0)
  @@ -138,6 +139,9 @@ static int imx_pwm_config_v2(struct pwm_chip *chip,
  if (test_bit(PWMF_ENABLED, pwm-flags))
  cr |= MX3_PWMCR_EN;
   
  +   if (pwm-polarity == PWM_POLARITY_INVERSED)
  +   cr |= MX3_PWMCR_POUTC;
  +
  writel(cr, imx-mmio_base + MX3_PWMCR);
   
  return 0;
  @@ -155,6 +159,11 @@ static void imx_pwm_set_enable_v2(struct pwm_chip 
  *chip, bool enable)
  else
  val = ~MX3_PWMCR_EN;
   
  +   if (chip-pwms[0].polarity == PWM_POLARITY_INVERSED)
  +   val |= MX3_PWMCR_POUTC;
  +   else
  +   val = ~MX3_PWMCR_POUTC;
  +
  writel(val, imx-mmio_base + MX3_PWMCR);
   }
   
  @@ -198,6 +207,17 @@ static void imx_pwm_disable(struct pwm_chip *chip, 
  struct pwm_device *pwm)
  clk_disable_unprepare(imx-clk_per);
   }
   
  +static int imx_pwm_set_polarity(struct pwm_chip *chip, struct pwm_device 
  *pwm,
  +   enum pwm_polarity polarity)
  +{
  +   struct imx_chip *imx = to_imx_chip(chip);
  +
  +   dev_dbg(imx-chip.dev, %s: polarity set to %s\n, __func__,
  +   polarity == PWM_POLARITY_INVERSED ? inverted : normal);
  +
  +   return 0;
  +}
  +
   static struct pwm_ops imx_pwm_ops = {
  .enable = imx_pwm_enable,
  .disable = imx_pwm_disable,
  @@ -209,6 +229,7 @@ struct imx_pwm_data {
  int (*config)(struct pwm_chip *chip,
  struct pwm_device *pwm, int duty_ns, int period_ns);
  void (*set_enable)(struct pwm_chip *chip, bool enable);
  +   unsigned output_polarity:1;
   };
   
   static struct imx_pwm_data imx_pwm_data_v1 = {
  @@ -219,6 +240,7 @@ static struct imx_pwm_data imx_pwm_data_v1 = {
   static struct imx_pwm_data imx_pwm_data_v2 = {
  .config = imx_pwm_config_v2,
  .set_enable = imx_pwm_set_enable_v2,
  +   .output_polarity = 1,
   };
   
   static const struct of_device_id imx_pwm_dt_ids[] = {
  @@ -271,6 +293,26 @@ static int imx_pwm_probe(struct platform_device *pdev)
  return PTR_ERR(imx-mmio_base);
   
  data = of_id-data;
  +   if (data-output_polarity) {
  +   const struct device_node *np = pdev-dev.of_node;
  +   u32 num_cells;
  +
  +   dev_dbg(pdev-dev, PWM supports output inversion\n);
  +   ret = of_property_read_u32(np, #pwm-cells, num_cells);
  +   if (ret  0) {
  +   dev_err(pdev-dev, missing property '#pwm-cells'\n);
  +   return ret;
  +   }
  +   if (num_cells == 3) {
  +   imx_pwm_ops.set_polarity = imx_pwm_set_polarity;
  +   imx-chip.of_xlate = of_pwm_xlate_with_flags;
  +   } else if (num_cells != 2) {
  +   dev_err(pdev-dev, '#pwm-cells' must be 2 or 
  3\n);
  +   return -EINVAL;
  +   }
  +   imx-chip.of_pwm_n_cells = num_cells;
  +   }
 
 Can't this be done in the PWM core? Right now the PWM core checks for
 of_pwm_n_cells before calling -of_xlate. IMO this check should be done
 in the of_xlate hook. Then of_pwm_simple_xlate and
 of_pwm_xlate_with_flags can be merged into something like:
 
This wouldn't buy much without a material change to 

Re: [PATCH 3/5] ARM: firmware: enable Trusted Foundations by default

[Alexandre Courbot]

On Thu, Jan 23, 2014 at 5:42 AM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 01/21/2014 03:10 AM, Alexandre Courbot wrote:
 As discussed previously (https://lkml.org/lkml/2013/11/26/289), enable
 Trusted Foundation support by default since it already depends on a
 supporting architecture being selected.

 Doing so allows us to remove it from tegra_defconfig.

  arch/arm/configs/tegra_defconfig | 1 -
  arch/arm/firmware/Kconfig| 1 +

 Can we split out the defconfig and code changes into separate patches?
 They need to go through seperate branches, possibly even separate repos.

 The defconfig change might not even be necessary; at some point I'll
 just rebuild it via make tegra_defconfig; make savedefconfig on top of
 some linux-next that includes the Kconfig change, and it'll happen
 automatically. Still, I guess there's no harm explicitly sending the patch.

If we can do without the defconfig change then I will just omit it in
the next version - I don't like sending too many oneliners. :P
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/5] ARM: trusted_foundations: implement do_idle()

[Alexandre Courbot]

On Thu, Jan 23, 2014 at 5:43 AM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 01/21/2014 03:10 AM, Alexandre Courbot wrote:
 Support the do_idle() firmware call, which is necessary to properly
 support cpuidle.

 diff --git a/arch/arm/firmware/trusted_foundations.c 
 b/arch/arm/firmware/trusted_foundations.c

 +#define TF_CPU_PM 0xfffc
 +#define TF_CPU_PM_LP0 0xffe3
 +#define TF_CPU_PM_LP1 0xffe6
 +#define TF_CPU_PM_LP1_NO_MC_CLK   0xffe5
 +#define TF_CPU_PM_LP2 0xffe4
 +#define TF_CPU_PM_LP2_NOFLUSH_L2 0xffe7

 Hmm. This must be Tegra-specific, not generic to any TF client, since
 aren't the names of the suspend states (LP0, LP1, LP2) entirely specific
 to Tegra?

The names are negligence on my part, actually. I arbitrarily named
them that way without thinking this was Tegra-only denomination. The
downstream kernel does not even use these, they hardcode the values
directly. Will fix that, thanks for spotting it.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pinctrl: at91: use locked variant of irq_set_handler

[Linus Walleij]

On Tue, Jan 21, 2014 at 4:55 PM, Nicolas Ferre nicolas.fe...@atmel.com wrote:

 When setting the gpio irq type, use the __irq_set_handler_locked()
 variant instead of the irq_set_handler() to prevent false
 spinlock recursion warning.

 Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
 Cc: stable sta...@vger.kernel.org # v3.12

Patch applied for fixes.

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

Re: [PATCH 5/5] ARM: tegra: cpuidle: use firmware call for power down

[Alexandre Courbot]

On Thu, Jan 23, 2014 at 5:45 AM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 01/21/2014 03:10 AM, Alexandre Courbot wrote:
 Invoke the do_idle() firmware call before suspending a CPU so that the
 underlying firmware (if any) can take necessary action.

 diff --git a/arch/arm/mach-tegra/cpuidle-tegra114.c 
 b/arch/arm/mach-tegra/cpuidle-tegra114.c

 @@ -45,6 +46,8 @@ static int tegra114_idle_power_down(struct cpuidle_device 
 *dev,

   clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, dev-cpu);

 + call_firmware_op(do_idle);
 +
   cpu_suspend(0, tegra30_sleep_cpu_secondary_finish);

   clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, dev-cpu);

 Don't you need to have the kernel also *not* do something when entering
 idle; doesn't the FW op replace some of the register writes that the
 kernel would otherwise be doing?

It seems like the operation is actually to inform the firmware that we
are going to suspend the CPU. Downstream kernel also uses it that way.
But you are right in that we should expect do_idle() to actually
perform the suspend operation. Maybe a prepare_idle() operation should
be added to the firmware interface for this purpose?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 1/1] suspend: make sync() on suspend-to-RAM optional

[Brown, Len]

  +   depends on PM_SLEEP

 this is actually a suspend specific feature, and it should depends on
 SUSPEND instead?

yup, will update.

thanks,
-Len

Re: [PATCH 1/1] suspend: make sync() on suspend-to-RAM optional

[Srivatsa S. Bhat]

On 01/23/2014 12:41 PM, Len Brown wrote:
 From: Len Brown len.br...@intel.com
 
 Linux suspend-to-RAM was unreliable when first developed,
 and so sys_sync() was invoked inside the kernel at the
 start of every suspend flow.
 
 Today, many devices are invoking suspend with
 high reliability and high frequency, and they don't
 want to be forced to pay for sync on every suspend.
 
 So here we make it optional.
 De-select CONFIG_PM_SLEEP_SYNC to delete the call entirely.
 or keep CONFIG_PM_SLEEP and you can now clear the
 sys/power/sleep_sync attribte to disable the sync
 from user-space.
 
 As we have had this call for a long time,
 the default remains to keep the call, and to
 invoke it on every suspend.
 
 Signed-off-by: Len Brown len.br...@intel.com
 ---
  kernel/power/Kconfig   |  8 
  kernel/power/main.c| 33 +
  kernel/power/power.h   |  1 +
  kernel/power/suspend.c | 10 +++---
  4 files changed, 49 insertions(+), 3 deletions(-)
 
 diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
 index 2fac9cc..d2927ce 100644
 --- a/kernel/power/Kconfig
 +++ b/kernel/power/Kconfig
 @@ -102,6 +102,14 @@ config PM_SLEEP_SMP
   depends on PM_SLEEP
   select HOTPLUG_CPU
 
 +config PM_SLEEP_SYNC

How about naming it as PM_SLEEP_FS_SYNC (and similarly in the sysfs files
and variable names as well). Just to avoid confusion with synchronous/async.

Regards,
Srivatsa S. Bhat

 + bool Suspend to RAM starts with in-kernel call to sync()
 + default y
 + depends on PM_SLEEP
 + ---help---
 + Build a call to sync() into the Linux kernel suspend to RAM flow.
 + The sync can still be skipped by clearing /sys/power/sleep_sync.
 +
  config PM_AUTOSLEEP
   bool Opportunistic sleep
   depends on PM_SLEEP
 diff --git a/kernel/power/main.c b/kernel/power/main.c
 index 1d1bf63..1102871 100644
 --- a/kernel/power/main.c
 +++ b/kernel/power/main.c
 @@ -71,6 +71,36 @@ static ssize_t pm_async_store(struct kobject *kobj, struct 
 kobj_attribute *attr,
 
  power_attr(pm_async);
 
 +#ifdef CONFIG_PM_SLEEP_SYNC
 +
 +/* If set, sync file systems at start of suspend flow */
 +int pm_sleep_sync_enabled = 1;
 +
 +static ssize_t pm_sleep_sync_show(struct kobject *kobj, struct 
 kobj_attribute *attr,
 +  char *buf)
 +{
 + return sprintf(buf, %d\n, pm_sleep_sync_enabled);
 +}
 +
 +static ssize_t pm_sleep_sync_store(struct kobject *kobj, struct 
 kobj_attribute *attr,
 +   const char *buf, size_t n)
 +{
 + unsigned long val;
 +
 + if (kstrtoul(buf, 10, val))
 + return -EINVAL;
 +
 + if (val  1)
 + return -EINVAL;
 +
 + pm_sleep_sync_enabled = val;
 + return n;
 +}
 +
 +power_attr(pm_sleep_sync);
 +
 +#endif /* CONFIG_PM_SLEEP_SYNC */
 +
  #ifdef CONFIG_PM_DEBUG
  int pm_test_level = TEST_NONE;
 
 @@ -592,6 +622,9 @@ static struct attribute * g[] = {
  #ifdef CONFIG_PM_SLEEP
   pm_async_attr.attr,
   wakeup_count_attr.attr,
 +#ifdef CONFIG_PM_SLEEP_SYNC
 + pm_sleep_sync_attr.attr,
 +#endif
  #ifdef CONFIG_PM_AUTOSLEEP
   autosleep_attr.attr,
  #endif
 diff --git a/kernel/power/power.h b/kernel/power/power.h
 index 7d4b7ff..dca60a7 100644
 --- a/kernel/power/power.h
 +++ b/kernel/power/power.h
 @@ -200,6 +200,7 @@ static inline void suspend_test_finish(const char *label) 
 {}
  #ifdef CONFIG_PM_SLEEP
  /* kernel/power/main.c */
  extern int pm_notifier_call_chain(unsigned long val);
 +extern int pm_sleep_sync_enabled;
  #endif
 
  #ifdef CONFIG_HIGHMEM
 diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
 index 62ee437..2fb2f51 100644
 --- a/kernel/power/suspend.c
 +++ b/kernel/power/suspend.c
 @@ -333,9 +333,13 @@ static int enter_state(suspend_state_t state)
   if (state == PM_SUSPEND_FREEZE)
   freeze_begin();
 
 - printk(KERN_INFO PM: Syncing filesystems ... );
 - sys_sync();
 - printk(done.\n);
 +#ifdef CONFIG_PM_SLEEP_SYNC
 + if (pm_sleep_sync_enabled) {
 + printk(KERN_INFO PM: Syncing filesystems ... );
 + sys_sync();
 + printk(done.\n);
 + }
 +#endif /* CONFIG_PM_SLEEP_SYNC */
 
   pr_debug(PM: Preparing system for %s sleep\n, pm_states[state]);
   error = suspend_prepare(state);
 


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

Re: [PATCH 2/2] Add at24 based EEPROMs to the eeprom_dev hardware class

[Laszlo Papp]

On Wed, Jan 22, 2014 at 5:23 PM, Curt Brune c...@cumulusnetworks.com wrote:
 During device instantiation have the at24 driver add the new device to
 the eeprom_dev hardware class.  The functionality is enabled by
 CONFIG_EEPROM_CLASS.

 Signed-off-by: Curt Brune c...@cumulusnetworks.com
 ---
  drivers/misc/eeprom/at24.c |   20 
  1 file changed, 20 insertions(+)

 diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
 index d87f77f..07782ea 100644
 --- a/drivers/misc/eeprom/at24.c
 +++ b/drivers/misc/eeprom/at24.c
 @@ -1,170 +1,177 @@
  /*
   * at24.c - handle most I2C EEPROMs
   *
   * Copyright (C) 2005-2007 David Brownell
   * Copyright (C) 2008 Wolfram Sang, Pengutronix
   *
   * This program is free software; you can redistribute it and/or modify
   * it under the terms of the GNU General Public License as published by
   * the Free Software Foundation; either version 2 of the License, or
   * (at your option) any later version.
   */
  #include linux/kernel.h
  #include linux/init.h
  #include linux/module.h
  #include linux/slab.h
  #include linux/delay.h
  #include linux/mutex.h
  #include linux/sysfs.h
  #include linux/mod_devicetable.h
  #include linux/log2.h
  #include linux/bitops.h
  #include linux/jiffies.h
  #include linux/of.h
  #include linux/i2c.h
  #include linux/platform_data/at24.h

 +#ifdef CONFIG_EEPROM_CLASS
 +#include linux/eeprom_class.h
 +#endif
 +
  /*
   * I2C EEPROMs from most vendors are inexpensive and mostly interchangeable.
   * Differences between different vendor product lines (like Atmel AT24C or
   * MicroChip 24LC, etc) won't much matter for typical read/write access.
   * There are also I2C RAM chips, likewise interchangeable. One example
   * would be the PCF8570, which acts like a 24c02 EEPROM (256 bytes).
   *
   * However, misconfiguration can lose data. Set 16-bit memory address
   * to a part with 8-bit addressing will overwrite data. Writing with too
   * big a page size also loses data. And it's not safe to assume that the
   * conventional addresses 0x50..0x57 only hold eeproms; a PCF8563 RTC
   * uses 0x51, for just one example.
   *
   * Accordingly, explicit board-specific configuration data should be used
   * in almost all cases. (One partial exception is an SMBus used to access
   * SPD data for DRAM sticks. Those only use 24c02 EEPROMs.)
   *
   * So this driver uses new style I2C driver binding, expecting to be
   * told what devices exist. That may be in arch/X/mach-Y/board-Z.c or
   * similar kernel-resident tables; or, configuration data coming from
   * a bootloader.
   *
   * Other than binding model, current differences from eeprom driver are
   * that this one handles write access and isn't restricted to 24c02 devices.
   * It also handles larger devices (32 kbit and up) with two-byte addresses,
   * which won't work on pure SMBus systems.
   */

  struct at24_data {
 struct at24_platform_data chip;
 struct memory_accessor macc;
 int use_smbus;

 /*
  * Lock protects against activities from other Linux tasks,
  * but not from changes by other I2C masters.
  */
 struct mutex lock;
 struct bin_attribute bin;

 u8 *writebuf;
 unsigned write_max;
 unsigned num_addresses;

 +#ifdef CONFIG_EEPROM_CLASS
 +   struct device *eeprom_dev;
 +#endif
 /*
  * Some chips tie up multiple I2C addresses; dummy devices reserve
  * them for us, and we'll use them with SMBus calls.
  */
 struct i2c_client *client[];
  };

  /*
   * This parameter is to help this driver avoid blocking other drivers out
   * of I2C for potentially troublesome amounts of time. With a 100 kHz I2C
   * clock, one 256 byte read takes about 1/43 second which is excessive;
   * but the 1/170 second it takes at 400 kHz may be quite reasonable; and
   * at 1 MHz (Fm+) a 1/430 second delay could easily be invisible.
   *
   * This value is forced to be a power of two so that writes align on pages.
   */
  static unsigned io_limit = 128;
  module_param(io_limit, uint, 0);
  MODULE_PARM_DESC(io_limit, Maximum bytes per I/O (default 128));

  /*
   * Specs often allow 5 msec for a page write, sometimes 20 msec;
   * it's important to recover from write timeouts.
   */
  static unsigned write_timeout = 25;
  module_param(write_timeout, uint, 0);
  MODULE_PARM_DESC(write_timeout, Time (in ms) to try writes (default 25));

  #define AT24_SIZE_BYTELEN 5
  #define AT24_SIZE_FLAGS 8

  #define AT24_BITMASK(x) (BIT(x) - 1)

  /* create non-zero magic value for given eeprom parameters */
  #define AT24_DEVICE_MAGIC(_len, _flags)\
 ((1  AT24_SIZE_FLAGS | (_flags))  \
  AT24_SIZE_BYTELEN | ilog2(_len))

  static const struct i2c_device_id at24_ids[] = {
 /* needs 8 addresses as A0-A2 are ignored */
 { 24c00, AT24_DEVICE_MAGIC(128 / 8, AT24_FLAG_TAKE8ADDR) },
 /* 

Re: [PATCH v5 00/22] Rewrite XIP code and add XIP support to ext4

[Dave Chinner]

On Wed, Jan 15, 2014 at 08:24:18PM -0500, Matthew Wilcox wrote:
 This series of patches add support for XIP to ext4.  Unfortunately,
 it turns out to be necessary to rewrite the existing XIP support code
 first due to races that are unfixable in the current design.
 
 Since v4 of this patchset, I've improved the documentation, fixed a
 couple of warnings that a newer version of gcc emitted, and fixed a
 bug where we would read/write the wrong address for I/Os that were not
 aligned to PAGE_SIZE.
 
 I've dropped the PMD fault patch from this set since there are some
 places where we would need to split a PMD page and there's no way to do
 that right now.  In its place, I've added a patch which attempts to add
 support for unwritten extents.  I'm still in two minds about this; on the
 one hand, it's clearly a win for reads and writes.  On the other hand,
 it adds a lot of complexity, and it probably isn't a win for pagefaults.

FYI, this may just be pure coincidence, but shortly after the first
boot of a machine with this patchset on 3.13 the root *ext3*
filesystem started having problems.  It now gives persistent ENOSPC
errors when there's 2.3GB of space free (on a 8GB partition), even
though e2fsck says the filesystem is clean and error free.

Fmeh.

Update: I've just removed the patchset, rebuilt the kernel and the
ENOSPC problem is still there. So it may be co-incidence, but given
that it is persistent something is screwed got screwed up in the
filesytem.

Cheers,

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

[PATCH v2] suspend: make sync() on suspend-to-RAM optional

[Len Brown]

From: Len Brown len.br...@intel.com

Linux suspend-to-RAM was unreliable when first developed,
and so sys_sync() was invoked inside the kernel at the
start of every suspend flow.

Today, many devices are invoking suspend with
high reliability and high frequency, and they don't
want to be forced to pay for sync on every suspend.

So here we make it optional.
De-select CONFIG_PM_SUSPEND_SYNC to delete the call entirely.
or keep CONFIG_PM_SUSPEND_SYNC and you can now clear the
sys/power/suspend_sync attribte to disable the sync
from user-space.

As we have had this call for a long time,
the default remains to keep the call, and to
invoke it on every suspend.

Signed-off-by: Len Brown len.br...@intel.com
---
 kernel/power/Kconfig   |  8 
 kernel/power/main.c| 33 +
 kernel/power/power.h   |  1 +
 kernel/power/suspend.c | 10 +++---
 4 files changed, 49 insertions(+), 3 deletions(-)

diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 2fac9cc..61c7bd1 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -102,6 +102,14 @@ config PM_SLEEP_SMP
depends on PM_SLEEP
select HOTPLUG_CPU
 
+config SUSPEND_SYNC
+   bool Suspend to RAM starts with in-kernel call to sync()
+   default y
+   depends on SUSPEND
+   ---help---
+   Build a call to sync() into the Linux kernel suspend to RAM flow.
+   The sync can still be skipped by clearing /sys/power/suspend_sync.
+
 config PM_AUTOSLEEP
bool Opportunistic sleep
depends on PM_SLEEP
diff --git a/kernel/power/main.c b/kernel/power/main.c
index 1d1bf63..bd7eeeb 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -71,6 +71,36 @@ static ssize_t pm_async_store(struct kobject *kobj, struct 
kobj_attribute *attr,
 
 power_attr(pm_async);
 
+#ifdef CONFIG_SUSPEND_SYNC
+
+/* If set, sync file systems at start of suspend flow */
+int suspend_sync_enabled = 1;
+
+static ssize_t suspend_sync_show(struct kobject *kobj, struct kobj_attribute 
*attr,
+char *buf)
+{
+   return sprintf(buf, %d\n, suspend_sync_enabled);
+}
+
+static ssize_t suspend_sync_store(struct kobject *kobj, struct kobj_attribute 
*attr,
+ const char *buf, size_t n)
+{
+   unsigned long val;
+
+   if (kstrtoul(buf, 10, val))
+   return -EINVAL;
+
+   if (val  1)
+   return -EINVAL;
+
+   suspend_sync_enabled = val;
+   return n;
+}
+
+power_attr(suspend_sync);
+
+#endif /* CONFIG_SUSPEND_SYNC */
+
 #ifdef CONFIG_PM_DEBUG
 int pm_test_level = TEST_NONE;
 
@@ -592,6 +622,9 @@ static struct attribute * g[] = {
 #ifdef CONFIG_PM_SLEEP
pm_async_attr.attr,
wakeup_count_attr.attr,
+#ifdef CONFIG_PM_SLEEP_SYNC
+   suspend_sync_attr.attr,
+#endif
 #ifdef CONFIG_PM_AUTOSLEEP
autosleep_attr.attr,
 #endif
diff --git a/kernel/power/power.h b/kernel/power/power.h
index 7d4b7ff..7dd66ff 100644
--- a/kernel/power/power.h
+++ b/kernel/power/power.h
@@ -200,6 +200,7 @@ static inline void suspend_test_finish(const char *label) {}
 #ifdef CONFIG_PM_SLEEP
 /* kernel/power/main.c */
 extern int pm_notifier_call_chain(unsigned long val);
+extern int suspend_sync_enabled;
 #endif
 
 #ifdef CONFIG_HIGHMEM
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 62ee437..5155cb9 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -333,9 +333,13 @@ static int enter_state(suspend_state_t state)
if (state == PM_SUSPEND_FREEZE)
freeze_begin();
 
-   printk(KERN_INFO PM: Syncing filesystems ... );
-   sys_sync();
-   printk(done.\n);
+#ifdef CONFIG_SUSPEND_SYNC
+   if (suspend_sync_enabled) {
+   printk(KERN_INFO PM: Syncing filesystems ... );
+   sys_sync();
+   printk(done.\n);
+   }
+#endif /* CONFIG_SUSPEND_SYNC */
 
pr_debug(PM: Preparing system for %s sleep\n, pm_states[state]);
error = suspend_prepare(state);
-- 
1.8.3.2

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

Re: [PATCH v5 00/22] Rewrite XIP code and add XIP support to ext4

[Dave Chinner]

On Thu, Jan 23, 2014 at 06:48:25PM +1100, Dave Chinner wrote:
 On Wed, Jan 15, 2014 at 08:24:18PM -0500, Matthew Wilcox wrote:
  This series of patches add support for XIP to ext4.  Unfortunately,
  it turns out to be necessary to rewrite the existing XIP support code
  first due to races that are unfixable in the current design.
  
  Since v4 of this patchset, I've improved the documentation, fixed a
  couple of warnings that a newer version of gcc emitted, and fixed a
  bug where we would read/write the wrong address for I/Os that were not
  aligned to PAGE_SIZE.
  
  I've dropped the PMD fault patch from this set since there are some
  places where we would need to split a PMD page and there's no way to do
  that right now.  In its place, I've added a patch which attempts to add
  support for unwritten extents.  I'm still in two minds about this; on the
  one hand, it's clearly a win for reads and writes.  On the other hand,
  it adds a lot of complexity, and it probably isn't a win for pagefaults.
 
 FYI, this may just be pure coincidence, but shortly after the first
 boot of a machine with this patchset on 3.13 the root *ext3*
 filesystem started having problems.  It now gives persistent ENOSPC
 errors when there's 2.3GB of space free (on a 8GB partition), even
 though e2fsck says the filesystem is clean and error free.
 
 Fmeh.
 
 Update: I've just removed the patchset, rebuilt the kernel and the
 ENOSPC problem is still there. So it may be co-incidence, but given
 that it is persistent something is screwed got screwed up in the
 filesytem.

OK, false alarm - it is co-incidence. The damn root filesystem ran
out of inodes. Can you beleive that you're only allowed 600k inodes
in an 8GB filesystems? Sheesh! :)

Cheers,

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

RE: [PATCH 1/1] suspend: make sync() on suspend-to-RAM optional

[Brown, Len]

 How about naming it as PM_SLEEP_FS_SYNC (and similarly in the sysfs
 files
 and variable names as well). Just to avoid confusion with
 synchronous/async.


good point -- thanks!


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

Re: [PATCH v4 2/2] usb: dwc3: adapt dwc3 core to use Generic PHY Framework

[Roger Quadros]

On 01/22/2014 08:04 AM, Vivek Gautam wrote:
> Hi,
> 
> 
> On Tue, Jan 21, 2014 at 7:30 PM, Roger Quadros  wrote:
>> Hi Kishon,
>>
>> On 01/21/2014 12:11 PM, Kishon Vijay Abraham I wrote:
>>> Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
>>> power_on and power_off the following APIs are used phy_init(), phy_exit(),
>>> phy_power_on() and phy_power_off().
>>>
>>> However using the old USB phy library wont be removed till the PHYs of all
>>> other SoC's using dwc3 core is adapted to the Generic PHY Framework.
>>>
>>> Signed-off-by: Kishon Vijay Abraham I 
>>> ---
>>> Changes from v3:
>>> * avoided using quirks
>>>
>>>  Documentation/devicetree/bindings/usb/dwc3.txt |6 ++-
>>>  drivers/usb/dwc3/core.c|   60 
>>> 
>>>  drivers/usb/dwc3/core.h|7 +++
>>>  3 files changed, 71 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
>>> b/Documentation/devicetree/bindings/usb/dwc3.txt
>>> index e807635..471366d 100644
>>> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
>>> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
>>> @@ -6,11 +6,13 @@ Required properties:
>>>   - compatible: must be "snps,dwc3"
>>>   - reg : Address and length of the register set for the device
>>>   - interrupts: Interrupts used by the dwc3 controller.
>>> +
>>> +Optional properties:
>>>   - usb-phy : array of phandle for the PHY device.  The first element
>>> in the array is expected to be a handle to the USB2/HS PHY and
>>> the second element is expected to be a handle to the USB3/SS PHY
>>> -
>>> -Optional properties:
>>> + - phys: from the *Generic PHY* bindings
>>> + - phy-names: from the *Generic PHY* bindings
>>>   - tx-fifo-resize: determines if the FIFO *has* to be reallocated.
>>>
>>>  This is usually a subnode to DWC3 glue to which it is connected.
>>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>>> index e009d4e..036d589 100644
>>> --- a/drivers/usb/dwc3/core.c
>>> +++ b/drivers/usb/dwc3/core.c
>>> @@ -82,6 +82,11 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
>>>
>>>   usb_phy_init(dwc->usb2_phy);
>>>   usb_phy_init(dwc->usb3_phy);
>>> + if (dwc->usb2_generic_phy)
>>> + phy_init(dwc->usb2_generic_phy);
>>
>> What if phy_init() fails? You need to report and fail. Same applies for all 
>> PHY apis in this patch.
>>
>>> + if (dwc->usb3_generic_phy)
>>> + phy_init(dwc->usb3_generic_phy);
>>> +
>>>   mdelay(100);
>>>
>>>   /* Clear USB3 PHY reset */
>>> @@ -343,6 +348,11 @@ static void dwc3_core_exit(struct dwc3 *dwc)
>>>  {
>>>   usb_phy_shutdown(dwc->usb2_phy);
>>>   usb_phy_shutdown(dwc->usb3_phy);
>>> + if (dwc->usb2_generic_phy)
>>> + phy_exit(dwc->usb2_generic_phy);
>>> + if (dwc->usb3_generic_phy)
>>> + phy_exit(dwc->usb3_generic_phy);
>>> +
>>>  }
>>>
>>>  #define DWC3_ALIGN_MASK  (16 - 1)
>>> @@ -433,6 +443,32 @@ static int dwc3_probe(struct platform_device *pdev)
>>>   }
>>>   }
>>>
>>> + dwc->usb2_generic_phy = devm_phy_get(dev, "usb2-phy");
>>> + if (IS_ERR(dwc->usb2_generic_phy)) {
>>> + ret = PTR_ERR(dwc->usb2_generic_phy);
>>> + if (ret == -ENOSYS || ret == -ENODEV) {
>>> + dwc->usb2_generic_phy = NULL;
>>> + } else if (ret == -EPROBE_DEFER) {
>>> + return ret;
>>> + } else {
>>> + dev_err(dev, "no usb2 phy configured\n");
>>> + return ret;
>>> + }
>>> + }
>>> +
>>> + dwc->usb3_generic_phy = devm_phy_get(dev, "usb3-phy");
>>> + if (IS_ERR(dwc->usb3_generic_phy)) {
>>> + ret = PTR_ERR(dwc->usb3_generic_phy);
>>> + if (ret == -ENOSYS || ret == -ENODEV) {
>>> + dwc->usb3_generic_phy = NULL;
>>> + } else if (ret == -EPROBE_DEFER) {
>>> + return ret;
>>> + } else {
>>> + dev_err(dev, "no usb3 phy configured\n");
>>> + return ret;
>>> + }
>>> + }
>>> +
>>>   dwc->xhci_resources[0].start = res->start;
>>>   dwc->xhci_resources[0].end = dwc->xhci_resources[0].start +
>>>   DWC3_XHCI_REGS_END;
>>> @@ -482,6 +518,11 @@ static int dwc3_probe(struct platform_device *pdev)
>>>   usb_phy_set_suspend(dwc->usb2_phy, 0);
>>>   usb_phy_set_suspend(dwc->usb3_phy, 0);
>>>
>>> + if (dwc->usb2_generic_phy)
>>> + phy_power_on(dwc->usb2_generic_phy);
>>> + if (dwc->usb3_generic_phy)
>>> + phy_power_on(dwc->usb3_generic_phy);
>>> +
>>
>> Is it OK to power on the phy before phy_init()?
> 
> Isn't phy_init() being done before phy_power_on() in the
> core_soft_reset() in this patch ?
> Isn't that what you want here ?
> 
>>
>> I suggest to move phy_init() from 

Re: [PATCH v2 0/4] Intel MPX support

[David Rientjes]

On Wed, 22 Jan 2014, Qiaowei Ren wrote:

> Changes since v1:
>   * check to see if #BR occurred in userspace or kernel space.
>   * use generic structure and macro as much as possible when
> decode mpx instructions.
> 
> Qiaowei Ren (4):
>   x86, mpx: add documentation on Intel MPX
>   x86, mpx: hook #BR exception handler to allocate bound tables
>   x86, mpx: add prctl commands PR_MPX_INIT, PR_MPX_RELEASE
>   x86, mpx: extend siginfo structure to include bound violation
> information
> 
>  Documentation/x86/intel_mpx.txt|   76 +++
>  arch/x86/Kconfig   |4 +
>  arch/x86/include/asm/mpx.h |   63 ++
>  arch/x86/include/asm/processor.h   |   16 ++
>  arch/x86/kernel/Makefile   |1 +
>  arch/x86/kernel/mpx.c  |  417 
> 
>  arch/x86/kernel/traps.c|   61 +-
>  include/uapi/asm-generic/siginfo.h |9 +-
>  include/uapi/linux/prctl.h |6 +
>  kernel/signal.c|4 +
>  kernel/sys.c   |   12 +
>  11 files changed, 667 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/x86/intel_mpx.txt
>  create mode 100644 arch/x86/include/asm/mpx.h
>  create mode 100644 arch/x86/kernel/mpx.c
> 

There's compiler warnings spread amongst the various patches with x86_64 
defconfig:

arch/x86/kernel/mpx.c: In function ‘do_mpx_bounds’:
arch/x86/kernel/mpx.c:415:2: warning: format ‘%lx’ expects argument of type 
‘long unsigned int’, but argument 3 has type ‘void *’ [-Wformat]
arch/x86/kernel/mpx.c:415:2: warning: format ‘%lx’ expects argument of type 
‘long unsigned int’, but argument 4 has type ‘void *’ [-Wformat]
arch/x86/kernel/mpx.c: In function ‘do_mpx_bt_fault’:
arch/x86/kernel/mpx.c:373:5: warning: ‘old_val’ may be used uninitialized in 
this function [-Wuninitialized]
arch/x86/kernel/mpx.c:360:25: note: ‘old_val’ was declared here

and I had to resolve the second patch manually because of "x86/traps: 
Clean up error exception handler definitions" in the x86 tree.

With 32-bit, we get casting warnings:

arch/x86/kernel/mpx.c: In function ‘do_mpx_bounds’:
arch/x86/kernel/mpx.c:407:3: warning: cast to pointer from integer of different 
size [-Wint-to-pointer-cast]
arch/x86/kernel/mpx.c:409:3: warning: cast to pointer from integer of different 
size [-Wint-to-pointer-cast]

and I'm pretty sure you want this to be available for such a config.

There's also whitespace in the fourth patch.

Re: [PATCH v2] mm/zswap: Check all pool pages instead of one pool pages

[Minchan Kim]

Hello Cai,

On Tue, Jan 21, 2014 at 09:52:25PM +0800, Cai Liu wrote:
> Hello Minchan
> 
> 2014/1/21 Minchan Kim :
> > Hello,
> >
> > On Tue, Jan 21, 2014 at 02:35:07PM +0800, Cai Liu wrote:
> >> 2014/1/21 Minchan Kim :
> >> > Please check your MUA and don't break thread.
> >> >
> >> > On Tue, Jan 21, 2014 at 11:07:42AM +0800, Cai Liu wrote:
> >> >> Thanks for your review.
> >> >>
> >> >> 2014/1/21 Minchan Kim :
> >> >> > Hello Cai,
> >> >> >
> >> >> > On Mon, Jan 20, 2014 at 03:50:18PM +0800, Cai Liu wrote:
> >> >> >> zswap can support multiple swapfiles. So we need to check
> >> >> >> all zbud pool pages in zswap.
> >> >> >>
> >> >> >> Version 2:
> >> >> >>   * add *total_zbud_pages* in zbud to record all the pages in pools
> >> >> >>   * move the updating of pool pages statistics to
> >> >> >> alloc_zbud_page/free_zbud_page to hide the details
> >> >> >>
> >> >> >> Signed-off-by: Cai Liu 
> >> >> >> ---
> >> >> >>  include/linux/zbud.h |2 +-
> >> >> >>  mm/zbud.c|   44 
> >> >> >> 
> >> >> >>  mm/zswap.c   |4 ++--
> >> >> >>  3 files changed, 35 insertions(+), 15 deletions(-)
> >> >> >>
> >> >> >> diff --git a/include/linux/zbud.h b/include/linux/zbud.h
> >> >> >> index 2571a5c..1dbc13e 100644
> >> >> >> --- a/include/linux/zbud.h
> >> >> >> +++ b/include/linux/zbud.h
> >> >> >> @@ -17,6 +17,6 @@ void zbud_free(struct zbud_pool *pool, unsigned 
> >> >> >> long handle);
> >> >> >>  int zbud_reclaim_page(struct zbud_pool *pool, unsigned int retries);
> >> >> >>  void *zbud_map(struct zbud_pool *pool, unsigned long handle);
> >> >> >>  void zbud_unmap(struct zbud_pool *pool, unsigned long handle);
> >> >> >> -u64 zbud_get_pool_size(struct zbud_pool *pool);
> >> >> >> +u64 zbud_get_pool_size(void);
> >> >> >>
> >> >> >>  #endif /* _ZBUD_H_ */
> >> >> >> diff --git a/mm/zbud.c b/mm/zbud.c
> >> >> >> index 9451361..711aaf4 100644
> >> >> >> --- a/mm/zbud.c
> >> >> >> +++ b/mm/zbud.c
> >> >> >> @@ -52,6 +52,13 @@
> >> >> >>  #include 
> >> >> >>  #include 
> >> >> >>
> >> >> >> +/*
> >> >> >> +* statistics
> >> >> >> +**/
> >> >> >> +
> >> >> >> +/* zbud pages in all pools */
> >> >> >> +static u64 total_zbud_pages;
> >> >> >> +
> >> >> >>  /*
> >> >> >>   * Structures
> >> >> >>  */
> >> >> >> @@ -142,10 +149,28 @@ static struct zbud_header 
> >> >> >> *init_zbud_page(struct page *page)
> >> >> >>   return zhdr;
> >> >> >>  }
> >> >> >>
> >> >> >> +static struct page *alloc_zbud_page(struct zbud_pool *pool, gfp_t 
> >> >> >> gfp)
> >> >> >> +{
> >> >> >> + struct page *page;
> >> >> >> +
> >> >> >> + page = alloc_page(gfp);
> >> >> >> +
> >> >> >> + if (page) {
> >> >> >> + pool->pages_nr++;
> >> >> >> + total_zbud_pages++;
> >> >> >
> >> >> > Who protect race?
> >> >>
> >> >> Yes, here the pool->pages_nr and also the total_zbud_pages are not 
> >> >> protected.
> >> >> I will re-do it.
> >> >>
> >> >> I will change *total_zbud_pages* to atomic type.
> >> >
> >> > Wait, it doesn't make sense. Now, you assume zbud allocator would be used
> >> > for only zswap. It's true until now but we couldn't make sure it in 
> >> > future.
> >> > If other user start to use zbud allocator, total_zbud_pages would be 
> >> > pointless.
> >>
> >> Yes, you are right.  ZBUD is a common module. So in this patch calculate 
> >> the
> >> zswap pool size in zbud is not suitable.
> >>
> >> >
> >> > Another concern is that what's your scenario for above two swap?
> >> > How often we need to call zbud_get_pool_size?
> >> > In previous your patch, you reduced the number of call so IIRC,
> >> > we only called it in zswap_is_full and for debugfs.
> >>
> >> zbud_get_pool_size() is called frequently when adding/freeing zswap
> >> entry happen in zswap . This is why in this patch I added a counter in 
> >> zbud,
> >> and then in zswap the iteration of zswap_list to calculate the pool size 
> >> will
> >> not be needed.
> >
> > We can remove updating zswap_pool_pages in zswap_frontswap_store and
> > zswap_free_entry as I said. So zswap_is_full is only hot spot.
> > Do you think it's still big overhead? Why? Maybe locking to prevent
> > destroying? Then, we can use RCU to minimize the overhead as I mentioned.
> 
> I get your point. Yes, In my previous patch, zswap_is_full() was the
> only path to call
> zbud_get_pool_size(). And your suggestion on patch v1 to remove the 
> unnecessary
> iteration will reduce the overhead further.
> 
> So adding the calculating of all the pool size in zswap.c is better.
> 
> >>
> >> > Of course, it would need some lock or refcount to prevent destroy
> >> > of zswap_tree in parallel with zswap_frontswap_invalidate_area but
> >> > zswap_is_full doesn't need to be exact so RCU would be good fit.
> >> >
> >> > Most important point is that now zswap doesn't consider multiple swap.
> >> > For example, Let's 

Re: [PATCH v9 3/5] qrwlock, x86 - Treat all data type not bigger than long as atomic in x86

[Peter Zijlstra]

On Tue, Jan 21, 2014 at 04:31:56PM -0800, Linus Torvalds wrote:
> And if somebody tries to do a "smp_store_release()" on a random
> structure or union, do we care? We're not some nanny state that wants
> to give nice warnings for insane code.

Hurm, and here I thought warning on insane code was a good idea :/

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

Re: [PATCH] Documentation: devicetree: mct: Fix counter bit of CPU local timers

[Jingoo Han]

On Tuesday, January 21, 2014 6:03 PM, Jingoo Han wrote:
> 
> According to the datasheet of Exynos SoCs, the counter bit
> of CPU local timers is 31-bit, not 32-bit; thus, it should
> be fixed.

Please, ignore this patch.
There is a 31-bit counter in CPU local timers; however,
FRC (free running down-counters) of CPU local timers is
32-bit. Thus, there is no need to fix it.
Thank you.

Best regards,
Jingoo Han

> 
> Signed-off-by: Jingoo Han 
> ---
>  Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
> b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
> index 167d5da..8c77791 100644
> --- a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
> +++ b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
> @@ -3,7 +3,7 @@ Samsung's Multi Core Timer (MCT)
>  The Samsung's Multi Core Timer (MCT) module includes two main blocks, the
>  global timer and CPU local timers. The global timer is a 64-bit free running
>  up-counter and can generate 4 interrupts when the counter reaches one of the
> -four preset counter values. The CPU local timers are 32-bit free running
> +four preset counter values. The CPU local timers are 31-bit free running
>  down-counters and generate an interrupt when the counter expires. There is
>  one CPU local timer instantiated in MCT for every CPU in the system.
> 
> --
> 1.7.10.4


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

Re: [PATCH v5 0/4] ata: ahci_platform: Add PHY support and OMAP support

[Roger Quadros]

Hi,

On 01/21/2014 03:59 PM, Hans de Goede wrote:
> Hi,
> 
> On 01/21/2014 12:59 PM, Roger Quadros wrote:
>> On 01/21/2014 10:34 AM, Roger Quadros wrote:
>>> On 01/20/2014 06:48 PM, Hans de Goede wrote:
 Hi,

 On 01/20/2014 03:41 PM, Roger Quadros wrote:
> Hi,
>
> Some platforms have a PHY hooked up to the SATA controller.
> The PHY needs to be initialized and powered up for SATA to work.
> We do that using the Generic PHY framework in PATCH 3.
>
> In order to support SATA on the OMAP platforms we need to runtime
> resume the device before use. PATCH 4 takes care of that.

 Thanks for keeping me in the loop on this. I'm afraid this conflicts
 quite a bit with my recent ahci_platform.c work, not a big problem
 really, the series can go in either way.

 Your phy support will slot nicely into the new ahci_platform_get_resources
 and ahci_platform_enable_resources functions my refactoring introduces,
 looking at it from this pov it might be better / easier to rebase your 
 series
 on top of the v4 of my series I've just send.

 Which brings me to one comment about your series why are you not doing 
 phy_exit
 and phy_init on suspend resp. resume ? The phy can use quite a bit of 
 power,
 if the phy init / exit end up in ahci_platform_enable_resources /
 ahci_platform_disable_resources, this will happen automatically for better 
 or
 worse. So it would be good to test if this would work or not ...
>>>
>>> Right. Bartlomiej had pointed this out earlier, but I just wasn't very sure 
>>> about it.
>>>
>>> Is it sufficient to just call phy_power_off() in suspend and phy_power_on() 
>>> in resume?
>>> Or do we call phy_exit() and phy_init() respectively as well.
>>>
>>> Kishon, any suggestions?
>>
>> OK. Answering my own question.
>>
>> On OMAP platform we power down the phy in phy_power_off() and idle the DPLL 
>> in phy_exit(),
>> so my guess is both should be called in suspend() to save the most power.
> 
> Right, this would also match nicely with putting both the phy_init and the 
> phy_power_on call
> in ahci_platform_enable_resources in ahci_platform.c as it looks after v4 of 
> my ahci_platform
> rework patch-set, see:
> https://github.com/jwrdegoede/linux-sunxi/blob/sunxi-devel/drivers/ata/ahci_platform.c
> 
> If this goes there it will be automatically called on both probe and resume 
> (and the counterparts
> should go to ahci_platform_disable_resources, which will be called on suspend 
> and remove).
> 
> As said before I don't really have a preference for in which order these 
> patches go upstream,
> but can you please check that calling phy_poweroff + phy_exit on suspend and 
> undo on resume
> does not cause issues ?  If it does I need to rethink how things will work 
> after my refactoring,
> because currently all the clks / optional regulator and now also optional phy 
> get en/disabled in
> one go through ahci_platform_en/disable_resources.

I too don't have any preference of the upstream path. Maybe i'll repost this 
series based on your v4 an then you can include them in your series if you 
like. BTW why is your series still RFC at v4?

As far as OMAP platform is concerned, calling phy_power_off() + phy_exit() 
shouldn't be a problem for suspend.
Not sure about other platforms as we can't really know for sure what they do in 
phy_exit().

If phy_power_on/off() and phy_init()/phy_exit() are always meant to be called 
together then what is the point of having 2 functions each for power up/down.

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

Re: [PATCH -mm 2/2] memcg: fix css reference leak and endless loop in mem_cgroup_iter

[Michal Hocko]

On Tue 21-01-14 11:42:19, Andrew Morton wrote:
> On Tue, 21 Jan 2014 11:45:43 +0100 Michal Hocko  wrote:
> 
> > 19f39402864e (memcg: simplify mem_cgroup_iter) has reorganized
> > mem_cgroup_iter code in order to simplify it. A part of that change was
> > dropping an optimization which didn't call css_tryget on the root of
> > the walked tree. The patch however didn't change the css_put part in
> > mem_cgroup_iter which excludes root.
> > This wasn't an issue at the time because __mem_cgroup_iter_next bailed
> > out for root early without taking a reference as cgroup iterators
> > (css_next_descendant_pre) didn't visit root themselves.
> > 
> > Nevertheless cgroup iterators have been reworked to visit root by
> > bd8815a6d802 (cgroup: make css_for_each_descendant() and friends include
> > the origin css in the iteration) when the root bypass have been dropped
> > in __mem_cgroup_iter_next. This means that css_put is not called for
> > root and so css along with mem_cgroup and other cgroup internal object
> > tied by css lifetime are never freed.
> > 
> > Fix the issue by reintroducing root check in __mem_cgroup_iter_next
> > and do not take css reference for it.
> > 
> > This reference counting magic protects us also from another issue, an
> > endless loop reported by Hugh Dickins when reclaim races with root
> > removal and css_tryget called by iterator internally would fail. There
> > would be no other nodes to visit so __mem_cgroup_iter_next would return
> > NULL and mem_cgroup_iter would interpret it as "start looping from root
> > again" and so mem_cgroup_iter would loop forever internally.
> 
> I grabbed these two patches but I will sit on them for a week or so,
> pending review-n-test.

Yes, there is no rush and this needs a proper review.

> > Cc: sta...@vger.kernel.org # mem_leak part 3.12+
> 
> What does this mean?

Dohh. I had both patches in one but then I decided to split it. This is
just left over. Should be 3.12+.

Sorry about the confusion.

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

Re: [GIT PULL] GPIO bulk changes for v3.14

[Geert Uytterhoeven]

On Wed, Jan 22, 2014 at 8:54 AM, Linus Walleij  wrote:
>> The fact that it doesn't even compile makes me doubt your statement
>> that it has been in linux-next. It doesn't even pass a basic
>> allmodconfig build.
>
> Hm I rely on the zeroday build, and didn't get any angry compile errors.
> I'll double-check with Fengguang to see what's going on here and
> that branches get proper buildtesting.

There may be some delay. Sometimes it's a few hours, but last week I got an
email about a build failure I had in one of my branches since at least v3.9.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] sched: add statistic for rq->max_idle_balance_cost

[Alex Shi]

On 01/21/2014 03:43 PM, Jason Low wrote:
> On Mon, Jan 20, 2014 at 9:33 PM, Alex Shi  wrote:
>> It's useful to track this value in debug mode.
>>
>> Signed-off-by: Alex Shi 
>> ---
>>  kernel/sched/debug.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
>> index 1e43e70..f5c529a 100644
>> --- a/kernel/sched/debug.c
>> +++ b/kernel/sched/debug.c
>> @@ -315,6 +315,7 @@ do { 
>>\
>> P(sched_goidle);
>>  #ifdef CONFIG_SMP
>> P64(avg_idle);
>> +   p64(max_idle_balance_cost);
> 
> Hi Alex,
> 
> Does this need to be P64(max_idle_balance_cost)?
> 

Ops, this letter lay in my Drafts box.

Yes, thanks for fix!

===

>From 173417f3646ac1c6ac83809b51d0471591cbc8f0 Mon Sep 17 00:00:00 2001
From: Alex Shi 
Date: Tue, 21 Jan 2014 13:28:55 +0800
Subject: [RFC PATCH] sched: add statistic for rq->max_idle_balance_cost

It's useful to track this value in debug mode.

Signed-off-by: Alex Shi 
---
 kernel/sched/debug.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index 1e43e70..f5c529a 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -315,6 +315,7 @@ do {
\
P(sched_goidle);
 #ifdef CONFIG_SMP
P64(avg_idle);
+   P64(max_idle_balance_cost);
 #endif
P(ttwu_count);
-- 
1.8.1.2



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

Re: [PATCH 18/20] clocksource / acpi: Add macro CLOCKSOURCE_ACPI_DECLARE

[Linus Walleij]

On Fri, Jan 17, 2014 at 1:25 PM, Hanjun Guo  wrote:

> From: Amit Daniel Kachhap 
>
> This macro does the same job as CLOCKSOURCE_OF_DECLARE. The device
> name from the ACPI timer table is matched with all the registered
> timer controllers and matching initialisation routine is invoked.
>
> Signed-off-by: Amit Daniel Kachhap 
> Signed-off-by: Hanjun Guo 

Actually I have a fat patch renaming CLOCKSOURCE_OF_DECLARE()
to TIMER_OF_DECLARE() and I think this macro, if needed, should
be named TIMER_ACPI_DECLARE().

The reason is that "clocksource" is a Linux-internal name and this
macro pertains to the hardware name in respective system
description type.

> +#ifdef CONFIG_ACPI
> +#define CLOCKSOURCE_ACPI_DECLARE(name, compat, fn) \
> +   static const struct acpi_device_id __clksrc_acpi_table_##name   \
> +   __used __section(__clksrc_acpi_table)   \
> += { .id = compat,  \
> +.driver_data = (kernel_ulong_t)fn }
> +#else
> +#define CLOCKSOURCE_ACPI_DECLARE(name, compat, fn)
> +#endif

This hammers down the world to compile one binary for ACPI
and one binary for device tree. Maybe that's fine, I don't know.

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

Re: [PATCH -mm 2/2] memcg: fix css reference leak and endless loop in mem_cgroup_iter

[Michal Hocko]

On Tue 21-01-14 13:18:42, Hugh Dickins wrote:
[...]
> We do have a confusing situation.  The hang goes back to 3.10 but takes
> two different forms, because of intervening changes: in 3.10 and 3.11
> mem_cgroup_iter repeatedly returns root memcg to its caller, in 3.12 and
> 3.13 mem_cgroup_iter repeatedly gets NULL memcg from mem_cgroup_iter_next
> and cannot return to its caller.
> 
> Patch 1/2 is what's needed to fix 3.10 and 3.11 (and applies correctly
> to 3.11, but will have to be rediffed for 3.10 because of rearrangement
> in between). 

I will backport it when it reaches stable queue.

> Patch 2/2 is what's needed to fix 3.12 and 3.13 (but applies
> correctly to neither of them because it's diffed on top of my CSS_ONLINE
> fix).  Patch 1/2 is correct but unnecessary in 3.12 and 3.13: I'm unclear
> whether Michal is claiming that it would also fix the hang in 3.12 and
> 3.13 if we didn't have 2/2: I doubt that, and haven't tested that.

Actually both patches are needed. If we had only 2/2 then we wouldn't
endless loop inside mem_cgroup_iter but we could still return root to
caller all the time because mem_cgroup_iter_load would return NULL on
css_tryget failure on the cached root. Or am I missing something that
would prevent that?

> Given how Michal has diffed this patch on top of my CSS_ONLINE one
> (mm-memcg-iteration-skip-memcgs-not-yet-fully-initialized.patch),
> it would be helpful if you could mark that one also for stable 3.12+,
> to save us from having to rediff this one for stable.  We don't have
> a concrete example of a problem it solves in the vanilla kernel, but
> it makes more sense to include it than to exclude it.

Yes, I think it makes sense to queue it for 3.12+ as well because it is
non intrusive and potential issues would be really subtle.

> (You would be right to point out that the CSS_ONLINE one fixes
> something that goes back to 3.10: I'm saying 3.12+ because I'm not
> motivated to rediff it for 3.10 and 3.11 when there's nothing to
> go on top; but that's not a very good reason to lie - overrule me.)
> 
> Hugh

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

Re: [PATCH v5 0/4] ata: ahci_platform: Add PHY support and OMAP support

[Hans de Goede]

Hi,

On 01/22/2014 09:11 AM, Roger Quadros wrote:

Hi,

On 01/21/2014 03:59 PM, Hans de Goede wrote:

Hi,

On 01/21/2014 12:59 PM, Roger Quadros wrote:

On 01/21/2014 10:34 AM, Roger Quadros wrote:

On 01/20/2014 06:48 PM, Hans de Goede wrote:

Hi,

On 01/20/2014 03:41 PM, Roger Quadros wrote:

Hi,

Some platforms have a PHY hooked up to the SATA controller.
The PHY needs to be initialized and powered up for SATA to work.
We do that using the Generic PHY framework in PATCH 3.

In order to support SATA on the OMAP platforms we need to runtime
resume the device before use. PATCH 4 takes care of that.


Thanks for keeping me in the loop on this. I'm afraid this conflicts
quite a bit with my recent ahci_platform.c work, not a big problem
really, the series can go in either way.

Your phy support will slot nicely into the new ahci_platform_get_resources
and ahci_platform_enable_resources functions my refactoring introduces,
looking at it from this pov it might be better / easier to rebase your series
on top of the v4 of my series I've just send.

Which brings me to one comment about your series why are you not doing phy_exit
and phy_init on suspend resp. resume ? The phy can use quite a bit of power,
if the phy init / exit end up in ahci_platform_enable_resources /
ahci_platform_disable_resources, this will happen automatically for better or
worse. So it would be good to test if this would work or not ...


Right. Bartlomiej had pointed this out earlier, but I just wasn't very sure 
about it.

Is it sufficient to just call phy_power_off() in suspend and phy_power_on() in 
resume?
Or do we call phy_exit() and phy_init() respectively as well.

Kishon, any suggestions?


OK. Answering my own question.

On OMAP platform we power down the phy in phy_power_off() and idle the DPLL in 
phy_exit(),
so my guess is both should be called in suspend() to save the most power.


Right, this would also match nicely with putting both the phy_init and the 
phy_power_on call
in ahci_platform_enable_resources in ahci_platform.c as it looks after v4 of my 
ahci_platform
rework patch-set, see:
https://github.com/jwrdegoede/linux-sunxi/blob/sunxi-devel/drivers/ata/ahci_platform.c

If this goes there it will be automatically called on both probe and resume 
(and the counterparts
should go to ahci_platform_disable_resources, which will be called on suspend 
and remove).

As said before I don't really have a preference for in which order these 
patches go upstream,
but can you please check that calling phy_poweroff + phy_exit on suspend and 
undo on resume
does not cause issues ?  If it does I need to rethink how things will work 
after my refactoring,
because currently all the clks / optional regulator and now also optional phy 
get en/disabled in
one go through ahci_platform_en/disable_resources.


I too don't have any preference of the upstream path. Maybe i'll repost this 
series based on your v4 an then you can include them in your series if you like.


As indicated doing things in that order has my preference as rebase-conflict 
resolution should be a lot
easier that way then the other way around. So if you could do that, that would 
be great.


BTW why is your series still RFC at v4?


It was not RFC at v1 and v2, it became RFC at v3 because at that point it 
included changes which would
also impact ahci_imx, and I did not have hardware to verify those changes. The 
wandboard I ordered
for this has arrived yesterday, so my next version should not be RFC anymore :)


As far as OMAP platform is concerned, calling phy_power_off() + phy_exit() 
shouldn't be a problem for suspend.
Not sure about other platforms as we can't really know for sure what they do in 
phy_exit().


Good, after the rework my patch-series does, platforms which need something 
else can always override
the ahci_platform_disable_resources behavior (by doing that part themselves) 
while still using other parts
of ahci_platform.c as is, that is the whole idea of the rework.

Thanks & Regards,

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

Re: [PATCH V2] cpuidle/governors: Fix logic in selection of idle states

[Daniel Lezcano]

On 01/17/2014 05:33 AM, Preeti U Murthy wrote:

The cpuidle governors today are not handling scenarios where no idle state
can be chosen. Such scenarios coud arise if the user has disabled all the
idle states at runtime or the latency requirement from the cpus is very strict.

The menu governor returns 0th index of the idle state table when no other
idle state is suitable. This is even when the idle state corresponding to this
index is disabled or the latency requirement is strict and the exit_latency
of the lowest idle state is also not acceptable. Hence this patch
fixes this logic in the menu governor by defaulting to an idle state index
of -1 unless any other state is suitable.

The ladder governor needs a few more fixes in addition to that required in the
menu governor. When the ladder governor decides to demote the idle state of a
CPU, it does not check if the lower idle states are enabled. Add this logic
in addition to the logic where it chooses an index of -1 if it can neither
promote or demote the idle state of a cpu nor can it choose the current idle
state.

The cpuidle_idle_call() will return back if the governor decides upon not
entering any idle state. However it cannot return an error code because all
archs have the logic today that if the call to cpuidle_idle_call() fails, it
means that the cpuidle driver failed to *function*; for instance due to
errors during registration. As a result they end up deciding upon a
default idle state on their own, which could very well be a deep idle state.
This is incorrect in cases where no idle state is suitable.

Besides for the scenario that this patch is addressing, the call actually
succeeds. Its just that no idle state is thought to be suitable by the 
governors.
Under such a circumstance return success code without entering any idle
state.

Signed-off-by: Preeti U Murthy 

Changes from V1:https://lkml.org/lkml/2014/1/14/26

1. Change the return code to success from -EINVAL due to the reason mentioned
in the changelog.
2. Add logic that the patch is addressing in the ladder governor as well.
3. Added relevant comments and removed redundant logic as suggested in the
above thread.
---

  drivers/cpuidle/cpuidle.c  |   15 +-
  drivers/cpuidle/governors/ladder.c |   98 ++--
  drivers/cpuidle/governors/menu.c   |7 +--
  3 files changed, 89 insertions(+), 31 deletions(-)

diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index a55e68f..831b664 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -131,8 +131,9 @@ int cpuidle_idle_call(void)

/* ask the governor for the next state */
next_state = cpuidle_curr_governor->select(drv, dev);
+
+   dev->last_residency = 0;
if (need_resched()) {
-   dev->last_residency = 0;


Why do you need to do this change ? ^


/* give the governor an opportunity to reflect on the outcome */
if (cpuidle_curr_governor->reflect)
cpuidle_curr_governor->reflect(dev, next_state);
@@ -140,6 +141,18 @@ int cpuidle_idle_call(void)
return 0;
}

+   /* Unlike in the need_resched() case, we return here because the
+* governor did not find a suitable idle state. However idle is still
+* in progress as we are not asked to reschedule. Hence we return
+* without enabling interrupts.


That will lead to a WARN.


+* NOTE: The return code should still be success, since the verdict of 
this
+* call is "do not enter any idle state" and not a failed call due to
+* errors.
+*/
+   if (next_state < 0)
+   return 0;
+


Returning from here breaks the symmetry of the trace.


trace_cpu_idle_rcuidle(next_state, dev->cpu);

broadcast = !!(drv->states[next_state].flags & CPUIDLE_FLAG_TIMER_STOP);
diff --git a/drivers/cpuidle/governors/ladder.c 
b/drivers/cpuidle/governors/ladder.c
index 9f08e8c..f495f57 100644
--- a/drivers/cpuidle/governors/ladder.c
+++ b/drivers/cpuidle/governors/ladder.c
@@ -58,6 +58,36 @@ static inline void ladder_do_selection(struct ladder_device 
*ldev,
ldev->last_state_idx = new_idx;
  }

+static int can_promote(struct ladder_device *ldev, int last_idx,
+   int last_residency)
+{
+   struct ladder_device_state *last_state;
+
+   last_state = >states[last_idx];
+   if (last_residency > last_state->threshold.promotion_time) {
+   last_state->stats.promotion_count++;
+   last_state->stats.demotion_count = 0;
+   if (last_state->stats.promotion_count >= 
last_state->threshold.promotion_count)
+   return 1;
+   }
+   return 0;
+}
+
+static int can_demote(struct ladder_device *ldev, int last_idx,
+   int last_residency)
+{
+   struct ladder_device_state *last_state;
+
+   last_state = >states[last_idx];

Re: [PATCH] Documentation: devicetree: mct: Fix counter bit of CPU local timers

[Daniel Lezcano]

On 01/22/2014 09:08 AM, Jingoo Han wrote:

On Tuesday, January 21, 2014 6:03 PM, Jingoo Han wrote:


According to the datasheet of Exynos SoCs, the counter bit
of CPU local timers is 31-bit, not 32-bit; thus, it should
be fixed.


Please, ignore this patch.
There is a 31-bit counter in CPU local timers; however,
FRC (free running down-counters) of CPU local timers is
32-bit. Thus, there is no need to fix it.
Thank you.


Ok.



Signed-off-by: Jingoo Han 
---
  Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
index 167d5da..8c77791 100644
--- a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
+++ b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
@@ -3,7 +3,7 @@ Samsung's Multi Core Timer (MCT)
  The Samsung's Multi Core Timer (MCT) module includes two main blocks, the
  global timer and CPU local timers. The global timer is a 64-bit free running
  up-counter and can generate 4 interrupts when the counter reaches one of the
-four preset counter values. The CPU local timers are 32-bit free running
+four preset counter values. The CPU local timers are 31-bit free running
  down-counters and generate an interrupt when the counter expires. There is
  one CPU local timer instantiated in MCT for every CPU in the system.

--
1.7.10.4






--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

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

Re: Deadlock between cpu_hotplug_begin and cpu_add_remove_lock

[Srivatsa S. Bhat]

Hi Paul,

On 01/22/2014 11:22 AM, Paul Mackerras wrote:
> This arises out of a report from a tester that offlining a CPU never
> finished on a system they were testing.  This was on a POWER8 running
> a 3.10.x kernel, but the issue is still present in mainline AFAICS.
> 
> What I found when I looked at the system was this:
> 
> * There was a ppc64_cpu process stuck inside cpu_hotplug_begin(),
>   called from _cpu_down(), from cpu_down().  This process was holding
>   the cpu_add_remove_lock mutex, since cpu_down() calls
>   cpu_maps_update_begin() before calling _cpu_down().  It was stuck
>   there because cpu_hotplug.refcount == 1.
> 
> * There was a mdadm process trying to acquire the cpu_add_remove_lock
>   mutex inside register_cpu_notifier(), called from
>   raid5_alloc_percpu() in drivers/md/raid5.c.  That process had
>   previously called get_online_cpus, which is why cpu_hotplug.refcount
>   was 1.
> 
> Result: deadlock.
> 
> Thus it seems that the following code is not safe:
> 
>   get_online_cpus();
>   register_cpu_notifier(&...);
>   put_online_cpus();
>

Yes, this is a known problem, and I had proposed an elaborate solution
some time ago: https://lkml.org/lkml/2012/3/1/39
But that won't work for all cases, so that solution is a no-go.

If we forget the CPU_POST_DEAD stage for a moment, we can just replace the
calls to cpu_maps_update_begin/done() with get/put_online_cpus() in both
register_cpu_notifier() as well as unregister_cpu_notifier(). After all,
the callback registration code needs to synchronize only with the actual
hotplug operations, and not the update of cpu-maps. So they don't really
need to acquire the cpu_add_remove_lock.

However, CPU_POST_DEAD notifications run with the hotplug lock dropped.
So we can't simply replace cpu_add_remove_lock with hotplug lock in the
registration routines, because notifier invocations and notifier registration
needs to be synchronized.

Hmm...
 
> There are a few different places that do that sort of thing; besides
> drivers/md/raid5.c, there are instances in arch/x86/kernel/cpu,
> arch/x86/oprofile, drivers/cpufreq/acpi-cpufreq.c,
> drivers/oprofile/nmi_timer_int.c and kernel/trace/ring_buffer.c.
> 
> My question is this: is it reasonable to call register_cpu_notifier
> inside a get/put_online_cpus block?

Ideally, we would want that to work. Because there is no other race-free
way of registering a notifier.

>  If so, the deadlock needs to be
> fixed; if not, the callers need to be fixed, and the restriction
> should be documented.

Fixing the callers is a last resort. I'm thinking of ways to fix the
deadlock itself, and allow the callers to call register_cpu_notifier
within a get/put_online_cpus() block...

Regards,
Srivatsa S. Bhat


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

Re: [patch 1/3] drm/fb-helper: don't sleep for screen unblank when an oops is in progress

[Daniel Vetter]

On Tue, Jan 21, 2014 at 11:34 PM,   wrote:
> From: Daniel Vetter 
> Subject: drm/fb-helper: don't sleep for screen unblank when an oops is in 
> progress
>
> Otherwise the system will burn even brighter and worse, leave the user
> wondering what's going on exactly.
>
> Since we already have a panic handler which will (try) to restore the
> entire fbdev console mode, we can just bail out.  Inspired by a patch from
> Konstantin Khlebnikov.  The callchain leading to this, cut from
> Konstantin's original patch:
>
> callstack:
> panic()
> bust_spinlocks(1)
> unblank_screen()
> vc->vc_sw->con_blank()
> fbcon_blank()
> fb_blank()
> info->fbops->fb_blank()
> drm_fb_helper_blank()
> drm_fb_helper_dpms()
> drm_modeset_lock_all()
> mutex_lock(>mode_config.mutex)
>
> Note that the entire locking in the fb helper around panic/sysrq and kdbg
> is ...  non-existant.  So we have a decent change of blowing up
> everything.  But since reworking this ties in with funny concepts like the
> fbdev notifier chain or the impressive things which happen around
> console_lock while oopsing, I'll leave that as an exercise for braver
> souls than me.
>
> Signed-off-by: Daniel Vetter 
> Cc: Konstantin Khlebnikov 
> Cc: Dave Airlie 
> Reviewed-by: Rob Clark 
> Signed-off-by: Andrew Morton 

We've merged this twic already in 1b1d5397058f06b and
928c2f0c006bf7f381f58 and then had to take out the superflous hunk
again in ecc7e6f3bb8ad56764

For some oddball reason git/patch _really_ gets confused here and
loves to readd that hunk a few more times (iirc one of my own trees
once even ended up with 3 copies ...). No idea what's going on, but we
can drop this on here ;-)

Or what exactly was the point of this patch submission, I didn't spot
a "dropped from -mm" or similar note, and it doesn't seem to be cc'ed
to lists.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v2 0/4] Intel MPX support

[Ren, Qiaowei]

> -Original Message-
> From: David Rientjes [mailto:rient...@google.com]
> Sent: Wednesday, January 22, 2014 4:01 PM
> To: Ren, Qiaowei
> Cc: H. Peter Anvin; Thomas Gleixner; Ingo Molnar; x...@kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 0/4] Intel MPX support
> 
> On Wed, 22 Jan 2014, Qiaowei Ren wrote:
> 
> > Changes since v1:
> >   * check to see if #BR occurred in userspace or kernel space.
> >   * use generic structure and macro as much as possible when
> > decode mpx instructions.
> >
> > Qiaowei Ren (4):
> >   x86, mpx: add documentation on Intel MPX
> >   x86, mpx: hook #BR exception handler to allocate bound tables
> >   x86, mpx: add prctl commands PR_MPX_INIT, PR_MPX_RELEASE
> >   x86, mpx: extend siginfo structure to include bound violation
> > information
> >
> >  Documentation/x86/intel_mpx.txt|   76 +++
> >  arch/x86/Kconfig   |4 +
> >  arch/x86/include/asm/mpx.h |   63 ++
> >  arch/x86/include/asm/processor.h   |   16 ++
> >  arch/x86/kernel/Makefile   |1 +
> >  arch/x86/kernel/mpx.c  |  417
> 
> >  arch/x86/kernel/traps.c|   61 +-
> >  include/uapi/asm-generic/siginfo.h |9 +-
> >  include/uapi/linux/prctl.h |6 +
> >  kernel/signal.c|4 +
> >  kernel/sys.c   |   12 +
> >  11 files changed, 667 insertions(+), 2 deletions(-)  create mode
> > 100644 Documentation/x86/intel_mpx.txt  create mode 100644
> > arch/x86/include/asm/mpx.h  create mode 100644 arch/x86/kernel/mpx.c
> >
> 
> There's compiler warnings spread amongst the various patches with x86_64
> defconfig:
> 
> arch/x86/kernel/mpx.c: In function ‘do_mpx_bounds’:
> arch/x86/kernel/mpx.c:415:2: warning: format ‘%lx’ expects argument of
> type ‘long unsigned int’, but argument 3 has type ‘void *’ [-Wformat]
> arch/x86/kernel/mpx.c:415:2: warning: format ‘%lx’ expects argument of
> type ‘long unsigned int’, but argument 4 has type ‘void *’ [-Wformat]
> arch/x86/kernel/mpx.c: In function ‘do_mpx_bt_fault’:
> arch/x86/kernel/mpx.c:373:5: warning: ‘old_val’ may be used uninitialized in
> this function [-Wuninitialized]
> arch/x86/kernel/mpx.c:360:25: note: ‘old_val’ was declared here
> 
I will fix these warnings.
old_val will be set by user_atomic_cmpxchg_inatomic().

> and I had to resolve the second patch manually because of "x86/traps:
> Clean up error exception handler definitions" in the x86 tree.
> 
There is a conflict with latest kernel. I just fixed it and built successfully.

> With 32-bit, we get casting warnings:
> 
> arch/x86/kernel/mpx.c: In function ‘do_mpx_bounds’:
> arch/x86/kernel/mpx.c:407:3: warning: cast to pointer from integer of 
> different
> size [-Wint-to-pointer-cast]
> arch/x86/kernel/mpx.c:409:3: warning: cast to pointer from integer of 
> different
> size [-Wint-to-pointer-cast]
> 
> and I'm pretty sure you want this to be available for such a config.
> 
> There's also whitespace in the fourth patch.
Thanks much for your feedback.

Qiaowei

Re: qemu hangs on current git

[Markus Trippelsdorf]

On 2014.01.21 at 22:51 +0100, Markus Trippelsdorf wrote:
> Running the current git tree (v3.13-3260-g03d11a0e458d) on the host,
> qemu sometimes hangs during test boots of the kernel (version of the guest
> kernel doesn't matter). This happens roughly every 4-6 runs and manifest
> itself in hangs during the guest boot. Perf shows:
> 
> 31.56%  qemu-system-x86  [kernel.kallsyms][k] __srcu_read_unlock
> 31.51%  qemu-system-x86  [kernel.kallsyms][k] __srcu_read_lock
> 20.95%  qemu-system-x86  [kernel.kallsyms][k] 
> kvm_arch_vcpu_ioctl_run
>  4.72%  qemu-system-x86  [kernel.kallsyms][k] 
> svm_complete_interrupts
>  3.28%  qemu-system-x86  [kernel.kallsyms][k] 
> kvm_check_async_pf_completion
>  2.04%  qemu-system-x86  [kernel.kallsyms][k] 
> apic_has_pending_timer
>  1.38%  qemu-system-x86  [kernel.kallsyms][k] svm_cancel_injection
>  1.29%  qemu-system-x86  [kernel.kallsyms][k] _cond_resched
>  1.04%  qemu-system-x86  [kernel.kallsyms][k] kvm_resched
>  0.66%  qemu-system-x86  [kernel.kallsyms][k] 
> svm_prepare_guest_switch
>  0.16%  qemu-system-x86  qemu-system-x86_64   [.] phys_page_find
> 
> qemu command used:
>  % qemu-system-x86_64 -s -enable-kvm -net nic,vlan=0,model=virtio -net user 
> -fsdev local,security_model=none,id=root,path=/ -device 
> virtio-9p-pci,id=root,fsdev=root,mount_tag=/dev/root -m 512 -smp 2 -kernel 
> /usr/src/linux/arch/x86/boot/bzImage -nographic -append "init=/bin/zsh 
> root=/dev/root console=ttyS0 kgdboc=ttyS0 rootflags=rw,trans=virtio 
> rootfstype=9p ip=dhcp earlyprintk=ttyS0"

Some more info:

[Jan22 09:45] INFO: rcu_sched self-detected stall on CPU
[  +0.06]   0: (17999 ticks this GP) idle=def/141/0 
softirq=2462/2462 
[  +0.01](t=18000 jiffies g=991 c=990 q=6528)
[  +0.02] sending NMI to all CPUs:
[  +0.07] NMI backtrace for cpu 0
[  +0.07] CPU: 0 PID: 705 Comm: qemu-system-x86 Not tainted 
3.13.0-03477-gdf32e43a54d0 #98
[  +0.01] Hardware name: System manufacturer System Product Name/M4A78T-E, 
BIOS 350304/13/2011
[  +0.02] task: 8802106aed00 ti: 8800c8e24000 task.ti: 
8800c8e24000
[  +0.01] RIP: 0010:[]  [] 
__const_udelay+0x9/0x30
[  +0.06] RSP: 0018:8800dfc03e60  EFLAGS: 0006
[  +0.02] RAX: 0c00 RBX: 2710 RCX: 0007
[  +0.01] RDX: 00a3503e RSI: 0046 RDI: 00418958
[  +0.01] RBP: 81a1c4c0 R08: 02b0 R09: 
[  +0.01] R10:  R11: 02af R12: 
[  +0.01] R13: 81a64fd8 R14: 1980 R15: 81a1c4c0
[  +0.01] FS:  () GS:8800dfc0() 
knlGS:
[  +0.01] CS:  0010 DS:  ES:  CR0: 8005003b
[  +0.01] CR2: 880001ab0ff8 CR3: 00021456c000 CR4: 07f0
[  +0.01] Stack:
[  +0.01]  81053295 8800dfc0d4c0 810a0e17 
0086
[  +0.02]  810a2976 00011a00 0086 
8802106aed00
[  +0.02]     
8800dfc0ce78
[  +0.02] Call Trace:
[  +0.01]   

[  +0.04]  [] ? arch_trigger_all_cpu_backtrace+0x55/0x70
[  +0.03]  [] ? rcu_check_callbacks+0x387/0x5e0
[  +0.03]  [] ? update_wall_time+0x276/0x660
[  +0.03]  [] ? update_process_times+0x49/0x80
[  +0.02]  [] ? tick_sched_timer+0x42/0x70
[  +0.03]  [] ? __run_hrtimer.isra.32+0x4d/0x110
[  +0.02]  [] ? hrtimer_interrupt+0xe7/0x230
[  +0.02]  [] ? smp_apic_timer_interrupt+0x36/0x50
[  +0.03]  [] ? apic_timer_interrupt+0x67/0x70
[  +0.00]   

[  +0.03]  [] ? __srcu_read_lock+0x28/0x50
[  +0.04]  [] ? kvm_arch_vcpu_ioctl_run+0xb2c/0x1090
[  +0.03]  [] ? pty_write+0x5c/0x60
[  +0.03]  [] ? remove_wait_queue+0x18/0x60
[  +0.02]  [] ? kvm_arch_vcpu_load+0x47/0x1d0
[  +0.03]  [] ? kvm_vcpu_ioctl+0x2a2/0x530
[  +0.03]  [] ? kvm_vm_ioctl+0x5d7/0x730
[  +0.02]  [] ? fsnotify+0x27e/0x350
[  +0.02]  [] ? do_vfs_ioctl+0x2d0/0x490
[  +0.03]  [] ? __schedule+0x2a4/0x750
[  +0.02]  [] ? SyS_ioctl+0x4d/0xa0
[  +0.02]  [] ? system_call_fastpath+0x16/0x1b
[  +0.01] Code: 89 07 31 c0 f3 c3 66 66 66 2e 0f 1f 84 00 00 00 00 00 48 8b 
05 d9 b9 83 00 ff e0 0f 1f 80 00 00 00 00 65 48 8b 14 25 20 12 01 00 <48> 8d 0c 
92 48 8d 04 bd
 00 00 00 00 48 89 ca 48 c1 e2 04 48 29 
[  +0.23] NMI backtrace for cpu 3
[  +0.10] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 
3.13.0-03477-gdf32e43a54d0 #98
[  +0.03] Hardware name: System manufacturer System Product Name/M4A78T-E, 
BIOS 350304/13/2011
[  +0.05] task: 88021f88caf0 ti: 88021f8b4000 task.ti: 
88021f8b4000
[  +0.03] RIP: 0010:[]  [] 
rcu_check_callbacks+0xd9/0x5e0
[  +0.14] RSP: 0018:8800dfd83d90  EFLAGS: 

Re: [PATCH 68/73] drivers/cpufreq: delete non-required instances of

[Paul Gortmaker]

On 1/21/14, Viresh Kumar  wrote:
> On 22 January 2014 02:53, Paul Gortmaker 
> wrote:
>> None of these files are actually using any __init type directives
>> and hence don't need to include .  Most are just a
>> left over from __devinit and __cpuinit removal, or simply due to
>> code getting copied from one driver to the next.
>>
>> Cc: Kevin Hilman 
>> Cc: "Rafael J. Wysocki" 
>> Cc: Viresh Kumar 
>> Cc: cpuf...@vger.kernel.org
>> Cc: linux...@vger.kernel.org
>> Signed-off-by: Paul Gortmaker 
>> ---
>>  drivers/cpufreq/omap-cpufreq.c| 1 -
>>  drivers/cpufreq/powernow-k8.c | 1 -
>>  drivers/cpufreq/s3c2412-cpufreq.c | 1 -
>>  drivers/cpufreq/s3c2440-cpufreq.c | 1 -
>>  drivers/cpufreq/spear-cpufreq.c   | 1 -
>>  drivers/cpufreq/speedstep-lib.c   | 1 -
>>  6 files changed, 6 deletions(-)
>
> We have discussed this in past where I pointed out this file is required
> by stuff like module_init, what happened to that query ?

Patch 31/73 relocates module_init and similar macros to
module.h so that is no longer an implicit dependency.

https://lkml.org/lkml/2014/1/21/488

Thanks,
Paul
--

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

RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst [NEW HARDWARE]

[David Laight]

From: walt
> On 01/21/2014 01:51 AM, David Laight wrote:
> > From: Sarah Sharp
> >> On Mon, Jan 20, 2014 at 11:21:14AM +, David Laight wrote:
> > ...
> >>> A guess...
> >>>
> >>> In queue_bulk_sg_tx() try calling xhci_v1_0_td_remainder() instead
> >>> of xhci_td_remainder().
> >>
> David, I tried the one-liner below, which changed nothing AFAICS, but
> then I'm not sure it's the change you intended:
...
>   /* Set the TRB length, TD size, and interrupter fields. */
> - if (xhci->hci_version < 0x100) {
> + if (xhci->hci_version > 0x100) {
>   remainder = xhci_td_remainder(
>   urb->transfer_buffer_length -
>   running_total);

So my wild guess wasn't right.
Can't win them all.

David

Re: Deadlock between cpu_hotplug_begin and cpu_add_remove_lock

[Srivatsa S. Bhat]

On 01/22/2014 02:00 PM, Srivatsa S. Bhat wrote:
> Hi Paul,
> 
> On 01/22/2014 11:22 AM, Paul Mackerras wrote:
>> This arises out of a report from a tester that offlining a CPU never
>> finished on a system they were testing.  This was on a POWER8 running
>> a 3.10.x kernel, but the issue is still present in mainline AFAICS.
>>
>> What I found when I looked at the system was this:
>>
>> * There was a ppc64_cpu process stuck inside cpu_hotplug_begin(),
>>   called from _cpu_down(), from cpu_down().  This process was holding
>>   the cpu_add_remove_lock mutex, since cpu_down() calls
>>   cpu_maps_update_begin() before calling _cpu_down().  It was stuck
>>   there because cpu_hotplug.refcount == 1.
>>
>> * There was a mdadm process trying to acquire the cpu_add_remove_lock
>>   mutex inside register_cpu_notifier(), called from
>>   raid5_alloc_percpu() in drivers/md/raid5.c.  That process had
>>   previously called get_online_cpus, which is why cpu_hotplug.refcount
>>   was 1.
>>
>> Result: deadlock.
>>
>> Thus it seems that the following code is not safe:
>>
>>  get_online_cpus();
>>  register_cpu_notifier(&...);
>>  put_online_cpus();
>>
> 
> Yes, this is a known problem, and I had proposed an elaborate solution
> some time ago: https://lkml.org/lkml/2012/3/1/39
> But that won't work for all cases, so that solution is a no-go.
> 

Wait a min, that _will_ actually work for all cases because I have provided
an option to invoke _any_ arbitrary function as the "setup" routine.

So, taking the example of raid5 that you mentioned below, instead of doing
this:

static int raid5_alloc_percpu()
{
...
get_online_cpus();
for_each_present_cpu(cpu) {
  ...
}
...
register_cpu_notifier();
put_online_cpus();
}

We can do this:

void func()
{
for_each_present_cpu(cpu) {
...
}
...
}

static int raid5_alloc_percpu()
{
...
register_allcpu_notifier(..., true, func);
}


The other, simpler alternative fix is to use cpu_hotplug_disable/enable()
in place of get/put_online_cpus() around the callback registration code.
Something like this:

cpu_hotplug_disable();
register_cpu_notifier();
cpu_hotplug_enable();

But the problem with this is that a hotplug operation that tries to run
concurrently with this will get a -EBUSY, which is kinda undesirable.
Also, this will only synchronize with hotplug operations initiated via
calls to cpu_up/down() (such as those that are initiated by writing to the
online file in sysfs). It won't synchronize with the hotplug operations
invoked by disable/enable_nonboot_cpus(), which by-pass cpu_up/down() and
directly call _cpu_up/down() by ignoring the cpu_hotplug_disabled flag.

The latter is a more controlled environment though, since its mostly used
by the suspend/hibernate code, in a state where the entire userspace is
frozen. So it might not be that bad.

Regards,
Srivatsa S. Bhat

> If we forget the CPU_POST_DEAD stage for a moment, we can just replace the
> calls to cpu_maps_update_begin/done() with get/put_online_cpus() in both
> register_cpu_notifier() as well as unregister_cpu_notifier(). After all,
> the callback registration code needs to synchronize only with the actual
> hotplug operations, and not the update of cpu-maps. So they don't really
> need to acquire the cpu_add_remove_lock.
> 
> However, CPU_POST_DEAD notifications run with the hotplug lock dropped.
> So we can't simply replace cpu_add_remove_lock with hotplug lock in the
> registration routines, because notifier invocations and notifier registration
> needs to be synchronized.
> 
> Hmm...
>  
>> There are a few different places that do that sort of thing; besides
>> drivers/md/raid5.c, there are instances in arch/x86/kernel/cpu,
>> arch/x86/oprofile, drivers/cpufreq/acpi-cpufreq.c,
>> drivers/oprofile/nmi_timer_int.c and kernel/trace/ring_buffer.c.
>>
>> My question is this: is it reasonable to call register_cpu_notifier
>> inside a get/put_online_cpus block?
> 
> Ideally, we would want that to work. Because there is no other race-free
> way of registering a notifier.
> 
>>  If so, the deadlock needs to be
>> fixed; if not, the callers need to be fixed, and the restriction
>> should be documented.
> 
> Fixing the callers is a last resort. I'm thinking of ways to fix the
> deadlock itself, and allow the callers to call register_cpu_notifier
> within a get/put_online_cpus() block...
> 

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

Re: [PATCH] pwm: add support for Intel Low Power Subsystem PWM

[Mika Westerberg]

On Tue, Jan 21, 2014 at 08:43:39PM +0100, Thierry Reding wrote:
> The idea behind this is that only a single user can have access to a
> given PWM device at a time. The PWM device's PWMF_REQUESTED flag is set
> (and cleared) under the pwm_lock and any subsequent users will not be
> able to use that specific device (pwm_request() return -EBUSY).
> 
> There is obviously an assumption here that each user knows what they are
> doing and aren't calling any of the public pwm_*() functions
> concurrently. I haven't come across a situation where this is actually a
> problem because typically these functions are called either via sysfs or
> some other higher-level where synchronization is already properly
> handled.
> 
> So the only thing that drivers should be taking care of is synchronizing
> access to registers common to multiple PWM devices.

OK, and since LPSS PWM don't share registers we shouldn't need to do
anything here.

> Does that clarify things?

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

[PATCH v3 0/4] power_supply: Introduce power supply charging driver

[Jenny TC]

v1: introduced feature as a framework within power supply class driver with
separate files for battid framework and charging framework
v2: fixed review comments, moved macros and inline functions to power_supply.h
v3: moved the feature as a separate driver, combined battid framework and
charging framework inside the power supply charging driver. Moved
charger specific properties to power_supply_charger.h and plugged the
driver with power supply subsystem using power_supply_notifier
introduced in my previous patch. Also a sample charger chip driver
(bq24261) patch added to give more idea on the psy charging driver
usage

The Power Supply charging driver connects multiple subsystems
to do charging in a generic way. The subsystems involves power_supply,
thermal and battery communication subsystems (1wire).
With this the charging is handled in a generic way.

The driver makes use of different new features - Battery Identification
interfaces, pluggable charging algorithms, charger cable arbitrations etc.

At present the charging is done based on the static battery characteristics.
This is done at the boot time by passing the battery properties (max_voltage,
capacity) etc. as a platform data to the charger/battery driver.
But new generation high volt batteries needs to be identified dynamically
to do charging in a safe manner. The batteries are coming with different
communication protocols (BSI/SDQ/MIPI BIF). It become necessary to communicate
with battery and identify it's charging profiles before setup charging.

Also the charging algorithms can vary based on the battery characteristics
and the platform characteristics. To handle charging in a generic way it's
necessary to support pluggable charging algorithms. Power Supply Charging
driver selects algorithms based on the type of battery charging profile.
This is a simple binding and can be improved later. This may be improved to
select the algorithms based on the platform requirements. Also we can extend
this driver to plug algorithms from the user space.

The driver also introduces the charger cable arbitration. A charger may
supports multiple cables, but it may not be able to charge with multiple
cables at a time (USB/AC/Wireless etc). The arbitration logic inside the
driver selects the cable based on it's capabilities and the maximum
charge current the platform can support. Also the driver arbitrates between
different charger chip drivers based on their priority.

Also the driver exposes features to control charging on different platform
states. One such feature is thermal. The driver handles the thermal
throttling requests for charging and control charging based on the thermal
subsystem requirements.

The patch also introduces generic interface for charger cable notifications.
Charger cable events and capabilities can be notified using the generic
power_supply_notifier chain.

Overall this driver removes the charging logic out of the charger chip driver
and the charger chip driver can just listen to the request from the power
supply charging driver to set the charger properties. This can be implemented
by exposing get_property and set property callbacks.

Jenny TC (4):
  power_supply: Add inlmt,iterm, min/max temp props
  power_supply: Introduce Generic Power Supply charging driver
  power_supply: Introduce PSE compliant algorithm
  power_supply: bq24261 charger driver

 Documentation/power/power_supply_charger.txt |  332 ++
 Documentation/power/power_supply_class.txt   |6 +
 drivers/power/Kconfig|   30 +
 drivers/power/Makefile   |3 +
 drivers/power/bq24261_charger.c  | 1447 ++
 drivers/power/charging_algo_pse.c|  198 
 drivers/power/power_supply_charger.c | 1191 +
 drivers/power/power_supply_charger.h |  218 
 drivers/power/power_supply_core.c|3 +
 drivers/power/power_supply_sysfs.c   |4 +
 include/linux/power/bq24261_charger.h|   33 +
 include/linux/power/power_supply_charger.h   |  234 +
 include/linux/power_supply.h |  162 +++
 13 files changed, 3861 insertions(+)
 create mode 100644 Documentation/power/power_supply_charger.txt
 create mode 100644 drivers/power/bq24261_charger.c
 create mode 100644 drivers/power/charging_algo_pse.c
 create mode 100644 drivers/power/power_supply_charger.c
 create mode 100644 drivers/power/power_supply_charger.h
 create mode 100644 include/linux/power/bq24261_charger.h
 create mode 100644 include/linux/power/power_supply_charger.h

-- 
1.7.9.5

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

[PATCH 4/4] power_supply: bq24261 charger driver

[Jenny TC]

This patch introduces BQ24261 charger driver. The driver makes use of power
supply charging driver to setup charging. So the driver does hardware
abstraction and handles h/w specific corner cases. The charging logic resides
with power supply charging driver

Signed-off-by: Jenny TC 
---
 drivers/power/Kconfig |   10 +
 drivers/power/Makefile|1 +
 drivers/power/bq24261_charger.c   | 1447 +
 include/linux/power/bq24261_charger.h |   33 +
 4 files changed, 1491 insertions(+)
 create mode 100644 drivers/power/bq24261_charger.c
 create mode 100644 include/linux/power/bq24261_charger.h

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 655457b..3f32f61 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -408,6 +408,16 @@ config BATTERY_GOLDFISH
  Say Y to enable support for the battery and AC power in the
  Goldfish emulator.
 
+config BQ24261_CHARGER
+   tristate "BQ24261 charger driver"
+   select POWER_SUPPLY_CHARGER
+   depends on I2C
+   help
+ Say Y to include support for BQ24261 Charger driver. This driver
+ makes use of power supply charging driver. So the driver gives
+ the charger hardware abstraction only. Charging logic is abstracted
+ in the power supply charging driver.
+
 source "drivers/power/reset/Kconfig"
 
 endif # POWER_SUPPLY
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 77535fd..6d184c8 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -59,4 +59,5 @@ obj-$(CONFIG_CHARGER_BQ24735) += bq24735-charger.o
 obj-$(CONFIG_POWER_AVS)+= avs/
 obj-$(CONFIG_CHARGER_SMB347)   += smb347-charger.o
 obj-$(CONFIG_CHARGER_TPS65090) += tps65090-charger.o
+obj-$(CONFIG_BQ24261_CHARGER)  += bq24261_charger.o
 obj-$(CONFIG_POWER_RESET)  += reset/
diff --git a/drivers/power/bq24261_charger.c b/drivers/power/bq24261_charger.c
new file mode 100644
index 000..6ac063b
--- /dev/null
+++ b/drivers/power/bq24261_charger.c
@@ -0,0 +1,1447 @@
+/*
+ * bq24261_charger.c - BQ24261 Charger I2C client driver
+ *
+ * Copyright (C) 2011 Intel Corporation
+ *
+ * ~~
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.See the GNU
+ * General Public License for more details.
+ *
+ * ~~
+ * Author: Jenny TC 
+ */
+#define DEBUG
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define DEV_NAME "bq24261_charger"
+#define DEV_MANUFACTURER "TI"
+#define MODEL_NAME_SIZE 8
+#define DEV_MANUFACTURER_NAME_SIZE 4
+
+#define EXCEPTION_MONITOR_DELAY (60 * HZ)
+#define WDT_RESET_DELAY (15 * HZ)
+
+/* BQ24261 registers */
+#define BQ24261_STAT_CTRL0_ADDR0x00
+#define BQ24261_CTRL_ADDR  0x01
+#define BQ24261_BATT_VOL_CTRL_ADDR 0x02
+#define BQ24261_VENDOR_REV_ADDR0x03
+#define BQ24261_TERM_FCC_ADDR  0x04
+#define BQ24261_VINDPM_STAT_ADDR   0x05
+#define BQ24261_ST_NTC_MON_ADDR0x06
+
+#define BQ24261_RESET_MASK (0x01 << 7)
+#define BQ24261_RESET_ENABLE   (0x01 << 7)
+
+#define BQ24261_FAULT_MASK 0x07
+#define BQ24261_STAT_MASK  (0x03 << 4)
+#define BQ24261_BOOST_MASK (0x01 << 6)
+#define BQ24261_TMR_RST_MASK   (0x01 << 7)
+#define BQ24261_TMR_RST(0x01 << 7)
+
+#define BQ24261_ENABLE_BOOST   (0x01 << 6)
+
+#define BQ24261_VOVP   0x01
+#define BQ24261_LOW_SUPPLY 0x02
+#define BQ24261_THERMAL_SHUTDOWN   0x03
+#define BQ24261_BATT_TEMP_FAULT0x04
+#define BQ24261_TIMER_FAULT0x05
+#define BQ24261_BATT_OVP   0x06
+#define BQ24261_NO_BATTERY 0x07
+#define BQ24261_STAT_READY 0x00
+
+#define BQ24261_STAT_CHRG_PRGRSS   (0x01 << 4)
+#define BQ24261_STAT_CHRG_DONE (0x02 << 4)
+#define BQ24261_STAT_FAULT (0x03 << 4)
+
+#define BQ24261_CE_MASK(0x01 << 1)
+#define BQ24261_CE_DISABLE (0x01 << 1)
+
+#define BQ24261_HZ_MASK(0x01)
+#define BQ24261_HZ_ENABLE  (0x01)
+
+#define BQ24261_ICHRG_MASK (0x1F << 3)
+#define BQ24261_ICHRG_100ma(0x01 << 3)
+#define BQ24261_ICHRG_200ma(0x01 << 4)
+#define 

[PATCH 3/4] power_supply: Introduce PSE compliant algorithm

[Jenny TC]

As per Product Safety Engineering (PSE) specification for battery charging, the
battery characteristics and thereby the charging rates can vary on different
temperature zones. This patch introduces a PSE compliant charging algorithm with
maintenance charging support. The algorithm can be selected by the power supply
charging driver based on the type of the battery charging profile.

Signed-off-by: Jenny TC 
---
 drivers/power/Kconfig  |   12 ++
 drivers/power/Makefile |1 +
 drivers/power/charging_algo_pse.c  |  198 
 include/linux/power/power_supply_charger.h |   44 +++
 4 files changed, 255 insertions(+)
 create mode 100644 drivers/power/charging_algo_pse.c

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 7bfad7a..655457b 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -22,6 +22,18 @@ config POWER_SUPPLY_CHARGER
  drivers to keep the charging logic outside and the charger driver
  just need to abstract the charger hardware
 
+config POWER_SUPPLY_CHARGING_ALGO_PSE
+   bool "PSE compliant charging algorithm"
+   help
+ Say Y here to select PSE compliant charging algorithm. As per PSE
+ standard the battery characteristics and thereby the charging rates
+ can vary on different temperature zones. This config will enable PSE
+ compliant charging algorithm with maintenance charging support. The
+ algorithm can be selected by the charging framework based on the type
+ of the battery charging profile.
+
+   depends on POWER_SUPPLY_CHARGER
+
 config PDA_POWER
tristate "Generic PDA/phone power driver"
depends on !S390
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 405f0f4..77535fd 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_POWER_SUPPLY)  += power_supply.o
 obj-$(CONFIG_GENERIC_ADC_BATTERY)  += generic-adc-battery.o
 
 obj-$(CONFIG_POWER_SUPPLY_CHARGER) += power_supply_charger.o
+obj-$(CONFIG_POWER_SUPPLY_CHARGING_ALGO_PSE) += charging_algo_pse.o
 obj-$(CONFIG_PDA_POWER)+= pda_power.o
 obj-$(CONFIG_APM_POWER)+= apm_power.o
 obj-$(CONFIG_MAX8925_POWER)+= max8925_power.o
diff --git a/drivers/power/charging_algo_pse.c 
b/drivers/power/charging_algo_pse.c
new file mode 100644
index 000..41c24c3
--- /dev/null
+++ b/drivers/power/charging_algo_pse.c
@@ -0,0 +1,198 @@
+/*
+ * Copyright (C) 2012 Intel Corporation
+ *
+ * ~~
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.See the GNU
+ * General Public License for more details.
+ *
+ * ~~
+ * Author: Jenny TC 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "power_supply.h"
+#include "power_supply_charger.h"
+
+/* 98% of CV is considered as voltage to detect Full */
+#define FULL_CV_MIN 98
+
+/* Offset to exit from maintenance charging. In maintenance charging
+*  if the volatge is less than the (maintenance_lower_threshold -
+*  MAINT_EXIT_OFFSET) then system can switch to normal charging
+*/
+#define MAINT_EXIT_OFFSET 50  /* mv */
+
+static int get_tempzone(struct psy_ps_pse_mod_prof *pse_mod_bprof,
+   int temp)
+{
+
+   int i = 0;
+   int temp_range_cnt = min_t(u16, pse_mod_bprof->temp_mon_ranges,
+   BATT_TEMP_NR_RNG);
+
+   if ((temp < pse_mod_bprof->temp_low_lim) ||
+   (temp > pse_mod_bprof->temp_mon_range[0].temp_up_lim))
+   return -EINVAL;
+
+   for (i = 0; i < temp_range_cnt; ++i)
+   if (temp > pse_mod_bprof->temp_mon_range[i].temp_up_lim)
+   break;
+   return i-1;
+}
+
+static inline bool __is_battery_full
+   (long volt, long cur, long iterm, unsigned long cv)
+{
+   pr_devel("%s:current=%ld pse_mod_bprof->chrg_term_ma =%ld 
voltage_now=%ld full_cond=%ld",
+   __func__, cur, iterm, volt * 100, (FULL_CV_MIN * cv));
+
+   return (cur > 0) && (cur <= iterm) &&
+   ((volt * 100)  >= (FULL_CV_MIN * cv));
+
+}
+
+static inline bool is_battery_full(struct psy_batt_props bat_prop,
+   struct psy_ps_pse_mod_prof *pse_mod_bprof, unsigned long cv)
+{
+
+   int i;
+   /* Software full detection. Check the battery charge current to detect
+   *  battery Full. The voltage also verified to avoid false charge
+ 

[PATCH 1/4] power_supply: Add inlmt,iterm, min/max temp props

[Jenny TC]

Add new power supply properties for input current, charge termination
current, min and max temperature

POWER_SUPPLY_PROP_TEMP_MIN - minimum operatable temperature
POWER_SUPPLY_PROP_TEMP_MAX - maximum operatable temperature

POWER_SUPPLY_PROP_INLMT - input current limit programmed by charger. Indicates
the input current for a charging source.

POWER_SUPPLY_PROP_CHARGE_TERM_CUR - Charge termination current used to detect
the end of charge condition

Change-Id: Ifb40662bbfa24387ac7493ffa7ce01c6fae7e800
Signed-off-by: Jenny TC 
---
 Documentation/power/power_supply_class.txt |6 ++
 drivers/power/power_supply_sysfs.c |4 
 include/linux/power_supply.h   |4 
 3 files changed, 14 insertions(+)

diff --git a/Documentation/power/power_supply_class.txt 
b/Documentation/power/power_supply_class.txt
index 89a8816..f7e06d7 100644
--- a/Documentation/power/power_supply_class.txt
+++ b/Documentation/power/power_supply_class.txt
@@ -118,6 +118,10 @@ relative, time-based measurements.
 CONSTANT_CHARGE_CURRENT - constant charge current programmed by charger.
 CONSTANT_CHARGE_CURRENT_MAX - maximum charge current supported by the
 power supply object.
+INPUT_CURRENT_LIMIT - input current limit programmed by charger. Indicates
+the current drawn from a charging source.
+CHARGE_TERM_CUR - Charge termination current used to detect the end of charge
+condition
 
 CONSTANT_CHARGE_VOLTAGE - constant charge voltage programmed by charger.
 CONSTANT_CHARGE_VOLTAGE_MAX - maximum charge voltage supported by the
@@ -140,6 +144,8 @@ TEMP_ALERT_MAX - maximum battery temperature alert.
 TEMP_AMBIENT - ambient temperature.
 TEMP_AMBIENT_ALERT_MIN - minimum ambient temperature alert.
 TEMP_AMBIENT_ALERT_MAX - maximum ambient temperature alert.
+TEMP_MIN - minimum operatable temperature
+TEMP_MAX - maximum operatable temperature
 
 TIME_TO_EMPTY - seconds left for battery to be considered empty (i.e.
 while battery powers a load)
diff --git a/drivers/power/power_supply_sysfs.c 
b/drivers/power/power_supply_sysfs.c
index 44420d1..222dd78 100644
--- a/drivers/power/power_supply_sysfs.c
+++ b/drivers/power/power_supply_sysfs.c
@@ -167,6 +167,7 @@ static struct device_attribute power_supply_attrs[] = {
POWER_SUPPLY_ATTR(constant_charge_voltage_max),
POWER_SUPPLY_ATTR(charge_control_limit),
POWER_SUPPLY_ATTR(charge_control_limit_max),
+   POWER_SUPPLY_ATTR(input_cur_limit),
POWER_SUPPLY_ATTR(energy_full_design),
POWER_SUPPLY_ATTR(energy_empty_design),
POWER_SUPPLY_ATTR(energy_full),
@@ -178,6 +179,8 @@ static struct device_attribute power_supply_attrs[] = {
POWER_SUPPLY_ATTR(capacity_alert_max),
POWER_SUPPLY_ATTR(capacity_level),
POWER_SUPPLY_ATTR(temp),
+   POWER_SUPPLY_ATTR(temp_max),
+   POWER_SUPPLY_ATTR(temp_min),
POWER_SUPPLY_ATTR(temp_alert_min),
POWER_SUPPLY_ATTR(temp_alert_max),
POWER_SUPPLY_ATTR(temp_ambient),
@@ -189,6 +192,7 @@ static struct device_attribute power_supply_attrs[] = {
POWER_SUPPLY_ATTR(time_to_full_avg),
POWER_SUPPLY_ATTR(type),
POWER_SUPPLY_ATTR(scope),
+   POWER_SUPPLY_ATTR(charge_term_cur),
/* Properties of type `const char *' */
POWER_SUPPLY_ATTR(model_name),
POWER_SUPPLY_ATTR(manufacturer),
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index c9dc4e0..4dbb543 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -120,6 +120,7 @@ enum power_supply_property {
POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX,
POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT,
POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT_MAX,
+   POWER_SUPPLY_PROP_INLMT,
POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN,
POWER_SUPPLY_PROP_ENERGY_EMPTY_DESIGN,
POWER_SUPPLY_PROP_ENERGY_FULL,
@@ -131,6 +132,8 @@ enum power_supply_property {
POWER_SUPPLY_PROP_CAPACITY_ALERT_MAX, /* in percents! */
POWER_SUPPLY_PROP_CAPACITY_LEVEL,
POWER_SUPPLY_PROP_TEMP,
+   POWER_SUPPLY_PROP_TEMP_MAX,
+   POWER_SUPPLY_PROP_TEMP_MIN,
POWER_SUPPLY_PROP_TEMP_ALERT_MIN,
POWER_SUPPLY_PROP_TEMP_ALERT_MAX,
POWER_SUPPLY_PROP_TEMP_AMBIENT,
@@ -142,6 +145,7 @@ enum power_supply_property {
POWER_SUPPLY_PROP_TIME_TO_FULL_AVG,
POWER_SUPPLY_PROP_TYPE, /* use power_supply.type instead */
POWER_SUPPLY_PROP_SCOPE,
+   POWER_SUPPLY_PROP_CHARGE_TERM_CUR,
/* Properties of type `const char *' */
POWER_SUPPLY_PROP_MODEL_NAME,
POWER_SUPPLY_PROP_MANUFACTURER,
-- 
1.7.9.5

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

Re: [PATCH] Add HID's to hid-microsoft driver of Surface Type/Touch Cover 2 to fix bug

[Jiri Kosina]

On Tue, 21 Jan 2014, Benjamin Tissoires wrote:

> > From 291742873dcf181faf9657b41279487f31302c73 Mon Sep 17 00:00:00 2001
> > From: Reyad Attiyat 
> > Date: Tue, 21 Jan 2014 01:22:25 -0600
> > Subject: [PATCH 1/1] Added in HID's for Microsoft Surface Type/Touch cover 
> > 2.
> >  This is to fix bug 64811 where this device is detected as a multitouch 
> > device
> >
> 
> You are missing a commit message here (the first message you sent
> would fit perfectly here).

Also it's missing a Signed-off-by: line and Reyad's mail client damaged 
the patch by line-wrapping.

> So to sum up, with the commit message amended:
> Reviewed-by: Benjamin Tissoires 

Reyad, please do a full resubmission with

- proper changelog
- Signed-off-by: line added
- Benjamin's Reviewed-by: line added
- your mail client fixed so that it doesn't damage the patch

I'll then queue the patch in my tree.

Thanks,

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

Re: [PATCH v2] backlight: turn backlight on/off when necessary

[Jani Nikula]

On Mon, 20 Jan 2014, Liu Ying  wrote:
> We don't have to turn backlight on/off everytime a blanking
> or unblanking event comes because the backlight status may
> have already been what we want. Another thought is that one
> backlight device may be shared by multiple framebuffers. We
> don't hope blanking one of the framebuffers may turn the
> backlight off for all the other framebuffers, since they are
> likely being active to display something. This patch adds
> some logics to record each framebuffer's backlight usage to
> determine the backlight device use count and whether the
> backlight should be turned on or off. To be more specific,
> only one unblank operation on a certain blanked framebuffer
> may increase the backlight device's use count by one, while
> one blank operation on a certain unblanked framebuffer may
> decrease the use count by one, because the userspace is
> likely to unblank a unblanked framebuffer or blank a blanked
> framebuffer.
>
> Signed-off-by: Liu Ying 
> ---
> v1 can be found at https://lkml.org/lkml/2013/5/30/139
>
> v1->v2:
> * Make the commit message be more specific about the condition
>   in which backlight device use count can be increased/decreased.
> * Correct the setting for bd->props.fb_blank.
>
>  drivers/video/backlight/backlight.c |   28 +---
>  include/linux/backlight.h   |6 ++
>  2 files changed, 27 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/video/backlight/backlight.c 
> b/drivers/video/backlight/backlight.c
> index 5d0..42044be 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -34,13 +34,15 @@ static const char *const backlight_types[] = {
>  defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE))
>  /* This callback gets called when something important happens inside a
>   * framebuffer driver. We're looking if that important event is blanking,
> - * and if it is, we're switching backlight power as well ...
> + * and if it is and necessary, we're switching backlight power as well ...
>   */
>  static int fb_notifier_callback(struct notifier_block *self,
>   unsigned long event, void *data)
>  {
>   struct backlight_device *bd;
>   struct fb_event *evdata = data;
> + int node = evdata->info->node;
> + int fb_blank = 0;
>  
>   /* If we aren't interested in this event, skip it immediately ... */
>   if (event != FB_EVENT_BLANK && event != FB_EVENT_CONBLANK)
> @@ -51,12 +53,24 @@ static int fb_notifier_callback(struct notifier_block 
> *self,
>   if (bd->ops)
>   if (!bd->ops->check_fb ||
>   bd->ops->check_fb(bd, evdata->info)) {
> - bd->props.fb_blank = *(int *)evdata->data;
> - if (bd->props.fb_blank == FB_BLANK_UNBLANK)
> - bd->props.state &= ~BL_CORE_FBBLANK;
> - else
> - bd->props.state |= BL_CORE_FBBLANK;
> - backlight_update_status(bd);
> + fb_blank = *(int *)evdata->data;
> + if (fb_blank == FB_BLANK_UNBLANK &&
> + !bd->fb_bl_on[node]) {
> + bd->fb_bl_on[node] = true;
> + if (!bd->use_count++) {
> + bd->props.state &= ~BL_CORE_FBBLANK;
> + bd->props.fb_blank = FB_BLANK_UNBLANK;
> + backlight_update_status(bd);
> + }
> + } else if (fb_blank != FB_BLANK_UNBLANK &&
> +bd->fb_bl_on[node]) {
> + bd->fb_bl_on[node] = false;
> + if (!(--bd->use_count)) {
> + bd->props.state |= BL_CORE_FBBLANK;
> + bd->props.fb_blank = FB_BLANK_POWERDOWN;
> + backlight_update_status(bd);
> + }
> + }

Anything backlight worries me a little, and there are actually three
changes bundled into one patch here:

1. Changing bd->props.state and bd->props.fb_blank only when use_count
   changes from 0->1 or 1->0.

2. Calling backlight_update_status() only with the above change, and not
   on all notifier callbacks.

3. Setting bd->props.fb_blank always to either FB_BLANK_UNBLANK or
   FB_BLANK_POWERDOWN instead of *(int *)evdata->data.

The rationale in the commit message seems plausible, and AFAICT the code
does what it says on the box, so for that (and for that alone) you can
have my

Reviewed-by: Jani Nikula 

*BUT* it would be laborous to figure out whether this change in
behaviour might regress some drivers. I'm just punting on that. And that
brings us back to the three changes above - in a bisect POV it might be
helpful to split the 

Re: [Lsf-pc] [LSF/MM TOPIC] really large storage sectors - going beyond 4096 bytes

[Mel Gorman]

On Tue, Jan 21, 2014 at 10:04:29PM -0500, Ric Wheeler wrote:
> One topic that has been lurking forever at the edges is the current
> 4k limitation for file system block sizes. Some devices in
> production today and others coming soon have larger sectors and it
> would be interesting to see if it is time to poke at this topic
> again.
> 

Large block support was proposed years ago by Christoph Lameter
(http://lwn.net/Articles/232757/). I think I was just getting started
in the community at the time so I do not recall any of the details. I do
believe it motivated an alternative by Nick Piggin called fsblock though
(http://lwn.net/Articles/321390/). At the very least it would be nice to
know why neither were never merged for those of us that were not around
at the time and who may not have the chance to dive through mailing list
archives between now and March.

FWIW, I would expect that a show-stopper for any proposal is requiring
high-order allocations to succeed for the system to behave correctly.

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

[Bisected] qemu hangs on current git

[Markus Trippelsdorf]

On 2014.01.22 at 09:50 +0100, Markus Trippelsdorf wrote:
> On 2014.01.21 at 22:51 +0100, Markus Trippelsdorf wrote:
> > Running the current git tree (v3.13-3260-g03d11a0e458d) on the host,
> > qemu sometimes hangs during test boots of the kernel (version of the guest
> > kernel doesn't matter). This happens roughly every 4-6 runs and manifest
> > itself in hangs during the guest boot. Perf shows:
> > 
> > 31.56%  qemu-system-x86  [kernel.kallsyms][k] __srcu_read_unlock
> > 31.51%  qemu-system-x86  [kernel.kallsyms][k] __srcu_read_lock
> > 20.95%  qemu-system-x86  [kernel.kallsyms][k] 
> > kvm_arch_vcpu_ioctl_run
> >  4.72%  qemu-system-x86  [kernel.kallsyms][k] 
> > svm_complete_interrupts
> >  3.28%  qemu-system-x86  [kernel.kallsyms][k] 
> > kvm_check_async_pf_completion
> >  2.04%  qemu-system-x86  [kernel.kallsyms][k] 
> > apic_has_pending_timer
> >  1.38%  qemu-system-x86  [kernel.kallsyms][k] 
> > svm_cancel_injection
> >  1.29%  qemu-system-x86  [kernel.kallsyms][k] _cond_resched
> >  1.04%  qemu-system-x86  [kernel.kallsyms][k] kvm_resched
> >  0.66%  qemu-system-x86  [kernel.kallsyms][k] 
> > svm_prepare_guest_switch
> >  0.16%  qemu-system-x86  qemu-system-x86_64   [.] phys_page_find
> > 
> > qemu command used:
> >  % qemu-system-x86_64 -s -enable-kvm -net nic,vlan=0,model=virtio -net user 
> > -fsdev local,security_model=none,id=root,path=/ -device 
> > virtio-9p-pci,id=root,fsdev=root,mount_tag=/dev/root -m 512 -smp 2 -kernel 
> > /usr/src/linux/arch/x86/boot/bzImage -nographic -append "init=/bin/zsh 
> > root=/dev/root console=ttyS0 kgdboc=ttyS0 rootflags=rw,trans=virtio 
> > rootfstype=9p ip=dhcp earlyprintk=ttyS0"
> 
> Some more info:
> 
> [Jan22 09:45] INFO: rcu_sched self-detected stall on CPU
> [  +0.06]   0: (17999 ticks this GP) idle=def/141/0 
> softirq=2462/2462 
> [  +0.01](t=18000 jiffies g=991 c=990 q=6528)
> [  +0.02] sending NMI to all CPUs:
> [  +0.07] NMI backtrace for cpu 0
> [  +0.07] CPU: 0 PID: 705 Comm: qemu-system-x86 Not tainted 
> 3.13.0-03477-gdf32e43a54d0 #98
> [  +0.01] Hardware name: System manufacturer System Product 
> Name/M4A78T-E, BIOS 350304/13/2011
> [  +0.02] task: 8802106aed00 ti: 8800c8e24000 task.ti: 
> 8800c8e24000
> [  +0.01] RIP: 0010:[]  [] 
> __const_udelay+0x9/0x30
> [  +0.06] RSP: 0018:8800dfc03e60  EFLAGS: 0006
> [  +0.02] RAX: 0c00 RBX: 2710 RCX: 
> 0007
> [  +0.01] RDX: 00a3503e RSI: 0046 RDI: 
> 00418958
> [  +0.01] RBP: 81a1c4c0 R08: 02b0 R09: 
> 
> [  +0.01] R10:  R11: 02af R12: 
> 
> [  +0.01] R13: 81a64fd8 R14: 1980 R15: 
> 81a1c4c0
> [  +0.01] FS:  () GS:8800dfc0() 
> knlGS:
> [  +0.01] CS:  0010 DS:  ES:  CR0: 8005003b
> [  +0.01] CR2: 880001ab0ff8 CR3: 00021456c000 CR4: 
> 07f0
> [  +0.01] Stack:
> [  +0.01]  81053295 8800dfc0d4c0 810a0e17 
> 0086
> [  +0.02]  810a2976 00011a00 0086 
> 8802106aed00
> [  +0.02]     
> 8800dfc0ce78
> [  +0.02] Call Trace:
> [  +0.01]   
> 
> [  +0.04]  [] ? arch_trigger_all_cpu_backtrace+0x55/0x70
> [  +0.03]  [] ? rcu_check_callbacks+0x387/0x5e0
> [  +0.03]  [] ? update_wall_time+0x276/0x660
> [  +0.03]  [] ? update_process_times+0x49/0x80
> [  +0.02]  [] ? tick_sched_timer+0x42/0x70
> [  +0.03]  [] ? __run_hrtimer.isra.32+0x4d/0x110
> [  +0.02]  [] ? hrtimer_interrupt+0xe7/0x230
> [  +0.02]  [] ? smp_apic_timer_interrupt+0x36/0x50
> [  +0.03]  [] ? apic_timer_interrupt+0x67/0x70
> [  +0.00]   
> 
> [  +0.03]  [] ? __srcu_read_lock+0x28/0x50
> [  +0.04]  [] ? kvm_arch_vcpu_ioctl_run+0xb2c/0x1090
> [  +0.03]  [] ? pty_write+0x5c/0x60
> [  +0.03]  [] ? remove_wait_queue+0x18/0x60
> [  +0.02]  [] ? kvm_arch_vcpu_load+0x47/0x1d0
> [  +0.03]  [] ? kvm_vcpu_ioctl+0x2a2/0x530
> [  +0.03]  [] ? kvm_vm_ioctl+0x5d7/0x730
> [  +0.02]  [] ? fsnotify+0x27e/0x350
> [  +0.02]  [] ? do_vfs_ioctl+0x2d0/0x490
> [  +0.03]  [] ? __schedule+0x2a4/0x750
> [  +0.02]  [] ? SyS_ioctl+0x4d/0xa0
> [  +0.02]  [] ? system_call_fastpath+0x16/0x1b
> [  +0.01] Code: 89 07 31 c0 f3 c3 66 66 66 2e 0f 1f 84 00 00 00 00 00 48 
> 8b 05 d9 b9 83 00 ff e0 0f 1f 80 00 00 00 00 65 48 8b 14 25 20 12 01 00 <48> 
> 8d 0c 92 48 8d 04 bd
>  00 00 00 00 48 89 ca 48 c1 e2 04 48 29 
> [  +0.23] NMI backtrace for cpu 3
> [  +0.10] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 
> 3.13.0-03477-gdf32e43a54d0 #98
> [  +0.03] Hardware name: 

Re: [PATCH 0/8] Add support for PowerPC Hypervisor supplied performance counters

[Anshuman Khandual]

On 01/22/2014 07:02 AM, Michael Ellerman wrote:
> On Thu, 2014-01-16 at 15:53 -0800, Cody P Schafer wrote:
>> These patches add basic pmus for 2 powerpc hypervisor interfaces to obtain
>> performance counters: gpci ("get performance counter info") and 24x7.
>>
>> The counters supplied by these interfaces are continually counting and never
>> need to be (and cannot be) disabled or enabled. They additionally do not
>> generate any interrupts. This makes them in some regards similar to software
>> counters, and as a result their implimentation shares some common code (which
>> an initial patch exposes) with the sw counters.
> 
> Hi Cody,
> 
> Can you please add some more explanation of this series.
> 
> In particular why do we need two new PMUs, and how do they relate to each
> other?
> 
> And can you add an example of how I'd actually use them using perf.
> 

Yeah, agreed.

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

[PATCH] tty/serial: atmel_serial: remove dev_dbg in atmel_set_termios

[Nicolas Ferre]

This fixes a driver bug which stopped the whole system (in case
of serial console).
This log message is not useful anyway as this information is
printed elsewhere.

Signed-off-by: Nicolas Ferre 
---
 drivers/tty/serial/atmel_serial.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/tty/serial/atmel_serial.c 
b/drivers/tty/serial/atmel_serial.c
index a49f10d269b2..3d7206fc532f 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -1853,13 +1853,10 @@ static void atmel_set_termios(struct uart_port *port, 
struct ktermios *termios,
mode &= ~ATMEL_US_USMODE;
 
if (atmel_port->rs485.flags & SER_RS485_ENABLED) {
-   dev_dbg(port->dev, "Setting UART to RS485\n");
if ((atmel_port->rs485.delay_rts_after_send) > 0)
UART_PUT_TTGR(port,
atmel_port->rs485.delay_rts_after_send);
mode |= ATMEL_US_USMODE_RS485;
-   } else {
-   dev_dbg(port->dev, "Setting UART to RS232\n");
}
 
/* set the parity, stop bits and data size */
-- 
1.8.2.2

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

Re: [RFC] restore user defined min_free_kbytes when disabling thp

[Mel Gorman]

On Wed, Jan 22, 2014 at 02:05:06PM +0800, Han Pingtian wrote:
> On Tue, Jan 21, 2014 at 10:23:51AM +, Mel Gorman wrote:
> > On Tue, Jan 21, 2014 at 05:38:59PM +0800, Han Pingtian wrote:
> > > The testcase 'thp04' of LTP will enable THP, do some testing, then
> > > disable it if it wasn't enabled. But this will leave a different value
> > > of min_free_kbytes if it has been set by admin. So I think it's better
> > > to restore the user defined value after disabling THP.
> > > 
> > 
> > Then have LTP record what min_free_kbytes was at the same time THP was
> > enabled by the test and restore both settings. It leaves a window where
> > an admin can set an alternative value during the test but that would also
> > invalidate the test in same cases and gets filed under "don't do that".
> > 
> 
> Because the value is changed in kernel, so it would be better to 
> restore it in kernel, right? :)  I have a v2 patch which will restore
> the value only if it isn't set again by user after THP's initialization.
> This v2 patch is dependent on the patch 'mm: show message when updating
> min_free_kbytes in thp' which has been added to -mm tree, can be found
> here:
> 

It still feels like the type of scenario that only shows up during tests
that modify kernel parameters as part of the test. I do not consider it
normal operation for THP to be enabled and disabled multiple types during
the lifetime of the system. If the system started with THP disabled, ran
for a long period of time then the benefit of having min_free_kbytes at
a higher value is already lost due to the system being potentially in a
fragmented state already.

I'm ok with the warning being displayed if min_free_kbytes is updated
but I'm not convinced that further trickery is necessary.

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

[PATCH] tracing: Use task_nice() in function __update_max_tr() to get the nice value of task.

[Dongsheng Yang]

There is already a function named task_nice in sched.h to get the nice value
of task_struct. We can use it in __update_max_tr() rather than calculate it
manually.

Signed-off-by: Dongsheng Yang 
---
 kernel/trace/trace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 9d20cd9..ec149b4 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -970,7 +970,7 @@ __update_max_tr(struct trace_array *tr, struct task_struct 
*tsk, int cpu)
else
max_data->uid = task_uid(tsk);
 
-   max_data->nice = tsk->static_prio - 20 - MAX_RT_PRIO;
+   max_data->nice = task_nice(tsk);
max_data->policy = tsk->policy;
max_data->rt_priority = tsk->rt_priority;
 
-- 
1.8.2.1

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

Re: [Xen-devel] [PATCH v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN

[Ian Campbell]

On Tue, 2014-01-21 at 13:44 +, Stefano Stabellini wrote:
> Remove !GENERIC_ATOMIC64 build dependency:
> - introduce xen_atomic64_xchg
> - use it to implement xchg_xen_ulong
> 
> Remove !CPU_V6 build dependency:
> - introduce __cmpxchg8 and __cmpxchg16, compiled even ifdef
>   CONFIG_CPU_V6
> - implement sync_cmpxchg using __cmpxchg8 and __cmpxchg16
> 
> Signed-off-by: Stefano Stabellini 

Acked-by: Ian Campbell 


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

Re: [PATCH 17/24] GFS2: Use RCU/hlist_bl based hash for quotas

[Steven Whitehouse]

Hi,

On Wed, 2014-01-22 at 01:06 -0500, Sasha Levin wrote:
> On 01/22/2014 12:32 AM, Paul E. McKenney wrote:
> > On Mon, Jan 20, 2014 at 12:23:40PM +, Steven Whitehouse wrote:
> >> >Prior to this patch, GFS2 kept all the quotas for each
> >> >super block in a single linked list. This is rather slow
> >> >when there are large numbers of quotas.
> >> >
> >> >This patch introduces a hlist_bl based hash table, similar
> >> >to the one used for glocks. The initial look up of the quota
> >> >is now lockless in the case where it is already cached,
> >> >although we still have to take the per quota spinlock in
> >> >order to bump the ref count. Either way though, this is a
> >> >big improvement on what was there before.
> >> >
> >> >The qd_lock and the per super block list is preserved, for
> >> >the time being. However it is intended that since this is no
> >> >longer used for its original role, it should be possible to
> >> >shrink the number of items on that list in due course and
> >> >remove the requirement to take qd_lock in qd_get.
> >> >
> >> >Signed-off-by: Steven Whitehouse
> >> >Cc: Abhijith Das
> >> >Cc: Paul E. McKenney
> > Interesting!  I thought that Sasha Levin had a hash table in the works,
> > but I don't see it, so CCing him.
> 
> Indeed, there is a hlist based hashtable at include/linux/hashtable.h for 
> couple kernel
> versions now. However, there's no hlist_bl one.
> 
> If there is a plan on adding a hlist_bl hashtable for whatever reason, it 
> should probably
> be done by expanding hashtable.h so that more places that use hlist_bl would 
> benefit from it (yes,
> there are couple more places that do hlist_bl hashtable).
> 
> Also, do we really want to use hlist_bl here? It doesn't seem like it's being 
> done to conserve on
> memory, and that's the only reason it should be used for. Doing a single 
> spinlock per bucket is
> much more efficient than using the bit locking scheme that hlist_bl does.
> 
> 
> Thanks,
> Sasha

So this will probably make a bit more sense with a bit of history to
explain how we got here... The recent addition of the quota hash table
is modeled upon the one we are using for glocks at the moment. The glock
hash table at one stage, had one lock per bucket, and was then expanded
so that we had more buckets, but the same number of locks - to conserve
memory. It was then expanded again when we moved to hlist_bl a little
while ago. At each stage we gained performance so the changes seemed to
be a good thing.

Really the max number of glocks depends on the size of the memory, so
that we should really try to scale the hash table with increasing memory
size, however a simpler static table has worked reasonably well for now.
If we could use a tree (or forest) instead of a hash table that would be
even better, but still a bit of a pain to do with RCU I think, which is
why I've not gone that extra step yet.

Now the quota hash table has been modeled as a smaller version of the
glock hash table for the time being. The question is how large it should
be?... any more than a single hash list head is an improvement on the
previous code, and maybe the table should be larger than I've made it
currently. We'll see whether anybody runs into issues if they have large
number of quotas in due course.

So perhaps the memory saving is not the most important thing with the
quota hash table, but at least it matches in form the glock hash table
which has been proven over many releases as being effective. However, if
we can make use of some generic code that solves many of the problems
for us, then I can certainly look into that.

The changes in the quota code are not complete yet, and with a bit of
luck we'll have a further set of changes ready for the next merge window
too,

Steve.


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

Re: [PATCH 01/73] init: delete the __cpuinit related stubs

[Paul Gortmaker]

On 1/21/14, Paul Gortmaker  wrote:
> The __cpuinit support was removed several releases ago.  People
> have had a chance to update their out of tree code, so now we
> remove the no-op stubs.
>
> Also delete the mention of __cpuinitdata from the tag script.
>
> Cc: Andrew Morton 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Paul Gortmaker 
> ---
>  include/linux/init.h | 11 ---
>  scripts/tags.sh  |  2 +-
>  2 files changed, 1 insertion(+), 12 deletions(-)
>  mode change 100755 => 100644 scripts

Odd.  I definitely did not chmod -x this file manually.
Wonder how that happened?  Will fix...

Paul.
--

>
> diff --git a/include/linux/init.h b/include/linux/init.h
> index e168880..f693cc3 100644
> --- a/include/linux/init.h
> +++ b/include/linux/init.h
> @@ -91,14 +91,6 @@
>
>  #define __exit  __section(.exit.text) __exitused __cold notrace
>
> -/* temporary, until all users are removed */
> -#define __cpuinit
> -#define __cpuinitdata
> -#define __cpuinitconst
> -#define __cpuexit
> -#define __cpuexitdata
> -#define __cpuexitconst
> -
>  /* Used for MEMORY_HOTPLUG */
>  #define __meminit__section(.meminit.text) __cold notrace
>  #define __meminitdata__section(.meminit.data)
> @@ -116,9 +108,6 @@
>  #define __INITRODATA .section".init.rodata","a",%progbits
>  #define __FINITDATA  .previous
>
> -/* temporary, until all users are removed */
> -#define __CPUINIT
> -
>  #define __MEMINIT.section".meminit.text", "ax"
>  #define __MEMINITDATA.section".meminit.data", "aw"
>  #define __MEMINITRODATA  .section".meminit.rodata", "a"
> diff --git a/scripts/tags.sh b/scripts/tags.sh
> old mode 100755
> new mode 100644
> index 58c4559..78382c2
> --- a/scripts/tags.sh
> +++ b/scripts/tags.sh
> @@ -150,7 +150,7 @@ exuberant()
>  {
>   all_target_sources | xargs $1 -a\
>   -I __initdata,__exitdata,__initconst,   \
> - -I __cpuinitdata,__initdata_memblock\
> + -I __initdata_memblock  \
>   -I __refdata,__attribute,__maybe_unused,__always_unused \
>   -I __acquires,__releases,__deprecated   \
>   -I __read_mostly,__aligned,cacheline_aligned\
> --
> 1.8.4.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arch" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Regression on next-20140116 [Was: [PATCH 3/3 v4] usb: chipidea: hw_phymode_configure moved before ci_usb_phy_init]

[Uwe Kleine-König]

Hello,

On Tue, Dec 03, 2013 at 04:01:50PM +0800, Chris Ruehl wrote:
> usb: chipidea: hw_phymode_configure moved before ci_usb_phy_init
> hw_phymode_configure configures the PORTSC registers and allow the
> following phy_inits to operate on the right parameters. This fix a problem
> where the UPLI (ISP1504) could not detected, because the Viewport was not
> available and read the viewport return 0's only.
This patch (or a later revision of it to be more exact) made it into
mainline as cd0b42c2a6d2.

On an i.MX27 based machine I'm hitting an oops (see below) on
next-20140116 + a few patches. (I didn't switch to 3.13+ yet, as I think
not everything I need has landed there.) The oops goes away (and still
better, lsusb reports my connected devices instead of "unable to
initialize libusb: -99") when I do at least one of the following:

 - set CONFIG_USB_CHIPIDEA=y instead of =m
 - revert commit
  cd0b42c2a6d2 (usb: chipidea: put hw_phymode_configure before 
ci_usb_phy_init)

The few patches I mentioned above are:
- device tree stuff to support my machine inclusive pinmuxing
- ulpi and cs support for drivers/usb/phy/phy-generic.c
  (I got these from Chris Ruehl by PM, don't know if they were sent
  out in public already.)

Unhandled fault: external abort on non-linefetch (0x808) at 0xf4424584
Internal error: : 808 [#1] PREEMPT ARM
Modules linked in: ci_hdrc_imx(+) ci_hdrc ehci_hcd usbcore usb_common 
usbmisc_imx
CPU: 0 PID: 354 Comm: systemd-udevd Not tainted 
3.13.0-rc8-next-20140116-5-gf6e6ae599f37 #45
task: c389e0e0 ti: c3ab task.ti: c3ab
PC is at ci_hdrc_probe+0x320/0x794 [ci_hdrc]
LR is at ci_hdrc_probe+0x310/0x794 [ci_hdrc]
pc : []lr : []psr: 6013
sp : c3ab1c48  ip : c041f1fc  fp : c3ab0030
r10: c3b2b9c0  r9 : c3a97000  r8 : 4000
r7 : 8c000400  r6 :   r5 : c3a97010  r4 : c3a14010
r3 : f4424584  r2 :   r1 : 0004  r0 : 0024
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 0005317f  Table: a3ac8000  DAC: 0015
Process systemd-udevd (pid: 354, stack limit = 0xc3ab01c0)
Stack: (0xc3ab1c48 to 0xc3ab2000)
1c40:   d200 8000 c3a97010 bf08b734 bf08b734 c389dc10
1c60: c0876958  c388d9c0 c01777b8 c01777a0 c3a97010  c0176440
1c80:  c3a97010 c0176588 c389dc10  c0174d74 c38214d8 c39c5454
1ca0: c3a97010 c3a97044 c3a97010 c017635c c3a97010 c036c638 c3a97010 c0175a60
1cc0: c3a97010 c3a97018  c01741ac  0002 c3ab0030 c0248f10
1ce0: c035d1fc c3a97000 0002 001c c3ab1d44  0002 c0177628
1d00: 10024400   c3a97000 c3ab1d44 bf089c84 c389dc10 c3ad19b0
1d20: c389dc00   bf099610  bf0992e0 c3ab1d68 
1d40: c00e6638 bf099614 0100  c388b990 0003 000a 0001
1d60:   c3f79604 0001 0002 0004 c3ad2dc0 c02e57da
1d80: c388f948 c3ad2d10 0001 0001 c389dc10 bf0997b8 bf0997b8 
1da0: c0876958 0001  c01777b8 c01777a0 c389dc10  c0176440
1dc0: c389dc10 c389dc44 bf0997b8  bf09b000 c017663c  bf0997b8
1de0: c01765cc c0174cd8 c38214a8 c3894750 bf0997b8 c39c5280 c036c638 c0175ca0
1e00: bf099778 0350  bf0997b8 0001 bf0997fc c3a386c0 c0176a30
1e20:  c3ab1f58 0001 c0008910 c3ab0010 0001 c0248a68 0001
1e40: 0001 c3a386f0 c086ad71 c0042c8c 6013 c0361198  bf0997fc
1e60: c086ad71 c0248a74 c03611b8 c0361194  c0037014  0001
1e80: c3ab1f58 c3ab1f58 0001 bf0997fc c3a386c0 bf099844 0001 c3a386f0
1ea0: c086ad71 c0061764 bf099808 7fff c005f2f4 bf00  c005f480
1ec0:  bf099808 c3ab0028 bf09993c  c49a81a8 c3ab1eec b6eb68b4
1ee0: c49a7000 1c74 007c1889  000c   
1f00:        
1f20:     0010  b6eb68b4 0006
1f40: 017b c000dda4 c3ab  00587ca8 c0061e54 c49a7000 1c74
1f60: c49a7cd0 c49a7b79 c49a8718 094c 0aac   
1f80: 001f 0020 0016  0012  0002 
1fa0:  c000dbe0 0002  0006 b6eb68b4  
1fc0: 0002   017b   0002d208 00587ca8
1fe0: bebd4ad8 bebd4ac8 b6eaec0c b6e2ca40 6010 0006 0a6f e5d30014
[] (ci_hdrc_probe [ci_hdrc]) from [] 
(platform_drv_probe+0x18/0x48)
[] (platform_drv_probe) from [] 
(driver_probe_device+0xb0/0x1f8)
[] (driver_probe_device) from [] 
(bus_for_each_drv+0x74/0x88)
[] (bus_for_each_drv) from [] (device_attach+0x6c/0x84)
[] (device_attach) from [] (bus_probe_device+0x28/0xa0)
[] (bus_probe_device) from [] (device_add+0x3f8/0x4d4)
[] (device_add) from [] (platform_device_add+0x128/0x1bc)
[] (platform_device_add) from [] 
(ci_hdrc_add_device+0x104/0x140 [ci_hdrc])
[] (ci_hdrc_add_device [ci_hdrc]) from 

[BUG] sched_clock: wrong printk time stamp

[Dave Young]

Hi,

With today's Linus tree, the printk time is very odd, see below
qemu/efi boot log:
[0.00] ACPI: FACS 1f9e4000 40
[0.00] ACPI: APIC 1f9dd000 78 (v01 OVMF   OVMFEDK2 20130221 
OVMF 0099)
[0.00] ACPI: SSDT 1f9db000 57 (v01 REDHAT OVMF 0001 
INTL 20120913)
[0.00] ACPI: Local APIC address 0xfee0
[0.00] Reserving 128MB of memory at 320MB for crashkernel (System RAM: 
510MB)
[0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00
[0.00] kvm-clock: cpu 0, msr 0:1f801001, boot clock
[ 1592.120520]  [ea00-ea7f] PMD -> 
[88001380-880013ff] on node 0
[ 1592.120526] Zone ranges:
[ 1592.121922]   DMA  [mem 0x1000-0x00ff]
[ 1592.124493]   DMA32[mem 0x0100-0x]
[ 1592.127056]   Normal   empty
[ 1592.128581] Movable zone start for each node

The previous normal log:
[0.00] ACPI: FACS 0d5e4000 40
[0.00] ACPI: APIC 0d5dd000 78 (v01 OVMF   OVMFEDK2 20130221 
OVMF 0099)
[0.00] ACPI: SSDT 0d5db000 57 (v01 REDHAT OVMF 0001 
INTL 20120913)
[0.00] crashkernel reservation failed - No suitable area found.
[0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00
[0.00] kvm-clock: cpu 0, msr 0:d401001, boot clock
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x1000-0x00ff]
[0.00]   DMA32[mem 0x0100-0x]
[0.00]   Normal   empty
[0.00] Movable zone start for each node
[snip]
[0.00] ... MAX_LOCKDEP_CHAINS:  32768
[0.00] ... CHAINHASH_SIZE:  16384
[0.00]  memory used by lock dependency info: 5855 kB
[0.00]  per task-struct memory footprint: 1920 bytes
[0.00] tsc: Detected 2793.268 MHz processor
[0.00] Calibrating delay loop (skipped) preset value.. 5588.30 BogoMIPS 
(lpj=9310893)
[0.010010] pid_max: default: 32768 minimum: 301
[0.013381] init_memory_mapping: [mem 0x0bd94000-0x0bd95fff]
[0.016707] init_memory_mapping: [mem 0x0bd96000-0x0bdabfff]
[0.020019] init_memory_mapping: [mem 0x0bdac000-0x0bdc0fff]
[0.023206] init_memory_mapping: [mem 0x0d581000-0x0d5b0fff]


I bisected the problem, it results from below commit, probably
local_irq should be still disabled?

-bash-4.2$ git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[ef08f0fff87630d4f67ceb09514d8b444df833f8] sched/clock: Remove 
local_irq_disable() from the clocks

Note: for the last several build steps I need manually revert
9ea4c380066fbe23fe0da7f4abfabc444f2467f4 or build will fail.

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

Re: [PATCH RFC 4/6] net: rfkill: gpio: add device tree support

[Linus Walleij]

On Tue, Jan 21, 2014 at 3:53 PM, Alexandre Courbot  wrote:
> On Tue, Jan 21, 2014 at 9:35 PM, Arnd Bergmann  wrote:
>> On Tuesday 21 January 2014, Linus Walleij wrote:

>>> As discussed earlier in this thread I'm not sure the con_id is
>>> suitable for labelling GPIOs. It'd be better to have a proper name
>>> specified in DT/ACPI instead.
>>
>> +1
>
> I wonder why you guys prefer to have the name defined in the GPIO
> mapping. Having the driver decide the label makes it easier to look up
> which GPIO does what in debugfs, whereas nothing prevents people to
> name GPIOs whatever inadequate name they want in the device DT node.
> What am I overlooking here?

The proper name of a GPIO does not come from the driver but from the
usecase, i.e. often the name of the rail on the board where it is used.

Remember GPIO are per definition general purpose, they cannot get
any clever names from the driver. They would just be named
"chip-foo-gpio0" thru "chip-foo-gpioN" if the driver was to name them.

Using the rail name on the board is way more useful. A GPIO line
named "HAL_SENSOR" or "MMC_CD" is actually telling us what
that line is used for.

But such names can only come from a DT or ACPI table that has
knowledge of how the GPIO is used on a certain system/board and
not just from the driver.

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

Re: [PATCH RFC 4/6] net: rfkill: gpio: add device tree support

[Linus Walleij]

On Tue, Jan 21, 2014 at 3:53 PM, Alexandre Courbot  wrote:

> The good (or bad, rather) thing about DT is that we can do whatever we
> please with the new bindings: decide which name or which index
> (doesn't matter here) a GPIO should have. However we don't have this
> control over ACPI, where nothing guarantees that the same index will
> be used for the same GPIO function.

It's not like ACPI will impose some tables on us and expect us to
use them as-is no matter how crazy they are. Then indeed the whole
idea of unifying ACPI and DT accessors would be moot and it would
only work by mistake or as a good joke.

The situation with ACPI is just like with DT, it is assumed that the
author of these tables also look at the Linux kernel drivers to figure
out what argument goes where and we can influence them.

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

Re: [PATCH 17/24] GFS2: Use RCU/hlist_bl based hash for quotas

[Steven Whitehouse]

Hi,

On Tue, 2014-01-21 at 21:32 -0800, Paul E. McKenney wrote:
> On Mon, Jan 20, 2014 at 12:23:40PM +, Steven Whitehouse wrote:
> > Prior to this patch, GFS2 kept all the quotas for each
> > super block in a single linked list. This is rather slow
> > when there are large numbers of quotas.
> > 
> > This patch introduces a hlist_bl based hash table, similar
> > to the one used for glocks. The initial look up of the quota
> > is now lockless in the case where it is already cached,
> > although we still have to take the per quota spinlock in
> > order to bump the ref count. Either way though, this is a
> > big improvement on what was there before.
> > 
> > The qd_lock and the per super block list is preserved, for
> > the time being. However it is intended that since this is no
> > longer used for its original role, it should be possible to
> > shrink the number of items on that list in due course and
> > remove the requirement to take qd_lock in qd_get.
> > 
> > Signed-off-by: Steven Whitehouse 
> > Cc: Abhijith Das 
> > Cc: Paul E. McKenney 
> 
> Interesting!  I thought that Sasha Levin had a hash table in the works,
> but I don't see it, so CCing him.
> 
> A few questions and comments below.
> 
>   Thanx, Paul
> 
Thanks for the review.

[snip]
> > +#define GFS2_QD_HASH_SHIFT  12

> Should this be a function of the number of CPUs?  (Might not be an issue
> if the really big systems don't use GFS.)

I'm not sure... really it depends on how many quotas are in use, so
number of users, and even on relatively small systems, there might be a
lot of them. So I'm guessing a bit, and we'll bump it up a bit if its a
problem. There is a lot of extra complexity in changing hash table sizes
on the fly, which would be another possible solution. Either way it is a
vast improvement on what was there before :-)

[snip] 
> > + if (!qid_eq(qd->qd_id, qid))
> > + continue;
> > + if (qd->qd_sbd != sdp)
> > + continue;
> > + if (lockref_get_not_dead(>qd_lockref)) {
> > + list_lru_del(_qd_lru, >qd_lru);

> list_lru_del() acquires a lock, but it is from an array whose size
> depends on the NODES_SHIFT Kconfig variable.  The array size seems to
> vary from 8 to 16 to 64 to 1024, depending on other configuration info,
> so should be OK.

Yes, we've tried to make use of the generic lru code here, and I'd like
to do that same for the glocks, however thats more complicated, so we've
not got that far just yet, even though we have made some steps in that
direction. Dave Chinner has pointed out to us that the lru code was
designed such that the lru lock should always be the inner most lock, so
thats the ordering that we've used here.

[snip]
> > @@ -1335,11 +1394,16 @@ void gfs2_quota_cleanup(struct gfs2_sbd *sdp)
> > spin_unlock(>qd_lockref.lock);
> > 
> > list_del(>qd_list);
> > +
> > /* Also remove if this qd exists in the reclaim list */
> > list_lru_del(_qd_lru, >qd_lru);
> > atomic_dec(>sd_quota_count);
> > spin_unlock(_lock);
> > 
> > +   spin_lock_bucket(qd->qd_hash);
> > +   hlist_bl_del_rcu(>qd_hlist);
> 
> Might just be my unfamiliarity with this code, but it took me a bit
> to see the difference between ->qd_hlist and ->qd_list.  Of course, until
> I spotted the difference, I was wondering why you were removing the
> item twice.  ;-)
> 
Well I hope that eventually qd_list might be able to go away. I'm still
working on a plan to deal with improving the quota data writeback which
should help to make that happen,

Steve.


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

Re: [PATCH-v2 10/17] target: Add protection SGLs to target_submit_cmd_map_sgls

[Sagi Grimberg]

On 1/22/2014 12:17 AM, Nicholas A. Bellinger wrote:

On Sun, 2014-01-19 at 14:12 +0200, Sagi Grimberg wrote:

On 1/19/2014 4:44 AM, Nicholas A. Bellinger wrote:

From: Nicholas Bellinger 

This patch adds support to target_submit_cmd_map_sgls() for
accepting 'sgl_prot' + 'sgl_prot_count' parameters for
DIF protection information.

Note the passed parameters are stored at se_cmd->t_prot_sg
and se_cmd->t_prot_nents respectively.

Also, update tcm_loop and vhost-scsi fabrics usage of
target_submit_cmd_map_sgls() to take into account the
new parameters.

I didn't see that you added protection allocation to transports that
does not use
target_submit_cmd_map_sgls() - which happens to be iSCSI/iSER/SRP :(

Don't you think that prot SG allocation should be added also to
target_alloc_sgl()? by then
se_cmd should contain the protection attributes and this routine can
know if it needs to
allocate prot_sg as well. This is how I used it...

Yes, this specific bit was left out for the moment as no code in the
patch for v3.14 actually uses it..

I'm planning to add it to for-next -> v3.15 code as soon as the merge
window closes.

--nab



Yes, that makes sense to me.

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

Re: [PATCH-v2 11/17] target/iblock: Add blk_integrity + BIP passthrough support

[Sagi Grimberg]

On 1/22/2014 3:52 AM, Martin K. Petersen wrote:

"Sagi" == Sagi Grimberg  writes:

Sagi> Please remind me why we ignore IP-CSUM guard type again?  MKP,
Sagi> will this be irrelevant for the initiator as well? if so, I don't
Sagi> see a reason to expose this in RDMA verbs.

I don't see much use for IP checksum for the target. You are required by
SBC to use T10 CRC on the wire so there is no point in converting to IP
checksum in the backend.

My impending patches will allow you to pass through PI with T10 CRC to a
device with an IP checksum block integrity profile (i.e. the choice of
checksum is a per-bio bip flag instead of an HBA-enforced global).



OK, so IP checksum support still makes sense.

Thanks!

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

Re: [PATCH] sched: fix sched_entity avg statistics update

[Chris Redpath]

On 21/01/14 16:12, Vincent Guittot wrote:

With the current implementation, the load average statistics of a sched entity
change according to other activity on the CPU even if this activity is done
between the running window of the sched entity and have no influence on the
running duration of the task.

When a task wakes up on the same CPU, we currently update last_runnable_update
with the return  of __synchronize_entity_decay without updating the
runnable_avg_sum and runnable_avg_period accordingly. In fact, we have to sync
the load_contrib of the se with the rq's blocked_load_contrib before removing
it from the latter (with __synchronize_entity_decay) but we must keep
last_runnable_update unchanged for updating runnable_avg_sum/period during the
next update_entity_load_avg.

Signed-off-by: Vincent Guittot 
---
  kernel/sched/fair.c |3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index e64b079..5b0ef90 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2370,8 +2370,7 @@ static inline void enqueue_entity_load_avg(struct cfs_rq 
*cfs_rq,
 * would have made count negative); we must be careful to avoid
 * double-accounting blocked time after synchronizing decays.
 */
-   se->avg.last_runnable_update += __synchronize_entity_decay(se)
-   << 20;
+   __synchronize_entity_decay(se);
}

/* migrated tasks did not contribute to our blocked load */



I've noticed this problem too. It becomes more apparent if you are 
closely inspecting load signals and comparing against ideal signals 
generated from task runtime traces. IMO it should be fixed.


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

Re: [PATCH-v2 12/17] target/file: Add DIF protection init/format support

[Sagi Grimberg]

On 1/22/2014 12:28 AM, Nicholas A. Bellinger wrote:

On Sun, 2014-01-19 at 14:31 +0200, Sagi Grimberg wrote:

On 1/19/2014 4:44 AM, Nicholas A. Bellinger wrote:

From: Nicholas Bellinger 

This patch adds support for DIF protection init/format support into
the FILEIO backend.

It involves using a seperate $FILE.protection for storing PI that is
opened via fd_init_prot() using the common pi_prot_type attribute.
The actual formatting of the protection is done via fd_format_prot()
using the common pi_prot_format attribute, that will populate the
initial PI data based upon the currently configured pi_prot_type.

Based on original FILEIO code from Sagi.

Nice! see comments below...


v1 changes:
- Fix sparse warnings in fd_init_format_buf (Fengguang)

Cc: Martin K. Petersen 
Cc: Christoph Hellwig 
Cc: Hannes Reinecke 
Cc: Sagi Grimberg 
Cc: Or Gerlitz 
Signed-off-by: Nicholas Bellinger 
---
   drivers/target/target_core_file.c |  137 
+
   drivers/target/target_core_file.h |4 ++
   2 files changed, 141 insertions(+)

diff --git a/drivers/target/target_core_file.c 
b/drivers/target/target_core_file.c
index 0e34cda..119d519 100644
--- a/drivers/target/target_core_file.c
+++ b/drivers/target/target_core_file.c
@@ -700,6 +700,140 @@ static sector_t fd_get_blocks(struct se_device *dev)
   dev->dev_attrib.block_size);
   }
   
+static int fd_init_prot(struct se_device *dev)

+{
+   struct fd_dev *fd_dev = FD_DEV(dev);
+   struct file *prot_file, *file = fd_dev->fd_file;
+   struct inode *inode;
+   int ret, flags = O_RDWR | O_CREAT | O_LARGEFILE | O_DSYNC;
+   char buf[FD_MAX_DEV_PROT_NAME];
+
+   if (!file) {
+   pr_err("Unable to locate fd_dev->fd_file\n");
+   return -ENODEV;
+   }
+
+   inode = file->f_mapping->host;
+   if (S_ISBLK(inode->i_mode)) {
+   pr_err("FILEIO Protection emulation only supported on"
+  " !S_ISBLK\n");
+   return -ENOSYS;
+   }
+
+   if (fd_dev->fbd_flags & FDBD_HAS_BUFFERED_IO_WCE)
+   flags &= ~O_DSYNC;
+
+   snprintf(buf, FD_MAX_DEV_PROT_NAME, "%s.protection",
+fd_dev->fd_dev_name);
+
+   prot_file = filp_open(buf, flags, 0600);
+   if (IS_ERR(prot_file)) {
+   pr_err("filp_open(%s) failed\n", buf);
+   ret = PTR_ERR(prot_file);
+   return ret;
+   }
+   fd_dev->fd_prot_file = prot_file;
+
+   return 0;
+}
+
+static void fd_init_format_buf(struct se_device *dev, unsigned char *buf,
+  u32 unit_size, u32 *ref_tag, u16 app_tag,
+  bool inc_reftag)
+{
+   unsigned char *p = buf;
+   int i;
+
+   for (i = 0; i < unit_size; i += dev->prot_length) {
+   *((u16 *)[0]) = 0x;
+   *((__be16 *)[2]) = cpu_to_be16(app_tag);
+   *((__be32 *)[4]) = cpu_to_be32(*ref_tag);
+
+   if (inc_reftag)
+   (*ref_tag)++;
+
+   p += dev->prot_length;
+   }
+}
+
+static int fd_format_prot(struct se_device *dev)
+{
+   struct fd_dev *fd_dev = FD_DEV(dev);
+   struct file *prot_fd = fd_dev->fd_prot_file;
+   sector_t prot_length, prot;
+   unsigned char *buf;
+   loff_t pos = 0;
+   u32 ref_tag = 0;
+   int unit_size = FDBD_FORMAT_UNIT_SIZE * dev->dev_attrib.block_size;
+   int rc, ret = 0, size, len;
+   bool inc_reftag = false;
+
+   if (!dev->dev_attrib.pi_prot_type) {
+   pr_err("Unable to format_prot while pi_prot_type == 0\n");
+   return -ENODEV;
+   }
+   if (!prot_fd) {
+   pr_err("Unable to locate fd_dev->fd_prot_file\n");
+   return -ENODEV;
+   }
+
+   switch (dev->dev_attrib.pi_prot_type) {

redundant - see below.

+   case TARGET_DIF_TYPE3_PROT:
+   ref_tag = 0x;
+   break;
+   case TARGET_DIF_TYPE2_PROT:
+   case TARGET_DIF_TYPE1_PROT:
+   inc_reftag = true;
+   break;
+   default:
+   break;
+   }
+
+   buf = vzalloc(unit_size);
+   if (!buf) {
+   pr_err("Unable to allocate FILEIO prot buf\n");
+   return -ENOMEM;
+   }
+
+   prot_length = (dev->transport->get_blocks(dev) + 1) * dev->prot_length;
+   size = prot_length;
+
+   pr_debug("Using FILEIO prot_length: %llu\n",
+(unsigned long long)prot_length);
+
+   for (prot = 0; prot < prot_length; prot += unit_size) {
+
+   fd_init_format_buf(dev, buf, unit_size, _tag, 0x,
+  inc_reftag);

I didn't send you my latest patches (my fault...).T10-PI format should
only place
escape values throughout the protection file (fill it with 0xff). so I
guess in this case
fd_init_formast_buf() boils down to memset(buf, 0xff, unit_size) once
before 

Re: linux-next: manual merge of the drm-intel tree with the drm tree

[Daniel Vetter]

Hi Stephen,

On Wed, Jan 22, 2014 at 4:04 AM, Stephen Rothwell  wrote:
> Hi all,
>
> Today's linux-next merge of the drm-intel tree got a conflict in
> drivers/gpu/drm/i915/i915_irq.c between commit abca9e454498 ("drm: Pass
> 'flags' from the caller to .get_scanout_position()") from the drm tree
> and commit d59a63ad8234 ("drm/i915: Add intel_get_crtc_scanline()") from
> the drm-intel tree.
>
> I fixed it up (I think - see below) and can carry the fix as necessary
> (no action is required).

Oops, this patch escaped - it's only for 3.15. I've shuffled my
branches around now for the merge window so this should not pop up in
your -next tree again until 3.15 starts.

Yours, Daniel

>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> diff --cc drivers/gpu/drm/i915/i915_irq.c
> index 17d8fcb1b6f7,ffb56a9db9cc..
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@@ -649,8 -675,9 +649,9 @@@ static bool ilk_pipe_in_vblank_locked(s
>   }
>
>   static int i915_get_crtc_scanoutpos(struct drm_device *dev, int pipe,
>  -  int *vpos, int *hpos,
>  +  unsigned int flags, int *vpos, int *hpos,
> -   ktime_t *stime, ktime_t *etime)
> +   ktime_t *stime, ktime_t *etime,
> +   bool adjust)
>   {
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct drm_crtc *crtc = dev_priv->pipe_to_crtc_mapping[pipe];
> @@@ -788,6 -786,24 +791,24 @@@
> return ret;
>   }
>
> + static int i915_get_scanout_position(struct drm_device *dev, int pipe,
> +int *vpos, int *hpos,
> +ktime_t *stime, ktime_t *etime)
> + {
>  -  return i915_get_crtc_scanoutpos(dev, pipe, vpos, hpos,
> ++  return i915_get_crtc_scanoutpos(dev, pipe, 0, vpos, hpos,
> +   stime, etime, true);
> + }
> +
> + int intel_get_crtc_scanline(struct drm_crtc *crtc)
> + {
> +   int vpos = 0, hpos = 0;
> +
>  -  i915_get_crtc_scanoutpos(crtc->dev, to_intel_crtc(crtc)->pipe,
> ++  i915_get_crtc_scanoutpos(crtc->dev, to_intel_crtc(crtc)->pipe, 0,
> +, , NULL, NULL, false);
> +
> +   return vpos;
> + }
> +
>   static int i915_get_vblank_timestamp(struct drm_device *dev, int pipe,
>   int *max_error,
>   struct timeval *vblank_time,



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 2/2] usb: dwc3: adapt dwc3 core to use Generic PHY Framework

[Kishon Vijay Abraham I]

On Wednesday 22 January 2014 01:29 PM, Roger Quadros wrote:
> On 01/22/2014 08:04 AM, Vivek Gautam wrote:
>> Hi,
>>
>>
>> On Tue, Jan 21, 2014 at 7:30 PM, Roger Quadros  wrote:
>>> Hi Kishon,
>>>
>>> On 01/21/2014 12:11 PM, Kishon Vijay Abraham I wrote:
 Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
 power_on and power_off the following APIs are used phy_init(), phy_exit(),
 phy_power_on() and phy_power_off().

 However using the old USB phy library wont be removed till the PHYs of all
 other SoC's using dwc3 core is adapted to the Generic PHY Framework.

 Signed-off-by: Kishon Vijay Abraham I 
 ---
 Changes from v3:
 * avoided using quirks

  Documentation/devicetree/bindings/usb/dwc3.txt |6 ++-
  drivers/usb/dwc3/core.c|   60 
 
  drivers/usb/dwc3/core.h|7 +++
  3 files changed, 71 insertions(+), 2 deletions(-)

 diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
 b/Documentation/devicetree/bindings/usb/dwc3.txt
 index e807635..471366d 100644
 --- a/Documentation/devicetree/bindings/usb/dwc3.txt
 +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
 @@ -6,11 +6,13 @@ Required properties:
   - compatible: must be "snps,dwc3"
   - reg : Address and length of the register set for the device
   - interrupts: Interrupts used by the dwc3 controller.
 +
 +Optional properties:
   - usb-phy : array of phandle for the PHY device.  The first element
 in the array is expected to be a handle to the USB2/HS PHY and
 the second element is expected to be a handle to the USB3/SS PHY
 -
 -Optional properties:
 + - phys: from the *Generic PHY* bindings
 + - phy-names: from the *Generic PHY* bindings
   - tx-fifo-resize: determines if the FIFO *has* to be reallocated.

  This is usually a subnode to DWC3 glue to which it is connected.
 diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
 index e009d4e..036d589 100644
 --- a/drivers/usb/dwc3/core.c
 +++ b/drivers/usb/dwc3/core.c
 @@ -82,6 +82,11 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)

   usb_phy_init(dwc->usb2_phy);
   usb_phy_init(dwc->usb3_phy);
 + if (dwc->usb2_generic_phy)
 + phy_init(dwc->usb2_generic_phy);
>>>
>>> What if phy_init() fails? You need to report and fail. Same applies for all 
>>> PHY apis in this patch.
>>>
 + if (dwc->usb3_generic_phy)
 + phy_init(dwc->usb3_generic_phy);
 +
   mdelay(100);

   /* Clear USB3 PHY reset */
 @@ -343,6 +348,11 @@ static void dwc3_core_exit(struct dwc3 *dwc)
  {
   usb_phy_shutdown(dwc->usb2_phy);
   usb_phy_shutdown(dwc->usb3_phy);
 + if (dwc->usb2_generic_phy)
 + phy_exit(dwc->usb2_generic_phy);
 + if (dwc->usb3_generic_phy)
 + phy_exit(dwc->usb3_generic_phy);
 +
  }

  #define DWC3_ALIGN_MASK  (16 - 1)
 @@ -433,6 +443,32 @@ static int dwc3_probe(struct platform_device *pdev)
   }
   }

 + dwc->usb2_generic_phy = devm_phy_get(dev, "usb2-phy");
 + if (IS_ERR(dwc->usb2_generic_phy)) {
 + ret = PTR_ERR(dwc->usb2_generic_phy);
 + if (ret == -ENOSYS || ret == -ENODEV) {
 + dwc->usb2_generic_phy = NULL;
 + } else if (ret == -EPROBE_DEFER) {
 + return ret;
 + } else {
 + dev_err(dev, "no usb2 phy configured\n");
 + return ret;
 + }
 + }
 +
 + dwc->usb3_generic_phy = devm_phy_get(dev, "usb3-phy");
 + if (IS_ERR(dwc->usb3_generic_phy)) {
 + ret = PTR_ERR(dwc->usb3_generic_phy);
 + if (ret == -ENOSYS || ret == -ENODEV) {
 + dwc->usb3_generic_phy = NULL;
 + } else if (ret == -EPROBE_DEFER) {
 + return ret;
 + } else {
 + dev_err(dev, "no usb3 phy configured\n");
 + return ret;
 + }
 + }
 +
   dwc->xhci_resources[0].start = res->start;
   dwc->xhci_resources[0].end = dwc->xhci_resources[0].start +
   DWC3_XHCI_REGS_END;
 @@ -482,6 +518,11 @@ static int dwc3_probe(struct platform_device *pdev)
   usb_phy_set_suspend(dwc->usb2_phy, 0);
   usb_phy_set_suspend(dwc->usb3_phy, 0);

 + if (dwc->usb2_generic_phy)
 + phy_power_on(dwc->usb2_generic_phy);
 + if (dwc->usb3_generic_phy)
 + phy_power_on(dwc->usb3_generic_phy);
 +
>>>
>>> Is it OK to power on the phy before