date:20150206

Change private struct member name from line_status to modem_status.
It will store MSR for some functions used

Signed-off-by: Peter Hung 
---
 drivers/usb/serial/f81232.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index c5dc233..669a2f2 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -47,7 +47,7 @@ MODULE_DEVICE_TABLE(usb, id_table);
 struct f81232_private {
spinlock_t lock;
u8 line_control;
-   u8 line_status;
+   u8 modem_status;
 };
 
 static void f81232_update_line_status(struct usb_serial_port *port,
@@ -113,8 +113,8 @@ static void f81232_process_read_urb(struct urb *urb)
 
/* update line status */
spin_lock_irqsave(>lock, flags);
-   line_status = priv->line_status;
-   priv->line_status &= ~UART_STATE_TRANSIENT_MASK;
+   line_status = priv->modem_status;
+   priv->modem_status &= ~UART_STATE_TRANSIENT_MASK;
spin_unlock_irqrestore(>lock, flags);
 
if (!urb->actual_length)
@@ -241,7 +241,7 @@ static void f81232_dtr_rts(struct usb_serial_port *port, 
int on)
 static int f81232_carrier_raised(struct usb_serial_port *port)
 {
struct f81232_private *priv = usb_get_serial_port_data(port);
-   if (priv->line_status & UART_DCD)
+   if (priv->modem_status & UART_DCD)
return 1;
return 0;
 }
-- 
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 V5 4/8] USB: f81232: implement set_termios

The original driver had do not any h/w change in driver.
This patch implements with configure H/W for
baud/parity/word length/stop bits functional.

Some init step extract to f81232_port_init(), called once with open().
And refine baudrate setting to f81232_set_baudrate()

Signed-off-by: Peter Hung 
---
 drivers/usb/serial/f81232.c | 145 +---
 1 file changed, 138 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index 9ea498a..06d1eb0 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -31,11 +31,19 @@ static const struct usb_device_id id_table[] = {
 };
 MODULE_DEVICE_TABLE(usb, id_table);
 
+/* Maximum baudrate for F81232 */
+#define F81232_MAX_BAUDRATE 115200L
+
 /* USB Control EP parameter */
 #define F81232_REGISTER_REQUEST 0xA0
 #define F81232_GET_REGISTER 0xc0
+#define F81232_SET_REGISTER 0x40
 
 #define SERIAL_BASE_ADDRESS   0x0120
+#define RECEIVE_BUFFER_REGISTER(0x00 + SERIAL_BASE_ADDRESS)
+#define INTERRUPT_ENABLE_REGISTER  (0x01 + SERIAL_BASE_ADDRESS)
+#define FIFO_CONTROL_REGISTER  (0x02 + SERIAL_BASE_ADDRESS)
+#define LINE_CONTROL_REGISTER  (0x03 + SERIAL_BASE_ADDRESS)
 #define MODEM_STATUS_REGISTER  (0x06 + SERIAL_BASE_ADDRESS)
 
 #define CONTROL_DTR0x01
@@ -61,6 +69,14 @@ struct f81232_private {
struct usb_serial_port *port;
 };
 
+static int calc_baud_divisor(u32 baudrate)
+{
+   if (!baudrate)
+   return 0;
+   else
+   return DIV_ROUND_CLOSEST(F81232_MAX_BAUDRATE, baudrate);
+}
+
 static int f81232_get_register(struct usb_serial_port *port,
  u16 reg, u8 *data)
 {
@@ -82,6 +98,27 @@ static int f81232_get_register(struct usb_serial_port *port,
return status;
 }
 
+static int f81232_set_register(struct usb_serial_port *port,
+ u16 reg, u8 data)
+{
+   int status;
+   struct usb_device *dev = port->serial->dev;
+
+   status = usb_control_msg(dev,
+   usb_sndctrlpipe(dev, 0),
+   F81232_REGISTER_REQUEST,
+   F81232_SET_REGISTER,
+   reg,
+   0,
+   ,
+   sizeof(data),
+   USB_CTRL_SET_TIMEOUT);
+   if (status < 0)
+   dev_err(>dev, "%s status: %d\n", __func__, status);
+
+   return status;
+}
+
 static void f81232_read_msr(struct usb_serial_port *port)
 {
int status;
@@ -247,18 +284,106 @@ static void f81232_break_ctl(struct tty_struct *tty, int 
break_state)
 */
 }
 
+static void f81232_set_baudrate(struct usb_serial_port *port, int baudrate)
+{
+   u8 divisor;
+   int status = 0;
+
+   divisor = calc_baud_divisor(baudrate);
+
+   status = f81232_set_register(port, LINE_CONTROL_REGISTER,
+UART_LCR_DLAB); /* DLAB */
+   if (status < 0) {
+   dev_err(>dev, "%s status: %d line:%d\n",
+   __func__, status, __LINE__);
+   }
+
+   status = f81232_set_register(port, RECEIVE_BUFFER_REGISTER,
+divisor & 0x00ff); /* low */
+   if (status < 0) {
+   dev_err(>dev, "%s status: %d line:%d\n",
+   __func__, status, __LINE__);
+   }
+
+   status = f81232_set_register(port, INTERRUPT_ENABLE_REGISTER,
+(divisor & 0xff00) >> 8); /* high */
+   if (status < 0) {
+   dev_err(>dev, "%s status: %d line:%d\n", __func__,
+   status, __LINE__);
+   }
+
+   status = f81232_set_register(port, LINE_CONTROL_REGISTER, 0x00);
+   if (status < 0) {
+   dev_err(>dev, "%s status: %d line:%d\n", __func__,
+   status, __LINE__);
+   }
+}
+
+static int f81232_port_init(struct usb_serial_port *port)
+{
+   u8 data;
+   int status = 0;
+
+   /* fifo on, trigger8, clear TX/RX*/
+   data = UART_FCR_TRIGGER_8 | UART_FCR_ENABLE_FIFO | UART_FCR_CLEAR_RCVR
+   | UART_FCR_CLEAR_XMIT;
+
+   status |= f81232_set_register(port, FIFO_CONTROL_REGISTER, data);
+
+   /* MSR Interrupt only, LSR will read from Bulk-in odd byte */
+   data = UART_IER_MSI;
+
+   /* IER */
+   status |= f81232_set_register(port, INTERRUPT_ENABLE_REGISTER, data);
+   if (status < 0) {
+   dev_err(>dev, "%s set error: %d\n", __func__, status);
+   return status;
+   }
+
+   return 0;
+}
+
 static void f81232_set_termios(struct tty_struct *tty,
struct usb_serial_port *port, struct ktermios *old_termios)
 {
-   /* FIXME - Stubbed out for now */
+   u8 new_lcr = 0;
+   int status = 0;
 
-   /* Don't change anything if nothing has changed */
-   if (old_termios &&

[PATCH V5 3/8] USB: f81232: implement RX bulk-in ep

The F81232 bulk-in is RX data + LSR channel, data format is
[LSR+Data][LSR+Data]. , We had reimplemented in this patch.

Signed-off-by: Peter Hung 
---
 drivers/usb/serial/f81232.c | 68 +++--
 1 file changed, 35 insertions(+), 33 deletions(-)

diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index ec4609d..9ea498a 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -185,44 +185,46 @@ exit:
 static void f81232_process_read_urb(struct urb *urb)
 {
struct usb_serial_port *port = urb->context;
-   struct f81232_private *priv = usb_get_serial_port_data(port);
unsigned char *data = urb->transfer_buffer;
-   char tty_flag = TTY_NORMAL;
-   unsigned long flags;
-   u8 line_status;
+   char tty_flag;
int i;
 
-   /* update line status */
-   spin_lock_irqsave(>lock, flags);
-   line_status = priv->modem_status;
-   priv->modem_status &= ~UART_STATE_TRANSIENT_MASK;
-   spin_unlock_irqrestore(>lock, flags);
-
-   if (!urb->actual_length)
+   if (urb->actual_length < 2)
return;
 
-   /* break takes precedence over parity, */
-   /* which takes precedence over framing errors */
-   if (line_status & UART_BREAK_ERROR)
-   tty_flag = TTY_BREAK;
-   else if (line_status & UART_PARITY_ERROR)
-   tty_flag = TTY_PARITY;
-   else if (line_status & UART_FRAME_ERROR)
-   tty_flag = TTY_FRAME;
-   dev_dbg(>dev, "%s - tty_flag = %d\n", __func__, tty_flag);
-
-   /* overrun is special, not associated with a char */
-   if (line_status & UART_OVERRUN_ERROR)
-   tty_insert_flip_char(>port, 0, TTY_OVERRUN);
-
-   if (port->port.console && port->sysrq) {
-   for (i = 0; i < urb->actual_length; ++i)
-   if (!usb_serial_handle_sysrq_char(port, data[i]))
-   tty_insert_flip_char(>port, data[i],
-   tty_flag);
-   } else {
-   tty_insert_flip_string_fixed_flag(>port, data, tty_flag,
-   urb->actual_length);
+   /* bulk-in data: [LSR(1Byte)+DATA(1Byte)][LSR(1Byte)+DATA(1Byte)]... */
+
+   for (i = 0 ; i < urb->actual_length ; i += 2) {
+   tty_flag = TTY_NORMAL;
+
+   if (unlikely(data[i+0] & UART_LSR_BRK_ERROR_BITS)) {
+   if (data[i+0] & UART_LSR_BI) {
+   tty_flag = TTY_BREAK;
+   port->icount.brk++;
+   usb_serial_handle_break(port);
+   } else if (data[i+0] & UART_LSR_PE) {
+   tty_flag = TTY_PARITY;
+   port->icount.parity++;
+   } else if (data[i+0] & UART_LSR_FE) {
+   tty_flag = TTY_FRAME;
+   port->icount.frame++;
+   }
+
+   if (data[0] & UART_LSR_OE) {
+   port->icount.overrun++;
+   tty_insert_flip_char(>port, 0,
+   TTY_OVERRUN);
+   }
+   }
+
+   if (port->port.console && port->sysrq) {
+   if (!usb_serial_handle_sysrq_char(port, data[i+1]))
+   tty_insert_flip_char(>port, data[i+1],
+   tty_flag);
+   } else {
+   tty_insert_flip_string_fixed_flag(>port,
+   [i+1], tty_flag, 1);
+   }
}
 
tty_flip_buffer_push(>port);
-- 
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 V5 5/8] USB: f81232: implement MCR/MSR function

This patch implement relative MCR/MSR function, such like
tiocmget()/tiocmset()/dtr_rts().

The f81232_set_mctrl() replace set_control_lines() to do MCR control
so we clean-up the set_control_lines() function.

Signed-off-by: Peter Hung 
---
 drivers/usb/serial/f81232.c | 98 +++--
 1 file changed, 77 insertions(+), 21 deletions(-)

diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index 06d1eb0..e1cdf42 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -44,6 +44,7 @@ MODULE_DEVICE_TABLE(usb, id_table);
 #define INTERRUPT_ENABLE_REGISTER  (0x01 + SERIAL_BASE_ADDRESS)
 #define FIFO_CONTROL_REGISTER  (0x02 + SERIAL_BASE_ADDRESS)
 #define LINE_CONTROL_REGISTER  (0x03 + SERIAL_BASE_ADDRESS)
+#define MODEM_CONTROL_REGISTER (0x04 + SERIAL_BASE_ADDRESS)
 #define MODEM_STATUS_REGISTER  (0x06 + SERIAL_BASE_ADDRESS)
 
 #define CONTROL_DTR0x01
@@ -156,6 +157,50 @@ static void f81232_read_msr(struct usb_serial_port *port)
wake_up_interruptible(>port.delta_msr_wait);
 }
 
+static int f81232_set_mctrl(struct usb_serial_port *port,
+  unsigned int set, unsigned int clear)
+{
+   u8 urb_value;
+   int status;
+   unsigned long flags;
+   struct f81232_private *priv = usb_get_serial_port_data(port);
+
+   if (((set | clear) & (TIOCM_DTR | TIOCM_RTS)) == 0)
+   return 0;   /* no change */
+
+   /* 'set' takes precedence over 'clear' */
+   clear &= ~set;
+
+   /* force enable interrupt with OUT2 */
+   urb_value = UART_MCR_OUT2 | priv->line_control;
+
+   if (clear & TIOCM_DTR)
+   urb_value &= ~UART_MCR_DTR;
+
+   if (clear & TIOCM_RTS)
+   urb_value &= ~UART_MCR_RTS;
+
+   if (set & TIOCM_DTR)
+   urb_value |= UART_MCR_DTR;
+
+   if (set & TIOCM_RTS)
+   urb_value |= UART_MCR_RTS;
+
+   dev_dbg(>dev, "%s new:%02x old:%02x\n", __func__,
+   urb_value, priv->line_control);
+
+   status = f81232_set_register(port, MODEM_CONTROL_REGISTER, urb_value);
+   if (status < 0) {
+   dev_err(>dev, "%s set MCR status < 0\n", __func__);
+   } else {
+   spin_lock_irqsave(>lock, flags);
+   priv->line_control = urb_value;
+   spin_unlock_irqrestore(>lock, flags);
+   }
+
+   return status;
+}
+
 static void f81232_update_modem_status(struct usb_serial_port *port,
  unsigned char *data,
  unsigned int actual_length)
@@ -267,12 +312,6 @@ static void f81232_process_read_urb(struct urb *urb)
tty_flip_buffer_push(>port);
 }
 
-static int set_control_lines(struct usb_device *dev, u8 value)
-{
-   /* FIXME - Stubbed out for now */
-   return 0;
-}
-
 static void f81232_break_ctl(struct tty_struct *tty, int break_state)
 {
/* FIXME - Stubbed out for now */
@@ -388,15 +427,41 @@ static void f81232_set_termios(struct tty_struct *tty,
 
 static int f81232_tiocmget(struct tty_struct *tty)
 {
-   /* FIXME - Stubbed out for now */
-   return 0;
+   int r;
+   struct usb_serial_port *port = tty->driver_data;
+   struct f81232_private *port_priv = usb_get_serial_port_data(port);
+   unsigned long flags;
+   u8 mcr, msr;
+
+   /* force get current MSR changed state */
+   f81232_read_msr(port);
+
+   spin_lock_irqsave(_priv->lock, flags);
+   mcr = port_priv->line_control;
+   msr = port_priv->modem_status;
+   spin_unlock_irqrestore(_priv->lock, flags);
+
+   r = (mcr & UART_MCR_DTR ? TIOCM_DTR : 0) |
+   (mcr & UART_MCR_RTS ? TIOCM_RTS : 0) |
+   (msr & UART_MSR_CTS ? TIOCM_CTS : 0) |
+   (msr & UART_MSR_DCD ? TIOCM_CAR : 0) |
+   (msr & UART_MSR_RI ? TIOCM_RI : 0) |
+   (msr & UART_MSR_DSR ? TIOCM_DSR : 0);
+
+   return r;
 }
 
 static int f81232_tiocmset(struct tty_struct *tty,
unsigned int set, unsigned int clear)
 {
-   /* FIXME - Stubbed out for now */
-   return 0;
+   int status;
+   struct usb_serial_port *port = tty->driver_data;
+
+   status = f81232_set_mctrl(port, set, clear);
+   if (status < 0)
+   return usb_translate_errors(status);
+   else
+   return 0;
 }
 
 static int f81232_open(struct tty_struct *tty, struct usb_serial_port *port)
@@ -437,19 +502,10 @@ static void f81232_close(struct usb_serial_port *port)
 
 static void f81232_dtr_rts(struct usb_serial_port *port, int on)
 {
-   struct f81232_private *priv = usb_get_serial_port_data(port);
-   unsigned long flags;
-   u8 control;
-
-   spin_lock_irqsave(>lock, flags);
-   /* Change DTR and RTS */
if (on)
-   priv->line_control |= (CONTROL_DTR | CONTROL_RTS);
+

[PATCH V5 8/8] USB: f81232: modify/add author

Add me to co-author and fix no '>' in greg kh's email

Signed-off-by: Peter Hung 
---
 drivers/usb/serial/f81232.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index 07abf0c..8799b66 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -608,5 +608,6 @@ static struct usb_serial_driver * const serial_drivers[] = {
 module_usb_serial_driver(serial_drivers, id_table);
 
 MODULE_DESCRIPTION("Fintek F81232 USB to serial adaptor driver");
-MODULE_AUTHOR("Greg Kroah-Hartman ");
+MODULE_AUTHOR("Peter Hong ");
 MODULE_LICENSE("GPL v2");
-- 
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 V5 7/8] USB: f81232: fix error in f81232_carrier_raised()

It's should compared with UART_MSR_DCD, not UART_DCD.
also we clean-up some non-used define to avoid impropriety use.

Signed-off-by: Peter Hung 
---
 drivers/usb/serial/f81232.c | 16 +---
 1 file changed, 1 insertion(+), 15 deletions(-)

diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index 4dddb44..07abf0c 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -47,20 +47,6 @@ MODULE_DEVICE_TABLE(usb, id_table);
 #define MODEM_CONTROL_REGISTER (0x04 + SERIAL_BASE_ADDRESS)
 #define MODEM_STATUS_REGISTER  (0x06 + SERIAL_BASE_ADDRESS)
 
-#define CONTROL_DTR0x01
-#define CONTROL_RTS0x02
-
-#define UART_STATE 0x08
-#define UART_STATE_TRANSIENT_MASK  0x74
-#define UART_DCD   0x01
-#define UART_DSR   0x02
-#define UART_BREAK_ERROR   0x04
-#define UART_RING  0x08
-#define UART_FRAME_ERROR   0x10
-#define UART_PARITY_ERROR  0x20
-#define UART_OVERRUN_ERROR 0x40
-#define UART_CTS   0x80
-
 struct f81232_private {
spinlock_t lock;
u8 line_control;
@@ -511,7 +497,7 @@ static void f81232_dtr_rts(struct usb_serial_port *port, 
int on)
 static int f81232_carrier_raised(struct usb_serial_port *port)
 {
struct f81232_private *priv = usb_get_serial_port_data(port);
-   if (priv->modem_status & UART_DCD)
+   if (priv->modem_status & UART_MSR_DCD)
return 1;
return 0;
 }
-- 
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 V5 6/8] USB: f81232: clarify f81232_ioctl()

We extract TIOCGSERIAL section in f81232_ioctl() to f81232_get_serial_info()
to make it clarify

The f81232_set_mctrl() replace set_control_lines() to do MCR control
so we clean-up the set_control_lines() function.

Signed-off-by: Peter Hung 
---
 drivers/usb/serial/f81232.c | 34 +++---
 1 file changed, 23 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index e1cdf42..4dddb44 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -516,24 +516,36 @@ static int f81232_carrier_raised(struct usb_serial_port 
*port)
return 0;
 }
 
+static int f81232_get_serial_info(struct usb_serial_port *port,
+   unsigned long arg)
+{
+   struct serial_struct ser;
+
+   memset(, 0, sizeof(ser));
+
+   ser.flags   = ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ;
+   ser.xmit_fifo_size  = port->bulk_out_size;
+   ser.close_delay = 5 * HZ;
+   ser.closing_wait= 30 * HZ;
+   ser.type = PORT_16550A;
+   ser.line = port->minor;
+   ser.port = port->port_number;
+   ser.baud_base = 115200;
+
+   if (copy_to_user((void __user *)arg, , sizeof(ser)))
+   return -EFAULT;
+
+   return 0;
+}
+
 static int f81232_ioctl(struct tty_struct *tty,
unsigned int cmd, unsigned long arg)
 {
-   struct serial_struct ser;
struct usb_serial_port *port = tty->driver_data;
 
switch (cmd) {
case TIOCGSERIAL:
-   memset(, 0, sizeof ser);
-   ser.type = PORT_16654;
-   ser.line = port->minor;
-   ser.port = port->port_number;
-   ser.baud_base = 460800;
-
-   if (copy_to_user((void __user *)arg, , sizeof ser))
-   return -EFAULT;
-
-   return 0;
+   return f81232_get_serial_info(port, arg);
default:
break;
}
-- 
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 V5 0/8] USB: f81534: v5 patch

This series patch V5 is improvement from V4 as following:

1. transform all function not to use private data as parameter, using
   usb_serial_port instead.

2. Some init step we extract it from set_term() to f81232_port_init()
   and run it when open port only.

3. We'll force re-read msr in tiocmget() because the IIR with MSR change
   maybe delay received.

4. process_read_urb() add process of Break/FrameError/ParityError.

5. clarify a lot of code about Johan suggested.

Peter Hung (8):
  USB: f81232: Rename private struct member name
  USB: f81232: implement read IIR/MSR with endpoint
  USB: f81232: implement RX bulk-in ep
  USB: f81232: implement set_termios
  USB: f81232: implement MCR/MSR function
  USB: f81232: clarify f81232_ioctl()
  USB: f81232: fix error in f81232_carrier_raised()
  USB: f81232: modify/add author

 drivers/usb/serial/f81232.c | 471 +++-
 1 file changed, 375 insertions(+), 96 deletions(-)

-- 
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 V5 2/8] USB: f81232: implement read IIR/MSR with endpoint

The interrupt Endpoint will report current IIR. If we got IIR with MSR Changed
, We will do read MSR with interrupt_work worker to do f81232_read_msr() func.

Signed-off-by: Peter Hung 
---
 drivers/usb/serial/f81232.c | 109 
 1 file changed, 100 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index 669a2f2..ec4609d 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x1934, 0x0706) },
@@ -30,6 +31,13 @@ static const struct usb_device_id id_table[] = {
 };
 MODULE_DEVICE_TABLE(usb, id_table);
 
+/* USB Control EP parameter */
+#define F81232_REGISTER_REQUEST 0xA0
+#define F81232_GET_REGISTER 0xc0
+
+#define SERIAL_BASE_ADDRESS   0x0120
+#define MODEM_STATUS_REGISTER  (0x06 + SERIAL_BASE_ADDRESS)
+
 #define CONTROL_DTR0x01
 #define CONTROL_RTS0x02
 
@@ -48,19 +56,92 @@ struct f81232_private {
spinlock_t lock;
u8 line_control;
u8 modem_status;
+
+   struct work_struct interrupt_work;
+   struct usb_serial_port *port;
 };
 
-static void f81232_update_line_status(struct usb_serial_port *port,
+static int f81232_get_register(struct usb_serial_port *port,
+ u16 reg, u8 *data)
+{
+   int status;
+   struct usb_device *dev = port->serial->dev;
+
+   status = usb_control_msg(dev,
+usb_rcvctrlpipe(dev, 0),
+F81232_REGISTER_REQUEST,
+F81232_GET_REGISTER,
+reg,
+0,
+data,
+sizeof(*data),
+USB_CTRL_GET_TIMEOUT);
+   if (status < 0)
+   dev_err(>dev, "%s status: %d\n", __func__, status);
+
+   return status;
+}
+
+static void f81232_read_msr(struct usb_serial_port *port)
+{
+   int status;
+   unsigned long flags;
+   u8 current_msr;
+   struct tty_struct *tty;
+   struct f81232_private *priv = usb_get_serial_port_data(port);
+
+   status = f81232_get_register(port, MODEM_STATUS_REGISTER,
+   _msr);
+   if (status < 0) {
+   /* Retain the error even reported in f81232_get_register()
+to make debug easily :D */
+   dev_err(>dev, "%s fail, status: %d\n", __func__, status);
+   return;
+   }
+
+   if (!(current_msr & UART_MSR_ANY_DELTA))
+   return;
+
+   tty = tty_port_tty_get(>port);
+   if (tty) {
+   if (current_msr & UART_MSR_DDCD) {
+   usb_serial_handle_dcd_change(port, tty,
+   current_msr & UART_MSR_DCD);
+   }
+
+   tty_kref_put(tty);
+   }
+
+   spin_lock_irqsave(>lock, flags);
+   priv->modem_status = current_msr;
+   spin_unlock_irqrestore(>lock, flags);
+
+   wake_up_interruptible(>port.delta_msr_wait);
+}
+
+static void f81232_update_modem_status(struct usb_serial_port *port,
  unsigned char *data,
  unsigned int actual_length)
 {
-   /*
-* FIXME: Update port->icount, and call
-*
-*  wake_up_interruptible(>port.delta_msr_wait);
-*
-*on MSR changes.
-*/
+   struct f81232_private *priv = usb_get_serial_port_data(port);
+
+   if (!actual_length)
+   return;
+
+   switch (data[0] & 0x07) {
+   case 0x00: /* msr change */
+   dev_dbg(>dev, "IIR: MSR Change: %x\n", data[0]);
+   schedule_work(>interrupt_work);
+   break;
+   case 0x02: /* tx-empty */
+   break;
+   case 0x04: /* rx data available */
+   break;
+   case 0x06: /* lsr change */
+   /* we can forget it. the LSR will read from bulk-in */
+   dev_dbg(>dev, "IIR: LSR Change: %x\n", data[0]);
+   break;
+   }
 }
 
 static void f81232_read_int_callback(struct urb *urb)
@@ -91,7 +172,7 @@ static void f81232_read_int_callback(struct urb *urb)
usb_serial_debug_data(>dev, __func__,
  urb->actual_length, urb->transfer_buffer);
 
-   f81232_update_line_status(port, data, actual_length);
+   f81232_update_modem_status(port, data, actual_length);
 
 exit:
retval = usb_submit_urb(urb, GFP_ATOMIC);
@@ -270,6 +351,14 @@ static int f81232_ioctl(struct tty_struct *tty,
return -ENOIOCTLCMD;
 }
 
+static void  f81232_interrupt_work(struct work_struct *work)
+{
+   struct f81232_private *priv =
+   container_of(work, struct f81232_private, interrupt_work);
+
+

Re: [RFT/PATCH] Input: bfin_rotary - introduce open and close methods

2015-02-06 Thread Sonic Zhang

Hi Dmitry,

After apply your patch manually to my blackfin kernel tree, I got
kernel panic when probe the rotary.

NULL pointer access
Kernel OOPS in progress
Deferred Exception context
CURRENT PROCESS:
COMM=swapper PID=1  CPU=0
invalid mm
return address: [0x00167648]; contents of:
0x00167620:  f000  b068  0a08  1807  3038  3007  e801  
0x00167630:  05b3  0010  3044  6001  e3fc  da5a  b0a8  0c80
0x00167640:  191b    6802  6000 [e511] 0075  ac4a  9710
0x00167650:  ac4a  6c22  9710  a3a2  a0a9  0c02  18ec  cc00

CPU: 0 PID: 1 Comm: swapper Not tainted
3.17.0-ADI-2014R1-pre-00455-ga5d060e-dirty #5
task: 04025a20 ti: 04026000 task.ti: 04026000
Compiled for cpu family 0x27fe (Rev 0), but running on:0x (Rev 0)
ADSP-BF609-0.0 500(MHz CCLK) 125(MHz SCLK) (mpu off)
Linux version 3.17.0-ADI-2014R1-pre-00455-ga5d060e-dirty (sonic@nine)
(gcc version 4.3.5 (ADI-mast5

SEQUENCER STATUS:   Not tainted
 SEQSTAT: 0027  IPEND: 8008  IMASK:   SYSCFG: 2806
  EXCAUSE   : 0x27
  physical IVG3 asserted : <0xffa00744> { _trap + 0x0 }
  physical IVG15 asserted : <0xffa00d68> { _evt_system_call + 0x0 }
  logical irq   6 mapped  : <0xffa003bc> { _bfin_coretmr_interrupt + 0x0 }
  logical irq   7 mapped  : <0x8858> { _bfin_fault_routine + 0x0 }
  logical irq  11 mapped  : <0x7754> { _l2_ecc_err + 0x0 }
  logical irq  13 mapped  : <0x8858> { _bfin_fault_routine + 0x0 }
  logical irq  39 mapped  : <0x0016a350> { _bfin_twi_interrupt_entry + 0x0 }
  logical irq  40 mapped  : <0x0016a350> { _bfin_twi_interrupt_entry + 0x0 }
  logical irq  62 mapped  : <0x00132438> { _adi_spi_tx_dma_isr + 0x0 }
  logical irq  63 mapped  : <0x00132784> { _adi_spi_rx_dma_isr + 0x0 }
  logical irq  64 mapped  : <0x0013282c> { _spi_irq_err + 0x0 }
  logical irq  65 mapped  : <0x00132438> { _adi_spi_tx_dma_isr + 0x0 }
  logical irq  66 mapped  : <0x00132784> { _adi_spi_rx_dma_isr + 0x0 }
  logical irq  67 mapped  : <0x0013282c> { _spi_irq_err + 0x0 }
 RETE: <0x> /* Maybe null pointer? */
 RETN: <0x04027cf4> /* kernel dynamic memory (maybe user-space) */
 RETX: <0x0480> /* Maybe fixed code section */
 RETS: <0x0016763c> { _bfin_rotary_probe + 0x54 }
 PC  : <0x00167648> { _bfin_rotary_probe + 0x60 }
DCPLB_FAULT_ADDR: <0x01d4> /* Maybe null pointer? */
ICPLB_FAULT_ADDR: <0x00167648> { _bfin_rotary_probe + 0x60 }
PROCESSOR STATE:
 R0 : R1 : R2 : 0400R3 : 0001
 R4 : 0030c310R5 : 002d6680R6 : 002e7bd8R7 : 
 P0 : 0002P1 : 002e86acP2 : P3 : 002e8690
 P4 : 002e7bccP5 : 0409930cFP : 04027d10SP : 04027c18
 LB0: ffa015b8LT0: ffa015b8LC0: 
 LB1: 00094072LT1: 00094062LC1: 
 B0 : 001fL0 : M0 : 0402a400I0 : 04027c44
 B1 : 000eL1 : M1 : 002fa814I1 : 0407846c
 B2 : 0020L2 : M2 : I2 : 04028ac8
 B3 : 0022aa6cL3 : M3 : I3 : 001a
A0.w:    A0.x:    A1.w:    A1.x: 
USP :   ASTAT: 02003004

Hardware Trace:
   0 Target : <0x3fe8> { _trap_c + 0x0 }
 Source : <0xffa006d8> { _exception_to_level5 + 0xa0 } JUMP.L
   1 Target : <0xffa00638> { _exception_to_level5 + 0x0 }
 Source : <0xffa004f2> { _bfin_return_from_exception + 0x6 } RTX
   2 Target : <0xffa004ec> { _bfin_return_from_exception + 0x0 }
 Source : <0xffa00590> { _ex_trap_c + 0x70 } JUMP.S
   3 Target : <0xffa00520> { _ex_trap_c + 0x0 }
 Source : <0xffa0076e> { _trap + 0x2a } JUMP (P4)
   4 Target : <0xffa00744> { _trap + 0x0 }
  FAULT : <0x00167648> { _bfin_rotary_probe + 0x60 } P1 = [P2 + -0x54]
 Source : <0x00167646> { _bfin_rotary_probe + 0x5e } 0x6000
   5 Target : <0x0016763c> { _bfin_rotary_probe + 0x54 }
 Source : <0x00102b50> { _platform_get_irq + 0x64 } RTS
   6 Target : <0x00102b44> { _platform_get_irq + 0x58 }
 Source : <0x00102b2c> { _platform_get_irq + 0x40 } IF CC JUMP pcrel
   7 Target : <0x00102b0a> { _platform_get_irq + 0x1e }
 Source : <0x00102b28> { _platform_get_irq + 0x3c } IF !CC JUMP pcrel (BP)
   8 Target : <0x00102b14> { _platform_get_irq + 0x28 }
 Source : <0x00102b08> { _platform_get_irq + 0x1c } JUMP.S
   9 Target : <0x00102aec> { _platform_get_irq + 0x0 }
 Source : <0x00167638> { _bfin_rotary_probe + 0x50 } JUMP.L
  10 Target : <0x00167634> { _bfin_rotary_probe + 0x4c }
 Source : <0x00167626> { _bfin_rotary_probe + 0x3e } IF CC JUMP pcrel
  11 Target : <0x0016761e> { _bfin_rotary_probe + 0x36 }
 Source : <0x000d9c04> { _devm_ioremap_resource + 0x38 } RTS
  12 Target : <0x000d9bfe> { _devm_ioremap_resource + 0x32 }
 Source : <0x000d9c46> { _devm_ioremap_resource + 0x7a } IF !CC
JUMP pcrel (BP)
  13 Target : <0x000d9c44> { _devm_ioremap_resource + 0x78 }
 Source : <0x000d9b58> { _devm_ioremap_nocache + 0x3c } RTS
  14 Target : <0x000d9b50> { _devm_ioremap_nocache + 0x34 }
 Source : <0x00103bc8> { _devres_add

Re: [PATCH V4] acpi:apd:add AMD ACPI2Platform device support for x86 system.

2015-02-06 Thread mika.westerb...@linux.intel.com

On Fri, Feb 06, 2015 at 08:34:52AM +0800, Ken Xue wrote:
> >From 1a6a3a5c0815cb1f52ec0a2b9601edfa9bfebe81 Mon Sep 17 00:00:00 2001
> From: Ken Xue 
> Date: Fri, 6 Feb 2015 08:27:51 +0800
> Subject: [PATCH] acpi:apd:add AMD ACPI2Platform device support for x86 system.
> 
> This new feature is to interpret AMD specific ACPI device to
> platform device such as I2C, UART, GPIO found on AMD CZ and
> later chipsets. It based on example intel LPSS. Now, it can
> support AMD I2C, UART and GPIO.
> 
> Signed-off-by: Ken Xue 

Acked-by: Mika Westerberg 
--
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 1/1] coccinelle: misc: Semantic patch to find attempts at comparing struct clk pointers

2015-02-06 Thread Quentin Lambert

This semantic patches find instances where struct clk pointers are compared.

This was proposed by Stephen Boyd.

Signed-off-by: Quentin Lambert 
---

 This patch was discussed in this thread:
 https://lkml.org/lkml/2015/2/2/629

 scripts/coccinelle/misc/structclk.cocci | 44 +
 1 file changed, 44 insertions(+)
 create mode 100644 scripts/coccinelle/misc/structclk.cocci

diff --git a/scripts/coccinelle/misc/structclk.cocci 
b/scripts/coccinelle/misc/structclk.cocci
new file mode 100644
index 000..0307d34
--- /dev/null
+++ b/scripts/coccinelle/misc/structclk.cocci
@@ -0,0 +1,44 @@
+/// Find any attempt to compare struct clk pointers.
+///
+// Confidence: High
+// Copyright: (C) 2015 Quentin Lambert, INRIA/LiP6. GPLv2
+// URL: http://coccinelle.lip6.fr/
+// Options: --recursive-includes --relax-include-path
+// Options: --include-headers-for-types
+
+virtual context
+virtual org
+virtual report
+
+
+// 
+
+@comparison depends on context || org || report@
+struct clk *x1, x2;
+position j0;
+@@
+
+(
+*  x1@j0 == x2
+|
+*  x1@j0 != x2
+)
+
+// 
+
+@script:python comparison_org depends on org@
+j0 << comparison.j0;
+@@
+
+msg = "WARNING trying to compare struct clk pointers."
+coccilib.org.print_todo(j0[0], msg)
+
+// 
+
+@script:python comparison_report depends on report@
+j0 << comparison.j0;
+@@
+
+msg = "WARNING trying to compare struct clk pointers."
+coccilib.report.print_report(j0[0], msg)
+
-- 
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/

davinci-mcasp: extension to use AHCLKX pin as external clock source

2015-02-06 Thread Urs Fässler

The AHCLKX pin seems not to be supported as external source. The first
patch is a general fix to allow external clock. The second allows you to
select the AHCLKX pin as clock source.

Patch built against v3.19-rc7



signature.asc
Description: OpenPGP digital signature

[PATCH 1/2] davinci-mcasp: use bclk_master flag to decide if the SOC is clock master

2015-02-06 Thread Urs Fässler

Signed-off-by: Urs Fässler 
---
 sound/soc/davinci/davinci-mcasp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/davinci/davinci-mcasp.c
b/sound/soc/davinci/davinci-mcasp.c
index 30b94d4..396cdec 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -541,7 +541,7 @@ static int davinci_mcasp_set_sysclk(struct
snd_soc_dai *dai, int clk_id,
 {
struct davinci_mcasp *mcasp = snd_soc_dai_get_drvdata(dai);
 -  if (dir == SND_SOC_CLOCK_OUT) {
+   if (mcasp->bclk_master) {
mcasp_set_bits(mcasp, DAVINCI_MCASP_AHCLKXCTL_REG, AHCLKXE);
mcasp_set_bits(mcasp, DAVINCI_MCASP_AHCLKRCTL_REG, AHCLKRE);
mcasp_set_bits(mcasp, DAVINCI_MCASP_PDIR_REG, AHCLKX);
-- 
2.1.4




signature.asc
Description: OpenPGP digital signature

[PATCH 2/2] davinci-mcasp: add option to use AHCLKX pin as clock in

2015-02-06 Thread Urs Fässler

Signed-off-by: Urs Fässler 
---
 .../bindings/sound/davinci-mcasp-audio.txt |  1 +
 sound/soc/davinci/davinci-mcasp.c  | 26
+++---
 2 files changed, 24 insertions(+), 3 deletions(-)

diff --git
a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
index 46bc982..22a91d2 100644
--- a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
+++ b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
@@ -39,6 +39,7 @@ Optional properties:
 please refer to pinctrl-bindings.txt
 - fck_parent : Should contain a valid clock name which will be used as
parent
   for the McASP fck
+- ahclkx-pin : if set use AHCLKX pin for clock in instead of ACLKX
  Example:
 diff --git a/sound/soc/davinci/davinci-mcasp.c
b/sound/soc/davinci/davinci-mcasp.c
index 396cdec..3730288 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -85,6 +85,7 @@ struct davinci_mcasp {
int sysclk_freq;
boolbclk_master;
+   boolahclkx_pin;
/* McASP FIFO related */
u8  txnumevt;
@@ -429,7 +430,12 @@ static int davinci_mcasp_set_dai_fmt(struct
snd_soc_dai *cpu_dai,
break;
case SND_SOC_DAIFMT_CBM_CFS:
/* codec is clock master and frame slave */
-   mcasp_clr_bits(mcasp, DAVINCI_MCASP_ACLKXCTL_REG, ACLKXE);
+   if (mcasp->ahclkx_pin)
+   mcasp_set_bits(mcasp, DAVINCI_MCASP_ACLKXCTL_REG,
+   ACLKXE);
+   else
+   mcasp_clr_bits(mcasp, DAVINCI_MCASP_ACLKXCTL_REG,
+   ACLKXE);
mcasp_set_bits(mcasp, DAVINCI_MCASP_TXFMCTL_REG, AFSXE);
mcasp_clr_bits(mcasp, DAVINCI_MCASP_ACLKRCTL_REG, ACLKRE);
@@ -441,7 +447,12 @@ static int davinci_mcasp_set_dai_fmt(struct
snd_soc_dai *cpu_dai,
break;
case SND_SOC_DAIFMT_CBM_CFM:
/* codec is clock and frame master */
-   mcasp_clr_bits(mcasp, DAVINCI_MCASP_ACLKXCTL_REG, ACLKXE);
+   if (mcasp->ahclkx_pin)
+   mcasp_set_bits(mcasp, DAVINCI_MCASP_ACLKXCTL_REG,
+   ACLKXE);
+   else
+   mcasp_clr_bits(mcasp, DAVINCI_MCASP_ACLKXCTL_REG,
+   ACLKXE);
mcasp_clr_bits(mcasp, DAVINCI_MCASP_TXFMCTL_REG, AFSXE);
mcasp_clr_bits(mcasp, DAVINCI_MCASP_ACLKRCTL_REG, ACLKRE);
@@ -542,7 +553,12 @@ static int davinci_mcasp_set_sysclk(struct
snd_soc_dai *dai, int clk_id,
struct davinci_mcasp *mcasp = snd_soc_dai_get_drvdata(dai);
if (mcasp->bclk_master) {
-   mcasp_set_bits(mcasp, DAVINCI_MCASP_AHCLKXCTL_REG, AHCLKXE);
+   if (mcasp->ahclkx_pin)
+   mcasp_clr_bits(mcasp, DAVINCI_MCASP_AHCLKXCTL_REG,
+   AHCLKXE);
+   else
+   mcasp_set_bits(mcasp, DAVINCI_MCASP_AHCLKXCTL_REG,
+   AHCLKXE);
mcasp_set_bits(mcasp, DAVINCI_MCASP_AHCLKRCTL_REG, AHCLKRE);
mcasp_set_bits(mcasp, DAVINCI_MCASP_PDIR_REG, AHCLKX);
} else {
@@ -1340,6 +1356,8 @@ static struct davinci_mcasp_pdata
*davinci_mcasp_set_pdata_from_of(
if (ret >= 0)
pdata->sram_size_capture = val;
 +  pdata->clk_input_pin = of_property_read_bool(np, "ahclkx-pin");
+
return  pdata;
  nodata:
@@ -1412,6 +1430,8 @@ static int davinci_mcasp_probe(struct
platform_device *pdev)
goto err;
}
 +  mcasp->ahclkx_pin = pdata->clk_input_pin;
+
mcasp->op_mode = pdata->op_mode;
/* sanity check for tdm slots parameter */
if (mcasp->op_mode == DAVINCI_MCASP_IIS_MODE) {
-- 
2.1.4




signature.asc
Description: OpenPGP digital signature

Re: [PATCH] mtd: denali: Disable sub-page writes in Denali NAND driver

2015-02-06 Thread Richard Weinberger

Am 06.02.2015 um 09:29 schrieb Ricard Wanderlof:
> 
> On Thu, 5 Feb 2015, Graham Moore wrote:
> 
>> Actually, we made this change to make UBIFS work.  So, yes, the driver 
>> never worked for UBI.  Worked fine for JFFS2, raw data.
>>
>> A customer reported an issue with ECC errors when using UBIFS on NAND 
>> flash with Altera SoC.
>>
>> We debugged it and found the ECC errors occur because the UBI subsystem 
>> is trying to write sub-pages in the NAND, but neither the NAND chip 
>> itself nor the Denali NAND controller support sub-page writes.
> 
> Just a bit curious.
> 
> It is not uncommon for controllers or chips not to support sub-page 
> writes. In that case however, the partition(s) used by UBI should be 
> formatted accordingly, i.e. using the appropriate --sub-page-size argument 
> to ubiformat (when formatting partitions on the system itself), or the 
> corresponding argument to ubinize (when preparing images offline).
> 
> If that is done correctly, then the lack of subpage write capability is 
> not a problem per se (of course, the UBI EC and VID headers then take up 
> more space so less space is available for user data; on a flash with 2k 
> pages it is only 2k bytes per LEB that is lost however).

Yeah, but UBI automatically will use subpages unless you specify
use the vid_hdr_offs parameter.
IOW, if the driver advertises subpages UBI will use them.

Thanks,
//richard
--
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] drm/nouveau/clk: Change rate from u32 to u64 in gk20a_pllg_calc_rate()

2015-02-06 Thread Alexandre Courbot


On 02/06/2015 06:20 PM, Geert Uytterhoeven wrote:

On 32-bit platforms using asm-generic/div64.h:

drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c: In function 
'gk20a_pllg_calc_rate':
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:147:79: warning: comparison of 
distinct pointer types lacks a cast
   do_div(rate, divider);

^
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:147:2: warning: right shift count 
>= width of type
   do_div(rate, divider);
   ^
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:147:238: warning: passing 
argument 1 of '__div64_32' from incompatible pointer type
   do_div(rate, divider);


   ^
In file included from arch/parisc/include/generated/asm/div64.h:1:0,
  from include/linux/kernel.h:124,
  from include/linux/list.h:8,
  from include/linux/preempt.h:10,
  from include/linux/spinlock.h:50,
  from include/linux/mmzone.h:7,
  from include/linux/gfp.h:5,
  from include/linux/slab.h:14,
  from drivers/gpu/drm/nouveau/include/nvif/os.h:5,
  from drivers/gpu/drm/nouveau/include/nvkm/core/os.h:3,
  from drivers/gpu/drm/nouveau/include/nvkm/core/object.h:3,
  from drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h:3,
  from drivers/gpu/drm/nouveau/include/nvkm/subdev/clk.h:3,
  from drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:25:
include/asm-generic/div64.h:35:17: note: expected 'uint64_t *' but argument is 
of type 'u32 *'
  extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
  ^

do_div() is meant for 64-bit by 32-bit division, but both the dividend
and divisor are 32-bit here, causing the warning.

As the product of priv->parent_rate and priv->n may no longer fit in u32
soon, change rate from u32 to u64, which also fixes the warning.

Signed-off-by: Geert Uytterhoeven 
---
Compile-tested only.

This is v2 of "drm/nouveau/clk: Use plain "/" for 32-bit division".

v2:
   - Change rate from u32 to u64 instead of changing the division.

parisc/allmodconfig:
http://kisskb.ellerman.id.au/kisskb/buildresult/12358386/
---
  drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
index 65c532742b08d1c6..e87a964b8bea4d30 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
@@ -139,7 +139,7 @@ gk20a_pllg_read_mnp(struct gk20a_clk_priv *priv)
  static u32
  gk20a_pllg_calc_rate(struct gk20a_clk_priv *priv)
  {
-   u32 rate;
+   u64 rate;
u32 divider;

rate = priv->parent_rate * priv->n;



Tested-by: Alexandre Courbot 

Adding Ben as he might want to take this in his tree?
--
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: [RFT/PATCH] Input: bfin_rotary - introduce open and close methods

2015-02-06 Thread Sonic Zhang

Hi Dmitry,

On Fri, Feb 6, 2015 at 2:56 PM, Dmitry Torokhov
 wrote:
> Introduce open and close methods for the input device to postpone enabling
> the device until it is needed.
>
> Signed-off-by: Dmitry Torokhov 
> ---
>
> Hi Sonic,
>
> Could you please tell me if the driver still works with this parch?
>
> Thanks!
>
>  drivers/input/misc/bfin_rotary.c | 70 
> 
>  1 file changed, 42 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/input/misc/bfin_rotary.c 
> b/drivers/input/misc/bfin_rotary.c
> index 09d7612..1bc9409 100644
> --- a/drivers/input/misc/bfin_rotary.c
> +++ b/drivers/input/misc/bfin_rotary.c
> @@ -35,6 +35,10 @@ struct bfin_rot {
> unsigned int down_key;
> unsigned int button_key;
> unsigned int rel_code;
> +
> +   unsigned short mode;
> +   unsigned short debounce;
> +
> unsigned short cnt_config;
> unsigned short cnt_imask;
> unsigned short cnt_debounce;
> @@ -94,6 +98,35 @@ static irqreturn_t bfin_rotary_isr(int irq, void *dev_id)
> return IRQ_HANDLED;
>  }
>
> +static int bfin_rotary_open(struct input_dev *input)
> +{
> +   struct bfin_rot *rotary = input_get_drvdata(input);
> +   unsigned short val;
> +
> +   if (rotary->mode & ROT_DEBE)
> +   writew(rotary->debounce & DPRESCALE,
> +   rotary->base + CNT_DEBOUNCE_OFF);
> +
> +   writew(rotary->mode & ~CNTE, rotary->base + CNT_CONFIG_OFF);
> +
> +   val = UCIE | DCIE;
> +   if (rotary->button_key)
> +   val |= CZMIE;
> +   writew(val, rotary->base + CNT_IMASK_OFF);
> +
> +   writew(rotary->mode | CNTE, rotary->base + CNT_CONFIG_OFF);
> +
> +   return 0;
> +}
> +
> +static void bfin_rotary_close(struct input_dev *input)
> +{
> +   struct bfin_rot *rotary = input_get_drvdata(input);
> +
> +   writew(0, rotary->base + CNT_CONFIG_OFF);
> +   writew(0, rotary->base + CNT_IMASK_OFF);
> +}
> +
>  static void bfin_rotary_free_action(void *data)
>  {
> peripheral_free_list(data);
> @@ -154,6 +187,9 @@ static int bfin_rotary_probe(struct platform_device *pdev)
> rotary->button_key = pdata->rotary_button_key;
> rotary->rel_code = pdata->rotary_rel_code;
>
> +   rotary->mode = pdata->mode;
> +   rotary->debounce = pdata->debounce;
> +
> input->name = pdev->name;
> input->phys = "bfin-rotary/input0";
> input->dev.parent = >dev;
> @@ -165,6 +201,9 @@ static int bfin_rotary_probe(struct platform_device *pdev)
> input->id.product = 0x0001;
> input->id.version = 0x0100;
>
> +   input->open = bfin_rotary_open;
> +   input->close = bfin_rotary_close;
> +
> if (rotary->up_key) {
> __set_bit(EV_KEY, input->evbit);
> __set_bit(rotary->up_key, input->keybit);
> @@ -179,6 +218,9 @@ static int bfin_rotary_probe(struct platform_device *pdev)
> __set_bit(rotary->button_key, input->keybit);
> }
>
> +   /* Quiesce the device before requesting irq */
> +   bfin_rotary_close(input);
> +
> rotary->irq = platform_get_irq(pdev, 0);
> if (rotary->irq < 0) {
> dev_err(dev, "No rotary IRQ specified\n");

Could you generate the patch after applying patch "bfin_rotary:
convert to use managed resources"?
Your code base is different from mine. The above 3 lines doesn't exist
with the managed resources patch.

Thanks,

Sonic


> @@ -199,39 +241,12 @@ static int bfin_rotary_probe(struct platform_device 
> *pdev)
> return error;
> }
>
> -   if (pdata->rotary_button_key)
> -   writew(CZMIE, rotary->base + CNT_IMASK_OFF);
> -
> -   if (pdata->mode & ROT_DEBE)
> -   writew(pdata->debounce & DPRESCALE,
> -   rotary->base + CNT_DEBOUNCE_OFF);
> -
> -   if (pdata->mode)
> -   writew(readw(rotary->base + CNT_CONFIG_OFF) |
> -   (pdata->mode & ~CNTE),
> -   rotary->base + CNT_CONFIG_OFF);
> -
> -   writew(readw(rotary->base + CNT_IMASK_OFF) | UCIE | DCIE,
> -   rotary->base + CNT_IMASK_OFF);
> -   writew(readw(rotary->base + CNT_CONFIG_OFF) | CNTE,
> -   rotary->base + CNT_CONFIG_OFF);
> -
> platform_set_drvdata(pdev, rotary);
> device_init_wakeup(>dev, 1);
>
> return 0;
>  }
>
> -static int bfin_rotary_remove(struct platform_device *pdev)
> -{
> -   struct bfin_rot *rotary = platform_get_drvdata(pdev);
> -
> -   writew(0, rotary->base + CNT_CONFIG_OFF);
> -   writew(0, rotary->base + CNT_IMASK_OFF);
> -
> -   return 0;
> -}
> -
>  static int __maybe_unused bfin_rotary_suspend(struct device *dev)
>  {
> struct platform_device *pdev = to_platform_device(dev);
> @@ -270,7 +285,6 @@ static SIMPLE_DEV_PM_OPS(bfin_rotary_pm_ops,
>
>  static struct platform_driver bfin_rotary_device_driver = {
>

[PATCH v2] drm/nouveau/clk: Change rate from u32 to u64 in gk20a_pllg_calc_rate()

2015-02-06 Thread Geert Uytterhoeven

On 32-bit platforms using asm-generic/div64.h:

drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c: In function 
'gk20a_pllg_calc_rate':
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:147:79: warning: comparison of 
distinct pointer types lacks a cast
  do_div(rate, divider);
   ^
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:147:2: warning: right shift 
count >= width of type
  do_div(rate, divider);
  ^
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:147:238: warning: passing 
argument 1 of '__div64_32' from incompatible pointer type
  do_div(rate, divider);


  ^
In file included from arch/parisc/include/generated/asm/div64.h:1:0,
 from include/linux/kernel.h:124,
 from include/linux/list.h:8,
 from include/linux/preempt.h:10,
 from include/linux/spinlock.h:50,
 from include/linux/mmzone.h:7,
 from include/linux/gfp.h:5,
 from include/linux/slab.h:14,
 from drivers/gpu/drm/nouveau/include/nvif/os.h:5,
 from drivers/gpu/drm/nouveau/include/nvkm/core/os.h:3,
 from drivers/gpu/drm/nouveau/include/nvkm/core/object.h:3,
 from drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h:3,
 from drivers/gpu/drm/nouveau/include/nvkm/subdev/clk.h:3,
 from drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:25:
include/asm-generic/div64.h:35:17: note: expected 'uint64_t *' but argument is 
of type 'u32 *'
 extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
 ^

do_div() is meant for 64-bit by 32-bit division, but both the dividend
and divisor are 32-bit here, causing the warning.

As the product of priv->parent_rate and priv->n may no longer fit in u32
soon, change rate from u32 to u64, which also fixes the warning.

Signed-off-by: Geert Uytterhoeven 
---
Compile-tested only.

This is v2 of "drm/nouveau/clk: Use plain "/" for 32-bit division".

v2:
  - Change rate from u32 to u64 instead of changing the division.

parisc/allmodconfig:
http://kisskb.ellerman.id.au/kisskb/buildresult/12358386/
---
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
index 65c532742b08d1c6..e87a964b8bea4d30 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
@@ -139,7 +139,7 @@ gk20a_pllg_read_mnp(struct gk20a_clk_priv *priv)
 static u32
 gk20a_pllg_calc_rate(struct gk20a_clk_priv *priv)
 {
-   u32 rate;
+   u64 rate;
u32 divider;
 
rate = priv->parent_rate * priv->n;
-- 
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: [RFC PATCH 0/3] Fix power domains handling on exynos542x

2015-02-06 Thread Javier Martinez Canillas

Hello Joonyoung,

On 02/06/2015 06:27 AM, Joonyoung Shim wrote:
> On 02/05/2015 11:45 PM, Javier Martinez Canillas wrote:
>> 
>> I also tested on an Exynos5420 Peach Pit Chromebook and both the "Power
>> domain power-domain disable failed" message and the system crash are gone.
>> 
> 
> Really gone out "Power domain power-domain disable failed" message?
> 
> Still i get the message from second try,
> 
> # modetest -M exynos -s 23@21:1920x1080
> setting mode 1920x1080@XR24 on connectors 23, crtc 21
> 
> # modetest -M exynos -s 23@21:1920x1080
> setting mode 1920x1080@XR24 on connectors 23, crtc 21
> 
> [   39.608881] Power domain power-domain disable failed
> # modetest -M exynos -s 23@21:1920x1080
> setting mode 1920x1080@XR24 on connectors 23, crtc 21
> 
> [   42.827637] Power domain power-domain disable failed
> ...
>

You are right, I tested that if I execute:

# for val in 1 0; do echo $val > 
/sys/class/drm/card0/device/graphics/fb0/blank; done

many times I see the "Power domain power-domain disable failed" message
again and there is no output in the HDMI display when dpms on.

But even in that case, the imprecise external abort does not happen when the
exynos_mixer driver tries to access the mixer registers and the system does
not crash anymore.

So I think that Andrzej's patches are at least a step in the right direction.
 
Best regards,
Javier
--
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] video: fbdev: use msecs_to_jiffies for time conversion

2015-02-06 Thread Nicholas Mc Guire

This is only an API consolidation and should make things more readable
it replaces var * HZ / 1000 by msecs_to_jiffies(var).

Signed-off-by: Nicholas Mc Guire 
---

Patch was only compile tested with viper_defconfig (implies CONFIG_FB_PXA=m)

Patch is against 3.19.0-rc7 (localversion-next is -next-20150204)

 drivers/video/fbdev/pxafb.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
index da2431e..d8b4743 100644
--- a/drivers/video/fbdev/pxafb.c
+++ b/drivers/video/fbdev/pxafb.c
@@ -1285,7 +1285,7 @@ static int pxafb_smart_thread(void *arg)
mutex_unlock(>ctrlr_lock);
 
set_current_state(TASK_INTERRUPTIBLE);
-   schedule_timeout(30 * HZ / 1000);
+   schedule_timeout(msecs_to_jiffies(30));
}
 
pr_debug("%s(): task ending\n", __func__);
@@ -1460,7 +1460,7 @@ static void pxafb_disable_controller(struct pxafb_info 
*fbi)
 #ifdef CONFIG_FB_PXA_SMARTPANEL
if (fbi->lccr0 & LCCR0_LCDT) {
wait_for_completion_timeout(>refresh_done,
-   200 * HZ / 1000);
+   msecs_to_jiffies(200);
return;
}
 #endif
@@ -1472,7 +1472,7 @@ static void pxafb_disable_controller(struct pxafb_info 
*fbi)
lcd_writel(fbi, LCCR0, lccr0);
lcd_writel(fbi, LCCR0, lccr0 | LCCR0_DIS);
 
-   wait_for_completion_timeout(>disable_done, 200 * HZ / 1000);
+   wait_for_completion_timeout(>disable_done, msecs_to_jiffies(200));
 
/* disable LCD controller clock */
clk_disable_unprepare(fbi->clk);
-- 
1.7.10.4

--
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: [Cocci] [PATCH v13 3/6] clk: Make clk API return per-user struct clk instances

2015-02-06 Thread Julia Lawall

On Fri, 6 Feb 2015, Quentin Lambert wrote:

>
> On 06/02/2015 03:15, Stephen Boyd wrote:
> > Thanks for the coccinelle patch. Thinking more about it, I don't think
> > we care if the pointer is dereferenced because that would require a
> > definition of struct clk and that is most likely not the case outside of
> > the clock framework. Did you scan the entire kernel?
> No I haven't.
> > I'm running it now
> > but it seems to be taking a while.
> >
> Yes, that's why, as a first step, I chose to limit the scan to the arm
> directory.

Are you sure to be using all of the options provided:

// Options: --recursive-includes --relax-include-path
// Options: --include-headers-for-types

And are you using 1.0.0-rc23 or 1.0.0-rc24?  Those should save parsed
header files so that they don't have to be parsed over and over.

If you are using rc24, then you can use the -j option for parallelism.
But then you should also use an option like --chunksize 10 (I don't know
what number would be good), because the default is chunksize 1, and in
that case the saved parsed header files are not reused, because the fies
are all processed individually.  In general, it is only the files within a
chunk that will share parsed header files.

julia
--
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/3] genirq: Allow the irqchip state of an IRQ to be save/restored

2015-02-06 Thread Marc Zyngier

On 05/02/15 23:33, Bjorn Andersson wrote:
> On Wed, Jan 7, 2015 at 9:51 AM, Marc Zyngier  wrote:
>> There is a number of cases where a kernel subsystem may want to
>> introspect the state of an interrupt at the irqchip level:
>>
>> - When a peripheral is shared between virtual machines,
>>   its interrupt state becomes part of the guest's state,
>>   and must be switched accordingly. KVM on arm/arm64 requires
>>   this for its guest-visible timer
>> - Some GPIO controllers seem to require peeking into the
>>   interrupt controller they are connected to to report
>>   their internal state
>>
>> This seem to be a pattern that is common enough for the core code
>> to try and support this without too many horrible hacks. Introduce
>> a pair of accessors (irq_get_irqchip_state/irq_set_irqchip_state)
>> to retrieve the bits that can be of interest to another subsystem:
>> pending, active, and masked.
>>
>> - irq_get_irqchip_state returns the state of the interrupt according
>>   to a parameter set to IRQCHIP_STATE_PENDING, IRQCHIP_STATE_ACTIVE,
>>   IRQCHIP_STATE_MASKED or IRQCHIP_STATE_LINE_LEVEL.
>> - irq_set_irqchip_state similarly sets the state of the interrupt.
>>
>> Reviewed-by: Bjorn Andersson 
>> Tested-by: Bjorn Andersson 
>> Signed-off-by: Marc Zyngier 
> 
> Any update on the status of this?
> 
> I would like to be able to move ahead with the pinctrl driver for the
> Qualcomm PM8921 pmic, that depends on this being in place.

None so far.

Thomas, do you have any comment on this one?

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
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] Input: bfin_rotary - mark suspend and resume code as __maybe_unused

2015-02-06 Thread Sonic Zhang

Hi Dmitry,

On Fri, Feb 6, 2015 at 2:09 PM, Dmitry Torokhov
 wrote:
> Instead of using #ifdef to guard potentially unused suspend and resume code
> let's mark them as __maybe_unused so they still get discarded if they are
> not used but we do not get warning. This allows for better compile coverage.
>
> Signed-off-by: Dmitry Torokhov 
> ---
>  drivers/input/misc/bfin_rotary.c | 14 --
>  1 file changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/input/misc/bfin_rotary.c 
> b/drivers/input/misc/bfin_rotary.c
> index a39793c..09d7612 100644
> --- a/drivers/input/misc/bfin_rotary.c
> +++ b/drivers/input/misc/bfin_rotary.c
> @@ -232,8 +232,7 @@ static int bfin_rotary_remove(struct platform_device 
> *pdev)
> return 0;
>  }
>
> -#ifdef CONFIG_PM
> -static int bfin_rotary_suspend(struct device *dev)
> +static int __maybe_unused bfin_rotary_suspend(struct device *dev)
>  {
> struct platform_device *pdev = to_platform_device(dev);
> struct bfin_rot *rotary = platform_get_drvdata(pdev);
> @@ -248,7 +247,7 @@ static int bfin_rotary_suspend(struct device *dev)
> return 0;
>  }
>
> -static int bfin_rotary_resume(struct device *dev)
> +static int __maybe_unused bfin_rotary_resume(struct device *dev)
>  {
> struct platform_device *pdev = to_platform_device(dev);
> struct bfin_rot *rotary = platform_get_drvdata(pdev);
> @@ -266,20 +265,15 @@ static int bfin_rotary_resume(struct device *dev)
> return 0;
>  }
>
> -static const struct dev_pm_ops bfin_rotary_pm_ops = {
> -   .suspend= bfin_rotary_suspend,
> -   .resume = bfin_rotary_resume,
> -};
> -#endif
> +static SIMPLE_DEV_PM_OPS(bfin_rotary_pm_ops,
> +bfin_rotary_suspend, bfin_rotary_resume);
>
>  static struct platform_driver bfin_rotary_device_driver = {
> .probe  = bfin_rotary_probe,
> .remove = bfin_rotary_remove,
> .driver = {
> .name   = "bfin-rotary",

You missed
   .owner  = THIS_MODULE,
here.


> -#ifdef CONFIG_PM
> .pm = _rotary_pm_ops,
> -#endif
> },
>  };
>  module_platform_driver(bfin_rotary_device_driver);
> --
> 2.2.0.rc0.207.ga3a616c
>
>

Regards,

Sonic
--
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 3/3] arm64: dts: Add dts files for Hisilicon Hi6220 SoC

2015-02-06 Thread Marc Zyngier

On 06/02/15 08:42, Brent Wang wrote:

[...]

>>
>>> +   <0x0 0xf6802000 0x0 0x2000>, /* GICC */
>>> +   <0x0 0xf6804000 0x0 0x2000>, /* GICH */
>>> +   <0x0 0xf6806000 0x0 0x2000>; /* GICV */
>>
>> I guess no-one's bothered to consider 64k pages?
>>
>> Given GICH and GICV, I hope that this platform is booted at EL2?
> Transfer from EL3 to EL1 directly, keep these two just for future use.

That's a real shame, as it keeps users away from some key aspects of the
ARMv8 architecture.

>>
>>> + #interrupt-cells = <3>;
>>> + #address-cells = <0>;
>>> + interrupt-controller;

And if you're keeping GICH/GICV, where is the maintenance interrupt?

>>> + };
>>> +
>>> +
>>> + timer {
>>> + compatible = "arm,armv8-timer";
>>> + interrupt-parent = <>;
>>> + interrupts = <1 13 0xff08>,
>>> +  <1 14 0xff08>,
>>> +  <1 11 0xff08>,
>>> +  <1 10 0xff08>;
>>> + clock-frequency = <120>;
>>> + };
>>
>> NAK. Fix your firmware to configure CNTFRQ, on all CPUs.
> Fix in next version, maybe it will take some time to change firmware.

While you're at it, make sure CNTVOFF_EL2 is set to zero on all CPUs
before dropping to EL1. This tends to be overlooked.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
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: [Cocci] [PATCH v13 3/6] clk: Make clk API return per-user struct clk instances

2015-02-06 Thread Quentin Lambert



On 06/02/2015 03:15, Stephen Boyd wrote:

Thanks for the coccinelle patch. Thinking more about it, I don't think
we care if the pointer is dereferenced because that would require a
definition of struct clk and that is most likely not the case outside of
the clock framework. Did you scan the entire kernel?

No I haven't.

I'm running it now
but it seems to be taking a while.

Yes, that's why, as a first step, I chose to limit the scan to the arm 
directory.

--
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 6/6 v2] perf: Make perf aware of tracefs

2015-02-06 Thread Arnaldo Carvalho de Melo

Em Tue, Feb 03, 2015 at 11:45:50AM -0500, Steven Rostedt escreveu:
> On Tue, 3 Feb 2015 15:16:25 +0100
> Jiri Olsa  wrote:
> > I guess you ommited the fprint(stderr... ) warning on purpose
> > (like in find_debugfs), because the tracefs is not upstream yet, right?
 
> Right, because I didn't want people complaining about using a new perf
> with an old kernel, and suddenly get warnings.
 
> > maybe we want at least pr_debug warning here..
> > anyway, other than that the patchset looks ok to me:
 
> I was thinking that we could add one later, when tracefs is more common.
 
> > Acked-by: Jiri Olsa 
 
> Arnaldo, do you want to pick this up?

I will, but traveling now, as soon as I can I'll look at it and put it
in my perf/core branch.

- Arnaldo
--
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] linux-firmware: update firmware for Intel Broadwell SST DSP

2015-02-06 Thread Kyle McMartin

On Thu, Feb 05, 2015 at 11:27:04PM +0800, Jie Yang wrote:
> Update firmware intel/IntcSST2.bin from Version 8.4.1.68 to 8.4.1.77
> Fix for freeing capture stream just after resetting it.
> 
> Signed-off-by: Jie Yang 

applied, thanks Jie.

regards, Kyle

> ---
>  WHENCE |   1 +
>  intel/IntcSST2.bin | Bin 260256 -> 260320 bytes
>  2 files changed, 1 insertion(+)
> 
> diff --git a/WHENCE b/WHENCE
> index 7f2d6bf..6cb0778 100644
> --- a/WHENCE
> +++ b/WHENCE
> @@ -2646,6 +2646,7 @@ Licence: Redistributable. See LICENCE.it913x for details
>  Driver: snd_soc_sst_acpi
>  
>  File: intel/IntcSST2.bin
> +Version: 8.4.1.77
>  
>  License: Redistributable. See LICENCE.IntcSST2 for details
>  
> diff --git a/intel/IntcSST2.bin b/intel/IntcSST2.bin
> index 
> 69ac37e78582dc5971b56eb598f43821958a9a59..e11cb61f4a00bf32a304781e3e9b1f32775285e1
>  100644
> GIT binary patch
> delta 35726
> zcmZTQ30zZ0^VuW>2oK~8w?O16AS%HV#UrQ)-guu?g3ntk+QXZpEk+R95C
> z1q3z014NXdASf!}g=a;5UU+~gf};7)CeW|_{``KAw>vv~% z>eOi^ts;SiKp^;p6Ocoyw;0_^rH9*B-$H^}w~@f{4iX$*9w7+5tNm(@$Zq{cp&-i~
> zu;DM%P9V64>qXs!wu$)?u?(R@*wd`f{Px^PfyI;vfjBQxFbm%6;XyBj0t)i!khX<)
> zE4(S_)naOdz!CB;@LsbrLJ$Gz$>9-#5%7$Mv>(9Ziv)trP__v2$vE4rXGk5S46h6Z
> z!}kWmJxFIl=}veaLRuh*k83<85EPJ_&`Jfo4P69+c7s6h1Y1i6+C3+=4T8qQP-FeH
> z2*DdXUD7w89iZt8A_Q5hA_RWZBLuBbLK?F;5Ghz=hoFXGI6S9Zu4A1fcxWJi1qTcU
> zk-!kw7$6kX!BYZH7CbxQSr1S8Yk^=Pyd$EzkNH5<56?F56Fmspv6ul}
> z#X>o}VPFEkNx%Sr`$3*sV;qLSGZE^Jh!Ct?1dM{GWQFNT+6Tw^o?jU$<0e=+K
> zjexWxq$BWC^L3Wv0b($GG8ACOq6eCcf3UcOX5smkGtokP#L~;ZdOjk=B7wI+un2G+
> zV}TK$MF^Hcx!S;q3y zpc5X8vG9x*3jE-i1 zfL6D|7=b&4MRm~;g2RA68G4MEDHOCqxr+)$0O>X4NkxLXok%blo`Ro{zz?2u>}utO
> zDsYIES9G!t2}+`2wqjtUF%g2>&{l;lFc?NuvQj9pT?Z0>)#39@cyG5ky(H+12!XlF
> z-iX#UFw2mh{5en;^?v0>A3L1Ar2vRa51b@ByYL4yN2*E;JXf?#M5$3e9~d#
> zIeG&<2n1q5<|QIZ9}M@f9p{T$Z7G`tWgb2Z*rKXvFSO>Jn3k8Rl0pI@u?F0B3
> z97Q>Fy#mmMfLQ_hcmmR`@Qwr>71#&_W_NHRmDIhxd-U;-vBy6q6n#uB`p6Z1Tq z;t_r1W9*TS2}dFKv$@UmrTM+BeGxi>r`kL~KjDF0f~3zq)bebdJeMDlAKPU z+aPp1!k%`XfII}!PI#7GA9NZg+XcE#_AHej(8=>^|9GPge08&`hHJlBbVo@4
> zg)i6*L^?FGsg=ANws9de1yzu~3tV58JOssrlU;zCma`-siXl#bVmYA1U%DIeCka
> zKVIYVK)%RYa>)=Wnf%DX)?1+FR_gxvmWi>ZN zS(l$MsJRuo%ys-ke8}zPfZ^8RRR>XY_FENOMz*l&-TOeyDX;uug6}I48UYszOJr
> zHKF*5`+iS_v1ubHhgMkYTieR7cQj51;oTlfQ9L!G|zsXuf2v!WjW@QM6=$j
>

Re: [PATCH 3/3] arm64: dts: Add dts files for Hisilicon Hi6220 SoC

2015-02-06 Thread Brent Wang

Hello Mark,

2015-02-06 3:30 GMT+08:00 Mark Rutland :
> On Thu, Feb 05, 2015 at 09:24:37AM +, Bintian Wang wrote:
>> Add initial dtsi file to support Hisilicon Hi6220 SoC with
>> support of Octal core CPUs in two clusters and each cluster
>> has quard Cortex-A53.
>>
>> We now use the "spin-table" method for SMP, and it will be
>> changed to PSCI later.
>
> If that's the case, please don't place the enable-method and related
> properties in this file. Get your bootloader to add the appropriate
> properties for its boot protocol.
>
> When is PSCI likely to appear?
PSCI is under development.

>
> Are we certain of the split between components the PSCI implementation
> must touch and those the kernel must touch?
>
>> Also add dts file to support HiKey development board which
>> based on Hi6220 SoC and document the devicetree bindings.
>>
>> These dts files will be changed later and more nodes will be
>> added to describe other devices.
>
> How is this going to be changed other than the addition of nodes?
>
> Will this DTB continue to work in future? Or do you intend to make
> changes that will break support?
My original idea is: use spin-table for SMP now, when firmware is OK to
support PSCI, we submit another patch to replace the spin-table with PSCI.

If DTB should continue to work in the future, we really need to remove
the spin-table
from current dts file, how about just enable one core now?

Which one do you favor or any other suggestion?

>
>> Signed-off-by: Bintian Wang 
>> Reviewed-by: Haojian Zhuang 
>> Reviewed-by: Yiping Xu 
>> ---
>>  .../bindings/arm/hisilicon/hisilicon.txt   |   33 
>>  arch/arm64/boot/dts/Makefile   |1 +
>>  arch/arm64/boot/dts/hisilicon/Makefile |5 +
>>  arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts |   31 +++
>>  arch/arm64/boot/dts/hisilicon/hi6220.dtsi  |  204 
>> 
>>  5 files changed, 274 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/hisilicon/Makefile
>>  create mode 100644 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
>>  create mode 100644 arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>>
>> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt 
>> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
>> index f717c7b..5eb6b41 100644
>> --- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
>> +++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
>> @@ -9,6 +9,9 @@ HiP04 D01 Board
>>  Required root node properties:
>>   - compatible = "hisilicon,hip04-d01";
>>
>> +HiKey Board
>> +Required root node properties:
>> + - compatible = "hisilicon,hi6220-hikey";
>>
>>  Hisilicon system controller
>>
>> @@ -62,6 +65,36 @@ Example:
>>   };
>>
>>  ---
>> +Hisilicon Power Always ON domain controller
>> +
>> +Required properties:
>> +- compatible : "hisilicon,aoctrl"
>> +- reg : Register address and size
>> +
>> +Some clock registers are defined in power always on system controller,
>> +especially in Hi6220 SoC which is used for mobile platform.
>> +
>> +---
>> +Hisilicon Media domain controller
>> +
>> +Required properties:
>> +- compatible : "hisilicon,mediactrl"
>> +- reg : Register address and size
>> +
>> +Some clock registers of media module are defined in media system
>> +controller, especially in Hi6220 SoC which is used for mobile platform.
>> +
>> +---
>> +Hisilicon Power Management domain controller
>> +
>> +Required properties:
>> +- compatible : "hisilicon,pmctrl"
>> +- reg : Register address and size
>> +
>> +Some clock registers and PMU registers are defined in power management
>> +controller, especially in Hin6220 SoC which is used for mobile platform.
>> +
>> +---
>
> Looking at the dts below, none of these binding docs are sufficient.
>
> Define _all_ the properties and what they mean.
In fact, Hisilicon designs several system controllers for different
function domains,
we can control different functions(e.g. clk gate on or off /IP reset)
based on the base
address of controller + offset, I will give more description in next version.

> Please also split documentation into earlier patches.
OK, separate document and code in next version.

>
>>  Fabric:
>>
>>  Required Properties:
>> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
>> index c62b0f4..bffd6b7 100644
>> --- a/arch/arm64/boot/dts/Makefile
>> +++ b/arch/arm64/boot/dts/Makefile
>> @@ -2,5 +2,6 @@ dts-dirs += amd
>>  dts-dirs += apm
>>  dts-dirs += arm
>>  dts-dirs += cavium
>> +dts-dirs += hisilicon
>>
>>  subdir-y := $(dts-dirs)
>> diff --git a/arch/arm64/boot/dts/hisilicon/Makefile 
>> b/arch/arm64/boot/dts/hisilicon/Makefile
>> new file mode

[PATCH] ARM: at91: dts: sama5d4: add dts for sama5d4 xplained board

2015-02-06 Thread Josh Wu

add at91 sama5d4 xplained board support.

Signed-off-by: Josh Wu 
---

 arch/arm/boot/dts/Makefile  |   1 +
 arch/arm/boot/dts/at91-sama5d4_xplained.dts | 234 
 2 files changed, 235 insertions(+)
 create mode 100644 arch/arm/boot/dts/at91-sama5d4_xplained.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 38c89ca..4994052 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -49,6 +49,7 @@ dtb-$(CONFIG_ARCH_AT91)   += sama5d34ek.dtb
 dtb-$(CONFIG_ARCH_AT91)+= sama5d35ek.dtb
 dtb-$(CONFIG_ARCH_AT91)+= sama5d36ek.dtb
 # sama5d4
+dtb-$(CONFIG_ARCH_AT91)+= at91-sama5d4_xplained.dtb
 dtb-$(CONFIG_ARCH_AT91)+= at91-sama5d4ek.dtb
 
 dtb-$(CONFIG_ARCH_ATLAS6) += atlas6-evb.dtb
diff --git a/arch/arm/boot/dts/at91-sama5d4_xplained.dts 
b/arch/arm/boot/dts/at91-sama5d4_xplained.dts
new file mode 100644
index 000..04a9679
--- /dev/null
+++ b/arch/arm/boot/dts/at91-sama5d4_xplained.dts
@@ -0,0 +1,234 @@
+/*
+ * at91-sama5d4_xplained.dts - Device Tree file for SAMA5D4 Xplained board
+ *
+ *  Copyright (C) 2015 Atmel,
+ *2015 Josh Wu 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+/dts-v1/;
+#include "sama5d4.dtsi"
+
+/ {
+   model = "Atmel SAMA5D4 Xplained";
+   compatible = "atmel,sama5d4-xplained", "atmel,sama5d4", "atmel,sama5";
+
+   chosen {
+   bootargs = "console=ttyS0,115200 ignore_loglevel earlyprintk";
+   };
+
+   memory {
+   reg = <0x2000 0x2000>;
+   };
+
+   clocks {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   main_clock: clock@0 {
+   compatible = "atmel,osc", "fixed-clock";
+   clock-frequency = <1200>;
+   };
+
+   slow_xtal {
+   clock-frequency = <32768>;
+   };
+
+   main_xtal {
+   clock-frequency = <1200>;
+   };
+   };
+
+   ahb {
+   apb {
+   adc0: adc@fc034000 {
+   /* The vref depends on JP22 of EK. If connect 
1-2 then use 3.3V. connect 2-3 use 3.0V */
+   atmel,adc-vref = <3300>;
+   /*atmel,adc-ts-wires = <4>;*/   /* Set up ADC 
touch screen */
+   status = "okay";/* Enable ADC 
IIO support */
+   };
+
+   spi0: spi@f801 {
+   cs-gpios = < 3 0>, <0>, <0>, <0>;
+   status = "okay";
+   m25p80@0 {
+   compatible = "atmel,at25df321a";
+   spi-max-frequency = <5000>;
+   reg = <0>;
+   };
+   };
+
+   macb0:

Re: [PATCH v2 1/2] mtd: nand: pxa3xx: Fix PIO FIFO draining

2015-02-06 Thread Brian Norris

On Fri, Feb 06, 2015 at 09:13:07AM +0100, Boris Brezillon wrote:
> Hi Brian,
> 
> On Thu, 5 Feb 2015 17:08:35 -0800
> Brian Norris  wrote:
> > On Wed, Feb 04, 2015 at 11:10:28AM +0100, Boris Brezillon wrote:
> > > On Mon, 26 Jan 2015 15:56:03 +0100
> > > Maxime Ripard  wrote:
> > > > +   /*
> > > > +* According to the datasheet, when reading
> > > > +* from NDDB with BCH enabled, after each 32
> > > > +* bits reads, we have to make sure that the
> > > > +* NDSR.RDDREQ bit is set
> > > > +*/
> > > 
> > > I know the datasheet says this bit should be checked after each
> > > transfer, but I wonder if we shouldn't check it before reading the data.
> > > What happens if you drain all the data available in the FIFO ? Is the
> > > controller still setting the RDDREQ bit ?
> > > 
> > > Moreover, the datasheet says this RDDREQ bit should be checked after
> > > each 32 bytes (not 32 bits) transfer.
> > > Testing it after each readl call shouldn't hurt though.
> > 
> > Seems like that could quite possibly kill performance unnecessarily,
> > couldn't it? But then, PIO is probably not that fast in the first
> > place...
> 
> Absolutety, my point was, it shouldn't hurt from a functional POV, but
> yes it will definitely impact performances.

OK.

> But that's not the first thing I would rework of if you're concerned
> about performances: when doing PIO read/write, the page read/write
> operations (I mean the part reading the internal fifo) are all done in
> interrupt context (called from pxa3xx_nand_irq), and doing this will
> prevent any other interrupt from taking place while you are
> draining/filling the FIFO :-(.

...which reminds me; the jiffies-based timeout in this patch isn't going
to work in interrupt context. So it needs to be replaced either with a
tight udelay() loop, or it needs to be moved out of the ISR.

> An alternative would be to move this part into the read/write_buf
> functions, but that's a lot of work...

Yeah, that probably would be preferable, but I suppose it's not urgent
either.

Brian
--
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] mtd: denali: Disable sub-page writes in Denali NAND driver

2015-02-06 Thread Ricard Wanderlof

On Thu, 5 Feb 2015, Graham Moore wrote:

> Actually, we made this change to make UBIFS work.  So, yes, the driver 
> never worked for UBI.  Worked fine for JFFS2, raw data.
> 
> A customer reported an issue with ECC errors when using UBIFS on NAND 
> flash with Altera SoC.
> 
> We debugged it and found the ECC errors occur because the UBI subsystem 
> is trying to write sub-pages in the NAND, but neither the NAND chip 
> itself nor the Denali NAND controller support sub-page writes.

Just a bit curious.

It is not uncommon for controllers or chips not to support sub-page 
writes. In that case however, the partition(s) used by UBI should be 
formatted accordingly, i.e. using the appropriate --sub-page-size argument 
to ubiformat (when formatting partitions on the system itself), or the 
corresponding argument to ubinize (when preparing images offline).

If that is done correctly, then the lack of subpage write capability is 
not a problem per se (of course, the UBI EC and VID headers then take up 
more space so less space is available for user data; on a flash with 2k 
pages it is only 2k bytes per LEB that is lost however).

/Ricard
-- 
Ricard Wolf Wanderlöf   ricardw(at)axis.com
Axis Communications AB, Lund, Swedenwww.axis.com
Phone +46 46 272 2016   Fax +46 46 13 61 30
--
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] thermal: int340x: fix sparse warning

2015-02-06 Thread Zhang Rui

On Thu, 2015-02-05 at 13:43 +, Lad Prabhakar wrote:
> From: "Lad, Prabhakar" 
> 
> this patch fixes following sparse warning:
> 
> processor_thermal_device.c:188:6: warning: symbol 'proc_thermal_remove' was 
> not declared. Should it be static?
> 
> Signed-off-by: Lad, Prabhakar 

applied. thanks!

-rui
> ---
>  Found this issue on linux-next (gcc  version 4.9.2,
>  sparse version  0.4.5-rc1)and applies on top linux-next.
> 
>  drivers/thermal/int340x_thermal/processor_thermal_device.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/thermal/int340x_thermal/processor_thermal_device.c 
> b/drivers/thermal/int340x_thermal/processor_thermal_device.c
> index 0fe5dbb..095acac 100644
> --- a/drivers/thermal/int340x_thermal/processor_thermal_device.c
> +++ b/drivers/thermal/int340x_thermal/processor_thermal_device.c
> @@ -185,7 +185,7 @@ free_buffer:
>   return ret;
>  }
>  
> -void proc_thermal_remove(struct proc_thermal_device *proc_priv)
> +static void proc_thermal_remove(struct proc_thermal_device *proc_priv)
>  {
>   sysfs_remove_group(_priv->dev->kobj,
>  _limit_attribute_group);


--
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: [f2fs-dev] [PATCH 5/5 v4] f2fs: introduce a batched trim

2015-02-06 Thread Chao Yu

Hi Jaegeuk,

> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Friday, February 06, 2015 2:19 PM
> To: Chao Yu
> Cc: 'Changman Lee'; linux-fsde...@vger.kernel.org; 
> linux-kernel@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Subject: Re: [f2fs-dev] [PATCH 5/5 v4] f2fs: introduce a batched trim
> 
> Hi Chao,
> 
> Something like this?
> 
> Change log from v3:
>  o align to section size
> 
> This patch introduces a batched trimming feature, which submits split discard
> commands.
> 
> This is to avoid long latency due to huge trim commands.
> If fstrim was triggered ranging from 0 to the end of device, we should lock
> all the checkpoint-related mutexes, resulting in very long latency.
> 
> Signed-off-by: Jaegeuk Kim 

Looks good to me.

Reviewed-by: Chao Yu 

--
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] drm: atmel-hlcdc: Atomic mode-setting conversion

2015-02-06 Thread Daniel Vetter

On Thu, Feb 05, 2015 at 04:37:56PM +0100, Boris Brezillon wrote:
> On Thu, 5 Feb 2015 14:08:32 +0100
> Daniel Vetter  wrote:
> 
> > On Wed, Feb 04, 2015 at 09:20:51PM +0100, Boris Brezillon wrote:
> > > Convert the HLCDC driver to atomic mode-setting.
> > > 
> > > Signed-off-by: Boris Brezillon 
> > 
> > Just a quick comment: dpms isn't yet converted over, and from experience
> > with tegra/msm that probably will yield some surprises. Since only with
> > dpms will it be obvious how strict the added requirements from the atomic
> > helpers are ;-)
> 
> Yes, I noticed I was not using the appropriate dpms helper in the
> connector funcs just after sending this patch.
> 
> Would this patch [1] address what you're talking about, or am I still
> missing something ?
> 
> Thanks,
> 
> Boris
> 
> [1]http://code.bulix.org/l70xf4-87827

You should be able to bin all your dpms implementations too, at least if
you switch to the new enable/disable hooks for crtc/encoder.
prepare/commit/dpms are all depcrecated (for both crtc and encoder) and
shouldn't be needed any more.  Same with crtc_funcs->mode_set.

But yeah the functional change should be all there is, if it still works
you're all set.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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 1/2] mtd: nand: pxa3xx: Fix PIO FIFO draining

2015-02-06 Thread Boris Brezillon

Hi Brian,

On Thu, 5 Feb 2015 17:08:35 -0800
Brian Norris  wrote:

> + Rob
> 
> This patch has conflicts with an ARM64-preparation from Rob. I'd like to
> get this patch in first, as it's a bugfix. But I'd like to settle
> Boris's comments first.
> 
> (Regarding the request to get this into 3.19: not likely. Judging by the
> age of the "bug", it's not massively critical, and we have no time. It
> can get out through -stable once it's gotten proper review and testing.)
> 
> On Wed, Feb 04, 2015 at 11:10:28AM +0100, Boris Brezillon wrote:
> > On Mon, 26 Jan 2015 15:56:03 +0100
> > Maxime Ripard  wrote:
> > 
> > > The NDDB register holds the data that are needed by the read and write
> > > commands.
> > > 
> > > However, during a read PIO access, the datasheet specifies that after 
> > > each 32
> > > bits read in that register, when BCH is enabled, we have to make sure 
> > > that the
> > > RDDREQ bit is set in the NDSR register.
> > > 
> > > This fixes an issue that was seen on the Armada 385, and presumably other 
> > > mvebu
> > > SoCs, when a read on a newly erased page would end up in the driver 
> > > reporting a
> > > timeout from the NAND.
> > > 
> > > Cc:  # v3.14
> > > Signed-off-by: Maxime Ripard 
> > > ---
> > >  drivers/mtd/nand/pxa3xx_nand.c | 45 
> > > --
> > >  1 file changed, 39 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/mtd/nand/pxa3xx_nand.c 
> > > b/drivers/mtd/nand/pxa3xx_nand.c
> > > index 96b0b1d27df1..e6918befb951 100644
> > > --- a/drivers/mtd/nand/pxa3xx_nand.c
> > > +++ b/drivers/mtd/nand/pxa3xx_nand.c
> > > @@ -23,6 +23,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -480,6 +481,38 @@ static void disable_int(struct pxa3xx_nand_info 
> > > *info, uint32_t int_mask)
> > >   nand_writel(info, NDCR, ndcr | int_mask);
> > >  }
> > >  
> > > +static void drain_fifo(struct pxa3xx_nand_info *info, void *data, int 
> > > len)
> > > +{
> > > + u32 *dst = (u32 *)data;
> > > +
> > > + if (info->ecc_bch) {
> > > + while (len--) {
> > > + u32 timeout;
> > > +
> > > + *dst++ = nand_readl(info, NDDB);
> > > +
> > > + /*
> > > +  * According to the datasheet, when reading
> > > +  * from NDDB with BCH enabled, after each 32
> > > +  * bits reads, we have to make sure that the
> > > +  * NDSR.RDDREQ bit is set
> > > +  */
> > 
> > I know the datasheet says this bit should be checked after each
> > transfer, but I wonder if we shouldn't check it before reading the data.
> > What happens if you drain all the data available in the FIFO ? Is the
> > controller still setting the RDDREQ bit ?
> > 
> > Moreover, the datasheet says this RDDREQ bit should be checked after
> > each 32 bytes (not 32 bits) transfer.
> > Testing it after each readl call shouldn't hurt though.
> 
> Seems like that could quite possibly kill performance unnecessarily,
> couldn't it? But then, PIO is probably not that fast in the first
> place...

Absolutety, my point was, it shouldn't hurt from a functional POV, but
yes it will definitely impact performances.
But that's not the first thing I would rework of if you're concerned
about performances: when doing PIO read/write, the page read/write
operations (I mean the part reading the internal fifo) are all done in
interrupt context (called from pxa3xx_nand_irq), and doing this will
prevent any other interrupt from taking place while you are
draining/filling the FIFO :-(.
An alternative would be to move this part into the read/write_buf
functions, but that's a lot of work...

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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 RFC v8 11/21] Documentation: dt-bindings: Add bindings for Synopsys DW MIPI DSI DRM bridge driver

2015-02-06 Thread Liu Ying

On Thu, Feb 05, 2015 at 11:10:04AM +0100, Philipp Zabel wrote:
> Am Mittwoch, den 31.12.2014, 16:23 +0800 schrieb Liu Ying:
> > This patch adds device tree bindings for Synopsys DesignWare MIPI DSI
> > host controller DRM bridge driver.
> > 
> > Signed-off-by: Liu Ying 
> > ---
> > v7->v8:
> >  * None.
> > 
> > v6->v7:
> >  * None.
> > 
> > v5->v6:
> >  * Add the #address-cells and #size-cells properties in the example 'ports'
> >node.
> >  * Remove the useless input-port properties from the example port@0 and 
> > port@1
> >nodes.
> > 
> > v4->v5:
> >  * None.
> > 
> > v3->v4:
> >  * Newly introduced in v4.  This is separated from the relevant driver patch
> >in v3 to address Stefan Wahren's comment.
> > 
> >  .../devicetree/bindings/drm/bridge/dw_mipi_dsi.txt | 73 
> > ++
> >  1 file changed, 73 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt 
> > b/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt
> > new file mode 100644
> > index 000..f88a8d6
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt
> > @@ -0,0 +1,73 @@
> > +Device-Tree bindings for Synopsys DesignWare MIPI DSI host controller
> > +
> > +The controller is a digital core that implements all protocol functions
> > +defined in the MIPI DSI specification, providing an interface between
> > +the system and the MIPI DPHY, and allowing communication with a MIPI DSI
> > +compliant display.
> > +
> > +Required properties:
> > + - #address-cells: Should be <1>.
> > + - #size-cells: Should be <0>.
> > + - compatible: The compatible string should be "fsl,imx6q-mipi-dsi" for
> > +   i.MX6q/sdl SoCs.  For other SoCs, please refer to their specific
> > +   device tree binding documentations.
> 
> I think the compatible property should additionally contain
> "snps,dw-mipi-dsi". Also I think other SoCs using the same IP core
> should eventually list their compatibles here, but that's for later.
> 
> How about:
> + - compatible: The compatible string contain "fsl,imx6q-mipi-dsi" for
> +   i.MX6q/sdl SoCs.  For other SoCs, please refer to their specific
> +   device tree binding documentations. A common compatible string
> +   "snps,dw-mipi-dsi" should be appended for all SoCs.

I'm not sure if "snps,dw-mipi-dsi" should be appended.

Is it a compatible string that SoC specific drivers should actually use to
bind a device?

As Andy mentioned in [1], DW MIPI DSI embedded in RK618 is configured via I2C
bus, while i.MX6Q/DL is configured via ARM bus...

Another concern is that if users only specify "snps,dw-mipi-dsi" in their
device tree sources and use a kernel which supports multiple platforms,
say ARM multi v7 platforms, could several enabled SoC specific drivers be
probed for a single DW MIPI DSI device?

[1] http://lists.freedesktop.org/archives/dri-devel/2014-December/074344.html

> 
> > + - reg: Represent the physical address range of the controller.
> > + - interrupts: Represent the controller's interrupt to the CPU(s).
> > + - clocks, clock-names: Phandles to the controller pll reference and
> > +   core configuration clocks, as described in [1].
> 
> From the MIPI CSI-2 datasheets it looks like the D-PHY has a refclk and
> a cfg_clk input. So I suspect from the name of the "core_cfg" clock,
> that it actually represents two clock inputs, the "cfg_clk" wired to the
> D-PHY and a core clock wired to the MIPI DSI host controller. I am not
> sure if there are designs that control those clocks separately, but I
> think it'd be safer to split this into two clocks in the device tree.

What MIPI CSI-2 datasheets do you refer to?
I don't find the refclk and cfg_clk in the MIPI CSI chapter of the i.MX6DQ
Reference Manual v2[2].

I think we need to know the design philosophy of DW MIPI DSI clock sources
to settle down the documentation here.  I've asked our internal MIPI DSI
SoC owner for ideas.  But, someone from Synopsys might be the right
person, perhaps.

[2] 
http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6DQRM.pdf?fasp=1_TYPE=Reference%20Manuals_VENDOR=FREESCALE_FILE_FORMAT=pdf_ASSET=Documentation=.pdf

> 
> Also I am not sure which input to the MIPI DSI host controller the core
> clock represents. The i.MX6DQ Reference Manual v2 calls the remaining
> clock inputs gated by mipi_core_cfg_clk_enable "ac_clk_125m" and
> "ips_clk" (I think the latter is the ABP clock driving the register
> bank, just called "pclk" in the MIPI CSI-2 documentation).

The same MIPI CSI-2 documentation you mentioned above?

I'm also puzzled about the clocks.

Regards,
Liu Ying

> 
> regards
> Philipp
> 
--
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: [GIT PULL] at91: cleanup/soc for 3.20 #4 (bis)

2015-02-06 Thread Olof Johansson

On Mon, Feb 02, 2015 at 08:27:54PM +0100, Nicolas Ferre wrote:
> Arnd, Olof, Kevin,
> 
> As advised by Olof, here is a second attempt with this pull-request but this
> time with the at91-3.19-fixes branch as a base. Here is how I did it:
> - took v3.19-rc4
> - merged my at91-3.19-fixes branch that is now in Linus' tree
> - merged my at91-cleanup3 tag that you already have in your "soc" branch. 
> These
>   patches obviously depend on this tag.
> - stacked the contend of this cleanup/soc pull-request.

Yep -- only tweak is that next time you could either start with your cleanup3
tag and just merge fixes, or start with fixes and merge cleanup3 -- no need to
do an explicit merge of fixes on top of mainline.

Anyway, that's just a very minor detail. I've merged this now, thanks for
respinning!


-Olof
--
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] drm: atmel-hlcdc: Atomic mode-setting conversion

2015-02-06 Thread Daniel Vetter

On Thu, Feb 05, 2015 at 04:37:56PM +0100, Boris Brezillon wrote:
 On Thu, 5 Feb 2015 14:08:32 +0100
 Daniel Vetter dan...@ffwll.ch wrote:
 
  On Wed, Feb 04, 2015 at 09:20:51PM +0100, Boris Brezillon wrote:
   Convert the HLCDC driver to atomic mode-setting.
   
   Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
  
  Just a quick comment: dpms isn't yet converted over, and from experience
  with tegra/msm that probably will yield some surprises. Since only with
  dpms will it be obvious how strict the added requirements from the atomic
  helpers are ;-)
 
 Yes, I noticed I was not using the appropriate dpms helper in the
 connector funcs just after sending this patch.
 
 Would this patch [1] address what you're talking about, or am I still
 missing something ?
 
 Thanks,
 
 Boris
 
 [1]http://code.bulix.org/l70xf4-87827

You should be able to bin all your dpms implementations too, at least if
you switch to the new enable/disable hooks for crtc/encoder.
prepare/commit/dpms are all depcrecated (for both crtc and encoder) and
shouldn't be needed any more.  Same with crtc_funcs-mode_set.

But yeah the functional change should be all there is, if it still works
you're all set.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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: [f2fs-dev] [PATCH 5/5 v4] f2fs: introduce a batched trim

2015-02-06 Thread Chao Yu

Hi Jaegeuk,

 -Original Message-
 From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
 Sent: Friday, February 06, 2015 2:19 PM
 To: Chao Yu
 Cc: 'Changman Lee'; linux-fsde...@vger.kernel.org; 
 linux-kernel@vger.kernel.org;
 linux-f2fs-de...@lists.sourceforge.net
 Subject: Re: [f2fs-dev] [PATCH 5/5 v4] f2fs: introduce a batched trim

 Hi Chao,

 Something like this?

 Change log from v3:
  o align to section size

 This patch introduces a batched trimming feature, which submits split discard
 commands.

 This is to avoid long latency due to huge trim commands.
 If fstrim was triggered ranging from 0 to the end of device, we should lock
 all the checkpoint-related mutexes, resulting in very long latency.

 Signed-off-by: Jaegeuk Kim jaeg...@kernel.org

Looks good to me.

Reviewed-by: Chao Yu chao2...@samsung.com

--
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 1/2] mtd: nand: pxa3xx: Fix PIO FIFO draining

2015-02-06 Thread Brian Norris

On Fri, Feb 06, 2015 at 09:13:07AM +0100, Boris Brezillon wrote:
 Hi Brian,
 
 On Thu, 5 Feb 2015 17:08:35 -0800
 Brian Norris computersforpe...@gmail.com wrote:
  On Wed, Feb 04, 2015 at 11:10:28AM +0100, Boris Brezillon wrote:
   On Mon, 26 Jan 2015 15:56:03 +0100
   Maxime Ripard maxime.rip...@free-electrons.com wrote:
+   /*
+* According to the datasheet, when reading
+* from NDDB with BCH enabled, after each 32
+* bits reads, we have to make sure that the
+* NDSR.RDDREQ bit is set
+*/
   
   I know the datasheet says this bit should be checked after each
   transfer, but I wonder if we shouldn't check it before reading the data.
   What happens if you drain all the data available in the FIFO ? Is the
   controller still setting the RDDREQ bit ?
   
   Moreover, the datasheet says this RDDREQ bit should be checked after
   each 32 bytes (not 32 bits) transfer.
   Testing it after each readl call shouldn't hurt though.
  
  Seems like that could quite possibly kill performance unnecessarily,
  couldn't it? But then, PIO is probably not that fast in the first
  place...
 
 Absolutety, my point was, it shouldn't hurt from a functional POV, but
 yes it will definitely impact performances.

OK.

 But that's not the first thing I would rework of if you're concerned
 about performances: when doing PIO read/write, the page read/write
 operations (I mean the part reading the internal fifo) are all done in
 interrupt context (called from pxa3xx_nand_irq), and doing this will
 prevent any other interrupt from taking place while you are
 draining/filling the FIFO :-(.

...which reminds me; the jiffies-based timeout in this patch isn't going
to work in interrupt context. So it needs to be replaced either with a
tight udelay() loop, or it needs to be moved out of the ISR.

 An alternative would be to move this part into the read/write_buf
 functions, but that's a lot of work...

Yeah, that probably would be preferable, but I suppose it's not urgent
either.

Brian
--
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 RFC v8 11/21] Documentation: dt-bindings: Add bindings for Synopsys DW MIPI DSI DRM bridge driver

2015-02-06 Thread Liu Ying

On Thu, Feb 05, 2015 at 11:10:04AM +0100, Philipp Zabel wrote:
Am Mittwoch, den 31.12.2014, 16:23 +0800 schrieb Liu Ying:
This patch adds device tree bindings for Synopsys DesignWare MIPI DSI
host controller DRM bridge driver.

Signed-off-by: Liu Ying ying@freescale.com
---
v7-v8:
* None.

v6-v7:
* None.

v5-v6:
* Add the #address-cells and #size-cells properties in the example 'ports'
node.
* Remove the useless input-port properties from the example port@0 and
port@1
nodes.

v4-v5:
* None.

v3-v4:
* Newly introduced in v4. This is separated from the relevant driver patch
in v3 to address Stefan Wahren's comment.

.../devicetree/bindings/drm/bridge/dw_mipi_dsi.txt | 73
++
1 file changed, 73 insertions(+)
create mode 100644
Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt

diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt
b/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt
new file mode 100644
index 000..f88a8d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt
@@ -0,0 +1,73 @@
+Device-Tree bindings for Synopsys DesignWare MIPI DSI host controller
+
+The controller is a digital core that implements all protocol functions
+defined in the MIPI DSI specification, providing an interface between
+the system and the MIPI DPHY, and allowing communication with a MIPI DSI
+compliant display.
+
+Required properties:
+ - #address-cells: Should be 1.
+ - #size-cells: Should be 0.
+ - compatible: The compatible string should be fsl,imx6q-mipi-dsi for
+ i.MX6q/sdl SoCs. For other SoCs, please refer to their specific
+ device tree binding documentations.

I think the compatible property should additionally contain
snps,dw-mipi-dsi. Also I think other SoCs using the same IP core
should eventually list their compatibles here, but that's for later.

How about:
+ - compatible: The compatible string contain fsl,imx6q-mipi-dsi for
+ i.MX6q/sdl SoCs. For other SoCs, please refer to their specific
+ device tree binding documentations. A common compatible string
+ snps,dw-mipi-dsi should be appended for all SoCs.

I'm not sure if snps,dw-mipi-dsi should be appended.

Is it a compatible string that SoC specific drivers should actually use to
bind a device?

As Andy mentioned in [1], DW MIPI DSI embedded in RK618 is configured via I2C
bus, while i.MX6Q/DL is configured via ARM bus...

Another concern is that if users only specify snps,dw-mipi-dsi in their
device tree sources and use a kernel which supports multiple platforms,
say ARM multi v7 platforms, could several enabled SoC specific drivers be
probed for a single DW MIPI DSI device?

[1] http://lists.freedesktop.org/archives/dri-devel/2014-December/074344.html

+ - reg: Represent the physical address range of the controller.
+ - interrupts: Represent the controller's interrupt to the CPU(s).
+ - clocks, clock-names: Phandles to the controller pll reference and
+ core configuration clocks, as described in [1].

From the MIPI CSI-2 datasheets it looks like the D-PHY has a refclk and
a cfg_clk input. So I suspect from the name of the core_cfg clock,
that it actually represents two clock inputs, the cfg_clk wired to the
D-PHY and a core clock wired to the MIPI DSI host controller. I am not
sure if there are designs that control those clocks separately, but I
think it'd be safer to split this into two clocks in the device tree.

What MIPI CSI-2 datasheets do you refer to?
I don't find the refclk and cfg_clk in the MIPI CSI chapter of the i.MX6DQ
Reference Manual v2[2].

I think we need to know the design philosophy of DW MIPI DSI clock sources
to settle down the documentation here. I've asked our internal MIPI DSI
SoC owner for ideas. But, someone from Synopsys might be the right
person, perhaps.

[2]
http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6DQRM.pdf?fasp=1WT_TYPE=Reference%20ManualsWT_VENDOR=FREESCALEWT_FILE_FORMAT=pdfWT_ASSET=DocumentationfileExt=.pdf

Also I am not sure which input to the MIPI DSI host controller the core
clock represents. The i.MX6DQ Reference Manual v2 calls the remaining
clock inputs gated by mipi_core_cfg_clk_enable ac_clk_125m and
ips_clk (I think the latter is the ABP clock driving the register
bank, just called pclk in the MIPI CSI-2 documentation).

The same MIPI CSI-2 documentation you mentioned above?

I'm also puzzled about the clocks.

Regards,
Liu Ying

regards
Philipp

--
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 1/2] mtd: nand: pxa3xx: Fix PIO FIFO draining

2015-02-06 Thread Boris Brezillon

Hi Brian,

On Thu, 5 Feb 2015 17:08:35 -0800
Brian Norris computersforpe...@gmail.com wrote:

 + Rob
 
 This patch has conflicts with an ARM64-preparation from Rob. I'd like to
 get this patch in first, as it's a bugfix. But I'd like to settle
 Boris's comments first.
 
 (Regarding the request to get this into 3.19: not likely. Judging by the
 age of the bug, it's not massively critical, and we have no time. It
 can get out through -stable once it's gotten proper review and testing.)
 
 On Wed, Feb 04, 2015 at 11:10:28AM +0100, Boris Brezillon wrote:
  On Mon, 26 Jan 2015 15:56:03 +0100
  Maxime Ripard maxime.rip...@free-electrons.com wrote:
  
   The NDDB register holds the data that are needed by the read and write
   commands.
   
   However, during a read PIO access, the datasheet specifies that after 
   each 32
   bits read in that register, when BCH is enabled, we have to make sure 
   that the
   RDDREQ bit is set in the NDSR register.
   
   This fixes an issue that was seen on the Armada 385, and presumably other 
   mvebu
   SoCs, when a read on a newly erased page would end up in the driver 
   reporting a
   timeout from the NAND.
   
   Cc: sta...@vger.kernel.org # v3.14
   Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
   ---
drivers/mtd/nand/pxa3xx_nand.c | 45 
   --
1 file changed, 39 insertions(+), 6 deletions(-)
   
   diff --git a/drivers/mtd/nand/pxa3xx_nand.c 
   b/drivers/mtd/nand/pxa3xx_nand.c
   index 96b0b1d27df1..e6918befb951 100644
   --- a/drivers/mtd/nand/pxa3xx_nand.c
   +++ b/drivers/mtd/nand/pxa3xx_nand.c
   @@ -23,6 +23,7 @@
#include linux/mtd/partitions.h
#include linux/io.h
#include linux/irq.h
   +#include linux/jiffies.h
#include linux/slab.h
#include linux/of.h
#include linux/of_device.h
   @@ -480,6 +481,38 @@ static void disable_int(struct pxa3xx_nand_info 
   *info, uint32_t int_mask)
 nand_writel(info, NDCR, ndcr | int_mask);
}

   +static void drain_fifo(struct pxa3xx_nand_info *info, void *data, int 
   len)
   +{
   + u32 *dst = (u32 *)data;
   +
   + if (info-ecc_bch) {
   + while (len--) {
   + u32 timeout;
   +
   + *dst++ = nand_readl(info, NDDB);
   +
   + /*
   +  * According to the datasheet, when reading
   +  * from NDDB with BCH enabled, after each 32
   +  * bits reads, we have to make sure that the
   +  * NDSR.RDDREQ bit is set
   +  */
  
  I know the datasheet says this bit should be checked after each
  transfer, but I wonder if we shouldn't check it before reading the data.
  What happens if you drain all the data available in the FIFO ? Is the
  controller still setting the RDDREQ bit ?
  
  Moreover, the datasheet says this RDDREQ bit should be checked after
  each 32 bytes (not 32 bits) transfer.
  Testing it after each readl call shouldn't hurt though.
 
 Seems like that could quite possibly kill performance unnecessarily,
 couldn't it? But then, PIO is probably not that fast in the first
 place...

Absolutety, my point was, it shouldn't hurt from a functional POV, but
yes it will definitely impact performances.
But that's not the first thing I would rework of if you're concerned
about performances: when doing PIO read/write, the page read/write
operations (I mean the part reading the internal fifo) are all done in
interrupt context (called from pxa3xx_nand_irq), and doing this will
prevent any other interrupt from taking place while you are
draining/filling the FIFO :-(.
An alternative would be to move this part into the read/write_buf
functions, but that's a lot of work...

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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] mtd: denali: Disable sub-page writes in Denali NAND driver

2015-02-06 Thread Ricard Wanderlof


On Thu, 5 Feb 2015, Graham Moore wrote:

 Actually, we made this change to make UBIFS work.  So, yes, the driver 
 never worked for UBI.  Worked fine for JFFS2, raw data.
 
 A customer reported an issue with ECC errors when using UBIFS on NAND 
 flash with Altera SoC.
 
 We debugged it and found the ECC errors occur because the UBI subsystem 
 is trying to write sub-pages in the NAND, but neither the NAND chip 
 itself nor the Denali NAND controller support sub-page writes.

Just a bit curious.

It is not uncommon for controllers or chips not to support sub-page 
writes. In that case however, the partition(s) used by UBI should be 
formatted accordingly, i.e. using the appropriate --sub-page-size argument 
to ubiformat (when formatting partitions on the system itself), or the 
corresponding argument to ubinize (when preparing images offline).

If that is done correctly, then the lack of subpage write capability is 
not a problem per se (of course, the UBI EC and VID headers then take up 
more space so less space is available for user data; on a flash with 2k 
pages it is only 2k bytes per LEB that is lost however).

/Ricard
-- 
Ricard Wolf Wanderlöf   ricardw(at)axis.com
Axis Communications AB, Lund, Swedenwww.axis.com
Phone +46 46 272 2016   Fax +46 46 13 61 30
--
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] thermal: int340x: fix sparse warning

2015-02-06 Thread Zhang Rui

On Thu, 2015-02-05 at 13:43 +, Lad Prabhakar wrote:
 From: Lad, Prabhakar prabhakar.cse...@gmail.com
 
 this patch fixes following sparse warning:
 
 processor_thermal_device.c:188:6: warning: symbol 'proc_thermal_remove' was 
 not declared. Should it be static?
 
 Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com

applied. thanks!

-rui
 ---
  Found this issue on linux-next (gcc  version 4.9.2,
  sparse version  0.4.5-rc1)and applies on top linux-next.
 
  drivers/thermal/int340x_thermal/processor_thermal_device.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/thermal/int340x_thermal/processor_thermal_device.c 
 b/drivers/thermal/int340x_thermal/processor_thermal_device.c
 index 0fe5dbb..095acac 100644
 --- a/drivers/thermal/int340x_thermal/processor_thermal_device.c
 +++ b/drivers/thermal/int340x_thermal/processor_thermal_device.c
 @@ -185,7 +185,7 @@ free_buffer:
   return ret;
  }
  
 -void proc_thermal_remove(struct proc_thermal_device *proc_priv)
 +static void proc_thermal_remove(struct proc_thermal_device *proc_priv)
  {
   sysfs_remove_group(proc_priv-dev-kobj,
  power_limit_attribute_group);


--
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: [GIT PULL] at91: cleanup/soc for 3.20 #4 (bis)

2015-02-06 Thread Olof Johansson

On Mon, Feb 02, 2015 at 08:27:54PM +0100, Nicolas Ferre wrote:
 Arnd, Olof, Kevin,
 
 As advised by Olof, here is a second attempt with this pull-request but this
 time with the at91-3.19-fixes branch as a base. Here is how I did it:
 - took v3.19-rc4
 - merged my at91-3.19-fixes branch that is now in Linus' tree
 - merged my at91-cleanup3 tag that you already have in your soc branch. 
 These
   patches obviously depend on this tag.
 - stacked the contend of this cleanup/soc pull-request.

Yep -- only tweak is that next time you could either start with your cleanup3
tag and just merge fixes, or start with fixes and merge cleanup3 -- no need to
do an explicit merge of fixes on top of mainline.

Anyway, that's just a very minor detail. I've merged this now, thanks for
respinning!


-Olof
--
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: [PATCHv6 4/5] edac: altera: Add Altera L2 Cache and OCRAM EDAC Support

2015-02-06 Thread Mark Rutland

On Fri, Jan 09, 2015 at 02:53:55AM +, ttha...@opensource.altera.com wrote:
 From: Thor Thayer ttha...@opensource.altera.com
 
 Adding L2 Cache and On-Chip RAM EDAC support for the
 Altera SoCs using the EDAC device  model. The SDRAM
 controller is using the Memory Controller model.
 
 Each type of ECC is individually configurable.
 
 The SDRAM ECC is a separate Kconfig option because:
 1) the SDRAM preparation can take almost 2 seconds on boot and some
 customers need a faster boot time.
 2) the SDRAM has an ECC initialization dependency on the preloader
 which is outside the kernel. It is desirable to be able to turn the
 SDRAM on  off separately.
 
 Signed-off-by: Thor Thayer ttha...@opensource.altera.com
 ---
 v2: Fix L2 dependency comments.
 
 v3: Move OCRAM and L2 cache EDAC functions into altera_edac.c
 instead of separate files.
 
 v4: Change mask defines to use BIT().
 Fix comment style to agree with kernel coding style.
 Better printk description for read != write in trigger.
 Remove SysFS debugging message.
 Better dci-mod_name
 Move gen_pool pointer assignment to end of function.
 Invert logic to reduce indent in ocram depenency check.
 Change from dev_err() to edac_printk()
 Replace magic numbers with defines  comments.
 Improve error injection test.
 Change Makefile intermediary name to altr (from alt)
 
 v5: No change.
 
 v6: Convert to nested EDAC in device tree. Force L2 cache
 on for L2Cache ECC  remove L2 cache syscon for checking
 enable bit. Update year in header.
 ---
  drivers/edac/Kconfig   |   16 ++
  drivers/edac/Makefile  |5 +-
  drivers/edac/altera_edac.c |  506 
 +++-
  3 files changed, 524 insertions(+), 3 deletions(-)

[...]

 +/* EDAC Parent Probe */
 +
 +static const struct of_device_id altr_edac_device_of_match[];

Huh? What's this for?

 +static const struct of_device_id altr_edac_of_match[] = {
 +   { .compatible = altr,edac },
 +   {},
 +};
 +MODULE_DEVICE_TABLE(of, altr_edac_of_match);

I know it may seem like a minor thing, but the documentation really
should have come in an earlier patch. It's painful to review a patch
series when you have to randomly just to the end of hte series to see
the documentation.

The name is _very_ generic here. Do we not have a more specific name for
the EDAC block in your SoC?

Is there actually a specific EDAC device, or are you just grouping some
portions of HW blocks into an EDAC device to match what the Linux EDAC
framework wants?

[...]

 +ssize_t altr_edac_device_trig(struct edac_device_ctl_info *edac_dci,
 + const char *buffer, size_t count)
 +{
 +   u32 *ptemp, i, error_mask;
 +   int result = 0;
 +   unsigned long flags;
 +   struct altr_edac_device_dev *drvdata = edac_dci-pvt_info;
 +   const struct edac_device_prv_data *priv = drvdata-data;
 +   void *generic_ptr = edac_dci-dev;

Huh? What's hidden behind this generic_ptr?

 +
 +   if (!priv-alloc_mem)
 +   return -ENOMEM;
 +
 +   /*
 +* Note that generic_ptr is initialized to the device * but in
 +* some alloc_functions, this is overridden and returns data.
 +*/
 +   ptemp = priv-alloc_mem(priv-trig_alloc_sz, generic_ptr);
 +   if (!ptemp) {
 +   edac_printk(KERN_ERR, EDAC_DEVICE,
 +   Inject: Buffer Allocation error\n);
 +   return -ENOMEM;
 +   }
 +
 +   if (buffer[0] == ALTR_UE_TRIGGER_CHAR)
 +   error_mask = priv-ue_set_mask;
 +   else
 +   error_mask = priv-ce_set_mask;
 +
 +   edac_printk(KERN_ALERT, EDAC_DEVICE,
 +   Trigger Error Mask (0x%X)\n, error_mask);
 +
 +   local_irq_save(flags);
 +   /* write ECC corrupted data out. */
 +   for (i = 0; i  (priv-trig_alloc_sz / sizeof(*ptemp)); i++) {
 +   /* Read data so we're in the correct state */
 +   rmb();
 +   if (ACCESS_ONCE(ptemp[i]))
 +   result = -1;

Perhaps s/result/err/? You could even have an err_count, which would
give you slightly more useful output.

 +   /* Toggle Error bit (it is latched), leave ECC enabled */
 +   writel(error_mask, drvdata-base);
 +   writel(priv-ecc_enable_mask, drvdata-base);
 +   ptemp[i] = i;
 +   }
 +   /* Ensure it has been written out */
 +   wmb();
 +   local_irq_restore(flags);
 +
 +   if (result)
 +   edac_printk(KERN_ERR, EDAC_DEVICE, Mem Not Cleared\n);
 +
 +   /* Read out written data. ECC error caused here */
 +   for (i = 0; i  ALTR_TRIGGER_READ_WRD_CNT; i++)
 +   if (ACCESS_ONCE(ptemp[i]) != i)
 +   edac_printk(KERN_ERR, EDAC_DEVICE,
 +   Read doesn't match written data\n);
 +
 +   if

[PATCH 1/2] tracing: Add condition check to RCU lockdep checks

From: Steven Rostedt (Red Hat) rost...@goodmis.org

The trace_tlb_flush() tracepoint can be called when a CPU is going offline.
When a CPU is offline, RCU is no longer watching that CPU and since the
tracepoint is protected by RCU, it must not be called. To prevent the
tlb_flush tracepoint from being called when the CPU is offline, it was
converted to a TRACE_EVENT_CONDITION where the condition checks if the
CPU is online before calling the tracepoint.

Unfortunately, this was not enough to stop lockdep from complaining about
it. Even though the RCU protected code of the tracepoint will never be
called, the condition is hidden within the tracepoint, and even though the
condition prevents RCU code from being called, the lockdep checks are
outside the tracepoint (this is to test tracepoints even when they are not
enabled).

Even though tracepoints should be checked to be RCU safe when they are not
enabled, the condition should still be considered when checking RCU.

Link: 
http://lkml.kernel.org/r/CA+icZUUGiGDoL5NU8RuxKzFjoLjEKRtUWx=jb8b9a0eqv-e...@mail.gmail.com

Reported-by: Sedat Dilek sedat.di...@gmail.com
Signed-off-by: Steven Rostedt rost...@goodmis.org
---
 include/linux/tracepoint.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
index e08e21e5f601..68a346b8328a 100644
--- a/include/linux/tracepoint.h
+++ b/include/linux/tracepoint.h
@@ -173,7 +173,7 @@ extern void syscall_unregfunc(void);
TP_PROTO(data_proto),   \
TP_ARGS(data_args), \
TP_CONDITION(cond),,);  \
-   if (IS_ENABLED(CONFIG_LOCKDEP)) {   \
+   if (IS_ENABLED(CONFIG_LOCKDEP)  cond) {   
\
rcu_read_lock_sched_notrace();  \
rcu_dereference_sched(__tracepoint_##name.funcs);\
rcu_read_unlock_sched_notrace();\
-- 
2.1.4


--
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 0/2] tracing/tlb/x85: Fix splat of calling RCU trace code on offline CPU

Paul,

I found a much better fix than adding the rcu_nocheck(). Simply have the
rcu check inside the condition check as well. This way the rcu splat
will only happen if the condition is set too. The condition doesn't need
the tracepoint enabled.

Now I'm thinking that I should push the first patch through my tree as it
only touches tracing. The second patch you can freely take.

Neither patch really depends on the other, but both patches are required
to make the splat go away. If Sedat could test these patches together,
and give his tested-by tag, that would be great. I'll run my patch through
my full series of tests and then push to linux next. You could take the second
patch and push that through your tree (linux-next). When both arrive, the
bug will be fixed. The two do not need to come in together.

Thoughts?

-- Steve


Steven Rostedt (Red Hat) (2):
  tracing: Add condition check to RCU lockdep checks
  x86/tbl/trace: Do not trace on CPU that is offline


 include/linux/tracepoint.h | 2 +-
 include/trace/events/tlb.h | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)
--
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 2/2] x86/tbl/trace: Do not trace on CPU that is offline

On Fri, 6 Feb 2015 21:11:57 +0100
Sedat Dilek sedat.di...@gmail.com wrote:

 On Fri, Feb 6, 2015 at 9:06 PM, Steven Rostedt rost...@goodmis.org wrote:
  From: Steven Rostedt (Red Hat) rost...@goodmis.org
 
 
 Subject: x86/tbl/trace: --- .../tlb/...
 

But I wanted To Be Loved.

-- Steve

--
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 resend] spi: sc18is602: Support multiple devices on a single I2C bus if DT is configured

2015-02-06 Thread Guenter Roeck

The driver currently only supports a single device per I2C bus since it uses
the I2C bus number to set the SPI bus number. This makes it impossible to
connect more than one chip to a single I2C bus.

We don't want to use dynamic bus numbers unconditionally since this would
result in every instantiation getting a different bus number starting with
65,535 counting down unless devicetree is configured. If devicetree is
configured, however, the SPI bus number is obtained from devicetree
data. So we can use dynamic SPI bus numbers in this case.

Reported-and-Tested-by: Marco Menchise marco.mench...@gmail.com
Signed-off-by: Guenter Roeck li...@roeck-us.net
---
Resend, this time with Mark's correct e-mail address. Sorry for the noise.

 drivers/spi/spi-sc18is602.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-sc18is602.c b/drivers/spi/spi-sc18is602.c
index 237f2e7..c04e601 100644
--- a/drivers/spi/spi-sc18is602.c
+++ b/drivers/spi/spi-sc18is602.c
@@ -290,7 +290,7 @@ static int sc18is602_probe(struct i2c_client *client,
hw-freq = SC18IS602_CLOCK;
break;
}
-   master-bus_num = client-adapter-nr;
+   master-bus_num = np ? -1 : client-adapter-nr;
master-mode_bits = SPI_CPHA | SPI_CPOL | SPI_LSB_FIRST;
master-bits_per_word_mask = SPI_BPW_MASK(8);
master-setup = sc18is602_setup;
-- 
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 1/2] kernel/fork: handle put_user errors for CLONE_CHILD_SETTID/CLEARTID

2015-02-06 Thread Konstantin Khlebnikov

On Fri, Feb 6, 2015 at 10:55 PM, Oleg Nesterov o...@redhat.com wrote:
 On 02/06, Oleg Nesterov wrote:

 On 02/06, Konstantin Khlebnikov wrote:
 
  Whole sequence looks like: task calls fork, glibc calls syscall clone with
  CLONE_CHILD_SETTID and passes pointer to TLS THREAD_SELF-tid as argument.
  Child task gets read-only copy of VM including TLS. Child calls put_user()
  to handle CLONE_CHILD_SETTID from schedule_tail(). put_user() trigger page
  fault and it fails because do_wp_page()  hits memcg limit without invoking
  OOM-killer because this is page-fault from kernel-space.

 Because of !FAULT_FLAG_USER?

Yep. As I see memcg triggers OOM only on page-faults and only from user-space.


 Perhaps we should fix this? Say mem_cgroup_oom_enable/disable around 
 put_user(),
 I dunno.

  Put_user returns
  -EFAULT, which is ignored.  Child returns into user-space and catches here
  assert (THREAD_GETMEM (self, tid) != ppid),

 If only I understood why else we need CLONE_CHILD_SETTID ;)

I dunno, CLONE_PARENT_SETTID should be enough for everybody but it's
broken too. Twice. See the next patch =)


  --- a/kernel/sched/core.c
  +++ b/kernel/sched/core.c
  @@ -2312,8 +2312,20 @@ asmlinkage __visible void schedule_tail(struct 
  task_struct *prev)
  post_schedule(rq);
  preempt_enable();
 
  -   if (current-set_child_tid)
  -   put_user(task_pid_vnr(current), current-set_child_tid);
  +   if (current-set_child_tid 
  +   unlikely(put_user(task_pid_vnr(current), current-set_child_tid))) 
  {
  +   int dummy;
  +
  +   /*
  +* If this address is unreadable then userspace has not set
  +* proper pointer. Application either doesn't care or will
  +* notice this soon. If this address is readable then task
  +* will be mislead about its own tid. It's better to die.
  +*/
  +   if (!get_user(dummy, current-set_child_tid) 
  +   !fatal_signal_pending(current))
  +   force_sig(SIGSEGV, current);
  +   }

 Well, get_user() can fail the same way? The page we need to cow can be
 swapped out.

 At first glance, to me this problem should be solved somewhere else...
 I'll try to reread this all tomorrow.

 And in fact I think that this is not set_child_tid/etc-specific. Perhaps
 I am totally confused, but I think that put_user() simply should not fail
 this way. Say, why a syscall should return -EFAULT if memory allocation
 silently fails? Confused.

That's how memcg works. All other places are handled explicitly and
returns into user-space as -ENOMEM or -EFAULT.
Probably some strange numa policy / memoryaffinity might trigger this too.

Probably all page-faults must be forced to succeed or die mode,
in this case all errors in put_user/copy_to_user could be simply ignored.

--
Konstantin
--
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] livepatch: add missing newline to error message

2015-02-06 Thread Jiri Kosina

On Fri, 6 Feb 2015, Josh Poimboeuf wrote:

 Signed-off-by: Josh Poimboeuf jpoim...@redhat.com
 ---
  kernel/livepatch/core.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
 index 9adf86b..ff7f47d 100644
 --- a/kernel/livepatch/core.c
 +++ b/kernel/livepatch/core.c
 @@ -211,7 +211,7 @@ static int klp_verify_vmlinux_symbol(const char *name, 
 unsigned long addr)
   if (kallsyms_on_each_symbol(klp_verify_callback, args))
   return 0;
  
 - pr_err(symbol '%s' not found at specified address 0x%016lx, kernel 
 mismatch?,
 + pr_err(symbol '%s' not found at specified address 0x%016lx, kernel 
 mismatch?\n,
   name, addr);
   return -EINVAL;

Applied, thanks Josh.

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

Re: [PATCH 1/1] ARM: dts: Use more descriptive names for Exynos5420 PDs

2015-02-06 Thread Javier Martinez Canillas

Hello Sergei,

Thanks a lot for your feedback.

On 02/06/2015 08:09 PM, Sergei Shtylyov wrote:
 Hello.
 
 On 02/06/2015 08:37 PM, Javier Martinez Canillas wrote:
 
 All the device nodes for the Exynos5420 power-domains have a quite
 generic power-domain name.
 
 And this is in conformance to the ePAPR standard.
 

True, I forgot that the ePAPR recommends that the node names should be
somewhat generic but OTOH this is the only Exynos DTSI file that follows
the standard for the power domain device nodes. All other Exynos DTSI
use a prefix to differentiate between each power domain.

 So in case of an error, the Exynos PD
 driver shows the following (not very useful) message:
 
 Power domain power-domain disable failed
 
 Why not fix the message instead to use the full device name?


Well, the full node name is also not very useful IMHO since you have
to check the DTSI or SoC manual to map the device node unit-address to
the corresponding power domain.

I used $subject when debugging an HDMI issue and instead of dropping
it, I just posted it in case someone considered useful. I don't really
mind if the patch is nacked / not picked.

Best regards,
Javier
--
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 v1] clk: qcom: Add MSM8916 Global Clock Controller support

2015-02-06 Thread Georgi Djakov

This is preliminary and not fully tested patch which adds
support for the global clock controller found on the MSM8916
based devices. It allows the various device drivers to probe
and control their clocks and resets.

Signed-off-by: Georgi Djakov georgi.dja...@linaro.org
---
 .../devicetree/bindings/clock/qcom,gcc.txt |1 +
 drivers/clk/qcom/Kconfig   |8 +
 drivers/clk/qcom/Makefile  |1 +
 drivers/clk/qcom/gcc-msm8916.c | 2984 
 include/dt-bindings/clock/qcom,gcc-msm8916.h   |  162 ++
 include/dt-bindings/reset/qcom,gcc-msm8916.h   |  108 +
 6 files changed, 3264 insertions(+)
 create mode 100644 drivers/clk/qcom/gcc-msm8916.c
 create mode 100644 include/dt-bindings/clock/qcom,gcc-msm8916.h
 create mode 100644 include/dt-bindings/reset/qcom,gcc-msm8916.h

diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt 
b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
index aba3d254e037..54c23f34f194 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
@@ -8,6 +8,7 @@ Required properties :
qcom,gcc-apq8084
qcom,gcc-ipq8064
qcom,gcc-msm8660
+   qcom,gcc-msm8916
qcom,gcc-msm8960
qcom,gcc-msm8974
qcom,gcc-msm8974pro
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 0d7ab52b7ab0..d1772805cee6 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -46,6 +46,14 @@ config MSM_GCC_8660
  Say Y if you want to use peripheral devices such as UART, SPI,
  i2c, USB, SD/eMMC, etc.
 
+config MSM_GCC_8916
+   tristate MSM8916 Global Clock Controller
+   depends on COMMON_CLK_QCOM
+   help
+ Support for the global clock controller on msm8916 devices.
+ Say Y if you want to use peripheral devices such as UART, SPI,
+ i2c, USB, SD/eMMC, etc.
+
 config MSM_GCC_8960
tristate APQ8064/MSM8960 Global Clock Controller
depends on COMMON_CLK_QCOM
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 617826469595..50b337a24a87 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_APQ_MMCC_8084) += mmcc-apq8084.o
 obj-$(CONFIG_IPQ_GCC_806X) += gcc-ipq806x.o
 obj-$(CONFIG_IPQ_LCC_806X) += lcc-ipq806x.o
 obj-$(CONFIG_MSM_GCC_8660) += gcc-msm8660.o
+obj-$(CONFIG_MSM_GCC_8916) += gcc-msm8916.o
 obj-$(CONFIG_MSM_GCC_8960) += gcc-msm8960.o
 obj-$(CONFIG_MSM_LCC_8960) += lcc-msm8960.o
 obj-$(CONFIG_MSM_GCC_8974) += gcc-msm8974.o
diff --git a/drivers/clk/qcom/gcc-msm8916.c b/drivers/clk/qcom/gcc-msm8916.c
new file mode 100644
index ..ae3bf218f948
--- /dev/null
+++ b/drivers/clk/qcom/gcc-msm8916.c
@@ -0,0 +1,2984 @@
+/*
+ * Copyright 2015 Linaro Limited
+ *
+ * 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 linux/kernel.h
+#include linux/bitops.h
+#include linux/err.h
+#include linux/platform_device.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/clk-provider.h
+#include linux/regmap.h
+#include linux/reset-controller.h
+
+#include dt-bindings/clock/qcom,gcc-msm8916.h
+#include dt-bindings/reset/qcom,gcc-msm8916.h
+
+#include common.h
+#include clk-regmap.h
+#include clk-pll.h
+#include clk-rcg.h
+#include clk-branch.h
+#include reset.h
+
+#define P_XO   0
+#define P_GPLL01
+#define P_BIMC 2
+#define P_GPLL11
+#define P_GPLL21
+#define P_GPLL42
+#define P_SLEEP_CLK1
+#define P_GPLL1_AUX2
+#define P_GPLL0_AUX2
+#define P_GPLL2_AUX3
+#define P_DSI0_PHYPLL_BYTE 2
+#define P_DSI0_PHYPLL_DSI  2
+
+static const u8 gcc_xo_gpll0_map[] = {
+   [P_XO]  = 0,
+   [P_GPLL0]   = 1,
+};
+
+static const char *gcc_xo_gpll0[] = {
+   xo,
+   gpll0_vote,
+};
+
+static const u8 gcc_xo_gpll0_bimc_map[] = {
+   [P_XO]  = 0,
+   [P_GPLL0]   = 1,
+   [P_BIMC]= 2,
+};
+
+static const char *gcc_xo_gpll0_bimc[] = {
+   xo,
+   gpll0_vote,
+   bimc_pll,
+};
+
+static const u8 gcc_xo_gpll0a_gpll1_gpll2a_map[] = {
+   [P_XO]  = 0,
+   [P_GPLL1]   = 1,
+   [P_GPLL0_AUX]   = 3,
+   [P_GPLL2_AUX]   =

Re: [PATCH v13 3/6] clk: Make clk API return per-user struct clk instances

2015-02-06 Thread Russell King - ARM Linux

On Fri, Feb 06, 2015 at 11:30:18AM -0800, Stephen Boyd wrote:
 Why don't we make the legacy lookup more specific and actually indicate
 internal for the con_id? Then the external clock would fail to be
 found, but we can detect that case and figure out that it's not due to
 probe defer, but instead due to the fact that there really isn't any
 mapping. It looks like the code is already prepared for this anyway.

We _could_, and that would solve this specific issue, but I'd suggest
coccinelle is used to locate any other similar instances of this.

As I'm allergic to coccinelle (or coccinelle is allergic to me since
I never seem to be able to get it to do what I want...)

-- 
FTTC broadband for 0.8mile line: currently at 10.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/

[PATCH v2 2/3] clk: Rename child_node to clks_node to avoid confusion

2015-02-06 Thread Stephen Boyd

The child_node member of struct clk is named the same as the
child_node member of struct clk_core. Let's rename the struct
clk's member to clks_node to avoid getting confused with the
child_node member of struct clk_core and to match the name of the
list head, clks.

Reviewed-by: Tomeu Vizoso tomeu.viz...@collabora.com
Cc: Alban Browaeys alban.browa...@gmail.com
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
 drivers/clk/clk.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 5469d7714f5d..315dc22b7356 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -83,7 +83,7 @@ struct clk {
const char *con_id;
unsigned long min_rate;
unsigned long max_rate;
-   struct hlist_node child_node;
+   struct hlist_node clks_node;
 };
 
 /***   locking ***/
@@ -851,10 +851,10 @@ static void clk_core_get_boundaries(struct clk_core *clk,
*min_rate = 0;
*max_rate = ULONG_MAX;
 
-   hlist_for_each_entry(clk_user, clk-clks, child_node)
+   hlist_for_each_entry(clk_user, clk-clks, clks_node)
*min_rate = max(*min_rate, clk_user-min_rate);
 
-   hlist_for_each_entry(clk_user, clk-clks, child_node)
+   hlist_for_each_entry(clk_user, clk-clks, clks_node)
*max_rate = min(*max_rate, clk_user-max_rate);
 }
 
@@ -2376,7 +2376,7 @@ struct clk *__clk_create_clk(struct clk_hw *hw, const 
char *dev_id,
clk-max_rate = ULONG_MAX;
 
clk_prepare_lock();
-   hlist_add_head(clk-child_node, hw-core-clks);
+   hlist_add_head(clk-clks_node, hw-core-clks);
clk_prepare_unlock();
 
return clk;
@@ -2385,7 +2385,7 @@ struct clk *__clk_create_clk(struct clk_hw *hw, const 
char *dev_id,
 void __clk_free_clk(struct clk *clk)
 {
clk_prepare_lock();
-   hlist_del(clk-child_node);
+   hlist_del(clk-clks_node);
clk_prepare_unlock();
 
kfree(clk);
@@ -2663,7 +2663,7 @@ void __clk_put(struct clk *clk)
 
clk_prepare_lock();
 
-   hlist_del(clk-child_node);
+   hlist_del(clk-clks_node);
clk_core_set_rate_nolock(clk-core, clk-core-req_rate);
owner = clk-core-owner;
kref_put(clk-core-ref, __clk_release);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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 3/8] x86, fpu: kill save_init_fpu(), change math_error() to use unlazy_fpu()

From: Oleg Nesterov o...@redhat.com

math_error() calls save_init_fpu() after conditional_sti(), this means
that the caller can be preempted. If !use_eager_fpu() we can hit the
WARN_ON_ONCE(!__thread_has_fpu(tsk)) and/or save the wrong FPU state.

Change math_error() to use unlazy_fpu() and kill save_init_fpu().

Signed-off-by: Oleg Nesterov o...@redhat.com
Signed-off-by: Rik van Riel r...@redhat.com
---
 arch/x86/include/asm/fpu-internal.h | 18 --
 arch/x86/kernel/traps.c |  2 +-
 2 files changed, 1 insertion(+), 19 deletions(-)

diff --git a/arch/x86/include/asm/fpu-internal.h 
b/arch/x86/include/asm/fpu-internal.h
index 0dbc08282291..27d00e04f911 100644
--- a/arch/x86/include/asm/fpu-internal.h
+++ b/arch/x86/include/asm/fpu-internal.h
@@ -520,24 +520,6 @@ static inline void __save_fpu(struct task_struct *tsk)
 }
 
 /*
- * These disable preemption on their own and are safe
- */
-static inline void save_init_fpu(struct task_struct *tsk)
-{
-   WARN_ON_ONCE(!__thread_has_fpu(tsk));
-
-   if (use_eager_fpu()) {
-   __save_fpu(tsk);
-   return;
-   }
-
-   preempt_disable();
-   __save_init_fpu(tsk);
-   __thread_fpu_end(tsk);
-   preempt_enable();
-}
-
-/*
  * i387 state interaction
  */
 static inline unsigned short get_fpu_cwd(struct task_struct *tsk)
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index fb4cb6adf225..51c465846f06 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -663,7 +663,7 @@ static void math_error(struct pt_regs *regs, int 
error_code, int trapnr)
/*
 * Save the info for the exception handler and clear the error.
 */
-   save_init_fpu(task);
+   unlazy_fpu(task);
task-thread.trap_nr = trapnr;
task-thread.error_code = error_code;
info.si_signo = SIGFPE;
-- 
1.9.3

--
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 1/8] x86, fpu: unlazy_fpu: don't reset thread.fpu_counter

From: Oleg Nesterov o...@redhat.com

It is not clear why the else branch clears -fpu_counter, this makes
no sense.

If use_eager_fpu() then this has no effect. Otherwise, if we actually
wanted to prevent fpu preload after the context switch we would need to
reset it unconditionally, even if __thread_has_fpu().

Signed-off-by: Oleg Nesterov o...@redhat.com
Signed-off-by: Rik van Riel r...@redhat.com
---
 arch/x86/kernel/i387.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
index 47348653503a..c3b92c0975cd 100644
--- a/arch/x86/kernel/i387.c
+++ b/arch/x86/kernel/i387.c
@@ -122,8 +122,7 @@ void unlazy_fpu(struct task_struct *tsk)
if (__thread_has_fpu(tsk)) {
__save_init_fpu(tsk);
__thread_fpu_end(tsk);
-   } else
-   tsk-thread.fpu_counter = 0;
+   }
preempt_enable();
 }
 EXPORT_SYMBOL(unlazy_fpu);
-- 
1.9.3

--
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 4/8] x86,fpu: move lazy restore functions up a few lines

From: Rik van Riel r...@redhat.com

We need another lazy restore related function, that will be called
from a function that is above where the lazy restore functions are
now. It would be nice to keep all three functions grouped together.

Signed-off-by: Rik van Riel r...@redhat.com
---
 arch/x86/include/asm/fpu-internal.h | 36 ++--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/arch/x86/include/asm/fpu-internal.h 
b/arch/x86/include/asm/fpu-internal.h
index 27d00e04f911..439ac3921a1e 100644
--- a/arch/x86/include/asm/fpu-internal.h
+++ b/arch/x86/include/asm/fpu-internal.h
@@ -67,6 +67,24 @@ extern void finit_soft_fpu(struct i387_soft_struct *soft);
 static inline void finit_soft_fpu(struct i387_soft_struct *soft) {}
 #endif
 
+/*
+ * Must be run with preemption disabled: this clears the fpu_owner_task,
+ * on this CPU.
+ *
+ * This will disable any lazy FPU state restore of the current FPU state,
+ * but if the current thread owns the FPU, it will still be saved by.
+ */
+static inline void __cpu_disable_lazy_restore(unsigned int cpu)
+{
+   per_cpu(fpu_owner_task, cpu) = NULL;
+}
+
+static inline int fpu_lazy_restore(struct task_struct *new, unsigned int cpu)
+{
+   return new == this_cpu_read_stable(fpu_owner_task) 
+   cpu == new-thread.fpu.last_cpu;
+}
+
 static inline int is_ia32_compat_frame(void)
 {
return config_enabled(CONFIG_IA32_EMULATION) 
@@ -400,24 +418,6 @@ static inline void drop_init_fpu(struct task_struct *tsk)
  */
 typedef struct { int preload; } fpu_switch_t;
 
-/*
- * Must be run with preemption disabled: this clears the fpu_owner_task,
- * on this CPU.
- *
- * This will disable any lazy FPU state restore of the current FPU state,
- * but if the current thread owns the FPU, it will still be saved by.
- */
-static inline void __cpu_disable_lazy_restore(unsigned int cpu)
-{
-   per_cpu(fpu_owner_task, cpu) = NULL;
-}
-
-static inline int fpu_lazy_restore(struct task_struct *new, unsigned int cpu)
-{
-   return new == this_cpu_read_stable(fpu_owner_task) 
-   cpu == new-thread.fpu.last_cpu;
-}
-
 static inline fpu_switch_t switch_fpu_prepare(struct task_struct *old, struct 
task_struct *new, int cpu)
 {
fpu_switch_t fpu;
-- 
1.9.3

--
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 6/8] x86,fpu: use an explicit if/else in switch_fpu_prepare

From: Rik van Riel r...@redhat.com

Use an explicit if/else branch after __save_init_fpu(old) in
switch_fpu_prepare.  This makes substituting the assignment
with a call to task_disable_lazy_fpu() in the next patch easier
to review.

Signed-off-by: Rik van Riel r...@redhat.com
---
 arch/x86/include/asm/fpu-internal.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/fpu-internal.h 
b/arch/x86/include/asm/fpu-internal.h
index c1f66261ad12..04063751ac80 100644
--- a/arch/x86/include/asm/fpu-internal.h
+++ b/arch/x86/include/asm/fpu-internal.h
@@ -440,8 +440,9 @@ static inline fpu_switch_t switch_fpu_prepare(struct 
task_struct *old, struct ta
 new-thread.fpu_counter  5);
if (__thread_has_fpu(old)) {
if (!__save_init_fpu(old))
-   cpu = ~0;
-   old-thread.fpu.last_cpu = cpu;
+   old-thread.fpu.last_cpu = ~0;
+   else
+   old-thread.fpu.last_cpu = cpu;
old-thread.fpu.has_fpu = 0;/* But leave fpu_owner_task! */
 
/* Don't change CR0.TS if we just switch! */
-- 
1.9.3

--
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 2/2] x86/tbl/trace: Do not trace on CPU that is offline

2015-02-06 Thread Sedat Dilek

On Fri, Feb 6, 2015 at 9:06 PM, Steven Rostedt rost...@goodmis.org wrote:
 From: Steven Rostedt (Red Hat) rost...@goodmis.org


Subject: x86/tbl/trace: --- .../tlb/...

- Sedat -

 When taking a CPU down for suspend and resume, a tracepoint may be called
 when the CPU has been designated offline. As tracepoints require RCU for
 protection, they must not be called if the current CPU is offline.

 Unfortunately, trace_tlb_flush() is called in this scenario as was noted
 by LOCKDEP:

 ...

  Disabling non-boot CPUs ...
  intel_pstate CPU 1 exiting

  ===
  smpboot: CPU 1 didn't die...
  [ INFO: suspicious RCU usage. ]
  3.19.0-rc7-next-20150204.1-iniza-small #1 Not tainted
  ---
  include/trace/events/tlb.h:35 suspicious rcu_dereference_check() usage!

  other info that might help us debug this:

  RCU used illegally from offline CPU!
  rcu_scheduler_active = 1, debug_locks = 0
  no locks held by swapper/1/0.

  stack backtrace:
  CPU: 1 PID: 0 Comm: swapper/1 Not tainted 
 3.19.0-rc7-next-20150204.1-iniza-small #1
  Hardware name: SAMSUNG ELECTRONICS CO., LTD. 
 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
   0001 88011a44fe18 817e370d 0011
   88011a448290 88011a44fe48 810d6847 8800c66b9600
   0001 88011a44c000 81cb3900 88011a44fe78
  Call Trace:
   [817e370d] dump_stack+0x4c/0x65
   [810d6847] lockdep_rcu_suspicious+0xe7/0x120
   [810b71a5] idle_task_exit+0x205/0x2c0
   [81054c4e] play_dead_common+0xe/0x50
   [81054ca5] native_play_dead+0x15/0x140
   [8102963f] arch_cpu_idle_dead+0xf/0x20
   [810cd89e] cpu_startup_entry+0x37e/0x580
   [81053e20] start_secondary+0x140/0x150
  intel_pstate CPU 2 exiting

 ...

 By converting the tlb_flush tracepoint to a TRACE_EVENT_CONDITION where the
 condition is cpu_online(smp_processor_id()), we can avoid calling RCU 
 protected
 code when the CPU is offline.

 Link: 
 http://lkml.kernel.org/r/CA+icZUUGiGDoL5NU8RuxKzFjoLjEKRtUWx=jb8b9a0eqv-e...@mail.gmail.com

 Reported-by: Sedat Dilek sedat.di...@gmail.com
 Suggested-by: Paul E. McKenney paul...@linux.vnet.ibm.com
 Signed-off-by: Steven Rostedt rost...@goodmis.org
 ---
  include/trace/events/tlb.h | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

 diff --git a/include/trace/events/tlb.h b/include/trace/events/tlb.h
 index 13391d288107..0e7635765153 100644
 --- a/include/trace/events/tlb.h
 +++ b/include/trace/events/tlb.h
 @@ -13,11 +13,13 @@
 { TLB_LOCAL_SHOOTDOWN,  local shootdown },\
 { TLB_LOCAL_MM_SHOOTDOWN,   local mm shootdown }

 -TRACE_EVENT(tlb_flush,
 +TRACE_EVENT_CONDITION(tlb_flush,

 TP_PROTO(int reason, unsigned long pages),
 TP_ARGS(reason, pages),

 +   TP_CONDITION(cpu_online(smp_processor_id())),
 +
 TP_STRUCT__entry(
 __field(  int, reason)
 __field(unsigned long,  pages)
 --
 2.1.4


--
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 1/2] tracing: Add condition check to RCU lockdep checks


 diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
 index e08e21e5f601..68a346b8328a 100644
 --- a/include/linux/tracepoint.h
 +++ b/include/linux/tracepoint.h
 @@ -173,7 +173,7 @@ extern void syscall_unregfunc(void);
   TP_PROTO(data_proto),   \
   TP_ARGS(data_args), \
   TP_CONDITION(cond),,);  \
 - if (IS_ENABLED(CONFIG_LOCKDEP)) {   \
 + if (IS_ENABLED(CONFIG_LOCKDEP)  cond) {   
 \

Bah,

cond needs to be in parenthesis. Will post a v2 of this patch.

-- Steve

   rcu_read_lock_sched_notrace();  \
   rcu_dereference_sched(__tracepoint_##name.funcs);\
   rcu_read_unlock_sched_notrace();\

--
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: MADV_DONTNEED semantics? Was: [RFC PATCH] mm: madvise: Ignore repeated MADV_DONTNEED hints

2015-02-06 Thread Michal Hocko

On Fri 06-02-15 16:57:50, Michael Kerrisk wrote:
[...]
  Yes, this wording is better because many users are not aware of
  MAP_ANON|MAP_SHARED being file backed in fact and mmap man page doesn't
  mention that.
 
 (Michal, would you have a text to propose to add to the mmap(2) page?
 Maybe it would be useful to add something there.)

I am half way on vacation, but I can cook a patch after I am back after
week.
 
  I am just wondering whether it makes sense to mention that MADV_DONTNEED
  for shared mappings might be surprising and not freeing the backing
  pages thus not really freeing memory until there is a memory
  pressure. But maybe this is too implementation specific for a man
  page. What about the following wording on top of yours?
  
  Please note that the MADV_DONTNEED hint on shared mappings might not
  lead to immediate freeing of pages in the range. The kernel is free to
  delay this until an appropriate moment. RSS of the calling process will
  be reduced however.
  
 
 Thanks! I added this, but dropped in the word immediately in the last 
 sentence, since I assume that was implied. So now we have:
 
   After  a  successful MADV_DONTNEED operation, the seman‐
   tics of  memory  access  in  the  specified  region  are
   changed:  subsequent accesses of pages in the range will
   succeed, but will result in either repopulating the mem‐
   ory  contents from the up-to-date contents of the under‐
   lying mapped file  (for  shared  file  mappings,  shared
   anonymous  mappings,  and shmem-based techniques such as
   System V shared memory segments) or  zero-fill-on-demand
   pages for anonymous private mappings.
 
   Note  that,  when applied to shared mappings, MADV_DONT‐
   NEED might not lead to immediate freeing of the pages in
   the  range.   The  kernel  is  free to delay freeing the
   pages until an appropriate  moment.   The  resident  set
   size  (RSS)  of  the calling process will be immediately
   reduced however.

This sounds good to me and it is definitely much better than the current
state. Thanks!

 The current draft of the page can be found in a branch,
 http://git.kernel.org/cgit/docs/man-pages/man-pages.git/log/?h=draft_madvise
 
 Thanks,
 
 Michael
 
 
 
 -- 
 Michael Kerrisk
 Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
 Linux/UNIX System Programming Training: http://man7.org/training/

-- 
Michal Hocko
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/

Re: [PATCH 0/2] tracing/tlb/x85: Fix splat of calling RCU trace code on offline CPU

On Fri, 6 Feb 2015 16:18:03 -0500
Steven Rostedt rost...@goodmis.org wrote:


 But the first patch is a much broader change and more generic which
 could affect many other locations as well. It is specific to
 tracepoints, where the tlb one is specific to a single instance. As the
 first patch affects all tracepoints, I want it in my tree.
 

I may as well just push the first patch directly to Linus, as it does
fix false positives.

-- Steve
--
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/

[GIT PULL] please pull infiniband.git

2015-02-06 Thread Roland Dreier

Hi Linus,

Please pull from

git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git 
tags/rdma-for-linus


One more last-second RDMA change for 3.19:
 - Yann realized that the previous revert of new userspace ABI did not
   go far enough, and we're still exposing a change that we don't want.
   Revert even closer to 3.18 interface to make sure we get things right
   in the long run.

Sorry for sending this at the very end of the release cycle, but we
didn't realize the scope of the required fix until just now.


Yann Droneaud (1):
  Revert IB/core: Add support for extended query device caps

 drivers/infiniband/core/uverbs.h |   1 -
 drivers/infiniband/core/uverbs_cmd.c | 137 +++
 drivers/infiniband/hw/mlx5/main.c|   2 -
 include/rdma/ib_verbs.h  |   5 +-
 include/uapi/rdma/ib_user_verbs.h|  27 ---
 5 files changed, 42 insertions(+), 130 deletions(-)
--
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 1/5] rcu,nohz: add state parameter to context_tracking_user_enter/exit

2015-02-06 Thread Rik van Riel

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/06/2015 01:23 PM, Frederic Weisbecker wrote:
 On Fri, Feb 06, 2015 at 01:20:21PM -0500, Rik van Riel wrote: On
 02/06/2015 12:22 PM, Frederic Weisbecker wrote:
 On Thu, Feb 05, 2015 at 03:23:48PM -0500, r...@redhat.com
 wrote:
 From: Rik van Riel r...@redhat.com
 
 Add the expected ctx_state as a parameter to 
 context_tracking_user_enter and
 context_tracking_user_exit, allowing the same functions to
 not just track kernel  user space switching, but also
 kernel  guest transitions.
 
 Signed-off-by: Rik van Riel r...@redhat.com
 
 You should consider using guest_enter() and guest_exit()
 instead. These are context tracking APIs too but specifically
 for guest.
 
 What do you mean instead?  KVM already uses those.
 
 I just wanted to avoid duplicating the code...
 
 I mean you can call rcu_user APIs directly from
 guest_enter/exit. You don't really need to call the
 context_tracking_user functions since guest_enter/guest_exit
 already handle the vtime accounting.

I would still have to modify exception_enter and exception_exit,
and with them context_tracking_user_enter and
context_tracking_user_exit.

We have to re-enable RCU when an exception happens.

I suspect exceptions in a guest just trigger VMEXIT, and we
figure later why the exception happened. However, if we were
to get an exception during the code where we transition into
or out of guest mode, we would still need exception_enter
and exception_exit...

- -- 
All rights reversed
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJU1Q1MAAoJEM553pKExN6DB90H/iVCnfrooAB15E5Qioa3Ty+X
hNMaIMX6zjYg++IFR5BhYLp9hp36o/98sv8RLTjZQix2q1ljivobmbABvx2MBNhx
NiPfU9DyBkhz3gwI4oTkggb383Wrcyt+RgvclI/96AbwkhrdzxmT1nnUc0kA98xC
6NTW2+imkYX31sY/2SFmYWnJMVZOjOIep3LCVh/hrWnQARd6mdyzzFr+v6Z/vyFe
8P2rbqlkN0nf1pGYz3VF6zqF8wVmOi1mx4mo0qy80Sax7jsZv9+gGfbF1HkHJnjg
FLsj/q/mcrH1GBK54a3s3P6ghpcFXfwibjhkGmrmA07XNHqLiNgKgmgPtArhU+s=
=9Ln1
-END PGP SIGNATURE-
--
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: [PATCHv6 1/5] arm: socfpga: Enable L2 Cache ECC on startup.

2015-02-06 Thread Mark Rutland

On Fri, Jan 09, 2015 at 02:53:52AM +, ttha...@opensource.altera.com wrote:
 From: Thor Thayer ttha...@opensource.altera.com
 
 This patch enables the ECC for L2 cache on machine
 startup.  The ECC has to be enabled before data is
 is stored in memory otherwise the ECC will fail on
 reads.

I take it you mean before the L2 cache is enabled (and its memories are
used), rather than before main memory is in use?

 
 Signed-off-by: Thor Thayer ttha...@opensource.altera.com
 ---
 v2: Split OCRAM initialization into separate patch.
 
 v3/4: No change
 
 v5: Remove l2cache.h, use io.h instead of clk-provider.h
 Make copyright header inclusive. Remove MAINTAINERS entry.
 
 v6: Remove pr_debug()  update year in header.
 ---
  arch/arm/mach-socfpga/Makefile   |1 +
  arch/arm/mach-socfpga/core.h |2 ++
  arch/arm/mach-socfpga/l2_cache.c |   39 
 ++
  arch/arm/mach-socfpga/socfpga.c  |4 +++-
  4 files changed, 45 insertions(+), 1 deletion(-)
  create mode 100644 arch/arm/mach-socfpga/l2_cache.c
 
 diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
 index 6dd7a93..142609e 100644
 --- a/arch/arm/mach-socfpga/Makefile
 +++ b/arch/arm/mach-socfpga/Makefile
 @@ -4,3 +4,4 @@
  
  obj-y:= socfpga.o
  obj-$(CONFIG_SMP)+= headsmp.o platsmp.o
 +obj-$(CONFIG_EDAC_ALTERA_L2C) += l2_cache.o
 diff --git a/arch/arm/mach-socfpga/core.h b/arch/arm/mach-socfpga/core.h
 index 483cb46..28c8a15 100644
 --- a/arch/arm/mach-socfpga/core.h
 +++ b/arch/arm/mach-socfpga/core.h
 @@ -47,4 +47,6 @@ extern unsigned long socfpga_cpu1start_addr;
  
  #define SOCFPGA_SCU_VIRT_BASE   0xfffec000
  
 +void socfpga_init_l2_ecc(void);
 +
  #endif
 diff --git a/arch/arm/mach-socfpga/l2_cache.c 
 b/arch/arm/mach-socfpga/l2_cache.c
 new file mode 100644
 index 000..047759d
 --- /dev/null
 +++ b/arch/arm/mach-socfpga/l2_cache.c
 @@ -0,0 +1,39 @@
 +/*
 + * Copyright Altera Corporation (C) 2015. All rights reserved.
 + *
 + * 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.
 + *
 + * This program is distributed in the hope 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 http://www.gnu.org/licenses/.
 + */
 +#include linux/io.h
 +#include linux/of_platform.h
 +#include linux/of_address.h
 +
 +void socfpga_init_l2_ecc(void)
 +{
 + struct device_node *np;
 + void __iomem  *mapped_l2_edac_addr;
 +
 + np = of_find_compatible_node(NULL, NULL, altr,l2-edac);
 + if (!np) {
 + pr_err(SOCFPGA: Unable to find altr,l2-edac in dtb\n);
 + return;
 + }
 +
 + mapped_l2_edac_addr = of_iomap(np, 0);
 + if (!mapped_l2_edac_addr) {
 + pr_err(SOCFPGA: Unable to find L2 ECC mapping in dtb\n);
 + return;
 + }
 +
 + /* Enable ECC */
 + writel(0x01, mapped_l2_edac_addr);

Missing of_node_put(np)?

Surely you're leaking the mapping here? It's locally scoped and you
never unmap it.

Thanks,
Mark.
--
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 1/1] ARM: dts: Use more descriptive names for Exynos5420 PDs

2015-02-06 Thread Sergei Shtylyov


Hello.

On 02/06/2015 08:37 PM, Javier Martinez Canillas wrote:


All the device nodes for the Exynos5420 power-domains have a quite
generic power-domain name.


   And this is in conformance to the ePAPR standard.


So in case of an error, the Exynos PD
driver shows the following (not very useful) message:



Power domain power-domain disable failed


   Why not fix the message instead to use the full device name?


Use descriptive names to know on which PD enable or disable failed.



Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk


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 0/2] ARM: omap2+: omap_hwmod: Fix false lockdep warning

2015-02-06 Thread Peter Ujfalusi

On 02/06/2015 08:32 PM, Peter Zijlstra wrote:
 On Fri, Feb 06, 2015 at 06:05:32PM +0200, Peter Ujfalusi wrote:
 Certainly looks much simpler, but it adds quite a bit of data to the
 omap_hwmod struct, and we have a _lot_ of them for omap2plus configuration.

 ls -al vmlinux

 w/o any the lockdep warning fixes:
 110109168

 With my series applied:
 110112031 (base + 2863)

 With setting individual lockdep class:
 110114275 (base + 5107)

 I certainly like the lockdep_set_class() way since it is cleaner, but it adds
 almost double amount of bytes to the kernel.
 
 Yeah, I've never really bothered with data too much, its a debug
 feature. So lock_class_key is 8 bytes, and strictly speaking you could
 union them over other fields, all we really need is unique addresses, we
 don't actually use the storage.

True. our omap2plus defconfig does not have LOCKDEP enabled so it should not
add anything to the data when running default kernel.
I'll test the lockdep_set_class() method you suggested on Monday (not
tomorrow), but still as first thing.
If it is working as expected I'll send a patch with you as author.

Thanks,
Péter
--
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 7/8] x86,fpu: use disable_task_lazy_fpu_restore helper

From: Rik van Riel r...@redhat.com

Replace magic assignments of fpu.last_cpu = ~0 with more explicit
disable_task_lazy_fpu_restore calls.

This also fixes the lazy FPU restore disabling in drop_fpu, which
only really works when !use_eager_fpu().  This is fine for now,
because fpu_lazy_restore() is only used when !use_eager_fpu()
currently, but we may want to expand that.

Signed-off-by: Rik van Riel r...@redhat.com
---
 arch/x86/include/asm/fpu-internal.h | 4 ++--
 arch/x86/kernel/i387.c  | 2 +-
 arch/x86/kernel/process.c   | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/fpu-internal.h 
b/arch/x86/include/asm/fpu-internal.h
index 04063751ac80..06af286593d7 100644
--- a/arch/x86/include/asm/fpu-internal.h
+++ b/arch/x86/include/asm/fpu-internal.h
@@ -440,7 +440,7 @@ static inline fpu_switch_t switch_fpu_prepare(struct 
task_struct *old, struct ta
 new-thread.fpu_counter  5);
if (__thread_has_fpu(old)) {
if (!__save_init_fpu(old))
-   old-thread.fpu.last_cpu = ~0;
+   task_disable_lazy_fpu_restore(old);
else
old-thread.fpu.last_cpu = cpu;
old-thread.fpu.has_fpu = 0;/* But leave fpu_owner_task! */
@@ -454,7 +454,7 @@ static inline fpu_switch_t switch_fpu_prepare(struct 
task_struct *old, struct ta
stts();
} else {
old-thread.fpu_counter = 0;
-   old-thread.fpu.last_cpu = ~0;
+   task_disable_lazy_fpu_restore(old);
if (fpu.preload) {
new-thread.fpu_counter++;
if (!use_eager_fpu()  fpu_lazy_restore(new, cpu))
diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
index 8e070a6c30e5..8416b5f85806 100644
--- a/arch/x86/kernel/i387.c
+++ b/arch/x86/kernel/i387.c
@@ -250,7 +250,7 @@ int init_fpu(struct task_struct *tsk)
if (tsk_used_math(tsk)) {
if (cpu_has_fpu  tsk == current)
unlazy_fpu(tsk);
-   tsk-thread.fpu.last_cpu = ~0;
+   task_disable_lazy_fpu_restore(tsk);
return 0;
}
 
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index dd9a069a5ec5..83480373a642 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -68,8 +68,8 @@ int arch_dup_task_struct(struct task_struct *dst, struct 
task_struct *src)
 
dst-thread.fpu_counter = 0;
dst-thread.fpu.has_fpu = 0;
-   dst-thread.fpu.last_cpu = ~0;
dst-thread.fpu.state = NULL;
+   task_disable_lazy_fpu_restore(dst);
if (tsk_used_math(src)) {
int err = fpu_alloc(dst-thread.fpu);
if (err)
-- 
1.9.3

--
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 0/8] x86,fpu: various small FPU cleanups and optimizations

This includes the three patches by Oleg that are not in -tip yet,
and five more by myself.

I believe the changes to my patches address all the comments by
reviewers on the previous version.

--
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 5/8] x86,fpu: introduce task_disable_lazy_fpu_restore helper

From: Rik van Riel r...@redhat.com

Currently there are a few magic assignments sprinkled through the
code that disable lazy FPU state restoring, some more effective than
others, and all equally mystifying.

It would be easier to have a helper to explicitly disable lazy
FPU state restoring for a task.

Signed-off-by: Rik van Riel r...@redhat.com
---
 arch/x86/include/asm/fpu-internal.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/x86/include/asm/fpu-internal.h 
b/arch/x86/include/asm/fpu-internal.h
index 439ac3921a1e..c1f66261ad12 100644
--- a/arch/x86/include/asm/fpu-internal.h
+++ b/arch/x86/include/asm/fpu-internal.h
@@ -79,6 +79,16 @@ static inline void __cpu_disable_lazy_restore(unsigned int 
cpu)
per_cpu(fpu_owner_task, cpu) = NULL;
 }
 
+/*
+ * Used to indicate that the FPU state in memory is newer than the FPU
+ * state in registers, and the FPU state should be reloaded next time the
+ * task is run. Only safe on the current task, or non-running tasks.
+ */
+static inline void task_disable_lazy_fpu_restore(struct task_struct *tsk)
+{
+   tsk-thread.fpu.last_cpu = ~0;
+}
+
 static inline int fpu_lazy_restore(struct task_struct *new, unsigned int cpu)
 {
return new == this_cpu_read_stable(fpu_owner_task) 
-- 
1.9.3

--
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 2/8] x86, fpu: unlazy_fpu: don't do __thread_fpu_end() if use_eager_fpu()

From: Oleg Nesterov o...@redhat.com

unlazy_fpu()-__thread_fpu_end() doesn't look right if use_eager_fpu().
Unconditional __thread_fpu_end() is only correct if we know that this
thread can't return to user-mode and use FPU.

Fortunately it has only 2 callers. fpu_copy() checks use_eager_fpu(),
and init_fpu(current) can be only called by the coredumping thread via
regset-get(). But it is exported to modules, and imo this should be
fixed anyway.

And if we check use_eager_fpu() we can use __save_fpu() like fpu_copy()
and save_init_fpu() do.

- It seems that even !use_eager_fpu() case doesn't need the unconditional
  __thread_fpu_end(), we only need it if __save_init_fpu() returns 0.

- It is still not clear to me if __save_init_fpu() can safely nest with
  another save + restore from __kernel_fpu_begin(). If not, we can use
  kernel_fpu_disable() to fix the race.

Signed-off-by: Oleg Nesterov o...@redhat.com
Signed-off-by: Rik van Riel r...@redhat.com
---
 arch/x86/kernel/i387.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
index c3b92c0975cd..8e070a6c30e5 100644
--- a/arch/x86/kernel/i387.c
+++ b/arch/x86/kernel/i387.c
@@ -120,8 +120,12 @@ void unlazy_fpu(struct task_struct *tsk)
 {
preempt_disable();
if (__thread_has_fpu(tsk)) {
-   __save_init_fpu(tsk);
-   __thread_fpu_end(tsk);
+   if (use_eager_fpu()) {
+   __save_fpu(tsk);
+   } else {
+   __save_init_fpu(tsk);
+   __thread_fpu_end(tsk);
+   }
}
preempt_enable();
 }
-- 
1.9.3

--
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 8/8] x86,fpu: also check fpu_lazy_restore when use_eager_fpu

From: Rik van Riel r...@redhat.com

With Oleg's patch x86, fpu: don't abuse FPU in kernel threads if
use_eager_fpu(), kernel threads no longer have an FPU state even
on systems with use_eager_fpu()

That in turn means that a task may still have its FPU state
loaded in the FPU registers, if the task only got interrupted by
kernel threads from when it went to sleep, to when it woke up
again.

In that case, there is no need to restore the FPU state for
this task, since it is still in the registers.

The kernel can simply use the same logic to determine this as
is used for !use_eager_fpu() systems.

Signed-off-by: Rik van Riel r...@redhat.com
---
 arch/x86/include/asm/fpu-internal.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/fpu-internal.h 
b/arch/x86/include/asm/fpu-internal.h
index 06af286593d7..723b74da0685 100644
--- a/arch/x86/include/asm/fpu-internal.h
+++ b/arch/x86/include/asm/fpu-internal.h
@@ -457,7 +457,7 @@ static inline fpu_switch_t switch_fpu_prepare(struct 
task_struct *old, struct ta
task_disable_lazy_fpu_restore(old);
if (fpu.preload) {
new-thread.fpu_counter++;
-   if (!use_eager_fpu()  fpu_lazy_restore(new, cpu))
+   if (fpu_lazy_restore(new, cpu))
fpu.preload = 0;
else
prefetch(new-thread.fpu.state);
-- 
1.9.3

--
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 2/2] x86/tbl/trace: Do not trace on CPU that is offline

From: Steven Rostedt (Red Hat) rost...@goodmis.org

When taking a CPU down for suspend and resume, a tracepoint may be called
when the CPU has been designated offline. As tracepoints require RCU for
protection, they must not be called if the current CPU is offline.

Unfortunately, trace_tlb_flush() is called in this scenario as was noted
by LOCKDEP:

...

 Disabling non-boot CPUs ...
 intel_pstate CPU 1 exiting

 ===
 smpboot: CPU 1 didn't die...
 [ INFO: suspicious RCU usage. ]
 3.19.0-rc7-next-20150204.1-iniza-small #1 Not tainted
 ---
 include/trace/events/tlb.h:35 suspicious rcu_dereference_check() usage!

 other info that might help us debug this:

 RCU used illegally from offline CPU!
 rcu_scheduler_active = 1, debug_locks = 0
 no locks held by swapper/1/0.

 stack backtrace:
 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 
3.19.0-rc7-next-20150204.1-iniza-small #1
 Hardware name: SAMSUNG ELECTRONICS CO., LTD. 
530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
  0001 88011a44fe18 817e370d 0011
  88011a448290 88011a44fe48 810d6847 8800c66b9600
  0001 88011a44c000 81cb3900 88011a44fe78
 Call Trace:
  [817e370d] dump_stack+0x4c/0x65
  [810d6847] lockdep_rcu_suspicious+0xe7/0x120
  [810b71a5] idle_task_exit+0x205/0x2c0
  [81054c4e] play_dead_common+0xe/0x50
  [81054ca5] native_play_dead+0x15/0x140
  [8102963f] arch_cpu_idle_dead+0xf/0x20
  [810cd89e] cpu_startup_entry+0x37e/0x580
  [81053e20] start_secondary+0x140/0x150
 intel_pstate CPU 2 exiting

...

By converting the tlb_flush tracepoint to a TRACE_EVENT_CONDITION where the
condition is cpu_online(smp_processor_id()), we can avoid calling RCU protected
code when the CPU is offline.

Link: 
http://lkml.kernel.org/r/CA+icZUUGiGDoL5NU8RuxKzFjoLjEKRtUWx=jb8b9a0eqv-e...@mail.gmail.com

Reported-by: Sedat Dilek sedat.di...@gmail.com
Suggested-by: Paul E. McKenney paul...@linux.vnet.ibm.com
Signed-off-by: Steven Rostedt rost...@goodmis.org
---
 include/trace/events/tlb.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/trace/events/tlb.h b/include/trace/events/tlb.h
index 13391d288107..0e7635765153 100644
--- a/include/trace/events/tlb.h
+++ b/include/trace/events/tlb.h
@@ -13,11 +13,13 @@
{ TLB_LOCAL_SHOOTDOWN,  local shootdown },\
{ TLB_LOCAL_MM_SHOOTDOWN,   local mm shootdown }
 
-TRACE_EVENT(tlb_flush,
+TRACE_EVENT_CONDITION(tlb_flush,
 
TP_PROTO(int reason, unsigned long pages),
TP_ARGS(reason, pages),
 
+   TP_CONDITION(cpu_online(smp_processor_id())),
+
TP_STRUCT__entry(
__field(  int, reason)
__field(unsigned long,  pages)
-- 
2.1.4


--
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 2/2] KVM: x86: optimize delivery of TSC deadline timer interrupt

2015-02-06 Thread Marcelo Tosatti

On Fri, Feb 06, 2015 at 01:16:59PM +0100, Paolo Bonzini wrote:
 The newly-added tracepoint shows the following results on
 the tscdeadline_latency test:
 
 qemu-kvm-8387  [002]  6425.558974: kvm_vcpu_wakeup:  poll time 
 10407 ns
 qemu-kvm-8387  [002]  6425.558984: kvm_vcpu_wakeup:  poll time 0 
 ns
 qemu-kvm-8387  [002]  6425.561242: kvm_vcpu_wakeup:  poll time 
 10477 ns
 qemu-kvm-8387  [002]  6425.561251: kvm_vcpu_wakeup:  poll time 0 
 ns
 
 and so on.  This is because we need to go through kvm_vcpu_block again
 after the timer IRQ is injected.  Avoid it by polling once before
 entering kvm_vcpu_block.
 
 On my machine (Xeon E5 Sandy Bridge) this removes about 500 cycles (7%)
 from the latency of the TSC deadline timer.
 
 Signed-off-by: Paolo Bonzini pbonz...@redhat.com
 ---
  arch/x86/kvm/x86.c | 14 +-
  1 file changed, 9 insertions(+), 5 deletions(-)
 
 diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
 index 0b8dd13676ef..1e766033ebff 100644
 --- a/arch/x86/kvm/x86.c
 +++ b/arch/x86/kvm/x86.c
 @@ -6389,11 +6389,15 @@ static inline int __vcpu_run(struct kvm *kvm, struct 
 kvm_vcpu *vcpu)
   !vcpu-arch.apf.halted)
   return vcpu_enter_guest(vcpu);
  
 - srcu_read_unlock(kvm-srcu, vcpu-srcu_idx);
 - kvm_vcpu_block(vcpu);
 - vcpu-srcu_idx = srcu_read_lock(kvm-srcu);
 - if (!kvm_check_request(KVM_REQ_UNHALT, vcpu))
 - return 1;
 + if (kvm_arch_vcpu_runnable(vcpu))
 + clear_bit(KVM_REQ_UNHALT, vcpu-requests);
 + else {

Why the clear_bit? Since only kvm_vcpu_block in the below section
sets it, and that section clears it as well.

Can remove another 300 cycles from do_div when programming LAPIC
tscdeadline timer.

 + srcu_read_unlock(kvm-srcu, vcpu-srcu_idx);
 + kvm_vcpu_block(vcpu);
 + vcpu-srcu_idx = srcu_read_lock(kvm-srcu);
 + if (!kvm_check_request(KVM_REQ_UNHALT, vcpu))
 + return 1;
 + }
  
   kvm_apic_accept_events(vcpu);
   switch(vcpu-arch.mp_state) {
 -- 
 1.8.3.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 1/1] drivers/base: Remove unnecessary OOM message

2015-02-06 Thread Pavel Machek

On Fri 2015-02-06 16:39:12, Quentin Lambert wrote:
 This patch fix checkpatch warnings concerning the possible
 duplication of an out of memory message.

So, instead of nice and readable not enough memory for clock... we
get OOM, stackdump, and backtrace...? Not sure it is improvement.

Pavel

 --- a/drivers/base/power/clock_ops.c
 +++ b/drivers/base/power/clock_ops.c
 @@ -81,10 +81,8 @@ static int __pm_clk_add(struct device *dev, const char 
 *con_id,
   return -EINVAL;
  
   ce = kzalloc(sizeof(*ce), GFP_KERNEL);
 - if (!ce) {
 - dev_err(dev, Not enough memory for clock entry.\n);
 + if (!ce)
   return -ENOMEM;
 - }
  
   if (con_id) {
   ce-con_id = kstrdup(con_id, GFP_KERNEL);
 diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
 index 15bf299..677fb28 100644
 --- a/drivers/base/power/opp.c
 +++ b/drivers/base/power/opp.c
 @@ -474,10 +474,8 @@ static int _opp_add_dynamic(struct device *dev, unsigned 
 long freq,
  
   /* allocate new OPP node */
   new_opp = kzalloc(sizeof(*new_opp), GFP_KERNEL);
 - if (!new_opp) {
 - dev_warn(dev, %s: Unable to create new OPP node\n, __func__);
 + if (!new_opp)
   return -ENOMEM;
 - }
  
   /* Hold our list modification lock here */
   mutex_lock(dev_opp_list_lock);
 @@ -695,10 +693,8 @@ static int _opp_set_availability(struct device *dev, 
 unsigned long freq,
  
   /* keep the node allocated */
   new_opp = kmalloc(sizeof(*new_opp), GFP_KERNEL);
 - if (!new_opp) {
 - dev_warn(dev, %s: Unable to create OPP\n, __func__);
 + if (!new_opp)
   return -ENOMEM;
 - }
  
   mutex_lock(dev_opp_list_lock);
  

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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] tracing/tlb/x85: Fix splat of calling RCU trace code on offline CPU

On Fri, 6 Feb 2015 22:07:56 +0100
Sedat Dilek sedat.di...@gmail.com wrote:

 Your patchset fixes the issue for me (look at the attached files for
 more detailed information).

So I can add your Tested-by tag?

 
 I tested the To Be Loved (TBL VS. TLB flushes) edition against
 Linux-next (next-20150204) where I had originally seen and reported
 the call-trace.
 
 Before I forget... The Fixes-tag misses pointing to Dave Hansen's...
 
 commit d17d8f9dedb9dd76fd540a5c497101529d9eb25a
 x86/mm: Add tracepoints for TLB flushes

Sure, I can add that, and even Cc stable for 3.17+.

 
 My POV is that both patches somehow belong together.
 If you decide to push them through two different trees, please add a
 note/reference to each other.

The second patch should reference the first one.

But the first patch is a much broader change and more generic which
could affect many other locations as well. It is specific to
tracepoints, where the tlb one is specific to a single instance. As the
first patch affects all tracepoints, I want it in my tree.


-- Steve
--
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: [BUG] Kernel Panic in squashfs

2015-02-06 Thread Tim Tassonis


On Fri, Feb 6, 2015 at 5:55 PM, Tim Tassonis st...@decentral.ch wrote:

Hi all


Just found out that squashfs panics when compiled in statically instead of
as a module, when mounting an sqf file. The sequence I did was:


# mkdir /mnt/gaia-ro

# mount /gaiarule.sqf  /mnt/gaia-ro -t squashfs -o loop

Maybe it is of importance that the sqf file is located in the initramfs. The
kernel was panicking reliably with different sqf files, on different
hardware upon the mount command, with unable to handle kernel paging
request. This was on 3.18.5. As soon as I compiled squashfs as a modules,
the problem went away.

If you need further details, please cc me directly, as I unsubscribed from
the list due to not being able to handle the massive load.


What about sharing the actual kernel panic? :-)


Well, I will, if somebody bothers to actually look at it. Takes me some 
time to set everything up again for it. And it would be nice if you 
could cc me directly in the reply, as already mentioned, I'm not on the 
list and this copy-paste stuff from marc.info is a bit a nuisance.


Bye
Tim



--
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] x86 spinlock: Fix memory corruption on completing completions

2015-02-06 Thread Sasha Levin

On 02/06/2015 09:49 AM, Raghavendra K T wrote:
 Paravirt spinlock clears slowpath flag after doing unlock.
 As explained by Linus currently it does:
 prev = *lock;
 add_smp(lock-tickets.head, TICKET_LOCK_INC);
 
 /* add_smp() is a full mb() */
 
 if (unlikely(lock-tickets.tail  TICKET_SLOWPATH_FLAG))
 __ticket_unlock_slowpath(lock, prev);
 
 
 which is *exactly* the kind of things you cannot do with spinlocks,
 because after you've done the add_smp() and released the spinlock
 for the fast-path, you can't access the spinlock any more.  Exactly
 because a fast-path lock might come in, and release the whole data
 structure.
 
 Linus suggested that we should not do any writes to lock after unlock(),
 and we can move slowpath clearing to fastpath lock.
 
 However it brings additional case to be handled, viz., slowpath still
 could be set when somebody does arch_trylock. Handle that too by ignoring
 slowpath flag during lock availability check.
 
 Reported-by: Sasha Levin sasha.le...@oracle.com
 Suggested-by: Linus Torvalds torva...@linux-foundation.org
 Signed-off-by: Raghavendra K T raghavendra...@linux.vnet.ibm.com

With this patch, my VMs lock up quickly after boot with:

[  161.613469] BUG: spinlock lockup suspected on CPU#31, kworker/31:1/5213
[  161.613469]  lock: purge_lock.28981+0x0/0x40, .magic: dead4ead, .owner: 
kworker/7:1/6400, .owner_cpu: 7
[  161.613469] CPU: 31 PID: 5213 Comm: kworker/31:1 Not tainted 
3.19.0-rc7-next-20150204-sasha-00048-gee3a350 #1869
[  161.613469] Workqueue: events bpf_prog_free_deferred
[  161.613469]   f03dd27f 88056b227a88 
a1702276
[  161.613469]   88017cf7 88056b227aa8 
9e1d009c
[  161.613469]  a3edae60 86c3f830 88056b227ad8 
9e1d01d7
[  161.613469] Call Trace:
[  161.613469] dump_stack (lib/dump_stack.c:52)
[  161.613469] spin_dump (kernel/locking/spinlock_debug.c:68 (discriminator 8))
[  161.613469] do_raw_spin_lock (include/linux/nmi.h:48 
kernel/locking/spinlock_debug.c:119 kernel/locking/spinlock_debug.c:137)
[  161.613469] _raw_spin_lock (kernel/locking/spinlock.c:152)
[  161.613469] ? __purge_vmap_area_lazy (mm/vmalloc.c:615)
[  161.613469] __purge_vmap_area_lazy (mm/vmalloc.c:615)
[  161.613469] ? vm_unmap_aliases (mm/vmalloc.c:1021)
[  161.613469] vm_unmap_aliases (mm/vmalloc.c:1052)
[  161.613469] ? vm_unmap_aliases (mm/vmalloc.c:1021)
[  161.613469] ? __lock_acquire (kernel/locking/lockdep.c:2019 
kernel/locking/lockdep.c:3184)
[  161.613469] change_page_attr_set_clr (arch/x86/mm/pageattr.c:1394)
[  161.613469] ? debug_object_deactivate (lib/debugobjects.c:463)
[  161.613469] set_memory_rw (arch/x86/mm/pageattr.c:1662)
[  161.613469] ? __lock_is_held (kernel/locking/lockdep.c:3518)
[  161.613469] bpf_jit_free (include/linux/filter.h:377 
arch/x86/net/bpf_jit_comp.c:991)
[  161.613469] bpf_prog_free_deferred (kernel/bpf/core.c:646)
[  161.613469] process_one_work (kernel/workqueue.c:2014 
include/linux/jump_label.h:114 include/trace/events/workqueue.h:111 
kernel/workqueue.c:2019)
[  161.613469] ? process_one_work (./arch/x86/include/asm/atomic64_64.h:33 
include/asm-generic/atomic-long.h:38 kernel/workqueue.c:598 
kernel/workqueue.c:625 kernel/workqueue.c:2007)
[  161.613469] worker_thread (include/linux/list.h:189 kernel/workqueue.c:2147)
[  161.613469] ? process_one_work (kernel/workqueue.c:2091)
[  161.613469] kthread (kernel/kthread.c:207)
[  161.613469] ? finish_task_switch (./arch/x86/include/asm/current.h:14 
kernel/sched/sched.h:1058 kernel/sched/core.c:2258)
[  161.613469] ? flush_kthread_work (kernel/kthread.c:176)
[  161.613469] ret_from_fork (arch/x86/kernel/entry_64.S:283)
[  161.613469] ? flush_kthread_work (kernel/kthread.c:176)

And a few soft lockup messages inside the scheduler after that.


Thanks,
Sasha


--
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: [PATCHv6 5/5] arm: dts: Add Altera L2 Cache and OCRAM EDAC entries

2015-02-06 Thread Mark Rutland

On Fri, Jan 09, 2015 at 02:53:56AM +, ttha...@opensource.altera.com wrote:
 From: Thor Thayer ttha...@opensource.altera.com
 
 Adding the device tree entries and bindings needed to support
 the Altera L2 cache and On-Chip RAM EDAC. This patch relies upon
 an earlier patch to declare and setup On-chip RAM properly.
 http://www.spinics.net/lists/devicetree/msg51117.html
 
 Signed-off-by: Thor Thayer ttha...@opensource.altera.com
 ---
 v2: Remove OCRAM declaration and reference prior patch.
 
 v3-5: No Change
 
 v6: Change to nested EDAC device nodes based on community
 feedback. Remove L2 syscon. Use consolidated binding.
 ---
  .../bindings/arm/altera/socfpga-edac.txt   |   46 
 
  arch/arm/boot/dts/socfpga.dtsi |   20 +
  2 files changed, 66 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/arm/altera/socfpga-edac.txt
 
 diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-edac.txt 
 b/Documentation/devicetree/bindings/arm/altera/socfpga-edac.txt
 new file mode 100644
 index 000..4bf32e1
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/arm/altera/socfpga-edac.txt
 @@ -0,0 +1,46 @@
 +Altera SoCFPGA Error Detection and Correction [EDAC]
 +
 +Required Properties:
 +- compatible : Should be altr,edac

Is there a single large EDAC block that happens to perform EDAC
functions for various components, or various small EDAC blocks that
happen to be close to each other in the MMIO space?

 +- #address-cells: must be 1
 +- #size-cells: must be 1
 +- ranges : standard definition, should translate from local addresses

Surely these just need to be suitable for mapping the child nodes, and
you shouldn't care about their precise values?

 +
 +Subcomponents:
 +
 +L2 Cache ECC
 +Required Properties:
 +- compatible : Should be altr,l2-edac
 +- reg : Address and size for ECC error interrupt clear registers.
 +- interrupts : Should be single bit error interrupt, then double bit error
 + interrupt. Note the rising edge type.
 +
 +On Chip RAM ECC
 +Required Properties:
 +- compatible : Should be altr,ocram-edac
 +- reg : Address and size for ECC error interrupt clear registers.
 +- iram : phandle to On-Chip RAM definition.
 +- interrupts : Should be single bit error interrupt, then double bit error
 + interrupt. Note the rising edge type.

Do these actually differ in programming interface, or just w.r.t. the
component they are used to monitor?

It would be good to have an explicit link to what they monitor rather
than relying on there being single instances with particular compatible
strings. That will make this easier to generalise for multiple instances
in future SoCs that may reuse the EDAC block.

This doesn't look too bad, but I'd like to hear some response to this
and my other queries before I can say whether this is a good way of
describing the hardware; it all looks a bit vague.

As an aside, please place the documentation at the start of the series,
before the driver rework. The dts patches can come after the docs and
code patches.

Thanks,
Mark.

 +
 +Example:
 +
 + soc_ecc {
 + compatible = altr,edac;
 + #address-cells = 1;
 + #size-cells = 1;
 + ranges;
 +
 + l2edac@ffd08140 {
 + compatible = altr,l2-edac;
 + reg = 0xffd08140 0x4;
 + interrupts = 0 36 1, 0 37 1;
 + };
 +
 + ocramedac@ffd08144 {
 + compatible = altr,ocram-edac;
 + reg = 0xffd08144 0x4;
 + iram = ocram;
 + interrupts = 0 178 1, 0 179 1;
 + };
 + };
 diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
 index 252c3d1..e546e47 100644
 --- a/arch/arm/boot/dts/socfpga.dtsi
 +++ b/arch/arm/boot/dts/socfpga.dtsi
 @@ -618,6 +618,26 @@
   interrupts = 0 39 4;
   };
  
 + soc_ecc {
 + compatible = altr,edac;
 + #address-cells = 1;
 + #size-cells = 1;
 + ranges;
 +
 + l2edac@ffd08140 {
 + compatible = altr,l2-edac;
 + reg = 0xffd08140 0x4;
 + interrupts = 0 36 1, 0 37 1;
 + };
 +
 + ocramedac@ffd08144 {
 + compatible = altr,ocram-edac;
 + reg = 0xffd08144 0x4;
 + iram = ocram;
 + interrupts = 0 178 1, 0 179 1;
 + };
 + };
 +
   L2: l2-cache@fffef000 {
   compatible = arm,pl310-cache;
   reg = 0xfffef000 0x1000;
 -- 
 1.7.9.5
 
 --
 To unsubscribe from this list: send the line unsubscribe devicetree in
 the body of a message to

Re: [PATCH 1/2] kernel/fork: handle put_user errors for CLONE_CHILD_SETTID/CLEARTID

2015-02-06 Thread Oleg Nesterov

On 02/06, Konstantin Khlebnikov wrote:

 Whole sequence looks like: task calls fork, glibc calls syscall clone with
 CLONE_CHILD_SETTID and passes pointer to TLS THREAD_SELF-tid as argument.
 Child task gets read-only copy of VM including TLS. Child calls put_user()
 to handle CLONE_CHILD_SETTID from schedule_tail(). put_user() trigger page
 fault and it fails because do_wp_page()  hits memcg limit without invoking
 OOM-killer because this is page-fault from kernel-space.

Because of !FAULT_FLAG_USER?

Perhaps we should fix this? Say mem_cgroup_oom_enable/disable around put_user(),
I dunno.

 Put_user returns
 -EFAULT, which is ignored.  Child returns into user-space and catches here
 assert (THREAD_GETMEM (self, tid) != ppid),

If only I understood why else we need CLONE_CHILD_SETTID ;)

 --- a/kernel/sched/core.c
 +++ b/kernel/sched/core.c
 @@ -2312,8 +2312,20 @@ asmlinkage __visible void schedule_tail(struct 
 task_struct *prev)
   post_schedule(rq);
   preempt_enable();
  
 - if (current-set_child_tid)
 - put_user(task_pid_vnr(current), current-set_child_tid);
 + if (current-set_child_tid 
 + unlikely(put_user(task_pid_vnr(current), current-set_child_tid))) {
 + int dummy;
 +
 + /*
 +  * If this address is unreadable then userspace has not set
 +  * proper pointer. Application either doesn't care or will
 +  * notice this soon. If this address is readable then task
 +  * will be mislead about its own tid. It's better to die.
 +  */
 + if (!get_user(dummy, current-set_child_tid) 
 + !fatal_signal_pending(current))
 + force_sig(SIGSEGV, current);
 + }

Well, get_user() can fail the same way? The page we need to cow can be
swapped out.

At first glance, to me this problem should be solved somewhere else...
I'll try to reread this all tomorrow.

Oleg.

--
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 v5 3/5] x86: Split syscall_trace_enter into two phases

2015-02-06 Thread Kees Cook

On Fri, Feb 6, 2015 at 11:32 AM, Andy Lutomirski l...@amacapital.net wrote:
On Fri, Feb 6, 2015 at 11:23 AM, Kees Cook keesc...@chromium.org wrote:
On Thu, Feb 5, 2015 at 6:38 PM, Andy Lutomirski l...@amacapital.net wrote:
On Thu, Feb 5, 2015 at 6:32 PM, Dmitry V. Levin l...@altlinux.org wrote:
On Thu, Feb 05, 2015 at 04:09:06PM -0800, Andy Lutomirski wrote:
On Thu, Feb 5, 2015 at 3:49 PM, Kees Cook keesc...@chromium.org wrote:
On Thu, Feb 5, 2015 at 3:39 PM, Dmitry V. Levin l...@altlinux.org
wrote:
[...]
There is a clear difference: before these changes, SECCOMP_RET_ERRNO
used
to keep the syscall number unchanged and suppress syscall-exit-stop
event,
which was awful because userspace cannot distinguish syscall-enter-stop
from syscall-exit-stop and therefore relies on the kernel that
syscall-enter-stop is followed by syscall-exit-stop (or tracee's
death, etc.).

After these changes, SECCOMP_RET_ERRNO no longer causes
syscall-exit-stop
events to be suppressed, but now the syscall number is lost.

Ah-ha! Okay, thanks, I understand now. I think this means seccomp
phase1 should not treat RET_ERRNO as a skip event. Andy, what do you
think here?

I still don't quite see how this change caused this.

I have a test for this at
http://sourceforge.net/p/strace/code/ci/HEAD/~/tree/test/seccomp.c

I can play with
it a bit more. But RET_ERRNO *has* to be some kind of skip event,
because it needs to skip the syscall.

We could change this by treating RET_ERRNO as an instruction to enter
phase 2 and then asking for a skip in phase 2 without changing
orig_ax, but IMO this is pretty ugly.

I think this all kind of sucks. We're trying to run ptrace after
seccomp, so ptrace is seeing the syscalls as transformed by seccomp.
That means that if we use RET_TRAP, then ptrace will see the
possibly-modified syscall, if we use RET_ERRNO, then ptrace is (IMO
correctly given the current design) showing syscall -1, and if we use
RET_KILL, then ptrace just sees the process mysteriously die.

Userspace is usually not prepared to see syscall -1.
For example, strace had to be patched, otherwise it just skipped such
syscalls as not a syscall events or did other improper things:
http://sourceforge.net/p/strace/code/ci/c3948327717c29b10b5e00a436dc138b4ab1a486
http://sourceforge.net/p/strace/code/ci/8e398b6c4020fb2d33a5b3e40271ebf63199b891

The x32 thing is a legit ABI bug, I'd argue. I'd be happy to submit a
patch to fix that (clear the x32 bit if we're not x32).

A slightly different but related story: userspace is also not prepared
to handle large errno values produced by seccomp filters like this:
BPF_STMT(BPF_RET, SECCOMP_RET_ERRNO | SECCOMP_RET_DATA)

For example, glibc assumes that syscalls do not return errno values
greater than 0xfff:
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/x86_64/sysdep.h#l55
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/x86_64/syscall.S#l20

To save others the link reading: Linus said he will make sure the no
syscall returns a value in -1 .. -4095 as a valid result so we can
savely test with -4095.

Strictly speaking (ISO C, man 3 errno), errno is supposed to be a
full int, though digging around I find this in include/linux/err.h:

/*
* Kernel pointers have redundant information, so we can use a
* scheme where we can return either an error code or a normal
* pointer with the same return value.
*
* This should be a per-architecture thing, to allow different
* error and pointer decisions.
*/
#define MAX_ERRNO 4095

#ifndef __ASSEMBLY__

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

But no architecture overrides this.

If it isn't too late, I'd recommend changing SECCOMP_RET_DATA mask
applied in SECCOMP_RET_ERRNO case from current 0x to 0xfff.

I'm not opposed to this. I would want to more explicitly document the
4095 max value in man pages, though.

I think this is solidly in the don't do that category. Seccomp lets
you tamper with syscalls. If you tamper wrong, then you lose.

Kees, what do you think about reversing the whole thing so that
ptracers always see the original syscall?

What do you mean by reversing? The interactions I see here are:

PTRACE_SYSCALL
SECCOMP_RET_ERRNO
SECCOMP_RET_TRACE
SECCOMP_RET_TRAP

Both ptrace and seccomp will trigger via _TIF_WORK_SYSCALL_ENTRY. Only
ptrace will trigger via _TIF_WORK_SYSCALL_EXIT.

For SECCOMP_RET_ERRNO to work, we must skip the syscall, as mentioned
earlier:

arch/x86/kernel/entry_32.S ...
syscall_trace_entry:
movl $-ENOSYS,PT_EAX(%esp)
movl %esp, %eax
call syscall_trace_enter
/* What it returned is what we'll actually use. */
cmpl $(NR_syscalls), %eax
jnae syscall_call
jmp syscall_exit
END(syscall_trace_entry)

Both before and after the 2-phase change, syscall_trace_enter would
return -1

[PATCH v2 1/7] Input: synaptics - fix middle button on Lenovo 2015 products

2015-02-06 Thread Benjamin Tissoires

From: Dmitry Torokhov dmitry.torok...@gmail.com

On the X1 Carbon 3rd gen (with a 2015 broadwell cpu), the physical middle
button of the trackstick (attached to the touchpad serio device, of course)
seems to get lost.

Actually, the touchpads reports 3 extra buttons, which falls in the switch
below to the '2' case. Let's handle the case of odd numbers also, so that
the middle button finds its way back.

Cc: sta...@vger.kernel.org
Signed-off-by: Benjamin Tissoires benjamin.tissoi...@redhat.com
---

v2:
- used Dmitry's version
- fixed typo in synaptics_parse_ext_buttons() (buf[4] - buf[5])

 drivers/input/mouse/synaptics.c | 44 -
 1 file changed, 21 insertions(+), 23 deletions(-)

diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index 6506d22..3bd7032 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -653,6 +653,18 @@ static void synaptics_parse_agm(const unsigned char buf[],
}
 }
 
+static void synaptics_parse_ext_buttons(const unsigned char buf[],
+   struct synaptics_data *priv,
+   struct synaptics_hw_state *hw)
+{
+   unsigned int ext_bits =
+   (SYN_CAP_MULTI_BUTTON_NO(priv-ext_cap) + 1)  1;
+   unsigned int ext_mask = GENMASK(ext_bits - 1, 0);
+
+   hw-ext_buttons = buf[4]  ext_mask;
+   hw-ext_buttons |= (buf[5]  ext_mask)  ext_bits;
+}
+
 static bool is_forcepad;
 
 static int synaptics_parse_hw_state(const unsigned char buf[],
@@ -739,28 +751,9 @@ static int synaptics_parse_hw_state(const unsigned char 
buf[],
hw-down = ((buf[0] ^ buf[3])  0x02) ? 1 : 0;
}
 
-   if (SYN_CAP_MULTI_BUTTON_NO(priv-ext_cap) 
+   if (SYN_CAP_MULTI_BUTTON_NO(priv-ext_cap)  0 
((buf[0] ^ buf[3])  0x02)) {
-   switch (SYN_CAP_MULTI_BUTTON_NO(priv-ext_cap)  ~0x01) 
{
-   default:
-   /*
-* if nExtBtn is greater than 8 it should be
-* considered invalid and treated as 0
-*/
-   break;
-   case 8:
-   hw-ext_buttons |= ((buf[5]  0x08)) ? 0x80 : 0;
-   hw-ext_buttons |= ((buf[4]  0x08)) ? 0x40 : 0;
-   case 6:
-   hw-ext_buttons |= ((buf[5]  0x04)) ? 0x20 : 0;
-   hw-ext_buttons |= ((buf[4]  0x04)) ? 0x10 : 0;
-   case 4:
-   hw-ext_buttons |= ((buf[5]  0x02)) ? 0x08 : 0;
-   hw-ext_buttons |= ((buf[4]  0x02)) ? 0x04 : 0;
-   case 2:
-   hw-ext_buttons |= ((buf[5]  0x01)) ? 0x02 : 0;
-   hw-ext_buttons |= ((buf[4]  0x01)) ? 0x01 : 0;
-   }
+   synaptics_parse_ext_buttons(buf, priv, hw);
}
} else {
hw-x = (((buf[1]  0x1f)  8) | buf[2]);
@@ -827,6 +820,7 @@ static void synaptics_report_buttons(struct psmouse 
*psmouse,
 {
struct input_dev *dev = psmouse-dev;
struct synaptics_data *priv = psmouse-private;
+   int ext_bits = (SYN_CAP_MULTI_BUTTON_NO(priv-ext_cap) + 1)  1;
int i;
 
input_report_key(dev, BTN_LEFT, hw-left);
@@ -840,8 +834,12 @@ static void synaptics_report_buttons(struct psmouse 
*psmouse,
input_report_key(dev, BTN_BACK, hw-down);
}
 
-   for (i = 0; i  SYN_CAP_MULTI_BUTTON_NO(priv-ext_cap); i++)
-   input_report_key(dev, BTN_0 + i, hw-ext_buttons  (1  i));
+   for (i = 0; i  ext_bits; i++) {
+   input_report_key(dev, BTN_0 + 2 * i,
+hw-ext_buttons  (1  i));
+   input_report_key(dev, BTN_1 + 2 * i,
+hw-ext_buttons  (1  (i + ext_bits)));
+   }
 }
 
 static void synaptics_report_mt_data(struct psmouse *psmouse,
-- 
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] spi: sc18is602: Support multiple devices on a single I2C bus if DT is configured

2015-02-06 Thread Guenter Roeck

The driver currently only supports a single device per I2C bus since it uses
the I2C bus number to set the SPI bus number. This makes it impossible to
connect more than one chip to a single I2C bus.

We don't want to use dynamic bus numbers unconditionally since this would
result in every instantiation getting a different bus number starting with
65,535 counting down unless devicetree is configured. If devicetree is
configured, however, the SPI bus number is obtained from devicetree
data. So we can use dynamic SPI bus numbers in this case.

Reported-and-Tested-by: Marco Menchise marco.mench...@gmail.com
Signed-off-by: Guenter Roeck li...@roeck-us.net
---
 drivers/spi/spi-sc18is602.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-sc18is602.c b/drivers/spi/spi-sc18is602.c
index 237f2e7..c04e601 100644
--- a/drivers/spi/spi-sc18is602.c
+++ b/drivers/spi/spi-sc18is602.c
@@ -290,7 +290,7 @@ static int sc18is602_probe(struct i2c_client *client,
hw-freq = SC18IS602_CLOCK;
break;
}
-   master-bus_num = client-adapter-nr;
+   master-bus_num = np ? -1 : client-adapter-nr;
master-mode_bits = SPI_CPHA | SPI_CPOL | SPI_LSB_FIRST;
master-bits_per_word_mask = SPI_BPW_MASK(8);
master-setup = sc18is602_setup;
-- 
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 2/2] x86/tbl/trace: Do not trace on CPU that is offline

On Fri, 6 Feb 2015 21:23:13 +0100
Sedat Dilek sedat.di...@gmail.com wrote:

 On Fri, Feb 6, 2015 at 9:21 PM, Steven Rostedt rost...@goodmis.org wrote:
  On Fri, 6 Feb 2015 21:11:57 +0100
  Sedat Dilek sedat.di...@gmail.com wrote:
 
  On Fri, Feb 6, 2015 at 9:06 PM, Steven Rostedt rost...@goodmis.org wrote:
   From: Steven Rostedt (Red Hat) rost...@goodmis.org
  
 
  Subject: x86/tbl/trace: --- .../tlb/...
 
 
  But I wanted To Be Loved.
 
 
 Sorry, the patch is not applicable :-)

How about, I wanted x86 to be loved by trace? Or vice versa.

Applicable then?

-- Steve
--
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] ARM: print cma-reserved pages from show_mem

2015-02-06 Thread Gregory Fong

On Thu, Feb 5, 2015 at 4:41 PM, Laura Abbott lau...@codeaurora.org wrote:
 On 2/4/2015 3:22 PM, Gregory Fong wrote:

 Add cma reserved information to the ARM-specific show_mem.  It was
 added to the generic implementation by commit
 49abd8c28046adf77c5ce1949549aa64d7221881 lib/show_mem.c: add cma
 reserved information.

 Signed-off-by: Gregory Fong gregory.0...@gmail.com
 ---
   arch/arm/mm/init.c | 4 
   1 file changed, 4 insertions(+)

 diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
 index 2495c8c..da77507 100644
 --- a/arch/arm/mm/init.c
 +++ b/arch/arm/mm/init.c
 @@ -22,6 +22,7 @@
   #include linux/memblock.h
   #include linux/dma-contiguous.h
   #include linux/sizes.h
 +#include linux/cma.h

   #include asm/cp15.h
   #include asm/mach-types.h
 @@ -130,6 +131,9 @@ void show_mem(unsigned int filter)
 printk(%d pages of RAM\n, total);
 printk(%d free pages\n, free);
 printk(%d reserved pages\n, reserved);
 +#ifdef CONFIG_CMA
 +   printk(%lu cma reserved pages\n, totalcma_pages);
 +#endif


 Nit: 'cma reserved pages' is a bit unclear. Are there some CMA
 pages that aren't reserved? Dropping the reserved might be
 clearer.

Sure, I was trying to replicate what's in lib/show_mem.c, but it
doesn't actually make much sense.  Maybe it would be better to change
to cma pages here and change the wording in that lib/show_mem.c too.

I'll wait a bit for any other thoughts and send out a v2 with those changes.

Thanks,
Gregory
--
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 2/2] iser-target: Remove duplicate function names

2015-02-06 Thread Nicholas A. Bellinger

On Fri, 2015-02-06 at 01:09 +0100, Rasmus Villemoes wrote:
 The macro isert_dbg already ensures that __func__ is part of the
 output, so there's no reason to duplicate the function name in the
 format string itself.
 
 Signed-off-by: Rasmus Villemoes li...@rasmusvillemoes.dk
 ---
  drivers/infiniband/ulp/isert/ib_isert.c | 7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/infiniband/ulp/isert/ib_isert.c 
 b/drivers/infiniband/ulp/isert/ib_isert.c
 index dafb3c531f96..20097de9ac45 100644
 --- a/drivers/infiniband/ulp/isert/ib_isert.c
 +++ b/drivers/infiniband/ulp/isert/ib_isert.c
 @@ -949,7 +949,7 @@ isert_post_recv(struct isert_conn *isert_conn, u32 count)
   isert_err(ib_post_recv() failed with ret: %d\n, ret);
   isert_conn-post_recv_buf_count -= count;
   } else {
 - isert_dbg(isert_post_recv(): Posted %d RX buffers\n, count);
 + isert_dbg(Posted %d RX buffers\n, count);
   isert_conn-conn_rx_desc_head = rx_head;
   }
   return ret;
 @@ -1709,8 +1709,7 @@ isert_put_cmd(struct isert_cmd *isert_cmd, bool 
 comp_err)
* associated cmd-se_cmd needs to be released.
*/
   if (cmd-se_cmd.se_tfo != NULL) {
 - isert_dbg(Calling transport_generic_free_cmd from
 -   isert_put_cmd for 0x%02x\n,
 + isert_dbg(Calling transport_generic_free_cmd for 
 0x%02x\n,
cmd-iscsi_opcode);
   transport_generic_free_cmd(cmd-se_cmd, 0);
   break;
 @@ -3136,7 +3135,7 @@ accept_wait:
   spin_lock_bh(np-np_thread_lock);
   if (np-np_thread_state = ISCSI_NP_THREAD_RESET) {
   spin_unlock_bh(np-np_thread_lock);
 - isert_dbg(np_thread_state %d for isert_accept_np\n,
 + isert_dbg(np_thread_state %d\n,
np-np_thread_state);
   /**
* No point in stalling here when np_thread

Applied to target-pending/for-next.

Thanks Rasmus!

--nab

--
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 v2 6/7] trace: constify filter_parse_regex(), match_records(), ftrace_match() and ftrace_match_record()