[PATCH v8 3/7] irqdomain: Factor out code to add and remove items to and from the revmap

[David Daney]

The code to add and remove items to and from the revmap occurs several
times.

In preparation for the follow on patches that add more uses of this
code, factor this out in to separate static functions.

Signed-off-by: David Daney 
---
 kernel/irq/irqdomain.c | 58 +-
 1 file changed, 29 insertions(+), 29 deletions(-)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index f1f2514..2093b88 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -455,6 +455,31 @@ void irq_set_default_host(struct irq_domain *domain)
 }
 EXPORT_SYMBOL_GPL(irq_set_default_host);
 
+static void irq_domain_clear_mapping(struct irq_domain *domain,
+irq_hw_number_t hwirq)
+{
+   if (hwirq < domain->revmap_size) {
+   domain->linear_revmap[hwirq] = 0;
+   } else {
+   mutex_lock(_trees_mutex);
+   radix_tree_delete(>revmap_tree, hwirq);
+   mutex_unlock(_trees_mutex);
+   }
+}
+
+static void irq_domain_set_mapping(struct irq_domain *domain,
+  irq_hw_number_t hwirq,
+  struct irq_data *irq_data)
+{
+   if (hwirq < domain->revmap_size) {
+   domain->linear_revmap[hwirq] = irq_data->irq;
+   } else {
+   mutex_lock(_trees_mutex);
+   radix_tree_insert(>revmap_tree, hwirq, irq_data);
+   mutex_unlock(_trees_mutex);
+   }
+}
+
 void irq_domain_disassociate(struct irq_domain *domain, unsigned int irq)
 {
struct irq_data *irq_data = irq_get_irq_data(irq);
@@ -483,13 +508,7 @@ void irq_domain_disassociate(struct irq_domain *domain, 
unsigned int irq)
domain->mapcount--;
 
/* Clear reverse map for this hwirq */
-   if (hwirq < domain->revmap_size) {
-   domain->linear_revmap[hwirq] = 0;
-   } else {
-   mutex_lock(_trees_mutex);
-   radix_tree_delete(>revmap_tree, hwirq);
-   mutex_unlock(_trees_mutex);
-   }
+   irq_domain_clear_mapping(domain, hwirq);
 }
 
 int irq_domain_associate(struct irq_domain *domain, unsigned int virq,
@@ -533,13 +552,7 @@ int irq_domain_associate(struct irq_domain *domain, 
unsigned int virq,
}
 
domain->mapcount++;
-   if (hwirq < domain->revmap_size) {
-   domain->linear_revmap[hwirq] = virq;
-   } else {
-   mutex_lock(_trees_mutex);
-   radix_tree_insert(>revmap_tree, hwirq, irq_data);
-   mutex_unlock(_trees_mutex);
-   }
+   irq_domain_set_mapping(domain, hwirq, irq_data);
mutex_unlock(_domain_mutex);
 
irq_clear_status_flags(virq, IRQ_NOREQUEST);
@@ -1138,16 +1151,9 @@ static void irq_domain_insert_irq(int virq)
 
for (data = irq_get_irq_data(virq); data; data = data->parent_data) {
struct irq_domain *domain = data->domain;
-   irq_hw_number_t hwirq = data->hwirq;
 
domain->mapcount++;
-   if (hwirq < domain->revmap_size) {
-   domain->linear_revmap[hwirq] = virq;
-   } else {
-   mutex_lock(_trees_mutex);
-   radix_tree_insert(>revmap_tree, hwirq, data);
-   mutex_unlock(_trees_mutex);
-   }
+   irq_domain_set_mapping(domain, data->hwirq, data);
 
/* If not already assigned, give the domain the chip's name */
if (!domain->name && data->chip)
@@ -1171,13 +1177,7 @@ static void irq_domain_remove_irq(int virq)
irq_hw_number_t hwirq = data->hwirq;
 
domain->mapcount--;
-   if (hwirq < domain->revmap_size) {
-   domain->linear_revmap[hwirq] = 0;
-   } else {
-   mutex_lock(_trees_mutex);
-   radix_tree_delete(>revmap_tree, hwirq);
-   mutex_unlock(_trees_mutex);
-   }
+   irq_domain_clear_mapping(domain, hwirq);
}
 }
 
-- 
1.8.3.1

[PATCH v8 3/7] irqdomain: Factor out code to add and remove items to and from the revmap

[David Daney]

The code to add and remove items to and from the revmap occurs several
times.

In preparation for the follow on patches that add more uses of this
code, factor this out in to separate static functions.

Signed-off-by: David Daney 
---
 kernel/irq/irqdomain.c | 58 +-
 1 file changed, 29 insertions(+), 29 deletions(-)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index f1f2514..2093b88 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -455,6 +455,31 @@ void irq_set_default_host(struct irq_domain *domain)
 }
 EXPORT_SYMBOL_GPL(irq_set_default_host);
 
+static void irq_domain_clear_mapping(struct irq_domain *domain,
+irq_hw_number_t hwirq)
+{
+   if (hwirq < domain->revmap_size) {
+   domain->linear_revmap[hwirq] = 0;
+   } else {
+   mutex_lock(_trees_mutex);
+   radix_tree_delete(>revmap_tree, hwirq);
+   mutex_unlock(_trees_mutex);
+   }
+}
+
+static void irq_domain_set_mapping(struct irq_domain *domain,
+  irq_hw_number_t hwirq,
+  struct irq_data *irq_data)
+{
+   if (hwirq < domain->revmap_size) {
+   domain->linear_revmap[hwirq] = irq_data->irq;
+   } else {
+   mutex_lock(_trees_mutex);
+   radix_tree_insert(>revmap_tree, hwirq, irq_data);
+   mutex_unlock(_trees_mutex);
+   }
+}
+
 void irq_domain_disassociate(struct irq_domain *domain, unsigned int irq)
 {
struct irq_data *irq_data = irq_get_irq_data(irq);
@@ -483,13 +508,7 @@ void irq_domain_disassociate(struct irq_domain *domain, 
unsigned int irq)
domain->mapcount--;
 
/* Clear reverse map for this hwirq */
-   if (hwirq < domain->revmap_size) {
-   domain->linear_revmap[hwirq] = 0;
-   } else {
-   mutex_lock(_trees_mutex);
-   radix_tree_delete(>revmap_tree, hwirq);
-   mutex_unlock(_trees_mutex);
-   }
+   irq_domain_clear_mapping(domain, hwirq);
 }
 
 int irq_domain_associate(struct irq_domain *domain, unsigned int virq,
@@ -533,13 +552,7 @@ int irq_domain_associate(struct irq_domain *domain, 
unsigned int virq,
}
 
domain->mapcount++;
-   if (hwirq < domain->revmap_size) {
-   domain->linear_revmap[hwirq] = virq;
-   } else {
-   mutex_lock(_trees_mutex);
-   radix_tree_insert(>revmap_tree, hwirq, irq_data);
-   mutex_unlock(_trees_mutex);
-   }
+   irq_domain_set_mapping(domain, hwirq, irq_data);
mutex_unlock(_domain_mutex);
 
irq_clear_status_flags(virq, IRQ_NOREQUEST);
@@ -1138,16 +1151,9 @@ static void irq_domain_insert_irq(int virq)
 
for (data = irq_get_irq_data(virq); data; data = data->parent_data) {
struct irq_domain *domain = data->domain;
-   irq_hw_number_t hwirq = data->hwirq;
 
domain->mapcount++;
-   if (hwirq < domain->revmap_size) {
-   domain->linear_revmap[hwirq] = virq;
-   } else {
-   mutex_lock(_trees_mutex);
-   radix_tree_insert(>revmap_tree, hwirq, data);
-   mutex_unlock(_trees_mutex);
-   }
+   irq_domain_set_mapping(domain, data->hwirq, data);
 
/* If not already assigned, give the domain the chip's name */
if (!domain->name && data->chip)
@@ -1171,13 +1177,7 @@ static void irq_domain_remove_irq(int virq)
irq_hw_number_t hwirq = data->hwirq;
 
domain->mapcount--;
-   if (hwirq < domain->revmap_size) {
-   domain->linear_revmap[hwirq] = 0;
-   } else {
-   mutex_lock(_trees_mutex);
-   radix_tree_delete(>revmap_tree, hwirq);
-   mutex_unlock(_trees_mutex);
-   }
+   irq_domain_clear_mapping(domain, hwirq);
}
 }
 
-- 
1.8.3.1

[PATCH v8 0/7] genirq/gpio: Add driver for ThunderX and OCTEON-TX SoCs

[David Daney]

The ThunderX/OCTEON-TX GPIO hardware looks like a PCIe device, with
the interrupt signal from each GPIO line being routed to a dedicated
MSI-X.  This interrupt routing requires that we add some custom
processing to the beginning of the MSI-X irqdomain hierarchy.

Changes from v7:

 - Refactoring of irqdomain.c changes as suggested by Marc Zyngier.

 - Renaming of new handler functions in chip.c and making building of
   these conditional on a Kconfig variable, suggested by Thomas Gleixner.

Changes from v6:

 - Trivial rebase to v4.13.0-rc4:  Omit device tree bindings patch,
   which was already merged, and fix MAINTAINERS patch collision.

Changes from v5:

 - Added .irq_{request,release}_resources() functions to irq_chip.

 - Quit calling irq_set_irq_type() in the irq_map() function.

 - Added more error condition checking to irq_domain_{push,pop}_irq()

Changes from v4:

 - Rebased to post-v4.10 to support .set_config() function.

 - Added .get_direction() support.

 - Added PIN_CONFIG_INPUT_DEBOUNCE support.

 - Removed some improper use of ENOSYS.

Changes from v3:

 - Add some "depends on" to the driver Kconfig to avoid build errors
   in some architectures when doing COMPILE_TEST builds.

Changes from v2:

 - in 4/6: Added Rob Harring's Acked-by

 - Added three patches to genirq/irqdomain to support interrupt code
   in the driver.

 - Rewrite irq code in driver to use irqdomain hierarchy.

 - Other naming and style changes as recommended by Linus Walleij.

Changes from v1:

 - in 1/3: Addressed Rob Harring's comments.

 - in 2/3: Trivial cleanups found in internal review + add some
   comments.

David Daney (7):
  genirq: Export more irq_chip_*_parent() functions.
  genirq: Add handle_fasteoi_{level,edge}_irq flow handlers.
  irqdomain: Factor out code to add and remove items to and from the
revmap
  irqdomain: Check for NULL function pointer in
irq_domain_free_irqs_hierarchy()
  irqdomain: Add irq_domain_{push,pop}_irq() functions.
  gpio: Add gpio driver support for ThunderX and OCTEON-TX
  MAINTAINERS: Add entry for THUNDERX GPIO Driver.

 MAINTAINERS  |   5 +
 drivers/gpio/Kconfig |   9 +
 drivers/gpio/Makefile|   1 +
 drivers/gpio/gpio-thunderx.c | 639 +++
 include/linux/irq.h  |   2 +
 include/linux/irqdomain.h|   3 +
 kernel/irq/Kconfig   |   4 +
 kernel/irq/chip.c| 109 
 kernel/irq/irqdomain.c   | 230 ++--
 9 files changed, 972 insertions(+), 30 deletions(-)
 create mode 100644 drivers/gpio/gpio-thunderx.c

-- 
1.8.3.1

[PATCH v8 0/7] genirq/gpio: Add driver for ThunderX and OCTEON-TX SoCs

[David Daney]

The ThunderX/OCTEON-TX GPIO hardware looks like a PCIe device, with
the interrupt signal from each GPIO line being routed to a dedicated
MSI-X.  This interrupt routing requires that we add some custom
processing to the beginning of the MSI-X irqdomain hierarchy.

Changes from v7:

 - Refactoring of irqdomain.c changes as suggested by Marc Zyngier.

 - Renaming of new handler functions in chip.c and making building of
   these conditional on a Kconfig variable, suggested by Thomas Gleixner.

Changes from v6:

 - Trivial rebase to v4.13.0-rc4:  Omit device tree bindings patch,
   which was already merged, and fix MAINTAINERS patch collision.

Changes from v5:

 - Added .irq_{request,release}_resources() functions to irq_chip.

 - Quit calling irq_set_irq_type() in the irq_map() function.

 - Added more error condition checking to irq_domain_{push,pop}_irq()

Changes from v4:

 - Rebased to post-v4.10 to support .set_config() function.

 - Added .get_direction() support.

 - Added PIN_CONFIG_INPUT_DEBOUNCE support.

 - Removed some improper use of ENOSYS.

Changes from v3:

 - Add some "depends on" to the driver Kconfig to avoid build errors
   in some architectures when doing COMPILE_TEST builds.

Changes from v2:

 - in 4/6: Added Rob Harring's Acked-by

 - Added three patches to genirq/irqdomain to support interrupt code
   in the driver.

 - Rewrite irq code in driver to use irqdomain hierarchy.

 - Other naming and style changes as recommended by Linus Walleij.

Changes from v1:

 - in 1/3: Addressed Rob Harring's comments.

 - in 2/3: Trivial cleanups found in internal review + add some
   comments.

David Daney (7):
  genirq: Export more irq_chip_*_parent() functions.
  genirq: Add handle_fasteoi_{level,edge}_irq flow handlers.
  irqdomain: Factor out code to add and remove items to and from the
revmap
  irqdomain: Check for NULL function pointer in
irq_domain_free_irqs_hierarchy()
  irqdomain: Add irq_domain_{push,pop}_irq() functions.
  gpio: Add gpio driver support for ThunderX and OCTEON-TX
  MAINTAINERS: Add entry for THUNDERX GPIO Driver.

 MAINTAINERS  |   5 +
 drivers/gpio/Kconfig |   9 +
 drivers/gpio/Makefile|   1 +
 drivers/gpio/gpio-thunderx.c | 639 +++
 include/linux/irq.h  |   2 +
 include/linux/irqdomain.h|   3 +
 kernel/irq/Kconfig   |   4 +
 kernel/irq/chip.c| 109 
 kernel/irq/irqdomain.c   | 230 ++--
 9 files changed, 972 insertions(+), 30 deletions(-)
 create mode 100644 drivers/gpio/gpio-thunderx.c

-- 
1.8.3.1

[PATCH v8 4/7] irqdomain: Check for NULL function pointer in irq_domain_free_irqs_hierarchy()

[David Daney]

A follow-on patch will call irq_domain_free_irqs_hierarchy() when the
free() function pointer may be NULL.

Add a NULL pointer check to handle this new use case.

Signed-off-by: David Daney 
---
 kernel/irq/irqdomain.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 2093b88..24fda75 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -1362,7 +1362,8 @@ static void irq_domain_free_irqs_hierarchy(struct 
irq_domain *domain,
   unsigned int irq_base,
   unsigned int nr_irqs)
 {
-   domain->ops->free(domain, irq_base, nr_irqs);
+   if (domain->ops->free)
+   domain->ops->free(domain, irq_base, nr_irqs);
 }
 
 int irq_domain_alloc_irqs_hierarchy(struct irq_domain *domain,
-- 
1.8.3.1

[PATCH v8 4/7] irqdomain: Check for NULL function pointer in irq_domain_free_irqs_hierarchy()

[David Daney]

A follow-on patch will call irq_domain_free_irqs_hierarchy() when the
free() function pointer may be NULL.

Add a NULL pointer check to handle this new use case.

Signed-off-by: David Daney 
---
 kernel/irq/irqdomain.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 2093b88..24fda75 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -1362,7 +1362,8 @@ static void irq_domain_free_irqs_hierarchy(struct 
irq_domain *domain,
   unsigned int irq_base,
   unsigned int nr_irqs)
 {
-   domain->ops->free(domain, irq_base, nr_irqs);
+   if (domain->ops->free)
+   domain->ops->free(domain, irq_base, nr_irqs);
 }
 
 int irq_domain_alloc_irqs_hierarchy(struct irq_domain *domain,
-- 
1.8.3.1

[PATCH v8 6/7] gpio: Add gpio driver support for ThunderX and OCTEON-TX

[David Daney]

Cavium ThunderX and OCTEON-TX are arm64 based SoCs.  Add driver for
the on-chip GPIO pins.

Signed-off-by: David Daney 
---
 drivers/gpio/Kconfig |   9 +
 drivers/gpio/Makefile|   1 +
 drivers/gpio/gpio-thunderx.c | 639 +++
 3 files changed, 649 insertions(+)
 create mode 100644 drivers/gpio/gpio-thunderx.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 461d6fc..ddf6643 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -450,6 +450,15 @@ config GPIO_TS4800
help
  This driver support TS-4800 FPGA GPIO controllers.
 
+config GPIO_THUNDERX
+   tristate "Cavium ThunderX/OCTEON-TX GPIO"
+   depends on ARCH_THUNDER || (64BIT && COMPILE_TEST)
+   depends on PCI_MSI && IRQ_DOMAIN_HIERARCHY
+   select IRQ_FASTEOI_HIERARCHY_HANDLERS
+   help
+ Say yes here to support the on-chip GPIO lines on the ThunderX
+ and OCTEON-TX families of SoCs.
+
 config GPIO_TZ1090
bool "Toumaz Xenif TZ1090 GPIO support"
depends on SOC_TZ1090
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index a9fda6c..9ae168a 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -113,6 +113,7 @@ obj-$(CONFIG_GPIO_SYSCON)   += gpio-syscon.o
 obj-$(CONFIG_GPIO_TB10X)   += gpio-tb10x.o
 obj-$(CONFIG_GPIO_TC3589X) += gpio-tc3589x.o
 obj-$(CONFIG_GPIO_TEGRA)   += gpio-tegra.o
+obj-$(CONFIG_GPIO_THUNDERX)+= gpio-thunderx.o
 obj-$(CONFIG_GPIO_TIMBERDALE)  += gpio-timberdale.o
 obj-$(CONFIG_GPIO_PALMAS)  += gpio-palmas.o
 obj-$(CONFIG_GPIO_TPIC2810)+= gpio-tpic2810.o
diff --git a/drivers/gpio/gpio-thunderx.c b/drivers/gpio/gpio-thunderx.c
new file mode 100644
index 000..57efb25
--- /dev/null
+++ b/drivers/gpio/gpio-thunderx.c
@@ -0,0 +1,639 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2016, 2017 Cavium Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+#define GPIO_RX_DAT0x0
+#define GPIO_TX_SET0x8
+#define GPIO_TX_CLR0x10
+#define GPIO_CONST 0x90
+#define  GPIO_CONST_GPIOS_MASK 0xff
+#define GPIO_BIT_CFG   0x400
+#define  GPIO_BIT_CFG_TX_OEBIT(0)
+#define  GPIO_BIT_CFG_PIN_XOR  BIT(1)
+#define  GPIO_BIT_CFG_INT_EN   BIT(2)
+#define  GPIO_BIT_CFG_INT_TYPE BIT(3)
+#define  GPIO_BIT_CFG_FIL_MASK GENMASK(11, 4)
+#define  GPIO_BIT_CFG_FIL_CNT_SHIFT4
+#define  GPIO_BIT_CFG_FIL_SEL_SHIFT8
+#define  GPIO_BIT_CFG_TX_ODBIT(12)
+#define  GPIO_BIT_CFG_PIN_SEL_MASK GENMASK(25, 16)
+#define GPIO_INTR  0x800
+#define  GPIO_INTR_INTRBIT(0)
+#define  GPIO_INTR_INTR_W1SBIT(1)
+#define  GPIO_INTR_ENA_W1C BIT(2)
+#define  GPIO_INTR_ENA_W1S BIT(3)
+#define GPIO_2ND_BANK  0x1400
+
+#define GLITCH_FILTER_400NS ((4u << GPIO_BIT_CFG_FIL_SEL_SHIFT) | \
+(9u << GPIO_BIT_CFG_FIL_CNT_SHIFT))
+
+struct thunderx_gpio;
+
+struct thunderx_line {
+   struct thunderx_gpio*txgpio;
+   unsigned intline;
+   unsigned intfil_bits;
+};
+
+struct thunderx_gpio {
+   struct gpio_chipchip;
+   u8 __iomem  *register_base;
+   struct irq_domain   *irqd;
+   struct msix_entry   *msix_entries;  /* per line MSI-X */
+   struct thunderx_line*line_entries;  /* per line irq info */
+   raw_spinlock_t  lock;
+   unsigned long   invert_mask[2];
+   unsigned long   od_mask[2];
+   int base_msi;
+};
+
+static unsigned int bit_cfg_reg(unsigned int line)
+{
+   return 8 * line + GPIO_BIT_CFG;
+}
+
+static unsigned int intr_reg(unsigned int line)
+{
+   return 8 * line + GPIO_INTR;
+}
+
+static bool thunderx_gpio_is_gpio_nowarn(struct thunderx_gpio *txgpio,
+unsigned int line)
+{
+   u64 bit_cfg = readq(txgpio->register_base + bit_cfg_reg(line));
+
+   return (bit_cfg & GPIO_BIT_CFG_PIN_SEL_MASK) == 0;
+}
+
+/*
+ * Check (and WARN) that the pin is available for GPIO.  We will not
+ * allow modification of the state of non-GPIO pins from this driver.
+ */
+static bool thunderx_gpio_is_gpio(struct thunderx_gpio *txgpio,
+ unsigned int line)
+{
+   bool rv = thunderx_gpio_is_gpio_nowarn(txgpio, line);
+
+   WARN_RATELIMIT(!rv, "Pin %d not available for GPIO\n", line);
+
+   return rv;
+}
+
+static int thunderx_gpio_request(struct gpio_chip *chip, unsigned int line)
+{
+   struct thunderx_gpio *txgpio = gpiochip_get_data(chip);
+
+   return thunderx_gpio_is_gpio(txgpio, line) ? 0 : -EIO;
+}
+
+static int thunderx_gpio_dir_in(struct gpio_chip 

[PATCH v8 6/7] gpio: Add gpio driver support for ThunderX and OCTEON-TX

[David Daney]

Cavium ThunderX and OCTEON-TX are arm64 based SoCs.  Add driver for
the on-chip GPIO pins.

Signed-off-by: David Daney 
---
 drivers/gpio/Kconfig |   9 +
 drivers/gpio/Makefile|   1 +
 drivers/gpio/gpio-thunderx.c | 639 +++
 3 files changed, 649 insertions(+)
 create mode 100644 drivers/gpio/gpio-thunderx.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 461d6fc..ddf6643 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -450,6 +450,15 @@ config GPIO_TS4800
help
  This driver support TS-4800 FPGA GPIO controllers.
 
+config GPIO_THUNDERX
+   tristate "Cavium ThunderX/OCTEON-TX GPIO"
+   depends on ARCH_THUNDER || (64BIT && COMPILE_TEST)
+   depends on PCI_MSI && IRQ_DOMAIN_HIERARCHY
+   select IRQ_FASTEOI_HIERARCHY_HANDLERS
+   help
+ Say yes here to support the on-chip GPIO lines on the ThunderX
+ and OCTEON-TX families of SoCs.
+
 config GPIO_TZ1090
bool "Toumaz Xenif TZ1090 GPIO support"
depends on SOC_TZ1090
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index a9fda6c..9ae168a 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -113,6 +113,7 @@ obj-$(CONFIG_GPIO_SYSCON)   += gpio-syscon.o
 obj-$(CONFIG_GPIO_TB10X)   += gpio-tb10x.o
 obj-$(CONFIG_GPIO_TC3589X) += gpio-tc3589x.o
 obj-$(CONFIG_GPIO_TEGRA)   += gpio-tegra.o
+obj-$(CONFIG_GPIO_THUNDERX)+= gpio-thunderx.o
 obj-$(CONFIG_GPIO_TIMBERDALE)  += gpio-timberdale.o
 obj-$(CONFIG_GPIO_PALMAS)  += gpio-palmas.o
 obj-$(CONFIG_GPIO_TPIC2810)+= gpio-tpic2810.o
diff --git a/drivers/gpio/gpio-thunderx.c b/drivers/gpio/gpio-thunderx.c
new file mode 100644
index 000..57efb25
--- /dev/null
+++ b/drivers/gpio/gpio-thunderx.c
@@ -0,0 +1,639 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2016, 2017 Cavium Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+#define GPIO_RX_DAT0x0
+#define GPIO_TX_SET0x8
+#define GPIO_TX_CLR0x10
+#define GPIO_CONST 0x90
+#define  GPIO_CONST_GPIOS_MASK 0xff
+#define GPIO_BIT_CFG   0x400
+#define  GPIO_BIT_CFG_TX_OEBIT(0)
+#define  GPIO_BIT_CFG_PIN_XOR  BIT(1)
+#define  GPIO_BIT_CFG_INT_EN   BIT(2)
+#define  GPIO_BIT_CFG_INT_TYPE BIT(3)
+#define  GPIO_BIT_CFG_FIL_MASK GENMASK(11, 4)
+#define  GPIO_BIT_CFG_FIL_CNT_SHIFT4
+#define  GPIO_BIT_CFG_FIL_SEL_SHIFT8
+#define  GPIO_BIT_CFG_TX_ODBIT(12)
+#define  GPIO_BIT_CFG_PIN_SEL_MASK GENMASK(25, 16)
+#define GPIO_INTR  0x800
+#define  GPIO_INTR_INTRBIT(0)
+#define  GPIO_INTR_INTR_W1SBIT(1)
+#define  GPIO_INTR_ENA_W1C BIT(2)
+#define  GPIO_INTR_ENA_W1S BIT(3)
+#define GPIO_2ND_BANK  0x1400
+
+#define GLITCH_FILTER_400NS ((4u << GPIO_BIT_CFG_FIL_SEL_SHIFT) | \
+(9u << GPIO_BIT_CFG_FIL_CNT_SHIFT))
+
+struct thunderx_gpio;
+
+struct thunderx_line {
+   struct thunderx_gpio*txgpio;
+   unsigned intline;
+   unsigned intfil_bits;
+};
+
+struct thunderx_gpio {
+   struct gpio_chipchip;
+   u8 __iomem  *register_base;
+   struct irq_domain   *irqd;
+   struct msix_entry   *msix_entries;  /* per line MSI-X */
+   struct thunderx_line*line_entries;  /* per line irq info */
+   raw_spinlock_t  lock;
+   unsigned long   invert_mask[2];
+   unsigned long   od_mask[2];
+   int base_msi;
+};
+
+static unsigned int bit_cfg_reg(unsigned int line)
+{
+   return 8 * line + GPIO_BIT_CFG;
+}
+
+static unsigned int intr_reg(unsigned int line)
+{
+   return 8 * line + GPIO_INTR;
+}
+
+static bool thunderx_gpio_is_gpio_nowarn(struct thunderx_gpio *txgpio,
+unsigned int line)
+{
+   u64 bit_cfg = readq(txgpio->register_base + bit_cfg_reg(line));
+
+   return (bit_cfg & GPIO_BIT_CFG_PIN_SEL_MASK) == 0;
+}
+
+/*
+ * Check (and WARN) that the pin is available for GPIO.  We will not
+ * allow modification of the state of non-GPIO pins from this driver.
+ */
+static bool thunderx_gpio_is_gpio(struct thunderx_gpio *txgpio,
+ unsigned int line)
+{
+   bool rv = thunderx_gpio_is_gpio_nowarn(txgpio, line);
+
+   WARN_RATELIMIT(!rv, "Pin %d not available for GPIO\n", line);
+
+   return rv;
+}
+
+static int thunderx_gpio_request(struct gpio_chip *chip, unsigned int line)
+{
+   struct thunderx_gpio *txgpio = gpiochip_get_data(chip);
+
+   return thunderx_gpio_is_gpio(txgpio, line) ? 0 : -EIO;
+}
+
+static int thunderx_gpio_dir_in(struct gpio_chip *chip, unsigned int line)

[PATCH v8 5/7] irqdomain: Add irq_domain_{push,pop}_irq() functions.

[David Daney]

For an already existing irqdomain hierarchy, as might be obtained via
a call to pci_enable_msix_range(), a PCI driver wishing to add an
additional irqdomain to the hierarchy needs to be able to insert the
irqdomain to that already initialized hierarchy.  Calling
irq_domain_create_hierarchy() allows the new irqdomain to be created,
but no existing code allows for initializing the associated irq_data.

Add a couple of helper functions (irq_domain_push_irq() and
irq_domain_pop_irq()) to initialize the irq_data for the new
irqdomain added to an existing hierarchy.

Signed-off-by: David Daney 
---
 include/linux/irqdomain.h |   3 +
 kernel/irq/irqdomain.c| 169 ++
 2 files changed, 172 insertions(+)

diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index cac77a5..2318f29 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -460,6 +460,9 @@ extern void irq_domain_free_irqs_common(struct irq_domain 
*domain,
 extern void irq_domain_free_irqs_top(struct irq_domain *domain,
 unsigned int virq, unsigned int nr_irqs);
 
+extern int irq_domain_push_irq(struct irq_domain *domain, int virq, void *arg);
+extern int irq_domain_pop_irq(struct irq_domain *domain, int virq);
+
 extern int irq_domain_alloc_irqs_parent(struct irq_domain *domain,
unsigned int irq_base,
unsigned int nr_irqs, void *arg);
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 24fda75..1ff9912 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -1449,6 +1449,175 @@ int __irq_domain_alloc_irqs(struct irq_domain *domain, 
int irq_base,
return ret;
 }
 
+/* The irq_data was moved, fix the revmap to refer to the new location */
+static void irq_domain_fix_revmap(struct irq_data *d)
+{
+   void **slot;
+
+   if (d->hwirq < d->domain->revmap_size)
+   return; /* Not using radix tree. */
+
+   /* Fix up the revmap. */
+   mutex_lock(_trees_mutex);
+   slot = radix_tree_lookup_slot(>domain->revmap_tree, d->hwirq);
+   if (slot)
+   radix_tree_replace_slot(>domain->revmap_tree, slot, d);
+   mutex_unlock(_trees_mutex);
+}
+
+/**
+ * irq_domain_push_irq() - Push a domain in to the top of a hierarchy.
+ * @domain:Domain to push.
+ * @virq:  Irq to push the domain in to.
+ * @arg:   Passed to the irq_domain_ops alloc() function.
+ *
+ * For an already existing irqdomain hierarchy, as might be obtained
+ * via a call to pci_enable_msix(), add an additional domain to the
+ * head of the processing chain.  Must be called before request_irq()
+ * has been called.
+ */
+int irq_domain_push_irq(struct irq_domain *domain, int virq, void *arg)
+{
+   struct irq_data *child_irq_data;
+   struct irq_data *root_irq_data = irq_get_irq_data(virq);
+   struct irq_desc *desc;
+   int rv = 0;
+
+   /*
+* Check that no action has been set, which indicates the virq
+* is in a state where this function doesn't have to deal with
+* races between interrupt handling and maintaining the
+* hierarchy.  This will catch gross misuse.  Attempting to
+* make the check race free would require holding locks across
+* calls to struct irq_domain_ops->alloc(), which could lead
+* to deadlock, so we just do a simple check before starting.
+*/
+   desc = irq_to_desc(virq);
+   if (!desc)
+   return -EINVAL;
+   if (WARN_ON(desc->action))
+   return -EBUSY;
+
+   if (domain == NULL)
+   return -EINVAL;
+
+   if (WARN_ON(!irq_domain_is_hierarchy(domain)))
+   return -EINVAL;
+
+   if (domain->parent != root_irq_data->domain)
+   return -EINVAL;
+
+   if (!root_irq_data)
+   return -EINVAL;
+
+   child_irq_data = kzalloc_node(sizeof(*child_irq_data), GFP_KERNEL,
+ irq_data_get_node(root_irq_data));
+   if (!child_irq_data)
+   return -ENOMEM;
+
+   mutex_lock(_domain_mutex);
+
+   /* Copy the original irq_data. */
+   *child_irq_data = *root_irq_data;
+
+   /*
+* Overwrite the root_irq_data, which is embedded in struct
+* irq_desc, with values for this domain.
+*/
+   root_irq_data->parent_data = child_irq_data;
+   root_irq_data->domain = domain;
+   root_irq_data->mask = 0;
+   root_irq_data->hwirq = 0;
+   root_irq_data->chip = NULL;
+   root_irq_data->chip_data = NULL;
+
+   /* May (probably does) set hwirq, chip, etc. */
+   rv = irq_domain_alloc_irqs_hierarchy(domain, virq, 1, arg);
+   if (rv) {
+   /* Restore the original irq_data. */
+   *root_irq_data = *child_irq_data;
+   goto error;
+   }
+
+   

[PATCH v8 5/7] irqdomain: Add irq_domain_{push,pop}_irq() functions.

[David Daney]

For an already existing irqdomain hierarchy, as might be obtained via
a call to pci_enable_msix_range(), a PCI driver wishing to add an
additional irqdomain to the hierarchy needs to be able to insert the
irqdomain to that already initialized hierarchy.  Calling
irq_domain_create_hierarchy() allows the new irqdomain to be created,
but no existing code allows for initializing the associated irq_data.

Add a couple of helper functions (irq_domain_push_irq() and
irq_domain_pop_irq()) to initialize the irq_data for the new
irqdomain added to an existing hierarchy.

Signed-off-by: David Daney 
---
 include/linux/irqdomain.h |   3 +
 kernel/irq/irqdomain.c| 169 ++
 2 files changed, 172 insertions(+)

diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index cac77a5..2318f29 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -460,6 +460,9 @@ extern void irq_domain_free_irqs_common(struct irq_domain 
*domain,
 extern void irq_domain_free_irqs_top(struct irq_domain *domain,
 unsigned int virq, unsigned int nr_irqs);
 
+extern int irq_domain_push_irq(struct irq_domain *domain, int virq, void *arg);
+extern int irq_domain_pop_irq(struct irq_domain *domain, int virq);
+
 extern int irq_domain_alloc_irqs_parent(struct irq_domain *domain,
unsigned int irq_base,
unsigned int nr_irqs, void *arg);
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 24fda75..1ff9912 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -1449,6 +1449,175 @@ int __irq_domain_alloc_irqs(struct irq_domain *domain, 
int irq_base,
return ret;
 }
 
+/* The irq_data was moved, fix the revmap to refer to the new location */
+static void irq_domain_fix_revmap(struct irq_data *d)
+{
+   void **slot;
+
+   if (d->hwirq < d->domain->revmap_size)
+   return; /* Not using radix tree. */
+
+   /* Fix up the revmap. */
+   mutex_lock(_trees_mutex);
+   slot = radix_tree_lookup_slot(>domain->revmap_tree, d->hwirq);
+   if (slot)
+   radix_tree_replace_slot(>domain->revmap_tree, slot, d);
+   mutex_unlock(_trees_mutex);
+}
+
+/**
+ * irq_domain_push_irq() - Push a domain in to the top of a hierarchy.
+ * @domain:Domain to push.
+ * @virq:  Irq to push the domain in to.
+ * @arg:   Passed to the irq_domain_ops alloc() function.
+ *
+ * For an already existing irqdomain hierarchy, as might be obtained
+ * via a call to pci_enable_msix(), add an additional domain to the
+ * head of the processing chain.  Must be called before request_irq()
+ * has been called.
+ */
+int irq_domain_push_irq(struct irq_domain *domain, int virq, void *arg)
+{
+   struct irq_data *child_irq_data;
+   struct irq_data *root_irq_data = irq_get_irq_data(virq);
+   struct irq_desc *desc;
+   int rv = 0;
+
+   /*
+* Check that no action has been set, which indicates the virq
+* is in a state where this function doesn't have to deal with
+* races between interrupt handling and maintaining the
+* hierarchy.  This will catch gross misuse.  Attempting to
+* make the check race free would require holding locks across
+* calls to struct irq_domain_ops->alloc(), which could lead
+* to deadlock, so we just do a simple check before starting.
+*/
+   desc = irq_to_desc(virq);
+   if (!desc)
+   return -EINVAL;
+   if (WARN_ON(desc->action))
+   return -EBUSY;
+
+   if (domain == NULL)
+   return -EINVAL;
+
+   if (WARN_ON(!irq_domain_is_hierarchy(domain)))
+   return -EINVAL;
+
+   if (domain->parent != root_irq_data->domain)
+   return -EINVAL;
+
+   if (!root_irq_data)
+   return -EINVAL;
+
+   child_irq_data = kzalloc_node(sizeof(*child_irq_data), GFP_KERNEL,
+ irq_data_get_node(root_irq_data));
+   if (!child_irq_data)
+   return -ENOMEM;
+
+   mutex_lock(_domain_mutex);
+
+   /* Copy the original irq_data. */
+   *child_irq_data = *root_irq_data;
+
+   /*
+* Overwrite the root_irq_data, which is embedded in struct
+* irq_desc, with values for this domain.
+*/
+   root_irq_data->parent_data = child_irq_data;
+   root_irq_data->domain = domain;
+   root_irq_data->mask = 0;
+   root_irq_data->hwirq = 0;
+   root_irq_data->chip = NULL;
+   root_irq_data->chip_data = NULL;
+
+   /* May (probably does) set hwirq, chip, etc. */
+   rv = irq_domain_alloc_irqs_hierarchy(domain, virq, 1, arg);
+   if (rv) {
+   /* Restore the original irq_data. */
+   *root_irq_data = *child_irq_data;
+   goto error;
+   }
+
+   irq_domain_fix_revmap(child_irq_data);
+ 

[PATCH v8 7/7] MAINTAINERS: Add entry for THUNDERX GPIO Driver.

[David Daney]

Signed-off-by: David Daney 
---
 MAINTAINERS | 5 +
 1 file changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6f7721d..67d4000 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12993,6 +12993,11 @@ M: Yehezkel Bernat 
 S: Maintained
 F: drivers/thunderbolt/
 
+THUNDERX GPIO DRIVER
+M: David Daney 
+S: Maintained
+F: drivers/gpio/gpio-thunderx.c
+
 TI AM437X VPFE DRIVER
 M: "Lad, Prabhakar" 
 L: linux-me...@vger.kernel.org
-- 
1.8.3.1

[PATCH v8 7/7] MAINTAINERS: Add entry for THUNDERX GPIO Driver.

[David Daney]

Signed-off-by: David Daney 
---
 MAINTAINERS | 5 +
 1 file changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6f7721d..67d4000 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12993,6 +12993,11 @@ M: Yehezkel Bernat 
 S: Maintained
 F: drivers/thunderbolt/
 
+THUNDERX GPIO DRIVER
+M: David Daney 
+S: Maintained
+F: drivers/gpio/gpio-thunderx.c
+
 TI AM437X VPFE DRIVER
 M: "Lad, Prabhakar" 
 L: linux-me...@vger.kernel.org
-- 
1.8.3.1

[PATCH v8 1/7] genirq: Export more irq_chip_*_parent() functions.

[David Daney]

Many of the family of functions including irq_chip_mask_parent(),
irq_chip_unmask_parent() are exported, but not all.

Add EXPORT_SYMBOL_GPL to irq_chip_enable_parent,
irq_chip_disable_parent and irq_chip_set_affinity_parent, so they
likewise are usable from modules.

Signed-off-by: David Daney 
---
 kernel/irq/chip.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index a3cc37c..6514f07 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -1105,6 +1105,7 @@ void irq_chip_enable_parent(struct irq_data *data)
else
data->chip->irq_unmask(data);
 }
+EXPORT_SYMBOL_GPL(irq_chip_enable_parent);
 
 /**
  * irq_chip_disable_parent - Disable the parent interrupt (defaults to mask if
@@ -1119,6 +1120,7 @@ void irq_chip_disable_parent(struct irq_data *data)
else
data->chip->irq_mask(data);
 }
+EXPORT_SYMBOL_GPL(irq_chip_disable_parent);
 
 /**
  * irq_chip_ack_parent - Acknowledge the parent interrupt
@@ -1181,6 +1183,7 @@ int irq_chip_set_affinity_parent(struct irq_data *data,
 
return -ENOSYS;
 }
+EXPORT_SYMBOL_GPL(irq_chip_set_affinity_parent);
 
 /**
  * irq_chip_set_type_parent - Set IRQ type on the parent interrupt
-- 
1.8.3.1

[PATCH v8 1/7] genirq: Export more irq_chip_*_parent() functions.

[David Daney]

Many of the family of functions including irq_chip_mask_parent(),
irq_chip_unmask_parent() are exported, but not all.

Add EXPORT_SYMBOL_GPL to irq_chip_enable_parent,
irq_chip_disable_parent and irq_chip_set_affinity_parent, so they
likewise are usable from modules.

Signed-off-by: David Daney 
---
 kernel/irq/chip.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index a3cc37c..6514f07 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -1105,6 +1105,7 @@ void irq_chip_enable_parent(struct irq_data *data)
else
data->chip->irq_unmask(data);
 }
+EXPORT_SYMBOL_GPL(irq_chip_enable_parent);
 
 /**
  * irq_chip_disable_parent - Disable the parent interrupt (defaults to mask if
@@ -1119,6 +1120,7 @@ void irq_chip_disable_parent(struct irq_data *data)
else
data->chip->irq_mask(data);
 }
+EXPORT_SYMBOL_GPL(irq_chip_disable_parent);
 
 /**
  * irq_chip_ack_parent - Acknowledge the parent interrupt
@@ -1181,6 +1183,7 @@ int irq_chip_set_affinity_parent(struct irq_data *data,
 
return -ENOSYS;
 }
+EXPORT_SYMBOL_GPL(irq_chip_set_affinity_parent);
 
 /**
  * irq_chip_set_type_parent - Set IRQ type on the parent interrupt
-- 
1.8.3.1

Re: [PATCH] iommu: Avoid NULL group dereference

[Shawn Lin]

Hi

On 2017/8/17 18:40, Robin Murphy wrote:

The recently-removed FIXME in iommu_get_domain_for_dev() turns out to
have been a little misleading, since that check is still worthwhile even
when groups *are* universal. We have a few IOMMU-aware drivers which
only care whether their device is already attached to an existing domain
or not, for which the previous behaviour of iommu_get_domain_for_dev()
was ideal, and who now crash if their device does not have an IOMMU.



It works, thanks!

Tested-by: Shawn Lin 



With IOMMU groups now serving as a reliable indicator of whether a
device has an IOMMU or not (barring false-positives from VFIO no-IOMMU
mode), drivers could arguably do this:

group = iommu_group_get(dev);
if (group) {
domain = iommu_get_domain_for_dev(dev);
iommu_group_put(group);
}

However, rather than duplicate that code across multiple callsites,
particularly when it's still only the domain they care about, let's skip
straight to the next step and factor out the check into the common place
it applies - in iommu_get_domain_for_dev() itself. Sure, it ends up
looking rather familiar, but now it's backed by the reasoning of having
a robust API able to do the expected thing for all devices regardless.

Fixes: 05f80300dc8b ("iommu: Finish making iommu_group support mandatory")
Reported-by: Shawn Lin 
Signed-off-by: Robin Murphy 
---

As well as dma-iommu, there are at least the Cavium ThunderX and
Freescale DPAA2 ethernet drivers expecting this to work too.

  drivers/iommu/iommu.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index af69bf7e035a..5499a0387349 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1352,6 +1352,8 @@ struct iommu_domain *iommu_get_domain_for_dev(struct 
device *dev)
struct iommu_group *group;
  
  	group = iommu_group_get(dev);

+   if (!group)
+   return NULL;
  
  	domain = group->domain;
  

Re: [PATCH] iommu: Avoid NULL group dereference

[Shawn Lin]

Hi

On 2017/8/17 18:40, Robin Murphy wrote:

The recently-removed FIXME in iommu_get_domain_for_dev() turns out to
have been a little misleading, since that check is still worthwhile even
when groups *are* universal. We have a few IOMMU-aware drivers which
only care whether their device is already attached to an existing domain
or not, for which the previous behaviour of iommu_get_domain_for_dev()
was ideal, and who now crash if their device does not have an IOMMU.



It works, thanks!

Tested-by: Shawn Lin 



With IOMMU groups now serving as a reliable indicator of whether a
device has an IOMMU or not (barring false-positives from VFIO no-IOMMU
mode), drivers could arguably do this:

group = iommu_group_get(dev);
if (group) {
domain = iommu_get_domain_for_dev(dev);
iommu_group_put(group);
}

However, rather than duplicate that code across multiple callsites,
particularly when it's still only the domain they care about, let's skip
straight to the next step and factor out the check into the common place
it applies - in iommu_get_domain_for_dev() itself. Sure, it ends up
looking rather familiar, but now it's backed by the reasoning of having
a robust API able to do the expected thing for all devices regardless.

Fixes: 05f80300dc8b ("iommu: Finish making iommu_group support mandatory")
Reported-by: Shawn Lin 
Signed-off-by: Robin Murphy 
---

As well as dma-iommu, there are at least the Cavium ThunderX and
Freescale DPAA2 ethernet drivers expecting this to work too.

  drivers/iommu/iommu.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index af69bf7e035a..5499a0387349 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1352,6 +1352,8 @@ struct iommu_domain *iommu_get_domain_for_dev(struct 
device *dev)
struct iommu_group *group;
  
  	group = iommu_group_get(dev);

+   if (!group)
+   return NULL;
  
  	domain = group->domain;
  

Re: [PATCH V5 net-next 01/21] net-next/hinic: Initialize hw interface

[Stephen Hemminger]

On Thu, 17 Aug 2017 19:52:42 +0800
Aviad Krawczyk  wrote:

> + nic_dev = (struct hinic_dev *)netdev_priv(netdev);

Sinc netdev_priv() returns void *, a cast is not necessary here.

Re: [PATCH V5 net-next 01/21] net-next/hinic: Initialize hw interface

[Stephen Hemminger]

On Thu, 17 Aug 2017 19:52:42 +0800
Aviad Krawczyk  wrote:

> + nic_dev = (struct hinic_dev *)netdev_priv(netdev);

Sinc netdev_priv() returns void *, a cast is not necessary here.

Re: [PATCH net v2 2/2] net: ixgbe: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

[Ding Tianhong]

On 2017/8/17 22:17, Tantilov, Emil S wrote:

>>  ret_val = ixgbe_start_hw_generic(hw);
>>
>> -#ifndef CONFIG_SPARC
>> -/* Disable relaxed ordering */
>> -for (i = 0; ((i < hw->mac.max_tx_queues) &&
>> - (i < IXGBE_DCA_MAX_QUEUES_82598)); i++) {
>> -regval = IXGBE_READ_REG(hw, IXGBE_DCA_TXCTRL(i));
>> -regval &= ~IXGBE_DCA_TXCTRL_DESC_WRO_EN;
>> -IXGBE_WRITE_REG(hw, IXGBE_DCA_TXCTRL(i), regval);
>> -}
>> +if (!pcie_relaxed_ordering_enabled(adapter->pdev)) {
> 
> As Alex mentioned there is no need for this check in any form.
> 
> The HW defaults to Relaxed Ordering enabled unless it is disabled in 
> the PCIe Device Control Register. So the above logic is already done by HW.
> 
> All you have to do is strip the code disabling relaxed ordering.
> 

Hi Tantilov:

I misunderstood Alex's suggestion, But I still couldn't find the logic where
the HW disable the Relaxed Ordering when the PCIe Device Control Register
disable it, can you point it out?

Thanks
Ding

> Thanks,
> Emil
> 
> 
> .
> 

Re: [PATCH net v2 2/2] net: ixgbe: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

[Ding Tianhong]

On 2017/8/17 22:17, Tantilov, Emil S wrote:

>>  ret_val = ixgbe_start_hw_generic(hw);
>>
>> -#ifndef CONFIG_SPARC
>> -/* Disable relaxed ordering */
>> -for (i = 0; ((i < hw->mac.max_tx_queues) &&
>> - (i < IXGBE_DCA_MAX_QUEUES_82598)); i++) {
>> -regval = IXGBE_READ_REG(hw, IXGBE_DCA_TXCTRL(i));
>> -regval &= ~IXGBE_DCA_TXCTRL_DESC_WRO_EN;
>> -IXGBE_WRITE_REG(hw, IXGBE_DCA_TXCTRL(i), regval);
>> -}
>> +if (!pcie_relaxed_ordering_enabled(adapter->pdev)) {
> 
> As Alex mentioned there is no need for this check in any form.
> 
> The HW defaults to Relaxed Ordering enabled unless it is disabled in 
> the PCIe Device Control Register. So the above logic is already done by HW.
> 
> All you have to do is strip the code disabling relaxed ordering.
> 

Hi Tantilov:

I misunderstood Alex's suggestion, But I still couldn't find the logic where
the HW disable the Relaxed Ordering when the PCIe Device Control Register
disable it, can you point it out?

Thanks
Ding

> Thanks,
> Emil
> 
> 
> .
> 

Re: [PATCH v2] swap: choose swap device according to numa node

[Aaron Lu]

On Thu, Aug 17, 2017 at 03:44:08PM -0700, Andrew Morton wrote:
> On Wed, 16 Aug 2017 10:44:40 +0800 Aaron Lu  wrote:
> > ...
> >
> > +static int __init swapfile_init(void)
> > +{
> > +   int nid;
> > +
> > +   swap_avail_heads = kmalloc(nr_node_ids * sizeof(struct plist_head), 
> > GFP_KERNEL);
> 
> I suppose we should use kmalloc_array(), as someone wrote it for us.
> 
> --- a/mm/swapfile.c~swap-choose-swap-device-according-to-numa-node-v2-fix
> +++ a/mm/swapfile.c
> @@ -3700,7 +3700,8 @@ static int __init swapfile_init(void)
>  {
>   int nid;
>  
> - swap_avail_heads = kmalloc(nr_node_ids * sizeof(struct plist_head), 
> GFP_KERNEL);
> + swap_avail_heads = kmalloc_array(nr_node_ids, sizeof(struct plist_head),
> +  GFP_KERNEL);
>   if (!swap_avail_heads) {
>   pr_emerg("Not enough memory for swap heads, swap is 
> disabled\n");
>   return -ENOMEM;
> 
> > +   if (!swap_avail_heads) {
> > +   pr_emerg("Not enough memory for swap heads, swap is 
> > disabled\n");
> 
> checkpatch tells us that the "Not enough memory" is a bit redundant, as
> the memory allocator would have already warned.  So it's sufficient to
> additionally say only "swap is disabled" here.  But it's hardly worth
> changing.

Thanks Andrew for taking care of this.

Re: [PATCH v2] swap: choose swap device according to numa node

[Aaron Lu]

On Thu, Aug 17, 2017 at 03:44:08PM -0700, Andrew Morton wrote:
> On Wed, 16 Aug 2017 10:44:40 +0800 Aaron Lu  wrote:
> > ...
> >
> > +static int __init swapfile_init(void)
> > +{
> > +   int nid;
> > +
> > +   swap_avail_heads = kmalloc(nr_node_ids * sizeof(struct plist_head), 
> > GFP_KERNEL);
> 
> I suppose we should use kmalloc_array(), as someone wrote it for us.
> 
> --- a/mm/swapfile.c~swap-choose-swap-device-according-to-numa-node-v2-fix
> +++ a/mm/swapfile.c
> @@ -3700,7 +3700,8 @@ static int __init swapfile_init(void)
>  {
>   int nid;
>  
> - swap_avail_heads = kmalloc(nr_node_ids * sizeof(struct plist_head), 
> GFP_KERNEL);
> + swap_avail_heads = kmalloc_array(nr_node_ids, sizeof(struct plist_head),
> +  GFP_KERNEL);
>   if (!swap_avail_heads) {
>   pr_emerg("Not enough memory for swap heads, swap is 
> disabled\n");
>   return -ENOMEM;
> 
> > +   if (!swap_avail_heads) {
> > +   pr_emerg("Not enough memory for swap heads, swap is 
> > disabled\n");
> 
> checkpatch tells us that the "Not enough memory" is a bit redundant, as
> the memory allocator would have already warned.  So it's sufficient to
> additionally say only "swap is disabled" here.  But it's hardly worth
> changing.

Thanks Andrew for taking care of this.

Re: [PATCH V5 net-next 01/21] net-next/hinic: Initialize hw interface

[Stephen Hemminger]

On Thu, 17 Aug 2017 19:52:42 +0800
Aviad Krawczyk  wrote:

> +
> +/**
> + * init_pfhwdev - Initialize the extended components of PF
> + * @pfhwdev: the HW device for PF
> + *
> + * Return 0 - success, negative - failure
> + **/
> +static int init_pfhwdev(struct hinic_pfhwdev *pfhwdev)
> +{
> + /* Initialize PF HW device extended components */
> + return 0;
> +}
> +
> +/**
> + * free_pfhwdev - Free the extended components of PF
> + * @pfhwdev: the HW device for PF
> + **/
> +static void free_pfhwdev(struct hinic_pfhwdev *pfhwdev)
> +{
> +}

Please drop these functions, they do nothing and are not used
as stubs in any operations table.

Re: [PATCH V5 net-next 01/21] net-next/hinic: Initialize hw interface

[Stephen Hemminger]

On Thu, 17 Aug 2017 19:52:42 +0800
Aviad Krawczyk  wrote:

> +
> +/**
> + * init_pfhwdev - Initialize the extended components of PF
> + * @pfhwdev: the HW device for PF
> + *
> + * Return 0 - success, negative - failure
> + **/
> +static int init_pfhwdev(struct hinic_pfhwdev *pfhwdev)
> +{
> + /* Initialize PF HW device extended components */
> + return 0;
> +}
> +
> +/**
> + * free_pfhwdev - Free the extended components of PF
> + * @pfhwdev: the HW device for PF
> + **/
> +static void free_pfhwdev(struct hinic_pfhwdev *pfhwdev)
> +{
> +}

Please drop these functions, they do nothing and are not used
as stubs in any operations table.

RE: [PATCH net-next 2/3] vsock: fix vsock_dequeue/enqueue_accept race

[Dexuan Cui]

> > On Aug 16, 2017, at 12:15 AM, Dexuan Cui  wrote:
> > With the current code, when vsock_dequeue_accept() is removing a sock
> > from the list, nothing prevents vsock_enqueue_accept() from adding a new
> > sock into the list concurrently. We should add a lock to protect the list.
> 
> For the VMCI socket transport, we always lock the sockets before calling into
> vsock_enqueue_accept and af_vsock.c locks the socket before calling
> vsock_dequeue_accept, so from our point of view these operations are already
> protected, but with finer granularity than a single global lock. As far as I 
> can see,
> the virtio transport also locks the socket before calling 
> vsock_enqueue_accept,
> so they should be fine with the current version as well, but Stefan can 
> comment
> on that.
> 
> Jorgen

Hi Jorgen,
Thanks, you're correct.
Please ignore this patch. I'll update the hv_sock driver to add proper 
lock_sock()/relesae_sock().

Thanks,
-- Dexuan

RE: [PATCH net-next 2/3] vsock: fix vsock_dequeue/enqueue_accept race

[Dexuan Cui]

> > On Aug 16, 2017, at 12:15 AM, Dexuan Cui  wrote:
> > With the current code, when vsock_dequeue_accept() is removing a sock
> > from the list, nothing prevents vsock_enqueue_accept() from adding a new
> > sock into the list concurrently. We should add a lock to protect the list.
> 
> For the VMCI socket transport, we always lock the sockets before calling into
> vsock_enqueue_accept and af_vsock.c locks the socket before calling
> vsock_dequeue_accept, so from our point of view these operations are already
> protected, but with finer granularity than a single global lock. As far as I 
> can see,
> the virtio transport also locks the socket before calling 
> vsock_enqueue_accept,
> so they should be fine with the current version as well, but Stefan can 
> comment
> on that.
> 
> Jorgen

Hi Jorgen,
Thanks, you're correct.
Please ignore this patch. I'll update the hv_sock driver to add proper 
lock_sock()/relesae_sock().

Thanks,
-- Dexuan

Re: [PATCH] ACPI / sysfs: Extend ACPI sysfs to provide access to boot error region

[Alan Cox]

On Thu, 17 Aug 2017 14:39:46 -0700
"Luck, Tony"  wrote:

> From: Tony Luck 
> 
> The ACPI sysfs interface provides a way to read each ACPI table from
> userspace via entries in /sys/firmware/acpi/tables/
> 
> The BERT table simply provides the size and address of the error
> record in BIOS reserved memory and users may want access to this
> record.
> 
> In an earlier age we might have used /dev/mem to retrieve this error
> record, but many systems disable /dev/mem for security reasons.
> 
> Extend this driver to provide read-only access to the data via a
> file in a new directory /sys/firmware/acpi/tables/data/BERT

Should this not also have a capability check. Assuming file permissions
are sufficient for grabbing a chunk of system memory holding error
info doesn't seem too scary but it's at odds with a lot of other cases ?

Alan

Re: [PATCH] ACPI / sysfs: Extend ACPI sysfs to provide access to boot error region

[Alan Cox]

On Thu, 17 Aug 2017 14:39:46 -0700
"Luck, Tony"  wrote:

> From: Tony Luck 
> 
> The ACPI sysfs interface provides a way to read each ACPI table from
> userspace via entries in /sys/firmware/acpi/tables/
> 
> The BERT table simply provides the size and address of the error
> record in BIOS reserved memory and users may want access to this
> record.
> 
> In an earlier age we might have used /dev/mem to retrieve this error
> record, but many systems disable /dev/mem for security reasons.
> 
> Extend this driver to provide read-only access to the data via a
> file in a new directory /sys/firmware/acpi/tables/data/BERT

Should this not also have a capability check. Assuming file permissions
are sufficient for grabbing a chunk of system memory holding error
info doesn't seem too scary but it's at odds with a lot of other cases ?

Alan

Re: [PATCH] IB/core: fix duplicated code for different branches

[Gustavo A. R. Silva]

Hi Leon,

On 08/13/2017 01:31 AM, Leon Romanovsky wrote:

On Sat, Aug 12, 2017 at 07:52:35PM -0500, Gustavo A. R. Silva wrote:

Refactor code to avoid identical code for different branches.

This issue was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/infiniband/core/cm.c | 4 
 1 file changed, 4 deletions(-)


I see that you used the same commit message and title for many patches,
it will be better to have description on what exactly you are removing
and why there is no bug in that code.



Thank you for the suggestion.

I will add a note saying that it is up to the maintainer to verify 
whether the code is applicable or not.


The intention of the patch is to point out a duplication of code found 
by a Coccinelle script. I'm also working on similar issues reported by 
Coverity. It was tested only by compilation as I don't have the proper 
hardware to test it on.






diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c
index 2b4d613..b46262f 100644
--- a/drivers/infiniband/core/cm.c
+++ b/drivers/infiniband/core/cm.c
@@ -590,8 +590,6 @@ static struct cm_id_private * cm_insert_listen(struct 
cm_id_private *cm_id_priv)
link = &(*link)->rb_right;
else if (be64_lt(service_id, cur_cm_id_priv->id.service_id))
link = &(*link)->rb_left;
-   else if (be64_gt(service_id, cur_cm_id_priv->id.service_id))
-   link = &(*link)->rb_right;
else
link = &(*link)->rb_right;
}
@@ -619,8 +617,6 @@ static struct cm_id_private * cm_find_listen(struct 
ib_device *device,
node = node->rb_right;
else if (be64_lt(service_id, cm_id_priv->id.service_id))
node = node->rb_left;
-   else if (be64_gt(service_id, cm_id_priv->id.service_id))
-   node = node->rb_right;


You should remove be64_gt() too.



Thank you for pointing it out.


else
node = node->rb_right;
}
--
2.5.0



--
Gustavo A. R. Silva

Re: [PATCH] IB/core: fix duplicated code for different branches

[Gustavo A. R. Silva]

Hi Leon,

On 08/13/2017 01:31 AM, Leon Romanovsky wrote:

On Sat, Aug 12, 2017 at 07:52:35PM -0500, Gustavo A. R. Silva wrote:

Refactor code to avoid identical code for different branches.

This issue was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/infiniband/core/cm.c | 4 
 1 file changed, 4 deletions(-)


I see that you used the same commit message and title for many patches,
it will be better to have description on what exactly you are removing
and why there is no bug in that code.



Thank you for the suggestion.

I will add a note saying that it is up to the maintainer to verify 
whether the code is applicable or not.


The intention of the patch is to point out a duplication of code found 
by a Coccinelle script. I'm also working on similar issues reported by 
Coverity. It was tested only by compilation as I don't have the proper 
hardware to test it on.






diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c
index 2b4d613..b46262f 100644
--- a/drivers/infiniband/core/cm.c
+++ b/drivers/infiniband/core/cm.c
@@ -590,8 +590,6 @@ static struct cm_id_private * cm_insert_listen(struct 
cm_id_private *cm_id_priv)
link = &(*link)->rb_right;
else if (be64_lt(service_id, cur_cm_id_priv->id.service_id))
link = &(*link)->rb_left;
-   else if (be64_gt(service_id, cur_cm_id_priv->id.service_id))
-   link = &(*link)->rb_right;
else
link = &(*link)->rb_right;
}
@@ -619,8 +617,6 @@ static struct cm_id_private * cm_find_listen(struct 
ib_device *device,
node = node->rb_right;
else if (be64_lt(service_id, cm_id_priv->id.service_id))
node = node->rb_left;
-   else if (be64_gt(service_id, cm_id_priv->id.service_id))
-   node = node->rb_right;


You should remove be64_gt() too.



Thank you for pointing it out.


else
node = node->rb_right;
}
--
2.5.0



--
Gustavo A. R. Silva

Re: [RFC v6 21/62] powerpc: introduce execute-only pkey

[Ram Pai]

On Thu, Aug 17, 2017 at 04:35:55PM -0700, Ram Pai wrote:
> On Wed, Aug 02, 2017 at 07:40:46PM +1000, Michael Ellerman wrote:
> > Thiago Jung Bauermann  writes:
> > 
> > > Michael Ellerman  writes:
> > >
> > >> Thiago Jung Bauermann  writes:
> > >>> Ram Pai  writes:
> > >> ...
> >  +
> >  +  /* We got one, store it and use it from here on out */
> >  +  if (need_to_set_mm_pkey)
> >  +  mm->context.execute_only_pkey = execute_only_pkey;
> >  +  return execute_only_pkey;
> >  +}
> > >>>
> > >>> If you follow the code flow in __execute_only_pkey, the AMR and UAMOR
> > >>> are read 3 times in total, and AMR is written twice. IAMR is read and
> > >>> written twice. Since they are SPRs and access to them is slow (or isn't
> > >>> it?),
> > >>
> > >> SPRs read/writes are slow, but they're not *that* slow in comparison to
> > >> a system call (which I think is where this code is being called?).
> > >
> > > Yes, this code runs on mprotect and mmap syscalls if the memory is
> > > requested to have execute but not read nor write permissions.
> > 
> > Yep. That's not in the fast path for key usage, ie. the fast path is
> > userspace changing the AMR itself, and the overhead of a syscall is
> > already hundreds of cycles.
> > 
> > >> So we should try to avoid too many SPR read/writes, but at the same time
> > >> we can accept more than the minimum if it makes the code much easier to
> > >> follow.
> > >
> > > Ok. Ram had asked me to suggest a way to optimize the SPR reads and
> > > writes and I came up with the patch below. Do you think it's worth it?
> > 
> > At a glance no I don't think it is. Sorry you spent that much time on it.
> > 
> > I think we can probably reduce the number of SPR accesses without
> > needing to go to that level of complexity.
> > 
> > But don't throw the patch away, I may eat my words once I have the full
> > series applied and am looking at it hard - at the moment I'm just
> > reviewing the patches piecemeal as I get time.
> 

Thiago's patch does save some cycles. I dont feel like throwing his
work. I agree, It should be considered after applying all the patches. 
 
RP

-- 
Ram Pai

Re: [RFC v6 21/62] powerpc: introduce execute-only pkey

[Ram Pai]

On Thu, Aug 17, 2017 at 04:35:55PM -0700, Ram Pai wrote:
> On Wed, Aug 02, 2017 at 07:40:46PM +1000, Michael Ellerman wrote:
> > Thiago Jung Bauermann  writes:
> > 
> > > Michael Ellerman  writes:
> > >
> > >> Thiago Jung Bauermann  writes:
> > >>> Ram Pai  writes:
> > >> ...
> >  +
> >  +  /* We got one, store it and use it from here on out */
> >  +  if (need_to_set_mm_pkey)
> >  +  mm->context.execute_only_pkey = execute_only_pkey;
> >  +  return execute_only_pkey;
> >  +}
> > >>>
> > >>> If you follow the code flow in __execute_only_pkey, the AMR and UAMOR
> > >>> are read 3 times in total, and AMR is written twice. IAMR is read and
> > >>> written twice. Since they are SPRs and access to them is slow (or isn't
> > >>> it?),
> > >>
> > >> SPRs read/writes are slow, but they're not *that* slow in comparison to
> > >> a system call (which I think is where this code is being called?).
> > >
> > > Yes, this code runs on mprotect and mmap syscalls if the memory is
> > > requested to have execute but not read nor write permissions.
> > 
> > Yep. That's not in the fast path for key usage, ie. the fast path is
> > userspace changing the AMR itself, and the overhead of a syscall is
> > already hundreds of cycles.
> > 
> > >> So we should try to avoid too many SPR read/writes, but at the same time
> > >> we can accept more than the minimum if it makes the code much easier to
> > >> follow.
> > >
> > > Ok. Ram had asked me to suggest a way to optimize the SPR reads and
> > > writes and I came up with the patch below. Do you think it's worth it?
> > 
> > At a glance no I don't think it is. Sorry you spent that much time on it.
> > 
> > I think we can probably reduce the number of SPR accesses without
> > needing to go to that level of complexity.
> > 
> > But don't throw the patch away, I may eat my words once I have the full
> > series applied and am looking at it hard - at the moment I'm just
> > reviewing the patches piecemeal as I get time.
> 

Thiago's patch does save some cycles. I dont feel like throwing his
work. I agree, It should be considered after applying all the patches. 
 
RP

-- 
Ram Pai

[git pull] drm fixes for 4.13-rc6

[Dave Airlie]

Hi Linus,

Seems to be slowing down nicely, just one amdgpu fix, and a bunch of i915 fixes.

Dave.

The following changes since commit ef954844c7ace62f773f4f23e28d2d915adc419f:

  Linux 4.13-rc5 (2017-08-13 16:01:32 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.13-rc6

for you to fetch changes up to 28eb46287916f7f3ceec874959693e3fc49a294a:

  Merge branch 'drm-fixes-4.13' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes (2017-08-18
05:45:03 +1000)


amd and i915 fixes.


Chris Wilson (2):
  drm/i915: Perform an invalidate prior to executing golden renderstate
  drm/i915: Suppress switch_mm emission between the same aliasing_ppgtt

Chunming Zhou (1):
  drm/amdgpu: save list length when fence is signaled

Daniel Vetter (1):
  drm/i915: Avoid the gpu reset vs. modeset deadlock

Dave Airlie (2):
  Merge tag 'drm-intel-fixes-2017-08-16' of
git://anongit.freedesktop.org/git/drm-intel into drm-fixes
  Merge branch 'drm-fixes-4.13' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes

Lionel Landwerlin (1):
  drm/i915: remove unused function declaration

Matthias Kaehlcke (1):
  drm/i915: Return correct EDP voltage swing table for 0.85V

Rodrigo Vivi (1):
  drm/i915/cnl: Add slice and subslice information to debugfs.

 drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 13 ++---
 drivers/gpu/drm/i915/i915_debugfs.c  |  2 +-
 drivers/gpu/drm/i915/i915_gem_context.c  | 15 ---
 drivers/gpu/drm/i915/i915_gem_render_state.c |  4 
 drivers/gpu/drm/i915/intel_ddi.c |  2 +-
 drivers/gpu/drm/i915/intel_display.c |  7 +++
 drivers/gpu/drm/i915/intel_lrc.h |  1 -
 7 files changed, 27 insertions(+), 17 deletions(-)

[git pull] drm fixes for 4.13-rc6

[Dave Airlie]

Hi Linus,

Seems to be slowing down nicely, just one amdgpu fix, and a bunch of i915 fixes.

Dave.

The following changes since commit ef954844c7ace62f773f4f23e28d2d915adc419f:

  Linux 4.13-rc5 (2017-08-13 16:01:32 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.13-rc6

for you to fetch changes up to 28eb46287916f7f3ceec874959693e3fc49a294a:

  Merge branch 'drm-fixes-4.13' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes (2017-08-18
05:45:03 +1000)


amd and i915 fixes.


Chris Wilson (2):
  drm/i915: Perform an invalidate prior to executing golden renderstate
  drm/i915: Suppress switch_mm emission between the same aliasing_ppgtt

Chunming Zhou (1):
  drm/amdgpu: save list length when fence is signaled

Daniel Vetter (1):
  drm/i915: Avoid the gpu reset vs. modeset deadlock

Dave Airlie (2):
  Merge tag 'drm-intel-fixes-2017-08-16' of
git://anongit.freedesktop.org/git/drm-intel into drm-fixes
  Merge branch 'drm-fixes-4.13' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes

Lionel Landwerlin (1):
  drm/i915: remove unused function declaration

Matthias Kaehlcke (1):
  drm/i915: Return correct EDP voltage swing table for 0.85V

Rodrigo Vivi (1):
  drm/i915/cnl: Add slice and subslice information to debugfs.

 drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 13 ++---
 drivers/gpu/drm/i915/i915_debugfs.c  |  2 +-
 drivers/gpu/drm/i915/i915_gem_context.c  | 15 ---
 drivers/gpu/drm/i915/i915_gem_render_state.c |  4 
 drivers/gpu/drm/i915/intel_ddi.c |  2 +-
 drivers/gpu/drm/i915/intel_display.c |  7 +++
 drivers/gpu/drm/i915/intel_lrc.h |  1 -
 7 files changed, 27 insertions(+), 17 deletions(-)

Re: [RFT PATCH] [media] partial revert of "[media] tvp5150: add HW input connectors support"

[Laurent Pinchart]

Hi Javier,

(Resent to your new e-mail address)

Thank you for the patch.

On Tuesday 13 Dec 2016 12:39:19 Javier Martinez Canillas wrote:
> Commit f7b4b54e6364 ("[media] tvp5150: add HW input connectors support")
> added input signals support for the tvp5150, but the approach was found
> to be incorrect so the corresponding DT binding commit 82c2ffeb217a
> ("[media] tvp5150: document input connectors DT bindings") was reverted.
> 
> This left the driver with an undocumented (and wrong) DT parsing logic,
> so lets get rid of this code as well until the input connectors support
> is implemented properly.
> 
> It's a partial revert due other patches added on top of mentioned commit
> not allowing the commit to be reverted cleanly anymore. But all the code
> related to the DT parsing logic and input entities creation are removed.
> 
> Suggested-by: Laurent Pinchart 
> Signed-off-by: Javier Martinez Canillas 

Acked-by: Laurent Pinchart 

> ---
> 
> Hello Laurent,
> 
> I've tested this patch on top of media/master on my IGEPv2 + tvp5150
> with the following:
> 
> $ media-ctl -r -l '"tvp5150 1-005c":1->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
> CCDC":1->"OMAP3 ISP CCDC output":0[1]' $ media-ctl -v --set-format '"OMAP3
> ISP CCDC":0 [UYVY2X8 720x240 field:alternate]' $ media-ctl -v --set-format
> '"OMAP3 ISP CCDC":1 [UYVY2X8 720x240 field:interlaced-tb]' $ yavta -f UYVY
> -s 720x480 -n 1 --field interlaced-tb --capture=1 -F /dev/video2 $
> raw2rgbpnm -f UYVY -s 720x480 frame-00.bin frame.pnm
> 
> I've also tested the other composite input with the following change:
> 
> diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
> index 5fe5faefe212..973be68ff78c 100644
> --- a/drivers/media/i2c/tvp5150.c
> +++ b/drivers/media/i2c/tvp5150.c
> @@ -1371,7 +1371,7 @@ static int tvp5150_probe(struct i2c_client *c,
> return res;
> 
> core->norm = V4L2_STD_ALL;  /* Default is autodetect */
> -   core->input = TVP5150_COMPOSITE1;
> +   core->input = TVP5150_COMPOSITE0;
> core->enable = true;
> 
> v4l2_ctrl_handler_init(>hdl, 5);
> 
> But as mentioned, it also worked for me without the revert so please let
> me know if the driver works with your omap3 board.
> 
> Best regards,
> Javier
> 
>  drivers/media/i2c/tvp5150.c | 142
>  1 file changed, 142
> deletions(-)
> 
> diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
> index 48646a7f3fb0..5fe5faefe212 100644
> --- a/drivers/media/i2c/tvp5150.c
> +++ b/drivers/media/i2c/tvp5150.c
> @@ -42,8 +42,6 @@ struct tvp5150 {
>   struct v4l2_subdev sd;
>  #ifdef CONFIG_MEDIA_CONTROLLER
>   struct media_pad pads[DEMOD_NUM_PADS];
> - struct media_entity input_ent[TVP5150_INPUT_NUM];
> - struct media_pad input_pad[TVP5150_INPUT_NUM];
>  #endif
>   struct v4l2_ctrl_handler hdl;
>   struct v4l2_rect rect;
> @@ -1018,40 +1016,6 @@ static int tvp5150_enum_frame_size(struct v4l2_subdev
> *sd, }
> 
>  /**
> ** -  Media entity ops
> -
> ***
> */ -
> -#ifdef CONFIG_MEDIA_CONTROLLER
> -static int tvp5150_link_setup(struct media_entity *entity,
> -   const struct media_pad *local,
> -   const struct media_pad *remote, u32 flags)
> -{
> - struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
> - struct tvp5150 *decoder = to_tvp5150(sd);
> - int i;
> -
> - for (i = 0; i < TVP5150_INPUT_NUM; i++) {
> - if (remote->entity == >input_ent[i])
> - break;
> - }
> -
> - /* Do nothing for entities that are not input connectors */
> - if (i == TVP5150_INPUT_NUM)
> - return 0;
> -
> - decoder->input = i;
> -
> - tvp5150_selmux(sd);
> -
> - return 0;
> -}
> -
> -static const struct media_entity_operations tvp5150_sd_media_ops = {
> - .link_setup = tvp5150_link_setup,
> -};
> -#endif
> -
> -/**
> ** I2C Command
>  
> ***
> */
> 
> @@ -1188,42 +1152,6 @@ static int tvp5150_g_tuner(struct v4l2_subdev *sd,
> struct v4l2_tuner *vt) return 0;
>  }
> 
> -static int tvp5150_registered(struct v4l2_subdev *sd)
> -{
> -#ifdef CONFIG_MEDIA_CONTROLLER
> - struct tvp5150 *decoder = to_tvp5150(sd);
> - int ret = 0;
> - int i;
> -
> - for (i = 0; i < TVP5150_INPUT_NUM; i++) {
> - struct media_entity *input = >input_ent[i];
> - struct media_pad *pad = >input_pad[i];
> -
> - if (!input->name)
> - continue;
> -
> - decoder->input_pad[i].flags = MEDIA_PAD_FL_SOURCE;

Re: [RFT PATCH] [media] partial revert of "[media] tvp5150: add HW input connectors support"

[Laurent Pinchart]

Hi Javier,

(Resent to your new e-mail address)

Thank you for the patch.

On Tuesday 13 Dec 2016 12:39:19 Javier Martinez Canillas wrote:
> Commit f7b4b54e6364 ("[media] tvp5150: add HW input connectors support")
> added input signals support for the tvp5150, but the approach was found
> to be incorrect so the corresponding DT binding commit 82c2ffeb217a
> ("[media] tvp5150: document input connectors DT bindings") was reverted.
> 
> This left the driver with an undocumented (and wrong) DT parsing logic,
> so lets get rid of this code as well until the input connectors support
> is implemented properly.
> 
> It's a partial revert due other patches added on top of mentioned commit
> not allowing the commit to be reverted cleanly anymore. But all the code
> related to the DT parsing logic and input entities creation are removed.
> 
> Suggested-by: Laurent Pinchart 
> Signed-off-by: Javier Martinez Canillas 

Acked-by: Laurent Pinchart 

> ---
> 
> Hello Laurent,
> 
> I've tested this patch on top of media/master on my IGEPv2 + tvp5150
> with the following:
> 
> $ media-ctl -r -l '"tvp5150 1-005c":1->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
> CCDC":1->"OMAP3 ISP CCDC output":0[1]' $ media-ctl -v --set-format '"OMAP3
> ISP CCDC":0 [UYVY2X8 720x240 field:alternate]' $ media-ctl -v --set-format
> '"OMAP3 ISP CCDC":1 [UYVY2X8 720x240 field:interlaced-tb]' $ yavta -f UYVY
> -s 720x480 -n 1 --field interlaced-tb --capture=1 -F /dev/video2 $
> raw2rgbpnm -f UYVY -s 720x480 frame-00.bin frame.pnm
> 
> I've also tested the other composite input with the following change:
> 
> diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
> index 5fe5faefe212..973be68ff78c 100644
> --- a/drivers/media/i2c/tvp5150.c
> +++ b/drivers/media/i2c/tvp5150.c
> @@ -1371,7 +1371,7 @@ static int tvp5150_probe(struct i2c_client *c,
> return res;
> 
> core->norm = V4L2_STD_ALL;  /* Default is autodetect */
> -   core->input = TVP5150_COMPOSITE1;
> +   core->input = TVP5150_COMPOSITE0;
> core->enable = true;
> 
> v4l2_ctrl_handler_init(>hdl, 5);
> 
> But as mentioned, it also worked for me without the revert so please let
> me know if the driver works with your omap3 board.
> 
> Best regards,
> Javier
> 
>  drivers/media/i2c/tvp5150.c | 142
>  1 file changed, 142
> deletions(-)
> 
> diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
> index 48646a7f3fb0..5fe5faefe212 100644
> --- a/drivers/media/i2c/tvp5150.c
> +++ b/drivers/media/i2c/tvp5150.c
> @@ -42,8 +42,6 @@ struct tvp5150 {
>   struct v4l2_subdev sd;
>  #ifdef CONFIG_MEDIA_CONTROLLER
>   struct media_pad pads[DEMOD_NUM_PADS];
> - struct media_entity input_ent[TVP5150_INPUT_NUM];
> - struct media_pad input_pad[TVP5150_INPUT_NUM];
>  #endif
>   struct v4l2_ctrl_handler hdl;
>   struct v4l2_rect rect;
> @@ -1018,40 +1016,6 @@ static int tvp5150_enum_frame_size(struct v4l2_subdev
> *sd, }
> 
>  /**
> ** -  Media entity ops
> -
> ***
> */ -
> -#ifdef CONFIG_MEDIA_CONTROLLER
> -static int tvp5150_link_setup(struct media_entity *entity,
> -   const struct media_pad *local,
> -   const struct media_pad *remote, u32 flags)
> -{
> - struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
> - struct tvp5150 *decoder = to_tvp5150(sd);
> - int i;
> -
> - for (i = 0; i < TVP5150_INPUT_NUM; i++) {
> - if (remote->entity == >input_ent[i])
> - break;
> - }
> -
> - /* Do nothing for entities that are not input connectors */
> - if (i == TVP5150_INPUT_NUM)
> - return 0;
> -
> - decoder->input = i;
> -
> - tvp5150_selmux(sd);
> -
> - return 0;
> -}
> -
> -static const struct media_entity_operations tvp5150_sd_media_ops = {
> - .link_setup = tvp5150_link_setup,
> -};
> -#endif
> -
> -/**
> ** I2C Command
>  
> ***
> */
> 
> @@ -1188,42 +1152,6 @@ static int tvp5150_g_tuner(struct v4l2_subdev *sd,
> struct v4l2_tuner *vt) return 0;
>  }
> 
> -static int tvp5150_registered(struct v4l2_subdev *sd)
> -{
> -#ifdef CONFIG_MEDIA_CONTROLLER
> - struct tvp5150 *decoder = to_tvp5150(sd);
> - int ret = 0;
> - int i;
> -
> - for (i = 0; i < TVP5150_INPUT_NUM; i++) {
> - struct media_entity *input = >input_ent[i];
> - struct media_pad *pad = >input_pad[i];
> -
> - if (!input->name)
> - continue;
> -
> - decoder->input_pad[i].flags = MEDIA_PAD_FL_SOURCE;
> -
> - ret = media_entity_pads_init(input, 1, pad);
> - if (ret < 0)

Re: [RFT PATCH] [media] partial revert of "[media] tvp5150: add HW input connectors support"

[Laurent Pinchart]

Hi Javier,

Thank you for the patch.

On Tuesday 13 Dec 2016 12:39:19 Javier Martinez Canillas wrote:
> Commit f7b4b54e6364 ("[media] tvp5150: add HW input connectors support")
> added input signals support for the tvp5150, but the approach was found
> to be incorrect so the corresponding DT binding commit 82c2ffeb217a
> ("[media] tvp5150: document input connectors DT bindings") was reverted.
> 
> This left the driver with an undocumented (and wrong) DT parsing logic,
> so lets get rid of this code as well until the input connectors support
> is implemented properly.
> 
> It's a partial revert due other patches added on top of mentioned commit
> not allowing the commit to be reverted cleanly anymore. But all the code
> related to the DT parsing logic and input entities creation are removed.
> 
> Suggested-by: Laurent Pinchart 
> Signed-off-by: Javier Martinez Canillas 

Acked-by: Laurent Pinchart 

> ---
> 
> Hello Laurent,
> 
> I've tested this patch on top of media/master on my IGEPv2 + tvp5150
> with the following:
> 
> $ media-ctl -r -l '"tvp5150 1-005c":1->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
> CCDC":1->"OMAP3 ISP CCDC output":0[1]' $ media-ctl -v --set-format '"OMAP3
> ISP CCDC":0 [UYVY2X8 720x240 field:alternate]' $ media-ctl -v --set-format
> '"OMAP3 ISP CCDC":1 [UYVY2X8 720x240 field:interlaced-tb]' $ yavta -f UYVY
> -s 720x480 -n 1 --field interlaced-tb --capture=1 -F /dev/video2 $
> raw2rgbpnm -f UYVY -s 720x480 frame-00.bin frame.pnm
> 
> I've also tested the other composite input with the following change:
> 
> diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
> index 5fe5faefe212..973be68ff78c 100644
> --- a/drivers/media/i2c/tvp5150.c
> +++ b/drivers/media/i2c/tvp5150.c
> @@ -1371,7 +1371,7 @@ static int tvp5150_probe(struct i2c_client *c,
> return res;
> 
> core->norm = V4L2_STD_ALL;  /* Default is autodetect */
> -   core->input = TVP5150_COMPOSITE1;
> +   core->input = TVP5150_COMPOSITE0;
> core->enable = true;
> 
> v4l2_ctrl_handler_init(>hdl, 5);
> 
> But as mentioned, it also worked for me without the revert so please let
> me know if the driver works with your omap3 board.
> 
> Best regards,
> Javier
> 
>  drivers/media/i2c/tvp5150.c | 142
>  1 file changed, 142
> deletions(-)
> 
> diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
> index 48646a7f3fb0..5fe5faefe212 100644
> --- a/drivers/media/i2c/tvp5150.c
> +++ b/drivers/media/i2c/tvp5150.c
> @@ -42,8 +42,6 @@ struct tvp5150 {
>   struct v4l2_subdev sd;
>  #ifdef CONFIG_MEDIA_CONTROLLER
>   struct media_pad pads[DEMOD_NUM_PADS];
> - struct media_entity input_ent[TVP5150_INPUT_NUM];
> - struct media_pad input_pad[TVP5150_INPUT_NUM];
>  #endif
>   struct v4l2_ctrl_handler hdl;
>   struct v4l2_rect rect;
> @@ -1018,40 +1016,6 @@ static int tvp5150_enum_frame_size(struct v4l2_subdev
> *sd, }
> 
>  /**
> ** -  Media entity ops
> -
> ***
> */ -
> -#ifdef CONFIG_MEDIA_CONTROLLER
> -static int tvp5150_link_setup(struct media_entity *entity,
> -   const struct media_pad *local,
> -   const struct media_pad *remote, u32 flags)
> -{
> - struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
> - struct tvp5150 *decoder = to_tvp5150(sd);
> - int i;
> -
> - for (i = 0; i < TVP5150_INPUT_NUM; i++) {
> - if (remote->entity == >input_ent[i])
> - break;
> - }
> -
> - /* Do nothing for entities that are not input connectors */
> - if (i == TVP5150_INPUT_NUM)
> - return 0;
> -
> - decoder->input = i;
> -
> - tvp5150_selmux(sd);
> -
> - return 0;
> -}
> -
> -static const struct media_entity_operations tvp5150_sd_media_ops = {
> - .link_setup = tvp5150_link_setup,
> -};
> -#endif
> -
> -/**
> ** I2C Command
>  
> ***
> */
> 
> @@ -1188,42 +1152,6 @@ static int tvp5150_g_tuner(struct v4l2_subdev *sd,
> struct v4l2_tuner *vt) return 0;
>  }
> 
> -static int tvp5150_registered(struct v4l2_subdev *sd)
> -{
> -#ifdef CONFIG_MEDIA_CONTROLLER
> - struct tvp5150 *decoder = to_tvp5150(sd);
> - int ret = 0;
> - int i;
> -
> - for (i = 0; i < TVP5150_INPUT_NUM; i++) {
> - struct media_entity *input = >input_ent[i];
> - struct media_pad *pad = >input_pad[i];
> -
> - if (!input->name)
> - continue;
> -
> - decoder->input_pad[i].flags = MEDIA_PAD_FL_SOURCE;
> -
> - ret = 

Re: [RFT PATCH] [media] partial revert of "[media] tvp5150: add HW input connectors support"

[Laurent Pinchart]

Hi Javier,

Thank you for the patch.

On Tuesday 13 Dec 2016 12:39:19 Javier Martinez Canillas wrote:
> Commit f7b4b54e6364 ("[media] tvp5150: add HW input connectors support")
> added input signals support for the tvp5150, but the approach was found
> to be incorrect so the corresponding DT binding commit 82c2ffeb217a
> ("[media] tvp5150: document input connectors DT bindings") was reverted.
> 
> This left the driver with an undocumented (and wrong) DT parsing logic,
> so lets get rid of this code as well until the input connectors support
> is implemented properly.
> 
> It's a partial revert due other patches added on top of mentioned commit
> not allowing the commit to be reverted cleanly anymore. But all the code
> related to the DT parsing logic and input entities creation are removed.
> 
> Suggested-by: Laurent Pinchart 
> Signed-off-by: Javier Martinez Canillas 

Acked-by: Laurent Pinchart 

> ---
> 
> Hello Laurent,
> 
> I've tested this patch on top of media/master on my IGEPv2 + tvp5150
> with the following:
> 
> $ media-ctl -r -l '"tvp5150 1-005c":1->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
> CCDC":1->"OMAP3 ISP CCDC output":0[1]' $ media-ctl -v --set-format '"OMAP3
> ISP CCDC":0 [UYVY2X8 720x240 field:alternate]' $ media-ctl -v --set-format
> '"OMAP3 ISP CCDC":1 [UYVY2X8 720x240 field:interlaced-tb]' $ yavta -f UYVY
> -s 720x480 -n 1 --field interlaced-tb --capture=1 -F /dev/video2 $
> raw2rgbpnm -f UYVY -s 720x480 frame-00.bin frame.pnm
> 
> I've also tested the other composite input with the following change:
> 
> diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
> index 5fe5faefe212..973be68ff78c 100644
> --- a/drivers/media/i2c/tvp5150.c
> +++ b/drivers/media/i2c/tvp5150.c
> @@ -1371,7 +1371,7 @@ static int tvp5150_probe(struct i2c_client *c,
> return res;
> 
> core->norm = V4L2_STD_ALL;  /* Default is autodetect */
> -   core->input = TVP5150_COMPOSITE1;
> +   core->input = TVP5150_COMPOSITE0;
> core->enable = true;
> 
> v4l2_ctrl_handler_init(>hdl, 5);
> 
> But as mentioned, it also worked for me without the revert so please let
> me know if the driver works with your omap3 board.
> 
> Best regards,
> Javier
> 
>  drivers/media/i2c/tvp5150.c | 142
>  1 file changed, 142
> deletions(-)
> 
> diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
> index 48646a7f3fb0..5fe5faefe212 100644
> --- a/drivers/media/i2c/tvp5150.c
> +++ b/drivers/media/i2c/tvp5150.c
> @@ -42,8 +42,6 @@ struct tvp5150 {
>   struct v4l2_subdev sd;
>  #ifdef CONFIG_MEDIA_CONTROLLER
>   struct media_pad pads[DEMOD_NUM_PADS];
> - struct media_entity input_ent[TVP5150_INPUT_NUM];
> - struct media_pad input_pad[TVP5150_INPUT_NUM];
>  #endif
>   struct v4l2_ctrl_handler hdl;
>   struct v4l2_rect rect;
> @@ -1018,40 +1016,6 @@ static int tvp5150_enum_frame_size(struct v4l2_subdev
> *sd, }
> 
>  /**
> ** -  Media entity ops
> -
> ***
> */ -
> -#ifdef CONFIG_MEDIA_CONTROLLER
> -static int tvp5150_link_setup(struct media_entity *entity,
> -   const struct media_pad *local,
> -   const struct media_pad *remote, u32 flags)
> -{
> - struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
> - struct tvp5150 *decoder = to_tvp5150(sd);
> - int i;
> -
> - for (i = 0; i < TVP5150_INPUT_NUM; i++) {
> - if (remote->entity == >input_ent[i])
> - break;
> - }
> -
> - /* Do nothing for entities that are not input connectors */
> - if (i == TVP5150_INPUT_NUM)
> - return 0;
> -
> - decoder->input = i;
> -
> - tvp5150_selmux(sd);
> -
> - return 0;
> -}
> -
> -static const struct media_entity_operations tvp5150_sd_media_ops = {
> - .link_setup = tvp5150_link_setup,
> -};
> -#endif
> -
> -/**
> ** I2C Command
>  
> ***
> */
> 
> @@ -1188,42 +1152,6 @@ static int tvp5150_g_tuner(struct v4l2_subdev *sd,
> struct v4l2_tuner *vt) return 0;
>  }
> 
> -static int tvp5150_registered(struct v4l2_subdev *sd)
> -{
> -#ifdef CONFIG_MEDIA_CONTROLLER
> - struct tvp5150 *decoder = to_tvp5150(sd);
> - int ret = 0;
> - int i;
> -
> - for (i = 0; i < TVP5150_INPUT_NUM; i++) {
> - struct media_entity *input = >input_ent[i];
> - struct media_pad *pad = >input_pad[i];
> -
> - if (!input->name)
> - continue;
> -
> - decoder->input_pad[i].flags = MEDIA_PAD_FL_SOURCE;
> -
> - ret = media_entity_pads_init(input, 1, pad);
> - if (ret < 0)
> - return ret;
> 

RE: [PATCH-resend] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

[Luck, Tony]

> It's unclear (to lil ole me) what the end-user-visible effects of this
> are.
>
> Could we please have a description of that?  So a) people can
> understand your decision to cc:stable and b) people whose kernels are
> misbehaving can use your description to decide whether your patch might
> fix the issue their users are reporting.

Ingo already applied this to the tip tree, so too late to fix the commit 
message :-(

A very, very, unlucky end user with a system that supports machine check 
recovery
(Xeon E7, or Xeon-SP-platinum) that has recovered from one or more uncorrected
memory errors (lucky so far) might find a subsequent uncorrected memory error 
flagged
as fatal because the machine check bank that should log the error is already 
occupied
by a log caused by a speculative access to one of the earlier uncorrected 
errors (the
unlucky part).

We haven't seen this happen at the Linux OS level, but it is a theoretical 
possibility.
[Some BIOS that map physical memory 1:1 have seen this when doing eMCA 
processing
for the first error ... as soon as they load the address of the error from the 
MCi_ADDR
register they are vulnerable to some speculative access dereferencing the 
register with 
the address and setting the overflow bit in the machine check bank that still 
holds the
original log].

-Tony

RE: [PATCH-resend] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

[Luck, Tony]

> It's unclear (to lil ole me) what the end-user-visible effects of this
> are.
>
> Could we please have a description of that?  So a) people can
> understand your decision to cc:stable and b) people whose kernels are
> misbehaving can use your description to decide whether your patch might
> fix the issue their users are reporting.

Ingo already applied this to the tip tree, so too late to fix the commit 
message :-(

A very, very, unlucky end user with a system that supports machine check 
recovery
(Xeon E7, or Xeon-SP-platinum) that has recovered from one or more uncorrected
memory errors (lucky so far) might find a subsequent uncorrected memory error 
flagged
as fatal because the machine check bank that should log the error is already 
occupied
by a log caused by a speculative access to one of the earlier uncorrected 
errors (the
unlucky part).

We haven't seen this happen at the Linux OS level, but it is a theoretical 
possibility.
[Some BIOS that map physical memory 1:1 have seen this when doing eMCA 
processing
for the first error ... as soon as they load the address of the error from the 
MCi_ADDR
register they are vulnerable to some speculative access dereferencing the 
register with 
the address and setting the overflow bit in the machine check bank that still 
holds the
original log].

-Tony

mmotm 2017-08-17-16-29 uploaded

[akpm]

The mm-of-the-moment snapshot 2017-08-17-16-29 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (4.x
or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.

A git tree which contains the memory management portion of this tree is
maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
by Michal Hocko.  It contains the patches which are between the
"#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
file, http://www.ozlabs.org/~akpm/mmotm/series.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/

To develop on top of mmotm git:

  $ git remote add mmotm 
git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
  $ git remote update mmotm
  $ git checkout -b topic mmotm/master
  
  $ git send-email mmotm/master.. [...]

To rebase a branch with older patches to a new mmotm release:

  $ git remote update mmotm
  $ git rebase --onto mmotm/master  topic




The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is available at

http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/

and use of this tree is similar to
http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.


This mmotm tree contains the following patches against 4.13-rc5:
(patches marked "*" will be included in linux-next)

  origin.patch
  i-need-old-gcc.patch
* mm-skip-hwpoisoned-pages-when-onlining-pages.patch
* fortify-use-warn-instead-of-bug-for-now.patch
* adfs-use-unsigned-types-for-memcpy-length.patch
* mm-memcontrol-fix-null-pointer-crash-in-test_clear_page_writeback.patch
* kernel-watchdog-fix-kconfig-constraints-for-perf-hardlockup-watchdog.patch
* wait-add-wait_event_killable_timeout.patch
* kmod-fix-wait-on-recursive-loop.patch
* test_kmod-fix-description-for-s-and-c-parameters.patch
* mm-discard-memblock-data-later.patch
* slub-fix-per-memcg-cache-leak-on-css-offline.patch
* mm-fix-double-mmap_sem-unlock-on-mmf_unstable-enforced-sigbus.patch
* mm-oom-fix-potential-data-corruption-when-oom_reaper-races-with-writer.patch
* signal-dont-remove-signal_unkillable-for-traced-tasks.patch
* mm-cma-fix-stack-corruption-due-to-sprintf-usage.patch
* mm-mempolicy-fix-use-after-free-when-calling-get_mempolicy.patch
* mm-vmalloc-dont-unconditonally-use-__gfp_highmem.patch
* mm-hwpoison-clear-present-bit-for-kernel-1-1-mappings-of-poison-pages.patch
* mm-revert-x86_64-and-arm64-elf_et_dyn_base-base.patch
* arm-arch-arm-include-asm-pageh-needs-personalityh.patch
* metag-numa-remove-the-unused-parent_node-macro.patch
* mm-add-vm_insert_mixed_mkwrite.patch
* dax-relocate-some-dax-functions.patch
* dax-use-common-4k-zero-page-for-dax-mmap-reads.patch
* dax-remove-dax-code-from-page_cache_tree_insert.patch
* dax-move-all-dax-radix-tree-defs-to-fs-daxc.patch
* dax-explain-how-read2-write2-addresses-are-validated.patch
* modpost-simplify-sec_name.patch
* ocfs2-make-ocfs2_set_acl-static.patch
* ocfs2-get-rid-of-ocfs2_is_o2cb_active-function.patch
* 
ocfs2-old-mle-put-and-release-after-the-function-dlm_add_migration_mle-called.patch
* 
ocfs2-old-mle-put-and-release-after-the-function-dlm_add_migration_mle-called-fix.patch
* ocfs2-dlm-optimization-of-code-while-free-dead-node-locks.patch
* 
ocfs2-dlm-optimization-of-code-while-free-dead-node-locks-checkpatch-fixes.patch
* ocfs2-give-an-obvious-tip-for-dismatch-cluster-names.patch
* ocfs2-give-an-obvious-tip-for-dismatch-cluster-names-v2.patch
* ocfs2-move-some-definitions-to-header-file.patch
* ocfs2-fix-some-small-problems.patch
* ocfs2-add-kobject-for-online-file-check.patch
* ocfs2-add-duplicative-ino-number-check.patch
* 
block-restore-proc-partitions-to-not-display-non-partitionable-removable-devices.patch
  mm.patch
* slub-make-sure-struct-kmem_cache_node-is-initialized-before-publication.patch
* mm-add-slub-free-list-pointer-obfuscation.patch
* 

mmotm 2017-08-17-16-29 uploaded

[akpm]

The mm-of-the-moment snapshot 2017-08-17-16-29 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (4.x
or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.

A git tree which contains the memory management portion of this tree is
maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
by Michal Hocko.  It contains the patches which are between the
"#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
file, http://www.ozlabs.org/~akpm/mmotm/series.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/

To develop on top of mmotm git:

  $ git remote add mmotm 
git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
  $ git remote update mmotm
  $ git checkout -b topic mmotm/master
  
  $ git send-email mmotm/master.. [...]

To rebase a branch with older patches to a new mmotm release:

  $ git remote update mmotm
  $ git rebase --onto mmotm/master  topic




The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is available at

http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/

and use of this tree is similar to
http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.


This mmotm tree contains the following patches against 4.13-rc5:
(patches marked "*" will be included in linux-next)

  origin.patch
  i-need-old-gcc.patch
* mm-skip-hwpoisoned-pages-when-onlining-pages.patch
* fortify-use-warn-instead-of-bug-for-now.patch
* adfs-use-unsigned-types-for-memcpy-length.patch
* mm-memcontrol-fix-null-pointer-crash-in-test_clear_page_writeback.patch
* kernel-watchdog-fix-kconfig-constraints-for-perf-hardlockup-watchdog.patch
* wait-add-wait_event_killable_timeout.patch
* kmod-fix-wait-on-recursive-loop.patch
* test_kmod-fix-description-for-s-and-c-parameters.patch
* mm-discard-memblock-data-later.patch
* slub-fix-per-memcg-cache-leak-on-css-offline.patch
* mm-fix-double-mmap_sem-unlock-on-mmf_unstable-enforced-sigbus.patch
* mm-oom-fix-potential-data-corruption-when-oom_reaper-races-with-writer.patch
* signal-dont-remove-signal_unkillable-for-traced-tasks.patch
* mm-cma-fix-stack-corruption-due-to-sprintf-usage.patch
* mm-mempolicy-fix-use-after-free-when-calling-get_mempolicy.patch
* mm-vmalloc-dont-unconditonally-use-__gfp_highmem.patch
* mm-hwpoison-clear-present-bit-for-kernel-1-1-mappings-of-poison-pages.patch
* mm-revert-x86_64-and-arm64-elf_et_dyn_base-base.patch
* arm-arch-arm-include-asm-pageh-needs-personalityh.patch
* metag-numa-remove-the-unused-parent_node-macro.patch
* mm-add-vm_insert_mixed_mkwrite.patch
* dax-relocate-some-dax-functions.patch
* dax-use-common-4k-zero-page-for-dax-mmap-reads.patch
* dax-remove-dax-code-from-page_cache_tree_insert.patch
* dax-move-all-dax-radix-tree-defs-to-fs-daxc.patch
* dax-explain-how-read2-write2-addresses-are-validated.patch
* modpost-simplify-sec_name.patch
* ocfs2-make-ocfs2_set_acl-static.patch
* ocfs2-get-rid-of-ocfs2_is_o2cb_active-function.patch
* 
ocfs2-old-mle-put-and-release-after-the-function-dlm_add_migration_mle-called.patch
* 
ocfs2-old-mle-put-and-release-after-the-function-dlm_add_migration_mle-called-fix.patch
* ocfs2-dlm-optimization-of-code-while-free-dead-node-locks.patch
* 
ocfs2-dlm-optimization-of-code-while-free-dead-node-locks-checkpatch-fixes.patch
* ocfs2-give-an-obvious-tip-for-dismatch-cluster-names.patch
* ocfs2-give-an-obvious-tip-for-dismatch-cluster-names-v2.patch
* ocfs2-move-some-definitions-to-header-file.patch
* ocfs2-fix-some-small-problems.patch
* ocfs2-add-kobject-for-online-file-check.patch
* ocfs2-add-duplicative-ino-number-check.patch
* 
block-restore-proc-partitions-to-not-display-non-partitionable-removable-devices.patch
  mm.patch
* slub-make-sure-struct-kmem_cache_node-is-initialized-before-publication.patch
* mm-add-slub-free-list-pointer-obfuscation.patch
* 

Re: [PATCH 2/2] Revert "pstore: Honor dmesg_restrict sysctl on dmesg dumps"

[Sergey Senozhatsky]

Hello,

On (08/17/17 16:01), Kees Cook wrote:
> On Wed, Aug 16, 2017 at 6:29 PM, Sergey Senozhatsky
>  wrote:
> > can we accidentally "leak" kernel pointers or some other critical
> > info? kptr_restrict requires CAP_SYSLOG and pstore read used to
> > require CAP_SYSLOG, but it seems that now we can bypass it by
> > letting "entirely unprivileged groups" to read pstore. is there
> > something to be concerned about (or at least mention it in the
> > commit messages)?
> 
> I can expand the commit message a bit more, sure.

that would be lovely. please do.

> There may be sensitive things in pstorefs, and it's up to a system builder
> to decide how they want to deal with that risk. Most users of pstore
> don't mount with update_ms=N so pstorefs contains (mostly) old
> addresses.

I see...

> Without this change, though, a builder can't give permissions to an
> unprivileged crash dump process without also giving it CAP_SYSLOG which
> has much MORE privilege that it would need (reading and wiping _current_
> dmesg, for example).

ok, the "CAP_SYSLOG and _current_ dmesg" point is surely interesting.
could you please also add this to the commit message?


FWIW, both patches

Reviewed-by: Sergey Senozhatsky 

-ss

Re: [PATCH 2/2] Revert "pstore: Honor dmesg_restrict sysctl on dmesg dumps"

[Sergey Senozhatsky]

Hello,

On (08/17/17 16:01), Kees Cook wrote:
> On Wed, Aug 16, 2017 at 6:29 PM, Sergey Senozhatsky
>  wrote:
> > can we accidentally "leak" kernel pointers or some other critical
> > info? kptr_restrict requires CAP_SYSLOG and pstore read used to
> > require CAP_SYSLOG, but it seems that now we can bypass it by
> > letting "entirely unprivileged groups" to read pstore. is there
> > something to be concerned about (or at least mention it in the
> > commit messages)?
> 
> I can expand the commit message a bit more, sure.

that would be lovely. please do.

> There may be sensitive things in pstorefs, and it's up to a system builder
> to decide how they want to deal with that risk. Most users of pstore
> don't mount with update_ms=N so pstorefs contains (mostly) old
> addresses.

I see...

> Without this change, though, a builder can't give permissions to an
> unprivileged crash dump process without also giving it CAP_SYSLOG which
> has much MORE privilege that it would need (reading and wiping _current_
> dmesg, for example).

ok, the "CAP_SYSLOG and _current_ dmesg" point is surely interesting.
could you please also add this to the commit message?


FWIW, both patches

Reviewed-by: Sergey Senozhatsky 

-ss

Re: [PATCH v2] blktrace: Fix potentail deadlock between delete & sysfs ops

[Steven Rostedt]

On Thu, 17 Aug 2017 18:18:18 -0400
Steven Rostedt  wrote:

> On Thu, 17 Aug 2017 18:13:20 -0400
> Steven Rostedt  wrote:
> 
> > On Thu, 17 Aug 2017 17:27:22 -0400
> > Waiman Long  wrote:
> > 
> >   
> > > It is actually what the patch is trying to do by checking for the
> > > deletion flag in the mutex_trylock loop. Please note that mutex does not
> > > guarantee FIFO ordering of lock acquisition. As a result, cpu1 may call
> > > mutex_lock() and wait for it while cpu2 can set the deletion flag later
> > > and get the mutex first before cpu1. So checking for the deletion flag
> > > before taking the mutex isn't enough.
> > 
> > Yeah, I figured that out already (crossed emails). BTW, how did you
> > trigger this warning. I'm playing around with adding loop devices,
> > volume groups, and logical volumes, and reading the trace files
> > created in the sysfs directory, then removing those items, but it's
> > not triggering the "delete" path. What operation deletes the partition?  
> 
> I'm guessing that deleting an actual partition may work (unfortunately,
> my test box has no partition to delete ;-) I'll find another box to
> test on.
>

OK, deleting a partition doesn't trigger the lockdep splat. But I also
added a printk in the BLKPG_DEL_PARTITION case switch, which also
doesn't print. What command do I need to do to trigger that path?

Thanks,

-- Steve

Re: [PATCH v2] blktrace: Fix potentail deadlock between delete & sysfs ops

[Steven Rostedt]

On Thu, 17 Aug 2017 18:18:18 -0400
Steven Rostedt  wrote:

> On Thu, 17 Aug 2017 18:13:20 -0400
> Steven Rostedt  wrote:
> 
> > On Thu, 17 Aug 2017 17:27:22 -0400
> > Waiman Long  wrote:
> > 
> >   
> > > It is actually what the patch is trying to do by checking for the
> > > deletion flag in the mutex_trylock loop. Please note that mutex does not
> > > guarantee FIFO ordering of lock acquisition. As a result, cpu1 may call
> > > mutex_lock() and wait for it while cpu2 can set the deletion flag later
> > > and get the mutex first before cpu1. So checking for the deletion flag
> > > before taking the mutex isn't enough.
> > 
> > Yeah, I figured that out already (crossed emails). BTW, how did you
> > trigger this warning. I'm playing around with adding loop devices,
> > volume groups, and logical volumes, and reading the trace files
> > created in the sysfs directory, then removing those items, but it's
> > not triggering the "delete" path. What operation deletes the partition?  
> 
> I'm guessing that deleting an actual partition may work (unfortunately,
> my test box has no partition to delete ;-) I'll find another box to
> test on.
>

OK, deleting a partition doesn't trigger the lockdep splat. But I also
added a printk in the BLKPG_DEL_PARTITION case switch, which also
doesn't print. What command do I need to do to trigger that path?

Thanks,

-- Steve

[PATCH net] rxrpc: Fix oops when discarding a preallocated service call

[David Howells]

rxrpc_service_prealloc_one() doesn't set the socket pointer on any new call
it preallocates, but does add it to the rxrpc net namespace call list.
This, however, causes rxrpc_put_call() to oops when the call is discarded
when the socket is closed.  rxrpc_put_call() needs the socket to be able to
reach the namespace so that it can use a lock held therein.

Fix this by setting a call's socket pointer immediately before discarding
it.

This can be triggered by unloading the kafs module, resulting in an oops
like the following:

BUG: unable to handle kernel NULL pointer dereference at 0030
IP: rxrpc_put_call+0x1e2/0x32d
PGD 0
P4D 0
Oops:  [#1] SMP
Modules linked in: kafs(E-)
CPU: 3 PID: 3037 Comm: rmmod Tainted: GE   4.12.0-fscache+ #213
Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
task: 8803fc92e2c0 task.stack: 8803fef74000
RIP: 0010:rxrpc_put_call+0x1e2/0x32d
RSP: 0018:8803fef77e08 EFLAGS: 00010282
RAX:  RBX: 8803fab99ac0 RCX: 000f
RDX: 81c50a40 RSI: 000c RDI: 8803fc92ea88
RBP: 8803fef77e30 R08: 8803fc87b941 R09: 82946d20
R10: 8803fef77d10 R11: 76fc R12: 0005
R13: 8803fab99c20 R14: 0001 R15: 816c6aee
FS:  7f915a059700() GS:88041fb8() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0030 CR3: 0003fef39000 CR4: 001406e0
Call Trace:
 rxrpc_discard_prealloc+0x325/0x341
 rxrpc_listen+0xf9/0x146
 kernel_listen+0xb/0xd
 afs_close_socket+0x3e/0x173 [kafs]
 afs_exit+0x1f/0x57 [kafs]
 SyS_delete_module+0x10f/0x19a
 do_syscall_64+0x8a/0x149
 entry_SYSCALL64_slow_path+0x25/0x25

Fixes: 2baec2c3f854 ("rxrpc: Support network namespacing")
Signed-off-by: David Howells 
cc: sta...@vger.kernel.org
---

 net/rxrpc/call_accept.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/net/rxrpc/call_accept.c b/net/rxrpc/call_accept.c
index dd30d74824b0..ec3383f97d4c 100644
--- a/net/rxrpc/call_accept.c
+++ b/net/rxrpc/call_accept.c
@@ -223,6 +223,7 @@ void rxrpc_discard_prealloc(struct rxrpc_sock *rx)
tail = b->call_backlog_tail;
while (CIRC_CNT(head, tail, size) > 0) {
struct rxrpc_call *call = b->call_backlog[tail];
+   call->socket = rx;
if (rx->discard_new_call) {
_debug("discard %lx", call->user_call_ID);
rx->discard_new_call(call, call->user_call_ID);

Re: [RFC][PATCHv5 06/13] printk: register PM notifier

[Sergey Senozhatsky]

Hello,

On (08/17/17 17:43), Rafael J. Wysocki wrote:
[..]
> > > In that case I would call printk_emergency_begin_sync() from
> > > dpm_prepare() and printk_emergency_end_sync() from dpm_complete().
> > 
> > hm, isn't it the case that dpm_prepare/dpm_complete are invoked only
> > by hibernate path? or does suspend path (s2ram, etc.) also calls
> > dpm_prepare/dpm_complete?
> 
> Yes, it does.

oh, good.

> > the 3 things we need to have (in PM context) for offloading:
> > - unparked printk kthread
> > - running scheduler
> > - online non-boot CPUs (on a UP system, or with non-boot CPUs disabled,
> >   offloading is a bit questionable)
> > 
> > - hm, may be something else...
> 
> All of that is there during the entire device suspend/resume including
> dpm_suspend/resume_noirq().
>
> But probably dpm_prepare/complete() are better places for the hooks at
> least for now.

ok, thanks.

> > > I just don't see much point in using the notifier thing if you can
> > > achieve basically the same without using it. :-)
> > 
> > sure, I just didn't want to mix printk internals with PM internals.
> > that would put us in position of verifying future PM changes from
> > printk-kthread point of view as well; and it can be quite complex,
> > because printk offloading brings in big guns like scheduler and
> > timekeeping. so the notifiers interface looks like a good
> > alternative, besides those notifications happen early (and late)
> > enough to keep us on the safe side.
> > 
> > well, I may be wrong.
> 
> I prefer direct invocations, becasue they generally allow to figure out
> what's going on by simply following the code instead of having to
> track all of the users of the notifiers to see what they may have
> registered.

I see the point: notifiers, in some sense, help us to alter sub-systems
without ever touching them or even explaining anything to the maintainers.
we just register a notifier and all of a sudden sub-system FOO begins to
execute our code at some point. all done entirely with in the printk.c file.
there is some power/flexibility and, perhaps, beauty in it, but there is
also some potential for abuse/wrongdoing in it. if direct calls work better
for you (and PM), then no objections from my side :)

> Moreover, the ordering of what happens is clear then, whereas with notifiers 
> it
> depends on the registration ordering and the entry and exit path orderings of
> notifiers are the same which may be problematic sometimes.
> 
> In fact, the PM notifiers are mostly for stuff that cannot be done with frozen
> user space and surely not for core subsystems.
> 
> Let alone that adding two lines of code is better than adding 50 lines for the
> same purpose IMO ...

ok. I can rework the PM patch and get rid of notifiers for the next
submission (unless there will be objections from others). will take
a look.

thanks!

-ss

Re: [RFC][PATCHv5 06/13] printk: register PM notifier

[Sergey Senozhatsky]

Hello,

On (08/17/17 17:43), Rafael J. Wysocki wrote:
[..]
> > > In that case I would call printk_emergency_begin_sync() from
> > > dpm_prepare() and printk_emergency_end_sync() from dpm_complete().
> > 
> > hm, isn't it the case that dpm_prepare/dpm_complete are invoked only
> > by hibernate path? or does suspend path (s2ram, etc.) also calls
> > dpm_prepare/dpm_complete?
> 
> Yes, it does.

oh, good.

> > the 3 things we need to have (in PM context) for offloading:
> > - unparked printk kthread
> > - running scheduler
> > - online non-boot CPUs (on a UP system, or with non-boot CPUs disabled,
> >   offloading is a bit questionable)
> > 
> > - hm, may be something else...
> 
> All of that is there during the entire device suspend/resume including
> dpm_suspend/resume_noirq().
>
> But probably dpm_prepare/complete() are better places for the hooks at
> least for now.

ok, thanks.

> > > I just don't see much point in using the notifier thing if you can
> > > achieve basically the same without using it. :-)
> > 
> > sure, I just didn't want to mix printk internals with PM internals.
> > that would put us in position of verifying future PM changes from
> > printk-kthread point of view as well; and it can be quite complex,
> > because printk offloading brings in big guns like scheduler and
> > timekeeping. so the notifiers interface looks like a good
> > alternative, besides those notifications happen early (and late)
> > enough to keep us on the safe side.
> > 
> > well, I may be wrong.
> 
> I prefer direct invocations, becasue they generally allow to figure out
> what's going on by simply following the code instead of having to
> track all of the users of the notifiers to see what they may have
> registered.

I see the point: notifiers, in some sense, help us to alter sub-systems
without ever touching them or even explaining anything to the maintainers.
we just register a notifier and all of a sudden sub-system FOO begins to
execute our code at some point. all done entirely with in the printk.c file.
there is some power/flexibility and, perhaps, beauty in it, but there is
also some potential for abuse/wrongdoing in it. if direct calls work better
for you (and PM), then no objections from my side :)

> Moreover, the ordering of what happens is clear then, whereas with notifiers 
> it
> depends on the registration ordering and the entry and exit path orderings of
> notifiers are the same which may be problematic sometimes.
> 
> In fact, the PM notifiers are mostly for stuff that cannot be done with frozen
> user space and surely not for core subsystems.
> 
> Let alone that adding two lines of code is better than adding 50 lines for the
> same purpose IMO ...

ok. I can rework the PM patch and get rid of notifiers for the next
submission (unless there will be objections from others). will take
a look.

thanks!

-ss

[PATCH net] rxrpc: Fix oops when discarding a preallocated service call

[David Howells]

rxrpc_service_prealloc_one() doesn't set the socket pointer on any new call
it preallocates, but does add it to the rxrpc net namespace call list.
This, however, causes rxrpc_put_call() to oops when the call is discarded
when the socket is closed.  rxrpc_put_call() needs the socket to be able to
reach the namespace so that it can use a lock held therein.

Fix this by setting a call's socket pointer immediately before discarding
it.

This can be triggered by unloading the kafs module, resulting in an oops
like the following:

BUG: unable to handle kernel NULL pointer dereference at 0030
IP: rxrpc_put_call+0x1e2/0x32d
PGD 0
P4D 0
Oops:  [#1] SMP
Modules linked in: kafs(E-)
CPU: 3 PID: 3037 Comm: rmmod Tainted: GE   4.12.0-fscache+ #213
Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
task: 8803fc92e2c0 task.stack: 8803fef74000
RIP: 0010:rxrpc_put_call+0x1e2/0x32d
RSP: 0018:8803fef77e08 EFLAGS: 00010282
RAX:  RBX: 8803fab99ac0 RCX: 000f
RDX: 81c50a40 RSI: 000c RDI: 8803fc92ea88
RBP: 8803fef77e30 R08: 8803fc87b941 R09: 82946d20
R10: 8803fef77d10 R11: 76fc R12: 0005
R13: 8803fab99c20 R14: 0001 R15: 816c6aee
FS:  7f915a059700() GS:88041fb8() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0030 CR3: 0003fef39000 CR4: 001406e0
Call Trace:
 rxrpc_discard_prealloc+0x325/0x341
 rxrpc_listen+0xf9/0x146
 kernel_listen+0xb/0xd
 afs_close_socket+0x3e/0x173 [kafs]
 afs_exit+0x1f/0x57 [kafs]
 SyS_delete_module+0x10f/0x19a
 do_syscall_64+0x8a/0x149
 entry_SYSCALL64_slow_path+0x25/0x25

Fixes: 2baec2c3f854 ("rxrpc: Support network namespacing")
Signed-off-by: David Howells 
cc: sta...@vger.kernel.org
---

 net/rxrpc/call_accept.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/net/rxrpc/call_accept.c b/net/rxrpc/call_accept.c
index dd30d74824b0..ec3383f97d4c 100644
--- a/net/rxrpc/call_accept.c
+++ b/net/rxrpc/call_accept.c
@@ -223,6 +223,7 @@ void rxrpc_discard_prealloc(struct rxrpc_sock *rx)
tail = b->call_backlog_tail;
while (CIRC_CNT(head, tail, size) > 0) {
struct rxrpc_call *call = b->call_backlog[tail];
+   call->socket = rx;
if (rx->discard_new_call) {
_debug("discard %lx", call->user_call_ID);
rx->discard_new_call(call, call->user_call_ID);

Re: [PATCH] selftests: timers: drop support for !KTEST case

[John Stultz]

On Thu, Aug 17, 2017 at 12:41 PM, Shuah Khan  wrote:
> There is no need to keep timers tests in sync with external timers
> repo. Drop support for !KTEST to support for building and running
> timers tests without kselftest framework.
>
> Reference: https://lkml.org/lkml/2017/8/10/952
> Signed-off-by: Shuah Khan 

Acked-by: John Stultz 

Re: [PATCH] selftests: timers: drop support for !KTEST case

[John Stultz]

On Thu, Aug 17, 2017 at 12:41 PM, Shuah Khan  wrote:
> There is no need to keep timers tests in sync with external timers
> repo. Drop support for !KTEST to support for building and running
> timers tests without kselftest framework.
>
> Reference: https://lkml.org/lkml/2017/8/10/952
> Signed-off-by: Shuah Khan 

Acked-by: John Stultz 

[PATCH] media: venus: fix duplicated code for different branches

[Gustavo A. R. Silva]

Refactor code in order to avoid identical code for different branches.

This issue was detected with the help of Coccinelle.

Addresses-Coverity-ID: 1415317
Signed-off-by: Gustavo A. R. Silva 
---
This code was reported by Coverity and it was tested by compilation only.
Please, verify if this is an actual bug.

 drivers/media/platform/qcom/venus/helpers.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/helpers.c 
b/drivers/media/platform/qcom/venus/helpers.c
index 5f4434c..8a5c467 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -240,11 +240,7 @@ static void return_buf_error(struct venus_inst *inst,
 {
struct v4l2_m2m_ctx *m2m_ctx = inst->m2m_ctx;
 
-   if (vbuf->vb2_buf.type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
-   v4l2_m2m_src_buf_remove_by_buf(m2m_ctx, vbuf);
-   else
-   v4l2_m2m_src_buf_remove_by_buf(m2m_ctx, vbuf);
-
+   v4l2_m2m_src_buf_remove_by_buf(m2m_ctx, vbuf);
v4l2_m2m_buf_done(vbuf, VB2_BUF_STATE_ERROR);
 }
 
-- 
2.5.0

[PATCH] media: venus: fix duplicated code for different branches

[Gustavo A. R. Silva]

Refactor code in order to avoid identical code for different branches.

This issue was detected with the help of Coccinelle.

Addresses-Coverity-ID: 1415317
Signed-off-by: Gustavo A. R. Silva 
---
This code was reported by Coverity and it was tested by compilation only.
Please, verify if this is an actual bug.

 drivers/media/platform/qcom/venus/helpers.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/helpers.c 
b/drivers/media/platform/qcom/venus/helpers.c
index 5f4434c..8a5c467 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -240,11 +240,7 @@ static void return_buf_error(struct venus_inst *inst,
 {
struct v4l2_m2m_ctx *m2m_ctx = inst->m2m_ctx;
 
-   if (vbuf->vb2_buf.type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
-   v4l2_m2m_src_buf_remove_by_buf(m2m_ctx, vbuf);
-   else
-   v4l2_m2m_src_buf_remove_by_buf(m2m_ctx, vbuf);
-
+   v4l2_m2m_src_buf_remove_by_buf(m2m_ctx, vbuf);
v4l2_m2m_buf_done(vbuf, VB2_BUF_STATE_ERROR);
 }
 
-- 
2.5.0

Re: [PATCH 1/2] MIPS: Add Onion Omega2+ board

[kbuild test robot]

Hi Harvey,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.13-rc5 next-20170817]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Harvey-Hunt/MIPS-Add-Onion-Omega2-board/20170818-033709
config: mips-maltaup_xpa_defconfig (attached as .config)
compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> FATAL ERROR: Couldn't open "mt7628a.dtsi": No such file or directory

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 1/2] MIPS: Add Onion Omega2+ board

[kbuild test robot]

Hi Harvey,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.13-rc5 next-20170817]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Harvey-Hunt/MIPS-Add-Onion-Omega2-board/20170818-033709
config: mips-maltaup_xpa_defconfig (attached as .config)
compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> FATAL ERROR: Couldn't open "mt7628a.dtsi": No such file or directory

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 2/2] Revert "pstore: Honor dmesg_restrict sysctl on dmesg dumps"

[Kees Cook]

On Wed, Aug 16, 2017 at 6:29 PM, Sergey Senozhatsky
 wrote:
> can we accidentally "leak" kernel pointers or some other critical
> info? kptr_restrict requires CAP_SYSLOG and pstore read used to
> require CAP_SYSLOG, but it seems that now we can bypass it by
> letting "entirely unprivileged groups" to read pstore. is there
> something to be concerned about (or at least mention it in the
> commit messages)?

I can expand the commit message a bit more, sure. There may be
sensitive things in pstorefs, and it's up to a system builder to
decide how they want to deal with that risk. Most users of pstore
don't mount with update_ms=N so pstorefs contains (mostly) old
addresses. Without this change, though, a builder can't give
permissions to an unprivileged crash dump process without also giving
it CAP_SYSLOG which has much MORE privilege that it would need
(reading and wiping _current_ dmesg, for example).

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH 2/2] Revert "pstore: Honor dmesg_restrict sysctl on dmesg dumps"

[Kees Cook]

On Wed, Aug 16, 2017 at 6:29 PM, Sergey Senozhatsky
 wrote:
> can we accidentally "leak" kernel pointers or some other critical
> info? kptr_restrict requires CAP_SYSLOG and pstore read used to
> require CAP_SYSLOG, but it seems that now we can bypass it by
> letting "entirely unprivileged groups" to read pstore. is there
> something to be concerned about (or at least mention it in the
> commit messages)?

I can expand the commit message a bit more, sure. There may be
sensitive things in pstorefs, and it's up to a system builder to
decide how they want to deal with that risk. Most users of pstore
don't mount with update_ms=N so pstorefs contains (mostly) old
addresses. Without this change, though, a builder can't give
permissions to an unprivileged crash dump process without also giving
it CAP_SYSLOG which has much MORE privilege that it would need
(reading and wiping _current_ dmesg, for example).

-Kees

-- 
Kees Cook
Pixel Security

[PATCH v4] pinctrl: aspeed: Fix ast2500 strap register write logic

[Yong Li]

On AST2500, the hardware strap register(SCU70) only accepts write ‘1’,
to clear it to ‘0’, must set bits(write  ‘1’) to SCU7C

Signed-off-by: Yong Li 
---
 drivers/pinctrl/aspeed/pinctrl-aspeed.c | 21 +
 drivers/pinctrl/aspeed/pinctrl-aspeed.h |  1 +
 2 files changed, 22 insertions(+)

diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed.c 
b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
index a86a4d6..7f13ce8 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
@@ -213,6 +213,27 @@ static int aspeed_sig_expr_set(const struct 
aspeed_sig_expr *expr,
if (desc->ip == ASPEED_IP_SCU && desc->reg == HW_STRAP2)
continue;
 
+   /* On AST2500, Set bits in SCU7C are cleared from SCU70 */
+   if (desc->ip == ASPEED_IP_SCU && desc->reg == HW_STRAP1) {
+   unsigned int rev_id;
+
+   ret = regmap_read(maps[ASPEED_IP_SCU],
+   HW_REVISION_ID, _id);
+   if (ret < 0)
+   return ret;
+
+   if (0x04 == (rev_id >> 24)) {
+   u32 value = ~val & desc->mask;
+
+   if (value) {
+   ret = regmap_write(maps[desc->ip],
+   HW_REVISION_ID, value);
+   if (ret < 0)
+   return ret;
+   }
+   }
+   }
+
ret = regmap_update_bits(maps[desc->ip], desc->reg,
 desc->mask, val);
 
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed.h 
b/drivers/pinctrl/aspeed/pinctrl-aspeed.h
index fa125db..d4d7f03 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed.h
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed.h
@@ -251,6 +251,7 @@
 #define SCU3C   0x3C /* System Reset Control/Status Register */
 #define SCU48   0x48 /* MAC Interface Clock Delay Setting */
 #define HW_STRAP1   0x70 /* AST2400 strapping is 33 bits, is split */
+#define HW_REVISION_ID  0x7C /* Silicon revision ID register */
 #define SCU80   0x80 /* Multi-function Pin Control #1 */
 #define SCU84   0x84 /* Multi-function Pin Control #2 */
 #define SCU88   0x88 /* Multi-function Pin Control #3 */
-- 
2.7.4

[PATCH v4] pinctrl: aspeed: Fix ast2500 strap register write logic

[Yong Li]

On AST2500, the hardware strap register(SCU70) only accepts write ‘1’,
to clear it to ‘0’, must set bits(write  ‘1’) to SCU7C

Signed-off-by: Yong Li 
---
 drivers/pinctrl/aspeed/pinctrl-aspeed.c | 21 +
 drivers/pinctrl/aspeed/pinctrl-aspeed.h |  1 +
 2 files changed, 22 insertions(+)

diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed.c 
b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
index a86a4d6..7f13ce8 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
@@ -213,6 +213,27 @@ static int aspeed_sig_expr_set(const struct 
aspeed_sig_expr *expr,
if (desc->ip == ASPEED_IP_SCU && desc->reg == HW_STRAP2)
continue;
 
+   /* On AST2500, Set bits in SCU7C are cleared from SCU70 */
+   if (desc->ip == ASPEED_IP_SCU && desc->reg == HW_STRAP1) {
+   unsigned int rev_id;
+
+   ret = regmap_read(maps[ASPEED_IP_SCU],
+   HW_REVISION_ID, _id);
+   if (ret < 0)
+   return ret;
+
+   if (0x04 == (rev_id >> 24)) {
+   u32 value = ~val & desc->mask;
+
+   if (value) {
+   ret = regmap_write(maps[desc->ip],
+   HW_REVISION_ID, value);
+   if (ret < 0)
+   return ret;
+   }
+   }
+   }
+
ret = regmap_update_bits(maps[desc->ip], desc->reg,
 desc->mask, val);
 
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed.h 
b/drivers/pinctrl/aspeed/pinctrl-aspeed.h
index fa125db..d4d7f03 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed.h
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed.h
@@ -251,6 +251,7 @@
 #define SCU3C   0x3C /* System Reset Control/Status Register */
 #define SCU48   0x48 /* MAC Interface Clock Delay Setting */
 #define HW_STRAP1   0x70 /* AST2400 strapping is 33 bits, is split */
+#define HW_REVISION_ID  0x7C /* Silicon revision ID register */
 #define SCU80   0x80 /* Multi-function Pin Control #1 */
 #define SCU84   0x84 /* Multi-function Pin Control #2 */
 #define SCU88   0x88 /* Multi-function Pin Control #3 */
-- 
2.7.4

Re: [PATCH 2/2] mm,fork: introduce MADV_WIPEONFORK

[Andrew Morton]

On Tue, 15 Aug 2017 22:18:19 -0400 Rik van Riel  wrote:

> > > --- a/mm/madvise.c
> > > +++ b/mm/madvise.c
> > > @@ -80,6 +80,17 @@ static long madvise_behavior(struct
> > > vm_area_struct *vma,
> > > __}
> > > __new_flags &= ~VM_DONTCOPY;
> > > __break;
> > > + case MADV_WIPEONFORK:
> > > + /* MADV_WIPEONFORK is only supported on anonymous
> > > memory. */
> > > + if (vma->vm_file || vma->vm_flags & VM_SHARED) {
> > > + error = -EINVAL;
> > > + goto out;
> > > + }
> > > + new_flags |= VM_WIPEONFORK;
> > > + break;
> > > + case MADV_KEEPONFORK:
> > > + new_flags &= ~VM_WIPEONFORK;
> > > + break;
> > > __case MADV_DONTDUMP:
> > > __new_flags |= VM_DONTDUMP;
> > > __break;
> > 
> > It seems odd to permit MADV_KEEPONFORK against other-than-anon vmas?
> 
> Given that the only way to set VM_WIPEONFORK is through
> MADV_WIPEONFORK, calling MADV_KEEPONFORK on an
> other-than-anon vma would be equivalent to a noop.
> 
> If new_flags == vma->vm_flags, madvise_behavior() will
> immediately exit.

Yes, but calling MADV_WIPEONFORK against an other-than-anon vma is
presumably a userspace bug.  A bug which will probably result in
userspace having WIPEONFORK memory which it didn't want.  The kernel
can trivially tell userspace that it has this bug so why not do so?

Re: [PATCH 2/2] mm,fork: introduce MADV_WIPEONFORK

[Andrew Morton]

On Tue, 15 Aug 2017 22:18:19 -0400 Rik van Riel  wrote:

> > > --- a/mm/madvise.c
> > > +++ b/mm/madvise.c
> > > @@ -80,6 +80,17 @@ static long madvise_behavior(struct
> > > vm_area_struct *vma,
> > > __}
> > > __new_flags &= ~VM_DONTCOPY;
> > > __break;
> > > + case MADV_WIPEONFORK:
> > > + /* MADV_WIPEONFORK is only supported on anonymous
> > > memory. */
> > > + if (vma->vm_file || vma->vm_flags & VM_SHARED) {
> > > + error = -EINVAL;
> > > + goto out;
> > > + }
> > > + new_flags |= VM_WIPEONFORK;
> > > + break;
> > > + case MADV_KEEPONFORK:
> > > + new_flags &= ~VM_WIPEONFORK;
> > > + break;
> > > __case MADV_DONTDUMP:
> > > __new_flags |= VM_DONTDUMP;
> > > __break;
> > 
> > It seems odd to permit MADV_KEEPONFORK against other-than-anon vmas?
> 
> Given that the only way to set VM_WIPEONFORK is through
> MADV_WIPEONFORK, calling MADV_KEEPONFORK on an
> other-than-anon vma would be equivalent to a noop.
> 
> If new_flags == vma->vm_flags, madvise_behavior() will
> immediately exit.

Yes, but calling MADV_WIPEONFORK against an other-than-anon vma is
presumably a userspace bug.  A bug which will probably result in
userspace having WIPEONFORK memory which it didn't want.  The kernel
can trivially tell userspace that it has this bug so why not do so?

[PATCH] selftests: timers: Fix run_destructive_tests target to handle skipped tests

[Shuah Khan]

When a test exits with skip exit code of 4, "make run_destructive_tests"
halts testing. Fix run_destructive_tests target to handle error exit codes.

Reported-by: John Stultz 
Signed-off-by: Shuah Khan 
---
 tools/testing/selftests/timers/Makefile | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/tools/testing/selftests/timers/Makefile 
b/tools/testing/selftests/timers/Makefile
index c805ab048d26..6c1327278d5f 100644
--- a/tools/testing/selftests/timers/Makefile
+++ b/tools/testing/selftests/timers/Makefile
@@ -13,20 +13,20 @@ TEST_GEN_PROGS_EXTENDED = alarmtimer-suspend valid-adjtimex 
adjtick change_skew
 
 include ../lib.mk
 
+define RUN_DESTRUCTIVE_TESTS
+   @for TEST in $(TEST_GEN_PROGS_EXTENDED); do \
+   BASENAME_TEST=`basename $$TEST`;\
+   if [ ! -x $$BASENAME_TEST ]; then   \
+   echo "selftests: Warning: file $$BASENAME_TEST is not 
executable, correct this.";\
+   echo "selftests: $$BASENAME_TEST [FAIL]"; \
+   else\
+   cd `dirname $$TEST`; (./$$BASENAME_TEST && echo 
"selftests: $$BASENAME_TEST [PASS]") || echo "selftests:  $$BASENAME_TEST 
[FAIL]"; cd -;\
+   fi; \
+   done;
+endef
+
 # these tests require escalated privileges
 # and may modify the system time or trigger
 # other behavior like suspend
 run_destructive_tests: run_tests
-   ./alarmtimer-suspend
-   ./valid-adjtimex
-   ./adjtick
-   ./change_skew
-   ./skew_consistency
-   ./clocksource-switch
-   ./freq-step
-   ./leap-a-day -s -i 10
-   ./leapcrash
-   ./set-tz
-   ./set-tai
-   ./set-2038
-
+   $(RUN_DESTRUCTIVE_TESTS)
-- 
2.11.0

[PATCH] selftests: timers: Fix run_destructive_tests target to handle skipped tests

[Shuah Khan]

When a test exits with skip exit code of 4, "make run_destructive_tests"
halts testing. Fix run_destructive_tests target to handle error exit codes.

Reported-by: John Stultz 
Signed-off-by: Shuah Khan 
---
 tools/testing/selftests/timers/Makefile | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/tools/testing/selftests/timers/Makefile 
b/tools/testing/selftests/timers/Makefile
index c805ab048d26..6c1327278d5f 100644
--- a/tools/testing/selftests/timers/Makefile
+++ b/tools/testing/selftests/timers/Makefile
@@ -13,20 +13,20 @@ TEST_GEN_PROGS_EXTENDED = alarmtimer-suspend valid-adjtimex 
adjtick change_skew
 
 include ../lib.mk
 
+define RUN_DESTRUCTIVE_TESTS
+   @for TEST in $(TEST_GEN_PROGS_EXTENDED); do \
+   BASENAME_TEST=`basename $$TEST`;\
+   if [ ! -x $$BASENAME_TEST ]; then   \
+   echo "selftests: Warning: file $$BASENAME_TEST is not 
executable, correct this.";\
+   echo "selftests: $$BASENAME_TEST [FAIL]"; \
+   else\
+   cd `dirname $$TEST`; (./$$BASENAME_TEST && echo 
"selftests: $$BASENAME_TEST [PASS]") || echo "selftests:  $$BASENAME_TEST 
[FAIL]"; cd -;\
+   fi; \
+   done;
+endef
+
 # these tests require escalated privileges
 # and may modify the system time or trigger
 # other behavior like suspend
 run_destructive_tests: run_tests
-   ./alarmtimer-suspend
-   ./valid-adjtimex
-   ./adjtick
-   ./change_skew
-   ./skew_consistency
-   ./clocksource-switch
-   ./freq-step
-   ./leap-a-day -s -i 10
-   ./leapcrash
-   ./set-tz
-   ./set-tai
-   ./set-2038
-
+   $(RUN_DESTRUCTIVE_TESTS)
-- 
2.11.0

[PATCH 1/1] xen-blkback: stop blkback thread of every queue in xen_blkif_disconnect

[Annie Li]

If there is inflight I/O in any non-last queue, blkback returns -EBUSY
directly, and never stops thread of remaining queue and processs them. When
removing vbd device with lots of disk I/O load, some queues with inflight
I/O still have blkback thread running even though the corresponding vbd
device or guest is gone.
And this could cause some problems, for example, if the backend device type
is file, some loop devices and blkback thread always lingers there forever
after guest is destroyed, and this causes failure of umounting repositories
unless rebooting the dom0. So stop all threads properly and return -EBUSY
if any queue has inflight I/O.

Signed-off-by: Annie Li 
Reviewed-by: Herbert van den Bergh 
Reviewed-by: Bhavesh Davda 
Reviewed-by: Adnan Misherfi 
---
 drivers/block/xen-blkback/xenbus.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/block/xen-blkback/xenbus.c 
b/drivers/block/xen-blkback/xenbus.c
index 792da68..2adb859 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -244,6 +244,7 @@ static int xen_blkif_disconnect(struct xen_blkif *blkif)
 {
struct pending_req *req, *n;
unsigned int j, r;
+   bool busy = false;
 
for (r = 0; r < blkif->nr_rings; r++) {
struct xen_blkif_ring *ring = >rings[r];
@@ -261,8 +262,10 @@ static int xen_blkif_disconnect(struct xen_blkif *blkif)
 * don't have any discard_io or other_io requests. So, checking
 * for inflight IO is enough.
 */
-   if (atomic_read(>inflight) > 0)
-   return -EBUSY;
+   if (atomic_read(>inflight) > 0) {
+   busy = true;
+   continue;
+   }
 
if (ring->irq) {
unbind_from_irqhandler(ring->irq, ring);
@@ -300,6 +303,9 @@ static int xen_blkif_disconnect(struct xen_blkif *blkif)
WARN_ON(i != (XEN_BLKIF_REQS_PER_PAGE * blkif->nr_ring_pages));
ring->active = false;
}
+   if (busy)
+   return -EBUSY;
+
blkif->nr_ring_pages = 0;
/*
 * blkif->rings was allocated in connect_ring, so we should free it in
-- 
1.9.3

[PATCH 1/1] xen-blkback: stop blkback thread of every queue in xen_blkif_disconnect

[Annie Li]

If there is inflight I/O in any non-last queue, blkback returns -EBUSY
directly, and never stops thread of remaining queue and processs them. When
removing vbd device with lots of disk I/O load, some queues with inflight
I/O still have blkback thread running even though the corresponding vbd
device or guest is gone.
And this could cause some problems, for example, if the backend device type
is file, some loop devices and blkback thread always lingers there forever
after guest is destroyed, and this causes failure of umounting repositories
unless rebooting the dom0. So stop all threads properly and return -EBUSY
if any queue has inflight I/O.

Signed-off-by: Annie Li 
Reviewed-by: Herbert van den Bergh 
Reviewed-by: Bhavesh Davda 
Reviewed-by: Adnan Misherfi 
---
 drivers/block/xen-blkback/xenbus.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/block/xen-blkback/xenbus.c 
b/drivers/block/xen-blkback/xenbus.c
index 792da68..2adb859 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -244,6 +244,7 @@ static int xen_blkif_disconnect(struct xen_blkif *blkif)
 {
struct pending_req *req, *n;
unsigned int j, r;
+   bool busy = false;
 
for (r = 0; r < blkif->nr_rings; r++) {
struct xen_blkif_ring *ring = >rings[r];
@@ -261,8 +262,10 @@ static int xen_blkif_disconnect(struct xen_blkif *blkif)
 * don't have any discard_io or other_io requests. So, checking
 * for inflight IO is enough.
 */
-   if (atomic_read(>inflight) > 0)
-   return -EBUSY;
+   if (atomic_read(>inflight) > 0) {
+   busy = true;
+   continue;
+   }
 
if (ring->irq) {
unbind_from_irqhandler(ring->irq, ring);
@@ -300,6 +303,9 @@ static int xen_blkif_disconnect(struct xen_blkif *blkif)
WARN_ON(i != (XEN_BLKIF_REQS_PER_PAGE * blkif->nr_ring_pages));
ring->active = false;
}
+   if (busy)
+   return -EBUSY;
+
blkif->nr_ring_pages = 0;
/*
 * blkif->rings was allocated in connect_ring, so we should free it in
-- 
1.9.3

Re: [PATCH v2] swap: choose swap device according to numa node

[Andrew Morton]

On Wed, 16 Aug 2017 10:44:40 +0800 Aaron Lu  wrote:

> 
> If the system has more than one swap device and swap device has the node
> information, we can make use of this information to decide which swap
> device to use in get_swap_pages() to get better performance.
> 
> The current code uses a priority based list, swap_avail_list, to decide
> which swap device to use and if multiple swap devices share the same
> priority, they are used round robin.  This patch changes the previous
> single global swap_avail_list into a per-numa-node list, i.e.  for each
> numa node, it sees its own priority based list of available swap devices.
> Swap device's priority can be promoted on its matching node's
> swap_avail_list.
> 
> The current swap device's priority is set as: user can set a >=0 value, or
> the system will pick one starting from -1 then downwards.  The priority
> value in the swap_avail_list is the negated value of the swap device's due
> to plist being sorted from low to high.  The new policy doesn't change the
> semantics for priority >=0 cases, the previous starting from -1 then
> downwards now becomes starting from -2 then downwards and -1 is reserved
> as the promoted value.
> 
> ...
>
> +static int __init swapfile_init(void)
> +{
> + int nid;
> +
> + swap_avail_heads = kmalloc(nr_node_ids * sizeof(struct plist_head), 
> GFP_KERNEL);

I suppose we should use kmalloc_array(), as someone wrote it for us.

--- a/mm/swapfile.c~swap-choose-swap-device-according-to-numa-node-v2-fix
+++ a/mm/swapfile.c
@@ -3700,7 +3700,8 @@ static int __init swapfile_init(void)
 {
int nid;
 
-   swap_avail_heads = kmalloc(nr_node_ids * sizeof(struct plist_head), 
GFP_KERNEL);
+   swap_avail_heads = kmalloc_array(nr_node_ids, sizeof(struct plist_head),
+GFP_KERNEL);
if (!swap_avail_heads) {
pr_emerg("Not enough memory for swap heads, swap is 
disabled\n");
return -ENOMEM;

> + if (!swap_avail_heads) {
> + pr_emerg("Not enough memory for swap heads, swap is 
> disabled\n");

checkpatch tells us that the "Not enough memory" is a bit redundant, as
the memory allocator would have already warned.  So it's sufficient to
additionally say only "swap is disabled" here.  But it's hardly worth
changing.

> + return -ENOMEM;
> + }
> +
> + for_each_node(nid)
> + plist_head_init(_avail_heads[nid]);
> +
> + return 0;
> +}
> +subsys_initcall(swapfile_init);

Re: [PATCH v2] swap: choose swap device according to numa node

[Andrew Morton]

On Wed, 16 Aug 2017 10:44:40 +0800 Aaron Lu  wrote:

> 
> If the system has more than one swap device and swap device has the node
> information, we can make use of this information to decide which swap
> device to use in get_swap_pages() to get better performance.
> 
> The current code uses a priority based list, swap_avail_list, to decide
> which swap device to use and if multiple swap devices share the same
> priority, they are used round robin.  This patch changes the previous
> single global swap_avail_list into a per-numa-node list, i.e.  for each
> numa node, it sees its own priority based list of available swap devices.
> Swap device's priority can be promoted on its matching node's
> swap_avail_list.
> 
> The current swap device's priority is set as: user can set a >=0 value, or
> the system will pick one starting from -1 then downwards.  The priority
> value in the swap_avail_list is the negated value of the swap device's due
> to plist being sorted from low to high.  The new policy doesn't change the
> semantics for priority >=0 cases, the previous starting from -1 then
> downwards now becomes starting from -2 then downwards and -1 is reserved
> as the promoted value.
> 
> ...
>
> +static int __init swapfile_init(void)
> +{
> + int nid;
> +
> + swap_avail_heads = kmalloc(nr_node_ids * sizeof(struct plist_head), 
> GFP_KERNEL);

I suppose we should use kmalloc_array(), as someone wrote it for us.

--- a/mm/swapfile.c~swap-choose-swap-device-according-to-numa-node-v2-fix
+++ a/mm/swapfile.c
@@ -3700,7 +3700,8 @@ static int __init swapfile_init(void)
 {
int nid;
 
-   swap_avail_heads = kmalloc(nr_node_ids * sizeof(struct plist_head), 
GFP_KERNEL);
+   swap_avail_heads = kmalloc_array(nr_node_ids, sizeof(struct plist_head),
+GFP_KERNEL);
if (!swap_avail_heads) {
pr_emerg("Not enough memory for swap heads, swap is 
disabled\n");
return -ENOMEM;

> + if (!swap_avail_heads) {
> + pr_emerg("Not enough memory for swap heads, swap is 
> disabled\n");

checkpatch tells us that the "Not enough memory" is a bit redundant, as
the memory allocator would have already warned.  So it's sufficient to
additionally say only "swap is disabled" here.  But it's hardly worth
changing.

> + return -ENOMEM;
> + }
> +
> + for_each_node(nid)
> + plist_head_init(_avail_heads[nid]);
> +
> + return 0;
> +}
> +subsys_initcall(swapfile_init);

RE: [PATCH-resend] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

[Elliott, Robert (Persistent Memory)]

> -Original Message-
> From: Andrew Morton [mailto:a...@linux-foundation.org]
> Sent: Thursday, August 17, 2017 5:10 PM
> To: Luck, Tony 
> Cc: Borislav Petkov ; Dave Hansen ;
> Naoya Horiguchi ; Elliott, Robert (Persistent
> Memory) ; x...@kernel.org; linux...@kvack.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH-resend] mm/hwpoison: Clear PRESENT bit for kernel 1:1
> mappings of poison pages
> 
> On Wed, 16 Aug 2017 10:18:03 -0700 "Luck, Tony" 
> wrote:
> 
> > Speculative processor accesses may reference any memory that has a
> > valid page table entry.  While a speculative access won't generate
> > a machine check, it will log the error in a machine check bank. That
> > could cause escalation of a subsequent error since the overflow bit
> > will be then set in the machine check bank status register.
> >
> > Code has to be double-plus-tricky to avoid mentioning the 1:1 virtual
> > address of the page we want to map out otherwise we may trigger the
> > very problem we are trying to avoid.  We use a non-canonical address
> > that passes through the usual Linux table walking code to get to the
> > same "pte".
> >
> > Thanks to Dave Hansen for reviewing several iterations of this.
> 
> It's unclear (to lil ole me) what the end-user-visible effects of this
> are.
> 
> Could we please have a description of that?  So a) people can
> understand your decision to cc:stable and b) people whose kernels are
> misbehaving can use your description to decide whether your patch might
> fix the issue their users are reporting.

In general, the system is subject to halting due to uncorrectable
memory errors at addresses that software is not even accessing.  

The first error doesn't cause the crash, but if a second error happens
before the machine check handler services the first one, it'll find
the Overflow bit set and won't know what errors or how many errors
happened (e.g., it might have been problems in an instruction fetch,
and the instructions the CPU is slated to run are bogus).  Halting is 
the only safe thing to do.

For persistent memory, the BIOS reports known-bad addresses in the
ACPI ARS (address range scrub) table.  They are likely to keep
reappearing every boot since it is persistent memory, so you can't
just reboot and hope they go away.  Software is supposed to avoid
reading those addresses until it fixes them (e.g., writes new data
to those locations).  Even if it follows this rule, the system can
still crash due to speculative reads (e.g., prefetches) touching
those addresses.

Tony's patch marks those addresses in the page tables so the CPU
won't speculatively try to read them.

---
Robert Elliott, HPE Persistent Memory

RE: [PATCH-resend] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

[Elliott, Robert (Persistent Memory)]

> -Original Message-
> From: Andrew Morton [mailto:a...@linux-foundation.org]
> Sent: Thursday, August 17, 2017 5:10 PM
> To: Luck, Tony 
> Cc: Borislav Petkov ; Dave Hansen ;
> Naoya Horiguchi ; Elliott, Robert (Persistent
> Memory) ; x...@kernel.org; linux...@kvack.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH-resend] mm/hwpoison: Clear PRESENT bit for kernel 1:1
> mappings of poison pages
> 
> On Wed, 16 Aug 2017 10:18:03 -0700 "Luck, Tony" 
> wrote:
> 
> > Speculative processor accesses may reference any memory that has a
> > valid page table entry.  While a speculative access won't generate
> > a machine check, it will log the error in a machine check bank. That
> > could cause escalation of a subsequent error since the overflow bit
> > will be then set in the machine check bank status register.
> >
> > Code has to be double-plus-tricky to avoid mentioning the 1:1 virtual
> > address of the page we want to map out otherwise we may trigger the
> > very problem we are trying to avoid.  We use a non-canonical address
> > that passes through the usual Linux table walking code to get to the
> > same "pte".
> >
> > Thanks to Dave Hansen for reviewing several iterations of this.
> 
> It's unclear (to lil ole me) what the end-user-visible effects of this
> are.
> 
> Could we please have a description of that?  So a) people can
> understand your decision to cc:stable and b) people whose kernels are
> misbehaving can use your description to decide whether your patch might
> fix the issue their users are reporting.

In general, the system is subject to halting due to uncorrectable
memory errors at addresses that software is not even accessing.  

The first error doesn't cause the crash, but if a second error happens
before the machine check handler services the first one, it'll find
the Overflow bit set and won't know what errors or how many errors
happened (e.g., it might have been problems in an instruction fetch,
and the instructions the CPU is slated to run are bogus).  Halting is 
the only safe thing to do.

For persistent memory, the BIOS reports known-bad addresses in the
ACPI ARS (address range scrub) table.  They are likely to keep
reappearing every boot since it is persistent memory, so you can't
just reboot and hope they go away.  Software is supposed to avoid
reading those addresses until it fixes them (e.g., writes new data
to those locations).  Even if it follows this rule, the system can
still crash due to speculative reads (e.g., prefetches) touching
those addresses.

Tony's patch marks those addresses in the page tables so the CPU
won't speculatively try to read them.

---
Robert Elliott, HPE Persistent Memory

Beloved

[Mrs Susan Patrick]

I am Mrs Susan Patrick i have a proposal donation if you are interested get 
back to me via email: susanpatrick...@gmail.com

Thanks 
Hope to hear from you soon
Mrs Susan Patrick

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com

Beloved

[Mrs Susan Patrick]

I am Mrs Susan Patrick i have a proposal donation if you are interested get 
back to me via email: susanpatrick...@gmail.com

Thanks 
Hope to hear from you soon
Mrs Susan Patrick

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com

Re: [Nouveau] [PATCH][V2] drm/nouveau: perform null check on msto[i] rathern than msto

[Ben Skeggs]

On 08/18/2017 08:20 AM, Ben Skeggs wrote:
> On 08/18/2017 08:16 AM, Colin Ian King wrote:
>> On 17/08/17 23:07, Ilia Mirkin wrote:
>>> On Thu, Aug 17, 2017 at 6:03 PM, Colin King  
>>> wrote:
 From: Colin Ian King 

 The null check on the array msto is incorrect since msto is never
 null. The null check should be instead on msto[i] since this is
 being dereferenced in the call to drm_mode_connector_attach_encoder.

 Thanks to Emil Velikov for pointing out the mistake in my original
 fix and for suggesting the correct fix.

 Detected by CoverityScan, CID#1375915 ("Array compared against 0")

 Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2 
 multi-stream")
 Signed-off-by: Colin Ian King 
 ---
  drivers/gpu/drm/nouveau/nv50_display.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
 b/drivers/gpu/drm/nouveau/nv50_display.c
 index f7b4326a4641..ed444ecd9e85 100644
 --- a/drivers/gpu/drm/nouveau/nv50_display.c
 +++ b/drivers/gpu/drm/nouveau/nv50_display.c
 @@ -3141,7 +3141,7 @@ nv50_mstc_new(struct nv50_mstm *mstm, struct 
 drm_dp_mst_port *port,
 mstc->connector.funcs->reset(>connector);
 nouveau_conn_attach_properties(>connector);

 -   for (i = 0; i < ARRAY_SIZE(mstm->msto) && mstm->msto; i++)
 +   for (i = 0; i < ARRAY_SIZE(mstm->msto) && mstm->msto[i]; i++)
>>>
>>> Ben will have to rule on which way is correct, but another
>>> interpretation is that it should be
>>>
>>> for (...; i < ARRAY_SIZE; i++)
>>>   if (mstm->msto[i])
>>> do_stuff()
>>
>> Yes, I suspect that is a better generic solution top cope with potential
>> "holes".
>>>
>>> I haven't the faintest clue whether the msto array can have "holes" or not.
>>
>> Indeed. Let's see what Ben says.
> No, there can't be holes here.  I believe the V2 patch to be correct.
Also, I've taken the patch in my tree, and will get it to Dave at some
point.

Thank you!
Ben.

> 
> Ben.
>>
>>
>>>
 drm_mode_connector_attach_encoder(>connector, 
 >msto[i]->encoder);

 drm_object_attach_property(>connector.base, 
 dev->mode_config.path_property, 0);
 --
 2.11.0

>>> --
>>> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" 
>>> in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
>> ___
>> Nouveau mailing list
>> nouv...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/nouveau
>>
> 



signature.asc
Description: OpenPGP digital signature

Re: [Nouveau] [PATCH][V2] drm/nouveau: perform null check on msto[i] rathern than msto

[Ben Skeggs]

On 08/18/2017 08:20 AM, Ben Skeggs wrote:
> On 08/18/2017 08:16 AM, Colin Ian King wrote:
>> On 17/08/17 23:07, Ilia Mirkin wrote:
>>> On Thu, Aug 17, 2017 at 6:03 PM, Colin King  
>>> wrote:
 From: Colin Ian King 

 The null check on the array msto is incorrect since msto is never
 null. The null check should be instead on msto[i] since this is
 being dereferenced in the call to drm_mode_connector_attach_encoder.

 Thanks to Emil Velikov for pointing out the mistake in my original
 fix and for suggesting the correct fix.

 Detected by CoverityScan, CID#1375915 ("Array compared against 0")

 Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2 
 multi-stream")
 Signed-off-by: Colin Ian King 
 ---
  drivers/gpu/drm/nouveau/nv50_display.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
 b/drivers/gpu/drm/nouveau/nv50_display.c
 index f7b4326a4641..ed444ecd9e85 100644
 --- a/drivers/gpu/drm/nouveau/nv50_display.c
 +++ b/drivers/gpu/drm/nouveau/nv50_display.c
 @@ -3141,7 +3141,7 @@ nv50_mstc_new(struct nv50_mstm *mstm, struct 
 drm_dp_mst_port *port,
 mstc->connector.funcs->reset(>connector);
 nouveau_conn_attach_properties(>connector);

 -   for (i = 0; i < ARRAY_SIZE(mstm->msto) && mstm->msto; i++)
 +   for (i = 0; i < ARRAY_SIZE(mstm->msto) && mstm->msto[i]; i++)
>>>
>>> Ben will have to rule on which way is correct, but another
>>> interpretation is that it should be
>>>
>>> for (...; i < ARRAY_SIZE; i++)
>>>   if (mstm->msto[i])
>>> do_stuff()
>>
>> Yes, I suspect that is a better generic solution top cope with potential
>> "holes".
>>>
>>> I haven't the faintest clue whether the msto array can have "holes" or not.
>>
>> Indeed. Let's see what Ben says.
> No, there can't be holes here.  I believe the V2 patch to be correct.
Also, I've taken the patch in my tree, and will get it to Dave at some
point.

Thank you!
Ben.

> 
> Ben.
>>
>>
>>>
 drm_mode_connector_attach_encoder(>connector, 
 >msto[i]->encoder);

 drm_object_attach_property(>connector.base, 
 dev->mode_config.path_property, 0);
 --
 2.11.0

>>> --
>>> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" 
>>> in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
>> ___
>> Nouveau mailing list
>> nouv...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/nouveau
>>
> 



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v4 1/5] iio: srf08: add device tree binding for srf02 and srf10

[Rob Herring]

On Fri, Aug 18, 2017 at 12:08:51AM +0200, Andreas Klinger wrote:
> add trivial device tree binding "devantech,srf02" and "devantech,srf10"
> 
> Signed-off-by: Andreas Klinger 
> ---
>  Documentation/devicetree/bindings/trivial-devices.txt | 2 ++
>  1 file changed, 2 insertions(+)

I applied just this patch.

Rob

Re: [PATCH v4 1/5] iio: srf08: add device tree binding for srf02 and srf10

[Rob Herring]

On Fri, Aug 18, 2017 at 12:08:51AM +0200, Andreas Klinger wrote:
> add trivial device tree binding "devantech,srf02" and "devantech,srf10"
> 
> Signed-off-by: Andreas Klinger 
> ---
>  Documentation/devicetree/bindings/trivial-devices.txt | 2 ++
>  1 file changed, 2 insertions(+)

I applied just this patch.

Rob

Re: [RFT PATCH] tpm: ibmvtpm: simplify crq initialization and document crq format

[msuchanek]

ping?

On Fri, 24 Feb 2017 20:35:16 +0100
Michal Suchanek  wrote:

> The crq is passed in registers and is the same on BE and LE hosts.
> However, current implementation allocates a structure on-stack to
> represent the crq, initializes the members swapping them to BE, and
> loads the structure swapping it from BE. This is pointless and causes
> GCC warnings about ununitialized members. Get rid of the structure and
> the warnings.
> 
> Signed-off-by: Michal Suchanek 
> Reviewed-by: Jarkko Sakkinen 
> ---
> v2
> 
> fix typos and spelling in comments
> ---
>  drivers/char/tpm/tpm_ibmvtpm.c | 96
> ++ 1 file changed, 60
> insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm_ibmvtpm.c
> b/drivers/char/tpm/tpm_ibmvtpm.c index 1b9d61ffe991..89027339d55f
> 100644 --- a/drivers/char/tpm/tpm_ibmvtpm.c
> +++ b/drivers/char/tpm/tpm_ibmvtpm.c
> @@ -39,19 +39,63 @@ static struct vio_device_id
> tpm_ibmvtpm_device_table[] = { MODULE_DEVICE_TABLE(vio,
> tpm_ibmvtpm_device_table); 
>  /**
> + *
> + * ibmvtpm_send_crq_word - Send a CRQ request
> + * @vdev:vio device struct
> + * @w1:  pre-constructed first word of tpm crq (second
> word is reserved)
> + *
> + * Return:
> + *   0 - Success
> + *   Non-zero - Failure
> + */
> +static int ibmvtpm_send_crq_word(struct vio_dev *vdev, u64 w1)
> +{
> + return plpar_hcall_norets(H_SEND_CRQ, vdev->unit_address,
> w1, 0); +}
> +
> +/**
> + *
>   * ibmvtpm_send_crq - Send a CRQ request
>   *
>   * @vdev:vio device struct
> - * @w1:  first word
> - * @w2:  second word
> + * @valid:   Valid field
> + * @msg: Type field
> + * @len: Length field
> + * @data:Data field
> + *
> + * The ibmvtpm crq is defined as follows:
> + *
> + * Byte  |   0   |   1   |   2   |   3   |   4   |   5   |   6   |
> 7
> + *
> ---
> + * Word0 | Valid | Type  | Length|  Data
> + *
> ---
> + * Word1 |Reserved
> + *
> ---
> + *
> + * Which matches the following structure (on bigendian host):
> + *
> + * struct ibmvtpm_crq {
> + * u8 valid;
> + * u8 msg;
> + * __be16 len;
> + * __be32 data;
> + * __be64 reserved;
> + * } __attribute__((packed, aligned(8)));
> + *
> + * However, the value is passed in a register so just compute the
> numeric value
> + * to load into the register avoiding byteswap altogether. Endian
> only affects
> + * memory loads and stores - registers are internally represented
> the same. *
>   * Return:
> - *   0 -Sucess
> + *   0 (H_SUCCESS) - Success
>   *   Non-zero - Failure
>   */
> -static int ibmvtpm_send_crq(struct vio_dev *vdev, u64 w1, u64 w2)
> +static int ibmvtpm_send_crq(struct vio_dev *vdev,
> + u8 valid, u8 msg, u16 len, u32 data)
>  {
> - return plpar_hcall_norets(H_SEND_CRQ, vdev->unit_address,
> w1, w2);
> + u64 w1 = ((u64)valid << 56) | ((u64)msg << 48) | ((u64)len
> << 32) |
> + (u64)data;
> + return ibmvtpm_send_crq_word(vdev, w1);
>  }
>  
>  /**
> @@ -109,8 +153,6 @@ static int tpm_ibmvtpm_recv(struct tpm_chip
> *chip, u8 *buf, size_t count) static int tpm_ibmvtpm_send(struct
> tpm_chip *chip, u8 *buf, size_t count) {
>   struct ibmvtpm_dev *ibmvtpm = dev_get_drvdata(>dev);
> - struct ibmvtpm_crq crq;
> - __be64 *word = (__be64 *)
>   int rc, sig;
>  
>   if (!ibmvtpm->rtce_buf) {
> @@ -137,10 +179,6 @@ static int tpm_ibmvtpm_send(struct tpm_chip
> *chip, u8 *buf, size_t count) spin_lock(>rtce_lock);
>   ibmvtpm->res_len = 0;
>   memcpy((void *)ibmvtpm->rtce_buf, (void *)buf, count);
> - crq.valid = (u8)IBMVTPM_VALID_CMD;
> - crq.msg = (u8)VTPM_TPM_COMMAND;
> - crq.len = cpu_to_be16(count);
> - crq.data = cpu_to_be32(ibmvtpm->rtce_dma_handle);
>  
>   /*
>* set the processing flag before the Hcall, since we may
> get the @@ -148,8 +186,9 @@ static int tpm_ibmvtpm_send(struct
> tpm_chip *chip, u8 *buf, size_t count) */
>   ibmvtpm->tpm_processing_cmd = true;
>  
> - rc = ibmvtpm_send_crq(ibmvtpm->vdev, be64_to_cpu(word[0]),
> -   be64_to_cpu(word[1]));
> + rc = ibmvtpm_send_crq(ibmvtpm->vdev,
> + IBMVTPM_VALID_CMD, VTPM_TPM_COMMAND,
> + count, ibmvtpm->rtce_dma_handle);
>   if (rc != H_SUCCESS) {
>   dev_err(ibmvtpm->dev, "tpm_ibmvtpm_send failed
> rc=%d\n", rc); rc = 0;
> @@ -182,15 +221,10 @@ static u8 tpm_ibmvtpm_status(struct tpm_chip
> *chip) */
>  static int ibmvtpm_crq_get_rtce_size(struct ibmvtpm_dev *ibmvtpm)
>  {
> - struct ibmvtpm_crq crq;
> - u64 *buf = (u64 *) 
>   int rc;
>  
> - crq.valid = 

Re: [RFT PATCH] tpm: ibmvtpm: simplify crq initialization and document crq format

[msuchanek]

ping?

On Fri, 24 Feb 2017 20:35:16 +0100
Michal Suchanek  wrote:

> The crq is passed in registers and is the same on BE and LE hosts.
> However, current implementation allocates a structure on-stack to
> represent the crq, initializes the members swapping them to BE, and
> loads the structure swapping it from BE. This is pointless and causes
> GCC warnings about ununitialized members. Get rid of the structure and
> the warnings.
> 
> Signed-off-by: Michal Suchanek 
> Reviewed-by: Jarkko Sakkinen 
> ---
> v2
> 
> fix typos and spelling in comments
> ---
>  drivers/char/tpm/tpm_ibmvtpm.c | 96
> ++ 1 file changed, 60
> insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm_ibmvtpm.c
> b/drivers/char/tpm/tpm_ibmvtpm.c index 1b9d61ffe991..89027339d55f
> 100644 --- a/drivers/char/tpm/tpm_ibmvtpm.c
> +++ b/drivers/char/tpm/tpm_ibmvtpm.c
> @@ -39,19 +39,63 @@ static struct vio_device_id
> tpm_ibmvtpm_device_table[] = { MODULE_DEVICE_TABLE(vio,
> tpm_ibmvtpm_device_table); 
>  /**
> + *
> + * ibmvtpm_send_crq_word - Send a CRQ request
> + * @vdev:vio device struct
> + * @w1:  pre-constructed first word of tpm crq (second
> word is reserved)
> + *
> + * Return:
> + *   0 - Success
> + *   Non-zero - Failure
> + */
> +static int ibmvtpm_send_crq_word(struct vio_dev *vdev, u64 w1)
> +{
> + return plpar_hcall_norets(H_SEND_CRQ, vdev->unit_address,
> w1, 0); +}
> +
> +/**
> + *
>   * ibmvtpm_send_crq - Send a CRQ request
>   *
>   * @vdev:vio device struct
> - * @w1:  first word
> - * @w2:  second word
> + * @valid:   Valid field
> + * @msg: Type field
> + * @len: Length field
> + * @data:Data field
> + *
> + * The ibmvtpm crq is defined as follows:
> + *
> + * Byte  |   0   |   1   |   2   |   3   |   4   |   5   |   6   |
> 7
> + *
> ---
> + * Word0 | Valid | Type  | Length|  Data
> + *
> ---
> + * Word1 |Reserved
> + *
> ---
> + *
> + * Which matches the following structure (on bigendian host):
> + *
> + * struct ibmvtpm_crq {
> + * u8 valid;
> + * u8 msg;
> + * __be16 len;
> + * __be32 data;
> + * __be64 reserved;
> + * } __attribute__((packed, aligned(8)));
> + *
> + * However, the value is passed in a register so just compute the
> numeric value
> + * to load into the register avoiding byteswap altogether. Endian
> only affects
> + * memory loads and stores - registers are internally represented
> the same. *
>   * Return:
> - *   0 -Sucess
> + *   0 (H_SUCCESS) - Success
>   *   Non-zero - Failure
>   */
> -static int ibmvtpm_send_crq(struct vio_dev *vdev, u64 w1, u64 w2)
> +static int ibmvtpm_send_crq(struct vio_dev *vdev,
> + u8 valid, u8 msg, u16 len, u32 data)
>  {
> - return plpar_hcall_norets(H_SEND_CRQ, vdev->unit_address,
> w1, w2);
> + u64 w1 = ((u64)valid << 56) | ((u64)msg << 48) | ((u64)len
> << 32) |
> + (u64)data;
> + return ibmvtpm_send_crq_word(vdev, w1);
>  }
>  
>  /**
> @@ -109,8 +153,6 @@ static int tpm_ibmvtpm_recv(struct tpm_chip
> *chip, u8 *buf, size_t count) static int tpm_ibmvtpm_send(struct
> tpm_chip *chip, u8 *buf, size_t count) {
>   struct ibmvtpm_dev *ibmvtpm = dev_get_drvdata(>dev);
> - struct ibmvtpm_crq crq;
> - __be64 *word = (__be64 *)
>   int rc, sig;
>  
>   if (!ibmvtpm->rtce_buf) {
> @@ -137,10 +179,6 @@ static int tpm_ibmvtpm_send(struct tpm_chip
> *chip, u8 *buf, size_t count) spin_lock(>rtce_lock);
>   ibmvtpm->res_len = 0;
>   memcpy((void *)ibmvtpm->rtce_buf, (void *)buf, count);
> - crq.valid = (u8)IBMVTPM_VALID_CMD;
> - crq.msg = (u8)VTPM_TPM_COMMAND;
> - crq.len = cpu_to_be16(count);
> - crq.data = cpu_to_be32(ibmvtpm->rtce_dma_handle);
>  
>   /*
>* set the processing flag before the Hcall, since we may
> get the @@ -148,8 +186,9 @@ static int tpm_ibmvtpm_send(struct
> tpm_chip *chip, u8 *buf, size_t count) */
>   ibmvtpm->tpm_processing_cmd = true;
>  
> - rc = ibmvtpm_send_crq(ibmvtpm->vdev, be64_to_cpu(word[0]),
> -   be64_to_cpu(word[1]));
> + rc = ibmvtpm_send_crq(ibmvtpm->vdev,
> + IBMVTPM_VALID_CMD, VTPM_TPM_COMMAND,
> + count, ibmvtpm->rtce_dma_handle);
>   if (rc != H_SUCCESS) {
>   dev_err(ibmvtpm->dev, "tpm_ibmvtpm_send failed
> rc=%d\n", rc); rc = 0;
> @@ -182,15 +221,10 @@ static u8 tpm_ibmvtpm_status(struct tpm_chip
> *chip) */
>  static int ibmvtpm_crq_get_rtce_size(struct ibmvtpm_dev *ibmvtpm)
>  {
> - struct ibmvtpm_crq crq;
> - u64 *buf = (u64 *) 
>   int rc;
>  
> - crq.valid = (u8)IBMVTPM_VALID_CMD;
> - crq.msg = (u8)VTPM_GET_RTCE_BUFFER_SIZE;
> -
> -

Re: [PATCH v3 1/2] remoteproc: dt: Provide bindings for iMX6SX/7D Remote Processor Controller driver

[Rob Herring]

On Thu, Aug 17, 2017 at 09:15:25AM +0200, Oleksij Rempel wrote:
> Signed-off-by: Oleksij Rempel 
> ---
>  .../devicetree/bindings/remoteproc/imx-rproc.txt   | 33 
> ++
>  1 file changed, 33 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/remoteproc/imx-rproc.txt

Acked-by: Rob Herring 

Re: [PATCH v3 1/2] remoteproc: dt: Provide bindings for iMX6SX/7D Remote Processor Controller driver

[Rob Herring]

On Thu, Aug 17, 2017 at 09:15:25AM +0200, Oleksij Rempel wrote:
> Signed-off-by: Oleksij Rempel 
> ---
>  .../devicetree/bindings/remoteproc/imx-rproc.txt   | 33 
> ++
>  1 file changed, 33 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/remoteproc/imx-rproc.txt

Acked-by: Rob Herring 

Re: [Nouveau] [PATCH][V2] drm/nouveau: perform null check on msto[i] rathern than msto

[Ben Skeggs]

On 08/18/2017 08:16 AM, Colin Ian King wrote:
> On 17/08/17 23:07, Ilia Mirkin wrote:
>> On Thu, Aug 17, 2017 at 6:03 PM, Colin King  wrote:
>>> From: Colin Ian King 
>>>
>>> The null check on the array msto is incorrect since msto is never
>>> null. The null check should be instead on msto[i] since this is
>>> being dereferenced in the call to drm_mode_connector_attach_encoder.
>>>
>>> Thanks to Emil Velikov for pointing out the mistake in my original
>>> fix and for suggesting the correct fix.
>>>
>>> Detected by CoverityScan, CID#1375915 ("Array compared against 0")
>>>
>>> Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2 
>>> multi-stream")
>>> Signed-off-by: Colin Ian King 
>>> ---
>>>  drivers/gpu/drm/nouveau/nv50_display.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
>>> b/drivers/gpu/drm/nouveau/nv50_display.c
>>> index f7b4326a4641..ed444ecd9e85 100644
>>> --- a/drivers/gpu/drm/nouveau/nv50_display.c
>>> +++ b/drivers/gpu/drm/nouveau/nv50_display.c
>>> @@ -3141,7 +3141,7 @@ nv50_mstc_new(struct nv50_mstm *mstm, struct 
>>> drm_dp_mst_port *port,
>>> mstc->connector.funcs->reset(>connector);
>>> nouveau_conn_attach_properties(>connector);
>>>
>>> -   for (i = 0; i < ARRAY_SIZE(mstm->msto) && mstm->msto; i++)
>>> +   for (i = 0; i < ARRAY_SIZE(mstm->msto) && mstm->msto[i]; i++)
>>
>> Ben will have to rule on which way is correct, but another
>> interpretation is that it should be
>>
>> for (...; i < ARRAY_SIZE; i++)
>>   if (mstm->msto[i])
>> do_stuff()
> 
> Yes, I suspect that is a better generic solution top cope with potential
> "holes".
>>
>> I haven't the faintest clue whether the msto array can have "holes" or not.
> 
> Indeed. Let's see what Ben says.
No, there can't be holes here.  I believe the V2 patch to be correct.

Ben.
> 
> 
>>
>>> drm_mode_connector_attach_encoder(>connector, 
>>> >msto[i]->encoder);
>>>
>>> drm_object_attach_property(>connector.base, 
>>> dev->mode_config.path_property, 0);
>>> --
>>> 2.11.0
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
> 



signature.asc
Description: OpenPGP digital signature

Re: [Nouveau] [PATCH][V2] drm/nouveau: perform null check on msto[i] rathern than msto

[Ben Skeggs]

On 08/18/2017 08:16 AM, Colin Ian King wrote:
> On 17/08/17 23:07, Ilia Mirkin wrote:
>> On Thu, Aug 17, 2017 at 6:03 PM, Colin King  wrote:
>>> From: Colin Ian King 
>>>
>>> The null check on the array msto is incorrect since msto is never
>>> null. The null check should be instead on msto[i] since this is
>>> being dereferenced in the call to drm_mode_connector_attach_encoder.
>>>
>>> Thanks to Emil Velikov for pointing out the mistake in my original
>>> fix and for suggesting the correct fix.
>>>
>>> Detected by CoverityScan, CID#1375915 ("Array compared against 0")
>>>
>>> Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2 
>>> multi-stream")
>>> Signed-off-by: Colin Ian King 
>>> ---
>>>  drivers/gpu/drm/nouveau/nv50_display.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
>>> b/drivers/gpu/drm/nouveau/nv50_display.c
>>> index f7b4326a4641..ed444ecd9e85 100644
>>> --- a/drivers/gpu/drm/nouveau/nv50_display.c
>>> +++ b/drivers/gpu/drm/nouveau/nv50_display.c
>>> @@ -3141,7 +3141,7 @@ nv50_mstc_new(struct nv50_mstm *mstm, struct 
>>> drm_dp_mst_port *port,
>>> mstc->connector.funcs->reset(>connector);
>>> nouveau_conn_attach_properties(>connector);
>>>
>>> -   for (i = 0; i < ARRAY_SIZE(mstm->msto) && mstm->msto; i++)
>>> +   for (i = 0; i < ARRAY_SIZE(mstm->msto) && mstm->msto[i]; i++)
>>
>> Ben will have to rule on which way is correct, but another
>> interpretation is that it should be
>>
>> for (...; i < ARRAY_SIZE; i++)
>>   if (mstm->msto[i])
>> do_stuff()
> 
> Yes, I suspect that is a better generic solution top cope with potential
> "holes".
>>
>> I haven't the faintest clue whether the msto array can have "holes" or not.
> 
> Indeed. Let's see what Ben says.
No, there can't be holes here.  I believe the V2 patch to be correct.

Ben.
> 
> 
>>
>>> drm_mode_connector_attach_encoder(>connector, 
>>> >msto[i]->encoder);
>>>
>>> drm_object_attach_property(>connector.base, 
>>> dev->mode_config.path_property, 0);
>>> --
>>> 2.11.0
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
> 



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v3 9/9] dt-bindings: ASoC: rockchip: Update description of rockchip,codec

[Rob Herring]

On Thu, Aug 17, 2017 at 12:44:17PM +0800, Jeffy Chen wrote:
> Update description for newly added optional audio codecs.
> 
> Signed-off-by: Jeffy Chen 
> ---
> 
> Changes in v3: None
> Changes in v2: None
> 
>  Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Rob Herring 

Re: [PATCH v3 9/9] dt-bindings: ASoC: rockchip: Update description of rockchip,codec

[Rob Herring]

On Thu, Aug 17, 2017 at 12:44:17PM +0800, Jeffy Chen wrote:
> Update description for newly added optional audio codecs.
> 
> Signed-off-by: Jeffy Chen 
> ---
> 
> Changes in v3: None
> Changes in v2: None
> 
>  Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Rob Herring 

[PATCH] ALSA: usb-audio: don't retry snd_usb_ctl_msg after timeout

[Stephen Barber]

A few calls to snd_usb_ctl_msg wrap the function in a retry loop. In
the worst case, the timeout for snd_usb_ctl_msg is 5 seconds, which when
retried 10 times (for example, if a device is removed) could cause a
probe to hang for ~50 seconds.

Example stack trace from 3.14 which triggered a hung task timeout:
Call Trace:
 [] ? inet6_set_link_af.part.35+0x12/0x12
 [] schedule+0x6e/0x70
 [] schedule_timeout+0xfc/0x13c
 [] ? rcu_read_unlock_sched_notrace+0x17/0x17
 [] __wait_for_common+0x153/0x190
 [] ? __wait_for_common+0x153/0x190
 [] ? wake_up_state+0x12/0x12
 [] wait_for_completion_timeout+0x1d/0x1f
 [] usb_start_wait_urb+0x93/0xf1
 [] usb_control_msg+0xe1/0x11d
 [] snd_usb_ctl_msg+0x9c/0xf1 [snd_usb_audio]
 [] snd_usb_mixer_set_ctl_value+0x124/0xab1 [snd_usb_audio]
 [] snd_usb_mixer_set_ctl_value+0x1c3/0xab1 [snd_usb_audio]
 [] snd_usb_mixer_set_ctl_value+0x521/0xab1 [snd_usb_audio]
 [] snd_usb_mixer_add_control+0x36a/0x1264 [snd_usb_audio]
 [] snd_usb_mixer_add_control+0x805/0x1264 [snd_usb_audio]
 [] ? usb_free_urb+0x1a/0x1c
 [] snd_usb_mixer_add_control+0x11d9/0x1264 [snd_usb_audio]
 [] snd_usb_create_mixer+0xbc/0x286 [snd_usb_audio]
 [] 0xc02cac17
 [] usb_probe_interface+0x17c/0x21c
 [] driver_probe_device+0xae/0x1fa
 [] __device_attach_driver+0x5f/0x66
 [] ? driver_probe_device+0x1fa/0x1fa
 [] bus_for_each_drv+0x87/0xaa
 [] __device_attach+0x9d/0x101
 [] device_initial_probe+0x13/0x15
 [] bus_probe_device+0x33/0x96
 [] device_add+0x328/0x547
 [] usb_set_configuration+0x624/0x674
 [] generic_probe+0x45/0x77
 [] usb_probe_device+0x2d/0x40
 [] driver_probe_device+0xae/0x1fa
 [] __device_attach_driver+0x5f/0x66
 [] ? driver_probe_device+0x1fa/0x1fa
 [] bus_for_each_drv+0x87/0xaa
 [] __device_attach+0x9d/0x101
 [] device_initial_probe+0x13/0x15
 [] bus_probe_device+0x33/0x96
 [] device_add+0x328/0x547
 [] ? add_device_randomness+0x111/0x130
 [] usb_new_device+0x2a2/0x3c0
 [] hub_thread+0xa3d/0xeed
 [] ? __schedule+0x41e/0x5ac
 [] ? finish_wait+0x62/0x62
 [] ? usb_reset_device+0x16a/0x16a
 [] kthread+0x108/0x110
 [] ? __kthread_parkme+0x67/0x67
 [] ret_from_fork+0x7c/0xb0
 [] ? __kthread_parkme+0x67/0x67

Signed-off-by: Stephen Barber 
---
 sound/usb/mixer.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c
index 082736c539bc..253fc946db29 100644
--- a/sound/usb/mixer.c
+++ b/sound/usb/mixer.c
@@ -318,12 +318,15 @@ static int get_ctl_value_v1(struct usb_mixer_elem_info 
*cval, int request,
 
while (timeout-- > 0) {
idx = snd_usb_ctrl_intf(chip) | (cval->head.id << 8);
-   if (snd_usb_ctl_msg(chip->dev, usb_rcvctrlpipe(chip->dev, 0), 
request,
-   USB_RECIP_INTERFACE | USB_TYPE_CLASS | 
USB_DIR_IN,
-   validx, idx, buf, val_len) >= val_len) {
+   err = snd_usb_ctl_msg(chip->dev, usb_rcvctrlpipe(chip->dev, 0), 
request,
+ USB_RECIP_INTERFACE | USB_TYPE_CLASS | 
USB_DIR_IN,
+ validx, idx, buf, val_len);
+   if (err >= val_len) {
*value_ret = convert_signed_value(cval, 
snd_usb_combine_bytes(buf, val_len));
err = 0;
goto out;
+   } else if (err == -ETIMEDOUT) {
+   goto out;
}
}
usb_audio_dbg(chip,
@@ -483,12 +486,15 @@ int snd_usb_mixer_set_ctl_value(struct 
usb_mixer_elem_info *cval,
 
while (timeout-- > 0) {
idx = snd_usb_ctrl_intf(chip) | (cval->head.id << 8);
-   if (snd_usb_ctl_msg(chip->dev,
-   usb_sndctrlpipe(chip->dev, 0), request,
-   USB_RECIP_INTERFACE | USB_TYPE_CLASS | 
USB_DIR_OUT,
-   validx, idx, buf, val_len) >= 0) {
+   err = snd_usb_ctl_msg(chip->dev,
+ usb_sndctrlpipe(chip->dev, 0), request,
+ USB_RECIP_INTERFACE | USB_TYPE_CLASS | 
USB_DIR_OUT,
+ validx, idx, buf, val_len);
+   if (err >= 0) {
err = 0;
goto out;
+   } else if (err == -ETIMEDOUT) {
+   goto out;
}
}
usb_audio_dbg(chip, "cannot set ctl value: req = %#x, wValue = %#x, 
wIndex = %#x, type = %d, data = %#x/%#x\n",
-- 
2.14.1.480.gb18f417b89-goog

[PATCH] ALSA: usb-audio: don't retry snd_usb_ctl_msg after timeout

[Stephen Barber]

A few calls to snd_usb_ctl_msg wrap the function in a retry loop. In
the worst case, the timeout for snd_usb_ctl_msg is 5 seconds, which when
retried 10 times (for example, if a device is removed) could cause a
probe to hang for ~50 seconds.

Example stack trace from 3.14 which triggered a hung task timeout:
Call Trace:
 [] ? inet6_set_link_af.part.35+0x12/0x12
 [] schedule+0x6e/0x70
 [] schedule_timeout+0xfc/0x13c
 [] ? rcu_read_unlock_sched_notrace+0x17/0x17
 [] __wait_for_common+0x153/0x190
 [] ? __wait_for_common+0x153/0x190
 [] ? wake_up_state+0x12/0x12
 [] wait_for_completion_timeout+0x1d/0x1f
 [] usb_start_wait_urb+0x93/0xf1
 [] usb_control_msg+0xe1/0x11d
 [] snd_usb_ctl_msg+0x9c/0xf1 [snd_usb_audio]
 [] snd_usb_mixer_set_ctl_value+0x124/0xab1 [snd_usb_audio]
 [] snd_usb_mixer_set_ctl_value+0x1c3/0xab1 [snd_usb_audio]
 [] snd_usb_mixer_set_ctl_value+0x521/0xab1 [snd_usb_audio]
 [] snd_usb_mixer_add_control+0x36a/0x1264 [snd_usb_audio]
 [] snd_usb_mixer_add_control+0x805/0x1264 [snd_usb_audio]
 [] ? usb_free_urb+0x1a/0x1c
 [] snd_usb_mixer_add_control+0x11d9/0x1264 [snd_usb_audio]
 [] snd_usb_create_mixer+0xbc/0x286 [snd_usb_audio]
 [] 0xc02cac17
 [] usb_probe_interface+0x17c/0x21c
 [] driver_probe_device+0xae/0x1fa
 [] __device_attach_driver+0x5f/0x66
 [] ? driver_probe_device+0x1fa/0x1fa
 [] bus_for_each_drv+0x87/0xaa
 [] __device_attach+0x9d/0x101
 [] device_initial_probe+0x13/0x15
 [] bus_probe_device+0x33/0x96
 [] device_add+0x328/0x547
 [] usb_set_configuration+0x624/0x674
 [] generic_probe+0x45/0x77
 [] usb_probe_device+0x2d/0x40
 [] driver_probe_device+0xae/0x1fa
 [] __device_attach_driver+0x5f/0x66
 [] ? driver_probe_device+0x1fa/0x1fa
 [] bus_for_each_drv+0x87/0xaa
 [] __device_attach+0x9d/0x101
 [] device_initial_probe+0x13/0x15
 [] bus_probe_device+0x33/0x96
 [] device_add+0x328/0x547
 [] ? add_device_randomness+0x111/0x130
 [] usb_new_device+0x2a2/0x3c0
 [] hub_thread+0xa3d/0xeed
 [] ? __schedule+0x41e/0x5ac
 [] ? finish_wait+0x62/0x62
 [] ? usb_reset_device+0x16a/0x16a
 [] kthread+0x108/0x110
 [] ? __kthread_parkme+0x67/0x67
 [] ret_from_fork+0x7c/0xb0
 [] ? __kthread_parkme+0x67/0x67

Signed-off-by: Stephen Barber 
---
 sound/usb/mixer.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c
index 082736c539bc..253fc946db29 100644
--- a/sound/usb/mixer.c
+++ b/sound/usb/mixer.c
@@ -318,12 +318,15 @@ static int get_ctl_value_v1(struct usb_mixer_elem_info 
*cval, int request,
 
while (timeout-- > 0) {
idx = snd_usb_ctrl_intf(chip) | (cval->head.id << 8);
-   if (snd_usb_ctl_msg(chip->dev, usb_rcvctrlpipe(chip->dev, 0), 
request,
-   USB_RECIP_INTERFACE | USB_TYPE_CLASS | 
USB_DIR_IN,
-   validx, idx, buf, val_len) >= val_len) {
+   err = snd_usb_ctl_msg(chip->dev, usb_rcvctrlpipe(chip->dev, 0), 
request,
+ USB_RECIP_INTERFACE | USB_TYPE_CLASS | 
USB_DIR_IN,
+ validx, idx, buf, val_len);
+   if (err >= val_len) {
*value_ret = convert_signed_value(cval, 
snd_usb_combine_bytes(buf, val_len));
err = 0;
goto out;
+   } else if (err == -ETIMEDOUT) {
+   goto out;
}
}
usb_audio_dbg(chip,
@@ -483,12 +486,15 @@ int snd_usb_mixer_set_ctl_value(struct 
usb_mixer_elem_info *cval,
 
while (timeout-- > 0) {
idx = snd_usb_ctrl_intf(chip) | (cval->head.id << 8);
-   if (snd_usb_ctl_msg(chip->dev,
-   usb_sndctrlpipe(chip->dev, 0), request,
-   USB_RECIP_INTERFACE | USB_TYPE_CLASS | 
USB_DIR_OUT,
-   validx, idx, buf, val_len) >= 0) {
+   err = snd_usb_ctl_msg(chip->dev,
+ usb_sndctrlpipe(chip->dev, 0), request,
+ USB_RECIP_INTERFACE | USB_TYPE_CLASS | 
USB_DIR_OUT,
+ validx, idx, buf, val_len);
+   if (err >= 0) {
err = 0;
goto out;
+   } else if (err == -ETIMEDOUT) {
+   goto out;
}
}
usb_audio_dbg(chip, "cannot set ctl value: req = %#x, wValue = %#x, 
wIndex = %#x, type = %d, data = %#x/%#x\n",
-- 
2.14.1.480.gb18f417b89-goog

Re: [PATCH v2 2/2] dt-bindings: usb: keystone-usb: Update bindings pm and clocks properties

[Rob Herring]

On Wed, Aug 16, 2017 at 04:54:08PM -0500, Franklin S Cooper Jr wrote:
> Update various properties to properly indicate their requirement depending
> on the SoC.
> 
> Signed-off-by: Franklin S Cooper Jr 
> ---
> Version 2:
> Clarify clock requirements in binding document
> 
>  Documentation/devicetree/bindings/usb/keystone-usb.txt | 17 +++--
>  1 file changed, 15 insertions(+), 2 deletions(-)

Acked-by: Rob Herring 

Re: [PATCH v2 2/2] dt-bindings: usb: keystone-usb: Update bindings pm and clocks properties

[Rob Herring]

On Wed, Aug 16, 2017 at 04:54:08PM -0500, Franklin S Cooper Jr wrote:
> Update various properties to properly indicate their requirement depending
> on the SoC.
> 
> Signed-off-by: Franklin S Cooper Jr 
> ---
> Version 2:
> Clarify clock requirements in binding document
> 
>  Documentation/devicetree/bindings/usb/keystone-usb.txt | 17 +++--
>  1 file changed, 15 insertions(+), 2 deletions(-)

Acked-by: Rob Herring 

Re: [PATCH v3 1/5] iio: srf08: add device tree binding for srf02 and srf10

[Rob Herring]

On Wed, Aug 16, 2017 at 09:33:23PM +0200, Andreas Klinger wrote:
> add trivial device tree binding "devantech,srf02" and "devantech,srf10"
> 
> Signed-off-by: Andreas Klinger 
> Acked-by: Jonathan Cameron 
> ---
>  Documentation/devicetree/bindings/i2c/trivial-devices.txt | 2 ++
>  1 file changed, 2 insertions(+)

I thought this was mentioned in the prior versions, but this file has 
moved. Rebase to 4.13. Please send trivial-devices.txt changes 
separately to me.

Rob

Re: [PATCH v3 1/5] iio: srf08: add device tree binding for srf02 and srf10

[Rob Herring]

On Wed, Aug 16, 2017 at 09:33:23PM +0200, Andreas Klinger wrote:
> add trivial device tree binding "devantech,srf02" and "devantech,srf10"
> 
> Signed-off-by: Andreas Klinger 
> Acked-by: Jonathan Cameron 
> ---
>  Documentation/devicetree/bindings/i2c/trivial-devices.txt | 2 ++
>  1 file changed, 2 insertions(+)

I thought this was mentioned in the prior versions, but this file has 
moved. Rebase to 4.13. Please send trivial-devices.txt changes 
separately to me.

Rob

Re: [PATCH v2] blktrace: Fix potentail deadlock between delete & sysfs ops

[Steven Rostedt]

On Thu, 17 Aug 2017 18:13:20 -0400
Steven Rostedt  wrote:

> On Thu, 17 Aug 2017 17:27:22 -0400
> Waiman Long  wrote:
> 
> 
> > It is actually what the patch is trying to do by checking for the
> > deletion flag in the mutex_trylock loop. Please note that mutex does not
> > guarantee FIFO ordering of lock acquisition. As a result, cpu1 may call
> > mutex_lock() and wait for it while cpu2 can set the deletion flag later
> > and get the mutex first before cpu1. So checking for the deletion flag
> > before taking the mutex isn't enough.  
> 
> Yeah, I figured that out already (crossed emails). BTW, how did you
> trigger this warning. I'm playing around with adding loop devices,
> volume groups, and logical volumes, and reading the trace files
> created in the sysfs directory, then removing those items, but it's
> not triggering the "delete" path. What operation deletes the partition?

I'm guessing that deleting an actual partition may work (unfortunately,
my test box has no partition to delete ;-) I'll find another box to
test on.

-- Steve

Re: [PATCH v2] blktrace: Fix potentail deadlock between delete & sysfs ops

[Steven Rostedt]

On Thu, 17 Aug 2017 18:13:20 -0400
Steven Rostedt  wrote:

> On Thu, 17 Aug 2017 17:27:22 -0400
> Waiman Long  wrote:
> 
> 
> > It is actually what the patch is trying to do by checking for the
> > deletion flag in the mutex_trylock loop. Please note that mutex does not
> > guarantee FIFO ordering of lock acquisition. As a result, cpu1 may call
> > mutex_lock() and wait for it while cpu2 can set the deletion flag later
> > and get the mutex first before cpu1. So checking for the deletion flag
> > before taking the mutex isn't enough.  
> 
> Yeah, I figured that out already (crossed emails). BTW, how did you
> trigger this warning. I'm playing around with adding loop devices,
> volume groups, and logical volumes, and reading the trace files
> created in the sysfs directory, then removing those items, but it's
> not triggering the "delete" path. What operation deletes the partition?

I'm guessing that deleting an actual partition may work (unfortunately,
my test box has no partition to delete ;-) I'll find another box to
test on.

-- Steve

Re: [HMM-v25 00/19] HMM (Heterogeneous Memory Management) v25

[Andrew Morton]

On Thu, 17 Aug 2017 14:59:20 -0700 Dan Williams  
wrote:

> On Thu, Aug 17, 2017 at 2:55 PM, Jerome Glisse  wrote:
> > On Thu, Aug 17, 2017 at 02:39:16PM -0700, Andrew Morton wrote:
> >> On Wed, 16 Aug 2017 20:05:29 -0400 J__r__me Glisse  
> >> wrote:
> >>
> >> > Heterogeneous Memory Management (HMM) (description and justification)
> >>
> >> The patchset adds 55 kbytes to x86_64's mm/*.o and there doesn't appear
> >> to be any way of avoiding this overhead, or of avoiding whatever
> >> runtime overheads are added.
> >
> > HMM have already been integrated in couple of Red Hat kernel and AFAIK there
> > is no runtime performance issue reported. Thought the RHEL version does not
> > use static key as Dan asked.
> >
> >>
> >> It also adds 18k to arm's mm/*.o and arm doesn't support HMM at all.
> >>
> >> So that's all quite a lot of bloat for systems which get no benefit from
> >> the patchset.  What can we do to improve this situation (a lot)?
> >
> > I will look into why object file grow so much on arm. My guess is that the
> > new migrate code is the bulk of that. I can hide the new page migration code
> > behind a kernel configuration flag.
> 
> Shouldn't we completely disable all of it unless there is a driver in
> the kernel that selects it?

That would be typical (and nice).

I'm not sure that Red Hat's decision is a broad enough guide here. 
Someone who is using Linux to make a cash register or a thermostat
faces different tradeoffs...

Re: [PATCH][V2] drm/nouveau: perform null check on msto[i] rathern than msto

[Colin Ian King]

On 17/08/17 23:07, Ilia Mirkin wrote:
> On Thu, Aug 17, 2017 at 6:03 PM, Colin King  wrote:
>> From: Colin Ian King 
>>
>> The null check on the array msto is incorrect since msto is never
>> null. The null check should be instead on msto[i] since this is
>> being dereferenced in the call to drm_mode_connector_attach_encoder.
>>
>> Thanks to Emil Velikov for pointing out the mistake in my original
>> fix and for suggesting the correct fix.
>>
>> Detected by CoverityScan, CID#1375915 ("Array compared against 0")
>>
>> Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2 
>> multi-stream")
>> Signed-off-by: Colin Ian King 
>> ---
>>  drivers/gpu/drm/nouveau/nv50_display.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
>> b/drivers/gpu/drm/nouveau/nv50_display.c
>> index f7b4326a4641..ed444ecd9e85 100644
>> --- a/drivers/gpu/drm/nouveau/nv50_display.c
>> +++ b/drivers/gpu/drm/nouveau/nv50_display.c
>> @@ -3141,7 +3141,7 @@ nv50_mstc_new(struct nv50_mstm *mstm, struct 
>> drm_dp_mst_port *port,
>> mstc->connector.funcs->reset(>connector);
>> nouveau_conn_attach_properties(>connector);
>>
>> -   for (i = 0; i < ARRAY_SIZE(mstm->msto) && mstm->msto; i++)
>> +   for (i = 0; i < ARRAY_SIZE(mstm->msto) && mstm->msto[i]; i++)
> 
> Ben will have to rule on which way is correct, but another
> interpretation is that it should be
> 
> for (...; i < ARRAY_SIZE; i++)
>   if (mstm->msto[i])
> do_stuff()

Yes, I suspect that is a better generic solution top cope with potential
"holes".
> 
> I haven't the faintest clue whether the msto array can have "holes" or not.

Indeed. Let's see what Ben says.


> 
>> drm_mode_connector_attach_encoder(>connector, 
>> >msto[i]->encoder);
>>
>> drm_object_attach_property(>connector.base, 
>> dev->mode_config.path_property, 0);
>> --
>> 2.11.0
>>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [HMM-v25 00/19] HMM (Heterogeneous Memory Management) v25

[Andrew Morton]

On Thu, 17 Aug 2017 14:59:20 -0700 Dan Williams  
wrote:

> On Thu, Aug 17, 2017 at 2:55 PM, Jerome Glisse  wrote:
> > On Thu, Aug 17, 2017 at 02:39:16PM -0700, Andrew Morton wrote:
> >> On Wed, 16 Aug 2017 20:05:29 -0400 J__r__me Glisse  
> >> wrote:
> >>
> >> > Heterogeneous Memory Management (HMM) (description and justification)
> >>
> >> The patchset adds 55 kbytes to x86_64's mm/*.o and there doesn't appear
> >> to be any way of avoiding this overhead, or of avoiding whatever
> >> runtime overheads are added.
> >
> > HMM have already been integrated in couple of Red Hat kernel and AFAIK there
> > is no runtime performance issue reported. Thought the RHEL version does not
> > use static key as Dan asked.
> >
> >>
> >> It also adds 18k to arm's mm/*.o and arm doesn't support HMM at all.
> >>
> >> So that's all quite a lot of bloat for systems which get no benefit from
> >> the patchset.  What can we do to improve this situation (a lot)?
> >
> > I will look into why object file grow so much on arm. My guess is that the
> > new migrate code is the bulk of that. I can hide the new page migration code
> > behind a kernel configuration flag.
> 
> Shouldn't we completely disable all of it unless there is a driver in
> the kernel that selects it?

That would be typical (and nice).

I'm not sure that Red Hat's decision is a broad enough guide here. 
Someone who is using Linux to make a cash register or a thermostat
faces different tradeoffs...

Re: [PATCH][V2] drm/nouveau: perform null check on msto[i] rathern than msto

[Colin Ian King]

On 17/08/17 23:07, Ilia Mirkin wrote:
> On Thu, Aug 17, 2017 at 6:03 PM, Colin King  wrote:
>> From: Colin Ian King 
>>
>> The null check on the array msto is incorrect since msto is never
>> null. The null check should be instead on msto[i] since this is
>> being dereferenced in the call to drm_mode_connector_attach_encoder.
>>
>> Thanks to Emil Velikov for pointing out the mistake in my original
>> fix and for suggesting the correct fix.
>>
>> Detected by CoverityScan, CID#1375915 ("Array compared against 0")
>>
>> Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2 
>> multi-stream")
>> Signed-off-by: Colin Ian King 
>> ---
>>  drivers/gpu/drm/nouveau/nv50_display.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
>> b/drivers/gpu/drm/nouveau/nv50_display.c
>> index f7b4326a4641..ed444ecd9e85 100644
>> --- a/drivers/gpu/drm/nouveau/nv50_display.c
>> +++ b/drivers/gpu/drm/nouveau/nv50_display.c
>> @@ -3141,7 +3141,7 @@ nv50_mstc_new(struct nv50_mstm *mstm, struct 
>> drm_dp_mst_port *port,
>> mstc->connector.funcs->reset(>connector);
>> nouveau_conn_attach_properties(>connector);
>>
>> -   for (i = 0; i < ARRAY_SIZE(mstm->msto) && mstm->msto; i++)
>> +   for (i = 0; i < ARRAY_SIZE(mstm->msto) && mstm->msto[i]; i++)
> 
> Ben will have to rule on which way is correct, but another
> interpretation is that it should be
> 
> for (...; i < ARRAY_SIZE; i++)
>   if (mstm->msto[i])
> do_stuff()

Yes, I suspect that is a better generic solution top cope with potential
"holes".
> 
> I haven't the faintest clue whether the msto array can have "holes" or not.

Indeed. Let's see what Ben says.


> 
>> drm_mode_connector_attach_encoder(>connector, 
>> >msto[i]->encoder);
>>
>> drm_object_attach_property(>connector.base, 
>> dev->mode_config.path_property, 0);
>> --
>> 2.11.0
>>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH v3] MTD: NAND: add OOB layout without ECC bytes

[Boris Brezillon]

+Yoshi

Hi Miquel,

Subject prefix should be "mtd: nand: " in lowercase.

Le Wed, 16 Aug 2017 09:39:06 +0200,
Miquel Raynal  a écrit :

> Add layout functions for small and large pages with mainly free bytes
> plus reserved space for Bad Block Markers. This may be useful for
> specific chip that use on-die ECC feature, ie. the TOSHIBA BENAND
> (Built-in ECC NAND). The ECC bytes are stored in an isolated area
> inaccessible by the driver and thus the OOB layout must only reserve
> space for Bad Block Markers.

Yes, that's true, but as said below, I expect the toshiba driver to
explicitly set this layout.

> 
> Bad Block Markers position was extracted from the existing OOB layouts
> by assigning as free all the bytes marked as ECC.
> 
> The layout functions added by this patch were supposed to be used with
> ECC_NONE mode but it would break existing drivers that do not rely on
> an implementation of this layout by the core, so set it as a fallthrough
> when no other layout matches.

Well, it's still supposed to be used when ECC_NONE is set, except we can
only use it for cases that were not already falling in the supported
large/small page with ECC cases.

> 
> Signed-off-by: Miquel Raynal 
> ---
>  drivers/mtd/nand/nand_base.c | 65 
> 
>  1 file changed, 60 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index c5221795a1e8..7c0ae674e50a 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -53,7 +53,38 @@ static int nand_get_device(struct mtd_info *mtd, int 
> new_state);
>  static int nand_do_write_oob(struct mtd_info *mtd, loff_t to,
>struct mtd_oob_ops *ops);
>  
> -/* Define default oob placement schemes for large and small page devices */
> +/*
> + * Define default OOB placement schemes for:
> + *   - no ECC or software ECC
> + *   - small or large page devices
> + */
> +static int nand_ooblayout_free_sp_no_ecc(struct mtd_info *mtd, int section,
> +struct mtd_oob_region *oobregion)
> +{
> + if (section > 1)
> + return -ERANGE;
> +
> + if (!section) {
> + if (mtd->oobsize == 16) {
> + oobregion->offset = 0;
> + oobregion->length = 4;
> + } else {
> + oobregion->offset = 0;
> + oobregion->length = 5;
> + }
> + } else {
> + oobregion->offset = 6;
> + oobregion->length = mtd->oobsize - oobregion->offset;
> + }
> +
> + return 0;
> +}
> +
> +const struct mtd_ooblayout_ops nand_ooblayout_sp_no_ecc_ops = {
> + .free = nand_ooblayout_free_sp_no_ecc,
> +};
> +EXPORT_SYMBOL_GPL(nand_ooblayout_sp_no_ecc_ops);
> +
>  static int nand_ooblayout_ecc_sp(struct mtd_info *mtd, int section,
>struct mtd_oob_region *oobregion)
>  {
> @@ -109,6 +140,23 @@ const struct mtd_ooblayout_ops nand_ooblayout_sp_ops = {
>  };
>  EXPORT_SYMBOL_GPL(nand_ooblayout_sp_ops);
>  
> +static int nand_ooblayout_free_lp_no_ecc(struct mtd_info *mtd, int section,
> +struct mtd_oob_region *oobregion)
> +{
> + if (section)
> + return -ERANGE;
> +
> + oobregion->offset = 2;
> + oobregion->length = mtd->oobsize - oobregion->offset;
> +
> + return 0;
> +}
> +
> +const struct mtd_ooblayout_ops nand_ooblayout_lp_no_ecc_ops = {
> + .free = nand_ooblayout_free_lp_no_ecc,
> +};
> +EXPORT_SYMBOL_GPL(nand_ooblayout_lp_no_ecc_ops);

No need to export those symbols until someone really needs them.
BTW, they are exported but not declared in nand.h, so right now nobody can
use them.

> +
>  static int nand_ooblayout_ecc_lp(struct mtd_info *mtd, int section,
>struct mtd_oob_region *oobregion)
>  {
> @@ -4649,10 +4697,17 @@ int nand_scan_tail(struct mtd_info *mtd)
>   mtd_set_ooblayout(mtd, _ooblayout_lp_hamming_ops);
>   break;
>   default:
> - WARN(1, "No oob scheme defined for oobsize %d\n",
> - mtd->oobsize);
> - ret = -EINVAL;
> - goto err_free;
> + /*
> +  * In the case of on-die ECC (when ECC are stored in an
> +  * isolated area inaccessible by the driver), the OOB
> +  * layout must only reserve space for Bad Block Markers.
> +  */

This kind of on-die ECC is not yet supported and I'd expect NAND
manufacturer drivers to set the appropriate layout before reaching this
point, so that's not really relevant here.

> + if (mtd->writesize <= 512)
> + mtd_set_ooblayout(mtd,
> +

Re: [PATCH v3] MTD: NAND: add OOB layout without ECC bytes

[Boris Brezillon]

+Yoshi

Hi Miquel,

Subject prefix should be "mtd: nand: " in lowercase.

Le Wed, 16 Aug 2017 09:39:06 +0200,
Miquel Raynal  a écrit :

> Add layout functions for small and large pages with mainly free bytes
> plus reserved space for Bad Block Markers. This may be useful for
> specific chip that use on-die ECC feature, ie. the TOSHIBA BENAND
> (Built-in ECC NAND). The ECC bytes are stored in an isolated area
> inaccessible by the driver and thus the OOB layout must only reserve
> space for Bad Block Markers.

Yes, that's true, but as said below, I expect the toshiba driver to
explicitly set this layout.

> 
> Bad Block Markers position was extracted from the existing OOB layouts
> by assigning as free all the bytes marked as ECC.
> 
> The layout functions added by this patch were supposed to be used with
> ECC_NONE mode but it would break existing drivers that do not rely on
> an implementation of this layout by the core, so set it as a fallthrough
> when no other layout matches.

Well, it's still supposed to be used when ECC_NONE is set, except we can
only use it for cases that were not already falling in the supported
large/small page with ECC cases.

> 
> Signed-off-by: Miquel Raynal 
> ---
>  drivers/mtd/nand/nand_base.c | 65 
> 
>  1 file changed, 60 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index c5221795a1e8..7c0ae674e50a 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -53,7 +53,38 @@ static int nand_get_device(struct mtd_info *mtd, int 
> new_state);
>  static int nand_do_write_oob(struct mtd_info *mtd, loff_t to,
>struct mtd_oob_ops *ops);
>  
> -/* Define default oob placement schemes for large and small page devices */
> +/*
> + * Define default OOB placement schemes for:
> + *   - no ECC or software ECC
> + *   - small or large page devices
> + */
> +static int nand_ooblayout_free_sp_no_ecc(struct mtd_info *mtd, int section,
> +struct mtd_oob_region *oobregion)
> +{
> + if (section > 1)
> + return -ERANGE;
> +
> + if (!section) {
> + if (mtd->oobsize == 16) {
> + oobregion->offset = 0;
> + oobregion->length = 4;
> + } else {
> + oobregion->offset = 0;
> + oobregion->length = 5;
> + }
> + } else {
> + oobregion->offset = 6;
> + oobregion->length = mtd->oobsize - oobregion->offset;
> + }
> +
> + return 0;
> +}
> +
> +const struct mtd_ooblayout_ops nand_ooblayout_sp_no_ecc_ops = {
> + .free = nand_ooblayout_free_sp_no_ecc,
> +};
> +EXPORT_SYMBOL_GPL(nand_ooblayout_sp_no_ecc_ops);
> +
>  static int nand_ooblayout_ecc_sp(struct mtd_info *mtd, int section,
>struct mtd_oob_region *oobregion)
>  {
> @@ -109,6 +140,23 @@ const struct mtd_ooblayout_ops nand_ooblayout_sp_ops = {
>  };
>  EXPORT_SYMBOL_GPL(nand_ooblayout_sp_ops);
>  
> +static int nand_ooblayout_free_lp_no_ecc(struct mtd_info *mtd, int section,
> +struct mtd_oob_region *oobregion)
> +{
> + if (section)
> + return -ERANGE;
> +
> + oobregion->offset = 2;
> + oobregion->length = mtd->oobsize - oobregion->offset;
> +
> + return 0;
> +}
> +
> +const struct mtd_ooblayout_ops nand_ooblayout_lp_no_ecc_ops = {
> + .free = nand_ooblayout_free_lp_no_ecc,
> +};
> +EXPORT_SYMBOL_GPL(nand_ooblayout_lp_no_ecc_ops);

No need to export those symbols until someone really needs them.
BTW, they are exported but not declared in nand.h, so right now nobody can
use them.

> +
>  static int nand_ooblayout_ecc_lp(struct mtd_info *mtd, int section,
>struct mtd_oob_region *oobregion)
>  {
> @@ -4649,10 +4697,17 @@ int nand_scan_tail(struct mtd_info *mtd)
>   mtd_set_ooblayout(mtd, _ooblayout_lp_hamming_ops);
>   break;
>   default:
> - WARN(1, "No oob scheme defined for oobsize %d\n",
> - mtd->oobsize);
> - ret = -EINVAL;
> - goto err_free;
> + /*
> +  * In the case of on-die ECC (when ECC are stored in an
> +  * isolated area inaccessible by the driver), the OOB
> +  * layout must only reserve space for Bad Block Markers.
> +  */

This kind of on-die ECC is not yet supported and I'd expect NAND
manufacturer drivers to set the appropriate layout before reaching this
point, so that's not really relevant here.

> + if (mtd->writesize <= 512)
> + mtd_set_ooblayout(mtd,
> + _ooblayout_sp_no_ecc_ops);
> + 

[PATCH] irda: do not leak initialized list.dev to userspace

[Colin King]

From: Colin Ian King 

list.dev has not been initialized and so the copy_to_user is copying
data from the stack back to user space which is a potential
information leak. Fix this ensuring all of list is initialized to
zero.

Detected by CoverityScan, CID#1357894 ("Uninitialized scalar variable")

Signed-off-by: Colin Ian King 
---
 net/irda/af_irda.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/irda/af_irda.c b/net/irda/af_irda.c
index 2e6990f8b80b..23fa7c8b09a5 100644
--- a/net/irda/af_irda.c
+++ b/net/irda/af_irda.c
@@ -2213,7 +2213,7 @@ static int irda_getsockopt(struct socket *sock, int 
level, int optname,
 {
struct sock *sk = sock->sk;
struct irda_sock *self = irda_sk(sk);
-   struct irda_device_list list;
+   struct irda_device_list list = { 0 };
struct irda_device_info *discoveries;
struct irda_ias_set *   ias_opt;/* IAS get/query params */
struct ias_object * ias_obj;/* Object in IAS */
-- 
2.11.0

[PATCH] irda: do not leak initialized list.dev to userspace

[Colin King]

From: Colin Ian King 

list.dev has not been initialized and so the copy_to_user is copying
data from the stack back to user space which is a potential
information leak. Fix this ensuring all of list is initialized to
zero.

Detected by CoverityScan, CID#1357894 ("Uninitialized scalar variable")

Signed-off-by: Colin Ian King 
---
 net/irda/af_irda.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/irda/af_irda.c b/net/irda/af_irda.c
index 2e6990f8b80b..23fa7c8b09a5 100644
--- a/net/irda/af_irda.c
+++ b/net/irda/af_irda.c
@@ -2213,7 +2213,7 @@ static int irda_getsockopt(struct socket *sock, int 
level, int optname,
 {
struct sock *sk = sock->sk;
struct irda_sock *self = irda_sk(sk);
-   struct irda_device_list list;
+   struct irda_device_list list = { 0 };
struct irda_device_info *discoveries;
struct irda_ias_set *   ias_opt;/* IAS get/query params */
struct ias_object * ias_obj;/* Object in IAS */
-- 
2.11.0