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

[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: linux-next - lockdep whine in MMC/SDHC code

[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

[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

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

[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

[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 4/9] tty: serial: fsl_lpuart: fix clearing of receive flag

[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

[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

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

[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

[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 net-next 6/9] net: hns: normalize two different loop

[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

[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 v3 1/3]nbd: fix might_sleep warning on socket shutdown

[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);
> queue_flag_clear_unlocked(QUEUE_FLAG_DISCARD, nbd->disk->queue);
> del_timer_sync(>timeout_timer);
>  }
> @@ -802,11 +813,11 @@ 

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

[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

[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 2/3] powerpc/spinlock: support vcpu preempted check

[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] arc: warn only once if DW2_UNWIND is disabled

[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 5/8] KEYS: Provide software public key query function [ver #2]

[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

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

[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

[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

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

[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

[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 1/2] ipc/sem.c: Fix complex_count vs. simple op race

[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

[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 0/4] ftrace: One more check on x86 and some small fixes

[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

[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
>

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

[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

[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 0/2] Add mt6755 basic chip support

[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

[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

[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>;
+  

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

[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

[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>;
+   };
+   };
+
+   uart_clk: dummy26m {
+   

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

[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 v3 2/3] iio: Add driver for Broadcom iproc-static-adc

[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
> >>> +
> >>> +/* IPROC ADC Channel register offsets */
> >>> +#define IPROC_ADC_CHANNEL_REGCTL1 

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

[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: [PATCH v2] notifier: Fix soft lockup for notifier_call_chain().

[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

[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: acpi: broken suspend to RAM with v4.7-rc1

[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

[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] capabilities: add capability cgroup controller

[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

[Bjorn Andersson]

On Fri 17 Jun 03:15 PDT 2016, Neil Armstrong wrote:

> Signed-off-by: Neil Armstrong 

Acked-by: Bjorn Andersson 

Regards,
Bjorn

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

[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

[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 

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

[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 software; you can redistribute it and/or
-- 
end-of-patch for PATCH V1

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

[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 1/2] pinctrl: qcom: Add support for MDM9615 TLMM

[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

[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: [PATCH 2/3] powerpc/spinlock: support vcpu preempted check

[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？

[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 

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

[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().

[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

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

[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

[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 

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

[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 otg_leave_state(struct otg_fsm *fsm, enum
> usb_otg_state old_state)
>   fsm->a_wait_bcon_tmout = 0;
>   break;
>   case OTG_STATE_A_HOST:
> + 

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

[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

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

[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

[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

[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

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

[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

[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

[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

[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 4/5] ARM: dts: rockchip: add the panel power supply for rk3288-evb board with act8846 pmu

[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

[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

[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

[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 1/5] dt-bindings: Add support for LG LP079QX1-SP0V 1536x2048 panel

[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

[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

[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 v1 0/5] Enable graphic support on RK3288 EVB boards

[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

[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 2/3] powerpc/opal: Add #define to get rc from an ASYNC_COMP opal_msg

[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 @@ static int 

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

[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

[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

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

[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 b/drivers/char/Kconfig
index 601f64f..fdb8f3e 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -178,6 

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

[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？

[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.

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

[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

[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

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

[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

[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 2/2] ARM: cache-l2x0.c: Do not clear bit 23 in prefetch control register

[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

[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()

[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

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

[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()

[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

[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

[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 2/5] mmu: pass execonly value when initializing rsvd bits

[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

[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

[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 0/5] Add support for EPT execute only for nested hypervisors

[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

[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

[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

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

[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

[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

[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] arc: warn only once if DW2_UNWIND is disabled

[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

[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 v3 0/3] toshiba_acpi: Accelerometer updates

[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