date:20170323

On Tue, 21 Mar 2017, Quentin Schulz wrote:

> This patch adds documentation for the A33 GPADC binding.
> 
> Signed-off-by: Quentin Schulz 
> ---
> 
> v3:
>   - fixed missing allwinner in front of compatible,
>   - updated compatible to allwinner,sun8i-a33-ths to better reflect the
>   datasheet's name,
>   - updated example's DT node name and label to ths,
> 
> added in v2
> 
>  .../devicetree/bindings/mfd/sun4i-gpadc.txt| 59 
> ++
>  1 file changed, 59 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt

This is going to need a DT Ack.

> diff --git a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt 
> b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> new file mode 100644
> index 000..badff36
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> @@ -0,0 +1,59 @@
> +Allwinner SoCs' GPADC Device Tree bindings
> +--
> +The Allwinner SoCs all have an ADC that can also act as a thermal sensor
> +and sometimes as a touchscreen controller.
> +
> +Required properties:
> +  - compatible: "allwinner,sun8i-a33-ths",
> +  - reg: mmio address range of the chip,
> +  - #thermal-sensor-cells: shall be 0,
> +  - #io-channel-cells: shall be 0,
> +
> +Example:
> + ths: ths@01c25000 {
> + compatible = "allwinner,sun8i-a33-ths";
> + reg = <0x01c25000 0x100>;
> + #thermal-sensor-cells = <0>;
> + #io-channel-cells = <0>;
> + };
> +
> +sun4i, sun5i and sun6i SoCs are also supported via the older binding:
> +
> +sun4i resistive touchscreen controller
> +--
> +
> +Required properties:
> + - compatible: "allwinner,sun4i-a10-ts", "allwinner,sun5i-a13-ts" or
> +   "allwinner,sun6i-a31-ts"
> + - reg: mmio address range of the chip
> + - interrupts: interrupt to which the chip is connected
> + - #thermal-sensor-cells: shall be 0
> +
> +Optional properties:
> + - allwinner,ts-attached  : boolean indicating that an actual touchscreen
> +is attached to the controller
> + - allwinner,tp-sensitive-adjust : integer (4 bits)
> +adjust sensitivity of pen down detection
> +between 0 (least sensitive) and 15
> +(defaults to 15)
> + - allwinner,filter-type  : integer (2 bits)
> +select median and averaging filter
> +samples used for median / averaging filter
> +0: 4/2
> +1: 5/3
> +2: 8/4
> +3: 16/8
> +(defaults to 1)
> +
> +Example:
> +
> + rtp: rtp@01c25000 {
> + compatible = "allwinner,sun4i-a10-ts";
> + reg = <0x01c25000 0x100>;
> + interrupts = <29>;
> + allwinner,ts-attached;
> + #thermal-sensor-cells = <0>;
> + /* sensitive/noisy touch panel */
> + allwinner,tp-sensitive-adjust = <0>;
> + allwinner,filter-type = <3>;
> + };

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH 1/8] pinctrl: meson: gxbb: add i2s output pins

2017-03-23 Thread Jerome Brunet

Signed-off-by: Jerome Brunet 
---
 drivers/pinctrl/meson/pinctrl-meson-gxbb.c | 31 ++
 1 file changed, 31 insertions(+)

diff --git a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c 
b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
index 7671424d46cb..8d5dd4772042 100644
--- a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
+++ b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
@@ -236,6 +236,10 @@ static const unsigned int hdmi_hpd_pins[]  = { 
PIN(GPIOH_0, EE_OFF) };
 static const unsigned int hdmi_sda_pins[]  = { PIN(GPIOH_1, EE_OFF) };
 static const unsigned int hdmi_scl_pins[]  = { PIN(GPIOH_2, EE_OFF) };
 
+static const unsigned int i2s_out_ch23_y_pins[]= { PIN(GPIOY_8, 
EE_OFF) };
+static const unsigned int i2s_out_ch45_y_pins[]= { PIN(GPIOY_9, 
EE_OFF) };
+static const unsigned int i2s_out_ch67_y_pins[]= { PIN(GPIOY_10, 
EE_OFF) };
+
 static const struct pinctrl_pin_desc meson_gxbb_aobus_pins[] = {
MESON_PIN(GPIOAO_0, 0),
MESON_PIN(GPIOAO_1, 0),
@@ -274,6 +278,13 @@ static const unsigned int pwm_ao_a_6_pins[]= { 
PIN(GPIOAO_6, 0) };
 static const unsigned int pwm_ao_a_12_pins[]   = { PIN(GPIOAO_12, 0) };
 static const unsigned int pwm_ao_b_pins[]  = { PIN(GPIOAO_13, 0) };
 
+static const unsigned int i2s_am_clk_pins[] = { PIN(GPIOAO_8, 0) };
+static const unsigned int i2s_out_ao_clk_pins[] = { PIN(GPIOAO_9, 0) };
+static const unsigned int i2s_out_lr_clk_pins[] = { PIN(GPIOAO_10, 0) 
};
+static const unsigned int i2s_out_ch01_ao_pins[] = { PIN(GPIOAO_11, 0) };
+static const unsigned int i2s_out_ch23_ao_pins[] = { PIN(GPIOAO_12, 0) };
+static const unsigned int i2s_out_ch45_ao_pins[] = { PIN(GPIOAO_13, 0) };
+
 static struct meson_pmx_group meson_gxbb_periphs_groups[] = {
GPIO_GROUP(GPIOZ_0, EE_OFF),
GPIO_GROUP(GPIOZ_1, EE_OFF),
@@ -426,6 +437,9 @@ static struct meson_pmx_group meson_gxbb_periphs_groups[] = 
{
GROUP(uart_rx_c,1,  16),
GROUP(pwm_a_y,  1,  21),
GROUP(pwm_f_y,  1,  20),
+   GROUP(i2s_out_ch23_y,   1,  5),
+   GROUP(i2s_out_ch45_y,   1,  6),
+   GROUP(i2s_out_ch67_y,   1,  7),
 
/* Bank Z */
GROUP(eth_mdio, 6,  1),
@@ -523,6 +537,12 @@ static struct meson_pmx_group meson_gxbb_aobus_groups[] = {
GROUP(pwm_ao_a_6,   0,  18),
GROUP(pwm_ao_a_12,  0,  17),
GROUP(pwm_ao_b, 0,  3),
+   GROUP(i2s_am_clk,   0,  30),
+   GROUP(i2s_out_ao_clk,   0,  29),
+   GROUP(i2s_out_lr_clk,   0,  28),
+   GROUP(i2s_out_ch01_ao,  0,  27),
+   GROUP(i2s_out_ch23_ao,  1,  0),
+   GROUP(i2s_out_ch45_ao,  1,  1),
 };
 
 static const char * const gpio_periphs_groups[] = {
@@ -652,6 +672,10 @@ static const char * const hdmi_i2c_groups[] = {
"hdmi_sda", "hdmi_scl",
 };
 
+static const char * const i2s_out_groups[] = {
+   "i2s_out_ch23_y", "i2s_out_ch45_y", "i2s_out_ch67_y",
+};
+
 static const char * const gpio_aobus_groups[] = {
"GPIOAO_0", "GPIOAO_1", "GPIOAO_2", "GPIOAO_3", "GPIOAO_4",
"GPIOAO_5", "GPIOAO_6", "GPIOAO_7", "GPIOAO_8", "GPIOAO_9",
@@ -694,6 +718,11 @@ static const char * const pwm_ao_b_groups[] = {
"pwm_ao_b",
 };
 
+static const char * const i2s_out_ao_groups[] = {
+   "i2s_am_clk", "i2s_out_ao_clk", "i2s_out_lr_clk",
+   "i2s_out_ch01_ao", "i2s_out_ch23_ao", "i2s_out_ch45_ao",
+};
+
 static struct meson_pmx_func meson_gxbb_periphs_functions[] = {
FUNCTION(gpio_periphs),
FUNCTION(emmc),
@@ -717,6 +746,7 @@ static struct meson_pmx_func meson_gxbb_periphs_functions[] 
= {
FUNCTION(pwm_f_y),
FUNCTION(hdmi_hpd),
FUNCTION(hdmi_i2c),
+   FUNCTION(i2s_out),
 };
 
 static struct meson_pmx_func meson_gxbb_aobus_functions[] = {
@@ -730,6 +760,7 @@ static struct meson_pmx_func meson_gxbb_aobus_functions[] = 
{
FUNCTION(pwm_ao_a_6),
FUNCTION(pwm_ao_a_12),
FUNCTION(pwm_ao_b),
+   FUNCTION(i2s_out_ao),
 };
 
 static struct meson_bank meson_gxbb_periphs_banks[] = {
-- 
2.9.3

Re: [PATCH v3 04/11] Documentation: DT: bindings: mfd: add A33 GPADC binding

On Tue, 21 Mar 2017, Quentin Schulz wrote:

> This patch adds documentation for the A33 GPADC binding.
> 
> Signed-off-by: Quentin Schulz 
> ---
> 
> v3:
>   - fixed missing allwinner in front of compatible,
>   - updated compatible to allwinner,sun8i-a33-ths to better reflect the
>   datasheet's name,
>   - updated example's DT node name and label to ths,
> 
> added in v2
> 
>  .../devicetree/bindings/mfd/sun4i-gpadc.txt| 59 
> ++
>  1 file changed, 59 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt

This is going to need a DT Ack.

> diff --git a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt 
> b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> new file mode 100644
> index 000..badff36
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> @@ -0,0 +1,59 @@
> +Allwinner SoCs' GPADC Device Tree bindings
> +--
> +The Allwinner SoCs all have an ADC that can also act as a thermal sensor
> +and sometimes as a touchscreen controller.
> +
> +Required properties:
> +  - compatible: "allwinner,sun8i-a33-ths",
> +  - reg: mmio address range of the chip,
> +  - #thermal-sensor-cells: shall be 0,
> +  - #io-channel-cells: shall be 0,
> +
> +Example:
> + ths: ths@01c25000 {
> + compatible = "allwinner,sun8i-a33-ths";
> + reg = <0x01c25000 0x100>;
> + #thermal-sensor-cells = <0>;
> + #io-channel-cells = <0>;
> + };
> +
> +sun4i, sun5i and sun6i SoCs are also supported via the older binding:
> +
> +sun4i resistive touchscreen controller
> +--
> +
> +Required properties:
> + - compatible: "allwinner,sun4i-a10-ts", "allwinner,sun5i-a13-ts" or
> +   "allwinner,sun6i-a31-ts"
> + - reg: mmio address range of the chip
> + - interrupts: interrupt to which the chip is connected
> + - #thermal-sensor-cells: shall be 0
> +
> +Optional properties:
> + - allwinner,ts-attached  : boolean indicating that an actual touchscreen
> +is attached to the controller
> + - allwinner,tp-sensitive-adjust : integer (4 bits)
> +adjust sensitivity of pen down detection
> +between 0 (least sensitive) and 15
> +(defaults to 15)
> + - allwinner,filter-type  : integer (2 bits)
> +select median and averaging filter
> +samples used for median / averaging filter
> +0: 4/2
> +1: 5/3
> +2: 8/4
> +3: 16/8
> +(defaults to 1)
> +
> +Example:
> +
> + rtp: rtp@01c25000 {
> + compatible = "allwinner,sun4i-a10-ts";
> + reg = <0x01c25000 0x100>;
> + interrupts = <29>;
> + allwinner,ts-attached;
> + #thermal-sensor-cells = <0>;
> + /* sensitive/noisy touch panel */
> + allwinner,tp-sensitive-adjust = <0>;
> + allwinner,filter-type = <3>;
> + };

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 2/5] mfd: intel_soc_pmic: Select designware i2c-bus driver

On Wed, 22 Mar 2017, Andy Shevchenko wrote:

> On Wed, 2017-03-22 at 12:29 +0100, Hans de Goede wrote:
> > The Crystal Cove PMIC provides an ACPI OPRegion handler, which must be
> > available before other drivers using it are loaded, which is why
> > INTEL_SOC_PMIC is a bool.
> > 
> > Just having the driver is not enough, the driver for the i2c-bus must
> > also be built in, to ensure this, this patch adds a select for it.
> > 
> 
> > While at it this patch also changes the human readable name of the
> > Kconfig
> > option to make clear the INTEL_SOC_PMIC option selects support for the
> > Intel Crystal Cove PMIC and documents why this is a bool.
> 
> The above is what my patch does, I'm okay if the change is going with
> this series as long as Lee is on the same side. Otherwise I would prefer
> to go my changes first.

I think this set is going to need to be rebase on top of MFD.

> > Cc: Andy Shevchenko 
> > Signed-off-by: Hans de Goede 
> > ---
> > Note this patch will partially conflicts with (contains the same
> > changes as)
> > a patch in Andy Shevchenko's tree.
> > ---
> >  drivers/mfd/Kconfig | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > index d427a10..0c6a967 100644
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -425,14 +425,17 @@ config LPC_SCH
> >       System Management Bus and General Purpose I/O.
> >  
> >  config INTEL_SOC_PMIC
> > -   bool "Support for Intel Atom SoC PMIC"
> > +   # This is a bool as it provides an ACPI Opregion which must
> > be
> > +   # available as soon as possible
> > +   bool "Support for Intel Crystal Cove PMIC"
> >     depends on GPIOLIB
> >     depends on I2C=y
> >     select MFD_CORE
> >     select REGMAP_I2C
> >     select REGMAP_IRQ
> > +   select I2C_DESIGNWARE_PLATFORM
> >     help
> > -     Select this option to enable support for the PMIC device
> > +     Select this option to enable support for the Crystal Cove
> > PMIC
> >       on some Intel SoC systems. The PMIC provides ADC, GPIO,
> >       thermal, charger and related power management functions
> >       on these systems.
> 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 2/5] mfd: intel_soc_pmic: Select designware i2c-bus driver

On Wed, 22 Mar 2017, Andy Shevchenko wrote:

> On Wed, 2017-03-22 at 12:29 +0100, Hans de Goede wrote:
> > The Crystal Cove PMIC provides an ACPI OPRegion handler, which must be
> > available before other drivers using it are loaded, which is why
> > INTEL_SOC_PMIC is a bool.
> > 
> > Just having the driver is not enough, the driver for the i2c-bus must
> > also be built in, to ensure this, this patch adds a select for it.
> > 
> 
> > While at it this patch also changes the human readable name of the
> > Kconfig
> > option to make clear the INTEL_SOC_PMIC option selects support for the
> > Intel Crystal Cove PMIC and documents why this is a bool.
> 
> The above is what my patch does, I'm okay if the change is going with
> this series as long as Lee is on the same side. Otherwise I would prefer
> to go my changes first.

I think this set is going to need to be rebase on top of MFD.

> > Cc: Andy Shevchenko 
> > Signed-off-by: Hans de Goede 
> > ---
> > Note this patch will partially conflicts with (contains the same
> > changes as)
> > a patch in Andy Shevchenko's tree.
> > ---
> >  drivers/mfd/Kconfig | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > index d427a10..0c6a967 100644
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -425,14 +425,17 @@ config LPC_SCH
> >       System Management Bus and General Purpose I/O.
> >  
> >  config INTEL_SOC_PMIC
> > -   bool "Support for Intel Atom SoC PMIC"
> > +   # This is a bool as it provides an ACPI Opregion which must
> > be
> > +   # available as soon as possible
> > +   bool "Support for Intel Crystal Cove PMIC"
> >     depends on GPIOLIB
> >     depends on I2C=y
> >     select MFD_CORE
> >     select REGMAP_I2C
> >     select REGMAP_IRQ
> > +   select I2C_DESIGNWARE_PLATFORM
> >     help
> > -     Select this option to enable support for the PMIC device
> > +     Select this option to enable support for the Crystal Cove
> > PMIC
> >       on some Intel SoC systems. The PMIC provides ADC, GPIO,
> >       thermal, charger and related power management functions
> >       on these systems.
> 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [Xen-devel] [PATCH 0/2 v2] xen/acpi: upload PM state from init-domain to Xen

2017-03-23 Thread Boris Ostrovsky

On 03/21/2017 06:43 PM, Ankur Arora wrote:
> This patch series re-enables the upload of PM data from initial-domain
> to Xen. This was broken in commit cd979883b9ede90643e019f33cb317933eb867b4.
>
> The upload now happens post-resume in workqueue context. From the
> POV of Xen, the PM upload might be delayed a little but should be
> fine -- Xen falls-back on more limited P and C states.
>
> Tested C-state upload via mwait_idle=0.
>
> Changes in v2:
>  - rebased to 4.11.0-rc2
>  - addressed comments from Boris Ostrovsky
>
> Ankur Arora (2):
>   xen/acpi: Replace hard coded "ACPI0007"
>   xen/acpi: upload PM state from init-domain to Xen
>
>  drivers/xen/xen-acpi-processor.c | 36 +++-
>  1 file changed, 27 insertions(+), 9 deletions(-)
>

Applied to for-linus-4.11b, with some modifications to commit message in
patch 2.

Next time please copy maintainers (Juergen and me), otherwise there is a
chance that we may miss this. I am also copying Konrad since since his
R-b was not given on the public list.

-boris

Re: [Xen-devel] [PATCH 0/2 v2] xen/acpi: upload PM state from init-domain to Xen

2017-03-23 Thread Boris Ostrovsky

On 03/21/2017 06:43 PM, Ankur Arora wrote:
> This patch series re-enables the upload of PM data from initial-domain
> to Xen. This was broken in commit cd979883b9ede90643e019f33cb317933eb867b4.
>
> The upload now happens post-resume in workqueue context. From the
> POV of Xen, the PM upload might be delayed a little but should be
> fine -- Xen falls-back on more limited P and C states.
>
> Tested C-state upload via mwait_idle=0.
>
> Changes in v2:
>  - rebased to 4.11.0-rc2
>  - addressed comments from Boris Ostrovsky
>
> Ankur Arora (2):
>   xen/acpi: Replace hard coded "ACPI0007"
>   xen/acpi: upload PM state from init-domain to Xen
>
>  drivers/xen/xen-acpi-processor.c | 36 +++-
>  1 file changed, 27 insertions(+), 9 deletions(-)
>

Applied to for-linus-4.11b, with some modifications to commit message in
patch 2.

Next time please copy maintainers (Juergen and me), otherwise there is a
chance that we may miss this. I am also copying Konrad since since his
R-b was not given on the public list.

-boris

Re: [PATCH v2 1/3] mfd: Add Cherry Trail Whiskey Cove PMIC driver

On Mon, 20 Mar 2017, Hans de Goede wrote:

> Add mfd driver for Intel CHT Whiskey Cove PMIC, based on various non
> upstreamed CHT Whiskey Cove PMIC patches.
> 
> This is a somewhat minimal version which adds irqchip support and cells
> for: ACPI PMIC opregion support, the i2c-controller driving the external
> charger irc and the pwrsrc/extcon block.
> 
> Further cells can be added in the future if/when drivers are upstreamed
> for them.
> 
> Cc: Bin Gao 
> Cc: Felipe Balbi 
> Cc: Andy Shevchenko 
> Signed-off-by: Hans de Goede 
> Reviewed-by: Andy Shevchenko 
> ---
> Changes in v2:
> -Since this uses plain mfd and not the intel_soc_pmic stuff give it
>  its own Kconfig and allow this to be built as a module
> -Add missing #include 
> Changes in v3:
> -Drop #include  again, not the right fix for the build errors
> -Error out when the upper byte of the register-address passed to the regmap
>  functions is 0 rather then hardcoding an address in that case
> -Various minor style tweaks / cleanups
> -Move defines of regulator register addresses to intel_pmic_chtwc.c,
>  it is the only place where they are used
> -Drop now empty include/linux/mfd/intel_chtwc.h
> -Rename intel_soc_pmic_chtwc.c to intel_cht_wc.c to match Kconfig option name
> -Add irqchip support
> -Add external charger cell
> -Add pwrsrc cell
> Changes in v4:
> -Use PLATFORM_DEVID_NONE
> ---
>  drivers/mfd/Kconfig|  11 ++
>  drivers/mfd/Makefile   |   1 +
>  drivers/mfd/intel_soc_pmic_chtwc.c | 244 
> +
>  3 files changed, 256 insertions(+)
>  create mode 100644 drivers/mfd/intel_soc_pmic_chtwc.c
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 55ecdfb..d427a10 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -437,6 +437,17 @@ config INTEL_SOC_PMIC
> thermal, charger and related power management functions
> on these systems.
>  
> +config INTEL_SOC_PMIC_CHTWC
> + tristate "Support for Intel Cherry Trail Whiskey Cove PMIC"
> + depends on ACPI
> + depends on I2C

Nit: Any reason why these can't be on one line?

> + select MFD_CORE
> + select REGMAP_I2C
> + select REGMAP_IRQ
> + help
> +   Select this option to enable support for the Intel Cherry Trail
> +   Whiskey Cove PMIC found on some Intel Cherry Trail systems.
> +
>  config MFD_INTEL_LPSS
>   tristate
>   select COMMON_CLK
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 31ce076..d2ca514 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -209,6 +209,7 @@ obj-$(CONFIG_MFD_SKY81452)+= sky81452.o
>  intel-soc-pmic-objs  := intel_soc_pmic_core.o intel_soc_pmic_crc.o
>  intel-soc-pmic-$(CONFIG_INTEL_PMC_IPC)   += intel_soc_pmic_bxtwc.o
>  obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
> +obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC) += intel_soc_pmic_chtwc.o
>  obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
>  
>  obj-$(CONFIG_MFD_ALTERA_A10SR)   += altera-a10sr.o
> diff --git a/drivers/mfd/intel_soc_pmic_chtwc.c 
> b/drivers/mfd/intel_soc_pmic_chtwc.c
> new file mode 100644
> index 000..50aec44
> --- /dev/null
> +++ b/drivers/mfd/intel_soc_pmic_chtwc.c
> @@ -0,0 +1,244 @@
> +/*
> + * MFD core driver for Intel Cherrytrail Whiskey Cove PMIC
> + * Copyright (C) 2017 Hans de Goede 
> + *
> + * Based on various non upstream patches to support the CHT Whiskey Cove 
> PMIC:
> + * Copyright (C) 2013-2015 Intel Corporation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + */

We have a shortened version of the licence now -- any reason why it
can't be used here?

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* PMIC device registers */
> +#define REG_OFFSET_MASK  GENMASK(7, 0)
> +#define REG_ADDR_MASKGENMASK(15, 8)
> +#define REG_ADDR_SHIFT   8
> +
> +#define CHT_WC_IRQLVL1   0x6e02
> +#define CHT_WC_IRQLVL1_MASK  0x6e0e
> +
> +/* Whiskey Cove PMIC share same ACPI ID between different platforms */
> +#define CHT_WC_HRV   3
> +
> +/* Level 1 IRQs (level 2 IRQs are handled in the child device drivers) */
> +enum {
> + CHT_WC_PWRSRC_IRQ = 0,
> + CHT_WC_THRM_IRQ,
> + CHT_WC_BCU_IRQ,
> + CHT_WC_ADC_IRQ,
> +

Re: [PATCH v2 1/3] mfd: Add Cherry Trail Whiskey Cove PMIC driver

On Mon, 20 Mar 2017, Hans de Goede wrote:

> Add mfd driver for Intel CHT Whiskey Cove PMIC, based on various non
> upstreamed CHT Whiskey Cove PMIC patches.
> 
> This is a somewhat minimal version which adds irqchip support and cells
> for: ACPI PMIC opregion support, the i2c-controller driving the external
> charger irc and the pwrsrc/extcon block.
> 
> Further cells can be added in the future if/when drivers are upstreamed
> for them.
> 
> Cc: Bin Gao 
> Cc: Felipe Balbi 
> Cc: Andy Shevchenko 
> Signed-off-by: Hans de Goede 
> Reviewed-by: Andy Shevchenko 
> ---
> Changes in v2:
> -Since this uses plain mfd and not the intel_soc_pmic stuff give it
>  its own Kconfig and allow this to be built as a module
> -Add missing #include 
> Changes in v3:
> -Drop #include  again, not the right fix for the build errors
> -Error out when the upper byte of the register-address passed to the regmap
>  functions is 0 rather then hardcoding an address in that case
> -Various minor style tweaks / cleanups
> -Move defines of regulator register addresses to intel_pmic_chtwc.c,
>  it is the only place where they are used
> -Drop now empty include/linux/mfd/intel_chtwc.h
> -Rename intel_soc_pmic_chtwc.c to intel_cht_wc.c to match Kconfig option name
> -Add irqchip support
> -Add external charger cell
> -Add pwrsrc cell
> Changes in v4:
> -Use PLATFORM_DEVID_NONE
> ---
>  drivers/mfd/Kconfig|  11 ++
>  drivers/mfd/Makefile   |   1 +
>  drivers/mfd/intel_soc_pmic_chtwc.c | 244 
> +
>  3 files changed, 256 insertions(+)
>  create mode 100644 drivers/mfd/intel_soc_pmic_chtwc.c
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 55ecdfb..d427a10 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -437,6 +437,17 @@ config INTEL_SOC_PMIC
> thermal, charger and related power management functions
> on these systems.
>  
> +config INTEL_SOC_PMIC_CHTWC
> + tristate "Support for Intel Cherry Trail Whiskey Cove PMIC"
> + depends on ACPI
> + depends on I2C

Nit: Any reason why these can't be on one line?

> + select MFD_CORE
> + select REGMAP_I2C
> + select REGMAP_IRQ
> + help
> +   Select this option to enable support for the Intel Cherry Trail
> +   Whiskey Cove PMIC found on some Intel Cherry Trail systems.
> +
>  config MFD_INTEL_LPSS
>   tristate
>   select COMMON_CLK
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 31ce076..d2ca514 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -209,6 +209,7 @@ obj-$(CONFIG_MFD_SKY81452)+= sky81452.o
>  intel-soc-pmic-objs  := intel_soc_pmic_core.o intel_soc_pmic_crc.o
>  intel-soc-pmic-$(CONFIG_INTEL_PMC_IPC)   += intel_soc_pmic_bxtwc.o
>  obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
> +obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC) += intel_soc_pmic_chtwc.o
>  obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
>  
>  obj-$(CONFIG_MFD_ALTERA_A10SR)   += altera-a10sr.o
> diff --git a/drivers/mfd/intel_soc_pmic_chtwc.c 
> b/drivers/mfd/intel_soc_pmic_chtwc.c
> new file mode 100644
> index 000..50aec44
> --- /dev/null
> +++ b/drivers/mfd/intel_soc_pmic_chtwc.c
> @@ -0,0 +1,244 @@
> +/*
> + * MFD core driver for Intel Cherrytrail Whiskey Cove PMIC
> + * Copyright (C) 2017 Hans de Goede 
> + *
> + * Based on various non upstream patches to support the CHT Whiskey Cove 
> PMIC:
> + * Copyright (C) 2013-2015 Intel Corporation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + */

We have a shortened version of the licence now -- any reason why it
can't be used here?

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* PMIC device registers */
> +#define REG_OFFSET_MASK  GENMASK(7, 0)
> +#define REG_ADDR_MASKGENMASK(15, 8)
> +#define REG_ADDR_SHIFT   8
> +
> +#define CHT_WC_IRQLVL1   0x6e02
> +#define CHT_WC_IRQLVL1_MASK  0x6e0e
> +
> +/* Whiskey Cove PMIC share same ACPI ID between different platforms */
> +#define CHT_WC_HRV   3
> +
> +/* Level 1 IRQs (level 2 IRQs are handled in the child device drivers) */
> +enum {
> + CHT_WC_PWRSRC_IRQ = 0,
> + CHT_WC_THRM_IRQ,
> + CHT_WC_BCU_IRQ,
> + CHT_WC_ADC_IRQ,
> + CHT_WC_EXT_CHGR_IRQ,
> + CHT_WC_GPIO_IRQ,
> + /* There is no irq 6 */
> + CHT_WC_CRIT_IRQ = 7,
> +};
> +
> +static struct resource cht_wc_pwrsrc_resources[] = {
> +

Re: kvm: BUG in pte_list_remove

On Mon, Nov 14, 2016 at 10:43 AM, Dmitry Vyukov  wrote:
> On Mon, Nov 14, 2016 at 10:34 AM, Paolo Bonzini  wrote:
>>
>>
>> On 14/11/2016 10:03, Dmitry Vyukov wrote:
>>> Paolo,
>>> can you please also commit this test to tools/testing? We are
>>> frustrated by the situation that we reported hundreds of bugs with
>>> reproducers, but exactly 0 kernel regression tests were added.
>>
>> Ok.  Last time I only put the reproducers in commit messages.  We can
>> look into adding some KVM regression testing to tools/testing this time.
>
>
> Tests in commit messages will be lost.
> Growing a base of kernel regression tests will be great.
>
>
>>> On Sun, Nov 13, 2016 at 5:00 PM, Paolo Bonzini  wrote:
 Beautified source code:

 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 

 long r[16];

 int main()
 {
   void *p = valloc(0x4000);

   r[2] = open("/dev/kvm", 0);
   r[3] = ioctl(r[2], KVM_CREATE_VM, 0x0ul);

   uint64_t addr = 0xf000;
   ioctl(r[3], KVM_SET_IDENTITY_MAP_ADDR, );
   r[6] = ioctl(r[3], KVM_CREATE_VCPU, 0x0ul);
   ioctl(r[3], KVM_SET_TSS_ADDR, 0x0ul);
   ioctl(r[6], KVM_RUN, 0);
   ioctl(r[6], KVM_RUN, 0);

   struct kvm_userspace_memory_region mr = {
   .slot = 0,
   .flags = KVM_MEM_LOG_DIRTY_PAGES,
   .guest_phys_addr = 0xf000,
   .memory_size = 0x4000,
   .userspace_addr = (uintptr_t) p
   };
   ioctl(r[3], KVM_SET_USER_MEMORY_REGION, );
   return 0;
 }


This is still happens on a recent 093b995e3b55a0ae0670226ddfcb05bfbf0099ae:


[ cut here ]
kernel BUG at arch/x86/kvm/mmu.c:1157!
invalid opcode:  [#1] SMP KASAN
Modules linked in:
CPU: 0 PID: 2966 Comm: a.out Not tainted 4.11.0-rc3+ #365
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 88006432a5c0 task.stack: 880064e48000
RIP: 0010:pte_list_remove+0x3ae/0x3c0 arch/x86/kvm/mmu.c:1156
RSP: 0018:880064e4eda0 EFLAGS: 00010282
RAX: 0028 RBX: 88006ac72180 RCX: 
RDX: 0028 RSI: 11000c9c9d72 RDI: ed000c9c9da8
RBP: 880064e4ede0 R08: ed000da03dae R09: ed000da03dae
R10: 0001 R11: ed000da03dad R12: 000f
R13:  R14: 88006bcd8ec0 R15: 88006bcd8ee8
FS:  () GS:88006d00() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2:  CR3: 6870b000 CR4: 001426f0
Call Trace:
 rmap_remove arch/x86/kvm/mmu.c:1233 [inline]
 drop_spte+0x16c/0x270 arch/x86/kvm/mmu.c:1315
 mmu_page_zap_pte+0x223/0x350 arch/x86/kvm/mmu.c:2427
 kvm_mmu_page_unlink_children arch/x86/kvm/mmu.c:2449 [inline]
 kvm_mmu_prepare_zap_page+0x1bb/0x1260 arch/x86/kvm/mmu.c:2493
 kvm_zap_obsolete_pages arch/x86/kvm/mmu.c:5123 [inline]
 kvm_mmu_invalidate_zap_all_pages+0x4a8/0x680 arch/x86/kvm/mmu.c:5164
 kvm_arch_flush_shadow_all+0x15/0x20 arch/x86/kvm/x86.c:8370
 kvm_mmu_notifier_release+0x71/0xb0
arch/x86/kvm/../../../virt/kvm/kvm_main.c:472
 __mmu_notifier_release+0x1e5/0x6b0 mm/mmu_notifier.c:75
 mmu_notifier_release include/linux/mmu_notifier.h:235 [inline]
 exit_mmap+0x3a3/0x470 mm/mmap.c:2941
 __mmput kernel/fork.c:894 [inline]
 mmput+0x25e/0x790 kernel/fork.c:916
 exit_mm kernel/exit.c:558 [inline]
 do_exit+0xa51/0x26d0 kernel/exit.c:866
 do_group_exit+0x149/0x400 kernel/exit.c:983
 SYSC_exit_group kernel/exit.c:994 [inline]
 SyS_exit_group+0x1d/0x20 kernel/exit.c:992
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x433609
RSP: 002b:7ffdbe967178 EFLAGS: 0246 ORIG_RAX: 00e7
RAX: ffda RBX:  RCX: 00433609
RDX:  RSI:  RDI: 
RBP: 0086 R08: 003c R09: 00e7
R10: ffc0 R11: 0246 R12: 00d7fbb0
R13: 0001b411 R14: 2710 R15: 006c08b8
Code: 99 f9 5d 00 48 8b 75 d0 48 c7 c7 00 4a 42 84 e8 9c 13 72 00 0f
0b e8 82 f9 5d 00 48 8b 75 d0 48 c7 c7 c0 49 42 84 e8 85 13 72 00 <0f>
0b 4c 89 ef e8 78 14 8c 00 e9 01 fe ff ff 0f 1f 00 55 48 89
RIP: pte_list_remove+0x3ae/0x3c0 arch/x86/kvm/mmu.c:1156 RSP: 880064e4eda0
---[ end trace 2cf22c8ade550ee0 ]---


#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

long r[16];

int main()
{
  void *p = valloc(0x4000);

  r[2] = open("/dev/kvm", 0);
  r[3] = ioctl(r[2], KVM_CREATE_VM, 0x0ul);

  uint64_t addr = 0xf000;
  ioctl(r[3], KVM_SET_IDENTITY_MAP_ADDR, );
  r[6] = ioctl(r[3], KVM_CREATE_VCPU, 0x0ul);
  ioctl(r[3],

Re: kvm: BUG in pte_list_remove

On Mon, Nov 14, 2016 at 10:43 AM, Dmitry Vyukov  wrote:
> On Mon, Nov 14, 2016 at 10:34 AM, Paolo Bonzini  wrote:
>>
>>
>> On 14/11/2016 10:03, Dmitry Vyukov wrote:
>>> Paolo,
>>> can you please also commit this test to tools/testing? We are
>>> frustrated by the situation that we reported hundreds of bugs with
>>> reproducers, but exactly 0 kernel regression tests were added.
>>
>> Ok.  Last time I only put the reproducers in commit messages.  We can
>> look into adding some KVM regression testing to tools/testing this time.
>
>
> Tests in commit messages will be lost.
> Growing a base of kernel regression tests will be great.
>
>
>>> On Sun, Nov 13, 2016 at 5:00 PM, Paolo Bonzini  wrote:
 Beautified source code:

 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 

 long r[16];

 int main()
 {
   void *p = valloc(0x4000);

   r[2] = open("/dev/kvm", 0);
   r[3] = ioctl(r[2], KVM_CREATE_VM, 0x0ul);

   uint64_t addr = 0xf000;
   ioctl(r[3], KVM_SET_IDENTITY_MAP_ADDR, );
   r[6] = ioctl(r[3], KVM_CREATE_VCPU, 0x0ul);
   ioctl(r[3], KVM_SET_TSS_ADDR, 0x0ul);
   ioctl(r[6], KVM_RUN, 0);
   ioctl(r[6], KVM_RUN, 0);

   struct kvm_userspace_memory_region mr = {
   .slot = 0,
   .flags = KVM_MEM_LOG_DIRTY_PAGES,
   .guest_phys_addr = 0xf000,
   .memory_size = 0x4000,
   .userspace_addr = (uintptr_t) p
   };
   ioctl(r[3], KVM_SET_USER_MEMORY_REGION, );
   return 0;
 }


This is still happens on a recent 093b995e3b55a0ae0670226ddfcb05bfbf0099ae:


[ cut here ]
kernel BUG at arch/x86/kvm/mmu.c:1157!
invalid opcode:  [#1] SMP KASAN
Modules linked in:
CPU: 0 PID: 2966 Comm: a.out Not tainted 4.11.0-rc3+ #365
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 88006432a5c0 task.stack: 880064e48000
RIP: 0010:pte_list_remove+0x3ae/0x3c0 arch/x86/kvm/mmu.c:1156
RSP: 0018:880064e4eda0 EFLAGS: 00010282
RAX: 0028 RBX: 88006ac72180 RCX: 
RDX: 0028 RSI: 11000c9c9d72 RDI: ed000c9c9da8
RBP: 880064e4ede0 R08: ed000da03dae R09: ed000da03dae
R10: 0001 R11: ed000da03dad R12: 000f
R13:  R14: 88006bcd8ec0 R15: 88006bcd8ee8
FS:  () GS:88006d00() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2:  CR3: 6870b000 CR4: 001426f0
Call Trace:
 rmap_remove arch/x86/kvm/mmu.c:1233 [inline]
 drop_spte+0x16c/0x270 arch/x86/kvm/mmu.c:1315
 mmu_page_zap_pte+0x223/0x350 arch/x86/kvm/mmu.c:2427
 kvm_mmu_page_unlink_children arch/x86/kvm/mmu.c:2449 [inline]
 kvm_mmu_prepare_zap_page+0x1bb/0x1260 arch/x86/kvm/mmu.c:2493
 kvm_zap_obsolete_pages arch/x86/kvm/mmu.c:5123 [inline]
 kvm_mmu_invalidate_zap_all_pages+0x4a8/0x680 arch/x86/kvm/mmu.c:5164
 kvm_arch_flush_shadow_all+0x15/0x20 arch/x86/kvm/x86.c:8370
 kvm_mmu_notifier_release+0x71/0xb0
arch/x86/kvm/../../../virt/kvm/kvm_main.c:472
 __mmu_notifier_release+0x1e5/0x6b0 mm/mmu_notifier.c:75
 mmu_notifier_release include/linux/mmu_notifier.h:235 [inline]
 exit_mmap+0x3a3/0x470 mm/mmap.c:2941
 __mmput kernel/fork.c:894 [inline]
 mmput+0x25e/0x790 kernel/fork.c:916
 exit_mm kernel/exit.c:558 [inline]
 do_exit+0xa51/0x26d0 kernel/exit.c:866
 do_group_exit+0x149/0x400 kernel/exit.c:983
 SYSC_exit_group kernel/exit.c:994 [inline]
 SyS_exit_group+0x1d/0x20 kernel/exit.c:992
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x433609
RSP: 002b:7ffdbe967178 EFLAGS: 0246 ORIG_RAX: 00e7
RAX: ffda RBX:  RCX: 00433609
RDX:  RSI:  RDI: 
RBP: 0086 R08: 003c R09: 00e7
R10: ffc0 R11: 0246 R12: 00d7fbb0
R13: 0001b411 R14: 2710 R15: 006c08b8
Code: 99 f9 5d 00 48 8b 75 d0 48 c7 c7 00 4a 42 84 e8 9c 13 72 00 0f
0b e8 82 f9 5d 00 48 8b 75 d0 48 c7 c7 c0 49 42 84 e8 85 13 72 00 <0f>
0b 4c 89 ef e8 78 14 8c 00 e9 01 fe ff ff 0f 1f 00 55 48 89
RIP: pte_list_remove+0x3ae/0x3c0 arch/x86/kvm/mmu.c:1156 RSP: 880064e4eda0
---[ end trace 2cf22c8ade550ee0 ]---


#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

long r[16];

int main()
{
  void *p = valloc(0x4000);

  r[2] = open("/dev/kvm", 0);
  r[3] = ioctl(r[2], KVM_CREATE_VM, 0x0ul);

  uint64_t addr = 0xf000;
  ioctl(r[3], KVM_SET_IDENTITY_MAP_ADDR, );
  r[6] = ioctl(r[3], KVM_CREATE_VCPU, 0x0ul);
  ioctl(r[3], KVM_SET_TSS_ADDR, 0x0ul);
  ioctl(r[6], KVM_RUN, 0);
  ioctl(r[6],

Re: [PATCH] tpm2: fix off-by-one comparison and out-of-bounds read error

2017-03-23 Thread Dan Carpenter

On Thu, Mar 23, 2017 at 05:53:58PM +0200, Jarkko Sakkinen wrote:
> On Wed, Mar 22, 2017 at 04:12:49PM +0300, Dan Carpenter wrote:
> > On Wed, Mar 22, 2017 at 11:45:37AM +, Colin Ian King wrote:
> > > On 22/03/17 11:42, Jarkko Sakkinen wrote:
> > > > On Mon, Mar 20, 2017 at 02:23:36PM +, Colin King wrote:
> > > >> From: Colin Ian King 
> > > >>
> > > >> The comparison of an out of range index into space->context_tbl is
> > > >> off-by-one and should be using >= rather than > in the comparison.
> > > >>
> > > >> Detected by CoverityScan, CID#1419694 ("Out-of-bounds read")
> > > >>
> > > >> Fixes: 849246e7ce9ce ("tpm2: add session handle context saving and 
> > > >> restoring to the space code")
> > > >> Signed-off-by: Colin Ian King 
> > > >> ---
> > > >>  drivers/char/tpm/tpm2-space.c | 2 +-
> > > >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >>
> > > >> diff --git a/drivers/char/tpm/tpm2-space.c 
> > > >> b/drivers/char/tpm/tpm2-space.c
> > > >> index d36d81e07076..009934269514 100644
> > > >> --- a/drivers/char/tpm/tpm2-space.c
> > > >> +++ b/drivers/char/tpm/tpm2-space.c
> > > >> @@ -229,7 +229,7 @@ static bool tpm2_map_to_phandle(struct tpm_space 
> > > >> *space, void *handle)
> > > >>int i;
> > > >>  
> > > >>i = 0xFF - (vhandle & 0xFF);
> > > >> -  if (i > ARRAY_SIZE(space->context_tbl) || 
> > > >> !space->context_tbl[i])
> > > >> +  if (i >= ARRAY_SIZE(space->context_tbl) || 
> > > >> !space->context_tbl[i])
> > > >>return false;
> > > >>  
> > > >>phandle = space->context_tbl[i];
> > > >> -- 
> > > >> 2.11.0
> > > > 
> > > > Thanks. If you don't mind, I would squash this to that patch?
> > > > 
> > > > /Jarkko
> > > > 
> > > Sure squash it, and maybe add a Reported-by: Colin Ian King
> > >  if that's OK with you.
> > 
> > Reported-by isn't really correct though...  We should have a Fixes-from:
> > tag for squashed fixes.
> > 
> > regards,
> > dan carpenter
> 
> Hmm... Maybe so depending on how you interpret Reported-by but
> Fixes-from is not something that is used at the moment, is it?

No, but we should create it.

regards,
dan carpenter

Re: [PATCH] tpm2: fix off-by-one comparison and out-of-bounds read error

2017-03-23 Thread Dan Carpenter

On Thu, Mar 23, 2017 at 05:53:58PM +0200, Jarkko Sakkinen wrote:
> On Wed, Mar 22, 2017 at 04:12:49PM +0300, Dan Carpenter wrote:
> > On Wed, Mar 22, 2017 at 11:45:37AM +, Colin Ian King wrote:
> > > On 22/03/17 11:42, Jarkko Sakkinen wrote:
> > > > On Mon, Mar 20, 2017 at 02:23:36PM +, Colin King wrote:
> > > >> From: Colin Ian King 
> > > >>
> > > >> The comparison of an out of range index into space->context_tbl is
> > > >> off-by-one and should be using >= rather than > in the comparison.
> > > >>
> > > >> Detected by CoverityScan, CID#1419694 ("Out-of-bounds read")
> > > >>
> > > >> Fixes: 849246e7ce9ce ("tpm2: add session handle context saving and 
> > > >> restoring to the space code")
> > > >> Signed-off-by: Colin Ian King 
> > > >> ---
> > > >>  drivers/char/tpm/tpm2-space.c | 2 +-
> > > >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >>
> > > >> diff --git a/drivers/char/tpm/tpm2-space.c 
> > > >> b/drivers/char/tpm/tpm2-space.c
> > > >> index d36d81e07076..009934269514 100644
> > > >> --- a/drivers/char/tpm/tpm2-space.c
> > > >> +++ b/drivers/char/tpm/tpm2-space.c
> > > >> @@ -229,7 +229,7 @@ static bool tpm2_map_to_phandle(struct tpm_space 
> > > >> *space, void *handle)
> > > >>int i;
> > > >>  
> > > >>i = 0xFF - (vhandle & 0xFF);
> > > >> -  if (i > ARRAY_SIZE(space->context_tbl) || 
> > > >> !space->context_tbl[i])
> > > >> +  if (i >= ARRAY_SIZE(space->context_tbl) || 
> > > >> !space->context_tbl[i])
> > > >>return false;
> > > >>  
> > > >>phandle = space->context_tbl[i];
> > > >> -- 
> > > >> 2.11.0
> > > > 
> > > > Thanks. If you don't mind, I would squash this to that patch?
> > > > 
> > > > /Jarkko
> > > > 
> > > Sure squash it, and maybe add a Reported-by: Colin Ian King
> > >  if that's OK with you.
> > 
> > Reported-by isn't really correct though...  We should have a Fixes-from:
> > tag for squashed fixes.
> > 
> > regards,
> > dan carpenter
> 
> Hmm... Maybe so depending on how you interpret Reported-by but
> Fixes-from is not something that is used at the moment, is it?

No, but we should create it.

regards,
dan carpenter

Re: [REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for virtqueues") causes crashes in guest

2017-03-23 Thread Michael S. Tsirkin

On Thu, Mar 23, 2017 at 03:19:07PM +, Richard W.M. Jones wrote:
> On Thu, Mar 23, 2017 at 01:13:50PM +0800, Jason Wang wrote:
> > >From 312859b596e83a2164a8430343d31fce2a5ad808 Mon Sep 17 00:00:00 2001
> > From: Jason Wang 
> > Date: Thu, 23 Mar 2017 13:07:16 +0800
> > Subject: [PATCH] virtio_pci: fix out of bound access for msix_names
> > 
> > Signed-off-by: Jason Wang 
> 
> I tested this, and it does appear to fix the crashes in
> vp_modern_find_vqs.  Therefore:
> 
> Tested-by: Richard W.M. Jones 
> 
> Thanks,
> 
> Rich.

I've queued the fix, thanks everyone!

> >  drivers/virtio/virtio_pci_common.c | 9 +
> >  1 file changed, 5 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/virtio/virtio_pci_common.c 
> > b/drivers/virtio/virtio_pci_common.c
> > index df548a6..5905349 100644
> > --- a/drivers/virtio/virtio_pci_common.c
> > +++ b/drivers/virtio/virtio_pci_common.c
> > @@ -147,7 +147,7 @@ static int vp_find_vqs_msix(struct virtio_device *vdev, 
> > unsigned nvqs,
> >  {
> > struct virtio_pci_device *vp_dev = to_vp_device(vdev);
> > const char *name = dev_name(_dev->vdev.dev);
> > -   int i, err = -ENOMEM, allocated_vectors, nvectors;
> > +   int i, j, err = -ENOMEM, allocated_vectors, nvectors;
> > unsigned flags = PCI_IRQ_MSIX;
> > bool shared = false;
> > u16 msix_vec;
> > @@ -212,7 +212,7 @@ static int vp_find_vqs_msix(struct virtio_device *vdev, 
> > unsigned nvqs,
> > if (!vp_dev->msix_vector_map)
> > goto out_disable_config_irq;
> >  
> > -   allocated_vectors = 1; /* vector 0 is the config interrupt */
> > +   allocated_vectors = j = 1; /* vector 0 is the config interrupt */
> > for (i = 0; i < nvqs; ++i) {
> > if (!names[i]) {
> > vqs[i] = NULL;
> > @@ -236,18 +236,19 @@ static int vp_find_vqs_msix(struct virtio_device 
> > *vdev, unsigned nvqs,
> > continue;
> > }
> >  
> > -   snprintf(vp_dev->msix_names[i + 1],
> > +   snprintf(vp_dev->msix_names[j],
> >  sizeof(*vp_dev->msix_names), "%s-%s",
> >  dev_name(_dev->vdev.dev), names[i]);
> > err = request_irq(pci_irq_vector(vp_dev->pci_dev, msix_vec),
> >   vring_interrupt, IRQF_SHARED,
> > - vp_dev->msix_names[i + 1], vqs[i]);
> > + vp_dev->msix_names[j], vqs[i]);
> > if (err) {
> > /* don't free this irq on error */
> > vp_dev->msix_vector_map[i] = VIRTIO_MSI_NO_VECTOR;
> > goto out_remove_vqs;
> > }
> > vp_dev->msix_vector_map[i] = msix_vec;
> > +   j++;
> >  
> > /*
> >  * Use a different vector for each queue if they are available,
> > -- 
> > 2.7.4
> > 
> 
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-builder quickly builds VMs from scratch
> http://libguestfs.org/virt-builder.1.html

Re: [REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for virtqueues") causes crashes in guest

2017-03-23 Thread Michael S. Tsirkin

On Thu, Mar 23, 2017 at 03:19:07PM +, Richard W.M. Jones wrote:
> On Thu, Mar 23, 2017 at 01:13:50PM +0800, Jason Wang wrote:
> > >From 312859b596e83a2164a8430343d31fce2a5ad808 Mon Sep 17 00:00:00 2001
> > From: Jason Wang 
> > Date: Thu, 23 Mar 2017 13:07:16 +0800
> > Subject: [PATCH] virtio_pci: fix out of bound access for msix_names
> > 
> > Signed-off-by: Jason Wang 
> 
> I tested this, and it does appear to fix the crashes in
> vp_modern_find_vqs.  Therefore:
> 
> Tested-by: Richard W.M. Jones 
> 
> Thanks,
> 
> Rich.

I've queued the fix, thanks everyone!

> >  drivers/virtio/virtio_pci_common.c | 9 +
> >  1 file changed, 5 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/virtio/virtio_pci_common.c 
> > b/drivers/virtio/virtio_pci_common.c
> > index df548a6..5905349 100644
> > --- a/drivers/virtio/virtio_pci_common.c
> > +++ b/drivers/virtio/virtio_pci_common.c
> > @@ -147,7 +147,7 @@ static int vp_find_vqs_msix(struct virtio_device *vdev, 
> > unsigned nvqs,
> >  {
> > struct virtio_pci_device *vp_dev = to_vp_device(vdev);
> > const char *name = dev_name(_dev->vdev.dev);
> > -   int i, err = -ENOMEM, allocated_vectors, nvectors;
> > +   int i, j, err = -ENOMEM, allocated_vectors, nvectors;
> > unsigned flags = PCI_IRQ_MSIX;
> > bool shared = false;
> > u16 msix_vec;
> > @@ -212,7 +212,7 @@ static int vp_find_vqs_msix(struct virtio_device *vdev, 
> > unsigned nvqs,
> > if (!vp_dev->msix_vector_map)
> > goto out_disable_config_irq;
> >  
> > -   allocated_vectors = 1; /* vector 0 is the config interrupt */
> > +   allocated_vectors = j = 1; /* vector 0 is the config interrupt */
> > for (i = 0; i < nvqs; ++i) {
> > if (!names[i]) {
> > vqs[i] = NULL;
> > @@ -236,18 +236,19 @@ static int vp_find_vqs_msix(struct virtio_device 
> > *vdev, unsigned nvqs,
> > continue;
> > }
> >  
> > -   snprintf(vp_dev->msix_names[i + 1],
> > +   snprintf(vp_dev->msix_names[j],
> >  sizeof(*vp_dev->msix_names), "%s-%s",
> >  dev_name(_dev->vdev.dev), names[i]);
> > err = request_irq(pci_irq_vector(vp_dev->pci_dev, msix_vec),
> >   vring_interrupt, IRQF_SHARED,
> > - vp_dev->msix_names[i + 1], vqs[i]);
> > + vp_dev->msix_names[j], vqs[i]);
> > if (err) {
> > /* don't free this irq on error */
> > vp_dev->msix_vector_map[i] = VIRTIO_MSI_NO_VECTOR;
> > goto out_remove_vqs;
> > }
> > vp_dev->msix_vector_map[i] = msix_vec;
> > +   j++;
> >  
> > /*
> >  * Use a different vector for each queue if they are available,
> > -- 
> > 2.7.4
> > 
> 
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-builder quickly builds VMs from scratch
> http://libguestfs.org/virt-builder.1.html

Re: [PATCH v2 2/4] mvebu: xp: Add pwm properties to .dtsi files

Hi Ralph,
 
 On sam., mars 18 2017, Ralph Sennhauser  wrote:

It seems that I don't receive the 1st patch of the series.

Also could you refresh my mind to expose why these patchse were not
apply the first time and why we should apply them now?

Thanks,

Gregory


> From: Andrew Lunn 
>
> Add properties to the gpio nodes to allow them to be also used as pwm
> lines.
>
> Signed-off-by: Andrew Lunn 
> URL: https://patchwork.ozlabs.org/patch/427294/
> Signed-off-by: Ralph Sennhauser 
> ---
>  arch/arm/boot/dts/armada-370.dtsi| 10 --
>  arch/arm/boot/dts/armada-xp-mv78230.dtsi | 10 --
>  arch/arm/boot/dts/armada-xp-mv78260.dtsi |  8 ++--
>  arch/arm/boot/dts/armada-xp-mv78460.dtsi | 10 --
>  4 files changed, 30 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/boot/dts/armada-370.dtsi 
> b/arch/arm/boot/dts/armada-370.dtsi
> index cc011c8..aa9fe72 100644
> --- a/arch/arm/boot/dts/armada-370.dtsi
> +++ b/arch/arm/boot/dts/armada-370.dtsi
> @@ -138,24 +138,30 @@
>  
>   gpio0: gpio@18100 {
>   compatible = "marvell,orion-gpio";
> - reg = <0x18100 0x40>;
> + reg = <0x18100 0x40>, <0x181c0 0x08>;
> + reg-names = "gpio", "pwm";
>   ngpios = <32>;
>   gpio-controller;
>   #gpio-cells = <2>;
> + #pwm-cells = <2>;
>   interrupt-controller;
>   #interrupt-cells = <2>;
>   interrupts = <82>, <83>, <84>, <85>;
> + clocks = < 0>;
>   };
>  
>   gpio1: gpio@18140 {
>   compatible = "marvell,orion-gpio";
> - reg = <0x18140 0x40>;
> + reg = <0x18140 0x40>, <0x181c8 0x08>;
> + reg-names = "gpio", "pwm";
>   ngpios = <32>;
>   gpio-controller;
>   #gpio-cells = <2>;
> + #pwm-cells = <2>;
>   interrupt-controller;
>   #interrupt-cells = <2>;
>   interrupts = <87>, <88>, <89>, <90>;
> + clocks = < 0>;
>   };
>  
>   gpio2: gpio@18180 {
> diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi 
> b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
> index 07c5090..fc3934f 100644
> --- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
> +++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
> @@ -203,24 +203,30 @@
>   internal-regs {
>   gpio0: gpio@18100 {
>   compatible = "marvell,orion-gpio";
> - reg = <0x18100 0x40>;
> + reg = <0x18100 0x40>, <0x181c0 0x08>;
> + reg-names = "gpio", "pwm";
>   ngpios = <32>;
>   gpio-controller;
>   #gpio-cells = <2>;
> + #pwm-cells = <2>;
>   interrupt-controller;
>   #interrupt-cells = <2>;
>   interrupts = <82>, <83>, <84>, <85>;
> + clocks = < 0>;
>   };
>  
>   gpio1: gpio@18140 {
>   compatible = "marvell,orion-gpio";
> - reg = <0x18140 0x40>;
> + reg = <0x18140 0x40>, <0x181c8 0x08>;
> + reg-names = "gpio", "pwm";
>   ngpios = <17>;
>   gpio-controller;
>   #gpio-cells = <2>;
> + #pwm-cells = <2>;
>   interrupt-controller;
>   #interrupt-cells = <2>;
>   interrupts = <87>, <88>, <89>;
> + clocks = < 0>;
>   };
>   };
>   };
> diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi 
> b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
> index 64e936a..04dda6a 100644
> --- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
> +++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
> @@ -286,24 +286,28 @@
>   internal-regs {
>   gpio0: gpio@18100 {
>   compatible = "marvell,orion-gpio";
> - reg = <0x18100 0x40>;
> + reg = <0x18100 0x40>, <0x181c0 0x08>;
> +

Re: [PATCH v2 2/4] mvebu: xp: Add pwm properties to .dtsi files

Hi Ralph,
 
 On sam., mars 18 2017, Ralph Sennhauser  wrote:

It seems that I don't receive the 1st patch of the series.

Also could you refresh my mind to expose why these patchse were not
apply the first time and why we should apply them now?

Thanks,

Gregory


> From: Andrew Lunn 
>
> Add properties to the gpio nodes to allow them to be also used as pwm
> lines.
>
> Signed-off-by: Andrew Lunn 
> URL: https://patchwork.ozlabs.org/patch/427294/
> Signed-off-by: Ralph Sennhauser 
> ---
>  arch/arm/boot/dts/armada-370.dtsi| 10 --
>  arch/arm/boot/dts/armada-xp-mv78230.dtsi | 10 --
>  arch/arm/boot/dts/armada-xp-mv78260.dtsi |  8 ++--
>  arch/arm/boot/dts/armada-xp-mv78460.dtsi | 10 --
>  4 files changed, 30 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/boot/dts/armada-370.dtsi 
> b/arch/arm/boot/dts/armada-370.dtsi
> index cc011c8..aa9fe72 100644
> --- a/arch/arm/boot/dts/armada-370.dtsi
> +++ b/arch/arm/boot/dts/armada-370.dtsi
> @@ -138,24 +138,30 @@
>  
>   gpio0: gpio@18100 {
>   compatible = "marvell,orion-gpio";
> - reg = <0x18100 0x40>;
> + reg = <0x18100 0x40>, <0x181c0 0x08>;
> + reg-names = "gpio", "pwm";
>   ngpios = <32>;
>   gpio-controller;
>   #gpio-cells = <2>;
> + #pwm-cells = <2>;
>   interrupt-controller;
>   #interrupt-cells = <2>;
>   interrupts = <82>, <83>, <84>, <85>;
> + clocks = < 0>;
>   };
>  
>   gpio1: gpio@18140 {
>   compatible = "marvell,orion-gpio";
> - reg = <0x18140 0x40>;
> + reg = <0x18140 0x40>, <0x181c8 0x08>;
> + reg-names = "gpio", "pwm";
>   ngpios = <32>;
>   gpio-controller;
>   #gpio-cells = <2>;
> + #pwm-cells = <2>;
>   interrupt-controller;
>   #interrupt-cells = <2>;
>   interrupts = <87>, <88>, <89>, <90>;
> + clocks = < 0>;
>   };
>  
>   gpio2: gpio@18180 {
> diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi 
> b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
> index 07c5090..fc3934f 100644
> --- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
> +++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
> @@ -203,24 +203,30 @@
>   internal-regs {
>   gpio0: gpio@18100 {
>   compatible = "marvell,orion-gpio";
> - reg = <0x18100 0x40>;
> + reg = <0x18100 0x40>, <0x181c0 0x08>;
> + reg-names = "gpio", "pwm";
>   ngpios = <32>;
>   gpio-controller;
>   #gpio-cells = <2>;
> + #pwm-cells = <2>;
>   interrupt-controller;
>   #interrupt-cells = <2>;
>   interrupts = <82>, <83>, <84>, <85>;
> + clocks = < 0>;
>   };
>  
>   gpio1: gpio@18140 {
>   compatible = "marvell,orion-gpio";
> - reg = <0x18140 0x40>;
> + reg = <0x18140 0x40>, <0x181c8 0x08>;
> + reg-names = "gpio", "pwm";
>   ngpios = <17>;
>   gpio-controller;
>   #gpio-cells = <2>;
> + #pwm-cells = <2>;
>   interrupt-controller;
>   #interrupt-cells = <2>;
>   interrupts = <87>, <88>, <89>;
> + clocks = < 0>;
>   };
>   };
>   };
> diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi 
> b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
> index 64e936a..04dda6a 100644
> --- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
> +++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
> @@ -286,24 +286,28 @@
>   internal-regs {
>   gpio0: gpio@18100 {
>   compatible = "marvell,orion-gpio";
> - reg = <0x18100 0x40>;
> + reg = <0x18100 0x40>, <0x181c0 0x08>;
> + reg-names = "gpio", "pwm";
>   ngpios = <32>;
>

Re: [PATCH v1] KVM: kvm_io_bus_unregister_dev() should never fail

On Thu, 23 Mar 2017 17:20:48 +0100
David Hildenbrand  wrote:

> 
> > As this may set kvm->buses[bus_idx] to NULL, don't you also need to
> > guard for bus == NULL in kvm_io_bus_destroy()? (I looked at the code on
> > kvm/queue.)
> 
> very right, so something like this?
> 
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index e1be4b4..ef1aa7f 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -728,7 +728,8 @@ static void kvm_destroy_vm(struct kvm *kvm)
> spin_unlock(_lock);
> kvm_free_irq_routing(kvm);
> for (i = 0; i < KVM_NR_BUSES; i++) {
> -   kvm_io_bus_destroy(kvm->buses[i]);
> +   if (kvm->buses[i])
> +   kvm_io_bus_destroy(kvm->buses[i]);
> kvm->buses[i] = NULL;
> }
> kvm_coalesced_mmio_free(kvm);
> 
> Thanks!
> 
> > 
> >>synchronize_srcu_expedited(>srcu);
> >>kfree(bus);
> >> -  return r;
> >> +  return;
> >>  }
> > 
> 
> 

Either that, or an early exit for bus == NULL in kvm_io_bus_destroy().
(I think the second option is more straightforward.)

Re: [PATCH v1] KVM: kvm_io_bus_unregister_dev() should never fail

On Thu, 23 Mar 2017 17:20:48 +0100
David Hildenbrand  wrote:

> 
> > As this may set kvm->buses[bus_idx] to NULL, don't you also need to
> > guard for bus == NULL in kvm_io_bus_destroy()? (I looked at the code on
> > kvm/queue.)
> 
> very right, so something like this?
> 
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index e1be4b4..ef1aa7f 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -728,7 +728,8 @@ static void kvm_destroy_vm(struct kvm *kvm)
> spin_unlock(_lock);
> kvm_free_irq_routing(kvm);
> for (i = 0; i < KVM_NR_BUSES; i++) {
> -   kvm_io_bus_destroy(kvm->buses[i]);
> +   if (kvm->buses[i])
> +   kvm_io_bus_destroy(kvm->buses[i]);
> kvm->buses[i] = NULL;
> }
> kvm_coalesced_mmio_free(kvm);
> 
> Thanks!
> 
> > 
> >>synchronize_srcu_expedited(>srcu);
> >>kfree(bus);
> >> -  return r;
> >> +  return;
> >>  }
> > 
> 
> 

Either that, or an early exit for bus == NULL in kvm_io_bus_destroy().
(I think the second option is more straightforward.)

Re: kvm: WARNING in mmu_spte_clear_track_bits

On Tue, Mar 14, 2017 at 4:17 PM, Radim Krčmář  wrote:
> 2017-03-12 12:20+0100, Dmitry Vyukov:
>> On Tue, Jan 17, 2017 at 5:00 PM, Dmitry Vyukov  wrote:
>>> On Tue, Jan 17, 2017 at 4:20 PM, Paolo Bonzini  wrote:


 On 13/01/2017 12:15, Dmitry Vyukov wrote:
>
> I've commented out the WARNING for now, but I am seeing lots of
> use-after-free's and rcu stalls involving mmu_spte_clear_track_bits:
>
>
> BUG: KASAN: use-after-free in mmu_spte_clear_track_bits+0x186/0x190
> arch/x86/kvm/mmu.c:597 at addr 880068ae2008
> Read of size 8 by task syz-executor2/16715
> page:ea00016e6170 count:0 mapcount:0 mapping:  (null) 
> index:0x0
> flags: 0x500()
> raw: 0500   
> raw: ea00017ec5a0 ea0001783d48 88006aec5d98
> page dumped because: kasan: bad access detected
> CPU: 2 PID: 16715 Comm: syz-executor2 Not tainted 4.10.0-rc3+ #163
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 
> 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:15 [inline]
>  dump_stack+0x292/0x3a2 lib/dump_stack.c:51
>  kasan_report_error mm/kasan/report.c:213 [inline]
>  kasan_report+0x42d/0x460 mm/kasan/report.c:307
>  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:333
>  mmu_spte_clear_track_bits+0x186/0x190 arch/x86/kvm/mmu.c:597
>  drop_spte+0x24/0x280 arch/x86/kvm/mmu.c:1182
>  kvm_zap_rmapp+0x119/0x260 arch/x86/kvm/mmu.c:1401
>  kvm_unmap_rmapp+0x1d/0x30 arch/x86/kvm/mmu.c:1412
>  kvm_handle_hva_range+0x54a/0x7d0 arch/x86/kvm/mmu.c:1565
>  kvm_unmap_hva_range+0x2e/0x40 arch/x86/kvm/mmu.c:1591
>  kvm_mmu_notifier_invalidate_range_start+0xae/0x140
> arch/x86/kvm/../../../virt/kvm/kvm_main.c:360
>  __mmu_notifier_invalidate_range_start+0x1f8/0x300 mm/mmu_notifier.c:199
>  mmu_notifier_invalidate_range_start include/linux/mmu_notifier.h:282 
> [inline]
>  unmap_vmas+0x14b/0x1b0 mm/memory.c:1368
>  unmap_region+0x2f8/0x560 mm/mmap.c:2460
>  do_munmap+0x7b8/0xfa0 mm/mmap.c:2657
>  mmap_region+0x68f/0x18e0 mm/mmap.c:1612
>  do_mmap+0x6a2/0xd40 mm/mmap.c:1450
>  do_mmap_pgoff include/linux/mm.h:2031 [inline]
>  vm_mmap_pgoff+0x1a9/0x200 mm/util.c:305
>  SYSC_mmap_pgoff mm/mmap.c:1500 [inline]
>  SyS_mmap_pgoff+0x22c/0x5d0 mm/mmap.c:1458
>  SYSC_mmap arch/x86/kernel/sys_x86_64.c:95 [inline]
>  SyS_mmap+0x16/0x20 arch/x86/kernel/sys_x86_64.c:86
>  entry_SYSCALL_64_fastpath+0x1f/0xc2
> RIP: 0033:0x445329
> RSP: 002b:7fb33933cb58 EFLAGS: 0282 ORIG_RAX: 0009
> RAX: ffda RBX: 2000 RCX: 00445329
> RDX: 0003 RSI: 00af1000 RDI: 2000
> RBP: 006dfe90 R08:  R09: 
> R10: 0032 R11: 0282 R12: 0070
> R13: 0006 R14:  R15: 20001000
> Memory state around the buggy address:
>  880068ae1f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  880068ae1f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> 880068ae2000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>   ^
>  880068ae2080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>  880068ae2100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ==

 This could be related to the gfn_to_rmap issues.
>>>
>>>
>>> Humm... That's possible. Potentially I am not seeing any more of
>>> spte-related crashes after I applied the following patch:
>>>
>>> --- a/virt/kvm/kvm_main.c
>>> +++ b/virt/kvm/kvm_main.c
>>> @@ -968,8 +968,7 @@ int __kvm_set_memory_region(struct kvm *kvm,
>>> /* Check for overlaps */
>>> r = -EEXIST;
>>> kvm_for_each_memslot(slot, __kvm_memslots(kvm, as_id)) {
>>> -   if ((slot->id >= KVM_USER_MEM_SLOTS) ||
>>> -   (slot->id == id))
>>> +   if (slot->id == id)
>>> continue;
>>> if (!((base_gfn + npages <= slot->base_gfn) ||
>>>   (base_gfn >= slot->base_gfn + slot->npages)))
>
> I don't understand how this fixes the test: the only memslot that the
> test creates is at memory range 0x0-0x1000, which should not overlap
> with any private memslots.
> There should be just the IDENTITY_PAGETABLE_PRIVATE_MEMSLOT @
> 0xfffbc000ul.
>
> Do you get any ouput with this hunk?
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index a17d78759727..7e1929432232 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -888,6 +888,14 @@ static struct kvm_memslots

Re: kvm: WARNING in mmu_spte_clear_track_bits

On Tue, Mar 14, 2017 at 4:17 PM, Radim Krčmář  wrote:
> 2017-03-12 12:20+0100, Dmitry Vyukov:
>> On Tue, Jan 17, 2017 at 5:00 PM, Dmitry Vyukov  wrote:
>>> On Tue, Jan 17, 2017 at 4:20 PM, Paolo Bonzini  wrote:


 On 13/01/2017 12:15, Dmitry Vyukov wrote:
>
> I've commented out the WARNING for now, but I am seeing lots of
> use-after-free's and rcu stalls involving mmu_spte_clear_track_bits:
>
>
> BUG: KASAN: use-after-free in mmu_spte_clear_track_bits+0x186/0x190
> arch/x86/kvm/mmu.c:597 at addr 880068ae2008
> Read of size 8 by task syz-executor2/16715
> page:ea00016e6170 count:0 mapcount:0 mapping:  (null) 
> index:0x0
> flags: 0x500()
> raw: 0500   
> raw: ea00017ec5a0 ea0001783d48 88006aec5d98
> page dumped because: kasan: bad access detected
> CPU: 2 PID: 16715 Comm: syz-executor2 Not tainted 4.10.0-rc3+ #163
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 
> 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:15 [inline]
>  dump_stack+0x292/0x3a2 lib/dump_stack.c:51
>  kasan_report_error mm/kasan/report.c:213 [inline]
>  kasan_report+0x42d/0x460 mm/kasan/report.c:307
>  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:333
>  mmu_spte_clear_track_bits+0x186/0x190 arch/x86/kvm/mmu.c:597
>  drop_spte+0x24/0x280 arch/x86/kvm/mmu.c:1182
>  kvm_zap_rmapp+0x119/0x260 arch/x86/kvm/mmu.c:1401
>  kvm_unmap_rmapp+0x1d/0x30 arch/x86/kvm/mmu.c:1412
>  kvm_handle_hva_range+0x54a/0x7d0 arch/x86/kvm/mmu.c:1565
>  kvm_unmap_hva_range+0x2e/0x40 arch/x86/kvm/mmu.c:1591
>  kvm_mmu_notifier_invalidate_range_start+0xae/0x140
> arch/x86/kvm/../../../virt/kvm/kvm_main.c:360
>  __mmu_notifier_invalidate_range_start+0x1f8/0x300 mm/mmu_notifier.c:199
>  mmu_notifier_invalidate_range_start include/linux/mmu_notifier.h:282 
> [inline]
>  unmap_vmas+0x14b/0x1b0 mm/memory.c:1368
>  unmap_region+0x2f8/0x560 mm/mmap.c:2460
>  do_munmap+0x7b8/0xfa0 mm/mmap.c:2657
>  mmap_region+0x68f/0x18e0 mm/mmap.c:1612
>  do_mmap+0x6a2/0xd40 mm/mmap.c:1450
>  do_mmap_pgoff include/linux/mm.h:2031 [inline]
>  vm_mmap_pgoff+0x1a9/0x200 mm/util.c:305
>  SYSC_mmap_pgoff mm/mmap.c:1500 [inline]
>  SyS_mmap_pgoff+0x22c/0x5d0 mm/mmap.c:1458
>  SYSC_mmap arch/x86/kernel/sys_x86_64.c:95 [inline]
>  SyS_mmap+0x16/0x20 arch/x86/kernel/sys_x86_64.c:86
>  entry_SYSCALL_64_fastpath+0x1f/0xc2
> RIP: 0033:0x445329
> RSP: 002b:7fb33933cb58 EFLAGS: 0282 ORIG_RAX: 0009
> RAX: ffda RBX: 2000 RCX: 00445329
> RDX: 0003 RSI: 00af1000 RDI: 2000
> RBP: 006dfe90 R08:  R09: 
> R10: 0032 R11: 0282 R12: 0070
> R13: 0006 R14:  R15: 20001000
> Memory state around the buggy address:
>  880068ae1f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  880068ae1f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> 880068ae2000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>   ^
>  880068ae2080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>  880068ae2100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ==

 This could be related to the gfn_to_rmap issues.
>>>
>>>
>>> Humm... That's possible. Potentially I am not seeing any more of
>>> spte-related crashes after I applied the following patch:
>>>
>>> --- a/virt/kvm/kvm_main.c
>>> +++ b/virt/kvm/kvm_main.c
>>> @@ -968,8 +968,7 @@ int __kvm_set_memory_region(struct kvm *kvm,
>>> /* Check for overlaps */
>>> r = -EEXIST;
>>> kvm_for_each_memslot(slot, __kvm_memslots(kvm, as_id)) {
>>> -   if ((slot->id >= KVM_USER_MEM_SLOTS) ||
>>> -   (slot->id == id))
>>> +   if (slot->id == id)
>>> continue;
>>> if (!((base_gfn + npages <= slot->base_gfn) ||
>>>   (base_gfn >= slot->base_gfn + slot->npages)))
>
> I don't understand how this fixes the test: the only memslot that the
> test creates is at memory range 0x0-0x1000, which should not overlap
> with any private memslots.
> There should be just the IDENTITY_PAGETABLE_PRIVATE_MEMSLOT @
> 0xfffbc000ul.
>
> Do you get any ouput with this hunk?
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index a17d78759727..7e1929432232 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -888,6 +888,14 @@ static struct kvm_memslots *install_new_memslots(struct 
> kvm *kvm,
> return

Re: [PATCH] hibernation: on 32-bit x86, disabled in favor of KASLR

2017-03-23 Thread Yu Chen

Hi,

On Thu, Mar 23, 2017 at 9:23 PM, Evgenii Shatokhin
 wrote:
> On 23.03.2017 03:27, Kees Cook wrote:
>>
>> This is a modified revert of commit 65fe935dd238 ("x86/KASLR, x86/power:
>> Remove x86 hibernation restrictions"), since it appears that 32-bit
>> hibernation still can't support KASLR. 64-bit is fine. Since people have
>> been running with KASLR by default on 32-bit since v4.8, this disables
>> hibernation (with a warning). Booting with "nokaslr" will disable KASLR
>> and enable hibernation.
>>
>> Reported-by: Evgenii Shatokhin 
>> Signed-off-by: Kees Cook 
>> Cc: sta...@vger.kernel.org # v4.8+
>
>
> The patch does not work as intended on my system, unfortunately.
>
> I tried the mainline kernel v4.11-rc3 and added this patch. With "nokaslr"
> in the kernel command line, the system fails to hibernate. It complains this
> way in the log:
Could you please send me your kernel config? I've built a 4.11-rc3
image and runs
it on my 32bit laptop and hibernate works on CONFIG_RANDOMIZE_BASE=y

Yu

Re: [PATCH] hibernation: on 32-bit x86, disabled in favor of KASLR

2017-03-23 Thread Yu Chen

Hi,

On Thu, Mar 23, 2017 at 9:23 PM, Evgenii Shatokhin
 wrote:
> On 23.03.2017 03:27, Kees Cook wrote:
>>
>> This is a modified revert of commit 65fe935dd238 ("x86/KASLR, x86/power:
>> Remove x86 hibernation restrictions"), since it appears that 32-bit
>> hibernation still can't support KASLR. 64-bit is fine. Since people have
>> been running with KASLR by default on 32-bit since v4.8, this disables
>> hibernation (with a warning). Booting with "nokaslr" will disable KASLR
>> and enable hibernation.
>>
>> Reported-by: Evgenii Shatokhin 
>> Signed-off-by: Kees Cook 
>> Cc: sta...@vger.kernel.org # v4.8+
>
>
> The patch does not work as intended on my system, unfortunately.
>
> I tried the mainline kernel v4.11-rc3 and added this patch. With "nokaslr"
> in the kernel command line, the system fails to hibernate. It complains this
> way in the log:
Could you please send me your kernel config? I've built a 4.11-rc3
image and runs
it on my 32bit laptop and hibernate works on CONFIG_RANDOMIZE_BASE=y

Yu

[PATCH v6 1/4] irqchip: mips-gic: Add context saving for MIPS_REMOTEPROC

The MIPS remote processor driver allows non-Linux firmware to take
control of and execute on one of the systems VPEs. If that VPE is
brought back under Linux, it is necessary to ensure that all GIC
interrupts are routed and masked as Linux expects them, as the firmware
can have done anything it likes with the GIC configuration (hopefully
just for that VPEs local interrupt sources, but allow for shared
external interrupts as well).

The configuration of shared and local CPU interrupts is maintained and
updated every time a change is made. When a CPU is brought online, the
saved configuration is restored.

These functions will also be useful for restoring GIC context after a
suspend to RAM.

Signed-off-by: Matt Redfearn 
---

Changes in v6:
Rebase on Linux 4.11-rc3

Changes in v5: None
Changes in v4:
Fix inconsistency of Linux CPU number and VP ID

Changes in v3:
Update GIC context saving to use CPU hotplug state machine

Changes in v2:
Add dependence on additional patches to mips-gic in commit log
Incorporate changes from Marc Zynger's review:
- Remove CONTEXT_SAVING define.
- Make saved local state a per-cpu variable
- Make gic_save_* static functions when enabled, and do { } while(0)
  otherwise

 drivers/irqchip/irq-mips-gic.c | 207 +++--
 1 file changed, 200 insertions(+), 7 deletions(-)

diff --git a/drivers/irqchip/irq-mips-gic.c b/drivers/irqchip/irq-mips-gic.c
index 11d12bccc4e7..15c0feb8a52f 100644
--- a/drivers/irqchip/irq-mips-gic.c
+++ b/drivers/irqchip/irq-mips-gic.c
@@ -8,6 +8,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -56,6 +57,79 @@ static unsigned int timer_cpu_pin;
 static struct irq_chip gic_level_irq_controller, gic_edge_irq_controller;
 DECLARE_BITMAP(ipi_resrv, GIC_MAX_INTRS);
 
+#ifdef CONFIG_MIPS_REMOTEPROC
+struct gic_local_state_t {
+   u8 mask;
+};
+
+DEFINE_PER_CPU(struct gic_local_state_t, gic_local_state);
+
+static void gic_save_local_rmask(int cpu, int mask)
+{
+   struct gic_local_state_t *state = per_cpu_ptr(_local_state, cpu);
+
+   state->mask &= mask;
+}
+
+static void gic_save_local_smask(int cpu, int mask)
+{
+   struct gic_local_state_t *state = per_cpu_ptr(_local_state, cpu);
+
+   state->mask |= mask;
+}
+
+static struct {
+   unsigned vpe:   8;
+   unsigned pin:   4;
+
+   unsigned polarity:  1;
+   unsigned trigger:   1;
+   unsigned dual_edge: 1;
+   unsigned mask:  1;
+} gic_shared_state[GIC_MAX_INTRS];
+
+static void gic_save_shared_vpe(int intr, int vpe)
+{
+   gic_shared_state[intr].vpe = vpe;
+}
+
+static void gic_save_shared_pin(int intr, int pin)
+{
+   gic_shared_state[intr].pin = pin;
+}
+
+static void gic_save_shared_polarity(int intr, int polarity)
+{
+   gic_shared_state[intr].polarity = polarity;
+}
+
+static void gic_save_shared_trigger(int intr, int trigger)
+{
+   gic_shared_state[intr].trigger = trigger;
+}
+
+static void gic_save_shared_dual_edge(int intr, int dual_edge)
+{
+   gic_shared_state[intr].dual_edge = dual_edge;
+}
+
+static void gic_save_shared_mask(int intr, int mask)
+{
+   gic_shared_state[intr].mask = mask;
+}
+
+#else
+#define gic_save_local_rmask(cpu, i)   do { } while (0)
+#define gic_save_local_smask(cpu, i)   do { } while (0)
+
+#define gic_save_shared_vpe(i, v)  do { } while (0)
+#define gic_save_shared_pin(i, p)  do { } while (0)
+#define gic_save_shared_polarity(i, p) do { } while (0)
+#define gic_save_shared_trigger(i, t)  do { } while (0)
+#define gic_save_shared_dual_edge(i, d)do { } while (0)
+#define gic_save_shared_mask(i, m) do { } while (0)
+#endif /* CONFIG_MIPS_REMOTEPROC */
+
 static void __gic_irq_dispatch(void);
 
 static inline u32 gic_read32(unsigned int reg)
@@ -105,52 +179,94 @@ static inline void gic_update_bits(unsigned int reg, 
unsigned long mask,
gic_write(reg, regval);
 }
 
-static inline void gic_reset_mask(unsigned int intr)
+static inline void gic_write_reset_mask(unsigned int intr)
 {
gic_write(GIC_REG(SHARED, GIC_SH_RMASK) + GIC_INTR_OFS(intr),
  1ul << GIC_INTR_BIT(intr));
 }
 
-static inline void gic_set_mask(unsigned int intr)
+static inline void gic_reset_mask(unsigned int intr)
+{
+   gic_save_shared_mask(intr, 0);
+   gic_write_reset_mask(intr);
+}
+
+static inline void gic_write_set_mask(unsigned int intr)
 {
gic_write(GIC_REG(SHARED, GIC_SH_SMASK) + GIC_INTR_OFS(intr),
  1ul << GIC_INTR_BIT(intr));
 }
 
-static inline void gic_set_polarity(unsigned int intr, unsigned int pol)
+static inline void gic_set_mask(unsigned int intr)
+{
+   gic_save_shared_mask(intr, 1);
+   gic_write_set_mask(intr);
+}
+
+static inline void gic_write_polarity(unsigned int intr, unsigned int pol)
 {
gic_update_bits(GIC_REG(SHARED, GIC_SH_SET_POLARITY) +
GIC_INTR_OFS(intr), 1ul <<

[PATCH v6 1/4] irqchip: mips-gic: Add context saving for MIPS_REMOTEPROC

The MIPS remote processor driver allows non-Linux firmware to take
control of and execute on one of the systems VPEs. If that VPE is
brought back under Linux, it is necessary to ensure that all GIC
interrupts are routed and masked as Linux expects them, as the firmware
can have done anything it likes with the GIC configuration (hopefully
just for that VPEs local interrupt sources, but allow for shared
external interrupts as well).

The configuration of shared and local CPU interrupts is maintained and
updated every time a change is made. When a CPU is brought online, the
saved configuration is restored.

These functions will also be useful for restoring GIC context after a
suspend to RAM.

Signed-off-by: Matt Redfearn 
---

Changes in v6:
Rebase on Linux 4.11-rc3

Changes in v5: None
Changes in v4:
Fix inconsistency of Linux CPU number and VP ID

Changes in v3:
Update GIC context saving to use CPU hotplug state machine

Changes in v2:
Add dependence on additional patches to mips-gic in commit log
Incorporate changes from Marc Zynger's review:
- Remove CONTEXT_SAVING define.
- Make saved local state a per-cpu variable
- Make gic_save_* static functions when enabled, and do { } while(0)
  otherwise

 drivers/irqchip/irq-mips-gic.c | 207 +++--
 1 file changed, 200 insertions(+), 7 deletions(-)

diff --git a/drivers/irqchip/irq-mips-gic.c b/drivers/irqchip/irq-mips-gic.c
index 11d12bccc4e7..15c0feb8a52f 100644
--- a/drivers/irqchip/irq-mips-gic.c
+++ b/drivers/irqchip/irq-mips-gic.c
@@ -8,6 +8,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -56,6 +57,79 @@ static unsigned int timer_cpu_pin;
 static struct irq_chip gic_level_irq_controller, gic_edge_irq_controller;
 DECLARE_BITMAP(ipi_resrv, GIC_MAX_INTRS);
 
+#ifdef CONFIG_MIPS_REMOTEPROC
+struct gic_local_state_t {
+   u8 mask;
+};
+
+DEFINE_PER_CPU(struct gic_local_state_t, gic_local_state);
+
+static void gic_save_local_rmask(int cpu, int mask)
+{
+   struct gic_local_state_t *state = per_cpu_ptr(_local_state, cpu);
+
+   state->mask &= mask;
+}
+
+static void gic_save_local_smask(int cpu, int mask)
+{
+   struct gic_local_state_t *state = per_cpu_ptr(_local_state, cpu);
+
+   state->mask |= mask;
+}
+
+static struct {
+   unsigned vpe:   8;
+   unsigned pin:   4;
+
+   unsigned polarity:  1;
+   unsigned trigger:   1;
+   unsigned dual_edge: 1;
+   unsigned mask:  1;
+} gic_shared_state[GIC_MAX_INTRS];
+
+static void gic_save_shared_vpe(int intr, int vpe)
+{
+   gic_shared_state[intr].vpe = vpe;
+}
+
+static void gic_save_shared_pin(int intr, int pin)
+{
+   gic_shared_state[intr].pin = pin;
+}
+
+static void gic_save_shared_polarity(int intr, int polarity)
+{
+   gic_shared_state[intr].polarity = polarity;
+}
+
+static void gic_save_shared_trigger(int intr, int trigger)
+{
+   gic_shared_state[intr].trigger = trigger;
+}
+
+static void gic_save_shared_dual_edge(int intr, int dual_edge)
+{
+   gic_shared_state[intr].dual_edge = dual_edge;
+}
+
+static void gic_save_shared_mask(int intr, int mask)
+{
+   gic_shared_state[intr].mask = mask;
+}
+
+#else
+#define gic_save_local_rmask(cpu, i)   do { } while (0)
+#define gic_save_local_smask(cpu, i)   do { } while (0)
+
+#define gic_save_shared_vpe(i, v)  do { } while (0)
+#define gic_save_shared_pin(i, p)  do { } while (0)
+#define gic_save_shared_polarity(i, p) do { } while (0)
+#define gic_save_shared_trigger(i, t)  do { } while (0)
+#define gic_save_shared_dual_edge(i, d)do { } while (0)
+#define gic_save_shared_mask(i, m) do { } while (0)
+#endif /* CONFIG_MIPS_REMOTEPROC */
+
 static void __gic_irq_dispatch(void);
 
 static inline u32 gic_read32(unsigned int reg)
@@ -105,52 +179,94 @@ static inline void gic_update_bits(unsigned int reg, 
unsigned long mask,
gic_write(reg, regval);
 }
 
-static inline void gic_reset_mask(unsigned int intr)
+static inline void gic_write_reset_mask(unsigned int intr)
 {
gic_write(GIC_REG(SHARED, GIC_SH_RMASK) + GIC_INTR_OFS(intr),
  1ul << GIC_INTR_BIT(intr));
 }
 
-static inline void gic_set_mask(unsigned int intr)
+static inline void gic_reset_mask(unsigned int intr)
+{
+   gic_save_shared_mask(intr, 0);
+   gic_write_reset_mask(intr);
+}
+
+static inline void gic_write_set_mask(unsigned int intr)
 {
gic_write(GIC_REG(SHARED, GIC_SH_SMASK) + GIC_INTR_OFS(intr),
  1ul << GIC_INTR_BIT(intr));
 }
 
-static inline void gic_set_polarity(unsigned int intr, unsigned int pol)
+static inline void gic_set_mask(unsigned int intr)
+{
+   gic_save_shared_mask(intr, 1);
+   gic_write_set_mask(intr);
+}
+
+static inline void gic_write_polarity(unsigned int intr, unsigned int pol)
 {
gic_update_bits(GIC_REG(SHARED, GIC_SH_SET_POLARITY) +
GIC_INTR_OFS(intr), 1ul << GIC_INTR_BIT(intr),

[PATCH v6 4/4] MIPS: Deprecate VPE Loader

The MIPS remote processor driver (CONFIG_MIPS_REMOTEPROC) provides a
more standard mechanism for using one or more VPs as coprocessors
running separate firmware.

Here we deprecate this mechanism before it is removed.

Signed-off-by: Matt Redfearn 
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/mips/Kconfig | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 6cdc23da8761..dbec6893c6e7 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -2303,7 +2303,7 @@ config MIPSR2_TO_R6_EMULATOR
  final kernel image.
 
 config MIPS_VPE_LOADER
-   bool "VPE loader support."
+   bool "VPE loader support (DEPRECATED)"
depends on SYS_SUPPORTS_MULTITHREADING && MODULES
select CPU_MIPSR2_IRQ_VI
select CPU_MIPSR2_IRQ_EI
@@ -2312,6 +2312,9 @@ config MIPS_VPE_LOADER
  Includes a loader for loading an elf relocatable object
  onto another VPE and running it.
 
+ Unless you have a specific need, you should use CONFIG_MIPS_REMOTEPROC
+  instead of this.
+
 config MIPS_VPE_LOADER_CMP
bool
default "y"
-- 
2.7.4

[PATCH v6 4/4] MIPS: Deprecate VPE Loader

The MIPS remote processor driver (CONFIG_MIPS_REMOTEPROC) provides a
more standard mechanism for using one or more VPs as coprocessors
running separate firmware.

Here we deprecate this mechanism before it is removed.

Signed-off-by: Matt Redfearn 
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/mips/Kconfig | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 6cdc23da8761..dbec6893c6e7 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -2303,7 +2303,7 @@ config MIPSR2_TO_R6_EMULATOR
  final kernel image.
 
 config MIPS_VPE_LOADER
-   bool "VPE loader support."
+   bool "VPE loader support (DEPRECATED)"
depends on SYS_SUPPORTS_MULTITHREADING && MODULES
select CPU_MIPSR2_IRQ_VI
select CPU_MIPSR2_IRQ_EI
@@ -2312,6 +2312,9 @@ config MIPS_VPE_LOADER
  Includes a loader for loading an elf relocatable object
  onto another VPE and running it.
 
+ Unless you have a specific need, you should use CONFIG_MIPS_REMOTEPROC
+  instead of this.
+
 config MIPS_VPE_LOADER_CMP
bool
default "y"
-- 
2.7.4

[PATCH v6 2/4] MIPS: CPS: Add VP(E) stealing

From: Lisa Parratt 

VP(E) stealing provides a mechanism for removing an offline Virtual
Processor from the Linux kernel such that it is available to run bare
metal code.
Once the CPU has been offlined from Linux, the CPU can be given a task
to run via mips_cps_steal_cpu_and_execute(). The CPU is removed from the
cpu_present mask and is set up to execute from address entry_fn. Stack
space is assigned via the tsk task_struct so that C initialisation code
may be used.
To return the CPU back to Linux control, mips_cps_halt_and_return_cpu
will arrange to halt the CPU and return it to the cpu_present mask. It
is then available to be brought online again via CPU hotplug.

This mechanism is used by the MIPS remote processor driver to allow
CPUs within the system to execute bare metal code, not under control of
the kernel.

Signed-off-by: Lisa Parratt 
Signed-off-by: Matt Redfearn 
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/mips/Kconfig   |   7 ++
 arch/mips/include/asm/smp-cps.h |   8 ++
 arch/mips/kernel/smp-cps.c  | 162 ++--
 arch/mips/kernel/smp.c  |  12 +++
 4 files changed, 182 insertions(+), 7 deletions(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index a008a9f03072..6cdc23da8761 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -2381,6 +2381,13 @@ config MIPS_CPS
  no external assistance. It is safe to enable this when hardware
  support is unavailable.
 
+config MIPS_CPU_STEAL
+   bool "VPE stealing"
+   depends on HOTPLUG_CPU && MIPS_CPS
+   help
+ Select this is you wish to be able to run bare metal code on offline
+ VPEs.
+
 config MIPS_CPS_PM
depends on MIPS_CPS
select MIPS_CPC
diff --git a/arch/mips/include/asm/smp-cps.h b/arch/mips/include/asm/smp-cps.h
index 2ae1f61a4a95..5cab043d7e6f 100644
--- a/arch/mips/include/asm/smp-cps.h
+++ b/arch/mips/include/asm/smp-cps.h
@@ -34,6 +34,14 @@ extern void mips_cps_boot_vpes(struct core_boot_config *cfg, 
unsigned vpe);
 extern void mips_cps_pm_save(void);
 extern void mips_cps_pm_restore(void);
 
+#ifdef CONFIG_MIPS_CPU_STEAL
+
+extern int mips_cps_steal_cpu_and_execute(unsigned int cpu, void *entry_fn,
+ struct task_struct *tsk);
+extern int mips_cps_halt_and_return_cpu(unsigned int cpu);
+
+#endif /* CONFIG_MIPS_CPU_STEAL */
+
 #ifdef CONFIG_MIPS_CPS
 
 extern bool mips_cps_smp_in_use(void);
diff --git a/arch/mips/kernel/smp-cps.c b/arch/mips/kernel/smp-cps.c
index 6d45f05538c8..3a1e08a0c327 100644
--- a/arch/mips/kernel/smp-cps.c
+++ b/arch/mips/kernel/smp-cps.c
@@ -8,6 +8,7 @@
  * option) any later version.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -40,6 +41,31 @@ static int __init setup_nothreads(char *s)
 }
 early_param("nothreads", setup_nothreads);
 
+#ifdef CONFIG_MIPS_CPU_STEAL
+struct cpumask cpu_stolen_mask;
+
+static inline bool cpu_stolen(int cpu)
+{
+   return cpumask_test_cpu(cpu, _stolen_mask);
+}
+
+static inline void set_cpu_stolen(int cpu, bool state)
+{
+   if (state)
+   cpumask_set_cpu(cpu, _stolen_mask);
+   else
+   cpumask_clear_cpu(cpu, _stolen_mask);
+}
+#else
+static inline bool cpu_stolen(int cpu)
+{
+   return false;
+}
+
+static inline void set_cpu_stolen(int cpu, bool state) { }
+
+#endif /* CONFIG_MIPS_CPU_STEAL */
+
 static unsigned core_vpe_count(unsigned core)
 {
unsigned cfg;
@@ -110,6 +136,10 @@ static void __init cps_smp_setup(void)
write_gcr_bev_base(core_entry);
}
 
+#ifdef CONFIG_MIPS_CPU_STEAL
+   cpumask_clear(_stolen_mask);
+#endif /* CONFIG_MIPS_CPU_STEAL */
+
 #ifdef CONFIG_MIPS_MT_FPAFF
/* If we have an FPU, enroll ourselves in the FPU-full mask */
if (cpu_has_fpu)
@@ -288,7 +318,7 @@ static void remote_vpe_boot(void *dummy)
mips_cps_boot_vpes(core_cfg, cpu_vpe_id(_cpu_data));
 }
 
-static void cps_boot_secondary(int cpu, struct task_struct *idle)
+static void cps_start_secondary(int cpu, void *entry_fn, struct task_struct 
*tsk)
 {
unsigned core = cpu_data[cpu].core;
unsigned vpe_id = cpu_vpe_id(_data[cpu]);
@@ -298,9 +328,9 @@ static void cps_boot_secondary(int cpu, struct task_struct 
*idle)
unsigned int remote;
int err;
 
-   vpe_cfg->pc = (unsigned long)_bootstrap;
-   vpe_cfg->sp = __KSTK_TOS(idle);
-   vpe_cfg->gp = (unsigned long)task_thread_info(idle);
+   vpe_cfg->pc = (unsigned long)entry_fn;
+   vpe_cfg->sp = __KSTK_TOS(tsk);
+   vpe_cfg->gp = (unsigned long)task_thread_info(tsk);
 
atomic_or(1 << cpu_vpe_id(_data[cpu]), _cfg->vpe_mask);
 
@@ -348,6 +378,11 @@ static void cps_boot_secondary(int cpu, struct task_struct 
*idle)
preempt_enable();
 }
 
+static void cps_boot_secondary(int cpu, struct

[PATCH v6 2/4] MIPS: CPS: Add VP(E) stealing

From: Lisa Parratt 

VP(E) stealing provides a mechanism for removing an offline Virtual
Processor from the Linux kernel such that it is available to run bare
metal code.
Once the CPU has been offlined from Linux, the CPU can be given a task
to run via mips_cps_steal_cpu_and_execute(). The CPU is removed from the
cpu_present mask and is set up to execute from address entry_fn. Stack
space is assigned via the tsk task_struct so that C initialisation code
may be used.
To return the CPU back to Linux control, mips_cps_halt_and_return_cpu
will arrange to halt the CPU and return it to the cpu_present mask. It
is then available to be brought online again via CPU hotplug.

This mechanism is used by the MIPS remote processor driver to allow
CPUs within the system to execute bare metal code, not under control of
the kernel.

Signed-off-by: Lisa Parratt 
Signed-off-by: Matt Redfearn 
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/mips/Kconfig   |   7 ++
 arch/mips/include/asm/smp-cps.h |   8 ++
 arch/mips/kernel/smp-cps.c  | 162 ++--
 arch/mips/kernel/smp.c  |  12 +++
 4 files changed, 182 insertions(+), 7 deletions(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index a008a9f03072..6cdc23da8761 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -2381,6 +2381,13 @@ config MIPS_CPS
  no external assistance. It is safe to enable this when hardware
  support is unavailable.
 
+config MIPS_CPU_STEAL
+   bool "VPE stealing"
+   depends on HOTPLUG_CPU && MIPS_CPS
+   help
+ Select this is you wish to be able to run bare metal code on offline
+ VPEs.
+
 config MIPS_CPS_PM
depends on MIPS_CPS
select MIPS_CPC
diff --git a/arch/mips/include/asm/smp-cps.h b/arch/mips/include/asm/smp-cps.h
index 2ae1f61a4a95..5cab043d7e6f 100644
--- a/arch/mips/include/asm/smp-cps.h
+++ b/arch/mips/include/asm/smp-cps.h
@@ -34,6 +34,14 @@ extern void mips_cps_boot_vpes(struct core_boot_config *cfg, 
unsigned vpe);
 extern void mips_cps_pm_save(void);
 extern void mips_cps_pm_restore(void);
 
+#ifdef CONFIG_MIPS_CPU_STEAL
+
+extern int mips_cps_steal_cpu_and_execute(unsigned int cpu, void *entry_fn,
+ struct task_struct *tsk);
+extern int mips_cps_halt_and_return_cpu(unsigned int cpu);
+
+#endif /* CONFIG_MIPS_CPU_STEAL */
+
 #ifdef CONFIG_MIPS_CPS
 
 extern bool mips_cps_smp_in_use(void);
diff --git a/arch/mips/kernel/smp-cps.c b/arch/mips/kernel/smp-cps.c
index 6d45f05538c8..3a1e08a0c327 100644
--- a/arch/mips/kernel/smp-cps.c
+++ b/arch/mips/kernel/smp-cps.c
@@ -8,6 +8,7 @@
  * option) any later version.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -40,6 +41,31 @@ static int __init setup_nothreads(char *s)
 }
 early_param("nothreads", setup_nothreads);
 
+#ifdef CONFIG_MIPS_CPU_STEAL
+struct cpumask cpu_stolen_mask;
+
+static inline bool cpu_stolen(int cpu)
+{
+   return cpumask_test_cpu(cpu, _stolen_mask);
+}
+
+static inline void set_cpu_stolen(int cpu, bool state)
+{
+   if (state)
+   cpumask_set_cpu(cpu, _stolen_mask);
+   else
+   cpumask_clear_cpu(cpu, _stolen_mask);
+}
+#else
+static inline bool cpu_stolen(int cpu)
+{
+   return false;
+}
+
+static inline void set_cpu_stolen(int cpu, bool state) { }
+
+#endif /* CONFIG_MIPS_CPU_STEAL */
+
 static unsigned core_vpe_count(unsigned core)
 {
unsigned cfg;
@@ -110,6 +136,10 @@ static void __init cps_smp_setup(void)
write_gcr_bev_base(core_entry);
}
 
+#ifdef CONFIG_MIPS_CPU_STEAL
+   cpumask_clear(_stolen_mask);
+#endif /* CONFIG_MIPS_CPU_STEAL */
+
 #ifdef CONFIG_MIPS_MT_FPAFF
/* If we have an FPU, enroll ourselves in the FPU-full mask */
if (cpu_has_fpu)
@@ -288,7 +318,7 @@ static void remote_vpe_boot(void *dummy)
mips_cps_boot_vpes(core_cfg, cpu_vpe_id(_cpu_data));
 }
 
-static void cps_boot_secondary(int cpu, struct task_struct *idle)
+static void cps_start_secondary(int cpu, void *entry_fn, struct task_struct 
*tsk)
 {
unsigned core = cpu_data[cpu].core;
unsigned vpe_id = cpu_vpe_id(_data[cpu]);
@@ -298,9 +328,9 @@ static void cps_boot_secondary(int cpu, struct task_struct 
*idle)
unsigned int remote;
int err;
 
-   vpe_cfg->pc = (unsigned long)_bootstrap;
-   vpe_cfg->sp = __KSTK_TOS(idle);
-   vpe_cfg->gp = (unsigned long)task_thread_info(idle);
+   vpe_cfg->pc = (unsigned long)entry_fn;
+   vpe_cfg->sp = __KSTK_TOS(tsk);
+   vpe_cfg->gp = (unsigned long)task_thread_info(tsk);
 
atomic_or(1 << cpu_vpe_id(_data[cpu]), _cfg->vpe_mask);
 
@@ -348,6 +378,11 @@ static void cps_boot_secondary(int cpu, struct task_struct 
*idle)
preempt_enable();
 }
 
+static void cps_boot_secondary(int cpu, struct task_struct *idle)
+{
+   cps_start_secondary(cpu, _bootstrap, idle);
+}
+

[PATCH v6 0/4] MIPS: Remote processor driver

The MIPS remote processor driver allows non-Linux firmware to take
control of and execute on one of the systems VPEs, turning the system
into a hybrid of SMP Linux and AMP.

This is useful to allow running bare metal code, or an RTOS, on one or
more CPUs while allowing Linux to continue running on those remaining.

This functionality is conceptually similar to the VPE loader, an arch
specific mechanism which has been in the MIPS Linux kernel since 2005.
This driver is an attempt to make that functionality more standard by
moving it into the remoteproc subsystem.

A system CPU must be offlined from Linux and the driver enabled for that
CPU via the drivers sysfs interface. The remoteproc subsystem then takes
control of the CPU and loads a separate firmware image to it. A full
description is available at [1]. Example firmware images for the driver
and host programs to test them are available at [2].

The first patches in this series lay the groundwork for the driver
before it is added. The last series deprecates the VPE loader.

This functionality is supported on:
- MIPS32r2 devices implementing the MIPS MT ASE for multithreading, such
as interAptiv.
- MIPS32r6 devices implementing VPs, such as I6400.

Limitations:
- The remoteproc core supports only 32bit ELFs. Therefore it is only
possible to run 32bit firmware on the remote processor. Also, for
virtio communication, pointers are passed from the kernel to firmware.
There can be no mismatch in pointer sizes between the kernel and
firmware, so this limits the host kernel to 32bit as well.

The functionality has been tested on the Ci40 board which has a 2 core 2
thread interAptiv.

This series is based on v4.11-rc3

[1]
http://wiki.prplfoundation.org/w/images/d/df/MIPS_OS_Remote_Processor_Driver_Whitepaper_1.0.9.pdf
[2] https://github.com/MIPS/mips-rproc-example

Changes in v6:
Rebase on Linux 4.11-rc3
Change to set_current_state() as set_task_state has been removed.

Changes in v5:
Depend on !64bit since this driver only works with 32bit kernels
Set mproc->tsk state to TASK_DEAD before freeing it to avoid warning
Flush icache of each carveout so that icache sees latest data written

Changes in v4:
Fix inconsistency of Linux CPU number and VP ID
Have a single mips-rproc device to be parent to each CPU's rproc device.
Support per-device coherence introduced in v4.9
Add a sysfs interface to control the mask of cpus available to rproc

Changes in v3:
Update GIC context saving to use CPU hotplug state machine
Update MIPS remoteproc driver to use CPU hotplug state machine
Remove sysfs interface from MIPS rproc driver, now provided by the core.
Drop patches that Ralf has already merged to mips-next

Changes in v2:
Add dependence on additional patches to mips-gic in commit log
Incorporate changes from Marc Zynger's review:
- Remove CONTEXT_SAVING define.
- Make saved local state a per-cpu variable
- Make gic_save_* static functions when enabled, and do { } while(0)
otherwise

Lisa Parratt (1):
MIPS: CPS: Add VP(E) stealing

Matt Redfearn (3):
irqchip: mips-gic: Add context saving for MIPS_REMOTEPROC
remoteproc/MIPS: Add a remoteproc driver for MIPS
MIPS: Deprecate VPE Loader

Documentation/ABI/testing/sysfs-devices-mips-rproc | 13 +
arch/mips/Kconfig | 12 +-
arch/mips/include/asm/smp-cps.h| 8 +
arch/mips/kernel/smp-cps.c | 162 +-
arch/mips/kernel/smp.c | 12 +
drivers/irqchip/irq-mips-gic.c | 207 ++-
drivers/remoteproc/Kconfig | 11 +
drivers/remoteproc/Makefile| 1 +
drivers/remoteproc/mips_remoteproc.c | 599 +
9 files changed, 1010 insertions(+), 15 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-devices-mips-rproc
create mode 100644 drivers/remoteproc/mips_remoteproc.c

--
2.7.4

[PATCH v6 3/4] remoteproc/MIPS: Add a remoteproc driver for MIPS

This driver allows a MIPS processor offlined from Linux to be used as a
remote processor. The processor can then handle real-time tasks or
perform coprocessing while remaining processors are available to Linux,
effectively making the system hybrid of SMP Linux and AMP.

A sysfs interface is provided to allow control of which system CPUs may
be acquired by the driver when offlined from Linux.

Coprocessor firmware must abide by the remoteproc standard, i.e.
implement the resource table containing memory layouts and virtio device
descriptions, and additionally abide by the MIPS UHI coprocessor boot
protocol in the startup code.

Example firmware and host executables to test them are located at [1].

[1] https://github.com/MIPS/mips-rproc-example

Signed-off-by: Lisa Parratt 
Signed-off-by: Matt Redfearn 

---

Changes in v6:
Change to set_current_state() as set_task_state has been removed.

Changes in v5:
Depend on !64bit since this driver only works with 32bit kernels
Set mproc->tsk state to TASK_DEAD before freeing it to avoid warning
Flush icache of each carveout so that icache sees latest data written

Changes in v4:
Have a single mips-rproc device to be parent to each CPU's rproc device.
Support per-device coherence introduced in v4.9
Add a sysfs interface to control the mask of cpus available to rproc

Changes in v3:
Update MIPS remoteproc driver to use CPU hotplug state machine
Remove sysfs interface from MIPS rproc driver, now provided by the core.
Drop patches that Ralf has already merged to mips-next

Changes in v2: None

 Documentation/ABI/testing/sysfs-devices-mips-rproc |  13 +
 drivers/remoteproc/Kconfig |  11 +
 drivers/remoteproc/Makefile|   1 +
 drivers/remoteproc/mips_remoteproc.c   | 599 +
 4 files changed, 624 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-devices-mips-rproc
 create mode 100644 drivers/remoteproc/mips_remoteproc.c

diff --git a/Documentation/ABI/testing/sysfs-devices-mips-rproc 
b/Documentation/ABI/testing/sysfs-devices-mips-rproc
new file mode 100644
index ..b06f6671807a
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-mips-rproc
@@ -0,0 +1,13 @@
+What:  /sys/devices/mips-rproc/cpus
+Date:  October 2016
+Contact:   Matt Redfearn 
+Description:
+   CPU topology file describing which CPUs may be used by the
+   MIPS remote processor driver when offline from Linux.
+
+   This can be read to observe the current setting, or written to
+   change the allowed CPUs.
+
+   The format is compatible with cpulist_parse()
+   [see ], for example to enable the MIPS remote
+   processor driver on CPUs 1,2 & 3, write "1-3" into this file.
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 65f86bc24c07..558b67184723 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -71,6 +71,17 @@ config DA8XX_REMOTEPROC
  It's safe to say n here if you're not interested in multimedia
  offloading.
 
+config MIPS_REMOTEPROC
+   tristate "MIPS remoteproc support"
+   depends on MIPS_CPS && HAS_DMA && !64BIT
+   depends on REMOTEPROC
+   select CMA
+   select MIPS_CPU_STEAL
+   help
+ Say y here to support using offline cores/VPEs as remote processors
+ via the remote processor framework.
+ If unsure say N.
+
 config QCOM_ADSP_PIL
tristate "Qualcomm ADSP Peripheral Image Loader"
depends on OF && ARCH_QCOM
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index ffc5e430df27..9525debba686 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -11,6 +11,7 @@ remoteproc-y  += 
remoteproc_elf_loader.o
 obj-$(CONFIG_OMAP_REMOTEPROC)  += omap_remoteproc.o
 obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o
 obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
+obj-$(CONFIG_MIPS_REMOTEPROC)  += mips_remoteproc.o
 obj-$(CONFIG_QCOM_ADSP_PIL)+= qcom_adsp_pil.o
 obj-$(CONFIG_QCOM_RPROC_COMMON)+= qcom_common.o
 obj-$(CONFIG_QCOM_Q6V5_PIL)+= qcom_q6v5_pil.o
diff --git a/drivers/remoteproc/mips_remoteproc.c 
b/drivers/remoteproc/mips_remoteproc.c
new file mode 100644
index ..9a0e5e06c0b1
--- /dev/null
+++ b/drivers/remoteproc/mips_remoteproc.c
@@ -0,0 +1,599 @@
+/*
+ * MIPS Remote Processor driver
+ *
+ * Copyright (C) 2016 Imagination Technologies
+ * Lisa Parratt 
+ * Matt Redfearn 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation;  either version 2 of the

[PATCH v6 0/4] MIPS: Remote processor driver

The MIPS remote processor driver allows non-Linux firmware to take
control of and execute on one of the systems VPEs, turning the system
into a hybrid of SMP Linux and AMP.

This is useful to allow running bare metal code, or an RTOS, on one or
more CPUs while allowing Linux to continue running on those remaining.

The first patches in this series lay the groundwork for the driver
before it is added. The last series deprecates the VPE loader.

This functionality is supported on:
- MIPS32r2 devices implementing the MIPS MT ASE for multithreading, such
as interAptiv.
- MIPS32r6 devices implementing VPs, such as I6400.

The functionality has been tested on the Ci40 board which has a 2 core 2
thread interAptiv.

This series is based on v4.11-rc3

[1]
http://wiki.prplfoundation.org/w/images/d/df/MIPS_OS_Remote_Processor_Driver_Whitepaper_1.0.9.pdf
[2] https://github.com/MIPS/mips-rproc-example

Changes in v6:
Rebase on Linux 4.11-rc3
Change to set_current_state() as set_task_state has been removed.

Lisa Parratt (1):
MIPS: CPS: Add VP(E) stealing

Matt Redfearn (3):
irqchip: mips-gic: Add context saving for MIPS_REMOTEPROC
remoteproc/MIPS: Add a remoteproc driver for MIPS
MIPS: Deprecate VPE Loader

--
2.7.4

[PATCH v6 3/4] remoteproc/MIPS: Add a remoteproc driver for MIPS

This driver allows a MIPS processor offlined from Linux to be used as a
remote processor. The processor can then handle real-time tasks or
perform coprocessing while remaining processors are available to Linux,
effectively making the system hybrid of SMP Linux and AMP.

A sysfs interface is provided to allow control of which system CPUs may
be acquired by the driver when offlined from Linux.

Coprocessor firmware must abide by the remoteproc standard, i.e.
implement the resource table containing memory layouts and virtio device
descriptions, and additionally abide by the MIPS UHI coprocessor boot
protocol in the startup code.

Example firmware and host executables to test them are located at [1].

[1] https://github.com/MIPS/mips-rproc-example

Signed-off-by: Lisa Parratt 
Signed-off-by: Matt Redfearn 

---

Changes in v6:
Change to set_current_state() as set_task_state has been removed.

Changes in v5:
Depend on !64bit since this driver only works with 32bit kernels
Set mproc->tsk state to TASK_DEAD before freeing it to avoid warning
Flush icache of each carveout so that icache sees latest data written

Changes in v4:
Have a single mips-rproc device to be parent to each CPU's rproc device.
Support per-device coherence introduced in v4.9
Add a sysfs interface to control the mask of cpus available to rproc

Changes in v3:
Update MIPS remoteproc driver to use CPU hotplug state machine
Remove sysfs interface from MIPS rproc driver, now provided by the core.
Drop patches that Ralf has already merged to mips-next

Changes in v2: None

 Documentation/ABI/testing/sysfs-devices-mips-rproc |  13 +
 drivers/remoteproc/Kconfig |  11 +
 drivers/remoteproc/Makefile|   1 +
 drivers/remoteproc/mips_remoteproc.c   | 599 +
 4 files changed, 624 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-devices-mips-rproc
 create mode 100644 drivers/remoteproc/mips_remoteproc.c

diff --git a/Documentation/ABI/testing/sysfs-devices-mips-rproc 
b/Documentation/ABI/testing/sysfs-devices-mips-rproc
new file mode 100644
index ..b06f6671807a
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-mips-rproc
@@ -0,0 +1,13 @@
+What:  /sys/devices/mips-rproc/cpus
+Date:  October 2016
+Contact:   Matt Redfearn 
+Description:
+   CPU topology file describing which CPUs may be used by the
+   MIPS remote processor driver when offline from Linux.
+
+   This can be read to observe the current setting, or written to
+   change the allowed CPUs.
+
+   The format is compatible with cpulist_parse()
+   [see ], for example to enable the MIPS remote
+   processor driver on CPUs 1,2 & 3, write "1-3" into this file.
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 65f86bc24c07..558b67184723 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -71,6 +71,17 @@ config DA8XX_REMOTEPROC
  It's safe to say n here if you're not interested in multimedia
  offloading.
 
+config MIPS_REMOTEPROC
+   tristate "MIPS remoteproc support"
+   depends on MIPS_CPS && HAS_DMA && !64BIT
+   depends on REMOTEPROC
+   select CMA
+   select MIPS_CPU_STEAL
+   help
+ Say y here to support using offline cores/VPEs as remote processors
+ via the remote processor framework.
+ If unsure say N.
+
 config QCOM_ADSP_PIL
tristate "Qualcomm ADSP Peripheral Image Loader"
depends on OF && ARCH_QCOM
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index ffc5e430df27..9525debba686 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -11,6 +11,7 @@ remoteproc-y  += 
remoteproc_elf_loader.o
 obj-$(CONFIG_OMAP_REMOTEPROC)  += omap_remoteproc.o
 obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o
 obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
+obj-$(CONFIG_MIPS_REMOTEPROC)  += mips_remoteproc.o
 obj-$(CONFIG_QCOM_ADSP_PIL)+= qcom_adsp_pil.o
 obj-$(CONFIG_QCOM_RPROC_COMMON)+= qcom_common.o
 obj-$(CONFIG_QCOM_Q6V5_PIL)+= qcom_q6v5_pil.o
diff --git a/drivers/remoteproc/mips_remoteproc.c 
b/drivers/remoteproc/mips_remoteproc.c
new file mode 100644
index ..9a0e5e06c0b1
--- /dev/null
+++ b/drivers/remoteproc/mips_remoteproc.c
@@ -0,0 +1,599 @@
+/*
+ * MIPS Remote Processor driver
+ *
+ * Copyright (C) 2016 Imagination Technologies
+ * Lisa Parratt 
+ * Matt Redfearn 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include

Re: [PATCH] tpm2: fix off-by-one comparison and out-of-bounds read error

2017-03-23 Thread Jarkko Sakkinen

On Thu, Mar 23, 2017 at 05:53:58PM +0200, Jarkko Sakkinen wrote:
> On Wed, Mar 22, 2017 at 04:12:49PM +0300, Dan Carpenter wrote:
> > On Wed, Mar 22, 2017 at 11:45:37AM +, Colin Ian King wrote:
> > > On 22/03/17 11:42, Jarkko Sakkinen wrote:
> > > > On Mon, Mar 20, 2017 at 02:23:36PM +, Colin King wrote:
> > > >> From: Colin Ian King 
> > > >>
> > > >> The comparison of an out of range index into space->context_tbl is
> > > >> off-by-one and should be using >= rather than > in the comparison.
> > > >>
> > > >> Detected by CoverityScan, CID#1419694 ("Out-of-bounds read")
> > > >>
> > > >> Fixes: 849246e7ce9ce ("tpm2: add session handle context saving and 
> > > >> restoring to the space code")
> > > >> Signed-off-by: Colin Ian King 
> > > >> ---
> > > >>  drivers/char/tpm/tpm2-space.c | 2 +-
> > > >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >>
> > > >> diff --git a/drivers/char/tpm/tpm2-space.c 
> > > >> b/drivers/char/tpm/tpm2-space.c
> > > >> index d36d81e07076..009934269514 100644
> > > >> --- a/drivers/char/tpm/tpm2-space.c
> > > >> +++ b/drivers/char/tpm/tpm2-space.c
> > > >> @@ -229,7 +229,7 @@ static bool tpm2_map_to_phandle(struct tpm_space 
> > > >> *space, void *handle)
> > > >>int i;
> > > >>  
> > > >>i = 0xFF - (vhandle & 0xFF);
> > > >> -  if (i > ARRAY_SIZE(space->context_tbl) || 
> > > >> !space->context_tbl[i])
> > > >> +  if (i >= ARRAY_SIZE(space->context_tbl) || 
> > > >> !space->context_tbl[i])
> > > >>return false;
> > > >>  
> > > >>phandle = space->context_tbl[i];
> > > >> -- 
> > > >> 2.11.0
> > > > 
> > > > Thanks. If you don't mind, I would squash this to that patch?
> > > > 
> > > > /Jarkko
> > > > 
> > > Sure squash it, and maybe add a Reported-by: Colin Ian King
> > >  if that's OK with you.
> > 
> > Reported-by isn't really correct though...  We should have a Fixes-from:
> > tag for squashed fixes.
> > 
> > regards,
> > dan carpenter
> 
> Hmm... Maybe so depending on how you interpret Reported-by but
> Fixes-from is not something that is used at the moment, is it?
> 
> /Jarkko

When I started squashing the commit I realized what you meant so
I'm adding this to the commit:

Fixes-from: Colin Ian King 

/Jarkko

Re: [PATCH] tpm2: fix off-by-one comparison and out-of-bounds read error

2017-03-23 Thread Jarkko Sakkinen

On Thu, Mar 23, 2017 at 05:53:58PM +0200, Jarkko Sakkinen wrote:
> On Wed, Mar 22, 2017 at 04:12:49PM +0300, Dan Carpenter wrote:
> > On Wed, Mar 22, 2017 at 11:45:37AM +, Colin Ian King wrote:
> > > On 22/03/17 11:42, Jarkko Sakkinen wrote:
> > > > On Mon, Mar 20, 2017 at 02:23:36PM +, Colin King wrote:
> > > >> From: Colin Ian King 
> > > >>
> > > >> The comparison of an out of range index into space->context_tbl is
> > > >> off-by-one and should be using >= rather than > in the comparison.
> > > >>
> > > >> Detected by CoverityScan, CID#1419694 ("Out-of-bounds read")
> > > >>
> > > >> Fixes: 849246e7ce9ce ("tpm2: add session handle context saving and 
> > > >> restoring to the space code")
> > > >> Signed-off-by: Colin Ian King 
> > > >> ---
> > > >>  drivers/char/tpm/tpm2-space.c | 2 +-
> > > >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >>
> > > >> diff --git a/drivers/char/tpm/tpm2-space.c 
> > > >> b/drivers/char/tpm/tpm2-space.c
> > > >> index d36d81e07076..009934269514 100644
> > > >> --- a/drivers/char/tpm/tpm2-space.c
> > > >> +++ b/drivers/char/tpm/tpm2-space.c
> > > >> @@ -229,7 +229,7 @@ static bool tpm2_map_to_phandle(struct tpm_space 
> > > >> *space, void *handle)
> > > >>int i;
> > > >>  
> > > >>i = 0xFF - (vhandle & 0xFF);
> > > >> -  if (i > ARRAY_SIZE(space->context_tbl) || 
> > > >> !space->context_tbl[i])
> > > >> +  if (i >= ARRAY_SIZE(space->context_tbl) || 
> > > >> !space->context_tbl[i])
> > > >>return false;
> > > >>  
> > > >>phandle = space->context_tbl[i];
> > > >> -- 
> > > >> 2.11.0
> > > > 
> > > > Thanks. If you don't mind, I would squash this to that patch?
> > > > 
> > > > /Jarkko
> > > > 
> > > Sure squash it, and maybe add a Reported-by: Colin Ian King
> > >  if that's OK with you.
> > 
> > Reported-by isn't really correct though...  We should have a Fixes-from:
> > tag for squashed fixes.
> > 
> > regards,
> > dan carpenter
> 
> Hmm... Maybe so depending on how you interpret Reported-by but
> Fixes-from is not something that is used at the moment, is it?
> 
> /Jarkko

When I started squashing the commit I realized what you meant so
I'm adding this to the commit:

Fixes-from: Colin Ian King 

/Jarkko

Re: [PATCH 1/2] mfd: hi655x: Reference required regulator driver

On Mon, 20 Mar 2017, Jeremy Linton wrote:

> The hisi pmic requires an independent regulator driver to be
> loaded so that devices dependent on the pmic/regulator are
> started properly. Currently there is only a single compatible
> regulator driver in the tree, so reference it with a module soft
> dependency so that modprobe loads it whenever the hisi pmic
> driver is loaded.

This is a new one on my, but it sounds okay.

OOI, what happens when there are lots of compatible drivers?

> Signed-off-by: Jeremy Linton 
> ---
>  drivers/mfd/hi655x-pmic.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/mfd/hi655x-pmic.c b/drivers/mfd/hi655x-pmic.c
> index ba706ad..56e027d 100644
> --- a/drivers/mfd/hi655x-pmic.c
> +++ b/drivers/mfd/hi655x-pmic.c
> @@ -184,3 +184,4 @@ module_platform_driver(hi655x_pmic_driver);
>  MODULE_AUTHOR("Chen Feng ");
>  MODULE_DESCRIPTION("Hisilicon hi655x PMIC driver");
>  MODULE_LICENSE("GPL v2");
> +MODULE_SOFTDEP("post: hi655x-regulator");

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 1/2] mfd: hi655x: Reference required regulator driver

On Mon, 20 Mar 2017, Jeremy Linton wrote:

> The hisi pmic requires an independent regulator driver to be
> loaded so that devices dependent on the pmic/regulator are
> started properly. Currently there is only a single compatible
> regulator driver in the tree, so reference it with a module soft
> dependency so that modprobe loads it whenever the hisi pmic
> driver is loaded.

This is a new one on my, but it sounds okay.

OOI, what happens when there are lots of compatible drivers?

> Signed-off-by: Jeremy Linton 
> ---
>  drivers/mfd/hi655x-pmic.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/mfd/hi655x-pmic.c b/drivers/mfd/hi655x-pmic.c
> index ba706ad..56e027d 100644
> --- a/drivers/mfd/hi655x-pmic.c
> +++ b/drivers/mfd/hi655x-pmic.c
> @@ -184,3 +184,4 @@ module_platform_driver(hi655x_pmic_driver);
>  MODULE_AUTHOR("Chen Feng ");
>  MODULE_DESCRIPTION("Hisilicon hi655x PMIC driver");
>  MODULE_LICENSE("GPL v2");
> +MODULE_SOFTDEP("post: hi655x-regulator");

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: linux-next: manual merge of the gpio tree with the input tree

2017-03-23 Thread Dmitry Torokhov

On Thu, Mar 23, 2017 at 2:27 AM, Linus Walleij  wrote:
> On Mon, Mar 20, 2017 at 5:03 AM, Stephen Rothwell  
> wrote:
>> Hi Linus,
>>
>> Today's linux-next merge of the gpio tree got a conflict in:
>>
>>   drivers/input/misc/soc_button_array.c
>>
>> between commit:
>>
>>   a01cd17000a4 ("Input: soc_button_array - use NULL for GPIO connection ID")
>>
>> from the input tree and commit:
>>
>>   c5097538c86a ("Input: soc_button_array - Propagate error from 
>> gpiod_count()")
>>
>> from the gpio tree.
>
> Dmitry, I could pick the commit from the input tree and apply
> Stephen's solution and put the result in the GPIO tree if you think
> it's a good idea.

I think the fix is trivial and if it does not both Stephen to carry it
on we'll let the other Linus resolve it in his tree when merging. I
think he prefers to have cross-tree merges only happen when it is
needed for development, not simply to resolve conflicts.

Thanks.

-- 
Dmitry

Re: linux-next: manual merge of the gpio tree with the input tree

2017-03-23 Thread Dmitry Torokhov

On Thu, Mar 23, 2017 at 2:27 AM, Linus Walleij  wrote:
> On Mon, Mar 20, 2017 at 5:03 AM, Stephen Rothwell  
> wrote:
>> Hi Linus,
>>
>> Today's linux-next merge of the gpio tree got a conflict in:
>>
>>   drivers/input/misc/soc_button_array.c
>>
>> between commit:
>>
>>   a01cd17000a4 ("Input: soc_button_array - use NULL for GPIO connection ID")
>>
>> from the input tree and commit:
>>
>>   c5097538c86a ("Input: soc_button_array - Propagate error from 
>> gpiod_count()")
>>
>> from the gpio tree.
>
> Dmitry, I could pick the commit from the input tree and apply
> Stephen's solution and put the result in the GPIO tree if you think
> it's a good idea.

I think the fix is trivial and if it does not both Stephen to carry it
on we'll let the other Linus resolve it in his tree when merging. I
think he prefers to have cross-tree merges only happen when it is
needed for development, not simply to resolve conflicts.

Thanks.

-- 
Dmitry

Re: [PATCH v2] ARM: dts: mvebu: linksys: enable buffer manager support

Hi Ralph,
 
 On jeu., mars 16 2017, Ralph Sennhauser  wrote:

> Add appropriate properties to devices in the Linksys WRT AC Series for the
> mvneta driver to use hardware buffer management.
>
> Also update "soc" ranges property and set the status of bm and bm-bppi
> to "okay" (SRAM).
>
> Signed-off-by: Ralph Sennhauser 


Applied on mvebu/dt

Thanks,

Gregory

> ---
>
> v1 -> v2:
>   Use independent pools for short (suggested by Gregory Clement)
>
>
>  arch/arm/boot/dts/armada-385-linksys.dtsi | 17 -
>  arch/arm/boot/dts/armada-xp-linksys-mamba.dts | 17 -
>  2 files changed, 32 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/armada-385-linksys.dtsi 
> b/arch/arm/boot/dts/armada-385-linksys.dtsi
> index df47bf1..aa0d225 100644
> --- a/arch/arm/boot/dts/armada-385-linksys.dtsi
> +++ b/arch/arm/boot/dts/armada-385-linksys.dtsi
> @@ -59,7 +59,8 @@
>   ranges =  MBUS_ID(0x01, 0x1d) 0 0xfff0 0x10
> MBUS_ID(0x09, 0x19) 0 0xf110 0x1
> -   MBUS_ID(0x09, 0x15) 0 0xf111 0x1>;
> +   MBUS_ID(0x09, 0x15) 0 0xf111 0x1
> +   MBUS_ID(0x0c, 0x04) 0 0xf120 0x10>;
>  
>   internal-regs {
>   i2c@11000 {
> @@ -88,6 +89,9 @@
>   ethernet@7 {
>   status = "okay";
>   phy-mode = "rgmii-id";
> + buffer-manager = <>;
> + bm,pool-long = <2>;
> + bm,pool-short = <3>;
>   fixed-link {
>   speed = <1000>;
>   full-duplex;
> @@ -97,6 +101,9 @@
>   ethernet@34000 {
>   status = "okay";
>   phy-mode = "sgmii";
> + buffer-manager = <>;
> + bm,pool-long = <0>;
> + bm,pool-short = <1>;
>   fixed-link {
>   speed = <1000>;
>   full-duplex;
> @@ -159,6 +166,10 @@
>   status = "okay";
>   };
>  
> + bm@c8000 {
> + status = "okay";
> + };
> +
>   /* USB part of the eSATA/USB 2.0 port */
>   usb@58000 {
>   status = "okay";
> @@ -241,6 +252,10 @@
>   };
>   };
>  
> + bm-bppi {
> + status = "okay";
> + };
> +
>   pcie-controller {
>   status = "okay";
>  
> diff --git a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts 
> b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
> index 3744ba3..9efcf59 100644
> --- a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
> +++ b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
> @@ -71,7 +71,8 @@
>   ranges =  MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10
> MBUS_ID(0x09, 0x09) 0 0 0xf110 0x1
> -   MBUS_ID(0x09, 0x05) 0 0 0xf111 0x1>;
> +   MBUS_ID(0x09, 0x05) 0 0 0xf111 0x1
> +   MBUS_ID(0x0c, 0x04) 0 0 0xf120 0x10>;
>  
>   internal-regs {
>  
> @@ -95,6 +96,9 @@
>   pinctrl-names = "default";
>   status = "okay";
>   phy-mode = "rgmii-id";
> + buffer-manager = <>;
> + bm,pool-long = <0>;
> + bm,pool-short = <1>;
>   fixed-link {
>   speed = <1000>;
>   full-duplex;
> @@ -106,6 +110,9 @@
>   pinctrl-names = "default";
>   status = "okay";
>   phy-mode = "rgmii-id";
> + buffer-manager = <>;
> + bm,pool-long = <2>;
> + bm,pool-short = <3>;
>   fixed-link {
>   speed = <1000>;
>   full-duplex;
> @@ -186,6 +193,10 @@
>   };
>   };
>  
> + bm@c8000 {
> + status = "okay";
> + };
> +
>   nand@d {
>

Re: [PATCH v2] ARM: dts: mvebu: linksys: enable buffer manager support

Hi Ralph,
 
 On jeu., mars 16 2017, Ralph Sennhauser  wrote:

> Add appropriate properties to devices in the Linksys WRT AC Series for the
> mvneta driver to use hardware buffer management.
>
> Also update "soc" ranges property and set the status of bm and bm-bppi
> to "okay" (SRAM).
>
> Signed-off-by: Ralph Sennhauser 


Applied on mvebu/dt

Thanks,

Gregory

> ---
>
> v1 -> v2:
>   Use independent pools for short (suggested by Gregory Clement)
>
>
>  arch/arm/boot/dts/armada-385-linksys.dtsi | 17 -
>  arch/arm/boot/dts/armada-xp-linksys-mamba.dts | 17 -
>  2 files changed, 32 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/armada-385-linksys.dtsi 
> b/arch/arm/boot/dts/armada-385-linksys.dtsi
> index df47bf1..aa0d225 100644
> --- a/arch/arm/boot/dts/armada-385-linksys.dtsi
> +++ b/arch/arm/boot/dts/armada-385-linksys.dtsi
> @@ -59,7 +59,8 @@
>   ranges =  MBUS_ID(0x01, 0x1d) 0 0xfff0 0x10
> MBUS_ID(0x09, 0x19) 0 0xf110 0x1
> -   MBUS_ID(0x09, 0x15) 0 0xf111 0x1>;
> +   MBUS_ID(0x09, 0x15) 0 0xf111 0x1
> +   MBUS_ID(0x0c, 0x04) 0 0xf120 0x10>;
>  
>   internal-regs {
>   i2c@11000 {
> @@ -88,6 +89,9 @@
>   ethernet@7 {
>   status = "okay";
>   phy-mode = "rgmii-id";
> + buffer-manager = <>;
> + bm,pool-long = <2>;
> + bm,pool-short = <3>;
>   fixed-link {
>   speed = <1000>;
>   full-duplex;
> @@ -97,6 +101,9 @@
>   ethernet@34000 {
>   status = "okay";
>   phy-mode = "sgmii";
> + buffer-manager = <>;
> + bm,pool-long = <0>;
> + bm,pool-short = <1>;
>   fixed-link {
>   speed = <1000>;
>   full-duplex;
> @@ -159,6 +166,10 @@
>   status = "okay";
>   };
>  
> + bm@c8000 {
> + status = "okay";
> + };
> +
>   /* USB part of the eSATA/USB 2.0 port */
>   usb@58000 {
>   status = "okay";
> @@ -241,6 +252,10 @@
>   };
>   };
>  
> + bm-bppi {
> + status = "okay";
> + };
> +
>   pcie-controller {
>   status = "okay";
>  
> diff --git a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts 
> b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
> index 3744ba3..9efcf59 100644
> --- a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
> +++ b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
> @@ -71,7 +71,8 @@
>   ranges =  MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10
> MBUS_ID(0x09, 0x09) 0 0 0xf110 0x1
> -   MBUS_ID(0x09, 0x05) 0 0 0xf111 0x1>;
> +   MBUS_ID(0x09, 0x05) 0 0 0xf111 0x1
> +   MBUS_ID(0x0c, 0x04) 0 0 0xf120 0x10>;
>  
>   internal-regs {
>  
> @@ -95,6 +96,9 @@
>   pinctrl-names = "default";
>   status = "okay";
>   phy-mode = "rgmii-id";
> + buffer-manager = <>;
> + bm,pool-long = <0>;
> + bm,pool-short = <1>;
>   fixed-link {
>   speed = <1000>;
>   full-duplex;
> @@ -106,6 +110,9 @@
>   pinctrl-names = "default";
>   status = "okay";
>   phy-mode = "rgmii-id";
> + buffer-manager = <>;
> + bm,pool-long = <2>;
> + bm,pool-short = <3>;
>   fixed-link {
>   speed = <1000>;
>   full-duplex;
> @@ -186,6 +193,10 @@
>   };
>   };
>  
> + bm@c8000 {
> + status = "okay";
> + };
> +
>   nand@d {
>   status = "okay";
>   num-cs = <1>;
> @@ -259,6 +270,10 @@
>   };
>

[RFT PATCH 2/6] ARM64: dts: meson-gxl: Add gpio-ranges properties

Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index fe11b5f..64f4b6e 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -79,6 +79,7 @@
reg-names = "mux", "pull", "gpio";
gpio-controller;
#gpio-cells = <2>;
+   gpio-ranges = <_aobus 0 0 14>;
};
 
uart_ao_a_pins: uart_ao_a {
@@ -142,6 +143,7 @@
reg-names = "mux", "pull", "pull-enable", "gpio";
gpio-controller;
#gpio-cells = <2>;
+   gpio-ranges = <_periphs 0 14 101>;
};
 
emmc_pins: emmc {
-- 
1.9.1

[RFT PATCH 2/6] ARM64: dts: meson-gxl: Add gpio-ranges properties

Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index fe11b5f..64f4b6e 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -79,6 +79,7 @@
reg-names = "mux", "pull", "gpio";
gpio-controller;
#gpio-cells = <2>;
+   gpio-ranges = <_aobus 0 0 14>;
};
 
uart_ao_a_pins: uart_ao_a {
@@ -142,6 +143,7 @@
reg-names = "mux", "pull", "pull-enable", "gpio";
gpio-controller;
#gpio-cells = <2>;
+   gpio-ranges = <_periphs 0 14 101>;
};
 
emmc_pins: emmc {
-- 
1.9.1

[RFT PATCH 3/6] ARM: dts: meson8: Add gpio-ranges properties

Signed-off-by: Neil Armstrong 
---
 arch/arm/boot/dts/meson8.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
index 45619f6..ebc763e 100644
--- a/arch/arm/boot/dts/meson8.dtsi
+++ b/arch/arm/boot/dts/meson8.dtsi
@@ -106,6 +106,7 @@
reg-names = "mux", "pull", "pull-enable", "gpio";
gpio-controller;
#gpio-cells = <2>;
+   gpio-ranges = <_cbus 0 0 120>;
};
 
spi_nor_pins: nor {
@@ -148,6 +149,7 @@
reg-names = "mux", "pull", "gpio";
gpio-controller;
#gpio-cells = <2>;
+   gpio-ranges = <_aobus 0 120 16>;
};
 
uart_ao_a_pins: uart_ao_a {
-- 
1.9.1

[RFT PATCH 3/6] ARM: dts: meson8: Add gpio-ranges properties

Signed-off-by: Neil Armstrong 
---
 arch/arm/boot/dts/meson8.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
index 45619f6..ebc763e 100644
--- a/arch/arm/boot/dts/meson8.dtsi
+++ b/arch/arm/boot/dts/meson8.dtsi
@@ -106,6 +106,7 @@
reg-names = "mux", "pull", "pull-enable", "gpio";
gpio-controller;
#gpio-cells = <2>;
+   gpio-ranges = <_cbus 0 0 120>;
};
 
spi_nor_pins: nor {
@@ -148,6 +149,7 @@
reg-names = "mux", "pull", "gpio";
gpio-controller;
#gpio-cells = <2>;
+   gpio-ranges = <_aobus 0 120 16>;
};
 
uart_ao_a_pins: uart_ao_a {
-- 
1.9.1

[RFT PATCH 0/6] pinctrl: meson: Fix gpio-ranged for GPIO Hog

Whem trying to add a gpio hog to enable the USB Hub on the Odroid-C2, I
encountered a strange bug where when calling gpiochip_add_data() the gpiolib
code was trying to add the Hog but failed because the gpio ranges were missing.

In the meson-pinctrl driver, the gpio ranges are added manually /after/ the
call to gpiochip_add_data().
The arch/arm meson8 and meson8b patches has not been tested, this is why this
patchset is an RFT.

So this patchset uses the DT gpio-ranges attribute instead and solves the issue.

The final patch is the actual GPIO Hog for the Odroid-C2 board, which is an ugly
hack but is necessary to have USB Ports working on the board until the generic
power sequence framework is merged.

Neil Armstrong (6):
  ARM64: dts: meson-gxbb: Add gpio-ranges properties
  ARM64: dts: meson-gxl: Add gpio-ranges properties
  ARM: dts: meson8: Add gpio-ranges properties
  ARM: dts: meson8b: Add gpio-ranges properties
  pinctrl: meson: use gpio-ranges from DT
  ARM64: dts: meson-gxbb: Add USB Hub GPIO hog

 arch/arm/boot/dts/meson8.dtsi   |  2 ++
 arch/arm/boot/dts/meson8b.dtsi  |  2 ++
 arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 15 +++
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi |  2 ++
 arch/arm64/boot/dts/amlogic/meson-gxl.dtsi  |  2 ++
 drivers/pinctrl/meson/pinctrl-meson.c   | 14 +-
 6 files changed, 24 insertions(+), 13 deletions(-)

-- 
1.9.1

[RFT PATCH 0/6] pinctrl: meson: Fix gpio-ranged for GPIO Hog

Whem trying to add a gpio hog to enable the USB Hub on the Odroid-C2, I
encountered a strange bug where when calling gpiochip_add_data() the gpiolib
code was trying to add the Hog but failed because the gpio ranges were missing.

In the meson-pinctrl driver, the gpio ranges are added manually /after/ the
call to gpiochip_add_data().
The arch/arm meson8 and meson8b patches has not been tested, this is why this
patchset is an RFT.

So this patchset uses the DT gpio-ranges attribute instead and solves the issue.

The final patch is the actual GPIO Hog for the Odroid-C2 board, which is an ugly
hack but is necessary to have USB Ports working on the board until the generic
power sequence framework is merged.

Neil Armstrong (6):
  ARM64: dts: meson-gxbb: Add gpio-ranges properties
  ARM64: dts: meson-gxl: Add gpio-ranges properties
  ARM: dts: meson8: Add gpio-ranges properties
  ARM: dts: meson8b: Add gpio-ranges properties
  pinctrl: meson: use gpio-ranges from DT
  ARM64: dts: meson-gxbb: Add USB Hub GPIO hog

 arch/arm/boot/dts/meson8.dtsi   |  2 ++
 arch/arm/boot/dts/meson8b.dtsi  |  2 ++
 arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 15 +++
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi |  2 ++
 arch/arm64/boot/dts/amlogic/meson-gxl.dtsi  |  2 ++
 drivers/pinctrl/meson/pinctrl-meson.c   | 14 +-
 6 files changed, 24 insertions(+), 13 deletions(-)

-- 
1.9.1

[RFT PATCH 4/6] ARM: dts: meson8b: Add gpio-ranges properties

Signed-off-by: Neil Armstrong 
---
 arch/arm/boot/dts/meson8b.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index 41fd536..828aa49 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -198,6 +198,7 @@
reg-names = "mux", "pull", "pull-enable", 
"gpio";
gpio-controller;
#gpio-cells = <2>;
+   gpio-ranges = <_cbus 0 0 130>;
};
};
 
@@ -215,6 +216,7 @@
reg-names = "mux", "pull", "gpio";
gpio-controller;
#gpio-cells = <2>;
+   gpio-ranges = <_aobus 0 130 16>;
};
 
uart_ao_a_pins: uart_ao_a {
-- 
1.9.1

[RFT PATCH 5/6] pinctrl: meson: use gpio-ranges from DT

When trying to add a gpio-hog, we enter a weird loop where the gpio-ranges
is needed when gpiochip_add_data() is called but in the current implementation
the ranges are added from the driver afterwards.

A simple solution is to rely on the DR gpio-ranges attribute and remove the
call to gpiochip_add_pin_range().

Signed-off-by: Neil Armstrong 
---
 drivers/pinctrl/meson/pinctrl-meson.c | 14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/drivers/pinctrl/meson/pinctrl-meson.c 
b/drivers/pinctrl/meson/pinctrl-meson.c
index cf1686e..66ed70c 100644
--- a/drivers/pinctrl/meson/pinctrl-meson.c
+++ b/drivers/pinctrl/meson/pinctrl-meson.c
@@ -555,22 +555,10 @@ static int meson_gpiolib_register(struct meson_pinctrl 
*pc)
if (ret) {
dev_err(pc->dev, "can't add gpio chip %s\n",
pc->data->name);
-   goto fail;
-   }
-
-   ret = gpiochip_add_pin_range(>chip, dev_name(pc->dev),
-0, pc->data->pin_base,
-pc->chip.ngpio);
-   if (ret) {
-   dev_err(pc->dev, "can't add pin range\n");
-   goto fail;
+   return ret;
}
 
return 0;
-fail:
-   gpiochip_remove(>chip);
-
-   return ret;
 }
 
 static struct regmap_config meson_regmap_config = {
-- 
1.9.1

[RFT PATCH 4/6] ARM: dts: meson8b: Add gpio-ranges properties

Signed-off-by: Neil Armstrong 
---
 arch/arm/boot/dts/meson8b.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index 41fd536..828aa49 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -198,6 +198,7 @@
reg-names = "mux", "pull", "pull-enable", 
"gpio";
gpio-controller;
#gpio-cells = <2>;
+   gpio-ranges = <_cbus 0 0 130>;
};
};
 
@@ -215,6 +216,7 @@
reg-names = "mux", "pull", "gpio";
gpio-controller;
#gpio-cells = <2>;
+   gpio-ranges = <_aobus 0 130 16>;
};
 
uart_ao_a_pins: uart_ao_a {
-- 
1.9.1

[RFT PATCH 5/6] pinctrl: meson: use gpio-ranges from DT

When trying to add a gpio-hog, we enter a weird loop where the gpio-ranges
is needed when gpiochip_add_data() is called but in the current implementation
the ranges are added from the driver afterwards.

A simple solution is to rely on the DR gpio-ranges attribute and remove the
call to gpiochip_add_pin_range().

Signed-off-by: Neil Armstrong 
---
 drivers/pinctrl/meson/pinctrl-meson.c | 14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/drivers/pinctrl/meson/pinctrl-meson.c 
b/drivers/pinctrl/meson/pinctrl-meson.c
index cf1686e..66ed70c 100644
--- a/drivers/pinctrl/meson/pinctrl-meson.c
+++ b/drivers/pinctrl/meson/pinctrl-meson.c
@@ -555,22 +555,10 @@ static int meson_gpiolib_register(struct meson_pinctrl 
*pc)
if (ret) {
dev_err(pc->dev, "can't add gpio chip %s\n",
pc->data->name);
-   goto fail;
-   }
-
-   ret = gpiochip_add_pin_range(>chip, dev_name(pc->dev),
-0, pc->data->pin_base,
-pc->chip.ngpio);
-   if (ret) {
-   dev_err(pc->dev, "can't add pin range\n");
-   goto fail;
+   return ret;
}
 
return 0;
-fail:
-   gpiochip_remove(>chip);
-
-   return ret;
 }
 
 static struct regmap_config meson_regmap_config = {
-- 
1.9.1

[RFT PATCH 6/6] ARM64: dts: meson-gxbb: Add USB Hub GPIO hog

The ODroid-C2 on-board USB Hub needs to to have it's reset signal set to
high level in order to be enumerated by the USB Host Controller.

But this management must be part of the currently in-development Generic
Power Sequence patch that will allow a USB Controller driver to start and stop
a power sequence associated to the USB Bus.

In the meantime, a simple USB Hog will work to enable the USB Hub.

Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts 
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index c59403a..6288538 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -177,6 +177,21 @@
pinctrl-names = "default";
 };
 
+_ao {
+   /*
+* WARNING: The USB Hub on the Odroid-C2 needs a reset signal
+* to be turned high in order to be detected by the USB Controller
+* This signal should be handled by a USB specific power sequence
+* in order to reset the Hub when USB bus is powered down.
+*/
+   usb-hub {
+   gpio-hog;
+   gpios = ;
+   output-high;
+   line-name = "usb-hub-reset";
+   };
+};
+
 _phy {
status = "okay";
phy-supply = <_otg_pwr>;
-- 
1.9.1

[RFT PATCH 6/6] ARM64: dts: meson-gxbb: Add USB Hub GPIO hog

The ODroid-C2 on-board USB Hub needs to to have it's reset signal set to
high level in order to be enumerated by the USB Host Controller.

But this management must be part of the currently in-development Generic
Power Sequence patch that will allow a USB Controller driver to start and stop
a power sequence associated to the USB Bus.

In the meantime, a simple USB Hog will work to enable the USB Hub.

Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts 
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index c59403a..6288538 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -177,6 +177,21 @@
pinctrl-names = "default";
 };
 
+_ao {
+   /*
+* WARNING: The USB Hub on the Odroid-C2 needs a reset signal
+* to be turned high in order to be detected by the USB Controller
+* This signal should be handled by a USB specific power sequence
+* in order to reset the Hub when USB bus is powered down.
+*/
+   usb-hub {
+   gpio-hog;
+   gpios = ;
+   output-high;
+   line-name = "usb-hub-reset";
+   };
+};
+
 _phy {
status = "okay";
phy-supply = <_otg_pwr>;
-- 
1.9.1

[RFT PATCH 1/6] ARM64: dts: meson-gxbb: Add gpio-ranges properties

Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 04b3324..84c590b 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -129,6 +129,7 @@
reg-names = "mux", "pull", "gpio";
gpio-controller;
#gpio-cells = <2>;
+   gpio-ranges = <_aobus 0 0 14>;
};
 
uart_ao_a_pins: uart_ao_a {
@@ -245,6 +246,7 @@
reg-names = "mux", "pull", "pull-enable", "gpio";
gpio-controller;
#gpio-cells = <2>;
+   gpio-ranges = <_periphs 0 14 120>;
};
 
emmc_pins: emmc {
-- 
1.9.1

[RFT PATCH 1/6] ARM64: dts: meson-gxbb: Add gpio-ranges properties

Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 04b3324..84c590b 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -129,6 +129,7 @@
reg-names = "mux", "pull", "gpio";
gpio-controller;
#gpio-cells = <2>;
+   gpio-ranges = <_aobus 0 0 14>;
};
 
uart_ao_a_pins: uart_ao_a {
@@ -245,6 +246,7 @@
reg-names = "mux", "pull", "pull-enable", "gpio";
gpio-controller;
#gpio-cells = <2>;
+   gpio-ranges = <_periphs 0 14 120>;
};
 
emmc_pins: emmc {
-- 
1.9.1

Re: [PATCH v2 05/23] MAINTAINERS: Add file patterns for dove device tree bindings

Hi Geert,
 
 On dim., mars 12 2017, Geert Uytterhoeven  wrote:

> Submitters of device tree binding documentation may forget to CC
> the subsystem maintainer if this is missing.
>
> Signed-off-by: Geert Uytterhoeven 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Sebastian Hesselbarth 
> Cc: Gregory Clement 
> Cc: linux-arm-ker...@lists.infradead.org


Applied on mvebu/soc

Thanks,

Gregory

> ---
> Please apply this patch directly if you want to be involved in device
> tree binding documentation for your subsystem.
>
> v2:
>   - No changes.
>
> Impact on next-20170310:
>
> +Jason Cooper  (maintainer:ARM/Marvell 
> Dove/MV78xx0/Orion SOC support)
> +Andrew Lunn  (maintainer:ARM/Marvell Dove/MV78xx0/Orion SOC 
> support)
> +Sebastian Hesselbarth  
> (maintainer:ARM/Marvell Dove/MV78xx0/Orion SOC support)
> +Gregory Clement  (maintainer:ARM/Marvell 
> Dove/MV78xx0/Orion SOC support)
>  Rob Herring  (maintainer:OPEN FIRMWARE AND FLATTENED 
> DEVICE TREE BINDINGS)
>  Mark Rutland  (maintainer:OPEN FIRMWARE AND FLATTENED 
> DEVICE TREE BINDINGS)
> +linux-arm-ker...@lists.infradead.org (moderated list:ARM/Marvell 
> Dove/MV78xx0/Orion SOC support)
>  devicet...@vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED DEVICE 
> TREE BINDINGS)
>  linux-kernel@vger.kernel.org (open list)
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 6428d3c82fce9670..ce461fefec6c9463 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1486,6 +1486,7 @@ M:  Sebastian Hesselbarth 
> 
>  M:   Gregory Clement 
>  L:   linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
>  S:   Maintained
> +F:   Documentation/devicetree/bindings/soc/dove/
>  F:   arch/arm/mach-dove/
>  F:   arch/arm/mach-mv78xx0/
>  F:   arch/arm/mach-orion5x/
> -- 
> 2.7.4
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH v2 05/23] MAINTAINERS: Add file patterns for dove device tree bindings

Hi Geert,
 
 On dim., mars 12 2017, Geert Uytterhoeven  wrote:

> Submitters of device tree binding documentation may forget to CC
> the subsystem maintainer if this is missing.
>
> Signed-off-by: Geert Uytterhoeven 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Sebastian Hesselbarth 
> Cc: Gregory Clement 
> Cc: linux-arm-ker...@lists.infradead.org


Applied on mvebu/soc

Thanks,

Gregory

> ---
> Please apply this patch directly if you want to be involved in device
> tree binding documentation for your subsystem.
>
> v2:
>   - No changes.
>
> Impact on next-20170310:
>
> +Jason Cooper  (maintainer:ARM/Marvell 
> Dove/MV78xx0/Orion SOC support)
> +Andrew Lunn  (maintainer:ARM/Marvell Dove/MV78xx0/Orion SOC 
> support)
> +Sebastian Hesselbarth  
> (maintainer:ARM/Marvell Dove/MV78xx0/Orion SOC support)
> +Gregory Clement  (maintainer:ARM/Marvell 
> Dove/MV78xx0/Orion SOC support)
>  Rob Herring  (maintainer:OPEN FIRMWARE AND FLATTENED 
> DEVICE TREE BINDINGS)
>  Mark Rutland  (maintainer:OPEN FIRMWARE AND FLATTENED 
> DEVICE TREE BINDINGS)
> +linux-arm-ker...@lists.infradead.org (moderated list:ARM/Marvell 
> Dove/MV78xx0/Orion SOC support)
>  devicet...@vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED DEVICE 
> TREE BINDINGS)
>  linux-kernel@vger.kernel.org (open list)
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 6428d3c82fce9670..ce461fefec6c9463 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1486,6 +1486,7 @@ M:  Sebastian Hesselbarth 
> 
>  M:   Gregory Clement 
>  L:   linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
>  S:   Maintained
> +F:   Documentation/devicetree/bindings/soc/dove/
>  F:   arch/arm/mach-dove/
>  F:   arch/arm/mach-mv78xx0/
>  F:   arch/arm/mach-orion5x/
> -- 
> 2.7.4
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH] printk: use console_trylock() in console_cpu_notify()

2017-03-23 Thread Petr Mladek

On Wed 2017-01-25 16:02:36, Petr Mladek wrote:
> On Sat 2017-01-21 19:47:29, Sergey Senozhatsky wrote:
> > There is no need to always call blocking console_lock() in
> > console_cpu_notify(), it's quite possible that console_sem can
> > be locked by other CPU on the system, either already printing
> > or soon to begin printing the messages. console_lock() in this
> > case can simply block CPU hotplug for unknown period of time
> > (console_unlock() is time unbound). Not that hotplug is very
> > fast, but still, with other CPUs being online and doing
> > printk() console_cpu_notify() can stuck.
> > 
> > Use console_trylock() instead and opt-out if console_sem is
> > already acquired from another CPU, since that CPU will do
> > the printing for us.
> > 
> > Signed-off-by: Sergey Senozhatsky 
> > ---
> >  kernel/printk/printk.c | 11 ++-
> >  1 file changed, 6 insertions(+), 5 deletions(-)
> > 
> > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > index 7180088cbb23..772eb16436ce 100644
> > --- a/kernel/printk/printk.c
> > +++ b/kernel/printk/printk.c
> > @@ -2028,15 +2028,16 @@ void resume_console(void)
> >   * @cpu: unused
> >   *
> >   * If printk() is called from a CPU that is not online yet, the messages
> > - * will be spooled but will not show up on the console.  This function is
> > - * called when a new CPU comes online (or fails to come up), and ensures
> > - * that any such output gets printed.
> > + * will be printed on the console only if there are CON_ANYTIME consoles.
> > + * This function is called when a new CPU comes online (or fails to come
> > + * up) or goes offline.
> >   */
> >  static int console_cpu_notify(unsigned int cpu)
> >  {
> > if (!cpuhp_tasks_frozen) {
> > -   console_lock();
> > -   console_unlock();
> > +   /* If trylock fails, someone else is doing the printing */
> > +   if (console_trylock())
> > +   console_unlock();
> > }
> > return 0;
> >  }
> 
> All in all. The change looks fine to me because it most likely
> improves the performance[1] and does not affect the reliability
> that much.
> 
> [1] https://lkml.kernel.org/r/20170119120744.GB435@tigerII.localdomain

Acked-by: Petr Mladek 

I am going to add this patch into printk.git for 4.12.

Best Regards,
Petr

Re: [PATCH] printk: use console_trylock() in console_cpu_notify()

2017-03-23 Thread Petr Mladek

On Wed 2017-01-25 16:02:36, Petr Mladek wrote:
> On Sat 2017-01-21 19:47:29, Sergey Senozhatsky wrote:
> > There is no need to always call blocking console_lock() in
> > console_cpu_notify(), it's quite possible that console_sem can
> > be locked by other CPU on the system, either already printing
> > or soon to begin printing the messages. console_lock() in this
> > case can simply block CPU hotplug for unknown period of time
> > (console_unlock() is time unbound). Not that hotplug is very
> > fast, but still, with other CPUs being online and doing
> > printk() console_cpu_notify() can stuck.
> > 
> > Use console_trylock() instead and opt-out if console_sem is
> > already acquired from another CPU, since that CPU will do
> > the printing for us.
> > 
> > Signed-off-by: Sergey Senozhatsky 
> > ---
> >  kernel/printk/printk.c | 11 ++-
> >  1 file changed, 6 insertions(+), 5 deletions(-)
> > 
> > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > index 7180088cbb23..772eb16436ce 100644
> > --- a/kernel/printk/printk.c
> > +++ b/kernel/printk/printk.c
> > @@ -2028,15 +2028,16 @@ void resume_console(void)
> >   * @cpu: unused
> >   *
> >   * If printk() is called from a CPU that is not online yet, the messages
> > - * will be spooled but will not show up on the console.  This function is
> > - * called when a new CPU comes online (or fails to come up), and ensures
> > - * that any such output gets printed.
> > + * will be printed on the console only if there are CON_ANYTIME consoles.
> > + * This function is called when a new CPU comes online (or fails to come
> > + * up) or goes offline.
> >   */
> >  static int console_cpu_notify(unsigned int cpu)
> >  {
> > if (!cpuhp_tasks_frozen) {
> > -   console_lock();
> > -   console_unlock();
> > +   /* If trylock fails, someone else is doing the printing */
> > +   if (console_trylock())
> > +   console_unlock();
> > }
> > return 0;
> >  }
> 
> All in all. The change looks fine to me because it most likely
> improves the performance[1] and does not affect the reliability
> that much.
> 
> [1] https://lkml.kernel.org/r/20170119120744.GB435@tigerII.localdomain

Acked-by: Petr Mladek 

I am going to add this patch into printk.git for 4.12.

Best Regards,
Petr

Re: [PATCH v3 02/12] irqchip: mtk-sysirq: extend intpol base to arbitrary number

On 19/03/17 15:26, Mars Cheng wrote:
> Originally driver only supports one base. However, MT6797 has
> more than one bases to configure interrupt polarity. To support
> possible design change, here comes a solution to use arbitrary
> number of bases.
> 
> Signed-off-by: Mars Cheng 

Acked-by: Marc Zyngier 

What is the merge strategy for this? I'm happy to take the irqchip stuff
through my tree, but there is much more in this series...

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH v3 02/12] irqchip: mtk-sysirq: extend intpol base to arbitrary number

On 19/03/17 15:26, Mars Cheng wrote:
> Originally driver only supports one base. However, MT6797 has
> more than one bases to configure interrupt polarity. To support
> possible design change, here comes a solution to use arbitrary
> number of bases.
> 
> Signed-off-by: Mars Cheng 

Acked-by: Marc Zyngier 

What is the merge strategy for this? I'm happy to take the irqchip stuff
through my tree, but there is much more in this series...

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH v1] KVM: kvm_io_bus_unregister_dev() should never fail

2017-03-23 Thread David Hildenbrand


> As this may set kvm->buses[bus_idx] to NULL, don't you also need to
> guard for bus == NULL in kvm_io_bus_destroy()? (I looked at the code on
> kvm/queue.)

very right, so something like this?

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index e1be4b4..ef1aa7f 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -728,7 +728,8 @@ static void kvm_destroy_vm(struct kvm *kvm)
spin_unlock(_lock);
kvm_free_irq_routing(kvm);
for (i = 0; i < KVM_NR_BUSES; i++) {
-   kvm_io_bus_destroy(kvm->buses[i]);
+   if (kvm->buses[i])
+   kvm_io_bus_destroy(kvm->buses[i]);
kvm->buses[i] = NULL;
}
kvm_coalesced_mmio_free(kvm);

Thanks!

> 
>>  synchronize_srcu_expedited(>srcu);
>>  kfree(bus);
>> -return r;
>> +return;
>>  }
> 


-- 

Thanks,

David

Re: [PATCH v1] KVM: kvm_io_bus_unregister_dev() should never fail

2017-03-23 Thread David Hildenbrand


> As this may set kvm->buses[bus_idx] to NULL, don't you also need to
> guard for bus == NULL in kvm_io_bus_destroy()? (I looked at the code on
> kvm/queue.)

very right, so something like this?

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index e1be4b4..ef1aa7f 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -728,7 +728,8 @@ static void kvm_destroy_vm(struct kvm *kvm)
spin_unlock(_lock);
kvm_free_irq_routing(kvm);
for (i = 0; i < KVM_NR_BUSES; i++) {
-   kvm_io_bus_destroy(kvm->buses[i]);
+   if (kvm->buses[i])
+   kvm_io_bus_destroy(kvm->buses[i]);
kvm->buses[i] = NULL;
}
kvm_coalesced_mmio_free(kvm);

Thanks!

> 
>>  synchronize_srcu_expedited(>srcu);
>>  kfree(bus);
>> -return r;
>> +return;
>>  }
> 


-- 

Thanks,

David

Re: next build: 208 builds: 9 failed, 199 passed, 857 errors, 444 warnings (next-20170323)

On Thu, Mar 23, 2017 at 6:46 AM, kernelci.org bot  wrote:

> acs5k_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
>
> Warnings:
> :1328:2: warning: #warning syscall arch_prctl not implemented [-Wcpp]
> :1328:2: warning: #warning syscall arch_prctl not implemented [-Wcpp]

patch sent today, we don't really want this syscall except on x86

> allmodconfig (arm64) — FAIL, 6 errors, 5 warnings, 0 section mismatches
>
> Errors:
> ERROR (phandle_references): Reference to non-existent node or label 
> "pwm_f_clk_pins"
> ERROR (phandle_references): Reference to non-existent node or label 
> "pwm_ao_a_3_pins"
> ERROR: Input tree has errors, aborting (use -f to force output)
> ERROR (phandle_references): Reference to non-existent node or label 
> "pwm_f_clk_pins"
> ERROR (phandle_references): Reference to non-existent node or label 
> "pwm_ao_a_3_pins"
> ERROR: Input tree has errors, aborting (use -f to force output)

Kevin has already backed out the commit that caused this.

> Warnings:
> :1325:2: warning: #warning syscall statx not implemented [-Wcpp]

Should get fixed in the next few days when the patch gets picked up for arm64.

> drivers/misc/aspeed-lpc-ctrl.c:232:17: warning: format '%x' expects argument 
> of type 'unsigned int', but argument 4 has type 'resource_size_t {aka long 
> long unsigned int}' [-Wformat=]

patch sent today

> include/uapi/linux/byteorder/big_endian.h:32:26: warning: large integer 
> implicitly truncated to unsigned type [-Woverflow]
> include/uapi/linux/byteorder/big_endian.h:32:26: warning: large integer 
> implicitly truncated to unsigned type [-Woverflow]

I sent this one a few days ago

> allmodconfig (x86) — PASS, 0 errors, 11 warnings, 0 section mismatches
>
> Warnings:
> drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects 
> argument of type 'long int', but argument 4 has type 'long long int' 
> [-Wformat=]
> drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects 
> argument of type 'long int', but argument 5 has type 'long long int' 
> [-Wformat=]

This one too.

> cavium_octeon_defconfig (mips) — FAIL, 830 errors, 3 warnings, 0 section 
> mismatches
>
> Errors:
> arch/mips/include/asm/octeon/cvmx-mio-defs.h:78:3: error: expected 
> specifier-qualifier-list before '__BITFIELD_FIELD'
> arch/mips/include/asm/octeon/cvmx-mio-defs.h:95:3: error: expected 
> specifier-qualifier-list before '__BITFIELD_FIELD'

Maybe caused by 4cd156de2ca8 ("MIPS: Octeon: Remove unused MIO types
and macros.")
I have not looked in detail

> net/bridge/br_netlink.c:1339:1: warning: the frame size of 2544 bytes is 
> larger than 2048 bytes [-Wframe-larger-than=]
> net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes is 
> larger than 2048 bytes [-Wframe-larger-than=]
> net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes is 
> larger than 2048 bytes [-Wframe-larger-than=]
> net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes is 
> larger than 2048 bytes [-Wframe-larger-than=]

Still need to rework my patches.

Arnd

Re: next build: 208 builds: 9 failed, 199 passed, 857 errors, 444 warnings (next-20170323)

On Thu, Mar 23, 2017 at 6:46 AM, kernelci.org bot  wrote:

> acs5k_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
>
> Warnings:
> :1328:2: warning: #warning syscall arch_prctl not implemented [-Wcpp]
> :1328:2: warning: #warning syscall arch_prctl not implemented [-Wcpp]

patch sent today, we don't really want this syscall except on x86

> allmodconfig (arm64) — FAIL, 6 errors, 5 warnings, 0 section mismatches
>
> Errors:
> ERROR (phandle_references): Reference to non-existent node or label 
> "pwm_f_clk_pins"
> ERROR (phandle_references): Reference to non-existent node or label 
> "pwm_ao_a_3_pins"
> ERROR: Input tree has errors, aborting (use -f to force output)
> ERROR (phandle_references): Reference to non-existent node or label 
> "pwm_f_clk_pins"
> ERROR (phandle_references): Reference to non-existent node or label 
> "pwm_ao_a_3_pins"
> ERROR: Input tree has errors, aborting (use -f to force output)

Kevin has already backed out the commit that caused this.

> Warnings:
> :1325:2: warning: #warning syscall statx not implemented [-Wcpp]

Should get fixed in the next few days when the patch gets picked up for arm64.

> drivers/misc/aspeed-lpc-ctrl.c:232:17: warning: format '%x' expects argument 
> of type 'unsigned int', but argument 4 has type 'resource_size_t {aka long 
> long unsigned int}' [-Wformat=]

patch sent today

> include/uapi/linux/byteorder/big_endian.h:32:26: warning: large integer 
> implicitly truncated to unsigned type [-Woverflow]
> include/uapi/linux/byteorder/big_endian.h:32:26: warning: large integer 
> implicitly truncated to unsigned type [-Woverflow]

I sent this one a few days ago

> allmodconfig (x86) — PASS, 0 errors, 11 warnings, 0 section mismatches
>
> Warnings:
> drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects 
> argument of type 'long int', but argument 4 has type 'long long int' 
> [-Wformat=]
> drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects 
> argument of type 'long int', but argument 5 has type 'long long int' 
> [-Wformat=]

This one too.

> cavium_octeon_defconfig (mips) — FAIL, 830 errors, 3 warnings, 0 section 
> mismatches
>
> Errors:
> arch/mips/include/asm/octeon/cvmx-mio-defs.h:78:3: error: expected 
> specifier-qualifier-list before '__BITFIELD_FIELD'
> arch/mips/include/asm/octeon/cvmx-mio-defs.h:95:3: error: expected 
> specifier-qualifier-list before '__BITFIELD_FIELD'

Maybe caused by 4cd156de2ca8 ("MIPS: Octeon: Remove unused MIO types
and macros.")
I have not looked in detail

> net/bridge/br_netlink.c:1339:1: warning: the frame size of 2544 bytes is 
> larger than 2048 bytes [-Wframe-larger-than=]
> net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes is 
> larger than 2048 bytes [-Wframe-larger-than=]
> net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes is 
> larger than 2048 bytes [-Wframe-larger-than=]
> net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes is 
> larger than 2048 bytes [-Wframe-larger-than=]

Still need to rework my patches.

Arnd

Re: [PATCH v2 4/7] arm: dts: r7s72100: Add pin controller node

Hi Geert,

On Wed, Mar 22, 2017 at 02:12:04PM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
> 
> On Mon, Mar 20, 2017 at 5:14 PM, Jacopo Mondi  
> wrote:
> > Add pin controller node with 12 gpio controller sub-nodes to
> > r7s72100 dtsi.
> >
> > Signed-off-by: Jacopo Mondi 
> 
> Reviewed-by: Geert Uytterhoeven 
> 
> > --- a/arch/arm/boot/dts/r7s72100.dtsi
> > +++ b/arch/arm/boot/dts/r7s72100.dtsi
> > @@ -183,6 +183,86 @@
> > };
> > };
> >
> > +   pinctrl: pinctrl@fcfe3000 {
> > +   compatible = "renesas,r7s72100-ports";
> > +
> > +   #pinctrl-cells = <1>;
> > +
> > +   reg = <0xfcfe3000 0x4248>;
> 
> How did you get to 0x4248? I had expected 0x4230.
> Not that it matters much, Linux rounds it up to a multiple of PAGE_SIZE 
> anyway.
> 

I guess I probably confused hex and dec values, as the correct
calculation here would have been (4200 + C * 4)
That 4248 value is what you get with (4200 + 12 * 4) so I probably
typed 12 in the calculator instead of C :)
I'll change this even if it does not make any difference..

> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds

Re: [PATCH v2 4/7] arm: dts: r7s72100: Add pin controller node

Hi Geert,

On Wed, Mar 22, 2017 at 02:12:04PM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
> 
> On Mon, Mar 20, 2017 at 5:14 PM, Jacopo Mondi  
> wrote:
> > Add pin controller node with 12 gpio controller sub-nodes to
> > r7s72100 dtsi.
> >
> > Signed-off-by: Jacopo Mondi 
> 
> Reviewed-by: Geert Uytterhoeven 
> 
> > --- a/arch/arm/boot/dts/r7s72100.dtsi
> > +++ b/arch/arm/boot/dts/r7s72100.dtsi
> > @@ -183,6 +183,86 @@
> > };
> > };
> >
> > +   pinctrl: pinctrl@fcfe3000 {
> > +   compatible = "renesas,r7s72100-ports";
> > +
> > +   #pinctrl-cells = <1>;
> > +
> > +   reg = <0xfcfe3000 0x4248>;
> 
> How did you get to 0x4248? I had expected 0x4230.
> Not that it matters much, Linux rounds it up to a multiple of PAGE_SIZE 
> anyway.
> 

I guess I probably confused hex and dec values, as the correct
calculation here would have been (4200 + C * 4)
That 4248 value is what you get with (4200 + 12 * 4) so I probably
typed 12 in the calculator instead of C :)
I'll change this even if it does not make any difference..

> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds

Re: [PATCH v3 03/12] irqchip: mtk-sysirq: prevent unnecessary visibility when set_type

On 19/03/17 15:26, Mars Cheng wrote:
> This prevent unnecessary visibility when configuring trigger type
> 
> Signed-off-by: Mars Cheng 

Acked-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH v3 03/12] irqchip: mtk-sysirq: prevent unnecessary visibility when set_type

On 19/03/17 15:26, Mars Cheng wrote:
> This prevent unnecessary visibility when configuring trigger type
> 
> Signed-off-by: Mars Cheng 

Acked-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH] arm64: kconfig: allow support for memory failure handling

2017-03-23 Thread Punit Agrawal




On 23/03/17 14:33, James Morse wrote:

Hi Punit,

On 01/02/17 21:38, Tyler Baicar wrote:

From: "Jonathan (Zhixiong) Zhang" 

If ACPI_APEI and MEMORY_FAILURE is configured, select
ACPI_APEI_MEMORY_FAILURE. This enables memory failure recovery
when such memory failure is reported through ACPI APEI. APEI
(ACPI Platform Error Interfaces) provides a means for the
platform to convey error information to the kernel.

Declare ARCH_SUPPORTS_MEMORY_FAILURE, as arm64 does support
memory failure recovery attempt.


Am I right in thinking we should wait for the hugepage issue you found with
hwpoison [0] to be fixed before arm64 can have ARCH_SUPPORTS_MEMORY_FAILURE?


We should at the least fix the huge_pte_offset() issue discovered in [0]
before we enable memory failure handling. Earlier today I posted a
RFC[1] fix for it based on Catalin's suggestion.



(If so, can this patch become part of that series to they are obviously 
related!)


Good point - I can include the patches enabling memory failure handling
on ARM64 if Tyler's fine with it.

Thanks,
Punit

[1] https://lkml.org/lkml/2017/3/23/293



Thanks,

James

[0] https://www.spinics.net/lists/arm-kernel/msg568995.html





diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index f92778d..4cd12a0 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -15,6 +15,8 @@ config ARM64
 select ARCH_HAS_SG_CHAIN
 select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
 select ARCH_USE_CMPXCHG_LOCKREF
+select ACPI_APEI_MEMORY_FAILURE if ACPI_APEI && MEMORY_FAILURE
+select ARCH_SUPPORTS_MEMORY_FAILURE
 select ARCH_SUPPORTS_ATOMIC_RMW
 select ARCH_SUPPORTS_NUMA_BALANCING
 select ARCH_WANT_COMPAT_IPC_PARSE_VERSION






IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Re: [PATCH] arm64: kconfig: allow support for memory failure handling

2017-03-23 Thread Punit Agrawal




On 23/03/17 14:33, James Morse wrote:

Hi Punit,

On 01/02/17 21:38, Tyler Baicar wrote:

From: "Jonathan (Zhixiong) Zhang" 

If ACPI_APEI and MEMORY_FAILURE is configured, select
ACPI_APEI_MEMORY_FAILURE. This enables memory failure recovery
when such memory failure is reported through ACPI APEI. APEI
(ACPI Platform Error Interfaces) provides a means for the
platform to convey error information to the kernel.

Declare ARCH_SUPPORTS_MEMORY_FAILURE, as arm64 does support
memory failure recovery attempt.


Am I right in thinking we should wait for the hugepage issue you found with
hwpoison [0] to be fixed before arm64 can have ARCH_SUPPORTS_MEMORY_FAILURE?


We should at the least fix the huge_pte_offset() issue discovered in [0]
before we enable memory failure handling. Earlier today I posted a
RFC[1] fix for it based on Catalin's suggestion.



(If so, can this patch become part of that series to they are obviously 
related!)


Good point - I can include the patches enabling memory failure handling
on ARM64 if Tyler's fine with it.

Thanks,
Punit

[1] https://lkml.org/lkml/2017/3/23/293



Thanks,

James

[0] https://www.spinics.net/lists/arm-kernel/msg568995.html





diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index f92778d..4cd12a0 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -15,6 +15,8 @@ config ARM64
 select ARCH_HAS_SG_CHAIN
 select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
 select ARCH_USE_CMPXCHG_LOCKREF
+select ACPI_APEI_MEMORY_FAILURE if ACPI_APEI && MEMORY_FAILURE
+select ARCH_SUPPORTS_MEMORY_FAILURE
 select ARCH_SUPPORTS_ATOMIC_RMW
 select ARCH_SUPPORTS_NUMA_BALANCING
 select ARCH_WANT_COMPAT_IPC_PARSE_VERSION






IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Re: [PATCH v4 1/4] pinctrl: rockchip: remove unnecessary locking

2017-03-23 Thread Julia Cartwright

Hello John-

One quick question below.  Apologies if this has been covered, but just
want to be sure.

On Thu, Mar 23, 2017 at 10:59:28AM +, John Keeping wrote:
> regmap_update_bits does its own locking and everything else accessed
> here is a local variable so there is no need to lock around it.
> 
> Signed-off-by: John Keeping 
> Reviewed-by: Heiko Stuebner 
> Tested-by: Heiko Stuebner 
> ---
> v3: unchanged
> v2.1:
> - Remove RK2928 locking in rockchip_set_pull()
> v2:
> - Also remove locking in rockchip_set_schmitt()
> ---
>  drivers/pinctrl/pinctrl-rockchip.c | 33 ++---
>  1 file changed, 2 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/pinctrl/pinctrl-rockchip.c 
> b/drivers/pinctrl/pinctrl-rockchip.c
> index bd4b63f66220..6568c867bdcd 100644
> --- a/drivers/pinctrl/pinctrl-rockchip.c
> +++ b/drivers/pinctrl/pinctrl-rockchip.c
[..]
> @@ -1185,17 +1177,14 @@ static int rockchip_set_drive_perpin(struct 
> rockchip_pin_bank *bank,
>   rmask = BIT(15) | BIT(31);
>   data |= BIT(31);
>   ret = regmap_update_bits(regmap, reg, rmask, data);
> - if (ret) {
> - spin_unlock_irqrestore(>slock, flags);
> + if (ret)
>   return ret;
> - }
>  
>   rmask = 0x3 | (0x3 << 16);
>   temp |= (0x3 << 16);
>   reg += 0x4;
>   ret = regmap_update_bits(regmap, reg, rmask, temp);

Killing the lock here means the writes to to this pair of registers (reg
and reg + 4) can be observed non-atomically.  Have you convinced
yourself that this isn't a problem?

   Julia


signature.asc
Description: PGP signature

Re: [PATCH v4 1/4] pinctrl: rockchip: remove unnecessary locking

2017-03-23 Thread Julia Cartwright

Hello John-

One quick question below.  Apologies if this has been covered, but just
want to be sure.

On Thu, Mar 23, 2017 at 10:59:28AM +, John Keeping wrote:
> regmap_update_bits does its own locking and everything else accessed
> here is a local variable so there is no need to lock around it.
> 
> Signed-off-by: John Keeping 
> Reviewed-by: Heiko Stuebner 
> Tested-by: Heiko Stuebner 
> ---
> v3: unchanged
> v2.1:
> - Remove RK2928 locking in rockchip_set_pull()
> v2:
> - Also remove locking in rockchip_set_schmitt()
> ---
>  drivers/pinctrl/pinctrl-rockchip.c | 33 ++---
>  1 file changed, 2 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/pinctrl/pinctrl-rockchip.c 
> b/drivers/pinctrl/pinctrl-rockchip.c
> index bd4b63f66220..6568c867bdcd 100644
> --- a/drivers/pinctrl/pinctrl-rockchip.c
> +++ b/drivers/pinctrl/pinctrl-rockchip.c
[..]
> @@ -1185,17 +1177,14 @@ static int rockchip_set_drive_perpin(struct 
> rockchip_pin_bank *bank,
>   rmask = BIT(15) | BIT(31);
>   data |= BIT(31);
>   ret = regmap_update_bits(regmap, reg, rmask, data);
> - if (ret) {
> - spin_unlock_irqrestore(>slock, flags);
> + if (ret)
>   return ret;
> - }
>  
>   rmask = 0x3 | (0x3 << 16);
>   temp |= (0x3 << 16);
>   reg += 0x4;
>   ret = regmap_update_bits(regmap, reg, rmask, temp);

Killing the lock here means the writes to to this pair of registers (reg
and reg + 4) can be observed non-atomically.  Have you convinced
yourself that this isn't a problem?

   Julia


signature.asc
Description: PGP signature

[PATCH] drivers/misc: aspeed-lpc-ctrl: fix printk format warning again

The format string is still broken after the first attempt to fix it:

drivers/misc/aspeed-lpc-ctrl.c: In function 'aspeed_lpc_ctrl_probe':
drivers/misc/aspeed-lpc-ctrl.c:232:17: error: format '%x' expects argument of 
type 'unsigned int', but argument 4 has type 'resource_size_t {aka long long 
unsigned int}' [-Werror=format=]

We can actually just print the resource structure directly here.

Fixes: 132c93d4215c ("drivers/misc: Aspeed LPC control fix compile error and 
warning")
Signed-off-by: Arnd Bergmann 
---
 drivers/misc/aspeed-lpc-ctrl.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/misc/aspeed-lpc-ctrl.c b/drivers/misc/aspeed-lpc-ctrl.c
index c654651a7b6d..b5439643f54b 100644
--- a/drivers/misc/aspeed-lpc-ctrl.c
+++ b/drivers/misc/aspeed-lpc-ctrl.c
@@ -229,8 +229,7 @@ static int aspeed_lpc_ctrl_probe(struct platform_device 
*pdev)
if (rc)
dev_err(dev, "Unable to register device\n");
else
-   dev_info(dev, "Loaded at %pap (0x%08x)\n",
-   _ctrl->mem_base, lpc_ctrl->mem_size);
+   dev_info(dev, "Loaded at %pr\n", );
 
return rc;
 }
-- 
2.9.0

[PATCH] drivers/misc: aspeed-lpc-ctrl: fix printk format warning again

The format string is still broken after the first attempt to fix it:

drivers/misc/aspeed-lpc-ctrl.c: In function 'aspeed_lpc_ctrl_probe':
drivers/misc/aspeed-lpc-ctrl.c:232:17: error: format '%x' expects argument of 
type 'unsigned int', but argument 4 has type 'resource_size_t {aka long long 
unsigned int}' [-Werror=format=]

We can actually just print the resource structure directly here.

Fixes: 132c93d4215c ("drivers/misc: Aspeed LPC control fix compile error and 
warning")
Signed-off-by: Arnd Bergmann 
---
 drivers/misc/aspeed-lpc-ctrl.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/misc/aspeed-lpc-ctrl.c b/drivers/misc/aspeed-lpc-ctrl.c
index c654651a7b6d..b5439643f54b 100644
--- a/drivers/misc/aspeed-lpc-ctrl.c
+++ b/drivers/misc/aspeed-lpc-ctrl.c
@@ -229,8 +229,7 @@ static int aspeed_lpc_ctrl_probe(struct platform_device 
*pdev)
if (rc)
dev_err(dev, "Unable to register device\n");
else
-   dev_info(dev, "Loaded at %pap (0x%08x)\n",
-   _ctrl->mem_base, lpc_ctrl->mem_size);
+   dev_info(dev, "Loaded at %pr\n", );
 
return rc;
 }
-- 
2.9.0

[PATCH] bna: avoid writing uninitialized data into hw registers

The latest gcc-7 snapshot warns about bfa_ioc_send_enable/bfa_ioc_send_disable
writing undefined values into the hardware registers:

drivers/net/ethernet/brocade/bna/bfa_ioc.c: In function 
'bfa_iocpf_sm_disabling_entry':
arch/arm/include/asm/io.h:109:22: error: '*((void *)_req+4)' is used 
uninitialized in this function [-Werror=uninitialized]
arch/arm/include/asm/io.h:109:22: error: '*((void *)_req+8)' is used 
uninitialized in this function [-Werror=uninitialized]

The two functions look like they should do the same thing, but only one
of them initializes the time stamp and clscode field. The fact that we
only get a warning for one of the two functions seems to be arbitrary,
based on the inlining decisions in the compiler.

To address this, I'm making both functions do the same thing:

- set the clscode from the ioc structure in both
- set the time stamp from ktime_get_real_seconds (which also
  avoids the signed-integer overflow in 2038 and extends the
  well-defined behavior until 2106).
- zero-fill the reserved field

Fixes: 8b230ed8ec96 ("bna: Brocade 10Gb Ethernet device driver")
Signed-off-by: Arnd Bergmann 
---
 drivers/net/ethernet/brocade/bna/bfa_ioc.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/brocade/bna/bfa_ioc.c 
b/drivers/net/ethernet/brocade/bna/bfa_ioc.c
index 9e59663a6ead..0f6811860ad5 100644
--- a/drivers/net/ethernet/brocade/bna/bfa_ioc.c
+++ b/drivers/net/ethernet/brocade/bna/bfa_ioc.c
@@ -1930,13 +1930,13 @@ static void
 bfa_ioc_send_enable(struct bfa_ioc *ioc)
 {
struct bfi_ioc_ctrl_req enable_req;
-   struct timeval tv;
 
bfi_h2i_set(enable_req.mh, BFI_MC_IOC, BFI_IOC_H2I_ENABLE_REQ,
bfa_ioc_portid(ioc));
enable_req.clscode = htons(ioc->clscode);
-   do_gettimeofday();
-   enable_req.tv_sec = ntohl(tv.tv_sec);
+   enable_req.rsvd = htons(0);
+   /* overflow in 2106 */
+   enable_req.tv_sec = ntohl(ktime_get_real_seconds());
bfa_ioc_mbox_send(ioc, _req, sizeof(struct bfi_ioc_ctrl_req));
 }
 
@@ -1947,6 +1947,10 @@ bfa_ioc_send_disable(struct bfa_ioc *ioc)
 
bfi_h2i_set(disable_req.mh, BFI_MC_IOC, BFI_IOC_H2I_DISABLE_REQ,
bfa_ioc_portid(ioc));
+   disable_req.clscode = htons(ioc->clscode);
+   disable_req.rsvd = htons(0);
+   /* overflow in 2106 */
+   disable_req.tv_sec = ntohl(ktime_get_real_seconds());
bfa_ioc_mbox_send(ioc, _req, sizeof(struct bfi_ioc_ctrl_req));
 }
 
-- 
2.9.0

Hello,

2017-03-23 Thread simpore rachidi



Dear Friend,

Can you be able to assist in handling this transaction? More details will be 
sent to you as soon as i receive your response. An approval will be granted to 
you as soon as you apply for the release of the fund to you.

I need your urgent assistance in transferring the sum of US$5 Million (Five 
million U.S Dollars) to your account. My requirements below, before we can 
proceed into this transaction:

1. Full name: .
2. Current Address: ...
3. Phone Number: .
4. E-mail Address: .
4. Occupation:
5. Age: ...
6. Country: 

Waiting for your urgent response.

Mr. Simpore Rachidi.

[PATCH] bna: avoid writing uninitialized data into hw registers

The latest gcc-7 snapshot warns about bfa_ioc_send_enable/bfa_ioc_send_disable
writing undefined values into the hardware registers:

drivers/net/ethernet/brocade/bna/bfa_ioc.c: In function 
'bfa_iocpf_sm_disabling_entry':
arch/arm/include/asm/io.h:109:22: error: '*((void *)_req+4)' is used 
uninitialized in this function [-Werror=uninitialized]
arch/arm/include/asm/io.h:109:22: error: '*((void *)_req+8)' is used 
uninitialized in this function [-Werror=uninitialized]

The two functions look like they should do the same thing, but only one
of them initializes the time stamp and clscode field. The fact that we
only get a warning for one of the two functions seems to be arbitrary,
based on the inlining decisions in the compiler.

To address this, I'm making both functions do the same thing:

- set the clscode from the ioc structure in both
- set the time stamp from ktime_get_real_seconds (which also
  avoids the signed-integer overflow in 2038 and extends the
  well-defined behavior until 2106).
- zero-fill the reserved field

Fixes: 8b230ed8ec96 ("bna: Brocade 10Gb Ethernet device driver")
Signed-off-by: Arnd Bergmann 
---
 drivers/net/ethernet/brocade/bna/bfa_ioc.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/brocade/bna/bfa_ioc.c 
b/drivers/net/ethernet/brocade/bna/bfa_ioc.c
index 9e59663a6ead..0f6811860ad5 100644
--- a/drivers/net/ethernet/brocade/bna/bfa_ioc.c
+++ b/drivers/net/ethernet/brocade/bna/bfa_ioc.c
@@ -1930,13 +1930,13 @@ static void
 bfa_ioc_send_enable(struct bfa_ioc *ioc)
 {
struct bfi_ioc_ctrl_req enable_req;
-   struct timeval tv;
 
bfi_h2i_set(enable_req.mh, BFI_MC_IOC, BFI_IOC_H2I_ENABLE_REQ,
bfa_ioc_portid(ioc));
enable_req.clscode = htons(ioc->clscode);
-   do_gettimeofday();
-   enable_req.tv_sec = ntohl(tv.tv_sec);
+   enable_req.rsvd = htons(0);
+   /* overflow in 2106 */
+   enable_req.tv_sec = ntohl(ktime_get_real_seconds());
bfa_ioc_mbox_send(ioc, _req, sizeof(struct bfi_ioc_ctrl_req));
 }
 
@@ -1947,6 +1947,10 @@ bfa_ioc_send_disable(struct bfa_ioc *ioc)
 
bfi_h2i_set(disable_req.mh, BFI_MC_IOC, BFI_IOC_H2I_DISABLE_REQ,
bfa_ioc_portid(ioc));
+   disable_req.clscode = htons(ioc->clscode);
+   disable_req.rsvd = htons(0);
+   /* overflow in 2106 */
+   disable_req.tv_sec = ntohl(ktime_get_real_seconds());
bfa_ioc_mbox_send(ioc, _req, sizeof(struct bfi_ioc_ctrl_req));
 }
 
-- 
2.9.0

Hello,

2017-03-23 Thread simpore rachidi



Dear Friend,

Can you be able to assist in handling this transaction? More details will be 
sent to you as soon as i receive your response. An approval will be granted to 
you as soon as you apply for the release of the fund to you.

I need your urgent assistance in transferring the sum of US$5 Million (Five 
million U.S Dollars) to your account. My requirements below, before we can 
proceed into this transaction:

1. Full name: .
2. Current Address: ...
3. Phone Number: .
4. E-mail Address: .
4. Occupation:
5. Age: ...
6. Country: 

Waiting for your urgent response.

Mr. Simpore Rachidi.

net/sched: GPF in qdisc_hash_add

Hello,

I've hit the following GPF while running syzkaller on commit
093b995e3b55a0ae0670226ddfcb05bfbf0099ae.  Note the preceding injected
kmalloc failure, most likely it's the root cause.

FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
CPU: 2 PID: 12732 Comm: syz-executor6 Not tainted 4.11.0-rc3+ #365
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x1b8/0x28d lib/dump_stack.c:52
 fail_dump lib/fault-inject.c:52 [inline]
 should_fail+0x804/0x8c0 lib/fault-inject.c:154
 should_failslab+0xec/0x120 mm/failslab.c:31
 slab_pre_alloc_hook mm/slab.h:434 [inline]
 slab_alloc_node mm/slab.c:3315 [inline]
 kmem_cache_alloc_node_trace+0x200/0x720 mm/slab.c:3679
 __do_kmalloc_node mm/slab.c:3699 [inline]
 __kmalloc_node+0x33/0x70 mm/slab.c:3707
 kmalloc_node include/linux/slab.h:532 [inline]
 kzalloc_node include/linux/slab.h:674 [inline]
 qdisc_alloc+0xf4/0x670 net/sched/sch_generic.c:604
 qdisc_create_dflt+0x59/0x160 net/sched/sch_generic.c:652
 attach_one_default_qdisc net/sched/sch_generic.c:767 [inline]
 netdev_for_each_tx_queue include/linux/netdevice.h:1948 [inline]
 attach_default_qdiscs net/sched/sch_generic.c:786 [inline]
 dev_activate+0x58d/0x920 net/sched/sch_generic.c:829
 __dev_open+0x25b/0x360 net/core/dev.c:1348
 __dev_change_flags+0x159/0x3d0 net/core/dev.c:6460
 dev_change_flags+0x88/0x140 net/core/dev.c:6525
 dev_ifsioc+0x51f/0x9b0 net/core/dev_ioctl.c:254
 dev_ioctl+0x1fe/0x1030 net/core/dev_ioctl.c:532
 sock_do_ioctl+0x94/0xb0 net/socket.c:902
 sock_ioctl+0x2c2/0x440 net/socket.c:993
 vfs_ioctl fs/ioctl.c:45 [inline]
 do_vfs_ioctl+0x1af/0x16d0 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700 [inline]
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x445b79
RSP: 002b:7f68665cf858 EFLAGS: 0286 ORIG_RAX: 0010
RAX: ffda RBX: 00708000 RCX: 00445b79
RDX: 2000 RSI: 8914 RDI: 0019
RBP: 0086 R08:  R09: 
R10:  R11: 0286 R12: 004a7e31
R13:  R14: 7f68665cf618 R15: 7f68665cf788
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] SMP KASAN
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 2 PID: 12732 Comm: syz-executor6 Not tainted 4.11.0-rc3+ #365
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 880062b7a2c0 task.stack: 88003348
RIP: 0010:qdisc_hash_add.part.19+0xb6/0x3c0 net/sched/sch_api.c:280
RSP: 0018:880033487820 EFLAGS: 00010202
RAX: dc00 RBX: 85357e00 RCX: c90002b24000
RDX: 007a RSI: 835a523a RDI: 03d0
RBP: 8800334878b8 R08: fbfff0a6afeb R09: fbfff0a6afeb
R10: 0001 R11: fbfff0a6afea R12: 85357e48
R13: 110006690f06 R14: 880033487890 R15: 
FS:  7f68665d0700() GS:88006e20() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 004c2d44 CR3: 3c6f8000 CR4: 26e0
Call Trace:
 qdisc_hash_add+0x76/0x90 net/sched/sch_api.c:279
 attach_default_qdiscs net/sched/sch_generic.c:798 [inline]
 dev_activate+0x6ca/0x920 net/sched/sch_generic.c:829
 __dev_open+0x25b/0x360 net/core/dev.c:1348
 __dev_change_flags+0x159/0x3d0 net/core/dev.c:6460
 dev_change_flags+0x88/0x140 net/core/dev.c:6525
 dev_ifsioc+0x51f/0x9b0 net/core/dev_ioctl.c:254
 dev_ioctl+0x1fe/0x1030 net/core/dev_ioctl.c:532
 sock_do_ioctl+0x94/0xb0 net/socket.c:902
 sock_ioctl+0x2c2/0x440 net/socket.c:993
 vfs_ioctl fs/ioctl.c:45 [inline]
 do_vfs_ioctl+0x1af/0x16d0 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700 [inline]
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x445b79
RSP: 002b:7f68665cf858 EFLAGS: 0286 ORIG_RAX: 0010
RAX: ffda RBX: 00708000 RCX: 00445b79
RDX: 2000 RSI: 8914 RDI: 0019
RBP: 0086 R08:  R09: 
R10:  R11: 0286 R12: 004a7e31
R13:  R14: 7f68665cf618 R15: 7f68665cf788
Code: 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 5a 02 00 00 4d 8b 3f 48 b8
00 00 00 00 00 fc ff df 49 8d bf d0 03 00 00 48 89 fa 48 c1 ea 03 <80>
3c 02 00 0f 85 c2 02 00 00 49 81 bf d0 03 00 00 00 7e 35 85
RIP: qdisc_hash_add.part.19+0xb6/0x3c0 net/sched/sch_api.c:280 RSP:
880033487820
---[ end trace 1529d12967754f9c ]---

net/sched: GPF in qdisc_hash_add

Hello,

I've hit the following GPF while running syzkaller on commit
093b995e3b55a0ae0670226ddfcb05bfbf0099ae.  Note the preceding injected
kmalloc failure, most likely it's the root cause.

FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
CPU: 2 PID: 12732 Comm: syz-executor6 Not tainted 4.11.0-rc3+ #365
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x1b8/0x28d lib/dump_stack.c:52
 fail_dump lib/fault-inject.c:52 [inline]
 should_fail+0x804/0x8c0 lib/fault-inject.c:154
 should_failslab+0xec/0x120 mm/failslab.c:31
 slab_pre_alloc_hook mm/slab.h:434 [inline]
 slab_alloc_node mm/slab.c:3315 [inline]
 kmem_cache_alloc_node_trace+0x200/0x720 mm/slab.c:3679
 __do_kmalloc_node mm/slab.c:3699 [inline]
 __kmalloc_node+0x33/0x70 mm/slab.c:3707
 kmalloc_node include/linux/slab.h:532 [inline]
 kzalloc_node include/linux/slab.h:674 [inline]
 qdisc_alloc+0xf4/0x670 net/sched/sch_generic.c:604
 qdisc_create_dflt+0x59/0x160 net/sched/sch_generic.c:652
 attach_one_default_qdisc net/sched/sch_generic.c:767 [inline]
 netdev_for_each_tx_queue include/linux/netdevice.h:1948 [inline]
 attach_default_qdiscs net/sched/sch_generic.c:786 [inline]
 dev_activate+0x58d/0x920 net/sched/sch_generic.c:829
 __dev_open+0x25b/0x360 net/core/dev.c:1348
 __dev_change_flags+0x159/0x3d0 net/core/dev.c:6460
 dev_change_flags+0x88/0x140 net/core/dev.c:6525
 dev_ifsioc+0x51f/0x9b0 net/core/dev_ioctl.c:254
 dev_ioctl+0x1fe/0x1030 net/core/dev_ioctl.c:532
 sock_do_ioctl+0x94/0xb0 net/socket.c:902
 sock_ioctl+0x2c2/0x440 net/socket.c:993
 vfs_ioctl fs/ioctl.c:45 [inline]
 do_vfs_ioctl+0x1af/0x16d0 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700 [inline]
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x445b79
RSP: 002b:7f68665cf858 EFLAGS: 0286 ORIG_RAX: 0010
RAX: ffda RBX: 00708000 RCX: 00445b79
RDX: 2000 RSI: 8914 RDI: 0019
RBP: 0086 R08:  R09: 
R10:  R11: 0286 R12: 004a7e31
R13:  R14: 7f68665cf618 R15: 7f68665cf788
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] SMP KASAN
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 2 PID: 12732 Comm: syz-executor6 Not tainted 4.11.0-rc3+ #365
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 880062b7a2c0 task.stack: 88003348
RIP: 0010:qdisc_hash_add.part.19+0xb6/0x3c0 net/sched/sch_api.c:280
RSP: 0018:880033487820 EFLAGS: 00010202
RAX: dc00 RBX: 85357e00 RCX: c90002b24000
RDX: 007a RSI: 835a523a RDI: 03d0
RBP: 8800334878b8 R08: fbfff0a6afeb R09: fbfff0a6afeb
R10: 0001 R11: fbfff0a6afea R12: 85357e48
R13: 110006690f06 R14: 880033487890 R15: 
FS:  7f68665d0700() GS:88006e20() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 004c2d44 CR3: 3c6f8000 CR4: 26e0
Call Trace:
 qdisc_hash_add+0x76/0x90 net/sched/sch_api.c:279
 attach_default_qdiscs net/sched/sch_generic.c:798 [inline]
 dev_activate+0x6ca/0x920 net/sched/sch_generic.c:829
 __dev_open+0x25b/0x360 net/core/dev.c:1348
 __dev_change_flags+0x159/0x3d0 net/core/dev.c:6460
 dev_change_flags+0x88/0x140 net/core/dev.c:6525
 dev_ifsioc+0x51f/0x9b0 net/core/dev_ioctl.c:254
 dev_ioctl+0x1fe/0x1030 net/core/dev_ioctl.c:532
 sock_do_ioctl+0x94/0xb0 net/socket.c:902
 sock_ioctl+0x2c2/0x440 net/socket.c:993
 vfs_ioctl fs/ioctl.c:45 [inline]
 do_vfs_ioctl+0x1af/0x16d0 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700 [inline]
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x445b79
RSP: 002b:7f68665cf858 EFLAGS: 0286 ORIG_RAX: 0010
RAX: ffda RBX: 00708000 RCX: 00445b79
RDX: 2000 RSI: 8914 RDI: 0019
RBP: 0086 R08:  R09: 
R10:  R11: 0286 R12: 004a7e31
R13:  R14: 7f68665cf618 R15: 7f68665cf788
Code: 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 5a 02 00 00 4d 8b 3f 48 b8
00 00 00 00 00 fc ff df 49 8d bf d0 03 00 00 48 89 fa 48 c1 ea 03 <80>
3c 02 00 0f 85 c2 02 00 00 49 81 bf d0 03 00 00 00 7e 35 85
RIP: qdisc_hash_add.part.19+0xb6/0x3c0 net/sched/sch_api.c:280 RSP:
880033487820
---[ end trace 1529d12967754f9c ]---

Re: [RFC] Add option to mount only a pids subset

2017-03-23 Thread Oleg Nesterov

Again, I can't really review this, I know nothing about vfs, but since
nobody else replied...

On 03/20, Alexey Gladkov wrote:
>
> @@ -97,7 +169,23 @@ static struct dentry *proc_mount(struct file_system_type 
> *fs_type,
>   ns = task_active_pid_ns(current);
>   }
>
> - return mount_ns(fs_type, flags, data, ns, ns->user_ns, proc_fill_super);
> + root = mount_ns(fs_type, flags, data, ns, ns->user_ns, proc_fill_super);
> +
> + if (!IS_ERR(root)) {
> + if (!proc_fill_options(data, ))
> + return ERR_PTR(-EINVAL);

So we have to call proc_fill_options() twice, not good... Yes, I understand
why, but perhaps we factor it out somehow, we can pack options + pid_ns into
sb->s_fs_info. Nevermind, this is minor.

> + if (opts.pid_only) {
> + int ret;
> +
> + if (!ns->pidfs && (ret = fill_pidfs_root(root->d_sb)))
> + return ERR_PTR(ret);
> +
> + root = ns->pidfs;

Afaics this lacks dget(ns->pidfs) which should pair with dput(mnt.mnt_root)
in cleanup_mnt(). IIUC otherwise ns->pidfs can go away after umount, OTOH,
if we return ns->pidfs then dget(sb->s_root) in mount_ns() is not balanced.
But this all is fixeable.

So with this change "mount -opidonly" creates another IS_ROOT() dentry which
is not equal to sb->s_root. I simply do not know if this is technically
correct or not... but, say, the "Only bind mounts can have disconnected paths"
comment in path_connected() makes me worry ;)

And this obviously means that /path-to-pidonly-mnt/ won't share dentries with
the normal /proc mount. Not really good imo even if not really wrong... Lets
look at proc_flush_task(). The exiting task will flush its $pid dentries in
/proc/ but not in /path-to-pidonly-mnt/ iiuc. Again, not really a bug, but
still...

Oleg.

Re: [RFC] Add option to mount only a pids subset

2017-03-23 Thread Oleg Nesterov

Again, I can't really review this, I know nothing about vfs, but since
nobody else replied...

On 03/20, Alexey Gladkov wrote:
>
> @@ -97,7 +169,23 @@ static struct dentry *proc_mount(struct file_system_type 
> *fs_type,
>   ns = task_active_pid_ns(current);
>   }
>
> - return mount_ns(fs_type, flags, data, ns, ns->user_ns, proc_fill_super);
> + root = mount_ns(fs_type, flags, data, ns, ns->user_ns, proc_fill_super);
> +
> + if (!IS_ERR(root)) {
> + if (!proc_fill_options(data, ))
> + return ERR_PTR(-EINVAL);

So we have to call proc_fill_options() twice, not good... Yes, I understand
why, but perhaps we factor it out somehow, we can pack options + pid_ns into
sb->s_fs_info. Nevermind, this is minor.

> + if (opts.pid_only) {
> + int ret;
> +
> + if (!ns->pidfs && (ret = fill_pidfs_root(root->d_sb)))
> + return ERR_PTR(ret);
> +
> + root = ns->pidfs;

Afaics this lacks dget(ns->pidfs) which should pair with dput(mnt.mnt_root)
in cleanup_mnt(). IIUC otherwise ns->pidfs can go away after umount, OTOH,
if we return ns->pidfs then dget(sb->s_root) in mount_ns() is not balanced.
But this all is fixeable.

So with this change "mount -opidonly" creates another IS_ROOT() dentry which
is not equal to sb->s_root. I simply do not know if this is technically
correct or not... but, say, the "Only bind mounts can have disconnected paths"
comment in path_connected() makes me worry ;)

And this obviously means that /path-to-pidonly-mnt/ won't share dentries with
the normal /proc mount. Not really good imo even if not really wrong... Lets
look at proc_flush_task(). The exiting task will flush its $pid dentries in
/proc/ but not in /path-to-pidonly-mnt/ iiuc. Again, not really a bug, but
still...

Oleg.

Re: [PATCH v1] KVM: kvm_io_bus_unregister_dev() should never fail

On Thu, 23 Mar 2017 15:34:41 +0100
David Hildenbrand  wrote:

> No caller currently checks the return value of
> kvm_io_bus_unregister_dev(). This is evil, as all callers silently go on
> freeing their device. A stale reference will remain in the io_bus,
> getting at least used again, when the iobus gets teared down on
> kvm_destroy_vm() - leading to use after free errors.
> 
> There is nothing the callers could do, except retrying over and over
> again.
> 
> So let's simply remove the bus altogether, print an error and make
> sure no one can access this broken bus again (returning -ENOMEM on any
> attempt to access it).
> 
> Fixes: e93f8a0f821e ("KVM: convert io_bus to SRCU")
> Cc: sta...@vger.kernel.org # 3.4+
> Reported-by: Dmitry Vyukov 
> Signed-off-by: David Hildenbrand 

>  /* Caller must hold slots_lock. */
> -int kvm_io_bus_unregister_dev(struct kvm *kvm, enum kvm_bus bus_idx,
> -   struct kvm_io_device *dev)
> +void kvm_io_bus_unregister_dev(struct kvm *kvm, enum kvm_bus bus_idx,
> +struct kvm_io_device *dev)
>  {
> - int i, r;
> + int i;
>   struct kvm_io_bus *new_bus, *bus;
>  
>   bus = kvm->buses[bus_idx];
> -
> - /*
> -  * It's possible the bus being released before hand. If so,
> -  * we're done here.
> -  */
>   if (!bus)
> - return 0;
> + return;
>  
> - r = -ENOENT;
>   for (i = 0; i < bus->dev_count; i++)
>   if (bus->range[i].dev == dev) {
> - r = 0;
>   break;
>   }
>  
> - if (r)
> - return r;
> + if (i == bus->dev_count)
> + return;
>  
>   new_bus = kmalloc(sizeof(*bus) + ((bus->dev_count - 1) *
> sizeof(struct kvm_io_range)), GFP_KERNEL);
> - if (!new_bus)
> - return -ENOMEM;
> + if (!new_bus)  {
> + pr_err("kvm: failed to shrink bus, removing it completely\n");
> + goto broken;
> + }
>  
>   memcpy(new_bus, bus, sizeof(*bus) + i * sizeof(struct kvm_io_range));
>   new_bus->dev_count--;
>   memcpy(new_bus->range + i, bus->range + i + 1,
>  (new_bus->dev_count - i) * sizeof(struct kvm_io_range));
>  
> +broken:
>   rcu_assign_pointer(kvm->buses[bus_idx], new_bus);

As this may set kvm->buses[bus_idx] to NULL, don't you also need to
guard for bus == NULL in kvm_io_bus_destroy()? (I looked at the code on
kvm/queue.)

>   synchronize_srcu_expedited(>srcu);
>   kfree(bus);
> - return r;
> + return;
>  }

Re: [PATCH v1] KVM: kvm_io_bus_unregister_dev() should never fail

On Thu, 23 Mar 2017 15:34:41 +0100
David Hildenbrand  wrote:

> No caller currently checks the return value of
> kvm_io_bus_unregister_dev(). This is evil, as all callers silently go on
> freeing their device. A stale reference will remain in the io_bus,
> getting at least used again, when the iobus gets teared down on
> kvm_destroy_vm() - leading to use after free errors.
> 
> There is nothing the callers could do, except retrying over and over
> again.
> 
> So let's simply remove the bus altogether, print an error and make
> sure no one can access this broken bus again (returning -ENOMEM on any
> attempt to access it).
> 
> Fixes: e93f8a0f821e ("KVM: convert io_bus to SRCU")
> Cc: sta...@vger.kernel.org # 3.4+
> Reported-by: Dmitry Vyukov 
> Signed-off-by: David Hildenbrand 

>  /* Caller must hold slots_lock. */
> -int kvm_io_bus_unregister_dev(struct kvm *kvm, enum kvm_bus bus_idx,
> -   struct kvm_io_device *dev)
> +void kvm_io_bus_unregister_dev(struct kvm *kvm, enum kvm_bus bus_idx,
> +struct kvm_io_device *dev)
>  {
> - int i, r;
> + int i;
>   struct kvm_io_bus *new_bus, *bus;
>  
>   bus = kvm->buses[bus_idx];
> -
> - /*
> -  * It's possible the bus being released before hand. If so,
> -  * we're done here.
> -  */
>   if (!bus)
> - return 0;
> + return;
>  
> - r = -ENOENT;
>   for (i = 0; i < bus->dev_count; i++)
>   if (bus->range[i].dev == dev) {
> - r = 0;
>   break;
>   }
>  
> - if (r)
> - return r;
> + if (i == bus->dev_count)
> + return;
>  
>   new_bus = kmalloc(sizeof(*bus) + ((bus->dev_count - 1) *
> sizeof(struct kvm_io_range)), GFP_KERNEL);
> - if (!new_bus)
> - return -ENOMEM;
> + if (!new_bus)  {
> + pr_err("kvm: failed to shrink bus, removing it completely\n");
> + goto broken;
> + }
>  
>   memcpy(new_bus, bus, sizeof(*bus) + i * sizeof(struct kvm_io_range));
>   new_bus->dev_count--;
>   memcpy(new_bus->range + i, bus->range + i + 1,
>  (new_bus->dev_count - i) * sizeof(struct kvm_io_range));
>  
> +broken:
>   rcu_assign_pointer(kvm->buses[bus_idx], new_bus);

As this may set kvm->buses[bus_idx] to NULL, don't you also need to
guard for bus == NULL in kvm_io_bus_destroy()? (I looked at the code on
kvm/queue.)

>   synchronize_srcu_expedited(>srcu);
>   kfree(bus);
> - return r;
> + return;
>  }

Re: [RFC] Add option to mount only a pids subset

2017-03-23 Thread Djalal Harouni

Hi Alexey,

On Mon, Mar 20, 2017 at 1:58 PM, Alexey Gladkov
 wrote:
>
>
> Al Viro, this patch looks better ?
>
> == Overview ==
>
> Some of the container virtualization systems are mounted /proc inside
> the container. This is done in most cases to operate with information
> about the processes. Knowing that /proc filesystem is not fully
> virtualized they are mounted on top of dangerous places empty files or
> directories (for exmaple /proc/sys, /proc/kcore, /sys/firmware, etc.).
>
> The structure of this filesystem is dynamic and any module can create a
> new object which will not necessarily be virtualized. There are
> proprietary modules that aren't in the mainline whose work we can not
> verify.
>
> This opens up a potential threat to the system. The developers of the
> virtualization system can't predict all dangerous places in /proc by
> definition.
>
> A more effective solution would be to mount into the container only what
> is necessary and ignore the rest.
>
> Right now there is the opportunity to pass in the container any port of
> the /proc filesystem using mount --bind expect the pids.
>
> This patch allows to mount only the part of /proc related to pids without
> rest objects. Since this is an option for /proc, flags applied to /proc
> have an effect on this subset of filesystem.

I just sent a patch that also has to deal with proc hidepid here:
https://lkml.org/lkml/2017/3/23/505

I'm not sure if that's the right approach, it is still buggy, however
seems that your patch also stores the mount option inside the
pid_namespace which may get propagated to all mounts inside same pidns
?

I didn't have enough time but maybe if they are related we can work it
out together ?

Thank you!


-- 
tixxdz

Re: [RFC] Add option to mount only a pids subset

2017-03-23 Thread Djalal Harouni

Hi Alexey,

On Mon, Mar 20, 2017 at 1:58 PM, Alexey Gladkov
 wrote:
>
>
> Al Viro, this patch looks better ?
>
> == Overview ==
>
> Some of the container virtualization systems are mounted /proc inside
> the container. This is done in most cases to operate with information
> about the processes. Knowing that /proc filesystem is not fully
> virtualized they are mounted on top of dangerous places empty files or
> directories (for exmaple /proc/sys, /proc/kcore, /sys/firmware, etc.).
>
> The structure of this filesystem is dynamic and any module can create a
> new object which will not necessarily be virtualized. There are
> proprietary modules that aren't in the mainline whose work we can not
> verify.
>
> This opens up a potential threat to the system. The developers of the
> virtualization system can't predict all dangerous places in /proc by
> definition.
>
> A more effective solution would be to mount into the container only what
> is necessary and ignore the rest.
>
> Right now there is the opportunity to pass in the container any port of
> the /proc filesystem using mount --bind expect the pids.
>
> This patch allows to mount only the part of /proc related to pids without
> rest objects. Since this is an option for /proc, flags applied to /proc
> have an effect on this subset of filesystem.

I just sent a patch that also has to deal with proc hidepid here:
https://lkml.org/lkml/2017/3/23/505

I'm not sure if that's the right approach, it is still buggy, however
seems that your patch also stores the mount option inside the
pid_namespace which may get propagated to all mounts inside same pidns
?

I didn't have enough time but maybe if they are related we can work it
out together ?

Thank you!


-- 
tixxdz

Re: [PATCH v2] HV: properly delay KVP packets when negotiation is in progress

2017-03-23 Thread Vitaly Kuznetsov

Long Li  writes:

> The host may send multiple negotiation packets (due to timeout) before 
> the KVP user-mode daemon is connected. We need to defer processing  
> those packets until the daemon is negotiated and connected. It's okay
> for guest to respond to all negotiation packets.
>
> In addition, the host may send multiple staged KVP requests as soon as
> negotiation is done. We need to properly process those packets using 
> one tasklet for exclusive access to ring buffer.
>
> This patch is based on the work of Nick Meier 
> 
>
> The patch v2 has incorporated suggestion from Vitaly Kuznetsov 
> .
>
> Signed-off-by: Long Li 
> ---
>  drivers/hv/hv_kvp.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c
> index de26371..845b70b 100644
> --- a/drivers/hv/hv_kvp.c
> +++ b/drivers/hv/hv_kvp.c
> @@ -113,7 +113,7 @@ static void kvp_poll_wrapper(void *channel)
>  {
>   /* Transaction is finished, reset the state here to avoid races. */
>   kvp_transaction.state = HVUTIL_READY;
> - hv_kvp_onchannelcallback(channel);
> + tasklet_schedule(&((struct vmbus_channel*)channel)->callback_event);
>  }

There is one more function in the code which calls
hv_kvp_onchannelcallback():

static void kvp_host_handshake_func(struct work_struct *dummy)
{
hv_poll_channel(kvp_transaction.recv_channel, hv_kvp_onchannelcallback);
}

we can't replace hv_kvp_onchannelcallback with kvp_poll_wrapper here as
we don't want to reset kvp_transaction.state but it seems this should
also get updated, e.g. hv_poll_channel() here can be replaced with the 
direct 

 tasklet_schedule(&((struct vmbus_channel*)channel)->callback_event);

call. This will ensure hv_kvp_onchannelcallback() calls are always
serialized.

>
>  static void kvp_register_done(void)
> @@ -628,16 +628,17 @@ void hv_kvp_onchannelcallback(void *context)
>NEGO_IN_PROGRESS,
>NEGO_FINISHED} host_negotiatied = NEGO_NOT_STARTED;
>
> - if (host_negotiatied == NEGO_NOT_STARTED &&
> - kvp_transaction.state < HVUTIL_READY) {
> + if (kvp_transaction.state < HVUTIL_READY) {
>   /*
>* If userspace daemon is not connected and host is asking
>* us to negotiate we need to delay to not lose messages.
>* This is important for Failover IP setting.
>*/
> - host_negotiatied = NEGO_IN_PROGRESS;
> - schedule_delayed_work(_host_handshake_work,
> + if (host_negotiatied == NEGO_NOT_STARTED) {
> + host_negotiatied = NEGO_IN_PROGRESS;
> + schedule_delayed_work(_host_handshake_work,
> HV_UTIL_NEGO_TIMEOUT * HZ);
> + }
>   return;
>   }
>   if (kvp_transaction.state > HVUTIL_READY)
> @@ -705,6 +706,7 @@ void hv_kvp_onchannelcallback(void *context)
>  VM_PKT_DATA_INBAND, 0);
>
>   host_negotiatied = NEGO_FINISHED;
> + hv_poll_channel(kvp_transaction.recv_channel, kvp_poll_wrapper);
>   }
>
>  }

-- 
  Vitaly

Re: [PATCH v2] HV: properly delay KVP packets when negotiation is in progress

2017-03-23 Thread Vitaly Kuznetsov

Long Li  writes:

> The host may send multiple negotiation packets (due to timeout) before 
> the KVP user-mode daemon is connected. We need to defer processing  
> those packets until the daemon is negotiated and connected. It's okay
> for guest to respond to all negotiation packets.
>
> In addition, the host may send multiple staged KVP requests as soon as
> negotiation is done. We need to properly process those packets using 
> one tasklet for exclusive access to ring buffer.
>
> This patch is based on the work of Nick Meier 
> 
>
> The patch v2 has incorporated suggestion from Vitaly Kuznetsov 
> .
>
> Signed-off-by: Long Li 
> ---
>  drivers/hv/hv_kvp.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c
> index de26371..845b70b 100644
> --- a/drivers/hv/hv_kvp.c
> +++ b/drivers/hv/hv_kvp.c
> @@ -113,7 +113,7 @@ static void kvp_poll_wrapper(void *channel)
>  {
>   /* Transaction is finished, reset the state here to avoid races. */
>   kvp_transaction.state = HVUTIL_READY;
> - hv_kvp_onchannelcallback(channel);
> + tasklet_schedule(&((struct vmbus_channel*)channel)->callback_event);
>  }

There is one more function in the code which calls
hv_kvp_onchannelcallback():

static void kvp_host_handshake_func(struct work_struct *dummy)
{
hv_poll_channel(kvp_transaction.recv_channel, hv_kvp_onchannelcallback);
}

we can't replace hv_kvp_onchannelcallback with kvp_poll_wrapper here as
we don't want to reset kvp_transaction.state but it seems this should
also get updated, e.g. hv_poll_channel() here can be replaced with the 
direct 

 tasklet_schedule(&((struct vmbus_channel*)channel)->callback_event);

call. This will ensure hv_kvp_onchannelcallback() calls are always
serialized.

>
>  static void kvp_register_done(void)
> @@ -628,16 +628,17 @@ void hv_kvp_onchannelcallback(void *context)
>NEGO_IN_PROGRESS,
>NEGO_FINISHED} host_negotiatied = NEGO_NOT_STARTED;
>
> - if (host_negotiatied == NEGO_NOT_STARTED &&
> - kvp_transaction.state < HVUTIL_READY) {
> + if (kvp_transaction.state < HVUTIL_READY) {
>   /*
>* If userspace daemon is not connected and host is asking
>* us to negotiate we need to delay to not lose messages.
>* This is important for Failover IP setting.
>*/
> - host_negotiatied = NEGO_IN_PROGRESS;
> - schedule_delayed_work(_host_handshake_work,
> + if (host_negotiatied == NEGO_NOT_STARTED) {
> + host_negotiatied = NEGO_IN_PROGRESS;
> + schedule_delayed_work(_host_handshake_work,
> HV_UTIL_NEGO_TIMEOUT * HZ);
> + }
>   return;
>   }
>   if (kvp_transaction.state > HVUTIL_READY)
> @@ -705,6 +706,7 @@ void hv_kvp_onchannelcallback(void *context)
>  VM_PKT_DATA_INBAND, 0);
>
>   host_negotiatied = NEGO_FINISHED;
> + hv_poll_channel(kvp_transaction.recv_channel, kvp_poll_wrapper);
>   }
>
>  }

-- 
  Vitaly

[PATCH V2] ACPI / IPMI: allow ACPI_IPMI with IPMI_SSIF

2017-03-23 Thread Sinan Kaya

ACPI_IPMI driver currently depends on IPMI System Interface (IPMI_SI)
driver to be enabled. IPMI_SI driver only handles KCS, SMIC and BT BMC
interfaces.

IPMI_SSIF is an alternative BMC communication method. It allows BMC to
be accessed over an I2C bus instead of a standard interface.

Enabling ACPI_IPMI over IPMI_SSIF with this change.

Signed-off-by: Sinan Kaya 
---
 drivers/acpi/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 83e5f7e..dc22c8a 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -256,7 +256,7 @@ config ACPI_PROCESSOR
 
 config ACPI_IPMI
tristate "IPMI"
-   depends on IPMI_SI
+   depends on IPMI_SI || IPMI_SSIF
default n
help
  This driver enables the ACPI to access the BMC controller. And it
-- 
1.9.1

[PATCH V2] ACPI / IPMI: allow ACPI_IPMI with IPMI_SSIF

2017-03-23 Thread Sinan Kaya

ACPI_IPMI driver currently depends on IPMI System Interface (IPMI_SI)
driver to be enabled. IPMI_SI driver only handles KCS, SMIC and BT BMC
interfaces.

IPMI_SSIF is an alternative BMC communication method. It allows BMC to
be accessed over an I2C bus instead of a standard interface.

Enabling ACPI_IPMI over IPMI_SSIF with this change.

Signed-off-by: Sinan Kaya 
---
 drivers/acpi/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 83e5f7e..dc22c8a 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -256,7 +256,7 @@ config ACPI_PROCESSOR
 
 config ACPI_IPMI
tristate "IPMI"
-   depends on IPMI_SI
+   depends on IPMI_SI || IPMI_SSIF
default n
help
  This driver enables the ACPI to access the BMC controller. And it
-- 
1.9.1

Re: loop: WARNING in sysfs_remove_group

2017-03-23 Thread Ming Lei

On Thu, Mar 23, 2017 at 03:09:44PM +0100, Dmitry Vyukov wrote:
> Hello,
> 
> I've got the following WARNING while running syzkaller on
> 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected
> kmalloc failure, most likely it's the root cause.
> 
> FAULT_INJECTION: forcing a failure.
> name failslab, interval 1, probability 0, space 0, times 0
> CPU: 3 PID: 21172 Comm: syz-executor4 Not tainted 4.11.0-rc3+ #364
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:16 [inline]
>  dump_stack+0x1b8/0x28d lib/dump_stack.c:52
>  fail_dump lib/fault-inject.c:45 [inline]
>  should_fail+0x78a/0x870 lib/fault-inject.c:154
>  should_failslab+0xec/0x120 mm/failslab.c:31
>  slab_pre_alloc_hook mm/slab.h:434 [inline]
>  slab_alloc mm/slab.c:3394 [inline]
>  kmem_cache_alloc+0x200/0x720 mm/slab.c:3570
>  kmem_cache_zalloc include/linux/slab.h:653 [inline]
>  __kernfs_new_node+0xd1/0x430 fs/kernfs/dir.c:629
>  kernfs_new_node+0x80/0xf0 fs/kernfs/dir.c:661
>  kernfs_create_dir_ns+0x41/0x140 fs/kernfs/dir.c:933
>  kernfs_create_dir include/linux/kernfs.h:477 [inline]
>  internal_create_group+0xf7/0x8f0 fs/sysfs/group.c:124
>  sysfs_create_group+0x1f/0x30 fs/sysfs/group.c:156
>  loop_sysfs_init drivers/block/loop.c:802 [inline]

Looks we should have handled failure of loop_sys_init().

Thanks,
Ming

Re: loop: WARNING in sysfs_remove_group

2017-03-23 Thread Ming Lei

On Thu, Mar 23, 2017 at 03:09:44PM +0100, Dmitry Vyukov wrote:
> Hello,
> 
> I've got the following WARNING while running syzkaller on
> 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected
> kmalloc failure, most likely it's the root cause.
> 
> FAULT_INJECTION: forcing a failure.
> name failslab, interval 1, probability 0, space 0, times 0
> CPU: 3 PID: 21172 Comm: syz-executor4 Not tainted 4.11.0-rc3+ #364
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:16 [inline]
>  dump_stack+0x1b8/0x28d lib/dump_stack.c:52
>  fail_dump lib/fault-inject.c:45 [inline]
>  should_fail+0x78a/0x870 lib/fault-inject.c:154
>  should_failslab+0xec/0x120 mm/failslab.c:31
>  slab_pre_alloc_hook mm/slab.h:434 [inline]
>  slab_alloc mm/slab.c:3394 [inline]
>  kmem_cache_alloc+0x200/0x720 mm/slab.c:3570
>  kmem_cache_zalloc include/linux/slab.h:653 [inline]
>  __kernfs_new_node+0xd1/0x430 fs/kernfs/dir.c:629
>  kernfs_new_node+0x80/0xf0 fs/kernfs/dir.c:661
>  kernfs_create_dir_ns+0x41/0x140 fs/kernfs/dir.c:933
>  kernfs_create_dir include/linux/kernfs.h:477 [inline]
>  internal_create_group+0xf7/0x8f0 fs/sysfs/group.c:124
>  sysfs_create_group+0x1f/0x30 fs/sysfs/group.c:156
>  loop_sysfs_init drivers/block/loop.c:802 [inline]

Looks we should have handled failure of loop_sys_init().

Thanks,
Ming

Re: [PATCH v2 2/7] dt-bindings: pinctrl: Add RZ/A1 bindings doc

Hi Geert,
   thanks for review

On Wed, Mar 22, 2017 at 11:33:50AM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
> 
> On Mon, Mar 20, 2017 at 5:14 PM, Jacopo Mondi  
> wrote:
> > Add device tree bindings documentation for Renesas RZ/A1 gpio and pin
> 
> for the Renesas ...
> 
> > controller.
> >
> > Signed-off-by: Jacopo Mondi 
> > ---
> >  .../bindings/pinctrl/renesas,rza1-pinctrl.txt  | 144 
> > +
> >  1 file changed, 144 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt 
> > b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
> > new file mode 100644
> > index 000..0474860
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
> > @@ -0,0 +1,144 @@
> > +Renesas RZ/A1 combined Pin and GPIO controller
> > +
> > +Renesas SoCs of RZ/A1 family feature a combined Pin and GPIO controller
> 
> the RZ/A1 family
> 
> > +hardware controller, named "Ports" in the hardware reference manual.
> 
> bogus "hardware controller"
> 
> > +Sub-nodes
> > +-
> > +
> > +The child nodes of the pin controller node describe a pin multiplexing
> > +function or a gpio controller alternatively.
> > +
> > +- Pin multiplexing sub-nodes:
> > +  A pin multiplexing sub-node describes how to configure a set of
> > +  (or a single) pin in some desired alternate function mode.
> > +  A single sub-node may define several pin configurations groups.
> > +
> > +  Required properties:
> > +- renesas,pins
> 
> Just "pins"?
> 

You know, I've been thinking about this, bu the "pins" property
definition in pinctrl-bidings is the following one:

Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
---
- pins takes a list of pin names or IDs as a required argument. The
  specific binding for the hardware defines:
  - Whether the entries are integers or strings, and their
meaning.
---

And all examples there assume one "pin name" or "ID" per pin.

Now, we use 2 values per each pin (the pin ID and the alternate
function number), so to me this is different from what the generic
binding describes.
Also, pinctrl-single, and pinctrl-imx which have and ABI similar to
the one this driver define, use "pinctrl-single,pins" and "fsl,pins"
respectively as property names.
So either they have to be updated yet, or we should keep using
"renesas,pins" for our own defined ABI.

Maybe Linus or other pinctrl people can give some suggestion here.

Thanks
   j

> > +  describes an array of pin multiplexing configurations.
> > +  When a pin has to be configured in alternate function mode, use this
> > +  property to identify the pin by its global index, and provide its
> > +  alternate function configuration description along with it.
> > +  When multiple pins are required to be configured as part of the same
> > +  alternate function (odds are single-pin alternate functions exist) 
> > they
> > +  shall be specified as members of the same argument list of a single
> > +  "renesas-pins" property.
> > +  Helper macros to ease calculating the pin index from its position
> > +  (port where it sits on and pin offset), and alternate function
> > +  configuration options are provided in pin controller header file at:
> 
> the pin ... file
> 
> > +  include/dt-bindings/pinctrl/r7s72100-pinctrl.h
> 
> Hence I'd include that file in this patch, as it's part of the bindings.
> 
> > +  Example:
> > +  A serial communication interface with a TX output pin and a RX input pin.
> 
> an RX
> 
> > +
> > +   {
> > +   scif2_pins: serial2 {
> > +   renesas,pins = ,
> > +  ;
> 
> Single line?
> 
> > +   };
> > +  }
> > +
> > +  Pin #0 on port #3 is configured in alternate function #6.
> > +  Pin #2 on port #3 is configured in alternate function #4.
> 
> as alternate function
> 
> > +
> > +  Example 2:
> > +  I2c master: both SDA and SCL pins need bi-directional operations
> > +
> > +   {
> > +   i2c2_pins: i2c2 {
> > +   renesas,pins = ,
> > +  ;
> > +   };
> > +  }
> > +
> > +  Pin #4 on port #1 is configured in alternate function #1.
> > +  Pin #5 on port #1 is configured in alternate function #1.
> 
> as alternate function
> 
> > +  Both need to work in bi-directional mode.
> > +
> > +  Example 3:
> > +  Multi-function timer input and output compare pins.
> > +  The hardware manual prescribes this pins to have input/output direction
> > +  specified by software. Configure TIOC0A as input and TIOC0B as output.
> > +
> > +   {
> > +   tioc0_pins: tioc0 {
> > +   renesas,pins = ,
> > +

Re: [PATCH v2 2/7] dt-bindings: pinctrl: Add RZ/A1 bindings doc