Re: [PATCH] clk: at91: fix num_parents test in at91sam9260 slow clk implementation

[Mike Turquette]

Quoting Boris BREZILLON (2014-09-02 08:27:51)
> The slow clk block provided by at91sam9260 and derived SoCs should always
> have 2 parents.
> 
> Signed-off-by: Boris BREZILLON 
> ---
> 
> Hello Mike,
> 
> Could you take this fix for the next 3.17 rc ?
> Without this fix you won't be able to use programmable clks (the slow
> clk is one of the parents of prog clks), and these prog clks are used,
> among other things, to provide clks to external audio chips.
> 
> No need to backport this fix to previous stable releases, as CCF support
> for at91sam9260 (and derived) SoCs only appeared in 3.17.

Pulled into clk-fixes.

Regards,
Mike

> 
> Best Regards,
> 
> Boris
> 
>  drivers/clk/at91/clk-slow.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/at91/clk-slow.c b/drivers/clk/at91/clk-slow.c
> index 0300c46..32f7c1b 100644
> --- a/drivers/clk/at91/clk-slow.c
> +++ b/drivers/clk/at91/clk-slow.c
> @@ -447,7 +447,7 @@ void __init of_at91sam9260_clk_slow_setup(struct 
> device_node *np,
> int i;
>  
> num_parents = of_count_phandle_with_args(np, "clocks", 
> "#clock-cells");
> -   if (num_parents <= 0 || num_parents > 1)
> +   if (num_parents != 2)
> return;
>  
> for (i = 0; i < num_parents; ++i) {
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 00/26] tty/serial flow control fixes

[Peter Hurley]

Hi Greg,

This patch series reworks the internals of tty and serial flow control to
fix multiple races in both START/STOP flow control and RTS/CTS flow control.

The main changes in this series are:
Patch 1
   Backs out the UPF_HARD_FLOW kludge for 8250. This revert should be
   for mainline and -next

Patches 3-7
   Fixes to x_char handling (ie., sending START/STOP) both in the serial
   core and to several UART drivers

Patches 10-15
   Rename and move ASYNC_CTS_FLOW and ASYNC_CHECK_CD statuses into
   a private field for the serial core, and add helper functions to test
   those statuses for UART drivers.

   This is a necessary step toward making tty port->flags SMP-safe, without
   introducing a new lock.

Patches 14, 17 and 21
   Make CTS flow control state SMP-safe, by moving hw_stopped into a private
   field of the serial core.

Patches 22-24
   Make tty flow control changes mutually exclusive.

   Protecting tty->stopped and tty->flow_stopped with a new spin lock (instead
   of the ->ctrl_lock) is required to fix multiple races with controlling
   terminal changes, coming in a follow-on patch series.

Patches 25 and 26
   Cleanup tcflow(TCIxxx)

Regards,

Peter Hurley (26):
  Revert "serial: uart: add hw flow control support configuration"
  serial: Style fix
  serial: imx: Fix x_char handling and tx flow control
  serial: core: Fix x_char race
  serial: core: Remove unsafe x_char optimization
  serial: Fix send_xchar() handlers
  serial: mpc52xx: Use default serial core x_char handler
  serial: sunsab: Don't enable tx if tx stopped
  serial: blackfin: Fix missing gpio.h
  serial: core: Document lock requirement for UPF_* flags updates
  serial: 8250: Document serial8250_modem_status() locking
  serial: core: Unwrap tertiary assignment in uart_handle_dcd_change()
  locking: Add non-fatal spin lock assert
  serial: core: Document and assert lock requirements for irq helpers
  serial: core: Privatize modem status enable flags
  isdn: i4l: Remove ASYNC_CTS_FLOW
  serial: core: Privatize tty->hw_stopped
  usb: serial: Remove unused tty->hw_stopped
  serial: bfin-uart: Fix auto CTS
  serial: core: Use spin_lock_irq() in uart_set_termios()
  tty: Convert tty_struct bitfield to bools
  tty: Serialize tty flow control changes with flow_lock
  tty: Move packet mode flow control notifications to pty driver
  tty: Serialize tcflow() with other tty flow control changes
  tty: Move and rename send_prio_char() as tty_send_xchar()
  tty: Hold termios_rwsem for tcflow(TCIxxx)

 .../devicetree/bindings/serial/of-serial.txt   |   1 -
 Documentation/serial/driver|   2 +
 drivers/isdn/i4l/isdn_tty.c|   5 -
 drivers/tty/pty.c  |  41 
 drivers/tty/serial/8250/8250_core.c|   7 +-
 drivers/tty/serial/bfin_sport_uart.c   |   1 +
 drivers/tty/serial/bfin_uart.c |  15 +--
 drivers/tty/serial/imx.c   |  39 +++-
 drivers/tty/serial/mpc52xx_uart.c  |  17 
 drivers/tty/serial/mxs-auart.c |   2 +-
 drivers/tty/serial/of_serial.c |   4 -
 drivers/tty/serial/serial_core.c   | 109 +++--
 drivers/tty/serial/sunhv.c |   3 +
 drivers/tty/serial/sunsab.c|   5 +-
 drivers/tty/tty_io.c   |  93 +++---
 drivers/tty/tty_ioctl.c|  47 +++--
 drivers/usb/serial/digi_acceleport.c   |   7 +-
 drivers/usb/serial/io_ti.c |   7 +-
 drivers/usb/serial/ti_usb_3410_5052.c  |   7 +-
 include/linux/serial_core.h|  16 ++-
 include/linux/spinlock.h   |   1 +
 include/linux/spinlock_api_smp.h   |   1 +
 include/linux/spinlock_api_up.h|   1 +
 include/linux/tty.h|  11 ++-
 include/linux/tty_driver.h |   4 +
 25 files changed, 238 insertions(+), 208 deletions(-)

-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 04/26] serial: core: Fix x_char race

[Peter Hurley]

The UART driver is expected to clear port->x_char after
transmission while holding the port->lock. However, the serial
core fails to take the port->lock before assigning port->xchar.
This allows for the following race

CPU 0 |  CPU 1
  |
  | serial8250_handle_irq
  |   ...
  |   serial8250_tx_chars
  | if (port->x_char)
  |   serial_out(up, UART_TX, port->x_char)
uart_send_xchar   |
  port->x_char = ch   |
  |   port->x_char = 0
  port->ops->start_tx()   |
  |

The x_char on CPU 0 will never be sent.

Take the port->lock in uart_send_xchar() before assigning port->x_char.

Signed-off-by: Peter Hurley 
---
 drivers/tty/serial/serial_core.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 87cde4c..a68bff0 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -596,12 +596,11 @@ static void uart_send_xchar(struct tty_struct *tty, char 
ch)
if (port->ops->send_xchar)
port->ops->send_xchar(port, ch);
else {
+   spin_lock_irqsave(>lock, flags);
port->x_char = ch;
-   if (ch) {
-   spin_lock_irqsave(>lock, flags);
+   if (ch)
port->ops->start_tx(port);
-   spin_unlock_irqrestore(>lock, flags);
-   }
+   spin_unlock_irqrestore(>lock, flags);
}
 }
 
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 03/26] serial: imx: Fix x_char handling and tx flow control

[Peter Hurley]

The serial core expects the UART driver to transmit x_char
(START/STOP chars) even if tx is stopped and before data already
in the tx ring buffer if possible. Also, sending x_char must
not cause additional data in the tx ring buffer to transmit
if tx is stopped.

Cause x_char to be transmitted before any other data is sent.
Auto-stop tx if the tx ring buffer is empty or tx should be stopped.
Only perform one write wakeup if tx ring buffer space is below
threshold.

x_char handling in DMA mode is still broken; add FIXME.

Signed-off-by: Peter Hurley 
---
 drivers/tty/serial/imx.c | 39 ---
 1 file changed, 16 insertions(+), 23 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 044e86d..c86f153 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -464,9 +464,19 @@ static inline void imx_transmit_buffer(struct imx_port 
*sport)
 {
struct circ_buf *xmit = >port.state->xmit;
 
+   if (sport->port.x_char) {
+   /* Send next char */
+   writel(sport->port.x_char, sport->port.membase + URTX0);
+   return;
+   }
+
+   if (uart_circ_empty(xmit) || uart_tx_stopped(>port)) {
+   imx_stop_tx(>port);
+   return;
+   }
+
while (!uart_circ_empty(xmit) &&
-   !(readl(sport->port.membase + uts_reg(sport))
-   & UTS_TXFULL)) {
+  !(readl(sport->port.membase + uts_reg(sport)) & UTS_TXFULL)) {
/* send xmit->buf[xmit->tail]
 * out the port here */
writel(xmit->buf[xmit->tail], sport->port.membase + URTX0);
@@ -567,9 +577,6 @@ static void imx_start_tx(struct uart_port *port)
struct imx_port *sport = (struct imx_port *)port;
unsigned long temp;
 
-   if (uart_circ_empty(>state->xmit))
-   return;
-
if (USE_IRDA(sport)) {
/* half duplex in IrDA mode; have to disable receive mode */
temp = readl(sport->port.membase + UCR4);
@@ -604,7 +611,10 @@ static void imx_start_tx(struct uart_port *port)
}
 
if (sport->dma_is_enabled) {
-   imx_dma_tx(sport);
+   /* FIXME: port->x_char must be transmitted if != 0 */
+   if (!uart_circ_empty(>state->xmit) &&
+   !uart_tx_stopped(port))
+   imx_dma_tx(sport);
return;
}
 
@@ -632,27 +642,10 @@ static irqreturn_t imx_rtsint(int irq, void *dev_id)
 static irqreturn_t imx_txint(int irq, void *dev_id)
 {
struct imx_port *sport = dev_id;
-   struct circ_buf *xmit = >port.state->xmit;
unsigned long flags;
 
spin_lock_irqsave(>port.lock, flags);
-   if (sport->port.x_char) {
-   /* Send next char */
-   writel(sport->port.x_char, sport->port.membase + URTX0);
-   goto out;
-   }
-
-   if (uart_circ_empty(xmit) || uart_tx_stopped(>port)) {
-   imx_stop_tx(>port);
-   goto out;
-   }
-
imx_transmit_buffer(sport);
-
-   if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
-   uart_write_wakeup(>port);
-
-out:
spin_unlock_irqrestore(>port.lock, flags);
return IRQ_HANDLED;
 }
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 06/26] serial: Fix send_xchar() handlers

[Peter Hurley]

START_CHAR() & STOP_CHAR() can be disabled if set to '\0'
(__DISABLED_CHAR).  UART drivers which define a send_xchar()
handler must not transmit __DISABLED_CHAR.

Document requirement.

Affected drivers:
sunsab
sunhv

cc: David S. Miller 
cc: 
Signed-off-by: Peter Hurley 
---
 Documentation/serial/driver | 2 ++
 drivers/tty/serial/sunhv.c  | 3 +++
 drivers/tty/serial/sunsab.c | 3 +++
 3 files changed, 8 insertions(+)

diff --git a/Documentation/serial/driver b/Documentation/serial/driver
index 3bba1ae..ba64e4b 100644
--- a/Documentation/serial/driver
+++ b/Documentation/serial/driver
@@ -140,6 +140,8 @@ hardware.
will append the character to the circular buffer and then call
start_tx() / stop_tx() to flush the data out.
 
+   Do not transmit if ch == '\0' (__DISABLED_CHAR).
+
Locking: none.
Interrupts: caller dependent.
 
diff --git a/drivers/tty/serial/sunhv.c b/drivers/tty/serial/sunhv.c
index 20521db..25d43ce 100644
--- a/drivers/tty/serial/sunhv.c
+++ b/drivers/tty/serial/sunhv.c
@@ -268,6 +268,9 @@ static void sunhv_send_xchar(struct uart_port *port, char 
ch)
unsigned long flags;
int limit = 1;
 
+   if (ch == __DISABLED_CHAR)
+   return;
+
spin_lock_irqsave(>lock, flags);
 
while (limit-- > 0) {
diff --git a/drivers/tty/serial/sunsab.c b/drivers/tty/serial/sunsab.c
index bb09920..c83b1c6 100644
--- a/drivers/tty/serial/sunsab.c
+++ b/drivers/tty/serial/sunsab.c
@@ -459,6 +459,9 @@ static void sunsab_send_xchar(struct uart_port *port, char 
ch)
struct uart_sunsab_port *up = (struct uart_sunsab_port *) port;
unsigned long flags;
 
+   if (ch == __DISABLED_CHAR)
+   return;
+
spin_lock_irqsave(>port.lock, flags);
 
sunsab_tec_wait(up);
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next v2] net: bpf: make eBPF interpreter images read-only

[Hannes Frederic Sowa]

On Tue, Sep 2, 2014, at 23:40, Eric Dumazet wrote:
> On Tue, 2014-09-02 at 14:31 -0700, Alexei Starovoitov wrote:
> 
> > > +static inline void bpf_prog_unlock_ro(struct bpf_prog *fp)
> > > +{
> > > +   set_memory_rw((unsigned long)fp, fp->pages);
> > 
> > why rw is needed?
> > since fp is allocated with vmalloc, vfree doesn't need
> > to touch the pages to free them, no?
> 
> That assumes that vmalloc() do not have any debugging features, like
> poisoning content before freeing, to catch some use after free.
> 
> Lets be clean and safe, and give back same memory permission we had
> after vmalloc()

Yes, I agree. I just went down the kmemleak codepaths and we certainly
don't want to cause issues in there if the implementation changes one
day.

Bye,
Hannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] mm: clean up zone flags

[David Rientjes]

On Tue, 2 Sep 2014, Johannes Weiner wrote:

> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 318df7051850..48bf12ef6620 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -521,13 +521,13 @@ struct zone {
>   atomic_long_t   vm_stat[NR_VM_ZONE_STAT_ITEMS];
>  } cacheline_internodealigned_in_smp;
>  
> -typedef enum {
> +enum zone_flags {
>   ZONE_RECLAIM_LOCKED,/* prevents concurrent reclaim */
>   ZONE_OOM_LOCKED,/* zone is in OOM killer zonelist */
>   ZONE_CONGESTED, /* zone has many dirty pages backed by
>* a congested BDI
>*/
> - ZONE_TAIL_LRU_DIRTY,/* reclaim scanning has recently found
> + ZONE_DIRTY, /* reclaim scanning has recently found
>* many dirty file pages at the tail
>* of the LRU.
>*/
> @@ -535,52 +535,7 @@ typedef enum {
>* many pages under writeback
>*/
>   ZONE_FAIR_DEPLETED, /* fair zone policy batch depleted */
> -} zone_flags_t;
> -
> -static inline void zone_set_flag(struct zone *zone, zone_flags_t flag)
> -{
> - set_bit(flag, >flags);
> -}
> -
> -static inline int zone_test_and_set_flag(struct zone *zone, zone_flags_t 
> flag)
> -{
> - return test_and_set_bit(flag, >flags);
> -}
> -
> -static inline void zone_clear_flag(struct zone *zone, zone_flags_t flag)
> -{
> - clear_bit(flag, >flags);
> -}
> -
> -static inline int zone_is_reclaim_congested(const struct zone *zone)
> -{
> - return test_bit(ZONE_CONGESTED, >flags);
> -}
> -
> -static inline int zone_is_reclaim_dirty(const struct zone *zone)
> -{
> - return test_bit(ZONE_TAIL_LRU_DIRTY, >flags);
> -}
> -
> -static inline int zone_is_reclaim_writeback(const struct zone *zone)
> -{
> - return test_bit(ZONE_WRITEBACK, >flags);
> -}
> -
> -static inline int zone_is_reclaim_locked(const struct zone *zone)
> -{
> - return test_bit(ZONE_RECLAIM_LOCKED, >flags);
> -}
> -
> -static inline int zone_is_fair_depleted(const struct zone *zone)
> -{
> - return test_bit(ZONE_FAIR_DEPLETED, >flags);
> -}
> -
> -static inline int zone_is_oom_locked(const struct zone *zone)
> -{
> - return test_bit(ZONE_OOM_LOCKED, >flags);
> -}
> +};
>  
>  static inline unsigned long zone_end_pfn(const struct zone *zone)
>  {
> diff --git a/mm/backing-dev.c b/mm/backing-dev.c
> index 1706cbbdf5f0..d7a9051a6db5 100644
> --- a/mm/backing-dev.c
> +++ b/mm/backing-dev.c
> @@ -631,7 +631,7 @@ long wait_iff_congested(struct zone *zone, int sync, long 
> timeout)
>* of sleeping on the congestion queue
>*/
>   if (atomic_read(_bdi_congested[sync]) == 0 ||
> - !zone_is_reclaim_congested(zone)) {
> + test_bit(ZONE_CONGESTED, >flags)) {
>   cond_resched();
>  
>   /* In case we scheduled, work out time remaining */

That's not equivalent.

[snip]

> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 2836b5373b2e..590a92bec6a4 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -920,7 +920,7 @@ static unsigned long shrink_page_list(struct list_head 
> *page_list,
>   /* Case 1 above */
>   if (current_is_kswapd() &&
>   PageReclaim(page) &&
> - zone_is_reclaim_writeback(zone)) {
> + test_bit(ZONE_WRITEBACK, >flags)) {
>   nr_immediate++;
>   goto keep_locked;
>  
> @@ -1002,7 +1002,7 @@ static unsigned long shrink_page_list(struct list_head 
> *page_list,
>*/
>   if (page_is_file_cache(page) &&
>   (!current_is_kswapd() ||
> -  !zone_is_reclaim_dirty(zone))) {
> +  test_bit(ZONE_DIRTY, >flags))) {
>   /*
>* Immediately reclaim when written back.
>* Similar in principal to deactivate_page()

Nor is this.

After fixed, for the oom killer bits:

Acked-by: David Rientjes 

since this un-obscurification is most welcome.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 05/26] serial: core: Remove unsafe x_char optimization

[Peter Hurley]

uart_unthrottle() attempts to avoid sending START and the previous
x_char if the previous x_char has not yet been sent. However, this
optimization could leave the sender in a throttled state; for example,
if the sender is throttled and this unthrottle coincides with a manual
tcflow(TCION) from user-space, then neither START would be sent.

Signed-off-by: Peter Hurley 
---
 drivers/tty/serial/serial_core.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index a68bff0..11c8fe6 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -643,12 +643,8 @@ static void uart_unthrottle(struct tty_struct *tty)
mask &= ~port->flags;
}
 
-   if (mask & UPF_SOFT_FLOW) {
-   if (port->x_char)
-   port->x_char = 0;
-   else
-   uart_send_xchar(tty, START_CHAR(tty));
-   }
+   if (mask & UPF_SOFT_FLOW)
+   uart_send_xchar(tty, START_CHAR(tty));
 
if (mask & UPF_HARD_FLOW)
uart_set_mctrl(port, TIOCM_RTS);
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 07/26] serial: mpc52xx: Use default serial core x_char handler

[Peter Hurley]

mpc52xx_uart_send_xchar() is _identical_ to the default serial core
x_char handling behavior in uart_send_xchar().

Remove mpc52xx_uart_send_xchar().

Signed-off-by: Peter Hurley 
---
 drivers/tty/serial/mpc52xx_uart.c | 17 -
 1 file changed, 17 deletions(-)

diff --git a/drivers/tty/serial/mpc52xx_uart.c 
b/drivers/tty/serial/mpc52xx_uart.c
index 97888f4..a5f4e36 100644
--- a/drivers/tty/serial/mpc52xx_uart.c
+++ b/drivers/tty/serial/mpc52xx_uart.c
@@ -1087,22 +1087,6 @@ mpc52xx_uart_start_tx(struct uart_port *port)
 }
 
 static void
-mpc52xx_uart_send_xchar(struct uart_port *port, char ch)
-{
-   unsigned long flags;
-   spin_lock_irqsave(>lock, flags);
-
-   port->x_char = ch;
-   if (ch) {
-   /* Make sure tx interrupts are on */
-   /* Truly necessary ??? They should be anyway */
-   psc_ops->start_tx(port);
-   }
-
-   spin_unlock_irqrestore(>lock, flags);
-}
-
-static void
 mpc52xx_uart_stop_rx(struct uart_port *port)
 {
/* port->lock taken by caller */
@@ -1361,7 +1345,6 @@ static struct uart_ops mpc52xx_uart_ops = {
.get_mctrl  = mpc52xx_uart_get_mctrl,
.stop_tx= mpc52xx_uart_stop_tx,
.start_tx   = mpc52xx_uart_start_tx,
-   .send_xchar = mpc52xx_uart_send_xchar,
.stop_rx= mpc52xx_uart_stop_rx,
.enable_ms  = mpc52xx_uart_enable_ms,
.break_ctl  = mpc52xx_uart_break_ctl,
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 8/9] ARM: tegra: jetson-tk1: Add xHCI support

[Andrew Bresticker]

Assign USB ports previously owned by the EHCI controllers to the xHCI
controller.  There is a mini-PCIe USB port (UTMI port 1) and a USB A
connector (UTMI port 2, USB3 port 0).  PCIe lane 0 is used for USB3
port 0.

Signed-off-by: Andrew Bresticker 
---
Changes from v2:
 - Updated VBUS power supply names.
Changes from v1:
 - Updated USB power supplies.
---
 arch/arm/boot/dts/tegra124-jetson-tk1.dts | 48 +--
 1 file changed, 27 insertions(+), 21 deletions(-)

diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts 
b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
index 624b0fb..a473750 100644
--- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
+++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
@@ -1515,7 +1515,7 @@
regulator-always-on;
};
 
-   ldo0 {
+   avdd_1v05_run: ldo0 {
regulator-name = "+1.05V_RUN_AVDD";
regulator-min-microvolt = <105>;
regulator-max-microvolt = <105>;
@@ -1619,15 +1619,40 @@
nvidia,sys-clock-req-active-high;
};
 
+   usb@0,7009 {
+   status = "okay";
+   phys = < TEGRA_XUSB_PADCTL_UTMI_P1>, /* mini-PCIe USB */
+  < TEGRA_XUSB_PADCTL_UTMI_P2>, /* USB A */
+  < TEGRA_XUSB_PADCTL_USB3_P0>; /* USB A */
+   phy-names = "utmi-1", "utmi-2", "usb3-0";
+   avddio-pex-supply = <_1v05_run>;
+   dvddio-pex-supply = <_1v05_run>;
+   avdd-usb-supply = <_3v3_lp0>;
+   avdd-pll-utmip-supply = <_1v8>;
+   avdd-pll-erefe-supply = <_1v05_run>;
+   avdd-pex-pll-supply = <_1v05_run>;
+   hvdd-pex-supply = <_3v3_lp0>;
+   hvdd-pex-plle-supply = <_3v3_lp0>;
+   };
+
padctl@0,7009f000 {
pinctrl-0 = <_default>;
pinctrl-names = "default";
 
+   vbus-2-supply = <_usb3_vbus>;
+   nvidia,usb3-port-0-lane = ;
+
padctl_default: pinmux {
+   otg {
+   nvidia,lanes = "otg-1", "otg-2";
+   nvidia,function = "xusb";
+   };
+
usb3 {
-   nvidia,lanes = "pcie-0", "pcie-1";
+   nvidia,lanes = "pcie-0";
nvidia,function = "usb3";
nvidia,iddq = <0>;
+   nvidia,usb2-port-num = <2>;
};
 
pcie {
@@ -1668,25 +1693,6 @@
};
};
 
-   /* mini-PCIe USB */
-   usb@0,7d004000 {
-   status = "okay";
-   };
-
-   usb-phy@0,7d004000 {
-   status = "okay";
-   };
-
-   /* USB A connector */
-   usb@0,7d008000 {
-   status = "okay";
-   };
-
-   usb-phy@0,7d008000 {
-   status = "okay";
-   vbus-supply = <_usb3_vbus>;
-   };
-
clocks {
compatible = "simple-bus";
#address-cells = <1>;
-- 
2.1.0.rc2.206.gedb03e5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 01/26] Revert "serial: uart: add hw flow control support configuration"

[Peter Hurley]

This reverts commit 06aa82e498c144c7784a6f3d3b55458b272d6146.
This commit purports to enable auto CTS flow control for the 8250
UART driver. However, the 8250 UART driver already supports auto
CTS flow control via UART_CAP_AFE and UART_CAP_EFR. Indeed, this
patch introduces another DT attribute for which an existing firmware
flag already exists ("auto-flow-control"). Furthermore, the use of
UPF_HARD_FLOW requires the UART driver to define .throttle and
.unthrottle methods, neither of which are defined for the 8250 UART
driver (which will result in a NULL ptr dereference). Finally, this patch
supposes to fix existing bugs in the serial core for auto CTS-enabled
hardware, but does not include the class of hardware for which these
bugs exist.

CC: Murali Karicheri 
CC: Rob Herring 
Signed-off-by: Peter Hurley 
---
 Documentation/devicetree/bindings/serial/of-serial.txt |  1 -
 drivers/tty/serial/8250/8250_core.c|  6 ++
 drivers/tty/serial/of_serial.c |  4 
 drivers/tty/serial/serial_core.c   | 12 +++-
 4 files changed, 5 insertions(+), 18 deletions(-)

diff --git a/Documentation/devicetree/bindings/serial/of-serial.txt 
b/Documentation/devicetree/bindings/serial/of-serial.txt
index 7705477..1928a3e 100644
--- a/Documentation/devicetree/bindings/serial/of-serial.txt
+++ b/Documentation/devicetree/bindings/serial/of-serial.txt
@@ -37,7 +37,6 @@ Optional properties:
 - auto-flow-control: one way to enable automatic flow control support. The
   driver is allowed to detect support for the capability even without this
   property.
-- has-hw-flow-control: the hardware has flow control capability.
 
 Example:
 
diff --git a/drivers/tty/serial/8250/8250_core.c 
b/drivers/tty/serial/8250/8250_core.c
index 7a91c6d..109da60 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -2333,11 +2333,9 @@ serial8250_do_set_termios(struct uart_port *port, struct 
ktermios *termios,
 * the trigger, or the MCR RTS bit is cleared.  In the case where
 * the remote UART is not using CTS auto flow control, we must
 * have sufficient FIFO entries for the latency of the remote
-* UART to respond.  IOW, at least 32 bytes of FIFO. Also enable
-* AFE if hw flow control is supported
+* UART to respond.  IOW, at least 32 bytes of FIFO.
 */
-   if ((up->capabilities & UART_CAP_AFE && (port->fifosize >= 32)) ||
-   (port->flags & UPF_HARD_FLOW)) {
+   if (up->capabilities & UART_CAP_AFE && port->fifosize >= 32) {
up->mcr &= ~UART_MCR_AFE;
if (termios->c_cflag & CRTSCTS)
up->mcr |= UART_MCR_AFE;
diff --git a/drivers/tty/serial/of_serial.c b/drivers/tty/serial/of_serial.c
index 68d4455..27981e2 100644
--- a/drivers/tty/serial/of_serial.c
+++ b/drivers/tty/serial/of_serial.c
@@ -183,10 +183,6 @@ static int of_platform_serial_probe(struct platform_device 
*ofdev)
  "auto-flow-control"))
port8250.capabilities |= UART_CAP_AFE;
 
-   if (of_property_read_bool(ofdev->dev.of_node,
- "has-hw-flow-control"))
-   port8250.port.flags |= UPF_HARD_FLOW;
-
ret = serial8250_register_8250_port();
break;
}
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index c2f90ec..261e49e 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -174,12 +174,8 @@ static int uart_port_startup(struct tty_struct *tty, 
struct uart_state *state,
if (tty->termios.c_cflag & CBAUD)
uart_set_mctrl(uport, TIOCM_RTS | TIOCM_DTR);
}
-   /*
-* if hw support flow control without software intervention,
-* then skip the below check
-*/
-   if (tty_port_cts_enabled(port) &&
-   !(uport->flags & UPF_HARD_FLOW)) {
+
+   if (tty_port_cts_enabled(port)) {
spin_lock_irq(>lock);
if (!(uport->ops->get_mctrl(uport) & TIOCM_CTS))
tty->hw_stopped = 1;
@@ -2777,9 +2773,7 @@ void uart_handle_cts_change(struct uart_port *uport, 
unsigned int status)
 
uport->icount.cts++;
 
-   /* skip below code if the hw flow control is supported */
-   if (tty_port_cts_enabled(port) &&
-   !(uport->flags & UPF_HARD_FLOW)) {
+   if (tty_port_cts_enabled(port)) {
if (tty->hw_stopped) {
if (status) {
tty->hw_stopped = 0;
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

Re: [PATCH net-next v2] net: bpf: make eBPF interpreter images read-only

[Eric Dumazet]

On Tue, 2014-09-02 at 14:31 -0700, Alexei Starovoitov wrote:

> > +static inline void bpf_prog_unlock_ro(struct bpf_prog *fp)
> > +{
> > +   set_memory_rw((unsigned long)fp, fp->pages);
> 
> why rw is needed?
> since fp is allocated with vmalloc, vfree doesn't need
> to touch the pages to free them, no?

That assumes that vmalloc() do not have any debugging features, like
poisoning content before freeing, to catch some use after free.

Lets be clean and safe, and give back same memory permission we had
after vmalloc()



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 08/26] serial: sunsab: Don't enable tx if tx stopped

[Peter Hurley]

The serial core may call the UART driver's start_tx() even if
tx is stopped; the UART driver must verify tx should be enabled
before transmitting.

Reported-by: Sam Ravnborg 
cc: David S. Miller 
cc: 
Signed-off-by: Peter Hurley 
---
 drivers/tty/serial/sunsab.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/sunsab.c b/drivers/tty/serial/sunsab.c
index c83b1c6..448a93b 100644
--- a/drivers/tty/serial/sunsab.c
+++ b/drivers/tty/serial/sunsab.c
@@ -427,7 +427,7 @@ static void sunsab_start_tx(struct uart_port *port)
struct circ_buf *xmit = >port.state->xmit;
int i;
 
-   if (uart_circ_empty(xmit))
+   if (uart_circ_empty(xmit) || uart_tx_stopped(port))
return;
 
up->interrupt_mask1 &= ~(SAB82532_IMR1_ALLS|SAB82532_IMR1_XPR);
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 09/26] serial: blackfin: Fix missing gpio.h

[Peter Hurley]

If CONFIG_SERIAL_BFIN_CTSRTS is set, compile fails because of missing
declarations for the gpio_* api. Include necessary header.

Signed-off-by: Peter Hurley 
---
 drivers/tty/serial/bfin_sport_uart.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/tty/serial/bfin_sport_uart.c 
b/drivers/tty/serial/bfin_sport_uart.c
index 7810aa2..d62d8da 100644
--- a/drivers/tty/serial/bfin_sport_uart.c
+++ b/drivers/tty/serial/bfin_sport_uart.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V4 1/8] namespaces: assign each namespace instance a serial number

[Richard Guy Briggs]

On 14/08/28, Eric W. Biederman wrote:
> Richard Guy Briggs  writes:
> > On 14/08/23, Eric W. Biederman wrote:
> >> Richard Guy Briggs  writes:
> >> 
> >> > Generate and assign a serial number per namespace instance since boot.
> >> >
> >> > Use a serial number per namespace (unique across one boot of one kernel)
> >> > instead of the inode number (which is claimed to have had the right to 
> >> > change
> >> > reserved and is not necessarily unique if there is more than one proc 
> >> > fs) to
> >> > uniquely identify it per kernel boot.
> >> 
> >> This approach is just broken.
> >> 
> >> For this to work with migration (aka criu) you need to implement a
> >> namespace of namespaces.  You haven't done this, and therefore
> >> such an interface will break existing userspace.
> >> 
> >> Inside of audit I can understand not caring about these issues,
> >> but you go foward and expose these serial numbers in proc,
> >> and generally make this infrastructure available to others.
> >> 
> >> The deep issue with migration is that we move tasks from one machine
> >> from another and on the destination machine we need to have all of the
> >> same global identifiers for software to function properly.
> >> 
> >> My weasel words around the proc inode numbers is to preserve to allow us
> >> room to be able to restore those ids if it every becomes relevant for
> >> migration.
> >
> > What do you do if the inode number is already in use on the target
> > host?
> 
> Since the inode numbers are relative to a superblock or a pid namespace
> the numbers that are in use can be restored on the target system
> by creating them in the appropriate namespace.

So you seem to be advocating for a namespace of namespaces, since
neither host can create a new namespace without consulting the others in
its pool for a new free number.

> The support does not exist in the kernel today for doing that because no
> one has cared but as architected the support can be added if needed to
> support migration.
> 
> >> That is the proc inode numbers (technically) live in a pid namespace,
> >> (aka a mount of proc).  So depending on the pid namespace you are in
> >> or the mount of proc you look in the numbers could change.
> >> 
> >> Qualifications like that must exist to have a prayer of ever supporting
> >> process migration in the crazy corner cases where people start caring
> >> about inode numbers.
> >> 
> >> We currently don't and inode numbers for a namespace will never change
> >> after a namespace is created.  So I think you really are ok using the
> >> proc inode numbers.  I am happy declaring by fiat that the inode numbers
> >> that audit uses are the numbers connected to the initial pid namespace.
> >
> > But once a namespace/container is migrated, it is a different audit that
> > is looking at it (unless we create an audit manager or entity that
> > functions at the level of a container manager), so audit should not care.
> 
> These numbers were exported to everyone as a general purpose facility in
> proc.  If audit is global and audit doesn't migrate you are right it
> doesn't matter.  However if these numbers are used by anyone else for
> anything else it causes a problem.

So let us restrict their use to audit, by removing them from
/proc//ns/ and only exposing them via netlink calls to audit gated
by CAP_AUDIT_WRITE or CAP_AUDIT_CONTROL.

> Further given that people run entire distributions in containers we may
> reach the point where we wish to run auditd in a container in the
> future.  I would hate to paint ourselves into a corner with a design
> that could never allow audit to migrate.  Support that case someday
> seems a valid naive desire.

Agreed.  That is an option we do not want to rule out at this point.
I'll need to think about this one more.

> >> At a fairly basic level anything that is used to identify namespaces for
> >> any general purpose use needs to have most if not all of the same
> >> properties of the proc inode numbers.  The most important of which is
> >> being tied to some context/namespace so there is a ability if we ever
> >> need it to migrate those numbers from one machine to another.
> >
> > Sooo...  does it make any sense to have those inode or serial numbers be
> > blank inside the namespace/container itself, but only visible to its
> > manager outside the container (unless it is the initial namespace)?
> 
> Mostly I think it makes sense to use the inode numbers from the initial
> pid namespace.  They already exist.  They already are unique.  (Which
> means I don't need to maintain more code and more special cases).  And
> the do what you need now.

Will inode numbers never be re-used once they are freed?  Guaranteed?

> I probably haven't followed closely enough but I don't see what makes
> inode numbers undesirable.

This posting:
https://www.redhat.com/archives/linux-audit/2013-March/msg00032.html

> Eric

- RGB

--
Richard Guy Briggs 
Senior Software Engineer, Kernel Security, AMER ENG 

[PATCH 02/26] serial: Style fix

[Peter Hurley]

Unwrap if() conditional; no functional change.

Signed-off-by: Peter Hurley 
---
 drivers/tty/serial/serial_core.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 261e49e..87cde4c 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1283,8 +1283,7 @@ static void uart_set_termios(struct tty_struct *tty,
/* Handle transition away from B0 status */
else if (!(old_termios->c_cflag & CBAUD) && (cflag & CBAUD)) {
unsigned int mask = TIOCM_DTR;
-   if (!(cflag & CRTSCTS) ||
-   !test_bit(TTY_THROTTLED, >flags))
+   if (!(cflag & CRTSCTS) || !test_bit(TTY_THROTTLED, >flags))
mask |= TIOCM_RTS;
uart_set_mctrl(uport, mask);
}
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 3/9] of: Update Tegra XUSB pad controller binding for USB

[Andrew Bresticker]

Add new bindings used for USB support by the Tegra XUSB pad controller.
This includes additional PHY types, USB-specific pinconfig properties, etc.

Signed-off-by: Andrew Bresticker 
---
Changes from v2:
 - Added nvidia,otg-hs-curr-level-offset property.
 - Dropped "-otg" from VBUS supplies.
 - Added mbox-names property.
 - Removed extra whitespace.
Changes from v1:
 - Updated to use common mailbox bindings.
 - Made USB3 port-to-lane mappins a top-level binding rather than a pinconfig
   binding.
 - Add #defines for the padctl lanes.
---
 .../pinctrl/nvidia,tegra124-xusb-padctl.txt| 56 --
 include/dt-bindings/pinctrl/pinctrl-tegra-xusb.h   | 20 
 2 files changed, 72 insertions(+), 4 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt 
b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt
index 2f9c0bd..4a1b9475 100644
--- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt
@@ -21,6 +21,18 @@ Required properties:
   - padctl
 - #phy-cells: Should be 1. The specifier is the index of the PHY to reference.
   See  for the list of valid values.
+- mboxes: Must contain an entry for the XUSB mailbox channel.
+  See ../mailbox/mailbox.txt for details.
+- mbox-names: Must include the following entries:
+  - xusb
+
+Optional properties:
+---
+- vbus-{0,1,2}-supply: VBUS regulator for the corresponding UTMI pad.
+- vddio-hsic-supply: VDDIO regulator for the HSIC pads.
+- nvidia,usb3-port-{0,1}-lane: PCIe/SATA lane to which the corresponding USB3
+  port is mapped.  See  for the list
+  of valid values.
 
 Lane muxing:
 
@@ -50,6 +62,17 @@ Optional properties:
   pin or group should be assigned to. Valid values for function names are
   listed below.
 - nvidia,iddq: Enables IDDQ mode of the lane. (0: no, 1: yes)
+- nvidia,usb2-port-num: USB2 port (0, 1, or 2) to which the lane is mapped.
+- nvidia,hsic-strobe-trim: HSIC strobe trimmer value.
+- nvidia,hsic-rx-strobe-trim: HSIC RX strobe trimmer value.
+- nvidia,hsic-rx-data-trim: HSIC RX data trimmer value.
+- nvidia,hsic-tx-rtune-n: HSIC TX RTUNEN value.
+- nvidia,hsic-tx-rtune-p: HSIC TX RTUNEP value.
+- nvidia,hsic-tx-slew-n: HSIC TX SLEWN value.
+- nvidia,hsic-tx-slew-p: HSIC TX SLEWP value.
+- nvidia,hsic-auto-term: Enables HSIC AUTO_TERM. (0: no, 1: yes)
+- nvidia,otg-hs-curr-level-offset: Offset to be applied to the pad's fused
+  HS_CURR_LEVEL value.
 
 Note that not all of these properties are valid for all lanes. Lanes can be
 divided into three groups:
@@ -58,18 +81,21 @@ divided into three groups:
 
 Valid functions for this group are: "snps", "xusb", "uart", "rsvd".
 
-The nvidia,iddq property does not apply to this group.
+The nvidia,otg-hs-curr-level-offset property only applies.
 
   - ulpi-0, hsic-0, hsic-1:
 
 Valid functions for this group are: "snps", "xusb".
 
-The nvidia,iddq property does not apply to this group.
+The nvidia,hsic-* properties apply only to the pins hsic-{0,1} when
+the function is xusb.
 
   - pcie-0, pcie-1, pcie-2, pcie-3, pcie-4, sata-0:
 
 Valid functions for this group are: "pcie", "usb3", "sata", "rsvd".
 
+The nvidia,usb2-port-num property only applies and is required when
+the function is usb3.
 
 Example:
 
@@ -82,6 +108,8 @@ SoC file extract:
reg = <0x0 0x7009f000 0x0 0x1000>;
resets = <_car 142>;
reset-names = "padctl";
+   mboxes = <_mbox>;
+   mbox-names = "xusb";
 
#phy-cells = <1>;
};
@@ -100,15 +128,35 @@ Board file extract:
 
...
 
+   usb@0,7009 {
+   ...
+
+   phys = < 5>, < 6>, < 7>;
+   phy-names = "utmi-1", "utmi-2", "usb3-0";
+
+   ...
+   }
+
+   ...
+
padctl: padctl@0,7009f000 {
pinctrl-0 = <_default>;
pinctrl-names = "default";
 
+   nvidia,usb3-port-0-lane = ;
+   vbus-2-supply = <_usb3_vbus>;
+
padctl_default: pinmux {
-   usb3 {
-   nvidia,lanes = "pcie-0", "pcie-1";
+   otg {
+   nvidia,lanes = "otg-1", "otg-2";
+   nvidia,function = "xusb";
+   };
+
+   usb3p0 {
+   nvidia,lanes = "pcie-0";
nvidia,function = "usb3";
nvidia,iddq = <0>;
+   nvidia,usb2-port-num = <2>;
};
 
pcie {
diff --git a/include/dt-bindings/pinctrl/pinctrl-tegra-xusb.h 
b/include/dt-bindings/pinctrl/pinctrl-tegra-xusb.h
index 914d56d..17b1aab 100644
--- 

[PATCH v3 4/9] pinctrl: tegra-xusb: Add USB PHY support

[Andrew Bresticker]

In addition to the PCIe and SATA PHYs, the XUSB pad controller also
supports 3 UTMI, 2 HSIC, and 2 USB3 PHYs.  Each USB3 PHY uses a single
PCIe or SATA lane and is mapped to one of the three UTMI ports.

The xHCI controller will also send messages intended for the PHY driver,
so request and listen for messages on the mailbox's PHY channel.

Signed-off-by: Andrew Bresticker 
Acked-by: Linus Walleij 
---
Changes from v2:
 - Added support for nvidia,otg-hs-curr-level-offset property.
 - Moved mailbox request handling to workqueue.
 - Added filtering out of non-PHY mailbox messages.
 - Dropped "-otg" from VBUS supplies.
Changes from v1:
 - Updated to use common mailbox API.
 - Added SATA PHY enable sequence for USB3 ports using the SATA lane.
 - Made USB3 port-to-lane mappins a top-level binding rather than a pinconfig
   binding.
---
 drivers/pinctrl/Kconfig  |1 +
 drivers/pinctrl/pinctrl-tegra-xusb.c | 1233 +-
 include/soc/tegra/xusb.h |7 +
 3 files changed, 1213 insertions(+), 28 deletions(-)

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index bfd2c2e..d5bc4f5 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -265,6 +265,7 @@ config PINCTRL_TEGRA_XUSB
select GENERIC_PHY
select PINCONF
select PINMUX
+   select MAILBOX
 
 config PINCTRL_TZ1090
bool "Toumaz Xenif TZ1090 pin control driver"
diff --git a/drivers/pinctrl/pinctrl-tegra-xusb.c 
b/drivers/pinctrl/pinctrl-tegra-xusb.c
index e641b42..0618be5 100644
--- a/drivers/pinctrl/pinctrl-tegra-xusb.c
+++ b/drivers/pinctrl/pinctrl-tegra-xusb.c
@@ -13,23 +13,54 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
+
+#include 
+#include 
 
 #include 
 
 #include "core.h"
 #include "pinctrl-utils.h"
 
+#define FUSE_SKU_CALIB_HS_CURR_LEVEL_PADX_SHIFT(x) ((x) ? 15 : 0)
+#define FUSE_SKU_CALIB_HS_CURR_LEVEL_PAD_MASK 0x3f
+#define FUSE_SKU_CALIB_HS_IREF_CAP_SHIFT 13
+#define FUSE_SKU_CALIB_HS_IREF_CAP_MASK 0x3
+#define FUSE_SKU_CALIB_HS_SQUELCH_LEVEL_SHIFT 11
+#define FUSE_SKU_CALIB_HS_SQUELCH_LEVEL_MASK 0x3
+#define FUSE_SKU_CALIB_HS_TERM_RANGE_ADJ_SHIFT 7
+#define FUSE_SKU_CALIB_HS_TERM_RANGE_ADJ_MASK 0xf
+
+#define XUSB_PADCTL_USB2_PORT_CAP 0x008
+#define XUSB_PADCTL_USB2_PORT_CAP_PORTX_CAP_SHIFT(x) ((x) * 4)
+#define XUSB_PADCTL_USB2_PORT_CAP_PORT_CAP_MASK 0x3
+#define XUSB_PADCTL_USB2_PORT_CAP_DISABLED 0x0
+#define XUSB_PADCTL_USB2_PORT_CAP_HOST 0x1
+#define XUSB_PADCTL_USB2_PORT_CAP_DEVICE 0x2
+#define XUSB_PADCTL_USB2_PORT_CAP_OTG 0x3
+
+#define XUSB_PADCTL_SS_PORT_MAP 0x014
+#define XUSB_PADCTL_SS_PORT_MAP_PORTX_SHIFT(x) ((x) * 4)
+#define XUSB_PADCTL_SS_PORT_MAP_PORT_MASK 0x7
+
 #define XUSB_PADCTL_ELPG_PROGRAM 0x01c
 #define XUSB_PADCTL_ELPG_PROGRAM_AUX_MUX_LP0_VCORE_DOWN (1 << 26)
 #define XUSB_PADCTL_ELPG_PROGRAM_AUX_MUX_LP0_CLAMP_EN_EARLY (1 << 25)
 #define XUSB_PADCTL_ELPG_PROGRAM_AUX_MUX_LP0_CLAMP_EN (1 << 24)
+#define XUSB_PADCTL_ELPG_PROGRAM_SSPX_ELPG_VCORE_DOWN(x) (1 << (18 + (x) * 4))
+#define XUSB_PADCTL_ELPG_PROGRAM_SSPX_ELPG_CLAMP_EN_EARLY(x) \
+   (1 << (17 + (x) * 4))
+#define XUSB_PADCTL_ELPG_PROGRAM_SSPX_ELPG_CLAMP_EN(x) (1 << (16 + (x) * 4))
 
 #define XUSB_PADCTL_IOPHY_PLL_P0_CTL1 0x040
 #define XUSB_PADCTL_IOPHY_PLL_P0_CTL1_PLL0_LOCKDET (1 << 19)
@@ -41,17 +72,136 @@
 #define XUSB_PADCTL_IOPHY_PLL_P0_CTL2_TXCLKREF_EN (1 << 5)
 #define XUSB_PADCTL_IOPHY_PLL_P0_CTL2_TXCLKREF_SEL (1 << 4)
 
+#define XUSB_PADCTL_IOPHY_USB3_PADX_CTL2(x) (0x058 + (x) * 4)
+#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_CDR_CNTL_SHIFT 24
+#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_CDR_CNTL_MASK 0xff
+#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_RX_EQ_Z_SHIFT 16
+#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_RX_EQ_Z_MASK 0x3f
+#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_RX_EQ_G_SHIFT 8
+#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_RX_EQ_G_MASK 0x3f
+#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_RX_EQ_SHIFT 8
+#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_RX_EQ_MASK 0x
+#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_RX_WANDER_SHIFT 4
+#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL2_RX_WANDER_MASK 0x7
+
+#define XUSB_PADCTL_IOPHY_USB3_PADX_CTL4(x) (0x068 + (x) * 4)
+#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL4_DFE_CNTL_TAP_SHIFT 24
+#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL4_DFE_CNTL_TAP_MASK 0x1f
+#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL4_DFE_CNTL_AMP_SHIFT 16
+#define XUSB_PADCTL_IOPHY_USB3_PAD_CTL4_DFE_CNTL_AMP_MASK 0x7f
+
+#define XUSB_PADCTL_IOPHY_MISC_PAD_PX_CTL2(x) ((x) < 2 ? 0x078 + (x) * 4 : \
+  0x0f8 + (x) * 4)
+#define XUSB_PADCTL_IOPHY_MISC_PAD_CTL2_SPARE_IN_SHIFT 28
+#define XUSB_PADCTL_IOPHY_MISC_PAD_CTL2_SPARE_IN_MASK 0x3
+
+#define XUSB_PADCTL_IOPHY_MISC_PAD_PX_CTL5(x) ((x) < 2 ? 0x090 + (x) * 4 : \
+  0x11c + (x) * 4)
+#define 

[PATCH v3 2/9] mailbox: Add NVIDIA Tegra XUSB mailbox driver

[Andrew Bresticker]

The Tegra xHCI controller's firmware communicates requests to the host
processor through a mailbox interface.  While there is only a single
physical channel, messages sent by the controller can be divided
into two groups: those intended for the PHY driver and those intended
for the host-controller driver.  The requesting driver is assigned
one of two virtual channels when the single physical channel is
requested.  All incoming messages are sent to both virtual channels.

Signed-off-by: Andrew Bresticker 
---
Jassi: I've handled the sharing by making the channels in the Tegra
driver 'virtual' channels.  Having the mailbox core handle channel
sharing would be a much more invasive change, but let me know if that's
what you'd prefer.

Changes from v2:
 - Fixed mailbox IRQ vs. channel alloc/free race.
 - Renamed defines to match TRM.
 - Dropped channel specifier and instead allocated virtual channels as they
   were requested.
 - Removed MODULE_ALIAS.
Changes from v1:
 - Converted to common mailbox framework.
 - Removed useless polling sequences in TX path.
 - Moved xusb include from linux/ to soc/tegra/
---
 drivers/mailbox/Kconfig  |   3 +
 drivers/mailbox/Makefile |   2 +
 drivers/mailbox/tegra-xusb-mailbox.c | 290 +++
 include/soc/tegra/xusb.h |  46 ++
 4 files changed, 341 insertions(+)
 create mode 100644 drivers/mailbox/tegra-xusb-mailbox.c
 create mode 100644 include/soc/tegra/xusb.h

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 9fd9c67..97369c2 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -33,4 +33,7 @@ config OMAP_MBOX_KFIFO_SIZE
  Specify the default size of mailbox's kfifo buffers (bytes).
  This can also be changed at runtime (via the mbox_kfifo_size
  module parameter).
+
+config TEGRA_XUSB_MBOX
+   def_bool y if ARCH_TEGRA
 endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 94ed7ce..7f0af9c 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -5,3 +5,5 @@ obj-$(CONFIG_MAILBOX)   += mailbox.o
 obj-$(CONFIG_PL320_MBOX)   += pl320-ipc.o
 
 obj-$(CONFIG_OMAP2PLUS_MBOX)   += omap-mailbox.o
+
+obj-$(CONFIG_TEGRA_XUSB_MBOX)  += tegra-xusb-mailbox.o
diff --git a/drivers/mailbox/tegra-xusb-mailbox.c 
b/drivers/mailbox/tegra-xusb-mailbox.c
new file mode 100644
index 000..2d87b8a
--- /dev/null
+++ b/drivers/mailbox/tegra-xusb-mailbox.c
@@ -0,0 +1,290 @@
+/*
+ * NVIDIA Tegra XUSB mailbox driver
+ *
+ * Copyright (C) 2014 NVIDIA Corporation
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define XUSB_CFG_ARU_MBOX_CMD  0xe4
+#define  MBOX_DEST_FALCBIT(27)
+#define  MBOX_DEST_PME BIT(28)
+#define  MBOX_DEST_SMI BIT(29)
+#define  MBOX_DEST_XHCIBIT(30)
+#define  MBOX_INT_EN   BIT(31)
+#define XUSB_CFG_ARU_MBOX_DATA_IN  0xe8
+#define  CMD_DATA_SHIFT0
+#define  CMD_DATA_MASK 0xff
+#define  CMD_TYPE_SHIFT24
+#define  CMD_TYPE_MASK 0xff
+#define XUSB_CFG_ARU_MBOX_DATA_OUT 0xec
+#define XUSB_CFG_ARU_MBOX_OWNER0xf0
+#define  MBOX_OWNER_NONE   0
+#define  MBOX_OWNER_FW 1
+#define  MBOX_OWNER_SW 2
+#define XUSB_CFG_ARU_SMI_INTR  0x428
+#define  MBOX_SMI_INTR_FW_HANG BIT(1)
+#define  MBOX_SMI_INTR_EN  BIT(3)
+
+struct tegra_xusb_mbox {
+   struct mbox_controller mbox;
+   int irq;
+   void __iomem *regs;
+   spinlock_t lock;
+   bool vchan_allocated[TEGRA_XUSB_MBOX_NUM_CHANS];
+};
+
+static inline u32 mbox_readl(struct tegra_xusb_mbox *mbox, unsigned long 
offset)
+{
+   return readl(mbox->regs + offset);
+}
+
+static inline void mbox_writel(struct tegra_xusb_mbox *mbox, u32 val,
+  unsigned long offset)
+{
+   writel(val, mbox->regs + offset);
+}
+
+static inline u32 mbox_pack_msg(struct tegra_xusb_mbox_msg *msg)
+{
+   u32 val;
+
+   val = (msg->cmd & CMD_TYPE_MASK) << CMD_TYPE_SHIFT;
+   val |= (msg->data & CMD_DATA_MASK) << CMD_DATA_SHIFT;
+
+   return val;
+}
+
+static inline void mbox_unpack_msg(u32 val, struct tegra_xusb_mbox_msg *msg)
+{
+   msg->cmd = (val >> CMD_TYPE_SHIFT) & CMD_TYPE_MASK;
+   msg->data = (val >> CMD_DATA_SHIFT) & CMD_DATA_MASK;
+}
+
+static int tegra_xusb_mbox_send_data(struct 

[PATCH v3 5/9] of: Add NVIDIA Tegra xHCI controller binding

[Andrew Bresticker]

Add device-tree binding documentation for the xHCI controller present
on Tegra124 and later SoCs.

Signed-off-by: Andrew Bresticker 
---
Changes from v2:
 - Added mbox-names property.
Changes from v1:
 - Updated to use common mailbox bindings.
 - Added remaining XUSB-related clocks and resets.
 - Updated list of power supplies to be more accurate wrt to the hardware.
---
 .../bindings/usb/nvidia,tegra124-xhci.txt  | 104 +
 1 file changed, 104 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt

diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt 
b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt
new file mode 100644
index 000..51a7751
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt
@@ -0,0 +1,104 @@
+NVIDIA Tegra xHCI controller
+
+
+The Tegra xHCI controller supports both USB2 and USB3 interfaces exposed
+by the Tegra XUSB pad controller.
+
+Required properties:
+
+ - compatible: Should be "nvidia,tegra124-xhci".
+ - reg: Address and length of the register sets.  There should be three
+   entries in the following order: xHCI host registers, FPCI registers, and
+   IPFS registers.
+ - interrupts: xHCI host interrupt.
+ - clocks: Must contain an entry for each entry in clock-names.
+   See ../clock/clock-bindings.txt for details.
+ - clock-names: Must include the following entries:
+- xusb_host
+- xusb_host_src
+- xusb_dev
+- xusb_dev_src
+- xusb_falcon_src
+- xusb_ss
+- xusb_ss_src
+- xusb_ss_div2
+- xusb_hs_src
+- xusb_fs_src
+- pll_u_480m
+- clk_m
+- pll_e
+ - resets: Must contain an entry for each entry in reset-names.
+   See ../reset/reset.txt for details.
+ - reset-names: Must include the following entries:
+   - xusb_host
+   - xusb_dev
+   - xusb_ss
+   - xusb
+   Note that xusb_dev is the shared reset for xusb_dev and xusb_dev_src and
+   that xusb is the shared reset for xusb_{ss,hs,fs,falcon,host}_src.
+ - mboxes: Must contain an entry for the XUSB mailbox channel.
+   See ../mailbox/mailbox.txt for details.
+ - mbox-names: Must include the following entries:
+   - xusb
+
+Optional properties:
+
+ - phys: Must contain an entry for each entry in phy-names.
+   See ../phy/phy-bindings.txt for details.
+ - phy-names: Should include an entry for each PHY used by the controller.
+   May be a subset of the following:
+- utmi-{0,1,2}
+- hsic-{0,1}
+- usb3-{0,1}
+ - avddio-pex-supply: PCIe/USB3 analog logic power supply.  Must supply 1.05V.
+ - dvddio-pex-supply: PCIe/USB3 digital logic power supply.  Must supply 1.05V.
+ - avdd-usb-supply: USB controller power supply.  Must supply 3.3V.
+ - avdd-pll-utmip-supply: UTMI PLL power supply.  Must supply 1.8V.
+ - avdd-pll-erefe-supply: PLLE reference PLL power supply.  Must supply 1.05V.
+ - avdd-pex-pll-supply: PCIe/USB3 PLL power supply.  Must supply 1.05V.
+ - hvdd-pex-supply: High-voltage PCIe/USB3 power supply.  Must supply 3.3V.
+ - hvdd-pex-plle-supply: High-voltage PLLE power supply.  Must supply 3.3V.
+
+Example:
+
+   usb@0,7009 {
+   compatible = "nvidia,tegra124-xhci";
+   reg = <0x0 0x7009 0x0 0x8000>,
+ <0x0 0x70098000 0x0 0x1000>,
+ <0x0 0x70099000 0x0 0x1000>;
+   interrupts = ;
+   clocks = <_car TEGRA124_CLK_XUSB_HOST>,
+<_car TEGRA124_CLK_XUSB_HOST_SRC>,
+<_car TEGRA124_CLK_XUSB_DEV>,
+<_car TEGRA124_CLK_XUSB_DEV_SRC>,
+<_car TEGRA124_CLK_XUSB_FALCON_SRC>,
+<_car TEGRA124_CLK_XUSB_SS>,
+<_car TEGRA124_CLK_XUSB_SS_DIV2>,
+<_car TEGRA124_CLK_XUSB_SS_SRC>,
+<_car TEGRA124_CLK_XUSB_HS_SRC>,
+<_car TEGRA124_CLK_XUSB_FS_SRC>,
+<_car TEGRA124_CLK_PLL_U_480M>,
+<_car TEGRA124_CLK_CLK_M>,
+<_car TEGRA124_CLK_PLL_E>;
+   clock-names = "xusb_host", "xusb_host_src", "xusb_dev",
+ "xusb_dev_src", "xusb_falcon_src", "xusb_ss",
+ "xusb_ss_div2", "xusb_ss_src", "xusb_hs_src",
+ "xusb_fs_src", "pll_u_480m", "clk_m", "pll_e";
+   resets = <_car 89>, <_car 95>, <_car 156>,
+<_car 143>;
+   reset-names = "xusb_host", "xusb_dev", "xusb_ss", "xusb";
+   mboxes = <_mbox>;
+   mbox-names = "xusb";
+   phys = < TEGRA_XUSB_PADCTL_UTMI_P1>, /* mini-PCIe USB */
+  < TEGRA_XUSB_PADCTL_UTMI_P2>, /* USB A */
+  < TEGRA_XUSB_PADCTL_USB3_P0>; /* USB A */
+   phy-names = 

[PATCH v3 7/9] ARM: tegra: Add Tegra124 XUSB mailbox and xHCI controller

[Andrew Bresticker]

Add nodes for the Tegra XUSB mailbox and Tegra xHCI controller and
add the PHY mailbox channel to the XUSB padctl node.

Signed-off-by: Andrew Bresticker 
---
Changes from v2:
 - Dropped channel specifier from mailbox bindings.
 - Added mbox-names properties.
Changes from v1:
 - Updated to use common mailbox bindings.
 - Added remaining clocks/resets.
---
 arch/arm/boot/dts/tegra124.dtsi | 41 +
 1 file changed, 41 insertions(+)

diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index 03916ef..89afd45 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -495,11 +495,52 @@
status = "disabled";
};
 
+   usb@0,7009 {
+   compatible = "nvidia,tegra124-xhci";
+   reg = <0x0 0x7009 0x0 0x8000>,
+ <0x0 0x70098000 0x0 0x1000>,
+ <0x0 0x70099000 0x0 0x1000>;
+   interrupts = ;
+   clocks = <_car TEGRA124_CLK_XUSB_HOST>,
+<_car TEGRA124_CLK_XUSB_HOST_SRC>,
+<_car TEGRA124_CLK_XUSB_DEV>,
+<_car TEGRA124_CLK_XUSB_DEV_SRC>,
+<_car TEGRA124_CLK_XUSB_FALCON_SRC>,
+<_car TEGRA124_CLK_XUSB_SS>,
+<_car TEGRA124_CLK_XUSB_SS_DIV2>,
+<_car TEGRA124_CLK_XUSB_SS_SRC>,
+<_car TEGRA124_CLK_XUSB_HS_SRC>,
+<_car TEGRA124_CLK_XUSB_FS_SRC>,
+<_car TEGRA124_CLK_PLL_U_480M>,
+<_car TEGRA124_CLK_CLK_M>,
+<_car TEGRA124_CLK_PLL_E>;
+   clock-names = "xusb_host", "xusb_host_src", "xusb_dev",
+ "xusb_dev_src", "xusb_falcon_src", "xusb_ss",
+ "xusb_ss_div2", "xusb_ss_src", "xusb_hs_src",
+ "xusb_fs_src", "pll_u_480m", "clk_m", "pll_e";
+   resets = <_car 89>, <_car 95>, <_car 156>,
+<_car 143>;
+   reset-names = "xusb_host", "xusb_dev", "xusb_ss", "xusb";
+   mboxes = <_mbox>;
+   mbox-names = "xusb";
+   status = "disabled";
+   };
+
+   xusb_mbox: mailbox@0,70098000 {
+   compatible = "nvidia,tegra124-xusb-mbox";
+   reg = <0x0 0x70098000 0x0 0x1000>;
+   interrupts = ;
+
+   #mbox-cells = <0>;
+   };
+
padctl: padctl@0,7009f000 {
compatible = "nvidia,tegra124-xusb-padctl";
reg = <0x0 0x7009f000 0x0 0x1000>;
resets = <_car 142>;
reset-names = "padctl";
+   mboxes = <_mbox>;
+   mbox-names = "xusb";
 
#phy-cells = <1>;
};
-- 
2.1.0.rc2.206.gedb03e5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 6/9] usb: xhci: Add NVIDIA Tegra xHCI host-controller driver

[Andrew Bresticker]

Add support for the on-chip xHCI host controller present on Tegra SoCs.

The driver is currently very basic: it loads the controller with its
firmware, starts the controller, and is able to service messages sent
by the controller's firmware.  The hardware also supports device mode
as well as powergating of the SuperSpeed and host-controller logic
when not in use, but support for these is not yet implemented.

Based on work by:
  Ajay Gupta 
  Bharath Yadav 

Signed-off-by: Andrew Bresticker 
---
Changes from v2:
 - Added filtering out of non-host mailbox messages.
 - Removed MODULE_ALIAS.
Changes from v1:
 - Updated to use common mailbox API.
 - Fixed up so that the driver can be built and used as a module.
 - Incorporated review feedback from Stephen.
 - Misc. cleanups.
---
 drivers/usb/host/Kconfig  |   9 +
 drivers/usb/host/Makefile |   1 +
 drivers/usb/host/xhci-tegra.c | 905 ++
 3 files changed, 915 insertions(+)
 create mode 100644 drivers/usb/host/xhci-tegra.c

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index f5a5831..1fffbed 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -50,6 +50,15 @@ config USB_XHCI_RCAR
  Say 'Y' to enable the support for the xHCI host controller
  found in Renesas R-Car ARM SoCs.
 
+config USB_XHCI_TEGRA
+   tristate "NVIDIA Tegra XHCI support"
+   depends on ARCH_TEGRA
+   select MAILBOX
+   select FW_LOADER
+   ---help---
+ Say 'Y' to enable the support for the xHCI host controller
+ found in NVIDIA Tegra124 and later SoCs.
+
 endif # USB_XHCI_HCD
 
 config USB_EHCI_HCD
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 702d9b7..0a30e26 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_PCI) += pci-quirks.o
 
 obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
 obj-$(CONFIG_USB_XHCI_PLATFORM) += xhci-plat-hcd.o
+obj-$(CONFIG_USB_XHCI_TEGRA)   += xhci-tegra.o
 
 obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o
 obj-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o
diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
new file mode 100644
index 000..71dd6f4
--- /dev/null
+++ b/drivers/usb/host/xhci-tegra.c
@@ -0,0 +1,905 @@
+/*
+ * NVIDIA Tegra xHCI host controller driver
+ *
+ * Copyright (C) 2014 NVIDIA Corporation
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "xhci.h"
+
+#define TEGRA_XHCI_SS_CLK_HIGH_SPEED 12000
+#define TEGRA_XHCI_SS_CLK_LOW_SPEED 1200
+
+/* FPCI CFG registers */
+#define XUSB_CFG_1 0x004
+#define  XUSB_IO_SPACE_EN  BIT(0)
+#define  XUSB_MEM_SPACE_EN BIT(1)
+#define  XUSB_BUS_MASTER_ENBIT(2)
+#define XUSB_CFG_4 0x010
+#define  XUSB_BASE_ADDR_SHIFT  15
+#define  XUSB_BASE_ADDR_MASK   0x1
+#define XUSB_CFG_ARU_C11_CSBRANGE  0x41c
+#define XUSB_CFG_CSB_BASE_ADDR 0x800
+
+/* IPFS registers */
+#define IPFS_XUSB_HOST_CONFIGURATION_0 0x180
+#define  IPFS_EN_FPCI  BIT(0)
+#define IPFS_XUSB_HOST_INTR_MASK_0 0x188
+#define  IPFS_IP_INT_MASK  BIT(16)
+#define IPFS_XUSB_HOST_CLKGATE_HYSTERESIS_00x1bc
+
+#define CSB_PAGE_SELECT_MASK   0x7f
+#define CSB_PAGE_SELECT_SHIFT  9
+#define CSB_PAGE_OFFSET_MASK   0x1ff
+#define CSB_PAGE_SELECT(addr)  ((addr) >> (CSB_PAGE_SELECT_SHIFT) &\
+CSB_PAGE_SELECT_MASK)
+#define CSB_PAGE_OFFSET(addr)  ((addr) & CSB_PAGE_OFFSET_MASK)
+
+/* Falcon CSB registers */
+#define XUSB_FALC_CPUCTL   0x100
+#define  CPUCTL_STARTCPU   BIT(1)
+#define  CPUCTL_STATE_HALTED   BIT(4)
+#define XUSB_FALC_BOOTVEC  0x104
+#define XUSB_FALC_DMACTL   0x10c
+#define XUSB_FALC_IMFILLRNG1   0x154
+#define  IMFILLRNG1_TAG_MASK   0x
+#define  IMFILLRNG1_TAG_LO_SHIFT   0
+#define  IMFILLRNG1_TAG_HI_SHIFT   16
+#define XUSB_FALC_IMFILLCTL0x158
+
+/* MP CSB registers */
+#define XUSB_CSB_MP_ILOAD_ATTR 0x101a00
+#define XUSB_CSB_MP_ILOAD_BASE_LO  0x101a04
+#define XUSB_CSB_MP_ILOAD_BASE_HI  0x101a08
+#define XUSB_CSB_MP_L2IMEMOP_SIZE  0x101a10
+#define  

Re: [PATCH v11 06/19] irqchip: gic: Provide support for interrupt grouping

[Catalin Marinas]

On 2 Sep 2014, at 20:33, Russell King - ARM Linux  
wrote:
> On Tue, Sep 02, 2014 at 02:00:40PM +0100, Daniel Thompson wrote:
>> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
>> index 4b959e6..423707c 100644
>> --- a/drivers/irqchip/irq-gic.c
>> +++ b/drivers/irqchip/irq-gic.c
>> @@ -41,6 +41,9 @@
>> #include 
>> 
>> #include 
>> +#ifdef CONFIG_FIQ
>> +#include 
>> +#endif
> 
> Is there much advantage to this ifdef over providing a dummy asm/fiq.h
> in ARM64?

While it’s unlikely we’ll use FIQs on arm64 (they are generally
reserved for the secure world/firmware), I don’t mind an empty
asm/fiq.h file.

Catalin--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 0/9] Tegra xHCI support

[Andrew Bresticker]

This series adds support for xHCI on NVIDIA Tegra SoCs.  This includes:
 - patches 1 and 2: adding a driver for the mailbox used to communicate
   with the xHCI controller's firmware,
 - patches 3 and 4: extending the XUSB pad controller driver to support
   the USB PHY types (UTMI, HSIC, and USB3),
 - patches 5 and 6: adding a xHCI host-controller driver, and
 - patches 7, 8, and 9: updating the relevant DT files.

The PHY and host drivers have compile-time dependencies on the mailbox
driver, and the host driver has compile-time dependencies on the PHY
driver.  It is probably best if these all get merged through the Tegra
tree.

Based on 3.17-rc3, Jassi Brar's common mailbox framework [0], and my
xHCI modules series [1].

Tested on Venice2, Jetson TK1, and Big with a variety of USB2.0 and
USB3.0 memory sticks and ethernet dongles using controller firmware
recently posted by Andrew Chew [2].

Notes:
 - HSIC support is mostly untested and I think there are still some issues
   to work out there.  I do have a Tegra124 board with a HSIC hub so I'll
   try to sort those out later.
 - The XUSB padctl driver doesn't play nice with the existing Tegra USB2.0
   PHY driver, so all ports should be assigned to the XHCI controller.

Based on work by:
  a lot of people, but from what I can tell from the L4T tree [3], the
  original authors of the Tegra xHCI driver are:
Ajay Gupta 
Bharath Yadav 

Chagnes from v2:
 - Dropped mailbox channel specifier.  The mailbox driver allocates virtual
   channels backed by the single physical channel.
 - Added support for HS_CURR_LEVEL adjustment pinconfig property, which
   will be required for the Blaze board.
 - Addressed Stephen's review comments.

Changes from v1:
 - Converted mailbox driver to use the common mailbox framework.
 - Fixed up host driver so that it can now be built and used as a module.
 - Addressed Stephen's review comments.
 - Misc. cleanups.

Changes from RFC:
 - Dropped Tegra114 support.
 - Split out mailbox into separate driver.
 - Stopped using child xhci-plat device in xHCI host-controller driver.
 - Added PHY support to Thierry's XUSB padctl driver instead of in a separate
   USB PHY driver.
 - Added Jetson TK1 support.
 - Misc. cleanups.

[0] https://lkml.org/lkml/2014/8/1/200
[1] https://lkml.org/lkml/2014/8/18/504
[2] https://patchwork.ozlabs.org/patch/384013/
[3] git://nv-tegra.nvidia.com/linux-3.10.git

Andrew Bresticker (9):
  of: Add NVIDIA Tegra XUSB mailbox binding
  mailbox: Add NVIDIA Tegra XUSB mailbox driver
  of: Update Tegra XUSB pad controller binding for USB
  pinctrl: tegra-xusb: Add USB PHY support
  of: Add NVIDIA Tegra xHCI controller binding
  usb: xhci: Add NVIDIA Tegra xHCI host-controller driver
  ARM: tegra: Add Tegra124 XUSB mailbox and xHCI controller
  ARM: tegra: jetson-tk1: Add xHCI support
  ARM: tegra: venice2: Add xHCI support

 .../bindings/mailbox/nvidia,tegra124-xusb-mbox.txt |   32 +
 .../pinctrl/nvidia,tegra124-xusb-padctl.txt|   56 +-
 .../bindings/usb/nvidia,tegra124-xhci.txt  |  104 ++
 arch/arm/boot/dts/tegra124-jetson-tk1.dts  |   48 +-
 arch/arm/boot/dts/tegra124-venice2.dts |   79 +-
 arch/arm/boot/dts/tegra124.dtsi|   41 +
 drivers/mailbox/Kconfig|3 +
 drivers/mailbox/Makefile   |2 +
 drivers/mailbox/tegra-xusb-mailbox.c   |  290 +
 drivers/pinctrl/Kconfig|1 +
 drivers/pinctrl/pinctrl-tegra-xusb.c   | 1233 +++-
 drivers/usb/host/Kconfig   |9 +
 drivers/usb/host/Makefile  |1 +
 drivers/usb/host/xhci-tegra.c  |  905 ++
 include/dt-bindings/pinctrl/pinctrl-tegra-xusb.h   |   20 +
 include/soc/tegra/xusb.h   |   53 +
 16 files changed, 2796 insertions(+), 81 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt
 create mode 100644 
Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt
 create mode 100644 drivers/mailbox/tegra-xusb-mailbox.c
 create mode 100644 drivers/usb/host/xhci-tegra.c
 create mode 100644 include/soc/tegra/xusb.h

-- 
2.1.0.rc2.206.gedb03e5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next v2] net: bpf: make eBPF interpreter images read-only

[Hannes Frederic Sowa]

On Tue, Sep 2, 2014, at 23:31, Alexei Starovoitov wrote:
> On Tue, Sep 2, 2014 at 1:53 PM, Hannes Frederic Sowa
>  wrote:
> > From: Daniel Borkmann 
> >
> > With eBPF getting more extended and exposure to user space is on it's way,
> > hardening the memory range the interpreter uses to steer its command flow
> > seems appropriate.  This patch moves the to be interpreted bytecode to
> > read-only pages.
> ...
> >  11 files changed, 144 insertions(+), 32 deletions(-)
> 
> nice. quite short.
> 
> > +#ifdef CONFIG_DEBUG_SET_MODULE_RONX
> > +static inline void bpf_prog_lock_ro(struct bpf_prog *fp)
> > +{
> > +   set_memory_ro((unsigned long)fp, fp->pages);
> 
> since ronx are ifdef checked together,
> would probably make sense to set nx too?

NX bit is already set, because we didn't request page with
PAGE_KERNEL_EXEC.

E.g. in kernel_page_tables:
0xc9a94000-0xc9a96000   8K ro
GLB NX pte

> > +static inline void bpf_prog_unlock_ro(struct bpf_prog *fp)
> > +{
> > +   set_memory_rw((unsigned long)fp, fp->pages);
> 
> why rw is needed?
> since fp is allocated with vmalloc, vfree doesn't need
> to touch the pages to free them, no?

We will check that. It basically was copied from jit hardening code.
Maybe we can omit the call.

Thanks,
Hannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 1/9] of: Add NVIDIA Tegra XUSB mailbox binding

[Andrew Bresticker]

Add device-tree bindings for the Tegra XUSB mailbox which will be used
for communication between the Tegra xHCI controller's firmware and the
host processor.

Signed-off-by: Andrew Bresticker 
---
Changes from v2:
 - Dropped channel specifier.
 - Added pointer to mailbox documentation.
Changes from v1:
 - Updated to use common mailbox bindings.
---
 .../bindings/mailbox/nvidia,tegra124-xusb-mbox.txt | 32 ++
 1 file changed, 32 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt

diff --git 
a/Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt 
b/Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt
new file mode 100644
index 000..b35ea6e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt
@@ -0,0 +1,32 @@
+NVIDIA Tegra XUSB mailbox
+=
+
+The Tegra XUSB mailbox is used by the Tegra xHCI controller's firmware to
+communicate requests to the host and PHY drivers.
+
+Refer to ./mailbox.txt for generic information about mailbox device-tree
+bindings.
+
+Required properties:
+
+ - compatible: Should be "nvidia,tegra124-xusb-mbox".
+ - reg: Address and length of the XUSB FPCI registers.
+ - interrupts: XUSB mailbox interrupt.
+ - #mbox-cells: Should be 0.  There is only one physical channel.
+
+Example:
+
+   xusb_mbox: mailbox@0,70098000 {
+   compatible = "nvidia,tegra124-xusb-mbox";
+   reg = <0x0 0x70098000 0x0 0x1000>;
+   interrupts = ;
+
+   #mbox-cells = <0>;
+   };
+
+   usb@0,7009 {
+   ...
+   mboxes = <_mbox>;
+   mbox-names = "xusb";
+   ...
+   };
-- 
2.1.0.rc2.206.gedb03e5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 9/9] ARM: tegra: venice2: Add xHCI support

[Andrew Bresticker]

Assign ports previously owned by the EHCI controllers to the xHCI
controller.  There are two external USB ports (UTMI ports 0/2 and
USB3 ports 0/1) and an internal USB port (UTMI port 1).  PCIe lanes
0 and 1 are used by the USB3 ports.

Signed-off-by: Andrew Bresticker 
---
Changes from v2:
 - Updated VBUS power supply names.
Changes from v1:
 - Updated USB power supplies.
---
 arch/arm/boot/dts/tegra124-venice2.dts | 79 ++
 1 file changed, 51 insertions(+), 28 deletions(-)

diff --git a/arch/arm/boot/dts/tegra124-venice2.dts 
b/arch/arm/boot/dts/tegra124-venice2.dts
index 70ad91d..1cc3be2 100644
--- a/arch/arm/boot/dts/tegra124-venice2.dts
+++ b/arch/arm/boot/dts/tegra124-venice2.dts
@@ -736,7 +736,7 @@
regulator-always-on;
};
 
-   ldo0 {
+   avdd_1v05_run: ldo0 {
regulator-name = "+1.05V_RUN_AVDD";
regulator-min-microvolt = <105>;
regulator-max-microvolt = <105>;
@@ -878,6 +878,56 @@
status = "okay";
};
 
+   usb@0,7009 {
+   status = "okay";
+   phys = < TEGRA_XUSB_PADCTL_UTMI_P0>, /* 1st USB A */
+  < TEGRA_XUSB_PADCTL_UTMI_P1>, /* Internal USB */
+  < TEGRA_XUSB_PADCTL_UTMI_P2>, /* 2nd USB A */
+  < TEGRA_XUSB_PADCTL_USB3_P0>, /* 1st USB A */
+  < TEGRA_XUSB_PADCTL_USB3_P1>; /* 2nd USB A */
+   phy-names = "utmi-0", "utmi-1", "utmi-2", "usb3-0", "usb3-1";
+   avddio-pex-supply = <_1v05_run>;
+   dvddio-pex-supply = <_1v05_run>;
+   avdd-usb-supply = <_3v3_lp0>;
+   avdd-pll-utmip-supply = <_1v8>;
+   avdd-pll-erefe-supply = <_1v05_run>;
+   avdd-pex-pll-supply = <_1v05_run>;
+   hvdd-pex-supply = <_3v3_lp0>;
+   hvdd-pex-plle-supply = <_3v3_lp0>;
+   };
+
+   padctl@0,7009f000 {
+   pinctrl-0 = <_default>;
+   pinctrl-names = "default";
+
+   vbus-0-supply = <_usb1_vbus>;
+   vbus-1-supply = <_run_cam>;
+   vbus-2-supply = <_usb3_vbus>;
+   nvidia,usb3-port-0-lane = ;
+   nvidia,usb3-port-1-lane = ;
+
+   padctl_default: pinmux {
+   otg {
+   nvidia,lanes = "otg-0", "otg-1", "otg-2";
+   nvidia,function = "xusb";
+   };
+
+   usb3p0 {
+   nvidia,lanes = "pcie-0";
+   nvidia,function = "usb3";
+   nvidia,iddq = <0>;
+   nvidia,usb2-port-num = <0>;
+   };
+
+   usb3p1 {
+   nvidia,lanes = "pcie-1";
+   nvidia,function = "usb3";
+   nvidia,iddq = <0>;
+   nvidia,usb2-port-num = <2>;
+   };
+   };
+   };
+
sdhci@0,700b0400 {
cd-gpios = < TEGRA_GPIO(V, 2) GPIO_ACTIVE_HIGH>;
power-gpios = < TEGRA_GPIO(R, 0) GPIO_ACTIVE_HIGH>;
@@ -898,33 +948,6 @@
};
};
 
-   usb@0,7d00 {
-   status = "okay";
-   };
-
-   usb-phy@0,7d00 {
-   status = "okay";
-   vbus-supply = <_usb1_vbus>;
-   };
-
-   usb@0,7d004000 {
-   status = "okay";
-   };
-
-   usb-phy@0,7d004000 {
-   status = "okay";
-   vbus-supply = <_run_cam>;
-   };
-
-   usb@0,7d008000 {
-   status = "okay";
-   };
-
-   usb-phy@0,7d008000 {
-   status = "okay";
-   vbus-supply = <_usb3_vbus>;
-   };
-
backlight: backlight {
compatible = "pwm-backlight";
 
-- 
2.1.0.rc2.206.gedb03e5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ACPICA: ACPI 5.1: Add support for runtime validation of _DSD package.

[Rafael J. Wysocki]

On Friday, August 29, 2014 09:32:42 AM Lv Zheng wrote:
> From: Mika Westerberg 
> 
> Adds ACPICA kernel runtime support to validate contents/format
> of the _DSD package, similar to the iASL support. Ported by
> Mika Westerberg.
> 
> Signed-off-by: Mika Westerberg 
> Signed-off-by: Bob Moore 
> Signed-off-by: Lv Zheng 

Queued up for 3.17-rc4, thanks!

> ---
>  drivers/acpi/acpica/nsprepkg.c |   39 +++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/drivers/acpi/acpica/nsprepkg.c b/drivers/acpi/acpica/nsprepkg.c
> index 68f7258..1b13b92 100644
> --- a/drivers/acpi/acpica/nsprepkg.c
> +++ b/drivers/acpi/acpica/nsprepkg.c
> @@ -316,6 +316,45 @@ acpi_ns_check_package(struct acpi_evaluate_info *info,
>   acpi_ns_check_package_list(info, package, elements, count);
>   break;
>  
> + case ACPI_PTYPE2_UUID_PAIR:
> +
> + /* The package must contain pairs of (UUID + type) */
> +
> + if (count & 1) {
> + expected_count = count + 1;
> + goto package_too_small;
> + }
> +
> + while (count > 0) {
> + status = acpi_ns_check_object_type(info, elements,
> +package->ret_info.
> +object_type1, 0);
> + if (ACPI_FAILURE(status)) {
> + return (status);
> + }
> +
> + /* Validate length of the UUID buffer */
> +
> + if ((*elements)->buffer.length != 16) {
> + ACPI_WARN_PREDEFINED((AE_INFO,
> +   info->full_pathname,
> +   info->node_flags,
> +   "Invalid length for UUID 
> Buffer"));
> + return (AE_AML_OPERAND_VALUE);
> + }
> +
> + status = acpi_ns_check_object_type(info, elements + 1,
> +package->ret_info.
> +object_type2, 0);
> + if (ACPI_FAILURE(status)) {
> + return (status);
> + }
> +
> + elements += 2;
> + count -= 2;
> + }
> + break;
> +
>   default:
>  
>   /* Should not get here if predefined info table is correct */
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ACPI/EC: Add msi quirk for Clevo W350etq

[Rafael J. Wysocki]

On Friday, August 29, 2014 10:50:08 AM Lan Tianyu wrote:
> Clevo W350etq's EC will not produce GPE interrupt some time after
> booting. The ACPI notify event won't trigger when the issue takes
> place. After debugging, adding msi quirk for the machine can fix
> the issue. This patch is to add msi quirk for the machine.
> 
> Reference: https://bugzilla.kernel.org/show_bug.cgi?id=77431
> Reported-and-tested-by: qba...@gmail.com
> Signed-off-by: Lan Tianyu 

Queued up for 3.17-rc4, thanks!

> ---
>  drivers/acpi/ec.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
> index a66ab65..d8535b3 100644
> --- a/drivers/acpi/ec.c
> +++ b/drivers/acpi/ec.c
> @@ -1015,6 +1015,10 @@ static struct dmi_system_id ec_dmi_table[] __initdata 
> = {
>   DMI_MATCH(DMI_SYS_VENDOR, "Quanta"),
>   DMI_MATCH(DMI_PRODUCT_NAME, "TW9/SW9"),}, NULL},
>   {
> + ec_flag_msi, "Clevo W350etq", {
> + DMI_MATCH(DMI_SYS_VENDOR, "CLEVO CO."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "W35_37ET"),}, NULL},
> + {
>   ec_validate_ecdt, "ASUS hardware", {
>   DMI_MATCH(DMI_BIOS_VENDOR, "ASUS") }, NULL},
>   {
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next v2] net: bpf: make eBPF interpreter images read-only

[Alexei Starovoitov]

On Tue, Sep 2, 2014 at 1:53 PM, Hannes Frederic Sowa
 wrote:
> From: Daniel Borkmann 
>
> With eBPF getting more extended and exposure to user space is on it's way,
> hardening the memory range the interpreter uses to steer its command flow
> seems appropriate.  This patch moves the to be interpreted bytecode to
> read-only pages.
...
>  11 files changed, 144 insertions(+), 32 deletions(-)

nice. quite short.

> +#ifdef CONFIG_DEBUG_SET_MODULE_RONX
> +static inline void bpf_prog_lock_ro(struct bpf_prog *fp)
> +{
> +   set_memory_ro((unsigned long)fp, fp->pages);

since ronx are ifdef checked together,
would probably make sense to set nx too?

> +static inline void bpf_prog_unlock_ro(struct bpf_prog *fp)
> +{
> +   set_memory_rw((unsigned long)fp, fp->pages);

why rw is needed?
since fp is allocated with vmalloc, vfree doesn't need
to touch the pages to free them, no?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Revert "leds: convert blink timer to workqueue"

[Jiri Kosina]

On Tue, 2 Sep 2014, Bryan Wu wrote:

> On Tue, Sep 2, 2014 at 2:03 AM, Jiri Kosina  wrote:
> > This reverts commit 8b37e1bef5a6b60e949e28a4db3006e4b00bd758.
> >
> > It's broken as it changes led_blink_set() in a way that it can now sleep
> > (while synchronously waiting for workqueue to be cancelled). That's a
> > problem, because it's possible that this function gets called from atomic
> > context (tpt_trig_timer() takes a readlock and thus disables preemption).
> >
> > This has been brought up 3 weeks ago already [1] but no proper fix has
> > materialized, and I keep seeing the problem since 3.18-rc1.
> 
> Is this 3.18-rc1? I think it should be 3.17-rc1, right?

Indeed, brainfart on my side, thanks for noticing.

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/9] Documentation: devicetree: Add binding for Synopsys DDR controller

[Soren Brinkmann]

Signed-off-by: Soren Brinkmann 
---
 .../devicetree/bindings/memory-controllers/synopsys.txt   | 11 +++
 1 file changed, 11 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/memory-controllers/synopsys.txt

diff --git a/Documentation/devicetree/bindings/memory-controllers/synopsys.txt 
b/Documentation/devicetree/bindings/memory-controllers/synopsys.txt
new file mode 100644
index ..f9c6454146b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/synopsys.txt
@@ -0,0 +1,11 @@
+Binding for Synopsys IntelliDDR Multi Protocol Memory Controller
+
+Required properties:
+ - compatible: Should be 'xlnx,zynq-ddrc-a05'
+ - reg: Base address and size of the controllers memory area
+
+Example:
+   memory-controller@f8006000 {
+   compatible = "xlnx,zynq-ddrc-a05";
+   reg = <0xf8006000 0x1000>;
+   };
-- 
2.1.0.1.g27b9230

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/9] Zynq PM updates

[Soren Brinkmann]

Hi all,

here is v2 of this series. It's mostly the same and most changes are
related to reformatting comments. The only functional change is in 'ARM:
zynq: PM: Enable DDR clock stop' which does no longer enable
self-refresh too. It seems self-refresh is inflicting a non-negligible
amount of latency that degrades memory performance if enabled throughout
the whole run time.

Thanks,
Sören

Daniel Lezcano (2):
  ARM: zynq: Remove invalidate cache for cpu die
  ARM: zynq: cpuidle: Remove pointless code

Soren Brinkmann (7):
  ARM: zynq: PM: Enable A9 internal clock gating feature
  Documentation: devicetree: Add binding for Synopsys DDR controller
  ARM: zynq: DT: Add DDRC node
  ARM: zynq: PM: Enable DDR clock stop
  ARM: zynq: Synchronise zynq_cpu_die/kill
  ARM: zynq: Remove hotplug.c
  ARM: zynq: Rename 'zynq_platform_cpu_die'

 .../bindings/memory-controllers/synopsys.txt   | 11 +++
 arch/arm/boot/dts/zynq-7000.dtsi   |  5 ++
 arch/arm/mach-zynq/Makefile|  3 +-
 arch/arm/mach-zynq/common.c|  7 ++
 arch/arm/mach-zynq/common.h| 16 -
 arch/arm/mach-zynq/hotplug.c   | 47 +---
 arch/arm/mach-zynq/platsmp.c   | 41 ++-
 arch/arm/mach-zynq/pm.c| 83 ++
 arch/arm/mach-zynq/slcr.c  | 43 ++-
 drivers/cpuidle/cpuidle-zynq.c | 10 +--
 10 files changed, 205 insertions(+), 61 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/memory-controllers/synopsys.txt
 create mode 100644 arch/arm/mach-zynq/pm.c

-- 
2.1.0.1.g27b9230

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 3/9] ARM: zynq: DT: Add DDRC node

[Soren Brinkmann]

Add the DDR controller to the Zynq devicetree.

Signed-off-by: Soren Brinkmann 
---
 arch/arm/boot/dts/zynq-7000.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index 6cc83d4c6c76..587cadcf7001 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -146,6 +146,11 @@
cache-level = <2>;
};
 
+   memory-controller@f8006000 {
+   compatible = "xlnx,zynq-ddrc-a05";
+   reg = <0xf8006000 0x1000>;
+   } ;
+
uart0: serial@e000 {
compatible = "xlnx,xuartps", "cdns,uart-r1p8";
status = "disabled";
-- 
2.1.0.1.g27b9230

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/9] ARM: zynq: PM: Enable A9 internal clock gating feature

[Soren Brinkmann]

Signed-off-by: Soren Brinkmann 
---
v2:
 - make comments comply to kernel-doc format
---
 arch/arm/mach-zynq/common.c  |  6 ++
 arch/arm/mach-zynq/common.h  | 11 +++
 arch/arm/mach-zynq/platsmp.c | 13 +
 3 files changed, 30 insertions(+)

diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index 31a6fa40ba37..3cb7c198615a 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -98,6 +98,11 @@ static int __init zynq_get_revision(void)
return revision;
 }
 
+static void __init zynq_init_late(void)
+{
+   zynq_core_pm_init();
+}
+
 /**
  * zynq_init_machine - System specific initialization, intended to be
  *called from board specific initialization.
@@ -204,6 +209,7 @@ DT_MACHINE_START(XILINX_EP107, "Xilinx Zynq Platform")
.map_io = zynq_map_io,
.init_irq   = zynq_irq_init,
.init_machine   = zynq_init_machine,
+   .init_late  = zynq_init_late,
.init_time  = zynq_timer_init,
.dt_compat  = zynq_dt_match,
.reserve= zynq_memory_init,
diff --git a/arch/arm/mach-zynq/common.h b/arch/arm/mach-zynq/common.h
index f652f0a884a6..596ef0b5067c 100644
--- a/arch/arm/mach-zynq/common.h
+++ b/arch/arm/mach-zynq/common.h
@@ -40,4 +40,15 @@ extern void __iomem *zynq_scu_base;
 /* Hotplug */
 extern void zynq_platform_cpu_die(unsigned int cpu);
 
+static inline void zynq_core_pm_init(void)
+{
+   /* A9 clock gating */
+   asm volatile ("mrc  p15, 0, r12, c15, c0, 0\n"
+ "orr  r12, r12, #1\n"
+ "mcr  p15, 0, r12, c15, c0, 0\n"
+ : /* no outputs */
+ : /* no inputs */
+ : "r12");
+}
+
 #endif
diff --git a/arch/arm/mach-zynq/platsmp.c b/arch/arm/mach-zynq/platsmp.c
index abc82ef085c1..6c7843108c7f 100644
--- a/arch/arm/mach-zynq/platsmp.c
+++ b/arch/arm/mach-zynq/platsmp.c
@@ -112,6 +112,18 @@ static void __init zynq_smp_prepare_cpus(unsigned int 
max_cpus)
scu_enable(zynq_scu_base);
 }
 
+/**
+ * zynq_secondary_init - Initialize secondary CPU cores
+ * @cpu:   CPU that is initialized
+ *
+ * This function is in the hotplug path. Don't move it into the
+ * init section!!
+ */
+static void zynq_secondary_init(unsigned int cpu)
+{
+   zynq_core_pm_init();
+}
+
 #ifdef CONFIG_HOTPLUG_CPU
 static int zynq_cpu_kill(unsigned cpu)
 {
@@ -124,6 +136,7 @@ struct smp_operations zynq_smp_ops __initdata = {
.smp_init_cpus  = zynq_smp_init_cpus,
.smp_prepare_cpus   = zynq_smp_prepare_cpus,
.smp_boot_secondary = zynq_boot_secondary,
+   .smp_secondary_init = zynq_secondary_init,
 #ifdef CONFIG_HOTPLUG_CPU
.cpu_die= zynq_platform_cpu_die,
.cpu_kill   = zynq_cpu_kill,
-- 
2.1.0.1.g27b9230

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 5/9] ARM: zynq: Remove invalidate cache for cpu die

[Soren Brinkmann]

From: Daniel Lezcano 

As there is no Power management unit on this board, it is not possible to power
down a core, just WFI is allowed. There is no point to invalidate the cache and
exit coherency.

Signed-off-by: Daniel Lezcano 
Reviewed-and-tested-by: Soren Brinkmann 
---
 arch/arm/mach-zynq/hotplug.c | 32 +---
 1 file changed, 1 insertion(+), 31 deletions(-)

diff --git a/arch/arm/mach-zynq/hotplug.c b/arch/arm/mach-zynq/hotplug.c
index 5052c70326e4..366f46c91365 100644
--- a/arch/arm/mach-zynq/hotplug.c
+++ b/arch/arm/mach-zynq/hotplug.c
@@ -10,35 +10,7 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
-#include 
-#include 
-#include 
-
-#include 
-#include 
-#include "common.h"
-
-static inline void zynq_cpu_enter_lowpower(void)
-{
-   unsigned int v;
-
-   flush_cache_all();
-   asm volatile(
-   "   mcr p15, 0, %1, c7, c5, 0\n"
-   "   dsb\n"
-   /*
-* Turn off coherency
-*/
-   "   mrc p15, 0, %0, c1, c0, 1\n"
-   "   bic %0, %0, #0x40\n"
-   "   mcr p15, 0, %0, c1, c0, 1\n"
-   "   mrc p15, 0, %0, c1, c0, 0\n"
-   "   bic %0, %0, %2\n"
-   "   mcr p15, 0, %0, c1, c0, 0\n"
- : "=" (v)
- : "r" (0), "Ir" (CR_C)
- : "cc");
-}
+#include 
 
 /*
  * platform-specific code to shutdown a CPU
@@ -47,8 +19,6 @@ static inline void zynq_cpu_enter_lowpower(void)
  */
 void zynq_platform_cpu_die(unsigned int cpu)
 {
-   zynq_cpu_enter_lowpower();
-
/*
 * there is no power-control hardware on this platform, so all
 * we can do is put the core into WFI; this is safe as the calling
-- 
2.1.0.1.g27b9230

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 6/9] ARM: zynq: cpuidle: Remove pointless code

[Soren Brinkmann]

From: Daniel Lezcano 

The core is not powered down, it is pointless to call the cpu_pm notifiers and
switch to the global timer.

Signed-off-by: Daniel Lezcano 
Reviewed-and-tested-by: Soren Brinkmann 
---
 drivers/cpuidle/cpuidle-zynq.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/cpuidle/cpuidle-zynq.c b/drivers/cpuidle/cpuidle-zynq.c
index aded75928028..c61b8b2a7c77 100644
--- a/drivers/cpuidle/cpuidle-zynq.c
+++ b/drivers/cpuidle/cpuidle-zynq.c
@@ -26,7 +26,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -38,15 +37,9 @@
 static int zynq_enter_idle(struct cpuidle_device *dev,
   struct cpuidle_driver *drv, int index)
 {
-   /* Devices must be stopped here */
-   cpu_pm_enter();
-
/* Add code for DDR self refresh start */
cpu_do_idle();
 
-   /* Add code for DDR self refresh stop */
-   cpu_pm_exit();
-
return index;
 }
 
@@ -59,8 +52,7 @@ static struct cpuidle_driver zynq_idle_driver = {
.enter  = zynq_enter_idle,
.exit_latency   = 10,
.target_residency   = 1,
-   .flags  = CPUIDLE_FLAG_TIME_VALID |
- CPUIDLE_FLAG_TIMER_STOP,
+   .flags  = CPUIDLE_FLAG_TIME_VALID,
.name   = "RAM_SR",
.desc   = "WFI and RAM Self Refresh",
},
-- 
2.1.0.1.g27b9230

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 8/9] ARM: zynq: Remove hotplug.c

[Soren Brinkmann]

The hotplug code contains only a single function, which is an SMP
function. Move that to platsmp.c where all other SMP runctions reside.
That allows removing hotplug.c and declaring the cpu_die function
static.

Signed-off-by: Soren Brinkmann 
---
v2:
 - don't add function prototype a second time
---
 arch/arm/mach-zynq/Makefile  |  1 -
 arch/arm/mach-zynq/common.h  |  3 ---
 arch/arm/mach-zynq/hotplug.c | 17 -
 arch/arm/mach-zynq/platsmp.c | 18 ++
 4 files changed, 18 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-zynq/Makefile b/arch/arm/mach-zynq/Makefile
index 820dff6e1eba..c85fb3f7d5cd 100644
--- a/arch/arm/mach-zynq/Makefile
+++ b/arch/arm/mach-zynq/Makefile
@@ -6,5 +6,4 @@
 obj-y  := common.o slcr.o pm.o
 CFLAGS_REMOVE_hotplug.o=-march=armv6k
 CFLAGS_hotplug.o   =-Wa,-march=armv7-a -mcpu=cortex-a9
-obj-$(CONFIG_HOTPLUG_CPU)  += hotplug.o
 obj-$(CONFIG_SMP)  += headsmp.o platsmp.o
diff --git a/arch/arm/mach-zynq/common.h b/arch/arm/mach-zynq/common.h
index 24d6340d3fb6..2bc71273c73c 100644
--- a/arch/arm/mach-zynq/common.h
+++ b/arch/arm/mach-zynq/common.h
@@ -39,9 +39,6 @@ extern struct smp_operations zynq_smp_ops __initdata;
 
 extern void __iomem *zynq_scu_base;
 
-/* Hotplug */
-extern void zynq_platform_cpu_die(unsigned int cpu);
-
 void zynq_pm_late_init(void);
 
 static inline void zynq_core_pm_init(void)
diff --git a/arch/arm/mach-zynq/hotplug.c b/arch/arm/mach-zynq/hotplug.c
index fe44a05677e2..b685c89f11e4 100644
--- a/arch/arm/mach-zynq/hotplug.c
+++ b/arch/arm/mach-zynq/hotplug.c
@@ -12,20 +12,3 @@
  */
 #include 
 
-/*
- * platform-specific code to shutdown a CPU
- *
- * Called with IRQs disabled
- */
-void zynq_platform_cpu_die(unsigned int cpu)
-{
-   zynq_slcr_cpu_state_write(cpu, true);
-
-   /*
-* there is no power-control hardware on this platform, so all
-* we can do is put the core into WFI; this is safe as the calling
-* code will have already disabled interrupts
-*/
-   for (;;)
-   cpu_do_idle();
-}
diff --git a/arch/arm/mach-zynq/platsmp.c b/arch/arm/mach-zynq/platsmp.c
index 06415eeba7e6..f722b5a83a45 100644
--- a/arch/arm/mach-zynq/platsmp.c
+++ b/arch/arm/mach-zynq/platsmp.c
@@ -136,6 +136,24 @@ static int zynq_cpu_kill(unsigned cpu)
zynq_slcr_cpu_stop(cpu);
return 1;
 }
+
+/*
+ * platform-specific code to shutdown a CPU
+ *
+ * Called with IRQs disabled
+ */
+static void zynq_platform_cpu_die(unsigned int cpu)
+{
+   zynq_slcr_cpu_state_write(cpu, true);
+
+   /*
+* there is no power-control hardware on this platform, so all
+* we can do is put the core into WFI; this is safe as the calling
+* code will have already disabled interrupts
+*/
+   for (;;)
+   cpu_do_idle();
+}
 #endif
 
 struct smp_operations zynq_smp_ops __initdata = {
-- 
2.1.0.1.g27b9230

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 7/9] ARM: zynq: Synchronise zynq_cpu_die/kill

[Soren Brinkmann]

Avoid races and add synchronisation between the arch specific
kill and die routines.

The same synchronisation issue was fixed on IMX platform
by this commit:
"ARM: imx: fix sync issue between imx_cpu_die and imx_cpu_kill"
(sha1: 2f3edfd7e27ad4206acbc2ae99c9df5f46353024)

Signed-off-by: Soren Brinkmann 
Signed-off-by: Michal Simek 
---
 arch/arm/mach-zynq/common.h  |  2 ++
 arch/arm/mach-zynq/hotplug.c |  2 ++
 arch/arm/mach-zynq/platsmp.c |  6 ++
 arch/arm/mach-zynq/slcr.c| 43 ++-
 4 files changed, 52 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-zynq/common.h b/arch/arm/mach-zynq/common.h
index 0edbb6997b1c..24d6340d3fb6 100644
--- a/arch/arm/mach-zynq/common.h
+++ b/arch/arm/mach-zynq/common.h
@@ -24,6 +24,8 @@ extern int zynq_early_slcr_init(void);
 extern void zynq_slcr_system_reset(void);
 extern void zynq_slcr_cpu_stop(int cpu);
 extern void zynq_slcr_cpu_start(int cpu);
+extern bool zynq_slcr_cpu_state_read(int cpu);
+extern void zynq_slcr_cpu_state_write(int cpu, bool die);
 extern u32 zynq_slcr_get_device_id(void);
 
 #ifdef CONFIG_SMP
diff --git a/arch/arm/mach-zynq/hotplug.c b/arch/arm/mach-zynq/hotplug.c
index 366f46c91365..fe44a05677e2 100644
--- a/arch/arm/mach-zynq/hotplug.c
+++ b/arch/arm/mach-zynq/hotplug.c
@@ -19,6 +19,8 @@
  */
 void zynq_platform_cpu_die(unsigned int cpu)
 {
+   zynq_slcr_cpu_state_write(cpu, true);
+
/*
 * there is no power-control hardware on this platform, so all
 * we can do is put the core into WFI; this is safe as the calling
diff --git a/arch/arm/mach-zynq/platsmp.c b/arch/arm/mach-zynq/platsmp.c
index 6c7843108c7f..06415eeba7e6 100644
--- a/arch/arm/mach-zynq/platsmp.c
+++ b/arch/arm/mach-zynq/platsmp.c
@@ -127,6 +127,12 @@ static void zynq_secondary_init(unsigned int cpu)
 #ifdef CONFIG_HOTPLUG_CPU
 static int zynq_cpu_kill(unsigned cpu)
 {
+   unsigned long timeout = jiffies + msecs_to_jiffies(50);
+
+   while (zynq_slcr_cpu_state_read(cpu))
+   if (time_after(jiffies, timeout))
+   return 0;
+
zynq_slcr_cpu_stop(cpu);
return 1;
 }
diff --git a/arch/arm/mach-zynq/slcr.c b/arch/arm/mach-zynq/slcr.c
index c43a2d16e223..d4cb50cf97c0 100644
--- a/arch/arm/mach-zynq/slcr.c
+++ b/arch/arm/mach-zynq/slcr.c
@@ -138,6 +138,8 @@ void zynq_slcr_cpu_start(int cpu)
zynq_slcr_write(reg, SLCR_A9_CPU_RST_CTRL_OFFSET);
reg &= ~(SLCR_A9_CPU_CLKSTOP << cpu);
zynq_slcr_write(reg, SLCR_A9_CPU_RST_CTRL_OFFSET);
+
+   zynq_slcr_cpu_state_write(cpu, false);
 }
 
 /**
@@ -154,8 +156,47 @@ void zynq_slcr_cpu_stop(int cpu)
 }
 
 /**
- * zynq_slcr_init - Regular slcr driver init
+ * zynq_slcr_cpu_state - Read/write cpu state
+ * @cpu:   cpu number
  *
+ * SLCR_REBOOT_STATUS save upper 2 bits (31/30 cpu states for cpu0 and cpu1)
+ * 0 means cpu is running, 1 cpu is going to die.
+ *
+ * Return: true if cpu is running, false if cpu is going to die
+ */
+bool zynq_slcr_cpu_state_read(int cpu)
+{
+   u32 state;
+
+   state = readl(zynq_slcr_base + SLCR_REBOOT_STATUS_OFFSET);
+   state &= 1 << (31 - cpu);
+
+   return !state;
+}
+
+/**
+ * zynq_slcr_cpu_state - Read/write cpu state
+ * @cpu:   cpu number
+ * @die:   cpu state - true if cpu is going to die
+ *
+ * SLCR_REBOOT_STATUS save upper 2 bits (31/30 cpu states for cpu0 and cpu1)
+ * 0 means cpu is running, 1 cpu is going to die.
+ */
+void zynq_slcr_cpu_state_write(int cpu, bool die)
+{
+   u32 state, mask;
+
+   state = readl(zynq_slcr_base + SLCR_REBOOT_STATUS_OFFSET);
+   mask = 1 << (31 - cpu);
+   if (die)
+   state |= mask;
+   else
+   state &= ~mask;
+   writel(state, zynq_slcr_base + SLCR_REBOOT_STATUS_OFFSET);
+}
+
+/**
+ * zynq_slcr_init - Regular slcr driver init
  * Return: 0 on success, negative errno otherwise.
  *
  * Called early during boot from platform code to remap SLCR area.
-- 
2.1.0.1.g27b9230

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 9/9] ARM: zynq: Rename 'zynq_platform_cpu_die'

[Soren Brinkmann]

Match the naming pattern of all other SMP ops and rename
zynq_platform_cpu_die --> zynq_cpu_die.

Signed-off-by: Soren Brinkmann 
---
v2:
 - make comments comply to kernel-doc format
---
 arch/arm/mach-zynq/platsmp.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-zynq/platsmp.c b/arch/arm/mach-zynq/platsmp.c
index f722b5a83a45..52d768ff7857 100644
--- a/arch/arm/mach-zynq/platsmp.c
+++ b/arch/arm/mach-zynq/platsmp.c
@@ -137,12 +137,14 @@ static int zynq_cpu_kill(unsigned cpu)
return 1;
 }
 
-/*
- * platform-specific code to shutdown a CPU
+/**
+ * zynq_cpu_die - Let a CPU core die
+ * @cpu:   Dying CPU
  *
- * Called with IRQs disabled
+ * Platform-specific code to shutdown a CPU.
+ * Called with IRQs disabled on the dying CPU.
  */
-static void zynq_platform_cpu_die(unsigned int cpu)
+static void zynq_cpu_die(unsigned int cpu)
 {
zynq_slcr_cpu_state_write(cpu, true);
 
@@ -162,7 +164,7 @@ struct smp_operations zynq_smp_ops __initdata = {
.smp_boot_secondary = zynq_boot_secondary,
.smp_secondary_init = zynq_secondary_init,
 #ifdef CONFIG_HOTPLUG_CPU
-   .cpu_die= zynq_platform_cpu_die,
+   .cpu_die= zynq_cpu_die,
.cpu_kill   = zynq_cpu_kill,
 #endif
 };
-- 
2.1.0.1.g27b9230

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 4/9] ARM: zynq: PM: Enable DDR clock stop

[Soren Brinkmann]

The DDR controller can detect idle periods and leverage low power
features clock stop. When new requests occur, the DDRC resumes
normal operation.

Signed-off-by: Soren Brinkmann 
---
v2:
 - properly document return value for zynq_pm_ioremap
 - change zynq_pm_late_init signature to return void
 - add kernel doc to late_init()
 - fix kernel doc
 - only enable clock-stop during boot and leave out self-refresh. The
   self-refresh penalty is apparently not-negligible
---
 arch/arm/mach-zynq/Makefile |  2 +-
 arch/arm/mach-zynq/common.c |  1 +
 arch/arm/mach-zynq/common.h |  2 ++
 arch/arm/mach-zynq/pm.c | 83 +
 4 files changed, 87 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-zynq/pm.c

diff --git a/arch/arm/mach-zynq/Makefile b/arch/arm/mach-zynq/Makefile
index 1b25d92ebf22..820dff6e1eba 100644
--- a/arch/arm/mach-zynq/Makefile
+++ b/arch/arm/mach-zynq/Makefile
@@ -3,7 +3,7 @@
 #
 
 # Common support
-obj-y  := common.o slcr.o
+obj-y  := common.o slcr.o pm.o
 CFLAGS_REMOVE_hotplug.o=-march=armv6k
 CFLAGS_hotplug.o   =-Wa,-march=armv7-a -mcpu=cortex-a9
 obj-$(CONFIG_HOTPLUG_CPU)  += hotplug.o
diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index 3cb7c198615a..6bd13e5ce6b7 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -101,6 +101,7 @@ static int __init zynq_get_revision(void)
 static void __init zynq_init_late(void)
 {
zynq_core_pm_init();
+   zynq_pm_late_init();
 }
 
 /**
diff --git a/arch/arm/mach-zynq/common.h b/arch/arm/mach-zynq/common.h
index 596ef0b5067c..0edbb6997b1c 100644
--- a/arch/arm/mach-zynq/common.h
+++ b/arch/arm/mach-zynq/common.h
@@ -40,6 +40,8 @@ extern void __iomem *zynq_scu_base;
 /* Hotplug */
 extern void zynq_platform_cpu_die(unsigned int cpu);
 
+void zynq_pm_late_init(void);
+
 static inline void zynq_core_pm_init(void)
 {
/* A9 clock gating */
diff --git a/arch/arm/mach-zynq/pm.c b/arch/arm/mach-zynq/pm.c
new file mode 100644
index ..911fcf865be8
--- /dev/null
+++ b/arch/arm/mach-zynq/pm.c
@@ -0,0 +1,83 @@
+/*
+ * Zynq power management
+ *
+ *  Copyright (C) 2012 - 2014 Xilinx
+ *
+ *  Sören Brinkmann 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include "common.h"
+
+/* register offsets */
+#define DDRC_CTRL_REG1_OFFS0x60
+#define DDRC_DRAM_PARAM_REG3_OFFS  0x20
+
+/* bitfields */
+#define DDRC_CLOCKSTOP_MASKBIT(23)
+#define DDRC_SELFREFRESH_MASK  BIT(12)
+
+static void __iomem *ddrc_base;
+
+/**
+ * zynq_pm_ioremap() - Create IO mappings
+ * @comp:  DT compatible string
+ * Return: Pointer to the mapped memory or NULL.
+ *
+ * Remap the memory region for a compatible DT node.
+ */
+static void __iomem *zynq_pm_ioremap(const char *comp)
+{
+   struct device_node *np;
+   void __iomem *base = NULL;
+
+   np = of_find_compatible_node(NULL, NULL, comp);
+   if (np) {
+   base = of_iomap(np, 0);
+   of_node_put(np);
+   } else {
+   pr_warn("%s: no compatible node found for '%s'\n", __func__,
+   comp);
+   }
+
+   return base;
+}
+
+/**
+ * zynq_pm_late_init() - Power management init
+ *
+ * Initialization of power management related featurs and infrastructure.
+ */
+void __init zynq_pm_late_init(void)
+{
+   u32 reg;
+
+   ddrc_base = zynq_pm_ioremap("xlnx,zynq-ddrc-a05");
+   if (!ddrc_base) {
+   pr_warn("%s: Unable to map DDRC IO memory.\n", __func__);
+   } else {
+   /*
+* Enable DDRC clock stop feature. The HW takes care of
+* entering/exiting the correct mode depending
+* on activity state.
+*/
+   reg = readl(ddrc_base + DDRC_DRAM_PARAM_REG3_OFFS);
+   reg |= DDRC_CLOCKSTOP_MASK;
+   writel(reg, ddrc_base + DDRC_DRAM_PARAM_REG3_OFFS);
+   }
+}
-- 
2.1.0.1.g27b9230

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] semaphore: Resolve some shadow warnings

[Rustad, Mark D]

On Sep 1, 2014, at 4:41 PM, Jeff Kirsher  wrote:

> On Mon, 2014-09-01 at 14:02 +0200, Peter Zijlstra wrote:
>> On Thu, Aug 28, 2014 at 05:19:26AM -0700, Jeff Kirsher wrote:
>>> From: Mark Rustad 
>>> 
>>> Resolve some shadow warnings resulting from using the name
>>> jiffies, which is a well-known global. This is not a problem
>>> of course, but it could be a trap for someone copying and
>>> pasting code, and it just makes W=2 a little cleaner.
>>> 
>>> Signed-off-by: Mark Rustad 
>>> Signed-off-by: Jeff Kirsher 
>> 
>> Why isn't Mark sending this email?
> 
> Mark sent me several patches like this, for me to push upstream.  So, I
> am making sure the appropriate owner is the receives the patch versus
> blindly sending to LKML.
> 
>> 
>>> ---
>>> kernel/locking/semaphore.c | 12 ++--
>>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>> 
>>> diff --git a/kernel/locking/semaphore.c b/kernel/locking/semaphore.c
>>> index 6815171..7782dbc 100644
>>> --- a/kernel/locking/semaphore.c
>>> +++ b/kernel/locking/semaphore.c
>>> @@ -36,7 +36,7 @@
>>> static noinline void __down(struct semaphore *sem);
>>> static noinline int __down_interruptible(struct semaphore *sem);
>>> static noinline int __down_killable(struct semaphore *sem);
>>> -static noinline int __down_timeout(struct semaphore *sem, long jiffies);
>>> +static noinline int __down_timeout(struct semaphore *sem, long njiffies);
>>> static noinline void __up(struct semaphore *sem);
>> 
>> So what's wrong with calling it "timeout" instead? That's what most
>> other sites do.
> 
> Timeout would work as well to resolve the shadow warnings.

It would, but then it would be unclear as to what units the timeout was in. I 
have no other objection to timeout, I was just trying to preserve the meaning 
in the existing overloaded name. The "n" to me suggests a number and, if 
anything, number of jiffies conveys a more precise meaning than simply jiffies 
did.

-- 
Mark Rustad, Networking Division, Intel Corporation



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [RFC] dynticks: dynticks_idle is only modified locally use this_cpu ops

[Paul E. McKenney]

On Tue, Sep 02, 2014 at 03:47:55PM -0500, Christoph Lameter wrote:
> On Tue, 2 Sep 2014, Paul E. McKenney wrote:
> 
> > But yes, in theory, something like this can work if appropriate memory
> > barriers are put in place.  In practice, this sort of change needs
> > profound testing on multiple architectures.
> 
> Ok how can we move forward? I just looked further and it seems a similar
> approach could perhaps work for the dynticks field.

Yep, these two have been on my "when I am feeling insanely gutsy" list
for quite some time.

But I have to ask...  On x86, is a pair of mfence instructions really
cheaper than an atomic increment?

> If the first patch I send gets merged then a lot of other this_cpu related
> optimizations become possible regardless of the ones in the RFC.

Yep, I am queuing that one.

But could you please do future patches against the rcu/dev branch of
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git?
I had to hand-apply due to conflicts.  Please see below for my version,
and please check to make sure that I didn't mess something up in the
translation.

Thanx, Paul



rcu: Remove rcu_dynticks * parameters when they are always 
this_cpu_ptr(_dynticks)

For some functions in kernel/rcu/tree* the rdtp parameter is always
this_cpu_ptr(rdtp).  Remove the parameter if constant and calculate the
pointer in function.

This will have the advantage that it is obvious that the address are
all per cpu offsets and thus it will enable the use of this_cpu_ops in
the future.

Signed-off-by: Christoph Lameter 
[ paulmck: Forward-ported to rcu/dev, whitespace adjustment. ]
Signed-off-by: Paul E. McKenney 

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 929ea9a6e0a1..65c42a6465eb 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -497,11 +497,11 @@ cpu_needs_another_gp(struct rcu_state *rsp, struct 
rcu_data *rdp)
  * we really have entered idle, and must do the appropriate accounting.
  * The caller must have disabled interrupts.
  */
-static void rcu_eqs_enter_common(struct rcu_dynticks *rdtp, long long oldval,
-   bool user)
+static void rcu_eqs_enter_common(long long oldval, bool user)
 {
struct rcu_state *rsp;
struct rcu_data *rdp;
+   struct rcu_dynticks *rdtp = this_cpu_ptr(_dynticks);
 
trace_rcu_dyntick(TPS("Start"), oldval, rdtp->dynticks_nesting);
if (!user && !is_idle_task(current)) {
@@ -552,7 +552,7 @@ static void rcu_eqs_enter(bool user)
WARN_ON_ONCE((oldval & DYNTICK_TASK_NEST_MASK) == 0);
if ((oldval & DYNTICK_TASK_NEST_MASK) == DYNTICK_TASK_NEST_VALUE) {
rdtp->dynticks_nesting = 0;
-   rcu_eqs_enter_common(rdtp, oldval, user);
+   rcu_eqs_enter_common(oldval, user);
} else {
rdtp->dynticks_nesting -= DYNTICK_TASK_NEST_VALUE;
}
@@ -576,7 +576,7 @@ void rcu_idle_enter(void)
 
local_irq_save(flags);
rcu_eqs_enter(false);
-   rcu_sysidle_enter(this_cpu_ptr(_dynticks), 0);
+   rcu_sysidle_enter(0);
local_irq_restore(flags);
 }
 EXPORT_SYMBOL_GPL(rcu_idle_enter);
@@ -626,8 +626,8 @@ void rcu_irq_exit(void)
if (rdtp->dynticks_nesting)
trace_rcu_dyntick(TPS("--="), oldval, rdtp->dynticks_nesting);
else
-   rcu_eqs_enter_common(rdtp, oldval, true);
-   rcu_sysidle_enter(rdtp, 1);
+   rcu_eqs_enter_common(oldval, true);
+   rcu_sysidle_enter(1);
local_irq_restore(flags);
 }
 
@@ -638,9 +638,10 @@ void rcu_irq_exit(void)
  * we really have exited idle, and must do the appropriate accounting.
  * The caller must have disabled interrupts.
  */
-static void rcu_eqs_exit_common(struct rcu_dynticks *rdtp, long long oldval,
-  int user)
+static void rcu_eqs_exit_common(long long oldval, int user)
 {
+   struct rcu_dynticks *rdtp = this_cpu_ptr(_dynticks);
+
rcu_dynticks_task_exit();
smp_mb__before_atomic();  /* Force ordering w/previous sojourn. */
atomic_inc(>dynticks);
@@ -678,7 +679,7 @@ static void rcu_eqs_exit(bool user)
rdtp->dynticks_nesting += DYNTICK_TASK_NEST_VALUE;
} else {
rdtp->dynticks_nesting = DYNTICK_TASK_EXIT_IDLE;
-   rcu_eqs_exit_common(rdtp, oldval, user);
+   rcu_eqs_exit_common(oldval, user);
}
 }
 
@@ -699,7 +700,7 @@ void rcu_idle_exit(void)
 
local_irq_save(flags);
rcu_eqs_exit(false);
-   rcu_sysidle_exit(this_cpu_ptr(_dynticks), 0);
+   rcu_sysidle_exit(0);
local_irq_restore(flags);
 }
 EXPORT_SYMBOL_GPL(rcu_idle_exit);
@@ -750,8 +751,8 @@ void rcu_irq_enter(void)
if (oldval)
trace_rcu_dyntick(TPS("++="), oldval, rdtp->dynticks_nesting);
else
-   

Re: [PATCH v3 2/4] Documentation/scheduler/sched-deadline.txt: Rewrite section 4 intro

[Henrik Austad]

On Thu, Aug 28, 2014 at 11:00:27AM +0100, Juri Lelli wrote:
> Section 4 intro was still describing the old interface. Rewrite it.
> 
> Signed-off-by: Juri Lelli 
> Signed-off-by: Luca Abeni 
> Cc: Randy Dunlap 
> Cc: Peter Zijlstra 
> Cc: Ingo Molnar 
> Cc: Henrik Austad 
> Cc: Dario Faggioli 
> Cc: Juri Lelli 
> Cc: linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  Documentation/scheduler/sched-deadline.txt | 51 
> +++---
>  1 file changed, 25 insertions(+), 26 deletions(-)
> 
> diff --git a/Documentation/scheduler/sched-deadline.txt 
> b/Documentation/scheduler/sched-deadline.txt
> index dce6d63..0aff2d5 100644
> --- a/Documentation/scheduler/sched-deadline.txt
> +++ b/Documentation/scheduler/sched-deadline.txt
> @@ -165,39 +165,38 @@ CONTENTS
>  
>   In order for the -deadline scheduling to be effective and useful, it is
>   important to have some method to keep the allocation of the available CPU
> - bandwidth to the tasks under control.
> - This is usually called "admission control" and if it is not performed at 
> all,
> - no guarantee can be given on the actual scheduling of the -deadline tasks.
> -
> - Since when RT-throttling has been introduced each task group has a bandwidth
> - associated, calculated as a certain amount of runtime over a period.
> - Moreover, to make it possible to manipulate such bandwidth, 
> readable/writable
> - controls have been added to both procfs (for system wide settings) and 
> cgroupfs
> - (for per-group settings).
> - Therefore, the same interface is being used for controlling the bandwidth
> - distrubution to -deadline tasks.
> -
> - However, more discussion is needed in order to figure out how we want to 
> manage
> - SCHED_DEADLINE bandwidth at the task group level. Therefore, SCHED_DEADLINE
> - uses (for now) a less sophisticated, but actually very sensible, mechanism 
> to
> - ensure that a certain utilization cap is not overcome per each root_domain.
> -
> - Another main difference between deadline bandwidth management and 
> RT-throttling
> + bandwidth to the tasks under control. This is usually called "admission
> + control" and if it is not performed at all, no guarantee can be given on
> + the actual scheduling of the -deadline tasks.
> +
> + The interface used to control the fraction of CPU bandwidth that can be
> + allocated to -deadline tasks is similar to the one already used for -rt
> + tasks with real-time group scheduling (a.k.a. RT-throttling - see
> + Documentation/scheduler/sched-rt-group.txt), and is based on readable/
> + writable control files located in procfs (for system wide settings).
> + Notice that per-group settings (controlled through cgroupfs) are still not
> + defined for -deadline tasks, because more discussion is needed in order to
> + figure out how we want to manage SCHED_DEADLINE bandwidth at the task group
> + level.
> +
> + A main difference between deadline bandwidth management and RT-throttling
>   is that -deadline tasks have bandwidth on their own (while -rt ones don't!),
> - and thus we don't need an higher level throttling mechanism to enforce the
> - desired bandwidth.
> + and thus we don't need a higher level throttling mechanism to enforce the
> + desired bandwidth. Therefore, using this simple interface we can put a cap
> + on total utilization of -deadline tasks (i.e., \Sum (runtime_i / period_i) <
> + some_desired_value).

s/some_desired_value/global_dl_utilization_cap/  perhaps?

>  4.1 System wide settings
>  
>  
>   The system wide settings are configured under the /proc virtual file system.
>  
> - For now the -rt knobs are used for dl admission control and the -deadline
> - runtime is accounted against the -rt runtime. We realise that this isn't
> - entirely desirable; however, it is better to have a small interface for now,
> - and be able to change it easily later. The ideal situation (see 5.) is to 
> run
> - -rt tasks from a -deadline server; in which case the -rt bandwidth is a 
> direct
> - subset of dl_bw.
> + For now the -rt knobs are used for -deadline admission control and the
> + -deadline runtime is accounted against the -rt runtime. We realise that this
> + isn't entirely desirable; however, it is better to have a small interface 
> for
> + now, and be able to change it easily later. The ideal situation (see 5.) is 
> to
> + run -rt tasks from a -deadline server; in which case the -rt bandwidth is a
> + direct subset of dl_bw.

Isn't forking forbidden for _dl tasks? Or did I miss a memo somewhere?

>   This means that, for a root_domain comprising M CPUs, -deadline tasks
>   can be created while the sum of their bandwidths stays below:
> -- 
> 2.0.4
> 
> 

All in all, looks pretty good to me!

-- 
Henrik
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  

[PATCH] drivers: staging: lustre: Fix "space prohibited after that open parenthesis '('" errors

[Greg Donald]

Fix checkpatch.pl "space prohibited after that open parenthesis '('" errors

Signed-off-by: Greg Donald 
---
 drivers/staging/lustre/lustre/lmv/lmv_internal.h   |  2 +-
 .../lustre/lustre/obdclass/linux/linux-module.c|  4 ++--
 drivers/staging/lustre/lustre/obdclass/obdo.c  | 28 +++---
 3 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/lustre/lustre/lmv/lmv_internal.h 
b/drivers/staging/lustre/lustre/lmv/lmv_internal.h
index 80e6604..96d35bf 100644
--- a/drivers/staging/lustre/lustre/lmv/lmv_internal.h
+++ b/drivers/staging/lustre/lustre/lmv/lmv_internal.h
@@ -93,7 +93,7 @@ static inline struct lmv_stripe_md *lmv_get_mea(struct 
ptlrpc_request *req)
 
if (mea->mea_count == 0)
return NULL;
-   if( mea->mea_magic != MEA_MAGIC_LAST_CHAR &&
+   if (mea->mea_magic != MEA_MAGIC_LAST_CHAR &&
mea->mea_magic != MEA_MAGIC_ALL_CHARS &&
mea->mea_magic != MEA_MAGIC_HASH_SEGMENT)
return NULL;
diff --git a/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c 
b/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
index 9ce3d36..50256a9 100644
--- a/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
+++ b/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
@@ -84,7 +84,7 @@ int obd_ioctl_getdata(char **buf, int *len, void *arg)
int offset = 0;
 
err = copy_from_user(, (void *)arg, sizeof(hdr));
-   if ( err )
+   if (err)
return err;
 
if (hdr.ioc_version != OBD_IOCTL_VERSION) {
@@ -118,7 +118,7 @@ int obd_ioctl_getdata(char **buf, int *len, void *arg)
data = (struct obd_ioctl_data *)*buf;
 
err = copy_from_user(*buf, (void *)arg, hdr.ioc_len);
-   if ( err ) {
+   if (err) {
OBD_FREE_LARGE(*buf, hdr.ioc_len);
return err;
}
diff --git a/drivers/staging/lustre/lustre/obdclass/obdo.c 
b/drivers/staging/lustre/lustre/obdclass/obdo.c
index bdc00ea..d170b14 100644
--- a/drivers/staging/lustre/lustre/obdclass/obdo.c
+++ b/drivers/staging/lustre/lustre/obdclass/obdo.c
@@ -161,35 +161,35 @@ int obdo_cmp_md(struct obdo *dst, struct obdo *src, u32 
compare)
 {
int res = 0;
 
-   if ( compare & OBD_MD_FLATIME )
+   if (compare & OBD_MD_FLATIME)
res = (res || (dst->o_atime != src->o_atime));
-   if ( compare & OBD_MD_FLMTIME )
+   if (compare & OBD_MD_FLMTIME)
res = (res || (dst->o_mtime != src->o_mtime));
-   if ( compare & OBD_MD_FLCTIME )
+   if (compare & OBD_MD_FLCTIME)
res = (res || (dst->o_ctime != src->o_ctime));
-   if ( compare & OBD_MD_FLSIZE )
+   if (compare & OBD_MD_FLSIZE)
res = (res || (dst->o_size != src->o_size));
-   if ( compare & OBD_MD_FLBLOCKS ) /* allocation of space */
+   if (compare & OBD_MD_FLBLOCKS) /* allocation of space */
res = (res || (dst->o_blocks != src->o_blocks));
-   if ( compare & OBD_MD_FLBLKSZ )
+   if (compare & OBD_MD_FLBLKSZ)
res = (res || (dst->o_blksize != src->o_blksize));
-   if ( compare & OBD_MD_FLTYPE )
+   if (compare & OBD_MD_FLTYPE)
res = (res || (((dst->o_mode ^ src->o_mode) & S_IFMT) != 0));
-   if ( compare & OBD_MD_FLMODE )
+   if (compare & OBD_MD_FLMODE)
res = (res || (((dst->o_mode ^ src->o_mode) & ~S_IFMT) != 0));
-   if ( compare & OBD_MD_FLUID )
+   if (compare & OBD_MD_FLUID)
res = (res || (dst->o_uid != src->o_uid));
-   if ( compare & OBD_MD_FLGID )
+   if (compare & OBD_MD_FLGID)
res = (res || (dst->o_gid != src->o_gid));
-   if ( compare & OBD_MD_FLFLAGS )
+   if (compare & OBD_MD_FLFLAGS)
res = (res || (dst->o_flags != src->o_flags));
-   if ( compare & OBD_MD_FLNLINK )
+   if (compare & OBD_MD_FLNLINK)
res = (res || (dst->o_nlink != src->o_nlink));
-   if ( compare & OBD_MD_FLFID ) {
+   if (compare & OBD_MD_FLFID) {
res = (res || (dst->o_parent_seq != src->o_parent_seq));
res = (res || (dst->o_parent_ver != src->o_parent_ver));
}
-   if ( compare & OBD_MD_FLGENER )
+   if (compare & OBD_MD_FLGENER)
res = (res || (dst->o_parent_oid != src->o_parent_oid));
/* XXX Don't know if these should be included here - wasn't previously
if ( compare & OBD_MD_FLINLINE )
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/4] Documentation/scheduler/sched-deadline.txt: fix terminology and improve clarity

[Henrik Austad]

On Thu, Aug 28, 2014 at 11:00:26AM +0100, Juri Lelli wrote:
> From: Luca Abeni 
> 
> Several small changes regarding SCHED_DEADLINE documentation that fix
> terminology and improve clarity and readability:
> 
>  - "current runtime" becomes "remaining runtime"
> 
>  - readablity of an equation is improved by introducing more spacing
> 
>  - clarify when admission control will certainly fail
> 
>  - new URL for CBS technical report
> 
>  - substitue "smallest" with "closest"

I'm tempted to say "earliest" (being part of the algorithm's name and all 
;)

> 
> Signed-off-by: Luca Abeni 
> Signed-off-by: Juri Lelli 
> Cc: Randy Dunlap 
> Cc: Peter Zijlstra 
> Cc: Ingo Molnar 
> Cc: Henrik Austad 
> Cc: Dario Faggioli 
> Cc: Juri Lelli 
> Cc: linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  Documentation/scheduler/sched-deadline.txt | 32 
> --
>  1 file changed, 17 insertions(+), 15 deletions(-)
> 
> diff --git a/Documentation/scheduler/sched-deadline.txt 
> b/Documentation/scheduler/sched-deadline.txt
> index 18adc92..dce6d63 100644
> --- a/Documentation/scheduler/sched-deadline.txt
> +++ b/Documentation/scheduler/sched-deadline.txt
> @@ -45,14 +45,14 @@ CONTENTS
>   every time the task wakes up, the scheduler computes a "scheduling deadline"
>   consistent with the guarantee (using the CBS[2,3] algorithm). Tasks are then
>   scheduled using EDF[1] on these scheduling deadlines (the task with the
> - smallest scheduling deadline is selected for execution). Notice that this
> + closest scheduling deadline is selected for execution). Notice that this
>   guaranteed is respected if a proper "admission control" strategy (see 
> Section
>   "4. Bandwidth management") is used.
>  
>   Summing up, the CBS[2,3] algorithms assigns scheduling deadlines to tasks so
>   that each task runs for at most its runtime every period, avoiding any
>   interference between different tasks (bandwidth isolation), while the EDF[1]
> - algorithm selects the task with the smallest scheduling deadline as the one
> + algorithm selects the task with the closest scheduling deadline as the one
>   to be executed first.  Thanks to this feature, also tasks that do not

s/first/next/

Also, next sentence does not make much sense, I would drop the also;

"Thanks to this feature, tasks that do not strictly comply with the ..."

>   strictly comply with the "traditional" real-time task model (see Section 3)
>   can effectively use the new policy.
> @@ -64,45 +64,45 @@ CONTENTS
>  "deadline", and "period" parameters;
>  
>- The state of the task is described by a "scheduling deadline", and
> -a "current runtime". These two parameters are initially set to 0;
> +a "remaining runtime". These two parameters are initially set to 0;
>  
>- When a SCHED_DEADLINE task wakes up (becomes ready for execution),
>  the scheduler checks if
>  
> -current runtimeruntime
> - -- > 
> - scheduling deadline - current time period
> + remaining runtime  runtime
> +-->-
> +scheduling deadline - current time   period
>
>  then, if the scheduling deadline is smaller than the current time, or
>  this condition is verified, the scheduling deadline and the
> -current budget are re-initialised as
> +remaining runtime are re-initialised as
>  
>   scheduling deadline = current time + deadline
> - current runtime = runtime
> + remaining runtime = runtime
>  
> -otherwise, the scheduling deadline and the current runtime are
> +otherwise, the scheduling deadline and the remaining runtime are
>  left unchanged;
>  
>- When a SCHED_DEADLINE task executes for an amount of time t, its
> -current runtime is decreased as
> +remaining runtime is decreased as
>  
> - current runtime = current runtime - t
> + remaining runtime = remaining runtime - t
>  
>  (technically, the runtime is decreased at every tick, or when the
>  task is descheduled / preempted);
>  
> -  - When the current runtime becomes less or equal than 0, the task is
> +  - When the remaining runtime becomes less or equal than 0, the task is
>  said to be "throttled" (also known as "depleted" in real-time literature)
>  and cannot be scheduled until its scheduling deadline. The "replenishment
>  time" for this task (see next item) is set to be equal to the current
>  value of the scheduling deadline;
>  
>- When the current time is equal to the replenishment time of a
> -throttled task, the scheduling deadline and the current runtime are
> +throttled task, the scheduling deadline and the remaining runtime are
>  updated as
>  
>   scheduling deadline = scheduling deadline + period
> - current runtime = 

[tip:x86/platform] x86/iosf: Add debugfs support

[tip-bot for David E. Box]

Commit-ID:  8dc12f933c9d732c5bbfb233daf27377893b109c
Gitweb: http://git.kernel.org/tip/8dc12f933c9d732c5bbfb233daf27377893b109c
Author: David E. Box 
AuthorDate: Wed, 27 Aug 2014 14:40:40 -0700
Committer:  H. Peter Anvin 
CommitDate: Wed, 27 Aug 2014 14:48:36 -0700

x86/iosf: Add debugfs support

Allows access to the iosf sideband through debugfs.

Signed-off-by: David E. Box 
Link: 
http://lkml.kernel.org/r/1409175640-32426-3-git-send-email-david.e@linux.intel.com
Signed-off-by: H. Peter Anvin 
---
 arch/x86/kernel/iosf_mbi.c | 74 ++
 1 file changed, 74 insertions(+)

diff --git a/arch/x86/kernel/iosf_mbi.c b/arch/x86/kernel/iosf_mbi.c
index 9030e83..0a2faa3 100644
--- a/arch/x86/kernel/iosf_mbi.c
+++ b/arch/x86/kernel/iosf_mbi.c
@@ -22,6 +22,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 
@@ -187,6 +189,75 @@ bool iosf_mbi_available(void)
 }
 EXPORT_SYMBOL(iosf_mbi_available);
 
+/** debugfs begin /
+static u32 dbg_mdr;
+static u32 dbg_mcr;
+static u32 dbg_mcrx;
+
+static int mcr_get(void *data, u64 *val)
+{
+   *val = *(u32 *)data;
+   return 0;
+}
+
+static int mcr_set(void *data, u64 val)
+{
+   u8 command = ((u32)val & 0xFF00) >> 24,
+  port= ((u32)val & 0x00FF) >> 16,
+  offset  = ((u32)val & 0xFF00) >> 8;
+   int err;
+
+   *(u32 *)data = val;
+
+   if (!capable(CAP_SYS_RAWIO))
+   return -EACCES;
+
+   if (command & 1u)
+   err = iosf_mbi_write(port,
+  command,
+  dbg_mcrx | offset,
+  dbg_mdr);
+   else
+   err = iosf_mbi_read(port,
+ command,
+ dbg_mcrx | offset,
+ _mdr);
+
+   return err;
+}
+DEFINE_SIMPLE_ATTRIBUTE(iosf_mcr_fops, mcr_get, mcr_set , "%llx\n");
+
+static struct dentry *iosf_dbg;
+static void iosf_sideband_debug_init(void)
+{
+   struct dentry *d;
+
+   iosf_dbg = debugfs_create_dir("iosf_sb", NULL);
+   if (IS_ERR_OR_NULL(iosf_dbg))
+   return;
+
+   /* mdr */
+   d = debugfs_create_x32("mdr", 0660, iosf_dbg, _mdr);
+   if (IS_ERR_OR_NULL(d))
+   goto cleanup;
+
+   /* mcrx */
+   debugfs_create_x32("mcrx", 0660, iosf_dbg, _mcrx);
+   if (IS_ERR_OR_NULL(d))
+   goto cleanup;
+
+   /* mcr - initiates mailbox tranaction */
+   debugfs_create_file("mcr", 0660, iosf_dbg, _mcr, _mcr_fops);
+   if (IS_ERR_OR_NULL(d))
+   goto cleanup;
+
+   return;
+
+cleanup:
+   debugfs_remove_recursive(d);
+}
+/** debugfs end /
+
 static int iosf_mbi_probe(struct pci_dev *pdev,
  const struct pci_device_id *unused)
 {
@@ -217,11 +288,14 @@ static struct pci_driver iosf_mbi_pci_driver = {
 
 static int __init iosf_mbi_init(void)
 {
+   iosf_sideband_debug_init();
return pci_register_driver(_mbi_pci_driver);
 }
 
 static void __exit iosf_mbi_exit(void)
 {
+   debugfs_remove_recursive(iosf_dbg);
+
pci_unregister_driver(_mbi_pci_driver);
if (mbi_pdev) {
pci_dev_put(mbi_pdev);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/platform] x86/iosf: Add Kconfig prompt for IOSF_MBI selection

[tip-bot for David E. Box]

Commit-ID:  aa8e4f22ab7773352ba3895597189b8097f2c307
Gitweb: http://git.kernel.org/tip/aa8e4f22ab7773352ba3895597189b8097f2c307
Author: David E. Box 
AuthorDate: Wed, 27 Aug 2014 14:40:39 -0700
Committer:  H. Peter Anvin 
CommitDate: Wed, 27 Aug 2014 14:48:33 -0700

x86/iosf: Add Kconfig prompt for IOSF_MBI selection

Fixes an error in having the iosf build as 'default m'. On X86 SoC's the iosf
sideband is the only way to access information for some registers, as opposed to
through MSR's on other Intel architectures. While selecting IOSF_MBI is
preferred, it does mean carrying extra code on non-SoC architectures. This
exports the selection to the user, allowing those driver writers to compile out
iosf code if it's not being built.

Signed-off-by: David E. Box 
Link: 
http://lkml.kernel.org/r/1409175640-32426-2-git-send-email-david.e@linux.intel.com
Signed-off-by: H. Peter Anvin 
---
 arch/x86/Kconfig | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 5d0bf1a..a99988f 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2433,9 +2433,19 @@ config X86_DMA_REMAP
depends on STA2X11
 
 config IOSF_MBI
-   tristate
-   default m
+   tristate "Intel System On Chip IOSF Sideband support"
depends on PCI
+   ---help---
+ Enables sideband access to mailbox registers on SoC's. The sideband is
+ available on the following platforms. This list is not meant to be
+ exclusive.
+  - BayTrail
+  - Cherryview
+  - Braswell
+  - Quark
+
+ You should say Y if you are running a kernel on one of these
+ platforms.
 
 config PMC_ATOM
def_bool y
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC v2 0/9] KVM-VFIO IRQ forward control

[Alex Williamson]

On Mon, 2014-09-01 at 14:52 +0200, Eric Auger wrote:
> This RFC proposes an integration of "ARM: Forwarding physical
> interrupts to a guest VM" (http://lwn.net/Articles/603514/) in
> KVM.
> 
> It enables to transform a VFIO platform driver IRQ into a forwarded
> IRQ. The direct benefit is that, for a level sensitive IRQ, a VM
> switch can be avoided on guest virtual IRQ completion. Before this
> patch, a maintenance IRQ was triggered on the virtual IRQ completion.
> 
> When the IRQ is forwarded, the VFIO platform driver does not need to
> disable the IRQ anymore. Indeed when returning from the IRQ handler
> the IRQ is not deactivated. Only its priority is lowered. This means
> the same IRQ cannot hit before the guest completes the virtual IRQ
> and the GIC automatically deactivates the corresponding physical IRQ.
> 
> Besides, the injection still is based on irqfd triggering. The only
> impact on irqfd process is resamplefd is not called anymore on
> virtual IRQ completion since this latter becomes "transparent".
> 
> The current integration is based on an extension of the KVM-VFIO
> device, previously used by KVM to interact with VFIO groups. The
> patch serie now enables KVM to directly interact with a VFIO
> platform device. The VFIO external API was extended for that purpose.
> 
> Th KVM-VFIO device can get/put the vfio platform device, check its
> integrity and type, get the IRQ number associated to an IRQ index.
> 
> The IRQ forward programming is architecture specific (virtual interrupt
> controller programming basically). However the whole infrastructure is
> kept generic.
> 
> from a user point of view, the functionality is provided through new
> KVM-VFIO device commands, KVM_DEV_VFIO_DEVICE_(UN)FORWARD_IRQ
> and the capability can be checked with KVM_HAS_DEVICE_ATTR.
> Assignment can only be changed when the physical IRQ is not active.
> It is the responsability of the user to do this check.
> 
> This patch serie has the following dependencies:
> - "ARM: Forwarding physical interrupts to a guest VM"
>   (http://lwn.net/Articles/603514/) in
> - [PATCH v3] irqfd for ARM
> - and obviously the VFIO platform driver serie:
>   [RFC PATCH v6 00/20] VFIO support for platform devices on ARM
>   https://www.mail-archive.com/kvm@vger.kernel.org/msg103247.html
> 
> Integrated pieces can be found at
> ssh://git.linaro.org/people/eric.auger/linux.git
> on branch 3.17rc3_irqfd_forward_integ_v2
> 
> This was was tested on Calxeda Midway, assigning the xgmac main IRQ.
> 
> v1 -> v2:
> - forward control is moved from architecture specific file into generic
>   vfio.c module.
>   only kvm_arch_set_fwd_state remains architecture specific
> - integrate Kim's patch which enables KVM-VFIO for ARM
> - fix vgic state bypass in vgic_queue_hwirq
> - struct kvm_arch_forwarded_irq moved from arch/arm/include/uapi/asm/kvm.h
>   to include/uapi/linux/kvm.h
>   also irq_index renamed into index and guest_irq renamed into gsi
> - ASSIGN/DEASSIGN renamed into FORWARD/UNFORWARD
> - vfio_external_get_base_device renamed into vfio_external_base_device
> - vfio_external_get_type removed
> - kvm_vfio_external_get_base_device renamed into kvm_vfio_external_base_device
> - __KVM_HAVE_ARCH_KVM_VFIO renamed into __KVM_HAVE_ARCH_KVM_VFIO_FORWARD
> 
> Eric Auger (8):
>   KVM: ARM: VGIC: fix multiple injection of level sensitive forwarded
> IRQ
>   KVM: ARM: VGIC: add forwarded irq rbtree lock
>   VFIO: platform: handler tests whether the IRQ is forwarded
>   KVM: KVM-VFIO: update user API to program forwarded IRQ
>   VFIO: Extend external user API
>   KVM: KVM-VFIO: add new VFIO external API hooks
>   KVM: KVM-VFIO: generic KVM_DEV_VFIO_DEVICE command and IRQ forwarding
> control
>   KVM: KVM-VFIO: ARM forwarding control
> 
> Kim Phillips (1):
>   ARM: KVM: Enable the KVM-VFIO device
> 
>  Documentation/virtual/kvm/devices/vfio.txt |  26 ++
>  arch/arm/include/asm/kvm_host.h|   7 +
>  arch/arm/kvm/Kconfig   |   1 +
>  arch/arm/kvm/Makefile  |   4 +-
>  arch/arm/kvm/kvm_vfio_arm.c|  85 +
>  drivers/vfio/platform/vfio_platform_irq.c  |   7 +-
>  drivers/vfio/vfio.c|  24 ++
>  include/kvm/arm_vgic.h |   1 +
>  include/linux/kvm_host.h   |  27 ++
>  include/linux/vfio.h   |   3 +
>  include/uapi/linux/kvm.h   |   9 +
>  virt/kvm/arm/vgic.c|  59 +++-
>  virt/kvm/vfio.c| 497 
> -
>  13 files changed, 733 insertions(+), 17 deletions(-)
>  create mode 100644 arch/arm/kvm/kvm_vfio_arm.c
> 

Have we ventured too far in the other direction?  I suppose what I was
hoping to see was something more like:

case KVM_DEV_VFIO_DEVICE_FORWARD_IRQ:{

/* get vfio_device */

/* get mutex */

/* verify device+irq isn't already forwarded */

Compat sysinfo syscall (kernel/sys.c) relying on undefined behavior?

[Scotty Bauer]

 am getting acquainted with the linux kernel and to do so I've been browsing 
the source.


In the compat version of sysinfo, kernel/sys.c we see the following:

COMPAT_SYSCALL_DEFINE1(sysinfo, struct compat_sysinfo __user *, info)
{
struct sysinfo s;

do_sysinfo();

/* Check to see if any memory value is too large for 32-bit and scale
 *  down if needed
 */
if ((s.totalram >> 32) || (s.totalswap >> 32)) {
int bitcount = 0;

...


s.totalram is a u32, and the standard says:
"If the value of the right operand is negative or is greater than or equal to 
the width 
of the promoted left operand, the behavior is undefined."

Is there some promotion, compiler flag, something obvious that I am missing, or 
is this a 
problem?


Best,
Scotty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: rcu: Remove rcu_dynticks * parameters when they are always this_cpu_ptr(_dynticks)

[Paul E. McKenney]

On Tue, Sep 02, 2014 at 03:13:44PM -0500, Christoph Lameter wrote:
> For some functions in kernel/rcu/tree* the rdtp parameter is always 
> this_cpu_ptr(rdtp).
> Remove the parameter if constant and calculate the pointer in function.
> 
> This will have the advantage that it is obvious that the address are all per 
> cpu
> offsets and thus it will enable the use of this_cpu_ops in the future.
> 
> Signed-off-by: Christoph Lameter 

Looks plausible, thank you.  Let's see what testing, especially
Fengguang's testing, makes of this.  ;-)

Thanx, Paul

> Index: linux/kernel/rcu/tree.c
> ===
> --- linux.orig/kernel/rcu/tree.c
> +++ linux/kernel/rcu/tree.c
> @@ -499,11 +499,11 @@ cpu_needs_another_gp(struct rcu_state *r
>   * we really have entered idle, and must do the appropriate accounting.
>   * The caller must have disabled interrupts.
>   */
> -static void rcu_eqs_enter_common(struct rcu_dynticks *rdtp, long long oldval,
> - bool user)
> +static void rcu_eqs_enter_common(long long oldval, bool user)
>  {
>   struct rcu_state *rsp;
>   struct rcu_data *rdp;
> + struct rcu_dynticks *rdtp = this_cpu_ptr(_dynticks);
> 
>   trace_rcu_dyntick(TPS("Start"), oldval, rdtp->dynticks_nesting);
>   if (!user && !is_idle_task(current)) {
> @@ -553,7 +553,7 @@ static void rcu_eqs_enter(bool user)
>   WARN_ON_ONCE((oldval & DYNTICK_TASK_NEST_MASK) == 0);
>   if ((oldval & DYNTICK_TASK_NEST_MASK) == DYNTICK_TASK_NEST_VALUE) {
>   rdtp->dynticks_nesting = 0;
> - rcu_eqs_enter_common(rdtp, oldval, user);
> + rcu_eqs_enter_common(oldval, user);
>   } else {
>   rdtp->dynticks_nesting -= DYNTICK_TASK_NEST_VALUE;
>   }
> @@ -577,7 +577,7 @@ void rcu_idle_enter(void)
> 
>   local_irq_save(flags);
>   rcu_eqs_enter(false);
> - rcu_sysidle_enter(this_cpu_ptr(_dynticks), 0);
> + rcu_sysidle_enter(0);
>   local_irq_restore(flags);
>  }
>  EXPORT_SYMBOL_GPL(rcu_idle_enter);
> @@ -627,8 +627,8 @@ void rcu_irq_exit(void)
>   if (rdtp->dynticks_nesting)
>   trace_rcu_dyntick(TPS("--="), oldval, rdtp->dynticks_nesting);
>   else
> - rcu_eqs_enter_common(rdtp, oldval, true);
> - rcu_sysidle_enter(rdtp, 1);
> + rcu_eqs_enter_common(oldval, true);
> + rcu_sysidle_enter(1);
>   local_irq_restore(flags);
>  }
> 
> @@ -639,9 +639,11 @@ void rcu_irq_exit(void)
>   * we really have exited idle, and must do the appropriate accounting.
>   * The caller must have disabled interrupts.
>   */
> -static void rcu_eqs_exit_common(struct rcu_dynticks *rdtp, long long oldval,
> +static void rcu_eqs_exit_common(long long oldval,
>  int user)
>  {
> + struct rcu_dynticks *rdtp = this_cpu_ptr(_dynticks);
> +
>   smp_mb__before_atomic();  /* Force ordering w/previous sojourn. */
>   atomic_inc(>dynticks);
>   /* CPUs seeing atomic_inc() must see later RCU read-side crit sects */
> @@ -678,7 +680,7 @@ static void rcu_eqs_exit(bool user)
>   rdtp->dynticks_nesting += DYNTICK_TASK_NEST_VALUE;
>   } else {
>   rdtp->dynticks_nesting = DYNTICK_TASK_EXIT_IDLE;
> - rcu_eqs_exit_common(rdtp, oldval, user);
> + rcu_eqs_exit_common(oldval, user);
>   }
>  }
> 
> @@ -699,7 +701,7 @@ void rcu_idle_exit(void)
> 
>   local_irq_save(flags);
>   rcu_eqs_exit(false);
> - rcu_sysidle_exit(this_cpu_ptr(_dynticks), 0);
> + rcu_sysidle_exit(0);
>   local_irq_restore(flags);
>  }
>  EXPORT_SYMBOL_GPL(rcu_idle_exit);
> @@ -750,8 +752,8 @@ void rcu_irq_enter(void)
>   if (oldval)
>   trace_rcu_dyntick(TPS("++="), oldval, rdtp->dynticks_nesting);
>   else
> - rcu_eqs_exit_common(rdtp, oldval, true);
> - rcu_sysidle_exit(rdtp, 1);
> + rcu_eqs_exit_common(oldval, true);
> + rcu_sysidle_exit(1);
>   local_irq_restore(flags);
>  }
> 
> Index: linux/kernel/rcu/tree.h
> ===
> --- linux.orig/kernel/rcu/tree.h
> +++ linux/kernel/rcu/tree.h
> @@ -595,8 +595,8 @@ static void rcu_boot_init_nocb_percpu_da
>  static void rcu_spawn_nocb_kthreads(struct rcu_state *rsp);
>  static void __maybe_unused rcu_kick_nohz_cpu(int cpu);
>  static bool init_nocb_callback_list(struct rcu_data *rdp);
> -static void rcu_sysidle_enter(struct rcu_dynticks *rdtp, int irq);
> -static void rcu_sysidle_exit(struct rcu_dynticks *rdtp, int irq);
> +static void rcu_sysidle_enter(int irq);
> +static void rcu_sysidle_exit(int irq);
>  static void rcu_sysidle_check_cpu(struct rcu_data *rdp, bool *isidle,
> unsigned long *maxj);
>  static bool is_sysidle_rcu_state(struct rcu_state *rsp);
> Index: linux/kernel/rcu/tree_plugin.h
> 

Re: regression caused by cgroups optimization in 3.17-rc2

[Dave Hansen]

I, of course, forgot to include the most important detail.  This appears
to be pretty run-of-the-mill spinlock contention in the resource counter
code.  Nearly 80% of the CPU is spent spinning in the charge or uncharge
paths in the kernel.  It is apparently spinning on res_counter->lock in
both the charge and uncharge paths.

It already does _some_ batching here on the free side, but that
apparently breaks down after ~40 threads.

It's a no-brainer since the patch in question removed an optimization
skipping the charging, and now we're seeing overhead from the charging.

Here's the first entry from perf top:

80.18%80.18%  [kernel]   [k] _raw_spin_lock
  |
  --- _raw_spin_lock
 |
 |--66.59%-- res_counter_uncharge_until
 |  res_counter_uncharge
 |  uncharge_batch
 |  uncharge_list
 |  mem_cgroup_uncharge_list
 |  release_pages
 |  free_pages_and_swap_cache
 |  tlb_flush_mmu_free
 |  |
 |  |--90.12%-- unmap_single_vma
 |  |  unmap_vmas
 |  |  unmap_region
 |  |  do_munmap
 |  |  vm_munmap
 |  |  sys_munmap
 |  |  system_call_fastpath
 |  |  __GI___munmap
 |  |
 |   --9.88%-- tlb_flush_mmu
 | tlb_finish_mmu
 | unmap_region
 | do_munmap
 | vm_munmap
 | sys_munmap
 | system_call_fastpath
 | __GI___munmap
 |
 |--46.13%-- __res_counter_charge
 |  res_counter_charge
 |  try_charge
 |  mem_cgroup_try_charge
 |  |
 |  |--99.89%-- do_cow_fault
 |  |  handle_mm_fault
 |  |  __do_page_fault
 |  |  do_page_fault
 |  |  page_fault
 |  |  testcase
 |   --0.11%-- [...]
 |
 |--1.14%-- do_cow_fault
 |  handle_mm_fault
 |  __do_page_fault
 |  do_page_fault
 |  page_fault
 |  testcase
  --8217937613.29%-- [...]

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 3/4] irq: Allow multiple clients to register for irq affinity notification

[Thomas Gleixner]

On Tue, 2 Sep 2014, Lina Iyer wrote:
> On Wed, Aug 27 2014 at 14:56 -0600, Thomas Gleixner wrote:
> > On Wed, 27 Aug 2014, Lina Iyer wrote:
> > 
> > All you are describing is the fact, that there is only a single
> > notifier possible right now, but you completely miss to describe WHY
> > you need multiple ones.
> > 
> > The existing notifier was introduced to tell the driver that the irq
> > affinity has changed, so it can move its buffers to the proper NUMA
> > node. So if that driver gets this information then it can tell the PM
> > QoS code that its affinity changed so that stuff can react
> > accordingly, right?
> > 
> With the new PM QoS changes, multiple drivers would now be interested in
> knowing the smp_affinity changes of the same IRQ. PM QoS abstracts the

Again, you fail to tell me WHY multiple drivers are interested and
which drivers are interested and what they do with that information.

> notifier in the framework, so individual drivers dont have to register
> for notification themselves and handle affinity notifications. But PM
> QoS needs to coexist with NUMA and other arch drivers that need to
> modify based on their arch specific needs upon affinity change
> notifications.

Lots of unspecified blurb. What has NUMA to do with other arch
drivers? Are you actually understanding what this is all about?

> Modifying the IRQ notifications to list, benefits having a simpler
> mechanism to notify all arch drivers and frameworks like PM QoS.

Painting my bikeshed blue benefits all neighbours and institutions
like the Royal Navy, right?

Lina, this is leading nowhere. You just make completely unspecified
claims and try to push your solution to a not explained problem
through. That's not how it works, at least not with me.

So please sit down and write up a proper description of the problem
you are trying to solve.

All I can see from your postings so far is:

1) You want to use the notification for PM QoS

2) You run into conflicts with the existing notifiers

3) You want to solve that conflict

What you are not telling is:

1) In which way is PM QoS going to use that notifier

2) How does that conflict with the existing users. And we only
   have two of them:

   - InfiniPath 7322 chip driver

   - cpu_rmap driver, which is used by

- solarflare NIC driver
- mellanox mlx4 driver
- cisco enic driver

So how is that conflicting with your ARM centric PM QoS work?

Please provide proper debug info about such a conflict, if it
exists at all.

3) Which arch drivers are involved?

   So far none, at least not in mainline according to
   "grep irq_set_affinity_notifier arch/".

   If you have out of tree code which uses this, then we want to
   see it first to understand what the arch driver is trying to
   solve by using that notification mechanism.

The more I think about what you are not telling the more I get the
feeling that this whole PM QoS thing you try to do is a complete
design disaster.

>From your changelog:

 "PM QoS and other idle frameworks can do a better job of addressing
  power and performance requirements for a cpu, knowing the IRQs that
  are affine to that cpu."

I agree with that. PM might make better decisions if it knows which
activities are targeted at a particular cpu.

So someone figured that out and you got tasked to implement it. So you
looked for a way to get to this information and you found the existing
notifier and decided to (ab)use it for your purpose. But you did not
spend a split second to figure out why this is wrong and even useless.

At the point where PM QoS or whatever decides to use that information,
it does not know at all what the current affinity mask is. So in your
patch 4/4, which I ignored so far you do:

+struct irq_desc *desc = irq_to_desc(req->irq);
+struct cpumask *mask = desc->irq_data.affinity;

WTF?

You did not even have the courtesy to use the proper functions for
this. And of course you access all of this unlocked. So how is that
supposed to work with a concurrent affinity update? Not at
all.

Fiddling with irq_desc is a NONO: Consult your preferred search
machine or just the kernel changelogs about the consequences.

Looking at the other patches you really seem to have missed out on
some other NONOs:

 struct pm_qos_request {
+   enum pm_qos_req_type type;
+   struct cpumask cpus_affine;
+   /* Internal structure members */
struct plist_node node;
int pm_qos_class;
struct delayed_work work; /* for pm_qos_update_request_timeout */
@@ -80,6 +90,7 @@ enum pm_qos_type {
 struct pm_qos_constraints {
struct plist_head list;
s32 target_value; /* Do not change to 64 bit */
+   s32 target_per_cpu[NR_CPUS];
s32 default_value;
s32 no_constraint_value;
enum pm_qos_type type;

Go figure how well "struct cpumask" and a s32 array sizeof NR_CPUS

[PATCH net-next v2] net: bpf: make eBPF interpreter images read-only

[Hannes Frederic Sowa]

From: Daniel Borkmann 

With eBPF getting more extended and exposure to user space is on it's way,
hardening the memory range the interpreter uses to steer its command flow
seems appropriate.  This patch moves the to be interpreted bytecode to
read-only pages.

In case we execute a corrupted BPF interpreter image for some reason e.g.
caused by an attacker which got past a verifier stage, it would not only
provide arbitrary read/write memory access but arbitrary function calls
as well. After setting up the BPF interpreter image, its contents do not
change until destruction time, thus we can setup the image on immutable
made pages in order to mitigate modifications to that code. The idea
is derived from commit 314beb9bcabf ("x86: bpf_jit_comp: secure bpf jit
against spraying attacks").

This is possible because bpf_prog is not part of sk_filter anymore.
After setup bpf_prog cannot be altered during its life-time. This prevents
any modifications to the entire bpf_prog structure (incl. function/JIT
image pointer).

Every eBPF program (including classic BPF that are migrated) have to call
bpf_prog_select_runtime() to select either interpreter or a JIT image
as a last setup step, and they all are being freed via bpf_prog_free(),
including non-JIT. Therefore, we can easily integrate this into the
eBPF life-time, plus since we directly allocate a bpf_prog, we have no
performance penalty.

Tested with seccomp and test_bpf testsuite in JIT/non-JIT mode and manual
inspection of kernel_page_tables.  Brad Spengler proposed the same idea
via Twitter during development of this patch.

Joint work with Hannes Frederic Sowa.

Suggested-by: Brad Spengler 
Signed-off-by: Daniel Borkmann 
Signed-off-by: Hannes Frederic Sowa 
Cc: Alexei Starovoitov 
Cc: Kees Cook 
---
v2) During proofreading I accidentally did not remove the old duplicate
paragraph from the changelog.

 arch/arm/net/bpf_jit_32.c   |  3 +-
 arch/mips/net/bpf_jit.c |  3 +-
 arch/powerpc/net/bpf_jit_comp.c |  3 +-
 arch/s390/net/bpf_jit_comp.c|  2 +-
 arch/sparc/net/bpf_jit_comp.c   |  3 +-
 arch/x86/net/bpf_jit_comp.c | 18 --
 include/linux/filter.h  | 49 ++---
 kernel/bpf/core.c   | 80 +++--
 kernel/seccomp.c|  7 ++--
 lib/test_bpf.c  |  2 +-
 net/core/filter.c   |  6 ++--
 11 files changed, 144 insertions(+), 32 deletions(-)

diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index a37b989..a76623b 100644
--- a/arch/arm/net/bpf_jit_32.c
+++ b/arch/arm/net/bpf_jit_32.c
@@ -930,5 +930,6 @@ void bpf_jit_free(struct bpf_prog *fp)
 {
if (fp->jited)
module_free(NULL, fp->bpf_func);
-   kfree(fp);
+
+   bpf_prog_unlock_free(fp);
 }
diff --git a/arch/mips/net/bpf_jit.c b/arch/mips/net/bpf_jit.c
index 05a5661..cfa83cf 100644
--- a/arch/mips/net/bpf_jit.c
+++ b/arch/mips/net/bpf_jit.c
@@ -1427,5 +1427,6 @@ void bpf_jit_free(struct bpf_prog *fp)
 {
if (fp->jited)
module_free(NULL, fp->bpf_func);
-   kfree(fp);
+
+   bpf_prog_unlock_free(fp);
 }
diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index 3afa6f4..40c53ff 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -697,5 +697,6 @@ void bpf_jit_free(struct bpf_prog *fp)
 {
if (fp->jited)
module_free(NULL, fp->bpf_func);
-   kfree(fp);
+
+   bpf_prog_unlock_free(fp);
 }
diff --git a/arch/s390/net/bpf_jit_comp.c b/arch/s390/net/bpf_jit_comp.c
index 61e45b7..f2833c5 100644
--- a/arch/s390/net/bpf_jit_comp.c
+++ b/arch/s390/net/bpf_jit_comp.c
@@ -887,5 +887,5 @@ void bpf_jit_free(struct bpf_prog *fp)
module_free(NULL, header);
 
 free_filter:
-   kfree(fp);
+   bpf_prog_unlock_free(fp);
 }
diff --git a/arch/sparc/net/bpf_jit_comp.c b/arch/sparc/net/bpf_jit_comp.c
index 1f76c22..f7a736b 100644
--- a/arch/sparc/net/bpf_jit_comp.c
+++ b/arch/sparc/net/bpf_jit_comp.c
@@ -812,5 +812,6 @@ void bpf_jit_free(struct bpf_prog *fp)
 {
if (fp->jited)
module_free(NULL, fp->bpf_func);
-   kfree(fp);
+
+   bpf_prog_unlock_free(fp);
 }
diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index b08a98c..39ccfbb 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -972,23 +972,17 @@ out:
kfree(addrs);
 }
 
-static void bpf_jit_free_deferred(struct work_struct *work)
+void bpf_jit_free(struct bpf_prog *fp)
 {
-   struct bpf_prog *fp = container_of(work, struct bpf_prog, work);
unsigned long addr = (unsigned long)fp->bpf_func & PAGE_MASK;
struct bpf_binary_header *header = (void *)addr;
 
+   if (!fp->jited)
+   goto free_filter;
+
set_memory_rw(addr, header->pages);
module_free(NULL, header);
-   kfree(fp);
-}
 
-void bpf_jit_free(struct bpf_prog *fp)
-{
-   if 

Re: [PATCH] ethernet: nvidia: Remove extra parens

[David Miller]

From: David Wood 
Date: Mon, 1 Sep 2014 15:31:55 -0700

> Remove unnecessary double parenthesis around if statement.
> 
> Signed-off-by: David Wood 

Applied, thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] dynticks: dynticks_idle is only modified locally use this_cpu ops

[Christoph Lameter]

On Tue, 2 Sep 2014, Paul E. McKenney wrote:

> But yes, in theory, something like this can work if appropriate memory
> barriers are put in place.  In practice, this sort of change needs
> profound testing on multiple architectures.

Ok how can we move forward? I just looked further and it seems a similar
approach could perhaps work for the dynticks field.

If the first patch I send gets merged then a lot of other this_cpu related
optimizations become possible regardless of the ones in the RFC.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH net-next] net: bpf: make eBPF interpreter images read-only

[Hannes Frederic Sowa]

From: Daniel Borkmann 

With eBPF getting more extended and exposure to user space is on it's way,
hardening the memory range the interpreter uses to steer its command flow
seems appropriate.  This patch moves the to be interpreted bytecode to
read-only pages.

In case we execute a corrupted BPF interpreter image for some reason e.g.
caused by an attacker which got past a verifier stage, it would not only
provide arbitrary read/write memory access but arbitrary function calls
as well. After setting up the BPF interpreter image, its contents do not
change until destruction time, thus we can setup the image on immutable
made pages in order to mitigate modifications to that code. The idea
is derived from commit 314beb9bcabf ("x86: bpf_jit_comp: secure bpf jit
against spraying attacks").

Therefore, introduce a page allocator for eBPF and RO locking mechanisms
in order to mitigate modifications to that code. The idea is derived
from commit 314beb9bcabf ("x86: bpf_jit_comp: secure bpf jit against
spraying attacks").

This is possible because bpf_prog is not part of sk_filter anymore.
After setup bpf_prog cannot be altered during its life-time. This prevents
any modifications to the entire bpf_prog structure (incl. function/JIT
image pointer).

Every eBPF program (including classic BPF that are migrated) have to call
bpf_prog_select_runtime() to select either interpreter or a JIT image
as a last setup step, and they all are being freed via bpf_prog_free(),
including non-JIT. Therefore, we can easily integrate this into the
eBPF life-time, plus since we directly allocate a bpf_prog, we have no
performance penalty.

Tested with seccomp and test_bpf testsuite in JIT/non-JIT mode and manual
inspection of kernel_page_tables.  Brad Spengler proposed the same idea
via Twitter during development of this patch.

Joint work with Hannes Frederic Sowa.

Suggested-by: Brad Spengler 
Signed-off-by: Daniel Borkmann 
Signed-off-by: Hannes Frederic Sowa 
Cc: Alexei Starovoitov 
Cc: Kees Cook 
---
 arch/arm/net/bpf_jit_32.c   |  3 +-
 arch/mips/net/bpf_jit.c |  3 +-
 arch/powerpc/net/bpf_jit_comp.c |  3 +-
 arch/s390/net/bpf_jit_comp.c|  2 +-
 arch/sparc/net/bpf_jit_comp.c   |  3 +-
 arch/x86/net/bpf_jit_comp.c | 18 --
 include/linux/filter.h  | 49 ++---
 kernel/bpf/core.c   | 80 +++--
 kernel/seccomp.c|  7 ++--
 lib/test_bpf.c  |  2 +-
 net/core/filter.c   |  6 ++--
 11 files changed, 144 insertions(+), 32 deletions(-)

diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index a37b989..a76623b 100644
--- a/arch/arm/net/bpf_jit_32.c
+++ b/arch/arm/net/bpf_jit_32.c
@@ -930,5 +930,6 @@ void bpf_jit_free(struct bpf_prog *fp)
 {
if (fp->jited)
module_free(NULL, fp->bpf_func);
-   kfree(fp);
+
+   bpf_prog_unlock_free(fp);
 }
diff --git a/arch/mips/net/bpf_jit.c b/arch/mips/net/bpf_jit.c
index 05a5661..cfa83cf 100644
--- a/arch/mips/net/bpf_jit.c
+++ b/arch/mips/net/bpf_jit.c
@@ -1427,5 +1427,6 @@ void bpf_jit_free(struct bpf_prog *fp)
 {
if (fp->jited)
module_free(NULL, fp->bpf_func);
-   kfree(fp);
+
+   bpf_prog_unlock_free(fp);
 }
diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index 3afa6f4..40c53ff 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -697,5 +697,6 @@ void bpf_jit_free(struct bpf_prog *fp)
 {
if (fp->jited)
module_free(NULL, fp->bpf_func);
-   kfree(fp);
+
+   bpf_prog_unlock_free(fp);
 }
diff --git a/arch/s390/net/bpf_jit_comp.c b/arch/s390/net/bpf_jit_comp.c
index 61e45b7..f2833c5 100644
--- a/arch/s390/net/bpf_jit_comp.c
+++ b/arch/s390/net/bpf_jit_comp.c
@@ -887,5 +887,5 @@ void bpf_jit_free(struct bpf_prog *fp)
module_free(NULL, header);
 
 free_filter:
-   kfree(fp);
+   bpf_prog_unlock_free(fp);
 }
diff --git a/arch/sparc/net/bpf_jit_comp.c b/arch/sparc/net/bpf_jit_comp.c
index 1f76c22..f7a736b 100644
--- a/arch/sparc/net/bpf_jit_comp.c
+++ b/arch/sparc/net/bpf_jit_comp.c
@@ -812,5 +812,6 @@ void bpf_jit_free(struct bpf_prog *fp)
 {
if (fp->jited)
module_free(NULL, fp->bpf_func);
-   kfree(fp);
+
+   bpf_prog_unlock_free(fp);
 }
diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index b08a98c..39ccfbb 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -972,23 +972,17 @@ out:
kfree(addrs);
 }
 
-static void bpf_jit_free_deferred(struct work_struct *work)
+void bpf_jit_free(struct bpf_prog *fp)
 {
-   struct bpf_prog *fp = container_of(work, struct bpf_prog, work);
unsigned long addr = (unsigned long)fp->bpf_func & PAGE_MASK;
struct bpf_binary_header *header = (void *)addr;
 
+   if (!fp->jited)
+   goto free_filter;
+
set_memory_rw(addr, 

Re: [PATCH] platform/x86: toshiba: re-enable acpi hotkeys after suspend to disk

[Matthew Garrett]

On Tue, 2014-09-02 at 14:04 -0400, Benjamin Tissoires wrote:

> we noticed this problem on a Toshiba Z40. I kind of brute-forced the thing, 
> and
> I ended up that calling "ENAB" was making the keys working again 
> (rmmod/insmod 
> the driver was sufficient, and the only command which was different from the
> resume was this ACPI call).
> 
> I am really surprised some toshiba laptops do not need this, so I'd prefer 
> that
> an ACPI expert (Matthew???) gives its wisdom regarding that.

Looks good to me. I'd be surprised if this breaks anything.

Acked-by: Matthew Garrett 

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

Re: [PATCH 15/15] tty: serial: 8250: omap: add dma support

[Sebastian Reichel]

On Tue, Sep 02, 2014 at 01:15:37PM -0700, Tony Lindgren wrote:
> * Sebastian Andrzej Siewior  [140902 11:40]:
> > On 09/01/2014 07:47 PM, Sebastian Andrzej Siewior wrote:
> > > Comparing it with serial-omap I see the same thing: I takes approx the
> > > same amount of data until the first one is displayed. After a lot of
> > > "long" writes which wake the chip up from idle I manage to freeze both,
> > > the serial-omap driver and mine driver.
> > 
> > So after some testing:
> > - it happens with omap-serial as well. Especially after disabling the
> >   LED trigger for both LEDs.
> > 
> > - it seemed that disabling the MDR1 check whether or not we lost
> >   context made the problem appear less often but it was a trick. Even
> >   with restoring the context each time I see the same problem.
> > 
> > - it seems to be easier to trigger with the LED trigger switched off.
> >   However sometimes it works for 10 minutes, sometimes it triggers
> >   after one.
> > 
> > - I see to face two kind of "deaths":
> >   - the LED still goes on and off and the uart just does not respond
> > even if I tell the button print something on the screen (the button
> > also changes the frequency of the LED so I know that the button is
> > doing something).
> > Also from dumping the content of /proc/interrupts it seems that a
> > wake up is made, the uart should have restored the registers.
> 
> OK yeah this is the case I was seeing too. So do you just set the
> LED triggers to none in sysfs to make it easier to reproduce?
> 
> >   - one where the system is dead and the LED does not blink anymore.
> > Also my button is dead.
> 
> This I don't think I've seen. This could also be the errata issue on
> your earlier rev beagleboard-xm with off-idle.
>  
> > - disabling DMA makes the problem not go away.
> 
> OK
>  
> > - mdelay(25) in omap8250_lost_context() is long enough to drop the 403
> >   bytes I send in my testcase. That means I see only "good" characters.
> >   With this the box remained alive for 2h. However the uart died anyway.
> 
> I wonder if doing some TX on the uart restores it? So maybe try
> 
> $ while [ 1 ]; do date; sleep 10 done &
> 
> To have it occasionally print something in the background.

If there is a way to detect the hangup you may try to recover by
resetting the serial device using omap_hwmod_reset().

-- Sebastian


signature.asc
Description: Digital signature

Re: [RFC] dynticks: dynticks_idle is only modified locally use this_cpu ops

[Paul E. McKenney]

On Tue, Sep 02, 2014 at 03:14:43PM -0500, Christoph Lameter wrote:
> 
> Since dynticks_idle is only ever modified by the local cpu we do
> not need to use an atomic there. The weak "atomicity" of this_cpu
> ops is sufficient since there is no other cpu modifying the variable.
> 
> [This is a cautious patch that leaves the barriers in place]

Actually, not so cautious.  On x86:

#define smp_mb__before_atomic() barrier()
#define smp_mb__after_atomic()  barrier()

But yes, in theory, something like this can work if appropriate memory
barriers are put in place.  In practice, this sort of change needs
profound testing on multiple architectures.

Thanx, Paul

> Signed-off-by: Christoph Lameter 
> 
> Index: linux/kernel/rcu/tree.c
> ===
> --- linux.orig/kernel/rcu/tree.c
> +++ linux/kernel/rcu/tree.c
> @@ -213,7 +213,7 @@ static DEFINE_PER_CPU(struct rcu_dyntick
>   .dynticks = ATOMIC_INIT(1),
>  #ifdef CONFIG_NO_HZ_FULL_SYSIDLE
>   .dynticks_idle_nesting = DYNTICK_TASK_NEST_VALUE,
> - .dynticks_idle = ATOMIC_INIT(1),
> + .dynticks_idle = 1,
>  #endif /* #ifdef CONFIG_NO_HZ_FULL_SYSIDLE */
>  };
> 
> Index: linux/kernel/rcu/tree.h
> ===
> --- linux.orig/kernel/rcu/tree.h
> +++ linux/kernel/rcu/tree.h
> @@ -91,7 +91,7 @@ struct rcu_dynticks {
>  #ifdef CONFIG_NO_HZ_FULL_SYSIDLE
>   long long dynticks_idle_nesting;
>   /* irq/process nesting level from idle. */
> - atomic_t dynticks_idle; /* Even value for idle, else odd. */
> + long dynticks_idle; /* Even value for idle, else odd. */
>   /*  "Idle" excludes userspace execution. */
>   unsigned long dynticks_idle_jiffies;
>   /* End of last non-NMI non-idle period. */
> Index: linux/kernel/rcu/tree_plugin.h
> ===
> --- linux.orig/kernel/rcu/tree_plugin.h
> +++ linux/kernel/rcu/tree_plugin.h
> @@ -2644,9 +2644,9 @@ static void rcu_sysidle_enter(int irq)
>   j = jiffies;
>   ACCESS_ONCE(rdtp->dynticks_idle_jiffies) = j;
>   smp_mb__before_atomic();
> - atomic_inc(>dynticks_idle);
> + this_cpu_inc(rcu_dynticks.dynticks_idle);
>   smp_mb__after_atomic();
> - WARN_ON_ONCE(atomic_read(>dynticks_idle) & 0x1);
> + WARN_ON_ONCE(__this_cpu_read(rcu_dynticks.dynticks_idle) & 0x1);
>  }
> 
>  /*
> @@ -2712,9 +2712,9 @@ static void rcu_sysidle_exit(int irq)
> 
>   /* Record end of idle period. */
>   smp_mb__before_atomic();
> - atomic_inc(>dynticks_idle);
> + this_cpu_inc(rcu_dynticks.dynticks_idle);
>   smp_mb__after_atomic();
> - WARN_ON_ONCE(!(atomic_read(>dynticks_idle) & 0x1));
> + WARN_ON_ONCE(!(__this_cpu_read(rcu_dynticks.dynticks_idle) & 0x1));
> 
>   /*
>* If we are the timekeeping CPU, we are permitted to be non-idle
> @@ -2755,7 +2755,7 @@ static void rcu_sysidle_check_cpu(struct
>   WARN_ON_ONCE(smp_processor_id() != tick_do_timer_cpu);
> 
>   /* Pick up current idle and NMI-nesting counter and check. */
> - cur = atomic_read(>dynticks_idle);
> + cur = rdtp->dynticks_idle;
>   if (cur & 0x1) {
>   *isidle = false; /* We are not idle! */
>   return;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] PM / sleep: Fix test_suspend= command line option

[Rafael J. Wysocki]

On Tuesday, September 02, 2014 09:43:49 AM Srinivas Pandruvada wrote:
> On Tue, 2014-09-02 at 01:37 +0200, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki 
> > 
> > After commit d431cbc53cb7 (PM / sleep: Simplify sleep states sysfs
> > interface code) the pm_states[] array is not populated initially,
> > which causes setup_test_suspend() to always fail and the suspend
> > testing during boot doesn't work any more.
> > 
> > Fix the problem by using pm_labels[] instead of pm_states[] in
> > setup_test_suspend() and storing a pointer to the label of the
> > sleep state to test rather than the number representing it,
> > because the connection between the state numbers and labels is
> > only established by suspend_set_ops().
> > 
> This is still causing panic when I applied to 3.17.rc2.
> Need further debug.

Well, it works for me, so it would be good to know some details.

Perhaps the one below works better?

Rafael

---
From: Rafael J. Wysocki 
Subject: PM / sleep: Fix test_suspend= command line option

After commit d431cbc53cb7 (PM / sleep: Simplify sleep states sysfs
interface code) the pm_states[] array is not populated initially,
which causes setup_test_suspend() to always fail and the suspend
testing during boot doesn't work any more.

Fix the problem by using pm_labels[] instead of pm_states[] in
setup_test_suspend() and storing a pointer to the label of the
sleep state to test rather than the number representing it,
because the connection between the state numbers and labels is
only established by suspend_set_ops().

Fixes: d431cbc53cb7 (PM / sleep: Simplify sleep states sysfs interface code)
Reported-by: Srinivas Pandruvada 
Signed-off-by: Rafael J. Wysocki 
---
 kernel/power/power.h|1 +
 kernel/power/suspend.c  |2 +-
 kernel/power/suspend_test.c |   31 +++
 3 files changed, 21 insertions(+), 13 deletions(-)

Index: linux-pm/kernel/power/power.h
===
--- linux-pm.orig/kernel/power/power.h
+++ linux-pm/kernel/power/power.h
@@ -179,6 +179,7 @@ extern void swsusp_show_speed(struct tim
 
 #ifdef CONFIG_SUSPEND
 /* kernel/power/suspend.c */
+extern const char *pm_labels[];
 extern const char *pm_states[];
 
 extern int suspend_devices_and_enter(suspend_state_t state);
Index: linux-pm/kernel/power/suspend.c
===
--- linux-pm.orig/kernel/power/suspend.c
+++ linux-pm/kernel/power/suspend.c
@@ -31,7 +31,7 @@
 
 #include "power.h"
 
-static const char *pm_labels[] = { "mem", "standby", "freeze", };
+const char *pm_labels[] = { "mem", "standby", "freeze", NULL };
 const char *pm_states[PM_SUSPEND_MAX];
 
 static const struct platform_suspend_ops *suspend_ops;
Index: linux-pm/kernel/power/suspend_test.c
===
--- linux-pm.orig/kernel/power/suspend_test.c
+++ linux-pm/kernel/power/suspend_test.c
@@ -129,20 +129,20 @@ static int __init has_wakealarm(struct d
  * at startup time.  They're normally disabled, for faster boot and because
  * we can't know which states really work on this particular system.
  */
-static suspend_state_t test_state __initdata = PM_SUSPEND_ON;
+static const char *test_state_label __initdata;
 
 static char warn_bad_state[] __initdata =
KERN_WARNING "PM: can't test '%s' suspend state\n";
 
 static int __init setup_test_suspend(char *value)
 {
-   suspend_state_t i;
+   int i;
 
/* "=mem" ==> "mem" */
value++;
-   for (i = PM_SUSPEND_MIN; i < PM_SUSPEND_MAX; i++)
-   if (!strcmp(pm_states[i], value)) {
-   test_state = i;
+   for (i = 0; pm_labels[i]; i++)
+   if (!strcmp(pm_labels[i], value)) {
+   test_state_label = pm_labels[i];
return 0;
}
 
@@ -158,13 +158,21 @@ static int __init test_suspend(void)
 
struct rtc_device   *rtc = NULL;
struct device   *dev;
+   suspend_state_t test_state;
 
/* PM is initialized by now; is that state testable? */
-   if (test_state == PM_SUSPEND_ON)
-   goto done;
-   if (!pm_states[test_state]) {
-   printk(warn_bad_state, pm_states[test_state]);
-   goto done;
+   if (!test_state_label)
+   return 0;
+
+   for (test_state = PM_SUSPEND_MIN; test_state < PM_SUSPEND_MAX; 
test_state++) {
+   const char *state_label = pm_states[test_state];
+
+   if (state_label && !strcmp(test_state_label, state_label))
+   break;
+   }
+   if (test_state == PM_SUSPEND_MAX) {
+   printk(warn_bad_state, test_state_label);
+   return 0;
}
 
/* RTCs have initialized by now too ... can we use one? */
@@ -173,13 +181,12 @@ static int __init test_suspend(void)
rtc = 

[RFC PATCH v6] tpm_tis: verify interrupt during init

[Scot Doyle]

On Tue, 2 Sep 2014, Jason Gunthorpe wrote:
> On Sat, Aug 30, 2014 at 11:23:56PM +, Scot Doyle wrote:
>> The output is now
>> [1.526798] tpm_tis 00:08: 1.2 TPM (device-id 0xB, rev-id 16)
>> [5.914732] tpm_tis 00:08: [Firmware Bug]: TPM interrupt not working, 
>> polling instead
>
> Cool, why did it take 4 seconds though?

It's spending that time (now 3 seconds) in tpm_tis_send_data.

Output is
[2.928481] tpm_tis 00:08: 1.2 TPM (device-id 0xB, rev-id 16)
[5.943468] tpm_tis 00:08: [Firmware Bug]: TPM interrupt not working, 
polling instead


> Looks really good to me, I can try and test the next version here this
> week.

Thanks!


---
diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index 2c46734..6e42d60 100644
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -75,6 +75,10 @@ enum tis_defaults {
 #defineTPM_DID_VID(l)  (0x0F00 | ((l) << 12))
 #defineTPM_RID(l)  (0x0F04 | ((l) << 12))

+struct priv_data {
+   bool irq_tested;
+};
+
 static LIST_HEAD(tis_chips);
 static DEFINE_MUTEX(tis_lock);

@@ -338,6 +342,21 @@ out_err:
return rc;
 }

+static void disable_interrupts(struct tpm_chip *chip)
+{
+   u32 intmask;
+   intmask =
+   ioread32(chip->vendor.iobase +
+TPM_INT_ENABLE(chip->vendor.locality));
+   intmask |= TPM_INTF_CMD_READY_INT | TPM_INTF_LOCALITY_CHANGE_INT |
+  TPM_INTF_DATA_AVAIL_INT | TPM_INTF_STS_VALID_INT;
+   iowrite32(intmask,
+ chip->vendor.iobase +
+ TPM_INT_ENABLE(chip->vendor.locality));
+   free_irq(chip->vendor.irq, chip);
+   chip->vendor.irq = 0;
+}
+
 /*
  * If interrupts are used (signaled by an irq set in the vendor structure)
  * tpm.c can skip polling for the data to be available as the interrupt is
@@ -345,8 +364,10 @@ out_err:
  */
 static int tpm_tis_send(struct tpm_chip *chip, u8 *buf, size_t len)
 {
-   int rc;
+   int rc, irq;
u32 ordinal;
+   bool test_irq;
+   struct priv_data *priv = chip->vendor.priv;

rc = tpm_tis_send_data(chip, buf, len);
if (rc < 0)
@@ -358,13 +379,30 @@ static int tpm_tis_send(struct tpm_chip *chip, u8 *buf, 
size_t len)

if (chip->vendor.irq) {
ordinal = be32_to_cpu(*((__be32 *) (buf + 6)));
-   if (wait_for_tpm_stat
-   (chip, TPM_STS_DATA_AVAIL | TPM_STS_VALID,
-tpm_calc_ordinal_duration(chip, ordinal),
->vendor.read_queue, false) < 0) {
+   test_irq = !priv->irq_tested;
+   if (test_irq) {
+   irq = chip->vendor.irq;
+   chip->vendor.irq = 0;
+   }
+   rc = wait_for_tpm_stat
+(chip, TPM_STS_DATA_AVAIL | TPM_STS_VALID,
+ tpm_calc_ordinal_duration(chip, ordinal),
+ >vendor.read_queue, false);
+   if (test_irq)
+   chip->vendor.irq = irq;
+   if (rc < 0) {
rc = -ETIME;
goto out_err;
}
+   if (test_irq) {
+   msleep(1);
+   if (!priv->irq_tested) {
+   disable_interrupts(chip);
+   dev_err(chip->dev,
+   FW_BUG "TPM interrupt not working, 
polling instead\n");
+   }
+   priv->irq_tested = true;
+   }
}
return len;
 out_err:
@@ -505,6 +543,7 @@ static irqreturn_t tis_int_handler(int dummy, void *dev_id)
if (interrupt == 0)
return IRQ_NONE;

+   ((struct priv_data*)chip->vendor.priv)->irq_tested = true;
if (interrupt & TPM_INTF_DATA_AVAIL_INT)
wake_up_interruptible(>vendor.read_queue);
if (interrupt & TPM_INTF_LOCALITY_CHANGE_INT)
@@ -534,10 +573,14 @@ static int tpm_tis_init(struct device *dev, 
resource_size_t start,
u32 vendor, intfcaps, intmask;
int rc, i, irq_s, irq_e, probe;
struct tpm_chip *chip;
+   struct priv_data *priv;

if (!(chip = tpm_register_hardware(dev, _tis)))
return -ENODEV;

+   priv = devm_kzalloc(dev, sizeof(struct priv_data), GFP_KERNEL);
+   chip->vendor.priv = priv;
+
chip->vendor.iobase = ioremap(start, len);
if (!chip->vendor.iobase) {
rc = -EIO;
@@ -605,19 +648,6 @@ static int tpm_tis_init(struct device *dev, 
resource_size_t start,
if (intfcaps & TPM_INTF_DATA_AVAIL_INT)
dev_dbg(dev, "\tData Avail Int Support\n");

-   /* get the timeouts before testing for irqs */
-   if (tpm_get_timeouts(chip)) {
-   dev_err(dev, "Could not get TPM timeouts and durations\n");
-   rc = -ENODEV;
-   goto out_err;

Re: [PATCH] net: calxedaxgmac: fix driver dependencies

[David Miller]

From: Bartlomiej Zolnierkiewicz 
Date: Mon, 01 Sep 2014 17:39:04 +0200

> Calxeda 1G/10G XGMAC Ethernet support should be available only on
> Calxeda ECX-1000/2000 (Highbank/Midway) platforms.
> 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> Acked-by: Kyungmin Park 

Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] net: sh_eth: fix driver dependencies

[David Miller]

From: Bartlomiej Zolnierkiewicz 
Date: Mon, 01 Sep 2014 16:25:35 +0200

> Renesas SuperH Ethernet support should be available only on
> Renesas ARM SoCs and SuperH architecture.
> 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> Acked-by: Kyungmin Park 

Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net: lpc_eth: Fix crash on ip link up

[David Miller]

From: sti...@antcom.de
Date: Mon,  1 Sep 2014 13:46:46 +0200

> From: Roland Stigge 
> 
> When a link is already up, the following sequence makes the kernel
> block completely:
> 
>   ip link set dev eth0 down
>   ip link set dev eth0 up
> 
> This is because on suspended phy, the following lines
> 
>   __lpc_eth_reset(pldat);
>   __lpc_eth_init(pldat);
> 
> make the LPC ethernet core block (see LPC32x0 manual). The PHY needs to be
> (re-)activated low-level first.
> 
> Signed-off-by: Roland Stigge 

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 23

[Peter Zijlstra]

On Tue, Sep 02, 2014 at 12:04:45PM -0700, Guenter Roeck wrote:

> I provided qemu images and instructions as follows.
>   http://server.roeck-us.net/qemu/mipsel/ MIPS 32 bit, little 
> endian
>   http://server.roeck-us.net/qemu/mips64el/   MIPS 64 bit, little 
> endian
> 
> Let me know if you also need big endian images.

Thanks! Does the below work? It appears to work for the mips64 build I did.
I'll send a proper patch tomorrow; sleep time :-)

---
diff --git a/arch/mips/configs/malta_defconfig 
b/arch/mips/configs/malta_defconfig
index e18741e..869efe7 100644
--- a/arch/mips/configs/malta_defconfig
+++ b/arch/mips/configs/malta_defconfig
@@ -441,3 +441,6 @@ CONFIG_CRYPTO_TEA=m
 CONFIG_CRYPTO_TWOFISH=m
 # CONFIG_CRYPTO_ANSI_CPRNG is not set
 CONFIG_CRC16=m
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_CPU_MIPS64_R1=y
+CONFIG_64BIT=y
diff --git a/arch/mips/include/asm/atomic.h b/arch/mips/include/asm/atomic.h
index 476fe3b..f3ee721 100644
--- a/arch/mips/include/asm/atomic.h
+++ b/arch/mips/include/asm/atomic.h
@@ -93,7 +93,7 @@ static __inline__ int atomic_##op##_return(int i, atomic_t * 
v)   \
"   " #asm_op " %0, %1, %3  \n" 
\
"   sc  %0, %2  \n" 
\
"   beqzl   %0, 1b  \n" 
\
-   "   addu%0, %1, %3  \n" 
\
+   "   " #asm_op " %0, %1, %3  \n" 
\
"   .setmips0   \n" 
\
: "=" (result), "=" (temp), "+m" (v->counter)   
\
: "Ir" (i));
\
@@ -111,7 +111,7 @@ static __inline__ int atomic_##op##_return(int i, atomic_t 
* v) \
: "Ir" (i));
\
} while (unlikely(!result));
\

\
-   result = temp + i;  
\
+   result = temp; result c_op i;   
\
} else {
\
unsigned long flags;
\

\
@@ -387,7 +387,7 @@ static __inline__ long atomic64_##op##_return(long i, 
atomic64_t * v)   \
: "memory");
\
} while (unlikely(!result));
\

\
-   result = temp + i;  
\
+   result = temp; result c_op i;   
\
} else {
\
unsigned long flags;
\

\

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: regression caused by cgroups optimization in 3.17-rc2

[Dave Hansen]

On 09/02/2014 12:05 PM, Dave Hansen wrote:
> It does not revert cleanly because of the hunks below.  The code in
> those hunks was removed, so I tried running without properly merging
> them and it spews warnings because counter->usage is seen going negative.
> 
> So, it doesn't appear we can quickly revert this.

I'm fairly confident that I missed some of the cases (especially in the
charge-moving code), but the attached patch does at least work around
the regression for me.  It restores the original performance, or at
least gets _close_ to it.




---

 b/mm/memcontrol.c |   14 ++
 1 file changed, 14 insertions(+)

diff -puN mm/memcontrol.c~try-partial-revert-of-root-charge-regression-patch mm/memcontrol.c
--- a/mm/memcontrol.c~try-partial-revert-of-root-charge-regression-patch	2014-09-02 12:20:11.209527453 -0700
+++ b/mm/memcontrol.c	2014-09-02 13:10:28.756736862 -0700
@@ -2534,6 +2534,8 @@ static int try_charge(struct mem_cgroup
 	unsigned long long size;
 	int ret = 0;
 
+	if (mem_cgroup_is_root(memcg))
+		goto done;
 retry:
 	if (consume_stock(memcg, nr_pages))
 		goto done;
@@ -2640,6 +2642,9 @@ static void __mem_cgroup_cancel_local_ch
 {
 	unsigned long bytes = nr_pages * PAGE_SIZE;
 
+	if (mem_cgroup_is_root(memcg))
+		return;
+
 	res_counter_uncharge_until(>res, memcg->res.parent, bytes);
 	if (do_swap_account)
 		res_counter_uncharge_until(>memsw,
@@ -6440,6 +6445,9 @@ void mem_cgroup_commit_charge(struct pag
 	VM_BUG_ON_PAGE(!page->mapping, page);
 	VM_BUG_ON_PAGE(PageLRU(page) && !lrucare, page);
 
+	if (mem_cgroup_is_root(memcg))
+		return;
+
 	if (mem_cgroup_disabled())
 		return;
 	/*
@@ -6484,6 +6492,9 @@ void mem_cgroup_cancel_charge(struct pag
 {
 	unsigned int nr_pages = 1;
 
+	if (mem_cgroup_is_root(memcg))
+		return;
+
 	if (mem_cgroup_disabled())
 		return;
 	/*
@@ -6509,6 +6520,9 @@ static void uncharge_batch(struct mem_cg
 {
 	unsigned long flags;
 
+	if (mem_cgroup_is_root(memcg))
+		return;
+
 	if (nr_mem)
 		res_counter_uncharge(>res, nr_mem * PAGE_SIZE);
 	if (nr_memsw)
_

Re: [PATCH 15/15] tty: serial: 8250: omap: add dma support

[Tony Lindgren]

* Sebastian Andrzej Siewior  [140902 11:40]:
> On 09/01/2014 07:47 PM, Sebastian Andrzej Siewior wrote:
> > Comparing it with serial-omap I see the same thing: I takes approx the
> > same amount of data until the first one is displayed. After a lot of
> > "long" writes which wake the chip up from idle I manage to freeze both,
> > the serial-omap driver and mine driver.
> 
> So after some testing:
> - it happens with omap-serial as well. Especially after disabling the
>   LED trigger for both LEDs.
> 
> - it seemed that disabling the MDR1 check whether or not we lost
>   context made the problem appear less often but it was a trick. Even
>   with restoring the context each time I see the same problem.
> 
> - it seems to be easier to trigger with the LED trigger switched off.
>   However sometimes it works for 10 minutes, sometimes it triggers
>   after one.
> 
> - I see to face two kind of "deaths":
>   - the LED still goes on and off and the uart just does not respond
> even if I tell the button print something on the screen (the button
> also changes the frequency of the LED so I know that the button is
> doing something).
> Also from dumping the content of /proc/interrupts it seems that a
> wake up is made, the uart should have restored the registers.

OK yeah this is the case I was seeing too. So do you just set the
LED triggers to none in sysfs to make it easier to reproduce?

>   - one where the system is dead and the LED does not blink anymore.
> Also my button is dead.

This I don't think I've seen. This could also be the errata issue on
your earlier rev beagleboard-xm with off-idle.
 
> - disabling DMA makes the problem not go away.

OK
 
> - mdelay(25) in omap8250_lost_context() is long enough to drop the 403
>   bytes I send in my testcase. That means I see only "good" characters.
>   With this the box remained alive for 2h. However the uart died anyway.

I wonder if doing some TX on the uart restores it? So maybe try

$ while [ 1 ]; do date; sleep 10 done &

To have it occasionally print something in the background.

Regards,

Tony

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[no subject]

[Andy King]

This version addresses Sergei's comments.

o Fixed description and added Reported-by
o Removed NULL check for kfree()

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC] dynticks: dynticks_idle is only modified locally use this_cpu ops

[Christoph Lameter]

Since dynticks_idle is only ever modified by the local cpu we do
not need to use an atomic there. The weak "atomicity" of this_cpu
ops is sufficient since there is no other cpu modifying the variable.

[This is a cautious patch that leaves the barriers in place]

Signed-off-by: Christoph Lameter 

Index: linux/kernel/rcu/tree.c
===
--- linux.orig/kernel/rcu/tree.c
+++ linux/kernel/rcu/tree.c
@@ -213,7 +213,7 @@ static DEFINE_PER_CPU(struct rcu_dyntick
.dynticks = ATOMIC_INIT(1),
 #ifdef CONFIG_NO_HZ_FULL_SYSIDLE
.dynticks_idle_nesting = DYNTICK_TASK_NEST_VALUE,
-   .dynticks_idle = ATOMIC_INIT(1),
+   .dynticks_idle = 1,
 #endif /* #ifdef CONFIG_NO_HZ_FULL_SYSIDLE */
 };

Index: linux/kernel/rcu/tree.h
===
--- linux.orig/kernel/rcu/tree.h
+++ linux/kernel/rcu/tree.h
@@ -91,7 +91,7 @@ struct rcu_dynticks {
 #ifdef CONFIG_NO_HZ_FULL_SYSIDLE
long long dynticks_idle_nesting;
/* irq/process nesting level from idle. */
-   atomic_t dynticks_idle; /* Even value for idle, else odd. */
+   long dynticks_idle; /* Even value for idle, else odd. */
/*  "Idle" excludes userspace execution. */
unsigned long dynticks_idle_jiffies;
/* End of last non-NMI non-idle period. */
Index: linux/kernel/rcu/tree_plugin.h
===
--- linux.orig/kernel/rcu/tree_plugin.h
+++ linux/kernel/rcu/tree_plugin.h
@@ -2644,9 +2644,9 @@ static void rcu_sysidle_enter(int irq)
j = jiffies;
ACCESS_ONCE(rdtp->dynticks_idle_jiffies) = j;
smp_mb__before_atomic();
-   atomic_inc(>dynticks_idle);
+   this_cpu_inc(rcu_dynticks.dynticks_idle);
smp_mb__after_atomic();
-   WARN_ON_ONCE(atomic_read(>dynticks_idle) & 0x1);
+   WARN_ON_ONCE(__this_cpu_read(rcu_dynticks.dynticks_idle) & 0x1);
 }

 /*
@@ -2712,9 +2712,9 @@ static void rcu_sysidle_exit(int irq)

/* Record end of idle period. */
smp_mb__before_atomic();
-   atomic_inc(>dynticks_idle);
+   this_cpu_inc(rcu_dynticks.dynticks_idle);
smp_mb__after_atomic();
-   WARN_ON_ONCE(!(atomic_read(>dynticks_idle) & 0x1));
+   WARN_ON_ONCE(!(__this_cpu_read(rcu_dynticks.dynticks_idle) & 0x1));

/*
 * If we are the timekeeping CPU, we are permitted to be non-idle
@@ -2755,7 +2755,7 @@ static void rcu_sysidle_check_cpu(struct
WARN_ON_ONCE(smp_processor_id() != tick_do_timer_cpu);

/* Pick up current idle and NMI-nesting counter and check. */
-   cur = atomic_read(>dynticks_idle);
+   cur = rdtp->dynticks_idle;
if (cur & 0x1) {
*isidle = false; /* We are not idle! */
return;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

rcu: Remove rcu_dynticks * parameters when they are always this_cpu_ptr(_dynticks)

[Christoph Lameter]

For some functions in kernel/rcu/tree* the rdtp parameter is always 
this_cpu_ptr(rdtp).
Remove the parameter if constant and calculate the pointer in function.

This will have the advantage that it is obvious that the address are all per cpu
offsets and thus it will enable the use of this_cpu_ops in the future.

Signed-off-by: Christoph Lameter 

Index: linux/kernel/rcu/tree.c
===
--- linux.orig/kernel/rcu/tree.c
+++ linux/kernel/rcu/tree.c
@@ -499,11 +499,11 @@ cpu_needs_another_gp(struct rcu_state *r
  * we really have entered idle, and must do the appropriate accounting.
  * The caller must have disabled interrupts.
  */
-static void rcu_eqs_enter_common(struct rcu_dynticks *rdtp, long long oldval,
-   bool user)
+static void rcu_eqs_enter_common(long long oldval, bool user)
 {
struct rcu_state *rsp;
struct rcu_data *rdp;
+   struct rcu_dynticks *rdtp = this_cpu_ptr(_dynticks);

trace_rcu_dyntick(TPS("Start"), oldval, rdtp->dynticks_nesting);
if (!user && !is_idle_task(current)) {
@@ -553,7 +553,7 @@ static void rcu_eqs_enter(bool user)
WARN_ON_ONCE((oldval & DYNTICK_TASK_NEST_MASK) == 0);
if ((oldval & DYNTICK_TASK_NEST_MASK) == DYNTICK_TASK_NEST_VALUE) {
rdtp->dynticks_nesting = 0;
-   rcu_eqs_enter_common(rdtp, oldval, user);
+   rcu_eqs_enter_common(oldval, user);
} else {
rdtp->dynticks_nesting -= DYNTICK_TASK_NEST_VALUE;
}
@@ -577,7 +577,7 @@ void rcu_idle_enter(void)

local_irq_save(flags);
rcu_eqs_enter(false);
-   rcu_sysidle_enter(this_cpu_ptr(_dynticks), 0);
+   rcu_sysidle_enter(0);
local_irq_restore(flags);
 }
 EXPORT_SYMBOL_GPL(rcu_idle_enter);
@@ -627,8 +627,8 @@ void rcu_irq_exit(void)
if (rdtp->dynticks_nesting)
trace_rcu_dyntick(TPS("--="), oldval, rdtp->dynticks_nesting);
else
-   rcu_eqs_enter_common(rdtp, oldval, true);
-   rcu_sysidle_enter(rdtp, 1);
+   rcu_eqs_enter_common(oldval, true);
+   rcu_sysidle_enter(1);
local_irq_restore(flags);
 }

@@ -639,9 +639,11 @@ void rcu_irq_exit(void)
  * we really have exited idle, and must do the appropriate accounting.
  * The caller must have disabled interrupts.
  */
-static void rcu_eqs_exit_common(struct rcu_dynticks *rdtp, long long oldval,
+static void rcu_eqs_exit_common(long long oldval,
   int user)
 {
+   struct rcu_dynticks *rdtp = this_cpu_ptr(_dynticks);
+
smp_mb__before_atomic();  /* Force ordering w/previous sojourn. */
atomic_inc(>dynticks);
/* CPUs seeing atomic_inc() must see later RCU read-side crit sects */
@@ -678,7 +680,7 @@ static void rcu_eqs_exit(bool user)
rdtp->dynticks_nesting += DYNTICK_TASK_NEST_VALUE;
} else {
rdtp->dynticks_nesting = DYNTICK_TASK_EXIT_IDLE;
-   rcu_eqs_exit_common(rdtp, oldval, user);
+   rcu_eqs_exit_common(oldval, user);
}
 }

@@ -699,7 +701,7 @@ void rcu_idle_exit(void)

local_irq_save(flags);
rcu_eqs_exit(false);
-   rcu_sysidle_exit(this_cpu_ptr(_dynticks), 0);
+   rcu_sysidle_exit(0);
local_irq_restore(flags);
 }
 EXPORT_SYMBOL_GPL(rcu_idle_exit);
@@ -750,8 +752,8 @@ void rcu_irq_enter(void)
if (oldval)
trace_rcu_dyntick(TPS("++="), oldval, rdtp->dynticks_nesting);
else
-   rcu_eqs_exit_common(rdtp, oldval, true);
-   rcu_sysidle_exit(rdtp, 1);
+   rcu_eqs_exit_common(oldval, true);
+   rcu_sysidle_exit(1);
local_irq_restore(flags);
 }

Index: linux/kernel/rcu/tree.h
===
--- linux.orig/kernel/rcu/tree.h
+++ linux/kernel/rcu/tree.h
@@ -595,8 +595,8 @@ static void rcu_boot_init_nocb_percpu_da
 static void rcu_spawn_nocb_kthreads(struct rcu_state *rsp);
 static void __maybe_unused rcu_kick_nohz_cpu(int cpu);
 static bool init_nocb_callback_list(struct rcu_data *rdp);
-static void rcu_sysidle_enter(struct rcu_dynticks *rdtp, int irq);
-static void rcu_sysidle_exit(struct rcu_dynticks *rdtp, int irq);
+static void rcu_sysidle_enter(int irq);
+static void rcu_sysidle_exit(int irq);
 static void rcu_sysidle_check_cpu(struct rcu_data *rdp, bool *isidle,
  unsigned long *maxj);
 static bool is_sysidle_rcu_state(struct rcu_state *rsp);
Index: linux/kernel/rcu/tree_plugin.h
===
--- linux.orig/kernel/rcu/tree_plugin.h
+++ linux/kernel/rcu/tree_plugin.h
@@ -2618,9 +2618,10 @@ static int full_sysidle_state;   /* Curre
  * to detect full-system idle states, not RCU quiescent states and grace
  * periods.  The caller must have disabled interrupts.
  */
-static void rcu_sysidle_enter(struct 

Re: [PATCH] pci/pci-sysfs: Set pci interface in uppercase

[Bjorn Helgaas]

On Tue, Sep 2, 2014 at 1:22 PM, Ricardo Ribalda Delgado
 wrote:
> Hej Bjorn
>
> I have seen that you have updated your pci tree without this patch. Is
> there something wrong with it?
>
> If you are already considering it, sorry for the mail, but I wanted to
> make sure that it is in 3.17 and then back ported.

I haven't even looked at it yet; I'm just starting to get caught up.
Since this looks like a fix for a very old bug, I'll probably apply it
for v3.18, and mark it for stable.

> On Wed, Aug 27, 2014 at 10:51 PM, Greg KH  wrote:
>> On Wed, Aug 27, 2014 at 01:23:01PM -0700, Greg KH wrote:
>>> On Wed, Aug 27, 2014 at 02:57:57PM +0200, Ricardo Ribalda Delgado wrote:
>>> > There is a missmatch between the way file2alias generates the modalias
>>> > and the way the pci driver generates it.
>>> >
>>> > Some implementations of modprobe will fail to load the driver for a pci
>>> > device automatically when the pci interface is defined on the driver. As
>>> > one will be in uppercase and the other in lowercase.
>>> >
>>> > Fortunatelly not many drivers define this.
>>> >
>>> > Signed-off-by: Ricardo Ribalda Delgado 
>>> > ---
>>> >  drivers/pci/pci-sysfs.c | 2 +-
>>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>>> >
>>> > diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
>>> > index 9ff0a90..76ef791 100644
>>> > --- a/drivers/pci/pci-sysfs.c
>>> > +++ b/drivers/pci/pci-sysfs.c
>>> > @@ -177,7 +177,7 @@ static ssize_t modalias_show(struct device *dev, 
>>> > struct device_attribute *attr,
>>> >  {
>>> > struct pci_dev *pci_dev = to_pci_dev(dev);
>>> >
>>> > -   return sprintf(buf, "pci:v%08Xd%08Xsv%08Xsd%08Xbc%02Xsc%02Xi%02x\n",
>>> > +   return sprintf(buf, "pci:v%08Xd%08Xsv%08Xsd%08Xbc%02Xsc%02Xi%02X\n",
>>> >pci_dev->vendor, pci_dev->device,
>>> >pci_dev->subsystem_vendor, pci_dev->subsystem_device,
>>> >(u8)(pci_dev->class >> 16), (u8)(pci_dev->class >> 8),
>>>
>>> As said in the other thread about this issue, no, this code has been
>>> here for over 9 years just fine.  Please fix your userspace code that is
>>> trying to compare hex values as a string and not a numeric value, that
>>> is the stuff that is wrong, not the kernel.
>>
>> Oh wait, I see what you are worried about now, the mis-match for just
>> the upper bits of the class value.
>>
>> Yeah, that's a bug, sorry about that, a 9+ year old one, nice catch :)
>>
>> Bjorn, feel free to apply this, sorry for the earlier objection.  Also
>> please mark it for stable tree inclusion so this gets backported
>> properly.
>>
>> thanks,
>>
>> greg k-h
>
>
>
> --
> Ricardo Ribalda
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] VMXNET3: Check for map error in vmxnet3_set_mc

[Andy King]

We should check if the map of the table actually succeeds, and also free
resources accordingly.

Version bumped to 1.2.1.0

Acked-by: Shelley Gong 
Acked-by: Bhavesh Davda 
Signed-off-by: Andy King 
Reported-by: Tetsuo Handa 
---
 drivers/net/vmxnet3/vmxnet3_drv.c |   15 ---
 drivers/net/vmxnet3/vmxnet3_int.h |4 ++--
 2 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c 
b/drivers/net/vmxnet3/vmxnet3_drv.c
index d6e90c7..6dfcbf5 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -2056,7 +2056,6 @@ vmxnet3_set_mc(struct net_device *netdev)
if (!netdev_mc_empty(netdev)) {
new_table = vmxnet3_copy_mc(netdev);
if (new_table) {
-   new_mode |= VMXNET3_RXM_MCAST;
rxConf->mfTableLen = cpu_to_le16(
netdev_mc_count(netdev) * ETH_ALEN);
new_table_pa = dma_map_single(
@@ -2064,15 +2063,18 @@ vmxnet3_set_mc(struct net_device *netdev)
new_table,
rxConf->mfTableLen,
PCI_DMA_TODEVICE);
+   }
+
+   if (new_table_pa) {
+   new_mode |= VMXNET3_RXM_MCAST;
rxConf->mfTablePA = cpu_to_le64(new_table_pa);
} else {
-   netdev_info(netdev, "failed to copy mcast list"
-   ", setting ALL_MULTI\n");
+   netdev_info(netdev,
+   "failed to copy mcast list, setting 
ALL_MULTI\n");
new_mode |= VMXNET3_RXM_ALL_MULTI;
}
}
 
-
if (!(new_mode & VMXNET3_RXM_MCAST)) {
rxConf->mfTableLen = 0;
rxConf->mfTablePA = 0;
@@ -2091,11 +2093,10 @@ vmxnet3_set_mc(struct net_device *netdev)
   VMXNET3_CMD_UPDATE_MAC_FILTERS);
spin_unlock_irqrestore(>cmd_lock, flags);
 
-   if (new_table) {
+   if (new_table_pa)
dma_unmap_single(>pdev->dev, new_table_pa,
 rxConf->mfTableLen, PCI_DMA_TODEVICE);
-   kfree(new_table);
-   }
+   kfree(new_table);
 }
 
 void
diff --git a/drivers/net/vmxnet3/vmxnet3_int.h 
b/drivers/net/vmxnet3/vmxnet3_int.h
index 29ee77f2..3759479 100644
--- a/drivers/net/vmxnet3/vmxnet3_int.h
+++ b/drivers/net/vmxnet3/vmxnet3_int.h
@@ -69,10 +69,10 @@
 /*
  * Version numbers
  */
-#define VMXNET3_DRIVER_VERSION_STRING   "1.2.0.0-k"
+#define VMXNET3_DRIVER_VERSION_STRING   "1.2.1.0-k"
 
 /* a 32-bit int, each byte encode a verion number in VMXNET3_DRIVER_VERSION */
-#define VMXNET3_DRIVER_VERSION_NUM  0x0102
+#define VMXNET3_DRIVER_VERSION_NUM  0x01020100
 
 #if defined(CONFIG_PCI_MSI)
/* RSS only makes sense if MSI-X is supported. */
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3] hwspinlock: qcom: Add support for Qualcomm HW Mutex block

[Bjorn Andersson]

From: Kumar Gala 

Add driver for Qualcomm Hardware Mutex block that exists on newer
Qualcomm SoCs.

Cc: Jeffrey Hugo 
Cc: Eric Holmberg 
Cc: Courtney Cavin 
Signed-off-by: Kumar Gala 
[bjorn: added pm_runtime calls, from Courtney,
added sfpb-mutex compatible,
updated DT binding documentation formatting,
based stride on resource size instead of hardcoded values,
replaced msm prefix with qcom,
cleaned up includes]
Signed-off-by: Bjorn Andersson 
---

We need this driver to add support for the shared memory manager, so I'm
reviving Kumars patch from a year ago, with some additional sprinkles on top.

Changes since v2:
 - MODULE_DEVICE_TABLE
 - Changed prefix to qcom
 - Cleaned up includes
 - Rely on reg and num-locks to figure out stride, instead of of_match data

Changes since v1:
 - Added the pm_runtime calls needed to be able to boot a kernel with
   pm_runtime and this driver, patch from Courtney.
 - Added sfpb-mutex compatible, for re-use of the driver in family A platforms.
 - Updated formatting of DT binding documentation, while adding the extra
   compatible.
 - Dropped Stephen Boyds Reviewed-by due to these changes.

 .../devicetree/bindings/hwlock/qcom-hwspinlock.txt |   35 +
 drivers/hwspinlock/Kconfig |   11 ++
 drivers/hwspinlock/Makefile|1 +
 drivers/hwspinlock/qcom_hwspinlock.c   |  147 
 4 files changed, 194 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt
 create mode 100644 drivers/hwspinlock/qcom_hwspinlock.c

diff --git a/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt 
b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt
new file mode 100644
index 000..27c7c80
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt
@@ -0,0 +1,35 @@
+Qualcomm Hardware Mutex Block:
+
+The hardware block provides mutexes utilized between different processors
+on the SoC as part of the communication protocol used by these processors.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be one of:
+   "qcom,sfpb-mutex",
+   "qcom,tcsr-mutex"
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: base address and size of the mutex registers
+
+- reg-names:
+   Usage: required
+   Value type: 
+   Definition: must be "mutex-base"
+
+- qcom,num-locks:
+   Usage: required
+   Value type: 
+   Definition: the number of locks/mutex available in this block
+
+Example:
+
+   hwlock@fd484000 {
+   compatible = "qcom,tcsr-mutex";
+   reg = <0xfd484000 0x1000>;
+   reg-names = "mutex-base";
+   qcom,num-locks = <32>;
+   };
diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
index 3612cb5..af4c7e6 100644
--- a/drivers/hwspinlock/Kconfig
+++ b/drivers/hwspinlock/Kconfig
@@ -8,6 +8,17 @@ config HWSPINLOCK
 
 menu "Hardware Spinlock drivers"
 
+config HWSPINLOCK_QCOM
+   tristate "Qualcomm Hardware Spinlock device"
+   depends on ARCH_QCOM
+   select HWSPINLOCK
+   help
+ Say y here to support the Qualcomm Hardware Mutex functionality, which
+ provides a synchronisation mechanism for the various processors on
+ the SoC.
+
+ If unsure, say N.
+
 config HWSPINLOCK_OMAP
tristate "OMAP Hardware Spinlock device"
depends on ARCH_OMAP4 || SOC_OMAP5 || SOC_DRA7XX || SOC_AM33XX || 
SOC_AM43XX
diff --git a/drivers/hwspinlock/Makefile b/drivers/hwspinlock/Makefile
index 93eb64b..f3bff48 100644
--- a/drivers/hwspinlock/Makefile
+++ b/drivers/hwspinlock/Makefile
@@ -3,5 +3,6 @@
 #
 
 obj-$(CONFIG_HWSPINLOCK)   += hwspinlock_core.o
+obj-$(CONFIG_HWSPINLOCK_QCOM)  += qcom_hwspinlock.o
 obj-$(CONFIG_HWSPINLOCK_OMAP)  += omap_hwspinlock.o
 obj-$(CONFIG_HSEM_U8500)   += u8500_hsem.o
diff --git a/drivers/hwspinlock/qcom_hwspinlock.c 
b/drivers/hwspinlock/qcom_hwspinlock.c
new file mode 100644
index 000..a9e5fa4
--- /dev/null
+++ b/drivers/hwspinlock/qcom_hwspinlock.c
@@ -0,0 +1,147 @@
+/*
+ * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2014, Sony Mobile Communications AB
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "hwspinlock_internal.h"
+
+#define SPINLOCK_ID_APPS_PROC  1
+#define 

Re: [PATCH] VMXNET3: Check for map error in vmxnet3_set_mc

[Sergei Shtylyov]

Hello.

On 09/02/2014 08:30 PM, Andy King wrote:


We should check if the map of the table actually succeeds, and also free
resources accordingly. This fixes the kernel panic reported by Tetsuo
Handa.


   There's "Reported-by:" line for that.


Version bumped to 1.2.1.0



Acked-by: Shelley Gong 
Acked-by: Bhavesh Davda 
Signed-off-by: Andy King 
---
  drivers/net/vmxnet3/vmxnet3_drv.c |   14 --
  drivers/net/vmxnet3/vmxnet3_int.h |4 ++--
  2 files changed, 10 insertions(+), 8 deletions(-)



diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c 
b/drivers/net/vmxnet3/vmxnet3_drv.c
index d6e90c7..f450010 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c

[...]

@@ -2091,11 +2093,11 @@ vmxnet3_set_mc(struct net_device *netdev)
   VMXNET3_CMD_UPDATE_MAC_FILTERS);
spin_unlock_irqrestore(>cmd_lock, flags);

-   if (new_table) {
+   if (new_table_pa)
dma_unmap_single(>pdev->dev, new_table_pa,
 rxConf->mfTableLen, PCI_DMA_TODEVICE);
+   if (new_table)
kfree(new_table);


   The above *if* is not needed -- kfree() already checks for NULL.

[...]

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 0/5] Add rockchip RK808 pmic driver

[Heiko Stübner]

Am Montag, 1. September 2014, 17:07:43 schrieb Chris Zhong:
> This is the initial version of the RK808 PMIC. This is a power management IC
> for multimedia products.
> 
> It provides regulators that are able to supply power to processor cores
> and other components. The chip provides other modules including RTC,
> Clockout

The whole series on a 3-17-rc1 with the already applied regulator commits 
pulled in and used by my pending cpufreq patches to set the core voltage

Tested-by: Heiko Stuebner 



> 
> Changes in v7:
> Advices by Mark Rutland
> - modify description about clock-cells
> - update the example
> Adviced by Lee Jones
> - coding style
> - remove rk808_pre_init function
> Adviced by Doug
> - add "&& OF" to the dependencies
> - add .init_ack_masked = true in rk808_irq_chip
> Adviced by doug
> - read rtc time from shadowed registers
> Adviced by Dmitry
> - use CONFIG_PM_SLEEP replace CONFIG_PM
> - use SIMPLE_DEV_PM_OPS replace dev_pm_ops
> - fix dev_warn
> - coding style
> Adviced by Heiko
> - remove rtc_ctl
> Adviced by doug
> -fix coding style problems
> - remove pdata struct from header file, add rk808_regulator struct
> 
> Changes in v6:
> Advices by Mark Rutland
> - add description about clock-cells
> Advices by Doug
> - modify description about regulator
> - remove pinctrl description
> Adviced by Lee Jones in v2
> - rk808_i2c_client instead of g_rk808
> - remove pdata form struct rk808
> Adviced by doug
> - move RTC_READSEL setting into probe
> Adviced by doug
> - use correct argument call of_clk_add_provider in probe
> - remove the redundant code
> 
> Changes in v5:
> Advices by Mark Brown
> - add description about regulator valid name.
> - add a header file "rockchip,rk808".
> - fixed a bug about set_time failed
> Adviced by doug
> - add some error checking in probe
> - move "rockchip,rk808.h" into the patch about dt-bindings
> - re-edit base on Mark's branch
> 
> Changes in v4:
> Advices by Doug
> - add a "#clock-cells" propertiy
> - update the example
> Adviced by Lee Jones in v2
> - modify the description in Kconfig
> - remove some unnecessary header files
> - remove dev from struct rk808
> - use enum for define RK808_ID...
> - use >dev replace rk808->dev
> Adviced by doug
> - add "clock-output-names" propertiey
> - add a header file "rockchip,rk808.h"
> - use >dev replace rk808->dev
> 
> Changes in v3:
> - fix compile err
> - fix compile err
> 
> Changes in v2:
> Adviced by Mark Browm:
> - use defines for register setting value
> - remove rtc alarm disable in shutdown
> - remove while(1) in shutdown
> - remove read 0x2f in probe
> Adviced by javier.martinez
> - Add a separate clock driver, rather than in RTC driver
> Adviced by javier.martinez
> - separated from rtc-rk808.c
> Adviced by Mark Browm:
> - change of_find_node_by_name to find_child_by_name
> - use RK808_NUM_REGULATORS as the name of the constant
> - create a pdata when missing platform data
> - use the rk808_reg name to supply_regulator name
> - replace regulator_register with devm_regulator_register
> - some other problem with coding style
> 
> Chris Zhong (5):
>   dt-bindings: Add RK808 device tree bindings document
>   MFD: RK808: Add new mfd driver for RK808
>   RTC: RK808: add RTC driver for RK808
>   clk: RK808: Add clkout driver for RK808
>   regulator: RK808: Remove pdata from the regulator
> 
>  Documentation/devicetree/bindings/mfd/rk808.txt |  166 +
>  drivers/clk/Kconfig |9 +
>  drivers/clk/Makefile|1 +
>  drivers/clk/clk-rk808.c |  160 +
>  drivers/mfd/Kconfig |   13 +
>  drivers/mfd/Makefile|1 +
>  drivers/mfd/rk808.c |  243 +
>  drivers/regulator/rk808-regulator.c |   52 ++-
>  drivers/rtc/Kconfig |   10 +
>  drivers/rtc/Makefile|1 +
>  drivers/rtc/rtc-rk808.c |  419
> +++ include/dt-bindings/clock/rockchip,rk808.h  |  
> 11 +
>  include/linux/mfd/rk808.h   |  196 +++
>  13 files changed, 1250 insertions(+), 32 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/mfd/rk808.txt
>  create mode 100644 drivers/clk/clk-rk808.c
>  create mode 100644 drivers/mfd/rk808.c
>  create mode 100644 drivers/rtc/rtc-rk808.c
>  create mode 100644 include/dt-bindings/clock/rockchip,rk808.h
>  create mode 100644 include/linux/mfd/rk808.h

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] locks: Ability to test for flock presence on fd

[Jeff Layton]

On Tue, 2 Sep 2014 15:43:00 -0400
"J. Bruce Fields"  wrote:

> On Tue, Sep 02, 2014 at 11:07:14PM +0400, Pavel Emelyanov wrote:
> > On 09/02/2014 10:44 PM, J. Bruce Fields wrote:
> > > On Tue, Sep 02, 2014 at 09:17:34PM +0400, Pavel Emelyanov wrote:
> > >> Hi,
> > >>
> > >> There's a problem with getting information about who has a flock on
> > >> a specific file. The thing is that the "owner" field, that is shown in
> > >> /proc/locks is the pid of the task who created the flock, not the one
> > >> who _may_ hold it.
> > >>
> > >> If the flock creator shared the file with some other task (by forking
> > >> or via scm_rights) and then died or closed the file, the information
> > >> shown in proc no longer corresponds to the reality.
> > >>
> > >> This is critical for CRIU project, that tries to dump (and restore)
> > >> the state of running tasks. For example, let's take two tasks A and B
> > >> both opened a file "/foo", one of tasks places a LOCK_SH lock on the 
> > >> file and then "obfuscated" the owner field in /proc/locks. After this
> > >> we have no ways to find out who is the lock holder.
> > >>
> > >> I'd like to note, that for LOCK_EX this problem is not critical -- we
> > >> may go to both tasks and "ask" them to LOCK_EX the file again (we can
> > >> do it in CRIU, I can tell more if required). The one who succeeds is 
> > >> the lock holder.
> > > 
> > > It could be both, actually, right?
> > 
> > Two succeeding with LOCK_EX? AFAIU no. Am I missing something?
> 
> After a fork, two processes "own" the lock, right?:
> 
>   int main(int argc, char *argv[])
>   {
>   int fd, ret;
>   
>   fd = open(argv[1], O_RDWR);
>   ret = flock(fd, LOCK_EX);
>   if (ret)
>   err(1, "flock");
>   ret = fork();
>   if (ret == -1)
>   err(1, "flock");
>   ret = flock(fd, LOCK_EX);
>   if (ret)
>   err(1, "flock");
>   printf("%d got exclusive lock\n", getpid());
>   sleep(1000);
>   }
> 
>   $ touch TMP
>   $ ./test TMP
>   15882 got exclusive lock
>   15883 got exclusive lock
>   ^C
> 
> I may misunderstand what you're doing.
> 

Yeah, I don't understand either.

Flock locks are owned by the file description. The task that set
them is really irrelevant once they are set.

In the second flock() call there, you're just "modifying" an existing
lock (which turns out to be a noop here).

So, I don't quite understand the problem this solves. I get that you're
trying to reestablish the flock "state" after a checkpoint/restore
event, but why does it matter what task actually sets the locks as long
as they're set on the correct set of fds?

> > >> With LOCK_SH this doesn't work. Trying to drop the
> > >> lock doesn't work either, as flock(LOCK_UN) reports 0 in both cases:
> > >> if the file is locked and if it is not.
> > >>
> > >> That said, I'd like to propose the LOCK_TEST flag to the flock call,
> > >> that would check whether the lock of the given type (LOCK_SH or LOCK_EX)
> > >> exists on the file we test. It's not the same as the existing in-kernel
> > >> FL_ACCESS flag, which checks whether the new lock is possible, but
> > >> it's a new FL_TEST flag, that checks whether the existing lock is there.
> > >>
> > >> What do you think?
> > > 
> > > I guess I can't see anything really wrong with it.
> > > 
> > > It ignores the (poorly documented) LOCK_MAND case, but maybe that's OK.
> > 
> > I actually checked it and it seemed to work. What problems do
> > you see with this case?
> 
> On its own it just doesn't tell you whether or not LOCK_MAND is set.
> But I guess you can still get that out of /proc/locks.
> 
> To be honest I don't really know whether LOCK_MAND works or is used.
> 
> --b.


-- 
Jeff Layton 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How is pivot_root intended to be used?

[Andy Lutomirski]

On 09/01/2014 02:19 PM, Steven Stewart-Gallus wrote:

Hello,

I am not confused about how I can currently use pivot_root for
containers on my kernel (version 3.13). Currently a sequence like:

 if (-1 == syscall(__NR_pivot_root, ".", ".")) {
 perror("pivot_root");
 return EXIT_FAILURE;
 }

 if (-1 == umount2(".", MNT_DETACH)) {
 perror("umount");
 return EXIT_FAILURE;


Given the comment, you don't know what '.' refers to in the umount2 call 
above.  In fact, I think you're actually detaching the wrong thing, 
leaving possible security issues.


See:

https://github.com/sandstorm-io/sandstorm/blob/master/src/sandstorm/supervisor-main.c%2B%2B#L922

for a program that does this more carefully.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] Add input supplies to rk808 regulator

[Doug Anderson]

Heiko,

On Tue, Sep 2, 2014 at 12:48 PM, Heiko Stübner  wrote:
> Am Dienstag, 2. September 2014, 09:14:27 schrieb Doug Anderson:
>> We want to specify the input supplies to the rk808 regulator.  This
>> patch series adds them to the driver.  Note that the bindings are
>> based atop Chris's most recent version at
>> .  If the regulator patch
>> is applied before Chris sends out his next version then I think Chris
>> could squash my bindings change (patch 2) into his next version.
>>
>>
>> Doug Anderson (2):
>>   regulator: RK808: Add proper input supplies for rk808
>
> Patch 1 didn't apply, as it didn't take the recent pdata removal Chris
> posted. After fixing this [0], it sucessfully solved the missing supplies
> I've seen on the weekend, so
>
> Tested-by: Heiko Stuebner 

Thanks!  ...ah, I guess I usually apply things with "git am -3" and it
didn't complain about applying my patch atop Chris's or not atop
Chris's.  Sorry for not making it clear.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] Add input supplies to rk808 regulator

[Heiko Stübner]

Am Dienstag, 2. September 2014, 09:14:27 schrieb Doug Anderson:
> We want to specify the input supplies to the rk808 regulator.  This
> patch series adds them to the driver.  Note that the bindings are
> based atop Chris's most recent version at
> .  If the regulator patch
> is applied before Chris sends out his next version then I think Chris
> could squash my bindings change (patch 2) into his next version.
> 
> 
> Doug Anderson (2):
>   regulator: RK808: Add proper input supplies for rk808

Patch 1 didn't apply, as it didn't take the recent pdata removal Chris
posted. After fixing this [0], it sucessfully solved the missing supplies
I've seen on the weekend, so

Tested-by: Heiko Stuebner 


>   dt-bindings: Add input supplies to rk808 bindings
> 
>  Documentation/devicetree/bindings/mfd/rk808.txt | 11 +++
>  drivers/regulator/rk808-regulator.c | 15 ++-
>  2 files changed, 25 insertions(+), 1 deletion(-)



[0]
--- "[PATCH 1_2] regulator_RK808_Add proper input supplies for rk808.mbox.orig" 
2014-09-02 20:49:12.0 +0200
+++ "[PATCH 1_2] regulator_RK808_Add proper input supplies for rk808.mbox"  
2014-09-02 21:22:57.052197875 +0200
@@ -203,7 +203,7 @@
.type = REGULATOR_VOLTAGE,
 @@ -364,7 +378,6 @@ static int rk808_regulator_probe(struct platform_device 
*pdev)
if (client->dev.of_node)
-   config.of_node = pdata->of_node[i];
+   config.of_node = rk808_regulator->of_node[i];
  
 -  reg_data->supply_regulator = rk808_reg[i].name;
config.init_data = reg_data;

As Chris is supposed to merge these changes into his series, this doesn't
really matter though.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] locks: Ability to test for flock presence on fd

[J. Bruce Fields]

On Tue, Sep 02, 2014 at 11:07:14PM +0400, Pavel Emelyanov wrote:
> On 09/02/2014 10:44 PM, J. Bruce Fields wrote:
> > On Tue, Sep 02, 2014 at 09:17:34PM +0400, Pavel Emelyanov wrote:
> >> Hi,
> >>
> >> There's a problem with getting information about who has a flock on
> >> a specific file. The thing is that the "owner" field, that is shown in
> >> /proc/locks is the pid of the task who created the flock, not the one
> >> who _may_ hold it.
> >>
> >> If the flock creator shared the file with some other task (by forking
> >> or via scm_rights) and then died or closed the file, the information
> >> shown in proc no longer corresponds to the reality.
> >>
> >> This is critical for CRIU project, that tries to dump (and restore)
> >> the state of running tasks. For example, let's take two tasks A and B
> >> both opened a file "/foo", one of tasks places a LOCK_SH lock on the 
> >> file and then "obfuscated" the owner field in /proc/locks. After this
> >> we have no ways to find out who is the lock holder.
> >>
> >> I'd like to note, that for LOCK_EX this problem is not critical -- we
> >> may go to both tasks and "ask" them to LOCK_EX the file again (we can
> >> do it in CRIU, I can tell more if required). The one who succeeds is 
> >> the lock holder.
> > 
> > It could be both, actually, right?
> 
> Two succeeding with LOCK_EX? AFAIU no. Am I missing something?

After a fork, two processes "own" the lock, right?:

int main(int argc, char *argv[])
{
int fd, ret;

fd = open(argv[1], O_RDWR);
ret = flock(fd, LOCK_EX);
if (ret)
err(1, "flock");
ret = fork();
if (ret == -1)
err(1, "flock");
ret = flock(fd, LOCK_EX);
if (ret)
err(1, "flock");
printf("%d got exclusive lock\n", getpid());
sleep(1000);
}

$ touch TMP
$ ./test TMP
15882 got exclusive lock
15883 got exclusive lock
^C

I may misunderstand what you're doing.

> >> With LOCK_SH this doesn't work. Trying to drop the
> >> lock doesn't work either, as flock(LOCK_UN) reports 0 in both cases:
> >> if the file is locked and if it is not.
> >>
> >> That said, I'd like to propose the LOCK_TEST flag to the flock call,
> >> that would check whether the lock of the given type (LOCK_SH or LOCK_EX)
> >> exists on the file we test. It's not the same as the existing in-kernel
> >> FL_ACCESS flag, which checks whether the new lock is possible, but
> >> it's a new FL_TEST flag, that checks whether the existing lock is there.
> >>
> >> What do you think?
> > 
> > I guess I can't see anything really wrong with it.
> > 
> > It ignores the (poorly documented) LOCK_MAND case, but maybe that's OK.
> 
> I actually checked it and it seemed to work. What problems do
> you see with this case?

On its own it just doesn't tell you whether or not LOCK_MAND is set.
But I guess you can still get that out of /proc/locks.

To be honest I don't really know whether LOCK_MAND works or is used.

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v11 11/19] irqchip: vic: Add support for FIQ management

[Russell King - ARM Linux]

On Tue, Sep 02, 2014 at 02:00:45PM +0100, Daniel Thompson wrote:
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index bda5a91..8821160 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -502,13 +502,17 @@ static void __init gic_init_fiq(struct gic_chip_data 
> *gic,
>  /*
>   * Fully acknowledge (both ack and eoi) a FIQ-based IPI
>   */
> -static int gic_handle_fiq_ipi(struct notifier_block *nb, unsigned long regs,
> -void *data)
> +void gic_handle_fiq_ipi(void)
>  {
>   struct gic_chip_data *gic = _data[0];
> - void __iomem *cpu_base = gic_data_cpu_base(gic);
> + void __iomem *cpu_base;
>   unsigned long irqstat, irqnr;
>  
> + if (!gic || !gic->fiq_enable)
> + return;
> +
> + cpu_base = gic_data_cpu_base(gic);
> +
>   if (WARN_ON(!in_nmi()))
>   return NOTIFY_BAD;
>  
> @@ -525,13 +529,6 @@ static int gic_handle_fiq_ipi(struct notifier_block *nb, 
> unsigned long regs,
>  
>   return NOTIFY_OK;
>  }
> -
> -/*
> - * Notifier to ensure IPI FIQ is acknowledged correctly.
> - */
> -static struct notifier_block gic_fiq_ipi_notifier = {
> - .notifier_call = gic_handle_fiq_ipi,
> -};
>  #else /* CONFIG_FIQ */
>  static inline void gic_set_group_irq(void __iomem *base, unsigned int hwirq,
>int group) {}
> @@ -1250,10 +1247,6 @@ void __init gic_init_bases(unsigned int gic_nr, int 
> irq_start,
>  #ifdef CONFIG_SMP
>   set_smp_cross_call(gic_raise_softirq);
>   register_cpu_notifier(_cpu_notifier);
> -#ifdef CONFIG_FIQ
> - if (gic_data_fiq_enable(gic))
> - register_fiq_nmi_notifier(_fiq_ipi_notifier);
> -#endif
>  #endif
>   set_handle_irq(gic_handle_irq);
>   }

Shouldn't this be merged into some other patch?

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 03/12] of: Add binding document for MIPS GIC

[Andrew Bresticker]

On Tue, Sep 2, 2014 at 10:27 AM, David Daney  wrote:
> On 08/29/2014 03:14 PM, Andrew Bresticker wrote:
>>
>> The Global Interrupt Controller (GIC) present on certain MIPS systems
>> can be used to route external interrupts to individual VPEs and CPU
>> interrupt vectors.  It also supports a timer and software-generated
>> interrupts.
>>
>> Signed-off-by: Andrew Bresticker 
>> ---
>>   Documentation/devicetree/bindings/mips/gic.txt | 50
>> ++
>>   1 file changed, 50 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/mips/gic.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mips/gic.txt
>> b/Documentation/devicetree/bindings/mips/gic.txt
>> new file mode 100644
>> index 000..725f1ef
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mips/gic.txt
>> @@ -0,0 +1,50 @@
>> +MIPS Global Interrupt Controller (GIC)
>> +
>> +The MIPS GIC routes external interrupts to individual VPEs and IRQ pins.
>> +It also supports a timer and software-generated interrupts which can be
>> +used as IPIs.
>> +
>> +Required properties:
>> +- compatible : Should be "mti,global-interrupt-controller"
>> +- reg : Base address and length of the GIC registers.
>> +- interrupts : Core interrupts to which the GIC may route external
>> interrupts.
>
>
> This doesn't make sense to me.  The GIC can, and does, route interrupts to
> all CPU cores in a SMP system.  How can there be a concept of only
> associating it with several interrupt lines on a single CPU in the system?
> That is not what the GIC does, is it?  It is a Global interrupts controller,
> not local.  So specifying device tree bindings that don't show its Global
> nature seems wrong.

While the GIC can route external interrupts to any HW interrupt vector
it may not make sense to actually use all those vectors.  For example,
the CP0 timer is usually hooked up to HW vector 5 (it could be treated
as a GIC local interrupt, though it may still be fixed to HW vector
5).  BTW, the Malta example about the i8259 I gave before was wrong -
it appears that it actually gets chained with the GIC.

What would you suggest instead?  Route all GIC interrupts to a single
vector?  Attempt to distribute them over all 6 vectors?

>> +- interrupt-controller : Identifies the node as an interrupt controller
>> +- #interrupt-cells : Specifies the number of cells needed to encode an
>> +  interrupt specifier.  Should be 3.
>> +  - The first cell is the GIC interrupt number.
>> +  - The second cell encodes the interrupt flags.
>> +See  for a list of
>> valid
>> +flags.
>> +  - The optional third cell indicates which CPU interrupt vector the GIC
>> +interrupt should be routed to.  It is a 0-based index into the list
>> of
>> +GIC-to-CPU interrupts specified in the "interrupts" property
>> described
>> +above.  For example, a '2' in this cell will route the interrupt to
>> the
>> +3rd core interrupt listed in 'interrupts'.  If omitted, the interrupt
>> will
>> +be routed to the 1st core interrupt.
>> +
>
>
> This seems like a really convoluted way of doing things that really goes
> against the device tree model.
>
> The routing of interrupts through the GIC to a core interrupt is controlled
> entirely within the GIC hardware and therefore should be a property of the
> GIC itself, not all the random devices connected upstream to the GIC.
>
> It also places policy about the priority of the various interrupts into the
> device tree.  Typically the device tree would contain only information about
> the topology of the hardware blocks, not arbitrary policy decisions that
> software could change and still have a perfectly functional system.
>
> Therefore I would recommend removing the third cell from the interrupt
> specifier.

As Mark mentioned, putting priority policy in the DT is a bit of a
gray area.  Since I don't see any need for it currently, I've decided
to drop it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v11 07/19] irqchip: gic: Add support for FIQ management

[Russell King - ARM Linux]

On Tue, Sep 02, 2014 at 02:00:41PM +0100, Daniel Thompson wrote:
> +static void gic_enable_fiq(struct irq_data *d)
> +{
> + gic_set_group_irq(d, 0);
> +}
> +
> +static void gic_disable_fiq(struct irq_data *d)
> +{
> + gic_set_group_irq(d, 1);
> +}

I think both the above functions should also call gic_unmask_irq() and
gic_mask_irq() directly rather than looping through enable_irq()/
disable_irq().

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 1/1] drivers: introduce ARM SBSA generic UART driver

[Arnd Bergmann]

On Tuesday 02 September 2014 12:38:23 Rob Herring wrote:
> On Tue, Sep 2, 2014 at 8:48 AM, Arnd Bergmann  wrote:
> > On Tuesday 02 September 2014 08:20:53 Rob Herring wrote:
> >> >>
> >> >> This alone is not okay. There is no such implementation of hardware.
> >> >
> >> > But the SBSA explicitly allows this. I don't know of any vendor who just
> >> > implements the subset, but I've been told that this has been asked for.
> >>
> >> To use baudrate as an example, that must be configurable somehow
> >> either with pl011 registers or in a vendor specific way. I suppose you
> >> could do an actual implementation with all those things hardcoded in
> >> the design, but that seems unlikely.
> >
> > Why does the baudrate need to be configurable? I think it's completely
> > reasonable to specify a console port that has a fixed (as in the
> > OS must not care) rate, and that can be implemented either as a UART
> > with a programmable rate or as a set of registers that directly talks
> > to a remote system management device over whatever hardware protocol
> > they choose.
> 
> Sure. It is also completely reasonable that baudrate is configurable
> and vendors can implement it however they choose since the SBSA does
> not specify it. IIRC, the enabling and disabling bits are not
> specified either.
> 
> Not having configurability is simply one variation on possible
> implementations.

It's not obvious to me though that we are served better by a
pl011 driver that allows any possible subset of the features,
rather than having the existing driver for pl011, and a new driver
for the sbsa subset, which then won't allow any of the optional
features.

Yes, there is some duplication, but a driver for this kind of
dumb console port should be doable in very little code, at
least less than the proposed implementation.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v11 06/19] irqchip: gic: Provide support for interrupt grouping

[Russell King - ARM Linux]

On Tue, Sep 02, 2014 at 02:00:40PM +0100, Daniel Thompson wrote:
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index 4b959e6..423707c 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -41,6 +41,9 @@
>  #include 
>  
>  #include 
> +#ifdef CONFIG_FIQ
> +#include 
> +#endif

Is there much advantage to this ifdef over providing a dummy asm/fiq.h
in ARM64?

>  #include 
>  #include 
>  #include 
> @@ -68,6 +71,9 @@ struct gic_chip_data {
>  #ifdef CONFIG_GIC_NON_BANKED
>   void __iomem *(*get_base)(union gic_base *);
>  #endif
> +#ifdef CONFIG_FIQ
> + bool fiq_enable;
> +#endif
>  };
>  
>  static DEFINE_RAW_SPINLOCK(irq_controller_lock);
> @@ -131,6 +137,16 @@ static inline void gic_set_base_accessor(struct 
> gic_chip_data *data,
>  #define gic_set_base_accessor(d, f)
>  #endif
>  
> +#ifdef CONFIG_FIQ
> +static inline bool gic_data_fiq_enable(struct gic_chip_data *data)
> +{
> + return data->fiq_enable;
> +}
> +#else
> +static inline bool gic_data_fiq_enable(
> + struct gic_chip_data *data) { return false; }

I really hate this style.  Just lay it out as a normal function.

> + /*
> +  * If grouping is not available (not implemented or prohibited by
> +  * security mode) these registers a read-as-zero/write-ignored.
> +  * However as a precaution we restore the reset default regardless of
> +  * the result of the test.
> +  */

Have we found that this additional complexity is actually necessary?
If not, we're over-engineering the code, making it more complex (and
hence more likely to be buggy) for very little reason.

Last night, I booted an unconditional version of this on OMAP3430, and
OMAP4430.  It's also been booted on the range of iMX6 CPUs.  Nothing
here has shown any signs of problems to having these registers written.

> + /*
> +  * Set EnableGrp1/EnableGrp0 (bit 1 and 0) or EnableGrp (bit 0 only,
> +  * bit 1 ignored)
> +  */
> + if (gic_data_fiq_enable(gic))
> + writel_relaxed(3, base + GIC_DIST_CTRL);
> + else
> + writel_relaxed(1, base + GIC_DIST_CTRL);

If we are going to do this conditionally, and the only thing which
is variable is the value to be written, I much prefer the conditional
bit to be on the value and not the write.  The compiler doesn't always
optimise these things very well.  So:

writel_relaxed(gic_data_fiq_enable(gic) ? 3 : 1, base + GIC_DIST_CTRL);

works well enough for me.  If you feel better by using a temporary
local, that works for me too.

> + if (gic_data_fiq_enable(gic))
> + writel_relaxed(0x1f, base + GIC_CPU_CTRL);
> + else
> + writel_relaxed(1, base + GIC_CPU_CTRL);

Same here.

> @@ -485,7 +564,10 @@ static void gic_dist_restore(unsigned int gic_nr)
>   writel_relaxed(gic_data[gic_nr].saved_spi_enable[i],
>   dist_base + GIC_DIST_ENABLE_SET + i * 4);
>  
> - writel_relaxed(1, dist_base + GIC_DIST_CTRL);
> + if (gic_data_fiq_enable(_data[gic_nr]))
> + writel_relaxed(3, dist_base + GIC_DIST_CTRL);
> + else
> + writel_relaxed(1, dist_base + GIC_DIST_CTRL);

And here.

> @@ -542,7 +624,7 @@ static void gic_cpu_restore(unsigned int gic_nr)
>   writel_relaxed(0xa0a0a0a0, dist_base + GIC_DIST_PRI + i * 4);
>  
>   writel_relaxed(0xf0, cpu_base + GIC_CPU_PRIMASK);
> - writel_relaxed(1, cpu_base + GIC_CPU_CTRL);
> + writel_relaxed(0x1f, cpu_base + GIC_CPU_CTRL);

Interestingly, here you write 0x1f unconditionally.
>  }
>  
>  static int gic_notifier(struct notifier_block *self, unsigned long cmd,  
> void *v)
> @@ -604,6 +686,7 @@ static void gic_raise_softirq(const struct cpumask *mask, 
> unsigned int irq)
>  {
>   int cpu;
>   unsigned long flags, map = 0;
> + unsigned long softint;
>  
>   raw_spin_lock_irqsave(_controller_lock, flags);
>  
> @@ -618,7 +701,11 @@ static void gic_raise_softirq(const struct cpumask 
> *mask, unsigned int irq)
>   dmb(ishst);
>  
>   /* this always happens on GIC0 */
> - writel_relaxed(map << 16 | irq, gic_data_dist_base(_data[0]) + 
> GIC_DIST_SOFTINT);
> + softint = map << 16 | irq;
> + if (gic_data_fiq_enable(_data[0]))
> + softint |= 0x8000;

I guess that this always has to be done conditionally.  I'd prefer this
test to be done slightly differently (and we might as well wrap in a bit
of patch 9 here):

if (sgi_is_nonsecure(irq, _data[0]))
softint |= 0x8000;

which follows the true purpose of that bit.  This bit only has effect if
we are running in secure mode, where it must match the status of the
target interrupt (as programmed into GIC_DIST_IGROUP).

We probably should do this based on a bitmask of SGIs in the
gic_chip_data, which is initialised according to how we've been able
to setup the GIC_DIST_IGROUP register(s).

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps 

Re: [PATCH] pci/probe: Enable CRS for Intel Haswell root ports

[Linus Torvalds]

On Mon, Sep 1, 2014 at 9:14 PM, Bjorn Helgaas  wrote:
>
> I'm not a fan of adding a whitelist for devices that work correctly.
> I don't think that's a maintainable solution.  Since we haven't had
> many systems yet that care about CRS, some kind of "enable CRS on
> machines newer than X" might work.

I'd suggest trying to just enable CRS unconditionally (ie revert my
old commit ad7edfe04908). We've done other changes in this area since,
and in particular, it's entirely possible that the original problem we
had doesn't even trigger any more.

In particular, looking at one of the old reports, I don't see that
"Device %04x:%02x:%02x.%d not responding" warning that we *should*
have triggered in pci_scan_device(). So I wonder if we had some case
that read the vendor ID without that whole loop, and that _that_ was
our fundamental problem.

It would be great if somebody could test with the old hardware that
triggered the problem originally, but those reports are from 2007, so
it might be hard to find anything relevant today. But trying to just
go back to unconditionally enabling CRS (say, in 3.18-rc1) and seeing
if anybody hollers, might just be the right approach.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [REGRESSION] "efi: efistub: Convert into static library" and preparation patches

[Matt Fleming]

On Tue, 02 Sep, at 05:25:58PM, Maarten Lankhorst wrote:
> Hey,
> 
> My macbook pro 8.2 fails to do a efi stub boot with these patches.
> 
> Commit f23cf8bd5c1f49 "efi/x86: efistub: Move shared dependencies to 
> "
> causes the first break, but this can be averted by changing
> 
> struct efi_config *efi_early;
> 
> to
> 
> struct efi_config *efi_early __attribute__((visibility("hidden")));
 
Weird. That sounds like a bug in the Apple EFI PE loader. Does any other
visibility result in a working kernel?

> I also need to revert commit f4f75ad5741fe "efi: efistub: Convert into static 
> library"
> to get boot working.
 
I'll take a look at the symbol changes between these commits and try and
guess what's going on.

> I'm not an early boot expert, so I have no idea what's going on here.
> Only console output I see when the boot fails is "setup_efi_pci() failed!" 
> after
> the commit that adds this message.

Yeah, that should be unrelated.

Thanks for the report.

-- 
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] staging: android: use braces on all arms of if

[Grzegorz Swirski]

Signed-off-by: Grzegorz Swirski 
---
 drivers/staging/android/sync.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 0d37495..c5255dc 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -387,9 +387,9 @@ int sync_fence_wait(struct sync_fence *fence, long timeout)
   timeout);
trace_sync_wait(fence, 0);
 
-   if (ret < 0)
+   if (ret < 0) {
return ret;
-   else if (ret == 0) {
+   } else if (ret == 0) {
if (timeout) {
pr_info("fence timeout on [%p] after %dms\n", fence,
jiffies_to_msecs(timeout));
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pci/pci-sysfs: Set pci interface in uppercase

[Ricardo Ribalda Delgado]

Hej Bjorn

I have seen that you have updated your pci tree without this patch. Is
there something wrong with it?

If you are already considering it, sorry for the mail, but I wanted to
make sure that it is in 3.17 and then back ported.


Thanks!!

On Wed, Aug 27, 2014 at 10:51 PM, Greg KH  wrote:
> On Wed, Aug 27, 2014 at 01:23:01PM -0700, Greg KH wrote:
>> On Wed, Aug 27, 2014 at 02:57:57PM +0200, Ricardo Ribalda Delgado wrote:
>> > There is a missmatch between the way file2alias generates the modalias
>> > and the way the pci driver generates it.
>> >
>> > Some implementations of modprobe will fail to load the driver for a pci
>> > device automatically when the pci interface is defined on the driver. As
>> > one will be in uppercase and the other in lowercase.
>> >
>> > Fortunatelly not many drivers define this.
>> >
>> > Signed-off-by: Ricardo Ribalda Delgado 
>> > ---
>> >  drivers/pci/pci-sysfs.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
>> > index 9ff0a90..76ef791 100644
>> > --- a/drivers/pci/pci-sysfs.c
>> > +++ b/drivers/pci/pci-sysfs.c
>> > @@ -177,7 +177,7 @@ static ssize_t modalias_show(struct device *dev, 
>> > struct device_attribute *attr,
>> >  {
>> > struct pci_dev *pci_dev = to_pci_dev(dev);
>> >
>> > -   return sprintf(buf, "pci:v%08Xd%08Xsv%08Xsd%08Xbc%02Xsc%02Xi%02x\n",
>> > +   return sprintf(buf, "pci:v%08Xd%08Xsv%08Xsd%08Xbc%02Xsc%02Xi%02X\n",
>> >pci_dev->vendor, pci_dev->device,
>> >pci_dev->subsystem_vendor, pci_dev->subsystem_device,
>> >(u8)(pci_dev->class >> 16), (u8)(pci_dev->class >> 8),
>>
>> As said in the other thread about this issue, no, this code has been
>> here for over 9 years just fine.  Please fix your userspace code that is
>> trying to compare hex values as a string and not a numeric value, that
>> is the stuff that is wrong, not the kernel.
>
> Oh wait, I see what you are worried about now, the mis-match for just
> the upper bits of the class value.
>
> Yeah, that's a bug, sorry about that, a 9+ year old one, nice catch :)
>
> Bjorn, feel free to apply this, sorry for the earlier objection.  Also
> please mark it for stable tree inclusion so this gets backported
> properly.
>
> thanks,
>
> greg k-h



-- 
Ricardo Ribalda
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] [PATCH] Solved the Xen PV/KASLR riddle

[Konrad Rzeszutek Wilk]

On Mon, Sep 01, 2014 at 06:03:06AM +0200, Juergen Gross wrote:
> On 08/29/2014 04:55 PM, Konrad Rzeszutek Wilk wrote:
> >On Fri, Aug 29, 2014 at 03:44:06PM +0100, Jan Beulich wrote:
> >On 29.08.14 at 16:27,  wrote:
> >>>Sure. Btw, someone also contacted me saying they have the same problem
> >>>without
> >>>changing the layout but having really big initrd (500M). While that feels
> >>>like
> >>>it should be impossible (if the kernel+initrd+xen stuff has to fix the 512M
> >>>kernel image size area then). But if it can happen, then surely it does
> >>>cause
> >>>mappings to be where the module space starts then.
> >>
> >>Since the initrd doesn't really need to be mapped into the (limited)
> >>virtual address space a pv guest starts with, we specifically got
> >>
> >>/*
> >>  * Whether or not the guest can deal with being passed an initrd not
> >>  * mapped through its initial page tables.
> >>  */
> >>#define XEN_ELFNOTE_MOD_START_PFN 16
> >>
> >>to deal with that situation. The hypervisor side for Dom0 is in place,
> >>and the kernel side works in our (classic) kernels. Whether it got
> >>implemented for DomU meanwhile I don't know; I'm pretty certain
> >>pv-ops kernels don't support it so far.
> >
> >Correct - Not implemented. Here is what I had mentioned in the past:
> >(see http://lists.xen.org/archives/html/xen-devel/2014-03/msg00580.html)
> >
> >
> >XEN_ELFNOTE_INIT_P2M, XEN_ELFNOTE_MOD_START_PFN - I had been looking
> > at that but I can't figure out a nice way of implementing this
> > without the usage of SPARSEMAP_VMAP virtual addresses - which is how
> > the classic Xen does it. But then - I don't know who is using huge PV
> > guests - as the PVHVM does a fine job? But then with PVH, now you can
> > boot with large amount of memory (1TB?) - so some of these issues
> > would go away? Except the 'large ramdisk' as that would eat in the
> > MODULES_VADDR I think? Needs more thinking.
> >
> >.. and then I left it and to my suprise saw on Luis's slides that
> >Jurgen is going to take a look at that (500GB support).
> 
> I have a patch which should do the job. It is based on the classic
> kernel patch Jan mentioned above. The system is coming up with it, I
> haven't tested it with a huge initrd up to now. My plan was to post the
> patch together with the rest of the >500GB support, but I can send it
> on it's own if required.

Oooh goodies! I think it makes sense to post it whenever you think
it is in the right state to be posted.

Now that your pvSCSI drivers are in, you have tons of free time
I suspect :-)


> 
> Juergen
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RTNL: assertion failed at net/ipv6/addrconf.c (1699)

[Cong Wang]

On Tue, Sep 2, 2014 at 12:02 PM, Hannes Frederic Sowa
 wrote:
>
> If fixes tag is well researched, it won't point to the addition of
> ASSERT_RTNL() but your patch would help to discover a bug somewhere else
> in the stack.
>
> I think for this patch a fixes-tag is hard to find because it is hard to
> find because it dates back to the beginning of the git history IMHO.
>

As I replied to Eric, this warning is probably caused by
the following commit:

commit c15b1ccadb323ea50023e8f1cca2954129a62b51
Author: Hannes Frederic Sowa 
Date:   Thu Mar 27 18:28:07 2014 +0100

ipv6: move DAD and addrconf_verify processing to workqueue


HOWEVER, you can definitely argue that the code without your
ASSERT_RTNL() was already broken, it's a little hard to tell without
digging more, that might date back to the beginning of git as you said.

For safety, I think we can simply assume it's that commit to be fixed
so that we don't fix older kernels until someone really reports a bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] init/Kconfig: move RCU_NOCB_CPU dependencies to choice

[Paul E. McKenney]

On Tue, Sep 02, 2014 at 08:05:48PM +0200, Stefan Hengelein wrote:
> 2014-09-02 19:07 GMT+02:00 Paul E. McKenney :
> > On Fri, Aug 29, 2014 at 03:08:20PM +0200, Stefan Hengelein wrote:
> >> Every choice item of the "Build-forced no-CBs CPUs" choice had a
> >> dependency to RCU_NOCB_CPU. It's more comprehensible if the choice
> >> itself has the dependency instead of every choice item.
> >> The choice itself doesn't need to be visible if there are no items
> >> selectable (i.e. on arch/frv) or RCU_NOCB_CPU is not defined.
> >>
> >> Signed-off-by: Stefan Hengelein 
> >> Signed-off-by: Andreas Ruprecht 
> >
> > Looks like a nice improvement, but could you please forward-port to branch
> > rcu/dev of 
> > git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git?
> >
> > Thanx, Paul
> 
> done, i attached the adjusted patch.

Queued, thank you!

Thanx, Paul

> Best Regards,
> Stefan
> 
> >
> >> ---
> >>  init/Kconfig | 6 +++---
> >>  1 file changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/init/Kconfig b/init/Kconfig
> >> index 197b563..d604000 100644
> >> --- a/init/Kconfig
> >> +++ b/init/Kconfig
> >> @@ -729,6 +729,7 @@ config RCU_NOCB_CPU
> >>  choice
> >>   prompt "Build-forced no-CBs CPUs"
> >>   default RCU_NOCB_CPU_NONE
> >> + depends on RCU_NOCB_CPU
> >>   help
> >> This option allows no-CBs CPUs (whose RCU callbacks are invoked
> >> from kthreads rather than from softirq context) to be specified
> >> @@ -737,7 +738,7 @@ choice
> >>
> >>  config RCU_NOCB_CPU_NONE
> >>   bool "No build_forced no-CBs CPUs"
> >> - depends on RCU_NOCB_CPU && !NO_HZ_FULL_ALL
> >> + depends on !NO_HZ_FULL_ALL
> >>   help
> >> This option does not force any of the CPUs to be no-CBs CPUs.
> >> Only CPUs designated by the rcu_nocbs= boot parameter will be
> >> @@ -751,7 +752,7 @@ config RCU_NOCB_CPU_NONE
> >>
> >>  config RCU_NOCB_CPU_ZERO
> >>   bool "CPU 0 is a build_forced no-CBs CPU"
> >> - depends on RCU_NOCB_CPU && !NO_HZ_FULL_ALL
> >> + depends on !NO_HZ_FULL_ALL
> >>   help
> >> This option forces CPU 0 to be a no-CBs CPU, so that its RCU
> >> callbacks are invoked by a per-CPU kthread whose name begins
> >> @@ -766,7 +767,6 @@ config RCU_NOCB_CPU_ZERO
> >>
> >>  config RCU_NOCB_CPU_ALL
> >>   bool "All CPUs are build_forced no-CBs CPUs"
> >> - depends on RCU_NOCB_CPU
> >>   help
> >> This option forces all CPUs to be no-CBs CPUs.  The rcu_nocbs=
> >> boot parameter will be ignored.  All CPUs' RCU callbacks will
> >> --
> >> 1.9.1
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >> the body of a message to majord...@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> Please read the FAQ at  http://www.tux.org/lkml/
> >>
> >

> From 1f82e1240eba4b31091bcff0e3c126853adacb53 Mon Sep 17 00:00:00 2001
> From: Stefan Hengelein 
> Date: Tue, 2 Sep 2014 19:55:11 +0200
> Subject: [PATCH] init/Kconfig: move RCU_NOCB_CPU dependencies to choice
> 
> Every choice item of the "Build-forced no-CBs CPUs" choice had a
> dependency to RCU_NOCB_CPU.  It's more comprehensible if the choice
> itself has the dependency instead of every choice item.  The choice
> itself doesn't need to be visible if there are no items selectable
> (i.e.  on arch/frv) or RCU_NOCB_CPU is not defined.
> 
> Signed-off-by: Stefan Hengelein 
> Signed-off-by: Andreas Ruprecht 
> Reviewed-by: Josh Triplett 
> Signed-off-by: Andrew Morton 
> ---
>  init/Kconfig | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index 4fe5500..95a1447 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -739,6 +739,7 @@ config RCU_NOCB_CPU
>  choice
>   prompt "Build-forced no-CBs CPUs"
>   default RCU_NOCB_CPU_NONE
> + depends on RCU_NOCB_CPU
>   help
> This option allows no-CBs CPUs (whose RCU callbacks are invoked
> from kthreads rather than from softirq context) to be specified
> @@ -747,7 +748,6 @@ choice
>  
>  config RCU_NOCB_CPU_NONE
>   bool "No build_forced no-CBs CPUs"
> - depends on RCU_NOCB_CPU
>   help
> This option does not force any of the CPUs to be no-CBs CPUs.
> Only CPUs designated by the rcu_nocbs= boot parameter will be
> @@ -761,7 +761,6 @@ config RCU_NOCB_CPU_NONE
>  
>  config RCU_NOCB_CPU_ZERO
>   bool "CPU 0 is a build_forced no-CBs CPU"
> - depends on RCU_NOCB_CPU
>   help
> This option forces CPU 0 to be a no-CBs CPU, so that its RCU
> callbacks are invoked by a per-CPU kthread whose name begins
> @@ -776,7 +775,6 @@ config RCU_NOCB_CPU_ZERO
>  
>  config RCU_NOCB_CPU_ALL
>   bool "All CPUs are build_forced no-CBs CPUs"
> - depends on RCU_NOCB_CPU
>   

[PATCH -v2] x86: only load initrd above 4g on second try

[Yinghai Lu]

Mantas found that after commit 4bf7111f5016 ("x86/efi: Support initrd
loaded above 4G"), the kernel freezes at the earliest possible moment
when trying to boot via UEFI on Asus laptop.

Revert to old way to load initrd under 4G on first try,
second try will use above 4G buffer when initrd is too big
and does not fit under 4G.

-v2: add print out for second try, and print out files buf address.

Reported-by: Mantas Mikulėnas 
Tested-by: Anders Darander 
Signed-off-by: Yinghai Lu 

---
 arch/x86/boot/compressed/eboot.c   |   18 +++---
 drivers/firmware/efi/libstub/efi-stub-helper.c |5 +
 2 files changed, 16 insertions(+), 7 deletions(-)

Index: linux-2.6/arch/x86/boot/compressed/eboot.c
===
--- linux-2.6.orig/arch/x86/boot/compressed/eboot.c
+++ linux-2.6/arch/x86/boot/compressed/eboot.c
@@ -1032,7 +1032,6 @@ struct boot_params *make_boot_params(str
int i;
unsigned long ramdisk_addr;
unsigned long ramdisk_size;
-   unsigned long initrd_addr_max;
 
efi_early = c;
sys_table = (efi_system_table_t *)(unsigned long)efi_early->table;
@@ -1095,15 +1094,20 @@ struct boot_params *make_boot_params(str
 
memset(sdt, 0, sizeof(*sdt));
 
-   if (hdr->xloadflags & XLF_CAN_BE_LOADED_ABOVE_4G)
-   initrd_addr_max = -1UL;
-   else
-   initrd_addr_max = hdr->initrd_addr_max;
-
status = handle_cmdline_files(sys_table, image,
  (char *)(unsigned long)hdr->cmd_line_ptr,
- "initrd=", initrd_addr_max,
+ "initrd=", hdr->initrd_addr_max,
  _addr, _size);
+
+   if (status != EFI_SUCCESS &&
+   hdr->xloadflags & XLF_CAN_BE_LOADED_ABOVE_4G) {
+   efi_printk(sys_table, "Trying to load files to higher 
address\n");
+   status = handle_cmdline_files(sys_table, image,
+ (char *)(unsigned long)hdr->cmd_line_ptr,
+ "initrd=", -1UL,
+ _addr, _size);
+   }
+
if (status != EFI_SUCCESS)
goto fail2;
hdr->ramdisk_image = ramdisk_addr & 0x;
Index: linux-2.6/drivers/firmware/efi/libstub/efi-stub-helper.c
===
--- linux-2.6.orig/drivers/firmware/efi/libstub/efi-stub-helper.c
+++ linux-2.6/drivers/firmware/efi/libstub/efi-stub-helper.c
@@ -396,6 +396,7 @@ efi_status_t handle_cmdline_files(efi_sy
 
if (file_size_total) {
unsigned long addr;
+   char buf[64];
 
/*
 * Multiple files need to be at consecutive addresses in memory,
@@ -416,6 +417,10 @@ efi_status_t handle_cmdline_files(efi_sy
goto free_file_total;
}
 
+   snprintf(buf, sizeof(buf), "files buf: [%lx,%lx)\n",
+   file_addr, file_addr + file_size_total);
+   efi_printk(sys_table_arg, buf);
+
addr = file_addr;
for (j = 0; j < nr_files; j++) {
unsigned long size;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Race condition in HR timers that cause double insertion and hard lockup -- all latest versions

[Thomas Gleixner]

On Tue, 2 Sep 2014, Linus Torvalds wrote:

> On Tue, Sep 2, 2014 at 8:45 AM, Itzcak Pechtalt
>  wrote:
> >
> > I opened a bug in https://bugzilla.kernel.org/show_bug.cgi?id=83601  for 
> > this subject with full description.
> > There is also a short fix patch for kernel/hrtimer.c file.
> > Even if this bug occurs rary, however it resolves system hard lockup option.
> 
> The patch is whitespace-damaged, but with a small oneliner like this
> that doesn't much matter (the timer files moved to kernel/time/ during
> this merge window, so the patch wouldn't apply as-is anyway).
> 
> It needs a sign-off (see Documentation/SubmittingPatches), but even
> more importantly it needs to go to the right people for
> double-checking.
> 
> But the patch is more broken than whitespace and even lack of
> sign-off. It cannot even have compiled. I'm assuming "timer_state" was
> intended to be "timer->state". Also, every caller but one already has
> "HRTIMER_STATE_CALLBACK" set unconditionally or to the old state in
> "newstate", so I suspect if this patch is the real fix (which I'll
> leave for Thomas to comment more on), afaik the actual problem can
> only happen through migrate_hrtimer_list() which uconditionally sets
> the whole state to HRTIMER_STATE_MIGRATE.
> 
> Thomas? Leaving damaged patch quoted below.

Right. It's been fixed long ago and the migrate path cannot suffer
from this problem because at this point a callback running on the dead
cpu would cause the 

BUG_ON(hrtimer_callback_running(timer));

a few lines above the remove_hrtimer() call to trigger and send the
machine into lala land.

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RTNL: assertion failed at net/ipv6/addrconf.c (1699)

[Vlad Yasevich]

On 09/02/2014 02:15 PM, Cong Wang wrote:
> On Tue, Sep 2, 2014 at 11:11 AM, Eric Dumazet  wrote:
>> On Tue, 2014-09-02 at 11:04 -0700, Cong Wang wrote:
>>> On Tue, Sep 2, 2014 at 10:58 AM, Hannes Frederic Sowa
>>
 I definitely don't have a problem cleaning this up in net-next. I wanted
 a minimal patch for stable because I didn't check history where and when
 additional users of dev_get_by_flags_rcu were removed.
>>>
>>> `git grep` should show you we only have one caller. Apparently we don't
>>> care about any out-of-tree module.
>>
>> Point is : you did not check if some stable versions had more callers.
>>
>> Its very nice you checked current version, but it is not enough for a
>> stable candidate.
> 
> That is what we do when backporting patches, I can do that if David asks
> me to backport it, but you know for netdev that is David's work.
> 
> (I am not saying I don't want to help him, I just want to point out the fact.
> I am very pleased to help David for stable backports as long as he asks)

Instead of helping after the fact, why not arrange the patches so that it's
not such a big issue.  Leave the _rcu variant alone.  Add an _rtnl variant
of the function and use that in the patch.  Have a follow-on patch that
removes the _rcu variant all by itself.  This way backports become easier,
and if anyone wants the _rcu variant back, all they have to do is revert
a very simple commit.

-vlad

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] locks: Ability to test for flock presence on fd

[Pavel Emelyanov]

On 09/02/2014 10:44 PM, J. Bruce Fields wrote:
> On Tue, Sep 02, 2014 at 09:17:34PM +0400, Pavel Emelyanov wrote:
>> Hi,
>>
>> There's a problem with getting information about who has a flock on
>> a specific file. The thing is that the "owner" field, that is shown in
>> /proc/locks is the pid of the task who created the flock, not the one
>> who _may_ hold it.
>>
>> If the flock creator shared the file with some other task (by forking
>> or via scm_rights) and then died or closed the file, the information
>> shown in proc no longer corresponds to the reality.
>>
>> This is critical for CRIU project, that tries to dump (and restore)
>> the state of running tasks. For example, let's take two tasks A and B
>> both opened a file "/foo", one of tasks places a LOCK_SH lock on the 
>> file and then "obfuscated" the owner field in /proc/locks. After this
>> we have no ways to find out who is the lock holder.
>>
>> I'd like to note, that for LOCK_EX this problem is not critical -- we
>> may go to both tasks and "ask" them to LOCK_EX the file again (we can
>> do it in CRIU, I can tell more if required). The one who succeeds is 
>> the lock holder.
> 
> It could be both, actually, right?

Two succeeding with LOCK_EX? AFAIU no. Am I missing something?

>> With LOCK_SH this doesn't work. Trying to drop the
>> lock doesn't work either, as flock(LOCK_UN) reports 0 in both cases:
>> if the file is locked and if it is not.
>>
>> That said, I'd like to propose the LOCK_TEST flag to the flock call,
>> that would check whether the lock of the given type (LOCK_SH or LOCK_EX)
>> exists on the file we test. It's not the same as the existing in-kernel
>> FL_ACCESS flag, which checks whether the new lock is possible, but
>> it's a new FL_TEST flag, that checks whether the existing lock is there.
>>
>> What do you think?
> 
> I guess I can't see anything really wrong with it.
> 
> It ignores the (poorly documented) LOCK_MAND case, but maybe that's OK.

I actually checked it and it seemed to work. What problems do
you see with this case?

> Would it make sense to return the lock type held instead, so you could
> do one flock(fd, LOCK_TEST) instead of flock(fd, LOCK_TEST|LOCK_SH) and
> flock(fd, LOCK_TEST|LOCK_EX) ?

Well, in our case we parse /proc/locks anyway to see what
files at least to test for being locked. But what you propose
looks even better. I'll look what can be done here.

> It'd be nice if we could fix /proc/locks.  (You'd think I'd know better,
> but I've certainly been confused before when /proc/locks told me a lock
> was owned by a nonexistant PID.)  But as long as multiple PIDs can "own"
> a flock and as long as there's no simple ID we can use to refer to a
> given struct file, I don't see an easy solution.
> 
> --b.
> 
> 
>>
>> Signed-off-by: Pavel Emelyanov 
>>
>> ---
>>
>> diff --git a/fs/locks.c b/fs/locks.c
>> index bb08857..50842bf 100644
>> --- a/fs/locks.c
>> +++ b/fs/locks.c
>> @@ -830,7 +830,7 @@ static int flock_lock_file(struct file *filp, struct 
>> file_lock *request)
>>  int found = 0;
>>  LIST_HEAD(dispose);
>>  
>> -if (!(request->fl_flags & FL_ACCESS) && (request->fl_type != F_UNLCK)) {
>> +if (!(request->fl_flags & (FL_ACCESS|FL_TEST)) && (request->fl_type != 
>> F_UNLCK)) {
>>  new_fl = locks_alloc_lock();
>>  if (!new_fl)
>>  return -ENOMEM;
>> @@ -850,11 +850,18 @@ static int flock_lock_file(struct file *filp, struct 
>> file_lock *request)
>>  continue;
>>  if (request->fl_type == fl->fl_type)
>>  goto out;
>> +if (request->fl_flags & FL_TEST)
>> +break;
>>  found = 1;
>>  locks_delete_lock(before, );
>>  break;
>>  }
>>  
>> +if (request->fl_flags & FL_TEST) {
>> +error = -ENOENT;
>> +goto out;
>> +}
>> +
>>  if (request->fl_type == F_UNLCK) {
>>  if ((request->fl_flags & FL_EXISTS) && !found)
>>  error = -ENOENT;
>> @@ -1852,15 +1859,16 @@ SYSCALL_DEFINE2(flock, unsigned int, fd, unsigned 
>> int, cmd)
>>  {
>>  struct fd f = fdget(fd);
>>  struct file_lock *lock;
>> -int can_sleep, unlock;
>> +int can_sleep, unlock, test;
>>  int error;
>>  
>>  error = -EBADF;
>>  if (!f.file)
>>  goto out;
>>  
>> +test = (cmd & LOCK_TEST);
>>  can_sleep = !(cmd & LOCK_NB);
>> -cmd &= ~LOCK_NB;
>> +cmd &= ~(LOCK_NB|LOCK_TEST);
>>  unlock = (cmd == LOCK_UN);
>>  
>>  if (!unlock && !(cmd & LOCK_MAND) &&
>> @@ -1872,6 +1880,8 @@ SYSCALL_DEFINE2(flock, unsigned int, fd, unsigned int, 
>> cmd)
>>  goto out_putf;
>>  if (can_sleep)
>>  lock->fl_flags |= FL_SLEEP;
>> +if (test)
>> +lock->fl_flags |= FL_TEST;
>>  
>>  error = security_file_lock(f.file, lock->fl_type);
>>  if (error)
>> diff --git a/include/linux/fs.h b/include/linux/fs.h
>> index 

regression caused by cgroups optimization in 3.17-rc2

[Dave Hansen]

I'm seeing a pretty large regression in 3.17-rc2 vs 3.16 coming from the
memory cgroups code.  This is on a kernel with cgroups enabled at
compile time, but not _used_ for anything.  See the green lines in the
graph:

https://www.sr71.net/~dave/intel/regression-from-05b843012.png

The workload is a little parallel microbenchmark doing page faults:

> https://github.com/antonblanchard/will-it-scale/blob/master/tests/page_fault2.c

The hardware is an 8-socket Westmere box with 160 hardware threads.  For
some reason, this does not affect the version of the microbenchmark
which is doing completely anonymous page faults.

I bisected it down to this commit:

> commit 05b8430123359886ef6a4146fba384e30d771b3f
> Author: Johannes Weiner 
> Date:   Wed Aug 6 16:05:59 2014 -0700
> 
> mm: memcontrol: use root_mem_cgroup res_counter
> 
> Due to an old optimization to keep expensive res_counter changes at a
> minimum, the root_mem_cgroup res_counter is never charged; there is no
> limit at that level anyway, and any statistics can be generated on
> demand by summing up the counters of all other cgroups.
> 
> However, with per-cpu charge caches, res_counter operations do not even
> show up in profiles anymore, so this optimization is no longer
> necessary.
> 
> Remove it to simplify the code.

It does not revert cleanly because of the hunks below.  The code in
those hunks was removed, so I tried running without properly merging
them and it spews warnings because counter->usage is seen going negative.

So, it doesn't appear we can quickly revert this.

> --- mm/memcontrol.c
> +++ mm/memcontrol.c
> @@ -3943,7 +3947,7 @@
>  * replacement page, so leave it alone when phasing out the
>  * page that is unused after the migration.
>  */
> -   if (!end_migration)
> +   if (!end_migration && !mem_cgroup_is_root(memcg))
> mem_cgroup_do_uncharge(memcg, nr_pages, ctype);
>  
> return memcg;
> @@ -4076,7 +4080,8 @@
>  * We uncharge this because swap is freed.  This memcg can
>  * be obsolete one. We avoid calling css_tryget_online().
>  */
> -   res_counter_uncharge(>memsw, PAGE_SIZE);
> +   if (!mem_cgroup_is_root(memcg))
> +   res_counter_uncharge(>memsw, PAGE_SIZE);
> mem_cgroup_swap_statistics(memcg, false);
> css_put(>css);
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 23

[Guenter Roeck]

On Tue, Sep 02, 2014 at 11:55:53AM +0200, Peter Zijlstra wrote:
> On Tue, Sep 02, 2014 at 11:40:16AM +0200, Peter Zijlstra wrote:
> > On Mon, Sep 01, 2014 at 09:04:38PM +0200, Peter Zijlstra wrote:
> > > On Mon, Sep 01, 2014 at 09:46:42AM -0700, Guenter Roeck wrote:
> > > > Yes, the problem is still seen in next-140829. See qemu test results at
> > > > http://server.roeck-us.net:8010/builders.
> > > > 
> > > > I provided sparc64 images at http://server.roeck-us.net/qemu/sparc64/.
> > > > The README file includes instructions on how to run the image in qemu
> > > > and how to build a kernel.
> > > > 
> > > > I can do the same for mips and mips64 if needed; let me know.
> > > 
> > > Thanks, that's enough to get started.
> > 
> > This makes sparc64 go again, silly oversight indeed.
> > 
> 
> The same for mips. Can you either provide the mips image or verify this works?
> 
Still fails, unfortunately.

I provided qemu images and instructions as follows.
http://server.roeck-us.net/qemu/mipsel/ MIPS 32 bit, little 
endian
http://server.roeck-us.net/qemu/mips64el/   MIPS 64 bit, little 
endian

Let me know if you also need big endian images.

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RTNL: assertion failed at net/ipv6/addrconf.c (1699)

[Hannes Frederic Sowa]

On Di, 2014-09-02 at 11:40 -0700, Cong Wang wrote:
> On Tue, Sep 2, 2014 at 11:18 AM, Hannes Frederic Sowa
>  wrote:
> > Those ASSERT_RTNLs were misplaced and only caught the callers mostly
> > from addrconf.c. I don't mind getting reports from stable kernel users
> > and fixing those, too (or help fixing those). ASSERT_RTNL is not
> > dangerous.
> >
> > We had a long history in not correctly using rtnl lock in ipv6/multicast
> > code and those wrongfully placed ASSERT_RTNLs were my bad when I fixed
> > the duplicate address detection handling.
> >
> > If enough multicast addresses are subscribed to an interface we might
> > again get those splats because enabling promisc mode on an interface
> > will also check for rtnl lock.
> >
> 
> Sure, I never doubt adding ASSERT_RTNL() is helpful, I just still think
> this should be for net-next, or at least a separated patch. I don't want
> my patch to be blamed in others' "Fixes:". :)

Come on, that's why we have community review. Nobody blames anyone
because of added regressions. It's more a fault of the community then,
and it works out fairly good I think! Even others are keen on fixing
your bugs sometimes. ;)

If fixes tag is well researched, it won't point to the addition of
ASSERT_RTNL() but your patch would help to discover a bug somewhere else
in the stack.

I think for this patch a fixes-tag is hard to find because it is hard to
find because it dates back to the beginning of the git history IMHO.

Bye,
Hannes


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/