Re: [PATCH 3/3] spinlock_debug: panic on recursive lock spin_dump()

[Sergey Senozhatsky]

On (02/02/16 01:14), Sergey Senozhatsky wrote:
> how about splitting ->owner_cpu 4 bytes as:
> 
> |   |
>   1 byte spin bug recursion | 1 byte spin_dump recursion counter | 2 bytes 
> owner cpu
> |   |

after some thinking... no, this will not do the trick. one byte is not
enough for recursion counter -- we can have 8K CPUs on the system and
8K-1 cpus can "suspect a lockup". so, a slightly different approach:

1) split ->owner_cpu 4 bytes in struct raw_spinlock
 unsigned short owner_cpu;
 unsigned short recursion;

I still can use only ->owner_cpu, but it's much easier when they are
apart. with a single 4 byte variable for recursion and cpu owner we
need to take extra care of higher 2 bytes every time we touch the
->owner_cpu

CPU1CPU2
spin_dump
 ->owner_cpu[recursion_bits] += 1   spin_unlock
->owner_cpu = -1
^^^ need to store cpu_id in
lower 2 bytes, avoiding
overwrite of 2 higher bytes, 
etc.
 ->owner_cpu[recursion_bits] -= 1

which is fragile and ugly.


2) ->recursion has most significant bit for spin_bug() bit, the
remaining bits are for recursion counter.

spin_bug() does
set SPIN_BUG bit (most significant bit)
spin_dump
clear SPIN_BUG bit

spin_dump() does
read SPIN_BUG bit
inc ->recursion
do_checks
printk...
dec ->recursion

and the do_checks is:

-- "if the SPIN_BUG bit is set AND recursion counter > NR_CPUS"
   then we have a spin_bug() recursion on at least one of the CPUs
   and we need to panic the system

printk
 spin_lock
  spin_bug
   spin_dump
printk
 spin_lock
  spin_bug
   spin_dump
...


-- "if the SPIN_BUG bit is clear AND recursion counter >= SHRT_MAX/2"
   then we have spin_dump() recursion (16K calls.. can be bigger) and
   we need to panic the system. if recursion counter < SHRT_MAX/2 - keep
   going. "suspected soft lockup" potentially can be resolved (the lock
   owner unlocks the lock), so we need to have a big enough limit before
   we declare panic().

printk
 spin_lock
  spin_dump
   printk
spin_lock
 spin_dump
  ...

I guess I'll I'll start a new thread with the next submission, to
refresh it.

RFC, any opinions are appreciated.
not yet tested code.

---
 include/linux/spinlock_types.h  |  4 +++-
 kernel/locking/spinlock_debug.c | 40 +---
 2 files changed, 40 insertions(+), 4 deletions(-)

diff --git a/include/linux/spinlock_types.h b/include/linux/spinlock_types.h
index 73548eb..c8f6b56 100644
--- a/include/linux/spinlock_types.h
+++ b/include/linux/spinlock_types.h
@@ -23,7 +23,9 @@ typedef struct raw_spinlock {
unsigned int break_lock;
 #endif
 #ifdef CONFIG_DEBUG_SPINLOCK
-   unsigned int magic, owner_cpu;
+   unsigned int magic;
+   unsigned short owner_cpu;
+   unsigned short recursion;
void *owner;
 #endif
 #ifdef CONFIG_DEBUG_LOCK_ALLOC
diff --git a/kernel/locking/spinlock_debug.c b/kernel/locking/spinlock_debug.c
index 0374a59..f838fe9 100644
--- a/kernel/locking/spinlock_debug.c
+++ b/kernel/locking/spinlock_debug.c
@@ -13,6 +13,8 @@
 #include 
 #include 
 
+#define SPIN_BUG_RECURSION (1 << 15)
+
 void __raw_spin_lock_init(raw_spinlock_t *lock, const char *name,
  struct lock_class_key *key)
 {
@@ -26,7 +28,8 @@ void __raw_spin_lock_init(raw_spinlock_t *lock, const char 
*name,
lock->raw_lock = (arch_spinlock_t)__ARCH_SPIN_LOCK_UNLOCKED;
lock->magic = SPINLOCK_MAGIC;
lock->owner = SPINLOCK_OWNER_INIT;
-   lock->owner_cpu = -1;
+   lock->owner_cpu = USHRT_MAX;
+   lock->recursion = 0;
 }
 
 EXPORT_SYMBOL(__raw_spin_lock_init);
@@ -49,9 +52,31 @@ void __rwlock_init(rwlock_t *lock, const char *name,
 
 EXPORT_SYMBOL(__rwlock_init);
 
+static void spin_recursion_panic(raw_spinlock_t *lock, const char *msg)
+{
+   panic("lock: %pS %s recursion on CPU#%d, %s/%d\n",
+   lock, msg, raw_smp_processor_id(),
+   current->comm, task_pid_nr(current));
+}
+
 static void spin_dump(raw_spinlock_t *lock, const char *msg)
 {
struct task_struct *owner = NULL;
+   unsigned short dump_counter;
+   bool spin_bug;
+
+   spin_bug = lock->recursion & SPIN_BUG_RECURSION;
+   dump_counter = lock->recursion & SHRT_MAX;
+   smp_rmb();
+
+   smp_wmb();
+   lock->recursion += 1;
+   dump_counter++;
+
+   if (spin_bug && dump_counter > NR_CPUS) /* num_online_cpus() */
+   spin_recursion_panic(lock, "spin_bug()");
+   if (dump_counter >= (SHRT_MAX >> 1))
+   

[PATCH] kernel/fork.c: use sizeof() instead of sizeof

[Wei Tang]

This patch fixes the checkpatch.pl warning to fork.c:

WARNING: sizeof sig->rlim should be sizeof(sig->rlim)

Signed-off-by: Wei Tang 
---
 kernel/fork.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/fork.c b/kernel/fork.c
index 2e391c7..30e04d2 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1143,7 +1143,7 @@ static int copy_signal(unsigned long clone_flags, struct 
task_struct *tsk)
sig->real_timer.function = it_real_fn;
 
task_lock(current->group_leader);
-   memcpy(sig->rlim, current->signal->rlim, sizeof sig->rlim);
+   memcpy(sig->rlim, current->signal->rlim, sizeof(sig->rlim));
task_unlock(current->group_leader);
 
posix_cpu_timers_init_group(sig);
-- 
1.9.1

Re: [PATCH] signal: use sizeof() instead of sizeof

[Richard Weinberger]

Hi!

Am 02.02.2016 um 08:35 schrieb Wei Tang:
> This patch fixes the checkpatch.pl warning to signal.c:
> 
> WARNING: sizeof info should be sizeof(info)

And why is this patch needed? What problem does it fix?
Complex expressions should be within parents
but in this case it is IMHO perfectly fine.

Thanks,
//richard

[PATCH 3/2] mm, vmstat: cancel pending work of the cpu_stat_off CPU

[Mike Galbraith]

Cancel pending work of the cpu_stat_off CPU.

Signed-off-by: Mike Galbraith 
---
 mm/vmstat.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -1486,25 +1486,25 @@ static void vmstat_shepherd(struct work_
 
get_online_cpus();
/* Check processors whose vmstat worker threads have been disabled */
-   for_each_cpu(cpu, cpu_stat_off)
+   for_each_cpu(cpu, cpu_stat_off) {
+   struct delayed_work *dw = _cpu(vmstat_work, cpu);
+
if (need_update(cpu)) {
if (cpumask_test_and_clear_cpu(cpu, cpu_stat_off))
-   queue_delayed_work_on(cpu, vmstat_wq,
-   _cpu(vmstat_work, cpu), 0);
+   queue_delayed_work_on(cpu, vmstat_wq, dw, 0);
} else {
/*
 * Cancel the work if quiet_vmstat has put this
 * cpu on cpu_stat_off because the work item might
 * be still scheduled
 */
-   cancel_delayed_work(this_cpu_ptr(_work));
+   cancel_delayed_work(dw);
}
-
+   }
put_online_cpus();
 
schedule_delayed_work(,
round_jiffies_relative(sysctl_stat_interval));
-
 }
 
 static void __init start_shepherd_timer(void)

[PATCH v2] mac80211: fix memory leak

[Sudip Mukherjee]

From: Sudip Mukherjee 

On error we jumped to the error label and returned the error code but we
missed releasing sinfo.

Fixes: 5fe74014172d ("mac80211: avoid excessive stack usage in sta_info")
Reviewed-by: Julian Calaby 
Signed-off-by: Sudip Mukherjee 
---

v2: added Fixes tag, Reviewed-by and From:.

 net/mac80211/sta_info.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 6c198e6..36e75c4 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -561,6 +561,7 @@ static int sta_info_insert_finish(struct sta_info *sta) 
__acquires(RCU)
__cleanup_single_sta(sta);
  out_err:
mutex_unlock(>sta_mtx);
+   kfree(sinfo);
rcu_read_lock();
return err;
 }
-- 
1.9.1

Re: [PATCH] dts/ls1021a: add the DTS for QSPI support

[Shawn Guo]

On Thu, Jan 28, 2016 at 04:33:26PM +0800, Yuan Yao wrote:
> From: Yuan Yao 
> 
> Signed-off-by: Yuan Yao 
> ---
> Add in v1:
> Can merge, but the function depend on the patch:
> https://patchwork.kernel.org/patch/8118251/

Please send me dts patch only after the driver part gets applied.

> 
> mtd: spi-nor: fsl-quadspi: add support for ls1021a
> 
> LS1021a also support Freescale Quad SPI controller.
> Add fsl-quadspi support for ls1021a chip and make SPI_FSL_QUADSPI
> selectable for LS1021A SOC hardwares.
> 
> ---
>  arch/arm/boot/dts/ls1021a.dtsi | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> index 9430a99..c764fa5 100644
> --- a/arch/arm/boot/dts/ls1021a.dtsi
> +++ b/arch/arm/boot/dts/ls1021a.dtsi
> @@ -252,6 +252,21 @@
>   status = "disabled";
>   };
>  
> + qspi: quadspi@155 {
> + compatible = "fsl,ls1021a-qspi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x0 0x155 0x0 0x1>,
> + <0x0 0x4000 0x0 0x400>;
> + reg-names = "QuadSPI", "QuadSPI-memory";
> + interrupts = ;
> + clock-names = "qspi_en", "qspi";
> + clocks = <_clk 1>, <_clk 1>;
> + big-endian;
> + amba-base = <0x4000>;

What is this property?  I cannot find it in any bindings doc.  Is it
added by your patches on driver code?

Shawn

> + status = "disabled";
> + };
> +
>   i2c0: i2c@218 {
>   compatible = "fsl,vf610-i2c";
>   #address-cells = <1>;
> -- 
> 2.1.0.27.g96db324
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

Re: [PATCH v6 20/22] usb: dwc2: host: Properly set even/odd frame

[Kever Yang]

Doug,

On 01/29/2016 10:20 AM, Douglas Anderson wrote:

When setting up ISO and INT transfers dwc2 needs to specify whether the
transfer is for an even or an odd frame (or microframe if the controller
is running in high speed mode).

The controller appears to use this as a simple way to figure out if a
transfer should happen right away (in the current microframe) or should
happen at the start of the next microframe.  Said another way:

- If you set "odd" and the current frame number is odd it appears that
   the controller will try to transfer right away.  Same thing if you set
   "even" and the current frame number is even.
- If the oddness you set and the oddness of the frame number are
   _different_, the transfer will be delayed until the frame number
   changes.

As I understand it, the above technique allows you to plan ahead of time
where possible by always working on the next frame.  ...but it still
allows you to properly respond immediately to things that happened in
the previous frame.

The old dwc2_hc_set_even_odd_frame() didn't really handle this concept.
It always looked at the frame number and setup the transfer to happen in
the next frame.  In some cases that meant that certain transactions
would be transferred in the wrong frame.

We'll try our best to set the even / odd to do the transfer in the
scheduled frame.  If that fails then we'll do an ugly "schedule ASAP".
We'll also modify the scheduler code to handle this and not try to
schedule a second transfer for the same frame.

Note that this change relies on the work to redo the microframe
scheduler.  It can work atop ("usb: dwc2: host: Manage frame nums better
in scheduler") but it works even better after ("usb: dwc2: host: Totally
redo the microframe scheduler").

With this change my stressful USB test (USB webcam + USB audio +
keyboards) has less audio crackling than before.

Seems this really help for your case?

Do you check if the transfer can happen right in the current frame? I 
know it's

quite difficult to check it, but this changes what I know for the dwc core
schedule the transaction.

In dwc_otgbook, Interrupt OUT Transactions(also similar for Int IN, Iso 
IN/OUT)

in DMA Mode, the normal Interrupt OUT operation says:
The DWC_otg host attempts to send out the OUT token in the beginning of next
odd frame/microframe.

So I'm confuse about if the dwc core can do the transaction at the same 
frame

of host channel initialized or not.

Thanks,
- Kever


Signed-off-by: Douglas Anderson 
Tested-by: Heiko Stuebner 
Tested-by: Stefan Wahren 
---
Changes in v6:
- Add Heiko's Tested-by.
- Add Stefan's Tested-by.

Changes in v5: None
Changes in v4:
- Properly set even/odd frame new for v4.

Changes in v3: None
Changes in v2: None

  drivers/usb/dwc2/core.c  | 92 +++-
  drivers/usb/dwc2/hcd_queue.c | 11 +-
  2 files changed, 100 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index a5db20f12ee4..c143f26bd9d9 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -1703,9 +1703,97 @@ static void dwc2_hc_set_even_odd_frame(struct dwc2_hsotg 
*hsotg,
  {
if (chan->ep_type == USB_ENDPOINT_XFER_INT ||
chan->ep_type == USB_ENDPOINT_XFER_ISOC) {
-   /* 1 if _next_ frame is odd, 0 if it's even */
-   if (!(dwc2_hcd_get_frame_number(hsotg) & 0x1))
+   int host_speed;
+   int xfer_ns;
+   int xfer_us;
+   int bytes_in_fifo;
+   u16 fifo_space;
+   u16 frame_number;
+   u16 wire_frame;
+
+   /*
+* Try to figure out if we're an even or odd frame. If we set
+* even and the current frame number is even the the transfer
+* will happen immediately.  Similar if both are odd. If one is
+* even and the other is odd then the transfer will happen when
+* the frame number ticks.
+*
+* There's a bit of a balancing act to get this right.
+* Sometimes we may want to send data in the current frame (AK
+* right away).  We might want to do this if the frame number
+* _just_ ticked, but we might also want to do this in order
+* to continue a split transaction that happened late in a
+* microframe (so we didn't know to queue the next transfer
+* until the frame number had ticked).  The problem is that we
+* need a lot of knowledge to know if there's actually still
+* time to send things or if it would be better to wait until
+* the next frame.
+*
+* We can look at how much time is left in the current frame
+* and make a guess about whether we'll have time to transfer.
+* We'll do that.
+*/
+
+ 

[PATCH] signal: use sizeof() instead of sizeof

[Wei Tang]

This patch fixes the checkpatch.pl warning to signal.c:

WARNING: sizeof info should be sizeof(info)

Signed-off-by: Wei Tang 
---
 kernel/signal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/signal.c b/kernel/signal.c
index f3f1f7a..13b267a 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -1900,7 +1900,7 @@ static void ptrace_do_notify(int signr, int exit_code, 
int why)
 {
siginfo_t info;
 
-   memset(, 0, sizeof info);
+   memset(, 0, sizeof(info));
info.si_signo = signr;
info.si_code = exit_code;
info.si_pid = task_pid_vnr(current);
-- 
1.9.1

Re: [PATCH 1/5] all: s390: move wrapper infrastructure to generic headers

[Heiko Carstens]

On Mon, Feb 01, 2016 at 02:42:51PM +0300, Yury Norov wrote:
> Hi Heiko,
> 
> I tried this idea, and I don't like what happened.
>  - Wrappers around safe syscalls does exist. We can remove it by
>overcomplicating __SC_COMPAT_CAST, but I don't like it.
>  - We still need to declare numerous list of new compat syscalls.
>And it becomes even bigger, as we need to declare all compat
>syscall versions not declared in include/linux/compat.h already.
>(Currently - only for unsafe syscalls.)
>  - 'Weak' trick doesn't work for the whole kernel, so we'd figure out
>some new prefix for wrapped syscalls. Or declare all non-compat
>syscalls explicitly with SYSCALL_COMPAT_DEFINE. So the list of
>replacements grow. And for me, it's harder to explain why we are
>wrapping safe syscalls. Or we introduce another bunch of useless
>wrappers (with new prefix), and have to handle it in non-compat code.
>  - With all listed above, we move all wrapper logic to non-compat
>'include/linux/syscalls.h' header. Which is not a good idea, if it
>doesn't benefit us much in return.
> 
> > > No need to look up if a compat variant (or wrapper) exists or
> > > sys_ should be used instead. Also no possibility for security
> > > bugs that could creep in because SYSCALL_DEFINE has been used instead of
> > > SYSCALL_DEFINE_WRAP.
> 
> I thought again about it. With current version, it's very easy to
> define whether we have wrapper or not - just by macro we use. Once
> reviewed, this list is hardly to be changed frequently. If someone is
> introducing new syscall, it will attract much attention, so security
> risk is minimal.
> 
> Maybe I missed some elegant implementation, and if so  I'll be happy
> if someone'll point me out. But with what I see, I'd vote for what we
> have now. (Plus description in docs, plus renaming new macro.)

Well, I'd like to have some proof by the compiler or linker that nothing
went wrong. Which seems hard if only selected system call defines will be
converted to the new defines.

How can you tell that nothing has been forgotten?

Also, what happens if the prototype of a system call get's changed shortly
after it was merged. We might miss such changes and have bugs.

Therefore, and to get to a solution, I think we should stick with your
first idea, which only moves the compat_wrapper.c file.

Before doing that I think you should actually revert this patch: my commit
7681df456f97 ("s390/compat: remove superfluous compat wrappers") probably
wasn't a very bright idea :)

This again allows me to use only compat system calls in s390's system call
table (execpt for system calls without parameters, but that can be easily
fixed).

What I still don't like is that you need to add all the protoypes. Why are
the system call tables actually written in C and not in asm?

Re: [PATCH 14/14] ARM: dts: sun8i: Add A83T based Sinovoip Bpi-M3 Board

[Chen-Yu Tsai]

On Sun, Jan 31, 2016 at 9:21 AM, Vishnu Patekar
 wrote:
> This patch adds support for Sinovoip BPI-M3 A83T based board.
>
> It has 2G LPDDR3, UART, ethernet, USB, HDMI, USB Sata, MIPI DSI,
> mic, AP6212 Wifi, etc on it.
> It is paired with AXP813 PMIC which is almost same as AXP818.
>
> Signed-off-by: Vishnu Patekar 
> ---
>  arch/arm/boot/dts/Makefile   |  1 +
>  arch/arm/boot/dts/sun8i-a83t-sinovoip-bpi-m3.dts | 88 
> 
>  2 files changed, 89 insertions(+)
>  create mode 100644 arch/arm/boot/dts/sun8i-a83t-sinovoip-bpi-m3.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 58e461a..c0dd016 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -694,6 +694,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
> sun8i-a33-sinlinx-sina33.dtb \
> sun8i-a83t-allwinner-h8homlet-v2.dtb \
> sun8i-a83t-cubietruck-plus.dtb \
> +   sun8i-a83t-sinovoip-bpi-m3.dtb \
> sun8i-h3-orangepi-plus.dtb
>  dtb-$(CONFIG_MACH_SUN9I) += \
> sun9i-a80-optimus.dtb \
> diff --git a/arch/arm/boot/dts/sun8i-a83t-sinovoip-bpi-m3.dts 
> b/arch/arm/boot/dts/sun8i-a83t-sinovoip-bpi-m3.dts
> new file mode 100644
> index 000..fecc7dc
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun8i-a83t-sinovoip-bpi-m3.dts
> @@ -0,0 +1,88 @@
> +/*
> + * Copyright 2015 Vishnu Patekar

2016?

> + * Vishnu Patekar 
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file 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 file 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.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "sun8i-a83t.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +
> +/ {
> +   model = "Sinovoip BananaPi M3 v1.2";
> +   compatible = "sinovoip,bpi-m3", "allwinner,sun8i-a83t";
> +
> +   aliases {
> +   serial0 = 
> +   };
> +
> +   chosen {
> +   stdout-path = "serial0:115200n8";
> +   };
> +};
> +
> + {
> +   mmc0_cd_pin_bpi_m3: mmc0_cd_pin@0 {
> +   allwinner,pins = "PF6";
> +   allwinner,function = "gpio_in";
> +   allwinner,drive = ;
> +   allwinner,pull = ;
> +   };

Maybe we should just put this in the .dtsi and call it
"mmc0_cd_pin_reference_design"?

We have something similar for sun4i-a10.

> +};
> +
> + {
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_pins_a>, <_cd_pin_bpi_m3>;
> +   vmmc-supply = <_vcc3v0>;
> +   cd-gpios = < 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
> +   bus-width = <4>;
> +   cd-inverted;
> +   status = "okay";
> +};
> +
> + {
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_pins_b>;
> +   status = "okay";
> +};
> +
> +_rsb {

This goes before uart0.

> +   status = "okay";
> +};

What about eMMC?


Thanks!
ChenYu

[PATCH] thermal: devfreq_cooling: remove impossible condition

[Sudip Mukherjee]

state is an unsigned long and can never be less than 0.

Signed-off-by: Sudip Mukherjee 
---
 drivers/thermal/devfreq_cooling.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/devfreq_cooling.c 
b/drivers/thermal/devfreq_cooling.c
index 01f0015..81631b1 100644
--- a/drivers/thermal/devfreq_cooling.c
+++ b/drivers/thermal/devfreq_cooling.c
@@ -312,7 +312,7 @@ static int devfreq_cooling_state2power(struct 
thermal_cooling_device *cdev,
unsigned long freq;
u32 static_power;
 
-   if (state < 0 || state >= dfc->freq_table_size)
+   if (state >= dfc->freq_table_size)
return -EINVAL;
 
freq = dfc->freq_table[state];
-- 
1.9.1

Re: [PATCH 13/14] ARM: dts: sun8i: enable mmc for H8Homlet Board.

[Chen-Yu Tsai]

Hi,

On Sun, Jan 31, 2016 at 9:21 AM, Vishnu Patekar
 wrote:
> This enables mmc0.
>
> Signed-off-by: Vishnu Patekar 
> Tested-by: LABBE Corentin 
> ---
>  .../boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts| 20 
> 
>  1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts 
> b/arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts
> index 342e1d3..6c1f598 100644
> --- a/arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts
> +++ b/arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts
> @@ -43,6 +43,7 @@
>
>  /dts-v1/;
>  #include "sun8i-a83t.dtsi"
> +#include "sunxi-common-regulators.dtsi"
>
>  / {
> model = "Allwinner A83T H8Homlet Proto Dev Board v2.0";
> @@ -57,6 +58,25 @@
> };
>  };
>
> + {
> +   mmc0_cd_pin_h8homlet: mmc0_cd_pin@0 {
> +   allwinner,pins = "PF6";
> +   allwinner,function = "gpio_in";
> +   allwinner,drive = ;
> +   allwinner,pull = ;
> +   };
> +};
> +

Please keep them alphabetically sorted.

> + {
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_pins_a>, <_cd_pin_h8homlet>;
> +   vmmc-supply = <_vcc3v0>;

The board design says 3.3V, but stock firmware uses 3.0V. I guess both work.

> +   cd-gpios = < 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
> +   bus-width = <4>;
> +   cd-inverted;
> +   status = "okay";
> +};
> +

There's also eMMC onboard. Have you tried that?


Thanks!
ChenYu


>   {
> pinctrl-names = "default";
> pinctrl-0 = <_pins_b>;
> --
> 1.9.1
>

Re: [PATCH v2 2/4] power: reset: add reboot mode driver

[Andy Yan]

Hi Moritz:

On 2016年01月27日 18:53, Moritz Fischer wrote:

Hi Andy,

On Tue, Jan 12, 2016 at 12:31 PM, Andy Yan  wrote:

This driver parse the reboot commands like "reboot loader"
and "reboot recovery" to get a boot mode described in the
device tree , then call the write interfae to store the boot
mode in some persistent storage  like special register or ram,
which can be read by the bootloader after system reboot, then
the bootloader can take different action according to the mode
stored.

This is commonly used on Android based devices, which in order
to reboot the device into fastboot or recovery mode.

Signed-off-by: Andy Yan 

---

Changes in v2:
- move to dir drivers/power/reset/
- make syscon-reboot-mode a generic driver

Changes in v1:
- fix the embarrassed compile warning
- correct the maskrom magic number
- check for the normal reboot

  drivers/power/reset/Kconfig  |  16 +
  drivers/power/reset/Makefile |   2 +
  drivers/power/reset/reboot-mode.c| 100 +++
  drivers/power/reset/reboot-mode.h|   6 ++
  drivers/power/reset/syscon-reboot-mode.c |  62 +++
  5 files changed, 186 insertions(+)
  create mode 100644 drivers/power/reset/reboot-mode.c
  create mode 100644 drivers/power/reset/reboot-mode.h
  create mode 100644 drivers/power/reset/syscon-reboot-mode.c

diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 1131cf7..2e6d873 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -173,5 +173,21 @@ config POWER_RESET_ZX
 help
   Reboot support for ZTE SoCs.

+config REBOOT_MODE
+   tristate
+   depends on OF
+   help
+This driver will help to pass the system reboot mode
+to bootloader
+
+config SYSCON_REBOOT_MODE
+   bool "Generic SYSCON regmap reboot mode driver"
+   select REBOOT_MODE
+   help
+Say y here will enable reboot mode driver. This will
+get reboot mode arguments and store it in SYSCON mapped
+register, then the bootloader can read it to take different
+action according to the mode.
+
  endif

diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index 096fa67..a63865b 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -20,3 +20,5 @@ obj-$(CONFIG_POWER_RESET_SYSCON) += syscon-reboot.o
  obj-$(CONFIG_POWER_RESET_SYSCON_POWEROFF) += syscon-poweroff.o
  obj-$(CONFIG_POWER_RESET_RMOBILE) += rmobile-reset.o
  obj-$(CONFIG_POWER_RESET_ZX) += zx-reboot.o
+obj-$(CONFIG_REBOOT_MODE) += reboot-mode.o
+obj-$(CONFIG_SYSCON_REBOOT_MODE) += syscon-reboot-mode.o
diff --git a/drivers/power/reset/reboot-mode.c 
b/drivers/power/reset/reboot-mode.c
new file mode 100644
index 000..92b7b4d
--- /dev/null
+++ b/drivers/power/reset/reboot-mode.c
@@ -0,0 +1,100 @@
+/*
+ * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "reboot-mode.h"
+
+struct mode_info {
+   const char *mode;
+   int magic;
+   struct list_head list;
+};
+
+struct reboot_mode_driver {
+   struct list_head head;
+   int (*write)(int magic);
+   struct notifier_block reboot_notifier;
+};
+
+static int get_reboot_mode_magic(struct reboot_mode_driver *reboot,
+const char *cmd)
+{
+   const char *normal = "normal";
+   int magic = 0;
+   struct mode_info *info;
+
+   if (!cmd)
+   cmd = normal;
+
+   list_for_each_entry(info, >head, list) {
+   if (!strcmp(info->mode, cmd)) {
+   magic = info->magic;
+   break;
+   }
+   }
+
+   return magic;
+}
+
+static int reboot_mode_notify(struct notifier_block *this,
+ unsigned long mode, void *cmd)
+{
+   struct reboot_mode_driver *reboot;
+   int magic;
+
+   reboot = container_of(this, struct reboot_mode_driver, reboot_notifier);
+   magic = get_reboot_mode_magic(reboot, cmd);
+   if (magic)
+   reboot->write(magic);
+
+   return NOTIFY_DONE;
+}
+
+int reboot_mode_register(struct device *dev, int (*write)(int))
+{
+   struct reboot_mode_driver *reboot;
+   struct mode_info *info;
+   struct device_node *child;
+   int ret;
+
+   reboot = devm_kzalloc(dev, sizeof(*reboot), GFP_KERNEL);
+   if (!reboot)
+   return -ENOMEM;
+
+   reboot->write = write;
+   INIT_LIST_HEAD(>head);
+   for_each_child_of_node(dev->of_node, child) {
+   info = devm_kzalloc(dev, sizeof(*info), GFP_KERNEL);
+   if (!info)
+  

[PATCH] component: remove impossible condition

[Sudip Mukherjee]

We will be evaluating this condition only if match->num == match->alloc
and that means we have already dereferenced match which implies match
can not be NULL at this point.
Moreover we have done a NULL check on match just before this.

Signed-off-by: Sudip Mukherjee 
---
 drivers/base/component.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/component.c b/drivers/base/component.c
index 2738039..0ed3b72 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -267,7 +267,7 @@ void component_match_add_release(struct device *master,
}
 
if (match->num == match->alloc) {
-   size_t new_size = match ? match->alloc + 16 : 15;
+   size_t new_size = match->alloc + 16;
int ret;
 
ret = component_match_realloc(master, match, new_size);
-- 
1.9.1

Re: [PATCH v5 5/6] reset: mediatek: Add MT2701 reset controller dt-binding file

[James Liao]

Hi Philipp,

On Mon, 2016-02-01 at 09:56 +0100, Philipp Zabel wrote:
> Am Mittwoch, den 27.01.2016, 15:21 +0800 schrieb James Liao:
> > From: Shunli Wang 
> > 
> > Dt-binding file about reset controller is used to provide
> > kinds of definition, which is referenced by dts file and
> > IC-specified reset controller driver code.
> > 
> > Signed-off-by: Shunli Wang 
> > Signed-off-by: James Liao 
> > Tested-by: John Crispin 
> 
> In case you missed my Acked-by for patches 5 and 6, it still stands.

I'll add it in next version of patch, thanks.


Best regards,

James

[PATCH] lock/semaphore: Avoid a deadlock within __up()

[Byungchul Park]

Since I faced a infinite recursive printk() bug, I've tried to propose
patches the title of which is "lib/spinlock_debug.c: prevent a recursive
cycle in the debug code". But I noticed the root problem cannot be fixed
by that, through some discussion thanks to Sergey and Peter. So I focused
on preventing the DEADLOCK.

-8<-
>From 94a66990677735459a7790b637179d8600479639 Mon Sep 17 00:00:00 2001
From: Byungchul Park 
Date: Tue, 2 Feb 2016 15:35:48 +0900
Subject: [PATCH] lock/semaphore: Avoid a deadlock within __up()

When the semaphore __up() is called from within printk() with
console_sem.lock, a DEADLOCK can happen, since the wake_up_process() can
call printk() again, esp. if defined CONFIG_DEBUG_SPINLOCK. And the
wake_up_process() don't need to be within a critical section.

The scenario the bad thing can happen is,

printk
  console_trylock
  console_unlock
up_console_sem
  up
raw_spin_lock_irqsave(>lock, flags)
__up
  wake_up_process
try_to_wake_up
  raw_spin_lock_irqsave(>pi_lock)
__spin_lock_debug
  spin_dump
printk
  console_trylock
raw_spin_lock_irqsave(>lock, flags)

*** DEADLOCK ***

Signed-off-by: Byungchul Park 
---
 kernel/locking/semaphore.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/kernel/locking/semaphore.c b/kernel/locking/semaphore.c
index b8120ab..d3a28dc 100644
--- a/kernel/locking/semaphore.c
+++ b/kernel/locking/semaphore.c
@@ -259,5 +259,14 @@ static noinline void __sched __up(struct semaphore *sem)
struct semaphore_waiter, list);
list_del(>list);
waiter->up = true;
+
+   /*
+* Trying to acquire this sem->lock in wake_up_process() leads a
+* DEADLOCK unless we unlock it here. For example, it's possile
+* in the case that called from within printk() since
+* wake_up_process() might call printk().
+*/
+   raw_spin_unlock_irq(>lock);
wake_up_process(waiter->task);
+   raw_spin_lock_irq(>lock);
 }
-- 
1.9.1

[PATCH] ath10k: remove impossible code

[Sudip Mukherjee]

From: Sudip Mukherjee 

len has been initialized with a value of 0 and buf_len with 4096. There
is no way that this condition (len > buf_len) can be true now.

Signed-off-by: Sudip Mukherjee 
---
 drivers/net/wireless/ath/ath10k/debug.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
b/drivers/net/wireless/ath/ath10k/debug.c
index 2bdf540..8b187e0 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -2176,9 +2176,6 @@ static ssize_t ath10k_debug_fw_checksums_read(struct file 
*file,
 
mutex_lock(>conf_mutex);
 
-   if (len > buf_len)
-   len = buf_len;
-
len += scnprintf(buf + len, buf_len - len,
 "firmware-N.bin\t\t%08x\n",
 crc32_le(0, ar->firmware->data, ar->firmware->size));
-- 
1.9.1

Re: [PATCH 2/2] dax: fix bdev NULL pointer dereferences

[Dave Chinner]

On Mon, Feb 01, 2016 at 05:02:12PM -0700, Ross Zwisler wrote:
> Relying on the bh->b_bdev returned by get_block() is correct, yea?

IMO, yes.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

[PATCH] drivers: soc: samsung: Enable COMPILE_TEST

[Krzysztof Kozlowski]

Get some build coverage of Exynos SROM controller and PMU drivers. The
PMU driver depends on asm/cputype.h so its compilation is limited to ARM
architectures.

Signed-off-by: Krzysztof Kozlowski 

---
The SROM driver was compile-tested on x86, x86_64, ppc64, arm, arm64 and
mips. The PMU driver on arm and arm64.
---
 drivers/soc/samsung/Kconfig | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 895f16934b75..e5c11ac88a38 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -1,17 +1,17 @@
 #
 # SAMSUNG SoC drivers
 #
-menu "Samsung SOC driver support"
+menuconfig SOC_SAMSUNG
+   bool "Samsung SoC driver support" if COMPILE_TEST
 
-config SOC_SAMSUNG
-   bool
+if SOC_SAMSUNG
 
 config EXYNOS_SROM
-   bool
-   depends on ARM && ARCH_EXYNOS
+   bool "Exynos SROM controller driver" if COMPILE_TEST
+   depends on (ARM && ARCH_EXYNOS) || COMPILE_TEST
 
 config EXYNOS_PMU
-   bool
-   depends on ARM && ARCH_EXYNOS
+   bool "Exynos PMU controller driver" if COMPILE_TEST
+   depends on (ARM && ARCH_EXYNOS) || ((ARM || ARM64) && COMPILE_TEST)
 
-endmenu
+endif
-- 
1.9.1

Re: [PATCH v6 18/22] usb: dwc2: host: Schedule periodic right away if it's time

[Kever Yang]

Doug,

On 02/02/2016 08:36 AM, Doug Anderson wrote:

Kever,

On Sun, Jan 31, 2016 at 8:36 PM, Doug Anderson  wrote:

Kever,

On Sun, Jan 31, 2016 at 7:32 PM, Kever Yang  wrote:

Doug,


On 02/01/2016 06:09 AM, Doug Anderson wrote:

Kever,

On Sun, Jan 31, 2016 at 1:36 AM, Kever Yang 
wrote:

Doug,


On 01/29/2016 10:20 AM, Douglas Anderson wrote:

In dwc2_hcd_qh_deactivate() we will put some things on the
periodic_sched_ready list.  These things won't be taken off the ready
list until the next SOF, which might be a little late.  Let's put them
on right away.

Signed-off-by: Douglas Anderson 
Tested-by: Heiko Stuebner 
Tested-by: Stefan Wahren 
---
Changes in v6:
- Add Heiko's Tested-by.
- Add Stefan's Tested-by.

Changes in v5: None
Changes in v4:
- Schedule periodic right away if it's time new for v4.

Changes in v3: None
Changes in v2: None

drivers/usb/dwc2/hcd_queue.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc2/hcd_queue.c b/drivers/usb/dwc2/hcd_queue.c
index 9b3c435339ee..3abb34a5fc5b 100644
--- a/drivers/usb/dwc2/hcd_queue.c
+++ b/drivers/usb/dwc2/hcd_queue.c
@@ -1080,12 +1080,26 @@ void dwc2_hcd_qh_deactivate(struct dwc2_hsotg
*hsotg, struct dwc2_qh *qh,
   * Note: we purposely use the frame_number from the "hsotg"
structure
   * since we know SOF interrupt will handle future frames.
   */
-   if (dwc2_frame_num_le(qh->next_active_frame,
hsotg->frame_number))
+   if (dwc2_frame_num_le(qh->next_active_frame,
hsotg->frame_number))
{
+   enum dwc2_transaction_type tr_type;
+
+   /*
+* We're bypassing the SOF handler which is normally
what
puts
+* us on the ready list because we're in a hurry and
need
to
+* try to catch up.
+*/
+   dwc2_sch_vdbg(hsotg, "QH=%p IMM ready fn=%04x,
nxt=%04x\n",
+ qh, frame_number, qh->next_active_frame);
  list_move_tail(>qh_list_entry,
 >periodic_sched_ready);
-   else
+
+   tr_type = dwc2_hcd_select_transactions(hsotg);

Do we need to add select_transactions call here? If we get into this
function in interrupt
and once we put the qh in ready queue, the qh can be handled in this
frame
again by the
later function call of dwc_hcd_select_transactions, so what we need to to
here is put
it in ready list instead of inactive queue, and wait for the schedule.

I'm not sure I understand.  Can you restate?


I'll try to explain more in the meantime...

Both before and after my change, this function would place something
on the ready queue if the next_active_frame <= the frame number as of
last SOF interrupt (aka hsotg->frame_number).  Otherwise it goes on
the inactive queue.  Assuming that the previous change ("usb: dwc2:
host: Manage frame nums better in scheduler") worked properly then
next_active_frame shouldn't be less than (hsotg->frame_number - 1).
Remember that next_active_frame is always 1 before the wire frame, so
if "next_active_frame == hsotg->frame_number - 1" it means that we
need to get the transfer on the wire _right away_.  If
"next_active_frame == hsotg->frame_number" the transfer doesn't need
to go on the wire right away, but since dwc2 can be prepped one frame
in advance it doesn't hurt to give it to the hardware right away if
there's space.

As I understand it, if we stick something on the ready queue it won't
generally get looked at until the next SOF interrupt.  That means
we'll be too late if "next_active_frame == hsotg->frame_number - 1"
and we'll possibly be too late (depending on interrupt latency) if
"next_active_frame == hsotg->frame_number"


I understand this patch and agree with your point of schedule the
periodic right away instead of at least next frame.
My point is, there are only two call to dwc2_hcd_qh_deactivate(), from
dwc2_hcd_urb_dequeue() and dwc2_release_channel(), we don't need
to do the schedule for dequeue, and there is one
dwc2_hcd_select_transactions() call at the end of dwc2_release_channel(),
maybe we don't need another dwc2_hcd_select_transactions() here.

I think the duration from this point to the function call of
dwc2_hcd_select_transactions()
in dwc2_release_channel() will be the main factor for us to decide if
we need to add a function call of  dwc2_hcd_select_transactions() here.

Oh, now I get what you're saying!

A) You've got dwc2_release_channel() -> dwc2_deactivate_qh() ->
dwc2_hcd_qh_deactivate()
...and always in that case we'll do a select / queue, so we don't need it there.

B) You've got dwc2_hcd_urb_dequeue() -> dwc2_hcd_qh_deactivate()

...but why don't we need it for dwc2_hcd_urb_dequeue()?  Yes, you're
not continuing a split so timing isn't quite as urgent, but you still
might have an INT or ISOC packet that's scheduled with an interval of
1.  We still might want to schedule right away if there are remaining
QTDs, right?

I 

Re: [PATCH 0/4] ARM: dts: imx53: update Ka-Ro electronics TX53 module support

[Shawn Guo]

On Wed, Jan 20, 2016 at 02:09:18PM +0100, Lothar Waßmann wrote:
> ARM: dts: imx53: fix LVDS data-mapping and data-width
> ARM: dts: imx53: add display timing for NL12880BC20
> ARM: dts: imx53-tx53: set correct mclk frequency

Applied these 3, thanks.

Re: [PATCH v4 1/4] soc: mediatek: Refine scpsys to support multiple platform

[James Liao]

Hi Matthias,

On Sun, 2016-01-31 at 12:51 +0100, Matthias Brugger wrote:
> 
> On 20/01/16 07:08, James Liao wrote:
> > Refine scpsys driver common code to support multiple SoC / platform.
> >
> > Signed-off-by: James Liao 
> > ---
> >   drivers/soc/mediatek/mtk-scpsys.c | 418 
> > --
> >   drivers/soc/mediatek/mtk-scpsys.h |  55 +
> >   2 files changed, 270 insertions(+), 203 deletions(-)
> >   create mode 100644 drivers/soc/mediatek/mtk-scpsys.h
> 
> In general this approach looks fine to me, comments below.
> 
> >
> > diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
> > b/drivers/soc/mediatek/mtk-scpsys.c
> > index 0221387..339adfc 100644
> > --- a/drivers/soc/mediatek/mtk-scpsys.c
> > +++ b/drivers/soc/mediatek/mtk-scpsys.c
> > @@ -11,29 +11,17 @@
> >* GNU General Public License for more details.
> >*/
> >   #include 
> > -#include 
> > +#include 
> >   #include 
> > -#include 
> >   #include 
> 
> When at it, do we need this include?

syscon_regmap_lookup_by_phandle() is declared in this head file.

> > -#include 
> >   #include 
> >   #include 
> >   #include 
> > -#include 
> > -#include 
> >   #include 
> > -#include 
> > +#include 
> > +
> > +#include "mtk-scpsys.h"
> >
> > -#define SPM_VDE_PWR_CON0x0210
> > -#define SPM_MFG_PWR_CON0x0214
> > -#define SPM_VEN_PWR_CON0x0230
> > -#define SPM_ISP_PWR_CON0x0238
> > -#define SPM_DIS_PWR_CON0x023c
> > -#define SPM_VEN2_PWR_CON   0x0298
> > -#define SPM_AUDIO_PWR_CON  0x029c
> > -#define SPM_MFG_2D_PWR_CON 0x02c0
> > -#define SPM_MFG_ASYNC_PWR_CON  0x02c4
> > -#define SPM_USB_PWR_CON0x02cc
> 
> I would prefer to keep this defines and declare SoC specific ones where 
> necessary. It makes the code more readable.

Some register address may be reused by other modules among SoCs, so it's
not easy to maintain the defines when we implement multiple SoC drivers
in the same file. For example, offset 0x0298 is VEN2_PWR_CON on MT8173,
but it is MJC_PWR_CON on other chips.

Furthermore, these register offsets are only used in scp_domain_data[],
and each element has its own power domain name. So I think it's enough
to know which power domain are using these registers and status bits.

> >   #define SPM_PWR_STATUS0x060c
> >   #define SPM_PWR_STATUS_2ND0x0610
> >
> > @@ -43,154 +31,6 @@
> >   #define PWR_ON_2ND_BITBIT(3)
> >   #define PWR_CLK_DIS_BIT   BIT(4)
> >
> > -#define PWR_STATUS_DISPBIT(3)
> > -#define PWR_STATUS_MFG BIT(4)
> > -#define PWR_STATUS_ISP BIT(5)
> > -#define PWR_STATUS_VDECBIT(7)
> > -#define PWR_STATUS_VENC_LT BIT(20)
> > -#define PWR_STATUS_VENCBIT(21)
> > -#define PWR_STATUS_MFG_2D  BIT(22)
> > -#define PWR_STATUS_MFG_ASYNC   BIT(23)
> > -#define PWR_STATUS_AUDIO   BIT(24)
> > -#define PWR_STATUS_USB BIT(25)
> > -
> 
> Same here.
> 
> > -enum clk_id {
> > -   MT8173_CLK_NONE,
> > -   MT8173_CLK_MM,
> > -   MT8173_CLK_MFG,
> > -   MT8173_CLK_VENC,
> > -   MT8173_CLK_VENC_LT,
> > -   MT8173_CLK_MAX,
> > -};
> > -
> > -#define MAX_CLKS   2
> > -
> > -struct scp_domain_data {
> > -   const char *name;
> > -   u32 sta_mask;
> > -   int ctl_offs;
> > -   u32 sram_pdn_bits;
> > -   u32 sram_pdn_ack_bits;
> > -   u32 bus_prot_mask;
> > -   enum clk_id clk_id[MAX_CLKS];
> > -   bool active_wakeup;
> > -};
> > -
> > -static const struct scp_domain_data scp_domain_data[] __initconst = {
> > -   [MT8173_POWER_DOMAIN_VDEC] = {
> > -   .name = "vdec",
> > -   .sta_mask = PWR_STATUS_VDEC,
> > -   .ctl_offs = SPM_VDE_PWR_CON,
> > -   .sram_pdn_bits = GENMASK(11, 8),
> > -   .sram_pdn_ack_bits = GENMASK(12, 12),
> > -   .clk_id = {MT8173_CLK_MM},
> > -   },
> > -   [MT8173_POWER_DOMAIN_VENC] = {
> > -   .name = "venc",
> > -   .sta_mask = PWR_STATUS_VENC,
> > -   .ctl_offs = SPM_VEN_PWR_CON,
> > -   .sram_pdn_bits = GENMASK(11, 8),
> > -   .sram_pdn_ack_bits = GENMASK(15, 12),
> > -   .clk_id = {MT8173_CLK_MM, MT8173_CLK_VENC},
> > -   },
> > -   [MT8173_POWER_DOMAIN_ISP] = {
> > -   .name = "isp",
> > -   .sta_mask = PWR_STATUS_ISP,
> > -   .ctl_offs = SPM_ISP_PWR_CON,
> > -   .sram_pdn_bits = GENMASK(11, 8),
> > -   .sram_pdn_ack_bits = GENMASK(13, 12),
> > -   .clk_id = {MT8173_CLK_MM},
> > -   },
> > -   [MT8173_POWER_DOMAIN_MM] = {
> > -   .name = "mm",
> > -   .sta_mask = PWR_STATUS_DISP,
> > -   .ctl_offs = SPM_DIS_PWR_CON,
> > -   .sram_pdn_bits = GENMASK(11, 8),
> > -   .sram_pdn_ack_bits = GENMASK(12, 12),
> > -   .clk_id = {MT8173_CLK_MM},

Re: [PATCH wq/for-4.5-fixes] workqueue: skip flush dependency checks for legacy workqueues

[Archit Taneja]

On 01/29/2016 04:29 PM, Tejun Heo wrote:

fca839c00a12 ("workqueue: warn if memory reclaim tries to flush
!WQ_MEM_RECLAIM workqueue") implemented flush dependency warning which
triggers if a PF_MEMALLOC task or WQ_MEM_RECLAIM workqueue tries to
flush a !WQ_MEM_RECLAIM workquee.

This assumes that workqueues marked with WQ_MEM_RECLAIM sit in memory
reclaim path and making it depend on something which may need more
memory to make forward progress can lead to deadlocks.  Unfortunately,
workqueues created with the legacy create*_workqueue() interface
always have WQ_MEM_RECLAIM regardless of whether they are depended
upon memory reclaim or not.  These spurious WQ_MEM_RECLAIM markings
cause spurious triggering of the flush dependency checks.

   WARNING: CPU: 0 PID: 6 at kernel/workqueue.c:2361 
check_flush_dependency+0x138/0x144()
   workqueue: WQ_MEM_RECLAIM deferwq:deferred_probe_work_func is flushing 
!WQ_MEM_RECLAIM events:lru_add_drain_per_cpu
   ...
   Workqueue: deferwq deferred_probe_work_func
   [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
   [] (show_stack) from [] (dump_stack+0x94/0xd4)
   [] (dump_stack) from [] (warn_slowpath_common+0x80/0xb0)
   [] (warn_slowpath_common) from [] 
(warn_slowpath_fmt+0x30/0x40)
   [] (warn_slowpath_fmt) from [] 
(check_flush_dependency+0x138/0x144)
   [] (check_flush_dependency) from [] 
(flush_work+0x50/0x15c)
   [] (flush_work) from [] (lru_add_drain_all+0x130/0x180)
   [] (lru_add_drain_all) from [] (migrate_prep+0x8/0x10)
   [] (migrate_prep) from [] (alloc_contig_range+0xd8/0x338)
   [] (alloc_contig_range) from [] (cma_alloc+0xe0/0x1ac)
   [] (cma_alloc) from [] 
(__alloc_from_contiguous+0x38/0xd8)
   [] (__alloc_from_contiguous) from [] 
(__dma_alloc+0x240/0x278)
   [] (__dma_alloc) from [] (arm_dma_alloc+0x54/0x5c)
   [] (arm_dma_alloc) from [] 
(dmam_alloc_coherent+0xc0/0xec)
   [] (dmam_alloc_coherent) from [] 
(ahci_port_start+0x150/0x1dc)
   [] (ahci_port_start) from [] 
(ata_host_start.part.3+0xc8/0x1c8)
   [] (ata_host_start.part.3) from [] 
(ata_host_activate+0x50/0x148)
   [] (ata_host_activate) from [] 
(ahci_host_activate+0x44/0x114)
   [] (ahci_host_activate) from [] 
(ahci_platform_init_host+0x1d8/0x3c8)
   [] (ahci_platform_init_host) from [] 
(tegra_ahci_probe+0x448/0x4e8)
   [] (tegra_ahci_probe) from [] 
(platform_drv_probe+0x50/0xac)
   [] (platform_drv_probe) from [] 
(driver_probe_device+0x214/0x2c0)
   [] (driver_probe_device) from [] 
(bus_for_each_drv+0x60/0x94)
   [] (bus_for_each_drv) from [] 
(__device_attach+0xb0/0x114)
   [] (__device_attach) from [] (bus_probe_device+0x84/0x8c)
   [] (bus_probe_device) from [] 
(deferred_probe_work_func+0x68/0x98)
   [] (deferred_probe_work_func) from [] 
(process_one_work+0x120/0x3f8)
   [] (process_one_work) from [] (worker_thread+0x38/0x55c)
   [] (worker_thread) from [] (kthread+0xdc/0xf4)
   [] (kthread) from [] (ret_from_fork+0x14/0x3c)

Fix it by marking workqueues created via create*_workqueue() with
__WQ_LEGACY and disabling flush dependency checks on them.

Signed-off-by: Tejun Heo 
Reported-by: Thierry Reding 
Link: http://lkml.kernel.org/g/20160126173843.ga11...@ulmo.nvidia.com
---
Hello, Thierry.

Can youp please verify the fix?


This fixes a similar backtrace observed when the drm/msm driver
tries to allocate a vram buffer via cma.

Thanks,
Archit



Thanks.

  include/linux/workqueue.h |9 +
  kernel/workqueue.c|3 ++-
  2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index 0e32bc7..ca73c50 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -311,6 +311,7 @@ enum {

__WQ_DRAINING   = 1 << 16, /* internal: workqueue is draining */
__WQ_ORDERED= 1 << 17, /* internal: workqueue is ordered */
+   __WQ_LEGACY = 1 << 18, /* internal: create*_workqueue() */

WQ_MAX_ACTIVE   = 512,/* I like 512, better ideas? */
WQ_MAX_UNBOUND_PER_CPU  = 4,  /* 4 * #cpus for unbound wq */
@@ -411,12 +412,12 @@ __alloc_workqueue_key(const char *fmt, unsigned int 
flags, int max_active,
alloc_workqueue(fmt, WQ_UNBOUND | __WQ_ORDERED | (flags), 1, ##args)

  #define create_workqueue(name)
\
-   alloc_workqueue("%s", WQ_MEM_RECLAIM, 1, (name))
+   alloc_workqueue("%s", __WQ_LEGACY | WQ_MEM_RECLAIM, 1, (name))
  #define create_freezable_workqueue(name)  \
-   alloc_workqueue("%s", WQ_FREEZABLE | WQ_UNBOUND | WQ_MEM_RECLAIM, \
-   1, (name))
+   alloc_workqueue("%s", __WQ_LEGACY | WQ_FREEZABLE | WQ_UNBOUND |   \
+   WQ_MEM_RECLAIM, 1, (name))
  #define create_singlethread_workqueue(name)   \
-   alloc_ordered_workqueue("%s", WQ_MEM_RECLAIM, name)
+   alloc_ordered_workqueue("%s", __WQ_LEGACY | WQ_MEM_RECLAIM, name)

  extern void 

Re: [PATCH 1/4] ARM: dts: imx53: add ethernet PHY supply regulator

[Shawn Guo]

On Wed, Jan 20, 2016 at 02:09:19PM +0100, Lothar Waßmann wrote:
> Signed-off-by: Lothar Waßmann 
> ---
>  arch/arm/boot/dts/imx53-tx53.dtsi | 40 
> ++-
>  1 file changed, 31 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx53-tx53.dtsi 
> b/arch/arm/boot/dts/imx53-tx53.dtsi
> index d3e50b2..8f08389 100644
> --- a/arch/arm/boot/dts/imx53-tx53.dtsi
> +++ b/arch/arm/boot/dts/imx53-tx53.dtsi
> @@ -87,9 +87,20 @@
>   regulator-max-microvolt = <330>;
>   };
>  
> - reg_can_xcvr: regulator@2 {
> + reg_3v3_etn: regulator@2 {

Why cannot this be added as regulator@5 to avoid changing every node?

>   compatible = "regulator-fixed";
>   reg = <2>;
> + regulator-name = "ETN 3V3";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_etn_phy>;
> + gpio = < 20 GPIO_ACTIVE_HIGH>;
> + };
> +
> + reg_can_xcvr: regulator@3 {
> + compatible = "regulator-fixed";
> + reg = <3>;
>   regulator-name = "CAN XCVR";
>   regulator-min-microvolt = <330>;
>   regulator-max-microvolt = <330>;
> @@ -98,9 +109,9 @@
>   gpio = < 21 GPIO_ACTIVE_HIGH>;
>   };
>  
> - reg_usbh1_vbus: regulator@3 {
> + reg_usbh1_vbus: regulator@4 {
>   compatible = "regulator-fixed";
> - reg = <3>;
> + reg = <4>;
>   regulator-name = "usbh1_vbus";
>   regulator-min-microvolt = <500>;
>   regulator-max-microvolt = <500>;
> @@ -110,9 +121,9 @@
>   enable-active-high;
>   };
>  
> - reg_usbotg_vbus: regulator@4 {
> + reg_usbotg_vbus: regulator@5 {
>   compatible = "regulator-fixed";
> - reg = <4>;
> + reg = <5>;
>   regulator-name = "usbotg_vbus";
>   regulator-min-microvolt = <500>;
>   regulator-max-microvolt = <500>;
> @@ -204,13 +215,20 @@
>   phy-mode = "rmii";
>   phy-reset-gpios = < 6 GPIO_ACTIVE_HIGH>;
>   phy-handle = <>;
> + phy-supply = <_3v3_etn>;
>   mac-address = []; /* placeholder; will be overwritten by 
> bootloader */
>   status = "okay";
>  
> - phy0: ethernet-phy@0 {
> - interrupt-parent = <>;
> - interrupts = <4>;
> - device_type = "ethernet-phy";
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + phy0: ethernet-phy@0 {
> + compatible = "ethernet-phy-id0007.c0f1", 
> "ethernet-phy-ieee802.3-c22";
> + reg = <0>;
> + interrupt-parent = <>;
> + interrupts = <4>;
> + };

This should be a separate change.

Shawn

>   };
>  };
>  
> @@ -309,6 +327,10 @@
>   fsl,pins = ; /* 
> Flexcan XCVR enable */
>   };
>  
> + pinctrl_etn_phy: etn-phygrp {
> + fsl,pins = ; /* ETN 
> PHY Power enable */
> + };
> +
>   pinctrl_ds1339: ds1339grp {
>   fsl,pins = ;
>   };
> -- 
> 2.1.4
> 
> 

Re: [lkp] [kallsyms] bf2d2b07db: kasan: GPF could be caused by NULL-ptr deref or user memory accessgeneral protection fault: 0000 [#1] general protection fault: 0000 [#1] PREEMPT PREEMPT KASANKASAN

[Ard Biesheuvel]

On 2 February 2016 at 04:48, Guenter Roeck  wrote:
> On 02/01/2016 04:20 PM, Andrew Morton wrote:
>>
>> On Thu, 28 Jan 2016 09:12:15 +0800 kernel test robot
>>  wrote:
>>
>>> FYI, we noticed the below changes on
>>>
>>> https://git.linaro.org/people/ard.biesheuvel/linux-arm arm64-kaslr-v4a
>>> commit bf2d2b07db19001ae0bd55826025b0ba47fae0c2 ("kallsyms: add support
>>> for relative offsets in kallsyms address table")
>>>
>>>
>>>
>>> +---+++
>>> |   | 2c4d21df0f
>>> | bf2d2b07db |
>>>
>>> +---+++
>>> | boot_successes| 10
>>> | 0  |
>>> | boot_failures | 6
>>> | 36 |
>>> | Kernel_panic-not_syncing:Attempted_to_kill_init!exitcode= | 2
>>> ||
>>> | IP-Config:Auto-configuration_of_network_failed| 4
>>> ||
>>> | general_protection_fault:#[##]PREEMPT_PREEMPT_KASANKASAN  | 0
>>> | 36 |
>>> | general_protection_fault:#[##]| 0
>>> | 36 |
>>> | BUG:kernel_boot_hang  | 0
>>> | 36 |
>>>
>>> +---+++
>>>
>>>
>>>
>>> [ 0.281636] kasan: CONFIG_KASAN_INLINE enabled
>>>
>>> [ 0.282416] kasan: GPF could be caused by NULL-ptr deref or user memory
>>> access
>>> [ 0.282416] kasan: GPF could be caused by NULL-ptr deref or user memory
>>> accessgeneral protection fault:  [#1] general protection fault: 
>>> [#1] PREEMPT PREEMPT KASANKASAN
>>>
>>> [ 0.284561] Modules linked in:
>>> [ 0.284561] Modules linked in:
>>>
>>> [ 0.285136] CPU: 0 PID: 1 Comm: swapper Not tainted
>>> 4.5.0-rc1-00036-gbf2d2b0 #1
>>> [ 0.285136] CPU: 0 PID: 1 Comm: swapper Not tainted
>>> 4.5.0-rc1-00036-gbf2d2b0 #1
>>> [ 0.286438] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>>> Debian-1.8.2-1 04/01/2014
>>> [ 0.286438] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>>> Debian-1.8.2-1 04/01/2014
>>> [ 0.288000] task: 88000fcb ti: 88000fcb8000 task.ti:
>>> 88000fcb8000
>>> [ 0.288000] task: 88000fcb ti: 88000fcb8000 task.ti:
>>> 88000fcb8000
>>> [ 0.289287] RIP: 0010:[]
>>
>>
>> I'm not sufficiently familiar with KASAN to be able to interpret this.
>> Perhaps Andrey can shed some light?
>>
>> The lack of symbol decoding is a problem.
>>
>> CONFIG_KALLSYMS=y
>> CONFIG_KALLSYMS_ALL=y
>> CONFIG_KALLSYMS_BASE_RELATIVE=y
>>
>> It should be there.  Perhaps it is not because this error is itself
>> (possibly) related to kallsyms changes?
>>
>
> Probably. I had seen something similar (crash and no symbols) with an
> earlier version of the patch,
> if the symbols were not created. There might be a message in the log,
> indicating that kallsyms
> failed to generate the symbols.
>

Please disregard. That is a working branch for my kaslr arm64 series,
in which I replaced my versions of the kallsyms patches with the
versions that have your T-b and S-o-b's
However, the branch does not have the x86 smp patch (it does have the
absolute/percpu patch since it was required for context):
http://ozlabs.org/~akpm/mmotm/broken-out/x86-kallsyms-disable-absolute-percpu-symbols-on-smp.patch

I have tried building this .config locally, and applying the above
patch gets things working again.

Thanks,
Ard.

Re: [RFC 3/3] CMDQ: Mediatek CMDQ driver

[Horng-Shyang Liao]

On Mon, 2016-02-01 at 18:22 +0800, Daniel Kurtz wrote:
> On Mon, Feb 1, 2016 at 2:20 PM, Horng-Shyang Liao  
> wrote:
> > On Mon, 2016-02-01 at 12:15 +0800, Daniel Kurtz wrote:
> >> On Mon, Feb 1, 2016 at 10:04 AM, Horng-Shyang Liao  
> >> wrote:
> >> >
> >> > On Fri, 2016-01-29 at 21:15 +0800, Daniel Kurtz wrote:
> >> > > On Fri, Jan 29, 2016 at 8:24 PM, Horng-Shyang Liao 
> >> > >  wrote:
> >> > > > On Fri, 2016-01-29 at 16:42 +0800, Daniel Kurtz wrote:
> >> > > >> On Fri, Jan 29, 2016 at 3:39 PM, Horng-Shyang Liao 
> >> > > >>  wrote:
> >> > > >> > Hi Dan,
> >> > > >> >
> >> > > >> > Many thanks for your comments and time.
> >> > > >> > I reply my plan inline.
> >> > > >> >
> >> > > >> >
> >> > > >> > On Thu, 2016-01-28 at 12:49 +0800, Daniel Kurtz wrote:
> >> > > >> >> Hi HS,
> >> > > >> >>
> >> > > >> >> Sorry for the delay.  It is hard to find time to review a >3700 
> >> > > >> >> line
> >> > > >> >> driver :-o in detail
> >> > > >> >>
> >> > > >> >> Some review comments inline, although I still do not completely
> >> > > >> >> understand how all that this driver does and how it works.
> >> > > >> >> I'll try to find time to go through this driver in detail again 
> >> > > >> >> next
> >> > > >> >> time you post it for review.
> >> > > >> >>
> >> > > >> >> On Tue, Jan 19, 2016 at 9:14 PM,   wrote:
> >> > > >> >> > From: HS Liao 
> >> > > >> >> >
> >> > > >> >> > This patch is first version of Mediatek Command Queue(CMDQ) 
> >> > > >> >> > driver. The
> >> > > >> >> > CMDQ is used to help read/write registers with critical time 
> >> > > >> >> > limitation,
> >> > > >> >> > such as updating display configuration during the vblank. It 
> >> > > >> >> > controls
> >> > > >> >> > Global Command Engine (GCE) hardware to achieve this 
> >> > > >> >> > requirement.
> >> > > >> >> > Currently, CMDQ only supports display related hardwares, but 
> >> > > >> >> > we expect
> >> > > >> >> > it can be extended to other hardwares for future requirements.
> >> > > >> >> >
> >> > > >> >> > Signed-off-by: HS Liao 
> >> > > >> >>
> >> > > >> >> [snip]
> >> > > >> >>
> >> > > >> >> > diff --git a/drivers/soc/mediatek/mtk-cmdq.c 
> >> > > >> >> > b/drivers/soc/mediatek/mtk-cmdq.c
> >> > > >> >> > new file mode 100644
> >> > > >> >> > index 000..7570f00
> >> > > >> >> > --- /dev/null
> >> > > >> >> > +++ b/drivers/soc/mediatek/mtk-cmdq.c
> >> > > >
> >> > > > [snip]
> >> > > >
> >> > > >> >> > +static const struct cmdq_subsys g_subsys[] = {
> >> > > >> >> > +   {0x1400, 1, "MMSYS"},
> >> > > >> >> > +   {0x1401, 2, "DISP"},
> >> > > >> >> > +   {0x1402, 3, "DISP"},
> >> > > >> >>
> >> > > >> >> This isn't going to scale.  These addresses could be different on
> >> > > >> >> different chips.
> >> > > >> >> Instead of a static table like this, we probably need specify to 
> >> > > >> >> the
> >> > > >> >> connection between gce and other devices via devicetree 
> >> > > >> >> phandles, and
> >> > > >> >> then use the phandles to lookup the corresponding device address
> >> > > >> >> range.
> >> > > >> >
> >> > > >> > I will define them in device tree.
> >> > > >> > E.g.
> >> > > >> > cmdq {
> >> > > >> >   reg_domain = 0x1400, 0x1401, 0x1402
> >> > > >> > }
> >> > > >>
> >> > > >> The devicetree should only model hardware relationships, not 
> >> > > >> software
> >> > > >> considerations.
> >> > > >>
> >> > > >> Is the hardware constraint here for using gce with various other
> >> > > >> hardware blocks?  I think we already model this by only providing a
> >> > > >> gce phandle in the device tree nodes for those devices that can use
> >> > > >> gce.
> >> > > >>
> >> > > >> Looking at the driver closer, as far as I can tell, the whole subsys
> >> > > >> concept is a purely software abstraction, and only used to debug the
> >> > > >> CMDQ_CODE_WRITE command.  In fact, AFAICT, everything would work 
> >> > > >> fine
> >> > > >> if we just completely removed the 'subsys' concept, and just passed
> >> > > >> through the raw address provided by the driver.
> >> > > >>
> >> > > >> So, I recommend just removing 'subsys' completely from the driver -
> >> > > >> from this array, and in the masks.
> >> > > >>
> >> > > >> Instead, if there is an error on the write command, just print the
> >> > > >> address that fails.  There are other ways to deduce the subsystem 
> >> > > >> from
> >> > > >> a physical address.
> >> > > >>
> >> > > >> Thanks,
> >> > > >>
> >> > > >> -Dan
> >> > > >
> >> > > > Hi Dan,
> >> > > >
> >> > > > Subsys is not just for debug.
> >> > > > Its main purpose is to transfer CPU address to GCE address.
> >> > > > Let me explain it by "write" op,
> >> > > > I list a code segment from cmdq_rec_append_command().
> >> > > >
> >> > > > case CMDQ_CODE_WRITE:
> >> > > > subsys = cmdq_subsys_from_phys_addr(cqctx, arg_a);
> >> > > > if (subsys < 0) {
> >> > > > dev_err(dev,
> >> > > > 

[PATCH] ocfs2: fix build warning

[Sudip Mukherjee]

We were getting build warning about:
/fs/ocfs2/file.c: In function ‘ocfs2_file_write_iter’:
fs/ocfs2/file.c:2198:1: warning: label ‘relock’ defined but not used

The previous commit has cleaned up the code for direct io and removed
the jump instruction to relock, but missed removing the label which is
unused now.

Fixes: 1a46f12e5071 ("ocfs2: code clean up for direct io")
Cc: Ryan Ding 
Signed-off-by: Sudip Mukherjee 
---
 fs/ocfs2/file.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c
index 41c506e..c18ab45 100644
--- a/fs/ocfs2/file.c
+++ b/fs/ocfs2/file.c
@@ -2195,7 +2195,6 @@ static ssize_t ocfs2_file_write_iter(struct kiocb *iocb,
 
inode_lock(inode);
 
-relock:
/*
 * Concurrent O_DIRECT writes are allowed with
 * mount_option "coherency=buffered".
-- 
1.9.1

Re: [PATCH v2] locktorture: Fix NULL pointer when torture_type is invalid

[Paul E. McKenney]

On Mon, Feb 01, 2016 at 11:28:07AM +0800, Kefeng Wang wrote:
> 
> 
> On 2016/2/1 11:02, Davidlohr Bueso wrote:
> > On Mon, 01 Feb 2016, Kefeng Wang wrote:
> > 
> >> Hi Davidlohr,
> >>
> [...]
> >>
> >> Yes, it works, but what you are doing is to revert commit 
> >> a36a99618b1adb2d6ca0b7e08e3a656a04e477fe
> > 
> > Oh, I see. I was definitely not aware of that one.
> > 
> > [...]
> > 
> >> And what Paul wanted is something that would print the full statistics
> >> at the end regardless of the periodic statistics.
> >>
> >> I prefer my version 2, here is some log with my patch v2, it is keep 
> >> consistent
> >> with rcutorture.
> >> ---
> >> -bash-4.3# insmod locktorture.ko torture_type=mutex
> >> [  190.845067] lock-torture: invalid torture type: "mutex"
> >> [  190.845748] lock-torture types:
> >> [  190.846099]  lock_busted spin_lock
> >> [  190.863211]  spin_lock_irq rw_lock
> >> [  190.863668]  rw_lock_irq mutex_lock
> >> [  190.864049]  rtmutex_lock rwsem_lock
> >> [  190.864390]  percpu_rwsem_lock[  190.864686]
> >> [  190.865662] Writes:  Total: 0  Max/Min: 0/0   Fail: 0
> >> [  190.866218] Reads :  Total: 0  Max/Min: 0/0   Fail: 0
> >> [  190.875071] mutex-torture:--- End of test: SUCCESS: nwriters_stress=0 
> >> nreaders_stress=0 stat_interval=60 verbose=1 shuffle_interval=3 stutter=5 
> >> shutdown_secs=0 onoff_interval=0 onoff_holdoff=0
> > 
> > How can the above be a successful run (SUCCESS string) if we didn't pass a
> > valid torture_type? iow, there is no test without it. Just think of passing
> > the wrong param in a userland application, 99.999% of the tools simply error
> > out complaining about the bogus input.
> > 
> > I think the right approach would be to decouple the statistics from the 
> > cleanup,
> > that way we can still do the required cleanups and avoid any stats.
> 
> Just like I mentioned before, keep consistent with rcutorture，I am happy to 
> any
> way to solve this issue,
> 
> To Paul， what's your advice?

Hmmm...   If nothing happened, then I agree that it makes sense not to
print any statistics.  But if some testing actually was carried out, then
we really need to print the statistics.

Thanx, Paul

> Thanks,
> Kefeng
> 
> Attached rcutorture log,
> --
> -bash-4.3# insmod rcutorture.ko torture_type=xxx
> [ 3195.103753] rcu-torture: invalid torture type: "xxx"
> [ 3195.104328] rcu-torture types:
> [ 3195.104610]  rcu rcu_bh
> [ 3195.104889]  rcu_busted srcu
> [ 3195.105188]  srcud sched
> [ 3195.105464]  tasks[ 3195.105680]
> [ 3196.121026] xxx-torture: rtc:   (null) ver: 0 tfle: 1 rta: 0 rtaf: 
> 0 rtf: 0 rtmbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 0 onoff: 0/0:0/0 
> -1,0:-1,0 0:0 (HZ=250) barrier: 0/0:0 cbflood: 0
> [ 3196.125066] xxx-torture: Reader Pipe:  0 0 0 0 0 0 0 0 0 0 0
> [ 3196.126176] xxx-torture: Reader Batch:  0 0 0 0 0 0 0 0 0 0 0
> [ 3196.128884] xxx-torture: Free-Block Circulation:  0 0 0 0 0 0 0 0 0 0 0
> [ 3196.129945] xxx-torture:--- End of test: SUCCESS: nreaders=0 
> nfakewriters=4 stat_interval=60 verbose=1 test_no_idle_hz=1 
> shuffle_interval=3 stutter=5 irqreader=1 fqs_duration=0 fqs_holdoff=0 
> fqs_stutter=3 test_boost=1/0 test_boost_interval=7 test_boost_duration=4 
> shutdown_secs=0 stall_cpu=0 stall_cpu_holdoff=10 n_barrier_cbs=0 
> onoff_interval=0 onoff_holdoff=0
> insmod: ERROR: could not insert module rcutorture.ko: Invalid parameters
> 
> 
> -bash-4.3# insmod rcutorture.ko torture_type=rcu
> [ 3205.456128] rcu-torture:--- Start of test: nreaders=1 nfakewriters=4 
> stat_interval=60 verbose=1 test_no_idle_hz=1 shuffle_interval=3 stutter=5 
> irqreader=1 fqs_duration=0 fqs_holdoff=0 fqs_stutter=3 test_boost=1/0 
> test_boost_interval=7 test_boost_duration=4 shutdown_secs=0 stall_cpu=0 
> stall_cpu_holdoff=10 n_barrier_cbs=0 onoff_interval=0 onoff_holdoff=0
> [ 3205.474983] rcu-torture: Creating rcu_torture_writer task
> [ 3205.478951] rcu-torture: Creating rcu_torture_fakewriter task
> [ 3205.479966] rcu-torture: rcu_torture_writer task started
> [ 3205.480410] rcu-torture: Grace periods expedited from boot/sysfs for rcu,
> [ 3205.480942] rcu-torture: Testing of dynamic grace-period expediting 
> diabled.
> [ 3205.482951] rcu-torture: Creating rcu_torture_fakewriter task
> [ 3205.483854] rcu-torture: rcu_torture_fakewriter task started
> [ 3205.491931] rcu-torture: Creating rcu_torture_fakewriter task
> [ 3205.492858] rcu-torture: rcu_torture_fakewriter task started
> [ 3205.493613] rcu-torture: Creating rcu_torture_fakewriter task
> [ 3205.495176] rcu-torture: rcu_torture_fakewriter task started
> [ 3205.499013] rcu-torture: Creating rcu_torture_reader task
> [ 3205.499919] rcu-torture: rcu_torture_fakewriter task started
> [ 3205.500578] rcu-torture: Creating rcu_torture_stats task
> [ 3205.501297] rcu-torture: rcu_torture_reader task started
> [ 3205.502903] 

Re: [PATCH 2/2] dax: fix bdev NULL pointer dereferences

[Dan Williams]

On Mon, Feb 1, 2016 at 10:06 PM, Jared Hulbert  wrote:
> On Mon, Feb 1, 2016 at 1:47 PM, Dave Chinner  wrote:
>> On Mon, Feb 01, 2016 at 03:51:47PM +0100, Jan Kara wrote:
>>> On Sat 30-01-16 00:28:33, Matthew Wilcox wrote:
>>> > On Fri, Jan 29, 2016 at 11:28:15AM -0700, Ross Zwisler wrote:
>>> > > I guess I need to go off and understand if we can have DAX mappings on 
>>> > > such a
>>> > > device.  If we can, we may have a problem - we can get the block_device 
>>> > > from
>>> > > get_block() in I/O path and the various fault paths, but we don't have 
>>> > > access
>>> > > to get_block() when flushing via dax_writeback_mapping_range().  We 
>>> > > avoid
>>> > > needing it the normal case by storing the sector results from 
>>> > > get_block() in
>>> > > the radix tree.
>>> >
>>> > I think we're doing it wrong by storing the sector in the radix tree; we'd
>>> > really need to store both the sector and the bdev which is too much data.
>>> >
>>> > If we store the PFN of the underlying page instead, we don't have this
>>> > problem.  Instead, we have a different problem; of the device going
>>> > away under us.  I'm trying to find the code which tears down PTEs when
>>> > the device goes away, and I'm not seeing it.  What do we do about user
>>> > mappings of the device?
>>>
>>> So I don't have a strong opinion whether storing PFN or sector is better.
>>> Maybe PFN is somewhat more generic but OTOH turning DAX off for special
>>> cases like inodes on XFS RT devices would be IMHO fine.
>>
>> We need to support alternate devices.
>
> Embedded devices trying to use NOR Flash to free up RAM was
> historically one of the more prevalent real world uses of the old
> filemap_xip.c code although the users never made it to mainline.  So I
> spent some time last week trying to figure out how to make a subset of
> DAX not depend on CONFIG_BLOCK.  It was a very frustrating and
> unfruitful experience.  I discarded my main conclusion as impractical,
> but now that I see the difficultly DAX faces in dealing with
> "alternate devices" especially some of the crazy stuff btrfs can do, I
> wonder if it's not so crazy after all.
>
> Lets stop calling bdev_direct_access() directly from DAX.  Let the
> filesystems do it.
>
> Sure we could enable generic_dax_direct_access() helper for the
> filesystems that only support single devices to make it easy.  But XFS
> and btrfs for example, have to do the work of figuring out what bdev
> is required and then calling bdev_direct_access().
>
> My reasoning is that the filesystem knows how to map inodes and
> offsets to devices and sectors, no matter how complex that is.  It
> would even enable a filesystem to intelligently use a mix of
> direct_access and regular block devices down the road.  Of course it
> would also make the block-less solution doable.
>
> Good idea?  Stupid idea?

The CONFIG_BLOCK=y case isn't going anywhere, so if anything it seems
the CONFIG_BLOCK=n is an incremental feature in its own right.  What
driver and what filesystem are looking to enable this XIP support in?

Re: [PATCH 10/14] ARM: dts: sun8i-a83t: Add PRCM related clocks and resets

[Chen-Yu Tsai]

On Sun, Jan 31, 2016 at 9:21 AM, Vishnu Patekar
 wrote:
> This adds A83T PRCM related clocks, clock resets.
>
> As a83t apb0 gates clock support is added earlier, this enables it.
> Apart from apb0 gates, other added clocks are compatible with
> earlier sun8i socs.
>
> Signed-off-by: Vishnu Patekar 
> ---
>  arch/arm/boot/dts/sun8i-a83t.dtsi | 44 
> +++
>  1 file changed, 44 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
> b/arch/arm/boot/dts/sun8i-a83t.dtsi
> index ac96aa1..5ea20ff 100644
> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
> @@ -268,6 +268,44 @@
>  "mmc2_output",
>  "mmc2_sample";
> };
> +
> +   cpus_clk: clk@01f01400 {
> +   compatible = "allwinner,sun9i-a80-cpus-clk";
> +   reg = <0x01f01400 0x4>;
> +   #clock-cells = <0>;
> +   clocks = <>, <>, <>, <>;
> +   clock-output-names = "cpus";
> +   };
> +
> +   ahb0: ahb0_clk {
> +   compatible = "fixed-factor-clock";
> +   #clock-cells = <0>;
> +   clock-div = <1>;
> +   clock-mult = <1>;
> +   clocks = <_clk>;
> +   clock-output-names = "ahb0";
> +   };
> +
> +   apb0: clk@01f0140c {
> +   compatible = "allwinner,sun8i-a23-apb0-clk";

This is actually wrong, as it is wrong in sun9i-a80.dtsi.
I've sent a patch series for it.

Also the drivers for "allwinner,sun9i-a80-cpus-clk" and
"allwinner,sun9i-a80-apbs-clk"
are only compiled for CONFIG_MACH_SUN9I. Please add a patch to address this.

Regards
ChenYu

> +   reg = <0x01f0140c 0x4>;
> +   #clock-cells = <0>;
> +   clocks = <>;
> +   clock-output-names = "apb0";
> +   };
> +
> +   apb0_gates: clk@01f01428 {
> +   compatible = "allwinner,sun8i-a83t-apb0-gates-clk";
> +   reg = <0x01f01428 0x4>;
> +   #clock-cells = <1>;
> +   clocks = <>;
> +   clock-indices = <0>, <1>,
> +   <2>, <3>,
> +   <4>, <6>, <7>;
> +   clock-output-names = "apb0_pio", "apb0_ir",
> +   "apb0_timer", "apb0_rsb",
> +   "apb0_uart", "apb0_i2c0", "apb0_twd";
> +   };
> };
>
> soc {
> @@ -434,5 +472,11 @@
> #interrupt-cells = <3>;
> interrupts =  IRQ_TYPE_LEVEL_HIGH)>;
> };
> +
> +   apb0_reset: reset@01f014b0 {
> +   reg = <0x01f014b0 0x4>;
> +   compatible = "allwinner,sun6i-a31-clock-reset";
> +   #reset-cells = <1>;
> +   };
> };
>  };
> --
> 1.9.1
>

Re: [RFC][PATCH] mips: Fix arch_spin_unlock()

[Paul E. McKenney]

On Tue, Feb 02, 2016 at 01:19:04PM +0800, Boqun Feng wrote:
> Hi Paul,
> 
> On Mon, Feb 01, 2016 at 07:54:58PM -0800, Paul E. McKenney wrote:
> > On Mon, Feb 01, 2016 at 01:56:22PM +, Will Deacon wrote:
> > > On Fri, Jan 29, 2016 at 02:22:53AM -0800, Paul E. McKenney wrote:
> > > > On Fri, Jan 29, 2016 at 09:59:59AM +, Will Deacon wrote:
> > > > > On Thu, Jan 28, 2016 at 02:31:31PM -0800, Paul E. McKenney wrote:
> > > > 
> > > > [ . . . ]
> > > > 
> > > > > > For Linux in general, this is a question: How strict do we want to 
> > > > > > be
> > > > > > about matching the type of write with the corresponding read?  My
> > > > > > default approach is to initially be quite strict and loosen as 
> > > > > > needed.
> > > > > > Here "quite strict" might mean requiring an rcu_assign_pointer() for
> > > > > > the write and rcu_dereference() for the read, as opposed to (say)
> > > > > > ACCESS_ONCE() for the read.  (I am guessing that this would be too
> > > > > > tight, but it makes a good example.)
> > > > > > 
> > > > > > Thoughts?
> > > > > 
> > > > > That sounds broadly sensible to me and allows rcu_assign_pointer and
> > > > > rcu_dereference to be used as drop-in replacements for release/acquire
> > > > > where local transitivity isn't required. However, I don't think we can
> > > > > rule out READ_ONCE/WRITE_ONCE interactions as they seem to be used
> > > > > already in things like the osq_lock (albeit without the address
> > > > > dependency).
> > > > 
> > > > Agreed.  So in the most strict case that I can imagine anyone putting
> > > > up with, we have the following pairings:
> > > 
> > > I think we can group these up:
> > > 
> > > Locally transitive:
> > > 
> > > > o   smp_store_release() -> smp_load_acquire() (locally transitive)
> > > 
> > > Locally transitive chain termination:
> > > 
> > > (i.e. these can't be used to extend a chain)
> > 
> > Agreed.
> > 
> > > > o   smp_store_release() -> lockless_dereference() (???)
> > > > o   rcu_assign_pointer() -> rcu_dereference()
> > > > o   smp_store_release() -> READ_ONCE(); if
> 
> Just want to make sure, this one is actually:
> 
> o smp_store_release() -> READ_ONCE(); if ;
> 
> right? Because control dependency only orders READ->WRITE.

Yep!

> If so, do we also need to take the following pairing into consideration?
> 
> o smp_store_release() -> READ_ONCE(); if ;smp_rmb(); 

It looks like we will be restricing smp_rmb() and smp_wmb() to pairwise
scenarios only.  So no transitivity in any scenarios involving these
two primitives.

> > I am OK with the first and last, but I believe that the middle one
> > has real use cases.  So the rcu_assign_pointer() -> rcu_dereference()
> > case needs to be locally transitive.
> 
> Hmm... I don't think we should differ rcu_dereference() and
> lockless_dereference(). One reason: list_for_each_entry_rcu() are using
> lockless_dereference() right now, which means we used to think
> rcu_dereference() and lockless_dereference() are interchangeable, right?

They use the same instructions, if that is what you mean, so intuitively
they should behave the same.  I don't feel all that strongly either way.
But where there is uncertainty, we should -not- assume ordering.  It is
easy to tighten the rules later, but hard to loosen them.

That might change if tools that automatically analyze usage patterns
in raw code, but we do not yet have such tools.

Thanx, Paul

> Besides, Will, what's the reason of having a locally transitive chain
> termination? Because on some architectures RELEASE->DEPENDENCY pairs may
> not be locally transitive?
> 
> Regards,
> Boqun
> 
> > > Globally transitive:
> > > 
> > > > o   smp_mb(); WRITE_ONCE() -> READ_ONCE(); (globally transitive)
> > > > o   synchronize_rcu(); WRITE_ONCE() -> READ_ONCE(); (globally 
> > > > transitive)
> > > 
> > > RCU:
> > > 
> > > > o   synchronize_rcu(); WRITE_ONCE() -> rcu_read_lock(); READ_ONCE()
> > > > (strange and wonderful properties)
> > 
> > Agreed.
> > 
> > > > Seem reasonable, or am I missing some?
> > > 
> > > Looks alright to me.
> > 
> > So I have some litmus tests to generate.  ;-)
> > 
> > Thnax, Paul
> > 

Re: [PATCH 4/6] ARM: dts: imx6: change TX6 module names due to new HW revision

[Shawn Guo]

On Wed, Jan 20, 2016 at 01:57:04PM +0100, Lothar Waßmann wrote:
> The second last digit of the Ka-Ro electronics TX-module names denotes
> the HW revision of the module. HW rev 1 and 3 of the TX6 modules can
> use the same DTB. Change this digit to 'x' to indicate that the DTB
> file can be used for both HW revisions.

This is simply a unnecessary churn of the source tree.  I wouldn't take
it.

Shawn

> 
> Signed-off-by: Lothar Waßmann 
> ---
>  arch/arm/boot/dts/Makefile   |  10 +-
>  arch/arm/boot/dts/imx6dl-tx6u-801x.dts   | 177 ---
>  arch/arm/boot/dts/imx6dl-tx6u-80xx.dts   | 185 
>  arch/arm/boot/dts/imx6dl-tx6u-811x.dts   | 150 
>  arch/arm/boot/dts/imx6dl-tx6u-81xx.dts   | 156 +
>  arch/arm/boot/dts/imx6q-tx6q-1010-comtft.dts | 103 ---
>  arch/arm/boot/dts/imx6q-tx6q-1010.dts| 177 ---
>  arch/arm/boot/dts/imx6q-tx6q-10x0-comtft.dts | 119 +
>  arch/arm/boot/dts/imx6q-tx6q-10x0.dts| 191 
>  arch/arm/boot/dts/imx6q-tx6q-1110.dts| 154 -
>  arch/arm/boot/dts/imx6q-tx6q-11x0.dts| 249 
> +++
>  11 files changed, 905 insertions(+), 766 deletions(-)
>  delete mode 100644 arch/arm/boot/dts/imx6dl-tx6u-801x.dts
>  create mode 100644 arch/arm/boot/dts/imx6dl-tx6u-80xx.dts
>  delete mode 100644 arch/arm/boot/dts/imx6dl-tx6u-811x.dts
>  create mode 100644 arch/arm/boot/dts/imx6dl-tx6u-81xx.dts
>  delete mode 100644 arch/arm/boot/dts/imx6q-tx6q-1010-comtft.dts
>  delete mode 100644 arch/arm/boot/dts/imx6q-tx6q-1010.dts
>  create mode 100644 arch/arm/boot/dts/imx6q-tx6q-10x0-comtft.dts
>  create mode 100644 arch/arm/boot/dts/imx6q-tx6q-10x0.dts
>  delete mode 100644 arch/arm/boot/dts/imx6q-tx6q-1110.dts
>  create mode 100644 arch/arm/boot/dts/imx6q-tx6q-11x0.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index a4a6d70..5759aac 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -312,8 +312,8 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
>   imx6dl-sabrelite.dtb \
>   imx6dl-sabresd.dtb \
>   imx6dl-tx6dl-comtft.dtb \
> - imx6dl-tx6u-801x.dtb \
> - imx6dl-tx6u-811x.dtb \
> + imx6dl-tx6u-80xx.dtb \
> + imx6dl-tx6u-81xx.dtb \
>   imx6dl-udoo.dtb \
>   imx6dl-wandboard.dtb \
>   imx6dl-wandboard-revb1.dtb \
> @@ -342,11 +342,11 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
>   imx6q-sabresd.dtb \
>   imx6q-sbc6x.dtb \
>   imx6q-tbs2910.dtb \
> - imx6q-tx6q-1010.dtb \
> - imx6q-tx6q-1010-comtft.dtb \
>   imx6q-tx6q-1020.dtb \
>   imx6q-tx6q-1020-comtft.dtb \
> - imx6q-tx6q-1110.dtb \
> + imx6q-tx6q-10x0-comtft.dtb \
> + imx6q-tx6q-10x0.dtb \
> + imx6q-tx6q-11x0.dtb \
>   imx6q-udoo.dtb \
>   imx6q-wandboard.dtb \
>   imx6q-wandboard-revb1.dtb
> diff --git a/arch/arm/boot/dts/imx6dl-tx6u-801x.dts 
> b/arch/arm/boot/dts/imx6dl-tx6u-801x.dts
> deleted file mode 100644
> index 5fe465c..000
> --- a/arch/arm/boot/dts/imx6dl-tx6u-801x.dts
> +++ /dev/null
> @@ -1,177 +0,0 @@
> -/*
> - * Copyright 2014 Lothar Waßmann 
> - *
> - * The code contained herein is licensed under the GNU General Public
> - * License. You may obtain a copy of the GNU General Public License
> - * Version 2 at the following locations:
> - *
> - * http://www.opensource.org/licenses/gpl-license.html
> - * http://www.gnu.org/copyleft/gpl.html
> - */
> -
> -/dts-v1/;
> -#include "imx6dl.dtsi"
> -#include "imx6qdl-tx6.dtsi"
> -
> -/ {
> - model = "Ka-Ro electronics TX6U-801x Module";
> - compatible = "karo,imx6dl-tx6dl", "fsl,imx6dl";
> -
> - aliases {
> - display = 
> - };
> -
> - backlight: backlight {
> - compatible = "pwm-backlight";
> - pwms = < 0 50 PWM_POLARITY_INVERTED>;
> - power-supply = <_3v3>;
> - /*
> -  * a poor man's way to create a 1:1 relationship between
> -  * the PWM value and the actual duty cycle
> -  */
> - brightness-levels = < 0  1  2  3  4  5  6  7  8  9
> -  10 11 12 13 14 15 16 17 18 19
> -  20 21 22 23 24 25 26 27 28 29
> -  30 31 32 33 34 35 36 37 38 39
> -  40 41 42 43 44 45 46 47 48 49
> -  50 51 52 53 54 55 56 57 58 59
> -  60 61 62 63 64 65 66 67 68 69
> -  70 71 72 73 74 75 76 77 78 79
> -  80 81 82 83 84 85 86 87 88 89
> -  90 91 92 93 94 95 96 97 98 99
> - 100>;
> - default-brightness-level = <50>;
> - };
> -
> - display: display@di0 {
> - compatible = "fsl,imx-parallel-display";
> - 

Re: [PATCH 09/14] ARM: dts: sun8i-a83t: Add mmc controller nodes

[Chen-Yu Tsai]

On Sun, Jan 31, 2016 at 9:21 AM, Vishnu Patekar
 wrote:
> A83T mmc is compatible with earliers sunxi socs.
> This adds mmc0, mmc1, and mmc2 controller nodes for A83T.
>
> Signed-off-by: Vishnu Patekar 
> ---
>  arch/arm/boot/dts/sun8i-a83t.dtsi | 57 
> +++
>  1 file changed, 57 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
> b/arch/arm/boot/dts/sun8i-a83t.dtsi
> index b8c8b60..ac96aa1 100644
> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
> @@ -276,6 +276,63 @@
> #size-cells = <1>;
> ranges;
>
> +   mmc0: mmc@01c0f000 {
> +   compatible = "allwinner,sun5i-a13-mmc";
> +   reg = <0x01c0f000 0x1000>;
> +   clocks = <_gates 8>,
> +<_clk 0>,
> +<_clk 1>,
> +<_clk 2>;
> +   clock-names = "ahb",
> + "mmc",
> + "output",
> + "sample";
> +   resets = <_reset0 8>;
> +   reset-names = "ahb";
> +   interrupts = ;
> +   status = "disabled";
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   };
> +
> +   mmc1: mmc@01c1 {
> +   compatible = "allwinner,sun5i-a13-mmc";
> +   reg = <0x01c1 0x1000>;
> +   clocks = <_gates 9>,
> +<_clk 0>,
> +<_clk 1>,
> +<_clk 2>;
> +   clock-names = "ahb",
> + "mmc",
> + "output",
> + "sample";
> +   resets = <_reset0 9>;
> +   reset-names = "ahb";
> +   interrupts = ;
> +   status = "disabled";
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   };
> +
> +   mmc2: mmc@01c11000 {
> +   compatible = "allwinner,sun5i-a13-mmc";
> +   reg = <0x01c11000 0x1000>;
> +   clocks = <_gates 10>,
> +<_clk 0>,
> +<_clk 1>,
> +<_clk 2>;
> +   clock-names = "ahb",
> + "mmc",
> + "output",
> + "sample";
> +   resets = <_reset0 10>;
> +   reset-names = "ahb";
> +   interrupts = ;
> +   status = "disabled";
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   };
> +

This patch looks good, except for the reset control I pointed out in
the other patch.

Regards
ChenYu

> pio: pinctrl@01c20800 {
> compatible = "allwinner,sun8i-a83t-pinctrl";
> interrupts = ,
> --
> 1.9.1
>

Re: [RFC PATCH 11/19] cpufreq: assert policy->rwsem is held in __cpufreq_governor

[Viresh Kumar]

On 01-02-16, 22:00, Rafael J. Wysocki wrote:
> I'm not sure what you mean by "the sysfs lock" here?  The policy rwsem
> or something else?

He perhaps referred to the s_active.lock that we see in traces.

-- 
viresh

Re: [RFC PATCH 11/19] cpufreq: assert policy->rwsem is held in __cpufreq_governor

[Viresh Kumar]

On 01-02-16, 12:24, Saravana Kannan wrote:
> On 02/01/2016 02:22 AM, Rafael J. Wysocki wrote:
> I'm not sure whose idea you are referring to. Viresh's (I don't think I saw
> his proposal) or mine.

http://git.linaro.org/people/viresh.kumar/linux.git/commit/57714d5b1778f2f610bcc5c74d85b29ba1cc1995

> Anyway, to explain my suggestion better, I'm proposing to make it so that we
> don't have a need for the AB BA locking. The only reason the governor needs
> to even grab the sysfs lock is to add/remove the sysfs attribute files.
> 
> That can be easily achieved if the policy struct has some "gov_attrs"
> field(s) that each governor populates. Then the framework just has to create
> them after POLICY_INIT is processed by the governor and remove them before
> POILICY_EXIT is sent to the governor.

What will that solve? It will stay exactly same then as well, as we
would be adding/removing these attributes from within the same
policy->rwsem ..

> That way, we also avoid having to worry about the gov attributes accessed by
> the show/store disappearing while the files are being accessed.

It can't happen. S_active lock should be taking care of that, isn't
it?

-- 
viresh

Re: [PATCH 3/6] ARM: dts: imx6qdl-tx6: add ENET_OUT clock to fec node

[Shawn Guo]

On Wed, Jan 20, 2016 at 01:57:03PM +0100, Lothar Waßmann wrote:
> ENET_OUT is used as reference clock for the ethernet PHY on the Ka-Ro
> TX6 modules. Specify this clock in DTB to let it be managed correctly
> by the driver.
> 
> Signed-off-by: Lothar Waßmann 

Applied, thanks.

Re: [PATCH 2/6] ARM: dts: imx6: use correct mclk frequency for audio codec

[Shawn Guo]

On Wed, Jan 20, 2016 at 01:57:02PM +0100, Lothar Waßmann wrote:
> The reference clock for the SGTL5000 is generated by a 26MHz crystal
> oscillator on the Ka-Ro electronics STK5 eval kits. Use the correct
> frequency setting in DTB.
> 
> Signed-off-by: Lothar Waßmann 

Applied, thanks.

> ---
>  arch/arm/boot/dts/imx6qdl-tx6.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/imx6qdl-tx6.dtsi 
> b/arch/arm/boot/dts/imx6qdl-tx6.dtsi
> index 13cb7cc..9404668 100644
> --- a/arch/arm/boot/dts/imx6qdl-tx6.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-tx6.dtsi
> @@ -41,7 +41,7 @@
>   compatible = "fixed-clock";
>   reg = <0>;
>   #clock-cells = <0>;
> - clock-frequency = <2700>;
> + clock-frequency = <2600>;
>   };
>   };
>  
> -- 
> 2.1.4
> 
> 

[PATCH] usb: xhci: fix build warning

[Sudip Mukherjee]

We were getting build warning about:

drivers/usb/host/xhci.c: In function ‘xhci_add_ep_to_interval_table’:
drivers/usb/host/xhci.c:2499:2: warning: enumeration value
‘USB_SPEED_SUPER_PLUS’ not handled in switch

Fix it by adding SuperSpeedPlus USB3.1 devices as the behaviour is same
as with USB_SPEED_SUPER SuperSpeed devices.

Fixes: 8a1b2725a60d ("usb: define USB_SPEED_SUPER_PLUS speed for SuperSpeedPlus 
USB3.1 devices")
Cc: Mathias Nyman 
Signed-off-by: Sudip Mukherjee 
---
 drivers/usb/host/xhci.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 26a44c0..5bde15b 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -2410,7 +2410,7 @@ void xhci_drop_ep_from_interval_table(struct xhci_hcd 
*xhci,
if (xhci_is_async_ep(ep_bw->type))
return;
 
-   if (udev->speed == USB_SPEED_SUPER) {
+   if (udev->speed >= USB_SPEED_SUPER) {
if (xhci_is_sync_in_ep(ep_bw->type))
xhci->devs[udev->slot_id]->bw_table->ss_bw_in -=
xhci_get_ss_bw_consumed(ep_bw);
@@ -2448,6 +2448,7 @@ void xhci_drop_ep_from_interval_table(struct xhci_hcd 
*xhci,
interval_bw->overhead[HS_OVERHEAD_TYPE] -= 1;
break;
case USB_SPEED_SUPER:
+   case USB_SPEED_SUPER_PLUS:
case USB_SPEED_UNKNOWN:
case USB_SPEED_WIRELESS:
/* Should never happen because only LS/FS/HS endpoints will get
@@ -2474,7 +2475,7 @@ static void xhci_add_ep_to_interval_table(struct xhci_hcd 
*xhci,
if (xhci_is_async_ep(ep_bw->type))
return;
 
-   if (udev->speed == USB_SPEED_SUPER) {
+   if (udev->speed >= USB_SPEED_SUPER) {
if (xhci_is_sync_in_ep(ep_bw->type))
xhci->devs[udev->slot_id]->bw_table->ss_bw_in +=
xhci_get_ss_bw_consumed(ep_bw);
@@ -2507,6 +2508,7 @@ static void xhci_add_ep_to_interval_table(struct xhci_hcd 
*xhci,
interval_bw->overhead[HS_OVERHEAD_TYPE] += 1;
break;
case USB_SPEED_SUPER:
+   case USB_SPEED_SUPER_PLUS:
case USB_SPEED_UNKNOWN:
case USB_SPEED_WIRELESS:
/* Should never happen because only LS/FS/HS endpoints will get
-- 
1.9.1

Re: [PATCH] vmpressure: Fix subtree pressure detection

[Andrew Morton]

On Fri, 29 Jan 2016 11:37:49 +0300 Vladimir Davydov  
wrote:

> On Thu, Jan 28, 2016 at 08:24:30PM +0100, Vlastimil Babka wrote:
> > On 28.1.2016 16:55, Michal Hocko wrote:
> > > On Wed 27-01-16 19:28:57, Vladimir Davydov wrote:
> > >> When vmpressure is called for the entire subtree under pressure we
> > >> mistakenly use vmpressure->scanned instead of vmpressure->tree_scanned
> > >> when checking if vmpressure work is to be scheduled. This results in
> > >> suppressing all vmpressure events in the legacy cgroup hierarchy. Fix
> > >> it.
> > >>
> > >> Fixes: 8e8ae645249b ("mm: memcontrol: hook up vmpressure to socket 
> > >> pressure")
> > >> Signed-off-by: Vladimir Davydov 
> > > 
> > > a = b += c made me scratch my head for a second but this looks correct
> > 
> > Ugh, it's actually a = b += a
> > 
> > While clever and compact, this will make scratch their head anyone looking 
> > at
> > the code in the future. Is it worth it?
> 
> I'm just trying to be consistend with the !tree case, where we do
> exactly the same.

I stared suspiciously at it for a while, decided to let it go. 
Possibly we can remove local `scanned' altogether.  No matter, someone
will clean it all up sometime.

Re: [PATCH] pinctrl: sunxi: Add H3 R_PIO controller support

[Chen-Yu Tsai]

On Mon, Feb 1, 2016 at 6:12 PM, Krzysztof Adamski  wrote:
> H3 has additional PIO controller similar to what we can find on A23.
> It's a 12 pin port, described in H3 Datasheet rev 1.1, pages 345-350.
>
> Signed-off-by: Krzysztof Adamski 
> ---
> .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
> arch/arm/boot/dts/sun8i-h3.dtsi|  12 +++
> drivers/pinctrl/sunxi/Kconfig  |   4 +
> drivers/pinctrl/sunxi/Makefile |   1 +
> drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c | 105
> +
> 5 files changed, 123 insertions(+)
> create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c
>
> diff --git
> a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> index 9213b27..730a917 100644
> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> @@ -20,6 +20,7 @@ Required properties:
>   "allwinner,sun9i-a80-pinctrl"
>   "allwinner,sun9i-a80-r-pinctrl"
>   "allwinner,sun8i-a83t-pinctrl"
> +  "allwinner,sun8i-h3-r-pinctrl"
>   "allwinner,sun8i-h3-pinctrl"

h3-r-pinctrl comes after h3-pinctrl


>
> - reg: Should contain the register physical address and length for the
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
> b/arch/arm/boot/dts/sun8i-h3.dtsi
> index 1524130e..745f64c 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -493,5 +493,17 @@
> interrupts = ,
>  ;
> };
> +
> +   r_pio: pinctrl@01f02c00 {
> +   compatible = "allwinner,sun8i-h3-r-pinctrl";
> +   reg = <0x01f02c00 0x400>;
> +   interrupts = ;
> +   clocks = <_gates 69>;

This is probably wrong. According to other SoCs all R_ block peripherals
have clock gates and reset controls in the PRCM.

> +   gpio-controller;
> +   #gpio-cells = <3>;
> +   interrupt-controller;
> +   #interrupt-cells = <2>;
> +   };
> +

Extra new line here.

Also please split this into a separate patch.

> };
> };
> diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
> index f8dbc8b..75a26c9 100644
> --- a/drivers/pinctrl/sunxi/Kconfig
> +++ b/drivers/pinctrl/sunxi/Kconfig
> @@ -55,6 +55,10 @@ config PINCTRL_SUN8I_H3
> def_bool MACH_SUN8I
> select PINCTRL_SUNXI_COMMON
>
> +config PINCTRL_SUN8I_H3_R
> +   def_bool MACH_SUN8I
> +   select PINCTRL_SUNXI_COMMON
> +
> config PINCTRL_SUN9I_A80
> def_bool MACH_SUN9I
> select PINCTRL_SUNXI_COMMON
> diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
> index ef82f22..a5d56f1 100644
> --- a/drivers/pinctrl/sunxi/Makefile
> +++ b/drivers/pinctrl/sunxi/Makefile
> @@ -14,5 +14,6 @@ obj-$(CONFIG_PINCTRL_SUN8I_A23_R) +=
> pinctrl-sun8i-a23-r.o
> obj-$(CONFIG_PINCTRL_SUN8I_A33) += pinctrl-sun8i-a33.o
> obj-$(CONFIG_PINCTRL_SUN8I_A83T)+= pinctrl-sun8i-a83t.o
> obj-$(CONFIG_PINCTRL_SUN8I_H3)  += pinctrl-sun8i-h3.o
> +obj-$(CONFIG_PINCTRL_SUN8I_H3_R)   += pinctrl-sun8i-h3-r.o
> obj-$(CONFIG_PINCTRL_SUN9I_A80) += pinctrl-sun9i-a80.o
> obj-$(CONFIG_PINCTRL_SUN9I_A80_R)   += pinctrl-sun9i-a80-r.o
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c
> b/drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c
> new file mode 100644
> index 000..6271ceb
> --- /dev/null
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c
> @@ -0,0 +1,105 @@
> +/*
> + * Allwinner H3 SoCs pinctrl driver.
> + *
> + * Copyright (C) 2016 Krzysztof Adamski 
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "pinctrl-sunxi.h"
> +
> +static const struct sunxi_desc_pin sun8i_h3_r_pins[] = {
> +   SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_twi"), /* SCK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)),  /* PL_EINT0 */
> +   SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_twi"), /* SDA */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)),  /* PL_EINT1 */
> +   SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + 

Re: [PATCH 1/6] dma: enable mxs-dma for imx6ul

[Shawn Guo]

On Mon, Jan 25, 2016 at 05:40:43PM +0530, Vinod Koul wrote:
> On Wed, Jan 20, 2016 at 01:57:01PM +0100, Lothar Waßmann wrote:
> > The mxs-dma unit is also available on i.MX6UL. Make it possible to
> > select it in Kconfig.
> 
> It should be dmaengine:xxx
> 
> With that
> 
> Acked-by: Vinod Koul 

I think this can go separately via dma tree.

Shawn

> 
> > 
> > Signed-off-by: Lothar Waßmann 
> > ---
> >  drivers/dma/Kconfig | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> > index 79b1390..2516524 100644
> > --- a/drivers/dma/Kconfig
> > +++ b/drivers/dma/Kconfig
> > @@ -341,12 +341,13 @@ config MV_XOR
> >  
> >  config MXS_DMA
> > bool "MXS DMA support"
> > -   depends on SOC_IMX23 || SOC_IMX28 || SOC_IMX6Q
> > +   depends on SOC_IMX23 || SOC_IMX28 || SOC_IMX6Q || SOC_MX6UL
> > select STMP_DEVICE
> > select DMA_ENGINE
> > help
> >   Support the MXS DMA engine. This engine including APBH-DMA
> > - and APBX-DMA is integrated into Freescale i.MX23/28/MX6Q/MX6DL chips.
> > + and APBX-DMA is integrated into Freescale
> > + i.MX23/28/MX6Q/MX6DL/MX6UL chips.
> >  
> >  config MX3_IPU
> > bool "MX3x Image Processing Unit support"
> > -- 
> > 2.1.4
> > 
> 
> -- 
> ~Vinod
> 

Re: [PATCH] ARM: dts: imx28-tx28: use correct mclk frequency

[Shawn Guo]

On Wed, Jan 20, 2016 at 01:30:15PM +0100, Lothar Waßmann wrote:
> The reference clock for the SGTL5000 is generated by a 26MHz crystal
> oscillator on the Ka-Ro electronics STK5 eval kits. Use the correct
> frequency setting in DTB.
> 
> Signed-off-by: Lothar Waßmann 

Applied, thanks.

Re: [PATCH v2] err.h: allow IS_ERR_VALUE to handle properly more types

[Andrew Morton]

On Thu, 28 Jan 2016 09:27:28 +0100 Andrzej Hajda  wrote:

> Current implementation of IS_ERR_VALUE works correctly only with
> following types:
> - unsigned long,
> - short, int, long.
> Other types are handled incorrectly either on 32-bit either on 64-bit
> either on both architectures.
> The patch fixes it by comparing argument with MAX_ERRNO casted
> to argument's type for unsigned types and comparing with zero for signed
> types. As a result all integer types bigger than char are handled properly.
> 
> I have analyzed usage of IS_ERR_VALUE using coccinelle and in about 35
> cases it is used incorrectly, ie it can hide errors depending of 32/64 bit
> architecture. Instead of fixing usage I propose to enhance the macro
> to cover more types.
> And just for the record: the macro is used 101 times with signed variables,
> I am not sure if it should be preferred over simple comparison "ret < 0",
> but the new version can do it as well.
> 
> And below list of detected potential errors:
>
> ...
>
> --- a/include/linux/err.h
> +++ b/include/linux/err.h
> @@ -18,7 +18,9 @@
>  
>  #ifndef __ASSEMBLY__
>  
> -#define IS_ERR_VALUE(x) unlikely((x) >= (unsigned long)-MAX_ERRNO)
> +#define IS_ERR_VALUE(x) ((typeof(x))(-1) <= 0 \
> + ? unlikely((x) < 0) \
> + : unlikely((x) >= (typeof(x))-MAX_ERRNO))
>  

hm, seems complicated.  Can we simply cast the value to long?

#define IS_ERR_VALUE(x) ((long)x < 0) && (long)x >= (long)-MAX_ERRNO)

and simplify that to

#define IS_ERR_VALUE(x) ((unsigned long)(long)x >= (unsigned long)-MAX_ERRNO)

or something like that.

[PATCH 1/1] xen-netfront: uninitialized fields in xenvif_rx_action

[Dongli Zhang]

While npo.copy and npo.meta are initialized in xenvif_rx_action, fields
such as npo.meta_prod are directly used later in xenvif_gop_skb without
being initialized first. Although the output of xenvif_rx_action is based
on the difference between new npo->meta_prod and old npo->meta_prod, it is
better to initialize them to 0 at the beginning.

Signed-off-by: Dongli Zhang 
---
 drivers/net/xen-netback/netback.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/xen-netback/netback.c 
b/drivers/net/xen-netback/netback.c
index 61b97c3..32f0fbd 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -560,6 +560,10 @@ static void xenvif_rx_action(struct xenvif_queue *queue)
bool need_to_notify = false;
 
struct netrx_pending_operations npo = {
+   .copy_prod = 0,
+   .copy_cons = 0,
+   .meta_prod = 0,
+   .meta_cons = 0,
.copy  = queue->grant_copy_op,
.meta  = queue->meta,
};
-- 
1.9.1

Re: [PATCH] ARM: dts: imx51: add support for Ka-Ro electronics TX51 modules

[Shawn Guo]

On Wed, Jan 20, 2016 at 01:23:39PM +0100, Lothar Waßmann wrote:
> The TX51-8xxx module series is a System On Module manufactured by
>   Ka-Ro electronics GmbH with the following characteristics:
>   ProcessorFreescale i.MX515
>  up to 800 MHz (commercial)
>  up to 600 MHz (industrial)
>   RAM  128/256MB mobile DDR-SDRAM
>   ROM  128MB NAND Flash
>   RTC  DS1339 Real Time Clock
>   Power supply Single 3.1V to 5.5V
>   Size 26mm SO-DIMM
>   Temp. Range  0°C..70°C (-40°C..85°C)
> 
> Signed-off-by: Lothar Waßmann 
> ---
>  arch/arm/boot/dts/Makefile   |   3 +-
>  arch/arm/boot/dts/imx51-tx51.dts | 749 
> +++
>  2 files changed, 751 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/boot/dts/imx51-tx51.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index a4a6d70..ea70f34 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -277,7 +277,8 @@ dtb-$(CONFIG_SOC_IMX51) += \
>   imx51-babbage.dtb \
>   imx51-digi-connectcore-jsk.dtb \
>   imx51-eukrea-mbimxsd51-baseboard.dtb \
> - imx51-ts4800.dtb
> + imx51-ts4800.dtb \
> + imx51-tx51.dtb
>  dtb-$(CONFIG_SOC_IMX53) += \
>   imx53-ard.dtb \
>   imx53-m53evk.dtb \
> diff --git a/arch/arm/boot/dts/imx51-tx51.dts 
> b/arch/arm/boot/dts/imx51-tx51.dts
> new file mode 100644
> index 000..80c5d60
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx51-tx51.dts
> @@ -0,0 +1,749 @@
> +/*
> + * Copyright 2012-2014 Lothar Waßmann 
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */

We generally suggest GPL/X11 dual license for new dts to consider
non-Linux device tree users.

> +
> +/dts-v1/;
> +#include "imx51.dtsi"
> +#include 
> +#include 
> +
> +/ {
> + model = "Ka-Ro electronics TX51 module";
> + compatible = "karo,tx51", "fsl,imx51";
> +
> + aliases {
> + backlight = 
> + display = 
> + i2c1 = _gpio;
> + usbotg = 
> + wlan0 = 
> + };
> +
> + chosen {
> + stdout-path = 
> + };
> +
> + backlight: pwm-backlight {
> + compatible = "pwm-backlight";
> + pwms = < 0 50 PWM_POLARITY_INVERTED>;
> + power-supply = <_3v3>;
> + brightness-levels = <
> +   0  1  2  3  4  5  6  7  8  9
> +  10 11 12 13 14 15 16 17 18 19
> +  20 21 22 23 24 25 26 27 28 29
> +  30 31 32 33 34 35 36 37 38 39
> +  40 41 42 43 44 45 46 47 48 49
> +  50 51 52 53 54 55 56 57 58 59
> +  60 61 62 63 64 65 66 67 68 69
> +  70 71 72 73 74 75 76 77 78 79
> +  80 81 82 83 84 85 86 87 88 89
> +  90 91 92 93 94 95 96 97 98 99
> + 100
> + >;
> + default-brightness-level = <50>;
> + };
> +
> + clocks {
> + ckih1 {
> + clock-frequency = <0>;
> + };
> +
> + mclk: clock@0 {

I would like to see these fixed rate clocks are named in a consistent
way, maybe just drop 'reg' property and use a unique clock name to align
with what imx51.dtsi does.

> + compatible = "fixed-clock";
> + reg = <0>;
> + #clock-cells = <0>;
> + clock-output-names = "mclk";
> + clock-frequency = <2600>;
> + };
> +
> + clk_26M: clock@1 {
> + compatible = "fixed-clock";
> + reg = <1>;
> + #clock-cells = <0>;
> + clock-output-names = "clk_26M";
> + clock-frequency = <2600>;
> + gpios = < 7 GPIO_ACTIVE_HIGH>;
> + };
> +
> + wlan_ref_clk: wlan-ref-clk {
> + compatible = "ti,wilink-clock";

I do not see this compatible string is documented anywhere.  And how is
this compatible string used by kernel?

> + #clock-cells = <0>;
> + clock-frequency = <3840>;
> + };
> + };
> +
> + display: display@di0 {
> + compatible = "fsl,imx-parallel-display";
> + interface-pix-fmt = "rgb24";
> + pinctrl-names = "default";
> + pinctrl-0 = <_ipu_disp0>;
> +
> + display-timings {
> + VGA {
> + clock-frequency = <2520>;
> + hactive = <640>;
> + vactive = 

[PATCH v2] mmc: dw_mmc: fix num_slots setting

[Shawn Lin]

This patch make num_slots to 1 if pdata->num_slot is not
defined. Meanwhile, we need to make sure num_slots should
not larger that the supported slots

Signed-off-by: Shawn Lin 

---

Changes in v2:
- remove default num-slots setting from dw_mci_parse_dt

 drivers/mmc/host/dw_mmc.c | 23 ++-
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 7128351..9696b77 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2864,12 +2864,7 @@ static struct dw_mci_board *dw_mci_parse_dt(struct 
dw_mci *host)
return ERR_PTR(-ENOMEM);
 
/* find out number of slots supported */
-   if (of_property_read_u32(dev->of_node, "num-slots",
-   >num_slots)) {
-   dev_info(dev,
-"num-slots property not found, assuming 1 slot is 
available\n");
-   pdata->num_slots = 1;
-   }
+   of_property_read_u32(np, "num-slots", >num_slots);
 
/* get quirks */
for (idx = 0; idx < ARRAY_SIZE(of_quirks); idx++)
@@ -2949,12 +2944,6 @@ int dw_mci_probe(struct dw_mci *host)
}
}
 
-   if (host->pdata->num_slots < 1) {
-   dev_err(host->dev,
-   "Platform data must supply num_slots.\n");
-   return -ENODEV;
-   }
-
host->biu_clk = devm_clk_get(host->dev, "biu");
if (IS_ERR(host->biu_clk)) {
dev_dbg(host->dev, "biu clock not available\n");
@@ -3111,7 +3100,15 @@ int dw_mci_probe(struct dw_mci *host)
if (host->pdata->num_slots)
host->num_slots = host->pdata->num_slots;
else
-   host->num_slots = SDMMC_GET_SLOT_NUM(mci_readl(host, HCON));
+   host->num_slots = 1;
+
+   if (host->num_slots < 1 ||
+   host->num_slots > SDMMC_GET_SLOT_NUM(mci_readl(host, HCON))) {
+   dev_err(host->dev,
+   "Platform data must supply correct num_slots.\n");
+   ret = -ENODEV;
+   goto err_clk_ciu;
+   }
 
/*
 * Enable interrupts for command done, data over, data empty,
-- 
2.3.7

Re: [PATCH V2 16/16] cpufreq: dt: No need to allocate resources anymore

[Viresh Kumar]

On 28-01-16, 13:50, Viresh Kumar wrote:
> OPP layer manages it now and cpufreq-dt driver doesn't need it. But, we
> still need to check for availability of resources for deferred probing.
> 
> Signed-off-by: Viresh Kumar 

Got updated due to 11/16 ..

-8<-
From: Viresh Kumar 
Date: Wed, 9 Sep 2015 10:41:26 +0530
Subject: [PATCH 09/20] cpufreq: dt: No need to allocate resources anymore

OPP layer manages it now and cpufreq-dt driver doesn't need it. But, we
still need to check for availability of resources for deferred probing.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq-dt.c | 116 ++-
 1 file changed, 48 insertions(+), 68 deletions(-)

diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 3c43fda48bdf..1beb484b4bbe 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -31,7 +31,6 @@
 
 struct private_data {
struct device *cpu_dev;
-   struct regulator *cpu_reg;
struct thermal_cooling_device *cdev;
const char *reg_name;
 };
@@ -88,73 +87,61 @@ static const char *find_supply_name(struct device *dev)
return name;
 }
 
-static int allocate_resources(int cpu, struct device **cdev,
- struct regulator **creg, struct clk **cclk)
+static int resources_available(void)
 {
struct device *cpu_dev;
struct regulator *cpu_reg;
struct clk *cpu_clk;
int ret = 0;
-   char *reg_cpu0 = "cpu0", *reg_cpu = "cpu", *reg;
+   const char *name;
 
-   cpu_dev = get_cpu_device(cpu);
+   cpu_dev = get_cpu_device(0);
if (!cpu_dev) {
-   pr_err("failed to get cpu%d device\n", cpu);
+   pr_err("failed to get cpu0 device\n");
return -ENODEV;
}
 
-   /* Try "cpu0" for older DTs */
-   if (!cpu)
-   reg = reg_cpu0;
-   else
-   reg = reg_cpu;
-
-try_again:
-   cpu_reg = regulator_get_optional(cpu_dev, reg);
-   ret = PTR_ERR_OR_ZERO(cpu_reg);
+   cpu_clk = clk_get(cpu_dev, NULL);
+   ret = PTR_ERR_OR_ZERO(cpu_clk);
if (ret) {
/*
-* If cpu's regulator supply node is present, but regulator is
-* not yet registered, we should try defering probe.
+* If cpu's clk node is present, but clock is not yet
+* registered, we should try defering probe.
 */
-   if (ret == -EPROBE_DEFER) {
-   dev_dbg(cpu_dev, "cpu%d regulator not ready, retry\n",
-   cpu);
-   return ret;
-   }
-
-   /* Try with "cpu-supply" */
-   if (reg == reg_cpu0) {
-   reg = reg_cpu;
-   goto try_again;
-   }
+   if (ret == -EPROBE_DEFER)
+   dev_dbg(cpu_dev, "clock not ready, retry\n");
+   else
+   dev_err(cpu_dev, "failed to get clock: %d\n", ret);
 
-   dev_dbg(cpu_dev, "no regulator for cpu%d: %d\n", cpu, ret);
+   return ret;
}
 
-   cpu_clk = clk_get(cpu_dev, NULL);
-   ret = PTR_ERR_OR_ZERO(cpu_clk);
-   if (ret) {
-   /* put regulator */
-   if (!IS_ERR(cpu_reg))
-   regulator_put(cpu_reg);
+   clk_put(cpu_clk);
+
+   name = find_supply_name(cpu_dev);
+   if (IS_ERR(name))
+   return PTR_ERR(name);
+
+   if (!name)
+   return 0;
 
+   cpu_reg = regulator_get_optional(cpu_dev, name);
+   ret = PTR_ERR_OR_ZERO(cpu_reg);
+   if (ret) {
/*
-* If cpu's clk node is present, but clock is not yet
-* registered, we should try defering probe.
+* If cpu's regulator supply node is present, but regulator is
+* not yet registered, we should try defering probe.
 */
if (ret == -EPROBE_DEFER)
-   dev_dbg(cpu_dev, "cpu%d clock not ready, retry\n", cpu);
+   dev_dbg(cpu_dev, "cpu0 regulator not ready, retry\n");
else
-   dev_err(cpu_dev, "failed to get cpu%d clock: %d\n", cpu,
-   ret);
-   } else {
-   *cdev = cpu_dev;
-   *creg = cpu_reg;
-   *cclk = cpu_clk;
+   dev_dbg(cpu_dev, "no regulator for cpu0: %d\n", ret);
+
+   return ret;
}
 
-   return ret;
+   regulator_put(cpu_reg);
+   return 0;
 }
 
 static int cpufreq_init(struct cpufreq_policy *policy)
@@ -162,7 +149,6 @@ static int cpufreq_init(struct cpufreq_policy *policy)
struct cpufreq_frequency_table *freq_table;
struct private_data *priv;
struct device *cpu_dev;
-   

Re: [PATCH V2 15/16] cpufreq: dt: drop references to DT node

[Viresh Kumar]

On 28-01-16, 13:50, Viresh Kumar wrote:
> We don't need to get reference to DT node now, lets drop it.
> 
> Signed-off-by: Viresh Kumar 
> Reviewed-by: Stephen Boyd 

And because of changes in 11/16, this got updated as well:

-8<-
From: Viresh Kumar 
Date: Tue, 8 Sep 2015 17:34:26 +0530
Subject: [PATCH 08/20] cpufreq: dt: No need to fetch voltage-tolerance

Its already done by core and we don't need to get it anymore.  And so,
we don't need to get of node in cpufreq_init() anymore, move that to
find_supply_name() instead.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq-dt.c | 48 ++--
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 35c5ec3b333c..3c43fda48bdf 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -33,7 +33,6 @@ struct private_data {
struct device *cpu_dev;
struct regulator *cpu_reg;
struct thermal_cooling_device *cdev;
-   unsigned int voltage_tolerance; /* in percentage */
const char *reg_name;
 };
 
@@ -55,24 +54,38 @@ static int set_target(struct cpufreq_policy *policy, 
unsigned int index)
  * An earlier version of opp-v1 bindings used to name the regulator
  * "cpu0-supply", we still need to handle that for backwards compatibility.
  */
-static const char *find_supply_name(struct device *dev, struct device_node *np)
+static const char *find_supply_name(struct device *dev)
 {
+   struct device_node *np;
struct property *pp;
int cpu = dev->id;
+   const char *name = NULL;
+
+   np = of_node_get(dev->of_node);
+   if (!np) {
+   dev_err(dev, "failed to find cpu%d node\n", cpu);
+   return ERR_PTR(-ENOENT);
+   }
 
/* Try "cpu0" for older DTs */
if (!cpu) {
pp = of_find_property(np, "cpu0-supply", NULL);
-   if (pp)
-   return "cpu0";
+   if (pp) {
+   name = "cpu0";
+   goto node_put;
+   }
}
 
pp = of_find_property(np, "cpu-supply", NULL);
-   if (pp)
-   return "cpu";
+   if (pp) {
+   name = "cpu";
+   goto node_put;
+   }
 
dev_dbg(dev, "no regulator for cpu%d\n", cpu);
-   return NULL;
+node_put:
+   of_node_put(np);
+   return name;
 }
 
 static int allocate_resources(int cpu, struct device **cdev,
@@ -147,7 +160,6 @@ static int allocate_resources(int cpu, struct device **cdev,
 static int cpufreq_init(struct cpufreq_policy *policy)
 {
struct cpufreq_frequency_table *freq_table;
-   struct device_node *np;
struct private_data *priv;
struct device *cpu_dev;
struct regulator *cpu_reg;
@@ -164,13 +176,6 @@ static int cpufreq_init(struct cpufreq_policy *policy)
return ret;
}
 
-   np = of_node_get(cpu_dev->of_node);
-   if (!np) {
-   dev_err(cpu_dev, "failed to find cpu%d node\n", policy->cpu);
-   ret = -ENOENT;
-   goto out_put_reg_clk;
-   }
-
/* Get OPP-sharing information from "operating-points-v2" bindings */
ret = dev_pm_opp_of_get_sharing_cpus(cpu_dev, policy->cpus);
if (ret) {
@@ -181,17 +186,17 @@ static int cpufreq_init(struct cpufreq_policy *policy)
if (ret == -ENOENT)
opp_v1 = true;
else
-   goto out_node_put;
+   goto out_put_reg_clk;
}
 
/*
 * OPP layer will be taking care of regulators now, but it needs to know
 * the name of the regulator first.
 */
-   name = find_supply_name(cpu_dev, np);
+   name = find_supply_name(cpu_dev);
if (IS_ERR(name)) {
ret = PTR_ERR(name);
-   goto out_node_put;
+   goto out_put_reg_clk;
}
 
if (name) {
@@ -199,7 +204,7 @@ static int cpufreq_init(struct cpufreq_policy *policy)
if (ret) {
dev_err(cpu_dev, "Failed to set regulator for cpu%d: 
%d\n",
policy->cpu, ret);
-   goto out_node_put;
+   goto out_put_reg_clk;
}
}
 
@@ -249,7 +254,6 @@ static int cpufreq_init(struct cpufreq_policy *policy)
}
 
priv->reg_name = name;
-   of_property_read_u32(np, "voltage-tolerance", >voltage_tolerance);
 
ret = dev_pm_opp_init_cpufreq_table(cpu_dev, _table);
if (ret) {
@@ -291,8 +295,6 @@ static int cpufreq_init(struct cpufreq_policy *policy)
 
policy->cpuinfo.transition_latency = transition_latency;
 
-   of_node_put(np);
-
return 0;
 
 out_free_cpufreq_table:
@@ -303,8 +305,6 @@ static int cpufreq_init(struct cpufreq_policy 

Re: [PATCH v3 2/2] phy: Add a driver for the ATH79 USB phy

[Kishon Vijay Abraham I]

Hi,

On Friday 29 January 2016 01:22 AM, Alban Bedel wrote:
> The ATH79 USB phy is very simple, it only have a reset. On some SoC a
> second reset is used to force the phy in suspend mode regardless of the
> USB controller status.
> 
> Signed-off-by: Alban Bedel 
> ---
> Changelog:
> v2: * Rebased on the simple PHY driver
> * Added myself as maintainer of the driver
> ---
>  MAINTAINERS |   8 +++
>  drivers/phy/Kconfig |   8 +++
>  drivers/phy/Makefile|   1 +
>  drivers/phy/phy-ath79-usb.c | 116 
> 
>  4 files changed, 133 insertions(+)
>  create mode 100644 drivers/phy/phy-ath79-usb.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 30aca4a..f536d52 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1866,6 +1866,14 @@ S: Maintained
>  F:   drivers/gpio/gpio-ath79.c
>  F:   Documentation/devicetree/bindings/gpio/gpio-ath79.txt
>  
> +ATHEROS 71XX/9XXX USB PHY DRIVER
> +M:   Alban Bedel 
> +W:   https://github.com/AlbanBedel/linux
> +T:   git git://github.com/AlbanBedel/linux
> +S:   Maintained
> +F:   drivers/phy/phy-ath79-usb.c
> +F:   Documentation/devicetree/bindings/phy/phy-ath79-usb.txt
> +
>  ATHEROS ATH GENERIC UTILITIES
>  M:   "Luis R. Rodriguez" 
>  L:   linux-wirel...@vger.kernel.org
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index efbaee4..6090c63 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -15,6 +15,14 @@ config GENERIC_PHY
> phy users can obtain reference to the PHY. All the users of this
> framework should select this config.
>  
> +config PHY_ATH79_USB
> + tristate "Atheros AR71XX/9XXX USB PHY driver"
> + depends on ATH79 || COMPILE_TEST
> + default y if USB_EHCI_HCD_PLATFORM
> + select PHY_SIMPLE
> + help
> +   Enable this to support the USB PHY on Atheros AR71XX/9XXX SoCs.
> +
>  config PHY_BERLIN_USB
>   tristate "Marvell Berlin USB PHY Driver"
>   depends on ARCH_BERLIN && RESET_CONTROLLER && HAS_IOMEM && OF
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 1cc7268..5c9ca5f 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -3,6 +3,7 @@
>  #
>  
>  obj-$(CONFIG_GENERIC_PHY)+= phy-core.o
> +obj-$(CONFIG_PHY_ATH79_USB)  += phy-ath79-usb.o
>  obj-$(CONFIG_PHY_BERLIN_USB) += phy-berlin-usb.o
>  obj-$(CONFIG_PHY_BERLIN_SATA)+= phy-berlin-sata.o
>  obj-$(CONFIG_PHY_DM816X_USB) += phy-dm816x-usb.o
> diff --git a/drivers/phy/phy-ath79-usb.c b/drivers/phy/phy-ath79-usb.c
> new file mode 100644
> index 000..ff49356
> --- /dev/null
> +++ b/drivers/phy/phy-ath79-usb.c
> @@ -0,0 +1,116 @@
> +/*
> + * Copyright (C) 2015 Alban Bedel 

2016?
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct ath79_usb_phy {
> + struct simple_phy sphy;
> + struct reset_control *suspend_override;
> +};
> +
> +static int ath79_usb_phy_power_on(struct phy *phy)
> +{
> + struct ath79_usb_phy *priv = container_of(
> + phy_get_drvdata(phy), struct ath79_usb_phy, sphy);
> + int err;
> +
> + err = simple_phy_power_on(phy);

Why do you need a separate driver for ath79_usb? We should be able to directly
use simple phy driver right?

Thanks
Kishon

Re: [PATCH V2 11/16] cpufreq: dt: Pass regulator name to the OPP core

[Viresh Kumar]

On 01-02-16, 18:34, Stephen Boyd wrote:
> On 01/28, Viresh Kumar wrote:
> > +   cpu_reg = regulator_get_optional(dev, reg);
> > +   ret = PTR_ERR_OR_ZERO(cpu_reg);
> > +   if (!ret) {
> > +   regulator_put(cpu_reg);
> 
> What's the point of creating a regulator just to find the name?
> It seems like we should just look in the DT node of the CPU for
> cpu-supply vs cpu0-supply. Then we don't need to involve the
> regulator framework at all.

Yeah, this can be simplified a bit..

> >  static int allocate_resources(int cpu, struct device **cdev,
> >   struct regulator **creg, struct clk **cclk)
> >  {
> > @@ -383,6 +450,9 @@ static int cpufreq_exit(struct cpufreq_policy *policy)
> > cpufreq_cooling_unregister(priv->cdev);
> > dev_pm_opp_free_cpufreq_table(priv->cpu_dev, >freq_table);
> > dev_pm_opp_of_cpumask_remove_table(policy->related_cpus);
> > +   if (priv->reg_name)
> > +   dev_pm_opp_put_regulator(priv->cpu_dev);
> 
> Let's hope this goes away because it's always right next to
> dev_pm_opp_of_cpumask_remove_table() anyway. Same for reg_name.

We are calling it from cpufreq-dt in this particular case, but it can
be called from platform code as well.

-8<-
From: Viresh Kumar 
Date: Tue, 8 Sep 2015 17:16:46 +0530
Subject: [PATCH 04/20] cpufreq: dt: Pass regulator name to the OPP core

OPP core can handle the regulators by itself, and but it needs to know
the name of the regulator to fetch. Add support for that.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq-dt.c | 51 
 1 file changed, 51 insertions(+)

diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 4c9f8a828f6f..d4651d684f11 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -34,6 +34,7 @@ struct private_data {
struct regulator *cpu_reg;
struct thermal_cooling_device *cdev;
unsigned int voltage_tolerance; /* in percentage */
+   const char *reg_name;
 };
 
 static struct freq_attr *cpufreq_dt_attr[] = {
@@ -119,6 +120,30 @@ static int set_target(struct cpufreq_policy *policy, 
unsigned int index)
return ret;
 }
 
+/*
+ * An earlier version of opp-v1 bindings used to name the regulator
+ * "cpu0-supply", we still need to handle that for backwards compatibility.
+ */
+static const char *find_supply_name(struct device *dev, struct device_node *np)
+{
+   struct property *pp;
+   int cpu = dev->id;
+
+   /* Try "cpu0" for older DTs */
+   if (!cpu) {
+   pp = of_find_property(np, "cpu0-supply", NULL);
+   if (pp)
+   return "cpu0";
+   }
+
+   pp = of_find_property(np, "cpu-supply", NULL);
+   if (pp)
+   return "cpu";
+
+   dev_dbg(dev, "no regulator for cpu%d\n", cpu);
+   return NULL;
+}
+
 static int allocate_resources(int cpu, struct device **cdev,
  struct regulator **creg, struct clk **cclk)
 {
@@ -200,6 +225,7 @@ static int cpufreq_init(struct cpufreq_policy *policy)
unsigned long min_uV = ~0, max_uV = 0;
unsigned int transition_latency;
bool opp_v1 = false;
+   const char *name = NULL;
int ret;
 
ret = allocate_resources(policy->cpu, _dev, _reg, _clk);
@@ -229,6 +255,25 @@ static int cpufreq_init(struct cpufreq_policy *policy)
}
 
/*
+* OPP layer will be taking care of regulators now, but it needs to know
+* the name of the regulator first.
+*/
+   name = find_supply_name(cpu_dev, np);
+   if (IS_ERR(name)) {
+   ret = PTR_ERR(name);
+   goto out_node_put;
+   }
+
+   if (name) {
+   ret = dev_pm_opp_set_regulator(cpu_dev, name);
+   if (ret) {
+   dev_err(cpu_dev, "Failed to set regulator for cpu%d: 
%d\n",
+   policy->cpu, ret);
+   goto out_node_put;
+   }
+   }
+
+   /*
 * Initialize OPP tables for all policy->cpus. They will be shared by
 * all CPUs which have marked their CPUs shared with OPP bindings.
 *
@@ -273,6 +318,7 @@ static int cpufreq_init(struct cpufreq_policy *policy)
goto out_free_opp;
}
 
+   priv->reg_name = name;
of_property_read_u32(np, "voltage-tolerance", >voltage_tolerance);
 
transition_latency = dev_pm_opp_get_max_clock_latency(cpu_dev);
@@ -366,6 +412,8 @@ static int cpufreq_init(struct cpufreq_policy *policy)
kfree(priv);
 out_free_opp:
dev_pm_opp_of_cpumask_remove_table(policy->cpus);
+   if (name)
+   dev_pm_opp_put_regulator(cpu_dev);
 out_node_put:
of_node_put(np);
 out_put_reg_clk:
@@ -383,6 +431,9 @@ static int cpufreq_exit(struct cpufreq_policy *policy)
cpufreq_cooling_unregister(priv->cdev);

[PATCH kernel-tests] kbuild: don't CC the list for BUILD DONE notifications

[Fengguang Wu]

[linux-review:Bean-Huo/Add-a-bakvol-module-in-UBI-layer-for-MLC-paired-page-power-loss-issue/20160202-104450]
 2078d3920abf1d89be7eaf087100b4482dd532dc BUILD DONE

To: Bean Huo 
Cc: peterpand...@micron.com, zszubboc...@micron.com, 
linux-kernel@vger.kernel.org, linux-...@lists.infradead.org, 
bean...@micron.com, boris.brezil...@free-electrons.com, 
computersforpe...@gmail.com, adrian.hun...@intel.com, dedeki...@gmail.com, 
rich...@nod.at

https://github.com/0day-ci/linux  
Bean-Huo/Add-a-bakvol-module-in-UBI-layer-for-MLC-paired-page-power-loss-issue/20160202-104450
2078d3920abf1d89be7eaf087100b4482dd532dc  drivers:mtd:ubi: Kconfig Makefile

Signed-off-by: Fengguang Wu 
---
 lib/kbuild.sh | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/lib/kbuild.sh b/lib/kbuild.sh
index 757aefb..bb879e5 100755
--- a/lib/kbuild.sh
+++ b/lib/kbuild.sh
@@ -5075,9 +5075,6 @@ email_header()
eval "$($LKP_SRC/bin/yaml-to-shell-vars 
$REVIEW_ROOT/$head_commit)"
echo "In-Reply-To: <$message_id>"
echo "TO: ${from//$'\n'/, }"
-   [[ $subject =~ (RFC|Re: |RE: ) ]] && return
-   echo "CC: ${to//$'\n'/, }"
-   echo "CC: ${cc//$'\n'/, }"
else
add_to "$(git_committer $head_commit)"
fi
-- 
2.7.0.rc3

Re: [PATCH 2/2] dax: fix bdev NULL pointer dereferences

[Jared Hulbert]

On Mon, Feb 1, 2016 at 1:47 PM, Dave Chinner  wrote:
> On Mon, Feb 01, 2016 at 03:51:47PM +0100, Jan Kara wrote:
>> On Sat 30-01-16 00:28:33, Matthew Wilcox wrote:
>> > On Fri, Jan 29, 2016 at 11:28:15AM -0700, Ross Zwisler wrote:
>> > > I guess I need to go off and understand if we can have DAX mappings on 
>> > > such a
>> > > device.  If we can, we may have a problem - we can get the block_device 
>> > > from
>> > > get_block() in I/O path and the various fault paths, but we don't have 
>> > > access
>> > > to get_block() when flushing via dax_writeback_mapping_range().  We avoid
>> > > needing it the normal case by storing the sector results from 
>> > > get_block() in
>> > > the radix tree.
>> >
>> > I think we're doing it wrong by storing the sector in the radix tree; we'd
>> > really need to store both the sector and the bdev which is too much data.
>> >
>> > If we store the PFN of the underlying page instead, we don't have this
>> > problem.  Instead, we have a different problem; of the device going
>> > away under us.  I'm trying to find the code which tears down PTEs when
>> > the device goes away, and I'm not seeing it.  What do we do about user
>> > mappings of the device?
>>
>> So I don't have a strong opinion whether storing PFN or sector is better.
>> Maybe PFN is somewhat more generic but OTOH turning DAX off for special
>> cases like inodes on XFS RT devices would be IMHO fine.
>
> We need to support alternate devices.

Embedded devices trying to use NOR Flash to free up RAM was
historically one of the more prevalent real world uses of the old
filemap_xip.c code although the users never made it to mainline.  So I
spent some time last week trying to figure out how to make a subset of
DAX not depend on CONFIG_BLOCK.  It was a very frustrating and
unfruitful experience.  I discarded my main conclusion as impractical,
but now that I see the difficultly DAX faces in dealing with
"alternate devices" especially some of the crazy stuff btrfs can do, I
wonder if it's not so crazy after all.

Lets stop calling bdev_direct_access() directly from DAX.  Let the
filesystems do it.

Sure we could enable generic_dax_direct_access() helper for the
filesystems that only support single devices to make it easy.  But XFS
and btrfs for example, have to do the work of figuring out what bdev
is required and then calling bdev_direct_access().

My reasoning is that the filesystem knows how to map inodes and
offsets to devices and sectors, no matter how complex that is.  It
would even enable a filesystem to intelligently use a mix of
direct_access and regular block devices down the road.  Of course it
would also make the block-less solution doable.

Good idea?  Stupid idea?

[PATCH] drm/gma500: remove helper function

[Sudip Mukherjee]

We were getting build warning about:
drivers/gpu/drm/gma500/mdfld_dsi_output.c:407:2: warning: initialization
from incompatible pointer type

The callback to dpms was pointing to a helper function which had a
return type of void, whereas the callback should point to a function
which has a return type of int.
On closer look it turned out that we do not need the helper function
since if we call drm_helper_connector_dpms() directly, the first check
that drm_helper_connector_dpms() does is: if (mode == connector->dpms)

Signed-off-by: Sudip Mukherjee 
---
 drivers/gpu/drm/gma500/mdfld_dsi_output.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_output.c 
b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
index d758f4c..907cb51 100644
--- a/drivers/gpu/drm/gma500/mdfld_dsi_output.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
@@ -382,16 +382,6 @@ static int mdfld_dsi_connector_mode_valid(struct 
drm_connector *connector,
return MODE_OK;
 }
 
-static void mdfld_dsi_connector_dpms(struct drm_connector *connector, int mode)
-{
-   if (mode == connector->dpms)
-   return;
-
-   /*first, execute dpms*/
-
-   drm_helper_connector_dpms(connector, mode);
-}
-
 static struct drm_encoder *mdfld_dsi_connector_best_encoder(
struct drm_connector *connector)
 {
@@ -404,7 +394,7 @@ static struct drm_encoder *mdfld_dsi_connector_best_encoder(
 
 /*DSI connector funcs*/
 static const struct drm_connector_funcs mdfld_dsi_connector_funcs = {
-   .dpms = /*drm_helper_connector_dpms*/mdfld_dsi_connector_dpms,
+   .dpms = drm_helper_connector_dpms,
.detect = mdfld_dsi_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.set_property = mdfld_dsi_connector_set_property,
-- 
1.9.1

Re: [PATCH v4 1/9] lib/string: introduce match_string() helper

[Andrew Morton]

On Thu, 28 Jan 2016 15:14:17 +0200 Andy Shevchenko 
 wrote:

> >From time to time we have to match a string in an array. Make a simple helper
> for that purpose.
> 
> ...
>
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -131,6 +131,8 @@ extern void argv_free(char **argv);
>  extern bool sysfs_streq(const char *s1, const char *s2);
>  extern int strtobool(const char *s, bool *res);
>  
> +int match_string(const char * const *array, size_t n, const char *string);
> +
>  #ifdef CONFIG_BINARY_PRINTF
>  int vbin_printf(u32 *bin_buf, size_t size, const char *fmt, va_list args);
>  int bstr_printf(char *buf, size_t size, const char *fmt, const u32 *bin_buf);
> diff --git a/lib/string.c b/lib/string.c
> index 0323c0d..ba01d4f 100644
> --- a/lib/string.c
> +++ b/lib/string.c
> @@ -631,6 +631,32 @@ bool sysfs_streq(const char *s1, const char *s2)
>  EXPORT_SYMBOL(sysfs_streq);
>  
>  /**
> + * match_string - matches given string in an array

I can't say I'm in love with the name, but I guess it will suffice. 
search_string() doesn't seem much better.


> + * @array:   array of strings
> + * @n:   number of strings in the array or -1 for NULL 
> terminated arrays
> + * @string:  string to match with
> + *
> + * Return:
> + * index of a @string in the @array if matches, or %-ENODATA otherwise.
> + */
> +int match_string(const char * const *array, size_t n, const char *string)
> +{
> + int index;
> + const char *item;
> +
> + for (index = 0; index < n; index++) {

So we're taking an int and comparing that with (size_t)-1, relying upon
the compiler promoting the int to an unsigned type because size_t is
unsigned.  It works, but it isn't pretty - there wasn't really much
point in making size have type size_t.


> + item = array[index];
> + if (!item)
> + break;
> + if (!strcmp(item, string))
> + return index;
> + }
> +
> + return -ENODATA;
> +}
> +EXPORT_SYMBOL(match_string);

Re: [PATCH] mmc: dw_mmc: fix num_slots setting

[Shawn Lin]

Hi Jaehoon,

On 2016/2/2 12:42, Jaehoon Chung wrote:

Hi, Shawn.

On 01/22/2016 04:43 PM, Shawn Lin wrote:

This patch make num_slots to 1 if pdata->num_slot is not
defined. Meanwhile, we need to make sure num_slots should
not larger that the supported slots

Signed-off-by: Shawn Lin 
---

  drivers/mmc/host/dw_mmc.c | 16 +---
  1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 7128351..065a8f5 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2949,12 +2949,6 @@ int dw_mci_probe(struct dw_mci *host)
}
}

-   if (host->pdata->num_slots < 1) {
-   dev_err(host->dev,
-   "Platform data must supply num_slots.\n");
-   return -ENODEV;
-   }
-
host->biu_clk = devm_clk_get(host->dev, "biu");
if (IS_ERR(host->biu_clk)) {
dev_dbg(host->dev, "biu clock not available\n");
@@ -3111,7 +3105,15 @@ int dw_mci_probe(struct dw_mci *host)
if (host->pdata->num_slots)
host->num_slots = host->pdata->num_slots;
else
-   host->num_slots = SDMMC_GET_SLOT_NUM(mci_readl(host, HCON));
+   host->num_slots = 1;


If host->nums_slots is set to 1, it assumes that there is one slot.
Then the code in dw_mci_parse_dt() can be removed

 dev_info(dev,
  "num-slots property not found, assuming 1 slot is 
available\n");
 pdata->num_slots = 1;



Good catch. I will respin v2 to move it.

Thanks.


Best Regards,
Jaehoon Chung



+
+   if (host->num_slots < 1 ||
+   host->num_slots > SDMMC_GET_SLOT_NUM(mci_readl(host, HCON))) {
+   dev_err(host->dev,
+   "Platform data must supply correct num_slots.\n");
+   ret = -ENODEV;
+   goto err_clk_ciu;
+   }

/*
 * Enable interrupts for command done, data over, data empty,









--
Best Regards
Shawn Lin

Re: [PATCH v4 3/9] pinctrl: convert to use match_string() helper

[Andrew Morton]

On Thu, 28 Jan 2016 15:14:19 +0200 Andy Shevchenko 
 wrote:

> The new helper returns index of the mathing string in an array. We would use 
> it
> here.
> 
> --- a/drivers/pinctrl/pinmux.c
> +++ b/drivers/pinctrl/pinmux.c
> @@ -334,7 +334,6 @@ int pinmux_map_to_setting(struct pinctrl_map const *map,
>   unsigned num_groups;
>   int ret;
>   const char *group;
> - int i;
>  
>   if (!pmxops) {
>   dev_err(pctldev->dev, "does not support mux function\n");
> @@ -363,19 +362,13 @@ int pinmux_map_to_setting(struct pinctrl_map const *map,
>   return -EINVAL;
>   }
>   if (map->data.mux.group) {
> - bool found = false;
>   group = map->data.mux.group;
> - for (i = 0; i < num_groups; i++) {
> - if (!strcmp(group, groups[i])) {
> - found = true;
> - break;
> - }
> - }
> - if (!found) {
> + ret = match_string(groups, num_groups, group);
> + if (ret < 0) {
>   dev_err(pctldev->dev,
>   "invalid group \"%s\" for function \"%s\"\n",
>   group, map->data.mux.function);
> - return -EINVAL;
> + return ret;

Changes the return value from -EINVAL to -ENODATA.  I'm not reealy
sure what ENODATA means - it seems mostly a networking thing?  People
use it in various places because it kinda sounds like whatever it is
that just went wrong.

But the question is: what will the end user think when this error comes
out of the kernel?  Given that he/she has just tried to misconfigure
the pinctrl system, ENODATA will cause much head-scratching.  EINVAL is
more appropriate?  "You tried to do something invalid".

>   }
>   } else {
>   group = groups[0];
> -- 
> 2.7.0.rc3

Re: [Bug 111541] Race between cat /proc/kallsyms and rmmod

[Rusty Russell]

Rusty Russell  writes:
> And there are other places with the same issue.  This is a more
> complex, but I think worth it (actually two patches, rolled into one
> for testing):

And this one actually works...

diff --git a/include/linux/module.h b/include/linux/module.h
index 4560d8f1545d..2bb0c3085706 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -324,6 +324,12 @@ struct module_layout {
 #define __module_layout_align
 #endif
 
+struct mod_kallsyms {
+   Elf_Sym *symtab;
+   unsigned int num_symtab;
+   char *strtab;
+};
+
 struct module {
enum module_state state;
 
@@ -405,15 +411,10 @@ struct module {
 #endif
 
 #ifdef CONFIG_KALLSYMS
-   /*
-* We keep the symbol and string tables for kallsyms.
-* The core_* fields below are temporary, loader-only (they
-* could really be discarded after module init).
-*/
-   Elf_Sym *symtab, *core_symtab;
-   unsigned int num_symtab, core_num_syms;
-   char *strtab, *core_strtab;
-
+   /* Protected by RCU and/or module_mutex: use rcu_dereference() */
+   struct mod_kallsyms *kallsyms;
+   struct mod_kallsyms core_kallsyms;
+   
/* Section attributes */
struct module_sect_attrs *sect_attrs;
 
diff --git a/kernel/module.c b/kernel/module.c
index 2149f7003e49..4e4d567139f4 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -303,6 +303,9 @@ struct load_info {
struct _ddebug *debug;
unsigned int num_debug;
bool sig_ok;
+#ifdef CONFIG_KALLSYMS
+   unsigned long mod_kallsyms_init_off;
+#endif
struct {
unsigned int sym, str, mod, vers, info, pcpu;
} index;
@@ -2480,10 +2483,21 @@ static void layout_symtab(struct module *mod, struct 
load_info *info)
strsect->sh_flags |= SHF_ALLOC;
strsect->sh_entsize = get_offset(mod, >init_layout.size, strsect,
 info->index.str) | INIT_OFFSET_MASK;
-   mod->init_layout.size = debug_align(mod->init_layout.size);
pr_debug("\t%s\n", info->secstrings + strsect->sh_name);
+
+   /* We'll tack temporary mod_kallsyms on the end. */
+   mod->init_layout.size = ALIGN(mod->init_layout.size,
+ __alignof__(struct mod_kallsyms));
+   info->mod_kallsyms_init_off = mod->init_layout.size;
+   mod->init_layout.size += sizeof(struct mod_kallsyms);
+   mod->init_layout.size = debug_align(mod->init_layout.size);
 }
 
+/*
+ * We use the full symtab and strtab which layout_symtab arranged to
+ * be appended to the init section  Later we switch to the cut-down
+ * core-only one.
+ */
 static void add_kallsyms(struct module *mod, const struct load_info *info)
 {
unsigned int i, ndst;
@@ -2492,29 +2506,34 @@ static void add_kallsyms(struct module *mod, const 
struct load_info *info)
char *s;
Elf_Shdr *symsec = >sechdrs[info->index.sym];
 
-   mod->symtab = (void *)symsec->sh_addr;
-   mod->num_symtab = symsec->sh_size / sizeof(Elf_Sym);
+   /* Set up to point into init section. */
+   mod->kallsyms = mod->init_layout.base + info->mod_kallsyms_init_off;
+
+   mod->kallsyms->symtab = (void *)symsec->sh_addr;
+   mod->kallsyms->num_symtab = symsec->sh_size / sizeof(Elf_Sym);
/* Make sure we get permanent strtab: don't use info->strtab. */
-   mod->strtab = (void *)info->sechdrs[info->index.str].sh_addr;
+   mod->kallsyms->strtab = (void *)info->sechdrs[info->index.str].sh_addr;
 
/* Set types up while we still have access to sections. */
-   for (i = 0; i < mod->num_symtab; i++)
-   mod->symtab[i].st_info = elf_type(>symtab[i], info);
-
-   mod->core_symtab = dst = mod->core_layout.base + info->symoffs;
-   mod->core_strtab = s = mod->core_layout.base + info->stroffs;
-   src = mod->symtab;
-   for (ndst = i = 0; i < mod->num_symtab; i++) {
+   for (i = 0; i < mod->kallsyms->num_symtab; i++)
+   mod->kallsyms->symtab[i].st_info
+   = elf_type(>kallsyms->symtab[i], info);
+
+   /* Now populate the cut down core kallsyms for after init. */
+   mod->core_kallsyms.symtab = dst = mod->core_layout.base + info->symoffs;
+   mod->core_kallsyms.strtab = s = mod->core_layout.base + info->stroffs;
+   src = mod->kallsyms->symtab;
+   for (ndst = i = 0; i < mod->kallsyms->num_symtab; i++) {
if (i == 0 ||
is_core_symbol(src+i, info->sechdrs, info->hdr->e_shnum,
   info->index.pcpu)) {
dst[ndst] = src[i];
-   dst[ndst++].st_name = s - mod->core_strtab;
-   s += strlcpy(s, >strtab[src[i].st_name],
+   dst[ndst++].st_name = s - mod->core_kallsyms.strtab;
+   s += strlcpy(s, >kallsyms->strtab[src[i].st_name],
 KSYM_NAME_LEN) 

Re: [PATCH LINUX 0/6] Second part of xuartps fixes

[Sören Brinkmann]

ping? Any comments?

Thanks,
Sören

On Mon, 2016-01-11 at 17:41:35 -0800, Soren Brinkmann wrote:
> Hi,
> 
> this is the second part of fixes for xuartps that evolved from this
> series: https://lkml.org/lkml/2015/12/26/26.
> 
> This series, obviously, depends on the patches mentioned above. It
> includes several minor improvements and refactoring and the refactoring
> of the IRQ management, which prevents lock ups that could happen when
> RX-related IRQs fired while the receiver was disabled.
> 
>   Thanks,
>   Sören
> 
> Sören Brinkmann (6):
>   tty: xuartps: Move request_irq to after setting up the HW
>   tty: xuartps: Refactor IRQ handling
>   tty: xuartps: Cleanup: Reformat if-else
>   tty: xuartps: Improve sysrq handling
>   tty: xuartps: Remove '_OFFSET' suffix from #defines
>   tty: xuartps: Consolidate TX handling
> 
>  drivers/tty/serial/xilinx_uartps.c | 460 
> +
>  1 file changed, 216 insertions(+), 244 deletions(-)
> 
> -- 
> 2.7.0.3.g497ea1e
> 

Re: [PATCH] kexec: unmap reserved pages for each error-return way

[Andrew Morton]

On Thu, 28 Jan 2016 11:57:22 +0300 Dmitry Safonov  
wrote:

> On 01/28/2016 09:29 AM, Minfei Huang wrote:
> > On 01/27/16 at 02:48pm, Dmitry Safonov wrote:
> >> For allocation of kimage failure or kexec_prepare or load segments
> >> errors there is no need to keep crashkernel memory mapped.
> >> It will affect only s390 as map/unmap hook defined only for it.
> >> As on unmap s390 also changes os_info structure let's check return code
> >> and add info only on success.
> > Hi, Dmitry.
> >
> > Previously, I sent a patch to fix this issue. You can refer it in
> > following link.
> >
> > http://lists.infradead.org/pipermail/kexec/2015-July/013960.html
> Oh, scratch my patch - I'm fine with yours, wanted to do the similar thing
> because it has dazzled me while I was debugging around.

There were a bunch of patches tossed around in that thread but I'm not
sure that anything actually got applied?  Perhaps some resending is
needed.

[PATCH V5] netfilter: h323: avoid potential attack

[Zhouyi Zhou]

I think hackers chould build a malicious h323 packet to overflow
the pointer p which will panic during the memcpy(addr, p, len)
For example, he may fabricate a very large taddr->ipAddress.ip.

In order to avoid this, I add a valid memory reference check in
 get_h2x5_addr functions.

As suggested by Eric, this module is protected by a lock (nf_h323_lock)
so adding a variable h323_buffer_valid_bytes that would contain
the number of valid bytes would not require to change prototypes of
get_h2x5_addr.

Signed-off-by: Zhouyi Zhou 

---
 net/netfilter/nf_conntrack_h323_main.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/net/netfilter/nf_conntrack_h323_main.c 
b/net/netfilter/nf_conntrack_h323_main.c
index 9511af0..21665ec 100644
--- a/net/netfilter/nf_conntrack_h323_main.c
+++ b/net/netfilter/nf_conntrack_h323_main.c
@@ -110,6 +110,25 @@ int (*nat_q931_hook) (struct sk_buff *skb,
 
 static DEFINE_SPINLOCK(nf_h323_lock);
 static char *h323_buffer;
+static int h323_buffer_valid_bytes;
+
+static bool h323_buffer_ref_valid(void *p, int len)
+{
+
+   if ((unsigned long)len > h323_buffer_valid_bytes) {
+   return false; 
+   }
+
+   if (p + len > (void *)h323_buffer + h323_buffer_valid_bytes) {
+   return false;
+   }
+
+   if (p < (void *)h323_buffer) {
+   return false;
+   }
+
+   return true;
+}
 
 static struct nf_conntrack_helper nf_conntrack_helper_h245;
 static struct nf_conntrack_helper nf_conntrack_helper_q931[];
@@ -145,6 +164,7 @@ static int get_tpkt_data(struct sk_buff *skb, unsigned int 
protoff,
 
if (*data == NULL) {/* first TPKT */
/* Get first TPKT pointer */
+   h323_buffer_valid_bytes = tcpdatalen;
tpkt = skb_header_pointer(skb, tcpdataoff, tcpdatalen,
  h323_buffer);
BUG_ON(tpkt == NULL);
@@ -247,6 +267,9 @@ static int get_h245_addr(struct nf_conn *ct, const unsigned 
char *data,
return 0;
}
 
+   if (!h323_buffer_ref_valid((void *)p, len + sizeof(__be16)))
+   return 0;
+
memcpy(addr, p, len);
memset((void *)addr + len, 0, sizeof(*addr) - len);
memcpy(port, p + len, sizeof(__be16));
@@ -669,6 +692,9 @@ int get_h225_addr(struct nf_conn *ct, unsigned char *data,
return 0;
}
 
+   if (!h323_buffer_ref_valid((void *)p, len + sizeof(__be16)))
+   return 0;
+
memcpy(addr, p, len);
memset((void *)addr + len, 0, sizeof(*addr) - len);
memcpy(port, p + len, sizeof(__be16));
@@ -1248,6 +1274,7 @@ static unsigned char *get_udp_data(struct sk_buff *skb, 
unsigned int protoff,
if (dataoff >= skb->len)
return NULL;
*datalen = skb->len - dataoff;
+   h323_buffer_valid_bytes = *datalen;
return skb_header_pointer(skb, dataoff, *datalen, h323_buffer);
 }
 
-- 
1.9.1

Re: linux-4.5-rc1 TI pandboard-es wifi wlcore locks and reset

[Ross Green]

I have not tried a bisect yet, but I can confirm 4.4 and 4.4.1 work.
4.5-rc1 and 4.5-rc2 don't work.

It appears the tx to device times out and then just goes into reset of
the device to try and recover. A tx to device seems not to work.
although somehow firmware has been loaded to the device. So some types
of tx might work. Strange!

There were quite a few omap and omap4 plus patches that have come
along recently. so the culprit is in there somewhere. These machines
have been rock solid for quite some time.

If I get time, this evening, I'll see if I can give a bisect a try.

Regards,

Ross Green

On Tue, Feb 2, 2016 at 3:34 PM, Sebastian Reichel  wrote:
> Hi,
>
> On Mon, Feb 01, 2016 at 11:38:38PM +1100, Ross Green wrote:
>> On Mon, Jan 25, 2016 at 11:47 PM, Ross Green  wrote:
>> > Just tried the new kernel release on faithful pandaboard es with the
>> > new 4.5-rc1 release.
>> >
>> > There is a problem with the wifi modules once the modules are loaded.
>> > Looks like the wifi firmware gets loaded put no response after that
>> > causing recovery action.
>> >
>> > the kernel 4.4 works quite happily with this board.
>> >
>> > Here is a dmesg dump in the attachment.
>> >
>> > Anyone have any ideas here?
>>
>> Just updated to the latest linux-4.5-rc2 and same result as rc1.
>>
>> The wireless module loads firmware and then stalls causing a reset of
>> the device and then continues to go through a stall and reset cycle.
>>
>> please find enclosed a copy of the dmesg output.
>>
>> Is there anyone else testing a pandaboard with linux-4.5-rc2?
>>
>> Just for completeness also tested the latest linux-4.4.1 kernel and
>> found no problems with the wireless modules.
>
> I can see the same problem with Nokia N950 (which uses spi connected
> wl1271). v4.4 + wl12xx spi DT patches from Uri Mashiach worked, v4.5
>  + the same patches does not work. I currently suspect 133b7326e960
> or 3719c17e1816 to be the culprit. I have not yet verified it, though.
>
> Have you tried to bisect the problem?
>
> -- Sebastian

Re: [RFC PATCH] mm: CONFIG_NR_ZONES_EXTENDED

[Andrew Morton]

On Wed, 27 Jan 2016 22:19:14 -0800 Dan Williams  
wrote:

> ZONE_DEVICE (merged in 4.3) and ZONE_CMA (proposed) are examples of new
> mm zones that are bumping up against the current maximum limit of 4
> zones, i.e. 2 bits in page->flags.  When adding a zone this equation
> still needs to be satisified:
> 
> SECTIONS_WIDTH + ZONES_WIDTH + NODES_SHIFT + LAST_CPUPID_SHIFT
> <= BITS_PER_LONG - NR_PAGEFLAGS
> 
> ZONE_DEVICE currently tries to satisfy this equation by requiring that
> ZONE_DMA be disabled, but this is untenable given generic kernels want
> to support ZONE_DEVICE and ZONE_DMA simultaneously.  ZONE_CMA would like
> to increase the amount of memory covered per section, but that limits
> the minimum granularity at which consecutive memory ranges can be added
> via devm_memremap_pages().
> 
> The trade-off of what is acceptable to sacrifice depends heavily on the
> platform.  For example, ZONE_CMA is targeted for 32-bit platforms where
> page->flags is constrained, but those platforms likely do not care about
> the minimum granularity of memory hotplug.  A big iron machine with 1024
> numa nodes can likely sacrifice ZONE_DMA where a general purpose
> distribution kernel can not.
> 
> CONFIG_NR_ZONES_EXTENDED is a configuration symbol that gets selected
> when the number of configured zones exceeds 4.  It documents the
> configuration symbols and definitions that get modified when ZONES_WIDTH
> is greater than 2.
> 
> For now, it steals a bit from NODES_SHIFT.  Later on it can be used to
> document the definitions that get modified when a 32-bit configuration
> wants more zone bits.

So if you want ZONE_DMA, you're limited to 512 NUMA nodes?

That seems reasonable.

> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1409,8 +1409,10 @@ config NUMA_EMU
>  
>  config NODES_SHIFT
>   int "Maximum NUMA Nodes (as a power of 2)" if !MAXSMP
> - range 1 10
> - default "10" if MAXSMP
> + range 1 10 if !NR_ZONES_EXTENDED
> + range 1 9 if NR_ZONES_EXTENDED
> + default "10" if MAXSMP && !NR_ZONES_EXTENDED
> + default "9" if MAXSMP && NR_ZONES_EXTENDED
>   default "6" if X86_64
>   default "3"
>   depends on NEED_MULTIPLE_NODES
> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> index 28ad5f6494b0..5979c2c80140 100644
> --- a/include/linux/gfp.h
> +++ b/include/linux/gfp.h
> @@ -329,22 +329,29 @@ static inline bool gfpflags_allow_blocking(const gfp_t 
> gfp_flags)
>   *   0xe=> BAD (MOVABLE+DMA32+HIGHMEM)
>   *   0xf=> BAD (MOVABLE+DMA32+HIGHMEM+DMA)
>   *
> - * ZONES_SHIFT must be <= 2 on 32 bit platforms.
> + * GFP_ZONES_SHIFT must be <= 2 on 32 bit platforms.
>   */
>  
> -#if 16 * ZONES_SHIFT > BITS_PER_LONG
> -#error ZONES_SHIFT too large to create GFP_ZONE_TABLE integer
> +#if defined(CONFIG_ZONE_DEVICE) && (MAX_NR_ZONES-1) <= 4
> +/* ZONE_DEVICE is not a valid GFP zone specifier */
> +#define GFP_ZONES_SHIFT 2
> +#else
> +#define GFP_ZONES_SHIFT ZONES_SHIFT
> +#endif
> +
> +#if 16 * GFP_ZONES_SHIFT > BITS_PER_LONG
> +#error GFP_ZONES_SHIFT too large to create GFP_ZONE_TABLE integer
>  #endif
>  
>  #define GFP_ZONE_TABLE ( \
> - (ZONE_NORMAL << 0 * ZONES_SHIFT)  \
> - | (OPT_ZONE_DMA << ___GFP_DMA * ZONES_SHIFT)  \
> - | (OPT_ZONE_HIGHMEM << ___GFP_HIGHMEM * ZONES_SHIFT)  \
> - | (OPT_ZONE_DMA32 << ___GFP_DMA32 * ZONES_SHIFT)  \
> - | (ZONE_NORMAL << ___GFP_MOVABLE * ZONES_SHIFT)   \
> - | (OPT_ZONE_DMA << (___GFP_MOVABLE | ___GFP_DMA) * ZONES_SHIFT)   \
> - | (ZONE_MOVABLE << (___GFP_MOVABLE | ___GFP_HIGHMEM) * ZONES_SHIFT)   \
> - | (OPT_ZONE_DMA32 << (___GFP_MOVABLE | ___GFP_DMA32) * ZONES_SHIFT)   \
> + (ZONE_NORMAL << 0 * GFP_ZONES_SHIFT)
> \
> + | (OPT_ZONE_DMA << ___GFP_DMA * GFP_ZONES_SHIFT)
> \
> + | (OPT_ZONE_HIGHMEM << ___GFP_HIGHMEM * GFP_ZONES_SHIFT)
> \
> + | (OPT_ZONE_DMA32 << ___GFP_DMA32 * GFP_ZONES_SHIFT)
> \
> + | (ZONE_NORMAL << ___GFP_MOVABLE * GFP_ZONES_SHIFT) 
> \
> + | (OPT_ZONE_DMA << (___GFP_MOVABLE | ___GFP_DMA) * GFP_ZONES_SHIFT) 
> \
> + | (ZONE_MOVABLE << (___GFP_MOVABLE | ___GFP_HIGHMEM) * GFP_ZONES_SHIFT) 
> \
> + | (OPT_ZONE_DMA32 << (___GFP_MOVABLE | ___GFP_DMA32) * GFP_ZONES_SHIFT) 
> \
>  )

Geeze.  Congrats on decrypting this stuff.  I hope.  Do you think it's
possible to comprehensibly document it all for the next poor soul who
ventures into it?

[linux-review:Bean-Huo/Add-a-bakvol-module-in-UBI-layer-for-MLC-paired-page-power-loss-issue/20160202-104450] 2078d3920abf1d89be7eaf087100b4482dd532dc BUILD DONE

[kbuild test robot]

https://github.com/0day-ci/linux  
Bean-Huo/Add-a-bakvol-module-in-UBI-layer-for-MLC-paired-page-power-loss-issue/20160202-104450
2078d3920abf1d89be7eaf087100b4482dd532dc  drivers:mtd:ubi: Kconfig Makefile

drivers/mtd/mtdpart.c:213:26: error: implicit declaration of function 'PART' 
[-Werror=implicit-function-declaration]
drivers/mtd/mtdpart.c:213:26: warning: initialization makes pointer from 
integer without a cast
drivers/mtd/mtdpart.c:213:26: warning: initialization makes pointer from 
integer without a cast [enabled by default]
drivers/mtd/mtdpart.c:213:26: warning: initialization makes pointer from 
integer without a cast [-Wint-conversion]
drivers/mtd/mtdpart.c:213:9: error: implicit declaration of function 'PART'
drivers/mtd/mtdpart.c:213:9: error: implicit declaration of function 'PART' 
[-Werror=implicit-function-declaration]
drivers/mtd/mtdpart.c:213: error: implicit declaration of function 'PART'
drivers/mtd/mtdpart.c:213: warning: initialization makes pointer from integer 
without a cast
drivers/mtd/nand/nand_base.c:2463:12: error: too few arguments to function 
'chip->ecc.write_page_raw'
drivers/mtd/nand/nand_base.c:2463:50: sparse: not enough arguments for function 
write_page_raw
drivers/mtd/nand/nand_base.c:2464:8: error: too few arguments to function 
'chip->ecc.write_page_raw'
drivers/mtd/nand/nand_base.c:2464: error: too few arguments to function 
'chip->ecc.write_page_raw'
drivers/mtd/nand/nand_base.c:2466:12: error: too few arguments to function 
'chip->ecc.write_subpage'
drivers/mtd/nand/nand_base.c:2466:49: sparse: not enough arguments for function 
write_subpage
drivers/mtd/nand/nand_base.c:2467:8: error: too few arguments to function 
'chip->ecc.write_subpage'
drivers/mtd/nand/nand_base.c:2467: error: too few arguments to function 
'chip->ecc.write_subpage'
drivers/mtd/nand/nand_base.c:2469:12: error: too few arguments to function 
'chip->ecc.write_page'
drivers/mtd/nand/nand_base.c:2469:3: error: too few arguments to function 
'chip->ecc.write_page'
drivers/mtd/nand/nand_base.c:2469:46: sparse: not enough arguments for function 
write_page
drivers/mtd/nand/nand_base.c:2469: error: too few arguments to function 
'chip->ecc.write_page'
drivers/mtd/ubi/bakvol.c:1211:1-15: ERROR: reference preceded by free on line 
1210
drivers/mtd/ubi/bakvol.c:651:3: note: in expansion of macro 'ubi_err'
drivers/mtd/ubi/bakvol.c:862:17-28: ERROR: ubi -> bkblk_tbl is NULL but 
dereferenced.
drivers/mtd/ubi/eba.c:607:8: error: too few arguments to function 
'ubi_io_write_data'
drivers/mtd/ubi/fastmap.c:1315:9: error: too few arguments to function 
'ubi_io_write'
drivers/mtd/ubi/io.c:235:5: error: conflicting types for 'ubi_io_write'
drivers/mtd/ubi/io.c:242:6: warning: unused variable 'skip' [-Wunused-variable]
drivers/mtd/ubi/io.c:242: warning: unused variable 'skip'
drivers/mtd/ubi/io.c:321:5: note: in expansion of macro 'ubi_err'
drivers/mtd/ubi/io.c:321:5: warning: format '%d' expects argument of type 
'int', but argument 4 has type 'size_t' [-Wformat=]
drivers/mtd/ubi/io.c:321:5: warning: format '%d' expects argument of type 
'int', but argument 4 has type 'size_t' [-Wformat]
drivers/mtd/ubi/ubi.h:59:32: note: in expansion of macro 'pr_err'
include/linux/mtd/nand.h:739: warning: No description found for parameter 
'write_plane_page'

Error ids grouped by kconfigs:

recent_errors
├── alpha-allyesconfig
│   ├── drivers-mtd-mtdpart.c:error:implicit-declaration-of-function-PART
│   ├── 
drivers-mtd-mtdpart.c:warning:initialization-makes-pointer-from-integer-without-a-cast
│   ├── 
drivers-mtd-nand-nand_base.c:error:too-few-arguments-to-function-chip-ecc.write_page
│   ├── 
drivers-mtd-nand-nand_base.c:error:too-few-arguments-to-function-chip-ecc.write_page_raw
│   ├── 
drivers-mtd-nand-nand_base.c:error:too-few-arguments-to-function-chip-ecc.write_subpage
│   └── 
drivers-mtd-ubi-io.c:warning:format-d-expects-argument-of-type-int-but-argument-has-type-size_t
├── arm-at91_dt_defconfig
│   ├── drivers-mtd-mtdpart.c:error:implicit-declaration-of-function-PART
│   ├── 
drivers-mtd-mtdpart.c:warning:initialization-makes-pointer-from-integer-without-a-cast
│   ├── 
drivers-mtd-nand-nand_base.c:error:too-few-arguments-to-function-chip-ecc.write_page
│   ├── 
drivers-mtd-nand-nand_base.c:error:too-few-arguments-to-function-chip-ecc.write_page_raw
│   └── 
drivers-mtd-nand-nand_base.c:error:too-few-arguments-to-function-chip-ecc.write_subpage
├── arm-efm32_defconfig
│   ├── drivers-mtd-mtdpart.c:error:implicit-declaration-of-function-PART
│   └── 
drivers-mtd-mtdpart.c:warning:initialization-makes-pointer-from-integer-without-a-cast
├── arm-ep93xx_defconfig
│   ├── drivers-mtd-mtdpart.c:error:implicit-declaration-of-function-PART
│   ├── 
drivers-mtd-mtdpart.c:warning:initialization-makes-pointer-from-integer-without-a-cast
│   ├── 
drivers-mtd-nand-nand_base.c:error:too-few-arguments-to-function-chip-ecc.write_page
│   ├── 

Re: [PATCH v1 1/8] kasan: Change the behavior of kmalloc_large_oob_right test

[Andrew Morton]

On Wed, 27 Jan 2016 19:25:06 +0100 Alexander Potapenko  
wrote:

> depending on which allocator (SLAB or SLUB) is being used
> 
> ...
>
> --- a/lib/test_kasan.c
> +++ b/lib/test_kasan.c
> @@ -68,7 +68,22 @@ static noinline void __init kmalloc_node_oob_right(void)
>  static noinline void __init kmalloc_large_oob_right(void)
>  {
>   char *ptr;
> - size_t size = KMALLOC_MAX_CACHE_SIZE + 10;
> + size_t size;
> +
> + if (KMALLOC_MAX_CACHE_SIZE == KMALLOC_MAX_SIZE) {
> + /*
> +  * We're using the SLAB allocator. Allocate a chunk that fits
> +  * into a slab.
> +  */
> + size = KMALLOC_MAX_CACHE_SIZE - 256;
> + } else {
> + /*
> +  * KMALLOC_MAX_SIZE > KMALLOC_MAX_CACHE_SIZE.
> +  * We're using the SLUB allocator. Allocate a chunk that does
> +  * not fit into a slab to trigger the page allocator.
> +  */
> + size = KMALLOC_MAX_CACHE_SIZE + 10;
> + }

This seems a weird way of working out whether we're using SLAB or SLUB.

Can't we use, umm, #ifdef CONFIG_SLAB?  If not that then let's cook up
something standardized rather than a weird just-happens-to-work like
this.

Re: BUG caused by "Use new drm_fb_helper functions" series

[Archit Taneja]

Hi Peter,

On 02/02/2016 02:07 AM, Peter Hurley wrote:

Hi Archit,

Just booting 4.4-rc5+, I got this splat [1]
At first glance, this appears to be a simple fix.


Thanks for sharing this.



However, I'm concerned that fbcon functions, which may be called with
interrupts disabled, are now hooked up to fbdev functions which may assume
interrupts are not disabled (as is the case with cfb_imageblit()).


In the case when CONFIG_FB is enabled, drm_fb_helper_cfb_imageblit
helper simply wraps around cfg_imageblit, so I don't see how we'd have
any difference in behaviour.



For example, in the splat below, it's a simple fix to make the splat go
away with GFP_ATOMIC allocation. However, the following fence wait is _never_
going to trigger with interrupts disabled on UP.

FWIW, I've been running almost exclusively debug kernel builds so I'm not
sure why this hasn't triggered many times before, but it hasn't.


We could revert the patch
"drm/nouveau: Use new drm_fb_helper functions" and see if we still hit this
issue.

Thanks,
Archit


Regards,
Peter Hurley


[1] BUG splat

[   37.438494] BUG: sleeping function called from invalid context at 
/home/peter/src/kernels/mainline/mm/slub.c:1287
[   37.438495] in_atomic(): 1, irqs_disabled(): 1, pid: 2276, name: auditd
[   37.438497] 1 lock held by auditd/2276:
[   37.438507]  #0:  (audit_cmd_mutex){+.+.+.}, at: [] 
audit_receive+0x1f/0xa0
[   37.438507] irq event stamp: 1689
[   37.438511] hardirqs last  enabled at (1689): [] 
vprintk_emit+0x236/0x620
[   37.438513] hardirqs last disabled at (1688): [] 
vprintk_emit+0xd4/0x620
[   37.438518] softirqs last  enabled at (1652): [] 
netlink_poll+0x138/0x1c0
[   37.438520] softirqs last disabled at (1650): [] 
netlink_poll+0xf7/0x1c0
[   37.438522] CPU: 7 PID: 2276 Comm: auditd Not tainted 
4.4.0-rc5+wip-xeon+debug #rc5+wip
[   37.438523] Hardware name: Dell Inc. Precision WorkStation T5400  /0RW203, 
BIOS A11 04/30/2012
[   37.438526]  81ce5cc8 8802a87c3590 813fb6c5 
8802ac768000
[   37.438528]  8802a87c35b8 810a6fb9 81ce5cc8 
0507
[   37.438530]   8802a87c35e0 810a70b9 
024080c0
[   37.438531] Call Trace:
[   37.438535]  [] dump_stack+0x4e/0x79
[   37.438538]  [] ___might_sleep+0x149/0x200
[   37.438540]  [] __might_sleep+0x49/0x80
[   37.438544]  [] kmem_cache_alloc_trace+0x20d/0x2e0
[   37.438600]  [] ? nouveau_fence_new+0x3b/0x90 [nouveau]
[   37.438624]  [] nouveau_fence_new+0x3b/0x90 [nouveau]
[   37.438649]  [] nouveau_channel_idle+0x42/0xb0 [nouveau]
[   37.438673]  [] nouveau_fbcon_sync+0x7f/0xb0 [nouveau]
[   37.438677]  [] cfb_imageblit+0x9a/0x4d0
[   37.438681]  [] ? trace_hardirqs_off_caller+0x1f/0xc0
[   37.438693]  [] drm_fb_helper_cfb_imageblit+0xe/0x10 
[drm_kms_helper]
[   37.438717]  [] nouveau_fbcon_imageblit+0x51/0xd0 [nouveau]
[   37.438719]  [] bit_putcs+0x2dc/0x530
[   37.438721]  [] ? trace_hardirqs_off+0xd/0x10
[   37.438725]  [] ? get_color.isra.15+0x34/0x130
[   37.438727]  [] fbcon_putcs+0x128/0x160
[   37.438728]  [] ? bit_cursor+0x5e0/0x5e0
[   37.438730]  [] fbcon_redraw.isra.25+0x16b/0x1d0
[   37.438731]  [] fbcon_scroll+0x1ea/0xce0
[   37.438734]  [] scrup+0x14a/0x160
[   37.438736]  [] lf+0x80/0x90
[   37.438737]  [] vt_console_print+0x2a7/0x3e0
[   37.438739]  [] 
call_console_drivers.constprop.24+0x144/0x1d0
[   37.438741]  [] console_unlock+0x463/0x540
[   37.438742]  [] vprintk_emit+0x35a/0x620
[   37.438744]  [] vprintk_default+0x29/0x40
[   37.438748]  [] printk+0x4d/0x4f
[   37.438750]  [] audit_printk_skb+0x62/0x70
[   37.438751]  [] audit_log_end+0x1d4/0x2d0
[   37.438752]  [] ? audit_log_end+0x30/0x2d0
[   37.438754]  [] audit_log_config_change+0x89/0xa0
[   37.438756]  [] audit_receive_msg+0xa5a/0xbb0
[   37.438759]  [] ? mutex_lock_nested+0x2ed/0x450
[   37.438761]  [] ? audit_receive+0x1f/0xa0
[   37.438762]  [] ? audit_receive+0x1f/0xa0
[   37.438764]  [] audit_receive+0x52/0xa0
[   37.438766]  [] netlink_unicast+0xf2/0x1c0
[   37.438767]  [] netlink_sendmsg+0x3e7/0x620
[   37.438771]  [] sock_sendmsg+0x38/0x50
[   37.438772]  [] SYSC_sendto+0xf6/0x170
[   37.438775]  [] ? context_tracking_exit+0x1d/0x30
[   37.438778]  [] ? enter_from_user_mode+0x1f/0x50
[   37.438780]  [] ? syscall_trace_enter_phase1+0xcb/0x130
[   37.438781]  [] ? trace_hardirqs_on_thunk+0x17/0x19
[   37.438784]  [] SyS_sendto+0xe/0x10
[   37.438786]  [] entry_SYSCALL_64_fastpath+0x16/0x7a



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

Re: [RFC][PATCH] mips: Fix arch_spin_unlock()

[Boqun Feng]

Hi Paul,

On Mon, Feb 01, 2016 at 07:54:58PM -0800, Paul E. McKenney wrote:
> On Mon, Feb 01, 2016 at 01:56:22PM +, Will Deacon wrote:
> > On Fri, Jan 29, 2016 at 02:22:53AM -0800, Paul E. McKenney wrote:
> > > On Fri, Jan 29, 2016 at 09:59:59AM +, Will Deacon wrote:
> > > > On Thu, Jan 28, 2016 at 02:31:31PM -0800, Paul E. McKenney wrote:
> > > 
> > > [ . . . ]
> > > 
> > > > > For Linux in general, this is a question: How strict do we want to be
> > > > > about matching the type of write with the corresponding read?  My
> > > > > default approach is to initially be quite strict and loosen as needed.
> > > > > Here "quite strict" might mean requiring an rcu_assign_pointer() for
> > > > > the write and rcu_dereference() for the read, as opposed to (say)
> > > > > ACCESS_ONCE() for the read.  (I am guessing that this would be too
> > > > > tight, but it makes a good example.)
> > > > > 
> > > > > Thoughts?
> > > > 
> > > > That sounds broadly sensible to me and allows rcu_assign_pointer and
> > > > rcu_dereference to be used as drop-in replacements for release/acquire
> > > > where local transitivity isn't required. However, I don't think we can
> > > > rule out READ_ONCE/WRITE_ONCE interactions as they seem to be used
> > > > already in things like the osq_lock (albeit without the address
> > > > dependency).
> > > 
> > > Agreed.  So in the most strict case that I can imagine anyone putting
> > > up with, we have the following pairings:
> > 
> > I think we can group these up:
> > 
> > Locally transitive:
> > 
> > > o smp_store_release() -> smp_load_acquire() (locally transitive)
> > 
> > Locally transitive chain termination:
> > 
> > (i.e. these can't be used to extend a chain)
> 
> Agreed.
> 
> > > o smp_store_release() -> lockless_dereference() (???)
> > > o rcu_assign_pointer() -> rcu_dereference()
> > > o smp_store_release() -> READ_ONCE(); if

Just want to make sure, this one is actually:

o   smp_store_release() -> READ_ONCE(); if ;

right? Because control dependency only orders READ->WRITE.

If so, do we also need to take the following pairing into consideration?

o   smp_store_release() -> READ_ONCE(); if ;smp_rmb(); 

> 
> I am OK with the first and last, but I believe that the middle one
> has real use cases.  So the rcu_assign_pointer() -> rcu_dereference()
> case needs to be locally transitive.
> 

Hmm... I don't think we should differ rcu_dereference() and
lockless_dereference(). One reason: list_for_each_entry_rcu() are using
lockless_dereference() right now, which means we used to think
rcu_dereference() and lockless_dereference() are interchangeable, right?

Besides, Will, what's the reason of having a locally transitive chain
termination? Because on some architectures RELEASE->DEPENDENCY pairs may
not be locally transitive?

Regards,
Boqun

> > Globally transitive:
> > 
> > > o smp_mb(); WRITE_ONCE() -> READ_ONCE(); (globally transitive)
> > > o synchronize_rcu(); WRITE_ONCE() -> READ_ONCE(); (globally transitive)
> > 
> > RCU:
> > 
> > > o synchronize_rcu(); WRITE_ONCE() -> rcu_read_lock(); READ_ONCE()
> > >   (strange and wonderful properties)
> 
> Agreed.
> 
> > > Seem reasonable, or am I missing some?
> > 
> > Looks alright to me.
> 
> So I have some litmus tests to generate.  ;-)
> 
>   Thnax, Paul
> 


signature.asc
Description: PGP signature

Re: linux-next: manual merge of the btrfs-kdave tree with Linus' tree

[Chandan Rajendra]

On Tuesday 02 Feb 2016 10:22:16 Stephen Rothwell wrote:
> Hi David,
> 
> Today's linux-next merge of the btrfs-kdave tree got a conflict in:
> 
>   fs/btrfs/file.c
> 
> between commit:
> 
>   5955102c9984 ("wrappers for ->i_mutex access")
> 
> from Linus' tree and commit:
> 
>   9703fefe0b13 ("Btrfs: fallocate: Work with sectorsized blocks")
> 
> from the btrfs-kdave tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

The fixes look good to me. Thanks for doing this.

-- 
chandan

Re: [PATCH v4 1/3] mailbox: Add support for APM X-Gene platform mailbox driver

[Jassi Brar]

On Tue, Feb 2, 2016 at 1:08 AM, Duc Dang  wrote:
> Hi Jassi,
>
> On Fri, Jan 15, 2016 at 6:57 PM, Duc Dang  wrote:
>> X-Gene mailbox controller provides 8 mailbox channels, with
>> each channel has a dedicated interrupt line.
>
> Did you have a chance to look into this version 4 of my mail-box patch?
>
Seems ok, please just fix the "section mismatch" warnings reported by
the build-bot.

Thanks

Re: PCI device driver broken between 4.2 and 4.3

[Олег Мороз]

it looks much better with pci=routeirq

[  100.896723] *Before pci_enable_device IRQ 20* 
[  100.896735] *After pci_enable_device IRQ 20* 
[  100.896745] *Before pci_enable_device IRQ 21* 
[  100.896752] *After pci_enable_device IRQ 21*


On Monday 01 of February 2016 15:08:23 Bjorn Helgaas wrote:
> [+cc Yinghai]
> 
> On Mon, Feb 01, 2016 at 08:18:35AM +0300, Олег Мороз wrote:
> > Okay. I've started from driver level printk
> > results are:
> > 
> > On 4.2
> > 
> > [414006.575989] Before pci_enable_device IRQ 20
> > 
> > [414006.575991] After pci_enable_device IRQ 20
> > 
> > [414006.575997] Before pci_enable_device IRQ 21
> > 
> > [414006.575999] After pci_enable_device IRQ 21
> > 
> > on 4.3
> > 
> > [  114.862289] Before pci_enable_device IRQ 5
> > 
> > [  114.862303] After pci_enable_device IRQ 5
> > 
> > [  114.862316] Before pci_enable_device IRQ 5
> > 
> > [  114.862326] After pci_enable_device IRQ 5
> > 
> > I've got two cards, because of that pci_enable_device() calls twice.
> 
> Did you try booting with pci=routeirq as Yinghai suggested?  That's
> not a fix, but if it does make things work, it may give us an idea for
> how to fix it correctly.
> 
> > On Friday 29 of January 2016 10:31:59 Bjorn Helgaas wrote:
> > > On Thu, Jan 28, 2016 at 10:28:14PM +0300, Мороз Олег wrote:
> > > > What i need to print out at first order?
> > > 
> > > Jiang, can you chime in here?
> > > 
> > > 991de2e59090 is related to IRQs, so I'd start by printing dev->irq in
> > > your
> > > driver before and after you call pci_enable_device().  Add some printks
> > > in
> > > pcibios_alloc_irq() and pcibios_enable_device() just to confirm that we
> > > got
> > > 
> > > there and when, e.g., add lines like this:
> > >   dev_info(>dev, "%s\n", __func__);
> > > 
> > > Bjorn
> > > 
> > > > 27 янв. 2016 г. 16:22 пользователь Bjorn Helgaas 
> > 
> > написал:
> > > > > On Wed, Jan 27, 2016 at 12:38:06PM +0300, Мороз Олег wrote:
> > > > > > Also, my drive has no
> > > > > > 
> > > > > > pcibios_enable_device()
> > > > > > pcibios_alloc_irq()
> > > > > > 
> > > > > > calls.
> > > > > 
> > > > > Those are internal interfaces used by the PCI core.  Drivers
> > > > > shouldn't
> > > > > call them directly.  Drivers normally call pci_enable_device(), and
> > > > > those internal interfaces are used in that path.
> > > > > 
> > > > > > 26.01.2016 22:05, Олег Мороз пишет:
> > > > > > >I confirmed it works in
> > > > > > >
> > > > > > >890e4847587f
> > > > > > >
> > > > > > >and do not works in
> > > > > > >
> > > > > > >991de2e59090
> > > > > > >
> > > > > > >26.01.2016 18:32, Bjorn Helgaas пишет:
> > > > > > >>[+cc Jiang]
> > > > > > >>
> > > > > > >>On Mon, Jan 25, 2016 at 03:52:51PM -0600, Bjorn Helgaas wrote:
> > > > > > >>>Hi Олег,
> > > > > > >>>
> > > > > > >>>On Sun, Jan 24, 2016 at 04:50:08PM +0300, Олег Мороз wrote:
> > > > > > Okay. I've sent logs (dmesg and lspci) from both 4.2 and 4.3
> > > > > > to bugzilla
> > > > > > >>>
> > > > > > >>>I don't see anything wrong in either log.  Both v4.2 and v4.3
> > > > > > >>>enumerate the device the same way, and the driver seems to
> > > > > > >>>claim it
> > > > > > >>>
> > > > > > >>>the same way:
> > > > > > >>>   pci :0d:00.0: [10b5:9030] type 00 class 0x078000
> > > > > > >>>   pci :0d:00.0: reg 0x14: [io  0x2100-0x217f]
> > > > > > >>>   pci :0d:00.0: reg 0x18: [io  0x2380-0x239f]
> > > > > > >>>   pci :0d:00.0: PME# supported from D0 D3hot
> > > > > > >>>   pci :0d:01.0: [10b5:9030] type 00 class 0x078000
> > > > > > >>>   pci :0d:01.0: reg 0x14: [io  0x2180-0x21ff]
> > > > > > >>>   pci :0d:01.0: reg 0x18: [io  0x23a0-0x23bf]
> > > > > > >>>   pci :0d:01.0: PME# supported from D0 D3hot
> > > > > > >>>   pci :0d:02.0: [10b5:9030] type 00 class 0x078000
> > > > > > >>>   pci :0d:02.0: reg 0x14: [io  0x2200-0x227f]
> > > > > > >>>   pci :0d:02.0: reg 0x18: [io  0x2280-0x22ff]
> > > > > > >>>   pci :0d:02.0: reg 0x1c: [io  0x2300-0x237f]
> > > > > > >>>   pci :0d:02.0: PME# supported from D0 D3hot
> > > > > > >>>   
> > > > > > >>>   sja1000_plx_pci :0d:02.0: Detected "Eclus CAN-200-PCI"
> > > > > > >>>
> > > > > > >>>card at slot #2
> > > > > > >>>
> > > > > > >>>   sja1000_plx_pci :0d:02.0: Channel #1 at
> > > > > > >>>
> > > > > > >>>0x00012280, irq 22 registered as can0
> > > > > > >>>
> > > > > > >>>   sja1000_plx_pci :0d:02.0: Channel #2 at
> > > > > > >>>
> > > > > > >>>0x00012300, irq 22 registered as can1
> > > > > > >>>
> > > > > > >>>   sja1000_plx_pci :0d:02.0 can0: setting BTR0=0x03
> > > > > > >>>   BTR1=0x37
> > > > > > >>>
> > > > > > >>>One option is always to bisect between v4.2 and v4.3 to see
> > > > > > >>>which
> > > > > > >>>commit made it stop working.  See
> > > > > > >>>https://git-scm.com/docs/git-bisect
> > > > > > >>
> > > > > > >>Jiang, Олег bisected this to 991de2e59090 ("PCI, x86: Implement
> > > > > > >>pcibios_alloc_irq() and pcibios_free_irq()").
> > > > > > 

Re: [Bug 111541] Race between cat /proc/kallsyms and rmmod

[Rusty Russell]

Peter Zijlstra  writes:
> Adding lkml to Cc so that there is an actual email record of this.
>
> (I could for example not reply to Masami's later entries).
>
> On Mon, Feb 01, 2016 at 12:02:01PM +1030, Rusty Russell wrote:
>> > https://bugzilla.kernel.org/show_bug.cgi?id=111541
>
>> Unfortunately, that would also create a DoS where anyone can stop module
>> loading.
>
>> diff --git a/kernel/module.c b/kernel/module.c
>> index 8358f4697c0c..9f2de09b6d8c 100644
>> --- a/kernel/module.c
>> +++ b/kernel/module.c
>> @@ -1992,6 +1992,9 @@ static void free_module(struct module *mod)
>>  mod->state = MODULE_STATE_UNFORMED;
>>  mutex_unlock(_mutex);
>>  
>> +/* kallsyms walks list without mutex; make sure they see UNFORMED */
>> +synchronize_sched();
>> +
>>  /* Remove dynamic debug info */
>>  ddebug_remove_module(mod->name);
>
> So it all depends on when this mod->symtab stuff gets freed, and I could
> not actually find this.

You're right.  The symtab is part of the module core, so it's freed
after the synchronize_sched() below anyway:

mutex_lock(_mutex);
/* Unlink carefully: kallsyms could be walking list. */
list_del_rcu(>list);
mod_tree_remove(mod);
/* Remove this module from bug list, this uses list_del_rcu */
module_bug_cleanup(mod);
/* Wait for RCU-sched synchronizing before releasing mod->list and 
buglist. */
synchronize_sched();
mutex_unlock(_mutex);

/* This may be empty, but that's OK */
disable_ro_nx(>init_layout);
module_arch_freeing_init(mod);
module_memfree(mod->init_layout.base);
kfree(mod->args);
percpu_modfree(mod);

/* Free lock-classes; relies on the preceding sync_rcu(). */
lockdep_free_key_range(mod->core_layout.base, mod->core_layout.size);

/* Finally, free the core (containing the module structure) */
disable_ro_nx(>core_layout);
==> module_memfree(mod->core_layout.base);

I finally reproduced it.

For kallsyms, there are two copies of the symtab: a complete copy
tacked onto the end of the init part, and a filtered core-symbols-only
copy in the core part.

We reassign the symtab pointer and size halfway through
do_init_module():

#ifdef CONFIG_KALLSYMS
mod->num_symtab = mod->core_num_syms;
mod->symtab = mod->core_symtab;
mod->strtab = mod->core_strtab;
#endif

Our kallsyms code uses the old (larger!) num_symtab value and boom:

list_for_each_entry_rcu(mod, , list) {
if (mod->state == MODULE_STATE_UNFORMED)
continue;
if (symnum < mod->num_symtab) {
...
strlcpy(name, mod->strtab + mod->symtab[symnum].st_name,
KSYM_NAME_LEN);

And there are other places with the same issue.  This is a more
complex, but I think worth it (actually two patches, rolled into one
for testing):

diff --git a/include/linux/module.h b/include/linux/module.h
index 4560d8f1545d..2bb0c3085706 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -324,6 +324,12 @@ struct module_layout {
 #define __module_layout_align
 #endif
 
+struct mod_kallsyms {
+   Elf_Sym *symtab;
+   unsigned int num_symtab;
+   char *strtab;
+};
+
 struct module {
enum module_state state;
 
@@ -405,15 +411,10 @@ struct module {
 #endif
 
 #ifdef CONFIG_KALLSYMS
-   /*
-* We keep the symbol and string tables for kallsyms.
-* The core_* fields below are temporary, loader-only (they
-* could really be discarded after module init).
-*/
-   Elf_Sym *symtab, *core_symtab;
-   unsigned int num_symtab, core_num_syms;
-   char *strtab, *core_strtab;
-
+   /* Protected by RCU and/or module_mutex: use rcu_dereference() */
+   struct mod_kallsyms *kallsyms;
+   struct mod_kallsyms core_kallsyms;
+   
/* Section attributes */
struct module_sect_attrs *sect_attrs;
 
diff --git a/kernel/module.c b/kernel/module.c
index 2149f7003e49..ecc920df45e6 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -303,6 +303,9 @@ struct load_info {
struct _ddebug *debug;
unsigned int num_debug;
bool sig_ok;
+#ifdef CONFIG_KALLSYMS
+   unsigned long mod_kallsyms_init_off;
+#endif
struct {
unsigned int sym, str, mod, vers, info, pcpu;
} index;
@@ -2482,8 +2485,19 @@ static void layout_symtab(struct module *mod, struct 
load_info *info)
 info->index.str) | INIT_OFFSET_MASK;
mod->init_layout.size = debug_align(mod->init_layout.size);
pr_debug("\t%s\n", info->secstrings + strsect->sh_name);
+
+   /* We'll tack temporary mod_kallsyms on the end. */
+   mod->init_layout.size = ALIGN(mod->init_layout.size,
+ __alignof__(struct mod_kallsyms));
+   

Re: [PATCH] autofs: show pipe inode in mount options

[Ian Kent]

On Tue, 2016-01-26 at 11:55 +0800, Ian Kent wrote:
> On Mon, 2016-01-25 at 15:48 -0800, Andrew Morton wrote:
> > On Tue, 26 Jan 2016 10:19:07 +1100 Stephen Rothwell <
> > s...@canb.auug.org.au> wrote:
> > 
> > > Hi Ian,
> > > 
> > > On Sat, 23 Jan 2016 08:30:17 +0800 Ian Kent 
> > > wrote:
> > > > 
> > > > I haven't had anything significant enough for autofs to warrant
> > > > maintaining a tree and sending push requests so I'll need to ask
> > > > Stephen what I need to do (perhaps you could offer some advise on
> > > > that
> > > > now Stephen, please).
> > > 
> > > I guess if its just a few patches every now and then, then Andrew
> > > Morton may be the best person to shepherd them upstream.
> > 
> > yup, send 'em along.
> > 
> > I actually was handling the autofs4 stuff back in 2014 for a bit.
> 
> Thanks Andrew.
> 
> Last time I tried to send the module rename series we got confused some
> how, patches not seen leading to conflicts in applying later patches
> IIRC, which lead to the recommendation I send them to linux-next.
> 
> The series has grown a bit too now but I'm thinking I should send them
> in smaller groups, such as coding style fixes and white space fixes,
> change to use pr* logging, etc.
> 
> Hopefully that will make the process much more straight forward.
> 
> The thing is the patches are mostly not urgent which is why I keep
> postponing sending them when higher priority things come up.
> 
> As for the patch from Stanislav, I'll put that at the top of my patch
> queue, have a quick look at it and send it over so that, hopefully, it
> can get merged.
> 
> I'll probably send a couple of others too to get things going on with
> (what I'm calling) the module rename series.

Hi Andrew,

I've sent the first bunch of patches to get this change started, including
 Stanislav's patch.

Thanks
Ian

Re: [PATCH] mmc: dw_mmc: fix num_slots setting

[Jaehoon Chung]

Hi, Shawn.

On 01/22/2016 04:43 PM, Shawn Lin wrote:
> This patch make num_slots to 1 if pdata->num_slot is not
> defined. Meanwhile, we need to make sure num_slots should
> not larger that the supported slots
> 
> Signed-off-by: Shawn Lin 
> ---
> 
>  drivers/mmc/host/dw_mmc.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 7128351..065a8f5 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -2949,12 +2949,6 @@ int dw_mci_probe(struct dw_mci *host)
>   }
>   }
>  
> - if (host->pdata->num_slots < 1) {
> - dev_err(host->dev,
> - "Platform data must supply num_slots.\n");
> - return -ENODEV;
> - }
> -
>   host->biu_clk = devm_clk_get(host->dev, "biu");
>   if (IS_ERR(host->biu_clk)) {
>   dev_dbg(host->dev, "biu clock not available\n");
> @@ -3111,7 +3105,15 @@ int dw_mci_probe(struct dw_mci *host)
>   if (host->pdata->num_slots)
>   host->num_slots = host->pdata->num_slots;
>   else
> - host->num_slots = SDMMC_GET_SLOT_NUM(mci_readl(host, HCON));
> + host->num_slots = 1;

If host->nums_slots is set to 1, it assumes that there is one slot.
Then the code in dw_mci_parse_dt() can be removed 

dev_info(dev,
 "num-slots property not found, assuming 1 slot is 
available\n");
pdata->num_slots = 1;


Best Regards,
Jaehoon Chung


> +
> + if (host->num_slots < 1 ||
> + host->num_slots > SDMMC_GET_SLOT_NUM(mci_readl(host, HCON))) {
> + dev_err(host->dev,
> + "Platform data must supply correct num_slots.\n");
> + ret = -ENODEV;
> + goto err_clk_ciu;
> + }
>  
>   /*
>* Enable interrupts for command done, data over, data empty,
> 

Re: linux-4.5-rc1 TI pandboard-es wifi wlcore locks and reset

[Sebastian Reichel]

Hi,

On Mon, Feb 01, 2016 at 11:38:38PM +1100, Ross Green wrote:
> On Mon, Jan 25, 2016 at 11:47 PM, Ross Green  wrote:
> > Just tried the new kernel release on faithful pandaboard es with the
> > new 4.5-rc1 release.
> >
> > There is a problem with the wifi modules once the modules are loaded.
> > Looks like the wifi firmware gets loaded put no response after that
> > causing recovery action.
> >
> > the kernel 4.4 works quite happily with this board.
> >
> > Here is a dmesg dump in the attachment.
> >
> > Anyone have any ideas here?
>
> Just updated to the latest linux-4.5-rc2 and same result as rc1.
> 
> The wireless module loads firmware and then stalls causing a reset of
> the device and then continues to go through a stall and reset cycle.
> 
> please find enclosed a copy of the dmesg output.
> 
> Is there anyone else testing a pandaboard with linux-4.5-rc2?
> 
> Just for completeness also tested the latest linux-4.4.1 kernel and
> found no problems with the wireless modules.

I can see the same problem with Nokia N950 (which uses spi connected
wl1271). v4.4 + wl12xx spi DT patches from Uri Mashiach worked, v4.5
 + the same patches does not work. I currently suspect 133b7326e960
or 3719c17e1816 to be the culprit. I have not yet verified it, though.

Have you tried to bisect the problem?

-- Sebastian


signature.asc
Description: PGP signature

[PATCH char-misc-next 0/8] Enable Virtio Over PCIe (VOP) driver

[Sudeep Dutt]

This patch series moves virtio functionality from the MIC host/card
driver into a separate hardware independent Virtio Over PCIe (VOP)
driver. Apart from being moved into a separate driver the functionality
is essentially unchanged. This refactoring allows this hardware
independent logic to be shared easily across multiple generations of
MIC devices. The original commits are listed below for reference:
- commit f69bcbf3b4c4 ("Intel MIC Host Driver Changes for Virtio Devices.")
in drivers/misc/mic/host/mic_virtio.c
- commit 2141c7c5ee67 ("Intel MIC Card Driver Changes for Virtio Devices.")
in drivers/misc/mic/card/mic_virtio.c

The patch series is partitioned as follows:
1) Removes MIC X100 host virtio functionality
2) Removes MIC X100 card virtio functionality
3) Enables the Virtio Over PCIe (VOP) bus which abstracts the
   low level hardware details like interrupts and mapping remote
   memory so that the same VOP driver can work without changes
   with different MIC host or card drivers as long as the hardware
   bus operations are implemented.
4) Adds data structures for the VOP driver
5) Enables VOP host side functionality
6) Enables VOP card side functionality
7) Enables VOP debugfs and driver build
8) Implements the MIC host and card driver changes to enable VOP

Ashutosh Dixit (1):
  misc: mic: Enable VOP card side functionality

Sudeep Dutt (7):
  misc: mic: Remove MIC X100 host virtio functionality
  misc: mic: Remove MIC X100 card virtio functionality
  misc: mic: MIC VOP Bus
  misc: mic: Add data structures for the VOP driver
  misc: mic: Enable VOP host side functionality
  misc: mic: Enable VOP debugfs and driver build
  misc: mic: MIC host and card driver changes to enable VOP

 Documentation/mic/mic_overview.txt |   54 +-
 drivers/misc/mic/Kconfig   |   44 +-
 drivers/misc/mic/Makefile  |1 +
 drivers/misc/mic/bus/Makefile  |1 +
 drivers/misc/mic/card/Makefile |1 -
 drivers/misc/mic/host/Makefile |2 -
 drivers/misc/mic/vop/Makefile  |9 +
 drivers/misc/mic/bus/vop_bus.h |  142 +++
 drivers/misc/mic/card/mic_device.h |3 +
 drivers/misc/mic/card/mic_virtio.h |   76 --
 drivers/misc/mic/host/mic_device.h |9 +-
 drivers/misc/mic/host/mic_fops.h   |   32 -
 .../misc/mic/{host/mic_virtio.h => vop/vop_main.h} |  129 ++-
 Documentation/mic/mpssd/mpssd.c|2 +-
 drivers/misc/mic/bus/vop_bus.c |  204 
 drivers/misc/mic/card/mic_device.c |   89 +-
 drivers/misc/mic/card/mic_virtio.c |  634 ---
 drivers/misc/mic/card/mic_x100.c   |1 +
 drivers/misc/mic/host/mic_boot.c   |  127 ++-
 drivers/misc/mic/host/mic_debugfs.c|  190 
 drivers/misc/mic/host/mic_fops.c   |  222 
 drivers/misc/mic/host/mic_main.c   |   49 +-
 drivers/misc/mic/host/mic_virtio.c |  811 --
 drivers/misc/mic/vop/vop_debugfs.c |  232 
 drivers/misc/mic/vop/vop_main.c|  755 +
 drivers/misc/mic/vop/vop_vringh.c  | 1164 
 Documentation/mic/mpssd/mpss   |2 +-
 27 files changed, 2869 insertions(+), 2116 deletions(-)
 create mode 100644 drivers/misc/mic/vop/Makefile
 create mode 100644 drivers/misc/mic/bus/vop_bus.h
 delete mode 100644 drivers/misc/mic/card/mic_virtio.h
 delete mode 100644 drivers/misc/mic/host/mic_fops.h
 rename drivers/misc/mic/{host/mic_virtio.h => vop/vop_main.h} (58%)
 create mode 100644 drivers/misc/mic/bus/vop_bus.c
 delete mode 100644 drivers/misc/mic/card/mic_virtio.c
 delete mode 100644 drivers/misc/mic/host/mic_fops.c
 delete mode 100644 drivers/misc/mic/host/mic_virtio.c
 create mode 100644 drivers/misc/mic/vop/vop_debugfs.c
 create mode 100644 drivers/misc/mic/vop/vop_main.c
 create mode 100644 drivers/misc/mic/vop/vop_vringh.c

-- 
1.8.2.1

[PATCH char-misc-next 1/8] misc: mic: Remove MIC X100 host virtio functionality

[Sudeep Dutt]

This patch deletes the virtio functionality from the MIC X100 host
driver. A subsequent patch will re-enable this functionality by
consolidating the hardware independent logic in a new Virtio over PCIe
(VOP) driver.

Reviewed-by: Ashutosh Dixit 
Signed-off-by: Sudeep Dutt 
---
 drivers/misc/mic/host/Makefile  |   2 -
 drivers/misc/mic/host/mic_device.h  |   6 -
 drivers/misc/mic/host/mic_fops.h|  32 --
 drivers/misc/mic/host/mic_virtio.h  | 155 ---
 drivers/misc/mic/host/mic_boot.c|   2 -
 drivers/misc/mic/host/mic_debugfs.c | 190 -
 drivers/misc/mic/host/mic_fops.c| 222 --
 drivers/misc/mic/host/mic_main.c|  48 +--
 drivers/misc/mic/host/mic_virtio.c  | 811 
 9 files changed, 4 insertions(+), 1464 deletions(-)
 delete mode 100644 drivers/misc/mic/host/mic_fops.h
 delete mode 100644 drivers/misc/mic/host/mic_virtio.h
 delete mode 100644 drivers/misc/mic/host/mic_fops.c
 delete mode 100644 drivers/misc/mic/host/mic_virtio.c

diff --git a/drivers/misc/mic/host/Makefile b/drivers/misc/mic/host/Makefile
index 004d3db..f3b5023 100644
--- a/drivers/misc/mic/host/Makefile
+++ b/drivers/misc/mic/host/Makefile
@@ -9,5 +9,3 @@ mic_host-objs += mic_smpt.o
 mic_host-objs += mic_intr.o
 mic_host-objs += mic_boot.o
 mic_host-objs += mic_debugfs.o
-mic_host-objs += mic_fops.o
-mic_host-objs += mic_virtio.o
diff --git a/drivers/misc/mic/host/mic_device.h 
b/drivers/misc/mic/host/mic_device.h
index 461184a..8460de1 100644
--- a/drivers/misc/mic/host/mic_device.h
+++ b/drivers/misc/mic/host/mic_device.h
@@ -64,9 +64,6 @@ extern struct cosm_hw_ops cosm_hw_ops;
  * @bootaddr: MIC boot address.
  * @dp: virtio device page
  * @dp_dma_addr: virtio device page DMA address.
- * @name: name for the misc char device
- * @miscdev: registered misc char device
- * @vdev_list: list of virtio devices.
  * @dma_mbdev: MIC BUS DMA device.
  * @dma_ch - Array of DMA channels
  * @num_dma_ch - Number of DMA channels available
@@ -91,9 +88,6 @@ struct mic_device {
u32 bootaddr;
void *dp;
dma_addr_t dp_dma_addr;
-   char name[16];
-   struct miscdevice miscdev;
-   struct list_head vdev_list;
struct mbus_device *dma_mbdev;
struct dma_chan *dma_ch[MIC_MAX_DMA_CHAN];
int num_dma_ch;
diff --git a/drivers/misc/mic/host/mic_fops.h b/drivers/misc/mic/host/mic_fops.h
deleted file mode 100644
index dc3893d..000
--- a/drivers/misc/mic/host/mic_fops.h
+++ /dev/null
@@ -1,32 +0,0 @@
-/*
- * Intel MIC Platform Software Stack (MPSS)
- *
- * Copyright(c) 2013 Intel Corporation.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License, version 2, as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * The full GNU General Public License is included in this distribution in
- * the file called "COPYING".
- *
- * Intel MIC Host driver.
- *
- */
-#ifndef _MIC_FOPS_H_
-#define _MIC_FOPS_H_
-
-int mic_open(struct inode *inode, struct file *filp);
-int mic_release(struct inode *inode, struct file *filp);
-ssize_t mic_read(struct file *filp, char __user *buf,
-   size_t count, loff_t *pos);
-long mic_ioctl(struct file *filp, unsigned int cmd, unsigned long arg);
-int mic_mmap(struct file *f, struct vm_area_struct *vma);
-unsigned int mic_poll(struct file *f, poll_table *wait);
-
-#endif
diff --git a/drivers/misc/mic/host/mic_virtio.h 
b/drivers/misc/mic/host/mic_virtio.h
deleted file mode 100644
index a80631f..000
--- a/drivers/misc/mic/host/mic_virtio.h
+++ /dev/null
@@ -1,155 +0,0 @@
-/*
- * Intel MIC Platform Software Stack (MPSS)
- *
- * Copyright(c) 2013 Intel Corporation.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License, version 2, as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * The full GNU General Public License is included in this distribution in
- * the file called "COPYING".
- *
- * Intel MIC Host driver.
- *
- */
-#ifndef MIC_VIRTIO_H
-#define MIC_VIRTIO_H
-
-#include 
-#include 
-
-/*
- * Note on endianness.
- * 1. Host can be both BE or LE
- * 2. Guest/card is LE. Host uses le_to_cpu to access desc/avail
- *rings and ioreadXX/iowriteXX to access used ring.
- * 3. Device page exposed by host to guest contains LE values. Guest
- *accesses these using ioreadXX/iowriteXX etc. This way in general we
- *obey the 

[PATCH char-misc-next 3/8] misc: mic: MIC VOP Bus

[Sudeep Dutt]

The Virtio Over PCIe (VOP) bus abstracts the low level hardware
details like interrupts and mapping remote memory so that the same VOP
driver can work without changes with different MIC host or card
drivers as long as the hardware bus operations are implemented. The
VOP driver registers itself on the VOP bus. The base PCIe drivers
implement the bus ops and register VOP devices on the bus, resulting
in the VOP driver being probed with the VOP devices. This allows the
VOP functionality to be shared between multiple generations of Intel
MIC products.

Reviewed-by: Ashutosh Dixit 
Signed-off-by: Sudeep Dutt 
---
 drivers/misc/mic/Kconfig   |  17 
 drivers/misc/mic/bus/Makefile  |   1 +
 drivers/misc/mic/bus/vop_bus.h | 142 
 drivers/misc/mic/bus/vop_bus.c | 204 +
 4 files changed, 364 insertions(+)
 create mode 100644 drivers/misc/mic/bus/vop_bus.h
 create mode 100644 drivers/misc/mic/bus/vop_bus.c

diff --git a/drivers/misc/mic/Kconfig b/drivers/misc/mic/Kconfig
index 40677df..840f7ef 100644
--- a/drivers/misc/mic/Kconfig
+++ b/drivers/misc/mic/Kconfig
@@ -32,6 +32,23 @@ config SCIF_BUS
  OS and tools for MIC to use with this driver are available from
  .
 
+comment "VOP Bus Driver"
+
+config VOP_BUS
+   tristate "VOP Bus Driver"
+   depends on 64BIT && PCI && X86 && X86_DEV_DMA_OPS
+   help
+ This option is selected by any driver which registers a
+ device or driver on the VOP Bus, such as CONFIG_INTEL_MIC_HOST
+ and CONFIG_INTEL_MIC_CARD.
+
+ If you are building a host/card kernel with an Intel MIC device
+ then say M (recommended) or Y, else say N. If unsure say N.
+
+ More information about the Intel MIC family as well as the Linux
+ OS and tools for MIC to use with this driver are available from
+ .
+
 comment "Intel MIC Host Driver"
 
 config INTEL_MIC_HOST
diff --git a/drivers/misc/mic/bus/Makefile b/drivers/misc/mic/bus/Makefile
index 761842b..8758a7d 100644
--- a/drivers/misc/mic/bus/Makefile
+++ b/drivers/misc/mic/bus/Makefile
@@ -5,3 +5,4 @@
 obj-$(CONFIG_INTEL_MIC_BUS) += mic_bus.o
 obj-$(CONFIG_SCIF_BUS) += scif_bus.o
 obj-$(CONFIG_MIC_COSM) += cosm_bus.o
+obj-$(CONFIG_VOP_BUS) += vop_bus.o
diff --git a/drivers/misc/mic/bus/vop_bus.h b/drivers/misc/mic/bus/vop_bus.h
new file mode 100644
index 000..97fa5d6
--- /dev/null
+++ b/drivers/misc/mic/bus/vop_bus.h
@@ -0,0 +1,142 @@
+/*
+ * Intel MIC Platform Software Stack (MPSS)
+ *
+ * Copyright(c) 2016 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * The full GNU General Public License is included in this distribution in
+ * the file called "COPYING".
+ *
+ * Intel Virtio over PCIe Bus driver.
+ */
+#ifndef _VOP_BUS_H_
+#define _VOP_BUS_H_
+/*
+ * Everything a vop driver needs to work with any particular vop
+ * implementation.
+ */
+#include 
+#include 
+
+#include "../common/mic_dev.h"
+
+struct vop_device_id {
+   u32 device;
+   u32 vendor;
+};
+
+#define VOP_DEV_TRNSP 1
+#define VOP_DEV_ANY_ID 0x
+/*
+ * Size of the internal buffer used during DMA's as an intermediate buffer
+ * for copy to/from user. Must be an integral number of pages.
+ */
+#define VOP_INT_DMA_BUF_SIZE PAGE_ALIGN(64 * 1024ULL)
+
+/**
+ * vop_device - representation of a device using vop
+ * @priv: private pointer for the driver's use.
+ * @hw_ops: the hardware ops supported by this device.
+ * @id: the device type identification (used to match it with a driver).
+ * @dev: underlying device.
+ * @dnode - The destination node which this device will communicate with.
+ * @aper: Aperture memory window
+ * @dma_ch - DMA channel
+ * @index: unique position on the vop bus
+ */
+struct vop_device {
+   void *priv;
+   struct vop_hw_ops *hw_ops;
+   struct vop_device_id id;
+   struct device dev;
+   u8 dnode;
+   struct mic_mw *aper;
+   struct dma_chan *dma_ch;
+   int index;
+};
+
+/**
+ * vop_driver - operations for a vop I/O driver
+ * @driver: underlying device driver (populate name and owner).
+ * @id_table: the ids serviced by this driver.
+ * @probe: the function to call when a device is found.  Returns 0 or -errno.
+ * @remove: the function to call when a device is removed.
+ */
+struct vop_driver {
+   struct device_driver driver;
+   const struct vop_device_id *id_table;
+   int (*probe)(struct vop_device *dev);
+   void 

[PATCH char-misc-next 2/8] misc: mic: Remove MIC X100 card virtio functionality

[Sudeep Dutt]

This patch deletes the virtio functionality from the MIC X100 card
driver. A subsequent patch will re-enable this functionality by
consolidating the hardware independent logic in a new Virtio over PCIe
(VOP) driver.

Reviewed-by: Ashutosh Dixit 
Signed-off-by: Sudeep Dutt 
---
 drivers/misc/mic/card/Makefile |   1 -
 drivers/misc/mic/card/mic_virtio.h |  76 -
 drivers/misc/mic/card/mic_device.c |   9 +-
 drivers/misc/mic/card/mic_virtio.c | 634 -
 4 files changed, 1 insertion(+), 719 deletions(-)
 delete mode 100644 drivers/misc/mic/card/mic_virtio.h
 delete mode 100644 drivers/misc/mic/card/mic_virtio.c

diff --git a/drivers/misc/mic/card/Makefile b/drivers/misc/mic/card/Makefile
index 69d58be..6e9675e 100644
--- a/drivers/misc/mic/card/Makefile
+++ b/drivers/misc/mic/card/Makefile
@@ -8,4 +8,3 @@ obj-$(CONFIG_INTEL_MIC_CARD) += mic_card.o
 mic_card-y += mic_x100.o
 mic_card-y += mic_device.o
 mic_card-y += mic_debugfs.o
-mic_card-y += mic_virtio.o
diff --git a/drivers/misc/mic/card/mic_virtio.h 
b/drivers/misc/mic/card/mic_virtio.h
deleted file mode 100644
index d0407ba..000
--- a/drivers/misc/mic/card/mic_virtio.h
+++ /dev/null
@@ -1,76 +0,0 @@
-/*
- * Intel MIC Platform Software Stack (MPSS)
- *
- * Copyright(c) 2013 Intel Corporation.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License, version 2, as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * The full GNU General Public License is included in this distribution in
- * the file called "COPYING".
- *
- * Disclaimer: The codes contained in these modules may be specific to
- * the Intel Software Development Platform codenamed: Knights Ferry, and
- * the Intel product codenamed: Knights Corner, and are not backward
- * compatible with other Intel products. Additionally, Intel will NOT
- * support the codes or instruction set in future products.
- *
- * Intel MIC Card driver.
- *
- */
-#ifndef __MIC_CARD_VIRTIO_H
-#define __MIC_CARD_VIRTIO_H
-
-#include 
-#include "mic_device.h"
-
-/*
- * 64 bit I/O access
- */
-#ifndef ioread64
-#define ioread64 readq
-#endif
-#ifndef iowrite64
-#define iowrite64 writeq
-#endif
-
-static inline unsigned mic_desc_size(struct mic_device_desc __iomem *desc)
-{
-   return sizeof(*desc)
-   + ioread8(>num_vq) * sizeof(struct mic_vqconfig)
-   + ioread8(>feature_len) * 2
-   + ioread8(>config_len);
-}
-
-static inline struct mic_vqconfig __iomem *
-mic_vq_config(struct mic_device_desc __iomem *desc)
-{
-   return (struct mic_vqconfig __iomem *)(desc + 1);
-}
-
-static inline __u8 __iomem *
-mic_vq_features(struct mic_device_desc __iomem *desc)
-{
-   return (__u8 __iomem *)(mic_vq_config(desc) + ioread8(>num_vq));
-}
-
-static inline __u8 __iomem *
-mic_vq_configspace(struct mic_device_desc __iomem *desc)
-{
-   return mic_vq_features(desc) + ioread8(>feature_len) * 2;
-}
-static inline unsigned mic_total_desc_size(struct mic_device_desc __iomem 
*desc)
-{
-   return mic_aligned_desc_size(desc) + sizeof(struct mic_device_ctrl);
-}
-
-int mic_devices_init(struct mic_driver *mdrv);
-void mic_devices_uninit(struct mic_driver *mdrv);
-
-#endif
diff --git a/drivers/misc/mic/card/mic_device.c 
b/drivers/misc/mic/card/mic_device.c
index d0edaf7..ff03c63 100644
--- a/drivers/misc/mic/card/mic_device.c
+++ b/drivers/misc/mic/card/mic_device.c
@@ -34,7 +34,6 @@
 #include 
 #include "../common/mic_dev.h"
 #include "mic_device.h"
-#include "mic_virtio.h"
 
 static struct mic_driver *g_drv;
 
@@ -309,9 +308,6 @@ int __init mic_driver_init(struct mic_driver *mdrv)
rc = -ENODEV;
goto irq_uninit;
}
-   rc = mic_devices_init(mdrv);
-   if (rc)
-   goto dma_free;
bootparam = mdrv->dp;
node_id = ioread8(>node_id);
mdrv->scdev = scif_register_device(mdrv->dev, MIC_SCIF_DEV,
@@ -321,13 +317,11 @@ int __init mic_driver_init(struct mic_driver *mdrv)
   mdrv->num_dma_ch, true);
if (IS_ERR(mdrv->scdev)) {
rc = PTR_ERR(mdrv->scdev);
-   goto device_uninit;
+   goto dma_free;
}
mic_create_card_debug_dir(mdrv);
 done:
return rc;
-device_uninit:
-   mic_devices_uninit(mdrv);
 dma_free:
mic_free_dma_chans(mdrv);
 irq_uninit:
@@ -348,7 +342,6 @@ void mic_driver_uninit(struct mic_driver *mdrv)
 {
mic_delete_card_debug_dir(mdrv);
scif_unregister_device(mdrv->scdev);
-   mic_devices_uninit(mdrv);
mic_free_dma_chans(mdrv);
mic_uninit_irq();
mic_dp_uninit();
diff --git 

[PATCH char-misc-next 8/8] misc: mic: MIC host and card driver changes to enable VOP

[Sudeep Dutt]

This patch modifies the MIC host and card drivers to start using the
VOP driver. The MIC host and card drivers now implement the VOP bus
operations and register a VOP device on the VOP bus. MIC driver stack
documentation is also updated to include the new VOP driver.

Reviewed-by: Ashutosh Dixit 
Signed-off-by: Sudeep Dutt 
---
 Documentation/mic/mic_overview.txt |  54 +---
 drivers/misc/mic/Kconfig   |   7 ++-
 drivers/misc/mic/card/mic_device.h |   3 +
 drivers/misc/mic/host/mic_device.h |   3 +
 Documentation/mic/mpssd/mpssd.c|   2 +-
 drivers/misc/mic/card/mic_device.c |  84 -
 drivers/misc/mic/card/mic_x100.c   |   1 +
 drivers/misc/mic/host/mic_boot.c   | 125 -
 drivers/misc/mic/host/mic_main.c   |   1 +
 Documentation/mic/mpssd/mpss   |   2 +-
 10 files changed, 249 insertions(+), 33 deletions(-)

diff --git a/Documentation/mic/mic_overview.txt 
b/Documentation/mic/mic_overview.txt
index 73f44fc..074adbd 100644
--- a/Documentation/mic/mic_overview.txt
+++ b/Documentation/mic/mic_overview.txt
@@ -12,10 +12,19 @@ for the X100 devices.
 
 Since it is a PCIe card, it does not have the ability to host hardware
 devices for networking, storage and console. We provide these devices
-on X100 coprocessors thus enabling a self-bootable equivalent environment
-for applications. A key benefit of our solution is that it leverages
-the standard virtio framework for network, disk and console devices,
-though in our case the virtio framework is used across a PCIe bus.
+on X100 coprocessors thus enabling a self-bootable equivalent
+environment for applications. A key benefit of our solution is that it
+leverages the standard virtio framework for network, disk and console
+devices, though in our case the virtio framework is used across a PCIe
+bus. A Virtio Over PCIe (VOP) driver allows creating user space
+backends or devices on the host which are used to probe virtio drivers
+for these devices on the MIC card. The existing VRINGH infrastructure
+in the kernel is used to access virtio rings from the host. The card
+VOP driver allows card virtio drivers to communicate with their user
+space backends on the host via a device page. Ring 3 apps on the host
+can add, remove and configure virtio devices. A thin MIC specific
+virtio_config_ops is implemented which is borrowed heavily from
+previous similar implementations in lguest and s390.
 
 MIC PCIe card has a dma controller with 8 channels. These channels are
 shared between the host s/w and the card s/w. 0 to 3 are used by host
@@ -38,7 +47,6 @@ single threaded performance for the host compared to MIC, the 
ability of
 the host to initiate DMA's to/from the card using the MIC DMA engine and
 the fact that the virtio block storage backend can only be on the host.
 
-  |
+--+   | +--+
| Card OS  |   | | Host OS  |
+--+   | +--+
@@ -47,27 +55,25 @@ the fact that the virtio block storage backend can only be 
on the host.
 | Virtio| |Virtio  | |Virtio| | |Virtio   |  |Virtio  | |Virtio  |
 | Net   | |Console | |Block | | |Net  |  |Console | |Block   |
 | Driver| |Driver  | |Driver| | |backend  |  |backend | |backend |
-+---+ ++ +--+ | +-+  ++ ++
++---+---+ +---++ +--+---+ | +-+  ++---+ ++
 | | | |  || |
 | | | |User  || |
-| | | |--||-|---
-+---+ |Kernel +--+
-  |   |   | Virtio over PCIe IOCTLs  |
-  |   |   +--+
-+---+ |   |   |  +---+
-| MIC DMA   | |  +--+ | +--+ +--+ |  | MIC DMA   |
-| Driver| |  | SCIF | | | SCIF | | COSM | |  | Driver|
-+---+ |  +--+ | +--+ +--+---+ |  +---+
-  |   | | ||| ||
-+---+ |  +--+ | +--+---+ +--+---+ | ++
-|MIC virtual Bus| |  |SCIF  | | |SCIF  | | COSM | | |MIC virtual Bus |
-+---+ |  |HW Bus| | |HW Bus| | Bus  | | ++
-  |   |  +--+ | +--+---+ +--+ |  |
-  |   | | |   | | |  |
-  |   +---+---+ | |   |+---+ |
-  |   |Intel MIC  | | |   ||Intel MIC  | |
-  +---|Card Driver| | |   ||Host Driver| |
-   

[PATCH char-misc-next 6/8] misc: mic: Enable VOP card side functionality

[Sudeep Dutt]

From: Ashutosh Dixit 

This patch moves virtio functionality from the MIC card driver into a
separate hardware independent Virtio Over PCIe (VOP) driver. This
functionality was introduced in commit 2141c7c5ee67 ("Intel MIC Card
Driver Changes for Virtio Devices.") in
drivers/misc/mic/card/mic_virtio.c. Apart from being moved into a
separate driver the functionality is essentially unchanged. See the
above mentioned commit for a description of this functionality.

Signed-off-by: Sudeep Dutt 
Signed-off-by: Ashutosh Dixit 
---
 drivers/misc/mic/vop/vop_main.c | 755 
 1 file changed, 755 insertions(+)
 create mode 100644 drivers/misc/mic/vop/vop_main.c

diff --git a/drivers/misc/mic/vop/vop_main.c b/drivers/misc/mic/vop/vop_main.c
new file mode 100644
index 000..c86aeeb
--- /dev/null
+++ b/drivers/misc/mic/vop/vop_main.c
@@ -0,0 +1,755 @@
+/*
+ * Intel MIC Platform Software Stack (MPSS)
+ *
+ * Copyright(c) 2016 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * The full GNU General Public License is included in this distribution in
+ * the file called "COPYING".
+ *
+ * Adapted from:
+ *
+ * virtio for kvm on s390
+ *
+ * Copyright IBM Corp. 2008
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License (version 2 only)
+ * as published by the Free Software Foundation.
+ *
+ *Author(s): Christian Borntraeger 
+ *
+ * Intel Virtio Over PCIe (VOP) driver.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+
+#include "vop_main.h"
+
+#define VOP_MAX_VRINGS 4
+
+/*
+ * _vop_vdev - Allocated per virtio device instance injected by the peer.
+ *
+ * @vdev: Virtio device
+ * @desc: Virtio device page descriptor
+ * @dc: Virtio device control
+ * @vpdev: VOP device which is the parent for this virtio device
+ * @vr: Buffer for accessing the VRING
+ * @used: Buffer for used
+ * @used_size: Size of the used buffer
+ * @reset_done: Track whether VOP reset is complete
+ * @virtio_cookie: Cookie returned upon requesting a interrupt
+ * @c2h_vdev_db: The doorbell used by the guest to interrupt the host
+ * @h2c_vdev_db: The doorbell used by the host to interrupt the guest
+ * @dnode: The destination node
+ */
+struct _vop_vdev {
+   struct virtio_device vdev;
+   struct mic_device_desc __iomem *desc;
+   struct mic_device_ctrl __iomem *dc;
+   struct vop_device *vpdev;
+   void __iomem *vr[VOP_MAX_VRINGS];
+   dma_addr_t used[VOP_MAX_VRINGS];
+   int used_size[VOP_MAX_VRINGS];
+   struct completion reset_done;
+   struct mic_irq *virtio_cookie;
+   int c2h_vdev_db;
+   int h2c_vdev_db;
+   int dnode;
+};
+
+#define to_vopvdev(vd) container_of(vd, struct _vop_vdev, vdev)
+
+#define _vop_aligned_desc_size(d) __mic_align(_vop_desc_size(d), 8)
+
+/* Helper API to obtain the parent of the virtio device */
+static inline struct device *_vop_dev(struct _vop_vdev *vdev)
+{
+   return vdev->vdev.dev.parent;
+}
+
+static inline unsigned _vop_desc_size(struct mic_device_desc __iomem *desc)
+{
+   return sizeof(*desc)
+   + ioread8(>num_vq) * sizeof(struct mic_vqconfig)
+   + ioread8(>feature_len) * 2
+   + ioread8(>config_len);
+}
+
+static inline struct mic_vqconfig __iomem *
+_vop_vq_config(struct mic_device_desc __iomem *desc)
+{
+   return (struct mic_vqconfig __iomem *)(desc + 1);
+}
+
+static inline u8 __iomem *
+_vop_vq_features(struct mic_device_desc __iomem *desc)
+{
+   return (u8 __iomem *)(_vop_vq_config(desc) + ioread8(>num_vq));
+}
+
+static inline u8 __iomem *
+_vop_vq_configspace(struct mic_device_desc __iomem *desc)
+{
+   return _vop_vq_features(desc) + ioread8(>feature_len) * 2;
+}
+
+static inline unsigned
+_vop_total_desc_size(struct mic_device_desc __iomem *desc)
+{
+   return _vop_aligned_desc_size(desc) + sizeof(struct mic_device_ctrl);
+}
+
+/* This gets the device's feature bits. */
+static u64 vop_get_features(struct virtio_device *vdev)
+{
+   unsigned int i, bits;
+   u32 features = 0;
+   struct mic_device_desc __iomem *desc = to_vopvdev(vdev)->desc;
+   u8 __iomem *in_features = _vop_vq_features(desc);
+   int feature_len = ioread8(>feature_len);
+
+   bits = min_t(unsigned, feature_len, sizeof(vdev->features)) * 8;
+   for (i = 0; i < bits; i++)
+   if (ioread8(_features[i / 8]) & (BIT(i % 8)))
+   features |= BIT(i);
+
+   return features;
+}
+
+static int vop_finalize_features(struct 

[PATCH char-misc-next 5/8] misc: mic: Enable VOP host side functionality

[Sudeep Dutt]

This patch moves virtio functionality from the MIC host driver into a
separate hardware independent Virtio Over PCIe (VOP) driver. This
functionality was introduced in commit f69bcbf3b4c4 ("Intel MIC Host
Driver Changes for Virtio Devices.") in
drivers/misc/mic/host/mic_virtio.c. Apart from being moved into a
separate driver the functionality is essentially unchanged. See the
above mentioned commit for a description of this functionality.

Signed-off-by: Ashutosh Dixit 
Signed-off-by: Sudeep Dutt 
---
 drivers/misc/mic/vop/vop_vringh.c | 1164 +
 1 file changed, 1164 insertions(+)
 create mode 100644 drivers/misc/mic/vop/vop_vringh.c

diff --git a/drivers/misc/mic/vop/vop_vringh.c 
b/drivers/misc/mic/vop/vop_vringh.c
new file mode 100644
index 000..6dc41fe
--- /dev/null
+++ b/drivers/misc/mic/vop/vop_vringh.c
@@ -0,0 +1,1164 @@
+/*
+ * Intel MIC Platform Software Stack (MPSS)
+ *
+ * Copyright(c) 2016 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * The full GNU General Public License is included in this distribution in
+ * the file called "COPYING".
+ *
+ * Intel Virtio Over PCIe (VOP) driver.
+ *
+ */
+#include 
+#include 
+#include 
+
+#include 
+#include "../common/mic_dev.h"
+
+#include 
+#include "vop_main.h"
+
+/* Helper API to obtain the VOP PCIe device */
+static inline struct device *vop_dev(struct vop_vdev *vdev)
+{
+   return vdev->vpdev->dev.parent;
+}
+
+/* Helper API to check if a virtio device is initialized */
+static inline int vop_vdev_inited(struct vop_vdev *vdev)
+{
+   if (!vdev)
+   return -EINVAL;
+   /* Device has not been created yet */
+   if (!vdev->dd || !vdev->dd->type) {
+   dev_err(vop_dev(vdev), "%s %d err %d\n",
+   __func__, __LINE__, -EINVAL);
+   return -EINVAL;
+   }
+   /* Device has been removed/deleted */
+   if (vdev->dd->type == -1) {
+   dev_dbg(vop_dev(vdev), "%s %d err %d\n",
+   __func__, __LINE__, -ENODEV);
+   return -ENODEV;
+   }
+   return 0;
+}
+
+static void _vop_notify(struct vringh *vrh)
+{
+   struct vop_vringh *vvrh = container_of(vrh, struct vop_vringh, vrh);
+   struct vop_vdev *vdev = vvrh->vdev;
+   struct vop_device *vpdev = vdev->vpdev;
+   s8 db = vdev->dc->h2c_vdev_db;
+
+   if (db != -1)
+   vpdev->hw_ops->send_intr(vpdev, db);
+}
+
+static void vop_virtio_init_post(struct vop_vdev *vdev)
+{
+   struct mic_vqconfig *vqconfig = mic_vq_config(vdev->dd);
+   struct vop_device *vpdev = vdev->vpdev;
+   int i, used_size;
+
+   for (i = 0; i < vdev->dd->num_vq; i++) {
+   used_size = PAGE_ALIGN(sizeof(u16) * 3 +
+   sizeof(struct vring_used_elem) *
+   le16_to_cpu(vqconfig->num));
+   if (!le64_to_cpu(vqconfig[i].used_address)) {
+   dev_warn(vop_dev(vdev), "used_address zero??\n");
+   continue;
+   }
+   vdev->vvr[i].vrh.vring.used =
+   (void __force *)vpdev->hw_ops->ioremap(
+   vpdev,
+   le64_to_cpu(vqconfig[i].used_address),
+   used_size);
+   }
+
+   vdev->dc->used_address_updated = 0;
+
+   dev_info(vop_dev(vdev), "%s: device type %d LINKUP\n",
+__func__, vdev->virtio_id);
+}
+
+static inline void vop_virtio_device_reset(struct vop_vdev *vdev)
+{
+   int i;
+
+   dev_dbg(vop_dev(vdev), "%s: status %d device type %d RESET\n",
+   __func__, vdev->dd->status, vdev->virtio_id);
+
+   for (i = 0; i < vdev->dd->num_vq; i++)
+   /*
+* Avoid lockdep false positive. The + 1 is for the vop
+* mutex which is held in the reset devices code path.
+*/
+   mutex_lock_nested(>vvr[i].vr_mutex, i + 1);
+
+   /* 0 status means "reset" */
+   vdev->dd->status = 0;
+   vdev->dc->vdev_reset = 0;
+   vdev->dc->host_ack = 1;
+
+   for (i = 0; i < vdev->dd->num_vq; i++) {
+   struct vringh *vrh = >vvr[i].vrh;
+
+   vdev->vvr[i].vring.info->avail_idx = 0;
+   vrh->completed = 0;
+   vrh->last_avail_idx = 0;
+   vrh->last_used_idx = 0;
+   }
+
+   for (i = 0; i < vdev->dd->num_vq; i++)
+   mutex_unlock(>vvr[i].vr_mutex);
+}
+
+static void vop_virtio_reset_devices(struct vop_info *vi)

[PATCH char-misc-next 7/8] misc: mic: Enable VOP debugfs and driver build

[Sudeep Dutt]

This patch moves the virtio specific debugfs hooks previously in
mic_debugfs.c in the MIC host driver into the VOP driver. The
Kconfig/Makefile is also updated to allow building the VOP driver.

Reviewed-by: Ashutosh Dixit 
Signed-off-by: Sudeep Dutt 
---
 drivers/misc/mic/Kconfig   |  20 
 drivers/misc/mic/Makefile  |   1 +
 drivers/misc/mic/vop/Makefile  |   9 ++
 drivers/misc/mic/vop/vop_debugfs.c | 232 +
 4 files changed, 262 insertions(+)
 create mode 100644 drivers/misc/mic/vop/Makefile
 create mode 100644 drivers/misc/mic/vop/vop_debugfs.c

diff --git a/drivers/misc/mic/Kconfig b/drivers/misc/mic/Kconfig
index 840f7ef..b03bb17 100644
--- a/drivers/misc/mic/Kconfig
+++ b/drivers/misc/mic/Kconfig
@@ -124,3 +124,23 @@ config MIC_COSM
  More information about the Intel MIC family as well as the Linux
  OS and tools for MIC to use with this driver are available from
  .
+
+comment "VOP Driver"
+
+config VOP
+   tristate "VOP Driver"
+   depends on 64BIT && PCI && X86 && VOP_BUS
+   select VHOST_RING
+   help
+ This enables VOP (Virtio over PCIe) Driver support for the Intel
+ Many Integrated Core (MIC) family of PCIe form factor coprocessor
+ devices. The VOP driver allows virtio drivers, e.g. net, console
+ and block drivers, on the card connect to user space virtio
+ devices on the host.
+
+ If you are building a host kernel with an Intel MIC device then
+ say M (recommended) or Y, else say N. If unsure say N.
+
+ More information about the Intel MIC family as well as the Linux
+ OS and tools for MIC to use with this driver are available from
+ .
diff --git a/drivers/misc/mic/Makefile b/drivers/misc/mic/Makefile
index e288a11..f2b1323 100644
--- a/drivers/misc/mic/Makefile
+++ b/drivers/misc/mic/Makefile
@@ -8,3 +8,4 @@ obj-y += bus/
 obj-$(CONFIG_SCIF) += scif/
 obj-$(CONFIG_MIC_COSM) += cosm/
 obj-$(CONFIG_MIC_COSM) += cosm_client/
+obj-$(CONFIG_VOP) += vop/
diff --git a/drivers/misc/mic/vop/Makefile b/drivers/misc/mic/vop/Makefile
new file mode 100644
index 000..78819c8
--- /dev/null
+++ b/drivers/misc/mic/vop/Makefile
@@ -0,0 +1,9 @@
+#
+# Makefile - Intel MIC Linux driver.
+# Copyright(c) 2016, Intel Corporation.
+#
+obj-m := vop.o
+
+vop-objs += vop_main.o
+vop-objs += vop_debugfs.o
+vop-objs += vop_vringh.o
diff --git a/drivers/misc/mic/vop/vop_debugfs.c 
b/drivers/misc/mic/vop/vop_debugfs.c
new file mode 100644
index 000..ab43884
--- /dev/null
+++ b/drivers/misc/mic/vop/vop_debugfs.c
@@ -0,0 +1,232 @@
+/*
+ * Intel MIC Platform Software Stack (MPSS)
+ *
+ * Copyright(c) 2016 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * The full GNU General Public License is included in this distribution in
+ * the file called "COPYING".
+ *
+ * Intel Virtio Over PCIe (VOP) driver.
+ *
+ */
+#include 
+#include 
+
+#include "vop_main.h"
+
+static int vop_dp_show(struct seq_file *s, void *pos)
+{
+   struct mic_device_desc *d;
+   struct mic_device_ctrl *dc;
+   struct mic_vqconfig *vqconfig;
+   __u32 *features;
+   __u8 *config;
+   struct vop_info *vi = s->private;
+   struct vop_device *vpdev = vi->vpdev;
+   struct mic_bootparam *bootparam = vpdev->hw_ops->get_dp(vpdev);
+   int j, k;
+
+   seq_printf(s, "Bootparam: magic 0x%x\n",
+  bootparam->magic);
+   seq_printf(s, "Bootparam: h2c_config_db %d\n",
+  bootparam->h2c_config_db);
+   seq_printf(s, "Bootparam: node_id %d\n",
+  bootparam->node_id);
+   seq_printf(s, "Bootparam: c2h_scif_db %d\n",
+  bootparam->c2h_scif_db);
+   seq_printf(s, "Bootparam: h2c_scif_db %d\n",
+  bootparam->h2c_scif_db);
+   seq_printf(s, "Bootparam: scif_host_dma_addr 0x%llx\n",
+  bootparam->scif_host_dma_addr);
+   seq_printf(s, "Bootparam: scif_card_dma_addr 0x%llx\n",
+  bootparam->scif_card_dma_addr);
+
+   for (j = sizeof(*bootparam);
+   j < MIC_DP_SIZE; j += mic_total_desc_size(d)) {
+   d = (void *)bootparam + j;
+   dc = (void *)d + mic_aligned_desc_size(d);
+
+   /* end of list */
+   if (d->type == 0)
+   break;
+
+   if (d->type == -1)
+   continue;
+
+   

[PATCH resend] [dm]fix NULL pointer when create dm device

[DingXiang]

In some conditions(such as umount fs failed),origin path or origin bdev or both 
of the two is same
as cow's.If this happens, origin dev will be freed when get cow dev in function 
"dm_get_device" ,
then "s->origin->dev" which used by "dm_exception_store_set_chunk_size" will be 
a NULL pointer.

Here is my call trace

dracut-initqueue[2614]: mount: unknown filesystem type 'squashfs'
dracut-initqueue[2614]: umount: /run/initramfs/squashfs: not mounted
Unable to handle kernel NULL pointer dereference at virtual address 0098
pgd = ffc038c3d000
[0098] *pgd=, *pud=
Internal error: Oops: 9605 [#1] SMP
Modules linked in:
CPU: 20 PID: 6389 Comm: dmsetup Not tainted 3.19.8+ #19
Hardware name: Huawei Taishan 2160 /BC11SPCA, BIOS 1.16 01/13/2016
task: ffdfb3e060c0 ti: ffc03860 task.ti: ffc03860
PC is at dm_exception_store_set_chunk_size+0x6c/0x124
LR is at dm_exception_store_set_chunk_size+0x68/0x124
pc : [] lr : [] pstate: 4145
sp : ffc038603a90
x29: ffc038603a90 x28: ffc03860
x27: ffefab3b7630 x26: 0001
x25: ffc000c9e030 x24: ffdfb2187740
x23: ffc038603b94 x22: ffefab3b7730
x21: ff80003dd088 x20: ffdfb2187740
x19: 0008 x18: 007fac97383c
x17: 007fac8b9cb0 x16: ffc0001ae79c
x15: 007fac9a00b0 x14: 007fac9a00b0
x13: 0001 x12: 0020
x11: 0008 x10: 
x9 : 000a x8 : 0008
x7 : ffefa95f4179 x6 : 0008
x5 : 0008 x4 : 0007
x3 : 0008 x2 : ff80003dd088
x1 : 0008 x0 : 

Process dmsetup (pid: 6389, stack limit = 0xffc038600058)
Stack: (0xffc038603a90 to 0xffc038604000)
3a80: 38603ac0 ffc0 0060b6fc ffc0
3aa0:   003dd040 ff80 ab3b7600 ffef 0008 
3ac0: 38603b20 ffc0 0060a944 ffc0 b2187700 ffdf 003dd040 ff80
3ae0: ab3b7600 ffef ab3b7730 ffef 0002  0081e000 ffc0
3b00: 00cc6000 ffc0 3860 ffc0 38603b20 ffc0 b2187b58 0008
3b20: 38603bb0 ffc0 005f6378 ffc0 003dd040 ff80 ab3b7800 ffef
3b40:   a95f4150 ffef   003dd040 ff80
3b60: a95f4000 ffef a95f4000 ffef 00c58000 ffc0 3860 ffc0
3b80:   a95f416b ffef a95f4000 ffef 005f62d4 ffc0
3ba0: 003dd040 ff80 005f5f68 0008 38603c10 ffc0 005f98cc ffc0
3bc0: a95f4138 ffef a95f8000 ffef   b41b2400 ffdf
3be0: ab3b7800 ffef   a95f4160 ffef 0010 
3c00: 38603c10 0004 b2187700 ffdf 38603c70 ffc0 005fa484 ffc0
3c20: c7e1d2d0 007f   4000  0009 
3c40: 0001  005f97bc ffc0    
3c60:   ab3b7800 ffef 38603e00 ffc0 005fa758 ffc0
3c80: b7e82c00 ffdf c7e1d2d0 007f b87e6e88 ffef 0003 
3ca0: c7e1d2d0 007f c138fd09  011a  001d 
3cc0: 0020  0004 001d  4000 0138 0001
3ce0:  0004     6576696c 0077722d
3d00:        
3d20:        
3d40:        
3d60:        
3d80:        
3da0:        
3dc0:        
3de0:        
3e00: 38603e10 ffc0 001ae54c ffc0 38603e90 ffc0 001ae820 ffc0
3e20:   b7e82c00 ffdf b7e82c00 ffdf 0003 
3e40: 00cbb000 ffc0 b3e060c0 ffdf 8000  0015 
3e60:     38603e80 ffc0 001b88e4 ffc0
3e80: 38603e90 ffc0 001ae7dc ffc0 c6e64c40 007f 00086430 ffc0
3ea0:   c7e1d2d0 007f   ac8b9cbc 007f
3ec0: 6000  0015  0003  c138fd09 
3ee0: c7e1d2d0 007f 0007  ac9a73e8 007f c6e64aa0 007f
3f00: 37770e00 3c220354 c7e1d300 007f 001d  ffe8 ff80
3f20: c6e64b90 007f c6e64b90 007f ac9a00b0 007f ac9a00b0 007f
3f40: ac9a00b0 007f ac9a00b0 007f ac9bec98 007f ac8b9cb0 007f
3f60: ac97383c 007f c7e1d200 007f c7e1d2d0 007f c7e1d300 007f
3f80: ac9a6000 007f c7e1d380 007f ac9a00b0 007f ac9a00b0 007f

[PATCH char-misc-next 4/8] misc: mic: Add data structures for the VOP driver

[Sudeep Dutt]

This patch adds VOP driver data structures used in subsequent
patches. These data structures are refactored from similar data
structures used in the virtio parts of previous MIC host and card
drivers.

Signed-off-by: Ashutosh Dixit 
Signed-off-by: Sudeep Dutt 
---
 drivers/misc/mic/vop/vop_main.h | 170 
 1 file changed, 170 insertions(+)
 create mode 100644 drivers/misc/mic/vop/vop_main.h

diff --git a/drivers/misc/mic/vop/vop_main.h b/drivers/misc/mic/vop/vop_main.h
new file mode 100644
index 000..ba47ec7
--- /dev/null
+++ b/drivers/misc/mic/vop/vop_main.h
@@ -0,0 +1,170 @@
+/*
+ * Intel MIC Platform Software Stack (MPSS)
+ *
+ * Copyright(c) 2016 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * The full GNU General Public License is included in this distribution in
+ * the file called "COPYING".
+ *
+ * Intel Virtio Over PCIe (VOP) driver.
+ *
+ */
+#ifndef _VOP_MAIN_H_
+#define _VOP_MAIN_H_
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include "../common/mic_dev.h"
+
+#include "../bus/vop_bus.h"
+
+/*
+ * Note on endianness.
+ * 1. Host can be both BE or LE
+ * 2. Guest/card is LE. Host uses le_to_cpu to access desc/avail
+ *rings and ioreadXX/iowriteXX to access used ring.
+ * 3. Device page exposed by host to guest contains LE values. Guest
+ *accesses these using ioreadXX/iowriteXX etc. This way in general we
+ *obey the virtio spec according to which guest works with native
+ *endianness and host is aware of guest endianness and does all
+ *required endianness conversion.
+ * 4. Data provided from user space to guest (in ADD_DEVICE and
+ *CONFIG_CHANGE ioctl's) is not interpreted by the driver and should be
+ *in guest endianness.
+ */
+
+/*
+ * vop_info - Allocated per invocation of VOP probe
+ *
+ * @vpdev: VOP device
+ * @hotplug_work: Handle virtio device creation, deletion and configuration
+ * @cookie: Cookie received upon requesting a virtio configuration interrupt
+ * @h2c_config_db: The doorbell used by the peer to indicate a config change
+ * @vdev_list: List of "active" virtio devices injected in the peer node
+ * @vop_mutex: Synchronize access to the device page as well as serialize
+ * creation/deletion of virtio devices on the peer node
+ * @dp: Peer device page information
+ * @dbg: Debugfs entry
+ * @dma_ch: The DMA channel used by this transport for data transfers.
+ * @name: Name for this transport used in misc device creation.
+ * @miscdev: The misc device registered.
+ */
+struct vop_info {
+   struct vop_device *vpdev;
+   struct work_struct hotplug_work;
+   struct mic_irq *cookie;
+   int h2c_config_db;
+   struct list_head vdev_list;
+   struct mutex vop_mutex;
+   void __iomem *dp;
+   struct dentry *dbg;
+   struct dma_chan *dma_ch;
+   char name[16];
+   struct miscdevice miscdev;
+};
+
+/**
+ * struct vop_vringh - Virtio ring host information.
+ *
+ * @vring: The VOP vring used for setting up user space mappings.
+ * @vrh: The host VRINGH used for accessing the card vrings.
+ * @riov: The VRINGH read kernel IOV.
+ * @wiov: The VRINGH write kernel IOV.
+ * @head: The VRINGH head index address passed to vringh_getdesc_kern(..).
+ * @vr_mutex: Mutex for synchronizing access to the VRING.
+ * @buf: Temporary kernel buffer used to copy in/out data
+ * from/to the card via DMA.
+ * @buf_da: dma address of buf.
+ * @vdev: Back pointer to VOP virtio device for vringh_notify(..).
+ */
+struct vop_vringh {
+   struct mic_vring vring;
+   struct vringh vrh;
+   struct vringh_kiov riov;
+   struct vringh_kiov wiov;
+   u16 head;
+   struct mutex vr_mutex;
+   void *buf;
+   dma_addr_t buf_da;
+   struct vop_vdev *vdev;
+};
+
+/**
+ * struct vop_vdev - Host information for a card Virtio device.
+ *
+ * @virtio_id - Virtio device id.
+ * @waitq - Waitqueue to allow ring3 apps to poll.
+ * @vpdev - pointer to VOP bus device.
+ * @poll_wake - Used for waking up threads blocked in poll.
+ * @out_bytes - Debug stats for number of bytes copied from host to card.
+ * @in_bytes - Debug stats for number of bytes copied from card to host.
+ * @out_bytes_dma - Debug stats for number of bytes copied from host to card
+ * using DMA.
+ * @in_bytes_dma - Debug stats for number of bytes copied from card to host
+ * using DMA.
+ * @tx_len_unaligned - Debug stats for number of bytes copied to the card where
+ * the transfer length did not have the required DMA alignment.
+ * @tx_dst_unaligned - Debug stats 

Re: [PATCH] netfilter: nft_ct: define nft_ct_get_eval_counter() only when needed

[Florian Westphal]

Eric Biggers  wrote:
> This eliminates an "unused function" compiler warning when
> CONFIG_NF_CONNTRACK_LABELS is not defined.
> 
> Signed-off-by: Eric Biggers 

The nft_ct_get_eval_counter call should've been unconditional.
The #endif placement is wrong:

https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit?id=efaea94aaf0decd55b15aa7068d4d516a352e56e

RE: [PATCH v2 17/17] drivers:mtd:ubi: Kconfig Makefile

[beanhuo]

> Hi Bean,
> 
> [auto build test WARNING on v4.5-rc2]

This version 2.0 patches are based on 4.2-rc7.

> [also build test WARNING on next-20160201] [if your patch is applied to the
> wrong git tree, please drop us a note to help improving the system]

linux-next: Tree for Feb 2

[Stephen Rothwell]

Hi all,

Changes since 20160201:

The btrfs-kdave gained a conflict against Linus' tree and a build failure
so I used the version from next-20160201.

The rcu tree lost its build failure.

The gpio tree still had its build failure so I used the version from
next-20160128.

The aio tree still had a build failure so I used the version from
next-20160111.

Non-merge commits (relative to Linus' tree): 2051
 2060 files changed, 75683 insertions(+), 34139 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (36f90b0a2ddd Linux 4.5-rc2)
Merging fixes/master (92e963f50fc7 Linux 4.5-rc1)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (74bf8efb5fa6 Linux 4.4-rc7)
Merging arm-current/fixes (03590cb56d5d ARM: wire up copy_file_range() syscall)
Merging m68k-current/for-linus (daf670bc9d36 m68k/defconfig: Update defconfigs 
for v4.5-rc1)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-fixes/fixes (19f97c983071 powerpc/book3s_32: Fix build error 
with checkpoint restart)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (1a40b95374f6 sparc: Fix system call tracing register 
handling.)
Merging net/master (53729eb174c1 Merge branch 'for-upstream' of 
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth)
Merging ipsec/master (a8a572a6b5f2 xfrm: dst_entries_init() per-net dst_ops)
Merging ipvs/master (b16c29191dc8 netfilter: nf_conntrack: use safer way to 
lock all buckets)
Merging wireless-drivers/master (f9ead9beef3f Merge tag 
'iwlwifi-for-kalle-2016-01-26_2' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (f39ea2690bd6 mac80211: fix use of uninitialised values 
in RX aggregation)
Merging sound-current/for-linus (cc85f7a634cf ALSA: rawmidi: Remove kernel 
WARNING for NULL user-space buffer check)
Merging pci-current/for-linus (c43e4b52cbf2 PCI: iproc: Fix BCMA PCIe bus 
scanning regression)
Merging driver-core.current/driver-core-linus (36f90b0a2ddd Linux 4.5-rc2)
Merging tty.current/tty-linus (36f90b0a2ddd Linux 4.5-rc2)
Merging usb.current/usb-linus (36f90b0a2ddd Linux 4.5-rc2)
Merging usb-gadget-fixes/fixes (36f90b0a2ddd Linux 4.5-rc2)
Merging usb-serial-fixes/usb-linus (4152b387da81 USB: option: fix Cinterion 
AHxx enumeration)
Merging usb-chipidea-fixes/ci-for-usb-stable (6f51bc340d2a usb: chipidea: imx: 
fix a possible NULL dereference)
Merging staging.current/staging-linus (5982557ac6ee Merge tag 
'iio-fixes-for-4.5b' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio 
into staging-linus)
Merging char-misc.current/char-misc-linus (92e963f50fc7 Linux 4.5-rc1)
Merging input-current/for-linus (d4f1b06d685d Input: vmmouse - fix absolute 
device registration)
Merging crypto-current/master (49a20454e0eb crypto: atmel-aes - remove calls of 
clk_prepare() from atomic contexts)
Merging ide/master (e04a2bd6d8c9 drivers/ide: make ide-scan-pci.c driver 
explicitly non-modular)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put_addr())
Merging 

Re: [PATCH/RFC] VFS: Improve fairness when locking the per-superblock s_anon list

[NeilBrown]

On Tue, Feb 02 2016, J. Bruce Fields wrote:

> On Fri, Jan 29, 2016 at 11:17:43AM +1100, NeilBrown wrote:
>> bit-spin-locks, as used for dcache hash chains, are not fair.
>> This is not a problem for the dcache hash table as different CPUs are
>> likely to access different entries in the hash table so high contention
>> is not expected.
>> However anonymous dentryies (created by NFSD) all live on a single hash
>> chain "s_anon" and the bitlock on this can be highly contended, resulting
>> in soft-lockup warnings.
>
> Just out of curiosity, because I can't recall seeing complaints about
> warnings, when do you see it happen?  Server reboot, maybe?

Soft-lockup warnings.  Possibly some client might notice delays longer
than they should be, but the only actual complaints have been about the 
warnings.

>
> It should be hitting that __d_obtain_alias() case only when a filehandle
> lookup finds a file without a cached dentry, which is an important case
> to handle, but not normally what I'd expect to be the common case.  Am I
> forgetting something?

I don't think you are missing anything significant.  I too was somewhat
surprised that there would be enough contention to cause problems, but
the evidence was fairly conclusive (at two separate sites), and the
proposed fix made the symptoms disappear.

Maybe there are a great many different files being accessed and a lot of
memory pressure on the server keeps pushing them out of cache.  I find
that customers often have loads that have quite different from what I
might expect...

Thanks,
NeilBrown


>
> --b.
>
>> 
>> So introduce a global (fair) spinlock and take it before grabing the
>> bitlock on s_anon.  This provides fairness and makes the warnings go away.
>> 
>> We could alternately use s_inode_list_lock, or add another spinlock
>> to struct super_block.  Suggestions?
>> 
>> Signed-off-by: NeilBrown 
>> ---
>> 
>> Dave: I'd guess you would be against using the new s_inode_list_lock
>> for this because it is already highly contended - yes?
>> Is it worth adding another spinlock to 'struct super_block' ?
>> 
>> Thanks,
>> NeilBrown
>> 
>> 
>>  fs/dcache.c | 8 
>>  1 file changed, 8 insertions(+)
>> 
>> diff --git a/fs/dcache.c b/fs/dcache.c
>> index 92d5140de851..e83f1ac1540c 100644
>> --- a/fs/dcache.c
>> +++ b/fs/dcache.c
>> @@ -104,6 +104,8 @@ static unsigned int d_hash_shift __read_mostly;
>>  
>>  static struct hlist_bl_head *dentry_hashtable __read_mostly;
>>  
>> +static DEFINE_SPINLOCK(s_anon_lock);
>> +
>>  static inline struct hlist_bl_head *d_hash(const struct dentry *parent,
>>  unsigned int hash)
>>  {
>> @@ -490,10 +492,14 @@ void __d_drop(struct dentry *dentry)
>>  else
>>  b = d_hash(dentry->d_parent, dentry->d_name.hash);
>>  
>> +if (b == >d_sb->s_anon)
>> +spin_lock(_anon_lock);
>>  hlist_bl_lock(b);
>>  __hlist_bl_del(>d_hash);
>>  dentry->d_hash.pprev = NULL;
>>  hlist_bl_unlock(b);
>> +if (b == >d_sb->s_anon)
>> +spin_unlock(_anon_lock);
>>  dentry_rcuwalk_invalidate(dentry);
>>  }
>>  }
>> @@ -1978,9 +1984,11 @@ static struct dentry *__d_obtain_alias(struct inode 
>> *inode, int disconnected)
>>  spin_lock(>d_lock);
>>  __d_set_inode_and_type(tmp, inode, add_flags);
>>  hlist_add_head(>d_u.d_alias, >i_dentry);
>> +spin_lock(_anon_lock);
>>  hlist_bl_lock(>d_sb->s_anon);
>>  hlist_bl_add_head(>d_hash, >d_sb->s_anon);
>>  hlist_bl_unlock(>d_sb->s_anon);
>> +spin_unlock(_anon_lock);
>>  spin_unlock(>d_lock);
>>  spin_unlock(>i_lock);
>>  security_d_instantiate(tmp, inode);
>> -- 
>> 2.7.0
>> 


signature.asc
Description: PGP signature

Re: [PATCH v2 17/17] drivers:mtd:ubi: Kconfig Makefile

[kbuild test robot]

Hi Bean,

[auto build test WARNING on v4.5-rc2]
[also build test WARNING on next-20160201]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Bean-Huo/Add-a-bakvol-module-in-UBI-layer-for-MLC-paired-page-power-loss-issue/20160202-104450


coccinelle warnings: (new ones prefixed by >>)

>> drivers/mtd/ubi/bakvol.c:862:17-28: ERROR: ubi -> bkblk_tbl is NULL but 
>> dereferenced.
--
>> drivers/mtd/ubi/bakvol.c:1211:1-15: ERROR: reference preceded by free on 
>> line 1210
   drivers/mtd/ubi/bakvol.c:862:1-15: ERROR: reference preceded by free on line 
855

vim +862 drivers/mtd/ubi/bakvol.c

3b3521fb Bean Huo 2016-02-02  846  out0:
3b3521fb Bean Huo 2016-02-02  847   kfree(oob_ops_src->oobbuf);
3b3521fb Bean Huo 2016-02-02  848  out_oob_ops:
3b3521fb Bean Huo 2016-02-02  849   kfree(oob_ops_src);
3b3521fb Bean Huo 2016-02-02  850  out_obs_src:
3b3521fb Bean Huo 2016-02-02  851   kfree(oob_ops_bak->oobbuf);
3b3521fb Bean Huo 2016-02-02  852  out_back_oob_ops:
3b3521fb Bean Huo 2016-02-02  853   kfree(oob_ops_bak);
3b3521fb Bean Huo 2016-02-02  854  out_backup_info:
3b3521fb Bean Huo 2016-02-02  855   kfree(ubi->bkblk_tbl);
3b3521fb Bean Huo 2016-02-02  856  out_vidh:
3b3521fb Bean Huo 2016-02-02  857   ubi_free_vid_hdr(ubi, vidh);
3b3521fb Bean Huo 2016-02-02  858  out_ech:
3b3521fb Bean Huo 2016-02-02  859   kfree(ech);
3b3521fb Bean Huo 2016-02-02  860  out_init:
3b3521fb Bean Huo 2016-02-02  861   ubi_err(ubi, "bakvol module init 
error,init step [%d].\n", step);
3b3521fb Bean Huo 2016-02-02 @862   ubi->bkblk_tbl->bakvol_flag = 
UBI_BAKVOL_REJECT;
3b3521fb Bean Huo 2016-02-02  863   return -1;
3b3521fb Bean Huo 2016-02-02  864  }
3b3521fb Bean Huo 2016-02-02  865  
3b3521fb Bean Huo 2016-02-02  866  /**
3b3521fb Bean Huo 2016-02-02  867   * ubi_bakvol_peb_scan - check VID 
header,see if this PEB
3b3521fb Bean Huo 2016-02-02  868   *   belongs to 
bakvol
3b3521fb Bean Huo 2016-02-02  869   *
3b3521fb Bean Huo 2016-02-02  870   * This function returns 1 if this PEB not 
belongs to bakvol

:: The code at line 862 was first introduced by commit
:: 3b3521fb6dda26424b36620d13e0195a5b4930b0 driver:mtd:ubi:add new bakvol 
module in ubi layer

:: TO: Bean Huo 
:: CC: 0day robot 

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

Re: [PATCH v2 17/17] drivers:mtd:ubi: Kconfig Makefile

[kbuild test robot]

Hi Bean,

[auto build test WARNING on v4.5-rc2]
[also build test WARNING on next-20160201]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Bean-Huo/Add-a-bakvol-module-in-UBI-layer-for-MLC-paired-page-power-loss-issue/20160202-104450
config: x86_64-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   include/linux/compiler.h:228:8: sparse: attribute 'no_sanitize_address': 
unknown attribute
   In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from drivers/mtd/ubi/bakvol.c:35:
   drivers/mtd/ubi/bakvol.c: In function 'ubi_duplicate_data_to_bakvol':
   include/linux/kern_levels.h:4:18: warning: format '%d' expects argument of 
type 'int', but argument 5 has type 'size_t {aka long unsigned int}' [-Wformat=]
#define KERN_SOH "\001"  /* ASCII Start Of Header */
 ^
   include/linux/kern_levels.h:10:18: note: in expansion of macro 'KERN_SOH'
#define KERN_ERR KERN_SOH "3" /* error conditions */
 ^
   include/linux/printk.h:252:9: note: in expansion of macro 'KERN_ERR'
 printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
^
   drivers/mtd/ubi/ubi.h:59:32: note: in expansion of macro 'pr_err'
#define ubi_err(ubi, fmt, ...) pr_err(UBI_NAME_STR "%d error: %s: " fmt 
"\n", \
   ^
>> drivers/mtd/ubi/bakvol.c:651:3: note: in expansion of macro 'ubi_err'
  ubi_err(ubi, "%d: Write data len overflow [%d]\n",
  ^

vim +/ubi_err +651 drivers/mtd/ubi/bakvol.c

3b3521fb Bean Huo 2016-02-02  635   * @buf: data buffer, points to data that 
should be programmed
3b3521fb Bean Huo 2016-02-02  636   */
3b3521fb Bean Huo 2016-02-02  637  int ubi_duplicate_data_to_bakvol(struct 
ubi_device *ubi, loff_t addr,
3b3521fb Bean Huo 2016-02-02  638   size_t len, 
size_t *retlen, const void *buf)
3b3521fb Bean Huo 2016-02-02  639  {
3b3521fb Bean Huo 2016-02-02  640   struct ubi_bkblk_tbl *backup_info = 
ubi->bkblk_tbl;
3b3521fb Bean Huo 2016-02-02  641   struct mtd_info *mtd = ubi->mtd;
3b3521fb Bean Huo 2016-02-02  642   int err = 0, nobak = 0;
3b3521fb Bean Huo 2016-02-02  643   int pnum;
3b3521fb Bean Huo 2016-02-02  644   u8 oppe_plane;
3b3521fb Bean Huo 2016-02-02  645   loff_t lpage_addr; /* Lower page byte 
address */
3b3521fb Bean Huo 2016-02-02  646   struct ubi_bkblk_info *pbk;
3b3521fb Bean Huo 2016-02-02  647   int page_num;
3b3521fb Bean Huo 2016-02-02  648   struct bakvol_oob_info *oob_bak = NULL, 
*oob_src = NULL;
3b3521fb Bean Huo 2016-02-02  649  
3b3521fb Bean Huo 2016-02-02  650   if (len > ubi->min_io_size) {
3b3521fb Bean Huo 2016-02-02 @651   ubi_err(ubi, "%d: Write data 
len overflow [%d]\n",
3b3521fb Bean Huo 2016-02-02  652   
__LINE__, len);
3b3521fb Bean Huo 2016-02-02  653   return -EROFS;
3b3521fb Bean Huo 2016-02-02  654   }
3b3521fb Bean Huo 2016-02-02  655  
3b3521fb Bean Huo 2016-02-02  656   if (!buf) {
3b3521fb Bean Huo 2016-02-02  657   ubi_err(ubi, "%d: Write buf is 
NULL!\n", __LINE__);
3b3521fb Bean Huo 2016-02-02  658   return -EROFS;
3b3521fb Bean Huo 2016-02-02  659  

:: The code at line 651 was first introduced by commit
:: 3b3521fb6dda26424b36620d13e0195a5b4930b0 driver:mtd:ubi:add new bakvol 
module in ubi layer

:: TO: Bean Huo 
:: CC: 0day robot 

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


.config.gz
Description: Binary data

Re: [RFC][PATCH] mips: Fix arch_spin_unlock()

[Paul E. McKenney]

On Mon, Feb 01, 2016 at 01:56:22PM +, Will Deacon wrote:
> On Fri, Jan 29, 2016 at 02:22:53AM -0800, Paul E. McKenney wrote:
> > On Fri, Jan 29, 2016 at 09:59:59AM +, Will Deacon wrote:
> > > On Thu, Jan 28, 2016 at 02:31:31PM -0800, Paul E. McKenney wrote:
> > 
> > [ . . . ]
> > 
> > > > For Linux in general, this is a question: How strict do we want to be
> > > > about matching the type of write with the corresponding read?  My
> > > > default approach is to initially be quite strict and loosen as needed.
> > > > Here "quite strict" might mean requiring an rcu_assign_pointer() for
> > > > the write and rcu_dereference() for the read, as opposed to (say)
> > > > ACCESS_ONCE() for the read.  (I am guessing that this would be too
> > > > tight, but it makes a good example.)
> > > > 
> > > > Thoughts?
> > > 
> > > That sounds broadly sensible to me and allows rcu_assign_pointer and
> > > rcu_dereference to be used as drop-in replacements for release/acquire
> > > where local transitivity isn't required. However, I don't think we can
> > > rule out READ_ONCE/WRITE_ONCE interactions as they seem to be used
> > > already in things like the osq_lock (albeit without the address
> > > dependency).
> > 
> > Agreed.  So in the most strict case that I can imagine anyone putting
> > up with, we have the following pairings:
> 
> I think we can group these up:
> 
> Locally transitive:
> 
> > o   smp_store_release() -> smp_load_acquire() (locally transitive)
> 
> Locally transitive chain termination:
> 
> (i.e. these can't be used to extend a chain)

Agreed.

> > o   smp_store_release() -> lockless_dereference() (???)
> > o   rcu_assign_pointer() -> rcu_dereference()
> > o   smp_store_release() -> READ_ONCE(); if

I am OK with the first and last, but I believe that the middle one
has real use cases.  So the rcu_assign_pointer() -> rcu_dereference()
case needs to be locally transitive.

> Globally transitive:
> 
> > o   smp_mb(); WRITE_ONCE() -> READ_ONCE(); (globally transitive)
> > o   synchronize_rcu(); WRITE_ONCE() -> READ_ONCE(); (globally transitive)
> 
> RCU:
> 
> > o   synchronize_rcu(); WRITE_ONCE() -> rcu_read_lock(); READ_ONCE()
> > (strange and wonderful properties)

Agreed.

> > Seem reasonable, or am I missing some?
> 
> Looks alright to me.

So I have some litmus tests to generate.  ;-)

Thnax, Paul

Re: [lkp] [kallsyms] bf2d2b07db: kasan: GPF could be caused by NULL-ptr deref or user memory accessgeneral protection fault: 0000 [#1] general protection fault: 0000 [#1] PREEMPT PREEMPT KASANKASAN

[Guenter Roeck]

On 02/01/2016 04:20 PM, Andrew Morton wrote:

On Thu, 28 Jan 2016 09:12:15 +0800 kernel test robot 
 wrote:


FYI, we noticed the below changes on

https://git.linaro.org/people/ard.biesheuvel/linux-arm arm64-kaslr-v4a
commit bf2d2b07db19001ae0bd55826025b0ba47fae0c2 ("kallsyms: add support for relative 
offsets in kallsyms address table")


+---+++
|   | 2c4d21df0f | 
bf2d2b07db |
+---+++
| boot_successes| 10 | 0
  |
| boot_failures | 6  | 36   
  |
| Kernel_panic-not_syncing:Attempted_to_kill_init!exitcode= | 2  |  
  |
| IP-Config:Auto-configuration_of_network_failed| 4  |  
  |
| general_protection_fault:#[##]PREEMPT_PREEMPT_KASANKASAN  | 0  | 36   
  |
| general_protection_fault:#[##]| 0  | 36   
  |
| BUG:kernel_boot_hang  | 0  | 36   
  |
+---+++



[0.281636] kasan: CONFIG_KASAN_INLINE enabled

[0.282416] kasan: GPF could be caused by NULL-ptr deref or user memory 
access
[0.282416] kasan: GPF could be caused by NULL-ptr deref or user memory 
accessgeneral protection fault:  [#1] general protection fault:  [#1] 
PREEMPT PREEMPT KASANKASAN

[0.284561] Modules linked in:
[0.284561] Modules linked in:

[0.285136] CPU: 0 PID: 1 Comm: swapper Not tainted 4.5.0-rc1-00036-gbf2d2b0 
#1
[0.285136] CPU: 0 PID: 1 Comm: swapper Not tainted 4.5.0-rc1-00036-gbf2d2b0 
#1
[0.286438] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[0.286438] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[0.288000] task: 88000fcb ti: 88000fcb8000 task.ti: 
88000fcb8000
[0.288000] task: 88000fcb ti: 88000fcb8000 task.ti: 
88000fcb8000
[0.289287] RIP: 0010:[]


I'm not sufficiently familiar with KASAN to be able to interpret this.
Perhaps Andrey can shed some light?

The lack of symbol decoding is a problem.

CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_BASE_RELATIVE=y

It should be there.  Perhaps it is not because this error is itself
(possibly) related to kallsyms changes?



Probably. I had seen something similar (crash and no symbols) with an earlier 
version of the patch,
if the symbols were not created. There might be a message in the log, 
indicating that kallsyms
failed to generate the symbols.

Guenter

[PATCH v5 2/8] clk: rockchip: rk3036: fix and add node id for emac clock

[Caesar Wang]

From: zhengxing 

In the emac driver, we need to refer HCLK_MAC since there are
only 3PLLs (APLL/GPLL/DPLL) on the rk3036, most clock are under the
GPLL, and it is unable to provide the accurate rate for mac_ref which
need to 50MHz probability, we should let it under the DPLL and are
able to set the freq which integer multiples of 50MHz, so we add these
emac node for reference.

Signed-off-by: Xing Zheng 
Signed-off-by: Caesar Wang 

---

Changes in v5: None
Changes in v4:
- fix the commit, pick up from the
  https://patchwork.kernel.org/patch/7976631/.
- The emac parent shouldn't depend on the APLL. instead of DPLL.

 drivers/clk/rockchip/clk-rk3036.c  | 9 ++---
 include/dt-bindings/clock/rk3036-cru.h | 2 ++
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/rockchip/clk-rk3036.c 
b/drivers/clk/rockchip/clk-rk3036.c
index be71a41..701f702 100644
--- a/drivers/clk/rockchip/clk-rk3036.c
+++ b/drivers/clk/rockchip/clk-rk3036.c
@@ -343,8 +343,11 @@ static struct rockchip_clk_branch rk3036_clk_branches[] 
__initdata = {
RK2928_CLKSEL_CON(16), 0, 2, MFLAGS, 2, 5, DFLAGS,
RK2928_CLKGATE_CON(10), 5, GFLAGS),
 
-   COMPOSITE_NOGATE(0, "mac_pll_src", mux_pll_src_3plls_p, 0,
-   RK2928_CLKSEL_CON(21), 0, 2, MFLAGS, 9, 5, DFLAGS),
+   MUX(SCLK_MACPLL, "mac_pll_pre", mux_pll_src_3plls_p, 0,
+   RK2928_CLKSEL_CON(21), 0, 2, MFLAGS),
+   DIV(0, "mac_pll_src", "mac_pll_pre", 0,
+   RK2928_CLKSEL_CON(21), 9, 5, DFLAGS),
+
MUX(SCLK_MACREF, "mac_clk_ref", mux_mac_p, CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(21), 3, 1, MFLAGS),
 
@@ -404,7 +407,7 @@ static struct rockchip_clk_branch rk3036_clk_branches[] 
__initdata = {
GATE(HCLK_OTG1, "hclk_otg1", "hclk_peri", CLK_IGNORE_UNUSED, 
RK2928_CLKGATE_CON(7), 3, GFLAGS),
GATE(HCLK_I2S, "hclk_i2s", "hclk_peri", 0, RK2928_CLKGATE_CON(7), 2, 
GFLAGS),
GATE(0, "hclk_sfc", "hclk_peri", CLK_IGNORE_UNUSED, 
RK2928_CLKGATE_CON(3), 14, GFLAGS),
-   GATE(0, "hclk_mac", "hclk_peri", CLK_IGNORE_UNUSED, 
RK2928_CLKGATE_CON(3), 15, GFLAGS),
+   GATE(HCLK_MAC, "hclk_mac", "hclk_peri", 0, RK2928_CLKGATE_CON(3), 5, 
GFLAGS),
 
/* pclk_peri gates */
GATE(0, "pclk_peri_matrix", "pclk_peri", CLK_IGNORE_UNUSED, 
RK2928_CLKGATE_CON(4), 1, GFLAGS),
diff --git a/include/dt-bindings/clock/rk3036-cru.h 
b/include/dt-bindings/clock/rk3036-cru.h
index ebc7a7b..de44109 100644
--- a/include/dt-bindings/clock/rk3036-cru.h
+++ b/include/dt-bindings/clock/rk3036-cru.h
@@ -54,6 +54,7 @@
 #define SCLK_PVTM_VIDEO125
 #define SCLK_MAC   151
 #define SCLK_MACREF152
+#define SCLK_MACPLL153
 #define SCLK_SFC   160
 
 /* aclk gates */
@@ -92,6 +93,7 @@
 #define HCLK_SDMMC 456
 #define HCLK_SDIO  457
 #define HCLK_EMMC  459
+#define HCLK_MAC   460
 #define HCLK_I2S   462
 #define HCLK_LCDC  465
 #define HCLK_ROM   467
-- 
1.9.1

[PATCH v5 6/8] ASoC: rt5616: trivial: fix the typo

[Caesar Wang]

This patch fixes the trivial typo.

Run "scripts/checkpatch.pl -f --subjective xxx"
The enable more subjective tests.

Signed-off-by: Caesar Wang 

Cc:  alsa-de...@alsa-project.org
Cc:  Mark Brown 
Cc:  Bard Liao 

---

Changes in v5:
-Cc releated alsa experts.

Changes in v4:
- Add this patch included in kylin series patches.

 sound/soc/codecs/rt5616.c | 376 +++---
 1 file changed, 191 insertions(+), 185 deletions(-)

diff --git a/sound/soc/codecs/rt5616.c b/sound/soc/codecs/rt5616.c
index 1c10d8e..d4bdf9f 100644
--- a/sound/soc/codecs/rt5616.c
+++ b/sound/soc/codecs/rt5616.c
@@ -53,6 +53,7 @@ static const struct reg_sequence init_list[] = {
{RT5616_PR_BASE + 0x21, 0x4040},
{RT5616_PR_BASE + 0x23, 0x0004},
 };
+
 #define RT5616_INIT_REG_LEN ARRAY_SIZE(init_list)
 
 static const struct reg_default rt5616_reg[] = {
@@ -162,9 +163,8 @@ static bool rt5616_volatile_register(struct device *dev, 
unsigned int reg)
 
for (i = 0; i < ARRAY_SIZE(rt5616_ranges); i++) {
if (reg >= rt5616_ranges[i].range_min &&
-   reg <= rt5616_ranges[i].range_max) {
+   reg <= rt5616_ranges[i].range_max)
return true;
-   }
}
 
switch (reg) {
@@ -190,9 +190,8 @@ static bool rt5616_readable_register(struct device *dev, 
unsigned int reg)
 
for (i = 0; i < ARRAY_SIZE(rt5616_ranges); i++) {
if (reg >= rt5616_ranges[i].range_min &&
-   reg <= rt5616_ranges[i].range_max) {
+   reg <= rt5616_ranges[i].range_max)
return true;
-   }
}
 
switch (reg) {
@@ -307,45 +306,45 @@ static unsigned int bst_tlv[] = {
 static const struct snd_kcontrol_new rt5616_snd_controls[] = {
/* Headphone Output Volume */
SOC_DOUBLE("HP Playback Switch", RT5616_HP_VOL,
-   RT5616_L_MUTE_SFT, RT5616_R_MUTE_SFT, 1, 1),
+  RT5616_L_MUTE_SFT, RT5616_R_MUTE_SFT, 1, 1),
SOC_DOUBLE_TLV("HP Playback Volume", RT5616_HP_VOL,
-   RT5616_L_VOL_SFT, RT5616_R_VOL_SFT, 39, 1, out_vol_tlv),
+  RT5616_L_VOL_SFT, RT5616_R_VOL_SFT, 39, 1, out_vol_tlv),
/* OUTPUT Control */
SOC_DOUBLE("OUT Playback Switch", RT5616_LOUT_CTRL1,
-   RT5616_L_MUTE_SFT, RT5616_R_MUTE_SFT, 1, 1),
+  RT5616_L_MUTE_SFT, RT5616_R_MUTE_SFT, 1, 1),
SOC_DOUBLE("OUT Channel Switch", RT5616_LOUT_CTRL1,
-   RT5616_VOL_L_SFT, RT5616_VOL_R_SFT, 1, 1),
+  RT5616_VOL_L_SFT, RT5616_VOL_R_SFT, 1, 1),
SOC_DOUBLE_TLV("OUT Playback Volume", RT5616_LOUT_CTRL1,
-   RT5616_L_VOL_SFT, RT5616_R_VOL_SFT, 39, 1, out_vol_tlv),
+  RT5616_L_VOL_SFT, RT5616_R_VOL_SFT, 39, 1, out_vol_tlv),
 
/* DAC Digital Volume */
SOC_DOUBLE_TLV("DAC1 Playback Volume", RT5616_DAC1_DIG_VOL,
-   RT5616_L_VOL_SFT, RT5616_R_VOL_SFT,
-   175, 0, dac_vol_tlv),
+  RT5616_L_VOL_SFT, RT5616_R_VOL_SFT,
+  175, 0, dac_vol_tlv),
/* IN1/IN2 Control */
SOC_SINGLE_TLV("IN1 Boost Volume", RT5616_IN1_IN2,
-   RT5616_BST_SFT1, 8, 0, bst_tlv),
+  RT5616_BST_SFT1, 8, 0, bst_tlv),
SOC_SINGLE_TLV("IN2 Boost Volume", RT5616_IN1_IN2,
-   RT5616_BST_SFT2, 8, 0, bst_tlv),
+  RT5616_BST_SFT2, 8, 0, bst_tlv),
/* INL/INR Volume Control */
SOC_DOUBLE_TLV("IN Capture Volume", RT5616_INL1_INR1_VOL,
-   RT5616_INL_VOL_SFT, RT5616_INR_VOL_SFT,
-   31, 1, in_vol_tlv),
+  RT5616_INL_VOL_SFT, RT5616_INR_VOL_SFT,
+  31, 1, in_vol_tlv),
/* ADC Digital Volume Control */
SOC_DOUBLE("ADC Capture Switch", RT5616_ADC_DIG_VOL,
-   RT5616_L_MUTE_SFT, RT5616_R_MUTE_SFT, 1, 1),
+  RT5616_L_MUTE_SFT, RT5616_R_MUTE_SFT, 1, 1),
SOC_DOUBLE_TLV("ADC Capture Volume", RT5616_ADC_DIG_VOL,
-   RT5616_L_VOL_SFT, RT5616_R_VOL_SFT,
-   127, 0, adc_vol_tlv),
+  RT5616_L_VOL_SFT, RT5616_R_VOL_SFT,
+  127, 0, adc_vol_tlv),
 
/* ADC Boost Volume Control */
SOC_DOUBLE_TLV("ADC Boost Volume", RT5616_ADC_BST_VOL,
-   RT5616_ADC_L_BST_SFT, RT5616_ADC_R_BST_SFT,
-   3, 0, adc_bst_tlv),
+  RT5616_ADC_L_BST_SFT, RT5616_ADC_R_BST_SFT,
+  3, 0, adc_bst_tlv),
 };
 
 static int is_sys_clk_from_pll(struct snd_soc_dapm_widget *source,
-struct snd_soc_dapm_widget *sink)
+  struct snd_soc_dapm_widget *sink)
 {
unsigned int val;
 
@@ -462,20 +461,20 @@ static const struct snd_kcontrol_new 

[PATCH v5 7/8] ASoC: rt5616: add the mclk for the codec driver

[Caesar Wang]

This patch adds the code to enable the clock to the CODEC driver
if it needs the clock enabled.

In some case, We need to claim the clock which is driving the codec
so that when we enable clock gating, we continue to clock the codec
when needed.

We can enable and disable the clock source if mclk provided.

Signed-off-by: Caesar Wang 
Cc:  alsa-de...@alsa-project.org
Cc:  Mark Brown 
Cc:  Bard Liao 

---

Changes in v5:
- Cc related alsa experts.

Changes in v4:
- AS the previous discussed by them, add the mclk for codec.
  (https://patchwork.kernel.org/patch/8041001/)

 sound/soc/codecs/rt5616.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/sound/soc/codecs/rt5616.c b/sound/soc/codecs/rt5616.c
index d4bdf9f..fdca636 100644
--- a/sound/soc/codecs/rt5616.c
+++ b/sound/soc/codecs/rt5616.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -144,6 +145,7 @@ struct rt5616_priv {
struct snd_soc_codec *codec;
struct delayed_work patch_work;
struct regmap *regmap;
+   struct clk *mclk;
 
int sysclk;
int sysclk_src;
@@ -1159,7 +1161,34 @@ static int rt5616_set_dai_pll(struct snd_soc_dai *dai, 
int pll_id, int source,
 static int rt5616_set_bias_level(struct snd_soc_codec *codec,
 enum snd_soc_bias_level level)
 {
+   struct rt5616_priv *rt5616 = snd_soc_codec_get_drvdata(codec);
+   int ret;
+
switch (level) {
+
+   case SND_SOC_BIAS_ON:
+   break;
+
+   case SND_SOC_BIAS_PREPARE:
+   /*
+* SND_SOC_BIAS_PREPARE is called while preparing for a
+* transition to ON or away from ON. If current bias_level
+* is SND_SOC_BIAS_ON, then it is preparing for a transition
+* away from ON. Disable the clock in that case, otherwise
+* enable it.
+*/
+   if (IS_ERR(rt5616->mclk))
+   break;
+
+   if (snd_soc_codec_get_bias_level(codec) == SND_SOC_BIAS_ON) {
+   clk_disable_unprepare(rt5616->mclk);
+   } else {
+   ret = clk_prepare_enable(rt5616->mclk);
+   if (ret)
+   return ret;
+   }
+   break;
+
case SND_SOC_BIAS_STANDBY:
if (snd_soc_codec_get_bias_level(codec) == SND_SOC_BIAS_OFF) {
snd_soc_update_bits(codec, RT5616_PWR_ANLG1,
@@ -1198,6 +1227,11 @@ static int rt5616_probe(struct snd_soc_codec *codec)
 {
struct rt5616_priv *rt5616 = snd_soc_codec_get_drvdata(codec);
 
+   /* Check if MCLK provided */
+   rt5616->mclk = devm_clk_get(codec->dev, "mclk");
+   if (PTR_ERR(rt5616->mclk) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+
rt5616->codec = codec;
 
return 0;
-- 
1.9.1

[PATCH v5 5/8] ASoC: rt5616: add mclk property for rt5616 document

[Caesar Wang]

This patch adds the mclk property for the CODEC driver,
since sometimes the CODEC driver needs the clock enabled.

The system clock of ALC5616 can be selected from MCLK,
That also makes the codec the master clock provider.

Signed-off-by: Caesar Wang 
Acked-by: Rob Herring 

Cc:  alsa-de...@alsa-project.org
Cc:  Mark Brown 
Cc:  Bard Liao 

---

Changes in v5:
- Fix the wrong word, as the Rob comments on
  https://patchwork.kernel.org/patch/8147731/.
- Cc the related alsa experts.

Changes in v4:
- Add this patch included in kylin series patches.

 Documentation/devicetree/bindings/sound/rt5616.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/rt5616.txt 
b/Documentation/devicetree/bindings/sound/rt5616.txt
index efc48c6..e410858 100644
--- a/Documentation/devicetree/bindings/sound/rt5616.txt
+++ b/Documentation/devicetree/bindings/sound/rt5616.txt
@@ -8,6 +8,12 @@ Required properties:
 
 - reg : The I2C address of the device.
 
+Optional properties:
+
+- clocks: The phandle of the master clock to the CODEC.
+
+- clock-names: Should be "mclk".
+
 Pins on the device (for linking into audio routes) for RT5616:
 
   * IN1P
-- 
1.9.1

[PATCH] arch/x86/kernel/cpu: Convert printk(KERN_ ...) to pr_(...)

[Chen Yucong]

 - Use the more current logging style pr_(...) instead of the old
   printk(KERN_ ...).
 - Convert pr_warning() to pr_warn().

Signed-off-by: Chen Yucong 
---
 arch/x86/kernel/cpu/amd.c   | 23 +++
 arch/x86/kernel/cpu/bugs_64.c   |  2 +-
 arch/x86/kernel/cpu/centaur.c   | 10 +++
 arch/x86/kernel/cpu/common.c| 42 +--
 arch/x86/kernel/cpu/cyrix.c | 10 +++
 arch/x86/kernel/cpu/hypervisor.c|  2 +-
 arch/x86/kernel/cpu/intel.c | 10 +++
 arch/x86/kernel/cpu/intel_cacheinfo.c   |  2 +-
 arch/x86/kernel/cpu/mcheck/mce-inject.c | 15 +-
 arch/x86/kernel/cpu/mcheck/p5.c | 18 +---
 arch/x86/kernel/cpu/mcheck/therm_throt.c| 15 +-
 arch/x86/kernel/cpu/mcheck/threshold.c  |  4 +--
 arch/x86/kernel/cpu/mcheck/winchip.c|  5 ++--
 arch/x86/kernel/cpu/microcode/amd.c |  2 +-
 arch/x86/kernel/cpu/mshyperv.c  |  8 +++---
 arch/x86/kernel/cpu/mtrr/centaur.c  |  2 +-
 arch/x86/kernel/cpu/mtrr/cleanup.c  | 44 ++---
 arch/x86/kernel/cpu/mtrr/generic.c  | 23 ---
 arch/x86/kernel/cpu/mtrr/main.c | 20 ++---
 arch/x86/kernel/cpu/perf_event.c|  9 +++---
 arch/x86/kernel/cpu/perf_event_amd_ibs.c| 10 +++
 arch/x86/kernel/cpu/perf_event_amd_uncore.c |  4 +--
 arch/x86/kernel/cpu/perf_event_intel_ds.c   |  6 ++--
 arch/x86/kernel/cpu/rdrand.c|  2 +-
 arch/x86/kernel/cpu/topology.c  |  4 +--
 arch/x86/kernel/cpu/transmeta.c |  8 +++---
 arch/x86/kernel/cpu/vmware.c|  5 ++--
 27 files changed, 146 insertions(+), 159 deletions(-)

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index a07956a..97c59fd 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -117,7 +117,7 @@ static void init_amd_k6(struct cpuinfo_x86 *c)
void (*f_vide)(void);
u64 d, d2;
 
-   printk(KERN_INFO "AMD K6 stepping B detected - ");
+   pr_info("AMD K6 stepping B detected - ");
 
/*
 * It looks like AMD fixed the 2.6.2 bug and improved indirect
@@ -133,10 +133,9 @@ static void init_amd_k6(struct cpuinfo_x86 *c)
d = d2-d;
 
if (d > 20*K6_BUG_LOOP)
-   printk(KERN_CONT
-   "system stability may be impaired when more 
than 32 MB are used.\n");
+   pr_cont("system stability may be impaired when more 
than 32 MB are used.\n");
else
-   printk(KERN_CONT "probably OK (after B9730).\n");
+   pr_cont("probably OK (after B9730).\n");
}
 
/* K6 with old style WHCR */
@@ -154,7 +153,7 @@ static void init_amd_k6(struct cpuinfo_x86 *c)
wbinvd();
wrmsr(MSR_K6_WHCR, l, h);
local_irq_restore(flags);
-   printk(KERN_INFO "Enabling old style K6 write 
allocation for %d Mb\n",
+   pr_info("Enabling old style K6 write allocation for %d 
Mb\n",
mbytes);
}
return;
@@ -175,7 +174,7 @@ static void init_amd_k6(struct cpuinfo_x86 *c)
wbinvd();
wrmsr(MSR_K6_WHCR, l, h);
local_irq_restore(flags);
-   printk(KERN_INFO "Enabling new style K6 write 
allocation for %d Mb\n",
+   pr_info("Enabling new style K6 write allocation for %d 
Mb\n",
mbytes);
}
 
@@ -202,7 +201,7 @@ static void init_amd_k7(struct cpuinfo_x86 *c)
 */
if (c->x86_model >= 6 && c->x86_model <= 10) {
if (!cpu_has(c, X86_FEATURE_XMM)) {
-   printk(KERN_INFO "Enabling disabled K7/SSE Support.\n");
+   pr_info("Enabling disabled K7/SSE Support.\n");
msr_clear_bit(MSR_K7_HWCR, 15);
set_cpu_cap(c, X86_FEATURE_XMM);
}
@@ -216,9 +215,8 @@ static void init_amd_k7(struct cpuinfo_x86 *c)
if ((c->x86_model == 8 && c->x86_mask >= 1) || (c->x86_model > 8)) {
rdmsr(MSR_K7_CLK_CTL, l, h);
if ((l & 0xfff0) != 0x2000) {
-   printk(KERN_INFO
-   "CPU: CLK_CTL MSR was %x. Reprogramming to %x\n",
-   l, ((l & 0x000f)|0x2000));
+   pr_info("CPU: CLK_CTL MSR was %x. Reprogramming to 
%x\n",
+   l, ((l & 0x000f)|0x2000));
wrmsr(MSR_K7_CLK_CTL, (l & 0x000f)|0x2000, h);
}
}

[PATCH v5 4/8] ARM: dts: rockchip: add mclk for rt5616 on kylin board

[Caesar Wang]

The I2S block that provide the output clock as the mclk for rt5616,
That will be the master clock  input.

Signed-off-by: Caesar Wang 

---

Changes in v5: None
Changes in v4:
- AS the previous discussed by them, add the mclk for codec.
 (https://patchwork.kernel.org/patch/8041001/)

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

diff --git a/arch/arm/boot/dts/rk3036-kylin.dts 
b/arch/arm/boot/dts/rk3036-kylin.dts
index cd45434..b0473bc 100644
--- a/arch/arm/boot/dts/rk3036-kylin.dts
+++ b/arch/arm/boot/dts/rk3036-kylin.dts
@@ -328,6 +328,8 @@
rt5616: rt5616@1b {
compatible = "rt5616";
reg = <0x1b>;
+   clocks = < SCLK_I2S_OUT>;
+   clock-names = "mclk";
#sound-dai-cells = <0>;
};
 };
-- 
1.9.1

[PATCH v5 8/8] ARM: dts: rockchip: support the spi for rk3036

[Caesar Wang]

This patch adds the needed spi node for rk3036 dts.

We have to use the 4 bus emmc to work if someone want to support
the spi devices, since the pins are re-used by emmc data[5-8] and spi.
In some caseswe need to support the spi devices, that will waste the
emmc performance.

Moment, the kylin/evb hasn't the spi devices to work, so maybe we need wait
the new required to enable in kylin/evb board.

Anyway, the spi should be needed land in rk3036 dts.

Signed-off-by: Caesar Wang 

---

Changes in v5:
- Remove the unused, as Heiko comments on 
https://patchwork.kernel.org/patch/8147761/
- Modify the commit.

Changes in v4:
- Add this patch included in kylin series patches.

 arch/arm/boot/dts/rk3036.dtsi | 40 
 1 file changed, 40 insertions(+)

diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index 532f232..30bb316 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -60,6 +60,7 @@
serial0 = 
serial1 = 
serial2 = 
+   spi = 
};
 
memory {
@@ -485,6 +486,21 @@
status = "disabled";
};
 
+   spi: spi@20074000 {
+   compatible = "rockchip,rockchip-spi";
+   reg = <0x20074000 0x1000>;
+   interrupts = ;
+   clocks =< PCLK_SPI>, < SCLK_SPI>;
+   clock-names = "apb-pclk","spi_pclk";
+   dmas = < 8>, < 9>;
+   dma-names = "tx", "rx";
+   pinctrl-names = "default";
+   pinctrl-0 = <_txd _rxd _clk _cs0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
pinctrl: pinctrl {
compatible = "rockchip,rk3036-pinctrl";
rockchip,grf = <>;
@@ -723,5 +739,29 @@
};
/* no rts / cts for uart2 */
};
+
+   spi {
+   spi_txd:spi-txd {
+   rockchip,pins = <1 29 RK_FUNC_3 
_pull_default>;
+   };
+
+   spi_rxd:spi-rxd {
+   rockchip,pins = <1 28 RK_FUNC_3 
_pull_default>;
+   };
+
+   spi_clk:spi-clk {
+   rockchip,pins = <2 0 RK_FUNC_2 
_pull_default>;
+   };
+
+   spi_cs0:spi-cs0 {
+   rockchip,pins = <1 30 RK_FUNC_3 
_pull_default>;
+
+   };
+
+   spi_cs1:spi-cs1 {
+   rockchip,pins = <1 31 RK_FUNC_3 
_pull_default>;
+
+   };
+   };
};
 };
-- 
1.9.1

[PATCH] clk: rockchip: free memory for error handle

[Shawn Lin]

Add free memeory if rockchip_clk_register_branch
failed.

Fixes: a245fecbb806 ("clk: rockchip: add basic infrastructure...")
Signed-off-by: Shawn Lin 
---

 drivers/clk/rockchip/clk.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/rockchip/clk.c b/drivers/clk/rockchip/clk.c
index d9a0b5d..62fbe2c 100644
--- a/drivers/clk/rockchip/clk.c
+++ b/drivers/clk/rockchip/clk.c
@@ -70,7 +70,7 @@ static struct clk *rockchip_clk_register_branch(const char 
*name,
if (gate_offset >= 0) {
gate = kzalloc(sizeof(*gate), GFP_KERNEL);
if (!gate)
-   return ERR_PTR(-ENOMEM);
+   goto err_gate;
 
gate->flags = gate_flags;
gate->reg = base + gate_offset;
@@ -82,7 +82,7 @@ static struct clk *rockchip_clk_register_branch(const char 
*name,
if (div_width > 0) {
div = kzalloc(sizeof(*div), GFP_KERNEL);
if (!div)
-   return ERR_PTR(-ENOMEM);
+   goto err_div;
 
div->flags = div_flags;
div->reg = base + muxdiv_offset;
@@ -100,6 +100,11 @@ static struct clk *rockchip_clk_register_branch(const char 
*name,
 flags);
 
return clk;
+err_div:
+   kfree(gate);
+err_gate:
+   kfree(mux);
+   return ERR_PTR(-ENOMEM);
 }
 
 struct rockchip_clk_frac {
-- 
2.3.7

[PATCH v5 1/8] ARM: dts: rockchip: add hdmi/vop device node for rk3036

[Caesar Wang]

This patch adds the needed display info for rk3036 SOCs.

The rk3036 support two overlay plane and one hwc plane,
it supports IOMMU, and its IOMMU same as rk3288's.
Meanwhile, add the inno hdmi for HDMI display.

Signed-off-by: Caesar Wang 

---

Changes in v5: None
Changes in v4:
- solve the lastest conflict, picked up from
  https://patchwork.kernel.org/patch/8040961/.

 arch/arm/boot/dts/rk3036-kylin.dts | 12 +++
 arch/arm/boot/dts/rk3036.dtsi  | 66 ++
 2 files changed, 78 insertions(+)

diff --git a/arch/arm/boot/dts/rk3036-kylin.dts 
b/arch/arm/boot/dts/rk3036-kylin.dts
index 3332a7f..1037ad6 100644
--- a/arch/arm/boot/dts/rk3036-kylin.dts
+++ b/arch/arm/boot/dts/rk3036-kylin.dts
@@ -116,6 +116,10 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
clock-frequency = <40>;
 
@@ -369,6 +373,14 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
+_mmu {
+   status = "okay";
+};
+
  {
leds {
led_ctl: led-ctl {
diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index 7897449..7abe3e2 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -147,6 +147,42 @@
};
};
 
+   vop: vop@10118000 {
+   compatible = "rockchip,rk3036-vop";
+   reg = <0x10118000 0x19c>;
+   interrupts = ;
+   clocks = < ACLK_LCDC>, < SCLK_LCDC>, < HCLK_LCDC>;
+   clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+   resets = < SRST_LCDC1_A>, < SRST_LCDC1_H>, < 
SRST_LCDC1_D>;
+   reset-names = "axi", "ahb", "dclk";
+   iommus = <_mmu>;
+
+   status = "disabled";
+
+   vop_out: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   vop_out_hdmi: endpoint@0 {
+   reg = <1>;
+   remote-endpoint = <_in_vop>;
+   };
+   };
+   };
+
+   display-subsystem {
+   compatible = "rockchip,display-subsystem";
+   ports = <_out>;
+   };
+
+   vop_mmu: iommu@10118300 {
+   compatible = "rockchip,iommu";
+   reg = <0x10118300 0x100>;
+   interrupts = ;
+   interrupt-names = "vop_mmu";
+   #iommu-cells = <0>;
+   status = "disabled";
+   };
+
gic: interrupt-controller@10139000 {
compatible = "arm,gic-400";
interrupt-controller;
@@ -274,6 +310,27 @@
status = "disabled";
};
 
+   hdmi: hdmi@20034000 {
+   compatible = "rockchip,rk3036-inno-hdmi";
+   reg = <0x20034000 0x4000>;
+   interrupts = ;
+   clocks = <  PCLK_HDMI>;
+   clock-names = "pclk";
+   rockchip,grf = <>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_ctl>;
+   status = "disabled";
+
+   hdmi_in: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   hdmi_in_vop: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_hdmi>;
+   };
+   };
+   };
+
timer: timer@20044000 {
compatible = "rockchip,rk3036-timer", "rockchip,rk3288-timer";
reg = <0x20044000 0x20>;
@@ -588,6 +645,15 @@
};
};
 
+   hdmi {
+   hdmi_ctl: hdmi-ctl {
+   rockchip,pins = <1 8  RK_FUNC_1 
_pull_none>,
+   <1 9  RK_FUNC_1 
_pull_none>,
+   <1 10 RK_FUNC_1 
_pull_none>,
+   <1 11 RK_FUNC_1 
_pull_none>;
+   };
+   };
+
uart0 {
uart0_xfer: uart0-xfer {
rockchip,pins = <0 16 RK_FUNC_1 
_pull_default>,
-- 
1.9.1