Re: [RFC PATCH v1 1/6] rockchip: rockchip: add new clock-type for the ddrclk

[hl]

Hi Shawn,

On 2016年06月03日 20:29, Shawn Lin wrote:

Hi Lin,

It looks good with only a few minor comments.

On 2016/6/3 17:55, Lin Huang wrote:

On new rockchip platform(rk3399 etc), there have dcf controller to
do ddr frequency scaling, and this controller will implement in
arm-trust-firmware. We add a special clock-type to handle that.

Signed-off-by: Lin Huang 
---
Changes in v1:
- None

 drivers/clk/rockchip/Makefile  |   1 +
 drivers/clk/rockchip/clk-ddr.c | 147 
+

 drivers/clk/rockchip/clk.c |   9 +++
 drivers/clk/rockchip/clk.h |  27 
 4 files changed, 184 insertions(+)
 create mode 100644 drivers/clk/rockchip/clk-ddr.c

diff --git a/drivers/clk/rockchip/Makefile 
b/drivers/clk/rockchip/Makefile

index f47a2fa..b5f2c8e 100644
--- a/drivers/clk/rockchip/Makefile
+++ b/drivers/clk/rockchip/Makefile
@@ -8,6 +8,7 @@ obj-y+= clk-pll.o
 obj-y+= clk-cpu.o
 obj-y+= clk-inverter.o
 obj-y+= clk-mmc-phase.o
+obj-y+= clk-ddr.o
 obj-$(CONFIG_RESET_CONTROLLER)+= softrst.o

 obj-y+= clk-rk3036.o
diff --git a/drivers/clk/rockchip/clk-ddr.c 
b/drivers/clk/rockchip/clk-ddr.c

new file mode 100644
index 000..5b6630d
--- /dev/null
+++ b/drivers/clk/rockchip/clk-ddr.c
@@ -0,0 +1,147 @@
+/*
+ * Copyright (c) 2016 Rockchip Electronics Co. Ltd.
+ * Author: Lin Huang 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "clk.h"
+


alphabetical order would be better.

Okay, will fix next version, thank you.



+struct rockchip_ddrclk {
+struct clk_hwhw;
+void __iomem*reg_base;
+intmux_offset;
+intmux_shift;
+intmux_width;
+intmux_flag;
+intdiv_shift;
+intdiv_width;
+intdiv_flag;
+spinlock_t*lock;
+};
+
+#define to_rockchip_ddrclk_hw(hw) container_of(hw, struct 
rockchip_ddrclk, hw)

+#define val_mask(width)((1 << (width)) - 1)
+
+static int rockchip_ddrclk_set_rate(struct clk_hw *hw, unsigned long 
drate,

+unsigned long prate)
+{
+struct rockchip_ddrclk *ddrclk = to_rockchip_ddrclk_hw(hw);
+unsigned long flags;
+
+spin_lock_irqsave(ddrclk->lock, flags);
+
+/* TODO: set ddr rate in bl31 */
+
+spin_unlock_irqrestore(ddrclk->lock, flags);
+


What do you wanna protect here?

I am not sure for now, when i finish this function,
if there nothing need protect i will remove it. Thank you.



+return 0;
+}
+
+static unsigned long
+rockchip_ddrclk_recalc_rate(struct clk_hw *hw,
+unsigned long parent_rate)
+{
+struct rockchip_ddrclk *ddrclk = to_rockchip_ddrclk_hw(hw);
+int val;
+
+val = clk_readl(ddrclk->reg_base +
+ddrclk->mux_offset) >> ddrclk->div_shift;
+val &= val_mask(ddrclk->div_width);
+
+return DIV_ROUND_UP_ULL((u64)parent_rate, val + 1);
+}
+
+static long clk_ddrclk_round_rate(struct clk_hw *hw, unsigned long 
rate,

+  unsigned long *prate)
+{
+return rate;
+}
+
+static u8 rockchip_ddrclk_get_parent(struct clk_hw *hw)
+{
+struct rockchip_ddrclk *ddrclk = to_rockchip_ddrclk_hw(hw);
+int num_parents = clk_hw_get_num_parents(hw);
+u32 val;
+
+val = clk_readl(ddrclk->reg_base +
+ddrclk->mux_offset) >> ddrclk->mux_shift;
+val &= val_mask(ddrclk->mux_width);
+
+if (val >= num_parents)
+return -EINVAL;
+
+return val;
+}
+
+static const struct clk_ops rockchip_ddrclk_ops = {
+.recalc_rate = rockchip_ddrclk_recalc_rate,
+.set_rate = rockchip_ddrclk_set_rate,
+.round_rate = clk_ddrclk_round_rate,
+.get_parent = rockchip_ddrclk_get_parent,
+};
+
+struct clk *rockchip_clk_register_ddrclk(const char *name, int flags,
+ const char *const *parent_names,
+ u8 num_parents, int mux_offset,
+ int mux_shift, int mux_width,
+ int mux_flag, int div_shift,
+ int div_width, int div_flag,
+ void __iomem *reg_base,
+ spinlock_t *lock)
+{
+struct rockchip_ddrclk *ddrclk;
+struct clk_init_data init;
+struct clk *clk;
+int ret;
+
+ddrclk = kzalloc(sizeof(*ddrclk), GFP_KERNEL);
+if (!ddrclk)
+return ERR_PTR(-ENOMEM);
+
+init.name = name;
+init.parent_names = parent_names;
+init.num_parents = num_parents;
+init.ops = 

Re: [RFC PATCH v1 1/6] rockchip: rockchip: add new clock-type for the ddrclk

[hl]

Hi Shawn,

On 2016年06月03日 20:29, Shawn Lin wrote:

Hi Lin,

It looks good with only a few minor comments.

On 2016/6/3 17:55, Lin Huang wrote:

On new rockchip platform(rk3399 etc), there have dcf controller to
do ddr frequency scaling, and this controller will implement in
arm-trust-firmware. We add a special clock-type to handle that.

Signed-off-by: Lin Huang 
---
Changes in v1:
- None

 drivers/clk/rockchip/Makefile  |   1 +
 drivers/clk/rockchip/clk-ddr.c | 147 
+

 drivers/clk/rockchip/clk.c |   9 +++
 drivers/clk/rockchip/clk.h |  27 
 4 files changed, 184 insertions(+)
 create mode 100644 drivers/clk/rockchip/clk-ddr.c

diff --git a/drivers/clk/rockchip/Makefile 
b/drivers/clk/rockchip/Makefile

index f47a2fa..b5f2c8e 100644
--- a/drivers/clk/rockchip/Makefile
+++ b/drivers/clk/rockchip/Makefile
@@ -8,6 +8,7 @@ obj-y+= clk-pll.o
 obj-y+= clk-cpu.o
 obj-y+= clk-inverter.o
 obj-y+= clk-mmc-phase.o
+obj-y+= clk-ddr.o
 obj-$(CONFIG_RESET_CONTROLLER)+= softrst.o

 obj-y+= clk-rk3036.o
diff --git a/drivers/clk/rockchip/clk-ddr.c 
b/drivers/clk/rockchip/clk-ddr.c

new file mode 100644
index 000..5b6630d
--- /dev/null
+++ b/drivers/clk/rockchip/clk-ddr.c
@@ -0,0 +1,147 @@
+/*
+ * Copyright (c) 2016 Rockchip Electronics Co. Ltd.
+ * Author: Lin Huang 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "clk.h"
+


alphabetical order would be better.

Okay, will fix next version, thank you.



+struct rockchip_ddrclk {
+struct clk_hwhw;
+void __iomem*reg_base;
+intmux_offset;
+intmux_shift;
+intmux_width;
+intmux_flag;
+intdiv_shift;
+intdiv_width;
+intdiv_flag;
+spinlock_t*lock;
+};
+
+#define to_rockchip_ddrclk_hw(hw) container_of(hw, struct 
rockchip_ddrclk, hw)

+#define val_mask(width)((1 << (width)) - 1)
+
+static int rockchip_ddrclk_set_rate(struct clk_hw *hw, unsigned long 
drate,

+unsigned long prate)
+{
+struct rockchip_ddrclk *ddrclk = to_rockchip_ddrclk_hw(hw);
+unsigned long flags;
+
+spin_lock_irqsave(ddrclk->lock, flags);
+
+/* TODO: set ddr rate in bl31 */
+
+spin_unlock_irqrestore(ddrclk->lock, flags);
+


What do you wanna protect here?

I am not sure for now, when i finish this function,
if there nothing need protect i will remove it. Thank you.



+return 0;
+}
+
+static unsigned long
+rockchip_ddrclk_recalc_rate(struct clk_hw *hw,
+unsigned long parent_rate)
+{
+struct rockchip_ddrclk *ddrclk = to_rockchip_ddrclk_hw(hw);
+int val;
+
+val = clk_readl(ddrclk->reg_base +
+ddrclk->mux_offset) >> ddrclk->div_shift;
+val &= val_mask(ddrclk->div_width);
+
+return DIV_ROUND_UP_ULL((u64)parent_rate, val + 1);
+}
+
+static long clk_ddrclk_round_rate(struct clk_hw *hw, unsigned long 
rate,

+  unsigned long *prate)
+{
+return rate;
+}
+
+static u8 rockchip_ddrclk_get_parent(struct clk_hw *hw)
+{
+struct rockchip_ddrclk *ddrclk = to_rockchip_ddrclk_hw(hw);
+int num_parents = clk_hw_get_num_parents(hw);
+u32 val;
+
+val = clk_readl(ddrclk->reg_base +
+ddrclk->mux_offset) >> ddrclk->mux_shift;
+val &= val_mask(ddrclk->mux_width);
+
+if (val >= num_parents)
+return -EINVAL;
+
+return val;
+}
+
+static const struct clk_ops rockchip_ddrclk_ops = {
+.recalc_rate = rockchip_ddrclk_recalc_rate,
+.set_rate = rockchip_ddrclk_set_rate,
+.round_rate = clk_ddrclk_round_rate,
+.get_parent = rockchip_ddrclk_get_parent,
+};
+
+struct clk *rockchip_clk_register_ddrclk(const char *name, int flags,
+ const char *const *parent_names,
+ u8 num_parents, int mux_offset,
+ int mux_shift, int mux_width,
+ int mux_flag, int div_shift,
+ int div_width, int div_flag,
+ void __iomem *reg_base,
+ spinlock_t *lock)
+{
+struct rockchip_ddrclk *ddrclk;
+struct clk_init_data init;
+struct clk *clk;
+int ret;
+
+ddrclk = kzalloc(sizeof(*ddrclk), GFP_KERNEL);
+if (!ddrclk)
+return ERR_PTR(-ENOMEM);
+
+init.name = name;
+init.parent_names = parent_names;
+init.num_parents = num_parents;
+init.ops = _ddrclk_ops;
+
+init.flags = flags;
+

RE: [PATCH 1/2] usb: configfs: allow UDC binding rule configured as binding to *any* UDC

[Du, Changbin]

Thanks, Machek, This patch has already been dropped.

> On Tue 2016-05-03 11:04:24, changbin...@intel.com wrote:
> > From: "Du, Changbin" 
> >
> > On most platforms, there is only one device controller available.
> > In this case, we desn't care the UDC's name. So let's ignore the
> > name by setting 'UDC' to 'any'. And also we can change UDC name
> > at any time if it is not binded (no need set to "" first).
> 
> making "any" special does not look like a good idea. What if it really
> is "any"?
> 
> Return nothing instead, not even \n?
> 
> > Signed-off-by: Du, Changbin 
> > Signed-off-by: Du, Changbin 
> 
> I don't think this is how you should sign it off.
> 
> Best regards,
> 
>   Pavel
> 
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

RE: [PATCH 1/2] usb: configfs: allow UDC binding rule configured as binding to *any* UDC

[Du, Changbin]

Thanks, Machek, This patch has already been dropped.

> On Tue 2016-05-03 11:04:24, changbin...@intel.com wrote:
> > From: "Du, Changbin" 
> >
> > On most platforms, there is only one device controller available.
> > In this case, we desn't care the UDC's name. So let's ignore the
> > name by setting 'UDC' to 'any'. And also we can change UDC name
> > at any time if it is not binded (no need set to "" first).
> 
> making "any" special does not look like a good idea. What if it really
> is "any"?
> 
> Return nothing instead, not even \n?
> 
> > Signed-off-by: Du, Changbin 
> > Signed-off-by: Du, Changbin 
> 
> I don't think this is how you should sign it off.
> 
> Best regards,
> 
>   Pavel
> 
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH RESEND -trivial] init/Kconfig: Spelling s/compuation/computation/, double "the"

[Randy Dunlap]

On 06/05/16 01:47, Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven 
> ---
> Sent before on 2014-08-08.
> ---
>  init/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index f755a602d4a176e0..fa0ab926aa8a150a 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -851,7 +851,7 @@ config LOG_CPU_MAX_BUF_SHIFT
> used as it forces an exact (power of two) size of the ring buffer.
>  
> The number of possible CPUs is used for this computation ignoring
> -   hotplugging making the compuation optimal for the the worst case
> +   hotplugging making the computation optimal for the worst case
> scenerio while allowing a simple algorithm to be used from bootup.

  scenario

>  
> Examples shift values and their meaning:
> 


-- 
~Randy

Re: [PATCH RESEND -trivial] init/Kconfig: Spelling s/compuation/computation/, double "the"

[Randy Dunlap]

On 06/05/16 01:47, Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven 
> ---
> Sent before on 2014-08-08.
> ---
>  init/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index f755a602d4a176e0..fa0ab926aa8a150a 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -851,7 +851,7 @@ config LOG_CPU_MAX_BUF_SHIFT
> used as it forces an exact (power of two) size of the ring buffer.
>  
> The number of possible CPUs is used for this computation ignoring
> -   hotplugging making the compuation optimal for the the worst case
> +   hotplugging making the computation optimal for the worst case
> scenerio while allowing a simple algorithm to be used from bootup.

  scenario

>  
> Examples shift values and their meaning:
> 


-- 
~Randy

Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

[Peter Chen]

On Sun, Jun 05, 2016 at 04:46:55PM +0800, Lu Baolu wrote:
> Hi,
> 
> On 06/05/2016 04:33 PM, Jun Li wrote:
> >> Port mux is part of dual role switch, but not the whole thing.
> >> > 
> >> > Dual role switch includes at least below things:
> >> >  - ID or type-C event detection
> >> >  - port mux
> >> >  - VBUS management
> >> >  - start/stop host/device controllers
> >> > 
> >> > An OTG/Dual-role framework can be used to keep all these things run
> >> > together with an internal state machine. But it's not duplicated with a
> >> > generic framework for port mux and the port mux drivers.
> >> > 
> >>> > > Your
> >>> > > case is just like Renesas case, which uses two different drivers
> >>> > > between peripheral and host[1].
> >> > 
> >> > In my case, the port mux devices are physical devices and they can be
> >> > controlled through GPIO pins or device registers. They are independent of
> >> > both peripheral and host controllers.
> >> > 
> > I also think current OTG/Dual role framework can support your case, if you
> > find there is any limitation of it which can't meet your requirement, we
> > should improve it, Roger also provide an example of dual role switch with
> > USB3 based on his OTG core.
> 
> Why do we need an OTG framework to support a device driver?

Just like you said above, OTG framework can manage role switch, the
role switch may need to start or stop host/gadget driver according to
different hardware signals or user input.

> Is it something like a bus or class driver?

The DRD/OTG framework uses the same device structure with the caller,
the caller can be a dual-role controller driver (like dwc3, chipidea,
etc), or a separate switch driver which like your mux port driver.

-- 

Best Regards,
Peter Chen

Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

[Peter Chen]

On Sun, Jun 05, 2016 at 04:46:55PM +0800, Lu Baolu wrote:
> Hi,
> 
> On 06/05/2016 04:33 PM, Jun Li wrote:
> >> Port mux is part of dual role switch, but not the whole thing.
> >> > 
> >> > Dual role switch includes at least below things:
> >> >  - ID or type-C event detection
> >> >  - port mux
> >> >  - VBUS management
> >> >  - start/stop host/device controllers
> >> > 
> >> > An OTG/Dual-role framework can be used to keep all these things run
> >> > together with an internal state machine. But it's not duplicated with a
> >> > generic framework for port mux and the port mux drivers.
> >> > 
> >>> > > Your
> >>> > > case is just like Renesas case, which uses two different drivers
> >>> > > between peripheral and host[1].
> >> > 
> >> > In my case, the port mux devices are physical devices and they can be
> >> > controlled through GPIO pins or device registers. They are independent of
> >> > both peripheral and host controllers.
> >> > 
> > I also think current OTG/Dual role framework can support your case, if you
> > find there is any limitation of it which can't meet your requirement, we
> > should improve it, Roger also provide an example of dual role switch with
> > USB3 based on his OTG core.
> 
> Why do we need an OTG framework to support a device driver?

Just like you said above, OTG framework can manage role switch, the
role switch may need to start or stop host/gadget driver according to
different hardware signals or user input.

> Is it something like a bus or class driver?

The DRD/OTG framework uses the same device structure with the caller,
the caller can be a dual-role controller driver (like dwc3, chipidea,
etc), or a separate switch driver which like your mux port driver.

-- 

Best Regards,
Peter Chen

Re: [PATCH v3 5/5] arm64/numa: avoid inconsistent information to be printed

[Leizhen (ThunderTown)]

On 2016/6/3 17:55, Will Deacon wrote:
> On Thu, Jun 02, 2016 at 10:28:11AM +0800, Zhen Lei wrote:
>> numa_init(of_numa_init) may returned error because of numa configuration
>> error. So "No NUMA configuration found" is inaccurate. In fact, specific
>> configuration error information should be immediately printed by the
>> testing branch.
>>
>> Signed-off-by: Zhen Lei 
>> ---
>>  arch/arm64/mm/numa.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> Looks fine to me, but this doesn't apply against -rc1.

Oh,

These patched based on https://lkml.org/lkml/2016/5/24/679 series.

> 
> Will
> 
>> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
>> index 2601660..1b9622c 100644
>> --- a/arch/arm64/mm/numa.c
>> +++ b/arch/arm64/mm/numa.c
>> @@ -338,8 +338,10 @@ static int __init numa_init(int (*init_func)(void))
>>  if (ret < 0)
>>  return ret;
>>
>> -if (nodes_empty(numa_nodes_parsed))
>> +if (nodes_empty(numa_nodes_parsed)) {
>> +pr_info("No NUMA configuration found\n");
>>  return -EINVAL;
>> +}
>>
>>  ret = numa_register_nodes();
>>  if (ret < 0)
>> @@ -370,8 +372,6 @@ static int __init dummy_numa_init(void)
>>
>>  if (numa_off)
>>  pr_info("NUMA disabled\n"); /* Forced off on command line. */
>> -else
>> -pr_info("No NUMA configuration found\n");
>>  pr_info("NUMA: Faking a node at [mem %#018Lx-%#018Lx]\n",
>> 0LLU, PFN_PHYS(max_pfn) - 1);
>>
>> --
>> 2.5.0
>>
>>
> 
> .
> 

Re: [PATCH v3 5/5] arm64/numa: avoid inconsistent information to be printed

[Leizhen (ThunderTown)]

On 2016/6/3 17:55, Will Deacon wrote:
> On Thu, Jun 02, 2016 at 10:28:11AM +0800, Zhen Lei wrote:
>> numa_init(of_numa_init) may returned error because of numa configuration
>> error. So "No NUMA configuration found" is inaccurate. In fact, specific
>> configuration error information should be immediately printed by the
>> testing branch.
>>
>> Signed-off-by: Zhen Lei 
>> ---
>>  arch/arm64/mm/numa.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> Looks fine to me, but this doesn't apply against -rc1.

Oh,

These patched based on https://lkml.org/lkml/2016/5/24/679 series.

> 
> Will
> 
>> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
>> index 2601660..1b9622c 100644
>> --- a/arch/arm64/mm/numa.c
>> +++ b/arch/arm64/mm/numa.c
>> @@ -338,8 +338,10 @@ static int __init numa_init(int (*init_func)(void))
>>  if (ret < 0)
>>  return ret;
>>
>> -if (nodes_empty(numa_nodes_parsed))
>> +if (nodes_empty(numa_nodes_parsed)) {
>> +pr_info("No NUMA configuration found\n");
>>  return -EINVAL;
>> +}
>>
>>  ret = numa_register_nodes();
>>  if (ret < 0)
>> @@ -370,8 +372,6 @@ static int __init dummy_numa_init(void)
>>
>>  if (numa_off)
>>  pr_info("NUMA disabled\n"); /* Forced off on command line. */
>> -else
>> -pr_info("No NUMA configuration found\n");
>>  pr_info("NUMA: Faking a node at [mem %#018Lx-%#018Lx]\n",
>> 0LLU, PFN_PHYS(max_pfn) - 1);
>>
>> --
>> 2.5.0
>>
>>
> 
> .
> 

Re: [PATCH 1/3] perf/x86/intel: output LBR support statement after validation

[Andi Kleen]

> It is not because you force LBR to ring3 only that you do not capture
> kernel addresses in the FROM field.
> Keep in mind that LBR priv level filtering applies to the target of
> the branch and not the source. You might
> still get a kernel address if returning from kernel. Now, in callstack
> mode, I think the return branch is never
> actually recorded in the LBR, it just causes a pop, so theoretically
> this should not happen. I'd like to be
> 100% sure of that, though.

Far branches shouldn't be included in call stack LBR. Don't think
there is any other situation where the ring 0 address could leak either.

-Andi
-- 
a...@linux.intel.com -- Speaking for myself only

Re: [PATCH 1/3] perf/x86/intel: output LBR support statement after validation

[Andi Kleen]

> It is not because you force LBR to ring3 only that you do not capture
> kernel addresses in the FROM field.
> Keep in mind that LBR priv level filtering applies to the target of
> the branch and not the source. You might
> still get a kernel address if returning from kernel. Now, in callstack
> mode, I think the return branch is never
> actually recorded in the LBR, it just causes a pop, so theoretically
> this should not happen. I'd like to be
> 100% sure of that, though.

Far branches shouldn't be included in call stack LBR. Don't think
there is any other situation where the ring 0 address could leak either.

-Andi
-- 
a...@linux.intel.com -- Speaking for myself only

Re: linux-next: build warning after merge of the mmc-uh tree

[Shawn Lin]

Hi Stephen,

On 2016/6/6 9:38, Stephen Rothwell wrote:

Hi Ulf,

After merging the mmc-uh tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

In file included from include/linux/err.h:4:0,
 from drivers/mmc/core/mmc.c:13:
drivers/mmc/core/mmc.c: In function 'mmc_select_hs400es':
include/linux/err.h:21:49: warning: cast to pointer from integer of different 
size [-Wint-to-pointer-cast]
 #define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned 
long)-MAX_ERRNO)
 ^
include/linux/compiler.h:170:42: note: in definition of macro 'unlikely'
 # define unlikely(x) __builtin_expect(!!(x), 0)
  ^
drivers/mmc/core/mmc.c:1244:6: note: in expansion of macro 'IS_ERR_VALUE'
  if (IS_ERR_VALUE(err))
  ^


Yup, sorry for this noise. Arnd had removed a lot of IS_ERR_VALUE
abuses, but I forgot to amend this one.


Hi Ulf,

Should I come up with a new fix or you could manually amend it from
"IS_ERR_VALUE(err)" to "err < 0"? :)



Introduced by commit

  8141f0ace818 ("mmc: core: implement enhanced strobe support")

I think error values now must be "long".




--
Best Regards
Shawn Lin

Re: linux-next: build warning after merge of the mmc-uh tree

[Shawn Lin]

Hi Stephen,

On 2016/6/6 9:38, Stephen Rothwell wrote:

Hi Ulf,

After merging the mmc-uh tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

In file included from include/linux/err.h:4:0,
 from drivers/mmc/core/mmc.c:13:
drivers/mmc/core/mmc.c: In function 'mmc_select_hs400es':
include/linux/err.h:21:49: warning: cast to pointer from integer of different 
size [-Wint-to-pointer-cast]
 #define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned 
long)-MAX_ERRNO)
 ^
include/linux/compiler.h:170:42: note: in definition of macro 'unlikely'
 # define unlikely(x) __builtin_expect(!!(x), 0)
  ^
drivers/mmc/core/mmc.c:1244:6: note: in expansion of macro 'IS_ERR_VALUE'
  if (IS_ERR_VALUE(err))
  ^


Yup, sorry for this noise. Arnd had removed a lot of IS_ERR_VALUE
abuses, but I forgot to amend this one.


Hi Ulf,

Should I come up with a new fix or you could manually amend it from
"IS_ERR_VALUE(err)" to "err < 0"? :)



Introduced by commit

  8141f0ace818 ("mmc: core: implement enhanced strobe support")

I think error values now must be "long".




--
Best Regards
Shawn Lin

RE: ath9k gpio request

[Pan, Miaoqing]

Got it, thanks.  There is no difference of the changes for AR9462 which is the 
chip Sudip tested.

Thanks,
Miaoqing

-Original Message-
From: Kalle Valo [mailto:kv...@codeaurora.org] 
Sent: Saturday, June 04, 2016 10:38 PM
To: Pan, Miaoqing 
Cc: Sudip Mukherjee ; Stephen Rothwell 
; ath9k-devel ; 
linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; 
linux-wirel...@vger.kernel.org; ath9k-de...@lists.ath9k.org; 
net...@vger.kernel.org; Miaoqing Pan 
Subject: Re: ath9k gpio request

(Fixing top posting)

"Pan, Miaoqing"  writes:

>>> --- a/drivers/net/wireless/ath/ath9k/reg.h
>>> +++ b/drivers/net/wireless/ath/ath9k/reg.h
>>> @@ -1122,8 +1122,8 @@ enum {
>>>   #define AR9300_NUM_GPIO  16
>>>   #define AR9330_NUM_GPIO 16
>>>   #define AR9340_NUM_GPIO 23
>>> -#define AR9462_NUM_GPIO 10
>>> -#define AR9485_NUM_GPIO 12
>>> +#define AR9462_NUM_GPIO 14
>>> +#define AR9485_NUM_GPIO 11
>>>   #define AR9531_NUM_GPIO 18
>>>   #define AR9550_NUM_GPIO 24
>>>   #define AR9561_NUM_GPIO 23
>>> @@ -1139,8 +1139,8 @@ enum {
>>>   #define AR9300_GPIO_MASK0xF4FF
>>>   #define AR9330_GPIO_MASK0xF4FF
>>>   #define AR9340_GPIO_MASK0x000F
>>> -#define AR9462_GPIO_MASK0x03FF
>>> -#define AR9485_GPIO_MASK0x0FFF
>>> +#define AR9462_GPIO_MASK0x3FFF
>>> +#define AR9485_GPIO_MASK0x07FF
>>>   #define AR9531_GPIO_MASK0x000F
>>>   #define AR9550_GPIO_MASK0x000F
>>>   #define AR9561_GPIO_MASK0x000F
>>
>> solves the problem.
>>
>> Tested-by: Sudip Mukherjee 
>
> Done, https://patchwork.kernel.org/patch/9151847/

But the patch 9151847 is different from what Sudip tested above? Why?

And if you modify something _after_ the reporter has tested the patch clearly 
document what you changed and why. I do not want find hidden changes like this, 
even more so when the patch is going to a 4.7-rc release.

Sudip, could you also test patch 9151847, please? You can download the patch 
from the patchwork link above.

--
Kalle Valo

RE: ath9k gpio request

[Pan, Miaoqing]

Got it, thanks.  There is no difference of the changes for AR9462 which is the 
chip Sudip tested.

Thanks,
Miaoqing

-Original Message-
From: Kalle Valo [mailto:kv...@codeaurora.org] 
Sent: Saturday, June 04, 2016 10:38 PM
To: Pan, Miaoqing 
Cc: Sudip Mukherjee ; Stephen Rothwell 
; ath9k-devel ; 
linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; 
linux-wirel...@vger.kernel.org; ath9k-de...@lists.ath9k.org; 
net...@vger.kernel.org; Miaoqing Pan 
Subject: Re: ath9k gpio request

(Fixing top posting)

"Pan, Miaoqing"  writes:

>>> --- a/drivers/net/wireless/ath/ath9k/reg.h
>>> +++ b/drivers/net/wireless/ath/ath9k/reg.h
>>> @@ -1122,8 +1122,8 @@ enum {
>>>   #define AR9300_NUM_GPIO  16
>>>   #define AR9330_NUM_GPIO 16
>>>   #define AR9340_NUM_GPIO 23
>>> -#define AR9462_NUM_GPIO 10
>>> -#define AR9485_NUM_GPIO 12
>>> +#define AR9462_NUM_GPIO 14
>>> +#define AR9485_NUM_GPIO 11
>>>   #define AR9531_NUM_GPIO 18
>>>   #define AR9550_NUM_GPIO 24
>>>   #define AR9561_NUM_GPIO 23
>>> @@ -1139,8 +1139,8 @@ enum {
>>>   #define AR9300_GPIO_MASK0xF4FF
>>>   #define AR9330_GPIO_MASK0xF4FF
>>>   #define AR9340_GPIO_MASK0x000F
>>> -#define AR9462_GPIO_MASK0x03FF
>>> -#define AR9485_GPIO_MASK0x0FFF
>>> +#define AR9462_GPIO_MASK0x3FFF
>>> +#define AR9485_GPIO_MASK0x07FF
>>>   #define AR9531_GPIO_MASK0x000F
>>>   #define AR9550_GPIO_MASK0x000F
>>>   #define AR9561_GPIO_MASK0x000F
>>
>> solves the problem.
>>
>> Tested-by: Sudip Mukherjee 
>
> Done, https://patchwork.kernel.org/patch/9151847/

But the patch 9151847 is different from what Sudip tested above? Why?

And if you modify something _after_ the reporter has tested the patch clearly 
document what you changed and why. I do not want find hidden changes like this, 
even more so when the patch is going to a 4.7-rc release.

Sudip, could you also test patch 9151847, please? You can download the patch 
from the patchwork link above.

--
Kalle Valo

Re: [PATCH v3 3/5] arm64/numa: add nid check for memory block

[Leizhen (ThunderTown)]

On 2016/6/3 17:52, Will Deacon wrote:
> On Thu, Jun 02, 2016 at 10:28:09AM +0800, Zhen Lei wrote:
>> Use the same tactic to cpu and numa-distance nodes.
> 
> Sorry, I don't understand... :/

In function of_numa_parse_cpu_nodes:
for_each_child_of_node(cpus, np) {
...
r = of_property_read_u32(np, "numa-node-id", );
...
if (nid >= MAX_NUMNODES)
//check nid
pr_warn("NUMA: Node id %u exceeds maximum value\n", 
nid);   //print warning info
...


In function numa_set_distance:
if (from >= numa_distance_cnt || to >= numa_distance_cnt || 
//check nid
from < 0 || to < 0) {
pr_warn_once("NUMA: Warning: node ids are out of bound, from=%d 
to=%d distance=%d\n",   //print warning info
from, to, distance);
return;
}

Both these two functions will check that whether nid(configured in dts, the 
subnodes of
cpus and distance-map) is right or not. So memory@ should also be checked.


memory@c0 {
device_type = "memory";
reg = <0x0 0xc0 0x0 0x8000>;
/* node 0 */
numa-node-id = <0>; //have not been 
checked yet.
};  //suppose I 
configued a wrong nid, it will not print any warning info

cpus {
#address-cells = <2>;
#size-cells = <0>;

cpu@0 {
device_type = "cpu";
compatible =  "arm,armv8";
reg = <0x0 0x0>;
enable-method = "psci";
/* node 0 */
numa-node-id = <0>; //checked in 
of_numa_parse_cpu_nodes
};

distance-map {
compatible = "numa-distance-map-v1";
distance-matrix = <0 0 10>, //checked in 
of_numa_parse_distance_map_v1 --> numa_set_distance
  <0 1 20>,
  <1 1 10>;
};

> 
> Will
> 
>>
>> Signed-off-by: Zhen Lei 
>> ---
>>  arch/arm64/mm/numa.c | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
>> index c7fe3ec..2601660 100644
>> --- a/arch/arm64/mm/numa.c
>> +++ b/arch/arm64/mm/numa.c
>> @@ -141,6 +141,11 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
>>  {
>>  int ret;
>>
>> +if (nid >= MAX_NUMNODES) {
>> +pr_warn("NUMA: Node id %u exceeds maximum value\n", nid);
>> +return -EINVAL;
>> +}
>> +
>>  ret = memblock_set_node(start, (end - start), , nid);
>>  if (ret < 0) {
>>  pr_err("NUMA: memblock [0x%llx - 0x%llx] failed to add on node 
>> %d\n",
>> --
>> 2.5.0
>>
>>
> 
> .
> 

Re: [PATCH v3 3/5] arm64/numa: add nid check for memory block

[Leizhen (ThunderTown)]

On 2016/6/3 17:52, Will Deacon wrote:
> On Thu, Jun 02, 2016 at 10:28:09AM +0800, Zhen Lei wrote:
>> Use the same tactic to cpu and numa-distance nodes.
> 
> Sorry, I don't understand... :/

In function of_numa_parse_cpu_nodes:
for_each_child_of_node(cpus, np) {
...
r = of_property_read_u32(np, "numa-node-id", );
...
if (nid >= MAX_NUMNODES)
//check nid
pr_warn("NUMA: Node id %u exceeds maximum value\n", 
nid);   //print warning info
...


In function numa_set_distance:
if (from >= numa_distance_cnt || to >= numa_distance_cnt || 
//check nid
from < 0 || to < 0) {
pr_warn_once("NUMA: Warning: node ids are out of bound, from=%d 
to=%d distance=%d\n",   //print warning info
from, to, distance);
return;
}

Both these two functions will check that whether nid(configured in dts, the 
subnodes of
cpus and distance-map) is right or not. So memory@ should also be checked.


memory@c0 {
device_type = "memory";
reg = <0x0 0xc0 0x0 0x8000>;
/* node 0 */
numa-node-id = <0>; //have not been 
checked yet.
};  //suppose I 
configued a wrong nid, it will not print any warning info

cpus {
#address-cells = <2>;
#size-cells = <0>;

cpu@0 {
device_type = "cpu";
compatible =  "arm,armv8";
reg = <0x0 0x0>;
enable-method = "psci";
/* node 0 */
numa-node-id = <0>; //checked in 
of_numa_parse_cpu_nodes
};

distance-map {
compatible = "numa-distance-map-v1";
distance-matrix = <0 0 10>, //checked in 
of_numa_parse_distance_map_v1 --> numa_set_distance
  <0 1 20>,
  <1 1 10>;
};

> 
> Will
> 
>>
>> Signed-off-by: Zhen Lei 
>> ---
>>  arch/arm64/mm/numa.c | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
>> index c7fe3ec..2601660 100644
>> --- a/arch/arm64/mm/numa.c
>> +++ b/arch/arm64/mm/numa.c
>> @@ -141,6 +141,11 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
>>  {
>>  int ret;
>>
>> +if (nid >= MAX_NUMNODES) {
>> +pr_warn("NUMA: Node id %u exceeds maximum value\n", nid);
>> +return -EINVAL;
>> +}
>> +
>>  ret = memblock_set_node(start, (end - start), , nid);
>>  if (ret < 0) {
>>  pr_err("NUMA: memblock [0x%llx - 0x%llx] failed to add on node 
>> %d\n",
>> --
>> 2.5.0
>>
>>
> 
> .
> 

Re: [PATCH RFC v7 3/5] skb_array: array based FIFO for skbs

[Jason Wang]

On 2016年06月03日 21:04, Michael S. Tsirkin wrote:

On Fri, Jun 03, 2016 at 02:58:39PM +0200, Jesper Dangaard Brouer wrote:

>
>On Thu, 2 Jun 2016 19:08:26 +0300 "Michael S. Tsirkin"  wrote:
>

> >A simple array based FIFO of pointers.  Intended for net stack so uses
> >skbs for type safety. Implemented as a set of wrappers around ptr_array.

> ^
>It is called "ptr_ring" not "ptr_array".

Thanks!
Jason, could you please tweak this when you repost?



Sure, looks like Jesper has pointed out some other issues, want me to 
fix them too? Or you want to post new version yourself?


Thanks

Re: [PATCH RFC v7 3/5] skb_array: array based FIFO for skbs

[Jason Wang]

On 2016年06月03日 21:04, Michael S. Tsirkin wrote:

On Fri, Jun 03, 2016 at 02:58:39PM +0200, Jesper Dangaard Brouer wrote:

>
>On Thu, 2 Jun 2016 19:08:26 +0300 "Michael S. Tsirkin"  wrote:
>

> >A simple array based FIFO of pointers.  Intended for net stack so uses
> >skbs for type safety. Implemented as a set of wrappers around ptr_array.

> ^
>It is called "ptr_ring" not "ptr_array".

Thanks!
Jason, could you please tweak this when you repost?



Sure, looks like Jesper has pointed out some other issues, want me to 
fix them too? Or you want to post new version yourself?


Thanks

linux-next: build warning after merge of the mmc-uh tree

[Stephen Rothwell]

Hi Ulf,

After merging the mmc-uh tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

In file included from include/linux/err.h:4:0,
 from drivers/mmc/core/mmc.c:13:
drivers/mmc/core/mmc.c: In function 'mmc_select_hs400es':
include/linux/err.h:21:49: warning: cast to pointer from integer of different 
size [-Wint-to-pointer-cast]
 #define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned 
long)-MAX_ERRNO)
 ^
include/linux/compiler.h:170:42: note: in definition of macro 'unlikely'
 # define unlikely(x) __builtin_expect(!!(x), 0)
  ^
drivers/mmc/core/mmc.c:1244:6: note: in expansion of macro 'IS_ERR_VALUE'
  if (IS_ERR_VALUE(err))
  ^

Introduced by commit

  8141f0ace818 ("mmc: core: implement enhanced strobe support")

I think error values now must be "long".

-- 
Cheers,
Stephen Rothwell

linux-next: build warning after merge of the mmc-uh tree

[Stephen Rothwell]

Hi Ulf,

After merging the mmc-uh tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

In file included from include/linux/err.h:4:0,
 from drivers/mmc/core/mmc.c:13:
drivers/mmc/core/mmc.c: In function 'mmc_select_hs400es':
include/linux/err.h:21:49: warning: cast to pointer from integer of different 
size [-Wint-to-pointer-cast]
 #define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned 
long)-MAX_ERRNO)
 ^
include/linux/compiler.h:170:42: note: in definition of macro 'unlikely'
 # define unlikely(x) __builtin_expect(!!(x), 0)
  ^
drivers/mmc/core/mmc.c:1244:6: note: in expansion of macro 'IS_ERR_VALUE'
  if (IS_ERR_VALUE(err))
  ^

Introduced by commit

  8141f0ace818 ("mmc: core: implement enhanced strobe support")

I think error values now must be "long".

-- 
Cheers,
Stephen Rothwell

Re: [linux-sunxi] [PATCH 1/5] ethernet: add sun8i-emac driver

[Chen-Yu Tsai]

On Mon, Jun 6, 2016 at 6:32 AM, André Przywara  wrote:
> On 03/06/16 10:56, LABBE Corentin wrote:
>
> Hi,
>
> first: thanks for posting this and the time and work that you spent on
> it. With the respective DT nodes this works for me on the Pine64 and
> turns this board eventually into something useful.
>
> Some comments below:
>
>> This patch add support for sun8i-emac ethernet MAC hardware.
>> It could be found in Allwinner H3/A83T/A64 SoCs.
>>
>> It supports 10/100/1000 Mbit/s speed with half/full duplex.
>> It can use an internal PHY (MII 10/100) or an external PHY
>> via RGMII/RMII.
>>
>> Signed-off-by: LABBE Corentin 
>> ---
>>  drivers/net/ethernet/allwinner/Kconfig  |   13 +
>>  drivers/net/ethernet/allwinner/Makefile |1 +
>>  drivers/net/ethernet/allwinner/sun8i-emac.c | 1943 
>> +++
>>  3 files changed, 1957 insertions(+)
>>  create mode 100644 drivers/net/ethernet/allwinner/sun8i-emac.c
>>
>> diff --git a/drivers/net/ethernet/allwinner/Kconfig 
>> b/drivers/net/ethernet/allwinner/Kconfig
>> index 47da7e7..226499d 100644
>> --- a/drivers/net/ethernet/allwinner/Kconfig
>> +++ b/drivers/net/ethernet/allwinner/Kconfig
>> @@ -33,4 +33,17 @@ config SUN4I_EMAC
>>To compile this driver as a module, choose M here.  The module
>>will be called sun4i-emac.
>>
>> +config SUN8I_EMAC
>> +tristate "Allwinner sun8i EMAC support"
>
> nit: w/s error
>
>> + depends on ARCH_SUNXI || COMPILE_TEST
>> + depends on OF
>> + select MII
>> + select PHYLIB
>> +---help---
>> +   This driver support the sun8i EMAC ethernet driver present on
>> +   H3/A83T/A64 Allwinner SoCs.
>> +
>> +  To compile this driver as a module, choose M here.  The module
>> +  will be called sun8i-emac.
>> +
>>  endif # NET_VENDOR_ALLWINNER
>> diff --git a/drivers/net/ethernet/allwinner/Makefile 
>> b/drivers/net/ethernet/allwinner/Makefile
>> index 03129f7..8bd1693c 100644
>> --- a/drivers/net/ethernet/allwinner/Makefile
>> +++ b/drivers/net/ethernet/allwinner/Makefile
>> @@ -3,3 +3,4 @@
>>  #
>>
>>  obj-$(CONFIG_SUN4I_EMAC) += sun4i-emac.o
>> +obj-$(CONFIG_SUN8I_EMAC) += sun8i-emac.o
>> diff --git a/drivers/net/ethernet/allwinner/sun8i-emac.c 
>> b/drivers/net/ethernet/allwinner/sun8i-emac.c
>> new file mode 100644
>> index 000..179aa61
>> --- /dev/null
>> +++ b/drivers/net/ethernet/allwinner/sun8i-emac.c
>> @@ -0,0 +1,1943 @@
>> +/*
>> + * sun8i-emac driver
>> + *
>> + * Copyright (C) 2015-2016 Corentin LABBE 
>> + *
>> + * This is the driver for Allwinner Ethernet MAC found in H3/A83T/A64 SoC
>> + *
>> + * TODO:
>> + * - NAPI
>> + * - MAC filtering
>> + * - Jumbo frame
>> + * - features rx-all (NETIF_F_RXALL_BIT)
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define SUN8I_EMAC_BASIC_CTL0 0x00
>> +#define SUN8I_EMAC_BASIC_CTL1 0x04
>> +
>> +#define SUN8I_EMAC_MDIO_CMD 0x48
>> +#define SUN8I_EMAC_MDIO_DATA 0x4C
>
> Can you align all these register offsets with tabs, so that the actual
> offset values are below each other?
> Also ordering them by address seems useful to me.
>
>> +
>> +#define SUN8I_EMAC_RX_CTL0 0x24
>> +#define SUN8I_EMAC_RX_CTL1 0x28
>> +
>> +#define SUN8I_EMAC_TX_CTL0 0x10
>> +#define SUN8I_EMAC_TX_CTL1 0x14
>> +
>> +#define SUN8I_EMAC_TX_FLOW_CTL 0x1C
>> +
>> +#define SUN8I_EMAC_RX_FRM_FLT 0x38
>> +
>> +#define SUN8I_EMAC_INT_STA 0x08
>> +#define SUN8I_EMAC_INT_EN 0x0C
>> +#define SUN8I_EMAC_RGMII_STA 0xD0
>
>
>> +
>> +#define SUN8I_EMAC_TX_DMA_STA 0xB0
>> +#define SUN8I_EMAC_TX_CUR_DESC 0xB4
>> +#define SUN8I_EMAC_TX_CUR_BUF 0xB8
>> +#define SUN8I_EMAC_RX_DMA_STA 0xC0
>> +
>> +#define MDIO_CMD_MII_BUSYBIT(0)
>> +#define MDIO_CMD_MII_WRITE   BIT(1)
>> +#define MDIO_CMD_MII_PHY_REG_ADDR_MASK   GENMASK(8, 4)
>> +#define MDIO_CMD_MII_PHY_REG_ADDR_SHIFT  4
>> +#define MDIO_CMD_MII_PHY_ADDR_MASK   GENMASK(16, 12)
>> +#define MDIO_CMD_MII_PHY_ADDR_SHIFT  12
>> +
>> +#define SUN8I_EMAC_MACADDR_HI0x50
>> +#define SUN8I_EMAC_MACADDR_LO0x54
>> +
>> +#define SUN8I_EMAC_RX_DESC_LIST 0x34
>> +#define SUN8I_EMAC_TX_DESC_LIST 0x20
>> +
>> +#define SUN8I_EMAC_TX_DO_CRC (BIT(27) | BIT(28))
>> +#define SUN8I_EMAC_RX_DO_CRC BIT(27)
>> +#define SUN8I_EMAC_RX_STRIP_FCS BIT(28)
>> +
>> +#define SUN8I_COULD_BE_USED_BY_DMA BIT(31)
>> +
>> +#define FLOW_RX 1
>> +#define FLOW_TX 2
>> +
>> +/* describe how data from skb are DMA mapped */
>> +#define MAP_SINGLE 1
>> +#define MAP_PAGE 2
>> +
>> +enum emac_variant {
>> + A83T_EMAC,
>> + H3_EMAC,
>> + A64_EMAC,
>> +};
>> +
>> +struct ethtool_str {
>> + char name[ETH_GSTRING_LEN];
>> +};
>> +
>> +static const struct 

Re: [linux-sunxi] [PATCH 1/5] ethernet: add sun8i-emac driver

[Chen-Yu Tsai]

On Mon, Jun 6, 2016 at 6:32 AM, André Przywara  wrote:
> On 03/06/16 10:56, LABBE Corentin wrote:
>
> Hi,
>
> first: thanks for posting this and the time and work that you spent on
> it. With the respective DT nodes this works for me on the Pine64 and
> turns this board eventually into something useful.
>
> Some comments below:
>
>> This patch add support for sun8i-emac ethernet MAC hardware.
>> It could be found in Allwinner H3/A83T/A64 SoCs.
>>
>> It supports 10/100/1000 Mbit/s speed with half/full duplex.
>> It can use an internal PHY (MII 10/100) or an external PHY
>> via RGMII/RMII.
>>
>> Signed-off-by: LABBE Corentin 
>> ---
>>  drivers/net/ethernet/allwinner/Kconfig  |   13 +
>>  drivers/net/ethernet/allwinner/Makefile |1 +
>>  drivers/net/ethernet/allwinner/sun8i-emac.c | 1943 
>> +++
>>  3 files changed, 1957 insertions(+)
>>  create mode 100644 drivers/net/ethernet/allwinner/sun8i-emac.c
>>
>> diff --git a/drivers/net/ethernet/allwinner/Kconfig 
>> b/drivers/net/ethernet/allwinner/Kconfig
>> index 47da7e7..226499d 100644
>> --- a/drivers/net/ethernet/allwinner/Kconfig
>> +++ b/drivers/net/ethernet/allwinner/Kconfig
>> @@ -33,4 +33,17 @@ config SUN4I_EMAC
>>To compile this driver as a module, choose M here.  The module
>>will be called sun4i-emac.
>>
>> +config SUN8I_EMAC
>> +tristate "Allwinner sun8i EMAC support"
>
> nit: w/s error
>
>> + depends on ARCH_SUNXI || COMPILE_TEST
>> + depends on OF
>> + select MII
>> + select PHYLIB
>> +---help---
>> +   This driver support the sun8i EMAC ethernet driver present on
>> +   H3/A83T/A64 Allwinner SoCs.
>> +
>> +  To compile this driver as a module, choose M here.  The module
>> +  will be called sun8i-emac.
>> +
>>  endif # NET_VENDOR_ALLWINNER
>> diff --git a/drivers/net/ethernet/allwinner/Makefile 
>> b/drivers/net/ethernet/allwinner/Makefile
>> index 03129f7..8bd1693c 100644
>> --- a/drivers/net/ethernet/allwinner/Makefile
>> +++ b/drivers/net/ethernet/allwinner/Makefile
>> @@ -3,3 +3,4 @@
>>  #
>>
>>  obj-$(CONFIG_SUN4I_EMAC) += sun4i-emac.o
>> +obj-$(CONFIG_SUN8I_EMAC) += sun8i-emac.o
>> diff --git a/drivers/net/ethernet/allwinner/sun8i-emac.c 
>> b/drivers/net/ethernet/allwinner/sun8i-emac.c
>> new file mode 100644
>> index 000..179aa61
>> --- /dev/null
>> +++ b/drivers/net/ethernet/allwinner/sun8i-emac.c
>> @@ -0,0 +1,1943 @@
>> +/*
>> + * sun8i-emac driver
>> + *
>> + * Copyright (C) 2015-2016 Corentin LABBE 
>> + *
>> + * This is the driver for Allwinner Ethernet MAC found in H3/A83T/A64 SoC
>> + *
>> + * TODO:
>> + * - NAPI
>> + * - MAC filtering
>> + * - Jumbo frame
>> + * - features rx-all (NETIF_F_RXALL_BIT)
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define SUN8I_EMAC_BASIC_CTL0 0x00
>> +#define SUN8I_EMAC_BASIC_CTL1 0x04
>> +
>> +#define SUN8I_EMAC_MDIO_CMD 0x48
>> +#define SUN8I_EMAC_MDIO_DATA 0x4C
>
> Can you align all these register offsets with tabs, so that the actual
> offset values are below each other?
> Also ordering them by address seems useful to me.
>
>> +
>> +#define SUN8I_EMAC_RX_CTL0 0x24
>> +#define SUN8I_EMAC_RX_CTL1 0x28
>> +
>> +#define SUN8I_EMAC_TX_CTL0 0x10
>> +#define SUN8I_EMAC_TX_CTL1 0x14
>> +
>> +#define SUN8I_EMAC_TX_FLOW_CTL 0x1C
>> +
>> +#define SUN8I_EMAC_RX_FRM_FLT 0x38
>> +
>> +#define SUN8I_EMAC_INT_STA 0x08
>> +#define SUN8I_EMAC_INT_EN 0x0C
>> +#define SUN8I_EMAC_RGMII_STA 0xD0
>
>
>> +
>> +#define SUN8I_EMAC_TX_DMA_STA 0xB0
>> +#define SUN8I_EMAC_TX_CUR_DESC 0xB4
>> +#define SUN8I_EMAC_TX_CUR_BUF 0xB8
>> +#define SUN8I_EMAC_RX_DMA_STA 0xC0
>> +
>> +#define MDIO_CMD_MII_BUSYBIT(0)
>> +#define MDIO_CMD_MII_WRITE   BIT(1)
>> +#define MDIO_CMD_MII_PHY_REG_ADDR_MASK   GENMASK(8, 4)
>> +#define MDIO_CMD_MII_PHY_REG_ADDR_SHIFT  4
>> +#define MDIO_CMD_MII_PHY_ADDR_MASK   GENMASK(16, 12)
>> +#define MDIO_CMD_MII_PHY_ADDR_SHIFT  12
>> +
>> +#define SUN8I_EMAC_MACADDR_HI0x50
>> +#define SUN8I_EMAC_MACADDR_LO0x54
>> +
>> +#define SUN8I_EMAC_RX_DESC_LIST 0x34
>> +#define SUN8I_EMAC_TX_DESC_LIST 0x20
>> +
>> +#define SUN8I_EMAC_TX_DO_CRC (BIT(27) | BIT(28))
>> +#define SUN8I_EMAC_RX_DO_CRC BIT(27)
>> +#define SUN8I_EMAC_RX_STRIP_FCS BIT(28)
>> +
>> +#define SUN8I_COULD_BE_USED_BY_DMA BIT(31)
>> +
>> +#define FLOW_RX 1
>> +#define FLOW_TX 2
>> +
>> +/* describe how data from skb are DMA mapped */
>> +#define MAP_SINGLE 1
>> +#define MAP_PAGE 2
>> +
>> +enum emac_variant {
>> + A83T_EMAC,
>> + H3_EMAC,
>> + A64_EMAC,
>> +};
>> +
>> +struct ethtool_str {
>> + char name[ETH_GSTRING_LEN];
>> +};
>> +
>> +static const struct ethtool_str estats_str[] = {
>> + /* errors */
>> + { "rx_payload_error" },
>> 

Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

[Peter Chen]

On Sun, Jun 05, 2016 at 02:55:56PM +0800, Lu Baolu wrote:
> Hi Peter,
> 
> On 06/04/2016 10:28 AM, Peter Chen wrote:
> > On Sat, Jun 04, 2016 at 12:06:06AM +0800, Lu Baolu wrote:
> >>> from my point,it is a dual-role switch
> >>> driver too,
> >> No, it's not a dual-role switch driver, but a driver for USB port 
> >> multiplexing.
> >>
> >> One example of port multiplexing can be found in several Intel SOC and PCH
> >> chips, inside of which, there are two independent USB controllers: host and
> >> device. They might share a single port and this port could be configured to
> >> route the line to one of these two controllers. This patch introduced a 
> >> generic
> >> framework for port mux drivers. It aids the drivers to handle port mux by
> >> providing interfaces to 1) register/unregister a mux device; 2) lookup the
> >> mux device; and 3) switch the port.
> >>
> > For this case, I can't see it is different with dual-role switch.
> 
> Port mux is part of dual role switch, but not the whole thing.
> 
> Dual role switch includes at least below things:
>  - ID or type-C event detection
>  - port mux
>  - VBUS management
>  - start/stop host/device controllers
> 
> An OTG/Dual-role framework can be used to keep all these
> things run together with an internal state machine. But it's
> not duplicated with a generic framework for port mux and
> the port mux drivers.

You have admitted port mux is one of the ports of dual-role switch,
Then, how they can co-work with each other? If can't, the dual-role
switch framework needs another input events management for switching.

> 
> > Your
> > case is just like Renesas case, which uses two different drivers between
> > peripheral and host[1].
> 
> In my case, the port mux devices are physical devices and they
> can be controlled through GPIO pins or device registers. They
> are independent of both peripheral and host controllers.
> 

Yes, it is the same. GPIO pin or device registers is like ID pin
event.

> 
> >> Port multiplexing isn't equal to USB dual role. There are other cases in 
> >> today's
> >> systems. In several Intel PCH chips, there equips two USB host 
> >> controllers: ehci
> >> and xhci. The xhci USB2 ports are multiplexed with ehci. This guarantees 
> >> all
> >> USB ports work even running an old version of OS which lacks of USB3 
> >> support.
> >> In theory, we can create a driver for the port mux and switch the ports 
> >> between
> >> xhci and ehci, but that's silly, isn't it? Why not always USB3?:-)
> >>
> >> Another case is xHCI debug capability. The xHCI host controller might equip
> >> a unit for system debugging (refer to 7.6 of xHCI spec). The debugging 
> >> unit is
> >> independent of xhci host controller. But it shares its port with xhci. 
> >> Software
> >> could switch the port between xhci and the debugging unit through the 
> >> registers
> >> defined in xHCI spec.
> >>
> > Yes, above two are different with dual role switch. But in your code and
> > Kconfig, it seems this framework is dedicated for dual-role. Eg:
> >
> > +menuconfig USB_PORTMUX
> > +   bool "USB dual role port MUX support"
> > +   help
> > + Generic USB dual role port mux support.
> 
> Above two cases are examples for port multiplexing, but I don't think we
> need drivers for them. At this moment, this framework is only for dual
> role port mux devices.
> 
> >
> > I think a general dual role port mux is necessary, it can be used to
> > manage different dual-role switch method, eg
> 
> Yes, I agree.
> 
> > - ID pin
> > - External connector through GPIO
> > - SoC register
> > - sysfs
> > - type-C events
> 
> ID pin and type-C events are the *reasons* which trigger the port
> mux switch. Currently, on our platforms, gpio, registers and sysfs
> are methods to control the mux.
> 
> >
> > But this code is better co-work with OTG/Dual-role framework, we'd
> > better have only interface that the user can know which role for the
> > current port.
> 
> OTG/Dual-role framework and portmux framework are not overlapped.
> The sysfs interface shouldn't be overlapped as well. Say, I have a port
> mux device and I have a driver for it. I am able to read the status of my
> port mux device through sysfs. This is not part of OTG/Dual-role as far
> as I can see.
> 

Then how the user wants to switch the role through the mux driver's
sysfs or dual-role switch sysfs?

-- 

Best Regards,
Peter Chen

Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

[Peter Chen]

On Sun, Jun 05, 2016 at 02:55:56PM +0800, Lu Baolu wrote:
> Hi Peter,
> 
> On 06/04/2016 10:28 AM, Peter Chen wrote:
> > On Sat, Jun 04, 2016 at 12:06:06AM +0800, Lu Baolu wrote:
> >>> from my point,it is a dual-role switch
> >>> driver too,
> >> No, it's not a dual-role switch driver, but a driver for USB port 
> >> multiplexing.
> >>
> >> One example of port multiplexing can be found in several Intel SOC and PCH
> >> chips, inside of which, there are two independent USB controllers: host and
> >> device. They might share a single port and this port could be configured to
> >> route the line to one of these two controllers. This patch introduced a 
> >> generic
> >> framework for port mux drivers. It aids the drivers to handle port mux by
> >> providing interfaces to 1) register/unregister a mux device; 2) lookup the
> >> mux device; and 3) switch the port.
> >>
> > For this case, I can't see it is different with dual-role switch.
> 
> Port mux is part of dual role switch, but not the whole thing.
> 
> Dual role switch includes at least below things:
>  - ID or type-C event detection
>  - port mux
>  - VBUS management
>  - start/stop host/device controllers
> 
> An OTG/Dual-role framework can be used to keep all these
> things run together with an internal state machine. But it's
> not duplicated with a generic framework for port mux and
> the port mux drivers.

You have admitted port mux is one of the ports of dual-role switch,
Then, how they can co-work with each other? If can't, the dual-role
switch framework needs another input events management for switching.

> 
> > Your
> > case is just like Renesas case, which uses two different drivers between
> > peripheral and host[1].
> 
> In my case, the port mux devices are physical devices and they
> can be controlled through GPIO pins or device registers. They
> are independent of both peripheral and host controllers.
> 

Yes, it is the same. GPIO pin or device registers is like ID pin
event.

> 
> >> Port multiplexing isn't equal to USB dual role. There are other cases in 
> >> today's
> >> systems. In several Intel PCH chips, there equips two USB host 
> >> controllers: ehci
> >> and xhci. The xhci USB2 ports are multiplexed with ehci. This guarantees 
> >> all
> >> USB ports work even running an old version of OS which lacks of USB3 
> >> support.
> >> In theory, we can create a driver for the port mux and switch the ports 
> >> between
> >> xhci and ehci, but that's silly, isn't it? Why not always USB3?:-)
> >>
> >> Another case is xHCI debug capability. The xHCI host controller might equip
> >> a unit for system debugging (refer to 7.6 of xHCI spec). The debugging 
> >> unit is
> >> independent of xhci host controller. But it shares its port with xhci. 
> >> Software
> >> could switch the port between xhci and the debugging unit through the 
> >> registers
> >> defined in xHCI spec.
> >>
> > Yes, above two are different with dual role switch. But in your code and
> > Kconfig, it seems this framework is dedicated for dual-role. Eg:
> >
> > +menuconfig USB_PORTMUX
> > +   bool "USB dual role port MUX support"
> > +   help
> > + Generic USB dual role port mux support.
> 
> Above two cases are examples for port multiplexing, but I don't think we
> need drivers for them. At this moment, this framework is only for dual
> role port mux devices.
> 
> >
> > I think a general dual role port mux is necessary, it can be used to
> > manage different dual-role switch method, eg
> 
> Yes, I agree.
> 
> > - ID pin
> > - External connector through GPIO
> > - SoC register
> > - sysfs
> > - type-C events
> 
> ID pin and type-C events are the *reasons* which trigger the port
> mux switch. Currently, on our platforms, gpio, registers and sysfs
> are methods to control the mux.
> 
> >
> > But this code is better co-work with OTG/Dual-role framework, we'd
> > better have only interface that the user can know which role for the
> > current port.
> 
> OTG/Dual-role framework and portmux framework are not overlapped.
> The sysfs interface shouldn't be overlapped as well. Say, I have a port
> mux device and I have a driver for it. I am able to read the status of my
> port mux device through sysfs. This is not part of OTG/Dual-role as far
> as I can see.
> 

Then how the user wants to switch the role through the mux driver's
sysfs or dual-role switch sysfs?

-- 

Best Regards,
Peter Chen

Re: [PATCH v3 0/5] MT2701 iommu support

[Honghui Zhang]

On Fri, 2016-05-27 at 16:56 +0800, honghui.zh...@mediatek.com wrote:
> From: Honghui Zhang 
> 

Is there will be some comments for this version patchset?
Any comments is welcome.
Thanks.

>   Mediatek's m4u(Multimedia Memory Management Unit) and SMI(Smart
> Multimedia Interface)have two generations HW. They basically sharing the
> same hardware block diagram, but have some difference as below:
> 
>   Generation one m4u only supports one layer, flat pagetable addressing,
> and only supports 4K size page mapping. While generation two m4u supports 2
> levels of pagetable which uses the ARM short-descriptor translation table
> format for address translation.
> They have slight different register base and register offset.
> They have very different HW ports defines.
> 
>   Generaion one SMI has additional "async" clock which transform the smi
> clock into emi clock domain, this clock should be prepared and enabled for
> SMI generation one HW.
> The register which control the iommu need to translation the address or not
> for a particular port is located at smi ao base(smi always on register
> base) for generation one SMI HW, but located at each larb's register base
> for generation two HW.
> 
> This patch set add mt2701 iommu support, it's based on 4.6-rc1 and James
> Liao's "Add clock support for Mediatek MT2701 v8[1]" and "Mediatek MT2701
> SCPSYS power domain support v7[2]" patch.
> 
> v3:
> -Rebase on "of: Implement iterator for phandles[3]" and take use of
>  of_for_each_phandle.
> -Forward-declare mtk_iommu_domain and implement the struct separately.
> -Free the pagetable memory in mtk_iommu_domain_free
> -Roll back the mapping in error case.
> -Minor cleanups.
> 
> v2: https://lists.linuxfoundation.org/pipermail/iommu/2016-May/017068.html
> -Fix syntax errors in dt-bindings.
> -Use dma_alloc/free_coherent to allocate pagetable memory and reduce the
>  streaming DMA stuff.
> -Make the mtk_iommu_ops.pgsize_bitmap as ~0UL << MT2701_IOMMU_PAGE_SHIFT.
> -Use macro instead of variable to indicate the pagetable size.
> -Change some macro name from MTK_XXX to MT2701_XXX.
> 
> v1: http://lists.infradead.org/pipermail/linux-mediatek/2016-May/005301.html
> -initial version
> 
> [1] http://lists.infradead.org/pipermail/linux-mediatek/2016-May/005439.html
> [2] http://lists.infradead.org/pipermail/linux-mediatek/2016-May/005429.html
> [3] https://lists.linuxfoundation.org/pipermail/iommu/2016-April/016300.html
> 
> Honghui Zhang (5):
>   dt-bindings: mediatek: add descriptions for mediatek mt2701 iommu and
> smi
>   iommu/mediatek: move the common struct into header file
>   memory/mediatek: add support for mt2701
>   iommu/mediatek: add support for mtk iommu generation one HW
>   ARM: dts: mt2701: add iommu/smi dtsi node for mt2701
> 
>  .../devicetree/bindings/iommu/mediatek,iommu.txt   |  13 +-
>  .../memory-controllers/mediatek,smi-common.txt |  21 +-
>  .../memory-controllers/mediatek,smi-larb.txt   |   4 +-
>  arch/arm/boot/dts/mt2701.dtsi  |  51 ++
>  drivers/iommu/Kconfig  |  18 +
>  drivers/iommu/Makefile |   1 +
>  drivers/iommu/mtk_iommu.c  |  48 +-
>  drivers/iommu/mtk_iommu.h  |  77 +++
>  drivers/iommu/mtk_iommu_v1.c   | 728 
> +
>  drivers/memory/mtk-smi.c   | 168 -
>  include/dt-bindings/memory/mt2701-larb-port.h  |  85 +++
>  11 files changed, 1140 insertions(+), 74 deletions(-)
>  create mode 100644 drivers/iommu/mtk_iommu.h
>  create mode 100644 drivers/iommu/mtk_iommu_v1.c
>  create mode 100644 include/dt-bindings/memory/mt2701-larb-port.h
> 

Re: [PATCH v3 0/5] MT2701 iommu support

[Honghui Zhang]

On Fri, 2016-05-27 at 16:56 +0800, honghui.zh...@mediatek.com wrote:
> From: Honghui Zhang 
> 

Is there will be some comments for this version patchset?
Any comments is welcome.
Thanks.

>   Mediatek's m4u(Multimedia Memory Management Unit) and SMI(Smart
> Multimedia Interface)have two generations HW. They basically sharing the
> same hardware block diagram, but have some difference as below:
> 
>   Generation one m4u only supports one layer, flat pagetable addressing,
> and only supports 4K size page mapping. While generation two m4u supports 2
> levels of pagetable which uses the ARM short-descriptor translation table
> format for address translation.
> They have slight different register base and register offset.
> They have very different HW ports defines.
> 
>   Generaion one SMI has additional "async" clock which transform the smi
> clock into emi clock domain, this clock should be prepared and enabled for
> SMI generation one HW.
> The register which control the iommu need to translation the address or not
> for a particular port is located at smi ao base(smi always on register
> base) for generation one SMI HW, but located at each larb's register base
> for generation two HW.
> 
> This patch set add mt2701 iommu support, it's based on 4.6-rc1 and James
> Liao's "Add clock support for Mediatek MT2701 v8[1]" and "Mediatek MT2701
> SCPSYS power domain support v7[2]" patch.
> 
> v3:
> -Rebase on "of: Implement iterator for phandles[3]" and take use of
>  of_for_each_phandle.
> -Forward-declare mtk_iommu_domain and implement the struct separately.
> -Free the pagetable memory in mtk_iommu_domain_free
> -Roll back the mapping in error case.
> -Minor cleanups.
> 
> v2: https://lists.linuxfoundation.org/pipermail/iommu/2016-May/017068.html
> -Fix syntax errors in dt-bindings.
> -Use dma_alloc/free_coherent to allocate pagetable memory and reduce the
>  streaming DMA stuff.
> -Make the mtk_iommu_ops.pgsize_bitmap as ~0UL << MT2701_IOMMU_PAGE_SHIFT.
> -Use macro instead of variable to indicate the pagetable size.
> -Change some macro name from MTK_XXX to MT2701_XXX.
> 
> v1: http://lists.infradead.org/pipermail/linux-mediatek/2016-May/005301.html
> -initial version
> 
> [1] http://lists.infradead.org/pipermail/linux-mediatek/2016-May/005439.html
> [2] http://lists.infradead.org/pipermail/linux-mediatek/2016-May/005429.html
> [3] https://lists.linuxfoundation.org/pipermail/iommu/2016-April/016300.html
> 
> Honghui Zhang (5):
>   dt-bindings: mediatek: add descriptions for mediatek mt2701 iommu and
> smi
>   iommu/mediatek: move the common struct into header file
>   memory/mediatek: add support for mt2701
>   iommu/mediatek: add support for mtk iommu generation one HW
>   ARM: dts: mt2701: add iommu/smi dtsi node for mt2701
> 
>  .../devicetree/bindings/iommu/mediatek,iommu.txt   |  13 +-
>  .../memory-controllers/mediatek,smi-common.txt |  21 +-
>  .../memory-controllers/mediatek,smi-larb.txt   |   4 +-
>  arch/arm/boot/dts/mt2701.dtsi  |  51 ++
>  drivers/iommu/Kconfig  |  18 +
>  drivers/iommu/Makefile |   1 +
>  drivers/iommu/mtk_iommu.c  |  48 +-
>  drivers/iommu/mtk_iommu.h  |  77 +++
>  drivers/iommu/mtk_iommu_v1.c   | 728 
> +
>  drivers/memory/mtk-smi.c   | 168 -
>  include/dt-bindings/memory/mt2701-larb-port.h  |  85 +++
>  11 files changed, 1140 insertions(+), 74 deletions(-)
>  create mode 100644 drivers/iommu/mtk_iommu.h
>  create mode 100644 drivers/iommu/mtk_iommu_v1.c
>  create mode 100644 include/dt-bindings/memory/mt2701-larb-port.h
> 

Various Articles on GRSecurity, RMS, etc.

[concernedfossdev]

Soylent news published an article/discussion on GRSecurity, RMS, etc
If you're interested it's here:
https://soylentnews.org/article.pl?sid=16/06/02/214243

> RMS Responds - GRsecurity is Preventing Others From Redistributing Source 
> Code [UPDATED]

Other discussions and articles on the topic, some including legal debates, if 
you are interested:
https://lists.gnu.org/archive/html/libreplanet-discuss/2016-05/msg00114.html
https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2016-June/016589.html
https://news.ycombinator.com/item?id=11808914
https://www.reddit.com/r/linux/comments/4m6mm5/libreplanetdiscuss_grsecurity_is_preventing/
https://sys.8ch.net/tech/res/605120.html
http://boards.4chan.org/g/thread/54839391
http://endchan.xyz/tech/res/4339.html
http://lwn.net/Articles/689385/

Various Articles on GRSecurity, RMS, etc.

[concernedfossdev]

Soylent news published an article/discussion on GRSecurity, RMS, etc
If you're interested it's here:
https://soylentnews.org/article.pl?sid=16/06/02/214243

> RMS Responds - GRsecurity is Preventing Others From Redistributing Source 
> Code [UPDATED]

Other discussions and articles on the topic, some including legal debates, if 
you are interested:
https://lists.gnu.org/archive/html/libreplanet-discuss/2016-05/msg00114.html
https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2016-June/016589.html
https://news.ycombinator.com/item?id=11808914
https://www.reddit.com/r/linux/comments/4m6mm5/libreplanetdiscuss_grsecurity_is_preventing/
https://sys.8ch.net/tech/res/605120.html
http://boards.4chan.org/g/thread/54839391
http://endchan.xyz/tech/res/4339.html
http://lwn.net/Articles/689385/

Re: [PATCH v2 2/5] of/numa: fix a memory@ node can only contains one memory block

[Leizhen (ThunderTown)]

On 2016/6/3 17:45, Will Deacon wrote:
> On Thu, Jun 02, 2016 at 09:36:40AM +0800, Leizhen (ThunderTown) wrote:
>> On 2016/6/2 4:13, Rob Herring wrote:
>>> I believe you still need this and not the one above. You only need it
>>> within the loop if you return. Otherwise, the last node always need to
>>> be put.
>>
>> OK. Thanks.
>>
>> Addition with Matthias's suggestion, I will move "return" into this patch,
>> so that this of_node_put(np) can be safely removed.
> 
> Do you want to include Kefeng's [1] patches in your series too? We don't
> need two sets of related NUMA cleanups :)

Yes, It's originally suggested by Joe Perches.

> 
> Will
> 
> [1] 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-June/432715.html
> 
> .
> 

Re: [PATCH v2 2/5] of/numa: fix a memory@ node can only contains one memory block

[Leizhen (ThunderTown)]

On 2016/6/3 17:45, Will Deacon wrote:
> On Thu, Jun 02, 2016 at 09:36:40AM +0800, Leizhen (ThunderTown) wrote:
>> On 2016/6/2 4:13, Rob Herring wrote:
>>> I believe you still need this and not the one above. You only need it
>>> within the loop if you return. Otherwise, the last node always need to
>>> be put.
>>
>> OK. Thanks.
>>
>> Addition with Matthias's suggestion, I will move "return" into this patch,
>> so that this of_node_put(np) can be safely removed.
> 
> Do you want to include Kefeng's [1] patches in your series too? We don't
> need two sets of related NUMA cleanups :)

Yes, It's originally suggested by Joe Perches.

> 
> Will
> 
> [1] 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-June/432715.html
> 
> .
> 

Re: [alsa-devel] [PATCH] ASoC: sgtl5000: only check VDDD-supply, not revision

[Fabio Estevam]

Hi Clemens,

On Sun, Jun 5, 2016 at 8:16 PM, Clemens Gruber
 wrote:

> I looked into this today and discovered the following:
>
> With my patch applied, if I reset the board just after playback, at the
> next boot, the sgtl5000_fill_defaults function does not succeed: Writing
> the default value 0x7060 to register 0x30 (CHIP_ANA_POWER) fails.
>
> How did CHIP_ANA_POWER change with my patch: Before, only
> LINREG_SIMPLE_POWERUP was cleared as is recommended in the datasheet
> when using the internal LDO, now both LINREG_SIMPLE_POWERUP and
> STARTUP_POWERUP are cleared, as is recommended when using external VDDD.
>
> But why does the SGTL5000 nack that default write to CHIP_ANA_POWER
> after a reboot, which interrupted the playback?
>
> The following patch from Eric solved the problem; one write fails but it
> continues setting the other registers and thus even if resetting a board
> during playback, the sound still works after reboot:
> http://mailman.alsa-project.org/pipermail/alsa-devel/2015-February/088356.html
> Another workaround might be to not even write a default value to
> CHIP_ANA_POWER, as in this patch from Eric:
> http://mailman.alsa-project.org/pipermail/alsa-devel/2015-February/088355.html
>
> What do you think we should do?

Shouldn't both patches be applied?

Re: [alsa-devel] [PATCH] ASoC: sgtl5000: only check VDDD-supply, not revision

[Fabio Estevam]

Hi Clemens,

On Sun, Jun 5, 2016 at 8:16 PM, Clemens Gruber
 wrote:

> I looked into this today and discovered the following:
>
> With my patch applied, if I reset the board just after playback, at the
> next boot, the sgtl5000_fill_defaults function does not succeed: Writing
> the default value 0x7060 to register 0x30 (CHIP_ANA_POWER) fails.
>
> How did CHIP_ANA_POWER change with my patch: Before, only
> LINREG_SIMPLE_POWERUP was cleared as is recommended in the datasheet
> when using the internal LDO, now both LINREG_SIMPLE_POWERUP and
> STARTUP_POWERUP are cleared, as is recommended when using external VDDD.
>
> But why does the SGTL5000 nack that default write to CHIP_ANA_POWER
> after a reboot, which interrupted the playback?
>
> The following patch from Eric solved the problem; one write fails but it
> continues setting the other registers and thus even if resetting a board
> during playback, the sound still works after reboot:
> http://mailman.alsa-project.org/pipermail/alsa-devel/2015-February/088356.html
> Another workaround might be to not even write a default value to
> CHIP_ANA_POWER, as in this patch from Eric:
> http://mailman.alsa-project.org/pipermail/alsa-devel/2015-February/088355.html
>
> What do you think we should do?

Shouldn't both patches be applied?

RE: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

[Jun Li]

> -Original Message-
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Sunday, June 05, 2016 4:47 PM
> To: Jun Li ; Peter Chen 
> Cc: felipe.ba...@linux.intel.com; Mathias Nyman ;
> Greg Kroah-Hartman ; Lee Jones
> ; Heikki Krogerus ;
> Liam Girdwood ; Mark Brown ;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Roger Quadros
> 
> Subject: Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port
> mux
> 
> Hi,
> 
> On 06/05/2016 04:33 PM, Jun Li wrote:
> >> Port mux is part of dual role switch, but not the whole thing.
> >> >
> >> > Dual role switch includes at least below things:
> >> >  - ID or type-C event detection
> >> >  - port mux
> >> >  - VBUS management
> >> >  - start/stop host/device controllers
> >> >
> >> > An OTG/Dual-role framework can be used to keep all these things run
> >> > together with an internal state machine. But it's not duplicated
> >> > with a generic framework for port mux and the port mux drivers.
> >> >
> >>> > > Your
> >>> > > case is just like Renesas case, which uses two different drivers
> >>> > > between peripheral and host[1].
> >> >
> >> > In my case, the port mux devices are physical devices and they can
> >> > be controlled through GPIO pins or device registers. They are
> >> > independent of both peripheral and host controllers.
> >> >
> > I also think current OTG/Dual role framework can support your case, if
> > you find there is any limitation of it which can't meet your
> > requirement, we should improve it, Roger also provide an example of
> > dual role switch with
> > USB3 based on his OTG core.
> 
> Why do we need an OTG framework to support a device driver?

Currently there are many controller drivers which are dual role
capable, all has its specific approach/implementation, your case
is another one, actually there are common part we can share and
reuse, Roger is introducing a common framework which cooperates
into usb core and udc-core. With that, each OTG/dual role user
only need take care of its small specific part.
  
> Is it something like a bus or class driver?

It's not actually a driver, instead, it's more like a lib or
helper routines. You just need register your host and gadget
into OTG core, and define the ops routines if required, OTG state
machine will help you do the switch.

Li Jun
 
> 
> Best regards,
> Lu Baolu

RE: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

[Jun Li]

> -Original Message-
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Sunday, June 05, 2016 4:47 PM
> To: Jun Li ; Peter Chen 
> Cc: felipe.ba...@linux.intel.com; Mathias Nyman ;
> Greg Kroah-Hartman ; Lee Jones
> ; Heikki Krogerus ;
> Liam Girdwood ; Mark Brown ;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Roger Quadros
> 
> Subject: Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port
> mux
> 
> Hi,
> 
> On 06/05/2016 04:33 PM, Jun Li wrote:
> >> Port mux is part of dual role switch, but not the whole thing.
> >> >
> >> > Dual role switch includes at least below things:
> >> >  - ID or type-C event detection
> >> >  - port mux
> >> >  - VBUS management
> >> >  - start/stop host/device controllers
> >> >
> >> > An OTG/Dual-role framework can be used to keep all these things run
> >> > together with an internal state machine. But it's not duplicated
> >> > with a generic framework for port mux and the port mux drivers.
> >> >
> >>> > > Your
> >>> > > case is just like Renesas case, which uses two different drivers
> >>> > > between peripheral and host[1].
> >> >
> >> > In my case, the port mux devices are physical devices and they can
> >> > be controlled through GPIO pins or device registers. They are
> >> > independent of both peripheral and host controllers.
> >> >
> > I also think current OTG/Dual role framework can support your case, if
> > you find there is any limitation of it which can't meet your
> > requirement, we should improve it, Roger also provide an example of
> > dual role switch with
> > USB3 based on his OTG core.
> 
> Why do we need an OTG framework to support a device driver?

Currently there are many controller drivers which are dual role
capable, all has its specific approach/implementation, your case
is another one, actually there are common part we can share and
reuse, Roger is introducing a common framework which cooperates
into usb core and udc-core. With that, each OTG/dual role user
only need take care of its small specific part.
  
> Is it something like a bus or class driver?

It's not actually a driver, instead, it's more like a lib or
helper routines. You just need register your host and gadget
into OTG core, and define the ops routines if required, OTG state
machine will help you do the switch.

Li Jun
 
> 
> Best regards,
> Lu Baolu

Re: [PATCH v1] KVM: VMX: enable guest access to LMCE related MSRs

[Haozhong Zhang]

On 06/05/16 21:43, Borislav Petkov wrote:
> On Sun, Jun 05, 2016 at 11:14:56PM +0800, Haozhong Zhang wrote:
> > Ashok was also involved in the development of v1 patch and it's based
> > on his v0 patch, so I think I should take his SOB?
> 
> You have at least three options:
> 
> 1.
> From: Author Name 
> 
> ...
> 
> Signed-off-by: Author Name 
> [ Submitter did this and that to the Author's patch ]
> Signed-off-by: Submitter Name 
>

Thanks! I'll take this option.

Haozhong

> So you either do that or you say something like
>
> 2. "Based on an original patch by Ashok..."
> 
> in the commit message
> 
> or
> 
> you add the tag
> 
> 3. Originally-by: Ashok..
> 
> Makes sense?
> 
> For more info see Documentation/SubmittingPatches.
> 
> -- 
> Regards/Gruss,
> Boris.
> 
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 
> 21284 (AG Nürnberg)
> -- 

Re: [PATCH v1] KVM: VMX: enable guest access to LMCE related MSRs

[Haozhong Zhang]

On 06/05/16 21:43, Borislav Petkov wrote:
> On Sun, Jun 05, 2016 at 11:14:56PM +0800, Haozhong Zhang wrote:
> > Ashok was also involved in the development of v1 patch and it's based
> > on his v0 patch, so I think I should take his SOB?
> 
> You have at least three options:
> 
> 1.
> From: Author Name 
> 
> ...
> 
> Signed-off-by: Author Name 
> [ Submitter did this and that to the Author's patch ]
> Signed-off-by: Submitter Name 
>

Thanks! I'll take this option.

Haozhong

> So you either do that or you say something like
>
> 2. "Based on an original patch by Ashok..."
> 
> in the commit message
> 
> or
> 
> you add the tag
> 
> 3. Originally-by: Ashok..
> 
> Makes sense?
> 
> For more info see Documentation/SubmittingPatches.
> 
> -- 
> Regards/Gruss,
> Boris.
> 
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 
> 21284 (AG Nürnberg)
> -- 

linux-next: manual merge of the samsung-krzk tree with the arm-soc tree

[Stephen Rothwell]

Hi Krzysztof,

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

  arch/arm/mach-exynos/Kconfig

between commit:

  5c34a4e89c74 ("ARM: do away with ARCH_[WANT_OPTIONAL|REQUIRE]_GPIOLIB")

from the arm-soc tree and commit:

  9479f7cc9187 ("soc: samsung: pm_domains: Enable COMPILE_TEST for build 
coverage")

from the samsung-krzk tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm/mach-exynos/Kconfig
index ecf139f31c4c,3fa6e7b8c3fe..
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@@ -18,7 -19,7 +18,8 @@@ menuconfig ARCH_EXYNO
select EXYNOS_THERMAL
select EXYNOS_PMU
select EXYNOS_SROM
+   select EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS
 +  select GPIOLIB
select HAVE_ARM_SCU if SMP
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG

linux-next: manual merge of the samsung-krzk tree with the arm-soc tree

[Stephen Rothwell]

Hi Krzysztof,

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

  arch/arm/mach-exynos/Kconfig

between commit:

  5c34a4e89c74 ("ARM: do away with ARCH_[WANT_OPTIONAL|REQUIRE]_GPIOLIB")

from the arm-soc tree and commit:

  9479f7cc9187 ("soc: samsung: pm_domains: Enable COMPILE_TEST for build 
coverage")

from the samsung-krzk tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm/mach-exynos/Kconfig
index ecf139f31c4c,3fa6e7b8c3fe..
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@@ -18,7 -19,7 +18,8 @@@ menuconfig ARCH_EXYNO
select EXYNOS_THERMAL
select EXYNOS_PMU
select EXYNOS_SROM
+   select EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS
 +  select GPIOLIB
select HAVE_ARM_SCU if SMP
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG

linux-next: build failure after merge of the amlogic tree

[Stephen Rothwell]

Hi Kevin,

After merging the amlogic tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

In file included from arch/arm/boot/dts/meson8b-mxq.dts:48:0:
arch/arm/boot/dts/meson8b.dtsi:49:53: fatal error: 
dt-bindings/reset/amlogic,meson8b-reset.h: No such file or directory
In file included from arch/arm/boot/dts/meson8b-odroidc1.dts:48:0:
arch/arm/boot/dts/meson8b.dtsi:49:53: fatal error: 
dt-bindings/reset/amlogic,meson8b-reset.h: No such file or directory

Caused by commit

  bf205ad75a17 ("ARM: dts: amlogic: Enable Reset Controller on Meson8b 
platforms")

I guess a file was forgotten.

I have dorpped the amlogic tree for today.

-- 
Cheers,
Stephen Rothwell

linux-next: build failure after merge of the amlogic tree

[Stephen Rothwell]

Hi Kevin,

After merging the amlogic tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

In file included from arch/arm/boot/dts/meson8b-mxq.dts:48:0:
arch/arm/boot/dts/meson8b.dtsi:49:53: fatal error: 
dt-bindings/reset/amlogic,meson8b-reset.h: No such file or directory
In file included from arch/arm/boot/dts/meson8b-odroidc1.dts:48:0:
arch/arm/boot/dts/meson8b.dtsi:49:53: fatal error: 
dt-bindings/reset/amlogic,meson8b-reset.h: No such file or directory

Caused by commit

  bf205ad75a17 ("ARM: dts: amlogic: Enable Reset Controller on Meson8b 
platforms")

I guess a file was forgotten.

I have dorpped the amlogic tree for today.

-- 
Cheers,
Stephen Rothwell

Re: [alsa-devel] [PATCH] ASoC: sgtl5000: only check VDDD-supply, not revision

[Clemens Gruber]

Hi Eric, Fabio, Mark,

On Sat, Jun 04, 2016 at 07:15:25PM +0200, Clemens Gruber wrote:
> please don't merge the patch yet, I just observed a strange effect when
> resetting the board during playback / just after playback stops.
> At next boot time, sometimes the following error occurs:
> imx-sgtl5000 sound: ASoc: CODEC DAI sgtl5000 not registered
> imx-sgtl5000 sound: snd_soc_register_card failed (-517)

I looked into this today and discovered the following:

With my patch applied, if I reset the board just after playback, at the
next boot, the sgtl5000_fill_defaults function does not succeed: Writing
the default value 0x7060 to register 0x30 (CHIP_ANA_POWER) fails.

How did CHIP_ANA_POWER change with my patch: Before, only
LINREG_SIMPLE_POWERUP was cleared as is recommended in the datasheet
when using the internal LDO, now both LINREG_SIMPLE_POWERUP and
STARTUP_POWERUP are cleared, as is recommended when using external VDDD.

But why does the SGTL5000 nack that default write to CHIP_ANA_POWER
after a reboot, which interrupted the playback?

The following patch from Eric solved the problem; one write fails but it
continues setting the other registers and thus even if resetting a board
during playback, the sound still works after reboot:
http://mailman.alsa-project.org/pipermail/alsa-devel/2015-February/088356.html
Another workaround might be to not even write a default value to
CHIP_ANA_POWER, as in this patch from Eric:
http://mailman.alsa-project.org/pipermail/alsa-devel/2015-February/088355.html

What do you think we should do?

Regards,
Clemens

Re: [alsa-devel] [PATCH] ASoC: sgtl5000: only check VDDD-supply, not revision

[Clemens Gruber]

Hi Eric, Fabio, Mark,

On Sat, Jun 04, 2016 at 07:15:25PM +0200, Clemens Gruber wrote:
> please don't merge the patch yet, I just observed a strange effect when
> resetting the board during playback / just after playback stops.
> At next boot time, sometimes the following error occurs:
> imx-sgtl5000 sound: ASoc: CODEC DAI sgtl5000 not registered
> imx-sgtl5000 sound: snd_soc_register_card failed (-517)

I looked into this today and discovered the following:

With my patch applied, if I reset the board just after playback, at the
next boot, the sgtl5000_fill_defaults function does not succeed: Writing
the default value 0x7060 to register 0x30 (CHIP_ANA_POWER) fails.

How did CHIP_ANA_POWER change with my patch: Before, only
LINREG_SIMPLE_POWERUP was cleared as is recommended in the datasheet
when using the internal LDO, now both LINREG_SIMPLE_POWERUP and
STARTUP_POWERUP are cleared, as is recommended when using external VDDD.

But why does the SGTL5000 nack that default write to CHIP_ANA_POWER
after a reboot, which interrupted the playback?

The following patch from Eric solved the problem; one write fails but it
continues setting the other registers and thus even if resetting a board
during playback, the sound still works after reboot:
http://mailman.alsa-project.org/pipermail/alsa-devel/2015-February/088356.html
Another workaround might be to not even write a default value to
CHIP_ANA_POWER, as in this patch from Eric:
http://mailman.alsa-project.org/pipermail/alsa-devel/2015-February/088355.html

What do you think we should do?

Regards,
Clemens

[PATCH 3.14 03/23] MIPS: ath79: make bootconsole wait for both THRE and TEMT

[Greg Kroah-Hartman]

3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Matthias Schiffer 

commit f5b556c94c8490d42fea79d7b4ae0ecbc291e69d upstream.

This makes the ath79 bootconsole behave the same way as the generic 8250
bootconsole.

Also waiting for TEMT (transmit buffer is empty) instead of just THRE
(transmit buffer is not full) ensures that all characters have been
transmitted before the real serial driver starts reconfiguring the serial
controller (which would sometimes result in garbage being transmitted.)
This change does not cause a visible performance loss.

In addition, this seems to fix a hang observed in certain configurations on
many AR7xxx/AR9xxx SoCs during autoconfig of the real serial driver.

A more complete follow-up patch will disable 8250 autoconfig for ath79
altogether (the serial controller is detected as a 16550A, which is not
fully compatible with the ath79 serial, and the autoconfig may lead to
undefined behavior on ath79.)

Signed-off-by: Matthias Schiffer 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/ath79/early_printk.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/arch/mips/ath79/early_printk.c
+++ b/arch/mips/ath79/early_printk.c
@@ -31,13 +31,15 @@ static inline void prom_putchar_wait(voi
} while (1);
 }
 
+#define BOTH_EMPTY (UART_LSR_TEMT | UART_LSR_THRE)
+
 static void prom_putchar_ar71xx(unsigned char ch)
 {
void __iomem *base = (void __iomem *)(KSEG1ADDR(AR71XX_UART_BASE));
 
-   prom_putchar_wait(base + UART_LSR * 4, UART_LSR_THRE, UART_LSR_THRE);
+   prom_putchar_wait(base + UART_LSR * 4, BOTH_EMPTY, BOTH_EMPTY);
__raw_writel(ch, base + UART_TX * 4);
-   prom_putchar_wait(base + UART_LSR * 4, UART_LSR_THRE, UART_LSR_THRE);
+   prom_putchar_wait(base + UART_LSR * 4, BOTH_EMPTY, BOTH_EMPTY);
 }
 
 static void prom_putchar_ar933x(unsigned char ch)

[PATCH 3.14 03/23] MIPS: ath79: make bootconsole wait for both THRE and TEMT

[Greg Kroah-Hartman]

3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Matthias Schiffer 

commit f5b556c94c8490d42fea79d7b4ae0ecbc291e69d upstream.

This makes the ath79 bootconsole behave the same way as the generic 8250
bootconsole.

Also waiting for TEMT (transmit buffer is empty) instead of just THRE
(transmit buffer is not full) ensures that all characters have been
transmitted before the real serial driver starts reconfiguring the serial
controller (which would sometimes result in garbage being transmitted.)
This change does not cause a visible performance loss.

In addition, this seems to fix a hang observed in certain configurations on
many AR7xxx/AR9xxx SoCs during autoconfig of the real serial driver.

A more complete follow-up patch will disable 8250 autoconfig for ath79
altogether (the serial controller is detected as a 16550A, which is not
fully compatible with the ath79 serial, and the autoconfig may lead to
undefined behavior on ath79.)

Signed-off-by: Matthias Schiffer 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/ath79/early_printk.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/arch/mips/ath79/early_printk.c
+++ b/arch/mips/ath79/early_printk.c
@@ -31,13 +31,15 @@ static inline void prom_putchar_wait(voi
} while (1);
 }
 
+#define BOTH_EMPTY (UART_LSR_TEMT | UART_LSR_THRE)
+
 static void prom_putchar_ar71xx(unsigned char ch)
 {
void __iomem *base = (void __iomem *)(KSEG1ADDR(AR71XX_UART_BASE));
 
-   prom_putchar_wait(base + UART_LSR * 4, UART_LSR_THRE, UART_LSR_THRE);
+   prom_putchar_wait(base + UART_LSR * 4, BOTH_EMPTY, BOTH_EMPTY);
__raw_writel(ch, base + UART_TX * 4);
-   prom_putchar_wait(base + UART_LSR * 4, UART_LSR_THRE, UART_LSR_THRE);
+   prom_putchar_wait(base + UART_LSR * 4, BOTH_EMPTY, BOTH_EMPTY);
 }
 
 static void prom_putchar_ar933x(unsigned char ch)

[PATCH 3.14 05/23] ath5k: Change led pin configuration for compaq c700 laptop

[Greg Kroah-Hartman]

3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Joseph Salisbury 

commit 7b9bc799a445aea95f64f15e0083cb19b5789abe upstream.

BugLink: http://bugs.launchpad.net/bugs/972604

Commit 09c9bae26b0d3c9472cb6ae45010460a2cee8b8d ("ath5k: add led pin
configuration for compaq c700 laptop") added a pin configuration for the Compaq
c700 laptop.  However, the polarity of the led pin is reversed.  It should be
red for wifi off and blue for wifi on, but it is the opposite.  This bug was
reported in the following bug report:
http://pad.lv/972604

Fixes: 09c9bae26b0d3c9472cb6ae45010460a2cee8b8d ("ath5k: add led pin 
configuration for compaq c700 laptop")
Signed-off-by: Joseph Salisbury 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/ath/ath5k/led.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/wireless/ath/ath5k/led.c
+++ b/drivers/net/wireless/ath/ath5k/led.c
@@ -77,7 +77,7 @@ static DEFINE_PCI_DEVICE_TABLE(ath5k_led
/* HP Compaq CQ60-206US (ddregg...@jumptv.com) */
{ ATH_SDEVICE(PCI_VENDOR_ID_HP, 0x0137a), ATH_LED(3, 1) },
/* HP Compaq C700 (nitrous...@gmail.com) */
-   { ATH_SDEVICE(PCI_VENDOR_ID_HP, 0x0137b), ATH_LED(3, 1) },
+   { ATH_SDEVICE(PCI_VENDOR_ID_HP, 0x0137b), ATH_LED(3, 0) },
/* LiteOn AR5BXB63 (mag...@salug.it) */
{ ATH_SDEVICE(PCI_VENDOR_ID_ATHEROS, 0x3067), ATH_LED(3, 0) },
/* IBM-specific AR5212 (all others) */

[PATCH 3.14 05/23] ath5k: Change led pin configuration for compaq c700 laptop

[Greg Kroah-Hartman]

3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Joseph Salisbury 

commit 7b9bc799a445aea95f64f15e0083cb19b5789abe upstream.

BugLink: http://bugs.launchpad.net/bugs/972604

Commit 09c9bae26b0d3c9472cb6ae45010460a2cee8b8d ("ath5k: add led pin
configuration for compaq c700 laptop") added a pin configuration for the Compaq
c700 laptop.  However, the polarity of the led pin is reversed.  It should be
red for wifi off and blue for wifi on, but it is the opposite.  This bug was
reported in the following bug report:
http://pad.lv/972604

Fixes: 09c9bae26b0d3c9472cb6ae45010460a2cee8b8d ("ath5k: add led pin 
configuration for compaq c700 laptop")
Signed-off-by: Joseph Salisbury 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/ath/ath5k/led.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/wireless/ath/ath5k/led.c
+++ b/drivers/net/wireless/ath/ath5k/led.c
@@ -77,7 +77,7 @@ static DEFINE_PCI_DEVICE_TABLE(ath5k_led
/* HP Compaq CQ60-206US (ddregg...@jumptv.com) */
{ ATH_SDEVICE(PCI_VENDOR_ID_HP, 0x0137a), ATH_LED(3, 1) },
/* HP Compaq C700 (nitrous...@gmail.com) */
-   { ATH_SDEVICE(PCI_VENDOR_ID_HP, 0x0137b), ATH_LED(3, 1) },
+   { ATH_SDEVICE(PCI_VENDOR_ID_HP, 0x0137b), ATH_LED(3, 0) },
/* LiteOn AR5BXB63 (mag...@salug.it) */
{ ATH_SDEVICE(PCI_VENDOR_ID_ATHEROS, 0x3067), ATH_LED(3, 0) },
/* IBM-specific AR5212 (all others) */

[PATCH 3.14 02/23] MIPS: Fix siginfo.h to use strict posix types

[Greg Kroah-Hartman]

3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: James Hogan 

commit 5daebc477da4dfeb31ae193d83084def58fd2697 upstream.

Commit 85efde6f4e0d ("make exported headers use strict posix types")
changed the asm-generic siginfo.h to use the __kernel_* types, and
commit 3a471cbc081b ("remove __KERNEL_STRICT_NAMES") make the internal
types accessible only to the kernel, but the MIPS implementation hasn't
been updated to match.

Switch to proper types now so that the exported asm/siginfo.h won't
produce quite so many compiler errors when included alone by a user
program.

Signed-off-by: James Hogan 
Cc: Christopher Ferris 
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/12477/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/include/uapi/asm/siginfo.h |   18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

--- a/arch/mips/include/uapi/asm/siginfo.h
+++ b/arch/mips/include/uapi/asm/siginfo.h
@@ -48,13 +48,13 @@ typedef struct siginfo {
 
/* kill() */
struct {
-   pid_t _pid; /* sender's pid */
+   __kernel_pid_t _pid;/* sender's pid */
__ARCH_SI_UID_T _uid;   /* sender's uid */
} _kill;
 
/* POSIX.1b timers */
struct {
-   timer_t _tid;   /* timer id */
+   __kernel_timer_t _tid;  /* timer id */
int _overrun;   /* overrun count */
char _pad[sizeof( __ARCH_SI_UID_T) - sizeof(int)];
sigval_t _sigval;   /* same as below */
@@ -63,26 +63,26 @@ typedef struct siginfo {
 
/* POSIX.1b signals */
struct {
-   pid_t _pid; /* sender's pid */
+   __kernel_pid_t _pid;/* sender's pid */
__ARCH_SI_UID_T _uid;   /* sender's uid */
sigval_t _sigval;
} _rt;
 
/* SIGCHLD */
struct {
-   pid_t _pid; /* which child */
+   __kernel_pid_t _pid;/* which child */
__ARCH_SI_UID_T _uid;   /* sender's uid */
int _status;/* exit code */
-   clock_t _utime;
-   clock_t _stime;
+   __kernel_clock_t _utime;
+   __kernel_clock_t _stime;
} _sigchld;
 
/* IRIX SIGCHLD */
struct {
-   pid_t _pid; /* which child */
-   clock_t _utime;
+   __kernel_pid_t _pid;/* which child */
+   __kernel_clock_t _utime;
int _status;/* exit code */
-   clock_t _stime;
+   __kernel_clock_t _stime;
} _irix_sigchld;
 
/* SIGILL, SIGFPE, SIGSEGV, SIGBUS */

[PATCH 3.14 02/23] MIPS: Fix siginfo.h to use strict posix types

[Greg Kroah-Hartman]

3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: James Hogan 

commit 5daebc477da4dfeb31ae193d83084def58fd2697 upstream.

Commit 85efde6f4e0d ("make exported headers use strict posix types")
changed the asm-generic siginfo.h to use the __kernel_* types, and
commit 3a471cbc081b ("remove __KERNEL_STRICT_NAMES") make the internal
types accessible only to the kernel, but the MIPS implementation hasn't
been updated to match.

Switch to proper types now so that the exported asm/siginfo.h won't
produce quite so many compiler errors when included alone by a user
program.

Signed-off-by: James Hogan 
Cc: Christopher Ferris 
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/12477/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/include/uapi/asm/siginfo.h |   18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

--- a/arch/mips/include/uapi/asm/siginfo.h
+++ b/arch/mips/include/uapi/asm/siginfo.h
@@ -48,13 +48,13 @@ typedef struct siginfo {
 
/* kill() */
struct {
-   pid_t _pid; /* sender's pid */
+   __kernel_pid_t _pid;/* sender's pid */
__ARCH_SI_UID_T _uid;   /* sender's uid */
} _kill;
 
/* POSIX.1b timers */
struct {
-   timer_t _tid;   /* timer id */
+   __kernel_timer_t _tid;  /* timer id */
int _overrun;   /* overrun count */
char _pad[sizeof( __ARCH_SI_UID_T) - sizeof(int)];
sigval_t _sigval;   /* same as below */
@@ -63,26 +63,26 @@ typedef struct siginfo {
 
/* POSIX.1b signals */
struct {
-   pid_t _pid; /* sender's pid */
+   __kernel_pid_t _pid;/* sender's pid */
__ARCH_SI_UID_T _uid;   /* sender's uid */
sigval_t _sigval;
} _rt;
 
/* SIGCHLD */
struct {
-   pid_t _pid; /* which child */
+   __kernel_pid_t _pid;/* which child */
__ARCH_SI_UID_T _uid;   /* sender's uid */
int _status;/* exit code */
-   clock_t _utime;
-   clock_t _stime;
+   __kernel_clock_t _utime;
+   __kernel_clock_t _stime;
} _sigchld;
 
/* IRIX SIGCHLD */
struct {
-   pid_t _pid; /* which child */
-   clock_t _utime;
+   __kernel_pid_t _pid;/* which child */
+   __kernel_clock_t _utime;
int _status;/* exit code */
-   clock_t _stime;
+   __kernel_clock_t _stime;
} _irix_sigchld;
 
/* SIGILL, SIGFPE, SIGSEGV, SIGBUS */

[PATCH 3.14 01/23] MIPS: math-emu: Fix jalr emulation when rd == $0

[Greg Kroah-Hartman]

3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Paul Burton 

commit ab4a92e66741b35ca12f8497896bafbe579c28a1 upstream.

When emulating a jalr instruction with rd == $0, the code in
isBranchInstr was incorrectly writing to GPR $0 which should actually
always remain zeroed. This would lead to any further instructions
emulated which use $0 operating on a bogus value until the task is next
context switched, at which point the value of $0 in the task context
would be restored to the correct zero by a store in SAVE_SOME. Fix this
by not writing to rd if it is $0.

Fixes: 102cedc32a6e ("MIPS: microMIPS: Floating point support.")
Signed-off-by: Paul Burton 
Cc: Maciej W. Rozycki 
Cc: James Hogan 
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13160/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/math-emu/cp1emu.c |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

--- a/arch/mips/math-emu/cp1emu.c
+++ b/arch/mips/math-emu/cp1emu.c
@@ -676,9 +676,11 @@ static int isBranchInstr(struct pt_regs
case spec_op:
switch (insn.r_format.func) {
case jalr_op:
-   regs->regs[insn.r_format.rd] =
-   regs->cp0_epc + dec_insn.pc_inc +
-   dec_insn.next_pc_inc;
+   if (insn.r_format.rd != 0) {
+   regs->regs[insn.r_format.rd] =
+   regs->cp0_epc + dec_insn.pc_inc +
+   dec_insn.next_pc_inc;
+   }
/* Fall through */
case jr_op:
*contpc = regs->regs[insn.r_format.rs];

[PATCH 3.14 01/23] MIPS: math-emu: Fix jalr emulation when rd == $0

[Greg Kroah-Hartman]

3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Paul Burton 

commit ab4a92e66741b35ca12f8497896bafbe579c28a1 upstream.

When emulating a jalr instruction with rd == $0, the code in
isBranchInstr was incorrectly writing to GPR $0 which should actually
always remain zeroed. This would lead to any further instructions
emulated which use $0 operating on a bogus value until the task is next
context switched, at which point the value of $0 in the task context
would be restored to the correct zero by a store in SAVE_SOME. Fix this
by not writing to rd if it is $0.

Fixes: 102cedc32a6e ("MIPS: microMIPS: Floating point support.")
Signed-off-by: Paul Burton 
Cc: Maciej W. Rozycki 
Cc: James Hogan 
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13160/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/math-emu/cp1emu.c |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

--- a/arch/mips/math-emu/cp1emu.c
+++ b/arch/mips/math-emu/cp1emu.c
@@ -676,9 +676,11 @@ static int isBranchInstr(struct pt_regs
case spec_op:
switch (insn.r_format.func) {
case jalr_op:
-   regs->regs[insn.r_format.rd] =
-   regs->cp0_epc + dec_insn.pc_inc +
-   dec_insn.next_pc_inc;
+   if (insn.r_format.rd != 0) {
+   regs->regs[insn.r_format.rd] =
+   regs->cp0_epc + dec_insn.pc_inc +
+   dec_insn.next_pc_inc;
+   }
/* Fall through */
case jr_op:
*contpc = regs->regs[insn.r_format.rs];

[PATCH 3.14 06/23] aacraid: Relinquish CPU during timeout wait

[Greg Kroah-Hartman]

3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Raghava Aditya Renukunta 

commit 07beca2be24cc710461c0b131832524c9ee08910 upstream.

aac_fib_send has a special function case for initial commands during
driver initialization using wait < 0(pseudo sync mode). In this case,
the command does not sleep but rather spins checking for timeout.This
loop is calls cpu_relax() in an attempt to allow other processes/threads
to use the CPU, but this function does not relinquish the CPU and so the
command will hog the processor. This was observed in a KDUMP
"crashkernel" and that prevented the "command thread" (which is
responsible for completing the command from being timed out) from
starting because it could not get the CPU.

Fixed by replacing "cpu_relax()" call with "schedule()"
Signed-off-by: Raghava Aditya Renukunta 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/scsi/aacraid/commsup.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/drivers/scsi/aacraid/commsup.c
+++ b/drivers/scsi/aacraid/commsup.c
@@ -590,10 +590,10 @@ int aac_fib_send(u16 command, struct fib
}
return -EFAULT;
}
-   /* We used to udelay() here but that absorbed
-* a CPU when a timeout occured. Not very
-* useful. */
-   cpu_relax();
+   /*
+* Allow other processes / CPUS to use core
+*/
+   schedule();
}
} else if (down_interruptible(>event_wait)) {
/* Do nothing ... satisfy

[PATCH 3.14 04/23] Input: uinput - handle compat ioctl for UI_SET_PHYS

[Greg Kroah-Hartman]

3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Ricky Liang 

commit affa80bd97f7ca282d1faa91667b3ee9e4c590e6 upstream.

When running a 32-bit userspace on a 64-bit kernel, the UI_SET_PHYS
ioctl needs to be treated with special care, as it has the pointer
size encoded in the command.

Signed-off-by: Ricky Liang 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/input/misc/uinput.c |6 ++
 1 file changed, 6 insertions(+)

--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -845,9 +845,15 @@ static long uinput_ioctl(struct file *fi
 }
 
 #ifdef CONFIG_COMPAT
+
+#define UI_SET_PHYS_COMPAT _IOW(UINPUT_IOCTL_BASE, 108, compat_uptr_t)
+
 static long uinput_compat_ioctl(struct file *file,
unsigned int cmd, unsigned long arg)
 {
+   if (cmd == UI_SET_PHYS_COMPAT)
+   cmd = UI_SET_PHYS;
+
return uinput_ioctl_handler(file, cmd, arg, compat_ptr(arg));
 }
 #endif

[PATCH 3.14 06/23] aacraid: Relinquish CPU during timeout wait

[Greg Kroah-Hartman]

3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Raghava Aditya Renukunta 

commit 07beca2be24cc710461c0b131832524c9ee08910 upstream.

aac_fib_send has a special function case for initial commands during
driver initialization using wait < 0(pseudo sync mode). In this case,
the command does not sleep but rather spins checking for timeout.This
loop is calls cpu_relax() in an attempt to allow other processes/threads
to use the CPU, but this function does not relinquish the CPU and so the
command will hog the processor. This was observed in a KDUMP
"crashkernel" and that prevented the "command thread" (which is
responsible for completing the command from being timed out) from
starting because it could not get the CPU.

Fixed by replacing "cpu_relax()" call with "schedule()"
Signed-off-by: Raghava Aditya Renukunta 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/scsi/aacraid/commsup.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/drivers/scsi/aacraid/commsup.c
+++ b/drivers/scsi/aacraid/commsup.c
@@ -590,10 +590,10 @@ int aac_fib_send(u16 command, struct fib
}
return -EFAULT;
}
-   /* We used to udelay() here but that absorbed
-* a CPU when a timeout occured. Not very
-* useful. */
-   cpu_relax();
+   /*
+* Allow other processes / CPUS to use core
+*/
+   schedule();
}
} else if (down_interruptible(>event_wait)) {
/* Do nothing ... satisfy

[PATCH 3.14 04/23] Input: uinput - handle compat ioctl for UI_SET_PHYS

[Greg Kroah-Hartman]

3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Ricky Liang 

commit affa80bd97f7ca282d1faa91667b3ee9e4c590e6 upstream.

When running a 32-bit userspace on a 64-bit kernel, the UI_SET_PHYS
ioctl needs to be treated with special care, as it has the pointer
size encoded in the command.

Signed-off-by: Ricky Liang 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/input/misc/uinput.c |6 ++
 1 file changed, 6 insertions(+)

--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -845,9 +845,15 @@ static long uinput_ioctl(struct file *fi
 }
 
 #ifdef CONFIG_COMPAT
+
+#define UI_SET_PHYS_COMPAT _IOW(UINPUT_IOCTL_BASE, 108, compat_uptr_t)
+
 static long uinput_compat_ioctl(struct file *file,
unsigned int cmd, unsigned long arg)
 {
+   if (cmd == UI_SET_PHYS_COMPAT)
+   cmd = UI_SET_PHYS;
+
return uinput_ioctl_handler(file, cmd, arg, compat_ptr(arg));
 }
 #endif

[PATCH 3.14 10/23] rtlwifi: Fix logic error in enter/exit power-save mode

[Greg Kroah-Hartman]

3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: wang yanqing 

commit 873ffe154ae074c46ed2d72dbd9a2a99f06f55b4 upstream.

In commit a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and
rtl_lps_enter() to use work queue"), the tests for enter/exit
power-save mode were inverted. With this change applied, the
wifi connection becomes much more stable.

Fixes: a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter() to 
use work queue")
Signed-off-by: Wang YanQing 
Acked-by: Larry Finger 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/rtlwifi/base.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/net/wireless/rtlwifi/base.c
+++ b/drivers/net/wireless/rtlwifi/base.c
@@ -1401,9 +1401,9 @@ void rtl_watchdog_wq_callback(void *data
if (((rtlpriv->link_info.num_rx_inperiod +
  rtlpriv->link_info.num_tx_inperiod) > 8) ||
(rtlpriv->link_info.num_rx_inperiod > 2))
-   rtlpriv->enter_ps = true;
-   else
rtlpriv->enter_ps = false;
+   else
+   rtlpriv->enter_ps = true;
 
/* LeisurePS only work in infra mode. */
schedule_work(>works.lps_change_work);

[PATCH 3.14 13/23] xen/events: Dont move disabled irqs

[Greg Kroah-Hartman]

3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Ross Lagerwall 

commit f0f393877c71ad227d36705d61d1e4062bc29cf5 upstream.

Commit ff1e22e7a638 ("xen/events: Mask a moving irq") open-coded
irq_move_irq() but left out checking if the IRQ is disabled. This broke
resuming from suspend since it tries to move a (disabled) irq without
holding the IRQ's desc->lock. Fix it by adding in a check for disabled
IRQs.

The resulting stacktrace was:
kernel BUG at /build/linux-UbQGH5/linux-4.4.0/kernel/irq/migration.c:31!
invalid opcode:  [#1] SMP
Modules linked in: xenfs xen_privcmd ...
CPU: 0 PID: 9 Comm: migration/0 Not tainted 4.4.0-22-generic #39-Ubuntu
Hardware name: Xen HVM domU, BIOS 4.6.1-xs125180 05/04/2016
task: 88003d75ee00 ti: 88003d7bc000 task.ti: 88003d7bc000
RIP: 0010:[]  [] 
irq_move_masked_irq+0xd2/0xe0
RSP: 0018:88003d7bfc50  EFLAGS: 00010046
RAX:  RBX: 88003d40ba00 RCX: 0001
RDX: 0001 RSI: 0100 RDI: 88003d40bad8
RBP: 88003d7bfc68 R08:  R09: 88003d00
R10:  R11: 023c R12: 88003d40bad0
R13: 81f3a4a0 R14: 0010 R15: 
FS:  () GS:88003da0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7fd4264de624 CR3: 37922000 CR4: 003406f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Stack:
 88003d40ba38 0024  88003d7bfca0
 814c8d92 0010813ef89d 805ea732 0009
 0024 88003cc39b80 88003d7bfce0 814c8f66
Call Trace:
 [] eoi_pirq+0xb2/0xf0
 [] __startup_pirq+0xe6/0x150
 [] xen_irq_resume+0x319/0x360
 [] xen_suspend+0xb5/0x180
 [] multi_cpu_stop+0xb5/0xe0
 [] ? cpu_stop_queue_work+0x80/0x80
 [] cpu_stopper_thread+0xb0/0x140
 [] ? finish_task_switch+0x76/0x220
 [] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20
 [] smpboot_thread_fn+0x105/0x160
 [] ? sort_range+0x30/0x30
 [] kthread+0xd8/0xf0
 [] ? kthread_create_on_node+0x1e0/0x1e0
 [] ret_from_fork+0x3f/0x70
 [] ? kthread_create_on_node+0x1e0/0x1e0

Signed-off-by: Ross Lagerwall 
Reviewed-by: Boris Ostrovsky 
Signed-off-by: David Vrabel 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/xen/events/events_base.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -506,7 +506,8 @@ static void eoi_pirq(struct irq_data *da
if (!VALID_EVTCHN(evtchn))
return;
 
-   if (unlikely(irqd_is_setaffinity_pending(data))) {
+   if (unlikely(irqd_is_setaffinity_pending(data)) &&
+   likely(!irqd_irq_disabled(data))) {
int masked = test_and_set_mask(evtchn);
 
clear_evtchn(evtchn);
@@ -1408,7 +1409,8 @@ static void ack_dynirq(struct irq_data *
if (!VALID_EVTCHN(evtchn))
return;
 
-   if (unlikely(irqd_is_setaffinity_pending(data))) {
+   if (unlikely(irqd_is_setaffinity_pending(data)) &&
+   likely(!irqd_irq_disabled(data))) {
int masked = test_and_set_mask(evtchn);
 
clear_evtchn(evtchn);

[PATCH 3.14 10/23] rtlwifi: Fix logic error in enter/exit power-save mode

[Greg Kroah-Hartman]

3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: wang yanqing 

commit 873ffe154ae074c46ed2d72dbd9a2a99f06f55b4 upstream.

In commit a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and
rtl_lps_enter() to use work queue"), the tests for enter/exit
power-save mode were inverted. With this change applied, the
wifi connection becomes much more stable.

Fixes: a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter() to 
use work queue")
Signed-off-by: Wang YanQing 
Acked-by: Larry Finger 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/rtlwifi/base.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/net/wireless/rtlwifi/base.c
+++ b/drivers/net/wireless/rtlwifi/base.c
@@ -1401,9 +1401,9 @@ void rtl_watchdog_wq_callback(void *data
if (((rtlpriv->link_info.num_rx_inperiod +
  rtlpriv->link_info.num_tx_inperiod) > 8) ||
(rtlpriv->link_info.num_rx_inperiod > 2))
-   rtlpriv->enter_ps = true;
-   else
rtlpriv->enter_ps = false;
+   else
+   rtlpriv->enter_ps = true;
 
/* LeisurePS only work in infra mode. */
schedule_work(>works.lps_change_work);

[PATCH 3.14 13/23] xen/events: Dont move disabled irqs

[Greg Kroah-Hartman]

3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Ross Lagerwall 

commit f0f393877c71ad227d36705d61d1e4062bc29cf5 upstream.

Commit ff1e22e7a638 ("xen/events: Mask a moving irq") open-coded
irq_move_irq() but left out checking if the IRQ is disabled. This broke
resuming from suspend since it tries to move a (disabled) irq without
holding the IRQ's desc->lock. Fix it by adding in a check for disabled
IRQs.

The resulting stacktrace was:
kernel BUG at /build/linux-UbQGH5/linux-4.4.0/kernel/irq/migration.c:31!
invalid opcode:  [#1] SMP
Modules linked in: xenfs xen_privcmd ...
CPU: 0 PID: 9 Comm: migration/0 Not tainted 4.4.0-22-generic #39-Ubuntu
Hardware name: Xen HVM domU, BIOS 4.6.1-xs125180 05/04/2016
task: 88003d75ee00 ti: 88003d7bc000 task.ti: 88003d7bc000
RIP: 0010:[]  [] 
irq_move_masked_irq+0xd2/0xe0
RSP: 0018:88003d7bfc50  EFLAGS: 00010046
RAX:  RBX: 88003d40ba00 RCX: 0001
RDX: 0001 RSI: 0100 RDI: 88003d40bad8
RBP: 88003d7bfc68 R08:  R09: 88003d00
R10:  R11: 023c R12: 88003d40bad0
R13: 81f3a4a0 R14: 0010 R15: 
FS:  () GS:88003da0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7fd4264de624 CR3: 37922000 CR4: 003406f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Stack:
 88003d40ba38 0024  88003d7bfca0
 814c8d92 0010813ef89d 805ea732 0009
 0024 88003cc39b80 88003d7bfce0 814c8f66
Call Trace:
 [] eoi_pirq+0xb2/0xf0
 [] __startup_pirq+0xe6/0x150
 [] xen_irq_resume+0x319/0x360
 [] xen_suspend+0xb5/0x180
 [] multi_cpu_stop+0xb5/0xe0
 [] ? cpu_stop_queue_work+0x80/0x80
 [] cpu_stopper_thread+0xb0/0x140
 [] ? finish_task_switch+0x76/0x220
 [] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20
 [] smpboot_thread_fn+0x105/0x160
 [] ? sort_range+0x30/0x30
 [] kthread+0xd8/0xf0
 [] ? kthread_create_on_node+0x1e0/0x1e0
 [] ret_from_fork+0x3f/0x70
 [] ? kthread_create_on_node+0x1e0/0x1e0

Signed-off-by: Ross Lagerwall 
Reviewed-by: Boris Ostrovsky 
Signed-off-by: David Vrabel 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/xen/events/events_base.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -506,7 +506,8 @@ static void eoi_pirq(struct irq_data *da
if (!VALID_EVTCHN(evtchn))
return;
 
-   if (unlikely(irqd_is_setaffinity_pending(data))) {
+   if (unlikely(irqd_is_setaffinity_pending(data)) &&
+   likely(!irqd_irq_disabled(data))) {
int masked = test_and_set_mask(evtchn);
 
clear_evtchn(evtchn);
@@ -1408,7 +1409,8 @@ static void ack_dynirq(struct irq_data *
if (!VALID_EVTCHN(evtchn))
return;
 
-   if (unlikely(irqd_is_setaffinity_pending(data))) {
+   if (unlikely(irqd_is_setaffinity_pending(data)) &&
+   likely(!irqd_irq_disabled(data))) {
int masked = test_and_set_mask(evtchn);
 
clear_evtchn(evtchn);

[PATCH 3.14 15/23] drm/gma500: Fix possible out of bounds read

[Greg Kroah-Hartman]

3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Itai Handler 

commit 7ccca1d5bf69fdd1d3c5fcf84faf1659a6e0ad11 upstream.

Fix possible out of bounds read, by adding missing comma.
The code may read pass the end of the dsi_errors array
when the most significant bit (bit #31) in the intr_stat register
is set.
This bug has been detected using CppCheck (static analysis tool).

Signed-off-by: Itai Handler 
Signed-off-by: Patrik Jakobsson 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
@@ -85,7 +85,7 @@ static const char *const dsi_errors[] =
"RX Prot Violation",
"HS Generic Write FIFO Full",
"LP Generic Write FIFO Full",
-   "Generic Read Data Avail"
+   "Generic Read Data Avail",
"Special Packet Sent",
"Tearing Effect",
 };

[PATCH 3.14 18/23] ext4: address UBSAN warning in mb_find_order_for_block()

[Greg Kroah-Hartman]

3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Nicolai Stange 

commit b5cb316cdf3a3f5f6125412b0f6065185240cfdc upstream.

Currently, in mb_find_order_for_block(), there's a loop like the following:

  while (order <= e4b->bd_blkbits + 1) {
...
bb += 1 << (e4b->bd_blkbits - order);
  }

Note that the updated bb is used in the loop's next iteration only.

However, at the last iteration, that is at order == e4b->bd_blkbits + 1,
the shift count becomes negative (c.f. C99 6.5.7(3)) and UBSAN reports

  UBSAN: Undefined behaviour in fs/ext4/mballoc.c:1281:11
  shift exponent -1 is negative
  [...]
  Call Trace:
   [] dump_stack+0xbc/0x117
   [] ? _atomic_dec_and_lock+0x169/0x169
   [] ubsan_epilogue+0xd/0x4e
   [] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254
   [] ? __ubsan_handle_load_invalid_value+0x158/0x158
   [] ? ext4_mb_generate_from_pa+0x590/0x590
   [] ? ext4_read_block_bitmap_nowait+0x598/0xe80
   [] mb_find_order_for_block+0x1ce/0x240
   [...]

Unless compilers start to do some fancy transformations (which at least
GCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the
such calculated value of bb is never used again.

Silence UBSAN by introducing another variable, bb_incr, holding the next
increment to apply to bb and adjust that one by right shifting it by one
position per loop iteration.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161

Signed-off-by: Nicolai Stange 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/ext4/mballoc.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -1236,6 +1236,7 @@ static void ext4_mb_unload_buddy(struct
 static int mb_find_order_for_block(struct ext4_buddy *e4b, int block)
 {
int order = 1;
+   int bb_incr = 1 << (e4b->bd_blkbits - 1);
void *bb;
 
BUG_ON(e4b->bd_bitmap == e4b->bd_buddy);
@@ -1248,7 +1249,8 @@ static int mb_find_order_for_block(struc
/* this block is part of buddy of order 'order' */
return order;
}
-   bb += 1 << (e4b->bd_blkbits - order);
+   bb += bb_incr;
+   bb_incr >>= 1;
order++;
}
return 0;

[PATCH 3.14 15/23] drm/gma500: Fix possible out of bounds read

[Greg Kroah-Hartman]

3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Itai Handler 

commit 7ccca1d5bf69fdd1d3c5fcf84faf1659a6e0ad11 upstream.

Fix possible out of bounds read, by adding missing comma.
The code may read pass the end of the dsi_errors array
when the most significant bit (bit #31) in the intr_stat register
is set.
This bug has been detected using CppCheck (static analysis tool).

Signed-off-by: Itai Handler 
Signed-off-by: Patrik Jakobsson 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
@@ -85,7 +85,7 @@ static const char *const dsi_errors[] =
"RX Prot Violation",
"HS Generic Write FIFO Full",
"LP Generic Write FIFO Full",
-   "Generic Read Data Avail"
+   "Generic Read Data Avail",
"Special Packet Sent",
"Tearing Effect",
 };

[PATCH 3.14 18/23] ext4: address UBSAN warning in mb_find_order_for_block()

[Greg Kroah-Hartman]

3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Nicolai Stange 

commit b5cb316cdf3a3f5f6125412b0f6065185240cfdc upstream.

Currently, in mb_find_order_for_block(), there's a loop like the following:

  while (order <= e4b->bd_blkbits + 1) {
...
bb += 1 << (e4b->bd_blkbits - order);
  }

Note that the updated bb is used in the loop's next iteration only.

However, at the last iteration, that is at order == e4b->bd_blkbits + 1,
the shift count becomes negative (c.f. C99 6.5.7(3)) and UBSAN reports

  UBSAN: Undefined behaviour in fs/ext4/mballoc.c:1281:11
  shift exponent -1 is negative
  [...]
  Call Trace:
   [] dump_stack+0xbc/0x117
   [] ? _atomic_dec_and_lock+0x169/0x169
   [] ubsan_epilogue+0xd/0x4e
   [] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254
   [] ? __ubsan_handle_load_invalid_value+0x158/0x158
   [] ? ext4_mb_generate_from_pa+0x590/0x590
   [] ? ext4_read_block_bitmap_nowait+0x598/0xe80
   [] mb_find_order_for_block+0x1ce/0x240
   [...]

Unless compilers start to do some fancy transformations (which at least
GCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the
such calculated value of bb is never used again.

Silence UBSAN by introducing another variable, bb_incr, holding the next
increment to apply to bb and adjust that one by right shifting it by one
position per loop iteration.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161

Signed-off-by: Nicolai Stange 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/ext4/mballoc.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -1236,6 +1236,7 @@ static void ext4_mb_unload_buddy(struct
 static int mb_find_order_for_block(struct ext4_buddy *e4b, int block)
 {
int order = 1;
+   int bb_incr = 1 << (e4b->bd_blkbits - 1);
void *bb;
 
BUG_ON(e4b->bd_bitmap == e4b->bd_buddy);
@@ -1248,7 +1249,8 @@ static int mb_find_order_for_block(struc
/* this block is part of buddy of order 'order' */
return order;
}
-   bb += 1 << (e4b->bd_blkbits - order);
+   bb += bb_incr;
+   bb_incr >>= 1;
order++;
}
return 0;

[PATCH 4.4 01/99] MIPS64: R6: R2 emulation bugfix

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Leonid Yegoshin 

commit 41fa29e4d8cf4150568a0fe9bb4d62229f9caed5 upstream.

Error recovery pointers for fixups was improperly set as ".word"
which is unsuitable for MIPS64.

Replaced by STR(PTR)

[r...@linux-mips.org: Apply changes as requested in the review process.]

Signed-off-by: Leonid Yegoshin 
Reviewed-by: James Hogan 
Reviewed-by: Markos Chandras 
Fixes: b0a668fb2038 ("MIPS: kernel: mips-r2-to-r6-emul: Add R2 emulator for 
MIPS R6")
Cc: ma...@linux-mips.org
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/9911/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/kernel/mips-r2-to-r6-emul.c |  105 +-
 1 file changed, 53 insertions(+), 52 deletions(-)

--- a/arch/mips/kernel/mips-r2-to-r6-emul.c
+++ b/arch/mips/kernel/mips-r2-to-r6-emul.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -1251,10 +1252,10 @@ fpu_emul:
"   j   10b\n"
"   .previous\n"
"   .section__ex_table,\"a\"\n"
-   "   .word   1b,8b\n"
-   "   .word   2b,8b\n"
-   "   .word   3b,8b\n"
-   "   .word   4b,8b\n"
+   STR(PTR) " 1b,8b\n"
+   STR(PTR) " 2b,8b\n"
+   STR(PTR) " 3b,8b\n"
+   STR(PTR) " 4b,8b\n"
"   .previous\n"
"   .setpop\n"
: "+"(rt), "="(rs),
@@ -1326,10 +1327,10 @@ fpu_emul:
"   j   10b\n"
"   .previous\n"
"   .section__ex_table,\"a\"\n"
-   "   .word   1b,8b\n"
-   "   .word   2b,8b\n"
-   "   .word   3b,8b\n"
-   "   .word   4b,8b\n"
+   STR(PTR) " 1b,8b\n"
+   STR(PTR) " 2b,8b\n"
+   STR(PTR) " 3b,8b\n"
+   STR(PTR) " 4b,8b\n"
"   .previous\n"
"   .setpop\n"
: "+"(rt), "="(rs),
@@ -1397,10 +1398,10 @@ fpu_emul:
"   j   9b\n"
"   .previous\n"
"   .section__ex_table,\"a\"\n"
-   "   .word   1b,8b\n"
-   "   .word   2b,8b\n"
-   "   .word   3b,8b\n"
-   "   .word   4b,8b\n"
+   STR(PTR) " 1b,8b\n"
+   STR(PTR) " 2b,8b\n"
+   STR(PTR) " 3b,8b\n"
+   STR(PTR) " 4b,8b\n"
"   .previous\n"
"   .setpop\n"
: "+"(rt), "="(rs),
@@ -1467,10 +1468,10 @@ fpu_emul:
"   j   9b\n"
"   .previous\n"
"   .section__ex_table,\"a\"\n"
-   "   .word   1b,8b\n"
-   "   .word   2b,8b\n"
-   "   .word   3b,8b\n"
-   "   .word   4b,8b\n"
+   STR(PTR) " 1b,8b\n"
+   STR(PTR) " 2b,8b\n"
+   STR(PTR) " 3b,8b\n"
+   STR(PTR) " 4b,8b\n"
"   .previous\n"
"   .setpop\n"
: "+"(rt), "="(rs),
@@ -1582,14 +1583,14 @@ fpu_emul:
"   j   9b\n"
"   .previous\n"
"   .section__ex_table,\"a\"\n"
-   "   .word   1b,8b\n"
-   "   .word   2b,8b\n"
-   "   .word   3b,8b\n"
-   "   .word   4b,8b\n"
-   "   .word   5b,8b\n"
-   "   .word   6b,8b\n"
-   "   .word   7b,8b\n"
-   "   .word   0b,8b\n"
+   STR(PTR) " 1b,8b\n"
+   STR(PTR) " 2b,8b\n"
+   STR(PTR) " 3b,8b\n"
+   STR(PTR) " 4b,8b\n"
+   STR(PTR) " 5b,8b\n"
+   STR(PTR) " 6b,8b\n"
+   STR(PTR) " 7b,8b\n"
+   STR(PTR) " 0b,8b\n"
" 

[PATCH 4.4 01/99] MIPS64: R6: R2 emulation bugfix

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Leonid Yegoshin 

commit 41fa29e4d8cf4150568a0fe9bb4d62229f9caed5 upstream.

Error recovery pointers for fixups was improperly set as ".word"
which is unsuitable for MIPS64.

Replaced by STR(PTR)

[r...@linux-mips.org: Apply changes as requested in the review process.]

Signed-off-by: Leonid Yegoshin 
Reviewed-by: James Hogan 
Reviewed-by: Markos Chandras 
Fixes: b0a668fb2038 ("MIPS: kernel: mips-r2-to-r6-emul: Add R2 emulator for 
MIPS R6")
Cc: ma...@linux-mips.org
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/9911/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/kernel/mips-r2-to-r6-emul.c |  105 +-
 1 file changed, 53 insertions(+), 52 deletions(-)

--- a/arch/mips/kernel/mips-r2-to-r6-emul.c
+++ b/arch/mips/kernel/mips-r2-to-r6-emul.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -1251,10 +1252,10 @@ fpu_emul:
"   j   10b\n"
"   .previous\n"
"   .section__ex_table,\"a\"\n"
-   "   .word   1b,8b\n"
-   "   .word   2b,8b\n"
-   "   .word   3b,8b\n"
-   "   .word   4b,8b\n"
+   STR(PTR) " 1b,8b\n"
+   STR(PTR) " 2b,8b\n"
+   STR(PTR) " 3b,8b\n"
+   STR(PTR) " 4b,8b\n"
"   .previous\n"
"   .setpop\n"
: "+"(rt), "="(rs),
@@ -1326,10 +1327,10 @@ fpu_emul:
"   j   10b\n"
"   .previous\n"
"   .section__ex_table,\"a\"\n"
-   "   .word   1b,8b\n"
-   "   .word   2b,8b\n"
-   "   .word   3b,8b\n"
-   "   .word   4b,8b\n"
+   STR(PTR) " 1b,8b\n"
+   STR(PTR) " 2b,8b\n"
+   STR(PTR) " 3b,8b\n"
+   STR(PTR) " 4b,8b\n"
"   .previous\n"
"   .setpop\n"
: "+"(rt), "="(rs),
@@ -1397,10 +1398,10 @@ fpu_emul:
"   j   9b\n"
"   .previous\n"
"   .section__ex_table,\"a\"\n"
-   "   .word   1b,8b\n"
-   "   .word   2b,8b\n"
-   "   .word   3b,8b\n"
-   "   .word   4b,8b\n"
+   STR(PTR) " 1b,8b\n"
+   STR(PTR) " 2b,8b\n"
+   STR(PTR) " 3b,8b\n"
+   STR(PTR) " 4b,8b\n"
"   .previous\n"
"   .setpop\n"
: "+"(rt), "="(rs),
@@ -1467,10 +1468,10 @@ fpu_emul:
"   j   9b\n"
"   .previous\n"
"   .section__ex_table,\"a\"\n"
-   "   .word   1b,8b\n"
-   "   .word   2b,8b\n"
-   "   .word   3b,8b\n"
-   "   .word   4b,8b\n"
+   STR(PTR) " 1b,8b\n"
+   STR(PTR) " 2b,8b\n"
+   STR(PTR) " 3b,8b\n"
+   STR(PTR) " 4b,8b\n"
"   .previous\n"
"   .setpop\n"
: "+"(rt), "="(rs),
@@ -1582,14 +1583,14 @@ fpu_emul:
"   j   9b\n"
"   .previous\n"
"   .section__ex_table,\"a\"\n"
-   "   .word   1b,8b\n"
-   "   .word   2b,8b\n"
-   "   .word   3b,8b\n"
-   "   .word   4b,8b\n"
-   "   .word   5b,8b\n"
-   "   .word   6b,8b\n"
-   "   .word   7b,8b\n"
-   "   .word   0b,8b\n"
+   STR(PTR) " 1b,8b\n"
+   STR(PTR) " 2b,8b\n"
+   STR(PTR) " 3b,8b\n"
+   STR(PTR) " 4b,8b\n"
+   STR(PTR) " 5b,8b\n"
+   STR(PTR) " 6b,8b\n"
+   STR(PTR) " 7b,8b\n"
+   STR(PTR) " 0b,8b\n"
"   .previous\n"
"   .setpop\n"
: "+"(rt), "="(rs),
@@ -1701,14 +1702,14 @@ fpu_emul:
 

[PATCH 3.14 17/23] ext4: fix hang when processing corrupted orphaned inode list

[Greg Kroah-Hartman]

3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Theodore Ts'o 

commit c9eb13a9105e2e418f72e46a2b6da3f49e696902 upstream.

If the orphaned inode list contains inode #5, ext4_iget() returns a
bad inode (since the bootloader inode should never be referenced
directly).  Because of the bad inode, we end up processing the inode
repeatedly and this hangs the machine.

This can be reproduced via:

   mke2fs -t ext4 /tmp/foo.img 100
   debugfs -w -R "ssv last_orphan 5" /tmp/foo.img
   mount -o loop /tmp/foo.img /mnt

(But don't do this if you are using an unpatched kernel if you care
about the system staying functional.  :-)

This bug was found by the port of American Fuzzy Lop into the kernel
to find file system problems[1].  (Since it *only* happens if inode #5
shows up on the orphan list --- 3, 7, 8, etc. won't do it, it's not
surprising that AFL needed two hours before it found it.)

[1] 
http://events.linuxfoundation.org/sites/events/files/slides/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0.pdf

Reported by: Vegard Nossum 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/ext4/ialloc.c |   10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

--- a/fs/ext4/ialloc.c
+++ b/fs/ext4/ialloc.c
@@ -1097,11 +1097,13 @@ struct inode *ext4_orphan_get(struct sup
goto iget_failed;
 
/*
-* If the orphans has i_nlinks > 0 then it should be able to be
-* truncated, otherwise it won't be removed from the orphan list
-* during processing and an infinite loop will result.
+* If the orphans has i_nlinks > 0 then it should be able to
+* be truncated, otherwise it won't be removed from the orphan
+* list during processing and an infinite loop will result.
+* Similarly, it must not be a bad inode.
 */
-   if (inode->i_nlink && !ext4_can_truncate(inode))
+   if ((inode->i_nlink && !ext4_can_truncate(inode)) ||
+   is_bad_inode(inode))
goto bad_orphan;
 
if (NEXT_ORPHAN(inode) > max_ino)

[PATCH 3.14 19/23] ext4: silence UBSAN in ext4_mb_init()

[Greg Kroah-Hartman]

3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Nicolai Stange 

commit 935244cd54b86ca46e69bc6604d2adfb1aec2d42 upstream.

Currently, in ext4_mb_init(), there's a loop like the following:

  do {
...
offset += 1 << (sb->s_blocksize_bits - i);
i++;
  } while (i <= sb->s_blocksize_bits + 1);

Note that the updated offset is used in the loop's next iteration only.

However, at the last iteration, that is at i == sb->s_blocksize_bits + 1,
the shift count becomes equal to (unsigned)-1 > 31 (c.f. C99 6.5.7(3))
and UBSAN reports

  UBSAN: Undefined behaviour in fs/ext4/mballoc.c:2621:15
  shift exponent 4294967295 is too large for 32-bit type 'int'
  [...]
  Call Trace:
   [] dump_stack+0xbc/0x117
   [] ? _atomic_dec_and_lock+0x169/0x169
   [] ubsan_epilogue+0xd/0x4e
   [] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254
   [] ? __ubsan_handle_load_invalid_value+0x158/0x158
   [] ? kmem_cache_alloc+0x101/0x390
   [] ? ext4_mb_init+0x13b/0xfd0
   [] ? create_cache+0x57/0x1f0
   [] ? create_cache+0x11a/0x1f0
   [] ? mutex_lock+0x38/0x60
   [] ? mutex_unlock+0x1b/0x50
   [] ? put_online_mems+0x5b/0xc0
   [] ? kmem_cache_create+0x117/0x2c0
   [] ext4_mb_init+0xc49/0xfd0
   [...]

Observe that the mentioned shift exponent, 4294967295, equals (unsigned)-1.

Unless compilers start to do some fancy transformations (which at least
GCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the
such calculated value of offset is never used again.

Silence UBSAN by introducing another variable, offset_incr, holding the
next increment to apply to offset and adjust that one by right shifting it
by one position per loop iteration.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161

Signed-off-by: Nicolai Stange 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/ext4/mballoc.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -2537,7 +2537,7 @@ int ext4_mb_init(struct super_block *sb)
 {
struct ext4_sb_info *sbi = EXT4_SB(sb);
unsigned i, j;
-   unsigned offset;
+   unsigned offset, offset_incr;
unsigned max;
int ret;
 
@@ -2566,11 +2566,13 @@ int ext4_mb_init(struct super_block *sb)
 
i = 1;
offset = 0;
+   offset_incr = 1 << (sb->s_blocksize_bits - 1);
max = sb->s_blocksize << 2;
do {
sbi->s_mb_offsets[i] = offset;
sbi->s_mb_maxs[i] = max;
-   offset += 1 << (sb->s_blocksize_bits - i);
+   offset += offset_incr;
+   offset_incr = offset_incr >> 1;
max = max >> 1;
i++;
} while (i <= sb->s_blocksize_bits + 1);

[PATCH 3.14 08/23] cpuidle: Indicate when a device has been unregistered

[Greg Kroah-Hartman]

3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Dave Gerlach 

commit c998c07836f985b24361629dc98506ec7893e7a0 upstream.

Currently the 'registered' member of the cpuidle_device struct is set
to 1 during cpuidle_register_device. In this same function there are
checks to see if the device is already registered to prevent duplicate
calls to register the device, but this value is never set to 0 even on
unregister of the device. Because of this, any attempt to call
cpuidle_register_device after a call to cpuidle_unregister_device will
fail which shouldn't be the case.

To prevent this, set registered to 0 when the device is unregistered.

Fixes: c878a52d3c7c (cpuidle: Check if device is already registered)
Signed-off-by: Dave Gerlach 
Acked-by: Daniel Lezcano 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/cpuidle/cpuidle.c |2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -313,6 +313,8 @@ static void __cpuidle_unregister_device(
list_del(>device_list);
per_cpu(cpuidle_devices, dev->cpu) = NULL;
module_put(drv->owner);
+
+   dev->registered = 0;
 }
 
 static void __cpuidle_device_init(struct cpuidle_device *dev)

[PATCH 3.14 23/23] xfs: skip stale inodes in xfs_iflush_cluster

[Greg Kroah-Hartman]

3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Dave Chinner 

commit 7d3aa7fe970791f1a674b14572a411accf2f4d4e upstream.

We don't write back stale inodes so we should skip them in
xfs_iflush_cluster, too.

Signed-off-by: Dave Chinner 
Reviewed-by: Brian Foster 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Dave Chinner 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/xfs/xfs_inode.c |1 +
 1 file changed, 1 insertion(+)

--- a/fs/xfs/xfs_inode.c
+++ b/fs/xfs/xfs_inode.c
@@ -2925,6 +2925,7 @@ xfs_iflush_cluster(
 */
spin_lock(>i_flags_lock);
if (!iq->i_ino ||
+   __xfs_iflags_test(iq, XFS_ISTALE) ||
(XFS_INO_TO_AGINO(mp, iq->i_ino) & mask) != first_index) {
spin_unlock(>i_flags_lock);
continue;

[PATCH 3.14 08/23] cpuidle: Indicate when a device has been unregistered

[Greg Kroah-Hartman]

3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Dave Gerlach 

commit c998c07836f985b24361629dc98506ec7893e7a0 upstream.

Currently the 'registered' member of the cpuidle_device struct is set
to 1 during cpuidle_register_device. In this same function there are
checks to see if the device is already registered to prevent duplicate
calls to register the device, but this value is never set to 0 even on
unregister of the device. Because of this, any attempt to call
cpuidle_register_device after a call to cpuidle_unregister_device will
fail which shouldn't be the case.

To prevent this, set registered to 0 when the device is unregistered.

Fixes: c878a52d3c7c (cpuidle: Check if device is already registered)
Signed-off-by: Dave Gerlach 
Acked-by: Daniel Lezcano 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/cpuidle/cpuidle.c |2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -313,6 +313,8 @@ static void __cpuidle_unregister_device(
list_del(>device_list);
per_cpu(cpuidle_devices, dev->cpu) = NULL;
module_put(drv->owner);
+
+   dev->registered = 0;
 }
 
 static void __cpuidle_device_init(struct cpuidle_device *dev)

[PATCH 3.14 23/23] xfs: skip stale inodes in xfs_iflush_cluster

[Greg Kroah-Hartman]

3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Dave Chinner 

commit 7d3aa7fe970791f1a674b14572a411accf2f4d4e upstream.

We don't write back stale inodes so we should skip them in
xfs_iflush_cluster, too.

Signed-off-by: Dave Chinner 
Reviewed-by: Brian Foster 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Dave Chinner 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/xfs/xfs_inode.c |1 +
 1 file changed, 1 insertion(+)

--- a/fs/xfs/xfs_inode.c
+++ b/fs/xfs/xfs_inode.c
@@ -2925,6 +2925,7 @@ xfs_iflush_cluster(
 */
spin_lock(>i_flags_lock);
if (!iq->i_ino ||
+   __xfs_iflags_test(iq, XFS_ISTALE) ||
(XFS_INO_TO_AGINO(mp, iq->i_ino) & mask) != first_index) {
spin_unlock(>i_flags_lock);
continue;

[PATCH 3.14 17/23] ext4: fix hang when processing corrupted orphaned inode list

[Greg Kroah-Hartman]

3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Theodore Ts'o 

commit c9eb13a9105e2e418f72e46a2b6da3f49e696902 upstream.

If the orphaned inode list contains inode #5, ext4_iget() returns a
bad inode (since the bootloader inode should never be referenced
directly).  Because of the bad inode, we end up processing the inode
repeatedly and this hangs the machine.

This can be reproduced via:

   mke2fs -t ext4 /tmp/foo.img 100
   debugfs -w -R "ssv last_orphan 5" /tmp/foo.img
   mount -o loop /tmp/foo.img /mnt

(But don't do this if you are using an unpatched kernel if you care
about the system staying functional.  :-)

This bug was found by the port of American Fuzzy Lop into the kernel
to find file system problems[1].  (Since it *only* happens if inode #5
shows up on the orphan list --- 3, 7, 8, etc. won't do it, it's not
surprising that AFL needed two hours before it found it.)

[1] 
http://events.linuxfoundation.org/sites/events/files/slides/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0.pdf

Reported by: Vegard Nossum 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/ext4/ialloc.c |   10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

--- a/fs/ext4/ialloc.c
+++ b/fs/ext4/ialloc.c
@@ -1097,11 +1097,13 @@ struct inode *ext4_orphan_get(struct sup
goto iget_failed;
 
/*
-* If the orphans has i_nlinks > 0 then it should be able to be
-* truncated, otherwise it won't be removed from the orphan list
-* during processing and an infinite loop will result.
+* If the orphans has i_nlinks > 0 then it should be able to
+* be truncated, otherwise it won't be removed from the orphan
+* list during processing and an infinite loop will result.
+* Similarly, it must not be a bad inode.
 */
-   if (inode->i_nlink && !ext4_can_truncate(inode))
+   if ((inode->i_nlink && !ext4_can_truncate(inode)) ||
+   is_bad_inode(inode))
goto bad_orphan;
 
if (NEXT_ORPHAN(inode) > max_ino)

[PATCH 3.14 19/23] ext4: silence UBSAN in ext4_mb_init()

[Greg Kroah-Hartman]

3.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Nicolai Stange 

commit 935244cd54b86ca46e69bc6604d2adfb1aec2d42 upstream.

Currently, in ext4_mb_init(), there's a loop like the following:

  do {
...
offset += 1 << (sb->s_blocksize_bits - i);
i++;
  } while (i <= sb->s_blocksize_bits + 1);

Note that the updated offset is used in the loop's next iteration only.

However, at the last iteration, that is at i == sb->s_blocksize_bits + 1,
the shift count becomes equal to (unsigned)-1 > 31 (c.f. C99 6.5.7(3))
and UBSAN reports

  UBSAN: Undefined behaviour in fs/ext4/mballoc.c:2621:15
  shift exponent 4294967295 is too large for 32-bit type 'int'
  [...]
  Call Trace:
   [] dump_stack+0xbc/0x117
   [] ? _atomic_dec_and_lock+0x169/0x169
   [] ubsan_epilogue+0xd/0x4e
   [] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254
   [] ? __ubsan_handle_load_invalid_value+0x158/0x158
   [] ? kmem_cache_alloc+0x101/0x390
   [] ? ext4_mb_init+0x13b/0xfd0
   [] ? create_cache+0x57/0x1f0
   [] ? create_cache+0x11a/0x1f0
   [] ? mutex_lock+0x38/0x60
   [] ? mutex_unlock+0x1b/0x50
   [] ? put_online_mems+0x5b/0xc0
   [] ? kmem_cache_create+0x117/0x2c0
   [] ext4_mb_init+0xc49/0xfd0
   [...]

Observe that the mentioned shift exponent, 4294967295, equals (unsigned)-1.

Unless compilers start to do some fancy transformations (which at least
GCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the
such calculated value of offset is never used again.

Silence UBSAN by introducing another variable, offset_incr, holding the
next increment to apply to offset and adjust that one by right shifting it
by one position per loop iteration.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161

Signed-off-by: Nicolai Stange 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/ext4/mballoc.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -2537,7 +2537,7 @@ int ext4_mb_init(struct super_block *sb)
 {
struct ext4_sb_info *sbi = EXT4_SB(sb);
unsigned i, j;
-   unsigned offset;
+   unsigned offset, offset_incr;
unsigned max;
int ret;
 
@@ -2566,11 +2566,13 @@ int ext4_mb_init(struct super_block *sb)
 
i = 1;
offset = 0;
+   offset_incr = 1 << (sb->s_blocksize_bits - 1);
max = sb->s_blocksize << 2;
do {
sbi->s_mb_offsets[i] = offset;
sbi->s_mb_maxs[i] = max;
-   offset += 1 << (sb->s_blocksize_bits - i);
+   offset += offset_incr;
+   offset_incr = offset_incr >> 1;
max = max >> 1;
i++;
} while (i <= sb->s_blocksize_bits + 1);

[PATCH 4.4 07/99] MIPS: Fix uapi include in exported asm/siginfo.h

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: James Hogan 

commit 987e5b834467c9251ca584febda65ef8f66351a9 upstream.

Since commit 8cb48fe169dd ("MIPS: Provide correct siginfo_t.si_stime"),
MIPS' uapi/asm/siginfo.h has included uapi/asm-generic/siginfo.h
directly before defining MIPS' struct siginfo, in order to get the
necessary definitions needed for the siginfo struct without the generic
copy_siginfo() hitting compiler errors due to struct siginfo not yet
being defined.

Now that the generic copy_siginfo() is moved out to linux/signal.h we
can safely include asm-generic/siginfo.h before defining the MIPS
specific struct siginfo, which avoids the uapi/ include as well as
breakage due to generic copy_siginfo() being defined before struct
siginfo.

Reported-by: Christopher Ferris 
Fixes: 8cb48fe169dd ("MIPS: Provide correct siginfo_t.si_stime")
Signed-off-by: James Hogan 
Cc: Petr Malat 
Cc: linux-m...@linux-mips.org
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/include/uapi/asm/siginfo.h |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

--- a/arch/mips/include/uapi/asm/siginfo.h
+++ b/arch/mips/include/uapi/asm/siginfo.h
@@ -28,7 +28,7 @@
 
 #define __ARCH_SIGSYS
 
-#include 
+#include 
 
 /* We can't use generic siginfo_t, because our si_code and si_errno are 
swapped */
 typedef struct siginfo {
@@ -118,6 +118,4 @@ typedef struct siginfo {
 #define SI_TIMER __SI_CODE(__SI_TIMER, -3) /* sent by timer expiration */
 #define SI_MESGQ __SI_CODE(__SI_MESGQ, -4) /* sent by real time mesq state 
change */
 
-#include 
-
 #endif /* _UAPI_ASM_SIGINFO_H */

[PATCH 4.4 07/99] MIPS: Fix uapi include in exported asm/siginfo.h

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: James Hogan 

commit 987e5b834467c9251ca584febda65ef8f66351a9 upstream.

Since commit 8cb48fe169dd ("MIPS: Provide correct siginfo_t.si_stime"),
MIPS' uapi/asm/siginfo.h has included uapi/asm-generic/siginfo.h
directly before defining MIPS' struct siginfo, in order to get the
necessary definitions needed for the siginfo struct without the generic
copy_siginfo() hitting compiler errors due to struct siginfo not yet
being defined.

Now that the generic copy_siginfo() is moved out to linux/signal.h we
can safely include asm-generic/siginfo.h before defining the MIPS
specific struct siginfo, which avoids the uapi/ include as well as
breakage due to generic copy_siginfo() being defined before struct
siginfo.

Reported-by: Christopher Ferris 
Fixes: 8cb48fe169dd ("MIPS: Provide correct siginfo_t.si_stime")
Signed-off-by: James Hogan 
Cc: Petr Malat 
Cc: linux-m...@linux-mips.org
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/include/uapi/asm/siginfo.h |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

--- a/arch/mips/include/uapi/asm/siginfo.h
+++ b/arch/mips/include/uapi/asm/siginfo.h
@@ -28,7 +28,7 @@
 
 #define __ARCH_SIGSYS
 
-#include 
+#include 
 
 /* We can't use generic siginfo_t, because our si_code and si_errno are 
swapped */
 typedef struct siginfo {
@@ -118,6 +118,4 @@ typedef struct siginfo {
 #define SI_TIMER __SI_CODE(__SI_TIMER, -3) /* sent by timer expiration */
 #define SI_MESGQ __SI_CODE(__SI_MESGQ, -4) /* sent by real time mesq state 
change */
 
-#include 
-
 #endif /* _UAPI_ASM_SIGINFO_H */

[PATCH 4.4 08/99] MIPS: Fix watchpoint restoration

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: James Hogan 

commit a7e89326b415b5d81c4b1016fd4a40db861eb58d upstream.

Commit f51246efee2b ("MIPS: Get rid of finish_arch_switch().") moved the
__restore_watch() call from finish_arch_switch() (i.e. after resume()
returns) to before the resume() call in switch_to(). This results in
watchpoints only being restored when a task is descheduled, preventing
the watchpoints from being effective most of the time, except due to
chance before the watchpoints are lazily removed.

Fix the call sequence from switch_to() through to
mips_install_watch_registers() to pass the task_struct pointer of the
next task, instead of using current. This allows the watchpoints for the
next (non-current) task to be restored without reintroducing
finish_arch_switch().

Fixes: f51246efee2b ("MIPS: Get rid of finish_arch_switch().")
Signed-off-by: James Hogan 
Cc: Paul Burton 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12726/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/include/asm/switch_to.h |2 +-
 arch/mips/include/asm/watch.h |   10 +-
 arch/mips/kernel/pm.c |2 +-
 arch/mips/kernel/watch.c  |5 ++---
 4 files changed, 9 insertions(+), 10 deletions(-)

--- a/arch/mips/include/asm/switch_to.h
+++ b/arch/mips/include/asm/switch_to.h
@@ -105,7 +105,7 @@ do {
\
__clear_software_ll_bit();  \
if (cpu_has_userlocal)  \
write_c0_userlocal(task_thread_info(next)->tp_value);   \
-   __restore_watch();  \
+   __restore_watch(next);  \
(last) = resume(prev, next, task_thread_info(next));\
 } while (0)
 
--- a/arch/mips/include/asm/watch.h
+++ b/arch/mips/include/asm/watch.h
@@ -12,21 +12,21 @@
 
 #include 
 
-void mips_install_watch_registers(void);
+void mips_install_watch_registers(struct task_struct *t);
 void mips_read_watch_registers(void);
 void mips_clear_watch_registers(void);
 void mips_probe_watch_registers(struct cpuinfo_mips *c);
 
 #ifdef CONFIG_HARDWARE_WATCHPOINTS
-#define __restore_watch() do { \
+#define __restore_watch(task) do { \
if (unlikely(test_bit(TIF_LOAD_WATCH,   \
- _thread_info()->flags))) {\
-   mips_install_watch_registers(); \
+ _thread_info(task)->flags))) {   \
+   mips_install_watch_registers(task); \
}   \
 } while (0)
 
 #else
-#define __restore_watch() do {} while (0)
+#define __restore_watch(task) do {} while (0)
 #endif
 
 #endif /* _ASM_WATCH_H */
--- a/arch/mips/kernel/pm.c
+++ b/arch/mips/kernel/pm.c
@@ -56,7 +56,7 @@ static void mips_cpu_restore(void)
write_c0_userlocal(current_thread_info()->tp_value);
 
/* Restore watch registers */
-   __restore_watch();
+   __restore_watch(current);
 }
 
 /**
--- a/arch/mips/kernel/watch.c
+++ b/arch/mips/kernel/watch.c
@@ -15,10 +15,9 @@
  * Install the watch registers for the current thread. A maximum of
  * four registers are installed although the machine may have more.
  */
-void mips_install_watch_registers(void)
+void mips_install_watch_registers(struct task_struct *t)
 {
-   struct mips3264_watch_reg_state *watches =
-   >thread.watch.mips3264;
+   struct mips3264_watch_reg_state *watches = >thread.watch.mips3264;
switch (current_cpu_data.watch_reg_use_cnt) {
default:
BUG();

[PATCH 4.4 06/99] MIPS: Fix siginfo.h to use strict posix types

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: James Hogan 

commit 5daebc477da4dfeb31ae193d83084def58fd2697 upstream.

Commit 85efde6f4e0d ("make exported headers use strict posix types")
changed the asm-generic siginfo.h to use the __kernel_* types, and
commit 3a471cbc081b ("remove __KERNEL_STRICT_NAMES") make the internal
types accessible only to the kernel, but the MIPS implementation hasn't
been updated to match.

Switch to proper types now so that the exported asm/siginfo.h won't
produce quite so many compiler errors when included alone by a user
program.

Signed-off-by: James Hogan 
Cc: Christopher Ferris 
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/12477/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/include/uapi/asm/siginfo.h |   18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

--- a/arch/mips/include/uapi/asm/siginfo.h
+++ b/arch/mips/include/uapi/asm/siginfo.h
@@ -42,13 +42,13 @@ typedef struct siginfo {
 
/* kill() */
struct {
-   pid_t _pid; /* sender's pid */
+   __kernel_pid_t _pid;/* sender's pid */
__ARCH_SI_UID_T _uid;   /* sender's uid */
} _kill;
 
/* POSIX.1b timers */
struct {
-   timer_t _tid;   /* timer id */
+   __kernel_timer_t _tid;  /* timer id */
int _overrun;   /* overrun count */
char _pad[sizeof( __ARCH_SI_UID_T) - sizeof(int)];
sigval_t _sigval;   /* same as below */
@@ -57,26 +57,26 @@ typedef struct siginfo {
 
/* POSIX.1b signals */
struct {
-   pid_t _pid; /* sender's pid */
+   __kernel_pid_t _pid;/* sender's pid */
__ARCH_SI_UID_T _uid;   /* sender's uid */
sigval_t _sigval;
} _rt;
 
/* SIGCHLD */
struct {
-   pid_t _pid; /* which child */
+   __kernel_pid_t _pid;/* which child */
__ARCH_SI_UID_T _uid;   /* sender's uid */
int _status;/* exit code */
-   clock_t _utime;
-   clock_t _stime;
+   __kernel_clock_t _utime;
+   __kernel_clock_t _stime;
} _sigchld;
 
/* IRIX SIGCHLD */
struct {
-   pid_t _pid; /* which child */
-   clock_t _utime;
+   __kernel_pid_t _pid;/* which child */
+   __kernel_clock_t _utime;
int _status;/* exit code */
-   clock_t _stime;
+   __kernel_clock_t _stime;
} _irix_sigchld;
 
/* SIGILL, SIGFPE, SIGSEGV, SIGBUS */

[PATCH 4.4 08/99] MIPS: Fix watchpoint restoration

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: James Hogan 

commit a7e89326b415b5d81c4b1016fd4a40db861eb58d upstream.

Commit f51246efee2b ("MIPS: Get rid of finish_arch_switch().") moved the
__restore_watch() call from finish_arch_switch() (i.e. after resume()
returns) to before the resume() call in switch_to(). This results in
watchpoints only being restored when a task is descheduled, preventing
the watchpoints from being effective most of the time, except due to
chance before the watchpoints are lazily removed.

Fix the call sequence from switch_to() through to
mips_install_watch_registers() to pass the task_struct pointer of the
next task, instead of using current. This allows the watchpoints for the
next (non-current) task to be restored without reintroducing
finish_arch_switch().

Fixes: f51246efee2b ("MIPS: Get rid of finish_arch_switch().")
Signed-off-by: James Hogan 
Cc: Paul Burton 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12726/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/include/asm/switch_to.h |2 +-
 arch/mips/include/asm/watch.h |   10 +-
 arch/mips/kernel/pm.c |2 +-
 arch/mips/kernel/watch.c  |5 ++---
 4 files changed, 9 insertions(+), 10 deletions(-)

--- a/arch/mips/include/asm/switch_to.h
+++ b/arch/mips/include/asm/switch_to.h
@@ -105,7 +105,7 @@ do {
\
__clear_software_ll_bit();  \
if (cpu_has_userlocal)  \
write_c0_userlocal(task_thread_info(next)->tp_value);   \
-   __restore_watch();  \
+   __restore_watch(next);  \
(last) = resume(prev, next, task_thread_info(next));\
 } while (0)
 
--- a/arch/mips/include/asm/watch.h
+++ b/arch/mips/include/asm/watch.h
@@ -12,21 +12,21 @@
 
 #include 
 
-void mips_install_watch_registers(void);
+void mips_install_watch_registers(struct task_struct *t);
 void mips_read_watch_registers(void);
 void mips_clear_watch_registers(void);
 void mips_probe_watch_registers(struct cpuinfo_mips *c);
 
 #ifdef CONFIG_HARDWARE_WATCHPOINTS
-#define __restore_watch() do { \
+#define __restore_watch(task) do { \
if (unlikely(test_bit(TIF_LOAD_WATCH,   \
- _thread_info()->flags))) {\
-   mips_install_watch_registers(); \
+ _thread_info(task)->flags))) {   \
+   mips_install_watch_registers(task); \
}   \
 } while (0)
 
 #else
-#define __restore_watch() do {} while (0)
+#define __restore_watch(task) do {} while (0)
 #endif
 
 #endif /* _ASM_WATCH_H */
--- a/arch/mips/kernel/pm.c
+++ b/arch/mips/kernel/pm.c
@@ -56,7 +56,7 @@ static void mips_cpu_restore(void)
write_c0_userlocal(current_thread_info()->tp_value);
 
/* Restore watch registers */
-   __restore_watch();
+   __restore_watch(current);
 }
 
 /**
--- a/arch/mips/kernel/watch.c
+++ b/arch/mips/kernel/watch.c
@@ -15,10 +15,9 @@
  * Install the watch registers for the current thread. A maximum of
  * four registers are installed although the machine may have more.
  */
-void mips_install_watch_registers(void)
+void mips_install_watch_registers(struct task_struct *t)
 {
-   struct mips3264_watch_reg_state *watches =
-   >thread.watch.mips3264;
+   struct mips3264_watch_reg_state *watches = >thread.watch.mips3264;
switch (current_cpu_data.watch_reg_use_cnt) {
default:
BUG();

[PATCH 4.4 06/99] MIPS: Fix siginfo.h to use strict posix types

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: James Hogan 

commit 5daebc477da4dfeb31ae193d83084def58fd2697 upstream.

Commit 85efde6f4e0d ("make exported headers use strict posix types")
changed the asm-generic siginfo.h to use the __kernel_* types, and
commit 3a471cbc081b ("remove __KERNEL_STRICT_NAMES") make the internal
types accessible only to the kernel, but the MIPS implementation hasn't
been updated to match.

Switch to proper types now so that the exported asm/siginfo.h won't
produce quite so many compiler errors when included alone by a user
program.

Signed-off-by: James Hogan 
Cc: Christopher Ferris 
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/12477/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/include/uapi/asm/siginfo.h |   18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

--- a/arch/mips/include/uapi/asm/siginfo.h
+++ b/arch/mips/include/uapi/asm/siginfo.h
@@ -42,13 +42,13 @@ typedef struct siginfo {
 
/* kill() */
struct {
-   pid_t _pid; /* sender's pid */
+   __kernel_pid_t _pid;/* sender's pid */
__ARCH_SI_UID_T _uid;   /* sender's uid */
} _kill;
 
/* POSIX.1b timers */
struct {
-   timer_t _tid;   /* timer id */
+   __kernel_timer_t _tid;  /* timer id */
int _overrun;   /* overrun count */
char _pad[sizeof( __ARCH_SI_UID_T) - sizeof(int)];
sigval_t _sigval;   /* same as below */
@@ -57,26 +57,26 @@ typedef struct siginfo {
 
/* POSIX.1b signals */
struct {
-   pid_t _pid; /* sender's pid */
+   __kernel_pid_t _pid;/* sender's pid */
__ARCH_SI_UID_T _uid;   /* sender's uid */
sigval_t _sigval;
} _rt;
 
/* SIGCHLD */
struct {
-   pid_t _pid; /* which child */
+   __kernel_pid_t _pid;/* which child */
__ARCH_SI_UID_T _uid;   /* sender's uid */
int _status;/* exit code */
-   clock_t _utime;
-   clock_t _stime;
+   __kernel_clock_t _utime;
+   __kernel_clock_t _stime;
} _sigchld;
 
/* IRIX SIGCHLD */
struct {
-   pid_t _pid; /* which child */
-   clock_t _utime;
+   __kernel_pid_t _pid;/* which child */
+   __kernel_clock_t _utime;
int _status;/* exit code */
-   clock_t _stime;
+   __kernel_clock_t _stime;
} _irix_sigchld;
 
/* SIGILL, SIGFPE, SIGSEGV, SIGBUS */

[PATCH 4.4 09/99] MIPS: Handle highmem pages in __update_cache

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Paul Burton 

commit f4281bba818105c7c91799abe40bc05c0dbdaa25 upstream.

The following patch will expose __update_cache to highmem pages. Handle
them by mapping them in for the duration of the cache maintenance, just
like in __flush_dcache_page. The code for that isn't shared because we
need the page address in __update_cache so sharing became messy. Given
that the entirity is an extra 5 lines, just duplicate it.

Signed-off-by: Paul Burton 
Cc: Lars Persson 
Cc: Andrew Morton 
Cc: Jerome Marchand 
Cc: Kirill A. Shutemov 
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/12721/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/mm/cache.c |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

--- a/arch/mips/mm/cache.c
+++ b/arch/mips/mm/cache.c
@@ -143,9 +143,17 @@ void __update_cache(struct vm_area_struc
return;
page = pfn_to_page(pfn);
if (page_mapping(page) && Page_dcache_dirty(page)) {
-   addr = (unsigned long) page_address(page);
+   if (PageHighMem(page))
+   addr = (unsigned long)kmap_atomic(page);
+   else
+   addr = (unsigned long)page_address(page);
+
if (exec || pages_do_alias(addr, address & PAGE_MASK))
flush_data_cache_page(addr);
+
+   if (PageHighMem(page))
+   __kunmap_atomic((void *)addr);
+
ClearPageDcacheDirty(page);
}
 }

[PATCH 4.4 09/99] MIPS: Handle highmem pages in __update_cache

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Paul Burton 

commit f4281bba818105c7c91799abe40bc05c0dbdaa25 upstream.

The following patch will expose __update_cache to highmem pages. Handle
them by mapping them in for the duration of the cache maintenance, just
like in __flush_dcache_page. The code for that isn't shared because we
need the page address in __update_cache so sharing became messy. Given
that the entirity is an extra 5 lines, just duplicate it.

Signed-off-by: Paul Burton 
Cc: Lars Persson 
Cc: Andrew Morton 
Cc: Jerome Marchand 
Cc: Kirill A. Shutemov 
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/12721/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/mm/cache.c |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

--- a/arch/mips/mm/cache.c
+++ b/arch/mips/mm/cache.c
@@ -143,9 +143,17 @@ void __update_cache(struct vm_area_struc
return;
page = pfn_to_page(pfn);
if (page_mapping(page) && Page_dcache_dirty(page)) {
-   addr = (unsigned long) page_address(page);
+   if (PageHighMem(page))
+   addr = (unsigned long)kmap_atomic(page);
+   else
+   addr = (unsigned long)page_address(page);
+
if (exec || pages_do_alias(addr, address & PAGE_MASK))
flush_data_cache_page(addr);
+
+   if (PageHighMem(page))
+   __kunmap_atomic((void *)addr);
+
ClearPageDcacheDirty(page);
}
 }

[PATCH 4.4 15/99] MIPS: Fix MSA ld_*/st_* asm macros to use PTR_ADDU

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: James Hogan 

commit ea1688573426adc2587ed52d086b51c7c62eaca3 upstream.

The MSA ld_*/st_* assembler macros for when the toolchain doesn't
support MSA use addu to offset the base address. However it is a virtual
memory pointer so fix it to use PTR_ADDU which expands to daddu for
64-bit kernels.

Signed-off-by: James Hogan 
Cc: Paul Burton 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13062/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/include/asm/asmmacro.h |   16 
 1 file changed, 8 insertions(+), 8 deletions(-)

--- a/arch/mips/include/asm/asmmacro.h
+++ b/arch/mips/include/asm/asmmacro.h
@@ -393,7 +393,7 @@
.setpush
.setnoat
SET_HARDFLOAT
-   addu$1, \base, \off
+   PTR_ADDU $1, \base, \off
.word   LDB_MSA_INSN | (\wd << 6)
.setpop
.endm
@@ -402,7 +402,7 @@
.setpush
.setnoat
SET_HARDFLOAT
-   addu$1, \base, \off
+   PTR_ADDU $1, \base, \off
.word   LDH_MSA_INSN | (\wd << 6)
.setpop
.endm
@@ -411,7 +411,7 @@
.setpush
.setnoat
SET_HARDFLOAT
-   addu$1, \base, \off
+   PTR_ADDU $1, \base, \off
.word   LDW_MSA_INSN | (\wd << 6)
.setpop
.endm
@@ -420,7 +420,7 @@
.setpush
.setnoat
SET_HARDFLOAT
-   addu$1, \base, \off
+   PTR_ADDU $1, \base, \off
.word   LDD_MSA_INSN | (\wd << 6)
.setpop
.endm
@@ -429,7 +429,7 @@
.setpush
.setnoat
SET_HARDFLOAT
-   addu$1, \base, \off
+   PTR_ADDU $1, \base, \off
.word   STB_MSA_INSN | (\wd << 6)
.setpop
.endm
@@ -438,7 +438,7 @@
.setpush
.setnoat
SET_HARDFLOAT
-   addu$1, \base, \off
+   PTR_ADDU $1, \base, \off
.word   STH_MSA_INSN | (\wd << 6)
.setpop
.endm
@@ -447,7 +447,7 @@
.setpush
.setnoat
SET_HARDFLOAT
-   addu$1, \base, \off
+   PTR_ADDU $1, \base, \off
.word   STW_MSA_INSN | (\wd << 6)
.setpop
.endm
@@ -456,7 +456,7 @@
.setpush
.setnoat
SET_HARDFLOAT
-   addu$1, \base, \off
+   PTR_ADDU $1, \base, \off
.word   STD_MSA_INSN | (\wd << 6)
.setpop
.endm

[PATCH 4.4 14/99] MIPS: Use copy_s.fmt rather than copy_u.fmt

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Paul Burton 

commit 8a3c8b48aca8771bff3536e40aa26ffb311699d1 upstream.

In revision 1.12 of the MSA specification, the copy_u.w instruction has
been removed for MIPS32 & the copy_u.d instruction has been removed for
MIPS64. Newer toolchains (eg. Codescape SDK essentials 2015.10) will
complain about this like so:

arch/mips/kernel/r4k_fpu.S:290: Error: opcode not supported on this
processor: mips32r2 (mips32r2) `copy_u.w $1,$w26[3]'

Since we always copy to the width of a GPR, simply use copy_s instead of
copy_u to fix this.

Signed-off-by: Paul Burton 
Signed-off-by: James Hogan 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13061/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/include/asm/asmmacro.h |   24 
 arch/mips/kernel/r4k_fpu.S   |   10 +-
 2 files changed, 17 insertions(+), 17 deletions(-)

--- a/arch/mips/include/asm/asmmacro.h
+++ b/arch/mips/include/asm/asmmacro.h
@@ -298,21 +298,21 @@
.setpop
.endm
 
-   .macro  copy_u_wws, n
+   .macro  copy_s_wws, n
.setpush
.setmips32r2
.setfp=64
.setmsa
-   copy_u.w $1, $w\ws[\n]
+   copy_s.w $1, $w\ws[\n]
.setpop
.endm
 
-   .macro  copy_u_dws, n
+   .macro  copy_s_dws, n
.setpush
.setmips64r2
.setfp=64
.setmsa
-   copy_u.d $1, $w\ws[\n]
+   copy_s.d $1, $w\ws[\n]
.setpop
.endm
 
@@ -346,8 +346,8 @@
 #define STH_MSA_INSN   0x5800081f
 #define STW_MSA_INSN   0x5800082f
 #define STD_MSA_INSN   0x5800083f
-#define COPY_UW_MSA_INSN   0x58f00056
-#define COPY_UD_MSA_INSN   0x58f80056
+#define COPY_SW_MSA_INSN   0x58b00056
+#define COPY_SD_MSA_INSN   0x58b80056
 #define INSERT_W_MSA_INSN  0x59300816
 #define INSERT_D_MSA_INSN  0x59380816
 #else
@@ -361,8 +361,8 @@
 #define STH_MSA_INSN   0x78000825
 #define STW_MSA_INSN   0x78000826
 #define STD_MSA_INSN   0x78000827
-#define COPY_UW_MSA_INSN   0x78f00059
-#define COPY_UD_MSA_INSN   0x78f80059
+#define COPY_SW_MSA_INSN   0x78b00059
+#define COPY_SD_MSA_INSN   0x78b80059
 #define INSERT_W_MSA_INSN  0x79300819
 #define INSERT_D_MSA_INSN  0x79380819
 #endif
@@ -461,21 +461,21 @@
.setpop
.endm
 
-   .macro  copy_u_wws, n
+   .macro  copy_s_wws, n
.setpush
.setnoat
SET_HARDFLOAT
.insn
-   .word   COPY_UW_MSA_INSN | (\n << 16) | (\ws << 11)
+   .word   COPY_SW_MSA_INSN | (\n << 16) | (\ws << 11)
.setpop
.endm
 
-   .macro  copy_u_dws, n
+   .macro  copy_s_dws, n
.setpush
.setnoat
SET_HARDFLOAT
.insn
-   .word   COPY_UD_MSA_INSN | (\n << 16) | (\ws << 11)
+   .word   COPY_SD_MSA_INSN | (\n << 16) | (\ws << 11)
.setpop
.endm
 
--- a/arch/mips/kernel/r4k_fpu.S
+++ b/arch/mips/kernel/r4k_fpu.S
@@ -244,17 +244,17 @@ LEAF(\name)
.setpush
.setnoat
 #ifdef CONFIG_64BIT
-   copy_u_d \wr, 1
+   copy_s_d \wr, 1
EX sd   $1, \off(\base)
 #elif defined(CONFIG_CPU_LITTLE_ENDIAN)
-   copy_u_w \wr, 2
+   copy_s_w \wr, 2
EX sw   $1, \off(\base)
-   copy_u_w \wr, 3
+   copy_s_w \wr, 3
EX sw   $1, (\off+4)(\base)
 #else /* CONFIG_CPU_BIG_ENDIAN */
-   copy_u_w \wr, 2
+   copy_s_w \wr, 2
EX sw   $1, (\off+4)(\base)
-   copy_u_w \wr, 3
+   copy_s_w \wr, 3
EX sw   $1, \off(\base)
 #endif
.setpop

[PATCH 4.4 04/99] MIPS: Dont unwind to user mode with EVA

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: James Hogan 

commit a816b306c62195b7c43c92cb13330821a96bdc27 upstream.

When unwinding through IRQs and exceptions, the unwinding only continues
if the PC is a kernel text address, however since EVA it is possible for
user and kernel address ranges to overlap, potentially allowing
unwinding to continue to user mode if the user PC happens to be in the
kernel text address range.

Adjust the check to also ensure that the register state from before the
exception is actually running in kernel mode, i.e. !user_mode(regs).

I don't believe any harm can come of this problem, since the PC is only
output, the stack pointer is checked to ensure it resides within the
task's stack page before it is dereferenced in search of the return
address, and the return address register is similarly only output (if
the PC is in a leaf function or the beginning of a non-leaf function).

However unwind_stack() is only meant for unwinding kernel code, so to be
correct the unwind should stop there.

Signed-off-by: James Hogan 
Reviewed-by: Leonid Yegoshin 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/11700/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/kernel/process.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/mips/kernel/process.c
+++ b/arch/mips/kernel/process.c
@@ -457,7 +457,7 @@ unsigned long notrace unwind_stack_by_ad
*sp + sizeof(*regs) <= stack_page + THREAD_SIZE - 32) {
regs = (struct pt_regs *)*sp;
pc = regs->cp0_epc;
-   if (__kernel_text_address(pc)) {
+   if (!user_mode(regs) && __kernel_text_address(pc)) {
*sp = regs->regs[29];
*ra = regs->regs[31];
return pc;

[PATCH 4.4 15/99] MIPS: Fix MSA ld_*/st_* asm macros to use PTR_ADDU

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: James Hogan 

commit ea1688573426adc2587ed52d086b51c7c62eaca3 upstream.

The MSA ld_*/st_* assembler macros for when the toolchain doesn't
support MSA use addu to offset the base address. However it is a virtual
memory pointer so fix it to use PTR_ADDU which expands to daddu for
64-bit kernels.

Signed-off-by: James Hogan 
Cc: Paul Burton 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13062/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/include/asm/asmmacro.h |   16 
 1 file changed, 8 insertions(+), 8 deletions(-)

--- a/arch/mips/include/asm/asmmacro.h
+++ b/arch/mips/include/asm/asmmacro.h
@@ -393,7 +393,7 @@
.setpush
.setnoat
SET_HARDFLOAT
-   addu$1, \base, \off
+   PTR_ADDU $1, \base, \off
.word   LDB_MSA_INSN | (\wd << 6)
.setpop
.endm
@@ -402,7 +402,7 @@
.setpush
.setnoat
SET_HARDFLOAT
-   addu$1, \base, \off
+   PTR_ADDU $1, \base, \off
.word   LDH_MSA_INSN | (\wd << 6)
.setpop
.endm
@@ -411,7 +411,7 @@
.setpush
.setnoat
SET_HARDFLOAT
-   addu$1, \base, \off
+   PTR_ADDU $1, \base, \off
.word   LDW_MSA_INSN | (\wd << 6)
.setpop
.endm
@@ -420,7 +420,7 @@
.setpush
.setnoat
SET_HARDFLOAT
-   addu$1, \base, \off
+   PTR_ADDU $1, \base, \off
.word   LDD_MSA_INSN | (\wd << 6)
.setpop
.endm
@@ -429,7 +429,7 @@
.setpush
.setnoat
SET_HARDFLOAT
-   addu$1, \base, \off
+   PTR_ADDU $1, \base, \off
.word   STB_MSA_INSN | (\wd << 6)
.setpop
.endm
@@ -438,7 +438,7 @@
.setpush
.setnoat
SET_HARDFLOAT
-   addu$1, \base, \off
+   PTR_ADDU $1, \base, \off
.word   STH_MSA_INSN | (\wd << 6)
.setpop
.endm
@@ -447,7 +447,7 @@
.setpush
.setnoat
SET_HARDFLOAT
-   addu$1, \base, \off
+   PTR_ADDU $1, \base, \off
.word   STW_MSA_INSN | (\wd << 6)
.setpop
.endm
@@ -456,7 +456,7 @@
.setpush
.setnoat
SET_HARDFLOAT
-   addu$1, \base, \off
+   PTR_ADDU $1, \base, \off
.word   STD_MSA_INSN | (\wd << 6)
.setpop
.endm

[PATCH 4.4 14/99] MIPS: Use copy_s.fmt rather than copy_u.fmt

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Paul Burton 

commit 8a3c8b48aca8771bff3536e40aa26ffb311699d1 upstream.

In revision 1.12 of the MSA specification, the copy_u.w instruction has
been removed for MIPS32 & the copy_u.d instruction has been removed for
MIPS64. Newer toolchains (eg. Codescape SDK essentials 2015.10) will
complain about this like so:

arch/mips/kernel/r4k_fpu.S:290: Error: opcode not supported on this
processor: mips32r2 (mips32r2) `copy_u.w $1,$w26[3]'

Since we always copy to the width of a GPR, simply use copy_s instead of
copy_u to fix this.

Signed-off-by: Paul Burton 
Signed-off-by: James Hogan 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13061/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/include/asm/asmmacro.h |   24 
 arch/mips/kernel/r4k_fpu.S   |   10 +-
 2 files changed, 17 insertions(+), 17 deletions(-)

--- a/arch/mips/include/asm/asmmacro.h
+++ b/arch/mips/include/asm/asmmacro.h
@@ -298,21 +298,21 @@
.setpop
.endm
 
-   .macro  copy_u_wws, n
+   .macro  copy_s_wws, n
.setpush
.setmips32r2
.setfp=64
.setmsa
-   copy_u.w $1, $w\ws[\n]
+   copy_s.w $1, $w\ws[\n]
.setpop
.endm
 
-   .macro  copy_u_dws, n
+   .macro  copy_s_dws, n
.setpush
.setmips64r2
.setfp=64
.setmsa
-   copy_u.d $1, $w\ws[\n]
+   copy_s.d $1, $w\ws[\n]
.setpop
.endm
 
@@ -346,8 +346,8 @@
 #define STH_MSA_INSN   0x5800081f
 #define STW_MSA_INSN   0x5800082f
 #define STD_MSA_INSN   0x5800083f
-#define COPY_UW_MSA_INSN   0x58f00056
-#define COPY_UD_MSA_INSN   0x58f80056
+#define COPY_SW_MSA_INSN   0x58b00056
+#define COPY_SD_MSA_INSN   0x58b80056
 #define INSERT_W_MSA_INSN  0x59300816
 #define INSERT_D_MSA_INSN  0x59380816
 #else
@@ -361,8 +361,8 @@
 #define STH_MSA_INSN   0x78000825
 #define STW_MSA_INSN   0x78000826
 #define STD_MSA_INSN   0x78000827
-#define COPY_UW_MSA_INSN   0x78f00059
-#define COPY_UD_MSA_INSN   0x78f80059
+#define COPY_SW_MSA_INSN   0x78b00059
+#define COPY_SD_MSA_INSN   0x78b80059
 #define INSERT_W_MSA_INSN  0x79300819
 #define INSERT_D_MSA_INSN  0x79380819
 #endif
@@ -461,21 +461,21 @@
.setpop
.endm
 
-   .macro  copy_u_wws, n
+   .macro  copy_s_wws, n
.setpush
.setnoat
SET_HARDFLOAT
.insn
-   .word   COPY_UW_MSA_INSN | (\n << 16) | (\ws << 11)
+   .word   COPY_SW_MSA_INSN | (\n << 16) | (\ws << 11)
.setpop
.endm
 
-   .macro  copy_u_dws, n
+   .macro  copy_s_dws, n
.setpush
.setnoat
SET_HARDFLOAT
.insn
-   .word   COPY_UD_MSA_INSN | (\n << 16) | (\ws << 11)
+   .word   COPY_SD_MSA_INSN | (\n << 16) | (\ws << 11)
.setpop
.endm
 
--- a/arch/mips/kernel/r4k_fpu.S
+++ b/arch/mips/kernel/r4k_fpu.S
@@ -244,17 +244,17 @@ LEAF(\name)
.setpush
.setnoat
 #ifdef CONFIG_64BIT
-   copy_u_d \wr, 1
+   copy_s_d \wr, 1
EX sd   $1, \off(\base)
 #elif defined(CONFIG_CPU_LITTLE_ENDIAN)
-   copy_u_w \wr, 2
+   copy_s_w \wr, 2
EX sw   $1, \off(\base)
-   copy_u_w \wr, 3
+   copy_s_w \wr, 3
EX sw   $1, (\off+4)(\base)
 #else /* CONFIG_CPU_BIG_ENDIAN */
-   copy_u_w \wr, 2
+   copy_s_w \wr, 2
EX sw   $1, (\off+4)(\base)
-   copy_u_w \wr, 3
+   copy_s_w \wr, 3
EX sw   $1, \off(\base)
 #endif
.setpop

[PATCH 4.4 04/99] MIPS: Dont unwind to user mode with EVA

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: James Hogan 

commit a816b306c62195b7c43c92cb13330821a96bdc27 upstream.

When unwinding through IRQs and exceptions, the unwinding only continues
if the PC is a kernel text address, however since EVA it is possible for
user and kernel address ranges to overlap, potentially allowing
unwinding to continue to user mode if the user PC happens to be in the
kernel text address range.

Adjust the check to also ensure that the register state from before the
exception is actually running in kernel mode, i.e. !user_mode(regs).

I don't believe any harm can come of this problem, since the PC is only
output, the stack pointer is checked to ensure it resides within the
task's stack page before it is dereferenced in search of the return
address, and the return address register is similarly only output (if
the PC is in a leaf function or the beginning of a non-leaf function).

However unwind_stack() is only meant for unwinding kernel code, so to be
correct the unwind should stop there.

Signed-off-by: James Hogan 
Reviewed-by: Leonid Yegoshin 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/11700/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/kernel/process.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/mips/kernel/process.c
+++ b/arch/mips/kernel/process.c
@@ -457,7 +457,7 @@ unsigned long notrace unwind_stack_by_ad
*sp + sizeof(*regs) <= stack_page + THREAD_SIZE - 32) {
regs = (struct pt_regs *)*sp;
pc = regs->cp0_epc;
-   if (__kernel_text_address(pc)) {
+   if (!user_mode(regs) && __kernel_text_address(pc)) {
*sp = regs->regs[29];
*ra = regs->regs[31];
return pc;

[PATCH 4.4 05/99] MIPS: Avoid using unwind_stack() with usermode

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: James Hogan 

commit 81a76d7119f63c359750e4adeff922a31ad1135f upstream.

When showing backtraces in response to traps, for example crashes and
address errors (usually unaligned accesses) when they are set in debugfs
to be reported, unwind_stack will be used if the PC was in the kernel
text address range. However since EVA it is possible for user and kernel
address ranges to overlap, and even without EVA userland can still
trigger an address error by jumping to a KSeg0 address.

Adjust the check to also ensure that it was running in kernel mode. I
don't believe any harm can come of this problem, since unwind_stack() is
sufficiently defensive, however it is only meant for unwinding kernel
code, so to be correct it should use the raw backtracing instead.

Signed-off-by: James Hogan 
Reviewed-by: Leonid Yegoshin 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/11701/
Signed-off-by: Ralf Baechle 
(cherry picked from commit d2941a975ac745c607dfb590e92bb30bc352dad9)
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/kernel/traps.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -144,7 +144,7 @@ static void show_backtrace(struct task_s
if (!task)
task = current;
 
-   if (raw_show_trace || !__kernel_text_address(pc)) {
+   if (raw_show_trace || user_mode(regs) || !__kernel_text_address(pc)) {
show_raw_backtrace(sp);
return;
}

[PATCH 4.4 28/99] ARM: dts: at91: fix typo in sama5d2 PIN_PD24 description

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Florian Vallee 

commit b1f3a3b03eb5f61b4051e2da9aa15653e705e111 upstream.

Fix a typo on PIN_PD24 for UTXD2 and FLEXCOM4_IO3 which were
wrongly linked to PIN_PD23).

Signed-off-by: Florian Vallee 
Fixes: 7f16cb676c00 ("ARM: at91/dt: add sama5d2 pinmux")
[nicolas.fe...@atmel.com: add commit message, changed subject]
Signed-off-by: Nicolas Ferre 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm/boot/dts/sama5d2-pinfunc.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/arm/boot/dts/sama5d2-pinfunc.h
+++ b/arch/arm/boot/dts/sama5d2-pinfunc.h
@@ -837,8 +837,8 @@
 #define PIN_PD23__ISC_FIELDPINMUX_PIN(PIN_PD23, 6, 4)
 #define PIN_PD24   120
 #define PIN_PD24__GPIO PINMUX_PIN(PIN_PD24, 0, 0)
-#define PIN_PD24__UTXD2PINMUX_PIN(PIN_PD23, 1, 2)
-#define PIN_PD24__FLEXCOM4_IO3 PINMUX_PIN(PIN_PD23, 3, 3)
+#define PIN_PD24__UTXD2PINMUX_PIN(PIN_PD24, 1, 2)
+#define PIN_PD24__FLEXCOM4_IO3 PINMUX_PIN(PIN_PD24, 3, 3)
 #define PIN_PD25   121
 #define PIN_PD25__GPIO PINMUX_PIN(PIN_PD25, 0, 0)
 #define PIN_PD25__SPI1_SPCKPINMUX_PIN(PIN_PD25, 1, 3)

[PATCH 4.4 19/99] MIPS: ptrace: Prevent writes to read-only FCSR bits

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Maciej W. Rozycki 

commit abf378be49f38c4d3e23581d3df3fa9f1b1b11d2 upstream.

Correct the cases missed with commit 9b26616c8d9d ("MIPS: Respect the
ISA level in FCSR handling") and prevent writes to read-only FCSR bits
there.

This in particular applies to FP context initialisation where any IEEE
754-2008 bits preset by `mips_set_personality_nan' are cleared before
the relevant ptrace(2) call takes effect and the PTRACE_POKEUSR request
addressing FPC_CSR where no masking of read-only FCSR bits is done.

Remove the FCSR clearing from FP context initialisation then and unify
PTRACE_POKEUSR/FPC_CSR and PTRACE_SETFPREGS handling, by factoring out
code from `ptrace_setfpregs' and calling it from both places.

This mostly matters to soft float configurations where the emulator can
be switched this way to a mode which should not be accessible and cannot
be set with the CTC1 instruction.  With hard float configurations any
effect is transient anyway as read-only bits will retain their values at
the time the FP context is restored.

Signed-off-by: Maciej W. Rozycki 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13239/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/kernel/ptrace.c |   28 +++-
 1 file changed, 19 insertions(+), 9 deletions(-)

--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -57,8 +57,7 @@ static void init_fp_ctx(struct task_stru
/* Begin with data registers set to all 1s... */
memset(>thread.fpu.fpr, ~0, sizeof(target->thread.fpu.fpr));
 
-   /* ...and FCSR zeroed */
-   target->thread.fpu.fcr31 = 0;
+   /* FCSR has been preset by `mips_set_personality_nan'.  */
 
/*
 * Record that the target has "used" math, such that the context
@@ -80,6 +79,22 @@ void ptrace_disable(struct task_struct *
 }
 
 /*
+ * Poke at FCSR according to its mask.  Don't set the cause bits as
+ * this is currently not handled correctly in FP context restoration
+ * and will cause an oops if a corresponding enable bit is set.
+ */
+static void ptrace_setfcr31(struct task_struct *child, u32 value)
+{
+   u32 fcr31;
+   u32 mask;
+
+   value &= ~FPU_CSR_ALL_X;
+   fcr31 = child->thread.fpu.fcr31;
+   mask = boot_cpu_data.fpu_msk31;
+   child->thread.fpu.fcr31 = (value & ~mask) | (fcr31 & mask);
+}
+
+/*
  * Read a general register set. We always use the 64-bit format, even
  * for 32-bit kernels and for 32-bit processes on a 64-bit kernel.
  * Registers are sign extended to fill the available space.
@@ -159,9 +174,7 @@ int ptrace_setfpregs(struct task_struct
 {
union fpureg *fregs;
u64 fpr_val;
-   u32 fcr31;
u32 value;
-   u32 mask;
int i;
 
if (!access_ok(VERIFY_READ, data, 33 * 8))
@@ -176,10 +189,7 @@ int ptrace_setfpregs(struct task_struct
}
 
__get_user(value, data + 64);
-   value &= ~FPU_CSR_ALL_X;
-   fcr31 = child->thread.fpu.fcr31;
-   mask = boot_cpu_data.fpu_msk31;
-   child->thread.fpu.fcr31 = (value & ~mask) | (fcr31 & mask);
+   ptrace_setfcr31(child, value);
 
/* FIR may not be written.  */
 
@@ -809,7 +819,7 @@ long arch_ptrace(struct task_struct *chi
break;
 #endif
case FPC_CSR:
-   child->thread.fpu.fcr31 = data & ~FPU_CSR_ALL_X;
+   ptrace_setfcr31(child, data);
break;
case DSP_BASE ... DSP_BASE + 5: {
dspreg_t *dregs;

[PATCH 4.4 22/99] MIPS: lib: Mark intrinsics notrace

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Harvey Hunt 

commit aedcfbe06558a9f53002e82d5be64c6c94687726 upstream.

On certain MIPS32 devices, the ftrace tracer "function_graph" uses
__lshrdi3() during the capturing of trace data. ftrace then attempts to
trace __lshrdi3() which leads to infinite recursion and a stack overflow.
Fix this by marking __lshrdi3() as notrace. Mark the other compiler
intrinsics as notrace in case the compiler decides to use them in the
ftrace path.

Signed-off-by: Harvey Hunt 
Cc: 
Cc: 
Patchwork: https://patchwork.linux-mips.org/patch/13354/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/lib/ashldi3.c |2 +-
 arch/mips/lib/ashrdi3.c |2 +-
 arch/mips/lib/bswapdi.c |2 +-
 arch/mips/lib/bswapsi.c |2 +-
 arch/mips/lib/cmpdi2.c  |2 +-
 arch/mips/lib/lshrdi3.c |2 +-
 arch/mips/lib/ucmpdi2.c |2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)

--- a/arch/mips/lib/ashldi3.c
+++ b/arch/mips/lib/ashldi3.c
@@ -2,7 +2,7 @@
 
 #include "libgcc.h"
 
-long long __ashldi3(long long u, word_type b)
+long long notrace __ashldi3(long long u, word_type b)
 {
DWunion uu, w;
word_type bm;
--- a/arch/mips/lib/ashrdi3.c
+++ b/arch/mips/lib/ashrdi3.c
@@ -2,7 +2,7 @@
 
 #include "libgcc.h"
 
-long long __ashrdi3(long long u, word_type b)
+long long notrace __ashrdi3(long long u, word_type b)
 {
DWunion uu, w;
word_type bm;
--- a/arch/mips/lib/bswapdi.c
+++ b/arch/mips/lib/bswapdi.c
@@ -1,6 +1,6 @@
 #include 
 
-unsigned long long __bswapdi2(unsigned long long u)
+unsigned long long notrace __bswapdi2(unsigned long long u)
 {
return (((u) & 0xff00ull) >> 56) |
   (((u) & 0x00ffull) >> 40) |
--- a/arch/mips/lib/bswapsi.c
+++ b/arch/mips/lib/bswapsi.c
@@ -1,6 +1,6 @@
 #include 
 
-unsigned int __bswapsi2(unsigned int u)
+unsigned int notrace __bswapsi2(unsigned int u)
 {
return (((u) & 0xff00) >> 24) |
   (((u) & 0x00ff) >>  8) |
--- a/arch/mips/lib/cmpdi2.c
+++ b/arch/mips/lib/cmpdi2.c
@@ -2,7 +2,7 @@
 
 #include "libgcc.h"
 
-word_type __cmpdi2(long long a, long long b)
+word_type notrace __cmpdi2(long long a, long long b)
 {
const DWunion au = {
.ll = a
--- a/arch/mips/lib/lshrdi3.c
+++ b/arch/mips/lib/lshrdi3.c
@@ -2,7 +2,7 @@
 
 #include "libgcc.h"
 
-long long __lshrdi3(long long u, word_type b)
+long long notrace __lshrdi3(long long u, word_type b)
 {
DWunion uu, w;
word_type bm;
--- a/arch/mips/lib/ucmpdi2.c
+++ b/arch/mips/lib/ucmpdi2.c
@@ -2,7 +2,7 @@
 
 #include "libgcc.h"
 
-word_type __ucmpdi2(unsigned long long a, unsigned long long b)
+word_type notrace __ucmpdi2(unsigned long long a, unsigned long long b)
 {
const DWunion au = {.ll = a};
const DWunion bu = {.ll = b};

[PATCH 4.4 21/99] MIPS: Build microMIPS VDSO for microMIPS kernels

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: James Hogan 

commit bb93078e655be1e24d68f28f2756676e62c037ce upstream.

MicroMIPS kernels may be expected to run on microMIPS only cores which
don't support the normal MIPS instruction set, so be sure to pass the
-mmicromips flag through to the VDSO cflags.

Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
Signed-off-by: James Hogan 
Cc: Paul Burton 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13349/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/vdso/Makefile |1 +
 1 file changed, 1 insertion(+)

--- a/arch/mips/vdso/Makefile
+++ b/arch/mips/vdso/Makefile
@@ -5,6 +5,7 @@ obj-vdso-y := elf.o gettimeofday.o sigre
 ccflags-vdso := \
$(filter -I%,$(KBUILD_CFLAGS)) \
$(filter -E%,$(KBUILD_CFLAGS)) \
+   $(filter -mmicromips,$(KBUILD_CFLAGS)) \
$(filter -march=%,$(KBUILD_CFLAGS))
 cflags-vdso := $(ccflags-vdso) \
$(filter -W%,$(filter-out -Wa$(comma)%,$(KBUILD_CFLAGS))) \

[PATCH 4.4 05/99] MIPS: Avoid using unwind_stack() with usermode

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: James Hogan 

commit 81a76d7119f63c359750e4adeff922a31ad1135f upstream.

When showing backtraces in response to traps, for example crashes and
address errors (usually unaligned accesses) when they are set in debugfs
to be reported, unwind_stack will be used if the PC was in the kernel
text address range. However since EVA it is possible for user and kernel
address ranges to overlap, and even without EVA userland can still
trigger an address error by jumping to a KSeg0 address.

Adjust the check to also ensure that it was running in kernel mode. I
don't believe any harm can come of this problem, since unwind_stack() is
sufficiently defensive, however it is only meant for unwinding kernel
code, so to be correct it should use the raw backtracing instead.

Signed-off-by: James Hogan 
Reviewed-by: Leonid Yegoshin 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/11701/
Signed-off-by: Ralf Baechle 
(cherry picked from commit d2941a975ac745c607dfb590e92bb30bc352dad9)
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/kernel/traps.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -144,7 +144,7 @@ static void show_backtrace(struct task_s
if (!task)
task = current;
 
-   if (raw_show_trace || !__kernel_text_address(pc)) {
+   if (raw_show_trace || user_mode(regs) || !__kernel_text_address(pc)) {
show_raw_backtrace(sp);
return;
}

[PATCH 4.4 28/99] ARM: dts: at91: fix typo in sama5d2 PIN_PD24 description

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Florian Vallee 

commit b1f3a3b03eb5f61b4051e2da9aa15653e705e111 upstream.

Fix a typo on PIN_PD24 for UTXD2 and FLEXCOM4_IO3 which were
wrongly linked to PIN_PD23).

Signed-off-by: Florian Vallee 
Fixes: 7f16cb676c00 ("ARM: at91/dt: add sama5d2 pinmux")
[nicolas.fe...@atmel.com: add commit message, changed subject]
Signed-off-by: Nicolas Ferre 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm/boot/dts/sama5d2-pinfunc.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/arm/boot/dts/sama5d2-pinfunc.h
+++ b/arch/arm/boot/dts/sama5d2-pinfunc.h
@@ -837,8 +837,8 @@
 #define PIN_PD23__ISC_FIELDPINMUX_PIN(PIN_PD23, 6, 4)
 #define PIN_PD24   120
 #define PIN_PD24__GPIO PINMUX_PIN(PIN_PD24, 0, 0)
-#define PIN_PD24__UTXD2PINMUX_PIN(PIN_PD23, 1, 2)
-#define PIN_PD24__FLEXCOM4_IO3 PINMUX_PIN(PIN_PD23, 3, 3)
+#define PIN_PD24__UTXD2PINMUX_PIN(PIN_PD24, 1, 2)
+#define PIN_PD24__FLEXCOM4_IO3 PINMUX_PIN(PIN_PD24, 3, 3)
 #define PIN_PD25   121
 #define PIN_PD25__GPIO PINMUX_PIN(PIN_PD25, 0, 0)
 #define PIN_PD25__SPI1_SPCKPINMUX_PIN(PIN_PD25, 1, 3)

[PATCH 4.4 19/99] MIPS: ptrace: Prevent writes to read-only FCSR bits

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Maciej W. Rozycki 

commit abf378be49f38c4d3e23581d3df3fa9f1b1b11d2 upstream.

Correct the cases missed with commit 9b26616c8d9d ("MIPS: Respect the
ISA level in FCSR handling") and prevent writes to read-only FCSR bits
there.

This in particular applies to FP context initialisation where any IEEE
754-2008 bits preset by `mips_set_personality_nan' are cleared before
the relevant ptrace(2) call takes effect and the PTRACE_POKEUSR request
addressing FPC_CSR where no masking of read-only FCSR bits is done.

Remove the FCSR clearing from FP context initialisation then and unify
PTRACE_POKEUSR/FPC_CSR and PTRACE_SETFPREGS handling, by factoring out
code from `ptrace_setfpregs' and calling it from both places.

This mostly matters to soft float configurations where the emulator can
be switched this way to a mode which should not be accessible and cannot
be set with the CTC1 instruction.  With hard float configurations any
effect is transient anyway as read-only bits will retain their values at
the time the FP context is restored.

Signed-off-by: Maciej W. Rozycki 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13239/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/kernel/ptrace.c |   28 +++-
 1 file changed, 19 insertions(+), 9 deletions(-)

--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -57,8 +57,7 @@ static void init_fp_ctx(struct task_stru
/* Begin with data registers set to all 1s... */
memset(>thread.fpu.fpr, ~0, sizeof(target->thread.fpu.fpr));
 
-   /* ...and FCSR zeroed */
-   target->thread.fpu.fcr31 = 0;
+   /* FCSR has been preset by `mips_set_personality_nan'.  */
 
/*
 * Record that the target has "used" math, such that the context
@@ -80,6 +79,22 @@ void ptrace_disable(struct task_struct *
 }
 
 /*
+ * Poke at FCSR according to its mask.  Don't set the cause bits as
+ * this is currently not handled correctly in FP context restoration
+ * and will cause an oops if a corresponding enable bit is set.
+ */
+static void ptrace_setfcr31(struct task_struct *child, u32 value)
+{
+   u32 fcr31;
+   u32 mask;
+
+   value &= ~FPU_CSR_ALL_X;
+   fcr31 = child->thread.fpu.fcr31;
+   mask = boot_cpu_data.fpu_msk31;
+   child->thread.fpu.fcr31 = (value & ~mask) | (fcr31 & mask);
+}
+
+/*
  * Read a general register set. We always use the 64-bit format, even
  * for 32-bit kernels and for 32-bit processes on a 64-bit kernel.
  * Registers are sign extended to fill the available space.
@@ -159,9 +174,7 @@ int ptrace_setfpregs(struct task_struct
 {
union fpureg *fregs;
u64 fpr_val;
-   u32 fcr31;
u32 value;
-   u32 mask;
int i;
 
if (!access_ok(VERIFY_READ, data, 33 * 8))
@@ -176,10 +189,7 @@ int ptrace_setfpregs(struct task_struct
}
 
__get_user(value, data + 64);
-   value &= ~FPU_CSR_ALL_X;
-   fcr31 = child->thread.fpu.fcr31;
-   mask = boot_cpu_data.fpu_msk31;
-   child->thread.fpu.fcr31 = (value & ~mask) | (fcr31 & mask);
+   ptrace_setfcr31(child, value);
 
/* FIR may not be written.  */
 
@@ -809,7 +819,7 @@ long arch_ptrace(struct task_struct *chi
break;
 #endif
case FPC_CSR:
-   child->thread.fpu.fcr31 = data & ~FPU_CSR_ALL_X;
+   ptrace_setfcr31(child, data);
break;
case DSP_BASE ... DSP_BASE + 5: {
dspreg_t *dregs;

[PATCH 4.4 22/99] MIPS: lib: Mark intrinsics notrace

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Harvey Hunt 

commit aedcfbe06558a9f53002e82d5be64c6c94687726 upstream.

On certain MIPS32 devices, the ftrace tracer "function_graph" uses
__lshrdi3() during the capturing of trace data. ftrace then attempts to
trace __lshrdi3() which leads to infinite recursion and a stack overflow.
Fix this by marking __lshrdi3() as notrace. Mark the other compiler
intrinsics as notrace in case the compiler decides to use them in the
ftrace path.

Signed-off-by: Harvey Hunt 
Cc: 
Cc: 
Patchwork: https://patchwork.linux-mips.org/patch/13354/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/lib/ashldi3.c |2 +-
 arch/mips/lib/ashrdi3.c |2 +-
 arch/mips/lib/bswapdi.c |2 +-
 arch/mips/lib/bswapsi.c |2 +-
 arch/mips/lib/cmpdi2.c  |2 +-
 arch/mips/lib/lshrdi3.c |2 +-
 arch/mips/lib/ucmpdi2.c |2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)

--- a/arch/mips/lib/ashldi3.c
+++ b/arch/mips/lib/ashldi3.c
@@ -2,7 +2,7 @@
 
 #include "libgcc.h"
 
-long long __ashldi3(long long u, word_type b)
+long long notrace __ashldi3(long long u, word_type b)
 {
DWunion uu, w;
word_type bm;
--- a/arch/mips/lib/ashrdi3.c
+++ b/arch/mips/lib/ashrdi3.c
@@ -2,7 +2,7 @@
 
 #include "libgcc.h"
 
-long long __ashrdi3(long long u, word_type b)
+long long notrace __ashrdi3(long long u, word_type b)
 {
DWunion uu, w;
word_type bm;
--- a/arch/mips/lib/bswapdi.c
+++ b/arch/mips/lib/bswapdi.c
@@ -1,6 +1,6 @@
 #include 
 
-unsigned long long __bswapdi2(unsigned long long u)
+unsigned long long notrace __bswapdi2(unsigned long long u)
 {
return (((u) & 0xff00ull) >> 56) |
   (((u) & 0x00ffull) >> 40) |
--- a/arch/mips/lib/bswapsi.c
+++ b/arch/mips/lib/bswapsi.c
@@ -1,6 +1,6 @@
 #include 
 
-unsigned int __bswapsi2(unsigned int u)
+unsigned int notrace __bswapsi2(unsigned int u)
 {
return (((u) & 0xff00) >> 24) |
   (((u) & 0x00ff) >>  8) |
--- a/arch/mips/lib/cmpdi2.c
+++ b/arch/mips/lib/cmpdi2.c
@@ -2,7 +2,7 @@
 
 #include "libgcc.h"
 
-word_type __cmpdi2(long long a, long long b)
+word_type notrace __cmpdi2(long long a, long long b)
 {
const DWunion au = {
.ll = a
--- a/arch/mips/lib/lshrdi3.c
+++ b/arch/mips/lib/lshrdi3.c
@@ -2,7 +2,7 @@
 
 #include "libgcc.h"
 
-long long __lshrdi3(long long u, word_type b)
+long long notrace __lshrdi3(long long u, word_type b)
 {
DWunion uu, w;
word_type bm;
--- a/arch/mips/lib/ucmpdi2.c
+++ b/arch/mips/lib/ucmpdi2.c
@@ -2,7 +2,7 @@
 
 #include "libgcc.h"
 
-word_type __ucmpdi2(unsigned long long a, unsigned long long b)
+word_type notrace __ucmpdi2(unsigned long long a, unsigned long long b)
 {
const DWunion au = {.ll = a};
const DWunion bu = {.ll = b};

[PATCH 4.4 21/99] MIPS: Build microMIPS VDSO for microMIPS kernels

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: James Hogan 

commit bb93078e655be1e24d68f28f2756676e62c037ce upstream.

MicroMIPS kernels may be expected to run on microMIPS only cores which
don't support the normal MIPS instruction set, so be sure to pass the
-mmicromips flag through to the VDSO cflags.

Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
Signed-off-by: James Hogan 
Cc: Paul Burton 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13349/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/vdso/Makefile |1 +
 1 file changed, 1 insertion(+)

--- a/arch/mips/vdso/Makefile
+++ b/arch/mips/vdso/Makefile
@@ -5,6 +5,7 @@ obj-vdso-y := elf.o gettimeofday.o sigre
 ccflags-vdso := \
$(filter -I%,$(KBUILD_CFLAGS)) \
$(filter -E%,$(KBUILD_CFLAGS)) \
+   $(filter -mmicromips,$(KBUILD_CFLAGS)) \
$(filter -march=%,$(KBUILD_CFLAGS))
 cflags-vdso := $(ccflags-vdso) \
$(filter -W%,$(filter-out -Wa$(comma)%,$(KBUILD_CFLAGS))) \

[PATCH 4.4 23/99] MIPS: VDSO: Build with `-fno-strict-aliasing

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Maciej W. Rozycki 

commit 94cc36b84acc29f543b48bc5ed786011b112a666 upstream.

Avoid an aliasing issue causing a build error in VDSO:

In file included from include/linux/srcu.h:34:0,
 from include/linux/notifier.h:15,
 from ./arch/mips/include/asm/uprobes.h:9,
 from include/linux/uprobes.h:61,
 from include/linux/mm_types.h:13,
 from ./arch/mips/include/asm/vdso.h:14,
 from arch/mips/vdso/vdso.h:27,
 from arch/mips/vdso/gettimeofday.c:11:
include/linux/workqueue.h: In function 'work_static':
include/linux/workqueue.h:186:2: error: dereferencing type-punned pointer will 
break strict-aliasing rules [-Werror=strict-aliasing]
  return *work_data_bits(work) & WORK_STRUCT_STATIC;
  ^
cc1: all warnings being treated as errors
make[2]: *** [arch/mips/vdso/gettimeofday.o] Error 1

with a CONFIG_DEBUG_OBJECTS_WORK configuration and GCC 5.2.0.  Include
`-fno-strict-aliasing' along with compiler options used, as required for
kernel code, fixing a problem present since the introduction of VDSO
with commit ebb5e78cc634 ("MIPS: Initial implementation of a VDSO").

Thanks to Tejun for diagnosing this properly!

Signed-off-by: Maciej W. Rozycki 
Reviewed-by: James Hogan 
Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
Cc: Tejun Heo 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13357/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/vdso/Makefile |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/arch/mips/vdso/Makefile
+++ b/arch/mips/vdso/Makefile
@@ -9,7 +9,8 @@ ccflags-vdso := \
$(filter -march=%,$(KBUILD_CFLAGS))
 cflags-vdso := $(ccflags-vdso) \
$(filter -W%,$(filter-out -Wa$(comma)%,$(KBUILD_CFLAGS))) \
-   -O2 -g -fPIC -fno-common -fno-builtin -G 0 -DDISABLE_BRANCH_PROFILING \
+   -O2 -g -fPIC -fno-strict-aliasing -fno-common -fno-builtin -G 0 \
+   -DDISABLE_BRANCH_PROFILING \
$(call cc-option, -fno-stack-protector)
 aflags-vdso := $(ccflags-vdso) \
$(filter -I%,$(KBUILD_CFLAGS)) \

[PATCH 4.4 29/99] ARM: dts: exynos: Add interrupt line to MAX8997 PMIC on exynos4210-trats

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Marek Szyprowski 

commit 330d12764e15f6e3e94ff34cda29db96d2589c24 upstream.

MAX8997 PMIC requires interrupt and fails probing without it.

Signed-off-by: Marek Szyprowski 
Fixes: d105f0b1215d ("ARM: dts: Add basic dts file for Samsung Trats board")
[k.kozlowski: Write commit message, add CC-stable]
Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm/boot/dts/exynos4210-trats.dts |2 ++
 1 file changed, 2 insertions(+)

--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -298,6 +298,8 @@
compatible = "maxim,max8997-pmic";
 
reg = <0x66>;
+   interrupt-parent = <>;
+   interrupts = <7 0>;
 
max8997,pmic-buck1-uses-gpio-dvs;
max8997,pmic-buck2-uses-gpio-dvs;