Re: linux-next - lockdep whine in MMC/SDHC code

2016-06-27 Thread Adrian Hunter
sdhci locking needs work because it is trying to use a spin lock to protect
the whole driver, which isn't possible (and consequently the lock gets
unlocked in the middle of some code) and also has the undesirable
side-effect of disabling irqs.  This looks like we should add another hack
to unlock the spin lock when mapping the sg.

Of course the proper fix is to figure out what actually needs to be
protected, but that will take longer.

On 27/06/16 20:44, Valdis Kletnieks wrote:
> This may be indicative of an actual problem, as I've had at least one
> time that subsequently mounting and then trying to access files on the
> partition caused kernel BUGs.
> 
> Seen in next-0614 and next-0627.  Google reports similar issues, but from
> the 2013/2014 timeframe
> 
> [2.610725] NET: Registered protocol family 10
> 
> [2.623472] ==
> [2.623548] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
> [2.623638] 4.7.0-rc4-next-20160627-dirty #303 Not tainted
> [2.623733] --
> [2.623817] kworker/2:1/49 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
> [2.623883]  (pcpu_alloc_mutex){+.+.+.}, at: [] 
> pcpu_alloc+0x4e5/0x890
> [2.623986]
>and this task is already holding:
> [2.624044]  (&(>lock)->rlock#3){-.-...}, at: [] 
> sdhci_request+0x56/0x200
> [2.624153] which would create a new lock dependency:
> [2.624203]  (&(>lock)->rlock#3){-.-...} -> 
> (pcpu_alloc_mutex){+.+.+.}
> [2.624305]
>but this new dependency connects a HARDIRQ-irq-safe lock:
> [2.624381]  (&(>lock)->rlock#3){-.-...}
>... which became HARDIRQ-irq-safe at:
> [2.624473]   [] __lock_acquire+0x6cd/0x1d60
> [2.624553]   [] lock_acquire+0x119/0x2d0
> [2.624661]   [] _raw_spin_lock+0x3b/0x50
> [2.624769]   [] sdhci_irq+0x3b/0xc20
> [2.624869]   [] __handle_irq_event_percpu+0x127/0x690
> [2.624993]   [] handle_irq_event_percpu+0x34/0xb0
> [2.625110]   [] handle_irq_event+0x4b/0xc0
> [2.625218]   [] handle_fasteoi_irq+0x14f/0x310
> [2.625347]   [] handle_irq+0xa6/0x2c0
> [2.625462]   [] do_IRQ+0x88/0x1b0
> [2.625571]   [] ret_from_intr+0x0/0x19
> [2.625683]   [] cpuidle_enter+0x17/0x20
> [2.625786]   [] cpu_startup_entry+0x54e/0x720
> [2.625910]   [] start_secondary+0x1a1/0x250
> [2.626035]
>to a HARDIRQ-irq-unsafe lock:
> [2.626129]  (pcpu_alloc_mutex){+.+.+.}
>... which became HARDIRQ-irq-unsafe at:
> [2.626283] ...  [] __lock_acquire+0x74c/0x1d60
> [2.626403]   [] lock_acquire+0x119/0x2d0
> [2.626522]   [] mutex_lock_nested+0x77/0x620
> [2.626648]   [] pcpu_alloc+0x4e5/0x890
> [2.626764]   [] __alloc_percpu+0x15/0x20
> [2.626883]   [] alloc_kmem_cache_cpus.isra.38+0x31/0x140
> [2.627029]   [] __do_tune_cpucache+0x3d/0x220
> [2.627145]   [] enable_cpucache+0x7f/0x160
> [2.627251]   [] kmem_cache_init_late+0x85/0x100
> [2.627379]   [] start_kernel+0x4b0/0x78f
> [2.627499]   [] x86_64_start_reservations+0x5a/0x7b
> [2.627637]   [] x86_64_start_kernel+0x343/0x38a
> [2.627765]
>other info that might help us debug this:
> 
> [2.627898]  Possible interrupt unsafe locking scenario:
> 
> [2.628031]CPU0CPU1
> [2.628123]
> [2.628213]   lock(pcpu_alloc_mutex);
> [2.628293]local_irq_disable();
> [2.628394]lock(&(>lock)->rlock#3);
> [2.628531]lock(pcpu_alloc_mutex);
> [2.628666]   
> [2.628714] lock(&(>lock)->rlock#3);
> [2.628823]
> *** DEADLOCK ***
> 
> [2.628924] 3 locks held by kworker/2:1/49:
> [2.628998]  #0:  ("events_freezable"){.+.+.+}, at: [] 
> process_one_work+0x329/0xd70
> [2.629196]  #1:  ((&(>detect)->work)){+.+.+.}, at: 
> [] process_one_work+0x329/0xd70
> [2.634773]  #2:  (&(>lock)->rlock#3){-.-...}, at: 
> [] sdhci_request+0x56/0x200
> [2.639936]
>the dependencies between HARDIRQ-irq-safe lock and the holding 
> lock:
> [2.650257] -> (&(>lock)->rlock#3){-.-...} ops: 205 {
> [2.655394]IN-HARDIRQ-W at:
> [2.660399] [] 
> __lock_acquire+0x6cd/0x1d60
> [2.665557] [] 
> lock_acquire+0x119/0x2d0
> [2.670735] [] 
> _raw_spin_lock+0x3b/0x50
> [2.675778] [] sdh

RE: [PATCH 2/4] dmaengine: vdma: Add support for mulit-channel dma mode

2016-06-27 Thread Appana Durga Kedareswara Rao
Hi Vinod,

Thanks for the review...

> > > > > >  /**
> > > > > > + * struct xilinx_mcdma_config - DMA Multi channel
> > > > > > +configuration structure
> > > > > > + * @tdest: Channel to operate on
> > > > > > + * @tid:   Channel configuration
> > > > > > + * @tuser: Tuser configuration
> > > > > > + * @ax_user: ax_user value
> > > > > > + * @ax_cache: ax_cache value
> > > > > > + */
> > > > > > +struct xilinx_mcdma_config {
> > > > > > +   u8 tdest;
> > > > > > +   u8 tid;
> > > > > > +   u8 tuser;
> > > > > > +   u8 ax_user;
> > > > > > +   u8 ax_cache;
> > > > >
> > > > > can you describe these in details, what do these do, what are
> > > > > the values to be programmed?
> > > >
> > > > As said above In Multi-Channel Mode each Stream interface can be
> > > > Configured up to 16 channels each channel is differentiated based
> > > > on the tdest
> > > and tid values.
> > >
> > > Then why are you not registering 16 channels for this? That should
> > > give you channel to operate on!
> >
> > The number of channels are configurable.
> > We are registering number of Channels that h/w configured for.
> >
> > Will fix in the next version. Will remove this config.
> > And based on the channel type will configure the h/w.
> 
> Looking at this you should redesign!
> 
> The vchan was designed to operate on 'virtual' channels. The hardware channels
> can be independent of that.
> 
> Your IP seems to be a good fit for that approach. Do not link the two and
> separate them. User can have a virtual channel. In your driver, you can manage
> hardware channels...

Fixed it in the v2 and posted the v2 series.
Please go thought it...

> 
> >
> > >
> > > >
> > > > tdest:
> > > > TDEST provides routing information for the data stream.
> > >
> > > pls elobrate
> >
> > Need to configure this with the channel number that We would like to
> > transfer data.
> 
> This should be internal to driver...

Fixed it in the v2 and posted the v2 series.
Please go thought it...

Regards,
Kedar.

> 
> --
> ~Vinod


[PATCH v2 4/9] tty: serial: fsl_lpuart: fix clearing of receive flag

2016-06-27 Thread Bhuvanchandra DV
From: Stefan Agner 

Commit 8e4934c6d6c6 ("tty: serial: fsl_lpuart: clear receive flag on FIFO
flush") implemented clearing of the receive flag by reading the status register
only. It turned out that even though we flush the FIFO afterwards, a explicit
read of the data register is still required.

This leads to a FIFO underrun. To avoid this, follow the advice in the overrun
"Operation section": Unconditionally clear RXUF after using RXFLUSH.

Signed-off-by: Stefan Agner 
Signed-off-by: Bhuvanchandra DV 
---
 drivers/tty/serial/fsl_lpuart.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index 75a2098..97c1fda 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -935,13 +935,16 @@ static void lpuart_setup_watermark(struct lpuart_port 
*sport)
writeb(val | UARTPFIFO_TXFE | UARTPFIFO_RXFE,
sport->port.membase + UARTPFIFO);
 
-   /* explicitly clear RDRF */
-   readb(sport->port.membase + UARTSR1);
-
/* flush Tx and Rx FIFO */
writeb(UARTCFIFO_TXFLUSH | UARTCFIFO_RXFLUSH,
sport->port.membase + UARTCFIFO);
 
+   /* explicitly clear RDRF */
+   if (readb(sport->port.membase + UARTSR1) & UARTSR1_RDRF) {
+   readb(sport->port.membase + UARTDR);
+   writeb(UARTSFIFO_RXUF, sport->port.membase + UARTSFIFO);
+   }
+
writeb(0, sport->port.membase + UARTTWFIFO);
writeb(1, sport->port.membase + UARTRWFIFO);
 
-- 
2.9.0



[PATCH v2 1/9] tty: serial: fsl_lpuart: consider TX FIFO too in tx_empty

2016-06-27 Thread Bhuvanchandra DV
From: Stefan Agner 

Currently the tx_empty callback only considers the Transmit Complete Flag (TC).
The reference manual is not quite clear if the TC flag covers the TX FIFO too.
Debug prints on real hardware have shown that from time to time the TC flag is
asserted (indicating Transmitter idle) while there are still data in the
TX FIFO. Hence, in this case the serial core will call the shutdown callback
even though there are data remaining in the TX FIFO buffers.

Avoid early shutdowns by considering the TX FIFO empty flag too. Also avoid
theoretical race conditions between DMA and the driver by checking whether the
TX DMA is in progress too.

Signed-off-by: Stefan Agner 
Signed-off-by: Bhuvanchandra DV 
---
 drivers/tty/serial/fsl_lpuart.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index 3d79003..fabfa7e 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -810,8 +810,18 @@ static irqreturn_t lpuart32_int(int irq, void *dev_id)
 /* return TIOCSER_TEMT when transmitter is not busy */
 static unsigned int lpuart_tx_empty(struct uart_port *port)
 {
-   return (readb(port->membase + UARTSR1) & UARTSR1_TC) ?
-   TIOCSER_TEMT : 0;
+   struct lpuart_port *sport = container_of(port,
+   struct lpuart_port, port);
+   unsigned char sr1 = readb(port->membase + UARTSR1);
+   unsigned char sfifo = readb(port->membase + UARTSFIFO);
+
+   if (sport->dma_tx_in_progress)
+   return 0;
+
+   if (sr1 & UARTSR1_TC && sfifo & UARTSFIFO_TXEMPT)
+   return TIOCSER_TEMT;
+
+   return 0;
 }
 
 static unsigned int lpuart32_tx_empty(struct uart_port *port)
-- 
2.9.0



Re: [PATCH net-next 6/9] net: hns: normalize two different loop

2016-06-27 Thread Daode Huang



On 2016/6/27 20:13, Andy Shevchenko wrote:

On Mon, 2016-06-27 at 05:08 -0700, Joe Perches wrote:

On Mon, 2016-06-27 at 15:00 +0300, Andy Shevchenko wrote:

On Mon, 2016-06-27 at 04:49 -0700, Joe Perches wrote:

On Mon, 2016-06-27 at 17:54 +0800, Yisen Zhuang wrote:

From: Daode Huang 

There are two approaches to assign data, one does 2 loops,
another
does 1 loop. This patch normalize the different methods to 1
loop.

[]

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c

[]

@@ -2567,15 +2567,15 @@ static char
*hns_dsaf_get_node_stats_strings(char *data, int node,
buff += ETH_GSTRING_LEN;
if (node < DSAF_SERVICE_NW_NUM && !is_ver1) {
for (i = 0; i < DSAF_PRIO_NR; i++) {
-   snprintf(buff, ETH_GSTRING_LEN,
-"inod%d_pfc_prio%d_pkts",
node,
i);
-   buff += ETH_GSTRING_LEN;
-   }
-   for (i = 0; i < DSAF_PRIO_NR; i++) {
-   snprintf(buff, ETH_GSTRING_LEN,
-"onod%d_pfc_prio%d_pkts",
node,
i);
+   snprintf(buff + 0 * ETH_GSTRING_LEN *
DSAF_PRIO_NR,
+ETH_GSTRING_LEN,
"inod%d_pfc_prio%d_pkts",
+node, i);
+   snprintf(buff + 1 * ETH_GSTRING_LEN *
DSAF_PRIO_NR,
+ETH_GSTRING_LEN,
"onod%d_pfc_prio%d_pkts",
+node, i);
buff += ETH_GSTRING_LEN;

This looks odd and likely incorrect.

Why? the idea is to print stats for Rx and Tx at once.

I hope it was tested.

It changes the order of the strings in buff.

I don't see how.

Hi Andy,
The patch has been tested when sent out.


Is a bug fix or a style fix?

If it's a bug fix, then it should likely be added
to the stable trees.

I doubt it's a bug fix.


Because the previous patch is accepted in net-next, and this set is
an appendix to the series, in order to avoid merge conflict, we also
send this bug fix to net-next.

thanks.








Re: [PATCH v3 1/3]nbd: fix might_sleep warning on socket shutdown

2016-06-27 Thread Pranay Srivastava
Hi Markus,

On Fri, Jun 24, 2016 at 3:39 PM, Pranay Kr. Srivastava
 wrote:
> spinlocked ranges should be small and not contain calls into huge
> subfunctions. Fix my mistake and just get the pointer to the socket
> instead of doing everything with spinlock held.
>
> Reported-by: Mikulas Patocka 
> Signed-off-by: Markus Pargmann 
>
> Changelog:
> Pranay Kr. Srivastava:
>
> 1) Use spin_lock instead of irq version for sock_shutdown.
>
> 2) Use system work queue to actually trigger the shutdown of
>socket. This solves the issue when kernel_sendmsg is currently
>blocked while a timeout occurs.
>
> Signed-off-by: Pranay Kr. Srivastava 
> ---
>  drivers/block/nbd.c | 69 
> ++---
>  1 file changed, 44 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
> index 56f7f5d..586d946 100644
> --- a/drivers/block/nbd.c
> +++ b/drivers/block/nbd.c
> @@ -39,6 +39,7 @@
>  #include 
>
>  #include 
> +#include 
>
>  struct nbd_device {
> u32 flags;
> @@ -69,6 +70,10 @@ struct nbd_device {
>  #if IS_ENABLED(CONFIG_DEBUG_FS)
> struct dentry *dbg_dir;
>  #endif
> +   /*
> +   *This is specifically for calling sock_shutdown, for now.
> +   */
> +   struct work_struct ws_shutdown;
>  };
>
>  #if IS_ENABLED(CONFIG_DEBUG_FS)
> @@ -95,6 +100,11 @@ static int max_part;
>   */
>  static DEFINE_SPINLOCK(nbd_lock);
>
> +/*
> + * Shutdown function for nbd_dev work struct.
> + */
> +static void nbd_ws_func_shutdown(struct work_struct *);
> +
>  static inline struct device *nbd_to_dev(struct nbd_device *nbd)
>  {
> return disk_to_dev(nbd->disk);
> @@ -172,39 +182,35 @@ static void nbd_end_request(struct nbd_device *nbd, 
> struct request *req)
>   */
>  static void sock_shutdown(struct nbd_device *nbd)
>  {
> -   spin_lock_irq(>sock_lock);
> -
> -   if (!nbd->sock) {
> -   spin_unlock_irq(>sock_lock);
> -   return;
> -   }
> +   struct socket *sock;
>
> -   dev_warn(disk_to_dev(nbd->disk), "shutting down socket\n");
> -   kernel_sock_shutdown(nbd->sock, SHUT_RDWR);
> -   sockfd_put(nbd->sock);
> +   spin_lock(>sock_lock);
> +   sock = nbd->sock;
> nbd->sock = NULL;
> -   spin_unlock_irq(>sock_lock);
> +   spin_unlock(>sock_lock);
> +
> +   if (!sock)
> +   return;
>
> del_timer(>timeout_timer);
> +   dev_warn(disk_to_dev(nbd->disk), "shutting down socket\n");
> +   kernel_sock_shutdown(sock, SHUT_RDWR);
> +   sockfd_put(sock);
>  }
>
>  static void nbd_xmit_timeout(unsigned long arg)
>  {
> struct nbd_device *nbd = (struct nbd_device *)arg;
> -   unsigned long flags;
>
> if (list_empty(>queue_head))
> return;
> -
> -   spin_lock_irqsave(>sock_lock, flags);
> -
> nbd->timedout = true;
> -
> -   if (nbd->sock)
> -   kernel_sock_shutdown(nbd->sock, SHUT_RDWR);
> -
> -   spin_unlock_irqrestore(>sock_lock, flags);
> -
> +   schedule_work(>ws_shutdown);
> +   /*
> +* Make sure sender thread sees nbd->timedout.
> +*/
> +   smp_wmb();
> +   wake_up(>waiting_wq);
> dev_err(nbd_to_dev(nbd), "Connection timed out, shutting down 
> connection\n");
>  }
>
> @@ -574,8 +580,8 @@ static int nbd_thread_send(void *data)
> while (!kthread_should_stop() || !list_empty(>waiting_queue)) {
> /* wait for something to do */
> wait_event_interruptible(nbd->waiting_wq,
> -kthread_should_stop() ||
> -!list_empty(>waiting_queue));
> +   kthread_should_stop() ||
> +   !list_empty(>waiting_queue));
>
> /* extract request */
> if (list_empty(>waiting_queue))
> @@ -583,12 +589,16 @@ static int nbd_thread_send(void *data)
>
> spin_lock_irq(>queue_lock);
> req = list_entry(nbd->waiting_queue.next, struct request,
> -queuelist);
> +   queuelist);
> list_del_init(>queuelist);
> spin_unlock_irq(>queue_lock);
>
> -   /* handle request */
> nbd_handle_req(nbd, req);
> +   if (nbd->timedout) {
> +   req->errors++;
> +   nbd_end_request(nbd, req);
> +   } else
> +   nbd_handle_req(nbd, req);
> }
>
> nbd->task_send = NULL;
> @@ -668,6 +678,7 @@ static void nbd_reset(struct nbd_device *nbd)
> set_capacity(nbd->disk, 0);
> nbd->flags = 0;
> nbd->xmit_timeout = 0;
> +   INIT_WORK(>ws_shutdown, nbd_ws_func_shutdown);
> 

Re: [PATCH] arc: warn only once if DW2_UNWIND is disabled

2016-06-27 Thread Alexey Brodkin
Hi Vineet,

On Tue, 2016-06-28 at 10:00 +0530, Vineet Gupta wrote:
> On Thursday 23 June 2016 01:30 PM, Alexey Brodkin wrote:
> > 
> > If CONFIG_ARC_DW2_UNWIND is disabled every time arc_unwind_core()
> > gets called following message gets printed in debug console:
> > ->8---
> > CONFIG_ARC_DW2_UNWIND needs to be enabled
> > ->8---
> > 
> > That message makes sense if user indeed wants to see a backtrace or
> > get nice function call-graphs in perf but what if user disabled
> > unwinder for the purpose? Why pollute his debug console?
> > 
> > So instead we'll warn user about possibly missing feature once and
> > let him decide if that was what he or she really wanted.
> > 
> > Signed-off-by: Alexey Brodkin 
> > Cc: sta...@vger.kernel.org  [3.18+]
>
> Does this really need to be stable backport ?

I think it makes perfect sense for any kernel version because
it saves debug console from being polluted with messages which
most probably have no point (Ok I disabled unwinder in kernel config,
why then spam me with proposals to enable it)?

-Alexey


Re: [PATCH 2/3] powerpc/spinlock: support vcpu preempted check

2016-06-27 Thread xinhui



On 2016年06月28日 13:03, Boqun Feng wrote:

On Tue, Jun 28, 2016 at 11:39:18AM +0800, xinhui wrote:
[snip]

+{
+   struct lppaca *lp = _of(cpu);
+
+   if (unlikely(!(lppaca_shared_proc(lp) ||
+   lppaca_dedicated_proc(lp


Do you want to detect whether we are running in a guest(ie. pseries
kernel) here? Then I wonder whether "machine_is(pseries)" works here.


I tried as you said yesterday. but .h file has dependencies.
As you said, if we add #ifdef PPC_PSERIES, this is not a big problem. only 
powernv will be affected as they are built into same kernel img.



I never said this it not a big problem ;-)

The problem here is that we only need to detect the vcpu preemption in
a guest, and there could be several ways we can detect whether the
kernel is running in a guest. It's worthwhile to try find the best one
for this. Besides, it's really better that you can make sure we are
runing out of options before you introduce something like
lppaca_dedicated_proc().

I have a feeling that yield_count is non-zero only if we are running in
a guest, if so, we can use this and save several loads. But surely we
need the confirmation from ppc maintainers.


yes, on powernv, print the lppaca.yield_count and it is always zero. looks like 
only hypervisor and os can touch/modify it.



Regards,
Boqun





Re: [PATCH 5/8] KEYS: Provide software public key query function [ver #2]

2016-06-27 Thread Herbert Xu
On Mon, Jun 27, 2016 at 03:27:13PM +0100, David Howells wrote:
> 
> I have some patches I need to finish revamping.  I had it kind of working
> (though with a slightly different user interface) - then TPMv2 support was
> added to the TPM driver before I finished and I need to redo the patches.

In that case can we wait until this is ready before pushing the
user-space interface? Once you add a user-space interface it's
very difficult to change it again so we should be absolutely sure
what it's supposed to  look like before we add a new interace.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


[RFC/PATCH v2] ftrace: Reduce size of function graph entries

2016-06-27 Thread Namhyung Kim
Currently ftrace_graph_ent{,_entry} and ftrace_graph_ret{,_entry} struct
can have padding bytes at the end due to alignment in 64-bit data type.
As these data are recorded so frequently, those paddings waste
non-negligible space.  As some archs can have efficient unaligned
accesses, reducing the alignment can save ~10% of data size:

  ftrace_graph_ent_entry:  24 -> 20
  ftrace_graph_ret_entry:  48 -> 44

Also I moved the 'overrun' field in struct ftrace_graph_ret to minimize
the padding.  I think the FTRACE_ALIGNMENT still needs to have proper
alignment (even if ring buffer handles the alignment after all) since
the ftrace_graph_ent/ret struct is located on stack before copying to
the ring buffer.

Tested on x86_64 only.

Cc: linux-a...@vger.kernel.org
Signed-off-by: Namhyung Kim 
---
 include/linux/ftrace.h   | 16 
 kernel/trace/trace.h | 11 +++
 kernel/trace/trace_entries.h |  4 ++--
 3 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index dea12a6e413b..a86cdf167419 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -751,25 +751,33 @@ extern void ftrace_init(void);
 static inline void ftrace_init(void) { }
 #endif
 
+#ifdef CONFIG_HAVE_64BIT_ALIGNED_ACCESS
+# define FTRACE_ALIGNMENT  8
+#else
+# define FTRACE_ALIGNMENT  4
+#endif
+
+#define FTRACE_ALIGN_DATA  __attribute__((packed, 
aligned(FTRACE_ALIGNMENT)))
+
 /*
  * Structure that defines an entry function trace.
  */
 struct ftrace_graph_ent {
unsigned long func; /* Current function */
int depth;
-};
+} FTRACE_ALIGN_DATA;
 
 /*
  * Structure that defines a return function trace.
  */
 struct ftrace_graph_ret {
unsigned long func; /* Current function */
-   unsigned long long calltime;
-   unsigned long long rettime;
/* Number of functions that overran the depth limit for current task */
unsigned long overrun;
+   unsigned long long calltime;
+   unsigned long long rettime;
int depth;
-};
+} FTRACE_ALIGN_DATA;
 
 /* Type of the callback handlers for tracing function graph*/
 typedef void (*trace_func_graph_ret_t)(struct ftrace_graph_ret *); /* return */
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 5167c366d6b7..d2dd49ca55ee 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -80,6 +80,12 @@ enum trace_type {
FTRACE_ENTRY(name, struct_name, id, PARAMS(tstruct), PARAMS(print), \
 filter)
 
+#undef FTRACE_ENTRY_PACKED
+#define FTRACE_ENTRY_PACKED(name, struct_name, id, tstruct, print, \
+   filter) \
+   FTRACE_ENTRY(name, struct_name, id, PARAMS(tstruct), PARAMS(print), \
+filter) FTRACE_ALIGN_DATA
+
 #include "trace_entries.h"
 
 /*
@@ -1600,6 +1606,11 @@ int set_tracer_flag(struct trace_array *tr, unsigned int 
mask, int enabled);
 #define FTRACE_ENTRY_DUP(call, struct_name, id, tstruct, print, filter)
\
FTRACE_ENTRY(call, struct_name, id, PARAMS(tstruct), PARAMS(print), \
 filter)
+#undef FTRACE_ENTRY_PACKED
+#define FTRACE_ENTRY_PACKED(call, struct_name, id, tstruct, print, filter) \
+   FTRACE_ENTRY(call, struct_name, id, PARAMS(tstruct), PARAMS(print), \
+filter)
+
 #include "trace_entries.h"
 
 #if defined(CONFIG_PERF_EVENTS) && defined(CONFIG_FUNCTION_TRACER)
diff --git a/kernel/trace/trace_entries.h b/kernel/trace/trace_entries.h
index ee7b94a4810a..5c30efcda5e6 100644
--- a/kernel/trace/trace_entries.h
+++ b/kernel/trace/trace_entries.h
@@ -72,7 +72,7 @@ FTRACE_ENTRY_REG(function, ftrace_entry,
 );
 
 /* Function call entry */
-FTRACE_ENTRY(funcgraph_entry, ftrace_graph_ent_entry,
+FTRACE_ENTRY_PACKED(funcgraph_entry, ftrace_graph_ent_entry,
 
TRACE_GRAPH_ENT,
 
@@ -88,7 +88,7 @@ FTRACE_ENTRY(funcgraph_entry, ftrace_graph_ent_entry,
 );
 
 /* Function return entry */
-FTRACE_ENTRY(funcgraph_exit, ftrace_graph_ret_entry,
+FTRACE_ENTRY_PACKED(funcgraph_exit, ftrace_graph_ret_entry,
 
TRACE_GRAPH_RET,
 
-- 
2.8.0



Re: [PATCH 1/2] ipc/sem.c: Fix complex_count vs. simple op race

2016-06-27 Thread Davidlohr Bueso

On Thu, 23 Jun 2016, Manfred Spraul wrote:


What I'm not sure yet is if smp_load_acquire() is sufficient:

Thread A:

  if (!READ_ONCE(sma->complex_mode)) {

The code is test_and_test, no barrier requirements for first test


Yeah, it would just make us take the big lock unnecessarily, nothing fatal
and I agree its probably worth the optimization. It still might be worth
commenting.


   /*
* It appears that no complex operation is around.
* Acquire the per-semaphore lock.
*/
   spin_lock(>lock);

   if (!smp_load_acquire(>complex_mode)) {
   /* fast path successful! */
   return sops->sem_num;
   }
   spin_unlock(>lock);
   }


Thread B:

  WRITE_ONCE(sma->complex_mode, true);

   /* We need a full barrier:
* The write to complex_mode must be visible
* before we read the first sem->lock spinlock state.
*/
   smp_mb();

   for (i = 0; i < sma->sem_nsems; i++) {
   sem = sma->sem_base + i;
   spin_unlock_wait(>lock);
   }


If thread A is allowed to issue read_spinlock;read complex_mode;write 
spinlock, then thread B would not notice that thread A is in the 
critical section


Are you referring to the sem->lock word not being visibly locked before we
read complex_mode (for the second time)? This issue was fixed in 2c610022711
(locking/qspinlock: Fix spin_unlock_wait() some more). So smp_load_acquire
should be enough afaict, or are you referring to something else?

Thanks,
Davidlohr


Re: [PATCH 0/4] ftrace: One more check on x86 and some small fixes

2016-06-27 Thread Namhyung Kim
On Mon, Jun 27, 2016 at 10:54 PM, Petr Mladek  wrote:
> 1st patch adds one more paranoid check of the modified function on x86.
>
> Plus there are 3 small changes that appeared when hunting down
> the 1st patch.

For the series,

Acked-by: Namhyung Kim 

Thanks,
Namhyung


>
> Petr Mladek (4):
>   ftrace/x86: Make sure to modify 5-bite instructions
>   ftrace/x86: Do not crash when reading wrong ftrace func
>   ftrace: Always destroy trampoline when shutting down the trace
>   ftrace: Fixup trace_selftest_ops()
>
>  arch/x86/kernel/ftrace.c  | 12 -
>  kernel/trace/ftrace.c | 62 
> ++-
>  kernel/trace/trace_selftest.c |  7 ++---
>  3 files changed, 47 insertions(+), 34 deletions(-)
>
> --
> 1.8.5.6
>


Re: [PATCH V3] tracing: Make latency tracers fully support the set_graph_notrace

2016-06-27 Thread Namhyung Kim
Hello,

On Fri, Jun 24, 2016 at 7:55 PM, Chunyu Hu  wrote:
> latency tracers(wakeup, wakeup_rt, wakeup_dl, irqsoff) can use the
> function_graph trace when display_graph trace option is set by user
> via tracefs. And currently the set_graph_notrace filter is not fully
> supported in latency tracers, only the graph_ret event can be filtered,
> the graph_ent events will always be submitted to the trace ring buffer
> without respecting to the filter.
>
> The issue is that the submitted graph_entry event that matches the
> filter can be assigned with a negative depth(minuts FTRACE_NOTRACE_DEPTH)
> which will be used as the array index of fgraph_cpu_data when printing
> trace entries, as a result, an oops can be hit when accessing the array.
>
> Fully supporting the set_graph_notrace filter in latency tracers can
> avoid this oops and provide a small enhancement for these tracers at
> the same time.
>
> To reproduce the oops:
> echo 1 > options/display_graph
> echo schedule > set_graph_notrace
> echo wakeup > current_tracer
> cat trace (several times)

I'm unabled to reproduce the oops even after running 'cat trace' multiple times.

Anyway, the patch looks good to me.

Acked-by: Namhyung Kim 

Thanks,
Namhyung


>
> Signed-off-by: Chunyu Hu 
> ---
>  kernel/trace/trace_irqsoff.c  | 6 ++
>  kernel/trace/trace_sched_wakeup.c | 6 ++
>  2 files changed, 12 insertions(+)
>
> diff --git a/kernel/trace/trace_irqsoff.c b/kernel/trace/trace_irqsoff.c
> index 03cdff8..a4ed46a 100644
> --- a/kernel/trace/trace_irqsoff.c
> +++ b/kernel/trace/trace_irqsoff.c
> @@ -175,6 +175,12 @@ static int irqsoff_graph_entry(struct ftrace_graph_ent 
> *trace)
> int ret;
> int pc;
>
> +   if (trace->depth < 0)
> +   return 0;
> +
> +   if (ftrace_graph_notrace_addr(trace->func))
> +   return 1;
> +
> if (!func_prolog_dec(tr, , ))
> return 0;
>
> diff --git a/kernel/trace/trace_sched_wakeup.c 
> b/kernel/trace/trace_sched_wakeup.c
> index 9d4399b..e54fff7 100644
> --- a/kernel/trace/trace_sched_wakeup.c
> +++ b/kernel/trace/trace_sched_wakeup.c
> @@ -239,6 +239,12 @@ static int wakeup_graph_entry(struct ftrace_graph_ent 
> *trace)
> unsigned long flags;
> int pc, ret = 0;
>
> +   if (trace->depth < 0)
> +   return 0;
> +
> +   if (ftrace_graph_notrace_addr(trace->func))
> +   return 1;
> +
> if (!func_prolog_preempt_disable(tr, , ))
> return 0;
>
> --
> 1.8.3.1
>


[PATCH v2 0/2] Add mt6755 basic chip support

2016-06-27 Thread Mars Cheng
This patch adds basic support for Mediatek's new 8-core chip, mt6755.
Based on 4.7-rc1

Changes in v2:
1. use evb as project suffix
2. add "disable" property for uart dts nodes
3. only alias uart0 as serial0, since we don't enable uart1

Mars Cheng (2):
  Document: DT: Add bindings for mediatek MT6755 SoC Platform
  arm64: dts: mediatek: add mt6755 support

 Documentation/devicetree/bindings/arm/mediatek.txt |4 +
 .../interrupt-controller/mediatek,sysirq.txt   |1 +
 .../devicetree/bindings/serial/mtk-uart.txt|1 +
 arch/arm64/boot/dts/mediatek/Makefile  |1 +
 arch/arm64/boot/dts/mediatek/mt6755-evb.dts|   38 +
 arch/arm64/boot/dts/mediatek/mt6755.dtsi   |  145 
 6 files changed, 190 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt6755-evb.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt6755.dtsi


[PATCH v2 1/2] Document: DT: Add bindings for mediatek MT6755 SoC Platform

2016-06-27 Thread Mars Cheng
This adds DT binding documentation for Mediatek MT6755.

Signed-off-by: Mars Cheng 
---
 Documentation/devicetree/bindings/arm/mediatek.txt |4 
 .../interrupt-controller/mediatek,sysirq.txt   |1 +
 .../devicetree/bindings/serial/mtk-uart.txt|1 +
 3 files changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt 
b/Documentation/devicetree/bindings/arm/mediatek.txt
index d9c2a37..c860b24 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek.txt
@@ -10,6 +10,7 @@ compatible: Must contain one of
"mediatek,mt6580"
"mediatek,mt6589"
"mediatek,mt6592"
+   "mediatek,mt6755"
"mediatek,mt6795"
"mediatek,mt7623"
"mediatek,mt8127"
@@ -31,6 +32,9 @@ Supported boards:
 - Evaluation board for MT6592:
 Required root node properties:
   - compatible = "mediatek,mt6592-evb", "mediatek,mt6592";
+- Evaluation phone for MT6755(Helio P10):
+Required root node properties:
+  - compatible = "mediatek,mt6755-evb", "mediatek,mt6755";
 - Evaluation board for MT6795(Helio X10):
 Required root node properties:
   - compatible = "mediatek,mt6795-evb", "mediatek,mt6795";
diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt 
b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
index 8cf564d..9d1d72c 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
@@ -9,6 +9,7 @@ Required properties:
"mediatek,mt8135-sysirq"
"mediatek,mt8127-sysirq"
"mediatek,mt6795-sysirq"
+   "mediatek,mt6755-sysirq"
"mediatek,mt6592-sysirq"
"mediatek,mt6589-sysirq"
"mediatek,mt6582-sysirq"
diff --git a/Documentation/devicetree/bindings/serial/mtk-uart.txt 
b/Documentation/devicetree/bindings/serial/mtk-uart.txt
index e99e10a..0015c72 100644
--- a/Documentation/devicetree/bindings/serial/mtk-uart.txt
+++ b/Documentation/devicetree/bindings/serial/mtk-uart.txt
@@ -6,6 +6,7 @@ Required properties:
   * "mediatek,mt6580-uart" for MT6580 compatible UARTS
   * "mediatek,mt6582-uart" for MT6582 compatible UARTS
   * "mediatek,mt6589-uart" for MT6589 compatible UARTS
+  * "mediatek,mt6755-uart" for MT6755 compatible UARTS
   * "mediatek,mt6795-uart" for MT6795 compatible UARTS
   * "mediatek,mt7623-uart" for MT7623 compatible UARTS
   * "mediatek,mt8127-uart" for MT8127 compatible UARTS
-- 
1.7.9.5



[PATCH v2 2/2] arm64: dts: mediatek: add mt6755 support

2016-06-27 Thread Mars Cheng
This adds basic chip support for MT6755 SoC.

Signed-off-by: Mars Cheng 
---
 arch/arm64/boot/dts/mediatek/Makefile   |1 +
 arch/arm64/boot/dts/mediatek/mt6755-evb.dts |   38 +++
 arch/arm64/boot/dts/mediatek/mt6755.dtsi|  145 +++
 3 files changed, 184 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt6755-evb.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt6755.dtsi

diff --git a/arch/arm64/boot/dts/mediatek/Makefile 
b/arch/arm64/boot/dts/mediatek/Makefile
index e0a4bff..9fbfd32 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -1,3 +1,4 @@
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt6755-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt6795-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
 
diff --git a/arch/arm64/boot/dts/mediatek/mt6755-evb.dts 
b/arch/arm64/boot/dts/mediatek/mt6755-evb.dts
new file mode 100644
index 000..c568d49
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt6755-evb.dts
@@ -0,0 +1,38 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Mars.C 
+ *
+ * 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.
+ */
+
+/dts-v1/;
+#include "mt6755.dtsi"
+
+/ {
+   model = "MediaTek MT6755 EVB";
+   compatible = "mediatek,mt6755-evb", "mediatek,mt6755";
+
+   aliases {
+   serial0 = 
+   };
+
+   memory@4000 {
+   device_type = "memory";
+   reg = <0 0x4000 0 0x1e80>;
+   };
+
+   chosen {
+   stdout-path = "serial0:921600n8";
+   };
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt6755.dtsi 
b/arch/arm64/boot/dts/mediatek/mt6755.dtsi
new file mode 100644
index 000..01ba776
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt6755.dtsi
@@ -0,0 +1,145 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Mars.C 
+ *
+ * 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,
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+
+/ {
+   compatible = "mediatek,mt6755";
+   interrupt-parent = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   psci {
+   compatible = "arm,psci-0.2";
+   method = "smc";
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x000>;
+   };
+
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x001>;
+   };
+
+   cpu2: cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x002>;
+   };
+
+   cpu3: cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x003>;
+   };
+
+   cpu4: cpu@100 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x100>;
+   };
+
+   cpu5: cpu@101 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x101>;
+   };
+
+   cpu6: cpu@102 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x102>;
+   };
+
+   cpu7: cpu@103 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x103>;
+  

RE: [PATCH v3 2/3] iio: Add driver for Broadcom iproc-static-adc

2016-06-27 Thread Raveendra Padasalagi
> -Original Message-
> From: Jonathan Cameron [mailto:ji...@kernel.org]
> Sent: 28 June 2016 00:41
> To: Raveendra Padasalagi
> Cc: Peter Meerwald-Stadler; Rob Herring; Russell King; Arnd Bergmann;
> linux-
> i...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; Pawel Moll; Mark Rutland; Ian Campbell; Kumar
> Gala; Jonathan Richardson; Jon Mason; Florian Fainelli; Anup Patel; Ray
> Jui;
> Scott Branden; Pramod Kumar; linux-kernel@vger.kernel.org; bcm-kernel-
> feedback-list
> Subject: Re: [PATCH v3 2/3] iio: Add driver for Broadcom iproc-static-adc
>
> On 27/06/16 07:25, Raveendra Padasalagi wrote:
> > On Sun, Jun 26, 2016 at 4:08 PM, Jonathan Cameron 
> wrote:
> >> On 22/06/16 07:11, Raveendra Padasalagi wrote:
> >>> This patch adds basic driver implementation for Broadcom's static
> >>> adc controller used in iProc SoC's family.
> >>>
> >>> Signed-off-by: Raveendra Padasalagi
> >>> 
> >>> Reviewed-by: Ray Jui 
> >>> Reviewed-by: Scott Branden 
> >> A few tiny nitpicks.. Otherwise, looking good to me.
> >>
> >> Thanks,
> >>
> >> Jonathan
> >
> > Thank you.  I have provided my view on naming "indio_dev->name" below.
> > Need your opinion/suggestion on the same to address it.
> >
> >>> ---
> >>>  drivers/iio/adc/Kconfig |  12 +
> >>>  drivers/iio/adc/Makefile|   1 +
> >>>  drivers/iio/adc/bcm_iproc_adc.c | 648
> >>> 
> >>>  3 files changed, 661 insertions(+)
> >>>  create mode 100644 drivers/iio/adc/bcm_iproc_adc.c
> >>>
> >>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index
> >>> 25378c5..1de31bd 100644
> >>> --- a/drivers/iio/adc/Kconfig
> >>> +++ b/drivers/iio/adc/Kconfig
> >>> @@ -153,6 +153,18 @@ config AXP288_ADC
> >>> To compile this driver as a module, choose M here: the module
> >>> will be
> >>> called axp288_adc.
> >>>
> >>> +config BCM_IPROC_ADC
> >>> + tristate "Broadcom IPROC ADC driver"
> >>> + depends on ARCH_BCM_IPROC || COMPILE_TEST
> >>> + depends on MFD_SYSCON
> >>> + default ARCH_BCM_CYGNUS
> >>> + help
> >>> +   Say Y here if you want to add support for the Broadcom static
> >>> +   ADC driver.
> >>> +
> >>> +   Broadcom iProc ADC driver. Broadcom iProc ADC controller has 8
> >>> +   channels. The driver allows the user to read voltage values.
> >>> +
> >>>  config BERLIN2_ADC
> >>>   tristate "Marvell Berlin2 ADC driver"
> >>>   depends on ARCH_BERLIN
> >>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> >>> index 38638d4..0ba0d50 100644
> >>> --- a/drivers/iio/adc/Makefile
> >>> +++ b/drivers/iio/adc/Makefile
> >>> @@ -16,6 +16,7 @@ obj-$(CONFIG_AD799X) += ad799x.o
> >>>  obj-$(CONFIG_AT91_ADC) += at91_adc.o
> >>>  obj-$(CONFIG_AT91_SAMA5D2_ADC) += at91-sama5d2_adc.o
> >>>  obj-$(CONFIG_AXP288_ADC) += axp288_adc.o
> >>> +obj-$(CONFIG_BCM_IPROC_ADC) += bcm_iproc_adc.o
> >>>  obj-$(CONFIG_BERLIN2_ADC) += berlin2-adc.o
> >>>  obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
> >>>  obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o diff --git
> >>> a/drivers/iio/adc/bcm_iproc_adc.c b/drivers/iio/adc/bcm_iproc_adc.c
> >>> new file mode 100644 index 000..e10f6ce
> >>> --- /dev/null
> >>> +++ b/drivers/iio/adc/bcm_iproc_adc.c
> >>> @@ -0,0 +1,648 @@
> >>> +/*
> >>> + * Copyright 2016 Broadcom
> >>> + *
> >>> + * 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 (the "GPL").
> >>> + *
> >>> + * 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 version 2 (GPLv2) for more details.
> >>> + *
> >>> + * You should have received a copy of the GNU General Public
> >>> +License
> >>> + * version 2 (GPLv2) along with this source code.
> >>> + */
> >>> +
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +
> >>> +#include 
> >>> +
> >>> +/* Below Register's are common to IPROC ADC and Touchscreen IP */
> >>> +#define IPROC_REGCTL10x00
> >>> +#define IPROC_REGCTL20x04
> >>> +#define IPROC_INTERRUPT_THRES0x08
> >>> +#define IPROC_INTERRUPT_MASK 0x0c
> >>> +#define IPROC_INTERRUPT_STATUS   0x10
> >>> +#define IPROC_ANALOG_CONTROL 0x1c
> >>> +#define IPROC_CONTROLLER_STATUS  0x14
> >>> +#define IPROC_AUX_DATA   0x20
> >>> +#define IPROC_SOFT_BYPASS_CONTROL0x38
> >>> +#define IPROC_SOFT_BYPASS_DATA   0x3C
> 

Re: [PATCH v2] notifier: Fix soft lockup for notifier_call_chain().

2016-06-27 Thread Eric Dumazet
On Tue, 2016-06-28 at 12:56 +0800, Ding Tianhong wrote:
> The problem was occurs in my system that a lot of drviers register
> its own handler to the notifiler call chain for netdev_chain, and
> then create 4095 vlan dev for one nic, and add several ipv6 address
> on each one of them, just like this:
> 
> for i in `seq 1 4095`; do ip link add link eth0 name eth0.$i type vlan id $i; 
> done
> for i in `seq 1 4095`; do ip -6 addr add 2001::$i dev eth0.$i; done
> for i in `seq 1 4095`; do ip -6 addr add 2002::$i dev eth0.$i; done
> for i in `seq 1 4095`; do ip -6 addr add 2003::$i dev eth0.$i; done
> 
> ifconfig eth0 up
> ifconfig eth0 down

I would very much prefer cond_resched() at a more appropriate place.

touch_nmi_watchdog() does not fundamentally solve the issue, as some
process is holding one cpu for a very long time.

Probably in addrconf_ifdown(), as if you have 100,000 IPv6 addresses on
a single netdev, this function might also trigger a soft lockup, without
playing with 4096 vlans...

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 
a1f6b7b315317f811cafbf386cf21dfc510c2010..13b675f79a751db45af28fc0474ddb17d9b69b06
 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3566,6 +3566,7 @@ restart:
}
}
spin_unlock_bh(_hash_lock);
+   cond_resched();
}
 
write_lock_bh(>lock);





RE: acpi: broken suspend to RAM with v4.7-rc1

2016-06-27 Thread Zheng, Lv
Hi,

> From: Andrey Skvortsov [mailto:andrej.skvort...@gmail.com]
> Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
> 
> On 27 Jun, Zheng, Lv wrote:
> > Hi,
> >
> > > From: Andrey Skvortsov [mailto:andrej.skvort...@gmail.com]
> > > Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
> > >
> > > On 24 Jun, Zheng, Lv wrote:
> > > > Hi,
> > > >
> > > > > From: Andrey Skvortsov [mailto:andrej.skvort...@gmail.com]
> > > > > Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
> > > > >
> > > > > Hi Lv,
> > > > >
> > > > > On 13 Jun, Zheng, Lv wrote:
> > > > > > > From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> > > > > > > ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki
> > > > > > > Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
> > > > > > >
> > > > > > > On Saturday, June 11, 2016 01:49:22 PM Andrey Skvortsov
> wrote:
> > > > > > > > On 10 Jun, Rafael J. Wysocki wrote:
> > > > > > > > > On Friday, June 10, 2016 11:32:10 PM Andrey Skvortsov
> wrote:
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken
> > > suspend
> > > > > to RAM.
> > > > > > > > > > Laptop doesn't finish suspend to RAM process (disks are
> off,
> > > but
> > > > > > > > > > WiFi and Power LEDs are still on). The only way to get it
> out of
> > > > > > > > > > this state, is to turn the power off.
> > > > > > > > > >
> > > > > > > > > > I've bisected the issue to commit 66b1ed5aa8dd25
> > > > > > > > > > [ACPICA: ACPI 2.0, Hardware: Add
> access_width/bit_offset
> > > > > support
> > > > > > > > > > for acpi_hw_write()].
> > > > > > > > > >
> > > > > > > > > > If I revert this commit in v4.7-rc1 (or v4.7-rc2), suspend 
> > > > > > > > > > to
> > > RAM
> > > > > > > > > > is working again.
> > > > > > > > > >
> > > > > > > > > > The cause of this problem is that after this commit write
> to
> > > > > PM1A
> > > > > > > > > > Control Block (16-bit register) is done using two 8-bit
> writes.
> > > > > > > > > > If I force this write to be 16-bit, then all is working as
> before.
> > > > > > > > > >
> > > > > > > > > > To get it working 'access_width' for PM1A Control Block
> > > needs to
> > > > > > > > > > be 2 (16-bit), but it's 1 (8-bit).
> > > > > > [Lv Zheng]
> > > > > > Could you send me the acpidump of the machine?
> > > > > Here it is
> > > > >
> > >
> https://dl.dropboxusercontent.com/u/24023626/dell_vostro_1500.acpid
> > > > > ump.bin
> > > > [Lv Zheng]
> > > > I've been trying to download it these days but all failed.
> > > > Could you send an off-list email to me with this attached?
> > > Strange. I've check now. The link above is working, but I see that
> > > part of the link above is moved to the next line.
> > [Lv Zheng]
> > Maybe this is just because of ISP firewall.
> >
> > > Anyway I resend you all files off-list.
> > [Lv Zheng]
> > Great!
> >
> > >
> > >
> > > > > > > > > > The root of the problem seems to be not the commit
> > > > > > > 66b1ed5aa8dd25
> > > > > > > > > > itself, but the ACPI tables in BIOS where wrong
> access_width
> > > > > > > > > > comes from. I fixed problem in FACP  table, put it in initrd
> to
> > > > > > > > > > override FACP table from BIOS. This fixed the issue,
> suspend
> > > to
> > > > > > > > > > RAM is working now again.
> > > > > > > > > >
> > > > > > > > > > But I'm not sure whether is this proper fix for this
> problem.
> > > > > > > > > > Is there any place in the kernel, where such ACPI quirks
> are
> > > placed?
> > > > > > [Lv Zheng]
> > > > > > My question would be:
> > > > > > Does Windows behave correctly for this table?
> > > > > Yes, suspend to RAM is working under Windows Vista.
> > > > > IIRC it worked under Windows XP too.
> > > > >
> > > > > > However there is a real case showing that there are real tables
> need
> > > us to
> > > > > correctly support BitWidth/BitOffset.
> > > > > > Here is the information for you to refer:
> > > > > >
> > >
> http://permalink.gmane.org/gmane.linux.kernel.commits.head/313870
> > > > > >
> > > > > > > > >
> > > > > > > > > Well, if the commit in question caused a problem to happen
> for
> > > > > you,
> > > > > > > > > it also might cause similar problems to happen elsewhere.
> > > > > > > > >
> > > > > > > > > It looks like we'll need to revert that commit.
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > or maybe to reset access_width AnyAcc from FACP table only
> for
> > > > > PM1A
> > > > > > > > control register or even for all registers? This will fix the 
> > > > > > > > issue
> too.
> > > > > > >
> > > > > > > That's a good idea actually.
> > > > > > >
> > > > > > > > diff --git a/drivers/acpi/acpica/tbfadt.c
> > > > > > > > b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94
> 100644
> > > > > > > > --- a/drivers/acpi/acpica/tbfadt.c
> > > > > > > > +++ b/drivers/acpi/acpica/tbfadt.c
> > > > > > > > @@ -714,7 +714,14 @@ static void
> > > > > acpi_tb_setup_fadt_registers(void)
> > > > > > > > }
> > > > > 

Re: [PATCH] capabilities: add capability cgroup controller

2016-06-27 Thread Eric W. Biederman
Topi Miettinen  writes:

> On 06/24/16 17:21, Eric W. Biederman wrote:
>> "Serge E. Hallyn"  writes:
>> 
>>> Quoting Tejun Heo (t...@kernel.org):
 Hello,

 On Fri, Jun 24, 2016 at 10:59:16AM -0500, Serge E. Hallyn wrote:
> Quoting Tejun Heo (t...@kernel.org):
>> But isn't being recursive orthogonal to using cgroup?  Why not account
>> usages recursively along the process hierarchy?  Capabilities don't
>> have much to do with cgroup but everything with process hierarchy.
>> That's how they're distributed and modified.  If monitoring their
>> usages is necessary, it makes sense to do it in the same structure.
>
> That was my argument against using cgroups to enforce a new bounding
> set.  For tracking though, the cgroup process tracking seems as applicable
> to this as it does to systemd tracking of services.  It tracks a task and
> the children it forks.

 Just monitoring is less jarring than implementing security enforcement
 via cgroup, but it is still jarring.  What's wrong with recursive
 process hierarchy monitoring which is in line with the whole facility
 is implemented anyway?
>>>
>>> As I think Topi pointed out, one shortcoming is that if there is a 
>>> short-lived
>>> child task, using its /proc/self/status is racy.  You might just miss that 
>>> it
>>> ever even existed, let alone that the "application" needed it.
>>>
>>> Another alternative we've both mentioned is to use systemtap.  That's not
>>> as nice a solution as a cgroup, but then again this isn't really a common
>>> case, so maybe it is precisely what a tracing infrastructure is meant for.
>> 
>> Hmm.
>> 
>> We have capability use wired up into auditing.  So we might be able to
>> get away with just adding an appropriate audit message in
>> commoncap.c:cap_capable that honors the audit flag and logs an audit
>> message.  The hook in selinux already appears to do that.
>> 
>> Certainly audit sounds like the subsystem for this kind of work, as it's
>> whole point in life is logging things, then something in userspace can
>> just run over the audit longs and build a nice summary.
>
> Even simpler would be to avoid the complexity of audit subsystem and
> just printk() when a task starts using a capability first time (not on
> further uses by same task). There are not that many capability bits nor
> privileged processes, meaning not too many log entries. I know as this
> was actually my first approach. But it's also far less user friendly
> than just reading a summarized value which could be directly fed back to
> configuration.

Your loss.

> Logging/auditing approach also doesn't work well for other things I'd
> like to present meaningful values for the user. For example, consider
> RLIMIT_AS, where my goal is also to enable the users to be able to
> configure this limit for a service. Should there be an audit message
> whenever the address space limit grows (i.e. each mmap())? What about
> when it shrinks? For RLIMIT_NOFILE we'd have to report each
> open()/close()/dup()/socket()/etc. and track how many are opened at the
> same time. I think it's better to store the fully cooked (meaningful to
> user) value in kernel and present it only when asked.

That doesn't have anything to do with anything.

My suggestion was very much to do with capabilities which are already
logged with the audit subsystem with selinux.  The idea was to move
those audit calls into commoncap where they arguably belong allow anyone
to use them for anything.

That is a non-controversial code cleanup that happens to cover your
special case.  That is enough to build a tool in userspace that will
tell you which capabilities you need without penalizing the kernel, or
the vast majority of everyone who does not use your feature.

>From what I have seen of this conversation there is not and will not be
one interface to rule them all.

Eric


Re: [PATCH 2/2] dt-bindings: pinctrl: Add MDM9615 TLMM bindings

2016-06-27 Thread Bjorn Andersson
On Fri 17 Jun 03:15 PDT 2016, Neil Armstrong wrote:

> Signed-off-by: Neil Armstrong 

Acked-by: Bjorn Andersson 

Regards,
Bjorn


[PATCH V1] regulator: da9211: add descriptions for da9212/da9214

2016-06-27 Thread James Ban

From: James Ban 

This is a patch for adding description for da9212/da9214.

Signed-off-by: James Ban 

---
This patch applies against linux-next and next-20160624 


 .../devicetree/bindings/regulator/da9211.txt   |   44 ++--
 drivers/regulator/da9211-regulator.c   |5 ++-
 drivers/regulator/da9211-regulator.h   |3 +-
 include/linux/regulator/da9211.h   |3 +-
 4 files changed, 47 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/da9211.txt 
b/Documentation/devicetree/bindings/regulator/da9211.txt
index c620493..8766f75 100644
--- a/Documentation/devicetree/bindings/regulator/da9211.txt
+++ b/Documentation/devicetree/bindings/regulator/da9211.txt
@@ -1,4 +1,4 @@
-* Dialog Semiconductor DA9211/DA9213/DA9215 Voltage Regulator
+* Dialog Semiconductor DA9211/DA9212/DA9213/DA9214/DA9215 Voltage Regulator
 
 Required properties:
 - compatible: "dlg,da9211" or "dlg,da9213" or "dlg,da9215"
@@ -30,6 +30,25 @@ Example 1) DA9211
regulator-max-microamp  = <500>;
enable-gpios = < 27 0>;
};
+   };
+   };
+
+Example 2) DA9212
+
+   pmic: da9211@68 {
+   compatible = "dlg,da9211";
+   reg = <0x68>;
+   interrupts = <3 27>;
+
+   regulators {
+   BUCKA {
+   regulator-name = "VBUCKA";
+   regulator-min-microvolt = < 30>;
+   regulator-max-microvolt = <157>;
+   regulator-min-microamp  = <200>;
+   regulator-max-microamp  = <500>;
+   enable-gpios = < 27 0>;
+   };
BUCKB {
regulator-name = "VBUCKB";
regulator-min-microvolt = < 30>;
@@ -41,7 +60,25 @@ Example 1) DA9211
};
};
 
-Example 2) DA9213
+Example 3) DA9213
+   pmic: da9213@68 {
+   compatible = "dlg,da9213";
+   reg = <0x68>;
+   interrupts = <3 27>;
+
+   regulators {
+   BUCKA {
+   regulator-name = "VBUCKA";
+   regulator-min-microvolt = < 30>;
+   regulator-max-microvolt = <157>;
+   regulator-min-microamp  = <300>;
+   regulator-max-microamp  = <600>;
+   enable-gpios = < 27 0>;
+   };
+   };
+   };
+
+Example 4) DA9214
pmic: da9213@68 {
compatible = "dlg,da9213";
reg = <0x68>;
@@ -67,8 +104,7 @@ Example 2) DA9213
};
};
 
-
-Example 3) DA9215
+Example 5) DA9215
pmic: da9215@68 {
compatible = "dlg,da9215";
reg = <0x68>;
diff --git a/drivers/regulator/da9211-regulator.c 
b/drivers/regulator/da9211-regulator.c
index 236abf4..59cbd9b 100644
--- a/drivers/regulator/da9211-regulator.c
+++ b/drivers/regulator/da9211-regulator.c
@@ -1,5 +1,6 @@
 /*
- * da9211-regulator.c - Regulator device driver for DA9211/DA9213/DA9215
+ * da9211-regulator.c - Regulator device driver for DA9211/DA9212
+ * /DA9213/DA9214/DA9215
  * Copyright (C) 2015  Dialog Semiconductor Ltd.
  *
  * This library is free software; you can redistribute it and/or
@@ -521,5 +522,5 @@ static struct i2c_driver da9211_regulator_driver = {
 module_i2c_driver(da9211_regulator_driver);
 
 MODULE_AUTHOR("James Ban ");
-MODULE_DESCRIPTION("Regulator device driver for Dialog DA9211/DA9213/DA9215");
+MODULE_DESCRIPTION("DA9211/DA9212/DA9213/DA9214/DA9215 regulator driver");
 MODULE_LICENSE("GPL");
diff --git a/drivers/regulator/da9211-regulator.h 
b/drivers/regulator/da9211-regulator.h
index d6ad96f..b841bbf 100644
--- a/drivers/regulator/da9211-regulator.h
+++ b/drivers/regulator/da9211-regulator.h
@@ -1,5 +1,6 @@
 /*
- * da9211-regulator.h - Regulator definitions for DA9211/DA9213/DA9215
+ * da9211-regulator.h - Regulator definitions for DA9211/DA9212
+ * /DA9213/DA9214/DA9215
  * Copyright (C) 2015  Dialog Semiconductor Ltd.
  *
  * This program is free software; you can redistribute it and/or
diff --git a/include/linux/regulator/da9211.h b/include/linux/regulator/da9211.h
index a43a5ca..72c5a4d1 100644
--- a/include/linux/regulator/da9211.h
+++ b/include/linux/regulator/da9211.h
@@ -1,5 +1,6 @@
 /*
- * da9211.h - Regulator device driver for DA9211/DA9213/DA9215
+ * da9211.h - Regulator device driver for DA9211/DA9212
+ * /DA9213/DA9214/DA9215
  * Copyright (C) 2015  Dialog Semiconductor Ltd.
  *
  * This program is free 

Re: [PATCH 1/2] pinctrl: qcom: Add support for MDM9615 TLMM

2016-06-27 Thread Bjorn Andersson
On Fri 17 Jun 03:15 PDT 2016, Neil Armstrong wrote:

> In order to support the Qualcomm MDM9615 SoC, add support for the TLMM
> using the Qualcomm pinctrl generic driver.
> 
> Note: the pinctrl is partial, need Documentation to complete all the groups.
> Signed-off-by: Neil Armstrong 

Unfortunately I don't have docs for this platform; but what you have
here looks reasonable.

Acked-by: Bjorn Andersson 

Regards,
Bjorn


Re: [PATCH 2/3] powerpc/spinlock: support vcpu preempted check

2016-06-27 Thread Boqun Feng
On Tue, Jun 28, 2016 at 11:39:18AM +0800, xinhui wrote:
[snip]
> > > +{
> > > + struct lppaca *lp = _of(cpu);
> > > +
> > > + if (unlikely(!(lppaca_shared_proc(lp) ||
> > > + lppaca_dedicated_proc(lp
> > 
> > Do you want to detect whether we are running in a guest(ie. pseries
> > kernel) here? Then I wonder whether "machine_is(pseries)" works here.
> > 
> I tried as you said yesterday. but .h file has dependencies.
> As you said, if we add #ifdef PPC_PSERIES, this is not a big problem. only 
> powernv will be affected as they are built into same kernel img.
> 

I never said this it not a big problem ;-)

The problem here is that we only need to detect the vcpu preemption in
a guest, and there could be several ways we can detect whether the
kernel is running in a guest. It's worthwhile to try find the best one
for this. Besides, it's really better that you can make sure we are
runing out of options before you introduce something like
lppaca_dedicated_proc().

I have a feeling that yield_count is non-zero only if we are running in
a guest, if so, we can use this and save several loads. But surely we
need the confirmation from ppc maintainers.

Regards,
Boqun


signature.asc
Description: PGP signature


Re: IP ID check (flush_id) in inet_gro_receive is necessary or not?

2016-06-27 Thread Eric Dumazet
On Tue, 2016-06-28 at 12:40 +0800, Tan Xiaojun wrote:
> Hi everyone,
> 
>   I'm sorry to bother you. But I was confused.
> 
>   The IP ID check (flush_id) in inet_gro_receive is only used by
> tcp_gro_receive, and in tcp_gro_receive we have tcphdr check to ensure
> the order of skbs,
>   like below:
> 
>   flush |= (__force int)(th->ack_seq ^ th2->ack_seq);
>   flush |= (ntohl(th2->seq) + skb_gro_len(p)) ^ ntohl(th->seq);
> 
>   So if I remove the IP ID check in inet_gro_receive, there will be a
> problem ? And under what circumstances ?

You probably missed a recent patch ?

commit 1530545ed64b42e87acb43c0c16401bd1ebae6bf
Author: Alexander Duyck 
Date:   Sun Apr 10 21:44:57 2016 -0400

GRO: Add support for TCP with fixed IPv4 ID field, limit tunnel IP ID values

This patch does two things.

First it allows TCP to aggregate TCP frames with a fixed IPv4 ID field.  As
a result we should now be able to aggregate flows that were converted from
IPv6 to IPv4.  In addition this allows us more flexibility for future
implementations of segmentation as we may be able to use a fixed IP ID when
segmenting the flow.

The second thing this does is that it places limitations on the outer IPv4
ID header in the case of tunneled frames.  Specifically it forces the IP ID
to be incrementing by 1 unless the DF bit is set in the outer IPv4 header.
This way we can avoid creating overlapping series of IP IDs that could
possibly be fragmented if the frame goes through GRO and is then
resegmented via GSO.

Signed-off-by: Alexander Duyck 
Signed-off-by: David S. Miller 




[PATCH v2] notifier: Fix soft lockup for notifier_call_chain().

2016-06-27 Thread Ding Tianhong
The problem was occurs in my system that a lot of drviers register
its own handler to the notifiler call chain for netdev_chain, and
then create 4095 vlan dev for one nic, and add several ipv6 address
on each one of them, just like this:

for i in `seq 1 4095`; do ip link add link eth0 name eth0.$i type vlan id $i; 
done
for i in `seq 1 4095`; do ip -6 addr add 2001::$i dev eth0.$i; done
for i in `seq 1 4095`; do ip -6 addr add 2002::$i dev eth0.$i; done
for i in `seq 1 4095`; do ip -6 addr add 2003::$i dev eth0.$i; done

ifconfig eth0 up
ifconfig eth0 down

then it will halt several seconds, and occurs softlockup:

<0>[ 7620.364058]NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! 
[ifconfig:19186]
<0>[ 7620.364592]Call trace:
<4>[ 7620.364599][] dump_backtrace+0x0/0x220
<4>[ 7620.364603][] show_stack+0x20/0x28
<4>[ 7620.364607][] dump_stack+0x90/0xb0
<4>[ 7620.364612][] watchdog_timer_fn+0x41c/0x460
<4>[ 7620.364617][] __run_hrtimer+0x98/0x2d8
<4>[ 7620.364620][] hrtimer_interrupt+0x110/0x288
<4>[ 7620.364624][] arch_timer_handler_phys+0x38/0x48
<4>[ 7620.364628][] handle_percpu_devid_irq+0x9c/0x190
<4>[ 7620.364632][] generic_handle_irq+0x40/0x58
<4>[ 7620.364635][] __handle_domain_irq+0x68/0xc0
<4>[ 7620.364638][] gic_handle_irq+0xc4/0x1c8
<4>[ 7620.364641]Exception stack(0xffc0309b3640 to 0xffc0309b3770)
<4>[ 7620.364644]3640: 1000  ffc0309b37c0 
ffbfa1019cf8
<4>[ 7620.364647]3660: 8145 ffc0309b3958  
ffbfa1013008
<4>[ 7620.364651]3680: 07f0 ffbfa131b770 ffd08aaadc40 
ffbfa1019cf8
<4>[ 7620.364654]36a0: ffbfa1019cc4 ffd089c2b000 ffd08eff8000 
ffc0309b3958
<4>[ 7620.364656]36c0: ffbfa101c5c0   
ffbfa101c66c
<4>[ 7620.364659]36e0: 7f7f7f7f7f7f7f7f 0030  

<4>[ 7620.364662]3700:   ffc000393d58 
007f794d67b0
<4>[ 7620.364665]3720: 007fe62215d0 ffc0309b3830 ffc00021d8e0 
ffbfa1049b68
<4>[ 7620.364668]3740: ffc000697578 ffc0006974b8 ffc0309b3958 

<4>[ 7620.364670]3760: ffbfa1013008 07f0
<4>[ 7620.364673][] el1_irq+0x80/0x100
<4>[ 7620.364692][] fib6_walk+0x3c/0x70 [ipv6]
<4>[ 7620.364710][] fib6_clean_tree+0x68/0x90 [ipv6]
<4>[ 7620.364727][] __fib6_clean_all+0x88/0xc0 [ipv6]
<4>[ 7620.364746][] fib6_clean_all+0x28/0x30 [ipv6]
<4>[ 7620.364763][] rt6_ifdown+0x64/0x148 [ipv6]
<4>[ 7620.364781][] addrconf_ifdown+0x68/0x540 [ipv6]
<4>[ 7620.364798][] addrconf_notify+0xd0/0x8b8 [ipv6]
<4>[ 7620.364801][] notifier_call_chain+0x5c/0xa0
<4>[ 7620.364804][] raw_notifier_call_chain+0x20/0x28
<4>[ 7620.364809][] call_netdevice_notifiers_info+0x4c/0x80
<4>[ 7620.364812][] dev_close_many+0xd0/0x138
<4>[ 7620.364821][] vlan_device_event+0x4a8/0x6a0 [8021q]
<4>[ 7620.364824][] notifier_call_chain+0x5c/0xa0
<4>[ 7620.364827][] raw_notifier_call_chain+0x20/0x28
<4>[ 7620.364830][] call_netdevice_notifiers_info+0x4c/0x80
<4>[ 7620.364833][] __dev_notify_flags+0xb8/0xe0
<4>[ 7620.364836][] dev_change_flags+0x54/0x68
<4>[ 7620.364840][] devinet_ioctl+0x650/0x700
<4>[ 7620.364843][] inet_ioctl+0xa4/0xc8
<4>[ 7620.364847][] sock_do_ioctl+0x44/0x88
<4>[ 7620.364850][] sock_ioctl+0x23c/0x308
<4>[ 7620.364854][] do_vfs_ioctl+0x48c/0x620
<4>[ 7620.364857][] SyS_ioctl+0x94/0xa8

=cut 
here

It looks that the notifier_call_chain has to deal with too much handler, and 
will not
feed the watchdog until finish the work, and the notifier_call_chain may be 
called
in atomic context, so add touch_nmi_watchdog() in the loops to fix this problem,
and it will not panic again.

v2: add cond_resched() will break the atomic context, so feed the watchdog in
the loops to fix this bug.

Signed-off-by: Ding Tianhong 
---
 kernel/notifier.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/notifier.c b/kernel/notifier.c
index fd2c9ac..7eca3c1 100644
--- a/kernel/notifier.c
+++ b/kernel/notifier.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Notifier list for kernel code which wants to be called
@@ -92,6 +93,8 @@ static int notifier_call_chain(struct notifier_block **nl,
 #endif
ret = nb->notifier_call(nb, val, v);
 
+   touch_nmi_watchdog();
+
if (nr_calls)
(*nr_calls)++;
 
-- 
1.9.0




RE: [PATCH] usb: otg-fsm: Cancel HNP polling work when not used

2016-06-27 Thread Jun Li
Hi

> -Original Message-
> From: Stephen Boyd [mailto:stephen.b...@linaro.org]
> Sent: Tuesday, June 28, 2016 9:18 AM
> To: Peter Chen ; Felipe Balbi 
> Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> linux-...@vger.kernel.org; Jun Li ; Greg Kroah-Hartman
> 
> Subject: [PATCH] usb: otg-fsm: Cancel HNP polling work when not used
> 
> We setup the HNP polling worker, but we never stop it. The OTG state
> machine can go round and round and keep reinitializing the worker even
> while it's actively running. That's bad, and debug objects catches it. Fix
> this by canceling the work when we leave the A_HOST or B_HOST states.
> 

Normally we need not stop it because the scheduled delayed work will
be finished before next host entering, in your case there is another
host entering before the previous delayed work timeout, so we reinit
the active worker wrongly. Thanks for the required fix.

Acked-by: Li Jun 
 
> [otg_set_state]  Set state: a_wait_bcon
> usb 2-1: USB disconnect, device number 2 [otg_statemachine]  quit
> statemachine, changed = 1 [otg_set_state]  Set state: a_host  started> [otg_statemachine]  quit statemachine, changed = 1 usb 2-1: new
> low-speed USB device number 3 using ci_hdrc usb 2-1: New USB device found,
> idVendor=03f0, idProduct=134a usb 2-1: New USB device strings: Mfr=1,
> Product=2, SerialNumber=0 usb 2-1: Product: HP USB Optical Mouse usb 2-1:
> Manufacturer: PixArt
> input: PixArt HP USB Optical Mouse as
> /devices/platform/soc/f9a55000.usb/ci_hdrc.0/usb2/2-1/2-
> 1:1.0/0003:03F0:134A.0002/input/input1
> hid-generic 0003:03F0:134A.0002: input: USB HID v1.11 Mouse [PixArt HP USB
> Optical Mouse] on usb-ci_hdrc.0-1/input0 [otg_set_state]  Set state:
> a_wait_bcon usb 2-1: USB disconnect, device number 3 [otg_statemachine]
> quit statemachine, changed = 1 [otg_set_state]  Set state: a_host  Polling started> [ cut here ]
> WARNING: CPU: 2 PID: 95 at lib/debugobjects.c:263
> debug_print_object+0x98/0xc0
> ODEBUG: init active (active state 0) object type: timer_list hint:
> delayed_work_timer_fn+0x0/0x2c Modules linked in: phy_qcom_usb_hsic
> phy_qcom_usb_hs ci_hdrc_msm ci_hdrc
> CPU: 2 PID: 95 Comm: kworker/u8:1 Not tainted 4.7.0-rc1-00043-
> g1f22f3b65c44-dirty #442 Hardware name: Qualcomm (Flattened Device Tree)
> Workqueue: ci_otg ci_otg_work [ci_hdrc]
> [] (unwind_backtrace) from [] (show_stack+0x20/0x24)
> [] (show_stack) from [] (dump_stack+0x7c/0x9c)
> [] (dump_stack) from [] (__warn+0xe4/0x110)
> [] (__warn) from [] (warn_slowpath_fmt+0x48/0x50)
> [] (warn_slowpath_fmt) from []
> (debug_print_object+0x98/0xc0) [] (debug_print_object) from
> [] (__debug_object_init+0xcc/0x3bc) []
> (__debug_object_init) from [] (debug_object_init+0x24/0x2c)
> [] (debug_object_init) from []
> (init_timer_key+0x24/0x120) [] (init_timer_key) from []
> (otg_start_hnp_polling+0x7c/0xbc) [] (otg_start_hnp_polling)
> from [] (otg_set_state+0x740/0xc20) [] (otg_set_state)
> from [] (otg_statemachine+0x47c/0x4ac) []
> (otg_statemachine) from [] (ci_otg_fsm_work+0x48/0x1a0 [ci_hdrc])
> [] (ci_otg_fsm_work [ci_hdrc]) from []
> (ci_otg_work+0xd4/0x218 [ci_hdrc]) [] (ci_otg_work [ci_hdrc])
> from [] (process_one_work+0x154/0x4b4) []
> (process_one_work) from [] (worker_thread+0x38/0x4d0)
> [] (worker_thread) from [] (kthread+0xe8/0x104)
> [] (kthread) from [] (ret_from_fork+0x14/0x3c)
> 
> Cc: Li Jun 
> Cc: Greg Kroah-Hartman 
> Fixes: ae57e97a9521 ("usb: common: otg-fsm: add HNP polling support")
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/common/usb-otg-fsm.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/usb/common/usb-otg-fsm.c b/drivers/usb/common/usb-
> otg-fsm.c
> index 9059b7dc185e..73eec8c12235 100644
> --- a/drivers/usb/common/usb-otg-fsm.c
> +++ b/drivers/usb/common/usb-otg-fsm.c
> @@ -61,6 +61,18 @@ static int otg_set_protocol(struct otg_fsm *fsm, int
> protocol)
>   return 0;
>  }
> 
> +static void otg_stop_hnp_polling(struct otg_fsm *fsm) {
> + /*
> +  * The memory of host_req_flag should be allocated by
> +  * controller driver, otherwise, hnp polling is not started.
> +  */
> + if (!fsm->host_req_flag)
> + return;
> +
> + cancel_delayed_work_sync(>hnp_polling_work);
> +}
> +
>  /* Called when leaving a state.  Do state clean up jobs here */  static
> void otg_leave_state(struct otg_fsm *fsm, enum usb_otg_state old_state)
> { @@ -84,6 +96,7 @@ static void otg_leave_state(struct otg_fsm *fsm, enum
> usb_otg_state old_state)
>   fsm->b_ase0_brst_tmout = 0;
>   break;
>   case OTG_STATE_B_HOST:
> + otg_stop_hnp_polling(fsm);
>   break;
>   case OTG_STATE_A_IDLE:
>   fsm->adp_prb = 0;
> @@ -97,6 +110,7 @@ static void 

[PATCH] regulator: pwm: Fix regulator ramp delay for continuous mode

2016-06-27 Thread Douglas Anderson
The original commit adding support for continuous voltage mode didn't
handle the regulator ramp delay properly.  It treated the delay as a
fixed delay in uS despite the property being defined as uV / uS.  Let's
adjust it.  Luckily there appear to be no users of this ramp delay for
PWM regulators (as per grepping through device trees in linuxnext).

Note also that the upper bound of usleep_range probably shouldn't be a
full 1 ms longer than the lower bound since I've seen plenty of hardware
with a ramp rate of ~5000 uS / uV and for small jumps the total delays
are in the tens of uS.  1000 is way too much.  We'll try to be dynamic
and use 10%

Signed-off-by: Douglas Anderson 
---
Note that this patch is atop Boris's recent PWM regulator fixes.  If
desired it wouldn't be too hard to write it atop the old code, though
quite honestly anyone using a PWM regulator should probably be using his
new code.

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

diff --git a/drivers/regulator/pwm-regulator.c 
b/drivers/regulator/pwm-regulator.c
index fa1c74c77bb0..de94d19f6e1f 100644
--- a/drivers/regulator/pwm-regulator.c
+++ b/drivers/regulator/pwm-regulator.c
@@ -188,6 +188,7 @@ static int pwm_regulator_set_voltage(struct regulator_dev 
*rdev,
struct pwm_state pstate;
unsigned int diff_duty;
unsigned int dutycycle;
+   int old_uV = pwm_regulator_get_voltage(rdev);
int ret;
 
pwm_init_state(drvdata->pwm, );
@@ -219,8 +220,12 @@ static int pwm_regulator_set_voltage(struct regulator_dev 
*rdev,
return ret;
}
 
-   /* Delay required by PWM regulator to settle to the new voltage */
-   usleep_range(ramp_delay, ramp_delay + 1000);
+   if (ramp_delay == 0)
+   return 0;
+
+   /* Ramp delay is in uV/uS. Adjust to uS and delay */
+   ramp_delay = DIV_ROUND_UP(abs(req_min_uV - old_uV), ramp_delay);
+   usleep_range(ramp_delay, ramp_delay + DIV_ROUND_UP(ramp_delay, 10));
 
return 0;
 }
-- 
2.8.0.rc3.226.g39d4020



Re: [PATCH 15/21] usb: chipidea: msm: Mux over secondary phy at the right time

2016-06-27 Thread Bjorn Andersson
On Sun 26 Jun 00:28 PDT 2016, Stephen Boyd wrote:

> We need to pick the correct phy at runtime based on how the SoC
> has been wired onto the board. If the secondary phy is used, take
> it out of reset and mux over to it by writing into the TCSR
> register. Make sure to do this on reset too, because this
> register is reset to the default value (primary phy) after the
> RESET bit is set in USBCMD.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/ci_hdrc_msm.c | 78 
> +++---
>  1 file changed, 73 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
[..]
>  
> +static int ci_hdrc_msm_mux_phy(struct ci_hdrc_msm *ci,
> +struct platform_device *pdev)
> +{
> + struct regmap *regmap;
> + struct device_node *syscon;
> + struct device *dev = >dev;
> + u32 off, val;
> + int ret;
> +
> + syscon = of_parse_phandle(dev->of_node, "phy-select", 0);
> + if (!syscon)
> + return 0;
> +
> + regmap = syscon_node_to_regmap(syscon);
> + if (IS_ERR(regmap))
> + return PTR_ERR(regmap);
> +
> + ret = of_property_read_u32_index(dev->of_node, "phy-select", 1, );
> + if (ret < 0) {
> + dev_err(dev, "no offset in syscon\n");
> + return -EINVAL;
> + }
> +
> + ret = of_property_read_u32_index(dev->of_node, "phy-select", 2, );
> + if (ret < 0) {
> + dev_err(dev, "no value in syscon\n");
> + return -EINVAL;
> + }
> +
> + ret = regmap_write(regmap, off, val);

I recently found out (thanks to a comment from Srinivas) that you can
drop the last two error checks by using
of_parse_phandle_with_fixed_args() as in:

  struct of_phandle_args args;

  ret = of_parse_phandle_with_fixed_args(dev->of_node, "phy-select", 2, 0, 
);
  if (ret < 0)
...

  regmap = syscon_node_to_regmap(args.np);
  of_node_put(args.np);
  if (IS_ERR(regmap))
...

  ret = regmap_write(regmap, args.args[0], args.args[1]);

> + if (ret)
> + return ret;
> +
> + ci->secondary_phy = !!val;
> + if (ci->secondary_phy) {
> + val = readl_relaxed(ci->base + HS_PHY_SEC_CTRL);
> + val |= HS_PHY_DIG_CLAMP_N;
> + writel_relaxed(val, ci->base + HS_PHY_SEC_CTRL);
> + }
> +
> + return 0;
> +}
> +
>  static int ci_hdrc_msm_probe(struct platform_device *pdev)
>  {
>   struct ci_hdrc_msm *ci;
>   struct platform_device *plat_ci;
>   struct clk *clk;
>   struct reset_control *reset;
> + struct resource *res;
> + void __iomem *base;

Doesn't look like you need "base".

> + resource_size_t size;
>   int ret;
>  
>   dev_dbg(>dev, "ci_hdrc_msm_probe\n");
> @@ -76,6 +132,15 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>   if (IS_ERR(clk))
>   return PTR_ERR(clk);
>  
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res)
> + return -ENODEV;
> +
> + size = resource_size(res);
> + ci->base = base = devm_ioremap(>dev, res->start, size);
> + if (!base)
> + return -ENOMEM;

Replace these two snippets with:

  res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
  ci->base = devm_ioremap_resource(>dev, res);
  if (IS_ERR(ci->base))
return PTR_ERR(ci->base);

> +
>   reset_control_assert(reset);
>   usleep_range(1, 12000);
>   reset_control_deassert(reset);

Regards,
Bjorn


[PATCH v1 3/5] ARM: dts: rockchip: add eDP/panel display device nodes for rk3288-evb

2016-06-27 Thread Yakir Yang
The default eDP panel on RK3288 EVB board is LG LP079QX1-SP0V TFT LCD,
we haven't declared the panel regulator in the 'panel-simple' device
node here, so the specific board like ACT8846 / RK8080 need to support
the panel power supply.

Signed-off-by: Yakir Yang 
---
 arch/arm/boot/dts/rk3288-evb.dtsi | 43 ++-
 1 file changed, 42 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi 
b/arch/arm/boot/dts/rk3288-evb.dtsi
index 963365d..f293c44 100644
--- a/arch/arm/boot/dts/rk3288-evb.dtsi
+++ b/arch/arm/boot/dts/rk3288-evb.dtsi
@@ -48,7 +48,7 @@
reg = <0x0 0x8000>;
};
 
-   backlight {
+   backlight: backlight {
compatible = "pwm-backlight";
brightness-levels = <
  0   1   2   3   4   5   6   7
@@ -97,6 +97,20 @@
#clock-cells = <0>;
};
 
+   panel: panel {
+   compatible ="lg,lp079qx1-sp0v", "simple-panel";
+   backlight = <>;
+   enable-gpios = < 4 GPIO_ACTIVE_HIGH>;
+   pinctrl-0 = <_cs>;
+   ports {
+   panel_in: port {
+   panel_in_edp: endpoint {
+   remote-endpoint = <_out_panel>;
+   };
+   };
+   };
+   };
+
gpio-keys {
compatible = "gpio-keys";
autorepeat;
@@ -216,6 +230,27 @@
status = "okay";
 };
 
+_phy {
+   status = "okay";
+};
+
+ {
+   force-hpd;
+   status = "okay";
+
+   ports {
+   edp_out: port@1 {
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   edp_out_panel: endpoint {
+   reg = <0>;
+   remote-endpoint = <_in_edp>;
+   };
+   };
+   };
+};
+
  {
status = "okay";
 };
@@ -322,6 +357,12 @@
rockchip,pins = <0 6 RK_FUNC_GPIO _pull_none>;
};
};
+
+   lcd {
+   lcd_cs: lcd-cs {
+   rockchip,pins = <7 4 RK_FUNC_GPIO _pull_none>;
+   };
+   };
 };
 
  {
-- 
1.9.1




[PATCH v1 4/5] ARM: dts: rockchip: add the panel power supply for rk3288-evb board with act8846 pmu

2016-06-27 Thread Yakir Yang
Panel regulator is controller by a normal GPIO, so we need to
write a regulator-fixed node for it.

Signed-off-by: Yakir Yang 
---
 arch/arm/boot/dts/rk3288-evb-act8846.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288-evb-act8846.dts 
b/arch/arm/boot/dts/rk3288-evb-act8846.dts
index 452ca24..041dd5d 100644
--- a/arch/arm/boot/dts/rk3288-evb-act8846.dts
+++ b/arch/arm/boot/dts/rk3288-evb-act8846.dts
@@ -206,6 +206,10 @@
};
 };
 
+ {
+   power-supply = <_lcd>;
+};
+
  {
lcd {
lcd_en: lcd-en  {
-- 
1.9.1




[PATCH v1 2/5] drm/panel: simple: Add support for LG LP079QX1-SP0V 1536x2048 panel

2016-06-27 Thread Yakir Yang
The LG LP079QX1-SP0V is an 7.9" QXGA TFT with LED Backlight unit and
32 pins eDP interface. This module supports 1536x2048 mode.

Signed-off-by: Yakir Yang 
---
 drivers/gpu/drm/panel/panel-simple.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 3a7bdf1..072c994 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1017,6 +1017,29 @@ static const struct panel_desc lg_lb070wv8 = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
 };
 
+static const struct drm_display_mode lg_lp079qx1_sp0v_mode = {
+   .clock = 20,
+   .hdisplay = 1536,
+   .hsync_start = 1536 + 12,
+   .hsync_end = 1536 + 12 + 16,
+   .htotal = 1536 + 12 + 16 + 48,
+   .vdisplay = 2048,
+   .vsync_start = 2048 + 8,
+   .vsync_end = 2048 + 8 + 4,
+   .vtotal = 2048 + 8 + 4 + 8,
+   .vrefresh = 60,
+   .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc lg_lp079qx1_sp0v = {
+   .modes = _lp079qx1_sp0v_mode,
+   .num_modes = 1,
+   .size = {
+   .width = 129,
+   .height = 171,
+   },
+};
+
 static const struct drm_display_mode lg_lp120up1_mode = {
.clock = 162300,
.hdisplay = 1920,
@@ -1457,6 +1480,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "lg,lb070wv8",
.data = _lb070wv8,
}, {
+   .compatible = "lg,lp079qx1-sp0v",
+   .data = _lp079qx1_sp0v,
+   }, {
.compatible = "lg,lp120up1",
.data = _lp120up1,
}, {
-- 
1.9.1




[PATCH v1 1/5] dt-bindings: Add support for LG LP079QX1-SP0V 1536x2048 panel

2016-06-27 Thread Yakir Yang
The LG LP079QX1-SP0V is an 7.9" QXGA TFT with LED Backlight unit and
32 pins eDP interface. This module supports 1536x2048 mode.

Signed-off-by: Yakir Yang 
---
 .../devicetree/bindings/display/panel/lg,lp079qx1-sp0v.txt | 7 +++
 1 file changed, 7 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/lg,lp079qx1-sp0v.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/lg,lp079qx1-sp0v.txt 
b/Documentation/devicetree/bindings/display/panel/lg,lp079qx1-sp0v.txt
new file mode 100644
index 000..b9877ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/lg,lp079qx1-sp0v.txt
@@ -0,0 +1,7 @@
+LG LP079QX1-SP0V 7.9" (1536x2048 pixels) TFT LCD panel
+
+Required properties:
+- compatible: should be "lg,lp079qx1-sp0v"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
-- 
1.9.1




[PATCH v1 5/5] ARM: dts: rockchip: add the panel power supply for rk3288-evb board with rk808 pmu

2016-06-27 Thread Yakir Yang
Panel regulator is controller by a normal GPIO, so we need to
write a regulator-fixed node for it.

Signed-off-by: Yakir Yang 
---
 arch/arm/boot/dts/rk3288-evb-rk808.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288-evb-rk808.dts 
b/arch/arm/boot/dts/rk3288-evb-rk808.dts
index 736b08b..44ebc6e 100644
--- a/arch/arm/boot/dts/rk3288-evb-rk808.dts
+++ b/arch/arm/boot/dts/rk3288-evb-rk808.dts
@@ -233,3 +233,7 @@
};
};
 };
+
+ {
+   power-supply = <_lcd>;
+};
-- 
1.9.1




[PATCH v1 0/5] Enable graphic support on RK3288 EVB boards

2016-06-27 Thread Yakir Yang

Hi Heiko,

   This series just want to enable the graphic support on RK3288 EVB
boards, most of them are DTS changes, but still have one change about
new eDP panel support.

Thanks,
- Yakir


Yakir Yang (5):
  dt-bindings: Add support for LG LP079QX1-SP0V 1536x2048 panel
  drm/panel: simple: Add support for LG LP079QX1-SP0V 1536x2048 panel
  ARM: dts: rockchip: add eDP/panel display device nodes for rk3288-evb
  ARM: dts: rockchip: add the panel power supply for rk3288-evb board
with act8846 pmu
  ARM: dts: rockchip: add the panel power supply for rk3288-evb board
with rk808 pmu

 .../bindings/display/panel/lg,lp079qx1-sp0v.txt|  7 
 arch/arm/boot/dts/rk3288-evb-act8846.dts   |  4 ++
 arch/arm/boot/dts/rk3288-evb-rk808.dts |  4 ++
 arch/arm/boot/dts/rk3288-evb.dtsi  | 43 +-
 drivers/gpu/drm/panel/panel-simple.c   | 26 +
 5 files changed, 83 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/lg,lp079qx1-sp0v.txt

-- 
1.9.1




[PATCH V4 2/3] powerpc/opal: Add #define to get rc from an ASYNC_COMP opal_msg

2016-06-27 Thread Suraj Jitindar Singh
An opal_msg of type OPAL_MSG_ASYNC_COMP contains the return code in the
params[1] struct member. However this isn't intuitive or obvious when
reading the code and requires that a user look at the skiboot
documentation or opal-api.h to verify this.

Add a #define to get the return code from an opal_msg and update call
sites accordingly.

Signed-off-by: Suraj Jitindar Singh 

---

Change Log:

-> V4:
- Added Patch to Series
---
 arch/powerpc/include/asm/opal-api.h| 4 
 arch/powerpc/platforms/powernv/opal-sensor.c   | 2 +-
 arch/powerpc/platforms/powernv/opal-sysparam.c | 4 ++--
 drivers/i2c/busses/i2c-opal.c  | 2 +-
 drivers/leds/leds-powernv.c| 2 +-
 drivers/mtd/devices/powernv_flash.c| 2 +-
 drivers/rtc/rtc-opal.c | 4 ++--
 7 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/include/asm/opal-api.h 
b/arch/powerpc/include/asm/opal-api.h
index 9bb8ddf..7433cf0 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -387,6 +387,10 @@ struct opal_msg {
__be64 params[8];
 };
 
+#define GET_OPAL_MSG_ASYNC_COMP_RC(msg)(msg.msg_type == 
OPAL_MSG_ASYNC_COMP ? \
+   be64_to_cpu(msg.params[1]) : \
+   OPAL_PARAMETER)
+
 /* System parameter permission */
 enum OpalSysparamPerm {
OPAL_SYSPARAM_READ  = 0x1,
diff --git a/arch/powerpc/platforms/powernv/opal-sensor.c 
b/arch/powerpc/platforms/powernv/opal-sensor.c
index a06059d..f30fc35 100644
--- a/arch/powerpc/platforms/powernv/opal-sensor.c
+++ b/arch/powerpc/platforms/powernv/opal-sensor.c
@@ -55,7 +55,7 @@ int opal_get_sensor_data(u32 sensor_hndl, u32 *sensor_data)
goto out_token;
}
 
-   ret = opal_error_code(be64_to_cpu(msg.params[1]));
+   ret = opal_error_code(GET_OPAL_MSG_ASYNC_COMP_RC(msg));
*sensor_data = be32_to_cpu(data);
break;
 
diff --git a/arch/powerpc/platforms/powernv/opal-sysparam.c 
b/arch/powerpc/platforms/powernv/opal-sysparam.c
index afe66c5..9488bf5 100644
--- a/arch/powerpc/platforms/powernv/opal-sysparam.c
+++ b/arch/powerpc/platforms/powernv/opal-sysparam.c
@@ -67,7 +67,7 @@ static ssize_t opal_get_sys_param(u32 param_id, u32 length, 
void *buffer)
goto out_token;
}
 
-   ret = opal_error_code(be64_to_cpu(msg.params[1]));
+   ret = opal_error_code(GET_OPAL_MSG_ASYNC_COMP_RC(msg));
 
 out_token:
opal_async_release_token(token);
@@ -103,7 +103,7 @@ static int opal_set_sys_param(u32 param_id, u32 length, 
void *buffer)
goto out_token;
}
 
-   ret = opal_error_code(be64_to_cpu(msg.params[1]));
+   ret = opal_error_code(GET_OPAL_MSG_ASYNC_COMP_RC(msg));
 
 out_token:
opal_async_release_token(token);
diff --git a/drivers/i2c/busses/i2c-opal.c b/drivers/i2c/busses/i2c-opal.c
index 75dd6d0..7cd91b7 100644
--- a/drivers/i2c/busses/i2c-opal.c
+++ b/drivers/i2c/busses/i2c-opal.c
@@ -71,7 +71,7 @@ static int i2c_opal_send_request(u32 bus_id, struct 
opal_i2c_request *req)
if (rc)
goto exit;
 
-   rc = be64_to_cpu(msg.params[1]);
+   rc = GET_OPAL_MSG_ASYNC_COMP_RC(msg);
if (rc != OPAL_SUCCESS) {
rc = i2c_opal_translate_error(rc);
goto exit;
diff --git a/drivers/leds/leds-powernv.c b/drivers/leds/leds-powernv.c
index dfb8bd3..3b07a09 100644
--- a/drivers/leds/leds-powernv.c
+++ b/drivers/leds/leds-powernv.c
@@ -118,7 +118,7 @@ static int powernv_led_set(struct powernv_led_data 
*powernv_led,
goto out_token;
}
 
-   rc = be64_to_cpu(msg.params[1]);
+   rc = GET_OPAL_MSG_ASYNC_COMP_RC(msg);
if (rc != OPAL_SUCCESS)
dev_err(dev, "%s : OAPL async call returned failed [rc=%d]\n",
__func__, rc);
diff --git a/drivers/mtd/devices/powernv_flash.c 
b/drivers/mtd/devices/powernv_flash.c
index d5b870b..803059a 100644
--- a/drivers/mtd/devices/powernv_flash.c
+++ b/drivers/mtd/devices/powernv_flash.c
@@ -95,7 +95,7 @@ static int powernv_flash_async_op(struct mtd_info *mtd, enum 
flash_op op,
return -EIO;
}
 
-   rc = be64_to_cpu(msg.params[1]);
+   rc = GET_OPAL_MSG_ASYNC_COMP_RC(msg);
if (rc == OPAL_SUCCESS) {
rc = 0;
if (retlen)
diff --git a/drivers/rtc/rtc-opal.c b/drivers/rtc/rtc-opal.c
index 9c18d6f..0b42645 100644
--- a/drivers/rtc/rtc-opal.c
+++ b/drivers/rtc/rtc-opal.c
@@ -134,7 +134,7 @@ static int opal_get_tpo_time(struct device *dev, struct 
rtc_wkalrm *alarm)
goto exit;
}
 
-   rc = be64_to_cpu(msg.params[1]);
+   rc = GET_OPAL_MSG_ASYNC_COMP_RC(msg);
if (rc != OPAL_SUCCESS) {
rc = -EIO;
goto exit;
@@ -181,7 +181,7 @@ 

[PATCH V4 3/3] powerpc/drivers: Add driver for operator panel on FSP machines

2016-06-27 Thread Suraj Jitindar Singh
Implement new character device driver to allow access from user space
to the operator panel display present on IBM Power Systems machines
with FSPs.

This will allow status information to be presented on the display which
is visible to a user.

The driver implements a character buffer which a user can read/write
by accessing the device (/dev/op_panel). This buffer is then displayed on
the operator panel display. Any attempt to write past the last character
position will have no effect and attempts to write more characters than
the size of the display will be truncated. The device may only be accessed
by a single process at a time.

Signed-off-by: Suraj Jitindar Singh 
Reviewed-by: Andrew Donnellan 

---

Change Log:

V1 -> V2:
- Replace "IBM pSeries machines" with "IBM Power Systems machines
with FSPs" for improved clarity
- Basic wording/grammar fixes
V2 -> V3:
- Nothing
V3 -> V4:
- Various style changes and non-functional code updates
---
 MAINTAINERS|   6 +
 arch/powerpc/configs/powernv_defconfig |   1 +
 arch/powerpc/include/asm/opal.h|   2 +
 arch/powerpc/platforms/powernv/opal-wrappers.S |   1 +
 arch/powerpc/platforms/powernv/opal.c  |   5 +
 drivers/char/Kconfig   |  14 ++
 drivers/char/Makefile  |   1 +
 drivers/char/powernv-op-panel.c| 223 +
 8 files changed, 253 insertions(+)
 create mode 100644 drivers/char/powernv-op-panel.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 952fd2a..42ace38 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9094,6 +9094,12 @@ F:   drivers/firmware/psci.c
 F: include/linux/psci.h
 F: include/uapi/linux/psci.h
 
+POWERNV OPERATOR PANEL LCD DISPLAY DRIVER
+M: Suraj Jitindar Singh 
+L: linuxppc-...@lists.ozlabs.org
+S: Maintained
+F: drivers/char/powernv-op-panel.c
+
 PNP SUPPORT
 M: "Rafael J. Wysocki" 
 S: Maintained
diff --git a/arch/powerpc/configs/powernv_defconfig 
b/arch/powerpc/configs/powernv_defconfig
index 0450310..959d32b 100644
--- a/arch/powerpc/configs/powernv_defconfig
+++ b/arch/powerpc/configs/powernv_defconfig
@@ -181,6 +181,7 @@ CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_JSM=m
 CONFIG_VIRTIO_CONSOLE=m
+CONFIG_POWERNV_OP_PANEL=m
 CONFIG_IPMI_HANDLER=y
 CONFIG_IPMI_DEVICE_INTERFACE=y
 CONFIG_IPMI_POWERNV=y
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 9d86c66..b33e349 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -178,6 +178,8 @@ int64_t opal_dump_ack(uint32_t dump_id);
 int64_t opal_dump_resend_notification(void);
 
 int64_t opal_get_msg(uint64_t buffer, uint64_t size);
+int64_t opal_write_oppanel_async(uint64_t token, oppanel_line_t *lines,
+   uint64_t num_lines);
 int64_t opal_check_completion(uint64_t buffer, uint64_t size, uint64_t token);
 int64_t opal_sync_host_reboot(void);
 int64_t opal_get_param(uint64_t token, uint32_t param_id, uint64_t buffer,
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S 
b/arch/powerpc/platforms/powernv/opal-wrappers.S
index e45b88a..ddba8bf 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -278,6 +278,7 @@ OPAL_CALL(opal_dump_info2,  
OPAL_DUMP_INFO2);
 OPAL_CALL(opal_dump_read,  OPAL_DUMP_READ);
 OPAL_CALL(opal_dump_ack,   OPAL_DUMP_ACK);
 OPAL_CALL(opal_get_msg,OPAL_GET_MSG);
+OPAL_CALL(opal_write_oppanel_async,OPAL_WRITE_OPPANEL_ASYNC);
 OPAL_CALL(opal_check_completion,   OPAL_CHECK_ASYNC_COMPLETION);
 OPAL_CALL(opal_dump_resend_notification,   OPAL_DUMP_RESEND);
 OPAL_CALL(opal_sync_host_reboot,   OPAL_SYNC_HOST_REBOOT);
diff --git a/arch/powerpc/platforms/powernv/opal.c 
b/arch/powerpc/platforms/powernv/opal.c
index 0256d07..228751a 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -751,6 +751,9 @@ static int __init opal_init(void)
opal_pdev_init(opal_node, "ibm,opal-flash");
opal_pdev_init(opal_node, "ibm,opal-prd");
 
+   /* Initialise platform device: oppanel interface */
+   opal_pdev_init(opal_node, "ibm,opal-oppanel");
+
/* Initialise OPAL kmsg dumper for flushing console on panic */
opal_kmsg_init();
 
@@ -885,3 +888,5 @@ EXPORT_SYMBOL_GPL(opal_i2c_request);
 /* Export these symbols for PowerNV LED class driver */
 EXPORT_SYMBOL_GPL(opal_leds_get_ind);
 EXPORT_SYMBOL_GPL(opal_leds_set_ind);
+/* Export this symbol for PowerNV Operator Panel class driver */
+EXPORT_SYMBOL_GPL(opal_write_oppanel_async);
diff --git a/drivers/char/Kconfig 

[PATCH V4 1/3] devicetree/bindings: Add binding for operator panel on FSP machines

2016-06-27 Thread Suraj Jitindar Singh
Add a binding to Documentation/devicetree/bindings/powerpc/opal
(oppanel-opal.txt) for the operator panel which is present on IBM
Power Systems machines with FSPs.

Signed-off-by: Suraj Jitindar Singh 
Acked-by: Rob Herring 
Acked-by: Stewart Smith 

---

Change Log:

V1 -> V2:
- Nothing
V2 -> V3:
- Change "IBM pseries machines" to "IBM Power Systems machines"
in the commit message for improved clarity.
V3 -> V4:
- Nothing
---
 .../devicetree/bindings/powerpc/opal/oppanel-opal.txt  | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/powerpc/opal/oppanel-opal.txt

diff --git a/Documentation/devicetree/bindings/powerpc/opal/oppanel-opal.txt 
b/Documentation/devicetree/bindings/powerpc/opal/oppanel-opal.txt
new file mode 100644
index 000..dffb791
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/opal/oppanel-opal.txt
@@ -0,0 +1,14 @@
+IBM OPAL Operator Panel Binding
+---
+
+Required properties:
+- compatible : Should be "ibm,opal-oppanel".
+- #lines : Number of lines on the operator panel e.g. <0x2>.
+- #length: Number of characters per line of the operator panel e.g. <0x10>.
+
+Example:
+   oppanel {
+   compatible = "ibm,opal-oppanel";
+   #lines = <0x2>;
+   #length = <0x10>;
+   };
-- 
2.5.5



IP ID check (flush_id) in inet_gro_receive is necessary or not?

2016-06-27 Thread Tan Xiaojun
Hi everyone,

I'm sorry to bother you. But I was confused.

The IP ID check (flush_id) in inet_gro_receive is only used by 
tcp_gro_receive, and in tcp_gro_receive we have tcphdr check to ensure the 
order of skbs,
like below:

flush |= (__force int)(th->ack_seq ^ th2->ack_seq);
flush |= (ntohl(th2->seq) + skb_gro_len(p)) ^ ntohl(th->seq);

So if I remove the IP ID check in inet_gro_receive, there will be a 
problem ? And under what circumstances ?


Thanks.
Xiaojun.



RE: [PATCH 1/1] regulator: max77620: check for valid regulator info

2016-06-27 Thread Venkat Reddy Talla
> * PGP Signed by an unknown key
> 
> On Mon, Jun 27, 2016 at 05:13:44PM +0530, Venkat Reddy Talla wrote:
> > Check for valid regulator information data before configuring FPS
> > source and FPS power up/down period to avoid NULL pointer exception if
> > entries for PMIC regulators not provided through device tree.
> 
> This sounds like it's papering over a bug in the driver - the driver should be
> able to instantiate without anything beyond the registration of the device.
> What's the driver relying on from the DT?
> 
Sorry for confusion, there is no dependent on DTS entry, I mean, in probe
SD4 regulator for MAX77620 PMIC is not registered with regulator core framework 
so
Regulator info will be null.

> > SD4 regulator is not supported by MAX77620 PMIC, removing
> > SD4 entry from regulator information list.
> 
> This appears to be a separate change to the above and should be a separate
> patch.
> 
Regulator info data will be null since SD4 regulator is not getting registered 
with core framework,
MAX77620 not supporting SD4 regulator, due to this reason I have included this 
change as part of this patch.
I will change the commit message and push another patch on top of this patch.

Thanks for review.

> * Unknown Key
> * 0x5D5487D0


[RESEND PATCH 2/2] ARM: cache-l2x0.c: Do not clear bit 23 in prefetch control register

2016-06-27 Thread Andrey Smirnov
As per L2C-310 TRM[1]:

"... You can control this feature using bits 30,27 and 23 of the
Prefetch Control Register. Bit 23 and 27 are only used if you set bit 30
HIGH..."

which means there is no need to clear bit 23 if bit 30 is being cleared.

[1] 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0246e/CJAJACBJ.html

Acked-by: Arnd Bergmann 
Signed-off-by: Andrey Smirnov 
---
 arch/arm/mm/cache-l2x0.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 30e2012..12c1ba7 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -715,11 +715,8 @@ static void __init l2c310_fixup(void __iomem *base, u32 
cache_id,
if (revision >= L310_CACHE_ID_RTL_R3P0 &&
revision < L310_CACHE_ID_RTL_R3P2) {
u32 val = l2x0_saved_regs.prefetch_ctrl;
-   /* I don't think bit23 is required here... but iMX6 does so */
-   if (val & (L310_PREFETCH_CTRL_DBL_LINEFILL |
-  L310_PREFETCH_CTRL_DBL_LINEFILL_INCR)) {
-   val &= ~(L310_PREFETCH_CTRL_DBL_LINEFILL |
-L310_PREFETCH_CTRL_DBL_LINEFILL_INCR);
+   if (val & L310_PREFETCH_CTRL_DBL_LINEFILL) {
+   val &= ~L310_PREFETCH_CTRL_DBL_LINEFILL;
l2x0_saved_regs.prefetch_ctrl = val;
errata[n++] = "752271";
}
-- 
2.5.5



[RESEND PATCH 1/2] ARM: cache-l2x0.c: Replace magic numbers

2016-06-27 Thread Andrey Smirnov
Replace magic numbers used for L310 Prefetch Control Register

Acked-by: Arnd Bergmann 
Signed-off-by: Andrey Smirnov 
---
 arch/arm/mm/cache-l2x0.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 9f9d542..30e2012 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -716,8 +716,10 @@ static void __init l2c310_fixup(void __iomem *base, u32 
cache_id,
revision < L310_CACHE_ID_RTL_R3P2) {
u32 val = l2x0_saved_regs.prefetch_ctrl;
/* I don't think bit23 is required here... but iMX6 does so */
-   if (val & (BIT(30) | BIT(23))) {
-   val &= ~(BIT(30) | BIT(23));
+   if (val & (L310_PREFETCH_CTRL_DBL_LINEFILL |
+  L310_PREFETCH_CTRL_DBL_LINEFILL_INCR)) {
+   val &= ~(L310_PREFETCH_CTRL_DBL_LINEFILL |
+L310_PREFETCH_CTRL_DBL_LINEFILL_INCR);
l2x0_saved_regs.prefetch_ctrl = val;
errata[n++] = "752271";
}
-- 
2.5.5



[PATCH 4/5] mmu: remove is_present_gpte()

2016-06-27 Thread Bandan Das
We have two versions of the above function.
To prevent confusion and bugs in the future, remove
the non-FNAME version entirely and replace all calls
with the actual check.

Signed-off-by: Bandan Das 
---
 arch/x86/kvm/mmu.c | 2 +-
 arch/x86/kvm/mmu.h | 5 -
 arch/x86/kvm/paging_tmpl.h | 2 +-
 arch/x86/kvm/x86.c | 2 +-
 4 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index ee2fb16..7197e36 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -3195,7 +3195,7 @@ static int mmu_alloc_shadow_roots(struct kvm_vcpu *vcpu)
MMU_WARN_ON(VALID_PAGE(root));
if (vcpu->arch.mmu.root_level == PT32E_ROOT_LEVEL) {
pdptr = vcpu->arch.mmu.get_pdptr(vcpu, i);
-   if (!is_present_gpte(pdptr)) {
+   if (!(pdptr & PT_PRESENT_MASK)) {
vcpu->arch.mmu.pae_root[i] = 0;
continue;
}
diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h
index 66b33b9..ddc56e9 100644
--- a/arch/x86/kvm/mmu.h
+++ b/arch/x86/kvm/mmu.h
@@ -93,11 +93,6 @@ static inline int kvm_mmu_reload(struct kvm_vcpu *vcpu)
return kvm_mmu_load(vcpu);
 }
 
-static inline int is_present_gpte(unsigned long pte)
-{
-   return pte & PT_PRESENT_MASK;
-}
-
 /*
  * Currently, we have two sorts of write-protection, a) the first one
  * write-protects guest page to sync the guest modification, b) another one is
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 896118e..1384cb7 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -131,7 +131,7 @@ static inline void FNAME(protect_clean_gpte)(unsigned 
*access, unsigned gpte)
 static inline int FNAME(is_present_gpte)(unsigned long pte)
 {
 #if PTTYPE != PTTYPE_EPT
-   return is_present_gpte(pte);
+   return pte & PT_PRESENT_MASK;
 #else
return pte & 7;
 #endif
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 902d9da..dc4fed7 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -537,7 +537,7 @@ int load_pdptrs(struct kvm_vcpu *vcpu, struct kvm_mmu *mmu, 
unsigned long cr3)
goto out;
}
for (i = 0; i < ARRAY_SIZE(pdpte); ++i) {
-   if (is_present_gpte(pdpte[i]) &&
+   if ((pdpte[i] & PT_PRESENT_MASK) &&
(pdpte[i] &
 vcpu->arch.mmu.guest_rsvd_check.rsvd_bits_mask[0][2])) {
ret = 0;
-- 
2.5.5



[PATCH 2/5] mmu: pass execonly value when initializing rsvd bits

2016-06-27 Thread Bandan Das
In reset_tdp_shadow_zero_bits_mask, we always pass false
when initializing the reserved bits. By initializing with the
correct value of ept exec only, the host can correctly
identify if the guest pte is valid. Note that
kvm_init_shadow_ept_mmu() already knows about execonly.

Signed-off-by: Bandan Das 
---
 arch/x86/kvm/mmu.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index a50af79..875d4f7 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -3831,23 +3831,27 @@ static inline bool boot_cpu_is_amd(void)
 
 /*
  * the direct page table on host, use as much mmu features as
- * possible, however, kvm currently does not do execution-protection.
+ * possible
  */
 static void
 reset_tdp_shadow_zero_bits_mask(struct kvm_vcpu *vcpu,
struct kvm_mmu *context)
 {
+   bool execonly;
+
if (boot_cpu_is_amd())
__reset_rsvds_bits_mask(vcpu, >shadow_zero_check,
boot_cpu_data.x86_phys_bits,
context->shadow_root_level, false,
boot_cpu_has(X86_FEATURE_GBPAGES),
true, true);
-   else
+   else {
+   execonly = !(context->guest_rsvd_check.bad_mt_xwr &
+(1ull << VMX_EPT_EXECUTABLE_MASK));
__reset_rsvds_bits_mask_ept(>shadow_zero_check,
boot_cpu_data.x86_phys_bits,
-   false);
-
+   execonly);
+   }
 }
 
 /*
-- 
2.5.5



[PATCH 5/5] nvmx: advertise support for ept execute only

2016-06-27 Thread Bandan Das
KVM MMU now knows about execute only mappings, so
advertise the feature to L1 hypervisors

Signed-off-by: Bandan Das 
---
 arch/x86/kvm/vmx.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 417debc..0fe61a3 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2717,6 +2717,9 @@ static void nested_vmx_setup_ctls_msrs(struct vcpu_vmx 
*vmx)
vmx->nested.nested_vmx_ept_caps = VMX_EPT_PAGE_WALK_4_BIT |
 VMX_EPTP_WB_BIT | VMX_EPT_2MB_PAGE_BIT |
 VMX_EPT_INVEPT_BIT;
+   if (cpu_has_vmx_ept_execute_only())
+   vmx->nested.nested_vmx_ept_caps |=
+   VMX_EPT_EXECUTE_ONLY_BIT;
vmx->nested.nested_vmx_ept_caps &= vmx_capability.ept;
/*
 * For nested guests, we don't do anything specific
-- 
2.5.5



[PATCH 0/5] Add support for EPT execute only for nested hypervisors

2016-06-27 Thread Bandan Das
These patches are based on reviews to my RFC
http://www.spinics.net/lists/kvm/msg134440.html

Changes since RFC:
 - Remove shadow_xonly_valid, it's not needed
 - Remove checks from is_shadow_present_pte()
 - In reset_tdp_shadow_zero_bits_mask, pass correct execonly to 
__reset_rsvds_bits_mask_ept
 - Reuse shadow_user_mask in set_spte()
 - Remove is_present_gpte() and inline the operation at the two call sites

I spoke to Paolo about this a while back and thought to post this as
RFC while I am thinking of adding some unit tests.

Background: ESX refuses to run as L1 if support for EPT execute only isn't
found. I am not really sure if it uses it for anything since just advertising
the bits seems to work but adding the necessary plumbing seemed like a good 
idea.

Xiao, I took the liberty of adding you based on "git blame" :)

Thanks in advance.

Bandan Das (5):
  mmu: mark spte present if the x bit is set
  mmu: pass execonly value when initializing rsvd bits
  mmu: don't set the present bit unconditionally
  mmu: remove is_present_gpte()
  nvmx: advertise support for ept execute only

 arch/x86/kvm/mmu.c | 26 ++
 arch/x86/kvm/mmu.h |  5 -
 arch/x86/kvm/paging_tmpl.h |  4 ++--
 arch/x86/kvm/vmx.c |  5 -
 arch/x86/kvm/x86.c |  2 +-
 5 files changed, 25 insertions(+), 17 deletions(-)

-- 
2.5.5



[PATCH 3/5] mmu: don't set the present bit unconditionally

2016-06-27 Thread Bandan Das
To support execute only mappings on behalf of L1
hypervisors, we teach set_spte() to honor L1's valid XWR
bits. This is only if host supports EPT execute only. Reuse
ACC_USER_MASK to signify if the L1 hypervisor has the R bit
set

Signed-off-by: Bandan Das 
---
 arch/x86/kvm/mmu.c | 9 +++--
 arch/x86/kvm/paging_tmpl.h | 2 +-
 arch/x86/kvm/vmx.c | 2 +-
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 875d4f7..ee2fb16 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -2516,13 +2516,17 @@ static int set_spte(struct kvm_vcpu *vcpu, u64 *sptep,
gfn_t gfn, kvm_pfn_t pfn, bool speculative,
bool can_unsync, bool host_writable)
 {
-   u64 spte;
+   u64 spte = 0;
int ret = 0;
+   struct kvm_mmu *context = >arch.mmu;
+   bool execonly = !(context->guest_rsvd_check.bad_mt_xwr &
+ (1ull << VMX_EPT_EXECUTABLE_MASK));
 
if (set_mmio_spte(vcpu, sptep, gfn, pfn, pte_access))
return 0;
 
-   spte = PT_PRESENT_MASK;
+   if (!execonly)
+   spte |= PT_PRESENT_MASK;
if (!speculative)
spte |= shadow_accessed_mask;
 
@@ -2531,6 +2535,7 @@ static int set_spte(struct kvm_vcpu *vcpu, u64 *sptep,
else
spte |= shadow_nx_mask;
 
+   /* In the EPT case, shadow_user_mask is PT_PRESENT_MASK */
if (pte_access & ACC_USER_MASK)
spte |= shadow_user_mask;
 
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index bc019f7..896118e 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -187,7 +187,7 @@ static inline unsigned FNAME(gpte_access)(struct kvm_vcpu 
*vcpu, u64 gpte)
 #if PTTYPE == PTTYPE_EPT
access = ((gpte & VMX_EPT_WRITABLE_MASK) ? ACC_WRITE_MASK : 0) |
((gpte & VMX_EPT_EXECUTABLE_MASK) ? ACC_EXEC_MASK : 0) |
-   ACC_USER_MASK;
+   ((gpte & VMX_EPT_READABLE_MASK) ? ACC_USER_MASK : 0);
 #else
BUILD_BUG_ON(ACC_EXEC_MASK != PT_PRESENT_MASK);
BUILD_BUG_ON(ACC_EXEC_MASK != 1);
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 003618e..417debc 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -6366,7 +6366,7 @@ static __init int hardware_setup(void)
vmx_disable_intercept_msr_write_x2apic(0x83f);
 
if (enable_ept) {
-   kvm_mmu_set_mask_ptes(0ull,
+   kvm_mmu_set_mask_ptes(PT_PRESENT_MASK,
(enable_ept_ad_bits) ? VMX_EPT_ACCESS_BIT : 0ull,
(enable_ept_ad_bits) ? VMX_EPT_DIRTY_BIT : 0ull,
0ull, VMX_EPT_EXECUTABLE_MASK);
-- 
2.5.5



[PATCH 1/5] mmu: mark spte present if the x bit is set

2016-06-27 Thread Bandan Das
This is safe because is_shadow_present_pte() is called
on host controlled page table and we know the spte is
valid

Signed-off-by: Bandan Das 
---
 arch/x86/kvm/mmu.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index def97b3..a50af79 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -304,7 +304,8 @@ static int is_nx(struct kvm_vcpu *vcpu)
 
 static int is_shadow_present_pte(u64 pte)
 {
-   return pte & PT_PRESENT_MASK && !is_mmio_spte(pte);
+   return pte & (PT_PRESENT_MASK | shadow_x_mask) &&
+   !is_mmio_spte(pte);
 }
 
 static int is_large_pte(u64 pte)
-- 
2.5.5



Re: [PATCH] arc: warn only once if DW2_UNWIND is disabled

2016-06-27 Thread Vineet Gupta
On Thursday 23 June 2016 01:30 PM, Alexey Brodkin wrote:
> If CONFIG_ARC_DW2_UNWIND is disabled every time arc_unwind_core()
> gets called following message gets printed in debug console:
> ->8---
> CONFIG_ARC_DW2_UNWIND needs to be enabled
> ->8---
> 
> That message makes sense if user indeed wants to see a backtrace or
> get nice function call-graphs in perf but what if user disabled
> unwinder for the purpose? Why pollute his debug console?
> 
> So instead we'll warn user about possibly missing feature once and
> let him decide if that was what he or she really wanted.
> 
> Signed-off-by: Alexey Brodkin 
> Cc: sta...@vger.kernel.org  [3.18+]

Does this really need to be stable backport ?

> ---
>  arch/arc/kernel/stacktrace.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arc/kernel/stacktrace.c b/arch/arc/kernel/stacktrace.c
> index e0efff1..b9192a6 100644
> --- a/arch/arc/kernel/stacktrace.c
> +++ b/arch/arc/kernel/stacktrace.c
> @@ -142,7 +142,7 @@ arc_unwind_core(struct task_struct *tsk, struct pt_regs 
> *regs,
>* prelogue is setup (callee regs saved and then fp set and not other
>* way around
>*/
> - pr_warn("CONFIG_ARC_DW2_UNWIND needs to be enabled\n");
> + pr_warn_once("CONFIG_ARC_DW2_UNWIND needs to be enabled\n");
>   return 0;
>  
>  #endif
> 



Re: [PATCH v3 0/3] toshiba_acpi: Accelerometer updates

2016-06-27 Thread Darren Hart
On Mon, Jun 27, 2016 at 07:46:42PM -0600, Azael Avalos wrote:
> These series of patches update the accelerometer axis data
> reporting to use the IIO subsystem, deprecating the custom
> position sysfs entry, and finally bumping the driver version
> to 0.24.
> 

Thanks Azael, queued to testing for 4.8.

Jonathan, I took the full set.

> Changes since v2:
> - Small format and style changes once again
> - Renamed toshiba_accel* functions to toshiba_iio_accel* to
>   differentiate from the iio functions and the toshiba_acpi
>   driver fuctions
> - Print error messages instead of bailing out in case the
>   iio_device* functions fail, this is to allow the driver
>   to continue loading its many functions
> 
> Changes since v1:
> - Small format and style changes
> - Changed the iio code according to feedback from Jonathan Cameron
> 
> Azael Avalos (3):
>   toshiba_acpi: Add IIO interface for accelerometer axis data
>   toshiba_acpi: Remove the position sysfs entry
>   toshiba_acpi: Bump driver version and update copyright year
> 
>  drivers/platform/x86/toshiba_acpi.c | 136 
> +---
>  1 file changed, 109 insertions(+), 27 deletions(-)
> 
> -- 
> 2.8.4
> 
> 

-- 
Darren Hart
Intel Open Source Technology Center


Re: [PATCH 2/4] dmaengine: vdma: Add support for mulit-channel dma mode

2016-06-27 Thread Vinod Koul
On Wed, Jun 22, 2016 at 07:04:28AM +, Appana Durga Kedareswara Rao wrote:
> > > >
> > > > Can you elobrate what you meant by Multichannel mode? This patch
> > > > seems to do two things, one is to add interleaved dma support and
> > > > something else. Can you explain the latter part?
> > >
> > > AXI DMA has two Stream interfaces (Memory to Stream MM2S and Stream to
> > > Memory S2MM)
> > 
> > what is a stream in this context?
> 
> Stream means I/O transfer (Memory to I/O and I/O to Memory).
> Sorry if I confused you.
> 
> > 
> > > In Multi-Channel dma mode each stream interface can be configured up to 16
> > channels.
> > > In Multi-channel DMA mode IP supports only interleaved transfers (2-D
> > transfers).
> > 
> > 
> > >
> > > >
> > > > >  /**
> > > > > + * struct xilinx_mcdma_config - DMA Multi channel configuration
> > > > > +structure
> > > > > + * @tdest: Channel to operate on
> > > > > + * @tid:   Channel configuration
> > > > > + * @tuser: Tuser configuration
> > > > > + * @ax_user: ax_user value
> > > > > + * @ax_cache: ax_cache value
> > > > > + */
> > > > > +struct xilinx_mcdma_config {
> > > > > + u8 tdest;
> > > > > + u8 tid;
> > > > > + u8 tuser;
> > > > > + u8 ax_user;
> > > > > + u8 ax_cache;
> > > >
> > > > can you describe these in details, what do these do, what are the
> > > > values to be programmed?
> > >
> > > As said above In Multi-Channel Mode each Stream interface can be
> > > Configured up to 16 channels each channel is differentiated based on the 
> > > tdest
> > and tid values.
> > 
> > Then why are you not registering 16 channels for this? That should give you
> > channel to operate on!
> 
> The number of channels are configurable.
> We are registering number of Channels that h/w configured for.
> 
> Will fix in the next version. Will remove this config.
> And based on the channel type will configure the h/w.

Looking at this you should redesign!

The vchan was designed to operate on 'virtual' channels. The hardware
channels can be independent of that.

Your IP seems to be a good fit for that approach. Do not link the two and
separate them. User can have a virtual channel. In your driver, you can
manage hardware channels...

> 
> > 
> > >
> > > tdest:
> > > TDEST provides routing information for the data stream.
> > 
> > pls elobrate
> 
> Need to configure this with the channel number that
> We would like to transfer data.

This should be internal to driver...

-- 
~Vinod


Re: [PATCH 01/21] of: device: Support loading a module with OF based modalias

2016-06-27 Thread Bjorn Andersson
On Sun 26 Jun 00:28 PDT 2016, Stephen Boyd wrote:

> In the case of ULPI devices, we want to be able to load the
> driver before registering the device so that we don't get stuck
> in a loop waiting for the phy module to appear and failing usb
> controller probe. Currently we request the ulpi module via the
> ulpi ids, but in the DT case we might need to request it with the
> OF based modalias instead. Add a common function that allows
> anyone to request a module with the OF based modalias.
> 
> Cc: Rob Herring 
> Cc: 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/of/device.c   | 50 
> +++
>  include/linux/of_device.h |  6 ++
>  2 files changed, 56 insertions(+)
> 
> diff --git a/drivers/of/device.c b/drivers/of/device.c
> index fd5cfad7c403..f275e5beb736 100644
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -226,6 +226,56 @@ ssize_t of_device_get_modalias(struct device *dev, char 
> *str, ssize_t len)
>   return tsize;
>  }
>  
> +static ssize_t of_device_modalias_size(struct device *dev)
> +{
> + const char *compat;
> + int cplen, i;
> + ssize_t csize;
> +
> + if ((!dev) || (!dev->of_node))
> + return -ENODEV;
> +
> + /* Name & Type */
> + csize = 5 + strlen(dev->of_node->name) + strlen(dev->of_node->type);

It would be clearer if you replaced 5 with strlen("of:NT"), but...

> +
> + /* Get compatible property if any */
> + compat = of_get_property(dev->of_node, "compatible", );
> + if (!compat)
> + return csize;
> +
> + /* Find true end (we tolerate multiple \0 at the end */
> + for (i = (cplen - 1); i >= 0 && !compat[i]; i--)
> + cplen--;
> + if (!cplen)
> + return csize;
> + cplen++;
> +
> + /* Check space (need cplen+1 chars including final \0) */
> + return csize + cplen;
> +}

...if I understand of_device_get_modalias() correctly you should be able
to replace this function with:

  size = of_device_get_modalias(dev, NULL, 0);

snprintf() will not write to NULL, csize will be larger than 0 so tsize
will be returned before it will memcpy() to the buffer.

> +
> +int of_device_request_module(struct device *dev)
> +{
> + char *str;
> + ssize_t size;
> + int ret;
> +
> + size = of_device_modalias_size(dev);
> + if (size < 0)
> + return size;
> +
> + str = kmalloc(size + 1, GFP_KERNEL);
> + if (!str)
> + return -ENOMEM;
> +
> + of_device_get_modalias(dev, str, size);
> + str[size] = '\0';
> + ret = request_module(str);
> + kfree(str);
> +
> + return ret;
> +}
> +

Regards,
Bjorn


Re: arch/powerpc/xmon/dis-asm.h: 2 * wrong specifiers ?

2016-06-27 Thread Michael Ellerman
On Mon, 2016-06-27 at 09:04 +0100, David Binderman wrote:

> Hello there,
> 
> linux-4.7-rc5/arch/powerpc/xmon/dis-asm.h:20]: (warning) %x in format
> string (no. 1) requires 'unsigned int' but the argument type is
> 'unsigned long'.
> [linux-4.7-rc5/arch/powerpc/xmon/dis-asm.h:26]: (warning) %x in format
> string (no. 1) requires 'unsigned int' but the argument type is
> 'unsigned long'.

What config / toolchain are you using? I've never seen these.

Oh, I see, with CONFIG_XMON_DISASSEMBLY=n.

> static inline int print_insn_powerpc(unsigned long insn, unsigned long 
> memaddr)
> {
> printf("%.8x", insn);
> return 0;
> }

Send me a patch to cast insn to unsigned int?

cheers



Re: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support

2016-06-27 Thread Vinod Koul
On Tue, Jun 21, 2016 at 05:29:42PM +, Punnaiah Choudary Kalluri wrote:
> 
> Ok agree with you for the scenario that I have mentioned above.
> 
> Other simple dma mode feature that I missed to explain is configuring the 
> Dma descriptors. It provides a register interface for configuring the dma 
> transaction.
> So, no need to maintain the descriptors in memory and it will be useful for 
> the system 
> that are in crunch of memory.  

And why are these not coming out in the first place, which makes me think it
is fishy!

Do you mean programming DMA descriptors to hardware and you can use
registers instead of memory?

> 
> How do you want us to handle this case?
> 

> > Okay I am convince now this is not right approach. Please remove this
> > custom interface and then implement slave for required slave scenarios!
> >
> 
> Assume controller is having 8 channels and four of them are used for slave
> Dma and others are for memcpy.
> Controller didn't have the per channel priority control but providing the 
> rate control
> Mechanism. 

How does the use of few for memcpy and few for slave change things? IMO it
doesn't, you program the channel accordingly

> 
> So, I need some interface for configuring the rate control per channel at run 
> time irrespective
> Of whether the channel is allocated for slave dma or memcpy dma.

why?

> Is it wrong having the configurable dma parameters for dma memcpy operation? 
> We are exposing the
> Hw capabilities to the user for better dma transaction management.

For memcpy yes. Memcpy is a generic case where people do not do driver
specific stuff. So I tend ot push back on that..

For slave, existing APIs allow you to program the additional parameters..
FWIW, rate control is a generic parameter which if you justify enough can be
added to dma_slave_config

Thanks
-- 
~Vinod


Re: [PATCH 7/8] dmaengine: tegra20-apb-dma: Only calculate residue if txstate exists.

2016-06-27 Thread Vinod Koul
On Tue, Jun 21, 2016 at 06:19:50PM +0100, Jon Hunter wrote:
> 
> On 21/06/16 17:01, Vinod Koul wrote:
> > On Wed, Jun 08, 2016 at 09:51:57AM +0100, Jon Hunter wrote:
> >> Hi Peter,
> >>
> >> On 07/06/16 18:38, Peter Griffin wrote:
> >>> There is no point calculating the residue if there is
> >>> no txstate to store the value.
> >>>
> >>> Signed-off-by: Peter Griffin 
> >>> ---
> >>>  drivers/dma/tegra20-apb-dma.c | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
> >>> index 01e316f..7f4af8c 100644
> >>> --- a/drivers/dma/tegra20-apb-dma.c
> >>> +++ b/drivers/dma/tegra20-apb-dma.c
> >>> @@ -814,7 +814,7 @@ static enum dma_status tegra_dma_tx_status(struct 
> >>> dma_chan *dc,
> >>>   unsigned int residual;
> >>>  
> >>>   ret = dma_cookie_status(dc, cookie, txstate);
> >>> - if (ret == DMA_COMPLETE)
> >>> + if (ret == DMA_COMPLETE || !txstate)
> >>>   return ret;
> >>
> >> Thanks for reporting this. I agree that we should not do this, however, 
> >> looking at the code for Tegra, I am wondering if this could change the
> >> actual state that is returned. Looking at dma_cookie_status() it will
> >> call dma_async_is_complete() which will return either DMA_COMPLETE or
> >> DMA_IN_PROGRESS. It could be possible that the actual state for the
> >> DMA transfer in the tegra driver is DMA_ERROR, so I am wondering if we
> >> should do something like the following  ...
> > 
> > This one is stopping code execution when residue is not valid. Do notice
> > that it check for DMA_COMPLETE OR txstate. In other cases, wit will return
> > 'that' state when txstate is NULL.
> 
> Sorry what do you mean by "this one"?

the patch

> 
> My point is that if the status is not DMA_COMPLETE, then it is possible
> that it could be DMA_ERROR (for tegra that is). 

right it can be any state... and we check for only DMA_COMPLETE as residue
has no meaning.

> However,
> dma_cookie_status will only return DMA_IN_PROGRESS or DMA_COMPLETE and
> so if 'txstate' is NULL we will not see the DMA_ERROR status anymore and
> just think it is in progress when it is actually an error.

Yes that is an existing issue, if you are reporting DMA_ERROR then you
should add a check for DMA_ERROR as well and not do residue calculation for
that case.

> 
> I do agree that the driver is broken as we are not checking for
> !txstate, but this also changes the behaviour a bit.

It changes for better and not worse. Btw pls feel free to send a patch
handling DMA_ERROR :)

-- 
~Vinod


Re: [PATCH] rtlwifi: Create _rtl_dbg_trace function to reduce RT_TRACE code size

2016-06-27 Thread Joe Perches
On Mon, 2016-06-27 at 19:53 -0500, Larry Finger wrote:
> On 06/25/2016 05:46 PM, Joe Perches wrote:
> > 
> > This debugging macro can expand to a lot of code.
> > Make it a function to reduce code size.
> > 
> > (x86-64 defconfig w/ all rtlwifi drivers and allyesconfig)
> > $ size drivers/net/wireless/realtek/rtlwifi/built-in.o*
> > text   data bss dec hex filename
> >   900083 200499    1907 1102489  10d299 
> > drivers/net/wireless/realtek/rtlwifi/built-in.o.defconfig.new
> > 1113597  200499    1907 1316003  1414a3 
> > drivers/net/wireless/realtek/rtlwifi/built-in.o.defconfig.old
> > 1746879  453503    8512 2208894  21b47e 
> > drivers/net/wireless/realtek/rtlwifi/built-in.o.new
> > 2051965  503311    8512 2563788  271ecc 
> > drivers/net/wireless/realtek/rtlwifi/built-in.o.old
> > 
> > Signed-off-by: Joe Perches 
> I acked this before; however there is a bug that breaks the build if 
> CONFIG_RTLWIFI_DEBUG is not defined. The rest of the code calls 
> _rtl_dbg_trace(), but that symbol is never defined. The problem can be fixed 
> in 
> debug.c or debug.h.

Confused a bit.  What breaks again?

debug.h:

#ifdef CONFIG_RTLWIFI_DEBUG
[]
__printf(5, 6)
void _rtl_dbg_trace(struct rtl_priv *rtlpriv, int comp, int level,
const char *modname, const char *fmt, ...);

#define RT_TRACE(rtlpriv, comp, level, fmt, ...)\
_rtl_dbg_trace(rtlpriv, comp, level,\
   KBUILD_MODNAME, fmt, ##__VA_ARGS__)
[]
#else
[]
__printf(4, 5)
static inline void RT_TRACE(struct rtl_priv *rtlpriv,
int comp, int level,
const char *fmt, ...)
{
}
[]
#endif


Re: [PATCH 1/8] tty: serial: fsl_lpuart: consider TX FIFO too in tx_empty

2016-06-27 Thread Bhuvanchandra DV

On 06/26/16 02:56, Greg KH wrote:


On Thu, Jun 09, 2016 at 08:40:32PM +0530, Bhuvanchandra DV wrote:

From: Stefan Agner 

Currently the tx_empty callback only considers the Transmit Complete
Flag (TC). The reference manual is not quite clear if the TC flag
covers the TX FIFO too. Debug prints on real hardware have shown that
from time to time the TC flag is asserted (indicating Transmitter
idle) while there are still data in the TX FIFO. Hence, in this case
the serial core will call the shutdown callback even though there are
data remaining in the TX FIFO buffers.

Avoid early shutdowns by considering the TX FIFO empty flag too. Also
avoid theoretical race conditions between DMA and the driver by
checking whether the TX DMA is in progress too.

Signed-off-by: Stefan Agner 
---
  drivers/tty/serial/fsl_lpuart.c | 14 --
  1 file changed, 12 insertions(+), 2 deletions(-)

Why are you not signing off on patches that are flowing through you?
Please fix this up and resend the series, after breaking up the clock
change as asked.


Okay



thanks,

greg k-h




Re: powerpc/fadump: trivial fix of spelling mistake, clean up message

2016-06-27 Thread Michael Ellerman
On Mon, 2016-06-27 at 12:34 +0100, Colin Ian King wrote:
> On 27/06/16 12:20, Michael Ellerman wrote:
> > On Mon, 2016-06-27 at 03:51 -0700, Joe Perches wrote:
> > > On Mon, 2016-06-27 at 11:38 +0100, Colin Ian King wrote:
> > > > On 26/06/16 05:19, Michael Ellerman wrote:
> > > > > On Fri, 2016-24-06 at 17:43:00 UTC, Colin King wrote:
> > > > > > trivial fix to spelling mistake "rgistration" and minor clean up
> > > > > > of the printk error message
> > > > > Can you also:
> > > > >  - use pr_err()
> > > > >  - unsplit the message, ie. keep the string all on one line.
> > > > I can unsplit the string, but checkpatch will complain about that, so
> > > > I'm not sure if that's preferred or not.
> > > > 
> > > > WARNING: line over 80 characters
> > > 
> > > If the statement is wrapped after the format,
> > > then checkpatch shouldn't complain.
> > > 
> > >   pr_err("Failed to invalidate firmware-assisted dump registration. 
> > > Unexpected error (%d).\n",
> > >  rc);
> > 
> > But that's not actually any more readable, so just ignore checkpatch in this
> > case IMHO. It's a guide, not the gospel.
>
> OK, so shall I'll send a V3 w/o the spit and the pr_err fix?

Nah that's fine, I already grabbed v2.

cheers



Re: [ftrace] kernel panics during my attempt to use ftrace

2016-06-27 Thread Namhyung Kim
Hello,

On Tue, Jun 21, 2016 at 9:53 PM, Enrico Mioso  wrote:
> Hello guys.
>
> First of all - thank you for your great work in ftrace, and in general in
> the Linux tracing infrastructure. I am a newbie: so I am not able to use it
> at it's full power, still I find it's capabilities impressive.
>
> I am asking for help, since I am encountering some problems in using ftrace.
> I am trying to come up with a solution to trace a specific workload (a
> program): to understand what are the functions the kernel spends most of his
> time in.
> To do so, I inspired myself to some code I found around (I can mention it if
> needed). I took free inspiration: so my editing may be very very wrong.
> When I run this script, the kernel panics. the output is below. the kernel
> is Ubuntu 16.04 stock, running in a qemu virtual machine (using kvm).

Please check commit 8329e818f149 ("ftrace/x86: Set ftrace_stub to weak
to prevent gcc from using short jumps to it") The ubuntu 16.04 seems to
have binutils 2.26 which is same version that caused trouble in my system.

Thanks,
Namhyung


> Any help would be greatly apreciated. Thank you very much guys.
> Fort any needed infos, contact me.
> Enrico


Re: [PATCH 2/3] powerpc/spinlock: support vcpu preempted check

2016-06-27 Thread xinhui



On 2016年06月27日 22:58, Boqun Feng wrote:

Hi Xinhui,

On Mon, Jun 27, 2016 at 01:41:29PM -0400, Pan Xinhui wrote:

This is to fix some holder preemption issues. Spinning at one
vcpu which is preempted is meaningless.

Kernel need such interfaces, So lets support it.

We also should suooprt both the shared and dedicated mode.
So add lppaca_dedicated_proc macro in lppaca.h

Suggested-by: Boqun Feng 
Signed-off-by: Pan Xinhui 
---
  arch/powerpc/include/asm/lppaca.h   |  6 ++
  arch/powerpc/include/asm/spinlock.h | 15 +++
  2 files changed, 21 insertions(+)

diff --git a/arch/powerpc/include/asm/lppaca.h 
b/arch/powerpc/include/asm/lppaca.h
index d0a2a2f..0a263d3 100644
--- a/arch/powerpc/include/asm/lppaca.h
+++ b/arch/powerpc/include/asm/lppaca.h
@@ -111,12 +111,18 @@ extern struct lppaca lppaca[];
   * we will have to transition to something better.
   */
  #define LPPACA_OLD_SHARED_PROC2
+#define LPPACA_OLD_DEDICATED_PROC  (1 << 6)



I think you should describe a little bit about the magic number here,

right.


i.e. what document/specification says this should work, and how this
works.


yep, I need add some comments here. for example, this bit is firmware 
reserved...
thanks, will do that.


  static inline bool lppaca_shared_proc(struct lppaca *l)
  {
return !!(l->__old_status & LPPACA_OLD_SHARED_PROC);
  }

+static inline bool lppaca_dedicated_proc(struct lppaca *l)
+{
+   return !!(l->__old_status & LPPACA_OLD_DEDICATED_PROC);
+}
+
  /*
   * SLB shadow buffer structure as defined in the PAPR.  The save_area
   * contains adjacent ESID and VSID pairs for each shadowed SLB.  The
diff --git a/arch/powerpc/include/asm/spinlock.h 
b/arch/powerpc/include/asm/spinlock.h
index 523673d..ae938ee 100644
--- a/arch/powerpc/include/asm/spinlock.h
+++ b/arch/powerpc/include/asm/spinlock.h
@@ -52,6 +52,21 @@
  #define SYNC_IO
  #endif

+/* For fixing some spinning issues in a guest.
+ * kernel would check if vcpu is preempted during a spin loop.
+ * we support that.
+ */
+#define arch_vcpu_is_preempted arch_vcpu_is_preempted
+static inline bool arch_vcpu_is_preempted(int cpu)


This function should be guarded by #ifdef PPC_PSERIES .. #endif, right?
Because if the kernel is not compiled with guest support,
vcpu_is_preempted() should always be false, right?


oh, I forgot that. thanks for pointing it out.


+{
+   struct lppaca *lp = _of(cpu);
+
+   if (unlikely(!(lppaca_shared_proc(lp) ||
+   lppaca_dedicated_proc(lp


Do you want to detect whether we are running in a guest(ie. pseries
kernel) here? Then I wonder whether "machine_is(pseries)" works here.


I tried as you said yesterday. but .h file has dependencies.
As you said, if we add #ifdef PPC_PSERIES, this is not a big problem. only 
powernv will be affected as they are built into same kernel img.


Regards,
Boqun


+   return false;
+   return !!(be32_to_cpu(lp->yield_count) & 1);
+}
+
  static __always_inline int arch_spin_value_unlocked(arch_spinlock_t lock)
  {
return lock.slock == 0;
--
2.4.11





Re: [PATCH] Decouple CFG and IO in Designware PCIe Driver

2016-06-27 Thread Pratyush Anand
On Mon, Jun 27, 2016 at 6:38 PM, dongbo (E)  wrote:
> Hi, all.
>
> How about exchanging the assignments of `MEMORYs' and `CFGs/IOs'?
> In other words, assign MEMEORYs to iatu0, CFGs and IOs to iatu1.
>
> Once the iatu0 is initialized to MEMORY accesses, its BASE_ADDR,
> LIMIT and TYPE is fixed. MEMORYs match with iatu0 at first, so
> they will never being treated as IOs or CFGs by mistake.

This should be acceptable, so you can send it as a formal patch.

However, other corner point for failure is still there. Suppose,
another thread tries to write on IO space when iatu1 was programmed
for CFG.

~Pratyush

>
> The number of viewpoints used remains two, it would be OK for
> platforms only have 2 viewpoints.
>
> Here is the patch:
>
> Signed-off-by: Dong Bo 
> ---
>  drivers/pci/host/pcie-designware.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/host/pcie-designware.c 
> b/drivers/pci/host/pcie-designware.c
> index aafd766..1bd88d9 100644
> --- a/drivers/pci/host/pcie-designware.c
> +++ b/drivers/pci/host/pcie-designware.c
> @@ -599,11 +599,11 @@ static int dw_pcie_rd_other_conf(struct pcie_port *pp, 
> struct pci_bus *bus,
> va_cfg_base = pp->va_cfg1_base;
> }
>
> -   dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX0,
> +   dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX1,
>   type, cpu_addr,
>   busdev, cfg_size);
> ret = dw_pcie_cfg_read(va_cfg_base + where, size, val);
> -   dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX0,
> +   dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX1,
>   PCIE_ATU_TYPE_IO, pp->io_base,
>   pp->io_bus_addr, pp->io_size);
>
> @@ -636,11 +636,11 @@ static int dw_pcie_wr_other_conf(struct pcie_port *pp, 
> struct pci_bus *bus,
> va_cfg_base = pp->va_cfg1_base;
> }
>
> -   dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX0,
> +   dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX1,
>   type, cpu_addr,
>   busdev, cfg_size);
> ret = dw_pcie_cfg_write(va_cfg_base + where, size, val);
> -   dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX0,
> +   dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX1,
>   PCIE_ATU_TYPE_IO, pp->io_base,
>   pp->io_bus_addr, pp->io_size);
>
> @@ -779,7 +779,7 @@ void dw_pcie_setup_rc(struct pcie_port *pp)
>  * we should not program the ATU here.
>  */
> if (!pp->ops->rd_other_conf)
> -   dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX1,
> +   dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX0,
>   PCIE_ATU_TYPE_MEM, pp->mem_base,
>   pp->mem_bus_addr, pp->mem_size);
>
> --
> 1.9.1
>
> On 2016/6/27 12:37, Pratyush Anand wrote:
>> On Wed, Jun 22, 2016 at 1:54 PM, dongbo (E)  wrote:
>>> From: Dong Bo 
>>>
>>> In designware PCIe driver, the iatu0 is used for both CFG and IO accesses.
>>> When PCIe sends CFGs to peripherals (e.g. lspci),
>>> iatu0 frequently switches between CFG and IO alternatively.
>>>
>>> If the LIMIT of MEMORY is a value between CFGs BASE_ADDR and IOs LIMIT,
>>> this probably results in a MEMORY beging matched to be an IO by mistake.
>>>
>>> Considering the following configurations:
>>> MEMORY  ->  BASE_ADDR: 0xb410, LIMIT: 0xb4100FFF, TYPE=mem
>>> CFG ->  BASE_ADDR: 0xb400, LIMIT: 0xb4000FFF, TYPE=cfg
>>> IO  ->  BASE_ADDR: 0x, LIMIT: 0xFFFE, TYPE=io
>>> Suppose PCIe has just completed a CFG access, to switch back to IO, it set 
>>> the BASE_ADDR to 0x, LIMIT 0xFFFE and TYPE to io.
>>> When another CFG access come,
>>> PCIe first set BASE_ADDR to 0xb400 to switch to CFG.
>>> At this moment, a MEMORY access shows up, due to `0xb400 <= MEMORY 
>>> BASE_ADDR <= MEMORY LIMIE <= 0xFFF, it matches with iatu0.
>>> And it is treated as an IO access by mistake, then sent to perpheral.
>>>
>>
>> Hummm...This portion of driver has always been buggy.
>>
>>> This patch fixes the problem by decoupling CFG and IO, reassigning iatu2 to 
>>> IO.
>>
>> But, we can not just assign IOs to iatu2.
>> IIRC then, there are atleast two platforms which have only 2
>> viewports, therefore they can not program iatu2.
>>
>> Jingoo,Bjorn: IMHO, we should modify this portion of code, since more
>> number of platforms has 4+ viewports. Probably, we can take following
>> approach:
>>
>> (1) Pass number of viewports through DT. If we have *atleast*  3
>> viewports then assign separate viewports to memory and IO,  and share
>> one with CFG0 and CFG1.
>> (2) If 

Re: [PATCH] notifier: Fix soft lockup for notifier_call_chain().

2016-06-27 Thread Ding Tianhong
On 2016/6/28 3:50, Cong Wang wrote:
> On Fri, Jun 24, 2016 at 7:46 PM, Ding Tianhong  
> wrote:
>> diff --git a/kernel/notifier.c b/kernel/notifier.c
>> index fd2c9ac..9c30411 100644
>> --- a/kernel/notifier.c
>> +++ b/kernel/notifier.c
>> @@ -92,6 +92,8 @@ static int notifier_call_chain(struct notifier_block **nl,
>>  #endif
>> ret = nb->notifier_call(nb, val, v);
>>
>> +   cond_resched();
>> +
>> if (nr_calls)
>> (*nr_calls)++;
> 
> NAK.
> 
> You can't do a resched in atomic context in __atomic_notifier_call_chain().
> 
> 
Sorry, I miss this, so I think add touch_nmi_watchdog looks like the best 
solution for this problem.

Thanks
Ding






Re: [PATCH 2/2] x86/acpi: Remove the repeated lapic address override entry parsing

2016-06-27 Thread Baoquan He
On 06/28/16 at 03:25am, Rafael J. Wysocki wrote:
 
> > diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> > index 9414f84..6ef3694 100644
> > --- a/arch/x86/kernel/acpi/boot.c
> > +++ b/arch/x86/kernel/acpi/boot.c
> > @@ -990,21 +992,6 @@ static int __init acpi_parse_madt_lapic_entries(void)
> > if (!boot_cpu_has(X86_FEATURE_APIC))
> > return -ENODEV;
> >  
> > -   /*
> > -* Note that the LAPIC address is obtained from the MADT (32-bit value)
> > -* and (optionally) overridden by a LAPIC_ADDR_OVR entry (64-bit value).
> > -*/
> > -
> > -   count = acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_APIC_OVERRIDE,
> > - acpi_parse_lapic_addr_ovr, 0);
> > -   if (count < 0) {
> > -   printk(KERN_ERR PREFIX
> > -  "Error parsing LAPIC address override entry\n");
> > -   return count;
> > -   }
> > -
> > -   register_lapic_address(acpi_lapic_addr);
> > -
> 
> I'm not really sure if this change is correct.
> 
> Does it only deal with the override?

Hi Rafael,

Thanks for your comments.

Yes, it only deals with the override and it will call
register_lapic_address to set fixed mapping for lapic and get value for
boot_cpu_physical_apicid. Since this has heen done in
early_acpi_boot_init() there's no need to do it again in
acpi_boot_init().


> 
> > count = acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_SAPIC,
> >   acpi_parse_sapic, MAX_LOCAL_APIC);
> >  
> > diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> > index 60078a6..504311c 100644
> > --- a/arch/x86/kernel/apic/apic.c
> > +++ b/arch/x86/kernel/apic/apic.c
> > @@ -1799,7 +1799,7 @@ void __init register_lapic_address(unsigned long 
> > address)
> > if (!x2apic_mode) {
> > set_fixmap_nocache(FIX_APIC_BASE, address);
> > apic_printk(APIC_VERBOSE, "mapped APIC to %16lx (%16lx)\n",
> > -   APIC_BASE, mp_lapic_addr);
> > +   APIC_BASE, address);
> > }
> > if (boot_cpu_physical_apicid == -1U) {
> > boot_cpu_physical_apicid  = read_apic_id();
> > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> > index c4e7b39..059680d 100644
> > --- a/arch/x86/kernel/setup.c
> > +++ b/arch/x86/kernel/setup.c
> > @@ -1157,6 +1157,9 @@ void __init setup_arch(char **cmdline_p)
> >  */
> > acpi_boot_table_init();
> >  
> > +   /*
> > +* AMD NUMA support need get boot_cpu_id earlier.
> > +*/
> 
> Surely that's not the only goal of early_acpi_boot_init(), is it?

In commit cbf9bd60(acpi: get boot_cpu_id as early for k8_scan_nodes)
Yinghai added early_acpi_boot_init() and called it in amd numa code.
Then commit 2e42060c(x86, uv: add early detection of UV system types)
put it in arch/x86/kernel/setup.c to discover the apic type earlier.

So, you are right. This command adding is not correct.

> 
> > early_acpi_boot_init();
> >  
> > initmem_init();
> > 
> 
> Please CC ACPI-related patches to linux-a...@vger.kernel.org.

Will do when repost.

> 
> Thanks,
> Rafael
> 


Re: [PATCH 2/3] powerpc/spinlock: support vcpu preempted check

2016-06-27 Thread xinhui



On 2016年06月27日 22:17, Peter Zijlstra wrote:

On Mon, Jun 27, 2016 at 01:41:29PM -0400, Pan Xinhui wrote:

diff --git a/arch/powerpc/include/asm/spinlock.h 
b/arch/powerpc/include/asm/spinlock.h
index 523673d..ae938ee 100644
--- a/arch/powerpc/include/asm/spinlock.h
+++ b/arch/powerpc/include/asm/spinlock.h
@@ -52,6 +52,21 @@
  #define SYNC_IO
  #endif

+/* For fixing some spinning issues in a guest.
+ * kernel would check if vcpu is preempted during a spin loop.
+ * we support that.
+ */


If you look around in that file you'll notice that the above comment
style is inconsistent.

Nor is the comment really clarifying things, for one you fail to mention
the problem by its known name. You also forget to explain how this
interface will help. How about something like this:

/*
  * In order to deal with a various lock holder preemption issues provide
  * an interface to see if a vCPU is currently running or not.
  *
  * This allows us to terminate optimistic spin loops and block,
  * analogous to the native optimistic spin heuristic of testing if the
  * lock owner task is running or not.
  */

thanks!!!



Also, since you now have a useful comment, which is not architecture
specific, I would place it with the common vcpu_is_preempted()
definition in sched.h.


agree with you. Will do that. I will also add Suggested-by with you.
thanks


Hmm?


+#define arch_vcpu_is_preempted arch_vcpu_is_preempted
+static inline bool arch_vcpu_is_preempted(int cpu)
+{
+   struct lppaca *lp = _of(cpu);
+
+   if (unlikely(!(lppaca_shared_proc(lp) ||
+   lppaca_dedicated_proc(lp
+   return false;
+   return !!(be32_to_cpu(lp->yield_count) & 1);
+}
+
  static __always_inline int arch_spin_value_unlocked(arch_spinlock_t lock)
  {
return lock.slock == 0;
--
2.4.11







linux-next: manual merge of the audit tree with the security tree

2016-06-27 Thread Stephen Rothwell
Hi Paul,

Today's linux-next merge of the audit tree got conflicts in:

  arch/s390/kernel/ptrace.c

between commit:

  0208b9445bc0 ("s390/ptrace: run seccomp after ptrace")

from the security tree and commit:

  da7f750c1ef5 ("s390: ensure that syscall arguments are properly masked on 
s390")

from the audit tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc arch/s390/kernel/ptrace.c
index cea17010448f,defc0dca4510..
--- a/arch/s390/kernel/ptrace.c
+++ b/arch/s390/kernel/ptrace.c
@@@ -821,6 -821,16 +821,8 @@@ long compat_arch_ptrace(struct task_str
  
  asmlinkage long do_syscall_trace_enter(struct pt_regs *regs)
  {
 -  long ret = 0;
+   unsigned long mask = -1UL;
+ 
 -  /* Do the secure computing check first. */
 -  if (secure_computing()) {
 -  /* seccomp failures shouldn't expose any additional code. */
 -  ret = -1;
 -  goto out;
 -  }
 -
/*
 * The sysc_tracesys code in entry.S stored the system
 * call number to gprs[2].
@@@ -846,11 -850,14 +848,14 @@@
if (unlikely(test_thread_flag(TIF_SYSCALL_TRACEPOINT)))
trace_sys_enter(regs, regs->gprs[2]);
  
-   audit_syscall_entry(regs->gprs[2], regs->orig_gpr2,
-   regs->gprs[3], regs->gprs[4],
-   regs->gprs[5]);
+   if (is_compat_task())
+   mask = 0x;
+ 
+   audit_syscall_entry(regs->gprs[2], regs->orig_gpr2 & mask,
+   regs->gprs[3] & mask, regs->gprs[4] & mask,
+   regs->gprs[5] & mask);
 -out:
 -  return ret ?: regs->gprs[2];
 +
 +  return regs->gprs[2];
  }
  
  asmlinkage void do_syscall_trace_exit(struct pt_regs *regs)


[PATCH 0/2] serial: 8250_dw: Add ACPI support for uart on Hisilicon Hip05 soc

2016-06-27 Thread Kefeng Wang
Make dw8250_set_termios() as the default set_termios callback for 8250 dw uart, 
correct me
if I am wrong.

Then add ACPI support for uart on Hisilicon Hip05 soc, be careful that it is 
not 16500
compatible. Note, the build(no ACPI) depends on 
https://patchwork.kernel.org/patch/9141207/,
which was already accepted in net-next.

Meanwhile, set dw8250_serial_out32 to keep consistent between serial_out
and serial_in in ACPI.

Kefeng Wang (2):
  serial: 8250_dw: make dw8250_set_termios as default set_termios
callback
  serial: 8250_dw: add ACPI support for uart on Hisilicon Hip05 soc

 drivers/tty/serial/8250/8250_dw.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

-- 
1.7.12.4



[PATCH 1/2] serial: 8250_dw: make dw8250_set_termios as default set_termios callback

2016-06-27 Thread Kefeng Wang
We can safely use dw8250_set_termios() as the default set_termios
callback instead of serial8250_do_set_termios(), so do it.

Signed-off-by: Kefeng Wang 
---
 drivers/tty/serial/8250/8250_dw.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_dw.c 
b/drivers/tty/serial/8250/8250_dw.c
index e199696..65f3da7 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -301,7 +301,6 @@ static void dw8250_quirks(struct uart_port *p, struct 
dw8250_data *data)
p->iotype = UPIO_MEM32;
p->regshift = 2;
p->serial_in = dw8250_serial_in32;
-   p->set_termios = dw8250_set_termios;
/* So far none of there implement the Busy Functionality */
data->uart_16550_compatible = true;
}
@@ -309,7 +308,6 @@ static void dw8250_quirks(struct uart_port *p, struct 
dw8250_data *data)
/* Platforms with iDMA */
if (platform_get_resource_byname(to_platform_device(p->dev),
 IORESOURCE_MEM, "lpss_priv")) {
-   p->set_termios = dw8250_set_termios;
data->dma.rx_param = p->dev->parent;
data->dma.tx_param = p->dev->parent;
data->dma.fn = dw8250_idma_filter;
@@ -386,6 +384,7 @@ static int dw8250_probe(struct platform_device *pdev)
p->iotype   = UPIO_MEM;
p->serial_in= dw8250_serial_in;
p->serial_out   = dw8250_serial_out;
+   p->set_termios  = dw8250_set_termios;
 
p->membase = devm_ioremap(>dev, regs->start, resource_size(regs));
if (!p->membase)
-- 
1.7.12.4



[PATCH 2/2] serial: 8250_dw: add ACPI support for uart on Hisilicon Hip05 soc

2016-06-27 Thread Kefeng Wang
Add ACPI identifier for UART on Hisilicon Hip05 soc, be careful
that it is not 16550 compatibal.

Meanwhile, set dw8250_serial_out32 to keep consistent between serial_out
and serial_in in ACPI.

Signed-off-by: Kefeng Wang 
---
 drivers/tty/serial/8250/8250_dw.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_dw.c 
b/drivers/tty/serial/8250/8250_dw.c
index 65f3da7..7571b0f 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -301,8 +301,11 @@ static void dw8250_quirks(struct uart_port *p, struct 
dw8250_data *data)
p->iotype = UPIO_MEM32;
p->regshift = 2;
p->serial_in = dw8250_serial_in32;
-   /* So far none of there implement the Busy Functionality */
-   data->uart_16550_compatible = true;
+   p->serial_out = dw8250_serial_out32;
+
+   /* Hisilicon 8250 dw uart is not 16550 compatible */
+   if (!acpi_dev_found("HISI0031"))
+   data->uart_16550_compatible = true;
}
 
/* Platforms with iDMA */
@@ -618,6 +621,7 @@ static const struct acpi_device_id dw8250_acpi_match[] = {
{ "APMC0D08", 0},
{ "AMD0020", 0 },
{ "AMDI0020", 0 },
+   { "HISI0031", 0 },
{ },
 };
 MODULE_DEVICE_TABLE(acpi, dw8250_acpi_match);
-- 
1.7.12.4



Re: [PATCH v4 5/5] usb: dwc3: rockchip: add devicetree bindings documentation

2016-06-27 Thread William Wu

Dear Heiko,

On 06/25/2016 03:50 AM, Heiko Stuebner wrote:

Hi William,

Am Dienstag, 21. Juni 2016, 17:11:44 schrieb William Wu:

On 06/20/2016 10:44 PM, Heiko Stübner wrote:

Am Freitag, 17. Juni 2016, 17:18:59 schrieb William Wu:

On 06/17/2016 07:15 AM, Heiko Stübner wrote:

Am Donnerstag, 2. Juni 2016, 20:34:56 schrieb William Wu:

This patch adds the devicetree documentation required for Rockchip
USB3.0 core wrapper consisting of USB3.0 IP from Synopsys.

It supports DRD mode, and could operate in device mode (SS, HS, FS)
and host mode (SS, HS, FS, LS).

Signed-off-by: William Wu 

[...]


+Optional clocks:
+  "aclk_usb3otg0"Aclk for specific usb controller clock.

what does this clock do? Also most likely same argument as below.

Here is partial rk3399 clk tree about usb3:

aclk_usb3   77   29700 0 0
   aclk_usb3_grf11
29700  0 0
   aclk_usb3_rksoc_axi_perf 11
29700  0 0
   aclk_usb3otg111
29700  0 0
   aclk_usb3otg011
29700  0 0
   aclk_usb3_noc11
29700  0 0

from the clk tree, and check with our IC designers, we can see that:
1. aclk_usb3 is the parent clk of aclk_usb3
2. aclk_usb3_grf  is used for both otg0 and otg1 grf, and these usb3 grf
can be set
to control otg0 and otg1 controller, but not the phy.
3. aclk_usb3otg1 is otg1 controller clk,  aclk_usb3otg0 is otg0
controller clk.
4. aclk_usb3_rksoc_axi_perf is the clk for usb3 performance monitor
module. 5. aclk_usb3_noc is the clk for soc bus interconnect.


+  "aclk_usb3_rksoc_axi_perf"  USB AXI perf clock.  Not present on
all
platforms.

The clock names looks pretty strange. What are they for? Especially as
nothing seems to use them right now.

"aclk_usb3_rksoc_axi_perf", it's the clk for usb3 performance monitor
module, you can refer to the GRF_USB3_PERF_xxx. And we don't use the
usb3
performance monitor control registers right now.

ok, then I'd suggest not defining the clock for now.

For one, there are more perf blocks in the GRF (usb3, pcie, hdcp22,
gmac, gpu, etc) which all seem to share a somewhat similar design, so
they will maybe result in a separate driver of some form for the
performance monitors.

And secondly, it is somewhat easy to add new optional properties, but
you
cannot remove anything defined previously. So if we later decide to
handle all the performance monitors differently, you can't remove that
clock from the binding again. (or at least only with quite a bit of
hassle).

So as this clock isn't used at all yet, I guess it should not get
included now.

Yes, I agree with you. We can remove the aclk_usb3_rksoc_axi_perf right
now.

+  "aclk_usb3_grf"USB grf clock.  Not present on all platforms.

for my own education, which part of the GRF does this clock supply?

"aclk_usb3_grf", it's the clk for USB3 grf, e.g. GRF_USB3OTGX_CONX

Hmm, this looks more like it belongs to the otg phy?
Anyway, also seems unused right now, so same argument as above applies
here.

As I have described above, the "aclk_usb3_grf" is  used for both otg0
and otg1 grf,
and these usb3 grf can be set to control otg0 and otg1 controller, but
not the phy.
And we have done a test that remove the grf clk, and the result showed
that usb3
controller can't work normally. So I think we need the usb3 grf clk.

So about the usb3 controller clk management, I think it should contain
the following clk:
1.  aclk_usb3otg1
2.  aclk_usb3otg0
3.  aclk_usb3_grf

correct, aclk_usb3otgX would then be the busclk for each controller if I'm
not mistaken and the grf clock should also get enabled, like we also plan on
doing for the vio_grf clock in the display area.

OK, so  aclk_usb3_grf should be marked as critical, right?

I found that most of the grf clocks haven't been marked as critical, 
apart from vio_grf. So may I keep the aclk_usb3_grf in usb3 dts, and 
remove it after clock manager adds it to critical clocks?



4.  aclk_usb3_noc
For "aclk_usb3_noc", I discuss with our clk manager, the clk is always
on before,
but according to upstream maintainer's suggestion, we need to manage the
noc clk by each module.

can you point me to this discussion? The bus-interconnect is a very separate
component, which we don't model so far and thus we have all the noc clocks
simply marked as critical.

As this clock doesn't belong to the actual usb controller block, but said
separate component, handling it in the controller seems somehow wrong to me.

So my (current) opinion would again be to mark the noc clock as critical for
the time being.
Sorry, it seems that I get the new information about clk management too 
late.:-)


There's no dedicated discussion about noc clk, but similar to grf clock, 
please refer to "https://patchwork.kernel.org/patch/9171467/; for add 

Re: [PATCH 1/3] kernel/sched: introduce vcpu preempted check interface

2016-06-27 Thread xinhui



On 2016年06月27日 22:05, Boqun Feng wrote:

On Mon, Jun 27, 2016 at 01:41:28PM -0400, Pan Xinhui wrote:

this supports to fix lock holder preempted issue which run as a guest

for kernel users, we could use bool vcpu_is_preempted(int cpu) to detech
if one vcpu is preempted or not.

The default implementation is a macrodefined by false. So compiler can
wrap it out if arch dose not support such vcpu pteempted check.

archs can implement it by define arch_vcpu_is_preempted().

Signed-off-by: Pan Xinhui 
---
  include/linux/sched.h | 9 +
  1 file changed, 9 insertions(+)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 6e42ada..dc0a9c3 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -3293,6 +3293,15 @@ static inline void set_task_cpu(struct task_struct *p, 
unsigned int cpu)

  #endif /* CONFIG_SMP */

+#ifdef arch_vcpu_is_preempted
+static inline bool vcpu_is_preempted(int cpu)
+{
+   return arch_vcpu_is_preempted(cpu);
+}
+#else
+#define vcpu_is_preempted(cpu) false
+#endif
+


I think you are missing Peter's comment here. We can

#ifndef vcpu_is_preempted
#define vcpu_is_preempted(cpu)  fasle
#endif

And different archs implement their own versions of vcpu_is_preempted(),
IOW, no need for an arch_vcpu_is_preempted().


yes, right.
just vcpu_is_preempted, no arch_vcpu_is_preempted..
thanks


Regards,
Boqun


  extern long sched_setaffinity(pid_t pid, const struct cpumask *new_mask);
  extern long sched_getaffinity(pid_t pid, struct cpumask *mask);

--
2.4.11





Re: [PATCH 1/3] kernel/sched: introduce vcpu preempted check interface

2016-06-27 Thread xinhui



On 2016年06月27日 22:02, Peter Zijlstra wrote:

On Mon, Jun 27, 2016 at 04:00:43PM +0200, Peter Zijlstra wrote:

On Mon, Jun 27, 2016 at 01:41:28PM -0400, Pan Xinhui wrote:

+++ b/include/linux/sched.h
@@ -3293,6 +3293,15 @@ static inline void set_task_cpu(struct task_struct *p, 
unsigned int cpu)

  #endif /* CONFIG_SMP */

+#ifdef arch_vcpu_is_preempted
+static inline bool vcpu_is_preempted(int cpu)
+{
+   return arch_vcpu_is_preempted(cpu);
+}
+#else
+#define vcpu_is_preempted(cpu) false
+#endif


#ifndef vcpu_is_preempted
#define vcpu_is_preempted(cpu)  (false)
#endif

Is so much simpler...


fair enough.


Also, please Cc the virt list so that other interested parties can
comment, and maybe also the s390 folks.



oh. I forgot that. maybe we need cc more.

root@ltcalpine2-lp13:~/linux# find ./arch -name kvm
./arch/arm/kvm
./arch/arm64/kvm
./arch/mips/kvm
./arch/powerpc/kvm
./arch/s390/kvm
./arch/tile/kvm
./arch/x86/kvm


And before you hurry off to post again, add a patch doing
mutex_spin_on_owner() and rwsem_spin_in_owner().


will do that.

thanks for your suggestion. :)



linux-next: manual merge of the iommu tree with the arm tree

2016-06-27 Thread Stephen Rothwell
Hi Joerg,

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

  drivers/iommu/mtk_iommu.c

between commit:

  d267804c8457 ("iommu: convert DT component matching to 
component_match_add_release()")

from the arm tree and commit:

  9ca340c98c0d ("iommu/mediatek: move the common struct into header file")

from the iommu tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/iommu/mtk_iommu.c
index c036df1c49ca,b12c12d74c33..
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@@ -552,30 -524,6 +524,11 @@@ static int mtk_iommu_hw_init(const stru
return 0;
  }
  
- static int compare_of(struct device *dev, void *data)
- {
-   return dev->of_node == data;
- }
- 
 +static void release_of(struct device *dev, void *data)
 +{
 +  of_node_put(data);
 +}
 +
- static int mtk_iommu_bind(struct device *dev)
- {
-   struct mtk_iommu_data *data = dev_get_drvdata(dev);
- 
-   return component_bind_all(dev, >smi_imu);
- }
- 
- static void mtk_iommu_unbind(struct device *dev)
- {
-   struct mtk_iommu_data *data = dev_get_drvdata(dev);
- 
-   component_unbind_all(dev, >smi_imu);
- }
- 
  static const struct component_master_ops mtk_iommu_com_ops = {
.bind   = mtk_iommu_bind,
.unbind = mtk_iommu_unbind,


Re: [PATCH 00/21] Support qcom's HSIC USB and rewrite USB2 HS phy support

2016-06-27 Thread John Stultz
On Sun, Jun 26, 2016 at 12:28 AM, Stephen Boyd  wrote:
> The state of USB ChipIdea support on Qualcomm's platforms is not great.
> The DT description of these devices requires up to three different nodes
> for what amounts to be the same hardware block, when there should really
> only be one. Furthermore, the "phy" driver that is in mainline (phy-msm-usb.c)
> duplicates the OTG state machine and touches the ci controller wrapper
> registers when it should really be focused on the phy and the ULPI accesses
> needed to get the phy working. There's also a slimmed down phy driver for
> the msm8916 platform, but really the phy hardware is the same as other MSMs,
> so we have two drivers doing pretty much the same thing. This leads to a
> situtaion where we have the chipidea core driver, the "phy" driver, and
> sometimes the ehci-msm.c driver operating the same device all at the same
> time with very little coordination. This just isn't very safe and is
> confusing from a driver perspective when trying to figure out who does what.
> Finally, there isn't any HSIC support on platforms like apq8074 so we
> should add that.
>
> This patch series updates the ChipIdea driver and the MSM wrapper
> (ci_hdrc_msm.c) to properly handle the PHY and wrapper bits at the right
> times in the right places. To get there, we update the ChipIdea core to
> have support for the ULPI phy bus introduced by Heikki. Along the way
> we fix bugs with the extcon handling for peripheral and OTG mode controllers
> and move the parts of phy-usb-msm.c that are touching the CI controller
> wrapper into the wrapper driver (ci_hdrc_msm.c). Finally we add support
> for the HSIC phy based on the ULPI bus and rewrite the HS phy driver
> (phy-usb-msm.c) as a standard ULPI phy driver.
>
> Once this series is accepted, we should be able to delete the phy-usb-msm.c
> phy-qcom-8x16-usb.c, and ehci-msm.c drivers from the tree and use the ULPI
> based phy driver (which also lives in drivers/phy/ instead of 
> drivers/usb/phy/)
> and the chipidea host core instead.
>
> I've also sent seperate patches for other minor pieces to make this
> all work. The full tree can be found here[3], hacks and all to get
> things working. I've tested this on the db410c, apq8074 dragonboard,
> and ifc6410 with configfs gadgets and otg cables.
...
> [3] 
> https://git.linaro.org/people/stephen.boyd/linux.git/shortlog/refs/heads/usb-hsic-8074

Very excited to see this moving upstream!

Just a heads up, trying to build with this branch gives me:

drivers/usb/Kconfig:39:error: recursive dependency detected!
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/usb/Kconfig:39: symbol USB is selected by MOUSE_APPLETOUCH
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/input/mouse/Kconfig:187:symbol MOUSE_APPLETOUCH depends on INPUT
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/input/Kconfig:8:symbol INPUT is selected by VT
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/tty/Kconfig:12: symbol VT is selected by FB_STI
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:674:symbol FB_STI depends on FB
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:5:  symbol FB is selected by DRM_KMS_FB_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:42: symbol DRM_KMS_FB_HELPER is selected
by DRM_KMS_CMA_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:98: symbol DRM_KMS_CMA_HELPER is selected by DRM_IMX
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/imx/Kconfig:1:  symbol DRM_IMX depends on IMX_IPUV3_CORE
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/ipu-v3/Kconfig:1:   symbol IMX_IPUV3_CORE depends on
RESET_CONTROLLER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/reset/Kconfig:4:symbol RESET_CONTROLLER is selected by
USB_CHIPIDEA
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/usb/chipidea/Kconfig:1: symbol USB_CHIPIDEA depends on USB_EHCI_HCD
For a resolution refer to 

Re: [PATCH] geneve: fix max_mtu setting

2016-06-27 Thread Jesse Gross
On Mon, Jun 27, 2016 at 6:27 PM, 严海双  wrote:
>
> On Jun 28, 2016, at 12:10 AM, Jesse Gross  wrote:
>
> On Sun, Jun 26, 2016 at 6:13 PM, Haishuang Yan
>  wrote:
>
>
> On Jun 26, 2016, at 8:35 PM, zhuyj  wrote:
>
> +   if (geneve->remote.sa.sa_family == AF_INET)
> +   max_mtu -= sizeof(struct iphdr);
> +   else
> +   max_mtu -= sizeof(struct ipv6hdr);
>
> Sorry, if sa_family is not AF_NET, it is AF_INET6?
>
> There is a lot of macros in include/linux/socket.h.
>
> Zhu Yanjun
>
>
> There are only two enumerations AF_INET and AF_INET6 have been assigned in
> geneve_newlink:
>
>
> There's actually a third possibility: AF_UNSPEC, which is the default
> if neither remote type is specified. This is used by lightweight
> tunnels and should be able to work with either IPv4/v6. For the
> purposes of the MTU calculation this means that the IPv4 header size
> should be used to avoid disallowing potentially valid configurations.
>
>
> Yes, you’re right. Thanks for you advise. I will send a v2 commit like this:
>
>if (geneve->remote.sa.sa_family == AF_INET6)
>   max_mtu -= sizeof(struct ipv6hdr);
>else
>   max_mtu -= sizeof(struct iphdr);
>
> Is this ok?

Yes, that looks fine to me.


[PATCH net-next v2 6/6] r8152: add byte_enable for ocp_read_word function

2016-06-27 Thread Hayes Wang
Add byte_enable for ocp_read_word() to replace reading 4
bytes data with reading the desired 2 bytes data.

This is used to avoid the issue which is described in
commit b4d99def0938 ("r8152: remove sram_read"). The
origin method always reads 4 bytes data, and it may
have problem when reading the PHY registers.

The new method is supported since RTL8152B, but it
doesn't influence the previous chips. The bits of the
byte_enable for the previous chips are the reserved
bits, and the hw would ignore them.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 2fd4944..0bb7c1b 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -945,11 +945,13 @@ static u16 ocp_read_word(struct r8152 *tp, u16 type, u16 
index)
 {
u32 data;
__le32 tmp;
+   u16 byen = BYTE_EN_WORD;
u8 shift = index & 2;
 
index &= ~3;
+   byen <<= shift;
 
-   generic_ocp_read(tp, index, sizeof(tmp), , type);
+   generic_ocp_read(tp, index, sizeof(tmp), , type | byen);
 
data = __le32_to_cpu(tmp);
data >>= (shift * 8);
-- 
2.4.11



[PATCH net-next v2 0/6] r8152: support new chips

2016-06-27 Thread Hayes Wang
v2:
Fix the commit message for patch #6.

v1:
In order to support new chips, adjust some codes. Then, add the settings
for the new chips.

Hayes Wang (6):
  r8152: add aldps_enable for rtl_ops
  r8152: add u1u2_enable for rtl_ops
  r8152: add power_cut_en for rtl_ops
  r8152: support the new chip 8050
  r8152: support RTL8153B
  r8152: add byte_enable for ocp_read_word function

 drivers/net/usb/r8152.c | 621 
 1 file changed, 576 insertions(+), 45 deletions(-)

-- 
2.4.11



[PATCH net-next v2 4/6] r8152: support the new chip 8050

2016-06-27 Thread Hayes Wang
Support a new chip which has the product ID 0x8050.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index a4f8a01..3ccbff0 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -646,6 +646,7 @@ enum rtl_version {
RTL_VER_04,
RTL_VER_05,
RTL_VER_06,
+   RTL_VER_07,
RTL_VER_MAX
 };
 
@@ -3920,6 +3921,7 @@ static int rtl8152_get_coalesce(struct net_device *netdev,
switch (tp->version) {
case RTL_VER_01:
case RTL_VER_02:
+   case RTL_VER_07:
return -EOPNOTSUPP;
default:
break;
@@ -3939,6 +3941,7 @@ static int rtl8152_set_coalesce(struct net_device *netdev,
switch (tp->version) {
case RTL_VER_01:
case RTL_VER_02:
+   case RTL_VER_07:
return -EOPNOTSUPP;
default:
break;
@@ -4038,6 +4041,7 @@ static int rtl8152_change_mtu(struct net_device *dev, int 
new_mtu)
switch (tp->version) {
case RTL_VER_01:
case RTL_VER_02:
+   case RTL_VER_07:
return eth_change_mtu(dev, new_mtu);
default:
break;
@@ -4109,6 +4113,9 @@ static void r8152b_get_version(struct r8152 *tp)
tp->version = RTL_VER_06;
tp->mii.supports_gmii = 1;
break;
+   case 0x4800:
+   tp->version = RTL_VER_07;
+   break;
default:
netif_info(tp, probe, tp->netdev,
   "Unknown version 0x%04x\n", version);
@@ -4141,6 +4148,7 @@ static int rtl_ops_init(struct r8152 *tp)
switch (tp->version) {
case RTL_VER_01:
case RTL_VER_02:
+   case RTL_VER_07:
ops->init   = r8152b_init;
ops->enable = rtl8152_enable;
ops->disable= rtl8152_disable;
@@ -4336,6 +4344,7 @@ static void rtl8152_disconnect(struct usb_interface *intf)
 
 /* table of devices that work with this driver */
 static struct usb_device_id rtl8152_table[] = {
+   {REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8050)},
{REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8152)},
{REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8153)},
{REALTEK_USB_DEVICE(VENDOR_ID_SAMSUNG, 0xa101)},
-- 
2.4.11



[PATCH net-next v2 1/6] r8152: add aldps_enable for rtl_ops

2016-06-27 Thread Hayes Wang
Add aldps_enable() for rtl_ops.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 11178f9..b253003 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -619,6 +619,7 @@ struct r8152 {
int (*eee_get)(struct r8152 *, struct ethtool_eee *);
int (*eee_set)(struct r8152 *, struct ethtool_eee *);
bool (*in_nway)(struct r8152 *);
+   void (*aldps_enable)(struct r8152 *tp, bool enable);
void (*hw_phy_cfg)(struct r8152 *);
} rtl_ops;
 
@@ -2474,9 +2475,9 @@ static void r8152_aldps_en(struct r8152 *tp, bool enable)
 
 static void rtl8152_disable(struct r8152 *tp)
 {
-   r8152_aldps_en(tp, false);
+   tp->rtl_ops.aldps_enable(tp, false);
rtl_disable(tp);
-   r8152_aldps_en(tp, true);
+   tp->rtl_ops.aldps_enable(tp, true);
 }
 
 static void r8152b_hw_phy_cfg(struct r8152 *tp)
@@ -2801,9 +2802,7 @@ static void r8153_aldps_en(struct r8152 *tp, bool enable)
 
 static void rtl8153_disable(struct r8152 *tp)
 {
-   r8153_aldps_en(tp, false);
-   rtl_disable(tp);
-   r8153_aldps_en(tp, true);
+   rtl8152_disable(tp);
usb_enable_lpm(tp->udev);
 }
 
@@ -2924,9 +2923,9 @@ static void rtl8153_up(struct r8152 *tp)
return;
 
r8153_u1u2en(tp, false);
-   r8153_aldps_en(tp, false);
+   tp->rtl_ops.aldps_enable(tp, false);
r8153_first_init(tp);
-   r8153_aldps_en(tp, true);
+   tp->rtl_ops.aldps_enable(tp, true);
r8153_u2p3en(tp, true);
r8153_u1u2en(tp, true);
usb_enable_lpm(tp->udev);
@@ -2942,9 +2941,9 @@ static void rtl8153_down(struct r8152 *tp)
r8153_u1u2en(tp, false);
r8153_u2p3en(tp, false);
r8153_power_cut_en(tp, false);
-   r8153_aldps_en(tp, false);
+   tp->rtl_ops.aldps_enable(tp, false);
r8153_enter_oob(tp);
-   r8153_aldps_en(tp, true);
+   tp->rtl_ops.aldps_enable(tp, true);
 }
 
 static bool rtl8152_in_nway(struct r8152 *tp)
@@ -4142,6 +4141,7 @@ static int rtl_ops_init(struct r8152 *tp)
ops->eee_get= r8152_get_eee;
ops->eee_set= r8152_set_eee;
ops->in_nway= rtl8152_in_nway;
+   ops->aldps_enable   = r8152_aldps_en;
ops->hw_phy_cfg = r8152b_hw_phy_cfg;
break;
 
@@ -4158,6 +4158,7 @@ static int rtl_ops_init(struct r8152 *tp)
ops->eee_get= r8153_get_eee;
ops->eee_set= r8153_set_eee;
ops->in_nway= rtl8153_in_nway;
+   ops->aldps_enable   = r8153_aldps_en;
ops->hw_phy_cfg = r8153_hw_phy_cfg;
break;
 
-- 
2.4.11



[PATCH net-next v2 3/6] r8152: add power_cut_en for rtl_ops

2016-06-27 Thread Hayes Wang
Add power_cut_en() for rtl_ops.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f51d799..a4f8a01 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -622,6 +622,7 @@ struct r8152 {
void (*aldps_enable)(struct r8152 *tp, bool enable);
void (*u1u2_enable)(struct r8152 *tp, bool enable);
void (*hw_phy_cfg)(struct r8152 *);
+   void (*power_cut_en)(struct r8152 *tp, bool enable);
} rtl_ops;
 
int intr_interval;
@@ -2391,6 +2392,13 @@ static void r8153_power_cut_en(struct r8152 *tp, bool 
enable)
else
ocp_data &= ~(PWR_EN | PHASE2_EN);
ocp_write_word(tp, MCU_TYPE_USB, USB_POWER_CUT, ocp_data);
+}
+
+static void r8153A_power_cut_en(struct r8152 *tp, bool enable)
+{
+   u32 ocp_data;
+
+   r8153_power_cut_en(tp, enable);
 
ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_MISC_0);
ocp_data &= ~PCUT_STATUS;
@@ -2941,7 +2949,7 @@ static void rtl8153_down(struct r8152 *tp)
 
tp->rtl_ops.u1u2_enable(tp, false);
r8153_u2p3en(tp, false);
-   r8153_power_cut_en(tp, false);
+   tp->rtl_ops.power_cut_en(tp, false);
tp->rtl_ops.aldps_enable(tp, false);
r8153_enter_oob(tp);
tp->rtl_ops.aldps_enable(tp, true);
@@ -3397,7 +3405,7 @@ static void r8153_init(struct r8152 *tp)
 
ocp_write_word(tp, MCU_TYPE_USB, USB_CONNECT_TIMER, 0x0001);
 
-   r8153_power_cut_en(tp, false);
+   r8153A_power_cut_en(tp, false);
r8153_u1u2en(tp, true);
 
ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL, ALDPS_SPDWN_RATIO);
@@ -4122,7 +4130,7 @@ static void rtl8153_unload(struct r8152 *tp)
if (test_bit(RTL8152_UNPLUG, >flags))
return;
 
-   r8153_power_cut_en(tp, false);
+   tp->rtl_ops.power_cut_en(tp, false);
 }
 
 static int rtl_ops_init(struct r8152 *tp)
@@ -4145,6 +4153,7 @@ static int rtl_ops_init(struct r8152 *tp)
ops->aldps_enable   = r8152_aldps_en;
ops->u1u2_enable= r8153_u1u2en;
ops->hw_phy_cfg = r8152b_hw_phy_cfg;
+   ops->power_cut_en   = r8152_power_cut_en;
break;
 
case RTL_VER_03:
@@ -4163,6 +4172,7 @@ static int rtl_ops_init(struct r8152 *tp)
ops->aldps_enable   = r8153_aldps_en;
ops->u1u2_enable= r8153_u1u2en;
ops->hw_phy_cfg = r8153_hw_phy_cfg;
+   ops->power_cut_en   = r8153A_power_cut_en;
break;
 
default:
-- 
2.4.11



[PATCH net-next v2 2/6] r8152: add u1u2_enable for rtl_ops

2016-06-27 Thread Hayes Wang
Add u1u2_enable() for rtl_ops.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index b253003..f51d799 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -620,6 +620,7 @@ struct r8152 {
int (*eee_set)(struct r8152 *, struct ethtool_eee *);
bool (*in_nway)(struct r8152 *);
void (*aldps_enable)(struct r8152 *tp, bool enable);
+   void (*u1u2_enable)(struct r8152 *tp, bool enable);
void (*hw_phy_cfg)(struct r8152 *);
} rtl_ops;
 
@@ -2408,7 +2409,7 @@ static void rtl_runtime_suspend_enable(struct r8152 *tp, 
bool enable)
if (enable) {
u32 ocp_data;
 
-   r8153_u1u2en(tp, false);
+   tp->rtl_ops.u1u2_enable(tp, false);
r8153_u2p3en(tp, false);
 
__rtl_set_wol(tp, WAKE_ANY);
@@ -2423,7 +2424,7 @@ static void rtl_runtime_suspend_enable(struct r8152 *tp, 
bool enable)
} else {
__rtl_set_wol(tp, tp->saved_wolopts);
r8153_u2p3en(tp, true);
-   r8153_u1u2en(tp, true);
+   tp->rtl_ops.u1u2_enable(tp, true);
}
 }
 
@@ -2922,12 +2923,12 @@ static void rtl8153_up(struct r8152 *tp)
if (test_bit(RTL8152_UNPLUG, >flags))
return;
 
-   r8153_u1u2en(tp, false);
+   tp->rtl_ops.u1u2_enable(tp, false);
tp->rtl_ops.aldps_enable(tp, false);
r8153_first_init(tp);
tp->rtl_ops.aldps_enable(tp, true);
r8153_u2p3en(tp, true);
-   r8153_u1u2en(tp, true);
+   tp->rtl_ops.u1u2_enable(tp, true);
usb_enable_lpm(tp->udev);
 }
 
@@ -2938,7 +2939,7 @@ static void rtl8153_down(struct r8152 *tp)
return;
}
 
-   r8153_u1u2en(tp, false);
+   tp->rtl_ops.u1u2_enable(tp, false);
r8153_u2p3en(tp, false);
r8153_power_cut_en(tp, false);
tp->rtl_ops.aldps_enable(tp, false);
@@ -4142,6 +4143,7 @@ static int rtl_ops_init(struct r8152 *tp)
ops->eee_set= r8152_set_eee;
ops->in_nway= rtl8152_in_nway;
ops->aldps_enable   = r8152_aldps_en;
+   ops->u1u2_enable= r8153_u1u2en;
ops->hw_phy_cfg = r8152b_hw_phy_cfg;
break;
 
@@ -4159,6 +4161,7 @@ static int rtl_ops_init(struct r8152 *tp)
ops->eee_set= r8153_set_eee;
ops->in_nway= rtl8153_in_nway;
ops->aldps_enable   = r8153_aldps_en;
+   ops->u1u2_enable= r8153_u1u2en;
ops->hw_phy_cfg = r8153_hw_phy_cfg;
break;
 
-- 
2.4.11



[PATCH net-next v2 5/6] r8152: support RTL8153B

2016-06-27 Thread Hayes Wang
Support new chip RTL8153B.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 560 +---
 1 file changed, 533 insertions(+), 27 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 3ccbff0..2fd4944 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -28,7 +28,7 @@
 #include 
 
 /* Information for net-next */
-#define NETNEXT_VERSION"08"
+#define NETNEXT_VERSION"09"
 
 /* Information for net */
 #define NET_VERSION"3"
@@ -50,11 +50,14 @@
 #define PLA_FMC0xc0b4
 #define PLA_CFG_WOL0xc0b6
 #define PLA_TEREDO_CFG 0xc0bc
+#define PLA_TEREDO_WAKE_BASE   0xc0c4
 #define PLA_MAR0xcd00
 #define PLA_BACKUP 0xd000
 #define PAL_BDC_CR 0xd1a0
 #define PLA_TEREDO_TIMER   0xd2cc
 #define PLA_REALWOW_TIMER  0xd2e8
+#define PLA_EFUSE_DATA 0xdd00
+#define PLA_EFUSE_CMD  0xdd02
 #define PLA_LEDSEL 0xdd90
 #define PLA_LED_FEATURE0xdd92
 #define PLA_PHYAR  0xde00
@@ -104,7 +107,9 @@
 #define USB_CSR_DUMMY2 0xb466
 #define USB_DEV_STAT   0xb808
 #define USB_CONNECT_TIMER  0xcbf8
+#define USB_MSC_TIMER  0xcbfc
 #define USB_BURST_SIZE 0xcfc0
+#define USB_LPM_CONFIG 0xcfd8
 #define USB_USB_CTRL   0xd406
 #define USB_PHY_CTRL   0xd408
 #define USB_TX_AGG 0xd40a
@@ -112,14 +117,19 @@
 #define USB_USB_TIMER  0xd428
 #define USB_RX_EARLY_TIMEOUT   0xd42c
 #define USB_RX_EARLY_SIZE  0xd42e
-#define USB_PM_CTRL_STATUS 0xd432
+#define USB_PM_CTRL_STATUS 0xd432  /* RTL8153A */
+#define USB_RX_EXTRA_AGGR_TMR  0xd432  /* RTL8153B */
 #define USB_TX_DMA 0xd434
+#define USB_UPT_RXDMA_OWN  0xd437
 #define USB_TOLERANCE  0xd490
 #define USB_LPM_CTRL   0xd41a
+#define USB_U1U2_TIMER 0xd4da
 #define USB_UPS_CTRL   0xd800
 #define USB_MISC_0 0xd81a
 #define USB_POWER_CUT  0xd80a
 #define USB_AFE_CTRL2  0xd824
+#define USB_UPS_CFG0xd842
+#define USB_UPS_FLAGS  0xd848
 #define USB_WDT11_CTRL 0xe43c
 #define USB_BP_BA  0xfc26
 #define USB_BP_0   0xfc28
@@ -141,6 +151,7 @@
 #define OCP_EEE_AR 0xa41a
 #define OCP_EEE_DATA   0xa41c
 #define OCP_PHY_STATUS 0xa420
+#define OCP_NCTL_CFG   0xa42c
 #define OCP_POWER_CFG  0xa430
 #define OCP_EEE_CFG0xa432
 #define OCP_SRAM_ADDR  0xa436
@@ -150,9 +161,14 @@
 #define OCP_EEE_ADV0xa5d0
 #define OCP_EEE_LPABLE 0xa5d2
 #define OCP_PHY_STATE  0xa708  /* nway state for 8153 */
+#define OCP_PHY_PATCH_STAT 0xb800
+#define OCP_PHY_PATCH_CMD  0xb820
+#define OCP_ADC_IOFFSET0xbcfc
 #define OCP_ADC_CFG0xbc06
+#define OCP_SYSCLK_CFG 0xc416
 
 /* SRAM Register */
+#define SRAM_GREEN_CFG 0x8011
 #define SRAM_LPF_CFG   0x8012
 #define SRAM_10M_AMP1  0x8080
 #define SRAM_10M_AMP2  0x8082
@@ -250,6 +266,10 @@
 /* PAL_BDC_CR */
 #define ALDPS_PROXY_MODE   0x0001
 
+/* PLA_EFUSE_CMD */
+#define EFUSE_READ_CMD BIT(15)
+#define EFUSE_DATA_BIT16   BIT(7)
+
 /* PLA_CONFIG34 */
 #define LINK_ON_WAKE_EN0x0010
 #define LINK_OFF_WAKE_EN   0x0008
@@ -275,6 +295,7 @@
 
 /* PLA_MAC_PWR_CTRL2 */
 #define EEE_SPDWN_RATIO0x8007
+#define MAC_CLK_SPDWN_EN   BIT(15)
 
 /* PLA_MAC_PWR_CTRL3 */
 #define PKT_AVAIL_SPDWN_EN 0x0100
@@ -326,6 +347,9 @@
 #define STAT_SPEED_HIGH0x
 #define STAT_SPEED_FULL0x0002
 
+/* USB_LPM_CONFIG */
+#define LPM_U1U2_ENBIT(0)
+
 /* USB_TX_AGG */
 #define TX_AGG_MAX_THRESHOLD   0x03
 
@@ -333,11 +357,16 @@
 #define RX_THR_SUPPER  0x0c350180
 #define RX_THR_HIGH0x7a120180
 #define RX_THR_SLOW0x0180
+#define RX_THR_B   0x00010001
 
 /* USB_TX_DMA */
 #define TEST_MODE_DISABLE  0x0001
 #define TX_SIZE_ADJUST10x0100
 
+/* USB_UPT_RXDMA_OWN */
+#define OWN_UPDATE BIT(0)
+#define OWN_CLEAR  BIT(1)
+
 /* USB_UPS_CTRL */
 #define POWER_CUT  0x0100
 
@@ -354,6 +383,8 @@
 /* USB_POWER_CUT */
 #define PWR_EN 0x0001
 #define PHASE2_EN  0x0008
+#define UPS_EN BIT(4)
+#define USP_PREWAKEBIT(5)
 
 /* USB_MISC_0 */
 #define PCUT_STATUS0x0001
@@ -380,6 +411,37 @@
 #define SEN_VAL_NORMAL 0xa000
 #define SEL_RXIDLE 0x0100
 
+/* USB_UPS_CFG */
+#define SAW_CNT_1MS_MASK   0x0fff
+
+/* USB_UPS_FLAGS */
+#define UPS_FLAGS_R_TUNE   BIT(0)
+#define UPS_FLAGS_EN_10M_CKDIV BIT(1)
+#define UPS_FLAGS_250M_CKDIV 

Re: [PATCH v2 0/5] ARM: dts: imx7d: add i.MX 7Solo and Colibri iMX7S/D dts

2016-06-27 Thread Shawn Guo
On Sun, Jun 26, 2016 at 01:47:50AM -0700, Stefan Agner wrote:
> Stefan Agner (5):
>   ARM: imx: add support for i.MX 7Solo
>   ARM: dts: imx7d: use imx7s.dtsi as base device tree
>   ARM: dts: imx7d: recreate imx7d.dtsi with i.MX 7Dual specifics
>   ARM: dts: imx7d: move input header into base device tree
>   ARM: dts: imx7: add Toradex Colibri iMX7S/iMX7D support

Applied all, thanks.


[PATCH v2 3/5] spi: s3c64xx: do not configure the device twice

2016-06-27 Thread Andi Shyti
At the start of the transfer, the spi_config function is called
twice, the first time when the 3c64xx_spi_prepare_message is
called and the second time with the s3c64xx_spi_transfer_one,
both called from the spi framework.

Remove the first call at the prepare message because in that
point we don't have the imformation about "bit per word" and
frequency.

Signed-off-by: Andi Shyti 
---
 drivers/spi/spi-s3c64xx.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 14269b0..c65a9e6 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -676,16 +676,6 @@ static int s3c64xx_spi_prepare_message(struct spi_master 
*master,
struct spi_device *spi = msg->spi;
struct s3c64xx_spi_csinfo *cs = spi->controller_data;
 
-   /* If Master's(controller) state differs from that needed by Slave */
-   if (sdd->cur_speed != spi->max_speed_hz
-   || sdd->cur_mode != spi->mode
-   || sdd->cur_bpw != spi->bits_per_word) {
-   sdd->cur_bpw = spi->bits_per_word;
-   sdd->cur_speed = spi->max_speed_hz;
-   sdd->cur_mode = spi->mode;
-   s3c64xx_spi_config(sdd);
-   }
-
/* Configure feedback delay */
writel(cs->fb_delay & 0x3, sdd->regs + S3C64XX_SPI_FB_CLK);
 
@@ -712,6 +702,7 @@ static int s3c64xx_spi_transfer_one(struct spi_master 
*master,
if (bpw != sdd->cur_bpw || speed != sdd->cur_speed) {
sdd->cur_bpw = bpw;
sdd->cur_speed = speed;
+   sdd->cur_mode = spi->mode;
s3c64xx_spi_config(sdd);
}
 
-- 
2.8.1



[PATCH v2 5/5] spi: s3c64xx: use unsigned type for fifo handling variables

2016-06-27 Thread Andi Shyti
The 'quirks' variable cannot ever be negative, therefore use u8
instead of int. The 8 bit size is given from the fact that
currently the quirks variable has very few statuses.

The rx_lvl_offset and tx_st_done store shift values, so that u8
is a proper size.

fifo_lvl_mask stores a series of masks, to be in we will keep the
32 bit size.

Signed-off-by: Andi Shyti 
Signed-off-by: Jaehoon Chung 
---
 drivers/spi/spi-s3c64xx.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 6d8486f..6c9503a 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -150,10 +150,10 @@ struct s3c64xx_spi_dma_data {
  * which is provided as driver data to the driver.
  */
 struct s3c64xx_spi_port_config {
-   int fifo_lvl_mask[MAX_SPI_PORTS];
-   int rx_lvl_offset;
-   int tx_st_done;
-   int quirks;
+   u32 fifo_lvl_mask[MAX_SPI_PORTS];
+   u8  rx_lvl_offset;
+   u8  tx_st_done;
+   u8  quirks;
boolhigh_speed;
boolclk_from_cmu;
 };
-- 
2.8.1



[PATCH v2 1/5] spi: s3c64xx: group the CS signalling writes in a single function

2016-06-27 Thread Andi Shyti
To enable/disable the CS line, the driver performs a writel in
the S3C64XX_SPI_SLAVE_SEL registers. Group the register's
configuration in a single function.

Signed-off-by: Andi Shyti 
---
 drivers/spi/spi-s3c64xx.c | 36 ++--
 1 file changed, 26 insertions(+), 10 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 5a76a50..972367d 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -310,6 +310,28 @@ static void prepare_dma(struct s3c64xx_spi_dma_data *dma,
dma_async_issue_pending(dma->ch);
 }
 
+static void s3c64xx_spi_set_cs(struct spi_device *spi, bool enable)
+{
+   struct s3c64xx_spi_driver_data *sdd =
+   spi_master_get_devdata(spi->master);
+
+   if (enable) {
+   if (!(sdd->port_conf->quirks & S3C64XX_SPI_QUIRK_CS_AUTO)) {
+   writel(0, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
+   } else {
+   u32 ssel = readl(sdd->regs + S3C64XX_SPI_SLAVE_SEL);
+
+   ssel |= (S3C64XX_SPI_SLAVE_AUTO |
+   S3C64XX_SPI_SLAVE_NSC_CNT_2);
+   writel(ssel, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
+   }
+   } else {
+   if (!(sdd->port_conf->quirks & S3C64XX_SPI_QUIRK_CS_AUTO))
+   writel(S3C64XX_SPI_SLAVE_SIG_INACT,
+   sdd->regs + S3C64XX_SPI_SLAVE_SEL);
+   }
+}
+
 static int s3c64xx_spi_prepare_transfer(struct spi_master *spi)
 {
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
@@ -706,12 +728,7 @@ static int s3c64xx_spi_transfer_one(struct spi_master 
*master,
enable_datapath(sdd, spi, xfer, use_dma);
 
/* Start the signals */
-   if (!(sdd->port_conf->quirks & S3C64XX_SPI_QUIRK_CS_AUTO))
-   writel(0, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
-   else
-   writel(readl(sdd->regs + S3C64XX_SPI_SLAVE_SEL)
-   | S3C64XX_SPI_SLAVE_AUTO | S3C64XX_SPI_SLAVE_NSC_CNT_2,
-   sdd->regs + S3C64XX_SPI_SLAVE_SEL);
+   s3c64xx_spi_set_cs(spi, true);
 
spin_unlock_irqrestore(>lock, flags);
 
@@ -861,16 +878,15 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
 
pm_runtime_mark_last_busy(>pdev->dev);
pm_runtime_put_autosuspend(>pdev->dev);
-   if (!(sdd->port_conf->quirks & S3C64XX_SPI_QUIRK_CS_AUTO))
-   writel(S3C64XX_SPI_SLAVE_SIG_INACT, sdd->regs + 
S3C64XX_SPI_SLAVE_SEL);
+   s3c64xx_spi_set_cs(spi, false);
+
return 0;
 
 setup_exit:
pm_runtime_mark_last_busy(>pdev->dev);
pm_runtime_put_autosuspend(>pdev->dev);
/* setup() returns with device de-selected */
-   if (!(sdd->port_conf->quirks & S3C64XX_SPI_QUIRK_CS_AUTO))
-   writel(S3C64XX_SPI_SLAVE_SIG_INACT, sdd->regs + 
S3C64XX_SPI_SLAVE_SEL);
+   s3c64xx_spi_set_cs(spi, false);
 
if (gpio_is_valid(spi->cs_gpio))
gpio_free(spi->cs_gpio);
-- 
2.8.1



[PATCH v2 0/5] s3c64xx: consider the case of a disconnected CS line and some code rework

2016-06-27 Thread Andi Shyti
Hi,

the main goal of the patchset is to support SPI cnnected device
without CS line link.

The first two patches make the s3c64xx driver to consider the
case of a disconnected CS line. This is done by adding a property
in the DTS ("no-cs-readback") which informs the device driver the
absence of a chip selection link.

The last three patches are just some code re-work and
beautification.

Changelog: V1 -> V2

 - the first version of the patchset was removing an 'if'
   statement on "!spi->chip_select" which was causing the SPI
   core to fail. In this case the drivers would have been able to
   set a chip_select = 0 in absence of a CS link. After a short
   discussion with Mark, this has been replaced, as described
   above, by a property in the DTS.

 - one more patch has been added which assigns to some variable
   the proper type

 - some typos fixed in the commit messages

Thanks,
Andi

Andi Shyti (5):
  spi: s3c64xx: group the CS signalling writes in a single function
  spi: s3c64xx: consider the case when the CS line is not connected
  spi: s3c64xx: do not configure the device twice
  spi: s3c64xx: simplify if statement in prepare_transfer function
  spi: s3c64xx: use unsigned type for fifo handling variables

 .../devicetree/bindings/spi/spi-samsung.txt|   3 +
 drivers/spi/spi-s3c64xx.c  | 114 +++--
 include/linux/platform_data/spi-s3c64xx.h  |   1 +
 3 files changed, 65 insertions(+), 53 deletions(-)

-- 
2.8.1



[PATCH v2 2/5] spi: s3c64xx: consider the case when the CS line is not connected

2016-06-27 Thread Andi Shyti
When the CS line is not connected, it is not needed to enable or
disable the chip selection functionality from the s3c64xx
devices in order to perform a transfer.
Set the CS controller logically always enabled already during
initialization (by writing '0' in the S3C64XX_SPI_SLAVE_SEL
register) and never disable it.

Signed-off-by: Andi Shyti 
---
 Documentation/devicetree/bindings/spi/spi-samsung.txt | 3 +++
 drivers/spi/spi-s3c64xx.c | 9 -
 include/linux/platform_data/spi-s3c64xx.h | 1 +
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/spi/spi-samsung.txt 
b/Documentation/devicetree/bindings/spi/spi-samsung.txt
index 6dbdeb3..930bc73 100644
--- a/Documentation/devicetree/bindings/spi/spi-samsung.txt
+++ b/Documentation/devicetree/bindings/spi/spi-samsung.txt
@@ -40,6 +40,9 @@ Optional Board Specific Properties:
 
 - cs-gpios: should specify GPIOs used for chipselects (see spi-bus.txt)
 
+- no-cs-readback: the CS line is disconnected, therefore the device should not
+  operate based on CS signalling.
+
 SPI Controller specific data in SPI slave nodes:
 
 - The spi slave nodes should provide the following information which is 
required
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 972367d..14269b0 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -315,6 +315,9 @@ static void s3c64xx_spi_set_cs(struct spi_device *spi, bool 
enable)
struct s3c64xx_spi_driver_data *sdd =
spi_master_get_devdata(spi->master);
 
+   if (sdd->cntrlr_info->no_cs)
+   return;
+
if (enable) {
if (!(sdd->port_conf->quirks & S3C64XX_SPI_QUIRK_CS_AUTO)) {
writel(0, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
@@ -960,7 +963,9 @@ static void s3c64xx_spi_hwinit(struct 
s3c64xx_spi_driver_data *sdd, int channel)
 
sdd->cur_speed = 0;
 
-   if (!(sdd->port_conf->quirks & S3C64XX_SPI_QUIRK_CS_AUTO))
+   if (sci->no_cs)
+   writel(0, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
+   else if (!(sdd->port_conf->quirks & S3C64XX_SPI_QUIRK_CS_AUTO))
writel(S3C64XX_SPI_SLAVE_SIG_INACT, sdd->regs + 
S3C64XX_SPI_SLAVE_SEL);
 
/* Disable Interrupts - we use Polling if not DMA mode */
@@ -1015,6 +1020,8 @@ static struct s3c64xx_spi_info 
*s3c64xx_spi_parse_dt(struct device *dev)
sci->num_cs = temp;
}
 
+   sci->no_cs = of_property_read_bool(dev->of_node, "broken-cs");
+
return sci;
 }
 #else
diff --git a/include/linux/platform_data/spi-s3c64xx.h 
b/include/linux/platform_data/spi-s3c64xx.h
index fb5625b..5c1e21c 100644
--- a/include/linux/platform_data/spi-s3c64xx.h
+++ b/include/linux/platform_data/spi-s3c64xx.h
@@ -38,6 +38,7 @@ struct s3c64xx_spi_csinfo {
 struct s3c64xx_spi_info {
int src_clk_nr;
int num_cs;
+   bool no_cs;
int (*cfg_gpio)(void);
dma_filter_fn filter;
void *dma_tx;
-- 
2.8.1



[PATCH v2 4/5] spi: s3c64xx: simplify if statement in prepare_transfer function

2016-06-27 Thread Andi Shyti
The whole function is inside an 'if' statement
("!is_polling(sdd)").

Check the opposite of that statement at the beginning and exit,
this way we can have one level less of indentation.

Remove the goto paths as they are redundant.

Signed-off-by: Andi Shyti 
---
 drivers/spi/spi-s3c64xx.c | 50 +--
 1 file changed, 22 insertions(+), 28 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index c65a9e6..6d8486f 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -341,38 +341,32 @@ static int s3c64xx_spi_prepare_transfer(struct spi_master 
*spi)
dma_filter_fn filter = sdd->cntrlr_info->filter;
struct device *dev = >pdev->dev;
dma_cap_mask_t mask;
-   int ret;
 
-   if (!is_polling(sdd)) {
-   dma_cap_zero(mask);
-   dma_cap_set(DMA_SLAVE, mask);
-
-   /* Acquire DMA channels */
-   sdd->rx_dma.ch = dma_request_slave_channel_compat(mask, filter,
-  sdd->cntrlr_info->dma_rx, dev, "rx");
-   if (!sdd->rx_dma.ch) {
-   dev_err(dev, "Failed to get RX DMA channel\n");
-   ret = -EBUSY;
-   goto out;
-   }
-   spi->dma_rx = sdd->rx_dma.ch;
-
-   sdd->tx_dma.ch = dma_request_slave_channel_compat(mask, filter,
-  sdd->cntrlr_info->dma_tx, dev, "tx");
-   if (!sdd->tx_dma.ch) {
-   dev_err(dev, "Failed to get TX DMA channel\n");
-   ret = -EBUSY;
-   goto out_rx;
-   }
-   spi->dma_tx = sdd->tx_dma.ch;
+   if (is_polling(sdd))
+   return 0;
+
+   dma_cap_zero(mask);
+   dma_cap_set(DMA_SLAVE, mask);
+
+   /* Acquire DMA channels */
+   sdd->rx_dma.ch = dma_request_slave_channel_compat(mask, filter,
+  sdd->cntrlr_info->dma_rx, dev, "rx");
+   if (!sdd->rx_dma.ch) {
+   dev_err(dev, "Failed to get RX DMA channel\n");
+   return -EBUSY;
}
+   spi->dma_rx = sdd->rx_dma.ch;
 
-   return 0;
+   sdd->tx_dma.ch = dma_request_slave_channel_compat(mask, filter,
+  sdd->cntrlr_info->dma_tx, dev, "tx");
+   if (!sdd->tx_dma.ch) {
+   dev_err(dev, "Failed to get TX DMA channel\n");
+   dma_release_channel(sdd->rx_dma.ch);
+   return -EBUSY;
+   }
+   spi->dma_tx = sdd->tx_dma.ch;
 
-out_rx:
-   dma_release_channel(sdd->rx_dma.ch);
-out:
-   return ret;
+   return 0;
 }
 
 static int s3c64xx_spi_unprepare_transfer(struct spi_master *spi)
-- 
2.8.1



[PATCH] virtio-blk: Generate uevent after attribute available

2016-06-27 Thread Fam Zheng
Userspace listens to the KOBJ_ADD uevent generated in add_disk. At that
point we haven't created the serial attribute file, therefore depending
on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get
created.

This race condition can be easily reproduced by hot plugging a number of
virtio-blk disks.

Also in systemd, there used to be a related workaround in udev rules
called 'WAIT_FOR="serial"', but it is removed in later versions.

Now let's generate a KOBJ_CHANGE event after the attributes are ready.

Signed-off-by: Fam Zheng 
---
 drivers/block/virtio_blk.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 42758b5..5056007 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -567,6 +567,7 @@ static int virtblk_probe(struct virtio_device *vdev)
 {
struct virtio_blk *vblk;
struct request_queue *q;
+   struct device *ddev;
int err, index;
 
u64 cap;
@@ -746,6 +747,8 @@ static int virtblk_probe(struct virtio_device *vdev)
 _attr_cache_type_ro);
if (err)
goto out_del_disk;
+   ddev = disk_to_dev(vblk->disk);
+   kobject_uevent(>kobj, KOBJ_CHANGE);
return 0;
 
 out_del_disk:
-- 
2.9.0



Re: [PATCH v2 3/3] intel_pstate: Declare pid_params/pstate_funcs/hwp_active __read_mostly

2016-06-27 Thread Jisheng Zhang
Dear Rafael,

On Mon, 27 Jun 2016 10:29:54 -0700
Srinivas Pandruvada  wrote:

> On Mon, 2016-06-27 at 18:07 +0800, Jisheng Zhang wrote:
> > pid_params is written once by copy_pid_params() during
> > initialization,
> > and thereafter is mostly read by hot path intel_pstate_update_util().
> > The read of pid_params gets more after commit a4675fbc4a7a ("cpufreq:
> > intel_pstate: Replace timers with utilization update callbacks")
> > 
> > pstate_funcs is written once by copy_cpu_funcs() during
> > initialization,
> > and thereafter is mostly read by hot path intel_pstate_update_util()
> > 
> > hwp_active is written to once during initialization and thereafter is
> > mostly read by hot path intel_pstate_update_util().
> > 
> > The fact that they are mostly read and not written to makes them
> > candidates for __read_mostly declarations.
> > 
> > Signed-off-by: Jisheng Zhang   
> Acked-by: Srinivas Pandruvada 

oops, I missed Viresh's Ack in this patch, so can you please add the missing

Acked-by: Viresh Kumar 

Sorry for inconvenience,
Jisheng

> > ---
> >  drivers/cpufreq/intel_pstate.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/cpufreq/intel_pstate.c
> > b/drivers/cpufreq/intel_pstate.c
> > index 861bcba..2eda50d 100644
> > --- a/drivers/cpufreq/intel_pstate.c
> > +++ b/drivers/cpufreq/intel_pstate.c
> > @@ -281,9 +281,9 @@ struct cpu_defaults {
> >  static inline int32_t get_target_pstate_use_performance(struct
> > cpudata *cpu);
> >  static inline int32_t get_target_pstate_use_cpu_load(struct cpudata
> > *cpu);
> >  
> > -static struct pstate_adjust_policy pid_params;
> > -static struct pstate_funcs pstate_funcs;
> > -static int hwp_active;
> > +static struct pstate_adjust_policy pid_params __read_mostly;
> > +static struct pstate_funcs pstate_funcs __read_mostly;
> > +static int hwp_active __read_mostly;
> >  
> >  #ifdef CONFIG_ACPI
> >  static bool acpi_ppc;  



[lkp] [x86/mm/64] a611d6b7d4: RIP [] pud_offset+0x6/0x5e

2016-06-27 Thread kernel test robot

FYI, we noticed the following commit:

https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/vmap_stack
commit a611d6b7d4bdf3f57cfc792a45eb1ea5f4b776eb ("x86/mm/64: Enable vmapped 
stacks")


on test machine: 2 threads qemu-system-x86_64 -enable-kvm -cpu Nehalem with 
320M memory

caused below changes:


++++
|| 8518e11969 | 
a611d6b7d4 |
++++
| boot_successes | 0  | 
0  |
| boot_failures  | 16 | 
17 |
| BUG:KASAN:stack-out-of-bounds_in_setjmp_pre_handler_at_addr| 16 | 
   |
| BUG:KASAN:stack-out-of-bounds_in_longjmp_break_handler_at_addr | 16 | 
   |
| backtrace:init_kprobes | 16 | 
   |
| backtrace:kernel_init_freeable | 16 | 
   |
| double_fault:#[##]PREEMPT_SMP_KASAN| 0  | 
17 |
| RIP:pud_offset | 0  | 
17 |
| Kernel_panic-not_syncing:Fatal_exception   | 0  | 
17 |
++++



[0.024009] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0
[0.027432] Freeing SMP alternatives memory: 16K (8a11e000 - 
8a122000)
[0.027432] Freeing SMP alternatives memory: 16K (8a11e000 - 
8a122000)
[0.031457] double fault:  [#1] PREEMPT SMP KASAN
[0.031457] double fault:  [#1] PREEMPT SMP KASAN
[0.032000] Modules linked in:
[0.032000] Modules linked in:

[0.032000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
4.7.0-rc4-00037-ga611d6b #1
[0.032000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
4.7.0-rc4-00037-ga611d6b #1
[0.032000] task: 89a13900 ti: 89a0 task.ti: 
89a0
[0.032000] task: 89a13900 ti: 89a0 task.ti: 
89a0
[0.032000] RIP: 0010:[] 
[0.032000] RIP: 0010:[]  [] 
pud_offset+0x6/0x5e
 [] pud_offset+0x6/0x5e
[0.032000] RSP: :c9018000  EFLAGS: 00010002
[0.032000] RSP: :c9018000  EFLAGS: 00010002
[0.032000] RAX: dc00 RBX: 0003 RCX: 893430b0
[0.032000] RAX: dc00 RBX: 0003 RCX: 893430b0
[0.032000] RDX: 113415ea RSI: f5203039 RDI: 89a0af50
[0.032000] RDX: 113415ea RSI: f5203039 RDI: 89a0af50
[0.032000] RBP: c9018008 R08: 00030001 R09: 0001
[0.032000] RBP: c9018008 R08: 00030001 R09: 0001
[0.032000] R10: 89a07cb0 R11: 8a01c2df R12: 89a0af50
[0.032000] R10: 89a07cb0 R11: 8a01c2df R12: 89a0af50
[0.032000] R13: f5203039 R14:  R15: dc00
[0.032000] R13: f5203039 R14:  R15: dc00
[0.032000] FS:  () GS:88000ee0() 
knlGS:
[0.032000] FS:  () GS:88000ee0() 
knlGS:
[0.032000] CS:  0010 DS:  ES:  CR0: 80050033
[0.032000] CS:  0010 DS:  ES:  CR0: 80050033
[0.032000] CR2: c9017ff8 CR3: 09a0a000 CR4: 06b0
[0.032000] CR2: c9017ff8 CR3: 09a0a000 CR4: 06b0
[0.032000] Stack:
[0.032000] Stack:
[0.032000] 
[0.032000] 
[0.032000] Call Trace:
[0.032000] Call Trace:
[0.032000]   
[0.032000]   

[0.032000] Code: 
[0.032000] Code: 00 00 fc fc ff ff df df 80 80 3c 3c 02 02 00 00 74 74 05 
05 e8 e8 5e 5e 0d 0d 1f 1f 00 00 48 48 8b 8b 83 83 88 88 0a 0a 00 00 00 00 48 
48 c1 c1 e8 e8 08 08 83 83 e0 e0 01 01 0f 0f b6 b6 c0 c0 5b 5b 41 41 5c 5c 5d 
5d c3 c3 55 55 48 48 89 89 e5 e5 41 41 54 54 <53> <53> 49 49 89 89 fc fc 48 48 
c1 c1 ee ee 1b 1b 48 48 89 89 f3 f3 81 81 e3 e3 f8 f8 0f 0f 00 00 00 00 48 48 
89 89 fa fa 48 48 

[0.032000] RIP 
[0.032000] RIP  [] pud_offset+0x6/0x5e
 [] pud_offset+0x6/0x5e
[0.032000]  RSP 
[0.032000]  RSP 
[0.032000] ---[ end trace f29da57a14fc8712 ]---
[0.032000] ---[ end trace f29da57a14fc8712 ]---


FYI, raw QEMU command line is:

qemu-system-x86_64 -enable-kvm -cpu Nehalem -kernel 
/pkg/linux/x86_64-randconfig-b0-06221247+CONFIG_DEBUG_INFO_REDUCED/gcc-6/a611d6b7d4bdf3f57cfc792a45eb1ea5f4b776eb/vmlinuz-4.7.0-rc4-00037-ga611d6b
 -append 'root=/dev/ram0 user=lkp 

Re: [PATCH 0/6] kill off cpu_is_mx*()

2016-06-27 Thread Shawn Guo
On Fri, Jun 24, 2016 at 12:49:55PM +0200, Arnd Bergmann wrote:
> I noticed that i.MX still uses the traditional cpu_is_* functions to
> tell the difference between various SoC families, but every single
> user of those can be replaced with a simpler way, so we can just
> remove it all.
> 
> Please review and apply for 4.8 if it looks good to you.
> 
> Arnd Bergmann (6):
>   ARM: imx: remove cpu_is_mx1 check
>   ARM: imx: deconstruct mxc_rnga initialization
>   ARM: imx: deconstruct mx3_idle
>   ARM: imx: rework mx27_pm_init() call
>   ARM: imx: remove last call to cpu_is_mx5*
>   ARM: imx: remove cpu_is_mx*()

Thanks for cleaning this up.  Applied all.

Shawn


Re: [PATCH v3 5/8] rtc: ac100: Add clk output support

2016-06-27 Thread Chen-Yu Tsai
On Tue, Jun 28, 2016 at 3:23 AM, Maxime Ripard
 wrote:
> On Wed, Jun 22, 2016 at 06:11:55PM +0800, Chen-Yu Tsai wrote:
>> On Wed, Jun 22, 2016 at 6:02 PM, Maxime Ripard
>>  wrote:
>> > Hi,
>> >
>> > On Mon, Jun 20, 2016 at 10:52:15AM +0800, Chen-Yu Tsai wrote:
>> >> + /*
>> >> +  * The ADDA 4 MHz clock is from the codec side of the AC100,
>> >> +  * which is likely a different power domain. However, boards
>> >> +  * always have both sides powered on, so it is impossible to
>> >> +  * test this.
>> >> +  */
>> >
>> > If that ADDA clock is exposed by the codec, why are you putting it in
>> > the RTC?
>>
>> The thing is it's not entirely clear that it's from the codec side.
>> I'm just inferring this from the name. (I'll make the comment clearer.)
>> The codec parts of the datasheet don't mention this clock at all.
>>
>> Allwinner's SDK puts all the clocks under the RTC module. And the
>> are always on, so I can't really turn off the codec and see what
>> happens. That and I don't have an oscilloscope or logic analyzer.
>
> Why not just create a separate clock driver then?

That would mean a separate device node as well. I'd like to keep
the bindings close to how the hardware is organized.

I can move the ADDA clock over to the codec side.

ChenYu


Re: [RFC] Can we bypass the timeout when resetting Synaptics device?

2016-06-27 Thread Yu Chen
Hi Dmitry,
thanks very much for your reply,

On Tue, Jun 28, 2016 at 1:05 AM, Dmitry Torokhov
 wrote:
> Hi Yu,
>
> On Mon, Jun 27, 2016 at 09:04:58PM +0800, Yu Chen wrote:
>> Hi All,
>> Currently I'm doing some tunings on the speed of suspend/resume,
>> it looks like my serio driver tooks a 200ms to finish, which is
>> too long:
>
> Well, PS/2 is not fast, that is why we do not actually do any IO in
> resume handler, but rather schedule work to execute actions in a
> separate thread. You probably need to instrument the call to
> serio_queue_event() in serio_resume() and see what took so long.
Here's the systemtap track result when doing suspend:
In process [rtcwake]
on CPU [3]
 0x81650f00 : __ps2_command+0x0/0x4b0 [kernel]
 0x816513da : ps2_command+0x2a/0x40 [kernel]
 0x8165bc5e : atkbd_cleanup+0x4e/0x60 [kernel]
 0x8164dfc8 : serio_cleanup+0x38/0x50 [kernel]
 0x8164dff5 : serio_suspend+0x15/0x20 [kernel]
 0x815392fe : dpm_run_callback+0x4e/0x130 [kernel]
 0x8153a022 : __device_suspend+0x122/0x350 [kernel]
 0x8153b9e3 : dpm_suspend+0x133/0x2e0 [kernel]
 0x8153bfcf : dpm_suspend_start+0x4f/0x60 [kernel]
 0x810c7709 : suspend_devices_and_enter+0x89/0x6c0 [kernel]
 0x810c7e32 : pm_suspend+0xf2/0x3a0 [kernel]
 0x810c68d5 : state_store+0x75/0xe0 [kernel]
 0x813b2abf : kobj_attr_store+0xf/0x20 [kernel]
 0x8127766a : sysfs_kf_write+0x3a/0x50 [kernel]
 0x81276c8b : kernfs_fop_write+0x11b/0x1a0 [kernel]
 0x811fbff8 : __vfs_write+0x28/0x120 [kernel]
 0x811fcc32 : vfs_write+0xb2/0x1b0 [kernel]
 0x811fdf76 : sys_write+0x46/0xa0 [kernel]
 0x810039d9 : do_syscall_64+0x69/0x110 [kernel]
 0x817fbde5 : return_from_SYSCALL_64+0x0/0x6a [kernel]

But actually the overall suspend time will not be impact by serio too much,
because we can let the pm suspend callbacks running parallelly.

>
> Also, IIRC, there might be some issue when serio_reconnect_driver()
> fails and serio_reconnect_port() forcibly unbinds driver and rescans the
> device for new drivers. If this happens in the middle of PM transition
> there might be some contention on PM locks.
>
>>
>> [ 1120.255783] calling  serio0+ @ 2764, parent: i8042
>> [ 1120.452976] call serio0+ returned 0 after 192472 usecs
>>
>> So further investigation shows that the time cost is in
>> drivers/input/serio/libps2.c: __ps2_command
>>
>> /*
>>  * Some devices (Synaptics) peform the reset before
>>  * ACKing the reset command, and so it can take a long
>>  * time before the ACK arrives.
>>  */
>> if (ps2_sendbyte(ps2dev, command & 0xff,
>>  command == PS2_CMD_RESET_BAT ? 1000 : 200)) {
>> serio_pause_rx(ps2dev->serio);
>> goto out_reset_flags;
>> }
>> If I understand correctly, if it is a Synaptics device, then we have to wait
>> at least 200ms for ATKBD_CMD_RESET_DEF, although this device has already
>> been reset.
>
> No, you are misreading the code. If the command is PS2_CMD_RESET_BAT
> then we will be waiting for up to 1 sec for the reste to complete,
> because Synaptics touchpads may take that long to re-calibrate after
> reset. All other commands have timeout of 200 msec, but that does not
> mean that we wait that long - we'll continue if device responds faster.
Oh, I see. So I guess I did not have a Synaptics device, but it still
waits at least
200ms, maybe it is because of my hardware issue.
>
>>
>> So my question is, could we add flags to distinguish Synaptics device, and
>> if it is a Synaptics device, just do not wait that long time and
>> return after the command
>> has been sent out?
>
> No, because that's not how protocol works.
>
Got it.


-- 
thanks,
Yu


Re: [PATCH 2/2] GFS2: Add a gfs2-specific prune_icache_sb

2016-06-27 Thread Dave Chinner
On Fri, Jun 24, 2016 at 02:50:11PM -0500, Bob Peterson wrote:
> This patch adds a new prune_icache_sb function for the VFS slab
> shrinker to call. Trying to directly free the inodes from memory
> might deadlock because it evicts inodes, which calls into DLM
> to acquire the glock. The DLM, in turn, may block on a pending
> fence operation, which may already be blocked on memory allocation
> that caused the slab shrinker to be called in the first place.
> 
> Signed-off-by: Bob Peterson 

All sorts of problems with this.

> ---
>  fs/gfs2/incore.h |  2 ++
>  fs/gfs2/ops_fstype.c |  1 +
>  fs/gfs2/quota.c  | 25 +
>  fs/gfs2/super.c  | 13 +
>  4 files changed, 41 insertions(+)
> 
> diff --git a/fs/gfs2/incore.h b/fs/gfs2/incore.h
> index a6a3389..a367459 100644
> --- a/fs/gfs2/incore.h
> +++ b/fs/gfs2/incore.h
> @@ -757,6 +757,8 @@ struct gfs2_sbd {
>  
>   struct task_struct *sd_logd_process;
>   struct task_struct *sd_quotad_process;
> + int sd_iprune; /* inodes to prune */
> + spinlock_t sd_shrinkspin;
>  
>   /* Quota stuff */
>  
> diff --git a/fs/gfs2/ops_fstype.c b/fs/gfs2/ops_fstype.c
> index 4546360..65a69be 100644
> --- a/fs/gfs2/ops_fstype.c
> +++ b/fs/gfs2/ops_fstype.c
> @@ -95,6 +95,7 @@ static struct gfs2_sbd *init_sbd(struct super_block *sb)
>   spin_lock_init(>sd_jindex_spin);
>   mutex_init(>sd_jindex_mutex);
>   init_completion(>sd_journal_ready);
> + spin_lock_init(>sd_shrinkspin);
>  
>   INIT_LIST_HEAD(>sd_quota_list);
>   mutex_init(>sd_quota_mutex);
> diff --git a/fs/gfs2/quota.c b/fs/gfs2/quota.c
> index ce7d69a..5810a2c 100644
> --- a/fs/gfs2/quota.c
> +++ b/fs/gfs2/quota.c
> @@ -1528,14 +1528,39 @@ void gfs2_wake_up_statfs(struct gfs2_sbd *sdp) {
>  int gfs2_quotad(void *data)
>  {
>   struct gfs2_sbd *sdp = data;
> + struct super_block *sb = sdp->sd_vfs;
>   struct gfs2_tune *tune = >sd_tune;
>   unsigned long statfs_timeo = 0;
>   unsigned long quotad_timeo = 0;
>   unsigned long t = 0;
>   DEFINE_WAIT(wait);
>   int empty;
> + int rc;
> + struct shrink_control sc = {.gfp_mask = GFP_KERNEL, };
>  

Has not set PF_MEMALLOC context here, so memory reclaim operations that
require allocation to complete won't get access to memory reserves and
hence are likely to deadlock.

>   while (!kthread_should_stop()) {
> + /* TODO: Deal with shrinking of dcache */

I don't think that's ever going to be allowed.

> + /* Prune any inode cache intended by the shrinker. */
> + spin_lock(>sd_shrinkspin);
> + if (sdp->sd_iprune > 0) {
> + sc.nr_to_scan = sdp->sd_iprune;
> + if (sc.nr_to_scan > 1024)
> + sc.nr_to_scan = 1024;

Magic number warning. Where's that come from?

> + sdp->sd_iprune -= sc.nr_to_scan;
> + spin_unlock(>sd_shrinkspin);
> + rc = prune_icache_sb(sb, );
> + if (rc < 0) {
> + spin_lock(>sd_shrinkspin);
> + sdp->sd_iprune = 0;
> + spin_unlock(>sd_shrinkspin);
> + }
> + if (sdp->sd_iprune) {
> + cond_resched();
> + continue;
> + }
> + } else {
> + spin_unlock(>sd_shrinkspin);
> + }

Ok, so this only scans 1024 inodes per loop.  AFAICT, that's  only
once every quotad/statfs timeout, which appears to be 60/30 jiffies
by default.

What this means is that memory pressure is not going to be able to
evict gfs2 inodes at the rate required by memory pressure. If we
have a million cached inodes, and we can only reclaim 1000 every
~50ms, then we've got a severe memory imblance issue. in that same
time, we could be pulling thousands on inodes into the cache

>  
>   /* Update the master statfs file */
>   if (sdp->sd_statfs_force_sync) {
> diff --git a/fs/gfs2/super.c b/fs/gfs2/super.c
> index 9b2ff353..75e8a85 100644
> --- a/fs/gfs2/super.c
> +++ b/fs/gfs2/super.c
> @@ -1667,6 +1667,18 @@ static void gfs2_destroy_inode(struct inode *inode)
>   call_rcu(>i_rcu, gfs2_i_callback);
>  }
>  
> +static long gfs2_prune_icache_sb(struct super_block *sb,
> +  struct shrink_control *sc)
> +{
> + struct gfs2_sbd *sdp;
> +
> + sdp = sb->s_fs_info;
> + spin_lock(>sd_shrinkspin);
> + sdp->sd_iprune = sc->nr_to_scan + 1;
> + spin_unlock(>sd_shrinkspin);
> + return 0;

And so this is even more problematic. sc->nr_to_scan is set to to
either the shrinker batch size or SHRINK_BATCH (128), and the return
value of the shrinker is the number of objects freed. When the
shrinker calculates the number of objects that need to be freed from
the slab 

Re: [PATCH 1/1] usb: dwc2: add printf attribute to cat_printf()

2016-06-27 Thread John Youn
On 6/26/2016 1:12 AM, Nicolas Iooss wrote:
> As cat_printf() uses printf format strings in its parameters, adding
> __printf attribute allows the compiler to detect at compile-time some
> errors related to format strings (with -Wformat warning flag).
> 
> Signed-off-by: Nicolas Iooss 
> ---
>  drivers/usb/dwc2/hcd_queue.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/dwc2/hcd_queue.c b/drivers/usb/dwc2/hcd_queue.c
> index b5c7793a2df2..13754353251f 100644
> --- a/drivers/usb/dwc2/hcd_queue.c
> +++ b/drivers/usb/dwc2/hcd_queue.c
> @@ -367,7 +367,8 @@ static void pmap_unschedule(unsigned long *map, int 
> bits_per_period,
>   * @fmt:   The format for printf.
>   * @...:   The args for printf.
>   */
> -static void cat_printf(char **buf, size_t *size, const char *fmt, ...)
> +static __printf(3, 4)
> +void cat_printf(char **buf, size_t *size, const char *fmt, ...)
>  {
>   va_list args;
>   int i;
> 

Acked-by: John Youn 

John



Re: [PATCH] USB: dwc2-usb: add USB_GADGET dependency

2016-06-27 Thread John Youn
On 6/24/2016 12:28 AM, Arnd Bergmann wrote:
> The driver selects NOP_USB_XCEIV, which can only be built-in if
> USB_GADGET is either disabled or also built-in, so with USB_DWC2_PCI=y
> and USB_GADGET=m, NOP_USB_XCEIV is also built-in and we get this link
> error:
> 
> drivers/usb/built-in.o: In function `nop_set_peripheral':
> (text+0x1927c): undefined reference to `usb_gadget_vbus_connect'
> drivers/usb/built-in.o: In function `nop_gpio_vbus_thread':
> (text+0x197a0): undefined reference to `usb_gadget_vbus_connect'
> (text+0x19830): undefined reference to `usb_gadget_vbus_disconnect'
> 
> This adds the same dependency for the dwc2 driver to avoid that
> broken configuration.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/usb/dwc2/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/usb/dwc2/Kconfig b/drivers/usb/dwc2/Kconfig
> index c1f29caa8990..e838701d6dd5 100644
> --- a/drivers/usb/dwc2/Kconfig
> +++ b/drivers/usb/dwc2/Kconfig
> @@ -55,6 +55,7 @@ endchoice
>  config USB_DWC2_PCI
>   tristate "DWC2 PCI"
>   depends on PCI
> + depends on USB_GADGET || !USB_GADGET
>   default n
>   select NOP_USB_XCEIV
>   help
> 

Acked-by: John Youn 


John


Re: [PATCH v3] ARM: dts: sun7i: Add BCM53125 switch nodes to the lamobo-r1 board

2016-06-27 Thread Chen-Yu Tsai
On Tue, Jun 28, 2016 at 8:45 AM, Florian Fainelli  wrote:
> Now that we have a proper binding for Ethernet switches hanging off
> different buses, and a driver for the BCM53125 switch, add its Device
> Tree as a child MDIO node, at MDIO address 30 (Broadcom pseudo-PHY
> address) and describe the ports layout of the Lamobo R1 board.
>
> Signed-off-by: Florian Fainelli 

Acked-by: Chen-Yu Tsai 


Re: [PATCH 2/2] ARM: dts: imx53: add support for USB armory board

2016-06-27 Thread Shawn Guo
On Tue, Jun 21, 2016 at 04:50:53PM +0200, and...@inversepath.com wrote:
> From: Andrej Rosano 
> 
> Add support for Inverse Path USB armory board, an open source
> flash-drive sized computer based on NXP i.MX53 SoC.
> 
> https://inversepath.com/usbarmory
> 
> Signed-off-by: Andrej Rosano 
> ---
>  arch/arm/boot/dts/Makefile|   1 +
>  arch/arm/boot/dts/imx53-usbarmory.dts | 239 
> ++
>  2 files changed, 240 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx53-usbarmory.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 414b427..f8f85ab 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -303,6 +303,7 @@ dtb-$(CONFIG_SOC_IMX53) += \
>   imx53-smd.dtb \
>   imx53-tx53-x03x.dtb \
>   imx53-tx53-x13x.dtb \
> + imx53-usbarmory.dtb \
>   imx53-voipac-bsb.dtb
>  dtb-$(CONFIG_SOC_IMX6Q) += \
>   imx6dl-apf6dev.dtb \
> diff --git a/arch/arm/boot/dts/imx53-usbarmory.dts 
> b/arch/arm/boot/dts/imx53-usbarmory.dts
> new file mode 100644
> index 000..9a172fd
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx53-usbarmory.dts
> @@ -0,0 +1,239 @@
> +/*
> + * USB armory MkI device tree include file
> + * https://inversepath.com/usbarmory
> + *
> + * Copyright (C) 2015, Inverse Path
> + * Andrej Rosano 
> + *
> + * Licensed under GPLv2
> + */

Maybe GPL/X11 dual licence to consider non-Linux users.  There are
plenty of dual licence examples under arch/arm/boot/dts.

> +
> +/dts-v1/;
> +#include "imx53.dtsi"
> +
> +/ {
> + model = "Inverse Path USB armory";
> + compatible = "inversepath,imx53-usbarmory", "fsl,imx53";
> +};
> +
> +/ {
> + chosen {
> + stdout-path = 
> + };
> +
> + memory {
> + reg = <0x7000 0x2000>;
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <_pin_gpio4_27>;
> +
> + user {
> + label = "LED";
> + gpios = < 27 0>;

Use the macro in include/dt-bindings/gpio/gpio.h for polarity.

> + linux,default-trigger = "heartbeat";
> + };
> + };
> +};
> +
> + {
> + operating-points = <
> + /* kHz */
> + 16  85
> + 40  90
> + 80 105
> + >;

Can you put some comments in there explaining why you need a custom opp
table for the board?

> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_esdhc1>;
> + status = "okay";
> +};
> +
> + {
> + pinctrl-names = "default";

The property makes no sense where there is no pinctrl-0 property.

> +
> + imx53-usbarmory {

This container node can be dropped to save an indentation level.

> + led_pin_gpio4_27: led_gpio4_27@0 {

Can this node be named in a similar scheme as other pinctrl entries?

> + fsl,pins = <
> + MX53_PAD_DISP0_DAT6__GPIO4_27 0x0
> + >;
> + };
> +
> + pinctrl_esdhc1: esdhc1grp {
> + fsl,pins = <
> + MX53_PAD_SD1_DATA0__ESDHC1_DAT0 0x1d5
> + MX53_PAD_SD1_DATA1__ESDHC1_DAT1 0x1d5
> + MX53_PAD_SD1_DATA2__ESDHC1_DAT2 0x1d5
> + MX53_PAD_SD1_DATA3__ESDHC1_DAT3 0x1d5
> + MX53_PAD_SD1_CMD__ESDHC1_CMD0x1d5
> + MX53_PAD_SD1_CLK__ESDHC1_CLK0x1d5
> + >;
> + };
> +
> + pinctrl_i2c1_pmic: i2c1grp_pmic {

Please try to sort these pinctrl entries alphabetically.

> + fsl,pins = <
> + MX53_PAD_EIM_D21__I2C1_SCL  0x0
> + MX53_PAD_EIM_D28__I2C1_SDA  0x0
> + >;
> + };
> +
> + /*
> +  * UART mode pin header configration
> +  * 3 - GPIO5[26], pull-down 100K
> +  * 4 - GPIO5[27], pull-down 100K
> +  * 5 - TX, pull-up 100K
> +  * 6 - RX, pull-up 100K
> +  * 7 - GPIO5[30], pull-down 100K
> +  */
> + pinctrl_uart1: uart1grp {
> + fsl,pins = <
> + MX53_PAD_CSI0_DAT8__GPIO5_260xc0
> + MX53_PAD_CSI0_DAT9__GPIO5_270xc0
> + MX53_PAD_CSI0_DAT10__UART1_TXD_MUX  0x1e4
> + MX53_PAD_CSI0_DAT11__UART1_RXD_MUX  0x1e4
> + MX53_PAD_CSI0_DAT12__GPIO5_30   0xc0
> + >;
> + };
> +
> + /*
> +  * GPIO mode pin 

Re: [PATCH] hwmon: (jc42) Add support for Microchip MCP9808 temperature sensor

2016-06-27 Thread Guenter Roeck

On 06/27/2016 05:23 PM, Alison Schofield wrote:

MCP9808 is not officially compliant to JC-42, similar to MCP9804,
but its registers are compatible to JC-42.

Signed-off-by: Alison Schofield 
Cc: Daniel Baluta 


Applied to -next.

Thanks,
Guenter



  1   2   3   4   5   6   7   8   >