[PATCH V4 4/4] serial: 8250_pci: Remove Fintek F81504/508/512 UART driver

[Peter Hung]

Remove Fintek F81504/508/512 PCIE-to-UART device driver from 8250_pci.c

Paul recommed us do less code deletion to avoid confusing problem when
bisect.
https://lkml.org/lkml/2016/1/18/646

But this patch is sent after with following patch.
8250: 8250_f81504: Add Fintek F81504/508/512 PCIE-to-UART/GPIO UART support
mfd: f81504-core: Add Fintek F81504/508/512 PCIE-to-UART/GPIO core support

We must remove F81504/508/512 support in 8250_pci.c and migrate to
f81504-core/8250_f81504 to enable MFD support and Andy recommend me to
add these this in blacklist to avoid probed by 8250_pci.c

Suggested-by: Paul Gortmaker 
Suggested-by: Andy Shevchenko 
Signed-off-by: Peter Hung 
---
 drivers/tty/serial/8250/8250_pci.c | 206 +
 1 file changed, 5 insertions(+), 201 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_pci.c 
b/drivers/tty/serial/8250/8250_pci.c
index e71ec78..24a669c 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1532,156 +1532,6 @@ pci_brcm_trumanage_setup(struct serial_private *priv,
return ret;
 }
 
-/* RTS will control by MCR if this bit is 0 */
-#define FINTEK_RTS_CONTROL_BY_HW   BIT(4)
-/* only worked with FINTEK_RTS_CONTROL_BY_HW on */
-#define FINTEK_RTS_INVERT  BIT(5)
-
-/* We should do proper H/W transceiver setting before change to RS485 mode */
-static int pci_fintek_rs485_config(struct uart_port *port,
-  struct serial_rs485 *rs485)
-{
-   u8 setting;
-   u8 *index = (u8 *) port->private_data;
-   struct pci_dev *pci_dev = container_of(port->dev, struct pci_dev,
-   dev);
-
-   pci_read_config_byte(pci_dev, 0x40 + 8 * *index + 7, );
-
-   if (!rs485)
-   rs485 = >rs485;
-   else if (rs485->flags & SER_RS485_ENABLED)
-   memset(rs485->padding, 0, sizeof(rs485->padding));
-   else
-   memset(rs485, 0, sizeof(*rs485));
-
-   /* F81504/508/512 not support RTS delay before or after send */
-   rs485->flags &= SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND;
-
-   if (rs485->flags & SER_RS485_ENABLED) {
-   /* Enable RTS H/W control mode */
-   setting |= FINTEK_RTS_CONTROL_BY_HW;
-
-   if (rs485->flags & SER_RS485_RTS_ON_SEND) {
-   /* RTS driving high on TX */
-   setting &= ~FINTEK_RTS_INVERT;
-   } else {
-   /* RTS driving low on TX */
-   setting |= FINTEK_RTS_INVERT;
-   }
-
-   rs485->delay_rts_after_send = 0;
-   rs485->delay_rts_before_send = 0;
-   } else {
-   /* Disable RTS H/W control mode */
-   setting &= ~(FINTEK_RTS_CONTROL_BY_HW | FINTEK_RTS_INVERT);
-   }
-
-   pci_write_config_byte(pci_dev, 0x40 + 8 * *index + 7, setting);
-
-   if (rs485 != >rs485)
-   port->rs485 = *rs485;
-
-   return 0;
-}
-
-static int pci_fintek_setup(struct serial_private *priv,
-   const struct pciserial_board *board,
-   struct uart_8250_port *port, int idx)
-{
-   struct pci_dev *pdev = priv->dev;
-   u8 *data;
-   u8 config_base;
-   u16 iobase;
-
-   config_base = 0x40 + 0x08 * idx;
-
-   /* Get the io address from configuration space */
-   pci_read_config_word(pdev, config_base + 4, );
-
-   dev_dbg(>dev, "%s: idx=%d iobase=0x%x", __func__, idx, iobase);
-
-   port->port.iotype = UPIO_PORT;
-   port->port.iobase = iobase;
-   port->port.rs485_config = pci_fintek_rs485_config;
-
-   data = devm_kzalloc(>dev, sizeof(u8), GFP_KERNEL);
-   if (!data)
-   return -ENOMEM;
-
-   /* preserve index in PCI configuration space */
-   *data = idx;
-   port->port.private_data = data;
-
-   return 0;
-}
-
-static int pci_fintek_init(struct pci_dev *dev)
-{
-   unsigned long iobase;
-   u32 max_port, i;
-   u32 bar_data[3];
-   u8 config_base;
-   struct serial_private *priv = pci_get_drvdata(dev);
-   struct uart_8250_port *port;
-
-   switch (dev->device) {
-   case 0x1104: /* 4 ports */
-   case 0x1108: /* 8 ports */
-   max_port = dev->device & 0xff;
-   break;
-   case 0x1112: /* 12 ports */
-   max_port = 12;
-   break;
-   default:
-   return -EINVAL;
-   }
-
-   /* Get the io address dispatch from the BIOS */
-   pci_read_config_dword(dev, 0x24, _data[0]);
-   pci_read_config_dword(dev, 0x20, _data[1]);
-   pci_read_config_dword(dev, 0x1c, _data[2]);
-
-   for (i = 0; i < max_port; ++i) {
-   /* UART0 configuration offset start from 0x40 */
-   config_base = 0x40 + 0x08 

[PATCH V4 3/4] 8250: 8250_f81504: Add Fintek F81504/508/512 PCIE-to-UART/GPIO UART support

[Peter Hung]

This driver is 8250 driver for F81504/508/512, it'll handle the serial
port operation of this device. This module will depend on
MFD_FINTEK_F81504_CORE.

The serial ports support from 50bps to 1.5Mbps with Linux baudrate
define excluding 1.0Mbps due to not support 16MHz clock source.

PCI Configuration Space Registers, set:0~11(Max):
40h + 8 * set:
   bit7~6: Clock source selector
   00: 1.8432MHz
   01: 18.432MHz
   10: 24MHz
   11: 14.769MHz
   bit0: UART enable
41h + 8 * set:
   bit5~4: RX trigger multiple
   00: 1x * trigger level
   01: 2x * trigger level
   10: 4x * trigger level
   11: 8x * trigger level
   bit1~0: FIFO Size
   11: 128Bytes
44h + 8 * set: UART IO address (LSB)
45h + 8 * set: UART IO address (MSB)
47h + 8 * set:
   bit5: RTS invert (bit4 must enable)
   bit4: RTS auto direction enable
 0: RTS control by MCR
 1: RTS driven high when TX, otherwise low

Suggested-by: One Thousand Gnomes 
Suggested-by: Andy Shevchenko 
Signed-off-by: Peter Hung 
---
 drivers/tty/serial/8250/8250_f81504.c | 250 ++
 drivers/tty/serial/8250/Kconfig   |  10 ++
 drivers/tty/serial/8250/Makefile  |   1 +
 3 files changed, 261 insertions(+)
 create mode 100644 drivers/tty/serial/8250/8250_f81504.c

diff --git a/drivers/tty/serial/8250/8250_f81504.c 
b/drivers/tty/serial/8250/8250_f81504.c
new file mode 100644
index 000..2b6c3d3
--- /dev/null
+++ b/drivers/tty/serial/8250/8250_f81504.c
@@ -0,0 +1,250 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "8250.h"
+
+static u32 baudrate_table[] = { 150, 1152000, 921600 };
+static u8 clock_table[] = { F81504_CLKSEL_24_MHZ, F81504_CLKSEL_18_46_MHZ,
+   F81504_CLKSEL_14_77_MHZ };
+
+/* We should do proper H/W transceiver setting before change to RS485 mode */
+static int f81504_rs485_config(struct uart_port *port,
+  struct serial_rs485 *rs485)
+{
+   u8 setting;
+   u8 *index = port->private_data;
+   struct platform_device *pdev = container_of(port->dev,
+   struct platform_device, dev);
+   struct pci_dev *pci_dev = to_pci_dev(pdev->dev.parent);
+
+   pci_read_config_byte(pci_dev, F81504_UART_START_ADDR +
+   F81504_UART_OFFSET * *index + F81504_UART_MODE_OFFSET,
+   );
+
+   if (!rs485)
+   rs485 = >rs485;
+   else if (rs485->flags & SER_RS485_ENABLED)
+   memset(rs485->padding, 0, sizeof(rs485->padding));
+   else
+   memset(rs485, 0, sizeof(*rs485));
+
+   /* F81504/508/512 not support RTS delay before or after send */
+   rs485->flags &= SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND;
+
+   if (rs485->flags & SER_RS485_ENABLED) {
+   /* Enable RTS H/W control mode */
+   setting |= F81504_RTS_CONTROL_BY_HW;
+
+   if (rs485->flags & SER_RS485_RTS_ON_SEND) {
+   /* RTS driving high on TX */
+   setting &= ~F81504_RTS_INVERT;
+   } else {
+   /* RTS driving low on TX */
+   setting |= F81504_RTS_INVERT;
+   }
+
+   rs485->delay_rts_after_send = 0;
+   rs485->delay_rts_before_send = 0;
+   } else {
+   /* Disable RTS H/W control mode */
+   setting &= ~(F81504_RTS_CONTROL_BY_HW | F81504_RTS_INVERT);
+   }
+
+   pci_write_config_byte(pci_dev, F81504_UART_START_ADDR +
+   F81504_UART_OFFSET * *index + F81504_UART_MODE_OFFSET,
+   setting);
+
+   if (rs485 != >rs485)
+   port->rs485 = *rs485;
+
+   return 0;
+}
+
+static int f81504_check_baudrate(u32 baud, size_t *idx)
+{
+   size_t index;
+
+   for (index = 0; index < ARRAY_SIZE(baudrate_table); ++index) {
+   /* Clock source must larger than desire baud rate */
+   if (baud > baudrate_table[index])
+   continue;
+
+   /* Find divisible clock source */
+   if (!(baudrate_table[index] % baud)) {
+   if (idx)
+   *idx = index;
+   return 0;
+   }
+   }
+
+   return -EINVAL;
+}
+
+static void f81504_set_termios(struct uart_port *port,
+   struct ktermios *termios, struct ktermios *old)
+{
+   struct platform_device *pdev = container_of(port->dev,
+   struct platform_device, dev);
+   struct pci_dev *dev = to_pci_dev(pdev->dev.parent);
+   

[PATCH V4 2/4] gpio: gpio-f81504: Add Fintek F81504/508/512 PCIE-to-UART/GPIO GPIOLIB support

[Peter Hung]

This driver is GPIOLIB driver for F81504/508/512, it'll handle the
GPIOLIB operation of this device. This module will depend on
MFD_FINTEK_F81504_CORE.

IC function list:
F81504: Max 2x8 GPIOs and max 4 serial ports
port2/3 are multi-function
F81508: Max 6x8 GPIOs and max 8 serial ports
port2/3 are multi-function, port8/9/10/11 are gpio only
F81512: Max 6x8 GPIOs and max 12 serial ports
port2/3/8/9/10/11 are multi-function

GPIO register:
PCI Configuration space:
F0h: bit0~5: Enable GPIO0~5
 bit6~7: Reserve
F3h: bit0~5: Multi-Functional Flag (0:GPIO/1:UART)
 bit0: UART2 pin out for UART2 / GPIO0
 bit1: UART3 pin out for UART3 / GPIO1
 bit2: UART8 pin out for UART8 / GPIO2
 bit3: UART9 pin out for UART9 / GPIO3
 bit4: UART10 pin out for UART10 / GPIO4
 bit5: UART11 pin out for UART11 / GPIO5
 bit6~7: Reserve
F1h: IO address (LSB)
F2h: IO address (MSB)
F8h + 8 * set: Direction control (bitwise)
 bitx: 0 - Input mode
 bitx: 1 - Output mode
F9h + 8 * set: Drive ability control (bitwise)
 bitx: 0 - Open drain (default)
 bitx: 1 - Push Pull
 In this driver, we only implements open drain mode.

IO space:
(IO base + 0~5): GPIO-0x~5x in/out value (bitwise)

Suggested-by: One Thousand Gnomes 
Suggested-by: Andy Shevchenko 
Signed-off-by: Peter Hung 
---
 drivers/gpio/Kconfig   |  10 ++
 drivers/gpio/Makefile  |   1 +
 drivers/gpio/gpio-f81504.c | 241 +
 3 files changed, 252 insertions(+)
 create mode 100644 drivers/gpio/gpio-f81504.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 2b80903..c9e1cf8 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -912,6 +912,16 @@ config GPIO_WM8994
  Say yes here to access the GPIO signals of WM8994 audio hub
  CODECs from Wolfson Microelectronics.
 
+config GPIO_F81504
+tristate "Fintek F81504/508/512 PCIE-to-UART/GPIO support"
+depends on MFD_FINTEK_F81504_CORE
+select MFD_CORE
+help
+  Say yes here to support the GPIO functionality of Fintek
+  F81504/508/512 PCIE-to-UART/GPIO.
+
+  If unsure, say N.
+
 endmenu
 
 menu "PCI GPIO expanders"
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index c759190..f277089 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -112,6 +112,7 @@ obj-$(CONFIG_GPIO_VX855)+= gpio-vx855.o
 obj-$(CONFIG_GPIO_WM831X)  += gpio-wm831x.o
 obj-$(CONFIG_GPIO_WM8350)  += gpio-wm8350.o
 obj-$(CONFIG_GPIO_WM8994)  += gpio-wm8994.o
+obj-$(CONFIG_GPIO_F81504)   += gpio-f81504.o
 obj-$(CONFIG_GPIO_XGENE)   += gpio-xgene.o
 obj-$(CONFIG_GPIO_XGENE_SB)+= gpio-xgene-sb.o
 obj-$(CONFIG_GPIO_XILINX)  += gpio-xilinx.o
diff --git a/drivers/gpio/gpio-f81504.c b/drivers/gpio/gpio-f81504.c
new file mode 100644
index 000..25a535c
--- /dev/null
+++ b/drivers/gpio/gpio-f81504.c
@@ -0,0 +1,241 @@
+/*
+ * Copyright (C) 2016 Fintek Corporation
+ * Based on gpio-mpc8xxx.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+
+struct f81504_gpio_chip {
+   struct gpio_chip chip;
+   struct mutex locker;
+   u8 idx;
+   u8 save_out_en;
+   u8 save_drive_en;
+   u8 save_value;
+};
+
+static int f81504_gpio_direction_in(struct gpio_chip *chip, unsigned offset)
+{
+   struct f81504_gpio_chip *gc = gpiochip_get_data(chip);
+   struct platform_device *pdev = to_platform_device(chip->parent);
+   struct pci_dev *pci_dev = to_pci_dev(pdev->dev.parent);
+   u8 tmp;
+
+   mutex_lock(>locker);
+
+   /* Set input mode */
+   pci_read_config_byte(pci_dev, F81504_GPIO_START_ADDR + gc->idx *
+F81504_GPIO_SET_OFFSET +
+F81504_GPIO_OUT_EN_OFFSET, );
+   pci_write_config_byte(pci_dev, F81504_GPIO_START_ADDR + gc->idx *
+ F81504_GPIO_SET_OFFSET +
+ F81504_GPIO_OUT_EN_OFFSET, tmp & ~BIT(offset));
+
+   mutex_unlock(>locker);
+   return 0;
+}
+
+static int f81504_gpio_direction_out(struct gpio_chip *chip, unsigned offset,
+   int value)
+{
+   struct f81504_gpio_chip *gc = 

[PATCH V4 4/4] serial: 8250_pci: Remove Fintek F81504/508/512 UART driver

[Peter Hung]

Remove Fintek F81504/508/512 PCIE-to-UART device driver from 8250_pci.c

Paul recommed us do less code deletion to avoid confusing problem when
bisect.
https://lkml.org/lkml/2016/1/18/646

But this patch is sent after with following patch.
8250: 8250_f81504: Add Fintek F81504/508/512 PCIE-to-UART/GPIO UART support
mfd: f81504-core: Add Fintek F81504/508/512 PCIE-to-UART/GPIO core support

We must remove F81504/508/512 support in 8250_pci.c and migrate to
f81504-core/8250_f81504 to enable MFD support and Andy recommend me to
add these this in blacklist to avoid probed by 8250_pci.c

Suggested-by: Paul Gortmaker 
Suggested-by: Andy Shevchenko 
Signed-off-by: Peter Hung 
---
 drivers/tty/serial/8250/8250_pci.c | 206 +
 1 file changed, 5 insertions(+), 201 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_pci.c 
b/drivers/tty/serial/8250/8250_pci.c
index e71ec78..24a669c 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1532,156 +1532,6 @@ pci_brcm_trumanage_setup(struct serial_private *priv,
return ret;
 }
 
-/* RTS will control by MCR if this bit is 0 */
-#define FINTEK_RTS_CONTROL_BY_HW   BIT(4)
-/* only worked with FINTEK_RTS_CONTROL_BY_HW on */
-#define FINTEK_RTS_INVERT  BIT(5)
-
-/* We should do proper H/W transceiver setting before change to RS485 mode */
-static int pci_fintek_rs485_config(struct uart_port *port,
-  struct serial_rs485 *rs485)
-{
-   u8 setting;
-   u8 *index = (u8 *) port->private_data;
-   struct pci_dev *pci_dev = container_of(port->dev, struct pci_dev,
-   dev);
-
-   pci_read_config_byte(pci_dev, 0x40 + 8 * *index + 7, );
-
-   if (!rs485)
-   rs485 = >rs485;
-   else if (rs485->flags & SER_RS485_ENABLED)
-   memset(rs485->padding, 0, sizeof(rs485->padding));
-   else
-   memset(rs485, 0, sizeof(*rs485));
-
-   /* F81504/508/512 not support RTS delay before or after send */
-   rs485->flags &= SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND;
-
-   if (rs485->flags & SER_RS485_ENABLED) {
-   /* Enable RTS H/W control mode */
-   setting |= FINTEK_RTS_CONTROL_BY_HW;
-
-   if (rs485->flags & SER_RS485_RTS_ON_SEND) {
-   /* RTS driving high on TX */
-   setting &= ~FINTEK_RTS_INVERT;
-   } else {
-   /* RTS driving low on TX */
-   setting |= FINTEK_RTS_INVERT;
-   }
-
-   rs485->delay_rts_after_send = 0;
-   rs485->delay_rts_before_send = 0;
-   } else {
-   /* Disable RTS H/W control mode */
-   setting &= ~(FINTEK_RTS_CONTROL_BY_HW | FINTEK_RTS_INVERT);
-   }
-
-   pci_write_config_byte(pci_dev, 0x40 + 8 * *index + 7, setting);
-
-   if (rs485 != >rs485)
-   port->rs485 = *rs485;
-
-   return 0;
-}
-
-static int pci_fintek_setup(struct serial_private *priv,
-   const struct pciserial_board *board,
-   struct uart_8250_port *port, int idx)
-{
-   struct pci_dev *pdev = priv->dev;
-   u8 *data;
-   u8 config_base;
-   u16 iobase;
-
-   config_base = 0x40 + 0x08 * idx;
-
-   /* Get the io address from configuration space */
-   pci_read_config_word(pdev, config_base + 4, );
-
-   dev_dbg(>dev, "%s: idx=%d iobase=0x%x", __func__, idx, iobase);
-
-   port->port.iotype = UPIO_PORT;
-   port->port.iobase = iobase;
-   port->port.rs485_config = pci_fintek_rs485_config;
-
-   data = devm_kzalloc(>dev, sizeof(u8), GFP_KERNEL);
-   if (!data)
-   return -ENOMEM;
-
-   /* preserve index in PCI configuration space */
-   *data = idx;
-   port->port.private_data = data;
-
-   return 0;
-}
-
-static int pci_fintek_init(struct pci_dev *dev)
-{
-   unsigned long iobase;
-   u32 max_port, i;
-   u32 bar_data[3];
-   u8 config_base;
-   struct serial_private *priv = pci_get_drvdata(dev);
-   struct uart_8250_port *port;
-
-   switch (dev->device) {
-   case 0x1104: /* 4 ports */
-   case 0x1108: /* 8 ports */
-   max_port = dev->device & 0xff;
-   break;
-   case 0x1112: /* 12 ports */
-   max_port = 12;
-   break;
-   default:
-   return -EINVAL;
-   }
-
-   /* Get the io address dispatch from the BIOS */
-   pci_read_config_dword(dev, 0x24, _data[0]);
-   pci_read_config_dword(dev, 0x20, _data[1]);
-   pci_read_config_dword(dev, 0x1c, _data[2]);
-
-   for (i = 0; i < max_port; ++i) {
-   /* UART0 configuration offset start from 0x40 */
-   config_base = 0x40 + 0x08 * i;
-
-   /* Calculate Real IO Port */
-   iobase = (bar_data[i / 4] & 

[PATCH V4 1/4] mfd: f81504-core: Add Fintek F81504/508/512 PCIE-to-UART/GPIO core support

[Peter Hung]

The Fintek F81504/508/512 had implemented the basic serial port function in
8250_pci.c. We try to implement high baudrate & GPIOLIB with a spilt file
8250_f81504.c, but it seems too complex to add GPIOLIB.

Alan & Andy recommend us to rewrite and spilt our driver with MFD
architecture.
https://lkml.org/lkml/2016/1/19/288

This driver is core driver for F81504/508/512, it'll handle the generation
of UART/GPIO platform device and initialize PCIE configuration space when
probe()/resume().

IC function list:
F81504: Max 2x8 GPIOs and max 4 serial ports
port2/3 are multi-function
F81508: Max 6x8 GPIOs and max 8 serial ports
port2/3 are multi-function, port8/9/10/11 are gpio only
F81512: Max 6x8 GPIOs and max 12 serial ports
port2/3/8/9/10/11 are multi-function

H/W provider could changes the PCI configure space F0/F3h
values in EEPROM or ASL code to change mode.

F0h bit0~5: Enable GPIO0~5
bit6~7: Reserve

F3h bit0~5: Multi-Functional Flag (0:GPIO/1:UART)
bit0: UART2 pin out for UART2 / GPIO0
bit1: UART3 pin out for UART3 / GPIO1
bit2: UART8 pin out for UART8 / GPIO2
bit3: UART9 pin out for UART9 / GPIO3
bit4: UART10 pin out for UART10 / GPIO4
bit5: UART11 pin out for UART11 / GPIO5
bit6~7: Reserve

Suggested-by: One Thousand Gnomes 
Suggested-by: Andy Shevchenko 
Signed-off-by: Peter Hung 
---
 drivers/mfd/Kconfig|  12 ++
 drivers/mfd/Makefile   |   2 +
 drivers/mfd/f81504-core.c  | 335 +
 include/linux/mfd/f81504.h |  52 +++
 4 files changed, 401 insertions(+)
 create mode 100644 drivers/mfd/f81504-core.c
 create mode 100644 include/linux/mfd/f81504.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index aa21dc5..775761f 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -345,6 +345,18 @@ config HTC_I2CPLD
  This device provides input and output GPIOs through an I2C
  interface to one or more sub-chips.
 
+config MFD_FINTEK_F81504_CORE
+tristate "Fintek F81504/508/512 PCIE-to-UART/GPIO MFD support"
+depends on PCI
+select MFD_CORE
+default SERIAL_8250
+help
+  This driver provides the F81504/508/512 UART & GPIO platform
+  devices. You should enable CONFIG_GPIO_F81504 to get GPIOLIB
+  support and CONFIG_8250_F81504 to get serial port support.
+  This driver needs to be built into the kernel to use early
+  console support.
+
 config MFD_INTEL_QUARK_I2C_GPIO
tristate "Intel Quark MFD I2C GPIO"
depends on PCI
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 5eaa6465d..8e581ad 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -22,6 +22,8 @@ obj-$(CONFIG_HTC_EGPIO)   += htc-egpio.o
 obj-$(CONFIG_HTC_PASIC3)   += htc-pasic3.o
 obj-$(CONFIG_HTC_I2CPLD)   += htc-i2cpld.o
 
+obj-$(CONFIG_MFD_FINTEK_F81504_CORE)   += f81504-core.o
+
 obj-$(CONFIG_MFD_DAVINCI_VOICECODEC)   += davinci_voicecodec.o
 obj-$(CONFIG_MFD_DM355EVM_MSP) += dm355evm_msp.o
 obj-$(CONFIG_MFD_TI_AM335X_TSCADC) += ti_am335x_tscadc.o
diff --git a/drivers/mfd/f81504-core.c b/drivers/mfd/f81504-core.c
new file mode 100644
index 000..c192250
--- /dev/null
+++ b/drivers/mfd/f81504-core.c
@@ -0,0 +1,335 @@
+/*
+ * Core operations for Fintek F81504/508/512 PCIE-to-UART/GPIO device
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define F81504_IO_REGION   8
+
+const u8 fintek_gpio_mapping[F81504_MAX_GPIO_CNT] = { 2, 3, 8, 9, 10, 11 };
+EXPORT_SYMBOL(fintek_gpio_mapping);
+
+static bool f81504_is_gpio(unsigned int idx, u8 gpio_en)
+{
+   unsigned int i;
+
+   /* Find every port to check is multi-function port */
+   for (i = 0; i < ARRAY_SIZE(fintek_gpio_mapping); i++) {
+   if (fintek_gpio_mapping[i] != idx || !(gpio_en & BIT(i)))
+   continue;
+
+   /*
+* This port is multi-function and enabled as gpio mode.
+* So we'll not configure it as serial port.
+*/
+   return true;
+   }
+
+   return false;
+}
+
+static int f81504_port_init(struct pci_dev *pdev)
+{
+   struct f81504_pci_private *priv = pci_get_drvdata(pdev);
+   unsigned int i;
+   u32 gpio_addr;
+   u8 gpio_en, f0h_data, f3h_data;
+   u32 max_port, iobase;
+   u32 bar_data[3];
+   u16 tmp;
+   u8 config_base;
+
+   /* Init GPIO IO Address */
+   gpio_addr = pci_resource_start(pdev, 2);
+
+   /*
+* Write GPIO IO Address LSB/MSB to corresponding register. Due to we
+* can't write once with pci_write_config_word() on x86 platform, we'll
+* write it with pci_write_config_byte().
+*/
+   pci_write_config_byte(pdev, 

[PATCH V4 1/4] mfd: f81504-core: Add Fintek F81504/508/512 PCIE-to-UART/GPIO core support

[Peter Hung]

The Fintek F81504/508/512 had implemented the basic serial port function in
8250_pci.c. We try to implement high baudrate & GPIOLIB with a spilt file
8250_f81504.c, but it seems too complex to add GPIOLIB.

Alan & Andy recommend us to rewrite and spilt our driver with MFD
architecture.
https://lkml.org/lkml/2016/1/19/288

This driver is core driver for F81504/508/512, it'll handle the generation
of UART/GPIO platform device and initialize PCIE configuration space when
probe()/resume().

IC function list:
F81504: Max 2x8 GPIOs and max 4 serial ports
port2/3 are multi-function
F81508: Max 6x8 GPIOs and max 8 serial ports
port2/3 are multi-function, port8/9/10/11 are gpio only
F81512: Max 6x8 GPIOs and max 12 serial ports
port2/3/8/9/10/11 are multi-function

H/W provider could changes the PCI configure space F0/F3h
values in EEPROM or ASL code to change mode.

F0h bit0~5: Enable GPIO0~5
bit6~7: Reserve

F3h bit0~5: Multi-Functional Flag (0:GPIO/1:UART)
bit0: UART2 pin out for UART2 / GPIO0
bit1: UART3 pin out for UART3 / GPIO1
bit2: UART8 pin out for UART8 / GPIO2
bit3: UART9 pin out for UART9 / GPIO3
bit4: UART10 pin out for UART10 / GPIO4
bit5: UART11 pin out for UART11 / GPIO5
bit6~7: Reserve

Suggested-by: One Thousand Gnomes 
Suggested-by: Andy Shevchenko 
Signed-off-by: Peter Hung 
---
 drivers/mfd/Kconfig|  12 ++
 drivers/mfd/Makefile   |   2 +
 drivers/mfd/f81504-core.c  | 335 +
 include/linux/mfd/f81504.h |  52 +++
 4 files changed, 401 insertions(+)
 create mode 100644 drivers/mfd/f81504-core.c
 create mode 100644 include/linux/mfd/f81504.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index aa21dc5..775761f 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -345,6 +345,18 @@ config HTC_I2CPLD
  This device provides input and output GPIOs through an I2C
  interface to one or more sub-chips.
 
+config MFD_FINTEK_F81504_CORE
+tristate "Fintek F81504/508/512 PCIE-to-UART/GPIO MFD support"
+depends on PCI
+select MFD_CORE
+default SERIAL_8250
+help
+  This driver provides the F81504/508/512 UART & GPIO platform
+  devices. You should enable CONFIG_GPIO_F81504 to get GPIOLIB
+  support and CONFIG_8250_F81504 to get serial port support.
+  This driver needs to be built into the kernel to use early
+  console support.
+
 config MFD_INTEL_QUARK_I2C_GPIO
tristate "Intel Quark MFD I2C GPIO"
depends on PCI
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 5eaa6465d..8e581ad 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -22,6 +22,8 @@ obj-$(CONFIG_HTC_EGPIO)   += htc-egpio.o
 obj-$(CONFIG_HTC_PASIC3)   += htc-pasic3.o
 obj-$(CONFIG_HTC_I2CPLD)   += htc-i2cpld.o
 
+obj-$(CONFIG_MFD_FINTEK_F81504_CORE)   += f81504-core.o
+
 obj-$(CONFIG_MFD_DAVINCI_VOICECODEC)   += davinci_voicecodec.o
 obj-$(CONFIG_MFD_DM355EVM_MSP) += dm355evm_msp.o
 obj-$(CONFIG_MFD_TI_AM335X_TSCADC) += ti_am335x_tscadc.o
diff --git a/drivers/mfd/f81504-core.c b/drivers/mfd/f81504-core.c
new file mode 100644
index 000..c192250
--- /dev/null
+++ b/drivers/mfd/f81504-core.c
@@ -0,0 +1,335 @@
+/*
+ * Core operations for Fintek F81504/508/512 PCIE-to-UART/GPIO device
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define F81504_IO_REGION   8
+
+const u8 fintek_gpio_mapping[F81504_MAX_GPIO_CNT] = { 2, 3, 8, 9, 10, 11 };
+EXPORT_SYMBOL(fintek_gpio_mapping);
+
+static bool f81504_is_gpio(unsigned int idx, u8 gpio_en)
+{
+   unsigned int i;
+
+   /* Find every port to check is multi-function port */
+   for (i = 0; i < ARRAY_SIZE(fintek_gpio_mapping); i++) {
+   if (fintek_gpio_mapping[i] != idx || !(gpio_en & BIT(i)))
+   continue;
+
+   /*
+* This port is multi-function and enabled as gpio mode.
+* So we'll not configure it as serial port.
+*/
+   return true;
+   }
+
+   return false;
+}
+
+static int f81504_port_init(struct pci_dev *pdev)
+{
+   struct f81504_pci_private *priv = pci_get_drvdata(pdev);
+   unsigned int i;
+   u32 gpio_addr;
+   u8 gpio_en, f0h_data, f3h_data;
+   u32 max_port, iobase;
+   u32 bar_data[3];
+   u16 tmp;
+   u8 config_base;
+
+   /* Init GPIO IO Address */
+   gpio_addr = pci_resource_start(pdev, 2);
+
+   /*
+* Write GPIO IO Address LSB/MSB to corresponding register. Due to we
+* can't write once with pci_write_config_word() on x86 platform, we'll
+* write it with pci_write_config_byte().
+*/
+   pci_write_config_byte(pdev, F81504_GPIO_IO_LSB_REG, gpio_addr & 0xff);
+   pci_write_config_byte(pdev, 

[PATCH 1/2] drm/tegra: Set DMA ops

[Alexandre Courbot]

The current settings leaves the DRM device's dma_ops field NULL, which
makes it use the dummy DMA ops on arm64 and return an error whenever we
try to import a buffer. Call of_dma_configure() with a NULL node (since
the device is not spawn from the device tree) so that
arch_setup_dma_ops() is called and sets the default ioswtlb DMA ops.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpu/drm/tegra/drm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index d347188bf8f4..bc0555adecaf 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -9,6 +9,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -990,6 +991,7 @@ static int host1x_drm_probe(struct host1x_device *dev)
return -ENOMEM;
 
dev_set_drvdata(>dev, drm);
+   of_dma_configure(drm->dev, NULL);
 
err = drm_dev_register(drm, 0);
if (err < 0)
-- 
2.7.1

[PATCH 1/2] drm/tegra: Set DMA ops

[Alexandre Courbot]

The current settings leaves the DRM device's dma_ops field NULL, which
makes it use the dummy DMA ops on arm64 and return an error whenever we
try to import a buffer. Call of_dma_configure() with a NULL node (since
the device is not spawn from the device tree) so that
arch_setup_dma_ops() is called and sets the default ioswtlb DMA ops.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpu/drm/tegra/drm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index d347188bf8f4..bc0555adecaf 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -9,6 +9,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -990,6 +991,7 @@ static int host1x_drm_probe(struct host1x_device *dev)
return -ENOMEM;
 
dev_set_drvdata(>dev, drm);
+   of_dma_configure(drm->dev, NULL);
 
err = drm_dev_register(drm, 0);
if (err < 0)
-- 
2.7.1

[PATCH 2/2] drm/tegra: Set the DMA mask

[Alexandre Courbot]

The default DMA mask covers a 32 bits address range, but tegradrm can
address more than that. Set the DMA mask to the actual addressable range
to avoid the use of unneeded bounce buffers.

Signed-off-by: Alexandre Courbot 
---
Thierry, I am not absolutely sure whether the size is correct and applies
to all Tegra generations - please let me know if this needs to be
reworked.

 drivers/gpu/drm/tegra/drm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index bc0555adecaf..503fc9e73521 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -992,6 +992,7 @@ static int host1x_drm_probe(struct host1x_device *dev)
 
dev_set_drvdata(>dev, drm);
of_dma_configure(drm->dev, NULL);
+   dma_set_mask(drm->dev, DMA_BIT_MASK(34));
 
err = drm_dev_register(drm, 0);
if (err < 0)
-- 
2.7.1

[PATCH 2/2] drm/tegra: Set the DMA mask

[Alexandre Courbot]

The default DMA mask covers a 32 bits address range, but tegradrm can
address more than that. Set the DMA mask to the actual addressable range
to avoid the use of unneeded bounce buffers.

Signed-off-by: Alexandre Courbot 
---
Thierry, I am not absolutely sure whether the size is correct and applies
to all Tegra generations - please let me know if this needs to be
reworked.

 drivers/gpu/drm/tegra/drm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index bc0555adecaf..503fc9e73521 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -992,6 +992,7 @@ static int host1x_drm_probe(struct host1x_device *dev)
 
dev_set_drvdata(>dev, drm);
of_dma_configure(drm->dev, NULL);
+   dma_set_mask(drm->dev, DMA_BIT_MASK(34));
 
err = drm_dev_register(drm, 0);
if (err < 0)
-- 
2.7.1

RE: [PATCH] phy: rcar-gen3-usb2: remove HSUSB registers handling

[Yoshihiro Shimoda]

Hi Kishon,

Would you review this patch?

I checked the latest linux-phy.git / next branch today,
this patch can be applied on the top of branch.

commit 6b825eb7323a634cdd1014a4aa9a8ff07cf8040c
Author: Heiko Stuebner 
Date:   Mon Feb 22 12:55:01 2016 +0100

phy: rockchip-usb: add handler for usb-uart functionality

Best regards,
Yoshihiro Shimoda

> -Original Message-
> From: Yoshihiro Shimoda
> Sent: Tuesday, February 02, 2016 5:29 PM
> To: kis...@ti.com
> Cc: pawel.m...@arm.com; mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; 
> ga...@codeaurora.org;
> linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; 
> linux...@vger.kernel.org; 'Rob Herring' ;
> linux-renesas-...@vger.kernel.org
> Subject: RE: [PATCH] phy: rcar-gen3-usb2: remove HSUSB registers handling
> 
> Hi Kishon,
> 
> Would you review this patch?
> I checked the latest linux-phy.git / next branch today, and it is the same as 
> the following.
> 
> > >  This patch is based on the linux-phy / next branch.
> > >  (commit id = 9955a7835bf376e12482583958b2661f501b868b)
> 
> Best regards,
> Yoshihiro Shimoda
> 
> > From: Rob Herring [mailto:r...@kernel.org]
> > Sent: Sunday, January 10, 2016 7:33 AM
> > To: Yoshihiro Shimoda 
> > Cc: kis...@ti.com; pawel.m...@arm.com; mark.rutl...@arm.com; 
> > ijc+devicet...@hellion.org.uk; ga...@codeaurora.org;
> > linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; 
> > linux...@vger.kernel.org
> > Subject: Re: [PATCH] phy: rcar-gen3-usb2: remove HSUSB registers handling
> >
> > On Thu, Jan 07, 2016 at 06:16:44PM +0900, Yoshihiro Shimoda wrote:
> > > Since the related driver (CPG/MSSR driver) only manages the first module
> > > clock, this driver should not handle the HSUSB registers. So, this patch
> > > removes the HSUSB registers handling.
> > >
> > > Signed-off-by: Yoshihiro Shimoda 
> > > ---
> > >  This patch is based on the linux-phy / next branch.
> > >  (commit id = 9955a7835bf376e12482583958b2661f501b868b)
> > >
> > >  .../devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 15 ++--
> >
> > Acked-by: Rob Herring 
> >
> > >  drivers/phy/phy-rcar-gen3-usb2.c   | 83 
> > > +++---
> > >  2 files changed, 15 insertions(+), 83 deletions(-)
> >

RE: [PATCH] phy: rcar-gen3-usb2: remove HSUSB registers handling

[Yoshihiro Shimoda]

Hi Kishon,

Would you review this patch?

I checked the latest linux-phy.git / next branch today,
this patch can be applied on the top of branch.

commit 6b825eb7323a634cdd1014a4aa9a8ff07cf8040c
Author: Heiko Stuebner 
Date:   Mon Feb 22 12:55:01 2016 +0100

phy: rockchip-usb: add handler for usb-uart functionality

Best regards,
Yoshihiro Shimoda

> -Original Message-
> From: Yoshihiro Shimoda
> Sent: Tuesday, February 02, 2016 5:29 PM
> To: kis...@ti.com
> Cc: pawel.m...@arm.com; mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; 
> ga...@codeaurora.org;
> linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; 
> linux...@vger.kernel.org; 'Rob Herring' ;
> linux-renesas-...@vger.kernel.org
> Subject: RE: [PATCH] phy: rcar-gen3-usb2: remove HSUSB registers handling
> 
> Hi Kishon,
> 
> Would you review this patch?
> I checked the latest linux-phy.git / next branch today, and it is the same as 
> the following.
> 
> > >  This patch is based on the linux-phy / next branch.
> > >  (commit id = 9955a7835bf376e12482583958b2661f501b868b)
> 
> Best regards,
> Yoshihiro Shimoda
> 
> > From: Rob Herring [mailto:r...@kernel.org]
> > Sent: Sunday, January 10, 2016 7:33 AM
> > To: Yoshihiro Shimoda 
> > Cc: kis...@ti.com; pawel.m...@arm.com; mark.rutl...@arm.com; 
> > ijc+devicet...@hellion.org.uk; ga...@codeaurora.org;
> > linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; 
> > linux...@vger.kernel.org
> > Subject: Re: [PATCH] phy: rcar-gen3-usb2: remove HSUSB registers handling
> >
> > On Thu, Jan 07, 2016 at 06:16:44PM +0900, Yoshihiro Shimoda wrote:
> > > Since the related driver (CPG/MSSR driver) only manages the first module
> > > clock, this driver should not handle the HSUSB registers. So, this patch
> > > removes the HSUSB registers handling.
> > >
> > > Signed-off-by: Yoshihiro Shimoda 
> > > ---
> > >  This patch is based on the linux-phy / next branch.
> > >  (commit id = 9955a7835bf376e12482583958b2661f501b868b)
> > >
> > >  .../devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 15 ++--
> >
> > Acked-by: Rob Herring 
> >
> > >  drivers/phy/phy-rcar-gen3-usb2.c   | 83 
> > > +++---
> > >  2 files changed, 15 insertions(+), 83 deletions(-)
> >

[PATCH v2] net: jme: fix suspend/resume on JMC260

[Diego Viola]

The JMC260 network card fails to suspend/resume because the call to
jme_start_irq() was too early, moving the call to jme_start_irq() after
the jme_reset_link() function makes it work.

Prior this change suspend/resume would fail unless /sys/power/pm_async=0
was explicitly specified.

Signed-off-by: Diego Viola 
---
 drivers/net/ethernet/jme.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/jme.c b/drivers/net/ethernet/jme.c
index b1de7af..8adbe8f 100644
--- a/drivers/net/ethernet/jme.c
+++ b/drivers/net/ethernet/jme.c
@@ -3312,13 +3312,14 @@ jme_resume(struct device *dev)
jme_reset_phy_processor(jme);
jme_phy_calibration(jme);
jme_phy_setEA(jme);
-   jme_start_irq(jme);
netif_device_attach(netdev);
 
atomic_inc(>link_changing);
 
jme_reset_link(jme);
 
+   jme_start_irq(jme);
+
return 0;
 }
 
-- 
2.7.1

[PATCH v2] net: jme: fix suspend/resume on JMC260

[Diego Viola]

The JMC260 network card fails to suspend/resume because the call to
jme_start_irq() was too early, moving the call to jme_start_irq() after
the jme_reset_link() function makes it work.

Prior this change suspend/resume would fail unless /sys/power/pm_async=0
was explicitly specified.

Signed-off-by: Diego Viola 
---
 drivers/net/ethernet/jme.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/jme.c b/drivers/net/ethernet/jme.c
index b1de7af..8adbe8f 100644
--- a/drivers/net/ethernet/jme.c
+++ b/drivers/net/ethernet/jme.c
@@ -3312,13 +3312,14 @@ jme_resume(struct device *dev)
jme_reset_phy_processor(jme);
jme_phy_calibration(jme);
jme_phy_setEA(jme);
-   jme_start_irq(jme);
netif_device_attach(netdev);
 
atomic_inc(>link_changing);
 
jme_reset_link(jme);
 
+   jme_start_irq(jme);
+
return 0;
 }
 
-- 
2.7.1

RE: [RFC PATCH] drivers: ata: Read Rx water mark value from device-tree

[Anurag Kumar Vulisha]

Hi Arnd,

> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Monday, February 22, 2016 8:50 PM
> To: Anurag Kumar Vulisha
> Cc: robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com;
> ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; t...@kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> i...@vger.kernel.org; Anirudha Sarangi; Srikanth Vemula; Punnaiah Choudary
> Kalluri
> Subject: Re: [RFC PATCH] drivers: ata: Read Rx water mark value from device-
> tree
>
> On Monday 22 February 2016 10:53:11 Anurag Kumar Vulisha wrote:
> > > >
> > >
> > > How would a hardware integrator know which value is right for a
> > > particular SoC?
> > >
> > > Could it be keyed off the hardware ID? Could the bootloader perhaps
> > > set an appropriate value in the AHCI_VEND_PTC register at boot time
> > > and the driver read the initial value from it?
> > >
> > > From the description, it sounds like this is a policy decision
> > > rather than hardware description, and shouldn't really be in here.
> > >
> >
> > Thanks for reviewing the patch. Can I use module_param() for this
> > watermark instead of reading it from devicetree or doing it in
> > bootloader. In bootloader we are initializing serdes controller for
> > high speed devices. As a part of this initialization we will be reseting 
> > all the
> high speed pheripherals which are using serdes, so SATA will also get
> resetted. Because of this reason, can I use module_param() for Rxwatermark
> value  instead?
> >
>
> I don't know what is appropriate because I have no idea what Rxwatermark is
> good for. Can you try describing why we can't just set it to the correct value
> for everyone automatically?
>

This RX watermark level sets the minimum number of free locations within the RX 
FIFO .When the rx fifo level crosses the programmed watermark level ,sata 
controller  will transmit HOLDS to the device asking it to wait. This happens 
when dma
reads the rx fifo data slower than the device is sending the data. Note that it 
can take some time for the HOLDs to get to
the other end and in the time there must be enough room in the FIFO to absorb 
all data that could arrive from the device.
Currently we are using 0x40 for this value, which works fine with all hardware 
designs  we are currently having. But hoping
that this value may vary for future silicon versions, I wanted to make this as 
a configurable value. So for this reason I thought
of moving it either to device-tree or making it as a module_param() property.

Thanks,
Anurag Kumar V

>   Arnd


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

RE: [RFC PATCH] drivers: ata: Read Rx water mark value from device-tree

[Anurag Kumar Vulisha]

Hi Arnd,

> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Monday, February 22, 2016 8:50 PM
> To: Anurag Kumar Vulisha
> Cc: robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com;
> ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; t...@kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> i...@vger.kernel.org; Anirudha Sarangi; Srikanth Vemula; Punnaiah Choudary
> Kalluri
> Subject: Re: [RFC PATCH] drivers: ata: Read Rx water mark value from device-
> tree
>
> On Monday 22 February 2016 10:53:11 Anurag Kumar Vulisha wrote:
> > > >
> > >
> > > How would a hardware integrator know which value is right for a
> > > particular SoC?
> > >
> > > Could it be keyed off the hardware ID? Could the bootloader perhaps
> > > set an appropriate value in the AHCI_VEND_PTC register at boot time
> > > and the driver read the initial value from it?
> > >
> > > From the description, it sounds like this is a policy decision
> > > rather than hardware description, and shouldn't really be in here.
> > >
> >
> > Thanks for reviewing the patch. Can I use module_param() for this
> > watermark instead of reading it from devicetree or doing it in
> > bootloader. In bootloader we are initializing serdes controller for
> > high speed devices. As a part of this initialization we will be reseting 
> > all the
> high speed pheripherals which are using serdes, so SATA will also get
> resetted. Because of this reason, can I use module_param() for Rxwatermark
> value  instead?
> >
>
> I don't know what is appropriate because I have no idea what Rxwatermark is
> good for. Can you try describing why we can't just set it to the correct value
> for everyone automatically?
>

This RX watermark level sets the minimum number of free locations within the RX 
FIFO .When the rx fifo level crosses the programmed watermark level ,sata 
controller  will transmit HOLDS to the device asking it to wait. This happens 
when dma
reads the rx fifo data slower than the device is sending the data. Note that it 
can take some time for the HOLDs to get to
the other end and in the time there must be enough room in the FIFO to absorb 
all data that could arrive from the device.
Currently we are using 0x40 for this value, which works fine with all hardware 
designs  we are currently having. But hoping
that this value may vary for future silicon versions, I wanted to make this as 
a configurable value. So for this reason I thought
of moving it either to device-tree or making it as a module_param() property.

Thanks,
Anurag Kumar V

>   Arnd


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

[PATCH v2 2/2] ARM: at91: sama5/dts: move hsmc_clk out of nfc node

[Wenyou Yang]

From: Josh Wu 

For SAMA5D3, SAMA5D4 SoC family, as PMECC is a part of HSMC, PMECC
needs the HSMC clock, so move out hsmc_clk from the nfc node to
the nand node.

Signed-off-by: Josh Wu 
Signed-off-by: Wenyou Yang 
---

Changes in v2:
 - add a patch to change SAMA5D3 nand node's compatible string
   to "atmel,sama5d3-nand".
 - revert the mail address of Josh's Signed-off to the original.

 arch/arm/boot/dts/sama5d3.dtsi |2 +-
 arch/arm/boot/dts/sama5d4.dtsi |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index ee1b1a8..d20a38b 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -1474,6 +1474,7 @@
atmel,nand-has-dma;
pinctrl-names = "default";
pinctrl-0 = <_nand0_ale_cle>;
+   clocks = <_clk>;
atmel,pmecc-lookup-table-offset = <0x0 0x8000>;
status = "disabled";
 
@@ -1486,7 +1487,6 @@
0xc000 0x0070   /* NFC HSMC 
regs */
0x0020 0x0010   /* NFC SRAM 
banks */
>;
-   clocks = <_clk>;
};
};
};
diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi
index b8032bc..1499b33 100644
--- a/arch/arm/boot/dts/sama5d4.dtsi
+++ b/arch/arm/boot/dts/sama5d4.dtsi
@@ -295,6 +295,7 @@
atmel,nand-has-dma;
pinctrl-names = "default";
pinctrl-0 = <_nand>;
+   clocks = <_clk>;
status = "disabled";
 
nfc@9000 {
@@ -306,7 +307,6 @@
0xfc05c000 0x0070   /* NFC HSMC 
regs */
0x0010 0x0010   /* NFC SRAM 
banks */
  >;
-   clocks = <_clk>;
atmel,write-by-sram;
};
};
-- 
1.7.9.5

[PATCH v2 2/2] ARM: at91: sama5/dts: move hsmc_clk out of nfc node

[Wenyou Yang]

From: Josh Wu 

For SAMA5D3, SAMA5D4 SoC family, as PMECC is a part of HSMC, PMECC
needs the HSMC clock, so move out hsmc_clk from the nfc node to
the nand node.

Signed-off-by: Josh Wu 
Signed-off-by: Wenyou Yang 
---

Changes in v2:
 - add a patch to change SAMA5D3 nand node's compatible string
   to "atmel,sama5d3-nand".
 - revert the mail address of Josh's Signed-off to the original.

 arch/arm/boot/dts/sama5d3.dtsi |2 +-
 arch/arm/boot/dts/sama5d4.dtsi |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index ee1b1a8..d20a38b 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -1474,6 +1474,7 @@
atmel,nand-has-dma;
pinctrl-names = "default";
pinctrl-0 = <_nand0_ale_cle>;
+   clocks = <_clk>;
atmel,pmecc-lookup-table-offset = <0x0 0x8000>;
status = "disabled";
 
@@ -1486,7 +1487,6 @@
0xc000 0x0070   /* NFC HSMC 
regs */
0x0020 0x0010   /* NFC SRAM 
banks */
>;
-   clocks = <_clk>;
};
};
};
diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi
index b8032bc..1499b33 100644
--- a/arch/arm/boot/dts/sama5d4.dtsi
+++ b/arch/arm/boot/dts/sama5d4.dtsi
@@ -295,6 +295,7 @@
atmel,nand-has-dma;
pinctrl-names = "default";
pinctrl-0 = <_nand>;
+   clocks = <_clk>;
status = "disabled";
 
nfc@9000 {
@@ -306,7 +307,6 @@
0xfc05c000 0x0070   /* NFC HSMC 
regs */
0x0010 0x0010   /* NFC SRAM 
banks */
  >;
-   clocks = <_clk>;
atmel,write-by-sram;
};
};
-- 
1.7.9.5

[PATCH v2 1/2] ARM: at91: sama5d3/dts: add compatiable string for nand

[Wenyou Yang]

From: Josh Wu 

As introducing a new "atmel,sama5d3-nand" compatible string for
SAMA5D3's nand node, apply it for SAMA5D3 SoC.

Signed-off-by: Josh Wu 
Signed-off-by: Wenyou Yang 
---

Changes in v2: None

 arch/arm/boot/dts/sama5d3.dtsi |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index a532791..ee1b1a8 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -1459,7 +1459,7 @@
};
 
nand0: nand@6000 {
-   compatible = "atmel,at91rm9200-nand";
+   compatible = "atmel,sama5d3-nand", 
"atmel,at91rm9200-nand";
#address-cells = <1>;
#size-cells = <1>;
ranges;
-- 
1.7.9.5

[PATCH v2 1/2] ARM: at91: sama5d3/dts: add compatiable string for nand

[Wenyou Yang]

From: Josh Wu 

As introducing a new "atmel,sama5d3-nand" compatible string for
SAMA5D3's nand node, apply it for SAMA5D3 SoC.

Signed-off-by: Josh Wu 
Signed-off-by: Wenyou Yang 
---

Changes in v2: None

 arch/arm/boot/dts/sama5d3.dtsi |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index a532791..ee1b1a8 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -1459,7 +1459,7 @@
};
 
nand0: nand@6000 {
-   compatible = "atmel,at91rm9200-nand";
+   compatible = "atmel,sama5d3-nand", 
"atmel,at91rm9200-nand";
#address-cells = <1>;
#size-cells = <1>;
ranges;
-- 
1.7.9.5

[PATCH v2 0/2] ARM: at91: sama5/dts: move hsmc_clk out of nfc node

[Wenyou Yang]

For SAMA5D3, SAMA5D4 SoC family, PMECC needs the HSMC clock,
so move out hsmc_clk from the nfc node to the nand node.

Also, change the SAMA5D3 nand node's compatible string to
"atmel,sama5d3-nand".

Changes in v2:
 - add a patch to change SAMA5D3 nand node's compatible string
   to "atmel,sama5d3-nand".
 - revert the mail address of Josh's Signed-off to the original.

Josh Wu (2):
  ARM: at91: sama5d3/dts: add compatiable string for nand
  ARM: at91: sama5/dts: move hsmc_clk out of nfc node

 arch/arm/boot/dts/sama5d3.dtsi |4 ++--
 arch/arm/boot/dts/sama5d4.dtsi |2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

-- 
1.7.9.5

[PATCH v2 0/2] ARM: at91: sama5/dts: move hsmc_clk out of nfc node

[Wenyou Yang]

For SAMA5D3, SAMA5D4 SoC family, PMECC needs the HSMC clock,
so move out hsmc_clk from the nfc node to the nand node.

Also, change the SAMA5D3 nand node's compatible string to
"atmel,sama5d3-nand".

Changes in v2:
 - add a patch to change SAMA5D3 nand node's compatible string
   to "atmel,sama5d3-nand".
 - revert the mail address of Josh's Signed-off to the original.

Josh Wu (2):
  ARM: at91: sama5d3/dts: add compatiable string for nand
  ARM: at91: sama5/dts: move hsmc_clk out of nfc node

 arch/arm/boot/dts/sama5d3.dtsi |4 ++--
 arch/arm/boot/dts/sama5d4.dtsi |2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

-- 
1.7.9.5

[PATCH v3] mtd: atmel_nand: move the hsmc_clk from nfc node to nand node

[Wenyou Yang]

From: Josh Wu 

For SAMA5D3, SAMA5D4 SoC family, PMECC becomes a part of HSMC, they
need the HSMC clock enabled to work.
The NFC is a sub feature for current nand driver, it can be disabled.
But if HSMC clock is controlled by NFC, so disable NFC will also disable
the HSMC clock. then, it will make the PMECC fail to work.

So the solution is move the HSMC clock out of NFC to nand node. When
nand driver probed, it will check whether the chip has HSMC, if yes then
it will require a HSMC clock.

Add a new "atmel,sama5d3-nand" compatiable string for SAMA5D3's nand.

Signed-off-by: Josh Wu 
Signed-off-by: Wenyou Yang 
---

Changes in v3:
 - add "atmel,sama5d3-nand" compatiable string for SAMA5D3's nand.
 - revert the mail address of Josh's Signed-off to the original.

Changes in v2:
 - add missing .has_hsmc_clk assignment for sama5d2_caps.

 .../devicetree/bindings/mtd/atmel-nand.txt |4 +-
 drivers/mtd/nand/atmel_nand.c  |   51 +++-
 2 files changed, 30 insertions(+), 25 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt 
b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
index d53aba9..29bee7c 100644
--- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
@@ -15,6 +15,7 @@ Required properties:
 - atmel,nand-cmd-offset : offset for the command latch.
 - #address-cells, #size-cells : Must be present if the device has sub-nodes
   representing partitions.
+- clocks: phandle to the peripheral clock
 
 - gpios : specifies the gpio pins to control the NAND device. detect is an
   optional gpio and may be set to 0 if not present.
@@ -43,7 +44,6 @@ Required properties:
 - reg : should specify the address and size used for NFC command registers,
 NFC registers and NFC SRAM. NFC SRAM address and size can be absent
 if don't want to use it.
-- clocks: phandle to the peripheral clock
 Optional properties:
 - atmel,write-by-sram: boolean to enable NFC write by SRAM.
 
@@ -100,13 +100,13 @@ nand0: nand@4000 {
compatible = "atmel,at91rm9200-nand";
#address-cells = <1>;
#size-cells = <1>;
+   clocks = <_clk>
ranges;
 ...
 nfc@7000 {
compatible = "atmel,sama5d3-nfc";
#address-cells = <1>;
#size-cells = <1>;
-   clocks = <_clk>
reg = <
0x7000 0x1000   /* NFC Command Registers */
0xc000 0x0070   /* NFC HSMC regs */
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 20cbaab..482251c 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -66,6 +66,7 @@ module_param(on_flash_bbt, int, 0);
 struct atmel_nand_caps {
bool pmecc_correct_erase_page;
uint8_t pmecc_max_correction;
+   bool has_hsmc_clk;
 };
 
 struct atmel_nand_nfc_caps {
@@ -106,8 +107,6 @@ struct atmel_nfc {
booluse_nfc_sram;
boolwrite_by_sram;
 
-   struct clk  *clk;
-
boolis_initialized;
struct completion   comp_ready;
struct completion   comp_cmd_done;
@@ -132,6 +131,7 @@ struct atmel_nand_host {
struct dma_chan *dma_chan;
 
struct atmel_nfc*nfc;
+   struct clk  *clk;
 
const struct atmel_nand_caps*caps;
boolhas_pmecc;
@@ -2157,6 +2157,19 @@ static int atmel_nand_probe(struct platform_device *pdev)
nand_chip->IO_ADDR_R = host->io_base;
nand_chip->IO_ADDR_W = host->io_base;
 
+   if (host->caps->has_hsmc_clk) {
+   host->clk = devm_clk_get(>dev, NULL);
+   if (IS_ERR(host->clk)) {
+   dev_err(>dev, "HSMC clock is missing, update your 
Device Tree");
+   res = PTR_ERR(host->clk);
+   goto err_nand_ioremap;
+   }
+
+   res = clk_prepare_enable(host->clk);
+   if (res)
+   goto err_nand_ioremap;
+   }
+
if (nand_nfc.is_initialized) {
/* NFC driver is probed and initialized */
host->nfc = _nfc;
@@ -2321,6 +2334,9 @@ static int atmel_nand_remove(struct platform_device *pdev)
if (host->dma_chan)
dma_release_channel(host->dma_chan);
 
+   if (!IS_ERR(host->clk))
+   clk_disable_unprepare(host->clk);
+
platform_driver_unregister(_nand_nfc_driver);
 
return 0;
@@ -2334,11 +2350,19 @@ static int atmel_nand_remove(struct platform_device 
*pdev)
 static const struct atmel_nand_caps at91rm9200_caps = {
.pmecc_correct_erase_page = false,
.pmecc_max_correction = 24,
+   .has_hsmc_clk = false,
+};
+
+static struct 

[PATCH v3] mtd: atmel_nand: move the hsmc_clk from nfc node to nand node

[Wenyou Yang]

From: Josh Wu 

For SAMA5D3, SAMA5D4 SoC family, PMECC becomes a part of HSMC, they
need the HSMC clock enabled to work.
The NFC is a sub feature for current nand driver, it can be disabled.
But if HSMC clock is controlled by NFC, so disable NFC will also disable
the HSMC clock. then, it will make the PMECC fail to work.

So the solution is move the HSMC clock out of NFC to nand node. When
nand driver probed, it will check whether the chip has HSMC, if yes then
it will require a HSMC clock.

Add a new "atmel,sama5d3-nand" compatiable string for SAMA5D3's nand.

Signed-off-by: Josh Wu 
Signed-off-by: Wenyou Yang 
---

Changes in v3:
 - add "atmel,sama5d3-nand" compatiable string for SAMA5D3's nand.
 - revert the mail address of Josh's Signed-off to the original.

Changes in v2:
 - add missing .has_hsmc_clk assignment for sama5d2_caps.

 .../devicetree/bindings/mtd/atmel-nand.txt |4 +-
 drivers/mtd/nand/atmel_nand.c  |   51 +++-
 2 files changed, 30 insertions(+), 25 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt 
b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
index d53aba9..29bee7c 100644
--- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
@@ -15,6 +15,7 @@ Required properties:
 - atmel,nand-cmd-offset : offset for the command latch.
 - #address-cells, #size-cells : Must be present if the device has sub-nodes
   representing partitions.
+- clocks: phandle to the peripheral clock
 
 - gpios : specifies the gpio pins to control the NAND device. detect is an
   optional gpio and may be set to 0 if not present.
@@ -43,7 +44,6 @@ Required properties:
 - reg : should specify the address and size used for NFC command registers,
 NFC registers and NFC SRAM. NFC SRAM address and size can be absent
 if don't want to use it.
-- clocks: phandle to the peripheral clock
 Optional properties:
 - atmel,write-by-sram: boolean to enable NFC write by SRAM.
 
@@ -100,13 +100,13 @@ nand0: nand@4000 {
compatible = "atmel,at91rm9200-nand";
#address-cells = <1>;
#size-cells = <1>;
+   clocks = <_clk>
ranges;
 ...
 nfc@7000 {
compatible = "atmel,sama5d3-nfc";
#address-cells = <1>;
#size-cells = <1>;
-   clocks = <_clk>
reg = <
0x7000 0x1000   /* NFC Command Registers */
0xc000 0x0070   /* NFC HSMC regs */
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 20cbaab..482251c 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -66,6 +66,7 @@ module_param(on_flash_bbt, int, 0);
 struct atmel_nand_caps {
bool pmecc_correct_erase_page;
uint8_t pmecc_max_correction;
+   bool has_hsmc_clk;
 };
 
 struct atmel_nand_nfc_caps {
@@ -106,8 +107,6 @@ struct atmel_nfc {
booluse_nfc_sram;
boolwrite_by_sram;
 
-   struct clk  *clk;
-
boolis_initialized;
struct completion   comp_ready;
struct completion   comp_cmd_done;
@@ -132,6 +131,7 @@ struct atmel_nand_host {
struct dma_chan *dma_chan;
 
struct atmel_nfc*nfc;
+   struct clk  *clk;
 
const struct atmel_nand_caps*caps;
boolhas_pmecc;
@@ -2157,6 +2157,19 @@ static int atmel_nand_probe(struct platform_device *pdev)
nand_chip->IO_ADDR_R = host->io_base;
nand_chip->IO_ADDR_W = host->io_base;
 
+   if (host->caps->has_hsmc_clk) {
+   host->clk = devm_clk_get(>dev, NULL);
+   if (IS_ERR(host->clk)) {
+   dev_err(>dev, "HSMC clock is missing, update your 
Device Tree");
+   res = PTR_ERR(host->clk);
+   goto err_nand_ioremap;
+   }
+
+   res = clk_prepare_enable(host->clk);
+   if (res)
+   goto err_nand_ioremap;
+   }
+
if (nand_nfc.is_initialized) {
/* NFC driver is probed and initialized */
host->nfc = _nfc;
@@ -2321,6 +2334,9 @@ static int atmel_nand_remove(struct platform_device *pdev)
if (host->dma_chan)
dma_release_channel(host->dma_chan);
 
+   if (!IS_ERR(host->clk))
+   clk_disable_unprepare(host->clk);
+
platform_driver_unregister(_nand_nfc_driver);
 
return 0;
@@ -2334,11 +2350,19 @@ static int atmel_nand_remove(struct platform_device 
*pdev)
 static const struct atmel_nand_caps at91rm9200_caps = {
.pmecc_correct_erase_page = false,
.pmecc_max_correction = 24,
+   .has_hsmc_clk = false,
+};
+
+static struct atmel_nand_caps sama5d3_caps = {
+   

RE: [PATCH] ARM: at91: sama5/dts: move hsmc_clk out of nfc node

[Yang, Wenyou]

> -Original Message-
> From: Ferre, Nicolas
> Sent: 2016年2月22日 20:58
> To: Yang, Wenyou ; Rob Herring
> ; Pawel Moll ; Mark Brown
> ; Ian Campbell ; Kumar
> Gala ; Alexandre Belloni  electrons.com>; Jean-Christophe Plagniol-Villard ;
> Russell King 
> Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; Wu, Josh ; Josh Wu
> ; Alexandre Belloni  electrons.com>
> Subject: Re: [PATCH] ARM: at91: sama5/dts: move hsmc_clk out of nfc node
> 
> Le 17/02/2016 06:42, Wenyou Yang a écrit :
> > From: Josh Wu 
> >
> > In sama5d3, sama5d4 chips, pmecc will use the hsmc clock. As pmecc is
> > part of HSMC. So move out hsmc_clk from nfc node to nand node.
> >
> > Signed-off-by: Josh Wu 
> > Signed-off-by: Wenyou Yang 
> 
> I'm not against this change, but beware, it must be applied in 
> synchronization with
> the patch just posted "[PATCH] mtd: atmel_nand:
> move the hsmc_clk from nfc node to nand node"

Okay, revert the mail address to the original one, keep it consistent.

And add this address to CC. 

> 
> Bye,
> 
> 
> > ---
> >
> >  arch/arm/boot/dts/sama5d3.dtsi |2 +-
> >  arch/arm/boot/dts/sama5d4.dtsi |2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/sama5d3.dtsi
> > b/arch/arm/boot/dts/sama5d3.dtsi index a532791..a242d27 100644
> > --- a/arch/arm/boot/dts/sama5d3.dtsi
> > +++ b/arch/arm/boot/dts/sama5d3.dtsi
> > @@ -1474,6 +1474,7 @@
> > atmel,nand-has-dma;
> > pinctrl-names = "default";
> > pinctrl-0 = <_nand0_ale_cle>;
> > +   clocks = <_clk>;
> > atmel,pmecc-lookup-table-offset = <0x0 0x8000>;
> > status = "disabled";
> >
> > @@ -1486,7 +1487,6 @@
> > 0xc000 0x0070   /* NFC HSMC
> regs */
> > 0x0020 0x0010   /* NFC
> SRAM banks */
> > >;
> > -   clocks = <_clk>;
> > };
> > };
> > };
> > diff --git a/arch/arm/boot/dts/sama5d4.dtsi
> > b/arch/arm/boot/dts/sama5d4.dtsi index b8032bc..1499b33 100644
> > --- a/arch/arm/boot/dts/sama5d4.dtsi
> > +++ b/arch/arm/boot/dts/sama5d4.dtsi
> > @@ -295,6 +295,7 @@
> > atmel,nand-has-dma;
> > pinctrl-names = "default";
> > pinctrl-0 = <_nand>;
> > +   clocks = <_clk>;
> > status = "disabled";
> >
> > nfc@9000 {
> > @@ -306,7 +307,6 @@
> > 0xfc05c000 0x0070   /* NFC
> HSMC regs */
> > 0x0010 0x0010   /* NFC
> SRAM banks */
> >   >;
> > -   clocks = <_clk>;
> > atmel,write-by-sram;
> > };
> > };
> >
> 
> 
> --
> Nicolas Ferre


Best Regards,
Wenyou Yang

RE: [PATCH] ARM: at91: sama5/dts: move hsmc_clk out of nfc node

[Yang, Wenyou]

> -Original Message-
> From: Ferre, Nicolas
> Sent: 2016年2月22日 20:58
> To: Yang, Wenyou ; Rob Herring
> ; Pawel Moll ; Mark Brown
> ; Ian Campbell ; Kumar
> Gala ; Alexandre Belloni  electrons.com>; Jean-Christophe Plagniol-Villard ;
> Russell King 
> Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; Wu, Josh ; Josh Wu
> ; Alexandre Belloni  electrons.com>
> Subject: Re: [PATCH] ARM: at91: sama5/dts: move hsmc_clk out of nfc node
> 
> Le 17/02/2016 06:42, Wenyou Yang a écrit :
> > From: Josh Wu 
> >
> > In sama5d3, sama5d4 chips, pmecc will use the hsmc clock. As pmecc is
> > part of HSMC. So move out hsmc_clk from nfc node to nand node.
> >
> > Signed-off-by: Josh Wu 
> > Signed-off-by: Wenyou Yang 
> 
> I'm not against this change, but beware, it must be applied in 
> synchronization with
> the patch just posted "[PATCH] mtd: atmel_nand:
> move the hsmc_clk from nfc node to nand node"

Okay, revert the mail address to the original one, keep it consistent.

And add this address to CC. 

> 
> Bye,
> 
> 
> > ---
> >
> >  arch/arm/boot/dts/sama5d3.dtsi |2 +-
> >  arch/arm/boot/dts/sama5d4.dtsi |2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/sama5d3.dtsi
> > b/arch/arm/boot/dts/sama5d3.dtsi index a532791..a242d27 100644
> > --- a/arch/arm/boot/dts/sama5d3.dtsi
> > +++ b/arch/arm/boot/dts/sama5d3.dtsi
> > @@ -1474,6 +1474,7 @@
> > atmel,nand-has-dma;
> > pinctrl-names = "default";
> > pinctrl-0 = <_nand0_ale_cle>;
> > +   clocks = <_clk>;
> > atmel,pmecc-lookup-table-offset = <0x0 0x8000>;
> > status = "disabled";
> >
> > @@ -1486,7 +1487,6 @@
> > 0xc000 0x0070   /* NFC HSMC
> regs */
> > 0x0020 0x0010   /* NFC
> SRAM banks */
> > >;
> > -   clocks = <_clk>;
> > };
> > };
> > };
> > diff --git a/arch/arm/boot/dts/sama5d4.dtsi
> > b/arch/arm/boot/dts/sama5d4.dtsi index b8032bc..1499b33 100644
> > --- a/arch/arm/boot/dts/sama5d4.dtsi
> > +++ b/arch/arm/boot/dts/sama5d4.dtsi
> > @@ -295,6 +295,7 @@
> > atmel,nand-has-dma;
> > pinctrl-names = "default";
> > pinctrl-0 = <_nand>;
> > +   clocks = <_clk>;
> > status = "disabled";
> >
> > nfc@9000 {
> > @@ -306,7 +307,6 @@
> > 0xfc05c000 0x0070   /* NFC
> HSMC regs */
> > 0x0010 0x0010   /* NFC
> SRAM banks */
> >   >;
> > -   clocks = <_clk>;
> > atmel,write-by-sram;
> > };
> > };
> >
> 
> 
> --
> Nicolas Ferre


Best Regards,
Wenyou Yang

RE: [PATCH] mtd: atmel_nand: move the hsmc_clk from nfc node to nand node

[Yang, Wenyou]

> -Original Message-
> From: Ferre, Nicolas
> Sent: 2016年2月22日 20:57
> To: Yang, Wenyou ; Brian Norris
> ; David Woodhouse ;
> Josh Wu 
> Cc: linux-...@lists.infradead.org; linux-arm-ker...@lists.infradead.org; 
> linux-
> ker...@vger.kernel.org; Wu, Josh 
> Subject: Re: [PATCH] mtd: atmel_nand: move the hsmc_clk from nfc node to nand
> node
> 
> Le 17/02/2016 06:40, Wenyou Yang a écrit :
> > From: Josh Wu 
> >
> > For sama5d3, sama5d4 chip, the pmecc becomes a part of HSMC, they need
> > the HSMC clock to be enabled to work.
> > The NFC is a sub feature for current nand driver, it can be disabled.
> > But if HSMC clock is controlled by NFC, so disable NFC will also
> > disable the HSMC clock. then, it will make the PMECC fail to work.
> >
> > So the solution is to move the HSMC clock out of NFC to nand node.
> > When nand driver probed, it will check whether the chip has HSMC, if
> > yes then it will require a HSMC clock.
> >
> > Signed-off-by: Josh Wu 
> > Signed-off-by: Wenyou Yang 
> > ---
> >
> >  .../devicetree/bindings/mtd/atmel-nand.txt |4 +-
> >  drivers/mtd/nand/atmel_nand.c  |   43 
> > +---
> >  2 files changed, 22 insertions(+), 25 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> > b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> > index d53aba9..29bee7c 100644
> > --- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> > +++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> > @@ -15,6 +15,7 @@ Required properties:
> >  - atmel,nand-cmd-offset : offset for the command latch.
> >  - #address-cells, #size-cells : Must be present if the device has sub-nodes
> >representing partitions.
> > +- clocks: phandle to the peripheral clock
> >
> >  - gpios : specifies the gpio pins to control the NAND device. detect is an
> >optional gpio and may be set to 0 if not present.
> > @@ -43,7 +44,6 @@ Required properties:
> >  - reg : should specify the address and size used for NFC command registers,
> >  NFC registers and NFC SRAM. NFC SRAM address and size can be
> absent
> >  if don't want to use it.
> > -- clocks: phandle to the peripheral clock  Optional properties:
> >  - atmel,write-by-sram: boolean to enable NFC write by SRAM.
> >
> > @@ -100,13 +100,13 @@ nand0: nand@4000 {
> > compatible = "atmel,at91rm9200-nand";
> > #address-cells = <1>;
> > #size-cells = <1>;
> > +   clocks = <_clk>
> > ranges;
> >  ...
> >  nfc@7000 {
> > compatible = "atmel,sama5d3-nfc";
> > #address-cells = <1>;
> > #size-cells = <1>;
> > -   clocks = <_clk>
> > reg = <
> > 0x7000 0x1000   /* NFC Command
> Registers */
> > 0xc000 0x0070   /* NFC HSMC regs */
> > diff --git a/drivers/mtd/nand/atmel_nand.c
> > b/drivers/mtd/nand/atmel_nand.c index 20cbaab..a1f4ad2 100644
> > --- a/drivers/mtd/nand/atmel_nand.c
> > +++ b/drivers/mtd/nand/atmel_nand.c
> > @@ -66,6 +66,7 @@ module_param(on_flash_bbt, int, 0);  struct
> > atmel_nand_caps {
> > bool pmecc_correct_erase_page;
> > uint8_t pmecc_max_correction;
> > +   bool has_hsmc_clk;
> >  };
> >
> >  struct atmel_nand_nfc_caps {
> > @@ -106,8 +107,6 @@ struct atmel_nfc {
> > booluse_nfc_sram;
> > boolwrite_by_sram;
> >
> > -   struct clk  *clk;
> > -
> > boolis_initialized;
> > struct completion   comp_ready;
> > struct completion   comp_cmd_done;
> > @@ -132,6 +131,7 @@ struct atmel_nand_host {
> > struct dma_chan *dma_chan;
> >
> > struct atmel_nfc*nfc;
> > +   struct clk  *clk;
> >
> > const struct atmel_nand_caps*caps;
> > boolhas_pmecc;
> > @@ -2157,6 +2157,19 @@ static int atmel_nand_probe(struct platform_device
> *pdev)
> > nand_chip->IO_ADDR_R = host->io_base;
> > nand_chip->IO_ADDR_W = host->io_base;
> >
> > +   if (host->caps->has_hsmc_clk) {
> > +   host->clk = devm_clk_get(>dev, NULL);
> > +   if (IS_ERR(host->clk)) {
> > +   dev_err(>dev, "HSMC clock is missing, update
> your Device Tree");
> > +   res = PTR_ERR(host->clk);
> > +   goto err_nand_ioremap;
> > +   }
> > +
> > +   res = clk_prepare_enable(host->clk);
> > +   if (res)
> > +   goto err_nand_ioremap;
> > +   }
> > +
> > if (nand_nfc.is_initialized) {
> > /* NFC driver is probed and initialized */
> > host->nfc = _nfc;
> > @@ -2321,6 +2334,9 @@ static int atmel_nand_remove(struct platform_device
> *pdev)
> > if (host->dma_chan)
> >  

RE: [PATCH] mtd: atmel_nand: move the hsmc_clk from nfc node to nand node

[Yang, Wenyou]

> -Original Message-
> From: Ferre, Nicolas
> Sent: 2016年2月22日 20:57
> To: Yang, Wenyou ; Brian Norris
> ; David Woodhouse ;
> Josh Wu 
> Cc: linux-...@lists.infradead.org; linux-arm-ker...@lists.infradead.org; 
> linux-
> ker...@vger.kernel.org; Wu, Josh 
> Subject: Re: [PATCH] mtd: atmel_nand: move the hsmc_clk from nfc node to nand
> node
> 
> Le 17/02/2016 06:40, Wenyou Yang a écrit :
> > From: Josh Wu 
> >
> > For sama5d3, sama5d4 chip, the pmecc becomes a part of HSMC, they need
> > the HSMC clock to be enabled to work.
> > The NFC is a sub feature for current nand driver, it can be disabled.
> > But if HSMC clock is controlled by NFC, so disable NFC will also
> > disable the HSMC clock. then, it will make the PMECC fail to work.
> >
> > So the solution is to move the HSMC clock out of NFC to nand node.
> > When nand driver probed, it will check whether the chip has HSMC, if
> > yes then it will require a HSMC clock.
> >
> > Signed-off-by: Josh Wu 
> > Signed-off-by: Wenyou Yang 
> > ---
> >
> >  .../devicetree/bindings/mtd/atmel-nand.txt |4 +-
> >  drivers/mtd/nand/atmel_nand.c  |   43 
> > +---
> >  2 files changed, 22 insertions(+), 25 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> > b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> > index d53aba9..29bee7c 100644
> > --- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> > +++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> > @@ -15,6 +15,7 @@ Required properties:
> >  - atmel,nand-cmd-offset : offset for the command latch.
> >  - #address-cells, #size-cells : Must be present if the device has sub-nodes
> >representing partitions.
> > +- clocks: phandle to the peripheral clock
> >
> >  - gpios : specifies the gpio pins to control the NAND device. detect is an
> >optional gpio and may be set to 0 if not present.
> > @@ -43,7 +44,6 @@ Required properties:
> >  - reg : should specify the address and size used for NFC command registers,
> >  NFC registers and NFC SRAM. NFC SRAM address and size can be
> absent
> >  if don't want to use it.
> > -- clocks: phandle to the peripheral clock  Optional properties:
> >  - atmel,write-by-sram: boolean to enable NFC write by SRAM.
> >
> > @@ -100,13 +100,13 @@ nand0: nand@4000 {
> > compatible = "atmel,at91rm9200-nand";
> > #address-cells = <1>;
> > #size-cells = <1>;
> > +   clocks = <_clk>
> > ranges;
> >  ...
> >  nfc@7000 {
> > compatible = "atmel,sama5d3-nfc";
> > #address-cells = <1>;
> > #size-cells = <1>;
> > -   clocks = <_clk>
> > reg = <
> > 0x7000 0x1000   /* NFC Command
> Registers */
> > 0xc000 0x0070   /* NFC HSMC regs */
> > diff --git a/drivers/mtd/nand/atmel_nand.c
> > b/drivers/mtd/nand/atmel_nand.c index 20cbaab..a1f4ad2 100644
> > --- a/drivers/mtd/nand/atmel_nand.c
> > +++ b/drivers/mtd/nand/atmel_nand.c
> > @@ -66,6 +66,7 @@ module_param(on_flash_bbt, int, 0);  struct
> > atmel_nand_caps {
> > bool pmecc_correct_erase_page;
> > uint8_t pmecc_max_correction;
> > +   bool has_hsmc_clk;
> >  };
> >
> >  struct atmel_nand_nfc_caps {
> > @@ -106,8 +107,6 @@ struct atmel_nfc {
> > booluse_nfc_sram;
> > boolwrite_by_sram;
> >
> > -   struct clk  *clk;
> > -
> > boolis_initialized;
> > struct completion   comp_ready;
> > struct completion   comp_cmd_done;
> > @@ -132,6 +131,7 @@ struct atmel_nand_host {
> > struct dma_chan *dma_chan;
> >
> > struct atmel_nfc*nfc;
> > +   struct clk  *clk;
> >
> > const struct atmel_nand_caps*caps;
> > boolhas_pmecc;
> > @@ -2157,6 +2157,19 @@ static int atmel_nand_probe(struct platform_device
> *pdev)
> > nand_chip->IO_ADDR_R = host->io_base;
> > nand_chip->IO_ADDR_W = host->io_base;
> >
> > +   if (host->caps->has_hsmc_clk) {
> > +   host->clk = devm_clk_get(>dev, NULL);
> > +   if (IS_ERR(host->clk)) {
> > +   dev_err(>dev, "HSMC clock is missing, update
> your Device Tree");
> > +   res = PTR_ERR(host->clk);
> > +   goto err_nand_ioremap;
> > +   }
> > +
> > +   res = clk_prepare_enable(host->clk);
> > +   if (res)
> > +   goto err_nand_ioremap;
> > +   }
> > +
> > if (nand_nfc.is_initialized) {
> > /* NFC driver is probed and initialized */
> > host->nfc = _nfc;
> > @@ -2321,6 +2334,9 @@ static int atmel_nand_remove(struct platform_device
> *pdev)
> > if (host->dma_chan)
> > dma_release_channel(host->dma_chan);
> >
> > +   if (!IS_ERR(host->clk))
> > +   clk_disable_unprepare(host->clk);
> > +
> > 

Re: [PATCH v4 5/8] [Media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver

[李務誠]

On Thu, Feb 4, 2016 at 7:35 PM, Tiffany Lin  wrote:
> From: Andrew-CT Chen 
>
> Add v4l2 layer encoder driver for MT8173
>
> Signed-off-by: Tiffany Lin 
> ---
>  drivers/media/platform/Kconfig |   11 +
>  drivers/media/platform/Makefile|2 +
>  drivers/media/platform/mtk-vcodec/Makefile |8 +
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h |  388 ++
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 1380 
> 
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h |   46 +
>  .../media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c |  476 +++
>  .../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c  |  132 ++
>  .../media/platform/mtk-vcodec/mtk_vcodec_intr.c|  102 ++
>  .../media/platform/mtk-vcodec/mtk_vcodec_intr.h|   29 +
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_pm.h  |   26 +
>  .../media/platform/mtk-vcodec/mtk_vcodec_util.c|  106 ++
>  .../media/platform/mtk-vcodec/mtk_vcodec_util.h|   85 ++
>  drivers/media/platform/mtk-vcodec/venc_drv_base.h  |   62 +
>  drivers/media/platform/mtk-vcodec/venc_drv_if.c|  100 ++
>  drivers/media/platform/mtk-vcodec/venc_drv_if.h|  175 +++
>  drivers/media/platform/mtk-vcodec/venc_ipi_msg.h   |  212 +++
>  include/uapi/linux/v4l2-controls.h |4 +
>  18 files changed, 3344 insertions(+)
>  create mode 100644 drivers/media/platform/mtk-vcodec/Makefile
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_pm.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_base.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/venc_ipi_msg.h
>  mode change 100644 => 100755 include/uapi/linux/v4l2-controls.h
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index ba812d6..3e831c5 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -157,6 +157,17 @@ config VIDEO_MEDIATEK_VPU
> codec embedded in new Mediatek's SOCs. It is able
> to handle video decoding/encoding in a range of formats.
>
> +config VIDEO_MEDIATEK_VCODEC
> +tristate "Mediatek Video Codec driver"
> +depends on VIDEO_DEV && VIDEO_V4L2
> +depends on ARCH_MEDIATEK || COMPILE_TEST
> +select VIDEOBUF2_DMA_CONTIG
> +select V4L2_MEM2MEM_DEV
> +select MEDIATEK_VPU
> +default n
> +---help---
> +Mediatek video codec driver for V4L2
> +
>  config VIDEO_MEM2MEM_DEINTERLACE
> tristate "Deinterlace support"
> depends on VIDEO_DEV && VIDEO_V4L2 && DMA_ENGINE
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index e5b19c6..510e06b 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -57,3 +57,5 @@ obj-$(CONFIG_VIDEO_XILINX)+= xilinx/
>  ccflags-y += -I$(srctree)/drivers/media/i2c
>
>  obj-$(CONFIG_VIDEO_MEDIATEK_VPU)   += mtk-vpu/
> +
> +obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC)+= mtk-vcodec/
> diff --git a/drivers/media/platform/mtk-vcodec/Makefile 
> b/drivers/media/platform/mtk-vcodec/Makefile
> new file mode 100644
> index 000..ce38689
> --- /dev/null
> +++ b/drivers/media/platform/mtk-vcodec/Makefile
> @@ -0,0 +1,8 @@
> +obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk_vcodec_intr.o \
> +  mtk_vcodec_util.o \
> +  mtk_vcodec_enc_drv.o \
> +  mtk_vcodec_enc.o \
> +  mtk_vcodec_enc_pm.o \
> +  venc_drv_if.o
> +
> +ccflags-y += -I$(srctree)/drivers/media/platform/mtk-vpu
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h 
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> new file mode 100644
> index 000..9da2818
> --- /dev/null
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> @@ -0,0 +1,388 @@
> +/*
> +* Copyright (c) 2015 MediaTek Inc.
> +* Author: PC Chen 
> +* Tiffany Lin 

Re: [PATCH v4 5/8] [Media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver

[李務誠]

On Thu, Feb 4, 2016 at 7:35 PM, Tiffany Lin  wrote:
> From: Andrew-CT Chen 
>
> Add v4l2 layer encoder driver for MT8173
>
> Signed-off-by: Tiffany Lin 
> ---
>  drivers/media/platform/Kconfig |   11 +
>  drivers/media/platform/Makefile|2 +
>  drivers/media/platform/mtk-vcodec/Makefile |8 +
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h |  388 ++
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 1380 
> 
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h |   46 +
>  .../media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c |  476 +++
>  .../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c  |  132 ++
>  .../media/platform/mtk-vcodec/mtk_vcodec_intr.c|  102 ++
>  .../media/platform/mtk-vcodec/mtk_vcodec_intr.h|   29 +
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_pm.h  |   26 +
>  .../media/platform/mtk-vcodec/mtk_vcodec_util.c|  106 ++
>  .../media/platform/mtk-vcodec/mtk_vcodec_util.h|   85 ++
>  drivers/media/platform/mtk-vcodec/venc_drv_base.h  |   62 +
>  drivers/media/platform/mtk-vcodec/venc_drv_if.c|  100 ++
>  drivers/media/platform/mtk-vcodec/venc_drv_if.h|  175 +++
>  drivers/media/platform/mtk-vcodec/venc_ipi_msg.h   |  212 +++
>  include/uapi/linux/v4l2-controls.h |4 +
>  18 files changed, 3344 insertions(+)
>  create mode 100644 drivers/media/platform/mtk-vcodec/Makefile
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_pm.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_base.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/venc_ipi_msg.h
>  mode change 100644 => 100755 include/uapi/linux/v4l2-controls.h
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index ba812d6..3e831c5 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -157,6 +157,17 @@ config VIDEO_MEDIATEK_VPU
> codec embedded in new Mediatek's SOCs. It is able
> to handle video decoding/encoding in a range of formats.
>
> +config VIDEO_MEDIATEK_VCODEC
> +tristate "Mediatek Video Codec driver"
> +depends on VIDEO_DEV && VIDEO_V4L2
> +depends on ARCH_MEDIATEK || COMPILE_TEST
> +select VIDEOBUF2_DMA_CONTIG
> +select V4L2_MEM2MEM_DEV
> +select MEDIATEK_VPU
> +default n
> +---help---
> +Mediatek video codec driver for V4L2
> +
>  config VIDEO_MEM2MEM_DEINTERLACE
> tristate "Deinterlace support"
> depends on VIDEO_DEV && VIDEO_V4L2 && DMA_ENGINE
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index e5b19c6..510e06b 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -57,3 +57,5 @@ obj-$(CONFIG_VIDEO_XILINX)+= xilinx/
>  ccflags-y += -I$(srctree)/drivers/media/i2c
>
>  obj-$(CONFIG_VIDEO_MEDIATEK_VPU)   += mtk-vpu/
> +
> +obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC)+= mtk-vcodec/
> diff --git a/drivers/media/platform/mtk-vcodec/Makefile 
> b/drivers/media/platform/mtk-vcodec/Makefile
> new file mode 100644
> index 000..ce38689
> --- /dev/null
> +++ b/drivers/media/platform/mtk-vcodec/Makefile
> @@ -0,0 +1,8 @@
> +obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk_vcodec_intr.o \
> +  mtk_vcodec_util.o \
> +  mtk_vcodec_enc_drv.o \
> +  mtk_vcodec_enc.o \
> +  mtk_vcodec_enc_pm.o \
> +  venc_drv_if.o
> +
> +ccflags-y += -I$(srctree)/drivers/media/platform/mtk-vpu
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h 
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> new file mode 100644
> index 000..9da2818
> --- /dev/null
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> @@ -0,0 +1,388 @@
> +/*
> +* Copyright (c) 2015 MediaTek Inc.
> +* Author: PC Chen 
> +* Tiffany Lin 
> +*
> +* This program is free software; you can redistribute it and/or modify
> +* it under the terms of the GNU 

RE: [PATCH v3 00/11] KVM: x86: track guest page access

[Tian, Kevin]

> From: Song, Jike
> Sent: Tuesday, February 23, 2016 11:02 AM
> 
> +Kevin
> 
> On 02/22/2016 06:05 PM, Xiao Guangrong wrote:
> >
> > On 02/19/2016 08:00 PM, Paolo Bonzini wrote:
> >>
> >> I still have a doubt: how are you going to handle invalidation of GPU
> >> shadow page tables if a device (emulated in QEMU or even vhost) does DMA
> >> to the PPGTT?
> >
> > I think Jike is the better one to answer this question, Jike, could you
> > please clarify it? :)
> >
> 
> Sure :)
> 
> Actually in guest PPGTT is manipulated by CPU rather than GPU. The
> PPGTT page table itself are plain memory, composed & modified by the
> GPU driver, i.e. by CPU in Non-Root mode.
> 
> Given that, we write-protected guest PPGTT, when VM writes PPGTT, EPT
> violation rather than DMA fault happens.

'DMA to PPGTT' is NOT SUPPORTED on our vGPU device model. Today
Intel gfx driver doesn't use this method, and we explicitly list it as a
guest driver requirement to support a vGPU. If a malicious driver does 
program DMA to modify PPGTT, it can only modify guest PPGTT instead
of shadow PPGTT (being guest invisible). So there is no security issue 
either.

> 
> >> Generally, this was the reason to keep stuff out of KVM
> >> and instead hook into the kernel mm subsystem (as with userfaultfd).
> >
> > We considered it carefully but this way can not satisfy KVMGT's 
> > requirements.
> > The reasons i explained in the old thread 
> > (https://lkml.org/lkml/2015/12/1/516)
> > are:
> >
> > "For the performance, shadow GPU is performance critical and requires
> > frequently being switched, it is not good to handle it in userspace. And
> > windows guest has many GPU tables and updates it frequently, that means,
> > we need to write protect huge number of pages which are single page based,
> > I am afraid userfaultfd can not handle this case efficiently.

Yes, performance is the main concern. 

Paolo, we explained the reason for in-kernel emulation to you earlier with
your understanding:

> > It's definitely a fast path, e.g. command submission, shadow GPU page
> > table, etc. which are all in performance critical path. Another reason is
> > the I/O access frequency, which could be up to 100k/s for some gfx workload.
> > It's important to shorten the emulation path which can help performance
> > a lot. That's the major reason why we keep vGPU device model in the
> > kernel (will merged into i915 driver)
> 
> Ok, thanks---writing numbers down always helps.  MMIO to userspace costs
> 5000 clock cycles on the latest QEMU and processor (and does not need
> the "big QEMU lock" anymore), but still 100k/s is a ~50 clock cycle
> difference and approximately 15% host CPU usage.

(I believe ~50 should be ~500M clock cycle above)

> >
> > For the functionality, userfaultfd can not fill the need of shadow page
> > because:
> > - the page is keeping readonly, userfaultfd can not fix the fault and let
> > the vcpu progress (write access causes writeable gup).
> >
> > - the access need to be emulated, however, userfaultfd/kernel does not have
> > the ability to emulate the access as the access is trigged by guest, the
> > instruction info is stored in VMCS so that only KVM can emulate it.
> >
> > - shadow page needs to be notified after the emulation is finished as it
> > should know the new data written to the page to update its page 
> > hierarchy.
> > (some hardwares lack the 'retry' ability so the shadow page table need 
> > to
> >  reflect the table in guest at any time). "
> >
> > Any idea?
> >
> 

Thanks Guangrong for investigating the possibility.

Based on earlier explanation, we hope KVM community can re-think the
necessity of support in-kernel emulation for KVMGT. Same framework
might be extended to other type of I/O devices using similar mediated
pass-through concept in the future, which has device model tightly
integrated with native device driver for efficiency and simplicity purpose.

Actually a related open when discussing KVMGT/VFIO integration.
There are 7 total services required to support in-kernel emulation, which 
can be categorize into two groups:

a) services to connect vGPU with VM, which are essentially what a device
driver is doing (so VFIO can fit here), including:
1) Selectively pass-through a region to a VM
2) Trap-and-emulate a region
3) Inject a virtual interrupt
4) Pin/unpin guest memory
5) GPA->IOVA/HVA translation (as a side-effect)

b) services to support device emulation, which gonna be hypervisor
specific, including:
6) Map/unmap guest memory
7) Write-protect a guest memory page

We're working with VFIO community to add support of category a),
but there is still a gap in category b). This patch series can address
the requirement of 7). For 6) it's straightforward for KVM. We may
introduce a new file in KVM to wrap them together for in-kernel
emulation, but need an agreement from community first on this
direction. :-)

Thanks

RE: [PATCH v3 00/11] KVM: x86: track guest page access

[Tian, Kevin]

> From: Song, Jike
> Sent: Tuesday, February 23, 2016 11:02 AM
> 
> +Kevin
> 
> On 02/22/2016 06:05 PM, Xiao Guangrong wrote:
> >
> > On 02/19/2016 08:00 PM, Paolo Bonzini wrote:
> >>
> >> I still have a doubt: how are you going to handle invalidation of GPU
> >> shadow page tables if a device (emulated in QEMU or even vhost) does DMA
> >> to the PPGTT?
> >
> > I think Jike is the better one to answer this question, Jike, could you
> > please clarify it? :)
> >
> 
> Sure :)
> 
> Actually in guest PPGTT is manipulated by CPU rather than GPU. The
> PPGTT page table itself are plain memory, composed & modified by the
> GPU driver, i.e. by CPU in Non-Root mode.
> 
> Given that, we write-protected guest PPGTT, when VM writes PPGTT, EPT
> violation rather than DMA fault happens.

'DMA to PPGTT' is NOT SUPPORTED on our vGPU device model. Today
Intel gfx driver doesn't use this method, and we explicitly list it as a
guest driver requirement to support a vGPU. If a malicious driver does 
program DMA to modify PPGTT, it can only modify guest PPGTT instead
of shadow PPGTT (being guest invisible). So there is no security issue 
either.

> 
> >> Generally, this was the reason to keep stuff out of KVM
> >> and instead hook into the kernel mm subsystem (as with userfaultfd).
> >
> > We considered it carefully but this way can not satisfy KVMGT's 
> > requirements.
> > The reasons i explained in the old thread 
> > (https://lkml.org/lkml/2015/12/1/516)
> > are:
> >
> > "For the performance, shadow GPU is performance critical and requires
> > frequently being switched, it is not good to handle it in userspace. And
> > windows guest has many GPU tables and updates it frequently, that means,
> > we need to write protect huge number of pages which are single page based,
> > I am afraid userfaultfd can not handle this case efficiently.

Yes, performance is the main concern. 

Paolo, we explained the reason for in-kernel emulation to you earlier with
your understanding:

> > It's definitely a fast path, e.g. command submission, shadow GPU page
> > table, etc. which are all in performance critical path. Another reason is
> > the I/O access frequency, which could be up to 100k/s for some gfx workload.
> > It's important to shorten the emulation path which can help performance
> > a lot. That's the major reason why we keep vGPU device model in the
> > kernel (will merged into i915 driver)
> 
> Ok, thanks---writing numbers down always helps.  MMIO to userspace costs
> 5000 clock cycles on the latest QEMU and processor (and does not need
> the "big QEMU lock" anymore), but still 100k/s is a ~50 clock cycle
> difference and approximately 15% host CPU usage.

(I believe ~50 should be ~500M clock cycle above)

> >
> > For the functionality, userfaultfd can not fill the need of shadow page
> > because:
> > - the page is keeping readonly, userfaultfd can not fix the fault and let
> > the vcpu progress (write access causes writeable gup).
> >
> > - the access need to be emulated, however, userfaultfd/kernel does not have
> > the ability to emulate the access as the access is trigged by guest, the
> > instruction info is stored in VMCS so that only KVM can emulate it.
> >
> > - shadow page needs to be notified after the emulation is finished as it
> > should know the new data written to the page to update its page 
> > hierarchy.
> > (some hardwares lack the 'retry' ability so the shadow page table need 
> > to
> >  reflect the table in guest at any time). "
> >
> > Any idea?
> >
> 

Thanks Guangrong for investigating the possibility.

Based on earlier explanation, we hope KVM community can re-think the
necessity of support in-kernel emulation for KVMGT. Same framework
might be extended to other type of I/O devices using similar mediated
pass-through concept in the future, which has device model tightly
integrated with native device driver for efficiency and simplicity purpose.

Actually a related open when discussing KVMGT/VFIO integration.
There are 7 total services required to support in-kernel emulation, which 
can be categorize into two groups:

a) services to connect vGPU with VM, which are essentially what a device
driver is doing (so VFIO can fit here), including:
1) Selectively pass-through a region to a VM
2) Trap-and-emulate a region
3) Inject a virtual interrupt
4) Pin/unpin guest memory
5) GPA->IOVA/HVA translation (as a side-effect)

b) services to support device emulation, which gonna be hypervisor
specific, including:
6) Map/unmap guest memory
7) Write-protect a guest memory page

We're working with VFIO community to add support of category a),
but there is still a gap in category b). This patch series can address
the requirement of 7). For 6) it's straightforward for KVM. We may
introduce a new file in KVM to wrap them together for in-kernel
emulation, but need an agreement from community first on this
direction. :-)

Thanks

Re: [PATCH] net: jme: fix suspend/resume on JMC260

[Diego Viola]

On Tue, Feb 23, 2016 at 2:11 AM, Diego Viola  wrote:
> On Tue, Feb 23, 2016 at 1:42 AM, David Miller  wrote:
>> From: Diego Viola 
>> Date: Mon, 22 Feb 2016 22:58:48 -0300
>>
>>> On Mon, Feb 22, 2016 at 10:46 PM, Fabio Estevam  wrote:
 On Mon, Feb 22, 2016 at 9:32 PM, Diego Viola  wrote:
> Signed-off-by: Diego Viola 

 You should write a commit log.
>>>
>>> I thought about including the link to my bug report:
>>> https://bugzilla.kernel.org/show_bug.cgi?id=112351
>>>
>>> What else would you suggest I add to the commit message?
>>
>> The commit message is where you describe the change you are making.
>>
>> This includes exactly what you are fixing, how you are doing it, and why
>> you are doing it that way.
>>
>> Empty commit log messages are %99.9 of the time completely
>> inappropriate.
>
> David,
>
> I understand and appreciate your advice, thanks.
>
> However, please consider that I'm not a kernel developer, so I don't
> understand much or anything about how this driver works internally,
> this is why I came here to report about problem in the first place.
>
> All I can tell you for certain is that this change makes my
> suspend/resume work and it doesn't hang anymore while resuming from
> suspend.
>
> I apologize for the empty commit message and for not being able to
> explain things deeper, but Pavel Machek is the person who suggested I
> make this change in the code, so maybe he can provide some help?
>
> Diego

I will try sending a V2 patch again with a proper commit message, sorry.

Diego

Re: [PATCH] net: jme: fix suspend/resume on JMC260

[Diego Viola]

On Tue, Feb 23, 2016 at 2:11 AM, Diego Viola  wrote:
> On Tue, Feb 23, 2016 at 1:42 AM, David Miller  wrote:
>> From: Diego Viola 
>> Date: Mon, 22 Feb 2016 22:58:48 -0300
>>
>>> On Mon, Feb 22, 2016 at 10:46 PM, Fabio Estevam  wrote:
 On Mon, Feb 22, 2016 at 9:32 PM, Diego Viola  wrote:
> Signed-off-by: Diego Viola 

 You should write a commit log.
>>>
>>> I thought about including the link to my bug report:
>>> https://bugzilla.kernel.org/show_bug.cgi?id=112351
>>>
>>> What else would you suggest I add to the commit message?
>>
>> The commit message is where you describe the change you are making.
>>
>> This includes exactly what you are fixing, how you are doing it, and why
>> you are doing it that way.
>>
>> Empty commit log messages are %99.9 of the time completely
>> inappropriate.
>
> David,
>
> I understand and appreciate your advice, thanks.
>
> However, please consider that I'm not a kernel developer, so I don't
> understand much or anything about how this driver works internally,
> this is why I came here to report about problem in the first place.
>
> All I can tell you for certain is that this change makes my
> suspend/resume work and it doesn't hang anymore while resuming from
> suspend.
>
> I apologize for the empty commit message and for not being able to
> explain things deeper, but Pavel Machek is the person who suggested I
> make this change in the code, so maybe he can provide some help?
>
> Diego

I will try sending a V2 patch again with a proper commit message, sorry.

Diego

Re: [PATCH V4 5/6] perf/amd/iommu: Enable support for multiple IOMMUs

[Alex Williamson]

On Tue, 23 Feb 2016 12:12:42 +0700
Suravee Suthikulpanit  wrote:

> Hi
> 
> On 02/22/2016 09:07 PM, Peter Zijlstra wrote:
> > On Mon, Feb 22, 2016 at 03:00:31PM +0700, Suravee Suthikulpanit wrote:  
> >>> So I really don't have time to review new muck while I'm hunting perf
> >>> core fail, but Boris made me look at this.
> >>>
> >>> This is crazy, if you have multiple IOMMUs then create an event per
> >>> IOMMU, do _NOT_ fold them all into a single event.  
> >>
> >> These are system-wide events, which are programmed on every IOMMU the same
> >> way. I am not sure what you meant by creating an event per IOMMU. Do you
> >> mean I should create internal per-IOMMU struct perf_event for each event?  
> >
> > No, I meant to expose each IOMMU individually to userspace, as a
> > separate device.
> >
> > Is there never a case to profile just one of the IOMMUs ?
> >  
> 
> I see. That's definitely doable and simpler to implement.
> 
> I was not sure if making users specify the IOMMU instance (e.g. 
> amd_iommu_0/ , amd_iommu_1/, ) would be too 
> tedious. However, this would actually give users better control of the 
> performance events, which is a good trade-off. I think it is acceptable.
> 
> I'll make the change and send this out in V5.

We already expose individual IOMMU hardware units in /sys/class/iommu/,
you might consider trying to match the names there for the convenience
of the user.  Looks like we use ivhd%d for AMD.  Thanks,

Alex

Re: [PATCH V4 5/6] perf/amd/iommu: Enable support for multiple IOMMUs

[Alex Williamson]

On Tue, 23 Feb 2016 12:12:42 +0700
Suravee Suthikulpanit  wrote:

> Hi
> 
> On 02/22/2016 09:07 PM, Peter Zijlstra wrote:
> > On Mon, Feb 22, 2016 at 03:00:31PM +0700, Suravee Suthikulpanit wrote:  
> >>> So I really don't have time to review new muck while I'm hunting perf
> >>> core fail, but Boris made me look at this.
> >>>
> >>> This is crazy, if you have multiple IOMMUs then create an event per
> >>> IOMMU, do _NOT_ fold them all into a single event.  
> >>
> >> These are system-wide events, which are programmed on every IOMMU the same
> >> way. I am not sure what you meant by creating an event per IOMMU. Do you
> >> mean I should create internal per-IOMMU struct perf_event for each event?  
> >
> > No, I meant to expose each IOMMU individually to userspace, as a
> > separate device.
> >
> > Is there never a case to profile just one of the IOMMUs ?
> >  
> 
> I see. That's definitely doable and simpler to implement.
> 
> I was not sure if making users specify the IOMMU instance (e.g. 
> amd_iommu_0/ , amd_iommu_1/, ) would be too 
> tedious. However, this would actually give users better control of the 
> performance events, which is a good trade-off. I think it is acceptable.
> 
> I'll make the change and send this out in V5.

We already expose individual IOMMU hardware units in /sys/class/iommu/,
you might consider trying to match the names there for the convenience
of the user.  Looks like we use ivhd%d for AMD.  Thanks,

Alex

Re: Interesting csd deadlock on ARC

[Vineet Gupta]

On Friday 19 February 2016 12:17 PM, Vineet Gupta wrote:
> Hi Peter,
> 
> I've been debugging a csd_lock_wait() deadlock on SMP+PREEMPT ARC HS38x2 and 
> it
> turned out to be lot more interesting than I'd hoped for. This is stock v4.4
> 
> Trouble starts with an IPI to self which doesn't get delivered as the 
> inter-core
> interrupt providing h/w is not capable of IPI to self (which I found as part 
> of
> debugging this). Subsequent IPIs from other cores to this core get elided as 
> well
> due to the IPI coalescing optimization in arch/arc/kernel/smp.c: 
> ipi_send_msg_one()
> 
> There are ways to use a different h/w mechanism to solve the trigger issue 
> and I'd
> hoped to just implement arch_irq_work_raise(). But the trouble is the call 
> stack
> for this issue: IPI to self is triggered from
> 
> sys_sched_setscheduler
>__balance_callback
>pull_rt_task
>  irq_work_queue_on  <-- called with @cpu == self
> 
> Looking into irq_work.c, irq_work_queue() is what is semantically needed,
> specifically arch_irq_work_raise() will not be called, which means I need
> arch_send_call_function_single_ipi() to be able to IPI to self cpu also. Is 
> that
> expected from arch code

What I actually meant was is it OK for irq_work_queue_on() to be called locally
(is this a sched bug/optimization(. Further if it is OK to be called, does it 
need
to do behave more like irq_work_queue() i.e. call arch_irq_work_raise() or
arch_send_call_function_single_ipi() is expected to handle sending IPI to self !

> 
> Just wanted to understand before writing patches...
> 
> Test case triggering is harmless looking LTP: trace_sched -c 1
> It is kind of scheduler fizzer as it triggers a whole bunch of sched activity.
> 
> Thx,
> -Vineet
> 

Re: Interesting csd deadlock on ARC

[Vineet Gupta]

On Friday 19 February 2016 12:17 PM, Vineet Gupta wrote:
> Hi Peter,
> 
> I've been debugging a csd_lock_wait() deadlock on SMP+PREEMPT ARC HS38x2 and 
> it
> turned out to be lot more interesting than I'd hoped for. This is stock v4.4
> 
> Trouble starts with an IPI to self which doesn't get delivered as the 
> inter-core
> interrupt providing h/w is not capable of IPI to self (which I found as part 
> of
> debugging this). Subsequent IPIs from other cores to this core get elided as 
> well
> due to the IPI coalescing optimization in arch/arc/kernel/smp.c: 
> ipi_send_msg_one()
> 
> There are ways to use a different h/w mechanism to solve the trigger issue 
> and I'd
> hoped to just implement arch_irq_work_raise(). But the trouble is the call 
> stack
> for this issue: IPI to self is triggered from
> 
> sys_sched_setscheduler
>__balance_callback
>pull_rt_task
>  irq_work_queue_on  <-- called with @cpu == self
> 
> Looking into irq_work.c, irq_work_queue() is what is semantically needed,
> specifically arch_irq_work_raise() will not be called, which means I need
> arch_send_call_function_single_ipi() to be able to IPI to self cpu also. Is 
> that
> expected from arch code

What I actually meant was is it OK for irq_work_queue_on() to be called locally
(is this a sched bug/optimization(. Further if it is OK to be called, does it 
need
to do behave more like irq_work_queue() i.e. call arch_irq_work_raise() or
arch_send_call_function_single_ipi() is expected to handle sending IPI to self !

> 
> Just wanted to understand before writing patches...
> 
> Test case triggering is harmless looking LTP: trace_sched -c 1
> It is kind of scheduler fizzer as it triggers a whole bunch of sched activity.
> 
> Thx,
> -Vineet
> 

Re: [PATCH V4 5/6] perf/amd/iommu: Enable support for multiple IOMMUs

[Suravee Suthikulpanit]

Hi

On 02/22/2016 09:07 PM, Peter Zijlstra wrote:

On Mon, Feb 22, 2016 at 03:00:31PM +0700, Suravee Suthikulpanit wrote:

So I really don't have time to review new muck while I'm hunting perf
core fail, but Boris made me look at this.

This is crazy, if you have multiple IOMMUs then create an event per
IOMMU, do _NOT_ fold them all into a single event.


These are system-wide events, which are programmed on every IOMMU the same
way. I am not sure what you meant by creating an event per IOMMU. Do you
mean I should create internal per-IOMMU struct perf_event for each event?


No, I meant to expose each IOMMU individually to userspace, as a
separate device.

Is there never a case to profile just one of the IOMMUs ?



I see. That's definitely doable and simpler to implement.

I was not sure if making users specify the IOMMU instance (e.g. 
amd_iommu_0/ , amd_iommu_1/, ) would be too 
tedious. However, this would actually give users better control of the 
performance events, which is a good trade-off. I think it is acceptable.


I'll make the change and send this out in V5.

Thanks,
Suravee

Re: [PATCH V4 5/6] perf/amd/iommu: Enable support for multiple IOMMUs

[Suravee Suthikulpanit]

Hi

On 02/22/2016 09:07 PM, Peter Zijlstra wrote:

On Mon, Feb 22, 2016 at 03:00:31PM +0700, Suravee Suthikulpanit wrote:

So I really don't have time to review new muck while I'm hunting perf
core fail, but Boris made me look at this.

This is crazy, if you have multiple IOMMUs then create an event per
IOMMU, do _NOT_ fold them all into a single event.


These are system-wide events, which are programmed on every IOMMU the same
way. I am not sure what you meant by creating an event per IOMMU. Do you
mean I should create internal per-IOMMU struct perf_event for each event?


No, I meant to expose each IOMMU individually to userspace, as a
separate device.

Is there never a case to profile just one of the IOMMUs ?



I see. That's definitely doable and simpler to implement.

I was not sure if making users specify the IOMMU instance (e.g. 
amd_iommu_0/ , amd_iommu_1/, ) would be too 
tedious. However, this would actually give users better control of the 
performance events, which is a good trade-off. I think it is acceptable.


I'll make the change and send this out in V5.

Thanks,
Suravee

Re: [PATCH] net: jme: fix suspend/resume on JMC260

[Diego Viola]

On Tue, Feb 23, 2016 at 1:42 AM, David Miller  wrote:
> From: Diego Viola 
> Date: Mon, 22 Feb 2016 22:58:48 -0300
>
>> On Mon, Feb 22, 2016 at 10:46 PM, Fabio Estevam  wrote:
>>> On Mon, Feb 22, 2016 at 9:32 PM, Diego Viola  wrote:
 Signed-off-by: Diego Viola 
>>>
>>> You should write a commit log.
>>
>> I thought about including the link to my bug report:
>> https://bugzilla.kernel.org/show_bug.cgi?id=112351
>>
>> What else would you suggest I add to the commit message?
>
> The commit message is where you describe the change you are making.
>
> This includes exactly what you are fixing, how you are doing it, and why
> you are doing it that way.
>
> Empty commit log messages are %99.9 of the time completely
> inappropriate.

David,

I understand and appreciate your advice, thanks.

However, please consider that I'm not a kernel developer, so I don't
understand much or anything about how this driver works internally,
this is why I came here to report about problem in the first place.

All I can tell you for certain is that this change makes my
suspend/resume work and it doesn't hang anymore while resuming from
suspend.

I apologize for the empty commit message and for not being able to
explain things deeper, but Pavel Machek is the person who suggested I
make this change in the code, so maybe he can provide some help?

Diego

Re: [PATCH] net: jme: fix suspend/resume on JMC260

[Diego Viola]

On Tue, Feb 23, 2016 at 1:42 AM, David Miller  wrote:
> From: Diego Viola 
> Date: Mon, 22 Feb 2016 22:58:48 -0300
>
>> On Mon, Feb 22, 2016 at 10:46 PM, Fabio Estevam  wrote:
>>> On Mon, Feb 22, 2016 at 9:32 PM, Diego Viola  wrote:
 Signed-off-by: Diego Viola 
>>>
>>> You should write a commit log.
>>
>> I thought about including the link to my bug report:
>> https://bugzilla.kernel.org/show_bug.cgi?id=112351
>>
>> What else would you suggest I add to the commit message?
>
> The commit message is where you describe the change you are making.
>
> This includes exactly what you are fixing, how you are doing it, and why
> you are doing it that way.
>
> Empty commit log messages are %99.9 of the time completely
> inappropriate.

David,

I understand and appreciate your advice, thanks.

However, please consider that I'm not a kernel developer, so I don't
understand much or anything about how this driver works internally,
this is why I came here to report about problem in the first place.

All I can tell you for certain is that this change makes my
suspend/resume work and it doesn't hang anymore while resuming from
suspend.

I apologize for the empty commit message and for not being able to
explain things deeper, but Pavel Machek is the person who suggested I
make this change in the code, so maybe he can provide some help?

Diego

Re: [PATCH] firmware: fw_cfg register offsets on supported architectures only

[Michael S. Tsirkin]

On Mon, Feb 22, 2016 at 04:18:18PM -0500, Gabriel Somlo wrote:
> Refrain from defining default fw_cfg register offsets on
> unsupported architectures -- throw an error instead. If
> QEMU were to add fw_cfg support on additional architectures,
> we should add them to the FW_CFG_SYSFS depends statement in
> drivers/firmware/Kconfig, and provide default values for
> register offsets in drivers/firmware/qemu_fw_cfg.c at that
> time.
> 
> Suggested-by: Michael S. Tsirkin 
> Signed-off-by: Gabriel Somlo 

Acked-by: Michael S. Tsirkin 


> ---
>  drivers/firmware/qemu_fw_cfg.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/firmware/qemu_fw_cfg.c b/drivers/firmware/qemu_fw_cfg.c
> index fedbff5..79f6b7b 100644
> --- a/drivers/firmware/qemu_fw_cfg.c
> +++ b/drivers/firmware/qemu_fw_cfg.c
> @@ -109,9 +109,7 @@ static void fw_cfg_io_cleanup(void)
>  #  define FW_CFG_CTRL_OFF 0x00
>  #  define FW_CFG_DATA_OFF 0x01
>  # else
> -#  warning "QEMU FW_CFG may not be available on this architecture!"
> -#  define FW_CFG_CTRL_OFF 0x00
> -#  define FW_CFG_DATA_OFF 0x01
> +#  error "QEMU FW_CFG not available on this architecture!"
>  # endif
>  #endif
>  
> -- 
> 2.4.3

Re: [PATCH] firmware: fw_cfg register offsets on supported architectures only

[Michael S. Tsirkin]

On Mon, Feb 22, 2016 at 04:18:18PM -0500, Gabriel Somlo wrote:
> Refrain from defining default fw_cfg register offsets on
> unsupported architectures -- throw an error instead. If
> QEMU were to add fw_cfg support on additional architectures,
> we should add them to the FW_CFG_SYSFS depends statement in
> drivers/firmware/Kconfig, and provide default values for
> register offsets in drivers/firmware/qemu_fw_cfg.c at that
> time.
> 
> Suggested-by: Michael S. Tsirkin 
> Signed-off-by: Gabriel Somlo 

Acked-by: Michael S. Tsirkin 


> ---
>  drivers/firmware/qemu_fw_cfg.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/firmware/qemu_fw_cfg.c b/drivers/firmware/qemu_fw_cfg.c
> index fedbff5..79f6b7b 100644
> --- a/drivers/firmware/qemu_fw_cfg.c
> +++ b/drivers/firmware/qemu_fw_cfg.c
> @@ -109,9 +109,7 @@ static void fw_cfg_io_cleanup(void)
>  #  define FW_CFG_CTRL_OFF 0x00
>  #  define FW_CFG_DATA_OFF 0x01
>  # else
> -#  warning "QEMU FW_CFG may not be available on this architecture!"
> -#  define FW_CFG_CTRL_OFF 0x00
> -#  define FW_CFG_DATA_OFF 0x01
> +#  error "QEMU FW_CFG not available on this architecture!"
>  # endif
>  #endif
>  
> -- 
> 2.4.3

Re: [PATCH v8 1/4] firmware: introduce sysfs driver for QEMU's fw_cfg device

[Michael S. Tsirkin]

On Mon, Feb 22, 2016 at 03:26:23PM -0500, Gabriel L. Somlo wrote:
> On Mon, Feb 22, 2016 at 10:14:50PM +0200, Michael S. Tsirkin wrote:
> > On Sun, Feb 21, 2016 at 08:06:17AM -0500, Gabriel L. Somlo wrote:
> > > > > +static void fw_cfg_io_cleanup(void)
> > > > > +{
> > > > > + if (fw_cfg_is_mmio) {
> > > > > + iounmap(fw_cfg_dev_base);
> > > > > + release_mem_region(fw_cfg_p_base, fw_cfg_p_size);
> > > > > + } else {
> > > > > + ioport_unmap(fw_cfg_dev_base);
> > > > > + release_region(fw_cfg_p_base, fw_cfg_p_size);
> > > > > + }
> > > > > +}
> > > > > +
> > > > > +/* arch-specific ctrl & data register offsets are not available in 
> > > > > ACPI, DT */
> > > > 
> > > > So for all arches which support ACPI, I think this driver
> > > > should just rely on ACPI.
> > > 
> > > There was a discussion about that a few versions ago, and IIRC the
> > > conclusion was not to expect the firmware to contend for fw_cfg access
> > > after the guest kernel boots:
> > > 
> > > https://lkml.org/lkml/2015/10/5/283
> > > 
> > 
> > So it looks like NVDIMM at least wants to pass label data to guest -
> > for which fw cfg might be a reasonable choice.
> > 
> > I suspect things changed - fw cfg used to be very slow but we now have
> > DMA interface which makes it useful for a range of applications.

Comment on this? I'm really worried we'll release linux
without a way to access fw cfg from aml.
How about taking acpi lock around all accesses?

> > > (I even had a prototype version doing what you suggested, but per the 
> > > above
> > > reference decided to drop it -- which IMHO is for the better, since 
> > > otherwise
> > > I'd have had to ifdef between ACPI and non-ACPI versions of the driver --
> > > see https://lkml.org/lkml/2015/11/4/534 )
> > 
> > I'm not sure why you have these ifdefs - they are on the host, are they
> > not?
> 
> Think of those as "pseudocode" ifdefs, they're there to distinguish
> between AML that would be generated on MMIO vs. IOPORT systems
> (specifically, arm vs. x86, respectively)
> 
> Some of the AML is the same, but obviously the _CRS, and
> OperationRegion + Field are different, and I wanted to point that out
> somehow :)
> 
> Cheers,
> --Gabriel

You can do ifs as well.

-- 
MST

Re: [PATCH v8 1/4] firmware: introduce sysfs driver for QEMU's fw_cfg device

[Michael S. Tsirkin]

On Mon, Feb 22, 2016 at 03:26:23PM -0500, Gabriel L. Somlo wrote:
> On Mon, Feb 22, 2016 at 10:14:50PM +0200, Michael S. Tsirkin wrote:
> > On Sun, Feb 21, 2016 at 08:06:17AM -0500, Gabriel L. Somlo wrote:
> > > > > +static void fw_cfg_io_cleanup(void)
> > > > > +{
> > > > > + if (fw_cfg_is_mmio) {
> > > > > + iounmap(fw_cfg_dev_base);
> > > > > + release_mem_region(fw_cfg_p_base, fw_cfg_p_size);
> > > > > + } else {
> > > > > + ioport_unmap(fw_cfg_dev_base);
> > > > > + release_region(fw_cfg_p_base, fw_cfg_p_size);
> > > > > + }
> > > > > +}
> > > > > +
> > > > > +/* arch-specific ctrl & data register offsets are not available in 
> > > > > ACPI, DT */
> > > > 
> > > > So for all arches which support ACPI, I think this driver
> > > > should just rely on ACPI.
> > > 
> > > There was a discussion about that a few versions ago, and IIRC the
> > > conclusion was not to expect the firmware to contend for fw_cfg access
> > > after the guest kernel boots:
> > > 
> > > https://lkml.org/lkml/2015/10/5/283
> > > 
> > 
> > So it looks like NVDIMM at least wants to pass label data to guest -
> > for which fw cfg might be a reasonable choice.
> > 
> > I suspect things changed - fw cfg used to be very slow but we now have
> > DMA interface which makes it useful for a range of applications.

Comment on this? I'm really worried we'll release linux
without a way to access fw cfg from aml.
How about taking acpi lock around all accesses?

> > > (I even had a prototype version doing what you suggested, but per the 
> > > above
> > > reference decided to drop it -- which IMHO is for the better, since 
> > > otherwise
> > > I'd have had to ifdef between ACPI and non-ACPI versions of the driver --
> > > see https://lkml.org/lkml/2015/11/4/534 )
> > 
> > I'm not sure why you have these ifdefs - they are on the host, are they
> > not?
> 
> Think of those as "pseudocode" ifdefs, they're there to distinguish
> between AML that would be generated on MMIO vs. IOPORT systems
> (specifically, arm vs. x86, respectively)
> 
> Some of the AML is the same, but obviously the _CRS, and
> OperationRegion + Field are different, and I wanted to point that out
> somehow :)
> 
> Cheers,
> --Gabriel

You can do ifs as well.

-- 
MST

[PATCH 10/10] mtip32xx: Cleanup queued requests after surprise removal

[Asai Thambi SP]

Fail all pending requests after surprise removal of a drive.

misc: Proper handling of resource free in probe failure path.

Signed-off-by: Vignesh Gunasekaran 
Signed-off-by: Selvan Mani 
Signed-off-by: Asai Thambi S P 
---
 drivers/block/mtip32xx/mtip32xx.c |   78 
 1 files changed, 60 insertions(+), 18 deletions(-)

diff --git a/drivers/block/mtip32xx/mtip32xx.c 
b/drivers/block/mtip32xx/mtip32xx.c
index d8410e6..ef23f17 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -173,7 +173,13 @@ static struct mtip_cmd *mtip_get_int_command(struct 
driver_data *dd)
 {
 struct request *rq;
 
+if (mtip_check_surprise_removal(dd->pdev))
+return NULL;
+
 rq = blk_mq_alloc_request(dd->queue, 0, BLK_MQ_REQ_RESERVED);
+if (IS_ERR(rq))
+return NULL;
+
 return blk_mq_rq_to_pdu(rq);
 }
 
@@ -575,6 +581,8 @@ static void mtip_completion(struct mtip_port *port,
 dev_warn(>dd->pdev->dev,
 "Internal command %d completed with TFE\n", tag);
 
+command->comp_func = NULL;
+command->comp_data = NULL;
 complete(waiting);
 }
 
@@ -1044,12 +1052,14 @@ static bool mtip_pause_ncq(struct mtip_port *port,
  *
  * @portPointer to port data structure
  * @timeout Max duration to wait (ms)
+ * @atomic  gfp_t flag to indicate blockable context or not
  *
  * return value
  *0Success
  *-EBUSY  Commands still active
  */
-static int mtip_quiesce_io(struct mtip_port *port, unsigned long timeout)
+static int mtip_quiesce_io(struct mtip_port *port, unsigned long timeout,
+gfp_t atomic)
 {
 unsigned long to;
 unsigned int n;
@@ -1060,16 +1070,21 @@ static int mtip_quiesce_io(struct mtip_port *port, 
unsigned long timeout)
 to = jiffies + msecs_to_jiffies(timeout);
 do {
 if (test_bit(MTIP_PF_SVC_THD_ACTIVE_BIT, >flags) &&
-test_bit(MTIP_PF_ISSUE_CMDS_BIT, >flags)) {
+test_bit(MTIP_PF_ISSUE_CMDS_BIT, >flags) &&
+atomic == GFP_KERNEL) {
 msleep(20);
 continue; /* svc thd is actively issuing commands */
 }
 
-msleep(100);
+if (atomic == GFP_KERNEL)
+msleep(100);
+else {
+cpu_relax();
+udelay(100);
+}
+
 if (mtip_check_surprise_removal(port->dd->pdev))
 goto err_fault;
-if (test_bit(MTIP_DDF_REMOVE_PENDING_BIT, >dd->dd_flag))
-goto err_fault;
 
 /*
  * Ignore s_active bit 0 of array element 0.
@@ -1131,6 +1146,10 @@ static int mtip_exec_internal_command(struct mtip_port 
*port,
 }
 
 int_cmd = mtip_get_int_command(dd);
+if (!int_cmd) {
+dbg_printk(MTIP_DRV_NAME "Unable to allocate tag for PIO cmd\n");
+return -EFAULT;
+}
 
 set_bit(MTIP_PF_IC_ACTIVE_BIT, >flags);
 
@@ -1158,7 +1177,7 @@ static int mtip_exec_internal_command(struct mtip_port 
*port,
 if (fis->command != ATA_CMD_STANDBYNOW1) {
 /* wait for io to complete if non atomic */
 if (mtip_quiesce_io(port,
-MTIP_QUIESCE_IO_TIMEOUT_MS) < 0) {
+MTIP_QUIESCE_IO_TIMEOUT_MS, atomic) < 0) {
 dev_warn(>pdev->dev,
 "Failed to quiesce IO\n");
 
@@ -3416,10 +3435,6 @@ static int mtip_standby_drive(struct driver_data *dd)
  */
 static int mtip_hw_exit(struct driver_data *dd)
 {
-/*
- * Send standby immediate (E0h) to the drive so that it
- * saves its state.
- */
 if (!dd->sr) {
 /* de-initialize the port. */
 mtip_deinit_port(dd->port);
@@ -4036,7 +4051,7 @@ static int mtip_block_initialize(struct driver_data *dd)
 if (rv) {
 dev_err(>pdev->dev,
 "Unable to allocate request queue\n");
-goto block_queue_alloc_init_error;
+goto block_queue_alloc_tag_error;
 }
 
 /* Allocate the request queue. */
@@ -4149,8 +4164,9 @@ kthread_run_error:
 read_capacity_error:
 init_hw_cmds_error:
 blk_cleanup_queue(dd->queue);
-blk_mq_free_tag_set(>tags);
 block_queue_alloc_init_error:
+blk_mq_free_tag_set(>tags);
+block_queue_alloc_tag_error:
 mtip_hw_debugfs_exit(dd);
 disk_index_error:
 spin_lock(_index_lock);
@@ -4167,6 +4183,22 @@ protocol_init_error:
 return rv;
 }
 
+static void mtip_no_dev_cleanup(struct request *rq, void *data, bool reserv)
+{
+struct driver_data *dd = (struct driver_data *)data;
+struct mtip_cmd *cmd;
+
+if (likely(!reserv))
+blk_mq_complete_request(rq, -ENODEV);
+else if (test_bit(MTIP_PF_IC_ACTIVE_BIT, >port->flags)) {
+
+cmd = mtip_cmd_from_tag(dd, MTIP_TAG_INTERNAL);
+if (cmd->comp_func)
+cmd->comp_func(dd->port, MTIP_TAG_INTERNAL,
+cmd, -ENODEV);
+}
+}
+
 /*
  * Block layer deinitialization function.
  *
@@ 

[PATCH 10/10] mtip32xx: Cleanup queued requests after surprise removal

[Asai Thambi SP]

Fail all pending requests after surprise removal of a drive.

misc: Proper handling of resource free in probe failure path.

Signed-off-by: Vignesh Gunasekaran 
Signed-off-by: Selvan Mani 
Signed-off-by: Asai Thambi S P 
---
 drivers/block/mtip32xx/mtip32xx.c |   78 
 1 files changed, 60 insertions(+), 18 deletions(-)

diff --git a/drivers/block/mtip32xx/mtip32xx.c 
b/drivers/block/mtip32xx/mtip32xx.c
index d8410e6..ef23f17 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -173,7 +173,13 @@ static struct mtip_cmd *mtip_get_int_command(struct 
driver_data *dd)
 {
 struct request *rq;
 
+if (mtip_check_surprise_removal(dd->pdev))
+return NULL;
+
 rq = blk_mq_alloc_request(dd->queue, 0, BLK_MQ_REQ_RESERVED);
+if (IS_ERR(rq))
+return NULL;
+
 return blk_mq_rq_to_pdu(rq);
 }
 
@@ -575,6 +581,8 @@ static void mtip_completion(struct mtip_port *port,
 dev_warn(>dd->pdev->dev,
 "Internal command %d completed with TFE\n", tag);
 
+command->comp_func = NULL;
+command->comp_data = NULL;
 complete(waiting);
 }
 
@@ -1044,12 +1052,14 @@ static bool mtip_pause_ncq(struct mtip_port *port,
  *
  * @portPointer to port data structure
  * @timeout Max duration to wait (ms)
+ * @atomic  gfp_t flag to indicate blockable context or not
  *
  * return value
  *0Success
  *-EBUSY  Commands still active
  */
-static int mtip_quiesce_io(struct mtip_port *port, unsigned long timeout)
+static int mtip_quiesce_io(struct mtip_port *port, unsigned long timeout,
+gfp_t atomic)
 {
 unsigned long to;
 unsigned int n;
@@ -1060,16 +1070,21 @@ static int mtip_quiesce_io(struct mtip_port *port, 
unsigned long timeout)
 to = jiffies + msecs_to_jiffies(timeout);
 do {
 if (test_bit(MTIP_PF_SVC_THD_ACTIVE_BIT, >flags) &&
-test_bit(MTIP_PF_ISSUE_CMDS_BIT, >flags)) {
+test_bit(MTIP_PF_ISSUE_CMDS_BIT, >flags) &&
+atomic == GFP_KERNEL) {
 msleep(20);
 continue; /* svc thd is actively issuing commands */
 }
 
-msleep(100);
+if (atomic == GFP_KERNEL)
+msleep(100);
+else {
+cpu_relax();
+udelay(100);
+}
+
 if (mtip_check_surprise_removal(port->dd->pdev))
 goto err_fault;
-if (test_bit(MTIP_DDF_REMOVE_PENDING_BIT, >dd->dd_flag))
-goto err_fault;
 
 /*
  * Ignore s_active bit 0 of array element 0.
@@ -1131,6 +1146,10 @@ static int mtip_exec_internal_command(struct mtip_port 
*port,
 }
 
 int_cmd = mtip_get_int_command(dd);
+if (!int_cmd) {
+dbg_printk(MTIP_DRV_NAME "Unable to allocate tag for PIO cmd\n");
+return -EFAULT;
+}
 
 set_bit(MTIP_PF_IC_ACTIVE_BIT, >flags);
 
@@ -1158,7 +1177,7 @@ static int mtip_exec_internal_command(struct mtip_port 
*port,
 if (fis->command != ATA_CMD_STANDBYNOW1) {
 /* wait for io to complete if non atomic */
 if (mtip_quiesce_io(port,
-MTIP_QUIESCE_IO_TIMEOUT_MS) < 0) {
+MTIP_QUIESCE_IO_TIMEOUT_MS, atomic) < 0) {
 dev_warn(>pdev->dev,
 "Failed to quiesce IO\n");
 
@@ -3416,10 +3435,6 @@ static int mtip_standby_drive(struct driver_data *dd)
  */
 static int mtip_hw_exit(struct driver_data *dd)
 {
-/*
- * Send standby immediate (E0h) to the drive so that it
- * saves its state.
- */
 if (!dd->sr) {
 /* de-initialize the port. */
 mtip_deinit_port(dd->port);
@@ -4036,7 +4051,7 @@ static int mtip_block_initialize(struct driver_data *dd)
 if (rv) {
 dev_err(>pdev->dev,
 "Unable to allocate request queue\n");
-goto block_queue_alloc_init_error;
+goto block_queue_alloc_tag_error;
 }
 
 /* Allocate the request queue. */
@@ -4149,8 +4164,9 @@ kthread_run_error:
 read_capacity_error:
 init_hw_cmds_error:
 blk_cleanup_queue(dd->queue);
-blk_mq_free_tag_set(>tags);
 block_queue_alloc_init_error:
+blk_mq_free_tag_set(>tags);
+block_queue_alloc_tag_error:
 mtip_hw_debugfs_exit(dd);
 disk_index_error:
 spin_lock(_index_lock);
@@ -4167,6 +4183,22 @@ protocol_init_error:
 return rv;
 }
 
+static void mtip_no_dev_cleanup(struct request *rq, void *data, bool reserv)
+{
+struct driver_data *dd = (struct driver_data *)data;
+struct mtip_cmd *cmd;
+
+if (likely(!reserv))
+blk_mq_complete_request(rq, -ENODEV);
+else if (test_bit(MTIP_PF_IC_ACTIVE_BIT, >port->flags)) {
+
+cmd = mtip_cmd_from_tag(dd, MTIP_TAG_INTERNAL);
+if (cmd->comp_func)
+cmd->comp_func(dd->port, MTIP_TAG_INTERNAL,
+cmd, -ENODEV);
+}
+}
+
 /*
  * Block layer deinitialization function.
  *
@@ -4199,12 +4231,23 @@ static int mtip_block_remove(struct 

[PATCH 08/10] mtip32xx: Handle FTL rebuild failure state during device initialization

[Asai Thambi SP]

Allow device initialization to finish gracefully when it is in
FTL rebuild failure state. Also, recover device out of this state
after successfully secure erasing it.

Signed-off-by: Selvan Mani 
Signed-off-by: Vignesh Gunasekaran 
Signed-off-by: Asai Thambi S P 
---
 drivers/block/mtip32xx/mtip32xx.c |   11 ++-
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/block/mtip32xx/mtip32xx.c 
b/drivers/block/mtip32xx/mtip32xx.c
index 85c1794..96721c0 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -699,7 +699,7 @@ static void mtip_handle_tfe(struct driver_data *dd)
 fail_reason = "thermal shutdown";
 }
 if (buf[288] == 0xBF) {
-set_bit(MTIP_DDF_SEC_LOCK_BIT, >dd_flag);
+set_bit(MTIP_DDF_REBUILD_FAILED_BIT, >dd_flag);
 dev_info(>pdev->dev,
 "Drive indicates rebuild has failed. Secure erase 
required.\n");
 fail_all_ncq_cmds = 1;
@@ -1034,6 +1034,7 @@ static bool mtip_pause_ncq(struct mtip_port *port,
  fis->features == 0x62 || fis->features == 0x26 ||
  fis->features == 0x12))) {
 clear_bit(MTIP_DDF_SEC_LOCK_BIT, >dd->dd_flag);
+clear_bit(MTIP_DDF_REBUILD_FAILED_BIT, >dd->dd_flag);
 mtip_bdev_unclaim(port->dd);
 /* Com reset after secure erase or lowlevel format */
 mtip_restart_port(port);
@@ -1218,6 +1219,7 @@ static int mtip_exec_internal_command(struct mtip_port 
*port,
 if ((rv = wait_for_completion_interruptible_timeout(
 ,
 msecs_to_jiffies(timeout))) <= 0) {
+
 if (rv == -ERESTARTSYS) { /* interrupted */
 dev_err(>pdev->dev,
 "Internal command [%02X] was interrupted after %u ms\n",
@@ -3153,7 +3155,7 @@ static int mtip_hw_get_identify(struct driver_data *dd)
 if (buf[288] == 0xBF) {
 dev_info(>pdev->dev,
 "Drive indicates rebuild has failed.\n");
-/* TODO */
+set_bit(MTIP_DDF_REBUILD_FAILED_BIT, >dd_flag);
 }
 }
 
@@ -3756,10 +3758,9 @@ static int mtip_submit_request(struct blk_mq_hw_ctx 
*hctx, struct request *rq)
 rq_data_dir(rq))) {
 return -ENODATA;
 }
-if (unlikely(test_bit(MTIP_DDF_SEC_LOCK_BIT, >dd_flag)))
+if (unlikely(test_bit(MTIP_DDF_SEC_LOCK_BIT, >dd_flag) ||
+test_bit(MTIP_DDF_REBUILD_FAILED_BIT, >dd_flag)))
 return -ENODATA;
-if (test_bit(MTIP_DDF_REBUILD_FAILED_BIT, >dd_flag))
-return -ENXIO;
 }
 
 if (rq->cmd_flags & REQ_DISCARD) {
-- 
1.7.1

[PATCH 09/10] mtip32xx: Add timeout handler

[Asai Thambi SP]

Added timeout handler. Implementing timeout handler requires replacing 
blk_mq_end_request()
with blk_mq_complete_request() to avoid double completion of a request.

Signed-off-by: Selvan Mani 
Signed-off-by: Rajesh Kumar Sambandam 
Signed-off-by: Asai Thambi S P 
---
 drivers/block/mtip32xx/mtip32xx.c |   95 +---
 drivers/block/mtip32xx/mtip32xx.h |7 ++-
 2 files changed, 92 insertions(+), 10 deletions(-)

diff --git a/drivers/block/mtip32xx/mtip32xx.c 
b/drivers/block/mtip32xx/mtip32xx.c
index 96721c0..d8410e6 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -233,15 +233,9 @@ static void mtip_async_complete(struct mtip_port *port,
 "Command tag %d failed due to TFE\n", tag);
 }
 
-/* Unmap the DMA scatter list entries */
-dma_unmap_sg(>pdev->dev, cmd->sg, cmd->scatter_ents, cmd->direction);
-
 rq = mtip_rq_from_tag(dd, tag);
 
-if (unlikely(cmd->unaligned))
-up(>cmd_slot_unal);
-
-blk_mq_end_request(rq, status ? -EIO : 0);
+blk_mq_complete_request(rq, status);
 }
 
 /*
@@ -2958,6 +2952,42 @@ static int mtip_ftl_rebuild_poll(struct driver_data *dd)
 return -EFAULT;
 }
 
+static void mtip_softirq_done_fn(struct request *rq)
+{
+struct mtip_cmd *cmd = blk_mq_rq_to_pdu(rq);
+struct driver_data *dd = rq->q->queuedata;
+
+/* Unmap the DMA scatter list entries */
+dma_unmap_sg(>pdev->dev, cmd->sg, cmd->scatter_ents,
+cmd->direction);
+
+if (unlikely(cmd->unaligned))
+up(>port->cmd_slot_unal);
+
+blk_mq_end_request(rq, rq->errors);
+}
+
+static void mtip_abort_cmd(struct request *req, void *data,
+bool reserved)
+{
+struct driver_data *dd = data;
+
+dbg_printk(MTIP_DRV_NAME " Aborting request, tag = %d\n", req->tag);
+
+clear_bit(req->tag, dd->port->cmds_to_issue);
+req->errors = -EIO;
+mtip_softirq_done_fn(req);
+}
+
+static void mtip_queue_cmd(struct request *req, void *data,
+bool reserved)
+{
+struct driver_data *dd = data;
+
+set_bit(req->tag, dd->port->cmds_to_issue);
+blk_abort_request(req);
+}
+
 /*
  * service thread to issue queued commands
  *
@@ -2970,7 +3000,7 @@ static int mtip_ftl_rebuild_poll(struct driver_data *dd)
 static int mtip_service_thread(void *data)
 {
 struct driver_data *dd = (struct driver_data *)data;
-unsigned long slot, slot_start, slot_wrap;
+unsigned long slot, slot_start, slot_wrap, to;
 unsigned int num_cmd_slots = dd->slot_groups * 32;
 struct mtip_port *port = dd->port;
 
@@ -3007,6 +3037,32 @@ restart_eh:
 if (test_bit(MTIP_PF_EH_ACTIVE_BIT, >flags))
 goto restart_eh;
 
+if (test_bit(MTIP_PF_TO_ACTIVE_BIT, >flags)) {
+to = jiffies + msecs_to_jiffies(5000);
+
+do {
+mdelay(100);
+} while (atomic_read(>irq_workers_active) != 0 &&
+time_before(jiffies, to));
+
+if (atomic_read(>irq_workers_active) != 0)
+dev_warn(>pdev->dev,
+"Completion workers still active!");
+
+spin_lock(dd->queue->queue_lock);
+blk_mq_all_tag_busy_iter(*dd->tags.tags,
+mtip_queue_cmd, dd);
+spin_unlock(dd->queue->queue_lock);
+
+set_bit(MTIP_PF_ISSUE_CMDS_BIT, >port->flags);
+
+if (mtip_device_reset(dd))
+blk_mq_all_tag_busy_iter(*dd->tags.tags,
+mtip_abort_cmd, dd);
+
+clear_bit(MTIP_PF_TO_ACTIVE_BIT, >port->flags);
+}
+
 if (test_bit(MTIP_PF_ISSUE_CMDS_BIT, >flags)) {
 slot = 1;
 /* used to restrict the loop to one iteration */
@@ -3872,11 +3928,33 @@ static int mtip_init_cmd(void *data, struct request 
*rq, unsigned int hctx_idx,
 return 0;
 }
 
+static enum blk_eh_timer_return mtip_cmd_timeout(struct request *req,
+bool reserved)
+{
+struct driver_data *dd = req->q->queuedata;
+int ret = BLK_EH_RESET_TIMER;
+
+if (reserved)
+goto exit_handler;
+
+if (test_bit(req->tag, dd->port->cmds_to_issue))
+goto exit_handler;
+
+if (test_and_set_bit(MTIP_PF_TO_ACTIVE_BIT, >port->flags))
+goto exit_handler;
+
+wake_up_interruptible(>port->svc_wait);
+exit_handler:
+return ret;
+}
+
 static struct blk_mq_ops mtip_mq_ops = {
 .queue_rq= mtip_queue_rq,
 .map_queue= blk_mq_map_queue,
 .init_request= mtip_init_cmd,
 .exit_request= mtip_free_cmd,
+.complete= mtip_softirq_done_fn,
+.timeout= mtip_cmd_timeout,
 };
 
 /*
@@ -3952,6 +4030,7 @@ static int mtip_block_initialize(struct driver_data *dd)
 dd->tags.numa_node = dd->numa_node;
 dd->tags.flags = BLK_MQ_F_SHOULD_MERGE;
 

[PATCH 08/10] mtip32xx: Handle FTL rebuild failure state during device initialization

[Asai Thambi SP]

Allow device initialization to finish gracefully when it is in
FTL rebuild failure state. Also, recover device out of this state
after successfully secure erasing it.

Signed-off-by: Selvan Mani 
Signed-off-by: Vignesh Gunasekaran 
Signed-off-by: Asai Thambi S P 
---
 drivers/block/mtip32xx/mtip32xx.c |   11 ++-
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/block/mtip32xx/mtip32xx.c 
b/drivers/block/mtip32xx/mtip32xx.c
index 85c1794..96721c0 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -699,7 +699,7 @@ static void mtip_handle_tfe(struct driver_data *dd)
 fail_reason = "thermal shutdown";
 }
 if (buf[288] == 0xBF) {
-set_bit(MTIP_DDF_SEC_LOCK_BIT, >dd_flag);
+set_bit(MTIP_DDF_REBUILD_FAILED_BIT, >dd_flag);
 dev_info(>pdev->dev,
 "Drive indicates rebuild has failed. Secure erase 
required.\n");
 fail_all_ncq_cmds = 1;
@@ -1034,6 +1034,7 @@ static bool mtip_pause_ncq(struct mtip_port *port,
  fis->features == 0x62 || fis->features == 0x26 ||
  fis->features == 0x12))) {
 clear_bit(MTIP_DDF_SEC_LOCK_BIT, >dd->dd_flag);
+clear_bit(MTIP_DDF_REBUILD_FAILED_BIT, >dd->dd_flag);
 mtip_bdev_unclaim(port->dd);
 /* Com reset after secure erase or lowlevel format */
 mtip_restart_port(port);
@@ -1218,6 +1219,7 @@ static int mtip_exec_internal_command(struct mtip_port 
*port,
 if ((rv = wait_for_completion_interruptible_timeout(
 ,
 msecs_to_jiffies(timeout))) <= 0) {
+
 if (rv == -ERESTARTSYS) { /* interrupted */
 dev_err(>pdev->dev,
 "Internal command [%02X] was interrupted after %u ms\n",
@@ -3153,7 +3155,7 @@ static int mtip_hw_get_identify(struct driver_data *dd)
 if (buf[288] == 0xBF) {
 dev_info(>pdev->dev,
 "Drive indicates rebuild has failed.\n");
-/* TODO */
+set_bit(MTIP_DDF_REBUILD_FAILED_BIT, >dd_flag);
 }
 }
 
@@ -3756,10 +3758,9 @@ static int mtip_submit_request(struct blk_mq_hw_ctx 
*hctx, struct request *rq)
 rq_data_dir(rq))) {
 return -ENODATA;
 }
-if (unlikely(test_bit(MTIP_DDF_SEC_LOCK_BIT, >dd_flag)))
+if (unlikely(test_bit(MTIP_DDF_SEC_LOCK_BIT, >dd_flag) ||
+test_bit(MTIP_DDF_REBUILD_FAILED_BIT, >dd_flag)))
 return -ENODATA;
-if (test_bit(MTIP_DDF_REBUILD_FAILED_BIT, >dd_flag))
-return -ENXIO;
 }
 
 if (rq->cmd_flags & REQ_DISCARD) {
-- 
1.7.1

[PATCH 09/10] mtip32xx: Add timeout handler

[Asai Thambi SP]

Added timeout handler. Implementing timeout handler requires replacing 
blk_mq_end_request()
with blk_mq_complete_request() to avoid double completion of a request.

Signed-off-by: Selvan Mani 
Signed-off-by: Rajesh Kumar Sambandam 
Signed-off-by: Asai Thambi S P 
---
 drivers/block/mtip32xx/mtip32xx.c |   95 +---
 drivers/block/mtip32xx/mtip32xx.h |7 ++-
 2 files changed, 92 insertions(+), 10 deletions(-)

diff --git a/drivers/block/mtip32xx/mtip32xx.c 
b/drivers/block/mtip32xx/mtip32xx.c
index 96721c0..d8410e6 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -233,15 +233,9 @@ static void mtip_async_complete(struct mtip_port *port,
 "Command tag %d failed due to TFE\n", tag);
 }
 
-/* Unmap the DMA scatter list entries */
-dma_unmap_sg(>pdev->dev, cmd->sg, cmd->scatter_ents, cmd->direction);
-
 rq = mtip_rq_from_tag(dd, tag);
 
-if (unlikely(cmd->unaligned))
-up(>cmd_slot_unal);
-
-blk_mq_end_request(rq, status ? -EIO : 0);
+blk_mq_complete_request(rq, status);
 }
 
 /*
@@ -2958,6 +2952,42 @@ static int mtip_ftl_rebuild_poll(struct driver_data *dd)
 return -EFAULT;
 }
 
+static void mtip_softirq_done_fn(struct request *rq)
+{
+struct mtip_cmd *cmd = blk_mq_rq_to_pdu(rq);
+struct driver_data *dd = rq->q->queuedata;
+
+/* Unmap the DMA scatter list entries */
+dma_unmap_sg(>pdev->dev, cmd->sg, cmd->scatter_ents,
+cmd->direction);
+
+if (unlikely(cmd->unaligned))
+up(>port->cmd_slot_unal);
+
+blk_mq_end_request(rq, rq->errors);
+}
+
+static void mtip_abort_cmd(struct request *req, void *data,
+bool reserved)
+{
+struct driver_data *dd = data;
+
+dbg_printk(MTIP_DRV_NAME " Aborting request, tag = %d\n", req->tag);
+
+clear_bit(req->tag, dd->port->cmds_to_issue);
+req->errors = -EIO;
+mtip_softirq_done_fn(req);
+}
+
+static void mtip_queue_cmd(struct request *req, void *data,
+bool reserved)
+{
+struct driver_data *dd = data;
+
+set_bit(req->tag, dd->port->cmds_to_issue);
+blk_abort_request(req);
+}
+
 /*
  * service thread to issue queued commands
  *
@@ -2970,7 +3000,7 @@ static int mtip_ftl_rebuild_poll(struct driver_data *dd)
 static int mtip_service_thread(void *data)
 {
 struct driver_data *dd = (struct driver_data *)data;
-unsigned long slot, slot_start, slot_wrap;
+unsigned long slot, slot_start, slot_wrap, to;
 unsigned int num_cmd_slots = dd->slot_groups * 32;
 struct mtip_port *port = dd->port;
 
@@ -3007,6 +3037,32 @@ restart_eh:
 if (test_bit(MTIP_PF_EH_ACTIVE_BIT, >flags))
 goto restart_eh;
 
+if (test_bit(MTIP_PF_TO_ACTIVE_BIT, >flags)) {
+to = jiffies + msecs_to_jiffies(5000);
+
+do {
+mdelay(100);
+} while (atomic_read(>irq_workers_active) != 0 &&
+time_before(jiffies, to));
+
+if (atomic_read(>irq_workers_active) != 0)
+dev_warn(>pdev->dev,
+"Completion workers still active!");
+
+spin_lock(dd->queue->queue_lock);
+blk_mq_all_tag_busy_iter(*dd->tags.tags,
+mtip_queue_cmd, dd);
+spin_unlock(dd->queue->queue_lock);
+
+set_bit(MTIP_PF_ISSUE_CMDS_BIT, >port->flags);
+
+if (mtip_device_reset(dd))
+blk_mq_all_tag_busy_iter(*dd->tags.tags,
+mtip_abort_cmd, dd);
+
+clear_bit(MTIP_PF_TO_ACTIVE_BIT, >port->flags);
+}
+
 if (test_bit(MTIP_PF_ISSUE_CMDS_BIT, >flags)) {
 slot = 1;
 /* used to restrict the loop to one iteration */
@@ -3872,11 +3928,33 @@ static int mtip_init_cmd(void *data, struct request 
*rq, unsigned int hctx_idx,
 return 0;
 }
 
+static enum blk_eh_timer_return mtip_cmd_timeout(struct request *req,
+bool reserved)
+{
+struct driver_data *dd = req->q->queuedata;
+int ret = BLK_EH_RESET_TIMER;
+
+if (reserved)
+goto exit_handler;
+
+if (test_bit(req->tag, dd->port->cmds_to_issue))
+goto exit_handler;
+
+if (test_and_set_bit(MTIP_PF_TO_ACTIVE_BIT, >port->flags))
+goto exit_handler;
+
+wake_up_interruptible(>port->svc_wait);
+exit_handler:
+return ret;
+}
+
 static struct blk_mq_ops mtip_mq_ops = {
 .queue_rq= mtip_queue_rq,
 .map_queue= blk_mq_map_queue,
 .init_request= mtip_init_cmd,
 .exit_request= mtip_free_cmd,
+.complete= mtip_softirq_done_fn,
+.timeout= mtip_cmd_timeout,
 };
 
 /*
@@ -3952,6 +4030,7 @@ static int mtip_block_initialize(struct driver_data *dd)
 dd->tags.numa_node = dd->numa_node;
 dd->tags.flags = BLK_MQ_F_SHOULD_MERGE;
 dd->tags.driver_data = dd;
+dd->tags.timeout = MTIP_NCQ_CMD_TIMEOUT_MS;
 
 

[PATCH 06/10] mtip32xx: Fix for rmmod crash when drive is in FTL rebuild

[Asai Thambi SP]

When FTL rebuild is in progress, alloc_disk() initializes the disk
but device node will be created by add_disk() only after successful
completion of FTL rebuild. So, skip deletion of device node in
removal path when FTL rebuild is in progress.

Signed-off-by: Selvan Mani 
Signed-off-by: Asai Thambi S P 
---
 drivers/block/mtip32xx/mtip32xx.c |   14 +++---
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/block/mtip32xx/mtip32xx.c 
b/drivers/block/mtip32xx/mtip32xx.c
index ba832a8..7ad3b90 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -3037,10 +3037,8 @@ restart_eh:
 }
 
 if (test_bit(MTIP_PF_REBUILD_BIT, >flags)) {
-if (mtip_ftl_rebuild_poll(dd) < 0)
-set_bit(MTIP_DDF_REBUILD_FAILED_BIT,
->dd_flag);
-clear_bit(MTIP_PF_REBUILD_BIT, >flags);
+if (mtip_ftl_rebuild_poll(dd) == 0)
+clear_bit(MTIP_PF_REBUILD_BIT, >flags);
 }
 }
 
@@ -3920,7 +3918,6 @@ static int mtip_block_initialize(struct driver_data *dd)
 
 mtip_hw_debugfs_init(dd);
 
-skip_create_disk:
 memset(>tags, 0, sizeof(dd->tags));
 dd->tags.ops = _mq_ops;
 dd->tags.nr_hw_queues = 1;
@@ -3950,6 +3947,7 @@ skip_create_disk:
 dd->disk->queue= dd->queue;
 dd->queue->queuedata= dd;
 
+skip_create_disk:
 /* Initialize the protocol layer. */
 wait_for_rebuild = mtip_hw_get_identify(dd);
 if (wait_for_rebuild < 0) {
@@ -4112,7 +4110,8 @@ static int mtip_block_remove(struct driver_data *dd)
 dd->bdev = NULL;
 }
 if (dd->disk) {
-del_gendisk(dd->disk);
+if (test_bit(MTIP_DDF_INIT_DONE_BIT, >dd_flag))
+del_gendisk(dd->disk);
 if (dd->disk->queue) {
 blk_cleanup_queue(dd->queue);
 blk_mq_free_tag_set(>tags);
@@ -4153,7 +4152,8 @@ static int mtip_block_shutdown(struct driver_data *dd)
 dev_info(>pdev->dev,
 "Shutting down %s ...\n", dd->disk->disk_name);
 
-del_gendisk(dd->disk);
+if (test_bit(MTIP_DDF_INIT_DONE_BIT, >dd_flag))
+del_gendisk(dd->disk);
 if (dd->disk->queue) {
 blk_cleanup_queue(dd->queue);
 blk_mq_free_tag_set(>tags);
-- 
1.7.1

[PATCH 06/10] mtip32xx: Fix for rmmod crash when drive is in FTL rebuild

[Asai Thambi SP]

When FTL rebuild is in progress, alloc_disk() initializes the disk
but device node will be created by add_disk() only after successful
completion of FTL rebuild. So, skip deletion of device node in
removal path when FTL rebuild is in progress.

Signed-off-by: Selvan Mani 
Signed-off-by: Asai Thambi S P 
---
 drivers/block/mtip32xx/mtip32xx.c |   14 +++---
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/block/mtip32xx/mtip32xx.c 
b/drivers/block/mtip32xx/mtip32xx.c
index ba832a8..7ad3b90 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -3037,10 +3037,8 @@ restart_eh:
 }
 
 if (test_bit(MTIP_PF_REBUILD_BIT, >flags)) {
-if (mtip_ftl_rebuild_poll(dd) < 0)
-set_bit(MTIP_DDF_REBUILD_FAILED_BIT,
->dd_flag);
-clear_bit(MTIP_PF_REBUILD_BIT, >flags);
+if (mtip_ftl_rebuild_poll(dd) == 0)
+clear_bit(MTIP_PF_REBUILD_BIT, >flags);
 }
 }
 
@@ -3920,7 +3918,6 @@ static int mtip_block_initialize(struct driver_data *dd)
 
 mtip_hw_debugfs_init(dd);
 
-skip_create_disk:
 memset(>tags, 0, sizeof(dd->tags));
 dd->tags.ops = _mq_ops;
 dd->tags.nr_hw_queues = 1;
@@ -3950,6 +3947,7 @@ skip_create_disk:
 dd->disk->queue= dd->queue;
 dd->queue->queuedata= dd;
 
+skip_create_disk:
 /* Initialize the protocol layer. */
 wait_for_rebuild = mtip_hw_get_identify(dd);
 if (wait_for_rebuild < 0) {
@@ -4112,7 +4110,8 @@ static int mtip_block_remove(struct driver_data *dd)
 dd->bdev = NULL;
 }
 if (dd->disk) {
-del_gendisk(dd->disk);
+if (test_bit(MTIP_DDF_INIT_DONE_BIT, >dd_flag))
+del_gendisk(dd->disk);
 if (dd->disk->queue) {
 blk_cleanup_queue(dd->queue);
 blk_mq_free_tag_set(>tags);
@@ -4153,7 +4152,8 @@ static int mtip_block_shutdown(struct driver_data *dd)
 dev_info(>pdev->dev,
 "Shutting down %s ...\n", dd->disk->disk_name);
 
-del_gendisk(dd->disk);
+if (test_bit(MTIP_DDF_INIT_DONE_BIT, >dd_flag))
+del_gendisk(dd->disk);
 if (dd->disk->queue) {
 blk_cleanup_queue(dd->queue);
 blk_mq_free_tag_set(>tags);
-- 
1.7.1

linux-next: Tree for Feb 23

[Stephen Rothwell]

Hi all,

Changes since 20160222:

The f2fs tree gained complex conflicts against Linus' tree for which I
dropped a commit from the f2fs tree.

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

Non-merge commits (relative to Linus' tree): 6427
 5239 files changed, 238654 insertions(+), 118810 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (dea08e604408 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging fixes/master (36f90b0a2ddd Linux 4.5-rc2)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (74bf8efb5fa6 Linux 4.4-rc7)
Merging arm-current/fixes (c7edd7f99cda ARM: 8534/1: virt: fix hyp-stub build 
for pre-ARMv7 CPUs)
Merging m68k-current/for-linus (daf670bc9d36 m68k/defconfig: Update defconfigs 
for v4.5-rc1)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-fixes/fixes (6ecad912a007 powerpc/ioda: Set "read" permission 
when "write" is set)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (ca0bb0798022 Add sun4v_wdt watchdog driver)
Merging net/master (d856626d3b05 Merge tag 'linux-can-fixes-for-4.5-20160221' 
of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can)
Merging ipsec/master (325b71fe0f57 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (5acaf89f88b9 netfilter: ipvs: handle 
ip_vs_fill_iph_skb_off failure)
Merging wireless-drivers/master (c699404db182 Merge tag 
'iwlwifi-for-kalle-2016-02-15' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (212c5a5e6ba6 mac80211: minstrel: Change expected 
throughput unit back to Kbps)
Merging sound-current/for-linus (67ec1072b053 ALSA: pcm: Fix rwsem deadlock for 
non-atomic PCM stream)
Merging pci-current/for-linus (7d99d59d4c6b Revert "PCI, x86: Implement 
pcibios_alloc_irq() and pcibios_free_irq()")
Merging driver-core.current/driver-core-linus (18558cae0272 Linux 4.5-rc4)
Merging tty.current/tty-linus (18558cae0272 Linux 4.5-rc4)
Merging usb.current/usb-linus (e5bdfd50d6f7 Revert "usb: hub: do not clear BOS 
field during reset device")
Merging usb-gadget-fixes/fixes (d74f10bc834f MAINTAINERS: drop OMAP USB and 
MUSB maintainership)
Merging usb-serial-fixes/usb-linus (d061c1caa31d USB: option: add "4G LTE 
usb-modem U901")
Merging usb-chipidea-fixes/ci-for-usb-stable (8c0614ca312c usb: chipidea: fix 
return value check in ci_hdrc_pci_probe())
Merging staging.current/staging-linus (7a64cd887fdb drivers: android: correct 
the size of struct binder_uintptr_t for BC_DEAD_BINDER_DONE)
Merging char-misc.current/char-misc-linus (18558cae0272 Linux 4.5-rc4)
Merging input-current/for-linus (ff84dabe3c6e Input: colibri-vf50-ts - add 
missing #include )
Merging crypto-current/master (8a3978ad55fb crypto: marvell/cesa - fix test in 
mv_cesa_dev_dma_init())
Merging ide/master (e04a2bd6d8c9 drivers/ide: make ide-scan-pci.c driver 
explicitly non-modular)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-

linux-next: Tree for Feb 23

[Stephen Rothwell]

Hi all,

Changes since 20160222:

The f2fs tree gained complex conflicts against Linus' tree for which I
dropped a commit from the f2fs tree.

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

Non-merge commits (relative to Linus' tree): 6427
 5239 files changed, 238654 insertions(+), 118810 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (dea08e604408 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging fixes/master (36f90b0a2ddd Linux 4.5-rc2)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (74bf8efb5fa6 Linux 4.4-rc7)
Merging arm-current/fixes (c7edd7f99cda ARM: 8534/1: virt: fix hyp-stub build 
for pre-ARMv7 CPUs)
Merging m68k-current/for-linus (daf670bc9d36 m68k/defconfig: Update defconfigs 
for v4.5-rc1)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-fixes/fixes (6ecad912a007 powerpc/ioda: Set "read" permission 
when "write" is set)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (ca0bb0798022 Add sun4v_wdt watchdog driver)
Merging net/master (d856626d3b05 Merge tag 'linux-can-fixes-for-4.5-20160221' 
of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can)
Merging ipsec/master (325b71fe0f57 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (5acaf89f88b9 netfilter: ipvs: handle 
ip_vs_fill_iph_skb_off failure)
Merging wireless-drivers/master (c699404db182 Merge tag 
'iwlwifi-for-kalle-2016-02-15' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (212c5a5e6ba6 mac80211: minstrel: Change expected 
throughput unit back to Kbps)
Merging sound-current/for-linus (67ec1072b053 ALSA: pcm: Fix rwsem deadlock for 
non-atomic PCM stream)
Merging pci-current/for-linus (7d99d59d4c6b Revert "PCI, x86: Implement 
pcibios_alloc_irq() and pcibios_free_irq()")
Merging driver-core.current/driver-core-linus (18558cae0272 Linux 4.5-rc4)
Merging tty.current/tty-linus (18558cae0272 Linux 4.5-rc4)
Merging usb.current/usb-linus (e5bdfd50d6f7 Revert "usb: hub: do not clear BOS 
field during reset device")
Merging usb-gadget-fixes/fixes (d74f10bc834f MAINTAINERS: drop OMAP USB and 
MUSB maintainership)
Merging usb-serial-fixes/usb-linus (d061c1caa31d USB: option: add "4G LTE 
usb-modem U901")
Merging usb-chipidea-fixes/ci-for-usb-stable (8c0614ca312c usb: chipidea: fix 
return value check in ci_hdrc_pci_probe())
Merging staging.current/staging-linus (7a64cd887fdb drivers: android: correct 
the size of struct binder_uintptr_t for BC_DEAD_BINDER_DONE)
Merging char-misc.current/char-misc-linus (18558cae0272 Linux 4.5-rc4)
Merging input-current/for-linus (ff84dabe3c6e Input: colibri-vf50-ts - add 
missing #include )
Merging crypto-current/master (8a3978ad55fb crypto: marvell/cesa - fix test in 
mv_cesa_dev_dma_init())
Merging ide/master (e04a2bd6d8c9 drivers/ide: make ide-scan-pci.c driver 
explicitly non-modular)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-

[PATCH 07/10] mtip32xx: Handle safe removal during IO

[Asai Thambi SP]

Flush inflight IOs using fsync_bdev() when the device is safely
removed. Also, block further IOs in device open function.

Signed-off-by: Selvan Mani 
Signed-off-by: Rajesh Kumar Sambandam 
Signed-off-by: Asai Thambi S P 
---
 drivers/block/mtip32xx/mtip32xx.c |   34 --
 drivers/block/mtip32xx/mtip32xx.h |1 +
 2 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/drivers/block/mtip32xx/mtip32xx.c 
b/drivers/block/mtip32xx/mtip32xx.c
index 7ad3b90..85c1794 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -3664,6 +3664,28 @@ static int mtip_block_getgeo(struct block_device *dev,
 return 0;
 }
 
+static int mtip_block_open(struct block_device *dev, fmode_t mode)
+{
+struct driver_data *dd;
+
+if (dev && dev->bd_disk) {
+dd = (struct driver_data *) dev->bd_disk->private_data;
+
+if (dd) {
+if (test_bit(MTIP_DDF_REMOVAL_BIT,
+>dd_flag)) {
+return -ENODEV;
+}
+return 0;
+}
+}
+return -ENODEV;
+}
+
+void mtip_block_release(struct gendisk *disk, fmode_t mode)
+{
+}
+
 /*
  * Block device operation function.
  *
@@ -3671,6 +3693,8 @@ static int mtip_block_getgeo(struct block_device *dev,
  * layer.
  */
 static const struct block_device_operations mtip_block_ops = {
+.open= mtip_block_open,
+.release= mtip_block_release,
 .ioctl= mtip_block_ioctl,
 #ifdef CONFIG_COMPAT
 .compat_ioctl= mtip_block_compat_ioctl,
@@ -4498,7 +4522,7 @@ static void mtip_pci_remove(struct pci_dev *pdev)
 struct driver_data *dd = pci_get_drvdata(pdev);
 unsigned long flags, to;
 
-set_bit(MTIP_DDF_REMOVE_PENDING_BIT, >dd_flag);
+set_bit(MTIP_DDF_REMOVAL_BIT, >dd_flag);
 
 spin_lock_irqsave(_lock, flags);
 list_del_init(>online_list);
@@ -4515,12 +4539,18 @@ static void mtip_pci_remove(struct pci_dev *pdev)
 } while (atomic_read(>irq_workers_active) != 0 &&
 time_before(jiffies, to));
 
+fsync_bdev(dd->bdev);
+
 if (atomic_read(>irq_workers_active) != 0) {
 dev_warn(>pdev->dev,
 "Completion workers still active!\n");
 }
 
-blk_mq_stop_hw_queues(dd->queue);
+if (dd->sr)
+blk_mq_stop_hw_queues(dd->queue);
+
+set_bit(MTIP_DDF_REMOVE_PENDING_BIT, >dd_flag);
+
 /* Clean up the block layer. */
 mtip_block_remove(dd);
 
diff --git a/drivers/block/mtip32xx/mtip32xx.h 
b/drivers/block/mtip32xx/mtip32xx.h
index 64bfb82..b6436ce 100644
--- a/drivers/block/mtip32xx/mtip32xx.h
+++ b/drivers/block/mtip32xx/mtip32xx.h
@@ -158,6 +158,7 @@ enum {
 MTIP_DDF_RESUME_BIT = 6,
 MTIP_DDF_INIT_DONE_BIT  = 7,
 MTIP_DDF_REBUILD_FAILED_BIT = 8,
+MTIP_DDF_REMOVAL_BIT= 9,
 
 MTIP_DDF_STOP_IO  = ((1 << MTIP_DDF_REMOVE_PENDING_BIT) |
 (1 << MTIP_DDF_SEC_LOCK_BIT) |
-- 
1.7.1

[PATCH 07/10] mtip32xx: Handle safe removal during IO

[Asai Thambi SP]

Flush inflight IOs using fsync_bdev() when the device is safely
removed. Also, block further IOs in device open function.

Signed-off-by: Selvan Mani 
Signed-off-by: Rajesh Kumar Sambandam 
Signed-off-by: Asai Thambi S P 
---
 drivers/block/mtip32xx/mtip32xx.c |   34 --
 drivers/block/mtip32xx/mtip32xx.h |1 +
 2 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/drivers/block/mtip32xx/mtip32xx.c 
b/drivers/block/mtip32xx/mtip32xx.c
index 7ad3b90..85c1794 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -3664,6 +3664,28 @@ static int mtip_block_getgeo(struct block_device *dev,
 return 0;
 }
 
+static int mtip_block_open(struct block_device *dev, fmode_t mode)
+{
+struct driver_data *dd;
+
+if (dev && dev->bd_disk) {
+dd = (struct driver_data *) dev->bd_disk->private_data;
+
+if (dd) {
+if (test_bit(MTIP_DDF_REMOVAL_BIT,
+>dd_flag)) {
+return -ENODEV;
+}
+return 0;
+}
+}
+return -ENODEV;
+}
+
+void mtip_block_release(struct gendisk *disk, fmode_t mode)
+{
+}
+
 /*
  * Block device operation function.
  *
@@ -3671,6 +3693,8 @@ static int mtip_block_getgeo(struct block_device *dev,
  * layer.
  */
 static const struct block_device_operations mtip_block_ops = {
+.open= mtip_block_open,
+.release= mtip_block_release,
 .ioctl= mtip_block_ioctl,
 #ifdef CONFIG_COMPAT
 .compat_ioctl= mtip_block_compat_ioctl,
@@ -4498,7 +4522,7 @@ static void mtip_pci_remove(struct pci_dev *pdev)
 struct driver_data *dd = pci_get_drvdata(pdev);
 unsigned long flags, to;
 
-set_bit(MTIP_DDF_REMOVE_PENDING_BIT, >dd_flag);
+set_bit(MTIP_DDF_REMOVAL_BIT, >dd_flag);
 
 spin_lock_irqsave(_lock, flags);
 list_del_init(>online_list);
@@ -4515,12 +4539,18 @@ static void mtip_pci_remove(struct pci_dev *pdev)
 } while (atomic_read(>irq_workers_active) != 0 &&
 time_before(jiffies, to));
 
+fsync_bdev(dd->bdev);
+
 if (atomic_read(>irq_workers_active) != 0) {
 dev_warn(>pdev->dev,
 "Completion workers still active!\n");
 }
 
-blk_mq_stop_hw_queues(dd->queue);
+if (dd->sr)
+blk_mq_stop_hw_queues(dd->queue);
+
+set_bit(MTIP_DDF_REMOVE_PENDING_BIT, >dd_flag);
+
 /* Clean up the block layer. */
 mtip_block_remove(dd);
 
diff --git a/drivers/block/mtip32xx/mtip32xx.h 
b/drivers/block/mtip32xx/mtip32xx.h
index 64bfb82..b6436ce 100644
--- a/drivers/block/mtip32xx/mtip32xx.h
+++ b/drivers/block/mtip32xx/mtip32xx.h
@@ -158,6 +158,7 @@ enum {
 MTIP_DDF_RESUME_BIT = 6,
 MTIP_DDF_INIT_DONE_BIT  = 7,
 MTIP_DDF_REBUILD_FAILED_BIT = 8,
+MTIP_DDF_REMOVAL_BIT= 9,
 
 MTIP_DDF_STOP_IO  = ((1 << MTIP_DDF_REMOVE_PENDING_BIT) |
 (1 << MTIP_DDF_SEC_LOCK_BIT) |
-- 
1.7.1

[PATCH 05/10] mtip32xx: Avoid issuing standby immediate cmd during FTL rebuild

[Asai Thambi SP]

Prevent standby immediate command from being issued in remove,
suspend and shutdown paths, while drive is performing FTL rebuild
process.

Signed-off-by: Selvan Mani 
Signed-off-by: Vignesh Gunasekaran 
Signed-off-by: Asai Thambi S P 
---
 drivers/block/mtip32xx/mtip32xx.c |   20 
 1 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/block/mtip32xx/mtip32xx.c 
b/drivers/block/mtip32xx/mtip32xx.c
index ca9d35a..ba832a8 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -3329,20 +3329,25 @@ out1:
 return rv;
 }
 
-static void mtip_standby_drive(struct driver_data *dd)
+static int mtip_standby_drive(struct driver_data *dd)
 {
-if (dd->sr)
-return;
+int rv = 0;
 
+if (dd->sr || !dd->port)
+return -ENODEV;
 /*
  * Send standby immediate (E0h) to the drive so that it
  * saves its state.
  */
 if (!test_bit(MTIP_PF_REBUILD_BIT, >port->flags) &&
-!test_bit(MTIP_DDF_SEC_LOCK_BIT, >dd_flag))
-if (mtip_standby_immediate(dd->port))
+!test_bit(MTIP_DDF_REBUILD_FAILED_BIT, >dd_flag) &&
+!test_bit(MTIP_DDF_SEC_LOCK_BIT, >dd_flag)) {
+rv = mtip_standby_immediate(dd->port);
+if (rv)
 dev_warn(>pdev->dev,
 "STANDBY IMMEDIATE failed\n");
+}
+return rv;
 }
 
 /*
@@ -3400,8 +3405,7 @@ static int mtip_hw_shutdown(struct driver_data *dd)
  * Send standby immediate (E0h) to the drive so that it
  * saves its state.
  */
-if (!dd->sr && dd->port)
-mtip_standby_immediate(dd->port);
+mtip_standby_drive(dd);
 
 return 0;
 }
@@ -3424,7 +3428,7 @@ static int mtip_hw_suspend(struct driver_data *dd)
  * Send standby immediate (E0h) to the drive
  * so that it saves its state.
  */
-if (mtip_standby_immediate(dd->port) != 0) {
+if (mtip_standby_drive(dd) != 0) {
 dev_err(>pdev->dev,
 "Failed standby-immediate command\n");
 return -EFAULT;
-- 
1.7.1

[PATCH 05/10] mtip32xx: Avoid issuing standby immediate cmd during FTL rebuild

[Asai Thambi SP]

Prevent standby immediate command from being issued in remove,
suspend and shutdown paths, while drive is performing FTL rebuild
process.

Signed-off-by: Selvan Mani 
Signed-off-by: Vignesh Gunasekaran 
Signed-off-by: Asai Thambi S P 
---
 drivers/block/mtip32xx/mtip32xx.c |   20 
 1 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/block/mtip32xx/mtip32xx.c 
b/drivers/block/mtip32xx/mtip32xx.c
index ca9d35a..ba832a8 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -3329,20 +3329,25 @@ out1:
 return rv;
 }
 
-static void mtip_standby_drive(struct driver_data *dd)
+static int mtip_standby_drive(struct driver_data *dd)
 {
-if (dd->sr)
-return;
+int rv = 0;
 
+if (dd->sr || !dd->port)
+return -ENODEV;
 /*
  * Send standby immediate (E0h) to the drive so that it
  * saves its state.
  */
 if (!test_bit(MTIP_PF_REBUILD_BIT, >port->flags) &&
-!test_bit(MTIP_DDF_SEC_LOCK_BIT, >dd_flag))
-if (mtip_standby_immediate(dd->port))
+!test_bit(MTIP_DDF_REBUILD_FAILED_BIT, >dd_flag) &&
+!test_bit(MTIP_DDF_SEC_LOCK_BIT, >dd_flag)) {
+rv = mtip_standby_immediate(dd->port);
+if (rv)
 dev_warn(>pdev->dev,
 "STANDBY IMMEDIATE failed\n");
+}
+return rv;
 }
 
 /*
@@ -3400,8 +3405,7 @@ static int mtip_hw_shutdown(struct driver_data *dd)
  * Send standby immediate (E0h) to the drive so that it
  * saves its state.
  */
-if (!dd->sr && dd->port)
-mtip_standby_immediate(dd->port);
+mtip_standby_drive(dd);
 
 return 0;
 }
@@ -3424,7 +3428,7 @@ static int mtip_hw_suspend(struct driver_data *dd)
  * Send standby immediate (E0h) to the drive
  * so that it saves its state.
  */
-if (mtip_standby_immediate(dd->port) != 0) {
+if (mtip_standby_drive(dd) != 0) {
 dev_err(>pdev->dev,
 "Failed standby-immediate command\n");
 return -EFAULT;
-- 
1.7.1

[PATCH 04/10] mtip32xx: Print exact time when an internal command is interrupted

[Asai Thambi SP]

Print exact time when an internal command is interrupted.

Signed-off-by: Selvan Mani 
Signed-off-by: Rajesh Kumar Sambandam 
Signed-off-by: Asai Thambi S P 
---
 drivers/block/mtip32xx/mtip32xx.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/block/mtip32xx/mtip32xx.c 
b/drivers/block/mtip32xx/mtip32xx.c
index 30f8246..ca9d35a 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -1127,6 +1127,7 @@ static int mtip_exec_internal_command(struct mtip_port 
*port,
 struct mtip_cmd *int_cmd;
 struct driver_data *dd = port->dd;
 int rv = 0;
+unsigned long start;
 
 /* Make sure the buffer is 8 byte aligned. This is asic specific. */
 if (buffer & 0x0007) {
@@ -1207,6 +1208,8 @@ static int mtip_exec_internal_command(struct mtip_port 
*port,
 /* Populate the command header */
 int_cmd->command_header->byte_count = 0;
 
+start = jiffies;
+
 /* Issue the command to the hardware */
 mtip_issue_non_ncq_command(port, MTIP_TAG_INTERNAL);
 
@@ -1217,8 +1220,9 @@ static int mtip_exec_internal_command(struct mtip_port 
*port,
 msecs_to_jiffies(timeout))) <= 0) {
 if (rv == -ERESTARTSYS) { /* interrupted */
 dev_err(>pdev->dev,
-"Internal command [%02X] was interrupted after %lu ms\n",
-fis->command, timeout);
+"Internal command [%02X] was interrupted after %u ms\n",
+fis->command,
+jiffies_to_msecs(jiffies - start));
 rv = -EINTR;
 goto exec_ic_exit;
 } else if (rv == 0) /* timeout */
-- 
1.7.1

[PATCH 04/10] mtip32xx: Print exact time when an internal command is interrupted

[Asai Thambi SP]

Print exact time when an internal command is interrupted.

Signed-off-by: Selvan Mani 
Signed-off-by: Rajesh Kumar Sambandam 
Signed-off-by: Asai Thambi S P 
---
 drivers/block/mtip32xx/mtip32xx.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/block/mtip32xx/mtip32xx.c 
b/drivers/block/mtip32xx/mtip32xx.c
index 30f8246..ca9d35a 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -1127,6 +1127,7 @@ static int mtip_exec_internal_command(struct mtip_port 
*port,
 struct mtip_cmd *int_cmd;
 struct driver_data *dd = port->dd;
 int rv = 0;
+unsigned long start;
 
 /* Make sure the buffer is 8 byte aligned. This is asic specific. */
 if (buffer & 0x0007) {
@@ -1207,6 +1208,8 @@ static int mtip_exec_internal_command(struct mtip_port 
*port,
 /* Populate the command header */
 int_cmd->command_header->byte_count = 0;
 
+start = jiffies;
+
 /* Issue the command to the hardware */
 mtip_issue_non_ncq_command(port, MTIP_TAG_INTERNAL);
 
@@ -1217,8 +1220,9 @@ static int mtip_exec_internal_command(struct mtip_port 
*port,
 msecs_to_jiffies(timeout))) <= 0) {
 if (rv == -ERESTARTSYS) { /* interrupted */
 dev_err(>pdev->dev,
-"Internal command [%02X] was interrupted after %lu ms\n",
-fis->command, timeout);
+"Internal command [%02X] was interrupted after %u ms\n",
+fis->command,
+jiffies_to_msecs(jiffies - start));
 rv = -EINTR;
 goto exec_ic_exit;
 } else if (rv == 0) /* timeout */
-- 
1.7.1

[PATCH 03/10] mtip32xx: Remove unwanted code from taskfile error handler

[Asai Thambi SP]

Remove setting and clearing MTIP_PF_EH_ACTIVE_BIT flag in
mtip_handle_tfe() as they are redundant. Also avoid waking
up service thread from mtip_handle_tfe() because it is
already woken up in case of taskfile error.

Signed-off-by: Selvan Mani 
Signed-off-by: Rajesh Kumar Sambandam 
Signed-off-by: Asai Thambi S P 
---
 drivers/block/mtip32xx/mtip32xx.c |9 +
 1 files changed, 1 insertions(+), 8 deletions(-)

diff --git a/drivers/block/mtip32xx/mtip32xx.c 
b/drivers/block/mtip32xx/mtip32xx.c
index 4dfe2be..30f8246 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -618,8 +618,6 @@ static void mtip_handle_tfe(struct driver_data *dd)
 
 port = dd->port;
 
-set_bit(MTIP_PF_EH_ACTIVE_BIT, >flags);
-
 if (test_bit(MTIP_PF_IC_ACTIVE_BIT, >flags)) {
 cmd = mtip_cmd_from_tag(dd, MTIP_TAG_INTERNAL);
 dbg_printk(MTIP_DRV_NAME " TFE for the internal command\n");
@@ -628,7 +626,7 @@ static void mtip_handle_tfe(struct driver_data *dd)
 cmd->comp_func(port, MTIP_TAG_INTERNAL,
 cmd, PORT_IRQ_TF_ERR);
 }
-goto handle_tfe_exit;
+return;
 }
 
 /* clear the tag accumulator */
@@ -771,11 +769,6 @@ static void mtip_handle_tfe(struct driver_data *dd)
 }
 }
 print_tags(dd, "reissued (TFE)", tagaccum, cmd_cnt);
-
-handle_tfe_exit:
-/* clear eh_active */
-clear_bit(MTIP_PF_EH_ACTIVE_BIT, >flags);
-wake_up_interruptible(>svc_wait);
 }
 
 /*
-- 
1.7.1

[PATCH 03/10] mtip32xx: Remove unwanted code from taskfile error handler

[Asai Thambi SP]

Remove setting and clearing MTIP_PF_EH_ACTIVE_BIT flag in
mtip_handle_tfe() as they are redundant. Also avoid waking
up service thread from mtip_handle_tfe() because it is
already woken up in case of taskfile error.

Signed-off-by: Selvan Mani 
Signed-off-by: Rajesh Kumar Sambandam 
Signed-off-by: Asai Thambi S P 
---
 drivers/block/mtip32xx/mtip32xx.c |9 +
 1 files changed, 1 insertions(+), 8 deletions(-)

diff --git a/drivers/block/mtip32xx/mtip32xx.c 
b/drivers/block/mtip32xx/mtip32xx.c
index 4dfe2be..30f8246 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -618,8 +618,6 @@ static void mtip_handle_tfe(struct driver_data *dd)
 
 port = dd->port;
 
-set_bit(MTIP_PF_EH_ACTIVE_BIT, >flags);
-
 if (test_bit(MTIP_PF_IC_ACTIVE_BIT, >flags)) {
 cmd = mtip_cmd_from_tag(dd, MTIP_TAG_INTERNAL);
 dbg_printk(MTIP_DRV_NAME " TFE for the internal command\n");
@@ -628,7 +626,7 @@ static void mtip_handle_tfe(struct driver_data *dd)
 cmd->comp_func(port, MTIP_TAG_INTERNAL,
 cmd, PORT_IRQ_TF_ERR);
 }
-goto handle_tfe_exit;
+return;
 }
 
 /* clear the tag accumulator */
@@ -771,11 +769,6 @@ static void mtip_handle_tfe(struct driver_data *dd)
 }
 }
 print_tags(dd, "reissued (TFE)", tagaccum, cmd_cnt);
-
-handle_tfe_exit:
-/* clear eh_active */
-clear_bit(MTIP_PF_EH_ACTIVE_BIT, >flags);
-wake_up_interruptible(>svc_wait);
 }
 
 /*
-- 
1.7.1

[PATCH 02/10] mtip32xx: Fix broken service thread handling

[Asai Thambi SP]

Service thread does not detect the need for taskfile error handling. Fixed the
flag condition to process taskfile error.

Signed-off-by: Selvan Mani 
Signed-off-by: Asai Thambi S P 
---
 drivers/block/mtip32xx/mtip32xx.c |6 +++---
 drivers/block/mtip32xx/mtip32xx.h |5 +
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/block/mtip32xx/mtip32xx.c 
b/drivers/block/mtip32xx/mtip32xx.c
index 37690ab..4dfe2be 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -2986,9 +2986,7 @@ static int mtip_service_thread(void *data)
  * is in progress nor error handling is active
  */
 wait_event_interruptible(port->svc_wait, (port->flags) &&
-!(port->flags & MTIP_PF_PAUSE_IO));
-
-set_bit(MTIP_PF_SVC_THD_ACTIVE_BIT, >flags);
+(port->flags & MTIP_PF_SVC_THD_WORK));
 
 if (kthread_should_stop() ||
 test_bit(MTIP_PF_SVC_THD_STOP_BIT, >flags))
@@ -2998,6 +2996,8 @@ static int mtip_service_thread(void *data)
 >dd_flag)))
 goto st_out;
 
+set_bit(MTIP_PF_SVC_THD_ACTIVE_BIT, >flags);
+
 restart_eh:
 /* Demux bits: start with error handling */
 if (test_bit(MTIP_PF_EH_ACTIVE_BIT, >flags)) {
diff --git a/drivers/block/mtip32xx/mtip32xx.h 
b/drivers/block/mtip32xx/mtip32xx.h
index 29357fd..64bfb82 100644
--- a/drivers/block/mtip32xx/mtip32xx.h
+++ b/drivers/block/mtip32xx/mtip32xx.h
@@ -144,6 +144,11 @@ enum {
 MTIP_PF_REBUILD_BIT = 6,
 MTIP_PF_SVC_THD_STOP_BIT= 8,
 
+MTIP_PF_SVC_THD_WORK= ((1 << MTIP_PF_EH_ACTIVE_BIT) |
+  (1 << MTIP_PF_ISSUE_CMDS_BIT) |
+  (1 << MTIP_PF_REBUILD_BIT) |
+  (1 << MTIP_PF_SVC_THD_STOP_BIT)),
+
 /* below are bit numbers in 'dd_flag' defined in driver_data */
 MTIP_DDF_SEC_LOCK_BIT= 0,
 MTIP_DDF_REMOVE_PENDING_BIT = 1,
-- 
1.7.1

[PATCH 02/10] mtip32xx: Fix broken service thread handling

[Asai Thambi SP]

Service thread does not detect the need for taskfile error handling. Fixed the
flag condition to process taskfile error.

Signed-off-by: Selvan Mani 
Signed-off-by: Asai Thambi S P 
---
 drivers/block/mtip32xx/mtip32xx.c |6 +++---
 drivers/block/mtip32xx/mtip32xx.h |5 +
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/block/mtip32xx/mtip32xx.c 
b/drivers/block/mtip32xx/mtip32xx.c
index 37690ab..4dfe2be 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -2986,9 +2986,7 @@ static int mtip_service_thread(void *data)
  * is in progress nor error handling is active
  */
 wait_event_interruptible(port->svc_wait, (port->flags) &&
-!(port->flags & MTIP_PF_PAUSE_IO));
-
-set_bit(MTIP_PF_SVC_THD_ACTIVE_BIT, >flags);
+(port->flags & MTIP_PF_SVC_THD_WORK));
 
 if (kthread_should_stop() ||
 test_bit(MTIP_PF_SVC_THD_STOP_BIT, >flags))
@@ -2998,6 +2996,8 @@ static int mtip_service_thread(void *data)
 >dd_flag)))
 goto st_out;
 
+set_bit(MTIP_PF_SVC_THD_ACTIVE_BIT, >flags);
+
 restart_eh:
 /* Demux bits: start with error handling */
 if (test_bit(MTIP_PF_EH_ACTIVE_BIT, >flags)) {
diff --git a/drivers/block/mtip32xx/mtip32xx.h 
b/drivers/block/mtip32xx/mtip32xx.h
index 29357fd..64bfb82 100644
--- a/drivers/block/mtip32xx/mtip32xx.h
+++ b/drivers/block/mtip32xx/mtip32xx.h
@@ -144,6 +144,11 @@ enum {
 MTIP_PF_REBUILD_BIT = 6,
 MTIP_PF_SVC_THD_STOP_BIT= 8,
 
+MTIP_PF_SVC_THD_WORK= ((1 << MTIP_PF_EH_ACTIVE_BIT) |
+  (1 << MTIP_PF_ISSUE_CMDS_BIT) |
+  (1 << MTIP_PF_REBUILD_BIT) |
+  (1 << MTIP_PF_SVC_THD_STOP_BIT)),
+
 /* below are bit numbers in 'dd_flag' defined in driver_data */
 MTIP_DDF_SEC_LOCK_BIT= 0,
 MTIP_DDF_REMOVE_PENDING_BIT = 1,
-- 
1.7.1

[PATCH 01/10] mtip32xx: Abort secure erase when drive is mounted

[Asai Thambi SP]

To avoid erasing a device with a mounted filesystem, try to get exclusive
access to the blkdev object corresponding to the device.

Signed-off-by: Selvan Mani 
Signed-off-by: Rajesh Kumar Sambandam 
Signed-off-by: Asai Thambi S P 
---
 drivers/block/mtip32xx/mtip32xx.c |  113 ++---
 drivers/block/mtip32xx/mtip32xx.h |2 +
 2 files changed, 94 insertions(+), 21 deletions(-)

diff --git a/drivers/block/mtip32xx/mtip32xx.c 
b/drivers/block/mtip32xx/mtip32xx.c
index 9b180db..37690ab 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -982,6 +982,28 @@ static void mtip_issue_non_ncq_command(struct mtip_port 
*port, int tag)
 port->cmd_issue[MTIP_TAG_INDEX(tag)]);
 }
 
+static inline int mtip_bdev_claim(struct driver_data *dd)
+{
+if (dd->bdev_claimed == false) {
+igrab(dd->bdev->bd_inode);
+if (blkdev_get(dd->bdev, FMODE_EXCL, dd->bdev) < 0) {
+dev_warn(>pdev->dev, "Drive erase aborted due to non-zero 
refcount (%d)\n",
+dd->bdev->bd_holders);
+return -ERESTARTSYS;
+}
+dd->bdev_claimed = true;
+}
+return 0;
+}
+
+static inline void mtip_bdev_unclaim(struct driver_data *dd)
+{
+if (dd->bdev_claimed) {
+blkdev_put(dd->bdev, FMODE_EXCL);
+dd->bdev_claimed = false;
+}
+}
+
 static bool mtip_pause_ncq(struct mtip_port *port,
 struct host_to_dev_fis *fis)
 {
@@ -991,10 +1013,21 @@ static bool mtip_pause_ncq(struct mtip_port *port,
 reply = port->rxfis + RX_FIS_D2H_REG;
 task_file_data = readl(port->mmio+PORT_TFDATA);
 
-if ((task_file_data & 1))
+if ((task_file_data & 1)) {
+if ((fis->command == ATA_CMD_SEC_SET_PASS) ||
+(fis->command == ATA_CMD_SEC_ERASE_PREP) ||
+(fis->command == ATA_CMD_SEC_ERASE_UNIT) ||
+((fis->command == 0xFC) &&
+(fis->features == 0x27 || fis->features == 0x72 ||
+ fis->features == 0x62 || fis->features == 0x26 ||
+ fis->features == 0x12)))
+mtip_bdev_unclaim(port->dd);
 return false;
+}
 
-if (fis->command == ATA_CMD_SEC_ERASE_PREP) {
+if (fis->command == ATA_CMD_SEC_SET_PASS) {
+mtip_bdev_unclaim(port->dd);
+} else if (fis->command == ATA_CMD_SEC_ERASE_PREP) {
 port->ic_pause_timer = jiffies;
 return true;
 } else if ((fis->command == ATA_CMD_DOWNLOAD_MICRO) &&
@@ -1005,8 +1038,10 @@ static bool mtip_pause_ncq(struct mtip_port *port,
 } else if ((fis->command == ATA_CMD_SEC_ERASE_UNIT) ||
 ((fis->command == 0xFC) &&
 (fis->features == 0x27 || fis->features == 0x72 ||
- fis->features == 0x62 || fis->features == 0x26))) {
+ fis->features == 0x62 || fis->features == 0x26 ||
+ fis->features == 0x12))) {
 clear_bit(MTIP_DDF_SEC_LOCK_BIT, >dd->dd_flag);
+mtip_bdev_unclaim(port->dd);
 /* Com reset after secure erase or lowlevel format */
 mtip_restart_port(port);
 clear_bit(MTIP_PF_SE_ACTIVE_BIT, >flags);
@@ -1110,8 +1145,23 @@ static int mtip_exec_internal_command(struct mtip_port 
*port,
 
 set_bit(MTIP_PF_IC_ACTIVE_BIT, >flags);
 
+/* Check for secure erase while fs mounted */
+if ((fis->command == ATA_CMD_SEC_SET_PASS) ||
+(fis->command == ATA_CMD_SEC_ERASE_PREP) ||
+(fis->command == ATA_CMD_SEC_ERASE_UNIT) ||
+((fis->command == 0xFC) &&
+(fis->features == 0x27 || fis->features == 0x72 ||
+ fis->features == 0x62 || fis->features == 0x26 ||
+ fis->features == 0x12))) {
+rv = mtip_bdev_claim(dd);
+if (rv)
+goto exec_ic_exit;
+}
+
 if (fis->command == ATA_CMD_SEC_ERASE_PREP)
 set_bit(MTIP_PF_SE_ACTIVE_BIT, >flags);
+else if (fis->command == ATA_CMD_SEC_ERASE_UNIT)
+dd->port->ic_pause_timer = 0;
 
 clear_bit(MTIP_PF_DM_ACTIVE_BIT, >flags);
 
@@ -1122,6 +1172,8 @@ static int mtip_exec_internal_command(struct mtip_port 
*port,
 MTIP_QUIESCE_IO_TIMEOUT_MS) < 0) {
 dev_warn(>pdev->dev,
 "Failed to quiesce IO\n");
+
+mtip_bdev_unclaim(dd);
 mtip_put_int_command(dd, int_cmd);
 clear_bit(MTIP_PF_IC_ACTIVE_BIT, >flags);
 wake_up_interruptible(>svc_wait);
@@ -1197,6 +1249,8 @@ static int mtip_exec_internal_command(struct mtip_port 
*port,
 mtip_device_reset(dd); /* recover from timeout issue */
 rv = -EAGAIN;
 goto exec_ic_exit;
+} else {
+rv = 0;
 }
 } else {
 u32 hba_stat, port_stat;
@@ -1247,6 +1301,10 @@ static int mtip_exec_internal_command(struct mtip_port 
*port,
 }
 }
 exec_ic_exit:
+if (rv < 0) {
+

[PATCH 01/10] mtip32xx: Abort secure erase when drive is mounted

[Asai Thambi SP]

To avoid erasing a device with a mounted filesystem, try to get exclusive
access to the blkdev object corresponding to the device.

Signed-off-by: Selvan Mani 
Signed-off-by: Rajesh Kumar Sambandam 
Signed-off-by: Asai Thambi S P 
---
 drivers/block/mtip32xx/mtip32xx.c |  113 ++---
 drivers/block/mtip32xx/mtip32xx.h |2 +
 2 files changed, 94 insertions(+), 21 deletions(-)

diff --git a/drivers/block/mtip32xx/mtip32xx.c 
b/drivers/block/mtip32xx/mtip32xx.c
index 9b180db..37690ab 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -982,6 +982,28 @@ static void mtip_issue_non_ncq_command(struct mtip_port 
*port, int tag)
 port->cmd_issue[MTIP_TAG_INDEX(tag)]);
 }
 
+static inline int mtip_bdev_claim(struct driver_data *dd)
+{
+if (dd->bdev_claimed == false) {
+igrab(dd->bdev->bd_inode);
+if (blkdev_get(dd->bdev, FMODE_EXCL, dd->bdev) < 0) {
+dev_warn(>pdev->dev, "Drive erase aborted due to non-zero 
refcount (%d)\n",
+dd->bdev->bd_holders);
+return -ERESTARTSYS;
+}
+dd->bdev_claimed = true;
+}
+return 0;
+}
+
+static inline void mtip_bdev_unclaim(struct driver_data *dd)
+{
+if (dd->bdev_claimed) {
+blkdev_put(dd->bdev, FMODE_EXCL);
+dd->bdev_claimed = false;
+}
+}
+
 static bool mtip_pause_ncq(struct mtip_port *port,
 struct host_to_dev_fis *fis)
 {
@@ -991,10 +1013,21 @@ static bool mtip_pause_ncq(struct mtip_port *port,
 reply = port->rxfis + RX_FIS_D2H_REG;
 task_file_data = readl(port->mmio+PORT_TFDATA);
 
-if ((task_file_data & 1))
+if ((task_file_data & 1)) {
+if ((fis->command == ATA_CMD_SEC_SET_PASS) ||
+(fis->command == ATA_CMD_SEC_ERASE_PREP) ||
+(fis->command == ATA_CMD_SEC_ERASE_UNIT) ||
+((fis->command == 0xFC) &&
+(fis->features == 0x27 || fis->features == 0x72 ||
+ fis->features == 0x62 || fis->features == 0x26 ||
+ fis->features == 0x12)))
+mtip_bdev_unclaim(port->dd);
 return false;
+}
 
-if (fis->command == ATA_CMD_SEC_ERASE_PREP) {
+if (fis->command == ATA_CMD_SEC_SET_PASS) {
+mtip_bdev_unclaim(port->dd);
+} else if (fis->command == ATA_CMD_SEC_ERASE_PREP) {
 port->ic_pause_timer = jiffies;
 return true;
 } else if ((fis->command == ATA_CMD_DOWNLOAD_MICRO) &&
@@ -1005,8 +1038,10 @@ static bool mtip_pause_ncq(struct mtip_port *port,
 } else if ((fis->command == ATA_CMD_SEC_ERASE_UNIT) ||
 ((fis->command == 0xFC) &&
 (fis->features == 0x27 || fis->features == 0x72 ||
- fis->features == 0x62 || fis->features == 0x26))) {
+ fis->features == 0x62 || fis->features == 0x26 ||
+ fis->features == 0x12))) {
 clear_bit(MTIP_DDF_SEC_LOCK_BIT, >dd->dd_flag);
+mtip_bdev_unclaim(port->dd);
 /* Com reset after secure erase or lowlevel format */
 mtip_restart_port(port);
 clear_bit(MTIP_PF_SE_ACTIVE_BIT, >flags);
@@ -1110,8 +1145,23 @@ static int mtip_exec_internal_command(struct mtip_port 
*port,
 
 set_bit(MTIP_PF_IC_ACTIVE_BIT, >flags);
 
+/* Check for secure erase while fs mounted */
+if ((fis->command == ATA_CMD_SEC_SET_PASS) ||
+(fis->command == ATA_CMD_SEC_ERASE_PREP) ||
+(fis->command == ATA_CMD_SEC_ERASE_UNIT) ||
+((fis->command == 0xFC) &&
+(fis->features == 0x27 || fis->features == 0x72 ||
+ fis->features == 0x62 || fis->features == 0x26 ||
+ fis->features == 0x12))) {
+rv = mtip_bdev_claim(dd);
+if (rv)
+goto exec_ic_exit;
+}
+
 if (fis->command == ATA_CMD_SEC_ERASE_PREP)
 set_bit(MTIP_PF_SE_ACTIVE_BIT, >flags);
+else if (fis->command == ATA_CMD_SEC_ERASE_UNIT)
+dd->port->ic_pause_timer = 0;
 
 clear_bit(MTIP_PF_DM_ACTIVE_BIT, >flags);
 
@@ -1122,6 +1172,8 @@ static int mtip_exec_internal_command(struct mtip_port 
*port,
 MTIP_QUIESCE_IO_TIMEOUT_MS) < 0) {
 dev_warn(>pdev->dev,
 "Failed to quiesce IO\n");
+
+mtip_bdev_unclaim(dd);
 mtip_put_int_command(dd, int_cmd);
 clear_bit(MTIP_PF_IC_ACTIVE_BIT, >flags);
 wake_up_interruptible(>svc_wait);
@@ -1197,6 +1249,8 @@ static int mtip_exec_internal_command(struct mtip_port 
*port,
 mtip_device_reset(dd); /* recover from timeout issue */
 rv = -EAGAIN;
 goto exec_ic_exit;
+} else {
+rv = 0;
 }
 } else {
 u32 hba_stat, port_stat;
@@ -1247,6 +1301,10 @@ static int mtip_exec_internal_command(struct mtip_port 
*port,
 }
 }
 exec_ic_exit:
+if (rv < 0) {
+clear_bit(MTIP_PF_SE_ACTIVE_BIT, >flags);
+mtip_bdev_unclaim(dd);
+}
 

[PATCH 00/10] mtip32xx: various fixes

[Asai Thambi SP]

Hi Jens,

This patchset includes various fixes for mtip32xx driver, tested
on kernel 4.5-rc3

Selvan Mani (10):
  mtip32xx: Abort secure erase when drive is mounted
  mtip32xx: Fix broken service thread handling
  mtip32xx: Remove unwanted code from taskfile error handler
  mtip32xx: Print exact time when an internal command is interrupted
  mtip32xx: Avoid issuing standby immediate cmd during FTL rebuild
  mtip32xx: Fix for rmmod crash when drive is in FTL rebuild
  mtip32xx: Handle safe removal during IO
  mtip32xx: Handle FTL rebuild failure state during device
initialization
  mtip32xx: Add timeout handler
  mtip32xx: Cleanup queued requests after surprise removal

 drivers/block/mtip32xx/mtip32xx.c |  380 +
 drivers/block/mtip32xx/mtip32xx.h |   13 ++-
 2 files changed, 314 insertions(+), 79 deletions(-)

[PATCH 00/10] mtip32xx: various fixes

[Asai Thambi SP]

Hi Jens,

This patchset includes various fixes for mtip32xx driver, tested
on kernel 4.5-rc3

Selvan Mani (10):
  mtip32xx: Abort secure erase when drive is mounted
  mtip32xx: Fix broken service thread handling
  mtip32xx: Remove unwanted code from taskfile error handler
  mtip32xx: Print exact time when an internal command is interrupted
  mtip32xx: Avoid issuing standby immediate cmd during FTL rebuild
  mtip32xx: Fix for rmmod crash when drive is in FTL rebuild
  mtip32xx: Handle safe removal during IO
  mtip32xx: Handle FTL rebuild failure state during device
initialization
  mtip32xx: Add timeout handler
  mtip32xx: Cleanup queued requests after surprise removal

 drivers/block/mtip32xx/mtip32xx.c |  380 +
 drivers/block/mtip32xx/mtip32xx.h |   13 ++-
 2 files changed, 314 insertions(+), 79 deletions(-)

Re: [PATCH v3 11/11] KVM: MMU: apply page track notifier

[Xiao Guangrong]

On 02/19/2016 07:56 PM, Paolo Bonzini wrote:



On 14/02/2016 12:31, Xiao Guangrong wrote:

Register the notifier to receive write track event so that we can update
our shadow page table

It makes kvm_mmu_pte_write() be the callback of the notifier, no function
is changed

Signed-off-by: Xiao Guangrong 
---
  arch/x86/include/asm/kvm_host.h |  5 +++--
  arch/x86/kvm/mmu.c  | 19 +--
  arch/x86/kvm/x86.c  |  4 ++--
  3 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 254d103..5246f07 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -696,6 +696,7 @@ struct kvm_arch {
 */
struct list_head active_mmu_pages;
struct list_head zapped_obsolete_pages;
+   struct kvm_page_track_notifier_node mmu_sp_tracker;
struct kvm_page_track_notifier_head track_notifier_head;

struct list_head assigned_dev_head;
@@ -994,6 +995,8 @@ void kvm_mmu_module_exit(void);
  void kvm_mmu_destroy(struct kvm_vcpu *vcpu);
  int kvm_mmu_create(struct kvm_vcpu *vcpu);
  void kvm_mmu_setup(struct kvm_vcpu *vcpu);
+void kvm_mmu_init_vm(struct kvm *kvm);
+void kvm_mmu_uninit_vm(struct kvm *kvm);
  void kvm_mmu_set_mask_ptes(u64 user_mask, u64 accessed_mask,
u64 dirty_mask, u64 nx_mask, u64 x_mask);

@@ -1133,8 +1136,6 @@ void kvm_pic_clear_all(struct kvm_pic *pic, int 
irq_source_id);

  void kvm_inject_nmi(struct kvm_vcpu *vcpu);

-void kvm_mmu_pte_write(struct kvm_vcpu *vcpu, gpa_t gpa,
-  const u8 *new, int bytes);
  int kvm_mmu_unprotect_page(struct kvm *kvm, gfn_t gfn);
  int kvm_mmu_unprotect_page_virt(struct kvm_vcpu *vcpu, gva_t gva);
  void __kvm_mmu_free_some_pages(struct kvm_vcpu *vcpu);
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index f924e6c..57cf30b 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4316,8 +4316,8 @@ static u64 *get_written_sptes(struct kvm_mmu_page *sp, 
gpa_t gpa, int *nspte)
return spte;
  }

-void kvm_mmu_pte_write(struct kvm_vcpu *vcpu, gpa_t gpa,
-  const u8 *new, int bytes)
+static void kvm_mmu_pte_write(struct kvm_vcpu *vcpu, gpa_t gpa,
+ const u8 *new, int bytes)
  {
gfn_t gfn = gpa >> PAGE_SHIFT;
struct kvm_mmu_page *sp;
@@ -4531,6 +4531,21 @@ void kvm_mmu_setup(struct kvm_vcpu *vcpu)
init_kvm_mmu(vcpu);
  }

+void kvm_mmu_init_vm(struct kvm *kvm)
+{
+   struct kvm_page_track_notifier_node *node = >arch.mmu_sp_tracker;
+
+   node->track_write = kvm_mmu_pte_write;
+   kvm_page_track_register_notifier(kvm, node);
+}
+
+void kvm_mmu_uninit_vm(struct kvm *kvm)
+{
+   struct kvm_page_track_notifier_node *node = >arch.mmu_sp_tracker;
+
+   kvm_page_track_unregister_notifier(kvm, node);
+}
+
  /* The return value indicates if tlb flush on all vcpus is needed. */
  typedef bool (*slot_level_handler) (struct kvm *kvm, struct kvm_rmap_head 
*rmap_head);

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 98019b6..319d572 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4369,7 +4369,6 @@ int emulator_write_phys(struct kvm_vcpu *vcpu, gpa_t gpa,
ret = kvm_vcpu_write_guest(vcpu, gpa, val, bytes);
if (ret < 0)
return 0;
-   kvm_mmu_pte_write(vcpu, gpa, val, bytes);
kvm_page_track_write(vcpu, gpa, val, bytes);
return 1;
  }
@@ -4628,7 +4627,6 @@ static int emulator_cmpxchg_emulated(struct 
x86_emulate_ctxt *ctxt,
return X86EMUL_CMPXCHG_FAILED;

kvm_vcpu_mark_page_dirty(vcpu, gpa >> PAGE_SHIFT);
-   kvm_mmu_pte_write(vcpu, gpa, new, bytes);
kvm_page_track_write(vcpu, gpa, new, bytes);

return X86EMUL_CONTINUE;
@@ -7751,6 +7749,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
INIT_DELAYED_WORK(>arch.kvmclock_sync_work, kvmclock_sync_fn);

kvm_page_track_init(kvm);
+   kvm_mmu_init_vm(kvm);

return 0;
  }
@@ -7878,6 +7877,7 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
kfree(kvm->arch.vioapic);
kvm_free_vcpus(kvm);
kfree(rcu_dereference_check(kvm->arch.apic_map, 1));
+   kvm_mmu_uninit_vm(kvm);


This function is not necessary, since the VM is disappearing anyway and
the page tracker is not going to be called.


I think it is still necessary, as we are using srcu to protect the notifier, so
we should wait all the callers of notifier callbacks gone, i.e, 
synchronize_srcu()
is needed anyway.

Re: [PATCH v3 11/11] KVM: MMU: apply page track notifier

[Xiao Guangrong]

On 02/19/2016 07:56 PM, Paolo Bonzini wrote:



On 14/02/2016 12:31, Xiao Guangrong wrote:

Register the notifier to receive write track event so that we can update
our shadow page table

It makes kvm_mmu_pte_write() be the callback of the notifier, no function
is changed

Signed-off-by: Xiao Guangrong 
---
  arch/x86/include/asm/kvm_host.h |  5 +++--
  arch/x86/kvm/mmu.c  | 19 +--
  arch/x86/kvm/x86.c  |  4 ++--
  3 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 254d103..5246f07 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -696,6 +696,7 @@ struct kvm_arch {
 */
struct list_head active_mmu_pages;
struct list_head zapped_obsolete_pages;
+   struct kvm_page_track_notifier_node mmu_sp_tracker;
struct kvm_page_track_notifier_head track_notifier_head;

struct list_head assigned_dev_head;
@@ -994,6 +995,8 @@ void kvm_mmu_module_exit(void);
  void kvm_mmu_destroy(struct kvm_vcpu *vcpu);
  int kvm_mmu_create(struct kvm_vcpu *vcpu);
  void kvm_mmu_setup(struct kvm_vcpu *vcpu);
+void kvm_mmu_init_vm(struct kvm *kvm);
+void kvm_mmu_uninit_vm(struct kvm *kvm);
  void kvm_mmu_set_mask_ptes(u64 user_mask, u64 accessed_mask,
u64 dirty_mask, u64 nx_mask, u64 x_mask);

@@ -1133,8 +1136,6 @@ void kvm_pic_clear_all(struct kvm_pic *pic, int 
irq_source_id);

  void kvm_inject_nmi(struct kvm_vcpu *vcpu);

-void kvm_mmu_pte_write(struct kvm_vcpu *vcpu, gpa_t gpa,
-  const u8 *new, int bytes);
  int kvm_mmu_unprotect_page(struct kvm *kvm, gfn_t gfn);
  int kvm_mmu_unprotect_page_virt(struct kvm_vcpu *vcpu, gva_t gva);
  void __kvm_mmu_free_some_pages(struct kvm_vcpu *vcpu);
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index f924e6c..57cf30b 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4316,8 +4316,8 @@ static u64 *get_written_sptes(struct kvm_mmu_page *sp, 
gpa_t gpa, int *nspte)
return spte;
  }

-void kvm_mmu_pte_write(struct kvm_vcpu *vcpu, gpa_t gpa,
-  const u8 *new, int bytes)
+static void kvm_mmu_pte_write(struct kvm_vcpu *vcpu, gpa_t gpa,
+ const u8 *new, int bytes)
  {
gfn_t gfn = gpa >> PAGE_SHIFT;
struct kvm_mmu_page *sp;
@@ -4531,6 +4531,21 @@ void kvm_mmu_setup(struct kvm_vcpu *vcpu)
init_kvm_mmu(vcpu);
  }

+void kvm_mmu_init_vm(struct kvm *kvm)
+{
+   struct kvm_page_track_notifier_node *node = >arch.mmu_sp_tracker;
+
+   node->track_write = kvm_mmu_pte_write;
+   kvm_page_track_register_notifier(kvm, node);
+}
+
+void kvm_mmu_uninit_vm(struct kvm *kvm)
+{
+   struct kvm_page_track_notifier_node *node = >arch.mmu_sp_tracker;
+
+   kvm_page_track_unregister_notifier(kvm, node);
+}
+
  /* The return value indicates if tlb flush on all vcpus is needed. */
  typedef bool (*slot_level_handler) (struct kvm *kvm, struct kvm_rmap_head 
*rmap_head);

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 98019b6..319d572 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4369,7 +4369,6 @@ int emulator_write_phys(struct kvm_vcpu *vcpu, gpa_t gpa,
ret = kvm_vcpu_write_guest(vcpu, gpa, val, bytes);
if (ret < 0)
return 0;
-   kvm_mmu_pte_write(vcpu, gpa, val, bytes);
kvm_page_track_write(vcpu, gpa, val, bytes);
return 1;
  }
@@ -4628,7 +4627,6 @@ static int emulator_cmpxchg_emulated(struct 
x86_emulate_ctxt *ctxt,
return X86EMUL_CMPXCHG_FAILED;

kvm_vcpu_mark_page_dirty(vcpu, gpa >> PAGE_SHIFT);
-   kvm_mmu_pte_write(vcpu, gpa, new, bytes);
kvm_page_track_write(vcpu, gpa, new, bytes);

return X86EMUL_CONTINUE;
@@ -7751,6 +7749,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
INIT_DELAYED_WORK(>arch.kvmclock_sync_work, kvmclock_sync_fn);

kvm_page_track_init(kvm);
+   kvm_mmu_init_vm(kvm);

return 0;
  }
@@ -7878,6 +7877,7 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
kfree(kvm->arch.vioapic);
kvm_free_vcpus(kvm);
kfree(rcu_dereference_check(kvm->arch.apic_map, 1));
+   kvm_mmu_uninit_vm(kvm);


This function is not necessary, since the VM is disappearing anyway and
the page tracker is not going to be called.


I think it is still necessary, as we are using srcu to protect the notifier, so
we should wait all the callers of notifier callbacks gone, i.e, 
synchronize_srcu()
is needed anyway.

Re: [PATCH v3 10/11] KVM: MMU: clear write-flooding on the fast path of tracked page

[Xiao Guangrong]

On 02/19/2016 07:55 PM, Paolo Bonzini wrote:



On 14/02/2016 12:31, Xiao Guangrong wrote:

If the page fault is caused by write access on write tracked page, the
real shadow page walking is skipped, we lost the chance to clear write
flooding for the page structure current vcpu is using

Fix it by locklessly waking shadow page table to clear write flooding
on the shadow page structure out of mmu-lock. So that we change the
count to atomic_t


Should this be moved earlier in the series, so that the issue never
surfaces?


Okay, i will move it to the place that is behind:
[PATCH v3 06/11] KVM: MMU: let page fault handler be aware tracked page

Re: [PATCH v3 10/11] KVM: MMU: clear write-flooding on the fast path of tracked page

[Xiao Guangrong]

On 02/19/2016 07:55 PM, Paolo Bonzini wrote:



On 14/02/2016 12:31, Xiao Guangrong wrote:

If the page fault is caused by write access on write tracked page, the
real shadow page walking is skipped, we lost the chance to clear write
flooding for the page structure current vcpu is using

Fix it by locklessly waking shadow page table to clear write flooding
on the shadow page structure out of mmu-lock. So that we change the
count to atomic_t


Should this be moved earlier in the series, so that the issue never
surfaces?


Okay, i will move it to the place that is behind:
[PATCH v3 06/11] KVM: MMU: let page fault handler be aware tracked page

Re: [PATCH 10/56] staging/lustre: Remove ldlm type/mode typedefs

[kbuild test robot]

Hi Oleg,

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.5-rc5 next-20160222]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/green-linuxhacker-ru/More-Lustre-cleanups/20160223-120654
config: sparc64-allyesconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

Note: the 
linux-review/green-linuxhacker-ru/More-Lustre-cleanups/20160223-120654 HEAD 
340181b90a18083de9509c39311e6e7859b89274 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   In file included from 
drivers/staging/lustre/lustre/fid/../include/lustre_export.h:51:0,
from drivers/staging/lustre/lustre/fid/../include/obd.h:54,
from drivers/staging/lustre/lustre/fid/fid_request.c:48:
>> drivers/staging/lustre/lustre/fid/../include/lustre_dlm.h:852:2: error: 
>> unknown type name 'ldlm_mode_t'
 ldlm_mode_t  lr_most_restr;
 ^
--
   In file included from 
drivers/staging/lustre/lustre/fld/../include/lustre_export.h:51:0,
from drivers/staging/lustre/lustre/fld/../include/obd.h:54,
from drivers/staging/lustre/lustre/fld/fld_request.c:49:
>> drivers/staging/lustre/lustre/fld/../include/lustre_dlm.h:852:2: error: 
>> unknown type name 'ldlm_mode_t'
 ldlm_mode_t  lr_most_restr;
 ^
--
   In file included from 
drivers/staging/lustre/lustre/llite/../include/linux/../lustre_export.h:51:0,
from 
drivers/staging/lustre/lustre/llite/../include/linux/../obd.h:54,
from 
drivers/staging/lustre/lustre/llite/../include/linux/../obd_class.h:42,
from 
drivers/staging/lustre/lustre/llite/../include/linux/lustre_lite.h:47,
from 
drivers/staging/lustre/lustre/llite/../include/lustre_lite.h:45,
from drivers/staging/lustre/lustre/llite/dcache.c:44:
>> drivers/staging/lustre/lustre/llite/../include/linux/../lustre_dlm.h:852:2: 
>> error: unknown type name 'ldlm_mode_t'
 ldlm_mode_t  lr_most_restr;
 ^
--
   In file included from 
drivers/staging/lustre/lustre/llite/../include/lustre_export.h:51:0,
from 
drivers/staging/lustre/lustre/llite/../include/obd.h:54,
from 
drivers/staging/lustre/lustre/llite/../include/obd_class.h:42,
from drivers/staging/lustre/lustre/llite/dir.c:52:
>> drivers/staging/lustre/lustre/llite/../include/lustre_dlm.h:852:2: error: 
>> unknown type name 'ldlm_mode_t'
 ldlm_mode_t  lr_most_restr;
 ^
--
   In file included from 
drivers/staging/lustre/lustre/lmv/../include/lustre_export.h:51:0,
from drivers/staging/lustre/lustre/lmv/../include/obd.h:54,
from 
drivers/staging/lustre/lustre/lmv/../include/obd_class.h:42,
from drivers/staging/lustre/lustre/lmv/lmv_obd.c:52:
>> drivers/staging/lustre/lustre/lmv/../include/lustre_dlm.h:852:2: error: 
>> unknown type name 'ldlm_mode_t'
 ldlm_mode_t  lr_most_restr;
 ^
--
   In file included from drivers/staging/lustre/lustre/lov/lov_obd.c:51:0:
>> drivers/staging/lustre/lustre/lov/../include/lustre_dlm.h:852:2: error: 
>> unknown type name 'ldlm_mode_t'
 ldlm_mode_t  lr_most_restr;
 ^
--
   In file included from 
drivers/staging/lustre/lustre/mdc/../include/lustre_export.h:51:0,
from drivers/staging/lustre/lustre/mdc/../include/obd.h:54,
from 
drivers/staging/lustre/lustre/mdc/../include/obd_class.h:42,
from drivers/staging/lustre/lustre/mdc/mdc_request.c:46:
>> drivers/staging/lustre/lustre/mdc/../include/lustre_dlm.h:852:2: error: 
>> unknown type name 'ldlm_mode_t'
 ldlm_mode_t  lr_most_restr;
 ^
--
   In file included from 
drivers/staging/lustre/lustre/mgc/../include/lustre_export.h:51:0,
from drivers/staging/lustre/lustre/mgc/../include/obd.h:54,
from 
drivers/staging/lustre/lustre/mgc/../include/obd_class.h:42,
from drivers/staging/lustre/lustre/mgc/mgc_request.c:45:
>> drivers/staging/lustre/lustre/mgc/../include/lustre_dlm.h:852:2: error: 
>> unknown type name 'ldlm_mode_t'
 ldlm_mode_t  lr_most_restr;
 ^
--
   In file included from 
drivers/staging/lustre/lustre/obdclass/../include/lustre_export.h:51:0,
from 
drivers/staging/lustre/lustre/obdclass/../include/obd.h:54,
from 
drivers/staging/lustre/lustre/obdclass/../include/obd_class.h:42,
from drivers/staging/lustre/lus

Re: [PATCH 10/56] staging/lustre: Remove ldlm type/mode typedefs

[kbuild test robot]

Hi Oleg,

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.5-rc5 next-20160222]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/green-linuxhacker-ru/More-Lustre-cleanups/20160223-120654
config: sparc64-allyesconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

Note: the 
linux-review/green-linuxhacker-ru/More-Lustre-cleanups/20160223-120654 HEAD 
340181b90a18083de9509c39311e6e7859b89274 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   In file included from 
drivers/staging/lustre/lustre/fid/../include/lustre_export.h:51:0,
from drivers/staging/lustre/lustre/fid/../include/obd.h:54,
from drivers/staging/lustre/lustre/fid/fid_request.c:48:
>> drivers/staging/lustre/lustre/fid/../include/lustre_dlm.h:852:2: error: 
>> unknown type name 'ldlm_mode_t'
 ldlm_mode_t  lr_most_restr;
 ^
--
   In file included from 
drivers/staging/lustre/lustre/fld/../include/lustre_export.h:51:0,
from drivers/staging/lustre/lustre/fld/../include/obd.h:54,
from drivers/staging/lustre/lustre/fld/fld_request.c:49:
>> drivers/staging/lustre/lustre/fld/../include/lustre_dlm.h:852:2: error: 
>> unknown type name 'ldlm_mode_t'
 ldlm_mode_t  lr_most_restr;
 ^
--
   In file included from 
drivers/staging/lustre/lustre/llite/../include/linux/../lustre_export.h:51:0,
from 
drivers/staging/lustre/lustre/llite/../include/linux/../obd.h:54,
from 
drivers/staging/lustre/lustre/llite/../include/linux/../obd_class.h:42,
from 
drivers/staging/lustre/lustre/llite/../include/linux/lustre_lite.h:47,
from 
drivers/staging/lustre/lustre/llite/../include/lustre_lite.h:45,
from drivers/staging/lustre/lustre/llite/dcache.c:44:
>> drivers/staging/lustre/lustre/llite/../include/linux/../lustre_dlm.h:852:2: 
>> error: unknown type name 'ldlm_mode_t'
 ldlm_mode_t  lr_most_restr;
 ^
--
   In file included from 
drivers/staging/lustre/lustre/llite/../include/lustre_export.h:51:0,
from 
drivers/staging/lustre/lustre/llite/../include/obd.h:54,
from 
drivers/staging/lustre/lustre/llite/../include/obd_class.h:42,
from drivers/staging/lustre/lustre/llite/dir.c:52:
>> drivers/staging/lustre/lustre/llite/../include/lustre_dlm.h:852:2: error: 
>> unknown type name 'ldlm_mode_t'
 ldlm_mode_t  lr_most_restr;
 ^
--
   In file included from 
drivers/staging/lustre/lustre/lmv/../include/lustre_export.h:51:0,
from drivers/staging/lustre/lustre/lmv/../include/obd.h:54,
from 
drivers/staging/lustre/lustre/lmv/../include/obd_class.h:42,
from drivers/staging/lustre/lustre/lmv/lmv_obd.c:52:
>> drivers/staging/lustre/lustre/lmv/../include/lustre_dlm.h:852:2: error: 
>> unknown type name 'ldlm_mode_t'
 ldlm_mode_t  lr_most_restr;
 ^
--
   In file included from drivers/staging/lustre/lustre/lov/lov_obd.c:51:0:
>> drivers/staging/lustre/lustre/lov/../include/lustre_dlm.h:852:2: error: 
>> unknown type name 'ldlm_mode_t'
 ldlm_mode_t  lr_most_restr;
 ^
--
   In file included from 
drivers/staging/lustre/lustre/mdc/../include/lustre_export.h:51:0,
from drivers/staging/lustre/lustre/mdc/../include/obd.h:54,
from 
drivers/staging/lustre/lustre/mdc/../include/obd_class.h:42,
from drivers/staging/lustre/lustre/mdc/mdc_request.c:46:
>> drivers/staging/lustre/lustre/mdc/../include/lustre_dlm.h:852:2: error: 
>> unknown type name 'ldlm_mode_t'
 ldlm_mode_t  lr_most_restr;
 ^
--
   In file included from 
drivers/staging/lustre/lustre/mgc/../include/lustre_export.h:51:0,
from drivers/staging/lustre/lustre/mgc/../include/obd.h:54,
from 
drivers/staging/lustre/lustre/mgc/../include/obd_class.h:42,
from drivers/staging/lustre/lustre/mgc/mgc_request.c:45:
>> drivers/staging/lustre/lustre/mgc/../include/lustre_dlm.h:852:2: error: 
>> unknown type name 'ldlm_mode_t'
 ldlm_mode_t  lr_most_restr;
 ^
--
   In file included from 
drivers/staging/lustre/lustre/obdclass/../include/lustre_export.h:51:0,
from 
drivers/staging/lustre/lustre/obdclass/../include/obd.h:54,
from 
drivers/staging/lustre/lustre/obdclass/../include/obd_class.h:42,
from drivers/staging/lustre/lus

Re: [PATCH] net: jme: fix suspend/resume on JMC260

[David Miller]

From: Diego Viola 
Date: Mon, 22 Feb 2016 22:58:48 -0300

> On Mon, Feb 22, 2016 at 10:46 PM, Fabio Estevam  wrote:
>> On Mon, Feb 22, 2016 at 9:32 PM, Diego Viola  wrote:
>>> Signed-off-by: Diego Viola 
>>
>> You should write a commit log.
> 
> I thought about including the link to my bug report:
> https://bugzilla.kernel.org/show_bug.cgi?id=112351
> 
> What else would you suggest I add to the commit message?

The commit message is where you describe the change you are making.

This includes exactly what you are fixing, how you are doing it, and why
you are doing it that way.

Empty commit log messages are %99.9 of the time completely
inappropriate.

Re: [PATCH v3 07/11] KVM: page track: add notifier support

[Xiao Guangrong]

On 02/19/2016 07:51 PM, Paolo Bonzini wrote:



On 14/02/2016 12:31, Xiao Guangrong wrote:



+void kvm_page_track_write(struct kvm_vcpu *vcpu, gpa_t gpa, const u8 *new,
+ int bytes)
+{
+   struct kvm_page_track_notifier_head *head;
+   struct kvm_page_track_notifier_node *n;
+   int idx;
+
+   head = >kvm->arch.track_notifier_head;


Please check outside SRCU if the notifier list is empty.  If so, there
is no need to do the (relatively) expensive srcu_read_lock/unlock.



Good to me. I will check it by calling hlist_empty() first before holding
the srcu read lock.


Paolo


+   idx = srcu_read_lock(>track_srcu);
+   hlist_for_each_entry_rcu(n, >track_notifier_list, node)
+   if (n->track_write)
+   n->track_write(vcpu, gpa, new, bytes);
+   srcu_read_unlock(>track_srcu, idx);
+}
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index e25ebb7..98019b6 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4370,6 +4370,7 @@ int emulator_write_phys(struct kvm_vcpu *vcpu, gpa_t gpa,
if (ret < 0)
return 0;


A kvm_vcpu_mark_page_dirty is missing here, isn't it?  I can take care
of it, but it would be great if you double-checked this.  If so, that
should be fixed in stable kernels too.


No. It's already been handled in emulator_write_phys() -> kvm_vcpu_write_guest()
-> kvm_vcpu_write_guest_page() -> __kvm_write_guest_page().



Can you add a kvm_vcpu_note_page_write(vcpu, gpa, val, bytes) function
that takes care of calling kvm_vcpu_mark_page_dirty, kvm_mmu_pte_write
and kvm_page_track-write?



After this patchset, kvm_mmu_pte_write is only a static notifier callback called
by kvm_page_track_write().

And the dirty tracking in emulator_write_phys() is handled in a public API (as 
my
explanation above), in emulator_cmpxchg_emulated is handled by itself. So i 
think
it is better to leaving dirty tracking to the separate paths, no? :)

Re: [PATCH] net: jme: fix suspend/resume on JMC260

[David Miller]

From: Diego Viola 
Date: Mon, 22 Feb 2016 22:58:48 -0300

> On Mon, Feb 22, 2016 at 10:46 PM, Fabio Estevam  wrote:
>> On Mon, Feb 22, 2016 at 9:32 PM, Diego Viola  wrote:
>>> Signed-off-by: Diego Viola 
>>
>> You should write a commit log.
> 
> I thought about including the link to my bug report:
> https://bugzilla.kernel.org/show_bug.cgi?id=112351
> 
> What else would you suggest I add to the commit message?

The commit message is where you describe the change you are making.

This includes exactly what you are fixing, how you are doing it, and why
you are doing it that way.

Empty commit log messages are %99.9 of the time completely
inappropriate.

Re: [PATCH v3 07/11] KVM: page track: add notifier support

[Xiao Guangrong]

On 02/19/2016 07:51 PM, Paolo Bonzini wrote:



On 14/02/2016 12:31, Xiao Guangrong wrote:



+void kvm_page_track_write(struct kvm_vcpu *vcpu, gpa_t gpa, const u8 *new,
+ int bytes)
+{
+   struct kvm_page_track_notifier_head *head;
+   struct kvm_page_track_notifier_node *n;
+   int idx;
+
+   head = >kvm->arch.track_notifier_head;


Please check outside SRCU if the notifier list is empty.  If so, there
is no need to do the (relatively) expensive srcu_read_lock/unlock.



Good to me. I will check it by calling hlist_empty() first before holding
the srcu read lock.


Paolo


+   idx = srcu_read_lock(>track_srcu);
+   hlist_for_each_entry_rcu(n, >track_notifier_list, node)
+   if (n->track_write)
+   n->track_write(vcpu, gpa, new, bytes);
+   srcu_read_unlock(>track_srcu, idx);
+}
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index e25ebb7..98019b6 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4370,6 +4370,7 @@ int emulator_write_phys(struct kvm_vcpu *vcpu, gpa_t gpa,
if (ret < 0)
return 0;


A kvm_vcpu_mark_page_dirty is missing here, isn't it?  I can take care
of it, but it would be great if you double-checked this.  If so, that
should be fixed in stable kernels too.


No. It's already been handled in emulator_write_phys() -> kvm_vcpu_write_guest()
-> kvm_vcpu_write_guest_page() -> __kvm_write_guest_page().



Can you add a kvm_vcpu_note_page_write(vcpu, gpa, val, bytes) function
that takes care of calling kvm_vcpu_mark_page_dirty, kvm_mmu_pte_write
and kvm_page_track-write?



After this patchset, kvm_mmu_pte_write is only a static notifier callback called
by kvm_page_track_write().

And the dirty tracking in emulator_write_phys() is handled in a public API (as 
my
explanation above), in emulator_cmpxchg_emulated is handled by itself. So i 
think
it is better to leaving dirty tracking to the separate paths, no? :)

[PATCH] arm64: dts: uniphier: rename PH1-LD10 to PH1-LD20

[Masahiro Yamada]

Due to the company's awful projecting, this chip has been renamed to
PH1-LD20.  It has not been shipped yet, this change would not give
much impact on our customers.

Signed-off-by: Masahiro Yamada 
---

Olof, Arnd,

Please apply this patch along with my series
"[PATCH 0/9] ARM: uniphier: UniPhier updates for Linux 4.6-rc1".

If it goes to a different branch, it will cause a big merge conflict later.


 arch/arm64/boot/dts/socionext/Makefile| 2 +-
 .../{uniphier-ph1-ld10-ref.dts => uniphier-ph1-ld20-ref.dts}  | 8 
 .../socionext/{uniphier-ph1-ld10.dtsi => uniphier-ph1-ld20.dtsi}  | 6 +++---
 3 files changed, 8 insertions(+), 8 deletions(-)
 rename arch/arm64/boot/dts/socionext/{uniphier-ph1-ld10-ref.dts => 
uniphier-ph1-ld20-ref.dts} (92%)
 rename arch/arm64/boot/dts/socionext/{uniphier-ph1-ld10.dtsi => 
uniphier-ph1-ld20.dtsi} (98%)

diff --git a/arch/arm64/boot/dts/socionext/Makefile 
b/arch/arm64/boot/dts/socionext/Makefile
index 8d72771..299b67e 100644
--- a/arch/arm64/boot/dts/socionext/Makefile
+++ b/arch/arm64/boot/dts/socionext/Makefile
@@ -1,4 +1,4 @@
-dtb-$(CONFIG_ARCH_UNIPHIER) += uniphier-ph1-ld10-ref.dtb
+dtb-$(CONFIG_ARCH_UNIPHIER) += uniphier-ph1-ld20-ref.dtb
 
 always := $(dtb-y)
 clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts 
b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20-ref.dts
similarity index 92%
rename from arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
rename to arch/arm64/boot/dts/socionext/uniphier-ph1-ld20-ref.dts
index e5c8a20..727ae5f 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20-ref.dts
@@ -1,5 +1,5 @@
 /*
- * Device Tree Source for UniPhier PH1-LD10 Reference Board
+ * Device Tree Source for UniPhier PH1-LD20 Reference Board
  *
  * Copyright (C) 2015 Masahiro Yamada 
  *
@@ -43,12 +43,12 @@
  */
 
 /dts-v1/;
-/include/ "uniphier-ph1-ld10.dtsi"
+/include/ "uniphier-ph1-ld20.dtsi"
 /include/ "uniphier-support-card.dtsi"
 
 / {
-   model = "UniPhier PH1-LD10 Reference Board";
-   compatible = "socionext,ph1-ld10-ref", "socionext,ph1-ld10";
+   model = "UniPhier PH1-LD20 Reference Board";
+   compatible = "socionext,ph1-ld20-ref", "socionext,ph1-ld20";
 
memory {
device_type = "memory";
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10.dtsi 
b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi
similarity index 98%
rename from arch/arm64/boot/dts/socionext/uniphier-ph1-ld10.dtsi
rename to arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi
index 84637eb..65e9651 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi
@@ -1,5 +1,5 @@
 /*
- * Device Tree Source for UniPhier PH1-LD10 SoC
+ * Device Tree Source for UniPhier PH1-LD20 SoC
  *
  * Copyright (C) 2015 Masahiro Yamada 
  *
@@ -43,7 +43,7 @@
  */
 
 / {
-   compatible = "socionext,ph1-ld10";
+   compatible = "socionext,ph1-ld20";
#address-cells = <2>;
#size-cells = <2>;
interrupt-parent = <>;
@@ -268,7 +268,7 @@
};
 
pinctrl: pinctrl@5f801000 {
-   compatible = "socionext,ph1-ld10-pinctrl", "syscon";
+   compatible = "socionext,ph1-ld20-pinctrl", "syscon";
reg = <0x5f801000 0xe00>;
};
 
-- 
1.9.1

[PATCH] arm64: dts: uniphier: rename PH1-LD10 to PH1-LD20

[Masahiro Yamada]

Due to the company's awful projecting, this chip has been renamed to
PH1-LD20.  It has not been shipped yet, this change would not give
much impact on our customers.

Signed-off-by: Masahiro Yamada 
---

Olof, Arnd,

Please apply this patch along with my series
"[PATCH 0/9] ARM: uniphier: UniPhier updates for Linux 4.6-rc1".

If it goes to a different branch, it will cause a big merge conflict later.


 arch/arm64/boot/dts/socionext/Makefile| 2 +-
 .../{uniphier-ph1-ld10-ref.dts => uniphier-ph1-ld20-ref.dts}  | 8 
 .../socionext/{uniphier-ph1-ld10.dtsi => uniphier-ph1-ld20.dtsi}  | 6 +++---
 3 files changed, 8 insertions(+), 8 deletions(-)
 rename arch/arm64/boot/dts/socionext/{uniphier-ph1-ld10-ref.dts => 
uniphier-ph1-ld20-ref.dts} (92%)
 rename arch/arm64/boot/dts/socionext/{uniphier-ph1-ld10.dtsi => 
uniphier-ph1-ld20.dtsi} (98%)

diff --git a/arch/arm64/boot/dts/socionext/Makefile 
b/arch/arm64/boot/dts/socionext/Makefile
index 8d72771..299b67e 100644
--- a/arch/arm64/boot/dts/socionext/Makefile
+++ b/arch/arm64/boot/dts/socionext/Makefile
@@ -1,4 +1,4 @@
-dtb-$(CONFIG_ARCH_UNIPHIER) += uniphier-ph1-ld10-ref.dtb
+dtb-$(CONFIG_ARCH_UNIPHIER) += uniphier-ph1-ld20-ref.dtb
 
 always := $(dtb-y)
 clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts 
b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20-ref.dts
similarity index 92%
rename from arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
rename to arch/arm64/boot/dts/socionext/uniphier-ph1-ld20-ref.dts
index e5c8a20..727ae5f 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20-ref.dts
@@ -1,5 +1,5 @@
 /*
- * Device Tree Source for UniPhier PH1-LD10 Reference Board
+ * Device Tree Source for UniPhier PH1-LD20 Reference Board
  *
  * Copyright (C) 2015 Masahiro Yamada 
  *
@@ -43,12 +43,12 @@
  */
 
 /dts-v1/;
-/include/ "uniphier-ph1-ld10.dtsi"
+/include/ "uniphier-ph1-ld20.dtsi"
 /include/ "uniphier-support-card.dtsi"
 
 / {
-   model = "UniPhier PH1-LD10 Reference Board";
-   compatible = "socionext,ph1-ld10-ref", "socionext,ph1-ld10";
+   model = "UniPhier PH1-LD20 Reference Board";
+   compatible = "socionext,ph1-ld20-ref", "socionext,ph1-ld20";
 
memory {
device_type = "memory";
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10.dtsi 
b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi
similarity index 98%
rename from arch/arm64/boot/dts/socionext/uniphier-ph1-ld10.dtsi
rename to arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi
index 84637eb..65e9651 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi
@@ -1,5 +1,5 @@
 /*
- * Device Tree Source for UniPhier PH1-LD10 SoC
+ * Device Tree Source for UniPhier PH1-LD20 SoC
  *
  * Copyright (C) 2015 Masahiro Yamada 
  *
@@ -43,7 +43,7 @@
  */
 
 / {
-   compatible = "socionext,ph1-ld10";
+   compatible = "socionext,ph1-ld20";
#address-cells = <2>;
#size-cells = <2>;
interrupt-parent = <>;
@@ -268,7 +268,7 @@
};
 
pinctrl: pinctrl@5f801000 {
-   compatible = "socionext,ph1-ld10-pinctrl", "syscon";
+   compatible = "socionext,ph1-ld20-pinctrl", "syscon";
reg = <0x5f801000 0xe00>;
};
 
-- 
1.9.1

Re: [PATCH v4 1/1] ideapad-laptop: Add ideapad Y700 (15) to the no_hw_rfkill DMI list

[John Dahlstrom]

On Mon, 22 Feb 2016, Darren Hart wrote:


Unfortunately, backporting this to stable is not quite so simple.

First, 3.16 doesn't really work as between 3.16 and 3.17 the following patch
landed:

ce363c2 ideapad-laptop: Change Lenovo Yoga 2 series rfkill handling

Which changes the name of the dmi_system_id struct from rfkill_blacklist to
no_hw_rfkill_list.

Following that, there were several additions to the list which should be applied
before this patch to each stable kernel for which they haven't been picked up in
order for this one to apply cleanly. Several of those are included below:



Despite the change in the no_hw_rfkill_list, GNU patch still yields the
correct output but with fuzz. I interpret apply cleanly to mean that
the patch must also apply with zero fuzz, such as with "patch -F 0".

In the case where the context has changed (including changes to an
enclosing struct or function), I gather that a patch exactly modified
for an older kernel is to be sent to sta...@vger.kernel.org after the 
unmodified patch is accepted upstream with a commit ID.



$ git l v3.17.. drivers/platform/x86/ideapad-laptop.c

[...]


If you are going to specify a kernel version, you should also include the
commits above necessary to make the patch apply cleanly. That would be a long
list as you would need many of these for each version.



Thank you for that information. One commit is sufficient to apply the 
patch to all kernel versions without fuzz:


4fa9dab ideapad_laptop: Lenovo G50-30 fix rfkill reports wireless blocked


What I'm going to do is include a single Cc to stable line without a kernel
version. The maintainers will pull that back as far as they can using their own
judgement. If you want this to go back earlier than they do on their own, you
should submit it to linux-stable directly and include the Cc lines for the
dependencies for each kernel you care to see this backported to. See the
stable-kernel-rules for the specific formatting to accomplish this.



I've submitted v5 of the patch with a single Cc line with the prerequisite
kernel(s) and commit ID specified exactly.

Kind regards,

John

Re: [PATCH v4 1/1] ideapad-laptop: Add ideapad Y700 (15) to the no_hw_rfkill DMI list

[John Dahlstrom]

On Mon, 22 Feb 2016, Darren Hart wrote:


Unfortunately, backporting this to stable is not quite so simple.

First, 3.16 doesn't really work as between 3.16 and 3.17 the following patch
landed:

ce363c2 ideapad-laptop: Change Lenovo Yoga 2 series rfkill handling

Which changes the name of the dmi_system_id struct from rfkill_blacklist to
no_hw_rfkill_list.

Following that, there were several additions to the list which should be applied
before this patch to each stable kernel for which they haven't been picked up in
order for this one to apply cleanly. Several of those are included below:



Despite the change in the no_hw_rfkill_list, GNU patch still yields the
correct output but with fuzz. I interpret apply cleanly to mean that
the patch must also apply with zero fuzz, such as with "patch -F 0".

In the case where the context has changed (including changes to an
enclosing struct or function), I gather that a patch exactly modified
for an older kernel is to be sent to sta...@vger.kernel.org after the 
unmodified patch is accepted upstream with a commit ID.



$ git l v3.17.. drivers/platform/x86/ideapad-laptop.c

[...]


If you are going to specify a kernel version, you should also include the
commits above necessary to make the patch apply cleanly. That would be a long
list as you would need many of these for each version.



Thank you for that information. One commit is sufficient to apply the 
patch to all kernel versions without fuzz:


4fa9dab ideapad_laptop: Lenovo G50-30 fix rfkill reports wireless blocked


What I'm going to do is include a single Cc to stable line without a kernel
version. The maintainers will pull that back as far as they can using their own
judgement. If you want this to go back earlier than they do on their own, you
should submit it to linux-stable directly and include the Cc lines for the
dependencies for each kernel you care to see this backported to. See the
stable-kernel-rules for the specific formatting to accomplish this.



I've submitted v5 of the patch with a single Cc line with the prerequisite
kernel(s) and commit ID specified exactly.

Kind regards,

John

Re: [PATCH v3 06/11] KVM: MMU: let page fault handler be aware tracked page

[Xiao Guangrong]

On 02/19/2016 07:45 PM, Paolo Bonzini wrote:



On 14/02/2016 12:31, Xiao Guangrong wrote:

+/*
+ * check if the corresponding access on the specified guest page is tracked.
+ */
+bool kvm_page_track_check_mode(struct kvm_vcpu *vcpu, gfn_t gfn,
+  enum kvm_page_track_mode mode)


Please rename to kvm_page_track_is_active.


Got it! Will do it in the next version.

Re: [PATCH v3 06/11] KVM: MMU: let page fault handler be aware tracked page

[Xiao Guangrong]

On 02/19/2016 07:45 PM, Paolo Bonzini wrote:



On 14/02/2016 12:31, Xiao Guangrong wrote:

+/*
+ * check if the corresponding access on the specified guest page is tracked.
+ */
+bool kvm_page_track_check_mode(struct kvm_vcpu *vcpu, gfn_t gfn,
+  enum kvm_page_track_mode mode)


Please rename to kvm_page_track_is_active.


Got it! Will do it in the next version.

Re: [PATCH v3 05/11] KVM: page track: introduce kvm_page_track_{add,remove}_page

[Xiao Guangrong]

On 02/19/2016 07:37 PM, Paolo Bonzini wrote:



On 14/02/2016 12:31, Xiao Guangrong wrote:

+static bool check_mode(enum kvm_page_track_mode mode)
+{
+   if (mode < 0 || mode >= KVM_PAGE_TRACK_MAX)
+   return false;
+
+   return true;
+}


Oops, forgot about this; please rename to page_track_mode_is_valid and
make it "static inline".


Sure, it looks good to me. :)

Re: [PATCH v3 05/11] KVM: page track: introduce kvm_page_track_{add,remove}_page

[Xiao Guangrong]

On 02/19/2016 07:37 PM, Paolo Bonzini wrote:



On 14/02/2016 12:31, Xiao Guangrong wrote:

+static bool check_mode(enum kvm_page_track_mode mode)
+{
+   if (mode < 0 || mode >= KVM_PAGE_TRACK_MAX)
+   return false;
+
+   return true;
+}


Oops, forgot about this; please rename to page_track_mode_is_valid and
make it "static inline".


Sure, it looks good to me. :)

Re: [PATCH v3 05/11] KVM: page track: introduce kvm_page_track_{add,remove}_page

[Xiao Guangrong]

On 02/19/2016 07:37 PM, Paolo Bonzini wrote:



On 14/02/2016 12:31, Xiao Guangrong wrote:

+   /* does tracking count wrap? */
+   WARN_ON((count > 0) && (val + count < val));


This doesn't work, because "val + count" is an int.


val is 'unsigned short val' and count is 'short', so
'val + count' is not int...




+   /* the last tracker has already gone? */
+   WARN_ON((count < 0) && (val < !count));


Also, here any underflow should warn.

You can actually use the fact that val + count is an int like this:

 WARN_ON(val + count < 0 || val + count > USHRT_MAX)



It looks nice, i will change the type of val to int to simplify the
code.


and also please return if the warning fires.



Okay.


+void kvm_page_track_add_page(struct kvm *kvm, gfn_t gfn,
+enum kvm_page_track_mode mode)
+{
+   struct kvm_memslots *slots;
+   struct kvm_memory_slot *slot;
+   int i;
+
+   for (i = 0; i < KVM_ADDRESS_SPACE_NUM; i++) {
+   slots = __kvm_memslots(kvm, i);
+
+   slot = __gfn_to_memslot(slots, gfn);
+   if (!slot)
+   continue;
+
+   spin_lock(>mmu_lock);
+   kvm_slot_page_track_add_page_nolock(kvm, slot, gfn, mode);
+   spin_unlock(>mmu_lock);
+   }
+}


I don't think it is right to walk all address spaces.  The good news is


Then we can not track the page in SMM mode, but i think it is not a big
problem as SMM is invisible to OS (it is expected to not hurting OS) and
current shadow page in normal spaces can not reflect the changes happend
in SMM either. So it is okay to only take normal space into account.


that you're not using kvm_page_track_{add,remove}_page at all as far as
I can see, so you can just remove them.


kvm_page_track_{add,remove}_page, which hides the mmu specifics (e.g. slot,
mmu-lock, etc.) and are exported as APIs for other users, are just the
small wrappers of kvm_slot_page_track_{add,remove}_page_nolock and the
nolock functions are used in the later patch.

If you think it is not a good time to export these APIs, i am okay to export
_nolock functions only in the next version.



Also, when you will need it, I think it's better to move the
spin_lock/spin_unlock pair outside the for loop.  With this change,
perhaps it's better to leave it to the caller completely---but I cannot
say until I see the caller.


I will remove page tracking in SMM address space, so this is no loop in
the next version. ;)



In the meanwhile, please leave out _nolock from the other functions' name.


I just wanted to warn the user that these functions are not safe as they
are not protected by mmu-lock. I will remove these hints if you dislike them.

Re: [PATCH v3 05/11] KVM: page track: introduce kvm_page_track_{add,remove}_page

[Xiao Guangrong]

On 02/19/2016 07:37 PM, Paolo Bonzini wrote:



On 14/02/2016 12:31, Xiao Guangrong wrote:

+   /* does tracking count wrap? */
+   WARN_ON((count > 0) && (val + count < val));


This doesn't work, because "val + count" is an int.


val is 'unsigned short val' and count is 'short', so
'val + count' is not int...




+   /* the last tracker has already gone? */
+   WARN_ON((count < 0) && (val < !count));


Also, here any underflow should warn.

You can actually use the fact that val + count is an int like this:

 WARN_ON(val + count < 0 || val + count > USHRT_MAX)



It looks nice, i will change the type of val to int to simplify the
code.


and also please return if the warning fires.



Okay.


+void kvm_page_track_add_page(struct kvm *kvm, gfn_t gfn,
+enum kvm_page_track_mode mode)
+{
+   struct kvm_memslots *slots;
+   struct kvm_memory_slot *slot;
+   int i;
+
+   for (i = 0; i < KVM_ADDRESS_SPACE_NUM; i++) {
+   slots = __kvm_memslots(kvm, i);
+
+   slot = __gfn_to_memslot(slots, gfn);
+   if (!slot)
+   continue;
+
+   spin_lock(>mmu_lock);
+   kvm_slot_page_track_add_page_nolock(kvm, slot, gfn, mode);
+   spin_unlock(>mmu_lock);
+   }
+}


I don't think it is right to walk all address spaces.  The good news is


Then we can not track the page in SMM mode, but i think it is not a big
problem as SMM is invisible to OS (it is expected to not hurting OS) and
current shadow page in normal spaces can not reflect the changes happend
in SMM either. So it is okay to only take normal space into account.


that you're not using kvm_page_track_{add,remove}_page at all as far as
I can see, so you can just remove them.


kvm_page_track_{add,remove}_page, which hides the mmu specifics (e.g. slot,
mmu-lock, etc.) and are exported as APIs for other users, are just the
small wrappers of kvm_slot_page_track_{add,remove}_page_nolock and the
nolock functions are used in the later patch.

If you think it is not a good time to export these APIs, i am okay to export
_nolock functions only in the next version.



Also, when you will need it, I think it's better to move the
spin_lock/spin_unlock pair outside the for loop.  With this change,
perhaps it's better to leave it to the caller completely---but I cannot
say until I see the caller.


I will remove page tracking in SMM address space, so this is no loop in
the next version. ;)



In the meanwhile, please leave out _nolock from the other functions' name.


I just wanted to warn the user that these functions are not safe as they
are not protected by mmu-lock. I will remove these hints if you dislike them.

RE: [PATCH v2 4/4] dmaengine: xilinx_vdma: Improve channel idle checking

[Appana Durga Kedareswara Rao]

Hi Vinod,

> -Original Message-
> From: Vinod Koul [mailto:vinod.k...@intel.com]
> Sent: Tuesday, February 23, 2016 8:42 AM
> To: Appana Durga Kedareswara Rao
> Cc: dan.j.willi...@intel.com; Michal Simek; Soren Brinkmann; Appana Durga
> Kedareswara Rao; moritz.fisc...@ettus.com;
> laurent.pinch...@ideasonboard.com; l...@debethencourt.com; Anirudha
> Sarangi; dmaeng...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 4/4] dmaengine: xilinx_vdma: Improve channel idle
> checking
> 
> On Mon, Feb 22, 2016 at 11:24:37AM +0530, Kedareswara rao Appana wrote:
> > This patch improves the channel idle cheking by introduing
> ^
> typo

Ok will fix.

> 
> > a new varibale in chan private structure.
>   ^^^
> here too :(

Ok will fix.

> 
> and there is no description how this improvement is achieved and why

Ok will give detailed explanation in the next version of the patch.

Regards,
Kedar.

> >
> > Signed-off-by: Kedareswara rao Appana 
> > ---
> > Changes for v2:
> > ---> splitted the changes into multiple patches.
> >
> >  drivers/dma/xilinx/xilinx_vdma.c | 41
> > 
> >  1 file changed, 8 insertions(+), 33 deletions(-)
> >
> > diff --git a/drivers/dma/xilinx/xilinx_vdma.c
> > b/drivers/dma/xilinx/xilinx_vdma.c
> > index 8db07f7..51686d1 100644
> > --- a/drivers/dma/xilinx/xilinx_vdma.c
> > +++ b/drivers/dma/xilinx/xilinx_vdma.c
> > @@ -202,6 +202,7 @@ struct xilinx_vdma_tx_descriptor {
> >   * @has_sg: Support scatter transfers
> >   * @genlock: Support genlock mode
> >   * @err: Channel has errors
> > + * @idle: Check for channel idle
> >   * @tasklet: Cleanup work after irq
> >   * @config: Device configuration info
> >   * @flush_on_fsync: Flush on Frame sync @@ -225,6 +226,7 @@ struct
> > xilinx_vdma_chan {
> > bool has_sg;
> > bool genlock;
> > bool err;
> > +   bool idle;
> > struct tasklet_struct tasklet;
> > struct xilinx_vdma_config config;
> > bool flush_on_fsync;
> > @@ -519,32 +521,6 @@ static enum dma_status
> > xilinx_vdma_tx_status(struct dma_chan *dchan,  }
> >
> >  /**
> > - * xilinx_vdma_is_running - Check if VDMA channel is running
> > - * @chan: Driver specific VDMA channel
> > - *
> > - * Return: '1' if running, '0' if not.
> > - */
> > -static bool xilinx_vdma_is_running(struct xilinx_vdma_chan *chan) -{
> > -   return !(vdma_ctrl_read(chan, XILINX_VDMA_REG_DMASR) &
> > -XILINX_VDMA_DMASR_HALTED) &&
> > -   (vdma_ctrl_read(chan, XILINX_VDMA_REG_DMACR) &
> > -XILINX_VDMA_DMACR_RUNSTOP);
> > -}
> > -
> > -/**
> > - * xilinx_vdma_is_idle - Check if VDMA channel is idle
> > - * @chan: Driver specific VDMA channel
> > - *
> > - * Return: '1' if idle, '0' if not.
> > - */
> > -static bool xilinx_vdma_is_idle(struct xilinx_vdma_chan *chan) -{
> > -   return vdma_ctrl_read(chan, XILINX_VDMA_REG_DMASR) &
> > -   XILINX_VDMA_DMASR_IDLE;
> > -}
> > -
> > -/**
> >   * xilinx_vdma_halt - Halt VDMA channel
> >   * @chan: Driver specific VDMA channel
> >   */
> > @@ -614,6 +590,9 @@ static void xilinx_vdma_start_transfer(struct
> xilinx_vdma_chan *chan)
> > if (list_empty(>pending_list))
> > return;
> >
> > +   if (!chan->idle)
> > +   return;
> > +
> > desc = list_first_entry(>pending_list,
> > struct xilinx_vdma_tx_descriptor, node);
> > tail_desc = list_last_entry(>pending_list,
> > @@ -622,13 +601,6 @@ static void xilinx_vdma_start_transfer(struct
> xilinx_vdma_chan *chan)
> > tail_segment = list_last_entry(_desc->segments,
> >struct xilinx_vdma_tx_segment, node);
> >
> > -   /* If it is SG mode and hardware is busy, cannot submit */
> > -   if (chan->has_sg && xilinx_vdma_is_running(chan) &&
> > -   !xilinx_vdma_is_idle(chan)) {
> > -   dev_dbg(chan->dev, "DMA controller still busy\n");
> > -   return;
> > -   }
> > -
> > /*
> >  * If hardware is idle, then all descriptors on the running lists are
> >  * done, start new transfers
> > @@ -708,6 +680,7 @@ static void xilinx_vdma_start_transfer(struct
> > xilinx_vdma_chan *chan)
> >
> > list_splice_tail_init(>pending_list, >active_list);
> > chan->desc_pendingcount = 0;
> > +   chan->idle = false;
> >  }
> >
> >  /**
> > @@ -854,6 +827,7 @@ static irqreturn_t xilinx_vdma_irq_handler(int irq, void
> *data)
> > if (status & XILINX_VDMA_DMASR_FRM_CNT_IRQ) {
> > spin_lock(>lock);
> > xilinx_vdma_complete_descriptor(chan);
> > +   chan->idle = true;
> > xilinx_vdma_start_transfer(chan);
> > spin_unlock(>lock);
> > }
> > @@ -1212,6 +1186,7 @@ static int xilinx_vdma_chan_probe(struct
> > xilinx_vdma_device *xdev,
> >
> > list_add_tail(>common.device_node, 
> >common.channels);
> > xdev->chan[chan->id] = chan;
> > 

RE: [PATCH v2 4/4] dmaengine: xilinx_vdma: Improve channel idle checking

[Appana Durga Kedareswara Rao]

Hi Vinod,

> -Original Message-
> From: Vinod Koul [mailto:vinod.k...@intel.com]
> Sent: Tuesday, February 23, 2016 8:42 AM
> To: Appana Durga Kedareswara Rao
> Cc: dan.j.willi...@intel.com; Michal Simek; Soren Brinkmann; Appana Durga
> Kedareswara Rao; moritz.fisc...@ettus.com;
> laurent.pinch...@ideasonboard.com; l...@debethencourt.com; Anirudha
> Sarangi; dmaeng...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 4/4] dmaengine: xilinx_vdma: Improve channel idle
> checking
> 
> On Mon, Feb 22, 2016 at 11:24:37AM +0530, Kedareswara rao Appana wrote:
> > This patch improves the channel idle cheking by introduing
> ^
> typo

Ok will fix.

> 
> > a new varibale in chan private structure.
>   ^^^
> here too :(

Ok will fix.

> 
> and there is no description how this improvement is achieved and why

Ok will give detailed explanation in the next version of the patch.

Regards,
Kedar.

> >
> > Signed-off-by: Kedareswara rao Appana 
> > ---
> > Changes for v2:
> > ---> splitted the changes into multiple patches.
> >
> >  drivers/dma/xilinx/xilinx_vdma.c | 41
> > 
> >  1 file changed, 8 insertions(+), 33 deletions(-)
> >
> > diff --git a/drivers/dma/xilinx/xilinx_vdma.c
> > b/drivers/dma/xilinx/xilinx_vdma.c
> > index 8db07f7..51686d1 100644
> > --- a/drivers/dma/xilinx/xilinx_vdma.c
> > +++ b/drivers/dma/xilinx/xilinx_vdma.c
> > @@ -202,6 +202,7 @@ struct xilinx_vdma_tx_descriptor {
> >   * @has_sg: Support scatter transfers
> >   * @genlock: Support genlock mode
> >   * @err: Channel has errors
> > + * @idle: Check for channel idle
> >   * @tasklet: Cleanup work after irq
> >   * @config: Device configuration info
> >   * @flush_on_fsync: Flush on Frame sync @@ -225,6 +226,7 @@ struct
> > xilinx_vdma_chan {
> > bool has_sg;
> > bool genlock;
> > bool err;
> > +   bool idle;
> > struct tasklet_struct tasklet;
> > struct xilinx_vdma_config config;
> > bool flush_on_fsync;
> > @@ -519,32 +521,6 @@ static enum dma_status
> > xilinx_vdma_tx_status(struct dma_chan *dchan,  }
> >
> >  /**
> > - * xilinx_vdma_is_running - Check if VDMA channel is running
> > - * @chan: Driver specific VDMA channel
> > - *
> > - * Return: '1' if running, '0' if not.
> > - */
> > -static bool xilinx_vdma_is_running(struct xilinx_vdma_chan *chan) -{
> > -   return !(vdma_ctrl_read(chan, XILINX_VDMA_REG_DMASR) &
> > -XILINX_VDMA_DMASR_HALTED) &&
> > -   (vdma_ctrl_read(chan, XILINX_VDMA_REG_DMACR) &
> > -XILINX_VDMA_DMACR_RUNSTOP);
> > -}
> > -
> > -/**
> > - * xilinx_vdma_is_idle - Check if VDMA channel is idle
> > - * @chan: Driver specific VDMA channel
> > - *
> > - * Return: '1' if idle, '0' if not.
> > - */
> > -static bool xilinx_vdma_is_idle(struct xilinx_vdma_chan *chan) -{
> > -   return vdma_ctrl_read(chan, XILINX_VDMA_REG_DMASR) &
> > -   XILINX_VDMA_DMASR_IDLE;
> > -}
> > -
> > -/**
> >   * xilinx_vdma_halt - Halt VDMA channel
> >   * @chan: Driver specific VDMA channel
> >   */
> > @@ -614,6 +590,9 @@ static void xilinx_vdma_start_transfer(struct
> xilinx_vdma_chan *chan)
> > if (list_empty(>pending_list))
> > return;
> >
> > +   if (!chan->idle)
> > +   return;
> > +
> > desc = list_first_entry(>pending_list,
> > struct xilinx_vdma_tx_descriptor, node);
> > tail_desc = list_last_entry(>pending_list,
> > @@ -622,13 +601,6 @@ static void xilinx_vdma_start_transfer(struct
> xilinx_vdma_chan *chan)
> > tail_segment = list_last_entry(_desc->segments,
> >struct xilinx_vdma_tx_segment, node);
> >
> > -   /* If it is SG mode and hardware is busy, cannot submit */
> > -   if (chan->has_sg && xilinx_vdma_is_running(chan) &&
> > -   !xilinx_vdma_is_idle(chan)) {
> > -   dev_dbg(chan->dev, "DMA controller still busy\n");
> > -   return;
> > -   }
> > -
> > /*
> >  * If hardware is idle, then all descriptors on the running lists are
> >  * done, start new transfers
> > @@ -708,6 +680,7 @@ static void xilinx_vdma_start_transfer(struct
> > xilinx_vdma_chan *chan)
> >
> > list_splice_tail_init(>pending_list, >active_list);
> > chan->desc_pendingcount = 0;
> > +   chan->idle = false;
> >  }
> >
> >  /**
> > @@ -854,6 +827,7 @@ static irqreturn_t xilinx_vdma_irq_handler(int irq, void
> *data)
> > if (status & XILINX_VDMA_DMASR_FRM_CNT_IRQ) {
> > spin_lock(>lock);
> > xilinx_vdma_complete_descriptor(chan);
> > +   chan->idle = true;
> > xilinx_vdma_start_transfer(chan);
> > spin_unlock(>lock);
> > }
> > @@ -1212,6 +1186,7 @@ static int xilinx_vdma_chan_probe(struct
> > xilinx_vdma_device *xdev,
> >
> > list_add_tail(>common.device_node, 
> >common.channels);
> > xdev->chan[chan->id] = chan;
> > +   chan->idle = 

RE: [PATCH v2 2/4] dmaengine: xilinx_vdma: Simplify spin lock handling

[Appana Durga Kedareswara Rao]

Hi Vinod,

> -Original Message-
> From: Vinod Koul [mailto:vinod.k...@intel.com]
> Sent: Tuesday, February 23, 2016 8:40 AM
> To: Appana Durga Kedareswara Rao
> Cc: dan.j.willi...@intel.com; Michal Simek; Soren Brinkmann; Appana Durga
> Kedareswara Rao; moritz.fisc...@ettus.com;
> laurent.pinch...@ideasonboard.com; l...@debethencourt.com; Anirudha
> Sarangi; dmaeng...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 2/4] dmaengine: xilinx_vdma: Simplify spin lock 
> handling
> 
> On Mon, Feb 22, 2016 at 11:24:35AM +0530, Kedareswara rao Appana wrote:
> > This patch simplifies the spin lock handling in the driver.
> 
> But sadly doesn't describe how?

Ok sure will improve commit message in the next version.

> 
> >
> > Signed-off-by: Kedareswara rao Appana 
> > ---
> > Changes for v2:
> > ---> splitted the changes into multiple patches.
> >
> >  drivers/dma/xilinx/xilinx_vdma.c | 27 ++-
> >  1 file changed, 10 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/dma/xilinx/xilinx_vdma.c
> > b/drivers/dma/xilinx/xilinx_vdma.c
> > index 06bffec..d646218 100644
> > --- a/drivers/dma/xilinx/xilinx_vdma.c
> > +++ b/drivers/dma/xilinx/xilinx_vdma.c
> > @@ -605,17 +605,14 @@ static void xilinx_vdma_start_transfer(struct
> > xilinx_vdma_chan *chan)  {
> > struct xilinx_vdma_config *config = >config;
> > struct xilinx_vdma_tx_descriptor *desc, *tail_desc;
> > -   unsigned long flags;
> > u32 reg;
> > struct xilinx_vdma_tx_segment *tail_segment;
> >
> > if (chan->err)
> > return;
> >
> > -   spin_lock_irqsave(>lock, flags);
> > -
> 
> It would help if you add a comment to this function taht we need to invoke 
> this
> with lock held...

Ok sure will add comment..

> 
> > if (list_empty(>pending_list))
> > -   goto out_unlock;
> > +   return;
> >
> > desc = list_first_entry(>pending_list,
> > struct xilinx_vdma_tx_descriptor, node); @@ -
> 629,7 +626,7 @@
> > static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
> > if (chan->has_sg && xilinx_vdma_is_running(chan) &&
> > !xilinx_vdma_is_idle(chan)) {
> > dev_dbg(chan->dev, "DMA controller still busy\n");
> > -   goto out_unlock;
> > +   return;
> > }
> >
> > /*
> > @@ -676,7 +673,7 @@ static void xilinx_vdma_start_transfer(struct
> xilinx_vdma_chan *chan)
> > xilinx_vdma_start(chan);
> >
> > if (chan->err)
> > -   goto out_unlock;
> > +   return;
> >
> > /* Start the transfer */
> > if (chan->has_sg) {
> > @@ -696,7 +693,7 @@ static void xilinx_vdma_start_transfer(struct
> xilinx_vdma_chan *chan)
> > }
> >
> > if (!last)
> > -   goto out_unlock;
> > +   return;
> >
> > /* HW expects these parameters to be same for one
> transaction */
> > vdma_desc_write(chan, XILINX_VDMA_REG_HSIZE, last-
> >hw.hsize); @@
> > -707,9 +704,6 @@ static void xilinx_vdma_start_transfer(struct
> > xilinx_vdma_chan *chan)
> >
> > list_splice_tail_init(>pending_list, >active_list);
> > chan->desc_pendingcount = 0;
> > -
> > -out_unlock:
> > -   spin_unlock_irqrestore(>lock, flags);
> >  }
> >
> >  /**
> > @@ -719,8 +713,11 @@ out_unlock:
> >  static void xilinx_vdma_issue_pending(struct dma_chan *dchan)  {
> > struct xilinx_vdma_chan *chan = to_xilinx_chan(dchan);
> > +   unsigned long flags;
> >
> > +   spin_lock_irqsave(>lock, flags);
> > xilinx_vdma_start_transfer(chan);
> > +   spin_unlock_irqrestore(>lock, flags);
> >  }
> >
> >  /**
> > @@ -732,21 +729,15 @@ static void xilinx_vdma_issue_pending(struct
> > dma_chan *dchan)  static void xilinx_vdma_complete_descriptor(struct
> > xilinx_vdma_chan *chan)  {
> > struct xilinx_vdma_tx_descriptor *desc, *next;
> > -   unsigned long flags;
> > -
> > -   spin_lock_irqsave(>lock, flags);
> 
> this one as well

Ok sure will add comment..

Regards,
Kedar.

> 
> >
> > if (list_empty(>active_list))
> > -   goto out_unlock;
> > +   return;
> >
> > list_for_each_entry_safe(desc, next, >active_list, node) {
> > list_del(>node);
> > dma_cookie_complete(>async_tx);
> > list_add_tail(>node, >done_list);
> > }
> > -
> > -out_unlock:
> > -   spin_unlock_irqrestore(>lock, flags);
> >  }
> >
> >  /**
> > @@ -857,8 +848,10 @@ static irqreturn_t xilinx_vdma_irq_handler(int irq,
> void *data)
> > }
> >
> > if (status & XILINX_VDMA_DMASR_FRM_CNT_IRQ) {
> > +   spin_lock(>lock);
> > xilinx_vdma_complete_descriptor(chan);
> > xilinx_vdma_start_transfer(chan);
> > +   spin_unlock(>lock);
> > }
> >
> > tasklet_schedule(>tasklet);
> > --
> > 2.1.2
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe dmaengine"
> > in the body of a 

RE: [PATCH v2 2/4] dmaengine: xilinx_vdma: Simplify spin lock handling

[Appana Durga Kedareswara Rao]

Hi Vinod,

> -Original Message-
> From: Vinod Koul [mailto:vinod.k...@intel.com]
> Sent: Tuesday, February 23, 2016 8:40 AM
> To: Appana Durga Kedareswara Rao
> Cc: dan.j.willi...@intel.com; Michal Simek; Soren Brinkmann; Appana Durga
> Kedareswara Rao; moritz.fisc...@ettus.com;
> laurent.pinch...@ideasonboard.com; l...@debethencourt.com; Anirudha
> Sarangi; dmaeng...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 2/4] dmaengine: xilinx_vdma: Simplify spin lock 
> handling
> 
> On Mon, Feb 22, 2016 at 11:24:35AM +0530, Kedareswara rao Appana wrote:
> > This patch simplifies the spin lock handling in the driver.
> 
> But sadly doesn't describe how?

Ok sure will improve commit message in the next version.

> 
> >
> > Signed-off-by: Kedareswara rao Appana 
> > ---
> > Changes for v2:
> > ---> splitted the changes into multiple patches.
> >
> >  drivers/dma/xilinx/xilinx_vdma.c | 27 ++-
> >  1 file changed, 10 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/dma/xilinx/xilinx_vdma.c
> > b/drivers/dma/xilinx/xilinx_vdma.c
> > index 06bffec..d646218 100644
> > --- a/drivers/dma/xilinx/xilinx_vdma.c
> > +++ b/drivers/dma/xilinx/xilinx_vdma.c
> > @@ -605,17 +605,14 @@ static void xilinx_vdma_start_transfer(struct
> > xilinx_vdma_chan *chan)  {
> > struct xilinx_vdma_config *config = >config;
> > struct xilinx_vdma_tx_descriptor *desc, *tail_desc;
> > -   unsigned long flags;
> > u32 reg;
> > struct xilinx_vdma_tx_segment *tail_segment;
> >
> > if (chan->err)
> > return;
> >
> > -   spin_lock_irqsave(>lock, flags);
> > -
> 
> It would help if you add a comment to this function taht we need to invoke 
> this
> with lock held...

Ok sure will add comment..

> 
> > if (list_empty(>pending_list))
> > -   goto out_unlock;
> > +   return;
> >
> > desc = list_first_entry(>pending_list,
> > struct xilinx_vdma_tx_descriptor, node); @@ -
> 629,7 +626,7 @@
> > static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
> > if (chan->has_sg && xilinx_vdma_is_running(chan) &&
> > !xilinx_vdma_is_idle(chan)) {
> > dev_dbg(chan->dev, "DMA controller still busy\n");
> > -   goto out_unlock;
> > +   return;
> > }
> >
> > /*
> > @@ -676,7 +673,7 @@ static void xilinx_vdma_start_transfer(struct
> xilinx_vdma_chan *chan)
> > xilinx_vdma_start(chan);
> >
> > if (chan->err)
> > -   goto out_unlock;
> > +   return;
> >
> > /* Start the transfer */
> > if (chan->has_sg) {
> > @@ -696,7 +693,7 @@ static void xilinx_vdma_start_transfer(struct
> xilinx_vdma_chan *chan)
> > }
> >
> > if (!last)
> > -   goto out_unlock;
> > +   return;
> >
> > /* HW expects these parameters to be same for one
> transaction */
> > vdma_desc_write(chan, XILINX_VDMA_REG_HSIZE, last-
> >hw.hsize); @@
> > -707,9 +704,6 @@ static void xilinx_vdma_start_transfer(struct
> > xilinx_vdma_chan *chan)
> >
> > list_splice_tail_init(>pending_list, >active_list);
> > chan->desc_pendingcount = 0;
> > -
> > -out_unlock:
> > -   spin_unlock_irqrestore(>lock, flags);
> >  }
> >
> >  /**
> > @@ -719,8 +713,11 @@ out_unlock:
> >  static void xilinx_vdma_issue_pending(struct dma_chan *dchan)  {
> > struct xilinx_vdma_chan *chan = to_xilinx_chan(dchan);
> > +   unsigned long flags;
> >
> > +   spin_lock_irqsave(>lock, flags);
> > xilinx_vdma_start_transfer(chan);
> > +   spin_unlock_irqrestore(>lock, flags);
> >  }
> >
> >  /**
> > @@ -732,21 +729,15 @@ static void xilinx_vdma_issue_pending(struct
> > dma_chan *dchan)  static void xilinx_vdma_complete_descriptor(struct
> > xilinx_vdma_chan *chan)  {
> > struct xilinx_vdma_tx_descriptor *desc, *next;
> > -   unsigned long flags;
> > -
> > -   spin_lock_irqsave(>lock, flags);
> 
> this one as well

Ok sure will add comment..

Regards,
Kedar.

> 
> >
> > if (list_empty(>active_list))
> > -   goto out_unlock;
> > +   return;
> >
> > list_for_each_entry_safe(desc, next, >active_list, node) {
> > list_del(>node);
> > dma_cookie_complete(>async_tx);
> > list_add_tail(>node, >done_list);
> > }
> > -
> > -out_unlock:
> > -   spin_unlock_irqrestore(>lock, flags);
> >  }
> >
> >  /**
> > @@ -857,8 +848,10 @@ static irqreturn_t xilinx_vdma_irq_handler(int irq,
> void *data)
> > }
> >
> > if (status & XILINX_VDMA_DMASR_FRM_CNT_IRQ) {
> > +   spin_lock(>lock);
> > xilinx_vdma_complete_descriptor(chan);
> > xilinx_vdma_start_transfer(chan);
> > +   spin_unlock(>lock);
> > }
> >
> > tasklet_schedule(>tasklet);
> > --
> > 2.1.2
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe dmaengine"
> > in the body of a message to 

[PATCH 05/56] staging/lustre: Get rid of ost_cmd_t typedef

[green]

From: Oleg Drokin 

Replace it with enum ost_cmd

Signed-off-by: Oleg Drokin 
---
 drivers/staging/lustre/lustre/include/lustre/lustre_idl.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h 
b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
index 0f37b61..50e70fe 100644
--- a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
+++ b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
@@ -1419,7 +1419,7 @@ enum cksum_type {
  */
 
 /* opcodes */
-typedef enum {
+enum ost_cmd {
OST_REPLY  =  0,   /* reply ? */
OST_GETATTR=  1,
OST_SETATTR=  2,
@@ -1440,7 +1440,7 @@ typedef enum {
OST_QUOTACTL   = 19,
OST_QUOTA_ADJUST_QUNIT = 20, /* not used since 2.4 */
OST_LAST_OPC
-} ost_cmd_t;
+};
 #define OST_FIRST_OPC  OST_REPLY
 
 enum obdo_flags {
-- 
2.1.0

[PATCH 05/56] staging/lustre: Get rid of ost_cmd_t typedef

[green]

From: Oleg Drokin 

Replace it with enum ost_cmd

Signed-off-by: Oleg Drokin 
---
 drivers/staging/lustre/lustre/include/lustre/lustre_idl.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h 
b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
index 0f37b61..50e70fe 100644
--- a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
+++ b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
@@ -1419,7 +1419,7 @@ enum cksum_type {
  */
 
 /* opcodes */
-typedef enum {
+enum ost_cmd {
OST_REPLY  =  0,   /* reply ? */
OST_GETATTR=  1,
OST_SETATTR=  2,
@@ -1440,7 +1440,7 @@ typedef enum {
OST_QUOTACTL   = 19,
OST_QUOTA_ADJUST_QUNIT = 20, /* not used since 2.4 */
OST_LAST_OPC
-} ost_cmd_t;
+};
 #define OST_FIRST_OPC  OST_REPLY
 
 enum obdo_flags {
-- 
2.1.0

[PATCH 00/56] More Lustre cleanups.

[green]

From: Oleg Drokin 

This is another round of Lustre cleanups mostly aimed at
fixing checkpatch warnings, but also removing
unneeded code and fixign other things I am noticing along the way.

Oleg Drokin (56):
  staging/lustre/fld: Remove useless typedefs
  staging/lustre: Get rid of client_obd_lock_t typedef
  staging/lustre: Get rid of loc_flags_t typedef
  stagig/lustre: Get rid of cksum_type_t typedef
  staging/lustre: Get rid of ost_cmd_t typedef
  staging/lustre: Get rid of quota_cmd_t typedef
  staging/lustre: Get rid of mds_cmd_t typedef
  staging/lustre: Get rid of mds_reint_t, mdt_reint_t typedefs
  staging/lustre: Get rid of ldlm_cmd_t typedef
  staging/lustre: Remove ldlm typedefs
  staging/lustre: Get rid of mgs_cmd_t typedef
  staging/lustre: Get rid of obd_cmd_t typedef
  staging/lustre: Get rid of llog_op_type typedef
  staging/lustre: Get rid of sec_cmd_t typedef
  staging/lustre/ldlm: Remove unused lr_most_restr from struct
ldlm_resource
  staging/lustre: Get rid of object update code
  staging/lustre: Get rid of lustre_fid typedef
  staging/lustre: Get rid of lustre_quota_version typedef
  staging/lustre: Get rid of ldlm_error_t typedef
  staging/lustre: Remove ldlm_appetite_t typedef
  staging/lustre: Get rid of ldlm_ns_type_t typedef
  staging/lustre: Get rid of ldlm_cancel_flags_t typedef
  staging/lustre/llite: Get rid of se_stat_t typedef
  staging/lustre: Remove lustre_build_version.h
  staging/lustre: Get rid of C99 comments in lustre_idl.h
  staging/lustre: Remove server-side changelog defines
  staging/lustre: Remove FSF mailing address from GPL notices
  staging/lustre: Remove server-only values from enum lu_dirent_attrs
  staging/lustre: Remove *_CONNECT_SUPPORTED defines
  staging/lustre: Remove duplicated quota defines
  staging/lustre: Remove unused struct quota_body
  staging/lustre: Remove lquota_glb_rec, lquota_slv_rec and
lquota_acct_rec
  staging/lustre: S_DIRSYNC is always defined in kernel
  staging/lustre: FMODE_READ and FMODE_WRITE are always defined in the
kernel
  staging/lustre: Remvoe index file transfer structures
  staging/lustre: Remove server data from struct obd_export
  staging/lustre: Remove last_rcvd-file related data
  staging/lustre: Remove dead code in ldlm_lock_destroy_internal
  staging/lustre: MAY_NOT_BLOCK is always defined, don't check for it.
  staging/lustre: Remove unused lli_open_count from struct ll_inode_info
  staging/lustre: Reformat comments and structures in lustre_idl.h
  staging/lustre/include: Adjust comment style
  staging/lustre/fld: Adjust comments to better conform to coding style
  staging/lustre/fid: Adjust comments to better conform to coding style
  staging/lustre/lclient: Adjust comments to better conform to coding
style
  staging/lustre/ldlm: Adjust comments to better conform to coding style
  staging/lustre/llite: Adjust comments to better conform to coding
style
  staging/lustre/lmv: Adjust comments to better conform to coding style
  staging/lustre/lov: Adjust comments to better conform to coding style
  staging/lustre/mdc: Adjust comments to better conform to coding style
  staging/lustre/mgc: Adjust comments to better conform to coding style
  staging/lustre/obdclass: Adjust comments to better conform to coding
style
  staging/lustre/obdecho: Adjust comments to better conform to coding
style
  staging/lustre/osc: Adjust comments to better conform to coding style
  staging/lustre/ptlrpc: Adjust comments to better conform to coding
style
  staging/lustre: Fix indentation mistakes

 .../lustre/include/linux/libcfs/libcfs_cpu.h   |   5 -
 .../lustre/include/linux/libcfs/linux/linux-cpu.h  |   5 -
 drivers/staging/lustre/lnet/lnet/lib-ptl.c |   5 -
 drivers/staging/lustre/lustre/fid/fid_request.c|   6 +-
 drivers/staging/lustre/lustre/fld/fld_cache.c  |   9 +-
 drivers/staging/lustre/lustre/fld/fld_internal.h   |  33 +-
 drivers/staging/lustre/lustre/fld/fld_request.c|   9 +-
 drivers/staging/lustre/lustre/include/cl_object.h  |  69 +-
 drivers/staging/lustre/lustre/include/lclient.h|   3 +-
 drivers/staging/lustre/lustre/include/linux/obd.h  |  12 +-
 .../staging/lustre/lustre/include/lprocfs_status.h |  31 +-
 drivers/staging/lustre/lustre/include/lu_object.h  |  12 +-
 .../lustre/lustre/include/lustre/ll_fiemap.h   |  63 +-
 .../lustre/include/lustre/lustre_build_version.h   |   2 -
 .../lustre/lustre/include/lustre/lustre_idl.h  | 731 ++---
 .../lustre/lustre/include/lustre/lustre_user.h |  82 ++-
 drivers/staging/lustre/lustre/include/lustre_cfg.h |   9 +-
 .../staging/lustre/lustre/include/lustre_disk.h| 252 +--
 drivers/staging/lustre/lustre/include/lustre_dlm.h | 111 ++--
 .../lustre/lustre/include/lustre_dlm_flags.h   |  51 +-
 .../staging/lustre/lustre/include/lustre_export.h  |  73 +-
 drivers/staging/lustre/lustre/include/lustre_fid.h |  18 +-
 

[PATCH 00/56] More Lustre cleanups.

[green]

From: Oleg Drokin 

This is another round of Lustre cleanups mostly aimed at
fixing checkpatch warnings, but also removing
unneeded code and fixign other things I am noticing along the way.

Oleg Drokin (56):
  staging/lustre/fld: Remove useless typedefs
  staging/lustre: Get rid of client_obd_lock_t typedef
  staging/lustre: Get rid of loc_flags_t typedef
  stagig/lustre: Get rid of cksum_type_t typedef
  staging/lustre: Get rid of ost_cmd_t typedef
  staging/lustre: Get rid of quota_cmd_t typedef
  staging/lustre: Get rid of mds_cmd_t typedef
  staging/lustre: Get rid of mds_reint_t, mdt_reint_t typedefs
  staging/lustre: Get rid of ldlm_cmd_t typedef
  staging/lustre: Remove ldlm typedefs
  staging/lustre: Get rid of mgs_cmd_t typedef
  staging/lustre: Get rid of obd_cmd_t typedef
  staging/lustre: Get rid of llog_op_type typedef
  staging/lustre: Get rid of sec_cmd_t typedef
  staging/lustre/ldlm: Remove unused lr_most_restr from struct
ldlm_resource
  staging/lustre: Get rid of object update code
  staging/lustre: Get rid of lustre_fid typedef
  staging/lustre: Get rid of lustre_quota_version typedef
  staging/lustre: Get rid of ldlm_error_t typedef
  staging/lustre: Remove ldlm_appetite_t typedef
  staging/lustre: Get rid of ldlm_ns_type_t typedef
  staging/lustre: Get rid of ldlm_cancel_flags_t typedef
  staging/lustre/llite: Get rid of se_stat_t typedef
  staging/lustre: Remove lustre_build_version.h
  staging/lustre: Get rid of C99 comments in lustre_idl.h
  staging/lustre: Remove server-side changelog defines
  staging/lustre: Remove FSF mailing address from GPL notices
  staging/lustre: Remove server-only values from enum lu_dirent_attrs
  staging/lustre: Remove *_CONNECT_SUPPORTED defines
  staging/lustre: Remove duplicated quota defines
  staging/lustre: Remove unused struct quota_body
  staging/lustre: Remove lquota_glb_rec, lquota_slv_rec and
lquota_acct_rec
  staging/lustre: S_DIRSYNC is always defined in kernel
  staging/lustre: FMODE_READ and FMODE_WRITE are always defined in the
kernel
  staging/lustre: Remvoe index file transfer structures
  staging/lustre: Remove server data from struct obd_export
  staging/lustre: Remove last_rcvd-file related data
  staging/lustre: Remove dead code in ldlm_lock_destroy_internal
  staging/lustre: MAY_NOT_BLOCK is always defined, don't check for it.
  staging/lustre: Remove unused lli_open_count from struct ll_inode_info
  staging/lustre: Reformat comments and structures in lustre_idl.h
  staging/lustre/include: Adjust comment style
  staging/lustre/fld: Adjust comments to better conform to coding style
  staging/lustre/fid: Adjust comments to better conform to coding style
  staging/lustre/lclient: Adjust comments to better conform to coding
style
  staging/lustre/ldlm: Adjust comments to better conform to coding style
  staging/lustre/llite: Adjust comments to better conform to coding
style
  staging/lustre/lmv: Adjust comments to better conform to coding style
  staging/lustre/lov: Adjust comments to better conform to coding style
  staging/lustre/mdc: Adjust comments to better conform to coding style
  staging/lustre/mgc: Adjust comments to better conform to coding style
  staging/lustre/obdclass: Adjust comments to better conform to coding
style
  staging/lustre/obdecho: Adjust comments to better conform to coding
style
  staging/lustre/osc: Adjust comments to better conform to coding style
  staging/lustre/ptlrpc: Adjust comments to better conform to coding
style
  staging/lustre: Fix indentation mistakes

 .../lustre/include/linux/libcfs/libcfs_cpu.h   |   5 -
 .../lustre/include/linux/libcfs/linux/linux-cpu.h  |   5 -
 drivers/staging/lustre/lnet/lnet/lib-ptl.c |   5 -
 drivers/staging/lustre/lustre/fid/fid_request.c|   6 +-
 drivers/staging/lustre/lustre/fld/fld_cache.c  |   9 +-
 drivers/staging/lustre/lustre/fld/fld_internal.h   |  33 +-
 drivers/staging/lustre/lustre/fld/fld_request.c|   9 +-
 drivers/staging/lustre/lustre/include/cl_object.h  |  69 +-
 drivers/staging/lustre/lustre/include/lclient.h|   3 +-
 drivers/staging/lustre/lustre/include/linux/obd.h  |  12 +-
 .../staging/lustre/lustre/include/lprocfs_status.h |  31 +-
 drivers/staging/lustre/lustre/include/lu_object.h  |  12 +-
 .../lustre/lustre/include/lustre/ll_fiemap.h   |  63 +-
 .../lustre/include/lustre/lustre_build_version.h   |   2 -
 .../lustre/lustre/include/lustre/lustre_idl.h  | 731 ++---
 .../lustre/lustre/include/lustre/lustre_user.h |  82 ++-
 drivers/staging/lustre/lustre/include/lustre_cfg.h |   9 +-
 .../staging/lustre/lustre/include/lustre_disk.h| 252 +--
 drivers/staging/lustre/lustre/include/lustre_dlm.h | 111 ++--
 .../lustre/lustre/include/lustre_dlm_flags.h   |  51 +-
 .../staging/lustre/lustre/include/lustre_export.h  |  73 +-
 drivers/staging/lustre/lustre/include/lustre_fid.h |  18 +-
 drivers/staging/lustre/lustre/include/lustre_fld.h |  33 +-
 

[PATCH 04/56] stagig/lustre: Get rid of cksum_type_t typedef

[green]

From: Oleg Drokin 

Replace it with enum cksum_type

Signed-off-by: Oleg Drokin 
---
 drivers/staging/lustre/lustre/include/lustre/lustre_idl.h |  4 ++--
 drivers/staging/lustre/lustre/include/obd.h   |  2 +-
 drivers/staging/lustre/lustre/include/obd_cksum.h | 12 ++--
 drivers/staging/lustre/lustre/osc/osc_request.c   | 10 +-
 4 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h 
b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
index 0e3bac6..0f37b61 100644
--- a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
+++ b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
@@ -1408,11 +1408,11 @@ void lustre_swab_connect(struct obd_connect_data *ocd);
  * Please update DECLARE_CKSUM_NAME/OBD_CKSUM_ALL in obd.h when adding a new
  * algorithm and also the OBD_FL_CKSUM* flags.
  */
-typedef enum {
+enum cksum_type {
OBD_CKSUM_CRC32  = 0x0001,
OBD_CKSUM_ADLER  = 0x0002,
OBD_CKSUM_CRC32C = 0x0004,
-} cksum_type_t;
+};
 
 /*
  *   OST requests: OBDO & OBD request records
diff --git a/drivers/staging/lustre/lustre/include/obd.h 
b/drivers/staging/lustre/lustre/include/obd.h
index d6e5a17..09f1a5b 100644
--- a/drivers/staging/lustre/lustre/include/obd.h
+++ b/drivers/staging/lustre/lustre/include/obd.h
@@ -339,7 +339,7 @@ struct client_obd {
/* supported checksum types that are worked out at connect time */
__u32   cl_supp_cksum_types;
/* checksum algorithm to be used */
-   cksum_type_t cl_cksum_type;
+   enum cksum_type  cl_cksum_type;
 
/* also protected by the poorly named _loi_list_lock lock above */
struct osc_async_rc  cl_ar;
diff --git a/drivers/staging/lustre/lustre/include/obd_cksum.h 
b/drivers/staging/lustre/lustre/include/obd_cksum.h
index 01db604..d61b4db 100644
--- a/drivers/staging/lustre/lustre/include/obd_cksum.h
+++ b/drivers/staging/lustre/lustre/include/obd_cksum.h
@@ -37,7 +37,7 @@
 #include "../../include/linux/libcfs/libcfs.h"
 #include "lustre/lustre_idl.h"
 
-static inline unsigned char cksum_obd2cfs(cksum_type_t cksum_type)
+static inline unsigned char cksum_obd2cfs(enum cksum_type cksum_type)
 {
switch (cksum_type) {
case OBD_CKSUM_CRC32:
@@ -64,7 +64,7 @@ static inline unsigned char cksum_obd2cfs(cksum_type_t 
cksum_type)
  * because that is supported by all clients since 1.8
  *
  * In case multiple algorithms are supported the best one is used. */
-static inline u32 cksum_type_pack(cksum_type_t cksum_type)
+static inline u32 cksum_type_pack(enum cksum_type cksum_type)
 {
unsigned intperformance = 0, tmp;
u32 flag = OBD_FL_CKSUM_ADLER;
@@ -98,7 +98,7 @@ static inline u32 cksum_type_pack(cksum_type_t cksum_type)
return flag;
 }
 
-static inline cksum_type_t cksum_type_unpack(u32 o_flags)
+static inline enum cksum_type cksum_type_unpack(u32 o_flags)
 {
switch (o_flags & OBD_FL_CKSUM_ALL) {
case OBD_FL_CKSUM_CRC32C:
@@ -116,9 +116,9 @@ static inline cksum_type_t cksum_type_unpack(u32 o_flags)
  * 1.8 supported ADLER it is base and not depend on hw
  * Client uses all available local algos
  */
-static inline cksum_type_t cksum_types_supported_client(void)
+static inline enum cksum_type cksum_types_supported_client(void)
 {
-   cksum_type_t ret = OBD_CKSUM_ADLER;
+   enum cksum_type ret = OBD_CKSUM_ADLER;
 
CDEBUG(D_INFO, "Crypto hash speed: crc %d, crc32c %d, adler %d\n",
   cfs_crypto_hash_speed(cksum_obd2cfs(OBD_CKSUM_CRC32)),
@@ -140,7 +140,7 @@ static inline cksum_type_t 
cksum_types_supported_client(void)
  * checksum type due to its benchmarking at libcfs module load.
  * Caution is advised, however, since what is fastest on a single client may
  * not be the fastest or most efficient algorithm on the server.  */
-static inline cksum_type_t cksum_type_select(cksum_type_t cksum_types)
+static inline enum cksum_type cksum_type_select(enum cksum_type cksum_types)
 {
return cksum_type_unpack(cksum_type_pack(cksum_types));
 }
diff --git a/drivers/staging/lustre/lustre/osc/osc_request.c 
b/drivers/staging/lustre/lustre/osc/osc_request.c
index 43b11c6..cb9587f 100644
--- a/drivers/staging/lustre/lustre/osc/osc_request.c
+++ b/drivers/staging/lustre/lustre/osc/osc_request.c
@@ -1151,7 +1151,7 @@ static inline int can_merge_pages(struct brw_page *p1, 
struct brw_page *p2)
 
 static u32 osc_checksum_bulk(int nob, u32 pg_count,
 struct brw_page **pga, int opc,
-cksum_type_t cksum_type)
+enum cksum_type cksum_type)
 {
__u32 cksum;
int i = 0;
@@ -1355,7 +1355,7 @@ static int osc_brw_prep_request(int cmd, struct 
client_obd *cli,
!sptlrpc_flavor_has_bulk(>rq_flvr)) {
 

[PATCH 04/56] stagig/lustre: Get rid of cksum_type_t typedef

[green]

From: Oleg Drokin 

Replace it with enum cksum_type

Signed-off-by: Oleg Drokin 
---
 drivers/staging/lustre/lustre/include/lustre/lustre_idl.h |  4 ++--
 drivers/staging/lustre/lustre/include/obd.h   |  2 +-
 drivers/staging/lustre/lustre/include/obd_cksum.h | 12 ++--
 drivers/staging/lustre/lustre/osc/osc_request.c   | 10 +-
 4 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h 
b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
index 0e3bac6..0f37b61 100644
--- a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
+++ b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
@@ -1408,11 +1408,11 @@ void lustre_swab_connect(struct obd_connect_data *ocd);
  * Please update DECLARE_CKSUM_NAME/OBD_CKSUM_ALL in obd.h when adding a new
  * algorithm and also the OBD_FL_CKSUM* flags.
  */
-typedef enum {
+enum cksum_type {
OBD_CKSUM_CRC32  = 0x0001,
OBD_CKSUM_ADLER  = 0x0002,
OBD_CKSUM_CRC32C = 0x0004,
-} cksum_type_t;
+};
 
 /*
  *   OST requests: OBDO & OBD request records
diff --git a/drivers/staging/lustre/lustre/include/obd.h 
b/drivers/staging/lustre/lustre/include/obd.h
index d6e5a17..09f1a5b 100644
--- a/drivers/staging/lustre/lustre/include/obd.h
+++ b/drivers/staging/lustre/lustre/include/obd.h
@@ -339,7 +339,7 @@ struct client_obd {
/* supported checksum types that are worked out at connect time */
__u32   cl_supp_cksum_types;
/* checksum algorithm to be used */
-   cksum_type_t cl_cksum_type;
+   enum cksum_type  cl_cksum_type;
 
/* also protected by the poorly named _loi_list_lock lock above */
struct osc_async_rc  cl_ar;
diff --git a/drivers/staging/lustre/lustre/include/obd_cksum.h 
b/drivers/staging/lustre/lustre/include/obd_cksum.h
index 01db604..d61b4db 100644
--- a/drivers/staging/lustre/lustre/include/obd_cksum.h
+++ b/drivers/staging/lustre/lustre/include/obd_cksum.h
@@ -37,7 +37,7 @@
 #include "../../include/linux/libcfs/libcfs.h"
 #include "lustre/lustre_idl.h"
 
-static inline unsigned char cksum_obd2cfs(cksum_type_t cksum_type)
+static inline unsigned char cksum_obd2cfs(enum cksum_type cksum_type)
 {
switch (cksum_type) {
case OBD_CKSUM_CRC32:
@@ -64,7 +64,7 @@ static inline unsigned char cksum_obd2cfs(cksum_type_t 
cksum_type)
  * because that is supported by all clients since 1.8
  *
  * In case multiple algorithms are supported the best one is used. */
-static inline u32 cksum_type_pack(cksum_type_t cksum_type)
+static inline u32 cksum_type_pack(enum cksum_type cksum_type)
 {
unsigned intperformance = 0, tmp;
u32 flag = OBD_FL_CKSUM_ADLER;
@@ -98,7 +98,7 @@ static inline u32 cksum_type_pack(cksum_type_t cksum_type)
return flag;
 }
 
-static inline cksum_type_t cksum_type_unpack(u32 o_flags)
+static inline enum cksum_type cksum_type_unpack(u32 o_flags)
 {
switch (o_flags & OBD_FL_CKSUM_ALL) {
case OBD_FL_CKSUM_CRC32C:
@@ -116,9 +116,9 @@ static inline cksum_type_t cksum_type_unpack(u32 o_flags)
  * 1.8 supported ADLER it is base and not depend on hw
  * Client uses all available local algos
  */
-static inline cksum_type_t cksum_types_supported_client(void)
+static inline enum cksum_type cksum_types_supported_client(void)
 {
-   cksum_type_t ret = OBD_CKSUM_ADLER;
+   enum cksum_type ret = OBD_CKSUM_ADLER;
 
CDEBUG(D_INFO, "Crypto hash speed: crc %d, crc32c %d, adler %d\n",
   cfs_crypto_hash_speed(cksum_obd2cfs(OBD_CKSUM_CRC32)),
@@ -140,7 +140,7 @@ static inline cksum_type_t 
cksum_types_supported_client(void)
  * checksum type due to its benchmarking at libcfs module load.
  * Caution is advised, however, since what is fastest on a single client may
  * not be the fastest or most efficient algorithm on the server.  */
-static inline cksum_type_t cksum_type_select(cksum_type_t cksum_types)
+static inline enum cksum_type cksum_type_select(enum cksum_type cksum_types)
 {
return cksum_type_unpack(cksum_type_pack(cksum_types));
 }
diff --git a/drivers/staging/lustre/lustre/osc/osc_request.c 
b/drivers/staging/lustre/lustre/osc/osc_request.c
index 43b11c6..cb9587f 100644
--- a/drivers/staging/lustre/lustre/osc/osc_request.c
+++ b/drivers/staging/lustre/lustre/osc/osc_request.c
@@ -1151,7 +1151,7 @@ static inline int can_merge_pages(struct brw_page *p1, 
struct brw_page *p2)
 
 static u32 osc_checksum_bulk(int nob, u32 pg_count,
 struct brw_page **pga, int opc,
-cksum_type_t cksum_type)
+enum cksum_type cksum_type)
 {
__u32 cksum;
int i = 0;
@@ -1355,7 +1355,7 @@ static int osc_brw_prep_request(int cmd, struct 
client_obd *cli,
!sptlrpc_flavor_has_bulk(>rq_flvr)) {
/* store cl_cksum_type in a local