[PATCH v2 1/6] MAINTAINERS: add at91 usart mfd driver

[Radu Pirea]

Added entry for at91 usart mfd driver.

Signed-off-by: Radu Pirea 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8e2a2fddbd19..ca06c6f58299 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9192,6 +9192,13 @@ S:   Supported
 F: drivers/mtd/nand/raw/atmel/*
 F: Documentation/devicetree/bindings/mtd/atmel-nand.txt
 
+MICROCHIP AT91 USART MFD DRIVER
+M: Radu Pirea 
+L: linux-kernel@vger.kernel.org
+S: Supported
+F: drivers/mfd/at91-usart.c
+F: include/dt-bindings/mfd/at91-usart.h
+
 MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER
 M: Woojung Huh 
 M: Microchip Linux Driver Support 
-- 
2.17.0

[PATCH v2 1/6] MAINTAINERS: add at91 usart mfd driver

[Radu Pirea]

Added entry for at91 usart mfd driver.

Signed-off-by: Radu Pirea 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8e2a2fddbd19..ca06c6f58299 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9192,6 +9192,13 @@ S:   Supported
 F: drivers/mtd/nand/raw/atmel/*
 F: Documentation/devicetree/bindings/mtd/atmel-nand.txt
 
+MICROCHIP AT91 USART MFD DRIVER
+M: Radu Pirea 
+L: linux-kernel@vger.kernel.org
+S: Supported
+F: drivers/mfd/at91-usart.c
+F: include/dt-bindings/mfd/at91-usart.h
+
 MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER
 M: Woojung Huh 
 M: Microchip Linux Driver Support 
-- 
2.17.0

Re: [PATCH 0/3] K2G: mmc: Update mmc dt node to use sdhci-omap

[santosh.shilim...@oracle.com]

On 5/4/18 1:06 AM, Kishon Vijay Abraham I wrote:

Hi Santosh,

On Friday 04 May 2018 12:22 AM, santosh.shilim...@oracle.com wrote:

On 5/3/18 4:57 AM, Kishon Vijay Abraham I wrote:

Hi Santosh,

On Wednesday 25 April 2018 11:10 PM, Santosh Shilimkar wrote:

On 4/25/2018 6:27 AM, Kishon Vijay Abraham I wrote:

Update mmc dt node to use sdhci-omap binding instead of omap_hsmmc
binding.

I've also updated keystone_defconfig to enable CONFIG_MMC_SDHCI_OMAP.
Everyone who use a custom .config should also enable
CONFIG_MMC_SDHCI_OMAP for MMC to work.

This series should be merged only after [1]
[1] -> https://marc.info/?l=linux-kernel=152465820531802=2


Keep me posted once the dependency gets merged.


Ulf has merged the sdhci part and has shared an immutable branch

git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git sdhci_omap
with his signed tag sdhci-omap-v4.17-rc3.

Can you use it as a base for merging this series?


How about I apply only DTS patches and exlude config file update ?
You can send the config patch after the merge window. Are the DTS
changes also going to break anything without basing of this sdhci
branch ?


Yes, the bindings has changed for sdhci-omap.
It should also be fine if this entire series can be merged during the 4.18 -rc
cycle since the dependent patches would have been already merged then.


I see. In that, lets wait for 4.18-rcx for all the dependencies to make
it. This series won't qualify for fixes but at least we can get that
into next early in the cycle so that it becomes usable.

Thanks for followup Kishon !!

Regards,
Santosh

Re: [PATCH 0/3] K2G: mmc: Update mmc dt node to use sdhci-omap

[santosh.shilim...@oracle.com]

On 5/4/18 1:06 AM, Kishon Vijay Abraham I wrote:

Hi Santosh,

On Friday 04 May 2018 12:22 AM, santosh.shilim...@oracle.com wrote:

On 5/3/18 4:57 AM, Kishon Vijay Abraham I wrote:

Hi Santosh,

On Wednesday 25 April 2018 11:10 PM, Santosh Shilimkar wrote:

On 4/25/2018 6:27 AM, Kishon Vijay Abraham I wrote:

Update mmc dt node to use sdhci-omap binding instead of omap_hsmmc
binding.

I've also updated keystone_defconfig to enable CONFIG_MMC_SDHCI_OMAP.
Everyone who use a custom .config should also enable
CONFIG_MMC_SDHCI_OMAP for MMC to work.

This series should be merged only after [1]
[1] -> https://marc.info/?l=linux-kernel=152465820531802=2


Keep me posted once the dependency gets merged.


Ulf has merged the sdhci part and has shared an immutable branch

git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git sdhci_omap
with his signed tag sdhci-omap-v4.17-rc3.

Can you use it as a base for merging this series?


How about I apply only DTS patches and exlude config file update ?
You can send the config patch after the merge window. Are the DTS
changes also going to break anything without basing of this sdhci
branch ?


Yes, the bindings has changed for sdhci-omap.
It should also be fine if this entire series can be merged during the 4.18 -rc
cycle since the dependent patches would have been already merged then.


I see. In that, lets wait for 4.18-rcx for all the dependencies to make
it. This series won't qualify for fixes but at least we can get that
into next early in the cycle so that it becomes usable.

Thanks for followup Kishon !!

Regards,
Santosh

[PATCH v2 3/6] MAINTAINERS: add at91 usart spi driver

[Radu Pirea]

Added entry for at91 usart mfd driver.

Signed-off-by: Radu Pirea 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ca06c6f58299..9243b9007966 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9199,6 +9199,13 @@ S:   Supported
 F: drivers/mfd/at91-usart.c
 F: include/dt-bindings/mfd/at91-usart.h
 
+MICROCHIP AT91 USART SPI DRIVER
+M: Radu Pirea 
+L: linux-...@vger.kernel.org
+S: Supported
+F: drivers/spi/spi-at91-usart.c
+F: Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
+
 MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER
 M: Woojung Huh 
 M: Microchip Linux Driver Support 
-- 
2.17.0

Re: [PATCH v2] ARM: dts: k2g-evm: Add DCAN dt nodes

[santosh.shilim...@oracle.com]

On 5/3/18 12:28 AM, Faiz Abbas wrote:

The 66AK2G evm has support for dcan.
Add nodes and pinmuxes for dcan0 and dcan1.

Signed-off-by: Faiz Abbas 
---
Changes since v1:
Description updated.

Will pick this up.

Regards,
Santosh

[PATCH v2 3/6] MAINTAINERS: add at91 usart spi driver

[Radu Pirea]

Added entry for at91 usart mfd driver.

Signed-off-by: Radu Pirea 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ca06c6f58299..9243b9007966 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9199,6 +9199,13 @@ S:   Supported
 F: drivers/mfd/at91-usart.c
 F: include/dt-bindings/mfd/at91-usart.h
 
+MICROCHIP AT91 USART SPI DRIVER
+M: Radu Pirea 
+L: linux-...@vger.kernel.org
+S: Supported
+F: drivers/spi/spi-at91-usart.c
+F: Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
+
 MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER
 M: Woojung Huh 
 M: Microchip Linux Driver Support 
-- 
2.17.0

Re: [PATCH v2] ARM: dts: k2g-evm: Add DCAN dt nodes

[santosh.shilim...@oracle.com]

On 5/3/18 12:28 AM, Faiz Abbas wrote:

The 66AK2G evm has support for dcan.
Add nodes and pinmuxes for dcan0 and dcan1.

Signed-off-by: Faiz Abbas 
---
Changes since v1:
Description updated.

Will pick this up.

Regards,
Santosh

[PATCH v2 6/6] tty/serial: atmel: changed the driver to work under at91-usart mfd

[Radu Pirea]

This patch modifies the place where resources and device tree properties
are searched.

Signed-off-by: Radu Pirea 
---
 drivers/tty/serial/Kconfig|  1 +
 drivers/tty/serial/atmel_serial.c | 29 +++--
 2 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 3682fd3e960c..25e55332f8b1 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -119,6 +119,7 @@ config SERIAL_ATMEL
depends on ARCH_AT91 || COMPILE_TEST
select SERIAL_CORE
select SERIAL_MCTRL_GPIO if GPIOLIB
+   select MFD_AT91_USART
help
  This enables the driver for the on-chip UARTs of the Atmel
  AT91 processors.
diff --git a/drivers/tty/serial/atmel_serial.c 
b/drivers/tty/serial/atmel_serial.c
index df46a9e88c34..6b4494352853 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -193,8 +193,8 @@ static struct console atmel_console;
 
 #if defined(CONFIG_OF)
 static const struct of_device_id atmel_serial_dt_ids[] = {
-   { .compatible = "atmel,at91rm9200-usart" },
-   { .compatible = "atmel,at91sam9260-usart" },
+   { .compatible = "atmel,at91rm9200-usart-serial" },
+   { .compatible = "atmel,at91sam9260-usart-serial" },
{ /* sentinel */ }
 };
 #endif
@@ -1631,7 +1631,7 @@ static void atmel_tasklet_tx_func(unsigned long data)
 static void atmel_init_property(struct atmel_uart_port *atmel_port,
struct platform_device *pdev)
 {
-   struct device_node *np = pdev->dev.of_node;
+   struct device_node *np = pdev->dev.parent->of_node;
 
/* DMA/PDC usage specification */
if (of_property_read_bool(np, "atmel,use-dma-rx")) {
@@ -2223,7 +2223,8 @@ static const char *atmel_type(struct uart_port *port)
 static void atmel_release_port(struct uart_port *port)
 {
struct platform_device *pdev = to_platform_device(port->dev);
-   int size = pdev->resource[0].end - pdev->resource[0].start + 1;
+   int size = to_platform_device(pdev->dev.parent)->resource[0].end -
+   to_platform_device(pdev->dev.parent)->resource[0].start + 1;
 
release_mem_region(port->mapbase, size);
 
@@ -2239,7 +2240,8 @@ static void atmel_release_port(struct uart_port *port)
 static int atmel_request_port(struct uart_port *port)
 {
struct platform_device *pdev = to_platform_device(port->dev);
-   int size = pdev->resource[0].end - pdev->resource[0].start + 1;
+   int size = to_platform_device(pdev->dev.parent)->resource[0].end -
+   to_platform_device(pdev->dev.parent)->resource[0].start + 1;
 
if (!request_mem_region(port->mapbase, size, "atmel_serial"))
return -EBUSY;
@@ -2345,23 +2347,23 @@ static int atmel_init_port(struct atmel_uart_port 
*atmel_port,
atmel_init_property(atmel_port, pdev);
atmel_set_ops(port);
 
-   uart_get_rs485_mode(>dev, >rs485);
+   uart_get_rs485_mode(pdev->dev.parent, >rs485);
 
port->iotype= UPIO_MEM;
port->flags = UPF_BOOT_AUTOCONF | UPF_IOREMAP;
port->ops   = _pops;
port->fifosize  = 1;
port->dev   = >dev;
-   port->mapbase   = pdev->resource[0].start;
-   port->irq   = pdev->resource[1].start;
+   port->mapbase   = 
to_platform_device(pdev->dev.parent)->resource[0].start;
+   port->irq   = 
to_platform_device(pdev->dev.parent)->resource[1].start;
port->rs485_config  = atmel_config_rs485;
-   port->membase   = NULL;
+   port->membase   = NULL;
 
memset(_port->rx_ring, 0, sizeof(atmel_port->rx_ring));
 
/* for console, the clock could already be configured */
if (!atmel_port->clk) {
-   atmel_port->clk = clk_get(>dev, "usart");
+   atmel_port->clk = clk_get(pdev->dev.parent, "usart");
if (IS_ERR(atmel_port->clk)) {
ret = PTR_ERR(atmel_port->clk);
atmel_port->clk = NULL;
@@ -2656,7 +2658,7 @@ static void atmel_serial_probe_fifos(struct 
atmel_uart_port *atmel_port,
atmel_port->rts_low = 0;
atmel_port->rts_high = 0;
 
-   if (of_property_read_u32(pdev->dev.of_node,
+   if (of_property_read_u32(pdev->dev.parent->of_node,
 "atmel,fifo-size",
 _port->fifo_size))
return;
@@ -2694,11 +2696,10 @@ static void atmel_serial_probe_fifos(struct 
atmel_uart_port *atmel_port,
 static int atmel_serial_probe(struct platform_device *pdev)
 {
struct atmel_uart_port *atmel_port;
-   struct device_node *np = pdev->dev.of_node;
+   struct device_node *np = pdev->dev.parent->of_node;
void *data;
int ret = -ENODEV;
bool rs485_enabled;
-

[PATCH v2 6/6] tty/serial: atmel: changed the driver to work under at91-usart mfd

[Radu Pirea]

This patch modifies the place where resources and device tree properties
are searched.

Signed-off-by: Radu Pirea 
---
 drivers/tty/serial/Kconfig|  1 +
 drivers/tty/serial/atmel_serial.c | 29 +++--
 2 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 3682fd3e960c..25e55332f8b1 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -119,6 +119,7 @@ config SERIAL_ATMEL
depends on ARCH_AT91 || COMPILE_TEST
select SERIAL_CORE
select SERIAL_MCTRL_GPIO if GPIOLIB
+   select MFD_AT91_USART
help
  This enables the driver for the on-chip UARTs of the Atmel
  AT91 processors.
diff --git a/drivers/tty/serial/atmel_serial.c 
b/drivers/tty/serial/atmel_serial.c
index df46a9e88c34..6b4494352853 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -193,8 +193,8 @@ static struct console atmel_console;
 
 #if defined(CONFIG_OF)
 static const struct of_device_id atmel_serial_dt_ids[] = {
-   { .compatible = "atmel,at91rm9200-usart" },
-   { .compatible = "atmel,at91sam9260-usart" },
+   { .compatible = "atmel,at91rm9200-usart-serial" },
+   { .compatible = "atmel,at91sam9260-usart-serial" },
{ /* sentinel */ }
 };
 #endif
@@ -1631,7 +1631,7 @@ static void atmel_tasklet_tx_func(unsigned long data)
 static void atmel_init_property(struct atmel_uart_port *atmel_port,
struct platform_device *pdev)
 {
-   struct device_node *np = pdev->dev.of_node;
+   struct device_node *np = pdev->dev.parent->of_node;
 
/* DMA/PDC usage specification */
if (of_property_read_bool(np, "atmel,use-dma-rx")) {
@@ -2223,7 +2223,8 @@ static const char *atmel_type(struct uart_port *port)
 static void atmel_release_port(struct uart_port *port)
 {
struct platform_device *pdev = to_platform_device(port->dev);
-   int size = pdev->resource[0].end - pdev->resource[0].start + 1;
+   int size = to_platform_device(pdev->dev.parent)->resource[0].end -
+   to_platform_device(pdev->dev.parent)->resource[0].start + 1;
 
release_mem_region(port->mapbase, size);
 
@@ -2239,7 +2240,8 @@ static void atmel_release_port(struct uart_port *port)
 static int atmel_request_port(struct uart_port *port)
 {
struct platform_device *pdev = to_platform_device(port->dev);
-   int size = pdev->resource[0].end - pdev->resource[0].start + 1;
+   int size = to_platform_device(pdev->dev.parent)->resource[0].end -
+   to_platform_device(pdev->dev.parent)->resource[0].start + 1;
 
if (!request_mem_region(port->mapbase, size, "atmel_serial"))
return -EBUSY;
@@ -2345,23 +2347,23 @@ static int atmel_init_port(struct atmel_uart_port 
*atmel_port,
atmel_init_property(atmel_port, pdev);
atmel_set_ops(port);
 
-   uart_get_rs485_mode(>dev, >rs485);
+   uart_get_rs485_mode(pdev->dev.parent, >rs485);
 
port->iotype= UPIO_MEM;
port->flags = UPF_BOOT_AUTOCONF | UPF_IOREMAP;
port->ops   = _pops;
port->fifosize  = 1;
port->dev   = >dev;
-   port->mapbase   = pdev->resource[0].start;
-   port->irq   = pdev->resource[1].start;
+   port->mapbase   = 
to_platform_device(pdev->dev.parent)->resource[0].start;
+   port->irq   = 
to_platform_device(pdev->dev.parent)->resource[1].start;
port->rs485_config  = atmel_config_rs485;
-   port->membase   = NULL;
+   port->membase   = NULL;
 
memset(_port->rx_ring, 0, sizeof(atmel_port->rx_ring));
 
/* for console, the clock could already be configured */
if (!atmel_port->clk) {
-   atmel_port->clk = clk_get(>dev, "usart");
+   atmel_port->clk = clk_get(pdev->dev.parent, "usart");
if (IS_ERR(atmel_port->clk)) {
ret = PTR_ERR(atmel_port->clk);
atmel_port->clk = NULL;
@@ -2656,7 +2658,7 @@ static void atmel_serial_probe_fifos(struct 
atmel_uart_port *atmel_port,
atmel_port->rts_low = 0;
atmel_port->rts_high = 0;
 
-   if (of_property_read_u32(pdev->dev.of_node,
+   if (of_property_read_u32(pdev->dev.parent->of_node,
 "atmel,fifo-size",
 _port->fifo_size))
return;
@@ -2694,11 +2696,10 @@ static void atmel_serial_probe_fifos(struct 
atmel_uart_port *atmel_port,
 static int atmel_serial_probe(struct platform_device *pdev)
 {
struct atmel_uart_port *atmel_port;
-   struct device_node *np = pdev->dev.of_node;
+   struct device_node *np = pdev->dev.parent->of_node;
void *data;
int ret = -ENODEV;
bool rs485_enabled;
-
BUILD_BUG_ON(ATMEL_SERIAL_RINGSIZE 

[PATCH v2 5/6] spi: at91-usart: add driver for at91-usart as spi

[Radu Pirea]

This is the driver for at91-usart in spi mode. The USART IP can be configured
to work in many modes and one of them is SPI.

The driver was tested on sama5d3-xplained and sama5d4-xplained boards with
enc28j60 ethernet controller as slave.

Signed-off-by: Radu Pirea 
---
 drivers/spi/Kconfig  |   9 +
 drivers/spi/Makefile |   1 +
 drivers/spi/spi-at91-usart.c | 545 +++
 3 files changed, 555 insertions(+)
 create mode 100644 drivers/spi/spi-at91-usart.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 6fb0347a24f2..c675e6b8dd5a 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -77,6 +77,15 @@ config SPI_ATMEL
  This selects a driver for the Atmel SPI Controller, present on
  many AT91 (ARM) chips.
 
+config SPI_AT91_USART
+tristate "Atmel USART Controller as SPI"
+   depends on HAS_DMA
+   depends on (ARCH_AT91 || COMPILE_TEST)
+select MFD_AT91_USART
+   help
+ This selects a driver for the AT91 USART Controller as SPI Master,
+ present on AT91 and SAMA5 SoC series.
+
 config SPI_AU1550
tristate "Au1550/Au1200/Au1300 SPI Controller"
depends on MIPS_ALCHEMY
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 34c5f2832ddf..fb6cb42f4eaa 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_SPI_LOOPBACK_TEST)   += 
spi-loopback-test.o
 obj-$(CONFIG_SPI_ALTERA)   += spi-altera.o
 obj-$(CONFIG_SPI_ARMADA_3700)  += spi-armada-3700.o
 obj-$(CONFIG_SPI_ATMEL)+= spi-atmel.o
+obj-$(CONFIG_SPI_AT91_USART)   += spi-at91-usart.o
 obj-$(CONFIG_SPI_ATH79)+= spi-ath79.o
 obj-$(CONFIG_SPI_AU1550)   += spi-au1550.o
 obj-$(CONFIG_SPI_AXI_SPI_ENGINE)   += spi-axi-spi-engine.o
diff --git a/drivers/spi/spi-at91-usart.c b/drivers/spi/spi-at91-usart.c
new file mode 100644
index ..94b3eb6e7296
--- /dev/null
+++ b/drivers/spi/spi-at91-usart.c
@@ -0,0 +1,545 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for AT91 USART Controllers as SPI
+ *
+ * Copyright (C) 2018 Microchip Technology Inc.
+ * Author: Radu Pirea 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+
+#define US_CR  0x00
+#define US_MR  0x04
+#define US_IER 0x08
+#defineUS_IDR  0x0C
+#defineUS_CSR  0x14
+#define US_RHR 0x18
+#defineUS_THR  0x1C
+#define US_BRGR0x20
+#define US_VERSION 0xFC
+
+#define US_CR_RSTRXBIT(2)
+#define US_CR_RSTTXBIT(3)
+#define US_CR_RXEN BIT(4)
+#define US_CR_RXDISBIT(5)
+#define US_CR_TXEN BIT(6)
+#define US_CR_TXDISBIT(7)
+
+#define US_MR_SPI_MASTER   0x0E
+#define US_MR_CHRL GENMASK(7, 6)
+#define US_MR_CPHA BIT(8)
+#define US_MR_CPOL BIT(16)
+#define US_MR_CLKO BIT(18)
+#define US_MR_WRDBTBIT(20)
+#define US_MR_LOOP BIT(15)
+
+#define US_IR_RXRDYBIT(0)
+#define US_IR_TXRDYBIT(1)
+#define US_IR_OVRE BIT(5)
+
+#define US_BRGR_SIZE   BIT(16)
+
+#define US_MIN_CLK_DIV 0x06
+#define US_MAX_CLK_DIV BIT(16)
+
+#define US_DUMMY_TX0xFF
+
+/* Register access macros */
+#define spi_readl(port, reg) \
+   readl_relaxed((port)->regs + US_##reg)
+#define spi_writel(port, reg, value) \
+   writel_relaxed((value), (port)->regs + US_##reg)
+
+#define spi_readb(port, reg) \
+   readb_relaxed((port)->regs + US_##reg)
+#define spi_writeb(port, reg, value) \
+   writeb_relaxed((value), (port)->regs + US_##reg)
+
+struct at91_usart_spi {
+   struct spi_transfer *current_transfer;
+   void __iomem*regs;
+   struct device   *dev;
+   struct clk  *clk;
+
+   /*used in interrupt to protect data reading*/
+   spinlock_t  lock;
+
+   int irq;
+   unsigned intcurrent_tx_remaining_bytes;
+   unsigned intcurrent_rx_remaining_bytes;
+   int done_status;
+
+   u32 spi_clk;
+   u32 status;
+
+   boolxfer_failed;
+   boolkeep_cs;
+   boolcs_active;
+};
+
+struct at91_usart_spi_device {
+   struct gpio_desc*npcs_pin;
+   u32 mr;
+};
+
+static inline u32 at91_usart_spi_tx_ready(struct at91_usart_spi *aus)
+{
+   return aus->status & US_IR_TXRDY;
+}
+
+static 

[PATCH v2 5/6] spi: at91-usart: add driver for at91-usart as spi

[Radu Pirea]

This is the driver for at91-usart in spi mode. The USART IP can be configured
to work in many modes and one of them is SPI.

The driver was tested on sama5d3-xplained and sama5d4-xplained boards with
enc28j60 ethernet controller as slave.

Signed-off-by: Radu Pirea 
---
 drivers/spi/Kconfig  |   9 +
 drivers/spi/Makefile |   1 +
 drivers/spi/spi-at91-usart.c | 545 +++
 3 files changed, 555 insertions(+)
 create mode 100644 drivers/spi/spi-at91-usart.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 6fb0347a24f2..c675e6b8dd5a 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -77,6 +77,15 @@ config SPI_ATMEL
  This selects a driver for the Atmel SPI Controller, present on
  many AT91 (ARM) chips.
 
+config SPI_AT91_USART
+tristate "Atmel USART Controller as SPI"
+   depends on HAS_DMA
+   depends on (ARCH_AT91 || COMPILE_TEST)
+select MFD_AT91_USART
+   help
+ This selects a driver for the AT91 USART Controller as SPI Master,
+ present on AT91 and SAMA5 SoC series.
+
 config SPI_AU1550
tristate "Au1550/Au1200/Au1300 SPI Controller"
depends on MIPS_ALCHEMY
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 34c5f2832ddf..fb6cb42f4eaa 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_SPI_LOOPBACK_TEST)   += 
spi-loopback-test.o
 obj-$(CONFIG_SPI_ALTERA)   += spi-altera.o
 obj-$(CONFIG_SPI_ARMADA_3700)  += spi-armada-3700.o
 obj-$(CONFIG_SPI_ATMEL)+= spi-atmel.o
+obj-$(CONFIG_SPI_AT91_USART)   += spi-at91-usart.o
 obj-$(CONFIG_SPI_ATH79)+= spi-ath79.o
 obj-$(CONFIG_SPI_AU1550)   += spi-au1550.o
 obj-$(CONFIG_SPI_AXI_SPI_ENGINE)   += spi-axi-spi-engine.o
diff --git a/drivers/spi/spi-at91-usart.c b/drivers/spi/spi-at91-usart.c
new file mode 100644
index ..94b3eb6e7296
--- /dev/null
+++ b/drivers/spi/spi-at91-usart.c
@@ -0,0 +1,545 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for AT91 USART Controllers as SPI
+ *
+ * Copyright (C) 2018 Microchip Technology Inc.
+ * Author: Radu Pirea 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+
+#define US_CR  0x00
+#define US_MR  0x04
+#define US_IER 0x08
+#defineUS_IDR  0x0C
+#defineUS_CSR  0x14
+#define US_RHR 0x18
+#defineUS_THR  0x1C
+#define US_BRGR0x20
+#define US_VERSION 0xFC
+
+#define US_CR_RSTRXBIT(2)
+#define US_CR_RSTTXBIT(3)
+#define US_CR_RXEN BIT(4)
+#define US_CR_RXDISBIT(5)
+#define US_CR_TXEN BIT(6)
+#define US_CR_TXDISBIT(7)
+
+#define US_MR_SPI_MASTER   0x0E
+#define US_MR_CHRL GENMASK(7, 6)
+#define US_MR_CPHA BIT(8)
+#define US_MR_CPOL BIT(16)
+#define US_MR_CLKO BIT(18)
+#define US_MR_WRDBTBIT(20)
+#define US_MR_LOOP BIT(15)
+
+#define US_IR_RXRDYBIT(0)
+#define US_IR_TXRDYBIT(1)
+#define US_IR_OVRE BIT(5)
+
+#define US_BRGR_SIZE   BIT(16)
+
+#define US_MIN_CLK_DIV 0x06
+#define US_MAX_CLK_DIV BIT(16)
+
+#define US_DUMMY_TX0xFF
+
+/* Register access macros */
+#define spi_readl(port, reg) \
+   readl_relaxed((port)->regs + US_##reg)
+#define spi_writel(port, reg, value) \
+   writel_relaxed((value), (port)->regs + US_##reg)
+
+#define spi_readb(port, reg) \
+   readb_relaxed((port)->regs + US_##reg)
+#define spi_writeb(port, reg, value) \
+   writeb_relaxed((value), (port)->regs + US_##reg)
+
+struct at91_usart_spi {
+   struct spi_transfer *current_transfer;
+   void __iomem*regs;
+   struct device   *dev;
+   struct clk  *clk;
+
+   /*used in interrupt to protect data reading*/
+   spinlock_t  lock;
+
+   int irq;
+   unsigned intcurrent_tx_remaining_bytes;
+   unsigned intcurrent_rx_remaining_bytes;
+   int done_status;
+
+   u32 spi_clk;
+   u32 status;
+
+   boolxfer_failed;
+   boolkeep_cs;
+   boolcs_active;
+};
+
+struct at91_usart_spi_device {
+   struct gpio_desc*npcs_pin;
+   u32 mr;
+};
+
+static inline u32 at91_usart_spi_tx_ready(struct at91_usart_spi *aus)
+{
+   return aus->status & US_IR_TXRDY;
+}
+
+static inline u32 at91_usart_spi_rx_ready(struct 

[PATCH v2 4/6] dt-bindings: add binding for at91-usart in spi mode

[Radu Pirea]

These are bindings for at91-usart IP in spi spi mode. There is no support for
internal chip select. Only kind of chip selects available are gpio chip
selects.

Signed-off-by: Radu Pirea 
---
 .../bindings/spi/microchip,at91-usart-spi.txt | 28 +++
 1 file changed, 28 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt

diff --git a/Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt 
b/Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
new file mode 100644
index ..b68a3bec4121
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
@@ -0,0 +1,28 @@
+* Universal Synchronous Asynchronous Receiver/Transmitter (USART) in SPI mode
+
+Required properties:
+- #size-cells  : Must be <0>
+- #address-cells   : Must be <1>
+- compatible: Should be "atmel,at91rm9200-usart" or "atmel,at91sam9260-usart"
+- reg: Should contain registers location and length
+- interrupts: Should contain interrupt
+- clocks: phandles to input clocks.
+- clock-names: tuple listing input clock names.
+   Required elements: "usart"
+- cs-gpios: chipselects (internal cs not supported)
+- at91,usart-mode: AT91_USART_MODE_SPI (found in dt-bindings/mfd/at91-usart.h)
+
+Example:
+   #include 
+
+   spi0: spi@f001c000 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "atmel,at91rm9200-usart", 
"atmel,at91sam9260-usart";
+   at91,usart-mode = ;
+   reg = <0xf001c000 0x100>;
+   interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <_clk>;
+   clock-names = "usart";
+   cs-gpios = < 3 0>;
+   };
-- 
2.17.0

[PATCH v2 4/6] dt-bindings: add binding for at91-usart in spi mode

[Radu Pirea]

These are bindings for at91-usart IP in spi spi mode. There is no support for
internal chip select. Only kind of chip selects available are gpio chip
selects.

Signed-off-by: Radu Pirea 
---
 .../bindings/spi/microchip,at91-usart-spi.txt | 28 +++
 1 file changed, 28 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt

diff --git a/Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt 
b/Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
new file mode 100644
index ..b68a3bec4121
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
@@ -0,0 +1,28 @@
+* Universal Synchronous Asynchronous Receiver/Transmitter (USART) in SPI mode
+
+Required properties:
+- #size-cells  : Must be <0>
+- #address-cells   : Must be <1>
+- compatible: Should be "atmel,at91rm9200-usart" or "atmel,at91sam9260-usart"
+- reg: Should contain registers location and length
+- interrupts: Should contain interrupt
+- clocks: phandles to input clocks.
+- clock-names: tuple listing input clock names.
+   Required elements: "usart"
+- cs-gpios: chipselects (internal cs not supported)
+- at91,usart-mode: AT91_USART_MODE_SPI (found in dt-bindings/mfd/at91-usart.h)
+
+Example:
+   #include 
+
+   spi0: spi@f001c000 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "atmel,at91rm9200-usart", 
"atmel,at91sam9260-usart";
+   at91,usart-mode = ;
+   reg = <0xf001c000 0x100>;
+   interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <_clk>;
+   clock-names = "usart";
+   cs-gpios = < 3 0>;
+   };
-- 
2.17.0

[PATCH v2 2/6] mfd: at91-usart: added mfd driver for usart

[Radu Pirea]

This mfd driver is just a wrapper over atmel_serial driver and
spi-at91-usart driver. Selection of one of the drivers is based on a
property from device tree. If the property is not specified, the default
driver is atmel_serial.

Signed-off-by: Radu Pirea 
---
 drivers/mfd/Kconfig  | 10 
 drivers/mfd/Makefile |  1 +
 drivers/mfd/at91-usart.c | 81 
 include/dt-bindings/mfd/at91-usart.h | 17 ++
 4 files changed, 109 insertions(+)
 create mode 100644 drivers/mfd/at91-usart.c
 create mode 100644 include/dt-bindings/mfd/at91-usart.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b860eb5aa194..de99b79061b7 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -99,6 +99,16 @@ config MFD_AAT2870_CORE
  additional drivers must be enabled in order to use the
  functionality of the device.
 
+config MFD_AT91_USART
+   tristate "AT91 USART Driver"
+   select MFD_CORE
+   depends on OF
+   help
+ Select this to get support for AT91 USART IP. This is a wrapper
+ over at91-usart-serial driver and usart-spi-driver. Only one function
+ can be used at a time. The choice is done at boot time by the probe
+ function of this MFD driver according to a device tree property.
+
 config MFD_ATMEL_FLEXCOM
tristate "Atmel Flexcom (Flexible Serial Communication Unit)"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index d9d2cf0d32ef..db1332aa96db 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -185,6 +185,7 @@ obj-$(CONFIG_MFD_SPMI_PMIC) += qcom-spmi-pmic.o
 obj-$(CONFIG_TPS65911_COMPARATOR)  += tps65911-comparator.o
 obj-$(CONFIG_MFD_TPS65090) += tps65090.o
 obj-$(CONFIG_MFD_AAT2870_CORE) += aat2870-core.o
+obj-$(CONFIG_MFD_AT91_USART)   += at91-usart.o
 obj-$(CONFIG_MFD_ATMEL_FLEXCOM)+= atmel-flexcom.o
 obj-$(CONFIG_MFD_ATMEL_HLCDC)  += atmel-hlcdc.o
 obj-$(CONFIG_MFD_ATMEL_SMC)+= atmel-smc.o
diff --git a/drivers/mfd/at91-usart.c b/drivers/mfd/at91-usart.c
new file mode 100644
index ..cd8f020ca7c0
--- /dev/null
+++ b/drivers/mfd/at91-usart.c
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Driver for AT91 USART
+ *
+ * Copyright (C) 2018 Microchip Technology
+ *
+ * Author: Radu Pirea 
+ *
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct mfd_cell at91_usart_spi_subdev = {
+   .name = "at91_usart_spi",
+   .of_compatible = "microchip,at91sam9g45-usart-spi",
+   };
+
+static struct mfd_cell at91_usart_serial_subdev = {
+   .name = "atmel_usart_serial",
+   .of_compatible = "atmel,at91rm9200-usart-serial",
+   };
+
+static int at91_usart_mode_probe(struct platform_device *pdev)
+{
+   struct device_node *np = pdev->dev.of_node;
+   struct mfd_cell cell;
+   u32 opmode;
+   int err;
+
+   err = of_property_read_u32(np, "at91,usart-mode", );
+
+   switch (opmode) {
+   case AT91_USART_MODE_SPI:
+   cell = at91_usart_spi_subdev;
+   break;
+   case AT91_USART_MODE_SERIAL:
+   default:
+   cell = at91_usart_serial_subdev;
+   }
+
+   err = mfd_add_devices(>dev, PLATFORM_DEVID_AUTO, , 1,
+ NULL, 0, NULL);
+   if (err) {
+   dev_err(>dev, "failed to add subdevices\n");
+   return err;
+   }
+
+   return devm_of_platform_populate(>dev);
+}
+
+static const struct of_device_id at91_usart_mode_of_match[] = {
+   { .compatible = "atmel,at91rm9200-usart" },
+   { .compatible = "atmel,at91sam9260-usart" },
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, at91_flexcom_of_match);
+
+static struct platform_driver at91_usart_mfd = {
+   .probe  = at91_usart_mode_probe,
+   .driver = {
+   .name   = "at91_usart_mode",
+   .of_match_table = at91_usart_mode_of_match,
+   },
+};
+
+module_platform_driver(at91_usart_mfd);
+
+MODULE_AUTHOR("Radu Pirea ");
+MODULE_DESCRIPTION("AT91 USART MFD driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/dt-bindings/mfd/at91-usart.h 
b/include/dt-bindings/mfd/at91-usart.h
new file mode 100644
index ..ac811628a42d
--- /dev/null
+++ b/include/dt-bindings/mfd/at91-usart.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * This header provides macros for AT91 USART DT bindings.
+ *
+ * Copyright (C) 2018 Microchip Technology
+ *
+ * Author: Radu Pirea 
+ *
+ */
+
+#ifndef __DT_BINDINGS_AT91_USART_H__
+#define __DT_BINDINGS_AT91_USART_H__
+
+#define AT91_USART_MODE_SERIAL 1
+#define AT91_USART_MODE_SPI2
+
+#endif /* __DT_BINDINGS_AT91_USART_H__ */
-- 
2.17.0

[PATCH v2 2/6] mfd: at91-usart: added mfd driver for usart

[Radu Pirea]

This mfd driver is just a wrapper over atmel_serial driver and
spi-at91-usart driver. Selection of one of the drivers is based on a
property from device tree. If the property is not specified, the default
driver is atmel_serial.

Signed-off-by: Radu Pirea 
---
 drivers/mfd/Kconfig  | 10 
 drivers/mfd/Makefile |  1 +
 drivers/mfd/at91-usart.c | 81 
 include/dt-bindings/mfd/at91-usart.h | 17 ++
 4 files changed, 109 insertions(+)
 create mode 100644 drivers/mfd/at91-usart.c
 create mode 100644 include/dt-bindings/mfd/at91-usart.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b860eb5aa194..de99b79061b7 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -99,6 +99,16 @@ config MFD_AAT2870_CORE
  additional drivers must be enabled in order to use the
  functionality of the device.
 
+config MFD_AT91_USART
+   tristate "AT91 USART Driver"
+   select MFD_CORE
+   depends on OF
+   help
+ Select this to get support for AT91 USART IP. This is a wrapper
+ over at91-usart-serial driver and usart-spi-driver. Only one function
+ can be used at a time. The choice is done at boot time by the probe
+ function of this MFD driver according to a device tree property.
+
 config MFD_ATMEL_FLEXCOM
tristate "Atmel Flexcom (Flexible Serial Communication Unit)"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index d9d2cf0d32ef..db1332aa96db 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -185,6 +185,7 @@ obj-$(CONFIG_MFD_SPMI_PMIC) += qcom-spmi-pmic.o
 obj-$(CONFIG_TPS65911_COMPARATOR)  += tps65911-comparator.o
 obj-$(CONFIG_MFD_TPS65090) += tps65090.o
 obj-$(CONFIG_MFD_AAT2870_CORE) += aat2870-core.o
+obj-$(CONFIG_MFD_AT91_USART)   += at91-usart.o
 obj-$(CONFIG_MFD_ATMEL_FLEXCOM)+= atmel-flexcom.o
 obj-$(CONFIG_MFD_ATMEL_HLCDC)  += atmel-hlcdc.o
 obj-$(CONFIG_MFD_ATMEL_SMC)+= atmel-smc.o
diff --git a/drivers/mfd/at91-usart.c b/drivers/mfd/at91-usart.c
new file mode 100644
index ..cd8f020ca7c0
--- /dev/null
+++ b/drivers/mfd/at91-usart.c
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Driver for AT91 USART
+ *
+ * Copyright (C) 2018 Microchip Technology
+ *
+ * Author: Radu Pirea 
+ *
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct mfd_cell at91_usart_spi_subdev = {
+   .name = "at91_usart_spi",
+   .of_compatible = "microchip,at91sam9g45-usart-spi",
+   };
+
+static struct mfd_cell at91_usart_serial_subdev = {
+   .name = "atmel_usart_serial",
+   .of_compatible = "atmel,at91rm9200-usart-serial",
+   };
+
+static int at91_usart_mode_probe(struct platform_device *pdev)
+{
+   struct device_node *np = pdev->dev.of_node;
+   struct mfd_cell cell;
+   u32 opmode;
+   int err;
+
+   err = of_property_read_u32(np, "at91,usart-mode", );
+
+   switch (opmode) {
+   case AT91_USART_MODE_SPI:
+   cell = at91_usart_spi_subdev;
+   break;
+   case AT91_USART_MODE_SERIAL:
+   default:
+   cell = at91_usart_serial_subdev;
+   }
+
+   err = mfd_add_devices(>dev, PLATFORM_DEVID_AUTO, , 1,
+ NULL, 0, NULL);
+   if (err) {
+   dev_err(>dev, "failed to add subdevices\n");
+   return err;
+   }
+
+   return devm_of_platform_populate(>dev);
+}
+
+static const struct of_device_id at91_usart_mode_of_match[] = {
+   { .compatible = "atmel,at91rm9200-usart" },
+   { .compatible = "atmel,at91sam9260-usart" },
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, at91_flexcom_of_match);
+
+static struct platform_driver at91_usart_mfd = {
+   .probe  = at91_usart_mode_probe,
+   .driver = {
+   .name   = "at91_usart_mode",
+   .of_match_table = at91_usart_mode_of_match,
+   },
+};
+
+module_platform_driver(at91_usart_mfd);
+
+MODULE_AUTHOR("Radu Pirea ");
+MODULE_DESCRIPTION("AT91 USART MFD driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/dt-bindings/mfd/at91-usart.h 
b/include/dt-bindings/mfd/at91-usart.h
new file mode 100644
index ..ac811628a42d
--- /dev/null
+++ b/include/dt-bindings/mfd/at91-usart.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * This header provides macros for AT91 USART DT bindings.
+ *
+ * Copyright (C) 2018 Microchip Technology
+ *
+ * Author: Radu Pirea 
+ *
+ */
+
+#ifndef __DT_BINDINGS_AT91_USART_H__
+#define __DT_BINDINGS_AT91_USART_H__
+
+#define AT91_USART_MODE_SERIAL 1
+#define AT91_USART_MODE_SPI2
+
+#endif /* __DT_BINDINGS_AT91_USART_H__ */
-- 
2.17.0

[PATCH 1/5] spinlock: atomic_dec_and_lock: Add an irqsave variant

[Sebastian Andrzej Siewior]

From: Anna-Maria Gleixner 

There are in-tree users of atomic_dec_and_lock() which must acquire the
spin lock with interrupts disabled. To workaround the lack of an irqsave
variant of atomic_dec_and_lock() they use local_irq_save() at the call
site. This causes extra code and creates in some places unneeded long
interrupt disabled times. These places need also extra treatment for
PREEMPT_RT due to the disconnect of the irq disabling and the lock
function.

Implement the missing irqsave variant of the function.

Signed-off-by: Anna-Maria Gleixner 
Signed-off-by: Sebastian Andrzej Siewior 
---
 include/linux/spinlock.h |  5 +
 lib/dec_and_lock.c   | 16 
 2 files changed, 21 insertions(+)

diff --git a/include/linux/spinlock.h b/include/linux/spinlock.h
index 4894d322d258..803536c992f5 100644
--- a/include/linux/spinlock.h
+++ b/include/linux/spinlock.h
@@ -409,6 +409,11 @@ extern int _atomic_dec_and_lock(atomic_t *atomic, 
spinlock_t *lock);
 #define atomic_dec_and_lock(atomic, lock) \
__cond_lock(lock, _atomic_dec_and_lock(atomic, lock))
 
+extern int _atomic_dec_and_lock_irqsave(atomic_t *atomic, spinlock_t *lock,
+   unsigned long *flags);
+#define atomic_dec_and_lock_irqsave(atomic, lock, flags) \
+   __cond_lock(lock, _atomic_dec_and_lock_irqsave(atomic, lock, 
&(flags)))
+
 int alloc_bucket_spinlocks(spinlock_t **locks, unsigned int *lock_mask,
   size_t max_size, unsigned int cpu_mult,
   gfp_t gfp);
diff --git a/lib/dec_and_lock.c b/lib/dec_and_lock.c
index 347fa7ac2e8a..9555b68bb774 100644
--- a/lib/dec_and_lock.c
+++ b/lib/dec_and_lock.c
@@ -33,3 +33,19 @@ int _atomic_dec_and_lock(atomic_t *atomic, spinlock_t *lock)
 }
 
 EXPORT_SYMBOL(_atomic_dec_and_lock);
+
+int _atomic_dec_and_lock_irqsave(atomic_t *atomic, spinlock_t *lock,
+unsigned long *flags)
+{
+   /* Subtract 1 from counter unless that drops it to 0 (ie. it was 1) */
+   if (atomic_add_unless(atomic, -1, 1))
+   return 0;
+
+   /* Otherwise do it the slow way */
+   spin_lock_irqsave(lock, *flags);
+   if (atomic_dec_and_test(atomic))
+   return 1;
+   spin_unlock_irqrestore(lock, *flags);
+   return 0;
+}
+EXPORT_SYMBOL(_atomic_dec_and_lock_irqsave);
-- 
2.17.0

Introduce atomic_dec_and_lock_irqsave()

[Sebastian Andrzej Siewior]

This series introduces atomic_dec_and_lock_irqsave() and converts a few
users to use it. They were using local_irq_save() +
atomic_dec_and_lock() before that series.

Sebastian

Introduce atomic_dec_and_lock_irqsave()

[Sebastian Andrzej Siewior]

This series introduces atomic_dec_and_lock_irqsave() and converts a few
users to use it. They were using local_irq_save() +
atomic_dec_and_lock() before that series.

Sebastian

[PATCH 1/5] spinlock: atomic_dec_and_lock: Add an irqsave variant

[Sebastian Andrzej Siewior]

From: Anna-Maria Gleixner 

There are in-tree users of atomic_dec_and_lock() which must acquire the
spin lock with interrupts disabled. To workaround the lack of an irqsave
variant of atomic_dec_and_lock() they use local_irq_save() at the call
site. This causes extra code and creates in some places unneeded long
interrupt disabled times. These places need also extra treatment for
PREEMPT_RT due to the disconnect of the irq disabling and the lock
function.

Implement the missing irqsave variant of the function.

Signed-off-by: Anna-Maria Gleixner 
Signed-off-by: Sebastian Andrzej Siewior 
---
 include/linux/spinlock.h |  5 +
 lib/dec_and_lock.c   | 16 
 2 files changed, 21 insertions(+)

diff --git a/include/linux/spinlock.h b/include/linux/spinlock.h
index 4894d322d258..803536c992f5 100644
--- a/include/linux/spinlock.h
+++ b/include/linux/spinlock.h
@@ -409,6 +409,11 @@ extern int _atomic_dec_and_lock(atomic_t *atomic, 
spinlock_t *lock);
 #define atomic_dec_and_lock(atomic, lock) \
__cond_lock(lock, _atomic_dec_and_lock(atomic, lock))
 
+extern int _atomic_dec_and_lock_irqsave(atomic_t *atomic, spinlock_t *lock,
+   unsigned long *flags);
+#define atomic_dec_and_lock_irqsave(atomic, lock, flags) \
+   __cond_lock(lock, _atomic_dec_and_lock_irqsave(atomic, lock, 
&(flags)))
+
 int alloc_bucket_spinlocks(spinlock_t **locks, unsigned int *lock_mask,
   size_t max_size, unsigned int cpu_mult,
   gfp_t gfp);
diff --git a/lib/dec_and_lock.c b/lib/dec_and_lock.c
index 347fa7ac2e8a..9555b68bb774 100644
--- a/lib/dec_and_lock.c
+++ b/lib/dec_and_lock.c
@@ -33,3 +33,19 @@ int _atomic_dec_and_lock(atomic_t *atomic, spinlock_t *lock)
 }
 
 EXPORT_SYMBOL(_atomic_dec_and_lock);
+
+int _atomic_dec_and_lock_irqsave(atomic_t *atomic, spinlock_t *lock,
+unsigned long *flags)
+{
+   /* Subtract 1 from counter unless that drops it to 0 (ie. it was 1) */
+   if (atomic_add_unless(atomic, -1, 1))
+   return 0;
+
+   /* Otherwise do it the slow way */
+   spin_lock_irqsave(lock, *flags);
+   if (atomic_dec_and_test(atomic))
+   return 1;
+   spin_unlock_irqrestore(lock, *flags);
+   return 0;
+}
+EXPORT_SYMBOL(_atomic_dec_and_lock_irqsave);
-- 
2.17.0

[PATCH 4/5] drivers/md/raid5: Use irqsave variant of atomic_dec_and_lock()

[Sebastian Andrzej Siewior]

From: Anna-Maria Gleixner 

The irqsave variant of atomic_dec_and_lock handles irqsave/restore when
taking/releasing the spin lock. With this variant the call of
local_irq_save is no longer required.

Signed-off-by: Anna-Maria Gleixner 
Signed-off-by: Sebastian Andrzej Siewior 
---
 drivers/md/raid5.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index be117d0a65a8..0a5e6f5d271d 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -409,16 +409,15 @@ void raid5_release_stripe(struct stripe_head *sh)
md_wakeup_thread(conf->mddev->thread);
return;
 slow_path:
-   local_irq_save(flags);
/* we are ok here if STRIPE_ON_RELEASE_LIST is set or not */
-   if (atomic_dec_and_lock(>count, >device_lock)) {
+   if (atomic_dec_and_lock_irqsave(>count, >device_lock, flags)) 
{
INIT_LIST_HEAD();
hash = sh->hash_lock_index;
do_release_stripe(conf, sh, );
spin_unlock(>device_lock);
release_inactive_stripe_list(conf, , hash);
+   local_irq_restore(flags);
}
-   local_irq_restore(flags);
 }
 
 static inline void remove_hash(struct stripe_head *sh)
-- 
2.17.0

[PATCH v2 0/6] Driver for at91 usart in spi mode

[Radu Pirea]

Hello,

This is the second version of driver. I added a mfd driver which by
default probes atmel_serial driver and if in dt is specified to probe
the spi driver, then the spi-at91-usart driver will be probed. The
compatible for atmel_serial is now the compatible for at91-usart mfd
driver and compatilbe for atmel_serial driver was changed in order to
keep the bindings for serial as they are.

Changes in v1:
- added spi-at91-usart driver

Changes in v2:
- added at91-usart mfd driver
- modified spi-at91-usart driver to work as mfd driver child
- modified atmel_serial driver to work as mfd driver child

Radu Pirea (6):
  MAINTAINERS: add at91 usart mfd driver
  mfd: at91-usart: added mfd driver for usart
  MAINTAINERS: add at91 usart spi driver
  dt-bindings: add binding for at91-usart in spi mode
  spi: at91-usart: add driver for at91-usart as spi
  tty/serial: atmel: changed the driver to work under at91-usart mfd

 .../bindings/spi/microchip,at91-usart-spi.txt |  28 +
 MAINTAINERS   |  14 +
 drivers/mfd/Kconfig   |  10 +
 drivers/mfd/Makefile  |   1 +
 drivers/mfd/at91-usart.c  |  81 +++
 drivers/spi/Kconfig   |   9 +
 drivers/spi/Makefile  |   1 +
 drivers/spi/spi-at91-usart.c  | 545 ++
 drivers/tty/serial/Kconfig|   1 +
 drivers/tty/serial/atmel_serial.c |  29 +-
 include/dt-bindings/mfd/at91-usart.h  |  17 +
 11 files changed, 722 insertions(+), 14 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
 create mode 100644 drivers/mfd/at91-usart.c
 create mode 100644 drivers/spi/spi-at91-usart.c
 create mode 100644 include/dt-bindings/mfd/at91-usart.h

-- 
2.17.0

[PATCH 4/5] drivers/md/raid5: Use irqsave variant of atomic_dec_and_lock()

[Sebastian Andrzej Siewior]

From: Anna-Maria Gleixner 

The irqsave variant of atomic_dec_and_lock handles irqsave/restore when
taking/releasing the spin lock. With this variant the call of
local_irq_save is no longer required.

Signed-off-by: Anna-Maria Gleixner 
Signed-off-by: Sebastian Andrzej Siewior 
---
 drivers/md/raid5.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index be117d0a65a8..0a5e6f5d271d 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -409,16 +409,15 @@ void raid5_release_stripe(struct stripe_head *sh)
md_wakeup_thread(conf->mddev->thread);
return;
 slow_path:
-   local_irq_save(flags);
/* we are ok here if STRIPE_ON_RELEASE_LIST is set or not */
-   if (atomic_dec_and_lock(>count, >device_lock)) {
+   if (atomic_dec_and_lock_irqsave(>count, >device_lock, flags)) 
{
INIT_LIST_HEAD();
hash = sh->hash_lock_index;
do_release_stripe(conf, sh, );
spin_unlock(>device_lock);
release_inactive_stripe_list(conf, , hash);
+   local_irq_restore(flags);
}
-   local_irq_restore(flags);
 }
 
 static inline void remove_hash(struct stripe_head *sh)
-- 
2.17.0

[PATCH v2 0/6] Driver for at91 usart in spi mode

[Radu Pirea]

Hello,

This is the second version of driver. I added a mfd driver which by
default probes atmel_serial driver and if in dt is specified to probe
the spi driver, then the spi-at91-usart driver will be probed. The
compatible for atmel_serial is now the compatible for at91-usart mfd
driver and compatilbe for atmel_serial driver was changed in order to
keep the bindings for serial as they are.

Changes in v1:
- added spi-at91-usart driver

Changes in v2:
- added at91-usart mfd driver
- modified spi-at91-usart driver to work as mfd driver child
- modified atmel_serial driver to work as mfd driver child

Radu Pirea (6):
  MAINTAINERS: add at91 usart mfd driver
  mfd: at91-usart: added mfd driver for usart
  MAINTAINERS: add at91 usart spi driver
  dt-bindings: add binding for at91-usart in spi mode
  spi: at91-usart: add driver for at91-usart as spi
  tty/serial: atmel: changed the driver to work under at91-usart mfd

 .../bindings/spi/microchip,at91-usart-spi.txt |  28 +
 MAINTAINERS   |  14 +
 drivers/mfd/Kconfig   |  10 +
 drivers/mfd/Makefile  |   1 +
 drivers/mfd/at91-usart.c  |  81 +++
 drivers/spi/Kconfig   |   9 +
 drivers/spi/Makefile  |   1 +
 drivers/spi/spi-at91-usart.c  | 545 ++
 drivers/tty/serial/Kconfig|   1 +
 drivers/tty/serial/atmel_serial.c |  29 +-
 include/dt-bindings/mfd/at91-usart.h  |  17 +
 11 files changed, 722 insertions(+), 14 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
 create mode 100644 drivers/mfd/at91-usart.c
 create mode 100644 drivers/spi/spi-at91-usart.c
 create mode 100644 include/dt-bindings/mfd/at91-usart.h

-- 
2.17.0

Re: [PATCH] Add a file named cgroup.procs_stat in cgroup

[Peter Zijlstra]

On Fri, May 04, 2018 at 10:28:20PM +0800, zhangq95 wrote:
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 5e10aae..ba969af 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -3404,11 +3404,19 @@ static void __sched notrace __schedule(bool preempt)
>   struct rq_flags rf;
>   struct rq *rq;
>   int cpu;
> + struct task_struct *prev_root = NULL, *next_root = NULL;
>  
>   cpu = smp_processor_id();
>   rq = cpu_rq(cpu);
>   prev = rq->curr;
>  
> + if (task_active_pid_ns(prev)) {
> + prev_root = task_active_pid_ns(prev)->child_reaper;
> + if (prev_root != init_pid_ns.child_reaper)
> + update_cpuacct_procs_stat(prev, prev->cpu,
> + CPUACCT_PROCS_SWITCHES, 1, 0);
> + }
> +
>   schedule_debug(prev);
>  
>   if (sched_feat(HRTICK))
> @@ -3462,6 +3470,12 @@ static void __sched notrace __schedule(bool preempt)
>   }
>  
>   next = pick_next_task(rq, prev, );
> + if (task_active_pid_ns(next)) {
> + next_root = task_active_pid_ns(next)->child_reaper;
> + if (prev_root && prev_root != next_root)
> + update_cpuacct_procs_stat(next, next->cpu,
> + CPUACCT_PROCS_SWITCHES, 1, 0);
> + }
>   clear_tsk_need_resched(prev);
>   clear_preempt_need_resched();
>  

> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 54dc31e..46adf63 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4757,6 +4774,7 @@ static void throttle_cfs_rq(struct cfs_rq *cfs_rq)
>   if (dequeue)
>   dequeue_entity(qcfs_rq, se, DEQUEUE_SLEEP);
>   qcfs_rq->h_nr_running -= task_delta;
> + update_cpuacct_running_from_cfs(qcfs_rq, -task_delta);
>  
>   if (qcfs_rq->load.weight)
>   dequeue = 0;
> @@ -4820,6 +4838,7 @@ void unthrottle_cfs_rq(struct cfs_rq *cfs_rq)
>   if (enqueue)
>   enqueue_entity(cfs_rq, se, ENQUEUE_WAKEUP);
>   cfs_rq->h_nr_running += task_delta;
> + update_cpuacct_running_from_cfs(cfs_rq, task_delta);
>  
>   if (cfs_rq_throttled(cfs_rq))
>   break;
> @@ -5379,6 +5398,7 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, 
> int flags)
>   if (cfs_rq_throttled(cfs_rq))
>   break;
>   cfs_rq->h_nr_running++;
> + update_cpuacct_running_from_cfs(cfs_rq, 1);
>  
>   flags = ENQUEUE_WAKEUP;
>   }
> @@ -5386,6 +5406,7 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, 
> int flags)
>   for_each_sched_entity(se) {
>   cfs_rq = cfs_rq_of(se);
>   cfs_rq->h_nr_running++;
> + update_cpuacct_running_from_cfs(cfs_rq, 1);
>  
>   if (cfs_rq_throttled(cfs_rq))
>   break;
> @@ -5427,6 +5448,7 @@ static void dequeue_task_fair(struct rq *rq, struct 
> task_struct *p, int flags)
>   if (cfs_rq_throttled(cfs_rq))
>   break;
>   cfs_rq->h_nr_running--;
> + update_cpuacct_running_from_cfs(cfs_rq, -1);
>  
>   /* Don't dequeue parent if it has other entities besides us */
>   if (cfs_rq->load.weight) {
> @@ -5446,6 +5468,7 @@ static void dequeue_task_fair(struct rq *rq, struct 
> task_struct *p, int flags)
>   for_each_sched_entity(se) {
>   cfs_rq = cfs_rq_of(se);
>   cfs_rq->h_nr_running--;
> + update_cpuacct_running_from_cfs(cfs_rq, -1);
>  
>   if (cfs_rq_throttled(cfs_rq))
>   break;
> diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
> index 7aef6b4..766ec16 100644
> --- a/kernel/sched/rt.c
> +++ b/kernel/sched/rt.c
> @@ -1327,6 +1327,7 @@ enqueue_task_rt(struct rq *rq, struct task_struct *p, 
> int flags)
>   rt_se->timeout = 0;
>  
>   enqueue_rt_entity(rt_se, flags);
> + update_cpuacct_procs_stat(p, cpu_of(rq), CPUACCT_PROCS_RUNNING, 1, 0);
>  
>   if (!task_current(rq, p) && p->nr_cpus_allowed > 1)
>   enqueue_pushable_task(rq, p);
> @@ -1338,6 +1339,7 @@ static void dequeue_task_rt(struct rq *rq, struct 
> task_struct *p, int flags)
>  
>   update_curr_rt(rq);
>   dequeue_rt_entity(rt_se, flags);
> + update_cpuacct_procs_stat(p, cpu_of(rq), CPUACCT_PROCS_RUNNING, -1, 0);
>  
>   dequeue_pushable_task(rq, p);
>  }


Yeah, I think not... death by accounting.

Re: [PATCH] Add a file named cgroup.procs_stat in cgroup

[Peter Zijlstra]

On Fri, May 04, 2018 at 10:28:20PM +0800, zhangq95 wrote:
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 5e10aae..ba969af 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -3404,11 +3404,19 @@ static void __sched notrace __schedule(bool preempt)
>   struct rq_flags rf;
>   struct rq *rq;
>   int cpu;
> + struct task_struct *prev_root = NULL, *next_root = NULL;
>  
>   cpu = smp_processor_id();
>   rq = cpu_rq(cpu);
>   prev = rq->curr;
>  
> + if (task_active_pid_ns(prev)) {
> + prev_root = task_active_pid_ns(prev)->child_reaper;
> + if (prev_root != init_pid_ns.child_reaper)
> + update_cpuacct_procs_stat(prev, prev->cpu,
> + CPUACCT_PROCS_SWITCHES, 1, 0);
> + }
> +
>   schedule_debug(prev);
>  
>   if (sched_feat(HRTICK))
> @@ -3462,6 +3470,12 @@ static void __sched notrace __schedule(bool preempt)
>   }
>  
>   next = pick_next_task(rq, prev, );
> + if (task_active_pid_ns(next)) {
> + next_root = task_active_pid_ns(next)->child_reaper;
> + if (prev_root && prev_root != next_root)
> + update_cpuacct_procs_stat(next, next->cpu,
> + CPUACCT_PROCS_SWITCHES, 1, 0);
> + }
>   clear_tsk_need_resched(prev);
>   clear_preempt_need_resched();
>  

> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 54dc31e..46adf63 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4757,6 +4774,7 @@ static void throttle_cfs_rq(struct cfs_rq *cfs_rq)
>   if (dequeue)
>   dequeue_entity(qcfs_rq, se, DEQUEUE_SLEEP);
>   qcfs_rq->h_nr_running -= task_delta;
> + update_cpuacct_running_from_cfs(qcfs_rq, -task_delta);
>  
>   if (qcfs_rq->load.weight)
>   dequeue = 0;
> @@ -4820,6 +4838,7 @@ void unthrottle_cfs_rq(struct cfs_rq *cfs_rq)
>   if (enqueue)
>   enqueue_entity(cfs_rq, se, ENQUEUE_WAKEUP);
>   cfs_rq->h_nr_running += task_delta;
> + update_cpuacct_running_from_cfs(cfs_rq, task_delta);
>  
>   if (cfs_rq_throttled(cfs_rq))
>   break;
> @@ -5379,6 +5398,7 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, 
> int flags)
>   if (cfs_rq_throttled(cfs_rq))
>   break;
>   cfs_rq->h_nr_running++;
> + update_cpuacct_running_from_cfs(cfs_rq, 1);
>  
>   flags = ENQUEUE_WAKEUP;
>   }
> @@ -5386,6 +5406,7 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, 
> int flags)
>   for_each_sched_entity(se) {
>   cfs_rq = cfs_rq_of(se);
>   cfs_rq->h_nr_running++;
> + update_cpuacct_running_from_cfs(cfs_rq, 1);
>  
>   if (cfs_rq_throttled(cfs_rq))
>   break;
> @@ -5427,6 +5448,7 @@ static void dequeue_task_fair(struct rq *rq, struct 
> task_struct *p, int flags)
>   if (cfs_rq_throttled(cfs_rq))
>   break;
>   cfs_rq->h_nr_running--;
> + update_cpuacct_running_from_cfs(cfs_rq, -1);
>  
>   /* Don't dequeue parent if it has other entities besides us */
>   if (cfs_rq->load.weight) {
> @@ -5446,6 +5468,7 @@ static void dequeue_task_fair(struct rq *rq, struct 
> task_struct *p, int flags)
>   for_each_sched_entity(se) {
>   cfs_rq = cfs_rq_of(se);
>   cfs_rq->h_nr_running--;
> + update_cpuacct_running_from_cfs(cfs_rq, -1);
>  
>   if (cfs_rq_throttled(cfs_rq))
>   break;
> diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
> index 7aef6b4..766ec16 100644
> --- a/kernel/sched/rt.c
> +++ b/kernel/sched/rt.c
> @@ -1327,6 +1327,7 @@ enqueue_task_rt(struct rq *rq, struct task_struct *p, 
> int flags)
>   rt_se->timeout = 0;
>  
>   enqueue_rt_entity(rt_se, flags);
> + update_cpuacct_procs_stat(p, cpu_of(rq), CPUACCT_PROCS_RUNNING, 1, 0);
>  
>   if (!task_current(rq, p) && p->nr_cpus_allowed > 1)
>   enqueue_pushable_task(rq, p);
> @@ -1338,6 +1339,7 @@ static void dequeue_task_rt(struct rq *rq, struct 
> task_struct *p, int flags)
>  
>   update_curr_rt(rq);
>   dequeue_rt_entity(rt_se, flags);
> + update_cpuacct_procs_stat(p, cpu_of(rq), CPUACCT_PROCS_RUNNING, -1, 0);
>  
>   dequeue_pushable_task(rq, p);
>  }


Yeah, I think not... death by accounting.

Re: [PATCH v2 09/10] ARM: dts: sun7i-a20: Add Video Engine and reserved memory nodes

[Maxime Ripard]

On Fri, May 04, 2018 at 03:57:48PM +0200, Paul Kocialkowski wrote:
> On Fri, 2018-05-04 at 15:40 +0200, Maxime Ripard wrote:
> > On Fri, May 04, 2018 at 02:04:38PM +0200, Paul Kocialkowski wrote:
> > > On Fri, 2018-05-04 at 11:15 +0200, Maxime Ripard wrote:
> > > > On Fri, May 04, 2018 at 10:47:44AM +0200, Paul Kocialkowski wrote:
> > > > > > > > > + reg = <0x01c0e000 0x1000>;
> > > > > > > > > + memory-region = <_memory>;
> > > > > > > > 
> > > > > > > > Since you made the CMA region the default one, you don't
> > > > > > > > need
> > > > > > > > to
> > > > > > > > tie
> > > > > > > > it to that device in particular (and you can drop it being
> > > > > > > > mandatory
> > > > > > > > from your binding as well).
> > > > > > > 
> > > > > > > What if another driver (or the system) claims memory from
> > > > > > > that
> > > > > > > zone
> > > > > > > and
> > > > > > > that the reserved memory ends up not being available for the
> > > > > > > VPU
> > > > > > > anymore?
> > > > > > > 
> > > > > > > Acccording to the reserved-memory documentation, the
> > > > > > > reusable
> > > > > > > property
> > > > > > > (that we need for dmabuf) puts a limitation that the device
> > > > > > > driver
> > > > > > > owning the region must be able to reclaim it back.
> > > > > > > 
> > > > > > > How does that work out if the CMA region is not tied to a
> > > > > > > driver
> > > > > > > in
> > > > > > > particular?
> > > > > > 
> > > > > > I'm not sure to get what you're saying. You have the property
> > > > > > linux,cma-default in your reserved region, so the behaviour
> > > > > > you
> > > > > > described is what you explicitly asked for.
> > > > > 
> > > > > My point is that I don't see how the driver can claim back (part
> > > > > of)
> > > > > the
> > > > > reserved area if the area is not explicitly attached to it.
> > > > > 
> > > > > Or is that mechanism made in a way that all drivers wishing to
> > > > > use
> > > > > the
> > > > > reserved memory area can claim it back from the system, but
> > > > > there is
> > > > > no
> > > > > priority (other than first-come first-served) for which drivers
> > > > > claims
> > > > > it back in case two want to use the same reserved region (in a
> > > > > scenario
> > > > > where there isn't enough memory to allow both drivers)?
> > > > 
> > > > This is indeed what happens. Reusable is to let the system use the
> > > > reserved memory for things like caches that can easily be dropped
> > > > when
> > > > a driver wants to use the memory in that reserved area. Once that
> > > > memory has been allocated, there's no claiming back, unless that
> > > > memory segment was freed of course.
> > > 
> > > Thanks for the clarification. So in our case, perhaps the best fit
> > > would
> > > be to make that area the default CMA pool so that we can be ensured
> > > that
> > > the whole 96 MiB is available for the VPU and that no other consumer
> > > of
> > > CMA will use it?
> > 
> > The best fit for what use case ? We already discussed this, and I
> > don't see any point in having two separate CMA regions. If you have a
> > reasonably sized region that will accomodate for both the VPU and
> > display engine, why would we want to split them?
> 
> The use case I have in mind is boilerplate use of the VPU with the
> display engine, say with DMAbuf.
> 
> It wasn't exactly clear in my memory whether we had decided that the CMA
> pool we use for the VPU should also be used for other CMA consumers (I
> realize that this is what we've been doing all along by having
> linux,cma-default; though).
> 
> The fact that the memory region will accomodate for both the display
> engine and the VPU is not straightforward IMO and I think this has to be
> an explicit choice that we take. I was under the impression that we
> chose the 96 MiB because that's what the Allwinner reference code does.
> Does the reference code also use this pool for display?

Yes

> I liked the idea of having 96 MiB fully reserved to the VPU because it
> allows us to provide a limit on the use case, such as "this guarantees N
> buffers for resolution foo in format bar". If the display engine also
> uses it, then the limit also depends on how many GEM buffers are
> allocated (unless I'm missing something).

This also guarantees that you take away a fifth of the RAM on some
boards. If we had yet another CMA pool of 64MB as is the multi_v7
defconfig, that's a third of your RAM that's gone, possibly for no
particular reason.

If we make the math, let's say that we are running a system with 4
planes used in 1080p, with 4 Bpp, in double buffering (which is
already an unlikely setup). Let's add on top of that that we're
decoding a 1080p video with 8 buffers pre-allocated with 2Bpp (in
YUV422). Which really seems extreme now :)

And we're at 80MB. My guess is that your memory bus is going to be
dead before you need to use all that memory.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)

Re: [PATCH v2 09/10] ARM: dts: sun7i-a20: Add Video Engine and reserved memory nodes

[Maxime Ripard]

On Fri, May 04, 2018 at 03:57:48PM +0200, Paul Kocialkowski wrote:
> On Fri, 2018-05-04 at 15:40 +0200, Maxime Ripard wrote:
> > On Fri, May 04, 2018 at 02:04:38PM +0200, Paul Kocialkowski wrote:
> > > On Fri, 2018-05-04 at 11:15 +0200, Maxime Ripard wrote:
> > > > On Fri, May 04, 2018 at 10:47:44AM +0200, Paul Kocialkowski wrote:
> > > > > > > > > + reg = <0x01c0e000 0x1000>;
> > > > > > > > > + memory-region = <_memory>;
> > > > > > > > 
> > > > > > > > Since you made the CMA region the default one, you don't
> > > > > > > > need
> > > > > > > > to
> > > > > > > > tie
> > > > > > > > it to that device in particular (and you can drop it being
> > > > > > > > mandatory
> > > > > > > > from your binding as well).
> > > > > > > 
> > > > > > > What if another driver (or the system) claims memory from
> > > > > > > that
> > > > > > > zone
> > > > > > > and
> > > > > > > that the reserved memory ends up not being available for the
> > > > > > > VPU
> > > > > > > anymore?
> > > > > > > 
> > > > > > > Acccording to the reserved-memory documentation, the
> > > > > > > reusable
> > > > > > > property
> > > > > > > (that we need for dmabuf) puts a limitation that the device
> > > > > > > driver
> > > > > > > owning the region must be able to reclaim it back.
> > > > > > > 
> > > > > > > How does that work out if the CMA region is not tied to a
> > > > > > > driver
> > > > > > > in
> > > > > > > particular?
> > > > > > 
> > > > > > I'm not sure to get what you're saying. You have the property
> > > > > > linux,cma-default in your reserved region, so the behaviour
> > > > > > you
> > > > > > described is what you explicitly asked for.
> > > > > 
> > > > > My point is that I don't see how the driver can claim back (part
> > > > > of)
> > > > > the
> > > > > reserved area if the area is not explicitly attached to it.
> > > > > 
> > > > > Or is that mechanism made in a way that all drivers wishing to
> > > > > use
> > > > > the
> > > > > reserved memory area can claim it back from the system, but
> > > > > there is
> > > > > no
> > > > > priority (other than first-come first-served) for which drivers
> > > > > claims
> > > > > it back in case two want to use the same reserved region (in a
> > > > > scenario
> > > > > where there isn't enough memory to allow both drivers)?
> > > > 
> > > > This is indeed what happens. Reusable is to let the system use the
> > > > reserved memory for things like caches that can easily be dropped
> > > > when
> > > > a driver wants to use the memory in that reserved area. Once that
> > > > memory has been allocated, there's no claiming back, unless that
> > > > memory segment was freed of course.
> > > 
> > > Thanks for the clarification. So in our case, perhaps the best fit
> > > would
> > > be to make that area the default CMA pool so that we can be ensured
> > > that
> > > the whole 96 MiB is available for the VPU and that no other consumer
> > > of
> > > CMA will use it?
> > 
> > The best fit for what use case ? We already discussed this, and I
> > don't see any point in having two separate CMA regions. If you have a
> > reasonably sized region that will accomodate for both the VPU and
> > display engine, why would we want to split them?
> 
> The use case I have in mind is boilerplate use of the VPU with the
> display engine, say with DMAbuf.
> 
> It wasn't exactly clear in my memory whether we had decided that the CMA
> pool we use for the VPU should also be used for other CMA consumers (I
> realize that this is what we've been doing all along by having
> linux,cma-default; though).
> 
> The fact that the memory region will accomodate for both the display
> engine and the VPU is not straightforward IMO and I think this has to be
> an explicit choice that we take. I was under the impression that we
> chose the 96 MiB because that's what the Allwinner reference code does.
> Does the reference code also use this pool for display?

Yes

> I liked the idea of having 96 MiB fully reserved to the VPU because it
> allows us to provide a limit on the use case, such as "this guarantees N
> buffers for resolution foo in format bar". If the display engine also
> uses it, then the limit also depends on how many GEM buffers are
> allocated (unless I'm missing something).

This also guarantees that you take away a fifth of the RAM on some
boards. If we had yet another CMA pool of 64MB as is the multi_v7
defconfig, that's a third of your RAM that's gone, possibly for no
particular reason.

If we make the math, let's say that we are running a system with 4
planes used in 1080p, with 4 Bpp, in double buffering (which is
already an unlikely setup). Let's add on top of that that we're
decoding a 1080p video with 8 buffers pre-allocated with 2Bpp (in
YUV422). Which really seems extreme now :)

And we're at 80MB. My guess is that your memory bus is going to be
dead before you need to use all that memory.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)

[PATCH] sched/numa: Stagger NUMA balancing scan periods for new threads v2

[Mel Gorman]

Changelog since v1
o Cosmetic changes and documentation (ingo)
o Note results were very similar to v1 and so I didn't update the changelog

Threads share an address space and each can change the protections of the
same address space to trap NUMA faults. This is redundant and potentially
counter-productive as any thread doing the update will suffice. Potentially
only one thread is required but that thread may be idle or it may not have
any locality concerns and pick an unsuitable scan rate.

This patch uses independent scan period but they are staggered based on
the number of address space users when the thread is created.  The intent
is that threads will avoid scanning at the same time and have a chance
to adapt their scan rate later if necessary. This reduces the total scan
activity early in the lifetime of the threads.

The different in headline performance across a range of machines and
workloads is marginal but the system CPU usage is reduced as well as overall
scan activity.  The following is the time reported by NAS Parallel Benchmark
using unbound openmp threads and a D size class.

  4.17.0-rc1 4.17.0-rc1
 vanilla   stagger-v1r1
Time bt.D  442.77 (   0.00%)  419.70 (   5.21%)
Time cg.D  171.90 (   0.00%)  180.85 (  -5.21%)
Time ep.D   33.10 (   0.00%)   32.90 (   0.60%)
Time is.D9.59 (   0.00%)9.42 (   1.77%)
Time lu.D  306.75 (   0.00%)  304.65 (   0.68%)
Time mg.D   54.56 (   0.00%)   52.38 (   4.00%)
Time sp.D 1020.03 (   0.00%)  903.77 (  11.40%)
Time ua.D  400.58 (   0.00%)  386.49 (   3.52%)

Note it's not a universal win but we have no prior knowledge of which
thread matters but the number of threads created often exceeds the size
of the node when the threads are not bound. However, there is a reducation
of overall system CPU usage

4.17.0-rc1 4.17.0-rc1
   vanilla   stagger-v1r1
sys-time-bt.D 48.78 (   0.00%)   48.22 (   1.15%)
sys-time-cg.D 25.31 (   0.00%)   26.63 (  -5.22%)
sys-time-ep.D  1.65 (   0.00%)0.62 (  62.42%)
sys-time-is.D 40.05 (   0.00%)   24.45 (  38.95%)
sys-time-lu.D 37.55 (   0.00%)   29.02 (  22.72%)
sys-time-mg.D 47.52 (   0.00%)   34.92 (  26.52%)
sys-time-sp.D119.01 (   0.00%)  109.05 (   8.37%)
sys-time-ua.D 51.52 (   0.00%)   45.13 (  12.40%)

NUMA scan activity is also reduced

NUMA alloc local   1042828 1342670
NUMA base PTE updates14048113893577468
NUMA huge PMD updates   272171  180766
NUMA page range updates  279832690   186129660
NUMA hint faults   1395972 1193897
NUMA hint local faults  877925  855053
NUMA hint local percent 62  71
NUMA pages migrated   12057909 9158023

Similar observations are made for other thread-intensive workloads. System
CPU usage is lower even though the headline gains in performance tend to be
small. For example, specjbb 2005 shows almost no difference in performance
but scan activity is reduced by a third on a 4-socket box. I didn't find
a workload (thread intensive or otherwise) that suffered badly.

Signed-off-by: Mel Gorman 
---
 kernel/sched/core.c  | 22 +-
 kernel/sched/fair.c  | 41 +
 kernel/sched/sched.h |  6 ++
 3 files changed, 48 insertions(+), 21 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 5e10aaeebfcc..9f47d6c3e386 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2174,27 +2174,7 @@ static void __sched_fork(unsigned long clone_flags, 
struct task_struct *p)
INIT_HLIST_HEAD(>preempt_notifiers);
 #endif
 
-#ifdef CONFIG_NUMA_BALANCING
-   if (p->mm && atomic_read(>mm->mm_users) == 1) {
-   p->mm->numa_next_scan = jiffies + 
msecs_to_jiffies(sysctl_numa_balancing_scan_delay);
-   p->mm->numa_scan_seq = 0;
-   }
-
-   if (clone_flags & CLONE_VM)
-   p->numa_preferred_nid = current->numa_preferred_nid;
-   else
-   p->numa_preferred_nid = -1;
-
-   p->node_stamp = 0ULL;
-   p->numa_scan_seq = p->mm ? p->mm->numa_scan_seq : 0;
-   p->numa_scan_period = sysctl_numa_balancing_scan_delay;
-   p->numa_work.next = >numa_work;
-   p->numa_faults = NULL;
-   p->last_task_numa_placement = 0;
-   p->last_sum_exec_runtime = 0;
-
-   p->numa_group = NULL;
-#endif /* CONFIG_NUMA_BALANCING */
+   init_numa_balancing(clone_flags, p);
 }
 
 DEFINE_STATIC_KEY_FALSE(sched_numa_balancing);
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 54dc31e7ab9b..a009c4b4f3a9 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1139,6 +1139,47 @@ static unsigned int 

[PATCH] sched/numa: Stagger NUMA balancing scan periods for new threads v2

[Mel Gorman]

Changelog since v1
o Cosmetic changes and documentation (ingo)
o Note results were very similar to v1 and so I didn't update the changelog

Threads share an address space and each can change the protections of the
same address space to trap NUMA faults. This is redundant and potentially
counter-productive as any thread doing the update will suffice. Potentially
only one thread is required but that thread may be idle or it may not have
any locality concerns and pick an unsuitable scan rate.

This patch uses independent scan period but they are staggered based on
the number of address space users when the thread is created.  The intent
is that threads will avoid scanning at the same time and have a chance
to adapt their scan rate later if necessary. This reduces the total scan
activity early in the lifetime of the threads.

The different in headline performance across a range of machines and
workloads is marginal but the system CPU usage is reduced as well as overall
scan activity.  The following is the time reported by NAS Parallel Benchmark
using unbound openmp threads and a D size class.

  4.17.0-rc1 4.17.0-rc1
 vanilla   stagger-v1r1
Time bt.D  442.77 (   0.00%)  419.70 (   5.21%)
Time cg.D  171.90 (   0.00%)  180.85 (  -5.21%)
Time ep.D   33.10 (   0.00%)   32.90 (   0.60%)
Time is.D9.59 (   0.00%)9.42 (   1.77%)
Time lu.D  306.75 (   0.00%)  304.65 (   0.68%)
Time mg.D   54.56 (   0.00%)   52.38 (   4.00%)
Time sp.D 1020.03 (   0.00%)  903.77 (  11.40%)
Time ua.D  400.58 (   0.00%)  386.49 (   3.52%)

Note it's not a universal win but we have no prior knowledge of which
thread matters but the number of threads created often exceeds the size
of the node when the threads are not bound. However, there is a reducation
of overall system CPU usage

4.17.0-rc1 4.17.0-rc1
   vanilla   stagger-v1r1
sys-time-bt.D 48.78 (   0.00%)   48.22 (   1.15%)
sys-time-cg.D 25.31 (   0.00%)   26.63 (  -5.22%)
sys-time-ep.D  1.65 (   0.00%)0.62 (  62.42%)
sys-time-is.D 40.05 (   0.00%)   24.45 (  38.95%)
sys-time-lu.D 37.55 (   0.00%)   29.02 (  22.72%)
sys-time-mg.D 47.52 (   0.00%)   34.92 (  26.52%)
sys-time-sp.D119.01 (   0.00%)  109.05 (   8.37%)
sys-time-ua.D 51.52 (   0.00%)   45.13 (  12.40%)

NUMA scan activity is also reduced

NUMA alloc local   1042828 1342670
NUMA base PTE updates14048113893577468
NUMA huge PMD updates   272171  180766
NUMA page range updates  279832690   186129660
NUMA hint faults   1395972 1193897
NUMA hint local faults  877925  855053
NUMA hint local percent 62  71
NUMA pages migrated   12057909 9158023

Similar observations are made for other thread-intensive workloads. System
CPU usage is lower even though the headline gains in performance tend to be
small. For example, specjbb 2005 shows almost no difference in performance
but scan activity is reduced by a third on a 4-socket box. I didn't find
a workload (thread intensive or otherwise) that suffered badly.

Signed-off-by: Mel Gorman 
---
 kernel/sched/core.c  | 22 +-
 kernel/sched/fair.c  | 41 +
 kernel/sched/sched.h |  6 ++
 3 files changed, 48 insertions(+), 21 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 5e10aaeebfcc..9f47d6c3e386 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2174,27 +2174,7 @@ static void __sched_fork(unsigned long clone_flags, 
struct task_struct *p)
INIT_HLIST_HEAD(>preempt_notifiers);
 #endif
 
-#ifdef CONFIG_NUMA_BALANCING
-   if (p->mm && atomic_read(>mm->mm_users) == 1) {
-   p->mm->numa_next_scan = jiffies + 
msecs_to_jiffies(sysctl_numa_balancing_scan_delay);
-   p->mm->numa_scan_seq = 0;
-   }
-
-   if (clone_flags & CLONE_VM)
-   p->numa_preferred_nid = current->numa_preferred_nid;
-   else
-   p->numa_preferred_nid = -1;
-
-   p->node_stamp = 0ULL;
-   p->numa_scan_seq = p->mm ? p->mm->numa_scan_seq : 0;
-   p->numa_scan_period = sysctl_numa_balancing_scan_delay;
-   p->numa_work.next = >numa_work;
-   p->numa_faults = NULL;
-   p->last_task_numa_placement = 0;
-   p->last_sum_exec_runtime = 0;
-
-   p->numa_group = NULL;
-#endif /* CONFIG_NUMA_BALANCING */
+   init_numa_balancing(clone_flags, p);
 }
 
 DEFINE_STATIC_KEY_FALSE(sched_numa_balancing);
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 54dc31e7ab9b..a009c4b4f3a9 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1139,6 +1139,47 @@ static unsigned int task_scan_max(struct task_struct *p)

Re: [PATCH] init/main.c: simplify repair_env_string

[Steven Rostedt]

Cleaning out my INBOX, I stumbled across this old patch.

On Fri, 15 Dec 2017 22:33:17 +0100
Michal Suchanek  wrote:

> Quoting characters are now removed from the parameter so value always
> follows directly after the NUL terminating parameter name.
> 
> Signed-off-by: Michal Suchanek 
> ---
>  init/main.c | 13 -
>  1 file changed, 4 insertions(+), 9 deletions(-)
> 
> Since the previous "[PATCH v9 3/8] lib/cmdline.c: add backslash support to
> kernel commandline parsing" adds the memmove in lib/cmdline.c it is now
> superfluous in init/main.c

I don't believe the above patches were ever applied. Were they?

-- Steve

> 
> diff --git a/init/main.c b/init/main.c
> index 1f5fdedbb293..1e5b1dc940d9 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -244,15 +244,10 @@ static int __init repair_env_string(char *param, char 
> *val,
>   const char *unused, void *arg)
>  {
>   if (val) {
> - /* param=val or param="val"? */
> - if (val == param+strlen(param)+1)
> - val[-1] = '=';
> - else if (val == param+strlen(param)+2) {
> - val[-2] = '=';
> - memmove(val-1, val, strlen(val)+1);
> - val--;
> - } else
> - BUG();
> + int parm_len = strlen(param);
> +
> + param[parm_len] = '=';
> + BUG_ON(val != param + parm_len + 1);
>   }
>   return 0;
>  }

Re: [PATCH] init/main.c: simplify repair_env_string

[Steven Rostedt]

Cleaning out my INBOX, I stumbled across this old patch.

On Fri, 15 Dec 2017 22:33:17 +0100
Michal Suchanek  wrote:

> Quoting characters are now removed from the parameter so value always
> follows directly after the NUL terminating parameter name.
> 
> Signed-off-by: Michal Suchanek 
> ---
>  init/main.c | 13 -
>  1 file changed, 4 insertions(+), 9 deletions(-)
> 
> Since the previous "[PATCH v9 3/8] lib/cmdline.c: add backslash support to
> kernel commandline parsing" adds the memmove in lib/cmdline.c it is now
> superfluous in init/main.c

I don't believe the above patches were ever applied. Were they?

-- Steve

> 
> diff --git a/init/main.c b/init/main.c
> index 1f5fdedbb293..1e5b1dc940d9 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -244,15 +244,10 @@ static int __init repair_env_string(char *param, char 
> *val,
>   const char *unused, void *arg)
>  {
>   if (val) {
> - /* param=val or param="val"? */
> - if (val == param+strlen(param)+1)
> - val[-1] = '=';
> - else if (val == param+strlen(param)+2) {
> - val[-2] = '=';
> - memmove(val-1, val, strlen(val)+1);
> - val--;
> - } else
> - BUG();
> + int parm_len = strlen(param);
> +
> + param[parm_len] = '=';
> + BUG_ON(val != param + parm_len + 1);
>   }
>   return 0;
>  }

Re: [PATCH 2/3] include/linux/gfp.h: use unsigned int in gfp_zone

[Matthew Wilcox]

On Fri, May 04, 2018 at 03:35:33PM +0200, Michal Hocko wrote:
> On Fri 04-05-18 14:52:08, Huaisheng Ye wrote:
> > Suggest using unsigned int instead of int for bit within gfp_zone.
> > @@ -401,7 +401,7 @@ static inline bool gfpflags_allow_blocking(const gfp_t 
> > gfp_flags)
> >  static inline enum zone_type gfp_zone(gfp_t flags)
> >  {
> > enum zone_type z;
> > -   int bit = (__force int) (flags & GFP_ZONEMASK);
> > +   unsigned int bit = (__force unsigned int) (flags & GFP_ZONEMASK);
> >  
> > z = (GFP_ZONE_TABLE >> (bit * GFP_ZONES_SHIFT)) &
> >  ((1 << GFP_ZONES_SHIFT) - 1);

That reminds me.  I wanted to talk about getting rid of GFP_ZONE_TABLE.
Instead, we should encode the zone number in the bottom three bits of
the gfp mask, while preserving the rules that ZONE_NORMAL gets encoded
as zero (so GFP_KERNEL | GFP_HIGHMEM continues to work) and also leaving
__GFP_MOVABLE in bit 3 so that it can continue to be used as a flag.

So I was thinking ...

-#define ___GFP_DMA 0x01u
-#define ___GFP_HIGHMEM 0x02u
-#define ___GFP_DMA32   0x04u
+#define ___GFP_ZONE_MASK   0x07u

#define __GFP_DMA   ((__force gfp_t)OPT_ZONE_DMA ^ ZONE_NORMAL)
#define __GFP_HIGHMEM   ((__force gfp_t)OPT_ZONE_HIGHMEM ^ ZONE_NORMAL)
#define __GFP_DMA32 ((__force gfp_t)OPT_ZONE_DMA32 ^ ZONE_NORMAL)
#define __GFP_MOVABLE   ((__force gfp_t)ZONE_MOVABLE ^ ZONE_NORMAL | \
 ___GFP_MOVABLE)
#define GFP_ZONEMASK((__force gfp_t)___GFP_ZONE_MASK | ___GFP_MOVABLE)

Then we can delete GFP_ZONE_TABLE and GFP_ZONE_BAD.
gfp_zone simply becomes:

static inline enum zone_type gfp_zone(gfp_t flags)
{
return ((__force int)flags & ___GFP_ZONE_MASK) ^ ZONE_NORMAL;
}

Huaisheng Ye, would you have time to investigate this idea?

Re: [PATCH 2/3] include/linux/gfp.h: use unsigned int in gfp_zone

[Matthew Wilcox]

On Fri, May 04, 2018 at 03:35:33PM +0200, Michal Hocko wrote:
> On Fri 04-05-18 14:52:08, Huaisheng Ye wrote:
> > Suggest using unsigned int instead of int for bit within gfp_zone.
> > @@ -401,7 +401,7 @@ static inline bool gfpflags_allow_blocking(const gfp_t 
> > gfp_flags)
> >  static inline enum zone_type gfp_zone(gfp_t flags)
> >  {
> > enum zone_type z;
> > -   int bit = (__force int) (flags & GFP_ZONEMASK);
> > +   unsigned int bit = (__force unsigned int) (flags & GFP_ZONEMASK);
> >  
> > z = (GFP_ZONE_TABLE >> (bit * GFP_ZONES_SHIFT)) &
> >  ((1 << GFP_ZONES_SHIFT) - 1);

That reminds me.  I wanted to talk about getting rid of GFP_ZONE_TABLE.
Instead, we should encode the zone number in the bottom three bits of
the gfp mask, while preserving the rules that ZONE_NORMAL gets encoded
as zero (so GFP_KERNEL | GFP_HIGHMEM continues to work) and also leaving
__GFP_MOVABLE in bit 3 so that it can continue to be used as a flag.

So I was thinking ...

-#define ___GFP_DMA 0x01u
-#define ___GFP_HIGHMEM 0x02u
-#define ___GFP_DMA32   0x04u
+#define ___GFP_ZONE_MASK   0x07u

#define __GFP_DMA   ((__force gfp_t)OPT_ZONE_DMA ^ ZONE_NORMAL)
#define __GFP_HIGHMEM   ((__force gfp_t)OPT_ZONE_HIGHMEM ^ ZONE_NORMAL)
#define __GFP_DMA32 ((__force gfp_t)OPT_ZONE_DMA32 ^ ZONE_NORMAL)
#define __GFP_MOVABLE   ((__force gfp_t)ZONE_MOVABLE ^ ZONE_NORMAL | \
 ___GFP_MOVABLE)
#define GFP_ZONEMASK((__force gfp_t)___GFP_ZONE_MASK | ___GFP_MOVABLE)

Then we can delete GFP_ZONE_TABLE and GFP_ZONE_BAD.
gfp_zone simply becomes:

static inline enum zone_type gfp_zone(gfp_t flags)
{
return ((__force int)flags & ___GFP_ZONE_MASK) ^ ZONE_NORMAL;
}

Huaisheng Ye, would you have time to investigate this idea?

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

[Randy Dunlap]

On 05/03/2018 09:17 PM, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build
> (x86_64_allmodconfig) produced this warning:
> 
> drivers/block/zram/zram_drv.c: In function 'read_block_state':
> drivers/block/zram/zram_drv.c:674:16: warning: format '%llu' expects argument 
> of type 'long long unsigned int', but argument 5 has type '__kernel_time_t 
> {aka long int}' [-Wformat=]
> "%12lu %12llu.%06lu %c%c%c\n",
>~^
>%12lu
> (unsigned long)index, ts.tv_sec,
>   ~
> 
> Introduced by commit
> 
>   827c7dbda8eb ("zram-introduce-zram-memory-tracking-update-fix-fix")
> 

typedef __s64 time64_t;

struct timespec64 {
time64_ttv_sec; /* seconds */
longtv_nsec;/* nanoseconds */
};

time64_t is signed. Also, %lu on i386 et al is for 32-bit longs.
I guess that "we" will need to cast ts.tv_sec to (s64) and use %lld to print it
in order to satisfy other $arch.

Andrew, want to add a fix-fix-fix patch?

-- 
~Randy

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

[Randy Dunlap]

On 05/03/2018 09:17 PM, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build
> (x86_64_allmodconfig) produced this warning:
> 
> drivers/block/zram/zram_drv.c: In function 'read_block_state':
> drivers/block/zram/zram_drv.c:674:16: warning: format '%llu' expects argument 
> of type 'long long unsigned int', but argument 5 has type '__kernel_time_t 
> {aka long int}' [-Wformat=]
> "%12lu %12llu.%06lu %c%c%c\n",
>~^
>%12lu
> (unsigned long)index, ts.tv_sec,
>   ~
> 
> Introduced by commit
> 
>   827c7dbda8eb ("zram-introduce-zram-memory-tracking-update-fix-fix")
> 

typedef __s64 time64_t;

struct timespec64 {
time64_ttv_sec; /* seconds */
longtv_nsec;/* nanoseconds */
};

time64_t is signed. Also, %lu on i386 et al is for 32-bit longs.
I guess that "we" will need to cast ts.tv_sec to (s64) and use %lld to print it
in order to satisfy other $arch.

Andrew, want to add a fix-fix-fix patch?

-- 
~Randy

Re: [PATCH] i2c: core-smbus: fix a potential uninitialization bug

[Peter Rosin]

On 2018-05-04 16:59, Wenwen Wang wrote:
> On Fri, May 4, 2018 at 2:27 AM, Peter Rosin  wrote:
>> On 2018-05-04 09:17, Wenwen Wang wrote:
>>> On Fri, May 4, 2018 at 1:49 AM, Peter Rosin  wrote:
 On 2018-05-04 07:28, Wenwen Wang wrote:
> On Fri, May 4, 2018 at 12:04 AM, Peter Rosin  wrote:
>> On 2018-05-04 06:08, Wenwen Wang wrote:
>>> On Thu, May 3, 2018 at 3:34 PM, Peter Rosin  wrote:
 On 2018-05-03 00:36, Wenwen Wang wrote:
> In i2c_smbus_xfer_emulated(), there are two buffers: msgbuf0 and 
> msgbuf1,
> which are used to save a series of messages, as mentioned in the 
> comment.
> According to the value of the variable "size", msgbuf0 is initialized 
> to
> various values. In contrast, msgbuf1 is left uninitialized until the
> function i2c_transfer() is invoked. However, mgsbuf1 is not always
> initialized on all possible execution paths (implementation) of
> i2c_transfer(). Thus, it is possible that mgsbuf1 may still not be

 double negation here

> uninitialized even after the invocation of the function 
> i2c_transfer(). In
> the following execution, the uninitialized msgbuf1 will be used, such 
> as
> for security checks. Since uninitialized values can be random and
> arbitrary, this will cause undefined behaviors or even check bypass. 
> For
> example, it is expected that if the value of "size" is
> I2C_SMBUS_BLOCK_PROC_CALL, the value of data->block[0] should not be 
> larger
> than I2C_SMBUS_BLOCK_MAX. But, at the end of 
> i2c_smbus_xfer_emulated(), the
> value read from msgbuf1 is assigned to data->block[0], which can
> potentially lead to invalid block write size, as demonstrated in the 
> error
> message.
>
> This patch simply initializes the buffer msgbuf1 with 0 to avoid 
> undefined
> behaviors or security issues.
>
> Signed-off-by: Wenwen Wang 
> ---
>  drivers/i2c/i2c-core-smbus.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/i2c-core-smbus.c 
> b/drivers/i2c/i2c-core-smbus.c
> index b5aec33..0fcca75 100644
> --- a/drivers/i2c/i2c-core-smbus.c
> +++ b/drivers/i2c/i2c-core-smbus.c
> @@ -324,7 +324,7 @@ static s32 i2c_smbus_xfer_emulated(struct 
> i2c_adapter *adapter, u16 addr,
>* somewhat simpler.
>*/
>   unsigned char msgbuf0[I2C_SMBUS_BLOCK_MAX+3];
> - unsigned char msgbuf1[I2C_SMBUS_BLOCK_MAX+2];
> + unsigned char msgbuf1[I2C_SMBUS_BLOCK_MAX+2] = {0};

 I think this will result in the whole of msgbuf1 being filled with 
 zeroes.
 It might be cheaper to do this with code proper rather than with an
 initializer?
>>>
>>> Thanks for your comment, Peter!  How about using a memset() only when
>>> i2c_smbus_xfer_emulated() emulates reading commands, since msgbuf1 is
>>> used only in that case?
>>
>> I was thinking that an assignment of
>>
>> msgbuf1[0] = 0;
>>
>> would be enough in the I2C_SMBUS_BLOCK_DATA and I2C_SMBUS_BLOCK_PROC_CALL
>> cases before the i2c_transfer call. However, this will only kick in if
>> the call to kzalloc fails (and it most likely will not) in the call to 
>> the
>> i2c_smbus_try_get_dmabuf helper. So, this thing that you are trying to 
>> fix
>> seems like a non-issue to me.
>>
>> However, while looking I think the bigger problem with that function is 
>> that
>> it considers all non-negative return values from i2c_transfer as 
>> good.
>> IMHO, it should barf on any return values <> num. Or at the very least
>> describe why a partial result is considered OK...
>>
>> Cheers,
>> Peter
>>

 Cheers,
 Peter

>   int num = read_write == I2C_SMBUS_READ ? 2 : 1;
>   int i;
>   u8 partial_pec = 0;
>

>>
>
> Yes, it is a big issue if the return value from i2c_transfer() is not
> equal to num. I can add a check like this:
>
> if (status != num)
>   return -EINVAL;
>

 Right, but make sure to add it *after* the existing "if (status < 0)"
 check as we want to preserve any existing error. Also, -EIO is perhaps
 more appropriate than -EINVAL which seems wrong for what is probably
 a runtime incident.

>>>
>>> Sure, I will place it after the existing check and replace -EINVAL with 
>>> -EIO.
>>>
> Also, I wonder why msgbuf1 is necessary if it is replaced by kzalloc
> in i2c_smbus_try_get_dmabuf()?

 

Re: [PATCH] i2c: core-smbus: fix a potential uninitialization bug

[Peter Rosin]

On 2018-05-04 16:59, Wenwen Wang wrote:
> On Fri, May 4, 2018 at 2:27 AM, Peter Rosin  wrote:
>> On 2018-05-04 09:17, Wenwen Wang wrote:
>>> On Fri, May 4, 2018 at 1:49 AM, Peter Rosin  wrote:
 On 2018-05-04 07:28, Wenwen Wang wrote:
> On Fri, May 4, 2018 at 12:04 AM, Peter Rosin  wrote:
>> On 2018-05-04 06:08, Wenwen Wang wrote:
>>> On Thu, May 3, 2018 at 3:34 PM, Peter Rosin  wrote:
 On 2018-05-03 00:36, Wenwen Wang wrote:
> In i2c_smbus_xfer_emulated(), there are two buffers: msgbuf0 and 
> msgbuf1,
> which are used to save a series of messages, as mentioned in the 
> comment.
> According to the value of the variable "size", msgbuf0 is initialized 
> to
> various values. In contrast, msgbuf1 is left uninitialized until the
> function i2c_transfer() is invoked. However, mgsbuf1 is not always
> initialized on all possible execution paths (implementation) of
> i2c_transfer(). Thus, it is possible that mgsbuf1 may still not be

 double negation here

> uninitialized even after the invocation of the function 
> i2c_transfer(). In
> the following execution, the uninitialized msgbuf1 will be used, such 
> as
> for security checks. Since uninitialized values can be random and
> arbitrary, this will cause undefined behaviors or even check bypass. 
> For
> example, it is expected that if the value of "size" is
> I2C_SMBUS_BLOCK_PROC_CALL, the value of data->block[0] should not be 
> larger
> than I2C_SMBUS_BLOCK_MAX. But, at the end of 
> i2c_smbus_xfer_emulated(), the
> value read from msgbuf1 is assigned to data->block[0], which can
> potentially lead to invalid block write size, as demonstrated in the 
> error
> message.
>
> This patch simply initializes the buffer msgbuf1 with 0 to avoid 
> undefined
> behaviors or security issues.
>
> Signed-off-by: Wenwen Wang 
> ---
>  drivers/i2c/i2c-core-smbus.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/i2c-core-smbus.c 
> b/drivers/i2c/i2c-core-smbus.c
> index b5aec33..0fcca75 100644
> --- a/drivers/i2c/i2c-core-smbus.c
> +++ b/drivers/i2c/i2c-core-smbus.c
> @@ -324,7 +324,7 @@ static s32 i2c_smbus_xfer_emulated(struct 
> i2c_adapter *adapter, u16 addr,
>* somewhat simpler.
>*/
>   unsigned char msgbuf0[I2C_SMBUS_BLOCK_MAX+3];
> - unsigned char msgbuf1[I2C_SMBUS_BLOCK_MAX+2];
> + unsigned char msgbuf1[I2C_SMBUS_BLOCK_MAX+2] = {0};

 I think this will result in the whole of msgbuf1 being filled with 
 zeroes.
 It might be cheaper to do this with code proper rather than with an
 initializer?
>>>
>>> Thanks for your comment, Peter!  How about using a memset() only when
>>> i2c_smbus_xfer_emulated() emulates reading commands, since msgbuf1 is
>>> used only in that case?
>>
>> I was thinking that an assignment of
>>
>> msgbuf1[0] = 0;
>>
>> would be enough in the I2C_SMBUS_BLOCK_DATA and I2C_SMBUS_BLOCK_PROC_CALL
>> cases before the i2c_transfer call. However, this will only kick in if
>> the call to kzalloc fails (and it most likely will not) in the call to 
>> the
>> i2c_smbus_try_get_dmabuf helper. So, this thing that you are trying to 
>> fix
>> seems like a non-issue to me.
>>
>> However, while looking I think the bigger problem with that function is 
>> that
>> it considers all non-negative return values from i2c_transfer as 
>> good.
>> IMHO, it should barf on any return values <> num. Or at the very least
>> describe why a partial result is considered OK...
>>
>> Cheers,
>> Peter
>>

 Cheers,
 Peter

>   int num = read_write == I2C_SMBUS_READ ? 2 : 1;
>   int i;
>   u8 partial_pec = 0;
>

>>
>
> Yes, it is a big issue if the return value from i2c_transfer() is not
> equal to num. I can add a check like this:
>
> if (status != num)
>   return -EINVAL;
>

 Right, but make sure to add it *after* the existing "if (status < 0)"
 check as we want to preserve any existing error. Also, -EIO is perhaps
 more appropriate than -EINVAL which seems wrong for what is probably
 a runtime incident.

>>>
>>> Sure, I will place it after the existing check and replace -EINVAL with 
>>> -EIO.
>>>
> Also, I wonder why msgbuf1 is necessary if it is replaced by kzalloc
> in i2c_smbus_try_get_dmabuf()?

 It is not always replaced. The stack buffer is probably retained as
 the default 

Re: [PATCH v2] perf: Suppress AUX/OVERWRITE records

[Arnaldo Carvalho de Melo]

Em Fri, May 04, 2018 at 12:35:34PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, May 04, 2018 at 03:09:59PM +0300, Alexander Shishkin escreveu:
> > On Wed, Apr 04, 2018 at 05:53:23PM +0300, Alexander Shishkin wrote:
> > > It has been pointed out to me many times that it is useful to be able
> > > to switch off AUX records to save the bandwidth for records that actually
> > > matter, for example, in AUX overwrite mode.
> > > 
> > > The usefulness of PERF_RECORD_AUX is in some of its flags, like the
> > > TRUNCATED flag that tells the decoder where exactly gaps in the trace are.
> > > The OVERWRITE flag, on the other hand will be set on every single record
> > > in overwrite mode. However, a PERF_RECORD_AUX[flags=OVERWRITE] is
> > > generated on every target task's sched_out, which over time adds up to
> > > a lot of useless information.
> > > 
> > > If any folks out there have userspace that depends on a constant stream of
> > > OVERWRITE records for a good reason, they'll have to let us know.
> > > 
> > > Signed-off-by: Alexander Shishkin 
> > > Cc: Markus Metzger 
> > > Cc: Adrian Hunter 
> > 
> > This one seems to be slipping through the cracks.
> 
> So, did you got Acked-by  or tested-by from anyone?

Yeah, tons of them, I'll pick this up

- Arnaldo

Re: [PATCH v2] perf: Suppress AUX/OVERWRITE records

[Arnaldo Carvalho de Melo]

Em Fri, May 04, 2018 at 12:35:34PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, May 04, 2018 at 03:09:59PM +0300, Alexander Shishkin escreveu:
> > On Wed, Apr 04, 2018 at 05:53:23PM +0300, Alexander Shishkin wrote:
> > > It has been pointed out to me many times that it is useful to be able
> > > to switch off AUX records to save the bandwidth for records that actually
> > > matter, for example, in AUX overwrite mode.
> > > 
> > > The usefulness of PERF_RECORD_AUX is in some of its flags, like the
> > > TRUNCATED flag that tells the decoder where exactly gaps in the trace are.
> > > The OVERWRITE flag, on the other hand will be set on every single record
> > > in overwrite mode. However, a PERF_RECORD_AUX[flags=OVERWRITE] is
> > > generated on every target task's sched_out, which over time adds up to
> > > a lot of useless information.
> > > 
> > > If any folks out there have userspace that depends on a constant stream of
> > > OVERWRITE records for a good reason, they'll have to let us know.
> > > 
> > > Signed-off-by: Alexander Shishkin 
> > > Cc: Markus Metzger 
> > > Cc: Adrian Hunter 
> > 
> > This one seems to be slipping through the cracks.
> 
> So, did you got Acked-by  or tested-by from anyone?

Yeah, tons of them, I'll pick this up

- Arnaldo

Re: [PATCH v2] perf: Suppress AUX/OVERWRITE records

[Arnaldo Carvalho de Melo]

Em Fri, May 04, 2018 at 03:09:59PM +0300, Alexander Shishkin escreveu:
> On Wed, Apr 04, 2018 at 05:53:23PM +0300, Alexander Shishkin wrote:
> > It has been pointed out to me many times that it is useful to be able
> > to switch off AUX records to save the bandwidth for records that actually
> > matter, for example, in AUX overwrite mode.
> > 
> > The usefulness of PERF_RECORD_AUX is in some of its flags, like the
> > TRUNCATED flag that tells the decoder where exactly gaps in the trace are.
> > The OVERWRITE flag, on the other hand will be set on every single record
> > in overwrite mode. However, a PERF_RECORD_AUX[flags=OVERWRITE] is
> > generated on every target task's sched_out, which over time adds up to
> > a lot of useless information.
> > 
> > If any folks out there have userspace that depends on a constant stream of
> > OVERWRITE records for a good reason, they'll have to let us know.
> > 
> > Signed-off-by: Alexander Shishkin 
> > Cc: Markus Metzger 
> > Cc: Adrian Hunter 
> 
> This one seems to be slipping through the cracks.

So, did you got Acked-by  or tested-by from anyone?


- Arnaldo

Re: [PATCH v2] perf: Suppress AUX/OVERWRITE records

[Arnaldo Carvalho de Melo]

Em Fri, May 04, 2018 at 03:09:59PM +0300, Alexander Shishkin escreveu:
> On Wed, Apr 04, 2018 at 05:53:23PM +0300, Alexander Shishkin wrote:
> > It has been pointed out to me many times that it is useful to be able
> > to switch off AUX records to save the bandwidth for records that actually
> > matter, for example, in AUX overwrite mode.
> > 
> > The usefulness of PERF_RECORD_AUX is in some of its flags, like the
> > TRUNCATED flag that tells the decoder where exactly gaps in the trace are.
> > The OVERWRITE flag, on the other hand will be set on every single record
> > in overwrite mode. However, a PERF_RECORD_AUX[flags=OVERWRITE] is
> > generated on every target task's sched_out, which over time adds up to
> > a lot of useless information.
> > 
> > If any folks out there have userspace that depends on a constant stream of
> > OVERWRITE records for a good reason, they'll have to let us know.
> > 
> > Signed-off-by: Alexander Shishkin 
> > Cc: Markus Metzger 
> > Cc: Adrian Hunter 
> 
> This one seems to be slipping through the cracks.

So, did you got Acked-by  or tested-by from anyone?


- Arnaldo

Re: [PATCH 2/2] mm: Add kvmalloc_ab_c and kvzalloc_struct

[Linus Torvalds]

On Fri, May 4, 2018 at 3:14 AM Matthew Wilcox  wrote:

> > In fact, the conversion I saw was buggy. You can *not* convert a
GFP_ATOMIC
> > user of kmalloc() to use kvmalloc.

> Not sure which conversion you're referring to; not one of mine, I hope?

I was thinking of the coccinelle patch in this thread, but just realized
that that actually only did it for GFP_KERNEL, so I guess it would work,
apart from the "oops, now it doesn't enforce the kmalloc limits any more"
issue.

> >   - that divide is really really expensive on many architectures.

> 'c' and 'size' are _supposed_ to be constant and get evaluated at
> compile-time.  ie you should get something like this on x86:

I guess that willalways  be true of the 'kvzalloc_struct() version that
will always use a sizeof(). I was more thinking of any bare kvalloc_ab_c()
cases, but maybe we'd discourage that to ever be used as such?

Because we definitely have things like that, ie a quick grep finds

f = kmalloc (sizeof (*f) + size*num, GFP_KERNEL);

where 'size' is not obviously a constant. There may be others, but I didn't
really try to grep any further.

Maybe they aren't common, and maybe the occasional divide doesn't matter,
but particularly if we use scripting to then catch and convert users, I
really hate the idea of "let's introduce something that is potentially much
more expensive than it needs to be".

(And the automated coccinelle scripting it's also something where we must
very much avoid then subtly lifting allocation size limits)

> > Something like
> >
> >   if (size > PAGE_SIZE)
> >return NULL;
> >   if (elem > 65535)
> >return NULL;
> >   if (offset > PAGE_SIZE)
> >return NULL;
> >   return kzalloc(size*elem+offset);
> >
> > and now you (a) guarantee it can't overflow and (b) don't make people
use
> > crazy vmalloc() allocations when they damn well shouldn't.

> I find your faith in the size of structs in the kernel touching ;-)

I *really* hope some of those examples of yours aren't allocated with
kmalloc using this pattern..

But yes, I may be naive on the sizes.

> We really have two reasons for using vmalloc -- one is "fragmentation
> currently makes it impossible to allocate enough contiguous memory
> to satisfy your needs" and the other is "this request is for too much
> memory to satisfy through the buddy allocator".  kvmalloc is normally
> (not always; see file descriptor example above) for the first kind of
> problem, but I wonder if kvmalloc() shouldn't have the same limit as
> kmalloc (2048 pages), then add a kvmalloc_large() which will not impose
> that limit check.

That would definitely solve at least one worry.

We do potentially have users which use kmalloc optimistically and do not
want to fall back to vmalloc (they'll fall back to smaller allocations
entirely), but I guess if fwe make sure to not convert any
__GFP_NOWARN/NORETRY users, that should all be ok.

But honestly, I'd rather see just kmalloc users stay as kmalloc users.

If instread of "kzvmalloc_ab_c()" you introduce the "struct size
calculation" part as a "saturating non-overflow calculation", then it
should be fairly easy to just do

   #define kzalloc_struct(p, member, n, gfp) \
  kzalloc(struct_size(p, member, n, gfp)

and you basically *know* that the only thing you changed was purely the
overflow semantics.

That also would take care of my diide worry, because now there  wouldn't be
any ab_c() calculations that might take a non-constant size. The
"struct_size()" thing would always do the sizeof.

So you'd have something like

   /* 'b' and 'c' are always constants */
   static inline sizeof_t __ab_c_saturating(size_t a, size_t b, size_t c)
   {
 if (b && n > (SIZE_MAX -c) / size)
 return SIZE_MAX;
 return a*b+c;
   }
   #define struct_size(p, member, n) \
   __ab_c_saturating(n, \
 sizeof(*(p)->member) + __must_be_array((p)->member), \
 offsetof(typeof(*(p)), member))

and then that kzalloc_struct() wrapper define above should just work.

The above is entirely untested, but it *looks* sane, and avoids all
semantic changes outside of the overflow protection. And nobody would use
that __ab_c_saturating() by mistake, I hope.

No?

   Linus

Re: [PATCH 2/2] mm: Add kvmalloc_ab_c and kvzalloc_struct

[Linus Torvalds]

On Fri, May 4, 2018 at 3:14 AM Matthew Wilcox  wrote:

> > In fact, the conversion I saw was buggy. You can *not* convert a
GFP_ATOMIC
> > user of kmalloc() to use kvmalloc.

> Not sure which conversion you're referring to; not one of mine, I hope?

I was thinking of the coccinelle patch in this thread, but just realized
that that actually only did it for GFP_KERNEL, so I guess it would work,
apart from the "oops, now it doesn't enforce the kmalloc limits any more"
issue.

> >   - that divide is really really expensive on many architectures.

> 'c' and 'size' are _supposed_ to be constant and get evaluated at
> compile-time.  ie you should get something like this on x86:

I guess that willalways  be true of the 'kvzalloc_struct() version that
will always use a sizeof(). I was more thinking of any bare kvalloc_ab_c()
cases, but maybe we'd discourage that to ever be used as such?

Because we definitely have things like that, ie a quick grep finds

f = kmalloc (sizeof (*f) + size*num, GFP_KERNEL);

where 'size' is not obviously a constant. There may be others, but I didn't
really try to grep any further.

Maybe they aren't common, and maybe the occasional divide doesn't matter,
but particularly if we use scripting to then catch and convert users, I
really hate the idea of "let's introduce something that is potentially much
more expensive than it needs to be".

(And the automated coccinelle scripting it's also something where we must
very much avoid then subtly lifting allocation size limits)

> > Something like
> >
> >   if (size > PAGE_SIZE)
> >return NULL;
> >   if (elem > 65535)
> >return NULL;
> >   if (offset > PAGE_SIZE)
> >return NULL;
> >   return kzalloc(size*elem+offset);
> >
> > and now you (a) guarantee it can't overflow and (b) don't make people
use
> > crazy vmalloc() allocations when they damn well shouldn't.

> I find your faith in the size of structs in the kernel touching ;-)

I *really* hope some of those examples of yours aren't allocated with
kmalloc using this pattern..

But yes, I may be naive on the sizes.

> We really have two reasons for using vmalloc -- one is "fragmentation
> currently makes it impossible to allocate enough contiguous memory
> to satisfy your needs" and the other is "this request is for too much
> memory to satisfy through the buddy allocator".  kvmalloc is normally
> (not always; see file descriptor example above) for the first kind of
> problem, but I wonder if kvmalloc() shouldn't have the same limit as
> kmalloc (2048 pages), then add a kvmalloc_large() which will not impose
> that limit check.

That would definitely solve at least one worry.

We do potentially have users which use kmalloc optimistically and do not
want to fall back to vmalloc (they'll fall back to smaller allocations
entirely), but I guess if fwe make sure to not convert any
__GFP_NOWARN/NORETRY users, that should all be ok.

But honestly, I'd rather see just kmalloc users stay as kmalloc users.

If instread of "kzvmalloc_ab_c()" you introduce the "struct size
calculation" part as a "saturating non-overflow calculation", then it
should be fairly easy to just do

   #define kzalloc_struct(p, member, n, gfp) \
  kzalloc(struct_size(p, member, n, gfp)

and you basically *know* that the only thing you changed was purely the
overflow semantics.

That also would take care of my diide worry, because now there  wouldn't be
any ab_c() calculations that might take a non-constant size. The
"struct_size()" thing would always do the sizeof.

So you'd have something like

   /* 'b' and 'c' are always constants */
   static inline sizeof_t __ab_c_saturating(size_t a, size_t b, size_t c)
   {
 if (b && n > (SIZE_MAX -c) / size)
 return SIZE_MAX;
 return a*b+c;
   }
   #define struct_size(p, member, n) \
   __ab_c_saturating(n, \
 sizeof(*(p)->member) + __must_be_array((p)->member), \
 offsetof(typeof(*(p)), member))

and then that kzalloc_struct() wrapper define above should just work.

The above is entirely untested, but it *looks* sane, and avoids all
semantic changes outside of the overflow protection. And nobody would use
that __ab_c_saturating() by mistake, I hope.

No?

   Linus

[PATCH] percpu_ida: Use _irqsave() instead of local_irq_save() + spin_lock

[Sebastian Andrzej Siewior]

percpu_ida() decouples disabling interrupts from the locking operations.
This breaks some assumptions if the locking operations are replaced like
they are under -RT.
The same locking can be achieved by avoiding local_irq_save() and using
spin_lock_irqsave() instead. percpu_ida_alloc() gains one more
preemption point because after unlocking the fastpath and before the
pool lock is acquired, the interrupts are briefly enabled.

Signed-off-by: Sebastian Andrzej Siewior 
---
 lib/percpu_ida.c | 63 
 1 file changed, 21 insertions(+), 42 deletions(-)

diff --git a/lib/percpu_ida.c b/lib/percpu_ida.c
index 6016f1deb1f5..9bbd9c5d375a 100644
--- a/lib/percpu_ida.c
+++ b/lib/percpu_ida.c
@@ -112,18 +112,6 @@ static inline void alloc_global_tags(struct percpu_ida 
*pool,
  min(pool->nr_free, pool->percpu_batch_size));
 }
 
-static inline unsigned alloc_local_tag(struct percpu_ida_cpu *tags)
-{
-   int tag = -ENOSPC;
-
-   spin_lock(>lock);
-   if (tags->nr_free)
-   tag = tags->freelist[--tags->nr_free];
-   spin_unlock(>lock);
-
-   return tag;
-}
-
 /**
  * percpu_ida_alloc - allocate a tag
  * @pool: pool to allocate from
@@ -147,20 +135,22 @@ int percpu_ida_alloc(struct percpu_ida *pool, int state)
DEFINE_WAIT(wait);
struct percpu_ida_cpu *tags;
unsigned long flags;
-   int tag;
+   int tag = -ENOSPC;
 
-   local_irq_save(flags);
-   tags = this_cpu_ptr(pool->tag_cpu);
+   tags = raw_cpu_ptr(pool->tag_cpu);
+   spin_lock_irqsave(>lock, flags);
 
/* Fastpath */
-   tag = alloc_local_tag(tags);
-   if (likely(tag >= 0)) {
-   local_irq_restore(flags);
+   if (likely(tags->nr_free >= 0)) {
+   tag = tags->freelist[--tags->nr_free];
+   spin_unlock_irqrestore(>lock, flags);
return tag;
}
+   spin_unlock_irqrestore(>lock, flags);
 
while (1) {
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
+   tags = this_cpu_ptr(pool->tag_cpu);
 
/*
 * prepare_to_wait() must come before steal_tags(), in case
@@ -184,8 +174,7 @@ int percpu_ida_alloc(struct percpu_ida *pool, int state)
>cpus_have_tags);
}
 
-   spin_unlock(>lock);
-   local_irq_restore(flags);
+   spin_unlock_irqrestore(>lock, flags);
 
if (tag >= 0 || state == TASK_RUNNING)
break;
@@ -196,9 +185,6 @@ int percpu_ida_alloc(struct percpu_ida *pool, int state)
}
 
schedule();
-
-   local_irq_save(flags);
-   tags = this_cpu_ptr(pool->tag_cpu);
}
if (state != TASK_RUNNING)
finish_wait(>wait, );
@@ -222,28 +208,24 @@ void percpu_ida_free(struct percpu_ida *pool, unsigned 
tag)
 
BUG_ON(tag >= pool->nr_tags);
 
-   local_irq_save(flags);
-   tags = this_cpu_ptr(pool->tag_cpu);
+   tags = raw_cpu_ptr(pool->tag_cpu);
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
tags->freelist[tags->nr_free++] = tag;
 
nr_free = tags->nr_free;
-   spin_unlock(>lock);
 
if (nr_free == 1) {
cpumask_set_cpu(smp_processor_id(),
>cpus_have_tags);
wake_up(>wait);
}
+   spin_unlock_irqrestore(>lock, flags);
 
if (nr_free == pool->percpu_max_size) {
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
+   spin_lock(>lock);
 
-   /*
-* Global lock held and irqs disabled, don't need percpu
-* lock
-*/
if (tags->nr_free == pool->percpu_max_size) {
move_tags(pool->freelist, >nr_free,
  tags->freelist, >nr_free,
@@ -251,10 +233,9 @@ void percpu_ida_free(struct percpu_ida *pool, unsigned tag)
 
wake_up(>wait);
}
-   spin_unlock(>lock);
+   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);
}
-
-   local_irq_restore(flags);
 }
 EXPORT_SYMBOL_GPL(percpu_ida_free);
 
@@ -346,29 +327,27 @@ int percpu_ida_for_each_free(struct percpu_ida *pool, 
percpu_ida_cb fn,
struct percpu_ida_cpu *remote;
unsigned cpu, i, err = 0;
 
-   local_irq_save(flags);
for_each_possible_cpu(cpu) {
remote = per_cpu_ptr(pool->tag_cpu, cpu);
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
for (i = 0; i < remote->nr_free; i++) {
err = fn(remote->freelist[i], data);
if (err)
break;
  

[PATCH] percpu_ida: Use _irqsave() instead of local_irq_save() + spin_lock

[Sebastian Andrzej Siewior]

percpu_ida() decouples disabling interrupts from the locking operations.
This breaks some assumptions if the locking operations are replaced like
they are under -RT.
The same locking can be achieved by avoiding local_irq_save() and using
spin_lock_irqsave() instead. percpu_ida_alloc() gains one more
preemption point because after unlocking the fastpath and before the
pool lock is acquired, the interrupts are briefly enabled.

Signed-off-by: Sebastian Andrzej Siewior 
---
 lib/percpu_ida.c | 63 
 1 file changed, 21 insertions(+), 42 deletions(-)

diff --git a/lib/percpu_ida.c b/lib/percpu_ida.c
index 6016f1deb1f5..9bbd9c5d375a 100644
--- a/lib/percpu_ida.c
+++ b/lib/percpu_ida.c
@@ -112,18 +112,6 @@ static inline void alloc_global_tags(struct percpu_ida 
*pool,
  min(pool->nr_free, pool->percpu_batch_size));
 }
 
-static inline unsigned alloc_local_tag(struct percpu_ida_cpu *tags)
-{
-   int tag = -ENOSPC;
-
-   spin_lock(>lock);
-   if (tags->nr_free)
-   tag = tags->freelist[--tags->nr_free];
-   spin_unlock(>lock);
-
-   return tag;
-}
-
 /**
  * percpu_ida_alloc - allocate a tag
  * @pool: pool to allocate from
@@ -147,20 +135,22 @@ int percpu_ida_alloc(struct percpu_ida *pool, int state)
DEFINE_WAIT(wait);
struct percpu_ida_cpu *tags;
unsigned long flags;
-   int tag;
+   int tag = -ENOSPC;
 
-   local_irq_save(flags);
-   tags = this_cpu_ptr(pool->tag_cpu);
+   tags = raw_cpu_ptr(pool->tag_cpu);
+   spin_lock_irqsave(>lock, flags);
 
/* Fastpath */
-   tag = alloc_local_tag(tags);
-   if (likely(tag >= 0)) {
-   local_irq_restore(flags);
+   if (likely(tags->nr_free >= 0)) {
+   tag = tags->freelist[--tags->nr_free];
+   spin_unlock_irqrestore(>lock, flags);
return tag;
}
+   spin_unlock_irqrestore(>lock, flags);
 
while (1) {
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
+   tags = this_cpu_ptr(pool->tag_cpu);
 
/*
 * prepare_to_wait() must come before steal_tags(), in case
@@ -184,8 +174,7 @@ int percpu_ida_alloc(struct percpu_ida *pool, int state)
>cpus_have_tags);
}
 
-   spin_unlock(>lock);
-   local_irq_restore(flags);
+   spin_unlock_irqrestore(>lock, flags);
 
if (tag >= 0 || state == TASK_RUNNING)
break;
@@ -196,9 +185,6 @@ int percpu_ida_alloc(struct percpu_ida *pool, int state)
}
 
schedule();
-
-   local_irq_save(flags);
-   tags = this_cpu_ptr(pool->tag_cpu);
}
if (state != TASK_RUNNING)
finish_wait(>wait, );
@@ -222,28 +208,24 @@ void percpu_ida_free(struct percpu_ida *pool, unsigned 
tag)
 
BUG_ON(tag >= pool->nr_tags);
 
-   local_irq_save(flags);
-   tags = this_cpu_ptr(pool->tag_cpu);
+   tags = raw_cpu_ptr(pool->tag_cpu);
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
tags->freelist[tags->nr_free++] = tag;
 
nr_free = tags->nr_free;
-   spin_unlock(>lock);
 
if (nr_free == 1) {
cpumask_set_cpu(smp_processor_id(),
>cpus_have_tags);
wake_up(>wait);
}
+   spin_unlock_irqrestore(>lock, flags);
 
if (nr_free == pool->percpu_max_size) {
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
+   spin_lock(>lock);
 
-   /*
-* Global lock held and irqs disabled, don't need percpu
-* lock
-*/
if (tags->nr_free == pool->percpu_max_size) {
move_tags(pool->freelist, >nr_free,
  tags->freelist, >nr_free,
@@ -251,10 +233,9 @@ void percpu_ida_free(struct percpu_ida *pool, unsigned tag)
 
wake_up(>wait);
}
-   spin_unlock(>lock);
+   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);
}
-
-   local_irq_restore(flags);
 }
 EXPORT_SYMBOL_GPL(percpu_ida_free);
 
@@ -346,29 +327,27 @@ int percpu_ida_for_each_free(struct percpu_ida *pool, 
percpu_ida_cb fn,
struct percpu_ida_cpu *remote;
unsigned cpu, i, err = 0;
 
-   local_irq_save(flags);
for_each_possible_cpu(cpu) {
remote = per_cpu_ptr(pool->tag_cpu, cpu);
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
for (i = 0; i < remote->nr_free; i++) {
err = fn(remote->freelist[i], data);
if (err)
break;
}
-  

[PATCH] ALSA: pcm: Hide local_irq_disable/enable() and local_irqsave/restore()

[Sebastian Andrzej Siewior]

From: Anna-Maria Gleixner 

The snd_pcm_stream_lock_irq*() functions decouple disabling interrupts
from the actual locking process. This does not work as expected if the
locking primitives are replaced like on preempt-rt.

Provide one function for locking which uses correct locking primitives.

Signed-off-by: Anna-Maria Gleixner 
Signed-off-by: Sebastian Andrzej Siewior 
---
 sound/core/pcm_native.c | 85 +++--
 1 file changed, 57 insertions(+), 28 deletions(-)

diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index d18b3982548b..92c10fc838e9 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -99,6 +99,57 @@ static inline void down_write_nonblock(struct rw_semaphore 
*lock)
cond_resched();
 }
 
+#define PCM_LOCK_DEFAULT   0
+#define PCM_LOCK_IRQ   1
+#define PCM_LOCK_IRQSAVE   2
+
+static unsigned long __snd_pcm_stream_lock_mode(struct snd_pcm_substream 
*substream,
+   unsigned int mode)
+{
+   unsigned long flags = 0;
+   if (substream->pcm->nonatomic) {
+   down_read_nested(_pcm_link_rwsem, SINGLE_DEPTH_NESTING);
+   mutex_lock(>self_group.mutex);
+   } else {
+   switch (mode) {
+   case PCM_LOCK_DEFAULT:
+   read_lock(_pcm_link_rwlock);
+   break;
+   case PCM_LOCK_IRQ:
+   read_lock_irq(_pcm_link_rwlock);
+   break;
+   case PCM_LOCK_IRQSAVE:
+   read_lock_irqsave(_pcm_link_rwlock, flags);
+   break;
+   }
+   spin_lock(>self_group.lock);
+   }
+   return flags;
+}
+
+static void __snd_pcm_stream_unlock_mode(struct snd_pcm_substream *substream,
+unsigned int mode, unsigned long flags)
+{
+   if (substream->pcm->nonatomic) {
+   mutex_unlock(>self_group.mutex);
+   up_read(_pcm_link_rwsem);
+   } else {
+   spin_unlock(>self_group.lock);
+
+   switch (mode) {
+   case PCM_LOCK_DEFAULT:
+   read_unlock(_pcm_link_rwlock);
+   break;
+   case PCM_LOCK_IRQ:
+   read_unlock_irq(_pcm_link_rwlock);
+   break;
+   case PCM_LOCK_IRQSAVE:
+   read_unlock_irqrestore(_pcm_link_rwlock, flags);
+   break;
+   }
+   }
+}
+
 /**
  * snd_pcm_stream_lock - Lock the PCM stream
  * @substream: PCM substream
@@ -109,13 +160,7 @@ static inline void down_write_nonblock(struct rw_semaphore 
*lock)
  */
 void snd_pcm_stream_lock(struct snd_pcm_substream *substream)
 {
-   if (substream->pcm->nonatomic) {
-   down_read_nested(_pcm_link_rwsem, SINGLE_DEPTH_NESTING);
-   mutex_lock(>self_group.mutex);
-   } else {
-   read_lock(_pcm_link_rwlock);
-   spin_lock(>self_group.lock);
-   }
+   __snd_pcm_stream_lock_mode(substream, PCM_LOCK_DEFAULT);
 }
 EXPORT_SYMBOL_GPL(snd_pcm_stream_lock);
 
@@ -127,13 +172,7 @@ EXPORT_SYMBOL_GPL(snd_pcm_stream_lock);
  */
 void snd_pcm_stream_unlock(struct snd_pcm_substream *substream)
 {
-   if (substream->pcm->nonatomic) {
-   mutex_unlock(>self_group.mutex);
-   up_read(_pcm_link_rwsem);
-   } else {
-   spin_unlock(>self_group.lock);
-   read_unlock(_pcm_link_rwlock);
-   }
+   __snd_pcm_stream_unlock_mode(substream, PCM_LOCK_DEFAULT, 0);
 }
 EXPORT_SYMBOL_GPL(snd_pcm_stream_unlock);
 
@@ -147,9 +186,7 @@ EXPORT_SYMBOL_GPL(snd_pcm_stream_unlock);
  */
 void snd_pcm_stream_lock_irq(struct snd_pcm_substream *substream)
 {
-   if (!substream->pcm->nonatomic)
-   local_irq_disable();
-   snd_pcm_stream_lock(substream);
+   __snd_pcm_stream_lock_mode(substream, PCM_LOCK_IRQ);
 }
 EXPORT_SYMBOL_GPL(snd_pcm_stream_lock_irq);
 
@@ -161,19 +198,13 @@ EXPORT_SYMBOL_GPL(snd_pcm_stream_lock_irq);
  */
 void snd_pcm_stream_unlock_irq(struct snd_pcm_substream *substream)
 {
-   snd_pcm_stream_unlock(substream);
-   if (!substream->pcm->nonatomic)
-   local_irq_enable();
+   __snd_pcm_stream_unlock_mode(substream, PCM_LOCK_IRQ, 0);
 }
 EXPORT_SYMBOL_GPL(snd_pcm_stream_unlock_irq);
 
 unsigned long _snd_pcm_stream_lock_irqsave(struct snd_pcm_substream *substream)
 {
-   unsigned long flags = 0;
-   if (!substream->pcm->nonatomic)
-   local_irq_save(flags);
-   snd_pcm_stream_lock(substream);
-   return flags;
+   return __snd_pcm_stream_lock_mode(substream, PCM_LOCK_IRQSAVE);
 }
 EXPORT_SYMBOL_GPL(_snd_pcm_stream_lock_irqsave);
 
@@ -187,9 +218,7 @@ EXPORT_SYMBOL_GPL(_snd_pcm_stream_lock_irqsave);
 

[PATCH] ALSA: pcm: Hide local_irq_disable/enable() and local_irqsave/restore()

[Sebastian Andrzej Siewior]

From: Anna-Maria Gleixner 

The snd_pcm_stream_lock_irq*() functions decouple disabling interrupts
from the actual locking process. This does not work as expected if the
locking primitives are replaced like on preempt-rt.

Provide one function for locking which uses correct locking primitives.

Signed-off-by: Anna-Maria Gleixner 
Signed-off-by: Sebastian Andrzej Siewior 
---
 sound/core/pcm_native.c | 85 +++--
 1 file changed, 57 insertions(+), 28 deletions(-)

diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index d18b3982548b..92c10fc838e9 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -99,6 +99,57 @@ static inline void down_write_nonblock(struct rw_semaphore 
*lock)
cond_resched();
 }
 
+#define PCM_LOCK_DEFAULT   0
+#define PCM_LOCK_IRQ   1
+#define PCM_LOCK_IRQSAVE   2
+
+static unsigned long __snd_pcm_stream_lock_mode(struct snd_pcm_substream 
*substream,
+   unsigned int mode)
+{
+   unsigned long flags = 0;
+   if (substream->pcm->nonatomic) {
+   down_read_nested(_pcm_link_rwsem, SINGLE_DEPTH_NESTING);
+   mutex_lock(>self_group.mutex);
+   } else {
+   switch (mode) {
+   case PCM_LOCK_DEFAULT:
+   read_lock(_pcm_link_rwlock);
+   break;
+   case PCM_LOCK_IRQ:
+   read_lock_irq(_pcm_link_rwlock);
+   break;
+   case PCM_LOCK_IRQSAVE:
+   read_lock_irqsave(_pcm_link_rwlock, flags);
+   break;
+   }
+   spin_lock(>self_group.lock);
+   }
+   return flags;
+}
+
+static void __snd_pcm_stream_unlock_mode(struct snd_pcm_substream *substream,
+unsigned int mode, unsigned long flags)
+{
+   if (substream->pcm->nonatomic) {
+   mutex_unlock(>self_group.mutex);
+   up_read(_pcm_link_rwsem);
+   } else {
+   spin_unlock(>self_group.lock);
+
+   switch (mode) {
+   case PCM_LOCK_DEFAULT:
+   read_unlock(_pcm_link_rwlock);
+   break;
+   case PCM_LOCK_IRQ:
+   read_unlock_irq(_pcm_link_rwlock);
+   break;
+   case PCM_LOCK_IRQSAVE:
+   read_unlock_irqrestore(_pcm_link_rwlock, flags);
+   break;
+   }
+   }
+}
+
 /**
  * snd_pcm_stream_lock - Lock the PCM stream
  * @substream: PCM substream
@@ -109,13 +160,7 @@ static inline void down_write_nonblock(struct rw_semaphore 
*lock)
  */
 void snd_pcm_stream_lock(struct snd_pcm_substream *substream)
 {
-   if (substream->pcm->nonatomic) {
-   down_read_nested(_pcm_link_rwsem, SINGLE_DEPTH_NESTING);
-   mutex_lock(>self_group.mutex);
-   } else {
-   read_lock(_pcm_link_rwlock);
-   spin_lock(>self_group.lock);
-   }
+   __snd_pcm_stream_lock_mode(substream, PCM_LOCK_DEFAULT);
 }
 EXPORT_SYMBOL_GPL(snd_pcm_stream_lock);
 
@@ -127,13 +172,7 @@ EXPORT_SYMBOL_GPL(snd_pcm_stream_lock);
  */
 void snd_pcm_stream_unlock(struct snd_pcm_substream *substream)
 {
-   if (substream->pcm->nonatomic) {
-   mutex_unlock(>self_group.mutex);
-   up_read(_pcm_link_rwsem);
-   } else {
-   spin_unlock(>self_group.lock);
-   read_unlock(_pcm_link_rwlock);
-   }
+   __snd_pcm_stream_unlock_mode(substream, PCM_LOCK_DEFAULT, 0);
 }
 EXPORT_SYMBOL_GPL(snd_pcm_stream_unlock);
 
@@ -147,9 +186,7 @@ EXPORT_SYMBOL_GPL(snd_pcm_stream_unlock);
  */
 void snd_pcm_stream_lock_irq(struct snd_pcm_substream *substream)
 {
-   if (!substream->pcm->nonatomic)
-   local_irq_disable();
-   snd_pcm_stream_lock(substream);
+   __snd_pcm_stream_lock_mode(substream, PCM_LOCK_IRQ);
 }
 EXPORT_SYMBOL_GPL(snd_pcm_stream_lock_irq);
 
@@ -161,19 +198,13 @@ EXPORT_SYMBOL_GPL(snd_pcm_stream_lock_irq);
  */
 void snd_pcm_stream_unlock_irq(struct snd_pcm_substream *substream)
 {
-   snd_pcm_stream_unlock(substream);
-   if (!substream->pcm->nonatomic)
-   local_irq_enable();
+   __snd_pcm_stream_unlock_mode(substream, PCM_LOCK_IRQ, 0);
 }
 EXPORT_SYMBOL_GPL(snd_pcm_stream_unlock_irq);
 
 unsigned long _snd_pcm_stream_lock_irqsave(struct snd_pcm_substream *substream)
 {
-   unsigned long flags = 0;
-   if (!substream->pcm->nonatomic)
-   local_irq_save(flags);
-   snd_pcm_stream_lock(substream);
-   return flags;
+   return __snd_pcm_stream_lock_mode(substream, PCM_LOCK_IRQSAVE);
 }
 EXPORT_SYMBOL_GPL(_snd_pcm_stream_lock_irqsave);
 
@@ -187,9 +218,7 @@ EXPORT_SYMBOL_GPL(_snd_pcm_stream_lock_irqsave);
 void snd_pcm_stream_unlock_irqrestore(struct snd_pcm_substream *substream,

Re: [PATCH v3 2/5] efi: Add embedded peripheral firmware support

[Martijn Coenen]

On Thu, May 3, 2018 at 5:21 PM, Luis R. Rodriguez  wrote:
> Android folks, poke below. otherwise we'll have no option but to seriously
> consider Mimi's patch to prevent these calls when IMA appraisal is enforced:

Sorry, figuring out who's the right person to answer this, will get
back to you ASAP.

Martijn

>
> http://lkml.kernel.org/r/1525182503-13849-7-git-send-email-zo...@linux.vnet.ibm.com
>
> Please read below
>
> On Wed, Apr 25, 2018 at 05:55:57PM +, Luis R. Rodriguez wrote:
>> On Wed, Apr 25, 2018 at 01:00:09AM -0400, Mimi Zohar wrote:
>> > On Tue, 2018-04-24 at 23:42 +, Luis R. Rodriguez wrote:
>> > > On Tue, Apr 24, 2018 at 12:07:01PM -0400, Mimi Zohar wrote:
>> > > > On Tue, 2018-04-24 at 17:09 +0200, Hans de Goede wrote:
>> > > If its of any help --
>> > >
>> > > drivers/soc/qcom/mdt_loader.c is the only driver currently using
>> > > request_firmware_into_buf() however I'll note qcom_mdt_load() is used in 
>> > > many
>> > > other drivers so they are wrappers around request_firmware_into_buf():
>> > >
>> > > drivers/gpu/drm/msm/adreno/a5xx_gpu.c:   * adreno_request_fw() handles 
>> > > this, but qcom_mdt_load() does
>> > > drivers/gpu/drm/msm/adreno/a5xx_gpu.c:  ret = qcom_mdt_load(dev, 
>> > > fw, fwname, GPU_PAS_ID,
>> > > drivers/gpu/drm/msm/adreno/a5xx_gpu.c:  ret = qcom_mdt_load(dev, 
>> > > fw, newname, GPU_PAS_ID,
>> > > drivers/media/platform/qcom/venus/firmware.c:   ret = qcom_mdt_load(dev, 
>> > > mdt, fwname, VENUS_PAS_ID, mem_va, mem_phys,
>> > > drivers/remoteproc/qcom_adsp_pil.c: return qcom_mdt_load(adsp->dev, 
>> > > fw, rproc->firmware, adsp->pas_id,
>> > > drivers/remoteproc/qcom_wcnss.c:return qcom_mdt_load(wcnss->dev, 
>> > > fw, rproc->firmware, WCNSS_PAS_ID,
>> > >
>> > > > > As such the current IMA code (from v4.17-rc2) actually does
>> > > > > not handle READING_FIRMWARE_PREALLOC_BUFFER at all,
>> > > >
>> > > > Right, it doesn't yet address READING_FIRMWARE_PREALLOC_BUFFER, but
>> > > > should.
>> > > >
>> > > > Depending on whether the device requesting the firmware has access to
>> > > > the DMA memory, before the signature verification,
>> > >
>> > > It would seem from the original patch review about 
>> > > READING_FIRMWARE_PREALLOC_BUFFER
>> > > that this is not a DMA buffer.
>
> To be very clear I believe Stephen implied this was not DMA buffer. Mimi
> asked for READING_FIRMWARE_DMA if it was:
>
> https://patchwork.kernel.org/patch/9074611/
>
>> > The call sequence:
>> > qcom_mdt_load() -> qcom_scm_pas_init_image() -> dma_alloc_coherent()
>> >
>> > If dma_alloc_coherent() isn't allocating a DMA buffer, then the
>> > function name is misleading/confusing.
>>
>> Hah, by *definition* the device *and* processor has immediate access
>> to data written *immediately* when dma_alloc_coherent() is used. From
>> Documentation/DMA-API.txt:
>>
>> ---
>> Part Ia - Using large DMA-coherent buffers
>> --
>>
>> ::
>>
>> void *
>> dma_alloc_coherent(struct device *dev, size_t size,
>>dma_addr_t *dma_handle, gfp_t flag)
>>
>> Consistent memory is memory for which a write by either the device or
>> the processor can immediately be read by the processor or device
>> without having to worry about caching effects.  (You may however need
>> to make sure to flush the processor's write buffers before telling
>> devices to read that memory.)
>> 
>>
>> Is ptr below
>>
>>   ret = request_firmware_into_buf(_fw, fw_name, dev,
>>   ptr, phdr->p_filesz);
>>
>> Also part of the DMA buffer allocated earlier via:
>>
>> ret = qcom_scm_pas_init_image(pas_id, fw->data, fw->size);
>>
>> Android folks?
>
> Android folks?
>
>> > > The device driver should have access to the buffer pointer with write 
>> > > given
>> > > that with request_firmware_into_buf() the driver is giving full write 
>> > > access to
>> > > the memory pointer so that the firmware API can stuff the firmware it 
>> > > finds
>> > > there.
>> > >
>> > > Firmware signature verification would be up to the device hardware to do 
>> > > upon
>> > > load *after* request_firmware_into_buf().
>> >
>> > We're discussing the kernel's signature verification, not the device
>> > hardware's signature verification.  Can the device driver access the
>> > buffer, before IMA-appraisal has verified the firmware's signature?
>>
>> It will depend on the above question.
>
>   Luis

Re: [PATCH v3 2/5] efi: Add embedded peripheral firmware support

[Martijn Coenen]

On Thu, May 3, 2018 at 5:21 PM, Luis R. Rodriguez  wrote:
> Android folks, poke below. otherwise we'll have no option but to seriously
> consider Mimi's patch to prevent these calls when IMA appraisal is enforced:

Sorry, figuring out who's the right person to answer this, will get
back to you ASAP.

Martijn

>
> http://lkml.kernel.org/r/1525182503-13849-7-git-send-email-zo...@linux.vnet.ibm.com
>
> Please read below
>
> On Wed, Apr 25, 2018 at 05:55:57PM +, Luis R. Rodriguez wrote:
>> On Wed, Apr 25, 2018 at 01:00:09AM -0400, Mimi Zohar wrote:
>> > On Tue, 2018-04-24 at 23:42 +, Luis R. Rodriguez wrote:
>> > > On Tue, Apr 24, 2018 at 12:07:01PM -0400, Mimi Zohar wrote:
>> > > > On Tue, 2018-04-24 at 17:09 +0200, Hans de Goede wrote:
>> > > If its of any help --
>> > >
>> > > drivers/soc/qcom/mdt_loader.c is the only driver currently using
>> > > request_firmware_into_buf() however I'll note qcom_mdt_load() is used in 
>> > > many
>> > > other drivers so they are wrappers around request_firmware_into_buf():
>> > >
>> > > drivers/gpu/drm/msm/adreno/a5xx_gpu.c:   * adreno_request_fw() handles 
>> > > this, but qcom_mdt_load() does
>> > > drivers/gpu/drm/msm/adreno/a5xx_gpu.c:  ret = qcom_mdt_load(dev, 
>> > > fw, fwname, GPU_PAS_ID,
>> > > drivers/gpu/drm/msm/adreno/a5xx_gpu.c:  ret = qcom_mdt_load(dev, 
>> > > fw, newname, GPU_PAS_ID,
>> > > drivers/media/platform/qcom/venus/firmware.c:   ret = qcom_mdt_load(dev, 
>> > > mdt, fwname, VENUS_PAS_ID, mem_va, mem_phys,
>> > > drivers/remoteproc/qcom_adsp_pil.c: return qcom_mdt_load(adsp->dev, 
>> > > fw, rproc->firmware, adsp->pas_id,
>> > > drivers/remoteproc/qcom_wcnss.c:return qcom_mdt_load(wcnss->dev, 
>> > > fw, rproc->firmware, WCNSS_PAS_ID,
>> > >
>> > > > > As such the current IMA code (from v4.17-rc2) actually does
>> > > > > not handle READING_FIRMWARE_PREALLOC_BUFFER at all,
>> > > >
>> > > > Right, it doesn't yet address READING_FIRMWARE_PREALLOC_BUFFER, but
>> > > > should.
>> > > >
>> > > > Depending on whether the device requesting the firmware has access to
>> > > > the DMA memory, before the signature verification,
>> > >
>> > > It would seem from the original patch review about 
>> > > READING_FIRMWARE_PREALLOC_BUFFER
>> > > that this is not a DMA buffer.
>
> To be very clear I believe Stephen implied this was not DMA buffer. Mimi
> asked for READING_FIRMWARE_DMA if it was:
>
> https://patchwork.kernel.org/patch/9074611/
>
>> > The call sequence:
>> > qcom_mdt_load() -> qcom_scm_pas_init_image() -> dma_alloc_coherent()
>> >
>> > If dma_alloc_coherent() isn't allocating a DMA buffer, then the
>> > function name is misleading/confusing.
>>
>> Hah, by *definition* the device *and* processor has immediate access
>> to data written *immediately* when dma_alloc_coherent() is used. From
>> Documentation/DMA-API.txt:
>>
>> ---
>> Part Ia - Using large DMA-coherent buffers
>> --
>>
>> ::
>>
>> void *
>> dma_alloc_coherent(struct device *dev, size_t size,
>>dma_addr_t *dma_handle, gfp_t flag)
>>
>> Consistent memory is memory for which a write by either the device or
>> the processor can immediately be read by the processor or device
>> without having to worry about caching effects.  (You may however need
>> to make sure to flush the processor's write buffers before telling
>> devices to read that memory.)
>> 
>>
>> Is ptr below
>>
>>   ret = request_firmware_into_buf(_fw, fw_name, dev,
>>   ptr, phdr->p_filesz);
>>
>> Also part of the DMA buffer allocated earlier via:
>>
>> ret = qcom_scm_pas_init_image(pas_id, fw->data, fw->size);
>>
>> Android folks?
>
> Android folks?
>
>> > > The device driver should have access to the buffer pointer with write 
>> > > given
>> > > that with request_firmware_into_buf() the driver is giving full write 
>> > > access to
>> > > the memory pointer so that the firmware API can stuff the firmware it 
>> > > finds
>> > > there.
>> > >
>> > > Firmware signature verification would be up to the device hardware to do 
>> > > upon
>> > > load *after* request_firmware_into_buf().
>> >
>> > We're discussing the kernel's signature verification, not the device
>> > hardware's signature verification.  Can the device driver access the
>> > buffer, before IMA-appraisal has verified the firmware's signature?
>>
>> It will depend on the above question.
>
>   Luis

[PATCH] posix-cpu-timers: remove lockdep_assert_irqs_disabled()

[Sebastian Andrzej Siewior]

The lockdep_assert_irqs_disabled() was a BUG_ON() statement in the
beginning and it was added just before the "spin_lock(siglock)"
statement to ensure this lock was taken with disabled interrupts.
This is no longer the case: the siglock is acquired via
lock_task_sighand() and this function already disables the interrupts.
The lock is also acquired before this "lockdep_assert_irqs_disabled" so
it is beset to remove it.

Signed-off-by: Sebastian Andrzej Siewior 
---
 kernel/time/posix-cpu-timers.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/kernel/time/posix-cpu-timers.c b/kernel/time/posix-cpu-timers.c
index 2541bd89f20e..d4f54df9c9fa 100644
--- a/kernel/time/posix-cpu-timers.c
+++ b/kernel/time/posix-cpu-timers.c
@@ -604,7 +604,6 @@ static int posix_cpu_timer_set(struct k_itimer *timer, int 
timer_flags,
/*
 * Disarm any old timer after extracting its expiry time.
 */
-   lockdep_assert_irqs_disabled();
 
ret = 0;
old_incr = timer->it.cpu.incr;
@@ -1049,7 +1048,6 @@ static void posix_cpu_timer_rearm(struct k_itimer *timer)
/*
 * Now re-arm for the new expiry time.
 */
-   lockdep_assert_irqs_disabled();
arm_timer(timer);
 unlock:
unlock_task_sighand(p, );
-- 
2.17.0

[PATCH] posix-cpu-timers: remove lockdep_assert_irqs_disabled()

[Sebastian Andrzej Siewior]

The lockdep_assert_irqs_disabled() was a BUG_ON() statement in the
beginning and it was added just before the "spin_lock(siglock)"
statement to ensure this lock was taken with disabled interrupts.
This is no longer the case: the siglock is acquired via
lock_task_sighand() and this function already disables the interrupts.
The lock is also acquired before this "lockdep_assert_irqs_disabled" so
it is beset to remove it.

Signed-off-by: Sebastian Andrzej Siewior 
---
 kernel/time/posix-cpu-timers.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/kernel/time/posix-cpu-timers.c b/kernel/time/posix-cpu-timers.c
index 2541bd89f20e..d4f54df9c9fa 100644
--- a/kernel/time/posix-cpu-timers.c
+++ b/kernel/time/posix-cpu-timers.c
@@ -604,7 +604,6 @@ static int posix_cpu_timer_set(struct k_itimer *timer, int 
timer_flags,
/*
 * Disarm any old timer after extracting its expiry time.
 */
-   lockdep_assert_irqs_disabled();
 
ret = 0;
old_incr = timer->it.cpu.incr;
@@ -1049,7 +1048,6 @@ static void posix_cpu_timer_rearm(struct k_itimer *timer)
/*
 * Now re-arm for the new expiry time.
 */
-   lockdep_assert_irqs_disabled();
arm_timer(timer);
 unlock:
unlock_task_sighand(p, );
-- 
2.17.0

[PATCH v4 1/3] dt-bindings: panel: Add the Ilitek ILI9881c panel documentation

[Maxime Ripard]

The LHR050H41 from BananaPi is a 1280x700 4-lanes DSI panel based on the
ILI9881c from Ilitek.

Acked-by: Rob Herring 
Signed-off-by: Maxime Ripard 
---
 Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.txt | 20 

 1 file changed, 20 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.txt 
b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.txt
new file mode 100644
index ..df05e8bb4851
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.txt
@@ -0,0 +1,20 @@
+Ilitek ILI9881c based MIPI-DSI panels
+
+Required properties:
+  - compatible: must be "ilitek,ili9881c" and one of:
+* "bananapi,lhr050h41"
+  - reg: DSI virtual channel used by that screen
+  - power-gpios: a GPIO phandle for the power pin
+  - reset-gpios: a GPIO phandle for the reset pin
+
+Optional properties:
+  - backlight: phandle to the backlight used
+
+Example:
+panel@0 {
+   compatible = "bananapi,lhr050h41", "ilitek,ili9881c";
+   reg = <0>;
+   power-gpios = < 1 7 GPIO_ACTIVE_HIGH>; /* PB07 */
+   reset-gpios = <_pio 0 5 GPIO_ACTIVE_LOW>; /* PL05 */
+   backlight = <_bl>;
+};
-- 
git-series 0.9.1

[PATCH v4 1/3] dt-bindings: panel: Add the Ilitek ILI9881c panel documentation

[Maxime Ripard]

The LHR050H41 from BananaPi is a 1280x700 4-lanes DSI panel based on the
ILI9881c from Ilitek.

Acked-by: Rob Herring 
Signed-off-by: Maxime Ripard 
---
 Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.txt | 20 

 1 file changed, 20 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.txt 
b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.txt
new file mode 100644
index ..df05e8bb4851
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.txt
@@ -0,0 +1,20 @@
+Ilitek ILI9881c based MIPI-DSI panels
+
+Required properties:
+  - compatible: must be "ilitek,ili9881c" and one of:
+* "bananapi,lhr050h41"
+  - reg: DSI virtual channel used by that screen
+  - power-gpios: a GPIO phandle for the power pin
+  - reset-gpios: a GPIO phandle for the reset pin
+
+Optional properties:
+  - backlight: phandle to the backlight used
+
+Example:
+panel@0 {
+   compatible = "bananapi,lhr050h41", "ilitek,ili9881c";
+   reg = <0>;
+   power-gpios = < 1 7 GPIO_ACTIVE_HIGH>; /* PB07 */
+   reset-gpios = <_pio 0 5 GPIO_ACTIVE_LOW>; /* PL05 */
+   backlight = <_bl>;
+};
-- 
git-series 0.9.1

[PATCH v4 3/3] [DO NOT MERGE] arm: dts: sun8i: bpi-m2m: Add DSI display

[Maxime Ripard]

The BananaPi M2M has an optional 1280x720 DSI panel. Since that panel is
optional, we can only show a DT patch that would show how to enable it.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts | 39 +-
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts 
b/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
index eaf09666720d..30e710e94912 100644
--- a/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
+++ b/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
@@ -44,6 +44,7 @@
 #include "sun8i-a33.dtsi"
 
 #include 
+#include 
 
 / {
model = "BananaPi M2 Magic";
@@ -81,6 +82,14 @@
};
};
 
+   pwm_bl: backlight {
+   compatible = "pwm-backlight";
+   pwms = < 0 5 PWM_POLARITY_INVERTED>;
+   brightness-levels = <1 2 4 8 16 32 64 128 255>;
+   default-brightness-level = <8>;
+   enable-gpios = <_pio 0 4 GPIO_ACTIVE_HIGH>; /* PG10 */
+   };
+
reg_vcc5v0: vcc5v0 {
compatible = "regulator-fixed";
regulator-name = "vcc5v0";
@@ -120,6 +129,26 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+
+   panel@0 {
+   compatible = "bananapi,lhr050h41", "ilitek,ili9881c";
+   reg = <0>;
+   power-gpios = < 1 7 GPIO_ACTIVE_HIGH>; /* PB07 */
+   reset-gpios = <_pio 0 5 GPIO_ACTIVE_LOW>; /* PL05 */
+   backlight = <_bl>;
+   };
+};
+
  {
status = "okay";
 };
@@ -179,6 +208,12 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "okay";
+};
+
 _rsb {
status = "okay";
 
@@ -291,6 +326,10 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_b>;
-- 
git-series 0.9.1

[PATCH v4 3/3] [DO NOT MERGE] arm: dts: sun8i: bpi-m2m: Add DSI display

[Maxime Ripard]

The BananaPi M2M has an optional 1280x720 DSI panel. Since that panel is
optional, we can only show a DT patch that would show how to enable it.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts | 39 +-
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts 
b/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
index eaf09666720d..30e710e94912 100644
--- a/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
+++ b/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
@@ -44,6 +44,7 @@
 #include "sun8i-a33.dtsi"
 
 #include 
+#include 
 
 / {
model = "BananaPi M2 Magic";
@@ -81,6 +82,14 @@
};
};
 
+   pwm_bl: backlight {
+   compatible = "pwm-backlight";
+   pwms = < 0 5 PWM_POLARITY_INVERTED>;
+   brightness-levels = <1 2 4 8 16 32 64 128 255>;
+   default-brightness-level = <8>;
+   enable-gpios = <_pio 0 4 GPIO_ACTIVE_HIGH>; /* PG10 */
+   };
+
reg_vcc5v0: vcc5v0 {
compatible = "regulator-fixed";
regulator-name = "vcc5v0";
@@ -120,6 +129,26 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+
+   panel@0 {
+   compatible = "bananapi,lhr050h41", "ilitek,ili9881c";
+   reg = <0>;
+   power-gpios = < 1 7 GPIO_ACTIVE_HIGH>; /* PB07 */
+   reset-gpios = <_pio 0 5 GPIO_ACTIVE_LOW>; /* PL05 */
+   backlight = <_bl>;
+   };
+};
+
  {
status = "okay";
 };
@@ -179,6 +208,12 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "okay";
+};
+
 _rsb {
status = "okay";
 
@@ -291,6 +326,10 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_b>;
-- 
git-series 0.9.1

Re: [PATCH] IB/umem: use tgid instead of pid in ib_umem structure

[陈立东]

> 在 2018年5月4日，21:39，Leon Romanovsky  写道：
> 
>> On Fri, May 04, 2018 at 04:32:38PM +0800, 858585 jemmy wrote:
>>> On Fri, May 4, 2018 at 6:01 AM, Jason Gunthorpe  wrote:
 On Thu, May 03, 2018 at 09:43:01PM +0300, Leon Romanovsky wrote:
> On Thu, May 03, 2018 at 12:26:56PM -0600, Jason Gunthorpe wrote:
>> On Thu, May 03, 2018 at 09:12:35PM +0300, Leon Romanovsky wrote:
>>> On Thu, May 03, 2018 at 09:33:10AM -0600, Jason Gunthorpe wrote:
 On Thu, May 03, 2018 at 10:04:34PM +0800, Lidong Chen wrote:
 The userspace may invoke ibv_reg_mr and ibv_dereg_mr by different 
 threads.
 If when ibv_dereg_mr invoke and the thread which invoked ibv_reg_mr has
 exited, get_pid_task will return NULL, ib_umem_release does not 
 decrease
 mm->pinned_vm. This patch fixes it by use tgid.
 
 Signed-off-by: Lidong Chen 
 drivers/infiniband/core/umem.c | 12 ++--
 include/rdma/ib_umem.h |  2 +-
 2 files changed, 7 insertions(+), 7 deletions(-)
>>> 
>>> Why are we even using a struct pid for this? Does anyone know?
>>> 
>> 
>> Can it be related to "fork" support?
> 
> Not sure..
> 
> Ideally we want to hold the struct mm, but we can't hold it long
> term, so pid is a surrogate for that.
> 
>>> I'm surprised that struct task isn't held in the struct ib_umem..
>>> 
>> 
>> I think that this code can be removed and all accesses to mm_struct can
>> be done with "current->mm".
> 
> That sounds wrong for fork support, as the mm used in destroy MUST
> exactly match the mm used in create..
> 
> How does this accounting work in fork anyhow?
 
 We are not supporting fork, so this is why I proposed to remove it.
>>> 
>>> Er, the new kabi certainly can call reg and dereg across a fork
>> 
>> what is the expect behavior after fork?
>> I write a test code, the dereg just return EACCES in the child
>> process. and have no effect.
> 
> Did you do reg/dereg over write() interface? If yes, this is expected
> behaviour of "not-supported fork()". A couple of months/years ago, your
> test program would work, but we closed this option due to security
> constraints.

the parent process call ibv_reg_mr, and the child process call ibv_dereg_mr.

If fork is not supported now, so use tgid to get mm structure is fine for 
multithread.

> 
> Thanks
> 
>> 
>>> 
>>> Jason

Re: [PATCH] IB/umem: use tgid instead of pid in ib_umem structure

[陈立东]

> 在 2018年5月4日，21:39，Leon Romanovsky  写道：
> 
>> On Fri, May 04, 2018 at 04:32:38PM +0800, 858585 jemmy wrote:
>>> On Fri, May 4, 2018 at 6:01 AM, Jason Gunthorpe  wrote:
 On Thu, May 03, 2018 at 09:43:01PM +0300, Leon Romanovsky wrote:
> On Thu, May 03, 2018 at 12:26:56PM -0600, Jason Gunthorpe wrote:
>> On Thu, May 03, 2018 at 09:12:35PM +0300, Leon Romanovsky wrote:
>>> On Thu, May 03, 2018 at 09:33:10AM -0600, Jason Gunthorpe wrote:
 On Thu, May 03, 2018 at 10:04:34PM +0800, Lidong Chen wrote:
 The userspace may invoke ibv_reg_mr and ibv_dereg_mr by different 
 threads.
 If when ibv_dereg_mr invoke and the thread which invoked ibv_reg_mr has
 exited, get_pid_task will return NULL, ib_umem_release does not 
 decrease
 mm->pinned_vm. This patch fixes it by use tgid.
 
 Signed-off-by: Lidong Chen 
 drivers/infiniband/core/umem.c | 12 ++--
 include/rdma/ib_umem.h |  2 +-
 2 files changed, 7 insertions(+), 7 deletions(-)
>>> 
>>> Why are we even using a struct pid for this? Does anyone know?
>>> 
>> 
>> Can it be related to "fork" support?
> 
> Not sure..
> 
> Ideally we want to hold the struct mm, but we can't hold it long
> term, so pid is a surrogate for that.
> 
>>> I'm surprised that struct task isn't held in the struct ib_umem..
>>> 
>> 
>> I think that this code can be removed and all accesses to mm_struct can
>> be done with "current->mm".
> 
> That sounds wrong for fork support, as the mm used in destroy MUST
> exactly match the mm used in create..
> 
> How does this accounting work in fork anyhow?
 
 We are not supporting fork, so this is why I proposed to remove it.
>>> 
>>> Er, the new kabi certainly can call reg and dereg across a fork
>> 
>> what is the expect behavior after fork?
>> I write a test code, the dereg just return EACCES in the child
>> process. and have no effect.
> 
> Did you do reg/dereg over write() interface? If yes, this is expected
> behaviour of "not-supported fork()". A couple of months/years ago, your
> test program would work, but we closed this option due to security
> constraints.

the parent process call ibv_reg_mr, and the child process call ibv_dereg_mr.

If fork is not supported now, so use tgid to get mm structure is fine for 
multithread.

> 
> Thanks
> 
>> 
>>> 
>>> Jason

[PATCH v4 2/3] drm/panel: Add Ilitek ILI9881c panel driver

[Maxime Ripard]

The LHR050H41 panel is the panel shipped with the BananaPi M2-Magic, and is
based on the Ilitek ILI9881c Controller. Add a driver for it, modelled
after the other Ilitek controller drivers.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/panel/Kconfig |   9 +-
 drivers/gpu/drm/panel/Makefile|   1 +-
 drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 488 +++-
 3 files changed, 498 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9881c.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 25682ff3449a..6020c30a33b3 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -46,6 +46,15 @@ config DRM_PANEL_ILITEK_IL9322
  Say Y here if you want to enable support for Ilitek IL9322
  QVGA (320x240) RGB, YUV and ITU-T BT.656 panels.
 
+config DRM_PANEL_ILITEK_ILI9881C
+   tristate "Ilitek ILI9881C-based panels"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y if you want to enable support for panels based on the
+ Ilitek ILI9881c controller.
+
 config DRM_PANEL_INNOLUX_P079ZCA
tristate "Innolux P079ZCA panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index f26efc11d746..5ccaaa9d13af 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
 obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
 obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
+obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
 obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
 obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c 
b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
new file mode 100644
index ..7c7e308cdb22
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
@@ -0,0 +1,488 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2017-2018, Bootlin
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+struct ili9881c {
+   struct drm_panelpanel;
+   struct mipi_dsi_device  *dsi;
+
+   struct backlight_device *backlight;
+   struct gpio_desc*power;
+   struct gpio_desc*reset;
+};
+
+enum ili9881c_op {
+   ILI9881C_SWITCH_PAGE,
+   ILI9881C_COMMAND,
+};
+
+struct ili9881c_instr {
+   enum ili9881c_opop;
+
+   union arg {
+   struct cmd {
+   u8  cmd;
+   u8  data;
+   } cmd;
+   u8  page;
+   } arg;
+};
+
+#define ILI9881C_SWITCH_PAGE_INSTR(_page)  \
+   {   \
+   .op = ILI9881C_SWITCH_PAGE, \
+   .arg = {\
+   .page = (_page),\
+   },  \
+   }
+
+#define ILI9881C_COMMAND_INSTR(_cmd, _data)\
+   {   \
+   .op = ILI9881C_COMMAND, \
+   .arg = {\
+   .cmd = {\
+   .cmd = (_cmd),  \
+   .data = (_data),\
+   },  \
+   },  \
+   }
+
+static const struct ili9881c_instr ili9881c_init[] = {
+   ILI9881C_SWITCH_PAGE_INSTR(3),
+   ILI9881C_COMMAND_INSTR(0x01, 0x00),
+   ILI9881C_COMMAND_INSTR(0x02, 0x00),
+   ILI9881C_COMMAND_INSTR(0x03, 0x73),
+   ILI9881C_COMMAND_INSTR(0x04, 0x03),
+   ILI9881C_COMMAND_INSTR(0x05, 0x00),
+   ILI9881C_COMMAND_INSTR(0x06, 0x06),
+   ILI9881C_COMMAND_INSTR(0x07, 0x06),
+   ILI9881C_COMMAND_INSTR(0x08, 0x00),
+   ILI9881C_COMMAND_INSTR(0x09, 0x18),
+   ILI9881C_COMMAND_INSTR(0x0a, 0x04),
+   ILI9881C_COMMAND_INSTR(0x0b, 0x00),
+   ILI9881C_COMMAND_INSTR(0x0c, 0x02),
+   ILI9881C_COMMAND_INSTR(0x0d, 0x03),
+   ILI9881C_COMMAND_INSTR(0x0e, 0x00),
+   ILI9881C_COMMAND_INSTR(0x0f, 0x25),
+   ILI9881C_COMMAND_INSTR(0x10, 0x25),
+   ILI9881C_COMMAND_INSTR(0x11, 0x00),
+   ILI9881C_COMMAND_INSTR(0x12, 0x00),
+   ILI9881C_COMMAND_INSTR(0x13, 0x00),
+   ILI9881C_COMMAND_INSTR(0x14, 0x00),
+   ILI9881C_COMMAND_INSTR(0x15, 0x00),
+   ILI9881C_COMMAND_INSTR(0x16, 0x0C),
+   ILI9881C_COMMAND_INSTR(0x17, 0x00),
+ 

[PATCH v4 0/3] drm/panel: Add Ilitek ILI9881c controller driver

[Maxime Ripard]

Hi,

Here is the next version of the patches to add the support for the Ilitek
ILI9881c panel controller.

This used to be a part of the larger DSI support series for the Allwinner
SoCs whose patches have been since merged and are obviously not part of
this series anymore.

Let me know what you think,
Maxime

Changes from v4:
  - Updated the copyright notice
  - Made the init structure const

Changes from v3:
  - Rebased on top of current drm-misc-next
  - Switched to SPDX license header
  - Made the ECC array const
  - Split the big DSI patch into two, one to add the DSI driver and one to
add the TCON bits.
  - Removed the dithering code
  - Changed the DT labels to remove the indices
  - Used sleeps instead of delays in the panel driver
  - Used the backlight_enable / _disable functions
  - Added Chen-Yu's Reviewed-by

Changes from v2:
  - Added a ports node under the DSI node
  - Changed the huarui panel driver to an ili9881c driver
  - Changed the panel vendor to bananapi
  - Made the init table static in the panel driver
  - Dropped the huarui vendor patch for the DT doc.

Changes from v1:
  - Rebased on 4.16-rc1
  - Constified a few function arguments and structures
  - Reworked the DT binding example a bit
  - Reworked the panel driver to check for DSI return codes, and use DCS
helpers when possible

Maxime Ripard (3):
  dt-bindings: panel: Add the Ilitek ILI9881c panel documentation
  drm/panel: Add Ilitek ILI9881c panel driver
  [DO NOT MERGE] arm: dts: sun8i: bpi-m2m: Add DSI display

 Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.txt |  20 +++-
 arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts|  39 
++-
 drivers/gpu/drm/panel/Kconfig   |   9 +-
 drivers/gpu/drm/panel/Makefile  |   1 +-
 drivers/gpu/drm/panel/panel-ilitek-ili9881c.c   | 488 
-
 5 files changed, 557 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.txt
 create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9881c.c

base-commit: a08fc7c8056e75b08285a2ad955228002dcd86bc
-- 
git-series 0.9.1

[PATCH v4 2/3] drm/panel: Add Ilitek ILI9881c panel driver

[Maxime Ripard]

The LHR050H41 panel is the panel shipped with the BananaPi M2-Magic, and is
based on the Ilitek ILI9881c Controller. Add a driver for it, modelled
after the other Ilitek controller drivers.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/panel/Kconfig |   9 +-
 drivers/gpu/drm/panel/Makefile|   1 +-
 drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 488 +++-
 3 files changed, 498 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9881c.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 25682ff3449a..6020c30a33b3 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -46,6 +46,15 @@ config DRM_PANEL_ILITEK_IL9322
  Say Y here if you want to enable support for Ilitek IL9322
  QVGA (320x240) RGB, YUV and ITU-T BT.656 panels.
 
+config DRM_PANEL_ILITEK_ILI9881C
+   tristate "Ilitek ILI9881C-based panels"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y if you want to enable support for panels based on the
+ Ilitek ILI9881c controller.
+
 config DRM_PANEL_INNOLUX_P079ZCA
tristate "Innolux P079ZCA panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index f26efc11d746..5ccaaa9d13af 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
 obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
 obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
+obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
 obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
 obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c 
b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
new file mode 100644
index ..7c7e308cdb22
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
@@ -0,0 +1,488 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2017-2018, Bootlin
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+struct ili9881c {
+   struct drm_panelpanel;
+   struct mipi_dsi_device  *dsi;
+
+   struct backlight_device *backlight;
+   struct gpio_desc*power;
+   struct gpio_desc*reset;
+};
+
+enum ili9881c_op {
+   ILI9881C_SWITCH_PAGE,
+   ILI9881C_COMMAND,
+};
+
+struct ili9881c_instr {
+   enum ili9881c_opop;
+
+   union arg {
+   struct cmd {
+   u8  cmd;
+   u8  data;
+   } cmd;
+   u8  page;
+   } arg;
+};
+
+#define ILI9881C_SWITCH_PAGE_INSTR(_page)  \
+   {   \
+   .op = ILI9881C_SWITCH_PAGE, \
+   .arg = {\
+   .page = (_page),\
+   },  \
+   }
+
+#define ILI9881C_COMMAND_INSTR(_cmd, _data)\
+   {   \
+   .op = ILI9881C_COMMAND, \
+   .arg = {\
+   .cmd = {\
+   .cmd = (_cmd),  \
+   .data = (_data),\
+   },  \
+   },  \
+   }
+
+static const struct ili9881c_instr ili9881c_init[] = {
+   ILI9881C_SWITCH_PAGE_INSTR(3),
+   ILI9881C_COMMAND_INSTR(0x01, 0x00),
+   ILI9881C_COMMAND_INSTR(0x02, 0x00),
+   ILI9881C_COMMAND_INSTR(0x03, 0x73),
+   ILI9881C_COMMAND_INSTR(0x04, 0x03),
+   ILI9881C_COMMAND_INSTR(0x05, 0x00),
+   ILI9881C_COMMAND_INSTR(0x06, 0x06),
+   ILI9881C_COMMAND_INSTR(0x07, 0x06),
+   ILI9881C_COMMAND_INSTR(0x08, 0x00),
+   ILI9881C_COMMAND_INSTR(0x09, 0x18),
+   ILI9881C_COMMAND_INSTR(0x0a, 0x04),
+   ILI9881C_COMMAND_INSTR(0x0b, 0x00),
+   ILI9881C_COMMAND_INSTR(0x0c, 0x02),
+   ILI9881C_COMMAND_INSTR(0x0d, 0x03),
+   ILI9881C_COMMAND_INSTR(0x0e, 0x00),
+   ILI9881C_COMMAND_INSTR(0x0f, 0x25),
+   ILI9881C_COMMAND_INSTR(0x10, 0x25),
+   ILI9881C_COMMAND_INSTR(0x11, 0x00),
+   ILI9881C_COMMAND_INSTR(0x12, 0x00),
+   ILI9881C_COMMAND_INSTR(0x13, 0x00),
+   ILI9881C_COMMAND_INSTR(0x14, 0x00),
+   ILI9881C_COMMAND_INSTR(0x15, 0x00),
+   ILI9881C_COMMAND_INSTR(0x16, 0x0C),
+   ILI9881C_COMMAND_INSTR(0x17, 0x00),
+   

[PATCH v4 0/3] drm/panel: Add Ilitek ILI9881c controller driver

[Maxime Ripard]

Hi,

Here is the next version of the patches to add the support for the Ilitek
ILI9881c panel controller.

This used to be a part of the larger DSI support series for the Allwinner
SoCs whose patches have been since merged and are obviously not part of
this series anymore.

Let me know what you think,
Maxime

Changes from v4:
  - Updated the copyright notice
  - Made the init structure const

Changes from v3:
  - Rebased on top of current drm-misc-next
  - Switched to SPDX license header
  - Made the ECC array const
  - Split the big DSI patch into two, one to add the DSI driver and one to
add the TCON bits.
  - Removed the dithering code
  - Changed the DT labels to remove the indices
  - Used sleeps instead of delays in the panel driver
  - Used the backlight_enable / _disable functions
  - Added Chen-Yu's Reviewed-by

Changes from v2:
  - Added a ports node under the DSI node
  - Changed the huarui panel driver to an ili9881c driver
  - Changed the panel vendor to bananapi
  - Made the init table static in the panel driver
  - Dropped the huarui vendor patch for the DT doc.

Changes from v1:
  - Rebased on 4.16-rc1
  - Constified a few function arguments and structures
  - Reworked the DT binding example a bit
  - Reworked the panel driver to check for DSI return codes, and use DCS
helpers when possible

Maxime Ripard (3):
  dt-bindings: panel: Add the Ilitek ILI9881c panel documentation
  drm/panel: Add Ilitek ILI9881c panel driver
  [DO NOT MERGE] arm: dts: sun8i: bpi-m2m: Add DSI display

 Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.txt |  20 +++-
 arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts|  39 
++-
 drivers/gpu/drm/panel/Kconfig   |   9 +-
 drivers/gpu/drm/panel/Makefile  |   1 +-
 drivers/gpu/drm/panel/panel-ilitek-ili9881c.c   | 488 
-
 5 files changed, 557 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.txt
 create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9881c.c

base-commit: a08fc7c8056e75b08285a2ad955228002dcd86bc
-- 
git-series 0.9.1

Re: [RFC PATCH 00/35] overlayfs: stack file operations

[Miklos Szeredi]

On Thu, Apr 12, 2018 at 5:07 PM, Miklos Szeredi  wrote:

> Git tree is here:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git 
> overlayfs-rorw

Thanks everyone for your review.

Force pushed new version to the above branch.

Hopefully no comment was missed (I didn't add more reverts yet, those
can wait).  I'll do a mailbomb as well next week and start processing
the metacopy patches.

Thanks,
Miklos
---

Miklos Szeredi (38):
  vfs: dedpue: return s64
  vfs: dedupe: rationalize args
  vfs: dedupe: extract helper for a single dedup
  vfs: add path_open()
  vfs: optionally don't account file in nr_files
  vfs: add f_op->pre_mmap()
  vfs: export vfs_ioctl() to modules
  vfs: export vfs_dedupe_file_range_one() to modules
  ovl: copy up times
  ovl: copy up inode flags
  Revert "Revert "ovl: get_write_access() in truncate""
  ovl: copy up file size as well
  ovl: deal with overlay files in ovl_d_real()
  ovl: stack file ops
  ovl: add helper to return real file
  ovl: add ovl_read_iter()
  ovl: add ovl_write_iter()
  ovl: add ovl_fsync()
  ovl: add ovl_mmap()
  ovl: add ovl_fallocate()
  ovl: add lsattr/chattr support
  ovl: add ovl_fiemap()
  ovl: add O_DIRECT support
  ovl: add reflink/copyfile/dedup support
  vfs: don't open real
  ovl: copy-up on MAP_SHARED
  vfs: simplify dentry_open()
  Revert "ovl: fix may_write_real() for overlayfs directories"
  Revert "ovl: don't allow writing ioctl on lower layer"
  vfs: fix freeze protection in mnt_want_write_file() for overlayfs
  Revert "ovl: fix relatime for directories"
  Revert "vfs: update ovl inode before relatime check"
  Revert "vfs: add flags to d_real()"
  Revert "vfs: do get_write_access() on upper layer of overlayfs"
  Partially revert "locks: fix file locking on overlayfs"
  Revert "fsnotify: support overlayfs"
  vfs: remove open_flags from d_real()
  ovl: fix documentation of non-standard behavior

---
 Documentation/filesystems/Locking   |   4 +-
 Documentation/filesystems/overlayfs.txt |  60 ++--
 Documentation/filesystems/vfs.txt   |  19 +-
 fs/btrfs/ctree.h|   4 +-
 fs/btrfs/ioctl.c|   6 +-
 fs/file_table.c |  13 +-
 fs/inode.c  |  46 +--
 fs/internal.h   |  17 +-
 fs/ioctl.c  |   1 +
 fs/locks.c  |  20 +-
 fs/namei.c  |   2 +-
 fs/namespace.c  |  69 +
 fs/ocfs2/file.c |  10 +-
 fs/open.c   |  74 ++---
 fs/overlayfs/Kconfig|  21 ++
 fs/overlayfs/Makefile   |   4 +-
 fs/overlayfs/dir.c  |  33 ++-
 fs/overlayfs/file.c | 506 
 fs/overlayfs/inode.c|  63 +++-
 fs/overlayfs/overlayfs.h|  21 +-
 fs/overlayfs/ovl_entry.h|   1 +
 fs/overlayfs/super.c|  65 ++--
 fs/overlayfs/util.c |  11 +-
 fs/read_write.c |  91 +++---
 fs/xattr.c  |   9 +-
 fs/xfs/xfs_file.c   |   8 +-
 include/linux/dcache.h  |  15 +-
 include/linux/fs.h  |  30 +-
 include/linux/fsnotify.h|  14 +-
 include/uapi/linux/fs.h |   1 -
 mm/util.c   |   5 +
 31 files changed, 886 insertions(+), 357 deletions(-)
 create mode 100644 fs/overlayfs/file.c

Re: [RFC PATCH 00/35] overlayfs: stack file operations

[Miklos Szeredi]

On Thu, Apr 12, 2018 at 5:07 PM, Miklos Szeredi  wrote:

> Git tree is here:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git 
> overlayfs-rorw

Thanks everyone for your review.

Force pushed new version to the above branch.

Hopefully no comment was missed (I didn't add more reverts yet, those
can wait).  I'll do a mailbomb as well next week and start processing
the metacopy patches.

Thanks,
Miklos
---

Miklos Szeredi (38):
  vfs: dedpue: return s64
  vfs: dedupe: rationalize args
  vfs: dedupe: extract helper for a single dedup
  vfs: add path_open()
  vfs: optionally don't account file in nr_files
  vfs: add f_op->pre_mmap()
  vfs: export vfs_ioctl() to modules
  vfs: export vfs_dedupe_file_range_one() to modules
  ovl: copy up times
  ovl: copy up inode flags
  Revert "Revert "ovl: get_write_access() in truncate""
  ovl: copy up file size as well
  ovl: deal with overlay files in ovl_d_real()
  ovl: stack file ops
  ovl: add helper to return real file
  ovl: add ovl_read_iter()
  ovl: add ovl_write_iter()
  ovl: add ovl_fsync()
  ovl: add ovl_mmap()
  ovl: add ovl_fallocate()
  ovl: add lsattr/chattr support
  ovl: add ovl_fiemap()
  ovl: add O_DIRECT support
  ovl: add reflink/copyfile/dedup support
  vfs: don't open real
  ovl: copy-up on MAP_SHARED
  vfs: simplify dentry_open()
  Revert "ovl: fix may_write_real() for overlayfs directories"
  Revert "ovl: don't allow writing ioctl on lower layer"
  vfs: fix freeze protection in mnt_want_write_file() for overlayfs
  Revert "ovl: fix relatime for directories"
  Revert "vfs: update ovl inode before relatime check"
  Revert "vfs: add flags to d_real()"
  Revert "vfs: do get_write_access() on upper layer of overlayfs"
  Partially revert "locks: fix file locking on overlayfs"
  Revert "fsnotify: support overlayfs"
  vfs: remove open_flags from d_real()
  ovl: fix documentation of non-standard behavior

---
 Documentation/filesystems/Locking   |   4 +-
 Documentation/filesystems/overlayfs.txt |  60 ++--
 Documentation/filesystems/vfs.txt   |  19 +-
 fs/btrfs/ctree.h|   4 +-
 fs/btrfs/ioctl.c|   6 +-
 fs/file_table.c |  13 +-
 fs/inode.c  |  46 +--
 fs/internal.h   |  17 +-
 fs/ioctl.c  |   1 +
 fs/locks.c  |  20 +-
 fs/namei.c  |   2 +-
 fs/namespace.c  |  69 +
 fs/ocfs2/file.c |  10 +-
 fs/open.c   |  74 ++---
 fs/overlayfs/Kconfig|  21 ++
 fs/overlayfs/Makefile   |   4 +-
 fs/overlayfs/dir.c  |  33 ++-
 fs/overlayfs/file.c | 506 
 fs/overlayfs/inode.c|  63 +++-
 fs/overlayfs/overlayfs.h|  21 +-
 fs/overlayfs/ovl_entry.h|   1 +
 fs/overlayfs/super.c|  65 ++--
 fs/overlayfs/util.c |  11 +-
 fs/read_write.c |  91 +++---
 fs/xattr.c  |   9 +-
 fs/xfs/xfs_file.c   |   8 +-
 include/linux/dcache.h  |  15 +-
 include/linux/fs.h  |  30 +-
 include/linux/fsnotify.h|  14 +-
 include/uapi/linux/fs.h |   1 -
 mm/util.c   |   5 +
 31 files changed, 886 insertions(+), 357 deletions(-)
 create mode 100644 fs/overlayfs/file.c

Re: [PATCH v1 5/5] ARM: dts: tegra114: Add IOMMU nodes to Host1x and its clients

[Thierry Reding]

On Fri, May 04, 2018 at 02:47:23AM +0300, Dmitry Osipenko wrote:
> Enable IOMMU support for Host1x and its clients.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  arch/arm/boot/dts/tegra114.dtsi | 5 +
>  1 file changed, 5 insertions(+)

Applied, thanks.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH v1 5/5] ARM: dts: tegra114: Add IOMMU nodes to Host1x and its clients

[Thierry Reding]

On Fri, May 04, 2018 at 02:47:23AM +0300, Dmitry Osipenko wrote:
> Enable IOMMU support for Host1x and its clients.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  arch/arm/boot/dts/tegra114.dtsi | 5 +
>  1 file changed, 5 insertions(+)

Applied, thanks.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH v1 4/5] ARM: dts: tegra30: Add IOMMU nodes to Host1x and its clients

[Thierry Reding]

On Fri, May 04, 2018 at 02:47:22AM +0300, Dmitry Osipenko wrote:
> Enable IOMMU support for Host1x and its clients.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  arch/arm/boot/dts/tegra30.dtsi | 14 ++
>  1 file changed, 14 insertions(+)

Applied, thanks.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH v1 4/5] ARM: dts: tegra30: Add IOMMU nodes to Host1x and its clients

[Thierry Reding]

On Fri, May 04, 2018 at 02:47:22AM +0300, Dmitry Osipenko wrote:
> Enable IOMMU support for Host1x and its clients.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  arch/arm/boot/dts/tegra30.dtsi | 14 ++
>  1 file changed, 14 insertions(+)

Applied, thanks.

Thierry


signature.asc
Description: PGP signature

[PATCH net-next] net: phy: sfp: handle cases where neither BR,min nor BR,max is given

[Antoine Tenart]

When computing the bitrate using values read from an SFP module EEPROM,
we use the nominal BR plus BR,min and BR,max to determine the
boundaries. But in some cases BR,min and BR,max aren't provided, which
led the SFP code to end up having the nominal value for both the minimum
and maximum bitrate values. When using a passive cable, the nominal
value should be used as the maximum one, and there is no minimum one
so we should use 0.

Signed-off-by: Antoine Tenart 
---

Hi Russell,

I'm not completely sure about this patch as this case is not really
specified in the specification. But the issue is there, and I've discuss
this with others. It seemed logical (at least to us :)) to use the
BR,nominal values as br_max and 0 as br_min when using a passive cable
which only provides BR,nominal as this would be the highest rate at
which the cable could work. And because it's passive, there should be no
issues using it at a lower rate.

I've tested this with one passive cable which only reports its
BR,nominal (which was 10300) while it could be used when using 1000baseX
or 2500baseX modes.

Thanks,
Antoine

 drivers/net/phy/sfp-bus.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c
index fd6c23f69c2f..d437f4f5ed52 100644
--- a/drivers/net/phy/sfp-bus.c
+++ b/drivers/net/phy/sfp-bus.c
@@ -132,6 +132,13 @@ void sfp_parse_support(struct sfp_bus *bus, const struct 
sfp_eeprom_id *id,
br_max = br_nom + br_nom * id->ext.br_min / 100;
br_min = br_nom - br_nom * id->ext.br_min / 100;
}
+
+   /* When using passive cables, in case neither BR,min nor BR,max
+* are specified, set br_min to 0 as the nominal value is then
+* used as the maximum.
+*/
+   if (br_min == br_max && id->base.sfp_ct_passive)
+   br_min = 0;
}
 
/* Set ethtool support from the compliance fields. */
-- 
2.17.0

[PATCH net-next] net: phy: sfp: handle cases where neither BR,min nor BR,max is given

[Antoine Tenart]

When computing the bitrate using values read from an SFP module EEPROM,
we use the nominal BR plus BR,min and BR,max to determine the
boundaries. But in some cases BR,min and BR,max aren't provided, which
led the SFP code to end up having the nominal value for both the minimum
and maximum bitrate values. When using a passive cable, the nominal
value should be used as the maximum one, and there is no minimum one
so we should use 0.

Signed-off-by: Antoine Tenart 
---

Hi Russell,

I'm not completely sure about this patch as this case is not really
specified in the specification. But the issue is there, and I've discuss
this with others. It seemed logical (at least to us :)) to use the
BR,nominal values as br_max and 0 as br_min when using a passive cable
which only provides BR,nominal as this would be the highest rate at
which the cable could work. And because it's passive, there should be no
issues using it at a lower rate.

I've tested this with one passive cable which only reports its
BR,nominal (which was 10300) while it could be used when using 1000baseX
or 2500baseX modes.

Thanks,
Antoine

 drivers/net/phy/sfp-bus.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c
index fd6c23f69c2f..d437f4f5ed52 100644
--- a/drivers/net/phy/sfp-bus.c
+++ b/drivers/net/phy/sfp-bus.c
@@ -132,6 +132,13 @@ void sfp_parse_support(struct sfp_bus *bus, const struct 
sfp_eeprom_id *id,
br_max = br_nom + br_nom * id->ext.br_min / 100;
br_min = br_nom - br_nom * id->ext.br_min / 100;
}
+
+   /* When using passive cables, in case neither BR,min nor BR,max
+* are specified, set br_min to 0 as the nominal value is then
+* used as the maximum.
+*/
+   if (br_min == br_max && id->base.sfp_ct_passive)
+   br_min = 0;
}
 
/* Set ethtool support from the compliance fields. */
-- 
2.17.0

Re: [PATCH v2 1/3] drm/tegra: dc: Enable plane scaling filters

[Thierry Reding]

On Fri, May 04, 2018 at 05:39:58PM +0300, Dmitry Osipenko wrote:
[...]
> +static bool tegra_dc_window_can_use_horizontal_filtering(
> + struct tegra_plane *plane,
> + const struct tegra_dc_window *window)
[...]
> +static bool tegra_dc_window_can_use_vertical_filtering(
> + struct tegra_plane *plane,
> + const struct tegra_dc_window *window)

I made these a little shorter.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH v2 1/3] drm/tegra: dc: Enable plane scaling filters

[Thierry Reding]

On Fri, May 04, 2018 at 05:39:58PM +0300, Dmitry Osipenko wrote:
[...]
> +static bool tegra_dc_window_can_use_horizontal_filtering(
> + struct tegra_plane *plane,
> + const struct tegra_dc_window *window)
[...]
> +static bool tegra_dc_window_can_use_vertical_filtering(
> + struct tegra_plane *plane,
> + const struct tegra_dc_window *window)

I made these a little shorter.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH v2 0/3] Couple more DRM plane features for Tegra

[Thierry Reding]

On Fri, May 04, 2018 at 05:39:57PM +0300, Dmitry Osipenko wrote:
> Hi,
> 
> This series improves DRM plane support by supporting zPos on older Tegra's
> and enabling plane scaling filters (up to Tegra210).
> 
> Changelog:
> 
> v2:
>   - Addressed v1 review comments.
> 
> Dmitry Osipenko (3):
>   drm/tegra: dc: Enable plane scaling filters
>   drm/tegra: plane: Implement zPos plane property for older Tegra's
>   drm/tegra: dc: Rename supports_blending to has_legacy_blending

All three patches applied, thanks.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH v2 0/3] Couple more DRM plane features for Tegra

[Thierry Reding]

On Fri, May 04, 2018 at 05:39:57PM +0300, Dmitry Osipenko wrote:
> Hi,
> 
> This series improves DRM plane support by supporting zPos on older Tegra's
> and enabling plane scaling filters (up to Tegra210).
> 
> Changelog:
> 
> v2:
>   - Addressed v1 review comments.
> 
> Dmitry Osipenko (3):
>   drm/tegra: dc: Enable plane scaling filters
>   drm/tegra: plane: Implement zPos plane property for older Tegra's
>   drm/tegra: dc: Rename supports_blending to has_legacy_blending

All three patches applied, thanks.

Thierry


signature.asc
Description: PGP signature

[PATCH net] net: phy: sfp: fix the BR,min computation

[Antoine Tenart]

In an SFP EEPROM values can be read to get information about a given SFP
module. One of those is the bitrate, which can be determined using a
nominal bitrate in addition with min and max values (in %). The SFP code
currently compute both BR,min and BR,max values thanks to this nominal
and min,max values.

This patch fixes the BR,min computation as the min value should be
subtracted to the nominal one, not added.

Fixes: 9962acf7fb8c ("sfp: add support for 1000Base-PX and 1000Base-BX10")
Signed-off-by: Antoine Tenart 
---
 drivers/net/phy/sfp-bus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c
index 0381da78d228..fd6c23f69c2f 100644
--- a/drivers/net/phy/sfp-bus.c
+++ b/drivers/net/phy/sfp-bus.c
@@ -125,7 +125,7 @@ void sfp_parse_support(struct sfp_bus *bus, const struct 
sfp_eeprom_id *id,
if (id->base.br_nominal) {
if (id->base.br_nominal != 255) {
br_nom = id->base.br_nominal * 100;
-   br_min = br_nom + id->base.br_nominal * id->ext.br_min;
+   br_min = br_nom - id->base.br_nominal * id->ext.br_min;
br_max = br_nom + id->base.br_nominal * id->ext.br_max;
} else if (id->ext.br_max) {
br_nom = 250 * id->ext.br_max;
-- 
2.17.0

[PATCH net] net: phy: sfp: fix the BR,min computation

[Antoine Tenart]

In an SFP EEPROM values can be read to get information about a given SFP
module. One of those is the bitrate, which can be determined using a
nominal bitrate in addition with min and max values (in %). The SFP code
currently compute both BR,min and BR,max values thanks to this nominal
and min,max values.

This patch fixes the BR,min computation as the min value should be
subtracted to the nominal one, not added.

Fixes: 9962acf7fb8c ("sfp: add support for 1000Base-PX and 1000Base-BX10")
Signed-off-by: Antoine Tenart 
---
 drivers/net/phy/sfp-bus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c
index 0381da78d228..fd6c23f69c2f 100644
--- a/drivers/net/phy/sfp-bus.c
+++ b/drivers/net/phy/sfp-bus.c
@@ -125,7 +125,7 @@ void sfp_parse_support(struct sfp_bus *bus, const struct 
sfp_eeprom_id *id,
if (id->base.br_nominal) {
if (id->base.br_nominal != 255) {
br_nom = id->base.br_nominal * 100;
-   br_min = br_nom + id->base.br_nominal * id->ext.br_min;
+   br_min = br_nom - id->base.br_nominal * id->ext.br_min;
br_max = br_nom + id->base.br_nominal * id->ext.br_max;
} else if (id->ext.br_max) {
br_nom = 250 * id->ext.br_max;
-- 
2.17.0

Re: [PATCH 6/7] arm64: allwinner: h6: add R_I2C controller

[Maxime Ripard]

On Fri, May 04, 2018 at 02:38:46AM +0800, Icenowy Zheng wrote:
> Allwinner H6 SoC has a R_I2C controller wired to the PL0/PL1 pins, which
> are used in the reference design to connect AXP805 PMIC.
> 
> Add support for it.
> 
> Signed-off-by: Icenowy Zheng 

Dropped the headers (that should have been in your previous patch to
maintain the bisectability) and changed for indices, and applied.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH 6/7] arm64: allwinner: h6: add R_I2C controller

[Maxime Ripard]

On Fri, May 04, 2018 at 02:38:46AM +0800, Icenowy Zheng wrote:
> Allwinner H6 SoC has a R_I2C controller wired to the PL0/PL1 pins, which
> are used in the reference design to connect AXP805 PMIC.
> 
> Add support for it.
> 
> Signed-off-by: Icenowy Zheng 

Dropped the headers (that should have been in your previous patch to
maintain the bisectability) and changed for indices, and applied.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH 5/7] arm64: allwinner: h6: add R_INTC interrupt controller

[Maxime Ripard]

On Fri, May 04, 2018 at 02:38:45AM +0800, Icenowy Zheng wrote:
> Allwinner H6 SoC has also a R_INTC interrupt controller like Allwinner
> A64 SoC, but has its base address changed due to the memory map change
> in H6.
> 
> Add it into the device tree.
> 
> Signed-off-by: Icenowy Zheng 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH 5/7] arm64: allwinner: h6: add R_INTC interrupt controller

[Maxime Ripard]

On Fri, May 04, 2018 at 02:38:45AM +0800, Icenowy Zheng wrote:
> Allwinner H6 SoC has also a R_INTC interrupt controller like Allwinner
> A64 SoC, but has its base address changed due to the memory map change
> in H6.
> 
> Add it into the device tree.
> 
> Signed-off-by: Icenowy Zheng 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH 4/7] arm64: allwinner: h6: add node for R_PIO pin controller

[Maxime Ripard]

On Fri, May 04, 2018 at 02:38:44AM +0800, Icenowy Zheng wrote:
> Allwinner H6 SoC has a R_PIO pin controller which controls PL and PM
> GPIO banks.
> 
> Add support for it.
> 
> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi 
> b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> index db9da343ba46..a18b78fb4850 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> @@ -183,5 +183,18 @@
>   #clock-cells = <1>;
>   #reset-cells = <1>;
>   };
> +
> + r_pio: pinctrl@7022000 {
> + compatible = "allwinner,sun50i-h6-r-pinctrl";
> + reg = <0x07022000 0x400>;
> + interrupts = ,
> +  ;
> + clocks = <_ccu CLK_R_APB1>, <>, <>;

As usual, try not to use the indices you introduce in the previous
patches of your serie. This introduces a dependency between the clk
and arm-soc tree that is not easy to deal with.

changed for the raw index, and applied, thanks!
maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH 4/7] arm64: allwinner: h6: add node for R_PIO pin controller

[Maxime Ripard]

On Fri, May 04, 2018 at 02:38:44AM +0800, Icenowy Zheng wrote:
> Allwinner H6 SoC has a R_PIO pin controller which controls PL and PM
> GPIO banks.
> 
> Add support for it.
> 
> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi 
> b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> index db9da343ba46..a18b78fb4850 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> @@ -183,5 +183,18 @@
>   #clock-cells = <1>;
>   #reset-cells = <1>;
>   };
> +
> + r_pio: pinctrl@7022000 {
> + compatible = "allwinner,sun50i-h6-r-pinctrl";
> + reg = <0x07022000 0x400>;
> + interrupts = ,
> +  ;
> + clocks = <_ccu CLK_R_APB1>, <>, <>;

As usual, try not to use the indices you introduce in the previous
patches of your serie. This introduces a dependency between the clk
and arm-soc tree that is not easy to deal with.

changed for the raw index, and applied, thanks!
maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH 2/7] arm64: allwinner: h6: add PRCM CCU device node

[Maxime Ripard]

On Fri, May 04, 2018 at 02:38:42AM +0800, Icenowy Zheng wrote:
> Allwinner H6 has also a PRCM CCU.
> 
> Add its device node into the device tree.
> 
> Signed-off-by: Icenowy Zheng 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH 2/7] arm64: allwinner: h6: add PRCM CCU device node

[Maxime Ripard]

On Fri, May 04, 2018 at 02:38:42AM +0800, Icenowy Zheng wrote:
> Allwinner H6 has also a PRCM CCU.
> 
> Add its device node into the device tree.
> 
> Signed-off-by: Icenowy Zheng 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH 1/7] clk: sunxi-ng: add support for H6 PRCM CCU

[Maxime Ripard]

On Fri, May 04, 2018 at 02:38:41AM +0800, Icenowy Zheng wrote:
> The H6 has clock/reset controls in PRCM part, like old SoCs such as H3
> and A64. However, the PRCM CCU is rearranged; the register arragement
> is now similar to the main CCU of H6, and the PRCM now has two APB
> buses to control -- one is clocked from AHB clock derivde from AR100
> clock, the other is clocked from the same mux with AR100 clock.
> Therefore a new driver is written for it.
> 
> As there's no official document about the PRCM in H6, all the information
> are indirectly collected from BSP and parts of the document, and the
> information source is noted as comments in the driver's source code. If
> reliable information is provided furtherly, the driver needs to be
> rechecked.
> 
> Signed-off-by: Icenowy Zheng 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH 1/7] clk: sunxi-ng: add support for H6 PRCM CCU

[Maxime Ripard]

On Fri, May 04, 2018 at 02:38:41AM +0800, Icenowy Zheng wrote:
> The H6 has clock/reset controls in PRCM part, like old SoCs such as H3
> and A64. However, the PRCM CCU is rearranged; the register arragement
> is now similar to the main CCU of H6, and the PRCM now has two APB
> buses to control -- one is clocked from AHB clock derivde from AR100
> clock, the other is clocked from the same mux with AR100 clock.
> Therefore a new driver is written for it.
> 
> As there's no official document about the PRCM in H6, all the information
> are indirectly collected from BSP and parts of the document, and the
> information source is noted as comments in the driver's source code. If
> reliable information is provided furtherly, the driver needs to be
> rechecked.
> 
> Signed-off-by: Icenowy Zheng 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH 3/7] pinctrl: sunxi: add support for H6 R_PIO pin controller

[Maxime Ripard]

On Fri, May 04, 2018 at 02:38:43AM +0800, Icenowy Zheng wrote:
> Allwinner H6 SoC has a R_PIO pin controller like other Allwinner SoCs,
> which controls the PL and PM pin banks.
> 
> Add support for it.
> 
> Signed-off-by: Icenowy Zheng 

Acked-by: Maxime Ripard 

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH 3/7] pinctrl: sunxi: add support for H6 R_PIO pin controller

[Maxime Ripard]

On Fri, May 04, 2018 at 02:38:43AM +0800, Icenowy Zheng wrote:
> Allwinner H6 SoC has a R_PIO pin controller like other Allwinner SoCs,
> which controls the PL and PM pin banks.
> 
> Add support for it.
> 
> Signed-off-by: Icenowy Zheng 

Acked-by: Maxime Ripard 

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH 1/6] powerpc/syscalls: Switch trivial cases to SYSCALL_DEFINE

[Naveen N. Rao]

Michael Ellerman wrote:

From: Al Viro 

Signed-off-by: Al Viro 
---
 arch/powerpc/kernel/pci_32.c   | 6 +++---
 arch/powerpc/kernel/pci_64.c   | 4 ++--
 arch/powerpc/mm/subpage-prot.c | 4 +++-
 arch/powerpc/platforms/cell/spu_syscalls.c | 3 ++-
 4 files changed, 10 insertions(+), 7 deletions(-)



I suppose we can also do this for switch_endian?

diff --git a/arch/powerpc/kernel/syscalls.c b/arch/powerpc/kernel/syscalls.c
index 466216506eb2..290265f2700c 100644
--- a/arch/powerpc/kernel/syscalls.c
+++ b/arch/powerpc/kernel/syscalls.c
@@ -123,7 +123,7 @@ long ppc_fadvise64_64(int fd, int advice, u32 offset_high, 
u32 offset_low,
 (u64)len_high << 32 | len_low, advice);
}

-long sys_switch_endian(void)
+SYSCALL_DEFINE0(switch_endian)
{
struct thread_info *ti;


- Naveen

Re: [PATCH 1/6] powerpc/syscalls: Switch trivial cases to SYSCALL_DEFINE

[Naveen N. Rao]

Michael Ellerman wrote:

From: Al Viro 

Signed-off-by: Al Viro 
---
 arch/powerpc/kernel/pci_32.c   | 6 +++---
 arch/powerpc/kernel/pci_64.c   | 4 ++--
 arch/powerpc/mm/subpage-prot.c | 4 +++-
 arch/powerpc/platforms/cell/spu_syscalls.c | 3 ++-
 4 files changed, 10 insertions(+), 7 deletions(-)



I suppose we can also do this for switch_endian?

diff --git a/arch/powerpc/kernel/syscalls.c b/arch/powerpc/kernel/syscalls.c
index 466216506eb2..290265f2700c 100644
--- a/arch/powerpc/kernel/syscalls.c
+++ b/arch/powerpc/kernel/syscalls.c
@@ -123,7 +123,7 @@ long ppc_fadvise64_64(int fd, int advice, u32 offset_high, 
u32 offset_low,
 (u64)len_high << 32 | len_low, advice);
}

-long sys_switch_endian(void)
+SYSCALL_DEFINE0(switch_endian)
{
struct thread_info *ti;


- Naveen

Re: [PATCH] i2c: core-smbus: fix a potential uninitialization bug

[Wenwen Wang]

On Fri, May 4, 2018 at 2:27 AM, Peter Rosin  wrote:
> On 2018-05-04 09:17, Wenwen Wang wrote:
>> On Fri, May 4, 2018 at 1:49 AM, Peter Rosin  wrote:
>>> On 2018-05-04 07:28, Wenwen Wang wrote:
 On Fri, May 4, 2018 at 12:04 AM, Peter Rosin  wrote:
> On 2018-05-04 06:08, Wenwen Wang wrote:
>> On Thu, May 3, 2018 at 3:34 PM, Peter Rosin  wrote:
>>> On 2018-05-03 00:36, Wenwen Wang wrote:
 In i2c_smbus_xfer_emulated(), there are two buffers: msgbuf0 and 
 msgbuf1,
 which are used to save a series of messages, as mentioned in the 
 comment.
 According to the value of the variable "size", msgbuf0 is initialized 
 to
 various values. In contrast, msgbuf1 is left uninitialized until the
 function i2c_transfer() is invoked. However, mgsbuf1 is not always
 initialized on all possible execution paths (implementation) of
 i2c_transfer(). Thus, it is possible that mgsbuf1 may still not be
>>>
>>> double negation here
>>>
 uninitialized even after the invocation of the function 
 i2c_transfer(). In
 the following execution, the uninitialized msgbuf1 will be used, such 
 as
 for security checks. Since uninitialized values can be random and
 arbitrary, this will cause undefined behaviors or even check bypass. 
 For
 example, it is expected that if the value of "size" is
 I2C_SMBUS_BLOCK_PROC_CALL, the value of data->block[0] should not be 
 larger
 than I2C_SMBUS_BLOCK_MAX. But, at the end of 
 i2c_smbus_xfer_emulated(), the
 value read from msgbuf1 is assigned to data->block[0], which can
 potentially lead to invalid block write size, as demonstrated in the 
 error
 message.

 This patch simply initializes the buffer msgbuf1 with 0 to avoid 
 undefined
 behaviors or security issues.

 Signed-off-by: Wenwen Wang 
 ---
  drivers/i2c/i2c-core-smbus.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/i2c/i2c-core-smbus.c 
 b/drivers/i2c/i2c-core-smbus.c
 index b5aec33..0fcca75 100644
 --- a/drivers/i2c/i2c-core-smbus.c
 +++ b/drivers/i2c/i2c-core-smbus.c
 @@ -324,7 +324,7 @@ static s32 i2c_smbus_xfer_emulated(struct 
 i2c_adapter *adapter, u16 addr,
* somewhat simpler.
*/
   unsigned char msgbuf0[I2C_SMBUS_BLOCK_MAX+3];
 - unsigned char msgbuf1[I2C_SMBUS_BLOCK_MAX+2];
 + unsigned char msgbuf1[I2C_SMBUS_BLOCK_MAX+2] = {0};
>>>
>>> I think this will result in the whole of msgbuf1 being filled with 
>>> zeroes.
>>> It might be cheaper to do this with code proper rather than with an
>>> initializer?
>>
>> Thanks for your comment, Peter!  How about using a memset() only when
>> i2c_smbus_xfer_emulated() emulates reading commands, since msgbuf1 is
>> used only in that case?
>
> I was thinking that an assignment of
>
> msgbuf1[0] = 0;
>
> would be enough in the I2C_SMBUS_BLOCK_DATA and I2C_SMBUS_BLOCK_PROC_CALL
> cases before the i2c_transfer call. However, this will only kick in if
> the call to kzalloc fails (and it most likely will not) in the call to the
> i2c_smbus_try_get_dmabuf helper. So, this thing that you are trying to fix
> seems like a non-issue to me.
>
> However, while looking I think the bigger problem with that function is 
> that
> it considers all non-negative return values from i2c_transfer as good.
> IMHO, it should barf on any return values <> num. Or at the very least
> describe why a partial result is considered OK...
>
> Cheers,
> Peter
>
>>>
>>> Cheers,
>>> Peter
>>>
   int num = read_write == I2C_SMBUS_READ ? 2 : 1;
   int i;
   u8 partial_pec = 0;

>>>
>

 Yes, it is a big issue if the return value from i2c_transfer() is not
 equal to num. I can add a check like this:

 if (status != num)
   return -EINVAL;

>>>
>>> Right, but make sure to add it *after* the existing "if (status < 0)"
>>> check as we want to preserve any existing error. Also, -EIO is perhaps
>>> more appropriate than -EINVAL which seems wrong for what is probably
>>> a runtime incident.
>>>
>>
>> Sure, I will place it after the existing check and replace -EINVAL with -EIO.
>>
 Also, I wonder why msgbuf1 is necessary if it is replaced by kzalloc
 in i2c_smbus_try_get_dmabuf()?
>>>
>>> It is not always replaced. The stack buffer is probably retained as
>>> the default mode of operation (and fallback) because kzalloc is
>>> expensive and because kzalloc might fail?
>>>
>>

Re: [PATCH] i2c: core-smbus: fix a potential uninitialization bug

[Wenwen Wang]

On Fri, May 4, 2018 at 2:27 AM, Peter Rosin  wrote:
> On 2018-05-04 09:17, Wenwen Wang wrote:
>> On Fri, May 4, 2018 at 1:49 AM, Peter Rosin  wrote:
>>> On 2018-05-04 07:28, Wenwen Wang wrote:
 On Fri, May 4, 2018 at 12:04 AM, Peter Rosin  wrote:
> On 2018-05-04 06:08, Wenwen Wang wrote:
>> On Thu, May 3, 2018 at 3:34 PM, Peter Rosin  wrote:
>>> On 2018-05-03 00:36, Wenwen Wang wrote:
 In i2c_smbus_xfer_emulated(), there are two buffers: msgbuf0 and 
 msgbuf1,
 which are used to save a series of messages, as mentioned in the 
 comment.
 According to the value of the variable "size", msgbuf0 is initialized 
 to
 various values. In contrast, msgbuf1 is left uninitialized until the
 function i2c_transfer() is invoked. However, mgsbuf1 is not always
 initialized on all possible execution paths (implementation) of
 i2c_transfer(). Thus, it is possible that mgsbuf1 may still not be
>>>
>>> double negation here
>>>
 uninitialized even after the invocation of the function 
 i2c_transfer(). In
 the following execution, the uninitialized msgbuf1 will be used, such 
 as
 for security checks. Since uninitialized values can be random and
 arbitrary, this will cause undefined behaviors or even check bypass. 
 For
 example, it is expected that if the value of "size" is
 I2C_SMBUS_BLOCK_PROC_CALL, the value of data->block[0] should not be 
 larger
 than I2C_SMBUS_BLOCK_MAX. But, at the end of 
 i2c_smbus_xfer_emulated(), the
 value read from msgbuf1 is assigned to data->block[0], which can
 potentially lead to invalid block write size, as demonstrated in the 
 error
 message.

 This patch simply initializes the buffer msgbuf1 with 0 to avoid 
 undefined
 behaviors or security issues.

 Signed-off-by: Wenwen Wang 
 ---
  drivers/i2c/i2c-core-smbus.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/i2c/i2c-core-smbus.c 
 b/drivers/i2c/i2c-core-smbus.c
 index b5aec33..0fcca75 100644
 --- a/drivers/i2c/i2c-core-smbus.c
 +++ b/drivers/i2c/i2c-core-smbus.c
 @@ -324,7 +324,7 @@ static s32 i2c_smbus_xfer_emulated(struct 
 i2c_adapter *adapter, u16 addr,
* somewhat simpler.
*/
   unsigned char msgbuf0[I2C_SMBUS_BLOCK_MAX+3];
 - unsigned char msgbuf1[I2C_SMBUS_BLOCK_MAX+2];
 + unsigned char msgbuf1[I2C_SMBUS_BLOCK_MAX+2] = {0};
>>>
>>> I think this will result in the whole of msgbuf1 being filled with 
>>> zeroes.
>>> It might be cheaper to do this with code proper rather than with an
>>> initializer?
>>
>> Thanks for your comment, Peter!  How about using a memset() only when
>> i2c_smbus_xfer_emulated() emulates reading commands, since msgbuf1 is
>> used only in that case?
>
> I was thinking that an assignment of
>
> msgbuf1[0] = 0;
>
> would be enough in the I2C_SMBUS_BLOCK_DATA and I2C_SMBUS_BLOCK_PROC_CALL
> cases before the i2c_transfer call. However, this will only kick in if
> the call to kzalloc fails (and it most likely will not) in the call to the
> i2c_smbus_try_get_dmabuf helper. So, this thing that you are trying to fix
> seems like a non-issue to me.
>
> However, while looking I think the bigger problem with that function is 
> that
> it considers all non-negative return values from i2c_transfer as good.
> IMHO, it should barf on any return values <> num. Or at the very least
> describe why a partial result is considered OK...
>
> Cheers,
> Peter
>
>>>
>>> Cheers,
>>> Peter
>>>
   int num = read_write == I2C_SMBUS_READ ? 2 : 1;
   int i;
   u8 partial_pec = 0;

>>>
>

 Yes, it is a big issue if the return value from i2c_transfer() is not
 equal to num. I can add a check like this:

 if (status != num)
   return -EINVAL;

>>>
>>> Right, but make sure to add it *after* the existing "if (status < 0)"
>>> check as we want to preserve any existing error. Also, -EIO is perhaps
>>> more appropriate than -EINVAL which seems wrong for what is probably
>>> a runtime incident.
>>>
>>
>> Sure, I will place it after the existing check and replace -EINVAL with -EIO.
>>
 Also, I wonder why msgbuf1 is necessary if it is replaced by kzalloc
 in i2c_smbus_try_get_dmabuf()?
>>>
>>> It is not always replaced. The stack buffer is probably retained as
>>> the default mode of operation (and fallback) because kzalloc is
>>> expensive and because kzalloc might fail?
>>>
>>
>> That means the stack buffer is probably used if kzalloc is failed.
>> Actually, the 

Re: [RFC PATCH] Add /proc//numa_vamaps for numa node information

[Christopher Lameter]

On Thu, 3 May 2018, prakash.sangappa wrote:

> > > exact numa node from where the pages have been allocated.
> > Cant you write a small script that scans the information in numa_maps and
> > then displays the total pages per NUMA node and then a list of which
> > ranges have how many pages on a particular node?
>
> Don't think we can determine which numa node a given user process
> address range has pages from, based on the existing 'numa_maps' file.

Well the information is contained in numa_maps I thought. What is missing?

> > > reading this file will not be restricted(i.e requiring CAP_SYS_ADMIN).
> > So a prime motivator here is security restricted access to numa_maps?
> No it is the opposite. A regular user should be able to determine
> numa node information.

That used to be the case until changes were made to the permissions for
reading numa_maps.

Re: [RFC PATCH] Add /proc//numa_vamaps for numa node information

[Christopher Lameter]

On Thu, 3 May 2018, prakash.sangappa wrote:

> > > exact numa node from where the pages have been allocated.
> > Cant you write a small script that scans the information in numa_maps and
> > then displays the total pages per NUMA node and then a list of which
> > ranges have how many pages on a particular node?
>
> Don't think we can determine which numa node a given user process
> address range has pages from, based on the existing 'numa_maps' file.

Well the information is contained in numa_maps I thought. What is missing?

> > > reading this file will not be restricted(i.e requiring CAP_SYS_ADMIN).
> > So a prime motivator here is security restricted access to numa_maps?
> No it is the opposite. A regular user should be able to determine
> numa node information.

That used to be the case until changes were made to the permissions for
reading numa_maps.

Re: [PATCH 1/3] kcov: ensure irq code sees a valid area

[Mark Rutland]

On Fri, May 04, 2018 at 02:55:33PM +0100, Mark Rutland wrote:
> In kcov_init_task() Since we update t->kcov_{mode,area,size} with plain
> stores, which may be re-ordered, torn, etc. Thus
> __sanitizer_cov_trace_pc() may see bogus values for any of these fields,
> and may attempt to write to memory which is not mapped.

Whoops; that 'Since' shuoldn't be there. I've fixed this up locally.

Mark.

Re: [PATCH 1/3] kcov: ensure irq code sees a valid area

[Mark Rutland]

On Fri, May 04, 2018 at 02:55:33PM +0100, Mark Rutland wrote:
> In kcov_init_task() Since we update t->kcov_{mode,area,size} with plain
> stores, which may be re-ordered, torn, etc. Thus
> __sanitizer_cov_trace_pc() may see bogus values for any of these fields,
> and may attempt to write to memory which is not mapped.

Whoops; that 'Since' shuoldn't be there. I've fixed this up locally.

Mark.

Re: [PATCH] memcg: Replace mm->owner with mm->memcg

[Oleg Nesterov]

On 05/04, Eric W. Biederman wrote:
>
> Oleg Nesterov  writes:
>
> > OK, what about exec() ? mm_init_memcg() initializes bprm->mm->memcg early in
> > bprm_mm_init(). What if the execing task migrates before exec_mmap() ?
>
> We need the the cgroup when the mm is initialized.  That way we have the
> cgroup information when initializing the mm.

Yes, we need to initialize new_mm->memcg but iiuc mostly for the error path,

> I don't know if a lock preventing changing the cgroup in exec or just
> a little bit of code in exec_mmap to ensure mm->memcg is properly set
> is the better approach.

I'd vote for the change in exec_mmap(). This way mm_init_memcg() can just
nullify mm->memcg.

> This does look like a very good place for an incremental patch to close
> that race.

Hmm. I think v2 makes more sense, but I won't argue.

Oleg.

Re: [PATCH] memcg: Replace mm->owner with mm->memcg

[Oleg Nesterov]

On 05/04, Eric W. Biederman wrote:
>
> Oleg Nesterov  writes:
>
> > OK, what about exec() ? mm_init_memcg() initializes bprm->mm->memcg early in
> > bprm_mm_init(). What if the execing task migrates before exec_mmap() ?
>
> We need the the cgroup when the mm is initialized.  That way we have the
> cgroup information when initializing the mm.

Yes, we need to initialize new_mm->memcg but iiuc mostly for the error path,

> I don't know if a lock preventing changing the cgroup in exec or just
> a little bit of code in exec_mmap to ensure mm->memcg is properly set
> is the better approach.

I'd vote for the change in exec_mmap(). This way mm_init_memcg() can just
nullify mm->memcg.

> This does look like a very good place for an incremental patch to close
> that race.

Hmm. I think v2 makes more sense, but I won't argue.

Oleg.

Re: [v2] mm: access to uninitialized struct page

[Steven Rostedt]

On Fri, 04 May 2018 12:47:53 +
Pavel Tatashin  wrote:

> Hi Andrei,
> 
> Could you please provide me with scripts to reproduce this issue?
> 
>

And the config that was used. Just saying that the commit doesn't boot
isn't very useful.

-- Steve

Re: [v2] mm: access to uninitialized struct page

[Steven Rostedt]

On Fri, 04 May 2018 12:47:53 +
Pavel Tatashin  wrote:

> Hi Andrei,
> 
> Could you please provide me with scripts to reproduce this issue?
> 
>

And the config that was used. Just saying that the commit doesn't boot
isn't very useful.

-- Steve