[PATCH v5 00/10] Fixes and new clocks support for Mediatek MT8173

[James Liao]

This patchset is based on 4.2-rc1 and [1], and contains minor fixes and
subsystem clocks support for Mediatek MT8173.

The previous reviews can be found in [2]. The most different from previous
patchset are adding separated patches for minor coding fixes, and refining
USB clock implementation by removing mtk_clk_register_apmixed_ex().

changes since v4:
- Add a separated patch to remove unused dpi_ck.
- Add separated patches to fix clk/mediatek in release 4.2-rc1.
- Add __init* for initialization data and functions.
- Rename dummy_clk with oscillator in DT.
- Remove mtk_clk_register_apmixed_ex(), call mtk_clk_register_ref2usb_tx()
  directly to register USB clock.

changes since v3:
- Remove clk_null dependency from root clocks.
- Use fixed-rate clocks with typical rate to replace clk_null.
- Separate ref2usb_tx implementation to clk-apmixed.c
- Use clock-controller as the name of clock providers.

changes since v2:
- Rebase to 4.2-rc1.
- Add device tree nodes for subsystem clocks.
- Fine tune comments of patches.
- Add __init, __initconst and const to init data and functions.
- Removed unused code from init functions of subsystem clocks.

changes since v1:
- Add CA7PLL and CA15PLL as critical clocks.
- Use the same register descriptor for imgsys, vensys and vencltsys.
- Generalize apmixedsys special clocks registration.

[1] https://patchwork.kernel.org/patch/6446341/
[2] https://lkml.org/lkml/2015/7/23/911

James Liao (9):
  clk: mediatek: Removed unused dpi_ck clock from MT8173
  clk: mediatek: Remove unused code from MT8173.
  clk: mediatek: Add __initdata and __init for data and functions
  clk: mediatek: Add fixed clocks support for Mediatek SoC.
  clk: mediatek: Fix rate and dependency of MT8173 clocks
  dt-bindings: ARM: Mediatek: Document devicetree bindings for clock
controllers
  clk: mediatek: Add subsystem clocks of MT8173
  clk: mediatek: Add USB clock support in MT8173 APMIXEDSYS
  arm64: dts: mt8173: Add subsystem clock controller device nodes

Sascha Hauer (1):
  clk: mediatek: mt8173: Fix enabling of critical clocks

 .../bindings/arm/mediatek/mediatek,imgsys.txt  |  22 ++
 .../bindings/arm/mediatek/mediatek,mmsys.txt   |  22 ++
 .../bindings/arm/mediatek/mediatek,vdecsys.txt |  22 ++
 .../bindings/arm/mediatek/mediatek,vencltsys.txt   |  22 ++
 .../bindings/arm/mediatek/mediatek,vencsys.txt |  22 ++
 arch/arm64/boot/dts/mediatek/mt8173.dtsi   |  37 +++
 drivers/clk/mediatek/Makefile  |   2 +-
 drivers/clk/mediatek/clk-apmixed.c | 107 ++
 drivers/clk/mediatek/clk-gate.c|   2 +-
 drivers/clk/mediatek/clk-mt8173.c  | 361 -
 drivers/clk/mediatek/clk-mtk.c |  36 +-
 drivers/clk/mediatek/clk-mtk.h |  24 +-
 drivers/clk/mediatek/clk-pll.c |   7 +-
 include/dt-bindings/clock/mt8173-clk.h | 101 +-
 14 files changed, 749 insertions(+), 38 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt
 create mode 100644 drivers/clk/mediatek/clk-apmixed.c

--
1.8.1.1.dirty

--
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 v5 04/10] clk: mediatek: Add fixed clocks support for Mediatek SoC.

[James Liao]

This patch adds fixed clocks support by using CCF fixed-rate
clock implementation.

Signed-off-by: James Liao 
---
 drivers/clk/mediatek/clk-mtk.c | 23 +++
 drivers/clk/mediatek/clk-mtk.h | 17 +
 2 files changed, 40 insertions(+)

diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index 268b6ff..cf08db6 100644
--- a/drivers/clk/mediatek/clk-mtk.c
+++ b/drivers/clk/mediatek/clk-mtk.c
@@ -49,6 +49,29 @@ err_out:
return NULL;
 }
 
+void __init mtk_clk_register_fixed_clks(const struct mtk_fixed_clk *clks,
+   int num, struct clk_onecell_data *clk_data)
+{
+   int i;
+   struct clk *clk;
+
+   for (i = 0; i < num; i++) {
+   const struct mtk_fixed_clk *rc = &clks[i];
+
+   clk = clk_register_fixed_rate(NULL, rc->name, rc->parent,
+   rc->parent ? 0 : CLK_IS_ROOT, rc->rate);
+
+   if (IS_ERR(clk)) {
+   pr_err("Failed to register clk %s: %ld\n",
+   rc->name, PTR_ERR(clk));
+   continue;
+   }
+
+   if (clk_data)
+   clk_data->clks[rc->id] = clk;
+   }
+}
+
 void __init mtk_clk_register_factors(const struct mtk_fixed_factor *clks,
int num, struct clk_onecell_data *clk_data)
 {
diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
index 740fe5e..32d4f55 100644
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -25,6 +25,23 @@
 
 #define MHZ (1000 * 1000)
 
+struct mtk_fixed_clk {
+   int id;
+   const char *name;
+   const char *parent;
+   unsigned long rate;
+};
+
+#define FIXED_CLK(_id, _name, _parent, _rate) {\
+   .id = _id,  \
+   .name = _name,  \
+   .parent = _parent,  \
+   .rate = _rate,  \
+   }
+
+void mtk_clk_register_fixed_clks(const struct mtk_fixed_clk *clks,
+   int num, struct clk_onecell_data *clk_data);
+
 struct mtk_fixed_factor {
int id;
const char *name;
-- 
1.8.1.1.dirty

--
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 v5 03/10] clk: mediatek: Add __initdata and __init for data and functions

[James Liao]

Add __init for clock registration functions, and add __initdata for
mtk_gate_regs initial structures.

Signed-off-by: James Liao 
---
 drivers/clk/mediatek/clk-gate.c   |  2 +-
 drivers/clk/mediatek/clk-mt8173.c |  6 +++---
 drivers/clk/mediatek/clk-mtk.c| 13 +++--
 3 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/clk/mediatek/clk-gate.c b/drivers/clk/mediatek/clk-gate.c
index 5702036..576bdb7 100644
--- a/drivers/clk/mediatek/clk-gate.c
+++ b/drivers/clk/mediatek/clk-gate.c
@@ -97,7 +97,7 @@ const struct clk_ops mtk_clk_gate_ops_setclr_inv = {
.disable= mtk_cg_disable_inv,
 };
 
-struct clk *mtk_clk_register_gate(
+struct clk * __init mtk_clk_register_gate(
const char *name,
const char *parent_name,
struct regmap *regmap,
diff --git a/drivers/clk/mediatek/clk-mt8173.c 
b/drivers/clk/mediatek/clk-mt8173.c
index 4478849..a33a531 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -586,7 +586,7 @@ static const struct mtk_composite top_muxes[] __initconst = 
{
MUX(CLK_TOP_I2S3_B_SEL, "i2s3_b_ck_sel", i2s3_b_ck_parents, 0x120, 8, 
1),
 };
 
-static const struct mtk_gate_regs infra_cg_regs = {
+static const struct mtk_gate_regs infra_cg_regs __initconst = {
.set_ofs = 0x0040,
.clr_ofs = 0x0044,
.sta_ofs = 0x0048,
@@ -615,13 +615,13 @@ static const struct mtk_gate infra_clks[] __initconst = {
GATE_ICG(CLK_INFRA_PMICWRAP, "infra_pmicwrap", "axi_sel", 23),
 };
 
-static const struct mtk_gate_regs peri0_cg_regs = {
+static const struct mtk_gate_regs peri0_cg_regs __initconst = {
.set_ofs = 0x0008,
.clr_ofs = 0x0010,
.sta_ofs = 0x0018,
 };
 
-static const struct mtk_gate_regs peri1_cg_regs = {
+static const struct mtk_gate_regs peri1_cg_regs __initconst = {
.set_ofs = 0x000c,
.clr_ofs = 0x0014,
.sta_ofs = 0x001c,
diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index 18444ae..268b6ff 100644
--- a/drivers/clk/mediatek/clk-mtk.c
+++ b/drivers/clk/mediatek/clk-mtk.c
@@ -24,7 +24,7 @@
 #include "clk-mtk.h"
 #include "clk-gate.h"
 
-struct clk_onecell_data *mtk_alloc_clk_data(unsigned int clk_num)
+struct clk_onecell_data * __init mtk_alloc_clk_data(unsigned int clk_num)
 {
int i;
struct clk_onecell_data *clk_data;
@@ -49,8 +49,8 @@ err_out:
return NULL;
 }
 
-void mtk_clk_register_factors(const struct mtk_fixed_factor *clks, int num,
-   struct clk_onecell_data *clk_data)
+void __init mtk_clk_register_factors(const struct mtk_fixed_factor *clks,
+   int num, struct clk_onecell_data *clk_data)
 {
int i;
struct clk *clk;
@@ -72,7 +72,8 @@ void mtk_clk_register_factors(const struct mtk_fixed_factor 
*clks, int num,
}
 }
 
-int mtk_clk_register_gates(struct device_node *node, const struct mtk_gate 
*clks,
+int __init mtk_clk_register_gates(struct device_node *node,
+   const struct mtk_gate *clks,
int num, struct clk_onecell_data *clk_data)
 {
int i;
@@ -111,7 +112,7 @@ int mtk_clk_register_gates(struct device_node *node, const 
struct mtk_gate *clks
return 0;
 }
 
-struct clk *mtk_clk_register_composite(const struct mtk_composite *mc,
+struct clk * __init mtk_clk_register_composite(const struct mtk_composite *mc,
void __iomem *base, spinlock_t *lock)
 {
struct clk *clk;
@@ -196,7 +197,7 @@ err_out:
return ERR_PTR(ret);
 }
 
-void mtk_clk_register_composites(const struct mtk_composite *mcs,
+void __init mtk_clk_register_composites(const struct mtk_composite *mcs,
int num, void __iomem *base, spinlock_t *lock,
struct clk_onecell_data *clk_data)
 {
-- 
1.8.1.1.dirty

--
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 v2] sound: convert to parse_integer()

[Takashi Iwai]

On Mon, 27 Jul 2015 23:03:01 +0200,
Alexey Dobriyan wrote:
> 
> Convert away from deprecated simple_strto*() interfaces to
> parse_integer() and kstrto*().
> 
> Signed-off-by: Alexey Dobriyan 

The error handling looks good to me.  In addition to Andrew's
suggestion and the removal of word termination check, some nitpicking
below:

> --- a/sound/core/oss/mixer_oss.c
> +++ b/sound/core/oss/mixer_oss.c
> @@ -1180,6 +1180,7 @@ static void snd_mixer_oss_proc_write(struct 
> snd_info_entry *entry,
>   int ch, idx;
>   struct snd_mixer_oss_assign_table *tbl;
>   struct slot *slot;
> + int rv;

A more common variable name is err or ret for such a purpose.

> --- a/sound/soc/soc-core.c
> +++ b/sound/soc/soc-core.c
> @@ -250,7 +250,7 @@ static ssize_t codec_reg_write_file(struct file *file,
>   char buf[32];
>   size_t buf_size;
>   char *start = buf;
> - unsigned long reg, value;
> + unsigned int reg, value;
>   struct snd_soc_codec *codec = file->private_data;
>   int ret;
>  
> @@ -261,10 +261,13 @@ static ssize_t codec_reg_write_file(struct file *file,
>  
>   while (*start == ' ')
>   start++;
> - reg = simple_strtoul(start, &start, 16);
> + ret = parse_integer(start, 16, ®);
> + if (ret < 0)
> + return ret;
> + start += ret;
>   while (*start == ' ')
>   start++;
> - ret = kstrtoul(start, 16, &value);
> + ret = kstrtouint(start, 16, &value);
>   if (ret)
>   return ret;

This looks inconsistent, the first one uses parse_integer() while the
second kstrtouint().  Better to stick with one API.


thanks,

Takashi
--
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 v5 06/10] clk: mediatek: mt8173: Fix enabling of critical clocks

[James Liao]

From: Sascha Hauer 

On the MT8173 the clocks are provided by different units. To enable
the critical clocks we must be sure that all parent clocks are already
registered, otherwise the parents of the critical clocks end up being
unused and get disabled later.

On MT8173, for example, it is the CLK_TOP clocks that have CLK_APMIXED
PLLs as their parents, so we cannot enable the CLK_TOP critical clocks
until the CLK_APMIXED clocks have all been registered.

To find a place where all parents are registered we try each time
after we've registered some clocks if all known providers are present
now and only then we enable the critical clocks.

Signed-off-by: Sascha Hauer 
Signed-off-by: James Liao 
---
 drivers/clk/mediatek/clk-mt8173.c | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mt8173.c 
b/drivers/clk/mediatek/clk-mt8173.c
index 412c36d..c7933b2 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -697,6 +697,22 @@ static const struct mtk_composite peri_clks[] __initconst 
= {
MUX(CLK_PERI_UART3_SEL, "uart3_ck_sel", uart_ck_sel_parents, 0x40c, 3, 
1),
 };
 
+static struct clk_onecell_data *mt8173_top_clk_data;
+static struct clk_onecell_data *mt8173_pll_clk_data;
+
+static void __init mtk_clk_enable_critical(void)
+{
+   if (!mt8173_top_clk_data || !mt8173_pll_clk_data)
+   return;
+
+   clk_prepare_enable(mt8173_pll_clk_data->clks[CLK_APMIXED_ARMCA15PLL]);
+   clk_prepare_enable(mt8173_pll_clk_data->clks[CLK_APMIXED_ARMCA7PLL]);
+   clk_prepare_enable(mt8173_top_clk_data->clks[CLK_TOP_MEM_SEL]);
+   clk_prepare_enable(mt8173_top_clk_data->clks[CLK_TOP_DDRPHYCFG_SEL]);
+   clk_prepare_enable(mt8173_top_clk_data->clks[CLK_TOP_CCI400_SEL]);
+   clk_prepare_enable(mt8173_top_clk_data->clks[CLK_TOP_RTC_SEL]);
+}
+
 static void __init mtk_topckgen_init(struct device_node *node)
 {
struct clk_onecell_data *clk_data;
@@ -709,19 +725,19 @@ static void __init mtk_topckgen_init(struct device_node 
*node)
return;
}
 
-   clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK);
+   mt8173_top_clk_data = clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK);
 
mtk_clk_register_fixed_clks(fixed_clks, ARRAY_SIZE(fixed_clks), 
clk_data);
mtk_clk_register_factors(top_divs, ARRAY_SIZE(top_divs), clk_data);
mtk_clk_register_composites(top_muxes, ARRAY_SIZE(top_muxes), base,
&mt8173_clk_lock, clk_data);
 
-   clk_prepare_enable(clk_data->clks[CLK_TOP_CCI400_SEL]);
-
r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
if (r)
pr_err("%s(): could not register clock provider: %d\n",
__func__, r);
+
+   mtk_clk_enable_critical();
 }
 CLK_OF_DECLARE(mtk_topckgen, "mediatek,mt8173-topckgen", mtk_topckgen_init);
 
@@ -815,13 +831,13 @@ static void __init mtk_apmixedsys_init(struct device_node 
*node)
 {
struct clk_onecell_data *clk_data;
 
-   clk_data = mtk_alloc_clk_data(CLK_APMIXED_NR_CLK);
+   mt8173_pll_clk_data = clk_data = mtk_alloc_clk_data(CLK_APMIXED_NR_CLK);
if (!clk_data)
return;
 
mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data);
 
-   clk_prepare_enable(clk_data->clks[CLK_APMIXED_ARMCA15PLL]);
+   mtk_clk_enable_critical();
 }
 CLK_OF_DECLARE(mtk_apmixedsys, "mediatek,mt8173-apmixedsys",
mtk_apmixedsys_init);
-- 
1.8.1.1.dirty

--
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/4] Input: Remove the max77843 haptic driver

[Krzysztof Kozlowski]

2015-07-29 15:31 GMT+09:00 Krzysztof Kozlowski :
> The max77693 haptic driver supports Maxim 77843 device so remove the
> max77843 driver.
>
> Signed-off-by: Krzysztof Kozlowski 

Crap, wrong signed-off-by. I'll respin.

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/

[PATCH v5 02/10] clk: mediatek: Remove unused code from MT8173.

[James Liao]

Remove unused header files from MT8173, and remove unused
keywords from function declaration.

Signed-off-by: James Liao 
---
 drivers/clk/mediatek/clk-mt8173.c | 2 --
 drivers/clk/mediatek/clk-mtk.h| 4 ++--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mt8173.c 
b/drivers/clk/mediatek/clk-mt8173.c
index 4486f8f..4478849 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -14,8 +14,6 @@
 
 #include 
 #include 
-#include 
-#include 
 
 #include "clk-mtk.h"
 #include "clk-gate.h"
diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
index 9dda9d8..740fe5e 100644
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -41,7 +41,7 @@ struct mtk_fixed_factor {
.div = _div,\
}
 
-extern void mtk_clk_register_factors(const struct mtk_fixed_factor *clks,
+void mtk_clk_register_factors(const struct mtk_fixed_factor *clks,
int num, struct clk_onecell_data *clk_data);
 
 struct mtk_composite {
@@ -152,7 +152,7 @@ struct mtk_pll_data {
int pcw_shift;
 };
 
-void __init mtk_clk_register_plls(struct device_node *node,
+void mtk_clk_register_plls(struct device_node *node,
const struct mtk_pll_data *plls, int num_plls,
struct clk_onecell_data *clk_data);
 
-- 
1.8.1.1.dirty

--
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 v5 10/10] arm64: dts: mt8173: Add subsystem clock controller device nodes

[James Liao]

This patch adds device nodes providing subsystem clocks on MT8173,
includes mmsys, imgsys, vdecsys, vencsys and vencltsys.

Signed-off-by: James Liao 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 37 
 1 file changed, 37 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index a2f63e4..32c85cc 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -102,6 +102,13 @@
clock-output-names = "clk32k";
};
 
+   cpum_ck: oscillator@2 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <0>;
+   clock-output-names = "cpum_ck";
+   };
+
timer {
compatible = "arm,armv8-timer";
interrupt-parent = <&gic>;
@@ -227,6 +234,36 @@
clocks = <&uart_clk>;
status = "disabled";
};
+
+   mmsys: clock-controller@1400 {
+   compatible = "mediatek,mt8173-mmsys", "syscon";
+   reg = <0 0x1400 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   imgsys: clock-controller@1500 {
+   compatible = "mediatek,mt8173-imgsys", "syscon";
+   reg = <0 0x1500 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   vdecsys: clock-controller@1600 {
+   compatible = "mediatek,mt8173-vdecsys", "syscon";
+   reg = <0 0x1600 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   vencsys: clock-controller@1800 {
+   compatible = "mediatek,mt8173-vencsys", "syscon";
+   reg = <0 0x1800 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   vencltsys: clock-controller@1900 {
+   compatible = "mediatek,mt8173-vencltsys", "syscon";
+   reg = <0 0x1900 0 0x1000>;
+   #clock-cells = <1>;
+   };
};
 };
 
-- 
1.8.1.1.dirty

--
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 v5 07/10] dt-bindings: ARM: Mediatek: Document devicetree bindings for clock controllers

[James Liao]

This adds the binding documentation for the mmsys, imgsys, vdecsys,
vencsys and vencltsys controllers found on Mediatek SoCs.

Signed-off-by: James Liao 
---
 .../bindings/arm/mediatek/mediatek,imgsys.txt  | 22 ++
 .../bindings/arm/mediatek/mediatek,mmsys.txt   | 22 ++
 .../bindings/arm/mediatek/mediatek,vdecsys.txt | 22 ++
 .../bindings/arm/mediatek/mediatek,vencltsys.txt   | 22 ++
 .../bindings/arm/mediatek/mediatek,vencsys.txt | 22 ++
 5 files changed, 110 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt

diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
new file mode 100644
index 000..b1f2ce1
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
@@ -0,0 +1,22 @@
+Mediatek imgsys controller
+
+
+The Mediatek imgsys controller provides various clocks to the system.
+
+Required Properties:
+
+- compatible: Should be:
+   - "mediatek,mt8173-imgsys", "syscon"
+- #clock-cells: Must be 1
+
+The imgsys controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+
+Example:
+
+imgsys: clock-controller@1500 {
+   compatible = "mediatek,mt8173-imgsys", "syscon";
+   reg = <0 0x1500 0 0x1000>;
+   #clock-cells = <1>;
+};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
new file mode 100644
index 000..4385946
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
@@ -0,0 +1,22 @@
+Mediatek mmsys controller
+
+
+The Mediatek mmsys controller provides various clocks to the system.
+
+Required Properties:
+
+- compatible: Should be:
+   - "mediatek,mt8173-mmsys", "syscon"
+- #clock-cells: Must be 1
+
+The mmsys controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+
+Example:
+
+mmsys: clock-controller@1400 {
+   compatible = "mediatek,mt8173-mmsys", "syscon";
+   reg = <0 0x1400 0 0x1000>;
+   #clock-cells = <1>;
+};
diff --git 
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
new file mode 100644
index 000..1faacf1
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
@@ -0,0 +1,22 @@
+Mediatek vdecsys controller
+
+
+The Mediatek vdecsys controller provides various clocks to the system.
+
+Required Properties:
+
+- compatible: Should be:
+   - "mediatek,mt8173-vdecsys", "syscon"
+- #clock-cells: Must be 1
+
+The vdecsys controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+
+Example:
+
+vdecsys: clock-controller@1600 {
+   compatible = "mediatek,mt8173-vdecsys", "syscon";
+   reg = <0 0x1600 0 0x1000>;
+   #clock-cells = <1>;
+};
diff --git 
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt
new file mode 100644
index 000..3cc299f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt
@@ -0,0 +1,22 @@
+Mediatek vencltsys controller
+
+
+The Mediatek vencltsys controller provides various clocks to the system.
+
+Required Properties:
+
+- compatible: Should be:
+   - "mediatek,mt8173-vencltsys", "syscon"
+- #clock-cells: Must be 1
+
+The vencltsys controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+
+Example:
+
+vencltsys: clock-controller@1900 {
+   compatible = "mediatek,mt8173-vencltsys", "syscon";
+   reg = <0 0x1900 0 0x1000>;
+   #clock-cells = <1>;
+};
diff --git 
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt
new file mode 100644
index 000..5bb2866
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/med

[PATCH v5 05/10] clk: mediatek: Fix rate and dependency of MT8173 clocks

[James Liao]

Remove the dependency from clk_null, and give all root clocks a
typical rate, include clkph_mck_o, usb_syspll_125m and hdmitx_dig_cts.

dpi_ck was removed due to no clock reference to it.

Replace parent clock of infra_cpum with cpum_ck, which is an external
clock and can be defined in the device tree.

Signed-off-by: James Liao 
---
 drivers/clk/mediatek/clk-mt8173.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mt8173.c 
b/drivers/clk/mediatek/clk-mt8173.c
index a33a531..412c36d 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -22,10 +22,9 @@
 
 static DEFINE_SPINLOCK(mt8173_clk_lock);
 
-static const struct mtk_fixed_factor root_clk_alias[] __initconst = {
-   FACTOR(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk_null", 1, 1),
-   FACTOR(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk_null", 1, 1),
-   FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "clk_null", 1, 1),
+static const struct mtk_fixed_clk fixed_clks[] __initconst = {
+   FIXED_CLK(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk26m", 400 * MHZ),
+   FIXED_CLK(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk26m", 125 * 
MHZ),
 };
 
 static const struct mtk_fixed_factor top_divs[] __initconst = {
@@ -50,6 +49,7 @@ static const struct mtk_fixed_factor top_divs[] __initconst = 
{
FACTOR(CLK_TOP_CLKRTC_INT, "clkrtc_int", "clk26m", 1, 793),
FACTOR(CLK_TOP_FPC, "fpc_ck", "clk26m", 1, 1),
 
+   FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "tvdpll_445p5m", 1, 3),
FACTOR(CLK_TOP_HDMITXPLL_D2, "hdmitxpll_d2", "hdmitx_dig_cts", 1, 2),
FACTOR(CLK_TOP_HDMITXPLL_D3, "hdmitxpll_d3", "hdmitx_dig_cts", 1, 3),
 
@@ -608,7 +608,7 @@ static const struct mtk_gate infra_clks[] __initconst = {
GATE_ICG(CLK_INFRA_GCE, "infra_gce", "axi_sel", 6),
GATE_ICG(CLK_INFRA_L2C_SRAM, "infra_l2c_sram", "axi_sel", 7),
GATE_ICG(CLK_INFRA_M4U, "infra_m4u", "mem_sel", 8),
-   GATE_ICG(CLK_INFRA_CPUM, "infra_cpum", "clk_null", 15),
+   GATE_ICG(CLK_INFRA_CPUM, "infra_cpum", "cpum_ck", 15),
GATE_ICG(CLK_INFRA_KP, "infra_kp", "axi_sel", 16),
GATE_ICG(CLK_INFRA_CEC, "infra_cec", "clk26m", 18),
GATE_ICG(CLK_INFRA_PMICSPI, "infra_pmicspi", "pmicspi_sel", 22),
@@ -711,7 +711,7 @@ static void __init mtk_topckgen_init(struct device_node 
*node)
 
clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK);
 
-   mtk_clk_register_factors(root_clk_alias, ARRAY_SIZE(root_clk_alias), 
clk_data);
+   mtk_clk_register_fixed_clks(fixed_clks, ARRAY_SIZE(fixed_clks), 
clk_data);
mtk_clk_register_factors(top_divs, ARRAY_SIZE(top_divs), clk_data);
mtk_clk_register_composites(top_muxes, ARRAY_SIZE(top_muxes), base,
&mt8173_clk_lock, clk_data);
-- 
1.8.1.1.dirty

--
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/4] auxdisplay: ks0108: fix refcount

[Sudip Mukherjee]

On Mon, Jul 20, 2015 at 05:27:21PM +0530, Sudip Mukherjee wrote:
> parport_find_base() will implicitly do parport_get_port() which
> increases the refcount. Then parport_register_device() will again
> increment the refcount. But while unloading the module we are only
> doing parport_unregister_device() decrementing the refcount only once.
> We add an parport_put_port() to neutralize the effect of
> parport_get_port().
> 
> Cc:  # 2.6.32+
> Signed-off-by: Sudip Mukherjee 
> ---
Hi Miguel,
A gentle ping.

regards
sudip
--
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] Staging : wilc1000: Remove braces for single statement blocks

[Shraddha Barke]

This patch fixes the following checkpatch.pl warning:

WARNING: braces {} are not necessary for single statement blocks
Signed-off-by: Shraddha Barke 
---
 drivers/staging/wilc1000/coreconfigurator.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/wilc1000/coreconfigurator.c 
b/drivers/staging/wilc1000/coreconfigurator.c
index ed6ac45..eb1b8f2 100644
--- a/drivers/staging/wilc1000/coreconfigurator.c
+++ b/drivers/staging/wilc1000/coreconfigurator.c
@@ -855,9 +855,8 @@ s32 ParseNetworkInfo(u8 *pu8MsgBuffer, tstrNetworkInfo 
**ppstrNetworkInfo)
 
/* Get DTIM Period */
pu8TimElm = get_tim_elm(pu8msa, (u16RxLen + FCS_LEN), u8index);
-   if (pu8TimElm != 0) {
+   if (pu8TimElm != 0)
pstrNetworkInfo->u8DtimPeriod = pu8TimElm[3];
-   }
pu8IEs = &pu8msa[MAC_HDR_LEN + TIME_STAMP_LEN + 
BEACON_INTERVAL_LEN + CAP_INFO_LEN];
u16IEsLen = u16RxLen - (MAC_HDR_LEN + TIME_STAMP_LEN + 
BEACON_INTERVAL_LEN + CAP_INFO_LEN);
 
-- 
2.1.0

--
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 v5 08/10] clk: mediatek: Add subsystem clocks of MT8173

[James Liao]

Most multimedia subsystem clocks will be accessed by multiple
drivers, so it's a better way to manage these clocks in CCF.
This patch adds clock support for MM, IMG, VDEC, VENC and VENC_LT
subsystems.

Signed-off-by: James Liao 
---
 drivers/clk/mediatek/clk-mt8173.c  | 267 +
 include/dt-bindings/clock/mt8173-clk.h |  97 +++-
 2 files changed, 361 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mt8173.c 
b/drivers/clk/mediatek/clk-mt8173.c
index c7933b2..4506083 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -25,6 +25,10 @@ static DEFINE_SPINLOCK(mt8173_clk_lock);
 static const struct mtk_fixed_clk fixed_clks[] __initconst = {
FIXED_CLK(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk26m", 400 * MHZ),
FIXED_CLK(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk26m", 125 * 
MHZ),
+   FIXED_CLK(CLK_TOP_DSI0_DIG, "dsi0_dig", "clk26m", 130 * MHZ),
+   FIXED_CLK(CLK_TOP_DSI1_DIG, "dsi1_dig", "clk26m", 130 * MHZ),
+   FIXED_CLK(CLK_TOP_LVDS_PXL, "lvds_pxl", "lvdspll", 148.5 * MHZ),
+   FIXED_CLK(CLK_TOP_LVDS_CTS, "lvds_cts", "lvdspll", 51.975 * MHZ),
 };
 
 static const struct mtk_fixed_factor top_divs[] __initconst = {
@@ -697,6 +701,183 @@ static const struct mtk_composite peri_clks[] __initconst 
= {
MUX(CLK_PERI_UART3_SEL, "uart3_ck_sel", uart_ck_sel_parents, 0x40c, 3, 
1),
 };
 
+static const struct mtk_gate_regs cg_regs_4_8_0 __initconst = {
+   .set_ofs = 0x0004,
+   .clr_ofs = 0x0008,
+   .sta_ofs = 0x,
+};
+
+#define GATE_IMG(_id, _name, _parent, _shift) {\
+   .id = _id,  \
+   .name = _name,  \
+   .parent_name = _parent, \
+   .regs = &cg_regs_4_8_0, \
+   .shift = _shift,\
+   .ops = &mtk_clk_gate_ops_setclr,\
+   }
+
+static const struct mtk_gate img_clks[] __initconst = {
+   GATE_IMG(CLK_IMG_LARB2_SMI, "img_larb2_smi", "mm_sel", 0),
+   GATE_IMG(CLK_IMG_CAM_SMI, "img_cam_smi", "mm_sel", 5),
+   GATE_IMG(CLK_IMG_CAM_CAM, "img_cam_cam", "mm_sel", 6),
+   GATE_IMG(CLK_IMG_SEN_TG, "img_sen_tg", "camtg_sel", 7),
+   GATE_IMG(CLK_IMG_SEN_CAM, "img_sen_cam", "mm_sel", 8),
+   GATE_IMG(CLK_IMG_CAM_SV, "img_cam_sv", "mm_sel", 9),
+   GATE_IMG(CLK_IMG_FD, "img_fd", "mm_sel", 11),
+};
+
+static const struct mtk_gate_regs mm0_cg_regs __initconst = {
+   .set_ofs = 0x0104,
+   .clr_ofs = 0x0108,
+   .sta_ofs = 0x0100,
+};
+
+static const struct mtk_gate_regs mm1_cg_regs __initconst = {
+   .set_ofs = 0x0114,
+   .clr_ofs = 0x0118,
+   .sta_ofs = 0x0110,
+};
+
+#define GATE_MM0(_id, _name, _parent, _shift) {\
+   .id = _id,  \
+   .name = _name,  \
+   .parent_name = _parent, \
+   .regs = &mm0_cg_regs,   \
+   .shift = _shift,\
+   .ops = &mtk_clk_gate_ops_setclr,\
+   }
+
+#define GATE_MM1(_id, _name, _parent, _shift) {\
+   .id = _id,  \
+   .name = _name,  \
+   .parent_name = _parent, \
+   .regs = &mm1_cg_regs,   \
+   .shift = _shift,\
+   .ops = &mtk_clk_gate_ops_setclr,\
+   }
+
+static const struct mtk_gate mm_clks[] __initconst = {
+   /* MM0 */
+   GATE_MM0(CLK_MM_SMI_COMMON, "mm_smi_common", "mm_sel", 0),
+   GATE_MM0(CLK_MM_SMI_LARB0, "mm_smi_larb0", "mm_sel", 1),
+   GATE_MM0(CLK_MM_CAM_MDP, "mm_cam_mdp", "mm_sel", 2),
+   GATE_MM0(CLK_MM_MDP_RDMA0, "mm_mdp_rdma0", "mm_sel", 3),
+   GATE_MM0(CLK_MM_MDP_RDMA1, "mm_mdp_rdma1", "mm_sel", 4),
+   GATE_MM0(CLK_MM_MDP_RSZ0, "mm_mdp_rsz0", "mm_sel", 5),
+   GATE_MM0(CLK_MM_MDP_RSZ1, "mm_mdp_rsz1", "mm_sel", 6),
+   GATE_MM0(CLK_MM_MDP_RSZ2, "mm_mdp_rsz2", "mm_sel", 7),
+   GATE_MM0(CLK_MM_MDP_TDSHP0, "mm_mdp_tdshp0", "mm_sel", 8),
+   GATE_MM0(CLK_MM_MDP_TDSHP1, "mm_mdp_tdshp1", "mm_sel", 9),
+   GATE_MM0(CLK_MM_MDP_WDMA, "mm_mdp_wdma", "mm_sel", 11),
+   GATE_MM0(CLK_MM_MDP_WROT0, "mm_mdp_wrot0", "mm_sel", 12),
+   GATE_MM0(CLK_MM_MDP_WROT1, "mm_mdp_wrot1", "mm_sel", 13),
+   GATE_MM0(CLK_MM_FAKE_ENG, "mm_fake_eng", "mm_sel", 14),
+   GATE_MM0(CLK_MM_MUTEX_32K, "mm_mutex_32k", "rtc_sel", 15),
+   GATE_MM0(CLK_MM_DISP_OVL0, "mm_disp_ovl0", "mm_sel", 16),
+   GATE_MM0(CLK_MM_DISP_OVL1, "mm_disp_ovl1", "m

[PATCH v5 01/10] clk: mediatek: Removed unused dpi_ck clock from MT8173

[James Liao]

The dpi_ck clock can be removed because it not actually used
in topckgen and subsystems.

Signed-off-by: James Liao 
---
 drivers/clk/mediatek/clk-mt8173.c  | 1 -
 include/dt-bindings/clock/mt8173-clk.h | 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mt8173.c 
b/drivers/clk/mediatek/clk-mt8173.c
index 4b9e04c..4486f8f 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -26,7 +26,6 @@ static DEFINE_SPINLOCK(mt8173_clk_lock);
 
 static const struct mtk_fixed_factor root_clk_alias[] __initconst = {
FACTOR(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk_null", 1, 1),
-   FACTOR(CLK_TOP_DPI, "dpi_ck", "clk_null", 1, 1),
FACTOR(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk_null", 1, 1),
FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "clk_null", 1, 1),
 };
diff --git a/include/dt-bindings/clock/mt8173-clk.h 
b/include/dt-bindings/clock/mt8173-clk.h
index 4ad76ed..7230c38 100644
--- a/include/dt-bindings/clock/mt8173-clk.h
+++ b/include/dt-bindings/clock/mt8173-clk.h
@@ -18,7 +18,6 @@
 /* TOPCKGEN */
 
 #define CLK_TOP_CLKPH_MCK_O1
-#define CLK_TOP_DPI2
 #define CLK_TOP_USB_SYSPLL_125M3
 #define CLK_TOP_HDMITX_DIG_CTS 4
 #define CLK_TOP_ARMCA7PLL_754M 5
-- 
1.8.1.1.dirty

--
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 v5 09/10] clk: mediatek: Add USB clock support in MT8173 APMIXEDSYS

[James Liao]

Add REF2USB_TX clock support into MT8173 APMIXEDSYS. This clock
is needed by USB 3.0.

Signed-off-by: James Liao 
---
 drivers/clk/mediatek/Makefile  |   2 +-
 drivers/clk/mediatek/clk-apmixed.c | 107 +
 drivers/clk/mediatek/clk-mt8173.c  |  47 +++
 drivers/clk/mediatek/clk-mtk.h |   3 +
 drivers/clk/mediatek/clk-pll.c |   7 +--
 include/dt-bindings/clock/mt8173-clk.h |   3 +-
 6 files changed, 161 insertions(+), 8 deletions(-)
 create mode 100644 drivers/clk/mediatek/clk-apmixed.c

diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index 8e4b2a4..95fdfac 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -1,4 +1,4 @@
-obj-y += clk-mtk.o clk-pll.o clk-gate.o
+obj-y += clk-mtk.o clk-pll.o clk-gate.o clk-apmixed.o
 obj-$(CONFIG_RESET_CONTROLLER) += reset.o
 obj-y += clk-mt8135.o
 obj-y += clk-mt8173.o
diff --git a/drivers/clk/mediatek/clk-apmixed.c 
b/drivers/clk/mediatek/clk-apmixed.c
new file mode 100644
index 000..5303c59
--- /dev/null
+++ b/drivers/clk/mediatek/clk-apmixed.c
@@ -0,0 +1,107 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author: James Liao 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+
+#include "clk-mtk.h"
+
+#define REF2USB_TX_EN  BIT(0)
+#define REF2USB_TX_LPF_EN  BIT(1)
+#define REF2USB_TX_OUT_EN  BIT(2)
+#define REF2USB_EN_MASK(REF2USB_TX_EN | REF2USB_TX_LPF_EN | \
+REF2USB_TX_OUT_EN)
+
+struct mtk_ref2usb_tx {
+   struct clk_hw   hw;
+   void __iomem*base_addr;
+};
+
+static inline struct mtk_ref2usb_tx *to_mtk_ref2usb_tx(struct clk_hw *hw)
+{
+   return container_of(hw, struct mtk_ref2usb_tx, hw);
+}
+
+static int mtk_ref2usb_tx_is_prepared(struct clk_hw *hw)
+{
+   struct mtk_ref2usb_tx *tx = to_mtk_ref2usb_tx(hw);
+
+   return (readl(tx->base_addr) & REF2USB_EN_MASK) == REF2USB_EN_MASK;
+}
+
+static int mtk_ref2usb_tx_prepare(struct clk_hw *hw)
+{
+   struct mtk_ref2usb_tx *tx = to_mtk_ref2usb_tx(hw);
+   u32 val;
+
+   val = readl(tx->base_addr);
+
+   val |= REF2USB_TX_EN;
+   writel(val, tx->base_addr);
+   udelay(100);
+
+   val |= REF2USB_TX_LPF_EN;
+   writel(val, tx->base_addr);
+
+   val |= REF2USB_TX_OUT_EN;
+   writel(val, tx->base_addr);
+
+   return 0;
+}
+
+static void mtk_ref2usb_tx_unprepare(struct clk_hw *hw)
+{
+   struct mtk_ref2usb_tx *tx = to_mtk_ref2usb_tx(hw);
+   u32 val;
+
+   val = readl(tx->base_addr);
+   val &= ~REF2USB_EN_MASK;
+   writel(val, tx->base_addr);
+}
+
+static const struct clk_ops mtk_ref2usb_tx_ops = {
+   .is_prepared= mtk_ref2usb_tx_is_prepared,
+   .prepare= mtk_ref2usb_tx_prepare,
+   .unprepare  = mtk_ref2usb_tx_unprepare,
+};
+
+struct clk * __init mtk_clk_register_ref2usb_tx(const char *name,
+   const char *parent_name, void __iomem *reg)
+{
+   struct mtk_ref2usb_tx *tx;
+   struct clk_init_data init = {};
+   struct clk *clk;
+
+   tx = kzalloc(sizeof(*tx), GFP_KERNEL);
+   if (!tx)
+   return ERR_PTR(-ENOMEM);
+
+   tx->base_addr = reg;
+   tx->hw.init = &init;
+
+   init.name = name;
+   init.ops = &mtk_ref2usb_tx_ops;
+   init.parent_names = &parent_name;
+   init.num_parents = 1;
+
+   clk = clk_register(NULL, &tx->hw);
+
+   if (IS_ERR(clk)) {
+   pr_err("Failed to register clk %s: %ld\n", name, PTR_ERR(clk));
+   kfree(tx);
+   }
+
+   return clk;
+}
diff --git a/drivers/clk/mediatek/clk-mt8173.c 
b/drivers/clk/mediatek/clk-mt8173.c
index 4506083..c0665b7 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -969,6 +969,24 @@ static void __init mtk_pericfg_init(struct device_node 
*node)
 }
 CLK_OF_DECLARE(mtk_pericfg, "mediatek,mt8173-pericfg", mtk_pericfg_init);
 
+struct mtk_clk_usb {
+   int id;
+   const char *name;
+   const char *parent;
+   u32 reg_ofs;
+};
+
+#define APMIXED_USB(_id, _name, _parent, _reg_ofs) {   \
+   .id = _id,  \
+   .name = _name,  \
+   .parent = _parent,  \
+   .reg_ofs = _reg_ofs,\
+   }
+
+static const struct mtk_clk_usb apmixed_usb[] __initconst = {
+   AP

Re: [PATCH v2 08/25] arch: introduce memremap()

[Christoph Hellwig]

On Mon, Jul 27, 2015 at 04:26:03PM -0700, Dan Williams wrote:
> Oh, because all we have at this point is ioremap_cache() which
> silently falls back.  It's not until the introduction of
> arch_memremp() where we update the arch code to break that behavior.

Ok, makes sense.  Might be worth to document in the changelog.

> That said, I think it may be beneficial to allow a fallback if the
> user cares.  So maybe memremap() can call plain ioremap() if
> MEMREMAP_STRICT is not set and none of the other mapping types are
> satisfied.

Is there a real use case for it?  Fallback APIs always seem confusing
and it might make more sense to do this in the caller(s) that actually
need 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 -mm v2] sound: convert to parse_integer()

[Takashi Iwai]

On Tue, 28 Jul 2015 23:06:15 +0200,
Andrew Morton wrote:
> 
> On Tue, 28 Jul 2015 00:03:01 +0300 Alexey Dobriyan  
> wrote:
> 
> > Convert away from deprecated simple_strto*() interfaces to
> > parse_integer() and kstrto*().
> 
> The patch does a lot more than this!  It also adds lots of handling of
> previously-ignored errors.

Yes, please give more description.

> And it thereby introduces possible back-compatibility issues.  Someone
> who is doing "echo 42foo > wherever" will now get an error, whereas
> they previously got 42.

Right, many strings don't care about spaces, i.e. it contains trailing
spaces, so the patch seems doing way too strict.  I think it's better
to omit the word termination check in each place.

> So hm.  Probably a good patch and I'll stick it in -mm for testing, but
> this should go upstream via tiwai, please.

Well, but parse_integer() isn't upstreamed yet, so it has to be after
mm tree, right?


thanks,

Takashi
--
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/8] jump_label: Another (better) static_key interface

[Heiko Carstens]

On Tue, Jul 28, 2015 at 03:20:55PM +0200, Peter Zijlstra wrote:
> Hi all,
> 
> After yet another bug because of the weirdness of the static key interface,
> here an attempt at providing a better one.
> 
> This series is tested on x86_64 (by me) and s390x (heiko).

Works nice. You may include the s390 patch below, so the conversion to the
new interface happens when your code gets merged:

>From 3c9b5a2b9a90d6bb2b41f381f5f89b3657fe4ea5 Mon Sep 17 00:00:00 2001
From: Heiko Carstens 
Date: Wed, 29 Jul 2015 08:31:24 +0200
Subject: [PATCH] s390/uaccess: employ static_branch_likely()

Use the new static_branch_likely() primitive to make sure that the
most likely case is executed without taking an unconditional branch.
This wasn't possible with the old jump label primitives.

Signed-off-by: Heiko Carstens 
---
 arch/s390/lib/uaccess.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/s390/lib/uaccess.c b/arch/s390/lib/uaccess.c
index 4614d415bb58..93cb1d09493d 100644
--- a/arch/s390/lib/uaccess.c
+++ b/arch/s390/lib/uaccess.c
@@ -15,7 +15,7 @@
 #include 
 #include 
 
-static struct static_key have_mvcos = STATIC_KEY_INIT_FALSE;
+static DEFINE_STATIC_KEY_FALSE(have_mvcos);
 
 static inline unsigned long copy_from_user_mvcos(void *x, const void __user 
*ptr,
 unsigned long size)
@@ -104,7 +104,7 @@ static inline unsigned long copy_from_user_mvcp(void *x, 
const void __user *ptr,
 
 unsigned long __copy_from_user(void *to, const void __user *from, unsigned 
long n)
 {
-   if (static_key_false(&have_mvcos))
+   if (static_branch_likely(&have_mvcos))
return copy_from_user_mvcos(to, from, n);
return copy_from_user_mvcp(to, from, n);
 }
@@ -177,7 +177,7 @@ static inline unsigned long copy_to_user_mvcs(void __user 
*ptr, const void *x,
 
 unsigned long __copy_to_user(void __user *to, const void *from, unsigned long 
n)
 {
-   if (static_key_false(&have_mvcos))
+   if (static_branch_likely(&have_mvcos))
return copy_to_user_mvcos(to, from, n);
return copy_to_user_mvcs(to, from, n);
 }
@@ -240,7 +240,7 @@ static inline unsigned long copy_in_user_mvc(void __user 
*to, const void __user
 
 unsigned long __copy_in_user(void __user *to, const void __user *from, 
unsigned long n)
 {
-   if (static_key_false(&have_mvcos))
+   if (static_branch_likely(&have_mvcos))
return copy_in_user_mvcos(to, from, n);
return copy_in_user_mvc(to, from, n);
 }
@@ -312,7 +312,7 @@ static inline unsigned long clear_user_xc(void __user *to, 
unsigned long size)
 
 unsigned long __clear_user(void __user *to, unsigned long size)
 {
-   if (static_key_false(&have_mvcos))
+   if (static_branch_likely(&have_mvcos))
return clear_user_mvcos(to, size);
return clear_user_xc(to, size);
 }
@@ -386,7 +386,7 @@ early_param("uaccess_primary", parse_uaccess_pt);
 static int __init uaccess_init(void)
 {
if (!uaccess_primary && test_facility(27))
-   static_key_slow_inc(&have_mvcos);
+   static_branch_enable(&have_mvcos);
return 0;
 }
 early_initcall(uaccess_init);
-- 
2.3.8

--
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/5] iTCO_wdt: Expose watchdog properties using platform data

[Jean Delvare]

Le Tuesday 28 July 2015 à 10:46 +0100, Lee Jones a écrit :
> On Mon, 27 Jul 2015, Matt Fleming wrote:
> > +   strcpy(pdata->name, info->name);
> 
> strncpy() is safer.

And strlcpy() is even better.

-- 
Jean Delvare
SUSE L3 Support

--
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/5] iTCO_wdt: Add support for TCO on Intel Sunrisepoint

[Jean Delvare]

Hi Matt,

Le Monday 27 July 2015 à 14:38 +0100, Matt Fleming a écrit :
> From: Matt Fleming 
> 
> The revision of the watchdog hardware in Sunrisepoint necessitates a new
> "version" inside the TCO watchdog driver because some of the register
> layouts have changed.
> 
> Cc: Wim Van Sebroeck 
> Signed-off-by: Matt Fleming 
> ---
>  drivers/watchdog/iTCO_wdt.c | 58 
> ++---
>  1 file changed, 34 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/watchdog/iTCO_wdt.c b/drivers/watchdog/iTCO_wdt.c
> index 9a6e70976f64..17dfbc51b85a 100644
> --- a/drivers/watchdog/iTCO_wdt.c
> +++ b/drivers/watchdog/iTCO_wdt.c
> (...) 
> @@ -503,7 +510,10 @@ static int iTCO_wdt_probe(struct platform_device *dev)
>   pdata->name, pdata->iTCO_version, (u64)TCOBASE);
>  
>   /* Clear out the (probably old) status */
> - if (iTCO_wdt_private.iTCO_version == 3) {
> + if (iTCO_wdt_private.iTCO_version == 4) {
> + outw(0x0008, TCO1_STS); /* Clear the Time Out Status bit */
> + outw(0x0002, TCO2_STS); /* Clear SECOND_TO_STS bit */
> + } else if (iTCO_wdt_private.iTCO_version == 3) {
>   outl(0x20008, TCO1_STS);
>   } else {
>   outw(0x0008, TCO1_STS); /* Clear the Time Out Status bit */

The "version == 4" branch is a subset of the "else" branch, so you could
merge both with a conditional. If you prefer not to, then it probably
makes sense to change the whole block to a switch/case construct.

-- 
Jean Delvare
SUSE L3 Support

--
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 6/8] jump_label: Add a new static_key interface

[Heiko Carstens]

On Tue, Jul 28, 2015 at 03:21:01PM +0200, Peter Zijlstra wrote:
> There are various problems and short-comings with the current
> static_key interface:
> 
>  - static_key_{true,false}() read like a branch depending on the key
>value, instead of the actual likely/unlikely branch depending on
>init value.
> 
>  - static_key_{true,false}() are, as stated above, tied to the
>static_key init values STATIC_KEY_INIT_{TRUE,FALSE}.
> 
>  - we're limited to the 2 (out of 4) possible options that compile to
>a default NOP because that's what our arch_static_branch() assembly
>emits.
> 
> So provide a new static_key interface:
> 
>   DEFINE_STATIC_KEY_TRUE(name);
>   DEFINE_STATIC_KEY_FALSE(name);
> 
> Which define a key of different types with an initial true/false
> value.
> 
> Then allow:
> 
>static_branch_likely()
>static_branch_unlikely()
> 
> to take a key of either type and emit the right instruction for the
> case.
> 
> This means adding a second arch_static_branch_jump() assembly helper
> which emits a JMP per default.
> 
> In order to determine the right instruction for the right state,
> encode the branch type in the LSB of jump_entry::key.
> 
> Signed-off-by: Peter Zijlstra (Intel) 
> ---
>  arch/arm/include/asm/jump_label.h |   24 +++--
>  arch/arm64/include/asm/jump_label.h   |   18 +++-
>  arch/mips/include/asm/jump_label.h|   19 
>  arch/powerpc/include/asm/jump_label.h |   19 
>  arch/s390/include/asm/jump_label.h|   19 
>  arch/sparc/include/asm/jump_label.h   |   35 ++--
>  arch/x86/include/asm/jump_label.h |   21 
>  include/linux/jump_label.h|  143 
> --
>  kernel/jump_label.c   |   35 ++--
>  9 files changed, 294 insertions(+), 39 deletions(-)

for the s390 part:

Acked-by: Heiko Carstens 

--
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 1/4] mm, compaction: introduce kcompactd

[Vlastimil Babka]

On 07/29/2015 02:33 AM, David Rientjes wrote:
> On Fri, 24 Jul 2015, Vlastimil Babka wrote:
> 
>> > Two issues I want to bring up:
>> > 
>> >   (1) do non-thp configs benefit from periodic compaction?
>> > 
>> >   In my experience, no, but perhaps there are other use cases where
>> >   this has been a pain.  The primary candidates, in my opinion,
>> >   would be the networking stack and slub.  Joonsoo reports having to
>> >   workaround issues with high-order slub allocations being too
>> >   expensive.  I'm not sure that would be better served by periodic
>> >   compaction, but it seems like a candidate for background compaction.
>> 
>> Yes hopefully a proactive background compaction would serve them enough.
>> 
>> >   This is why my rfc tied periodic compaction to khugepaged, and we
>> >   have strong evidence that this helps thp and cpu utilization.  For
>> >   periodic compaction to be possible outside of thp, we'd need a use
>> >   case for it.
>> > 
>> >   (2) does kcompactd have to be per-node?
>> > 
>> >   I don't see the immediate benefit since direct compaction can
>> >   already scan remote memory and migrate it, khugepaged can do the
>> 
>> It can work remotely, but it's slower.
>> 
>> >   same.  Is there evidence that suggests that a per-node kcompactd
>> >   is significantly better than a single kthread?  I think others
>> >   would be more receptive of a single kthread addition.
>> 
>> I think it's simpler design wrt waking up the kthread for the desired node,
>> and self-tuning any sleeping depending on per-node pressure. It also matches
>> the design of kswapd. And IMHO machines with many memory nodes should
>> naturally have also many CPU's to cope with the threads, so it should all
>> scale well.
>> 
> 
> I see your "proactive background compaction" as my "periodic compaction" 
> :)  And I agree with your comment that we should be careful about defining 
> the API so it can be easily extended in the future.
> 
> I see the two mechanisms different enough that they need to be defined 
> separately: periodic compaction that would be done at certain intervals 
> regardless of fragmentation or allocation failures to keep fragmentation 
> low, and background compaction that would be done when a zone reaches a 
> certain fragmentation index for high orders, similar to extfrag_threshold, 
> or an allocation failure.

Is there a smart way to check the fragmentation index without doing it just
periodically, and without polluting the allocator fast paths?

Do you think we should still handle THP availability separately as this patchset
does, or not? I think it could still serve to reduce page fault latencies and
pointless khugepaged scanning when hugepages cannot be allocated.
Which implies, can the following be built on top of this patchset?

> Per-node kcompactd threads we agree would be optimal, so let's try to see 
> if we can make that work.
> 
> What do you think about the following?
> 
>  - add vm.compact_period_secs to define the number of seconds between
>full compactions on each node.  This compaction would reset the
>pageblock skip heuristic and be synchronous.  It would default to 900
>based only on our evidence that 15m period compaction helps increase
>our cpu utilization for khugepaged; it is arbitrary and I'd happily
>change it if someone has a better suggestion.  Changing it to 0 would
>disable periodic compaction (we don't anticipate anybody will ever
>want kcompactd threads will take 100% of cpu on each node).  We can
>stagger this over all nodes to avoid all kcompactd threads working at
>the same time.

I guess more testing would be useful to see that it still improves things over
the background compaction?

>  - add vm.compact_background_extfrag_threshold to define the extfrag
>threshold when kcompactd should start doing sync_light migration
>in the background without resetting the pageblock skip heuristic.
>The threshold is defined at PAGE_ALLOC_COSTLY_ORDER and is halved
>for each order higher so that very high order allocations don't

I've pondered what exactly the fragmentation index calculates, and it's hard to
imagine how I'd set the threshold. Note that the equation already does
effectively a halving with each order increase, but probably in the opposite
direction that you want it to.

Michal Hocko suggested to me offline that we have tunables like
compact_min_order and compact_max_order, where (IIUC) compaction would trigger
when no pages of >=compact_min_order are available, and then compaction would
stop when pages of >=compact_max_order are available (i.e. a kind of
hysteresis). I'm not sure about this either, as the user would have to know
which order-allocations his particular drivers need (unless it's somehow
self-tuning).

What I have instead in mind is something like the current high-order watermark
checking (which may be going away soon, but anyway...

Re: [PATCH v2 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS

[Vignesh R]

On 07/23/2015 09:05 PM, R, Vignesh wrote:
> 
> 
> On 7/16/2015 9:01 PM, R, Vignesh wrote:
>> Hi,
>>
>> On 07/16/2015 03:24 AM, Paul Walmsley wrote:
>>> Hi,
>>>
>>> some comments.
>>>
>>> On Wed, 3 Jun 2015, Vignesh R wrote:
>>>
 Add hwmod entries for the PWMSS on DRA7.

 Set l4_root_clk_div as the main_clk of PWMSS. It is fixed-factored clock
 equal to L4PER2_L3_GICLK/2(l3_iclk_div/2).
 As per AM57x TRM SPRUHZ6[1], October 2014, Section 29.1.3 Table 29-4,
 clock source to PWMSS is L4PER2_L3_GICLK. But it is actually
 L4PER2_L3_GICLK/2. The TRM does not show the division by 2.
>>>
>>> Is the divide-by-two coming from PWMSS_EPWM.EPWM_TBCTL[HSPCLKDIV]?  Or is 
>>> HSPCLKDIV a separate divider after the divide-by-2 you mention above?
>>
>> No, it not related to HSPCLKDIV. The TRM wrongly states L4PER2_L3_GICLK
>> as clock input for PWMSS. But actually  L4PER2_L4_GICLK(=L3_GICLK/2) is
>> the clock input for PWMSS. This will be updated in TRM soon.
>>
>>>
 [1] www.ti.com/lit/ug/spruhz6/spruhz6.pdf

 Signed-off-by: Vignesh R 
 ---

 v2:
  * add TRM references.

  arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 239 
 ++
  1 file changed, 239 insertions(+)

 diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
 b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
 index 0e64c2fac0b5..86a7ac9a3138 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
 @@ -362,6 +362,149 @@ static struct omap_hwmod dra7xx_dcan2_hwmod = {
},
  };
  
 +/* pwmss  */
 +static struct omap_hwmod_class_sysconfig dra7xx_epwmss_sysc = {
 +  .rev_offs   = 0x0,
 +  .sysc_offs  = 0x4,
 +  .sysc_flags = SYSC_HAS_SIDLEMODE | SYSC_HAS_RESET_STATUS,
>>>
>>> This doesn't match SPRUHZ6 Table 29-13 "PWMSS_SYSCONFIG".  There's no 
>>> RESETSTATUS bit.  There is a SOFTRESET bit. 
>>>
>>> Could you please confirm whether this is intentional?
>>
>> sorry my bad... I will change this in v3.
>>
>>>
 +  .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
 +  .sysc_fields= &omap_hwmod_sysc_type2,
 +};
 +
 +struct omap_hwmod_class dra7xx_epwmss_hwmod_class = {
 +  .name   = "epwmss",
 +  .sysc   = &dra7xx_epwmss_sysc,
 +};
 +
 +static struct omap_hwmod_class dra7xx_ecap_hwmod_class = {
 +  .name   = "ecap",
 +};
 +
 +static struct omap_hwmod_class dra7xx_eqep_hwmod_class = {
 +  .name   = "eqep",
 +};
 +
 +struct omap_hwmod_class dra7xx_ehrpwm_hwmod_class = {
 +  .name   = "ehrpwm",
 +};
 +
 +/* epwmss0 */
 +struct omap_hwmod dra7xx_epwmss0_hwmod = {
 +  .name   = "epwmss0",
 +  .class  = &dra7xx_epwmss_hwmod_class,
 +  .clkdm_name = "l4per2_clkdm",
 +  .main_clk   = "l4_root_clk_div",
 +  .prcm   = {
 +  .omap4  = {
 +  .modulemode = MODULEMODE_SWCTRL,
 +  .clkctrl_offs   = 
 DRA7XX_CM_L4PER2_PWMSS1_CLKCTRL_OFFSET,
 +  .context_offs   = 
 DRA7XX_RM_L4PER2_PWMSS1_CONTEXT_OFFSET,
 +  },
 +  },
>>>
>>> Per my comment on the previous patch, sounds like it might be better to 
>>> mark this as HWMOD_SWSUP_SIDLE?  Then again, see the next comment below 
>>> re: main_clk.
>>>
 +};
 +
 +/* ecap0 */
 +struct omap_hwmod dra7xx_ecap0_hwmod = {
 +  .name   = "ecap0",
 +  .class  = &dra7xx_ecap_hwmod_class,
 +  .clkdm_name = "l4per2_clkdm",
 +  .main_clk   = "l4_root_clk_div",
>>>
>>> Looking at SPRUHZ6 Section 29.1.4.2 "PWMSS Modules Local Clock Gating", 
>>> there appears to be a local "mini-PRCM" for the PWMSS which implements 
>>> clock gating and reports back on the status of what I'd guess is the local 
>>> clock gating FSM.
>>>
>>> So from that point of view, you should probably create a clock driver that 
>>> manages both the clock gate request bit and the FSM status bit.  It should 
>>> be something that can be reused for the other PWMSS IP blocks.  Then 
>>> you'd create per-IP block clock nodes and set the main_clk to point to 
>>> that node.
>>>
>>
>> Since, this register is within the config space of PWMSS, the individual
>> gating and reporting for the modules within PWMSS
>> (PWMSS_CLKCONFIG) is currently being taken care by pwm-tipwmss.c(almost
>> the sole function this driver is doing). It has been the same since
>> am335x. Adding new clock nodes will result in driver changes and also
>> changes to am335x, am437x (and other platforms) hwmod files. It also
>> involves adding new nodes to clocks.dtsi and it will be difficult to
>> maintain backward compatibility for older platforms. Is it not better to
>> keep this as is, in order to maintain consistency (with am335x, am437x
>> etc) and also that thes

Re: [PATCH v3 5/6] iommu/mediatek: Add mt8173 IOMMU driver

[Yong Wu]

On Mon, 2015-07-27 at 14:23 +0100, Robin Murphy wrote:
> On 16/07/15 10:04, Yong Wu wrote:
> > This patch adds support for mediatek m4u (MultiMedia Memory Management
> > Unit).
> >
> > Signed-off-by: Yong Wu 
> [...]
> > +static void mtk_iommu_flush_pgtable(void *ptr, size_t size, void *cookie)
> > +{
> > +   struct mtk_iommu_domain *domain = cookie;
> > +   unsigned long offset = (unsigned long)ptr & ~PAGE_MASK;
> > +
> > +   dma_map_page(domain->data->dev, virt_to_page(ptr), offset,
> > +size, DMA_TO_DEVICE);
> 
> Nit: this looks like it may as well be dma_map_single.
> 
> It would probably be worth following it with a matching unmap too, just 
> to avoid any possible leakage bugs (especially if this M4U ever appears 
> in a SoC supporting RAM above the 32-bit boundary).

About the map, I will read and try to follow your patch:
iommu/io-pgtable-arm: Allow appropriate DMA API use.

> 
>  > +}
>  > +
> [...]
> > +static int mtk_iommu_parse_dt(struct platform_device *pdev,
> > + struct mtk_iommu_data *data)
> > +{
> > +   struct device *dev = &pdev->dev;
> > +   struct device_node *ofnode;
> > +   struct resource *res;
> > +   int i;
> > +
> > +   ofnode = dev->of_node;
> > +
> > +   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +   data->base = devm_ioremap_resource(&pdev->dev, res);
> > +   if (IS_ERR(data->base))
> > +   return PTR_ERR(data->base);
> > +
> > +   data->irq = platform_get_irq(pdev, 0);
> > +   if (data->irq < 0)
> > +   return data->irq;
> > +
> > +   data->bclk = devm_clk_get(dev, "bclk");
> > +   if (IS_ERR(data->bclk))
> > +   return PTR_ERR(data->bclk);
> > +
> > +   data->larb_nr = of_count_phandle_with_args(
> > +   ofnode, "mediatek,larb", NULL);
> > +   if (data->larb_nr < 0)
> > +   return data->larb_nr;
> > +
> > +   for (i = 0; i < data->larb_nr; i++) {
> > +   struct device_node *larbnode;
> > +   struct platform_device *plarbdev;
> > +
> > +   larbnode = of_parse_phandle(ofnode, "mediatek,larb", i);
> > +   if (!larbnode)
> > +   return -EINVAL;
> > +
> > +   plarbdev = of_find_device_by_node(larbnode);
> > +   of_node_put(larbnode);
> > +   if (!plarbdev)
> > +   return -EPROBE_DEFER;
> > +   data->larbdev[i] = &plarbdev->dev;
> > +   }
> 
> At a glance this seems like a job for of_parse_phandle_with_args, but I 
> may be missing something subtle.

It seems We can not use of_parse_phandle_with_args here.

The node of larb is.
//=
larb0: larb@14021000 {
compatible = "mediatek,mt8173-smi-larb";
reg = <0 0x14021000 0 0x1000>;
mediatek,smi = <&smi_common>;   
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_SMI_LARB0>,
 <&mmsys CLK_MM_SMI_LARB0>;
clock-names = "apb", "smi";
};
//==
  of_parse_phandle_with_args(ofnode,"mediatek,larb", "mediatek,smi",
&larb) will be wrong due to there is no item like "mediatek,smi = <1>;"
in larb.

And this code seems to be not simple if we use
of_parse_phandle_with_args. Both need a loop.

so I don't change it here, ok?
> 
> > +   return 0;
> > +}
> > +
> [...]
> > +static int mtk_iommu_init_domain_context(struct mtk_iommu_domain *dom)
> > +{
> > +   int ret;
> > +
> > +   if (dom->iop)
> > +   return 0;
> > +
> > +   spin_lock_init(&dom->pgtlock);
> > +   dom->cfg.quirks = IO_PGTABLE_QUIRK_ARM_NS |
> > +   IO_PGTABLE_QUIRK_SHORT_SUPERSECTION |
> > +   IO_PGTABLE_QUIRK_SHORT_MTK;
> > +   dom->cfg.pgsize_bitmap = mtk_iommu_ops.pgsize_bitmap,
> > +   dom->cfg.ias = 32;
> > +   dom->cfg.oas = 32;
> > +   dom->cfg.tlb = &mtk_iommu_gather_ops;
> > +
> > +   dom->iop = alloc_io_pgtable_ops(ARM_SHORT_DESC, &dom->cfg, dom);
> > +   if (!dom->iop) {
> > +   pr_err("Failed to alloc io pgtable\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   /* Update our support page sizes bitmap */
> > +   mtk_iommu_ops.pgsize_bitmap = dom->cfg.pgsize_bitmap;
> > +
> > +   ret = mtk_iommu_hw_init(dom);
> > +   if (ret)
> > +   free_io_pgtable_ops(dom->iop);
> > +
> > +   return ret;
> > +}
> 
> I don't see that you need the above function at all - since your 
> pagetable config is fixed and doesn't have any depency on which IOMMU 
> you're attaching to, can't you just do all of that straight away in 
> domain_alloc?

Yes. We could move it into domain_alloc.

> 
> > +static struct iommu_domain *mtk_iommu_domain_alloc(unsigned type)
> > +{
> > +   struct mtk_iommu_domain *priv;
> > +
> > +   /* We only support unmanaged domains for now */
> > +   if (typ

[PATCH 1/4] Input: max77693: Remove a read-only pwm_divisor field

[Krzysztof Kozlowski]

Storing a predefined PWM divisor in state container structure is
meaningless. The field, after initialization, is only read so this only
obfuscates the code. Remove the field and use directly enum value.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/input/misc/max77693-haptic.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/input/misc/max77693-haptic.c 
b/drivers/input/misc/max77693-haptic.c
index 4524499ea72f..8dc43c1ebf0e 100644
--- a/drivers/input/misc/max77693-haptic.c
+++ b/drivers/input/misc/max77693-haptic.c
@@ -60,7 +60,6 @@ struct max77693_haptic {
unsigned int pwm_duty;
enum max77693_haptic_motor_type type;
enum max77693_haptic_pulse_mode mode;
-   enum max77693_haptic_pwm_divisor pwm_divisor;
 
struct work_struct work;
 };
@@ -88,7 +87,7 @@ static int max77693_haptic_configure(struct max77693_haptic 
*haptic,
value = ((haptic->type << MAX77693_CONFIG2_MODE) |
(enable << MAX77693_CONFIG2_MEN) |
(haptic->mode << MAX77693_CONFIG2_HTYP) |
-   (haptic->pwm_divisor));
+   MAX77693_HAPTIC_PWM_DIVISOR_128);
 
error = regmap_write(haptic->regmap_haptic,
 MAX77693_HAPTIC_REG_CONFIG2, value);
@@ -259,7 +258,6 @@ static int max77693_haptic_probe(struct platform_device 
*pdev)
haptic->dev = &pdev->dev;
haptic->type = MAX77693_HAPTIC_LRA;
haptic->mode = MAX77693_HAPTIC_EXTERNAL_MODE;
-   haptic->pwm_divisor = MAX77693_HAPTIC_PWM_DIVISOR_128;
haptic->suspend_state = false;
 
INIT_WORK(&haptic->work, max77693_haptic_play_work);
-- 
1.9.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/

[PATCH 3/4] Input: max77693: Add support for Maxim 77843

[Krzysztof Kozlowski]

The Maxim 77843 haptic driver differs from 77693 by:
1. Setting the bias.
2. Different configuration register.
3. Not enabling the low-sys DAC.
4. Using same regmap for PMIC and haptic blocks.

Incorporate all differences into max77693 haptic driver so both devices
can be supported.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/input/misc/Kconfig   |  6 ++---
 drivers/input/misc/max77693-haptic.c | 48 +---
 2 files changed, 48 insertions(+), 6 deletions(-)

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index d4f0a817e858..f5d7a98a329d 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -167,12 +167,12 @@ config INPUT_M68K_BEEP
depends on M68K
 
 config INPUT_MAX77693_HAPTIC
-   tristate "MAXIM MAX77693 haptic controller support"
-   depends on MFD_MAX77693 && PWM
+   tristate "MAXIM MAX77693/MAX77843 haptic controller support"
+   depends on (MFD_MAX77693 || MFD_MAX77843) && PWM
select INPUT_FF_MEMLESS
help
  This option enables support for the haptic controller on
- MAXIM MAX77693 chip.
+ MAXIM MAX77693 and MAX77843 chips.
 
  To compile this driver as module, choose M here: the
  module will be called max77693-haptic.
diff --git a/drivers/input/misc/max77693-haptic.c 
b/drivers/input/misc/max77693-haptic.c
index 4c0f67ab66d9..6d96bff32a0e 100644
--- a/drivers/input/misc/max77693-haptic.c
+++ b/drivers/input/misc/max77693-haptic.c
@@ -1,8 +1,9 @@
 /*
- * MAXIM MAX77693 Haptic device driver
+ * MAXIM MAX77693/MAX77843 Haptic device driver
  *
- * Copyright (C) 2014 Samsung Electronics
+ * Copyright (C) 2014,2015 Samsung Electronics
  * Jaewon Kim 
+ * Krzysztof Kozlowski 
  *
  * This program is not provided / owned by Maxim Integrated Products.
  *
@@ -26,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define MAX_MAGNITUDE_SHIFT16
 
@@ -80,6 +82,26 @@ static int max77693_haptic_set_duty_cycle(struct 
max77693_haptic *haptic)
return 0;
 }
 
+static int max77843_haptic_bias(struct max77693_haptic *haptic, bool on)
+{
+   int error;
+
+   if (haptic->dev_type != TYPE_MAX77843)
+   return 0;
+
+   error = regmap_update_bits(haptic->regmap_haptic,
+  MAX77843_SYS_REG_MAINCTRL1,
+  MAX77843_MAINCTRL1_BIASEN_MASK,
+  on << MAINCTRL1_BIASEN_SHIFT);
+   if (error) {
+   dev_err(haptic->dev, "failed to %s bias: %d\n",
+   on ? "enable" : "disable", error);
+   return error;
+   }
+
+   return 0;
+}
+
 static int max77693_haptic_configure(struct max77693_haptic *haptic,
 bool enable)
 {
@@ -94,6 +116,12 @@ static int max77693_haptic_configure(struct max77693_haptic 
*haptic,
MAX77693_HAPTIC_PWM_DIVISOR_128);
config_reg = MAX77693_HAPTIC_REG_CONFIG2;
break;
+   case TYPE_MAX77843:
+   value = (haptic->type << MCONFIG_MODE_SHIFT) |
+   (enable << MCONFIG_MEN_SHIFT) |
+   MAX77693_HAPTIC_PWM_DIVISOR_128;
+   config_reg = MAX77843_HAP_REG_MCONFIG;
+   break;
default:
return -EINVAL;
}
@@ -113,6 +141,9 @@ static int max77693_haptic_lowsys(struct max77693_haptic 
*haptic, bool enable)
 {
int error;
 
+   if (haptic->dev_type != TYPE_MAX77693)
+   return 0;
+
error = regmap_update_bits(haptic->regmap_pmic,
   MAX77693_PMIC_REG_LSCNFG,
   MAX77693_PMIC_LOW_SYS_MASK,
@@ -228,6 +259,10 @@ static int max77693_haptic_open(struct input_dev *dev)
struct max77693_haptic *haptic = input_get_drvdata(dev);
int error;
 
+   error = max77843_haptic_bias(haptic, true);
+   if (error)
+   return error;
+
error = regulator_enable(haptic->motor_reg);
if (error) {
dev_err(haptic->dev,
@@ -250,6 +285,8 @@ static void max77693_haptic_close(struct input_dev *dev)
if (error)
dev_err(haptic->dev,
"failed to disable regulator: %d\n", error);
+
+   max77843_haptic_bias(haptic, false);
 }
 
 static int max77693_haptic_probe(struct platform_device *pdev)
@@ -274,6 +311,9 @@ static int max77693_haptic_probe(struct platform_device 
*pdev)
case TYPE_MAX77693:
haptic->regmap_haptic = max77693->regmap_haptic;
break;
+   case TYPE_MAX77843:
+   haptic->regmap_haptic = max77693->regmap;
+   break;
default:
dev_err(&pdev->dev, "unsupported device type: %u\n",
haptic->dev_type);
@@ -359,6 +399,7 @@ static SIMPLE_DEV_PM_OPS(max77693_haptic_pm_ops,
 
 static const struct 

[PATCH 2/4] Input: max77693: Prepare for adding support for Maxim 77843

[Krzysztof Kozlowski]

Prepare the driver for supporting two devices: Maxim 77693 and 77843:
1. Add table of device ids and store current device type for later
   usage.
2. Differentiate the haptic device configuration.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/input/misc/max77693-haptic.c | 41 ++--
 1 file changed, 34 insertions(+), 7 deletions(-)

diff --git a/drivers/input/misc/max77693-haptic.c 
b/drivers/input/misc/max77693-haptic.c
index 8dc43c1ebf0e..4c0f67ab66d9 100644
--- a/drivers/input/misc/max77693-haptic.c
+++ b/drivers/input/misc/max77693-haptic.c
@@ -47,6 +47,8 @@ enum max77693_haptic_pwm_divisor {
 };
 
 struct max77693_haptic {
+   enum max77693_types dev_type;
+
struct regmap *regmap_pmic;
struct regmap *regmap_haptic;
struct device *dev;
@@ -81,16 +83,23 @@ static int max77693_haptic_set_duty_cycle(struct 
max77693_haptic *haptic)
 static int max77693_haptic_configure(struct max77693_haptic *haptic,
 bool enable)
 {
-   unsigned int value;
+   unsigned int value, config_reg;
int error;
 
-   value = ((haptic->type << MAX77693_CONFIG2_MODE) |
-   (enable << MAX77693_CONFIG2_MEN) |
-   (haptic->mode << MAX77693_CONFIG2_HTYP) |
-   MAX77693_HAPTIC_PWM_DIVISOR_128);
+   switch (haptic->dev_type) {
+   case TYPE_MAX77693:
+   value = ((haptic->type << MAX77693_CONFIG2_MODE) |
+   (enable << MAX77693_CONFIG2_MEN) |
+   (haptic->mode << MAX77693_CONFIG2_HTYP) |
+   MAX77693_HAPTIC_PWM_DIVISOR_128);
+   config_reg = MAX77693_HAPTIC_REG_CONFIG2;
+   break;
+   default:
+   return -EINVAL;
+   }
 
error = regmap_write(haptic->regmap_haptic,
-MAX77693_HAPTIC_REG_CONFIG2, value);
+config_reg, value);
if (error) {
dev_err(haptic->dev,
"failed to update haptic config: %d\n", error);
@@ -254,12 +263,23 @@ static int max77693_haptic_probe(struct platform_device 
*pdev)
return -ENOMEM;
 
haptic->regmap_pmic = max77693->regmap;
-   haptic->regmap_haptic = max77693->regmap_haptic;
haptic->dev = &pdev->dev;
haptic->type = MAX77693_HAPTIC_LRA;
haptic->mode = MAX77693_HAPTIC_EXTERNAL_MODE;
haptic->suspend_state = false;
 
+   /* Variant-specific init */
+   haptic->dev_type = platform_get_device_id(pdev)->driver_data;
+   switch (haptic->dev_type) {
+   case TYPE_MAX77693:
+   haptic->regmap_haptic = max77693->regmap_haptic;
+   break;
+   default:
+   dev_err(&pdev->dev, "unsupported device type: %u\n",
+   haptic->dev_type);
+   return -EINVAL;
+   }
+
INIT_WORK(&haptic->work, max77693_haptic_play_work);
 
/* Get pwm and regulatot for haptic device */
@@ -337,12 +357,19 @@ static int __maybe_unused max77693_haptic_resume(struct 
device *dev)
 static SIMPLE_DEV_PM_OPS(max77693_haptic_pm_ops,
 max77693_haptic_suspend, max77693_haptic_resume);
 
+static const struct platform_device_id max77693_haptic_id[] = {
+   { "max77693-haptic", TYPE_MAX77693 },
+   {},
+};
+MODULE_DEVICE_TABLE(platform, max77693_haptic_id);
+
 static struct platform_driver max77693_haptic_driver = {
.driver = {
.name   = "max77693-haptic",
.pm = &max77693_haptic_pm_ops,
},
.probe  = max77693_haptic_probe,
+   .id_table   = max77693_haptic_id,
 };
 module_platform_driver(max77693_haptic_driver);
 
-- 
1.9.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/

[PATCH 0/4] Input: Merge max77843 haptic driver into max77693

[Krzysztof Kozlowski]

Hi,


Description
===
The Maxim 77843 haptic driver differs from 77693 by:
1. Setting the bias.
2. Different configuration register.
3. Not enabling the low-sys DAC.
4. Using same regmap for PMIC and haptic blocks.

The patchset merges max77843 driver into the max77693.


Dependencies

The patchset *depends on* "regulator: Merge max77843 into max77693" [0]
which was applied by Mark Brown (regulator tree). The mentioned
regulator patchset actually changed also MFD drivers and other headers
so the child drivers (like max77693 regulator or haptic) can be used
with both max77693 and max77843 main MFD drivers.


Merging ideas
=
0. Patches 1 and 2 can be applied directly.
For rest of it (patches 3 and 4):
1. If this will go to v4.3, then maybe Mark Brown could prepare
   an immutable branch (or a tag) with the [0] patchset?
2. If this will go to v4.4, then patchset can wait till MFD/regulator
   changes reach Linus' tree.


Best regards,
Krzysztof

[0] https://lkml.org/lkml/2015/7/15/554


Krzysztof Kozlowski (4):
  Input: max77693: Remove a read-only pwm_divisor field
  Input: max77693: Prepare for adding support for Maxim 77843
  Input: max77693: Add support for Maxim 77843
  Input: Remove the max77843 haptic driver

 drivers/input/misc/Kconfig   |  18 +-
 drivers/input/misc/Makefile  |   1 -
 drivers/input/misc/max77693-haptic.c |  91 +++--
 drivers/input/misc/max77843-haptic.c | 359 ---
 4 files changed, 82 insertions(+), 387 deletions(-)
 delete mode 100644 drivers/input/misc/max77843-haptic.c

-- 
1.9.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/

[PATCH 4/4] Input: Remove the max77843 haptic driver

[Krzysztof Kozlowski]

The max77693 haptic driver supports Maxim 77843 device so remove the
max77843 driver.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/input/misc/Kconfig   |  12 --
 drivers/input/misc/Makefile  |   1 -
 drivers/input/misc/max77843-haptic.c | 359 ---
 3 files changed, 372 deletions(-)
 delete mode 100644 drivers/input/misc/max77843-haptic.c

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index f5d7a98a329d..c41dec819cdf 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -177,18 +177,6 @@ config INPUT_MAX77693_HAPTIC
  To compile this driver as module, choose M here: the
  module will be called max77693-haptic.
 
-config INPUT_MAX77843_HAPTIC
-tristate "MAXIM MAX77843 haptic controller support"
-depends on MFD_MAX77843 && REGULATOR
-select INPUT_FF_MEMLESS
-help
-  This option enables support for the haptic controller on
-  MAXIM MAX77843 chip. The driver supports ff-memless interface
-  from input framework.
-
-  To compile this driver as module, choose M here: the
-  module will be called max77843-haptic.
-
 config INPUT_MAX8925_ONKEY
tristate "MAX8925 ONKEY support"
depends on MFD_MAX8925
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 53df07dcc23c..0357a088c6a9 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -41,7 +41,6 @@ obj-$(CONFIG_INPUT_KEYSPAN_REMOTE)+= keyspan_remote.o
 obj-$(CONFIG_INPUT_KXTJ9)  += kxtj9.o
 obj-$(CONFIG_INPUT_M68K_BEEP)  += m68kspkr.o
 obj-$(CONFIG_INPUT_MAX77693_HAPTIC)+= max77693-haptic.o
-obj-$(CONFIG_INPUT_MAX77843_HAPTIC)+= max77843-haptic.o
 obj-$(CONFIG_INPUT_MAX8925_ONKEY)  += max8925_onkey.o
 obj-$(CONFIG_INPUT_MAX8997_HAPTIC) += max8997_haptic.o
 obj-$(CONFIG_INPUT_MC13783_PWRBUTTON)  += mc13783-pwrbutton.o
diff --git a/drivers/input/misc/max77843-haptic.c 
b/drivers/input/misc/max77843-haptic.c
deleted file mode 100644
index 30da81ab5a21..
--- a/drivers/input/misc/max77843-haptic.c
+++ /dev/null
@@ -1,359 +0,0 @@
-/*
- * MAXIM MAX77693 Haptic device driver
- *
- * Copyright (C) 2015 Samsung Electronics
- * Author: Jaewon Kim 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#define MAX_MAGNITUDE_SHIFT16
-
-enum max77843_haptic_motor_type {
-   MAX77843_HAPTIC_ERM = 0,
-   MAX77843_HAPTIC_LRA,
-};
-
-enum max77843_haptic_pwm_divisor {
-   MAX77843_HAPTIC_PWM_DIVISOR_32 = 0,
-   MAX77843_HAPTIC_PWM_DIVISOR_64,
-   MAX77843_HAPTIC_PWM_DIVISOR_128,
-   MAX77843_HAPTIC_PWM_DIVISOR_256,
-};
-
-struct max77843_haptic {
-   struct regmap *regmap_haptic;
-   struct device *dev;
-   struct input_dev *input_dev;
-   struct pwm_device *pwm_dev;
-   struct regulator *motor_reg;
-   struct work_struct work;
-   struct mutex mutex;
-
-   unsigned int magnitude;
-   unsigned int pwm_duty;
-
-   bool active;
-   bool suspended;
-
-   enum max77843_haptic_motor_type type;
-   enum max77843_haptic_pwm_divisor pwm_divisor;
-};
-
-static int max77843_haptic_set_duty_cycle(struct max77843_haptic *haptic)
-{
-   int delta = (haptic->pwm_dev->period + haptic->pwm_duty) / 2;
-   int error;
-
-   error = pwm_config(haptic->pwm_dev, delta, haptic->pwm_dev->period);
-   if (error) {
-   dev_err(haptic->dev, "failed to configure pwm: %d\n", error);
-   return error;
-   }
-
-   return 0;
-}
-
-static int max77843_haptic_bias(struct max77843_haptic *haptic, bool on)
-{
-   int error;
-
-   error = regmap_update_bits(haptic->regmap_haptic,
-  MAX77843_SYS_REG_MAINCTRL1,
-  MAX77843_MAINCTRL1_BIASEN_MASK,
-  on << MAINCTRL1_BIASEN_SHIFT);
-   if (error) {
-   dev_err(haptic->dev, "failed to %s bias: %d\n",
-   on ? "enable" : "disable", error);
-   return error;
-   }
-
-   return 0;
-}
-
-static int max77843_haptic_config(struct max77843_haptic *haptic, bool enable)
-{
-   unsigned int value;
-   int error;
-
-   value = (haptic->type << MCONFIG_MODE_SHIFT) |
-   (enable << MCONFIG_MEN_SHIFT) |
-   (haptic->pwm_divisor << MCONFIG_PDIV_SHIFT);
-
-   error = regmap_write(haptic->regmap_haptic,
-MAX77843_HAP_REG_MCONFIG, value);
-   if (error) {
-   dev_err(haptic->dev,
-   "failed to u

Re: [RFCv2 1/3] docs: dts: Added documentation for Xilinx Zynq Reset Controller bindings.

[Moritz Fischer]

Hi Sören,

On Tue, Jul 28, 2015 at 3:53 PM, Sören Brinkmann
 wrote:
> On Mon, 2015-07-27 at 09:52PM -0700, Moritz Fischer wrote:
>> Hi Sören,
>>
>> thanks for your feedback.
>>
>> On Mon, Jul 27, 2015 at 7:58 PM, Sören Brinkmann
>>  wrote:
>> > Hi Moritz,
>> >
>> > On Fri, 2015-07-24 at 05:21PM -0700, Moritz Fischer wrote:
>> >> Signed-off-by: Moritz Fischer 
>> >> ---
>> >>  Documentation/devicetree/bindings/reset/zynq-reset-pl.txt | 13 
>> >> +
>> >>  1 file changed, 13 insertions(+)
>> >>  create mode 100644 
>> >> Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt 
>> >> b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>> >> new file mode 100644
>> >> index 000..ac4499e
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>> >> @@ -0,0 +1,13 @@
>> >> +Xilinx Zynq PL Reset Manager
>> >> +
>> >> +Required properties:
>> >> +- compatible: "xlnx,zynq-reset-pl"
>> >> +- syscon <&slcr>;
>> >> +- #reset-cells: 1
>> >> +
>> >> +Example:
>> >> + rstc: rstc@240 {
>> >> + #reset-cells = <1>;
>> >> + compatible = "xlnx,zynq-reset-pl";
>> >> + syscon = <&slcr>;
>> >> + };
>> >
>> > I think you also have to add the outputs and make them part of the
>> > binding. Otherwise you'd have to read the implementation to find
>> > out what device should be hooked up to which output of the 
>> > reset-controller.
>>
>> Is something like this what you had in mind? I had that prepared for
>> the next round of patches:
>>
>> Reset outputs:
>>  0  : soft reset
>>  32 : ddr reset
>>  64 : topsw reset
>>  96 : dmac reset
>>  128: usb0 reset
>>  129: usb1 reset
>>  160: gem0 reset
>>  161: gem1 reset
>>  164: gem0 rx reset
>>  165: gem1 rx reset
>>  166: gem0 ref reset
>>  167: gem1 ref reset
>>  192: sdio0 reset
>>  193: sdio1 reset
>>  196: sdio0 ref reset
>>  197: sdio1 ref reset
>>  224: spi0 reset
>>  225: spi1 reset
>>  226: spi0 ref reset
>>  227: spi1 ref reset
>>  256: can0 reset
>>  257: can1 reset
>>  258: can0 ref reset
>>  259: can1 ref reset
>>  288: i2c0 reset
>>  289: i2c1 reset
>>  320: uart0 reset
>>  321: uart1 reset
>>  322: uart0 ref reset
>>  323: uart1 ref reset
>>  352: gpio reset
>>  384: lqspi reset
>>  385: qspi ref reset
>>  416: smc reset
>>  417: smc ref reset
>>  448: ocm reset
>>  512: fpga0 out reset
>>  513: fpga1 out reset
>>  514: fpga2 out reset
>>  515: fpga3 out reset
>>  544: a9 reset 0
>>  545: a9 reset 1
>>  552: peri reset
>
> Basically, yes. I guess the gaps are due to directly mapping this number
> to bank and bit instead of doing some more complex mapping in between?
> I'm not sure whether I like this :) I guess if a number is off the
> driver would still toggle the addressed bit?

My assumption was that people would use a #include
 in their dts. Assuming I got the
numbers in there right this makes it hard to misuse by accident.
I'm not saying it's perfect ...

> I'm not sure, is it worth
> to do some explicit mapping from logical outputs to a physical reset? It
> seems it would be a little safer since it would be easy to check that
> the addressed reset is valid and there wouldn't be any reserved/invalid
> bits be toggled. Also, it would make the outputs in here a continuous
> series of numbers without these gaps. Not sure though whether
> it's worth the additional complexity in the implementation.

So your suggestion is to have a large switch case kind of thingy? I
thought about it and it seemed complex as there's quite a bunch of
resets with gaps. Do you know of a driver that does something similar?
When I wrote this I looked at the other reset drivers and figured they
all had this kind of bank mapping of sorts so I assumed that's how
people usually do it.

>
> Thanks,
> Sören

Thanks again for your input,

Moritz
--
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 04/22] of/platform: add of_platform_device_find()

[Tomeu Vizoso]

On 28 July 2015 at 17:31, Rob Herring  wrote:
> On Tue, Jul 28, 2015 at 8:54 AM, Tomeu Vizoso
>  wrote:
>> On 28 July 2015 at 15:39, Rob Herring  wrote:
>>> On Tue, Jul 28, 2015 at 8:19 AM, Tomeu Vizoso
>>>  wrote:
 From an arbitrary node in the tree, find the enclosing node that
 corresponds to a platform device, as registered by
 of_platform_populate().

 This can be used to find out what device needs to be probed so the
 dependency described by a given node is made available.

 Signed-off-by: Tomeu Vizoso 
 ---

 Changes in v2:
 - Move the logic for finding a platform device from its firmware node to
   of/platform.c as it's not needed for ACPI nodes.

  drivers/of/platform.c   | 60 
 +
  include/linux/of_platform.h |  1 +
  2 files changed, 61 insertions(+)

 diff --git a/drivers/of/platform.c b/drivers/of/platform.c
 index ff27494cda8c..89c5cd513027 100644
 --- a/drivers/of/platform.c
 +++ b/drivers/of/platform.c
 @@ -501,6 +501,66 @@ void of_platform_depopulate(struct device *parent)
  }
  EXPORT_SYMBOL_GPL(of_platform_depopulate);

 +static bool of_is_platform(struct device_node *np)
 +{
 +   int count;
 +
 +   count = of_property_count_strings(np, "compatible");
 +
 +   /* The node has to have a compatible string */
 +   if (!count)
 +   return false;
 +
 +   /* But it cannot be just a simple memory-mapped bus */
 +   if (count == 1 && of_match_node(of_default_bus_match_table, np))
 +   return false;
 +
 +   /* But AMBA devices aren't platform devices */
 +   if (of_device_is_compatible(np, "arm,primecell"))
 +   return false;
 +
 +   /* Node is immediately below root */
 +   if (!np->parent || !np->parent->parent)
 +   return true;
 +
 +   /* If it's a node in a simple memory-mapped bus */
 +   if (of_match_node(of_default_bus_match_table, np->parent))
 +   return true;
>>>
>>> This seems really fragile.
>>
>> I think this finding logic matches the logic for registering platform
>> devices in of_platform_populate and also what is documented in
>> Documentation/devicetree/usage-model.txt.
>
> Right. So now we have that logic in 2 places. One is descending from
> the root and one is walking up from the child. That's an opportunity
> for some mismatch.

Definitely.

>>> What about platform devices which are
>>> children of MFDs but are not "simple-mfd"?
>>
>> This code should deal fine with those (the boards I tested with do
>> have them). It probes the mfd master, and that in turn will call
>> mfd_add_devices causing the target device to be probed.
>
> I don't see how this function would ever return true in this case
> unless you put the MFD at the root level. The only other way to return
> true is matching on of_default_bus_match_table for the parent (i.e.
> the MFD).

Oops, you are right.

>>> Does of_find_device_by_node not work for you?
>>
>> Well, the dependencies aren't always platform devices, that's why I
>> need to go up the tree until I find a node that corresponds to a
>> platform device that I can query and probe.
>>
>> If I had a way to get, say, a i2c device from its fwnode then I would
>> just need to make sure that a device's parent is probed before probing
>> it and everything would be cleaner in the OF case.
>
> If you have the struct device from the device_node, then you should be
> able to do this, right?

Yes, if I could go back from the device_node to the struct device that
was registered from it, for all buses, then all this would be much
simpler and more robust. It would basically work like in the ACPI
case.

I will play with this idea.

>>> That is probably not the
>>> most efficient search, but we could fix that. We could add struct
>>> device ptr to struct device_node and check without searching for
>>> example.
>>
>> That would be great, but I thought there was an issue with a OF node
>> being able to be related to more than one struct device (but I haven't
>> found this myself yet).
>
> I think it pretty much should be one to one. I'm not aware of any
> examples where that is not the case. This function would already be
> broken if you could have more than one struct device.

Well, for platform devices we currently know that there can only be
one struct device for a given device_node, but that's not so clear for
other devices.

> There is an issue where you could have 2 drivers match the same node,
> but on different compatible strings. But that's a different issue.

Yup.

Thanks,

Tomeu

> Rob
> --
> 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 F

[PATCH] drivers/rtc/rtc-pl031.c: fix typo for author email

[Leo Yan]

The email address missed character ">", so add it.

Signed-off-by: Leo Yan 
---
 drivers/rtc/rtc-pl031.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-pl031.c b/drivers/rtc/rtc-pl031.c
index 99181fff..41dcb7d 100644
--- a/drivers/rtc/rtc-pl031.c
+++ b/drivers/rtc/rtc-pl031.c
@@ -476,6 +476,6 @@ static struct amba_driver pl031_driver = {
 
 module_amba_driver(pl031_driver);
 
-MODULE_AUTHOR("Deepak Saxena ");
 MODULE_DESCRIPTION("ARM AMBA PL031 RTC Driver");
 MODULE_LICENSE("GPL");
-- 
1.9.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/

[PATCH] memstick: fix Kconfig typo

[AceLan Kao]

The module name of the Realtek USB Memstick Card Interface Driver should be
rtsx_usb_ms, instead of rts5139_ms.

Signed-off-by: AceLan Kao 
---
 drivers/memstick/host/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/memstick/host/Kconfig b/drivers/memstick/host/Kconfig
index 7310e32..1add71a 100644
--- a/drivers/memstick/host/Kconfig
+++ b/drivers/memstick/host/Kconfig
@@ -61,4 +61,4 @@ config MEMSTICK_REALTEK_USB
  of Realtek RTS5129/39 series USB card reader
 
  To compile this driver as a module, choose M here: the module will
- be called rts5139_ms.
+ be called rtsx_usb_ms.
-- 
2.1.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 RFC 2/3] x86: Add Intel PT logger

[Alexander Shishkin]

Takao Indoh  writes:

> This patch provides Intel PT logging feature. When system boots with a
> parameter "intel_pt_log", log buffers for Intel PT are allocated and
> logging starts, then processor flow information is written in the log
> buffer by hardware like flight recorder. This is very helpful to
> investigate a cause of kernel panic.
>
> The log buffer size is specified by the parameter
> "intel_pt_log_buf_len=". This buffer is used as circular buffer,
> therefore old events are overwritten by new events.

[skip]

> +static void enable_pt(int enable)
> +{
> + u64 ctl;
> +
> + rdmsrl(MSR_IA32_RTIT_CTL, ctl);

Ideally, you shouldn't need this rdmsr(), because in this code you
should know exactly which ctl bits you need set when you enable.

> +
> + if (enable)
> + ctl |= RTIT_CTL_TRACEEN;
> + else
> + ctl &= ~RTIT_CTL_TRACEEN;
> +
> + wrmsrl(MSR_IA32_RTIT_CTL, ctl);
> +}

But the bigger problem with this approach is that it duplicates the
existing driver's functionality and some of the code, which just makes
it harder to maintain amoung other things.

Instead, we should be able to do use the existing perf functionality to
enable the system-wide tracing, so that it goes through the
driver. Another thing to remember is that you'd also need some of the
sideband data (vm mappings, context switches) to be able to properly
decode the trace, which also can come from perf. And it'd also be much
less code. The only missing piece is the code that would allocate the
ring buffer for such events.

Something like:

static DEFINE_PER_CPU(struct perf_event *, perf_kdump_event);

static struct perf_event_attr perf_kdump_attr;

...

static int perf_kdump_init(void)
{
struct perf_event *event;
int cpu;

get_online_cpus();
for_each_possible_cpu(cpu) {
event = perf_create_kernel_counter(&perf_kdump_attr,
   cpu, NULL,
   NULL, NULL);

...

ret = rb_alloc_kernel(event, perf_kdump_data_size, 
perf_kdump_aux_size);

...

per_cpu(perf_kdump_event, cpu) = event;
}
put_online_cpus();
}
--
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] drivers/rtc/rtc-pl031.c: reset registers in init flow

[Leo Yan]

When use rtc-pl031 for suspend test on Hisilicon's SoC Hi6220, Usually
the data register (DR) will read back as value zero. So the suspend
test code will set the match register (MR) for 10 seconds' timeout; But
there have chance later will read back some random values from DR
register; So finally miss with match value and will not trigger
waken up event anymore.

This issue can be dismissed by reset registers in initialization flow;
And this code have no harm for ST's variant.

Signed-off-by: Leo Yan 
---
 drivers/rtc/rtc-pl031.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/rtc/rtc-pl031.c b/drivers/rtc/rtc-pl031.c
index 99181fff..01768de 100644
--- a/drivers/rtc/rtc-pl031.c
+++ b/drivers/rtc/rtc-pl031.c
@@ -345,6 +345,12 @@ static int pl031_probe(struct amba_device *adev, const 
struct amba_id *id)
dev_dbg(&adev->dev, "designer ID = 0x%02x\n", amba_manf(adev));
dev_dbg(&adev->dev, "revision = 0x%01x\n", amba_rev(adev));
 
+   /* Init registers */
+   writel(0x0, ldata->base + RTC_LR);
+   writel(0x0, ldata->base + RTC_DR);
+   writel(0x0, ldata->base + RTC_IMSC);
+   writel(RTC_BIT_AI, ldata->base + RTC_ICR);
+
data = readl(ldata->base + RTC_CR);
/* Enable the clockwatch on ST Variants */
if (vendor->clockwatch)
-- 
1.9.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: [PATCH RFC 0/3] x86: Intel Processor Trace Logger

[Takao Indoh]

On 2015/07/29 14:44, Alexander Shishkin wrote:
> Takao Indoh  writes:
> 
>> Hi all,
>>
>> This patch creates log buffer for Intel PT and enable logging at boot
>> time. When kernel panic occurs, we can get this log buffer from
>> crashdump file by kdump, and reconstruct the flow that led to the panic.
> 
> Good to see this work going forward!
> 
>> Takao Indoh (3):
>>x86: Add Intel PT common files
>>x86: Add Intel PT logger
>>x86: Stop Intel PT and save its registers when panic occurs
>>
>>   arch/x86/Kconfig  |   16 ++
>>   arch/x86/include/asm/intel_pt.h   |   84 +
>>   arch/x86/kernel/cpu/Makefile  |3 +
>>   arch/x86/kernel/cpu/intel_pt.h|  131 -
>>   arch/x86/kernel/cpu/intel_pt_cap.c|   69 +++
>>   arch/x86/kernel/cpu/intel_pt_log.c|  288 
>> +
>>   arch/x86/kernel/cpu/intel_pt_perf.h   |   78 
>>   arch/x86/kernel/cpu/perf_event_intel_pt.c |   54 +-
>>   arch/x86/kernel/crash.c   |9 +
>>   9 files changed, 556 insertions(+), 176 deletions(-)
>>   create mode 100644 arch/x86/include/asm/intel_pt.h
>>   delete mode 100644 arch/x86/kernel/cpu/intel_pt.h
>>   create mode 100644 arch/x86/kernel/cpu/intel_pt_cap.c
>>   create mode 100644 arch/x86/kernel/cpu/intel_pt_log.c
>>   create mode 100644 arch/x86/kernel/cpu/intel_pt_perf.h
> 
> One note here: you want to use -M with git-format-patch so that renames
> are handled better.

Thank you, I didn't know this option. I'll do next time.

Thanks,
Takao Indoh


> 
> Regards,
> --
> 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: Re: [V2 PATCH 1/3] x86/panic: Fix re-entrance problem due to panic on NMI

[河合英宏 / KAWAI，HIDEHIRO]

Hi,

> From: linux-kernel-ow...@vger.kernel.org 
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Hidehiro Kawai
> (2015/07/27 23:34), Michal Hocko wrote:
> > On Mon 27-07-15 10:58:50, Hidehiro Kawai wrote:
[...]
> > The check could be also relaxed a bit and nmi_panic would
> > return only if the ongoing panic is the current cpu when we really have
> > to return and allow the preempted panic to finish.
> 
> It's reasonable.  I'll do that in the next version.

I noticed atomic_read() is insufficient.  Please consider the following
scenario.

CPU 1: call panic() in the normal context
CPU 0: call nmi_panic(), check the value of panic_cpu, then call panic()
CPU 1: set 1 to panic_cpu
CPU 0: fail to set 0 to panic_cpu, then do an infinite loop
CPU 1: call crash_kexec(), then call kdump_nmi_shootdown_cpus()

At this point, since CPU 0 loops in NMI context, it never executes
the NMI handler registered by kdump_nmi_shootdown_cpus().  This means
that no register states are saved and no cleanups for VMX/SVM are
performed.  So, we should still use atomic_cmpxchg() in nmi_panic() to
prevent other cpus from running panic routines.

> > +void nmi_panic(const char *fmt, ...)
> > +{
> > +   /*
> > +* We have to back off if the NMI has preempted an ongoing panic and
> > +* allow it to finish
> > +*/
> > +   if (atomic_read(&panic_cpu) == raw_smp_processor_id())
> > +   return;
> > +
> > +   panic();
> > +}
> > +EXPORT_SYMBOL(nmi_panic);

--
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] input: twl4030-vibra: Fix ERROR: Bad of_node_put() warning

[Dr. H. Nikolaus Schaller]

Hi all,

Am 29.07.2015 um 05:13 schrieb Rob Herring :

> On Tue, Jul 28, 2015 at 3:23 PM, Belisko Marek  
> wrote:
>> Hi Dmitry,
>> 
>> On Thu, Jul 23, 2015 at 10:53 PM, Dmitry Torokhov
>>  wrote:
>>> On Thu, Jul 23, 2015 at 10:38:34PM +0200, Marek Belisko wrote:
 Fix following:
 [8.862274] ERROR: Bad of_node_put() on /ocp/i2c@4807/twl@48/audio
 [8.869293] CPU: 0 PID: 1003 Comm: modprobe Not tainted 
 4.2.0-rc2-letux+ #1175
 [8.876922] Hardware name: Generic OMAP36xx (Flattened Device Tree)
 [8.883514] [] (unwind_backtrace) from [] 
 (show_stack+0x10/0x14)
 [8.891693] [] (show_stack) from [] 
 (dump_stack+0x78/0x94)
 [8.899322] [] (dump_stack) from [] 
 (kobject_release+0x68/0x7c)
 [8.907409] [] (kobject_release) from [] 
 (twl4030_vibra_probe+0x74/0x188 [twl4030_vibra])
 [8.917877] [] (twl4030_vibra_probe [twl4030_vibra]) from 
 [] (platform_drv_probe+0x48/0x90)
 [8.928497] [] (platform_drv_probe) from [] 
 (really_probe+0xd4/0x238)
 [8.937103] [] (really_probe) from [] 
 (driver_probe_device+0x30/0x48)
 [8.945678] [] (driver_probe_device) from [] 
 (__driver_attach+0x68/0x8c)
 [8.954589] [] (__driver_attach) from [] 
 (bus_for_each_dev+0x50/0x84)
 [8.963226] [] (bus_for_each_dev) from [] 
 (bus_add_driver+0xcc/0x1e4)
 [8.971832] [] (bus_add_driver) from [] 
 (driver_register+0x9c/0xe0)
 [8.980255] [] (driver_register) from [] 
 (do_one_initcall+0x100/0x1b8)
 [8.988983] [] (do_one_initcall) from [] 
 (do_init_module+0x58/0x1c0)
 [8.997497] [] (do_init_module) from [] 
 (SyS_init_module+0x54/0x64)
 [9.005950] [] (SyS_init_module) from [] 
 (ret_fast_syscall+0x0/0x54)
 [9.015838] input: twl4030:vibrator as 
 /devices/platform/6800.ocp/4807.i2c/i2c-0/0-0048/4807.i2c:twl@48:audio/input/input2
 
 node passed to of_find_node_by_name is put inside that function and new 
 node
 is returned if found. Free returned node not already freed node.
>>> 
>>> Hmm, if of_find_node_by_name() "puts" passed in node should we not "get"
>>> it before calling of_find_node_by_name()? The node pointer in question
>>> is simply copied from parent device.
>> I'm not sure. what I can say is that I cannot see such error in 4.1
>> but only in 4.2-rcx.
>> Adding Grant and Rob to CC, maybe they know what should be done and
>> why I see such error in 4.2-rcx.
> 
> The problem was that node passed into of_find_node_by_name is the the
> starting point to search, but you should be doing the put on the
> returned node. So the patch below is correct.

Fine!

We have a similar error on OMAP5 here:

[   11.027144] CPU: 1 PID: 6 Comm: kworker/u4:0 Not tainted 4.2.0-rc4-letux+ 
#1187
[   11.034790] Hardware name: Generic OMAP5 (Flattened Device Tree)
[   11.041077] Workqueue: deferwq deferred_probe_work_func
[   11.046557] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[   11.054663] [] (show_stack) from [] 
(dump_stack+0x78/0x94)
[   11.062224] [] (dump_stack) from [] 
(kobject_release+0x68/0x7c)
[   11.070234] [] (kobject_release) from [] 
(omapdss_of_find_source_for_first_ep+0x58/0x74)
[   11.080510] [] (omapdss_of_find_source_for_first_ep) from 
[] (hdmic_probe+0xb4/0x22c [connector_hdmi])
[   11.092080] [] (hdmic_probe [connector_hdmi]) from [] 
(platform_drv_probe+0x48/0x90)
[   11.101997] [] (platform_drv_probe) from [] 
(really_probe+0xd4/0x238)
[   11.110556] [] (really_probe) from [] 
(driver_probe_device+0x30/0x48)
[   11.119108] [] (driver_probe_device) from [] 
(bus_for_each_drv+0x4c/0x84)
[   11.128023] [] (bus_for_each_drv) from [] 
(__device_attach+0x70/0xd0)
[   11.136579] [] (__device_attach) from [] 
(bus_probe_device+0x28/0x84)
[   11.145135] [] (bus_probe_device) from [] 
(deferred_probe_work_func+0x58/0x88)
[   11.154518] [] (deferred_probe_work_func) from [] 
(process_one_work+0x294/0x4a0)
[   11.164083] [] (process_one_work) from [] 
(worker_thread+0x1ec/0x2fc)
[   11.172641] [] (worker_thread) from [] 
(kthread+0xd4/0xe8)
[   11.180200] [] (kthread) from [] 
(ret_from_fork+0x14/0x3c)

So it looks as if there are more get/put mismatches in the drivers which are 
usually not visible.

> 
> As far as why in 4.2, it seems you have OF_DYNAMIC enabled in your
> config either because you have DT unit test or overlays enabled.
> Overlays are now user enable-able in 4.2.

Further analysis turns out that we recently have enabled 
DRM_TILCDC_SLAVE_COMPAT=y
which we need to make our uImage additionally support the BeagleBone Black with 
LDC panel
(as mandated by  arch/arm/boot/dts/am335x-boneblack.dts using 
“ti,tilcdc,slave”).

This automatically enables OF_OVERLAY which enables OF_DYNAMIC.

Obviously this now has unexpected side-effects on other systems with universal 
kernels configured
to support both, beaglebone and non-beaglebone devices.

So what is wrong? The sequence 

Re: [PATCH v2] cpufreq: Avoid attempts to create duplicate symbolic links

[Viresh Kumar]

On 29-07-15, 03:38, Rafael J. Wysocki wrote:
> The rule is supposed to be "all of the present CPUs which do not own
> a policy should point to one, unless it doesn't exist".  The right
> approach is then to create links from them to a policy object as soon
> as we create one for them.  Waiting for something else to happen is just
> pointless and this approach covers both the offline and online CPUs, so
> I don't think that changing it would improve things really.

Ack.

-- 
viresh
--
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 0/3] x86: Intel Processor Trace Logger

[Alexander Shishkin]

Takao Indoh  writes:

> Hi all,
>
> This patch creates log buffer for Intel PT and enable logging at boot
> time. When kernel panic occurs, we can get this log buffer from
> crashdump file by kdump, and reconstruct the flow that led to the panic.

Good to see this work going forward!

> Takao Indoh (3):
>   x86: Add Intel PT common files
>   x86: Add Intel PT logger
>   x86: Stop Intel PT and save its registers when panic occurs
>
>  arch/x86/Kconfig  |   16 ++
>  arch/x86/include/asm/intel_pt.h   |   84 +
>  arch/x86/kernel/cpu/Makefile  |3 +
>  arch/x86/kernel/cpu/intel_pt.h|  131 -
>  arch/x86/kernel/cpu/intel_pt_cap.c|   69 +++
>  arch/x86/kernel/cpu/intel_pt_log.c|  288 
> +
>  arch/x86/kernel/cpu/intel_pt_perf.h   |   78 
>  arch/x86/kernel/cpu/perf_event_intel_pt.c |   54 +-
>  arch/x86/kernel/crash.c   |9 +
>  9 files changed, 556 insertions(+), 176 deletions(-)
>  create mode 100644 arch/x86/include/asm/intel_pt.h
>  delete mode 100644 arch/x86/kernel/cpu/intel_pt.h
>  create mode 100644 arch/x86/kernel/cpu/intel_pt_cap.c
>  create mode 100644 arch/x86/kernel/cpu/intel_pt_log.c
>  create mode 100644 arch/x86/kernel/cpu/intel_pt_perf.h

One note here: you want to use -M with git-format-patch so that renames
are handled better.

Regards,
--
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 v3 5/6] iommu/mediatek: Add mt8173 IOMMU driver

[Yong Wu]

On Mon, 2015-07-27 at 16:49 +0100, Robin Murphy wrote:
> On 27/07/15 16:31, Russell King - ARM Linux wrote:
> > On Mon, Jul 27, 2015 at 02:23:26PM +0100, Robin Murphy wrote:
> >> On 16/07/15 10:04, Yong Wu wrote:
> >>> This patch adds support for mediatek m4u (MultiMedia Memory Management
> >>> Unit).
> >>>
> >>> Signed-off-by: Yong Wu 
> >> [...]
> >>> +static void mtk_iommu_flush_pgtable(void *ptr, size_t size, void *cookie)
> >>> +{
> >>> +   struct mtk_iommu_domain *domain = cookie;
> >>> +   unsigned long offset = (unsigned long)ptr & ~PAGE_MASK;
> >>> +
> >>> +   dma_map_page(domain->data->dev, virt_to_page(ptr), offset,
> >>> +size, DMA_TO_DEVICE);
> >>
> >> Nit: this looks like it may as well be dma_map_single.
> >>
> >> It would probably be worth following it with a matching unmap too, just to
> >> avoid any possible leakage bugs (especially if this M4U ever appears in a
> >> SoC supporting RAM above the 32-bit boundary).
> >
> > Why not do the job properly?  Take a look at how I implemented the
> > streaming DMA API on Tegra SMMU (patch set recently sent out earlier
> > today).
> >
> > There's no need for hacks like dma_map_page() (and discarding it's
> > return value) or dma_map_page() followed by dma_unmap_page().
> 
> Indeed, as it happens I do have a branch where I prototyped that for the 
> long-descriptor io-pgtable-arm code a while ago; this discussion has 
> prompted me to dig it up again. Stay tuned, folks...

Hi Russell, Robin,

 From I see in arm-smmu-v3.c in v4.2-rc1, 
 
 The flush_pgtable seems like this:
//==
dma_addr_t dma_addr;

dma_addr = dma_map_page(dev, ptr, size, DMA_TO_DEVICE);

if (dma_mapping_error(dev, dma_addr))
dev_err(dev, "failed to flush pgtable at %p\n", ptr);
else
dma_unmap_page(dev, dma_addr, size, DMA_TO_DEVICE);
//==
   I will change map like this and use dma_map_single instead.

   Is this also seems to be not proper?

   Then how to do it?  add this before unmap? :
   dma_sync_single_for_device(dev, dma_addr, size, DMA_TO_DEVICE);

> 
> Robin.
> 


--
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] x86/vm86: Move vm86 fields out of thread_struct

[Brian Gerst]

Allocate a separate structure for the vm86 fields.

Signed-off-by: Brian Gerst 
---
 arch/x86/include/asm/processor.h | 11 +++---
 arch/x86/include/asm/vm86.h  | 19 -
 arch/x86/kernel/process.c|  3 +++
 arch/x86/kernel/vm86_32.c| 46 +++-
 arch/x86/mm/fault.c  |  4 ++--
 5 files changed, 53 insertions(+), 30 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 42c460c..19577dd 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -6,8 +6,8 @@
 /* Forward declaration, a strange C thing */
 struct task_struct;
 struct mm_struct;
+struct vm86;
 
-#include 
 #include 
 #include 
 #include 
@@ -400,13 +400,9 @@ struct thread_struct {
unsigned long   cr2;
unsigned long   trap_nr;
unsigned long   error_code;
-#ifdef CONFIG_X86_32
+#ifdef CONFIG_VM86
/* Virtual 86 mode info */
-   struct vm86plus_struct __user *vm86_info;
-   unsigned long   screen_bitmap;
-   unsigned long   v86flags;
-   unsigned long   v86mask;
-   unsigned long   saved_sp0;
+   struct vm86 *vm86;
 #endif
/* IO permissions: */
unsigned long   *io_bitmap_ptr;
@@ -710,7 +706,6 @@ static inline void spin_lock_prefetch(const void *x)
 
 #define INIT_THREAD  {   \
.sp0= TOP_OF_INIT_STACK,  \
-   .vm86_info  = NULL,   \
.sysenter_cs= __KERNEL_CS,\
.io_bitmap_ptr  = NULL,   \
 }
diff --git a/arch/x86/include/asm/vm86.h b/arch/x86/include/asm/vm86.h
index 1d8de3f..20b43b7 100644
--- a/arch/x86/include/asm/vm86.h
+++ b/arch/x86/include/asm/vm86.h
@@ -1,7 +1,6 @@
 #ifndef _ASM_X86_VM86_H
 #define _ASM_X86_VM86_H
 
-
 #include 
 #include 
 
@@ -58,6 +57,14 @@ struct kernel_vm86_struct {
  */
 };
 
+struct vm86 {
+   struct vm86plus_struct __user *vm86_info;
+   unsigned long screen_bitmap;
+   unsigned long v86flags;
+   unsigned long v86mask;
+   unsigned long saved_sp0;
+};
+
 #ifdef CONFIG_VM86
 
 void handle_vm86_fault(struct kernel_vm86_regs *, long);
@@ -67,6 +74,14 @@ struct pt_regs *save_v86_state(struct kernel_vm86_regs *);
 struct task_struct;
 void release_vm86_irqs(struct task_struct *);
 
+#define free_vm86(t) do {  \
+   struct thread_struct *__t = (t);\
+   if (__t->vm86 != NULL) {\
+   kfree(__t->vm86);   \
+   __t->vm86 = NULL;   \
+   }   \
+} while (0)
+
 #else
 
 #define handle_vm86_fault(a, b)
@@ -77,6 +92,8 @@ static inline int handle_vm86_trap(struct kernel_vm86_regs 
*a, long b, int c)
return 0;
 }
 
+#define free_vm86(t) do { } while(0)
+
 #endif /* CONFIG_VM86 */
 
 #endif /* _ASM_X86_VM86_H */
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 397688b..2199d9b 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * per-CPU TSS segments. Threads are completely 'soft' on Linux,
@@ -110,6 +111,8 @@ void exit_thread(void)
kfree(bp);
}
 
+   free_vm86(t);
+
fpu__drop(fpu);
 }
 
diff --git a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c
index e6c2b47..bfa59b1 100644
--- a/arch/x86/kernel/vm86_32.c
+++ b/arch/x86/kernel/vm86_32.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -81,8 +82,8 @@
 /*
  * virtual flags (16 and 32-bit versions)
  */
-#define VFLAGS (*(unsigned short *)&(current->thread.v86flags))
-#define VEFLAGS(current->thread.v86flags)
+#define VFLAGS (*(unsigned short *)&(current->thread.vm86->v86flags))
+#define VEFLAGS(current->thread.vm86->v86flags)
 
 #define set_flags(X, new, mask) \
 ((X) = ((X) & ~(mask)) | ((new) & (mask)))
@@ -96,6 +97,7 @@ struct pt_regs *save_v86_state(struct kernel_vm86_regs *regs)
struct pt_regs *ret;
struct task_struct *tsk = current;
struct vm86plus_struct __user *user;
+   struct vm86 *vm86 = current->thread.vm86;
long err = 0;
 
/*
@@ -105,12 +107,12 @@ struct pt_regs *save_v86_state(struct kernel_vm86_regs 
*regs)
 */
local_irq_enable();
 
-   if (!tsk->thread.vm86_info) {
+   if (!vm86 || !vm86->vm86_info) {
pr_alert("no vm86_info: BAD\n");
do_exit(SIGSEGV);
}
-   set_flags(regs->pt.flags, VEFLAGS, X86_EFLAGS_VIF | 
tsk->thread.v86mask);
-   user = tsk->thread.vm86_info;
+   set_flags(regs->pt.flags, VEFL

[PATCH 3/8] x86/vm86: Eliminate kernel_vm86_struct

[Brian Gerst]

Now there is no vm86-specific data left on the kernel stack while in
userspace, except for the 32-bit regs.

Signed-off-by: Brian Gerst 
---
 arch/x86/include/asm/vm86.h | 25 +---
 arch/x86/kernel/vm86_32.c   | 95 +++--
 2 files changed, 42 insertions(+), 78 deletions(-)

diff --git a/arch/x86/include/asm/vm86.h b/arch/x86/include/asm/vm86.h
index 47c7648..226d6c1 100644
--- a/arch/x86/include/asm/vm86.h
+++ b/arch/x86/include/asm/vm86.h
@@ -27,32 +27,9 @@ struct kernel_vm86_regs {
unsigned short gs, __gsh;
 };
 
-struct kernel_vm86_struct {
-   struct kernel_vm86_regs regs;
-/*
- * the below part remains on the kernel stack while we are in VM86 mode.
- * 'tss.esp0' then contains the address of VM86_TSS_ESP0 below, and when we
- * get forced back from VM86, the CPU and "SAVE_ALL" will restore the above
- * 'struct kernel_vm86_regs' with the then actual values.
- * Therefore, pt_regs in fact points to a complete 'kernel_vm86_struct'
- * in kernelspace, hence we need not reget the data from userspace.
- */
-#define VM86_TSS_ESP0 regs32
-   struct pt_regs *regs32;   /* here we save the pointer to the old regs */
-/*
- * The below is not part of the structure, but the stack layout continues
- * this way. In front of 'return-eip' may be some data, depending on
- * compilation, so we don't rely on this and save the pointer to 'oldregs'
- * in 'regs32' above.
- * However, with GCC-2.7.2 and the current CFLAGS you see exactly this:
-
-   long return-eip;from call to vm86()
-   struct pt_regs oldregs;  user space registers as saved by syscall
- */
-};
-
 struct vm86 {
struct vm86plus_struct __user *vm86_info;
+   struct pt_regs *regs32;
unsigned long v86flags;
unsigned long v86mask;
unsigned long saved_sp0;
diff --git a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c
index f71b4b9..696ef76 100644
--- a/arch/x86/kernel/vm86_32.c
+++ b/arch/x86/kernel/vm86_32.c
@@ -67,9 +67,6 @@
  */
 
 
-#define KVM86  ((struct kernel_vm86_struct *)regs)
-
-
 /*
  * 8- and 16-bit register defines..
  */
@@ -152,7 +149,7 @@ struct pt_regs *save_v86_state(struct kernel_vm86_regs 
*regs)
vm86->saved_sp0 = 0;
put_cpu();
 
-   ret = KVM86->regs32;
+   ret = vm86->regs32;
 
lazy_load_gs(ret->gs);
 
@@ -194,29 +191,16 @@ out:
 
 
 static int do_vm86_irq_handling(int subfunction, int irqnumber);
-static long do_sys_vm86(struct vm86plus_struct __user *v86, bool plus,
-   struct kernel_vm86_struct *info);
+static long do_sys_vm86(struct vm86plus_struct __user *v86, bool plus);
 
 SYSCALL_DEFINE1(vm86old, struct vm86_struct __user *, v86)
 {
-   struct kernel_vm86_struct info; /* declare this _on top_,
-* this avoids wasting of stack space.
-* This remains on the stack until we
-* return to 32 bit user space.
-*/
-
-   return do_sys_vm86((struct vm86plus_struct __user *) v86, false, &info);
+   return do_sys_vm86((struct vm86plus_struct __user *) v86, false);
 }
 
 
 SYSCALL_DEFINE2(vm86, unsigned long, cmd, unsigned long, arg)
 {
-   struct kernel_vm86_struct info; /* declare this _on top_,
-* this avoids wasting of stack space.
-* This remains on the stack until we
-* return to 32 bit user space.
-*/
-
switch (cmd) {
case VM86_REQUEST_IRQ:
case VM86_FREE_IRQ:
@@ -234,16 +218,17 @@ SYSCALL_DEFINE2(vm86, unsigned long, cmd, unsigned long, 
arg)
}
 
/* we come here only for functions VM86_ENTER, VM86_ENTER_NO_BYPASS */
-   return do_sys_vm86((struct vm86plus_struct __user *) arg, true, &info);
+   return do_sys_vm86((struct vm86plus_struct __user *) arg, true);
 }
 
 
-static long do_sys_vm86(struct vm86plus_struct __user *v86, bool plus,
-   struct kernel_vm86_struct *info)
+static long do_sys_vm86(struct vm86plus_struct __user *v86, bool plus)
 {
struct tss_struct *tss;
struct task_struct *tsk = current;
struct vm86 *vm86 = tsk->thread.vm86;
+   struct kernel_vm86_regs vm86regs;
+   struct pt_regs *regs32 = current_pt_regs();
unsigned long err = 0;
 
if (!vm86) {
@@ -259,27 +244,27 @@ static long do_sys_vm86(struct vm86plus_struct __user 
*v86, bool plus,
   sizeof(struct vm86plus_struct)))
return -EFAULT;
 
-   memset(info, 0, sizeof(*info));
+   memset(&vm86regs, 0, sizeof(vm86regs));
get_user_try {
unsigned short seg;
-   get_user_ex(info->regs.pt.bx, &v86->regs.ebx);
-   get_user_ex(info->regs.pt.cx, &v86->regs.ecx);
-   g

[PATCH 5/8] x86/vm86: Add a separate config option for hardware IRQ handling

[Brian Gerst]

Allow disabling hardware interrupt support for vm86.

Signed-off-by: Brian Gerst 
---
 arch/x86/Kconfig   |  8 
 arch/x86/include/asm/irq_vectors.h | 10 --
 arch/x86/include/asm/vm86.h| 20 ++--
 arch/x86/kernel/vm86_32.c  | 12 ++--
 4 files changed, 36 insertions(+), 14 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index cbd2d62..7c7ec31 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1067,6 +1067,14 @@ config VM86
bool
default X86_LEGACY_VM86
 
+config VM86_INTERRUPTS
+   bool "Enable VM86 interrupt support"
+   default y
+   depends on VM86
+   ---help---
+ This option allows VM86 programs to request interrupts for
+ real mode hardware drivers.
+
 config X86_16BIT
bool "Enable support for 16-bit segments" if EXPERT
default y
diff --git a/arch/x86/include/asm/irq_vectors.h 
b/arch/x86/include/asm/irq_vectors.h
index 4c2d2eb..6ca9fd6 100644
--- a/arch/x86/include/asm/irq_vectors.h
+++ b/arch/x86/include/asm/irq_vectors.h
@@ -117,16 +117,6 @@
 
 #define FPU_IRQ  13
 
-#defineFIRST_VM86_IRQ 3
-#define LAST_VM86_IRQ15
-
-#ifndef __ASSEMBLY__
-static inline int invalid_vm86_irq(int irq)
-{
-   return irq < FIRST_VM86_IRQ || irq > LAST_VM86_IRQ;
-}
-#endif
-
 /*
  * Size the maximum number of interrupts.
  *
diff --git a/arch/x86/include/asm/vm86.h b/arch/x86/include/asm/vm86.h
index dd45aa1..05f6394 100644
--- a/arch/x86/include/asm/vm86.h
+++ b/arch/x86/include/asm/vm86.h
@@ -49,7 +49,6 @@ int handle_vm86_trap(struct kernel_vm86_regs *, long, int);
 void save_v86_state(struct kernel_vm86_regs *, int);
 
 struct task_struct;
-void release_vm86_irqs(struct task_struct *);
 
 #define free_vm86(t) do {  \
struct thread_struct *__t = (t);\
@@ -62,7 +61,6 @@ void release_vm86_irqs(struct task_struct *);
 #else
 
 #define handle_vm86_fault(a, b)
-#define release_vm86_irqs(a)
 
 static inline int handle_vm86_trap(struct kernel_vm86_regs *a, long b, int c)
 {
@@ -75,4 +73,22 @@ static inline void save_v86_state(struct kernel_vm86_regs *, 
int) { }
 
 #endif /* CONFIG_VM86 */
 
+#ifdef CONFIG_VM86_INTERRUPTS
+
+#define FIRST_VM86_IRQ  3
+#define LAST_VM86_IRQ  15
+
+static inline int invalid_vm86_irq(int irq)
+{
+   return irq < FIRST_VM86_IRQ || irq > LAST_VM86_IRQ;
+}
+
+void release_vm86_irqs(struct task_struct *);
+
+#else /* CONFIG_VM86_INTERRUPTS */
+
+static inline void release_vm86_irqs(struct task_struct *tsk) { }
+
+#endif /* CONFIG_VM86_INTERRUPTS */
+
 #endif /* _ASM_X86_VM86_H */
diff --git a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c
index ffe98ec..9cdd33c 100644
--- a/arch/x86/kernel/vm86_32.c
+++ b/arch/x86/kernel/vm86_32.c
@@ -189,8 +189,15 @@ out:
 }
 
 
-
+#ifdef CONFIG_VM86_INTERRUPTS
 static int do_vm86_irq_handling(int subfunction, int irqnumber);
+#else
+static inline int do_vm86_irq_handling(int subfunction, int irqnumber)
+{
+   return -EINVAL;
+}
+#endif
+
 static long do_sys_vm86(struct vm86plus_struct __user *v86, bool plus);
 
 SYSCALL_DEFINE1(vm86old, struct vm86_struct __user *, v86)
@@ -713,6 +720,7 @@ simulate_sigsegv:
save_v86_state(regs, VM86_UNKNOWN);
 }
 
+#ifdef CONFIG_VM86_INTERRUPTS
 /*  vm86 special IRQ passing stuff - */
 
 #define VM86_IRQNAME   "vm86irq"
@@ -828,4 +836,4 @@ static int do_vm86_irq_handling(int subfunction, int 
irqnumber)
}
return -EINVAL;
 }
-
+#endif
-- 
2.4.3

--
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 7/8] x86/vm86: Rename vm86->vm86_info to user_vm86

[Brian Gerst]

Make it clearer that this is the pointer to the userspace vm86 state area.

Signed-off-by: Brian Gerst 
---
 arch/x86/include/asm/vm86.h |  2 +-
 arch/x86/kernel/vm86_32.c   | 70 +++--
 2 files changed, 37 insertions(+), 35 deletions(-)

diff --git a/arch/x86/include/asm/vm86.h b/arch/x86/include/asm/vm86.h
index 05f6394..5c027c5 100644
--- a/arch/x86/include/asm/vm86.h
+++ b/arch/x86/include/asm/vm86.h
@@ -28,7 +28,7 @@ struct kernel_vm86_regs {
 };
 
 struct vm86 {
-   struct vm86plus_struct __user *vm86_info;
+   struct vm86plus_struct __user *user_vm86;
struct pt_regs regs32;
unsigned long v86flags;
unsigned long v86mask;
diff --git a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c
index 6fce378..aca499d 100644
--- a/arch/x86/kernel/vm86_32.c
+++ b/arch/x86/kernel/vm86_32.c
@@ -104,17 +104,17 @@ void save_v86_state(struct kernel_vm86_regs *regs, int 
retval)
 */
local_irq_enable();
 
-   if (!vm86 || !vm86->vm86_info) {
-   pr_alert("no vm86_info: BAD\n");
+   if (!vm86 || !vm86->user_vm86) {
+   pr_alert("no user_vm86: BAD\n");
do_exit(SIGSEGV);
}
set_flags(regs->pt.flags, VEFLAGS, X86_EFLAGS_VIF | vm86->v86mask);
-   user = vm86->vm86_info;
+   user = vm86->user_vm86;
 
if (!access_ok(VERIFY_WRITE, user, vm86->vm86plus.is_vm86pus ?
   sizeof(struct vm86plus_struct) :
   sizeof(struct vm86_struct))) {
-   pr_alert("could not access userspace vm86_info\n");
+   pr_alert("could not access userspace vm86 info\n");
do_exit(SIGSEGV);
}
 
@@ -139,7 +139,7 @@ void save_v86_state(struct kernel_vm86_regs *regs, int 
retval)
put_user_ex(vm86->screen_bitmap, &user->screen_bitmap);
} put_user_catch(err);
if (err) {
-   pr_alert("could not access userspace vm86_info\n");
+   pr_alert("could not access userspace vm86 info\n");
do_exit(SIGSEGV);
}
 
@@ -199,11 +199,11 @@ static inline int do_vm86_irq_handling(int subfunction, 
int irqnumber)
 }
 #endif
 
-static long do_sys_vm86(struct vm86plus_struct __user *v86, bool plus);
+static long do_sys_vm86(struct vm86plus_struct __user *user_vm86, bool plus);
 
-SYSCALL_DEFINE1(vm86old, struct vm86_struct __user *, v86)
+SYSCALL_DEFINE1(vm86old, struct vm86_struct __user *, user_vm86)
 {
-   return do_sys_vm86((struct vm86plus_struct __user *) v86, false);
+   return do_sys_vm86((struct vm86plus_struct __user *) user_vm86, false);
 }
 
 
@@ -230,7 +230,7 @@ SYSCALL_DEFINE2(vm86, unsigned long, cmd, unsigned long, 
arg)
 }
 
 
-static long do_sys_vm86(struct vm86plus_struct __user *v86, bool plus)
+static long do_sys_vm86(struct vm86plus_struct __user *user_vm86, bool plus)
 {
struct tss_struct *tss;
struct task_struct *tsk = current;
@@ -247,7 +247,7 @@ static long do_sys_vm86(struct vm86plus_struct __user *v86, 
bool plus)
if (vm86->saved_sp0)
return -EPERM;
 
-   if (!access_ok(VERIFY_READ, v86, plus ?
+   if (!access_ok(VERIFY_READ, user_vm86, plus ?
   sizeof(struct vm86_struct) :
   sizeof(struct vm86plus_struct)))
return -EFAULT;
@@ -255,40 +255,42 @@ static long do_sys_vm86(struct vm86plus_struct __user 
*v86, bool plus)
memset(&vm86regs, 0, sizeof(vm86regs));
get_user_try {
unsigned short seg;
-   get_user_ex(vm86regs.pt.bx, &v86->regs.ebx);
-   get_user_ex(vm86regs.pt.cx, &v86->regs.ecx);
-   get_user_ex(vm86regs.pt.dx, &v86->regs.edx);
-   get_user_ex(vm86regs.pt.si, &v86->regs.esi);
-   get_user_ex(vm86regs.pt.di, &v86->regs.edi);
-   get_user_ex(vm86regs.pt.bp, &v86->regs.ebp);
-   get_user_ex(vm86regs.pt.ax, &v86->regs.eax);
-   get_user_ex(vm86regs.pt.ip, &v86->regs.eip);
-   get_user_ex(seg, &v86->regs.cs);
+   get_user_ex(vm86regs.pt.bx, &user_vm86->regs.ebx);
+   get_user_ex(vm86regs.pt.cx, &user_vm86->regs.ecx);
+   get_user_ex(vm86regs.pt.dx, &user_vm86->regs.edx);
+   get_user_ex(vm86regs.pt.si, &user_vm86->regs.esi);
+   get_user_ex(vm86regs.pt.di, &user_vm86->regs.edi);
+   get_user_ex(vm86regs.pt.bp, &user_vm86->regs.ebp);
+   get_user_ex(vm86regs.pt.ax, &user_vm86->regs.eax);
+   get_user_ex(vm86regs.pt.ip, &user_vm86->regs.eip);
+   get_user_ex(seg, &user_vm86->regs.cs);
vm86regs.pt.cs = seg;
-   get_user_ex(vm86regs.pt.flags, &v86->regs.eflags);
-   get_user_ex(vm86regs.pt.sp, &v86->regs.esp);
-   get_user_ex(seg, &v86->regs.ss);
+   get_user_ex(vm86regs.pt.flags, &user_vm86->regs.eflags);
+

[PATCH 4/8] x86/vm86: Use the normal pt_regs area for vm86

[Brian Gerst]

Change to use the normal pt_regs area to enter and exit vm86 mode.  This is
done by increasing the padding at the top of the stack to make room for the
extra vm86 segment slots in the IRET frame.  It then saves the 32-bit regs
in the off-stack vm86 data, and copies in the vm86 regs.  Exiting back to
32-bit mode does the reverse.  This allows removing the hacks to jump directly
into the exit asm code due to having to change the stack pointer.  Returning
normally from the vm86 syscall and the exception handlers allows things like
ptrace and auditing to work properly.

Signed-off-by: Brian Gerst 
---
 arch/x86/entry/entry_32.S  |  24 +---
 arch/x86/include/asm/thread_info.h |  11 ++--
 arch/x86/include/asm/vm86.h|   6 +-
 arch/x86/kernel/signal.c   |   3 +
 arch/x86/kernel/vm86_32.c  | 110 +++--
 5 files changed, 60 insertions(+), 94 deletions(-)

diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index 21dc60a..f940e24 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -525,34 +525,12 @@ work_resched:
 
 work_notifysig:# deal with pending 
signals and
# notify-resume requests
-#ifdef CONFIG_VM86
-   testl   $X86_EFLAGS_VM, PT_EFLAGS(%esp)
-   movl%esp, %eax
-   jnz work_notifysig_v86  # returning to kernel-space or
-   # vm86-space
-1:
-#else
-   movl%esp, %eax
-#endif
TRACE_IRQS_ON
ENABLE_INTERRUPTS(CLBR_NONE)
-   movbPT_CS(%esp), %bl
-   andb$SEGMENT_RPL_MASK, %bl
-   cmpb$USER_RPL, %bl
-   jb  resume_kernel
+   movl%esp, %eax
xorl%edx, %edx
calldo_notify_resume
jmp resume_userspace
-
-#ifdef CONFIG_VM86
-   ALIGN
-work_notifysig_v86:
-   pushl   %ecx# save ti_flags for 
do_notify_resume
-   callsave_v86_state  # %eax contains pt_regs pointer
-   popl%ecx
-   movl%eax, %esp
-   jmp 1b
-#endif
 END(work_pending)
 
# perform syscall exit tracing
diff --git a/arch/x86/include/asm/thread_info.h 
b/arch/x86/include/asm/thread_info.h
index 225ee54..fdad5c2 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -27,14 +27,17 @@
  * Without this offset, that can result in a page fault.  (We are
  * careful that, in this case, the value we read doesn't matter.)
  *
- * In vm86 mode, the hardware frame is much longer still, but we neither
- * access the extra members from NMI context, nor do we write such a
- * frame at sp0 at all.
+ * In vm86 mode, the hardware frame is much longer still, so add 16
+ * bytes to make room for the real-mode segments.
  *
  * x86_64 has a fixed-length stack frame.
  */
 #ifdef CONFIG_X86_32
-# define TOP_OF_KERNEL_STACK_PADDING 8
+# ifdef CONFIG_VM86
+#  define TOP_OF_KERNEL_STACK_PADDING 16
+# else
+#  define TOP_OF_KERNEL_STACK_PADDING 8
+# endif
 #else
 # define TOP_OF_KERNEL_STACK_PADDING 0
 #endif
diff --git a/arch/x86/include/asm/vm86.h b/arch/x86/include/asm/vm86.h
index 226d6c1..dd45aa1 100644
--- a/arch/x86/include/asm/vm86.h
+++ b/arch/x86/include/asm/vm86.h
@@ -29,7 +29,7 @@ struct kernel_vm86_regs {
 
 struct vm86 {
struct vm86plus_struct __user *vm86_info;
-   struct pt_regs *regs32;
+   struct pt_regs regs32;
unsigned long v86flags;
unsigned long v86mask;
unsigned long saved_sp0;
@@ -46,7 +46,7 @@ struct vm86 {
 
 void handle_vm86_fault(struct kernel_vm86_regs *, long);
 int handle_vm86_trap(struct kernel_vm86_regs *, long, int);
-struct pt_regs *save_v86_state(struct kernel_vm86_regs *);
+void save_v86_state(struct kernel_vm86_regs *, int);
 
 struct task_struct;
 void release_vm86_irqs(struct task_struct *);
@@ -69,6 +69,8 @@ static inline int handle_vm86_trap(struct kernel_vm86_regs 
*a, long b, int c)
return 0;
 }
 
+static inline void save_v86_state(struct kernel_vm86_regs *, int) { }
+
 #define free_vm86(t) do { } while(0)
 
 #endif /* CONFIG_VM86 */
diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index 7e88cc7..bfd736e 100644
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -635,6 +635,9 @@ handle_signal(struct ksignal *ksig, struct pt_regs *regs)
bool stepping, failed;
struct fpu *fpu = ¤t->thread.fpu;
 
+   if (v8086_mode(regs))
+   save_v86_state((struct kernel_vm86_regs *) regs, VM86_SIGNAL);
+
/* Are we from a system call? */
if (syscall_get_nr(current, regs) >= 0) {
/* If so, check system call restarting.. */
diff --git a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c
index 696ef76..ffe98ec 100644
--- a/arch/x86/kernel/vm86_32.c
+++ b/arch/x86/kernel/vm86_32.c
@@ -50,6 +50,7 @@
 #include 
 #include 
 #include 
+#includ

[PATCH 2/8] x86/vm86: Move fields from kernel_vm86_struct

[Brian Gerst]

Move the non-regs fields to the off-stack data.

Signed-off-by: Brian Gerst 
---
 arch/x86/include/asm/vm86.h | 16 
 arch/x86/kernel/vm86_32.c   | 42 ++
 2 files changed, 30 insertions(+), 28 deletions(-)

diff --git a/arch/x86/include/asm/vm86.h b/arch/x86/include/asm/vm86.h
index 20b43b7..47c7648 100644
--- a/arch/x86/include/asm/vm86.h
+++ b/arch/x86/include/asm/vm86.h
@@ -37,13 +37,7 @@ struct kernel_vm86_struct {
  * Therefore, pt_regs in fact points to a complete 'kernel_vm86_struct'
  * in kernelspace, hence we need not reget the data from userspace.
  */
-#define VM86_TSS_ESP0 flags
-   unsigned long flags;
-   unsigned long screen_bitmap;
-   unsigned long cpu_type;
-   struct revectored_struct int_revectored;
-   struct revectored_struct int21_revectored;
-   struct vm86plus_info_struct vm86plus;
+#define VM86_TSS_ESP0 regs32
struct pt_regs *regs32;   /* here we save the pointer to the old regs */
 /*
  * The below is not part of the structure, but the stack layout continues
@@ -59,10 +53,16 @@ struct kernel_vm86_struct {
 
 struct vm86 {
struct vm86plus_struct __user *vm86_info;
-   unsigned long screen_bitmap;
unsigned long v86flags;
unsigned long v86mask;
unsigned long saved_sp0;
+
+   unsigned long flags;
+   unsigned long screen_bitmap;
+   unsigned long cpu_type;
+   struct revectored_struct int_revectored;
+   struct revectored_struct int21_revectored;
+   struct vm86plus_info_struct vm86plus;
 };
 
 #ifdef CONFIG_VM86
diff --git a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c
index bfa59b1..f71b4b9 100644
--- a/arch/x86/kernel/vm86_32.c
+++ b/arch/x86/kernel/vm86_32.c
@@ -68,7 +68,6 @@
 
 
 #define KVM86  ((struct kernel_vm86_struct *)regs)
-#define VMPI   KVM86->vm86plus
 
 
 /*
@@ -114,7 +113,7 @@ struct pt_regs *save_v86_state(struct kernel_vm86_regs 
*regs)
set_flags(regs->pt.flags, VEFLAGS, X86_EFLAGS_VIF | vm86->v86mask);
user = vm86->vm86_info;
 
-   if (!access_ok(VERIFY_WRITE, user, VMPI.is_vm86pus ?
+   if (!access_ok(VERIFY_WRITE, user, vm86->vm86plus.is_vm86pus ?
   sizeof(struct vm86plus_struct) :
   sizeof(struct vm86_struct))) {
pr_alert("could not access userspace vm86_info\n");
@@ -282,25 +281,27 @@ static long do_sys_vm86(struct vm86plus_struct __user 
*v86, bool plus,
get_user_ex(info->regs.fs, &v86->regs.fs);
get_user_ex(info->regs.gs, &v86->regs.gs);
 
-   get_user_ex(info->flags, &v86->flags);
-   get_user_ex(info->screen_bitmap, &v86->screen_bitmap);
-   get_user_ex(info->cpu_type, &v86->cpu_type);
+   get_user_ex(vm86->flags, &v86->flags);
+   get_user_ex(vm86->screen_bitmap, &v86->screen_bitmap);
+   get_user_ex(vm86->cpu_type, &v86->cpu_type);
} get_user_catch(err);
if (err)
return err;
 
-   if (copy_from_user(&info->int_revectored, &v86->int_revectored,
+   if (copy_from_user(&vm86->int_revectored, &v86->int_revectored,
   sizeof(struct revectored_struct)))
return -EFAULT;
-   if (copy_from_user(&info->int21_revectored, &v86->int21_revectored,
+   if (copy_from_user(&vm86->int21_revectored, &v86->int21_revectored,
   sizeof(struct revectored_struct)))
return -EFAULT;
if (plus) {
-   if (copy_from_user(&info->vm86plus, &v86->vm86plus,
+   if (copy_from_user(&vm86->vm86plus, &v86->vm86plus,
   sizeof(struct vm86plus_info_struct)))
return -EFAULT;
-   info->vm86plus.is_vm86pus = 1;
-   }
+   vm86->vm86plus.is_vm86pus = 1;
+   } else
+   memset(&vm86->vm86plus, 0,
+  sizeof(struct vm86plus_info_struct));
 
info->regs32 = current_pt_regs();
vm86->vm86_info = v86;
@@ -317,7 +318,7 @@ static long do_sys_vm86(struct vm86plus_struct __user *v86, 
bool plus,
 
info->regs.pt.orig_ax = info->regs32->orig_ax;
 
-   switch (info->cpu_type) {
+   switch (vm86->cpu_type) {
case CPU_286:
vm86->v86mask = 0;
break;
@@ -346,8 +347,7 @@ static long do_sys_vm86(struct vm86plus_struct __user *v86, 
bool plus,
load_sp0(tss, &tsk->thread);
put_cpu();
 
-   vm86->screen_bitmap = info->screen_bitmap;
-   if (info->flags & VM86_SCREEN_BITMAP)
+   if (vm86->flags & VM86_SCREEN_BITMAP)
mark_screen_rdonly(tsk->mm);
 
/*call __audit_syscall_exit since we do not exit via the normal paths */
@@ -539,12 +539,13 @@ static void do_int(struct kernel_vm86_regs *regs, int i,
 {
unsigned long __user *intr_ptr;
unsigned long segoffs;
+   struct kernel_v

[PATCH 8/8] x86/vm86: Rename vm86->v86flags and v86mask

[Brian Gerst]

Rename v86flags to veflags, and v86mask to veflags_mask.

Signed-off-by: Brian Gerst 
---
 arch/x86/include/asm/vm86.h |  4 ++--
 arch/x86/kernel/vm86_32.c   | 20 ++--
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/x86/include/asm/vm86.h b/arch/x86/include/asm/vm86.h
index 5c027c5..13f91a6 100644
--- a/arch/x86/include/asm/vm86.h
+++ b/arch/x86/include/asm/vm86.h
@@ -30,8 +30,8 @@ struct kernel_vm86_regs {
 struct vm86 {
struct vm86plus_struct __user *user_vm86;
struct pt_regs regs32;
-   unsigned long v86flags;
-   unsigned long v86mask;
+   unsigned long veflags;
+   unsigned long veflags_mask;
unsigned long saved_sp0;
 
unsigned long flags;
diff --git a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c
index aca499d..8b8f9de 100644
--- a/arch/x86/kernel/vm86_32.c
+++ b/arch/x86/kernel/vm86_32.c
@@ -80,8 +80,8 @@
 /*
  * virtual flags (16 and 32-bit versions)
  */
-#define VFLAGS (*(unsigned short *)&(current->thread.vm86->v86flags))
-#define VEFLAGS(current->thread.vm86->v86flags)
+#define VFLAGS (*(unsigned short *)&(current->thread.vm86->veflags))
+#define VEFLAGS(current->thread.vm86->veflags)
 
 #define set_flags(X, new, mask) \
 ((X) = ((X) & ~(mask)) | ((new) & (mask)))
@@ -108,7 +108,7 @@ void save_v86_state(struct kernel_vm86_regs *regs, int 
retval)
pr_alert("no user_vm86: BAD\n");
do_exit(SIGSEGV);
}
-   set_flags(regs->pt.flags, VEFLAGS, X86_EFLAGS_VIF | vm86->v86mask);
+   set_flags(regs->pt.flags, VEFLAGS, X86_EFLAGS_VIF | vm86->veflags_mask);
user = vm86->user_vm86;
 
if (!access_ok(VERIFY_WRITE, user, vm86->vm86plus.is_vm86pus ?
@@ -315,16 +315,16 @@ static long do_sys_vm86(struct vm86plus_struct __user 
*user_vm86, bool plus)
 
switch (vm86->cpu_type) {
case CPU_286:
-   vm86->v86mask = 0;
+   vm86->veflags_mask = 0;
break;
case CPU_386:
-   vm86->v86mask = X86_EFLAGS_NT | X86_EFLAGS_IOPL;
+   vm86->veflags_mask = X86_EFLAGS_NT | X86_EFLAGS_IOPL;
break;
case CPU_486:
-   vm86->v86mask = X86_EFLAGS_AC | X86_EFLAGS_NT | X86_EFLAGS_IOPL;
+   vm86->veflags_mask = X86_EFLAGS_AC | X86_EFLAGS_NT | 
X86_EFLAGS_IOPL;
break;
default:
-   vm86->v86mask = X86_EFLAGS_ID | X86_EFLAGS_AC | X86_EFLAGS_NT | 
X86_EFLAGS_IOPL;
+   vm86->veflags_mask = X86_EFLAGS_ID | X86_EFLAGS_AC | 
X86_EFLAGS_NT | X86_EFLAGS_IOPL;
break;
}
 
@@ -384,7 +384,7 @@ static inline void clear_AC(struct kernel_vm86_regs *regs)
 
 static inline void set_vflags_long(unsigned long flags, struct 
kernel_vm86_regs *regs)
 {
-   set_flags(VEFLAGS, flags, current->thread.vm86->v86mask);
+   set_flags(VEFLAGS, flags, current->thread.vm86->veflags_mask);
set_flags(regs->pt.flags, flags, SAFE_MASK);
if (flags & X86_EFLAGS_IF)
set_IF(regs);
@@ -394,7 +394,7 @@ static inline void set_vflags_long(unsigned long flags, 
struct kernel_vm86_regs
 
 static inline void set_vflags_short(unsigned short flags, struct 
kernel_vm86_regs *regs)
 {
-   set_flags(VFLAGS, flags, current->thread.vm86->v86mask);
+   set_flags(VFLAGS, flags, current->thread.vm86->veflags_mask);
set_flags(regs->pt.flags, flags, SAFE_MASK);
if (flags & X86_EFLAGS_IF)
set_IF(regs);
@@ -409,7 +409,7 @@ static inline unsigned long get_vflags(struct 
kernel_vm86_regs *regs)
if (VEFLAGS & X86_EFLAGS_VIF)
flags |= X86_EFLAGS_IF;
flags |= X86_EFLAGS_IOPL;
-   return flags | (VEFLAGS & current->thread.vm86->v86mask);
+   return flags | (VEFLAGS & current->thread.vm86->veflags_mask);
 }
 
 static inline int is_revectored(int nr, struct revectored_struct *bitmap)
-- 
2.4.3

--
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 6/8] x86/vm86: Clean up vm86.h includes

[Brian Gerst]

vm86.h was being implicitly included in alot of places via processor.h, which
in turn got it from math_emu.h.  Break that chain and explicitly include vm86.h
in all files that need it.  Also remove unused vm86 field from math_emu_info.

Signed-off-by: Brian Gerst 
---
 arch/x86/include/asm/math_emu.h | 6 +-
 arch/x86/include/asm/syscalls.h | 1 +
 arch/x86/kernel/process_32.c| 1 +
 arch/x86/kernel/signal.c| 1 +
 arch/x86/kernel/traps.c | 1 +
 arch/x86/kernel/vm86_32.c   | 1 +
 arch/x86/math-emu/get_address.c | 1 +
 arch/x86/mm/fault.c | 1 +
 8 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/math_emu.h b/arch/x86/include/asm/math_emu.h
index 031f626..0d9b14f 100644
--- a/arch/x86/include/asm/math_emu.h
+++ b/arch/x86/include/asm/math_emu.h
@@ -2,7 +2,6 @@
 #define _ASM_X86_MATH_EMU_H
 
 #include 
-#include 
 
 /* This structure matches the layout of the data saved to the stack
following a device-not-present interrupt, part of it saved
@@ -10,9 +9,6 @@
*/
 struct math_emu_info {
long ___orig_eip;
-   union {
-   struct pt_regs *regs;
-   struct kernel_vm86_regs *vm86;
-   };
+   struct pt_regs *regs;
 };
 #endif /* _ASM_X86_MATH_EMU_H */
diff --git a/arch/x86/include/asm/syscalls.h b/arch/x86/include/asm/syscalls.h
index 592a6a6..91dfcaf 100644
--- a/arch/x86/include/asm/syscalls.h
+++ b/arch/x86/include/asm/syscalls.h
@@ -37,6 +37,7 @@ asmlinkage long sys_get_thread_area(struct user_desc __user 
*);
 asmlinkage unsigned long sys_sigreturn(void);
 
 /* kernel/vm86_32.c */
+struct vm86_struct;
 asmlinkage long sys_vm86old(struct vm86_struct __user *);
 asmlinkage long sys_vm86(unsigned long, unsigned long);
 
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index f73c962..c13df2c 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -53,6 +53,7 @@
 #include 
 #include 
 #include 
+#include 
 
 asmlinkage void ret_from_fork(void) __asm__("ret_from_fork");
 asmlinkage void ret_from_kernel_thread(void) __asm__("ret_from_kernel_thread");
diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index bfd736e..07eb844 100644
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_X86_64
 #include 
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 8e65d8a..86a82ea 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -62,6 +62,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_X86_64
 #include 
diff --git a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c
index 9cdd33c..6fce378 100644
--- a/arch/x86/kernel/vm86_32.c
+++ b/arch/x86/kernel/vm86_32.c
@@ -51,6 +51,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Known problems:
diff --git a/arch/x86/math-emu/get_address.c b/arch/x86/math-emu/get_address.c
index 6ef5e99..a2eefb1 100644
--- a/arch/x86/math-emu/get_address.c
+++ b/arch/x86/math-emu/get_address.c
@@ -21,6 +21,7 @@
 
 #include 
 #include 
+#include 
 
 #include "fpu_system.h"
 #include "exception.h"
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 5196ac4..cf576f5 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -21,6 +21,7 @@
 #include  /* kmemcheck_*(), ...   */
 #include /* VSYSCALL_ADDR
*/
 #include   /* emulate_vsyscall */
+#include   /* struct vm86  */
 
 #define CREATE_TRACE_POINTS
 #include 
-- 
2.4.3

--
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 v4] x86: vm86 cleanups

[Brian Gerst]

The goal of this set of patches is to change vm86 support to return to
userspace with the normal exit paths instead of leaving data on the kernel
stack and jumping directly into the exit asm routines.  This fixes issues
like ptrace and syscall auditing not working with vm86, and makes possible
cleanups in the syscall exit work code.

Changes from v3:
- Removed patches already accepted
- Renamed some fields per Ingo
- Added patches to allow disabling hardware IRQ support and to fix includes
- Added helper macro for free_vm86 (Note: could not use inline function due
  to header issues)

Changes from v2:
- Use gs slot of regs32 (present but unused in lazy mode)
- Add access_ok() checks before get_user_try/put_user_try

Changes from v1:
- Added first two patches
- Changed userspace access to copy each field explicitly instead of relying
  on the same order of members in the structure.

--
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 v1 7/7] ARM: dts: ifc6410: add inforce LVDS panel support

[Archit Taneja]

Hi Srini,

On 07/28/2015 06:24 PM, Srinivas Kandagatla wrote:

This patch adds LVDS panel for IFC6410.

Signed-off-by: Rob Clark 
[Rob Clark: WIP patch]
Signed-off-by: Srinivas Kandagatla 
---
  arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 66 ++
  1 file changed, 66 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts 
b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index 1ab71f1..3bdac02 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -63,6 +63,12 @@
qcom,switch-mode-frequency = <320>;
};

+   pm8921_l2: l2 {
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
+   bias-pull-down;
+   };
+
pm8921_l3: l3 {
regulator-min-microvolt = <305>;
regulator-max-microvolt = <330>;
@@ -96,6 +102,10 @@
pm8921_lvs1: lvs1 {
bias-pull-down;
};
+
+   pm8921_lvs7: lvs7 {
+   bias-pull-down;
+   };
};
};

@@ -119,6 +129,41 @@

mdp: qcom,mdp@510 {
status = "okay";
+   qcom,lvds-panel = <&panel>;


We're trying to switch to the of_graph way of representing connected
panels. With that, the above phandle will go away. This needs to be 
replaced with:


port {
lvds_out: endpoint {
remote_endpoint = <&auo_in>;
};
};


+   lvds-vccs-3p3v-supply = <&ext_3p3v>;
+   lvds-pll-vdda-supply = <&pm8921_l2>;
+   lvds-vdda-supply = <&pm8921_lvs7>;
+   };
+
+   panel_3p3v: panel_3p3v {
+   compatible = "regulator-fixed";
+   pinctrl-0 = <&disp_en_gpios>;
+   pinctrl-names = "default";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "panel_en_3p3v";
+   regulator-type = "voltage";
+   startup-delay-us = <0>;
+   gpio = <&pm8921_gpio 36 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   regulator-boot-on;
+   };
+
+   backlight: backlight{
+   pinctrl-0 = <&pwm_bl_gpios>;
+   pinctrl-names = "default";
+   compatible = "gpio-backlight";
+   gpios = <&pm8921_gpio 26 GPIO_ACTIVE_HIGH>;
+   default-on;
+   };
+
+   panel: auo,b101xtn01 {
+   status = "okay";
+   compatible = "auo,b101xtn01";
+
+   ddc-i2c-bus = <&i2c3>;
+   backlight = <&backlight>;
+   power-supply = <&panel_3p3v>;


and for the panel:

port {
auo_in: endpoint {
remote-endpoint = <&lvds_out>;
};
};

Thanks,
Archit


};

gsbi3: gsbi@1620 {
@@ -235,6 +280,27 @@
pm8921_gpio: gpio@150 {
pinctrl-names = "default";
pinctrl-0 = <&wlan_default_gpios>;
+
+   pwm_bl_gpios: pwm-bl-gpios {
+   pios {
+   pins = "gpio26";
+   bias-disable;
+   function = "normal";
+   qcom,drive-strength = 
;
+   power-source = 
;
+   };
+   };
+
+   disp_en_gpios: disp-en-gpios {
+   pios {
+   pins = "gpio36";
+   bias-disable;
+   function = "normal"

Re: [PATCH] cpufreq: Replace recover_policy with new_policy in cpufreq_online()

[Viresh Kumar]

On 29-07-15, 03:08, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> The recover_policy is unsed in cpufreq_online() to indicate whether
> a new policy object is created or an existing one is reinitialized.
> 
> The "recover" part of the name is slightly confusing (it should be
> "reinitialization" rather than "recovery") and the logical not (!)
> operator is applied to it in almost all of the checks it is used in,
> so replace that variable with a new one called "new_policy" that
> will be true in the case of a new policy creation.
> 
> While at it, drop one of the labels that is jumped to from only
> one spot.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
> 
> One extra cleanup on top of https://patchwork.kernel.org/patch/6888751/
> 
> ---
>  drivers/cpufreq/cpufreq.c |   23 +++
>  1 file changed, 11 insertions(+), 12 deletions(-)

Acked-by: Viresh Kumar 

-- 
viresh
--
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: Next round: revised futex(2) man page for review

[Darren Hart]

On Tue, Jul 28, 2015 at 09:11:41PM -0700, Darren Hart wrote:
> On Tue, Jul 28, 2015 at 10:23:51PM +0200, Thomas Gleixner wrote:
> > On Mon, 27 Jul 2015, Michael Kerrisk (man-pages) wrote:
> 
> ...
> 
> > >FUTEX_REQUEUE (since Linux 2.6.0)
> > > .\" FIXME(Torvald) Is there some indication that FUTEX_REQUEUE is broken
> > > .\" in general, or is this comment implicitly speaking about the
> > > .\" condvar (?) use case? If the latter we might want to weaken the
> > > .\" advice below a little.
> > > .\" [Anyone else have input on this?]
> > 
> > The condvar use case exposes the flaw nicely, but that's pretty much
> > true for everything which wants a sane requeue operation.
> 
> In an earlier discussion I argued this point (that FUTURE_REQUEUE is broken 
> and
> should not be used in new code) and someone argued strongly against... stating
> that there were legitimate uses for it. Of course I'm struggling to find the
> thread and the reference at the moment - immensely useful, I know.
> 
> I'll continue trying to find it and see if it can be useful here. I believe
> Torvald was on the thread as well.
> 

Found it on libc-alpha, here it is for reference:

From: Rich Felker 
Date: Wed, 29 Oct 2014 22:43:17 -0400
To: Darren Hart 
Cc: Carlos O'Donell , Roland McGrath 
,
Torvald Riegel , GLIBC Devel 
,
Michael Kerrisk 
Subject: Re: Add futex wrapper to glibc?

On Wed, Oct 29, 2014 at 06:59:15PM -0700, Darren Hart wrote:
> > We are IMO at the stage where futex is stable, few things are
> > changing, and with documentation in place, I would consider adding a
> > futex wrapper.
> 
> Yes, at least for the defined OP codes. New OPs may be added of
> course, but that isn't a concern for supporting what exists today, and
> doesn't break compatibility.
> 
> I wonder though... can we not wrap FUTEX_REQUEUE? It's fundamentally
> broken.  FUTEX_CMP_REQUEUE should *always* be used instead. The glibc
> wrapper is one way to encourage developers to do the right thing
> (don't expose the bad op in the header).

You're mistaken here. There are plenty of valid ways to use
FUTEX_REQUEUE - for example if the calling thread is requeuing the
target(s) to a lock that the calling thread owns. Just because it
doesn't meet the needs of the way glibc was using it internally
doesn't mean it's useless for other applications.

In any case, I don't think there's a proposal to intercept/modify the
commands to futex, just to pass them through (and possibly do a
cancellable syscall for some of them).

Rich


> > 
> > >   Avoid using this operation.  It is broken for its intended
> > >   purpose.  Use FUTEX_CMP_REQUEUE instead.
> > > 
> > >   Thisoperationperformsthesametaskas
> > >   FUTEX_CMP_REQUEUE, except that no check is made using  the
> > >   value in val3.  (The argument val3 is ignored.)
> > > 
> 
> -- 
> Darren Hart
> Intel Open Source Technology Center

-- 
Darren Hart
Intel Open Source Technology Center
--
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: [Update 2x][PATCH 7/7] cpufreq: Separate CPU device registration from CPU online

[Viresh Kumar]

On 29-07-15, 03:03, Rafael J. Wysocki wrote:
> +static int cpufreq_add_dev(struct device *dev, struct subsys_interface *sif)
> +{
> + unsigned cpu = dev->id;
> + int ret;
> +
> + dev_dbg(dev, "%s: adding CPU%u\n", __func__, cpu);
> +
> + if (cpu_online(cpu)) {
> + ret = cpufreq_online(cpu);

I will do return right here ...

> + } else {

... and this else will not be required anymore.

> + /*
> +  * A hotplug notifier will follow and we will handle it as CPU
> +  * online then.  For now, just create the sysfs link, unless
> +  * there is no policy or the link is already present.
> +  */
> + struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu);
> +
> + ret = policy && !cpumask_test_and_set_cpu(cpu, 
> policy->real_cpus)
> + ? add_cpu_dev_symlink(policy, cpu) : 0;
> + }
> +
> + return ret;
> +}

Looks good otherwise.

Acked-by: Viresh Kumar 

-- 
viresh
--
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 2/2] rcu: Use call_rcu_func_to to replace explicit type equivalents

[Boqun Feng]

We have call_rcu_func_t for a quite while, but we still use explicit
function pointer type equivalents in some places, this patch replace
these equivalent types with call_rcu_func_t to gain better readability.

Signed-off-by: Boqun Feng 
---
 kernel/rcu/rcutorture.c | 2 +-
 kernel/rcu/tree.h   | 3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 51c8e7f..f9ec6cb 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -252,7 +252,7 @@ struct rcu_torture_ops {
void (*exp_sync)(void);
unsigned long (*get_state)(void);
void (*cond_sync)(unsigned long oldstate);
-   void (*call)(struct rcu_head *head, void (*func)(struct rcu_head *rcu));
+   call_rcu_func_t call;
void (*cb_barrier)(void);
void (*fqs)(void);
void (*stats)(void);
diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
index ad11529..0c33c82 100644
--- a/kernel/rcu/tree.h
+++ b/kernel/rcu/tree.h
@@ -464,8 +464,7 @@ struct rcu_state {
/*  shut bogus gcc warning) */
u8 flavor_mask; /* bit in flavor mask. */
struct rcu_data __percpu *rda;  /* pointer of percu rcu_data. */
-   void (*call)(struct rcu_head *head, /* call_rcu() flavor. */
-void (*func)(struct rcu_head *head));
+   call_rcu_func_t call;   /* call_rcu() flavor. */
 
/* The following fields are guarded by the root rcu_node's lock. */
 
-- 
2.4.6

--
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/2] rcu: Use rcu_callback_t in call_rcu*() and friends

[Boqun Feng]

As we now have rcu_callback_t typedefs as the type of rcu callbacks, we
should use it in call_rcu*() and friends as the type of parameters. This
could save us a few lines of code and make it clear which function
requires an rcu callbacks rather than other callbacks as its argument.

Besides, this can also help cscope to generate a better database for
code reading.

Signed-off-by: Boqun Feng 
---
 include/linux/rcupdate.h | 10 +-
 include/linux/rcutiny.h  |  2 +-
 include/linux/rcutree.h  |  2 +-
 kernel/rcu/rcutorture.c  |  4 ++--
 kernel/rcu/srcu.c|  2 +-
 kernel/rcu/tiny.c|  8 
 kernel/rcu/tree.c|  8 
 kernel/rcu/tree.h|  2 +-
 kernel/rcu/tree_plugin.h |  2 +-
 kernel/rcu/update.c  |  2 +-
 10 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index ff47651..78af46c 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -160,7 +160,7 @@ void do_trace_rcu_torture_read(const char *rcutorturename,
  * more than one CPU).
  */
 void call_rcu(struct rcu_head *head,
- void (*func)(struct rcu_head *head));
+ rcu_callback_t func);
 
 #else /* #ifdef CONFIG_PREEMPT_RCU */
 
@@ -191,7 +191,7 @@ void call_rcu(struct rcu_head *head,
  * memory ordering guarantees.
  */
 void call_rcu_bh(struct rcu_head *head,
-void (*func)(struct rcu_head *head));
+rcu_callback_t func);
 
 /**
  * call_rcu_sched() - Queue an RCU for invocation after sched grace period.
@@ -213,7 +213,7 @@ void call_rcu_bh(struct rcu_head *head,
  * memory ordering guarantees.
  */
 void call_rcu_sched(struct rcu_head *head,
-   void (*func)(struct rcu_head *rcu));
+   rcu_callback_t func);
 
 void synchronize_sched(void);
 
@@ -275,7 +275,7 @@ do { \
  * See the description of call_rcu() for more detailed information on
  * memory ordering guarantees.
  */
-void call_rcu_tasks(struct rcu_head *head, void (*func)(struct rcu_head 
*head));
+void call_rcu_tasks(struct rcu_head *head, rcu_callback_t func);
 void synchronize_rcu_tasks(void);
 void rcu_barrier_tasks(void);
 
@@ -1066,7 +1066,7 @@ static inline notrace void 
rcu_read_unlock_sched_notrace(void)
 #define __kfree_rcu(head, offset) \
do { \
BUILD_BUG_ON(!__is_kfree_rcu_offset(offset)); \
-   kfree_call_rcu(head, (void (*)(struct rcu_head *))(unsigned 
long)(offset)); \
+   kfree_call_rcu(head, (rcu_callback_t)(unsigned long)(offset)); \
} while (0)
 
 /**
diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
index ff968b7..c8a0722 100644
--- a/include/linux/rcutiny.h
+++ b/include/linux/rcutiny.h
@@ -83,7 +83,7 @@ static inline void synchronize_sched_expedited(void)
 }
 
 static inline void kfree_call_rcu(struct rcu_head *head,
- void (*func)(struct rcu_head *rcu))
+ rcu_callback_t func)
 {
call_rcu(head, func);
 }
diff --git a/include/linux/rcutree.h b/include/linux/rcutree.h
index 5abec82..60d15a0 100644
--- a/include/linux/rcutree.h
+++ b/include/linux/rcutree.h
@@ -48,7 +48,7 @@ void synchronize_rcu_bh(void);
 void synchronize_sched_expedited(void);
 void synchronize_rcu_expedited(void);
 
-void kfree_call_rcu(struct rcu_head *head, void (*func)(struct rcu_head *rcu));
+void kfree_call_rcu(struct rcu_head *head, rcu_callback_t func);
 
 /**
  * synchronize_rcu_bh_expedited - Brute-force RCU-bh grace period
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 7719295..51c8e7f 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -448,7 +448,7 @@ static void synchronize_rcu_busted(void)
 }
 
 static void
-call_rcu_busted(struct rcu_head *head, void (*func)(struct rcu_head *rcu))
+call_rcu_busted(struct rcu_head *head, rcu_callback_t func)
 {
/* This is a deliberate bug for testing purposes only! */
func(head);
@@ -523,7 +523,7 @@ static void srcu_torture_synchronize(void)
 }
 
 static void srcu_torture_call(struct rcu_head *head,
- void (*func)(struct rcu_head *head))
+ rcu_callback_t func)
 {
call_srcu(srcu_ctlp, head, func);
 }
diff --git a/kernel/rcu/srcu.c b/kernel/rcu/srcu.c
index d3fcb2e..9e61225 100644
--- a/kernel/rcu/srcu.c
+++ b/kernel/rcu/srcu.c
@@ -387,7 +387,7 @@ static void srcu_flip(struct srcu_struct *sp)
  * srcu_struct structure.
  */
 void call_srcu(struct srcu_struct *sp, struct rcu_head *head,
-   void (*func)(struct rcu_head *head))
+  rcu_callback_t func)
 {
unsigned long flags;
 
diff --git a/kernel/rcu/tiny.c b/kernel/rcu/tiny.c
index d047105..944b1b4 100644
--- a/kernel/rcu/tiny.c
+++ b/kernel/rcu/tiny.c
@@ -44,7 +44,7 @@ struct rcu_ctrlblk;
 static void __rcu_process_callbacks(struct rcu_ctrlblk *rcp);
 static void rcu_process_callbacks(struct softirq_action *unuse

[PATCH 0/2] Replace explicit function pointer types with rcu_callback_t and call_rcu_func_t

[Boqun Feng]

Commit ("rcu: Create a synchronize_rcu_mult()") in linux-rcu.git#rcu/next
branch has introduced rcu_callback_t as the type for rcu callback
functions and call_rcu_func_t has been introduced for a while. This patch
series uses the rcu_callback_t and call_rcu_func_t to save a few lines of
code.

This patchset is based on rcu/next branch of Paul's linux-rcu tree, and
consists of two patches:

1.  Use rcu_callback_t as the type of callbacks in call_rcu*() and
friends

2.  Use call_rcu_func_t to replace the equivalent but complicated
function pointer type.

Besides cleaning up the code, this patchset can also help code tag program,
such as cscope to generate a better database.

This patchset has been already tested by 0day.

Regards,
Boqun

-
 include/linux/rcupdate.h | 10 +-
 include/linux/rcutiny.h  |  2 +-
 include/linux/rcutree.h  |  2 +-
 kernel/rcu/rcutorture.c  |  6 +++---
 kernel/rcu/srcu.c|  2 +-
 kernel/rcu/tiny.c|  8 
 kernel/rcu/tree.c|  8 
 kernel/rcu/tree.h|  5 ++---
 kernel/rcu/tree_plugin.h |  2 +-
 kernel/rcu/update.c  |  2 +-
 10 files changed, 23 insertions(+), 24 deletions(-)

-- 
2.4.6

--
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 0/3] x86: modify_ldt improvement, test, and config option

[Andy Lutomirski]

On Tue, Jul 28, 2015 at 8:01 PM, Boris Ostrovsky
 wrote:
> On 07/28/2015 08:47 PM, Andrew Cooper wrote:
>>
>> On 29/07/2015 01:21, Andy Lutomirski wrote:
>>>
>>> On Tue, Jul 28, 2015 at 10:10 AM, Boris Ostrovsky
>>>  wrote:

 On 07/28/2015 01:07 PM, Andy Lutomirski wrote:
>
> On Tue, Jul 28, 2015 at 9:30 AM, Andrew Cooper
>  wrote:
>>
>> I suspect that the set_ldt(NULL, 0) call hasn't reached Xen before
>> xen_free_ldt() is attempting to nab back the pages which Xen still has
>> mapped as an LDT.
>>
> I just instrumented it with yet more LSL instructions.  I'm pretty
> sure that set_ldt really is clearing at least LDT entry zero.
> Nonetheless the free_ldt call still oopses.
>
 Yes, I added some instrumentation to the hypervisor and we definitely
 set
 LDT to NULL before failing.

 -boris
>>>
>>> Looking at map_ldt_shadow_page: what keeps shadow_ldt_mapcnt from
>>> getting incremented once on each CPU at the same time if both CPUs
>>> fault in the same shadow LDT page at the same time?
>>
>> Nothing, but that is fine.  If a page is in use in two vcpus LDTs, it is
>> expected to have a type refcount of 2.
>>
>>> Similarly, what
>>> keeps both CPUs from calling get_page_type at the same time and
>>> therefore losing track of the page type reference count?
>>
>> a cmpxchg() loop in the depths of __get_page_type().
>>
>>> I don't see why vmalloc or vm_unmap_aliases would have anything to do
>>> with this, though.
>
>
> So just for kicks I made lazy_max_pages() return 0 to free vmaps immediately
> and the problem went away.

As far as I can tell, this affects TLB flushes but not unmaps.  That
means that my patch is totally bogus -- vm_unmap_aliases() *flushed*
aliases but isn't involved in removing them from the page tables.
That must be why xen_alloc_ldt and xen_set_ldt work today.

So what does flushing the TLB have to do with anything?  The only
thing I can think of is that it might force some deferred hypercalls
out.  I can reproduce this easily on UP, so IPIs aren't involved.

The other odd thing is that it seems like this happens when clearing
the LDT and freeing the old one but not when setting the LDT and
freeing the old one.  This is plausibly related to the lazy mode in
effect at the time, but I have no evidence for that.

Two more data points:  Putting xen_flush_mc before and after the
SET_LDT multicall has no effect.  Putting flush_tlb_all() in
xen_free_ldt doesn't help either, while vm_unmap_aliases() in the
exact same place does help.

--Andy
--
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: Next round: revised futex(2) man page for review

[Darren Hart]

On Tue, Jul 28, 2015 at 10:23:51PM +0200, Thomas Gleixner wrote:
> On Mon, 27 Jul 2015, Michael Kerrisk (man-pages) wrote:

...

> >FUTEX_REQUEUE (since Linux 2.6.0)
> > .\" FIXME(Torvald) Is there some indication that FUTEX_REQUEUE is broken
> > .\" in general, or is this comment implicitly speaking about the
> > .\" condvar (?) use case? If the latter we might want to weaken the
> > .\" advice below a little.
> > .\" [Anyone else have input on this?]
> 
> The condvar use case exposes the flaw nicely, but that's pretty much
> true for everything which wants a sane requeue operation.

In an earlier discussion I argued this point (that FUTURE_REQUEUE is broken and
should not be used in new code) and someone argued strongly against... stating
that there were legitimate uses for it. Of course I'm struggling to find the
thread and the reference at the moment - immensely useful, I know.

I'll continue trying to find it and see if it can be useful here. I believe
Torvald was on the thread as well.

> 
> >   Avoid using this operation.  It is broken for its intended
> >   purpose.  Use FUTEX_CMP_REQUEUE instead.
> > 
> >   Thisoperationperformsthesametaskas
> >   FUTEX_CMP_REQUEUE, except that no check is made using  the
> >   value in val3.  (The argument val3 is ignored.)
> > 

-- 
Darren Hart
Intel Open Source Technology Center
--
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] Staging : wilc1000: Remove unnecessary parentheses

[Shraddha Barke]

Remove parentheses around the right hand side of an assignment
as they are not needed

The semantic patch used is :

@@
expression E;
expression f;
constant C;
@@
(
f = (E == C)
|
f =
- (
  E
- )

)

Signed-off-by: Shraddha Barke 
---
 drivers/staging/wilc1000/wilc_sdio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wilc1000/wilc_sdio.c 
b/drivers/staging/wilc1000/wilc_sdio.c
index 897e47e..4b81f17 100644
--- a/drivers/staging/wilc1000/wilc_sdio.c
+++ b/drivers/staging/wilc1000/wilc_sdio.c
@@ -1072,7 +1072,7 @@ static int sdio_clear_int_ext(uint32_t val)
cmd.function = 0;
cmd.raw = 0;
cmd.address = 0xf8;
-   cmd.data = (1 << i);
+   cmd.data = 1 << i;
 
ret = g_sdio.sdio_cmd52(&cmd);
if (!ret) {
-- 
2.1.0

--
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/5] mtd: nand: Qualcomm NAND controller driver

[Archit Taneja]

On 07/29/2015 07:18 AM, Stephen Boyd wrote:

On 07/27/2015 09:34 PM, Archit Taneja wrote:

Hi,

On 07/25/2015 06:21 AM, Stephen Boyd wrote:

On 07/21/2015 03:34 AM, Archit Taneja wrote:


+  int size)
+{Looks like a
+struct desc_info *desc;
+struct dma_async_tx_descriptor *dma_desc;
+struct scatterlist *sgl;
+int r;
+
+desc = kzalloc(sizeof(*desc), GFP_KERNEL);
+if (!desc)
+return -ENOMEM;
+
+list_add_tail(&desc->list, &this->list);
+
+sgl = &desc->sgl;
+
+sg_init_one(sgl, vaddr, size);
+
+desc->dir = DMA_MEM_TO_DEV;
+
+r = dma_map_sg(this->dev, sgl, 1, desc->dir);
+if (r == 0)
+goto err;


Should we return an error in this case? Looks like return 0.


dma_map_sg returns the number of sg entries successfully mapped. In
this case, it should be 1.


Right, but this function returns 0 (success?) if we failed to map anything.


Yes. The return value is number of entries successfully mapped. 
dma_map_sg is a macro that is replaced by dma_map_sg_attrs. Its comment

says:

"dma_maps_sg_attrs returns 0 on error and > 0 on success. It should 
never return a value < 0."









+
+this->slave_conf.device_fc = 0;
+this->slave_conf.dst_addr = this->res->start + reg_off;
+this->slave_conf.dst_maxburst = 16;


Is there any reason why slave_conf can't be on the stack? Otherwise it's
odd that it's overwritten a few times before we submit the descriptors,
so it must be copied by the dmaengine provider, but that isn't clear at
all from the code. If it isn't copied, perhaps it should be part of the
desc_info structure. If it is copied I wonder why it isn't const in the
function signature.


The dmaengine drivers either memcpy slave_config in their
device_config() dmaengine op, or populate their local members reading
params in the passed slave_config.

I'll move slave_conf to stack. As you said, the config argument
in dmaengine_slave_config should ideally use const.


Cool, someone should send a patch.






+
+r = dmaengine_slave_config(this->chan, &this->slave_conf);
+if (r) {
+dev_err(this->dev, "failed to configure dma channel\n");
+goto err;
+}
+
+dma_desc = dmaengine_prep_slave_sg(this->chan, sgl, 1,
desc->dir, 0);
+if (!dma_desc) {
+dev_err(this->dev, "failed to prepare data write desc\n");
+r = PTR_ERR(dma_desc);
+goto err;
+}
+
+desc->dma_desc = dma_desc;
+
+return 0;
+err:
+kfree(desc);
+
+return r;
+}
+
+/*
+ * helper to prepare dma descriptors to configure registers needed
for reading a
+ * codeword/step in a page
+ */
+static void config_cw_read(struct qcom_nandc_data *this)
+{
+struct nandc_regs *regs = this->regs;
+
+write_reg_dma(this, NAND_FLASH_CMD, ®s->cmd, 3, true);


Maybe it would be better to have a case statement inside
{write,read}_reg_dma() that looked at the second argument and matched it
up with an offset in regs. Then this could be

 write_reg_dma(this, NAND_FLASH_CMD, 3, true);


That's a good idea. However, we have at least one programming seqeunce
(in nandc_param) where we need to write two different values to the
same register. In such a case, we need two different locations to
store the two values.

I can split up the programming sequence into two parts such that we
won't write to the same register twice. But doing this for the sake of
reducing an argument to write_reg_dma seems a bit unnecessary.



Or you could have two #defines that indicate the different usage? Like
NAND_CMD_FOO and NAND_CMD_BAR that both map to the same register but
uses different locations as storage.


Yeah, that seems like a good option. I'll try this out.





Are we guaranteed that this is called within the same context as where
the buffer is passed to this function? Otherwise this stack check isn't
going to work because object_is_on_stack() will silently fail.


These are funcs are finally tied to mtd ops. I think in normal operation
it'll be the same context. I'll still cross check. The aim of the check
is to prevent a memcpy of the buffer to/from the layer above. A false
negative will result in a slower read/write operation.


Right. It would be nice if the mtd layer was DMA aware and could
indicate to drivers that DMA on the buffer is allowable or not. Trying
to figure it out if the buffer is in lowmem after the buffer is mapped
is error prone, which is why not a lot of usage of object_is_on_stack()
exists. Honestly I'm confused, I thought the DMA APIs would "do the
right thing" when highmem was passed into the mapping APIs, but maybe
I'm wrong. I'll have to look.


It looks like NAND_USE_BOUNCE_BUFFER does just that. If we set this
flag, the nand_base layer provides a DMA-able buffer even if the
filesystem didn't.

No one was using this flag when I last checked. A new driver
brcmnand now uses it. I'll give this a try.

Archit

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

RE: [PATCH v3 1/1] kernel/sysctl.c: Add /proc/sys/vm/shrink_memory feature

[PINTU KUMAR]

Sorry, for late reply.

> -Original Message-
> From: Mel Gorman [mailto:mgor...@suse.de]
> Sent: Wednesday, July 22, 2015 7:36 PM
> To: PINTU KUMAR
> Cc: a...@linux-foundation.org; cor...@lwn.net; vba...@suse.cz;
> gorcu...@openvz.org; mho...@suse.cz; emun...@akamai.com;
> kirill.shute...@linux.intel.com; standby2...@gmail.com;
> han...@cmpxchg.org; vdavy...@parallels.com; hu...@google.com;
> minc...@kernel.org; t...@kernel.org; rient...@google.com;
> xypron.g...@gmx.de; dzic...@redhat.com; pra...@redhat.com;
> ebied...@xmission.com; rost...@goodmis.org; uober...@redhat.com;
> paul...@linux.vnet.ibm.com; iamjoonsoo@lge.com; ddstr...@ieee.org;
> sasha.le...@oracle.com; koc...@gmail.com; c...@linux.com;
> opensource.gan...@gmail.com; vinme...@codeaurora.org; linux-
> d...@vger.kernel.org; linux-kernel@vger.kernel.org; linux...@kvack.org; linux-
> p...@vger.kernel.org; qiuxi...@huawei.com; valdis.kletni...@vt.edu;
> c...@samsung.com; pintu_agar...@yahoo.com; vishnu...@samsung.com;
> rohit...@samsung.com; iqbal@samsung.com; pintu.p...@gmail.com;
> pint...@outlook.com
> Subject: Re: [PATCH v3 1/1] kernel/sysctl.c: Add /proc/sys/vm/shrink_memory
> feature
> 
> On Wed, Jul 22, 2015 at 06:33:26PM +0530, PINTU KUMAR wrote:
> > Dear Mel, thank you very much for your comments and suggestions.
> > I will drop this one and look on further improving direct_reclaim and
> > compaction.
> > Just few more comments below before I close.
> >
> > Also, during this patch, I feel that the hibernation_mode part in
> > shrink_all_memory can be corrected.
> > So, can I separately submit the below patch?
> > That is instead of hard-coding the hibernation_mode, we can get
> > hibernation status using:
> > system_entering_hibernation()
> >
> > Please let me know your suggestion about this changes.
> >
> > -#ifdef CONFIG_HIBERNATION
> > +#if defined CONFIG_HIBERNATION || CONFIG_SHRINK_MEMORY
> 
I was talking about only the following case.
Instead of hard coding the hibernation_mode in shrink_all_memory, 
We can set it at runtime.

-   .hibernation_mode = 1,

+   if (system_entering_hibernation())
+   sc.hibernation_mode = 1;
+   else
+   sc.hibernation_mode = 0;

The PM owners should confirm if this is ok.
Once confirmed, I will submit the full patch set.

+> This appears to be a patch on top of "Add /proc/sys/vm/shrink_memory feature"
> so I do not see what would be separately submitted that would make sense.
> 
And we don't need to have /proc/sys/vm/shrink_memory patch for this.

However, if required, we can also expose shrink_all_memory() outside the
hibernation using the CONFIG_SHRINK_MEMORY.
Otherwise, we can neglect other changes.

> --
> 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 v2 2/4] toshiba_acpi: Remove "*not supported" feature prints

[Darren Hart]

Hi Azael,

On Mon, Jul 27, 2015 at 07:22:26PM -0600, Azael Avalos wrote:
> Currently the driver prints "*not supported" if any of the features
> queried are in fact not supported, let us print the available
> features instead.
> 
> This patch removes all instances pr_info printing "*not supported",
> and add a new function called "print_supported_features", which will
> print the available laptop features.
> 
> Signed-off-by: Azael Avalos 
> ---
>  drivers/platform/x86/toshiba_acpi.c | 69 
> +++--
>  1 file changed, 44 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/platform/x86/toshiba_acpi.c 
> b/drivers/platform/x86/toshiba_acpi.c
> index e164926..e24f0f5 100644
> --- a/drivers/platform/x86/toshiba_acpi.c
> +++ b/drivers/platform/x86/toshiba_acpi.c
> @@ -477,13 +477,10 @@ static void toshiba_illumination_set(struct 
> led_classdev *cdev,
>   state = brightness ? 1 : 0;
>   result = sci_write(dev, SCI_ILLUMINATION, state);
>   sci_close(dev);
> - if (result == TOS_FAILURE) {
> + if (result == TOS_FAILURE)
>   pr_err("ACPI call for illumination failed\n");
> + else if (result == TOS_NOT_SUPPORTED)
>   return;

And otherwise return. So this last if test doesn't do anything. If you feel
the context is relevant, consider just including it as a comment.

Thanks,

-- 
Darren Hart
Intel Open Source Technology Center
--
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] toshiba_acpi: Change *available functions return type

[Darren Hart]

On Mon, Jul 27, 2015 at 07:22:25PM -0600, Azael Avalos wrote:
> This patch changes the *available functions return type from int to
> void.
> 
> The checks for support of their respective features are done inside
> such functions and there was no need to return anything as we can
> flag the queried feature as supported inside these functions.
> 
> The code was adapted accordingly to these changes and two new
> variables were created and another was changed from uint to bool.
> 
> While at the neighborhood, some of the functions were cleaned from

Please consider this a red flag in the future. "While in the neighborhood" means
you need to split the patch across distinct functional boundaries.

-- 
Darren Hart
Intel Open Source Technology Center
--
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 RFC 2/3] x86: Add Intel PT logger

[Takao Indoh]

This patch provides Intel PT logging feature. When system boots with a
parameter "intel_pt_log", log buffers for Intel PT are allocated and
logging starts, then processor flow information is written in the log
buffer by hardware like flight recorder. This is very helpful to
investigate a cause of kernel panic.

The log buffer size is specified by the parameter
"intel_pt_log_buf_len=". This buffer is used as circular buffer,
therefore old events are overwritten by new events.

Signed-off-by: Takao Indoh 
---
 arch/x86/Kconfig   |   16 ++
 arch/x86/kernel/cpu/Makefile   |2 +
 arch/x86/kernel/cpu/intel_pt_log.c |  288 
 3 files changed, 306 insertions(+), 0 deletions(-)
 create mode 100644 arch/x86/kernel/cpu/intel_pt_log.c

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 55bced1..c31400f 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1658,6 +1658,22 @@ config X86_INTEL_MPX
 
  If unsure, say N.
 
+config X86_INTEL_PT_LOG
+   prompt "Intel PT logger"
+   def_bool n
+   depends on CPU_SUP_INTEL
+   ---help---
+ Intel PT is a hardware features that can capture information
+ about program execution flow. Once Intel PT is enabled, the
+ events which change program flow, like branch instructions,
+ exceptions, interruptions, traps and so on are logged in
+ the memory.
+
+ This option enables starting Intel PT logging feature at boot
+ time. When kernel panic occurs, Intel PT log buffer can be
+ retrieved from crash dump file and enables to reconstruct the
+ detailed flow that led to the panic.
+
 config EFI
bool "EFI runtime service support"
depends on ACPI
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 77d371c..24629ff 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -58,6 +58,8 @@ obj-$(CONFIG_X86_LOCAL_APIC)  += perfctr-watchdog.o 
perf_event_amd_ibs.o
 
 obj-$(CONFIG_HYPERVISOR_GUEST) += vmware.o hypervisor.o mshyperv.o
 
+obj-$(CONFIG_X86_INTEL_PT_LOG) += intel_pt_log.o
+
 ifdef CONFIG_X86_FEATURE_NAMES
 quiet_cmd_mkcapflags = MKCAP   $@
   cmd_mkcapflags = $(CONFIG_SHELL) $(srctree)/$(src)/mkcapflags.sh $< $@
diff --git a/arch/x86/kernel/cpu/intel_pt_log.c 
b/arch/x86/kernel/cpu/intel_pt_log.c
new file mode 100644
index 000..b1c4d66
--- /dev/null
+++ b/arch/x86/kernel/cpu/intel_pt_log.c
@@ -0,0 +1,288 @@
+/*
+ * Intel Processor Trace Logger
+ *
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+
+#define PT_LOG_GFP (GFP_KERNEL | __GFP_ZERO | __GFP_NOWARN | __GFP_NORETRY)
+
+struct pt_log_buf {
+   int cpu;
+
+   void **region;  /* array of pointer to output region */
+   int region_size;/* size of region array */
+   int region_order;   /* page order of region */
+
+   void **tbl; /* array of pointer to ToPA table */
+   int tbl_size;   /* size of tbl array */
+
+   /* Saved registers on panic */
+   u64 saved_msr_ctl;
+   u64 saved_msr_status;
+   u64 saved_msr_output_base;
+   u64 saved_msr_output_mask;
+};
+
+static int pt_log_enabled;
+static int pt_log_buf_nr_pages = 1024; /* number of pages for log buffer */
+
+static DEFINE_PER_CPU(struct pt_log_buf, pt_log_buf_ptr);
+static struct cpumask pt_cpu_mask;
+
+static void enable_pt(int enable)
+{
+   u64 ctl;
+
+   rdmsrl(MSR_IA32_RTIT_CTL, ctl);
+
+   if (enable)
+   ctl |= RTIT_CTL_TRACEEN;
+   else
+   ctl &= ~RTIT_CTL_TRACEEN;
+
+   wrmsrl(MSR_IA32_RTIT_CTL, ctl);
+}
+
+void save_intel_pt_registers(void)
+{
+   struct pt_log_buf *buf = this_cpu_ptr(&pt_log_buf_ptr);
+
+   if (!cpumask_test_cpu(smp_processor_id(), &pt_cpu_mask))
+   return;
+
+   enable_pt(0);
+
+   rdmsrl(MSR_IA32_RTIT_CTL, buf->saved_msr_ctl);
+   rdmsrl(MSR_IA32_RTIT_STATUS, buf->saved_msr_status);
+   rdmsrl(MSR_IA32_RTIT_OUTPUT_BASE, buf->saved_msr_output_base);
+   rdmsrl(MSR_IA32_RTIT_OUTPUT_MASK, buf->saved_msr_output_mask);
+}
+
+static void setup_pt_ctl_register(void)
+{
+   u64 reg;
+
+   rdmsrl(MSR_IA32_RTIT_CTL, reg);
+
+   reg |= 
RTIT_CTL_OS|RTIT_CTL_USR|RTIT_CTL_TOPA|RTIT_CTL_TSC_EN|RTIT_CTL_BRANCH_EN;
+
+   wrmsrl(MSR_IA32_RTIT_CTL, reg);
+}
+
+static void setup_pt_output_register(void *base, unsigned int topa_idx,
+unsigned int output_off)
+{
+   u64 reg;
+
+   wrmsrl(MSR_IA32_RTIT_OUTPUT_BASE, virt_to_phys(base));
+
+   reg = 0x7f | ((u64)topa_idx << 7) | ((u64)output_off << 32);
+
+   wrmsrl(MSR_IA32_RTIT_OUTPUT_MASK, reg);
+}
+
+static void *pt_alloc_pages(void **buf, int *index, int node, int order)
+{
+   struct page *page;
+   void *ptr = NULL;
+
+   page = alloc_pages_node(node, PT_LOG_GFP, order);
+   if (p

Re: [PATCH v1 0/7] DT: APQ8064 for qcom-dt-next

[Andy Gross]

On Tue, Jul 28, 2015 at 01:52:36PM +0100, Srinivas Kandagatla wrote:
> Hi Andy, 
> 
> As discussed here are some dt patches which depend on
> pmic header "dt-bindings/pinctrl/qcom,pmic-gpio.h" which is availble in
> linux-next.

Ok.  I took all of these and put them on top of my 4.3 tags on the
qcom/for-next.  I compiled against the current next master and all was well.




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

--
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] toshiba_acpi: Add set_fan_status function

[Darren Hart]

On Mon, Jul 27, 2015 at 07:22:23PM -0600, Azael Avalos wrote:
> This patch adds a new function named "set_fan_status" to complement
> its get* counterpart, as well as to avoid code duplication between
> "fan_proc_write" and "fan_store".
> 
> Also, both functions (get*, set*) are now checking for TOS_FAILURE,
> TOS_NOT_SUPPORTED and TOS_SUCCESS (to be on par with the rest of the
> HCI/SCI functions), printing an error message, returning -ENODEV and
> zero respectively.
> 
> The proc and sysfs functions were updated to reflect these changes as
> well, returning -EIO for proc, and propagating the error value on the
> sysfs functions.
> 
> Signed-off-by: Azael Avalos 

Queued, thanks Azael!

-- 
Darren Hart
Intel Open Source Technology Center
--
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 RFC 3/3] x86: Stop Intel PT and save its registers when panic occurs

[Takao Indoh]

When panic occurs, Intel PT logging is stopped to prevent it from
overwrite its log buffer. The registers of Intel PT are saved in the
memory on panic, they are needed for debugger to find the last position
where Intel PT wrote data.

Signed-off-by: Takao Indoh 
---
 arch/x86/include/asm/intel_pt.h |2 ++
 arch/x86/kernel/crash.c |9 +
 2 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/arch/x86/include/asm/intel_pt.h b/arch/x86/include/asm/intel_pt.h
index 7cb16e1..71bcd8d 100644
--- a/arch/x86/include/asm/intel_pt.h
+++ b/arch/x86/include/asm/intel_pt.h
@@ -79,4 +79,6 @@ u32 pt_cap_get(enum pt_capabilities cap);
 const char *pt_cap_name(enum pt_capabilities cap);
 int pt_cap_num(void);
 
+void save_intel_pt_registers(void);
+
 #endif /* __INTEL_PT_H__ */
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index e068d66..953c086 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Alignment required for elf header segment */
 #define ELF_CORE_HEADER_ALIGN   4096
@@ -127,6 +128,10 @@ static void kdump_nmi_callback(int cpu, struct pt_regs 
*regs)
cpu_emergency_vmxoff();
cpu_emergency_svm_disable();
 
+#ifdef CONFIG_X86_INTEL_PT_LOG
+   save_intel_pt_registers();
+#endif
+
disable_local_APIC();
 }
 
@@ -172,6 +177,10 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
cpu_emergency_vmxoff();
cpu_emergency_svm_disable();
 
+#ifdef CONFIG_X86_INTEL_PT_LOG
+   save_intel_pt_registers();
+#endif
+
 #ifdef CONFIG_X86_IO_APIC
/* Prevent crash_kexec() from deadlocking on ioapic_lock. */
ioapic_zap_locks();
-- 
1.7.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/

[PATCH RFC 1/3] x86: Add Intel PT common files

[Takao Indoh]

Rename existing intel_pt.h to intel_pt_perf.h as a perf-specific header,
and make a new intel_pt.h as a common header of Intel PT feature. Also
add intel_pt_cap.c for Intel PT capability stuff.

Signed-off-by: Takao Indoh 
---
 arch/x86/include/asm/intel_pt.h   |   82 ++
 arch/x86/kernel/cpu/Makefile  |1 +
 arch/x86/kernel/cpu/intel_pt.h|  131 -
 arch/x86/kernel/cpu/intel_pt_cap.c|   69 +++
 arch/x86/kernel/cpu/intel_pt_perf.h   |   78 +
 arch/x86/kernel/cpu/perf_event_intel_pt.c |   54 ++--
 6 files changed, 239 insertions(+), 176 deletions(-)
 create mode 100644 arch/x86/include/asm/intel_pt.h
 delete mode 100644 arch/x86/kernel/cpu/intel_pt.h
 create mode 100644 arch/x86/kernel/cpu/intel_pt_cap.c
 create mode 100644 arch/x86/kernel/cpu/intel_pt_perf.h

diff --git a/arch/x86/include/asm/intel_pt.h b/arch/x86/include/asm/intel_pt.h
new file mode 100644
index 000..7cb16e1
--- /dev/null
+++ b/arch/x86/include/asm/intel_pt.h
@@ -0,0 +1,82 @@
+/*
+ * Intel(R) Processor Trace common header
+ * Copyright (c) 2013-2014, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ *
+ * Intel PT is specified in the Intel Architecture Instruction Set Extensions
+ * Programming Reference:
+ * http://software.intel.com/en-us/intel-isa-extensions
+ */
+
+#ifndef __INTEL_PT_H__
+#define __INTEL_PT_H__
+
+/*
+ * Table of Physical Addresses bits
+ */
+enum topa_sz {
+   TOPA_4K = 0,
+   TOPA_8K,
+   TOPA_16K,
+   TOPA_32K,
+   TOPA_64K,
+   TOPA_128K,
+   TOPA_256K,
+   TOPA_512K,
+   TOPA_1MB,
+   TOPA_2MB,
+   TOPA_4MB,
+   TOPA_8MB,
+   TOPA_16MB,
+   TOPA_32MB,
+   TOPA_64MB,
+   TOPA_128MB,
+   TOPA_SZ_END,
+};
+
+static inline unsigned int sizes(enum topa_sz tsz)
+{
+   return 1 << (tsz + 12);
+};
+
+struct topa_entry {
+   u64 end : 1;
+   u64 rsvd0   : 1;
+   u64 intr: 1;
+   u64 rsvd1   : 1;
+   u64 stop: 1;
+   u64 rsvd2   : 1;
+   u64 size: 4;
+   u64 rsvd3   : 2;
+   u64 base: 36;
+   u64 rsvd4   : 16;
+};
+
+#define TOPA_SHIFT 12
+#define PT_CPUID_LEAVES 2
+
+/*
+ * Capability stuff
+ */
+enum pt_capabilities {
+   PT_CAP_max_subleaf = 0,
+   PT_CAP_cr3_filtering,
+   PT_CAP_topa_output,
+   PT_CAP_topa_multiple_entries,
+   PT_CAP_payloads_lip,
+};
+
+void pt_cap_init(void);
+u32 pt_cap_get(enum pt_capabilities cap);
+const char *pt_cap_name(enum pt_capabilities cap);
+int pt_cap_num(void);
+
+#endif /* __INTEL_PT_H__ */
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 9bff687..77d371c 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_CPU_SUP_CYRIX_32)+= cyrix.o
 obj-$(CONFIG_CPU_SUP_CENTAUR)  += centaur.o
 obj-$(CONFIG_CPU_SUP_TRANSMETA_32) += transmeta.o
 obj-$(CONFIG_CPU_SUP_UMC_32)   += umc.o
+obj-$(CONFIG_CPU_SUP_INTEL)+= intel_pt_cap.o
 
 obj-$(CONFIG_PERF_EVENTS)  += perf_event.o
 
diff --git a/arch/x86/kernel/cpu/intel_pt.h b/arch/x86/kernel/cpu/intel_pt.h
deleted file mode 100644
index 1c338b0..000
--- a/arch/x86/kernel/cpu/intel_pt.h
+++ /dev/null
@@ -1,131 +0,0 @@
-/*
- * Intel(R) Processor Trace PMU driver for perf
- * Copyright (c) 2013-2014, Intel Corporation.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope 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.
- *
- * Intel PT is specified in the Intel Architecture Instruction Set Extensions
- * Programming Reference:
- * http://software.intel.com/en-us/intel-isa-extensions
- */
-
-#ifndef __INTEL_PT_H__
-#define __INTEL_PT_H__
-
-/*
- * Single-entry ToPA: when this close to region boundary, switch
- * buffers to avoid losing data.
- */
-#define TOPA_PMI_MARGIN 512
-
-/*
- * Table of Physical Addresses bits
- */
-enum topa_sz {
-   TOPA_4K = 0,
-   TOPA_8K,
-   TOPA_16K,
-   TOPA_32K,
-   TOPA_64K,
-   TOPA_128K,
-   TOPA_256K,
-   TOPA_512K,
-   TOPA_1MB,
-   TOPA_2MB,
-  

Re: [PATCH v2 3/4] toshiba_acpi: Refactor *{get, set} functions return value

[Darren Hart]

On Mon, Jul 27, 2015 at 07:22:27PM -0600, Azael Avalos wrote:
> This patch changes the default return value of the driver *{get, set}
> functions from 0 (success) to -EIO, since the driver default error
> value is -EIO.
> 
> All the functions now check for TOS_FAILURE, TOS_NOT_SUPPORTED and
> TOS_SUCCESS.
> 
> On TOS_FAILURE a pr_err message is printed informing the user of the
> error (no change was made to this, except the check was added to the
> functions not checking for this).
> 
> On TOS_NOT_SUPPORTED we now return -ENODEV immediately (some
> functions were returning -EIO)
> 
> On TOS_SUCCESS we now return 0, as a side effect, a new success value
> was added, since some functions return one instead of zero to
> indicate success.
> 
> As a special case, the LED functions only check for TOS_FAILURE on
> *set, and check for TOS_FAILURE and TOS_SUCCESS on *get with their
> default return value set to LED_OFF.
> 
> Also the {lcd, video}_proc* functions were adapted to reflect these
> changes to their parent HCI functions.
> 
> Signed-off-by: Azael Avalos 
> ---
>  drivers/platform/x86/toshiba_acpi.c | 432 
> ++--
>  1 file changed, 217 insertions(+), 215 deletions(-)
> 
> diff --git a/drivers/platform/x86/toshiba_acpi.c 
> b/drivers/platform/x86/toshiba_acpi.c
> index e24f0f5..0034341 100644
> --- a/drivers/platform/x86/toshiba_acpi.c
> +++ b/drivers/platform/x86/toshiba_acpi.c
> @@ -93,6 +93,7 @@ MODULE_LICENSE("GPL");
>  
>  /* Return codes */
>  #define TOS_SUCCESS  0x
> +#define TOS_SUCCESS2 0x0001

UGH, thanks Toshiba :-(

>  #define TOS_OPEN_CLOSE_OK0x0044
>  #define TOS_FAILURE  0x1000
>  #define TOS_NOT_SUPPORTED0x8000
> @@ -467,7 +468,8 @@ static void toshiba_illumination_set(struct led_classdev 
> *cdev,
>  {
>   struct toshiba_acpi_dev *dev = container_of(cdev,
>   struct toshiba_acpi_dev, led_dev);
> - u32 state, result;
> + u32 result;
> + u32 state;
>  

I should add that this is a apparently a preference of mine, and other
maintainers do not enforce this, some actively discourage it. I apologize for
this inconsistency among the maintainers, it came to my attention that the very
person I was modeling this preference after in fact feels the opposite. Sigh.
For the time being, we stick with the preference I've stated, for consistency
within this file and through drivers/platform/x86 if nothing else.

>   /* First request : initialize communication. */
>   if (!sci_open(dev))
> @@ -479,8 +481,6 @@ static void toshiba_illumination_set(struct led_classdev 
> *cdev,
>   sci_close(dev);
>   if (result == TOS_FAILURE)
>   pr_err("ACPI call for illumination failed\n");
> - else if (result == TOS_NOT_SUPPORTED)
> - return;
>  }
>  
>  static enum led_brightness toshiba_illumination_get(struct led_classdev 
> *cdev)
> @@ -496,14 +496,12 @@ static enum led_brightness 
> toshiba_illumination_get(struct led_classdev *cdev)
>   /* Check the illumination */
>   result = sci_read(dev, SCI_ILLUMINATION, &state);
>   sci_close(dev);
> - if (result == TOS_FAILURE || result == TOS_INPUT_DATA_ERROR) {
> + if (result == TOS_FAILURE)
>   pr_err("ACPI call for illumination failed\n");
> - return LED_OFF;
> - } else if (result == TOS_NOT_SUPPORTED) {
> - return LED_OFF;
> - }
> + else if (result == TOS_SUCCESS)
> + return state ? LED_FULL : LED_OFF;
>  

I believe it is more typical, and therefor more natural to my eye, to test for
failure.

else if (result != TOS_SUCCESS)
return LED_OFF;

return state ? LED_FULL : LED_OFF;
}

Applies throughout. However, there is of course no functional difference and
others may argue differently. I'm mentioning it because there is an issue that
requires a respin below. I'll leave it to you which way you want to handle this
in this driver.

...

>  
>  static int video_proc_show(struct seq_file *m, void *v)
>  {
>   struct toshiba_acpi_dev *dev = m->private;
>   u32 value;
> - int ret;
>  
> - ret = get_video_status(dev, &value);
> - if (!ret) {
> - int is_lcd = (value & HCI_VIDEO_OUT_LCD) ? 1 : 0;
> - int is_crt = (value & HCI_VIDEO_OUT_CRT) ? 1 : 0;
> - int is_tv = (value & HCI_VIDEO_OUT_TV) ? 1 : 0;
> + if (get_video_status(dev, &value))
> + return -EIO;
>  
> - seq_printf(m, "lcd_out: %d\n", is_lcd);
> - seq_printf(m, "crt_out: %d\n", is_crt);
> - seq_printf(m, "tv_out:  %d\n", is_tv);
> - }
> + int is_lcd = (value & HCI_VIDEO_OUT_LCD) ? 1 : 0;

In this case, these need to be defined above. Your build test should have caught
this:

drivers/platform/x86/toshiba_acpi.c:1292:2: warning: ISO C90 forbids mixed 
declarations and code [-Wdeclaration-aft

[PATCH RFC 0/3] x86: Intel Processor Trace Logger

[Takao Indoh]

Hi all,

These patch series provide logging feature for Intel Processor Trace
(Intel PT).

Intel PT is a new feature of Intel CPU "Broadwell", it captures
information about program execution flow. Here is a article about Intel
PT.
https://software.intel.com/en-us/blogs/2013/09/18/processor-tracing

Once Intel PT is enabled, the events which change program flow, like
branch instructions, exceptions, interruptions, traps and so on are
logged in the memory. This is very useful for debugging because we can
know the detailed behavior of software.

This patch creates log buffer for Intel PT and enable logging at boot
time. When kernel panic occurs, we can get this log buffer from
crashdump file by kdump, and reconstruct the flow that led to the panic.

Takao Indoh (3):
  x86: Add Intel PT common files
  x86: Add Intel PT logger
  x86: Stop Intel PT and save its registers when panic occurs

 arch/x86/Kconfig  |   16 ++
 arch/x86/include/asm/intel_pt.h   |   84 +
 arch/x86/kernel/cpu/Makefile  |3 +
 arch/x86/kernel/cpu/intel_pt.h|  131 -
 arch/x86/kernel/cpu/intel_pt_cap.c|   69 +++
 arch/x86/kernel/cpu/intel_pt_log.c|  288 +
 arch/x86/kernel/cpu/intel_pt_perf.h   |   78 
 arch/x86/kernel/cpu/perf_event_intel_pt.c |   54 +-
 arch/x86/kernel/crash.c   |9 +
 9 files changed, 556 insertions(+), 176 deletions(-)
 create mode 100644 arch/x86/include/asm/intel_pt.h
 delete mode 100644 arch/x86/kernel/cpu/intel_pt.h
 create mode 100644 arch/x86/kernel/cpu/intel_pt_cap.c
 create mode 100644 arch/x86/kernel/cpu/intel_pt_log.c
 create mode 100644 arch/x86/kernel/cpu/intel_pt_perf.h


--
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] [trivial] i2c: Fix typo in i2c-bfin-twi.c

[Zhang, Sonic]

Acked-by: Sonic Zhang 

>-Original Message-
>From: Masanari Iida [mailto:standby2...@gmail.com]
>Sent: Tuesday, July 28, 2015 7:11 PM
>To: triv...@kernel.org; Zhang, Sonic; w...@the-dreams.de; 
>linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
>bryan...@analog.com
>Cc: Masanari Iida
>Subject: [PATCH] [trivial] i2c: Fix typo in i2c-bfin-twi.c
>
>This patch fix some typos found in a printk message and MODULE_DESCRIPTION.
>
>Signed-off-by: Masanari Iida 
>---
> drivers/i2c/busses/i2c-bfin-twi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/i2c/busses/i2c-bfin-twi.c 
>b/drivers/i2c/busses/i2c-bfin-twi.c
>index af162b4..025686d 100644
>--- a/drivers/i2c/busses/i2c-bfin-twi.c
>+++ b/drivers/i2c/busses/i2c-bfin-twi.c
>@@ -692,7 +692,7 @@ static int i2c_bfin_twi_probe(struct platform_device *pdev)
>
>   platform_set_drvdata(pdev, iface);
>
>-  dev_info(&pdev->dev, "Blackfin BF5xx on-chip I2C TWI Contoller, "
>+  dev_info(&pdev->dev, "Blackfin BF5xx on-chip I2C TWI Controller, "
>   "regs_base@%p\n", iface->regs_base);
>
>   return 0;
>@@ -735,6 +735,6 @@ subsys_initcall(i2c_bfin_twi_init);
> module_exit(i2c_bfin_twi_exit);
>
> MODULE_AUTHOR("Bryan Wu, Sonic Zhang"); -MODULE_DESCRIPTION("Blackfin BF5xx 
> on-chip I2C TWI Contoller
>Driver");
>+MODULE_DESCRIPTION("Blackfin BF5xx on-chip I2C TWI Controller Driver");
> MODULE_LICENSE("GPL");
> MODULE_ALIAS("platform:i2c-bfin-twi");
>--
>2.5.0

--
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] of/irq: introduce of_has_named_irqs helper

[Vignesh R]

On 07/28/2015 11:37 PM, Dmitry Torokhov wrote:
> On Tue, Jul 28, 2015 at 11:16:44PM +0530, R, Vignesh wrote:
>> Hi,
>>
>> On 7/28/2015 10:53 PM, Dmitry Torokhov wrote:
>>> On Tue, Jul 28, 2015 at 06:53:52PM +0530, Vignesh R wrote:
 Hi Dmitry,

 On 07/25/2015 01:46 AM, Dmitry Torokhov wrote:
> On Fri, Jul 24, 2015 at 12:26:19PM -0700, Dmitry Torokhov wrote:
>> On Fri, Jul 24, 2015 at 02:14:57PM -0500, Rob Herring wrote:
>>> On Fri, Jul 24, 2015 at 1:26 PM, Dmitry Torokhov
>>>  wrote:
 Sometimes drivers might wish to transition from index-based to named
 interrupt descriptions. To aid in decision-making when parsing device
 tree data let's provide a helper that will indicate the scheme that is
 being used.
>>>
>>> Generally, IRQs are retrieved by platform_get_irq or
>>> platform_get_irq_byname. Drivers should not call the of_irq_*
>>> functions directly in most cases.
>>
>> That would be true for platform drivers, but not all devices are
>> platform devices.
>>
>>>

 Signed-off-by: Dmitry Torokhov 
 ---

 The intent is to it like this:

 if (of_has_named_irqs(np) {
 /* Wake IRQ is optional */
 dev->wakeirq = of_irq_get_byname(np, "wakeup");
 if (dev->wakeirq < 0 && dev->wakeirq != -ENODATA)
 return dev->wakeirq;
 }
>>>
>>> of_irq_get_byname will already return an error if the property is not
>>> present. Use that.
>>
>> I do not like that it returns -EINVAL when property is missing, can we
>> change it to return -ENODATA (so it is the same as when the property is
>> defined but such name is missing)?
>
> So here is what I had in mind.. It is based on recent patch by Vignesh
> for pixcir touchscreen, but I think it should be made available to all
> I2C devices. Completely untested at the moment.
>

 Thanks for the patch! I tested this on am437x-gp-evm and the
 suspend/resume worked fine (below patch + $subject patch). I was able to
 wake the system from low power state using touchscreen. Also verified
 module insertion and removal. One comment though, please see below.

> ---
>  drivers/i2c/i2c-core.c |   43 +--
>  1 file changed, 37 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index e6d4935..3971461 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -47,6 +47,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -631,6 +632,7 @@ static int i2c_device_probe(struct device *dev)
>  {
>   struct i2c_client   *client = i2c_verify_client(dev);
>   struct i2c_driver   *driver;
> + int wakeirq = 0;
>   int status;
>  
>   if (!client)
> @@ -639,11 +641,13 @@ static int i2c_device_probe(struct device *dev)
>   if (!client->irq) {
>   int irq = -ENOENT;
>  
> - if (dev->of_node)
> - irq = of_irq_get(dev->of_node, 0);
> - else if (ACPI_COMPANION(dev))
> + if (dev->of_node) {
> + irq = of_has_named_irqs(dev->of_node) ?
> + of_irq_get_byname(dev->of_node, "irq") :
> + of_irq_get(dev->of_node, 0);
> + } else if (ACPI_COMPANION(dev)) {
>   irq = acpi_dev_gpio_irq_get(ACPI_COMPANION(dev), 0);
> -
> + }
>   if (irq == -EPROBE_DEFER)
>   return irq;
>   if (irq < 0)
> @@ -652,6 +656,15 @@ static int i2c_device_probe(struct device *dev)
>   client->irq = irq;
>   }
>  
> + if (dev->of_node && of_has_named_irqs(dev->of_node)) {
> + wakeirq = of_irq_get_byname(dev->of_node, "wakeup");
> + if (wakeirq < 0) {
> + if (wakeirq != -ENODATA)
> + return wakeirq;
> + wakeirq = 0;
> + }
> + }
> +
>   driver = to_i2c_driver(dev->driver);
>   if (!driver->probe || !driver->id_table)
>   return -ENODEV;diff --git 
> a/drivers/input/touchscreen/pixcir_i2c_ts.c 
> b/drivers/input/touchscreen/pixcir_i2c_ts.c
>> index 8f3e243a62bf..6bd1d1ca9883 100644
>> --- a/drivers/input/touchscreen/pixcir_i2c_ts.c
>> +++ b/drivers/input/touchscreen/pixcir_i2c_ts.c
>> @@ -365,7 +365,6 @@ static int __maybe_unused
>> pixcir_i2c_ts_suspend(struct device *dev)
>> }
>> }
>>
>> -   enable_irq_wake(client->irq);
>> } else if (input->users) {
>> ret = pixcir_stop(ts);
>>

Re: [Xen-devel] [PATCH v4 0/3] x86: modify_ldt improvement, test, and config option

[Andy Lutomirski]

On Tue, Jul 28, 2015 at 8:01 PM, Boris Ostrovsky
 wrote:
> On 07/28/2015 08:47 PM, Andrew Cooper wrote:
>>
>> On 29/07/2015 01:21, Andy Lutomirski wrote:
>>>
>>> On Tue, Jul 28, 2015 at 10:10 AM, Boris Ostrovsky
>>>  wrote:

 On 07/28/2015 01:07 PM, Andy Lutomirski wrote:
>
> On Tue, Jul 28, 2015 at 9:30 AM, Andrew Cooper
>  wrote:
>>
>> I suspect that the set_ldt(NULL, 0) call hasn't reached Xen before
>> xen_free_ldt() is attempting to nab back the pages which Xen still has
>> mapped as an LDT.
>>
> I just instrumented it with yet more LSL instructions.  I'm pretty
> sure that set_ldt really is clearing at least LDT entry zero.
> Nonetheless the free_ldt call still oopses.
>
 Yes, I added some instrumentation to the hypervisor and we definitely
 set
 LDT to NULL before failing.

 -boris
>>>
>>> Looking at map_ldt_shadow_page: what keeps shadow_ldt_mapcnt from
>>> getting incremented once on each CPU at the same time if both CPUs
>>> fault in the same shadow LDT page at the same time?
>>
>> Nothing, but that is fine.  If a page is in use in two vcpus LDTs, it is
>> expected to have a type refcount of 2.
>>
>>> Similarly, what
>>> keeps both CPUs from calling get_page_type at the same time and
>>> therefore losing track of the page type reference count?
>>
>> a cmpxchg() loop in the depths of __get_page_type().
>>
>>> I don't see why vmalloc or vm_unmap_aliases would have anything to do
>>> with this, though.
>
>
> So just for kicks I made lazy_max_pages() return 0 to free vmaps immediately
> and the problem went away.
>
> I also saw this warning, BTW:
>
> [  178.686542] [ cut here ]
> [  178.686554] WARNING: CPU: 0 PID: 16440 at
> ./arch/x86/include/asm/mmu_context.h:96 load_mm_ldt+0x70/0x76()
> [  178.686558] DEBUG_LOCKS_WARN_ON(!irqs_disabled())

Whoops!  That should be checking preemptible(), not irqs_disabled().

--Andy
--
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 v3 01/11] stm class: Introduce an abstraction for System Trace Module devices

[Chunyan Zhang]

On Mon, Jul 6, 2015 at 6:08 PM, Alexander Shishkin
 wrote:
> A System Trace Module (STM) is a device exporting data in System Trace
> Protocol (STP) format as defined by MIPI STP standards. Examples of such
> devices are Intel Trace Hub and Coresight STM.
>
> This abstraction provides a unified interface for software trace sources
> to send their data over an STM device to a debug host. In order to do
> that, such a trace source needs to be assigned a pair of master/channel
> identifiers that all the data from this source will be tagged with. The
> STP decoder on the debug host side will use these master/channel tags to
> distinguish different trace streams from one another inside one STP
> stream.
>
> This abstraction provides a configfs-based policy management mechanism
> for dynamic allocation of these master/channel pairs based on trace
> source-supplied string identifier. It has the flexibility of being
> defined at runtime and at the same time (provided that the policy
> definition is aligned with the decoding end) consistency.
>
> For userspace trace sources, this abstraction provides write()-based and
> mmap()-based (if the underlying stm device allows this) output mechanism.
>
> For kernel-side trace sources, we provide "stm_source" device class that
> can be connected to an stm device at run time.
>
> Cc: linux-...@vger.kernel.org
> Cc: Mathieu Poirier 
> Signed-off-by: Alexander Shishkin 
> ---
>  Documentation/ABI/testing/configfs-stp-policy|   48 +
>  Documentation/ABI/testing/sysfs-class-stm|   14 +
>  Documentation/ABI/testing/sysfs-class-stm_source |   11 +
>  Documentation/ioctl/ioctl-number.txt |3 +
>  Documentation/trace/stm.txt  |   80 ++
>  drivers/Kconfig  |2 +
>  drivers/Makefile |1 +
>  drivers/hwtracing/stm/Kconfig|8 +
>  drivers/hwtracing/stm/Makefile   |3 +
>  drivers/hwtracing/stm/core.c | 1029 
> ++
>  drivers/hwtracing/stm/policy.c   |  529 +++
>  drivers/hwtracing/stm/stm.h  |   87 ++
>  include/linux/stm.h  |  126 +++
>  include/uapi/linux/stm.h |   50 ++
>  14 files changed, 1991 insertions(+)
>  create mode 100644 Documentation/ABI/testing/configfs-stp-policy
>  create mode 100644 Documentation/ABI/testing/sysfs-class-stm
>  create mode 100644 Documentation/ABI/testing/sysfs-class-stm_source
>  create mode 100644 Documentation/trace/stm.txt
>  create mode 100644 drivers/hwtracing/stm/Kconfig
>  create mode 100644 drivers/hwtracing/stm/Makefile
>  create mode 100644 drivers/hwtracing/stm/core.c
>  create mode 100644 drivers/hwtracing/stm/policy.c
>  create mode 100644 drivers/hwtracing/stm/stm.h
>  create mode 100644 include/linux/stm.h
>  create mode 100644 include/uapi/linux/stm.h
>
> diff --git a/Documentation/ABI/testing/configfs-stp-policy 
> b/Documentation/ABI/testing/configfs-stp-policy
> new file mode 100644
> index 00..421ce6825c
> --- /dev/null
> +++ b/Documentation/ABI/testing/configfs-stp-policy
> @@ -0,0 +1,48 @@
> +What:  /config/stp-policy
> +Date:  June 2015
> +KernelVersion: 4.3
> +Description:
> +   This group contains policies mandating Master/Channel 
> allocation
> +   for software sources wishing to send trace data over an STM
> +   device.
> +
> +What:  /config/stp-policy/.
> +Date:  June 2015
> +KernelVersion: 4.3
> +Description:
> +   This group is the root of a policy; its name is a 
> concatenation
> +   of an stm device name to which this policy applies and an
> +   arbitrary string. If  part doesn't match an existing
> +   stm device, mkdir will fail with ENODEV; if that device 
> already
> +   has a policy assigned to it, mkdir will fail with EBUSY.
> +
> +What:  /config/stp-policy/./device
> +Date:  June 2015
> +KernelVersion: 4.3
> +Description:
> +   STM device to which this policy applies, read only. Same as 
> the
> +component of its parent directory.
> +
> +What:  /config/stp-policy/./
> +Date:  June 2015
> +KernelVersion: 4.3
> +Description:
> +   Policy node is a string identifier that software clients will
> +   use to request a master/channel to be allocated and assigned 
> to
> +   them.
> +
> +What:  /config/stp-policy/.//masters
> +Date:  June 2015
> +KernelVersion: 4.3
> +Description:
> +   Range of masters from which to allocate for users of this 
> node.
> +   Write two numbers: the first master and the last master 
> number.
> +
> +What:  /config/stp-policy/.//channels
> +Date:  June 2015
> +KernelVersion: 4.3
> +Description:
> +   Range 

Re: [PATCH 1/2] mtd: spi-nor: rework spi nor read and write.

[Michal Suchanek]

On 28 July 2015 at 20:15, Marek Vasut  wrote:
> On Tuesday, July 28, 2015 at 11:23:02 AM, Michal Suchanek wrote:
>> The spi_nor read and write functions pass thru the mtd retlen to the
>> chip-specific read and write function. This makes it difficult to check
>> for errors in read and write functions and these errors are not checked.
>> This leads to silent data corruption.
>>
>> This patch styles the chip-specific read and write function as unix
>> read(2) and write(2) and updates the retlen in the spi-nor generic driver.
>>
>> This also makes it possible to check for write errors.
>> When pl330 fails to transfer the flash data over SPI I get I/O error
>> instead of 4M of zeroes.
>>
>> I do not have sst and fsl hardware to test with.
>>
>> Signed-off-by: Michal Suchanek 
>> ---
>>  drivers/mtd/devices/m25p80.c  | 33 ++-
>>  drivers/mtd/spi-nor/fsl-quadspi.c | 29 ++--
>>  drivers/mtd/spi-nor/spi-nor.c | 57
>> --- include/linux/mtd/spi-nor.h
>> |  8 +++---
>>  4 files changed, 81 insertions(+), 46 deletions(-)
>>
>> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
>> index d313f948b..d8f064b 100644
>> --- a/drivers/mtd/devices/m25p80.c
>> +++ b/drivers/mtd/devices/m25p80.c
>> @@ -75,14 +75,15 @@ static int m25p80_write_reg(struct spi_nor *nor, u8
>> opcode, u8 *buf, int len, return spi_write(spi, flash->command, len + 1);
>>  }
>>
>> -static void m25p80_write(struct spi_nor *nor, loff_t to, size_t len,
>> - size_t *retlen, const u_char *buf)
>> +static ssize_t m25p80_write(struct spi_nor *nor, loff_t to, size_t len,
>> + const u_char *buf)
>>  {
>>   struct m25p *flash = nor->priv;
>>   struct spi_device *spi = flash->spi;
>>   struct spi_transfer t[2] = {};
>>   struct spi_message m;
>>   int cmd_sz = m25p_cmdsz(nor);
>> + ssize_t ret;
>>
>>   spi_message_init(&m);
>>
>> @@ -100,9 +101,14 @@ static void m25p80_write(struct spi_nor *nor, loff_t
>> to, size_t len, t[1].len = len;
>>   spi_message_add_tail(&t[1], &m);
>>
>> - spi_sync(spi, &m);
>> + ret = spi_sync(spi, &m);
>> + if (ret)
>> + return ret;
>>
>> - *retlen += m.actual_length - cmd_sz;
>> + ret = m.actual_length - cmd_sz;
>> + if (ret < 0)
>> + return -EIO;
>> + return ret;
>
> I'd prefer to just add the return value and keep the retlen to keep error
> codes and transfer length separate.

I prefer to not pass around retlen because passing it around

 - causes code duplication
 - makes the code harder to understand

>
> btw. you change the transfer length from unsigned to signed type -- long
> transfer might get interpreted as an error.

Note that ssize_t is supposed to be enough for write(2) so when it
does not suffice you have a real system-wide problem.

That aside NOR flash sizes tend to be in the order of megabytes so
this concern is very theoretical.

Thanks

Michal
--
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/6] pci:host: Add Altera PCIe host controller driver

[Rob Herring]

On Tue, Jul 28, 2015 at 5:45 AM, Ley Foon Tan  wrote:
> This patch adds the Altera PCIe host controller driver.
>
> Signed-off-by: Ley Foon Tan 
> ---
>  drivers/pci/host/Kconfig   |   9 +
>  drivers/pci/host/Makefile  |   1 +
>  drivers/pci/host/pcie-altera.c | 576 
> +
>  3 files changed, 586 insertions(+)
>  create mode 100644 drivers/pci/host/pcie-altera.c
>
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index 675c2d1..af19039 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -145,4 +145,13 @@ config PCIE_IPROC_BCMA
>   Say Y here if you want to use the Broadcom iProc PCIe controller
>   through the BCMA bus interface
>
> +config PCIE_ALTERA
> +   bool "Altera PCIe controller"
> +   depends on ARCH_SOCFPGA
> +   depends on OF
> +   select PCI_MSI_IRQ_DOMAIN if PCI_MSI
> +   help
> + Say Y here if you want to enable PCIe controller support for Altera
> + SoCFPGA family of SoCs.
> +
>  endmenu
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index 140d66f..6954f76 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -17,3 +17,4 @@ obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
>  obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
>  obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
>  obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
> +obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
> diff --git a/drivers/pci/host/pcie-altera.c b/drivers/pci/host/pcie-altera.c
> new file mode 100644
> index 000..afa64e9
> --- /dev/null
> +++ b/drivers/pci/host/pcie-altera.c
> @@ -0,0 +1,576 @@
> +/*
> + * Copyright Altera Corporation (C) 2013-2015. All rights reserved
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope 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.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define A2P_ADDR_MAP_LO0   0x1000
> +#define A2P_ADDR_MAP_HI0   0x1004
> +#define RP_TX_REG0 0x2000
> +#define RP_TX_REG1 0x2004
> +#define RP_TX_CNTRL0x2008
> +#define RP_TX_EOP  0x2
> +#define RP_TX_SOP  0x1
> +#define RP_RXCPL_STATUS0x2010
> +#define RP_RXCPL_EOP   0x2
> +#define RP_RXCPL_SOP   0x1
> +#define RP_RXCPL_REG0  0x2014
> +#define RP_RXCPL_REG1  0x2018
> +#define P2A_INT_STATUS 0x3060
> +#define P2A_INT_STS_ALL0xF
> +#define P2A_INT_ENABLE 0x3070
> +#define P2A_INT_ENA_ALL0xF
> +#define RP_LTSSM   0x3C64
> +#define LTSSM_L0   0xF
> +
> +/* TLP configuration type 0 and 1 */
> +#define TLP_FMTTYPE_CFGRD0 0x04/* Configuration Read Type 0 
> */
> +#define TLP_FMTTYPE_CFGWR0 0x44/* Configuration Write Type 0 
> */
> +#define TLP_FMTTYPE_CFGRD1 0x05/* Configuration Read Type 1 
> */
> +#define TLP_FMTTYPE_CFGWR1 0x45/* Configuration Write Type 1 
> */
> +#define TLP_PAYLOAD_SIZE   0x01
> +#define TLP_READ_TAG   0x1D
> +#define TLP_WRITE_TAG  0x10
> +#define TLP_CFG_DW0(fmttype)   (((fmttype) << 24) | TLP_PAYLOAD_SIZE)
> +#define TLP_CFG_DW1(reqid, tag)(((reqid) << 16) | (tag << 8) 
> | 0xF)
> +#define TLP_CFG_DW2(bus, devfn, offset)\
> +   (((bus) << 24) | ((devfn) << 16) | (offset))
> +#define TLP_REQ_ID(bus, devfn) (((bus) << 8) | (devfn))
> +#define TLP_COMPL_STATUS(hdr)  (((hdr) & 0xE0) >> 13)
> +#define TLP_HDR_SIZE   3
> +#define TLP_LOOP   10
> +
> +#define INTX_NUM   4
> +
> +/* Address translation table entry size */
> +#define ATT_ENTRY_SIZE 8
> +
> +#define DWORD_MASK 3
> +
> +struct altera_pcie {
> +   struct platform_device  *pdev;
> +   struct resource *txs;
> +   void __iomem*cra_base;
> +   int hwirq;
> +   u8  root_bus_nr;
> +   struct irq_domain   *irq_domain;
> +   struct resource bus_range;
> +   struct list_head 

Re: [PATCH 4/6] pci: altera: Add Altera PCIe MSI driver

[Dinh Nguyen]

On Tue, Jul 28, 2015 at 10:07 PM, Ley Foon Tan  wrote:
> On Wed, Jul 29, 2015 at 1:00 AM, Dinh Nguyen  wrote:
>> On Tue, Jul 28, 2015 at 5:45 AM, Ley Foon Tan  wrote:
>>> This patch adds Altera PCIe MSI driver. This soft IP supports configurable
>>> number of vectors, which is a dts parameter.
>>> @@ -154,4 +154,11 @@ config PCIE_ALTERA
>>>   Say Y here if you want to enable PCIe controller support for 
>>> Altera
>>>   SoCFPGA family of SoCs.
>>>
>>> +config PCIE_ALTERA_MSI
>>> +   bool "Altera PCIe MSI feature"
>>> +   depends on PCI_MSI && PCIE_ALTERA
>>> +   help
>>> + Say Y here if you want PCIe MSI support for the Altera SocFPGA 
>>> SoC.
>>> + This MSI driver supports Altera MSI to GIC controller IP.
>>> +
>>
>> Couldn't this driver get combined with the pcie-altera driver?
>
> This MSI IP is a soft IP and it is optional to PCI system. So, we have
> individual driver for it and user can disable it.
>

So why can't you use CONFIG_PCI_MSI in the pcie-altera driver? I see
that most, if not
all of the other drivers are combined with MSI.

Dinh
--
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: shared usb dt document is incorrect

[Rob Herring]

On Tue, Jul 28, 2015 at 10:12 PM, Peter Chen  wrote:
>
>> > I was just doing some testing with USB on a Qualcomm SoC.
>> >
>> > I followed the instructions in the binding document:
>> > Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
>> >
>> > which has a compatible for "qcom,ci-hdrc", and is, in general, for
>> > chipidea-based USB controllers.
>> >
>> > It says in the document that the property usb-phy is deprecated, and
>> > to use phys and phy-names instead.  However, the Qualcomm driver for
>> > this still uses usb-phy.  That driver is in:
>> > drivers/usb/chipidea/ci_hdrc_msm.c
>>
>> Deprecated means it still exists in the wild and should be maintained, but 
>> don't
>> use it for new dts files.
>>
>
> But how the new SoC (for new dts) which still uses current USB PHY driver?

That's fine to use, but I would encourage people not to.

> Maybe we should not add additional description for this property,
> it depends on which PHY driver (Generic PHY vs USB PHY)  this controller
> will use, if it uses a new PHY driver, it must use generic PHY framework,  
> and will
> use 'phy' and 'phy-names' corresponding.

We're thinking about this the wrong way around. The driver should not
determine the binding used. The binding should be independent of the
driver used.

Either we should make the generic phy subsystem have feature parity
with usb-phy, or make the usb-phy drivers use the same generic phy
binding. Long term, I think we want the former and need a way to
subclass the generic phy. Other phys have similar needs for additional
protocol specific functions (e.g. configure the # of lanes for PCIe).
The generic phy subsystem needs some love in my brief experience with
it. For the latter case, this would make switching which phy driver is
used transparent to DT.

Rob
--
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] input: twl4030-vibra: Fix ERROR: Bad of_node_put() warning

[Rob Herring]

On Tue, Jul 28, 2015 at 3:23 PM, Belisko Marek  wrote:
> Hi Dmitry,
>
> On Thu, Jul 23, 2015 at 10:53 PM, Dmitry Torokhov
>  wrote:
>> On Thu, Jul 23, 2015 at 10:38:34PM +0200, Marek Belisko wrote:
>>> Fix following:
>>> [8.862274] ERROR: Bad of_node_put() on /ocp/i2c@4807/twl@48/audio
>>> [8.869293] CPU: 0 PID: 1003 Comm: modprobe Not tainted 4.2.0-rc2-letux+ 
>>> #1175
>>> [8.876922] Hardware name: Generic OMAP36xx (Flattened Device Tree)
>>> [8.883514] [] (unwind_backtrace) from [] 
>>> (show_stack+0x10/0x14)
>>> [8.891693] [] (show_stack) from [] 
>>> (dump_stack+0x78/0x94)
>>> [8.899322] [] (dump_stack) from [] 
>>> (kobject_release+0x68/0x7c)
>>> [8.907409] [] (kobject_release) from [] 
>>> (twl4030_vibra_probe+0x74/0x188 [twl4030_vibra])
>>> [8.917877] [] (twl4030_vibra_probe [twl4030_vibra]) from 
>>> [] (platform_drv_probe+0x48/0x90)
>>> [8.928497] [] (platform_drv_probe) from [] 
>>> (really_probe+0xd4/0x238)
>>> [8.937103] [] (really_probe) from [] 
>>> (driver_probe_device+0x30/0x48)
>>> [8.945678] [] (driver_probe_device) from [] 
>>> (__driver_attach+0x68/0x8c)
>>> [8.954589] [] (__driver_attach) from [] 
>>> (bus_for_each_dev+0x50/0x84)
>>> [8.963226] [] (bus_for_each_dev) from [] 
>>> (bus_add_driver+0xcc/0x1e4)
>>> [8.971832] [] (bus_add_driver) from [] 
>>> (driver_register+0x9c/0xe0)
>>> [8.980255] [] (driver_register) from [] 
>>> (do_one_initcall+0x100/0x1b8)
>>> [8.988983] [] (do_one_initcall) from [] 
>>> (do_init_module+0x58/0x1c0)
>>> [8.997497] [] (do_init_module) from [] 
>>> (SyS_init_module+0x54/0x64)
>>> [9.005950] [] (SyS_init_module) from [] 
>>> (ret_fast_syscall+0x0/0x54)
>>> [9.015838] input: twl4030:vibrator as 
>>> /devices/platform/6800.ocp/4807.i2c/i2c-0/0-0048/4807.i2c:twl@48:audio/input/input2
>>>
>>> node passed to of_find_node_by_name is put inside that function and new node
>>> is returned if found. Free returned node not already freed node.
>>
>> Hmm, if of_find_node_by_name() "puts" passed in node should we not "get"
>> it before calling of_find_node_by_name()? The node pointer in question
>> is simply copied from parent device.
> I'm not sure. what I can say is that I cannot see such error in 4.1
> but only in 4.2-rcx.
> Adding Grant and Rob to CC, maybe they know what should be done and
> why I see such error in 4.2-rcx.

The problem was that node passed into of_find_node_by_name is the the
starting point to search, but you should be doing the put on the
returned node. So the patch below is correct.

As far as why in 4.2, it seems you have OF_DYNAMIC enabled in your
config either because you have DT unit test or overlays enabled.
Overlays are now user enable-able in 4.2.

Rob

>>
>> Thanks.
>>
>>>
>>> Signed-off-by: Marek Belisko 
>>> ---
>>>  drivers/input/misc/twl4030-vibra.c | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/input/misc/twl4030-vibra.c 
>>> b/drivers/input/misc/twl4030-vibra.c
>>> index fc17b95..10c4e3d 100644
>>> --- a/drivers/input/misc/twl4030-vibra.c
>>> +++ b/drivers/input/misc/twl4030-vibra.c
>>> @@ -183,7 +183,8 @@ static bool twl4030_vibra_check_coexist(struct 
>>> twl4030_vibra_data *pdata,
>>>   if (pdata && pdata->coexist)
>>>   return true;
>>>
>>> - if (of_find_node_by_name(node, "codec")) {
>>> + node = of_find_node_by_name(node, "codec");
>>> + if (node) {
>>>   of_node_put(node);
>>>   return true;
>>>   }
>>> --
>>> 1.9.1
>>>
>>
>> --
>> Dmitry
>
> BR,
>
> marek
>
> --
> as simple and primitive as possible
> -
> Marek Belisko - OPEN-NANDRA
> Freelance Developer
>
> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> Tel: +421 915 052 184
> skype: marekwhite
> twitter: #opennandra
> web: http://open-nandra.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: Bug: shared usb dt document is incorrect

[Peter Chen]

 
> > I was just doing some testing with USB on a Qualcomm SoC.
> >
> > I followed the instructions in the binding document:
> > Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
> >
> > which has a compatible for "qcom,ci-hdrc", and is, in general, for
> > chipidea-based USB controllers.
> >
> > It says in the document that the property usb-phy is deprecated, and
> > to use phys and phy-names instead.  However, the Qualcomm driver for
> > this still uses usb-phy.  That driver is in:
> > drivers/usb/chipidea/ci_hdrc_msm.c
> 
> Deprecated means it still exists in the wild and should be maintained, but 
> don't
> use it for new dts files.
> 

But how the new SoC (for new dts) which still uses current USB PHY driver?

Maybe we should not add additional description for this property,
it depends on which PHY driver (Generic PHY vs USB PHY)  this controller
will use, if it uses a new PHY driver, it must use generic PHY framework,  and 
will
use 'phy' and 'phy-names' corresponding.

Peter

N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH] arch/*/io.h: Add ioremap_uc() to all architectures

[Stephen Rothwell]

Hi Luis,

On Tue, 28 Jul 2015 11:22:07 -0700 "Luis R. Rodriguez" 
 wrote:
>
> From: "Luis R. Rodriguez" 
> 
> This adds ioremap_uc() only for architectures that do not
> include asm-generic.h/io.h as that already provides a default
> definition for them for both cases where you have CONFIG_MMU
> and you do not, and because of this, the number of architectures
> this patch address is less than the architectures that the
> ioremap_wt() patch addressed, "arch/*/io.h: Add ioremap_wt() to all
> architectures").
> 
> In order to reduce the number of architectures we have to
> modify when adding new architecture IO APIs we'll have to review
> the architectures in this patch, see why they can't add
> asm-generic.h/io.h or issues that would be created by doing
> so and then spread a consistent inclusion of this header
> towards the end of their own header. For instance arch/metag
> includes the asm-generic/io.h *before* the ioremap*()
> definitions, this should be the other way around but only
> once we have guard wrappers for the non-MMU case also for
> asm-generic/io.h.
> 
> Cc: Arnd Bergmann 
> Reported-by: Stephen Rothwell 
> Signed-off-by: Luis R. Rodriguez 
> ---
>  arch/avr32/include/asm/io.h   | 1 +
>  arch/frv/include/asm/io.h | 1 +
>  arch/m32r/include/asm/io.h| 1 +
>  arch/m68k/include/asm/io_mm.h | 1 +
>  arch/mn10300/include/asm/io.h | 1 +
>  arch/powerpc/include/asm/io.h | 1 +
>  arch/sh/include/asm/io.h  | 1 +
>  arch/tile/include/asm/io.h| 1 +
>  8 files changed, 8 insertions(+)

I have added this to linux-next today instead of reverting the other 2
patches.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
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/6] pci: altera: Add Altera PCIe MSI driver

[Ley Foon Tan]

On Wed, Jul 29, 2015 at 1:00 AM, Dinh Nguyen  wrote:
> On Tue, Jul 28, 2015 at 5:45 AM, Ley Foon Tan  wrote:
>> This patch adds Altera PCIe MSI driver. This soft IP supports configurable
>> number of vectors, which is a dts parameter.
>> @@ -154,4 +154,11 @@ config PCIE_ALTERA
>>   Say Y here if you want to enable PCIe controller support for Altera
>>   SoCFPGA family of SoCs.
>>
>> +config PCIE_ALTERA_MSI
>> +   bool "Altera PCIe MSI feature"
>> +   depends on PCI_MSI && PCIE_ALTERA
>> +   help
>> + Say Y here if you want PCIe MSI support for the Altera SocFPGA SoC.
>> + This MSI driver supports Altera MSI to GIC controller IP.
>> +
>
> Couldn't this driver get combined with the pcie-altera driver?

This MSI IP is a soft IP and it is optional to PCI system. So, we have
individual driver for it and user can disable it.

Regards
Ley Foon
--
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/6] pci:host: Add Altera PCIe host controller driver

[Ley Foon Tan]

On Wed, Jul 29, 2015 at 12:45 AM, Dinh Nguyen  wrote:
> On Tue, Jul 28, 2015 at 5:45 AM, Ley Foon Tan  wrote:
>> This patch adds the Altera PCIe host controller driver.
>>
>> Signed-off-by: Ley Foon Tan 
>> ---
>>  drivers/pci/host/Kconfig   |   9 +
>>  drivers/pci/host/Makefile  |   1 +
>>  drivers/pci/host/pcie-altera.c | 576 
>> +
>>  3 files changed, 586 insertions(+)
>>  create mode 100644 drivers/pci/host/pcie-altera.c
>>
>> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
>> index 675c2d1..af19039 100644
>> --- a/drivers/pci/host/Kconfig
>> +++ b/drivers/pci/host/Kconfig
>> @@ -145,4 +145,13 @@ config PCIE_IPROC_BCMA
>>   Say Y here if you want to use the Broadcom iProc PCIe controller
>>   through the BCMA bus interface
>>
>> +config PCIE_ALTERA
>> +   bool "Altera PCIe controller"
>> +   depends on ARCH_SOCFPGA
>> +   depends on OF
>
> I don't think you need this, "depends on ARCH_SOCFPGA" should already
> have taken care of this.
Okay, will remove this.
>
>> +   select PCI_MSI_IRQ_DOMAIN if PCI_MSI
>> +   help
>> + Say Y here if you want to enable PCIe controller support for Altera
>> + SoCFPGA family of SoCs.
>> +
>>  endmenu
>
> 
>
>> +
>> +static int tlp_read_packet(struct altera_pcie *pcie, u32 *value)
>> +{
>> +   u8 loop;
>> +   struct tlp_rp_regpair_t tlp_rp_regdata;
>> +
>> +   for (loop = TLP_LOOP; loop > 0; loop--) {
>> +
>> +   tlp_read_rx(pcie, &tlp_rp_regdata);
>> +
>> +   if (tlp_rp_regdata.ctrl & RP_RXCPL_EOP) {
>> +
>> +   if (value)
>> +   *value = tlp_rp_regdata.reg0;
>> +
>> +   return PCIBIOS_SUCCESSFUL;
>> +   }
>
> Remove all the unnecessary newlines in this function.
Noted.

>> +   }
>> +
>> +   return -ENOENT;
>> +}
>> +
>
> 
>
>> +
>> +static struct platform_driver altera_pcie_driver = {
>> +   .probe  = altera_pcie_probe,
>> +   .remove = altera_pcie_remove,
>> +   .driver = {
>> +   .name   = "altera-pcie",
>> +   .owner  = THIS_MODULE,
>
> Don't need to set owner anymore as this will get populated by the driver core.

Will remove it.

Thanks for reviewing.

Regards
Ley Foon
--
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/6] arm: mach-socfpga: enable pci support

[Ley Foon Tan]

On Tue, Jul 28, 2015 at 9:26 PM, Rob Herring  wrote:
> On Tue, Jul 28, 2015 at 5:45 AM, Ley Foon Tan  wrote:
>> Enable CONFIG_ARCH_SUPPORT_MSI and CONFIG_PCI in SOCFPGA platform.
>>
>> Signed-off-by: Ley Foon Tan 
>> ---
>>  arch/arm/mach-socfpga/Kconfig | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
>> index 90efdeb..7ff4576 100644
>> --- a/arch/arm/mach-socfpga/Kconfig
>> +++ b/arch/arm/mach-socfpga/Kconfig
>> @@ -1,6 +1,7 @@
>>  menuconfig ARCH_SOCFPGA
>> bool "Altera SOCFPGA family" if ARCH_MULTI_V7
>> select ARCH_SUPPORTS_BIG_ENDIAN
>> +   select ARCH_SUPPORTS_MSI
>
> This doesn't exist in mainline having been removed in 3.12.
Will removed this.
>
>> select ARM_AMBA
>> select ARM_GIC
>> select CACHE_L2X0
>> @@ -9,6 +10,7 @@ menuconfig ARCH_SOCFPGA
>> select HAVE_ARM_SCU
>> select HAVE_ARM_TWD if SMP
>> select MFD_SYSCON
>> +   select PCI
>
> This should not be selected by the platform, but be user selectable
> unless perhaps you require PCI to boot.

Will removed this as well.

Thanks for reviewing.

Regards
Ley Foon
--
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 0/3] x86: modify_ldt improvement, test, and config option

[Boris Ostrovsky]

On 07/28/2015 08:47 PM, Andrew Cooper wrote:

On 29/07/2015 01:21, Andy Lutomirski wrote:

On Tue, Jul 28, 2015 at 10:10 AM, Boris Ostrovsky
 wrote:

On 07/28/2015 01:07 PM, Andy Lutomirski wrote:

On Tue, Jul 28, 2015 at 9:30 AM, Andrew Cooper
 wrote:

I suspect that the set_ldt(NULL, 0) call hasn't reached Xen before
xen_free_ldt() is attempting to nab back the pages which Xen still has
mapped as an LDT.


I just instrumented it with yet more LSL instructions.  I'm pretty
sure that set_ldt really is clearing at least LDT entry zero.
Nonetheless the free_ldt call still oopses.


Yes, I added some instrumentation to the hypervisor and we definitely set
LDT to NULL before failing.

-boris

Looking at map_ldt_shadow_page: what keeps shadow_ldt_mapcnt from
getting incremented once on each CPU at the same time if both CPUs
fault in the same shadow LDT page at the same time?

Nothing, but that is fine.  If a page is in use in two vcpus LDTs, it is
expected to have a type refcount of 2.


Similarly, what
keeps both CPUs from calling get_page_type at the same time and
therefore losing track of the page type reference count?

a cmpxchg() loop in the depths of __get_page_type().


I don't see why vmalloc or vm_unmap_aliases would have anything to do
with this, though.


So just for kicks I made lazy_max_pages() return 0 to free vmaps 
immediately and the problem went away.


I also saw this warning, BTW:

[  178.686542] [ cut here ]
[  178.686554] WARNING: CPU: 0 PID: 16440 at 
./arch/x86/include/asm/mmu_context.h:96 load_mm_ldt+0x70/0x76()

[  178.686558] DEBUG_LOCKS_WARN_ON(!irqs_disabled())
[  178.686561] Modules linked in:
[  178.686566] CPU: 0 PID: 16440 Comm: kworker/u2:1 Not tainted 
4.1.0-32b #80
[  178.686570]    ea4e3df8 c1670e71  ea4e3e28 
c106ac1e c1814e43
[  178.686577]  ea4e3e54 4038 c181bc2c 0060 c166fd3b c166fd3b 
e6705dc0 
[  178.686583]  ea665000 ea4e3e40 c106ad03 0009 ea4e3e38 c1814e43 
ea4e3e54 ea4e3e5c

[  178.686589] Call Trace:
[  178.686594]  [] dump_stack+0x41/0x52
[  178.686598]  [] warn_slowpath_common+0x8e/0xd0
[  178.686602]  [] ? load_mm_ldt+0x70/0x76
[  178.686609]  [] ? load_mm_ldt+0x70/0x76
[  178.686612]  [] warn_slowpath_fmt+0x33/0x40
[  178.686615]  [] load_mm_ldt+0x70/0x76
[  178.686619]  [] flush_old_exec+0x6f9/0x750
[  178.686626]  [] load_elf_binary+0x2b4/0x1040
[  178.686630]  [] ? page_address+0x15/0xf0
[  178.686633]  [] ? kunmap+0x1f/0x70
[  178.686636]  [] search_binary_handler+0x89/0x1c0
[  178.686639]  [] do_execveat_common+0x4c0/0x620
[  178.686653]  [] ? kmemdup+0x33/0x50
[  178.686659]  [] ? __call_rcu.constprop.66+0xbb/0x220
[  178.686673]  [] do_execve+0x24/0x30
[  178.686679]  [] call_usermodehelper+0xde/0x120
[  178.686684]  [] ret_from_kernel_thread+0x21/0x30
[  178.686696]  [] ? __request_module+0x240/0x240
[  178.686701] ---[ end trace 8b3f5341f50e6c88 ]---


-boris
--
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 v6 0/3] Add MediaTek display PWM driver

[YH Huang]

On Fri, 2015-07-24 at 17:10 +0800, YH Huang wrote:
> On Fri, 2015-07-24 at 10:42 +0200, Matthias Brugger wrote:
> > On Monday, July 20, 2015 04:17:14 PM YH Huang wrote:
> > > This patch series add the use of display PWM driver, documentation
> > > and device tree for Mediatek SoCs. The driver is used to support
> > > the backlight of the panel. This is based on v4.2-rc1.
> > > 
> > > The clock definitions (CLK_MM_DISP_PWM*) are added by James Liao's patch:
> > > clk: mediatek: Add subsystem clocks of MT8173
> > > 
> > > Change in v6:
> > > 1. Enable clocks in the pwm_enable function
> > > 2. Remove suspend/resume code since pwm-backlight driver has done the same
> > > things 3. Revise some code to make it easier to read
> > > 
> > 
> > Can you please provide the whole change log for all versions the next time.
> > It's easier this way to understand the evolution of the series.
> 
> Change in v6:
> 1. Enable clocks in the pwm_enable function.
> 2. Remove suspend/resume code since pwm-backlight driver has done the
> same things.
> 3. Revise some code to make it easier to read.
> 
> Change in v5:
> 1. Configure PWM output via pinctrl.
> 2. Fix the parameter name in dtsi.
> 
> Change in v4:
> 1. Codebase is on v4.2-rc1.
> 2. Add the PWM node in dtsi.
> 3. Change the dependency in Kconfig.
> 4. Rewrite some code for readability.
> 
> Change in v3:
> 1. Add suspend/resume function.
> 2. Fix the formula for high_width calculation.
> 3. Rewrite some code to make it easier to read.
> 4. Add more information in the commit message.
> 
> Change in v2:
> 1. Rewrite descriptions for driver in kconfig to make it much clear.
> 2. Rename the driver from "pwm-mediatek-disp" to "pwm-mtk-disp".
> 3. Disable clocks in the error path.
> 4. Change the shift values in decimal instead of hex.
> 5. Rename and add some variables or function name for consistency and
> readability.
> 6. Drop unnecessary parentheses, spaces, variables and add newlines to
> make the code easiler to read.

Hi all,

If you have any suggestions, please let me know.
Perhaps we can apply the patch?

Regards,
YH Huang

--
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: shared usb dt document is incorrect

[Rob Herring]

On Tue, Jul 28, 2015 at 8:06 PM, Tim Bird  wrote:
> Antoine and Rob,
>
> I was just doing some testing with USB on a Qualcomm SoC.
>
> I followed the instructions in the binding document:
> Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
>
> which has a compatible for "qcom,ci-hdrc", and is, in general,
> for chipidea-based USB controllers.
>
> It says in the document that the property usb-phy is deprecated, and to
> use phys and phy-names instead.  However, the Qualcomm
> driver for this still uses usb-phy.  That driver is in:
> drivers/usb/chipidea/ci_hdrc_msm.c

Deprecated means it still exists in the wild and should be maintained,
but don't use it for new dts files.

> I'm guessing I should update the Qualcomm driver to use
> phys and phy-names, but wanted to check with you-all to
> verify that this is the preferred method of getting
> phys by phandle now.  It's either change the driver
> or make an exception in the binding document, I believe.

That would be fine along with updating the dts files, but the doc
should remain for some time.

> I presume I should be changing devm_usb_get_phy_by_phandle()
> to of_phy_get(), but let me know if there's more to qit than that.

devm_phy_get actually. The driver already supports it. See
ci_hdrc_probe in core.c.

> In case I change the driver, do I then update the binding doc
> to remove the information about the deprecated property, or not?

Not.

Rob
--
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: manual merge of the mfd tree with the pm tree

[Stephen Rothwell]

Hi Lee,

Today's linux-next merge of the mfd tree got a conflict in:

  drivers/acpi/scan.c

between commit:

  68c6b148daa6 ("ACPI / scan: Move device matching code to bus.c")

from the pm tree and commit:

  712e960f0ee9 ("ACPI / PM: Attach ACPI power domain only once")

from the mfd tree.

I fixed it up by adding the following merge fix patch and can carry the
fix as necessary.

From: Stephen Rothwell 
Date: Wed, 29 Jul 2015 12:07:20 +1000
Subject: [PATCH] ACPI / PM: merge fix for code movement

Signed-off-by: Stephen Rothwell 
---
 drivers/acpi/bus.c | 46 ++
 1 file changed, 30 insertions(+), 16 deletions(-)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 54a2e66ce236..afc15bf929d8 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -482,6 +482,35 @@ static void acpi_device_remove_notify_handler(struct 
acpi_device *device)
  Device Matching
-- 
*/
 
+/**
+ * acpi_device_is_first_physical_node - Is given dev first physical node
+ * @adev: ACPI companion device
+ * @dev: Physical device to check
+ *
+ * Function checks if given @dev is the first physical devices attached to
+ * the ACPI companion device. This distinction is needed in some cases
+ * where the same companion device is shared between many physical devices.
+ *
+ * Note that the caller have to provide valid @adev pointer.
+ */
+bool acpi_device_is_first_physical_node(struct acpi_device *adev,
+   const struct device *dev)
+{
+   bool ret = false;
+
+   mutex_lock(&adev->physical_node_lock);
+   if (!list_empty(&adev->physical_node_list)) {
+   const struct acpi_device_physical_node *node;
+
+   node = list_first_entry(&adev->physical_node_list,
+   struct acpi_device_physical_node, node);
+   ret = node->dev == dev;
+   }
+   mutex_unlock(&adev->physical_node_lock);
+
+   return ret;
+}
+
 /*
  * acpi_companion_match() - Can we match via ACPI companion device
  * @dev: Device in question
@@ -506,7 +535,6 @@ static void acpi_device_remove_notify_handler(struct 
acpi_device *device)
 struct acpi_device *acpi_companion_match(const struct device *dev)
 {
struct acpi_device *adev;
-   struct mutex *physical_node_lock;
 
adev = ACPI_COMPANION(dev);
if (!adev)
@@ -515,21 +543,7 @@ struct acpi_device *acpi_companion_match(const struct 
device *dev)
if (list_empty(&adev->pnp.ids))
return NULL;
 
-   physical_node_lock = &adev->physical_node_lock;
-   mutex_lock(physical_node_lock);
-   if (list_empty(&adev->physical_node_list)) {
-   adev = NULL;
-   } else {
-   const struct acpi_device_physical_node *node;
-
-   node = list_first_entry(&adev->physical_node_list,
-   struct acpi_device_physical_node, node);
-   if (node->dev != dev)
-   adev = NULL;
-   }
-   mutex_unlock(physical_node_lock);
-
-   return adev;
+   return acpi_device_is_first_physical_node(adev, dev) ? adev : NULL;
 }
 
 /**
-- 
2.4.6

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
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: Possible regression due to "tick: broadcast: Prevent livelock from event handler"

[Simon Horman]

Hi Thomas,

On Fri, Jul 03, 2015 at 04:53:49PM +0200, Thomas Gleixner wrote:
> On Fri, 3 Jul 2015, Wolfram Sang wrote:
> > > So this is a single core machine and uses the em_sti timer w/o the
> > > broadcast nonsense. In Simons case it looks like em_sti is used as
> > > broadcast device.
> > 
> > We use the same board. Just my kernel has SMP=n.
> > 
> > > Though the issues you see in the highres=n case might be the same as
> > > the ones Simon is observing.
> > 
> > I hope so. One good thing about the issue I see is that it is 100%
> > reproducable.
> > 
> > > So in that nohz=y highres=n case, does adding idle=poll on the command
> > > line fix the issue?
> > 
> > Nope, still hangs.
> 
> Ok. So it's unrelated to deep idle states. Any chance of poking with
> JTAG at the frozen box? If not, are there GPIOs which you could use to
> monitor certain state?

Sorry for the delay, it has taken me a while to secure a JTAG.

I now have one hooked up to my emev2/kzm9d board; though I must
confess I am not at all experienced in driving it.

As far as I can tell, and to be quite honest I would not be at all
surprised if I am mistaken, the CPUs are sitting here:

pc: 0xC001F7E8, which corresponds to cpu_v7_do_idle

Hooking up GDB I see:

#0  cpu_v7_do_idle () at arch/arm/mm/proc-v7.S:74
#1  0xc0010734 in arch_cpu_idle () at arch/arm/kernel/process.c:72
#2  0xc04c406c in schedule_preempt_disabled () at kernel/sched/core.c:3115
#3  0xc0055130 in cpu_idle_loop () at kernel/sched/idle.c:279
#4  cpu_startup_entry (state=CPUHP_OFFLINE) at kernel/sched/idle.c:301
#5  0xc04bf440 in rest_init () at init/main.c:412
#6  0xc061bc6c in start_kernel () at init/main.c:683
#7  0x4000807c in ?? ()


I am using the renesas-devel-20150729-v4.2-rc4 tag of the my renesas tree
which, as the name suggests, is based on v4.2-rc4.
--
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: Next round: revised futex(2) man page for review

[Davidlohr Bueso]

On Tue, 2015-07-28 at 22:45 +0200, Peter Zijlstra wrote:
> Also, this code seems to use plist, which means it won't do the right
> thing for SCHED_DEADLINE either.

Ick, I don't look forward to seeing nice futex plists converted into
rbtrees. As opposed to, eg. rtmutexes, there are a few caveats:

- Dealing with the top_waiter in rtmutexes is always easy, but in
futexes we need to deal with keys, so caching the leftmost won't work as
nicely.

- This will bloat things like futex_wake, where O(logN) is not suited
for FIFO iteration. And iterating linked lists is, in essence, all that
we really do when calling futex(2).

I have to wonder about the extra overhead added by these points.  I do
understand the dl concern, nonetheless.

--
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 net v2 2/2] r8152: reset device when tx timeout

[Hayes Wang]

 Oliver Neukum [mailto:oneu...@suse.com]
> Sent: Tuesday, July 28, 2015 8:59 PM
[...]
> > > >  static void rtl8152_tx_timeout(struct net_device *netdev)  {
> > > > struct r8152 *tp = netdev_priv(netdev);
> > > > -   int i;
> > > >
> > > > netif_warn(tp, tx_err, netdev, "Tx timeout\n");
> > > > -   for (i = 0; i < RTL8152_MAX_TX; i++)
> > > > -   usb_unlink_urb(tp->tx_info[i].urb);
> > > > +
> > > > +   usb_queue_reset_device(tp->intf);
> > > > +   cancel_delayed_work(&tp->schedule);
> > >
> > > Sorry to bother you again, but this looks wrong.
> > > You want to cancel first. There is no point in running any work
> > > before the reset is done. It will undo any progress anyway.
> >
> > Excuse me. Do you mean I don't need cancel the other work because it
> > wouldn't be run before the reset is finished?
> 
> No, whatever the other work will do, the reset will undo.

Excuse me. I don't understand why I couldn't use usb_queue_reset_device() 
directly.
Why the reset will undo? 

Best Regards,
Hayes

RE: [PATCH 3/5] Add calls to translate Always Running Timer (ART) to system time

[Hall, Christopher S]

> -Original Message-
> From: John Stultz [mailto:john.stu...@linaro.org]
> Sent: Monday, July 27, 2015 9:11 PM
> To: Hall, Christopher S
> Cc: Thomas Gleixner; Richard Cochran; Ingo Molnar; Kirsher, Jeffrey T;
> Ronciak, John; H. Peter Anvin; x...@kernel.org; lkml;
> net...@vger.kernel.org
> Subject: Re: [PATCH 3/5] Add calls to translate Always Running Timer
> (ART) to system time
> 
> On Mon, Jul 27, 2015 at 5:46 PM, Christopher Hall
>  wrote:
> > +static bool checked_art_to_tsc(cycle_t *tsc)
> > +{
> > +   if (!has_art())
> > +   return false;
> > +   *tsc = art_to_tsc(*tsc);
> > +   return true;
> > +}
> > +
> > +static int art_to_rawmono64(struct timespec64 *rawmono, cycle_t art)
> > +{
> > +   if (!checked_art_to_tsc(&art))
> > +   return -ENXIO;
> > +   return tsc_to_rawmono64(rawmono, art);
> > +}
> > +EXPORT_SYMBOL(art_to_rawmono64);
> 
> This all seems to assume the TSC is the current clocksource, which it
> may not be if the user has overridden it.

I don't make that assumption.  The counter_to_* functions take a
pointer to a clocksource struct.  They return -ENXIO if that clocksource
doesn’t match the current clocksource.

The tsc_to_* functions pass the tsc clocksource pointer to the counter_to_*
functions.  These tsc conversion functions are called by the art_to_*
functions.

> 
> If instead there were a counter_to_rawmono64() which took the counter
> value and maybe the name of the clocksource (if the strncmp is
> affordable for your use), it might be easier for the core to provide
> an error if the current timekeeping clocksource isn't the one the
> counter value is based on. This would also allow the tsc_to_*()
> midlayers to be dropped (since they don't seem to do much).
> 
> thanks
> -john

Again, thanks for your input.

Chris

Re: [PATCH] virtio_mmio: add ACPI probing

[Shannon Zhao]

On 2015/7/29 5:10, Peter Maydell wrote:
> On 28 July 2015 at 21:28, G Gregory  wrote:
>> > On 28 July 2015 at 21:12, Peter Maydell  wrote:
>>> >> Mmm. I'm not terribly happy about stuff being in QEMU before the
>>> >> ACPI spec for it has been finalised. We should not be picking
>>> >> stuff randomly on the fly...
>>> >>
>>> >> If we want to fix the ACPI IDs QEMU is using for 2.4 then we
>>> >> really need to do that now (ie within the next day or two).
>>> >>
>> > It is upto the owner of the QEMU prefix to allocate numbers. This is
>> > not an issue for ACPI spec at all.
> I mean "the specification for how this device should be advertised
> in an ACPI table". I don't care whether that's an official ACPI
> consortium thing or something less official. The table is
> constructed by QEMU and read by the kernel (and possibly
> also by UEFI?), so everybody needs to agree on what the
> string is...

I agree with Peter. Maybe we should record these IDs at some place.
Since QEMU is owner of this device and we register QEMU in ASWG, the
official ID can be assigned by QEMU and the ID could(or should) be
"QEMU". But what's the exact ID for this virtio-mmio? That's what we
need to agree on and record.

P.S. I don't see "QEMU" in the list of approved Vendor IDs for ACPI.
http://www.uefi.org/sites/default/files/resources/PNPID_List.pdf
http://www.uefi.org/sites/default/files/resources/ACPIID_List.pdf

-- 
Shannon
--
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/2] drivers: watchdog: at91sam9_wdt: add new feature support

[Yang, Wenyou]

Hi Guenter,

Thank you for your prompt answer.

> -Original Message-
> From: Guenter Roeck [mailto:li...@roeck-us.net]
> Sent: 2015年7月29日 9:23
> To: Yang, Wenyou; w...@iguana.be; robh...@kernel.org; pawel.m...@arm.com;
> mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; ga...@codeaurora.org
> Cc: sylvain.roc...@finsecur.com; Ferre, Nicolas; boris.brezillon@free-
> electrons.com; devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; 
> linux-
> watch...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH 1/2] drivers: watchdog: at91sam9_wdt: add new feature
> support
> 
> On 07/28/2015 05:38 PM, Yang, Wenyou wrote:
> > Hi Guenter,
> >
> > Thank you very much for your review.
> >
> >> -Original Message-
> >> From: Guenter Roeck [mailto:li...@roeck-us.net]
> >> Sent: 2015年7月28日 15:14
> >> To: Yang, Wenyou; w...@iguana.be; robh...@kernel.org;
> >> pawel.m...@arm.com; mark.rutl...@arm.com;
> >> ijc+devicet...@hellion.org.uk; ga...@codeaurora.org
> >> Cc: sylvain.roc...@finsecur.com; Ferre, Nicolas;
> >> boris.brezillon@free- electrons.com; devicet...@vger.kernel.org;
> >> linux-kernel@vger.kernel.org; linux- watch...@vger.kernel.org;
> >> linux-arm-ker...@lists.infradead.org
> >> Subject: Re: [PATCH 1/2] drivers: watchdog: at91sam9_wdt: add new
> >> feature support
> >>
> >> On 07/28/2015 12:00 AM, Wenyou Yang wrote:
> >>> In the datasheet, the new feature is describled as "WDT_MR can be
> >>> written until a LOCKMR command is issued in WDT_CR".
> >>> That is to say, as long as the bootstrap and u-boot don't issue a
> >>> LOCKMR command, WDT_MR can be written in kernel.
> >>>
> >>> So the driver can enable/disable the watchdog timer hardware, set
> >>> WDV(Watchdog Counter Value) and WDD(Watchdog Delta Value) fields of
> >>> WDT_MR register to set the watchdog timer timeout.
> >>>
> >>> The timer is not necessary that regularly sends a keepalive ping to
> >>> the watchdog timer hardware.
> >>>
> >>> It is introduced from sama5d4 SoCs.
> >>>
> >> Since there are so many changes, I wonder is a separate driver would
> >> make more sense.
> > Yes, a bit many changes.
> > I thought reuse the driver code.
> > If a separate driver, I am afraid it includes much duplicated code.
> > After all, it is for the same device with different feature.
> >
> > I don't think it is necessary to have multiple drivers for the same 
> > peripheral with
> different feature.
> >
> 
> The concept for the two mechanisms is all different: In one, the watchdog
> keepalive is triggered from timer code. In the other, the watchdog timeout is
> triggered directly from the heartbeat function. One assumes that the watchdog 
> is
> always running, and that it must be pinged even if closed. The other disables 
> the
> watchdog on close.
> 
> What I _can_ see is that the driver is becoming an unmaintainable mess, with 
> lots
> of if/else in pretty much every function. I consider this much less desirable 
> than a
> bit of code duplication - if there is any. Seriously, most of the added code 
> might as
> well be for a completely different chip.

You are right, I accepted your advice. I will rewrite it. Thanks.

> 
> Guenter

Best Regards,
Wenyou Yang

Re: [PATCH v2 2/5] mtd: nand: Qualcomm NAND controller driver

[Stephen Boyd]

On 07/27/2015 09:34 PM, Archit Taneja wrote:

Hi,

On 07/25/2015 06:21 AM, Stephen Boyd wrote:

On 07/21/2015 03:34 AM, Archit Taneja wrote:


+  int size)
+{
+struct desc_info *desc;
+struct dma_async_tx_descriptor *dma_desc;
+struct scatterlist *sgl;
+int r;
+
+desc = kzalloc(sizeof(*desc), GFP_KERNEL);
+if (!desc)
+return -ENOMEM;
+
+list_add_tail(&desc->list, &this->list);
+
+sgl = &desc->sgl;
+
+sg_init_one(sgl, vaddr, size);
+
+desc->dir = DMA_MEM_TO_DEV;
+
+r = dma_map_sg(this->dev, sgl, 1, desc->dir);
+if (r == 0)
+goto err;


Should we return an error in this case? Looks like return 0.


dma_map_sg returns the number of sg entries successfully mapped. In
this case, it should be 1.


Right, but this function returns 0 (success?) if we failed to map anything.






+
+this->slave_conf.device_fc = 0;
+this->slave_conf.dst_addr = this->res->start + reg_off;
+this->slave_conf.dst_maxburst = 16;


Is there any reason why slave_conf can't be on the stack? Otherwise it's
odd that it's overwritten a few times before we submit the descriptors,
so it must be copied by the dmaengine provider, but that isn't clear at
all from the code. If it isn't copied, perhaps it should be part of the
desc_info structure. If it is copied I wonder why it isn't const in the
function signature.


The dmaengine drivers either memcpy slave_config in their
device_config() dmaengine op, or populate their local members reading
params in the passed slave_config.

I'll move slave_conf to stack. As you said, the config argument
in dmaengine_slave_config should ideally use const.


Cool, someone should send a patch.






+
+r = dmaengine_slave_config(this->chan, &this->slave_conf);
+if (r) {
+dev_err(this->dev, "failed to configure dma channel\n");
+goto err;
+}
+
+dma_desc = dmaengine_prep_slave_sg(this->chan, sgl, 1, 
desc->dir, 0);

+if (!dma_desc) {
+dev_err(this->dev, "failed to prepare data write desc\n");
+r = PTR_ERR(dma_desc);
+goto err;
+}
+
+desc->dma_desc = dma_desc;
+
+return 0;
+err:
+kfree(desc);
+
+return r;
+}
+
+/*
+ * helper to prepare dma descriptors to configure registers needed 
for reading a

+ * codeword/step in a page
+ */
+static void config_cw_read(struct qcom_nandc_data *this)
+{
+struct nandc_regs *regs = this->regs;
+
+write_reg_dma(this, NAND_FLASH_CMD, ®s->cmd, 3, true);


Maybe it would be better to have a case statement inside
{write,read}_reg_dma() that looked at the second argument and matched it
up with an offset in regs. Then this could be

 write_reg_dma(this, NAND_FLASH_CMD, 3, true);


That's a good idea. However, we have at least one programming seqeunce 
(in nandc_param) where we need to write two different values to the 
same register. In such a case, we need two different locations to 
store the two values.


I can split up the programming sequence into two parts such that we 
won't write to the same register twice. But doing this for the sake of 
reducing an argument to write_reg_dma seems a bit unnecessary.




Or you could have two #defines that indicate the different usage? Like 
NAND_CMD_FOO and NAND_CMD_BAR that both map to the same register but 
uses different locations as storage.




Are we guaranteed that this is called within the same context as where
the buffer is passed to this function? Otherwise this stack check isn't
going to work because object_is_on_stack() will silently fail.


These are funcs are finally tied to mtd ops. I think in normal operation
it'll be the same context. I'll still cross check. The aim of the check
is to prevent a memcpy of the buffer to/from the layer above. A false
negative will result in a slower read/write operation.


Right. It would be nice if the mtd layer was DMA aware and could 
indicate to drivers that DMA on the buffer is allowable or not. Trying 
to figure it out if the buffer is in lowmem after the buffer is mapped 
is error prone, which is why not a lot of usage of object_is_on_stack() 
exists. Honestly I'm confused, I thought the DMA APIs would "do the 
right thing" when highmem was passed into the mapping APIs, but maybe 
I'm wrong. I'll have to look.


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

--
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/5] Add calls to translate Always Running Timer (ART) to system time

[Andy Lutomirski]

On Tue, Jul 28, 2015 at 6:18 PM, Hall, Christopher S
 wrote:
>
>
>> -Original Message-
>> From: Andy Lutomirski [mailto:l...@kernel.org]
>> Sent: Monday, July 27, 2015 6:32 PM
>> To: Hall, Christopher S; john.stu...@linaro.org; t...@linutronix.de;
>> richardcoch...@gmail.com; mi...@redhat.com; Kirsher, Jeffrey T; Ronciak,
>> John; h...@zytor.com; x...@kernel.org
>> Cc: linux-kernel@vger.kernel.org; net...@vger.kernel.org; Borislav
>> Petkov
>> Subject: Re: [PATCH 3/5] Add calls to translate Always Running Timer
>> (ART) to system time
>>
>> On 07/27/2015 05:46 PM, Christopher Hall wrote:
>> > * art_to_mono64
>> > * art_to_rawmono64
>> > * art_to_realtime64
>> >
>> > Intel audio and PCH ethernet devices use the Always Running Timer
>> (ART) to
>> > relate their device clock to system time
>> >
>> > Signed-off-by: Christopher Hall 
>> > ---
>> >   arch/x86/Kconfig   |  12 
>> >   arch/x86/include/asm/art.h |  42 ++
>> >   arch/x86/kernel/Makefile   |   1 +
>> >   arch/x86/kernel/art.c  | 134
>> +
>> >   arch/x86/kernel/tsc.c  |   4 ++
>> >   5 files changed, 193 insertions(+)
>> >   create mode 100644 arch/x86/include/asm/art.h
>> >   create mode 100644 arch/x86/kernel/art.c
>> >
>> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> > index b3a1a5d..1ef9985 100644
>> > --- a/arch/x86/Kconfig
>> > +++ b/arch/x86/Kconfig
>> > @@ -1175,6 +1175,18 @@ config X86_CPUID
>> >   with major 203 and minors 0 to 31 for /dev/cpu/0/cpuid to
>> >   /dev/cpu/31/cpuid.
>> >
>> > +config X86_ART
>> > +   bool "Always Running Timer"
>> > +   default y
>> > +   depends on X86_TSC
>> > +   ---help---
>> > + This option provides functionality to drivers and devices that
>> use
>> > + the always-running-timer (ART) to correlate their device clock
>> > + counter with the system clock counter. The TSC is *exactly*
>> related
>> > + to the ART by a ratio m/n specified by CPUID leaf 0x15
>> > + (n=EAX,m=EBX). If ART is unused or unavailable there isn't any
>> > + performance impact. It's safe to say Y.
>> > +
>>
>> Is there a good reason to make this optional?
>
> If there aren't any objections, it sound OK to me.  So no, I don't know
> of any good reasons.
>
>>
>> Also, is there *still* no way to ask the thing for its nominal
>> frequnency?  Or can we expect CPUID leaf 16H to work on CPUs that
>> support this and can we expect it to actually work?
>
> There isn't any way to query nominal frequency.  CPUID leaf 0x15 only
> exposes the relationship between ART and TSC.  CPUID leaf 0x16 stays
> the more or less the same and isn't related to ART.
>
> The SDM says "The
>> returned information should not be used for any other purpose as the
>> returned information does not accurately correlate to information /
>> counters returned by other processor interfaces."
>>
>> Also, does this thing let us learn the real time base?  SDM 17.14.4
>> suggests that the ART value isn't affected by "privileged software" (aka
>> buggy/malicious firmware).  Or, alternatively, how do we learn the
>> offset K between ART and scaled TSC?
>
> ART isn't affected by software.  The determination of K used to convert ART to
> TSC is in a footnote (2) in that section of the SDM.  I'm not going to risk
> repeating it here and possibly altering its meaning.
>
>>
>> >   choice
>> > prompt "High Memory Support"
>> > default HIGHMEM4G
>> > diff --git a/arch/x86/include/asm/art.h b/arch/x86/include/asm/art.h
>> > new file mode 100644
>> > index 000..da58ce4
>> > --- /dev/null
>> > +++ b/arch/x86/include/asm/art.h
>> > @@ -0,0 +1,42 @@
>> > +/*
>> > + * x86 ART related functions
>> > + */
>> > +#ifndef _ASM_X86_ART_H
>> > +#define _ASM_X86_ART_H
>> > +
>> > +#ifndef CONFIG_X86_ART
>> > +
>> > +static inline int setup_art(void)
>> > +{
>> > +   return 0;
>> > +}
>> > +
>> > +static inline bool has_art(void)
>> > +{
>> > +   return false;
>> > +}
>> > +
>> > +static inline int art_to_rawmono64(struct timespec64 *rawmono,
>> cycle_t art)
>> > +{
>> > +   return -ENXIO;
>> > +}
>> > +static inline int art_to_realtime64(struct timespec64 *realtime,
>> cycle_t art)
>> > +{
>> > +   return -ENXIO;
>> > +}
>> > +static inline int art_to_mono64(struct timespec64 *mono, cycle_t art)
>> > +{
>> > +   return -ENXIO;
>> > +}
>> > +
>> > +#else
>> > +
>> > +extern int setup_art(void);
>> > +extern bool has_art(void);
>> > +extern int art_to_rawmono64(struct timespec64 *rawmono, cycle_t art);
>> > +extern int art_to_realtime64(struct timespec64 *realtime, cycle_t
>> art);
>> > +extern int art_to_mono64(struct timespec64 *mono, cycle_t art);
>> > +
>> > +#endif
>> > +
>> > +#endif/*_ASM_X86_ART_H*/
>> > diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
>> > index 0f15af4..0908311 100644
>> > --- a/arch/x86/kernel/Makefile
>> > +++ b/arch/x86/kernel/Makefile
>> > @@ -109,6 +109,7 @@ obj-$(CONFIG_PERF_EVENTS)   +=
>> perf_regs.o
>> >  

RE: [PATCH 1/5] Add functions producing system time given a backing counter value

[Hall, Christopher S]

> -Original Message-
> From: John Stultz [mailto:john.stu...@linaro.org]
> Sent: Monday, July 27, 2015 8:44 PM
> To: Hall, Christopher S
> Cc: Thomas Gleixner; Richard Cochran; Ingo Molnar; Kirsher, Jeffrey T;
> Ronciak, John; H. Peter Anvin; x...@kernel.org; lkml;
> net...@vger.kernel.org
> Subject: Re: [PATCH 1/5] Add functions producing system time given a
> backing counter value
> 
> On Mon, Jul 27, 2015 at 5:46 PM, Christopher Hall
>  wrote:
> > * counter_to_rawmono64
> > * counter_to_mono64
> > * counter_to_realtime64
> >
> > Enables drivers to translate a captured system clock counter to system
> > time. This is useful for network and audio devices that capture
> timestamps
> > in terms of both the system clock and device clock.
> 
> Huh.  So for counter_to_realtime64 & mono64, this seems to ignore the
> fact that the multiplier is constantly adjusted and corrected. So that
> calling the function twice with the same counter value may result in
> different returned values.
> 
> I've not yet groked the whole patchset, but it seems like there needs
> to be some mechanism that ensures the counter value is captured and
> used in the same (or at least close) interval that the timekeeper data
> is valid for.

The ART (and derived TSC) values are always in the past.  There's no
chance that we could exceed the interval.  I don't think any similar
usage would be a problem either.

Are you suggesting that, for completeness, this be enforced by the
conversion function?

I do a check here to make sure that the current counter value isn't before
the beginning of the current interval:

timekeeping_get_delta()
...
   if (cycle_now < tkr->cycle_last &&
   tkr->cycle_last - cycle_now < ROLLOVER_THRESHOLD)
return -EAGAIN;

If tkr->cycle_last - cycle_now is large, the assumption is that
rollover occurred.  Otherwise, the caller should re-read the counter
so that it falls within the current interval.  In my "normal use"
testing, re-read never occurred.

Thanks for your input.

Chris

> 
> thanks
> -john
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

RE: [PATCH 00/22] ACPICA: 20150717 Release

[Zheng, Lv]

Hi, Rafael
 
You may also need this patch:
https://patchwork.kernel.org/patch/6879621/
Which fixes a problem in this release.
Sorry for noticing this late.

Thanks and best regards
-Lv

> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Wednesday, July 29, 2015 8:58 AM
> 
> On Thursday, July 23, 2015 12:51:58 PM Lv Zheng wrote:
> > The 20150717 ACPICA kernel-resident subsystem updates are linuxized based
> > on the linux-pm/linux-next branch.
> >
> > The patchset has passed the following build/boot tests.
> > Build tests are performed as follows:
> > 1. i386 + default + COFNIG_ACPI=y
> > 2. i386 + allyes + CONFIG_ACPI=y
> > 3. i386 + default + COFNIG_ACPI=n
> > 4. i386 + allyes + CONFIG_ACPI=n
> > 5. x86_64 + default + COFNIG_ACPI=y
> > 6. x86_64 + allyes + CONFIG_ACPI=y
> > 7. x86_64 + default + COFNIG_ACPI=n
> > 8. x86_64 + allyes + CONFIG_ACPI=n
> > Boot tests are performed as follows:
> > 1. i386 + default + COFNIG_ACPI=y
> > 2. x86_64 + default + COFNIG_ACPI=y
> > Where:
> > 1. i386: machine named as "Dell Inspiron Mini 1010"
> > 2. x86_64: machine named as "HP Compaq 8200 Elite SFF PC"
> > 3. default: kernel configuration with following items enabled:
> >All hardware drivers related to the machines of i386/x86_64
> >All "drivers/acpi" configurations
> >All "drivers/platform" drivers
> >All other drivers that link the APIs provided by ACPICA subsystem
> >
> > The divergences checking result:
> > Before applying (20150619 Release):
> >   539 lines
> > After applying (20150717 Release):
> >   518 lines
> > Note that the reduction is due to:
> > 1. The FACS related divergences are not counted;
> > 2. Some debugger related divergences are merged in this release as the
> >configurability of the debugger code has improved.
> >
> > Bob Moore (6):
> >   ACPICA: iASL: Add new warnings for method local_x and arg_x
> > variables.
> >   ACPICA: Cleanup use of all non-ANSI local C library functions.
> >   ACPICA: Cleanup use of NEGATIVE and POSITIVE defines.
> >   ACPICA: iASL: Add support for TCPA Server Table.
> >   ACPICA: iASL/Disassembler: Add prototype verbose mode.
> >   ACPICA: Update version to 20150717.
> >
> > Lv Zheng (15):
> >   ACPICA: Parser: Reduce parser/namespace divergences for tracer
> > support.
> >   ACPICA: Parser: Cleanup aml_offset in struct acpi_walk_state.
> >   ACPICA: Parser: Cleanup aml_offset in union acpi_operand_object.
> >   ACPICA: Dispatcher: Cleanup union acpi_operand_object's AML address
> > assignments.
> >   ACPICA: Executer: Add back pointing reference of method operand.
> >   ACPICA: Namespace: Add function to directly return normalized full
> > path.
> >   ACPICA: Dispatcher: Move stack traversal code to dispatcher.
> >   ACPICA: Dispatcher: Add trace support for interpreter.
> >   ACPICA: Executer: Add interpreter tracing mode for method tracing
> > facility.
> >   ACPICA: Executer: Add OSL trace hook support.
> >   ACPICA: Executer: Add option to bypass opcode tracing.
> >   ACPICA: Parser: Remove redundant opcode execution debugging output.
> >   ACPICA: MSVC: Fix inclusion order issue of .
> >   ACPICA: Debugger: Reduce structure size for debugger.
> >   ACPICA: Debugger: Move debugger specific APIs to debugger component.
> >
> > Markus Elfring (1):
> >   ACPICA: Remove extraneous check for null walk_state.
> 
> Series queued up for 4.3, thanks!
> 
> Rafael

N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

[PATCH 1/2] drm/panel: Add Sharp LS043T1LE01 panel binding documentation

[Bjorn Andersson]

From: Werner Johansson 

Signed-off-by: Werner Johansson 
Signed-off-by: Bjorn Andersson 
---
 .../bindings/panel/sharp,ls043t1le01.txt   | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/panel/sharp,ls043t1le01.txt

diff --git a/Documentation/devicetree/bindings/panel/sharp,ls043t1le01.txt 
b/Documentation/devicetree/bindings/panel/sharp,ls043t1le01.txt
new file mode 100644
index ..758d48d33e46
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/sharp,ls043t1le01.txt
@@ -0,0 +1,22 @@
+Sharp Microelectronics 4.3" qHD TFT LCD panel
+
+Required properties:
+- compatible: should be "sharp,ls043t1le01-qhd-vid"
+- reg: DSI virtual channel of the peripheral
+- power-supply: phandle of the regulator that provides the supply voltage
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+- reset-gpios: a GPIO spec for the reset pin
+
+Example:
+
+   mdss_dsi0: qcom,mdss_dsi@fd922800 {
+   panel: panel@0 {
+   compatible = "sharp,ls043t1le01-qhd-vid";
+   reg = <0>;
+   avdd-supply = <&pm8941_l22>;
+   backlight = <&pm8941_wled>;
+   reset-gpios = <&pm8941_gpios 19 GPIO_ACTIVE_HIGH>;
+   };
+   };
-- 
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/