[PATCH v3 0/2] XRA1403,gpio - add XRA1403 gpio expander driver

[Nandor Han]

The patchset will add a driver to support basic functionality for
XRA1403 device. Features supported:
- get/set GPIO direction (input, output)
- get/set GPIO level (low, high)

Documentation: A gpio-xra1403.txt file was added to document the DTS
bindings related to driver.

Testing:

1.1 XRA1403 connected to iMX53 MCU
1.2 Use the GPIO tools provided by kernel from tools/gpio dir

2.1 `lsgpio`

root@csmon ppd:~# lsgpio
GPIO chip: gpiochip8, "xra1403", 16 GPIO lines
line  0: unnamed unused [output]
line  1: unnamed unused [output]
line  2: unnamed unused [output]
line  3: unnamed unused [output]
line  4: unnamed unused [output]
line  5: unnamed unused
line  6: unnamed unused
line  7: unnamed unused [output]
line  8: unnamed unused [output]
line  9: unnamed unused
line 10: unnamed unused [output]
line 11: unnamed unused
line 12: unnamed unused
line 13: unnamed unused
line 14: unnamed unused
line 15: unnamed unused [output]
GPIO chip: gpiochip7, "xra1403", 16 GPIO lines
line  0: unnamed unused
line  1: unnamed unused
line  2: unnamed unused
line  3: unnamed unused
line  4: unnamed unused
line  5: unnamed unused
line  6: unnamed unused
line  7: unnamed unused
line  8: unnamed unused
line  9: unnamed unused
line 10: unnamed unused
line 11: unnamed unused
line 12: unnamed unused
line 13: unnamed unused
line 14: unnamed unused
line 15: unnamed unused

3.1 `gpio-hammer`

root@csmon ppd:~# gpio-hammer -n gpiochip8 -o0 -o1 -o2 -o3
Hammer lines [0, 1, 2, 3] on gpiochip8, initial states: [0, 0, 0, 0]
[\] [0: 0, 1: 0, 2: 0, 3: 0]
...
[\] [0: 1, 1: 1, 2: 1, 3: 1]

When using `gpio-hammer` I also attached an oscilloscope to one of the pins and 
I was
able to monitor and validate the GPIO status.


Changes since v2: - improve the commit message by removing the "sysfs"
dependency and be more clear.
  - include "seq_file.h" header.
Note: documentation patches were accepted already.

Changes since v1: - use regmap for driver
  - small changes to documentation


Nandor Han (2):
  gpio - Add EXAR XRA1403 SPI GPIO expander driver
  Add XRA1403 support to MAINTAINERS file

 MAINTAINERS |   8 ++
 drivers/gpio/Kconfig|   5 +
 drivers/gpio/Makefile   |   1 +
 drivers/gpio/gpio-xra1403.c | 237 
 4 files changed, 251 insertions(+)
 create mode 100644 drivers/gpio/gpio-xra1403.c

-- 
2.10.1

[PATCH v3 2/2] Add XRA1403 support to MAINTAINERS file

[Nandor Han]

Add XRA1403 support to MAINTAINERS list.

Signed-off-by: Nandor Han 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f9deb67..db86335 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14078,6 +14078,14 @@ L: linux-kernel@vger.kernel.org
 S: Supported
 F: drivers/char/xillybus/
 
+XRA1403 GPIO EXPANDER
+M: Nandor Han 
+M: Semi Malinen 
+L: linux-g...@vger.kernel.org
+S: Maintained
+F: drivers/gpio/gpio-xra1403.c
+F: Documentation/devicetree/bindings/gpio/gpio-xra1403.txt
+
 XTENSA XTFPGA PLATFORM SUPPORT
 M: Max Filippov 
 L: linux-xte...@linux-xtensa.org
-- 
2.10.1

[PATCH v3 0/2] XRA1403,gpio - add XRA1403 gpio expander driver

[Nandor Han]

The patchset will add a driver to support basic functionality for
XRA1403 device. Features supported:
- get/set GPIO direction (input, output)
- get/set GPIO level (low, high)

Documentation: A gpio-xra1403.txt file was added to document the DTS
bindings related to driver.

Testing:

1.1 XRA1403 connected to iMX53 MCU
1.2 Use the GPIO tools provided by kernel from tools/gpio dir

2.1 `lsgpio`

root@csmon ppd:~# lsgpio
GPIO chip: gpiochip8, "xra1403", 16 GPIO lines
line  0: unnamed unused [output]
line  1: unnamed unused [output]
line  2: unnamed unused [output]
line  3: unnamed unused [output]
line  4: unnamed unused [output]
line  5: unnamed unused
line  6: unnamed unused
line  7: unnamed unused [output]
line  8: unnamed unused [output]
line  9: unnamed unused
line 10: unnamed unused [output]
line 11: unnamed unused
line 12: unnamed unused
line 13: unnamed unused
line 14: unnamed unused
line 15: unnamed unused [output]
GPIO chip: gpiochip7, "xra1403", 16 GPIO lines
line  0: unnamed unused
line  1: unnamed unused
line  2: unnamed unused
line  3: unnamed unused
line  4: unnamed unused
line  5: unnamed unused
line  6: unnamed unused
line  7: unnamed unused
line  8: unnamed unused
line  9: unnamed unused
line 10: unnamed unused
line 11: unnamed unused
line 12: unnamed unused
line 13: unnamed unused
line 14: unnamed unused
line 15: unnamed unused

3.1 `gpio-hammer`

root@csmon ppd:~# gpio-hammer -n gpiochip8 -o0 -o1 -o2 -o3
Hammer lines [0, 1, 2, 3] on gpiochip8, initial states: [0, 0, 0, 0]
[\] [0: 0, 1: 0, 2: 0, 3: 0]
...
[\] [0: 1, 1: 1, 2: 1, 3: 1]

When using `gpio-hammer` I also attached an oscilloscope to one of the pins and 
I was
able to monitor and validate the GPIO status.


Changes since v2: - improve the commit message by removing the "sysfs"
dependency and be more clear.
  - include "seq_file.h" header.
Note: documentation patches were accepted already.

Changes since v1: - use regmap for driver
  - small changes to documentation


Nandor Han (2):
  gpio - Add EXAR XRA1403 SPI GPIO expander driver
  Add XRA1403 support to MAINTAINERS file

 MAINTAINERS |   8 ++
 drivers/gpio/Kconfig|   5 +
 drivers/gpio/Makefile   |   1 +
 drivers/gpio/gpio-xra1403.c | 237 
 4 files changed, 251 insertions(+)
 create mode 100644 drivers/gpio/gpio-xra1403.c

-- 
2.10.1

[PATCH v3 2/2] Add XRA1403 support to MAINTAINERS file

[Nandor Han]

Add XRA1403 support to MAINTAINERS list.

Signed-off-by: Nandor Han 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f9deb67..db86335 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14078,6 +14078,14 @@ L: linux-kernel@vger.kernel.org
 S: Supported
 F: drivers/char/xillybus/
 
+XRA1403 GPIO EXPANDER
+M: Nandor Han 
+M: Semi Malinen 
+L: linux-g...@vger.kernel.org
+S: Maintained
+F: drivers/gpio/gpio-xra1403.c
+F: Documentation/devicetree/bindings/gpio/gpio-xra1403.txt
+
 XTENSA XTFPGA PLATFORM SUPPORT
 M: Max Filippov 
 L: linux-xte...@linux-xtensa.org
-- 
2.10.1

[PATCH v3 1/2] gpio - Add EXAR XRA1403 SPI GPIO expander driver

[Nandor Han]

This driver support basic XRA1403 functionalities:
- set gpio direction
- get gpio direction
- set gpio high/low
- get gpio status

Signed-off-by: Nandor Han 
Signed-off-by: Semi Malinen 
---
 drivers/gpio/Kconfig|   5 +
 drivers/gpio/Makefile   |   1 +
 drivers/gpio/gpio-xra1403.c | 237 
 3 files changed, 243 insertions(+)
 create mode 100644 drivers/gpio/gpio-xra1403.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 23ca51e..dbde3ae 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -1225,6 +1225,11 @@ config GPIO_PISOSR
  GPIO driver for SPI compatible parallel-in/serial-out shift
  registers. These are input only devices.
 
+config GPIO_XRA1403
+   tristate "EXAR XRA1403 16-bit GPIO expander"
+   help
+ GPIO driver for EXAR XRA1403 16-bit SPI-based GPIO expander.
+
 endmenu
 
 menu "SPI or I2C GPIO expanders"
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 68b9627..4d9adc6 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -141,6 +141,7 @@ obj-$(CONFIG_GPIO_XGENE)+= gpio-xgene.o
 obj-$(CONFIG_GPIO_XGENE_SB)+= gpio-xgene-sb.o
 obj-$(CONFIG_GPIO_XILINX)  += gpio-xilinx.o
 obj-$(CONFIG_GPIO_XLP) += gpio-xlp.o
+obj-$(CONFIG_GPIO_XRA1403) += gpio-xra1403.o
 obj-$(CONFIG_GPIO_XTENSA)  += gpio-xtensa.o
 obj-$(CONFIG_GPIO_ZEVIO)   += gpio-zevio.o
 obj-$(CONFIG_GPIO_ZYNQ)+= gpio-zynq.o
diff --git a/drivers/gpio/gpio-xra1403.c b/drivers/gpio/gpio-xra1403.c
new file mode 100644
index 000..0230e4b
--- /dev/null
+++ b/drivers/gpio/gpio-xra1403.c
@@ -0,0 +1,237 @@
+/*
+ * GPIO driver for EXAR XRA1403 16-bit GPIO expander
+ *
+ * Copyright (c) 2017, General Electric Company
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* XRA1403 registers */
+#define XRA_GSR   0x00 /* GPIO State */
+#define XRA_OCR   0x02 /* Output Control */
+#define XRA_PIR   0x04 /* Input Polarity Inversion */
+#define XRA_GCR   0x06 /* GPIO Configuration */
+#define XRA_PUR   0x08 /* Input Internal Pull-up Resistor Enable/Disable */
+#define XRA_IER   0x0A /* Input Interrupt Enable */
+#define XRA_TSCR  0x0C /* Output Three-State Control */
+#define XRA_ISR   0x0E /* Input Interrupt Status */
+#define XRA_REIR  0x10 /* Input Rising Edge Interrupt Enable */
+#define XRA_FEIR  0x12 /* Input Falling Edge Interrupt Enable */
+#define XRA_IFR   0x14 /* Input Filter Enable/Disable */
+
+struct xra1403 {
+   struct gpio_chip  chip;
+   struct regmap *regmap;
+};
+
+static const struct regmap_config xra1403_regmap_cfg = {
+   .reg_bits = 7,
+   .pad_bits = 1,
+   .val_bits = 8,
+
+   .max_register = XRA_IFR | 0x01,
+};
+
+static unsigned int to_reg(unsigned int reg, unsigned int offset)
+{
+   return reg + (offset > 7);
+}
+
+static int xra1403_direction_input(struct gpio_chip *chip, unsigned int offset)
+{
+   struct xra1403 *xra = gpiochip_get_data(chip);
+
+   return regmap_update_bits(xra->regmap, to_reg(XRA_GCR, offset),
+   BIT(offset % 8), BIT(offset % 8));
+}
+
+static int xra1403_direction_output(struct gpio_chip *chip, unsigned int 
offset,
+   int value)
+{
+   int ret;
+   struct xra1403 *xra = gpiochip_get_data(chip);
+
+   ret = regmap_update_bits(xra->regmap, to_reg(XRA_GCR, offset),
+   BIT(offset % 8), 0);
+   if (ret)
+   return ret;
+
+   ret = regmap_update_bits(xra->regmap, to_reg(XRA_OCR, offset),
+   BIT(offset % 8), value ? BIT(offset % 8) : 0);
+
+   return ret;
+}
+
+static int xra1403_get_direction(struct gpio_chip *chip, unsigned int offset)
+{
+   int ret;
+   unsigned int val;
+   struct xra1403 *xra = gpiochip_get_data(chip);
+
+   ret = regmap_read(xra->regmap, to_reg(XRA_GCR, offset), );
+   if (ret)
+   return ret;
+
+   return !!(val & BIT(offset % 8));
+}
+
+static int xra1403_get(struct gpio_chip *chip, unsigned int offset)
+{
+   int ret;
+   unsigned int val;
+   struct xra1403 *xra = gpiochip_get_data(chip);
+
+   ret = regmap_read(xra->regmap, 

[PATCH v3 1/2] gpio - Add EXAR XRA1403 SPI GPIO expander driver

[Nandor Han]

This driver support basic XRA1403 functionalities:
- set gpio direction
- get gpio direction
- set gpio high/low
- get gpio status

Signed-off-by: Nandor Han 
Signed-off-by: Semi Malinen 
---
 drivers/gpio/Kconfig|   5 +
 drivers/gpio/Makefile   |   1 +
 drivers/gpio/gpio-xra1403.c | 237 
 3 files changed, 243 insertions(+)
 create mode 100644 drivers/gpio/gpio-xra1403.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 23ca51e..dbde3ae 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -1225,6 +1225,11 @@ config GPIO_PISOSR
  GPIO driver for SPI compatible parallel-in/serial-out shift
  registers. These are input only devices.
 
+config GPIO_XRA1403
+   tristate "EXAR XRA1403 16-bit GPIO expander"
+   help
+ GPIO driver for EXAR XRA1403 16-bit SPI-based GPIO expander.
+
 endmenu
 
 menu "SPI or I2C GPIO expanders"
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 68b9627..4d9adc6 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -141,6 +141,7 @@ obj-$(CONFIG_GPIO_XGENE)+= gpio-xgene.o
 obj-$(CONFIG_GPIO_XGENE_SB)+= gpio-xgene-sb.o
 obj-$(CONFIG_GPIO_XILINX)  += gpio-xilinx.o
 obj-$(CONFIG_GPIO_XLP) += gpio-xlp.o
+obj-$(CONFIG_GPIO_XRA1403) += gpio-xra1403.o
 obj-$(CONFIG_GPIO_XTENSA)  += gpio-xtensa.o
 obj-$(CONFIG_GPIO_ZEVIO)   += gpio-zevio.o
 obj-$(CONFIG_GPIO_ZYNQ)+= gpio-zynq.o
diff --git a/drivers/gpio/gpio-xra1403.c b/drivers/gpio/gpio-xra1403.c
new file mode 100644
index 000..0230e4b
--- /dev/null
+++ b/drivers/gpio/gpio-xra1403.c
@@ -0,0 +1,237 @@
+/*
+ * GPIO driver for EXAR XRA1403 16-bit GPIO expander
+ *
+ * Copyright (c) 2017, General Electric Company
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* XRA1403 registers */
+#define XRA_GSR   0x00 /* GPIO State */
+#define XRA_OCR   0x02 /* Output Control */
+#define XRA_PIR   0x04 /* Input Polarity Inversion */
+#define XRA_GCR   0x06 /* GPIO Configuration */
+#define XRA_PUR   0x08 /* Input Internal Pull-up Resistor Enable/Disable */
+#define XRA_IER   0x0A /* Input Interrupt Enable */
+#define XRA_TSCR  0x0C /* Output Three-State Control */
+#define XRA_ISR   0x0E /* Input Interrupt Status */
+#define XRA_REIR  0x10 /* Input Rising Edge Interrupt Enable */
+#define XRA_FEIR  0x12 /* Input Falling Edge Interrupt Enable */
+#define XRA_IFR   0x14 /* Input Filter Enable/Disable */
+
+struct xra1403 {
+   struct gpio_chip  chip;
+   struct regmap *regmap;
+};
+
+static const struct regmap_config xra1403_regmap_cfg = {
+   .reg_bits = 7,
+   .pad_bits = 1,
+   .val_bits = 8,
+
+   .max_register = XRA_IFR | 0x01,
+};
+
+static unsigned int to_reg(unsigned int reg, unsigned int offset)
+{
+   return reg + (offset > 7);
+}
+
+static int xra1403_direction_input(struct gpio_chip *chip, unsigned int offset)
+{
+   struct xra1403 *xra = gpiochip_get_data(chip);
+
+   return regmap_update_bits(xra->regmap, to_reg(XRA_GCR, offset),
+   BIT(offset % 8), BIT(offset % 8));
+}
+
+static int xra1403_direction_output(struct gpio_chip *chip, unsigned int 
offset,
+   int value)
+{
+   int ret;
+   struct xra1403 *xra = gpiochip_get_data(chip);
+
+   ret = regmap_update_bits(xra->regmap, to_reg(XRA_GCR, offset),
+   BIT(offset % 8), 0);
+   if (ret)
+   return ret;
+
+   ret = regmap_update_bits(xra->regmap, to_reg(XRA_OCR, offset),
+   BIT(offset % 8), value ? BIT(offset % 8) : 0);
+
+   return ret;
+}
+
+static int xra1403_get_direction(struct gpio_chip *chip, unsigned int offset)
+{
+   int ret;
+   unsigned int val;
+   struct xra1403 *xra = gpiochip_get_data(chip);
+
+   ret = regmap_read(xra->regmap, to_reg(XRA_GCR, offset), );
+   if (ret)
+   return ret;
+
+   return !!(val & BIT(offset % 8));
+}
+
+static int xra1403_get(struct gpio_chip *chip, unsigned int offset)
+{
+   int ret;
+   unsigned int val;
+   struct xra1403 *xra = gpiochip_get_data(chip);
+
+   ret = regmap_read(xra->regmap, to_reg(XRA_GSR, offset), );
+   if 

Re: [PATCH 2/2] ipack: Improve a size determination in ipack_bus_register()

[Greg Kroah-Hartman]

On Mon, May 15, 2017 at 06:52:47AM +0200, Samuel Iglesias Gonsálvez wrote:
> Hello Markus,
> 
> Thanks for the patches!
> 
> Series is,
> 
> Acked-by: Samuel Iglesias Gonsalvez 
> 
> Greg, Would you mind picking this patch series through your char-misc
> tree?

I'm sorry, but this person is in my blacklist and I don't have any of
their emails, so I don't have these patches anywhere.  If you wish to
have them applied, please resend them with your acked-by, or just ignore
them, it's up to you.

good luck!

greg k-h

Re: [PATCH 2/2] ipack: Improve a size determination in ipack_bus_register()

[Greg Kroah-Hartman]

On Mon, May 15, 2017 at 06:52:47AM +0200, Samuel Iglesias Gonsálvez wrote:
> Hello Markus,
> 
> Thanks for the patches!
> 
> Series is,
> 
> Acked-by: Samuel Iglesias Gonsalvez 
> 
> Greg, Would you mind picking this patch series through your char-misc
> tree?

I'm sorry, but this person is in my blacklist and I don't have any of
their emails, so I don't have these patches anywhere.  If you wish to
have them applied, please resend them with your acked-by, or just ignore
them, it's up to you.

good luck!

greg k-h

[PATCH 3/3] clk: hi3660: Set PPLL2 to 2880M

[Guodong Xu]

From: Zhong Kaihua 

Set PPLL2 to 2880M. With this patch, we saw better compatibility
on various 1080p HDMI monitors.

Signed-off-by: Zhong Kaihua 
Signed-off-by: Zheng Shaobo 
---
 drivers/clk/hisilicon/clk-hi3660.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/hisilicon/clk-hi3660.c 
b/drivers/clk/hisilicon/clk-hi3660.c
index ffc765a..fd5ce7f 100644
--- a/drivers/clk/hisilicon/clk-hi3660.c
+++ b/drivers/clk/hisilicon/clk-hi3660.c
@@ -20,7 +20,7 @@ static const struct hisi_fixed_rate_clock 
hi3660_fixed_rate_clks[] = {
{ HI3660_CLK_FLL_SRC, "clk_fll_src", NULL, 0, 12800, },
{ HI3660_CLK_PPLL0, "clk_ppll0", NULL, 0, 16, },
{ HI3660_CLK_PPLL1, "clk_ppll1", NULL, 0, 186600, },
-   { HI3660_CLK_PPLL2, "clk_ppll2", NULL, 0, 96000, },
+   { HI3660_CLK_PPLL2, "clk_ppll2", NULL, 0, 288000, },
{ HI3660_CLK_PPLL3, "clk_ppll3", NULL, 0, 129000, },
{ HI3660_CLK_SCPLL, "clk_scpll", NULL, 0, 24576, },
{ HI3660_PCLK, "pclk", NULL, 0, 2000, },
@@ -42,7 +42,7 @@ static const struct hisi_fixed_factor_clock 
hi3660_crg_fixed_factor_clks[] = {
{ HI3660_CLK_GATE_I2C6, "clk_gate_i2c6", "clk_i2c6_iomcu", 1, 4, 0, },
{ HI3660_CLK_DIV_SYSBUS, "clk_div_sysbus", "clk_mux_sysbus", 1, 7, 0, },
{ HI3660_CLK_DIV_320M, "clk_div_320m", "clk_320m_pll_gt", 1, 5, 0, },
-   { HI3660_CLK_DIV_A53, "clk_div_a53hpm", "clk_a53hpm_andgt", 1, 2, 0, },
+   { HI3660_CLK_DIV_A53, "clk_div_a53hpm", "clk_a53hpm_andgt", 1, 6, 0, },
{ HI3660_CLK_GATE_SPI0, "clk_gate_spi0", "clk_ppll0", 1, 8, 0, },
{ HI3660_CLK_GATE_SPI2, "clk_gate_spi2", "clk_ppll0", 1, 8, 0, },
{ HI3660_PCIEPHY_REF, "clk_pciephy_ref", "clk_div_pciephy", 1, 1, 0, },
-- 
2.10.2

[PATCH 2/3] clk: hi3660: add clocks for video encoder and decoder

[Guodong Xu]

From: Chen Jun 

This patch adds clocks for video encoder and decoder.

Signed-off-by: Chen Jun 
Signed-off-by: Guodong Xu 
---
 drivers/clk/hisilicon/clk-hi3660.c   | 23 +++
 include/dt-bindings/clock/hi3660-clock.h | 10 ++
 2 files changed, 33 insertions(+)

diff --git a/drivers/clk/hisilicon/clk-hi3660.c 
b/drivers/clk/hisilicon/clk-hi3660.c
index 143ce0c..ffc765a 100644
--- a/drivers/clk/hisilicon/clk-hi3660.c
+++ b/drivers/clk/hisilicon/clk-hi3660.c
@@ -47,9 +47,12 @@ static const struct hisi_fixed_factor_clock 
hi3660_crg_fixed_factor_clks[] = {
{ HI3660_CLK_GATE_SPI2, "clk_gate_spi2", "clk_ppll0", 1, 8, 0, },
{ HI3660_PCIEPHY_REF, "clk_pciephy_ref", "clk_div_pciephy", 1, 1, 0, },
{ HI3660_CLK_ABB_USB, "clk_abb_usb", "clk_gate_usb_tcxo_en", 1, 1, 0 },
+   { HI3660_VENC_VOLT_HOLD, "venc_volt_hold", "peri_volt_hold", 1, 1, 0, },
 };
 
 static const struct hisi_gate_clock hi3660_crgctrl_gate_sep_clks[] = {
+   { HI3660_PERI_VOLT_HOLD, "peri_volt_hold", "clkin_sys",
+ CLK_SET_RATE_PARENT, 0x0, 0, 0, },
{ HI3660_HCLK_GATE_SDIO0, "hclk_gate_sdio0", "clk_div_sysbus",
  CLK_SET_RATE_PARENT, 0x0, 21, 0, },
{ HI3660_HCLK_GATE_SD, "hclk_gate_sd", "clk_div_sysbus",
@@ -120,6 +123,10 @@ static const struct hisi_gate_clock 
hi3660_crgctrl_gate_sep_clks[] = {
  CLK_SET_RATE_PARENT, 0x20, 27, 0, },
{ HI3660_CLK_GATE_DMAC, "clk_gate_dmac", "clk_div_sysbus",
  CLK_SET_RATE_PARENT, 0x30, 1, 0, },
+   { HI3660_CLK_GATE_VENC, "clk_gate_venc", "clk_div_venc",
+ CLK_SET_RATE_PARENT, 0x30, 10, 0, },
+   { HI3660_CLK_GATE_VDEC, "clk_gate_vdec", "clk_div_vdec",
+ CLK_SET_RATE_PARENT, 0x30, 11, 0, },
{ HI3660_PCLK_GATE_DSS, "pclk_gate_dss", "clk_div_cfgbus",
  CLK_SET_RATE_PARENT, 0x30, 12, 0, },
{ HI3660_ACLK_GATE_DSS, "aclk_gate_dss", "clk_gate_vivobus",
@@ -171,6 +178,10 @@ static const struct hisi_gate_clock 
hi3660_crgctrl_gate_clks[] = {
  CLK_SET_RATE_PARENT, 0xf0, 7, CLK_GATE_HIWORD_MASK, },
{ HI3660_CLK_ANDGT_EDC0, "clk_andgt_edc0", "clk_mux_edc0",
  CLK_SET_RATE_PARENT, 0xf0, 8, CLK_GATE_HIWORD_MASK, },
+   { HI3660_CLK_ANDGT_VDEC, "clk_andgt_vdec", "clk_mux_vdec",
+ CLK_SET_RATE_PARENT, 0xf0, 15, CLK_GATE_HIWORD_MASK, },
+   { HI3660_CLK_ANDGT_VENC, "clk_andgt_venc", "clk_mux_venc",
+ CLK_SET_RATE_PARENT, 0xf4, 0, CLK_GATE_HIWORD_MASK, },
{ HI3660_CLK_GATE_UFSPHY_GT, "clk_gate_ufsphy_gt", "clk_div_ufsperi",
  CLK_SET_RATE_PARENT, 0xf4, 1, CLK_GATE_HIWORD_MASK, },
{ HI3660_CLK_ANDGT_MMC, "clk_andgt_mmc", "clk_mux_mmc_pll",
@@ -239,6 +250,8 @@ static const char *const
 clk_mux_spi_p[] = {"clkin_sys", "clk_div_spi",};
 static const char *const
 clk_mux_i2c_p[] = {"clkin_sys", "clk_div_i2c",};
+static const char *const
+clk_mux_venc_p[] = {"clk_ppll0", "clk_ppll1", "clk_ppll3", "clk_ppll3",};
 
 static const struct hisi_mux_clock hi3660_crgctrl_mux_clks[] = {
{ HI3660_CLK_MUX_SYSBUS, "clk_mux_sysbus", clk_mux_sysbus_p,
@@ -283,6 +296,12 @@ static const struct hisi_mux_clock 
hi3660_crgctrl_mux_clks[] = {
{ HI3660_CLK_MUX_SDIO_PLL, "clk_mux_sdio_pll", clk_mux_pll_p,
  ARRAY_SIZE(clk_mux_pll_p), CLK_SET_RATE_PARENT, 0xc0, 4, 2,
  CLK_MUX_HIWORD_MASK, },
+   { HI3660_CLK_MUX_VENC, "clk_mux_venc", clk_mux_venc_p,
+ ARRAY_SIZE(clk_mux_venc_p), CLK_SET_RATE_PARENT, 0xc8, 11, 2,
+ CLK_MUX_HIWORD_MASK, },
+   { HI3660_CLK_MUX_VDEC, "clk_mux_vdec", clk_mux_pll0123_p,
+ ARRAY_SIZE(clk_mux_pll0123_p), CLK_SET_RATE_PARENT, 0xcc, 5, 2,
+ CLK_MUX_HIWORD_MASK, },
{ HI3660_CLK_MUX_VIVOBUS, "clk_mux_vivobus", clk_mux_pll0123_p,
  ARRAY_SIZE(clk_mux_pll0123_p), CLK_SET_RATE_PARENT, 0xd0, 12, 2,
  CLK_MUX_HIWORD_MASK, },
@@ -318,6 +337,10 @@ static const struct hisi_divider_clock 
hi3660_crgctrl_divider_clks[] = {
  CLK_SET_RATE_PARENT, 0xc0, 8, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
{ HI3660_CLK_DIV_SPI, "clk_div_spi", "clk_andgt_spi",
  CLK_SET_RATE_PARENT, 0xc4, 12, 4, CLK_DIVIDER_HIWORD_MASK, 0, },
+   { HI3660_CLK_DIV_VENC, "clk_div_venc", "clk_andgt_venc",
+ CLK_SET_RATE_PARENT, 0xc8, 6, 5, CLK_DIVIDER_HIWORD_MASK, 0, },
+   { HI3660_CLK_DIV_VDEC, "clk_div_vdec", "clk_andgt_vdec",
+ CLK_SET_RATE_PARENT, 0xcc, 0, 5, CLK_DIVIDER_HIWORD_MASK, 0, },
{ HI3660_CLK_DIV_VIVOBUS, "clk_div_vivobus", "clk_vivobus_andgt",
  CLK_SET_RATE_PARENT, 0xd0, 7, 5, CLK_DIVIDER_HIWORD_MASK, 0, },
{ HI3660_CLK_DIV_I2C, "clk_div_i2c", "clk_div_320m",
diff --git a/include/dt-bindings/clock/hi3660-clock.h 
b/include/dt-bindings/clock/hi3660-clock.h
index 1c00b7f..2cf01b4 100644
--- a/include/dt-bindings/clock/hi3660-clock.h
+++ b/include/dt-bindings/clock/hi3660-clock.h
@@ -154,6 +154,16 @@
 

[PATCH 3/3] clk: hi3660: Set PPLL2 to 2880M

[Guodong Xu]

From: Zhong Kaihua 

Set PPLL2 to 2880M. With this patch, we saw better compatibility
on various 1080p HDMI monitors.

Signed-off-by: Zhong Kaihua 
Signed-off-by: Zheng Shaobo 
---
 drivers/clk/hisilicon/clk-hi3660.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/hisilicon/clk-hi3660.c 
b/drivers/clk/hisilicon/clk-hi3660.c
index ffc765a..fd5ce7f 100644
--- a/drivers/clk/hisilicon/clk-hi3660.c
+++ b/drivers/clk/hisilicon/clk-hi3660.c
@@ -20,7 +20,7 @@ static const struct hisi_fixed_rate_clock 
hi3660_fixed_rate_clks[] = {
{ HI3660_CLK_FLL_SRC, "clk_fll_src", NULL, 0, 12800, },
{ HI3660_CLK_PPLL0, "clk_ppll0", NULL, 0, 16, },
{ HI3660_CLK_PPLL1, "clk_ppll1", NULL, 0, 186600, },
-   { HI3660_CLK_PPLL2, "clk_ppll2", NULL, 0, 96000, },
+   { HI3660_CLK_PPLL2, "clk_ppll2", NULL, 0, 288000, },
{ HI3660_CLK_PPLL3, "clk_ppll3", NULL, 0, 129000, },
{ HI3660_CLK_SCPLL, "clk_scpll", NULL, 0, 24576, },
{ HI3660_PCLK, "pclk", NULL, 0, 2000, },
@@ -42,7 +42,7 @@ static const struct hisi_fixed_factor_clock 
hi3660_crg_fixed_factor_clks[] = {
{ HI3660_CLK_GATE_I2C6, "clk_gate_i2c6", "clk_i2c6_iomcu", 1, 4, 0, },
{ HI3660_CLK_DIV_SYSBUS, "clk_div_sysbus", "clk_mux_sysbus", 1, 7, 0, },
{ HI3660_CLK_DIV_320M, "clk_div_320m", "clk_320m_pll_gt", 1, 5, 0, },
-   { HI3660_CLK_DIV_A53, "clk_div_a53hpm", "clk_a53hpm_andgt", 1, 2, 0, },
+   { HI3660_CLK_DIV_A53, "clk_div_a53hpm", "clk_a53hpm_andgt", 1, 6, 0, },
{ HI3660_CLK_GATE_SPI0, "clk_gate_spi0", "clk_ppll0", 1, 8, 0, },
{ HI3660_CLK_GATE_SPI2, "clk_gate_spi2", "clk_ppll0", 1, 8, 0, },
{ HI3660_PCIEPHY_REF, "clk_pciephy_ref", "clk_div_pciephy", 1, 1, 0, },
-- 
2.10.2

[PATCH 2/3] clk: hi3660: add clocks for video encoder and decoder

[Guodong Xu]

From: Chen Jun 

This patch adds clocks for video encoder and decoder.

Signed-off-by: Chen Jun 
Signed-off-by: Guodong Xu 
---
 drivers/clk/hisilicon/clk-hi3660.c   | 23 +++
 include/dt-bindings/clock/hi3660-clock.h | 10 ++
 2 files changed, 33 insertions(+)

diff --git a/drivers/clk/hisilicon/clk-hi3660.c 
b/drivers/clk/hisilicon/clk-hi3660.c
index 143ce0c..ffc765a 100644
--- a/drivers/clk/hisilicon/clk-hi3660.c
+++ b/drivers/clk/hisilicon/clk-hi3660.c
@@ -47,9 +47,12 @@ static const struct hisi_fixed_factor_clock 
hi3660_crg_fixed_factor_clks[] = {
{ HI3660_CLK_GATE_SPI2, "clk_gate_spi2", "clk_ppll0", 1, 8, 0, },
{ HI3660_PCIEPHY_REF, "clk_pciephy_ref", "clk_div_pciephy", 1, 1, 0, },
{ HI3660_CLK_ABB_USB, "clk_abb_usb", "clk_gate_usb_tcxo_en", 1, 1, 0 },
+   { HI3660_VENC_VOLT_HOLD, "venc_volt_hold", "peri_volt_hold", 1, 1, 0, },
 };
 
 static const struct hisi_gate_clock hi3660_crgctrl_gate_sep_clks[] = {
+   { HI3660_PERI_VOLT_HOLD, "peri_volt_hold", "clkin_sys",
+ CLK_SET_RATE_PARENT, 0x0, 0, 0, },
{ HI3660_HCLK_GATE_SDIO0, "hclk_gate_sdio0", "clk_div_sysbus",
  CLK_SET_RATE_PARENT, 0x0, 21, 0, },
{ HI3660_HCLK_GATE_SD, "hclk_gate_sd", "clk_div_sysbus",
@@ -120,6 +123,10 @@ static const struct hisi_gate_clock 
hi3660_crgctrl_gate_sep_clks[] = {
  CLK_SET_RATE_PARENT, 0x20, 27, 0, },
{ HI3660_CLK_GATE_DMAC, "clk_gate_dmac", "clk_div_sysbus",
  CLK_SET_RATE_PARENT, 0x30, 1, 0, },
+   { HI3660_CLK_GATE_VENC, "clk_gate_venc", "clk_div_venc",
+ CLK_SET_RATE_PARENT, 0x30, 10, 0, },
+   { HI3660_CLK_GATE_VDEC, "clk_gate_vdec", "clk_div_vdec",
+ CLK_SET_RATE_PARENT, 0x30, 11, 0, },
{ HI3660_PCLK_GATE_DSS, "pclk_gate_dss", "clk_div_cfgbus",
  CLK_SET_RATE_PARENT, 0x30, 12, 0, },
{ HI3660_ACLK_GATE_DSS, "aclk_gate_dss", "clk_gate_vivobus",
@@ -171,6 +178,10 @@ static const struct hisi_gate_clock 
hi3660_crgctrl_gate_clks[] = {
  CLK_SET_RATE_PARENT, 0xf0, 7, CLK_GATE_HIWORD_MASK, },
{ HI3660_CLK_ANDGT_EDC0, "clk_andgt_edc0", "clk_mux_edc0",
  CLK_SET_RATE_PARENT, 0xf0, 8, CLK_GATE_HIWORD_MASK, },
+   { HI3660_CLK_ANDGT_VDEC, "clk_andgt_vdec", "clk_mux_vdec",
+ CLK_SET_RATE_PARENT, 0xf0, 15, CLK_GATE_HIWORD_MASK, },
+   { HI3660_CLK_ANDGT_VENC, "clk_andgt_venc", "clk_mux_venc",
+ CLK_SET_RATE_PARENT, 0xf4, 0, CLK_GATE_HIWORD_MASK, },
{ HI3660_CLK_GATE_UFSPHY_GT, "clk_gate_ufsphy_gt", "clk_div_ufsperi",
  CLK_SET_RATE_PARENT, 0xf4, 1, CLK_GATE_HIWORD_MASK, },
{ HI3660_CLK_ANDGT_MMC, "clk_andgt_mmc", "clk_mux_mmc_pll",
@@ -239,6 +250,8 @@ static const char *const
 clk_mux_spi_p[] = {"clkin_sys", "clk_div_spi",};
 static const char *const
 clk_mux_i2c_p[] = {"clkin_sys", "clk_div_i2c",};
+static const char *const
+clk_mux_venc_p[] = {"clk_ppll0", "clk_ppll1", "clk_ppll3", "clk_ppll3",};
 
 static const struct hisi_mux_clock hi3660_crgctrl_mux_clks[] = {
{ HI3660_CLK_MUX_SYSBUS, "clk_mux_sysbus", clk_mux_sysbus_p,
@@ -283,6 +296,12 @@ static const struct hisi_mux_clock 
hi3660_crgctrl_mux_clks[] = {
{ HI3660_CLK_MUX_SDIO_PLL, "clk_mux_sdio_pll", clk_mux_pll_p,
  ARRAY_SIZE(clk_mux_pll_p), CLK_SET_RATE_PARENT, 0xc0, 4, 2,
  CLK_MUX_HIWORD_MASK, },
+   { HI3660_CLK_MUX_VENC, "clk_mux_venc", clk_mux_venc_p,
+ ARRAY_SIZE(clk_mux_venc_p), CLK_SET_RATE_PARENT, 0xc8, 11, 2,
+ CLK_MUX_HIWORD_MASK, },
+   { HI3660_CLK_MUX_VDEC, "clk_mux_vdec", clk_mux_pll0123_p,
+ ARRAY_SIZE(clk_mux_pll0123_p), CLK_SET_RATE_PARENT, 0xcc, 5, 2,
+ CLK_MUX_HIWORD_MASK, },
{ HI3660_CLK_MUX_VIVOBUS, "clk_mux_vivobus", clk_mux_pll0123_p,
  ARRAY_SIZE(clk_mux_pll0123_p), CLK_SET_RATE_PARENT, 0xd0, 12, 2,
  CLK_MUX_HIWORD_MASK, },
@@ -318,6 +337,10 @@ static const struct hisi_divider_clock 
hi3660_crgctrl_divider_clks[] = {
  CLK_SET_RATE_PARENT, 0xc0, 8, 6, CLK_DIVIDER_HIWORD_MASK, 0, },
{ HI3660_CLK_DIV_SPI, "clk_div_spi", "clk_andgt_spi",
  CLK_SET_RATE_PARENT, 0xc4, 12, 4, CLK_DIVIDER_HIWORD_MASK, 0, },
+   { HI3660_CLK_DIV_VENC, "clk_div_venc", "clk_andgt_venc",
+ CLK_SET_RATE_PARENT, 0xc8, 6, 5, CLK_DIVIDER_HIWORD_MASK, 0, },
+   { HI3660_CLK_DIV_VDEC, "clk_div_vdec", "clk_andgt_vdec",
+ CLK_SET_RATE_PARENT, 0xcc, 0, 5, CLK_DIVIDER_HIWORD_MASK, 0, },
{ HI3660_CLK_DIV_VIVOBUS, "clk_div_vivobus", "clk_vivobus_andgt",
  CLK_SET_RATE_PARENT, 0xd0, 7, 5, CLK_DIVIDER_HIWORD_MASK, 0, },
{ HI3660_CLK_DIV_I2C, "clk_div_i2c", "clk_div_320m",
diff --git a/include/dt-bindings/clock/hi3660-clock.h 
b/include/dt-bindings/clock/hi3660-clock.h
index 1c00b7f..2cf01b4 100644
--- a/include/dt-bindings/clock/hi3660-clock.h
+++ b/include/dt-bindings/clock/hi3660-clock.h
@@ -154,6 +154,16 @@
 #define HI3660_CLK_DIV_UFSPERI 137
 #define HI3660_CLK_DIV_AOMM 

[PATCH 1/3] clk: hi3660: fix wrong parent name of clk_mux_sysbus

[Guodong Xu]

From: Chen Jun 

Parent name of clk_mux_sysbus is not correct. This patch fixes it.

Signed-off-by: Chen Jun 
Signed-off-by: John Stultz 
Signed-off-by: Guodong Xu 
---
 drivers/clk/hisilicon/clk-hi3660.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/hisilicon/clk-hi3660.c 
b/drivers/clk/hisilicon/clk-hi3660.c
index 96a9697..143ce0c 100644
--- a/drivers/clk/hisilicon/clk-hi3660.c
+++ b/drivers/clk/hisilicon/clk-hi3660.c
@@ -206,6 +206,8 @@ static const struct hisi_gate_clock 
hi3660_crgctrl_gate_clks[] = {
 };
 
 static const char *const
+clk_mux_sysbus_p[] = {"clk_ppll1", "clk_ppll0"};
+static const char *const
 clk_mux_sdio_sys_p[] = {"clk_factor_mmc", "clk_div_sdio",};
 static const char *const
 clk_mux_sd_sys_p[] = {"clk_factor_mmc", "clk_div_sd",};
@@ -239,8 +241,8 @@ static const char *const
 clk_mux_i2c_p[] = {"clkin_sys", "clk_div_i2c",};
 
 static const struct hisi_mux_clock hi3660_crgctrl_mux_clks[] = {
-   { HI3660_CLK_MUX_SYSBUS, "clk_mux_sysbus", clk_mux_sdio_sys_p,
- ARRAY_SIZE(clk_mux_sdio_sys_p), CLK_SET_RATE_PARENT, 0xac, 0, 1,
+   { HI3660_CLK_MUX_SYSBUS, "clk_mux_sysbus", clk_mux_sysbus_p,
+ ARRAY_SIZE(clk_mux_sysbus_p), CLK_SET_RATE_PARENT, 0xac, 0, 1,
  CLK_MUX_HIWORD_MASK, },
{ HI3660_CLK_MUX_UART0, "clk_mux_uart0", clk_mux_uart0_p,
  ARRAY_SIZE(clk_mux_uart0_p), CLK_SET_RATE_PARENT, 0xac, 2, 1,
-- 
2.10.2

[PATCH 1/3] clk: hi3660: fix wrong parent name of clk_mux_sysbus

[Guodong Xu]

From: Chen Jun 

Parent name of clk_mux_sysbus is not correct. This patch fixes it.

Signed-off-by: Chen Jun 
Signed-off-by: John Stultz 
Signed-off-by: Guodong Xu 
---
 drivers/clk/hisilicon/clk-hi3660.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/hisilicon/clk-hi3660.c 
b/drivers/clk/hisilicon/clk-hi3660.c
index 96a9697..143ce0c 100644
--- a/drivers/clk/hisilicon/clk-hi3660.c
+++ b/drivers/clk/hisilicon/clk-hi3660.c
@@ -206,6 +206,8 @@ static const struct hisi_gate_clock 
hi3660_crgctrl_gate_clks[] = {
 };
 
 static const char *const
+clk_mux_sysbus_p[] = {"clk_ppll1", "clk_ppll0"};
+static const char *const
 clk_mux_sdio_sys_p[] = {"clk_factor_mmc", "clk_div_sdio",};
 static const char *const
 clk_mux_sd_sys_p[] = {"clk_factor_mmc", "clk_div_sd",};
@@ -239,8 +241,8 @@ static const char *const
 clk_mux_i2c_p[] = {"clkin_sys", "clk_div_i2c",};
 
 static const struct hisi_mux_clock hi3660_crgctrl_mux_clks[] = {
-   { HI3660_CLK_MUX_SYSBUS, "clk_mux_sysbus", clk_mux_sdio_sys_p,
- ARRAY_SIZE(clk_mux_sdio_sys_p), CLK_SET_RATE_PARENT, 0xac, 0, 1,
+   { HI3660_CLK_MUX_SYSBUS, "clk_mux_sysbus", clk_mux_sysbus_p,
+ ARRAY_SIZE(clk_mux_sysbus_p), CLK_SET_RATE_PARENT, 0xac, 0, 1,
  CLK_MUX_HIWORD_MASK, },
{ HI3660_CLK_MUX_UART0, "clk_mux_uart0", clk_mux_uart0_p,
  ARRAY_SIZE(clk_mux_uart0_p), CLK_SET_RATE_PARENT, 0xac, 2, 1,
-- 
2.10.2

Re: [PATCH] net: fec: select queue depending on VLAN priority

[Stefan Agner]

On 2017-05-10 21:49, Andy Duan wrote:
> From: Stefan Agner  Sent: Thursday, May 11, 2017 12:08 PM
>>To: Andy Duan 
>>Cc: David Miller ; and...@lunn.ch;
>>feste...@gmail.com; net...@vger.kernel.org; linux-
>>ker...@vger.kernel.org
>>Subject: Re: [PATCH] net: fec: select queue depending on VLAN priority
>>
>>On 2017-05-09 19:42, Andy Duan wrote:
>>> From: David Miller  Sent: Tuesday, May 09, 2017
>>> 9:39 PM
To: ste...@agner.ch
Cc: Andy Duan ; and...@lunn.ch;
feste...@gmail.com; net...@vger.kernel.org; linux-
ker...@vger.kernel.org
Subject: Re: [PATCH] net: fec: select queue depending on VLAN priority

From: Stefan Agner 
Date: Mon,  8 May 2017 22:37:08 -0700

> Since the addition of the multi queue code with commit 59d0f7465644
> ("net: fec: init multi queue date structure") the queue selection
> has been handelt by the default transmit queue selection
> implementation which tries to evenly distribute the traffic across
> all available queues. This selection presumes that the queues are
> using an equal priority, however, the queues 1 and 2 are actually of
> higher priority (the classification of the queues is enabled in
>>fec_enet_enable_ring).
>
> This can lead to net scheduler warnings and continuous TX ring dumps
> when exercising the system with iperf.
>
> Use only queue 0 for all common traffic (no VLAN and P802.1p
> priority
> 0 and 1) and route level 2-7 through queue 1 and 2.
>
> Signed-off-by: Fugang Duan 
> Fixes: 59d0f7465644 ("net: fec: init multi queue date structure")

If the queues are used for prioritization, and it does not have
multiple normal priority level queues, multiqueue is not what the
driver should have implemented.
>>> Firstly, HW multiple queues support:
>>> - Traffic-shaping bandwidth distribution supports credit-based and
>>> round-robin-based policies. Either policy can be combined with
>>> time-based shaping.
>>> - AVB (Audio Video Bridging, IEEE 802.1Qav) features:
>>> * Credit-based bandwidth distribution policy can be combined
>>with
>>> time-based shaping
>>> * AVB endpoint talker and listener support
>>> * Support for arbitration between different priority traffic 
>>> (for
>>> example, AVB class A, AVB class B, and non-AVB) Round-robin-based
>>> policies:
>>> It has the same priority for three queues: In the round-robin QoS
>>> scheme, each queue is given an equal opportunity to transmit one
>>> frame. For example, if queue n has a frame to transmit, the queue
>>> transmits its frame. After queue n has transmitted its frame, or if
>>> queue n does not have a frame to transmit, queue n+1 is then allowed
>>> to transmit its frame, and so on.
>>>
>>> Credit-based policies:
>>> The AVB credit based shaper acts independently, per class, to control
>>> the bandwidth distribution between normal traffic and time-sensitive
>>> traffic with respect to the total link bandwidth available.
>>> Credit based shaper conbined with time-based shaping:
>>> - priority: ClassA queue > ClassB queue > best effort
>>> - ensure the queue bandwidth as user set based on time-
>>based shaping
>>> algorithms (transmitter transmit frame from three queue in turn based
>>> on time-based shaping algorithms)
>>> And in real AVB case,  each streaming can be independent, and are
>>> fixed on related queue. Then driver level should implement
>>> .ndo_select_queue() to put the streaming into related queue. That is
>>> what the patch did.
>>>
>>> The current driver config the three queue to credit-based policies
>>> (AVB), the patch seems no problem for the implementation. Do you have
>>> any suggestion ?
>>>
>>
>>I tried using the round robin mode by adding this:
>>
>>+   /* Set Round-Robin policy */
>>+   writel(1, fep->hwp + FEC_QOS_SCHEME);
>>
>>After a while I got the warning non the less:
>>
>>WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:316
>>dev_watchdog+0x248/0x24c NETDEV WATCHDOG: eth0 (fec): transmit queue
>>2 timed out Modules linked in:
>>CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1-00058-g56d22eced8bc-
>>dirty #377 Hardware name: Freescale i.MX7 Dual (Device Tree) []
>>(unwind_backtrace) from [] (show_stack+0x10/0x14) []
>>(show_stack) from [] (dump_stack+0x78/0x8c) []
>>(dump_stack) from [] (__warn+0xe8/0x100) []
>>(__warn) from [] (warn_slowpath_fmt+0x38/0x48) []
>>(warn_slowpath_fmt) from []
>>(dev_watchdog+0x248/0x24c)
>>[] (dev_watchdog) from [] (call_timer_fn+0x28/0x98)
>>[] (call_timer_fn) from [] (expire_timers+0xa0/0xac)
>>[] (expire_timers) from []
>>(run_timer_softirq+0x9c/0x194)
>>[] (run_timer_softirq) from []
>>(__do_softirq+0x114/0x234)
>>[] (__do_softirq) from [] (irq_exit+0xcc/0x108)
>>[] (irq_exit) from []

Re: [PATCH] net: fec: select queue depending on VLAN priority

[Stefan Agner]

On 2017-05-10 21:49, Andy Duan wrote:
> From: Stefan Agner  Sent: Thursday, May 11, 2017 12:08 PM
>>To: Andy Duan 
>>Cc: David Miller ; and...@lunn.ch;
>>feste...@gmail.com; net...@vger.kernel.org; linux-
>>ker...@vger.kernel.org
>>Subject: Re: [PATCH] net: fec: select queue depending on VLAN priority
>>
>>On 2017-05-09 19:42, Andy Duan wrote:
>>> From: David Miller  Sent: Tuesday, May 09, 2017
>>> 9:39 PM
To: ste...@agner.ch
Cc: Andy Duan ; and...@lunn.ch;
feste...@gmail.com; net...@vger.kernel.org; linux-
ker...@vger.kernel.org
Subject: Re: [PATCH] net: fec: select queue depending on VLAN priority

From: Stefan Agner 
Date: Mon,  8 May 2017 22:37:08 -0700

> Since the addition of the multi queue code with commit 59d0f7465644
> ("net: fec: init multi queue date structure") the queue selection
> has been handelt by the default transmit queue selection
> implementation which tries to evenly distribute the traffic across
> all available queues. This selection presumes that the queues are
> using an equal priority, however, the queues 1 and 2 are actually of
> higher priority (the classification of the queues is enabled in
>>fec_enet_enable_ring).
>
> This can lead to net scheduler warnings and continuous TX ring dumps
> when exercising the system with iperf.
>
> Use only queue 0 for all common traffic (no VLAN and P802.1p
> priority
> 0 and 1) and route level 2-7 through queue 1 and 2.
>
> Signed-off-by: Fugang Duan 
> Fixes: 59d0f7465644 ("net: fec: init multi queue date structure")

If the queues are used for prioritization, and it does not have
multiple normal priority level queues, multiqueue is not what the
driver should have implemented.
>>> Firstly, HW multiple queues support:
>>> - Traffic-shaping bandwidth distribution supports credit-based and
>>> round-robin-based policies. Either policy can be combined with
>>> time-based shaping.
>>> - AVB (Audio Video Bridging, IEEE 802.1Qav) features:
>>> * Credit-based bandwidth distribution policy can be combined
>>with
>>> time-based shaping
>>> * AVB endpoint talker and listener support
>>> * Support for arbitration between different priority traffic 
>>> (for
>>> example, AVB class A, AVB class B, and non-AVB) Round-robin-based
>>> policies:
>>> It has the same priority for three queues: In the round-robin QoS
>>> scheme, each queue is given an equal opportunity to transmit one
>>> frame. For example, if queue n has a frame to transmit, the queue
>>> transmits its frame. After queue n has transmitted its frame, or if
>>> queue n does not have a frame to transmit, queue n+1 is then allowed
>>> to transmit its frame, and so on.
>>>
>>> Credit-based policies:
>>> The AVB credit based shaper acts independently, per class, to control
>>> the bandwidth distribution between normal traffic and time-sensitive
>>> traffic with respect to the total link bandwidth available.
>>> Credit based shaper conbined with time-based shaping:
>>> - priority: ClassA queue > ClassB queue > best effort
>>> - ensure the queue bandwidth as user set based on time-
>>based shaping
>>> algorithms (transmitter transmit frame from three queue in turn based
>>> on time-based shaping algorithms)
>>> And in real AVB case,  each streaming can be independent, and are
>>> fixed on related queue. Then driver level should implement
>>> .ndo_select_queue() to put the streaming into related queue. That is
>>> what the patch did.
>>>
>>> The current driver config the three queue to credit-based policies
>>> (AVB), the patch seems no problem for the implementation. Do you have
>>> any suggestion ?
>>>
>>
>>I tried using the round robin mode by adding this:
>>
>>+   /* Set Round-Robin policy */
>>+   writel(1, fep->hwp + FEC_QOS_SCHEME);
>>
>>After a while I got the warning non the less:
>>
>>WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:316
>>dev_watchdog+0x248/0x24c NETDEV WATCHDOG: eth0 (fec): transmit queue
>>2 timed out Modules linked in:
>>CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1-00058-g56d22eced8bc-
>>dirty #377 Hardware name: Freescale i.MX7 Dual (Device Tree) []
>>(unwind_backtrace) from [] (show_stack+0x10/0x14) []
>>(show_stack) from [] (dump_stack+0x78/0x8c) []
>>(dump_stack) from [] (__warn+0xe8/0x100) []
>>(__warn) from [] (warn_slowpath_fmt+0x38/0x48) []
>>(warn_slowpath_fmt) from []
>>(dev_watchdog+0x248/0x24c)
>>[] (dev_watchdog) from [] (call_timer_fn+0x28/0x98)
>>[] (call_timer_fn) from [] (expire_timers+0xa0/0xac)
>>[] (expire_timers) from []
>>(run_timer_softirq+0x9c/0x194)
>>[] (run_timer_softirq) from []
>>(__do_softirq+0x114/0x234)
>>[] (__do_softirq) from [] (irq_exit+0xcc/0x108)
>>[] (irq_exit) from []
>>(__handle_domain_irq+0x80/0xec)
>>[] (__handle_domain_irq) from []
>>(gic_handle_irq+0x48/0x8c)
>>[] (gic_handle_irq) from [] (__irq_svc+0x58/0x8c)

[PATCH] drivers/staging/ccree: Removing trailing whitespaces

[Pushkar Jambhlekar]

Fixing 'checkpatch.pl' warnings: Trailing whitespaces

Signed-off-by: Pushkar Jambhlekar 
---
 drivers/staging/ccree/ssi_cipher.c | 110 ++---
 1 file changed, 55 insertions(+), 55 deletions(-)

diff --git a/drivers/staging/ccree/ssi_cipher.c 
b/drivers/staging/ccree/ssi_cipher.c
index 664ed7e..7e85d2c 100644
--- a/drivers/staging/ccree/ssi_cipher.c
+++ b/drivers/staging/ccree/ssi_cipher.c
@@ -1,15 +1,15 @@
 /*
  * Copyright (C) 2012-2017 ARM Limited or its affiliates.
- * 
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
- * 
+ *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
- * 
+ *
  * You should have received a copy of the GNU General Public License
  * along with this program; if not, see .
  */
@@ -117,7 +117,7 @@ static int validate_data_size(struct ssi_ablkcipher_ctx 
*ctx_p, unsigned int siz
switch (ctx_p->cipher_mode){
case DRV_CIPHER_XTS:
if ((size >= SSI_MIN_AES_XTS_SIZE) &&
-   (size <= SSI_MAX_AES_XTS_SIZE) && 
+   (size <= SSI_MAX_AES_XTS_SIZE) &&
IS_ALIGNED(size, AES_BLOCK_SIZE))
return 0;
break;
@@ -189,7 +189,7 @@ static int ssi_blkcipher_init(struct crypto_tfm *tfm)
int rc = 0;
unsigned int max_key_buf_size = get_max_keysize(tfm);
 
-   SSI_LOG_DEBUG("Initializing context @%p for %s\n", ctx_p, 
+   SSI_LOG_DEBUG("Initializing context @%p for %s\n", ctx_p,
crypto_tfm_alg_name(tfm));
 
CHECK_AND_RETURN_UPON_FIPS_ERROR();
@@ -251,7 +251,7 @@ static void ssi_blkcipher_exit(struct crypto_tfm *tfm)
SSI_RESTORE_DMA_ADDR_TO_48BIT(ctx_p->user.key_dma_addr);
dma_unmap_single(dev, ctx_p->user.key_dma_addr, max_key_buf_size,
DMA_TO_DEVICE);
-   SSI_LOG_DEBUG("Unmapped key buffer key_dma_addr=0x%llX\n", 
+   SSI_LOG_DEBUG("Unmapped key buffer key_dma_addr=0x%llX\n",
(unsigned long long)ctx_p->user.key_dma_addr);
 
/* Free key buffer in context */
@@ -266,9 +266,9 @@ typedef struct tdes_keys{
 u8  key3[DES_KEY_SIZE];
 }tdes_keys_t;
 
-static const u8 zero_buff[] = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
+static const u8 zero_buff[] = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+   0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
-   0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0};
 
 /* The function verifies that tdes keys are not weak.*/
@@ -278,7 +278,7 @@ static int ssi_fips_verify_3des_keys(const u8 *key, 
unsigned int keylen)
 tdes_keys_t *tdes_key = (tdes_keys_t*)key;
 
/* verify key1 != key2 and key3 != key2*/
-if (unlikely( (memcmp((u8*)tdes_key->key1, (u8*)tdes_key->key2, 
sizeof(tdes_key->key1)) == 0) || 
+if (unlikely( (memcmp((u8*)tdes_key->key1, (u8*)tdes_key->key2, 
sizeof(tdes_key->key1)) == 0) ||
  (memcmp((u8*)tdes_key->key3, (u8*)tdes_key->key2, 
sizeof(tdes_key->key3)) == 0) )) {
 return -ENOEXEC;
 }
@@ -317,8 +317,8 @@ static enum HwCryptoKey hw_key_to_cc_hw_key(int slot_num)
return END_OF_KEYS;
 }
 
-static int ssi_blkcipher_setkey(struct crypto_tfm *tfm, 
-   const u8 *key, 
+static int ssi_blkcipher_setkey(struct crypto_tfm *tfm,
+   const u8 *key,
unsigned int keylen)
 {
struct ssi_ablkcipher_ctx *ctx_p = crypto_tfm_ctx(tfm);
@@ -334,7 +334,7 @@ static int ssi_blkcipher_setkey(struct crypto_tfm *tfm,
CHECK_AND_RETURN_UPON_FIPS_ERROR();
 
SSI_LOG_DEBUG("ssi_blkcipher_setkey: after FIPS check");
-   
+
/* STAT_PHASE_0: Init and sanity checks */
START_CYCLE_COUNT();
 
@@ -396,13 +396,13 @@ static int ssi_blkcipher_setkey(struct crypto_tfm *tfm,
return -EINVAL;
}
}
-   if ((ctx_p->cipher_mode == DRV_CIPHER_XTS) && 
+   if ((ctx_p->cipher_mode == DRV_CIPHER_XTS) &&
ssi_fips_verify_xts_keys(key, keylen) != 0) {
SSI_LOG_DEBUG("ssi_blkcipher_setkey: weak XTS key");
return -EINVAL;
}
-   if ((ctx_p->flow_mode == S_DIN_to_DES) && 
-   (keylen == DES3_EDE_KEY_SIZE) && 

[PATCH] drivers/staging/ccree: Removing trailing whitespaces

[Pushkar Jambhlekar]

Fixing 'checkpatch.pl' warnings: Trailing whitespaces

Signed-off-by: Pushkar Jambhlekar 
---
 drivers/staging/ccree/ssi_cipher.c | 110 ++---
 1 file changed, 55 insertions(+), 55 deletions(-)

diff --git a/drivers/staging/ccree/ssi_cipher.c 
b/drivers/staging/ccree/ssi_cipher.c
index 664ed7e..7e85d2c 100644
--- a/drivers/staging/ccree/ssi_cipher.c
+++ b/drivers/staging/ccree/ssi_cipher.c
@@ -1,15 +1,15 @@
 /*
  * Copyright (C) 2012-2017 ARM Limited or its affiliates.
- * 
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
- * 
+ *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
- * 
+ *
  * You should have received a copy of the GNU General Public License
  * along with this program; if not, see .
  */
@@ -117,7 +117,7 @@ static int validate_data_size(struct ssi_ablkcipher_ctx 
*ctx_p, unsigned int siz
switch (ctx_p->cipher_mode){
case DRV_CIPHER_XTS:
if ((size >= SSI_MIN_AES_XTS_SIZE) &&
-   (size <= SSI_MAX_AES_XTS_SIZE) && 
+   (size <= SSI_MAX_AES_XTS_SIZE) &&
IS_ALIGNED(size, AES_BLOCK_SIZE))
return 0;
break;
@@ -189,7 +189,7 @@ static int ssi_blkcipher_init(struct crypto_tfm *tfm)
int rc = 0;
unsigned int max_key_buf_size = get_max_keysize(tfm);
 
-   SSI_LOG_DEBUG("Initializing context @%p for %s\n", ctx_p, 
+   SSI_LOG_DEBUG("Initializing context @%p for %s\n", ctx_p,
crypto_tfm_alg_name(tfm));
 
CHECK_AND_RETURN_UPON_FIPS_ERROR();
@@ -251,7 +251,7 @@ static void ssi_blkcipher_exit(struct crypto_tfm *tfm)
SSI_RESTORE_DMA_ADDR_TO_48BIT(ctx_p->user.key_dma_addr);
dma_unmap_single(dev, ctx_p->user.key_dma_addr, max_key_buf_size,
DMA_TO_DEVICE);
-   SSI_LOG_DEBUG("Unmapped key buffer key_dma_addr=0x%llX\n", 
+   SSI_LOG_DEBUG("Unmapped key buffer key_dma_addr=0x%llX\n",
(unsigned long long)ctx_p->user.key_dma_addr);
 
/* Free key buffer in context */
@@ -266,9 +266,9 @@ typedef struct tdes_keys{
 u8  key3[DES_KEY_SIZE];
 }tdes_keys_t;
 
-static const u8 zero_buff[] = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
+static const u8 zero_buff[] = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+   0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
-   0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0};
 
 /* The function verifies that tdes keys are not weak.*/
@@ -278,7 +278,7 @@ static int ssi_fips_verify_3des_keys(const u8 *key, 
unsigned int keylen)
 tdes_keys_t *tdes_key = (tdes_keys_t*)key;
 
/* verify key1 != key2 and key3 != key2*/
-if (unlikely( (memcmp((u8*)tdes_key->key1, (u8*)tdes_key->key2, 
sizeof(tdes_key->key1)) == 0) || 
+if (unlikely( (memcmp((u8*)tdes_key->key1, (u8*)tdes_key->key2, 
sizeof(tdes_key->key1)) == 0) ||
  (memcmp((u8*)tdes_key->key3, (u8*)tdes_key->key2, 
sizeof(tdes_key->key3)) == 0) )) {
 return -ENOEXEC;
 }
@@ -317,8 +317,8 @@ static enum HwCryptoKey hw_key_to_cc_hw_key(int slot_num)
return END_OF_KEYS;
 }
 
-static int ssi_blkcipher_setkey(struct crypto_tfm *tfm, 
-   const u8 *key, 
+static int ssi_blkcipher_setkey(struct crypto_tfm *tfm,
+   const u8 *key,
unsigned int keylen)
 {
struct ssi_ablkcipher_ctx *ctx_p = crypto_tfm_ctx(tfm);
@@ -334,7 +334,7 @@ static int ssi_blkcipher_setkey(struct crypto_tfm *tfm,
CHECK_AND_RETURN_UPON_FIPS_ERROR();
 
SSI_LOG_DEBUG("ssi_blkcipher_setkey: after FIPS check");
-   
+
/* STAT_PHASE_0: Init and sanity checks */
START_CYCLE_COUNT();
 
@@ -396,13 +396,13 @@ static int ssi_blkcipher_setkey(struct crypto_tfm *tfm,
return -EINVAL;
}
}
-   if ((ctx_p->cipher_mode == DRV_CIPHER_XTS) && 
+   if ((ctx_p->cipher_mode == DRV_CIPHER_XTS) &&
ssi_fips_verify_xts_keys(key, keylen) != 0) {
SSI_LOG_DEBUG("ssi_blkcipher_setkey: weak XTS key");
return -EINVAL;
}
-   if ((ctx_p->flow_mode == S_DIN_to_DES) && 
-   (keylen == DES3_EDE_KEY_SIZE) && 
+   if 

Re: [patch 09/18] cpufreq/pasemi: Adjust system_state check

[Viresh Kumar]

On 14-05-17, 20:27, Thomas Gleixner wrote:
> To enable smp_processor_id() and might_sleep() debug checks earlier, it's
> required to add system states between SYSTEM_BOOTING and SYSTEM_RUNNING.
> 
> Adjust the system_state check in pas_cpufreq_cpu_exit() to handle the extra
> states.
> 
> Signed-off-by: Thomas Gleixner 
> Cc: "Rafael J. Wysocki" 
> Cc: Viresh Kumar 
> Cc: linuxppc-...@lists.ozlabs.org
> ---
>  drivers/cpufreq/pasemi-cpufreq.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/drivers/cpufreq/pasemi-cpufreq.c
> +++ b/drivers/cpufreq/pasemi-cpufreq.c
> @@ -226,7 +226,7 @@ static int pas_cpufreq_cpu_exit(struct c
>* We don't support CPU hotplug. Don't unmap after the system
>* has already made it to a running state.
>*/
> - if (system_state != SYSTEM_BOOTING)
> + if (system_state >= SYSTEM_RUNNING)
>   return 0;
>  
>   if (sdcasr_mapbase)

Acked-by: Viresh Kumar 

-- 
viresh

Re: [patch 09/18] cpufreq/pasemi: Adjust system_state check

[Viresh Kumar]

On 14-05-17, 20:27, Thomas Gleixner wrote:
> To enable smp_processor_id() and might_sleep() debug checks earlier, it's
> required to add system states between SYSTEM_BOOTING and SYSTEM_RUNNING.
> 
> Adjust the system_state check in pas_cpufreq_cpu_exit() to handle the extra
> states.
> 
> Signed-off-by: Thomas Gleixner 
> Cc: "Rafael J. Wysocki" 
> Cc: Viresh Kumar 
> Cc: linuxppc-...@lists.ozlabs.org
> ---
>  drivers/cpufreq/pasemi-cpufreq.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/drivers/cpufreq/pasemi-cpufreq.c
> +++ b/drivers/cpufreq/pasemi-cpufreq.c
> @@ -226,7 +226,7 @@ static int pas_cpufreq_cpu_exit(struct c
>* We don't support CPU hotplug. Don't unmap after the system
>* has already made it to a running state.
>*/
> - if (system_state != SYSTEM_BOOTING)
> + if (system_state >= SYSTEM_RUNNING)
>   return 0;
>  
>   if (sdcasr_mapbase)

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v5] iio: adc: Add support for TI ADC108S102 and ADC128S102

[Jan Kiszka]

On 2017-05-14 17:50, Jonathan Cameron wrote:
> On 08/05/17 09:46, Jan Kiszka wrote:
>> This is an upstream port of an IIO driver for the TI ADC108S102 and
>> ADC128S102. The former can be found on the Intel Galileo Gen2 and the
>> Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is
>> included.
>>
>> Due to the lack of regulators under ACPI, we hard-code the voltage
>> provided to the VA pin of the ADC to 5 V, the value used on Galileo and
>> IOT2000. For DT usage, the regulator "vref-supply" provides this
>> information. Note that DT usage has not been tested.
>>
>> Original author: Bogdan Pricop 
>> Ported from Intel Galileo Gen2 BSP to Intel Yocto kernel:
>> Todor Minchev .
>>
>> Signed-off-by: Jan Kiszka 
> A small race issue in remove, but otherwise looking very nice.
> 
> I'm on the edge of just cleaning that up and applying this,
> but with the reordering I'm suggesting it's probably best you
> give it some thought rather than me just assuming it'll be fine ;)
> 
> Jonathan
>> ---
>>
>> Changes in v5:
>>   - refactor error handling in adc108s102_read_raw
>>   - removed no longer needed checks before regulator_disable
>> (v3 left-over)
>>
>>   .../devicetree/bindings/iio/adc/ti-adc108s102.txt  |  18 ++
>>   drivers/iio/adc/Kconfig|  12 +
>>   drivers/iio/adc/Makefile   |   1 +
>>   drivers/iio/adc/ti-adc108s102.c| 342
>> +
>>   4 files changed, 373 insertions(+)
>>   create mode 100644
>> Documentation/devicetree/bindings/iio/adc/ti-adc108s102.txt
>>   create mode 100644 drivers/iio/adc/ti-adc108s102.c
>>
>> diff --git
>> a/Documentation/devicetree/bindings/iio/adc/ti-adc108s102.txt
>> b/Documentation/devicetree/bindings/iio/adc/ti-adc108s102.txt
>> new file mode 100644
>> index ..b4a9f58f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/adc/ti-adc108s102.txt
>> @@ -0,0 +1,18 @@
>> +* Texas Instruments' ADC108S102 and ADC128S102 ADC chip
>> +
>> +Required properties:
>> + - compatible: Should be "ti,adc108s102"
>> + - reg: spi chip select number for the device
>> + - vref-supply: The regulator supply for ADC reference voltage
>> +
>> +Recommended properties:
>> + - spi-max-frequency: Definition as per
>> +Documentation/devicetree/bindings/spi/spi-bus.txt
>> +
>> +Example:
>> +adc@0 {
>> +compatible = "ti,adc108s102";
>> +reg = <0>;
>> +vref-supply = <_supply>;
>> +spi-max-frequency = <100>;
>> +};
>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>> index dedae7adbce9..8b7dae5604f2 100644
>> --- a/drivers/iio/adc/Kconfig
>> +++ b/drivers/iio/adc/Kconfig
>> @@ -572,6 +572,18 @@ config TI_ADC12138
>> This driver can also be built as a module. If so, the module
>> will be
>> called ti-adc12138.
>>   +config TI_ADC108S102
>> +tristate "Texas Instruments ADC108S102 and ADC128S102 driver"
>> +depends on SPI
>> +select IIO_BUFFER
>> +select IIO_TRIGGERED_BUFFER
>> +help
>> +  Say yes here to build support for Texas Instruments ADC108S102 and
>> +  ADC128S102 ADC.
>> +
>> +  To compile this driver as a module, choose M here: the module will
>> +  be called ti-adc108s102.
>> +
>>   config TI_ADC128S052
>>   tristate "Texas Instruments ADC128S052/ADC122S021/ADC124S021"
>>   depends on SPI
>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>> index d0012620cd1c..e6c20fe3d4eb 100644
>> --- a/drivers/iio/adc/Makefile
>> +++ b/drivers/iio/adc/Makefile
>> @@ -52,6 +52,7 @@ obj-$(CONFIG_STM32_ADC) += stm32-adc.o
>>   obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>>   obj-$(CONFIG_TI_ADC0832) += ti-adc0832.o
>>   obj-$(CONFIG_TI_ADC12138) += ti-adc12138.o
>> +obj-$(CONFIG_TI_ADC108S102) += ti-adc108s102.o
>>   obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o
>>   obj-$(CONFIG_TI_ADC161S626) += ti-adc161s626.o
>>   obj-$(CONFIG_TI_ADS1015) += ti-ads1015.o
>> diff --git a/drivers/iio/adc/ti-adc108s102.c
>> b/drivers/iio/adc/ti-adc108s102.c
>> new file mode 100644
>> index ..bdf3254619a3
>> --- /dev/null
>> +++ b/drivers/iio/adc/ti-adc108s102.c
>> @@ -0,0 +1,342 @@
>> +/*
>> + * TI ADC108S102 SPI ADC driver
>> + *
>> + * Copyright (c) 2013-2015 Intel Corporation.
>> + * Copyright (c) 2017 Siemens AG
>> + *
>> + * This program is free software; you can redistribute it and/or
>> modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope it will be useful, but
>> WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
>> License for
>> + * more details.
>> + *
>> + * This IIO device driver is designed to work with the following
>> + * analog to digital 

Re: [PATCH v5] iio: adc: Add support for TI ADC108S102 and ADC128S102

[Jan Kiszka]

On 2017-05-14 17:50, Jonathan Cameron wrote:
> On 08/05/17 09:46, Jan Kiszka wrote:
>> This is an upstream port of an IIO driver for the TI ADC108S102 and
>> ADC128S102. The former can be found on the Intel Galileo Gen2 and the
>> Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is
>> included.
>>
>> Due to the lack of regulators under ACPI, we hard-code the voltage
>> provided to the VA pin of the ADC to 5 V, the value used on Galileo and
>> IOT2000. For DT usage, the regulator "vref-supply" provides this
>> information. Note that DT usage has not been tested.
>>
>> Original author: Bogdan Pricop 
>> Ported from Intel Galileo Gen2 BSP to Intel Yocto kernel:
>> Todor Minchev .
>>
>> Signed-off-by: Jan Kiszka 
> A small race issue in remove, but otherwise looking very nice.
> 
> I'm on the edge of just cleaning that up and applying this,
> but with the reordering I'm suggesting it's probably best you
> give it some thought rather than me just assuming it'll be fine ;)
> 
> Jonathan
>> ---
>>
>> Changes in v5:
>>   - refactor error handling in adc108s102_read_raw
>>   - removed no longer needed checks before regulator_disable
>> (v3 left-over)
>>
>>   .../devicetree/bindings/iio/adc/ti-adc108s102.txt  |  18 ++
>>   drivers/iio/adc/Kconfig|  12 +
>>   drivers/iio/adc/Makefile   |   1 +
>>   drivers/iio/adc/ti-adc108s102.c| 342
>> +
>>   4 files changed, 373 insertions(+)
>>   create mode 100644
>> Documentation/devicetree/bindings/iio/adc/ti-adc108s102.txt
>>   create mode 100644 drivers/iio/adc/ti-adc108s102.c
>>
>> diff --git
>> a/Documentation/devicetree/bindings/iio/adc/ti-adc108s102.txt
>> b/Documentation/devicetree/bindings/iio/adc/ti-adc108s102.txt
>> new file mode 100644
>> index ..b4a9f58f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/adc/ti-adc108s102.txt
>> @@ -0,0 +1,18 @@
>> +* Texas Instruments' ADC108S102 and ADC128S102 ADC chip
>> +
>> +Required properties:
>> + - compatible: Should be "ti,adc108s102"
>> + - reg: spi chip select number for the device
>> + - vref-supply: The regulator supply for ADC reference voltage
>> +
>> +Recommended properties:
>> + - spi-max-frequency: Definition as per
>> +Documentation/devicetree/bindings/spi/spi-bus.txt
>> +
>> +Example:
>> +adc@0 {
>> +compatible = "ti,adc108s102";
>> +reg = <0>;
>> +vref-supply = <_supply>;
>> +spi-max-frequency = <100>;
>> +};
>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>> index dedae7adbce9..8b7dae5604f2 100644
>> --- a/drivers/iio/adc/Kconfig
>> +++ b/drivers/iio/adc/Kconfig
>> @@ -572,6 +572,18 @@ config TI_ADC12138
>> This driver can also be built as a module. If so, the module
>> will be
>> called ti-adc12138.
>>   +config TI_ADC108S102
>> +tristate "Texas Instruments ADC108S102 and ADC128S102 driver"
>> +depends on SPI
>> +select IIO_BUFFER
>> +select IIO_TRIGGERED_BUFFER
>> +help
>> +  Say yes here to build support for Texas Instruments ADC108S102 and
>> +  ADC128S102 ADC.
>> +
>> +  To compile this driver as a module, choose M here: the module will
>> +  be called ti-adc108s102.
>> +
>>   config TI_ADC128S052
>>   tristate "Texas Instruments ADC128S052/ADC122S021/ADC124S021"
>>   depends on SPI
>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>> index d0012620cd1c..e6c20fe3d4eb 100644
>> --- a/drivers/iio/adc/Makefile
>> +++ b/drivers/iio/adc/Makefile
>> @@ -52,6 +52,7 @@ obj-$(CONFIG_STM32_ADC) += stm32-adc.o
>>   obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>>   obj-$(CONFIG_TI_ADC0832) += ti-adc0832.o
>>   obj-$(CONFIG_TI_ADC12138) += ti-adc12138.o
>> +obj-$(CONFIG_TI_ADC108S102) += ti-adc108s102.o
>>   obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o
>>   obj-$(CONFIG_TI_ADC161S626) += ti-adc161s626.o
>>   obj-$(CONFIG_TI_ADS1015) += ti-ads1015.o
>> diff --git a/drivers/iio/adc/ti-adc108s102.c
>> b/drivers/iio/adc/ti-adc108s102.c
>> new file mode 100644
>> index ..bdf3254619a3
>> --- /dev/null
>> +++ b/drivers/iio/adc/ti-adc108s102.c
>> @@ -0,0 +1,342 @@
>> +/*
>> + * TI ADC108S102 SPI ADC driver
>> + *
>> + * Copyright (c) 2013-2015 Intel Corporation.
>> + * Copyright (c) 2017 Siemens AG
>> + *
>> + * This program is free software; you can redistribute it and/or
>> modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope it will be useful, but
>> WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
>> License for
>> + * more details.
>> + *
>> + * This IIO device driver is designed to work with the following
>> + * analog to digital converters from Texas Instruments:
>> + *  ADC108S102
>> + *  

Re: [PATCH 2/2] ipack: Improve a size determination in ipack_bus_register()

[Samuel Iglesias Gonsálvez]

Hello Markus,

Thanks for the patches!

Series is,

Acked-by: Samuel Iglesias Gonsalvez 

Greg, Would you mind picking this patch series through your char-misc
tree?

Sam

On Sat, 2017-05-13 at 10:56 +0200, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Sat, 13 May 2017 10:37:06 +0200
> 
> Replace the specification of a data structure by a pointer
> dereference
> as the parameter for the operator "sizeof" to make the corresponding
> size
> determination a bit safer according to the Linux coding style
> convention.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/ipack/ipack.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/ipack/ipack.c b/drivers/ipack/ipack.c
> index 575c4f29e0f7..a1e07a77d4e6 100644
> --- a/drivers/ipack/ipack.c
> +++ b/drivers/ipack/ipack.c
> @@ -212,7 +212,7 @@ struct ipack_bus_device
> *ipack_bus_register(struct device *parent, int slots,
>   int bus_nr;
>   struct ipack_bus_device *bus;
>  
> - bus = kzalloc(sizeof(struct ipack_bus_device), GFP_KERNEL);
> + bus = kzalloc(sizeof(*bus), GFP_KERNEL);
>   if (!bus)
>   return NULL;
>  

signature.asc
Description: This is a digitally signed message part

Re: [PATCH 2/2] ipack: Improve a size determination in ipack_bus_register()

[Samuel Iglesias Gonsálvez]

Hello Markus,

Thanks for the patches!

Series is,

Acked-by: Samuel Iglesias Gonsalvez 

Greg, Would you mind picking this patch series through your char-misc
tree?

Sam

On Sat, 2017-05-13 at 10:56 +0200, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Sat, 13 May 2017 10:37:06 +0200
> 
> Replace the specification of a data structure by a pointer
> dereference
> as the parameter for the operator "sizeof" to make the corresponding
> size
> determination a bit safer according to the Linux coding style
> convention.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/ipack/ipack.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/ipack/ipack.c b/drivers/ipack/ipack.c
> index 575c4f29e0f7..a1e07a77d4e6 100644
> --- a/drivers/ipack/ipack.c
> +++ b/drivers/ipack/ipack.c
> @@ -212,7 +212,7 @@ struct ipack_bus_device
> *ipack_bus_register(struct device *parent, int slots,
>   int bus_nr;
>   struct ipack_bus_device *bus;
>  
> - bus = kzalloc(sizeof(struct ipack_bus_device), GFP_KERNEL);
> + bus = kzalloc(sizeof(*bus), GFP_KERNEL);
>   if (!bus)
>   return NULL;
>  

signature.asc
Description: This is a digitally signed message part

Re: nouveau "eDP-1: EDID is invalid" regression after 4.11 with HP ZBook 15 G3

[Tommi Rantala]

2017-05-15 3:03 GMT+03:00 Ben Skeggs :
> On 05/15/2017 01:10 AM, Tommi Rantala wrote:
>>
>> Hi,
>
> Hey Tommi,
>
> Thanks for bisecting this.  It's rather unexpected that you should be seeing
> problems here, but, the commit makes sense for it at least.
>
> Are you able to get me new kernel logs of both before and after this patch
> with "log_buf_len=8M drm.debug=0x14
> nouveau.debug=disp=trace,i2c=trace,bios=trace" please?

Hi Ben,

Before:
https://www.dropbox.com/s/b2namqtqvzv5ppp/trace.4.10.0-tr-10409-g5c68d91?dl=1

After:
https://www.dropbox.com/s/9url8qdo15959fy/trace.4.10.0-tr-10410-gdf8dc97?dl=1

-Tommi

> Thanks,
> Ben.
>
>
>>
>> Bisected this to:
>>
>> commit df8dc97cd17269474344d73cc02739532c468d04
>> Author: Ben Skeggs 
>> Date:   Wed Mar 1 09:42:04 2017 +1000
>>
>> drm/nouveau/kms/nv50: use drm core i2c-over-aux algorithm
>>
>> I'm not entirely sure NVKM needs to support this now, but I haven't
>> removed it as of yet just in case it's needed from DEVINIT scripts
>> where DRM isn't available.
>>
>> Signed-off-by: Ben Skeggs 
>>
>>
>> dmesg after boot with drm.debug enabled:
>>
>> v4.10-10409-g5c68d91 (still works):
>> http://termbin.com/b0is
>>
>> v4.10-10410-gdf8dc97 (failure):
>> http://termbin.com/j6lq
>>
>>
>> Tommi
>>
>>
>> 2017-05-10 11:24 GMT+03:00 Tommi Rantala :
>>>
>>> Hi,
>>>
>>> The HP ZBook 15 G3 laptop builtin display (eDP-1) does not work
>>> correctly with v4.11-11413-g2868b25.
>>>
>>> When booting the laptop, the resolution seems to be limited to
>>> 1024x768, and gnome-session segfaults.
>>>
>>> Up to 4.11 the display works just fine in 1920x1080 mode.
>>>
>>> I'm seeing this in the kernel logs:
>>>
>>> nouveau :01:00.0: eDP-1: EDID is invalid:
>>>  [00] BAD  00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff 84 53 54
>>>  [00] BAD  66 69 50 55 57 66 74 49 48 ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff 00 00 ff 00 ff
>>> nouveau :01:00.0: DRM: DDC responded, but no EDID for eDP-1
>>> [drm] Cannot find any crtc or sizes - going 1024x768
>>>
>>>
>>> $ lspci | grep NVIDIA
>>> 01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro
>>> M2000M] (rev a2)
>>>
>>> Any ideas, or should I bisect?
>>>
>>> 4.11 dmesg & xrandr output:
>>> https://pastebin.com/raw/P9LGP7e1
>>>
>>> 4.11-11413-g2868b25 dmesg:
>>> https://pastebin.com/raw/QBT9mMua
>>>
>>> -Tommi

Re: nouveau "eDP-1: EDID is invalid" regression after 4.11 with HP ZBook 15 G3

[Tommi Rantala]

2017-05-15 3:03 GMT+03:00 Ben Skeggs :
> On 05/15/2017 01:10 AM, Tommi Rantala wrote:
>>
>> Hi,
>
> Hey Tommi,
>
> Thanks for bisecting this.  It's rather unexpected that you should be seeing
> problems here, but, the commit makes sense for it at least.
>
> Are you able to get me new kernel logs of both before and after this patch
> with "log_buf_len=8M drm.debug=0x14
> nouveau.debug=disp=trace,i2c=trace,bios=trace" please?

Hi Ben,

Before:
https://www.dropbox.com/s/b2namqtqvzv5ppp/trace.4.10.0-tr-10409-g5c68d91?dl=1

After:
https://www.dropbox.com/s/9url8qdo15959fy/trace.4.10.0-tr-10410-gdf8dc97?dl=1

-Tommi

> Thanks,
> Ben.
>
>
>>
>> Bisected this to:
>>
>> commit df8dc97cd17269474344d73cc02739532c468d04
>> Author: Ben Skeggs 
>> Date:   Wed Mar 1 09:42:04 2017 +1000
>>
>> drm/nouveau/kms/nv50: use drm core i2c-over-aux algorithm
>>
>> I'm not entirely sure NVKM needs to support this now, but I haven't
>> removed it as of yet just in case it's needed from DEVINIT scripts
>> where DRM isn't available.
>>
>> Signed-off-by: Ben Skeggs 
>>
>>
>> dmesg after boot with drm.debug enabled:
>>
>> v4.10-10409-g5c68d91 (still works):
>> http://termbin.com/b0is
>>
>> v4.10-10410-gdf8dc97 (failure):
>> http://termbin.com/j6lq
>>
>>
>> Tommi
>>
>>
>> 2017-05-10 11:24 GMT+03:00 Tommi Rantala :
>>>
>>> Hi,
>>>
>>> The HP ZBook 15 G3 laptop builtin display (eDP-1) does not work
>>> correctly with v4.11-11413-g2868b25.
>>>
>>> When booting the laptop, the resolution seems to be limited to
>>> 1024x768, and gnome-session segfaults.
>>>
>>> Up to 4.11 the display works just fine in 1920x1080 mode.
>>>
>>> I'm seeing this in the kernel logs:
>>>
>>> nouveau :01:00.0: eDP-1: EDID is invalid:
>>>  [00] BAD  00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff 84 53 54
>>>  [00] BAD  66 69 50 55 57 66 74 49 48 ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff 00 00 ff 00 ff
>>> nouveau :01:00.0: DRM: DDC responded, but no EDID for eDP-1
>>> [drm] Cannot find any crtc or sizes - going 1024x768
>>>
>>>
>>> $ lspci | grep NVIDIA
>>> 01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro
>>> M2000M] (rev a2)
>>>
>>> Any ideas, or should I bisect?
>>>
>>> 4.11 dmesg & xrandr output:
>>> https://pastebin.com/raw/P9LGP7e1
>>>
>>> 4.11-11413-g2868b25 dmesg:
>>> https://pastebin.com/raw/QBT9mMua
>>>
>>> -Tommi

Re: [PATCH 04/11] arm64: dts: Initial DTS files for Broadcom Stingray SOC

[Anup Patel]

On Tue, May 9, 2017 at 2:02 AM, Scott Branden
 wrote:
> One update below needed dealing with memreserve
>
>
> On 17-05-06 04:54 AM, Anup Patel wrote:
>>
>> The Broadcom Stingray SoC is a new member in Broadcom iProc
>> SoC family.
>>
>> This patch adds initial DTS files for Broadcom Stingray SoC
>> and two of its reference boards (bcm958742k and bcm958742t).
>>
>> We have lot of reference boards and large number of devices
>> in Broadcom Stingray SoC so eventually we will have quite
>> a few DTS files for Stingray. To tackle, we have added a
>> separate directory for Stingray DTS files.
>>
>> Signed-off-by: Anup Patel 
>> Signed-off-by: Scott Branden 
>> Reviewed-by: Ray Jui 
>> ---
>>  arch/arm64/boot/dts/broadcom/Makefile  |   1 +
>>  arch/arm64/boot/dts/broadcom/stingray/Makefile |   6 +
>>  .../boot/dts/broadcom/stingray/bcm958742-base.dtsi |  64 +
>>  .../boot/dts/broadcom/stingray/bcm958742k.dts  |  48 
>>  .../boot/dts/broadcom/stingray/bcm958742t.dts  |  40 +++
>>  .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 307
>> +
>>  6 files changed, 466 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/broadcom/stingray/Makefile
>>  create mode 100644
>> arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
>>  create mode 100644 arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
>>  create mode 100644 arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
>>  create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/broadcom/Makefile
>> b/arch/arm64/boot/dts/broadcom/Makefile
>> index f1caece..a7c3208 100644
>> --- a/arch/arm64/boot/dts/broadcom/Makefile
>> +++ b/arch/arm64/boot/dts/broadcom/Makefile
>> @@ -2,6 +2,7 @@ dtb-$(CONFIG_ARCH_BCM2835) += bcm2837-rpi-3-b.dtb
>>  dtb-$(CONFIG_ARCH_BCM_IPROC) += ns2-svk.dtb ns2-xmc.dtb
>>  dtb-$(CONFIG_ARCH_VULCAN) += vulcan-eval.dtb
>>
>> +dts-dirs   := stingray
>>  always := $(dtb-y)
>>  subdir-y   := $(dts-dirs)
>>  clean-files:= *.dtb
>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/Makefile
>> b/arch/arm64/boot/dts/broadcom/stingray/Makefile
>> new file mode 100644
>> index 000..f70028e
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/broadcom/stingray/Makefile
>> @@ -0,0 +1,6 @@
>> +dtb-$(CONFIG_ARCH_BCM_IPROC) += bcm958742k.dtb
>> +dtb-$(CONFIG_ARCH_BCM_IPROC) += bcm958742t.dtb
>> +
>> +always := $(dtb-y)
>> +subdir-y   := $(dts-dirs)
>> +clean-files:= *.dtb
>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
>> b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
>> new file mode 100644
>> index 000..e3a2a36
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
>> @@ -0,0 +1,64 @@
>> +/*
>> + *  BSD LICENSE
>> + *
>> + *  Copyright(c) 2016-2017 Broadcom.  All rights reserved.
>> + *
>> + *  Redistribution and use in source and binary forms, with or without
>> + *  modification, are permitted provided that the following conditions
>> + *  are met:
>> + *
>> + ** Redistributions of source code must retain the above copyright
>> + *  notice, this list of conditions and the following disclaimer.
>> + ** Redistributions in binary form must reproduce the above copyright
>> + *  notice, this list of conditions and the following disclaimer in
>> + *  the documentation and/or other materials provided with the
>> + *  distribution.
>> + ** Neither the name of Broadcom nor the names of its
>> + *  contributors may be used to endorse or promote products derived
>> + *  from this software without specific prior written permission.
>> + *
>> + *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>> + *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>> + *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
>> + *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
>> + *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
>> + *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>> + *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
>> + *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
>> + *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>> + *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
>> + *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>> + */
>> +
>> +/*
>> + * Reserve portion of RAM used by secured firmware
>> + * running in background.
>> + */
>
> This memreserve comment was changed from the internal version of the dtsi
> file.  Comment is now misleading as I don't think this memreserve is used at
> all.  EFI Loader passes in the memory configuration.  Comment needs to be
> updated 

Re: [PATCH 04/11] arm64: dts: Initial DTS files for Broadcom Stingray SOC

[Anup Patel]

On Tue, May 9, 2017 at 2:02 AM, Scott Branden
 wrote:
> One update below needed dealing with memreserve
>
>
> On 17-05-06 04:54 AM, Anup Patel wrote:
>>
>> The Broadcom Stingray SoC is a new member in Broadcom iProc
>> SoC family.
>>
>> This patch adds initial DTS files for Broadcom Stingray SoC
>> and two of its reference boards (bcm958742k and bcm958742t).
>>
>> We have lot of reference boards and large number of devices
>> in Broadcom Stingray SoC so eventually we will have quite
>> a few DTS files for Stingray. To tackle, we have added a
>> separate directory for Stingray DTS files.
>>
>> Signed-off-by: Anup Patel 
>> Signed-off-by: Scott Branden 
>> Reviewed-by: Ray Jui 
>> ---
>>  arch/arm64/boot/dts/broadcom/Makefile  |   1 +
>>  arch/arm64/boot/dts/broadcom/stingray/Makefile |   6 +
>>  .../boot/dts/broadcom/stingray/bcm958742-base.dtsi |  64 +
>>  .../boot/dts/broadcom/stingray/bcm958742k.dts  |  48 
>>  .../boot/dts/broadcom/stingray/bcm958742t.dts  |  40 +++
>>  .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 307
>> +
>>  6 files changed, 466 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/broadcom/stingray/Makefile
>>  create mode 100644
>> arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
>>  create mode 100644 arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
>>  create mode 100644 arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
>>  create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/broadcom/Makefile
>> b/arch/arm64/boot/dts/broadcom/Makefile
>> index f1caece..a7c3208 100644
>> --- a/arch/arm64/boot/dts/broadcom/Makefile
>> +++ b/arch/arm64/boot/dts/broadcom/Makefile
>> @@ -2,6 +2,7 @@ dtb-$(CONFIG_ARCH_BCM2835) += bcm2837-rpi-3-b.dtb
>>  dtb-$(CONFIG_ARCH_BCM_IPROC) += ns2-svk.dtb ns2-xmc.dtb
>>  dtb-$(CONFIG_ARCH_VULCAN) += vulcan-eval.dtb
>>
>> +dts-dirs   := stingray
>>  always := $(dtb-y)
>>  subdir-y   := $(dts-dirs)
>>  clean-files:= *.dtb
>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/Makefile
>> b/arch/arm64/boot/dts/broadcom/stingray/Makefile
>> new file mode 100644
>> index 000..f70028e
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/broadcom/stingray/Makefile
>> @@ -0,0 +1,6 @@
>> +dtb-$(CONFIG_ARCH_BCM_IPROC) += bcm958742k.dtb
>> +dtb-$(CONFIG_ARCH_BCM_IPROC) += bcm958742t.dtb
>> +
>> +always := $(dtb-y)
>> +subdir-y   := $(dts-dirs)
>> +clean-files:= *.dtb
>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
>> b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
>> new file mode 100644
>> index 000..e3a2a36
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
>> @@ -0,0 +1,64 @@
>> +/*
>> + *  BSD LICENSE
>> + *
>> + *  Copyright(c) 2016-2017 Broadcom.  All rights reserved.
>> + *
>> + *  Redistribution and use in source and binary forms, with or without
>> + *  modification, are permitted provided that the following conditions
>> + *  are met:
>> + *
>> + ** Redistributions of source code must retain the above copyright
>> + *  notice, this list of conditions and the following disclaimer.
>> + ** Redistributions in binary form must reproduce the above copyright
>> + *  notice, this list of conditions and the following disclaimer in
>> + *  the documentation and/or other materials provided with the
>> + *  distribution.
>> + ** Neither the name of Broadcom nor the names of its
>> + *  contributors may be used to endorse or promote products derived
>> + *  from this software without specific prior written permission.
>> + *
>> + *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>> + *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>> + *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
>> + *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
>> + *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
>> + *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>> + *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
>> + *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
>> + *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>> + *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
>> + *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>> + */
>> +
>> +/*
>> + * Reserve portion of RAM used by secured firmware
>> + * running in background.
>> + */
>
> This memreserve comment was changed from the internal version of the dtsi
> file.  Comment is now misleading as I don't think this memreserve is used at
> all.  EFI Loader passes in the memory configuration.  Comment needs to be
> updated to indicate this is not used by standard bootloader.  Or, simply
> remove the memreserve here.

Re: [PATCH 04/11] arm64: dts: Initial DTS files for Broadcom Stingray SOC

[Anup Patel]

On Mon, May 8, 2017 at 5:00 AM, Florian Fainelli  wrote:
> Le 05/06/17 à 04:54, Anup Patel a écrit :
>> The Broadcom Stingray SoC is a new member in Broadcom iProc
>> SoC family.
>>
>> This patch adds initial DTS files for Broadcom Stingray SoC
>> and two of its reference boards (bcm958742k and bcm958742t).
>>
>> We have lot of reference boards and large number of devices
>> in Broadcom Stingray SoC so eventually we will have quite
>> a few DTS files for Stingray. To tackle, we have added a
>> separate directory for Stingray DTS files.
>>
>> Signed-off-by: Anup Patel 
>> Signed-off-by: Scott Branden 
>> Reviewed-by: Ray Jui 
>> ---
>
>> +
>> + scr {
>> + compatible = "simple-bus";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0 0 0 0x>;
>
> Sorry for missing that during the internal review, the ranges property
> here should include the 6300_ offset such that everything else under
> the "scr" node is relative to that base address. This makes it a lot
> easier to understand the different physical addresses involved and the
> bus topology.

Sure, I will do this.

Regards,
Anup

Re: [PATCH 04/11] arm64: dts: Initial DTS files for Broadcom Stingray SOC

[Anup Patel]

On Mon, May 8, 2017 at 5:00 AM, Florian Fainelli  wrote:
> Le 05/06/17 à 04:54, Anup Patel a écrit :
>> The Broadcom Stingray SoC is a new member in Broadcom iProc
>> SoC family.
>>
>> This patch adds initial DTS files for Broadcom Stingray SoC
>> and two of its reference boards (bcm958742k and bcm958742t).
>>
>> We have lot of reference boards and large number of devices
>> in Broadcom Stingray SoC so eventually we will have quite
>> a few DTS files for Stingray. To tackle, we have added a
>> separate directory for Stingray DTS files.
>>
>> Signed-off-by: Anup Patel 
>> Signed-off-by: Scott Branden 
>> Reviewed-by: Ray Jui 
>> ---
>
>> +
>> + scr {
>> + compatible = "simple-bus";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0 0 0 0x>;
>
> Sorry for missing that during the internal review, the ranges property
> here should include the 6300_ offset such that everything else under
> the "scr" node is relative to that base address. This makes it a lot
> easier to understand the different physical addresses involved and the
> bus topology.

Sure, I will do this.

Regards,
Anup

Re: [PATCH 02/11] dt-bindings: clk: Extend binding doc for Stingray SOC

[Anup Patel]

On Fri, May 12, 2017 at 8:51 PM, Rob Herring  wrote:
> On Sat, May 06, 2017 at 05:24:37PM +0530, Anup Patel wrote:
>> From: Sandeep Tripathy 
>>
>> Update iproc clock dt-binding documentation with
>> Stingray pll and clock details.
>>
>> Signed-off-by: Sandeep Tripathy 
>> Reviewed-by: Ray Jui 
>> Reviewed-by: Scott Branden 
>> ---
>>  .../bindings/clock/brcm,iproc-clocks.txt   | 76 
>> ++
>>  1 file changed, 76 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt 
>> b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
>> index 6f66e9a..f2c5f0e4a 100644
>> --- a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
>> +++ b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
>> @@ -219,3 +219,79 @@ BCM63138
>>  
>>  PLL and leaf clock compatible strings for BCM63138 are:
>>  "brcm,bcm63138-armpll"
>> +
>> +Stingray
>> +---
>> +PLL and leaf clock compatible strings for Stingray are:
>> +"brcm,sr-genpll0"
>> +"brcm,sr-genpll1"
>> +"brcm,sr-genpll2"
>> +"brcm,sr-genpll3"
>> +"brcm,sr-genpll4"
>> +"brcm,sr-genpll5"
>> +"brcm,sr-genpll6"
>> +
>> +"brcm,sr-lcpll0"
>> +"brcm,sr-lcpll1"
>> +"brcm,sr-lcpll-pcie"
>> +
>> +
>> +The following table defines the set of PLL/clock index and ID for Stingray.
>> +These clock IDs are defined in:
>> +"include/dt-bindings/clock/bcm-sr.h"
>
> This header should be part of this commit. With that,

Sure, I will include bcm-sr.h as-part of this commit.

>
> Acked-by: Rob Herring 

Thanks,
Anup

Re: [PATCH 02/11] dt-bindings: clk: Extend binding doc for Stingray SOC

[Anup Patel]

On Fri, May 12, 2017 at 8:51 PM, Rob Herring  wrote:
> On Sat, May 06, 2017 at 05:24:37PM +0530, Anup Patel wrote:
>> From: Sandeep Tripathy 
>>
>> Update iproc clock dt-binding documentation with
>> Stingray pll and clock details.
>>
>> Signed-off-by: Sandeep Tripathy 
>> Reviewed-by: Ray Jui 
>> Reviewed-by: Scott Branden 
>> ---
>>  .../bindings/clock/brcm,iproc-clocks.txt   | 76 
>> ++
>>  1 file changed, 76 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt 
>> b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
>> index 6f66e9a..f2c5f0e4a 100644
>> --- a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
>> +++ b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
>> @@ -219,3 +219,79 @@ BCM63138
>>  
>>  PLL and leaf clock compatible strings for BCM63138 are:
>>  "brcm,bcm63138-armpll"
>> +
>> +Stingray
>> +---
>> +PLL and leaf clock compatible strings for Stingray are:
>> +"brcm,sr-genpll0"
>> +"brcm,sr-genpll1"
>> +"brcm,sr-genpll2"
>> +"brcm,sr-genpll3"
>> +"brcm,sr-genpll4"
>> +"brcm,sr-genpll5"
>> +"brcm,sr-genpll6"
>> +
>> +"brcm,sr-lcpll0"
>> +"brcm,sr-lcpll1"
>> +"brcm,sr-lcpll-pcie"
>> +
>> +
>> +The following table defines the set of PLL/clock index and ID for Stingray.
>> +These clock IDs are defined in:
>> +"include/dt-bindings/clock/bcm-sr.h"
>
> This header should be part of this commit. With that,

Sure, I will include bcm-sr.h as-part of this commit.

>
> Acked-by: Rob Herring 

Thanks,
Anup

Re: linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Xunlei,

On Mon, 15 May 2017 12:02:18 +0800 Xunlei Pang  wrote:
>
> The following patch will fix it, do you want to me to send it out separately? 
> or help merge it into
> fc7d2b44367f ("powerpc/fadump: use the correct VMCOREINFO_NOTE_SIZE for 
> phdr") directly?

Andrew normally takes these as separate patches and then merges them
before sending them on.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Xunlei,

On Mon, 15 May 2017 12:02:18 +0800 Xunlei Pang  wrote:
>
> The following patch will fix it, do you want to me to send it out separately? 
> or help merge it into
> fc7d2b44367f ("powerpc/fadump: use the correct VMCOREINFO_NOTE_SIZE for 
> phdr") directly?

Andrew normally takes these as separate patches and then merges them
before sending them on.

-- 
Cheers,
Stephen Rothwell

Re: [linux-next, bisected, 1945bc45] build brakes for PowerPC BE configuration on LPAR

[Michael Ellerman]

On Thu, 2017-05-04 at 10:41:12 UTC, Nicholas Piggin wrote:
> On Thu, 04 May 2017 14:54:19 +0530
> Abdul Haleem  wrote:
> 
> > Hi,
> > 
> > linux-next build fails on BE config with next-20170424 onwards
> > 
> > the patch https://lkml.org/lkml/2017/4/20/994  fixes a similar issue
> > with kvm guest build failure.
> > 
> > arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
> > arch/powerpc/kernel/exceptions-64s.S:395: Error: operand out of range
> > (0x8280 is not between 0x and
> > 0x)
> > make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1
> > 
> > Bisection resulted with the below bad commit.
> > 
> > commit 1945bc4549e5cb1f9aa873ec29191aa54dc851d
> > Author: Nicholas Piggin 
> > Date:   Wed Apr 19 23:05:47 2017 +1000
> > 
> > powerpc/64s: Fix POWER9 machine check handler from stop state
> > 
> > Reviewed-by: Gautham R. Shenoy 
> > Reviewed-by: Mahesh J Salgaonkar 
> > Signed-off-by: Nicholas Piggin 
> > Signed-off-by: Michael Ellerman 
> > 
> >  arch/powerpc/include/asm/reg.h   |  1 +
> >  arch/powerpc/kernel/exceptions-64s.S | 79 
> > ---
> >  arch/powerpc/kernel/idle_book3s.S| 25 +
> >  3 files changed, 70 insertions(+), 35 deletions(-)
> > 
> > the BE configuration file is attached.
> > 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/6102c005a71b4a7a6433d43b887662

cheers

Re: powerpc: fix distclean with Makefile.postlink

[Michael Ellerman]

On Mon, 2017-05-08 at 08:50:16 UTC, =?utf-8?q?Horia_Geant=C4=83?= wrote:
> Makefile.postlink always includes include/config/auto.conf, however
> this file is not present in a clean kernel tree, causing make to fail:
> 
> arch/powerpc/Makefile.postlink:10: include/config/auto.conf: No such file or 
> directory
> make[1]: *** No rule to make target `include/config/auto.conf'.  Stop.
> make: *** [vmlinuxclean] Error 2
> 
> Change the inclusion such that file not being found does not trigger
> an error.
> 
> Fixes: f188d0524d7e ("powerpc: Use the new post-link pass to check 
> relocations")
> Reported-by: Mircea Pop 
> Signed-off-by: Horia Geantă 
> Tested-by: Justin M. Forbes 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/24e0bfbf63bac18495b0ad76115269

cheers

Re: [linux-next, bisected, 1945bc45] build brakes for PowerPC BE configuration on LPAR

[Michael Ellerman]

On Thu, 2017-05-04 at 10:41:12 UTC, Nicholas Piggin wrote:
> On Thu, 04 May 2017 14:54:19 +0530
> Abdul Haleem  wrote:
> 
> > Hi,
> > 
> > linux-next build fails on BE config with next-20170424 onwards
> > 
> > the patch https://lkml.org/lkml/2017/4/20/994  fixes a similar issue
> > with kvm guest build failure.
> > 
> > arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
> > arch/powerpc/kernel/exceptions-64s.S:395: Error: operand out of range
> > (0x8280 is not between 0x and
> > 0x)
> > make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1
> > 
> > Bisection resulted with the below bad commit.
> > 
> > commit 1945bc4549e5cb1f9aa873ec29191aa54dc851d
> > Author: Nicholas Piggin 
> > Date:   Wed Apr 19 23:05:47 2017 +1000
> > 
> > powerpc/64s: Fix POWER9 machine check handler from stop state
> > 
> > Reviewed-by: Gautham R. Shenoy 
> > Reviewed-by: Mahesh J Salgaonkar 
> > Signed-off-by: Nicholas Piggin 
> > Signed-off-by: Michael Ellerman 
> > 
> >  arch/powerpc/include/asm/reg.h   |  1 +
> >  arch/powerpc/kernel/exceptions-64s.S | 79 
> > ---
> >  arch/powerpc/kernel/idle_book3s.S| 25 +
> >  3 files changed, 70 insertions(+), 35 deletions(-)
> > 
> > the BE configuration file is attached.
> > 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/6102c005a71b4a7a6433d43b887662

cheers

Re: powerpc: fix distclean with Makefile.postlink

[Michael Ellerman]

On Mon, 2017-05-08 at 08:50:16 UTC, =?utf-8?q?Horia_Geant=C4=83?= wrote:
> Makefile.postlink always includes include/config/auto.conf, however
> this file is not present in a clean kernel tree, causing make to fail:
> 
> arch/powerpc/Makefile.postlink:10: include/config/auto.conf: No such file or 
> directory
> make[1]: *** No rule to make target `include/config/auto.conf'.  Stop.
> make: *** [vmlinuxclean] Error 2
> 
> Change the inclusion such that file not being found does not trigger
> an error.
> 
> Fixes: f188d0524d7e ("powerpc: Use the new post-link pass to check 
> relocations")
> Reported-by: Mircea Pop 
> Signed-off-by: Horia Geantă 
> Tested-by: Justin M. Forbes 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/24e0bfbf63bac18495b0ad76115269

cheers

[PATCH v8 2/4] async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome()

[Anup Patel]

The DMA_PREP_FENCE is to be used when preparing Tx descriptor if output
of Tx descriptor is to be used by next/dependent Tx descriptor.

The DMA_PREP_FENSE will not be set correctly in do_async_gen_syndrome()
when calling dma->device_prep_dma_pq() under following conditions:
1. ASYNC_TX_FENCE not set in submit->flags
2. DMA_PREP_FENCE not set in dma_flags
3. src_cnt (= (disks - 2)) is greater than dma_maxpq(dma, dma_flags)

This patch fixes DMA_PREP_FENCE usage in do_async_gen_syndrome() taking
inspiration from do_async_xor() implementation.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Acked-by: Dan Williams 
---
 crypto/async_tx/async_pq.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/crypto/async_tx/async_pq.c b/crypto/async_tx/async_pq.c
index f83de99..56bd612 100644
--- a/crypto/async_tx/async_pq.c
+++ b/crypto/async_tx/async_pq.c
@@ -62,9 +62,6 @@ do_async_gen_syndrome(struct dma_chan *chan,
dma_addr_t dma_dest[2];
int src_off = 0;
 
-   if (submit->flags & ASYNC_TX_FENCE)
-   dma_flags |= DMA_PREP_FENCE;
-
while (src_cnt > 0) {
submit->flags = flags_orig;
pq_src_cnt = min(src_cnt, dma_maxpq(dma, dma_flags));
@@ -83,6 +80,8 @@ do_async_gen_syndrome(struct dma_chan *chan,
if (cb_fn_orig)
dma_flags |= DMA_PREP_INTERRUPT;
}
+   if (submit->flags & ASYNC_TX_FENCE)
+   dma_flags |= DMA_PREP_FENCE;
 
/* Drivers force forward progress in case they can not provide
 * a descriptor
-- 
2.7.4

[PATCH v8 2/4] async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome()

[Anup Patel]

The DMA_PREP_FENCE is to be used when preparing Tx descriptor if output
of Tx descriptor is to be used by next/dependent Tx descriptor.

The DMA_PREP_FENSE will not be set correctly in do_async_gen_syndrome()
when calling dma->device_prep_dma_pq() under following conditions:
1. ASYNC_TX_FENCE not set in submit->flags
2. DMA_PREP_FENCE not set in dma_flags
3. src_cnt (= (disks - 2)) is greater than dma_maxpq(dma, dma_flags)

This patch fixes DMA_PREP_FENCE usage in do_async_gen_syndrome() taking
inspiration from do_async_xor() implementation.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Acked-by: Dan Williams 
---
 crypto/async_tx/async_pq.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/crypto/async_tx/async_pq.c b/crypto/async_tx/async_pq.c
index f83de99..56bd612 100644
--- a/crypto/async_tx/async_pq.c
+++ b/crypto/async_tx/async_pq.c
@@ -62,9 +62,6 @@ do_async_gen_syndrome(struct dma_chan *chan,
dma_addr_t dma_dest[2];
int src_off = 0;
 
-   if (submit->flags & ASYNC_TX_FENCE)
-   dma_flags |= DMA_PREP_FENCE;
-
while (src_cnt > 0) {
submit->flags = flags_orig;
pq_src_cnt = min(src_cnt, dma_maxpq(dma, dma_flags));
@@ -83,6 +80,8 @@ do_async_gen_syndrome(struct dma_chan *chan,
if (cb_fn_orig)
dma_flags |= DMA_PREP_INTERRUPT;
}
+   if (submit->flags & ASYNC_TX_FENCE)
+   dma_flags |= DMA_PREP_FENCE;
 
/* Drivers force forward progress in case they can not provide
 * a descriptor
-- 
2.7.4

[PATCH v8 4/4] dt-bindings: Add DT bindings document for Broadcom SBA RAID driver

[Anup Patel]

This patch adds the DT bindings document for newly added Broadcom
SBA RAID driver.

Acked-by: Rob Herring 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Signed-off-by: Anup Patel 
---
 .../devicetree/bindings/dma/brcm,iproc-sba.txt | 29 ++
 1 file changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt

diff --git a/Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt 
b/Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt
new file mode 100644
index 000..092913a
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt
@@ -0,0 +1,29 @@
+* Broadcom SBA RAID engine
+
+Required properties:
+- compatible: Should be one of the following
+ "brcm,iproc-sba"
+ "brcm,iproc-sba-v2"
+  The "brcm,iproc-sba" has support for only 6 PQ coefficients
+  The "brcm,iproc-sba-v2" has support for only 30 PQ coefficients
+- mboxes: List of phandle and mailbox channel specifiers
+
+Example:
+
+raid_mbox: mbox@6740 {
+   ...
+   #mbox-cells = <3>;
+   ...
+};
+
+raid0 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <_mbox 0 0x1 0x>,
+<_mbox 1 0x1 0x>,
+<_mbox 2 0x1 0x>,
+<_mbox 3 0x1 0x>,
+<_mbox 4 0x1 0x>,
+<_mbox 5 0x1 0x>,
+<_mbox 6 0x1 0x>,
+<_mbox 7 0x1 0x>;
+};
-- 
2.7.4

[PATCH v8 4/4] dt-bindings: Add DT bindings document for Broadcom SBA RAID driver

[Anup Patel]

This patch adds the DT bindings document for newly added Broadcom
SBA RAID driver.

Acked-by: Rob Herring 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Signed-off-by: Anup Patel 
---
 .../devicetree/bindings/dma/brcm,iproc-sba.txt | 29 ++
 1 file changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt

diff --git a/Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt 
b/Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt
new file mode 100644
index 000..092913a
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt
@@ -0,0 +1,29 @@
+* Broadcom SBA RAID engine
+
+Required properties:
+- compatible: Should be one of the following
+ "brcm,iproc-sba"
+ "brcm,iproc-sba-v2"
+  The "brcm,iproc-sba" has support for only 6 PQ coefficients
+  The "brcm,iproc-sba-v2" has support for only 30 PQ coefficients
+- mboxes: List of phandle and mailbox channel specifiers
+
+Example:
+
+raid_mbox: mbox@6740 {
+   ...
+   #mbox-cells = <3>;
+   ...
+};
+
+raid0 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <_mbox 0 0x1 0x>,
+<_mbox 1 0x1 0x>,
+<_mbox 2 0x1 0x>,
+<_mbox 3 0x1 0x>,
+<_mbox 4 0x1 0x>,
+<_mbox 5 0x1 0x>,
+<_mbox 6 0x1 0x>,
+<_mbox 7 0x1 0x>;
+};
-- 
2.7.4

[PATCH v8 3/4] dmaengine: Add Broadcom SBA RAID driver

[Anup Patel]

The Broadcom stream buffer accelerator (SBA) provides offloading
capabilities for RAID operations. This SBA offload engine is
accessible via Broadcom SoC specific ring manager.

This patch adds Broadcom SBA RAID driver which provides one
DMA device with RAID capabilities using one or more Broadcom
SoC specific ring manager channels. The SBA RAID driver in its
current shape implements memcpy, xor, and pq operations.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Acked-by: Dan Williams 
---
 drivers/dma/Kconfig|   14 +
 drivers/dma/Makefile   |1 +
 drivers/dma/bcm-sba-raid.c | 1785 
 3 files changed, 1800 insertions(+)
 create mode 100644 drivers/dma/bcm-sba-raid.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 24e8597..b7e0ab9 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -99,6 +99,20 @@ config AXI_DMAC
  controller is often used in Analog Device's reference designs for FPGA
  platforms.
 
+config BCM_SBA_RAID
+   tristate "Broadcom SBA RAID engine support"
+   depends on (ARM64 && MAILBOX && RAID6_PQ) || COMPILE_TEST
+   select DMA_ENGINE
+   select DMA_ENGINE_RAID
+   select ASYNC_TX_DISABLE_XOR_VAL_DMA
+   select ASYNC_TX_DISABLE_PQ_VAL_DMA
+   default ARCH_BCM_IPROC
+   help
+ Enable support for Broadcom SBA RAID Engine. The SBA RAID
+ engine is available on most of the Broadcom iProc SoCs. It
+ has the capability to offload memcpy, xor and pq computation
+ for raid5/6.
+
 config COH901318
bool "ST-Ericsson COH901318 DMA support"
select DMA_ENGINE
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 0b723e9..d12ab29 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_AMCC_PPC440SPE_ADMA) += ppc4xx/
 obj-$(CONFIG_AT_HDMAC) += at_hdmac.o
 obj-$(CONFIG_AT_XDMAC) += at_xdmac.o
 obj-$(CONFIG_AXI_DMAC) += dma-axi-dmac.o
+obj-$(CONFIG_BCM_SBA_RAID) += bcm-sba-raid.o
 obj-$(CONFIG_COH901318) += coh901318.o coh901318_lli.o
 obj-$(CONFIG_DMA_BCM2835) += bcm2835-dma.o
 obj-$(CONFIG_DMA_JZ4740) += dma-jz4740.o
diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
new file mode 100644
index 000..d6b927b
--- /dev/null
+++ b/drivers/dma/bcm-sba-raid.c
@@ -0,0 +1,1785 @@
+/*
+ * Copyright (C) 2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Broadcom SBA RAID Driver
+ *
+ * The Broadcom stream buffer accelerator (SBA) provides offloading
+ * capabilities for RAID operations. The SBA offload engine is accessible
+ * via Broadcom SoC specific ring manager. Two or more offload engines
+ * can share same Broadcom SoC specific ring manager due to this Broadcom
+ * SoC specific ring manager driver is implemented as a mailbox controller
+ * driver and offload engine drivers are implemented as mallbox clients.
+ *
+ * Typically, Broadcom SoC specific ring manager will implement larger
+ * number of hardware rings over one or more SBA hardware devices. By
+ * design, the internal buffer size of SBA hardware device is limited
+ * but all offload operations supported by SBA can be broken down into
+ * multiple small size requests and executed parallely on multiple SBA
+ * hardware devices for achieving high through-put.
+ *
+ * The Broadcom SBA RAID driver does not require any register programming
+ * except submitting request to SBA hardware device via mailbox channels.
+ * This driver implements a DMA device with one DMA channel using a set
+ * of mailbox channels provided by Broadcom SoC specific ring manager
+ * driver. To exploit parallelism (as described above), all DMA request
+ * coming to SBA RAID DMA channel are broken down to smaller requests
+ * and submitted to multiple mailbox channels in round-robin fashion.
+ * For having more SBA DMA channels, we can create more SBA device nodes
+ * in Broadcom SoC specific DTS based on number of hardware rings supported
+ * by Broadcom SoC ring manager.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "dmaengine.h"
+
+/* SBA command related defines */
+#define SBA_TYPE_SHIFT 48
+#define SBA_TYPE_MASK  GENMASK(1, 0)
+#define SBA_TYPE_A 0x0
+#define SBA_TYPE_B 0x2
+#define SBA_TYPE_C 0x3
+#define SBA_USER_DEF_SHIFT 32
+#define SBA_USER_DEF_MASK  GENMASK(15, 0)
+#define SBA_R_MDATA_SHIFT  24
+#define SBA_R_MDATA_MASK   

[PATCH v8 3/4] dmaengine: Add Broadcom SBA RAID driver

[Anup Patel]

The Broadcom stream buffer accelerator (SBA) provides offloading
capabilities for RAID operations. This SBA offload engine is
accessible via Broadcom SoC specific ring manager.

This patch adds Broadcom SBA RAID driver which provides one
DMA device with RAID capabilities using one or more Broadcom
SoC specific ring manager channels. The SBA RAID driver in its
current shape implements memcpy, xor, and pq operations.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Acked-by: Dan Williams 
---
 drivers/dma/Kconfig|   14 +
 drivers/dma/Makefile   |1 +
 drivers/dma/bcm-sba-raid.c | 1785 
 3 files changed, 1800 insertions(+)
 create mode 100644 drivers/dma/bcm-sba-raid.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 24e8597..b7e0ab9 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -99,6 +99,20 @@ config AXI_DMAC
  controller is often used in Analog Device's reference designs for FPGA
  platforms.
 
+config BCM_SBA_RAID
+   tristate "Broadcom SBA RAID engine support"
+   depends on (ARM64 && MAILBOX && RAID6_PQ) || COMPILE_TEST
+   select DMA_ENGINE
+   select DMA_ENGINE_RAID
+   select ASYNC_TX_DISABLE_XOR_VAL_DMA
+   select ASYNC_TX_DISABLE_PQ_VAL_DMA
+   default ARCH_BCM_IPROC
+   help
+ Enable support for Broadcom SBA RAID Engine. The SBA RAID
+ engine is available on most of the Broadcom iProc SoCs. It
+ has the capability to offload memcpy, xor and pq computation
+ for raid5/6.
+
 config COH901318
bool "ST-Ericsson COH901318 DMA support"
select DMA_ENGINE
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 0b723e9..d12ab29 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_AMCC_PPC440SPE_ADMA) += ppc4xx/
 obj-$(CONFIG_AT_HDMAC) += at_hdmac.o
 obj-$(CONFIG_AT_XDMAC) += at_xdmac.o
 obj-$(CONFIG_AXI_DMAC) += dma-axi-dmac.o
+obj-$(CONFIG_BCM_SBA_RAID) += bcm-sba-raid.o
 obj-$(CONFIG_COH901318) += coh901318.o coh901318_lli.o
 obj-$(CONFIG_DMA_BCM2835) += bcm2835-dma.o
 obj-$(CONFIG_DMA_JZ4740) += dma-jz4740.o
diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
new file mode 100644
index 000..d6b927b
--- /dev/null
+++ b/drivers/dma/bcm-sba-raid.c
@@ -0,0 +1,1785 @@
+/*
+ * Copyright (C) 2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Broadcom SBA RAID Driver
+ *
+ * The Broadcom stream buffer accelerator (SBA) provides offloading
+ * capabilities for RAID operations. The SBA offload engine is accessible
+ * via Broadcom SoC specific ring manager. Two or more offload engines
+ * can share same Broadcom SoC specific ring manager due to this Broadcom
+ * SoC specific ring manager driver is implemented as a mailbox controller
+ * driver and offload engine drivers are implemented as mallbox clients.
+ *
+ * Typically, Broadcom SoC specific ring manager will implement larger
+ * number of hardware rings over one or more SBA hardware devices. By
+ * design, the internal buffer size of SBA hardware device is limited
+ * but all offload operations supported by SBA can be broken down into
+ * multiple small size requests and executed parallely on multiple SBA
+ * hardware devices for achieving high through-put.
+ *
+ * The Broadcom SBA RAID driver does not require any register programming
+ * except submitting request to SBA hardware device via mailbox channels.
+ * This driver implements a DMA device with one DMA channel using a set
+ * of mailbox channels provided by Broadcom SoC specific ring manager
+ * driver. To exploit parallelism (as described above), all DMA request
+ * coming to SBA RAID DMA channel are broken down to smaller requests
+ * and submitted to multiple mailbox channels in round-robin fashion.
+ * For having more SBA DMA channels, we can create more SBA device nodes
+ * in Broadcom SoC specific DTS based on number of hardware rings supported
+ * by Broadcom SoC ring manager.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "dmaengine.h"
+
+/* SBA command related defines */
+#define SBA_TYPE_SHIFT 48
+#define SBA_TYPE_MASK  GENMASK(1, 0)
+#define SBA_TYPE_A 0x0
+#define SBA_TYPE_B 0x2
+#define SBA_TYPE_C 0x3
+#define SBA_USER_DEF_SHIFT 32
+#define SBA_USER_DEF_MASK  GENMASK(15, 0)
+#define SBA_R_MDATA_SHIFT  24
+#define SBA_R_MDATA_MASK   GENMASK(7, 0)
+#define SBA_C_MDATA_MS_SHIFT   18
+#define 

[PATCH v8 0/4] Broadcom SBA RAID support

[Anup Patel]

The Broadcom SBA RAID is a stream-based device which provides
RAID5/6 offload.

It requires a SoC specific ring manager (such as Broadcom FlexRM
ring manager) to provide ring-based programming interface. Due to
this, the Broadcom SBA RAID driver (mailbox client) implements
DMA device having one DMA channel using a set of mailbox channels
provided by Broadcom SoC specific ring manager driver (mailbox
controller).

The Broadcom SBA RAID hardware requires PQ disk position instead
of PQ disk coefficient. To address this, we have added raid_gflog
table which will help driver to convert PQ disk coefficient to PQ
disk position.

This patchset is based on Linux-4.12-rc1 and is available at
sba-raid-v8 branch of
https://github.com/Broadcom/arm64-linux.git

Changes since v7:
 - Rebased patches for Linux-4.12-rc1 because Broadcom FlexRM
   ring manager support is available in Linux-4.12

Changes since v6:
 - Rebased patches for Linux-4.11-rc4 and v7 of Broadcom FlexRM
   ring manager support

Changes since v5:
 - Rebased patches for Linux-4.11-rc1

Changes since v4:
 - Removed dependency of bcm-sba-raid driver on kconfig opton
   ASYNC_TX_ENABLE_CHANNEL_SWITCH
 - Select kconfig options ASYNC_TX_DISABLE_XOR_VAL_DMA and
   ASYNC_TX_DISABLE_PQ_VAL_DMA for bcm-sba-raid driver
 - Implemented device_prep_dma_interrupt() using dummy 8-byte
   copy operation so that the dma_async_device_register() can
   set DMA_ASYNC_TX capability for the DMA device provided
   by bcm-sba-raid driver

Changes since v3:
 - Replaced SBA_ENC() with sba_cmd_enc() inline function
 - Use list_first_entry_or_null() wherever possible
 - Remove unwanted brances around loops wherever possible
 - Use lockdep_assert_held() where required

Changes since v2:
 - Droped patch to handle DMA devices having support for fewer
   PQ coefficients in Linux Async Tx
 - Added work-around in bcm-sba-raid driver to handle unsupported
   PQ coefficients using multiple SBA requests

Changes since v1:
 - Droped patch to add mbox_channel_device() API
 - Used GENMASK and BIT macros wherever possible in bcm-sba-raid driver
 - Replaced C_MDATA macros with static inline functions in
   bcm-sba-raid driver
 - Removed sba_alloc_chan_resources() callback in bcm-sba-raid driver
 - Used dev_err() instead of dev_info() wherever applicable
 - Removed call to sba_issue_pending() from sba_tx_submit() in
   bcm-sba-raid driver
 - Implemented SBA request chaning for handling (len > sba->req_size)
   in bcm-sba-raid driver
 - Implemented device_terminate_all() callback in bcm-sba-raid driver

Anup Patel (4):
  lib/raid6: Add log-of-2 table for RAID6 HW requiring disk position
  async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome()
  dmaengine: Add Broadcom SBA RAID driver
  dt-bindings: Add DT bindings document for Broadcom SBA RAID driver

 .../devicetree/bindings/dma/brcm,iproc-sba.txt |   29 +
 crypto/async_tx/async_pq.c |5 +-
 drivers/dma/Kconfig|   14 +
 drivers/dma/Makefile   |1 +
 drivers/dma/bcm-sba-raid.c | 1785 
 include/linux/raid/pq.h|1 +
 lib/raid6/mktables.c   |   20 +
 7 files changed, 1852 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt
 create mode 100644 drivers/dma/bcm-sba-raid.c

-- 
2.7.4

[PATCH v8 1/4] lib/raid6: Add log-of-2 table for RAID6 HW requiring disk position

[Anup Patel]

The raid6_gfexp table represents {2}^n values for 0 <= n < 256. The
Linux async_tx framework pass values from raid6_gfexp as coefficients
for each source to prep_dma_pq() callback of DMA channel with PQ
capability. This creates problem for RAID6 offload engines (such as
Broadcom SBA) which take disk position (i.e. log of {2}) instead of
multiplicative cofficients from raid6_gfexp table.

This patch adds raid6_gflog table having log-of-2 value for any given
x such that 0 <= x < 256. For any given disk coefficient x, the
corresponding disk position is given by raid6_gflog[x]. The RAID6
offload engine driver can use this newly added raid6_gflog table to
get disk position from multiplicative coefficient.

Signed-off-by: Anup Patel 
Reviewed-by: Scott Branden 
Reviewed-by: Ray Jui 
Acked-by: Shaohua Li 
---
 include/linux/raid/pq.h |  1 +
 lib/raid6/mktables.c| 20 
 2 files changed, 21 insertions(+)

diff --git a/include/linux/raid/pq.h b/include/linux/raid/pq.h
index 4d57bba..30f9453 100644
--- a/include/linux/raid/pq.h
+++ b/include/linux/raid/pq.h
@@ -142,6 +142,7 @@ int raid6_select_algo(void);
 extern const u8 raid6_gfmul[256][256] __attribute__((aligned(256)));
 extern const u8 raid6_vgfmul[256][32] __attribute__((aligned(256)));
 extern const u8 raid6_gfexp[256]  __attribute__((aligned(256)));
+extern const u8 raid6_gflog[256]  __attribute__((aligned(256)));
 extern const u8 raid6_gfinv[256]  __attribute__((aligned(256)));
 extern const u8 raid6_gfexi[256]  __attribute__((aligned(256)));
 
diff --git a/lib/raid6/mktables.c b/lib/raid6/mktables.c
index 39787db..e824d08 100644
--- a/lib/raid6/mktables.c
+++ b/lib/raid6/mktables.c
@@ -125,6 +125,26 @@ int main(int argc, char *argv[])
printf("EXPORT_SYMBOL(raid6_gfexp);\n");
printf("#endif\n");
 
+   /* Compute log-of-2 table */
+   printf("\nconst u8 __attribute__((aligned(256)))\n"
+  "raid6_gflog[256] =\n" "{\n");
+   for (i = 0; i < 256; i += 8) {
+   printf("\t");
+   for (j = 0; j < 8; j++) {
+   v = 255;
+   for (k = 0; k < 256; k++)
+   if (exptbl[k] == (i + j)) {
+   v = k;
+   break;
+   }
+   printf("0x%02x,%c", v, (j == 7) ? '\n' : ' ');
+   }
+   }
+   printf("};\n");
+   printf("#ifdef __KERNEL__\n");
+   printf("EXPORT_SYMBOL(raid6_gflog);\n");
+   printf("#endif\n");
+
/* Compute inverse table x^-1 == x^254 */
printf("\nconst u8 __attribute__((aligned(256)))\n"
   "raid6_gfinv[256] =\n" "{\n");
-- 
2.7.4

[PATCH v8 0/4] Broadcom SBA RAID support

[Anup Patel]

The Broadcom SBA RAID is a stream-based device which provides
RAID5/6 offload.

It requires a SoC specific ring manager (such as Broadcom FlexRM
ring manager) to provide ring-based programming interface. Due to
this, the Broadcom SBA RAID driver (mailbox client) implements
DMA device having one DMA channel using a set of mailbox channels
provided by Broadcom SoC specific ring manager driver (mailbox
controller).

The Broadcom SBA RAID hardware requires PQ disk position instead
of PQ disk coefficient. To address this, we have added raid_gflog
table which will help driver to convert PQ disk coefficient to PQ
disk position.

This patchset is based on Linux-4.12-rc1 and is available at
sba-raid-v8 branch of
https://github.com/Broadcom/arm64-linux.git

Changes since v7:
 - Rebased patches for Linux-4.12-rc1 because Broadcom FlexRM
   ring manager support is available in Linux-4.12

Changes since v6:
 - Rebased patches for Linux-4.11-rc4 and v7 of Broadcom FlexRM
   ring manager support

Changes since v5:
 - Rebased patches for Linux-4.11-rc1

Changes since v4:
 - Removed dependency of bcm-sba-raid driver on kconfig opton
   ASYNC_TX_ENABLE_CHANNEL_SWITCH
 - Select kconfig options ASYNC_TX_DISABLE_XOR_VAL_DMA and
   ASYNC_TX_DISABLE_PQ_VAL_DMA for bcm-sba-raid driver
 - Implemented device_prep_dma_interrupt() using dummy 8-byte
   copy operation so that the dma_async_device_register() can
   set DMA_ASYNC_TX capability for the DMA device provided
   by bcm-sba-raid driver

Changes since v3:
 - Replaced SBA_ENC() with sba_cmd_enc() inline function
 - Use list_first_entry_or_null() wherever possible
 - Remove unwanted brances around loops wherever possible
 - Use lockdep_assert_held() where required

Changes since v2:
 - Droped patch to handle DMA devices having support for fewer
   PQ coefficients in Linux Async Tx
 - Added work-around in bcm-sba-raid driver to handle unsupported
   PQ coefficients using multiple SBA requests

Changes since v1:
 - Droped patch to add mbox_channel_device() API
 - Used GENMASK and BIT macros wherever possible in bcm-sba-raid driver
 - Replaced C_MDATA macros with static inline functions in
   bcm-sba-raid driver
 - Removed sba_alloc_chan_resources() callback in bcm-sba-raid driver
 - Used dev_err() instead of dev_info() wherever applicable
 - Removed call to sba_issue_pending() from sba_tx_submit() in
   bcm-sba-raid driver
 - Implemented SBA request chaning for handling (len > sba->req_size)
   in bcm-sba-raid driver
 - Implemented device_terminate_all() callback in bcm-sba-raid driver

Anup Patel (4):
  lib/raid6: Add log-of-2 table for RAID6 HW requiring disk position
  async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome()
  dmaengine: Add Broadcom SBA RAID driver
  dt-bindings: Add DT bindings document for Broadcom SBA RAID driver

 .../devicetree/bindings/dma/brcm,iproc-sba.txt |   29 +
 crypto/async_tx/async_pq.c |5 +-
 drivers/dma/Kconfig|   14 +
 drivers/dma/Makefile   |1 +
 drivers/dma/bcm-sba-raid.c | 1785 
 include/linux/raid/pq.h|1 +
 lib/raid6/mktables.c   |   20 +
 7 files changed, 1852 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt
 create mode 100644 drivers/dma/bcm-sba-raid.c

-- 
2.7.4

[PATCH v8 1/4] lib/raid6: Add log-of-2 table for RAID6 HW requiring disk position

[Anup Patel]

The raid6_gfexp table represents {2}^n values for 0 <= n < 256. The
Linux async_tx framework pass values from raid6_gfexp as coefficients
for each source to prep_dma_pq() callback of DMA channel with PQ
capability. This creates problem for RAID6 offload engines (such as
Broadcom SBA) which take disk position (i.e. log of {2}) instead of
multiplicative cofficients from raid6_gfexp table.

This patch adds raid6_gflog table having log-of-2 value for any given
x such that 0 <= x < 256. For any given disk coefficient x, the
corresponding disk position is given by raid6_gflog[x]. The RAID6
offload engine driver can use this newly added raid6_gflog table to
get disk position from multiplicative coefficient.

Signed-off-by: Anup Patel 
Reviewed-by: Scott Branden 
Reviewed-by: Ray Jui 
Acked-by: Shaohua Li 
---
 include/linux/raid/pq.h |  1 +
 lib/raid6/mktables.c| 20 
 2 files changed, 21 insertions(+)

diff --git a/include/linux/raid/pq.h b/include/linux/raid/pq.h
index 4d57bba..30f9453 100644
--- a/include/linux/raid/pq.h
+++ b/include/linux/raid/pq.h
@@ -142,6 +142,7 @@ int raid6_select_algo(void);
 extern const u8 raid6_gfmul[256][256] __attribute__((aligned(256)));
 extern const u8 raid6_vgfmul[256][32] __attribute__((aligned(256)));
 extern const u8 raid6_gfexp[256]  __attribute__((aligned(256)));
+extern const u8 raid6_gflog[256]  __attribute__((aligned(256)));
 extern const u8 raid6_gfinv[256]  __attribute__((aligned(256)));
 extern const u8 raid6_gfexi[256]  __attribute__((aligned(256)));
 
diff --git a/lib/raid6/mktables.c b/lib/raid6/mktables.c
index 39787db..e824d08 100644
--- a/lib/raid6/mktables.c
+++ b/lib/raid6/mktables.c
@@ -125,6 +125,26 @@ int main(int argc, char *argv[])
printf("EXPORT_SYMBOL(raid6_gfexp);\n");
printf("#endif\n");
 
+   /* Compute log-of-2 table */
+   printf("\nconst u8 __attribute__((aligned(256)))\n"
+  "raid6_gflog[256] =\n" "{\n");
+   for (i = 0; i < 256; i += 8) {
+   printf("\t");
+   for (j = 0; j < 8; j++) {
+   v = 255;
+   for (k = 0; k < 256; k++)
+   if (exptbl[k] == (i + j)) {
+   v = k;
+   break;
+   }
+   printf("0x%02x,%c", v, (j == 7) ? '\n' : ' ');
+   }
+   }
+   printf("};\n");
+   printf("#ifdef __KERNEL__\n");
+   printf("EXPORT_SYMBOL(raid6_gflog);\n");
+   printf("#endif\n");
+
/* Compute inverse table x^-1 == x^254 */
printf("\nconst u8 __attribute__((aligned(256)))\n"
   "raid6_gfinv[256] =\n" "{\n");
-- 
2.7.4

RE: [PATCH 1/2] Revert "ACPI / button: Remove lid_init_state=method mode"

[Zheng, Lv]

Hi, Benjamin

Let's stop endless discussing and focus on our needs.

I just copied my questions here.
You can ask them directly.
For the below inlined replies, I'll stop replying if they are based on 
dependent on our basic agreements.
And I'll reply if something is really bad from my point of view.

My point of view is:
There is a gap between (BIOS ensured/Windows expected) acpi control method lid 
device behavior and Linux user space expected acpi control method lid device 
behavior.
Button driver default behavior should be: button.lid_init_state=ignore
If user space programs have special needs, they can fix problems on their own, 
via the following mean:
 echo -n "open" > /sys/modules/button/parameters/lid_init_state
 echo -n "close" > /sys/modules/button/parameters/lid_init_state
Keeping open/close modes is because I don't think there is any bug in button 
driver.
So I need to prepare quirk modes from button driver's point of view and use 
them as a response to related bug reports reported in acpi community.
Your point of view is:
There is a gap between (BIOS ensured/Windows expected) acpi control method lid 
device behavior and Linux user space expected acpi control method lid device 
behavior.
Button driver default behavior should be (not 100% sure if this is your 
opinion): button.lid_init_state=method
If user space programs have special needs, they can fix them on their own, via 
the following mean:
 libinput:name:*Lid Switch*:dmi:*svnMicrosoftCorporation:pnSurface3:*
  LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=write_open
From this point of view, we actually don't need open/close modes.

It seems we just need to determine the following first:
1. Who should be responsible for solving bugs triggered by the conflict between 
bios and linux user space expectations:
   button driver? libinput? Some other user space programs? Users?
2. What should be the default button driver behavior?
   button.lid_init_state=ignore? button.lid_init_state=method?
3. If non button driver quirks are working, button driver quirk modes are 
useless.
   The question is: Should button.lid_init_state=open/close be kept?
4. From button driver's point of view, button.lid_init_state=ignore seems to be 
always correct, so we won't abandon it.
   If we can use libinput to manage platform quirks, then 
button.lid_init_state=method also looks useless.
   The question is: Should button.lid_init_state=method be kept?

I should also let you know my preference:
1. using button.lid_init_state=ignore and button.lid_init_state=method as 
default behavior is ok for me if answer to 1 is not button driver, otherwise 
using button.lid_init_state=method is not ok for me
2. deletion of button.lid_init_state=open/close is ok for me if answer to 1 is 
not button driver, otherwise deletion of button.lid_init_state=open/close is 
not ok for me
3. deletion of button.lid_init_state=method is always ok for me

See the base line from my side is very clear:
If acpi community need to handle such bug reports, button.lid_init_state=method 
cannot be the default behavior.
We are just using a different default behavior than "method" to drive things to 
reach the final root caused solution.

Could you let me know your preference so that we can figure out an agreement 
between us.
Though I don't know if end users will buy it (they may keep on filing 
regression reports in ACPI community).

> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: Re: [PATCH 1/2] Revert "ACPI / button: Remove lid_init_state=method 
> mode"

> ...
Skip as it looks the result of debating here can also be concluded from the 
answers of the questions.
Let's just stop arguing same thing again and again using different contexts.

> > > make reasonable assumptions based on the exact
> > > model capabilities (is the power button accessible with the LID closed),
> >
> > Sounds it's always accessible.
> 
> hmm, I am not sure we have the same fingers For me on all the
> laptops I have seen, if the LID is actually (physically) closed, I can
> not press the button. It's a design choice to not have anything powering
> on the laptop when it's in your bag.

Wow...
I can see that recent laptops are having their power buttons on the edge, not 
on the keypad.
For recent laptop/tablet 2-in-1 PCs or touch laptops which can have their 
keyboards folded and act notebooks, the power buttons are obviously not on the 
detachable keypads.
Also for the laptops supporting external monitors, obviously allow users to 
push power buttons while the lid is closed.

> ...
Skip as it looks the result of debating here can also be concluded from the 
answers of the questions.


> > > The issue we are fixing here is the fact that the switch state is wrong,
> > > which makes user space assumptions wrong too (and users angry).
> >
> > Considering no platform quirks.
> >
> > If ACPI button driver sends SW_LID, users are likely angry.
> > Unless the user space programs are changed to "ignore open 

RE: [PATCH 1/2] Revert "ACPI / button: Remove lid_init_state=method mode"

[Zheng, Lv]

Hi, Benjamin

Let's stop endless discussing and focus on our needs.

I just copied my questions here.
You can ask them directly.
For the below inlined replies, I'll stop replying if they are based on 
dependent on our basic agreements.
And I'll reply if something is really bad from my point of view.

My point of view is:
There is a gap between (BIOS ensured/Windows expected) acpi control method lid 
device behavior and Linux user space expected acpi control method lid device 
behavior.
Button driver default behavior should be: button.lid_init_state=ignore
If user space programs have special needs, they can fix problems on their own, 
via the following mean:
 echo -n "open" > /sys/modules/button/parameters/lid_init_state
 echo -n "close" > /sys/modules/button/parameters/lid_init_state
Keeping open/close modes is because I don't think there is any bug in button 
driver.
So I need to prepare quirk modes from button driver's point of view and use 
them as a response to related bug reports reported in acpi community.
Your point of view is:
There is a gap between (BIOS ensured/Windows expected) acpi control method lid 
device behavior and Linux user space expected acpi control method lid device 
behavior.
Button driver default behavior should be (not 100% sure if this is your 
opinion): button.lid_init_state=method
If user space programs have special needs, they can fix them on their own, via 
the following mean:
 libinput:name:*Lid Switch*:dmi:*svnMicrosoftCorporation:pnSurface3:*
  LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=write_open
From this point of view, we actually don't need open/close modes.

It seems we just need to determine the following first:
1. Who should be responsible for solving bugs triggered by the conflict between 
bios and linux user space expectations:
   button driver? libinput? Some other user space programs? Users?
2. What should be the default button driver behavior?
   button.lid_init_state=ignore? button.lid_init_state=method?
3. If non button driver quirks are working, button driver quirk modes are 
useless.
   The question is: Should button.lid_init_state=open/close be kept?
4. From button driver's point of view, button.lid_init_state=ignore seems to be 
always correct, so we won't abandon it.
   If we can use libinput to manage platform quirks, then 
button.lid_init_state=method also looks useless.
   The question is: Should button.lid_init_state=method be kept?

I should also let you know my preference:
1. using button.lid_init_state=ignore and button.lid_init_state=method as 
default behavior is ok for me if answer to 1 is not button driver, otherwise 
using button.lid_init_state=method is not ok for me
2. deletion of button.lid_init_state=open/close is ok for me if answer to 1 is 
not button driver, otherwise deletion of button.lid_init_state=open/close is 
not ok for me
3. deletion of button.lid_init_state=method is always ok for me

See the base line from my side is very clear:
If acpi community need to handle such bug reports, button.lid_init_state=method 
cannot be the default behavior.
We are just using a different default behavior than "method" to drive things to 
reach the final root caused solution.

Could you let me know your preference so that we can figure out an agreement 
between us.
Though I don't know if end users will buy it (they may keep on filing 
regression reports in ACPI community).

> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: Re: [PATCH 1/2] Revert "ACPI / button: Remove lid_init_state=method 
> mode"

> ...
Skip as it looks the result of debating here can also be concluded from the 
answers of the questions.
Let's just stop arguing same thing again and again using different contexts.

> > > make reasonable assumptions based on the exact
> > > model capabilities (is the power button accessible with the LID closed),
> >
> > Sounds it's always accessible.
> 
> hmm, I am not sure we have the same fingers For me on all the
> laptops I have seen, if the LID is actually (physically) closed, I can
> not press the button. It's a design choice to not have anything powering
> on the laptop when it's in your bag.

Wow...
I can see that recent laptops are having their power buttons on the edge, not 
on the keypad.
For recent laptop/tablet 2-in-1 PCs or touch laptops which can have their 
keyboards folded and act notebooks, the power buttons are obviously not on the 
detachable keypads.
Also for the laptops supporting external monitors, obviously allow users to 
push power buttons while the lid is closed.

> ...
Skip as it looks the result of debating here can also be concluded from the 
answers of the questions.


> > > The issue we are fixing here is the fact that the switch state is wrong,
> > > which makes user space assumptions wrong too (and users angry).
> >
> > Considering no platform quirks.
> >
> > If ACPI button driver sends SW_LID, users are likely angry.
> > Unless the user space programs are changed to "ignore open 

Re: [PATCH] i2c: mux: only print failure message on error

[Leon Romanovsky]

On Sun, May 14, 2017 at 06:41:13PM +0200, Peter Rosin wrote:
> As is, a failure message is printed unconditionally, which is confusing.
> And noisy.
>
> Fixes: 8d4d159f25a7 ("i2c: mux: provide more info on failure in 
> i2c_mux_add_adapter")
> Signed-off-by: Peter Rosin 
> ---
>  drivers/i2c/i2c-mux.c | 24 ++--
>  1 file changed, 14 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
> index 26f7237558ba..ccf2ce1836c8 100644
> --- a/drivers/i2c/i2c-mux.c
> +++ b/drivers/i2c/i2c-mux.c
> @@ -395,18 +395,22 @@ int i2c_mux_add_adapter(struct i2c_mux_core *muxc,
>   if (force_nr) {
>   priv->adap.nr = force_nr;
>   ret = i2c_add_numbered_adapter(>adap);
> - dev_err(>dev,
> - "failed to add mux-adapter %u as bus %u (error=%d)\n",
> - chan_id, force_nr, ret);
> + if (ret < 0) {
> + dev_err(>dev,
> + "failed to add mux-adapter %u as bus %u 
> (error=%d)\n",
> + chan_id, force_nr, ret);
> + kfree(priv);
> + return ret;
> + }
>   } else {
>   ret = i2c_add_adapter(>adap);
> - dev_err(>dev,
> - "failed to add mux-adapter %u (error=%d)\n",
> - chan_id, ret);
> - }
> - if (ret < 0) {
> - kfree(priv);
> - return ret;
> + if (ret < 0) {
> + dev_err(>dev,
> + "failed to add mux-adapter %u (error=%d)\n",
> + chan_id, ret);
> + kfree(priv);
> + return ret;

It is better to add goto label, this will give one place for kfree->return code.

Thanks

> + }
>   }
>
>   WARN(sysfs_create_link(>adap.dev.kobj, >dev->kobj,
> --
> 2.1.4
>


signature.asc
Description: PGP signature

Re: [PATCH] i2c: mux: only print failure message on error

[Leon Romanovsky]

On Sun, May 14, 2017 at 06:41:13PM +0200, Peter Rosin wrote:
> As is, a failure message is printed unconditionally, which is confusing.
> And noisy.
>
> Fixes: 8d4d159f25a7 ("i2c: mux: provide more info on failure in 
> i2c_mux_add_adapter")
> Signed-off-by: Peter Rosin 
> ---
>  drivers/i2c/i2c-mux.c | 24 ++--
>  1 file changed, 14 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
> index 26f7237558ba..ccf2ce1836c8 100644
> --- a/drivers/i2c/i2c-mux.c
> +++ b/drivers/i2c/i2c-mux.c
> @@ -395,18 +395,22 @@ int i2c_mux_add_adapter(struct i2c_mux_core *muxc,
>   if (force_nr) {
>   priv->adap.nr = force_nr;
>   ret = i2c_add_numbered_adapter(>adap);
> - dev_err(>dev,
> - "failed to add mux-adapter %u as bus %u (error=%d)\n",
> - chan_id, force_nr, ret);
> + if (ret < 0) {
> + dev_err(>dev,
> + "failed to add mux-adapter %u as bus %u 
> (error=%d)\n",
> + chan_id, force_nr, ret);
> + kfree(priv);
> + return ret;
> + }
>   } else {
>   ret = i2c_add_adapter(>adap);
> - dev_err(>dev,
> - "failed to add mux-adapter %u (error=%d)\n",
> - chan_id, ret);
> - }
> - if (ret < 0) {
> - kfree(priv);
> - return ret;
> + if (ret < 0) {
> + dev_err(>dev,
> + "failed to add mux-adapter %u (error=%d)\n",
> + chan_id, ret);
> + kfree(priv);
> + return ret;

It is better to add goto label, this will give one place for kfree->return code.

Thanks

> + }
>   }
>
>   WARN(sysfs_create_link(>adap.dev.kobj, >dev->kobj,
> --
> 2.1.4
>


signature.asc
Description: PGP signature

Re: [PATCH] staging: iio: meter: Replace symbolic permissions with octal permissions

[harinath Nampally]

Jonathan,

Thank you for letting me know about correct iio git tree.

I checked out 'togreg' branch, and noticed that
latest ade7758_core.c still has checkpatch.pl warnings.

Actually Quentin Swain fixed the similar warnings in the ade7854.c,
and my patch is fix for similar warnings but it is for different file
ade7758_core.c

Please correct me if I am wrong.

Thanks,
Harinath

On Mon, May 15, 2017 at 12:27 AM, harinath Nampally
 wrote:
> Jonathan,
>
> Thank you for letting me know about correct iio git tree.
>
> I checked out 'togreg' branch, and noticed that
> latest ade7758_core.c still has checkpatch.pl warnings.
>
> Actually Quentin Swain fixed the similar warnings in the ade7854.c,
> and my patch is fix for similar warnings but it is for different file
> ade7758_core.c
>
> Please refer to below link for Quentin Swain's patch.
> https://www.spinics.net/lists/linux-iio/msg33010.html
>
> Please let me know if I am wrong.
>
> Thanks,
> Harinath
>
> On Mon, May 15, 2017 at 12:22 AM, harinath Nampally
>  wrote:
>> Jonathan,
>>
>> Thank you for letting me know about correct iio git tree.
>>
>> I checked out 'togreg' branch, and noticed that
>> latest ade7758_core.c still has checkpatch.pl warnings.
>>
>> Actually Quentin Swain fixed the similar warnings in the ade7854.c,
>> and my patch is fix for similar warnings but it is for different file
>> ade7758_core.c
>>
>> Please refer to below link for Quentin Swain's patch.
>> https://www.spinics.net/lists/linux-iio/msg33010.html
>>
>> Please let me know if I am wrong.
>>
>> Thanks,
>> Harinath
>>
>> On Sun, May 14, 2017 at 10:41 AM, Jonathan Cameron  wrote:
>>>
>>> On 12/05/17 22:19, Harinath Nampally wrote:

 This patch fixes below kind of warnings:
 WARNING: Symbolic permissions 'S_IXXX | S_IXXX' are not preferred.

 Issue found and fixed by checkpatch.pl

 Signed-off-by: Harinath Nampally 
>>>
>>> Already done by Quentin Swain  last month...
>>>
>>> For IIO related patches, stuff gets queued up in iio.git on
>>> kernel.org before it gets sent on to Greg.  This is relatively
>>> unusual for staging, but does lead to lots of repeats of
>>> patches like this unfortunately.
>>>
>>> Jonathan
>>>
 ---
   drivers/staging/iio/meter/ade7758_core.c | 50
 
   1 file changed, 25 insertions(+), 25 deletions(-)

 diff --git a/drivers/staging/iio/meter/ade7758_core.c
 b/drivers/staging/iio/meter/ade7758_core.c
 index 99c89e6..40498af 100644
 --- a/drivers/staging/iio/meter/ade7758_core.c
 +++ b/drivers/staging/iio/meter/ade7758_core.c
 @@ -301,103 +301,103 @@ static int ade7758_reset(struct device *dev)
 return ret;
   }
   -static IIO_DEV_ATTR_VPEAK(S_IWUSR | S_IRUGO,
 +static IIO_DEV_ATTR_VPEAK(0644,
 ade7758_read_8bit,
 ade7758_write_8bit,
 ADE7758_VPEAK);
 -static IIO_DEV_ATTR_IPEAK(S_IWUSR | S_IRUGO,
 +static IIO_DEV_ATTR_IPEAK(0644,
 ade7758_read_8bit,
 ade7758_write_8bit,
 ADE7758_VPEAK);
 -static IIO_DEV_ATTR_APHCAL(S_IWUSR | S_IRUGO,
 +static IIO_DEV_ATTR_APHCAL(0644,
 ade7758_read_8bit,
 ade7758_write_8bit,
 ADE7758_APHCAL);
 -static IIO_DEV_ATTR_BPHCAL(S_IWUSR | S_IRUGO,
 +static IIO_DEV_ATTR_BPHCAL(0644,
 ade7758_read_8bit,
 ade7758_write_8bit,
 ADE7758_BPHCAL);
 -static IIO_DEV_ATTR_CPHCAL(S_IWUSR | S_IRUGO,
 +static IIO_DEV_ATTR_CPHCAL(0644,
 ade7758_read_8bit,
 ade7758_write_8bit,
 ADE7758_CPHCAL);
 -static IIO_DEV_ATTR_WDIV(S_IWUSR | S_IRUGO,
 +static IIO_DEV_ATTR_WDIV(0644,
 ade7758_read_8bit,
 ade7758_write_8bit,
 ADE7758_WDIV);
 -static IIO_DEV_ATTR_VADIV(S_IWUSR | S_IRUGO,
 +static IIO_DEV_ATTR_VADIV(0644,
 ade7758_read_8bit,
 ade7758_write_8bit,
 ADE7758_VADIV);
 -static IIO_DEV_ATTR_AIRMS(S_IRUGO,
 +static IIO_DEV_ATTR_AIRMS(0444,
 ade7758_read_24bit,
 NULL,
 ADE7758_AIRMS);
 -static IIO_DEV_ATTR_BIRMS(S_IRUGO,
 +static IIO_DEV_ATTR_BIRMS(0444,
 ade7758_read_24bit,
 NULL,
 ADE7758_BIRMS);
 -static IIO_DEV_ATTR_CIRMS(S_IRUGO,
 +static IIO_DEV_ATTR_CIRMS(0444,
 ade7758_read_24bit,
 NULL,
 ADE7758_CIRMS);
 -static IIO_DEV_ATTR_AVRMS(S_IRUGO,
 +static IIO_DEV_ATTR_AVRMS(0444,
 ade7758_read_24bit,
 NULL,
  

Re: [PATCH] staging: iio: meter: Replace symbolic permissions with octal permissions

[harinath Nampally]

Jonathan,

Thank you for letting me know about correct iio git tree.

I checked out 'togreg' branch, and noticed that
latest ade7758_core.c still has checkpatch.pl warnings.

Actually Quentin Swain fixed the similar warnings in the ade7854.c,
and my patch is fix for similar warnings but it is for different file
ade7758_core.c

Please correct me if I am wrong.

Thanks,
Harinath

On Mon, May 15, 2017 at 12:27 AM, harinath Nampally
 wrote:
> Jonathan,
>
> Thank you for letting me know about correct iio git tree.
>
> I checked out 'togreg' branch, and noticed that
> latest ade7758_core.c still has checkpatch.pl warnings.
>
> Actually Quentin Swain fixed the similar warnings in the ade7854.c,
> and my patch is fix for similar warnings but it is for different file
> ade7758_core.c
>
> Please refer to below link for Quentin Swain's patch.
> https://www.spinics.net/lists/linux-iio/msg33010.html
>
> Please let me know if I am wrong.
>
> Thanks,
> Harinath
>
> On Mon, May 15, 2017 at 12:22 AM, harinath Nampally
>  wrote:
>> Jonathan,
>>
>> Thank you for letting me know about correct iio git tree.
>>
>> I checked out 'togreg' branch, and noticed that
>> latest ade7758_core.c still has checkpatch.pl warnings.
>>
>> Actually Quentin Swain fixed the similar warnings in the ade7854.c,
>> and my patch is fix for similar warnings but it is for different file
>> ade7758_core.c
>>
>> Please refer to below link for Quentin Swain's patch.
>> https://www.spinics.net/lists/linux-iio/msg33010.html
>>
>> Please let me know if I am wrong.
>>
>> Thanks,
>> Harinath
>>
>> On Sun, May 14, 2017 at 10:41 AM, Jonathan Cameron  wrote:
>>>
>>> On 12/05/17 22:19, Harinath Nampally wrote:

 This patch fixes below kind of warnings:
 WARNING: Symbolic permissions 'S_IXXX | S_IXXX' are not preferred.

 Issue found and fixed by checkpatch.pl

 Signed-off-by: Harinath Nampally 
>>>
>>> Already done by Quentin Swain  last month...
>>>
>>> For IIO related patches, stuff gets queued up in iio.git on
>>> kernel.org before it gets sent on to Greg.  This is relatively
>>> unusual for staging, but does lead to lots of repeats of
>>> patches like this unfortunately.
>>>
>>> Jonathan
>>>
 ---
   drivers/staging/iio/meter/ade7758_core.c | 50
 
   1 file changed, 25 insertions(+), 25 deletions(-)

 diff --git a/drivers/staging/iio/meter/ade7758_core.c
 b/drivers/staging/iio/meter/ade7758_core.c
 index 99c89e6..40498af 100644
 --- a/drivers/staging/iio/meter/ade7758_core.c
 +++ b/drivers/staging/iio/meter/ade7758_core.c
 @@ -301,103 +301,103 @@ static int ade7758_reset(struct device *dev)
 return ret;
   }
   -static IIO_DEV_ATTR_VPEAK(S_IWUSR | S_IRUGO,
 +static IIO_DEV_ATTR_VPEAK(0644,
 ade7758_read_8bit,
 ade7758_write_8bit,
 ADE7758_VPEAK);
 -static IIO_DEV_ATTR_IPEAK(S_IWUSR | S_IRUGO,
 +static IIO_DEV_ATTR_IPEAK(0644,
 ade7758_read_8bit,
 ade7758_write_8bit,
 ADE7758_VPEAK);
 -static IIO_DEV_ATTR_APHCAL(S_IWUSR | S_IRUGO,
 +static IIO_DEV_ATTR_APHCAL(0644,
 ade7758_read_8bit,
 ade7758_write_8bit,
 ADE7758_APHCAL);
 -static IIO_DEV_ATTR_BPHCAL(S_IWUSR | S_IRUGO,
 +static IIO_DEV_ATTR_BPHCAL(0644,
 ade7758_read_8bit,
 ade7758_write_8bit,
 ADE7758_BPHCAL);
 -static IIO_DEV_ATTR_CPHCAL(S_IWUSR | S_IRUGO,
 +static IIO_DEV_ATTR_CPHCAL(0644,
 ade7758_read_8bit,
 ade7758_write_8bit,
 ADE7758_CPHCAL);
 -static IIO_DEV_ATTR_WDIV(S_IWUSR | S_IRUGO,
 +static IIO_DEV_ATTR_WDIV(0644,
 ade7758_read_8bit,
 ade7758_write_8bit,
 ADE7758_WDIV);
 -static IIO_DEV_ATTR_VADIV(S_IWUSR | S_IRUGO,
 +static IIO_DEV_ATTR_VADIV(0644,
 ade7758_read_8bit,
 ade7758_write_8bit,
 ADE7758_VADIV);
 -static IIO_DEV_ATTR_AIRMS(S_IRUGO,
 +static IIO_DEV_ATTR_AIRMS(0444,
 ade7758_read_24bit,
 NULL,
 ADE7758_AIRMS);
 -static IIO_DEV_ATTR_BIRMS(S_IRUGO,
 +static IIO_DEV_ATTR_BIRMS(0444,
 ade7758_read_24bit,
 NULL,
 ADE7758_BIRMS);
 -static IIO_DEV_ATTR_CIRMS(S_IRUGO,
 +static IIO_DEV_ATTR_CIRMS(0444,
 ade7758_read_24bit,
 NULL,
 ADE7758_CIRMS);
 -static IIO_DEV_ATTR_AVRMS(S_IRUGO,
 +static IIO_DEV_ATTR_AVRMS(0444,
 ade7758_read_24bit,
 NULL,
 ADE7758_AVRMS);
 -static IIO_DEV_ATTR_BVRMS(S_IRUGO,
 +static IIO_DEV_ATTR_BVRMS(0444,
  

Re: [PATCH] staging: iio: meter: Replace symbolic permissions with octal permissions

[harinath Nampally]

Jonathan,

Thank you for letting me know about correct iio git tree.

I checked out 'togreg' branch, and noticed that
latest ade7758_core.c still has checkpatch.pl warnings.

Actually Quentin Swain fixed the similar warnings in the ade7854.c,
and my patch is fix for similar warnings but it is for different file
ade7758_core.c

Please refer to below link for Quentin Swain's patch.
https://www.spinics.net/lists/linux-iio/msg33010.html

Please let me know if I am wrong.

Thanks,
Harinath

On Mon, May 15, 2017 at 12:22 AM, harinath Nampally
 wrote:
> Jonathan,
>
> Thank you for letting me know about correct iio git tree.
>
> I checked out 'togreg' branch, and noticed that
> latest ade7758_core.c still has checkpatch.pl warnings.
>
> Actually Quentin Swain fixed the similar warnings in the ade7854.c,
> and my patch is fix for similar warnings but it is for different file
> ade7758_core.c
>
> Please refer to below link for Quentin Swain's patch.
> https://www.spinics.net/lists/linux-iio/msg33010.html
>
> Please let me know if I am wrong.
>
> Thanks,
> Harinath
>
> On Sun, May 14, 2017 at 10:41 AM, Jonathan Cameron  wrote:
>>
>> On 12/05/17 22:19, Harinath Nampally wrote:
>>>
>>> This patch fixes below kind of warnings:
>>> WARNING: Symbolic permissions 'S_IXXX | S_IXXX' are not preferred.
>>>
>>> Issue found and fixed by checkpatch.pl
>>>
>>> Signed-off-by: Harinath Nampally 
>>
>> Already done by Quentin Swain  last month...
>>
>> For IIO related patches, stuff gets queued up in iio.git on
>> kernel.org before it gets sent on to Greg.  This is relatively
>> unusual for staging, but does lead to lots of repeats of
>> patches like this unfortunately.
>>
>> Jonathan
>>
>>> ---
>>>   drivers/staging/iio/meter/ade7758_core.c | 50
>>> 
>>>   1 file changed, 25 insertions(+), 25 deletions(-)
>>>
>>> diff --git a/drivers/staging/iio/meter/ade7758_core.c
>>> b/drivers/staging/iio/meter/ade7758_core.c
>>> index 99c89e6..40498af 100644
>>> --- a/drivers/staging/iio/meter/ade7758_core.c
>>> +++ b/drivers/staging/iio/meter/ade7758_core.c
>>> @@ -301,103 +301,103 @@ static int ade7758_reset(struct device *dev)
>>> return ret;
>>>   }
>>>   -static IIO_DEV_ATTR_VPEAK(S_IWUSR | S_IRUGO,
>>> +static IIO_DEV_ATTR_VPEAK(0644,
>>> ade7758_read_8bit,
>>> ade7758_write_8bit,
>>> ADE7758_VPEAK);
>>> -static IIO_DEV_ATTR_IPEAK(S_IWUSR | S_IRUGO,
>>> +static IIO_DEV_ATTR_IPEAK(0644,
>>> ade7758_read_8bit,
>>> ade7758_write_8bit,
>>> ADE7758_VPEAK);
>>> -static IIO_DEV_ATTR_APHCAL(S_IWUSR | S_IRUGO,
>>> +static IIO_DEV_ATTR_APHCAL(0644,
>>> ade7758_read_8bit,
>>> ade7758_write_8bit,
>>> ADE7758_APHCAL);
>>> -static IIO_DEV_ATTR_BPHCAL(S_IWUSR | S_IRUGO,
>>> +static IIO_DEV_ATTR_BPHCAL(0644,
>>> ade7758_read_8bit,
>>> ade7758_write_8bit,
>>> ADE7758_BPHCAL);
>>> -static IIO_DEV_ATTR_CPHCAL(S_IWUSR | S_IRUGO,
>>> +static IIO_DEV_ATTR_CPHCAL(0644,
>>> ade7758_read_8bit,
>>> ade7758_write_8bit,
>>> ADE7758_CPHCAL);
>>> -static IIO_DEV_ATTR_WDIV(S_IWUSR | S_IRUGO,
>>> +static IIO_DEV_ATTR_WDIV(0644,
>>> ade7758_read_8bit,
>>> ade7758_write_8bit,
>>> ADE7758_WDIV);
>>> -static IIO_DEV_ATTR_VADIV(S_IWUSR | S_IRUGO,
>>> +static IIO_DEV_ATTR_VADIV(0644,
>>> ade7758_read_8bit,
>>> ade7758_write_8bit,
>>> ADE7758_VADIV);
>>> -static IIO_DEV_ATTR_AIRMS(S_IRUGO,
>>> +static IIO_DEV_ATTR_AIRMS(0444,
>>> ade7758_read_24bit,
>>> NULL,
>>> ADE7758_AIRMS);
>>> -static IIO_DEV_ATTR_BIRMS(S_IRUGO,
>>> +static IIO_DEV_ATTR_BIRMS(0444,
>>> ade7758_read_24bit,
>>> NULL,
>>> ADE7758_BIRMS);
>>> -static IIO_DEV_ATTR_CIRMS(S_IRUGO,
>>> +static IIO_DEV_ATTR_CIRMS(0444,
>>> ade7758_read_24bit,
>>> NULL,
>>> ADE7758_CIRMS);
>>> -static IIO_DEV_ATTR_AVRMS(S_IRUGO,
>>> +static IIO_DEV_ATTR_AVRMS(0444,
>>> ade7758_read_24bit,
>>> NULL,
>>> ADE7758_AVRMS);
>>> -static IIO_DEV_ATTR_BVRMS(S_IRUGO,
>>> +static IIO_DEV_ATTR_BVRMS(0444,
>>> ade7758_read_24bit,
>>> NULL,
>>> ADE7758_BVRMS);
>>> -static IIO_DEV_ATTR_CVRMS(S_IRUGO,
>>> +static IIO_DEV_ATTR_CVRMS(0444,
>>> ade7758_read_24bit,
>>> NULL,
>>> ADE7758_CVRMS);
>>> -static IIO_DEV_ATTR_AIRMSOS(S_IWUSR | S_IRUGO,
>>> +static IIO_DEV_ATTR_AIRMSOS(0644,
>>> ade7758_read_16bit,
>>> ade7758_write_16bit,
>>> ADE7758_AIRMSOS);
>>> 

Re: [PATCH] staging: iio: meter: Replace symbolic permissions with octal permissions

[harinath Nampally]

Jonathan,

Thank you for letting me know about correct iio git tree.

I checked out 'togreg' branch, and noticed that
latest ade7758_core.c still has checkpatch.pl warnings.

Actually Quentin Swain fixed the similar warnings in the ade7854.c,
and my patch is fix for similar warnings but it is for different file
ade7758_core.c

Please refer to below link for Quentin Swain's patch.
https://www.spinics.net/lists/linux-iio/msg33010.html

Please let me know if I am wrong.

Thanks,
Harinath

On Mon, May 15, 2017 at 12:22 AM, harinath Nampally
 wrote:
> Jonathan,
>
> Thank you for letting me know about correct iio git tree.
>
> I checked out 'togreg' branch, and noticed that
> latest ade7758_core.c still has checkpatch.pl warnings.
>
> Actually Quentin Swain fixed the similar warnings in the ade7854.c,
> and my patch is fix for similar warnings but it is for different file
> ade7758_core.c
>
> Please refer to below link for Quentin Swain's patch.
> https://www.spinics.net/lists/linux-iio/msg33010.html
>
> Please let me know if I am wrong.
>
> Thanks,
> Harinath
>
> On Sun, May 14, 2017 at 10:41 AM, Jonathan Cameron  wrote:
>>
>> On 12/05/17 22:19, Harinath Nampally wrote:
>>>
>>> This patch fixes below kind of warnings:
>>> WARNING: Symbolic permissions 'S_IXXX | S_IXXX' are not preferred.
>>>
>>> Issue found and fixed by checkpatch.pl
>>>
>>> Signed-off-by: Harinath Nampally 
>>
>> Already done by Quentin Swain  last month...
>>
>> For IIO related patches, stuff gets queued up in iio.git on
>> kernel.org before it gets sent on to Greg.  This is relatively
>> unusual for staging, but does lead to lots of repeats of
>> patches like this unfortunately.
>>
>> Jonathan
>>
>>> ---
>>>   drivers/staging/iio/meter/ade7758_core.c | 50
>>> 
>>>   1 file changed, 25 insertions(+), 25 deletions(-)
>>>
>>> diff --git a/drivers/staging/iio/meter/ade7758_core.c
>>> b/drivers/staging/iio/meter/ade7758_core.c
>>> index 99c89e6..40498af 100644
>>> --- a/drivers/staging/iio/meter/ade7758_core.c
>>> +++ b/drivers/staging/iio/meter/ade7758_core.c
>>> @@ -301,103 +301,103 @@ static int ade7758_reset(struct device *dev)
>>> return ret;
>>>   }
>>>   -static IIO_DEV_ATTR_VPEAK(S_IWUSR | S_IRUGO,
>>> +static IIO_DEV_ATTR_VPEAK(0644,
>>> ade7758_read_8bit,
>>> ade7758_write_8bit,
>>> ADE7758_VPEAK);
>>> -static IIO_DEV_ATTR_IPEAK(S_IWUSR | S_IRUGO,
>>> +static IIO_DEV_ATTR_IPEAK(0644,
>>> ade7758_read_8bit,
>>> ade7758_write_8bit,
>>> ADE7758_VPEAK);
>>> -static IIO_DEV_ATTR_APHCAL(S_IWUSR | S_IRUGO,
>>> +static IIO_DEV_ATTR_APHCAL(0644,
>>> ade7758_read_8bit,
>>> ade7758_write_8bit,
>>> ADE7758_APHCAL);
>>> -static IIO_DEV_ATTR_BPHCAL(S_IWUSR | S_IRUGO,
>>> +static IIO_DEV_ATTR_BPHCAL(0644,
>>> ade7758_read_8bit,
>>> ade7758_write_8bit,
>>> ADE7758_BPHCAL);
>>> -static IIO_DEV_ATTR_CPHCAL(S_IWUSR | S_IRUGO,
>>> +static IIO_DEV_ATTR_CPHCAL(0644,
>>> ade7758_read_8bit,
>>> ade7758_write_8bit,
>>> ADE7758_CPHCAL);
>>> -static IIO_DEV_ATTR_WDIV(S_IWUSR | S_IRUGO,
>>> +static IIO_DEV_ATTR_WDIV(0644,
>>> ade7758_read_8bit,
>>> ade7758_write_8bit,
>>> ADE7758_WDIV);
>>> -static IIO_DEV_ATTR_VADIV(S_IWUSR | S_IRUGO,
>>> +static IIO_DEV_ATTR_VADIV(0644,
>>> ade7758_read_8bit,
>>> ade7758_write_8bit,
>>> ADE7758_VADIV);
>>> -static IIO_DEV_ATTR_AIRMS(S_IRUGO,
>>> +static IIO_DEV_ATTR_AIRMS(0444,
>>> ade7758_read_24bit,
>>> NULL,
>>> ADE7758_AIRMS);
>>> -static IIO_DEV_ATTR_BIRMS(S_IRUGO,
>>> +static IIO_DEV_ATTR_BIRMS(0444,
>>> ade7758_read_24bit,
>>> NULL,
>>> ADE7758_BIRMS);
>>> -static IIO_DEV_ATTR_CIRMS(S_IRUGO,
>>> +static IIO_DEV_ATTR_CIRMS(0444,
>>> ade7758_read_24bit,
>>> NULL,
>>> ADE7758_CIRMS);
>>> -static IIO_DEV_ATTR_AVRMS(S_IRUGO,
>>> +static IIO_DEV_ATTR_AVRMS(0444,
>>> ade7758_read_24bit,
>>> NULL,
>>> ADE7758_AVRMS);
>>> -static IIO_DEV_ATTR_BVRMS(S_IRUGO,
>>> +static IIO_DEV_ATTR_BVRMS(0444,
>>> ade7758_read_24bit,
>>> NULL,
>>> ADE7758_BVRMS);
>>> -static IIO_DEV_ATTR_CVRMS(S_IRUGO,
>>> +static IIO_DEV_ATTR_CVRMS(0444,
>>> ade7758_read_24bit,
>>> NULL,
>>> ADE7758_CVRMS);
>>> -static IIO_DEV_ATTR_AIRMSOS(S_IWUSR | S_IRUGO,
>>> +static IIO_DEV_ATTR_AIRMSOS(0644,
>>> ade7758_read_16bit,
>>> ade7758_write_16bit,
>>> ADE7758_AIRMSOS);
>>> -static IIO_DEV_ATTR_BIRMSOS(S_IWUSR | S_IRUGO,
>>> +static IIO_DEV_ATTR_BIRMSOS(0644,
>>>  

Re: [drm:qxl] BUG: sleeping function called from invalid context - qxl_bo_kmap_atomic_page()...splat

[Gabriel Krisman Bertazi]

Mike Galbraith  writes:

> On Tue, 2017-05-09 at 04:37 +0200, Mike Galbraith wrote:
>> On Mon, 2017-05-08 at 16:48 -0300, Gabriel Krisman Bertazi wrote:
>> 
>> > Thanks for reporting this.  Can you confirm the following patch prevents
>> > the issue?
>> 
>> Nope, it still gripes.
>
> The reason for this gripe is that we find that we don't have memory
> reserved.. a tad too late.
>

Thanks for the info.

Sorry I wasn't able to get back to this last week.  I'll try to get
another patch for -rc2.

> Xorg-2252  [000]    135.409756: qxl_release_map 
> <-qxl_cursor_atomic_update
> Xorg-2252  [000]    135.409756: qxl_bo_kmap_atomic_page 
> <-qxl_release_map
> Xorg-2252  [000]    135.409757: qxl_bo_kmap_atomic_page: ENTER
> Xorg-2252  [000]    135.409757: ttm_mem_io_lock 
> <-qxl_bo_kmap_atomic_page
> Xorg-2252  [000]    135.409757: ttm_mem_io_reserve 
> <-qxl_bo_kmap_atomic_page
> Xorg-2252  [000]    135.409757: qxl_ttm_io_mem_reserve 
> <-ttm_mem_io_reserve
> Xorg-2252  [000]    135.409757: ttm_mem_io_unlock 
> <-qxl_bo_kmap_atomic_page
> Xorg-2252  [000]    135.409757: qxl_bo_kmap_atomic_page: 
> PREEMPTION DISABLED
> Xorg-2252  [000] ...1   135.409758: qxl_bo_kmap 
> <-qxl_cursor_atomic_update
> Xorg-2252  [000] ...1   135.409758: ttm_bo_kmap <-qxl_bo_kmap  
> <== too late
> Xorg-2252  [000] ...1   135.409758: ttm_mem_io_reserve 
> <-ttm_bo_kmap
> Xorg-2252  [000] ...1   135.409758: qxl_ttm_io_mem_reserve 
> <-ttm_mem_io_reserve
> Xorg-2252  [000] ...1   135.409759: ioremap_nocache <-ttm_bo_kmap 
> <== game over
> Xorg-2252  [000] ...1   135.409759: __ioremap_caller 
> <-ioremap_nocache
> Xorg-2252  [000] ...1   135.409759: walk_system_ram_range 
> <-__ioremap_caller
> Xorg-2252  [000] ...1   135.409759: find_next_iomem_res 
> <-walk_system_ram_range
> Xorg-2252  [000] ...1   135.409759: _raw_read_lock 
> <-find_next_iomem_res
> Xorg-2252  [000] ...1   135.409760: reserve_memtype 
> <-__ioremap_caller
> Xorg-2252  [000] ...1   135.409760: pat_pagerange_is_ram 
> <-reserve_memtype
> Xorg-2252  [000] ...1   135.409761: walk_system_ram_range 
> <-pat_pagerange_is_ram
> Xorg-2252  [000] ...1   135.409761: find_next_iomem_res 
> <-walk_system_ram_range
> Xorg-2252  [000] ...1   135.409761: _raw_read_lock 
> <-find_next_iomem_res
> Xorg-2252  [000] ...1   135.409761: kmem_cache_alloc_trace 
> <-reserve_memtype
> Xorg-2252  [000] ...1   135.409761: __might_sleep 
> <-kmem_cache_alloc_trace
> Xorg-2252  [000] ...1   135.409762: ___might_sleep <-__might_sleep

-- 
Gabriel Krisman Bertazi

Re: [drm:qxl] BUG: sleeping function called from invalid context - qxl_bo_kmap_atomic_page()...splat

[Gabriel Krisman Bertazi]

Mike Galbraith  writes:

> On Tue, 2017-05-09 at 04:37 +0200, Mike Galbraith wrote:
>> On Mon, 2017-05-08 at 16:48 -0300, Gabriel Krisman Bertazi wrote:
>> 
>> > Thanks for reporting this.  Can you confirm the following patch prevents
>> > the issue?
>> 
>> Nope, it still gripes.
>
> The reason for this gripe is that we find that we don't have memory
> reserved.. a tad too late.
>

Thanks for the info.

Sorry I wasn't able to get back to this last week.  I'll try to get
another patch for -rc2.

> Xorg-2252  [000]    135.409756: qxl_release_map 
> <-qxl_cursor_atomic_update
> Xorg-2252  [000]    135.409756: qxl_bo_kmap_atomic_page 
> <-qxl_release_map
> Xorg-2252  [000]    135.409757: qxl_bo_kmap_atomic_page: ENTER
> Xorg-2252  [000]    135.409757: ttm_mem_io_lock 
> <-qxl_bo_kmap_atomic_page
> Xorg-2252  [000]    135.409757: ttm_mem_io_reserve 
> <-qxl_bo_kmap_atomic_page
> Xorg-2252  [000]    135.409757: qxl_ttm_io_mem_reserve 
> <-ttm_mem_io_reserve
> Xorg-2252  [000]    135.409757: ttm_mem_io_unlock 
> <-qxl_bo_kmap_atomic_page
> Xorg-2252  [000]    135.409757: qxl_bo_kmap_atomic_page: 
> PREEMPTION DISABLED
> Xorg-2252  [000] ...1   135.409758: qxl_bo_kmap 
> <-qxl_cursor_atomic_update
> Xorg-2252  [000] ...1   135.409758: ttm_bo_kmap <-qxl_bo_kmap  
> <== too late
> Xorg-2252  [000] ...1   135.409758: ttm_mem_io_reserve 
> <-ttm_bo_kmap
> Xorg-2252  [000] ...1   135.409758: qxl_ttm_io_mem_reserve 
> <-ttm_mem_io_reserve
> Xorg-2252  [000] ...1   135.409759: ioremap_nocache <-ttm_bo_kmap 
> <== game over
> Xorg-2252  [000] ...1   135.409759: __ioremap_caller 
> <-ioremap_nocache
> Xorg-2252  [000] ...1   135.409759: walk_system_ram_range 
> <-__ioremap_caller
> Xorg-2252  [000] ...1   135.409759: find_next_iomem_res 
> <-walk_system_ram_range
> Xorg-2252  [000] ...1   135.409759: _raw_read_lock 
> <-find_next_iomem_res
> Xorg-2252  [000] ...1   135.409760: reserve_memtype 
> <-__ioremap_caller
> Xorg-2252  [000] ...1   135.409760: pat_pagerange_is_ram 
> <-reserve_memtype
> Xorg-2252  [000] ...1   135.409761: walk_system_ram_range 
> <-pat_pagerange_is_ram
> Xorg-2252  [000] ...1   135.409761: find_next_iomem_res 
> <-walk_system_ram_range
> Xorg-2252  [000] ...1   135.409761: _raw_read_lock 
> <-find_next_iomem_res
> Xorg-2252  [000] ...1   135.409761: kmem_cache_alloc_trace 
> <-reserve_memtype
> Xorg-2252  [000] ...1   135.409761: __might_sleep 
> <-kmem_cache_alloc_trace
> Xorg-2252  [000] ...1   135.409762: ___might_sleep <-__might_sleep

-- 
Gabriel Krisman Bertazi

Re: [PATCH v2 6/8] drm: Introduce drm_bridge_mode_valid()

[Archit Taneja]

On 05/12/2017 04:31 PM, Laurent Pinchart wrote:

Hi Archit,

On Friday 12 May 2017 16:20:07 Archit Taneja wrote:

On 05/12/2017 03:08 PM, Laurent Pinchart wrote:

On Wednesday 10 May 2017 17:14:33 Daniel Vetter wrote:

On Wed, May 10, 2017 at 04:41:09PM +0300, Ville Syrjälä wrote:

On Tue, May 09, 2017 at 06:00:13PM +0100, Jose Abreu wrote:

Introduce a new helper function which calls mode_valid() callback
for all bridges in an encoder chain.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Andrzej Hajda 
Cc: Archit Taneja 
---

 drivers/gpu/drm/drm_bridge.c | 33 +
 include/drm/drm_bridge.h |  2 ++
 2 files changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/drm_bridge.c
b/drivers/gpu/drm/drm_bridge.c
index 86a7637..dc8cdfe 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -206,6 +206,39 @@ bool drm_bridge_mode_fixup(struct drm_bridge
*bridge,

 EXPORT_SYMBOL(drm_bridge_mode_fixup);

 /**

+ * drm_bridge_mode_valid - validate the mode against all bridges in
the
+ *encoder chain.
+ * @bridge: bridge control structure
+ * @mode: desired mode to be validated
+ *
+ * Calls _bridge_funcs.mode_valid for all the bridges in the
encoder
+ * chain, starting from the first bridge to the last. If at least one
bridge + * does not accept the mode the function returns the error
code.
+ *
+ * Note: the bridge passed should be the one closest to the encoder.
+ *
+ * RETURNS:
+ * MODE_OK on success, drm_mode_status Enum error code on failure
+ */
+enum drm_mode_status drm_bridge_mode_valid(struct drm_bridge *bridge,
+  const struct

drm_display_mode


*mode)


+{
+   enum drm_mode_status ret = MODE_OK;
+
+   if (!bridge)
+   return ret;
+
+   if (bridge->funcs->mode_valid)
+   ret = bridge->funcs->mode_valid(bridge, mode);
+
+   if (ret != MODE_OK)
+   return ret;
+
+   return drm_bridge_mode_valid(bridge->next, mode);


Looks like it should be pretty trivial to avoid the recursion.

Am I correct in interpreting this that bridges have some kind of
a hand rolled linked list implementation? Reusing the standard
linked lists would allow you to use list_for_each() etc.


Yeah it's a hand-rolled list, but current hw also has a bridge nesting
depth of 2, so it really doesn't matter. I guess once we have real long
chains of bridges we can fix this (and just using list_head sounds like a
great idea).


Even if not really needed right now, it's a pretty easy cleanup, if Jose
has time to handle it in v3 of this series let's not postpone it ;-)


jfyi, some of the bridge functions call the ops from the last bridge in the
chain to first, so we'd need to use list_for_each_entry_prev() (or something
like that) for them.


And now that I think about it, for some of the operations (especially
enable/disable) I believe that the bridge should be able to decide whether to
call the next/previous bridge first or to configure its hardware first. I can
image bridges that need the previous bridge in the chain to provide a valid
clock before they get started, as well as bridges that need to be started with
the incoming video signal stopped.


I guess converting into list would be a good start to achieve this. We'd 
probably
need to extend/redo the drm_bridge_attach() API to tweak the order in the which
the ops are called.

Thanks,
Archit

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 6/8] drm: Introduce drm_bridge_mode_valid()

[Archit Taneja]

On 05/12/2017 04:31 PM, Laurent Pinchart wrote:

Hi Archit,

On Friday 12 May 2017 16:20:07 Archit Taneja wrote:

On 05/12/2017 03:08 PM, Laurent Pinchart wrote:

On Wednesday 10 May 2017 17:14:33 Daniel Vetter wrote:

On Wed, May 10, 2017 at 04:41:09PM +0300, Ville Syrjälä wrote:

On Tue, May 09, 2017 at 06:00:13PM +0100, Jose Abreu wrote:

Introduce a new helper function which calls mode_valid() callback
for all bridges in an encoder chain.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Andrzej Hajda 
Cc: Archit Taneja 
---

 drivers/gpu/drm/drm_bridge.c | 33 +
 include/drm/drm_bridge.h |  2 ++
 2 files changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/drm_bridge.c
b/drivers/gpu/drm/drm_bridge.c
index 86a7637..dc8cdfe 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -206,6 +206,39 @@ bool drm_bridge_mode_fixup(struct drm_bridge
*bridge,

 EXPORT_SYMBOL(drm_bridge_mode_fixup);

 /**

+ * drm_bridge_mode_valid - validate the mode against all bridges in
the
+ *encoder chain.
+ * @bridge: bridge control structure
+ * @mode: desired mode to be validated
+ *
+ * Calls _bridge_funcs.mode_valid for all the bridges in the
encoder
+ * chain, starting from the first bridge to the last. If at least one
bridge + * does not accept the mode the function returns the error
code.
+ *
+ * Note: the bridge passed should be the one closest to the encoder.
+ *
+ * RETURNS:
+ * MODE_OK on success, drm_mode_status Enum error code on failure
+ */
+enum drm_mode_status drm_bridge_mode_valid(struct drm_bridge *bridge,
+  const struct

drm_display_mode


*mode)


+{
+   enum drm_mode_status ret = MODE_OK;
+
+   if (!bridge)
+   return ret;
+
+   if (bridge->funcs->mode_valid)
+   ret = bridge->funcs->mode_valid(bridge, mode);
+
+   if (ret != MODE_OK)
+   return ret;
+
+   return drm_bridge_mode_valid(bridge->next, mode);


Looks like it should be pretty trivial to avoid the recursion.

Am I correct in interpreting this that bridges have some kind of
a hand rolled linked list implementation? Reusing the standard
linked lists would allow you to use list_for_each() etc.


Yeah it's a hand-rolled list, but current hw also has a bridge nesting
depth of 2, so it really doesn't matter. I guess once we have real long
chains of bridges we can fix this (and just using list_head sounds like a
great idea).


Even if not really needed right now, it's a pretty easy cleanup, if Jose
has time to handle it in v3 of this series let's not postpone it ;-)


jfyi, some of the bridge functions call the ops from the last bridge in the
chain to first, so we'd need to use list_for_each_entry_prev() (or something
like that) for them.


And now that I think about it, for some of the operations (especially
enable/disable) I believe that the bridge should be able to decide whether to
call the next/previous bridge first or to configure its hardware first. I can
image bridges that need the previous bridge in the chain to provide a valid
clock before they get started, as well as bridges that need to be started with
the incoming video signal stopped.


I guess converting into list would be a good start to achieve this. We'd 
probably
need to extend/redo the drm_bridge_attach() API to tweak the order in the which
the ops are called.

Thanks,
Archit

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] net: x25: fix one potential use-after-free issue

[linzhang]

The function x25_init is not properly unregister related resources
on error handler.It is will result in kernel oops if x25_init init
failed, so add right unregister call on error handler.

Signed-off-by: linzhang 
---
 net/x25/af_x25.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c
index 8b911c2..e01e09a 100644
--- a/net/x25/af_x25.c
+++ b/net/x25/af_x25.c
@@ -1811,12 +1811,14 @@ static int __init x25_init(void)
x25_register_sysctl();
rc = x25_proc_init();
if (rc != 0)
-   goto out_dev;
+   goto out_sysctl;
 out:
return rc;
-out_dev:
+out_sysctl:
+   x25_unregister_sysctl();
unregister_netdevice_notifier(_dev_notifier);
 out_sock:
+   dev_remove_pack(_packet_type);
sock_unregister(AF_X25);
 out_proto:
proto_unregister(_proto);
-- 
1.8.3.1

[PATCH] net: x25: fix one potential use-after-free issue

[linzhang]

The function x25_init is not properly unregister related resources
on error handler.It is will result in kernel oops if x25_init init
failed, so add right unregister call on error handler.

Signed-off-by: linzhang 
---
 net/x25/af_x25.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c
index 8b911c2..e01e09a 100644
--- a/net/x25/af_x25.c
+++ b/net/x25/af_x25.c
@@ -1811,12 +1811,14 @@ static int __init x25_init(void)
x25_register_sysctl();
rc = x25_proc_init();
if (rc != 0)
-   goto out_dev;
+   goto out_sysctl;
 out:
return rc;
-out_dev:
+out_sysctl:
+   x25_unregister_sysctl();
unregister_netdevice_notifier(_dev_notifier);
 out_sock:
+   dev_remove_pack(_packet_type);
sock_unregister(AF_X25);
 out_proto:
proto_unregister(_proto);
-- 
1.8.3.1

Re: [PATCH v2 1/3] sched/deadline: Zero out positive runtime after throttling constrained tasks

[Xunlei Pang]

On 05/12/2017 at 11:32 AM, Xunlei Pang wrote:
> When a contrained task is throttled by dl_check_constrained_dl(),
> it may carry the remaining positive runtime, as a result when
> dl_task_timer() fires and calls replenish_dl_entity(), it will
> not be replenished correctly due to the positive dl_se->runtime.
>
> This patch assigns its runtime to 0 if positive after throttling.
>
> Fixes: df8eac8cafce ("sched/deadline: Throttle a constrained deadline task 
> activated after the deadline)
> Acked-by: Daniel Bristot de Oliveira 
> Signed-off-by: Xunlei Pang 

Hi Peter,

According to the previous discussion with Luca, please ignore the last two 
patches of this series.
Could you please only help review or pick up this one?

Regards,
Xunlei

> ---
>  kernel/sched/deadline.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index a2ce590..d3d291e 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -723,6 +723,8 @@ static inline void dl_check_constrained_dl(struct 
> sched_dl_entity *dl_se)
>   if (unlikely(dl_se->dl_boosted || !start_dl_timer(p)))
>   return;
>   dl_se->dl_throttled = 1;
> + if (dl_se->runtime > 0)
> + dl_se->runtime = 0;
>   }
>  }
>  

Re: [PATCH v2 1/3] sched/deadline: Zero out positive runtime after throttling constrained tasks

[Xunlei Pang]

On 05/12/2017 at 11:32 AM, Xunlei Pang wrote:
> When a contrained task is throttled by dl_check_constrained_dl(),
> it may carry the remaining positive runtime, as a result when
> dl_task_timer() fires and calls replenish_dl_entity(), it will
> not be replenished correctly due to the positive dl_se->runtime.
>
> This patch assigns its runtime to 0 if positive after throttling.
>
> Fixes: df8eac8cafce ("sched/deadline: Throttle a constrained deadline task 
> activated after the deadline)
> Acked-by: Daniel Bristot de Oliveira 
> Signed-off-by: Xunlei Pang 

Hi Peter,

According to the previous discussion with Luca, please ignore the last two 
patches of this series.
Could you please only help review or pick up this one?

Regards,
Xunlei

> ---
>  kernel/sched/deadline.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index a2ce590..d3d291e 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -723,6 +723,8 @@ static inline void dl_check_constrained_dl(struct 
> sched_dl_entity *dl_se)
>   if (unlikely(dl_se->dl_boosted || !start_dl_timer(p)))
>   return;
>   dl_se->dl_throttled = 1;
> + if (dl_se->runtime > 0)
> + dl_se->runtime = 0;
>   }
>  }
>  

Re: [PATCH] selftests/vm: Fix test for virtual address range mapping for arm64

[Anshuman Khandual]

On 05/10/2017 12:30 AM, Michal Suchanek wrote:
> Arm64 has 256TB address space so fix the test to pass on Arm as well.
> 
> Also remove unneeded numaif include.
> 
> Signed-off-by: Michal Suchanek 
> ---
>  tools/testing/selftests/vm/virtual_address_range.c | 36 
> --
>  1 file changed, 27 insertions(+), 9 deletions(-)
> 
> diff --git a/tools/testing/selftests/vm/virtual_address_range.c 
> b/tools/testing/selftests/vm/virtual_address_range.c
> index 3b02aa6..ff6628f 100644
> --- a/tools/testing/selftests/vm/virtual_address_range.c
> +++ b/tools/testing/selftests/vm/virtual_address_range.c
> @@ -10,7 +10,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
> 
> @@ -32,15 +31,34 @@
>   * different areas one below 128TB and one above 128TB
>   * till it reaches 512TB. One with size 128TB and the
>   * other being 384TB.
> + *
> + * On Arm64 the address space is 256TB and no high mappings
> + * are supported so far. Presumably support can be added in
> + * the future.
>   */
> +
>  #define NR_CHUNKS_128TB   8192UL /* Number of 16GB chunks for 128TB */
> -#define NR_CHUNKS_384TB  24576UL /* Number of 16GB chunks for 384TB */
> +#define NR_CHUNKS_256TB   (NR_CHUNKS_128TB * 2UL)
> +#define NR_CHUNKS_384TB   (NR_CHUNKS_128TB * 3UL)
> 
>  #define ADDR_MARK_128TB  (1UL << 47) /* First address beyond 128TB */
> +#define ADDR_MARK_256TB  (1UL << 48) /* First address beyond 256TB */
> +
> +#ifdef __aarch64__
> +#define HIGH_ADDR_MARK  ADDR_MARK_256TB
> +#define HIGH_ADDR_SHIFT 49
> +#define NR_CHUNKS_LOW   NR_CHUNKS_256TB
> +#define NR_CHUNKS_HIGH  NR_CHUNKS_256TB
> +#else
> +#define HIGH_ADDR_MARK  ADDR_MARK_128TB
> +#define HIGH_ADDR_SHIFT 48
> +#define NR_CHUNKS_LOW   NR_CHUNKS_128TB
> +#define NR_CHUNKS_HIGH  NR_CHUNKS_384TB
> +#endif
> 
>  static char *hind_addr(void)
>  {
> - int bits = 48 + rand() % 15;
> + int bits = HIGH_ADDR_SHIFT + rand() % 15;

The randomization is upto 63 bits. Hence if HIGH_ADDR_SHIFT is 49
instead of 48 then it should be rand() % 14 in that case.

> 
>   return (char *) (1UL << bits);
>  }
> @@ -50,14 +68,14 @@ static int validate_addr(char *ptr, int high_addr)
>   unsigned long addr = (unsigned long) ptr;
> 
>   if (high_addr) {
> - if (addr < ADDR_MARK_128TB) {
> + if (addr < HIGH_ADDR_MARK) {
>   printf("Bad address %lx\n", addr);
>   return 1;
>   }
>   return 0;
>   }
> 
> - if (addr > ADDR_MARK_128TB) {
> + if (addr > HIGH_ADDR_MARK) {
>   printf("Bad address %lx\n", addr);
>   return 1;
>   }
> @@ -79,12 +97,12 @@ static int validate_lower_address_hint(void)
> 
>  int main(int argc, char *argv[])
>  {
> - char *ptr[NR_CHUNKS_128TB];
> - char *hptr[NR_CHUNKS_384TB];
> + char *ptr[NR_CHUNKS_LOW];
> + char *hptr[NR_CHUNKS_HIGH];
>   char *hint;
>   unsigned long i, lchunks, hchunks;
> 
> - for (i = 0; i < NR_CHUNKS_128TB; i++) {
> + for (i = 0; i < NR_CHUNKS_LOW; i++) {
>   ptr[i] = mmap(NULL, MAP_CHUNK_SIZE, PROT_READ | PROT_WRITE,
>   MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
> 
> @@ -99,7 +117,7 @@ int main(int argc, char *argv[])
>   }
>   lchunks = i;
> 
> - for (i = 0; i < NR_CHUNKS_384TB; i++) {
> + for (i = 0; i < NR_CHUNKS_HIGH; i++) {

If ARM64 does not have address space beyond 256TB, all map requests
beyond 256TB (which is being attempted in this second for loop) will
fail. But does the arch support the hint based mechanism like powerpc
and x86 to allocate beyond certain point ? The split in the allocation
(represented by two for loops) is because of the fact that below
HIGH_ADDR_MARK hint is not required and its required above it till
the end of the total VA space. In this case,

> +#define HIGH_ADDR_MARK  ADDR_MARK_256TB
> +#define HIGH_ADDR_SHIFT 49
> +#define NR_CHUNKS_LOW   NR_CHUNKS_256TB
> +#define NR_CHUNKS_HIGH  NR_CHUNKS_256TB

both the for loops will be attempting below 256TB one with and one
without the hint mechanism. But all the validations will fail
for the second for loop (where hint will be passed beyond 256TB)
as the address will not be allocated beyond 256TB where it is
capped.

Re: [PATCH] selftests/vm: Fix test for virtual address range mapping for arm64

[Anshuman Khandual]

On 05/10/2017 12:30 AM, Michal Suchanek wrote:
> Arm64 has 256TB address space so fix the test to pass on Arm as well.
> 
> Also remove unneeded numaif include.
> 
> Signed-off-by: Michal Suchanek 
> ---
>  tools/testing/selftests/vm/virtual_address_range.c | 36 
> --
>  1 file changed, 27 insertions(+), 9 deletions(-)
> 
> diff --git a/tools/testing/selftests/vm/virtual_address_range.c 
> b/tools/testing/selftests/vm/virtual_address_range.c
> index 3b02aa6..ff6628f 100644
> --- a/tools/testing/selftests/vm/virtual_address_range.c
> +++ b/tools/testing/selftests/vm/virtual_address_range.c
> @@ -10,7 +10,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
> 
> @@ -32,15 +31,34 @@
>   * different areas one below 128TB and one above 128TB
>   * till it reaches 512TB. One with size 128TB and the
>   * other being 384TB.
> + *
> + * On Arm64 the address space is 256TB and no high mappings
> + * are supported so far. Presumably support can be added in
> + * the future.
>   */
> +
>  #define NR_CHUNKS_128TB   8192UL /* Number of 16GB chunks for 128TB */
> -#define NR_CHUNKS_384TB  24576UL /* Number of 16GB chunks for 384TB */
> +#define NR_CHUNKS_256TB   (NR_CHUNKS_128TB * 2UL)
> +#define NR_CHUNKS_384TB   (NR_CHUNKS_128TB * 3UL)
> 
>  #define ADDR_MARK_128TB  (1UL << 47) /* First address beyond 128TB */
> +#define ADDR_MARK_256TB  (1UL << 48) /* First address beyond 256TB */
> +
> +#ifdef __aarch64__
> +#define HIGH_ADDR_MARK  ADDR_MARK_256TB
> +#define HIGH_ADDR_SHIFT 49
> +#define NR_CHUNKS_LOW   NR_CHUNKS_256TB
> +#define NR_CHUNKS_HIGH  NR_CHUNKS_256TB
> +#else
> +#define HIGH_ADDR_MARK  ADDR_MARK_128TB
> +#define HIGH_ADDR_SHIFT 48
> +#define NR_CHUNKS_LOW   NR_CHUNKS_128TB
> +#define NR_CHUNKS_HIGH  NR_CHUNKS_384TB
> +#endif
> 
>  static char *hind_addr(void)
>  {
> - int bits = 48 + rand() % 15;
> + int bits = HIGH_ADDR_SHIFT + rand() % 15;

The randomization is upto 63 bits. Hence if HIGH_ADDR_SHIFT is 49
instead of 48 then it should be rand() % 14 in that case.

> 
>   return (char *) (1UL << bits);
>  }
> @@ -50,14 +68,14 @@ static int validate_addr(char *ptr, int high_addr)
>   unsigned long addr = (unsigned long) ptr;
> 
>   if (high_addr) {
> - if (addr < ADDR_MARK_128TB) {
> + if (addr < HIGH_ADDR_MARK) {
>   printf("Bad address %lx\n", addr);
>   return 1;
>   }
>   return 0;
>   }
> 
> - if (addr > ADDR_MARK_128TB) {
> + if (addr > HIGH_ADDR_MARK) {
>   printf("Bad address %lx\n", addr);
>   return 1;
>   }
> @@ -79,12 +97,12 @@ static int validate_lower_address_hint(void)
> 
>  int main(int argc, char *argv[])
>  {
> - char *ptr[NR_CHUNKS_128TB];
> - char *hptr[NR_CHUNKS_384TB];
> + char *ptr[NR_CHUNKS_LOW];
> + char *hptr[NR_CHUNKS_HIGH];
>   char *hint;
>   unsigned long i, lchunks, hchunks;
> 
> - for (i = 0; i < NR_CHUNKS_128TB; i++) {
> + for (i = 0; i < NR_CHUNKS_LOW; i++) {
>   ptr[i] = mmap(NULL, MAP_CHUNK_SIZE, PROT_READ | PROT_WRITE,
>   MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
> 
> @@ -99,7 +117,7 @@ int main(int argc, char *argv[])
>   }
>   lchunks = i;
> 
> - for (i = 0; i < NR_CHUNKS_384TB; i++) {
> + for (i = 0; i < NR_CHUNKS_HIGH; i++) {

If ARM64 does not have address space beyond 256TB, all map requests
beyond 256TB (which is being attempted in this second for loop) will
fail. But does the arch support the hint based mechanism like powerpc
and x86 to allocate beyond certain point ? The split in the allocation
(represented by two for loops) is because of the fact that below
HIGH_ADDR_MARK hint is not required and its required above it till
the end of the total VA space. In this case,

> +#define HIGH_ADDR_MARK  ADDR_MARK_256TB
> +#define HIGH_ADDR_SHIFT 49
> +#define NR_CHUNKS_LOW   NR_CHUNKS_256TB
> +#define NR_CHUNKS_HIGH  NR_CHUNKS_256TB

both the for loops will be attempting below 256TB one with and one
without the hint mechanism. But all the validations will fail
for the second for loop (where hint will be passed beyond 256TB)
as the address will not be allocated beyond 256TB where it is
capped.

Re: linux-next: build warning after merge of the akpm-current tree

[Xunlei Pang]

On 05/15/2017 at 09:56 AM, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> In file included from include/asm-generic/bug.h:15:0,
>  from arch/arm/include/asm/bug.h:59,
>  from include/linux/bug.h:4,
>  from include/linux/elfcore.h:5,
>  from include/linux/crash_core.h:5,
>  from kernel/crash_core.c:9:
> kernel/crash_core.c: In function 'vmcoreinfo_append_str':
> include/linux/kernel.h:757:16: warning: comparison of distinct pointer types 
> lacks a cast
>   (void) ( == );   \
> ^
> include/linux/kernel.h:760:2: note: in expansion of macro '__min'
>   __min(typeof(x), typeof(y),   \
>   ^
> kernel/crash_core.c:360:6: note: in expansion of macro 'min'
>   r = min(r, VMCOREINFO_BYTES - vmcoreinfo_size);
>   ^
>
> Introduced by commit
>
>   fc7d2b44367f ("powerpc/fadump: use the correct VMCOREINFO_NOTE_SIZE for 
> phdr")
>

Hi Stephen/Andrew,

Sorry for the trouble.

The following patch will fix it, do you want to me to send it out separately? 
or help merge it into
fc7d2b44367f ("powerpc/fadump: use the correct VMCOREINFO_NOTE_SIZE for phdr") 
directly?

Thanks,
Xunlei

===

From: Xunlei Pang 
Subject: [PATCH] crash: Fix build warning

linux-next build (arm multi_v7_defconfig) produced this warning:

In file included from include/asm-generic/bug.h:15:0,
 from arch/arm/include/asm/bug.h:59,
 from include/linux/bug.h:4,
 from include/linux/elfcore.h:5,
 from include/linux/crash_core.h:5,
 from kernel/crash_core.c:9:
kernel/crash_core.c: In function 'vmcoreinfo_append_str':
include/linux/kernel.h:757:16: warning: comparison of distinct pointer
types lacks a cast
  (void) ( == );   \
^
include/linux/kernel.h:760:2: note: in expansion of macro '__min'
  __min(typeof(x), typeof(y),   \
  ^
kernel/crash_core.c:360:6: note: in expansion of macro 'min'
  r = min(r, VMCOREINFO_BYTES - vmcoreinfo_size);
  ^

This patch fixes it.

Signed-off-by: Xunlei Pang 
---
 kernel/crash_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index 4a4a4ba..6db80fc 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -357,7 +357,7 @@ void vmcoreinfo_append_str(const char *fmt, ...)
 r = vscnprintf(buf, sizeof(buf), fmt, args);
 va_end(args);
 
-r = min(r, VMCOREINFO_BYTES - vmcoreinfo_size);
+r = min(r, (size_t)VMCOREINFO_BYTES - vmcoreinfo_size);
 
 memcpy(_data[vmcoreinfo_size], buf, r);
 
-- 
1.8.3.1

Re: linux-next: build warning after merge of the akpm-current tree

[Xunlei Pang]

On 05/15/2017 at 09:56 AM, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> In file included from include/asm-generic/bug.h:15:0,
>  from arch/arm/include/asm/bug.h:59,
>  from include/linux/bug.h:4,
>  from include/linux/elfcore.h:5,
>  from include/linux/crash_core.h:5,
>  from kernel/crash_core.c:9:
> kernel/crash_core.c: In function 'vmcoreinfo_append_str':
> include/linux/kernel.h:757:16: warning: comparison of distinct pointer types 
> lacks a cast
>   (void) ( == );   \
> ^
> include/linux/kernel.h:760:2: note: in expansion of macro '__min'
>   __min(typeof(x), typeof(y),   \
>   ^
> kernel/crash_core.c:360:6: note: in expansion of macro 'min'
>   r = min(r, VMCOREINFO_BYTES - vmcoreinfo_size);
>   ^
>
> Introduced by commit
>
>   fc7d2b44367f ("powerpc/fadump: use the correct VMCOREINFO_NOTE_SIZE for 
> phdr")
>

Hi Stephen/Andrew,

Sorry for the trouble.

The following patch will fix it, do you want to me to send it out separately? 
or help merge it into
fc7d2b44367f ("powerpc/fadump: use the correct VMCOREINFO_NOTE_SIZE for phdr") 
directly?

Thanks,
Xunlei

===

From: Xunlei Pang 
Subject: [PATCH] crash: Fix build warning

linux-next build (arm multi_v7_defconfig) produced this warning:

In file included from include/asm-generic/bug.h:15:0,
 from arch/arm/include/asm/bug.h:59,
 from include/linux/bug.h:4,
 from include/linux/elfcore.h:5,
 from include/linux/crash_core.h:5,
 from kernel/crash_core.c:9:
kernel/crash_core.c: In function 'vmcoreinfo_append_str':
include/linux/kernel.h:757:16: warning: comparison of distinct pointer
types lacks a cast
  (void) ( == );   \
^
include/linux/kernel.h:760:2: note: in expansion of macro '__min'
  __min(typeof(x), typeof(y),   \
  ^
kernel/crash_core.c:360:6: note: in expansion of macro 'min'
  r = min(r, VMCOREINFO_BYTES - vmcoreinfo_size);
  ^

This patch fixes it.

Signed-off-by: Xunlei Pang 
---
 kernel/crash_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index 4a4a4ba..6db80fc 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -357,7 +357,7 @@ void vmcoreinfo_append_str(const char *fmt, ...)
 r = vscnprintf(buf, sizeof(buf), fmt, args);
 va_end(args);
 
-r = min(r, VMCOREINFO_BYTES - vmcoreinfo_size);
+r = min(r, (size_t)VMCOREINFO_BYTES - vmcoreinfo_size);
 
 memcpy(_data[vmcoreinfo_size], buf, r);
 
-- 
1.8.3.1

Re: [PATCH v7 0/7] Introduce ZONE_CMA

[Joonsoo Kim]

On Fri, May 12, 2017 at 08:38:15AM +0200, Michal Hocko wrote:
> On Fri 12-05-17 11:00:48, Joonsoo Kim wrote:
> > On Thu, May 11, 2017 at 11:13:04AM +0200, Michal Hocko wrote:
> > > On Thu 11-05-17 11:12:43, Joonsoo Kim wrote:
> > > > Sorry for the late response. I was on a vacation.
> > > > 
> > > > On Tue, May 02, 2017 at 03:32:29PM +0200, Michal Hocko wrote:
> > > > > On Tue 02-05-17 13:01:32, Joonsoo Kim wrote:
> > > > > > On Thu, Apr 27, 2017 at 05:06:36PM +0200, Michal Hocko wrote:
> > > > > [...]
> > > > > > > I see this point and I agree that using a specific zone might be a
> > > > > > > _nicer_ solution in the end but you have to consider another 
> > > > > > > aspects as
> > > > > > > well. The main one I am worried about is a long term 
> > > > > > > maintainability.
> > > > > > > We are really out of page flags and consuming one for a rather 
> > > > > > > specific
> > > > > > > usecase is not good. Look at ZONE_DMA. I am pretty sure that 
> > > > > > > almost
> > > > > > > no sane HW needs 16MB zone anymore, yet we have hard time to get 
> > > > > > > rid
> > > > > > > of it and so we have that memory laying around unused all the time
> > > > > > > and blocking one page flag bit. CMA falls into a similar category
> > > > > > > AFAIU. I wouldn't be all that surprised if a future HW will not 
> > > > > > > need CMA
> > > > > > > allocations in few years, yet we will have to fight to get rid of 
> > > > > > > it
> > > > > > > like we do with ZONE_DMA. And not only that. We will also have to 
> > > > > > > fight
> > > > > > > finding page flags for other more general usecases in the 
> > > > > > > meantime.
> > > > > > 
> > > > > > This maintenance problem is inherent. This problem exists even if we
> > > > > > uses MIGRATETYPE approach. We cannot remove many hooks for CMA if a
> > > > > > future HW will not need CMA allocation in few years. The only
> > > > > > difference is that one takes single zone bit only for CMA user and 
> > > > > > the
> > > > > > other approach takes many hooks that we need to take care about it 
> > > > > > all
> > > > > > the time.
> > > > > 
> > > > > And I consider this a big difference. Because while hooks are not nice
> > > > > they will affect CMA users (in a sense of bugs/performance etc.). 
> > > > > While
> > > > > an additional bit consumed will affect potential future and more 
> > > > > generic
> > > > > features.
> > > > 
> > > > Because these hooks are so tricky and are spread on many places,
> > > > bugs about these hooks can be made by *non-CMA* user and they hurt
> > > > *CMA* user. These hooks could also delay non-CMA user's development 
> > > > speed
> > > > since there are many hooks about CMA and understanding how CMA is 
> > > > managed
> > > > is rather difficult.
> > > 
> > > Than make those hooks easier to maintain. Seriously this is a
> > > non-argument.
> > 
> > I can't understand what you said here. 
> 
> I wanted to say that you can make those hooks so non-intrusive that
> nobody outside of the CMA has to even care that CMA exists.

I guess that current code is the result of such effort and it would be
intrusive.

> 
> > With zone approach, someone who
> > isn't related to CMA don't need to understand how CMA is managed.
> > 
> > > 
> > > [...]
> > > 
> > > > > And all this can be isolated to CMA specific hooks with mostly minimum
> > > > > impact to most users. I hear you saying that zone approach is more 
> > > > > natural
> > > > > and I would agree if we wouldn't have to care about the number of 
> > > > > zones.
> > > > 
> > > > I attach a solution about one more bit in page flags although I don't
> > > > agree with your opinion that additional bit is no-go approach. Just
> > > > note that we have already used three bits for zone encoding in some
> > > > configuration due to ZONE_DEVICE.
> > > 
> > > I am absolutely not happy about ZONE_DEVICE but there is _no_ other
> > > viable solution right now. I know that people behind this are still
> > > considering struct page over direct pfn usage but they are not in the
> > > same situation as CMA which _can_ work without additional zone.
> > 
> > IIUC, ZONE_DEVICE can reuse the other zone and migratetype.
> 
> They are not going to migrate anything or define any allocation fallback
> policy because those pages are outside of the page allocator completely.
> And that is why a zone approach is a reasonable approach. There are
> probably other ways and I will certainly push going that way.

I have a different opinion but it's not a main issue here so I don't
argue anymore.

> [...]
> 
> > > If you _really_ insist on using zone for CMA then reuse ZONE_MOVABLE.
> > > I absolutely miss why do you push a specialized zone so hard.
> > 
> > As I said before, there is no fundamental issue to reuse ZONE_MOVABLE.
> > I just don't want to reuse it because they have a different
> > characteristic. In MM subsystem context, their characteristic is the same.
> > However, CMA memory should be used for the 

Re: [PATCH v7 0/7] Introduce ZONE_CMA

[Joonsoo Kim]

On Fri, May 12, 2017 at 08:38:15AM +0200, Michal Hocko wrote:
> On Fri 12-05-17 11:00:48, Joonsoo Kim wrote:
> > On Thu, May 11, 2017 at 11:13:04AM +0200, Michal Hocko wrote:
> > > On Thu 11-05-17 11:12:43, Joonsoo Kim wrote:
> > > > Sorry for the late response. I was on a vacation.
> > > > 
> > > > On Tue, May 02, 2017 at 03:32:29PM +0200, Michal Hocko wrote:
> > > > > On Tue 02-05-17 13:01:32, Joonsoo Kim wrote:
> > > > > > On Thu, Apr 27, 2017 at 05:06:36PM +0200, Michal Hocko wrote:
> > > > > [...]
> > > > > > > I see this point and I agree that using a specific zone might be a
> > > > > > > _nicer_ solution in the end but you have to consider another 
> > > > > > > aspects as
> > > > > > > well. The main one I am worried about is a long term 
> > > > > > > maintainability.
> > > > > > > We are really out of page flags and consuming one for a rather 
> > > > > > > specific
> > > > > > > usecase is not good. Look at ZONE_DMA. I am pretty sure that 
> > > > > > > almost
> > > > > > > no sane HW needs 16MB zone anymore, yet we have hard time to get 
> > > > > > > rid
> > > > > > > of it and so we have that memory laying around unused all the time
> > > > > > > and blocking one page flag bit. CMA falls into a similar category
> > > > > > > AFAIU. I wouldn't be all that surprised if a future HW will not 
> > > > > > > need CMA
> > > > > > > allocations in few years, yet we will have to fight to get rid of 
> > > > > > > it
> > > > > > > like we do with ZONE_DMA. And not only that. We will also have to 
> > > > > > > fight
> > > > > > > finding page flags for other more general usecases in the 
> > > > > > > meantime.
> > > > > > 
> > > > > > This maintenance problem is inherent. This problem exists even if we
> > > > > > uses MIGRATETYPE approach. We cannot remove many hooks for CMA if a
> > > > > > future HW will not need CMA allocation in few years. The only
> > > > > > difference is that one takes single zone bit only for CMA user and 
> > > > > > the
> > > > > > other approach takes many hooks that we need to take care about it 
> > > > > > all
> > > > > > the time.
> > > > > 
> > > > > And I consider this a big difference. Because while hooks are not nice
> > > > > they will affect CMA users (in a sense of bugs/performance etc.). 
> > > > > While
> > > > > an additional bit consumed will affect potential future and more 
> > > > > generic
> > > > > features.
> > > > 
> > > > Because these hooks are so tricky and are spread on many places,
> > > > bugs about these hooks can be made by *non-CMA* user and they hurt
> > > > *CMA* user. These hooks could also delay non-CMA user's development 
> > > > speed
> > > > since there are many hooks about CMA and understanding how CMA is 
> > > > managed
> > > > is rather difficult.
> > > 
> > > Than make those hooks easier to maintain. Seriously this is a
> > > non-argument.
> > 
> > I can't understand what you said here. 
> 
> I wanted to say that you can make those hooks so non-intrusive that
> nobody outside of the CMA has to even care that CMA exists.

I guess that current code is the result of such effort and it would be
intrusive.

> 
> > With zone approach, someone who
> > isn't related to CMA don't need to understand how CMA is managed.
> > 
> > > 
> > > [...]
> > > 
> > > > > And all this can be isolated to CMA specific hooks with mostly minimum
> > > > > impact to most users. I hear you saying that zone approach is more 
> > > > > natural
> > > > > and I would agree if we wouldn't have to care about the number of 
> > > > > zones.
> > > > 
> > > > I attach a solution about one more bit in page flags although I don't
> > > > agree with your opinion that additional bit is no-go approach. Just
> > > > note that we have already used three bits for zone encoding in some
> > > > configuration due to ZONE_DEVICE.
> > > 
> > > I am absolutely not happy about ZONE_DEVICE but there is _no_ other
> > > viable solution right now. I know that people behind this are still
> > > considering struct page over direct pfn usage but they are not in the
> > > same situation as CMA which _can_ work without additional zone.
> > 
> > IIUC, ZONE_DEVICE can reuse the other zone and migratetype.
> 
> They are not going to migrate anything or define any allocation fallback
> policy because those pages are outside of the page allocator completely.
> And that is why a zone approach is a reasonable approach. There are
> probably other ways and I will certainly push going that way.

I have a different opinion but it's not a main issue here so I don't
argue anymore.

> [...]
> 
> > > If you _really_ insist on using zone for CMA then reuse ZONE_MOVABLE.
> > > I absolutely miss why do you push a specialized zone so hard.
> > 
> > As I said before, there is no fundamental issue to reuse ZONE_MOVABLE.
> > I just don't want to reuse it because they have a different
> > characteristic. In MM subsystem context, their characteristic is the same.
> > However, CMA memory should be used for the 

Re: [PATCH v2 2/3] sched/deadline: Throttle the task when missing its deadline

[Xunlei Pang]

On 05/13/2017 at 04:58 AM, luca abeni wrote:
> On Fri, 12 May 2017 15:19:55 +0800
> Xunlei Pang  wrote:
> [...]
  "As seen, enforcing that the total utilization is smaller than M
 does not guarantee that global EDF schedules the tasks without
 missing any deadline (in other words, global EDF is not an optimal
 scheduling algorithm). However, a total utilization smaller than M
 is enough to guarantee that non real-time tasks are not starved
 and that the tardiness of real-time tasks has an upper bound[12]
 (as previously noted). Different bounds on the maximum tardiness
 experienced by real-time tasks have been developed in various
 papers[13,14], but the theoretical result that is important for
 SCHED_DEADLINE is that if the total utilization is smaller or equal
 than M then the response times of the tasks are limited."

 Do you mean there is some tardiness allowed in theory(global EDF is
 not an optimal scheduling algorithm), thus missed deadline is
 allowed for global EDF?  
>>> Right.
>>>
>>> With the admission test currently used by the kernel (sum of
>>> utilizations <= 1), tasks are guaranteed to have a tardiness smaller
>>> than a theoretical maximum... But this theoretical maximum can be
>>> larger than 0.
>>>
>>> If you want to strictly respect all of the deadlines, you need a
>>> stricter admission test (for example, the one based on WCET_max
>>> that is mentioned above).  
>> Understood.
>>
>> I think in Patch 3, it is still worthy to add the accounting in
>> dl_runtime_exceeded(), to track the dl scheduling tardiness(after all
>> tardiness is not a good thing) like: if
>> (dl_time_before(dl_se->deadline, rq_clock(rq)) && dl_se->runtime > 0)
>> ++dl_se->nr_underrun_sched;
>>
>> Maybe changing the name to use "nr_underrun_tardy" is better, large
>> value does need our attention. What do you think?
> I do not know, I never used statistics like these...
>
> If there are enough people having a good usecase for these statistics,
> it might be worth adding them, but I do not know other people's
> opinions about this.
>

Hi Luca,

Thanks for the feedback.

I think I can defer the statistics patch after Daniel's "sched/deadline: Use the
revised wakeup rule for suspending constrained dl tasks", since there will
be another underrun case in the fix, let's wait for other's opinions then.

Regards,
Xunlei

Re: [PATCH v2 2/3] sched/deadline: Throttle the task when missing its deadline

[Xunlei Pang]

On 05/13/2017 at 04:58 AM, luca abeni wrote:
> On Fri, 12 May 2017 15:19:55 +0800
> Xunlei Pang  wrote:
> [...]
  "As seen, enforcing that the total utilization is smaller than M
 does not guarantee that global EDF schedules the tasks without
 missing any deadline (in other words, global EDF is not an optimal
 scheduling algorithm). However, a total utilization smaller than M
 is enough to guarantee that non real-time tasks are not starved
 and that the tardiness of real-time tasks has an upper bound[12]
 (as previously noted). Different bounds on the maximum tardiness
 experienced by real-time tasks have been developed in various
 papers[13,14], but the theoretical result that is important for
 SCHED_DEADLINE is that if the total utilization is smaller or equal
 than M then the response times of the tasks are limited."

 Do you mean there is some tardiness allowed in theory(global EDF is
 not an optimal scheduling algorithm), thus missed deadline is
 allowed for global EDF?  
>>> Right.
>>>
>>> With the admission test currently used by the kernel (sum of
>>> utilizations <= 1), tasks are guaranteed to have a tardiness smaller
>>> than a theoretical maximum... But this theoretical maximum can be
>>> larger than 0.
>>>
>>> If you want to strictly respect all of the deadlines, you need a
>>> stricter admission test (for example, the one based on WCET_max
>>> that is mentioned above).  
>> Understood.
>>
>> I think in Patch 3, it is still worthy to add the accounting in
>> dl_runtime_exceeded(), to track the dl scheduling tardiness(after all
>> tardiness is not a good thing) like: if
>> (dl_time_before(dl_se->deadline, rq_clock(rq)) && dl_se->runtime > 0)
>> ++dl_se->nr_underrun_sched;
>>
>> Maybe changing the name to use "nr_underrun_tardy" is better, large
>> value does need our attention. What do you think?
> I do not know, I never used statistics like these...
>
> If there are enough people having a good usecase for these statistics,
> it might be worth adding them, but I do not know other people's
> opinions about this.
>

Hi Luca,

Thanks for the feedback.

I think I can defer the statistics patch after Daniel's "sched/deadline: Use the
revised wakeup rule for suspending constrained dl tasks", since there will
be another underrun case in the fix, let's wait for other's opinions then.

Regards,
Xunlei

RE: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

[Chen, Xiaoguang]

Hi Alex and Gerd,

>-Original Message-
>From: Alex Williamson [mailto:alex.william...@redhat.com]
>Sent: Saturday, May 13, 2017 12:38 AM
>To: Gerd Hoffmann 
>Cc: Chen, Xiaoguang ; Tian, Kevin
>; intel-...@lists.freedesktop.org; linux-
>ker...@vger.kernel.org; zhen...@linux.intel.com; Lv, Zhiyuan
>; intel-gvt-...@lists.freedesktop.org; Wang, Zhi A
>
>Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
>
>On Fri, 12 May 2017 11:12:05 +0200
>Gerd Hoffmann  wrote:
>
>>   Hi,
>>
>> > If the contents of the framebuffer change or if the parameters of
>> > the framebuffer change?  I can't image that creating a new dmabuf fd
>> > for every visual change within the framebuffer would be efficient,
>> > but I don't have any concept of what a dmabuf actually does.
>>
>> Ok, some background:
>>
>> The drm subsystem has the concept of planes.  The most important plane
>> is the primary framebuffer (i.e. what gets scanned out to the physical
>> display).  The cursor is a plane too, and there can be additional
>> overlay planes for stuff like video playback.
>>
>> Typically there are multiple planes in a system and only one of them
>> gets scanned out to the crtc, i.e. the fbdev emulation creates one
>> plane for the framebuffer console.  The X-Server creates a plane too,
>> and when you switch between X-Server and framebuffer console via
>> ctrl-alt-fn the intel driver just reprograms the encoder to scan out
>> the one or the other plane to the crtc.
>>
>> The dma-buf handed out by gvt is a reference to a plane.  I think on
>> the host side gvt can see only the active plane (from encoder/crtc
>> register
>> programming) not the inactive ones.
>>
>> The dma-buf can be imported as opengl texture and then be used to
>> render the guest display to a host window.  I think it is even
>> possible to use the dma-buf as plane in the host drm driver and scan
>> it out directly to a physical display.  The actual framebuffer content
>> stays in gpu memory all the time, the cpu never has to touch it.
>>
>> It is possible to cache the dma-buf handles, i.e. when the guest boots
>> you'll get the first for the fbcon plane, when the x-server starts the
>> second for the x-server framebuffer, and when the user switches to the
>> text console via ctrl-alt-fn you can re-use the fbcon dma-buf you
>> already have.
>>
>> The caching becomes more important for good performance when the guest
>> uses pageflipping (wayland does): define two planes, render into one
>> while displaying the other, then flip the two for a atomic display
>> update.
>>
>> The caching also makes it a bit difficult to create a good interface.
>> So, the current patch set creates:
>>
>>   (a) A way to query the active planes (ioctl
>>   INTEL_VGPU_QUERY_DMABUF added by patch 5/6 of this series).
>>   (b) A way to create a dma-buf for the active plane (ioctl
>>   INTEL_VGPU_GENERATE_DMABUF).
>>
>> Typical userspace workflow is to first query the plane, then check if
>> it already has a dma-buf for it, and if not create one.
>
>Thank you!  This is immensely helpful!
>
>> > What changes to the framebuffer require a new dmabuf fd?  Shouldn't
>> > the user query the parameters of the framebuffer through a dmabuf fd
>> > and shouldn't the dmabuf fd have some signaling mechanism to the
>> > user (eventfd perhaps) to notify the user to re-evaluate the parameters?
>>
>> dma-bufs don't support that, they are really just a handle to a piece
>> of memory, all metadata (format, size) most be communicated by other means.
>>
>> > Otherwise are you imagining that the user polls the vfio region?
>>
>> Hmm, notification support would probably a good reason to have a
>> separate file handle to manage the dma-bufs (instead of using
>> driver-specific ioctls on the vfio fd), because the driver could also
>> use the management fd for notifications then.
>
>I like this idea of a separate control fd for dmabufs, it provides not only a 
>central
>management point, but also a nice abstraction for the vfio device specific
>interface.  We potentially only need a single
>VFIO_DEVICE_GET_DMABUF_MGR_FD() ioctl to get a dmabuf management fd
>(perhaps with a type parameter, ex. GFX) where maybe we could have vfio-core
>incorporate this reference into the group lifecycle, so the vendor driver only
>needs to fdget/put this manager fd for the various plane dmabuf fds spawned in
>order to get core-level reference counting.
Following is my understanding of the management fd idea:
1) QEMU will call VFIO_DEVICE_GET_DMABUF_MGR_FD() ioctl to create a fd and 
saved the fd in vfio group while initializing the vfio.
2) vendor driver use fdget to add reference count of the fd.
3) vendor driver use ioctl to the fd to query plane information or create 
dma-buf fd.
4) vendor driver use fdput when finished using this fd.

Is my understanding right?

Both 

RE: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

[Chen, Xiaoguang]

Hi Alex and Gerd,

>-Original Message-
>From: Alex Williamson [mailto:alex.william...@redhat.com]
>Sent: Saturday, May 13, 2017 12:38 AM
>To: Gerd Hoffmann 
>Cc: Chen, Xiaoguang ; Tian, Kevin
>; intel-...@lists.freedesktop.org; linux-
>ker...@vger.kernel.org; zhen...@linux.intel.com; Lv, Zhiyuan
>; intel-gvt-...@lists.freedesktop.org; Wang, Zhi A
>
>Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
>
>On Fri, 12 May 2017 11:12:05 +0200
>Gerd Hoffmann  wrote:
>
>>   Hi,
>>
>> > If the contents of the framebuffer change or if the parameters of
>> > the framebuffer change?  I can't image that creating a new dmabuf fd
>> > for every visual change within the framebuffer would be efficient,
>> > but I don't have any concept of what a dmabuf actually does.
>>
>> Ok, some background:
>>
>> The drm subsystem has the concept of planes.  The most important plane
>> is the primary framebuffer (i.e. what gets scanned out to the physical
>> display).  The cursor is a plane too, and there can be additional
>> overlay planes for stuff like video playback.
>>
>> Typically there are multiple planes in a system and only one of them
>> gets scanned out to the crtc, i.e. the fbdev emulation creates one
>> plane for the framebuffer console.  The X-Server creates a plane too,
>> and when you switch between X-Server and framebuffer console via
>> ctrl-alt-fn the intel driver just reprograms the encoder to scan out
>> the one or the other plane to the crtc.
>>
>> The dma-buf handed out by gvt is a reference to a plane.  I think on
>> the host side gvt can see only the active plane (from encoder/crtc
>> register
>> programming) not the inactive ones.
>>
>> The dma-buf can be imported as opengl texture and then be used to
>> render the guest display to a host window.  I think it is even
>> possible to use the dma-buf as plane in the host drm driver and scan
>> it out directly to a physical display.  The actual framebuffer content
>> stays in gpu memory all the time, the cpu never has to touch it.
>>
>> It is possible to cache the dma-buf handles, i.e. when the guest boots
>> you'll get the first for the fbcon plane, when the x-server starts the
>> second for the x-server framebuffer, and when the user switches to the
>> text console via ctrl-alt-fn you can re-use the fbcon dma-buf you
>> already have.
>>
>> The caching becomes more important for good performance when the guest
>> uses pageflipping (wayland does): define two planes, render into one
>> while displaying the other, then flip the two for a atomic display
>> update.
>>
>> The caching also makes it a bit difficult to create a good interface.
>> So, the current patch set creates:
>>
>>   (a) A way to query the active planes (ioctl
>>   INTEL_VGPU_QUERY_DMABUF added by patch 5/6 of this series).
>>   (b) A way to create a dma-buf for the active plane (ioctl
>>   INTEL_VGPU_GENERATE_DMABUF).
>>
>> Typical userspace workflow is to first query the plane, then check if
>> it already has a dma-buf for it, and if not create one.
>
>Thank you!  This is immensely helpful!
>
>> > What changes to the framebuffer require a new dmabuf fd?  Shouldn't
>> > the user query the parameters of the framebuffer through a dmabuf fd
>> > and shouldn't the dmabuf fd have some signaling mechanism to the
>> > user (eventfd perhaps) to notify the user to re-evaluate the parameters?
>>
>> dma-bufs don't support that, they are really just a handle to a piece
>> of memory, all metadata (format, size) most be communicated by other means.
>>
>> > Otherwise are you imagining that the user polls the vfio region?
>>
>> Hmm, notification support would probably a good reason to have a
>> separate file handle to manage the dma-bufs (instead of using
>> driver-specific ioctls on the vfio fd), because the driver could also
>> use the management fd for notifications then.
>
>I like this idea of a separate control fd for dmabufs, it provides not only a 
>central
>management point, but also a nice abstraction for the vfio device specific
>interface.  We potentially only need a single
>VFIO_DEVICE_GET_DMABUF_MGR_FD() ioctl to get a dmabuf management fd
>(perhaps with a type parameter, ex. GFX) where maybe we could have vfio-core
>incorporate this reference into the group lifecycle, so the vendor driver only
>needs to fdget/put this manager fd for the various plane dmabuf fds spawned in
>order to get core-level reference counting.
Following is my understanding of the management fd idea:
1) QEMU will call VFIO_DEVICE_GET_DMABUF_MGR_FD() ioctl to create a fd and 
saved the fd in vfio group while initializing the vfio.
2) vendor driver use fdget to add reference count of the fd.
3) vendor driver use ioctl to the fd to query plane information or create 
dma-buf fd.
4) vendor driver use fdput when finished using this fd.

Is my understanding right?

Both QEMU and kernel vfio-core will have changes based on this proposal except 
the vendor part changes.
Who will make these changes?

Re: [PATCH 1/3] Fix ERROR: trailing statements should be on next line

[Alex Williamson]

On Mon, 15 May 2017 05:58:05 +0300
"Michael S. Tsirkin"  wrote:

> On Sun, May 14, 2017 at 07:51:28PM +0200, Maciek Fijalkowski wrote:
> > From: Maciej Fijalkowski 
> > 
> > Signed-off-by: Maciej Fijalkowski   
> 
> I prefer the original form - ; isn't a full statement.
> 
> > ---
> >  drivers/net/virtio_net.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > index 9320d96..f20dfb8 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -217,7 +217,8 @@ static void give_pages(struct receive_queue *rq, struct 
> > page *page)
> > struct page *end;
> >  
> > /* Find end of list, sew whole thing into vi->rq.pages. */
> > -   for (end = page; end->private; end = (struct page *)end->private);
> > +   for (end = page; end->private; end = (struct page *)end->private)
> > +   ;

FWIW, I generally like to put a comment on the next line to make it
abundantly clear that there's nothing in the body of the loop, it's
also more aesthetically pleasing than a semi-colon on the line by
itself, ex. /* Nothing */;  It's just too easy to misinterpret the
loop otherwise, especially without gratuitous white space.  Thanks,

Alex


> > end->private = (unsigned long)rq->pages;
> > rq->pages = page;
> >  }
> > -- 
> > 2.4.11  
> ___
> Virtualization mailing list
> virtualizat...@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 1/3] Fix ERROR: trailing statements should be on next line

[Alex Williamson]

On Mon, 15 May 2017 05:58:05 +0300
"Michael S. Tsirkin"  wrote:

> On Sun, May 14, 2017 at 07:51:28PM +0200, Maciek Fijalkowski wrote:
> > From: Maciej Fijalkowski 
> > 
> > Signed-off-by: Maciej Fijalkowski   
> 
> I prefer the original form - ; isn't a full statement.
> 
> > ---
> >  drivers/net/virtio_net.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > index 9320d96..f20dfb8 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -217,7 +217,8 @@ static void give_pages(struct receive_queue *rq, struct 
> > page *page)
> > struct page *end;
> >  
> > /* Find end of list, sew whole thing into vi->rq.pages. */
> > -   for (end = page; end->private; end = (struct page *)end->private);
> > +   for (end = page; end->private; end = (struct page *)end->private)
> > +   ;

FWIW, I generally like to put a comment on the next line to make it
abundantly clear that there's nothing in the body of the loop, it's
also more aesthetically pleasing than a semi-colon on the line by
itself, ex. /* Nothing */;  It's just too easy to misinterpret the
loop otherwise, especially without gratuitous white space.  Thanks,

Alex


> > end->private = (unsigned long)rq->pages;
> > rq->pages = page;
> >  }
> > -- 
> > 2.4.11  
> ___
> Virtualization mailing list
> virtualizat...@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH v4 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe

[Ryder Lee]

Add documentation for PCIe host driver available in MT7623
series SoCs.

Signed-off-by: Ryder Lee 
Acked-by: Rob Herring 
---
 .../bindings/pci/mediatek,mt7623-pcie.txt  | 130 +
 1 file changed, 130 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt

diff --git a/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt 
b/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
new file mode 100644
index 000..ae4a3f4
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
@@ -0,0 +1,130 @@
+Mediatek Gen2 PCIe controller which is available on MT7623 series SoCs
+
+PCIe subsys supports single root complex (RC) with 3 Root Ports. Each root
+ports supports a Gen2 1-lane Link and has PIPE interface to PHY.
+
+Required properties:
+- compatible: Should contain "mediatek,mt7623-pcie".
+- device_type: Must be "pci"
+- reg: Base addresses and lengths of the PCIe controller.
+- #address-cells: Address representation for root ports (must be 3)
+- #size-cells: Size representation for root ports (must be 2)
+- #interrupt-cells: Size representation for interrupts (must be 1)
+- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
+  Please refer to the standard PCI bus binding document for a more detailed
+  explanation.
+- clocks: Must contain an entry for each entry in clock-names.
+  See ../clocks/clock-bindings.txt for details.
+- clock-names: Must include the following entries:
+  - free_ck :for reference clock of PCIe subsys
+  - sys_ck0 :for clock of Port0
+  - sys_ck1 :for clock of Port1
+  - sys_ck2 :for clock of Port2
+- resets: Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names: Must include the following entries:
+  - pcie-rst0 :port0 reset
+  - pcie-rst1 :port1 reset
+  - pcie-rst2 :port2 reset
+- phys: List of PHY specifiers (used by generic PHY framework).
+- phy-names : Must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the
+  number of PHYs as specified in *phys* property.
+- power-domains: A phandle and power domain specifier pair to the power domain
+  which is responsible for collapsing and restoring power to the peripheral.
+- bus-range: Range of bus numbers associated with this controller.
+- ranges: Ranges for the PCI memory and I/O regions.
+
+In addition, the device tree node must have sub-nodes describing each
+PCIe port interface, having the following mandatory properties:
+
+Required properties:
+- device_type: Must be "pci"
+- reg: Only the first four bytes are used to refer to the correct bus number
+  and device number.
+- #address-cells: Must be 3
+- #size-cells: Must be 2
+- #interrupt-cells: Must be 1
+- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
+  Please refer to the standard PCI bus binding document for a more detailed
+  explanation.
+- ranges: Sub-ranges distributed from the PCIe controller node. An empty
+  property is sufficient.
+- num-lanes: Number of lanes to use for this port.
+
+Examples:
+
+   hifsys: syscon@1a00 {
+   compatible = "mediatek,mt7623-hifsys",
+"mediatek,mt2701-hifsys",
+"syscon";
+   reg = <0 0x1a00 0 0x1000>;
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   };
+
+   pcie: pcie-controller@1a14 {
+   compatible = "mediatek,mt7623-pcie";
+   device_type = "pci";
+   reg = <0 0x1a14 0 0x1000>, /* PCIe shared registers */
+ <0 0x1a142000 0 0x1000>, /* Port0 registers */
+ <0 0x1a143000 0 0x1000>, /* Port1 registers */
+ <0 0x1a144000 0 0x1000>; /* Port2 registers */
+   #address-cells = <3>;
+   #size-cells = <2>;
+   #interrupt-cells = <1>;
+   interrupt-map-mask = <0xf800 0 0 0>;
+   interrupt-map = <0x 0 0 0  GIC_SPI 193 
IRQ_TYPE_LEVEL_LOW>,
+   <0x0800 0 0 0  GIC_SPI 194 
IRQ_TYPE_LEVEL_LOW>,
+   <0x1000 0 0 0  GIC_SPI 195 
IRQ_TYPE_LEVEL_LOW>;
+   clocks = < CLK_TOP_ETHIF_SEL>,
+< CLK_HIFSYS_PCIE0>,
+< CLK_HIFSYS_PCIE1>,
+< CLK_HIFSYS_PCIE2>;
+   clock-names = "free_ck", "sys_ck0", "sys_ck1", "sys_ck2";
+   resets = < MT2701_HIFSYS_PCIE0_RST>,
+< MT2701_HIFSYS_PCIE1_RST>,
+< MT2701_HIFSYS_PCIE2_RST>;
+   reset-names = "pcie-rst0", "pcie-rst1", "pcie-rst2";
+   phys = <_phy>, <_phy>, <_phy>;
+   phy-names = "pcie-phy0", "pcie-phy1", "pcie-phy2";
+   power-domains = < MT2701_POWER_DOMAIN_HIF>;
+   bus-range = <0x00 0xff>;
+

Re: [PATCH v2 3/3] staging: iio: meter: Replace symbolic permissions with octal permissions.

[harinath Nampally]

Jonathan,

Thank you for letting me know. In future I will work on 'togreg' branch
of iio.git tree to send my patches.

Thanks,
Harinath

On Sun, May 14, 2017 at 11:29 AM, Jonathan Cameron  wrote:
> On 10/05/17 00:41, Harinath Nampally wrote:
>>
>> This patch fixes below kind of warnings:
>> WARNING: Symbolic permissions 'S_IXXX | S_IXXX' are not preferred.
>>
>> Below errors are false positives:
>> ade7753.c:382: ERROR: Use 4 digit octal (0777) not decimal permissions
>> ade7753.c:386: ERROR: Use 4 digit octal (0777) not decimal permissions
>>
>> Signed-off-by: Harinath Nampally 
>
> I've already taken a patch for this.
>
> For IIO patches (including for drivers in staging) please also
> check the iio.git tree and in particularly base the on the togreg branch
> of that unless you know something you need is in the testing branch
> (usually more recent) in which case use that.  This stuff all gets
> batched up every few weeks and sent as a pull request to Greg.
> Right now we have just ended a merge window so it's the longest gap
> that typically occurs in these going to Greg.
>
> Thanks,
>
> Jonathan
>
>> ---
>> Changes in v2:
>>   - None because only [PATCH v2 1/3] has improvement
>>
>>   drivers/staging/iio/meter/ade7753.c | 46
>> ++---
>>   1 file changed, 23 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/staging/iio/meter/ade7753.c
>> b/drivers/staging/iio/meter/ade7753.c
>> index 5d45a68..2534bd0 100644
>> --- a/drivers/staging/iio/meter/ade7753.c
>> +++ b/drivers/staging/iio/meter/ade7753.c
>> @@ -298,92 +298,92 @@ static IIO_DEV_ATTR_AENERGY(ade7753_read_24bit,
>> ADE7753_AENERGY);
>>   static IIO_DEV_ATTR_LAENERGY(ade7753_read_24bit, ADE7753_LAENERGY);
>>   static IIO_DEV_ATTR_VAENERGY(ade7753_read_24bit, ADE7753_VAENERGY);
>>   static IIO_DEV_ATTR_LVAENERGY(ade7753_read_24bit, ADE7753_LVAENERGY);
>> -static IIO_DEV_ATTR_CFDEN(S_IWUSR | S_IRUGO,
>> +static IIO_DEV_ATTR_CFDEN(0644,
>> ade7753_read_16bit,
>> ade7753_write_16bit,
>> ADE7753_CFDEN);
>> -static IIO_DEV_ATTR_CFNUM(S_IWUSR | S_IRUGO,
>> +static IIO_DEV_ATTR_CFNUM(0644,
>> ade7753_read_8bit,
>> ade7753_write_8bit,
>> ADE7753_CFNUM);
>>   static IIO_DEV_ATTR_CHKSUM(ade7753_read_8bit, ADE7753_CHKSUM);
>> -static IIO_DEV_ATTR_PHCAL(S_IWUSR | S_IRUGO,
>> +static IIO_DEV_ATTR_PHCAL(0644,
>> ade7753_read_16bit,
>> ade7753_write_16bit,
>> ADE7753_PHCAL);
>> -static IIO_DEV_ATTR_APOS(S_IWUSR | S_IRUGO,
>> +static IIO_DEV_ATTR_APOS(0644,
>> ade7753_read_16bit,
>> ade7753_write_16bit,
>> ADE7753_APOS);
>> -static IIO_DEV_ATTR_SAGCYC(S_IWUSR | S_IRUGO,
>> +static IIO_DEV_ATTR_SAGCYC(0644,
>> ade7753_read_8bit,
>> ade7753_write_8bit,
>> ADE7753_SAGCYC);
>> -static IIO_DEV_ATTR_SAGLVL(S_IWUSR | S_IRUGO,
>> +static IIO_DEV_ATTR_SAGLVL(0644,
>> ade7753_read_8bit,
>> ade7753_write_8bit,
>> ADE7753_SAGLVL);
>> -static IIO_DEV_ATTR_LINECYC(S_IWUSR | S_IRUGO,
>> +static IIO_DEV_ATTR_LINECYC(0644,
>> ade7753_read_8bit,
>> ade7753_write_8bit,
>> ADE7753_LINECYC);
>> -static IIO_DEV_ATTR_WDIV(S_IWUSR | S_IRUGO,
>> +static IIO_DEV_ATTR_WDIV(0644,
>> ade7753_read_8bit,
>> ade7753_write_8bit,
>> ADE7753_WDIV);
>> -static IIO_DEV_ATTR_IRMS(S_IWUSR | S_IRUGO,
>> +static IIO_DEV_ATTR_IRMS(0644,
>> ade7753_read_24bit,
>> NULL,
>> ADE7753_IRMS);
>> -static IIO_DEV_ATTR_VRMS(S_IRUGO,
>> +static IIO_DEV_ATTR_VRMS(0444,
>> ade7753_read_24bit,
>> NULL,
>> ADE7753_VRMS);
>> -static IIO_DEV_ATTR_IRMSOS(S_IWUSR | S_IRUGO,
>> +static IIO_DEV_ATTR_IRMSOS(0644,
>> ade7753_read_16bit,
>> ade7753_write_16bit,
>> ADE7753_IRMSOS);
>> -static IIO_DEV_ATTR_VRMSOS(S_IWUSR | S_IRUGO,
>> +static IIO_DEV_ATTR_VRMSOS(0644,
>> ade7753_read_16bit,
>> ade7753_write_16bit,
>> ADE7753_VRMSOS);
>> -static IIO_DEV_ATTR_WGAIN(S_IWUSR | S_IRUGO,
>> +static IIO_DEV_ATTR_WGAIN(0644,
>> ade7753_read_16bit,
>> ade7753_write_16bit,
>> ADE7753_WGAIN);
>> -static IIO_DEV_ATTR_VAGAIN(S_IWUSR | S_IRUGO,
>> +static IIO_DEV_ATTR_VAGAIN(0644,
>> ade7753_read_16bit,
>> ade7753_write_16bit,
>> ADE7753_VAGAIN);
>> -static IIO_DEV_ATTR_PGA_GAIN(S_IWUSR | S_IRUGO,
>> +static IIO_DEV_ATTR_PGA_GAIN(0644,
>> ade7753_read_16bit,
>> ade7753_write_16bit,
>> ADE7753_GAIN);
>> -static IIO_DEV_ATTR_IPKLVL(S_IWUSR | S_IRUGO,
>> +static 

[PATCH v4 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe

[Ryder Lee]

Add documentation for PCIe host driver available in MT7623
series SoCs.

Signed-off-by: Ryder Lee 
Acked-by: Rob Herring 
---
 .../bindings/pci/mediatek,mt7623-pcie.txt  | 130 +
 1 file changed, 130 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt

diff --git a/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt 
b/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
new file mode 100644
index 000..ae4a3f4
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
@@ -0,0 +1,130 @@
+Mediatek Gen2 PCIe controller which is available on MT7623 series SoCs
+
+PCIe subsys supports single root complex (RC) with 3 Root Ports. Each root
+ports supports a Gen2 1-lane Link and has PIPE interface to PHY.
+
+Required properties:
+- compatible: Should contain "mediatek,mt7623-pcie".
+- device_type: Must be "pci"
+- reg: Base addresses and lengths of the PCIe controller.
+- #address-cells: Address representation for root ports (must be 3)
+- #size-cells: Size representation for root ports (must be 2)
+- #interrupt-cells: Size representation for interrupts (must be 1)
+- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
+  Please refer to the standard PCI bus binding document for a more detailed
+  explanation.
+- clocks: Must contain an entry for each entry in clock-names.
+  See ../clocks/clock-bindings.txt for details.
+- clock-names: Must include the following entries:
+  - free_ck :for reference clock of PCIe subsys
+  - sys_ck0 :for clock of Port0
+  - sys_ck1 :for clock of Port1
+  - sys_ck2 :for clock of Port2
+- resets: Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names: Must include the following entries:
+  - pcie-rst0 :port0 reset
+  - pcie-rst1 :port1 reset
+  - pcie-rst2 :port2 reset
+- phys: List of PHY specifiers (used by generic PHY framework).
+- phy-names : Must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the
+  number of PHYs as specified in *phys* property.
+- power-domains: A phandle and power domain specifier pair to the power domain
+  which is responsible for collapsing and restoring power to the peripheral.
+- bus-range: Range of bus numbers associated with this controller.
+- ranges: Ranges for the PCI memory and I/O regions.
+
+In addition, the device tree node must have sub-nodes describing each
+PCIe port interface, having the following mandatory properties:
+
+Required properties:
+- device_type: Must be "pci"
+- reg: Only the first four bytes are used to refer to the correct bus number
+  and device number.
+- #address-cells: Must be 3
+- #size-cells: Must be 2
+- #interrupt-cells: Must be 1
+- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
+  Please refer to the standard PCI bus binding document for a more detailed
+  explanation.
+- ranges: Sub-ranges distributed from the PCIe controller node. An empty
+  property is sufficient.
+- num-lanes: Number of lanes to use for this port.
+
+Examples:
+
+   hifsys: syscon@1a00 {
+   compatible = "mediatek,mt7623-hifsys",
+"mediatek,mt2701-hifsys",
+"syscon";
+   reg = <0 0x1a00 0 0x1000>;
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   };
+
+   pcie: pcie-controller@1a14 {
+   compatible = "mediatek,mt7623-pcie";
+   device_type = "pci";
+   reg = <0 0x1a14 0 0x1000>, /* PCIe shared registers */
+ <0 0x1a142000 0 0x1000>, /* Port0 registers */
+ <0 0x1a143000 0 0x1000>, /* Port1 registers */
+ <0 0x1a144000 0 0x1000>; /* Port2 registers */
+   #address-cells = <3>;
+   #size-cells = <2>;
+   #interrupt-cells = <1>;
+   interrupt-map-mask = <0xf800 0 0 0>;
+   interrupt-map = <0x 0 0 0  GIC_SPI 193 
IRQ_TYPE_LEVEL_LOW>,
+   <0x0800 0 0 0  GIC_SPI 194 
IRQ_TYPE_LEVEL_LOW>,
+   <0x1000 0 0 0  GIC_SPI 195 
IRQ_TYPE_LEVEL_LOW>;
+   clocks = < CLK_TOP_ETHIF_SEL>,
+< CLK_HIFSYS_PCIE0>,
+< CLK_HIFSYS_PCIE1>,
+< CLK_HIFSYS_PCIE2>;
+   clock-names = "free_ck", "sys_ck0", "sys_ck1", "sys_ck2";
+   resets = < MT2701_HIFSYS_PCIE0_RST>,
+< MT2701_HIFSYS_PCIE1_RST>,
+< MT2701_HIFSYS_PCIE2_RST>;
+   reset-names = "pcie-rst0", "pcie-rst1", "pcie-rst2";
+   phys = <_phy>, <_phy>, <_phy>;
+   phy-names = "pcie-phy0", "pcie-phy1", "pcie-phy2";
+   power-domains = < MT2701_POWER_DOMAIN_HIF>;
+   bus-range = <0x00 0xff>;
+   ranges = <0x8100 0 0x1a16 0 

Re: [PATCH v2 3/3] staging: iio: meter: Replace symbolic permissions with octal permissions.

[harinath Nampally]

Jonathan,

Thank you for letting me know. In future I will work on 'togreg' branch
of iio.git tree to send my patches.

Thanks,
Harinath

On Sun, May 14, 2017 at 11:29 AM, Jonathan Cameron  wrote:
> On 10/05/17 00:41, Harinath Nampally wrote:
>>
>> This patch fixes below kind of warnings:
>> WARNING: Symbolic permissions 'S_IXXX | S_IXXX' are not preferred.
>>
>> Below errors are false positives:
>> ade7753.c:382: ERROR: Use 4 digit octal (0777) not decimal permissions
>> ade7753.c:386: ERROR: Use 4 digit octal (0777) not decimal permissions
>>
>> Signed-off-by: Harinath Nampally 
>
> I've already taken a patch for this.
>
> For IIO patches (including for drivers in staging) please also
> check the iio.git tree and in particularly base the on the togreg branch
> of that unless you know something you need is in the testing branch
> (usually more recent) in which case use that.  This stuff all gets
> batched up every few weeks and sent as a pull request to Greg.
> Right now we have just ended a merge window so it's the longest gap
> that typically occurs in these going to Greg.
>
> Thanks,
>
> Jonathan
>
>> ---
>> Changes in v2:
>>   - None because only [PATCH v2 1/3] has improvement
>>
>>   drivers/staging/iio/meter/ade7753.c | 46
>> ++---
>>   1 file changed, 23 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/staging/iio/meter/ade7753.c
>> b/drivers/staging/iio/meter/ade7753.c
>> index 5d45a68..2534bd0 100644
>> --- a/drivers/staging/iio/meter/ade7753.c
>> +++ b/drivers/staging/iio/meter/ade7753.c
>> @@ -298,92 +298,92 @@ static IIO_DEV_ATTR_AENERGY(ade7753_read_24bit,
>> ADE7753_AENERGY);
>>   static IIO_DEV_ATTR_LAENERGY(ade7753_read_24bit, ADE7753_LAENERGY);
>>   static IIO_DEV_ATTR_VAENERGY(ade7753_read_24bit, ADE7753_VAENERGY);
>>   static IIO_DEV_ATTR_LVAENERGY(ade7753_read_24bit, ADE7753_LVAENERGY);
>> -static IIO_DEV_ATTR_CFDEN(S_IWUSR | S_IRUGO,
>> +static IIO_DEV_ATTR_CFDEN(0644,
>> ade7753_read_16bit,
>> ade7753_write_16bit,
>> ADE7753_CFDEN);
>> -static IIO_DEV_ATTR_CFNUM(S_IWUSR | S_IRUGO,
>> +static IIO_DEV_ATTR_CFNUM(0644,
>> ade7753_read_8bit,
>> ade7753_write_8bit,
>> ADE7753_CFNUM);
>>   static IIO_DEV_ATTR_CHKSUM(ade7753_read_8bit, ADE7753_CHKSUM);
>> -static IIO_DEV_ATTR_PHCAL(S_IWUSR | S_IRUGO,
>> +static IIO_DEV_ATTR_PHCAL(0644,
>> ade7753_read_16bit,
>> ade7753_write_16bit,
>> ADE7753_PHCAL);
>> -static IIO_DEV_ATTR_APOS(S_IWUSR | S_IRUGO,
>> +static IIO_DEV_ATTR_APOS(0644,
>> ade7753_read_16bit,
>> ade7753_write_16bit,
>> ADE7753_APOS);
>> -static IIO_DEV_ATTR_SAGCYC(S_IWUSR | S_IRUGO,
>> +static IIO_DEV_ATTR_SAGCYC(0644,
>> ade7753_read_8bit,
>> ade7753_write_8bit,
>> ADE7753_SAGCYC);
>> -static IIO_DEV_ATTR_SAGLVL(S_IWUSR | S_IRUGO,
>> +static IIO_DEV_ATTR_SAGLVL(0644,
>> ade7753_read_8bit,
>> ade7753_write_8bit,
>> ADE7753_SAGLVL);
>> -static IIO_DEV_ATTR_LINECYC(S_IWUSR | S_IRUGO,
>> +static IIO_DEV_ATTR_LINECYC(0644,
>> ade7753_read_8bit,
>> ade7753_write_8bit,
>> ADE7753_LINECYC);
>> -static IIO_DEV_ATTR_WDIV(S_IWUSR | S_IRUGO,
>> +static IIO_DEV_ATTR_WDIV(0644,
>> ade7753_read_8bit,
>> ade7753_write_8bit,
>> ADE7753_WDIV);
>> -static IIO_DEV_ATTR_IRMS(S_IWUSR | S_IRUGO,
>> +static IIO_DEV_ATTR_IRMS(0644,
>> ade7753_read_24bit,
>> NULL,
>> ADE7753_IRMS);
>> -static IIO_DEV_ATTR_VRMS(S_IRUGO,
>> +static IIO_DEV_ATTR_VRMS(0444,
>> ade7753_read_24bit,
>> NULL,
>> ADE7753_VRMS);
>> -static IIO_DEV_ATTR_IRMSOS(S_IWUSR | S_IRUGO,
>> +static IIO_DEV_ATTR_IRMSOS(0644,
>> ade7753_read_16bit,
>> ade7753_write_16bit,
>> ADE7753_IRMSOS);
>> -static IIO_DEV_ATTR_VRMSOS(S_IWUSR | S_IRUGO,
>> +static IIO_DEV_ATTR_VRMSOS(0644,
>> ade7753_read_16bit,
>> ade7753_write_16bit,
>> ADE7753_VRMSOS);
>> -static IIO_DEV_ATTR_WGAIN(S_IWUSR | S_IRUGO,
>> +static IIO_DEV_ATTR_WGAIN(0644,
>> ade7753_read_16bit,
>> ade7753_write_16bit,
>> ADE7753_WGAIN);
>> -static IIO_DEV_ATTR_VAGAIN(S_IWUSR | S_IRUGO,
>> +static IIO_DEV_ATTR_VAGAIN(0644,
>> ade7753_read_16bit,
>> ade7753_write_16bit,
>> ADE7753_VAGAIN);
>> -static IIO_DEV_ATTR_PGA_GAIN(S_IWUSR | S_IRUGO,
>> +static IIO_DEV_ATTR_PGA_GAIN(0644,
>> ade7753_read_16bit,
>> ade7753_write_16bit,
>> ADE7753_GAIN);
>> -static IIO_DEV_ATTR_IPKLVL(S_IWUSR | S_IRUGO,
>> +static IIO_DEV_ATTR_IPKLVL(0644,
>> 

[PATCH v4 0/2] Add PCIe host driver support for Mediatek SoCs

[Ryder Lee]

Hi,

This patch series add Mediatek Gen2 PCIe host controller driver and
dt-binding document. It can be found on MT7623 series SoCs.

This driver was validated using Broadcom Tigon3 and Intel(R) 82575/82576
gigabit ethernet card.


P.S.

Hi Arnd,

I still keep interrupt-map properties of the child nodes in this version.
Because I consider if some ports link down that will break the order
of child buses we made in the binding. In such case, I'm not sure how to
cover it just using the 'bus' portion of the device address in the
interrupt-map properties from parent node.

But if you feel this is inappropriate, I will remove those in next version.

Changes since v4:
- move the per-port registers to the parent node.
- use a valid compatible for hifsys controller.
- use the 'sysirq' instead of 'gic' as a correct 'interrupt-parent' of the
  interrupt-map properties.
 
  'sysirq' is an interrupt-controller that could help us to inverse GIC SPIs 
polarity
  so that we could properly set irq type to level low without any extra 
properties.
  I made a **big mistake** to select wrong interrupt-parent in previous version.
  Now, we could remove interrupt properties entirely from binding.

Changes since v3:
- correct sub-nodes unit addresses.

Changes since v2:
- modify Kconfig to avoid kbuild test error on some architecture.
- change compatible string.
- revise binding document:
  add missing interrupt-names.
  remove the board dts example and drop 'status' properties.
  remove unnecessary descriptions bout standard PCI bus binding.

Changes since v1:
- add .suppress_bind_attrs.
- remove unnecessary *_valid_device() pattern.
- remove PCI_PROBE_ONLY.
- use the regular readl() instead of readl_relaxed().
- add .map_bus() and change to use 
pci_generic_config_read/pci_generic_config_write.
- revise dt-binding document and move nonstandard properties to root node.
- change compatible string.
- use interrupt-map property and replace mtk_pcie_map_irq() with 
of_irq_parse_and_map_pci().
- use the new pci_register_host_bridge() method instead of pci_scan_root_bus()

Ryder Lee (2):
  PCI: mediatek: Add Mediatek PCIe host controller support
  dt-bindings: pcie: Add documentation for Mediatek PCIe

 .../bindings/pci/mediatek,mt7623-pcie.txt  | 130 +
 drivers/pci/host/Kconfig   |  11 +
 drivers/pci/host/Makefile  |   1 +
 drivers/pci/host/pcie-mediatek.c   | 559 +
 4 files changed, 701 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
 create mode 100644 drivers/pci/host/pcie-mediatek.c

-- 
1.9.1

[PATCH v4 1/2] PCI: mediatek: Add Mediatek PCIe host controller support

[Ryder Lee]

Add support for the Mediatek PCIe Gen2 controller which can
be found on MT7623 series SoCs.

Signed-off-by: Ryder Lee 
---
 drivers/pci/host/Kconfig |  11 +
 drivers/pci/host/Makefile|   1 +
 drivers/pci/host/pcie-mediatek.c | 559 +++
 3 files changed, 571 insertions(+)
 create mode 100644 drivers/pci/host/pcie-mediatek.c

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index f7c1d4d..aef0de9 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -174,6 +174,17 @@ config PCIE_ROCKCHIP
  There is 1 internal PCIe port available to support GEN2 with
  4 slots.
 
+config PCIE_MEDIATEK
+   bool "Mediatek PCIe controller"
+   depends on ARM && (ARCH_MEDIATEK || COMPILE_TEST)
+   depends on OF
+   depends on PCI
+   select PCIEPORTBUS
+   help
+ Say Y here if you want to enable PCIe controller support on MT7623 
series
+ SoCs. There is one single root complex with 3 root ports available.
+ Each port supports Gen2 lane x1.
+
 config VMD
depends on PCI_MSI && X86_64 && SRCU
tristate "Intel Volume Management Device Driver"
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 4d36866..265adff 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
 obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
 obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
 obj-$(CONFIG_PCIE_ROCKCHIP) += pcie-rockchip.o
+obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
 obj-$(CONFIG_VMD) += vmd.o
 
 # The following drivers are for devices that use the generic ACPI
diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
new file mode 100644
index 000..b17b6dc
--- /dev/null
+++ b/drivers/pci/host/pcie-mediatek.c
@@ -0,0 +1,559 @@
+/*
+ * Mediatek PCIe host controller driver.
+ *
+ * Copyright (c) 2017 MediaTek Inc.
+ * Author: Ryder Lee 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* PCIe shared registers */
+#define PCIE_SYS_CFG   0x00
+#define PCIE_INT_ENABLE0x0c
+#define PCIE_CFG_ADDR  0x20
+#define PCIE_CFG_DATA  0x24
+
+/* PCIe per port registers */
+#define PCIE_BAR0_SETUP0x10
+#define PCIE_BAR1_SETUP0x14
+#define PCIE_BAR0_MEM_BASE 0x18
+#define PCIE_CLASS 0x34
+#define PCIE_LINK_STATUS   0x50
+
+#define PCIE_PORT_INT_EN(x)BIT(20 + (x))
+#define PCIE_PORT_PERST(x) BIT(1 + (x))
+#define PCIE_PORT_LINKUP   BIT(0)
+#define PCIE_BAR_MAP_MAX   GENMASK(31, 16)
+
+#define PCIE_BAR_ENABLEBIT(0)
+#define PCIE_REVISION_ID   BIT(0)
+#define PCIE_CLASS_CODE(0x60400 << 8)
+#define PCIE_CONF_REG(regn)(((regn) & GENMASK(7, 2)) | \
+   regn) >> 8) & GENMASK(3, 0)) << 24))
+#define PCIE_CONF_FUN(fun) (((fun) << 8) & GENMASK(10, 8))
+#define PCIE_CONF_DEV(dev) (((dev) << 11) & GENMASK(15, 11))
+#define PCIE_CONF_BUS(bus) (((bus) << 16) & GENMASK(23, 16))
+#define PCIE_CONF_ADDR(regn, fun, dev, bus) \
+   (PCIE_CONF_REG(regn) | PCIE_CONF_FUN(fun) | \
+PCIE_CONF_DEV(dev) | PCIE_CONF_BUS(bus))
+
+/* Mediatek specific configuration registers */
+#define PCIE_FTS_NUM   0x70c
+#define PCIE_FTS_NUM_MASK  GENMASK(15, 8)
+#define PCIE_FTS_NUM_L0(x) ((x) & 0xff << 8)
+
+#define PCIE_FC_CREDIT 0x73c
+#define PCIE_FC_CREDIT_MASK(GENMASK(31, 31) | GENMASK(28, 16))
+#define PCIE_FC_CREDIT_VAL(x)  ((x) << 16)
+
+/**
+ * struct mtk_pcie_port - PCIe port information
+ * @base: IO mapped register base
+ * @list: port list
+ * @pcie: pointer to PCIe host info
+ * @reset: pointer to port reset control
+ * @sys_ck: pointer to bus clock
+ * @phy: pointer to phy control block
+ * @lane: lane count
+ * @index: port index
+ */
+struct mtk_pcie_port {
+   void __iomem *base;
+   struct list_head list;
+   struct mtk_pcie *pcie;
+   struct reset_control *reset;
+   struct clk *sys_ck;
+   struct phy *phy;
+   u32 lane;
+   u32 index;
+};
+
+/**
+ * struct mtk_pcie - PCIe host information
+ * @dev: pointer to PCIe device
+ * @base: IO mapped register Base
+ * @free_ck: free-run reference clock
+ * @io: IO resource
+ * @pio: PIO resource
+ * @mem: 

[PATCH v4 0/2] Add PCIe host driver support for Mediatek SoCs

[Ryder Lee]

Hi,

This patch series add Mediatek Gen2 PCIe host controller driver and
dt-binding document. It can be found on MT7623 series SoCs.

This driver was validated using Broadcom Tigon3 and Intel(R) 82575/82576
gigabit ethernet card.


P.S.

Hi Arnd,

I still keep interrupt-map properties of the child nodes in this version.
Because I consider if some ports link down that will break the order
of child buses we made in the binding. In such case, I'm not sure how to
cover it just using the 'bus' portion of the device address in the
interrupt-map properties from parent node.

But if you feel this is inappropriate, I will remove those in next version.

Changes since v4:
- move the per-port registers to the parent node.
- use a valid compatible for hifsys controller.
- use the 'sysirq' instead of 'gic' as a correct 'interrupt-parent' of the
  interrupt-map properties.
 
  'sysirq' is an interrupt-controller that could help us to inverse GIC SPIs 
polarity
  so that we could properly set irq type to level low without any extra 
properties.
  I made a **big mistake** to select wrong interrupt-parent in previous version.
  Now, we could remove interrupt properties entirely from binding.

Changes since v3:
- correct sub-nodes unit addresses.

Changes since v2:
- modify Kconfig to avoid kbuild test error on some architecture.
- change compatible string.
- revise binding document:
  add missing interrupt-names.
  remove the board dts example and drop 'status' properties.
  remove unnecessary descriptions bout standard PCI bus binding.

Changes since v1:
- add .suppress_bind_attrs.
- remove unnecessary *_valid_device() pattern.
- remove PCI_PROBE_ONLY.
- use the regular readl() instead of readl_relaxed().
- add .map_bus() and change to use 
pci_generic_config_read/pci_generic_config_write.
- revise dt-binding document and move nonstandard properties to root node.
- change compatible string.
- use interrupt-map property and replace mtk_pcie_map_irq() with 
of_irq_parse_and_map_pci().
- use the new pci_register_host_bridge() method instead of pci_scan_root_bus()

Ryder Lee (2):
  PCI: mediatek: Add Mediatek PCIe host controller support
  dt-bindings: pcie: Add documentation for Mediatek PCIe

 .../bindings/pci/mediatek,mt7623-pcie.txt  | 130 +
 drivers/pci/host/Kconfig   |  11 +
 drivers/pci/host/Makefile  |   1 +
 drivers/pci/host/pcie-mediatek.c   | 559 +
 4 files changed, 701 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
 create mode 100644 drivers/pci/host/pcie-mediatek.c

-- 
1.9.1

[PATCH v4 1/2] PCI: mediatek: Add Mediatek PCIe host controller support

[Ryder Lee]

Add support for the Mediatek PCIe Gen2 controller which can
be found on MT7623 series SoCs.

Signed-off-by: Ryder Lee 
---
 drivers/pci/host/Kconfig |  11 +
 drivers/pci/host/Makefile|   1 +
 drivers/pci/host/pcie-mediatek.c | 559 +++
 3 files changed, 571 insertions(+)
 create mode 100644 drivers/pci/host/pcie-mediatek.c

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index f7c1d4d..aef0de9 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -174,6 +174,17 @@ config PCIE_ROCKCHIP
  There is 1 internal PCIe port available to support GEN2 with
  4 slots.
 
+config PCIE_MEDIATEK
+   bool "Mediatek PCIe controller"
+   depends on ARM && (ARCH_MEDIATEK || COMPILE_TEST)
+   depends on OF
+   depends on PCI
+   select PCIEPORTBUS
+   help
+ Say Y here if you want to enable PCIe controller support on MT7623 
series
+ SoCs. There is one single root complex with 3 root ports available.
+ Each port supports Gen2 lane x1.
+
 config VMD
depends on PCI_MSI && X86_64 && SRCU
tristate "Intel Volume Management Device Driver"
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 4d36866..265adff 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
 obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
 obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
 obj-$(CONFIG_PCIE_ROCKCHIP) += pcie-rockchip.o
+obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
 obj-$(CONFIG_VMD) += vmd.o
 
 # The following drivers are for devices that use the generic ACPI
diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
new file mode 100644
index 000..b17b6dc
--- /dev/null
+++ b/drivers/pci/host/pcie-mediatek.c
@@ -0,0 +1,559 @@
+/*
+ * Mediatek PCIe host controller driver.
+ *
+ * Copyright (c) 2017 MediaTek Inc.
+ * Author: Ryder Lee 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* PCIe shared registers */
+#define PCIE_SYS_CFG   0x00
+#define PCIE_INT_ENABLE0x0c
+#define PCIE_CFG_ADDR  0x20
+#define PCIE_CFG_DATA  0x24
+
+/* PCIe per port registers */
+#define PCIE_BAR0_SETUP0x10
+#define PCIE_BAR1_SETUP0x14
+#define PCIE_BAR0_MEM_BASE 0x18
+#define PCIE_CLASS 0x34
+#define PCIE_LINK_STATUS   0x50
+
+#define PCIE_PORT_INT_EN(x)BIT(20 + (x))
+#define PCIE_PORT_PERST(x) BIT(1 + (x))
+#define PCIE_PORT_LINKUP   BIT(0)
+#define PCIE_BAR_MAP_MAX   GENMASK(31, 16)
+
+#define PCIE_BAR_ENABLEBIT(0)
+#define PCIE_REVISION_ID   BIT(0)
+#define PCIE_CLASS_CODE(0x60400 << 8)
+#define PCIE_CONF_REG(regn)(((regn) & GENMASK(7, 2)) | \
+   regn) >> 8) & GENMASK(3, 0)) << 24))
+#define PCIE_CONF_FUN(fun) (((fun) << 8) & GENMASK(10, 8))
+#define PCIE_CONF_DEV(dev) (((dev) << 11) & GENMASK(15, 11))
+#define PCIE_CONF_BUS(bus) (((bus) << 16) & GENMASK(23, 16))
+#define PCIE_CONF_ADDR(regn, fun, dev, bus) \
+   (PCIE_CONF_REG(regn) | PCIE_CONF_FUN(fun) | \
+PCIE_CONF_DEV(dev) | PCIE_CONF_BUS(bus))
+
+/* Mediatek specific configuration registers */
+#define PCIE_FTS_NUM   0x70c
+#define PCIE_FTS_NUM_MASK  GENMASK(15, 8)
+#define PCIE_FTS_NUM_L0(x) ((x) & 0xff << 8)
+
+#define PCIE_FC_CREDIT 0x73c
+#define PCIE_FC_CREDIT_MASK(GENMASK(31, 31) | GENMASK(28, 16))
+#define PCIE_FC_CREDIT_VAL(x)  ((x) << 16)
+
+/**
+ * struct mtk_pcie_port - PCIe port information
+ * @base: IO mapped register base
+ * @list: port list
+ * @pcie: pointer to PCIe host info
+ * @reset: pointer to port reset control
+ * @sys_ck: pointer to bus clock
+ * @phy: pointer to phy control block
+ * @lane: lane count
+ * @index: port index
+ */
+struct mtk_pcie_port {
+   void __iomem *base;
+   struct list_head list;
+   struct mtk_pcie *pcie;
+   struct reset_control *reset;
+   struct clk *sys_ck;
+   struct phy *phy;
+   u32 lane;
+   u32 index;
+};
+
+/**
+ * struct mtk_pcie - PCIe host information
+ * @dev: pointer to PCIe device
+ * @base: IO mapped register Base
+ * @free_ck: free-run reference clock
+ * @io: IO resource
+ * @pio: PIO resource
+ * @mem: non-prefetchable memory resource
+ * @busn: bus range
+ 

Re: [PATCH 3/3] Fix ERROR: code indent should use tabs where possible

[Michael S. Tsirkin]

On Sun, May 14, 2017 at 07:51:30PM +0200, Maciek Fijalkowski wrote:
> From: Maciej Fijalkowski 
> 
> Signed-off-by: Maciej Fijalkowski 


Acked-by: Michael S. Tsirkin 

But you really want to fix the subject. Make it less verbose
drop upper case and add info about module. Something like:

virtio_net: coding style fix: use tabs for indent

Also, you misspelled Jason's email.

> ---
>  drivers/net/virtio_net.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 6c8170c..5d71e9f 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -2717,7 +2717,7 @@ static __init int virtio_net_driver_init(void)
>   if (ret)
>   goto err_dead;
>  
> -ret = register_virtio_driver(_net_driver);
> + ret = register_virtio_driver(_net_driver);
>   if (ret)
>   goto err_virtio;
>   return 0;
> -- 
> 2.4.11

Re: [PATCH 3/3] Fix ERROR: code indent should use tabs where possible

[Michael S. Tsirkin]

On Sun, May 14, 2017 at 07:51:30PM +0200, Maciek Fijalkowski wrote:
> From: Maciej Fijalkowski 
> 
> Signed-off-by: Maciej Fijalkowski 


Acked-by: Michael S. Tsirkin 

But you really want to fix the subject. Make it less verbose
drop upper case and add info about module. Something like:

virtio_net: coding style fix: use tabs for indent

Also, you misspelled Jason's email.

> ---
>  drivers/net/virtio_net.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 6c8170c..5d71e9f 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -2717,7 +2717,7 @@ static __init int virtio_net_driver_init(void)
>   if (ret)
>   goto err_dead;
>  
> -ret = register_virtio_driver(_net_driver);
> + ret = register_virtio_driver(_net_driver);
>   if (ret)
>   goto err_virtio;
>   return 0;
> -- 
> 2.4.11

linux-next: Tree for May 15

[Stephen Rothwell]

Hi all,

Changes since 20170512:

Non-merge commits (relative to Linus' tree): 508
 569 files changed, 13787 insertions(+), 5574 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
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 258 trees (counting Linus' and 37 trees of bug
fix patches pending for the current merge release).

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 (2ea659a9ef48 Linux 4.12-rc1)
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (2ea659a9ef48 Linux 4.12-rc1)
Merging arc-current/for-curr (cf4100d1cddc Revert "ARCv2: Allow enabling PAE40 
w/o HIGHMEM")
Merging arm-current/fixes (6d8059493691 ARM: 8670/1: V7M: Do not corrupt vector 
table around v7m_invalidate_l1 call)
Merging m68k-current/for-linus (f6ab4d59a5fe nubus: Add MVC and VSC video card 
definitions)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (be5c5e843c4a powerpc/64: Fix HMI exception on LE 
with CONFIG_RELOCATABLE=y)
Merging sparc/master (3c7f62212018 sparc64: fix fault handling in NGbzero.S and 
GENbzero.S)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (1c4d5f51a812 vmxnet3: ensure that adapter is in proper 
state during force_close)
Merging ipsec/master (2c1497bbc8fd xfrm: Fix NETDEV_DOWN with IPSec offload)
Merging netfilter/master (f411af682218 Merge branch 
'ibmvnic-Updated-reset-handler-andcode-fixes')
Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (d77facb88448 brcmfmac: use local iftype 
avoiding use-after-free of virtual interface)
Merging mac80211/master (29cee56c0be4 Merge tag 'mac80211-for-davem-2017-05-08' 
of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211)
Merging sound-current/for-linus (31cbee6a5611 sound: Disable the build of OSS 
drivers)
Merging pci-current/for-linus (b9c1153f7a9c PCI: hisi: Fix DT binding 
(hisi-pcie-almost-ecam))
Merging driver-core.current/driver-core-linus (af82455f7dbd Merge tag 
'char-misc-4.12-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc)
Merging tty.current/tty-linus (4f7d029b9bf0 Linux 4.11-rc7)
Merging usb.current/usb-linus (a71c9a1c779f Linux 4.11-rc5)
Merging usb-gadget-fixes/fixes (a351e9b9fc24 Linux 4.11)
Merging usb-serial-fixes/usb-linus (c02ed2e75ef4 Linux 4.11-rc4)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (1a09b6a7c10e phy: qcom-usb-hs: Add depends on EXTCON)
Merging staging.current/staging-linus (09d79d103371 Merge tag 'docs-4.12-2' of 
git://git.lwn.net/linux)
Merging char-misc.current/char-misc-linus (af82455f7dbd Merge tag 
'char-misc-4.12-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc)
Merging input-current/for-linus (3af9256150b3 Input: cros_ec_keyb - remove 
extraneous 'const')
Merging crypto-current/master (929562b14478 crypto: stm32 - Fix OF module alias 
information)
Merging ide/master (acfead32f3f9 ide: don't call memcpy with the same source 
and destination)
Merging vfio-fixes/for-linus (39da7c509acf Linux 4.11-rc6)
Merging kselftest-fixes/fixes (c1ae3cfa0e89 Linux 4.11-rc1)
Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: 
Handle EPROBE_DEFER while requesting the PWM)
Merging ftrace-fixes/for-next-urgent (6224beb12e19 tracing: Have branch 

linux-next: Tree for May 15

[Stephen Rothwell]

Hi all,

Changes since 20170512:

Non-merge commits (relative to Linus' tree): 508
 569 files changed, 13787 insertions(+), 5574 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
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 258 trees (counting Linus' and 37 trees of bug
fix patches pending for the current merge release).

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 (2ea659a9ef48 Linux 4.12-rc1)
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (2ea659a9ef48 Linux 4.12-rc1)
Merging arc-current/for-curr (cf4100d1cddc Revert "ARCv2: Allow enabling PAE40 
w/o HIGHMEM")
Merging arm-current/fixes (6d8059493691 ARM: 8670/1: V7M: Do not corrupt vector 
table around v7m_invalidate_l1 call)
Merging m68k-current/for-linus (f6ab4d59a5fe nubus: Add MVC and VSC video card 
definitions)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (be5c5e843c4a powerpc/64: Fix HMI exception on LE 
with CONFIG_RELOCATABLE=y)
Merging sparc/master (3c7f62212018 sparc64: fix fault handling in NGbzero.S and 
GENbzero.S)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (1c4d5f51a812 vmxnet3: ensure that adapter is in proper 
state during force_close)
Merging ipsec/master (2c1497bbc8fd xfrm: Fix NETDEV_DOWN with IPSec offload)
Merging netfilter/master (f411af682218 Merge branch 
'ibmvnic-Updated-reset-handler-andcode-fixes')
Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (d77facb88448 brcmfmac: use local iftype 
avoiding use-after-free of virtual interface)
Merging mac80211/master (29cee56c0be4 Merge tag 'mac80211-for-davem-2017-05-08' 
of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211)
Merging sound-current/for-linus (31cbee6a5611 sound: Disable the build of OSS 
drivers)
Merging pci-current/for-linus (b9c1153f7a9c PCI: hisi: Fix DT binding 
(hisi-pcie-almost-ecam))
Merging driver-core.current/driver-core-linus (af82455f7dbd Merge tag 
'char-misc-4.12-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc)
Merging tty.current/tty-linus (4f7d029b9bf0 Linux 4.11-rc7)
Merging usb.current/usb-linus (a71c9a1c779f Linux 4.11-rc5)
Merging usb-gadget-fixes/fixes (a351e9b9fc24 Linux 4.11)
Merging usb-serial-fixes/usb-linus (c02ed2e75ef4 Linux 4.11-rc4)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (1a09b6a7c10e phy: qcom-usb-hs: Add depends on EXTCON)
Merging staging.current/staging-linus (09d79d103371 Merge tag 'docs-4.12-2' of 
git://git.lwn.net/linux)
Merging char-misc.current/char-misc-linus (af82455f7dbd Merge tag 
'char-misc-4.12-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc)
Merging input-current/for-linus (3af9256150b3 Input: cros_ec_keyb - remove 
extraneous 'const')
Merging crypto-current/master (929562b14478 crypto: stm32 - Fix OF module alias 
information)
Merging ide/master (acfead32f3f9 ide: don't call memcpy with the same source 
and destination)
Merging vfio-fixes/for-linus (39da7c509acf Linux 4.11-rc6)
Merging kselftest-fixes/fixes (c1ae3cfa0e89 Linux 4.11-rc1)
Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: 
Handle EPROBE_DEFER while requesting the PWM)
Merging ftrace-fixes/for-next-urgent (6224beb12e19 tracing: Have branch 

Re: [PATCH 1/3] Fix ERROR: trailing statements should be on next line

[Michael S. Tsirkin]

On Sun, May 14, 2017 at 07:51:28PM +0200, Maciek Fijalkowski wrote:
> From: Maciej Fijalkowski 
> 
> Signed-off-by: Maciej Fijalkowski 

I prefer the original form - ; isn't a full statement.

> ---
>  drivers/net/virtio_net.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 9320d96..f20dfb8 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -217,7 +217,8 @@ static void give_pages(struct receive_queue *rq, struct 
> page *page)
>   struct page *end;
>  
>   /* Find end of list, sew whole thing into vi->rq.pages. */
> - for (end = page; end->private; end = (struct page *)end->private);
> + for (end = page; end->private; end = (struct page *)end->private)
> + ;
>   end->private = (unsigned long)rq->pages;
>   rq->pages = page;
>  }
> -- 
> 2.4.11

Re: [PATCH 1/3] Fix ERROR: trailing statements should be on next line

[Michael S. Tsirkin]

On Sun, May 14, 2017 at 07:51:28PM +0200, Maciek Fijalkowski wrote:
> From: Maciej Fijalkowski 
> 
> Signed-off-by: Maciej Fijalkowski 

I prefer the original form - ; isn't a full statement.

> ---
>  drivers/net/virtio_net.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 9320d96..f20dfb8 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -217,7 +217,8 @@ static void give_pages(struct receive_queue *rq, struct 
> page *page)
>   struct page *end;
>  
>   /* Find end of list, sew whole thing into vi->rq.pages. */
> - for (end = page; end->private; end = (struct page *)end->private);
> + for (end = page; end->private; end = (struct page *)end->private)
> + ;
>   end->private = (unsigned long)rq->pages;
>   rq->pages = page;
>  }
> -- 
> 2.4.11

Re: [PATCH 2/3] Fix ERROR: Macros with complex values should be enclosed in parentheses

[Michael S. Tsirkin]

On Sun, May 14, 2017 at 07:51:29PM +0200, Maciek Fijalkowski wrote:
> From: Maciej Fijalkowski 
> 
> Signed-off-by: Maciej Fijalkowski 

This is not a complex value.

> ---
>  drivers/net/virtio_net.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index f20dfb8..6c8170c 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -2663,7 +2663,7 @@ static struct virtio_device_id id_table[] = {
>  };
>  
>  #define VIRTNET_FEATURES \
> - VIRTIO_NET_F_CSUM, VIRTIO_NET_F_GUEST_CSUM, \
> + (VIRTIO_NET_F_CSUM, VIRTIO_NET_F_GUEST_CSUM, \
>   VIRTIO_NET_F_MAC, \
>   VIRTIO_NET_F_HOST_TSO4, VIRTIO_NET_F_HOST_UFO, VIRTIO_NET_F_HOST_TSO6, \
>   VIRTIO_NET_F_HOST_ECN, VIRTIO_NET_F_GUEST_TSO4, 
> VIRTIO_NET_F_GUEST_TSO6, \
> @@ -2672,7 +2672,7 @@ static struct virtio_device_id id_table[] = {
>   VIRTIO_NET_F_CTRL_RX, VIRTIO_NET_F_CTRL_VLAN, \
>   VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ, \
>   VIRTIO_NET_F_CTRL_MAC_ADDR, \
> - VIRTIO_NET_F_MTU
> + VIRTIO_NET_F_MTU)
>  
>  static unsigned int features[] = {
>   VIRTNET_FEATURES,
> -- 
> 2.4.11

Re: [PATCH 2/3] Fix ERROR: Macros with complex values should be enclosed in parentheses

[Michael S. Tsirkin]

On Sun, May 14, 2017 at 07:51:29PM +0200, Maciek Fijalkowski wrote:
> From: Maciej Fijalkowski 
> 
> Signed-off-by: Maciej Fijalkowski 

This is not a complex value.

> ---
>  drivers/net/virtio_net.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index f20dfb8..6c8170c 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -2663,7 +2663,7 @@ static struct virtio_device_id id_table[] = {
>  };
>  
>  #define VIRTNET_FEATURES \
> - VIRTIO_NET_F_CSUM, VIRTIO_NET_F_GUEST_CSUM, \
> + (VIRTIO_NET_F_CSUM, VIRTIO_NET_F_GUEST_CSUM, \
>   VIRTIO_NET_F_MAC, \
>   VIRTIO_NET_F_HOST_TSO4, VIRTIO_NET_F_HOST_UFO, VIRTIO_NET_F_HOST_TSO6, \
>   VIRTIO_NET_F_HOST_ECN, VIRTIO_NET_F_GUEST_TSO4, 
> VIRTIO_NET_F_GUEST_TSO6, \
> @@ -2672,7 +2672,7 @@ static struct virtio_device_id id_table[] = {
>   VIRTIO_NET_F_CTRL_RX, VIRTIO_NET_F_CTRL_VLAN, \
>   VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ, \
>   VIRTIO_NET_F_CTRL_MAC_ADDR, \
> - VIRTIO_NET_F_MTU
> + VIRTIO_NET_F_MTU)
>  
>  static unsigned int features[] = {
>   VIRTNET_FEATURES,
> -- 
> 2.4.11

Re: [PATCH] kmod: don't load module unless req process has CAP_SYS_MODULE

[महेश बंडेवार]

On Sun, May 14, 2017 at 3:45 AM, Greg Kroah-Hartman
 wrote:
> On Fri, May 12, 2017 at 04:22:59PM -0700, Mahesh Bandewar wrote:
>> From: Mahesh Bandewar 
>>
[...]
>>   Now try to create a bridge inside this newly created net-ns which would
>>   mean bridge module need to be loaded.
>>   # ip link add br0 type bridge
>>   # echo $?
>>   0
>>   # lsmod | grep bridge
>>   bridge110592  0
>>   stp16384  1 bridge
>>   llc16384  2 bridge,stp
>>   #
>>
>>   After this patch -
>>   # ip link add br0 type bridge
>>   RTNETLINK answers: Operation not supported
>>   # echo $?
>>   2
>>   # lsmod | grep bridge
>>   #
>
> Well, it only loads this because the kernel asked for it to be loaded,
> right?
>
Yes, kernel asked for it because of a user action.

>>
>> Signed-off-by: Mahesh Bandewar 
>> ---
>>  kernel/kmod.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/kernel/kmod.c b/kernel/kmod.c
>> index 563f97e2be36..ac30157169b7 100644
>> --- a/kernel/kmod.c
>> +++ b/kernel/kmod.c
>> @@ -133,6 +133,9 @@ int __request_module(bool wait, const char *fmt, ...)
>>  #define MAX_KMOD_CONCURRENT 50   /* Completely arbitrary value - KAO */
>>   static int kmod_loop_msg;
>>
>> + if (!capable(CAP_SYS_MODULE))
>> + return -EPERM;
>
> At first glance this looks right, but I'm worried what this will break
> that currently relies on this.  There might be lots of systems that are
> used to this being the method that the needed module is requested.  What
> about when userspace asks for a random char device and that module is
> then loaded?  Does this patch break that functionality?
>
Any module when loaded gets loaded system-wide as we can't allow
module loading per-ns. To validate the behavior I was comparing it
with insmod/modprobe, if that doesn't allow because of lack of this
capability in default-ns, then this *indirect* method of loading
module should not allow the same action and the behavior should be
consistent. So with that logic if userspace asks for a random
char-device if insmod/modprobe cannot load it, then this method should
not load it either for the consistency, right?

> thanks,
>
> greg k-h

Re: [PATCH] kmod: don't load module unless req process has CAP_SYS_MODULE

[महेश बंडेवार]

On Sun, May 14, 2017 at 3:45 AM, Greg Kroah-Hartman
 wrote:
> On Fri, May 12, 2017 at 04:22:59PM -0700, Mahesh Bandewar wrote:
>> From: Mahesh Bandewar 
>>
[...]
>>   Now try to create a bridge inside this newly created net-ns which would
>>   mean bridge module need to be loaded.
>>   # ip link add br0 type bridge
>>   # echo $?
>>   0
>>   # lsmod | grep bridge
>>   bridge110592  0
>>   stp16384  1 bridge
>>   llc16384  2 bridge,stp
>>   #
>>
>>   After this patch -
>>   # ip link add br0 type bridge
>>   RTNETLINK answers: Operation not supported
>>   # echo $?
>>   2
>>   # lsmod | grep bridge
>>   #
>
> Well, it only loads this because the kernel asked for it to be loaded,
> right?
>
Yes, kernel asked for it because of a user action.

>>
>> Signed-off-by: Mahesh Bandewar 
>> ---
>>  kernel/kmod.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/kernel/kmod.c b/kernel/kmod.c
>> index 563f97e2be36..ac30157169b7 100644
>> --- a/kernel/kmod.c
>> +++ b/kernel/kmod.c
>> @@ -133,6 +133,9 @@ int __request_module(bool wait, const char *fmt, ...)
>>  #define MAX_KMOD_CONCURRENT 50   /* Completely arbitrary value - KAO */
>>   static int kmod_loop_msg;
>>
>> + if (!capable(CAP_SYS_MODULE))
>> + return -EPERM;
>
> At first glance this looks right, but I'm worried what this will break
> that currently relies on this.  There might be lots of systems that are
> used to this being the method that the needed module is requested.  What
> about when userspace asks for a random char device and that module is
> then loaded?  Does this patch break that functionality?
>
Any module when loaded gets loaded system-wide as we can't allow
module loading per-ns. To validate the behavior I was comparing it
with insmod/modprobe, if that doesn't allow because of lack of this
capability in default-ns, then this *indirect* method of loading
module should not allow the same action and the behavior should be
consistent. So with that logic if userspace asks for a random
char-device if insmod/modprobe cannot load it, then this method should
not load it either for the consistency, right?

> thanks,
>
> greg k-h

Re: [PATCH] ACPI / GED: use late init to allow other drivers init

[Sinan Kaya]

Hi Rafael,

On 5/11/2017 10:52 AM, Rafael J. Wysocki wrote:
>> OK. I'll reach out to Harb and let's see where the proposal goes. 
> It looks like this is about operation regions after all, however, so _DEP as 
> is
> should be sufficient here.
> 
> There is some limited _DEP support in the ACPI layer, but we were missing
> a way to represent those dependencies in the driver core.
> 
> That can be done through device_link objects now, so we may be able to support
> _DEP in a more meaningful way, but the cases when _DEP is used for something
> different from operation regions in practice need to be treated with caution.
> 
> 

_DEP could certainly help here. However, _DEP doesn't answer the loose binding 
question.
If one driver is missing in one operating system, _GED driver will never load 
due 
to unsatisfied dependency. This forces us into all or none condition. We have 
operating
systems that we need to support and do not have vendor I2C or GPIO drivers. 
That's why,
we are hesitant to place _DEP into ACPI tables.

The problem is that there is no concept of per event dependency. This could 
have helped
us figure out if such an interrupt should be enabled or not.

Another solution for operating regions is _REG if FW wants to ignore the event 
during
boot. This is the one we are looking into at this moment for non-critical 
events. 

late_init proposed in this patch helps for built-in drivers such as GHES where 
we do
not want to ignore events. Since GHES is not an actual device, this has to be 
solved
in ACPI.


Sinan

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Re: [PATCH] ACPI / GED: use late init to allow other drivers init

[Sinan Kaya]

Hi Rafael,

On 5/11/2017 10:52 AM, Rafael J. Wysocki wrote:
>> OK. I'll reach out to Harb and let's see where the proposal goes. 
> It looks like this is about operation regions after all, however, so _DEP as 
> is
> should be sufficient here.
> 
> There is some limited _DEP support in the ACPI layer, but we were missing
> a way to represent those dependencies in the driver core.
> 
> That can be done through device_link objects now, so we may be able to support
> _DEP in a more meaningful way, but the cases when _DEP is used for something
> different from operation regions in practice need to be treated with caution.
> 
> 

_DEP could certainly help here. However, _DEP doesn't answer the loose binding 
question.
If one driver is missing in one operating system, _GED driver will never load 
due 
to unsatisfied dependency. This forces us into all or none condition. We have 
operating
systems that we need to support and do not have vendor I2C or GPIO drivers. 
That's why,
we are hesitant to place _DEP into ACPI tables.

The problem is that there is no concept of per event dependency. This could 
have helped
us figure out if such an interrupt should be enabled or not.

Another solution for operating regions is _REG if FW wants to ignore the event 
during
boot. This is the one we are looking into at this moment for non-critical 
events. 

late_init proposed in this patch helps for built-in drivers such as GHES where 
we do
not want to ignore events. Since GHES is not an actual device, this has to be 
solved
in ACPI.


Sinan

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Re: [PATCH v3 3/3] media: mtk-mdp: Fix mdp device tree

[Minghsiu Tsai]

On Fri, 2017-05-12 at 17:05 +0200, Matthias Brugger wrote:
> 
> On 12/05/17 05:22, Minghsiu Tsai wrote:
> > From: Daniel Kurtz 
> > 
> > If the mdp_* nodes are under an mdp sub-node, their corresponding
> > platform device does not automatically get its iommu assigned properly.
> > 
> > Fix this by moving the mdp component nodes up a level such that they are
> > siblings of mdp and all other SoC subsystems.  This also simplifies the
> > device tree.
> > 
> > Although it fixes iommu assignment issue, it also break compatibility
> > with old device tree. So, the patch in driver is needed to iterate over
> > sibling mdp device nodes, not child ones, to keep driver work properly.
> > 
> 
> Couldn't we preserve backwards compatibility by doing something like this:
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c 
> b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> index 9e4eb7dcc424..277d8fe6eb76 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> @@ -103,7 +103,7 @@ static int mtk_mdp_probe(struct platform_device *pdev)
>   {
>   struct mtk_mdp_dev *mdp;
>   struct device *dev = >dev;
> - struct device_node *node;
> + struct device_node *node, *parent;
>   int i, ret = 0;
> 
>   mdp = devm_kzalloc(dev, sizeof(*mdp), GFP_KERNEL);
> @@ -117,8 +117,14 @@ static int mtk_mdp_probe(struct platform_device *pdev)
>   mutex_init(>lock);
>   mutex_init(>vpulock);
> 
> + /* Old dts had the components as child nodes */
> + if (of_get_next_child(dev->of_node, NULL))
> + parent = dev->of_node;
> + else
> + parent = dev->of_node->parent;
> +
>   /* Iterate over sibling MDP function blocks */
> - for_each_child_of_node(dev->of_node, node) {
> + for_each_child_of_node(parent, node) {
>   const struct of_device_id *of_id;
>   enum mtk_mdp_comp_type comp_type;
>   int comp_id;
> 
> Maybe even by putting a warning in the if branch to make sure, people 
> are aware of their out-of-date device tree blobs.
> 
> Regards,
> Matthias
> 

Hi Matthias,

It is a good idea to do compatible in such a way and put a warning the
device tree is out of date. People can find out cause soon if device
tree is old.

I modify the code as below:

+   /* Old dts had the components as child nodes */
+   if (of_get_next_child(dev->of_node, NULL)) {
+   parent = dev->of_node;
+   dev_warn(dev, "device tree is out of date\n");
+   } else {
+   parent = dev->of_node->parent;
+   }

Will you upload it in a separate patch? 
If not, I can merge it in my patch series and upload v4.


Best Regards,

Ming Hsiu

> > Signed-off-by: Daniel Kurtz 
> > Signed-off-by: Minghsiu Tsai 
> > 
> > ---
> >   drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c 
> > b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> > index 9e4eb7d..a5ad586 100644
> > --- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> > +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> > @@ -118,7 +118,7 @@ static int mtk_mdp_probe(struct platform_device *pdev)
> > mutex_init(>vpulock);
> >   
> > /* Iterate over sibling MDP function blocks */
> > -   for_each_child_of_node(dev->of_node, node) {
> > +   for_each_child_of_node(dev->of_node->parent, node) {
> > const struct of_device_id *of_id;
> > enum mtk_mdp_comp_type comp_type;
> > int comp_id;
> > 

Re: [PATCH v3 3/3] media: mtk-mdp: Fix mdp device tree

[Minghsiu Tsai]

On Fri, 2017-05-12 at 17:05 +0200, Matthias Brugger wrote:
> 
> On 12/05/17 05:22, Minghsiu Tsai wrote:
> > From: Daniel Kurtz 
> > 
> > If the mdp_* nodes are under an mdp sub-node, their corresponding
> > platform device does not automatically get its iommu assigned properly.
> > 
> > Fix this by moving the mdp component nodes up a level such that they are
> > siblings of mdp and all other SoC subsystems.  This also simplifies the
> > device tree.
> > 
> > Although it fixes iommu assignment issue, it also break compatibility
> > with old device tree. So, the patch in driver is needed to iterate over
> > sibling mdp device nodes, not child ones, to keep driver work properly.
> > 
> 
> Couldn't we preserve backwards compatibility by doing something like this:
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c 
> b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> index 9e4eb7dcc424..277d8fe6eb76 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> @@ -103,7 +103,7 @@ static int mtk_mdp_probe(struct platform_device *pdev)
>   {
>   struct mtk_mdp_dev *mdp;
>   struct device *dev = >dev;
> - struct device_node *node;
> + struct device_node *node, *parent;
>   int i, ret = 0;
> 
>   mdp = devm_kzalloc(dev, sizeof(*mdp), GFP_KERNEL);
> @@ -117,8 +117,14 @@ static int mtk_mdp_probe(struct platform_device *pdev)
>   mutex_init(>lock);
>   mutex_init(>vpulock);
> 
> + /* Old dts had the components as child nodes */
> + if (of_get_next_child(dev->of_node, NULL))
> + parent = dev->of_node;
> + else
> + parent = dev->of_node->parent;
> +
>   /* Iterate over sibling MDP function blocks */
> - for_each_child_of_node(dev->of_node, node) {
> + for_each_child_of_node(parent, node) {
>   const struct of_device_id *of_id;
>   enum mtk_mdp_comp_type comp_type;
>   int comp_id;
> 
> Maybe even by putting a warning in the if branch to make sure, people 
> are aware of their out-of-date device tree blobs.
> 
> Regards,
> Matthias
> 

Hi Matthias,

It is a good idea to do compatible in such a way and put a warning the
device tree is out of date. People can find out cause soon if device
tree is old.

I modify the code as below:

+   /* Old dts had the components as child nodes */
+   if (of_get_next_child(dev->of_node, NULL)) {
+   parent = dev->of_node;
+   dev_warn(dev, "device tree is out of date\n");
+   } else {
+   parent = dev->of_node->parent;
+   }

Will you upload it in a separate patch? 
If not, I can merge it in my patch series and upload v4.


Best Regards,

Ming Hsiu

> > Signed-off-by: Daniel Kurtz 
> > Signed-off-by: Minghsiu Tsai 
> > 
> > ---
> >   drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c 
> > b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> > index 9e4eb7d..a5ad586 100644
> > --- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> > +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> > @@ -118,7 +118,7 @@ static int mtk_mdp_probe(struct platform_device *pdev)
> > mutex_init(>vpulock);
> >   
> > /* Iterate over sibling MDP function blocks */
> > -   for_each_child_of_node(dev->of_node, node) {
> > +   for_each_child_of_node(dev->of_node->parent, node) {
> > const struct of_device_id *of_id;
> > enum mtk_mdp_comp_type comp_type;
> > int comp_id;
> > 

Re: [PATCH v3 6/6] watchdog: ts4600: add driver for TS-4600 watchdog

[Guenter Roeck]

On 05/14/2017 07:00 PM, Shawn Guo wrote:

On Sun, May 14, 2017 at 07:39:33AM -0700, Guenter Roeck wrote:

On 05/11/2017 12:22 AM, Shawn Guo wrote:

On Fri, May 05, 2017 at 03:32:59PM -0400, Sebastien Bourdelin wrote:

This watchdog is instantiated in a FPGA and can only be access using a
GPIOs bit-banged bus, called the NBUS by Technologic Systems.
The watchdog is made of only one register, called the feed register.
Writing to this register will re-arm the watchdog for a given time (and
enable it if it was disable). It can be disabled by writing a special
value into it.

Signed-off-by: Sebastien Bourdelin 
---
Changes v2 -> v3:
 - rebase on master
 - remove the timeout table to simplify the logic (suggested by
 Guenter Roeck)
 - fix the set_timeout function (suggested by Guenter Roeck)
 - hardcode the max_hw_heartbeat_ms value based on the ts4600 max
 timeout value supported (suggested by Guenter Roeck)
 - remove the max_timeout usage and set a default timeout value
(suggested by Guenter Roeck)
 - use the devm_watchdog_register_device function instead of
 watchdog_register_device (suggested by Guenter Roeck)

Changes v1 -> v2:
 - rebase on master
 - retrieve the ts_nbus instantiated by the parent node (suggested by
 Linus Walleij)
 - rename the wdt by watchdog in the device tree and in the
 documentation (suggested by Rob Herring)
 - add a dependency to the TS_NBUS driver in the Kconfig (suggested by
 Guenter Roeck)
 - simplify the set_timeout function (suggested by Guenter Roeck)
 - use the max_hw_heartbeat_ms callback instead of the max_timeout
 callback (suggested by Guenter Roeck)
---
.../devicetree/bindings/watchdog/ts4600-wdt.txt|  16 ++
arch/arm/boot/dts/imx28-ts4600-common.dtsi |   5 +


The dts change shouldn't be mixed within driver patch.



Maybe, but Rob Acked the devicetree changes, so I don't see a reason
for splitting it up now.


What Rob Acked is devicetree bindings, and ARM dts changes should
normally go via arm-soc tree, unless there is a good reason they
shouldn't.


Ok, good point.

Guenter

Re: [PATCH v3 6/6] watchdog: ts4600: add driver for TS-4600 watchdog

[Guenter Roeck]

On 05/14/2017 07:00 PM, Shawn Guo wrote:

On Sun, May 14, 2017 at 07:39:33AM -0700, Guenter Roeck wrote:

On 05/11/2017 12:22 AM, Shawn Guo wrote:

On Fri, May 05, 2017 at 03:32:59PM -0400, Sebastien Bourdelin wrote:

This watchdog is instantiated in a FPGA and can only be access using a
GPIOs bit-banged bus, called the NBUS by Technologic Systems.
The watchdog is made of only one register, called the feed register.
Writing to this register will re-arm the watchdog for a given time (and
enable it if it was disable). It can be disabled by writing a special
value into it.

Signed-off-by: Sebastien Bourdelin 
---
Changes v2 -> v3:
 - rebase on master
 - remove the timeout table to simplify the logic (suggested by
 Guenter Roeck)
 - fix the set_timeout function (suggested by Guenter Roeck)
 - hardcode the max_hw_heartbeat_ms value based on the ts4600 max
 timeout value supported (suggested by Guenter Roeck)
 - remove the max_timeout usage and set a default timeout value
(suggested by Guenter Roeck)
 - use the devm_watchdog_register_device function instead of
 watchdog_register_device (suggested by Guenter Roeck)

Changes v1 -> v2:
 - rebase on master
 - retrieve the ts_nbus instantiated by the parent node (suggested by
 Linus Walleij)
 - rename the wdt by watchdog in the device tree and in the
 documentation (suggested by Rob Herring)
 - add a dependency to the TS_NBUS driver in the Kconfig (suggested by
 Guenter Roeck)
 - simplify the set_timeout function (suggested by Guenter Roeck)
 - use the max_hw_heartbeat_ms callback instead of the max_timeout
 callback (suggested by Guenter Roeck)
---
.../devicetree/bindings/watchdog/ts4600-wdt.txt|  16 ++
arch/arm/boot/dts/imx28-ts4600-common.dtsi |   5 +


The dts change shouldn't be mixed within driver patch.



Maybe, but Rob Acked the devicetree changes, so I don't see a reason
for splitting it up now.


What Rob Acked is devicetree bindings, and ARM dts changes should
normally go via arm-soc tree, unless there is a good reason they
shouldn't.


Ok, good point.

Guenter