Re: [PATCH v2] leds: pm8058: Silence pointer to integer size warning

[Lee Jones]

On Thu, 30 Nov 2017, Bjorn Andersson wrote:

> The pointer returned by of_device_get_match_data() doesn't have the same
> size as u32 on 64-bit architectures, causing a compile warning when
> compile-testing the driver on such platform.
> 
> Cast the return value of of_device_get_match_data() to unsigned long and
> then to u32 to silence this warning.
> 
> Cc: Linus Walleij 
> Fixes: 7f866986e705 ("leds: add PM8058 LEDs driver")
> Signed-off-by: Bjorn Andersson 
> ---
>  drivers/leds/leds-pm8058.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/leds/leds-pm8058.c b/drivers/leds/leds-pm8058.c
> index a52674327857..8988ba3b2d65 100644
> --- a/drivers/leds/leds-pm8058.c
> +++ b/drivers/leds/leds-pm8058.c
> @@ -106,7 +106,7 @@ static int pm8058_led_probe(struct platform_device *pdev)
>   if (!led)
>   return -ENOMEM;
>  
> - led->ledtype = (u32)of_device_get_match_data(>dev);
> + led->ledtype = (u32)(unsigned long)of_device_get_match_data(>dev);

Wouldn't (u32)(void *) be even more correct?

... if the compiler will let you get away with it.

>   map = dev_get_regmap(pdev->dev.parent, NULL);
>   if (!map) {

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

Re: [PATCH v2] leds: pm8058: Silence pointer to integer size warning

[Lee Jones]

On Thu, 30 Nov 2017, Bjorn Andersson wrote:

> The pointer returned by of_device_get_match_data() doesn't have the same
> size as u32 on 64-bit architectures, causing a compile warning when
> compile-testing the driver on such platform.
> 
> Cast the return value of of_device_get_match_data() to unsigned long and
> then to u32 to silence this warning.
> 
> Cc: Linus Walleij 
> Fixes: 7f866986e705 ("leds: add PM8058 LEDs driver")
> Signed-off-by: Bjorn Andersson 
> ---
>  drivers/leds/leds-pm8058.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/leds/leds-pm8058.c b/drivers/leds/leds-pm8058.c
> index a52674327857..8988ba3b2d65 100644
> --- a/drivers/leds/leds-pm8058.c
> +++ b/drivers/leds/leds-pm8058.c
> @@ -106,7 +106,7 @@ static int pm8058_led_probe(struct platform_device *pdev)
>   if (!led)
>   return -ENOMEM;
>  
> - led->ledtype = (u32)of_device_get_match_data(>dev);
> + led->ledtype = (u32)(unsigned long)of_device_get_match_data(>dev);

Wouldn't (u32)(void *) be even more correct?

... if the compiler will let you get away with it.

>   map = dev_get_regmap(pdev->dev.parent, NULL);
>   if (!map) {

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

Re: [PATCH] leds: pm8058: Make ledtype pointer sized type

[Lee Jones]

On Thu, 30 Nov 2017, Jacek Anaszewski wrote:

> On 11/30/2017 09:31 AM, Lee Jones wrote:
> > On Thu, 30 Nov 2017, Lee Jones wrote:
> > 
> >> On Wed, 29 Nov 2017, Bjorn Andersson wrote:
> >>
> >>> The pointer returned by of_device_get_match_data() doesn't have the same
> >>> size as u32 on 64-bit architectures, causing issues when compile testing
> >>> the driver on such platform. Make ledtype unsigned long instead, to
> >>> solve this problem.
> >>>
> >>> Fixes: 7f866986e705 ("leds: add PM8058 LEDs driver")
> >>> Cc: Linus Walleij 
> >>> Signed-off-by: Bjorn Andersson 
> >>> ---
> >>>  drivers/leds/leds-pm8058.c | 4 ++--
> >>>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> Hi Bjorn,
> >>
> >> (Nice to see you) :)
> >>
> >> I'm going to apply this *before* Linus' fix.
> >>
> >> Applied, thanks.
> > 
> > After I rx an Ack from Richard, Jacek or Pavel of course. :)
> > 
> > Will send a pull-request.
> 
> Huh? This is for LED subsystem AFAICS.

Right, hence why I said I'd sent out a pull-request.

The problem, however, arose due to a change in its parent driver's
Kconfig entry, which has been applied to the MFD tree.  We need to
ensure this patch is applied *before* the other 'fix' to quash the
warning before it starts, so to speak.

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

Re: [PATCH] leds: pm8058: Make ledtype pointer sized type

[Lee Jones]

On Thu, 30 Nov 2017, Jacek Anaszewski wrote:

> On 11/30/2017 09:31 AM, Lee Jones wrote:
> > On Thu, 30 Nov 2017, Lee Jones wrote:
> > 
> >> On Wed, 29 Nov 2017, Bjorn Andersson wrote:
> >>
> >>> The pointer returned by of_device_get_match_data() doesn't have the same
> >>> size as u32 on 64-bit architectures, causing issues when compile testing
> >>> the driver on such platform. Make ledtype unsigned long instead, to
> >>> solve this problem.
> >>>
> >>> Fixes: 7f866986e705 ("leds: add PM8058 LEDs driver")
> >>> Cc: Linus Walleij 
> >>> Signed-off-by: Bjorn Andersson 
> >>> ---
> >>>  drivers/leds/leds-pm8058.c | 4 ++--
> >>>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> Hi Bjorn,
> >>
> >> (Nice to see you) :)
> >>
> >> I'm going to apply this *before* Linus' fix.
> >>
> >> Applied, thanks.
> > 
> > After I rx an Ack from Richard, Jacek or Pavel of course. :)
> > 
> > Will send a pull-request.
> 
> Huh? This is for LED subsystem AFAICS.

Right, hence why I said I'd sent out a pull-request.

The problem, however, arose due to a change in its parent driver's
Kconfig entry, which has been applied to the MFD tree.  We need to
ensure this patch is applied *before* the other 'fix' to quash the
warning before it starts, so to speak.

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

Re: [PATCH v4 3/8] MIPS: Octeon: Add a global resource manager.

[Philippe Ombredanne]

Carlos,

On Thu, Nov 30, 2017 at 11:53 PM, James Hogan  wrote:
> On Tue, Nov 28, 2017 at 04:55:35PM -0800, David Daney wrote:
>> From: Carlos Munoz 
>>
>> Add a global resource manager to manage tagged pointers within
>> bootmem allocated memory. This is used by various functional
>> blocks in the Octeon core like the FPA, Ethernet nexus, etc.
>>
>> Signed-off-by: Carlos Munoz 
>> Signed-off-by: Steven J. Hill 
>> Signed-off-by: David Daney 
>> ---
>>  arch/mips/cavium-octeon/Makefile   |   3 +-
>>  arch/mips/cavium-octeon/resource-mgr.c | 371 
>> +
>>  arch/mips/include/asm/octeon/octeon.h  |  18 ++
>>  3 files changed, 391 insertions(+), 1 deletion(-)
>>  create mode 100644 arch/mips/cavium-octeon/resource-mgr.c
>>
>> diff --git a/arch/mips/cavium-octeon/Makefile 
>> b/arch/mips/cavium-octeon/Makefile
>> index 7c02e542959a..0a299ab8719f 100644
>> --- a/arch/mips/cavium-octeon/Makefile
>> +++ b/arch/mips/cavium-octeon/Makefile
>> @@ -9,7 +9,8 @@
>>  # Copyright (C) 2005-2009 Cavium Networks
>>  #
>>
>> -obj-y := cpu.o setup.o octeon-platform.o octeon-irq.o csrc-octeon.o
>> +obj-y := cpu.o setup.o octeon-platform.o octeon-irq.o csrc-octeon.o \
>> +  resource-mgr.o
>
> Maybe put that on a separate line like below.
>
>>  obj-y += dma-octeon.o
>>  obj-y += octeon-memcpy.o
>>  obj-y += executive/
>> diff --git a/arch/mips/cavium-octeon/resource-mgr.c 
>> b/arch/mips/cavium-octeon/resource-mgr.c
>> new file mode 100644
>> index ..ca25fa953402
>> --- /dev/null
>> +++ b/arch/mips/cavium-octeon/resource-mgr.c
>> @@ -0,0 +1,371 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Resource manager for Octeon.
>> + *
>> + * This file is subject to the terms and conditions of the GNU General 
>> Public
>> + * License.  See the file "COPYING" in the main directory of this archive
>> + * for more details.
>> + *
>> + * Copyright (C) 2017 Cavium, Inc.
>> + */

Since you nicely included an SPDX id, you would not need the
boilerplate anymore. e.g. these can go alright?

>> + * This file is subject to the terms and conditions of the GNU General 
>> Public
>> + * License.  See the file "COPYING" in the main directory of this archive
>> + * for more details.

-- 
Cordially
Philippe Ombredanne

Re: [PATCH v4 3/8] MIPS: Octeon: Add a global resource manager.

[Philippe Ombredanne]

Carlos,

On Thu, Nov 30, 2017 at 11:53 PM, James Hogan  wrote:
> On Tue, Nov 28, 2017 at 04:55:35PM -0800, David Daney wrote:
>> From: Carlos Munoz 
>>
>> Add a global resource manager to manage tagged pointers within
>> bootmem allocated memory. This is used by various functional
>> blocks in the Octeon core like the FPA, Ethernet nexus, etc.
>>
>> Signed-off-by: Carlos Munoz 
>> Signed-off-by: Steven J. Hill 
>> Signed-off-by: David Daney 
>> ---
>>  arch/mips/cavium-octeon/Makefile   |   3 +-
>>  arch/mips/cavium-octeon/resource-mgr.c | 371 
>> +
>>  arch/mips/include/asm/octeon/octeon.h  |  18 ++
>>  3 files changed, 391 insertions(+), 1 deletion(-)
>>  create mode 100644 arch/mips/cavium-octeon/resource-mgr.c
>>
>> diff --git a/arch/mips/cavium-octeon/Makefile 
>> b/arch/mips/cavium-octeon/Makefile
>> index 7c02e542959a..0a299ab8719f 100644
>> --- a/arch/mips/cavium-octeon/Makefile
>> +++ b/arch/mips/cavium-octeon/Makefile
>> @@ -9,7 +9,8 @@
>>  # Copyright (C) 2005-2009 Cavium Networks
>>  #
>>
>> -obj-y := cpu.o setup.o octeon-platform.o octeon-irq.o csrc-octeon.o
>> +obj-y := cpu.o setup.o octeon-platform.o octeon-irq.o csrc-octeon.o \
>> +  resource-mgr.o
>
> Maybe put that on a separate line like below.
>
>>  obj-y += dma-octeon.o
>>  obj-y += octeon-memcpy.o
>>  obj-y += executive/
>> diff --git a/arch/mips/cavium-octeon/resource-mgr.c 
>> b/arch/mips/cavium-octeon/resource-mgr.c
>> new file mode 100644
>> index ..ca25fa953402
>> --- /dev/null
>> +++ b/arch/mips/cavium-octeon/resource-mgr.c
>> @@ -0,0 +1,371 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Resource manager for Octeon.
>> + *
>> + * This file is subject to the terms and conditions of the GNU General 
>> Public
>> + * License.  See the file "COPYING" in the main directory of this archive
>> + * for more details.
>> + *
>> + * Copyright (C) 2017 Cavium, Inc.
>> + */

Since you nicely included an SPDX id, you would not need the
boilerplate anymore. e.g. these can go alright?

>> + * This file is subject to the terms and conditions of the GNU General 
>> Public
>> + * License.  See the file "COPYING" in the main directory of this archive
>> + * for more details.

-- 
Cordially
Philippe Ombredanne

Re: [PATCH RFC 2/2] arm64: allwinner: a64: Add Brava Keller initial support

[Maxime Ripard]

On Fri, Dec 01, 2017 at 12:12:14AM +0530, Jagan Teki wrote:
> Brava Keller is A64 based IoT device, which support
> - Allwinner A64 Cortex-A53
> - AXP803 PMIC
> - 1GB DDR3 RAM
> - 8GB eMMC
> - Mali-400MP2 GPU
> - AP6330 Wifi/BLE
> - Camera OV5640
> - USB Host and OTG
> 
> Signed-off-by: Jagan Teki 
> ---
> Note: Need to test it on hardware
>  
>  arch/arm64/boot/dts/allwinner/Makefile |   1 +
>  .../boot/dts/allwinner/sun50i-a64-brava-keller.dts | 244 
> +
>  2 files changed, 245 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-brava-keller.dts
> 
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
> b/arch/arm64/boot/dts/allwinner/Makefile
> index f505227..af80ca0 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -1,5 +1,6 @@
>  # SPDX-License-Identifier: GPL-2.0
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-brava-keller.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-nanopi-a64.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-olinuxino.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-brava-keller.dts 
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-brava-keller.dts
> new file mode 100644
> index 000..f5303a3
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-brava-keller.dts
> @@ -0,0 +1,244 @@
> +/*
> + * Copyright (C) 2017 Jagan Teki 
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This library 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.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-a64.dtsi"
> +
> +#include 
> +
> +/ {
> + model = "Brava Keller";
> + compatible = "brava,brava-keller", "allwinner,sun50i-a64";
> +
> + aliases {
> + serial2 = 
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };

Same comment than on U-Boot.

> + wifi_pwrseq: wifi_pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + pinctrl-names = "default";
> + reset-gpios = < 0 2 GPIO_ACTIVE_LOW>; /* WL-PMU-EN: PL2 */
> + post-power-on-delay-ms = <200>;
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + vmmc-supply = <_dcdc1>;
> + vqmmc-supply = <_dldo4>;
> + mmc-pwrseq = <_pwrseq>;
> + bus-width = <4>;
> + non-removable;
> + status = "okay";
> +
> + brcmf: wifi@1 {
> + reg = <1>;
> + compatible = "brcm,bcm4329-fmac";
> + interrupt-parent = <_pio>;
> + interrupts = <0 7 IRQ_TYPE_LEVEL_LOW>;  /* WL-WAKE-AP: PL3 */
> + interrupt-names = "host-wake";
> + };
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + vmmc-supply = <_dcdc1>;

You probably have a vqmmc 

Re: [PATCH RFC 2/2] arm64: allwinner: a64: Add Brava Keller initial support

[Maxime Ripard]

On Fri, Dec 01, 2017 at 12:12:14AM +0530, Jagan Teki wrote:
> Brava Keller is A64 based IoT device, which support
> - Allwinner A64 Cortex-A53
> - AXP803 PMIC
> - 1GB DDR3 RAM
> - 8GB eMMC
> - Mali-400MP2 GPU
> - AP6330 Wifi/BLE
> - Camera OV5640
> - USB Host and OTG
> 
> Signed-off-by: Jagan Teki 
> ---
> Note: Need to test it on hardware
>  
>  arch/arm64/boot/dts/allwinner/Makefile |   1 +
>  .../boot/dts/allwinner/sun50i-a64-brava-keller.dts | 244 
> +
>  2 files changed, 245 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-brava-keller.dts
> 
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
> b/arch/arm64/boot/dts/allwinner/Makefile
> index f505227..af80ca0 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -1,5 +1,6 @@
>  # SPDX-License-Identifier: GPL-2.0
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-brava-keller.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-nanopi-a64.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-olinuxino.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-brava-keller.dts 
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-brava-keller.dts
> new file mode 100644
> index 000..f5303a3
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-brava-keller.dts
> @@ -0,0 +1,244 @@
> +/*
> + * Copyright (C) 2017 Jagan Teki 
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This library 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.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-a64.dtsi"
> +
> +#include 
> +
> +/ {
> + model = "Brava Keller";
> + compatible = "brava,brava-keller", "allwinner,sun50i-a64";
> +
> + aliases {
> + serial2 = 
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };

Same comment than on U-Boot.

> + wifi_pwrseq: wifi_pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + pinctrl-names = "default";
> + reset-gpios = < 0 2 GPIO_ACTIVE_LOW>; /* WL-PMU-EN: PL2 */
> + post-power-on-delay-ms = <200>;
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + vmmc-supply = <_dcdc1>;
> + vqmmc-supply = <_dldo4>;
> + mmc-pwrseq = <_pwrseq>;
> + bus-width = <4>;
> + non-removable;
> + status = "okay";
> +
> + brcmf: wifi@1 {
> + reg = <1>;
> + compatible = "brcm,bcm4329-fmac";
> + interrupt-parent = <_pio>;
> + interrupts = <0 7 IRQ_TYPE_LEVEL_LOW>;  /* WL-WAKE-AP: PL3 */
> + interrupt-names = "host-wake";
> + };
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + vmmc-supply = <_dcdc1>;

You probably have a vqmmc tosetup too.

> + bus-width = <8>;
> + non-removable;

[PATCH v2 3/3] ARM: CMA: avoid double mapping to the CMA area if CONFIG_HIGHMEM = y

[js1304]

From: Joonsoo Kim 

CMA area is now managed by the separate zone, ZONE_MOVABLE,
to fix many MM related problems. In this implementation, if
CONFIG_HIGHMEM = y, then ZONE_MOVABLE is considered as HIGHMEM and
the memory of the CMA area is also considered as HIGHMEM.
That means that they are considered as the page without direct mapping.
However, CMA area could be in a lowmem and the memory could have
direct mapping.

In ARM, when establishing a new mapping for DMA, direct mapping should
be cleared since two mapping with different cache policy could cause
unknown problem. With this patch, PageHighmem() for the CMA memory
located in lowmem returns true so that the function for DMA mapping
cannot notice whether it needs to clear direct mapping or not, correctly.
To handle this situation, this patch always clears direct mapping
for such CMA memory.

Signed-off-by: Joonsoo Kim 
---
 arch/arm/mm/dma-mapping.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index ada8eb2..8c398fe 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -466,6 +466,12 @@ void __init dma_contiguous_early_fixup(phys_addr_t base, 
unsigned long size)
 void __init dma_contiguous_remap(void)
 {
int i;
+
+   if (!dma_mmu_remap_num)
+   return;
+
+   /* call flush_cache_all() since CMA area would be large enough */
+   flush_cache_all();
for (i = 0; i < dma_mmu_remap_num; i++) {
phys_addr_t start = dma_mmu_remap[i].base;
phys_addr_t end = start + dma_mmu_remap[i].size;
@@ -498,7 +504,15 @@ void __init dma_contiguous_remap(void)
flush_tlb_kernel_range(__phys_to_virt(start),
   __phys_to_virt(end));
 
-   iotable_init(, 1);
+   /*
+* All the memory in CMA region will be on ZONE_MOVABLE.
+* If that zone is considered as highmem, the memory in CMA
+* region is also considered as highmem even if it's
+* physical address belong to lowmem. In this case,
+* re-mapping isn't required.
+*/
+   if (!is_highmem_idx(ZONE_MOVABLE))
+   iotable_init(, 1);
}
 }
 
-- 
2.7.4

[PATCH v2 1/3] mm/cma: manage the memory of the CMA area by using the ZONE_MOVABLE

[js1304]

From: Joonsoo Kim 

0. History

This patchset is the follow-up of the discussion about the
"Introduce ZONE_CMA (v7)" [1]. Please reference it if more information
is needed.

1. What does this patch do?

This patch changes the management way for the memory of the CMA area
in the MM subsystem. Currently, The memory of the CMA area is managed
by the zone where their pfn is belong to. However, this approach has
some problems since MM subsystem doesn't have enough logic to handle
the situation that different characteristic memories are in a single zone.
To solve this issue, this patch try to manage all the memory of
the CMA area by using the MOVABLE zone. In MM subsystem's point of view,
characteristic of the memory on the MOVABLE zone and the memory of
the CMA area are the same. So, managing the memory of the CMA area
by using the MOVABLE zone will not have any problem.

2. Motivation

There are some problems with current approach. See following.
Although these problem would not be inherent and it could be fixed without
this conception change, it requires many hooks addition in various
code path and it would be intrusive to core MM and would be really
error-prone. Therefore, I try to solve them with this new approach.
Anyway, following is the problems of the current implementation.

o CMA memory utilization

First, following is the freepage calculation logic in MM.

- For movable allocation: freepage = total freepage
- For unmovable allocation: freepage = total freepage - CMA freepage

Freepages on the CMA area is used after the normal freepages in the zone
where the memory of the CMA area is belong to are exhausted. At that moment
that the number of the normal freepages is zero, so

- For movable allocation: freepage = total freepage = CMA freepage
- For unmovable allocation: freepage = 0

If unmovable allocation comes at this moment, allocation request would
fail to pass the watermark check and reclaim is started. After reclaim,
there would exist the normal freepages so freepages on the CMA areas
would not be used.

FYI, there is another attempt [2] trying to solve this problem in lkml.
And, as far as I know, Qualcomm also has out-of-tree solution for this
problem.

o useless reclaim

There is no logic to distinguish CMA pages in the reclaim path. Hence,
CMA page is reclaimed even if the system just needs the page that can
be usable for the kernel allocation.

o atomic allocation failure

This is also related to the fallback allocation policy for the memory
of the CMA area. Consider the situation that the number of the normal
freepages is *zero* since the bunch of the movable allocation requests
come. Kswapd would not be woken up due to following freepage calculation
logic.

- For movable allocation: freepage = total freepage = CMA freepage

If atomic unmovable allocation request comes at this moment, it would
fails due to following logic.

- For unmovable allocation: freepage = total freepage - CMA freepage = 0

It was reported by Aneesh [3].

o useless compaction

Usual high-order allocation request is unmovable allocation request and
it cannot be served from the memory of the CMA area. In compaction,
migration scanner try to migrate the page in the CMA area and make
high-order page there. As mentioned above, it cannot be usable
for the unmovable allocation request so it's just waste.

3. Current approach and new approach

Current approach is that the memory of the CMA area is managed by the zone
where their pfn is belong to. However, these memory should be
distinguishable since they have a strong limitation. So, they are marked
as MIGRATE_CMA in pageblock flag and handled specially. However,
as mentioned in section 2, the MM subsystem doesn't have enough logic
to deal with this special pageblock so many problems raised.

New approach is that the memory of the CMA area is managed by
the MOVABLE zone. MM already have enough logic to deal with special zone
like as HIGHMEM and MOVABLE zone. So, managing the memory of the CMA area
by the MOVABLE zone just naturally work well because constraints
for the memory of the CMA area that the memory should always be migratable
is the same with the constraint for the MOVABLE zone.

There is one side-effect for the usability of the memory of the CMA area.
The use of MOVABLE zone is only allowed for a request with GFP_HIGHMEM &&
GFP_MOVABLE so now the memory of the CMA area is also only allowed for
this gfp flag. Before this patchset, a request with GFP_MOVABLE can use
them. IMO, It would not be a big issue since most of GFP_MOVABLE request
also has GFP_HIGHMEM flag. For example, file cache page and anonymous page.
However, file cache page for blockdev file is an exception. Request for it
has no GFP_HIGHMEM flag. There is pros and cons on this exception.
In my experience, blockdev file cache pages are one of the top reason
that causes cma_alloc() to fail temporarily. So, we can get more guarantee
of cma_alloc() success by discarding this case.

[PATCH v2 3/3] ARM: CMA: avoid double mapping to the CMA area if CONFIG_HIGHMEM = y

[js1304]

From: Joonsoo Kim 

CMA area is now managed by the separate zone, ZONE_MOVABLE,
to fix many MM related problems. In this implementation, if
CONFIG_HIGHMEM = y, then ZONE_MOVABLE is considered as HIGHMEM and
the memory of the CMA area is also considered as HIGHMEM.
That means that they are considered as the page without direct mapping.
However, CMA area could be in a lowmem and the memory could have
direct mapping.

In ARM, when establishing a new mapping for DMA, direct mapping should
be cleared since two mapping with different cache policy could cause
unknown problem. With this patch, PageHighmem() for the CMA memory
located in lowmem returns true so that the function for DMA mapping
cannot notice whether it needs to clear direct mapping or not, correctly.
To handle this situation, this patch always clears direct mapping
for such CMA memory.

Signed-off-by: Joonsoo Kim 
---
 arch/arm/mm/dma-mapping.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index ada8eb2..8c398fe 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -466,6 +466,12 @@ void __init dma_contiguous_early_fixup(phys_addr_t base, 
unsigned long size)
 void __init dma_contiguous_remap(void)
 {
int i;
+
+   if (!dma_mmu_remap_num)
+   return;
+
+   /* call flush_cache_all() since CMA area would be large enough */
+   flush_cache_all();
for (i = 0; i < dma_mmu_remap_num; i++) {
phys_addr_t start = dma_mmu_remap[i].base;
phys_addr_t end = start + dma_mmu_remap[i].size;
@@ -498,7 +504,15 @@ void __init dma_contiguous_remap(void)
flush_tlb_kernel_range(__phys_to_virt(start),
   __phys_to_virt(end));
 
-   iotable_init(, 1);
+   /*
+* All the memory in CMA region will be on ZONE_MOVABLE.
+* If that zone is considered as highmem, the memory in CMA
+* region is also considered as highmem even if it's
+* physical address belong to lowmem. In this case,
+* re-mapping isn't required.
+*/
+   if (!is_highmem_idx(ZONE_MOVABLE))
+   iotable_init(, 1);
}
 }
 
-- 
2.7.4

[PATCH v2 1/3] mm/cma: manage the memory of the CMA area by using the ZONE_MOVABLE

[js1304]

From: Joonsoo Kim 

0. History

This patchset is the follow-up of the discussion about the
"Introduce ZONE_CMA (v7)" [1]. Please reference it if more information
is needed.

1. What does this patch do?

This patch changes the management way for the memory of the CMA area
in the MM subsystem. Currently, The memory of the CMA area is managed
by the zone where their pfn is belong to. However, this approach has
some problems since MM subsystem doesn't have enough logic to handle
the situation that different characteristic memories are in a single zone.
To solve this issue, this patch try to manage all the memory of
the CMA area by using the MOVABLE zone. In MM subsystem's point of view,
characteristic of the memory on the MOVABLE zone and the memory of
the CMA area are the same. So, managing the memory of the CMA area
by using the MOVABLE zone will not have any problem.

2. Motivation

There are some problems with current approach. See following.
Although these problem would not be inherent and it could be fixed without
this conception change, it requires many hooks addition in various
code path and it would be intrusive to core MM and would be really
error-prone. Therefore, I try to solve them with this new approach.
Anyway, following is the problems of the current implementation.

o CMA memory utilization

First, following is the freepage calculation logic in MM.

- For movable allocation: freepage = total freepage
- For unmovable allocation: freepage = total freepage - CMA freepage

Freepages on the CMA area is used after the normal freepages in the zone
where the memory of the CMA area is belong to are exhausted. At that moment
that the number of the normal freepages is zero, so

- For movable allocation: freepage = total freepage = CMA freepage
- For unmovable allocation: freepage = 0

If unmovable allocation comes at this moment, allocation request would
fail to pass the watermark check and reclaim is started. After reclaim,
there would exist the normal freepages so freepages on the CMA areas
would not be used.

FYI, there is another attempt [2] trying to solve this problem in lkml.
And, as far as I know, Qualcomm also has out-of-tree solution for this
problem.

o useless reclaim

There is no logic to distinguish CMA pages in the reclaim path. Hence,
CMA page is reclaimed even if the system just needs the page that can
be usable for the kernel allocation.

o atomic allocation failure

This is also related to the fallback allocation policy for the memory
of the CMA area. Consider the situation that the number of the normal
freepages is *zero* since the bunch of the movable allocation requests
come. Kswapd would not be woken up due to following freepage calculation
logic.

- For movable allocation: freepage = total freepage = CMA freepage

If atomic unmovable allocation request comes at this moment, it would
fails due to following logic.

- For unmovable allocation: freepage = total freepage - CMA freepage = 0

It was reported by Aneesh [3].

o useless compaction

Usual high-order allocation request is unmovable allocation request and
it cannot be served from the memory of the CMA area. In compaction,
migration scanner try to migrate the page in the CMA area and make
high-order page there. As mentioned above, it cannot be usable
for the unmovable allocation request so it's just waste.

3. Current approach and new approach

Current approach is that the memory of the CMA area is managed by the zone
where their pfn is belong to. However, these memory should be
distinguishable since they have a strong limitation. So, they are marked
as MIGRATE_CMA in pageblock flag and handled specially. However,
as mentioned in section 2, the MM subsystem doesn't have enough logic
to deal with this special pageblock so many problems raised.

New approach is that the memory of the CMA area is managed by
the MOVABLE zone. MM already have enough logic to deal with special zone
like as HIGHMEM and MOVABLE zone. So, managing the memory of the CMA area
by the MOVABLE zone just naturally work well because constraints
for the memory of the CMA area that the memory should always be migratable
is the same with the constraint for the MOVABLE zone.

There is one side-effect for the usability of the memory of the CMA area.
The use of MOVABLE zone is only allowed for a request with GFP_HIGHMEM &&
GFP_MOVABLE so now the memory of the CMA area is also only allowed for
this gfp flag. Before this patchset, a request with GFP_MOVABLE can use
them. IMO, It would not be a big issue since most of GFP_MOVABLE request
also has GFP_HIGHMEM flag. For example, file cache page and anonymous page.
However, file cache page for blockdev file is an exception. Request for it
has no GFP_HIGHMEM flag. There is pros and cons on this exception.
In my experience, blockdev file cache pages are one of the top reason
that causes cma_alloc() to fail temporarily. So, we can get more guarantee
of cma_alloc() success by discarding this case.

Note that there is no 

[PATCH v2 2/3] mm/cma: remove ALLOC_CMA

[js1304]

From: Joonsoo Kim 

Now, all reserved pages for CMA region are belong to the ZONE_MOVABLE
and it only serves for a request with GFP_HIGHMEM && GFP_MOVABLE.
Therefore, we don't need to maintain ALLOC_CMA at all.

Reviewed-by: Aneesh Kumar K.V 
Acked-by: Vlastimil Babka 
Signed-off-by: Joonsoo Kim 
---
 mm/compaction.c |  4 +---
 mm/internal.h   |  1 -
 mm/page_alloc.c | 28 +++-
 3 files changed, 4 insertions(+), 29 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index 10cd757..b8c2388 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1450,14 +1450,12 @@ static enum compact_result __compaction_suitable(struct 
zone *zone, int order,
 * if compaction succeeds.
 * For costly orders, we require low watermark instead of min for
 * compaction to proceed to increase its chances.
-* ALLOC_CMA is used, as pages in CMA pageblocks are considered
-* suitable migration targets
 */
watermark = (order > PAGE_ALLOC_COSTLY_ORDER) ?
low_wmark_pages(zone) : min_wmark_pages(zone);
watermark += compact_gap(order);
if (!__zone_watermark_ok(zone, 0, watermark, classzone_idx,
-   ALLOC_CMA, wmark_target))
+   0, wmark_target))
return COMPACT_SKIPPED;
 
return COMPACT_CONTINUE;
diff --git a/mm/internal.h b/mm/internal.h
index 1cfa4c7..3e5dc95 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -498,7 +498,6 @@ unsigned long reclaim_clean_pages_from_list(struct zone 
*zone,
 #define ALLOC_HARDER   0x10 /* try to alloc harder */
 #define ALLOC_HIGH 0x20 /* __GFP_HIGH set */
 #define ALLOC_CPUSET   0x40 /* check for correct cpuset */
-#define ALLOC_CMA  0x80 /* allow allocations from CMA areas */
 
 enum ttu_flags;
 struct tlbflush_unmap_batch;
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index eb5cdd5..18df47e 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2773,7 +2773,7 @@ int __isolate_free_page(struct page *page, unsigned int 
order)
 * exists.
 */
watermark = min_wmark_pages(zone) + (1UL << order);
-   if (!zone_watermark_ok(zone, 0, watermark, 0, ALLOC_CMA))
+   if (!zone_watermark_ok(zone, 0, watermark, 0, 0))
return 0;
 
__mod_zone_freepage_state(zone, -(1UL << order), mt);
@@ -3049,12 +3049,6 @@ bool __zone_watermark_ok(struct zone *z, unsigned int 
order, unsigned long mark,
}
 
 
-#ifdef CONFIG_CMA
-   /* If allocation can't use CMA areas don't use free CMA pages */
-   if (!(alloc_flags & ALLOC_CMA))
-   free_pages -= zone_page_state(z, NR_FREE_CMA_PAGES);
-#endif
-
/*
 * Check watermarks for an order-0 allocation request. If these
 * are not met, then a high-order request also cannot go ahead
@@ -3081,10 +3075,8 @@ bool __zone_watermark_ok(struct zone *z, unsigned int 
order, unsigned long mark,
}
 
 #ifdef CONFIG_CMA
-   if ((alloc_flags & ALLOC_CMA) &&
-   !list_empty(>free_list[MIGRATE_CMA])) {
+   if (!list_empty(>free_list[MIGRATE_CMA]))
return true;
-   }
 #endif
if (alloc_harder &&
!list_empty(>free_list[MIGRATE_HIGHATOMIC]))
@@ -3104,13 +3096,6 @@ static inline bool zone_watermark_fast(struct zone *z, 
unsigned int order,
unsigned long mark, int classzone_idx, unsigned int alloc_flags)
 {
long free_pages = zone_page_state(z, NR_FREE_PAGES);
-   long cma_pages = 0;
-
-#ifdef CONFIG_CMA
-   /* If allocation can't use CMA areas don't use free CMA pages */
-   if (!(alloc_flags & ALLOC_CMA))
-   cma_pages = zone_page_state(z, NR_FREE_CMA_PAGES);
-#endif
 
/*
 * Fast check for order-0 only. If this fails then the reserves
@@ -3119,7 +3104,7 @@ static inline bool zone_watermark_fast(struct zone *z, 
unsigned int order,
 * the caller is !atomic then it'll uselessly search the free
 * list. That corner case is then slower but it is harmless.
 */
-   if (!order && (free_pages - cma_pages) > mark + 
z->lowmem_reserve[classzone_idx])
+   if (!order && free_pages > mark + z->lowmem_reserve[classzone_idx])
return true;
 
return __zone_watermark_ok(z, order, mark, classzone_idx, alloc_flags,
@@ -3735,10 +3720,6 @@ gfp_to_alloc_flags(gfp_t gfp_mask)
} else if (unlikely(rt_task(current)) && !in_interrupt())
alloc_flags |= ALLOC_HARDER;
 
-#ifdef CONFIG_CMA
-   if (gfpflags_to_migratetype(gfp_mask) == MIGRATE_MOVABLE)
-   alloc_flags |= ALLOC_CMA;
-#endif
return alloc_flags;
 }
 

[PATCH v2 2/3] mm/cma: remove ALLOC_CMA

[js1304]

From: Joonsoo Kim 

Now, all reserved pages for CMA region are belong to the ZONE_MOVABLE
and it only serves for a request with GFP_HIGHMEM && GFP_MOVABLE.
Therefore, we don't need to maintain ALLOC_CMA at all.

Reviewed-by: Aneesh Kumar K.V 
Acked-by: Vlastimil Babka 
Signed-off-by: Joonsoo Kim 
---
 mm/compaction.c |  4 +---
 mm/internal.h   |  1 -
 mm/page_alloc.c | 28 +++-
 3 files changed, 4 insertions(+), 29 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index 10cd757..b8c2388 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1450,14 +1450,12 @@ static enum compact_result __compaction_suitable(struct 
zone *zone, int order,
 * if compaction succeeds.
 * For costly orders, we require low watermark instead of min for
 * compaction to proceed to increase its chances.
-* ALLOC_CMA is used, as pages in CMA pageblocks are considered
-* suitable migration targets
 */
watermark = (order > PAGE_ALLOC_COSTLY_ORDER) ?
low_wmark_pages(zone) : min_wmark_pages(zone);
watermark += compact_gap(order);
if (!__zone_watermark_ok(zone, 0, watermark, classzone_idx,
-   ALLOC_CMA, wmark_target))
+   0, wmark_target))
return COMPACT_SKIPPED;
 
return COMPACT_CONTINUE;
diff --git a/mm/internal.h b/mm/internal.h
index 1cfa4c7..3e5dc95 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -498,7 +498,6 @@ unsigned long reclaim_clean_pages_from_list(struct zone 
*zone,
 #define ALLOC_HARDER   0x10 /* try to alloc harder */
 #define ALLOC_HIGH 0x20 /* __GFP_HIGH set */
 #define ALLOC_CPUSET   0x40 /* check for correct cpuset */
-#define ALLOC_CMA  0x80 /* allow allocations from CMA areas */
 
 enum ttu_flags;
 struct tlbflush_unmap_batch;
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index eb5cdd5..18df47e 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2773,7 +2773,7 @@ int __isolate_free_page(struct page *page, unsigned int 
order)
 * exists.
 */
watermark = min_wmark_pages(zone) + (1UL << order);
-   if (!zone_watermark_ok(zone, 0, watermark, 0, ALLOC_CMA))
+   if (!zone_watermark_ok(zone, 0, watermark, 0, 0))
return 0;
 
__mod_zone_freepage_state(zone, -(1UL << order), mt);
@@ -3049,12 +3049,6 @@ bool __zone_watermark_ok(struct zone *z, unsigned int 
order, unsigned long mark,
}
 
 
-#ifdef CONFIG_CMA
-   /* If allocation can't use CMA areas don't use free CMA pages */
-   if (!(alloc_flags & ALLOC_CMA))
-   free_pages -= zone_page_state(z, NR_FREE_CMA_PAGES);
-#endif
-
/*
 * Check watermarks for an order-0 allocation request. If these
 * are not met, then a high-order request also cannot go ahead
@@ -3081,10 +3075,8 @@ bool __zone_watermark_ok(struct zone *z, unsigned int 
order, unsigned long mark,
}
 
 #ifdef CONFIG_CMA
-   if ((alloc_flags & ALLOC_CMA) &&
-   !list_empty(>free_list[MIGRATE_CMA])) {
+   if (!list_empty(>free_list[MIGRATE_CMA]))
return true;
-   }
 #endif
if (alloc_harder &&
!list_empty(>free_list[MIGRATE_HIGHATOMIC]))
@@ -3104,13 +3096,6 @@ static inline bool zone_watermark_fast(struct zone *z, 
unsigned int order,
unsigned long mark, int classzone_idx, unsigned int alloc_flags)
 {
long free_pages = zone_page_state(z, NR_FREE_PAGES);
-   long cma_pages = 0;
-
-#ifdef CONFIG_CMA
-   /* If allocation can't use CMA areas don't use free CMA pages */
-   if (!(alloc_flags & ALLOC_CMA))
-   cma_pages = zone_page_state(z, NR_FREE_CMA_PAGES);
-#endif
 
/*
 * Fast check for order-0 only. If this fails then the reserves
@@ -3119,7 +3104,7 @@ static inline bool zone_watermark_fast(struct zone *z, 
unsigned int order,
 * the caller is !atomic then it'll uselessly search the free
 * list. That corner case is then slower but it is harmless.
 */
-   if (!order && (free_pages - cma_pages) > mark + 
z->lowmem_reserve[classzone_idx])
+   if (!order && free_pages > mark + z->lowmem_reserve[classzone_idx])
return true;
 
return __zone_watermark_ok(z, order, mark, classzone_idx, alloc_flags,
@@ -3735,10 +3720,6 @@ gfp_to_alloc_flags(gfp_t gfp_mask)
} else if (unlikely(rt_task(current)) && !in_interrupt())
alloc_flags |= ALLOC_HARDER;
 
-#ifdef CONFIG_CMA
-   if (gfpflags_to_migratetype(gfp_mask) == MIGRATE_MOVABLE)
-   alloc_flags |= ALLOC_CMA;
-#endif
return alloc_flags;
 }
 
@@ -4205,9 +4186,6 @@ static inline bool prepare_alloc_pages(gfp_t gfp_mask, 
unsigned int 

[PATCH v2 0/3] mm/cma: manage the memory of the CMA area by using the ZONE_MOVABLE

[js1304]

From: Joonsoo Kim 

v2
o previous failure in linux-next turned out that it's not the problem of
this patchset. It was caused by the wrong assumption by specific
architecture.

lkml.kernel.org/r/20171114173719.ga28...@atomide.com

o add missing cache flush to the patch "ARM: CMA: avoid double mapping
to the CMA area if CONFIG_HIGHMEM = y"


This patchset is the follow-up of the discussion about the
"Introduce ZONE_CMA (v7)" [1]. Please reference it if more information
is needed.

In this patchset, the memory of the CMA area is managed by using
the ZONE_MOVABLE. Since there is another type of the memory in this zone,
we need to maintain a migratetype for the CMA memory to account
the number of the CMA memory. So, unlike previous patchset, there is
less deletion of the code.

Otherwise, there is no big change.

Motivation of this patchset is described in the commit description of
the patch "mm/cma: manage the memory of the CMA area by using
the ZONE_MOVABLE". Please refer it for more information.

This patchset is based on linux-next-20170822 plus
"mm/page_alloc: don't reserve ZONE_HIGHMEM for ZONE_MOVABLE".

Thanks.

[1]: lkml.kernel.org/r/1491880640-9944-1-git-send-email-iamjoonsoo@lge.com


Joonsoo Kim (3):
  mm/cma: manage the memory of the CMA area by using the ZONE_MOVABLE
  mm/cma: remove ALLOC_CMA
  ARM: CMA: avoid double mapping to the CMA area if CONFIG_HIGHMEM = y

 arch/arm/mm/dma-mapping.c  | 16 +++-
 include/linux/memory_hotplug.h |  3 --
 include/linux/mm.h |  1 +
 mm/cma.c   | 83 --
 mm/compaction.c|  4 +-
 mm/internal.h  |  4 +-
 mm/page_alloc.c| 83 +++---
 7 files changed, 145 insertions(+), 49 deletions(-)

-- 
2.7.4

[PATCH v2 0/3] mm/cma: manage the memory of the CMA area by using the ZONE_MOVABLE

[js1304]

From: Joonsoo Kim 

v2
o previous failure in linux-next turned out that it's not the problem of
this patchset. It was caused by the wrong assumption by specific
architecture.

lkml.kernel.org/r/20171114173719.ga28...@atomide.com

o add missing cache flush to the patch "ARM: CMA: avoid double mapping
to the CMA area if CONFIG_HIGHMEM = y"


This patchset is the follow-up of the discussion about the
"Introduce ZONE_CMA (v7)" [1]. Please reference it if more information
is needed.

In this patchset, the memory of the CMA area is managed by using
the ZONE_MOVABLE. Since there is another type of the memory in this zone,
we need to maintain a migratetype for the CMA memory to account
the number of the CMA memory. So, unlike previous patchset, there is
less deletion of the code.

Otherwise, there is no big change.

Motivation of this patchset is described in the commit description of
the patch "mm/cma: manage the memory of the CMA area by using
the ZONE_MOVABLE". Please refer it for more information.

This patchset is based on linux-next-20170822 plus
"mm/page_alloc: don't reserve ZONE_HIGHMEM for ZONE_MOVABLE".

Thanks.

[1]: lkml.kernel.org/r/1491880640-9944-1-git-send-email-iamjoonsoo@lge.com


Joonsoo Kim (3):
  mm/cma: manage the memory of the CMA area by using the ZONE_MOVABLE
  mm/cma: remove ALLOC_CMA
  ARM: CMA: avoid double mapping to the CMA area if CONFIG_HIGHMEM = y

 arch/arm/mm/dma-mapping.c  | 16 +++-
 include/linux/memory_hotplug.h |  3 --
 include/linux/mm.h |  1 +
 mm/cma.c   | 83 --
 mm/compaction.c|  4 +-
 mm/internal.h  |  4 +-
 mm/page_alloc.c| 83 +++---
 7 files changed, 145 insertions(+), 49 deletions(-)

-- 
2.7.4

[PATCH v5 5/5] misc serdev: w2sg0004: add debugging code and Kconfig

[H. Nikolaus Schaller]

This allows to set CONFIG_W2SG0004_DEBUG which will
make the driver report more activities and it will turn on the
GPS module during boot while the driver assumes that it
is off. This can be used to debug the correct functioning of
the hardware. Therefore we add it as an option to the driver
because we think it is of general use (and a little tricky to
add by system testers).

Normally it should be off.

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/misc/Kconfig|  8 
 drivers/misc/w2sg0004.c | 37 +
 2 files changed, 45 insertions(+)

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index a3b11016ed2b..ad6e60f0cc8c 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -518,4 +518,12 @@ config W2SG0004
  is opened/closed.
  It also provides a rfkill gps name to control the LNA power.
 
+config W2SG0004_DEBUG
+   bool "W2SG0004 on/off debugging"
+   depends on W2SG0004
+   help
+ Enable driver debugging mode of W2SG0004 GPS. If you say y here
+ this will turn on the module and you can check if it is turned
+ off by the driver.
+
 endmenu
diff --git a/drivers/misc/w2sg0004.c b/drivers/misc/w2sg0004.c
index 6bfd12eb8e02..82c708fce510 100644
--- a/drivers/misc/w2sg0004.c
+++ b/drivers/misc/w2sg0004.c
@@ -26,6 +26,10 @@
  *
  */
 
+#ifdef CONFIG_W2SG0004_DEBUG
+#define DEBUG 1
+#endif
+
 #include 
 #include 
 #include 
@@ -256,6 +260,7 @@ static int w2sg_tty_install(struct tty_driver *driver, 
struct tty_struct *tty)
pr_debug("%s() tty = %p\n", __func__, tty);
 
data = w2sg_get_by_minor(tty->index);
+   pr_debug("%s() data = %p\n", __func__, data);
 
if (!data)
return -ENODEV;
@@ -342,6 +347,8 @@ static int w2sg_probe(struct serdev_device *serdev)
if (data == NULL)
return -ENOMEM;
 
+   pr_debug("w2sg serdev_device_set_drvdata\n");
+
serdev_device_set_drvdata(serdev, data);
 
data->on_off_gpio = of_get_named_gpio_flags(serdev->dev.of_node,
@@ -375,6 +382,8 @@ static int w2sg_probe(struct serdev_device *serdev)
 
INIT_DELAYED_WORK(>work, toggle_work);
 
+   pr_debug("w2sg devm_gpio_request\n");
+
err = devm_gpio_request(>dev, data->on_off_gpio,
"w2sg0004-on-off");
if (err < 0)
@@ -388,6 +397,8 @@ static int w2sg_probe(struct serdev_device *serdev)
serdev_device_set_baudrate(data->uart, 9600);
serdev_device_set_flow_control(data->uart, false);
 
+   pr_debug("w2sg rfkill_alloc\n");
+
rf_kill = rfkill_alloc("GPS", >dev, RFKILL_TYPE_GPS,
_rfkill_ops, data);
if (rf_kill == NULL) {
@@ -395,6 +406,8 @@ static int w2sg_probe(struct serdev_device *serdev)
goto err_rfkill;
}
 
+   pr_debug("w2sg register rfkill\n");
+
err = rfkill_register(rf_kill);
if (err) {
dev_err(>dev, "Cannot register rfkill device\n");
@@ -403,6 +416,8 @@ static int w2sg_probe(struct serdev_device *serdev)
 
data->rf_kill = rf_kill;
 
+   pr_debug("w2sg alloc_tty_driver\n");
+
/* allocate the tty driver */
data->tty_drv = alloc_tty_driver(1);
if (!data->tty_drv)
@@ -428,6 +443,8 @@ static int w2sg_probe(struct serdev_device *serdev)
 */
tty_set_operations(data->tty_drv, _serial_ops);
 
+   pr_debug("w2sg tty_register_driver\n");
+
/* register the tty driver */
err = tty_register_driver(data->tty_drv);
if (err) {
@@ -443,9 +460,27 @@ static int w2sg_probe(struct serdev_device *serdev)
tty_port_init(>port);
data->port.ops = _port_ops;
 
+   pr_debug("w2sg call tty_port_register_device\n");
+
data->dev = tty_port_register_device(>port,
data->tty_drv, minor, >dev);
 
+   pr_debug("w2sg tty_port_register_device -> %p\n", data->dev);
+   pr_debug("w2sg port.tty = %p\n", data->port.tty);
+
+   pr_debug("w2sg probed\n");
+
+#ifdef CONFIG_W2SG0004_DEBUG
+   pr_debug("w2sg DEBUGGING MODE enabled\n");
+   /* turn on for debugging rx notifications */
+   pr_debug("w2sg power gpio ON\n");
+   gpio_set_value_cansleep(data->on_off_gpio, 1);
+   mdelay(100);
+   pr_debug("w2sg power gpio OFF\n");
+   gpio_set_value_cansleep(data->on_off_gpio, 0);
+   mdelay(300);
+#endif
+
/* keep off until user space requests the device */
w2sg_set_power(data, false);
 
@@ -455,6 +490,8 @@ static int w2sg_probe(struct serdev_device *serdev)
rfkill_destroy(rf_kill);
serdev_device_close(data->uart);
 out:
+   pr_debug("w2sg error %d\n", err);
+
return err;
 }
 
-- 
2.12.2

[PATCH v5 5/5] misc serdev: w2sg0004: add debugging code and Kconfig

[H. Nikolaus Schaller]

This allows to set CONFIG_W2SG0004_DEBUG which will
make the driver report more activities and it will turn on the
GPS module during boot while the driver assumes that it
is off. This can be used to debug the correct functioning of
the hardware. Therefore we add it as an option to the driver
because we think it is of general use (and a little tricky to
add by system testers).

Normally it should be off.

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/misc/Kconfig|  8 
 drivers/misc/w2sg0004.c | 37 +
 2 files changed, 45 insertions(+)

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index a3b11016ed2b..ad6e60f0cc8c 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -518,4 +518,12 @@ config W2SG0004
  is opened/closed.
  It also provides a rfkill gps name to control the LNA power.
 
+config W2SG0004_DEBUG
+   bool "W2SG0004 on/off debugging"
+   depends on W2SG0004
+   help
+ Enable driver debugging mode of W2SG0004 GPS. If you say y here
+ this will turn on the module and you can check if it is turned
+ off by the driver.
+
 endmenu
diff --git a/drivers/misc/w2sg0004.c b/drivers/misc/w2sg0004.c
index 6bfd12eb8e02..82c708fce510 100644
--- a/drivers/misc/w2sg0004.c
+++ b/drivers/misc/w2sg0004.c
@@ -26,6 +26,10 @@
  *
  */
 
+#ifdef CONFIG_W2SG0004_DEBUG
+#define DEBUG 1
+#endif
+
 #include 
 #include 
 #include 
@@ -256,6 +260,7 @@ static int w2sg_tty_install(struct tty_driver *driver, 
struct tty_struct *tty)
pr_debug("%s() tty = %p\n", __func__, tty);
 
data = w2sg_get_by_minor(tty->index);
+   pr_debug("%s() data = %p\n", __func__, data);
 
if (!data)
return -ENODEV;
@@ -342,6 +347,8 @@ static int w2sg_probe(struct serdev_device *serdev)
if (data == NULL)
return -ENOMEM;
 
+   pr_debug("w2sg serdev_device_set_drvdata\n");
+
serdev_device_set_drvdata(serdev, data);
 
data->on_off_gpio = of_get_named_gpio_flags(serdev->dev.of_node,
@@ -375,6 +382,8 @@ static int w2sg_probe(struct serdev_device *serdev)
 
INIT_DELAYED_WORK(>work, toggle_work);
 
+   pr_debug("w2sg devm_gpio_request\n");
+
err = devm_gpio_request(>dev, data->on_off_gpio,
"w2sg0004-on-off");
if (err < 0)
@@ -388,6 +397,8 @@ static int w2sg_probe(struct serdev_device *serdev)
serdev_device_set_baudrate(data->uart, 9600);
serdev_device_set_flow_control(data->uart, false);
 
+   pr_debug("w2sg rfkill_alloc\n");
+
rf_kill = rfkill_alloc("GPS", >dev, RFKILL_TYPE_GPS,
_rfkill_ops, data);
if (rf_kill == NULL) {
@@ -395,6 +406,8 @@ static int w2sg_probe(struct serdev_device *serdev)
goto err_rfkill;
}
 
+   pr_debug("w2sg register rfkill\n");
+
err = rfkill_register(rf_kill);
if (err) {
dev_err(>dev, "Cannot register rfkill device\n");
@@ -403,6 +416,8 @@ static int w2sg_probe(struct serdev_device *serdev)
 
data->rf_kill = rf_kill;
 
+   pr_debug("w2sg alloc_tty_driver\n");
+
/* allocate the tty driver */
data->tty_drv = alloc_tty_driver(1);
if (!data->tty_drv)
@@ -428,6 +443,8 @@ static int w2sg_probe(struct serdev_device *serdev)
 */
tty_set_operations(data->tty_drv, _serial_ops);
 
+   pr_debug("w2sg tty_register_driver\n");
+
/* register the tty driver */
err = tty_register_driver(data->tty_drv);
if (err) {
@@ -443,9 +460,27 @@ static int w2sg_probe(struct serdev_device *serdev)
tty_port_init(>port);
data->port.ops = _port_ops;
 
+   pr_debug("w2sg call tty_port_register_device\n");
+
data->dev = tty_port_register_device(>port,
data->tty_drv, minor, >dev);
 
+   pr_debug("w2sg tty_port_register_device -> %p\n", data->dev);
+   pr_debug("w2sg port.tty = %p\n", data->port.tty);
+
+   pr_debug("w2sg probed\n");
+
+#ifdef CONFIG_W2SG0004_DEBUG
+   pr_debug("w2sg DEBUGGING MODE enabled\n");
+   /* turn on for debugging rx notifications */
+   pr_debug("w2sg power gpio ON\n");
+   gpio_set_value_cansleep(data->on_off_gpio, 1);
+   mdelay(100);
+   pr_debug("w2sg power gpio OFF\n");
+   gpio_set_value_cansleep(data->on_off_gpio, 0);
+   mdelay(300);
+#endif
+
/* keep off until user space requests the device */
w2sg_set_power(data, false);
 
@@ -455,6 +490,8 @@ static int w2sg_probe(struct serdev_device *serdev)
rfkill_destroy(rf_kill);
serdev_device_close(data->uart);
 out:
+   pr_debug("w2sg error %d\n", err);
+
return err;
 }
 
-- 
2.12.2

[PATCH v5 1/5] dt-bindings: define vendor prefix for Wi2Wi, Inc.

[H. Nikolaus Schaller]

Introduce vendor prefix for Wi2Wi, Inc. for W2SG00x4 GPS modules
and W2CBW003 Bluetooth/WiFi combo (CSR/Marvell).

Signed-off-by: H. Nikolaus Schaller 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 0994bdd82cd3..879f1d9291cd 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -382,6 +382,7 @@ voipac  Voipac Technologies s.r.o.
 wd Western Digital Corp.
 wetek  WeTek Electronics, limited.
 wexler Wexler
+wi2wi  Wi2Wi, Inc.
 winbond Winbond Electronics corp.
 winstarWinstar Display Corp.
 wlfWolfson Microelectronics
-- 
2.12.2

[PATCH v5 1/5] dt-bindings: define vendor prefix for Wi2Wi, Inc.

[H. Nikolaus Schaller]

Introduce vendor prefix for Wi2Wi, Inc. for W2SG00x4 GPS modules
and W2CBW003 Bluetooth/WiFi combo (CSR/Marvell).

Signed-off-by: H. Nikolaus Schaller 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 0994bdd82cd3..879f1d9291cd 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -382,6 +382,7 @@ voipac  Voipac Technologies s.r.o.
 wd Western Digital Corp.
 wetek  WeTek Electronics, limited.
 wexler Wexler
+wi2wi  Wi2Wi, Inc.
 winbond Winbond Electronics corp.
 winstarWinstar Display Corp.
 wlfWolfson Microelectronics
-- 
2.12.2

[PATCH v5 3/5] misc serdev: Add w2sg0004 (gps receiver) power control driver

[H. Nikolaus Schaller]

Add driver for Wi2Wi W2SG0004/84 GPS module connected to some SoC UART.

It uses serdev API hooks to monitor and forward the UART traffic to /dev/ttyGPSn
and turn on/off the module. It also detects if the module is turned on (sends 
data)
but should be off, e.g. if it was already turned on during boot or 
power-on-reset.

Additionally, rfkill block/unblock can be used to control an external LNA
(and power down the module if not needed).

The driver concept is based on code developed by Neil Brown 
but simplified and adapted to use the new serdev API introduced in v4.11.

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/misc/Kconfig|  10 +
 drivers/misc/Makefile   |   1 +
 drivers/misc/w2sg0004.c | 553 
 3 files changed, 564 insertions(+)
 create mode 100644 drivers/misc/w2sg0004.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index f1a5c2357b14..a3b11016ed2b 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -508,4 +508,14 @@ source "drivers/misc/mic/Kconfig"
 source "drivers/misc/genwqe/Kconfig"
 source "drivers/misc/echo/Kconfig"
 source "drivers/misc/cxl/Kconfig"
+
+config W2SG0004
+   tristate "W2SG00x4 on/off control"
+   depends on GPIOLIB && SERIAL_DEV_BUS
+   help
+  Enable on/off control of W2SG00x4 GPS moduled connected
+ to some SoC UART to allow powering up/down if the /dev/ttyGPSn
+ is opened/closed.
+ It also provides a rfkill gps name to control the LNA power.
+
 endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 5ca5f64df478..d9d824b3d20a 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_SRAM_EXEC)   += sram-exec.o
 obj-y  += mic/
 obj-$(CONFIG_GENWQE)   += genwqe/
 obj-$(CONFIG_ECHO) += echo/
+obj-$(CONFIG_W2SG0004) += w2sg0004.o
 obj-$(CONFIG_VEXPRESS_SYSCFG)  += vexpress-syscfg.o
 obj-$(CONFIG_CXL_BASE) += cxl/
 obj-$(CONFIG_ASPEED_LPC_CTRL)  += aspeed-lpc-ctrl.o
diff --git a/drivers/misc/w2sg0004.c b/drivers/misc/w2sg0004.c
new file mode 100644
index ..6bfd12eb8e02
--- /dev/null
+++ b/drivers/misc/w2sg0004.c
@@ -0,0 +1,553 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for power controlling the w2sg0004/w2sg0084 GPS receiver.
+ *
+ * Copyright (C) 2013 Neil Brown 
+ * Copyright (C) 2015-2017 H. Nikolaus Schaller ,
+ * Golden Delicious Computers
+ *
+ * This receiver has an ON/OFF pin which must be toggled to
+ * turn the device 'on' of 'off'.  A high->low->high toggle
+ * will switch the device on if it is off, and off if it is on.
+ *
+ * To enable receiving on/off requests we register with the
+ * UART power management notifications.
+ *
+ * It is not possible to directly detect the state of the device.
+ * However when it is on it will send characters on a UART line
+ * regularly.
+ *
+ * To detect that the power state is out of sync (e.g. if GPS
+ * was enabled before a reboot), we register for UART data received
+ * notifications.
+ *
+ * In addition we register as a rfkill client so that we can
+ * control the LNA power.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * There seems to be restrictions on how quickly we can toggle the
+ * on/off line.  data sheets says "two rtc ticks", whatever that means.
+ * If we do it too soon it doesn't work.
+ * So we have a state machine which uses the common work queue to ensure
+ * clean transitions.
+ * When a change is requested we record that request and only act on it
+ * once the previous change has completed.
+ * A change involves a 10ms low pulse, and a 990ms raised level, so only
+ * one change per second.
+ */
+
+enum w2sg_state {
+   W2SG_IDLE,  /* is not changing state */
+   W2SG_PULSE, /* activate on/off impulse */
+   W2SG_NOPULSE/* deactivate on/off impulse */
+};
+
+struct w2sg_data {
+   struct  rfkill *rf_kill;
+   struct  regulator *lna_regulator;
+   int lna_blocked;/* rfkill block gps active */
+   int lna_is_off; /* LNA is currently off */
+   int is_on;  /* current state (0/1) */
+   unsigned long   last_toggle;
+   unsigned long   backoff;/* time to wait since last_toggle */
+   int on_off_gpio;/* the on-off gpio number */
+   struct  serdev_device *uart;/* uart connected to the chip */
+   struct  tty_driver *tty_drv;/* this is the user space tty */
+   struct  device *dev;/* from tty_port_register_device() */
+   struct  tty_port port;
+   int 

[PATCH v5 4/5] DTS: gta04: add uart2 child node for w2sg00x4

[H. Nikolaus Schaller]

GTA04 has a W2SG0004/84 connected to UART2 of the OMAP3
processor. A GPIO can pulse the on/off toggle switch.

The VSIM regulator is used to power on/off the LNA of an external
active GPS antenna so that a driver can turn the LNA off if GPS is
not needed to save battery energy.

Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap3-gta04.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
b/arch/arm/boot/dts/omap3-gta04.dtsi
index 4504908c23fe..1ad744a25c36 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -477,6 +477,13 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
+
+   gps: gps {
+   compatible = "wi2wi,w2sg0004";
+   lna-supply = <>;   /* LNA regulator */
+   /* GPIO_145: trigger for on/off-impulse for w2sg0004 */
+   enable-gpios = < 17 GPIO_ACTIVE_HIGH>;
+   };
 };
 
  {
-- 
2.12.2

[PATCH v5 3/5] misc serdev: Add w2sg0004 (gps receiver) power control driver

[H. Nikolaus Schaller]

Add driver for Wi2Wi W2SG0004/84 GPS module connected to some SoC UART.

It uses serdev API hooks to monitor and forward the UART traffic to /dev/ttyGPSn
and turn on/off the module. It also detects if the module is turned on (sends 
data)
but should be off, e.g. if it was already turned on during boot or 
power-on-reset.

Additionally, rfkill block/unblock can be used to control an external LNA
(and power down the module if not needed).

The driver concept is based on code developed by Neil Brown 
but simplified and adapted to use the new serdev API introduced in v4.11.

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/misc/Kconfig|  10 +
 drivers/misc/Makefile   |   1 +
 drivers/misc/w2sg0004.c | 553 
 3 files changed, 564 insertions(+)
 create mode 100644 drivers/misc/w2sg0004.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index f1a5c2357b14..a3b11016ed2b 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -508,4 +508,14 @@ source "drivers/misc/mic/Kconfig"
 source "drivers/misc/genwqe/Kconfig"
 source "drivers/misc/echo/Kconfig"
 source "drivers/misc/cxl/Kconfig"
+
+config W2SG0004
+   tristate "W2SG00x4 on/off control"
+   depends on GPIOLIB && SERIAL_DEV_BUS
+   help
+  Enable on/off control of W2SG00x4 GPS moduled connected
+ to some SoC UART to allow powering up/down if the /dev/ttyGPSn
+ is opened/closed.
+ It also provides a rfkill gps name to control the LNA power.
+
 endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 5ca5f64df478..d9d824b3d20a 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_SRAM_EXEC)   += sram-exec.o
 obj-y  += mic/
 obj-$(CONFIG_GENWQE)   += genwqe/
 obj-$(CONFIG_ECHO) += echo/
+obj-$(CONFIG_W2SG0004) += w2sg0004.o
 obj-$(CONFIG_VEXPRESS_SYSCFG)  += vexpress-syscfg.o
 obj-$(CONFIG_CXL_BASE) += cxl/
 obj-$(CONFIG_ASPEED_LPC_CTRL)  += aspeed-lpc-ctrl.o
diff --git a/drivers/misc/w2sg0004.c b/drivers/misc/w2sg0004.c
new file mode 100644
index ..6bfd12eb8e02
--- /dev/null
+++ b/drivers/misc/w2sg0004.c
@@ -0,0 +1,553 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for power controlling the w2sg0004/w2sg0084 GPS receiver.
+ *
+ * Copyright (C) 2013 Neil Brown 
+ * Copyright (C) 2015-2017 H. Nikolaus Schaller ,
+ * Golden Delicious Computers
+ *
+ * This receiver has an ON/OFF pin which must be toggled to
+ * turn the device 'on' of 'off'.  A high->low->high toggle
+ * will switch the device on if it is off, and off if it is on.
+ *
+ * To enable receiving on/off requests we register with the
+ * UART power management notifications.
+ *
+ * It is not possible to directly detect the state of the device.
+ * However when it is on it will send characters on a UART line
+ * regularly.
+ *
+ * To detect that the power state is out of sync (e.g. if GPS
+ * was enabled before a reboot), we register for UART data received
+ * notifications.
+ *
+ * In addition we register as a rfkill client so that we can
+ * control the LNA power.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * There seems to be restrictions on how quickly we can toggle the
+ * on/off line.  data sheets says "two rtc ticks", whatever that means.
+ * If we do it too soon it doesn't work.
+ * So we have a state machine which uses the common work queue to ensure
+ * clean transitions.
+ * When a change is requested we record that request and only act on it
+ * once the previous change has completed.
+ * A change involves a 10ms low pulse, and a 990ms raised level, so only
+ * one change per second.
+ */
+
+enum w2sg_state {
+   W2SG_IDLE,  /* is not changing state */
+   W2SG_PULSE, /* activate on/off impulse */
+   W2SG_NOPULSE/* deactivate on/off impulse */
+};
+
+struct w2sg_data {
+   struct  rfkill *rf_kill;
+   struct  regulator *lna_regulator;
+   int lna_blocked;/* rfkill block gps active */
+   int lna_is_off; /* LNA is currently off */
+   int is_on;  /* current state (0/1) */
+   unsigned long   last_toggle;
+   unsigned long   backoff;/* time to wait since last_toggle */
+   int on_off_gpio;/* the on-off gpio number */
+   struct  serdev_device *uart;/* uart connected to the chip */
+   struct  tty_driver *tty_drv;/* this is the user space tty */
+   struct  device *dev;/* from tty_port_register_device() */
+   struct  tty_port port;
+   int open_count; /* how often we were opened */
+   enum

[PATCH v5 4/5] DTS: gta04: add uart2 child node for w2sg00x4

[H. Nikolaus Schaller]

GTA04 has a W2SG0004/84 connected to UART2 of the OMAP3
processor. A GPIO can pulse the on/off toggle switch.

The VSIM regulator is used to power on/off the LNA of an external
active GPS antenna so that a driver can turn the LNA off if GPS is
not needed to save battery energy.

Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap3-gta04.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
b/arch/arm/boot/dts/omap3-gta04.dtsi
index 4504908c23fe..1ad744a25c36 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -477,6 +477,13 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
+
+   gps: gps {
+   compatible = "wi2wi,w2sg0004";
+   lna-supply = <>;   /* LNA regulator */
+   /* GPIO_145: trigger for on/off-impulse for w2sg0004 */
+   enable-gpios = < 17 GPIO_ACTIVE_HIGH>;
+   };
 };
 
  {
-- 
2.12.2

[PATCH v5 0/5] misc serdev: new serdev based driver for Wi2Wi w2sg00x4 GPS module

[H. Nikolaus Schaller]

Changes V5:
* clarified to keep it in drivers/misc and not create a new group drivers/gps
* fix formatting of new entry in omap3-gta04.dtsi (suggested by Tony Lindgren)
* removed MODULE_ALIAS (suggested by Andrew F. Davis)
* some more formatting, code fixes (suggested by Andrew F. Davis)
* apply __maybe_unused for PM (suggested by Andrew F. Davis)
* fixed copyright and author records (suggested by Andrew F. Davis)

2017-11-15 22:38:01: Changes V4:
* removed all pdata remains (suggested by Arnd Bergmann and Rob Herring)
* fixed minor issues and subject/commit messages (suggested by Rob Herring)
* added one missing Signed-off-By: (suggested by Andreas Färber)
* added SPDX header (suggested by Rob Herring)

2017-11-15 16:19:17: Changes V3:
* worked in suggestions by kbuild test robot
* added misc+serdev to the subject

2017-11-12 22:00:02: Changes V2:
* reduced to submit only w2sg00x4 GPS driver code
* add DT node for GTA04 device to make use of the driver
* split into base code and a debugging Kconfig option (brings device into false 
power state after boot)
* worked in comments by kbuild robot and Rob Herring

2017-05-21 12:44:07: RFC V1
* RFC concerning new serdev based drivers for Wi2Wi w2sg00x4 GPS module and 
w2cbw003 bluetooth

Years long history of getting this devices supported (original work by Neil 
Brown).

H. Nikolaus Schaller (5):
  dt-bindings: define vendor prefix for Wi2Wi, Inc.
  dt-bindings: gps: add w2sg00x4 bindings documentation (GPS module with
UART))
  misc serdev: Add w2sg0004 (gps receiver) power control driver
  DTS: gta04: add uart2 child node for w2sg00x4
  misc serdev: w2sg0004: add debugging code and Kconfig

 .../devicetree/bindings/gps/wi2wi,w2sg0004.txt |  24 +
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 arch/arm/boot/dts/omap3-gta04.dtsi |   7 +
 drivers/misc/Kconfig   |  18 +
 drivers/misc/Makefile  |   1 +
 drivers/misc/w2sg0004.c| 590 +
 6 files changed, 641 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gps/wi2wi,w2sg0004.txt
 create mode 100644 drivers/misc/w2sg0004.c

-- 
2.12.2

[PATCH v5 0/5] misc serdev: new serdev based driver for Wi2Wi w2sg00x4 GPS module

[H. Nikolaus Schaller]

Changes V5:
* clarified to keep it in drivers/misc and not create a new group drivers/gps
* fix formatting of new entry in omap3-gta04.dtsi (suggested by Tony Lindgren)
* removed MODULE_ALIAS (suggested by Andrew F. Davis)
* some more formatting, code fixes (suggested by Andrew F. Davis)
* apply __maybe_unused for PM (suggested by Andrew F. Davis)
* fixed copyright and author records (suggested by Andrew F. Davis)

2017-11-15 22:38:01: Changes V4:
* removed all pdata remains (suggested by Arnd Bergmann and Rob Herring)
* fixed minor issues and subject/commit messages (suggested by Rob Herring)
* added one missing Signed-off-By: (suggested by Andreas Färber)
* added SPDX header (suggested by Rob Herring)

2017-11-15 16:19:17: Changes V3:
* worked in suggestions by kbuild test robot
* added misc+serdev to the subject

2017-11-12 22:00:02: Changes V2:
* reduced to submit only w2sg00x4 GPS driver code
* add DT node for GTA04 device to make use of the driver
* split into base code and a debugging Kconfig option (brings device into false 
power state after boot)
* worked in comments by kbuild robot and Rob Herring

2017-05-21 12:44:07: RFC V1
* RFC concerning new serdev based drivers for Wi2Wi w2sg00x4 GPS module and 
w2cbw003 bluetooth

Years long history of getting this devices supported (original work by Neil 
Brown).

H. Nikolaus Schaller (5):
  dt-bindings: define vendor prefix for Wi2Wi, Inc.
  dt-bindings: gps: add w2sg00x4 bindings documentation (GPS module with
UART))
  misc serdev: Add w2sg0004 (gps receiver) power control driver
  DTS: gta04: add uart2 child node for w2sg00x4
  misc serdev: w2sg0004: add debugging code and Kconfig

 .../devicetree/bindings/gps/wi2wi,w2sg0004.txt |  24 +
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 arch/arm/boot/dts/omap3-gta04.dtsi |   7 +
 drivers/misc/Kconfig   |  18 +
 drivers/misc/Makefile  |   1 +
 drivers/misc/w2sg0004.c| 590 +
 6 files changed, 641 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gps/wi2wi,w2sg0004.txt
 create mode 100644 drivers/misc/w2sg0004.c

-- 
2.12.2

[PATCH v5 2/5] dt-bindings: gps: add w2sg00x4 bindings documentation (GPS module with UART))

[H. Nikolaus Schaller]

add bindings documentation for Wi2Wi W2SG00x4 GPS module.

Signed-off-by: H. Nikolaus Schaller 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/gps/wi2wi,w2sg0004.txt | 24 ++
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gps/wi2wi,w2sg0004.txt

diff --git a/Documentation/devicetree/bindings/gps/wi2wi,w2sg0004.txt 
b/Documentation/devicetree/bindings/gps/wi2wi,w2sg0004.txt
new file mode 100644
index ..bcf307382afb
--- /dev/null
+++ b/Documentation/devicetree/bindings/gps/wi2wi,w2sg0004.txt
@@ -0,0 +1,24 @@
+Wi2Wi GPS module connected through UART
+
+Should be a subnode of the SoC UART it is connected to.
+
+Required properties:
+- compatible:  should be one of (depending on precise model)
+   "wi2wi,w2sg0004"
+   "wi2wi,w2sg0084"
+- enable-gpio: the GPIO that controls the module's power toggle
+   input. A positive impulse of sufficent length toggles the
+   power state.
+
+Optional properties:
+- lna-supply:  an (optional) LNA regulator that is enabled together with the 
GPS receiver
+
+Example:
+
+ {
+   w2sg0004: gps {
+   compatible = "wi2wi,w2sg0004";
+   lna-supply = <>;   /* LNA regulator */
+   enable-gpios = < 17 GPIO_ACTIVE_HIGH>;/* GPIO_145: 
trigger for turning on/off w2sg0004 */
+};
+};
-- 
2.12.2

[PATCH v5 2/5] dt-bindings: gps: add w2sg00x4 bindings documentation (GPS module with UART))

[H. Nikolaus Schaller]

add bindings documentation for Wi2Wi W2SG00x4 GPS module.

Signed-off-by: H. Nikolaus Schaller 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/gps/wi2wi,w2sg0004.txt | 24 ++
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gps/wi2wi,w2sg0004.txt

diff --git a/Documentation/devicetree/bindings/gps/wi2wi,w2sg0004.txt 
b/Documentation/devicetree/bindings/gps/wi2wi,w2sg0004.txt
new file mode 100644
index ..bcf307382afb
--- /dev/null
+++ b/Documentation/devicetree/bindings/gps/wi2wi,w2sg0004.txt
@@ -0,0 +1,24 @@
+Wi2Wi GPS module connected through UART
+
+Should be a subnode of the SoC UART it is connected to.
+
+Required properties:
+- compatible:  should be one of (depending on precise model)
+   "wi2wi,w2sg0004"
+   "wi2wi,w2sg0084"
+- enable-gpio: the GPIO that controls the module's power toggle
+   input. A positive impulse of sufficent length toggles the
+   power state.
+
+Optional properties:
+- lna-supply:  an (optional) LNA regulator that is enabled together with the 
GPS receiver
+
+Example:
+
+ {
+   w2sg0004: gps {
+   compatible = "wi2wi,w2sg0004";
+   lna-supply = <>;   /* LNA regulator */
+   enable-gpios = < 17 GPIO_ACTIVE_HIGH>;/* GPIO_145: 
trigger for turning on/off w2sg0004 */
+};
+};
-- 
2.12.2

Re: [PATCH v4 2/5] soc: qcom: Introduce QMI helpers

[Philippe Ombredanne]

On Fri, Dec 1, 2017 at 6:35 AM, Bjorn Andersson
 wrote:
> On Thu 30 Nov 00:18 PST 2017, Philippe Ombredanne wrote:
>
>> Bjorn,
>>
>> On Thu, Nov 30, 2017 at 2:16 AM, Bjorn Andersson
>>  wrote:
>> []
>> > diff --git a/drivers/soc/qcom/qmi_interface.c 
>> > b/drivers/soc/qcom/qmi_interface.c
>> > new file mode 100644
>> > index ..4027b52b0834
>> > --- /dev/null
>> > +++ b/drivers/soc/qcom/qmi_interface.c
>> > @@ -0,0 +1,857 @@
>> > +/*
>> > + * Copyright (C) 2017 Linaro Ltd.
>> > + *
>> > + * This software is licensed under the terms of the GNU General Public
>> > + * License version 2, as published by the Free Software Foundation, and
>> > + * may be copied, distributed, and modified under those terms.
>> > + *
>> > + * This program is distributed in the hope that it will be useful,
>> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> > + * GNU General Public License for more details.
>> > + */
>>
>> Could it make sense, especially for new files, to use the new SPDX ids
>> and avoid adding boilerplate that will need to be cleaned up later?
>> e.g. something like this instead, using the new conventions started by
>> greg-kh and by documented tglx?
>>
>> NB: the // comment  style is not a mistake and is what Linus wants
>> there. See the threads on this topic.
>>
>> > @@ -0,0 +1,857 @@
>> > +// SPDX-License-Identifier: GPL-2.0
>> > +/*
>> > + * Copyright (C) 2017 Linaro Ltd.
>> > + */
>>
>> Isn't this shorter and better? :P
>>
>
> That sounds very reasonable, I will update the patches.

Note that when you only have a copyright left in a header comment
after removing the boilerplate, you might want to consider this even
shorter and cleaner form instead. But that's just me telling this:

>> > +// SPDX-License-Identifier: GPL-2.0
>> > +// Copyright (C) 2017 Linaro Ltd.

>> BTW, if you need help to fix this on the rest of Linaro contributed
>> code, I maintain a tool that can help there.
>>
>
> I haven't seen any guidelines on how this should be introduced
> throughout the kernel,

Thomas has sent a first doc patch [1] set. AFAIK he is working on an
updated version whenever his real time body clock yields a few ticks
so he can wrap this out.  But his real time clock only rarely yield
ticks outside of hard real time coding work ;)

Jonathan also wrote a nice background article on the topic at LWN [2].

I heard this was also briefly discussed among maintainers at the
plumbers meetup in Los Angeles: for me I only briefly discussed this
with Linus and Greg just before the meetup, but I could not stay
longer.

> should I make a similar push for the subsystems I
> maintain?

That would be great! And beside the fact it always feels good to
delete lines of code for once, this is one of the rare areas where you
can kill some lines and be pretty sure it will still compile and run
afterwards  well in most cases: Greg and Thomas found funny
cases of .h headers included in assembly where using the // comment
style was actually making things break weirdly and the compilation
would go down in flames with a beautiful tail spin : in these cases,
the convention is to use /**/ comments instead)

Again, if you need help with this, I can modestly chip in with my
scancode-toolkit tool and good intentions.

[1] https://marc.info/?l=linux-kernel=151051532322831=2
[2] https://lwn.net/SubscriberLink/739183/262749cbe307ddc7/
-- 
Cordially
Philippe Ombredanne, a happy licensing comments cleaner

Re: [PATCH v4 2/5] soc: qcom: Introduce QMI helpers

[Philippe Ombredanne]

On Fri, Dec 1, 2017 at 6:35 AM, Bjorn Andersson
 wrote:
> On Thu 30 Nov 00:18 PST 2017, Philippe Ombredanne wrote:
>
>> Bjorn,
>>
>> On Thu, Nov 30, 2017 at 2:16 AM, Bjorn Andersson
>>  wrote:
>> []
>> > diff --git a/drivers/soc/qcom/qmi_interface.c 
>> > b/drivers/soc/qcom/qmi_interface.c
>> > new file mode 100644
>> > index ..4027b52b0834
>> > --- /dev/null
>> > +++ b/drivers/soc/qcom/qmi_interface.c
>> > @@ -0,0 +1,857 @@
>> > +/*
>> > + * Copyright (C) 2017 Linaro Ltd.
>> > + *
>> > + * This software is licensed under the terms of the GNU General Public
>> > + * License version 2, as published by the Free Software Foundation, and
>> > + * may be copied, distributed, and modified under those terms.
>> > + *
>> > + * This program is distributed in the hope that it will be useful,
>> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> > + * GNU General Public License for more details.
>> > + */
>>
>> Could it make sense, especially for new files, to use the new SPDX ids
>> and avoid adding boilerplate that will need to be cleaned up later?
>> e.g. something like this instead, using the new conventions started by
>> greg-kh and by documented tglx?
>>
>> NB: the // comment  style is not a mistake and is what Linus wants
>> there. See the threads on this topic.
>>
>> > @@ -0,0 +1,857 @@
>> > +// SPDX-License-Identifier: GPL-2.0
>> > +/*
>> > + * Copyright (C) 2017 Linaro Ltd.
>> > + */
>>
>> Isn't this shorter and better? :P
>>
>
> That sounds very reasonable, I will update the patches.

Note that when you only have a copyright left in a header comment
after removing the boilerplate, you might want to consider this even
shorter and cleaner form instead. But that's just me telling this:

>> > +// SPDX-License-Identifier: GPL-2.0
>> > +// Copyright (C) 2017 Linaro Ltd.

>> BTW, if you need help to fix this on the rest of Linaro contributed
>> code, I maintain a tool that can help there.
>>
>
> I haven't seen any guidelines on how this should be introduced
> throughout the kernel,

Thomas has sent a first doc patch [1] set. AFAIK he is working on an
updated version whenever his real time body clock yields a few ticks
so he can wrap this out.  But his real time clock only rarely yield
ticks outside of hard real time coding work ;)

Jonathan also wrote a nice background article on the topic at LWN [2].

I heard this was also briefly discussed among maintainers at the
plumbers meetup in Los Angeles: for me I only briefly discussed this
with Linus and Greg just before the meetup, but I could not stay
longer.

> should I make a similar push for the subsystems I
> maintain?

That would be great! And beside the fact it always feels good to
delete lines of code for once, this is one of the rare areas where you
can kill some lines and be pretty sure it will still compile and run
afterwards  well in most cases: Greg and Thomas found funny
cases of .h headers included in assembly where using the // comment
style was actually making things break weirdly and the compilation
would go down in flames with a beautiful tail spin : in these cases,
the convention is to use /**/ comments instead)

Again, if you need help with this, I can modestly chip in with my
scancode-toolkit tool and good intentions.

[1] https://marc.info/?l=linux-kernel=151051532322831=2
[2] https://lwn.net/SubscriberLink/739183/262749cbe307ddc7/
-- 
Cordially
Philippe Ombredanne, a happy licensing comments cleaner

Re: [PATCH v3 1/4] omapdrm: panel: fix compatible vendor string for td028ttec1

[H. Nikolaus Schaller]

> Am 01.12.2017 um 02:57 schrieb Rob Herring :
> 
> On Tue, Nov 28, 2017 at 04:48:54PM +0100, H. Nikolaus Schaller wrote:
>> The vendor name was "toppoly" but other panels and the vendor list
>> have defined it as "tpo". So let's fix it in driver and bindings.
>> 
>> We keep the old definition in parallel to stay compatible with
>> potential older DTB setup.
>> 
>> Signed-off-by: H. Nikolaus Schaller 
>> ---
>> .../display/panel/{toppoly,td028ttec1.txt => tpo,td028ttec1.txt}  | 4 
>> ++--
>> drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c   | 3 +++
>> drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c  | 3 +++
>> 3 files changed, 8 insertions(+), 2 deletions(-)
>> rename 
>> Documentation/devicetree/bindings/display/panel/{toppoly,td028ttec1.txt => 
>> tpo,td028ttec1.txt} (84%)
>> 
>> diff --git 
>> a/Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt 
>> b/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
>> similarity index 84%
>> rename from 
>> Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt
>> rename to Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
>> index 7175dc3740ac..ed34253d9fb1 100644
>> --- a/Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt
>> +++ b/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
>> @@ -2,7 +2,7 @@ Toppoly TD028TTEC1 Panel
>> 
>> 
>> Required properties:
>> -- compatible: "toppoly,td028ttec1"
>> +- compatible: "tpo,td028ttec1"
>> 
>> Optional properties:
>> - label: a symbolic name for the panel
>> @@ -14,7 +14,7 @@ Example
>> ---
>> 
>> lcd-panel: td028ttec1@0 {
>> -compatible = "toppoly,td028ttec1";
>> +compatible = "tpo,td028ttec1";
>>  reg = <0>;
>>  spi-max-frequency = <10>;
>>  spi-cpol;
>> diff --git a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c 
>> b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
>> index 0a38a0e8c925..a0dfa14f4fab 100644
>> --- a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
>> +++ b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
>> @@ -452,6 +452,8 @@ static int td028ttec1_panel_remove(struct spi_device 
>> *spi)
>> }
>> 
>> static const struct of_device_id td028ttec1_of_match[] = {
>> +{ .compatible = "omapdss,tpo,td028ttec1", },
> 
> Why the omapdss part?

I think because they are (currently and still) omapdrm
(omapdss) specific since SoC specific drivers for the
same panel may exist in parallel.

All panel drivers in drivers/gpu/drm/omapdrm/displays
have and need this prefix.

As far as I understand, the omapdss driver takes the
DTS compatible string, adds "omapdss," and then looks for
a panel driver to probe.

See also: Sebastian Reichel's comment to "[PATCH v3 4/4] DTS: Pandora: fix 
panel compatibility string"

BR,
Nikolaus Schaller

Re: [PATCH v3 1/4] omapdrm: panel: fix compatible vendor string for td028ttec1

[H. Nikolaus Schaller]

> Am 01.12.2017 um 02:57 schrieb Rob Herring :
> 
> On Tue, Nov 28, 2017 at 04:48:54PM +0100, H. Nikolaus Schaller wrote:
>> The vendor name was "toppoly" but other panels and the vendor list
>> have defined it as "tpo". So let's fix it in driver and bindings.
>> 
>> We keep the old definition in parallel to stay compatible with
>> potential older DTB setup.
>> 
>> Signed-off-by: H. Nikolaus Schaller 
>> ---
>> .../display/panel/{toppoly,td028ttec1.txt => tpo,td028ttec1.txt}  | 4 
>> ++--
>> drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c   | 3 +++
>> drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c  | 3 +++
>> 3 files changed, 8 insertions(+), 2 deletions(-)
>> rename 
>> Documentation/devicetree/bindings/display/panel/{toppoly,td028ttec1.txt => 
>> tpo,td028ttec1.txt} (84%)
>> 
>> diff --git 
>> a/Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt 
>> b/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
>> similarity index 84%
>> rename from 
>> Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt
>> rename to Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
>> index 7175dc3740ac..ed34253d9fb1 100644
>> --- a/Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt
>> +++ b/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
>> @@ -2,7 +2,7 @@ Toppoly TD028TTEC1 Panel
>> 
>> 
>> Required properties:
>> -- compatible: "toppoly,td028ttec1"
>> +- compatible: "tpo,td028ttec1"
>> 
>> Optional properties:
>> - label: a symbolic name for the panel
>> @@ -14,7 +14,7 @@ Example
>> ---
>> 
>> lcd-panel: td028ttec1@0 {
>> -compatible = "toppoly,td028ttec1";
>> +compatible = "tpo,td028ttec1";
>>  reg = <0>;
>>  spi-max-frequency = <10>;
>>  spi-cpol;
>> diff --git a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c 
>> b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
>> index 0a38a0e8c925..a0dfa14f4fab 100644
>> --- a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
>> +++ b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
>> @@ -452,6 +452,8 @@ static int td028ttec1_panel_remove(struct spi_device 
>> *spi)
>> }
>> 
>> static const struct of_device_id td028ttec1_of_match[] = {
>> +{ .compatible = "omapdss,tpo,td028ttec1", },
> 
> Why the omapdss part?

I think because they are (currently and still) omapdrm
(omapdss) specific since SoC specific drivers for the
same panel may exist in parallel.

All panel drivers in drivers/gpu/drm/omapdrm/displays
have and need this prefix.

As far as I understand, the omapdss driver takes the
DTS compatible string, adds "omapdss," and then looks for
a panel driver to probe.

See also: Sebastian Reichel's comment to "[PATCH v3 4/4] DTS: Pandora: fix 
panel compatibility string"

BR,
Nikolaus Schaller

[PATCH 1/1] timecounter: Make cyclecounter struct part of timecounter struct

[Sagar Arun Kamble]

There is no real need for the users of timecounters to define cyclecounter
and timecounter variables separately. Since timecounter will always be
based on cyclecounter, have cyclecounter struct as member of timecounter
struct.

Suggested-by: Chris Wilson 
Signed-off-by: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: John Stultz 
Cc: Thomas Gleixner 
Cc: Stephen Boyd 
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: net...@vger.kernel.org
Cc: intel-wired-...@lists.osuosl.org
Cc: linux-r...@vger.kernel.org
Cc: alsa-de...@alsa-project.org
Cc: kvm...@lists.cs.columbia.edu
---
 arch/microblaze/kernel/timer.c | 20 ++--
 drivers/clocksource/arm_arch_timer.c   | 19 ++--
 drivers/net/ethernet/amd/xgbe/xgbe-dev.c   |  3 +-
 drivers/net/ethernet/amd/xgbe/xgbe-ptp.c   |  9 +++---
 drivers/net/ethernet/amd/xgbe/xgbe.h   |  1 -
 drivers/net/ethernet/broadcom/bnx2x/bnx2x.h|  1 -
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c   | 20 ++--
 drivers/net/ethernet/freescale/fec.h   |  1 -
 drivers/net/ethernet/freescale/fec_ptp.c   | 30 +-
 drivers/net/ethernet/intel/e1000e/e1000.h  |  1 -
 drivers/net/ethernet/intel/e1000e/netdev.c | 27 
 drivers/net/ethernet/intel/e1000e/ptp.c|  2 +-
 drivers/net/ethernet/intel/igb/igb.h   |  1 -
 drivers/net/ethernet/intel/igb/igb_ptp.c   | 25 ---
 drivers/net/ethernet/intel/ixgbe/ixgbe.h   |  1 -
 drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c   | 17 +-
 drivers/net/ethernet/mellanox/mlx4/en_clock.c  | 28 -
 drivers/net/ethernet/mellanox/mlx4/mlx4_en.h   |  1 -
 .../net/ethernet/mellanox/mlx5/core/lib/clock.c| 34 ++--
 drivers/net/ethernet/qlogic/qede/qede_ptp.c| 20 ++--
 drivers/net/ethernet/ti/cpts.c | 36 --
 drivers/net/ethernet/ti/cpts.h |  1 -
 include/linux/mlx5/driver.h|  1 -
 include/linux/timecounter.h|  4 +--
 include/sound/hdaudio.h|  1 -
 kernel/time/timecounter.c  | 28 -
 sound/hda/hdac_stream.c|  7 +++--
 virt/kvm/arm/arch_timer.c  |  6 ++--
 28 files changed, 163 insertions(+), 182 deletions(-)

diff --git a/arch/microblaze/kernel/timer.c b/arch/microblaze/kernel/timer.c
index 7de941c..b7f89e9 100644
--- a/arch/microblaze/kernel/timer.c
+++ b/arch/microblaze/kernel/timer.c
@@ -199,27 +199,25 @@ static u64 xilinx_read(struct clocksource *cs)
return (u64)xilinx_clock_read();
 }
 
-static struct timecounter xilinx_tc = {
-   .cc = NULL,
-};
-
 static u64 xilinx_cc_read(const struct cyclecounter *cc)
 {
return xilinx_read(NULL);
 }
 
-static struct cyclecounter xilinx_cc = {
-   .read = xilinx_cc_read,
-   .mask = CLOCKSOURCE_MASK(32),
-   .shift = 8,
+static struct timecounter xilinx_tc = {
+   .cc.read = xilinx_cc_read,
+   .cc.mask = CLOCKSOURCE_MASK(32),
+   .cc.mult = 0,
+   .cc.shift = 8,
 };
 
 static int __init init_xilinx_timecounter(void)
 {
-   xilinx_cc.mult = div_sc(timer_clock_freq, NSEC_PER_SEC,
-   xilinx_cc.shift);
+   struct cyclecounter *cc = _tc.cc;
+
+   cc->mult = div_sc(timer_clock_freq, NSEC_PER_SEC, cc->shift);
 
-   timecounter_init(_tc, _cc, sched_clock());
+   timecounter_init(_tc, sched_clock());
 
return 0;
 }
diff --git a/drivers/clocksource/arm_arch_timer.c 
b/drivers/clocksource/arm_arch_timer.c
index 57cb2f0..31543e5 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -179,11 +179,6 @@ static u64 arch_counter_read_cc(const struct cyclecounter 
*cc)
.flags  = CLOCK_SOURCE_IS_CONTINUOUS,
 };
 
-static struct cyclecounter cyclecounter __ro_after_init = {
-   .read   = arch_counter_read_cc,
-   .mask   = CLOCKSOURCE_MASK(56),
-};
-
 struct ate_acpi_oem_info {
char oem_id[ACPI_OEM_ID_SIZE + 1];
char oem_table_id[ACPI_OEM_TABLE_ID_SIZE + 1];
@@ -915,7 +910,10 @@ static u64 arch_counter_get_cntvct_mem(void)
return ((u64) vct_hi << 32) | vct_lo;
 }
 
-static struct arch_timer_kvm_info arch_timer_kvm_info;
+static struct arch_timer_kvm_info arch_timer_kvm_info = {
+   .timecounter.cc.read = arch_counter_read_cc,
+   .timecounter.cc.mask = CLOCKSOURCE_MASK(56),
+};
 
 struct arch_timer_kvm_info *arch_timer_get_kvm_info(void)
 {
@@ -925,6 +923,7 @@ struct arch_timer_kvm_info *arch_timer_get_kvm_info(void)
 static void __init arch_counter_register(unsigned type)
 {
u64 start_count;
+   

[PATCH 1/1] timecounter: Make cyclecounter struct part of timecounter struct

[Sagar Arun Kamble]

There is no real need for the users of timecounters to define cyclecounter
and timecounter variables separately. Since timecounter will always be
based on cyclecounter, have cyclecounter struct as member of timecounter
struct.

Suggested-by: Chris Wilson 
Signed-off-by: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: John Stultz 
Cc: Thomas Gleixner 
Cc: Stephen Boyd 
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: net...@vger.kernel.org
Cc: intel-wired-...@lists.osuosl.org
Cc: linux-r...@vger.kernel.org
Cc: alsa-de...@alsa-project.org
Cc: kvm...@lists.cs.columbia.edu
---
 arch/microblaze/kernel/timer.c | 20 ++--
 drivers/clocksource/arm_arch_timer.c   | 19 ++--
 drivers/net/ethernet/amd/xgbe/xgbe-dev.c   |  3 +-
 drivers/net/ethernet/amd/xgbe/xgbe-ptp.c   |  9 +++---
 drivers/net/ethernet/amd/xgbe/xgbe.h   |  1 -
 drivers/net/ethernet/broadcom/bnx2x/bnx2x.h|  1 -
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c   | 20 ++--
 drivers/net/ethernet/freescale/fec.h   |  1 -
 drivers/net/ethernet/freescale/fec_ptp.c   | 30 +-
 drivers/net/ethernet/intel/e1000e/e1000.h  |  1 -
 drivers/net/ethernet/intel/e1000e/netdev.c | 27 
 drivers/net/ethernet/intel/e1000e/ptp.c|  2 +-
 drivers/net/ethernet/intel/igb/igb.h   |  1 -
 drivers/net/ethernet/intel/igb/igb_ptp.c   | 25 ---
 drivers/net/ethernet/intel/ixgbe/ixgbe.h   |  1 -
 drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c   | 17 +-
 drivers/net/ethernet/mellanox/mlx4/en_clock.c  | 28 -
 drivers/net/ethernet/mellanox/mlx4/mlx4_en.h   |  1 -
 .../net/ethernet/mellanox/mlx5/core/lib/clock.c| 34 ++--
 drivers/net/ethernet/qlogic/qede/qede_ptp.c| 20 ++--
 drivers/net/ethernet/ti/cpts.c | 36 --
 drivers/net/ethernet/ti/cpts.h |  1 -
 include/linux/mlx5/driver.h|  1 -
 include/linux/timecounter.h|  4 +--
 include/sound/hdaudio.h|  1 -
 kernel/time/timecounter.c  | 28 -
 sound/hda/hdac_stream.c|  7 +++--
 virt/kvm/arm/arch_timer.c  |  6 ++--
 28 files changed, 163 insertions(+), 182 deletions(-)

diff --git a/arch/microblaze/kernel/timer.c b/arch/microblaze/kernel/timer.c
index 7de941c..b7f89e9 100644
--- a/arch/microblaze/kernel/timer.c
+++ b/arch/microblaze/kernel/timer.c
@@ -199,27 +199,25 @@ static u64 xilinx_read(struct clocksource *cs)
return (u64)xilinx_clock_read();
 }
 
-static struct timecounter xilinx_tc = {
-   .cc = NULL,
-};
-
 static u64 xilinx_cc_read(const struct cyclecounter *cc)
 {
return xilinx_read(NULL);
 }
 
-static struct cyclecounter xilinx_cc = {
-   .read = xilinx_cc_read,
-   .mask = CLOCKSOURCE_MASK(32),
-   .shift = 8,
+static struct timecounter xilinx_tc = {
+   .cc.read = xilinx_cc_read,
+   .cc.mask = CLOCKSOURCE_MASK(32),
+   .cc.mult = 0,
+   .cc.shift = 8,
 };
 
 static int __init init_xilinx_timecounter(void)
 {
-   xilinx_cc.mult = div_sc(timer_clock_freq, NSEC_PER_SEC,
-   xilinx_cc.shift);
+   struct cyclecounter *cc = _tc.cc;
+
+   cc->mult = div_sc(timer_clock_freq, NSEC_PER_SEC, cc->shift);
 
-   timecounter_init(_tc, _cc, sched_clock());
+   timecounter_init(_tc, sched_clock());
 
return 0;
 }
diff --git a/drivers/clocksource/arm_arch_timer.c 
b/drivers/clocksource/arm_arch_timer.c
index 57cb2f0..31543e5 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -179,11 +179,6 @@ static u64 arch_counter_read_cc(const struct cyclecounter 
*cc)
.flags  = CLOCK_SOURCE_IS_CONTINUOUS,
 };
 
-static struct cyclecounter cyclecounter __ro_after_init = {
-   .read   = arch_counter_read_cc,
-   .mask   = CLOCKSOURCE_MASK(56),
-};
-
 struct ate_acpi_oem_info {
char oem_id[ACPI_OEM_ID_SIZE + 1];
char oem_table_id[ACPI_OEM_TABLE_ID_SIZE + 1];
@@ -915,7 +910,10 @@ static u64 arch_counter_get_cntvct_mem(void)
return ((u64) vct_hi << 32) | vct_lo;
 }
 
-static struct arch_timer_kvm_info arch_timer_kvm_info;
+static struct arch_timer_kvm_info arch_timer_kvm_info = {
+   .timecounter.cc.read = arch_counter_read_cc,
+   .timecounter.cc.mask = CLOCKSOURCE_MASK(56),
+};
 
 struct arch_timer_kvm_info *arch_timer_get_kvm_info(void)
 {
@@ -925,6 +923,7 @@ struct arch_timer_kvm_info *arch_timer_get_kvm_info(void)
 static void __init arch_counter_register(unsigned type)
 {
u64 start_count;
+   struct cyclecounter *cc = _timer_kvm_info.timecounter.cc;
 
/* Register the CP15 based counter if we have one */
if (type & 

[PATCH v4 1/2] DTS: GTA04: improve panel compatibility string

[H. Nikolaus Schaller]

Official vendor string is now "tpo" and not "toppoly".

Requires patch "omapdrm: panel: fix compatible vendor string for td028ttec1"
so that the driver understands both.

Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
b/arch/arm/boot/dts/omap3-gta04.dtsi
index 4504908c23fe..ec27ed67a22a 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -86,7 +86,7 @@
 
/* lcd panel */
lcd: td028ttec1@0 {
-   compatible = "toppoly,td028ttec1";
+   compatible = "tpo,td028ttec1";
reg = <0>;
spi-max-frequency = <10>;
spi-cpol;
-- 
2.12.2

Re: Creating cyclecounter and lock member in timecounter structure [ Was Re: [RFC 1/4] drm/i915/perf: Add support to correlate GPU timestamp with system time]

[Sagar Arun Kamble]

On 12/1/2017 2:33 AM, Saeed Mahameed wrote:

On Mon, Nov 27, 2017 at 2:05 AM, Sagar Arun Kamble
 wrote:


On 11/24/2017 7:01 PM, Thomas Gleixner wrote:

On Fri, 24 Nov 2017, Sagar Arun Kamble wrote:

On 11/24/2017 12:29 AM, Thomas Gleixner wrote:

On Thu, 23 Nov 2017, Sagar Arun Kamble wrote:

We needed inputs on possible optimization that can be done to
timecounter/cyclecounter structures/usage.
This mail is in response to review of patch
https://patchwork.freedesktop.org/patch/188448/.

As Chris's observation below, about dozen of timecounter users in the
kernel
have below structures
defined individually:

spinlock_t lock;
struct cyclecounter cc;
struct timecounter tc;

Can we move lock and cc to tc? That way it will be convenient.
Also it will allow unifying the locking/overflow watchdog handling
across
all
drivers.

Looks like none of the timecounter usage sites has a real need to
separate
timecounter and cyclecounter.

Yes. Will share patch for this change.


The lock is a different question. The locking of the various drivers
differs and I have no idea how you want to handle that. Just sticking
the
lock into the datastructure and then not making use of it in the
timercounter code and leave it to the callsites does not make sense.

Most of the locks are held around timecounter_read. In some instances it
is held when cyclecounter is updated standalone or is updated along with
timecounter calls.  Was thinking if we move the lock in timecounter
functions, drivers just have to do locking around its operations on
cyclecounter. But then another problem I see is there are variation of
locking calls like lock_irqsave, lock_bh, write_lock_irqsave (some using
rwlock_t). Should this all locking be left to driver only then?

You could have the lock in the struct and protect the inner workings in
the
related core functions.

That might remove locking requirements from some of the callers and the
others still have their own thing around it.


For drivers having static/fixed cyclecounter, we can rely only on lock
inside timecounter.
Most of the network drivers update cyclecounter at runtime and they will
have to rely on two locks if
we add one to timecounter. This may not be efficient for them. Also the lock
in timecounter has to be less restrictive (may be seqlock) I guess.

Cc'd Mellanox list for inputs on this.

I have started feeling that the current approach of drivers managing the
locks is the right one so better leave the
lock out of timecounter.


I agree here,

In mlx5 we rely on our own read/write lock to serialize access to
mlx5_clock struct (mlx5 timecounter and cyclecounter).
the access is not as simple as
lock()
call time_counter_API
unlock()

Sometimes we also explicitly update/adjust timecycles counters with
mlx5 specific calculations after we read the timecounter all inside
our lock.
e.g.
@mlx5_ptp_adjfreq()

 write_lock_irqsave(>lock, flags);
 timecounter_read(>tc);
 clock->cycles.mult = neg_adj ? clock->nominal_c_mult - diff :
clock->nominal_c_mult + diff;
 write_unlock_irqrestore(>lock, flags);

So i don't think it will be a simple task to have a generic thread
safe timecounter API, without the need to specifically adjust it for
all driver use-cases.
Also as said above, in runtime it is not obvious in which context the
timecounter will be accessed irq/soft irq/user.

let's keep it as is, and let the driver decide which locking scheme is
most suitable for it.


Yes. Thanks for your inputs Saeed.

Regards
Sagar



Thanks,
Saeed.


Thanks,

 tglx


--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 1/2] DTS: GTA04: improve panel compatibility string

[H. Nikolaus Schaller]

Official vendor string is now "tpo" and not "toppoly".

Requires patch "omapdrm: panel: fix compatible vendor string for td028ttec1"
so that the driver understands both.

Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
b/arch/arm/boot/dts/omap3-gta04.dtsi
index 4504908c23fe..ec27ed67a22a 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -86,7 +86,7 @@
 
/* lcd panel */
lcd: td028ttec1@0 {
-   compatible = "toppoly,td028ttec1";
+   compatible = "tpo,td028ttec1";
reg = <0>;
spi-max-frequency = <10>;
spi-cpol;
-- 
2.12.2

Re: Creating cyclecounter and lock member in timecounter structure [ Was Re: [RFC 1/4] drm/i915/perf: Add support to correlate GPU timestamp with system time]

[Sagar Arun Kamble]

On 12/1/2017 2:33 AM, Saeed Mahameed wrote:

On Mon, Nov 27, 2017 at 2:05 AM, Sagar Arun Kamble
 wrote:


On 11/24/2017 7:01 PM, Thomas Gleixner wrote:

On Fri, 24 Nov 2017, Sagar Arun Kamble wrote:

On 11/24/2017 12:29 AM, Thomas Gleixner wrote:

On Thu, 23 Nov 2017, Sagar Arun Kamble wrote:

We needed inputs on possible optimization that can be done to
timecounter/cyclecounter structures/usage.
This mail is in response to review of patch
https://patchwork.freedesktop.org/patch/188448/.

As Chris's observation below, about dozen of timecounter users in the
kernel
have below structures
defined individually:

spinlock_t lock;
struct cyclecounter cc;
struct timecounter tc;

Can we move lock and cc to tc? That way it will be convenient.
Also it will allow unifying the locking/overflow watchdog handling
across
all
drivers.

Looks like none of the timecounter usage sites has a real need to
separate
timecounter and cyclecounter.

Yes. Will share patch for this change.


The lock is a different question. The locking of the various drivers
differs and I have no idea how you want to handle that. Just sticking
the
lock into the datastructure and then not making use of it in the
timercounter code and leave it to the callsites does not make sense.

Most of the locks are held around timecounter_read. In some instances it
is held when cyclecounter is updated standalone or is updated along with
timecounter calls.  Was thinking if we move the lock in timecounter
functions, drivers just have to do locking around its operations on
cyclecounter. But then another problem I see is there are variation of
locking calls like lock_irqsave, lock_bh, write_lock_irqsave (some using
rwlock_t). Should this all locking be left to driver only then?

You could have the lock in the struct and protect the inner workings in
the
related core functions.

That might remove locking requirements from some of the callers and the
others still have their own thing around it.


For drivers having static/fixed cyclecounter, we can rely only on lock
inside timecounter.
Most of the network drivers update cyclecounter at runtime and they will
have to rely on two locks if
we add one to timecounter. This may not be efficient for them. Also the lock
in timecounter has to be less restrictive (may be seqlock) I guess.

Cc'd Mellanox list for inputs on this.

I have started feeling that the current approach of drivers managing the
locks is the right one so better leave the
lock out of timecounter.


I agree here,

In mlx5 we rely on our own read/write lock to serialize access to
mlx5_clock struct (mlx5 timecounter and cyclecounter).
the access is not as simple as
lock()
call time_counter_API
unlock()

Sometimes we also explicitly update/adjust timecycles counters with
mlx5 specific calculations after we read the timecounter all inside
our lock.
e.g.
@mlx5_ptp_adjfreq()

 write_lock_irqsave(>lock, flags);
 timecounter_read(>tc);
 clock->cycles.mult = neg_adj ? clock->nominal_c_mult - diff :
clock->nominal_c_mult + diff;
 write_unlock_irqrestore(>lock, flags);

So i don't think it will be a simple task to have a generic thread
safe timecounter API, without the need to specifically adjust it for
all driver use-cases.
Also as said above, in runtime it is not obvious in which context the
timecounter will be accessed irq/soft irq/user.

let's keep it as is, and let the driver decide which locking scheme is
most suitable for it.


Yes. Thanks for your inputs Saeed.

Regards
Sagar



Thanks,
Saeed.


Thanks,

 tglx


--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 2/2] DTS: Pandora: fix panel compatibility string

[H. Nikolaus Schaller]

We can remove the unnecessary "omapdss," prefix because
the omapdrm driver takes care of it when matching with
the driver table.

Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap3-pandora-common.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi 
b/arch/arm/boot/dts/omap3-pandora-common.dtsi
index 53e007abdc71..64d967ec8c58 100644
--- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
+++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
@@ -626,7 +626,7 @@
 
lcd: lcd@1 {
reg = <1>;  /* CS1 */
-   compatible ="omapdss,tpo,td043mtea1";
+   compatible ="tpo,td043mtea1";
spi-max-frequency = <10>;
spi-cpol;
spi-cpha;
-- 
2.12.2

[PATCH v4 2/2] DTS: Pandora: fix panel compatibility string

[H. Nikolaus Schaller]

We can remove the unnecessary "omapdss," prefix because
the omapdrm driver takes care of it when matching with
the driver table.

Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap3-pandora-common.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi 
b/arch/arm/boot/dts/omap3-pandora-common.dtsi
index 53e007abdc71..64d967ec8c58 100644
--- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
+++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
@@ -626,7 +626,7 @@
 
lcd: lcd@1 {
reg = <1>;  /* CS1 */
-   compatible ="omapdss,tpo,td043mtea1";
+   compatible ="tpo,td043mtea1";
spi-max-frequency = <10>;
spi-cpol;
spi-cpha;
-- 
2.12.2

[PATCH v4 0/2] Fixes for omapdrm on OpenPandora and GTA04

[H. Nikolaus Schaller]

Changes V4:
* removed already accepted panel driver patches
* reworded commit subject to clarify

2017-11-28 16:49:00: Changes V3:
* stay compatible with old DTB files which still use "toppoly" (suggested by 
Tomi Valkeinen)
* replaced MODULE_ALIAS entries by MODULE_DEVICE_TABLE (suggested by Andrew F. 
Davis)
* removed DSI VDDS patch as it has already been accepted

2017-11-16 09:50:22: Changes V2:
* replaced patch to fix DSI VDDS for OMAP3 by equivalent patch from Laurent 
Pinchart
* keep previous compatibility option in panel driver to handle older device 
tree binaries

2017-11-08 22:09:36:
This patch set fixes vendor names of the panels
and fixes a problem on omapdrm with enabling
VDD_DSI for OMAP3 which is needed for displaying
the Red and Green channel on OMAP3530 (Pandora).

H. Nikolaus Schaller (2):
  DTS: GTA04: improve panel compatibility string
  DTS: Pandora: fix panel compatibility string

 arch/arm/boot/dts/omap3-gta04.dtsi  | 2 +-
 arch/arm/boot/dts/omap3-pandora-common.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.12.2

[PATCH v4 0/2] Fixes for omapdrm on OpenPandora and GTA04

[H. Nikolaus Schaller]

Changes V4:
* removed already accepted panel driver patches
* reworded commit subject to clarify

2017-11-28 16:49:00: Changes V3:
* stay compatible with old DTB files which still use "toppoly" (suggested by 
Tomi Valkeinen)
* replaced MODULE_ALIAS entries by MODULE_DEVICE_TABLE (suggested by Andrew F. 
Davis)
* removed DSI VDDS patch as it has already been accepted

2017-11-16 09:50:22: Changes V2:
* replaced patch to fix DSI VDDS for OMAP3 by equivalent patch from Laurent 
Pinchart
* keep previous compatibility option in panel driver to handle older device 
tree binaries

2017-11-08 22:09:36:
This patch set fixes vendor names of the panels
and fixes a problem on omapdrm with enabling
VDD_DSI for OMAP3 which is needed for displaying
the Red and Green channel on OMAP3530 (Pandora).

H. Nikolaus Schaller (2):
  DTS: GTA04: improve panel compatibility string
  DTS: Pandora: fix panel compatibility string

 arch/arm/boot/dts/omap3-gta04.dtsi  | 2 +-
 arch/arm/boot/dts/omap3-pandora-common.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.12.2

Re: [PATCH v3 4/4] DTS: Pandora: fix panel compatibility string

[H. Nikolaus Schaller]

> Am 30.11.2017 um 16:24 schrieb Tony Lindgren :
> 
> * H. Nikolaus Schaller  [171128 18:35]:
>> Hi,
>> 
>>> Am 28.11.2017 um 17:18 schrieb Tony Lindgren :
>>> 
>>> * H. Nikolaus Schaller  [171128 16:17]:
 Hi Tony,
 
> Am 28.11.2017 um 17:04 schrieb Tony Lindgren :
> 
> * H. Nikolaus Schaller  [171128 15:52]:
>> We can remove the unnecessary "omapdss," prefix because
>> the omapdrm driver takes care of it when matching with
>> the driver table.
> 
> So is this needed as a fix or is this another clean-up?
> 
> So is this is really needed as a fix?
 
 Hm. How do you differentiate between "fix" and "cleanup"?
 Maybe it is more a wording than a content issue...
 
 For me it is a "fix" because it is semantically wrong to have
 a prefix where it is not needed. And "fixing" it changes the
 compiler output by 8 bytes.
>>> 
>>> How about let's call it a "typo fix" then? :)
>> 
>> Well, it is not really a typo.
> 
> Well what if the stable people pick it into earlier stable series
> based on the word fix in the subject? That has happened before.

Well, that may happen but IMHO *every* such backport must be checked
for reasonability and compatibility and sometimes even modified to apply.

And I think the author of the original patch receives a notification
from the stable maintainers and can then veto.

For Example I received "[PATCH 4.7 118/186] w1:omap_hdq: fix regression"
"4.7-stable review patch.  If anyone has any objections, please let me know."

If that process still fails, we simply have to revert it... Has also
happened before. So it will not be end of mankind :)

> 
> I suggest you update the dts patches to use wording like
> "update compatible to use new naming" or something similar.

I have applied s/fix/improve/ for patch 3/4 and left 4/4 as
suggested by Sebastian since it is really a strongly suggested
correction.

Since Tomi has already accepted the underlaying driver patch,
[PATCH v4] will only have the remaining DTS patches.

BR and thanks,
Nikolaus

Re: [PATCH v3 4/4] DTS: Pandora: fix panel compatibility string

[H. Nikolaus Schaller]

> Am 30.11.2017 um 16:24 schrieb Tony Lindgren :
> 
> * H. Nikolaus Schaller  [171128 18:35]:
>> Hi,
>> 
>>> Am 28.11.2017 um 17:18 schrieb Tony Lindgren :
>>> 
>>> * H. Nikolaus Schaller  [171128 16:17]:
 Hi Tony,
 
> Am 28.11.2017 um 17:04 schrieb Tony Lindgren :
> 
> * H. Nikolaus Schaller  [171128 15:52]:
>> We can remove the unnecessary "omapdss," prefix because
>> the omapdrm driver takes care of it when matching with
>> the driver table.
> 
> So is this needed as a fix or is this another clean-up?
> 
> So is this is really needed as a fix?
 
 Hm. How do you differentiate between "fix" and "cleanup"?
 Maybe it is more a wording than a content issue...
 
 For me it is a "fix" because it is semantically wrong to have
 a prefix where it is not needed. And "fixing" it changes the
 compiler output by 8 bytes.
>>> 
>>> How about let's call it a "typo fix" then? :)
>> 
>> Well, it is not really a typo.
> 
> Well what if the stable people pick it into earlier stable series
> based on the word fix in the subject? That has happened before.

Well, that may happen but IMHO *every* such backport must be checked
for reasonability and compatibility and sometimes even modified to apply.

And I think the author of the original patch receives a notification
from the stable maintainers and can then veto.

For Example I received "[PATCH 4.7 118/186] w1:omap_hdq: fix regression"
"4.7-stable review patch.  If anyone has any objections, please let me know."

If that process still fails, we simply have to revert it... Has also
happened before. So it will not be end of mankind :)

> 
> I suggest you update the dts patches to use wording like
> "update compatible to use new naming" or something similar.

I have applied s/fix/improve/ for patch 3/4 and left 4/4 as
suggested by Sebastian since it is really a strongly suggested
correction.

Since Tomi has already accepted the underlaying driver patch,
[PATCH v4] will only have the remaining DTS patches.

BR and thanks,
Nikolaus

Re: [PATCH 00/18] introduce a new tool, valid access checker

[Joonsoo Kim]

On Wed, Nov 29, 2017 at 10:27:00AM +0100, Dmitry Vyukov wrote:
> On Tue, Nov 28, 2017 at 8:48 AM,   wrote:
> > From: Joonsoo Kim 
> >
> > Hello,
> >
> > This patchset introduces a new tool, valid access checker.
> >
> > Vchecker is a dynamic memory error detector. It provides a new debug feature
> > that can find out an un-intended access to valid area. Valid area here means
> > the memory which is allocated and allowed to be accessed by memory owner and
> > un-intended access means the read/write that is initiated by non-owner.
> > Usual problem of this class is memory overwritten.
> >
> > Most of debug feature focused on finding out un-intended access to
> > in-valid area, for example, out-of-bound access and use-after-free, and,
> > there are many good tools for it. But, as far as I know, there is no good 
> > tool
> > to find out un-intended access to valid area. This kind of problem is really
> > hard to solve so this tool would be very useful.
> >
> > This tool doesn't automatically catch a problem. Manual runtime 
> > configuration
> > to specify the target object is required.
> >
> > Note that there was a similar attempt for the debugging overwritten problem
> > however it requires manual code modifying and recompile.
> >
> > http://lkml.kernel.org/r/<20171117223043.7277-1-wen.gang.w...@oracle.com>
> >
> > To get more information about vchecker, please see a documention at
> > the last patch.
> >
> > Patchset can also be available at
> >
> > https://github.com/JoonsooKim/linux/tree/vchecker-master-v1.0-next-20171122
> >
> > Enjoy it.
> 
> 
> Hi Joonsoo,
> 
> I skimmed through the code and this looks fine from KASAN point of
> view (minimal code changes and no perf impact).
> I don't feel like I can judge if this should go in or not. I will not
> use this, we use KASAN for large-scale testing, but vchecker is in a
> different bucket, it is meant for developers debugging hard bugs.
> Wengang come up with a very similar change, and Andi said that this
> looks useful.

Thanks for comment.

Hello, other reviewers!
Please let me know more opinions about this patchset.

> 
> If the decision is that this goes in, please let me take a closer look
> before this is merged.

I will let you know when the decision is made.

Thanks.

Re: [PATCH 00/18] introduce a new tool, valid access checker

[Joonsoo Kim]

On Wed, Nov 29, 2017 at 10:27:00AM +0100, Dmitry Vyukov wrote:
> On Tue, Nov 28, 2017 at 8:48 AM,   wrote:
> > From: Joonsoo Kim 
> >
> > Hello,
> >
> > This patchset introduces a new tool, valid access checker.
> >
> > Vchecker is a dynamic memory error detector. It provides a new debug feature
> > that can find out an un-intended access to valid area. Valid area here means
> > the memory which is allocated and allowed to be accessed by memory owner and
> > un-intended access means the read/write that is initiated by non-owner.
> > Usual problem of this class is memory overwritten.
> >
> > Most of debug feature focused on finding out un-intended access to
> > in-valid area, for example, out-of-bound access and use-after-free, and,
> > there are many good tools for it. But, as far as I know, there is no good 
> > tool
> > to find out un-intended access to valid area. This kind of problem is really
> > hard to solve so this tool would be very useful.
> >
> > This tool doesn't automatically catch a problem. Manual runtime 
> > configuration
> > to specify the target object is required.
> >
> > Note that there was a similar attempt for the debugging overwritten problem
> > however it requires manual code modifying and recompile.
> >
> > http://lkml.kernel.org/r/<20171117223043.7277-1-wen.gang.w...@oracle.com>
> >
> > To get more information about vchecker, please see a documention at
> > the last patch.
> >
> > Patchset can also be available at
> >
> > https://github.com/JoonsooKim/linux/tree/vchecker-master-v1.0-next-20171122
> >
> > Enjoy it.
> 
> 
> Hi Joonsoo,
> 
> I skimmed through the code and this looks fine from KASAN point of
> view (minimal code changes and no perf impact).
> I don't feel like I can judge if this should go in or not. I will not
> use this, we use KASAN for large-scale testing, but vchecker is in a
> different bucket, it is meant for developers debugging hard bugs.
> Wengang come up with a very similar change, and Andi said that this
> looks useful.

Thanks for comment.

Hello, other reviewers!
Please let me know more opinions about this patchset.

> 
> If the decision is that this goes in, please let me take a closer look
> before this is merged.

I will let you know when the decision is made.

Thanks.

a racy access flag clearing warning when calling mmap system call

[chenjiankang]

Hi will

   I find a warning by a syzkaller test;

   When the mmap syscall is called to create a virtual memory,
firstly it delete a old huge page mapping area;   
   Before splitting the huge page, the pmd of a huge page is set up.
But The PTE_AF is zreo belonging to the current pmd of huge page.
   I suspect that when the child process is created, the PTE_AF is cleared in 
copy_one_pte();
So, the set_pte_at() can have a warning.
   
   There, whether the set_pte_at() should detect PTE_AF?

Thanks.

The log:

set_pte_at: racy access flag clearing: 00e09d200bd1 -> 01e09d200bd1
[ cut here ]  
WARNING: at ../../../../../kernel/linux-4.1/arch/arm64/include/asm/pgtable.h:211
Modules linked in: 
CPU: 0 PID: 3665 Comm: syz-executor7 Not tainted 4.1.44+ #1
Hardware name: linux,dummy-virt (DT)   
task: ffc06a873fc0 ti: ffc05aefc000 task.ti: ffc05aefc000
PC is at pmdp_splitting_flush+0x194/0x1b0
LR is at pmdp_splitting_flush+0x194/0x1b0
pc : [] lr : [] pstate: 8145
sp : ffc05aeff770 
x29: ffc05aeff770 x28: ffc05ae45800 
x27: 2020 x26: ffc061fdf450 
x25: 0002 x24: 0001 
x23: ffc06333d9c8 x22: ffc0014ba000 
x21: 01e09d200bd1 x20: 00e09d200bd1 
x19: ffc05ae45800 x18:  
x17: 004b4000 x16: ffc00017fdc0 
x15: 038ee280 x14: 3030653130203e2d 
x13: 2031646230303264 x12: 3930303030306530 
x11: 30203a676e697261 x10: 656c632067616c66 
x9 : 2073736563636120 x8 : 79636172203a7461 
x7 : ffc05aeff430 x6 : ffc00015f38c 
x5 : 0003 x4 :  
x3 : 0003 x2 : 0001 
x1 : ff9005a03000 x0 : 004b 
Call trace:
[] pmdp_splitting_flush+0x194/0x1b0
[] split_huge_page_to_list+0x168/0xdb0
[] __split_huge_page_pmd+0x1b0/0x510
[] split_huge_page_pmd_mm+0x84/0x88
[] split_huge_page_address+0xc4/0xe8
[] __vma_adjust_trans_huge+0x15c/0x190
[] vma_adjust+0x884/0x9f0
[] __split_vma.isra.5+0x200/0x310
[] do_munmap+0x5e0/0x608 
[] mmap_region+0x12c/0x900
[] do_mmap_pgoff+0x484/0x540
[] vm_mmap_pgoff+0x128/0x158
[] SyS_mmap_pgoff+0x188/0x300
[] sys_mmap+0x58/0x80   

a racy access flag clearing warning when calling mmap system call

[chenjiankang]

Hi will

   I find a warning by a syzkaller test;

   When the mmap syscall is called to create a virtual memory,
firstly it delete a old huge page mapping area;   
   Before splitting the huge page, the pmd of a huge page is set up.
But The PTE_AF is zreo belonging to the current pmd of huge page.
   I suspect that when the child process is created, the PTE_AF is cleared in 
copy_one_pte();
So, the set_pte_at() can have a warning.
   
   There, whether the set_pte_at() should detect PTE_AF?

Thanks.

The log:

set_pte_at: racy access flag clearing: 00e09d200bd1 -> 01e09d200bd1
[ cut here ]  
WARNING: at ../../../../../kernel/linux-4.1/arch/arm64/include/asm/pgtable.h:211
Modules linked in: 
CPU: 0 PID: 3665 Comm: syz-executor7 Not tainted 4.1.44+ #1
Hardware name: linux,dummy-virt (DT)   
task: ffc06a873fc0 ti: ffc05aefc000 task.ti: ffc05aefc000
PC is at pmdp_splitting_flush+0x194/0x1b0
LR is at pmdp_splitting_flush+0x194/0x1b0
pc : [] lr : [] pstate: 8145
sp : ffc05aeff770 
x29: ffc05aeff770 x28: ffc05ae45800 
x27: 2020 x26: ffc061fdf450 
x25: 0002 x24: 0001 
x23: ffc06333d9c8 x22: ffc0014ba000 
x21: 01e09d200bd1 x20: 00e09d200bd1 
x19: ffc05ae45800 x18:  
x17: 004b4000 x16: ffc00017fdc0 
x15: 038ee280 x14: 3030653130203e2d 
x13: 2031646230303264 x12: 3930303030306530 
x11: 30203a676e697261 x10: 656c632067616c66 
x9 : 2073736563636120 x8 : 79636172203a7461 
x7 : ffc05aeff430 x6 : ffc00015f38c 
x5 : 0003 x4 :  
x3 : 0003 x2 : 0001 
x1 : ff9005a03000 x0 : 004b 
Call trace:
[] pmdp_splitting_flush+0x194/0x1b0
[] split_huge_page_to_list+0x168/0xdb0
[] __split_huge_page_pmd+0x1b0/0x510
[] split_huge_page_pmd_mm+0x84/0x88
[] split_huge_page_address+0xc4/0xe8
[] __vma_adjust_trans_huge+0x15c/0x190
[] vma_adjust+0x884/0x9f0
[] __split_vma.isra.5+0x200/0x310
[] do_munmap+0x5e0/0x608 
[] mmap_region+0x12c/0x900
[] do_mmap_pgoff+0x484/0x540
[] vm_mmap_pgoff+0x128/0x158
[] SyS_mmap_pgoff+0x188/0x300
[] sys_mmap+0x58/0x80   

Re: [Intel-gfx] [RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation

[Daniel Vetter]

On Fri, Dec 01, 2017 at 12:53:31PM +0530, Ramalingam C wrote:
> Sean,
> 
> IMHO, it will good if we can have all generic hdcp1.4 authentication flow in
> drm helpers and all interested display drivers to use them.
> 
> This Design will make the extending of hdcp easy for other display drivers
> based on DRM.
> 
> We can have the required drm_hdcp_shim type of implementation at drm
> structure which will be called for platform specific operations (like
> prepare an, send aksv, program bksv/repeater/r0 and verify sha1 etc)?

I discussed this exact question with Sean Paul, and apparently the
hardware designs are too diverse to make shared code much useful. Some hw
has the entire hdcp flow in hw, some almost nothing (like i915 here), and
then there's everything in between.

Given that Sean has seen a lot more hdcp implementations than we have,
that we right now have no other implementation than i915 in upstream and
than wrong abstraction is much harder to fix than no abstraction I'm going
with Sean's approach of "no generic abstraction" here. Personally I'm not
even fully sold on the shim abstraction, but I think by that one is
fine.

> On Thursday 30 November 2017 08:38 AM, Sean Paul wrote:
> > This patch adds the framework required to add HDCP support to intel
> > connectors. It implements Aksv loading from fuse, and parts 1/2/3
> > of the HDCP authentication scheme.
> > 
> > Note that without shim implementations, this does not actually implement
> > HDCP. That will come in subsequent patches.
> > 
> > Signed-off-by: Sean Paul 
> > ---
> >   drivers/gpu/drm/i915/Makefile   |   1 +
> >   drivers/gpu/drm/i915/i915_reg.h |  83 +
> >   drivers/gpu/drm/i915/intel_atomic.c |  26 +-
> >   drivers/gpu/drm/i915/intel_ddi.c|  14 +
> >   drivers/gpu/drm/i915/intel_drv.h|  53 +++
> >   drivers/gpu/drm/i915/intel_hdcp.c   | 636 
> > 
> >   6 files changed, 811 insertions(+), 2 deletions(-)
> >   create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c
> > 
> > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> > index 6c3b0481ef82..1e745508e437 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -87,6 +87,7 @@ i915-y += intel_audio.o \
> >   intel_fbc.o \
> >   intel_fifo_underrun.o \
> >   intel_frontbuffer.o \
> > + intel_hdcp.o \
> >   intel_hotplug.o \
> >   intel_modes.o \
> >   intel_overlay.o \
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 68a58cce6ab1..43128030171d 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -7991,6 +7991,7 @@ enum {
> >   #define GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT  8
> >   #define GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT  16
> >   #define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT  24
> > +#define   SKL_PCODE_LOAD_HDCP_KEYS 0x5
> >   #define   SKL_PCODE_CDCLK_CONTROL 0x7
> >   #define SKL_CDCLK_PREPARE_FOR_CHANGE  0x3
> >   #define SKL_CDCLK_READY_FOR_CHANGE0x1
> > @@ -8285,6 +8286,88 @@ enum skl_power_gate {
> >   #define  SKL_PW_TO_PG(pw) ((pw) - SKL_DISP_PW_1 + SKL_PG1)
> >   #define  SKL_FUSE_PG_DIST_STATUS(pg)  (1 << (27 - (pg)))
> > +
> > +/* HDCP Key Registers */
> > +#define SKL_HDCP_KEY_CONF  _MMIO(0x66c00)
> > +#define SKL_HDCP_AKSV_SEND_TRIGGER BIT(31)
> > +#define  SKL_HDCP_CLEAR_KEYS_TRIGGER   BIT(30)
> > +#define SKL_HDCP_KEY_STATUS_MMIO(0x66c04)
> > +#define  SKL_HDCP_FUSE_IN_PROGRESS BIT(7)
> > +#define  SKL_HDCP_FUSE_ERROR   BIT(6)
> > +#define  SKL_HDCP_FUSE_DONEBIT(5)
> > +#define  SKL_HDCP_KEY_LOAD_STATUS  BIT(1)
> > +#define  SKL_HDCP_KEY_LOAD_DONEBIT(0)
> > +#define SKL_HDCP_AKSV_LO   _MMIO(0x66c10)
> > +#define SKL_HDCP_AKSV_HI   _MMIO(0x66c14)
> > +
> > +/* HDCP Repeater Registers */
> > +#define SKL_HDCP_REP_CTL   _MMIO(0x66d00)
> > +#define  SKL_HDCP_DDIB_REP_PRESENT BIT(30)
> > +#define  SKL_HDCP_DDIA_REP_PRESENT BIT(29)
> > +#define  SKL_HDCP_DDIC_REP_PRESENT BIT(28)
> > +#define  SKL_HDCP_DDID_REP_PRESENT BIT(27)
> > +#define  SKL_HDCP_DDIF_REP_PRESENT BIT(26)
> > +#define  SKL_HDCP_DDIE_REP_PRESENT BIT(25)
> > +#define  SKL_HDCP_DDIB_SHA1_M0 (1 << 20)
> > +#define  SKL_HDCP_DDIA_SHA1_M0 (2 << 20)
> > +#define  SKL_HDCP_DDIC_SHA1_M0 (3 << 20)
> > +#define  SKL_HDCP_DDID_SHA1_M0 (4 << 20)
> > +#define  SKL_HDCP_DDIF_SHA1_M0 (5 << 20)
> > +#define  SKL_HDCP_DDIE_SHA1_M0 (6 << 20) // Bspec says 5?
> > +#define  SKL_HDCP_SHA1_BUSYBIT(16)
> > +#define  SKL_HDCP_SHA1_READY   BIT(17)
> > +#define  SKL_HDCP_SHA1_COMPLETEBIT(18)
> > +#define  SKL_HDCP_SHA1_V_MATCH BIT(19)
> > +#define  SKL_HDCP_SHA1_TEXT_32  

Re: [Intel-gfx] [RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation

[Daniel Vetter]

On Fri, Dec 01, 2017 at 12:53:31PM +0530, Ramalingam C wrote:
> Sean,
> 
> IMHO, it will good if we can have all generic hdcp1.4 authentication flow in
> drm helpers and all interested display drivers to use them.
> 
> This Design will make the extending of hdcp easy for other display drivers
> based on DRM.
> 
> We can have the required drm_hdcp_shim type of implementation at drm
> structure which will be called for platform specific operations (like
> prepare an, send aksv, program bksv/repeater/r0 and verify sha1 etc)?

I discussed this exact question with Sean Paul, and apparently the
hardware designs are too diverse to make shared code much useful. Some hw
has the entire hdcp flow in hw, some almost nothing (like i915 here), and
then there's everything in between.

Given that Sean has seen a lot more hdcp implementations than we have,
that we right now have no other implementation than i915 in upstream and
than wrong abstraction is much harder to fix than no abstraction I'm going
with Sean's approach of "no generic abstraction" here. Personally I'm not
even fully sold on the shim abstraction, but I think by that one is
fine.

> On Thursday 30 November 2017 08:38 AM, Sean Paul wrote:
> > This patch adds the framework required to add HDCP support to intel
> > connectors. It implements Aksv loading from fuse, and parts 1/2/3
> > of the HDCP authentication scheme.
> > 
> > Note that without shim implementations, this does not actually implement
> > HDCP. That will come in subsequent patches.
> > 
> > Signed-off-by: Sean Paul 
> > ---
> >   drivers/gpu/drm/i915/Makefile   |   1 +
> >   drivers/gpu/drm/i915/i915_reg.h |  83 +
> >   drivers/gpu/drm/i915/intel_atomic.c |  26 +-
> >   drivers/gpu/drm/i915/intel_ddi.c|  14 +
> >   drivers/gpu/drm/i915/intel_drv.h|  53 +++
> >   drivers/gpu/drm/i915/intel_hdcp.c   | 636 
> > 
> >   6 files changed, 811 insertions(+), 2 deletions(-)
> >   create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c
> > 
> > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> > index 6c3b0481ef82..1e745508e437 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -87,6 +87,7 @@ i915-y += intel_audio.o \
> >   intel_fbc.o \
> >   intel_fifo_underrun.o \
> >   intel_frontbuffer.o \
> > + intel_hdcp.o \
> >   intel_hotplug.o \
> >   intel_modes.o \
> >   intel_overlay.o \
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 68a58cce6ab1..43128030171d 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -7991,6 +7991,7 @@ enum {
> >   #define GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT  8
> >   #define GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT  16
> >   #define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT  24
> > +#define   SKL_PCODE_LOAD_HDCP_KEYS 0x5
> >   #define   SKL_PCODE_CDCLK_CONTROL 0x7
> >   #define SKL_CDCLK_PREPARE_FOR_CHANGE  0x3
> >   #define SKL_CDCLK_READY_FOR_CHANGE0x1
> > @@ -8285,6 +8286,88 @@ enum skl_power_gate {
> >   #define  SKL_PW_TO_PG(pw) ((pw) - SKL_DISP_PW_1 + SKL_PG1)
> >   #define  SKL_FUSE_PG_DIST_STATUS(pg)  (1 << (27 - (pg)))
> > +
> > +/* HDCP Key Registers */
> > +#define SKL_HDCP_KEY_CONF  _MMIO(0x66c00)
> > +#define SKL_HDCP_AKSV_SEND_TRIGGER BIT(31)
> > +#define  SKL_HDCP_CLEAR_KEYS_TRIGGER   BIT(30)
> > +#define SKL_HDCP_KEY_STATUS_MMIO(0x66c04)
> > +#define  SKL_HDCP_FUSE_IN_PROGRESS BIT(7)
> > +#define  SKL_HDCP_FUSE_ERROR   BIT(6)
> > +#define  SKL_HDCP_FUSE_DONEBIT(5)
> > +#define  SKL_HDCP_KEY_LOAD_STATUS  BIT(1)
> > +#define  SKL_HDCP_KEY_LOAD_DONEBIT(0)
> > +#define SKL_HDCP_AKSV_LO   _MMIO(0x66c10)
> > +#define SKL_HDCP_AKSV_HI   _MMIO(0x66c14)
> > +
> > +/* HDCP Repeater Registers */
> > +#define SKL_HDCP_REP_CTL   _MMIO(0x66d00)
> > +#define  SKL_HDCP_DDIB_REP_PRESENT BIT(30)
> > +#define  SKL_HDCP_DDIA_REP_PRESENT BIT(29)
> > +#define  SKL_HDCP_DDIC_REP_PRESENT BIT(28)
> > +#define  SKL_HDCP_DDID_REP_PRESENT BIT(27)
> > +#define  SKL_HDCP_DDIF_REP_PRESENT BIT(26)
> > +#define  SKL_HDCP_DDIE_REP_PRESENT BIT(25)
> > +#define  SKL_HDCP_DDIB_SHA1_M0 (1 << 20)
> > +#define  SKL_HDCP_DDIA_SHA1_M0 (2 << 20)
> > +#define  SKL_HDCP_DDIC_SHA1_M0 (3 << 20)
> > +#define  SKL_HDCP_DDID_SHA1_M0 (4 << 20)
> > +#define  SKL_HDCP_DDIF_SHA1_M0 (5 << 20)
> > +#define  SKL_HDCP_DDIE_SHA1_M0 (6 << 20) // Bspec says 5?
> > +#define  SKL_HDCP_SHA1_BUSYBIT(16)
> > +#define  SKL_HDCP_SHA1_READY   BIT(17)
> > +#define  SKL_HDCP_SHA1_COMPLETEBIT(18)
> > +#define  SKL_HDCP_SHA1_V_MATCH BIT(19)
> > +#define  SKL_HDCP_SHA1_TEXT_32 (1 << 1)
> > 

Re: [PATCH v4] f2fs: obsolete free nid list approach

[Jaegeuk Kim]

Hi Chao,

This is really hard to review and risky a lot to apply it shortly. Do we have a
strong reason we have to do this? The original design goal was to minimize
allocation delay which is almost zero for now. Of course, I agreed that there'd
be some trade-off though, we don't have a critical issue with this, FWIW.
Can we expect to see some speed gains with this? How much?

Thanks,

On 11/30, Chao Yu wrote:
> Previously, we use free nid list to manage free nid entry, so during nid
> allocation, we can just pick up one entry from list header, which has
> quite low overhead.
> 
> But sadly, during initialization of free nid list, we should do lookup
> combining with lots of different inner caches, including NAT page cache,
> nat entry cache, curseg journal cache and free nid bitmap, so flow became
> quite complicated.
> 
> In this patch, we choose to obsolete old free nid management approach,
> instead, we use existing free nid bitmap which has the same functionality
> to manage free nid, in order to make free nid management codes more easy
> to maintain.
> 
> Signed-off-by: Chao Yu 
> ---
> v4: clean up codes.
>  fs/f2fs/checkpoint.c |   1 -
>  fs/f2fs/debug.c  |   7 +-
>  fs/f2fs/f2fs.h   |   9 +-
>  fs/f2fs/inode.c  |   2 +
>  fs/f2fs/node.c   | 487 
> +--
>  fs/f2fs/node.h   |  22 ---
>  fs/f2fs/segment.c|   5 -
>  fs/f2fs/shrinker.c   |  14 --
>  8 files changed, 164 insertions(+), 383 deletions(-)
> 
> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
> index d1f160ae4959..885525a0d981 100644
> --- a/fs/f2fs/checkpoint.c
> +++ b/fs/f2fs/checkpoint.c
> @@ -1024,7 +1024,6 @@ static void __prepare_cp_block(struct f2fs_sb_info *sbi)
>   struct f2fs_nm_info *nm_i = NM_I(sbi);
>   nid_t last_nid = nm_i->next_scan_nid;
>  
> - next_free_nid(sbi, _nid);
>   ckpt->valid_block_count = cpu_to_le64(valid_user_blocks(sbi));
>   ckpt->valid_node_count = cpu_to_le32(valid_node_count(sbi));
>   ckpt->valid_inode_count = cpu_to_le32(valid_inode_count(sbi));
> diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
> index a66107b5cfff..413e031b10c4 100644
> --- a/fs/f2fs/debug.c
> +++ b/fs/f2fs/debug.c
> @@ -100,9 +100,8 @@ static void update_general_status(struct f2fs_sb_info 
> *sbi)
>   si->dirty_nats = NM_I(sbi)->dirty_nat_cnt;
>   si->sits = MAIN_SEGS(sbi);
>   si->dirty_sits = SIT_I(sbi)->dirty_sentries;
> - si->free_nids = NM_I(sbi)->nid_cnt[FREE_NID];
> + si->free_nids = NM_I(sbi)->available_free_nids;
>   si->avail_nids = NM_I(sbi)->available_nids;
> - si->alloc_nids = NM_I(sbi)->nid_cnt[PREALLOC_NID];
>   si->bg_gc = sbi->bg_gc;
>   si->util_free = (int)(free_user_blocks(sbi) >> sbi->log_blocks_per_seg)
>   * 100 / (int)(sbi->user_block_count >> sbi->log_blocks_per_seg)
> @@ -233,10 +232,6 @@ static void update_mem_info(struct f2fs_sb_info *sbi)
>   atomic_read(_I(sbi)->dcc_info->discard_cmd_cnt);
>   }
>  
> - /* free nids */
> - si->cache_mem += (NM_I(sbi)->nid_cnt[FREE_NID] +
> - NM_I(sbi)->nid_cnt[PREALLOC_NID]) *
> - sizeof(struct free_nid);
>   si->cache_mem += NM_I(sbi)->nat_cnt * sizeof(struct nat_entry);
>   si->cache_mem += NM_I(sbi)->dirty_nat_cnt *
>   sizeof(struct nat_entry_set);
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index d92eba66263c..f08e0feb38c1 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -723,14 +723,13 @@ struct f2fs_nm_info {
>   unsigned int nat_blocks;/* # of nat blocks */
>  
>   /* free node ids management */
> - struct radix_tree_root free_nid_root;/* root of the free_nid cache */
> - struct list_head free_nid_list; /* list for free nids excluding 
> preallocated nids */
> - unsigned int nid_cnt[MAX_NID_STATE];/* the number of free node id */
> - spinlock_t nid_list_lock;   /* protect nid lists ops */
> + spinlock_t free_nid_lock;   /* protect nid lists ops */
>   struct mutex build_lock;/* lock for build free nids */
>   unsigned char (*free_nid_bitmap)[NAT_ENTRY_BITMAP_SIZE];
> + unsigned char (*prealloc_nid_bitmap)[NAT_ENTRY_BITMAP_SIZE];
>   unsigned char *nat_block_bitmap;
>   unsigned short *free_nid_count; /* free nid count of NAT block */
> + unsigned int available_free_nids;   /* available free nid count in 
> bitmaps */
>  
>   /* for checkpoint */
>   char *nat_bitmap;   /* NAT bitmap pointer */
> @@ -2622,11 +2621,9 @@ int fsync_node_pages(struct f2fs_sb_info *sbi, struct 
> inode *inode,
>   struct writeback_control *wbc, bool atomic);
>  int sync_node_pages(struct f2fs_sb_info *sbi, struct writeback_control *wbc,
>   bool do_balance, enum iostat_type io_type);
> -void build_free_nids(struct f2fs_sb_info 

Re: [PATCH v4] f2fs: obsolete free nid list approach

[Jaegeuk Kim]

Hi Chao,

This is really hard to review and risky a lot to apply it shortly. Do we have a
strong reason we have to do this? The original design goal was to minimize
allocation delay which is almost zero for now. Of course, I agreed that there'd
be some trade-off though, we don't have a critical issue with this, FWIW.
Can we expect to see some speed gains with this? How much?

Thanks,

On 11/30, Chao Yu wrote:
> Previously, we use free nid list to manage free nid entry, so during nid
> allocation, we can just pick up one entry from list header, which has
> quite low overhead.
> 
> But sadly, during initialization of free nid list, we should do lookup
> combining with lots of different inner caches, including NAT page cache,
> nat entry cache, curseg journal cache and free nid bitmap, so flow became
> quite complicated.
> 
> In this patch, we choose to obsolete old free nid management approach,
> instead, we use existing free nid bitmap which has the same functionality
> to manage free nid, in order to make free nid management codes more easy
> to maintain.
> 
> Signed-off-by: Chao Yu 
> ---
> v4: clean up codes.
>  fs/f2fs/checkpoint.c |   1 -
>  fs/f2fs/debug.c  |   7 +-
>  fs/f2fs/f2fs.h   |   9 +-
>  fs/f2fs/inode.c  |   2 +
>  fs/f2fs/node.c   | 487 
> +--
>  fs/f2fs/node.h   |  22 ---
>  fs/f2fs/segment.c|   5 -
>  fs/f2fs/shrinker.c   |  14 --
>  8 files changed, 164 insertions(+), 383 deletions(-)
> 
> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
> index d1f160ae4959..885525a0d981 100644
> --- a/fs/f2fs/checkpoint.c
> +++ b/fs/f2fs/checkpoint.c
> @@ -1024,7 +1024,6 @@ static void __prepare_cp_block(struct f2fs_sb_info *sbi)
>   struct f2fs_nm_info *nm_i = NM_I(sbi);
>   nid_t last_nid = nm_i->next_scan_nid;
>  
> - next_free_nid(sbi, _nid);
>   ckpt->valid_block_count = cpu_to_le64(valid_user_blocks(sbi));
>   ckpt->valid_node_count = cpu_to_le32(valid_node_count(sbi));
>   ckpt->valid_inode_count = cpu_to_le32(valid_inode_count(sbi));
> diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
> index a66107b5cfff..413e031b10c4 100644
> --- a/fs/f2fs/debug.c
> +++ b/fs/f2fs/debug.c
> @@ -100,9 +100,8 @@ static void update_general_status(struct f2fs_sb_info 
> *sbi)
>   si->dirty_nats = NM_I(sbi)->dirty_nat_cnt;
>   si->sits = MAIN_SEGS(sbi);
>   si->dirty_sits = SIT_I(sbi)->dirty_sentries;
> - si->free_nids = NM_I(sbi)->nid_cnt[FREE_NID];
> + si->free_nids = NM_I(sbi)->available_free_nids;
>   si->avail_nids = NM_I(sbi)->available_nids;
> - si->alloc_nids = NM_I(sbi)->nid_cnt[PREALLOC_NID];
>   si->bg_gc = sbi->bg_gc;
>   si->util_free = (int)(free_user_blocks(sbi) >> sbi->log_blocks_per_seg)
>   * 100 / (int)(sbi->user_block_count >> sbi->log_blocks_per_seg)
> @@ -233,10 +232,6 @@ static void update_mem_info(struct f2fs_sb_info *sbi)
>   atomic_read(_I(sbi)->dcc_info->discard_cmd_cnt);
>   }
>  
> - /* free nids */
> - si->cache_mem += (NM_I(sbi)->nid_cnt[FREE_NID] +
> - NM_I(sbi)->nid_cnt[PREALLOC_NID]) *
> - sizeof(struct free_nid);
>   si->cache_mem += NM_I(sbi)->nat_cnt * sizeof(struct nat_entry);
>   si->cache_mem += NM_I(sbi)->dirty_nat_cnt *
>   sizeof(struct nat_entry_set);
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index d92eba66263c..f08e0feb38c1 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -723,14 +723,13 @@ struct f2fs_nm_info {
>   unsigned int nat_blocks;/* # of nat blocks */
>  
>   /* free node ids management */
> - struct radix_tree_root free_nid_root;/* root of the free_nid cache */
> - struct list_head free_nid_list; /* list for free nids excluding 
> preallocated nids */
> - unsigned int nid_cnt[MAX_NID_STATE];/* the number of free node id */
> - spinlock_t nid_list_lock;   /* protect nid lists ops */
> + spinlock_t free_nid_lock;   /* protect nid lists ops */
>   struct mutex build_lock;/* lock for build free nids */
>   unsigned char (*free_nid_bitmap)[NAT_ENTRY_BITMAP_SIZE];
> + unsigned char (*prealloc_nid_bitmap)[NAT_ENTRY_BITMAP_SIZE];
>   unsigned char *nat_block_bitmap;
>   unsigned short *free_nid_count; /* free nid count of NAT block */
> + unsigned int available_free_nids;   /* available free nid count in 
> bitmaps */
>  
>   /* for checkpoint */
>   char *nat_bitmap;   /* NAT bitmap pointer */
> @@ -2622,11 +2621,9 @@ int fsync_node_pages(struct f2fs_sb_info *sbi, struct 
> inode *inode,
>   struct writeback_control *wbc, bool atomic);
>  int sync_node_pages(struct f2fs_sb_info *sbi, struct writeback_control *wbc,
>   bool do_balance, enum iostat_type io_type);
> -void build_free_nids(struct f2fs_sb_info *sbi, bool sync, bool 

Re: [RFC PATCH 5/6] drm/i915: Implement HDCP for HDMI

[Ramalingam C]

Sean,

We might want to check the panel's HDCP capability? Agreed that majority 
of HDMI/DP panel's supports it, but there is a possibility that we might 
avoid authentication on non-hdcp panels.


As per HDCP specification, check for valid bksv will serve the purpose.


On Thursday 30 November 2017 08:39 AM, Sean Paul wrote:

This patch adds HDCP support for HDMI connectors by implementing
the intel_hdcp_shim.

Nothing too special, just a bunch of DDC reads/writes.

Signed-off-by: Sean Paul 
---
  drivers/gpu/drm/i915/i915_reg.h   |   1 +
  drivers/gpu/drm/i915/intel_ddi.c  |  50 
  drivers/gpu/drm/i915/intel_hdmi.c | 253 ++
  3 files changed, 304 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 78370877fea3..061c52a5d7d7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8400,6 +8400,7 @@ enum skl_power_gate {
  #define  TRANS_DDI_EDP_INPUT_A_ONOFF  (4<<12)
  #define  TRANS_DDI_EDP_INPUT_B_ONOFF  (5<<12)
  #define  TRANS_DDI_EDP_INPUT_C_ONOFF  (6<<12)
+#define  TRANS_DDI_HDCP_SIGNALLING (1<<9)
  #define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC(1<<8)
  #define  TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE (1<<7)
  #define  TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 0e69337f410d..0324b09ecf76 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1650,6 +1650,56 @@ void intel_ddi_disable_transcoder_func(struct 
drm_i915_private *dev_priv,
I915_WRITE(reg, val);
  }
  
+int intel_ddi_disable_hdcp_signalling(struct intel_encoder *intel_encoder)

+{
+   struct drm_device *dev = intel_encoder->base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   enum pipe pipe = 0;
+   int ret = 0;
+   uint32_t tmp;
+
+   if (!intel_display_power_get_if_enabled(dev_priv,
+   intel_encoder->power_domain))
+   return -ENXIO;
+
+   if (!intel_encoder->get_hw_state(intel_encoder, )) {
+   ret = -EIO;
+   goto out;
+   }
+
+   tmp = I915_READ(TRANS_DDI_FUNC_CTL(pipe));
+   tmp &= ~TRANS_DDI_HDCP_SIGNALLING;
+   I915_WRITE(TRANS_DDI_FUNC_CTL(pipe), tmp);
+out:
+   intel_display_power_put(dev_priv, intel_encoder->power_domain);
+   return ret;
+}
+
+int intel_ddi_enable_hdcp_signalling(struct intel_encoder *intel_encoder)
+{
+   struct drm_device *dev = intel_encoder->base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   enum pipe pipe = 0;
+   int ret = 0;
+   uint32_t tmp;
+
+   if (!intel_display_power_get_if_enabled(dev_priv,
+   intel_encoder->power_domain))
+   return -ENXIO;
+
+   if (!intel_encoder->get_hw_state(intel_encoder, )) {
+   ret = -EIO;
+   goto out;
+   }
+
+   tmp = I915_READ(TRANS_DDI_FUNC_CTL(pipe));
+   tmp |= TRANS_DDI_HDCP_SIGNALLING;
+   I915_WRITE(TRANS_DDI_FUNC_CTL(pipe), tmp);
+out:
+   intel_display_power_put(dev_priv, intel_encoder->power_domain);
+   return ret;
+}
+
  bool intel_ddi_connector_get_hw_state(struct intel_connector *intel_connector)
  {
struct drm_device *dev = intel_connector->base.dev;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 59247a49a077..563168897dd9 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -34,6 +34,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include "intel_drv.h"
  #include 
@@ -875,6 +876,252 @@ void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi 
*hdmi, bool enable)
 adapter, enable);
  }
  
+static int intel_hdmi_hdcp_read(struct intel_digital_port *intel_dig_port,

+   unsigned int offset, void *buffer, size_t size)
+{
+   struct intel_hdmi *hdmi = _dig_port->hdmi;
+   struct drm_i915_private *dev_priv =
+   intel_dig_port->base.base.dev->dev_private;
+   struct i2c_adapter *adapter = intel_gmbus_get_adapter(dev_priv,
+ hdmi->ddc_bus);
+   int ret;
+   u8 start = offset & 0xff;
+   struct i2c_msg msgs[] = {
+   {
+   .addr = DRM_HDCP_DDC_ADDR,
+   .flags = 0,
+   .len = 1,
+   .buf = ,
+   },
+   {
+   .addr = DRM_HDCP_DDC_ADDR,
+   .flags = I2C_M_RD,
+   .len = size,
+   .buf = buffer
+   }
+   };
+   ret = i2c_transfer(adapter, msgs, ARRAY_SIZE(msgs));
+   if (ret == ARRAY_SIZE(msgs))
+   return 

Re: [PATCH 1/2] x86/stacktrace: do not fail when regs on stack for ORC

[Jiri Slaby]

On 11/30/2017, 08:59 PM, Josh Poimboeuf wrote:
> On Thu, Nov 30, 2017 at 01:57:10PM -0600, Josh Poimboeuf wrote:
>> On Thu, Nov 30, 2017 at 09:03:24AM +0100, Jiri Slaby wrote:
>>> save_stack_trace_reliable now returns "non reliable" when there are
>>> kernel pt_regs on stack. This means an interrupt or exception happened.
>>> Somewhere down the route. It is a problem for frame pointer unwinder,
>>> because the frame might now have been set up yet when the irq happened,
>>> so it might fail to unwind from the interrupted function.
>>>
>>> With ORC, this is not a problem, as ORC has out-of-band data. We can
>>> find ORC data even for the IP in interrupted function and always unwind
>>> one level up.
>>>
>>> So introduce `unwind_regs_reliable' which decides if this is an issue
>>> for the currently selected unwinder at all and change the code
>>> accordingly.
>>
>> Thanks.  I'm thinking there a few ways we can simplify things.  (Most of
>> these are actually issues with the existing code.)
>>
>> - Currently we check to make sure that there's no frame *after* the user
>>   space regs.  I think there's no way that could ever happen and the
>>   check is overkill.
>>
>> - We should probably remove the STACKTRACE_DUMP_ONCE() warnings.  There
>>   are some known places where a stack trace will fail, particularly with
>>   generated code.  I wish we had a DEBUG_WARN_ON() macro which used
>>   pr_debug(), but oh well.  At least the livepatch code has some helpful
>>   pr_warn()s, those are probably good enough.
> ^^^
> meant to say pr_debug()s.
> 
> Also adding the live patching mailing list as an FYI.

The changes are now in:
https://git.kernel.org/pub/scm/linux/kernel/git/jirislaby/linux.git/log/?h=devel

Letting 01 bot to run through them, then I will send a v2.

thanks,
-- 
js
suse labs

Re: [RFC PATCH 5/6] drm/i915: Implement HDCP for HDMI

[Ramalingam C]

Sean,

We might want to check the panel's HDCP capability? Agreed that majority 
of HDMI/DP panel's supports it, but there is a possibility that we might 
avoid authentication on non-hdcp panels.


As per HDCP specification, check for valid bksv will serve the purpose.


On Thursday 30 November 2017 08:39 AM, Sean Paul wrote:

This patch adds HDCP support for HDMI connectors by implementing
the intel_hdcp_shim.

Nothing too special, just a bunch of DDC reads/writes.

Signed-off-by: Sean Paul 
---
  drivers/gpu/drm/i915/i915_reg.h   |   1 +
  drivers/gpu/drm/i915/intel_ddi.c  |  50 
  drivers/gpu/drm/i915/intel_hdmi.c | 253 ++
  3 files changed, 304 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 78370877fea3..061c52a5d7d7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8400,6 +8400,7 @@ enum skl_power_gate {
  #define  TRANS_DDI_EDP_INPUT_A_ONOFF  (4<<12)
  #define  TRANS_DDI_EDP_INPUT_B_ONOFF  (5<<12)
  #define  TRANS_DDI_EDP_INPUT_C_ONOFF  (6<<12)
+#define  TRANS_DDI_HDCP_SIGNALLING (1<<9)
  #define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC(1<<8)
  #define  TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE (1<<7)
  #define  TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 0e69337f410d..0324b09ecf76 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1650,6 +1650,56 @@ void intel_ddi_disable_transcoder_func(struct 
drm_i915_private *dev_priv,
I915_WRITE(reg, val);
  }
  
+int intel_ddi_disable_hdcp_signalling(struct intel_encoder *intel_encoder)

+{
+   struct drm_device *dev = intel_encoder->base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   enum pipe pipe = 0;
+   int ret = 0;
+   uint32_t tmp;
+
+   if (!intel_display_power_get_if_enabled(dev_priv,
+   intel_encoder->power_domain))
+   return -ENXIO;
+
+   if (!intel_encoder->get_hw_state(intel_encoder, )) {
+   ret = -EIO;
+   goto out;
+   }
+
+   tmp = I915_READ(TRANS_DDI_FUNC_CTL(pipe));
+   tmp &= ~TRANS_DDI_HDCP_SIGNALLING;
+   I915_WRITE(TRANS_DDI_FUNC_CTL(pipe), tmp);
+out:
+   intel_display_power_put(dev_priv, intel_encoder->power_domain);
+   return ret;
+}
+
+int intel_ddi_enable_hdcp_signalling(struct intel_encoder *intel_encoder)
+{
+   struct drm_device *dev = intel_encoder->base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   enum pipe pipe = 0;
+   int ret = 0;
+   uint32_t tmp;
+
+   if (!intel_display_power_get_if_enabled(dev_priv,
+   intel_encoder->power_domain))
+   return -ENXIO;
+
+   if (!intel_encoder->get_hw_state(intel_encoder, )) {
+   ret = -EIO;
+   goto out;
+   }
+
+   tmp = I915_READ(TRANS_DDI_FUNC_CTL(pipe));
+   tmp |= TRANS_DDI_HDCP_SIGNALLING;
+   I915_WRITE(TRANS_DDI_FUNC_CTL(pipe), tmp);
+out:
+   intel_display_power_put(dev_priv, intel_encoder->power_domain);
+   return ret;
+}
+
  bool intel_ddi_connector_get_hw_state(struct intel_connector *intel_connector)
  {
struct drm_device *dev = intel_connector->base.dev;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 59247a49a077..563168897dd9 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -34,6 +34,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include "intel_drv.h"
  #include 
@@ -875,6 +876,252 @@ void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi 
*hdmi, bool enable)
 adapter, enable);
  }
  
+static int intel_hdmi_hdcp_read(struct intel_digital_port *intel_dig_port,

+   unsigned int offset, void *buffer, size_t size)
+{
+   struct intel_hdmi *hdmi = _dig_port->hdmi;
+   struct drm_i915_private *dev_priv =
+   intel_dig_port->base.base.dev->dev_private;
+   struct i2c_adapter *adapter = intel_gmbus_get_adapter(dev_priv,
+ hdmi->ddc_bus);
+   int ret;
+   u8 start = offset & 0xff;
+   struct i2c_msg msgs[] = {
+   {
+   .addr = DRM_HDCP_DDC_ADDR,
+   .flags = 0,
+   .len = 1,
+   .buf = ,
+   },
+   {
+   .addr = DRM_HDCP_DDC_ADDR,
+   .flags = I2C_M_RD,
+   .len = size,
+   .buf = buffer
+   }
+   };
+   ret = i2c_transfer(adapter, msgs, ARRAY_SIZE(msgs));
+   if (ret == ARRAY_SIZE(msgs))
+   return 0;
+   return ret 

Re: [PATCH 1/2] x86/stacktrace: do not fail when regs on stack for ORC

[Jiri Slaby]

On 11/30/2017, 08:59 PM, Josh Poimboeuf wrote:
> On Thu, Nov 30, 2017 at 01:57:10PM -0600, Josh Poimboeuf wrote:
>> On Thu, Nov 30, 2017 at 09:03:24AM +0100, Jiri Slaby wrote:
>>> save_stack_trace_reliable now returns "non reliable" when there are
>>> kernel pt_regs on stack. This means an interrupt or exception happened.
>>> Somewhere down the route. It is a problem for frame pointer unwinder,
>>> because the frame might now have been set up yet when the irq happened,
>>> so it might fail to unwind from the interrupted function.
>>>
>>> With ORC, this is not a problem, as ORC has out-of-band data. We can
>>> find ORC data even for the IP in interrupted function and always unwind
>>> one level up.
>>>
>>> So introduce `unwind_regs_reliable' which decides if this is an issue
>>> for the currently selected unwinder at all and change the code
>>> accordingly.
>>
>> Thanks.  I'm thinking there a few ways we can simplify things.  (Most of
>> these are actually issues with the existing code.)
>>
>> - Currently we check to make sure that there's no frame *after* the user
>>   space regs.  I think there's no way that could ever happen and the
>>   check is overkill.
>>
>> - We should probably remove the STACKTRACE_DUMP_ONCE() warnings.  There
>>   are some known places where a stack trace will fail, particularly with
>>   generated code.  I wish we had a DEBUG_WARN_ON() macro which used
>>   pr_debug(), but oh well.  At least the livepatch code has some helpful
>>   pr_warn()s, those are probably good enough.
> ^^^
> meant to say pr_debug()s.
> 
> Also adding the live patching mailing list as an FYI.

The changes are now in:
https://git.kernel.org/pub/scm/linux/kernel/git/jirislaby/linux.git/log/?h=devel

Letting 01 bot to run through them, then I will send a v2.

thanks,
-- 
js
suse labs

Re: [PATCH 1/2] f2fs: pass down write hints to block layer for bufferd write

[Jaegeuk Kim]

On 11/30, Chao Yu wrote:
> On 2017/11/28 8:23, Hyunchul Lee wrote:
> > From: Hyunchul Lee 
> > 
> > This implements which hint is passed down to block layer
> > for datas from the specific segment type.
> > 
> > segment type hints
> >  -
> > COLD_NODE & COLD_DATAWRITE_LIFE_EXTREME
> > WARM_DATAWRITE_LIFE_NONE
> > HOT_NODE & WARM_NODE WRITE_LIFE_LONG
> > HOT_DATA WRITE_LIFE_MEDIUM
> > META_DATAWRITE_LIFE_SHORT
> 
> The correspondence looks good to me.

Still, I don't fully get the point. Why do we have to assign WRITE_LIFE_NONE
to WARM_DATA? Why not using WRITE_LIFE_NOT_SET?

> > 
> > Many thanks to Chao Yu and Jaegeuk Kim for comments to
> > implement this patch.
> > 
> > Signed-off-by: Hyunchul Lee 
> > ---
> >  fs/f2fs/data.c|  1 +
> >  fs/f2fs/f2fs.h|  2 ++
> >  fs/f2fs/segment.c | 29 +
> >  fs/f2fs/super.c   |  2 ++
> >  4 files changed, 34 insertions(+)
> > 
> > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> > index a7ae418..0919a43 100644
> > --- a/fs/f2fs/data.c
> > +++ b/fs/f2fs/data.c
> > @@ -437,6 +437,7 @@ int f2fs_submit_page_write(struct f2fs_io_info *fio)
> > }
> > io->bio = __bio_alloc(sbi, fio->new_blkaddr,
> > BIO_MAX_PAGES, false);
> > +   io->bio->bi_write_hint = io->write_hint;
> 
> Need to assign bi_write_hint for IPU path?
> 
> - rewrite_data_page
>  - f2fs_submit_page_bio
> 
> > io->fio = *fio;
> > }
> >  
> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > index 7bcd148..be3cb0c 100644
> > --- a/fs/f2fs/f2fs.h
> > +++ b/fs/f2fs/f2fs.h
> > @@ -969,6 +969,7 @@ struct f2fs_bio_info {
> > struct rw_semaphore io_rwsem;   /* blocking op for bio */
> > spinlock_t io_lock; /* serialize DATA/NODE IOs */
> > struct list_head io_list;   /* track fios */
> > +   enum rw_hint write_hint;
> 
> Add missing comment?
> 
> >  };
> >  
> >  #define FDEV(i)(sbi->devs[i])
> > @@ -2674,6 +2675,7 @@ int lookup_journal_in_cursum(struct f2fs_journal 
> > *journal, int type,
> >  int __init create_segment_manager_caches(void);
> >  void destroy_segment_manager_caches(void);
> >  int rw_hint_to_seg_type(enum rw_hint hint);
> > +enum rw_hint io_type_to_rw_hint(enum page_type page, enum temp_type temp);
> >  
> >  /*
> >   * checkpoint.c
> > diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> > index c117e09..0570db7 100644
> > --- a/fs/f2fs/segment.c
> > +++ b/fs/f2fs/segment.c
> > @@ -2446,6 +2446,35 @@ int rw_hint_to_seg_type(enum rw_hint hint)
> > }
> >  }
> >  
> 
> It will be better to copy commit log here to declare correspondence
> more clearly.
> 
> Thanks,
> 
> > +enum rw_hint io_type_to_rw_hint(enum page_type page, enum temp_type temp)
> > +{
> > +   if (page == DATA) {
> > +   switch (temp) {
> > +   case WARM:
> > +   return WRITE_LIFE_NONE;
> > +   case COLD:
> > +   return WRITE_LIFE_EXTREME;
> > +   case HOT:
> > +   return WRITE_LIFE_MEDIUM;
> > +   default:
> > +   return WRITE_LIFE_NOT_SET;
> > +   }
> > +   } else if (page == NODE) {
> > +   switch (temp) {
> > +   case WARM:
> > +   case HOT:
> > +   return WRITE_LIFE_LONG;
> > +   case COLD:
> > +   return WRITE_LIFE_EXTREME;
> > +   default:
> > +   return WRITE_LIFE_NOT_SET;
> > +   }
> > +
> > +   } else {
> > +   return WRITE_LIFE_SHORT;
> > +   }
> > +}
> > +
> >  static int __get_segment_type_2(struct f2fs_io_info *fio)
> >  {
> > if (fio->type == DATA)
> > diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> > index a6c5dd4..51c19a0 100644
> > --- a/fs/f2fs/super.c
> > +++ b/fs/f2fs/super.c
> > @@ -2508,6 +2508,8 @@ static int f2fs_fill_super(struct super_block *sb, 
> > void *data, int silent)
> > sbi->write_io[i][j].bio = NULL;
> > spin_lock_init(>write_io[i][j].io_lock);
> > INIT_LIST_HEAD(>write_io[i][j].io_list);
> > +   sbi->write_io[i][j].write_hint =
> > +   io_type_to_rw_hint(i, j);
> > }
> > }
> >  
> > 

Re: [PATCH 1/2] f2fs: pass down write hints to block layer for bufferd write

[Jaegeuk Kim]

On 11/30, Chao Yu wrote:
> On 2017/11/28 8:23, Hyunchul Lee wrote:
> > From: Hyunchul Lee 
> > 
> > This implements which hint is passed down to block layer
> > for datas from the specific segment type.
> > 
> > segment type hints
> >  -
> > COLD_NODE & COLD_DATAWRITE_LIFE_EXTREME
> > WARM_DATAWRITE_LIFE_NONE
> > HOT_NODE & WARM_NODE WRITE_LIFE_LONG
> > HOT_DATA WRITE_LIFE_MEDIUM
> > META_DATAWRITE_LIFE_SHORT
> 
> The correspondence looks good to me.

Still, I don't fully get the point. Why do we have to assign WRITE_LIFE_NONE
to WARM_DATA? Why not using WRITE_LIFE_NOT_SET?

> > 
> > Many thanks to Chao Yu and Jaegeuk Kim for comments to
> > implement this patch.
> > 
> > Signed-off-by: Hyunchul Lee 
> > ---
> >  fs/f2fs/data.c|  1 +
> >  fs/f2fs/f2fs.h|  2 ++
> >  fs/f2fs/segment.c | 29 +
> >  fs/f2fs/super.c   |  2 ++
> >  4 files changed, 34 insertions(+)
> > 
> > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> > index a7ae418..0919a43 100644
> > --- a/fs/f2fs/data.c
> > +++ b/fs/f2fs/data.c
> > @@ -437,6 +437,7 @@ int f2fs_submit_page_write(struct f2fs_io_info *fio)
> > }
> > io->bio = __bio_alloc(sbi, fio->new_blkaddr,
> > BIO_MAX_PAGES, false);
> > +   io->bio->bi_write_hint = io->write_hint;
> 
> Need to assign bi_write_hint for IPU path?
> 
> - rewrite_data_page
>  - f2fs_submit_page_bio
> 
> > io->fio = *fio;
> > }
> >  
> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > index 7bcd148..be3cb0c 100644
> > --- a/fs/f2fs/f2fs.h
> > +++ b/fs/f2fs/f2fs.h
> > @@ -969,6 +969,7 @@ struct f2fs_bio_info {
> > struct rw_semaphore io_rwsem;   /* blocking op for bio */
> > spinlock_t io_lock; /* serialize DATA/NODE IOs */
> > struct list_head io_list;   /* track fios */
> > +   enum rw_hint write_hint;
> 
> Add missing comment?
> 
> >  };
> >  
> >  #define FDEV(i)(sbi->devs[i])
> > @@ -2674,6 +2675,7 @@ int lookup_journal_in_cursum(struct f2fs_journal 
> > *journal, int type,
> >  int __init create_segment_manager_caches(void);
> >  void destroy_segment_manager_caches(void);
> >  int rw_hint_to_seg_type(enum rw_hint hint);
> > +enum rw_hint io_type_to_rw_hint(enum page_type page, enum temp_type temp);
> >  
> >  /*
> >   * checkpoint.c
> > diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> > index c117e09..0570db7 100644
> > --- a/fs/f2fs/segment.c
> > +++ b/fs/f2fs/segment.c
> > @@ -2446,6 +2446,35 @@ int rw_hint_to_seg_type(enum rw_hint hint)
> > }
> >  }
> >  
> 
> It will be better to copy commit log here to declare correspondence
> more clearly.
> 
> Thanks,
> 
> > +enum rw_hint io_type_to_rw_hint(enum page_type page, enum temp_type temp)
> > +{
> > +   if (page == DATA) {
> > +   switch (temp) {
> > +   case WARM:
> > +   return WRITE_LIFE_NONE;
> > +   case COLD:
> > +   return WRITE_LIFE_EXTREME;
> > +   case HOT:
> > +   return WRITE_LIFE_MEDIUM;
> > +   default:
> > +   return WRITE_LIFE_NOT_SET;
> > +   }
> > +   } else if (page == NODE) {
> > +   switch (temp) {
> > +   case WARM:
> > +   case HOT:
> > +   return WRITE_LIFE_LONG;
> > +   case COLD:
> > +   return WRITE_LIFE_EXTREME;
> > +   default:
> > +   return WRITE_LIFE_NOT_SET;
> > +   }
> > +
> > +   } else {
> > +   return WRITE_LIFE_SHORT;
> > +   }
> > +}
> > +
> >  static int __get_segment_type_2(struct f2fs_io_info *fio)
> >  {
> > if (fio->type == DATA)
> > diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> > index a6c5dd4..51c19a0 100644
> > --- a/fs/f2fs/super.c
> > +++ b/fs/f2fs/super.c
> > @@ -2508,6 +2508,8 @@ static int f2fs_fill_super(struct super_block *sb, 
> > void *data, int silent)
> > sbi->write_io[i][j].bio = NULL;
> > spin_lock_init(>write_io[i][j].io_lock);
> > INIT_LIST_HEAD(>write_io[i][j].io_list);
> > +   sbi->write_io[i][j].write_hint =
> > +   io_type_to_rw_hint(i, j);
> > }
> > }
> >  
> > 

Re: KASAN: stack-out-of-bounds Read in xfrm_state_find (3)

[Steffen Klassert]

On Wed, Nov 22, 2017 at 08:05:00AM -0800, syzbot wrote:
> syzkaller has found reproducer for the following crash on
> 0c86a6bd85ff0629cd2c5141027fc1c8bb6cde9c
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> BUG: KASAN: stack-out-of-bounds in xfrm_state_find+0x30fc/0x3230
> net/xfrm/xfrm_state.c:1051
> Read of size 4 at addr 8801ccaa7af8 by task syzkaller231684/3045

The patch below should fix this. I plan to apply it to the ipsec tree
after some advanced testing.

Subject: [PATCH RFC] xfrm: Fix stack-out-of-bounds with misconfigured transport
 mode policies.

On policies with a transport mode template, we pass the addresses
from the flowi to xfrm_state_find(), assuming that the IP addresses
(and address family) don't change during transformation.

Unfortunately our policy template validation is not strict enough.
It is possible to configure policies with transport mode template
where the address family of the template does not match the selectors
address family. This lead to stack-out-of-bound reads because
we compare arddesses of the wrong family. Fix this by refusing
such a configuration, address family can not change on transport
mode.

We use the assumption that, on transport mode, the first templates
address family must match the address family of the policy selector.
Subsequent transport mode templates must mach the address family of
the previous template.

Reported-by: syzbot 
Signed-off-by: Steffen Klassert 
---
 net/xfrm/xfrm_user.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index 983b0233767b..57ad016ae675 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -1419,11 +1419,14 @@ static void copy_templates(struct xfrm_policy *xp, 
struct xfrm_user_tmpl *ut,
 
 static int validate_tmpl(int nr, struct xfrm_user_tmpl *ut, u16 family)
 {
+   u16 prev_family;
int i;
 
if (nr > XFRM_MAX_DEPTH)
return -EINVAL;
 
+   prev_family = family;
+
for (i = 0; i < nr; i++) {
/* We never validated the ut->family value, so many
 * applications simply leave it at zero.  The check was
@@ -1435,6 +1438,12 @@ static int validate_tmpl(int nr, struct xfrm_user_tmpl 
*ut, u16 family)
if (!ut[i].family)
ut[i].family = family;
 
+   if ((ut[i].mode == XFRM_MODE_TRANSPORT) &&
+   (ut[i].family != prev_family))
+   return -EINVAL;
+
+   prev_family = ut[i].family;
+
switch (ut[i].family) {
case AF_INET:
break;
-- 
2.14.1

Re: [RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation

[Ramalingam C]

Sean,

IMHO, it will good if we can have all generic hdcp1.4 authentication 
flow in drm helpers and all interested display drivers to use them.


This Design will make the extending of hdcp easy for other display 
drivers based on DRM.


We can have the required drm_hdcp_shim type of implementation at drm 
structure which will be called for platform specific operations (like 
prepare an, send aksv, program bksv/repeater/r0 and verify sha1 etc)?



On Thursday 30 November 2017 08:38 AM, Sean Paul wrote:

This patch adds the framework required to add HDCP support to intel
connectors. It implements Aksv loading from fuse, and parts 1/2/3
of the HDCP authentication scheme.

Note that without shim implementations, this does not actually implement
HDCP. That will come in subsequent patches.

Signed-off-by: Sean Paul 
---
  drivers/gpu/drm/i915/Makefile   |   1 +
  drivers/gpu/drm/i915/i915_reg.h |  83 +
  drivers/gpu/drm/i915/intel_atomic.c |  26 +-
  drivers/gpu/drm/i915/intel_ddi.c|  14 +
  drivers/gpu/drm/i915/intel_drv.h|  53 +++
  drivers/gpu/drm/i915/intel_hdcp.c   | 636 
  6 files changed, 811 insertions(+), 2 deletions(-)
  create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 6c3b0481ef82..1e745508e437 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -87,6 +87,7 @@ i915-y += intel_audio.o \
  intel_fbc.o \
  intel_fifo_underrun.o \
  intel_frontbuffer.o \
+ intel_hdcp.o \
  intel_hotplug.o \
  intel_modes.o \
  intel_overlay.o \
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 68a58cce6ab1..43128030171d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7991,6 +7991,7 @@ enum {
  #define GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT  8
  #define GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT  16
  #define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT  24
+#define   SKL_PCODE_LOAD_HDCP_KEYS 0x5
  #define   SKL_PCODE_CDCLK_CONTROL 0x7
  #define SKL_CDCLK_PREPARE_FOR_CHANGE  0x3
  #define SKL_CDCLK_READY_FOR_CHANGE0x1
@@ -8285,6 +8286,88 @@ enum skl_power_gate {
  #define  SKL_PW_TO_PG(pw) ((pw) - SKL_DISP_PW_1 + SKL_PG1)
  #define  SKL_FUSE_PG_DIST_STATUS(pg)  (1 << (27 - (pg)))
  
+

+/* HDCP Key Registers */
+#define SKL_HDCP_KEY_CONF  _MMIO(0x66c00)
+#define SKL_HDCP_AKSV_SEND_TRIGGER BIT(31)
+#define  SKL_HDCP_CLEAR_KEYS_TRIGGER   BIT(30)
+#define SKL_HDCP_KEY_STATUS_MMIO(0x66c04)
+#define  SKL_HDCP_FUSE_IN_PROGRESS BIT(7)
+#define  SKL_HDCP_FUSE_ERROR   BIT(6)
+#define  SKL_HDCP_FUSE_DONEBIT(5)
+#define  SKL_HDCP_KEY_LOAD_STATUS  BIT(1)
+#define  SKL_HDCP_KEY_LOAD_DONEBIT(0)
+#define SKL_HDCP_AKSV_LO   _MMIO(0x66c10)
+#define SKL_HDCP_AKSV_HI   _MMIO(0x66c14)
+
+/* HDCP Repeater Registers */
+#define SKL_HDCP_REP_CTL   _MMIO(0x66d00)
+#define  SKL_HDCP_DDIB_REP_PRESENT BIT(30)
+#define  SKL_HDCP_DDIA_REP_PRESENT BIT(29)
+#define  SKL_HDCP_DDIC_REP_PRESENT BIT(28)
+#define  SKL_HDCP_DDID_REP_PRESENT BIT(27)
+#define  SKL_HDCP_DDIF_REP_PRESENT BIT(26)
+#define  SKL_HDCP_DDIE_REP_PRESENT BIT(25)
+#define  SKL_HDCP_DDIB_SHA1_M0 (1 << 20)
+#define  SKL_HDCP_DDIA_SHA1_M0 (2 << 20)
+#define  SKL_HDCP_DDIC_SHA1_M0 (3 << 20)
+#define  SKL_HDCP_DDID_SHA1_M0 (4 << 20)
+#define  SKL_HDCP_DDIF_SHA1_M0 (5 << 20)
+#define  SKL_HDCP_DDIE_SHA1_M0 (6 << 20) // Bspec says 5?
+#define  SKL_HDCP_SHA1_BUSYBIT(16)
+#define  SKL_HDCP_SHA1_READY   BIT(17)
+#define  SKL_HDCP_SHA1_COMPLETEBIT(18)
+#define  SKL_HDCP_SHA1_V_MATCH BIT(19)
+#define  SKL_HDCP_SHA1_TEXT_32 (1 << 1)
+#define  SKL_HDCP_SHA1_COMPLETE_HASH   (2 << 1)
+#define  SKL_HDCP_SHA1_TEXT_24 (4 << 1)
+#define  SKL_HDCP_SHA1_TEXT_16 (5 << 1)
+#define  SKL_HDCP_SHA1_TEXT_8  (6 << 1)
+#define  SKL_HDCP_SHA1_TEXT_0  (7 << 1)
+#define SKL_HDCP_SHA_V_PRIME_H0_MMIO(0x66d04)
+#define SKL_HDCP_SHA_V_PRIME_H1_MMIO(0x66d08)
+#define SKL_HDCP_SHA_V_PRIME_H2_MMIO(0x66d0C)
+#define SKL_HDCP_SHA_V_PRIME_H3_MMIO(0x66d10)
+#define SKL_HDCP_SHA_V_PRIME_H4_MMIO(0x66d14)
+#define SKL_HDCP_SHA_V_PRIME(h)_MMIO((0x66d04 + h * 4))
+#define SKL_HDCP_SHA_TEXT  _MMIO(0x66d18)
+
+/* HDCP Auth Registers */
+#define _SKL_PORTA_HDCP_AUTHENC0x66800
+#define _SKL_PORTB_HDCP_AUTHENC0x66500
+#define _SKL_PORTC_HDCP_AUTHENC0x66600
+#define _SKL_PORTD_HDCP_AUTHENC0x66700
+#define 

Re: KASAN: stack-out-of-bounds Read in xfrm_state_find (3)

[Steffen Klassert]

On Wed, Nov 22, 2017 at 08:05:00AM -0800, syzbot wrote:
> syzkaller has found reproducer for the following crash on
> 0c86a6bd85ff0629cd2c5141027fc1c8bb6cde9c
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> BUG: KASAN: stack-out-of-bounds in xfrm_state_find+0x30fc/0x3230
> net/xfrm/xfrm_state.c:1051
> Read of size 4 at addr 8801ccaa7af8 by task syzkaller231684/3045

The patch below should fix this. I plan to apply it to the ipsec tree
after some advanced testing.

Subject: [PATCH RFC] xfrm: Fix stack-out-of-bounds with misconfigured transport
 mode policies.

On policies with a transport mode template, we pass the addresses
from the flowi to xfrm_state_find(), assuming that the IP addresses
(and address family) don't change during transformation.

Unfortunately our policy template validation is not strict enough.
It is possible to configure policies with transport mode template
where the address family of the template does not match the selectors
address family. This lead to stack-out-of-bound reads because
we compare arddesses of the wrong family. Fix this by refusing
such a configuration, address family can not change on transport
mode.

We use the assumption that, on transport mode, the first templates
address family must match the address family of the policy selector.
Subsequent transport mode templates must mach the address family of
the previous template.

Reported-by: syzbot 
Signed-off-by: Steffen Klassert 
---
 net/xfrm/xfrm_user.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index 983b0233767b..57ad016ae675 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -1419,11 +1419,14 @@ static void copy_templates(struct xfrm_policy *xp, 
struct xfrm_user_tmpl *ut,
 
 static int validate_tmpl(int nr, struct xfrm_user_tmpl *ut, u16 family)
 {
+   u16 prev_family;
int i;
 
if (nr > XFRM_MAX_DEPTH)
return -EINVAL;
 
+   prev_family = family;
+
for (i = 0; i < nr; i++) {
/* We never validated the ut->family value, so many
 * applications simply leave it at zero.  The check was
@@ -1435,6 +1438,12 @@ static int validate_tmpl(int nr, struct xfrm_user_tmpl 
*ut, u16 family)
if (!ut[i].family)
ut[i].family = family;
 
+   if ((ut[i].mode == XFRM_MODE_TRANSPORT) &&
+   (ut[i].family != prev_family))
+   return -EINVAL;
+
+   prev_family = ut[i].family;
+
switch (ut[i].family) {
case AF_INET:
break;
-- 
2.14.1

Re: [RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation

[Ramalingam C]

Sean,

IMHO, it will good if we can have all generic hdcp1.4 authentication 
flow in drm helpers and all interested display drivers to use them.


This Design will make the extending of hdcp easy for other display 
drivers based on DRM.


We can have the required drm_hdcp_shim type of implementation at drm 
structure which will be called for platform specific operations (like 
prepare an, send aksv, program bksv/repeater/r0 and verify sha1 etc)?



On Thursday 30 November 2017 08:38 AM, Sean Paul wrote:

This patch adds the framework required to add HDCP support to intel
connectors. It implements Aksv loading from fuse, and parts 1/2/3
of the HDCP authentication scheme.

Note that without shim implementations, this does not actually implement
HDCP. That will come in subsequent patches.

Signed-off-by: Sean Paul 
---
  drivers/gpu/drm/i915/Makefile   |   1 +
  drivers/gpu/drm/i915/i915_reg.h |  83 +
  drivers/gpu/drm/i915/intel_atomic.c |  26 +-
  drivers/gpu/drm/i915/intel_ddi.c|  14 +
  drivers/gpu/drm/i915/intel_drv.h|  53 +++
  drivers/gpu/drm/i915/intel_hdcp.c   | 636 
  6 files changed, 811 insertions(+), 2 deletions(-)
  create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 6c3b0481ef82..1e745508e437 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -87,6 +87,7 @@ i915-y += intel_audio.o \
  intel_fbc.o \
  intel_fifo_underrun.o \
  intel_frontbuffer.o \
+ intel_hdcp.o \
  intel_hotplug.o \
  intel_modes.o \
  intel_overlay.o \
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 68a58cce6ab1..43128030171d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7991,6 +7991,7 @@ enum {
  #define GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT  8
  #define GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT  16
  #define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT  24
+#define   SKL_PCODE_LOAD_HDCP_KEYS 0x5
  #define   SKL_PCODE_CDCLK_CONTROL 0x7
  #define SKL_CDCLK_PREPARE_FOR_CHANGE  0x3
  #define SKL_CDCLK_READY_FOR_CHANGE0x1
@@ -8285,6 +8286,88 @@ enum skl_power_gate {
  #define  SKL_PW_TO_PG(pw) ((pw) - SKL_DISP_PW_1 + SKL_PG1)
  #define  SKL_FUSE_PG_DIST_STATUS(pg)  (1 << (27 - (pg)))
  
+

+/* HDCP Key Registers */
+#define SKL_HDCP_KEY_CONF  _MMIO(0x66c00)
+#define SKL_HDCP_AKSV_SEND_TRIGGER BIT(31)
+#define  SKL_HDCP_CLEAR_KEYS_TRIGGER   BIT(30)
+#define SKL_HDCP_KEY_STATUS_MMIO(0x66c04)
+#define  SKL_HDCP_FUSE_IN_PROGRESS BIT(7)
+#define  SKL_HDCP_FUSE_ERROR   BIT(6)
+#define  SKL_HDCP_FUSE_DONEBIT(5)
+#define  SKL_HDCP_KEY_LOAD_STATUS  BIT(1)
+#define  SKL_HDCP_KEY_LOAD_DONEBIT(0)
+#define SKL_HDCP_AKSV_LO   _MMIO(0x66c10)
+#define SKL_HDCP_AKSV_HI   _MMIO(0x66c14)
+
+/* HDCP Repeater Registers */
+#define SKL_HDCP_REP_CTL   _MMIO(0x66d00)
+#define  SKL_HDCP_DDIB_REP_PRESENT BIT(30)
+#define  SKL_HDCP_DDIA_REP_PRESENT BIT(29)
+#define  SKL_HDCP_DDIC_REP_PRESENT BIT(28)
+#define  SKL_HDCP_DDID_REP_PRESENT BIT(27)
+#define  SKL_HDCP_DDIF_REP_PRESENT BIT(26)
+#define  SKL_HDCP_DDIE_REP_PRESENT BIT(25)
+#define  SKL_HDCP_DDIB_SHA1_M0 (1 << 20)
+#define  SKL_HDCP_DDIA_SHA1_M0 (2 << 20)
+#define  SKL_HDCP_DDIC_SHA1_M0 (3 << 20)
+#define  SKL_HDCP_DDID_SHA1_M0 (4 << 20)
+#define  SKL_HDCP_DDIF_SHA1_M0 (5 << 20)
+#define  SKL_HDCP_DDIE_SHA1_M0 (6 << 20) // Bspec says 5?
+#define  SKL_HDCP_SHA1_BUSYBIT(16)
+#define  SKL_HDCP_SHA1_READY   BIT(17)
+#define  SKL_HDCP_SHA1_COMPLETEBIT(18)
+#define  SKL_HDCP_SHA1_V_MATCH BIT(19)
+#define  SKL_HDCP_SHA1_TEXT_32 (1 << 1)
+#define  SKL_HDCP_SHA1_COMPLETE_HASH   (2 << 1)
+#define  SKL_HDCP_SHA1_TEXT_24 (4 << 1)
+#define  SKL_HDCP_SHA1_TEXT_16 (5 << 1)
+#define  SKL_HDCP_SHA1_TEXT_8  (6 << 1)
+#define  SKL_HDCP_SHA1_TEXT_0  (7 << 1)
+#define SKL_HDCP_SHA_V_PRIME_H0_MMIO(0x66d04)
+#define SKL_HDCP_SHA_V_PRIME_H1_MMIO(0x66d08)
+#define SKL_HDCP_SHA_V_PRIME_H2_MMIO(0x66d0C)
+#define SKL_HDCP_SHA_V_PRIME_H3_MMIO(0x66d10)
+#define SKL_HDCP_SHA_V_PRIME_H4_MMIO(0x66d14)
+#define SKL_HDCP_SHA_V_PRIME(h)_MMIO((0x66d04 + h * 4))
+#define SKL_HDCP_SHA_TEXT  _MMIO(0x66d18)
+
+/* HDCP Auth Registers */
+#define _SKL_PORTA_HDCP_AUTHENC0x66800
+#define _SKL_PORTB_HDCP_AUTHENC0x66500
+#define _SKL_PORTC_HDCP_AUTHENC0x66600
+#define _SKL_PORTD_HDCP_AUTHENC0x66700
+#define _SKL_PORTE_HDCP_AUTHENC

Re: [PATCH resend] mm/page_alloc: fix comment is __get_free_pages

[Michal Hocko]

On Thu 30-11-17 13:17:06, Andrew Morton wrote:
> On Thu, 30 Nov 2017 07:53:35 +0100 Michal Hocko  wrote:
> 
> > > mm...  So we have a caller which hopes to be getting highmem pages but
> > > isn't.  Caller then proceeds to pointlessly kmap the page and wonders
> > > why it isn't getting as much memory as it would like on 32-bit systems,
> > > etc.
> > 
> > How he can kmap the page when he gets a _virtual_ address?
> 
> doh.
> 
> > > I do think we should help ferret out such bogosity.  A WARN_ON_ONCE
> > > would suffice.
> > 
> > This function has always been about lowmem pages. I seriously doubt we
> > have anybody confused and asking for a highmem page in the kernel. I
> > haven't checked that but it would already blow up as VM_BUG_ON tends to
> > be enabled on many setups.
> 
> OK.  But silently accepting __GFP_HIGHMEM is a bit weird - callers
> shouldn't be doing that in the first place.

Yes, they shouldn't be.

> I wonder what happens if we just remove the WARN_ON and pass any
> __GFP_HIGHMEM straight through.  The caller gets a weird address from
> page_to_virt(highmem page) and usually goes splat?  Good enough
> treatment for something which never happens anyway?

page_address will return NULL so they will blow up and leak the freshly
allocated memory. I do not think this is really desirable. We _could_
handle this case but I am not really sure this is a win. A silent fixup
sounds like the most simply protection.

-- 
Michal Hocko
SUSE Labs

Re: [PATCH resend] mm/page_alloc: fix comment is __get_free_pages

[Michal Hocko]

On Thu 30-11-17 13:17:06, Andrew Morton wrote:
> On Thu, 30 Nov 2017 07:53:35 +0100 Michal Hocko  wrote:
> 
> > > mm...  So we have a caller which hopes to be getting highmem pages but
> > > isn't.  Caller then proceeds to pointlessly kmap the page and wonders
> > > why it isn't getting as much memory as it would like on 32-bit systems,
> > > etc.
> > 
> > How he can kmap the page when he gets a _virtual_ address?
> 
> doh.
> 
> > > I do think we should help ferret out such bogosity.  A WARN_ON_ONCE
> > > would suffice.
> > 
> > This function has always been about lowmem pages. I seriously doubt we
> > have anybody confused and asking for a highmem page in the kernel. I
> > haven't checked that but it would already blow up as VM_BUG_ON tends to
> > be enabled on many setups.
> 
> OK.  But silently accepting __GFP_HIGHMEM is a bit weird - callers
> shouldn't be doing that in the first place.

Yes, they shouldn't be.

> I wonder what happens if we just remove the WARN_ON and pass any
> __GFP_HIGHMEM straight through.  The caller gets a weird address from
> page_to_virt(highmem page) and usually goes splat?  Good enough
> treatment for something which never happens anyway?

page_address will return NULL so they will blow up and leak the freshly
allocated memory. I do not think this is really desirable. We _could_
handle this case but I am not really sure this is a win. A silent fixup
sounds like the most simply protection.

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v2] staging: xgifb: remove macros with hidden variable

[Dan Carpenter]

On Thu, Nov 30, 2017 at 10:39:48AM -0500, Joshua Abraham wrote:
> diff --git a/drivers/staging/xgifb/XGI_main_26.c 
> b/drivers/staging/xgifb/XGI_main_26.c
> index 6feecc55d2bc..6de66eaad96b 100644
> --- a/drivers/staging/xgifb/XGI_main_26.c
> +++ b/drivers/staging/xgifb/XGI_main_26.c
> @@ -34,16 +34,16 @@ static void dumpVGAReg(struct xgifb_video_info 
> *xgifb_info)
>  {
>   u8 i, reg;
>  
> - xgifb_reg_set(XGISR, 0x05, 0x86);
> + xgifb_reg_set(xgifb_info->dev_info.P3c4, 0x05, 0x86);

This patch is OK, but it might be nicer to create a temporary variable
so the lines are not so long:

struct vb_device_info *vb = _info->dev_info;
u8 i, reg;

xgifb_reg_set(vb->P3c4, 0x05, 0x86);

I chose "vb" based on the struct name...  "dev" and "info" aren't very
useful in a name because there are a lot of devices and lots of types
of info.

regards,
dan carpneter

Re: [PATCH v2] staging: xgifb: remove macros with hidden variable

[Dan Carpenter]

On Thu, Nov 30, 2017 at 10:39:48AM -0500, Joshua Abraham wrote:
> diff --git a/drivers/staging/xgifb/XGI_main_26.c 
> b/drivers/staging/xgifb/XGI_main_26.c
> index 6feecc55d2bc..6de66eaad96b 100644
> --- a/drivers/staging/xgifb/XGI_main_26.c
> +++ b/drivers/staging/xgifb/XGI_main_26.c
> @@ -34,16 +34,16 @@ static void dumpVGAReg(struct xgifb_video_info 
> *xgifb_info)
>  {
>   u8 i, reg;
>  
> - xgifb_reg_set(XGISR, 0x05, 0x86);
> + xgifb_reg_set(xgifb_info->dev_info.P3c4, 0x05, 0x86);

This patch is OK, but it might be nicer to create a temporary variable
so the lines are not so long:

struct vb_device_info *vb = _info->dev_info;
u8 i, reg;

xgifb_reg_set(vb->P3c4, 0x05, 0x86);

I chose "vb" based on the struct name...  "dev" and "info" aren't very
useful in a name because there are a lot of devices and lots of types
of info.

regards,
dan carpneter

Re: [PATCH 1/3] vhost: fix skb leak in handle_rx()

[Jason Wang]

On 2017年12月01日 13:54, w...@redhat.com wrote:

From: Wei Xu 

Matthew found a roughly 40% tcp throughput regression with commit
c67df11f(vhost_net: try batch dequing from skb array) as discussed
in the following thread:
https://www.mail-archive.com/netdev@vger.kernel.org/msg187936.html

Eventually we figured out that it was a skb leak in handle_rx()
when sending packets to the VM. This usually happens when a guest
can not drain out vq as fast as vhost fills in, afterwards it sets
off the traffic jam and leaks skb(s) which occurs as no headcount
to send on the vq from vhost side.

This can be avoided by making sure we have got enough headcount
before actually consuming a skb from the batched rx array while
transmitting, which is simply done by moving checking the zero
headcount a bit ahead.

Signed-off-by: Wei Xu 
Reported-by: Matthew Rosato 
---
  drivers/vhost/net.c | 20 ++--
  1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 8d626d7..c7bdeb6 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -778,16 +778,6 @@ static void handle_rx(struct vhost_net *net)
/* On error, stop handling until the next kick. */
if (unlikely(headcount < 0))
goto out;
-   if (nvq->rx_array)
-   msg.msg_control = vhost_net_buf_consume(>rxq);
-   /* On overrun, truncate and discard */
-   if (unlikely(headcount > UIO_MAXIOV)) {
-   iov_iter_init(_iter, READ, vq->iov, 1, 1);
-   err = sock->ops->recvmsg(sock, ,
-1, MSG_DONTWAIT | MSG_TRUNC);
-   pr_debug("Discarded rx packet: len %zd\n", sock_len);
-   continue;
-   }
/* OK, now we need to know about added descriptors. */
if (!headcount) {
if (unlikely(vhost_enable_notify(>dev, vq))) {
@@ -800,6 +790,16 @@ static void handle_rx(struct vhost_net *net)
 * they refilled. */
goto out;
}
+   if (nvq->rx_array)
+   msg.msg_control = vhost_net_buf_consume(>rxq);
+   /* On overrun, truncate and discard */
+   if (unlikely(headcount > UIO_MAXIOV)) {
+   iov_iter_init(_iter, READ, vq->iov, 1, 1);
+   err = sock->ops->recvmsg(sock, ,
+1, MSG_DONTWAIT | MSG_TRUNC);
+   pr_debug("Discarded rx packet: len %zd\n", sock_len);
+   continue;
+   }
/* We don't need to be notified again. */
iov_iter_init(_iter, READ, vq->iov, in, vhost_len);
fixup = msg.msg_iter;


I suggest to reorder this patch to 3/3.

Thanks

Re: [PATCH 1/3] vhost: fix skb leak in handle_rx()

[Jason Wang]

On 2017年12月01日 13:54, w...@redhat.com wrote:

From: Wei Xu 

Matthew found a roughly 40% tcp throughput regression with commit
c67df11f(vhost_net: try batch dequing from skb array) as discussed
in the following thread:
https://www.mail-archive.com/netdev@vger.kernel.org/msg187936.html

Eventually we figured out that it was a skb leak in handle_rx()
when sending packets to the VM. This usually happens when a guest
can not drain out vq as fast as vhost fills in, afterwards it sets
off the traffic jam and leaks skb(s) which occurs as no headcount
to send on the vq from vhost side.

This can be avoided by making sure we have got enough headcount
before actually consuming a skb from the batched rx array while
transmitting, which is simply done by moving checking the zero
headcount a bit ahead.

Signed-off-by: Wei Xu 
Reported-by: Matthew Rosato 
---
  drivers/vhost/net.c | 20 ++--
  1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 8d626d7..c7bdeb6 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -778,16 +778,6 @@ static void handle_rx(struct vhost_net *net)
/* On error, stop handling until the next kick. */
if (unlikely(headcount < 0))
goto out;
-   if (nvq->rx_array)
-   msg.msg_control = vhost_net_buf_consume(>rxq);
-   /* On overrun, truncate and discard */
-   if (unlikely(headcount > UIO_MAXIOV)) {
-   iov_iter_init(_iter, READ, vq->iov, 1, 1);
-   err = sock->ops->recvmsg(sock, ,
-1, MSG_DONTWAIT | MSG_TRUNC);
-   pr_debug("Discarded rx packet: len %zd\n", sock_len);
-   continue;
-   }
/* OK, now we need to know about added descriptors. */
if (!headcount) {
if (unlikely(vhost_enable_notify(>dev, vq))) {
@@ -800,6 +790,16 @@ static void handle_rx(struct vhost_net *net)
 * they refilled. */
goto out;
}
+   if (nvq->rx_array)
+   msg.msg_control = vhost_net_buf_consume(>rxq);
+   /* On overrun, truncate and discard */
+   if (unlikely(headcount > UIO_MAXIOV)) {
+   iov_iter_init(_iter, READ, vq->iov, 1, 1);
+   err = sock->ops->recvmsg(sock, ,
+1, MSG_DONTWAIT | MSG_TRUNC);
+   pr_debug("Discarded rx packet: len %zd\n", sock_len);
+   continue;
+   }
/* We don't need to be notified again. */
iov_iter_init(_iter, READ, vq->iov, in, vhost_len);
fixup = msg.msg_iter;


I suggest to reorder this patch to 3/3.

Thanks

Re: [PATCH 3/3] tap: free skb if flags error

[Jason Wang]

On 2017年12月01日 13:54, w...@redhat.com wrote:

From: Wei Xu 

tap_recvmsg() supports accepting skb by msg_control after
commit 3b4ba04acca8 ("tap: support receiving skb from msg_control"),
the skb if presented should be freed within the function, otherwise
it would be leaked.

Signed-off-by: Wei Xu 
Reported-by: Matthew Rosato 
---
  drivers/net/tap.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/tap.c b/drivers/net/tap.c
index e9489b8..1c66b75 100644
--- a/drivers/net/tap.c
+++ b/drivers/net/tap.c
@@ -1154,9 +1154,13 @@ static int tap_recvmsg(struct socket *sock, struct 
msghdr *m,
   size_t total_len, int flags)
  {
struct tap_queue *q = container_of(sock, struct tap_queue, sock);
+   struct sk_buff *skb = m->msg_control;
int ret;
-   if (flags & ~(MSG_DONTWAIT|MSG_TRUNC))
+   if (flags & ~(MSG_DONTWAIT|MSG_TRUNC)) {
+   if (skb)
+   kfree_skb(skb);
return -EINVAL;
+   }
ret = tap_do_read(q, >msg_iter, flags & MSG_DONTWAIT,
  m->msg_control);


Need to deal with iov_iterator_count() == 0.

Thanks


if (ret > total_len) {

Re: [PATCH 3/3] tap: free skb if flags error

[Jason Wang]

On 2017年12月01日 13:54, w...@redhat.com wrote:

From: Wei Xu 

tap_recvmsg() supports accepting skb by msg_control after
commit 3b4ba04acca8 ("tap: support receiving skb from msg_control"),
the skb if presented should be freed within the function, otherwise
it would be leaked.

Signed-off-by: Wei Xu 
Reported-by: Matthew Rosato 
---
  drivers/net/tap.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/tap.c b/drivers/net/tap.c
index e9489b8..1c66b75 100644
--- a/drivers/net/tap.c
+++ b/drivers/net/tap.c
@@ -1154,9 +1154,13 @@ static int tap_recvmsg(struct socket *sock, struct 
msghdr *m,
   size_t total_len, int flags)
  {
struct tap_queue *q = container_of(sock, struct tap_queue, sock);
+   struct sk_buff *skb = m->msg_control;
int ret;
-   if (flags & ~(MSG_DONTWAIT|MSG_TRUNC))
+   if (flags & ~(MSG_DONTWAIT|MSG_TRUNC)) {
+   if (skb)
+   kfree_skb(skb);
return -EINVAL;
+   }
ret = tap_do_read(q, >msg_iter, flags & MSG_DONTWAIT,
  m->msg_control);


Need to deal with iov_iterator_count() == 0.

Thanks


if (ret > total_len) {

Re: [PATCH 2/3] tun: free skb in early errors

[Jason Wang]

On 2017年12月01日 13:54, w...@redhat.com wrote:

From: Wei Xu 

tun_recvmsg() supports accepting skb by msg_control after
commit ac77cfd4258f ("tun: support receiving skb through msg_control"),
the skb if presented should be freed within the function, otherwise it
would be leaked.

Signed-off-by: Wei Xu 
Reported-by: Matthew Rosato 
---
  drivers/net/tun.c | 14 +++---
  1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 6a7bde9..5563430 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -2067,14 +2067,17 @@ static int tun_recvmsg(struct socket *sock, struct 
msghdr *m, size_t total_len,
  {
struct tun_file *tfile = container_of(sock, struct tun_file, socket);
struct tun_struct *tun = tun_get(tfile);
+   struct sk_buff *skb = m->msg_control;
int ret;
  
-	if (!tun)

-   return -EBADFD;
+   if (!tun) {
+   ret = -EBADFD;
+   goto out_free_skb;


Unfortunately, you can't to there since tun is NULL.



+   }
  
  	if (flags & ~(MSG_DONTWAIT|MSG_TRUNC|MSG_ERRQUEUE)) {

ret = -EINVAL;
-   goto out;
+   goto out_free_skb;
}
if (flags & MSG_ERRQUEUE) {
ret = sock_recv_errqueue(sock->sk, m, total_len,
@@ -2087,6 +2090,11 @@ static int tun_recvmsg(struct socket *sock, struct 
msghdr *m, size_t total_len,
m->msg_flags |= MSG_TRUNC;
ret = flags & MSG_TRUNC ? ret : total_len;
}
+   goto out;


We usually don't use goto in the case of success, and you need deal with 
the case skb != NULL but iov_iter_count(to) == 0 in tun_do_read().


Thanks


+
+out_free_skb:
+   if (skb)
+   kfree_skb(skb);
  out:
tun_put(tun);
return ret;

Re: [PATCH 2/3] tun: free skb in early errors

[Jason Wang]

On 2017年12月01日 13:54, w...@redhat.com wrote:

From: Wei Xu 

tun_recvmsg() supports accepting skb by msg_control after
commit ac77cfd4258f ("tun: support receiving skb through msg_control"),
the skb if presented should be freed within the function, otherwise it
would be leaked.

Signed-off-by: Wei Xu 
Reported-by: Matthew Rosato 
---
  drivers/net/tun.c | 14 +++---
  1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 6a7bde9..5563430 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -2067,14 +2067,17 @@ static int tun_recvmsg(struct socket *sock, struct 
msghdr *m, size_t total_len,
  {
struct tun_file *tfile = container_of(sock, struct tun_file, socket);
struct tun_struct *tun = tun_get(tfile);
+   struct sk_buff *skb = m->msg_control;
int ret;
  
-	if (!tun)

-   return -EBADFD;
+   if (!tun) {
+   ret = -EBADFD;
+   goto out_free_skb;


Unfortunately, you can't to there since tun is NULL.



+   }
  
  	if (flags & ~(MSG_DONTWAIT|MSG_TRUNC|MSG_ERRQUEUE)) {

ret = -EINVAL;
-   goto out;
+   goto out_free_skb;
}
if (flags & MSG_ERRQUEUE) {
ret = sock_recv_errqueue(sock->sk, m, total_len,
@@ -2087,6 +2090,11 @@ static int tun_recvmsg(struct socket *sock, struct 
msghdr *m, size_t total_len,
m->msg_flags |= MSG_TRUNC;
ret = flags & MSG_TRUNC ? ret : total_len;
}
+   goto out;


We usually don't use goto in the case of success, and you need deal with 
the case skb != NULL but iov_iter_count(to) == 0 in tun_do_read().


Thanks


+
+out_free_skb:
+   if (skb)
+   kfree_skb(skb);
  out:
tun_put(tun);
return ret;

[PATCH v2 1/2] drm/panel: support Innolux P097PFG panel

[Lin Huang]

Support Innolux P097PFG 9.7" 1536x2048 TFT LCD panel,
it refactor Innolux P079ZCA panel driver, let it support
multi panel, and add support P097PFG panel in this driver.

Signed-off-by: Lin Huang 
---
Changes in v2:
- change regulator property name to meet the panel datasheet 

 drivers/gpu/drm/panel/panel-innolux-p079zca.c | 178 --
 1 file changed, 136 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 6ba9344..5d690b7 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -20,12 +20,32 @@
 
 #include 
 
+struct panel_desc {
+   const struct drm_display_mode *modes;
+   unsigned int bpc;
+   struct {
+   unsigned int width;
+   unsigned int height;
+   } size;
+};
+
+struct panel_desc_dsi {
+   struct panel_desc desc;
+
+   unsigned long flags;
+   enum mipi_dsi_pixel_format format;
+   unsigned int lanes;
+};
+
 struct innolux_panel {
struct drm_panel base;
struct mipi_dsi_device *link;
+   const struct panel_desc_dsi *dsi_desc;
 
struct backlight_device *backlight;
-   struct regulator *supply;
+   struct regulator *vddi;
+   struct regulator *avdd;
+   struct regulator *avee;
struct gpio_desc *enable_gpio;
 
bool prepared;
@@ -78,9 +98,9 @@ static int innolux_panel_unprepare(struct drm_panel *panel)
/* T8: 80ms - 1000ms */
msleep(80);
 
-   err = regulator_disable(innolux->supply);
-   if (err < 0)
-   return err;
+   regulator_disable(innolux->avee);
+   regulator_disable(innolux->avdd);
+   regulator_disable(innolux->vddi);
 
innolux->prepared = false;
 
@@ -97,10 +117,18 @@ static int innolux_panel_prepare(struct drm_panel *panel)
 
gpiod_set_value_cansleep(innolux->enable_gpio, 0);
 
-   err = regulator_enable(innolux->supply);
+   err = regulator_enable(innolux->vddi);
if (err < 0)
return err;
 
+   err = regulator_enable(innolux->avdd);
+   if (err < 0)
+   goto disable_vddi;
+
+   err = regulator_enable(innolux->avee);
+   if (err < 0)
+   goto disable_avdd;
+
/* T2: 15ms - 1000ms */
usleep_range(15000, 16000);
 
@@ -134,12 +162,13 @@ static int innolux_panel_prepare(struct drm_panel *panel)
return 0;
 
 poweroff:
-   regulator_err = regulator_disable(innolux->supply);
-   if (regulator_err)
-   DRM_DEV_ERROR(panel->dev, "failed to disable regulator: %d\n",
- regulator_err);
-
gpiod_set_value_cansleep(innolux->enable_gpio, 0);
+   regulator_disable(innolux->avee);
+disable_avdd:
+   regulator_disable(innolux->avdd);
+disable_vddi:
+   regulator_disable(innolux->vddi);
+
return err;
 }
 
@@ -164,7 +193,7 @@ static int innolux_panel_enable(struct drm_panel *panel)
return 0;
 }
 
-static const struct drm_display_mode default_mode = {
+static const struct drm_display_mode innolux_p079zca_mode = {
.clock = 56900,
.hdisplay = 768,
.hsync_start = 768 + 40,
@@ -177,15 +206,59 @@ static const struct drm_display_mode default_mode = {
.vrefresh = 60,
 };
 
+static const struct panel_desc_dsi innolux_p079zca_panel_desc = {
+   .desc = {
+   .modes = _p079zca_mode,
+   .bpc = 8,
+   .size = {
+   .width = 120,
+   .height = 160,
+   },
+   },
+   .flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+MIPI_DSI_MODE_LPM,
+   .format = MIPI_DSI_FMT_RGB888,
+   .lanes = 4,
+};
+
+static const struct drm_display_mode innolux_p097pfg_mode = {
+   .clock = 22,
+   .hdisplay = 1536,
+   .hsync_start = 1536 + 100,
+   .hsync_end = 1536 + 100 + 24,
+   .htotal = 1536 + 100 + 24 + 100,
+   .vdisplay = 2048,
+   .vsync_start = 2048 + 18,
+   .vsync_end = 2048 + 18 + 2,
+   .vtotal = 2048 + 18 + 2 + 18,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc_dsi innolux_p097pfg_panel_desc = {
+   .desc = {
+   .modes = _p097pfg_mode,
+   .bpc = 8,
+   .size = {
+   .width = 147,
+   .height = 196,
+   },
+   },
+   .flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+MIPI_DSI_MODE_LPM,
+   .format = MIPI_DSI_FMT_RGB888,
+   .lanes = 8,
+};
+
 static int innolux_panel_get_modes(struct drm_panel *panel)
 {
struct drm_display_mode *mode;
+   struct innolux_panel *innolux = to_innolux_panel(panel);
+   const struct drm_display_mode *m = innolux->dsi_desc->desc.modes;
 
-   mode = drm_mode_duplicate(panel->drm, 

[PATCH v2 1/2] drm/panel: support Innolux P097PFG panel

[Lin Huang]

Support Innolux P097PFG 9.7" 1536x2048 TFT LCD panel,
it refactor Innolux P079ZCA panel driver, let it support
multi panel, and add support P097PFG panel in this driver.

Signed-off-by: Lin Huang 
---
Changes in v2:
- change regulator property name to meet the panel datasheet 

 drivers/gpu/drm/panel/panel-innolux-p079zca.c | 178 --
 1 file changed, 136 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 6ba9344..5d690b7 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -20,12 +20,32 @@
 
 #include 
 
+struct panel_desc {
+   const struct drm_display_mode *modes;
+   unsigned int bpc;
+   struct {
+   unsigned int width;
+   unsigned int height;
+   } size;
+};
+
+struct panel_desc_dsi {
+   struct panel_desc desc;
+
+   unsigned long flags;
+   enum mipi_dsi_pixel_format format;
+   unsigned int lanes;
+};
+
 struct innolux_panel {
struct drm_panel base;
struct mipi_dsi_device *link;
+   const struct panel_desc_dsi *dsi_desc;
 
struct backlight_device *backlight;
-   struct regulator *supply;
+   struct regulator *vddi;
+   struct regulator *avdd;
+   struct regulator *avee;
struct gpio_desc *enable_gpio;
 
bool prepared;
@@ -78,9 +98,9 @@ static int innolux_panel_unprepare(struct drm_panel *panel)
/* T8: 80ms - 1000ms */
msleep(80);
 
-   err = regulator_disable(innolux->supply);
-   if (err < 0)
-   return err;
+   regulator_disable(innolux->avee);
+   regulator_disable(innolux->avdd);
+   regulator_disable(innolux->vddi);
 
innolux->prepared = false;
 
@@ -97,10 +117,18 @@ static int innolux_panel_prepare(struct drm_panel *panel)
 
gpiod_set_value_cansleep(innolux->enable_gpio, 0);
 
-   err = regulator_enable(innolux->supply);
+   err = regulator_enable(innolux->vddi);
if (err < 0)
return err;
 
+   err = regulator_enable(innolux->avdd);
+   if (err < 0)
+   goto disable_vddi;
+
+   err = regulator_enable(innolux->avee);
+   if (err < 0)
+   goto disable_avdd;
+
/* T2: 15ms - 1000ms */
usleep_range(15000, 16000);
 
@@ -134,12 +162,13 @@ static int innolux_panel_prepare(struct drm_panel *panel)
return 0;
 
 poweroff:
-   regulator_err = regulator_disable(innolux->supply);
-   if (regulator_err)
-   DRM_DEV_ERROR(panel->dev, "failed to disable regulator: %d\n",
- regulator_err);
-
gpiod_set_value_cansleep(innolux->enable_gpio, 0);
+   regulator_disable(innolux->avee);
+disable_avdd:
+   regulator_disable(innolux->avdd);
+disable_vddi:
+   regulator_disable(innolux->vddi);
+
return err;
 }
 
@@ -164,7 +193,7 @@ static int innolux_panel_enable(struct drm_panel *panel)
return 0;
 }
 
-static const struct drm_display_mode default_mode = {
+static const struct drm_display_mode innolux_p079zca_mode = {
.clock = 56900,
.hdisplay = 768,
.hsync_start = 768 + 40,
@@ -177,15 +206,59 @@ static const struct drm_display_mode default_mode = {
.vrefresh = 60,
 };
 
+static const struct panel_desc_dsi innolux_p079zca_panel_desc = {
+   .desc = {
+   .modes = _p079zca_mode,
+   .bpc = 8,
+   .size = {
+   .width = 120,
+   .height = 160,
+   },
+   },
+   .flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+MIPI_DSI_MODE_LPM,
+   .format = MIPI_DSI_FMT_RGB888,
+   .lanes = 4,
+};
+
+static const struct drm_display_mode innolux_p097pfg_mode = {
+   .clock = 22,
+   .hdisplay = 1536,
+   .hsync_start = 1536 + 100,
+   .hsync_end = 1536 + 100 + 24,
+   .htotal = 1536 + 100 + 24 + 100,
+   .vdisplay = 2048,
+   .vsync_start = 2048 + 18,
+   .vsync_end = 2048 + 18 + 2,
+   .vtotal = 2048 + 18 + 2 + 18,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc_dsi innolux_p097pfg_panel_desc = {
+   .desc = {
+   .modes = _p097pfg_mode,
+   .bpc = 8,
+   .size = {
+   .width = 147,
+   .height = 196,
+   },
+   },
+   .flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+MIPI_DSI_MODE_LPM,
+   .format = MIPI_DSI_FMT_RGB888,
+   .lanes = 8,
+};
+
 static int innolux_panel_get_modes(struct drm_panel *panel)
 {
struct drm_display_mode *mode;
+   struct innolux_panel *innolux = to_innolux_panel(panel);
+   const struct drm_display_mode *m = innolux->dsi_desc->desc.modes;
 
-   mode = drm_mode_duplicate(panel->drm, _mode);
+   mode = 

[PATCH v2 2/2] dt-bindings: Add INNOLUX P097PFG panel bindings

[Lin Huang]

The Innolux P097PFG panel is 9.7" panel with 1536X2048
resolution, it reuse P079ZCA panel driver, so improve
p079ZCA dt-binding to support P097PFG.

Signed-off-by: Lin Huang 
---
 .../devicetree/bindings/display/panel/innolux,p079zca.txt | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt 
b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
index d0f5516..8cadd8c 100644
--- a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
+++ b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
@@ -1,13 +1,18 @@
 Innolux P079ZCA 7.85" 768x1024 TFT LCD panel
+Innolux P097PFG 9.7" 1536x2048 TFT LCD panel
 
 Required properties:
-- compatible: should be "innolux,p079zca"
+- compatible: should be should be one of the following.
+-"innolux,p079zca" for Innolux 7.9" P079ZCA 768*1024 panel
+-"innolux,p097pfg" for Innolux 9.7" P097PFG 1536*2048 panel
 - reg: DSI virtual channel of the peripheral
-- power-supply: phandle of the regulator that provides the supply voltage
 - enable-gpios: panel enable gpio
 
 Optional properties:
 - backlight: phandle of the backlight device attached to the panel
+- power-supply: phandle of the regulator that provides the supply voltage
+- avdd-supply: phandle of the regulator that provides positive voltage
+- avee-supply: phandle of the regulator that provides negative voltage
 
 Example:
 
@@ -16,6 +21,8 @@ Example:
compatible = "innolux,p079zca";
reg = <0>;
power-supply = <...>;
+   avdd-supply = <...>;
+   avee-supply = <...>;
backlight = <>;
enable-gpios = < 13 GPIO_ACTIVE_HIGH>;
};
-- 
2.7.4

[PATCH v2 2/2] dt-bindings: Add INNOLUX P097PFG panel bindings

[Lin Huang]

The Innolux P097PFG panel is 9.7" panel with 1536X2048
resolution, it reuse P079ZCA panel driver, so improve
p079ZCA dt-binding to support P097PFG.

Signed-off-by: Lin Huang 
---
 .../devicetree/bindings/display/panel/innolux,p079zca.txt | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt 
b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
index d0f5516..8cadd8c 100644
--- a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
+++ b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
@@ -1,13 +1,18 @@
 Innolux P079ZCA 7.85" 768x1024 TFT LCD panel
+Innolux P097PFG 9.7" 1536x2048 TFT LCD panel
 
 Required properties:
-- compatible: should be "innolux,p079zca"
+- compatible: should be should be one of the following.
+-"innolux,p079zca" for Innolux 7.9" P079ZCA 768*1024 panel
+-"innolux,p097pfg" for Innolux 9.7" P097PFG 1536*2048 panel
 - reg: DSI virtual channel of the peripheral
-- power-supply: phandle of the regulator that provides the supply voltage
 - enable-gpios: panel enable gpio
 
 Optional properties:
 - backlight: phandle of the backlight device attached to the panel
+- power-supply: phandle of the regulator that provides the supply voltage
+- avdd-supply: phandle of the regulator that provides positive voltage
+- avee-supply: phandle of the regulator that provides negative voltage
 
 Example:
 
@@ -16,6 +21,8 @@ Example:
compatible = "innolux,p079zca";
reg = <0>;
power-supply = <...>;
+   avdd-supply = <...>;
+   avee-supply = <...>;
backlight = <>;
enable-gpios = < 13 GPIO_ACTIVE_HIGH>;
};
-- 
2.7.4

Re: [PATCH] bus: simple-pm-bus: convert bool SIMPLE_PM_BUS to tristate

[Simon Horman]

On Thu, Nov 30, 2017 at 12:57:00PM +0100, Geert Uytterhoeven wrote:
> From: Paul Gortmaker 
> 
> The Kconfig currently controlling compilation of this code is:
> 
> config SIMPLE_PM_BUS
> bool "Simple Power-Managed Bus Driver"
> 
> ...meaning that it currently is not being built as a module by anyone.
> 
> In removing the orphaned modular support in a previous patch set,
> Geert indicated he'd rather see this code converted to tristate.
> 
> I normally don't do that because it extends functionality that I
> can't easily run time test or even know if the use case makes sense,
> but since in this case the author has nominated it as such, we do
> the conversion here.
> 
> Note that doesn't change the lack of run time testing ; this change
> is only tested for sucessful compile and modpost.
> 
> [geert: Ethernet is probed successfully on sh73a0/kzm9g after
> insmodding simple-pm-bus.ko]
> 
> Cc: Kevin Hilman 
> Cc: Simon Horman 
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Paul Gortmaker 
> Tested-by: Geert Uytterhoeven 
> Signed-off-by: Geert Uytterhoeven 

Acked-by: Simon Horman 

> ---
>  drivers/bus/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
> index dc7b3c7b7d42fd09..57e011d36a79fce3 100644
> --- a/drivers/bus/Kconfig
> +++ b/drivers/bus/Kconfig
> @@ -120,7 +120,7 @@ config QCOM_EBI2
> SRAM, ethernet adapters, FPGAs and LCD displays.
>  
>  config SIMPLE_PM_BUS
> - bool "Simple Power-Managed Bus Driver"
> + tristate "Simple Power-Managed Bus Driver"
>   depends on OF && PM
>   help
> Driver for transparent busses that don't need a real driver, but
> -- 
> 2.7.4
> 

Re: [PATCH] bus: simple-pm-bus: convert bool SIMPLE_PM_BUS to tristate

[Simon Horman]

On Thu, Nov 30, 2017 at 12:57:00PM +0100, Geert Uytterhoeven wrote:
> From: Paul Gortmaker 
> 
> The Kconfig currently controlling compilation of this code is:
> 
> config SIMPLE_PM_BUS
> bool "Simple Power-Managed Bus Driver"
> 
> ...meaning that it currently is not being built as a module by anyone.
> 
> In removing the orphaned modular support in a previous patch set,
> Geert indicated he'd rather see this code converted to tristate.
> 
> I normally don't do that because it extends functionality that I
> can't easily run time test or even know if the use case makes sense,
> but since in this case the author has nominated it as such, we do
> the conversion here.
> 
> Note that doesn't change the lack of run time testing ; this change
> is only tested for sucessful compile and modpost.
> 
> [geert: Ethernet is probed successfully on sh73a0/kzm9g after
> insmodding simple-pm-bus.ko]
> 
> Cc: Kevin Hilman 
> Cc: Simon Horman 
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Paul Gortmaker 
> Tested-by: Geert Uytterhoeven 
> Signed-off-by: Geert Uytterhoeven 

Acked-by: Simon Horman 

> ---
>  drivers/bus/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
> index dc7b3c7b7d42fd09..57e011d36a79fce3 100644
> --- a/drivers/bus/Kconfig
> +++ b/drivers/bus/Kconfig
> @@ -120,7 +120,7 @@ config QCOM_EBI2
> SRAM, ethernet adapters, FPGAs and LCD displays.
>  
>  config SIMPLE_PM_BUS
> - bool "Simple Power-Managed Bus Driver"
> + tristate "Simple Power-Managed Bus Driver"
>   depends on OF && PM
>   help
> Driver for transparent busses that don't need a real driver, but
> -- 
> 2.7.4
> 

Re: [PATCH 1/4] MODSIGN: do not load mok when secure boot disabled

[joeyli]

Hi James, 

First, thank you for reviewing and comment!

On Thu, Nov 30, 2017 at 07:51:03AM -0800, James Bottomley wrote:
> On Wed, 2017-11-29 at 22:11 +0800, Lee, Chun-Yi wrote:
> > The mok can not be trusted when the secure boot is disabled. Which
> > means that the kernel embedded certificate is the only trusted key.
> > 
> > Due to db/dbx are authenticated variables, they needs manufacturer's
> > KEK for update. So db/dbx are secure when secureboot disabled.
> > 
> > Cc: David Howells  
> > Cc: Josh Boyer 
> > Signed-off-by: "Lee, Chun-Yi" 
> > ---
> >  certs/load_uefi.c | 26 +++---
> >  1 file changed, 15 insertions(+), 11 deletions(-)
> > 
> > diff --git a/certs/load_uefi.c b/certs/load_uefi.c
> > index 3d88459..d6de4d0 100644
> > --- a/certs/load_uefi.c
> > +++ b/certs/load_uefi.c
> > @@ -164,17 +164,6 @@ static int __init load_uefi_certs(void)
> >     }
> >     }
> >  
> > -   mok = get_cert_list(L"MokListRT", _var, );
> > -   if (!mok) {
> > -   pr_info("MODSIGN: Couldn't get UEFI MokListRT\n");
> > -   } else {
> > -   rc = parse_efi_signature_list("UEFI:MokListRT",
> > -     mok, moksize,
> > get_handler_for_db);
> > -   if (rc)
> > -   pr_err("Couldn't parse MokListRT signatures:
> > %d\n", rc);
> > -   kfree(mok);
> > -   }
> > -
> >     dbx = get_cert_list(L"dbx", _var, );
> >     if (!dbx) {
> >     pr_info("MODSIGN: Couldn't get UEFI dbx list\n");
> > @@ -187,6 +176,21 @@ static int __init load_uefi_certs(void)
> >     kfree(dbx);
> >     }
> >  
> > +   /* the MOK can not be trusted when secure boot is disabled
> > */
> > +   if (!efi_enabled(EFI_SECURE_BOOT))
> > +   return 0;
> > +
> > +   mok = get_cert_list(L"MokListRT", _var, );
> 
> This isn't really a criticism of your patch but the underlying: all of
> the *RT variables, like MokListRT are insecure runtime variables and
> can be tampered with.  I can agree that I can't see a tamper attack
> between exit boot services and pulling this in to the key list, but I'd
> feel a lot happier if the values were obtained directly from the BS
> variable before exit boot services because that's means the path for
> getting the values is directly within the secure envelope and doesn't
> rely on passing via an insecure element.
>

The shim creates MokListRT as a Runtime-Volatile variable then copies
MokList to MokListRT at boot time. According to spec, the Runtime-Volatile
variable is read only after ExitBootService:

UEFI Sepc V2.7, P.281
...
Once ExitBootServices() is performed, only variables that have
EFI_VARIABLE_RUNTIME_ACCESS and EFI_VARIABLE_NON_VOLATILE set can be
set with SetVariable().
Variables that have runtime access but that are not nonvolatile
are read-only data variables once ExitBootServices() is performed.
...

On the other hand, the kernel code is signed and verified by shim. So
all codes in initial kernel path are secure. 

But, your suggestion reminds me that the code in get_cert_list() must
checks MOK/MOKx's attribute to make sure they are Runtime-Volatile
variables. I will update this patch.

Thanks a lot!
Joey Lee

Re: [PATCH 1/4] MODSIGN: do not load mok when secure boot disabled

[joeyli]

Hi James, 

First, thank you for reviewing and comment!

On Thu, Nov 30, 2017 at 07:51:03AM -0800, James Bottomley wrote:
> On Wed, 2017-11-29 at 22:11 +0800, Lee, Chun-Yi wrote:
> > The mok can not be trusted when the secure boot is disabled. Which
> > means that the kernel embedded certificate is the only trusted key.
> > 
> > Due to db/dbx are authenticated variables, they needs manufacturer's
> > KEK for update. So db/dbx are secure when secureboot disabled.
> > 
> > Cc: David Howells  
> > Cc: Josh Boyer 
> > Signed-off-by: "Lee, Chun-Yi" 
> > ---
> >  certs/load_uefi.c | 26 +++---
> >  1 file changed, 15 insertions(+), 11 deletions(-)
> > 
> > diff --git a/certs/load_uefi.c b/certs/load_uefi.c
> > index 3d88459..d6de4d0 100644
> > --- a/certs/load_uefi.c
> > +++ b/certs/load_uefi.c
> > @@ -164,17 +164,6 @@ static int __init load_uefi_certs(void)
> >     }
> >     }
> >  
> > -   mok = get_cert_list(L"MokListRT", _var, );
> > -   if (!mok) {
> > -   pr_info("MODSIGN: Couldn't get UEFI MokListRT\n");
> > -   } else {
> > -   rc = parse_efi_signature_list("UEFI:MokListRT",
> > -     mok, moksize,
> > get_handler_for_db);
> > -   if (rc)
> > -   pr_err("Couldn't parse MokListRT signatures:
> > %d\n", rc);
> > -   kfree(mok);
> > -   }
> > -
> >     dbx = get_cert_list(L"dbx", _var, );
> >     if (!dbx) {
> >     pr_info("MODSIGN: Couldn't get UEFI dbx list\n");
> > @@ -187,6 +176,21 @@ static int __init load_uefi_certs(void)
> >     kfree(dbx);
> >     }
> >  
> > +   /* the MOK can not be trusted when secure boot is disabled
> > */
> > +   if (!efi_enabled(EFI_SECURE_BOOT))
> > +   return 0;
> > +
> > +   mok = get_cert_list(L"MokListRT", _var, );
> 
> This isn't really a criticism of your patch but the underlying: all of
> the *RT variables, like MokListRT are insecure runtime variables and
> can be tampered with.  I can agree that I can't see a tamper attack
> between exit boot services and pulling this in to the key list, but I'd
> feel a lot happier if the values were obtained directly from the BS
> variable before exit boot services because that's means the path for
> getting the values is directly within the secure envelope and doesn't
> rely on passing via an insecure element.
>

The shim creates MokListRT as a Runtime-Volatile variable then copies
MokList to MokListRT at boot time. According to spec, the Runtime-Volatile
variable is read only after ExitBootService:

UEFI Sepc V2.7, P.281
...
Once ExitBootServices() is performed, only variables that have
EFI_VARIABLE_RUNTIME_ACCESS and EFI_VARIABLE_NON_VOLATILE set can be
set with SetVariable().
Variables that have runtime access but that are not nonvolatile
are read-only data variables once ExitBootServices() is performed.
...

On the other hand, the kernel code is signed and verified by shim. So
all codes in initial kernel path are secure. 

But, your suggestion reminds me that the code in get_cert_list() must
checks MOK/MOKx's attribute to make sure they are Runtime-Volatile
variables. I will update this patch.

Thanks a lot!
Joey Lee

blk-mq + bfq IO hangs after writing partition table

[ivan]

Hi,

I think I am triggering a blk-mq + bfq bug that I can reproduce 100%
of the time by using gdisk (1.0.1-1 in Debian stretch) to write a
partition table to a USB flash drive.  After it is triggered, IO hangs
forever to that device and the machine cannot be shut down cleanly.
I have reproduced this on two very different amd64 machines and two
different USB drives.  I don't know if this affects other storage
devices.  This happens *only* with blk-mq + bfq, never with mq-deadline
or kyber.

I built df8ba95c572a187ed2aa7403e97a7a7f58c01f00 (2017-11-30) from
Linus's tree with make-kpkg, without patches of any sort.

My cmdline was:
scsi_mod.use_blk_mq=y dm_mod.use_blk_mq=y apparmor=1 security=apparmor

.config file:
https://gist.githubusercontent.com/ivan/35935783e3153878ce650ab105c1695f/raw/b3de6c85eabd342118b5fecf2b4fab362bde7aa6/config

To reproduce:
boot with blk-mq
plug in a USB stick without any data you want to keep
echo bfq > /sys/block/sdX/queue/scheduler
gdisk /dev/sdX
delete some partitions or add some partitions
"w" to write the partition table
observe IO hang and call trace (below) in the journal after 2 minutes

Note the log below does not show "bfq" because it was loaded earlier.

If it does not reproduce, try another USB flash drive; if that does not
reproduce, cat /dev/zero over it first.

Best regards,

Ivan

Dec 01 05:12:17 kernel: usb 3-1: new high-speed USB device number 2 using 
xhci_hcd
Dec 01 05:12:18 kernel: usb 3-1: New USB device found, idVendor=26bf, 
idProduct=201a
Dec 01 05:12:18 kernel: usb 3-1: New USB device strings: Mfr=0, Product=3, 
SerialNumber=4
Dec 01 05:12:18 kernel: usb 3-1: Product: STORAGE DEVICE
Dec 01 05:12:18 kernel: usb 3-1: SerialNumber: 44705421454402634814
Dec 01 05:12:18 mtp-probe[3289]: checking bus 3, device 2: 
"/sys/devices/pci:00/:00:1c.7/:26:00.0/usb3/3-1"
Dec 01 05:12:18 mtp-probe[3289]: bus: 3, device: 2 was not an MTP device
Dec 01 05:12:18 kernel: usb-storage 3-1:1.0: USB Mass Storage device detected
Dec 01 05:12:18 kernel: scsi host6: usb-storage 3-1:1.0
Dec 01 05:12:18 kernel: usbcore: registered new interface driver usb-storage
Dec 01 05:12:18 kernel: usbcore: registered new interface driver uas
Dec 01 05:12:19 kernel: scsi 6:0:0:0: Direct-Access Specific STORAGE DEVICE 
  0009 PQ: 0 ANSI: 5
Dec 01 05:12:19 kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0
Dec 01 05:12:19 kernel: sd 6:0:0:0: [sdc] 7864320 512-byte logical blocks: 
(4.03 GB/3.75 GiB)
Dec 01 05:12:19 kernel: sd 6:0:0:0: [sdc] Attached SCSI removable disk
Dec 01 05:12:19 kernel:  sdc:
Dec 01 05:12:24 kernel:  sdc:
Dec 01 05:12:35 kernel:  sdc: sdc1 sdc2
Dec 01 05:12:36 kernel:  sdc: sdc1 sdc2
Dec 01 05:12:40 kernel: io scheduler kyber registered
Dec 01 05:12:41 kernel:  sdc: sdc1 sdc2
Dec 01 05:12:52 kernel:  sdc: sdc1
Dec 01 05:12:53 kernel:  sdc: sdc1
Dec 01 05:12:59 kernel:  sdc: sdc1
Dec 01 05:14:00 systemd-udevd[331]: seq 2520 
'/devices/pci:00/:00:1c.7/:26:00.0/usb3/3-1/3-1:1.0/host6/target6:0:0/6:0:0:0/block/sdc'
 is taking a long time
Dec 01 05:14:05 systemd[1]: Started Getty on tty3.
Dec 01 05:14:09 login[3339]: pam_unix(login:session): session opened for user 
root by LOGIN(uid=0)
Dec 01 05:14:09 systemd[1]: Created slice User Slice of root.
Dec 01 05:14:09 systemd[1]: Starting User Manager for UID 0...
Dec 01 05:14:09 systemd[3344]: pam_unix(systemd-user:session): session opened 
for user root by (uid=0)
Dec 01 05:14:09 systemd-logind[545]: New session 3 of user root.
Dec 01 05:14:09 systemd[1]: Started Session 3 of user root.
Dec 01 05:14:09 systemd[3344]: Reached target Paths.
Dec 01 05:14:09 systemd[3344]: Starting D-Bus User Message Bus Socket.
Dec 01 05:14:09 systemd[3344]: Listening on GnuPG cryptographic agent and 
passphrase cache (restricted).
Dec 01 05:14:09 systemd[3344]: Listening on GnuPG cryptographic agent and 
passphrase cache.
Dec 01 05:14:09 systemd[3344]: Listening on GnuPG cryptographic agent (access 
for web browsers).
Dec 01 05:14:09 systemd[3344]: Listening on GnuPG cryptographic agent 
(ssh-agent emulation).
Dec 01 05:14:09 systemd[3344]: Reached target Timers.
Dec 01 05:14:09 systemd[3344]: Listening on D-Bus User Message Bus Socket.
Dec 01 05:14:09 systemd[3344]: Reached target Sockets.
Dec 01 05:14:09 systemd[3344]: Reached target Basic System.
Dec 01 05:14:09 systemd[3344]: Reached target Default.
Dec 01 05:14:09 systemd[3344]: Startup finished in 13ms.
Dec 01 05:14:09 systemd[1]: Started User Manager for UID 0.
Dec 01 05:14:09 login[3350]: ROOT LOGIN  on '/dev/tty3'
Dec 01 05:15:23 kernel: INFO: task kworker/2:1:34 blocked for more than 120 
seconds.
Dec 01 05:15:23 kernel:   Not tainted 4.15.0-rc1+ #2
Dec 01 05:15:23 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" 
disables this message.
Dec 01 05:15:23 kernel: kworker/2:1 D034  2 0x8000
Dec 01 05:15:23 kernel: Workqueue: events_freezable_power_ disk_events_workfn
Dec 01 05:15:23 kernel: Call Trace:
Dec 01 05:15:23 kernel:  

blk-mq + bfq IO hangs after writing partition table

[ivan]

Hi,

I think I am triggering a blk-mq + bfq bug that I can reproduce 100%
of the time by using gdisk (1.0.1-1 in Debian stretch) to write a
partition table to a USB flash drive.  After it is triggered, IO hangs
forever to that device and the machine cannot be shut down cleanly.
I have reproduced this on two very different amd64 machines and two
different USB drives.  I don't know if this affects other storage
devices.  This happens *only* with blk-mq + bfq, never with mq-deadline
or kyber.

I built df8ba95c572a187ed2aa7403e97a7a7f58c01f00 (2017-11-30) from
Linus's tree with make-kpkg, without patches of any sort.

My cmdline was:
scsi_mod.use_blk_mq=y dm_mod.use_blk_mq=y apparmor=1 security=apparmor

.config file:
https://gist.githubusercontent.com/ivan/35935783e3153878ce650ab105c1695f/raw/b3de6c85eabd342118b5fecf2b4fab362bde7aa6/config

To reproduce:
boot with blk-mq
plug in a USB stick without any data you want to keep
echo bfq > /sys/block/sdX/queue/scheduler
gdisk /dev/sdX
delete some partitions or add some partitions
"w" to write the partition table
observe IO hang and call trace (below) in the journal after 2 minutes

Note the log below does not show "bfq" because it was loaded earlier.

If it does not reproduce, try another USB flash drive; if that does not
reproduce, cat /dev/zero over it first.

Best regards,

Ivan

Dec 01 05:12:17 kernel: usb 3-1: new high-speed USB device number 2 using 
xhci_hcd
Dec 01 05:12:18 kernel: usb 3-1: New USB device found, idVendor=26bf, 
idProduct=201a
Dec 01 05:12:18 kernel: usb 3-1: New USB device strings: Mfr=0, Product=3, 
SerialNumber=4
Dec 01 05:12:18 kernel: usb 3-1: Product: STORAGE DEVICE
Dec 01 05:12:18 kernel: usb 3-1: SerialNumber: 44705421454402634814
Dec 01 05:12:18 mtp-probe[3289]: checking bus 3, device 2: 
"/sys/devices/pci:00/:00:1c.7/:26:00.0/usb3/3-1"
Dec 01 05:12:18 mtp-probe[3289]: bus: 3, device: 2 was not an MTP device
Dec 01 05:12:18 kernel: usb-storage 3-1:1.0: USB Mass Storage device detected
Dec 01 05:12:18 kernel: scsi host6: usb-storage 3-1:1.0
Dec 01 05:12:18 kernel: usbcore: registered new interface driver usb-storage
Dec 01 05:12:18 kernel: usbcore: registered new interface driver uas
Dec 01 05:12:19 kernel: scsi 6:0:0:0: Direct-Access Specific STORAGE DEVICE 
  0009 PQ: 0 ANSI: 5
Dec 01 05:12:19 kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0
Dec 01 05:12:19 kernel: sd 6:0:0:0: [sdc] 7864320 512-byte logical blocks: 
(4.03 GB/3.75 GiB)
Dec 01 05:12:19 kernel: sd 6:0:0:0: [sdc] Attached SCSI removable disk
Dec 01 05:12:19 kernel:  sdc:
Dec 01 05:12:24 kernel:  sdc:
Dec 01 05:12:35 kernel:  sdc: sdc1 sdc2
Dec 01 05:12:36 kernel:  sdc: sdc1 sdc2
Dec 01 05:12:40 kernel: io scheduler kyber registered
Dec 01 05:12:41 kernel:  sdc: sdc1 sdc2
Dec 01 05:12:52 kernel:  sdc: sdc1
Dec 01 05:12:53 kernel:  sdc: sdc1
Dec 01 05:12:59 kernel:  sdc: sdc1
Dec 01 05:14:00 systemd-udevd[331]: seq 2520 
'/devices/pci:00/:00:1c.7/:26:00.0/usb3/3-1/3-1:1.0/host6/target6:0:0/6:0:0:0/block/sdc'
 is taking a long time
Dec 01 05:14:05 systemd[1]: Started Getty on tty3.
Dec 01 05:14:09 login[3339]: pam_unix(login:session): session opened for user 
root by LOGIN(uid=0)
Dec 01 05:14:09 systemd[1]: Created slice User Slice of root.
Dec 01 05:14:09 systemd[1]: Starting User Manager for UID 0...
Dec 01 05:14:09 systemd[3344]: pam_unix(systemd-user:session): session opened 
for user root by (uid=0)
Dec 01 05:14:09 systemd-logind[545]: New session 3 of user root.
Dec 01 05:14:09 systemd[1]: Started Session 3 of user root.
Dec 01 05:14:09 systemd[3344]: Reached target Paths.
Dec 01 05:14:09 systemd[3344]: Starting D-Bus User Message Bus Socket.
Dec 01 05:14:09 systemd[3344]: Listening on GnuPG cryptographic agent and 
passphrase cache (restricted).
Dec 01 05:14:09 systemd[3344]: Listening on GnuPG cryptographic agent and 
passphrase cache.
Dec 01 05:14:09 systemd[3344]: Listening on GnuPG cryptographic agent (access 
for web browsers).
Dec 01 05:14:09 systemd[3344]: Listening on GnuPG cryptographic agent 
(ssh-agent emulation).
Dec 01 05:14:09 systemd[3344]: Reached target Timers.
Dec 01 05:14:09 systemd[3344]: Listening on D-Bus User Message Bus Socket.
Dec 01 05:14:09 systemd[3344]: Reached target Sockets.
Dec 01 05:14:09 systemd[3344]: Reached target Basic System.
Dec 01 05:14:09 systemd[3344]: Reached target Default.
Dec 01 05:14:09 systemd[3344]: Startup finished in 13ms.
Dec 01 05:14:09 systemd[1]: Started User Manager for UID 0.
Dec 01 05:14:09 login[3350]: ROOT LOGIN  on '/dev/tty3'
Dec 01 05:15:23 kernel: INFO: task kworker/2:1:34 blocked for more than 120 
seconds.
Dec 01 05:15:23 kernel:   Not tainted 4.15.0-rc1+ #2
Dec 01 05:15:23 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" 
disables this message.
Dec 01 05:15:23 kernel: kworker/2:1 D034  2 0x8000
Dec 01 05:15:23 kernel: Workqueue: events_freezable_power_ disk_events_workfn
Dec 01 05:15:23 kernel: Call Trace:
Dec 01 05:15:23 kernel:  

Re: [PATCH v3 4/5] drm/rockchip: Add ROCKCHIP DW MIPI DSI controller driver

[Nickey Yang]

Hi Matthias,


On 2017年11月29日 04:48, Matthias Kaehlcke wrote:

El Tue, Nov 28, 2017 at 07:20:05PM +0800 Nickey Yang ha dit:


Add the ROCKCHIP DSI controller driver that uses the Synopsys DesignWare
MIPI DSI host controller bridge.

v2:
add err_pllref, remove unnecessary encoder.enable & disable
correct spelling mistakes
v3:
call dw_mipi_dsi_unbind() in dw_mipi_dsi_rockchip_unbind()
fix typo, use of_device_get_match_data(),
change some ‘bind()’ logic into 'probe()'
add 'dev_set_drvdata()'

Signed-off-by: Nickey Yang 
---
  drivers/gpu/drm/rockchip/Kconfig|2 +-
  drivers/gpu/drm/rockchip/Makefile   |2 +-
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c  | 1349 ---
  drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c |  764 +
  drivers/gpu/drm/rockchip/rockchip_drm_drv.c |2 +-
  drivers/gpu/drm/rockchip/rockchip_drm_drv.h |2 +-
  6 files changed, 768 insertions(+), 1353 deletions(-)
  delete mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c
  create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 0ccc762..9eb4795 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -7,7 +7,7 @@ config DRM_ROCKCHIP
select VIDEOMODE_HELPERS
select DRM_ANALOGIX_DP if ROCKCHIP_ANALOGIX_DP
select DRM_DW_HDMI if ROCKCHIP_DW_HDMI
-   select DRM_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI
+   select DRM_DW_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI
select SND_SOC_HDMI_CODEC if ROCKCHIP_CDN_DP && SND_SOC
help
  Choose this option if you have a Rockchip soc chipset.
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index a314e21..c05fe47 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -11,7 +11,7 @@ rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += 
rockchip_drm_fbdev.o
  rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
  rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
  rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
-rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
+rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi_rockchip.o
  rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
  rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o
  
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c

deleted file mode 100644
index b15755b..000
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ /dev/null
@@ -1,1349 +0,0 @@
-/*
- * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
- *
- * 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 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "rockchip_drm_drv.h"
-#include "rockchip_drm_vop.h"
-
-#define DRIVER_NAME"dw-mipi-dsi"
-
-#define RK3288_GRF_SOC_CON60x025c
-#define RK3288_DSI0_SEL_VOP_LITBIT(6)
-#define RK3288_DSI1_SEL_VOP_LITBIT(9)
-
-#define RK3399_GRF_SOC_CON20   0x6250
-#define RK3399_DSI0_SEL_VOP_LITBIT(0)
-#define RK3399_DSI1_SEL_VOP_LITBIT(4)
-
-/* disable turnrequest, turndisable, forcetxstopmode, forcerxmode */
-#define RK3399_GRF_SOC_CON22   0x6258
-#define RK3399_GRF_DSI_MODE0x
-
-#define DSI_VERSION0x00
-#define DSI_PWR_UP 0x04
-#define RESET  0
-#define POWERUPBIT(0)
-
-#define DSI_CLKMGR_CFG 0x08
-#define TO_CLK_DIVIDSION(div)  (((div) & 0xff) << 8)
-#define TX_ESC_CLK_DIVIDSION(div)  (((div) & 0xff) << 0)
-
-#define DSI_DPI_VCID   0x0c
-#define DPI_VID(vid)   (((vid) & 0x3) << 0)
-
-#define DSI_DPI_COLOR_CODING   0x10
-#define EN18_LOOSELY   BIT(8)
-#define DPI_COLOR_CODING_16BIT_1   0x0
-#define DPI_COLOR_CODING_16BIT_2   0x1
-#define DPI_COLOR_CODING_16BIT_3   0x2
-#define DPI_COLOR_CODING_18BIT_1   0x3
-#define DPI_COLOR_CODING_18BIT_2   0x4
-#define DPI_COLOR_CODING_24BIT 0x5
-
-#define DSI_DPI_CFG_POL0x14
-#define COLORM_ACTIVE_LOW  BIT(4)
-#define SHUTD_ACTIVE_LOW   BIT(3)
-#define HSYNC_ACTIVE_LOW   BIT(2)
-#define VSYNC_ACTIVE_LOW   BIT(1)
-#define DATAEN_ACTIVE_LOW  BIT(0)
-
-#define DSI_DPI_LP_CMD_TIM 

Re: [PATCH v3 4/5] drm/rockchip: Add ROCKCHIP DW MIPI DSI controller driver

[Nickey Yang]

Hi Matthias,


On 2017年11月29日 04:48, Matthias Kaehlcke wrote:

El Tue, Nov 28, 2017 at 07:20:05PM +0800 Nickey Yang ha dit:


Add the ROCKCHIP DSI controller driver that uses the Synopsys DesignWare
MIPI DSI host controller bridge.

v2:
add err_pllref, remove unnecessary encoder.enable & disable
correct spelling mistakes
v3:
call dw_mipi_dsi_unbind() in dw_mipi_dsi_rockchip_unbind()
fix typo, use of_device_get_match_data(),
change some ‘bind()’ logic into 'probe()'
add 'dev_set_drvdata()'

Signed-off-by: Nickey Yang 
---
  drivers/gpu/drm/rockchip/Kconfig|2 +-
  drivers/gpu/drm/rockchip/Makefile   |2 +-
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c  | 1349 ---
  drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c |  764 +
  drivers/gpu/drm/rockchip/rockchip_drm_drv.c |2 +-
  drivers/gpu/drm/rockchip/rockchip_drm_drv.h |2 +-
  6 files changed, 768 insertions(+), 1353 deletions(-)
  delete mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c
  create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 0ccc762..9eb4795 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -7,7 +7,7 @@ config DRM_ROCKCHIP
select VIDEOMODE_HELPERS
select DRM_ANALOGIX_DP if ROCKCHIP_ANALOGIX_DP
select DRM_DW_HDMI if ROCKCHIP_DW_HDMI
-   select DRM_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI
+   select DRM_DW_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI
select SND_SOC_HDMI_CODEC if ROCKCHIP_CDN_DP && SND_SOC
help
  Choose this option if you have a Rockchip soc chipset.
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index a314e21..c05fe47 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -11,7 +11,7 @@ rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += 
rockchip_drm_fbdev.o
  rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
  rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
  rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
-rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
+rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi_rockchip.o
  rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
  rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o
  
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c

deleted file mode 100644
index b15755b..000
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ /dev/null
@@ -1,1349 +0,0 @@
-/*
- * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
- *
- * 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 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "rockchip_drm_drv.h"
-#include "rockchip_drm_vop.h"
-
-#define DRIVER_NAME"dw-mipi-dsi"
-
-#define RK3288_GRF_SOC_CON60x025c
-#define RK3288_DSI0_SEL_VOP_LITBIT(6)
-#define RK3288_DSI1_SEL_VOP_LITBIT(9)
-
-#define RK3399_GRF_SOC_CON20   0x6250
-#define RK3399_DSI0_SEL_VOP_LITBIT(0)
-#define RK3399_DSI1_SEL_VOP_LITBIT(4)
-
-/* disable turnrequest, turndisable, forcetxstopmode, forcerxmode */
-#define RK3399_GRF_SOC_CON22   0x6258
-#define RK3399_GRF_DSI_MODE0x
-
-#define DSI_VERSION0x00
-#define DSI_PWR_UP 0x04
-#define RESET  0
-#define POWERUPBIT(0)
-
-#define DSI_CLKMGR_CFG 0x08
-#define TO_CLK_DIVIDSION(div)  (((div) & 0xff) << 8)
-#define TX_ESC_CLK_DIVIDSION(div)  (((div) & 0xff) << 0)
-
-#define DSI_DPI_VCID   0x0c
-#define DPI_VID(vid)   (((vid) & 0x3) << 0)
-
-#define DSI_DPI_COLOR_CODING   0x10
-#define EN18_LOOSELY   BIT(8)
-#define DPI_COLOR_CODING_16BIT_1   0x0
-#define DPI_COLOR_CODING_16BIT_2   0x1
-#define DPI_COLOR_CODING_16BIT_3   0x2
-#define DPI_COLOR_CODING_18BIT_1   0x3
-#define DPI_COLOR_CODING_18BIT_2   0x4
-#define DPI_COLOR_CODING_24BIT 0x5
-
-#define DSI_DPI_CFG_POL0x14
-#define COLORM_ACTIVE_LOW  BIT(4)
-#define SHUTD_ACTIVE_LOW   BIT(3)
-#define HSYNC_ACTIVE_LOW   BIT(2)
-#define VSYNC_ACTIVE_LOW   BIT(1)
-#define DATAEN_ACTIVE_LOW  BIT(0)
-
-#define DSI_DPI_LP_CMD_TIM 0x18
-#define 

RE: [PATCH v3 7/9] KVM: x86: Implement Intel Processor Trace MSRs read/write

[Kang, Luwei]

> > +   case MSR_IA32_RTIT_ADDR0_A ... MSR_IA32_RTIT_ADDR3_B: {
> > +   u32 eax, ebx, ecx, edx;
> > +
> > +   cpuid_count(0x14, 1, , , , );
> 
> Please cache the cpuid_count result, or do the cpuid_count after testing
> vmx_pt_supported() (which you can use instead of going through kvm_x86_ops).

Hi Paolo,
Thanks for your reply. I have cache EAX in "struct pt_desc" and will 
initialize in vmx_vcpu_setup().
+struct pt_desc {
+   unsigned int addr_num;
+   struct pt_ctx host;
+   struct pt_ctx guest;
+}; 
But kvm_init_msr_list() is invoked too early, I have to read from hardware. 
 So, what about change like this.

-   cpuid_count(0x14, 1, , , , );
-   if (!kvm_x86_ops->pt_supported() || msrs_to_save[i] -
-   MSR_IA32_RTIT_ADDR0_A >= (eax & 0x7))
+   if (!kvm_x86_ops->pt_supported())
continue;
+   cpuid_count(0x14, 1, , , , );
+   if (msrs_to_save[i] -
+   MSR_IA32_RTIT_ADDR0_A >= (eax & 0x7))
+   continue;

Thanks,
Luwei Kang

> 
> Thanks,
> 
> Paolo
> 
> > +   if (!kvm_x86_ops->pt_supported() || msrs_to_save[i] -
> > +   MSR_IA32_RTIT_ADDR0_A >= (eax & 0x7))
> > +   continue;
> > +   break;

RE: [PATCH v3 7/9] KVM: x86: Implement Intel Processor Trace MSRs read/write

[Kang, Luwei]

> > +   case MSR_IA32_RTIT_ADDR0_A ... MSR_IA32_RTIT_ADDR3_B: {
> > +   u32 eax, ebx, ecx, edx;
> > +
> > +   cpuid_count(0x14, 1, , , , );
> 
> Please cache the cpuid_count result, or do the cpuid_count after testing
> vmx_pt_supported() (which you can use instead of going through kvm_x86_ops).

Hi Paolo,
Thanks for your reply. I have cache EAX in "struct pt_desc" and will 
initialize in vmx_vcpu_setup().
+struct pt_desc {
+   unsigned int addr_num;
+   struct pt_ctx host;
+   struct pt_ctx guest;
+}; 
But kvm_init_msr_list() is invoked too early, I have to read from hardware. 
 So, what about change like this.

-   cpuid_count(0x14, 1, , , , );
-   if (!kvm_x86_ops->pt_supported() || msrs_to_save[i] -
-   MSR_IA32_RTIT_ADDR0_A >= (eax & 0x7))
+   if (!kvm_x86_ops->pt_supported())
continue;
+   cpuid_count(0x14, 1, , , , );
+   if (msrs_to_save[i] -
+   MSR_IA32_RTIT_ADDR0_A >= (eax & 0x7))
+   continue;

Thanks,
Luwei Kang

> 
> Thanks,
> 
> Paolo
> 
> > +   if (!kvm_x86_ops->pt_supported() || msrs_to_save[i] -
> > +   MSR_IA32_RTIT_ADDR0_A >= (eax & 0x7))
> > +   continue;
> > +   break;

[PATCH 1/4] arm: dts: imx28: Use phandles instead of unit addresses

[venkataravi . e]

From: Ravi Eluri 

Unit addresses for all peripherals of imx28 are defined in
the corresponding dtsi file, use phandles instead of unit addresses
to reference peripheral nodes in dts files. This makes the DT more
robust and readable.

Signed-off-by: Ravi Eluri 
Signed-off-by: Suniel Mahesh 
---
Note:
- This is the first patch of the four patch series.
- Patch was compile tested and built(ARCH=arm, imx28) on linux-next
  (latest).
- No build issues reported.
- Please discard this changeset, if this is not making any better.
---
 arch/arm/boot/dts/imx28-evk.dts | 44 -
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index 7f5b804..21ac4fa 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -22,14 +22,14 @@
 
apb@8000 {
apbh@8000 {
-   gpmi-nand@8000c000 {
+{
pinctrl-names = "default";
pinctrl-0 = <_pins_a _status_cfg
 _pins_evk>;
status = "okay";
};
 
-   ssp0: ssp@8001 {
+{
compatible = "fsl,imx28-mmc";
pinctrl-names = "default";
pinctrl-0 = <_8bit_pins_a
@@ -40,13 +40,13 @@
status = "okay";
};
 
-   ssp1: ssp@80012000 {
+{
compatible = "fsl,imx28-mmc";
bus-width = <8>;
wp-gpios = < 28 0>;
};
 
-   ssp2: ssp@80014000 {
+{
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,imx28-spi";
@@ -63,7 +63,7 @@
};
};
 
-   pinctrl@80018000 {
+{
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
 
@@ -119,7 +119,7 @@
};
};
 
-   lcdif@8003 {
+{
pinctrl-names = "default";
pinctrl-0 = <_24bit_pins_a
 _pins_evk>;
@@ -152,14 +152,14 @@
};
};
 
-   can0: can@80032000 {
+{
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
xceiver-supply = <_can_3v3>;
status = "okay";
};
 
-   can1: can@80034000 {
+{
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
xceiver-supply = <_can_3v3>;
@@ -168,20 +168,20 @@
};
 
apbx@8004 {
-   saif0: saif@80042000 {
+{
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
status = "okay";
};
 
-   saif1: saif@80046000 {
+{
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
fsl,saif-master = <>;
status = "okay";
};
 
-   lradc@8005 {
+{
status = "okay";
fsl,lradc-touchscreen-wires = <4>;
fsl,ave-ctrl = <4>;
@@ -189,7 +189,7 @@
fsl,settling = <10>;
};
 
-   i2c0: i2c@80058000 {
+{
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
status = "okay";
@@ -209,55 +209,55 @@
};
};
 
-   pwm: pwm@80064000 {
+{
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
status = "okay";

[PATCH 4/4] arm: dts: imx28: Device tree cleanup

[venkataravi . e]

From: Ravi Eluri 

Cleaned up device tree.

Signed-off-by: Ravi Eluri 
Signed-off-by: Suniel Mahesh 
---
Note:
- This is the fourth patch of the four patch series.
- Patch was compile tested and built(ARCH=arm, imx28) on linux-next
  (latest).
- No build issues reported.
- Please discard this changeset, if this is not making any better.
---
 arch/arm/boot/dts/imx28-evk.dts | 448 
 1 file changed, 224 insertions(+), 224 deletions(-)

diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index 9d74486..eb683264 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -121,249 +121,249 @@
};
 };
 
-{
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins_a _status_cfg
-_pins_evk>;
-   status = "okay";
-   };
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a _status_cfg
+_pins_evk>;
+   status = "okay";
+};
 
-{
-   compatible = "fsl,imx28-mmc";
-   pinctrl-names = "default";
-   pinctrl-0 = <_8bit_pins_a
-   _cd_cfg _sck_cfg>;
-   bus-width = <8>;
-   wp-gpios = < 12 0>;
-   vmmc-supply = <_vddio_sd0>;
-   status = "okay";
-   };
+ {
+   compatible = "fsl,imx28-mmc";
+   pinctrl-names = "default";
+   pinctrl-0 = <_8bit_pins_a
+_cd_cfg _sck_cfg>;
+   bus-width = <8>;
+   wp-gpios = < 12 0>;
+   vmmc-supply = <_vddio_sd0>;
+   status = "okay";
+};
 
-{
-   compatible = "fsl,imx28-mmc";
-   bus-width = <8>;
-   wp-gpios = < 28 0>;
-   };
+ {
+   compatible = "fsl,imx28-mmc";
+   bus-width = <8>;
+   wp-gpios = < 28 0>;
+};
 
-{
-   #address-cells = <1>;
-   #size-cells = <0>;
-   compatible = "fsl,imx28-spi";
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins_a>;
-   status = "okay";
-
-   flash: m25p80@0 {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   compatible = "sst,sst25vf016b", 
"jedec,spi-nor";
-   spi-max-frequency = <4000>;
-   reg = <0>;
-   };
-   };
+ {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,imx28-spi";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
 
-{
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins_a>;
-
-   hog_pins_a: hog@0 {
-   reg = <0>;
-   fsl,pinmux-ids = <
-   MX28_PAD_SSP1_CMD__GPIO_2_13
-   MX28_PAD_SSP1_DATA3__GPIO_2_15
-   MX28_PAD_ENET0_RX_CLK__GPIO_4_13
-   MX28_PAD_SSP1_SCK__GPIO_2_12
-   MX28_PAD_PWM3__GPIO_3_28
-   MX28_PAD_LCD_RESET__GPIO_3_30
-   MX28_PAD_AUART2_RX__GPIO_3_8
-   MX28_PAD_AUART2_TX__GPIO_3_9
-   >;
-   fsl,drive-strength = ;
-   fsl,voltage = ;
-   fsl,pull-up = ;
-   };
-
-   led_pin_gpio3_5: led_gpio3_5@0 {
-   reg = <0>;
-   fsl,pinmux-ids = <
-   MX28_PAD_AUART1_TX__GPIO_3_5
-   >;
-   fsl,drive-strength = ;
-   fsl,voltage = ;
-   fsl,pull-up = ;
-   };
-
-  

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

[Daniel Micay]

It was suggested that the feature would only be adopted in niches like
Android and I pointed out that it's not really relevant to Android.

It's a waste of time to try convincing me that it's useful elsewhere. I
never said or implied that it wasn't.

On Thu, 2017-11-30 at 09:50 +0100, Djalal Harouni wrote:
> On Thu, Nov 30, 2017 at 7:51 AM, Daniel Micay 
> wrote:
> [...]
> > Lots of potential module attack surface also gets eliminated by
> > default
> > via their SELinux whitelists for /dev, /sys, /proc, debugfs, ioctl
> > commands, etc. The global seccomp whitelist might be relevant in
> > some
> > cases too.
> 
> In embedded systems we can't maintain a SELinux policy, distro man
> power hardly manage. We have abstracted seccomp etc, but the kernel
> inherited the difficult multiplex things, plus all other paths that
> trigger this.

It's cheaper to use an existing system like Android Things where device
makers only need to make their apps and perhaps some userspace hardware
drivers for cases not covered by mainline kernel drivers. I don't think
it makes sense for every device vendor to manage an OS and I seriously
doubt that's how the ecosystem is going to end up as it matures.

> > Android devices like to build everything into the kernel too, so
> > even if
> > they weren't using a module this feature wouldn't usually help them.
> > It
> > would need to work like this existing sysctl:
> > 
> > net.ipv4.tcp_available_congestion_control = cubic reno lp
> > 
> > i.e. whitelists for functionality offered by the modules, not just
> > whether they can be loaded.
> 
> Yes, but it is hard to maintain a whitelist policy, the code is hardly
> maintained... if you include everything you should have an LSM policy
> or something like that, and compiling kernels is expert thing.

I'm not talking about whitelist vs. blacklist, compiling kernels or
anything like that.

> Otherwise IMHO the kernel should provide default secure behaviour on
> how to load or add new functionality to the running one. From a user
> perspective, a switch "yes/no" that a privileged entity will
> *understand* and assume is what should be there, and the switch or
> flag as discussed here is local to processes, the sysctl will be
> removed. IMO it should come from userspace point of view, cause as an
> example the sysctl:
> 
> net.ipv4.tcp_available_congestion_control = cubic reno lp
> 
> Is kernel thing, too technical, userspace developers, admins or
> privileged entity will not understand what cubic or reno mean.

Congestion control algorithms are being used as an example in terms of
the mechanism being used to control which are available to unprivileged
users. The obscurity of congestion control algorithms is irrelevant.

>  Doing
> the same per functionality directly like this seems to much of a
> burden compared to the use case. The kernel maybe can do this to
> advance the art of the networking stack and for advanced cases, but in
> IMHO a sane default behaviour + an abstracted process/sandbox flag
> "yes/no" for most others, userspace developers and humans is what
> should be provided and we need the kernel to help here.

There are cases where unprivileged module auto-loading is relied upon
like network protocols. Having configuration for which protocols can be
used by unprivileged users is superior to limiting only which ones can
be auto-loaded. That's why I bought up the existing congestion control
knob. It works well in terms of having a whitelist of the sane, widely
used cases with exposing anything obscure requiring configuration. They
happen to be implemented as modules too.

Killing off unprivileged module loading other than a few cases like that
makes sense, and then those can provide similar control with similarly
sane defaults.

[PATCH 3/4] arm: dts: imx28: Rearrange nodes for better readability

[venkataravi . e]

From: Ravi Eluri 

Moved regulator, sound, leds, backlight nodes to the top of the
device tree, cleaned up for better readability.

Signed-off-by: Ravi Eluri 
Signed-off-by: Suniel Mahesh 
---
Note:
- This is the third patch of the four patch series.
- Patch was compile tested and built(ARCH=arm, imx28) on linux-next
  (latest).
- No build issues reported.
- Please discard this changeset, if this is not making any better.
---
 arch/arm/boot/dts/imx28-evk.dts | 203 
 1 file changed, 101 insertions(+), 102 deletions(-)

diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index 28564864..9d74486 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -20,6 +20,107 @@
reg = <0x4000 0x0800>;
};
 
+   regulators {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg_3p3v: regulator@0 {
+   compatible = "regulator-fixed";
+   reg = <0>;
+   regulator-name = "3P3V";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   };
+
+   reg_vddio_sd0: regulator@1 {
+   compatible = "regulator-fixed";
+   reg = <1>;
+   regulator-name = "vddio-sd0";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = < 28 0>;
+   };
+
+   reg_fec_3v3: regulator@2 {
+   compatible = "regulator-fixed";
+   reg = <2>;
+   regulator-name = "fec-3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = < 15 0>;
+   };
+
+   reg_usb0_vbus: regulator@3 {
+   compatible = "regulator-fixed";
+   reg = <3>;
+   regulator-name = "usb0_vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = < 9 0>;
+   enable-active-high;
+   };
+
+   reg_usb1_vbus: regulator@4 {
+   compatible = "regulator-fixed";
+   reg = <4>;
+   regulator-name = "usb1_vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = < 8 0>;
+   enable-active-high;
+   };
+
+   reg_lcd_3v3: regulator@5 {
+   compatible = "regulator-fixed";
+   reg = <5>;
+   regulator-name = "lcd-3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = < 30 0>;
+   enable-active-high;
+   };
+
+   reg_can_3v3: regulator@6 {
+   compatible = "regulator-fixed";
+   reg = <6>;
+   regulator-name = "can-3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = < 13 0>;
+   enable-active-high;
+   };
+   };
+
+   sound {
+   compatible = "fsl,imx28-evk-sgtl5000",
+"fsl,mxs-audio-sgtl5000";
+   model = "imx28-evk-sgtl5000";
+   saif-controllers = < >;
+   audio-codec = <>;
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pin_gpio3_5>;
+
+   user {
+   label = "Heartbeat";
+   gpios = < 5 0>;
+   linux,default-trigger = "heartbeat";
+   };
+   };
+
+   backlight {
+   compatible = "pwm-backlight";
+   pwms = < 2 500>;
+   brightness-levels = <0 4 8 16 32 64 128 255>;
+   default-brightness-level = <6>;
+   };
+};
+
 {
pinctrl-names = "default";
pinctrl-0 = <_pins_a _status_cfg
@@ -266,105 +367,3 @@
pinctrl-0 = <_pins_a>;
status = "okay";
};
-
-   regulators {
-   compatible = 

[PATCH 1/4] arm: dts: imx28: Use phandles instead of unit addresses

[venkataravi . e]

From: Ravi Eluri 

Unit addresses for all peripherals of imx28 are defined in
the corresponding dtsi file, use phandles instead of unit addresses
to reference peripheral nodes in dts files. This makes the DT more
robust and readable.

Signed-off-by: Ravi Eluri 
Signed-off-by: Suniel Mahesh 
---
Note:
- This is the first patch of the four patch series.
- Patch was compile tested and built(ARCH=arm, imx28) on linux-next
  (latest).
- No build issues reported.
- Please discard this changeset, if this is not making any better.
---
 arch/arm/boot/dts/imx28-evk.dts | 44 -
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index 7f5b804..21ac4fa 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -22,14 +22,14 @@
 
apb@8000 {
apbh@8000 {
-   gpmi-nand@8000c000 {
+{
pinctrl-names = "default";
pinctrl-0 = <_pins_a _status_cfg
 _pins_evk>;
status = "okay";
};
 
-   ssp0: ssp@8001 {
+{
compatible = "fsl,imx28-mmc";
pinctrl-names = "default";
pinctrl-0 = <_8bit_pins_a
@@ -40,13 +40,13 @@
status = "okay";
};
 
-   ssp1: ssp@80012000 {
+{
compatible = "fsl,imx28-mmc";
bus-width = <8>;
wp-gpios = < 28 0>;
};
 
-   ssp2: ssp@80014000 {
+{
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,imx28-spi";
@@ -63,7 +63,7 @@
};
};
 
-   pinctrl@80018000 {
+{
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
 
@@ -119,7 +119,7 @@
};
};
 
-   lcdif@8003 {
+{
pinctrl-names = "default";
pinctrl-0 = <_24bit_pins_a
 _pins_evk>;
@@ -152,14 +152,14 @@
};
};
 
-   can0: can@80032000 {
+{
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
xceiver-supply = <_can_3v3>;
status = "okay";
};
 
-   can1: can@80034000 {
+{
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
xceiver-supply = <_can_3v3>;
@@ -168,20 +168,20 @@
};
 
apbx@8004 {
-   saif0: saif@80042000 {
+{
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
status = "okay";
};
 
-   saif1: saif@80046000 {
+{
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
fsl,saif-master = <>;
status = "okay";
};
 
-   lradc@8005 {
+{
status = "okay";
fsl,lradc-touchscreen-wires = <4>;
fsl,ave-ctrl = <4>;
@@ -189,7 +189,7 @@
fsl,settling = <10>;
};
 
-   i2c0: i2c@80058000 {
+{
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
status = "okay";
@@ -209,55 +209,55 @@
};
};
 
-   pwm: pwm@80064000 {
+{
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
status = "okay";
};
 
-   duart: serial@80074000 {
+   

[PATCH 4/4] arm: dts: imx28: Device tree cleanup

[venkataravi . e]

From: Ravi Eluri 

Cleaned up device tree.

Signed-off-by: Ravi Eluri 
Signed-off-by: Suniel Mahesh 
---
Note:
- This is the fourth patch of the four patch series.
- Patch was compile tested and built(ARCH=arm, imx28) on linux-next
  (latest).
- No build issues reported.
- Please discard this changeset, if this is not making any better.
---
 arch/arm/boot/dts/imx28-evk.dts | 448 
 1 file changed, 224 insertions(+), 224 deletions(-)

diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index 9d74486..eb683264 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -121,249 +121,249 @@
};
 };
 
-{
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins_a _status_cfg
-_pins_evk>;
-   status = "okay";
-   };
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a _status_cfg
+_pins_evk>;
+   status = "okay";
+};
 
-{
-   compatible = "fsl,imx28-mmc";
-   pinctrl-names = "default";
-   pinctrl-0 = <_8bit_pins_a
-   _cd_cfg _sck_cfg>;
-   bus-width = <8>;
-   wp-gpios = < 12 0>;
-   vmmc-supply = <_vddio_sd0>;
-   status = "okay";
-   };
+ {
+   compatible = "fsl,imx28-mmc";
+   pinctrl-names = "default";
+   pinctrl-0 = <_8bit_pins_a
+_cd_cfg _sck_cfg>;
+   bus-width = <8>;
+   wp-gpios = < 12 0>;
+   vmmc-supply = <_vddio_sd0>;
+   status = "okay";
+};
 
-{
-   compatible = "fsl,imx28-mmc";
-   bus-width = <8>;
-   wp-gpios = < 28 0>;
-   };
+ {
+   compatible = "fsl,imx28-mmc";
+   bus-width = <8>;
+   wp-gpios = < 28 0>;
+};
 
-{
-   #address-cells = <1>;
-   #size-cells = <0>;
-   compatible = "fsl,imx28-spi";
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins_a>;
-   status = "okay";
-
-   flash: m25p80@0 {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   compatible = "sst,sst25vf016b", 
"jedec,spi-nor";
-   spi-max-frequency = <4000>;
-   reg = <0>;
-   };
-   };
+ {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,imx28-spi";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
 
-{
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins_a>;
-
-   hog_pins_a: hog@0 {
-   reg = <0>;
-   fsl,pinmux-ids = <
-   MX28_PAD_SSP1_CMD__GPIO_2_13
-   MX28_PAD_SSP1_DATA3__GPIO_2_15
-   MX28_PAD_ENET0_RX_CLK__GPIO_4_13
-   MX28_PAD_SSP1_SCK__GPIO_2_12
-   MX28_PAD_PWM3__GPIO_3_28
-   MX28_PAD_LCD_RESET__GPIO_3_30
-   MX28_PAD_AUART2_RX__GPIO_3_8
-   MX28_PAD_AUART2_TX__GPIO_3_9
-   >;
-   fsl,drive-strength = ;
-   fsl,voltage = ;
-   fsl,pull-up = ;
-   };
-
-   led_pin_gpio3_5: led_gpio3_5@0 {
-   reg = <0>;
-   fsl,pinmux-ids = <
-   MX28_PAD_AUART1_TX__GPIO_3_5
-   >;
-   fsl,drive-strength = ;
-   fsl,voltage = ;
-   fsl,pull-up = ;
-   };
-
-   gpmi_pins_evk: gpmi-nand-evk@0 {
-   

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

[Daniel Micay]

It was suggested that the feature would only be adopted in niches like
Android and I pointed out that it's not really relevant to Android.

It's a waste of time to try convincing me that it's useful elsewhere. I
never said or implied that it wasn't.

On Thu, 2017-11-30 at 09:50 +0100, Djalal Harouni wrote:
> On Thu, Nov 30, 2017 at 7:51 AM, Daniel Micay 
> wrote:
> [...]
> > Lots of potential module attack surface also gets eliminated by
> > default
> > via their SELinux whitelists for /dev, /sys, /proc, debugfs, ioctl
> > commands, etc. The global seccomp whitelist might be relevant in
> > some
> > cases too.
> 
> In embedded systems we can't maintain a SELinux policy, distro man
> power hardly manage. We have abstracted seccomp etc, but the kernel
> inherited the difficult multiplex things, plus all other paths that
> trigger this.

It's cheaper to use an existing system like Android Things where device
makers only need to make their apps and perhaps some userspace hardware
drivers for cases not covered by mainline kernel drivers. I don't think
it makes sense for every device vendor to manage an OS and I seriously
doubt that's how the ecosystem is going to end up as it matures.

> > Android devices like to build everything into the kernel too, so
> > even if
> > they weren't using a module this feature wouldn't usually help them.
> > It
> > would need to work like this existing sysctl:
> > 
> > net.ipv4.tcp_available_congestion_control = cubic reno lp
> > 
> > i.e. whitelists for functionality offered by the modules, not just
> > whether they can be loaded.
> 
> Yes, but it is hard to maintain a whitelist policy, the code is hardly
> maintained... if you include everything you should have an LSM policy
> or something like that, and compiling kernels is expert thing.

I'm not talking about whitelist vs. blacklist, compiling kernels or
anything like that.

> Otherwise IMHO the kernel should provide default secure behaviour on
> how to load or add new functionality to the running one. From a user
> perspective, a switch "yes/no" that a privileged entity will
> *understand* and assume is what should be there, and the switch or
> flag as discussed here is local to processes, the sysctl will be
> removed. IMO it should come from userspace point of view, cause as an
> example the sysctl:
> 
> net.ipv4.tcp_available_congestion_control = cubic reno lp
> 
> Is kernel thing, too technical, userspace developers, admins or
> privileged entity will not understand what cubic or reno mean.

Congestion control algorithms are being used as an example in terms of
the mechanism being used to control which are available to unprivileged
users. The obscurity of congestion control algorithms is irrelevant.

>  Doing
> the same per functionality directly like this seems to much of a
> burden compared to the use case. The kernel maybe can do this to
> advance the art of the networking stack and for advanced cases, but in
> IMHO a sane default behaviour + an abstracted process/sandbox flag
> "yes/no" for most others, userspace developers and humans is what
> should be provided and we need the kernel to help here.

There are cases where unprivileged module auto-loading is relied upon
like network protocols. Having configuration for which protocols can be
used by unprivileged users is superior to limiting only which ones can
be auto-loaded. That's why I bought up the existing congestion control
knob. It works well in terms of having a whitelist of the sane, widely
used cases with exposing anything obscure requiring configuration. They
happen to be implemented as modules too.

Killing off unprivileged module loading other than a few cases like that
makes sense, and then those can provide similar control with similarly
sane defaults.

[PATCH 3/4] arm: dts: imx28: Rearrange nodes for better readability

[venkataravi . e]

From: Ravi Eluri 

Moved regulator, sound, leds, backlight nodes to the top of the
device tree, cleaned up for better readability.

Signed-off-by: Ravi Eluri 
Signed-off-by: Suniel Mahesh 
---
Note:
- This is the third patch of the four patch series.
- Patch was compile tested and built(ARCH=arm, imx28) on linux-next
  (latest).
- No build issues reported.
- Please discard this changeset, if this is not making any better.
---
 arch/arm/boot/dts/imx28-evk.dts | 203 
 1 file changed, 101 insertions(+), 102 deletions(-)

diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index 28564864..9d74486 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -20,6 +20,107 @@
reg = <0x4000 0x0800>;
};
 
+   regulators {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg_3p3v: regulator@0 {
+   compatible = "regulator-fixed";
+   reg = <0>;
+   regulator-name = "3P3V";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   };
+
+   reg_vddio_sd0: regulator@1 {
+   compatible = "regulator-fixed";
+   reg = <1>;
+   regulator-name = "vddio-sd0";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = < 28 0>;
+   };
+
+   reg_fec_3v3: regulator@2 {
+   compatible = "regulator-fixed";
+   reg = <2>;
+   regulator-name = "fec-3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = < 15 0>;
+   };
+
+   reg_usb0_vbus: regulator@3 {
+   compatible = "regulator-fixed";
+   reg = <3>;
+   regulator-name = "usb0_vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = < 9 0>;
+   enable-active-high;
+   };
+
+   reg_usb1_vbus: regulator@4 {
+   compatible = "regulator-fixed";
+   reg = <4>;
+   regulator-name = "usb1_vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = < 8 0>;
+   enable-active-high;
+   };
+
+   reg_lcd_3v3: regulator@5 {
+   compatible = "regulator-fixed";
+   reg = <5>;
+   regulator-name = "lcd-3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = < 30 0>;
+   enable-active-high;
+   };
+
+   reg_can_3v3: regulator@6 {
+   compatible = "regulator-fixed";
+   reg = <6>;
+   regulator-name = "can-3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = < 13 0>;
+   enable-active-high;
+   };
+   };
+
+   sound {
+   compatible = "fsl,imx28-evk-sgtl5000",
+"fsl,mxs-audio-sgtl5000";
+   model = "imx28-evk-sgtl5000";
+   saif-controllers = < >;
+   audio-codec = <>;
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pin_gpio3_5>;
+
+   user {
+   label = "Heartbeat";
+   gpios = < 5 0>;
+   linux,default-trigger = "heartbeat";
+   };
+   };
+
+   backlight {
+   compatible = "pwm-backlight";
+   pwms = < 2 500>;
+   brightness-levels = <0 4 8 16 32 64 128 255>;
+   default-brightness-level = <6>;
+   };
+};
+
 {
pinctrl-names = "default";
pinctrl-0 = <_pins_a _status_cfg
@@ -266,105 +367,3 @@
pinctrl-0 = <_pins_a>;
status = "okay";
};
-
-   regulators {
-   compatible = "simple-bus";
-   #address-cells = <1>;
-   #size-cells = 

[PATCH 2/4] arm: dts: imx28: Remove system bus unit addresses

[venkataravi . e]

From: Ravi Eluri 

Unit addresses for the system buses of imx28 are defined in
the corresponding dtsi file. Any peripheral node on APBH, APBX
and AHB busses can be accessed via phandle. Removed duplicate
system bus unit address entries, this makes the DT more robust
and readable.

Signed-off-by: Ravi Eluri 
Signed-off-by: Suniel Mahesh 
---
Note:
- This is the second patch of the four patch series.
- Patch was compile tested and built(ARCH=arm, imx28) on linux-next
  (latest).
- No build issues reported.
- Please discard this changeset, if this is not making any better.
---
 arch/arm/boot/dts/imx28-evk.dts | 8 
 1 file changed, 8 deletions(-)

diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index 21ac4fa..28564864 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -20,8 +20,6 @@
reg = <0x4000 0x0800>;
};
 
-   apb@8000 {
-   apbh@8000 {
 {
pinctrl-names = "default";
pinctrl-0 = <_pins_a _status_cfg
@@ -165,9 +163,7 @@
xceiver-supply = <_can_3v3>;
status = "okay";
};
-   };
 
-   apbx@8004 {
 {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
@@ -241,10 +237,7 @@
 {
status = "okay";
};
-   };
-   };
 
-   ahb@8008 {
 {
pinctrl-names = "default";
pinctrl-0 = <_id_pins_a>;
@@ -273,7 +266,6 @@
pinctrl-0 = <_pins_a>;
status = "okay";
};
-   };
 
regulators {
compatible = "simple-bus";
-- 
1.9.1

[PATCH 2/4] arm: dts: imx28: Remove system bus unit addresses

[venkataravi . e]

From: Ravi Eluri 

Unit addresses for the system buses of imx28 are defined in
the corresponding dtsi file. Any peripheral node on APBH, APBX
and AHB busses can be accessed via phandle. Removed duplicate
system bus unit address entries, this makes the DT more robust
and readable.

Signed-off-by: Ravi Eluri 
Signed-off-by: Suniel Mahesh 
---
Note:
- This is the second patch of the four patch series.
- Patch was compile tested and built(ARCH=arm, imx28) on linux-next
  (latest).
- No build issues reported.
- Please discard this changeset, if this is not making any better.
---
 arch/arm/boot/dts/imx28-evk.dts | 8 
 1 file changed, 8 deletions(-)

diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index 21ac4fa..28564864 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -20,8 +20,6 @@
reg = <0x4000 0x0800>;
};
 
-   apb@8000 {
-   apbh@8000 {
 {
pinctrl-names = "default";
pinctrl-0 = <_pins_a _status_cfg
@@ -165,9 +163,7 @@
xceiver-supply = <_can_3v3>;
status = "okay";
};
-   };
 
-   apbx@8004 {
 {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
@@ -241,10 +237,7 @@
 {
status = "okay";
};
-   };
-   };
 
-   ahb@8008 {
 {
pinctrl-names = "default";
pinctrl-0 = <_id_pins_a>;
@@ -273,7 +266,6 @@
pinctrl-0 = <_pins_a>;
status = "okay";
};
-   };
 
regulators {
compatible = "simple-bus";
-- 
1.9.1

[PATCH 0/4] arm: dts: imx28: imx28-evk device tree cleanup

[venkataravi . e]

From: Ravi Eluri 

Removed lot of redundant device tree syntax from imx28-evk device tree
to make it more robust and readable.

Total four changesets and are described as follows:

Changeset 1 removes unit addresses for all peripherals of imx28 in
imx28-evk DT as they are already defined in the corresponding dtsi file.
Make use of phandles reference peripheral nodes in dts files.

Changeset 2 removes unit addresses for the system buses of imx28 as they
are already defined in the corresponding dtsi file.

Changeset 3 rearranges nodes for better readability.

Changeset 4 does DT cleanup (whitespaces, tabs ...)

Note:
- Changesets were compile tested and built(ARCH=arm, imx28) on linux-next 
  (latest).
- No build issues reported.
- Please discard this changesets, if this is not making any better."

Ravi Eluri (4):
  arm: dts: imx28: Use phandles instead of unit addresses
  arm: dts: imx28: Remove system bus unit addresses
  arm: dts: imx28: Rearrange nodes for better readability
  arm: dts: imx28: Device tree cleanup

 arch/arm/boot/dts/imx28-evk.dts | 503 
 1 file changed, 247 insertions(+), 256 deletions(-)

-- 
1.9.1

[PATCH 0/4] arm: dts: imx28: imx28-evk device tree cleanup

[venkataravi . e]

From: Ravi Eluri 

Removed lot of redundant device tree syntax from imx28-evk device tree
to make it more robust and readable.

Total four changesets and are described as follows:

Changeset 1 removes unit addresses for all peripherals of imx28 in
imx28-evk DT as they are already defined in the corresponding dtsi file.
Make use of phandles reference peripheral nodes in dts files.

Changeset 2 removes unit addresses for the system buses of imx28 as they
are already defined in the corresponding dtsi file.

Changeset 3 rearranges nodes for better readability.

Changeset 4 does DT cleanup (whitespaces, tabs ...)

Note:
- Changesets were compile tested and built(ARCH=arm, imx28) on linux-next 
  (latest).
- No build issues reported.
- Please discard this changesets, if this is not making any better."

Ravi Eluri (4):
  arm: dts: imx28: Use phandles instead of unit addresses
  arm: dts: imx28: Remove system bus unit addresses
  arm: dts: imx28: Rearrange nodes for better readability
  arm: dts: imx28: Device tree cleanup

 arch/arm/boot/dts/imx28-evk.dts | 503 
 1 file changed, 247 insertions(+), 256 deletions(-)

-- 
1.9.1

[PATCH 1/6] x86/orc: Don't bail on stack overflow

[Andy Lutomirski]

If we overflow the stack into a guard page and then try to unwind it
with ORC, it should work well: by construction, there can't be any
meaningful data in the guard page because no writes to the guard page
will have succeeded.

This patch fixes a bug that unwinding from working correctly: if the
starting register state has RSP pointing into a stack guard page, the
ORC unwinder bails out immediately.  This patch fixes that: the ORC
unwinder will start the unwind.

I tested this by intentionally overflowing the task stack.  The
result is an accurate call trace instead of a trace consisting
purely of '?' entries.

There are a few other bugs that are triggered if the unwinder
encounters a stack overflow after the first step, and Josh has WIP
patches to fix those as well.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/kernel/unwind_orc.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/unwind_orc.c b/arch/x86/kernel/unwind_orc.c
index a3f973b2c97a..ff8e1132b2ae 100644
--- a/arch/x86/kernel/unwind_orc.c
+++ b/arch/x86/kernel/unwind_orc.c
@@ -553,8 +553,18 @@ void __unwind_start(struct unwind_state *state, struct 
task_struct *task,
}
 
if (get_stack_info((unsigned long *)state->sp, state->task,
-  >stack_info, >stack_mask))
-   return;
+  >stack_info, >stack_mask)) {
+   /*
+* We weren't on a valid stack.  It's possible that
+* we overflowed a valid stack into a guard page.
+* See if the next page up is valid so that we can
+* generate some kind of backtrace if this happens.
+*/
+   void *next_page = (void *)PAGE_ALIGN((unsigned long)state->sp);
+   if (get_stack_info(next_page, state->task, >stack_info,
+  >stack_mask))
+   return;
+   }
 
/*
 * The caller can provide the address of the first frame directly
-- 
2.13.6

[PATCH 1/6] x86/orc: Don't bail on stack overflow

[Andy Lutomirski]

If we overflow the stack into a guard page and then try to unwind it
with ORC, it should work well: by construction, there can't be any
meaningful data in the guard page because no writes to the guard page
will have succeeded.

This patch fixes a bug that unwinding from working correctly: if the
starting register state has RSP pointing into a stack guard page, the
ORC unwinder bails out immediately.  This patch fixes that: the ORC
unwinder will start the unwind.

I tested this by intentionally overflowing the task stack.  The
result is an accurate call trace instead of a trace consisting
purely of '?' entries.

There are a few other bugs that are triggered if the unwinder
encounters a stack overflow after the first step, and Josh has WIP
patches to fix those as well.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/kernel/unwind_orc.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/unwind_orc.c b/arch/x86/kernel/unwind_orc.c
index a3f973b2c97a..ff8e1132b2ae 100644
--- a/arch/x86/kernel/unwind_orc.c
+++ b/arch/x86/kernel/unwind_orc.c
@@ -553,8 +553,18 @@ void __unwind_start(struct unwind_state *state, struct 
task_struct *task,
}
 
if (get_stack_info((unsigned long *)state->sp, state->task,
-  >stack_info, >stack_mask))
-   return;
+  >stack_info, >stack_mask)) {
+   /*
+* We weren't on a valid stack.  It's possible that
+* we overflowed a valid stack into a guard page.
+* See if the next page up is valid so that we can
+* generate some kind of backtrace if this happens.
+*/
+   void *next_page = (void *)PAGE_ALIGN((unsigned long)state->sp);
+   if (get_stack_info(next_page, state->task, >stack_info,
+  >stack_mask))
+   return;
+   }
 
/*
 * The caller can provide the address of the first frame directly
-- 
2.13.6