Re: [RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

[Viresh Kumar]

On 17-07-17, 12:34, Rob Herring wrote:
> On Thu, Jul 13, 2017 at 03:06:08PM +0530, Viresh Kumar wrote:
> > On 12-07-17, 16:28, Rob Herring wrote:
> > > Display is a pretty well known use case here. Do you have other
> > > examples in mind?
> > 
> > No, I don't.
> > 
> > @Stephen: Do you have more cases like this for your Qcom products ?
> > 
> > > Other cases I've seen are automotive with keeping
> > > the backup camera going and CAN bus handling. Though my new car has a
> > > flicker shortly after coming on, so I guess the handoff doesn't have
> > > to be completely seemless. :)
> > 
> > :)
> > 
> > > [...]
> > > 
> > > > +   mmc: mmc@0x0 {
> > > > +   ...
> > > > +   ...
> > > > +   vmmc-supply = <_reg1>;
> > > > +   vmmcaux-supply = <_reg2>;
> > > > +   boot-constraint-supplies = "vmmc", "vmmcaux";
> > > > +   boot-constraint-uV = <180 200>, /* vmmc */
> > > > +<200 200>; /* vmmcaux */
> > > 
> > > No. I don't like how this is going to extend to all the other bindings
> > > people are going to want constraints for. We don't need a parallel set
> > > of properties for each type of binding.
> > 
> > Fair enough.
> > 
> > > I'm not convinced that we need a general solution for what's probably
> > > a handful of things that need a handoff versus just re-initialize.
> > 
> > What about keeping the first four patches (mostly) as it is and adding
> > these constraints from a platform specific constraints driver ?
> > 
> > Will that be acceptable ?
> 
> Meaning no DT binding? Then I don't care (from a DT perspective).

Yeah, kind of the way we decided to do the first step in the
power domain performance state series [1].

And then later on we can see how to get such information from DT, as
the kernel needs this information irrespective of the way we solve
this problem in the kernel.

-- 
viresh

[1] https://marc.info/?l=linux-kernel=149802907711074=2

Re: [RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

[Viresh Kumar]

On 17-07-17, 12:34, Rob Herring wrote:
> On Thu, Jul 13, 2017 at 03:06:08PM +0530, Viresh Kumar wrote:
> > On 12-07-17, 16:28, Rob Herring wrote:
> > > Display is a pretty well known use case here. Do you have other
> > > examples in mind?
> > 
> > No, I don't.
> > 
> > @Stephen: Do you have more cases like this for your Qcom products ?
> > 
> > > Other cases I've seen are automotive with keeping
> > > the backup camera going and CAN bus handling. Though my new car has a
> > > flicker shortly after coming on, so I guess the handoff doesn't have
> > > to be completely seemless. :)
> > 
> > :)
> > 
> > > [...]
> > > 
> > > > +   mmc: mmc@0x0 {
> > > > +   ...
> > > > +   ...
> > > > +   vmmc-supply = <_reg1>;
> > > > +   vmmcaux-supply = <_reg2>;
> > > > +   boot-constraint-supplies = "vmmc", "vmmcaux";
> > > > +   boot-constraint-uV = <180 200>, /* vmmc */
> > > > +<200 200>; /* vmmcaux */
> > > 
> > > No. I don't like how this is going to extend to all the other bindings
> > > people are going to want constraints for. We don't need a parallel set
> > > of properties for each type of binding.
> > 
> > Fair enough.
> > 
> > > I'm not convinced that we need a general solution for what's probably
> > > a handful of things that need a handoff versus just re-initialize.
> > 
> > What about keeping the first four patches (mostly) as it is and adding
> > these constraints from a platform specific constraints driver ?
> > 
> > Will that be acceptable ?
> 
> Meaning no DT binding? Then I don't care (from a DT perspective).

Yeah, kind of the way we decided to do the first step in the
power domain performance state series [1].

And then later on we can see how to get such information from DT, as
the kernel needs this information irrespective of the way we solve
this problem in the kernel.

-- 
viresh

[1] https://marc.info/?l=linux-kernel=149802907711074=2

Re: [PATCH] staging: iio: adc: add space around substraction operation

[Jonathan Cameron]

On 18 July 2017 06:38:08 BST, Hari Prasath  wrote:
>Fix checkpatch warning to add space around the substraction operation
>
>Signed-off-by: Hari Prasath 
>---
> drivers/staging/iio/adc/ad7280a.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/staging/iio/adc/ad7280a.c
>b/drivers/staging/iio/adc/ad7280a.c
>index d5ab83f..d79e774 100644
>--- a/drivers/staging/iio/adc/ad7280a.c
>+++ b/drivers/staging/iio/adc/ad7280a.c
>@@ -745,14 +745,14 @@ static irqreturn_t ad7280_event_handler(int irq,
>void *private)
> }
> 
> static IIO_DEVICE_ATTR_NAMED(in_thresh_low_value,
>-  in_voltage-voltage_thresh_low_value,
>+  in_voltage - voltage_thresh_low_value,
>   0644,
>   ad7280_read_channel_config,
>   ad7280_write_channel_config,
>   AD7280A_CELL_UNDERVOLTAGE);
> 
> static IIO_DEVICE_ATTR_NAMED(in_thresh_high_value,
>-  in_voltage-voltage_thresh_high_value,
>+  in_voltage - voltage_thresh_high_value,
>   0644,
>   ad7280_read_channel_config,
>   ad7280_write_channel_config,

Check what this code actually does. 
Using checkpatch gives suggestions of where
to look for issues; it is not always right!

This change breaks the userspace ABI.

Jonathan

Ps when ever  I see a patch involving whitespace and this driver I know I am 
going to give roughly
this response having done so perhaps 10 times in the past!  

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [PATCH] staging: iio: adc: add space around substraction operation

[Jonathan Cameron]

On 18 July 2017 06:38:08 BST, Hari Prasath  wrote:
>Fix checkpatch warning to add space around the substraction operation
>
>Signed-off-by: Hari Prasath 
>---
> drivers/staging/iio/adc/ad7280a.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/staging/iio/adc/ad7280a.c
>b/drivers/staging/iio/adc/ad7280a.c
>index d5ab83f..d79e774 100644
>--- a/drivers/staging/iio/adc/ad7280a.c
>+++ b/drivers/staging/iio/adc/ad7280a.c
>@@ -745,14 +745,14 @@ static irqreturn_t ad7280_event_handler(int irq,
>void *private)
> }
> 
> static IIO_DEVICE_ATTR_NAMED(in_thresh_low_value,
>-  in_voltage-voltage_thresh_low_value,
>+  in_voltage - voltage_thresh_low_value,
>   0644,
>   ad7280_read_channel_config,
>   ad7280_write_channel_config,
>   AD7280A_CELL_UNDERVOLTAGE);
> 
> static IIO_DEVICE_ATTR_NAMED(in_thresh_high_value,
>-  in_voltage-voltage_thresh_high_value,
>+  in_voltage - voltage_thresh_high_value,
>   0644,
>   ad7280_read_channel_config,
>   ad7280_write_channel_config,

Check what this code actually does. 
Using checkpatch gives suggestions of where
to look for issues; it is not always right!

This change breaks the userspace ABI.

Jonathan

Ps when ever  I see a patch involving whitespace and this driver I know I am 
going to give roughly
this response having done so perhaps 10 times in the past!  

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [PATCH] arm64: defconfig: enable CONFIG_UNIPHIER_WATCHDOG

[Masahiro Yamada]

2017-07-18 14:24 GMT+09:00 Keiji Hayashibara :
> Enable the watchdog driver for UniPhier SoC
>
> Signed-off-by: Keiji Hayashibara 
> ---
>  arch/arm64/configs/defconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 6c7d147..5d204a4 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -310,6 +310,7 @@ CONFIG_WATCHDOG=y
>  CONFIG_S3C2410_WATCHDOG=y
>  CONFIG_MESON_GXBB_WATCHDOG=m
>  CONFIG_MESON_WATCHDOG=m
> +CONFIG_UNIPHIER_WATCHDOG=y
>  CONFIG_RENESAS_WDT=y
>  CONFIG_BCM2835_WDT=y
>  CONFIG_MFD_CROS_EC=y


Please add CONFIG_UNIPHIER_WATCHDOG=y
below CONFIG_RENESAS_WDT=y

It is the order preferred by "make savedefconfig".

Re: [PATCH] arm64: defconfig: enable CONFIG_UNIPHIER_WATCHDOG

[Masahiro Yamada]

2017-07-18 14:24 GMT+09:00 Keiji Hayashibara :
> Enable the watchdog driver for UniPhier SoC
>
> Signed-off-by: Keiji Hayashibara 
> ---
>  arch/arm64/configs/defconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 6c7d147..5d204a4 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -310,6 +310,7 @@ CONFIG_WATCHDOG=y
>  CONFIG_S3C2410_WATCHDOG=y
>  CONFIG_MESON_GXBB_WATCHDOG=m
>  CONFIG_MESON_WATCHDOG=m
> +CONFIG_UNIPHIER_WATCHDOG=y
>  CONFIG_RENESAS_WDT=y
>  CONFIG_BCM2835_WDT=y
>  CONFIG_MFD_CROS_EC=y


Please add CONFIG_UNIPHIER_WATCHDOG=y
below CONFIG_RENESAS_WDT=y

It is the order preferred by "make savedefconfig".

Re: [PATCH 3/3] hwrng: mxc-fsl - add support for Freescale RNGC

[PrasannaKumar Muralidharan]

Hi Martin,

On 18 July 2017 at 02:46, Martin Kaiser  wrote:
> From: Steffen Trumtrar 
>
> The driver is ported from Freescales Linux git and can be
> found in the
>
> vendor/freescale/imx_2.6.35_maintain
>
> branch.
>
> According to that code, the RNGC is found on Freescales i.MX3/5 SoCs.
> The i.MX2x actually has an RNGB, which has no driver implementation
> in Freescales kernel. However as it turns out, the driver for the RNGC
> works fine on the (at least) i.MX25. So, they seem to be somewhat
> compatible.
>
> Signed-off-by: Steffen Trumtrar 
> Signed-off-by: Martin Kaiser 
> ---
> Changes in v3:
>- use pdev->dev to request the irq, rngc->dev is not yet initialized
>- remove unused defines for registers and fields
>- use module_platform_driver_probe()
>- clean up the error handling in the probe function,
>  disable the clock if necessary
>- self-test must succeed in the first run
>- check for errors after seeding, exit for errors unrelated to
>  statistics
>- set a timeout when waiting for a completion
>
> Changes in v2:
>   - remove irq variable from private struct
>   - move devm_request_irq from mxc_rngc_init to probe
>   - return irq in case of error
>   - handle irq 0 as error
>
>  drivers/char/hw_random/Kconfig|  13 ++
>  drivers/char/hw_random/Makefile   |   1 +
>  drivers/char/hw_random/mxc-rngc.c | 351 
> ++
>  3 files changed, 365 insertions(+)
>  create mode 100644 drivers/char/hw_random/mxc-rngc.c
>
> diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
> index 1b223c3..ef057b7 100644
> --- a/drivers/char/hw_random/Kconfig
> +++ b/drivers/char/hw_random/Kconfig
> @@ -255,6 +255,19 @@ config HW_RANDOM_MXC_RNGA
>
>   If unsure, say Y.
>
> +config HW_RANDOM_MXC_RNGC
> +   tristate "Freescale i.MX RNGC Random Number Generator"
> +   depends on ARCH_MXC
> +   default HW_RANDOM
> +   ---help---
> + This driver provides kernel-side support for the Random Number
> + Generator hardware found on some Freescale i.MX processors.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called mxc-rngc.
> +
> + If unsure, say Y.
> +
>  config HW_RANDOM_NOMADIK
> tristate "ST-Ericsson Nomadik Random Number Generator support"
> depends on ARCH_NOMADIK
> diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
> index b085975..043b71d 100644
> --- a/drivers/char/hw_random/Makefile
> +++ b/drivers/char/hw_random/Makefile
> @@ -20,6 +20,7 @@ obj-$(CONFIG_HW_RANDOM_PASEMI) += pasemi-rng.o
>  obj-$(CONFIG_HW_RANDOM_VIRTIO) += virtio-rng.o
>  obj-$(CONFIG_HW_RANDOM_TX4939) += tx4939-rng.o
>  obj-$(CONFIG_HW_RANDOM_MXC_RNGA) += mxc-rnga.o
> +obj-$(CONFIG_HW_RANDOM_MXC_RNGC) += mxc-rngc.o
>  obj-$(CONFIG_HW_RANDOM_OCTEON) += octeon-rng.o
>  obj-$(CONFIG_HW_RANDOM_NOMADIK) += nomadik-rng.o
>  obj-$(CONFIG_HW_RANDOM_PSERIES) += pseries-rng.o
> diff --git a/drivers/char/hw_random/mxc-rngc.c 
> b/drivers/char/hw_random/mxc-rngc.c
> new file mode 100644
> index 000..56175b1
> --- /dev/null
> +++ b/drivers/char/hw_random/mxc-rngc.c
> @@ -0,0 +1,351 @@
> +/*
> + * RNG driver for Freescale RNGC
> + *
> + * Copyright (C) 2008-2012 Freescale Semiconductor, Inc.
> + */
> +
> +/*
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */

Please combine above 2 comments.

> +
> +/*
> + * Hardware driver for the Intel/AMD/VIA Random Number Generators (RNG)
> + * (c) Copyright 2003 Red Hat Inc 
> + *
> + * derived from
> + *
> + * Hardware driver for the AMD 768 Random Number Generator (RNG)
> + * (c) Copyright 2001 Red Hat Inc 
> + *
> + * derived from
> + *
> + * Hardware driver for Intel i810 Random Number Generator (RNG)
> + * Copyright 2000,2001 Jeff Garzik 
> + * Copyright 2000,2001 Philipp Rumpf 
> + *
> + * This file is licensed under  the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */

I feel this comment is because of copy paste. If that's the case please remove.

> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define RNGC_COMMAND   0x0004
> +#define RNGC_CONTROL   0x0008
> +#define RNGC_STATUS0x000C
> +#define RNGC_ERROR 0x0010
> +#define RNGC_FIFO   

Re: [PATCH 3/3] hwrng: mxc-fsl - add support for Freescale RNGC

[PrasannaKumar Muralidharan]

Hi Martin,

On 18 July 2017 at 02:46, Martin Kaiser  wrote:
> From: Steffen Trumtrar 
>
> The driver is ported from Freescales Linux git and can be
> found in the
>
> vendor/freescale/imx_2.6.35_maintain
>
> branch.
>
> According to that code, the RNGC is found on Freescales i.MX3/5 SoCs.
> The i.MX2x actually has an RNGB, which has no driver implementation
> in Freescales kernel. However as it turns out, the driver for the RNGC
> works fine on the (at least) i.MX25. So, they seem to be somewhat
> compatible.
>
> Signed-off-by: Steffen Trumtrar 
> Signed-off-by: Martin Kaiser 
> ---
> Changes in v3:
>- use pdev->dev to request the irq, rngc->dev is not yet initialized
>- remove unused defines for registers and fields
>- use module_platform_driver_probe()
>- clean up the error handling in the probe function,
>  disable the clock if necessary
>- self-test must succeed in the first run
>- check for errors after seeding, exit for errors unrelated to
>  statistics
>- set a timeout when waiting for a completion
>
> Changes in v2:
>   - remove irq variable from private struct
>   - move devm_request_irq from mxc_rngc_init to probe
>   - return irq in case of error
>   - handle irq 0 as error
>
>  drivers/char/hw_random/Kconfig|  13 ++
>  drivers/char/hw_random/Makefile   |   1 +
>  drivers/char/hw_random/mxc-rngc.c | 351 
> ++
>  3 files changed, 365 insertions(+)
>  create mode 100644 drivers/char/hw_random/mxc-rngc.c
>
> diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
> index 1b223c3..ef057b7 100644
> --- a/drivers/char/hw_random/Kconfig
> +++ b/drivers/char/hw_random/Kconfig
> @@ -255,6 +255,19 @@ config HW_RANDOM_MXC_RNGA
>
>   If unsure, say Y.
>
> +config HW_RANDOM_MXC_RNGC
> +   tristate "Freescale i.MX RNGC Random Number Generator"
> +   depends on ARCH_MXC
> +   default HW_RANDOM
> +   ---help---
> + This driver provides kernel-side support for the Random Number
> + Generator hardware found on some Freescale i.MX processors.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called mxc-rngc.
> +
> + If unsure, say Y.
> +
>  config HW_RANDOM_NOMADIK
> tristate "ST-Ericsson Nomadik Random Number Generator support"
> depends on ARCH_NOMADIK
> diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
> index b085975..043b71d 100644
> --- a/drivers/char/hw_random/Makefile
> +++ b/drivers/char/hw_random/Makefile
> @@ -20,6 +20,7 @@ obj-$(CONFIG_HW_RANDOM_PASEMI) += pasemi-rng.o
>  obj-$(CONFIG_HW_RANDOM_VIRTIO) += virtio-rng.o
>  obj-$(CONFIG_HW_RANDOM_TX4939) += tx4939-rng.o
>  obj-$(CONFIG_HW_RANDOM_MXC_RNGA) += mxc-rnga.o
> +obj-$(CONFIG_HW_RANDOM_MXC_RNGC) += mxc-rngc.o
>  obj-$(CONFIG_HW_RANDOM_OCTEON) += octeon-rng.o
>  obj-$(CONFIG_HW_RANDOM_NOMADIK) += nomadik-rng.o
>  obj-$(CONFIG_HW_RANDOM_PSERIES) += pseries-rng.o
> diff --git a/drivers/char/hw_random/mxc-rngc.c 
> b/drivers/char/hw_random/mxc-rngc.c
> new file mode 100644
> index 000..56175b1
> --- /dev/null
> +++ b/drivers/char/hw_random/mxc-rngc.c
> @@ -0,0 +1,351 @@
> +/*
> + * RNG driver for Freescale RNGC
> + *
> + * Copyright (C) 2008-2012 Freescale Semiconductor, Inc.
> + */
> +
> +/*
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */

Please combine above 2 comments.

> +
> +/*
> + * Hardware driver for the Intel/AMD/VIA Random Number Generators (RNG)
> + * (c) Copyright 2003 Red Hat Inc 
> + *
> + * derived from
> + *
> + * Hardware driver for the AMD 768 Random Number Generator (RNG)
> + * (c) Copyright 2001 Red Hat Inc 
> + *
> + * derived from
> + *
> + * Hardware driver for Intel i810 Random Number Generator (RNG)
> + * Copyright 2000,2001 Jeff Garzik 
> + * Copyright 2000,2001 Philipp Rumpf 
> + *
> + * This file is licensed under  the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */

I feel this comment is because of copy paste. If that's the case please remove.

> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define RNGC_COMMAND   0x0004
> +#define RNGC_CONTROL   0x0008
> +#define RNGC_STATUS0x000C
> +#define RNGC_ERROR 0x0010
> +#define RNGC_FIFO  0x0014
> +#define RNGC_VERIF_CTRL0x0020
> +#define RNGC_OSC_CTRL_COUNT0x0028
> +#define RNGC_OSC_COUNT 0x002C
> 

Re: [PATCH] drm/i915: disable KASAN for handlers

[Jiri Slaby]

On 03/31/2017, 01:23 PM, Arnd Bergmann wrote:
> On Fri, Mar 31, 2017 at 12:29 PM, Jani Nikula
>  wrote:
>> On Fri, 31 Mar 2017, Zhenyu Wang  wrote:
>>> On 2017.03.30 11:46:27 +0200, Jiri Slaby wrote:
 Handlers are currently the only blocker to compile the kernel with gcc 7
 and KASAN+use-after-scope enabled:
 drivers/gpu/drm/i915/gvt/handlers.c:2200:1: error: the frame size of 43760 
 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
 drivers/gpu/drm/i915/gvt/handlers.c:2402:1: error: the frame size of 9400 
 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
 drivers/gpu/drm/i915/gvt/handlers.c:2628:1: error: the frame size of 11256 
 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]

 It is due to many expansions of MMIO_* macros in init_generic_mmio_info.
 INTEL_GVT_MMIO_OFFSET generates for each such line a __reg and an
 offset. There are too many for KASAN to keep up.

 So disable KASAN for this file.

 Signed-off-by: Jiri Slaby 
 Cc: Martin Liska 
 Cc: Zhenyu Wang 
 Cc: Zhi Wang 
 Cc: Daniel Vetter 
 Cc: Jani Nikula 
 Cc: David Airlie 
 Cc: intel-gvt-...@lists.freedesktop.org
 Cc: intel-...@lists.freedesktop.org
 Cc: dri-de...@lists.freedesktop.org
 ---
  drivers/gpu/drm/i915/gvt/Makefile | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
 b/drivers/gpu/drm/i915/gvt/Makefile
 index b123c20e2097..942f1849d194 100644
 --- a/drivers/gpu/drm/i915/gvt/Makefile
 +++ b/drivers/gpu/drm/i915/gvt/Makefile
 @@ -6,3 +6,5 @@ GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o 
 trace_points.o firmware.o \
  ccflags-y   += -I$(src) -I$(src)/$(GVT_DIR) -Wall
  i915-y  += $(addprefix $(GVT_DIR)/, 
 $(GVT_SOURCE))
  obj-$(CONFIG_DRM_I915_GVT_KVMGT)+= $(GVT_DIR)/kvmgt.o
 +
 +KASAN_SANITIZE_handlers.o := n
 --
 2.12.2

>>>
>>> Applied this, we'd better cleanup legacy usage to current i915 mmio
>>> reg define. Thanks!
>>
>> Hmmh, that was a bit fast, there was a related discussion going in [1].
>>
>> BR,
>> Jani.
>>
>>
>> [1] http://mid.mail-archive.com/20170320215713.3086140-1-arnd@arndb.de
> 
> Sorry about that, it looked like I never replied to your last mail.
> 
> There is also a related problem that I had sent another fix for:
> https://patchwork.kernel.org/patch/9601349/
> 
> I still think that my two patches are correct and they should both be applied.

Hi,

have they been applied yet? Or was this fixed some other way?

thanks,
-- 
js
suse labs

Re: [PATCH] drm/i915: disable KASAN for handlers

[Jiri Slaby]

On 03/31/2017, 01:23 PM, Arnd Bergmann wrote:
> On Fri, Mar 31, 2017 at 12:29 PM, Jani Nikula
>  wrote:
>> On Fri, 31 Mar 2017, Zhenyu Wang  wrote:
>>> On 2017.03.30 11:46:27 +0200, Jiri Slaby wrote:
 Handlers are currently the only blocker to compile the kernel with gcc 7
 and KASAN+use-after-scope enabled:
 drivers/gpu/drm/i915/gvt/handlers.c:2200:1: error: the frame size of 43760 
 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
 drivers/gpu/drm/i915/gvt/handlers.c:2402:1: error: the frame size of 9400 
 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
 drivers/gpu/drm/i915/gvt/handlers.c:2628:1: error: the frame size of 11256 
 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]

 It is due to many expansions of MMIO_* macros in init_generic_mmio_info.
 INTEL_GVT_MMIO_OFFSET generates for each such line a __reg and an
 offset. There are too many for KASAN to keep up.

 So disable KASAN for this file.

 Signed-off-by: Jiri Slaby 
 Cc: Martin Liska 
 Cc: Zhenyu Wang 
 Cc: Zhi Wang 
 Cc: Daniel Vetter 
 Cc: Jani Nikula 
 Cc: David Airlie 
 Cc: intel-gvt-...@lists.freedesktop.org
 Cc: intel-...@lists.freedesktop.org
 Cc: dri-de...@lists.freedesktop.org
 ---
  drivers/gpu/drm/i915/gvt/Makefile | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
 b/drivers/gpu/drm/i915/gvt/Makefile
 index b123c20e2097..942f1849d194 100644
 --- a/drivers/gpu/drm/i915/gvt/Makefile
 +++ b/drivers/gpu/drm/i915/gvt/Makefile
 @@ -6,3 +6,5 @@ GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o 
 trace_points.o firmware.o \
  ccflags-y   += -I$(src) -I$(src)/$(GVT_DIR) -Wall
  i915-y  += $(addprefix $(GVT_DIR)/, 
 $(GVT_SOURCE))
  obj-$(CONFIG_DRM_I915_GVT_KVMGT)+= $(GVT_DIR)/kvmgt.o
 +
 +KASAN_SANITIZE_handlers.o := n
 --
 2.12.2

>>>
>>> Applied this, we'd better cleanup legacy usage to current i915 mmio
>>> reg define. Thanks!
>>
>> Hmmh, that was a bit fast, there was a related discussion going in [1].
>>
>> BR,
>> Jani.
>>
>>
>> [1] http://mid.mail-archive.com/20170320215713.3086140-1-arnd@arndb.de
> 
> Sorry about that, it looked like I never replied to your last mail.
> 
> There is also a related problem that I had sent another fix for:
> https://patchwork.kernel.org/patch/9601349/
> 
> I still think that my two patches are correct and they should both be applied.

Hi,

have they been applied yet? Or was this fixed some other way?

thanks,
-- 
js
suse labs

Re: [PATCHv2 0/6] Motorola Droid 4 Audio Support

[Tony Lindgren]

* Sebastian Reichel  [170717 07:14]:
> Hi,
> 
> On Mon, Jul 17, 2017 at 03:17:10AM -0700, Tony Lindgren wrote:
> > * Sebastian Reichel  [170717 03:13]:
> > > On Mon, Jul 17, 2017 at 02:29:04AM -0700, Tony Lindgren wrote:
> > > > * Sebastian Reichel  [170712 08:19]:
> > > > >  * Switch from simple-audio-card to audio-graph-card
> > > > 
> > > > Gave this a quick try against v4.13-rc1 with SND_AUDIO_GRAPH_CARD
> > > > enabled as a loadable module. However loading it oopses for me,
> > > > see below. Maybe some dependencies are missing?
> > > 
> > > It works for me on top of v4.13-rc1 (my kernel is monolithic).
> > > Looking at the stacktrace it seems to be a bug in audio graph
> > > card and not in the codec driver.
> > 
> > OK I do also have:
> > 
> > CONFIG_DEBUG_LOCKDEP=y
> > CONFIG_DEBUG_ATOMIC_SLEEP=y
> 
> I added those and I do not get a stacktrace for anything sound
> related and audio works. I noticed one issue in dapm routing,
> that I accidently added. That will be fixed in PATCHv3, but its
> in untestable path anyways (EXT capture, probably FM radio is
> connected to EXT).

Hmm maybe that was not with DEBUG_ATOMIC_SLEEP then? I also
verified it does not happen unless your dts patch
"ARM: dts: omap4-droid4: add soundcard" is applied.

I doubt that having it as loadable module makes any difference
here as it's the might_sleep() in __mutex_lock_common() producing
the BUG.

Regards,

Tony

Re: [PATCHv2 0/6] Motorola Droid 4 Audio Support

[Tony Lindgren]

* Sebastian Reichel  [170717 07:14]:
> Hi,
> 
> On Mon, Jul 17, 2017 at 03:17:10AM -0700, Tony Lindgren wrote:
> > * Sebastian Reichel  [170717 03:13]:
> > > On Mon, Jul 17, 2017 at 02:29:04AM -0700, Tony Lindgren wrote:
> > > > * Sebastian Reichel  [170712 08:19]:
> > > > >  * Switch from simple-audio-card to audio-graph-card
> > > > 
> > > > Gave this a quick try against v4.13-rc1 with SND_AUDIO_GRAPH_CARD
> > > > enabled as a loadable module. However loading it oopses for me,
> > > > see below. Maybe some dependencies are missing?
> > > 
> > > It works for me on top of v4.13-rc1 (my kernel is monolithic).
> > > Looking at the stacktrace it seems to be a bug in audio graph
> > > card and not in the codec driver.
> > 
> > OK I do also have:
> > 
> > CONFIG_DEBUG_LOCKDEP=y
> > CONFIG_DEBUG_ATOMIC_SLEEP=y
> 
> I added those and I do not get a stacktrace for anything sound
> related and audio works. I noticed one issue in dapm routing,
> that I accidently added. That will be fixed in PATCHv3, but its
> in untestable path anyways (EXT capture, probably FM radio is
> connected to EXT).

Hmm maybe that was not with DEBUG_ATOMIC_SLEEP then? I also
verified it does not happen unless your dts patch
"ARM: dts: omap4-droid4: add soundcard" is applied.

I doubt that having it as loadable module makes any difference
here as it's the might_sleep() in __mutex_lock_common() producing
the BUG.

Regards,

Tony

Re: [PATCH RFC v5] cpufreq: schedutil: Make iowait boost more energy efficient

[Viresh Kumar]

On 17-07-17, 10:35, Joel Fernandes wrote:
> On Mon, Jul 17, 2017 at 1:04 AM, Viresh Kumar  wrote:
> > On 16-07-17, 01:04, Joel Fernandes wrote:

> >> + if (sg_cpu->iowait_boost_pending) {
> >> + sg_cpu->iowait_boost_pending = false;
> >> + sg_cpu->iowait_boost = min(sg_cpu->iowait_boost << 1,
> >> +sg_cpu->iowait_boost_max);
> >
> > Now this has a problem. We will also boost after waiting for

s/also/always/

> > rate_limit_us. And that's why I had proposed the tricky solution in
> 
> Not really unless rate_limit_us is < TICK_NSEC? Once TICK_NSEC
> elapses, we would clear the boost in sugov_set_iowait_boost and in
> sugov_next_freq_shared.

You misread it and I know why it happened. And so I have sent a small
patch to make it a bit more readable.

rate_limit_us is associated with "last_freq_update_time", while
iowait-boost is associated with "last_update".

And last_update gets updated way too often.

> > the first place. I thought we wanted to avoid instant boost only for
> > the first iteration, but after that we wanted to do it ASAP. Isn't it?
> >
> > Now that you are using policy->min instead of policy->cur, we can
> > simplify the solution I proposed and always do 2 * iowait_boost before
> 
> No, doubling on the first boost was never discussed or intended in my
> earlier patches. I thought even your patch never did, you were
> dividing by 2, and then scaling it back up by 2 before consuming it to
> preserve the initial boost.
> 
> > getting current util/max in above if loop. i.e. we will start iowait
> > boost with min * 2 instead of min and that should be fine.
> 
> Hmm, but why start from double of min? Why not just min? It doesn't
> make any difference to the intended behavior itself and is also
> consistent with my proposal in RFC v4. Also I feel what you're
> suggesting is more spike prone as well, the idea was to start from the
> minimum and double it as we go, not to double the min the first go.
> That was never intended.
> 
> Also I would rather keep the "set and use and set and use" pattern to
> keep the logic less confusing and clean IMO.
> So we set initial boost in sugov_set_iowait_boost, and then in
> sugov_iowait_boost we use it, and then set the boost for the next time
> around at the end of sugov_iowait_boost (that is we double it). Next
> time sugov_set_iowait_boost wouldn't touch the boost whether iowait
> flag is set or not and we would continue into sugov_iowait_boost to
> consume the boost. This would have a small delay in reducing the
> boost, but that's Ok since its only one cycle of delay, and keeps the
> code clean. I assume the last part is not an issue considering you're
> proposing double of the initial boost anyway ;-)

Okay, let me try to explain the problem first and then you can propose
a solution if required.

Expected Behavior:

(Window refers to a time window of rate_limit_us here)

A. The first window where IOWAIT flag is set, we set boost to min-freq
   and that shall be used for next freq update in
   sugov_iowait_boost().  Any more calls to sugov_set_iowait_boost()
   within this window shouldn't change the behavior.

B. If the next window also has IOWAIT flag set, then
   sugov_iowait_boost() should use iowait*2 for freq update.

C. If a window doesn't have IOWAIT flag set, then sugov_iowait_boost()
   should use iowait/2 in it.


Do they look fine to you?

Now coming to how will system behave with your patch:

A. would be fine. We will follow things properly.

But B. and C. aren't true anymore.

This happened because after the first window we updated iowait_boost
as 2*min unconditionally and the next window will *always* use that,
even if the flag isn't set. And we may end up increasing the frequency
unnecessarily, i.e. the spike where this discussion started.

And so in my initial solution I reversed the order in
sugov_iowait_boost().

-- 
viresh

[PATCH] soc: TI knav_qmss: Fix spelling mistake "instace" -> "instance"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in dev_err messages and comments

Signed-off-by: Colin Ian King 
---
 drivers/soc/ti/knav_dma.c  | 4 ++--
 drivers/soc/ti/knav_qmss.h | 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/soc/ti/knav_dma.c b/drivers/soc/ti/knav_dma.c
index 026182d3b27c..f463e04be412 100644
--- a/drivers/soc/ti/knav_dma.c
+++ b/drivers/soc/ti/knav_dma.c
@@ -431,7 +431,7 @@ void *knav_dma_open_channel(struct device *dev, const char 
*name,
 
chan_num = of_channel_match_helper(dev->of_node, name, );
if (chan_num < 0) {
-   dev_err(kdev->dev, "No DMA instace with name %s\n", name);
+   dev_err(kdev->dev, "No DMA instance with name %s\n", name);
return (void *)-EINVAL;
}
 
@@ -454,7 +454,7 @@ void *knav_dma_open_channel(struct device *dev, const char 
*name,
}
}
if (!found) {
-   dev_err(kdev->dev, "No DMA instace with name %s\n", instance);
+   dev_err(kdev->dev, "No DMA instance with name %s\n", instance);
return (void *)-EINVAL;
}
 
diff --git a/drivers/soc/ti/knav_qmss.h b/drivers/soc/ti/knav_qmss.h
index 905b974d1bdc..0cc29bd6c219 100644
--- a/drivers/soc/ti/knav_qmss.h
+++ b/drivers/soc/ti/knav_qmss.h
@@ -238,14 +238,14 @@ struct knav_pool {
 };
 
 /**
- * struct knav_queue_inst: qmss queue instace properties
+ * struct knav_queue_inst: qmss queue instance properties
  * @descs: descriptor pointer
  * @desc_head, desc_tail, desc_count:  descriptor counters
  * @acc:   accumulator channel pointer
  * @kdev:  qmss device pointer
  * @range: range info
  * @qmgr:  queue manager info
- * @id:queue instace id
+ * @id:queue instance id
  * @irq_num:   irq line number
  * @notify_needed: notifier needed based on queue type
  * @num_notifiers: total notifiers
@@ -272,7 +272,7 @@ struct knav_queue_inst {
 /**
  * struct knav_queue:  qmss queue properties
  * @reg_push, reg_pop, reg_peek:   push, pop queue registers
- * @inst:  qmss queue instace properties
+ * @inst:  qmss queue instance properties
  * @notifier_fn:   notifier function
  * @notifier_fn_arg:   notifier function argument
  * @notifier_enabled:  notier enabled for a give queue
-- 
2.11.0

Re: [PATCH RFC v5] cpufreq: schedutil: Make iowait boost more energy efficient

[Viresh Kumar]

On 17-07-17, 10:35, Joel Fernandes wrote:
> On Mon, Jul 17, 2017 at 1:04 AM, Viresh Kumar  wrote:
> > On 16-07-17, 01:04, Joel Fernandes wrote:

> >> + if (sg_cpu->iowait_boost_pending) {
> >> + sg_cpu->iowait_boost_pending = false;
> >> + sg_cpu->iowait_boost = min(sg_cpu->iowait_boost << 1,
> >> +sg_cpu->iowait_boost_max);
> >
> > Now this has a problem. We will also boost after waiting for

s/also/always/

> > rate_limit_us. And that's why I had proposed the tricky solution in
> 
> Not really unless rate_limit_us is < TICK_NSEC? Once TICK_NSEC
> elapses, we would clear the boost in sugov_set_iowait_boost and in
> sugov_next_freq_shared.

You misread it and I know why it happened. And so I have sent a small
patch to make it a bit more readable.

rate_limit_us is associated with "last_freq_update_time", while
iowait-boost is associated with "last_update".

And last_update gets updated way too often.

> > the first place. I thought we wanted to avoid instant boost only for
> > the first iteration, but after that we wanted to do it ASAP. Isn't it?
> >
> > Now that you are using policy->min instead of policy->cur, we can
> > simplify the solution I proposed and always do 2 * iowait_boost before
> 
> No, doubling on the first boost was never discussed or intended in my
> earlier patches. I thought even your patch never did, you were
> dividing by 2, and then scaling it back up by 2 before consuming it to
> preserve the initial boost.
> 
> > getting current util/max in above if loop. i.e. we will start iowait
> > boost with min * 2 instead of min and that should be fine.
> 
> Hmm, but why start from double of min? Why not just min? It doesn't
> make any difference to the intended behavior itself and is also
> consistent with my proposal in RFC v4. Also I feel what you're
> suggesting is more spike prone as well, the idea was to start from the
> minimum and double it as we go, not to double the min the first go.
> That was never intended.
> 
> Also I would rather keep the "set and use and set and use" pattern to
> keep the logic less confusing and clean IMO.
> So we set initial boost in sugov_set_iowait_boost, and then in
> sugov_iowait_boost we use it, and then set the boost for the next time
> around at the end of sugov_iowait_boost (that is we double it). Next
> time sugov_set_iowait_boost wouldn't touch the boost whether iowait
> flag is set or not and we would continue into sugov_iowait_boost to
> consume the boost. This would have a small delay in reducing the
> boost, but that's Ok since its only one cycle of delay, and keeps the
> code clean. I assume the last part is not an issue considering you're
> proposing double of the initial boost anyway ;-)

Okay, let me try to explain the problem first and then you can propose
a solution if required.

Expected Behavior:

(Window refers to a time window of rate_limit_us here)

A. The first window where IOWAIT flag is set, we set boost to min-freq
   and that shall be used for next freq update in
   sugov_iowait_boost().  Any more calls to sugov_set_iowait_boost()
   within this window shouldn't change the behavior.

B. If the next window also has IOWAIT flag set, then
   sugov_iowait_boost() should use iowait*2 for freq update.

C. If a window doesn't have IOWAIT flag set, then sugov_iowait_boost()
   should use iowait/2 in it.


Do they look fine to you?

Now coming to how will system behave with your patch:

A. would be fine. We will follow things properly.

But B. and C. aren't true anymore.

This happened because after the first window we updated iowait_boost
as 2*min unconditionally and the next window will *always* use that,
even if the flag isn't set. And we may end up increasing the frequency
unnecessarily, i.e. the spike where this discussion started.

And so in my initial solution I reversed the order in
sugov_iowait_boost().

-- 
viresh

[PATCH] soc: TI knav_qmss: Fix spelling mistake "instace" -> "instance"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in dev_err messages and comments

Signed-off-by: Colin Ian King 
---
 drivers/soc/ti/knav_dma.c  | 4 ++--
 drivers/soc/ti/knav_qmss.h | 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/soc/ti/knav_dma.c b/drivers/soc/ti/knav_dma.c
index 026182d3b27c..f463e04be412 100644
--- a/drivers/soc/ti/knav_dma.c
+++ b/drivers/soc/ti/knav_dma.c
@@ -431,7 +431,7 @@ void *knav_dma_open_channel(struct device *dev, const char 
*name,
 
chan_num = of_channel_match_helper(dev->of_node, name, );
if (chan_num < 0) {
-   dev_err(kdev->dev, "No DMA instace with name %s\n", name);
+   dev_err(kdev->dev, "No DMA instance with name %s\n", name);
return (void *)-EINVAL;
}
 
@@ -454,7 +454,7 @@ void *knav_dma_open_channel(struct device *dev, const char 
*name,
}
}
if (!found) {
-   dev_err(kdev->dev, "No DMA instace with name %s\n", instance);
+   dev_err(kdev->dev, "No DMA instance with name %s\n", instance);
return (void *)-EINVAL;
}
 
diff --git a/drivers/soc/ti/knav_qmss.h b/drivers/soc/ti/knav_qmss.h
index 905b974d1bdc..0cc29bd6c219 100644
--- a/drivers/soc/ti/knav_qmss.h
+++ b/drivers/soc/ti/knav_qmss.h
@@ -238,14 +238,14 @@ struct knav_pool {
 };
 
 /**
- * struct knav_queue_inst: qmss queue instace properties
+ * struct knav_queue_inst: qmss queue instance properties
  * @descs: descriptor pointer
  * @desc_head, desc_tail, desc_count:  descriptor counters
  * @acc:   accumulator channel pointer
  * @kdev:  qmss device pointer
  * @range: range info
  * @qmgr:  queue manager info
- * @id:queue instace id
+ * @id:queue instance id
  * @irq_num:   irq line number
  * @notify_needed: notifier needed based on queue type
  * @num_notifiers: total notifiers
@@ -272,7 +272,7 @@ struct knav_queue_inst {
 /**
  * struct knav_queue:  qmss queue properties
  * @reg_push, reg_pop, reg_peek:   push, pop queue registers
- * @inst:  qmss queue instace properties
+ * @inst:  qmss queue instance properties
  * @notifier_fn:   notifier function
  * @notifier_fn_arg:   notifier function argument
  * @notifier_enabled:  notier enabled for a give queue
-- 
2.11.0

Re: panic, bisect to commit 7f1d4e58dabb "spmi: pmic-arb: optimize table lookups"

[Frank Rowand]

On 07/17/17 22:06, Frank Rowand wrote:
> On 07/17/17 20:56, Rajendra Nayak wrote:
>>
>> On 07/18/2017 09:12 AM, Frank Rowand wrote:
>>> Hi Abhijeet,
>>>
>>> My qcom-apq8074-dragonboard panics on boot on v4.13-rc1.
>>>
>>> I bisected the problem to commit 7f1d4e58dabb, "spmi: pmic-arb:
>>> optimize table lookups".
>>
>> there's a fix on its way upstream,
>> https://patchwork.kernel.org/patch/9810723/
>>
> 
> Thank you for the pointer to the patch.  After adding the patch, my
> board still does not boot, but now has several different stack
> dumps from various drivers.  I do not know if the new errors are
> related to this patch or something entirely different.  I'll dig
> into it tomorrow.

There is one more test I should have done before sending my previous
email.  I added the patch that is planned to fix the problem I
reported on top of:

  76b069b1cb20 spmi: spmi-pmic-arb: enable the SPMI interrupt as a wakeup source

which is the last patch in the series that included the patch that
I reported a problem with.  My board boots fine at that point,
so I am fairly confident that my further boot issues have yet
another cause, and that the fix on its way upstream should fix
the specific problem that I reported.

-Frank

Re: panic, bisect to commit 7f1d4e58dabb "spmi: pmic-arb: optimize table lookups"

[Frank Rowand]

On 07/17/17 22:06, Frank Rowand wrote:
> On 07/17/17 20:56, Rajendra Nayak wrote:
>>
>> On 07/18/2017 09:12 AM, Frank Rowand wrote:
>>> Hi Abhijeet,
>>>
>>> My qcom-apq8074-dragonboard panics on boot on v4.13-rc1.
>>>
>>> I bisected the problem to commit 7f1d4e58dabb, "spmi: pmic-arb:
>>> optimize table lookups".
>>
>> there's a fix on its way upstream,
>> https://patchwork.kernel.org/patch/9810723/
>>
> 
> Thank you for the pointer to the patch.  After adding the patch, my
> board still does not boot, but now has several different stack
> dumps from various drivers.  I do not know if the new errors are
> related to this patch or something entirely different.  I'll dig
> into it tomorrow.

There is one more test I should have done before sending my previous
email.  I added the patch that is planned to fix the problem I
reported on top of:

  76b069b1cb20 spmi: spmi-pmic-arb: enable the SPMI interrupt as a wakeup source

which is the last patch in the series that included the patch that
I reported a problem with.  My board boots fine at that point,
so I am fairly confident that my further boot issues have yet
another cause, and that the fix on its way upstream should fix
the specific problem that I reported.

-Frank

Re: [PATCH V6 5/7] crypto: AES CBC multi-buffer glue code

[Herbert Xu]

On Tue, Jun 27, 2017 at 05:26:13PM -0700, Megha Dey wrote:
>
> +static void completion_callback(struct mcryptd_skcipher_request_ctx *rctx,
> + struct mcryptd_alg_cstate *cstate,
> + int err)
> +{
> + struct skcipher_request *req = cast_mcryptd_ctx_to_req(rctx);
> +
> +   /* remove from work list and invoke completion callback */
> + spin_lock(>work_lock);
> + list_del(>waiter);
> + spin_unlock(>work_lock);
> +
> + if (irqs_disabled())
> + rctx->complete(>base, err);
> + else {
> + local_bh_disable();
> + rctx->complete(>base, err);
> + local_bh_enable();
> + }
> +}

The fact that you need to do this check means that this design is
wrong.  You should always know what context you are in.

> +/*
> + * CRYPTO_ALG_ASYNC flag is passed to indicate we have an ablk
> + * scatter-gather walk.
> + */
> +static struct skcipher_alg aes_cbc_mb_alg = {
> + .base = {
> + .cra_name   = "cbc(aes)",
> + .cra_driver_name= "cbc-aes-aesni-mb",
> + .cra_priority   = 500,
> + .cra_flags  = CRYPTO_ALG_INTERNAL,
> + .cra_blocksize  = AES_BLOCK_SIZE,
> + .cra_ctxsize= CRYPTO_AES_CTX_SIZE,
> + .cra_module = THIS_MODULE,
> + },
> + .min_keysize= AES_MIN_KEY_SIZE,
> + .max_keysize= AES_MAX_KEY_SIZE,
> + .ivsize = AES_BLOCK_SIZE,
> + .setkey = aes_set_key,
> + .encrypt= mb_aes_cbc_encrypt,
> + .decrypt= mb_aes_cbc_decrypt
> +};

So this claims to be a sync algorithm.  Is this really the case?

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH V6 5/7] crypto: AES CBC multi-buffer glue code

[Herbert Xu]

On Tue, Jun 27, 2017 at 05:26:13PM -0700, Megha Dey wrote:
>
> +static void completion_callback(struct mcryptd_skcipher_request_ctx *rctx,
> + struct mcryptd_alg_cstate *cstate,
> + int err)
> +{
> + struct skcipher_request *req = cast_mcryptd_ctx_to_req(rctx);
> +
> +   /* remove from work list and invoke completion callback */
> + spin_lock(>work_lock);
> + list_del(>waiter);
> + spin_unlock(>work_lock);
> +
> + if (irqs_disabled())
> + rctx->complete(>base, err);
> + else {
> + local_bh_disable();
> + rctx->complete(>base, err);
> + local_bh_enable();
> + }
> +}

The fact that you need to do this check means that this design is
wrong.  You should always know what context you are in.

> +/*
> + * CRYPTO_ALG_ASYNC flag is passed to indicate we have an ablk
> + * scatter-gather walk.
> + */
> +static struct skcipher_alg aes_cbc_mb_alg = {
> + .base = {
> + .cra_name   = "cbc(aes)",
> + .cra_driver_name= "cbc-aes-aesni-mb",
> + .cra_priority   = 500,
> + .cra_flags  = CRYPTO_ALG_INTERNAL,
> + .cra_blocksize  = AES_BLOCK_SIZE,
> + .cra_ctxsize= CRYPTO_AES_CTX_SIZE,
> + .cra_module = THIS_MODULE,
> + },
> + .min_keysize= AES_MIN_KEY_SIZE,
> + .max_keysize= AES_MAX_KEY_SIZE,
> + .ivsize = AES_BLOCK_SIZE,
> + .setkey = aes_set_key,
> + .encrypt= mb_aes_cbc_encrypt,
> + .decrypt= mb_aes_cbc_decrypt
> +};

So this claims to be a sync algorithm.  Is this really the case?

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Regression with suspicious RCU usage splats with cpu_pm change

[Tony Lindgren]

* Paul E. McKenney  [170717 05:40]:
> On Sun, Jul 16, 2017 at 11:08:07PM -0700, Tony Lindgren wrote:
> > * Alex Shi  [170716 16:25]:
> > > I reused the rcu_irq_enter_irqson() from RCU_NONIDLE to avoid this issue. 
> > > It works fine.
> > > 
> > > Tony, Could you like to give a tested-by if this patch works for you.
> > 
> > Yeah that keeps things booting for me with no splats so:
> > 
> > Tested-by: Tony Lindgren 
> > 
> > In general, it seems we're missing the knowledge in Linux kernel
> > of when the entire system is idle. Right now it seems that only
> > cpuidle_coupled knows that?
> > 
> > We could probably simplify things by adding some PM state for
> > entire system idle. Then cpuidle code and timer code could use
> > that to test when it's safe to do whatever the SoC needs to do
> > to enter deeper power states.
> > 
> > If we already have something like that, please do let me know :)
> 
> Well, we used to have CONFIG_NO_HZ_FULL_SYSIDLE, which detected
> full-system idle lazily so as to avoid scalability bottlenecks.
> https://lwn.net/Articles/558284/
> 
> No one was using it, so I removed it last merge window.  The
> patch that removed it is at sysidle.2017.05.11a, which can
> probably still be reverted cleanly.  Or just use v4.11 or earlier.

OK thanks for the pointer, for reference that commit is
fe5ac724d81a ("rcu: Remove nohz_full full-system-idle state
machine").

For a potential user, I think we could use it for example in
cpuidle_enter_state_coupled() + omap_enter_idle_coupled() where
we try to figure out if the system is fully idle before calling
tick_broadcast_enter().

Regards,

Tony

Re: Regression with suspicious RCU usage splats with cpu_pm change

[Tony Lindgren]

* Paul E. McKenney  [170717 05:40]:
> On Sun, Jul 16, 2017 at 11:08:07PM -0700, Tony Lindgren wrote:
> > * Alex Shi  [170716 16:25]:
> > > I reused the rcu_irq_enter_irqson() from RCU_NONIDLE to avoid this issue. 
> > > It works fine.
> > > 
> > > Tony, Could you like to give a tested-by if this patch works for you.
> > 
> > Yeah that keeps things booting for me with no splats so:
> > 
> > Tested-by: Tony Lindgren 
> > 
> > In general, it seems we're missing the knowledge in Linux kernel
> > of when the entire system is idle. Right now it seems that only
> > cpuidle_coupled knows that?
> > 
> > We could probably simplify things by adding some PM state for
> > entire system idle. Then cpuidle code and timer code could use
> > that to test when it's safe to do whatever the SoC needs to do
> > to enter deeper power states.
> > 
> > If we already have something like that, please do let me know :)
> 
> Well, we used to have CONFIG_NO_HZ_FULL_SYSIDLE, which detected
> full-system idle lazily so as to avoid scalability bottlenecks.
> https://lwn.net/Articles/558284/
> 
> No one was using it, so I removed it last merge window.  The
> patch that removed it is at sysidle.2017.05.11a, which can
> probably still be reverted cleanly.  Or just use v4.11 or earlier.

OK thanks for the pointer, for reference that commit is
fe5ac724d81a ("rcu: Remove nohz_full full-system-idle state
machine").

For a potential user, I think we could use it for example in
cpuidle_enter_state_coupled() + omap_enter_idle_coupled() where
we try to figure out if the system is fully idle before calling
tick_broadcast_enter().

Regards,

Tony

[PATCH] staging: pi433: Fix a couple of spelling mistakes

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistakes in dev_dbg debug messages

"wiat" -> "wait"
"fonud" -> "found"

Signed-off-by: Colin Ian King 
---
 drivers/staging/pi433/pi433_if.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index 1bc478a7f49e..d9328ce5ec1d 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -618,7 +618,7 @@ pi433_tx_thread(void *data)
}
 
/* we are done. Wait for packet to get sent */
-   dev_dbg(device->dev, "thread: wiat for packet to get sent/fifo 
to be empty");
+   dev_dbg(device->dev, "thread: wait for packet to get sent/fifo 
to be empty");
wait_event_interruptible(device->fifo_wait_queue,
 device->free_in_fifo == FIFO_SIZE ||
 kthread_should_stop() );
@@ -1101,7 +1101,7 @@ static int pi433_probe(struct spi_device *spi)
switch(retval)
{
case 0x24:
-   dev_dbg(>dev, "fonud pi433 (ver. 0x%x)", retval);
+   dev_dbg(>dev, "found pi433 (ver. 0x%x)", retval);
break;
default:
dev_dbg(>dev, "unknown chip version: 0x%x", 
retval);
-- 
2.11.0

[PATCH v2] ARM: dts: imx6: RIoTboard provide gpio-line-names

[Oleksij Rempel]

gpio-line-names may help to make work with GPIOs from user space easier.
Following examples are provided with libgpiod
https://github.com/brgl/libgpiod :
|# Toggle a GPIO by name, then wait for the user to press ENTER.
|$ gpioset --mode=wait `gpiofind "USR-LED-2"`=1
|# Pause execution until a single event of any type occurs. Don't print
|# anything. Find the line by name.
|$ gpiomon --num-events=1 --silent `gpiofind "USR-IN"`

Used names was taken from RIoTboard schematics, version 1 (2013.12.07).

Signed-off-by: Oleksij Rempel 
---
 arch/arm/boot/dts/imx6dl-riotboard.dts | 45 ++
 1 file changed, 45 insertions(+)

diff --git a/arch/arm/boot/dts/imx6dl-riotboard.dts 
b/arch/arm/boot/dts/imx6dl-riotboard.dts
index 2cb72824e800..3ecd3913280f 100644
--- a/arch/arm/boot/dts/imx6dl-riotboard.dts
+++ b/arch/arm/boot/dts/imx6dl-riotboard.dts
@@ -101,6 +101,51 @@
status = "okay";
 };
 
+ {
+   gpio-line-names =
+   "", "", "SD2_WP", "", "SD2_CD", "I2C3_SCL",
+   "I2C3_SDA", "I2C4_SCL",
+   "I2C4_SDA", "", "", "", "", "", "", "",
+   "", "PWM3", "", "", "", "", "", "",
+   "", "", "", "", "", "", "", "";
+};
+
+ {
+   gpio-line-names =
+   "", "", "", "", "", "", "", "",
+   "", "", "", "", "", "", "", "",
+   "", "", "", "", "", "", "USB_OTG_VBUS", "",
+   "UART3_TXD", "UART3_RXD", "", "", "EIM_D28", "", "", "";
+};
+
+ {
+   gpio-line-names =
+   "", "", "", "", "", "", "UART4_TXD", "UART4_RXD",
+   "UART5_TXD", "UART5_RXD", "", "", "", "", "", "",
+   "GPIO4_16", "GPIO4_17", "GPIO4_18", "GPIO4_19", "",
+   "CSPI3_CLK", "CSPI3_MOSI", "CSPI3_MISO",
+   "CSPI3_CS0", "CSPI3_CS1", "GPIO4_26", "GPIO4_27",
+   "CSPI3_RDY", "PWM1", "PWM2", "GPIO4_31";
+};
+
+ {
+   gpio-line-names =
+   "", "", "EIM_A25", "", "", "GPIO5_05", "GPIO5_06",
+   "GPIO5_07",
+   "GPIO5_08", "CSPI2_CS1", "CSPI2_MOSI", "CSPI2_MISO",
+   "CSPI2_CS0", "CSPI2_CLK", "", "",
+   "", "", "", "", "", "", "", "",
+   "", "", "", "", "", "", "", "";
+};
+
+ {
+   gpio-line-names =
+   "SD3_CD", "SD3_WP", "", "", "", "", "", "",
+   "", "", "", "", "", "", "", "",
+   "", "", "", "", "", "", "", "",
+   "", "", "", "", "", "", "", "";
+};
+
  {
ddc-i2c-bus = <>;
status = "okay";
-- 
2.11.0

[PATCH] staging: pi433: Fix a couple of spelling mistakes

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistakes in dev_dbg debug messages

"wiat" -> "wait"
"fonud" -> "found"

Signed-off-by: Colin Ian King 
---
 drivers/staging/pi433/pi433_if.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index 1bc478a7f49e..d9328ce5ec1d 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -618,7 +618,7 @@ pi433_tx_thread(void *data)
}
 
/* we are done. Wait for packet to get sent */
-   dev_dbg(device->dev, "thread: wiat for packet to get sent/fifo 
to be empty");
+   dev_dbg(device->dev, "thread: wait for packet to get sent/fifo 
to be empty");
wait_event_interruptible(device->fifo_wait_queue,
 device->free_in_fifo == FIFO_SIZE ||
 kthread_should_stop() );
@@ -1101,7 +1101,7 @@ static int pi433_probe(struct spi_device *spi)
switch(retval)
{
case 0x24:
-   dev_dbg(>dev, "fonud pi433 (ver. 0x%x)", retval);
+   dev_dbg(>dev, "found pi433 (ver. 0x%x)", retval);
break;
default:
dev_dbg(>dev, "unknown chip version: 0x%x", 
retval);
-- 
2.11.0

[PATCH v2] ARM: dts: imx6: RIoTboard provide gpio-line-names

[Oleksij Rempel]

gpio-line-names may help to make work with GPIOs from user space easier.
Following examples are provided with libgpiod
https://github.com/brgl/libgpiod :
|# Toggle a GPIO by name, then wait for the user to press ENTER.
|$ gpioset --mode=wait `gpiofind "USR-LED-2"`=1
|# Pause execution until a single event of any type occurs. Don't print
|# anything. Find the line by name.
|$ gpiomon --num-events=1 --silent `gpiofind "USR-IN"`

Used names was taken from RIoTboard schematics, version 1 (2013.12.07).

Signed-off-by: Oleksij Rempel 
---
 arch/arm/boot/dts/imx6dl-riotboard.dts | 45 ++
 1 file changed, 45 insertions(+)

diff --git a/arch/arm/boot/dts/imx6dl-riotboard.dts 
b/arch/arm/boot/dts/imx6dl-riotboard.dts
index 2cb72824e800..3ecd3913280f 100644
--- a/arch/arm/boot/dts/imx6dl-riotboard.dts
+++ b/arch/arm/boot/dts/imx6dl-riotboard.dts
@@ -101,6 +101,51 @@
status = "okay";
 };
 
+ {
+   gpio-line-names =
+   "", "", "SD2_WP", "", "SD2_CD", "I2C3_SCL",
+   "I2C3_SDA", "I2C4_SCL",
+   "I2C4_SDA", "", "", "", "", "", "", "",
+   "", "PWM3", "", "", "", "", "", "",
+   "", "", "", "", "", "", "", "";
+};
+
+ {
+   gpio-line-names =
+   "", "", "", "", "", "", "", "",
+   "", "", "", "", "", "", "", "",
+   "", "", "", "", "", "", "USB_OTG_VBUS", "",
+   "UART3_TXD", "UART3_RXD", "", "", "EIM_D28", "", "", "";
+};
+
+ {
+   gpio-line-names =
+   "", "", "", "", "", "", "UART4_TXD", "UART4_RXD",
+   "UART5_TXD", "UART5_RXD", "", "", "", "", "", "",
+   "GPIO4_16", "GPIO4_17", "GPIO4_18", "GPIO4_19", "",
+   "CSPI3_CLK", "CSPI3_MOSI", "CSPI3_MISO",
+   "CSPI3_CS0", "CSPI3_CS1", "GPIO4_26", "GPIO4_27",
+   "CSPI3_RDY", "PWM1", "PWM2", "GPIO4_31";
+};
+
+ {
+   gpio-line-names =
+   "", "", "EIM_A25", "", "", "GPIO5_05", "GPIO5_06",
+   "GPIO5_07",
+   "GPIO5_08", "CSPI2_CS1", "CSPI2_MOSI", "CSPI2_MISO",
+   "CSPI2_CS0", "CSPI2_CLK", "", "",
+   "", "", "", "", "", "", "", "",
+   "", "", "", "", "", "", "", "";
+};
+
+ {
+   gpio-line-names =
+   "SD3_CD", "SD3_WP", "", "", "", "", "", "",
+   "", "", "", "", "", "", "", "",
+   "", "", "", "", "", "", "", "",
+   "", "", "", "", "", "", "", "";
+};
+
  {
ddc-i2c-bus = <>;
status = "okay";
-- 
2.11.0

[PATCH] staging: iio: adc: add space around substraction operation

[Hari Prasath]

Fix checkpatch warning to add space around the substraction operation

Signed-off-by: Hari Prasath 
---
 drivers/staging/iio/adc/ad7280a.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/iio/adc/ad7280a.c 
b/drivers/staging/iio/adc/ad7280a.c
index d5ab83f..d79e774 100644
--- a/drivers/staging/iio/adc/ad7280a.c
+++ b/drivers/staging/iio/adc/ad7280a.c
@@ -745,14 +745,14 @@ static irqreturn_t ad7280_event_handler(int irq, void 
*private)
 }
 
 static IIO_DEVICE_ATTR_NAMED(in_thresh_low_value,
-   in_voltage-voltage_thresh_low_value,
+   in_voltage - voltage_thresh_low_value,
0644,
ad7280_read_channel_config,
ad7280_write_channel_config,
AD7280A_CELL_UNDERVOLTAGE);
 
 static IIO_DEVICE_ATTR_NAMED(in_thresh_high_value,
-   in_voltage-voltage_thresh_high_value,
+   in_voltage - voltage_thresh_high_value,
0644,
ad7280_read_channel_config,
ad7280_write_channel_config,
-- 
2.10.0.GIT

[PATCH] staging: iio: adc: add space around substraction operation

[Hari Prasath]

Fix checkpatch warning to add space around the substraction operation

Signed-off-by: Hari Prasath 
---
 drivers/staging/iio/adc/ad7280a.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/iio/adc/ad7280a.c 
b/drivers/staging/iio/adc/ad7280a.c
index d5ab83f..d79e774 100644
--- a/drivers/staging/iio/adc/ad7280a.c
+++ b/drivers/staging/iio/adc/ad7280a.c
@@ -745,14 +745,14 @@ static irqreturn_t ad7280_event_handler(int irq, void 
*private)
 }
 
 static IIO_DEVICE_ATTR_NAMED(in_thresh_low_value,
-   in_voltage-voltage_thresh_low_value,
+   in_voltage - voltage_thresh_low_value,
0644,
ad7280_read_channel_config,
ad7280_write_channel_config,
AD7280A_CELL_UNDERVOLTAGE);
 
 static IIO_DEVICE_ATTR_NAMED(in_thresh_high_value,
-   in_voltage-voltage_thresh_high_value,
+   in_voltage - voltage_thresh_high_value,
0644,
ad7280_read_channel_config,
ad7280_write_channel_config,
-- 
2.10.0.GIT

Re: [PATCH 1/3] ACPI / blacklist: add acpi_match_oemlist() interface

[Borislav Petkov]

On Mon, Jul 17, 2017 at 03:59:10PM -0600, Toshi Kani wrote:
> ACPI OEM ID / OEM Table ID / Revision can be used to identify
> platform type based on ACPI firmware.  acpi_blacklisted(),
> intel_pstate_platform_pwr_mgmt_exists() and some other funcs
> have been using this type of check to detect a list of platforms
> that require special handlings.
> 
> Move the platform type check in acpi_blacklisted() to a common
> utility function, acpi_match_oemlist(), so that other drivers
> do not have to implement their own.
> 
> There is no change in functionality.
> 
> Signed-off-by: Toshi Kani 
> Cc: "Rafael J. Wysocki" 
> Cc: Borislav Petkov 
> Cc: Thomas Gleixner 
> ---
>  drivers/acpi/blacklist.c |   84 
> --
>  drivers/acpi/utils.c |   40 ++
>  include/linux/acpi.h |   19 ++
>  3 files changed, 74 insertions(+), 69 deletions(-)
> 
> diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
> index bb542ac..288fe4d 100644
> --- a/drivers/acpi/blacklist.c
> +++ b/drivers/acpi/blacklist.c
> @@ -30,30 +30,13 @@
>  
>  #include "internal.h"
>  
> -enum acpi_blacklist_predicates {
> - all_versions,
> - less_than_or_equal,
> - equal,
> - greater_than_or_equal,
> -};
> -
> -struct acpi_blacklist_item {
> - char oem_id[7];
> - char oem_table_id[9];
> - u32 oem_revision;
> - char *table;
> - enum acpi_blacklist_predicates oem_revision_predicate;
> - char *reason;
> - u32 is_critical_error;
> -};
> -
>  static struct dmi_system_id acpi_rev_dmi_table[] __initdata;
>  
>  /*
>   * POLICY: If *anything* doesn't work, put it on the blacklist.
>   *  If they are critical errors, mark it critical, and abort driver load.
>   */
> -static struct acpi_blacklist_item acpi_blacklist[] __initdata = {
> +static struct acpi_oemlist acpi_blacklist[] __initdata = {

Why the arbitrary rename?

If anything, you should shorten that

enum acpi_blacklist_predicates oem_revision_predicate;

unreadable insanity.

>   /* Compaq Presario 1700 */
>   {"PTLTD ", "  DSDT  ", 0x0604, ACPI_SIG_DSDT, less_than_or_equal,
>"Multiple problems", 1},
> @@ -67,65 +50,28 @@ static struct acpi_blacklist_item acpi_blacklist[] 
> __initdata = {
>   {"IBM   ", "TP600E  ", 0x0105, ACPI_SIG_DSDT, less_than_or_equal,
>"Incorrect _ADR", 1},
>  
> - {""}
> + { }
>  };
>  
>  int __init acpi_blacklisted(void)
>  {
> - int i = 0;
> + int i;
>   int blacklisted = 0;
> - struct acpi_table_header table_header;
> -
> - while (acpi_blacklist[i].oem_id[0] != '\0') {
> - if (acpi_get_table_header(acpi_blacklist[i].table, 0, 
> _header)) {
> - i++;
> - continue;
> - }
> -
> - if (strncmp(acpi_blacklist[i].oem_id, table_header.oem_id, 6)) {
> - i++;
> - continue;
> - }
> -
> - if (strncmp
> - (acpi_blacklist[i].oem_table_id, table_header.oem_table_id,
> -  8)) {
> - i++;
> - continue;
> - }
> -
> - if ((acpi_blacklist[i].oem_revision_predicate == all_versions)
> - || (acpi_blacklist[i].oem_revision_predicate ==
> - less_than_or_equal
> - && table_header.oem_revision <=
> - acpi_blacklist[i].oem_revision)
> - || (acpi_blacklist[i].oem_revision_predicate ==
> - greater_than_or_equal
> - && table_header.oem_revision >=
> - acpi_blacklist[i].oem_revision)
> - || (acpi_blacklist[i].oem_revision_predicate == equal
> - && table_header.oem_revision ==
> - acpi_blacklist[i].oem_revision)) {
>  
> - printk(KERN_ERR PREFIX
> -"Vendor \"%6.6s\" System \"%8.8s\" "
> -"Revision 0x%x has a known ACPI BIOS problem.\n",
> -acpi_blacklist[i].oem_id,
> -acpi_blacklist[i].oem_table_id,
> -acpi_blacklist[i].oem_revision);
> + i = acpi_match_oemlist(acpi_blacklist);
> + if (i >= 0) {
> + pr_err(PREFIX "Vendor \"%6.6s\" System \"%8.8s\" "
> +"Revision 0x%x has a known ACPI BIOS problem.\n",

Put that string on a single line for grepping. checkpatch catches that
error, didn't you see it?

> +acpi_blacklist[i].oem_id,
> +acpi_blacklist[i].oem_table_id,
> +acpi_blacklist[i].oem_revision);
>  
> - printk(KERN_ERR PREFIX
> -"Reason: %s. This is a %s error\n",
> -

Re: [PATCH 1/3] ACPI / blacklist: add acpi_match_oemlist() interface

[Borislav Petkov]

On Mon, Jul 17, 2017 at 03:59:10PM -0600, Toshi Kani wrote:
> ACPI OEM ID / OEM Table ID / Revision can be used to identify
> platform type based on ACPI firmware.  acpi_blacklisted(),
> intel_pstate_platform_pwr_mgmt_exists() and some other funcs
> have been using this type of check to detect a list of platforms
> that require special handlings.
> 
> Move the platform type check in acpi_blacklisted() to a common
> utility function, acpi_match_oemlist(), so that other drivers
> do not have to implement their own.
> 
> There is no change in functionality.
> 
> Signed-off-by: Toshi Kani 
> Cc: "Rafael J. Wysocki" 
> Cc: Borislav Petkov 
> Cc: Thomas Gleixner 
> ---
>  drivers/acpi/blacklist.c |   84 
> --
>  drivers/acpi/utils.c |   40 ++
>  include/linux/acpi.h |   19 ++
>  3 files changed, 74 insertions(+), 69 deletions(-)
> 
> diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
> index bb542ac..288fe4d 100644
> --- a/drivers/acpi/blacklist.c
> +++ b/drivers/acpi/blacklist.c
> @@ -30,30 +30,13 @@
>  
>  #include "internal.h"
>  
> -enum acpi_blacklist_predicates {
> - all_versions,
> - less_than_or_equal,
> - equal,
> - greater_than_or_equal,
> -};
> -
> -struct acpi_blacklist_item {
> - char oem_id[7];
> - char oem_table_id[9];
> - u32 oem_revision;
> - char *table;
> - enum acpi_blacklist_predicates oem_revision_predicate;
> - char *reason;
> - u32 is_critical_error;
> -};
> -
>  static struct dmi_system_id acpi_rev_dmi_table[] __initdata;
>  
>  /*
>   * POLICY: If *anything* doesn't work, put it on the blacklist.
>   *  If they are critical errors, mark it critical, and abort driver load.
>   */
> -static struct acpi_blacklist_item acpi_blacklist[] __initdata = {
> +static struct acpi_oemlist acpi_blacklist[] __initdata = {

Why the arbitrary rename?

If anything, you should shorten that

enum acpi_blacklist_predicates oem_revision_predicate;

unreadable insanity.

>   /* Compaq Presario 1700 */
>   {"PTLTD ", "  DSDT  ", 0x0604, ACPI_SIG_DSDT, less_than_or_equal,
>"Multiple problems", 1},
> @@ -67,65 +50,28 @@ static struct acpi_blacklist_item acpi_blacklist[] 
> __initdata = {
>   {"IBM   ", "TP600E  ", 0x0105, ACPI_SIG_DSDT, less_than_or_equal,
>"Incorrect _ADR", 1},
>  
> - {""}
> + { }
>  };
>  
>  int __init acpi_blacklisted(void)
>  {
> - int i = 0;
> + int i;
>   int blacklisted = 0;
> - struct acpi_table_header table_header;
> -
> - while (acpi_blacklist[i].oem_id[0] != '\0') {
> - if (acpi_get_table_header(acpi_blacklist[i].table, 0, 
> _header)) {
> - i++;
> - continue;
> - }
> -
> - if (strncmp(acpi_blacklist[i].oem_id, table_header.oem_id, 6)) {
> - i++;
> - continue;
> - }
> -
> - if (strncmp
> - (acpi_blacklist[i].oem_table_id, table_header.oem_table_id,
> -  8)) {
> - i++;
> - continue;
> - }
> -
> - if ((acpi_blacklist[i].oem_revision_predicate == all_versions)
> - || (acpi_blacklist[i].oem_revision_predicate ==
> - less_than_or_equal
> - && table_header.oem_revision <=
> - acpi_blacklist[i].oem_revision)
> - || (acpi_blacklist[i].oem_revision_predicate ==
> - greater_than_or_equal
> - && table_header.oem_revision >=
> - acpi_blacklist[i].oem_revision)
> - || (acpi_blacklist[i].oem_revision_predicate == equal
> - && table_header.oem_revision ==
> - acpi_blacklist[i].oem_revision)) {
>  
> - printk(KERN_ERR PREFIX
> -"Vendor \"%6.6s\" System \"%8.8s\" "
> -"Revision 0x%x has a known ACPI BIOS problem.\n",
> -acpi_blacklist[i].oem_id,
> -acpi_blacklist[i].oem_table_id,
> -acpi_blacklist[i].oem_revision);
> + i = acpi_match_oemlist(acpi_blacklist);
> + if (i >= 0) {
> + pr_err(PREFIX "Vendor \"%6.6s\" System \"%8.8s\" "
> +"Revision 0x%x has a known ACPI BIOS problem.\n",

Put that string on a single line for grepping. checkpatch catches that
error, didn't you see it?

> +acpi_blacklist[i].oem_id,
> +acpi_blacklist[i].oem_table_id,
> +acpi_blacklist[i].oem_revision);
>  
> - printk(KERN_ERR PREFIX
> -"Reason: %s. This is a %s error\n",
> -acpi_blacklist[i].reason,
> -(acpi_blacklist[i].

[PATCH v2 4/4] pinctrl: aspeed: g5: Add USB device and host support

[Andrew Jeffery]

Implement the AST2500 USB functions as described by the devicetree
bindings. The AST2500 exposes five USB controllers through two USB
ports. Similar to the AST2400, the pins exposing USB are outliers with
respect to the rest of the pinmux as they not capable of GPIO.

Signed-off-by: Andrew Jeffery 
---
 drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 58 +-
 1 file changed, 57 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c 
b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
index 68aa04664a62..634b371da43a 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
@@ -25,7 +25,7 @@
 #include "../pinctrl-utils.h"
 #include "pinctrl-aspeed.h"
 
-#define ASPEED_G5_NR_PINS 232
+#define ASPEED_G5_NR_PINS 236
 
 #define COND1  { ASPEED_IP_SCU, SCU90, BIT(6), 0, 0 }
 #define COND2  { ASPEED_IP_SCU, SCU94, GENMASK(1, 0), 0, 0 }
@@ -1724,6 +1724,48 @@ FUNC_GROUP_DECL(LPCRST, G22);
 
 FUNC_GROUP_DECL(ESPI, G21, G20, D22, E22, C22, F21, F22, G22);
 
+#define A7 232
+SIG_EXPR_LIST_DECL_SINGLE(USB2AHDP, USB2AH, SIG_DESC_SET(SCU90, 29));
+SIG_EXPR_LIST_DECL_SINGLE(USB2ADDP, USB2AD, SIG_DESC_BIT(SCU90, 29, 0));
+MS_PIN_DECL_(A7, SIG_EXPR_LIST_PTR(USB2AHDP), SIG_EXPR_LIST_PTR(USB2ADDP));
+
+#define A8 233
+SIG_EXPR_LIST_DECL_SINGLE(USB2AHDN, USB2AH, SIG_DESC_SET(SCU90, 29));
+SIG_EXPR_LIST_DECL_SINGLE(USB2ADDN, USB2AD, SIG_DESC_BIT(SCU90, 29, 0));
+MS_PIN_DECL_(A8, SIG_EXPR_LIST_PTR(USB2AHDN), SIG_EXPR_LIST_PTR(USB2ADDN));
+
+FUNC_GROUP_DECL(USB2AH, A7, A8);
+FUNC_GROUP_DECL(USB2AD, A7, A8);
+
+#define USB11BHID_DESC  { ASPEED_IP_SCU, SCU94, GENMASK(14, 13), 0, 0 }
+#define USB2BD_DESC   { ASPEED_IP_SCU, SCU94, GENMASK(14, 13), 1, 0 }
+#define USB2BH1_DESC { ASPEED_IP_SCU, SCU94, GENMASK(14, 13), 2, 0 }
+#define USB2BH2_DESC { ASPEED_IP_SCU, SCU94, GENMASK(14, 13), 3, 0 }
+
+#define B6 234
+SIG_EXPR_LIST_DECL_SINGLE(USB11BDP, USB11BHID, USB11BHID_DESC);
+SIG_EXPR_LIST_DECL_SINGLE(USB2BDDP, USB2BD, USB2BD_DESC);
+SIG_EXPR_DECL(USB2BHDP1, USB2BH, USB2BH1_DESC);
+SIG_EXPR_DECL(USB2BHDP2, USB2BH, USB2BH2_DESC);
+SIG_EXPR_LIST_DECL(USB2BHDP, SIG_EXPR_PTR(USB2BHDP1, USB2BH),
+   SIG_EXPR_PTR(USB2BHDP2, USB2BH));
+MS_PIN_DECL_(B6, SIG_EXPR_LIST_PTR(USB11BDP), SIG_EXPR_LIST_PTR(USB2BDDP),
+   SIG_EXPR_LIST_PTR(USB2BHDP));
+
+#define A6 235
+SIG_EXPR_LIST_DECL_SINGLE(USB11BDN, USB11BHID, USB11BHID_DESC);
+SIG_EXPR_LIST_DECL_SINGLE(USB2BDN, USB2BD, USB2BD_DESC);
+SIG_EXPR_DECL(USB2BHDN1, USB2BH, USB2BH1_DESC);
+SIG_EXPR_DECL(USB2BHDN2, USB2BH, USB2BH2_DESC);
+SIG_EXPR_LIST_DECL(USB2BHDN, SIG_EXPR_PTR(USB2BHDN1, USB2BH),
+   SIG_EXPR_PTR(USB2BHDN2, USB2BH));
+MS_PIN_DECL_(A6, SIG_EXPR_LIST_PTR(USB11BDN), SIG_EXPR_LIST_PTR(USB2BDN),
+   SIG_EXPR_LIST_PTR(USB2BHDN));
+
+FUNC_GROUP_DECL(USB11BHID, B6, A6);
+FUNC_GROUP_DECL(USB2BD, B6, A6);
+FUNC_GROUP_DECL(USB2BH, B6, A6);
+
 /* Pins, groups and functions are sort(1):ed alphabetically for sanity */
 
 static struct pinctrl_pin_desc aspeed_g5_pins[ASPEED_G5_NR_PINS] = {
@@ -1743,6 +1785,9 @@ static struct pinctrl_pin_desc 
aspeed_g5_pins[ASPEED_G5_NR_PINS] = {
ASPEED_PINCTRL_PIN(A3),
ASPEED_PINCTRL_PIN(A4),
ASPEED_PINCTRL_PIN(A5),
+   ASPEED_PINCTRL_PIN(A6),
+   ASPEED_PINCTRL_PIN(A7),
+   ASPEED_PINCTRL_PIN(A8),
ASPEED_PINCTRL_PIN(A9),
ASPEED_PINCTRL_PIN(AA1),
ASPEED_PINCTRL_PIN(AA19),
@@ -1777,6 +1822,7 @@ static struct pinctrl_pin_desc 
aspeed_g5_pins[ASPEED_G5_NR_PINS] = {
ASPEED_PINCTRL_PIN(B3),
ASPEED_PINCTRL_PIN(B4),
ASPEED_PINCTRL_PIN(B5),
+   ASPEED_PINCTRL_PIN(B6),
ASPEED_PINCTRL_PIN(B9),
ASPEED_PINCTRL_PIN(C1),
ASPEED_PINCTRL_PIN(C11),
@@ -2111,6 +2157,11 @@ static const struct aspeed_pin_group aspeed_g5_groups[] 
= {
ASPEED_PINCTRL_GROUP(TXD3),
ASPEED_PINCTRL_GROUP(TXD4),
ASPEED_PINCTRL_GROUP(UART6),
+   ASPEED_PINCTRL_GROUP(USB11BHID),
+   ASPEED_PINCTRL_GROUP(USB2AD),
+   ASPEED_PINCTRL_GROUP(USB2AH),
+   ASPEED_PINCTRL_GROUP(USB2BD),
+   ASPEED_PINCTRL_GROUP(USB2BH),
ASPEED_PINCTRL_GROUP(USBCKI),
ASPEED_PINCTRL_GROUP(VGABIOSROM),
ASPEED_PINCTRL_GROUP(VGAHS),
@@ -2275,6 +2326,11 @@ static const struct aspeed_pin_function 
aspeed_g5_functions[] = {
ASPEED_PINCTRL_FUNC(TXD3),
ASPEED_PINCTRL_FUNC(TXD4),
ASPEED_PINCTRL_FUNC(UART6),
+   ASPEED_PINCTRL_FUNC(USB11BHID),
+   ASPEED_PINCTRL_FUNC(USB2AD),
+   ASPEED_PINCTRL_FUNC(USB2AH),
+   ASPEED_PINCTRL_FUNC(USB2BD),
+   ASPEED_PINCTRL_FUNC(USB2BH),
ASPEED_PINCTRL_FUNC(USBCKI),
ASPEED_PINCTRL_FUNC(VGABIOSROM),
ASPEED_PINCTRL_FUNC(VGAHS),
-- 
2.11.0

[PATCH v2 2/4] dt-bindings: pinctrl: aspeed: Add g5 USB functions

[Andrew Jeffery]

The Aspeed AST2500 SoC contains a number of USB controllers:

* USB 1.1 Host Controller
* USB 2.0 Host Controller (x2)
* USB 2.0 Virtual Hub
* USB 2.0 Device Controller
* USB 1.1 HID Controller

The controllers are exposed via two USB ports with functionality muxed
as required. The following table illustrates the relationships between
the ports and the controllers via the mux function names:

Port  | USB Version  | USB Mode | Mux Function
--|--|--|-
A | 2.0  | Virtual Hub  | USB2AD
A | 2.0  | Host | USB2AH
B | 1.1  | HID  | USB11BHID
B | 2.0  | Device   | USB2BD
B | 2.0  | Host | USB2BH

Signed-off-by: Andrew Jeffery 
Acked-by: Rob Herring 
---
v1 -> v2:

* Update commit message to separate Virtual Hub, 2.0 Device and 1.1 HID
  controllers

 Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
index 09142dab47db..3b7266c7c438 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
@@ -87,7 +87,8 @@ SALT11 SALT12 SALT13 SALT14 SALT2 SALT3 SALT4 SALT5 SALT6 
SALT7 SALT8 SALT9
 SCL1 SCL2 SD1 SD2 SDA1 SDA2 SGPS1 SGPS2 SIOONCTRL SIOPBI SIOPBO SIOPWREQ
 SIOPWRGD SIOS3 SIOS5 SIOSCI SPI1 SPI1CS1 SPI1DEBUG SPI1PASSTHRU SPI2CK SPI2CS0
 SPI2CS1 SPI2MISO SPI2MOSI TIMER3 TIMER4 TIMER5 TIMER6 TIMER7 TIMER8 TXD1 TXD2
-TXD3 TXD4 UART6 USBCKI VGABIOSROM VGAHS VGAVS VPI24 VPO WDTRST1 WDTRST2
+TXD3 TXD4 UART6 USB11BHID USB2AD USB2AH USB2BD USB2BH USBCKI VGABIOSROM VGAHS
+VGAVS VPI24 VPO WDTRST1 WDTRST2
 
 Examples
 
-- 
2.11.0

[PATCH v2 4/4] pinctrl: aspeed: g5: Add USB device and host support

[Andrew Jeffery]

Implement the AST2500 USB functions as described by the devicetree
bindings. The AST2500 exposes five USB controllers through two USB
ports. Similar to the AST2400, the pins exposing USB are outliers with
respect to the rest of the pinmux as they not capable of GPIO.

Signed-off-by: Andrew Jeffery 
---
 drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 58 +-
 1 file changed, 57 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c 
b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
index 68aa04664a62..634b371da43a 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
@@ -25,7 +25,7 @@
 #include "../pinctrl-utils.h"
 #include "pinctrl-aspeed.h"
 
-#define ASPEED_G5_NR_PINS 232
+#define ASPEED_G5_NR_PINS 236
 
 #define COND1  { ASPEED_IP_SCU, SCU90, BIT(6), 0, 0 }
 #define COND2  { ASPEED_IP_SCU, SCU94, GENMASK(1, 0), 0, 0 }
@@ -1724,6 +1724,48 @@ FUNC_GROUP_DECL(LPCRST, G22);
 
 FUNC_GROUP_DECL(ESPI, G21, G20, D22, E22, C22, F21, F22, G22);
 
+#define A7 232
+SIG_EXPR_LIST_DECL_SINGLE(USB2AHDP, USB2AH, SIG_DESC_SET(SCU90, 29));
+SIG_EXPR_LIST_DECL_SINGLE(USB2ADDP, USB2AD, SIG_DESC_BIT(SCU90, 29, 0));
+MS_PIN_DECL_(A7, SIG_EXPR_LIST_PTR(USB2AHDP), SIG_EXPR_LIST_PTR(USB2ADDP));
+
+#define A8 233
+SIG_EXPR_LIST_DECL_SINGLE(USB2AHDN, USB2AH, SIG_DESC_SET(SCU90, 29));
+SIG_EXPR_LIST_DECL_SINGLE(USB2ADDN, USB2AD, SIG_DESC_BIT(SCU90, 29, 0));
+MS_PIN_DECL_(A8, SIG_EXPR_LIST_PTR(USB2AHDN), SIG_EXPR_LIST_PTR(USB2ADDN));
+
+FUNC_GROUP_DECL(USB2AH, A7, A8);
+FUNC_GROUP_DECL(USB2AD, A7, A8);
+
+#define USB11BHID_DESC  { ASPEED_IP_SCU, SCU94, GENMASK(14, 13), 0, 0 }
+#define USB2BD_DESC   { ASPEED_IP_SCU, SCU94, GENMASK(14, 13), 1, 0 }
+#define USB2BH1_DESC { ASPEED_IP_SCU, SCU94, GENMASK(14, 13), 2, 0 }
+#define USB2BH2_DESC { ASPEED_IP_SCU, SCU94, GENMASK(14, 13), 3, 0 }
+
+#define B6 234
+SIG_EXPR_LIST_DECL_SINGLE(USB11BDP, USB11BHID, USB11BHID_DESC);
+SIG_EXPR_LIST_DECL_SINGLE(USB2BDDP, USB2BD, USB2BD_DESC);
+SIG_EXPR_DECL(USB2BHDP1, USB2BH, USB2BH1_DESC);
+SIG_EXPR_DECL(USB2BHDP2, USB2BH, USB2BH2_DESC);
+SIG_EXPR_LIST_DECL(USB2BHDP, SIG_EXPR_PTR(USB2BHDP1, USB2BH),
+   SIG_EXPR_PTR(USB2BHDP2, USB2BH));
+MS_PIN_DECL_(B6, SIG_EXPR_LIST_PTR(USB11BDP), SIG_EXPR_LIST_PTR(USB2BDDP),
+   SIG_EXPR_LIST_PTR(USB2BHDP));
+
+#define A6 235
+SIG_EXPR_LIST_DECL_SINGLE(USB11BDN, USB11BHID, USB11BHID_DESC);
+SIG_EXPR_LIST_DECL_SINGLE(USB2BDN, USB2BD, USB2BD_DESC);
+SIG_EXPR_DECL(USB2BHDN1, USB2BH, USB2BH1_DESC);
+SIG_EXPR_DECL(USB2BHDN2, USB2BH, USB2BH2_DESC);
+SIG_EXPR_LIST_DECL(USB2BHDN, SIG_EXPR_PTR(USB2BHDN1, USB2BH),
+   SIG_EXPR_PTR(USB2BHDN2, USB2BH));
+MS_PIN_DECL_(A6, SIG_EXPR_LIST_PTR(USB11BDN), SIG_EXPR_LIST_PTR(USB2BDN),
+   SIG_EXPR_LIST_PTR(USB2BHDN));
+
+FUNC_GROUP_DECL(USB11BHID, B6, A6);
+FUNC_GROUP_DECL(USB2BD, B6, A6);
+FUNC_GROUP_DECL(USB2BH, B6, A6);
+
 /* Pins, groups and functions are sort(1):ed alphabetically for sanity */
 
 static struct pinctrl_pin_desc aspeed_g5_pins[ASPEED_G5_NR_PINS] = {
@@ -1743,6 +1785,9 @@ static struct pinctrl_pin_desc 
aspeed_g5_pins[ASPEED_G5_NR_PINS] = {
ASPEED_PINCTRL_PIN(A3),
ASPEED_PINCTRL_PIN(A4),
ASPEED_PINCTRL_PIN(A5),
+   ASPEED_PINCTRL_PIN(A6),
+   ASPEED_PINCTRL_PIN(A7),
+   ASPEED_PINCTRL_PIN(A8),
ASPEED_PINCTRL_PIN(A9),
ASPEED_PINCTRL_PIN(AA1),
ASPEED_PINCTRL_PIN(AA19),
@@ -1777,6 +1822,7 @@ static struct pinctrl_pin_desc 
aspeed_g5_pins[ASPEED_G5_NR_PINS] = {
ASPEED_PINCTRL_PIN(B3),
ASPEED_PINCTRL_PIN(B4),
ASPEED_PINCTRL_PIN(B5),
+   ASPEED_PINCTRL_PIN(B6),
ASPEED_PINCTRL_PIN(B9),
ASPEED_PINCTRL_PIN(C1),
ASPEED_PINCTRL_PIN(C11),
@@ -2111,6 +2157,11 @@ static const struct aspeed_pin_group aspeed_g5_groups[] 
= {
ASPEED_PINCTRL_GROUP(TXD3),
ASPEED_PINCTRL_GROUP(TXD4),
ASPEED_PINCTRL_GROUP(UART6),
+   ASPEED_PINCTRL_GROUP(USB11BHID),
+   ASPEED_PINCTRL_GROUP(USB2AD),
+   ASPEED_PINCTRL_GROUP(USB2AH),
+   ASPEED_PINCTRL_GROUP(USB2BD),
+   ASPEED_PINCTRL_GROUP(USB2BH),
ASPEED_PINCTRL_GROUP(USBCKI),
ASPEED_PINCTRL_GROUP(VGABIOSROM),
ASPEED_PINCTRL_GROUP(VGAHS),
@@ -2275,6 +2326,11 @@ static const struct aspeed_pin_function 
aspeed_g5_functions[] = {
ASPEED_PINCTRL_FUNC(TXD3),
ASPEED_PINCTRL_FUNC(TXD4),
ASPEED_PINCTRL_FUNC(UART6),
+   ASPEED_PINCTRL_FUNC(USB11BHID),
+   ASPEED_PINCTRL_FUNC(USB2AD),
+   ASPEED_PINCTRL_FUNC(USB2AH),
+   ASPEED_PINCTRL_FUNC(USB2BD),
+   ASPEED_PINCTRL_FUNC(USB2BH),
ASPEED_PINCTRL_FUNC(USBCKI),
ASPEED_PINCTRL_FUNC(VGABIOSROM),
ASPEED_PINCTRL_FUNC(VGAHS),
-- 
2.11.0

[PATCH v2 2/4] dt-bindings: pinctrl: aspeed: Add g5 USB functions

[Andrew Jeffery]

The Aspeed AST2500 SoC contains a number of USB controllers:

* USB 1.1 Host Controller
* USB 2.0 Host Controller (x2)
* USB 2.0 Virtual Hub
* USB 2.0 Device Controller
* USB 1.1 HID Controller

The controllers are exposed via two USB ports with functionality muxed
as required. The following table illustrates the relationships between
the ports and the controllers via the mux function names:

Port  | USB Version  | USB Mode | Mux Function
--|--|--|-
A | 2.0  | Virtual Hub  | USB2AD
A | 2.0  | Host | USB2AH
B | 1.1  | HID  | USB11BHID
B | 2.0  | Device   | USB2BD
B | 2.0  | Host | USB2BH

Signed-off-by: Andrew Jeffery 
Acked-by: Rob Herring 
---
v1 -> v2:

* Update commit message to separate Virtual Hub, 2.0 Device and 1.1 HID
  controllers

 Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
index 09142dab47db..3b7266c7c438 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
@@ -87,7 +87,8 @@ SALT11 SALT12 SALT13 SALT14 SALT2 SALT3 SALT4 SALT5 SALT6 
SALT7 SALT8 SALT9
 SCL1 SCL2 SD1 SD2 SDA1 SDA2 SGPS1 SGPS2 SIOONCTRL SIOPBI SIOPBO SIOPWREQ
 SIOPWRGD SIOS3 SIOS5 SIOSCI SPI1 SPI1CS1 SPI1DEBUG SPI1PASSTHRU SPI2CK SPI2CS0
 SPI2CS1 SPI2MISO SPI2MOSI TIMER3 TIMER4 TIMER5 TIMER6 TIMER7 TIMER8 TXD1 TXD2
-TXD3 TXD4 UART6 USBCKI VGABIOSROM VGAHS VGAVS VPI24 VPO WDTRST1 WDTRST2
+TXD3 TXD4 UART6 USB11BHID USB2AD USB2AH USB2BD USB2BH USBCKI VGABIOSROM VGAHS
+VGAVS VPI24 VPO WDTRST1 WDTRST2
 
 Examples
 
-- 
2.11.0

[PATCH v2 3/4] pinctrl: aspeed: g4: Add USB device and host support

[Andrew Jeffery]

Implement the AST2400 USB functions as described by the devicetree
bindings. Three ports are fully documented in the datasheet and exposed
through the bindings and pinctrl, though there are remnants of
documentation for a fourth port muxed with GPIO pins GPIOQ6 and GPIOQ7.
The implementation is updated to reflect this but the function and
group are not exposed.

Disregarding the mostly undocumented fourth port, the USB functions are
an outlier with respect to the rest of the muxed functionality on the
AST2400 as GPIO is not supported on these pins.

Signed-off-by: Andrew Jeffery 
---
 drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c | 66 ++
 1 file changed, 59 insertions(+), 7 deletions(-)

diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c 
b/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
index cf3106cec048..df56e58b05c1 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
@@ -1006,15 +1006,23 @@ SS_PIN_DECL(H3, GPIOQ5, SDA14);
 
 FUNC_GROUP_DECL(I2C14, H4, H3);
 
-#define DASH9028_DESC  SIG_DESC_SET(SCU90, 28)
+/*
+ * There are several opportunities to document USB port 4 in the datasheet, but
+ * it is only mentioned in one location. Particularly, the Multi-function Pins
+ * Mapping and Control table in the datasheet elides the signal names,
+ * suggesting that port 4 may not actually be functional. As such we define the
+ * signal names and control bit, but don't export the capability's function or
+ * group.
+ */
+#define USB11H3_DESC   SIG_DESC_SET(SCU90, 28)
 
 #define H2 134
-SIG_EXPR_LIST_DECL_SINGLE(DASHH2, DASHH2, DASH9028_DESC);
-SS_PIN_DECL(H2, GPIOQ6, DASHH2);
+SIG_EXPR_LIST_DECL_SINGLE(USB11HDP3, USB11H3, USB11H3_DESC);
+SS_PIN_DECL(H2, GPIOQ6, USB11HDP3);
 
 #define H1 135
-SIG_EXPR_LIST_DECL_SINGLE(DASHH1, DASHH1, DASH9028_DESC);
-SS_PIN_DECL(H1, GPIOQ7, DASHH1);
+SIG_EXPR_LIST_DECL_SINGLE(USB11HDN3, USB11H3, USB11H3_DESC);
+SS_PIN_DECL(H1, GPIOQ7, USB11HDN3);
 
 #define V20 136
 SSSF_PIN_DECL(V20, GPIOR0, ROMCS1, SIG_DESC_SET(SCU88, 24));
@@ -1706,10 +1714,42 @@ FUNC_GROUP_DECL(VPO12, U21, T19, V22, U20, R22, P18, 
P19, P20, P21, P22, M19,
 FUNC_GROUP_DECL(VPO24, U21, T19, V22, U20, L22, K18, V21, W22, R22, P18, P19,
P20, P21, P22, M19, M20, M21, M22, L18, L19);
 
+#define USB11H2_DESC   SIG_DESC_SET(SCU90, 3)
+#define USB11D1_DESC   SIG_DESC_BIT(SCU90, 3, 0)
+
+#define K4 220
+SIG_EXPR_LIST_DECL_SINGLE(USB11HDP2, USB11H2, USB11H2_DESC);
+SIG_EXPR_LIST_DECL_SINGLE(USB11DP1, USB11D1, USB11D1_DESC);
+MS_PIN_DECL_(K4, SIG_EXPR_LIST_PTR(USB11HDP2), SIG_EXPR_LIST_PTR(USB11DP1));
+
+#define K3 221
+SIG_EXPR_LIST_DECL_SINGLE(USB11HDN1, USB11H2, USB11H2_DESC);
+SIG_EXPR_LIST_DECL_SINGLE(USB11DDN1, USB11D1, USB11D1_DESC);
+MS_PIN_DECL_(K3, SIG_EXPR_LIST_PTR(USB11HDN1), SIG_EXPR_LIST_PTR(USB11DDN1));
+
+FUNC_GROUP_DECL(USB11H2, K4, K3);
+FUNC_GROUP_DECL(USB11D1, K4, K3);
+
+#define USB2H1_DESCSIG_DESC_SET(SCU90, 29)
+#define USB2D1_DESCSIG_DESC_BIT(SCU90, 29, 0)
+
+#define AB21 222
+SIG_EXPR_LIST_DECL_SINGLE(USB2HDP1, USB2H1, USB2H1_DESC);
+SIG_EXPR_LIST_DECL_SINGLE(USB2DDP1, USB2D1, USB2D1_DESC);
+MS_PIN_DECL_(AB21, SIG_EXPR_LIST_PTR(USB2HDP1), SIG_EXPR_LIST_PTR(USB2DDP1));
+
+#define AB20 223
+SIG_EXPR_LIST_DECL_SINGLE(USB2HDN1, USB2H1, USB2H1_DESC);
+SIG_EXPR_LIST_DECL_SINGLE(USB2DDN1, USB2D1, USB2D1_DESC);
+MS_PIN_DECL_(AB20, SIG_EXPR_LIST_PTR(USB2HDN1), SIG_EXPR_LIST_PTR(USB2DDN1));
+
+FUNC_GROUP_DECL(USB2H1, AB21, AB20);
+FUNC_GROUP_DECL(USB2D1, AB21, AB20);
+
 /* Note we account for GPIOY4-GPIOY7 even though they're not valid, thus 216
- * pins becomes 220.
+ * pins becomes 220. Four additional non-GPIO-capable pins are present for USB.
  */
-#define ASPEED_G4_NR_PINS 220
+#define ASPEED_G4_NR_PINS 224
 
 /* Pins, groups and functions are sort(1):ed alphabetically for sanity */
 
@@ -1749,6 +1789,8 @@ static struct pinctrl_pin_desc 
aspeed_g4_pins[ASPEED_G4_NR_PINS] = {
ASPEED_PINCTRL_PIN(AB5),
ASPEED_PINCTRL_PIN(AB6),
ASPEED_PINCTRL_PIN(AB7),
+   ASPEED_PINCTRL_PIN(AB20),
+   ASPEED_PINCTRL_PIN(AB21),
ASPEED_PINCTRL_PIN(B1),
ASPEED_PINCTRL_PIN(B10),
ASPEED_PINCTRL_PIN(B11),
@@ -1848,6 +1890,8 @@ static struct pinctrl_pin_desc 
aspeed_g4_pins[ASPEED_G4_NR_PINS] = {
ASPEED_PINCTRL_PIN(J5),
ASPEED_PINCTRL_PIN(K18),
ASPEED_PINCTRL_PIN(K20),
+   ASPEED_PINCTRL_PIN(K3),
+   ASPEED_PINCTRL_PIN(K4),
ASPEED_PINCTRL_PIN(K5),
ASPEED_PINCTRL_PIN(L1),
ASPEED_PINCTRL_PIN(L18),
@@ -2070,6 +2114,10 @@ static const struct aspeed_pin_group aspeed_g4_groups[] 
= {
ASPEED_PINCTRL_GROUP(TXD3),
ASPEED_PINCTRL_GROUP(TXD4),
ASPEED_PINCTRL_GROUP(UART6),
+   ASPEED_PINCTRL_GROUP(USB11D1),
+   ASPEED_PINCTRL_GROUP(USB11H2),
+   ASPEED_PINCTRL_GROUP(USB2D1),
+   ASPEED_PINCTRL_GROUP(USB2H1),
ASPEED_PINCTRL_GROUP(USBCKI),

[PATCH v2 0/4] pinctrl: Add USB support for Aspeed SoCs

[Andrew Jeffery]

Hello,

Here's v2 of the Aspeed pinctrl USB patches. It addresses the minor feedback on
the original series[1], amounting to commit message changes for the bindings
patches.

[1] https://lkml.org/lkml/2017/6/26/854

Please review!

Cheers,

Andrew

Andrew Jeffery (4):
  dt-bindings: pinctrl: aspeed: Add g4 USB functions
  dt-bindings: pinctrl: aspeed: Add g5 USB functions
  pinctrl: aspeed: g4: Add USB device and host support
  pinctrl: aspeed: g5: Add USB device and host support

 .../devicetree/bindings/pinctrl/pinctrl-aspeed.txt |  8 ++-
 drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c | 66 +++---
 drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 58 ++-
 3 files changed, 121 insertions(+), 11 deletions(-)

-- 
2.11.0

[PATCH v2 3/4] pinctrl: aspeed: g4: Add USB device and host support

[Andrew Jeffery]

Implement the AST2400 USB functions as described by the devicetree
bindings. Three ports are fully documented in the datasheet and exposed
through the bindings and pinctrl, though there are remnants of
documentation for a fourth port muxed with GPIO pins GPIOQ6 and GPIOQ7.
The implementation is updated to reflect this but the function and
group are not exposed.

Disregarding the mostly undocumented fourth port, the USB functions are
an outlier with respect to the rest of the muxed functionality on the
AST2400 as GPIO is not supported on these pins.

Signed-off-by: Andrew Jeffery 
---
 drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c | 66 ++
 1 file changed, 59 insertions(+), 7 deletions(-)

diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c 
b/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
index cf3106cec048..df56e58b05c1 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
@@ -1006,15 +1006,23 @@ SS_PIN_DECL(H3, GPIOQ5, SDA14);
 
 FUNC_GROUP_DECL(I2C14, H4, H3);
 
-#define DASH9028_DESC  SIG_DESC_SET(SCU90, 28)
+/*
+ * There are several opportunities to document USB port 4 in the datasheet, but
+ * it is only mentioned in one location. Particularly, the Multi-function Pins
+ * Mapping and Control table in the datasheet elides the signal names,
+ * suggesting that port 4 may not actually be functional. As such we define the
+ * signal names and control bit, but don't export the capability's function or
+ * group.
+ */
+#define USB11H3_DESC   SIG_DESC_SET(SCU90, 28)
 
 #define H2 134
-SIG_EXPR_LIST_DECL_SINGLE(DASHH2, DASHH2, DASH9028_DESC);
-SS_PIN_DECL(H2, GPIOQ6, DASHH2);
+SIG_EXPR_LIST_DECL_SINGLE(USB11HDP3, USB11H3, USB11H3_DESC);
+SS_PIN_DECL(H2, GPIOQ6, USB11HDP3);
 
 #define H1 135
-SIG_EXPR_LIST_DECL_SINGLE(DASHH1, DASHH1, DASH9028_DESC);
-SS_PIN_DECL(H1, GPIOQ7, DASHH1);
+SIG_EXPR_LIST_DECL_SINGLE(USB11HDN3, USB11H3, USB11H3_DESC);
+SS_PIN_DECL(H1, GPIOQ7, USB11HDN3);
 
 #define V20 136
 SSSF_PIN_DECL(V20, GPIOR0, ROMCS1, SIG_DESC_SET(SCU88, 24));
@@ -1706,10 +1714,42 @@ FUNC_GROUP_DECL(VPO12, U21, T19, V22, U20, R22, P18, 
P19, P20, P21, P22, M19,
 FUNC_GROUP_DECL(VPO24, U21, T19, V22, U20, L22, K18, V21, W22, R22, P18, P19,
P20, P21, P22, M19, M20, M21, M22, L18, L19);
 
+#define USB11H2_DESC   SIG_DESC_SET(SCU90, 3)
+#define USB11D1_DESC   SIG_DESC_BIT(SCU90, 3, 0)
+
+#define K4 220
+SIG_EXPR_LIST_DECL_SINGLE(USB11HDP2, USB11H2, USB11H2_DESC);
+SIG_EXPR_LIST_DECL_SINGLE(USB11DP1, USB11D1, USB11D1_DESC);
+MS_PIN_DECL_(K4, SIG_EXPR_LIST_PTR(USB11HDP2), SIG_EXPR_LIST_PTR(USB11DP1));
+
+#define K3 221
+SIG_EXPR_LIST_DECL_SINGLE(USB11HDN1, USB11H2, USB11H2_DESC);
+SIG_EXPR_LIST_DECL_SINGLE(USB11DDN1, USB11D1, USB11D1_DESC);
+MS_PIN_DECL_(K3, SIG_EXPR_LIST_PTR(USB11HDN1), SIG_EXPR_LIST_PTR(USB11DDN1));
+
+FUNC_GROUP_DECL(USB11H2, K4, K3);
+FUNC_GROUP_DECL(USB11D1, K4, K3);
+
+#define USB2H1_DESCSIG_DESC_SET(SCU90, 29)
+#define USB2D1_DESCSIG_DESC_BIT(SCU90, 29, 0)
+
+#define AB21 222
+SIG_EXPR_LIST_DECL_SINGLE(USB2HDP1, USB2H1, USB2H1_DESC);
+SIG_EXPR_LIST_DECL_SINGLE(USB2DDP1, USB2D1, USB2D1_DESC);
+MS_PIN_DECL_(AB21, SIG_EXPR_LIST_PTR(USB2HDP1), SIG_EXPR_LIST_PTR(USB2DDP1));
+
+#define AB20 223
+SIG_EXPR_LIST_DECL_SINGLE(USB2HDN1, USB2H1, USB2H1_DESC);
+SIG_EXPR_LIST_DECL_SINGLE(USB2DDN1, USB2D1, USB2D1_DESC);
+MS_PIN_DECL_(AB20, SIG_EXPR_LIST_PTR(USB2HDN1), SIG_EXPR_LIST_PTR(USB2DDN1));
+
+FUNC_GROUP_DECL(USB2H1, AB21, AB20);
+FUNC_GROUP_DECL(USB2D1, AB21, AB20);
+
 /* Note we account for GPIOY4-GPIOY7 even though they're not valid, thus 216
- * pins becomes 220.
+ * pins becomes 220. Four additional non-GPIO-capable pins are present for USB.
  */
-#define ASPEED_G4_NR_PINS 220
+#define ASPEED_G4_NR_PINS 224
 
 /* Pins, groups and functions are sort(1):ed alphabetically for sanity */
 
@@ -1749,6 +1789,8 @@ static struct pinctrl_pin_desc 
aspeed_g4_pins[ASPEED_G4_NR_PINS] = {
ASPEED_PINCTRL_PIN(AB5),
ASPEED_PINCTRL_PIN(AB6),
ASPEED_PINCTRL_PIN(AB7),
+   ASPEED_PINCTRL_PIN(AB20),
+   ASPEED_PINCTRL_PIN(AB21),
ASPEED_PINCTRL_PIN(B1),
ASPEED_PINCTRL_PIN(B10),
ASPEED_PINCTRL_PIN(B11),
@@ -1848,6 +1890,8 @@ static struct pinctrl_pin_desc 
aspeed_g4_pins[ASPEED_G4_NR_PINS] = {
ASPEED_PINCTRL_PIN(J5),
ASPEED_PINCTRL_PIN(K18),
ASPEED_PINCTRL_PIN(K20),
+   ASPEED_PINCTRL_PIN(K3),
+   ASPEED_PINCTRL_PIN(K4),
ASPEED_PINCTRL_PIN(K5),
ASPEED_PINCTRL_PIN(L1),
ASPEED_PINCTRL_PIN(L18),
@@ -2070,6 +2114,10 @@ static const struct aspeed_pin_group aspeed_g4_groups[] 
= {
ASPEED_PINCTRL_GROUP(TXD3),
ASPEED_PINCTRL_GROUP(TXD4),
ASPEED_PINCTRL_GROUP(UART6),
+   ASPEED_PINCTRL_GROUP(USB11D1),
+   ASPEED_PINCTRL_GROUP(USB11H2),
+   ASPEED_PINCTRL_GROUP(USB2D1),
+   ASPEED_PINCTRL_GROUP(USB2H1),
ASPEED_PINCTRL_GROUP(USBCKI),
ASPEED_PINCTRL_GROUP(VGABIOS_ROM),

[PATCH v2 0/4] pinctrl: Add USB support for Aspeed SoCs

[Andrew Jeffery]

Hello,

Here's v2 of the Aspeed pinctrl USB patches. It addresses the minor feedback on
the original series[1], amounting to commit message changes for the bindings
patches.

[1] https://lkml.org/lkml/2017/6/26/854

Please review!

Cheers,

Andrew

Andrew Jeffery (4):
  dt-bindings: pinctrl: aspeed: Add g4 USB functions
  dt-bindings: pinctrl: aspeed: Add g5 USB functions
  pinctrl: aspeed: g4: Add USB device and host support
  pinctrl: aspeed: g5: Add USB device and host support

 .../devicetree/bindings/pinctrl/pinctrl-aspeed.txt |  8 ++-
 drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c | 66 +++---
 drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 58 ++-
 3 files changed, 121 insertions(+), 11 deletions(-)

-- 
2.11.0

[PATCH v2 1/4] dt-bindings: pinctrl: aspeed: Add g4 USB functions

[Andrew Jeffery]

The AST2400 contains several USB controllers:

* USB 1.1 Host Controller
* USB 2.0 Host Controller
* USB 2.0 Virtual Hub
* USB 1.1 HID Controller

Pins for three ports are routed to the three controllers such that:

* Port 1 is a dedicated USB 1.1 host port
* Port 2 is shared between the USB 1.1 host and HID controllers
* Port 3 is shared between the USB 2.0 host and Hub controllers

As the pins for port 1 are fixed function there is no associated mux
function or group described in the bindings. Ports 2 and 3 are muxed as
above, and the table below describes the mapping between pinmux function
names and ports:

Port  | USB Version  | USB Mode  | Mux Function
--|--|---|-
1 | 1.1  | Host  | -
2 | 1.1  | Host  | USB11H2
2 | 1.1  | HID   | USB11D1
3 | 2.0  | Host  | USB2H1
3 | 2.0  | Device| USB2D1

Signed-off-by: Andrew Jeffery 
Acked-by: Rob Herring 
---
v1 -> v2:

* Updated the commit message to clarify HID details

 Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
index ca01710ee29a..09142dab47db 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
@@ -69,8 +69,9 @@ PWM1 PWM2 PWM3 PWM4 PWM5 PWM6 PWM7 RGMII1 RGMII2 RMII1 RMII2 
ROM16 ROM8 ROMCS1
 ROMCS2 ROMCS3 ROMCS4 RXD1 RXD2 RXD3 RXD4 SALT1 SALT2 SALT3 SALT4 SD1 SD2 SGPMCK
 SGPMI SGPMLD SGPMO SGPSCK SGPSI0 SGPSI1 SGPSLD SIOONCTRL SIOPBI SIOPBO SIOPWREQ
 SIOPWRGD SIOS3 SIOS5 SIOSCI SPI1 SPI1DEBUG SPI1PASSTHRU SPICS1 TIMER3 TIMER4
-TIMER5 TIMER6 TIMER7 TIMER8 TXD1 TXD2 TXD3 TXD4 UART6 USBCKI VGABIOS_ROM VGAHS
-VGAVS VPI18 VPI24 VPI30 VPO12 VPO24 WDTRST1 WDTRST2
+TIMER5 TIMER6 TIMER7 TIMER8 TXD1 TXD2 TXD3 TXD4 UART6 USB11D1 USB11H2 USB2D1
+USB2H1 USBCKI VGABIOS_ROM VGAHS VGAVS VPI18 VPI24 VPI30 VPO12 VPO24 WDTRST1
+WDTRST2
 
 aspeed,ast2500-pinctrl, aspeed,g5-pinctrl:
 
-- 
2.11.0

[PATCH v2 1/4] dt-bindings: pinctrl: aspeed: Add g4 USB functions

[Andrew Jeffery]

The AST2400 contains several USB controllers:

* USB 1.1 Host Controller
* USB 2.0 Host Controller
* USB 2.0 Virtual Hub
* USB 1.1 HID Controller

Pins for three ports are routed to the three controllers such that:

* Port 1 is a dedicated USB 1.1 host port
* Port 2 is shared between the USB 1.1 host and HID controllers
* Port 3 is shared between the USB 2.0 host and Hub controllers

As the pins for port 1 are fixed function there is no associated mux
function or group described in the bindings. Ports 2 and 3 are muxed as
above, and the table below describes the mapping between pinmux function
names and ports:

Port  | USB Version  | USB Mode  | Mux Function
--|--|---|-
1 | 1.1  | Host  | -
2 | 1.1  | Host  | USB11H2
2 | 1.1  | HID   | USB11D1
3 | 2.0  | Host  | USB2H1
3 | 2.0  | Device| USB2D1

Signed-off-by: Andrew Jeffery 
Acked-by: Rob Herring 
---
v1 -> v2:

* Updated the commit message to clarify HID details

 Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
index ca01710ee29a..09142dab47db 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
@@ -69,8 +69,9 @@ PWM1 PWM2 PWM3 PWM4 PWM5 PWM6 PWM7 RGMII1 RGMII2 RMII1 RMII2 
ROM16 ROM8 ROMCS1
 ROMCS2 ROMCS3 ROMCS4 RXD1 RXD2 RXD3 RXD4 SALT1 SALT2 SALT3 SALT4 SD1 SD2 SGPMCK
 SGPMI SGPMLD SGPMO SGPSCK SGPSI0 SGPSI1 SGPSLD SIOONCTRL SIOPBI SIOPBO SIOPWREQ
 SIOPWRGD SIOS3 SIOS5 SIOSCI SPI1 SPI1DEBUG SPI1PASSTHRU SPICS1 TIMER3 TIMER4
-TIMER5 TIMER6 TIMER7 TIMER8 TXD1 TXD2 TXD3 TXD4 UART6 USBCKI VGABIOS_ROM VGAHS
-VGAVS VPI18 VPI24 VPI30 VPO12 VPO24 WDTRST1 WDTRST2
+TIMER5 TIMER6 TIMER7 TIMER8 TXD1 TXD2 TXD3 TXD4 UART6 USB11D1 USB11H2 USB2D1
+USB2H1 USBCKI VGABIOS_ROM VGAHS VGAVS VPI18 VPI24 VPI30 VPO12 VPO24 WDTRST1
+WDTRST2
 
 aspeed,ast2500-pinctrl, aspeed,g5-pinctrl:
 
-- 
2.11.0

[PATCH v2] staging: unisys: visorbus: Constify attribute_group structures.

[Arvind Yadav]

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by  work
with const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
Changes in v2:
  Change log typo was not correct.

 drivers/staging/unisys/visorbus/visorbus_main.c | 4 ++--
 drivers/staging/unisys/visorbus/visorchipset.c  | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 1c785dd..bba10dc 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -249,7 +249,7 @@ static ssize_t typename_show(struct device *dev, struct 
device_attribute *attr,
NULL
 };
 
-static struct attribute_group channel_attr_grp = {
+static const struct attribute_group channel_attr_grp = {
.name = "channel",
.attrs = channel_attrs,
 };
@@ -340,7 +340,7 @@ static ssize_t channel_id_show(struct device *dev,
NULL
 };
 
-static struct attribute_group dev_attr_grp = {
+static const struct attribute_group dev_attr_grp = {
.attrs = dev_attrs,
 };
 
diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index 2215056..798a92e 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -1146,7 +1146,7 @@ static ssize_t deviceenabled_store(struct device *dev,
NULL
 };
 
-static struct attribute_group visorchipset_parahotplug_group = {
+static const struct attribute_group visorchipset_parahotplug_group = {
.name = "parahotplug",
.attrs = visorchipset_parahotplug_attrs
 };
-- 
1.9.1

[PATCH v2] staging: unisys: visorbus: Constify attribute_group structures.

[Arvind Yadav]

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by  work
with const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
Changes in v2:
  Change log typo was not correct.

 drivers/staging/unisys/visorbus/visorbus_main.c | 4 ++--
 drivers/staging/unisys/visorbus/visorchipset.c  | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 1c785dd..bba10dc 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -249,7 +249,7 @@ static ssize_t typename_show(struct device *dev, struct 
device_attribute *attr,
NULL
 };
 
-static struct attribute_group channel_attr_grp = {
+static const struct attribute_group channel_attr_grp = {
.name = "channel",
.attrs = channel_attrs,
 };
@@ -340,7 +340,7 @@ static ssize_t channel_id_show(struct device *dev,
NULL
 };
 
-static struct attribute_group dev_attr_grp = {
+static const struct attribute_group dev_attr_grp = {
.attrs = dev_attrs,
 };
 
diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index 2215056..798a92e 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -1146,7 +1146,7 @@ static ssize_t deviceenabled_store(struct device *dev,
NULL
 };
 
-static struct attribute_group visorchipset_parahotplug_group = {
+static const struct attribute_group visorchipset_parahotplug_group = {
.name = "parahotplug",
.attrs = visorchipset_parahotplug_attrs
 };
-- 
1.9.1

[PATCH] arm64: defconfig: enable CONFIG_UNIPHIER_WATCHDOG

[Keiji Hayashibara]

Enable the watchdog driver for UniPhier SoC

Signed-off-by: Keiji Hayashibara 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 6c7d147..5d204a4 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -310,6 +310,7 @@ CONFIG_WATCHDOG=y
 CONFIG_S3C2410_WATCHDOG=y
 CONFIG_MESON_GXBB_WATCHDOG=m
 CONFIG_MESON_WATCHDOG=m
+CONFIG_UNIPHIER_WATCHDOG=y
 CONFIG_RENESAS_WDT=y
 CONFIG_BCM2835_WDT=y
 CONFIG_MFD_CROS_EC=y
-- 
2.7.4

[PATCH] arm64: defconfig: enable CONFIG_UNIPHIER_WATCHDOG

[Keiji Hayashibara]

Enable the watchdog driver for UniPhier SoC

Signed-off-by: Keiji Hayashibara 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 6c7d147..5d204a4 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -310,6 +310,7 @@ CONFIG_WATCHDOG=y
 CONFIG_S3C2410_WATCHDOG=y
 CONFIG_MESON_GXBB_WATCHDOG=m
 CONFIG_MESON_WATCHDOG=m
+CONFIG_UNIPHIER_WATCHDOG=y
 CONFIG_RENESAS_WDT=y
 CONFIG_BCM2835_WDT=y
 CONFIG_MFD_CROS_EC=y
-- 
2.7.4

Re: [PATCH v2 01/22] docs: fpga: add a document for Intel FPGA driver overview

[Greg KH]

On Mon, Jul 17, 2017 at 03:14:29PM -0500, Alan Tull wrote:
> > Also, we're thinking that some operations require that you first "acquire
> > ownership" of the respective device, which I believe maps more easily to
> > open() and ioctls than sysfs.
> >
> > Thanks
> > - Enno
> 
> Yes, sysfs doesn't implement open/close so there's no clean way to
> have one thing in userspace that owns the interface.  It's a shame.

No, that was by design :)

Re: [PATCH v2 01/22] docs: fpga: add a document for Intel FPGA driver overview

[Greg KH]

On Mon, Jul 17, 2017 at 03:14:29PM -0500, Alan Tull wrote:
> > Also, we're thinking that some operations require that you first "acquire
> > ownership" of the respective device, which I believe maps more easily to
> > open() and ioctls than sysfs.
> >
> > Thanks
> > - Enno
> 
> Yes, sysfs doesn't implement open/close so there's no clean way to
> have one thing in userspace that owns the interface.  It's a shame.

No, that was by design :)

KINDLY REPLY URGENTLY

[IBRAHIM KABORE]

Dear Friend

I am contacting you on a business deal of $9,500,000.00 Million United States 
Dollars, ready for transfer into your own personal account and if we make this 
claim, we will share it on the ratio of 50% / 50% basis, I would like to assure 
you that it be 100% risk free and it will be legally backed up with government 
approval. Once you are interested to transact this business with me, kindly 
give me your consent response immediately.

Hoping to hear from you.

My regards,
Mr Ibrahim Kabore
EMAIL,ibrahim.kabore@hotmail. com

KINDLY REPLY URGENTLY

[IBRAHIM KABORE]

Dear Friend

I am contacting you on a business deal of $9,500,000.00 Million United States 
Dollars, ready for transfer into your own personal account and if we make this 
claim, we will share it on the ratio of 50% / 50% basis, I would like to assure 
you that it be 100% risk free and it will be legally backed up with government 
approval. Once you are interested to transact this business with me, kindly 
give me your consent response immediately.

Hoping to hear from you.

My regards,
Mr Ibrahim Kabore
EMAIL,ibrahim.kabore@hotmail. com

RE: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization earlier

[Zheng, Lv]

Hi,

Can the problem be fixed by invoking acpi_put_table() for mapped DMAR table?

Thanks
Lv

> From: Dou Liyang [mailto:douly.f...@cn.fujitsu.com]
> Sent: Friday, July 14, 2017 1:53 PM
> To: x...@kernel.org; linux-kernel@vger.kernel.org
> Cc: t...@linutronix.de; mi...@kernel.org; h...@zytor.com; 
> ebied...@xmission.com; b...@redhat.com;
> pet...@infradead.org; izumi.t...@jp.fujitsu.com; 
> tokunaga.kei...@jp.fujitsu.com; Dou Liyang
> ; linux-a...@vger.kernel.org; Rafael J. Wysocki 
> ; Zheng,
> Lv ; Julian Wollrath 
> Subject: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization 
> earlier
> 
> Linux uses acpi_early_init() to put the ACPI table management into
> the late stage from the early stage where the mapped ACPI tables is
> temporary and should be unmapped.
> 
> But, now initializing interrupt delivery mode should map and parse the
> DMAR table earlier in the early stage. This causes an ACPI error when
> Linux reallocates the ACPI root tables. Because Linux doesn't unmapped
> the DMAR table after using in the early stage.
> 
> Invoke acpi_early_init() earlier before late_time_init(), Keep the DMAR
> be mapped and parsed in late stage like before.
> 
> Reported-by: Xiaolong Ye 
> Signed-off-by: Dou Liyang 
> Cc: linux-a...@vger.kernel.org
> Cc: Rafael J. Wysocki 
> Cc: Zheng, Lv 
> Cc: Julian Wollrath 
> ---
> Test in my own PC(Lenovo M4340).
> Ask help for doing regression testing for the bug said in commit c4e1acbb35e4
> ("ACPI / init: Invoke early ACPI initialization later").
> 
>  init/main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/init/main.c b/init/main.c
> index df58a41..7a09467 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -654,12 +654,12 @@ asmlinkage __visible void __init start_kernel(void)
>   kmemleak_init();
>   setup_per_cpu_pageset();
>   numa_policy_init();
> + acpi_early_init();
>   if (late_time_init)
>   late_time_init();
>   calibrate_delay();
>   pidmap_init();
>   anon_vma_init();
> - acpi_early_init();
>  #ifdef CONFIG_X86
>   if (efi_enabled(EFI_RUNTIME_SERVICES))
>   efi_enter_virtual_mode();
> --
> 2.5.5
> 
> 

RE: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization earlier

[Zheng, Lv]

Hi,

Can the problem be fixed by invoking acpi_put_table() for mapped DMAR table?

Thanks
Lv

> From: Dou Liyang [mailto:douly.f...@cn.fujitsu.com]
> Sent: Friday, July 14, 2017 1:53 PM
> To: x...@kernel.org; linux-kernel@vger.kernel.org
> Cc: t...@linutronix.de; mi...@kernel.org; h...@zytor.com; 
> ebied...@xmission.com; b...@redhat.com;
> pet...@infradead.org; izumi.t...@jp.fujitsu.com; 
> tokunaga.kei...@jp.fujitsu.com; Dou Liyang
> ; linux-a...@vger.kernel.org; Rafael J. Wysocki 
> ; Zheng,
> Lv ; Julian Wollrath 
> Subject: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization 
> earlier
> 
> Linux uses acpi_early_init() to put the ACPI table management into
> the late stage from the early stage where the mapped ACPI tables is
> temporary and should be unmapped.
> 
> But, now initializing interrupt delivery mode should map and parse the
> DMAR table earlier in the early stage. This causes an ACPI error when
> Linux reallocates the ACPI root tables. Because Linux doesn't unmapped
> the DMAR table after using in the early stage.
> 
> Invoke acpi_early_init() earlier before late_time_init(), Keep the DMAR
> be mapped and parsed in late stage like before.
> 
> Reported-by: Xiaolong Ye 
> Signed-off-by: Dou Liyang 
> Cc: linux-a...@vger.kernel.org
> Cc: Rafael J. Wysocki 
> Cc: Zheng, Lv 
> Cc: Julian Wollrath 
> ---
> Test in my own PC(Lenovo M4340).
> Ask help for doing regression testing for the bug said in commit c4e1acbb35e4
> ("ACPI / init: Invoke early ACPI initialization later").
> 
>  init/main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/init/main.c b/init/main.c
> index df58a41..7a09467 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -654,12 +654,12 @@ asmlinkage __visible void __init start_kernel(void)
>   kmemleak_init();
>   setup_per_cpu_pageset();
>   numa_policy_init();
> + acpi_early_init();
>   if (late_time_init)
>   late_time_init();
>   calibrate_delay();
>   pidmap_init();
>   anon_vma_init();
> - acpi_early_init();
>  #ifdef CONFIG_X86
>   if (efi_enabled(EFI_RUNTIME_SERVICES))
>   efi_enter_virtual_mode();
> --
> 2.5.5
> 
> 

Re: [PATCH net-next v2 1/4] dt-bindings: net: mediatek: add support for MediaTek MT7623 and MT7622 SoC

[Sean Wang]

On Mon, 2017-07-17 at 15:38 +0200, Andrew Lunn wrote:
> On Mon, Jul 17, 2017 at 06:06:22PM +0800, sean.w...@mediatek.com wrote:
> > From: Sean Wang 
> > 
> > The patch adds the supplements in the dt-binding document for MediaTek
> > MT7622 SoC with extra SGMII system controller and relevant clock consumers
> > listed as the requirements for those SoCs equipped with the SGMII circuit.
> > Also, add the missing binding information for MT7623 SoC here which relies
> > on the fallback binding of MT2701.
> > 
> > Signed-off-by: Sean Wang 
> > ---
> >  Documentation/devicetree/bindings/net/mediatek-net.txt | 12 +---
> >  1 file changed, 9 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt 
> > b/Documentation/devicetree/bindings/net/mediatek-net.txt
> > index c7194e8..1d1168b 100644
> > --- a/Documentation/devicetree/bindings/net/mediatek-net.txt
> > +++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
> > @@ -7,24 +7,30 @@ have dual GMAC each represented by a child node..
> >  * Ethernet controller node
> >  
> >  Required properties:
> > -- compatible: Should be "mediatek,mt2701-eth"
> > +- compatible: Should be
> > +   "mediatek,mt2701-eth": for MT2701 SoC
> > +   "mediatek,mt7623-eth", "mediatek,mt2701-eth": for MT7623 SoC
> 
> Hi Sean
> 
> We appear to have "mediatek,mt2701-eth" twice.
> 

Hi, Andrew

mt7623-eth supported up to now currently rely on the fallback binding of
mt2701-eth

in fact, the logic could be commonly found in many driver such as mtk
sysirq such as [1] did, so i felt this usage should not make something
wrong.


[1] https://patchwork.kernel.org/patch/9739827/


>Andrew

Re: [PATCH net-next v2 1/4] dt-bindings: net: mediatek: add support for MediaTek MT7623 and MT7622 SoC

[Sean Wang]

On Mon, 2017-07-17 at 15:38 +0200, Andrew Lunn wrote:
> On Mon, Jul 17, 2017 at 06:06:22PM +0800, sean.w...@mediatek.com wrote:
> > From: Sean Wang 
> > 
> > The patch adds the supplements in the dt-binding document for MediaTek
> > MT7622 SoC with extra SGMII system controller and relevant clock consumers
> > listed as the requirements for those SoCs equipped with the SGMII circuit.
> > Also, add the missing binding information for MT7623 SoC here which relies
> > on the fallback binding of MT2701.
> > 
> > Signed-off-by: Sean Wang 
> > ---
> >  Documentation/devicetree/bindings/net/mediatek-net.txt | 12 +---
> >  1 file changed, 9 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt 
> > b/Documentation/devicetree/bindings/net/mediatek-net.txt
> > index c7194e8..1d1168b 100644
> > --- a/Documentation/devicetree/bindings/net/mediatek-net.txt
> > +++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
> > @@ -7,24 +7,30 @@ have dual GMAC each represented by a child node..
> >  * Ethernet controller node
> >  
> >  Required properties:
> > -- compatible: Should be "mediatek,mt2701-eth"
> > +- compatible: Should be
> > +   "mediatek,mt2701-eth": for MT2701 SoC
> > +   "mediatek,mt7623-eth", "mediatek,mt2701-eth": for MT7623 SoC
> 
> Hi Sean
> 
> We appear to have "mediatek,mt2701-eth" twice.
> 

Hi, Andrew

mt7623-eth supported up to now currently rely on the fallback binding of
mt2701-eth

in fact, the logic could be commonly found in many driver such as mtk
sysirq such as [1] did, so i felt this usage should not make something
wrong.


[1] https://patchwork.kernel.org/patch/9739827/


>Andrew

Re: [PATCH V3 3/4] spmi: pmic-arb: add support for HW version 5

[kgunda]

On 2017-07-14 23:00, Stephen Boyd wrote:

On 07/11, Kiran Gunda wrote:
@@ -420,7 +440,8 @@ static int pmic_arb_write_cmd(struct 
spmi_controller *ctrl, u8 opc, u8 sid,




Mostly style nitpicks!


Will check and address in the next patch.

/* Start the transaction */
pmic_arb_base_write(pmic_arb, offset + PMIC_ARB_CMD, cmd);
-   rc = pmic_arb_wait_for_done(ctrl, pmic_arb->wr_base, sid, addr);
+   rc = pmic_arb_wait_for_done(ctrl, pmic_arb->wr_base, sid, addr,
+   PMIC_ARB_CHANNEL_RW);
raw_spin_unlock_irqrestore(_arb->lock, flags);

return rc;
@@ -681,12 +702,19 @@ static int 
qpnpint_irq_domain_dt_translate(struct irq_domain *d,

ppid = intspec[0] << 8 | intspec[1];
rc = pmic_arb->ver_ops->ppid_to_apid(pmic_arb, ppid);
if (rc < 0) {
-		dev_err(_arb->spmic->dev, "failed to xlate sid = 0x%x, periph 
= 0x%x, irq = %x rc = %d\n",
+		dev_err(_arb->spmic->dev, "failed to xlate sid = %#x, periph = 
%#x, irq = %u rc = %d\n",

intspec[0], intspec[1], intspec[2], rc);


Unrelated change?


This just to print the irq number in decimal format.

return rc;
}

apid = rc;
+   if (pmic_arb->apid_data[apid].irq_ee != pmic_arb->ee) {
+		dev_err(_arb->spmic->dev, "failed to xlate sid = %#x, periph = 
%#x, irq = %u: ee=%u but owner=%u\n",

+   intspec[0], intspec[1], intspec[2], pmic_arb->ee,
+   pmic_arb->apid_data[apid].irq_ee);
+   return -ENODEV;
+   }
+
 	/* Keep track of {max,min}_apid for bounding search during interrupt 
*/

if (apid > pmic_arb->max_apid)
pmic_arb->max_apid = apid;
return apid_valid & ~PMIC_ARB_APID_VALID;
 }

+static int pmic_arb_read_apid_map_v5(struct spmi_pmic_arb *pmic_arb)
+{
+   struct apid_data *apid_info = pmic_arb->apid_data;
+   struct apid_data *prev_apid_info;
+   u16 i, j, ppid;
+   bool valid, is_irq_ee;
+   u32 regval, offset;
+
+   /*
+	 * PMIC_ARB_REG_CHNL is a table in HW mapping APID (channel) to 
PPID.


Is this comment stale? PMIC_ARB_REG_CHNL macro was deleted?


will remove this line in the next patch.
+	 * ppid_to_apid is an in-memory invert of that table.  In order to 
allow
+	 * multiple EEs to write to a single PPID in arbiter version 5, 
there
+	 * is more than one APID mapped to each PPID.  The owner field for 
each
+	 * of these mappings specifies the EE which is allowed to write to 
the

+* APID.  The owner of the last (highest) APID for a given PPID will
+* receive interrupts from the PPID.
+*/
+   for (i = 0; ; i++, apid_info++) {
+   offset = pmic_arb->ver_ops->apid_map_offset(i);
+   if (offset >= pmic_arb->core_size)
+   break;
+
+   regval = readl_relaxed(pmic_arb->core + offset);
+   if (!regval)
+   continue;
+   ppid = (regval >> 8) & PMIC_ARB_PPID_MASK;
+   is_irq_ee = PMIC_ARB_CHAN_IS_IRQ_OWNER(regval);
+
+   regval = readl_relaxed(pmic_arb->cnfg +
+ SPMI_OWNERSHIP_TABLE_REG(i));
+   apid_info->write_ee = SPMI_OWNERSHIP_PERIPH2OWNER(regval);
+
+   apid_info->irq_ee = is_irq_ee ?
+   apid_info->write_ee : INVALID_EE;


Perhaps apid_info can be renamed to apidd (for apid descriptor)
or apidi (for apid info) and then this line is short enough to
fit on one line?


ok. will change it in next patch.

+
+   valid = pmic_arb->ppid_to_apid[ppid] & PMIC_ARB_APID_VALID;
+   j = pmic_arb->ppid_to_apid[ppid] & ~PMIC_ARB_APID_VALID;


Maybe j can be 'apid'. Slightly more informative and usually 'j'
is reserved for iterating, which in this case we're not doing.
We're just directly indexing an apid into a table.


Will change in the next patch.

+   prev_apid_info = _arb->apid_data[j];
+
+   if (valid && is_irq_ee &&
+   prev_apid_info->write_ee == pmic_arb->ee) {
+   /*
+* Duplicate PPID mapping after the one for this EE;
+* override the irq owner
+*/
+   prev_apid_info->irq_ee = apid_info->irq_ee;
+   } else if (!valid || is_irq_ee) {
+   /* First PPID mapping or duplicate for another EE */
+   pmic_arb->ppid_to_apid[ppid] = i | PMIC_ARB_APID_VALID;
+   }
+
+   apid_info->ppid = ppid;
+   pmic_arb->last_apid = i;
+   }
+
+   /* Dump the mapping table for debug purposes. */
+   dev_dbg(_arb->spmic->dev, "PPID APID Write-EE IRQ-EE\n");
+   for (ppid = 0; ppid < PMIC_ARB_MAX_PPID; ppid++) {
+   valid = pmic_arb->ppid_to_apid[ppid] & PMIC_ARB_APID_VALID;
+   i = 

Re: [PATCH V3 3/4] spmi: pmic-arb: add support for HW version 5

[kgunda]

On 2017-07-14 23:00, Stephen Boyd wrote:

On 07/11, Kiran Gunda wrote:
@@ -420,7 +440,8 @@ static int pmic_arb_write_cmd(struct 
spmi_controller *ctrl, u8 opc, u8 sid,




Mostly style nitpicks!


Will check and address in the next patch.

/* Start the transaction */
pmic_arb_base_write(pmic_arb, offset + PMIC_ARB_CMD, cmd);
-   rc = pmic_arb_wait_for_done(ctrl, pmic_arb->wr_base, sid, addr);
+   rc = pmic_arb_wait_for_done(ctrl, pmic_arb->wr_base, sid, addr,
+   PMIC_ARB_CHANNEL_RW);
raw_spin_unlock_irqrestore(_arb->lock, flags);

return rc;
@@ -681,12 +702,19 @@ static int 
qpnpint_irq_domain_dt_translate(struct irq_domain *d,

ppid = intspec[0] << 8 | intspec[1];
rc = pmic_arb->ver_ops->ppid_to_apid(pmic_arb, ppid);
if (rc < 0) {
-		dev_err(_arb->spmic->dev, "failed to xlate sid = 0x%x, periph 
= 0x%x, irq = %x rc = %d\n",
+		dev_err(_arb->spmic->dev, "failed to xlate sid = %#x, periph = 
%#x, irq = %u rc = %d\n",

intspec[0], intspec[1], intspec[2], rc);


Unrelated change?


This just to print the irq number in decimal format.

return rc;
}

apid = rc;
+   if (pmic_arb->apid_data[apid].irq_ee != pmic_arb->ee) {
+		dev_err(_arb->spmic->dev, "failed to xlate sid = %#x, periph = 
%#x, irq = %u: ee=%u but owner=%u\n",

+   intspec[0], intspec[1], intspec[2], pmic_arb->ee,
+   pmic_arb->apid_data[apid].irq_ee);
+   return -ENODEV;
+   }
+
 	/* Keep track of {max,min}_apid for bounding search during interrupt 
*/

if (apid > pmic_arb->max_apid)
pmic_arb->max_apid = apid;
return apid_valid & ~PMIC_ARB_APID_VALID;
 }

+static int pmic_arb_read_apid_map_v5(struct spmi_pmic_arb *pmic_arb)
+{
+   struct apid_data *apid_info = pmic_arb->apid_data;
+   struct apid_data *prev_apid_info;
+   u16 i, j, ppid;
+   bool valid, is_irq_ee;
+   u32 regval, offset;
+
+   /*
+	 * PMIC_ARB_REG_CHNL is a table in HW mapping APID (channel) to 
PPID.


Is this comment stale? PMIC_ARB_REG_CHNL macro was deleted?


will remove this line in the next patch.
+	 * ppid_to_apid is an in-memory invert of that table.  In order to 
allow
+	 * multiple EEs to write to a single PPID in arbiter version 5, 
there
+	 * is more than one APID mapped to each PPID.  The owner field for 
each
+	 * of these mappings specifies the EE which is allowed to write to 
the

+* APID.  The owner of the last (highest) APID for a given PPID will
+* receive interrupts from the PPID.
+*/
+   for (i = 0; ; i++, apid_info++) {
+   offset = pmic_arb->ver_ops->apid_map_offset(i);
+   if (offset >= pmic_arb->core_size)
+   break;
+
+   regval = readl_relaxed(pmic_arb->core + offset);
+   if (!regval)
+   continue;
+   ppid = (regval >> 8) & PMIC_ARB_PPID_MASK;
+   is_irq_ee = PMIC_ARB_CHAN_IS_IRQ_OWNER(regval);
+
+   regval = readl_relaxed(pmic_arb->cnfg +
+ SPMI_OWNERSHIP_TABLE_REG(i));
+   apid_info->write_ee = SPMI_OWNERSHIP_PERIPH2OWNER(regval);
+
+   apid_info->irq_ee = is_irq_ee ?
+   apid_info->write_ee : INVALID_EE;


Perhaps apid_info can be renamed to apidd (for apid descriptor)
or apidi (for apid info) and then this line is short enough to
fit on one line?


ok. will change it in next patch.

+
+   valid = pmic_arb->ppid_to_apid[ppid] & PMIC_ARB_APID_VALID;
+   j = pmic_arb->ppid_to_apid[ppid] & ~PMIC_ARB_APID_VALID;


Maybe j can be 'apid'. Slightly more informative and usually 'j'
is reserved for iterating, which in this case we're not doing.
We're just directly indexing an apid into a table.


Will change in the next patch.

+   prev_apid_info = _arb->apid_data[j];
+
+   if (valid && is_irq_ee &&
+   prev_apid_info->write_ee == pmic_arb->ee) {
+   /*
+* Duplicate PPID mapping after the one for this EE;
+* override the irq owner
+*/
+   prev_apid_info->irq_ee = apid_info->irq_ee;
+   } else if (!valid || is_irq_ee) {
+   /* First PPID mapping or duplicate for another EE */
+   pmic_arb->ppid_to_apid[ppid] = i | PMIC_ARB_APID_VALID;
+   }
+
+   apid_info->ppid = ppid;
+   pmic_arb->last_apid = i;
+   }
+
+   /* Dump the mapping table for debug purposes. */
+   dev_dbg(_arb->spmic->dev, "PPID APID Write-EE IRQ-EE\n");
+   for (ppid = 0; ppid < PMIC_ARB_MAX_PPID; ppid++) {
+   valid = pmic_arb->ppid_to_apid[ppid] & PMIC_ARB_APID_VALID;
+   i = 

Re: [RFC PATCH 1/5] serial: arc: Remove __init marking from early write

[Greg KH]

On Tue, Jul 18, 2017 at 12:29:59PM +0800, Jeffy Chen wrote:
> The earlycon would be alive outside the init code in these cases:
> 1/ we have keep_bootcon in cmdline.
> 2/ we don't have a real console to switch to.
> 
> So remove the __init marking to avoid invalid memory access.
> 
> Signed-off-by: Jeffy Chen 
> ---
> 

I can't apply "RFC" patches.  If you have tested and found this series
to be correct, can you resend it without that on the patch?

thanks,

greg k-h

Re: [RFC PATCH 1/5] serial: arc: Remove __init marking from early write

[Greg KH]

On Tue, Jul 18, 2017 at 12:29:59PM +0800, Jeffy Chen wrote:
> The earlycon would be alive outside the init code in these cases:
> 1/ we have keep_bootcon in cmdline.
> 2/ we don't have a real console to switch to.
> 
> So remove the __init marking to avoid invalid memory access.
> 
> Signed-off-by: Jeffy Chen 
> ---
> 

I can't apply "RFC" patches.  If you have tested and found this series
to be correct, can you resend it without that on the patch?

thanks,

greg k-h

Re: [PATCH 2/2] arm64: dts: exynos: Add extcon property for TM2 and TM2E

[Krzysztof Kozlowski]

On Tue, Jun 20, 2017 at 04:12:24PM +0900, Dongwoo Lee wrote:
> Since commit 9840354ff429 ("usb: dwc3: Add dual-role support") dwc3
> node requires extcon property to be initialized as otg mode, and it
> can support dual-role mode operation.
> 
> Signed-off-by: Dongwoo Lee 
> ---
>  arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 1 +
>  1 file changed, 1 insertion(+)
> 

Thanks, applied.

Best regards,
Krzysztof

Re: [PATCH 2/2] arm64: dts: exynos: Add extcon property for TM2 and TM2E

[Krzysztof Kozlowski]

On Tue, Jun 20, 2017 at 04:12:24PM +0900, Dongwoo Lee wrote:
> Since commit 9840354ff429 ("usb: dwc3: Add dual-role support") dwc3
> node requires extcon property to be initialized as otg mode, and it
> can support dual-role mode operation.
> 
> Signed-off-by: Dongwoo Lee 
> ---
>  arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 1 +
>  1 file changed, 1 insertion(+)
> 

Thanks, applied.

Best regards,
Krzysztof

Re: [PATCH 1/2] arm64: dts: exynos: Fix wrong label for USB 3.0 controller node

[Krzysztof Kozlowski]

On Tue, Jun 20, 2017 at 04:12:23PM +0900, Dongwoo Lee wrote:
> Exynos5433 has two usb 3.0 controllers: usbhost and usbdrd. usbhost
> is host-only controller whereas usbdrd supports both peripheral and
> host mode. "drd" means dual-role device, so usbhost cannot be labeled
> with the name contains "drd". Howerver, the label usbdrd_dwc3_0 was
> used for usbhost's dwc3 node. It seems it obviously fault because TM2
> and TM2E doesn't use usbhost but dr_mode property is assigned to it.
> 
> This patch assigns the proper label for two dwc3 nodes, and apply
> changes to the related reference.
> 
> Signed-off-by: Dongwoo Lee 
> ---
>  arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 2 +-
>  arch/arm64/boot/dts/exynos/exynos5433.dtsi| 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 

Thanks, applied.

Best regards,
Krzysztof

Re: [PATCH 1/2] arm64: dts: exynos: Fix wrong label for USB 3.0 controller node

[Krzysztof Kozlowski]

On Tue, Jun 20, 2017 at 04:12:23PM +0900, Dongwoo Lee wrote:
> Exynos5433 has two usb 3.0 controllers: usbhost and usbdrd. usbhost
> is host-only controller whereas usbdrd supports both peripheral and
> host mode. "drd" means dual-role device, so usbhost cannot be labeled
> with the name contains "drd". Howerver, the label usbdrd_dwc3_0 was
> used for usbhost's dwc3 node. It seems it obviously fault because TM2
> and TM2E doesn't use usbhost but dr_mode property is assigned to it.
> 
> This patch assigns the proper label for two dwc3 nodes, and apply
> changes to the related reference.
> 
> Signed-off-by: Dongwoo Lee 
> ---
>  arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 2 +-
>  arch/arm64/boot/dts/exynos/exynos5433.dtsi| 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 

Thanks, applied.

Best regards,
Krzysztof

Re: panic, bisect to commit 7f1d4e58dabb "spmi: pmic-arb: optimize table lookups"

[Frank Rowand]

On 07/17/17 20:56, Rajendra Nayak wrote:
> 
> On 07/18/2017 09:12 AM, Frank Rowand wrote:
>> Hi Abhijeet,
>>
>> My qcom-apq8074-dragonboard panics on boot on v4.13-rc1.
>>
>> I bisected the problem to commit 7f1d4e58dabb, "spmi: pmic-arb:
>> optimize table lookups".
> 
> there's a fix on its way upstream,
> https://patchwork.kernel.org/patch/9810723/
> 

Thank you for the pointer to the patch.  After adding the patch, my
board still does not boot, but now has several different stack
dumps from various drivers.  I do not know if the new errors are
related to this patch or something entirely different.  I'll dig
into it tomorrow.

-Frank

Re: panic, bisect to commit 7f1d4e58dabb "spmi: pmic-arb: optimize table lookups"

[Frank Rowand]

On 07/17/17 20:56, Rajendra Nayak wrote:
> 
> On 07/18/2017 09:12 AM, Frank Rowand wrote:
>> Hi Abhijeet,
>>
>> My qcom-apq8074-dragonboard panics on boot on v4.13-rc1.
>>
>> I bisected the problem to commit 7f1d4e58dabb, "spmi: pmic-arb:
>> optimize table lookups".
> 
> there's a fix on its way upstream,
> https://patchwork.kernel.org/patch/9810723/
> 

Thank you for the pointer to the patch.  After adding the patch, my
board still does not boot, but now has several different stack
dumps from various drivers.  I do not know if the new errors are
related to this patch or something entirely different.  I'll dig
into it tomorrow.

-Frank

Re: [PATCH] staging: unisys: visorbus: constify attribute_group structures.

[Greg KH]

On Mon, Jul 17, 2017 at 09:36:58PM +, Kershner, David A wrote:
> > -Original Message-
> > From: Greg KH [mailto:g...@kroah.com]
> > Sent: Monday, July 17, 2017 8:38 AM
> > To: Arvind Yadav 
> > Cc: Kershner, David A ; Sell, Timothy C
> > ; Thompson, Bryan E.
> > ; jon.fri...@unisys.com; Binder, David
> > Anthony ; *S-Par-Maintainer
> > ; de...@driverdev.osuosl.org; linux-
> > ker...@vger.kernel.org
> > Subject: Re: [PATCH] staging: unisys: visorbus: constify attribute_group
> > structures.

Why is this in your email body?

> > 
> > On Mon, Jul 17, 2017 at 05:43:14PM +0530, Arvind Yadav wrote:
> > > Hi Greg,
> > >
> > >
> > > On Monday 17 July 2017 04:15 PM, Greg KH wrote:
> > > > On Mon, Jul 17, 2017 at 02:55:37PM +0530, Arvind Yadav wrote:
> > > > > attribute_groups are not supposed to change at runtime. All functions
> > > > > working with attribute_groups provided by  work
> > > > > with const attribute_group. So mark the non-const structs as const.
> > > > >
> > > > > Signed-off-by: Arvind Yadav 
> > > > > ---
> > > > >   drivers/staging/unisys/visorbus/visorbus_main.c | 4 ++--
> > > > >   drivers/staging/unisys/visorbus/visorchipset.c  | 2 +-
> > > > >   2 files changed, 3 insertions(+), 3 deletions(-)
> > > > Why not just use the ATTRIBUTE_GROUPS() macro for these?  Or is there
> > > > something that is preventing that?
> > > Yes, we can use. if we are only initializing '.attrs'.
> > > ATTRIBUTE_GROUPS() will not work if we will initialize other member of
> > > attribute_group like 'bin_attrs', 'is_visible', and  'name'.
> > 
> > That means you should redo this patch :)
> > 
> > Also, your changelog text had a typo, it is "attribute_group", not
> > "attribute_groups".
> > 
> 
> Greg, are you recommending that we shouldn't be setting the attribute_group
> .name field? What does it pick up if we don't specify it?

Why do you want a name for your group?  Anyway, yes, you are right, if
you set a .name, then you can't use the macro, my fault, I hadn't looked
at it in a long time.

> Also, for our attribute_groups in visorchipset, we are defining it with two
> different attribute_group variables. Are you allowed to use two different
> attribute_group variables in an attribute_groups, or is this frowned upon and
> we should flatten it out to just one? An example that we used in the kernel 
> was:
> 
>   static const struct attribute_group *l2_cache_pmu_attr_grps[] = {
>   _cache_pmu_format_group,
>   _cache_pmu_cpumask_group,
>   NULL,
>   };

Nah, that's fine, sorry for the noise.  But the changelog text still
should be fixed so I can take this.

thanks,

greg k-h

Re: [PATCH] staging: unisys: visorbus: constify attribute_group structures.

[Greg KH]

On Mon, Jul 17, 2017 at 09:36:58PM +, Kershner, David A wrote:
> > -Original Message-
> > From: Greg KH [mailto:g...@kroah.com]
> > Sent: Monday, July 17, 2017 8:38 AM
> > To: Arvind Yadav 
> > Cc: Kershner, David A ; Sell, Timothy C
> > ; Thompson, Bryan E.
> > ; jon.fri...@unisys.com; Binder, David
> > Anthony ; *S-Par-Maintainer
> > ; de...@driverdev.osuosl.org; linux-
> > ker...@vger.kernel.org
> > Subject: Re: [PATCH] staging: unisys: visorbus: constify attribute_group
> > structures.

Why is this in your email body?

> > 
> > On Mon, Jul 17, 2017 at 05:43:14PM +0530, Arvind Yadav wrote:
> > > Hi Greg,
> > >
> > >
> > > On Monday 17 July 2017 04:15 PM, Greg KH wrote:
> > > > On Mon, Jul 17, 2017 at 02:55:37PM +0530, Arvind Yadav wrote:
> > > > > attribute_groups are not supposed to change at runtime. All functions
> > > > > working with attribute_groups provided by  work
> > > > > with const attribute_group. So mark the non-const structs as const.
> > > > >
> > > > > Signed-off-by: Arvind Yadav 
> > > > > ---
> > > > >   drivers/staging/unisys/visorbus/visorbus_main.c | 4 ++--
> > > > >   drivers/staging/unisys/visorbus/visorchipset.c  | 2 +-
> > > > >   2 files changed, 3 insertions(+), 3 deletions(-)
> > > > Why not just use the ATTRIBUTE_GROUPS() macro for these?  Or is there
> > > > something that is preventing that?
> > > Yes, we can use. if we are only initializing '.attrs'.
> > > ATTRIBUTE_GROUPS() will not work if we will initialize other member of
> > > attribute_group like 'bin_attrs', 'is_visible', and  'name'.
> > 
> > That means you should redo this patch :)
> > 
> > Also, your changelog text had a typo, it is "attribute_group", not
> > "attribute_groups".
> > 
> 
> Greg, are you recommending that we shouldn't be setting the attribute_group
> .name field? What does it pick up if we don't specify it?

Why do you want a name for your group?  Anyway, yes, you are right, if
you set a .name, then you can't use the macro, my fault, I hadn't looked
at it in a long time.

> Also, for our attribute_groups in visorchipset, we are defining it with two
> different attribute_group variables. Are you allowed to use two different
> attribute_group variables in an attribute_groups, or is this frowned upon and
> we should flatten it out to just one? An example that we used in the kernel 
> was:
> 
>   static const struct attribute_group *l2_cache_pmu_attr_grps[] = {
>   _cache_pmu_format_group,
>   _cache_pmu_cpumask_group,
>   NULL,
>   };

Nah, that's fine, sorry for the noise.  But the changelog text still
should be fixed so I can take this.

thanks,

greg k-h

Re: [PATCH v5 4/5] arm64: dts: exynos: Remove the OF graph from DSI node

[Krzysztof Kozlowski]

On Wed, Mar 08, 2017 at 01:54:11PM +0900, Hoegeun Kwon wrote:
> The OF graph is not needed because the panel is a child of dsi. Remove
> the ports node in DSI node.
> 
> Signed-off-by: Hoegeun Kwon 
> Reviewed-by: Andrzej Hajda 
> Reviewed-by: Andi Shyti 
> ---
>  arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 14 --
>  1 file changed, 14 deletions(-)
> 

Thanks, applied this and 5/5.

Best regards,
Krzysztof

Re: [PATCH v5 4/5] arm64: dts: exynos: Remove the OF graph from DSI node

[Krzysztof Kozlowski]

On Wed, Mar 08, 2017 at 01:54:11PM +0900, Hoegeun Kwon wrote:
> The OF graph is not needed because the panel is a child of dsi. Remove
> the ports node in DSI node.
> 
> Signed-off-by: Hoegeun Kwon 
> Reviewed-by: Andrzej Hajda 
> Reviewed-by: Andi Shyti 
> ---
>  arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 14 --
>  1 file changed, 14 deletions(-)
> 

Thanks, applied this and 5/5.

Best regards,
Krzysztof

[PATCH v2 0/5] ARM: defconfig: Cleanup from old entries

[Krzysztof Kozlowski]

Hi,

Changes since v1:
1. Rebase on Simon Horman's repo to avoid duplication.
2. Add Liviu Dudau's ack for vexpress.

Best regards,
Krzysztof


Krzysztof Kozlowski (5):
  ARM: multi_v7_defconfig: Cleanup from non-existing options
  ARM: ixp4xx_defconfig: Cleanup from non-existing options
  ARM: vexpress_defconfig: Cleanup from non-existing options
  ARM: ezx_defconfig: Cleanup from non-existing options
  ARM: qcom_defconfig: Cleanup from non-existing options

 arch/arm/configs/ezx_defconfig  | 1 -
 arch/arm/configs/ixp4xx_defconfig   | 4 
 arch/arm/configs/multi_v7_defconfig | 7 ---
 arch/arm/configs/qcom_defconfig | 1 -
 arch/arm/configs/vexpress_defconfig | 1 -
 5 files changed, 14 deletions(-)

-- 
2.7.4

[PATCH v2 0/5] ARM: defconfig: Cleanup from old entries

[Krzysztof Kozlowski]

Hi,

Changes since v1:
1. Rebase on Simon Horman's repo to avoid duplication.
2. Add Liviu Dudau's ack for vexpress.

Best regards,
Krzysztof


Krzysztof Kozlowski (5):
  ARM: multi_v7_defconfig: Cleanup from non-existing options
  ARM: ixp4xx_defconfig: Cleanup from non-existing options
  ARM: vexpress_defconfig: Cleanup from non-existing options
  ARM: ezx_defconfig: Cleanup from non-existing options
  ARM: qcom_defconfig: Cleanup from non-existing options

 arch/arm/configs/ezx_defconfig  | 1 -
 arch/arm/configs/ixp4xx_defconfig   | 4 
 arch/arm/configs/multi_v7_defconfig | 7 ---
 arch/arm/configs/qcom_defconfig | 1 -
 arch/arm/configs/vexpress_defconfig | 1 -
 5 files changed, 14 deletions(-)

-- 
2.7.4

Re: [PATCH v4 1/2] wire: export w1_touch_bit (RESEND: line breaks fixed, I hope.)

[Greg Kroah-Hartman]

On Tue, Jul 18, 2017 at 12:53:14AM +0200, Jan Kandziora wrote:
> Changes in v4 against v3 in this subpatch:
>   - adapted to linux-4.12.0
> 
> No changes in v3 against v2,v1 in this subpatch.

All of that needs to go below the --- line.

And your subject needs to be fixed.  I should not have to edit anything
in a patch by hand in order to apply it.

> 
> The w1_ds28e17 driver from the next part of this patch needs to emit
> single-bit read timeslots to the DS28E17. The w1 subsystem already
> has this function but it is not exported outside drivers/w1/w1_io.c
> 
> This subpatch exports the w1_touch_bit symbol with EXPORT_SYMBOL_GPL,
> same as the other exported symbols in drivers/w1/w1_io.c
> 
> May be also useful later for writing drivers for other Onewire chips
> which do single-bit communication.
> 
> 
> Signed-off-by: Jan Kandziora 
> ---
> >From 6aedd1b890bd77bfe788f6af7a38724c16934ab0 Mon Sep 17 00:00:00 2001
> From: Jan Kandziora 
> Date: Sat, 8 Jul 2017 21:14:27 +0200
> Subject: [PATCH 1/2] wire: export w1_touch_bit


Why is this all here?

And where is patch 2/2?

Please fix and resend the whole series.

thanks,

greg k-h

Re: [PATCH v4 1/2] wire: export w1_touch_bit (RESEND: line breaks fixed, I hope.)

[Greg Kroah-Hartman]

On Tue, Jul 18, 2017 at 12:53:14AM +0200, Jan Kandziora wrote:
> Changes in v4 against v3 in this subpatch:
>   - adapted to linux-4.12.0
> 
> No changes in v3 against v2,v1 in this subpatch.

All of that needs to go below the --- line.

And your subject needs to be fixed.  I should not have to edit anything
in a patch by hand in order to apply it.

> 
> The w1_ds28e17 driver from the next part of this patch needs to emit
> single-bit read timeslots to the DS28E17. The w1 subsystem already
> has this function but it is not exported outside drivers/w1/w1_io.c
> 
> This subpatch exports the w1_touch_bit symbol with EXPORT_SYMBOL_GPL,
> same as the other exported symbols in drivers/w1/w1_io.c
> 
> May be also useful later for writing drivers for other Onewire chips
> which do single-bit communication.
> 
> 
> Signed-off-by: Jan Kandziora 
> ---
> >From 6aedd1b890bd77bfe788f6af7a38724c16934ab0 Mon Sep 17 00:00:00 2001
> From: Jan Kandziora 
> Date: Sat, 8 Jul 2017 21:14:27 +0200
> Subject: [PATCH 1/2] wire: export w1_touch_bit


Why is this all here?

And where is patch 2/2?

Please fix and resend the whole series.

thanks,

greg k-h

[PATCH v2 4/5] ARM: ezx_defconfig: Cleanup from non-existing options

[Krzysztof Kozlowski]

CPU_FREQ_DEBUG is gone since commit 2d06d8c49afd  ("[CPUFREQ] use
dynamic debug instead of custom infrastructure").

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/configs/ezx_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/configs/ezx_defconfig b/arch/arm/configs/ezx_defconfig
index 23660f3d0f7f..484e51fbd4a6 100644
--- a/arch/arm/configs/ezx_defconfig
+++ b/arch/arm/configs/ezx_defconfig
@@ -27,7 +27,6 @@ CONFIG_ZBOOT_ROM_BSS=0x0
 CONFIG_CMDLINE="console=tty1 root=/dev/mmcblk0p2 rootfstype=ext2 rootdelay=3 
ip=192.168.0.202:192.168.0.200:192.168.0.200:255.255.255.0 debug"
 CONFIG_KEXEC=y
 CONFIG_CPU_FREQ=y
-CONFIG_CPU_FREQ_DEBUG=y
 CONFIG_CPU_FREQ_GOV_POWERSAVE=m
 CONFIG_CPU_FREQ_GOV_USERSPACE=m
 CONFIG_CPU_FREQ_GOV_ONDEMAND=m
-- 
2.7.4

[PATCH v2 2/5] ARM: ixp4xx_defconfig: Cleanup from non-existing options

[Krzysztof Kozlowski]

Remove options which do not exist anymore:
 - ECONET is gone since commit 349f29d841db ("econet: remove ancient bug
   ridden protocol");

 - IPDDP_DECAP is gone since commit 9b5645b51384 ("appletalk: remove
   "config IPDDP_DECAP"");

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/configs/ixp4xx_defconfig | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/configs/ixp4xx_defconfig 
b/arch/arm/configs/ixp4xx_defconfig
index c8378da71913..8c3c99cd6de9 100644
--- a/arch/arm/configs/ixp4xx_defconfig
+++ b/arch/arm/configs/ixp4xx_defconfig
@@ -81,12 +81,8 @@ CONFIG_ATALK=m
 CONFIG_DEV_APPLETALK=m
 CONFIG_IPDDP=m
 CONFIG_IPDDP_ENCAP=y
-CONFIG_IPDDP_DECAP=y
 CONFIG_X25=m
 CONFIG_LAPB=m
-CONFIG_ECONET=m
-CONFIG_ECONET_AUNUDP=y
-CONFIG_ECONET_NATIVE=y
 CONFIG_WAN_ROUTER=m
 CONFIG_NET_SCHED=y
 CONFIG_NET_SCH_CBQ=m
-- 
2.7.4

[PATCH v2 2/5] ARM: ixp4xx_defconfig: Cleanup from non-existing options

[Krzysztof Kozlowski]

Remove options which do not exist anymore:
 - ECONET is gone since commit 349f29d841db ("econet: remove ancient bug
   ridden protocol");

 - IPDDP_DECAP is gone since commit 9b5645b51384 ("appletalk: remove
   "config IPDDP_DECAP"");

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/configs/ixp4xx_defconfig | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/configs/ixp4xx_defconfig 
b/arch/arm/configs/ixp4xx_defconfig
index c8378da71913..8c3c99cd6de9 100644
--- a/arch/arm/configs/ixp4xx_defconfig
+++ b/arch/arm/configs/ixp4xx_defconfig
@@ -81,12 +81,8 @@ CONFIG_ATALK=m
 CONFIG_DEV_APPLETALK=m
 CONFIG_IPDDP=m
 CONFIG_IPDDP_ENCAP=y
-CONFIG_IPDDP_DECAP=y
 CONFIG_X25=m
 CONFIG_LAPB=m
-CONFIG_ECONET=m
-CONFIG_ECONET_AUNUDP=y
-CONFIG_ECONET_NATIVE=y
 CONFIG_WAN_ROUTER=m
 CONFIG_NET_SCHED=y
 CONFIG_NET_SCH_CBQ=m
-- 
2.7.4

[PATCH v2 4/5] ARM: ezx_defconfig: Cleanup from non-existing options

[Krzysztof Kozlowski]

CPU_FREQ_DEBUG is gone since commit 2d06d8c49afd  ("[CPUFREQ] use
dynamic debug instead of custom infrastructure").

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/configs/ezx_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/configs/ezx_defconfig b/arch/arm/configs/ezx_defconfig
index 23660f3d0f7f..484e51fbd4a6 100644
--- a/arch/arm/configs/ezx_defconfig
+++ b/arch/arm/configs/ezx_defconfig
@@ -27,7 +27,6 @@ CONFIG_ZBOOT_ROM_BSS=0x0
 CONFIG_CMDLINE="console=tty1 root=/dev/mmcblk0p2 rootfstype=ext2 rootdelay=3 
ip=192.168.0.202:192.168.0.200:192.168.0.200:255.255.255.0 debug"
 CONFIG_KEXEC=y
 CONFIG_CPU_FREQ=y
-CONFIG_CPU_FREQ_DEBUG=y
 CONFIG_CPU_FREQ_GOV_POWERSAVE=m
 CONFIG_CPU_FREQ_GOV_USERSPACE=m
 CONFIG_CPU_FREQ_GOV_ONDEMAND=m
-- 
2.7.4

[PATCH v2 5/5] ARM: qcom_defconfig: Cleanup from non-existing options

[Krzysztof Kozlowski]

QCOM_SMD is gone since commit 395a48053af6 ("soc: qcom: smd: Remove
standalone driver").

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/configs/qcom_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig
index b02039c712c3..879159e4ab58 100644
--- a/arch/arm/configs/qcom_defconfig
+++ b/arch/arm/configs/qcom_defconfig
@@ -199,7 +199,6 @@ CONFIG_QCOM_WCNSS_PIL=y
 CONFIG_QCOM_GSBI=y
 CONFIG_QCOM_PM=y
 CONFIG_QCOM_SMEM=y
-CONFIG_QCOM_SMD=y
 CONFIG_QCOM_SMD_RPM=y
 CONFIG_QCOM_SMP2P=y
 CONFIG_QCOM_SMSM=y
-- 
2.7.4

Re: [PATCH v4 1/2] wire: export w1_touch_bit

[Greg Kroah-Hartman]

On Tue, Jul 18, 2017 at 12:56:46AM +0200, Jan Kandziora wrote:
> Am 17.07.2017 um 16:47 schrieb Greg Kroah-Hartman:
> > 
> > This is in no format that I can apply, sorry.
> > 
> > Jan, can you resend it in a correct format?
> > 
> I sent part 1/2 again with the line breaks fixed (I hope.)
> 
> Part 2/2 was okay?

I have no idea, always resend the whole series.

thanks,

greg k-h

Re: [PATCH v4 1/2] wire: export w1_touch_bit

[Greg Kroah-Hartman]

On Tue, Jul 18, 2017 at 12:56:46AM +0200, Jan Kandziora wrote:
> Am 17.07.2017 um 16:47 schrieb Greg Kroah-Hartman:
> > 
> > This is in no format that I can apply, sorry.
> > 
> > Jan, can you resend it in a correct format?
> > 
> I sent part 1/2 again with the line breaks fixed (I hope.)
> 
> Part 2/2 was okay?

I have no idea, always resend the whole series.

thanks,

greg k-h

[PATCH v2 5/5] ARM: qcom_defconfig: Cleanup from non-existing options

[Krzysztof Kozlowski]

QCOM_SMD is gone since commit 395a48053af6 ("soc: qcom: smd: Remove
standalone driver").

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/configs/qcom_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig
index b02039c712c3..879159e4ab58 100644
--- a/arch/arm/configs/qcom_defconfig
+++ b/arch/arm/configs/qcom_defconfig
@@ -199,7 +199,6 @@ CONFIG_QCOM_WCNSS_PIL=y
 CONFIG_QCOM_GSBI=y
 CONFIG_QCOM_PM=y
 CONFIG_QCOM_SMEM=y
-CONFIG_QCOM_SMD=y
 CONFIG_QCOM_SMD_RPM=y
 CONFIG_QCOM_SMP2P=y
 CONFIG_QCOM_SMSM=y
-- 
2.7.4

[PATCH v2 3/5] ARM: vexpress_defconfig: Cleanup from non-existing options

[Krzysztof Kozlowski]

ARCH_VEXPRESS_CA9X4 is gone since commit 81cc3f868d30 ("ARM: vexpress:
Remove non-DT code").

Signed-off-by: Krzysztof Kozlowski 
Acked-by: Liviu Dudau 
---
 arch/arm/configs/vexpress_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/configs/vexpress_defconfig 
b/arch/arm/configs/vexpress_defconfig
index 0fa0ed577b15..edae1c58fe80 100644
--- a/arch/arm/configs/vexpress_defconfig
+++ b/arch/arm/configs/vexpress_defconfig
@@ -19,7 +19,6 @@ CONFIG_MODULE_UNLOAD=y
 # CONFIG_IOSCHED_DEADLINE is not set
 # CONFIG_IOSCHED_CFQ is not set
 CONFIG_ARCH_VEXPRESS=y
-CONFIG_ARCH_VEXPRESS_CA9X4=y
 CONFIG_ARCH_VEXPRESS_DCSCB=y
 CONFIG_ARCH_VEXPRESS_TC2_PM=y
 # CONFIG_SWP_EMULATE is not set
-- 
2.7.4

[PATCH v2 3/5] ARM: vexpress_defconfig: Cleanup from non-existing options

[Krzysztof Kozlowski]

ARCH_VEXPRESS_CA9X4 is gone since commit 81cc3f868d30 ("ARM: vexpress:
Remove non-DT code").

Signed-off-by: Krzysztof Kozlowski 
Acked-by: Liviu Dudau 
---
 arch/arm/configs/vexpress_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/configs/vexpress_defconfig 
b/arch/arm/configs/vexpress_defconfig
index 0fa0ed577b15..edae1c58fe80 100644
--- a/arch/arm/configs/vexpress_defconfig
+++ b/arch/arm/configs/vexpress_defconfig
@@ -19,7 +19,6 @@ CONFIG_MODULE_UNLOAD=y
 # CONFIG_IOSCHED_DEADLINE is not set
 # CONFIG_IOSCHED_CFQ is not set
 CONFIG_ARCH_VEXPRESS=y
-CONFIG_ARCH_VEXPRESS_CA9X4=y
 CONFIG_ARCH_VEXPRESS_DCSCB=y
 CONFIG_ARCH_VEXPRESS_TC2_PM=y
 # CONFIG_SWP_EMULATE is not set
-- 
2.7.4

[PATCH v2 1/5] ARM: multi_v7_defconfig: Cleanup from non-existing options

[Krzysztof Kozlowski]

Remove options which do not exist anymore:
 - TEGRA_EMC_SCALING_ENABLE is gone since commit cab4d50389c6 ("ARM:
   tegra: remove TEGRA_EMC_SCALING_ENABLE");

 - ARCH_VEXPRESS_CA9X4 is gone since commit 81cc3f868d30
   ("ARM: vexpress: Remove non-DT code");

 - OMAP_USB3 was replaced by TI_PIPE3 in commit a70143bbef6b ("drivers:
   phy: usb3/pipe3: Adapt pipe3 driver to Generic PHY Framework");

 - MMC_DW_IDMAC is gone since commit 3fc7eaef44db ("mmc: dw_mmc: Add
   external dma interface support");

 - QCOM_SMD since commit 395a48053af6 ("soc: qcom: smd: Remove
   standalone driver");

 - COMMON_CLK_MAX77802 was merged into COMMON_CLK_MAX77686 in commit
   8ad313fe4e00 ("clk: max77686: Combine Maxim max77686 and max77802
   driver");

 - CRYPTO_DEV_TEGRA_AES is gone since commit 645af2e43705 ("crypto:
   tegra - remove driver");

Signed-off-by: Krzysztof Kozlowski 

---

Changes since v1:
1. Rebased on top of latest Simon Horman's work (drops RCAR changes).
---
 arch/arm/configs/multi_v7_defconfig | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 072a455008df..6cfd6137db88 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -104,13 +104,11 @@ CONFIG_ARCH_TEGRA_2x_SOC=y
 CONFIG_ARCH_TEGRA_3x_SOC=y
 CONFIG_ARCH_TEGRA_114_SOC=y
 CONFIG_ARCH_TEGRA_124_SOC=y
-CONFIG_TEGRA_EMC_SCALING_ENABLE=y
 CONFIG_ARCH_UNIPHIER=y
 CONFIG_ARCH_U8500=y
 CONFIG_MACH_HREFV60=y
 CONFIG_MACH_SNOWBALL=y
 CONFIG_ARCH_VEXPRESS=y
-CONFIG_ARCH_VEXPRESS_CA9X4=y
 CONFIG_ARCH_VEXPRESS_TC2_PM=y
 CONFIG_ARCH_WM8850=y
 CONFIG_ARCH_ZYNQ=y
@@ -696,7 +694,6 @@ CONFIG_USB_CHIPIDEA_UDC=y
 CONFIG_USB_CHIPIDEA_HOST=y
 CONFIG_AB8500_USB=y
 CONFIG_KEYSTONE_USB_PHY=y
-CONFIG_OMAP_USB3=y
 CONFIG_USB_GPIO_VBUS=y
 CONFIG_USB_ISP1301=y
 CONFIG_USB_MSM_OTG=m
@@ -729,7 +726,6 @@ CONFIG_MMC_SDHCI_MSM=y
 CONFIG_MMC_MVSDIO=y
 CONFIG_MMC_SDHI=y
 CONFIG_MMC_DW=y
-CONFIG_MMC_DW_IDMAC=y
 CONFIG_MMC_DW_PLTFM=y
 CONFIG_MMC_DW_EXYNOS=y
 CONFIG_MMC_DW_ROCKCHIP=y
@@ -826,7 +822,6 @@ CONFIG_BCMA_DRIVER_GPIO=y
 CONFIG_QCOM_GSBI=y
 CONFIG_QCOM_PM=y
 CONFIG_QCOM_SMEM=y
-CONFIG_QCOM_SMD=y
 CONFIG_QCOM_SMD_RPM=y
 CONFIG_QCOM_SMP2P=y
 CONFIG_QCOM_SMSM=y
@@ -838,7 +833,6 @@ CONFIG_CHROME_PLATFORMS=y
 CONFIG_STAGING_BOARD=y
 CONFIG_CROS_EC_CHARDEV=m
 CONFIG_COMMON_CLK_MAX77686=y
-CONFIG_COMMON_CLK_MAX77802=m
 CONFIG_COMMON_CLK_RK808=m
 CONFIG_COMMON_CLK_S2MPS11=m
 CONFIG_APQ_MMCC_8084=y
@@ -934,7 +928,6 @@ CONFIG_PRINTK_TIME=y
 CONFIG_DEBUG_FS=y
 CONFIG_MAGIC_SYSRQ=y
 CONFIG_LOCKUP_DETECTOR=y
-CONFIG_CRYPTO_DEV_TEGRA_AES=y
 CONFIG_CPUFREQ_DT=y
 CONFIG_KEYSTONE_IRQ=y
 CONFIG_HW_RANDOM=y
-- 
2.7.4

[PATCH v2 1/5] ARM: multi_v7_defconfig: Cleanup from non-existing options

[Krzysztof Kozlowski]

Remove options which do not exist anymore:
 - TEGRA_EMC_SCALING_ENABLE is gone since commit cab4d50389c6 ("ARM:
   tegra: remove TEGRA_EMC_SCALING_ENABLE");

 - ARCH_VEXPRESS_CA9X4 is gone since commit 81cc3f868d30
   ("ARM: vexpress: Remove non-DT code");

 - OMAP_USB3 was replaced by TI_PIPE3 in commit a70143bbef6b ("drivers:
   phy: usb3/pipe3: Adapt pipe3 driver to Generic PHY Framework");

 - MMC_DW_IDMAC is gone since commit 3fc7eaef44db ("mmc: dw_mmc: Add
   external dma interface support");

 - QCOM_SMD since commit 395a48053af6 ("soc: qcom: smd: Remove
   standalone driver");

 - COMMON_CLK_MAX77802 was merged into COMMON_CLK_MAX77686 in commit
   8ad313fe4e00 ("clk: max77686: Combine Maxim max77686 and max77802
   driver");

 - CRYPTO_DEV_TEGRA_AES is gone since commit 645af2e43705 ("crypto:
   tegra - remove driver");

Signed-off-by: Krzysztof Kozlowski 

---

Changes since v1:
1. Rebased on top of latest Simon Horman's work (drops RCAR changes).
---
 arch/arm/configs/multi_v7_defconfig | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 072a455008df..6cfd6137db88 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -104,13 +104,11 @@ CONFIG_ARCH_TEGRA_2x_SOC=y
 CONFIG_ARCH_TEGRA_3x_SOC=y
 CONFIG_ARCH_TEGRA_114_SOC=y
 CONFIG_ARCH_TEGRA_124_SOC=y
-CONFIG_TEGRA_EMC_SCALING_ENABLE=y
 CONFIG_ARCH_UNIPHIER=y
 CONFIG_ARCH_U8500=y
 CONFIG_MACH_HREFV60=y
 CONFIG_MACH_SNOWBALL=y
 CONFIG_ARCH_VEXPRESS=y
-CONFIG_ARCH_VEXPRESS_CA9X4=y
 CONFIG_ARCH_VEXPRESS_TC2_PM=y
 CONFIG_ARCH_WM8850=y
 CONFIG_ARCH_ZYNQ=y
@@ -696,7 +694,6 @@ CONFIG_USB_CHIPIDEA_UDC=y
 CONFIG_USB_CHIPIDEA_HOST=y
 CONFIG_AB8500_USB=y
 CONFIG_KEYSTONE_USB_PHY=y
-CONFIG_OMAP_USB3=y
 CONFIG_USB_GPIO_VBUS=y
 CONFIG_USB_ISP1301=y
 CONFIG_USB_MSM_OTG=m
@@ -729,7 +726,6 @@ CONFIG_MMC_SDHCI_MSM=y
 CONFIG_MMC_MVSDIO=y
 CONFIG_MMC_SDHI=y
 CONFIG_MMC_DW=y
-CONFIG_MMC_DW_IDMAC=y
 CONFIG_MMC_DW_PLTFM=y
 CONFIG_MMC_DW_EXYNOS=y
 CONFIG_MMC_DW_ROCKCHIP=y
@@ -826,7 +822,6 @@ CONFIG_BCMA_DRIVER_GPIO=y
 CONFIG_QCOM_GSBI=y
 CONFIG_QCOM_PM=y
 CONFIG_QCOM_SMEM=y
-CONFIG_QCOM_SMD=y
 CONFIG_QCOM_SMD_RPM=y
 CONFIG_QCOM_SMP2P=y
 CONFIG_QCOM_SMSM=y
@@ -838,7 +833,6 @@ CONFIG_CHROME_PLATFORMS=y
 CONFIG_STAGING_BOARD=y
 CONFIG_CROS_EC_CHARDEV=m
 CONFIG_COMMON_CLK_MAX77686=y
-CONFIG_COMMON_CLK_MAX77802=m
 CONFIG_COMMON_CLK_RK808=m
 CONFIG_COMMON_CLK_S2MPS11=m
 CONFIG_APQ_MMCC_8084=y
@@ -934,7 +928,6 @@ CONFIG_PRINTK_TIME=y
 CONFIG_DEBUG_FS=y
 CONFIG_MAGIC_SYSRQ=y
 CONFIG_LOCKUP_DETECTOR=y
-CONFIG_CRYPTO_DEV_TEGRA_AES=y
 CONFIG_CPUFREQ_DT=y
 CONFIG_KEYSTONE_IRQ=y
 CONFIG_HW_RANDOM=y
-- 
2.7.4

Re: linux-next: build failure after merge of the net-next tree

[John Fastabend]

On 07/17/2017 06:09 PM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the net-next tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> net/core/filter.o: In function `xdp_do_flush_map':
> filter.c:(.text+0x3770): undefined reference to `__dev_map_flush'
> net/core/filter.o: In function `__bpf_tx_xdp':
> filter.c:(.text+0x56dc): undefined reference to `__dev_map_insert_ctx'
> net/core/filter.o: In function `xdp_do_redirect_map':
> filter.c:(.text+0x5e24): undefined reference to `__dev_map_lookup_elem'
> 
> Caused by commit
> 
>   11393cc9b9be ("xdp: Add batching support to redirect map")
> 
> This build has
> 
> CONFIG_BPF=y
> # CONFIG_BPF_SYSCALL is not set
> 
> I have used the net-next tree from next-20170717 for today.
> 

I missed testing without CONFIG_BPF_SYSCALL. Patch is posted to netdev
and on patchworks at,

https://patchwork.ozlabs.org/patch/789862/

Thanks,
John

Re: linux-next: build failure after merge of the net-next tree

[John Fastabend]

On 07/17/2017 06:09 PM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the net-next tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> net/core/filter.o: In function `xdp_do_flush_map':
> filter.c:(.text+0x3770): undefined reference to `__dev_map_flush'
> net/core/filter.o: In function `__bpf_tx_xdp':
> filter.c:(.text+0x56dc): undefined reference to `__dev_map_insert_ctx'
> net/core/filter.o: In function `xdp_do_redirect_map':
> filter.c:(.text+0x5e24): undefined reference to `__dev_map_lookup_elem'
> 
> Caused by commit
> 
>   11393cc9b9be ("xdp: Add batching support to redirect map")
> 
> This build has
> 
> CONFIG_BPF=y
> # CONFIG_BPF_SYSCALL is not set
> 
> I have used the net-next tree from next-20170717 for today.
> 

I missed testing without CONFIG_BPF_SYSCALL. Patch is posted to netdev
and on patchworks at,

https://patchwork.ozlabs.org/patch/789862/

Thanks,
John

[PATCH] cpufreq: schedutil: Update last_update from sugov_set_iowait_boost()

[Viresh Kumar]

sg_cpu->last_update is always updated right after we call
sugov_set_iowait_boost() and its better to update it from that routine
itself. This makes it more readable.

Signed-off-by: Viresh Kumar 
---
 kernel/sched/cpufreq_schedutil.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 29a397067ffa..63557b9f36b6 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -177,6 +177,8 @@ static void sugov_set_iowait_boost(struct sugov_cpu 
*sg_cpu, u64 time,
if (delta_ns > TICK_NSEC)
sg_cpu->iowait_boost = 0;
}
+
+   sg_cpu->last_update = time;
 }
 
 static void sugov_iowait_boost(struct sugov_cpu *sg_cpu, unsigned long *util,
@@ -219,7 +221,6 @@ static void sugov_update_single(struct update_util_data 
*hook, u64 time,
bool busy;
 
sugov_set_iowait_boost(sg_cpu, time, flags);
-   sg_cpu->last_update = time;
 
if (!sugov_should_update_freq(sg_policy, time))
return;
@@ -299,7 +300,6 @@ static void sugov_update_shared(struct update_util_data 
*hook, u64 time,
sg_cpu->flags = flags;
 
sugov_set_iowait_boost(sg_cpu, time, flags);
-   sg_cpu->last_update = time;
 
if (sugov_should_update_freq(sg_policy, time)) {
if (flags & SCHED_CPUFREQ_RT_DL)
-- 
2.13.0.71.gd7076ec9c9cb

[PATCH] cpufreq: schedutil: Update last_update from sugov_set_iowait_boost()

[Viresh Kumar]

sg_cpu->last_update is always updated right after we call
sugov_set_iowait_boost() and its better to update it from that routine
itself. This makes it more readable.

Signed-off-by: Viresh Kumar 
---
 kernel/sched/cpufreq_schedutil.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 29a397067ffa..63557b9f36b6 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -177,6 +177,8 @@ static void sugov_set_iowait_boost(struct sugov_cpu 
*sg_cpu, u64 time,
if (delta_ns > TICK_NSEC)
sg_cpu->iowait_boost = 0;
}
+
+   sg_cpu->last_update = time;
 }
 
 static void sugov_iowait_boost(struct sugov_cpu *sg_cpu, unsigned long *util,
@@ -219,7 +221,6 @@ static void sugov_update_single(struct update_util_data 
*hook, u64 time,
bool busy;
 
sugov_set_iowait_boost(sg_cpu, time, flags);
-   sg_cpu->last_update = time;
 
if (!sugov_should_update_freq(sg_policy, time))
return;
@@ -299,7 +300,6 @@ static void sugov_update_shared(struct update_util_data 
*hook, u64 time,
sg_cpu->flags = flags;
 
sugov_set_iowait_boost(sg_cpu, time, flags);
-   sg_cpu->last_update = time;
 
if (sugov_should_update_freq(sg_policy, time)) {
if (flags & SCHED_CPUFREQ_RT_DL)
-- 
2.13.0.71.gd7076ec9c9cb

Re: [PATCH v6 0/6] provide power off support for iMX6 with external PMIC

[Oleksij Rempel]

Hallo all,

Here Gentle Ping to the Old King

DT is already ACKed.

On 20.06.2017 16:09, Oleksij Rempel wrote:

This patch series is providing power off support for Freescale/NXP iMX6 based
boards with external power management integrated circuit (PMIC).

changes:
v6:
 - rename imx6_pm_poweroff to imx6_pm_stby_poweroff
 - fix "MPIC_STBY_REQ" typo in the comment.

v5:
 - remove useless includes from pm-imx6.c patch
 - add Acked-by to "regulator: pfuze100: add fsl,pmic-stby-poweroff property"
   patch

v4:
 - update comment in "regulator: pfuze100: add fsl,pmic-stby-poweroff ..."
   patch
 - add Acked-by to "ARM: imx6q: provide documentation for new ..."
   patch

v3:
 - set pm_power_off_prepare = NULL on .remove.
 - documentation and spelling fixes.
 - use %pf instead of lookup_symbol_name.

Oleksij Rempel (6):
  ARM: imx6q: provide documentation for new fsl,pmic-stby-poweroff
property
  ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff"
is set
  kernel/reboot.c: export pm_power_off_prepare
  regulator: pfuze100: add fsl,pmic-stby-poweroff property
  regulator: pfuze100-regulator: provide pm_power_off_prepare handler
  ARM: dts: imx6: RIoTboard provide standby on power off option

 .../devicetree/bindings/clock/imx6q-clock.txt  |  8 ++
 .../devicetree/bindings/regulator/pfuze100.txt |  7 ++
 arch/arm/boot/dts/imx6dl-riotboard.dts |  5 ++
 arch/arm/mach-imx/pm-imx6.c| 25 ++
 drivers/regulator/pfuze100-regulator.c | 92 ++
 kernel/reboot.c|  1 +
 6 files changed, 138 insertions(+)

Re: [PATCH v6 0/6] provide power off support for iMX6 with external PMIC

[Oleksij Rempel]

Hallo all,

Here Gentle Ping to the Old King

DT is already ACKed.

On 20.06.2017 16:09, Oleksij Rempel wrote:

This patch series is providing power off support for Freescale/NXP iMX6 based
boards with external power management integrated circuit (PMIC).

changes:
v6:
 - rename imx6_pm_poweroff to imx6_pm_stby_poweroff
 - fix "MPIC_STBY_REQ" typo in the comment.

v5:
 - remove useless includes from pm-imx6.c patch
 - add Acked-by to "regulator: pfuze100: add fsl,pmic-stby-poweroff property"
   patch

v4:
 - update comment in "regulator: pfuze100: add fsl,pmic-stby-poweroff ..."
   patch
 - add Acked-by to "ARM: imx6q: provide documentation for new ..."
   patch

v3:
 - set pm_power_off_prepare = NULL on .remove.
 - documentation and spelling fixes.
 - use %pf instead of lookup_symbol_name.

Oleksij Rempel (6):
  ARM: imx6q: provide documentation for new fsl,pmic-stby-poweroff
property
  ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff"
is set
  kernel/reboot.c: export pm_power_off_prepare
  regulator: pfuze100: add fsl,pmic-stby-poweroff property
  regulator: pfuze100-regulator: provide pm_power_off_prepare handler
  ARM: dts: imx6: RIoTboard provide standby on power off option

 .../devicetree/bindings/clock/imx6q-clock.txt  |  8 ++
 .../devicetree/bindings/regulator/pfuze100.txt |  7 ++
 arch/arm/boot/dts/imx6dl-riotboard.dts |  5 ++
 arch/arm/mach-imx/pm-imx6.c| 25 ++
 drivers/regulator/pfuze100-regulator.c | 92 ++
 kernel/reboot.c|  1 +
 6 files changed, 138 insertions(+)

Re: [PATCH] hwmon: (lm75) Add a basic interrupt handler

[Guenter Roeck]

On Sun, Jul 16, 2017 at 09:51:24PM +, Tony O'Brien wrote:
> Hi Guenter -
> 
> The interrupt line the LM75 sits on is shared by other devices and therefore 
> cannot be disabled.  It was added in hardware as a possible feature can 
> cannot be disconnected.
> 

Ah yes, it is declared as shared, which makes me slightly uncomfortable.
Any chance that this (and TRIGGER_LOW) can be specified in devicetree ?

Sorry if I am annoying, but this is a generic driver, and I would like
to prevent bad surprises if possible.

Thanks,
Guenter

> Cheers,
> 
> Tony O'Brien
> Senior Software/Hardware Engineer
> Allied Telesis Labs
> 27 Nazareth Avenue
> Christchurch 8024
> New Zealand
> Ph: +64-3-339 3000
> DDI: +64-3-339 9210
> Web: http://AlliedTelesis.com
> 
> 
> 
> 
> From: Guenter Roeck 
> Sent: Sunday, 16 July 2017 12:42 p.m.
> To: Tony O'Brien; jdelv...@suse.com; linux-hw...@vger.kernel.org; 
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] hwmon: (lm75) Add a basic interrupt handler
> 
> On 07/11/2017 07:52 PM, Tony O'Brien wrote:
> > The LM75 interrupt cannot be masked in the device so an over-temperature
> > event can cause an interrupt that cannot be cleared.
> > Add an interrupt handler if an interrupt node exists in the DTS for an
> > LM75.  The handler simply reads a device register to clear the interrupt
> > and returns.
> >
> 
> Is this an actual problem ? If no interrupt handler is registered, the 
> interrupt
> should be disabled by the interrupt controller, and it should not matter if
> the interrupt line from the chip is active or not.
> 
> Thanks,
> Guenter
> 
> > Signed-off-by: Tony O'Brien 
> > Reviewed-by: Chris Packham 
> > ---
> >   drivers/hwmon/lm75.c | 28 
> >   drivers/hwmon/lm75.h |  1 +
> >   2 files changed, 29 insertions(+)
> >
> > diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
> > index 005ffb5ffa92..08a833e960aa 100644
> > --- a/drivers/hwmon/lm75.c
> > +++ b/drivers/hwmon/lm75.c
> > @@ -22,6 +22,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >   #include 
> >   #include 
> >   #include 
> > @@ -265,6 +266,17 @@ static void lm75_remove(void *data)
> >   i2c_smbus_write_byte_data(client, LM75_REG_CONF, lm75->orig_conf);
> >   }
> >
> > +static irqreturn_t lm75_process_interrupt(int irq, void *data)
> > +{
> > + struct i2c_client *client = (struct i2c_client *)data;
> > + int val;
> > +
> > + /* Do a read to clear the interrupt */
> > + val = i2c_smbus_read_byte_data(client, LM75_REG_CONF);
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> >   static int
> >   lm75_probe(struct i2c_client *client, const struct i2c_device_id *id)
> >   {
> > @@ -275,6 +287,7 @@ lm75_probe(struct i2c_client *client, const struct 
> > i2c_device_id *id)
> >   u8 set_mask, clr_mask;
> >   int new;
> >   enum lm75_type kind;
> > + int ret;
> >
> >   if (client->dev.of_node)
> >   kind = (enum lm75_type)of_device_get_match_data(>dev);
> > @@ -375,6 +388,21 @@ lm75_probe(struct i2c_client *client, const struct 
> > i2c_device_id *id)
> >   break;
> >   }
> >
> > + if (client->irq) {
> > + /* If requesting an interrupt then set to interrupt mode */
> > + set_mask |= LM75_MODE_INTERRUPT;
> > + ret = devm_request_threaded_irq(dev, client->irq, NULL,
> > + lm75_process_interrupt,
> > + IRQF_TRIGGER_LOW | 
> > IRQF_ONESHOT |
> > + IRQF_SHARED,
> > + dev_name(dev),
> > + client);
> > + if (ret) {
> > + dev_err(dev, "Error requesting irq\n");
> > + return ret;
> > + }
> > + }
> > +
> >   /* configure as specified */
> >   status = i2c_smbus_read_byte_data(client, LM75_REG_CONF);
> >   if (status < 0) {
> > diff --git a/drivers/hwmon/lm75.h b/drivers/hwmon/lm75.h
> > index 5cde94e56f17..82a71d870331 100644
> > --- a/drivers/hwmon/lm75.h
> > +++ b/drivers/hwmon/lm75.h
> > @@ -31,6 +31,7 @@
> >   #define LM75_TEMP_MIN (-55000)
> >   #define LM75_TEMP_MAX 125000
> >   #define LM75_SHUTDOWN 0x01
> > +#define LM75_MODE_INTERRUPT 0x02
> >
> >   /* TEMP: 0.001C/bit (-55C to +125C)
> >  REG: (0.5C/bit, two's complement) << 7 */
> >
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] hwmon: (lm75) Add a basic interrupt handler

[Guenter Roeck]

On Sun, Jul 16, 2017 at 09:51:24PM +, Tony O'Brien wrote:
> Hi Guenter -
> 
> The interrupt line the LM75 sits on is shared by other devices and therefore 
> cannot be disabled.  It was added in hardware as a possible feature can 
> cannot be disconnected.
> 

Ah yes, it is declared as shared, which makes me slightly uncomfortable.
Any chance that this (and TRIGGER_LOW) can be specified in devicetree ?

Sorry if I am annoying, but this is a generic driver, and I would like
to prevent bad surprises if possible.

Thanks,
Guenter

> Cheers,
> 
> Tony O'Brien
> Senior Software/Hardware Engineer
> Allied Telesis Labs
> 27 Nazareth Avenue
> Christchurch 8024
> New Zealand
> Ph: +64-3-339 3000
> DDI: +64-3-339 9210
> Web: http://AlliedTelesis.com
> 
> 
> 
> 
> From: Guenter Roeck 
> Sent: Sunday, 16 July 2017 12:42 p.m.
> To: Tony O'Brien; jdelv...@suse.com; linux-hw...@vger.kernel.org; 
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] hwmon: (lm75) Add a basic interrupt handler
> 
> On 07/11/2017 07:52 PM, Tony O'Brien wrote:
> > The LM75 interrupt cannot be masked in the device so an over-temperature
> > event can cause an interrupt that cannot be cleared.
> > Add an interrupt handler if an interrupt node exists in the DTS for an
> > LM75.  The handler simply reads a device register to clear the interrupt
> > and returns.
> >
> 
> Is this an actual problem ? If no interrupt handler is registered, the 
> interrupt
> should be disabled by the interrupt controller, and it should not matter if
> the interrupt line from the chip is active or not.
> 
> Thanks,
> Guenter
> 
> > Signed-off-by: Tony O'Brien 
> > Reviewed-by: Chris Packham 
> > ---
> >   drivers/hwmon/lm75.c | 28 
> >   drivers/hwmon/lm75.h |  1 +
> >   2 files changed, 29 insertions(+)
> >
> > diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
> > index 005ffb5ffa92..08a833e960aa 100644
> > --- a/drivers/hwmon/lm75.c
> > +++ b/drivers/hwmon/lm75.c
> > @@ -22,6 +22,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >   #include 
> >   #include 
> >   #include 
> > @@ -265,6 +266,17 @@ static void lm75_remove(void *data)
> >   i2c_smbus_write_byte_data(client, LM75_REG_CONF, lm75->orig_conf);
> >   }
> >
> > +static irqreturn_t lm75_process_interrupt(int irq, void *data)
> > +{
> > + struct i2c_client *client = (struct i2c_client *)data;
> > + int val;
> > +
> > + /* Do a read to clear the interrupt */
> > + val = i2c_smbus_read_byte_data(client, LM75_REG_CONF);
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> >   static int
> >   lm75_probe(struct i2c_client *client, const struct i2c_device_id *id)
> >   {
> > @@ -275,6 +287,7 @@ lm75_probe(struct i2c_client *client, const struct 
> > i2c_device_id *id)
> >   u8 set_mask, clr_mask;
> >   int new;
> >   enum lm75_type kind;
> > + int ret;
> >
> >   if (client->dev.of_node)
> >   kind = (enum lm75_type)of_device_get_match_data(>dev);
> > @@ -375,6 +388,21 @@ lm75_probe(struct i2c_client *client, const struct 
> > i2c_device_id *id)
> >   break;
> >   }
> >
> > + if (client->irq) {
> > + /* If requesting an interrupt then set to interrupt mode */
> > + set_mask |= LM75_MODE_INTERRUPT;
> > + ret = devm_request_threaded_irq(dev, client->irq, NULL,
> > + lm75_process_interrupt,
> > + IRQF_TRIGGER_LOW | 
> > IRQF_ONESHOT |
> > + IRQF_SHARED,
> > + dev_name(dev),
> > + client);
> > + if (ret) {
> > + dev_err(dev, "Error requesting irq\n");
> > + return ret;
> > + }
> > + }
> > +
> >   /* configure as specified */
> >   status = i2c_smbus_read_byte_data(client, LM75_REG_CONF);
> >   if (status < 0) {
> > diff --git a/drivers/hwmon/lm75.h b/drivers/hwmon/lm75.h
> > index 5cde94e56f17..82a71d870331 100644
> > --- a/drivers/hwmon/lm75.h
> > +++ b/drivers/hwmon/lm75.h
> > @@ -31,6 +31,7 @@
> >   #define LM75_TEMP_MIN (-55000)
> >   #define LM75_TEMP_MAX 125000
> >   #define LM75_SHUTDOWN 0x01
> > +#define LM75_MODE_INTERRUPT 0x02
> >
> >   /* TEMP: 0.001C/bit (-55C to +125C)
> >  REG: (0.5C/bit, two's complement) << 7 */
> >
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 2/5] spmi: pmic-arb: rename pa_xx to pmic_arb_xx and other code cleanup

[kgunda]

On 2017-07-14 23:50, Stephen Boyd wrote:

On 07/10, Kiran Gunda wrote:


-static u16 pmic_arb_find_apid(struct spmi_pmic_arb *pa, u16 ppid)
+static u16 pmic_arb_find_apid(struct spmi_pmic_arb *pmic_arb, u16 
ppid)

 {
+	struct apid_data *apid_info = 
_arb->apid_data[pmic_arb->last_apid];

u32 regval, offset;
-   u16 apid;
-   u16 id;
+   u16 id, i;

/*
-* PMIC_ARB_REG_CHNL is a table in HW mapping channel to ppid.
+* PMIC_ARB_REG_APID is a table in HW mapping apid to ppid.
 * ppid_to_apid is an in-memory invert of that table.
 */
-   for (apid = pa->last_apid; ; apid++) {
-   offset = PMIC_ARB_REG_CHNL(apid);
-   if (offset >= pa->core_size)
+   for (i = pmic_arb->last_apid; ; i++, apid_info++) {


Can we keep apid instead of replacing it with i please? That will
reduce the noise in this function.


Sure. Will do that in the next patch.

+   offset = PMIC_ARB_REG_CHNL(i);
+   if (offset >= pmic_arb->core_size)
break;

-   regval = readl_relaxed(pa->cnfg +
- SPMI_OWNERSHIP_TABLE_REG(apid));
-   pa->apid_data[apid].owner = SPMI_OWNERSHIP_PERIPH2OWNER(regval);
+   regval = readl_relaxed(pmic_arb->cnfg +
+   SPMI_OWNERSHIP_TABLE_REG(i));
+   apid_info->owner = SPMI_OWNERSHIP_PERIPH2OWNER(regval);

-   regval = readl_relaxed(pa->core + offset);
+   regval = readl_relaxed(pmic_arb->core + offset);
if (!regval)
continue;

id = (regval >> 8) & PMIC_ARB_PPID_MASK;
-   pa->ppid_to_apid[id] = apid | PMIC_ARB_CHAN_VALID;
-   pa->apid_data[apid].ppid = id;
+   pmic_arb->ppid_to_apid[id] = i | PMIC_ARB_APID_VALID;
+   apid_info->ppid = id;
if (id == ppid) {
-   apid |= PMIC_ARB_CHAN_VALID;
+   i |= PMIC_ARB_APID_VALID;
break;
}
}
-   pa->last_apid = apid & ~PMIC_ARB_CHAN_VALID;
+   pmic_arb->last_apid = i & ~PMIC_ARB_APID_VALID;

-   return apid;
+   return i;
 }


Otherwise patch looks ok.

Re: [PATCH v7 0/3] nvmem: upstream snvs_lpgpr driver

[Oleksij Rempel]

Hallo all,

Here Gentle Ping to the Old King ;)

DT is already ACKed.

On 20.06.2017 09:09, Oleksij Rempel wrote:

changes v7:
 - split imx6ul patch and squash it with with main patches.
 - spell fixes in the binding documentation
 - return regmap_bulk_read directly.

changes v6:
 - check if device is writable by reading GPR_SL and GPR_HL bits
 - use regmap_bulk_* functions instead of while() { regmap_read/write }
 - add patch for imx6ul

changes v5:
 - use dcfg->offset instead of priv->offset.

changes v4:
 - change dependencies in Kconfig
 - remove unused includes and order them alphabetically
 - set MODULE_LICENSE = GPL v2
 - remove unused int err variable

changes v3:
 - remove regmap and offset properties.

changes v2:
 - correct typos: Registe, parrent...

Oleksij Rempel (3):
  nvmem: dt: document SNVS LPGPR binding
  nvmem: add snvs_lpgpr driver
  ARM: dts: imx6qdl.dtsi/imx6ul.dtsi: add "fsl,imx6q-snvs-lpgpr" node

 .../devicetree/bindings/nvmem/snvs-lpgpr.txt   |  20 +++
 arch/arm/boot/dts/imx6qdl.dtsi |   4 +
 arch/arm/boot/dts/imx6ul.dtsi  |   4 +
 drivers/nvmem/Kconfig  |  10 ++
 drivers/nvmem/Makefile |   2 +
 drivers/nvmem/snvs_lpgpr.c | 155 +
 6 files changed, 195 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt
 create mode 100644 drivers/nvmem/snvs_lpgpr.c

Re: [PATCH V2 2/5] spmi: pmic-arb: rename pa_xx to pmic_arb_xx and other code cleanup

[kgunda]

On 2017-07-14 23:50, Stephen Boyd wrote:

On 07/10, Kiran Gunda wrote:


-static u16 pmic_arb_find_apid(struct spmi_pmic_arb *pa, u16 ppid)
+static u16 pmic_arb_find_apid(struct spmi_pmic_arb *pmic_arb, u16 
ppid)

 {
+	struct apid_data *apid_info = 
_arb->apid_data[pmic_arb->last_apid];

u32 regval, offset;
-   u16 apid;
-   u16 id;
+   u16 id, i;

/*
-* PMIC_ARB_REG_CHNL is a table in HW mapping channel to ppid.
+* PMIC_ARB_REG_APID is a table in HW mapping apid to ppid.
 * ppid_to_apid is an in-memory invert of that table.
 */
-   for (apid = pa->last_apid; ; apid++) {
-   offset = PMIC_ARB_REG_CHNL(apid);
-   if (offset >= pa->core_size)
+   for (i = pmic_arb->last_apid; ; i++, apid_info++) {


Can we keep apid instead of replacing it with i please? That will
reduce the noise in this function.


Sure. Will do that in the next patch.

+   offset = PMIC_ARB_REG_CHNL(i);
+   if (offset >= pmic_arb->core_size)
break;

-   regval = readl_relaxed(pa->cnfg +
- SPMI_OWNERSHIP_TABLE_REG(apid));
-   pa->apid_data[apid].owner = SPMI_OWNERSHIP_PERIPH2OWNER(regval);
+   regval = readl_relaxed(pmic_arb->cnfg +
+   SPMI_OWNERSHIP_TABLE_REG(i));
+   apid_info->owner = SPMI_OWNERSHIP_PERIPH2OWNER(regval);

-   regval = readl_relaxed(pa->core + offset);
+   regval = readl_relaxed(pmic_arb->core + offset);
if (!regval)
continue;

id = (regval >> 8) & PMIC_ARB_PPID_MASK;
-   pa->ppid_to_apid[id] = apid | PMIC_ARB_CHAN_VALID;
-   pa->apid_data[apid].ppid = id;
+   pmic_arb->ppid_to_apid[id] = i | PMIC_ARB_APID_VALID;
+   apid_info->ppid = id;
if (id == ppid) {
-   apid |= PMIC_ARB_CHAN_VALID;
+   i |= PMIC_ARB_APID_VALID;
break;
}
}
-   pa->last_apid = apid & ~PMIC_ARB_CHAN_VALID;
+   pmic_arb->last_apid = i & ~PMIC_ARB_APID_VALID;

-   return apid;
+   return i;
 }


Otherwise patch looks ok.

Re: [PATCH v7 0/3] nvmem: upstream snvs_lpgpr driver

[Oleksij Rempel]

Hallo all,

Here Gentle Ping to the Old King ;)

DT is already ACKed.

On 20.06.2017 09:09, Oleksij Rempel wrote:

changes v7:
 - split imx6ul patch and squash it with with main patches.
 - spell fixes in the binding documentation
 - return regmap_bulk_read directly.

changes v6:
 - check if device is writable by reading GPR_SL and GPR_HL bits
 - use regmap_bulk_* functions instead of while() { regmap_read/write }
 - add patch for imx6ul

changes v5:
 - use dcfg->offset instead of priv->offset.

changes v4:
 - change dependencies in Kconfig
 - remove unused includes and order them alphabetically
 - set MODULE_LICENSE = GPL v2
 - remove unused int err variable

changes v3:
 - remove regmap and offset properties.

changes v2:
 - correct typos: Registe, parrent...

Oleksij Rempel (3):
  nvmem: dt: document SNVS LPGPR binding
  nvmem: add snvs_lpgpr driver
  ARM: dts: imx6qdl.dtsi/imx6ul.dtsi: add "fsl,imx6q-snvs-lpgpr" node

 .../devicetree/bindings/nvmem/snvs-lpgpr.txt   |  20 +++
 arch/arm/boot/dts/imx6qdl.dtsi |   4 +
 arch/arm/boot/dts/imx6ul.dtsi  |   4 +
 drivers/nvmem/Kconfig  |  10 ++
 drivers/nvmem/Makefile |   2 +
 drivers/nvmem/snvs_lpgpr.c | 155 +
 6 files changed, 195 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt
 create mode 100644 drivers/nvmem/snvs_lpgpr.c

Re: [PATCH 0/4] Add various TI-SCI DT nodes on 66AK2G SoCs

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

On 7/17/17 8:28 PM, Suman Anna wrote:

Hi Santosh,

The following patch series adds various TI-SCI related DTS nodes that
probe the corresponding TI-SCI genpd, clock and reset drivers for the
66AK2G platforms.

This is the second of two series, and these nodes along with the defconfig
patches finally allows adding other peripherals to the 66AK2G platforms.
All the new peripherals should/will be added without using the device id
macros [1]. Patches are baselined on 4.13-rc1 and are intended for the 4.14
merge window.

And this one looks good as well. Please ping me if you don't see this 
show up in next, by next week.


Regards,
Santosh

Re: [PATCH 0/4] Add various TI-SCI DT nodes on 66AK2G SoCs

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

On 7/17/17 8:28 PM, Suman Anna wrote:

Hi Santosh,

The following patch series adds various TI-SCI related DTS nodes that
probe the corresponding TI-SCI genpd, clock and reset drivers for the
66AK2G platforms.

This is the second of two series, and these nodes along with the defconfig
patches finally allows adding other peripherals to the 66AK2G platforms.
All the new peripherals should/will be added without using the device id
macros [1]. Patches are baselined on 4.13-rc1 and are intended for the 4.14
merge window.

And this one looks good as well. Please ping me if you don't see this 
show up in next, by next week.


Regards,
Santosh

Re: [PATCH 0/3] Keystone defconfig updates

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

On 7/17/17 8:26 PM, Suman Anna wrote:

Hi Santosh,

The following patch series adds the necessary defconfig options to
keystone_defconfig to enable the TI-SCI protocol and their respective
genpd/clock/reset drivers.

This is the first of two series that provides a baseline for adding
and/or enabling other peripherals on the 66AK2G platforms. Patches are
baselined on 4.13-rc1 and are intended for the 4.14 merge window.


Looks good. Will add this to 4.14 queue and push it to next by
weekend.

Regards,
Santosh

Re: [PATCH 0/3] Keystone defconfig updates

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

On 7/17/17 8:26 PM, Suman Anna wrote:

Hi Santosh,

The following patch series adds the necessary defconfig options to
keystone_defconfig to enable the TI-SCI protocol and their respective
genpd/clock/reset drivers.

This is the first of two series that provides a baseline for adding
and/or enabling other peripherals on the 66AK2G platforms. Patches are
baselined on 4.13-rc1 and are intended for the 4.14 merge window.


Looks good. Will add this to 4.14 queue and push it to next by
weekend.

Regards,
Santosh

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

[Andi Kleen]

> We need a tradeoff here IMHO. I'll check Daniel's work to understand how/if
> it's better than menu governor.

I still would like to see how the fast path without the C1 heuristic works.

Fast pathing is a different concept from a better predictor. IMHO we need
both, but the first is likely lower hanging fruit.

-Andi

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

[Andi Kleen]

> We need a tradeoff here IMHO. I'll check Daniel's work to understand how/if
> it's better than menu governor.

I still would like to see how the fast path without the C1 heuristic works.

Fast pathing is a different concept from a better predictor. IMHO we need
both, but the first is likely lower hanging fruit.

-Andi