[PATCH v2] staging: greybus: arche-platform: Switch to the gpio descriptor interface

2018-11-16 Thread Nishad Kamdar
Use the gpiod interface instead of the deprecated
old non-descriptor interface.

Signed-off-by: Nishad Kamdar 
---
Changes in v2:
 - Move comment to the same line as to what it applies to.
---
 drivers/staging/greybus/arche-platform.c | 119 ---
 1 file changed, 41 insertions(+), 78 deletions(-)

diff --git a/drivers/staging/greybus/arche-platform.c 
b/drivers/staging/greybus/arche-platform.c
index 4c36e88766e7..a5cea79d8e32 100644
--- a/drivers/staging/greybus/arche-platform.c
+++ b/drivers/staging/greybus/arche-platform.c
@@ -8,10 +8,9 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -45,14 +44,14 @@ enum svc_wakedetect_state {
 
 struct arche_platform_drvdata {
/* Control GPIO signals to and from AP <=> SVC */
-   int svc_reset_gpio;
+   struct gpio_desc *svc_reset;
+   struct gpio_desc *svc_sysboot;
bool is_reset_act_hi;
-   int svc_sysboot_gpio;
-   int wake_detect_gpio; /* bi-dir,maps to WAKE_MOD & WAKE_FRAME signals */
+   struct gpio_desc *wake_detect; /* bi-dir,maps to WAKE_MOD & WAKE_FRAME 
signals */
 
enum arche_platform_state state;
 
-   int svc_refclk_req;
+   struct gpio_desc *svc_refclk_req;
struct clk *svc_ref_clk;
 
struct pinctrl *pinctrl;
@@ -85,9 +84,9 @@ static void arche_platform_set_wake_detect_state(
arche_pdata->wake_detect_state = state;
 }
 
-static inline void svc_reset_onoff(unsigned int gpio, bool onoff)
+static inline void svc_reset_onoff(struct gpio_desc *gpio, bool onoff)
 {
-   gpio_set_value(gpio, onoff);
+   gpiod_set_value(gpio, onoff);
 }
 
 static int apb_cold_boot(struct device *dev, void *data)
@@ -116,7 +115,6 @@ static int apb_poweroff(struct device *dev, void *data)
 static void arche_platform_wd_irq_en(struct arche_platform_drvdata 
*arche_pdata)
 {
/* Enable interrupt here, to read event back from SVC */
-   gpio_direction_input(arche_pdata->wake_detect_gpio);
enable_irq(arche_pdata->wake_detect_irq);
 }
 
@@ -160,7 +158,7 @@ static irqreturn_t arche_platform_wd_irq(int irq, void 
*devid)
 
spin_lock_irqsave(_pdata->wake_lock, flags);
 
-   if (gpio_get_value(arche_pdata->wake_detect_gpio)) {
+   if (gpiod_get_value(arche_pdata->wake_detect)) {
/* wake/detect rising */
 
/*
@@ -224,10 +222,10 @@ arche_platform_coldboot_seq(struct arche_platform_drvdata 
*arche_pdata)
 
dev_info(arche_pdata->dev, "Booting from cold boot state\n");
 
-   svc_reset_onoff(arche_pdata->svc_reset_gpio,
+   svc_reset_onoff(arche_pdata->svc_reset,
arche_pdata->is_reset_act_hi);
 
-   gpio_set_value(arche_pdata->svc_sysboot_gpio, 0);
+   gpiod_set_value(arche_pdata->svc_sysboot, 0);
usleep_range(100, 200);
 
ret = clk_prepare_enable(arche_pdata->svc_ref_clk);
@@ -238,7 +236,7 @@ arche_platform_coldboot_seq(struct arche_platform_drvdata 
*arche_pdata)
}
 
/* bring SVC out of reset */
-   svc_reset_onoff(arche_pdata->svc_reset_gpio,
+   svc_reset_onoff(arche_pdata->svc_reset,
!arche_pdata->is_reset_act_hi);
 
arche_platform_set_state(arche_pdata, ARCHE_PLATFORM_STATE_ACTIVE);
@@ -259,10 +257,10 @@ arche_platform_fw_flashing_seq(struct 
arche_platform_drvdata *arche_pdata)
 
dev_info(arche_pdata->dev, "Switching to FW flashing state\n");
 
-   svc_reset_onoff(arche_pdata->svc_reset_gpio,
+   svc_reset_onoff(arche_pdata->svc_reset,
arche_pdata->is_reset_act_hi);
 
-   gpio_set_value(arche_pdata->svc_sysboot_gpio, 1);
+   gpiod_set_value(arche_pdata->svc_sysboot, 1);
 
usleep_range(100, 200);
 
@@ -273,7 +271,7 @@ arche_platform_fw_flashing_seq(struct 
arche_platform_drvdata *arche_pdata)
return ret;
}
 
-   svc_reset_onoff(arche_pdata->svc_reset_gpio,
+   svc_reset_onoff(arche_pdata->svc_reset,
!arche_pdata->is_reset_act_hi);
 
arche_platform_set_state(arche_pdata, ARCHE_PLATFORM_STATE_FW_FLASHING);
@@ -305,7 +303,7 @@ arche_platform_poweroff_seq(struct arche_platform_drvdata 
*arche_pdata)
clk_disable_unprepare(arche_pdata->svc_ref_clk);
 
/* As part of exit, put APB back in reset state */
-   svc_reset_onoff(arche_pdata->svc_reset_gpio,
+   svc_reset_onoff(arche_pdata->svc_reset,
arche_pdata->is_reset_act_hi);
 
arche_platform_set_state(arche_pdata, ARCHE_PLATFORM_STATE_OFF);
@@ -435,6 +433,7 @@ static int arche_platform_probe(struct platform_device 
*pdev)
struct device *dev = >dev;
struct device_node *np = dev->of_node;
int ret;
+   unsigned int flags;
 
arche_pdata = devm_kzalloc(>dev, sizeof(*arche_pdata),
   GFP_KERNEL);
@@ -444,61 +443,33 @@ static int arche_platform_probe(struct 

Re: [PATCH] staging: greybus: arche-platform: Switch to the gpio descriptor interface

2018-11-16 Thread Nishad Kamdar
On Fri, Nov 16, 2018 at 05:06:22PM +0100, Johan Hovold wrote:
> On Fri, Nov 16, 2018 at 08:47:44PM +0530, Nishad Kamdar wrote:
> > Use the gpiod interface instead of the deprecated
> > old non-descriptor interface.
> > 
> > Signed-off-by: Nishad Kamdar 
> > ---
> 
> Always include a change log here after the cut-off line so we know what
> changed since previous versions.
> 
> Also include the patch revision in the Subject (e.g. "[PATCH v3]
> staging: greybus: ...").
> 

Ok, but this is the first patch version that I submitted
for greybus: arche-platform.

> >  drivers/staging/greybus/arche-platform.c | 120 ---
> >  1 file changed, 42 insertions(+), 78 deletions(-)
> > 
> > diff --git a/drivers/staging/greybus/arche-platform.c 
> > b/drivers/staging/greybus/arche-platform.c
> > index 4c36e88766e7..a826a1835628 100644
> > --- a/drivers/staging/greybus/arche-platform.c
> > +++ b/drivers/staging/greybus/arche-platform.c
> > @@ -8,10 +8,9 @@
> >  
> >  #include 
> >  #include 
> > -#include 
> > +#include 
> >  #include 
> >  #include 
> > -#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -45,14 +44,15 @@ enum svc_wakedetect_state {
> >  
> >  struct arche_platform_drvdata {
> > /* Control GPIO signals to and from AP <=> SVC */
> > -   int svc_reset_gpio;
> > +   struct gpio_desc *svc_reset;
> > +   struct gpio_desc *svc_sysboot;
> > bool is_reset_act_hi;
> > -   int svc_sysboot_gpio;
> > -   int wake_detect_gpio; /* bi-dir,maps to WAKE_MOD & WAKE_FRAME signals */
> > +   struct gpio_desc *wake_detect;
> > +   /* bi-dir,maps to WAKE_MOD & WAKE_FRAME signals */
> 
> I'm not commenting on the rest, but comments never go underneath what
> they apply to.
> 
> Just keep the current comment here, even if it's placement is a bit odd
> and makes the line be longer than 80 cols.
> 
> Johan

Ok, I'll keep that in mind.

Thanks for the review.

thanks and regards,
Nishad


Re: Memory hotplug softlock issue

2018-11-16 Thread Baoquan He
On 11/16/18 at 10:14am, Michal Hocko wrote:
> Could you try to apply this debugging patch on top please? It will dump
> stack trace for each reference count elevation for one page that fails
> to migrate after multiple passes.

Thanks, applied and fixed two code issues. The dmesg has been sent to
you privately, please check. The dmesg is overflow, if you need the
earlier message, I will retest.

diff --git a/include/linux/page_ref.h b/include/linux/page_ref.h
index b64ebf253381..f76e2c498f31 100644
--- a/include/linux/page_ref.h
+++ b/include/linux/page_ref.h
@@ -72,7 +72,7 @@ static inline int page_count(struct page *page)
return atomic_read(_head(page)->_refcount);
 }
 
-struct page *page_to_track;
+extern struct page *page_to_track;
 static inline void set_page_count(struct page *page, int v)
 {
atomic_set(>_refcount, v);
diff --git a/mm/migrate.c b/mm/migrate.c
index 9b2e395a3d68..42c7499c43b9 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1339,6 +1339,7 @@ static int unmap_and_move_huge_page(new_page_t 
get_new_page,
 }
 
 struct page *page_to_track;
+EXPORT_SYMBOL_GPL(page_to_track);
 
 /*
  * migrate_pages - migrate the pages specified in a list, to the free pages

> 
> diff --git a/include/linux/page_ref.h b/include/linux/page_ref.h
> index 14d14beb1f7f..b64ebf253381 100644
> --- a/include/linux/page_ref.h
> +++ b/include/linux/page_ref.h
> @@ -72,9 +72,12 @@ static inline int page_count(struct page *page)
>   return atomic_read(_head(page)->_refcount);
>  }
>  
> +struct page *page_to_track;
>  static inline void set_page_count(struct page *page, int v)
>  {
>   atomic_set(>_refcount, v);
> + if (page == page_to_track)
> + dump_stack();
>   if (page_ref_tracepoint_active(__tracepoint_page_ref_set))
>   __page_ref_set(page, v);
>  }
> @@ -91,6 +94,8 @@ static inline void init_page_count(struct page *page)
>  static inline void page_ref_add(struct page *page, int nr)
>  {
>   atomic_add(nr, >_refcount);
> + if (page == page_to_track)
> + dump_stack();
>   if (page_ref_tracepoint_active(__tracepoint_page_ref_mod))
>   __page_ref_mod(page, nr);
>  }
> @@ -105,6 +110,8 @@ static inline void page_ref_sub(struct page *page, int nr)
>  static inline void page_ref_inc(struct page *page)
>  {
>   atomic_inc(>_refcount);
> + if (page == page_to_track)
> + dump_stack();
>   if (page_ref_tracepoint_active(__tracepoint_page_ref_mod))
>   __page_ref_mod(page, 1);
>  }
> @@ -129,6 +136,8 @@ static inline int page_ref_inc_return(struct page *page)
>  {
>   int ret = atomic_inc_return(>_refcount);
>  
> + if (page == page_to_track)
> + dump_stack();
>   if (page_ref_tracepoint_active(__tracepoint_page_ref_mod_and_return))
>   __page_ref_mod_and_return(page, 1, ret);
>   return ret;
> @@ -156,6 +165,8 @@ static inline int page_ref_add_unless(struct page *page, 
> int nr, int u)
>  {
>   int ret = atomic_add_unless(>_refcount, nr, u);
>  
> + if (page == page_to_track)
> + dump_stack();
>   if (page_ref_tracepoint_active(__tracepoint_page_ref_mod_unless))
>   __page_ref_mod_unless(page, nr, ret);
>   return ret;
> diff --git a/mm/migrate.c b/mm/migrate.c
> index f7e4bfdc13b7..9b2e395a3d68 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -1338,6 +1338,8 @@ static int unmap_and_move_huge_page(new_page_t 
> get_new_page,
>   return rc;
>  }
>  
> +struct page *page_to_track;
> +
>  /*
>   * migrate_pages - migrate the pages specified in a list, to the free pages
>   *  supplied as the target for the page migration
> @@ -1375,6 +1377,7 @@ int migrate_pages(struct list_head *from, new_page_t 
> get_new_page,
>   if (!swapwrite)
>   current->flags |= PF_SWAPWRITE;
>  
> + page_to_track = NULL;
>   for(pass = 0; pass < 10 && retry; pass++) {
>   retry = 0;
>  
> @@ -1417,6 +1420,8 @@ int migrate_pages(struct list_head *from, new_page_t 
> get_new_page,
>   goto out;
>   case -EAGAIN:
>   retry++;
> + if (pass > 1 && !page_to_track)
> + page_to_track = page;
>   break;
>   case MIGRATEPAGE_SUCCESS:
>   nr_succeeded++;
> -- 
> Michal Hocko
> SUSE Labs


[PATCH] spi: npcm: Fix uninitialized variable warning

2018-11-16 Thread Olof Johansson
The compiler has no way to know that rsize 1 or 2 are the only valid
values. Also simplify the code a bit with early return.

The warning was:

drivers/spi/spi-npcm-pspi.c:215:6: warning: 'val' may be used uninitialized in 
this function [-Wmaybe-uninitialized]

Signed-off-by: Olof Johansson 
---
 drivers/spi/spi-npcm-pspi.c | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/drivers/spi/spi-npcm-pspi.c b/drivers/spi/spi-npcm-pspi.c
index 342178e282bcd..be0539cb19e49 100644
--- a/drivers/spi/spi-npcm-pspi.c
+++ b/drivers/spi/spi-npcm-pspi.c
@@ -217,15 +217,23 @@ static void npcm_pspi_recv(struct npcm_pspi *priv)
rsize = min(bytes_per_word(priv->bits_per_word), priv->rx_bytes);
priv->rx_bytes -= rsize;
 
-   if (priv->rx_buf) {
-   if (rsize == 1)
-   val = ioread8(priv->base + NPCM_PSPI_DATA);
-   if (rsize == 2)
-   val = ioread16(priv->base + NPCM_PSPI_DATA);
+   if (!priv->rx_buf)
+   return;
 
-   *priv->rx_buf = val;
-   priv->rx_buf += rsize;
+   switch (rsize) {
+   case 1:
+   val = ioread8(priv->base + NPCM_PSPI_DATA);
+   break;
+   case 2:
+   val = ioread16(priv->base + NPCM_PSPI_DATA);
+   break;
+   default:
+   WARN_ON_ONCE(1);
+   return;
}
+
+   *priv->rx_buf = val;
+   priv->rx_buf += rsize;
 }
 
 static int npcm_pspi_transfer_one(struct spi_master *master,
-- 
2.11.0



[PATCH] mtd: rawnand: qcom: Namespace prefix some commands

2018-11-16 Thread Olof Johansson
PAGE_READ is used by RISC-V arch code included through mm headers,
and it makes sense to bring in a prefix on these in the driver.

drivers/mtd/nand/raw/qcom_nandc.c:153: warning: "PAGE_READ" redefined
 #define PAGE_READ   0x2
In file included from include/linux/memremap.h:7,
 from include/linux/mm.h:27,
 from include/linux/scatterlist.h:8,
 from include/linux/dma-mapping.h:11,
 from drivers/mtd/nand/raw/qcom_nandc.c:17:
arch/riscv/include/asm/pgtable.h:48: note: this is the location of the previous 
definition

Caught by riscv allmodconfig.

Signed-off-by: Olof Johansson 
---
 drivers/mtd/nand/raw/qcom_nandc.c | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/mtd/nand/raw/qcom_nandc.c 
b/drivers/mtd/nand/raw/qcom_nandc.c
index ef75dfa62a4f8..699d3cf49c6da 100644
--- a/drivers/mtd/nand/raw/qcom_nandc.c
+++ b/drivers/mtd/nand/raw/qcom_nandc.c
@@ -150,15 +150,15 @@
 #defineNAND_VERSION_MINOR_SHIFT16
 
 /* NAND OP_CMDs */
-#definePAGE_READ   0x2
-#definePAGE_READ_WITH_ECC  0x3
-#definePAGE_READ_WITH_ECC_SPARE0x4
-#definePROGRAM_PAGE0x6
-#definePAGE_PROGRAM_WITH_ECC   0x7
-#definePROGRAM_PAGE_SPARE  0x9
-#defineBLOCK_ERASE 0xa
-#defineFETCH_ID0xb
-#defineRESET_DEVICE0xd
+#defineOP_PAGE_READ0x2
+#defineOP_PAGE_READ_WITH_ECC   0x3
+#defineOP_PAGE_READ_WITH_ECC_SPARE 0x4
+#defineOP_PROGRAM_PAGE 0x6
+#defineOP_PAGE_PROGRAM_WITH_ECC0x7
+#defineOP_PROGRAM_PAGE_SPARE   0x9
+#defineOP_BLOCK_ERASE  0xa
+#defineOP_FETCH_ID 0xb
+#defineOP_RESET_DEVICE 0xd
 
 /* Default Value for NAND_DEV_CMD_VLD */
 #define NAND_DEV_CMD_VLD_VAL   (READ_START_VLD | WRITE_START_VLD | \
@@ -692,11 +692,11 @@ static void update_rw_regs(struct qcom_nand_host *host, 
int num_cw, bool read)
 
if (read) {
if (host->use_ecc)
-   cmd = PAGE_READ_WITH_ECC | PAGE_ACC | LAST_PAGE;
+   cmd = OP_PAGE_READ_WITH_ECC | PAGE_ACC | LAST_PAGE;
else
-   cmd = PAGE_READ | PAGE_ACC | LAST_PAGE;
+   cmd = OP_PAGE_READ | PAGE_ACC | LAST_PAGE;
} else {
-   cmd = PROGRAM_PAGE | PAGE_ACC | LAST_PAGE;
+   cmd = OP_PROGRAM_PAGE | PAGE_ACC | LAST_PAGE;
}
 
if (host->use_ecc) {
@@ -1170,7 +1170,7 @@ static int nandc_param(struct qcom_nand_host *host)
 * in use. we configure the controller to perform a raw read of 512
 * bytes to read onfi params
 */
-   nandc_set_reg(nandc, NAND_FLASH_CMD, PAGE_READ | PAGE_ACC | LAST_PAGE);
+   nandc_set_reg(nandc, NAND_FLASH_CMD, OP_PAGE_READ | PAGE_ACC | 
LAST_PAGE);
nandc_set_reg(nandc, NAND_ADDR0, 0);
nandc_set_reg(nandc, NAND_ADDR1, 0);
nandc_set_reg(nandc, NAND_DEV0_CFG0, 0 << CW_PER_PAGE
@@ -1224,7 +1224,7 @@ static int erase_block(struct qcom_nand_host *host, int 
page_addr)
struct qcom_nand_controller *nandc = get_qcom_nand_controller(chip);
 
nandc_set_reg(nandc, NAND_FLASH_CMD,
- BLOCK_ERASE | PAGE_ACC | LAST_PAGE);
+ OP_BLOCK_ERASE | PAGE_ACC | LAST_PAGE);
nandc_set_reg(nandc, NAND_ADDR0, page_addr);
nandc_set_reg(nandc, NAND_ADDR1, 0);
nandc_set_reg(nandc, NAND_DEV0_CFG0,
@@ -1255,7 +1255,7 @@ static int read_id(struct qcom_nand_host *host, int 
column)
if (column == -1)
return 0;
 
-   nandc_set_reg(nandc, NAND_FLASH_CMD, FETCH_ID);
+   nandc_set_reg(nandc, NAND_FLASH_CMD, OP_FETCH_ID);
nandc_set_reg(nandc, NAND_ADDR0, column);
nandc_set_reg(nandc, NAND_ADDR1, 0);
nandc_set_reg(nandc, NAND_FLASH_CHIP_SELECT,
@@ -1276,7 +1276,7 @@ static int reset(struct qcom_nand_host *host)
struct nand_chip *chip = >chip;
struct qcom_nand_controller *nandc = get_qcom_nand_controller(chip);
 
-   nandc_set_reg(nandc, NAND_FLASH_CMD, RESET_DEVICE);
+   nandc_set_reg(nandc, NAND_FLASH_CMD, OP_RESET_DEVICE);
nandc_set_reg(nandc, NAND_EXEC_CMD, 1);
 
write_reg_dma(nandc, NAND_FLASH_CMD, 1, NAND_BAM_NEXT_SGL);
-- 
2.11.0



Re: [PATCH] RISC-V: Build flat and compressed kernel images

2018-11-16 Thread Anup Patel
On Sat, Nov 17, 2018 at 2:43 AM Palmer Dabbelt  wrote:
>
> On Sun, 11 Nov 2018 21:55:15 PST (-0800), a...@brainfault.org wrote:
> > This patch extends Linux RISC-V build system to build and install:
> > Image - Flat uncompressed kernel image
> > Image.gz - Flat and GZip compressed kernel image
> >
> > Quiet a few bootloaders (such as Uboot, UEFI, etc) are capable of
> > booting flat and compressed kernel images. In case of Uboot, booting
> > Image or Image.gz is achieved using bootm command.
> >
> > The flat and uncompressed kernel image (i.e. Image) is very useful
> > in pre-silicon developent and testing because we can create back-door
> > HEX files for RAM on FPGAs from Image.
> >
> > Signed-off-by: Anup Patel 
> > ---
> >  arch/riscv/Makefile | 15 -
> >  arch/riscv/boot/.gitignore  |  2 ++
> >  arch/riscv/boot/Makefile| 33 ++
> >  arch/riscv/boot/install.sh  | 60 +
> >  arch/riscv/kernel/head.S| 10 ++
> >  arch/riscv/kernel/vmlinux.lds.S |  2 +-
> >  6 files changed, 120 insertions(+), 2 deletions(-)
> >  create mode 100644 arch/riscv/boot/.gitignore
> >  create mode 100644 arch/riscv/boot/Makefile
> >  create mode 100644 arch/riscv/boot/install.sh
> >
> > diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
> > index d10146197533..d117a60362eb 100644
> > --- a/arch/riscv/Makefile
> > +++ b/arch/riscv/Makefile
> > @@ -71,10 +71,23 @@ KBUILD_CFLAGS += $(call cc-option,-mstrict-align)
> >  # arch specific predefines for sparse
> >  CHECKFLAGS += -D__riscv -D__riscv_xlen=$(BITS)
> >
> > +# Default target when executing plain make
> > +boot := arch/riscv/boot
> > +KBUILD_IMAGE := $(boot)/Image.gz
> > +
> >  head-y := arch/riscv/kernel/head.o
> >
> >  core-y += arch/riscv/kernel/ arch/riscv/mm/
> >
> >  libs-y += arch/riscv/lib/
> >
> > -all: vmlinux
> > +all: Image.gz
> > +
> > +Image: vmlinux
> > + $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
> > +
> > +Image.%: Image
> > + $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
> > +
> > +zinstall install:
> > + $(Q)$(MAKE) $(build)=$(boot) $@
> > diff --git a/arch/riscv/boot/.gitignore b/arch/riscv/boot/.gitignore
> > new file mode 100644
> > index ..8dab0bb6ae66
> > --- /dev/null
> > +++ b/arch/riscv/boot/.gitignore
> > @@ -0,0 +1,2 @@
> > +Image
> > +Image.gz
> > diff --git a/arch/riscv/boot/Makefile b/arch/riscv/boot/Makefile
> > new file mode 100644
> > index ..0990a9fdbe5d
> > --- /dev/null
> > +++ b/arch/riscv/boot/Makefile
> > @@ -0,0 +1,33 @@
> > +#
> > +# arch/riscv/boot/Makefile
> > +#
> > +# This file is included by the global makefile so that you can add your own
> > +# architecture-specific flags and dependencies.
> > +#
> > +# This file is subject to the terms and conditions of the GNU General 
> > Public
> > +# License.  See the file "COPYING" in the main directory of this archive
> > +# for more details.
> > +#
> > +# Copyright (C) 2018, Anup Patel.
> > +# Author: Anup Patel 
> > +#
> > +# Based on the ia64 and arm64 boot/Makefile.
> > +#
> > +
> > +OBJCOPYFLAGS_Image :=-O binary -R .note -R .note.gnu.build-id -R .comment 
> > -S
> > +
> > +targets := Image
> > +
> > +$(obj)/Image: vmlinux FORCE
> > + $(call if_changed,objcopy)
> > +
> > +$(obj)/Image.gz: $(obj)/Image FORCE
> > + $(call if_changed,gzip)
> > +
> > +install:
> > + $(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \
> > + $(obj)/Image System.map "$(INSTALL_PATH)"
> > +
> > +zinstall:
> > + $(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \
> > + $(obj)/Image.gz System.map "$(INSTALL_PATH)"
> > diff --git a/arch/riscv/boot/install.sh b/arch/riscv/boot/install.sh
> > new file mode 100644
> > index ..18c39159c0ff
> > --- /dev/null
> > +++ b/arch/riscv/boot/install.sh
> > @@ -0,0 +1,60 @@
> > +#!/bin/sh
> > +#
> > +# arch/riscv/boot/install.sh
> > +#
> > +# This file is subject to the terms and conditions of the GNU General 
> > Public
> > +# License.  See the file "COPYING" in the main directory of this archive
> > +# for more details.
> > +#
> > +# Copyright (C) 1995 by Linus Torvalds
> > +#
> > +# Adapted from code in arch/i386/boot/Makefile by H. Peter Anvin
> > +# Adapted from code in arch/i386/boot/install.sh by Russell King
> > +#
> > +# "make install" script for the RISC-V Linux port
> > +#
> > +# Arguments:
> > +#   $1 - kernel version
> > +#   $2 - kernel image file
> > +#   $3 - kernel map file
> > +#   $4 - default install path (blank if root directory)
> > +#
> > +
> > +verify () {
> > + if [ ! -f "$1" ]; then
> > + echo ""   1>&2
> > + echo " *** Missing file: $1"  1>&2
> > + echo ' *** You need to run "make" before "make install".' 1>&2
> > + echo ""   1>&2
> > + exit 1
> > + fi
> > +}
> > +
> > 

Re: [PATCH 4/6] dt-bindings:iio:resolver: Add docs for ad2s90

2018-11-16 Thread Matheus Tavares Bernardino
On Sun, Nov 11, 2018 at 9:48 AM Jonathan Cameron  wrote:
>
> On Fri,  9 Nov 2018 20:00:42 -0200
> Matheus Tavares  wrote:
>
> > This patch adds the device tree binding documentation for the ad2s90
> > resolver-to-digital converter.
> >
> > Signed-off-by: Matheus Tavares 
> > ---
> >  .../bindings/iio/resolver/ad2s90.txt  | 26 +++
> >  1 file changed, 26 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/iio/resolver/ad2s90.txt
> >
> > diff --git a/Documentation/devicetree/bindings/iio/resolver/ad2s90.txt 
> > b/Documentation/devicetree/bindings/iio/resolver/ad2s90.txt
> > new file mode 100644
> > index ..b42cc7752ffd
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/resolver/ad2s90.txt
> > @@ -0,0 +1,26 @@
> > +Analog Devices AD2S90 Resolver-to-Digital Converter
> > +
> > +https://www.analog.com/en/products/ad2s90.html
> > +
> > +Required properties:
> > +  - compatible : should be "adi,ad2s90"
> > +  - reg : SPI chip select number for the device
> > +  - spi-max-frequency : set maximum clock frequency, must be 83
> > +  - spi-cpol and spi-cpha : must be defined to enable SPI mode 3
>
> As the part only works in mode 3, my gut feeling is that this belongs
> in the driver, not here.  Rob, what do you think?
>

For this patch, I assumed the part only worked in mode 3 based on the
driver's code that set this at probe. But today I carefully looked for
it at the datasheet and now I'm unsure. It is never said, explicitly,
which SPI mode ad2s90 works with. But looking at the diagram that
shows the expected pins signals at each communication moment, it seems
to me that this chip can either work in mode 0 (CPOL=0, CPHA=0) or
mode 3 (CPOL=1, CPHA=1). Could someone help me to confirm this? And if
that is the case, them the SPI mode setting should be left in DT, as
adc/mcp320x and dac/ti-dac082s085 do, right?

Also, when I thought that ad2s90 only worked in mode 3, I wrote this
patch based on the dt-binding docs for the adxl345 accelerometer,
which only works in mode 3 but lets this setting to DT not in the
driver. Do you think, perhaps, it is wrong in adxl345, them?

Thanks,
Matheus.

> > +
> > +Note about max frequency:
> > +Chip's max frequency, as specified in its datasheet, is 2Mhz. But a 
> > 600ns
> > +delay is expected between the application of a logic LO to CS and the
> > +application of SCLK, as also specified. And since the delay is not
> > +implemented in the spi code, to satisfy it, SCLK's period should be at 
> > most
> > +2 * 600ns, so the max frequency should be 1 / (2 * 6e-7), which gives
> > +roughly 83Hz.
> > +
> > +Example:
> > +resolver@0 {
> > + compatible = "adi,ad2s90";
> > + reg = <0>;
> > + spi-max-frequency = <83>;
> > + spi-cpol;
> > + spi-cpha;
> > +};
>


Applied "ASoC: rt5663: Add documentation for power supply support" to the asoc tree

2018-11-16 Thread Mark Brown
The patch

   ASoC: rt5663: Add documentation for power supply support

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 276aa6d38e619d2bd61fbac71388a4da680e7ed5 Mon Sep 17 00:00:00 2001
From: Cheng-Yi Chiang 
Date: Fri, 16 Nov 2018 10:12:43 +0800
Subject: [PATCH] ASoC: rt5663: Add documentation for power supply support

rt5663 codec driver will support setting CPVDD and AVDD power supply
from device tree.

Signed-off-by: Cheng-Yi Chiang 
Signed-off-by: Mark Brown 
---
 Documentation/devicetree/bindings/sound/rt5663.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/rt5663.txt 
b/Documentation/devicetree/bindings/sound/rt5663.txt
index 23386446c63d..2a55e9133408 100644
--- a/Documentation/devicetree/bindings/sound/rt5663.txt
+++ b/Documentation/devicetree/bindings/sound/rt5663.txt
@@ -10,6 +10,10 @@ Required properties:
 
 - interrupts : The CODEC's interrupt output.
 
+- avdd-supply: Power supply for AVDD, providing 1.8V.
+
+- cpvdd-supply: Power supply for CPVDD, providing 3.5V.
+
 Optional properties:
 
 - "realtek,dc_offset_l_manual"
@@ -51,4 +55,6 @@ rt5663: codec@12 {
compatible = "realtek,rt5663";
reg = <0x12>;
interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
+   avdd-supply = <_a_alc5662>;
+   cpvdd-supply = <_a_alc5662>;
 };
-- 
2.19.1



Applied "spi: pxa2xx: Fix '"CONFIG_OF" is not defined' warning" to the spi tree

2018-11-16 Thread Mark Brown
The patch

   spi: pxa2xx: Fix '"CONFIG_OF" is not defined' warning

has been applied to the spi tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From f0915dfc44365b487a720d447ad3faa66de5205c Mon Sep 17 00:00:00 2001
From: Lubomir Rintel 
Date: Thu, 15 Nov 2018 11:32:09 +0100
Subject: [PATCH] spi: pxa2xx: Fix '"CONFIG_OF" is not defined' warning

A careless oversight. Sorry.

Fixes: 0a897143b7c9 ("spi: pxa2xx: Add slave mode support")
Signed-off-by: Lubomir Rintel 
Signed-off-by: Mark Brown 
---
 drivers/spi/spi-pxa2xx.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index e6a606354f62..d84b893a64d7 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -1555,19 +1555,13 @@ pxa2xx_spi_init_pdata(struct platform_device *pdev)
}
 #endif
 
-#if CONFIG_OF
-   if (of_id) {
-   pdata->is_slave = of_property_read_bool(pdev->dev.of_node,
-   "spi-slave");
-   }
-#endif
-
ssp->clk = devm_clk_get(>dev, NULL);
ssp->irq = platform_get_irq(pdev, 0);
ssp->type = type;
ssp->pdev = pdev;
ssp->port_id = pxa2xx_spi_get_port_id(adev);
 
+   pdata->is_slave = of_property_read_bool(pdev->dev.of_node, "spi-slave");
pdata->num_chipselect = 1;
pdata->enable_dma = true;
 
-- 
2.19.1



Applied "ASoC: tlv320dac33: clean up indentation, remove extraneous tab" to the asoc tree

2018-11-16 Thread Mark Brown
The patch

   ASoC: tlv320dac33: clean up indentation, remove extraneous tab

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 6857b9d0881e4cbf30237a1091e83a8e3e7ee7c3 Mon Sep 17 00:00:00 2001
From: Colin Ian King 
Date: Fri, 16 Nov 2018 15:06:34 +
Subject: [PATCH] ASoC: tlv320dac33: clean up indentation, remove extraneous
 tab

The goto statement is indented too much by one level, fix this by
removing the extraneous tab.

Signed-off-by: Colin Ian King 
Signed-off-by: Mark Brown 
---
 sound/soc/codecs/tlv320dac33.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/tlv320dac33.c b/sound/soc/codecs/tlv320dac33.c
index a957eaeb7bc1..32907b1e20cf 100644
--- a/sound/soc/codecs/tlv320dac33.c
+++ b/sound/soc/codecs/tlv320dac33.c
@@ -394,7 +394,7 @@ static int dac33_hard_power(struct snd_soc_component 
*component, int power)
if (ret != 0) {
dev_err(component->dev,
"Failed to enable supplies: %d\n", ret);
-   goto exit;
+   goto exit;
}
 
if (dac33->power_gpio >= 0)
-- 
2.19.1



Applied "ASoC: arizona: fix indentation issue with return statement" to the asoc tree

2018-11-16 Thread Mark Brown
The patch

   ASoC: arizona: fix indentation issue with return statement

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 812fb75d977efb0257fe41700e6f8e04900ab27c Mon Sep 17 00:00:00 2001
From: Colin Ian King 
Date: Fri, 16 Nov 2018 15:06:35 +
Subject: [PATCH] ASoC: arizona: fix indentation issue with return statement

The return statement is indented incorrectly. Fix this by adding in
the missing tab.

Signed-off-by: Colin Ian King 
Signed-off-by: Mark Brown 
---
 sound/soc/codecs/wm8998.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/wm8998.c b/sound/soc/codecs/wm8998.c
index 61294c787f27..409bed30a4e4 100644
--- a/sound/soc/codecs/wm8998.c
+++ b/sound/soc/codecs/wm8998.c
@@ -60,7 +60,7 @@ static int wm8998_asrc_ev(struct snd_soc_dapm_widget *w,
dev_warn(component->dev,
 "Unsupported ASRC rate1 (%s)\n",
 arizona_sample_rate_val_to_name(val));
-   return -EINVAL;
+   return -EINVAL;
}
break;
default:
-- 
2.19.1



Applied "ASoC: tlv320aic31xx: asihpi: clean up indentation, remove extraneous tab" to the asoc tree

2018-11-16 Thread Mark Brown
The patch

   ASoC: tlv320aic31xx: asihpi: clean up indentation, remove extraneous tab

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 7806869c6e5ea3c48aee80a72c790c55e6c3c303 Mon Sep 17 00:00:00 2001
From: Colin Ian King 
Date: Fri, 16 Nov 2018 15:06:33 +
Subject: [PATCH] ASoC: tlv320aic31xx: asihpi: clean up indentation, remove
 extraneous tab

The return statement is indented too much by one level, fix this by
removing an extraneous tab.

Signed-off-by: Colin Ian King 
Signed-off-by: Mark Brown 
---
 sound/soc/codecs/tlv320aic31xx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/tlv320aic31xx.c b/sound/soc/codecs/tlv320aic31xx.c
index 608ad49ad978..c6048d95c6d3 100644
--- a/sound/soc/codecs/tlv320aic31xx.c
+++ b/sound/soc/codecs/tlv320aic31xx.c
@@ -1095,7 +1095,7 @@ static int aic31xx_set_dai_sysclk(struct snd_soc_dai 
*codec_dai,
if (freq/i > 2000) {
dev_err(aic31xx->dev, "%s: Too high mclk frequency %u\n",
__func__, freq);
-   return -EINVAL;
+   return -EINVAL;
}
aic31xx->p_div = i;
 
-- 
2.19.1



Applied "ASoC: amd: fix spelling mistake "Inavlid" -> "Invalid"" to the asoc tree

2018-11-16 Thread Mark Brown
The patch

   ASoC: amd: fix spelling mistake "Inavlid" -> "Invalid"

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 00347e4ea8ca4c6ed5e254d7cebad0917175a07e Mon Sep 17 00:00:00 2001
From: Colin Ian King 
Date: Fri, 16 Nov 2018 13:39:43 +
Subject: [PATCH] ASoC: amd: fix spelling mistake "Inavlid" -> "Invalid"

There is a spelling mistake in a dev_err message. Fix this.

Signed-off-by: Colin Ian King 
Signed-off-by: Mark Brown 
---
 sound/soc/amd/raven/pci-acp3x.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/amd/raven/pci-acp3x.c b/sound/soc/amd/raven/pci-acp3x.c
index ef805e71a98f..c28457fd9b81 100644
--- a/sound/soc/amd/raven/pci-acp3x.c
+++ b/sound/soc/amd/raven/pci-acp3x.c
@@ -105,7 +105,7 @@ static int snd_acp3x_probe(struct pci_dev *pci,
}
break;
default:
-   dev_err(>dev, "Inavlid ACP audio mode : %d\n", val);
+   dev_err(>dev, "Invalid ACP audio mode : %d\n", val);
ret = -ENODEV;
goto unmap_mmio;
}
-- 
2.19.1



Applied "ASoC: rt5663: Fix error handling of regulator_set_load" to the asoc tree

2018-11-16 Thread Mark Brown
The patch

   ASoC: rt5663: Fix error handling of regulator_set_load

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 746dca0aebd4d77adccb76c500a60028a900dabb Mon Sep 17 00:00:00 2001
From: Cheng-Yi Chiang 
Date: Fri, 16 Nov 2018 17:28:56 +0800
Subject: [PATCH] ASoC: rt5663: Fix error handling of regulator_set_load

The default implementation of regulator_set_load returns
REGULATOR_MODE_NORMAL, which is positive.  [This was a bug which is
being fixed but the change is valid anyway -- bronie]

rt5663_i2c_probe should only do error handling when return value of
regulator_set_load is negative.
In this case, rt5663_i2c_probe should return error.

Also, consolidate err_irq into err_enable.

Fix the missing goto for temporary regmap and rt5663->regmap.

Signed-off-by: Cheng-Yi Chiang 
Signed-off-by: Mark Brown 
---
 sound/soc/codecs/rt5663.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/sound/soc/codecs/rt5663.c b/sound/soc/codecs/rt5663.c
index 29c059ed0682..da6647015708 100644
--- a/sound/soc/codecs/rt5663.c
+++ b/sound/soc/codecs/rt5663.c
@@ -3525,10 +3525,11 @@ static int rt5663_i2c_probe(struct i2c_client *i2c,
for (i = 0; i < ARRAY_SIZE(rt5663->supplies); i++) {
ret = regulator_set_load(rt5663->supplies[i].consumer,
 RT5663_SUPPLY_CURRENT_UA);
-   if (ret) {
+   if (ret < 0) {
dev_err(>dev,
-   "Failed to set regulator %s, ret: %d\n",
+   "Failed to set regulator load on %s, ret: %d\n",
rt5663->supplies[i].supply, ret);
+   return ret;
}
}
 
@@ -3546,7 +3547,7 @@ static int rt5663_i2c_probe(struct i2c_client *i2c,
ret = PTR_ERR(regmap);
dev_err(>dev, "Failed to allocate temp register map: %d\n",
ret);
-   return ret;
+   goto err_enable;
}
 
ret = regmap_read(regmap, RT5663_VENDOR_ID_2, );
@@ -3579,7 +3580,7 @@ static int rt5663_i2c_probe(struct i2c_client *i2c,
ret = PTR_ERR(rt5663->regmap);
dev_err(>dev, "Failed to allocate register map: %d\n",
ret);
-   return ret;
+   goto err_enable;
}
 
/* reset and calibrate */
@@ -3689,17 +3690,19 @@ static int rt5663_i2c_probe(struct i2c_client *i2c,
rt5663_dai, ARRAY_SIZE(rt5663_dai));
 
if (ret)
-   goto err_irq;
+   goto err_enable;
 
return 0;
 
-err_irq:
+
+   /*
+* Error after enabling regulators should goto err_enable
+* to disable regulators.
+*/
+err_enable:
if (i2c->irq)
free_irq(i2c->irq, rt5663);
 
-err_enable:
-   dev_err(>dev,
-   "%s: Disable regulator after probe error\n", __func__);
regulator_bulk_disable(ARRAY_SIZE(rt5663->supplies), rt5663->supplies);
return ret;
 }
-- 
2.19.1



Applied "ASoC: qcom: clean up indentation, remove extraneous tab" to the asoc tree

2018-11-16 Thread Mark Brown
The patch

   ASoC: qcom: clean up indentation, remove extraneous tab

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From e8d4bf8ae8dbcf635a87883437539fb3e5deb6d4 Mon Sep 17 00:00:00 2001
From: Colin Ian King 
Date: Fri, 16 Nov 2018 15:06:36 +
Subject: [PATCH] ASoC: qcom: clean up indentation, remove extraneous tab

The return statement is indented too much by one level, fix this by
removing the extraneous tab.

Signed-off-by: Colin Ian King 
Signed-off-by: Mark Brown 
---
 sound/soc/qcom/lpass-platform.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/qcom/lpass-platform.c b/sound/soc/qcom/lpass-platform.c
index d07271ea4c45..028bce671cbc 100644
--- a/sound/soc/qcom/lpass-platform.c
+++ b/sound/soc/qcom/lpass-platform.c
@@ -91,7 +91,7 @@ static int lpass_platform_pcmops_open(struct 
snd_pcm_substream *substream)
if (ret) {
dev_err(soc_runtime->dev,
"error writing to rdmactl reg: %d\n", ret);
-   return ret;
+   return ret;
}
 
data->dma_ch = dma_ch;
-- 
2.19.1



[PATCH] regulator: Fix return value of _set_load() stub

2018-11-16 Thread Mark Brown
The stub implementation of _set_load() returns a mode value which is
within the bounds of valid return codes for success (the documentation
just says that failures are negative error codes) but not sensible or
what the actual implementation does.  Fix it to just return 0.

Reported-by: Cheng-Yi Chiang 
Signed-off-by: Mark Brown 
---
 include/linux/regulator/consumer.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/regulator/consumer.h 
b/include/linux/regulator/consumer.h
index 25602afd4844..f3f76051e8b0 100644
--- a/include/linux/regulator/consumer.h
+++ b/include/linux/regulator/consumer.h
@@ -508,7 +508,7 @@ static inline int regulator_get_error_flags(struct 
regulator *regulator,
 
 static inline int regulator_set_load(struct regulator *regulator, int load_uA)
 {
-   return REGULATOR_MODE_NORMAL;
+   return 0;
 }
 
 static inline int regulator_allow_bypass(struct regulator *regulator,
-- 
2.19.1



Re: [PATCH] ASoC: rt5663: Fix error handling of regulator_set_load

2018-11-16 Thread Mark Brown
On Fri, Nov 16, 2018 at 05:28:56PM +0800, Cheng-Yi Chiang wrote:
> The default implementation of regulator_set_load returns
> REGULATOR_MODE_NORMAL, which is positive.

The stub does indeed do that however that just looks like a bug - the
actual implementation returns 0 on success and the other users don't
seem to expect to get a mode value back.

> rt5663_i2c_probe should only do error handling when return value of
> regulator_set_load is negative.
> In this case, rt5663_i2c_probe should return error.

However that's also true so the patch is valid.


signature.asc
Description: PGP signature


Re: [PATCH] ASoC: imx-audmux: complete dt-bindings for imx6

2018-11-16 Thread Mark Brown
On Fri, Nov 16, 2018 at 10:45:22PM +0800, Shawn Guo wrote:
> On Fri, Nov 16, 2018 at 11:25:07AM +0100, Clément Péron wrote:

> > It's still quite new for me to submit patch, but if this patch should
> > be sent to ASoC maintainer maybe there is a line missing in the
> > MAINTAINERS file no ?

> @Mark, comment?

Adding a file pattern for this seems sensible, yes.


signature.asc
Description: PGP signature


Re: [PATCH] riscv: fix warning in arch/riscv/include/asm/module.h

2018-11-16 Thread Olof Johansson
On Thu, Nov 8, 2018 at 11:32 AM Palmer Dabbelt  wrote:
>
> On Thu, 08 Nov 2018 11:07:00 PST (-0800), david.abdurachma...@gmail.com wrote:
> > Fixes warning: 'struct module' declared inside parameter list will not be
> > visible outside of this definition or declaration
> >
> > Signed-off-by: David Abdurachmanov 
> > ---
> >  arch/riscv/include/asm/module.h | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/riscv/include/asm/module.h 
> > b/arch/riscv/include/asm/module.h
> > index 349df33808c4..cd2af4b013e3 100644
> > --- a/arch/riscv/include/asm/module.h
> > +++ b/arch/riscv/include/asm/module.h
> > @@ -8,6 +8,7 @@
> >
> >  #define MODULE_ARCH_VERMAGIC"riscv"
> >
> > +struct module;
> >  u64 module_emit_got_entry(struct module *mod, u64 val);
> >  u64 module_emit_plt_entry(struct module *mod, u64 val);
>
> Works for me.  Looks like arm64 might have exactly the same issue.  I'll roll
> it up into the next RC.

Looks like it's still here in -next. So, patch:

Acked-by: Olof Johansson 

(and it'd be great to pickup together with the 32-bit build fix).


-Olof


Re: [RFC PATCH 01/13] arm: Fix mutual exclusion in arch_gettimeoffset

2018-11-16 Thread Michael Schmitz

Hi Finn,

Am 17.11.2018 um 11:49 schrieb Finn Thain:

On Fri, 16 Nov 2018, Russell King - ARM Linux wrote:



The EBSA110 is probably in a similar boat - I don't remember whether it
had 16MB or 32MB as the maximal amount of memory, but memory was getting
tight with some kernels even running a minimalist userspace.

So, it's probably time to say goodbyte to the kernel support for these
platforms.



Your call.

Note that removing code from mainline won't help users obtain older,
smaller, -stable kernel releases, free from the bug we were discussing.
(The bug appeared in Linux v2.6.32.)

BTW, if you did want to boot Linux on a 16 MB system, you do have some
options.

https://lwn.net/Articles/741494/
https://lwn.net/Articles/608945/
https://tiny.wiki.kernel.org/

Contributing to this kind of effort probably has value for IoT
deployments. I suspect it also cuts a small amount of bloat from a large
number of other Linux systems.


I boot 4.19 on a system with 14 MB RAM - 10 MB remain for user space 
once the kernel loads. After remote login, 4 MB of that remain free for 
buffers or user code (1.5 MB swapped).
That's with sysvinit - Christian tried to boot a systemd userland on his 
Falcon once, and ran out of memory before swap could be activated.


I shouldn't say 16 or 32 MB are hopeless. And the 2.6 kernels were a lot 
more sluggish to my recollection.


Cheers,

Michael


Re: [PATCH] arm64: Explicitly mark 64-bit constant as unsigned long

2018-11-16 Thread Olof Johansson
On Fri, Nov 16, 2018 at 6:27 PM Will Deacon  wrote:
>
> Hi Olof,
>
> On Fri, Nov 16, 2018 at 05:54:56PM -0800, Olof Johansson wrote:
> > Makes sparse happy. Before:
> >
> > arch/arm64/include/asm/sysreg.h:471:42: warning: constant 
> > 0x is so big it is unsigned long
> > arch/arm64/include/asm/sysreg.h:512:42: warning: constant 
> > 0x is so big it is unsigned long
> >
> > Signed-off-by: Olof Johansson 
> > ---
> >  arch/arm64/include/asm/sysreg.h | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
>
> The warning is bogus imo, but since it's harmless to fix it then we can do
> that. However, you've been beaten by:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2018-November/613179.html

Yeah, mostly bogus but still useful to silence warnings so you notice new ones.

Overlooked the duplicate, happy to ack that one instead.


-Olof


Re: [PATCH] mm: use this_cpu_cmpxchg_double in put_cpu_partial

2018-11-16 Thread Wei Yang
On Fri, Nov 16, 2018 at 05:33:35PM -0800, Wengang Wang wrote:
>The this_cpu_cmpxchg makes the do-while loop pass as long as the
>s->cpu_slab->partial as the same value. It doesn't care what happened to
>that slab. Interrupt is not disabled, and new alloc/free can happen in the
>interrupt handlers. Theoretically, after we have a reference to the it,
>stored in _oldpage_, the first slab on the partial list on this CPU can be
>moved to kmem_cache_node and then moved to different kmem_cache_cpu and
>then somehow can be added back as head to partial list of current
>kmem_cache_cpu, though that is a very rare case. If that rare case really

I didn't fully catch up with this case.

When put_cpu_partial() is called, this means we are trying to freeze an
frozen page and this pages is fully occupied. Since page->freelist is
NULL.

A full page is supposed to be on no where when has_cpu_partial() is
true.

So I don't understand when it will be moved to different kmem_cache_cpu.

>happened, the reading of oldpage->pobjects may get a 0xdead
>unexpectedly, stored in _pobjects_, if the reading happens just after
>another CPU removed the slab from kmem_cache_node, setting lru.prev to
>LIST_POISON2 (0xdead0200). The wrong _pobjects_(negative) then
>prevents slabs from being moved to kmem_cache_node and being finally freed.

Looks this page is removed from some list. This happens in which case? I
mean the page is previouly on which list?

>
>We see in a vmcore, there are 375210 slabs kept in the partial list of one
>kmem_cache_cpu, but only 305 in-use objects in the same list for
>kmalloc-2048 cache. We see negative values for page.pobjects, the last page
>with negative _pobjects_ has the value of 0xdead0004, the next page looks
>good (_pobjects is 1).
>
>For the fix, I wanted to call this_cpu_cmpxchg_double with
>oldpage->pobjects, but failed due to size difference between
>oldpage->pobjects and cpu_slab->partial. So I changed to call
>this_cpu_cmpxchg_double with _tid_. I don't really want no alloc/free
>happen in between, but just want to make sure the first slab did expereince
>a remove and re-add. This patch is more to call for ideas.
>
>Signed-off-by: Wengang Wang 
>---
> mm/slub.c | 20 +---
> 1 file changed, 17 insertions(+), 3 deletions(-)
>
>diff --git a/mm/slub.c b/mm/slub.c
>index e3629cd..26539e6 100644
>--- a/mm/slub.c
>+++ b/mm/slub.c
>@@ -2248,6 +2248,7 @@ static void put_cpu_partial(struct kmem_cache *s, struct 
>page *page, int drain)
> {
> #ifdef CONFIG_SLUB_CPU_PARTIAL
>   struct page *oldpage;
>+  unsigned long tid;
>   int pages;
>   int pobjects;
> 
>@@ -2255,8 +2256,12 @@ static void put_cpu_partial(struct kmem_cache *s, 
>struct page *page, int drain)
>   do {
>   pages = 0;
>   pobjects = 0;
>-  oldpage = this_cpu_read(s->cpu_slab->partial);
> 
>+  tid = this_cpu_read(s->cpu_slab->tid);
>+  /* read tid before reading oldpage */
>+  barrier();
>+
>+  oldpage = this_cpu_read(s->cpu_slab->partial);
>   if (oldpage) {
>   pobjects = oldpage->pobjects;
>   pages = oldpage->pages;
>@@ -2283,8 +2288,17 @@ static void put_cpu_partial(struct kmem_cache *s, 
>struct page *page, int drain)
>   page->pobjects = pobjects;
>   page->next = oldpage;
> 
>-  } while (this_cpu_cmpxchg(s->cpu_slab->partial, oldpage, page)
>-  != oldpage);
>+  /* we dont' change tid, but want to make sure it didn't change
>+   * in between. We don't really hope alloc/free not happen on
>+   * this CPU, but don't want the first slab be removed from and
>+   * then re-added as head to this partial list. If that case
>+   * happened, pobjects may read 0xdead when this slab is just
>+   * removed from kmem_cache_node by other CPU setting lru.prev
>+   * to LIST_POISON2.
>+   */
>+  } while (this_cpu_cmpxchg_double(s->cpu_slab->partial, s->cpu_slab->tid,
>+   oldpage, tid, page, tid) == 0);
>+
>   if (unlikely(!s->cpu_partial)) {
>   unsigned long flags;
> 
>-- 
>2.9.5

-- 
Wei Yang
Help you, Help me


Re: [PATCH] staging: gasket: formatting fixes

2018-11-16 Thread Todd Poynor
On Mon, Nov 12, 2018 at 1:27 PM Robert Deal
 wrote:
>
> Reformat arguments in a few functions in gasket_page_table.c to better
> follow linux kernel formatting standards.
>
> Signed-off-by: Robert Deal 
> ---
>  drivers/staging/gasket/gasket_page_table.c | 24 ++
>  1 file changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/staging/gasket/gasket_page_table.c 
> b/drivers/staging/gasket/gasket_page_table.c
> index f5253ba9a430..26755d9ca41d 100644
> --- a/drivers/staging/gasket/gasket_page_table.c
> +++ b/drivers/staging/gasket/gasket_page_table.c
> @@ -1088,9 +1088,9 @@ void gasket_page_table_reset(struct gasket_page_table 
> *pg_tbl)
>  }
>
>  /* See gasket_page_table.h for description. */
> -int gasket_page_table_lookup_page(
> -   struct gasket_page_table *pg_tbl, ulong dev_addr, struct page **ppage,
> -   ulong *poffset)
> +int gasket_page_table_lookup_page(struct gasket_page_table *pg_tbl,
> + ulong dev_addr, struct page **ppage,
> + ulong *poffset)
>  {
> uint page_num;
> struct gasket_page_table_entry *pte;
> @@ -1134,9 +1134,9 @@ int gasket_page_table_lookup_page(
>  }
>
>  /* See gasket_page_table.h for description. */
> -bool gasket_page_table_are_addrs_bad(
> -   struct gasket_page_table *pg_tbl, ulong host_addr, ulong dev_addr,
> -   ulong bytes)
> +bool gasket_page_table_are_addrs_bad(struct gasket_page_table *pg_tbl,
> +ulong host_addr, ulong dev_addr,
> +ulong bytes)
>  {
> if (host_addr & (PAGE_SIZE - 1)) {
> dev_err(pg_tbl->device,
> @@ -1150,8 +1150,8 @@ bool gasket_page_table_are_addrs_bad(
>  EXPORT_SYMBOL(gasket_page_table_are_addrs_bad);
>
>  /* See gasket_page_table.h for description. */
> -bool gasket_page_table_is_dev_addr_bad(
> -   struct gasket_page_table *pg_tbl, ulong dev_addr, ulong bytes)
> +bool gasket_page_table_is_dev_addr_bad(struct gasket_page_table *pg_tbl,
> +  ulong dev_addr, ulong bytes)
>  {
> uint num_pages = bytes / PAGE_SIZE;
>
> @@ -1226,9 +1226,8 @@ int gasket_page_table_system_status(struct 
> gasket_page_table *page_table)
>  }
>
>  /* Record the host_addr to coherent dma memory mapping. */
> -int gasket_set_user_virt(
> -   struct gasket_dev *gasket_dev, u64 size, dma_addr_t dma_address,
> -   ulong vma)
> +int gasket_set_user_virt(struct gasket_dev *gasket_dev, u64 size,
> +dma_addr_t dma_address, ulong vma)
>  {
> int j;
> struct gasket_page_table *pg_tbl;
> @@ -1346,8 +1345,7 @@ int gasket_free_coherent_memory(struct gasket_dev 
> *gasket_dev, u64 size,
>  }
>
>  /* Release all coherent memory. */
> -void gasket_free_coherent_memory_all(
> -   struct gasket_dev *gasket_dev, u64 index)
> +void gasket_free_coherent_memory_all(struct gasket_dev *gasket_dev, u64 
> index)
>  {
> if (!gasket_dev->page_table[index])
> return;
> --
> 2.17.1
>

Acked-by: Todd Poynor 

Thanks!


Re: [PATCH v2] riscv: add asm/unistd.h UAPI header

2018-11-16 Thread Olof Johansson
On Thu, Nov 8, 2018 at 11:02 AM David Abdurachmanov
 wrote:
>
> Marcin Juszkiewicz reported issues while generating syscall table for riscv
> using 4.20-rc1. The patch refactors our unistd.h files to match some other
> architectures.
>
> - Add asm/unistd.h UAPI header, which has __ARCH_WANT_NEW_STAT only for 64-bit
> - Remove asm/syscalls.h UAPI header and merge to asm/unistd.h
> - Adjust kernel asm/unistd.h
>
> So now asm/unistd.h UAPI header should show all syscalls for riscv.
>
> Before this, Makefile simply put `#include ` into
> generated asm/unistd.h UAPI header thus user didn't see:
>
> - __NR_riscv_flush_icache
> - __NR_newfstatat
> - __NR_fstat
>
> which are supported by riscv kernel.
>
> Signed-off-by: David Abdurachmanov 
> Cc: Arnd Bergmann 
> Cc: Marcin Juszkiewicz 
> Cc: Guenter Roeck 
> Fixes: 67314ec7b025 ("RISC-V: Request newstat syscalls")
> Signed-off-by: David Abdurachmanov 

Acked-by: Olof Johansson 

This fixes the 32-bit build error I'm seeing here as well. Palmer, it
would be nice to have 4.20 compile 32-bit kernels still.

Per builder logs:
http://arm-soc.lixom.net/buildlogs/mainline/v4.20-rc2-133-g1ce80e0fe98e7/buildall.riscv.rv32_defconfig.log.failed,
actual errors are:

include/uapi/asm-generic/unistd.h:247:29: error: 'sys_fstatat64'
undeclared here (not in a function); did you mean 'sys_fstatfs64'?
include/uapi/asm-generic/unistd.h:249:27: error: 'sys_fstat64'
undeclared here (not in a function); did you mean 'sys_fstatat64'?


-Olof


[Patch v5 09/16] x86/smt: Convert cpu_smt_control check to cpu_smt_enabled static key

2018-11-16 Thread Tim Chen
The checks to cpu_smt_control outside of kernel/cpu.c can be converted
to use cpu_smt_enabled key to run SMT specific code.

Save the export of cpu_smt_control and convert usage of cpu_smt_control
to cpu_smt_enabled outside of kernel/cpu.c.

Signed-off-by: Tim Chen 
---
 arch/x86/kernel/cpu/bugs.c | 21 +++--
 arch/x86/kvm/vmx.c |  2 +-
 include/linux/cpu.h|  8 
 kernel/cpu.c   |  9 -
 4 files changed, 24 insertions(+), 16 deletions(-)

diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index e4cfc4a..6e1b910 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -356,15 +356,16 @@ void arch_smt_update(void)
 
mutex_lock(_ctrl_mutex);
mask = x86_spec_ctrl_base;
-   if (cpu_smt_control == CPU_SMT_ENABLED)
+   if (static_branch_likely(_smt_enabled))
mask |= SPEC_CTRL_STIBP;
else
mask &= ~SPEC_CTRL_STIBP;
 
if (mask != x86_spec_ctrl_base) {
-   pr_info("Spectre v2 cross-process SMT mitigation: %s STIBP\n",
-   cpu_smt_control == CPU_SMT_ENABLED ?
-   "Enabling" : "Disabling");
+   if (static_branch_likely(_smt_enabled))
+   pr_info("Spectre v2 cross-process SMT mitigation: 
Enabling STIBP\n");
+   else
+   pr_info("Spectre v2 cross-process SMT mitigation: 
Disabling STIBP\n");
x86_spec_ctrl_base = mask;
on_each_cpu(update_stibp_msr, NULL, 1);
}
@@ -840,6 +841,14 @@ static const char *l1tf_vmx_states[] = {
[VMENTER_L1D_FLUSH_NOT_REQUIRED]= "flush not necessary"
 };
 
+static char *l1tf_show_smt_vulnerable(void)
+{
+   if (static_branch_likely(_smt_enabled))
+   return "vulnerable";
+   else
+   return "disabled";
+}
+
 static ssize_t l1tf_show_state(char *buf)
 {
if (l1tf_vmx_mitigation == VMENTER_L1D_FLUSH_AUTO)
@@ -847,13 +856,13 @@ static ssize_t l1tf_show_state(char *buf)
 
if (l1tf_vmx_mitigation == VMENTER_L1D_FLUSH_EPT_DISABLED ||
(l1tf_vmx_mitigation == VMENTER_L1D_FLUSH_NEVER &&
-cpu_smt_control == CPU_SMT_ENABLED))
+static_branch_likely(_smt_enabled)))
return sprintf(buf, "%s; VMX: %s\n", L1TF_DEFAULT_MSG,
   l1tf_vmx_states[l1tf_vmx_mitigation]);
 
return sprintf(buf, "%s; VMX: %s, SMT %s\n", L1TF_DEFAULT_MSG,
   l1tf_vmx_states[l1tf_vmx_mitigation],
-  cpu_smt_control == CPU_SMT_ENABLED ? "vulnerable" : 
"disabled");
+  l1tf_show_smt_vulnerable());
 }
 #else
 static ssize_t l1tf_show_state(char *buf)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 4555077..accfd2c 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -11607,7 +11607,7 @@ static int vmx_vm_init(struct kvm *kvm)
 * Warn upon starting the first VM in a potentially
 * insecure environment.
 */
-   if (cpu_smt_control == CPU_SMT_ENABLED)
+   if (static_branch_likely(_smt_enabled))
pr_warn_once(L1TF_MSG_SMT);
if (l1tf_vmx_mitigation == VMENTER_L1D_FLUSH_NEVER)
pr_warn_once(L1TF_MSG_L1D);
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index b54f085..00af2ae 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -170,15 +170,7 @@ void cpuhp_report_idle_dead(void);
 static inline void cpuhp_report_idle_dead(void) { }
 #endif /* #ifdef CONFIG_HOTPLUG_CPU */
 
-enum cpuhp_smt_control {
-   CPU_SMT_ENABLED,
-   CPU_SMT_DISABLED,
-   CPU_SMT_FORCE_DISABLED,
-   CPU_SMT_NOT_SUPPORTED,
-};
-
 #if defined(CONFIG_SMP) && defined(CONFIG_HOTPLUG_SMT)
-extern enum cpuhp_smt_control cpu_smt_control;
 extern void cpu_smt_disable(bool force);
 extern void cpu_smt_check_topology_early(void);
 extern void cpu_smt_check_topology(void);
diff --git a/kernel/cpu.c b/kernel/cpu.c
index e216154..54cf3f6 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -368,8 +368,15 @@ static void lockdep_release_cpus_lock(void)
 #endif /* CONFIG_HOTPLUG_CPU */
 
 #ifdef CONFIG_HOTPLUG_SMT
+
+enum cpuhp_smt_control {
+CPU_SMT_ENABLED,
+CPU_SMT_DISABLED,
+CPU_SMT_FORCE_DISABLED,
+CPU_SMT_NOT_SUPPORTED,
+};
+
 enum cpuhp_smt_control cpu_smt_control __read_mostly = CPU_SMT_ENABLED;
-EXPORT_SYMBOL_GPL(cpu_smt_control);
 DEFINE_STATIC_KEY_TRUE(cpu_smt_enabled);
 EXPORT_SYMBOL_GPL(cpu_smt_enabled);
 
-- 
2.9.4



[Patch v5 08/16] smt: Create cpu_smt_enabled static key for SMT specific code

2018-11-16 Thread Tim Chen
In later code, STIBP will be turned on/off in the context switch code
path when SMT is enabled.  Checks for SMT is best
avoided on such hot paths.

Create cpu_smt_enabled static key to turn on such SMT specific code
statically.

This key is set in code under hot plug, so it is limited in
scope to architecture supporting CPU hotplug, like x86.

Signed-off-by: Tim Chen 
---
 include/linux/cpu.h |  1 +
 kernel/cpu.c| 12 ++--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index 218df7f..b54f085 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -188,5 +188,6 @@ static inline void cpu_smt_disable(bool force) { }
 static inline void cpu_smt_check_topology_early(void) { }
 static inline void cpu_smt_check_topology(void) { }
 #endif
+DECLARE_STATIC_KEY_TRUE(cpu_smt_enabled);
 
 #endif /* _LINUX_CPU_H_ */
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 3c7f3b4..e216154 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -370,6 +370,8 @@ static void lockdep_release_cpus_lock(void)
 #ifdef CONFIG_HOTPLUG_SMT
 enum cpuhp_smt_control cpu_smt_control __read_mostly = CPU_SMT_ENABLED;
 EXPORT_SYMBOL_GPL(cpu_smt_control);
+DEFINE_STATIC_KEY_TRUE(cpu_smt_enabled);
+EXPORT_SYMBOL_GPL(cpu_smt_enabled);
 
 static bool cpu_smt_available __read_mostly;
 
@@ -386,6 +388,7 @@ void __init cpu_smt_disable(bool force)
pr_info("SMT: disabled\n");
cpu_smt_control = CPU_SMT_DISABLED;
}
+   static_branch_disable(_smt_enabled);
 }
 
 /*
@@ -395,8 +398,10 @@ void __init cpu_smt_disable(bool force)
  */
 void __init cpu_smt_check_topology_early(void)
 {
-   if (!topology_smt_supported())
+   if (!topology_smt_supported()) {
cpu_smt_control = CPU_SMT_NOT_SUPPORTED;
+   static_branch_disable(_smt_enabled);
+   }
 }
 
 /*
@@ -408,8 +413,10 @@ void __init cpu_smt_check_topology_early(void)
  */
 void __init cpu_smt_check_topology(void)
 {
-   if (!cpu_smt_available)
+   if (!cpu_smt_available) {
cpu_smt_control = CPU_SMT_NOT_SUPPORTED;
+   static_branch_disable(_smt_enabled);
+   }
 }
 
 static int __init smt_cmdline_disable(char *str)
@@ -2101,6 +2108,7 @@ static int cpuhp_smt_enable(void)
 
cpu_maps_update_begin();
cpu_smt_control = CPU_SMT_ENABLED;
+   static_branch_enable(_smt_enabled);
arch_smt_update();
for_each_present_cpu(cpu) {
/* Skip online CPUs and CPUs on offline nodes */
-- 
2.9.4



[Patch v5 04/16] x86/speculation: Add X86_FEATURE_USE_IBRS_ENHANCED

2018-11-16 Thread Tim Chen
STIBP is not needed when enhanced IBRS is used for Spectre V2 mitigation.
A CPU feature flag to indicate that enhanced IBRS is used will be handy
for skipping STIBP for this case.

Add X86_FEATURE_USE_IBRS_ENHANCED feature bit to indicate
enhanced IBRS is used for Spectre V2 mitigation.

Signed-off-by: Tim Chen 
---
 arch/x86/include/asm/cpufeatures.h | 1 +
 arch/x86/kernel/cpu/bugs.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/x86/include/asm/cpufeatures.h 
b/arch/x86/include/asm/cpufeatures.h
index 28c4a50..fe8e064 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -221,6 +221,7 @@
 #define X86_FEATURE_ZEN( 7*32+28) /* "" CPU is AMD 
family 0x17 (Zen) */
 #define X86_FEATURE_L1TF_PTEINV( 7*32+29) /* "" L1TF 
workaround PTE inversion */
 #define X86_FEATURE_IBRS_ENHANCED  ( 7*32+30) /* Enhanced IBRS */
+#define X86_FEATURE_USE_IBRS_ENHANCED  ( 7*32+31) /* "" Enhanced IBRS enabled 
*/
 
 /* Virtualization flags: Linux defined, word 8 */
 #define X86_FEATURE_TPR_SHADOW ( 8*32+ 0) /* Intel TPR Shadow */
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 91a754a..3a6f13b 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -387,6 +387,7 @@ static void __init spectre_v2_select_mitigation(void)
/* Force it so VMEXIT will restore correctly */
x86_spec_ctrl_base |= SPEC_CTRL_IBRS;
wrmsrl(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base);
+   setup_force_cpu_cap(X86_FEATURE_USE_IBRS_ENHANCED);
goto specv2_set_mode;
}
if (IS_ENABLED(CONFIG_RETPOLINE))
-- 
2.9.4



[Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes

2018-11-16 Thread Tim Chen
Add new protection modes for Spectre v2 mitigations against
Spectre v2 attacks on user processes.  There are three modes:

strict mode:
In this mode, IBPB and STIBP are deployed full
time to protect all processes.

lite mode:
In this mode, IBPB and STIBP are only deployed on
processes marked with TIF_STIBP flag.

none mode:
In this mode, no mitigations are deployed.

The protection mode can be specified by the spectre_v2_app2app
boot parameter with the following semantics:

spectre_v2_app2app=
off- Turn off mitigation
lite   - Protect processes which are marked non-dumpable
strict - Protect all processes
auto   - Kernel selects the mode

Not specifying this option is equivalent to
spectre_v2_app2app=auto.

Setting spectre_v2=off will also turn off this mitigation.

Setting spectre_v2=on implies unconditionally enabling
this mitigation.

Signed-off-by: Tim Chen 
---
 Documentation/admin-guide/kernel-parameters.txt |  20 
 arch/x86/include/asm/nospec-branch.h|   9 ++
 arch/x86/kernel/cpu/bugs.c  | 153 +---
 arch/x86/mm/tlb.c   |  23 +++-
 4 files changed, 185 insertions(+), 20 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 81d1d5a..9c306e3 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4215,6 +4215,26 @@
Not specifying this option is equivalent to
spectre_v2=auto.
 
+   spectre_v2_app2app=
+   [X86] Control mitigation of Spectre variant 2
+   application to application (indirect branch speculation)
+   vulnerability.
+
+   off- Unconditionally disable mitigations
+   lite   - Protect tasks which have requested restricted
+indirect branch speculation via the
+PR_SET_SPECULATION_CTRL prctl(). 
+   strict - Protect all processes
+   auto   - Kernel selects the mode
+
+   Not specifying this option is equivalent to
+   spectre_v2_app2app=auto.
+
+   Setting spectre_v2=off will also turn off this 
mitigation.
+
+   Setting spectre_v2=on implies unconditionally enabling
+   this mitigation.
+
spec_store_bypass_disable=
[HW] Control Speculative Store Bypass (SSB) Disable 
mitigation
(Speculative Store Bypass vulnerability)
diff --git a/arch/x86/include/asm/nospec-branch.h 
b/arch/x86/include/asm/nospec-branch.h
index 80dc144..587629d 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -3,6 +3,7 @@
 #ifndef _ASM_X86_NOSPEC_BRANCH_H_
 #define _ASM_X86_NOSPEC_BRANCH_H_
 
+#include 
 #include 
 #include 
 #include 
@@ -226,6 +227,12 @@ enum spectre_v2_mitigation {
SPECTRE_V2_IBRS_ENHANCED,
 };
 
+enum spectre_v2_app2app_mitigation {
+   SPECTRE_V2_APP2APP_NONE,
+   SPECTRE_V2_APP2APP_LITE,
+   SPECTRE_V2_APP2APP_STRICT,
+};
+
 /* The Speculative Store Bypass disable variants */
 enum ssb_mitigation {
SPEC_STORE_BYPASS_NONE,
@@ -237,6 +244,8 @@ enum ssb_mitigation {
 extern char __indirect_thunk_start[];
 extern char __indirect_thunk_end[];
 
+DECLARE_STATIC_KEY_FALSE(spectre_v2_app_lite);
+
 /*
  * On VMEXIT we must ensure that no RSB predictions learned in the guest
  * can be followed in the host, by overwriting the RSB completely. Both
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 6e1b910..21caade 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -133,6 +133,14 @@ enum spectre_v2_mitigation_cmd {
SPECTRE_V2_CMD_RETPOLINE_AMD,
 };
 
+enum spectre_v2_app2app_mitigation_cmd {
+   SPECTRE_V2_APP2APP_CMD_NONE,
+   SPECTRE_V2_APP2APP_CMD_AUTO,
+   SPECTRE_V2_APP2APP_CMD_FORCE,
+   SPECTRE_V2_APP2APP_CMD_LITE,
+   SPECTRE_V2_APP2APP_CMD_STRICT,
+};
+
 static const char *spectre_v2_strings[] = {
[SPECTRE_V2_NONE]   = "Vulnerable",
[SPECTRE_V2_RETPOLINE_MINIMAL]  = "Vulnerable: Minimal generic 
ASM retpoline",
@@ -142,12 +150,24 @@ static const char *spectre_v2_strings[] = {
[SPECTRE_V2_IBRS_ENHANCED]  = "Mitigation: Enhanced IBRS",
 };
 
+static const char *spectre_v2_app2app_strings[] = {
+   [SPECTRE_V2_APP2APP_NONE]   = "App-App Vulnerable",
+   [SPECTRE_V2_APP2APP_LITE]   = "App-App Mitigation: Protect branch 
speculation restricted tasks",
+   [SPECTRE_V2_APP2APP_STRICT] = "App-App Mitigation: Full app to app 

[Patch v5 02/16] x86/speculation: Remove unnecessary ret variable in cpu_show_common()

2018-11-16 Thread Tim Chen
Remove unnecessary ret variable in cpu_show_common() to make the
code more concise.

Signed-off-by: Tim Chen 
---
 arch/x86/kernel/cpu/bugs.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 5ac7070..84e3579 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -856,8 +856,6 @@ static ssize_t l1tf_show_state(char *buf)
 static ssize_t cpu_show_common(struct device *dev, struct device_attribute 
*attr,
   char *buf, unsigned int bug)
 {
-   int ret;
-
if (!boot_cpu_has_bug(bug))
return sprintf(buf, "Not affected\n");
 
@@ -875,13 +873,12 @@ static ssize_t cpu_show_common(struct device *dev, struct 
device_attribute *attr
return sprintf(buf, "Mitigation: __user pointer 
sanitization\n");
 
case X86_BUG_SPECTRE_V2:
-   ret = sprintf(buf, "%s%s%s%s%s%s\n", 
spectre_v2_strings[spectre_v2_enabled],
+   return sprintf(buf, "%s%s%s%s%s%s\n", 
spectre_v2_strings[spectre_v2_enabled],
   boot_cpu_has(X86_FEATURE_USE_IBPB) ? ", IBPB" : 
"",
   boot_cpu_has(X86_FEATURE_USE_IBRS_FW) ? ", 
IBRS_FW" : "",
   (x86_spec_ctrl_base & SPEC_CTRL_STIBP) ? ", 
STIBP" : "",
   boot_cpu_has(X86_FEATURE_RSB_CTXSW) ? ", RSB 
filling" : "",
   spectre_v2_module_string());
-   return ret;
 
case X86_BUG_SPEC_STORE_BYPASS:
return sprintf(buf, "%s\n", ssb_strings[ssb_mode]);
-- 
2.9.4



[Patch v5 10/16] x86/speculation: Turn on or off STIBP according to a task's TIF_STIBP

2018-11-16 Thread Tim Chen
If STIBP is used all the time, tasks that do not need STIBP
protection will get unnecessarily slowed down by STIBP.

To apply STIBP only to tasks that need it, a new task TIF_STIBP flag is
created. A x86 CPU uses STIBP only for tasks labeled with TIF_STIBP.

During context switch, this flag is checked and the STIBP bit in SPEC_CTRL
MSR is updated according to changes in this flag between previous and
next task.

Signed-off-by: Tim Chen 
---
 arch/x86/include/asm/msr-index.h   |  6 +-
 arch/x86/include/asm/spec-ctrl.h   | 12 
 arch/x86/include/asm/thread_info.h |  5 -
 arch/x86/kernel/process.c  | 10 +-
 4 files changed, 30 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 80f4a4f..501c9d3 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -41,7 +41,11 @@
 
 #define MSR_IA32_SPEC_CTRL 0x0048 /* Speculation Control */
 #define SPEC_CTRL_IBRS (1 << 0)   /* Indirect Branch 
Restricted Speculation */
-#define SPEC_CTRL_STIBP(1 << 1)   /* Single Thread 
Indirect Branch Predictors */
+#define SPEC_CTRL_STIBP_SHIFT  1  /*
+   * Single Thread Indirect 
Branch
+   * Predictor (STIBP) bit
+   */
+#define SPEC_CTRL_STIBP(1 << SPEC_CTRL_STIBP_SHIFT) /* 
STIBP mask */
 #define SPEC_CTRL_SSBD_SHIFT   2  /* Speculative Store Bypass 
Disable bit */
 #define SPEC_CTRL_SSBD (1 << SPEC_CTRL_SSBD_SHIFT)   /* 
Speculative Store Bypass Disable */
 
diff --git a/arch/x86/include/asm/spec-ctrl.h b/arch/x86/include/asm/spec-ctrl.h
index 8e2f841..b593779 100644
--- a/arch/x86/include/asm/spec-ctrl.h
+++ b/arch/x86/include/asm/spec-ctrl.h
@@ -53,12 +53,24 @@ static inline u64 ssbd_tif_to_spec_ctrl(u64 tifn)
return (tifn & _TIF_SSBD) >> (TIF_SSBD - SPEC_CTRL_SSBD_SHIFT);
 }
 
+static inline u64 stibp_tif_to_spec_ctrl(u64 tifn)
+{
+   BUILD_BUG_ON(TIF_STIBP < SPEC_CTRL_STIBP_SHIFT);
+   return (tifn & _TIF_STIBP) >> (TIF_STIBP - SPEC_CTRL_STIBP_SHIFT);
+}
+
 static inline unsigned long ssbd_spec_ctrl_to_tif(u64 spec_ctrl)
 {
BUILD_BUG_ON(TIF_SSBD < SPEC_CTRL_SSBD_SHIFT);
return (spec_ctrl & SPEC_CTRL_SSBD) << (TIF_SSBD - 
SPEC_CTRL_SSBD_SHIFT);
 }
 
+static inline unsigned long stibp_spec_ctrl_to_tif(u64 spec_ctrl)
+{
+   BUILD_BUG_ON(TIF_STIBP < SPEC_CTRL_STIBP_SHIFT);
+   return (spec_ctrl & SPEC_CTRL_STIBP) << (TIF_STIBP - 
SPEC_CTRL_STIBP_SHIFT);
+}
+
 static inline u64 ssbd_tif_to_amd_ls_cfg(u64 tifn)
 {
return (tifn & _TIF_SSBD) ? x86_amd_ls_cfg_ssbd_mask : 0ULL;
diff --git a/arch/x86/include/asm/thread_info.h 
b/arch/x86/include/asm/thread_info.h
index 2ff2a30..8736d23 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -83,6 +83,7 @@ struct thread_info {
 #define TIF_SYSCALL_EMU6   /* syscall emulation active */
 #define TIF_SYSCALL_AUDIT  7   /* syscall auditing active */
 #define TIF_SECCOMP8   /* secure computing */
+#define TIF_STIBP  9   /* Single thread indirect branch 
speculation */
 #define TIF_USER_RETURN_NOTIFY 11  /* notify kernel of userspace return */
 #define TIF_UPROBE 12  /* breakpointed or singlestepping */
 #define TIF_PATCH_PENDING  13  /* pending live patching update */
@@ -110,6 +111,7 @@ struct thread_info {
 #define _TIF_SYSCALL_EMU   (1 << TIF_SYSCALL_EMU)
 #define _TIF_SYSCALL_AUDIT (1 << TIF_SYSCALL_AUDIT)
 #define _TIF_SECCOMP   (1 << TIF_SECCOMP)
+#define _TIF_STIBP (1 << TIF_STIBP)
 #define _TIF_USER_RETURN_NOTIFY(1 << TIF_USER_RETURN_NOTIFY)
 #define _TIF_UPROBE(1 << TIF_UPROBE)
 #define _TIF_PATCH_PENDING (1 << TIF_PATCH_PENDING)
@@ -146,7 +148,8 @@ struct thread_info {
 
 /* flags to check in __switch_to() */
 #define _TIF_WORK_CTXSW
\
-   (_TIF_IO_BITMAP|_TIF_NOCPUID|_TIF_NOTSC|_TIF_BLOCKSTEP|_TIF_SSBD)
+   (_TIF_IO_BITMAP|_TIF_NOCPUID|_TIF_NOTSC|_TIF_BLOCKSTEP| \
+_TIF_SSBD|_TIF_STIBP)
 
 #define _TIF_WORK_CTXSW_PREV (_TIF_WORK_CTXSW|_TIF_USER_RETURN_NOTIFY)
 #define _TIF_WORK_CTXSW_NEXT (_TIF_WORK_CTXSW)
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 74bef48..943e90d 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -406,6 +406,14 @@ static __always_inline void spec_ctrl_update_msr(unsigned 
long tifn)
if (static_cpu_has(X86_FEATURE_SSBD))
msr |= ssbd_tif_to_spec_ctrl(tifn);
 
+   /*
+* Need STIBP defense against Spectre v2 attack
+* if SMT is in use and enhanced IBRS is unsupported.
+

[Patch v5 06/16] x86/speculation: Rename SSBD update functions

2018-11-16 Thread Tim Chen
During context switch, the SSBD bit in SPEC_CTRL MSR is updated according
to changes in TIF_SSBD flag in the current and next running task.
Currently, only the bit controlling speculative store in SPEC_CTRL MSR
is updated and the related update functions all have "speculative_store"
or "ssb" in their names.

In later patches, other bits controlling STIBP in SPEC_CTRL MSR need
to be updated.  The SPEC_CTRL MSR update functions should get rid of the
speculative store names as they will no longer be limited to SSBD update.

Rename the "speculative_store*" functions to a more generic name.

Signed-off-by: Tim Chen 
---
 arch/x86/include/asm/spec-ctrl.h |  6 +++---
 arch/x86/kernel/cpu/bugs.c   |  4 ++--
 arch/x86/kernel/process.c| 12 ++--
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/x86/include/asm/spec-ctrl.h b/arch/x86/include/asm/spec-ctrl.h
index ae7c2c5..8e2f841 100644
--- a/arch/x86/include/asm/spec-ctrl.h
+++ b/arch/x86/include/asm/spec-ctrl.h
@@ -70,11 +70,11 @@ extern void speculative_store_bypass_ht_init(void);
 static inline void speculative_store_bypass_ht_init(void) { }
 #endif
 
-extern void speculative_store_bypass_update(unsigned long tif);
+extern void speculation_ctrl_update(unsigned long tif);
 
-static inline void speculative_store_bypass_update_current(void)
+static inline void speculation_ctrl_update_current(void)
 {
-   speculative_store_bypass_update(current_thread_info()->flags);
+   speculation_ctrl_update(current_thread_info()->flags);
 }
 
 #endif
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 5c0eb2f..e4cfc4a 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -202,7 +202,7 @@ x86_virt_spec_ctrl(u64 guest_spec_ctrl, u64 
guest_virt_spec_ctrl, bool setguest)
tif = setguest ? ssbd_spec_ctrl_to_tif(guestval) :
 ssbd_spec_ctrl_to_tif(hostval);
 
-   speculative_store_bypass_update(tif);
+   speculation_ctrl_update(tif);
}
 }
 EXPORT_SYMBOL_GPL(x86_virt_spec_ctrl);
@@ -646,7 +646,7 @@ static int ssb_prctl_set(struct task_struct *task, unsigned 
long ctrl)
 * mitigation until it is next scheduled.
 */
if (task == current && update)
-   speculative_store_bypass_update_current();
+   speculation_ctrl_update_current();
 
return 0;
 }
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index c93fcfd..8aa4960 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -395,27 +395,27 @@ static __always_inline void 
amd_set_ssb_virt_state(unsigned long tifn)
wrmsrl(MSR_AMD64_VIRT_SPEC_CTRL, ssbd_tif_to_spec_ctrl(tifn));
 }
 
-static __always_inline void intel_set_ssb_state(unsigned long tifn)
+static __always_inline void spec_ctrl_update_msr(unsigned long tifn)
 {
u64 msr = x86_spec_ctrl_base | ssbd_tif_to_spec_ctrl(tifn);
 
wrmsrl(MSR_IA32_SPEC_CTRL, msr);
 }
 
-static __always_inline void __speculative_store_bypass_update(unsigned long 
tifn)
+static __always_inline void __speculation_ctrl_update(unsigned long tifn)
 {
if (static_cpu_has(X86_FEATURE_VIRT_SSBD))
amd_set_ssb_virt_state(tifn);
else if (static_cpu_has(X86_FEATURE_LS_CFG_SSBD))
amd_set_core_ssb_state(tifn);
else
-   intel_set_ssb_state(tifn);
+   spec_ctrl_update_msr(tifn);
 }
 
-void speculative_store_bypass_update(unsigned long tif)
+void speculation_ctrl_update(unsigned long tif)
 {
preempt_disable();
-   __speculative_store_bypass_update(tif);
+   __speculation_ctrl_update(tif);
preempt_enable();
 }
 
@@ -452,7 +452,7 @@ void __switch_to_xtra(struct task_struct *prev_p, struct 
task_struct *next_p,
set_cpuid_faulting(!!(tifn & _TIF_NOCPUID));
 
if ((tifp ^ tifn) & _TIF_SSBD)
-   __speculative_store_bypass_update(tifn);
+   __speculation_ctrl_update(tifn);
 }
 
 /*
-- 
2.9.4



[Patch v5 12/16] x86/speculation: Create PRCTL interface to restrict indirect branch speculation

2018-11-16 Thread Tim Chen
Create PRCTL interface to restrict an application's indirect branch
speculation.  This will protect the application against spectre v2 attack
from another application.

Invocations:
Check indirect branch speculation status with
- prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIR_BRANCH, 0, 0, 0);

Enable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIR_BRANCH, PR_SPEC_ENABLE, 0, 0);

Disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIR_BRANCH, PR_SPEC_DISABLE, 0, 0);

Force disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIR_BRANCH, PR_SPEC_FORCE_DISABLE, 
0, 0);

See Documentation/userspace-api/spec_ctrl.rst.

Signed-off-by: Tim Chen 
---
 Documentation/userspace-api/spec_ctrl.rst |  9 
 arch/x86/kernel/cpu/bugs.c| 80 +++
 include/linux/sched.h |  9 
 include/uapi/linux/prctl.h|  1 +
 tools/include/uapi/linux/prctl.h  |  1 +
 5 files changed, 100 insertions(+)

diff --git a/Documentation/userspace-api/spec_ctrl.rst 
b/Documentation/userspace-api/spec_ctrl.rst
index 32f3d55..8a4e268 100644
--- a/Documentation/userspace-api/spec_ctrl.rst
+++ b/Documentation/userspace-api/spec_ctrl.rst
@@ -92,3 +92,12 @@ Speculation misfeature controls
* prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_STORE_BYPASS, PR_SPEC_ENABLE, 0, 
0);
* prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_STORE_BYPASS, PR_SPEC_DISABLE, 0, 
0);
* prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_STORE_BYPASS, 
PR_SPEC_FORCE_DISABLE, 0, 0);
+
+- PR_SPEC_INDIR_BRANCH: Indirect Branch Speculation in User Processes
+(Mitigate Spectre V2 style attacks against user 
processes)
+
+  Invocations:
+   * prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIR_BRANCH, 0, 0, 0);
+   * prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIR_BRANCH, PR_SPEC_ENABLE, 0, 
0);
+   * prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIR_BRANCH, PR_SPEC_DISABLE, 0, 
0);
+   * prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIR_BRANCH, 
PR_SPEC_FORCE_DISABLE, 0, 0);
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 21caade..8f5187e 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -773,12 +773,69 @@ static int ssb_prctl_set(struct task_struct *task, 
unsigned long ctrl)
return 0;
 }
 
+static void set_task_stibp(struct task_struct *tsk, bool stibp_on)
+{
+   bool update = false;
+
+   if (stibp_on)
+   update = !test_and_set_tsk_thread_flag(tsk, TIF_STIBP);
+   else
+   update = test_and_clear_tsk_thread_flag(tsk, TIF_STIBP);
+
+   if (tsk == current && update)
+   speculation_ctrl_update_current();
+}
+
+static int indir_branch_prctl_set(struct task_struct *task, unsigned long ctrl)
+{
+   switch (ctrl) {
+   case PR_SPEC_ENABLE:
+   if (spectre_v2_app2app_enabled == SPECTRE_V2_APP2APP_NONE)
+   return 0;
+   /*
+* Indirect branch speculation is always disabled in
+* strict mode.
+*/
+   if (spectre_v2_app2app_enabled == SPECTRE_V2_APP2APP_STRICT)
+   return -EPERM;
+   task_clear_spec_indir_branch_disable(task);
+   set_task_stibp(task, false);
+   break;
+   case PR_SPEC_DISABLE:
+   /*
+* Indirect branch speculation is always allowed when
+* mitigation is force disabled.
+*/
+   if (spectre_v2_app2app_enabled == SPECTRE_V2_APP2APP_NONE)
+   return -EPERM;
+   if (spectre_v2_app2app_enabled == SPECTRE_V2_APP2APP_STRICT)
+   return 0;
+   task_set_spec_indir_branch_disable(task);
+   set_task_stibp(task, true);
+   break;
+   case PR_SPEC_FORCE_DISABLE:
+   if (spectre_v2_app2app_enabled == SPECTRE_V2_APP2APP_NONE)
+   return -EPERM;
+   if (spectre_v2_app2app_enabled == SPECTRE_V2_APP2APP_STRICT)
+   return 0;
+   task_set_spec_indir_branch_disable(task);
+   task_set_spec_indir_branch_force_disable(task);
+   set_task_stibp(task, true);
+   break;
+   default:
+   return -ERANGE;
+   }
+   return 0;
+}
+
 int arch_prctl_spec_ctrl_set(struct task_struct *task, unsigned long which,
 unsigned long ctrl)
 {
switch (which) {
case PR_SPEC_STORE_BYPASS:
return ssb_prctl_set(task, ctrl);
+   case PR_SPEC_INDIR_BRANCH:
+   return indir_branch_prctl_set(task, ctrl);
default:
return -ENODEV;
}
@@ -811,11 +868,34 @@ static int ssb_prctl_get(struct task_struct *task)
}
 }
 
+static int indir_branch_prctl_get(struct task_struct 

[Patch v5 13/16] security: Update speculation restriction of a process when modifying its dumpability

2018-11-16 Thread Tim Chen
When a task is made non-dumpable, a higher level of security is implied
implicitly as its memory is imposed with access restriction.  Many
daemons touching sensitive data (e.g. sshd) make theselves non-dumpable.
Such tasks should have speculative execution restricted to protect them
from attacks taking advantage of CPU speculation side channels.

Add calls to arch_update_spec_restiction() to put speculative restriction
on a task when changing its dumpability.  Restrict speculative execution
on a non-dumpable task and relax the restrictions on a dumpable task.

A change to dumpability occurs via setgid, setuid, or
prctl(SUID_SET_DUMPABLE) syscalls.  The user should expect associated
change in speculative restriction occurs only on the task that issued
such syscall. Speculative restriction changes are not extended to other
threads in the same process.  This should not be a problem as such
changes should be made before spawning additional threads.

Signed-off-by: Tim Chen 
---
 fs/exec.c   | 3 +++
 include/linux/cpu.h | 3 +++
 kernel/cpu.c| 4 
 kernel/cred.c   | 5 -
 kernel/sys.c| 7 +++
 5 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/fs/exec.c b/fs/exec.c
index fc281b7..d72e20d 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -62,6 +62,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1366,6 +1367,8 @@ void setup_new_exec(struct linux_binprm * bprm)
else
set_dumpable(current->mm, SUID_DUMP_USER);
 
+   arch_update_spec_restriction(current);
+
arch_setup_new_exec();
perf_event_exec();
__set_task_comm(current, kbasename(bprm->filename), true);
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index 00af2ae..3d90155 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -182,4 +182,7 @@ static inline void cpu_smt_check_topology(void) { }
 #endif
 DECLARE_STATIC_KEY_TRUE(cpu_smt_enabled);
 
+/* Update CPU's speculation restrictions on a task based on task's properties 
*/
+extern int arch_update_spec_restriction(struct task_struct *task);
+
 #endif /* _LINUX_CPU_H_ */
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 54cf3f6..d57ab2c 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -2291,6 +2291,10 @@ void init_cpu_online(const struct cpumask *src)
cpumask_copy(&__cpu_online_mask, src);
 }
 
+int __weak arch_update_spec_ctrl_restriction(struct task_struct *task)
+{
+}
+
 /*
  * Activate the first processor.
  */
diff --git a/kernel/cred.c b/kernel/cred.c
index ecf0365..bc47653 100644
--- a/kernel/cred.c
+++ b/kernel/cred.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #if 0
 #define kdebug(FMT, ...)   \
@@ -445,8 +446,10 @@ int commit_creds(struct cred *new)
!uid_eq(old->fsuid, new->fsuid) ||
!gid_eq(old->fsgid, new->fsgid) ||
!cred_cap_issubset(old, new)) {
-   if (task->mm)
+   if (task->mm) {
set_dumpable(task->mm, suid_dumpable);
+   arch_update_spec_restriction(task);
+   }
task->pdeath_signal = 0;
smp_wmb();
}
diff --git a/kernel/sys.c b/kernel/sys.c
index 123bd73..621ea94 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -2290,6 +2290,13 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, 
unsigned long, arg3,
break;
}
set_dumpable(me->mm, arg2);
+   /*
+* Any speculative execution restriction updates
+* associated with change in dumpability
+* applies only to the current task that issues
+* the request.
+*/
+   arch_update_spec_restriction(me);
break;
 
case PR_SET_UNALIGN:
-- 
2.9.4



[Patch v5 07/16] x86/speculation: Reorganize speculation control MSRs update

2018-11-16 Thread Tim Chen
The logic to detect whether there's a change in the previous
and next task's flag relevant to update speculation control
MSRs are spread out across multiple functions.

Consolidate all checks needed for updating speculation
control MSRs to __speculation_ctrl_update().

This makes it easy to pick the right speculation control MSR,
and the bits in the MSR that needs updating based on
TIF flags changes.

Originally-by: Thomas Lendacky 
Signed-off-by: Tim Chen 
---
 arch/x86/kernel/process.c | 44 +---
 1 file changed, 33 insertions(+), 11 deletions(-)

diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 8aa4960..74bef48 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -397,25 +397,48 @@ static __always_inline void 
amd_set_ssb_virt_state(unsigned long tifn)
 
 static __always_inline void spec_ctrl_update_msr(unsigned long tifn)
 {
-   u64 msr = x86_spec_ctrl_base | ssbd_tif_to_spec_ctrl(tifn);
+   u64 msr = x86_spec_ctrl_base;
+
+   /*
+* If X86_FEATURE_SSBD is not set, the SSBD
+* bit is not to be touched.
+*/
+   if (static_cpu_has(X86_FEATURE_SSBD))
+   msr |= ssbd_tif_to_spec_ctrl(tifn);
 
wrmsrl(MSR_IA32_SPEC_CTRL, msr);
 }
 
-static __always_inline void __speculation_ctrl_update(unsigned long tifn)
-{
-   if (static_cpu_has(X86_FEATURE_VIRT_SSBD))
-   amd_set_ssb_virt_state(tifn);
-   else if (static_cpu_has(X86_FEATURE_LS_CFG_SSBD))
-   amd_set_core_ssb_state(tifn);
-   else
+/*
+ * Update the MSRs managing speculation control during context switch.
+ *
+ * tifp: previous task's thread flags
+ * tifn: next task's thread flags
+ */
+static __always_inline void __speculation_ctrl_update(unsigned long tifp,
+ unsigned long tifn)
+{
+   bool updmsr = false;
+
+   /* If TIF_SSBD is different, select the proper mitigation method */
+   if ((tifp ^ tifn) & _TIF_SSBD) {
+   if (static_cpu_has(X86_FEATURE_VIRT_SSBD))
+   amd_set_ssb_virt_state(tifn);
+   else if (static_cpu_has(X86_FEATURE_LS_CFG_SSBD))
+   amd_set_core_ssb_state(tifn);
+   else if (static_cpu_has(X86_FEATURE_SSBD))
+   updmsr  = true;
+   }
+
+   if (updmsr)
spec_ctrl_update_msr(tifn);
 }
 
 void speculation_ctrl_update(unsigned long tif)
 {
+   /* Forced update. Make sure all relevant TIF flags are different */
preempt_disable();
-   __speculation_ctrl_update(tif);
+   __speculation_ctrl_update(~tif, tif);
preempt_enable();
 }
 
@@ -451,8 +474,7 @@ void __switch_to_xtra(struct task_struct *prev_p, struct 
task_struct *next_p,
if ((tifp ^ tifn) & _TIF_NOCPUID)
set_cpuid_faulting(!!(tifn & _TIF_NOCPUID));
 
-   if ((tifp ^ tifn) & _TIF_SSBD)
-   __speculation_ctrl_update(tifn);
+   __speculation_ctrl_update(tifp, tifn);
 }
 
 /*
-- 
2.9.4



[Patch v5 00/16] Provide task property based options to enable Spectre v2 userspace-userspace protection

2018-11-16 Thread Tim Chen
The previous version of this series had a patch to apply TIF_STIBP updates
to all threads affected by a dumpability change, and keeping all the CPUs'
SPEC CTRL MSRs in sync with running task's TIF_STIBP.

However, this feature adds much overhead and complexities
for little gain.  Normally a task making uid/gid or prctl dumpability change
will do so before it starts spawning threads.

So in this version, the TIF_STIBP associated with dumpability change
is only applied to the task that makes the change, and not extended
to its associated threads.

Thomas also pointed out that new cpu_smt_enabled staic key is
created under CONFIG_HOTPLUG_SMT and currently applies only to x86.
So cpu_smt_enabled cannot replace sched_smt_present key which needs to
be used by all architectures, unless the cpu_smt_control setting logic
is moved out of CONFIG_HOTPLUG_SMT.  So I dropped the patch replacing
sched_smt_present with cpu_smt_enabled.

I've also moved the TIF flags re-organization patch to the end
of the series to make it easier for backporting to stable kernels
without needing to reorganize the TIF flags.

Thomas, can you consider this series to be merged to 4.20-rc along
with Jiri's changes on STIBP?

Thanks.

Tim

Patch 1 to 3 are clean up patches.
Patch 4 and 5 disable STIBP for enhacned IBRS.
Patch 6 to 9 reorganize and clean up the code without affecting
 functionality for easier modification later.
Patch 10 introduces the STIBP flag on a task to dynamically
 enable STIBP for that task.
Patch 11 introduces different modes to protect a
 task against Spectre v2 user space attack.
Patch 12 adds prctl interface to turn on Spectre v2 user mode defenses on a 
task. 
Patch 13-14 add Spectre v2 defenses for non-dumpable tasks.
Patch 15-16 reorganizes the TIF flags, and can be dropped without affecting 
this series 

Changes:
v5:
1. Drop patch to extend TIF_STIBP changes to all related threads on 
a task's dumpabibility change.
2. Drop patch to replace sched_smt_present with cpu_smt_enabled.
3. Drop export of cpu_smt_control in kernel/cpu.c and replace external
usages of cpu_smt_control with cpu_smt_enabled.
4. Rebase patch series on 4.20-rc2.

v4:
1. Extend STIBP update to all threads of a process changing
it dumpability.
2. Add logic to update SPEC_CTRL MSR on a remote CPU when TIF flags
affecting speculation changes for task running on the remote CPU.
3. Regroup x86 TIF_* flags according to their functions.
4. Various code clean up.

v3:
1. Add logic to skip STIBP when Enhanced IBRS is used.
2. Break up v2 patches into smaller logical patches. 
3. Fix bug in arch_set_dumpable that did not update SPEC_CTRL
MSR right away when according to task's STIBP flag clearing which
caused SITBP to be left on.
4. Various code clean up. 

v2:
1. Extend per process STIBP to AMD cpus
2. Add prctl option to control per process indirect branch speculation
3. Bug fixes and cleanups 

Jiri's patchset to harden Spectre v2 user space mitigation makes IBPB
and STIBP in use for Spectre v2 mitigation on all processes.  IBPB will
be issued for switching to an application that's not ptraceable by the
previous application and STIBP will be always turned on.

However, leaving STIBP on all the time is expensive for certain
applications that have frequent indirect branches. One such application
is perlbench in the SpecInt Rate 2006 test suite which shows a
21% reduction in throughput.
There're also reports of drop in performance on Python and PHP benchmarks:
https://www.phoronix.com/scan.php?page=article=linux-420-bisect=2

Other applications like bzip2 with minimal indirct branches have
only a 0.7% reduction in throughput. IBPB will also impose
overhead during context switches.

Users may not wish to incur performance overhead from IBPB and STIBP for
general non security sensitive processes and use these mitigations only
for security sensitive processes.

This patchset provides a process property based lite protection mode.
In this mode, IBPB and STIBP mitigation are applied only to security
sensitive non-dumpable processes and processes that users want to protect
by having indirect branch speculation disabled via PRCTL.  So the overhead
from IBPB and STIBP are avoided for low security processes that don't
require extra protection.
Tim Chen (16):
  x86/speculation: Clean up spectre_v2_parse_cmdline()
  x86/speculation: Remove unnecessary ret variable in cpu_show_common()
  x86/speculation: Reorganize cpu_show_common()
  x86/speculation: Add X86_FEATURE_USE_IBRS_ENHANCED
  x86/speculation: Disable STIBP when enhanced IBRS is in use
  x86/speculation: Rename SSBD update functions
  x86/speculation: Reorganize speculation control MSRs update
  smt: Create cpu_smt_enabled static key for SMT specific code
  x86/smt: Convert cpu_smt_control check to cpu_smt_enabled static key
  x86/speculation: Turn on or off STIBP according to a task's TIF_STIBP
  x86/speculation: Add Spectre v2 app to app protection modes
  x86/speculation: Create PRCTL interface to 

[Patch v5 01/16] x86/speculation: Clean up spectre_v2_parse_cmdline()

2018-11-16 Thread Tim Chen
Remove unnecessary else statement in spectre_v2_parse_cmdline()
to save a indentation level.

Signed-off-by: Tim Chen 
---
 arch/x86/kernel/cpu/bugs.c | 27 +--
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index c37e66e..5ac7070 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -283,22 +283,21 @@ static enum spectre_v2_mitigation_cmd __init 
spectre_v2_parse_cmdline(void)
 
if (cmdline_find_option_bool(boot_command_line, "nospectre_v2"))
return SPECTRE_V2_CMD_NONE;
-   else {
-   ret = cmdline_find_option(boot_command_line, "spectre_v2", arg, 
sizeof(arg));
-   if (ret < 0)
-   return SPECTRE_V2_CMD_AUTO;
 
-   for (i = 0; i < ARRAY_SIZE(mitigation_options); i++) {
-   if (!match_option(arg, ret, 
mitigation_options[i].option))
-   continue;
-   cmd = mitigation_options[i].cmd;
-   break;
-   }
+   ret = cmdline_find_option(boot_command_line, "spectre_v2", arg, 
sizeof(arg));
+   if (ret < 0)
+   return SPECTRE_V2_CMD_AUTO;
 
-   if (i >= ARRAY_SIZE(mitigation_options)) {
-   pr_err("unknown option (%s). Switching to AUTO 
select\n", arg);
-   return SPECTRE_V2_CMD_AUTO;
-   }
+   for (i = 0; i < ARRAY_SIZE(mitigation_options); i++) {
+   if (!match_option(arg, ret, mitigation_options[i].option))
+   continue;
+   cmd = mitigation_options[i].cmd;
+   break;
+   }
+
+   if (i >= ARRAY_SIZE(mitigation_options)) {
+   pr_err("unknown option (%s). Switching to AUTO select\n", arg);
+   return SPECTRE_V2_CMD_AUTO;
}
 
if ((cmd == SPECTRE_V2_CMD_RETPOLINE ||
-- 
2.9.4



[Patch v5 14/16] x86/speculation: Use STIBP to restrict speculation on non-dumpable task

2018-11-16 Thread Tim Chen
When a task changes its dumpability, arch_update_spec_ctrl_restriction()
is called to place restriction on the task's speculative execution
according to dumpability changes.

Implements arch_update_spec_restriction() for x86.  Use STIBP to
restrict speculative execution when running a task set to non-dumpable,
or clear the restriction if the task is set to dumpable.

Signed-off-by: Tim Chen 
---
 Documentation/admin-guide/kernel-parameters.txt |  3 ++-
 arch/x86/kernel/cpu/bugs.c  | 21 +++--
 2 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 9c306e3..102f9a1 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4221,7 +4221,8 @@
vulnerability.
 
off- Unconditionally disable mitigations
-   lite   - Protect tasks which have requested restricted
+   lite   - Protect tasks which are marked non-dumpable
+and tasks which have requested restricted
 indirect branch speculation via the
 PR_SET_SPECULATION_CTRL prctl(). 
strict - Protect all processes
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 8f5187e..e7f9334 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -152,7 +153,7 @@ static const char *spectre_v2_strings[] = {
 
 static const char *spectre_v2_app2app_strings[] = {
[SPECTRE_V2_APP2APP_NONE]   = "App-App Vulnerable",
-   [SPECTRE_V2_APP2APP_LITE]   = "App-App Mitigation: Protect branch 
speculation restricted tasks",
+   [SPECTRE_V2_APP2APP_LITE]   = "App-App Mitigation: Protect non-dumpable 
and branch speculation restricted tasks",
[SPECTRE_V2_APP2APP_STRICT] = "App-App Mitigation: Full app to app 
attack protection",
 };
 
@@ -779,13 +780,29 @@ static void set_task_stibp(struct task_struct *tsk, bool 
stibp_on)
 
if (stibp_on)
update = !test_and_set_tsk_thread_flag(tsk, TIF_STIBP);
-   else
+   else if (!task_spec_indir_branch_disable(tsk))
update = test_and_clear_tsk_thread_flag(tsk, TIF_STIBP);
 
if (tsk == current && update)
speculation_ctrl_update_current();
 }
 
+int arch_update_spec_restriction(struct task_struct *task)
+{
+   if (!static_branch_unlikely(_v2_app_lite))
+   return 0;
+
+   if (!task->mm)
+   return -EINVAL;
+
+   if (get_dumpable(task->mm) != SUID_DUMP_USER)
+   set_task_stibp(task, true);
+   else
+   set_task_stibp(task, false);
+
+   return 0;
+}
+
 static int indir_branch_prctl_set(struct task_struct *task, unsigned long ctrl)
 {
switch (ctrl) {
-- 
2.9.4



[Patch v5 16/16] x86: Group thread info flags by functionality

2018-11-16 Thread Tim Chen
The thread info flags are currently randomly distributed in the header
file arch/x86/include/asm/thread_info.h.

Group TIF flags together according to the following categories:
operation mode, syscall mode, pending work, task status and security
status.

Signed-off-by: Tim Chen 
---
 arch/x86/include/asm/thread_info.h | 97 ++
 1 file changed, 56 insertions(+), 41 deletions(-)

diff --git a/arch/x86/include/asm/thread_info.h 
b/arch/x86/include/asm/thread_info.h
index a8c5e52..453616f 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -74,60 +74,75 @@ struct thread_info {
  * - these are process state flags that various assembly files
  *   may need to access
  */
-#define TIF_SYSCALL_TRACE  0   /* syscall trace active */
-#define TIF_NOTIFY_RESUME  1   /* callback before returning to user */
-#define TIF_SIGPENDING 2   /* signal pending */
-#define TIF_NEED_RESCHED   3   /* rescheduling necessary */
-#define TIF_SINGLESTEP 4   /* reenable singlestep on user return*/
-#define TIF_SSBD   5   /* Speculative store bypass disable */
-#define TIF_SYSCALL_EMU6   /* syscall emulation active */
-#define TIF_SYSCALL_AUDIT  7   /* syscall auditing active */
-#define TIF_SECCOMP8   /* secure computing */
-#define TIF_STIBP  9   /* Single thread indirect branch 
speculation */
-#define TIF_USER_RETURN_NOTIFY 11  /* notify kernel of userspace return */
-#define TIF_UPROBE 12  /* breakpointed or singlestepping */
-#define TIF_PATCH_PENDING  13  /* pending live patching update */
-#define TIF_NOCPUID15  /* CPUID is not accessible in userland 
*/
-#define TIF_NOTSC  16  /* TSC is not accessible in userland */
-#define TIF_IA32   17  /* IA32 compatibility process */
-#define TIF_NOHZ   19  /* in adaptive nohz mode */
-#define TIF_MEMDIE 20  /* is terminating due to OOM killer */
-#define TIF_POLLING_NRFLAG 21  /* idle is polling for TIF_NEED_RESCHED 
*/
-#define TIF_IO_BITMAP  22  /* uses I/O bitmap */
-#define TIF_FORCED_TF  24  /* true if TF in eflags artificially */
-#define TIF_BLOCKSTEP  25  /* set when we want DEBUGCTLMSR_BTF */
-#define TIF_LAZY_MMU_UPDATES   27  /* task is updating the mmu lazily */
-#define TIF_SYSCALL_TRACEPOINT 28  /* syscall tracepoint instrumentation */
-#define TIF_ADDR32 29  /* 32-bit address space on 64 bits */
-#define TIF_X3230  /* 32-bit native x86-64 binary 
*/
-#define TIF_FSCHECK31  /* Check FS is USER_DS on return */
+
+/* Operation mode */
+#define TIF_NOCPUID0   /* CPUID is not accessible in userland 
*/
+#define TIF_NOTSC  1   /* TSC is not accessible in userland */
+#define TIF_IA32   2   /* IA32 compatibility process */
+#define TIF_NOHZ   3   /* In adaptive nohz mode */
+#define TIF_ADDR32 4   /* 32-bit address space on 64 bits */
+#define TIF_X325   /* 32-bit native x86-64 binary 
*/
+
+/* Syscall mode */
+#define TIF_SYSCALL_TRACE  6   /* Syscall trace active */
+#define TIF_SYSCALL_EMU7   /* Syscall emulation active */
+#define TIF_SYSCALL_AUDIT  8   /* Syscall auditing active */
+#define TIF_SYSCALL_TRACEPOINT 9   /* Syscall tracepoint instrumentation */
+
+/* Pending work */
+#define TIF_NOTIFY_RESUME  10  /* Callback before returning to user */
+#define TIF_SIGPENDING 11  /* Signal pending */
+#define TIF_NEED_RESCHED   12  /* Rescheduling necessary */
+#define TIF_SINGLESTEP 13  /* Reenable singlestep on user return*/
+#define TIF_USER_RETURN_NOTIFY 14  /* Notify kernel of userspace return */
+#define TIF_PATCH_PENDING  15  /* Pending live patching update */
+#define TIF_FSCHECK16  /* Check FS is USER_DS on return */
+
+/* Task status */
+#define TIF_UPROBE 17  /* Breakpointed or singlestepping */
+#define TIF_MEMDIE 18  /* Is terminating due to OOM killer */
+#define TIF_POLLING_NRFLAG 19  /* Idle is polling for TIF_NEED_RESCHED 
*/
+#define TIF_IO_BITMAP  20  /* Uses I/O bitmap */
+#define TIF_FORCED_TF  21  /* True if TF in eflags artificially */
+#define TIF_BLOCKSTEP  22  /* Set when we want DEBUGCTLMSR_BTF */
+#define TIF_LAZY_MMU_UPDATES   23  /* Task is updating the mmu lazily */
+
+/* Security mode */
+#define TIF_SECCOMP24  /* Secure computing */
+#define TIF_SSBD   25  /* Speculative store bypass disable */
+#define TIF_STIBP  26  /* Single thread indirect branch 
speculation */
+
+#define _TIF_NOCPUID 

[Patch v5 15/16] x86/speculation: Update comment on TIF_SSBD

2018-11-16 Thread Tim Chen
The comment to TIF_SSBD uses the obsoleted name
"Reduced Data Speculation".

Update comment use the correct name
"Speculative store bypass disable".

Signed-off-by: Tim Chen 
---
 arch/x86/include/asm/thread_info.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/thread_info.h 
b/arch/x86/include/asm/thread_info.h
index 8736d23..a8c5e52 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -79,7 +79,7 @@ struct thread_info {
 #define TIF_SIGPENDING 2   /* signal pending */
 #define TIF_NEED_RESCHED   3   /* rescheduling necessary */
 #define TIF_SINGLESTEP 4   /* reenable singlestep on user return*/
-#define TIF_SSBD   5   /* Reduced data speculation */
+#define TIF_SSBD   5   /* Speculative store bypass disable */
 #define TIF_SYSCALL_EMU6   /* syscall emulation active */
 #define TIF_SYSCALL_AUDIT  7   /* syscall auditing active */
 #define TIF_SECCOMP8   /* secure computing */
-- 
2.9.4



[Patch v5 03/16] x86/speculation: Reorganize cpu_show_common()

2018-11-16 Thread Tim Chen
The Spectre V2 printout in cpu_show_common() handles conditionals for the
various mitigation methods directly in the sprintf() argument list. That's
hard to read and will become unreadable if more complex decisions need to
be made for a particular method.

Move the conditionals for STIBP and IBPB string selection into helper
functions, so they can be extended later on.

Signed-off-by: Tim Chen 
---
 arch/x86/kernel/cpu/bugs.c | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 84e3579..91a754a 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -853,6 +853,22 @@ static ssize_t l1tf_show_state(char *buf)
 }
 #endif
 
+static char *stibp_state(void)
+{
+   if (x86_spec_ctrl_base & SPEC_CTRL_STIBP)
+   return ", STIBP";
+   else
+   return "";
+}
+
+static char *ibpb_state(void)
+{
+   if (boot_cpu_has(X86_FEATURE_USE_IBPB))
+   return ", IBPB";
+   else
+   return "";
+}
+
 static ssize_t cpu_show_common(struct device *dev, struct device_attribute 
*attr,
   char *buf, unsigned int bug)
 {
@@ -874,9 +890,9 @@ static ssize_t cpu_show_common(struct device *dev, struct 
device_attribute *attr
 
case X86_BUG_SPECTRE_V2:
return sprintf(buf, "%s%s%s%s%s%s\n", 
spectre_v2_strings[spectre_v2_enabled],
-  boot_cpu_has(X86_FEATURE_USE_IBPB) ? ", IBPB" : 
"",
+  ibpb_state(),
   boot_cpu_has(X86_FEATURE_USE_IBRS_FW) ? ", 
IBRS_FW" : "",
-  (x86_spec_ctrl_base & SPEC_CTRL_STIBP) ? ", 
STIBP" : "",
+  stibp_state(),
   boot_cpu_has(X86_FEATURE_RSB_CTXSW) ? ", RSB 
filling" : "",
   spectre_v2_module_string());
 
-- 
2.9.4



[Patch v5 05/16] x86/speculation: Disable STIBP when enhanced IBRS is in use

2018-11-16 Thread Tim Chen
If enhanced IBRS is engaged, STIBP is redundant in mitigating Spectre
v2 user space exploits from hyperthread sibling.

Disable STIBP when enhanced IBRS is used.

Signed-off-by: Tim Chen 
---
 arch/x86/kernel/cpu/bugs.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 3a6f13b..5c0eb2f 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -325,9 +325,17 @@ static enum spectre_v2_mitigation_cmd __init 
spectre_v2_parse_cmdline(void)
 
 static bool stibp_needed(void)
 {
+   /*
+* Determine if STIBP should be always on.
+* Using enhanced IBRS makes using STIBP unnecessary.
+*/
+
if (spectre_v2_enabled == SPECTRE_V2_NONE)
return false;
 
+   if (static_cpu_has(X86_FEATURE_USE_IBRS_ENHANCED))
+   return false;
+
if (!boot_cpu_has(X86_FEATURE_STIBP))
return false;
 
@@ -856,6 +864,9 @@ static ssize_t l1tf_show_state(char *buf)
 
 static char *stibp_state(void)
 {
+   if (spectre_v2_enabled == SPECTRE_V2_IBRS_ENHANCED)
+   return "";
+
if (x86_spec_ctrl_base & SPEC_CTRL_STIBP)
return ", STIBP";
else
-- 
2.9.4



Re: [PATCH] arm64: Explicitly mark 64-bit constant as unsigned long

2018-11-16 Thread Will Deacon
Hi Olof,

On Fri, Nov 16, 2018 at 05:54:56PM -0800, Olof Johansson wrote:
> Makes sparse happy. Before:
> 
> arch/arm64/include/asm/sysreg.h:471:42: warning: constant 0x 
> is so big it is unsigned long
> arch/arm64/include/asm/sysreg.h:512:42: warning: constant 0x 
> is so big it is unsigned long
> 
> Signed-off-by: Olof Johansson 
> ---
>  arch/arm64/include/asm/sysreg.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

The warning is bogus imo, but since it's harmless to fix it then we can do
that. However, you've been beaten by:

http://lists.infradead.org/pipermail/linux-arm-kernel/2018-November/613179.html

Will


Re: [PATCH] pinctrl: zynq: Use define directive for PIN_CONFIG_IO_STANDARD

2018-11-16 Thread Nathan Chancellor
On Fri, Nov 16, 2018 at 09:40:45AM +0100, Michal Simek wrote:
> On 09. 11. 18 16:36, Nathan Chancellor wrote:
> > On Fri, Nov 09, 2018 at 10:33:00AM +0100, Michal Simek wrote:
> >> On 08. 11. 18 16:01, Nathan Chancellor wrote:
> >>> On Thu, Nov 08, 2018 at 07:45:42AM +0100, Michal Simek wrote:
>  On 07. 11. 18 18:48, Nick Desaulniers wrote:
> > On Wed, Nov 7, 2018 at 1:01 AM Michal Simek  
> > wrote:
> >>
> >> On 07. 11. 18 9:55, Nathan Chancellor wrote:
> >>> On Wed, Nov 07, 2018 at 09:46:12AM +0100, Michal Simek wrote:
>  On 01. 11. 18 1:57, Nathan Chancellor wrote:
> > Clang warns when one enumerated type is implicitly converted to 
> > another:
> >
> > drivers/pinctrl/pinctrl-zynq.c:985:18: warning: implicit conversion 
> > from
> > enumeration type 'enum zynq_pin_config_param' to different 
> > enumeration
> > type 'enum pin_config_param' [-Wenum-conversion]
> > {"io-standard", PIN_CONFIG_IOSTANDARD, zynq_iostd_lvcmos18},
> > ~   ^
> > drivers/pinctrl/pinctrl-zynq.c:990:16: warning: implicit conversion 
> > from
> > enumeration type 'enum zynq_pin_config_param' to different 
> > enumeration
> > type 'enum pin_config_param' [-Wenum-conversion]
> > = { PCONFDUMP(PIN_CONFIG_IOSTANDARD, "IO-standard", NULL, 
> > true),
> > 
> > ~~^
> > ./include/linux/pinctrl/pinconf-generic.h:163:11: note: expanded 
> > from
> > macro 'PCONFDUMP'
> > .param = a, .display = b, .format = c, .has_arg = d \
> >  ^
> > 2 warnings generated.
> 
>  This is interesting. I have never tried to use llvm for building the
>  kernel. Do you have any description how this can be done?
> 
> >>>
> >>> Depending on what version of Clang you have access to, it is usually 
> >>> just as
> >>> simple as running 'make ARCH=arm CC=clang 
> >>> CROSS_COMPILE=arm-linux-gnueabi-'.
> >>>
> >>> Clang 7.0+ is recommended but 6.0 might work too.
> >>
> >> TBH I would expect to download container and run this there to make 
> >> sure
> >> that I don't break anything else.
> >
> > This is the first request we've had for a container in order to test a
> > patch.  If it comes up again from other folks, I think it makes sense
> > to create one.  Until then, its nice to have.  It's definitely
> > overkill for this patch.
> 
>  I have played with it to see that error and here are some steps I did.
> 
>  docker run --name test-clang -it --rm debian:latest bash
>  apt-get update
>  apt-get install gcc-arm-linux-gnueabi gcc-aarch64-linux-gnu clang git bc
>  build-essential bison flex make llvm vim libssl-dev sparse
> 
>  git clone
>  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git --depth 
>  1
>  cd linux
> 
>  export ARCH=arm64
>  export CROSS_COMPILE=aarch64-linux-gnu-
> 
>  make defconfig
> >>>
> >>> This should also have 'CC=clang' because compiler detection happens in
> >>> Kconfig now so compiler flags get properly set. Other than that, looks
> >>> good and I was able to build pinctrl-zynq.o without any issues with
> >>> those commands.
> >>
> >> For arm32 I am still getting compilation issue (arm64 is fine)
> >> Below are my steps and version I use. Do you know what could be the
> >> problem?
> >>
> >> Thanks,
> >> Michal
> >>
> >> root@1e15921e6d15:~/linux# arm-linux-gnueabi-gcc --version
> >> arm-linux-gnueabi-gcc (Debian 6.3.0-18) 6.3.0 20170516
> >> Copyright (C) 2016 Free Software Foundation, Inc.
> >> This is free software; see the source for copying conditions.  There is NO
> >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> >>
> >> root@1e15921e6d15:~/linux# clang --version
> >> clang version 3.8.1-24 (tags/RELEASE_381/final)
> >> Target: x86_64-pc-linux-gnu
> >> Thread model: posix
> >> InstalledDir: /usr/bin
> >>
> >>
> >> export ARCH=arm
> >> export CROSS_COMPILE=arm-linux-gnuaebi-
> >> make CC=clang defconfig
> >> make CC=clang drivers/pinctrl/pinctrl-zynq.o
> >>
> >> and I get
> >> clang: error: unsupported argument '-W' to option 'Wa,'
> >> scripts/Makefile.build:305: recipe for target 'scripts/mod/empty.o' failed
> >> make[2]: *** [scripts/mod/empty.o] Error 1
> >> scripts/Makefile.build:546: recipe for target 'scripts/mod' failed
> >>
> > 
> > Ah because Debian's regular Clang is ancient.
> > 
> > For testing, we use the builds from apt.llvm.org. Commands assuming
> > you're using the normal Debian image:
> > 
> > curl https://apt.llvm.org/llvm-snapshot.gpg.key | apt-key add -
> > echo "deb http://apt.llvm.org/stretch/ llvm-toolchain-stretch main" | 

[PATCH] arm64: Explicitly mark 64-bit constant as unsigned long

2018-11-16 Thread Olof Johansson
Makes sparse happy. Before:

arch/arm64/include/asm/sysreg.h:471:42: warning: constant 0x is 
so big it is unsigned long
arch/arm64/include/asm/sysreg.h:512:42: warning: constant 0x is 
so big it is unsigned long

Signed-off-by: Olof Johansson 
---
 arch/arm64/include/asm/sysreg.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 0c909c4a932ff..981892b67b8f6 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -468,7 +468,7 @@
 SCTLR_ELx_SA | SCTLR_ELx_I| SCTLR_ELx_WXN | \
 SCTLR_ELx_DSSBS | ENDIAN_CLEAR_EL2 | SCTLR_EL2_RES0)
 
-#if (SCTLR_EL2_SET ^ SCTLR_EL2_CLEAR) != 0x
+#if (SCTLR_EL2_SET ^ SCTLR_EL2_CLEAR) != 0xul
 #error "Inconsistent SCTLR_EL2 set/clear bits"
 #endif
 
@@ -509,7 +509,7 @@
 SCTLR_EL1_UMA | SCTLR_ELx_WXN | ENDIAN_CLEAR_EL1 |\
 SCTLR_ELx_DSSBS | SCTLR_EL1_NTWI  | SCTLR_EL1_RES0)
 
-#if (SCTLR_EL1_SET ^ SCTLR_EL1_CLEAR) != 0x
+#if (SCTLR_EL1_SET ^ SCTLR_EL1_CLEAR) != 0xul
 #error "Inconsistent SCTLR_EL1 set/clear bits"
 #endif
 
-- 
2.11.0



[PATCH] mm: use this_cpu_cmpxchg_double in put_cpu_partial

2018-11-16 Thread Wengang Wang
The this_cpu_cmpxchg makes the do-while loop pass as long as the
s->cpu_slab->partial as the same value. It doesn't care what happened to
that slab. Interrupt is not disabled, and new alloc/free can happen in the
interrupt handlers. Theoretically, after we have a reference to the it,
stored in _oldpage_, the first slab on the partial list on this CPU can be
moved to kmem_cache_node and then moved to different kmem_cache_cpu and
then somehow can be added back as head to partial list of current
kmem_cache_cpu, though that is a very rare case. If that rare case really
happened, the reading of oldpage->pobjects may get a 0xdead
unexpectedly, stored in _pobjects_, if the reading happens just after
another CPU removed the slab from kmem_cache_node, setting lru.prev to
LIST_POISON2 (0xdead0200). The wrong _pobjects_(negative) then
prevents slabs from being moved to kmem_cache_node and being finally freed.

We see in a vmcore, there are 375210 slabs kept in the partial list of one
kmem_cache_cpu, but only 305 in-use objects in the same list for
kmalloc-2048 cache. We see negative values for page.pobjects, the last page
with negative _pobjects_ has the value of 0xdead0004, the next page looks
good (_pobjects is 1).

For the fix, I wanted to call this_cpu_cmpxchg_double with
oldpage->pobjects, but failed due to size difference between
oldpage->pobjects and cpu_slab->partial. So I changed to call
this_cpu_cmpxchg_double with _tid_. I don't really want no alloc/free
happen in between, but just want to make sure the first slab did expereince
a remove and re-add. This patch is more to call for ideas.

Signed-off-by: Wengang Wang 
---
 mm/slub.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/mm/slub.c b/mm/slub.c
index e3629cd..26539e6 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2248,6 +2248,7 @@ static void put_cpu_partial(struct kmem_cache *s, struct 
page *page, int drain)
 {
 #ifdef CONFIG_SLUB_CPU_PARTIAL
struct page *oldpage;
+   unsigned long tid;
int pages;
int pobjects;
 
@@ -2255,8 +2256,12 @@ static void put_cpu_partial(struct kmem_cache *s, struct 
page *page, int drain)
do {
pages = 0;
pobjects = 0;
-   oldpage = this_cpu_read(s->cpu_slab->partial);
 
+   tid = this_cpu_read(s->cpu_slab->tid);
+   /* read tid before reading oldpage */
+   barrier();
+
+   oldpage = this_cpu_read(s->cpu_slab->partial);
if (oldpage) {
pobjects = oldpage->pobjects;
pages = oldpage->pages;
@@ -2283,8 +2288,17 @@ static void put_cpu_partial(struct kmem_cache *s, struct 
page *page, int drain)
page->pobjects = pobjects;
page->next = oldpage;
 
-   } while (this_cpu_cmpxchg(s->cpu_slab->partial, oldpage, page)
-   != oldpage);
+   /* we dont' change tid, but want to make sure it didn't change
+* in between. We don't really hope alloc/free not happen on
+* this CPU, but don't want the first slab be removed from and
+* then re-added as head to this partial list. If that case
+* happened, pobjects may read 0xdead when this slab is just
+* removed from kmem_cache_node by other CPU setting lru.prev
+* to LIST_POISON2.
+*/
+   } while (this_cpu_cmpxchg_double(s->cpu_slab->partial, s->cpu_slab->tid,
+oldpage, tid, page, tid) == 0);
+
if (unlikely(!s->cpu_partial)) {
unsigned long flags;
 
-- 
2.9.5



Re: [PATCH v2 2/3] kernel.h: hide __is_constexpr() from sparse

2018-11-16 Thread Luc Van Oostenryck
On Fri, Nov 09, 2018 at 10:35:33AM +0100, Johannes Berg wrote:
> From: Johannes Berg 
> 
> __is_constexpr() is a work of art, understandable only to the most
> respected wizards of C. Even sparse doesn't seem to belong to that
> group and warns that there's an "expression using sizeof(void)".
> 
> Just hide the definition from sparse and pretend it's always true.

The development version of sparse doesn't issues a warning for
sizeof(void) soon after the introduction of __is_constexpr()
and sparse's main tree have been updated (very recently).

I strongly believe this patch shouldn't be.

Regards,
-- Luc


Re: [PATCH v2 1/3] compiler-gcc: hide COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW from sparse

2018-11-16 Thread Luc Van Oostenryck
On Fri, Nov 09, 2018 at 10:35:32AM +0100, Johannes Berg wrote:
> From: Johannes Berg 
> 
> Sparse doesn't support all the overflow builtins, so just hide
> them from it to avoid lots of warnings/errors reported by it.

The development version of sparse support these builtins
since their introduction in the kernel and sparse's main tree
have been updated (very recently).

I strongly believe this patch shouldn't be.

Regards,
-- Luc


[PATCH v3 0/7] freezer for cgroup v2

2018-11-16 Thread Roman Gushchin
This patchset implements freezer for cgroup v2.

It provides similar functionality as v1 freezer, but the interface
conforms to the cgroup v2 interface design principles, and it
provides a better user experience: tasks can be killed, ptrace works,
there is no separate controller, which has to be enabled, etc.

Patches (1), (2) and (3) are some preparational work, patch (4) contains
the implementation, patch (5) is a small cgroup kselftest fix,
patch (6) covers freezer adds 6 new kselftests to cover the freezer
functionality. Patch (7) adds corresponding docs.

v3->v2:
  - dropped TASK_FROZEN for now, frozen tasks are put into TASK_INTERRUPTIBLE
  state; it's probably not the final version, but the API question can be
  discussed separately
  - don't clear TIF_SIGPENDING before going to sleep, instead add
  task->frozen check in signal_pending_state() and recalc_sigpending()
  - cgroup-level counter are now synchronized using css_set_lock,
  which simplified the whole code (e.g. per-cgroup works were removed)
  - the amount of comments increased significantly
  - many other improvements incorporating feedback from Tejun and Oleg

v2->v1:
  - fixed locking aroung calling cgroup_freezer_leave()
  - added docs

Roman Gushchin (7):
  cgroup: rename freezer.c into legacy_freezer.c
  cgroup: implement __cgroup_task_count() helper
  cgroup: protect cgroup->nr_(dying_)descendants by css_set_lock
  cgroup: cgroup v2 freezer
  kselftests: cgroup: don't fail on cg_kill_all() error in cg_destroy()
  kselftests: cgroup: add freezer controller self-tests
  cgroup: document cgroup v2 freezer interface

 Documentation/admin-guide/cgroup-v2.rst   |  26 +
 include/linux/cgroup-defs.h   |  31 +
 include/linux/cgroup.h|  42 ++
 include/linux/sched.h |   2 +
 include/linux/sched/jobctl.h  |   2 +
 include/linux/sched/signal.h  |   2 +
 kernel/cgroup/Makefile|   4 +-
 kernel/cgroup/cgroup-internal.h   |   1 +
 kernel/cgroup/cgroup-v1.c |  16 -
 kernel/cgroup/cgroup.c| 165 -
 kernel/cgroup/freezer.c   | 641 ++--
 kernel/cgroup/legacy_freezer.c| 481 
 kernel/ptrace.c   |   7 +
 kernel/signal.c   |  57 +-
 tools/testing/selftests/cgroup/.gitignore |   1 +
 tools/testing/selftests/cgroup/Makefile   |   2 +
 tools/testing/selftests/cgroup/cgroup_util.c  |  85 ++-
 tools/testing/selftests/cgroup/cgroup_util.h  |   7 +
 tools/testing/selftests/cgroup/test_freezer.c | 685 ++
 19 files changed, 1804 insertions(+), 453 deletions(-)
 create mode 100644 kernel/cgroup/legacy_freezer.c
 create mode 100644 tools/testing/selftests/cgroup/test_freezer.c

-- 
2.17.2



[PATCH v3 2/7] cgroup: implement __cgroup_task_count() helper

2018-11-16 Thread Roman Gushchin
The helper is identical to the existing cgroup_task_count()
except it doesn't take the css_set_lock by itself, assuming
that the caller does.

Also, move cgroup_task_count() implementation into
kernel/cgroup/cgroup.c, as there is nothing specific to cgroup v1.

Signed-off-by: Roman Gushchin 
Cc: Tejun Heo 
Cc: kernel-t...@fb.com
---
 kernel/cgroup/cgroup-internal.h |  1 +
 kernel/cgroup/cgroup-v1.c   | 16 
 kernel/cgroup/cgroup.c  | 33 +
 3 files changed, 34 insertions(+), 16 deletions(-)

diff --git a/kernel/cgroup/cgroup-internal.h b/kernel/cgroup/cgroup-internal.h
index 75568fcf2180..fe01a9fa4a8d 100644
--- a/kernel/cgroup/cgroup-internal.h
+++ b/kernel/cgroup/cgroup-internal.h
@@ -224,6 +224,7 @@ int cgroup_rmdir(struct kernfs_node *kn);
 int cgroup_show_path(struct seq_file *sf, struct kernfs_node *kf_node,
 struct kernfs_root *kf_root);
 
+int __cgroup_task_count(const struct cgroup *cgrp);
 int cgroup_task_count(const struct cgroup *cgrp);
 
 /*
diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
index 51063e7a93c2..6134fef07d57 100644
--- a/kernel/cgroup/cgroup-v1.c
+++ b/kernel/cgroup/cgroup-v1.c
@@ -336,22 +336,6 @@ static struct cgroup_pidlist 
*cgroup_pidlist_find_create(struct cgroup *cgrp,
return l;
 }
 
-/**
- * cgroup_task_count - count the number of tasks in a cgroup.
- * @cgrp: the cgroup in question
- */
-int cgroup_task_count(const struct cgroup *cgrp)
-{
-   int count = 0;
-   struct cgrp_cset_link *link;
-
-   spin_lock_irq(_set_lock);
-   list_for_each_entry(link, >cset_links, cset_link)
-   count += link->cset->nr_tasks;
-   spin_unlock_irq(_set_lock);
-   return count;
-}
-
 /*
  * Load a cgroup's pidarray with either procs' tgids or tasks' pids
  */
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 4a3dae2a8283..ef3442555b32 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -561,6 +561,39 @@ static void cgroup_get_live(struct cgroup *cgrp)
css_get(>self);
 }
 
+/**
+ * __cgroup_task_count - count the number of tasks in a cgroup. The caller
+ * is responsible for taking the css_set_lock.
+ * @cgrp: the cgroup in question
+ */
+int __cgroup_task_count(const struct cgroup *cgrp)
+{
+   int count = 0;
+   struct cgrp_cset_link *link;
+
+   lockdep_assert_held(_set_lock);
+
+   list_for_each_entry(link, >cset_links, cset_link)
+   count += link->cset->nr_tasks;
+
+   return count;
+}
+
+/**
+ * cgroup_task_count - count the number of tasks in a cgroup.
+ * @cgrp: the cgroup in question
+ */
+int cgroup_task_count(const struct cgroup *cgrp)
+{
+   int count;
+
+   spin_lock_irq(_set_lock);
+   count = __cgroup_task_count(cgrp);
+   spin_unlock_irq(_set_lock);
+
+   return count;
+}
+
 struct cgroup_subsys_state *of_css(struct kernfs_open_file *of)
 {
struct cgroup *cgrp = of->kn->parent->priv;
-- 
2.17.2



[PATCH v3 3/7] cgroup: protect cgroup->nr_(dying_)descendants by css_set_lock

2018-11-16 Thread Roman Gushchin
Now the number of descendant cgroups and the number of dying
descendant cgroups are synchronized using the cgroup_mutex.

The number of descendant cgroups will be required by the cgroup v2
freezer, which will use it to determine if a cgroup is frozen
(depending on total number of descendants and number of frozen
descendants). It's not always acceptable to grab the cgroup_mutex,
especially from quite hot paths (e.g. exit()).

To avoid this, let's additionally synchronize these counters
using the css_set_lock.

Signed-off-by: Roman Gushchin 
Cc: Tejun Heo 
Cc: kernel-t...@fb.com
---
 include/linux/cgroup-defs.h |  3 +++
 kernel/cgroup/cgroup.c  | 20 
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
index 22254c1fe1c5..9e77559c7f49 100644
--- a/include/linux/cgroup-defs.h
+++ b/include/linux/cgroup-defs.h
@@ -346,6 +346,9 @@ struct cgroup {
 * Dying cgroups are cgroups which were deleted by a user,
 * but are still existing because someone else is holding a reference.
 * max_descendants is a maximum allowed number of descent cgroups.
+*
+* nr_descendants and nr_dying_descendants are protected
+* by css_set_lock.
 */
int nr_descendants;
int nr_dying_descendants;
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index ef3442555b32..2241cb1d1238 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -3409,11 +3409,15 @@ static int cgroup_events_show(struct seq_file *seq, 
void *v)
 static int cgroup_stat_show(struct seq_file *seq, void *v)
 {
struct cgroup *cgroup = seq_css(seq)->cgroup;
+   int nr_descendants, nr_dying_descendants;
 
-   seq_printf(seq, "nr_descendants %d\n",
-  cgroup->nr_descendants);
-   seq_printf(seq, "nr_dying_descendants %d\n",
-  cgroup->nr_dying_descendants);
+   spin_lock_irq(_set_lock);
+   nr_descendants = cgroup->nr_descendants;
+   nr_dying_descendants = cgroup->nr_dying_descendants;
+   spin_unlock_irq(_set_lock);
+
+   seq_printf(seq, "nr_descendants %d\n", nr_descendants);
+   seq_printf(seq, "nr_dying_descendants %d\n", nr_dying_descendants);
 
return 0;
 }
@@ -4684,9 +4688,11 @@ static void css_release_work_fn(struct work_struct *work)
if (cgroup_on_dfl(cgrp))
cgroup_rstat_flush(cgrp);
 
+   spin_lock_irq(_set_lock);
for (tcgrp = cgroup_parent(cgrp); tcgrp;
 tcgrp = cgroup_parent(tcgrp))
tcgrp->nr_dying_descendants--;
+   spin_unlock_irq(_set_lock);
 
cgroup_idr_remove(>root->cgroup_idr, cgrp->id);
cgrp->id = -1;
@@ -4899,12 +4905,14 @@ static struct cgroup *cgroup_create(struct cgroup 
*parent)
if (ret)
goto out_idr_free;
 
+   spin_lock_irq(_set_lock);
for (tcgrp = cgrp; tcgrp; tcgrp = cgroup_parent(tcgrp)) {
cgrp->ancestor_ids[tcgrp->level] = tcgrp->id;
 
if (tcgrp != cgrp)
tcgrp->nr_descendants++;
}
+   spin_unlock_irq(_set_lock);
 
if (notify_on_release(parent))
set_bit(CGRP_NOTIFY_ON_RELEASE, >flags);
@@ -4956,6 +4964,7 @@ static bool cgroup_check_hierarchy_limits(struct cgroup 
*parent)
 
lockdep_assert_held(_mutex);
 
+   spin_lock_irq(_set_lock);
for (cgroup = parent; cgroup; cgroup = cgroup_parent(cgroup)) {
if (cgroup->nr_descendants >= cgroup->max_descendants)
goto fail;
@@ -4968,6 +4977,7 @@ static bool cgroup_check_hierarchy_limits(struct cgroup 
*parent)
 
ret = true;
 fail:
+   spin_unlock_irq(_set_lock);
return ret;
 }
 
@@ -5187,10 +5197,12 @@ static int cgroup_destroy_locked(struct cgroup *cgrp)
if (parent && cgroup_is_threaded(cgrp))
parent->nr_threaded_children--;
 
+   spin_lock_irq(_set_lock);
for (tcgrp = cgroup_parent(cgrp); tcgrp; tcgrp = cgroup_parent(tcgrp)) {
tcgrp->nr_descendants--;
tcgrp->nr_dying_descendants++;
}
+   spin_unlock_irq(_set_lock);
 
cgroup1_check_for_release(parent);
 
-- 
2.17.2



[PATCH v3 5/7] kselftests: cgroup: don't fail on cg_kill_all() error in cg_destroy()

2018-11-16 Thread Roman Gushchin
If the cgroup destruction races with an exit() of a belonging
process(es), cg_kill_all() may fail. It's not a good reason to make
cg_destroy() fail and leave the cgroup in place, potentially causing
next test runs to fail.

Signed-off-by: Roman Gushchin 
Cc: Shuah Khan 
Cc: Tejun Heo 
Cc: kernel-t...@fb.com
Cc: linux-kselft...@vger.kernel.org
---
 tools/testing/selftests/cgroup/cgroup_util.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/tools/testing/selftests/cgroup/cgroup_util.c 
b/tools/testing/selftests/cgroup/cgroup_util.c
index 14c9fe284806..eba06f94433b 100644
--- a/tools/testing/selftests/cgroup/cgroup_util.c
+++ b/tools/testing/selftests/cgroup/cgroup_util.c
@@ -227,9 +227,7 @@ int cg_destroy(const char *cgroup)
 retry:
ret = rmdir(cgroup);
if (ret && errno == EBUSY) {
-   ret = cg_killall(cgroup);
-   if (ret)
-   return ret;
+   cg_killall(cgroup);
usleep(100);
goto retry;
}
-- 
2.17.2



[PATCH v3 6/7] kselftests: cgroup: add freezer controller self-tests

2018-11-16 Thread Roman Gushchin
This patch implements six tests for the freezer controller for
cgroup v2:
1) a simple test, which aims to freeze and unfreeze a cgroup with 100
processes
2) a more complicated tree test, which creates a hierarchy of cgroups,
puts some processes in some cgroups, and tries to freeze and unfreeze
different parts of the subtree
3) a forkbomb test: the test aims to freeze a forkbomb running in a
cgroup, kill all tasks in the cgroup and remove the cgroup without
the unfreezing.
4) rmdir test: the test creates two nested cgroups, freezes the parent
one, checks that the child can be successfully removed, and a new
child can be created
5) migration tests: the test checks migration of a task between
frozen cgroups: from a frozen to a running, from a running to a
frozen, and from a frozen to a frozen.
6) ptrace test: the test checks that it's possible to attach to
a process in a frozen cgroup, get some information and detach, and
the cgroup will remain frozen.

Expected output:

  $ ./test_freezer
  ok 1 test_cgfreezer_simple
  ok 2 test_cgfreezer_tree
  ok 3 test_cgfreezer_forkbomb
  ok 4 test_cgrreezer_rmdir
  ok 5 test_cgfreezer_migrate
  ok 6 test_cgfreezer_ptrace

Signed-off-by: Roman Gushchin 
Cc: Shuah Khan 
Cc: Tejun Heo 
Cc: kernel-t...@fb.com
Cc: linux-kselft...@vger.kernel.org
---
 tools/testing/selftests/cgroup/.gitignore |   1 +
 tools/testing/selftests/cgroup/Makefile   |   2 +
 tools/testing/selftests/cgroup/cgroup_util.c  |  81 ++-
 tools/testing/selftests/cgroup/cgroup_util.h  |   7 +
 tools/testing/selftests/cgroup/test_freezer.c | 685 ++
 5 files changed, 775 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/cgroup/test_freezer.c

diff --git a/tools/testing/selftests/cgroup/.gitignore 
b/tools/testing/selftests/cgroup/.gitignore
index adacda50a4b2..7f9835624793 100644
--- a/tools/testing/selftests/cgroup/.gitignore
+++ b/tools/testing/selftests/cgroup/.gitignore
@@ -1,2 +1,3 @@
 test_memcontrol
 test_core
+test_freezer
diff --git a/tools/testing/selftests/cgroup/Makefile 
b/tools/testing/selftests/cgroup/Makefile
index 23fbaa4a9630..8d369b6a2069 100644
--- a/tools/testing/selftests/cgroup/Makefile
+++ b/tools/testing/selftests/cgroup/Makefile
@@ -5,8 +5,10 @@ all:
 
 TEST_GEN_PROGS = test_memcontrol
 TEST_GEN_PROGS += test_core
+TEST_GEN_PROGS += test_freezer
 
 include ../lib.mk
 
 $(OUTPUT)/test_memcontrol: cgroup_util.c
 $(OUTPUT)/test_core: cgroup_util.c
+$(OUTPUT)/test_freezer: cgroup_util.c
diff --git a/tools/testing/selftests/cgroup/cgroup_util.c 
b/tools/testing/selftests/cgroup/cgroup_util.c
index eba06f94433b..e9cdad673901 100644
--- a/tools/testing/selftests/cgroup/cgroup_util.c
+++ b/tools/testing/selftests/cgroup/cgroup_util.c
@@ -74,6 +74,16 @@ char *cg_name_indexed(const char *root, const char *name, 
int index)
return ret;
 }
 
+char *cg_control(const char *cgroup, const char *control)
+{
+   size_t len = strlen(cgroup) + strlen(control) + 2;
+   char *ret = malloc(len);
+
+   snprintf(ret, len, "%s/%s", cgroup, control);
+
+   return ret;
+}
+
 int cg_read(const char *cgroup, const char *control, char *buf, size_t len)
 {
char path[PATH_MAX];
@@ -196,7 +206,59 @@ int cg_create(const char *cgroup)
return mkdir(cgroup, 0644);
 }
 
-static int cg_killall(const char *cgroup)
+int cg_for_all_procs(const char *cgroup, int (*fn)(int pid, void *arg),
+void *arg)
+{
+   char buf[PAGE_SIZE];
+   char *ptr = buf;
+   int ret;
+
+   if (cg_read(cgroup, "cgroup.procs", buf, sizeof(buf)))
+   return -1;
+
+   while (ptr < buf + sizeof(buf)) {
+   int pid = strtol(ptr, , 10);
+
+   if (pid == 0)
+   break;
+   if (*ptr)
+   ptr++;
+   else
+   break;
+   ret = fn(pid, arg);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
+int cg_wait_for_proc_count(const char *cgroup, int count)
+{
+   char buf[10 * PAGE_SIZE] = {0};
+   int attempts;
+   char *ptr;
+
+   for (attempts = 10; attempts >= 0; attempts--) {
+   int nr = 0;
+
+   if (cg_read(cgroup, "cgroup.procs", buf, sizeof(buf)))
+   break;
+
+   for (ptr = buf; *ptr; ptr++)
+   if (*ptr == '\n')
+   nr++;
+
+   if (nr >= count)
+   return 0;
+
+   usleep(10);
+   }
+
+   return -1;
+}
+
+int cg_killall(const char *cgroup)
 {
char buf[PAGE_SIZE];
char *ptr = buf;
@@ -238,6 +300,14 @@ int cg_destroy(const char *cgroup)
return ret;
 }
 
+int cg_enter(const char *cgroup, int pid)
+{
+   char pidbuf[64];
+
+   snprintf(pidbuf, sizeof(pidbuf), "%d", pid);
+   return cg_write(cgroup, "cgroup.procs", pidbuf);
+}
+
 int cg_enter_current(const 

[PATCH v3 1/7] cgroup: rename freezer.c into legacy_freezer.c

2018-11-16 Thread Roman Gushchin
Freezer.c will contain an implementation of cgroup v2 freezer,
so let's rename the v1 freezer to avoid naming conflicts.

Signed-off-by: Roman Gushchin 
Cc: Tejun Heo 
Cc: kernel-t...@fb.com
---
 kernel/cgroup/Makefile| 2 +-
 kernel/cgroup/{freezer.c => legacy_freezer.c} | 0
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename kernel/cgroup/{freezer.c => legacy_freezer.c} (100%)

diff --git a/kernel/cgroup/Makefile b/kernel/cgroup/Makefile
index bfcdae896122..8d5689ca94b9 100644
--- a/kernel/cgroup/Makefile
+++ b/kernel/cgroup/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-y := cgroup.o rstat.o namespace.o cgroup-v1.o
 
-obj-$(CONFIG_CGROUP_FREEZER) += freezer.o
+obj-$(CONFIG_CGROUP_FREEZER) += legacy_freezer.o
 obj-$(CONFIG_CGROUP_PIDS) += pids.o
 obj-$(CONFIG_CGROUP_RDMA) += rdma.o
 obj-$(CONFIG_CPUSETS) += cpuset.o
diff --git a/kernel/cgroup/freezer.c b/kernel/cgroup/legacy_freezer.c
similarity index 100%
rename from kernel/cgroup/freezer.c
rename to kernel/cgroup/legacy_freezer.c
-- 
2.17.2



[PATCH v3 4/7] cgroup: cgroup v2 freezer

2018-11-16 Thread Roman Gushchin
Cgroup v1 implements the freezer controller, which provides an ability
to stop the workload in a cgroup and temporarily free up some
resources (cpu, io, network bandwidth and, potentially, memory)
for some other tasks. Cgroup v2 lacks this functionality.

This patch implements freezer for cgroup v2.

Cgroup v2 freezer tries to put tasks into a state similar to jobctl
stop. This means that tasks can be killed, ptraced (using
PTRACE_SEIZE*), and interrupted. It is possible to attach to
a frozen task, get some information (e.g. read registers) and detach.
It's also possible to migrate a frozen tasks to another cgroup.

This differs cgroup v2 freezer from cgroup v1 freezer, which mostly
tried to imitate the system-wide freezer. However uninterruptible
sleep is fine when all tasks are going to be frozen (hibernation case),
it's not the acceptable state for some subset of the system.

Cgroup v2 freezer is not supporting freezing kthreads.
If a non-root cgroup contains kthread, the cgroup still can be frozen,
but the kthread will remain running, the cgroup will be shown
as non-frozen, and the notification will not be delivered.

* PTRACE_ATTACH is not working because non-fatal signal delivery
is blocked in frozen state.

There are some interface differences between cgroup v1 and cgroup v2
freezer too, which are required to conform the cgroup v2 interface
design principles:
1) There is no separate controller, which has to be turned on:
the functionality is always available and is represented by
cgroup.freeze and cgroup.events cgroup control files.
2) The desired state is defined by the cgroup.freeze control file.
Any hierarchical configuration is allowed.
3) The interface is asynchronous. The actual state is available
using cgroup.events control file ("frozen" field). There are no
dedicated transitional states.
4) It's allowed to make any changes with the cgroup hierarchy
(create new cgroups, remove old cgroups, move tasks between cgroups)
no matter if some cgroups are frozen.

Signed-off-by: Roman Gushchin 
Cc: Tejun Heo 
Cc: Oleg Nesterov 
Cc: kernel-t...@fb.com
---
 include/linux/cgroup-defs.h  |  28 
 include/linux/cgroup.h   |  42 +
 include/linux/sched.h|   2 +
 include/linux/sched/jobctl.h |   2 +
 include/linux/sched/signal.h |   2 +
 kernel/cgroup/Makefile   |   2 +-
 kernel/cgroup/cgroup.c   | 112 -
 kernel/cgroup/freezer.c  | 302 +++
 kernel/ptrace.c  |   7 +
 kernel/signal.c  |  57 +--
 10 files changed, 538 insertions(+), 18 deletions(-)
 create mode 100644 kernel/cgroup/freezer.c

diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
index 9e77559c7f49..d1ba02771baf 100644
--- a/include/linux/cgroup-defs.h
+++ b/include/linux/cgroup-defs.h
@@ -63,6 +63,12 @@ enum {
 * specified at mount time and thus is implemented here.
 */
CGRP_CPUSET_CLONE_CHILDREN,
+
+   /* Control group has to be frozen. */
+   CGRP_FREEZE,
+
+   /* Cgroup is frozen. */
+   CGRP_FROZEN,
 };
 
 /* cgroup_root->flags */
@@ -314,6 +320,25 @@ struct cgroup_rstat_cpu {
struct cgroup *updated_next;/* NULL iff not on the list */
 };
 
+struct cgroup_freezer_state {
+   /* Should the cgroup and its descendants be frozen. */
+   bool freeze;
+
+   /* Should the cgroup actually be frozen? */
+   int e_freeze;
+
+   /* Fields below are protected by css_set_lock */
+
+   /* Number of frozen descendant cgroups */
+   int nr_frozen_descendants;
+
+   /* Number of tasks to freeze */
+   int nr_tasks_to_freeze;
+
+   /* Number of frozen tasks */
+   int nr_frozen_tasks;
+};
+
 struct cgroup {
/* self css with NULL ->ss, points back to this cgroup */
struct cgroup_subsys_state self;
@@ -445,6 +470,9 @@ struct cgroup {
/* If there is block congestion on this cgroup. */
atomic_t congestion_count;
 
+   /* Used to store internal freezer state */
+   struct cgroup_freezer_state freezer;
+
/* ids of the ancestors at each level including self */
int ancestor_ids[];
 };
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 32c553556bbd..a40a54f322b4 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -871,4 +871,46 @@ static inline void put_cgroup_ns(struct cgroup_namespace 
*ns)
free_cgroup_ns(ns);
 }
 
+#ifdef CONFIG_CGROUPS
+
+void cgroup_enter_frozen(void);
+void cgroup_leave_frozen(void);
+void cgroup_freeze(struct cgroup *cgrp, bool freeze);
+void cgroup_update_frozen(struct cgroup *cgrp, bool frozen);
+void cgroup_freezer_migrate_task(struct task_struct *task, struct cgroup *src,
+struct cgroup *dst);
+static inline bool cgroup_task_freeze(struct task_struct *task)
+{
+   bool ret;
+
+   if (task->flags & PF_KTHREAD)
+   return false;
+
+   rcu_read_lock();
+   ret 

Re: [PATCH v3 1/2] x86/fpu: track AVX-512 usage of tasks

2018-11-16 Thread Li, Aubrey
On 2018/11/17 7:10, Dave Hansen wrote:
> On 11/15/18 4:21 PM, Li, Aubrey wrote:
>> "Core cycles where the core was running with power delivery for license
>> level 2 (introduced in Skylake Server microarchitecture). This includes
>> high current AVX 512-bit instructions."
>>
>> I translated license level 2 to frequency drop.
> 
> BTW, the "high" in that text: "high-current AVX 512-bit instructions" is
> talking about high-current, not "high ... instructions" or high-numbered
> registers.  I think that might be the source of some of the confusion
> about which XSAVE state needs to be examined.
> 
> Just to be clear: there are 3 AVX-512 XSAVE states:
> 
> XFEATURE_OPMASK,
> XFEATURE_ZMM_Hi256,
> XFEATURE_Hi16_ZMM,
> 
> I honestly don't know what XFEATURE_OPMASK does.  It does not appear to
> be affected by VZEROUPPER (although VZEROUPPER's SDM documentation isn't
> looking too great).
> 
> But, XFEATURE_ZMM_Hi256 is used for the upper 256 bits of the
> registers ZMM0-ZMM15.  Those are AVX-512-only registers.  The only way
> to get data into XFEATURE_ZMM_Hi256 state is by using AVX512 instructions.
> 
> XFEATURE_Hi16_ZMM is the same.  The only way to get state in there is
> with AVX512 instructions.
> 
> So, first of all, I think you *MUST* check XFEATURE_ZMM_Hi256 and
> XFEATURE_Hi16_ZMM.  That's without question.

No, XFEATURE_ZMM_Hi256 does not request turbo license 2, so it's less
interested to us.

> 
> It's probably *possible* to run AVX512 instructions by loading state
> into the YMM register and then executing AVX512 instructions that only
> write to memory and never to register state.  That *might* allow
> XFEATURE_Hi16_ZMM and XFEATURE_ZMM_Hi256 to stay in the init state, but
> for the frequency to be affected since AVX512 instructions _are_
> executing.  But, there's no way to detect this situation from XSAVE
> states themselves.
> 

Andi should have more details on this. FWICT, not all AVX512 instructions
has high current, those only touching memory do not cause notable frequency
drop.

Thanks,
-Aubrey


Re: [PATCH v2 2/2] build_bug.h: remove all dummy BUILD_BUG_ON stubs for sparse

2018-11-16 Thread Luc Van Oostenryck
On Fri, Nov 16, 2018 at 03:27:25PM +0900, Masahiro Yamada wrote:
> The introduction of these dummy BUILD_BUG_ON stubs dates back to
> commit 903c0c7cdc21 ("sparse: define dummy BUILD_BUG_ON definition
> for sparse"). At that time, BUILD_BUG_ON() was implemented with the
> negative array trick, which Sparse complains about even if the
> condition can be optimized and evaluated to 0 at compile-time.

OK, but from what I understand, the motivation for commit 903c0c7cdc21
was not to avoid false warnings but to avoid having twice the same
warnings: "... So it causes sparse to detect an error too. This
reduces sparse's usefulness.").

I'm not opposed to this patch (on the contrary, I think it's better
to have exactly the same code for GCC than for sparse) but I think
that your commit message need to be adjusted.

Kind regards,
-- Luc


Re: [Patch v4 2/3] CIFS: Add support for direct I/O write

2018-11-16 Thread Pavel Shilovsky
ср, 31 окт. 2018 г. в 15:26, Long Li :
>
> From: Long Li 
>
> With direct I/O write, user supplied buffers are pinned to the memory and data
> are transferred directly from user buffers to the transport layer.
>
> Change in v3: add support for kernel AIO
>
> Change in v4:
> Refactor common write code to __cifs_writev for direct and non-direct I/O.
> Retry on direct I/O failure.
>
> Signed-off-by: Long Li 
> ---
>  fs/cifs/cifsfs.h |   1 +
>  fs/cifs/file.c   | 194 
> +++
>  2 files changed, 154 insertions(+), 41 deletions(-)
>
> diff --git a/fs/cifs/cifsfs.h b/fs/cifs/cifsfs.h
> index 7fba9aa..e9c5103 100644
> --- a/fs/cifs/cifsfs.h
> +++ b/fs/cifs/cifsfs.h
> @@ -105,6 +105,7 @@ extern ssize_t cifs_user_readv(struct kiocb *iocb, struct 
> iov_iter *to);
>  extern ssize_t cifs_direct_readv(struct kiocb *iocb, struct iov_iter *to);
>  extern ssize_t cifs_strict_readv(struct kiocb *iocb, struct iov_iter *to);
>  extern ssize_t cifs_user_writev(struct kiocb *iocb, struct iov_iter *from);
> +extern ssize_t cifs_direct_writev(struct kiocb *iocb, struct iov_iter *from);
>  extern ssize_t cifs_strict_writev(struct kiocb *iocb, struct iov_iter *from);
>  extern int cifs_lock(struct file *, int, struct file_lock *);
>  extern int cifs_fsync(struct file *, loff_t, loff_t, int);
> diff --git a/fs/cifs/file.c b/fs/cifs/file.c
> index daab878..1a41c04 100644
> --- a/fs/cifs/file.c
> +++ b/fs/cifs/file.c
> @@ -2524,6 +2524,55 @@ wdata_fill_from_iovec(struct cifs_writedata *wdata, 
> struct iov_iter *from,
>  }
>
>  static int
> +cifs_resend_wdata(struct cifs_writedata *wdata, struct list_head 
> *wdata_list, struct cifs_aio_ctx *ctx)
> +{
> +   int wait_retry = 0;
> +   unsigned int wsize, credits;
> +   int rc;
> +   struct TCP_Server_Info *server = 
> tlink_tcon(wdata->cfile->tlink)->ses->server;
> +
> +   /*
> +* Try to resend this wdata, waiting for credits up to 3 seconds.
> +* Note: we are attempting to resend the whole wdata not in segments
> +*/
> +   do {
> +   rc = server->ops->wait_mtu_credits(server, wdata->bytes, 
> , );
> +
> +   if (rc)
> +   break;
> +
> +   if (wsize < wdata->bytes) {
> +   add_credits_and_wake_if(server, credits, 0);
> +   msleep(1000);
> +   wait_retry++;
> +   }
> +   } while (wsize < wdata->bytes && wait_retry < 3);
> +
> +   if (wsize < wdata->bytes) {
> +   rc = -EBUSY;
> +   goto out;
> +   }
> +
> +   rc = -EAGAIN;
> +   while (rc == -EAGAIN)
> +   if (!wdata->cfile->invalidHandle ||
> +   !(rc = cifs_reopen_file(wdata->cfile, false)))
> +   rc = server->ops->async_writev(wdata,
> +   cifs_uncached_writedata_release);
> +
> +   if (!rc) {
> +   list_add_tail(>list, wdata_list);
> +   return 0;
> +   }
> +
> +   add_credits_and_wake_if(server, wdata->credits, 0);
> +out:
> +   kref_put(>refcount, cifs_uncached_writedata_release);
> +
> +   return rc;
> +}
> +
> +static int
>  cifs_write_from_iter(loff_t offset, size_t len, struct iov_iter *from,
>  struct cifsFileInfo *open_file,
>  struct cifs_sb_info *cifs_sb, struct list_head 
> *wdata_list,
> @@ -2537,6 +2586,8 @@ cifs_write_from_iter(loff_t offset, size_t len, struct 
> iov_iter *from,
> loff_t saved_offset = offset;
> pid_t pid;
> struct TCP_Server_Info *server;
> +   struct page **pagevec;
> +   size_t start;
>
> if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_RWPIDFORWARD)
> pid = open_file->pid;
> @@ -2553,38 +2604,74 @@ cifs_write_from_iter(loff_t offset, size_t len, 
> struct iov_iter *from,
> if (rc)
> break;
>
> -   nr_pages = get_numpages(wsize, len, _len);
> -   wdata = cifs_writedata_alloc(nr_pages,
> +   if (ctx->direct_io) {
> +   cur_len = iov_iter_get_pages_alloc(
> +   from, , wsize, );
> +   if (cur_len < 0) {
> +   cifs_dbg(VFS,
> +   "direct_writev couldn't get user 
> pages "
> +   "(rc=%zd) iter type %d iov_offset %zd 
> count"
> +   " %zd\n",
> +   cur_len, from->type,
> +   from->iov_offset, from->count);
> +   dump_stack();
> +   break;
> +   }
> +   iov_iter_advance(from, cur_len);
> +
> +   nr_pages = (cur_len + start + PAGE_SIZE - 1) / 
> PAGE_SIZE;
> +
> +

Re: [Patch v4 1/3] CIFS: Add support for direct I/O read

2018-11-16 Thread Pavel Shilovsky
Hi Long,

Please find my comments below.


ср, 31 окт. 2018 г. в 15:14, Long Li :
>
> From: Long Li 
>
> With direct I/O read, we transfer the data directly from transport layer to
> the user data buffer.
>
> Change in v3: add support for kernel AIO
>
> Change in v4:
> Refactor common read code to __cifs_readv for direct and non-direct I/O.
> Retry on direct I/O failure.
>
> Signed-off-by: Long Li 
> ---
>  fs/cifs/cifsfs.h   |   1 +
>  fs/cifs/cifsglob.h |   5 ++
>  fs/cifs/file.c | 219 
> +++--
>  3 files changed, 186 insertions(+), 39 deletions(-)
>
> diff --git a/fs/cifs/cifsfs.h b/fs/cifs/cifsfs.h
> index 5f02318..7fba9aa 100644
> --- a/fs/cifs/cifsfs.h
> +++ b/fs/cifs/cifsfs.h
> @@ -102,6 +102,7 @@ extern int cifs_open(struct inode *inode, struct file 
> *file);
>  extern int cifs_close(struct inode *inode, struct file *file);
>  extern int cifs_closedir(struct inode *inode, struct file *file);
>  extern ssize_t cifs_user_readv(struct kiocb *iocb, struct iov_iter *to);
> +extern ssize_t cifs_direct_readv(struct kiocb *iocb, struct iov_iter *to);
>  extern ssize_t cifs_strict_readv(struct kiocb *iocb, struct iov_iter *to);
>  extern ssize_t cifs_user_writev(struct kiocb *iocb, struct iov_iter *from);
>  extern ssize_t cifs_strict_writev(struct kiocb *iocb, struct iov_iter *from);
> diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h
> index 7f62c98..52248dd 100644
> --- a/fs/cifs/cifsglob.h
> +++ b/fs/cifs/cifsglob.h
> @@ -1146,6 +1146,11 @@ struct cifs_aio_ctx {
> unsigned intlen;
> unsigned inttotal_len;
> boolshould_dirty;
> +   /*
> +* Indicates if this aio_ctx is for direct_io,
> +* If yes, iter is a copy of the user passed iov_iter
> +*/
> +   booldirect_io;
>  };
>
>  struct cifs_readdata;
> diff --git a/fs/cifs/file.c b/fs/cifs/file.c
> index 87eece6..daab878 100644
> --- a/fs/cifs/file.c
> +++ b/fs/cifs/file.c
> @@ -2965,7 +2965,6 @@ cifs_uncached_readdata_release(struct kref *refcount)
> kref_put(>ctx->refcount, cifs_aio_ctx_release);
> for (i = 0; i < rdata->nr_pages; i++) {
> put_page(rdata->pages[i]);
> -   rdata->pages[i] = NULL;
> }
> cifs_readdata_release(refcount);
>  }
> @@ -3092,6 +3091,63 @@ cifs_uncached_copy_into_pages(struct TCP_Server_Info 
> *server,
> return uncached_fill_pages(server, rdata, iter, iter->count);
>  }
>
> +static int cifs_resend_rdata(struct cifs_readdata *rdata,
> + struct list_head *rdata_list,
> + struct cifs_aio_ctx *ctx)
> +{
> +   int wait_retry = 0;
> +   unsigned int rsize, credits;
> +   int rc;
> +   struct TCP_Server_Info *server = 
> tlink_tcon(rdata->cfile->tlink)->ses->server;
> +
> +   /*
> +* Try to resend this rdata, waiting for credits up to 3 seconds.
> +* Note: we are attempting to resend the whole rdata not in segments
> +*/
> +   do {
> +   rc = server->ops->wait_mtu_credits(server, rdata->bytes,
> +   , );
> +
> +   if (rc)
> +   break;
> +
> +   if (rsize < rdata->bytes) {
> +   add_credits_and_wake_if(server, credits, 0);
> +   msleep(1000);
> +   wait_retry++;
> +   }
> +   } while (rsize < rdata->bytes && wait_retry < 3);
> +
> +   /*
> +* If we can't find enough credits to send this rdata
> +* release the rdata and return failure, this will pass
> +* whatever I/O amount we have finished to VFS.
> +*/
> +   if (rsize < rdata->bytes) {
> +   rc = -EBUSY;

We don't have enough credits and return EBUSY here...

> +   goto out;
> +   }
> +
> +   rc = -EAGAIN;
> +   while (rc == -EAGAIN)
> +   if (!rdata->cfile->invalidHandle ||
> +   !(rc = cifs_reopen_file(rdata->cfile, true)))
> +   rc = server->ops->async_readv(rdata);
> +
> +   if (!rc) {
> +   /* Add to aio pending list */
> +   list_add_tail(>list, rdata_list);
> +   return 0;
> +   }
> +
> +   add_credits_and_wake_if(server, rdata->credits, 0);
> +out:
> +   kref_put(>refcount,
> +   cifs_uncached_readdata_release);
> +
> +   return rc;
> +}
> +
>  static int
>  cifs_send_async_read(loff_t offset, size_t len, struct cifsFileInfo 
> *open_file,
>  struct cifs_sb_info *cifs_sb, struct list_head 
> *rdata_list,
> @@ -3103,6 +3159,9 @@ cifs_send_async_read(loff_t offset, size_t len, struct 
> cifsFileInfo *open_file,
> int rc;
> pid_t pid;
> struct TCP_Server_Info *server;
> +   struct page **pagevec;
> +   size_t start;
> +   struct iov_iter 

[PATCH 0/9] dt-bindings: Firmware node binding for ZynqMP core

2018-11-16 Thread Jolly Shah
Base firmware node and clock child node binding are part of mainline kernel. 
This patchset adds documentation to describe rest of the firmware child node 
bindings. 
Complete firmware DT node example is shown below for ease of understanding:

firmware {
zynqmp_firmware: zynqmp-firmware {
compatible = "xlnx,zynqmp-firmware";
method = "smc";
#power-domain-cells = <1>;
#reset-cells = <1>;

zynqmp_clk: clock-controller {
#clock-cells = <1>;
compatible = "xlnx,zynqmp-clk";
clocks = <_ref_clk>, <_clk>, 
<_alt_ref_clk>, <_ref_clk>, <_crx_ref_clk>;
clock-names = "pss_ref_clk", "video_clk", 
"pss_alt_ref_clk","aux_ref_clk", "gt_crx_ref_clk";
};

zynqmp_power: zynqmp-power {
compatible = "xlnx,zynqmp-power";
interrupts = <0 35 4>;
};

nvmem_firmware {
compatible = "xlnx,zynqmp-nvmem-fw";
#address-cells = <1>;
#size-cells = <1>;

/* Data cells */
soc_revision: soc_revision {
reg = <0x0 0x4>;
};
};

afi0: afi0 {
compatible = "xlnx,afi-fpga";
config-afi = <0 2>, <1 1>, <2 1>;
};

qspi: spi@ff0f {
compatible = "xlnx,zynqmp-qspi-1.0";
clock-names = "ref_clk", "pclk";
clocks = <_clk _clk>;
interrupts = <0 15 4>;
interrupt-parent = <>;
num-cs = <1>;
reg = <0x0 0xff0f 0x1000>,<0x0 0xc000 
0x800>;
};

serdes: zynqmp_phy@fd40 {
compatible = "xlnx,zynqmp-psgtr";
status = "okay";
reg = <0x0 0xfd40 0x0 0x4>, <0x0 0xfd3d 0x0 
0x1000>,
<0x0 0xff5e 0x0 0x1000>;
reg-names = "serdes", "siou", "lpd";

lane0: lane@0 {
#phy-cells = <4>;
};
lane1: lane@1 {
#phy-cells = <4>;
};
lane2: lane@2 {
#phy-cells = <4>;
};
lane3: lane@3 {
#phy-cells = <4>;
};
};

pinctrl_uart1_default: uart1-default {
mux {
groups = "uart0_4_grp";
function = "uart0";
};

conf {
groups = "uart0_4_grp";
slew-rate = ;
io-standard = ;
};

conf-rx {
pins = "MIO18";
bias-high-impedance;
};

conf-tx {
pins = "MIO19";
bias-disable;
schmitt-cmos = ;
};
};
zynqmp-r5-remoteproc@0 {
compatible = "xlnx,zynqmp-r5-remoteproc-1.0";
reg = <0x0 0xFFE0 0x0 0x1>,
<0x0 0xFFE2 0x0 0x1>,
<0x0 0xff34 0x0 0x100>;
reg-names = "tcm_a", "tcm_b", "ipi";
dma-ranges;
core_conf = "split0";
memory-region = <_0_fw_reserved>,
<_0_dma_reserved>;
tcm-pnode-id = <0xf>, <0x10>;
rpu-pnode-id = <0x7>;
interrupt-parent = <>;
interrupts = <0 29 4>;
};
};
};

Jolly Shah (2):
  dt-bindings: phy: Add dt bindings for ZynqMP PHY
  dt-bindings: fpga: Add binding doc for the afi config driver

Nava kishore Manne (2):
  dt-bindings: reset: Add bindings for ZynqMP reset driver
  dt-bindings: nvmem: Add bindings for ZynqMP nvmem driver

Rajan Vaja (4):
  dt-bindings: power: Add ZynqMP power domain bindings
  dt-bindings: soc: Add ZynqMP PM bindings
  dt-bindings: pinctrl: Add ZynqMP pin controller bindings
  dt-bindings: spi: zynqmp: Move SPI node under zynqmp firmware

Wendy Liang (1):
  dt-bindings: remoteproc: Add Xilinx 

[PATCH 7/9] dt-bindings: phy: Add dt bindings for ZynqMP PHY

2018-11-16 Thread Jolly Shah
This patch adds the document describing dt bindings for ZynqMP
PHY. ZynqMP SOC has a High Speed Processing System Gigabit
Transceiver which provides PHY capabilties to USB, SATA,
PCIE, Display Port and Ehernet SGMII controllers.

Signed-off-by: Anurag Kumar Vulisha 
Signed-off-by: Jolly Shah 
Signed-off-by: Michal Simek 
---
 .../devicetree/bindings/phy/phy-zynqmp.txt | 126 +
 1 file changed, 126 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-zynqmp.txt

diff --git a/Documentation/devicetree/bindings/phy/phy-zynqmp.txt 
b/Documentation/devicetree/bindings/phy/phy-zynqmp.txt
new file mode 100644
index 000..21cb722
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-zynqmp.txt
@@ -0,0 +1,126 @@
+Xilinx ZynqMP PHY binding
+
+This binding describes a ZynqMP PHY device that is used to control ZynqMP
+High Speed Gigabit Transceiver(GT). ZynqMP PS GTR provides four lanes
+and are used by USB, SATA, PCIE, Display port and Ethernet SGMMI controllers.
+
+Required properties (controller (parent) node):
+- compatible   : Can be "xlnx,zynqmp-psgtr-v1.1" or "xlnx,zynqmp-psgtr"
+ "xlnx,zynqmp-psgtr-v1.1" has the lpd address mapping removed
+
+- reg   : Address and length of register sets for each device in
+  "reg-names"
+- reg-names : The names of the register addresses corresponding to the
+ registers filled in "reg":
+   - serdes: SERDES block register set
+   - siou: SIOU block register set
+   - lpd: Low power domain peripherals reset control
+
+Required nodes :  A sub-node is required for each lane the controller
+  provides.
+
+Required properties (port (child) nodes):
+lane0:
+- #phy-cells   : Should be 4
+ Cell after port phandle is device type from:
+   - 
+   - 
+   - 
+   - 
+   - 
+lane1:
+- #phy-cells   : Should be 4
+ Cell after port phandle is device type from:
+   - 
+   - 
+   - 
+   - 
+   - 
+lane2:
+- #phy-cells   : Should be 4
+ Cell after port phandle is device type from:
+   - 
+   - 
+   - 
+   - 
+   - 
+lane3:
+- #phy-cells   : Should be 4
+ Cell after port phandle is device type from:
+   - 
+   - 
+   - 
+   - 
+   - 
+
+Note:  LANE_NUM : This determines which lane's reference clock is shared by 
controller.
+   FREQUENCY: This the clock frequency at which controller wants to 
operate.
+
+
+Example:
+firmware {
+   zynqmp_firmware: zynqmp-firmware {
+   compatible = "xlnx,zynqmp-firmware";
+   method = "smc";
+
+   serdes: zynqmp_phy@fd40 {
+   compatible = "xlnx,zynqmp-psgtr";
+   status = "okay";
+   reg = <0x0 0xfd40 0x0 0x4>, <0x0 0xfd3d 0x0 
0x1000>,
+   <0x0 0xff5e 0x0 0x1000>;
+   reg-names = "serdes", "siou", "lpd";
+
+   lane0: lane@0 {
+   #phy-cells = <4>;
+   };
+   lane1: lane@1 {
+   #phy-cells = <4>;
+   };
+   lane2: lane@2 {
+   #phy-cells = <4>;
+   };
+   lane3: lane@3 {
+   #phy-cells = <4>;
+   };
+   };
+   };
+};
+
+Specifying phy control of devices
+=
+
+Device nodes should specify the configuration required in their "phys"
+property, containing a phandle to the phy port node and a device type.
+
+phys = ;
+
+PHANDLE =  or  or  or 
+CONTROLLER_TYPE = PHY_TYPE_PCIE or PHY_TYPE_SATA or PHY_TYPE_USB
+ or PHY_TYPE_DP or PHY_TYPE_SGMII
+CONTROLLER_INSTANCE = Depends on controller type used, can be any of
+   PHY_TYPE_PCIE : 0 or 1 or 2 or 3
+   PHY_TYPE_SATA : 0 or 1
+   PHY_TYPE_USB  : 0 or 1
+   PHY_TYPE_DP   : 0 or 1
+   PHY_TYPE_SGMII: 0 or 1 or 2 or 3
+LANE_NUM= Depends on which lane clock is used as ref clk, can 
be
+ 0 or 1 or 2 or 3
+LANE_FREQ   = Frequency that controller can operate, can be any of
+ 19.2Mhz,20Mhz,24Mhz,26Mhz,27Mhz,28.4Mhz,40Mhz,52Mhz,
+

[PATCH 8/9] dt-bindings: remoteproc: Add Xilinx R5 rproc binding

2018-11-16 Thread Jolly Shah
From: Wendy Liang 

Add device tree binding for Xilinx Cortex-r5 remoteproc.

Signed-off-by: Wendy Liang 
Signed-off-by: Jolly Shah 
---
 .../remoteproc/xlnx,zynqmp-r5-remoteproc.txt   | 81 ++
 1 file changed, 81 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5-remoteproc.txt

diff --git 
a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5-remoteproc.txt 
b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5-remoteproc.txt
new file mode 100644
index 000..4831350
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5-remoteproc.txt
@@ -0,0 +1,81 @@
+Xilinx ARM Cortex A53-R5 remoteproc driver
+==
+
+ZynqMP family of devices use two Cortex R5 processors to help with various
+low power / real time tasks.
+
+This driver requires specific ZynqMP hardware design.
+
+ZynqMP R5 RemoteProc Device Node:
+=
+A zynqmp_r5_remoteproc device node is used to represent a R5 IP instance
+within ZynqMP SoC.
+
+Required properties:
+
+ - compatible : Should be "xlnx,zynqmp-r5-remoteproc-1.0"
+ - reg : Address and length of the register set for the device. It
+contains in the same order as described reg-names
+ - reg-names: Contain the register set names.
+  "tcm_a" and "tcm_b" for TCM memories.
+  If the user uses the remoteproc driver with the RPMsg kernel
+  driver,"ipi" for the IPI register used to communicate with RPU
+  is also required.
+  Otherwise, if user only uses the remoteproc driver to boot RPU
+  firmware, "ipi" is not required.
+ - tcm-pnode-id: TCM resources power nodes IDs which are used to request TCM
+ resources for the remoteproc driver to access.
+ - rpu-pnode-id : RPU power node id which is used by the remoteproc driver
+  to start RPU or shut it down.
+
+Optional properties:
+
+ - core_conf : R5 core configuration (valid string - split0 or split1 or
+   lock-step), default is lock-step.
+ - memory-region: memories regions for RPU executable and DMA memory.
+ - interrupts : Interrupt mapping for remoteproc IPI. It is required if the
+user uses the remoteproc driver with the RPMsg kernel driver.
+ - interrupt-parent : Phandle for the interrupt controller. It is required if
+  the user uses the remoteproc driver with the RPMsg kernel
+  kernel driver.
+
+Example:
+
+   reserved-memory {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   rproc_0_fw_reserved: rproc@3ed00 {
+   compatible = "rproc-prog-memory";
+   no-map;
+   reg = <0x0 0x3ed0 0x0 0x4>;
+   };
+   rproc_0_dma_reserved: rproc@3ed40 {
+   compatible = "shared-dma-pool";
+   no-map;
+   reg = <0x0 0x3ed4 0x0 0x8>;
+   };
+   };
+
+   firmware {
+   zynqmp_firmware: zynqmp-firmware {
+   compatible = "xlnx,zynqmp-firmware";
+   method = "smc";
+
+   zynqmp-r5-remoteproc@0 {
+   compatible = "xlnx,zynqmp-r5-remoteproc-1.0";
+   reg = <0x0 0xFFE0 0x0 0x1>,
+   <0x0 0xFFE2 0x0 0x1>,
+   <0x0 0xff34 0x0 0x100>;
+   reg-names = "tcm_a", "tcm_b", "ipi";
+   dma-ranges;
+   core_conf = "split0";
+   memory-region = <_0_fw_reserved>,
+   <_0_dma_reserved>;
+   tcm-pnode-id = <0xf>, <0x10>;
+   rpu-pnode-id = <0x7>;
+   interrupt-parent = <>;
+   interrupts = <0 29 4>;
+   } ;
+   };
+   };
-- 
2.7.4



[PATCH 4/9] dt-bindings: nvmem: Add bindings for ZynqMP nvmem driver

2018-11-16 Thread Jolly Shah
From: Nava kishore Manne 

Add documentation to describe Xilinx ZynqMP nvmem driver
bindings.

Signed-off-by: Nava kishore Manne 
Signed-off-by: Jolly Shah 
---
 .../bindings/nvmem/xlnx,zynqmp-nvmem.txt   | 44 ++
 1 file changed, 44 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt

diff --git a/Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt 
b/Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt
new file mode 100644
index 000..090ba08
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt
@@ -0,0 +1,44 @@
+--
+=  Zynq UltraScale+ MPSoC nvmem firmware driver binding =
+--
+The nvmem_firmware node provides access to the hardware related data
+like soc revision, IDCODE... etc, By using the firmware interface.
+
+Required properties:
+- compatible: should be "xlnx,zynqmp-nvmem-fw"
+
+= Data cells =
+Are child nodes of silicon id, bindings of which as described in
+bindings/nvmem/nvmem.txt
+
+---
+ Example
+---
+firmware {
+   zynqmp_firmware: zynqmp-firmware {
+   compatible = "xlnx,zynqmp-firmware";
+   method = "smc";
+
+   nvmem_firmware {
+   compatible = "xlnx,zynqmp-nvmem-fw";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   /* Data cells */
+   soc_revision: soc_revision {
+   reg = <0x0 0x4>;
+   };
+   };
+   };
+};
+
+= Data consumers =
+Are device nodes which consume nvmem data cells.
+
+For example:
+   pcap {
+   ...
+   nvmem-cells = <_revision>;
+   nvmem-cell-names = "soc_revision";
+   };
+
-- 
2.7.4



[PATCH 1/9] dt-bindings: power: Add ZynqMP power domain bindings

2018-11-16 Thread Jolly Shah
From: Rajan Vaja 

Add documentation to describe ZynqMP power domain bindings.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 .../bindings/power/xlnx,zynqmp-genpd.txt   | 34 +++
 include/dt-bindings/power/xlnx-zynqmp-power.h  | 39 ++
 2 files changed, 73 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
 create mode 100644 include/dt-bindings/power/xlnx-zynqmp-power.h

diff --git a/Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt 
b/Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
new file mode 100644
index 000..3c7f237
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
@@ -0,0 +1,34 @@
+---
+Device Tree Bindings for the Xilinx Zynq MPSoC PM domains
+---
+The binding for zynqmp-power-controller follow the common
+generic PM domain binding[1].
+
+[1] Documentation/devicetree/bindings/power/power_domain.txt
+
+== Zynq MPSoC Generic PM Domain Node ==
+
+Required property:
+ - Below property should be in zynqmp-firmware node.
+ - #power-domain-cells:Number of cells in a PM domain specifier. Must 
be 1.
+
+Power domain ID indexes are mentioned in
+include/dt-bindings/power/xlnx-zynqmp-power.h.
+
+---
+Example
+---
+
+firmware {
+   zynqmp_firmware: zynqmp-firmware {
+   ...
+   #power-domain-cells = <1>;
+   ...
+   };
+};
+
+sata {
+   ...
+   power-domains = <_firmware 2>;
+   ...
+};
diff --git a/include/dt-bindings/power/xlnx-zynqmp-power.h 
b/include/dt-bindings/power/xlnx-zynqmp-power.h
new file mode 100644
index 000..1bc9636
--- /dev/null
+++ b/include/dt-bindings/power/xlnx-zynqmp-power.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ *  Copyright (C) 2018 Xilinx, Inc.
+ */
+
+#ifndef _DT_BINDINGS_ZYNQMP_POWER_H
+#define _DT_BINDINGS_ZYNQMP_POWER_H
+
+#definePD_USB_00
+#definePD_USB_11
+#definePD_SATA 2
+#definePD_SPI_03
+#definePD_SPI_14
+#definePD_UART_0   5
+#definePD_UART_1   6
+#definePD_ETH_07
+#definePD_ETH_18
+#definePD_ETH_29
+#definePD_ETH_310
+#definePD_I2C_011
+#definePD_I2C_112
+#definePD_DP   13
+#definePD_GDMA 14
+#definePD_ADMA 15
+#definePD_TTC_016
+#definePD_TTC_117
+#definePD_TTC_218
+#definePD_TTC_319
+#definePD_SD_0 20
+#definePD_SD_1 21
+#definePD_NAND 22
+#definePD_QSPI 23
+#definePD_GPIO 24
+#definePD_CAN_025
+#definePD_CAN_126
+#definePD_PCIE 27
+#definePD_GPU  28
+
+#endif
-- 
2.7.4



[PATCH 6/9] dt-bindings: spi: zynqmp: Move SPI node under zynqmp firmware

2018-11-16 Thread Jolly Shah
From: Rajan Vaja 

SPI driver uses ZynqMP firmware interface and so it should be
populated by firmware driver.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 .../devicetree/bindings/spi/spi-zynqmp-qspi.txt| 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt 
b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt
index 0f6d37f..767bb8e 100644
--- a/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt
+++ b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt
@@ -14,12 +14,18 @@ Optional properties:
 - num-cs   : Number of chip selects used.
 
 Example:
-   qspi: spi@ff0f {
-   compatible = "xlnx,zynqmp-qspi-1.0";
-   clock-names = "ref_clk", "pclk";
-   clocks = <_clk _clk>;
-   interrupts = <0 15 4>;
-   interrupt-parent = <>;
-   num-cs = <1>;
-   reg = <0x0 0xff0f 0x1000>,<0x0 0xc000 0x800>;
+firmware {
+   zynqmp_firmware: zynqmp-firmware {
+   compatible = "xlnx,zynqmp-firmware";
+   method = "smc";
+   qspi: spi@ff0f {
+   compatible = "xlnx,zynqmp-qspi-1.0";
+   clock-names = "ref_clk", "pclk";
+   clocks = <_clk _clk>;
+   interrupts = <0 15 4>;
+   interrupt-parent = <>;
+   num-cs = <1>;
+   reg = <0x0 0xff0f 0x1000>,<0x0 0xc000 
0x800>;
+   };
};
+};
-- 
2.7.4



[PATCH 9/9] dt-bindings: fpga: Add binding doc for the afi config driver

2018-11-16 Thread Jolly Shah
Add the binding document for the afi config driver.

Signed-off-by: Shubhrajyoti Datta 
Signed-off-by: Michal Simek 
Signed-off-by: Jolly Shah 
---
 .../devicetree/bindings/fpga/xlnx,afi-fpga.txt | 67 ++
 1 file changed, 67 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/fpga/xlnx,afi-fpga.txt

diff --git a/Documentation/devicetree/bindings/fpga/xlnx,afi-fpga.txt 
b/Documentation/devicetree/bindings/fpga/xlnx,afi-fpga.txt
new file mode 100644
index 000..9006e72
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/xlnx,afi-fpga.txt
@@ -0,0 +1,67 @@
+Xilinx ZynqMp AFI interface Manager
+
+The Zynq UltraScale+ MPSoC Processing System core provides access from PL
+masters to PS internal peripherals, and memory through AXI FIFO interface
+(AFI) interfaces.
+
+Required properties:
+-compatible:   Should contain "xlnx,afi-fpga"
+-config-afi:   Pairs of  
+
+The possible values of regid and values are
+ regid:Regids of the register to be written possible values
+   0- AFIFM0_RDCTRL
+   1- AFIFM0_WRCTRL
+   2- AFIFM1_RDCTRL
+   3- AFIFM1_WRCTRL
+   4- AFIFM2_RDCTRL
+   5- AFIFM2_WRCTRL
+   6- AFIFM3_RDCTRL
+   7- AFIFM3_WRCTRL
+   8- AFIFM4_RDCTRL
+   9- AFIFM4_WRCTRL
+   10- AFIFM5_RDCTRL
+   11- AFIFM5_WRCTRL
+   12- AFIFM6_RDCTRL
+   13- AFIFM6_WRCTRL
+   14- AFIFS
+   15- AFIFS_SS2
+- value:   Array of values to be written.
+   for FM0_RDCTRL(0) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM0_WRCTRL(1) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM1_RDCTRL(2) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM1_WRCTRL(3) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM2_RDCTRL(4) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM2_WRCTRL(5) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM3_RDCTRL(6) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM3_WRCTRL(7) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM4_RDCTRL(8) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM4_WRCTRL(9) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM5_RDCTRL(10) the valid values-fabric width   2: 32-bit,1 
: 64-bit ,0: 128-bit enabled
+   for FM5_WRCTRL(11) the valid values-fabric width   2: 32-bit,1 
: 64-bit ,0: 128-bit enabled
+   for FM6_RDCTRL(12) the valid values-fabric width   2: 32-bit,1 
: 64-bit ,0: 128-bit enabled
+   for FM6_WRCTRL(13) the valid values-fabric width   2: 32-bit,1 
: 64-bit ,0: 128-bit enabled
+   for AFI_FA(14)
+   dw_ss1_sel  bits (11:10)
+   dw_ss0_sel  bits (9:8)
+   0x0: 32-bit AXI data width),
+   0x1: 64-bit AXI data width,
+   0x2: 128-bit AXI data
+   All other bits are 0 write ignored.
+
+   for AFI_FA(15)  selects for ss2AXI data width valid values
+   0x000: 32-bit AXI data width),
+   0x100: 64-bit AXI data width,
+   0x200: 128-bit AXI data
+
+Example:
+firmware {
+   zynqmp_firmware: zynqmp-firmware {
+   compatible = "xlnx,zynqmp-firmware";
+   method = "smc";
+   afi0: afi0 {
+   compatible = "xlnx,afi-fpga";
+   config-afi = <0 2>, <1 1>, <2 1>;
+   };
+   };
+};
-- 
2.7.4



[PATCH 3/9] dt-bindings: reset: Add bindings for ZynqMP reset driver

2018-11-16 Thread Jolly Shah
From: Nava kishore Manne 

Add documentation to describe Xilinx ZynqMP reset driver
bindings.

Signed-off-by: Nava kishore Manne 
Signed-off-by: Jolly Shah 
---
 .../bindings/reset/xlnx,zynqmp-reset.txt   | 148 +
 1 file changed, 148 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt

diff --git a/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt 
b/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt
new file mode 100644
index 000..e9c1af8
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt
@@ -0,0 +1,148 @@
+--
+ =  Zynq UltraScale+ MPSoC reset driver binding =
+--
+The Zynq UltraScale+ MPSoC has several different resets.
+
+See Chapter 36 of the Zynq UltraScale+ MPSoC TRM (UG) for more information
+about zynqmp resets.
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required Properties:
+- #reset-cells:Specifies the number of cells needed to encode reset
+   line, should be 1
+
+Reset outputs:
+   0   :PCIE config reset.
+   1   :PCIE bridge block level reset (AXI interface).
+   2   :PCIE control block level,reset.
+   3   :Display Port block level reset (includes DPDMA).
+   4   :FPD WDT reset.
+   5   :AF_FM5 block level reset.
+   6   :AF_FM4 block level reset.
+   7   :AF_FM3 block level reset.
+   8   :AF_FM2 block level reset.
+   9   :AF_FM1 block level reset.
+   10  :AF_FM0 block level reset.
+   11  :GDMA block level reset.
+   12  :Pixel Processor (GPU_PP1) block level reset.
+   13  :Pixel Processor (GPU_PP0) block level reset.
+   14  :GPU block level reset.
+   15  :GT block level reset.
+   16  :Sata block level reset.
+   17  :ACPU3 power on reset.
+   18  :ACPU2 power on reset.
+   19  :ACPU1 power on reset.
+   20  :ACPU0 power on reset.
+   21  :APU L2 reset.
+   22  :ACPU3 reset.
+   23  :ACPU2 reset.
+   24  :ACPU1 reset.
+   25  :ACPU0 reset.
+   26  :DDR block level reset inside of the DDR Sub System.
+   27  :APM block level reset inside of the DDR Sub System.
+   28  :soft reset.
+   29  :GEM 0 reset.
+   30  :GEM 1 reset.
+   31  :GEM 2 reset.
+   32  :GEM 3 reset.
+   33  :qspi reset.
+   34  :uart0 reset.
+   35  :uart1 reset.
+   36  :spi0 reset.
+   37  :spi1 reset.
+   38  :sdio0 reset.
+   39  :sdio1 reset.
+   40  :can0 reset.
+   41  :can1 reset.
+   42  :i2c0 reset.
+   43  :i2c1 reset.
+   44  :ttc0 reset.
+   45  :ttc1 reset.
+   46  :ttc2 reset.
+   47  :ttc3 reset.
+   48  :swdt reset.
+   49  :nand reset.
+   50  :adma reset.
+   51  :gpio reset.
+   52  :iou_cc reset.
+   53  :timestamp reset.
+   54  :rpu_r50 reset.
+   55  :rpu r51 reset.
+   56  :rpu_amba reset.
+   57  :ocm reset.
+   58  :rpu_pge reset.
+   59  :usb0_core reset.
+   60  :usb1_core reset.
+   61  :usb0_hiber reset.
+   62  :usb1_hiber reset.
+   63  :usb0_apb reset.
+   64  :usb1_apb reset.
+   65  :ipi reset.
+   66  :apm reset.
+   67  :rtc reset.
+   68  :sysmon reset.
+   69  :afi_fm6 reset.
+   70  :lpd_swdt reset.
+   71  :fpd_reset.
+   72  :rpu_dbg1 reset.
+   73  :rpu_dbg0 reset.
+   74  :dbg_lpd reset.
+   75  :dbg_fpd reset.
+   76  :apll reset.
+   77  :dpll reset.
+   78  :vpll reset.
+   79  :iopll reset.
+   80  :rpll reset.
+   81  :gpio_pl_0 reset.
+   82  :gpio_pl_1 reset.
+   83  :gpio_pl_2 reset.
+   84  :gpio_pl_3 reset.
+   85  :gpio_pl_4 reset.
+   86  :gpio_pl_5 reset.
+   87  :gpio_pl_6 reset.
+   88  :gpio_pl_7 reset.
+   89  :gpio_pl_8 reset.
+   90  :gpio_pl_9 reset.
+   91  :gpio_pl_10 reset.
+   92  :gpio_pl_11 reset.
+   93  :gpio_pl_12 reset.
+   94  :gpio_pl_13 reset.
+   95  :gpio_pl_14 reset.
+   96  :gpio_pl_15 reset.
+   97  :gpio_pl_16 reset.
+   98  :gpio_pl_17 reset.
+   99  :gpio_pl_18 reset.
+   100 :gpio_pl_19 reset.
+   101 :gpio_pl_20 reset.
+   102 :gpio_pl_21 reset.
+   103 :gpio_pl_22 reset.
+   104 :gpio_pl_23 reset.
+   105 :gpio_pl_24 reset.
+   106 :gpio_pl_25 reset.
+   107 :gpio_pl_26 reset.
+   108 :gpio_pl_27 reset.
+   109 :gpio_pl_28 reset.
+   110 :gpio_pl_29 reset.
+   111 :gpio_pl_30 reset.
+   112 :gpio_pl_31 reset.
+   113 :rpu_ls reset.
+   114 :ps_only reset.
+   115 :pl reset.
+   116 :ps_pl0 reset
+   117 :ps_pl1 reset
+   118 :ps_pl2 reset
+   119 :ps_pl3 reset
+
+---
+Example
+---
+
+firmware {
+   

[PATCH 5/9] dt-bindings: pinctrl: Add ZynqMP pin controller bindings

2018-11-16 Thread Jolly Shah
From: Rajan Vaja 

Add documentation to describe Xilinx ZynqMP pin controller
bindings.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 .../bindings/pinctrl/xlnx,zynqmp-pinctrl.txt   | 272 +
 1 file changed, 272 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.txt

diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.txt
new file mode 100644
index 000..0d54b40
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.txt
@@ -0,0 +1,272 @@
+   Binding for Xilinx ZynqMP Pinctrl
+
+Required properties:
+ZynqMP pin control driver is populated by ZynqMP firmware and doesn't need
+any separate property.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+ZynqMP's pin configuration nodes act as a container for an arbitrary number of
+subnodes. Each of these subnodes represents some desired configuration for a
+pin, a group, or a list of pins or groups. This configuration can include the
+mux function to select on those pin(s)/group(s), and various pin configuration
+parameters, such as pull-up, slew rate, etc.
+
+Each configuration node can consist of multiple nodes describing the pinmux and
+pinconf options. Those nodes can be pinmux nodes or pinconf nodes.
+
+The name of each subnode is not important; all subnodes should be enumerated
+and processed purely based on their content.
+
+Required properties for pinmux nodes are:
+ - groups: A list of pinmux groups.
+ - function: The name of a pinmux function to activate for the specified set
+   of groups.
+
+Required properties for configuration nodes:
+One of:
+ - pins: A list of pin names
+ - groups: A list of pinmux groups.
+
+The following generic properties as defined in pinctrl-bindings.txt are valid
+to specify in a pinmux subnode:
+ groups, function
+
+The following generic properties as defined in pinctrl-bindings.txt are valid
+to specify in a pinconf subnode:
+ groups, pins, bias-disable, bias-pull-up, bias-pull-down, slew-rate
+
+ Valid arguments for 'slew-rate' are 'SLEW_RATE_SLOW' and 'SLEW_RATE_FAST' to
+ select between slow and fast respectively.
+
+ Valid values for groups are:
+ ethernet0_0_grp, ethernet1_0_grp, ethernet2_0_grp,
+ ethernet3_0_grp, gemtsu0_0_grp, gemtsu0_1_grp,
+ gemtsu0_2_grp, mdio0_0_grp, mdio1_0_grp,
+ mdio1_1_grp, mdio2_0_grp, mdio3_0_grp,
+ qspi0_0_grp, qspi_ss_0_grp, qspi_fbclk_0_grp,
+ spi0_0_grp, spi0_ss_0_grp, spi0_ss_1_grp,
+ spi0_ss_2_grp, spi0_1_grp, spi0_ss_3_grp,
+ spi0_ss_4_grp, spi0_ss_5_grp, spi0_2_grp,
+ spi0_ss_6_grp, spi0_ss_7_grp, spi0_ss_8_grp,
+ spi0_3_grp, spi0_ss_9_grp, spi0_ss_10_grp,
+ spi0_ss_11_grp, spi0_4_grp, spi0_ss_12_grp,
+ spi0_ss_13_grp, spi0_ss_14_grp, spi0_5_grp,
+ spi0_ss_15_grp, spi0_ss_16_grp, spi0_ss_17_grp,
+ spi1_0_grp, spi1_ss_0_grp, spi1_ss_1_grp,
+ spi1_ss_2_grp, spi1_1_grp, spi1_ss_3_grp,
+ spi1_ss_4_grp, spi1_ss_5_grp, spi1_2_grp,
+ spi1_ss_6_grp, spi1_ss_7_grp, spi1_ss_8_grp,
+ spi1_3_grp, spi1_ss_9_grp, spi1_ss_10_grp,
+ spi1_ss_11_grp, spi1_4_grp, spi1_ss_12_grp,
+ spi1_ss_13_grp, spi1_ss_14_grp, spi1_5_grp,
+ spi1_ss_15_grp, spi1_ss_16_grp, spi1_ss_17_grp,
+ sdio0_0_grp, sdio0_1_grp, sdio0_2_grp,
+ sdio0_3_grp, sdio0_4_grp, sdio0_5_grp,
+ sdio0_6_grp, sdio0_7_grp, sdio0_8_grp,
+ sdio0_9_grp, sdio0_10_grp, sdio0_11_grp,
+ sdio0_12_grp, sdio0_13_grp, sdio0_14_grp,
+ sdio0_15_grp, sdio0_16_grp, sdio0_17_grp,
+ sdio0_18_grp, sdio0_19_grp, sdio0_20_grp,
+ sdio0_21_grp, sdio0_22_grp, sdio0_23_grp,
+ sdio0_24_grp, sdio0_25_grp, sdio0_26_grp,
+ sdio0_27_grp, sdio0_28_grp, sdio0_29_grp,
+ sdio0_30_grp, sdio0_31_grp, sdio0_32_grp,
+ sdio0_pc_0_grp, sdio0_cd_0_grp, sdio0_wp_0_grp,
+ sdio0_pc_1_grp, sdio0_cd_1_grp, sdio0_wp_1_grp,
+ sdio0_pc_2_grp, sdio0_cd_2_grp, sdio0_wp_2_grp,
+ sdio1_0_grp, sdio1_1_grp, sdio1_2_grp,
+ sdio1_3_grp, sdio1_4_grp, sdio1_5_grp,
+ sdio1_6_grp, sdio1_7_grp, sdio1_8_grp,
+ sdio1_9_grp, sdio1_10_grp, sdio1_11_grp,
+ sdio1_12_grp, sdio1_13_grp, sdio1_14_grp,
+ sdio1_15_grp, sdio1_pc_0_grp, sdio1_cd_0_grp,
+ sdio1_wp_0_grp, sdio1_pc_1_grp, sdio1_cd_1_grp,
+ sdio1_wp_1_grp, nand0_0_grp, nand0_ce_0_grp,
+ nand0_rb_0_grp, nand0_dqs_0_grp, nand0_ce_1_grp,
+ nand0_rb_1_grp, nand0_dqs_1_grp, can0_0_grp,
+ can0_1_grp, can0_2_grp, can0_3_grp,
+ can0_4_grp, can0_5_grp, can0_6_grp,
+ can0_7_grp, can0_8_grp, can0_9_grp,
+ can0_10_grp, can0_11_grp, can0_12_grp,
+ can0_13_grp, can0_14_grp, can0_15_grp,
+ can0_16_grp, can0_17_grp, can0_18_grp,
+ can1_0_grp, can1_1_grp, can1_2_grp,
+ can1_3_grp, can1_4_grp, can1_5_grp,
+ can1_6_grp, can1_7_grp, can1_8_grp,
+ can1_9_grp, can1_10_grp, can1_11_grp,
+ can1_12_grp, can1_13_grp, can1_14_grp,
+ can1_15_grp, can1_16_grp, can1_17_grp,
+ can1_18_grp, can1_19_grp, uart0_0_grp,
+ uart0_1_grp, 

[PATCH 2/9] dt-bindings: soc: Add ZynqMP PM bindings

2018-11-16 Thread Jolly Shah
From: Rajan Vaja 

Add documentation to describe Xilinx ZynqMP power management
bindings.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 .../bindings/power/reset/xlnx,zynqmp-power.txt | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt

diff --git 
a/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt 
b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt
new file mode 100644
index 000..d366f1e
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt
@@ -0,0 +1,25 @@
+
+Device Tree Bindings for the Xilinx Zynq MPSoC Power Management
+
+The zynqmp-power node describes the power management configurations.
+It will control remote suspend/shutdown interfaces.
+
+Required properties:
+ - compatible: Must contain:   "xlnx,zynqmp-power"
+ - interrupts: Interrupt specifier
+
+---
+Example
+---
+
+firmware {
+   zynqmp_firmware: zynqmp-firmware {
+   compatible = "xlnx,zynqmp-firmware";
+   method = "smc";
+
+   zynqmp_power: zynqmp-power {
+   compatible = "xlnx,zynqmp-power";
+   interrupts = <0 35 4>;
+   };
+   };
+};
-- 
2.7.4



Re: [PATCH] pinctrl: mediatek: Convert to using %pOFn instead of device_node.name

2018-11-16 Thread Sean Wang
On Fri, Nov 16, 2018 at 2:06 PM Rob Herring  wrote:
>
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
>
> Cc: Sean Wang 
> Cc: Linus Walleij 
> Cc: Matthias Brugger 
> Cc: linux-media...@lists.infradead.org
> Cc: linux-g...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Rob Herring 

Acked-by: Sean Wang 

> ---
>  drivers/pinctrl/mediatek/pinctrl-paris.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c 
> b/drivers/pinctrl/mediatek/pinctrl-paris.c
> index d2179028f134..7ff5ffa88198 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-paris.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
> @@ -419,8 +419,8 @@ static int mtk_pctrl_dt_subnode_to_map(struct pinctrl_dev 
> *pctldev,
>
> pins = of_find_property(node, "pinmux", NULL);
> if (!pins) {
> -   dev_err(hw->dev, "missing pins property in node %s .\n",
> -   node->name);
> +   dev_err(hw->dev, "missing pins property in node %pOFn .\n",
> +   node);
> return -EINVAL;
> }
>
> --
> 2.19.1
>


[PATCH 1/2] staging: emxx_udc: Split line and fix eol parenthesis

2018-11-16 Thread Cristian Sicilia
Fix some parenthesis opened at end of line.

Signed-off-by: Cristian Sicilia 
---
 drivers/staging/emxx_udc/emxx_udc.c | 73 ++---
 1 file changed, 36 insertions(+), 37 deletions(-)

diff --git a/drivers/staging/emxx_udc/emxx_udc.c 
b/drivers/staging/emxx_udc/emxx_udc.c
index bf7c5da..26bd77c 100644
--- a/drivers/staging/emxx_udc/emxx_udc.c
+++ b/drivers/staging/emxx_udc/emxx_udc.c
@@ -108,20 +108,20 @@ static void _nbu2ss_dump_register(struct nbu2ss_udc *udc)
 
dev_dbg(>dev, "\n-USB REG-\n");
for (i = 0x0 ; i < USB_BASE_SIZE ; i += 16) {
-   reg_data =   _nbu2ss_readl(
-   (u32 *)IO_ADDRESS(USB_BASE_ADDRESS + i));
+   reg_data = _nbu2ss_readl((u32 *)IO_ADDRESS(USB_BASE_ADDRESS +
+   i));
dev_dbg(>dev, "USB%04x =%08x", i, (int)reg_data);
 
-   reg_data =  _nbu2ss_readl(
-   (u32 *)IO_ADDRESS(USB_BASE_ADDRESS + i + 4));
+   reg_data = _nbu2ss_readl((u32 *)IO_ADDRESS(USB_BASE_ADDRESS +
+   i + 4));
dev_dbg(>dev, " %08x", (int)reg_data);
 
-   reg_data =  _nbu2ss_readl(
-   (u32 *)IO_ADDRESS(USB_BASE_ADDRESS + i + 8));
+   reg_data = _nbu2ss_readl((u32 *)IO_ADDRESS(USB_BASE_ADDRESS +
+   i + 8));
dev_dbg(>dev, " %08x", (int)reg_data);
 
-   reg_data =  _nbu2ss_readl(
-   (u32 *)IO_ADDRESS(USB_BASE_ADDRESS + i + 12));
+   reg_data = _nbu2ss_readl((u32 *)IO_ADDRESS(USB_BASE_ADDRESS +
+   i + 12));
dev_dbg(>dev, " %08x\n", (int)reg_data);
}
 
@@ -473,22 +473,23 @@ static void _nbu2ss_dma_map_single(
if (req->unaligned) {
req->req.dma = ep->phys_buf;
} else {
-   req->req.dma = dma_map_single(
-   udc->gadget.dev.parent,
-   req->req.buf,
-   req->req.length,
-   (direct == USB_DIR_IN)
-   ? DMA_TO_DEVICE : DMA_FROM_DEVICE);
+   req->req.dma =
+   dma_map_single(udc->gadget.dev.parent,
+  req->req.buf,
+  req->req.length,
+  (direct == USB_DIR_IN) ?
+   DMA_TO_DEVICE :
+   DMA_FROM_DEVICE);
}
req->mapped = 1;
} else {
if (!req->unaligned)
-   dma_sync_single_for_device(
-   udc->gadget.dev.parent,
-   req->req.dma,
-   req->req.length,
-   (direct == USB_DIR_IN)
-   ? DMA_TO_DEVICE : DMA_FROM_DEVICE);
+   dma_sync_single_for_device(udc->gadget.dev.parent,
+  req->req.dma,
+  req->req.length,
+  (direct == USB_DIR_IN)
+   ? DMA_TO_DEVICE :
+   DMA_FROM_DEVICE);
 
req->mapped = 0;
}
@@ -975,8 +976,8 @@ static int _nbu2ss_epn_out_transfer(
 
/*-*/
/* Receive Length */
-   i_recv_length
-   = _nbu2ss_readl(>EP_REGS[num].EP_LEN_DCNT) & EPN_LDATA;
+   i_recv_length =
+   _nbu2ss_readl(>EP_REGS[num].EP_LEN_DCNT) & EPN_LDATA;
 
if (i_recv_length != 0) {
result = _nbu2ss_epn_out_data(udc, ep, req, i_recv_length);
@@ -1115,10 +1116,9 @@ static int _nbu2ss_epn_in_pio(
i_word_length = length / sizeof(u32);
if (i_word_length > 0) {
for (i = 0; i < i_word_length; i++) {
-   _nbu2ss_writel(
-   >EP_REGS[ep->epnum - 1].EP_WRITE
-   , p_buf_32->dw
-   );
+   _nbu2ss_writel(>EP_REGS[ep->epnum -
+ 1].EP_WRITE,
+  p_buf_32->dw);
 
p_buf_32++;
}
@@ -1472,13 +1472,11 @@ static inline int _nbu2ss_req_feature(struct nbu2ss_udc 
*udc, bool bset)
if (0x == (wIndex & 0xFF70)) {
if (selector == 

[PATCH 2/2] staging: emxx_udc: Fixing function naming

2018-11-16 Thread Cristian Sicilia
Fix function naming and parenthesis.

Signed-off-by: Cristian Sicilia 
---
 drivers/staging/emxx_udc/emxx_udc.c | 212 
 1 file changed, 70 insertions(+), 142 deletions(-)

diff --git a/drivers/staging/emxx_udc/emxx_udc.c 
b/drivers/staging/emxx_udc/emxx_udc.c
index 26bd77c..f391abe 100644
--- a/drivers/staging/emxx_udc/emxx_udc.c
+++ b/drivers/staging/emxx_udc/emxx_udc.c
@@ -163,11 +163,8 @@ static void _nbu2ss_ep0_complete(struct usb_ep *_ep, 
struct usb_request *_req)
 
 /*-*/
 /* Initialization usb_request */
-static void _nbu2ss_create_ep0_packet(
-   struct nbu2ss_udc *udc,
-   void *p_buf,
-   unsigned length
-)
+static void _nbu2ss_create_ep0_packet(struct nbu2ss_udc *udc,
+ void *p_buf, unsigned int length)
 {
udc->ep0_req.req.buf= p_buf;
udc->ep0_req.req.length = length;
@@ -419,12 +416,8 @@ static void _nbu2ss_ep_dma_abort(struct nbu2ss_udc *udc, 
struct nbu2ss_ep *ep)
 
 /*-*/
 /* Start IN Transfer */
-static void _nbu2ss_ep_in_end(
-   struct nbu2ss_udc *udc,
-   u32 epnum,
-   u32 data32,
-   u32 length
-)
+static void _nbu2ss_ep_in_end(struct nbu2ss_udc *udc,
+ u32 epnum, u32 data32, u32 length)
 {
u32 data;
u32 num;
@@ -462,12 +455,9 @@ static void _nbu2ss_ep_in_end(
 
 #ifdef USE_DMA
 /*-*/
-static void _nbu2ss_dma_map_single(
-   struct nbu2ss_udc *udc,
-   struct nbu2ss_ep *ep,
-   struct nbu2ss_req *req,
-   u8  direct
-)
+static void _nbu2ss_dma_map_single(struct nbu2ss_udc *udc,
+  struct nbu2ss_ep *ep,
+  struct nbu2ss_req *req, u8 direct)
 {
if (req->req.dma == DMA_ADDR_INVALID) {
if (req->unaligned) {
@@ -496,12 +486,9 @@ static void _nbu2ss_dma_map_single(
 }
 
 /*-*/
-static void _nbu2ss_dma_unmap_single(
-   struct nbu2ss_udc *udc,
-   struct nbu2ss_ep *ep,
-   struct nbu2ss_req *req,
-   u8  direct
-)
+static void _nbu2ss_dma_unmap_single(struct nbu2ss_udc *udc,
+struct nbu2ss_ep *ep,
+struct nbu2ss_req *req, u8 direct)
 {
u8  data[4];
u8  *p;
@@ -672,10 +659,8 @@ static int EP0_receive_NULL(struct nbu2ss_udc *udc, bool 
pid_flag)
 }
 
 /*-*/
-static int _nbu2ss_ep0_in_transfer(
-   struct nbu2ss_udc *udc,
-   struct nbu2ss_req *req
-)
+static int _nbu2ss_ep0_in_transfer(struct nbu2ss_udc *udc,
+  struct nbu2ss_req *req)
 {
u8  *p_buffer;  /* IN Data Buffer */
u32 data;
@@ -729,10 +714,8 @@ static int _nbu2ss_ep0_in_transfer(
 }
 
 /*-*/
-static int _nbu2ss_ep0_out_transfer(
-   struct nbu2ss_udc *udc,
-   struct nbu2ss_req *req
-)
+static int _nbu2ss_ep0_out_transfer(struct nbu2ss_udc *udc,
+   struct nbu2ss_req *req)
 {
u8  *p_buffer;
u32 i_remain_size;
@@ -806,12 +789,8 @@ static int _nbu2ss_ep0_out_transfer(
 }
 
 /*-*/
-static int _nbu2ss_out_dma(
-   struct nbu2ss_udc *udc,
-   struct nbu2ss_req *req,
-   u32 num,
-   u32 length
-)
+static int _nbu2ss_out_dma(struct nbu2ss_udc *udc, struct nbu2ss_req *req,
+  u32 num, u32 length)
 {
dma_addr_t  p_buffer;
u32 mpkt;
@@ -869,12 +848,8 @@ static int _nbu2ss_out_dma(
 }
 
 /*-*/
-static int _nbu2ss_epn_out_pio(
-   struct nbu2ss_udc *udc,
-   struct nbu2ss_ep *ep,
-   struct nbu2ss_req *req,
-   u32 length
-)
+static int _nbu2ss_epn_out_pio(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
+  struct nbu2ss_req *req, u32 length)
 {
u8  *p_buffer;
u32 i;
@@ -928,12 +903,8 @@ static int _nbu2ss_epn_out_pio(
 }
 
 /*-*/
-static int _nbu2ss_epn_out_data(
-   struct nbu2ss_udc *udc,
-   struct nbu2ss_ep *ep,
-   struct nbu2ss_req *req,
-   u32 data_size
-)
+static int _nbu2ss_epn_out_data(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
+

[PATCH 0/2] Split line, fix eol parenthesis and fix functions

2018-11-16 Thread Cristian Sicilia
Patch 1: therea are some trying to split the line, but not shure about
 the result, like

1)
reg_data = _nbu2ss_readl((u32 *)IO_ADDRESS(USB_BASE_ADDRESS +
   i));

2) 
regdata = _nbu2ss_readl(>EP_REGS[ep->epnum -
   1].EP_STATUS);
 

The second patch try to fix the function, removing the parenthesis at
end of line, and add new line only if needed (over 80 chars)

Cristian Sicilia (2):
  staging: emxx_udc: Split line and fix eol parenthesis
  staging: emxx_udc: Fixing function naming

 drivers/staging/emxx_udc/emxx_udc.c | 285 ++--
 1 file changed, 106 insertions(+), 179 deletions(-)

-- 
2.7.4



Re: UBSAN: Undefined behaviour in mm/page_alloc.c

2018-11-16 Thread Dmitry Vyukov
On Tue, Nov 13, 2018 at 3:29 PM, Andrew Morton
 wrote:
> On Tue, 13 Nov 2018 10:43:05 +0100 Michal Hocko  wrote:
>
>> From: Michal Hocko 
>> Date: Fri, 9 Nov 2018 09:35:29 +0100
>> Subject: [PATCH] mm, page_alloc: check for max order in hot path
>>
>> Konstantin has noticed that kvmalloc might trigger the following warning
>> [Thu Nov  1 08:43:56 2018] WARNING: CPU: 0 PID: 6676 at mm/vmstat.c:986 
>> __fragmentation_index+0x54/0x60
>
> um, wait...
>
>> [...]
>> [Thu Nov  1 08:43:56 2018] Call Trace:
>> [Thu Nov  1 08:43:56 2018]  fragmentation_index+0x76/0x90
>> [Thu Nov  1 08:43:56 2018]  compaction_suitable+0x4f/0xf0
>> [Thu Nov  1 08:43:56 2018]  shrink_node+0x295/0x310
>> [Thu Nov  1 08:43:56 2018]  node_reclaim+0x205/0x250
>> [Thu Nov  1 08:43:56 2018]  get_page_from_freelist+0x649/0xad0
>> [Thu Nov  1 08:43:56 2018]  ? get_page_from_freelist+0x2d4/0xad0
>> [Thu Nov  1 08:43:56 2018]  ? release_sock+0x19/0x90
>> [Thu Nov  1 08:43:56 2018]  ? do_ipv6_setsockopt.isra.5+0x10da/0x1290
>> [Thu Nov  1 08:43:56 2018]  __alloc_pages_nodemask+0x12a/0x2a0
>> [Thu Nov  1 08:43:56 2018]  kmalloc_large_node+0x47/0x90
>> [Thu Nov  1 08:43:56 2018]  __kmalloc_node+0x22b/0x2e0
>> [Thu Nov  1 08:43:56 2018]  kvmalloc_node+0x3e/0x70
>> [Thu Nov  1 08:43:56 2018]  xt_alloc_table_info+0x3a/0x80 [x_tables]
>> [Thu Nov  1 08:43:56 2018]  do_ip6t_set_ctl+0xcd/0x1c0 [ip6_tables]
>> [Thu Nov  1 08:43:56 2018]  nf_setsockopt+0x44/0x60
>> [Thu Nov  1 08:43:56 2018]  SyS_setsockopt+0x6f/0xc0
>> [Thu Nov  1 08:43:56 2018]  do_syscall_64+0x67/0x120
>> [Thu Nov  1 08:43:56 2018]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
>
> If kvalloc_node() is going to call kmalloc() without checking for a
> huge allocation request then surely it should set __GFP_NOWARN.


kmalloc won't warn about large allocations after "mm: don't warn about
large allocations for slab":
https://lkml.org/lkml/2018/9/27/1156
It will just return NULL. That was already the case for slub.


> And it
> shouldn't bother at all if size > KMALLOC_MAX_SIZE, surely?  So
> something like
>
> --- a/mm/util.c~a
> +++ a/mm/util.c
> @@ -393,11 +393,16 @@ void *kvmalloc_node(size_t size, gfp_t f
> void *ret;
>
> /*
> -* vmalloc uses GFP_KERNEL for some internal allocations (e.g page 
> tables)
> -* so the given set of flags has to be compatible.
> +* vmalloc uses GFP_KERNEL for some internal allocations (e.g page
> +* tables) so the given set of flags has to be compatible.
>  */
> -   if ((flags & GFP_KERNEL) != GFP_KERNEL)
> +   if ((flags & GFP_KERNEL) != GFP_KERNEL) {
> +   if (size > KMALLOC_MAX_SIZE)
> +   return NULL;
> +   if (size > PAGE_SIZE)
> +   flags |= __GFP_NOWARN;
> return kmalloc_node(size, flags, node);
> +   }
>
> /*
>  * We want to attempt a large physically contiguous block first 
> because
>
>
>> the problem is that we only check for an out of bound order in the slow
>> path and the node reclaim might happen from the fast path already. This
>> is fixable by making sure that kvmalloc doesn't ever use kmalloc for
>> requests that are larger than KMALLOC_MAX_SIZE but this also shows that
>> the code is rather fragile. A recent UBSAN report just underlines that
>> by the following report
>>
>>  UBSAN: Undefined behaviour in mm/page_alloc.c:3117:19
>>  shift exponent 51 is too large for 32-bit type 'int'
>>  CPU: 0 PID: 6520 Comm: syz-executor1 Not tainted 4.19.0-rc2 #1
>>  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>  Call Trace:
>>   __dump_stack lib/dump_stack.c:77 [inline]
>>   dump_stack+0xd2/0x148 lib/dump_stack.c:113
>>   ubsan_epilogue+0x12/0x94 lib/ubsan.c:159
>>   __ubsan_handle_shift_out_of_bounds+0x2b6/0x30b lib/ubsan.c:425
>>   __zone_watermark_ok+0x2c7/0x400 mm/page_alloc.c:3117
>>   zone_watermark_fast mm/page_alloc.c:3216 [inline]
>>   get_page_from_freelist+0xc49/0x44c0 mm/page_alloc.c:3300
>>   __alloc_pages_nodemask+0x21e/0x640 mm/page_alloc.c:4370
>>   alloc_pages_current+0xcc/0x210 mm/mempolicy.c:2093
>>   alloc_pages include/linux/gfp.h:509 [inline]
>>   __get_free_pages+0x12/0x60 mm/page_alloc.c:4414
>>   dma_mem_alloc+0x36/0x50 arch/x86/include/asm/floppy.h:156
>>   raw_cmd_copyin drivers/block/floppy.c:3159 [inline]
>>   raw_cmd_ioctl drivers/block/floppy.c:3206 [inline]
>>   fd_locked_ioctl+0xa00/0x2c10 drivers/block/floppy.c:3544
>>   fd_ioctl+0x40/0x60 drivers/block/floppy.c:3571
>>   __blkdev_driver_ioctl block/ioctl.c:303 [inline]
>>   blkdev_ioctl+0xb3c/0x1a30 block/ioctl.c:601
>>   block_ioctl+0x105/0x150 fs/block_dev.c:1883
>>   vfs_ioctl fs/ioctl.c:46 [inline]
>>   do_vfs_ioctl+0x1c0/0x1150 fs/ioctl.c:687
>>   ksys_ioctl+0x9e/0xb0 fs/ioctl.c:702
>>   __do_sys_ioctl fs/ioctl.c:709 [inline]
>>   __se_sys_ioctl fs/ioctl.c:707 [inline]
>>   __x64_sys_ioctl+0x7e/0xc0 fs/ioctl.c:707
>>   do_syscall_64+0xc4/0x510 arch/x86/entry/common.c:290

Re: [PATCH v17 07/23] x86/mm: x86/sgx: Add new 'PF_SGX' page fault error code bit

2018-11-16 Thread Dave Hansen
On 11/15/18 5:01 PM, Jarkko Sakkinen wrote:
> The SGX bit is set in the #PF error code if and only if the fault is
> detected by the Enclave Page Cache Map (EPCM), a hardware-managed
> table that enforces the paging permissions defined by the enclave,
> e.g. to prevent the kernel from changing the permissions of an
> enclave's page(s).

This should probably also mention that, despite being a page fault,
X86_PF_SGX has nothing to do with paging itself.


Re: [PATCH v17 06/23] x86/cpu/intel: Detect SGX support and update caps appropriately

2018-11-16 Thread Dave Hansen
On 11/15/18 5:01 PM, Jarkko Sakkinen wrote:
> +static void detect_sgx(struct cpuinfo_x86 *c)
> +{
> + unsigned long long fc;
> +
> + rdmsrl(MSR_IA32_FEATURE_CONTROL, fc);
> + if (!(fc & FEATURE_CONTROL_LOCKED)) {
> + pr_err_once("sgx: IA32_FEATURE_CONTROL MSR is not locked\n");
> + goto out_unsupported;
> + }

This needs a check against the config option somewhere so the compiler
can toss it in its entirety if SGX is config'd out.


Re: [PATCH v17 03/23] x86/cpufeatures: Add SGX sub-features (as Linux-defined bits)

2018-11-16 Thread Dave Hansen
On 11/15/18 5:01 PM, Jarkko Sakkinen wrote:
> +#define X86_FEATURE_SGX1 ( 8*32+ 0) /* SGX1 leaf functions */
> +#define X86_FEATURE_SGX2 ( 8*32+ 1) /* SGX2 leaf functions */

Is there a reason these are not (all) tied to CONFIG_INTEL_SGX via:

arch/x86/include/asm/disabled-features.h

?


Re: [PATCH bpf] bpf: allocate local storage buffers using GFP_ATOMIC

2018-11-16 Thread Y Song
On Wed, Nov 14, 2018 at 6:01 PM Roman Gushchin  wrote:
>
> Naresh reported an issue with the non-atomic memory allocation of
> cgroup local storage buffers:
>
> [   73.047526] BUG: sleeping function called from invalid context at
> /srv/oe/build/tmp-rpb-glibc/work-shared/intel-corei7-64/kernel-source/mm/slab.h:421
> [   73.060915] in_atomic(): 1, irqs_disabled(): 0, pid: 3157, name: 
> test_cgroup_sto
> [   73.068342] INFO: lockdep is turned off.
> [   73.072293] CPU: 2 PID: 3157 Comm: test_cgroup_sto Not tainted
> 4.20.0-rc2-next-20181113 #1
> [   73.080548] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
> 2.0b 07/27/2017
> [   73.088018] Call Trace:
> [   73.090463]  dump_stack+0x70/0xa5
> [   73.093783]  ___might_sleep+0x152/0x240
> [   73.097619]  __might_sleep+0x4a/0x80
> [   73.101191]  __kmalloc_node+0x1cf/0x2f0
> [   73.105031]  ? cgroup_storage_update_elem+0x46/0x90
> [   73.109909]  cgroup_storage_update_elem+0x46/0x90
>
> cgroup_storage_update_elem() (as well as other update map update
> callbacks) is called with disabled preemption, so GFP_ATOMIC
> allocation should be used: e.g. alloc_htab_elem() in hashtab.c.
>
> Reported-by: Naresh Kamboju 
> Tested-by: Naresh Kamboju 
> Signed-off-by: Roman Gushchin 
> Cc: Alexei Starovoitov 
> Cc: Daniel Borkmann 

Acked-by: Yonghong Song 

> ---
>  kernel/bpf/local_storage.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)


[PATCH v5] x86/fsgsbase/64: Fix the base write helper functions

2018-11-16 Thread Chang S. Bae
The helper functions that purport to write the base should just write it
only. It shouldn't have magic optimizations to change the index.

Make the index explicitly changed from the caller, instead of including
the code in the helpers.

Subsequently, the task write helpers do not handle for the current task
anymore. The range check for a base value is also factored out, to
minimize code redundancy from the caller.

v2: Fix further on the task write functions. Revert the changes on the
task read helpers.

v3: Fix putreg(). Edit the changelog.

v4: Update the task write helper functions and do_arch_prctl_64(). Fix
the comment in putreg().

v5: Fix preempt_disable() calls in do_arch_prctl_64()

Suggested-by: Andy Lutomirski 
Signed-off-by: Chang S. Bae 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: H. Peter Anvin 
Cc: Andi Kleen 
Cc: Dave Hansen 
---
 arch/x86/include/asm/fsgsbase.h | 15 --
 arch/x86/kernel/process_64.c| 86 -
 arch/x86/kernel/ptrace.c|  9 ++--
 3 files changed, 58 insertions(+), 52 deletions(-)

diff --git a/arch/x86/include/asm/fsgsbase.h b/arch/x86/include/asm/fsgsbase.h
index eb377b6e9eed..bca4c743de77 100644
--- a/arch/x86/include/asm/fsgsbase.h
+++ b/arch/x86/include/asm/fsgsbase.h
@@ -16,8 +16,8 @@
  */
 extern unsigned long x86_fsbase_read_task(struct task_struct *task);
 extern unsigned long x86_gsbase_read_task(struct task_struct *task);
-extern int x86_fsbase_write_task(struct task_struct *task, unsigned long 
fsbase);
-extern int x86_gsbase_write_task(struct task_struct *task, unsigned long 
gsbase);
+extern void x86_fsbase_write_task(struct task_struct *task, unsigned long 
fsbase);
+extern void x86_gsbase_write_task(struct task_struct *task, unsigned long 
gsbase);
 
 /* Helper functions for reading/writing FS/GS base */
 
@@ -39,8 +39,15 @@ static inline unsigned long 
x86_gsbase_read_cpu_inactive(void)
return gsbase;
 }
 
-extern void x86_fsbase_write_cpu(unsigned long fsbase);
-extern void x86_gsbase_write_cpu_inactive(unsigned long gsbase);
+static inline void x86_fsbase_write_cpu(unsigned long fsbase)
+{
+   wrmsrl(MSR_FS_BASE, fsbase);
+}
+
+static inline void x86_gsbase_write_cpu_inactive(unsigned long gsbase)
+{
+   wrmsrl(MSR_KERNEL_GS_BASE, gsbase);
+}
 
 #endif /* CONFIG_X86_64 */
 
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 31b4755369f0..e2c3dbe68d69 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -337,24 +337,6 @@ static unsigned long x86_fsgsbase_read_task(struct 
task_struct *task,
return base;
 }
 
-void x86_fsbase_write_cpu(unsigned long fsbase)
-{
-   /*
-* Set the selector to 0 as a notion, that the segment base is
-* overwritten, which will be checked for skipping the segment load
-* during context switch.
-*/
-   loadseg(FS, 0);
-   wrmsrl(MSR_FS_BASE, fsbase);
-}
-
-void x86_gsbase_write_cpu_inactive(unsigned long gsbase)
-{
-   /* Set the selector to 0 for the same reason as %fs above. */
-   loadseg(GS, 0);
-   wrmsrl(MSR_KERNEL_GS_BASE, gsbase);
-}
-
 unsigned long x86_fsbase_read_task(struct task_struct *task)
 {
unsigned long fsbase;
@@ -383,38 +365,18 @@ unsigned long x86_gsbase_read_task(struct task_struct 
*task)
return gsbase;
 }
 
-int x86_fsbase_write_task(struct task_struct *task, unsigned long fsbase)
+void x86_fsbase_write_task(struct task_struct *task, unsigned long fsbase)
 {
-   /*
-* Not strictly needed for %fs, but do it for symmetry
-* with %gs
-*/
-   if (unlikely(fsbase >= TASK_SIZE_MAX))
-   return -EPERM;
+   WARN_ON_ONCE(task == current);
 
-   preempt_disable();
task->thread.fsbase = fsbase;
-   if (task == current)
-   x86_fsbase_write_cpu(fsbase);
-   task->thread.fsindex = 0;
-   preempt_enable();
-
-   return 0;
 }
 
-int x86_gsbase_write_task(struct task_struct *task, unsigned long gsbase)
+void x86_gsbase_write_task(struct task_struct *task, unsigned long gsbase)
 {
-   if (unlikely(gsbase >= TASK_SIZE_MAX))
-   return -EPERM;
+   WARN_ON_ONCE(task == current);
 
-   preempt_disable();
task->thread.gsbase = gsbase;
-   if (task == current)
-   x86_gsbase_write_cpu_inactive(gsbase);
-   task->thread.gsindex = 0;
-   preempt_enable();
-
-   return 0;
 }
 
 int copy_thread_tls(unsigned long clone_flags, unsigned long sp,
@@ -758,11 +720,47 @@ long do_arch_prctl_64(struct task_struct *task, int 
option, unsigned long arg2)
 
switch (option) {
case ARCH_SET_GS: {
-   ret = x86_gsbase_write_task(task, arg2);
+   if (unlikely(arg2 >= TASK_SIZE_MAX))
+   return -EPERM;
+
+   preempt_disable();
+   /*
+* ARCH_SET_GS has always overwritten the index
+* and the base. Zero 

Re: [PATCH v4] x86/fsgsbase/64: Fix the base write helper functions

2018-11-16 Thread Bae, Chang Seok
> On Nov 14, 2018, at 13:46, Bae, Chang Seok  wrote:
> 
> int copy_thread_tls(unsigned long clone_flags, unsigned long sp,
> @@ -758,11 +720,45 @@ long do_arch_prctl_64(struct task_struct *task, int 
> option, unsigned long arg2)
> 
>   switch (option) {
>   case ARCH_SET_GS: {
> - ret = x86_gsbase_write_task(task, arg2);
> + preempt_disable();
> + if (unlikely(arg2 >= TASK_SIZE_MAX))
> + return -EPERM;

Sorry, preempt_disabled() should go after this.
Chang


[PATCH] staging: axis-fifo: Split line to stay in 80 characters.

2018-11-16 Thread Cristian Sicilia
The line is split up to stay in 80 characters-

Signed-off-by: Cristian Sicilia 
---
 drivers/staging/axis-fifo/axis-fifo.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/axis-fifo/axis-fifo.c 
b/drivers/staging/axis-fifo/axis-fifo.c
index c18bf31..805437f 100644
--- a/drivers/staging/axis-fifo/axis-fifo.c
+++ b/drivers/staging/axis-fifo/axis-fifo.c
@@ -485,7 +485,8 @@ static ssize_t axis_fifo_write(struct file *f, const char 
__user *buf,
 ioread32(fifo->base_addr + XLLF_TDFV_OFFSET)
>= words_to_write,
 fifo->write_queue_lock,
-(write_timeout >= 0) ? msecs_to_jiffies(write_timeout) 
:
+(write_timeout >= 0) ?
+   msecs_to_jiffies(write_timeout) :
MAX_SCHEDULE_TIMEOUT);
spin_unlock_irq(>write_queue_lock);
 
-- 
2.7.4



Re: [PATCH v2 2/3] dt-bindings: clk: add documentation for the SiFive PRCI driver

2018-11-16 Thread Paul Walmsley

On Wed, 24 Oct 2018, Rob Herring wrote:


On Sat, Oct 20, 2018 at 06:50:23AM -0700, Paul Walmsley wrote:

Add DT binding documentation for the Linux driver for the SiFive
PRCI clock & reset control IP block, as found on the SiFive
FU540 chip.

Cc: Michael Turquette 
Cc: Stephen Boyd 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Palmer Dabbelt 
Cc: Megan Wachs 
Cc: linux-...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-ri...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Paul Walmsley 
Signed-off-by: Paul Walmsley 
---
v2: remove out-of-date example, add documentation for the compatible
string and for the required PCB clock nodes

.../bindings/clock/sifive/fu540-prci.txt  | 43 +++
 1 file changed, 43 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/sifive/fu540-prci.txt

diff --git a/Documentation/devicetree/bindings/clock/sifive/fu540-prci.txt 
b/Documentation/devicetree/bindings/clock/sifive/fu540-prci.txt
new file mode 100644
index ..d7c1e83fa5ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/sifive/fu540-prci.txt
@@ -0,0 +1,43 @@
+SiFive FU540 PRCI bindings
+
+On the FU540 family of SoCs, most system-wide clock and reset integration
+is via the PRCI IP block.
+
+Required properties:
+- compatible: Should be "sifive,-prci".  As of the time this
+  file was written, only one value is supported:
+ "sifive,fu540-c000-prci0"


What happens with this depends on the discussion on the other bindings.


We'll drop the trailing 0 since the SoC identifier prefix should be 
sufficiently precise.



Though here you are inconsistent without a fallback. Of course, I've
never seen a clock controller be the same across SoCs.


As you write, the assumption is that chip integration IP blocks like this 
one are likely to be specific to individual SoCs.


This may not be universally true for SiFive looking into the future, but 
since we don't yet have a clear sense of the extent of exact reuse (i.e. 
chip "families"), am not yet comfortable with advocating something like 
"sifive,prci0" yet, as we do with the sifive-blocks.



+- reg: Should describe the PRCI's register target physical address region
+- clocks: Should point to the hfclk device tree node and the rtcclk
+  device tree node.  The RTC clock here is not a time-of-day clock,
+ but is instead a high-stability clock source for system timers
+ and cycle counters.
+- #clock-cells: Should be <1>
+
+The clock consumer should specify the desired clock via the clock ID
+macros defined in include/linux/clk/sifive-fu540-prci.h.  These macros
+begin with PRCI_CLK_.
+
+The hfclk and rtcclk nodes are required, and represent physical
+crystals or resonators located on the PCB.
+
+Examples:
+
+hfclk: hfclk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <>;
+   clock-output-names = "hfclk";
+};
+rtcclk: rtcclk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <100>;
+   clock-output-names = "rtcclk";
+};
+prci0: prci@1000 {


clock-controller@...


Thanks; fixed.


- Paul


Re: [PATCH v2 1/2] dt-bindings: serial: add documentation for the SiFive UART driver

2018-11-16 Thread Paul Walmsley

On Wed, 24 Oct 2018, Rob Herring wrote:


On Tue, Oct 23, 2018 at 10:05:40AM -0700, Paul Walmsley wrote:

On 10/20/18 7:21 AM, Rob Herring wrote:

On Fri, Oct 19, 2018 at 5:06 PM Paul Walmsley  wrote:

On 10/19/18 1:45 PM, Rob Herring wrote:

On Fri, Oct 19, 2018 at 1:48 PM Paul Walmsley  wrote:

Add DT binding documentation for the Linux driver for the SiFive
asynchronous serial IP block.  Nothing too exotic.

Cc: linux-ser...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-ri...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Palmer Dabbelt 
Reviewed-by: Palmer Dabbelt 
Signed-off-by: Paul Walmsley 
Signed-off-by: Paul Walmsley 
---
   .../bindings/serial/sifive-serial.txt | 21 +++
   1 file changed, 21 insertions(+)
   create mode 100644 Documentation/devicetree/bindings/serial/sifive-serial.txt

diff --git a/Documentation/devicetree/bindings/serial/sifive-serial.txt 
b/Documentation/devicetree/bindings/serial/sifive-serial.txt
new file mode 100644
index ..8982338512f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/sifive-serial.txt
@@ -0,0 +1,21 @@
+SiFive asynchronous serial interface (UART)
+
+Required properties:
+
+- compatible: should be "sifive,fu540-c000-uart0" or "sifive,uart0"


As I mentioned for the
intc and now the pwm block bindings, if you are going to do version
numbers please document the versioning scheme.


Will add that to the binding document.

I don't seem to be making my point clear. I don't want any of this
added to a binding doc for particular IP blocks. Write a common doc
that explains the scheme and addresses the questions I asked. Then
just reference that doc here.

Maybe this is documented somewhere already? Otherwise, if one is
creating a new IP block, how do they know what the versioning scheme
is or what goes in the DT ROM?



Seems like there might be some confusion between IP blocks as integrated on
an SoC vs. IP blocks in isolation.  It's not necessarily the SoC integrator
that sets an IP block version number; this can come from the IP block vendor
itself.  So each IP block may have its own version numbering practices for
the IP block alone.


For SiFive IP blocks, we at SiFive could probably align on a common version
numbering structure for what's in the sifive-blocks repository.


I thought you had that from what Palmer said and what I've seen so far.
You have at least 3 bindings so far it seems.


Yep.


But other IP blocks from other vendors may not align to that, or may not
have version numbers exposed at all.  In those cases there's no way for
software folks to find out what they are,  as you pointed out earlier.  This
is the case with most DT compatible strings in the kernel tree.

For example, we've integrated the NVDLA IP block, from NVIDIA, on some
designs.  Any NVIDIA version numbers in that IP block will probably not
follow the SiFive version numbering scheme.  I'd propose the right thing to
do for an IP block compatible string is to follow the vendor's practice, and
then use the SoC integrator's version numbering practice for the
SoC-integrated compatible string.


Experience has shown that using compatible strings only specific to
vendor IP blocks (with or without version numbers) is pretty useless.

For licensed IP, I'd suggest you follow standard practices.


OK

A genericish fallback is generally only used when there's lots of SoCs 
sharing a block.


In these cases though it needs to be clear what bindings follow some
common versioning scheme and which don't. That's accomplished
by referencing what the version scheme is. Otherwise, I'd expect I'll
see the versioning scheme copied when in fact the source IP in no way
follows it.


In effect, an SoC integration DT compatible string like
"sifive,fu540-c000-uart" implicitly states an IP block version number:
"whatever came out of the fab on the chip"[**].   I'd propose that even in
these cases, there's an advantage to keeping the "0" on the end, since it
uniquely identifies an SoC-independent IP block, rather than just the type
of the IP block.   But if the "0" on the end of the SoC integration DT
compatible string is problematic for you, we can certainly drop that last 0
from the SoC integration DT compatible string, and only suffer a slight lack
of clarity as to what version was integrated on that chip.


Personally I'd leave it off, but I'm fine with either way. It just needs
to be the way you document for SiFive IP blocks.


OK, we'll leave it off.


Really, I'd just like to see folks get better at putting version and
configuration information into registers. We only need DT for what we
can't discover.


Yep, agreed.


- Paul

Re: [PATCH v3 1/2] x86/fpu: track AVX-512 usage of tasks

2018-11-16 Thread Dave Hansen
On 11/15/18 4:21 PM, Li, Aubrey wrote:
> "Core cycles where the core was running with power delivery for license
> level 2 (introduced in Skylake Server microarchitecture). This includes
> high current AVX 512-bit instructions."
> 
> I translated license level 2 to frequency drop.

BTW, the "high" in that text: "high-current AVX 512-bit instructions" is
talking about high-current, not "high ... instructions" or high-numbered
registers.  I think that might be the source of some of the confusion
about which XSAVE state needs to be examined.

Just to be clear: there are 3 AVX-512 XSAVE states:

XFEATURE_OPMASK,
XFEATURE_ZMM_Hi256,
XFEATURE_Hi16_ZMM,

I honestly don't know what XFEATURE_OPMASK does.  It does not appear to
be affected by VZEROUPPER (although VZEROUPPER's SDM documentation isn't
looking too great).

But, XFEATURE_ZMM_Hi256 is used for the upper 256 bits of the
registers ZMM0-ZMM15.  Those are AVX-512-only registers.  The only way
to get data into XFEATURE_ZMM_Hi256 state is by using AVX512 instructions.

XFEATURE_Hi16_ZMM is the same.  The only way to get state in there is
with AVX512 instructions.

So, first of all, I think you *MUST* check XFEATURE_ZMM_Hi256 and
XFEATURE_Hi16_ZMM.  That's without question.

It's probably *possible* to run AVX512 instructions by loading state
into the YMM register and then executing AVX512 instructions that only
write to memory and never to register state.  That *might* allow
XFEATURE_Hi16_ZMM and XFEATURE_ZMM_Hi256 to stay in the init state, but
for the frequency to be affected since AVX512 instructions _are_
executing.  But, there's no way to detect this situation from XSAVE
states themselves.


Re: [PATCH v1 2/5] perf cs-etm: Avoid stale branch samples when flush packet

2018-11-16 Thread Mathieu Poirier
On Sun, Nov 11, 2018 at 12:59:40PM +0800, Leo Yan wrote:
> At the end of trace buffer handling, function cs_etm__flush() is invoked
> to flush any remaining branch stack entries.  As a side effect, it also
> generates branch sample, because the 'etmq->packet' doesn't contains any
> new coming packet but point to one stale packet after packets swapping,
> so it wrongly makes synthesize branch samples with stale packet info.
> 
> We could review below detailed flow which causes issue:
> 
>   Packet1: start_addr=0x08b1fbf0 end_addr=0x08b1fbfc
>   Packet2: start_addr=0x08b1fb5c end_addr=0x08b1fb6c
> 
>   step 1: cs_etm__sample():
>   sample: ip=(0x08b1fbfc-4) addr=0x08b1fb5c
> 
>   step 2: flush packet in cs_etm__run_decoder():
>   cs_etm__run_decoder()
> `-> err = cs_etm__flush(etmq, false);
>   sample: ip=(0x08b1fb6c-4) addr=0x08b1fbf0
> 
> Packet1 and packet2 are two continuous packets, when packet2 is the new
> coming packet, cs_etm__sample() generates branch sample for these two
> packets and use [packet1::end_addr - 4 => packet2::start_addr] as branch
> jump flow, thus we can see the first generated branch sample in step 1.
> At the end of cs_etm__sample() it swaps packets so 'etm->prev_packet'=
> packet2 and 'etm->packet'=packet1, so far it's okay for branch sample.
> 
> If packet2 is the last one packet in trace buffer, even there have no
> any new coming packet, cs_etm__run_decoder() invokes cs_etm__flush() to
> flush branch stack entries as expected, but it also generates branch
> samples by taking 'etm->packet' as a new coming packet, thus the branch
> jump flow is as [packet2::end_addr - 4 =>  packet1::start_addr]; this
> is the second sample which is generated in step 2.  So actually the
> second sample is a stale sample and we should not generate it.
> 
> This patch is to add new argument 'new_packet' for cs_etm__flush(), we
> can pass 'true' for this argument if there have a new packet, otherwise
> it will pass 'false' for the purpose of only flushing branch stack
> entries and avoid to generate sample for stale packet.

Very good explanation, thanks for taking the time to write this.

> 
> Signed-off-by: Leo Yan 
> ---
>  tools/perf/util/cs-etm.c | 20 +---
>  1 file changed, 17 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> index fe18d7b..f4fa877 100644
> --- a/tools/perf/util/cs-etm.c
> +++ b/tools/perf/util/cs-etm.c
> @@ -955,7 +955,7 @@ static int cs_etm__sample(struct cs_etm_queue *etmq)
>   return 0;
>  }
>  
> -static int cs_etm__flush(struct cs_etm_queue *etmq)
> +static int cs_etm__flush(struct cs_etm_queue *etmq, bool new_packet)
>  {
>   int err = 0;
>   struct cs_etm_auxtrace *etm = etmq->etm;
> @@ -989,6 +989,20 @@ static int cs_etm__flush(struct cs_etm_queue *etmq)
>  
>   }
>  
> + /*
> +  * If 'new_packet' is false, this time call has no a new packet
> +  * coming and 'etmq->packet' contains the stale packet which is
> +  * set at the previous time with packets swapping.  In this case
> +  * this function is invoked only for flushing branch stack at
> +  * the end of buffer handling.
> +  *
> +  * Simply to say, branch samples should be generated when every
> +  * time receive one new packet; otherwise, directly bail out to
> +  * avoid generate branch sample with stale packet.
> +  */
> + if (!new_packet)
> + return 0;
> +
>   if (etm->sample_branches &&
>   etmq->prev_packet->sample_type == CS_ETM_RANGE) {
>   err = cs_etm__synth_branch_sample(etmq);
> @@ -1075,7 +1089,7 @@ static int cs_etm__run_decoder(struct cs_etm_queue 
> *etmq)
>* Discontinuity in trace, flush
>* previous branch stack
>*/
> - cs_etm__flush(etmq);
> + cs_etm__flush(etmq, true);
>   break;
>   case CS_ETM_EMPTY:
>   /*
> @@ -1092,7 +1106,7 @@ static int cs_etm__run_decoder(struct cs_etm_queue 
> *etmq)
>  
>   if (err == 0)
>   /* Flush any remaining branch stack entries */
> - err = cs_etm__flush(etmq);
> + err = cs_etm__flush(etmq, false);

I understand what you're doing and it will yield the correct results.  What I'm
not sure about is if we wouldn't be better off splitting cs_etm__flush()
in order to reduce the complexity of the main decoding loop.  That is rename
cs_etm__flush() to something like cs_etm__trace_on() and spin off a new
cs_etm__end_block().  

It does introduce a little bit of code duplication but I think we'd win in terms
of readability and flexibility.

Thanks,
Mathieu


>   

[PATCH 7/7] Staging: iio: adt7316: Use device tree data to assign irq_type

2018-11-16 Thread Shreeya Patel
ADT7316 driver no more uses platform data and hence use device tree
data instead of platform data for assigning irq_type field.
Switch case figures out the type of irq and if it's the default case
then assign the default value to the irq_type i.e.
irq_type = IRQF_TRIGGER_LOW

Signed-off-by: Shreeya Patel 
---
 drivers/staging/iio/addac/adt7316.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/iio/addac/adt7316.c 
b/drivers/staging/iio/addac/adt7316.c
index 9c72538baf9e..c647875a64f5 100644
--- a/drivers/staging/iio/addac/adt7316.c
+++ b/drivers/staging/iio/addac/adt7316.c
@@ -2101,8 +2101,7 @@ int adt7316_probe(struct device *dev, struct adt7316_bus 
*bus,
 {
struct adt7316_chip_info *chip;
struct iio_dev *indio_dev;
-   unsigned short *adt7316_platform_data = dev->platform_data;
-   int irq_type = IRQF_TRIGGER_LOW;
+   int irq_type;
int ret = 0;
 
indio_dev = devm_iio_device_alloc(dev, sizeof(*chip));
@@ -2146,8 +2145,22 @@ int adt7316_probe(struct device *dev, struct adt7316_bus 
*bus,
indio_dev->modes = INDIO_DIRECT_MODE;
 
if (chip->bus.irq > 0) {
-   if (adt7316_platform_data[0])
-   irq_type = adt7316_platform_data[0];
+   irq_type =
+   irqd_get_trigger_type(irq_get_irq_data(chip->bus.irq));
+
+   switch (irq_type) {
+   case IRQF_TRIGGER_HIGH:
+   case IRQF_TRIGGER_RISING:
+   break;
+   case IRQF_TRIGGER_LOW:
+   case IRQF_TRIGGER_FALLING:
+   break;
+   default:
+   dev_info(dev, "mode %d unsupported, using 
IRQF_TRIGGER_LOW\n",
+irq_type);
+   irq_type = IRQF_TRIGGER_LOW;
+   break;
+   }
 
ret = devm_request_threaded_irq(dev, chip->bus.irq,
NULL,
-- 
2.17.1



[PATCH 6/7] Staging: iio: adt7316: Change the name from irq_flags to irq_type

2018-11-16 Thread Shreeya Patel
Most of the drivers in IIO uses irq_type as the name for
storing the interrupt type and hence change the name from
irq_flags to irq_type for maintaining the consistency.

Signed-off-by: Shreeya Patel 
---
 drivers/staging/iio/addac/adt7316.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/iio/addac/adt7316.c 
b/drivers/staging/iio/addac/adt7316.c
index dfae22619287..9c72538baf9e 100644
--- a/drivers/staging/iio/addac/adt7316.c
+++ b/drivers/staging/iio/addac/adt7316.c
@@ -2102,7 +2102,7 @@ int adt7316_probe(struct device *dev, struct adt7316_bus 
*bus,
struct adt7316_chip_info *chip;
struct iio_dev *indio_dev;
unsigned short *adt7316_platform_data = dev->platform_data;
-   int irq_flags = IRQF_TRIGGER_LOW;
+   int irq_type = IRQF_TRIGGER_LOW;
int ret = 0;
 
indio_dev = devm_iio_device_alloc(dev, sizeof(*chip));
@@ -2147,18 +2147,18 @@ int adt7316_probe(struct device *dev, struct 
adt7316_bus *bus,
 
if (chip->bus.irq > 0) {
if (adt7316_platform_data[0])
-   irq_flags = adt7316_platform_data[0];
+   irq_type = adt7316_platform_data[0];
 
ret = devm_request_threaded_irq(dev, chip->bus.irq,
NULL,
adt7316_event_handler,
-   irq_flags | IRQF_ONESHOT,
+   irq_type | IRQF_ONESHOT,
indio_dev->name,
indio_dev);
if (ret)
return ret;
 
-   if (irq_flags & IRQF_TRIGGER_HIGH)
+   if (irq_type & IRQF_TRIGGER_HIGH)
chip->config1 |= ADT7316_INT_POLARITY;
}
 
-- 
2.17.1



Re: KMSAN: kernel-infoleak in kvm_arch_vcpu_ioctl

2018-11-16 Thread Liran Alon



> On 17 Nov 2018, at 0:09, syzbot 
>  wrote:
> 
> Hello,
> 
> syzbot found the following crash on:
> 
> HEAD commit:006aa39cddee kmsan: don't instrument fixup_bad_iret()
> git tree:   
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_google_kmsan.git_master=DwIBaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=Jk6Q8nNzkQ6LJ6g42qARkg6ryIDGQr-yKXPNGZbpTx0=6-j0bZwOIu2D7UVtppvdFzCPoDvVU1l3ExqVO_Po11o=qBVZxFprJcGeWFBppSXwwkTrx3u7E8vv78UxFb1N2yM=
> console output: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_x_log.txt-3Fx-3D101dcb0b40=DwIBaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=Jk6Q8nNzkQ6LJ6g42qARkg6ryIDGQr-yKXPNGZbpTx0=6-j0bZwOIu2D7UVtppvdFzCPoDvVU1l3ExqVO_Po11o=m7FuREmXFg2ZHCkPmLKPCIrMU2Pw0zlAPdkpQXTtmHs=
> kernel config:  
> https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_x_.config-3Fx-3Df388ea1732f3c473=DwIBaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=Jk6Q8nNzkQ6LJ6g42qARkg6ryIDGQr-yKXPNGZbpTx0=6-j0bZwOIu2D7UVtppvdFzCPoDvVU1l3ExqVO_Po11o=vvmEqhqn8-cl-D88zy6BsN9exSDvIKxVRopXWs0hIYE=
> dashboard link: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_bug-3Fextid-3Dcfbc368e283d381f8cef=DwIBaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=Jk6Q8nNzkQ6LJ6g42qARkg6ryIDGQr-yKXPNGZbpTx0=6-j0bZwOIu2D7UVtppvdFzCPoDvVU1l3ExqVO_Po11o=HTwepMOiTfeo-sYvcbfkdwY3-DouLgzz3XT6a26qLhM=
> compiler:   clang version 8.0.0 (trunk 343298)
> syz repro:  
> https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_x_repro.syz-3Fx-3D10c56fbd40=DwIBaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=Jk6Q8nNzkQ6LJ6g42qARkg6ryIDGQr-yKXPNGZbpTx0=6-j0bZwOIu2D7UVtppvdFzCPoDvVU1l3ExqVO_Po11o=N7ZWdZk1M360lcHmoXIX8utlbcjYLe7MPu_Gxe3sLBU=
> C reproducer:   
> https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_x_repro.c-3Fx-3D153c8a4740=DwIBaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=Jk6Q8nNzkQ6LJ6g42qARkg6ryIDGQr-yKXPNGZbpTx0=6-j0bZwOIu2D7UVtppvdFzCPoDvVU1l3ExqVO_Po11o=Y_PwncNZIx_yxjGLefhRu5GpOYmjCqOloLFHGxsH7eQ=
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+cfbc368e283d381f8...@syzkaller.appspotmail.com
> 
> IPVS: ftp: loaded support on port[0] = 21
> L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.kernel.org_doc_html_latest_admin-2Dguide_l1tf.html=DwIBaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=Jk6Q8nNzkQ6LJ6g42qARkg6ryIDGQr-yKXPNGZbpTx0=6-j0bZwOIu2D7UVtppvdFzCPoDvVU1l3ExqVO_Po11o=W59LMRxHTTYAxlGlzLxWOuioL5Z6ousHYqJPO5KJuDI=
>  for details.
> ==
> BUG: KMSAN: kernel-infoleak in _copy_to_user+0x19a/0x230 lib/usercopy.c:31
> CPU: 0 PID: 6697 Comm: syz-executor853 Not tainted 4.20.0-rc2+ #85
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS 
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x32d/0x480 lib/dump_stack.c:113
> kmsan_report+0x19f/0x300 mm/kmsan/kmsan.c:911
> kmsan_internal_check_memory+0x35b/0x3b0 mm/kmsan/kmsan.c:993
> kmsan_copy_to_user+0x7c/0xe0 mm/kmsan/kmsan_hooks.c:552
> _copy_to_user+0x19a/0x230 lib/usercopy.c:31
> copy_to_user include/linux/uaccess.h:183 [inline]
> kvm_vcpu_ioctl_enable_cap arch/x86/kvm/x86.c:3834 [inline]
> kvm_arch_vcpu_ioctl+0x5dee/0x7680 arch/x86/kvm/x86.c:4132
> kvm_vcpu_ioctl+0xca3/0x1f90 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2748
> do_vfs_ioctl+0xfbc/0x2f70 fs/ioctl.c:46
> ksys_ioctl fs/ioctl.c:713 [inline]
> __do_sys_ioctl fs/ioctl.c:720 [inline]
> __se_sys_ioctl+0x1da/0x270 fs/ioctl.c:718
> __x64_sys_ioctl+0x4a/0x70 fs/ioctl.c:718
> do_syscall_64+0xcf/0x110 arch/x86/entry/common.c:291
> entry_SYSCALL_64_after_hwframe+0x63/0xe7
> RIP: 0033:0x4471b9
> Code: e8 fc b9 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 
> 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 
> 83 3b 07 fc ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:7f1e22946da8 EFLAGS: 0246 ORIG_RAX: 0010
> RAX: ffda RBX: 006f0038 RCX: 004471b9
> RDX: 2000 RSI: 4068aea3 RDI: 0005
> RBP: 006f0030 R08:  R09: 
> R10:  R11: 0246 R12: 006f003c
> R13: 6d766b2f7665642f R14: 7f1e229479c0 R15: 03e8
> 
> Local variable description: __pu_val@kvm_arch_vcpu_ioctl
> Variable was created at:
> kvm_arch_vcpu_ioctl+0x29d/0x7680 arch/x86/kvm/x86.c:3848
> kvm_vcpu_ioctl+0xca3/0x1f90 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2748
> 
> Bytes 0-1 of 2 are uninitialized
> Memory access of size 2 starts at 8881967ffbb0
> Data copied to user address 00706000
> ==
> 

The info-leak bug is very simple, What happens is the 

[PATCH 5/7] Staging: iio: adt7316: Switch irq_flags to a local variable

2018-11-16 Thread Shreeya Patel
There is no need to store irq_flags into the structure as it
is always set to the same thing. Hence switch irq_flags to a
local variable.

Signed-off-by: Shreeya Patel 
---
 drivers/staging/iio/addac/adt7316-i2c.c | 1 -
 drivers/staging/iio/addac/adt7316-spi.c | 1 -
 drivers/staging/iio/addac/adt7316.c | 8 
 drivers/staging/iio/addac/adt7316.h | 1 -
 4 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/iio/addac/adt7316-i2c.c 
b/drivers/staging/iio/addac/adt7316-i2c.c
index d4b5060c18ee..91d6cdcb747e 100644
--- a/drivers/staging/iio/addac/adt7316-i2c.c
+++ b/drivers/staging/iio/addac/adt7316-i2c.c
@@ -104,7 +104,6 @@ static int adt7316_i2c_probe(struct i2c_client *client,
struct adt7316_bus bus = {
.client = client,
.irq = client->irq,
-   .irq_flags = IRQF_TRIGGER_LOW,
.read = adt7316_i2c_read,
.write = adt7316_i2c_write,
.multi_read = adt7316_i2c_multi_read,
diff --git a/drivers/staging/iio/addac/adt7316-spi.c 
b/drivers/staging/iio/addac/adt7316-spi.c
index 5cd22743e140..e75827e326a6 100644
--- a/drivers/staging/iio/addac/adt7316-spi.c
+++ b/drivers/staging/iio/addac/adt7316-spi.c
@@ -94,7 +94,6 @@ static int adt7316_spi_probe(struct spi_device *spi_dev)
struct adt7316_bus bus = {
.client = spi_dev,
.irq = spi_dev->irq,
-   .irq_flags = IRQF_TRIGGER_LOW,
.read = adt7316_spi_read,
.write = adt7316_spi_write,
.multi_read = adt7316_spi_multi_read,
diff --git a/drivers/staging/iio/addac/adt7316.c 
b/drivers/staging/iio/addac/adt7316.c
index deb2f7b40f60..dfae22619287 100644
--- a/drivers/staging/iio/addac/adt7316.c
+++ b/drivers/staging/iio/addac/adt7316.c
@@ -2102,6 +2102,7 @@ int adt7316_probe(struct device *dev, struct adt7316_bus 
*bus,
struct adt7316_chip_info *chip;
struct iio_dev *indio_dev;
unsigned short *adt7316_platform_data = dev->platform_data;
+   int irq_flags = IRQF_TRIGGER_LOW;
int ret = 0;
 
indio_dev = devm_iio_device_alloc(dev, sizeof(*chip));
@@ -2146,19 +2147,18 @@ int adt7316_probe(struct device *dev, struct 
adt7316_bus *bus,
 
if (chip->bus.irq > 0) {
if (adt7316_platform_data[0])
-   chip->bus.irq_flags = adt7316_platform_data[0];
+   irq_flags = adt7316_platform_data[0];
 
ret = devm_request_threaded_irq(dev, chip->bus.irq,
NULL,
adt7316_event_handler,
-   chip->bus.irq_flags |
-   IRQF_ONESHOT,
+   irq_flags | IRQF_ONESHOT,
indio_dev->name,
indio_dev);
if (ret)
return ret;
 
-   if (chip->bus.irq_flags & IRQF_TRIGGER_HIGH)
+   if (irq_flags & IRQF_TRIGGER_HIGH)
chip->config1 |= ADT7316_INT_POLARITY;
}
 
diff --git a/drivers/staging/iio/addac/adt7316.h 
b/drivers/staging/iio/addac/adt7316.h
index ec40fbb698a6..fd7c5c92b599 100644
--- a/drivers/staging/iio/addac/adt7316.h
+++ b/drivers/staging/iio/addac/adt7316.h
@@ -17,7 +17,6 @@
 struct adt7316_bus {
void *client;
int irq;
-   int irq_flags;
int (*read)(void *client, u8 reg, u8 *data);
int (*write)(void *client, u8 reg, u8 val);
int (*multi_read)(void *client, u8 first_reg, u8 count, u8 *data);
-- 
2.17.1



Re: [PATCH v5 5/9] dt-bindings: spi: Adjust the bindings for the FSL QSPI driver

2018-11-16 Thread Rob Herring
On Tue, 13 Nov 2018 13:47:37 +, Schrempf Frieder wrote:
> Adjust the documentation of the new SPI memory interface based
> driver to reflect the new drivers settings.
> 
> The "old" driver was using the "fsl,qspi-has-second-chip" property to
> select one of two dual chip setups (two chips on one bus or two chips
> on separate buses). And it used the order in which the subnodes are
> defined in the dt to select the CS, the chip is connected to.
> 
> Both methods are wrong and in fact the "reg" property should be used to
> determine which bus and CS a chip is connected to. This also enables us
> to use different setups than just single chip, or symmetric dual chip.
> 
> So the porting of the driver from the MTD to the SPI framework actually
> enforces the use of the "reg" properties and makes
> "fsl,qspi-has-second-chip" superfluous.
> 
> As all boards that have "fsl,qspi-has-second-chip" set, also have
> correct "reg" properties, the removal of this property shouldn't lead to
> any incompatibilities.
> 
> The only compatibility issues I can see are with imx6sx-sdb.dts and
> imx6sx-sdb-reva.dts, which have their reg properties set incorrectly
> (see explanation here: [2]), all other boards should stay compatible.
> 
> Also the "big-endian" flag was removed, as this setting is now selected
> by the driver, depending on which SoC is in use.
> 
> [2] https://patchwork.ozlabs.org/patch/922817/#1925445
> 
> Signed-off-by: Frieder Schrempf 
> ---
>  .../devicetree/bindings/spi/spi-fsl-qspi.txt  | 18 --
>  1 file changed, 8 insertions(+), 10 deletions(-)
> 

Reviewed-by: Rob Herring 



Re: [PATCH v5 4/9] dt-bindings: spi: Move the bindings for the FSL QSPI driver

2018-11-16 Thread Rob Herring
On Tue, 13 Nov 2018 13:47:34 +, Schrempf Frieder wrote:
> Move the documentation of the old SPI NOR driver to the place of the new
> SPI memory interface based driver.
> 
> Signed-off-by: Frieder Schrempf 
> ---
>  .../bindings/{mtd/fsl-quadspi.txt => spi/spi-fsl-qspi.txt}   | 0
>  1 file changed, 0 insertions(+), 0 deletions(-)
> 

Reviewed-by: Rob Herring 



Re: [PATCH v1 1/5] perf cs-etm: Correct packets swapping in cs_etm__flush()

2018-11-16 Thread Mathieu Poirier
On Sun, Nov 11, 2018 at 12:59:39PM +0800, Leo Yan wrote:
> The structure cs_etm_queue uses 'prev_packet' to point to previous
> packet, this can be used to combine with new coming packet to generate
> samples.
> 
> In function cs_etm__flush() it swaps packets only when the flag
> 'etm->synth_opts.last_branch' is true, this means that it will not
> swap packets if without option '--itrace=il' to generate last branch
> entries; thus for this case the 'prev_packet' doesn't point to the
> correct previous packet and the stale packet still will be used to
> generate sequential sample.  Thus if dump trace with 'perf script'
> command we can see the incorrect flow with the stale packet's address
> info.
> 
> This patch corrects packets swapping in cs_etm__flush(); except using
> the flag 'etm->synth_opts.last_branch' it also checks the another flag
> 'etm->sample_branches', if any flag is true then it swaps packets so
> can save correct content to 'prev_packet'.  Finally this can fix the
> wrong program flow dumping issue.
> 
> Signed-off-by: Leo Yan 
> ---
>  tools/perf/util/cs-etm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> index 48ad217..fe18d7b 100644
> --- a/tools/perf/util/cs-etm.c
> +++ b/tools/perf/util/cs-etm.c
> @@ -997,7 +997,7 @@ static int cs_etm__flush(struct cs_etm_queue *etmq)
>   }
>  
>  swap_packet:
> - if (etmq->etm->synth_opts.last_branch) {
> + if (etm->sample_branches || etmq->etm->synth_opts.last_branch) {

This seems like the right thing to do, if only to be consistent with that is
done in cs_etm__sample().

Reviewed-by: Mathieu Poirier 

>   /*
>* Swap PACKET with PREV_PACKET: PACKET becomes PREV_PACKET for
>* the next incoming packet.
> -- 
> 2.7.4
> 


[PATCH 4/7] Staging: iio: adt7316: Use device tree data to set ldac_pin

2018-11-16 Thread Shreeya Patel
Make the driver use device tree instead of the platform data.
Hence, use devm_gpiod_get_optional function to get the data from
device tree for ldac-pin and accordingly make the needed changes
in the driver.

Signed-off-by: Shreeya Patel 
---
 drivers/staging/iio/addac/adt7316.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/iio/addac/adt7316.c 
b/drivers/staging/iio/addac/adt7316.c
index 3f22d1088713..deb2f7b40f60 100644
--- a/drivers/staging/iio/addac/adt7316.c
+++ b/drivers/staging/iio/addac/adt7316.c
@@ -177,7 +177,7 @@
 
 struct adt7316_chip_info {
struct adt7316_bus  bus;
-   u16 ldac_pin;
+   struct gpio_desc*ldac_pin;
u16 int_mask;   /* 0x2f */
u8  config1;
u8  config2;
@@ -950,8 +950,8 @@ static ssize_t adt7316_store_update_DAC(struct device *dev,
if (ret)
return -EIO;
} else {
-   gpio_set_value(chip->ldac_pin, 0);
-   gpio_set_value(chip->ldac_pin, 1);
+   gpiod_set_value(chip->ldac_pin, 0);
+   gpiod_set_value(chip->ldac_pin, 1);
}
 
return len;
@@ -2120,7 +2120,13 @@ int adt7316_probe(struct device *dev, struct adt7316_bus 
*bus,
else
return -ENODEV;
 
-   chip->ldac_pin = adt7316_platform_data[1];
+   chip->ldac_pin = devm_gpiod_get_optional(dev, "ldac", GPIOD_OUT_LOW);
+   if (IS_ERR(chip->ldac_pin)) {
+   ret = PTR_ERR(chip->ldac_pin);
+   dev_err(dev, "Failed to request ldac GPIO: %d\n", ret);
+   return ret;
+   }
+
if (chip->ldac_pin) {
chip->config3 |= ADT7316_DA_EN_VIA_DAC_LDCA;
if ((chip->id & ID_FAMILY_MASK) == ID_ADT75XX)
-- 
2.17.1



[PATCH 3/7] Staging: iio: adt7316: Add of_device_id table

2018-11-16 Thread Shreeya Patel
When the kernel starts up, it kicks off compiled-in drivers
that match “compatible” entries it finds in the device tree.
At a later stage (when /lib/modules is available), all kernel modules
that match “compatible” entries in the device tree are loaded.
Hence to be able to use device tree for ADT7316, add of_device_id
table which specifies the supported devices through compatible
property.
Note that there is a fall back path in i2c that will result
in i2c_device_id table being used if there is no of_devcie_id table.

Signed-off-by: Shreeya Patel 
---
 drivers/staging/iio/addac/adt7316-i2c.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/staging/iio/addac/adt7316-i2c.c 
b/drivers/staging/iio/addac/adt7316-i2c.c
index 473e5e34ec00..d4b5060c18ee 100644
--- a/drivers/staging/iio/addac/adt7316-i2c.c
+++ b/drivers/staging/iio/addac/adt7316-i2c.c
@@ -126,6 +126,18 @@ static const struct i2c_device_id adt7316_i2c_id[] = {
 
 MODULE_DEVICE_TABLE(i2c, adt7316_i2c_id);
 
+static const struct of_device_id adt7316_of_match[] = {
+   { .compatible = "adi,adt7316" },
+   { .compatible = "adi,adt7317" },
+   { .compatible = "adi,adt7318" },
+   { .compatible = "adi,adt7516" },
+   { .compatible = "adi,adt7517" },
+   { .compatible = "adi,adt7519" },
+   { },
+};
+
+MODULE_DEVICE_TABLE(of, adt7316_of_match);
+
 static struct i2c_driver adt7316_driver = {
.driver = {
.name = "adt7316",
-- 
2.17.1



Re: [PATCH 1/7] node: Link memory nodes to their compute nodes

2018-11-16 Thread Dan Williams
On Thu, Nov 15, 2018 at 12:37 PM Matthew Wilcox  wrote:
>
> On Thu, Nov 15, 2018 at 07:59:20AM -0700, Keith Busch wrote:
> > On Thu, Nov 15, 2018 at 05:57:10AM -0800, Matthew Wilcox wrote:
> > > On Wed, Nov 14, 2018 at 03:49:14PM -0700, Keith Busch wrote:
> > > > Memory-only nodes will often have affinity to a compute node, and
> > > > platforms have ways to express that locality relationship.
> > > >
> > > > A node containing CPUs or other DMA devices that can initiate memory
> > > > access are referred to as "memory iniators". A "memory target" is a
> > > > node that provides at least one phyiscal address range accessible to a
> > > > memory initiator.
> > >
> > > I think I may be confused here.  If there is _no_ link from node X to
> > > node Y, does that mean that node X's CPUs cannot access the memory on
> > > node Y?  In my mind, all nodes can access all memory in the system,
> > > just not with uniform bandwidth/latency.
> >
> > The link is just about which nodes are "local". It's like how nodes have
> > a cpulist. Other CPUs not in the node's list can acces that node's memory,
> > but the ones in the mask are local, and provide useful optimization hints.
>
> So ... let's imagine a hypothetical system (I've never seen one built like
> this, but it doesn't seem too implausible).  Connect four CPU sockets in
> a square, each of which has some regular DIMMs attached to it.  CPU A is
> 0 hops to Memory A, one hop to Memory B and Memory C, and two hops from
> Memory D (each CPU only has two "QPI" links).  Then maybe there's some
> special memory extender device attached on the PCIe bus.  Now there's
> Memory B1 and B2 that's attached to CPU B and it's local to CPU B, but
> not as local as Memory B is ... and we'd probably _prefer_ to allocate
> memory for CPU A from Memory B1 than from Memory D.  But ... *mumble*,
> this seems hard.
>
> I understand you're trying to reflect what the HMAT table is telling you,
> I'm just really fuzzy on who's ultimately consuming this information
> and what decisions they're trying to drive from it.

The singular "local" is a limitation of the HMAT, but I would expect
the Linux translation of "local" would allow for multiple initiators
that can achieve some semblance of the "best" performance. Anything
less than best is going to have a wide range of variance and will
likely devolve to looking at the platform firmware data table
directly. The expected 80% case is software wants to be able to ask
"which CPUs should I run on to get the best access to this memory?"


[PATCH] perf: tests: Disable breakpoint tests on ARM (32-bit)

2018-11-16 Thread Florian Fainelli
breakpoint tests on the ARM 32-bit kernel are broken in several ways.

The breakpoint length requested does not necessarily match whether the
function address has the Thumb bit (bit 0) set or not, and this does
matter to the ARM kernel hw_breakpoint infrastructure. See [1] for
background.

[1]: https://lkml.org/lkml/2018/11/15/205

As Will indicated, the overflow handling would require single-stepping
which is not supported at the moment. Just disable those tests for the
ARM 32-bit platforms.

Signed-off-by: Florian Fainelli 
---
 tools/perf/tests/bp_signal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/tests/bp_signal.c b/tools/perf/tests/bp_signal.c
index a467615c5a0e..3b5471ea2331 100644
--- a/tools/perf/tests/bp_signal.c
+++ b/tools/perf/tests/bp_signal.c
@@ -296,7 +296,7 @@ bool test__bp_signal_is_supported(void)
  * instruction breakpoint using the perf event interface.
  * Once it's there we can release this.
  */
-#if defined(__powerpc__) || defined(__s390x__)
+#if defined(__powerpc__) || defined(__s390x__) || defined(__arm__)
return false;
 #else
return true;
-- 
2.17.1



Re: [PATCH v5 4/4] dt-bindings: iio: adc: Add docs for ad7124

2018-11-16 Thread Rob Herring
On Tue, 13 Nov 2018 13:22:18 +0200, Stefan Popa wrote:
> Add support for Analog Devices AD7124 4-channels and 8-channels ADC.
> 
> Signed-off-by: Stefan Popa 
> ---
> Changes in v2:
>   - Nothing changed.
> Changes in v3:
>   - Removed the "adi,channels" property.
>   - Used the "reg" property to get the channel number and 
> "adi,diff-channels"
> for the differential pins. The "adi,channel-number" property was 
> removed.
>   - adi,bipolar is of boolean type.
> Changes in v4:
>   - Used the bipolar and diff-channels properties defined in the new 
> adc.txt doc.
> Changes in v5:
>   - Removed the gain and odr properties from the example.
> 
>  .../devicetree/bindings/iio/adc/adi,ad7124.txt | 75 
> ++
>  MAINTAINERS|  1 +
>  2 files changed, 76 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ad7124.txt
> 

Reviewed-by: Rob Herring 


mmotm 2018-11-16-14-52 uploaded

2018-11-16 Thread akpm
The mm-of-the-moment snapshot 2018-11-16-14-52 has been uploaded to

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

mmotm-readme.txt says

README for mm-of-the-moment:

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

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

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

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

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

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


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

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

To develop on top of mmotm git:

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

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

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




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

A git copy of this tree is available at

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

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


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

  origin.patch
* z3fold-fix-possible-reclaim-races.patch
* psi-simplify-cgroup_move_task.patch
* hugetlbfs-fix-kernel-bug-at-fs-hugetlbfs-inodec-444.patch
* maintainers-update-omap-mmc-entry.patch
* mm-use-kvzalloc-for-swap_info_struct-allocation.patch
* sh-provide-prototypes-for-pci-i-o-mapping-in-asm-ioh.patch
* mm-memory_hotplug-check-zone_movable-in-has_unmovable_pages.patch
* mm-dont-reclaim-inodes-with-many-attached-pages.patch
* scripts-faddr2line-fix-location-of-start_kernel-in-comment.patch
* mm-thp-always-specify-disabled-vmas-as-nh-in-smaps.patch
* ocfs2-free-up-write-context-when-direct-io-failed.patch
* ocfs2-fix-dead-lock-caused-by-ocfs2_defrag_extent.patch
* mm-gup-fix-follow_page_mask-kernel-doc-comment.patch
* mm-fix-numa-statistics-updates.patch
* ubsan-dont-mark-__ubsan_handle_builtin_unreachable-as-noreturn.patch
* mm-fix-a-typo-in-__next_mem_pfn_range-comments.patch
* tmpfs-let-lseek-return-enxio-with-a-negative-offset.patch
* scripts-spdxcheck-make-python3-compliant.patch
* compiler-gcc-hide-compiler_has_generic_builtin_overflow-from-sparse.patch
* kernelh-hide-__is_constexpr-from-sparse.patch
* mm-page_alloc-check-for-max-order-in-hot-path.patch
* mm-cleancache-fix-corruption-on-missed-inode-invalidation.patch
* mm-cleancache-fix-corruption-on-missed-inode-invalidation-fix.patch
* arm-arch-arm-include-asm-pageh-needs-personalityh.patch
* bloat-o-meter-ignore-__addressable_-symbols.patch
* arch-sh-mach-kfr2r09-fix-struct-mtd_oob_ops-build-warning.patch
* ocfs2-optimize-the-reading-of-heartbeat-data.patch
* ocfs2-dlmfs-remove-set-but-not-used-variable-status.patch
* ocfs2-remove-set-but-not-used-variable-lastzero.patch
* ocfs2-improve-ocfs2-makefile.patch
* 
block-restore-proc-partitions-to-not-display-non-partitionable-removable-devices.patch
  mm.patch
* mm-slab-remove-unnecessary-unlikely.patch
* mm-slab-remove-unnecessary-unlikely-fix.patch
* mm-slub-remove-validation-on-cpu_slab-in-__flush_cpu_slab.patch
* mm-slub-page-is-always-non-null-for-node_match.patch
* mm-slub-record-final-state-of-slub-action-in-deactivate_slab.patch
* mm-slub-record-final-state-of-slub-action-in-deactivate_slab-fix.patch
* mm-page_owner-clamp-read-count-to-page_size.patch
* mm-page_owner-clamp-read-count-to-page_size-fix.patch
* mm-hotplug-optimize-clear_hwpoisoned_pages.patch
* mm-hotplug-optimize-clear_hwpoisoned_pages-fix.patch
* mm-mmu_notifier-remove-mmu_notifier_synchronize.patch
* mm-use-mm_zero_struct_page-from-sparc-on-all-64b-architectures.patch
* 

Re: [PATCH v5 2/4] dt-bindings: iio: adc: Add common ADCs properties to a separate file

2018-11-16 Thread Rob Herring
On Tue, 13 Nov 2018 13:21:01 +0200, Stefan Popa wrote:
> There are several ADC drivers that depend on the same device tree
> bindings. Rather than continue to duplicate the properties, this patch
> adds a common adc binding document that can be referenced. For beginning,
> only two properties are documented.
> 
> Signed-off-by: Stefan Popa 
> ---
> Changes in v2, v3:
>   - N/A.
> Changes in v4:
>   - Added this commit.
> Changes in v5:
>   - Nothing changed.
> 
>  Documentation/devicetree/bindings/iio/adc/adc.txt | 23 
> +++
>  1 file changed, 23 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/adc/adc.txt
> 

Reviewed-by: Rob Herring 


Re: [PATCH v5 2/4] dt-bindings: iio: adc: Add common ADCs properties to a separate file

2018-11-16 Thread Rob Herring
On Fri, Nov 16, 2018 at 06:38:38PM +, Jonathan Cameron wrote:
> On Tue, 13 Nov 2018 13:21:01 +0200
> Stefan Popa  wrote:
> 
> > There are several ADC drivers that depend on the same device tree
> > bindings. Rather than continue to duplicate the properties, this patch
> > adds a common adc binding document that can be referenced. For beginning,
> > only two properties are documented.
> > 
> > Signed-off-by: Stefan Popa 
> Looks very sensible to me, but as we are looking at a some generalization
> here, I'd like an Ack from Rob if possible (as he suggested it I think :)

Looks fine to me, but I don't have any clue if this will be flexible 
enough for various h/w.

Rob



Re: Enable tracing only for one function and its children?

2018-11-16 Thread Keith Busch
On Fri, Nov 16, 2018 at 04:37:55PM -0600, Timur Tabi wrote:
> Is there a way to enable ftrace tracing only for one specific function
> and all the functions it calls?  Then when the function returns,
> disable tracing until the next time?
> 
> When I pass the function name only to set_ftrace_filter, it literally
> only traces that function, which doesn't help me.  

I think you're looking for the set_graph_function option for the
function_graph tracer.


  1   2   3   4   5   >