Re: [PATCH] regulator: Convert to using %pOF instead of full_name

[Krzysztof Kozlowski]

On Tue, Jul 18, 2017 at 04:43:26PM -0500, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
> 
> Signed-off-by: Rob Herring 
> Cc: Liam Girdwood 
> Cc: Mark Brown 
> Cc: Sangbeom Kim 
> Cc: Krzysztof Kozlowski 
> Cc: Bartlomiej Zolnierkiewicz 
> Cc: Philipp Zabel 
> Cc: linux-samsung-...@vger.kernel.org
> ---
>  drivers/regulator/core.c  | 4 ++--
>  drivers/regulator/max1586.c   | 2 +-
>  drivers/regulator/s5m8767.c   | 4 ++--
>  drivers/reset/reset-socfpga.c | 4 ++--
>  4 files changed, 7 insertions(+), 7 deletions(-)
> 

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH] pinctrl: Convert to using %pOF instead of full_name

[Ludovic Desroches]

On Tue, Jul 18, 2017 at 04:43:23PM -0500, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
> 
> Signed-off-by: Rob Herring 
> Cc: Linus Walleij 
> Cc: Lee Jones 
> Cc: Eric Anholt 
> Cc: Stefan Wahren 
> Cc: Florian Fainelli 
> Cc: Ray Jui 
> Cc: Scott Branden 
> Cc: bcm-kernel-feedback-l...@broadcom.com
> Cc: Ludovic Desroches 
> Cc: Patrice Chotard 
> Cc: Tomasz Figa 
> Cc: Krzysztof Kozlowski 
> Cc: Sylwester Nawrocki 
> Cc: Laurent Pinchart 
> Cc: Geert Uytterhoeven 
> Cc: Barry Song 
> Cc: linux-g...@vger.kernel.org
> Cc: linux-rpi-ker...@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: ker...@stlinux.com
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-renesas-...@vger.kernel.org
> ---
>  drivers/pinctrl/bcm/pinctrl-bcm2835.c | 25 +++--
>  drivers/pinctrl/devicetree.c  |  4 ++--
>  drivers/pinctrl/freescale/pinctrl-imx.c   |  8 +++-
>  drivers/pinctrl/pinconf-generic.c |  7 +++
>  drivers/pinctrl/pinctrl-at91-pio4.c   | 11 +--

Acked-by: Ludovic Desroches 

>  drivers/pinctrl/pinctrl-st.c  |  2 +-
>  drivers/pinctrl/pinctrl-tb10x.c   |  4 ++--
>  drivers/pinctrl/samsung/pinctrl-samsung.c |  6 +++---
>  drivers/pinctrl/sh-pfc/pinctrl.c  |  2 +-
>  drivers/pinctrl/sirf/pinctrl-sirf.c   |  6 +++---
>  10 files changed, 34 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c 
> b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> index 230883168e99..3e71e5d782ee 100644
> --- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> +++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> @@ -692,8 +692,7 @@ static int bcm2835_pctl_dt_node_to_map_func(struct 
> bcm2835_pinctrl *pc,
>   struct pinctrl_map *map = *maps;
> 
>   if (fnum >= ARRAY_SIZE(bcm2835_functions)) {
> - dev_err(pc->dev, "%s: invalid brcm,function %d\n",
> - of_node_full_name(np), fnum);
> + dev_err(pc->dev, "%pOF: invalid brcm,function %d\n", np, fnum);
>   return -EINVAL;
>   }
> 
> @@ -713,8 +712,7 @@ static int bcm2835_pctl_dt_node_to_map_pull(struct 
> bcm2835_pinctrl *pc,
>   unsigned long *configs;
> 
>   if (pull > 2) {
> - dev_err(pc->dev, "%s: invalid brcm,pull %d\n",
> - of_node_full_name(np), pull);
> + dev_err(pc->dev, "%pOF: invalid brcm,pull %d\n", np, pull);
>   return -EINVAL;
>   }
> 
> @@ -745,8 +743,7 @@ static int bcm2835_pctl_dt_node_to_map(struct pinctrl_dev 
> *pctldev,
> 
>   pins = of_find_property(np, "brcm,pins", NULL);
>   if (!pins) {
> - dev_err(pc->dev, "%s: missing brcm,pins property\n",
> - of_node_full_name(np));
> + dev_err(pc->dev, "%pOF: missing brcm,pins property\n", np);
>   return -EINVAL;
>   }
> 
> @@ -755,8 +752,8 @@ static int bcm2835_pctl_dt_node_to_map(struct pinctrl_dev 
> *pctldev,
> 
>   if (!funcs && !pulls) {
>   dev_err(pc->dev,
> - "%s: neither brcm,function nor brcm,pull specified\n",
> - of_node_full_name(np));
> + "%pOF: neither brcm,function nor brcm,pull specified\n",
> + np);
>   return -EINVAL;
>   }
> 
> @@ -766,15 +763,15 @@ static int bcm2835_pctl_dt_node_to_map(struct 
> pinctrl_dev *pctldev,
> 
>   if (num_funcs > 1 && num_funcs != num_pins) {
>   dev_err(pc->dev,
> - "%s: brcm,function must have 1 or %d entries\n",
> - of_node_full_name(np), num_pins);
> + "%pOF: brcm,function must have 1 or %d entries\n",
> + np, num_pins);
>   return -EINVAL;
>   }
> 
>   if (num_pulls > 1 && num_pulls != num_pins) {
>   dev_err(pc->dev,
> - "%s: brcm,pull must have 1 or %d entries\n",
> - of_node_full_name(np), num_pins);
> + "%pOF: brcm,pull must have 1 or %d entries\n",
> + np, num_pins);
>   return -EINVAL;
>   }
> 
> @@ -793,8 +790,8 @@ static int bcm2835_pctl_dt_node_to_map(struct pinctrl_dev 
> *pctldev,
>   if (err)
>   goto out;
>   if (pin >= ARRAY_SIZE(bcm2835_gpio_pins)) {
> - dev_err(pc->dev, "%s: invalid brcm,pins 

Re: [PATCH] regulator: Convert to using %pOF instead of full_name

[Krzysztof Kozlowski]

On Tue, Jul 18, 2017 at 04:43:26PM -0500, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
> 
> Signed-off-by: Rob Herring 
> Cc: Liam Girdwood 
> Cc: Mark Brown 
> Cc: Sangbeom Kim 
> Cc: Krzysztof Kozlowski 
> Cc: Bartlomiej Zolnierkiewicz 
> Cc: Philipp Zabel 
> Cc: linux-samsung-...@vger.kernel.org
> ---
>  drivers/regulator/core.c  | 4 ++--
>  drivers/regulator/max1586.c   | 2 +-
>  drivers/regulator/s5m8767.c   | 4 ++--
>  drivers/reset/reset-socfpga.c | 4 ++--
>  4 files changed, 7 insertions(+), 7 deletions(-)
> 

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH] pinctrl: Convert to using %pOF instead of full_name

[Ludovic Desroches]

On Tue, Jul 18, 2017 at 04:43:23PM -0500, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
> 
> Signed-off-by: Rob Herring 
> Cc: Linus Walleij 
> Cc: Lee Jones 
> Cc: Eric Anholt 
> Cc: Stefan Wahren 
> Cc: Florian Fainelli 
> Cc: Ray Jui 
> Cc: Scott Branden 
> Cc: bcm-kernel-feedback-l...@broadcom.com
> Cc: Ludovic Desroches 
> Cc: Patrice Chotard 
> Cc: Tomasz Figa 
> Cc: Krzysztof Kozlowski 
> Cc: Sylwester Nawrocki 
> Cc: Laurent Pinchart 
> Cc: Geert Uytterhoeven 
> Cc: Barry Song 
> Cc: linux-g...@vger.kernel.org
> Cc: linux-rpi-ker...@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: ker...@stlinux.com
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-renesas-...@vger.kernel.org
> ---
>  drivers/pinctrl/bcm/pinctrl-bcm2835.c | 25 +++--
>  drivers/pinctrl/devicetree.c  |  4 ++--
>  drivers/pinctrl/freescale/pinctrl-imx.c   |  8 +++-
>  drivers/pinctrl/pinconf-generic.c |  7 +++
>  drivers/pinctrl/pinctrl-at91-pio4.c   | 11 +--

Acked-by: Ludovic Desroches 

>  drivers/pinctrl/pinctrl-st.c  |  2 +-
>  drivers/pinctrl/pinctrl-tb10x.c   |  4 ++--
>  drivers/pinctrl/samsung/pinctrl-samsung.c |  6 +++---
>  drivers/pinctrl/sh-pfc/pinctrl.c  |  2 +-
>  drivers/pinctrl/sirf/pinctrl-sirf.c   |  6 +++---
>  10 files changed, 34 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c 
> b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> index 230883168e99..3e71e5d782ee 100644
> --- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> +++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> @@ -692,8 +692,7 @@ static int bcm2835_pctl_dt_node_to_map_func(struct 
> bcm2835_pinctrl *pc,
>   struct pinctrl_map *map = *maps;
> 
>   if (fnum >= ARRAY_SIZE(bcm2835_functions)) {
> - dev_err(pc->dev, "%s: invalid brcm,function %d\n",
> - of_node_full_name(np), fnum);
> + dev_err(pc->dev, "%pOF: invalid brcm,function %d\n", np, fnum);
>   return -EINVAL;
>   }
> 
> @@ -713,8 +712,7 @@ static int bcm2835_pctl_dt_node_to_map_pull(struct 
> bcm2835_pinctrl *pc,
>   unsigned long *configs;
> 
>   if (pull > 2) {
> - dev_err(pc->dev, "%s: invalid brcm,pull %d\n",
> - of_node_full_name(np), pull);
> + dev_err(pc->dev, "%pOF: invalid brcm,pull %d\n", np, pull);
>   return -EINVAL;
>   }
> 
> @@ -745,8 +743,7 @@ static int bcm2835_pctl_dt_node_to_map(struct pinctrl_dev 
> *pctldev,
> 
>   pins = of_find_property(np, "brcm,pins", NULL);
>   if (!pins) {
> - dev_err(pc->dev, "%s: missing brcm,pins property\n",
> - of_node_full_name(np));
> + dev_err(pc->dev, "%pOF: missing brcm,pins property\n", np);
>   return -EINVAL;
>   }
> 
> @@ -755,8 +752,8 @@ static int bcm2835_pctl_dt_node_to_map(struct pinctrl_dev 
> *pctldev,
> 
>   if (!funcs && !pulls) {
>   dev_err(pc->dev,
> - "%s: neither brcm,function nor brcm,pull specified\n",
> - of_node_full_name(np));
> + "%pOF: neither brcm,function nor brcm,pull specified\n",
> + np);
>   return -EINVAL;
>   }
> 
> @@ -766,15 +763,15 @@ static int bcm2835_pctl_dt_node_to_map(struct 
> pinctrl_dev *pctldev,
> 
>   if (num_funcs > 1 && num_funcs != num_pins) {
>   dev_err(pc->dev,
> - "%s: brcm,function must have 1 or %d entries\n",
> - of_node_full_name(np), num_pins);
> + "%pOF: brcm,function must have 1 or %d entries\n",
> + np, num_pins);
>   return -EINVAL;
>   }
> 
>   if (num_pulls > 1 && num_pulls != num_pins) {
>   dev_err(pc->dev,
> - "%s: brcm,pull must have 1 or %d entries\n",
> - of_node_full_name(np), num_pins);
> + "%pOF: brcm,pull must have 1 or %d entries\n",
> + np, num_pins);
>   return -EINVAL;
>   }
> 
> @@ -793,8 +790,8 @@ static int bcm2835_pctl_dt_node_to_map(struct pinctrl_dev 
> *pctldev,
>   if (err)
>   goto out;
>   if (pin >= ARRAY_SIZE(bcm2835_gpio_pins)) {
> - dev_err(pc->dev, "%s: invalid brcm,pins value %d\n",
> - of_node_full_name(np), pin);
> + dev_err(pc->dev, "%pOF: invalid brcm,pins value %d\n",
> + np, pin);
>   err = -EINVAL;
>   goto out;
>   }
> diff --git a/drivers/pinctrl/devicetree.c b/drivers/pinctrl/devicetree.c
> index 0e5c9f14a706..0a20afc2210c 100644

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

[Borislav Petkov]

On Tue, Jul 18, 2017 at 06:15:45PM -0300, Mauro Carvalho Chehab wrote:
> The way it is, ghes_edac is a poor man's driver. What it hopefully
> provide is a detection that an error happened, without really telling
> the user what component should be replaced.

I beg to differ. From the UEFI spec:

"The module number of the memory error location. (NODE, CARD, and MODULE
should provide the information necessary to identify the failing FRU)."

So this tuple is sufficient to pinpoint the DIMM, IIUC.

Which means, ghes_edac can have a single layer of DIMMs without channels.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

[Borislav Petkov]

On Tue, Jul 18, 2017 at 06:15:45PM -0300, Mauro Carvalho Chehab wrote:
> The way it is, ghes_edac is a poor man's driver. What it hopefully
> provide is a detection that an error happened, without really telling
> the user what component should be replaced.

I beg to differ. From the UEFI spec:

"The module number of the memory error location. (NODE, CARD, and MODULE
should provide the information necessary to identify the failing FRU)."

So this tuple is sufficient to pinpoint the DIMM, IIUC.

Which means, ghes_edac can have a single layer of DIMMs without channels.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [PATCH] perf probe: Fix build failure for get_target_map()

[Michael Ellerman]

Arnaldo Carvalho de Melo  writes:

> Em Tue, Jul 18, 2017 at 07:19:45PM +1000, Michael Ellerman escreveu:
>> Arnaldo Carvalho de Melo  writes:
>> 
>> > Em Mon, Jul 17, 2017 at 04:02:22PM +0530, Ravi Bangoria escreveu:
>> >> Commit 801bc8193463 ("perf probe: Allow placing uprobes in
>> >> alternate namespaces.") is causing a build failure on powerpc:
>> >> 
>> >>   error: incompatible type for argument 2 of 'get_target_map'
>> >>   map = get_target_map(pev->target, pev->uprobes);
>> >> ^~~
>> >> 
>> >> Fix it by changing parameters of get_target_map().
>> >
>> > Thanks, since this hasn't made it to Ingo I'll fold this into the patch
>> > where the problem was introduced, adding credits to you, leaving a Link
>> > to this message, so that we don't lose bisection in this area on
>> > powerpc.
>> 
>> Thanks.
>> 
>> I just bisected to this commit too - should have checked the list first! :)
>
> :-)
>
> I just re-ammended this cset to cover the !HAVE_DWARF_SUPPORT build as
> well, just re-force-pushed acme/perf/core with this fix.

Thanks, all green here.

cheers

Re: [PATCH] perf probe: Fix build failure for get_target_map()

[Michael Ellerman]

Arnaldo Carvalho de Melo  writes:

> Em Tue, Jul 18, 2017 at 07:19:45PM +1000, Michael Ellerman escreveu:
>> Arnaldo Carvalho de Melo  writes:
>> 
>> > Em Mon, Jul 17, 2017 at 04:02:22PM +0530, Ravi Bangoria escreveu:
>> >> Commit 801bc8193463 ("perf probe: Allow placing uprobes in
>> >> alternate namespaces.") is causing a build failure on powerpc:
>> >> 
>> >>   error: incompatible type for argument 2 of 'get_target_map'
>> >>   map = get_target_map(pev->target, pev->uprobes);
>> >> ^~~
>> >> 
>> >> Fix it by changing parameters of get_target_map().
>> >
>> > Thanks, since this hasn't made it to Ingo I'll fold this into the patch
>> > where the problem was introduced, adding credits to you, leaving a Link
>> > to this message, so that we don't lose bisection in this area on
>> > powerpc.
>> 
>> Thanks.
>> 
>> I just bisected to this commit too - should have checked the list first! :)
>
> :-)
>
> I just re-ammended this cset to cover the !HAVE_DWARF_SUPPORT build as
> well, just re-force-pushed acme/perf/core with this fix.

Thanks, all green here.

cheers

Re: [PATCH v4 1/5] powerpc: io.h: move iomap.h include so that it can use readq/writeq defs

[Michael Ellerman]

Logan Gunthorpe  writes:

> Subsequent patches in this series makes use of the readq and writeq
> defines in iomap.h. However, as is, they get missed on the powerpc
> platform seeing the include comes before the define. This patch
> moves the include down to fix this.
>
> Signed-off-by: Logan Gunthorpe 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: Nicholas Piggin 
> Cc: Suresh Warrier 
> Cc: "Oliver O'Halloran" 
> ---
>  arch/powerpc/include/asm/io.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Seems fair enough, have you tested it at all?

cheers

Re: [PATCH v4 1/5] powerpc: io.h: move iomap.h include so that it can use readq/writeq defs

[Michael Ellerman]

Logan Gunthorpe  writes:

> Subsequent patches in this series makes use of the readq and writeq
> defines in iomap.h. However, as is, they get missed on the powerpc
> platform seeing the include comes before the define. This patch
> moves the include down to fix this.
>
> Signed-off-by: Logan Gunthorpe 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: Nicholas Piggin 
> Cc: Suresh Warrier 
> Cc: "Oliver O'Halloran" 
> ---
>  arch/powerpc/include/asm/io.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Seems fair enough, have you tested it at all?

cheers

Re: [PATCH] mmc: Convert to using %pOF instead of full_name

[Ludovic Desroches]

On Tue, Jul 18, 2017 at 04:43:16PM -0500, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
> 
> Signed-off-by: Rob Herring 
> Cc: Ulf Hansson 
> Cc: Ludovic Desroches 
> Cc: Jan Glauber 
> Cc: David Daney 
> Cc: "Steven J. Hill" 
> Cc: linux-...@vger.kernel.org
> ---
>  drivers/mmc/core/core.c  | 8 
>  drivers/mmc/host/atmel-mci.c | 4 ++--

Acked-by: Ludovic Desroches 

>  drivers/mmc/host/cavium.c| 6 ++
>  3 files changed, 8 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 26431267a3e2..6b4117615ad6 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -1137,11 +1137,11 @@ int mmc_of_parse_voltage(struct device_node *np, u32 
> *mask)
>   voltage_ranges = of_get_property(np, "voltage-ranges", _ranges);
>   num_ranges = num_ranges / sizeof(*voltage_ranges) / 2;
>   if (!voltage_ranges) {
> - pr_debug("%s: voltage-ranges unspecified\n", np->full_name);
> + pr_debug("%pOF: voltage-ranges unspecified\n", np);
>   return 0;
>   }
>   if (!num_ranges) {
> - pr_err("%s: voltage-ranges empty\n", np->full_name);
> + pr_err("%pOF: voltage-ranges empty\n", np);
>   return -EINVAL;
>   }
> 
> @@ -1153,8 +1153,8 @@ int mmc_of_parse_voltage(struct device_node *np, u32 
> *mask)
>   be32_to_cpu(voltage_ranges[j]),
>   be32_to_cpu(voltage_ranges[j + 1]));
>   if (!ocr_mask) {
> - pr_err("%s: voltage-range #%d is invalid\n",
> - np->full_name, i);
> + pr_err("%pOF: voltage-range #%d is invalid\n",
> + np, i);
>   return -EINVAL;
>   }
>   *mask |= ocr_mask;
> diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c
> index 97de2d32ba84..b7c1cd384306 100644
> --- a/drivers/mmc/host/atmel-mci.c
> +++ b/drivers/mmc/host/atmel-mci.c
> @@ -665,8 +665,8 @@ atmci_of_init(struct platform_device *pdev)
> 
>   for_each_child_of_node(np, cnp) {
>   if (of_property_read_u32(cnp, "reg", _id)) {
> - dev_warn(>dev, "reg property is missing for %s\n",
> -  cnp->full_name);
> + dev_warn(>dev, "reg property is missing for 
> %pOF\n",
> +  cnp);
>   continue;
>   }
> 
> diff --git a/drivers/mmc/host/cavium.c b/drivers/mmc/host/cavium.c
> index 3686d77c717b..27fb625cbcf3 100644
> --- a/drivers/mmc/host/cavium.c
> +++ b/drivers/mmc/host/cavium.c
> @@ -957,14 +957,12 @@ static int cvm_mmc_of_parse(struct device *dev, struct 
> cvm_mmc_slot *slot)
> 
>   ret = of_property_read_u32(node, "reg", );
>   if (ret) {
> - dev_err(dev, "Missing or invalid reg property on %s\n",
> - of_node_full_name(node));
> + dev_err(dev, "Missing or invalid reg property on %pOF\n", node);
>   return ret;
>   }
> 
>   if (id >= CAVIUM_MAX_MMC || slot->host->slot[id]) {
> - dev_err(dev, "Invalid reg property on %s\n",
> - of_node_full_name(node));
> + dev_err(dev, "Invalid reg property on %pOF\n", node);
>   return -EINVAL;
>   }
> 
> --
> 2.11.0
> 

Re: [PATCH] mmc: Convert to using %pOF instead of full_name

[Ludovic Desroches]

On Tue, Jul 18, 2017 at 04:43:16PM -0500, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
> 
> Signed-off-by: Rob Herring 
> Cc: Ulf Hansson 
> Cc: Ludovic Desroches 
> Cc: Jan Glauber 
> Cc: David Daney 
> Cc: "Steven J. Hill" 
> Cc: linux-...@vger.kernel.org
> ---
>  drivers/mmc/core/core.c  | 8 
>  drivers/mmc/host/atmel-mci.c | 4 ++--

Acked-by: Ludovic Desroches 

>  drivers/mmc/host/cavium.c| 6 ++
>  3 files changed, 8 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 26431267a3e2..6b4117615ad6 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -1137,11 +1137,11 @@ int mmc_of_parse_voltage(struct device_node *np, u32 
> *mask)
>   voltage_ranges = of_get_property(np, "voltage-ranges", _ranges);
>   num_ranges = num_ranges / sizeof(*voltage_ranges) / 2;
>   if (!voltage_ranges) {
> - pr_debug("%s: voltage-ranges unspecified\n", np->full_name);
> + pr_debug("%pOF: voltage-ranges unspecified\n", np);
>   return 0;
>   }
>   if (!num_ranges) {
> - pr_err("%s: voltage-ranges empty\n", np->full_name);
> + pr_err("%pOF: voltage-ranges empty\n", np);
>   return -EINVAL;
>   }
> 
> @@ -1153,8 +1153,8 @@ int mmc_of_parse_voltage(struct device_node *np, u32 
> *mask)
>   be32_to_cpu(voltage_ranges[j]),
>   be32_to_cpu(voltage_ranges[j + 1]));
>   if (!ocr_mask) {
> - pr_err("%s: voltage-range #%d is invalid\n",
> - np->full_name, i);
> + pr_err("%pOF: voltage-range #%d is invalid\n",
> + np, i);
>   return -EINVAL;
>   }
>   *mask |= ocr_mask;
> diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c
> index 97de2d32ba84..b7c1cd384306 100644
> --- a/drivers/mmc/host/atmel-mci.c
> +++ b/drivers/mmc/host/atmel-mci.c
> @@ -665,8 +665,8 @@ atmci_of_init(struct platform_device *pdev)
> 
>   for_each_child_of_node(np, cnp) {
>   if (of_property_read_u32(cnp, "reg", _id)) {
> - dev_warn(>dev, "reg property is missing for %s\n",
> -  cnp->full_name);
> + dev_warn(>dev, "reg property is missing for 
> %pOF\n",
> +  cnp);
>   continue;
>   }
> 
> diff --git a/drivers/mmc/host/cavium.c b/drivers/mmc/host/cavium.c
> index 3686d77c717b..27fb625cbcf3 100644
> --- a/drivers/mmc/host/cavium.c
> +++ b/drivers/mmc/host/cavium.c
> @@ -957,14 +957,12 @@ static int cvm_mmc_of_parse(struct device *dev, struct 
> cvm_mmc_slot *slot)
> 
>   ret = of_property_read_u32(node, "reg", );
>   if (ret) {
> - dev_err(dev, "Missing or invalid reg property on %s\n",
> - of_node_full_name(node));
> + dev_err(dev, "Missing or invalid reg property on %pOF\n", node);
>   return ret;
>   }
> 
>   if (id >= CAVIUM_MAX_MMC || slot->host->slot[id]) {
> - dev_err(dev, "Invalid reg property on %s\n",
> - of_node_full_name(node));
> + dev_err(dev, "Invalid reg property on %pOF\n", node);
>   return -EINVAL;
>   }
> 
> --
> 2.11.0
> 

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

[Borislav Petkov]

On Tue, Jul 18, 2017 at 07:58:54PM +, Kani, Toshimitsu wrote:
> I have HPE Haswell and Skylake test systems with GHES, but they do not
> hide IMCs from the OS.  So, the sb_edac and skx_edac drivers get
> attached on these systems when ghes_edac is disabled.

That's how it is supposed to work. The platform drivers are the
fallback, practically.

But this is the important piece of info I was looking for - having GHES
enabled in the firmware does not prevent the platform drivers from
loading. But I think we have a better solution, the FF thing.

> Hmm... what's the platform name of this box?  I can look into this case
> if you need.

You can but that's not addressing the issue as a whole so it'll be a
waste of time.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [RFC PATCH] mm, oom: allow oom reaper to race with exit_mmap

[Michal Hocko]

On Thu 29-06-17 10:46:21, Michal Hocko wrote:
> Forgot to CC Hugh.
> 
> Hugh, Andrew, do you see this could cause any problem wrt.
> ksm/khugepaged exit path?

ping. I would really appreciate some help here. I would like to resend
the patch soon.

> On Mon 26-06-17 15:03:46, Michal Hocko wrote:
> > From: Michal Hocko 
> > 
> > David has noticed that the oom killer might kill additional tasks while
> > the existing victim hasn't terminated yet because the oom_reaper marks
> > the curent victim MMF_OOM_SKIP too early when mm->mm_users dropped down
> > to 0. The race is as follows
> > 
> > oom_reap_task   do_exit
> >   exit_mm
> >   __oom_reap_task_mm
> > mmput
> >   __mmput
> > mmget_not_zero # fails
> > exit_mmap # frees memory
> >   set_bit(MMF_OOM_SKIP)
> > 
> > Currently we are try to reduce a risk of this race by taking oom_lock
> > and wait for out_of_memory sleep while holding the lock to give the
> > victim some time to exit. This is quite suboptimal approach because
> > there is no guarantee the victim (especially a large one) will manage
> > to unmap its address space and free enough memory to the particular oom
> > domain which needs a memory (e.g. a specific NUMA node).
> > 
> > Fix this problem by allowing __oom_reap_task_mm and __mmput path to
> > race. __oom_reap_task_mm is basically MADV_DONTNEED and that is allowed
> > to run in parallel with other unmappers (hence the mmap_sem for read).
> > The only tricky part is we have to exclude page tables tear down and all
> > operations which modify the address space in the __mmput path. exit_mmap
> > doesn't expect any other users so it doesn't use any locking. Nothing
> > really forbids us to use mmap_sem for write, though. In fact we are
> > already relying on this lock earlier in the __mmput path to synchronize
> > with ksm and khugepaged.
> > 
> > Take the exclusive mmap_sem when calling free_pgtables and destroying
> > vmas to sync with __oom_reap_task_mm which take the lock for read. All
> > other operations can safely race with the parallel unmap.
> > 
> > Reported-by: David Rientjes 
> > Fixes: 26db62f179d1 ("oom: keep mm of the killed task available")
> > Signed-off-by: Michal Hocko 
> > ---
> > 
> > Hi,
> > I am sending this as an RFC because I am not yet sure I haven't missed
> > something subtle here but the appoach should work in principle. I have
> > run it through some of my OOM stress tests to see if anything blows up
> > and it all went smoothly.
> > 
> > The issue has been brought up by David [1]. There were some attempts to
> > address it in oom proper [2][3] but the first one would cause problems
> > on their own [4] while the later is just too hairy.
> > 
> > Thoughts, objections, alternatives?
> > 
> > [1] 
> > http://lkml.kernel.org/r/alpine.deb.2.10.1706141632100.93...@chino.kir.corp.google.com
> > [2] 
> > http://lkml.kernel.org/r/201706171417.jhg48401.joqlhmfsvoo...@i-love.sakura.ne.jp
> > [3] http://lkml.kernel.org/r/201706220053.v5m0rmou078...@www262.sakura.ne.jp
> > [4] http://lkml.kernel.org/r/201706210217.v5l2hazc081...@www262.sakura.ne.jp
> > 
> >  mm/mmap.c |  7 +++
> >  mm/oom_kill.c | 40 ++--
> >  2 files changed, 9 insertions(+), 38 deletions(-)
> > 
> > diff --git a/mm/mmap.c b/mm/mmap.c
> > index 3bd5ecd20d4d..253808e716dc 100644
> > --- a/mm/mmap.c
> > +++ b/mm/mmap.c
> > @@ -2962,6 +2962,11 @@ void exit_mmap(struct mm_struct *mm)
> > /* Use -1 here to ensure all VMAs in the mm are unmapped */
> > unmap_vmas(, vma, 0, -1);
> >  
> > +   /*
> > +* oom reaper might race with exit_mmap so make sure we won't free
> > +* page tables or unmap VMAs under its feet
> > +*/
> > +   down_write(>mmap_sem);
> > free_pgtables(, vma, FIRST_USER_ADDRESS, USER_PGTABLES_CEILING);
> > tlb_finish_mmu(, 0, -1);
> >  
> > @@ -2974,7 +2979,9 @@ void exit_mmap(struct mm_struct *mm)
> > nr_accounted += vma_pages(vma);
> > vma = remove_vma(vma);
> > }
> > +   mm->mmap = NULL;
> > vm_unacct_memory(nr_accounted);
> > +   up_write(>mmap_sem);
> >  }
> >  
> >  /* Insert vm structure into process list sorted by address
> > diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> > index 0e2c925e7826..5dc0ff22d567 100644
> > --- a/mm/oom_kill.c
> > +++ b/mm/oom_kill.c
> > @@ -472,36 +472,8 @@ static bool __oom_reap_task_mm(struct task_struct 
> > *tsk, struct mm_struct *mm)
> > struct vm_area_struct *vma;
> > bool ret = true;
> >  
> > -   /*
> > -* We have to make sure to not race with the victim exit path
> > -* and cause premature new oom victim selection:
> > -* __oom_reap_task_mm   exit_mm
> > -*   mmget_not_zero
> > -*

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

[Borislav Petkov]

On Tue, Jul 18, 2017 at 07:58:54PM +, Kani, Toshimitsu wrote:
> I have HPE Haswell and Skylake test systems with GHES, but they do not
> hide IMCs from the OS.  So, the sb_edac and skx_edac drivers get
> attached on these systems when ghes_edac is disabled.

That's how it is supposed to work. The platform drivers are the
fallback, practically.

But this is the important piece of info I was looking for - having GHES
enabled in the firmware does not prevent the platform drivers from
loading. But I think we have a better solution, the FF thing.

> Hmm... what's the platform name of this box?  I can look into this case
> if you need.

You can but that's not addressing the issue as a whole so it'll be a
waste of time.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [RFC PATCH] mm, oom: allow oom reaper to race with exit_mmap

[Michal Hocko]

On Thu 29-06-17 10:46:21, Michal Hocko wrote:
> Forgot to CC Hugh.
> 
> Hugh, Andrew, do you see this could cause any problem wrt.
> ksm/khugepaged exit path?

ping. I would really appreciate some help here. I would like to resend
the patch soon.

> On Mon 26-06-17 15:03:46, Michal Hocko wrote:
> > From: Michal Hocko 
> > 
> > David has noticed that the oom killer might kill additional tasks while
> > the existing victim hasn't terminated yet because the oom_reaper marks
> > the curent victim MMF_OOM_SKIP too early when mm->mm_users dropped down
> > to 0. The race is as follows
> > 
> > oom_reap_task   do_exit
> >   exit_mm
> >   __oom_reap_task_mm
> > mmput
> >   __mmput
> > mmget_not_zero # fails
> > exit_mmap # frees memory
> >   set_bit(MMF_OOM_SKIP)
> > 
> > Currently we are try to reduce a risk of this race by taking oom_lock
> > and wait for out_of_memory sleep while holding the lock to give the
> > victim some time to exit. This is quite suboptimal approach because
> > there is no guarantee the victim (especially a large one) will manage
> > to unmap its address space and free enough memory to the particular oom
> > domain which needs a memory (e.g. a specific NUMA node).
> > 
> > Fix this problem by allowing __oom_reap_task_mm and __mmput path to
> > race. __oom_reap_task_mm is basically MADV_DONTNEED and that is allowed
> > to run in parallel with other unmappers (hence the mmap_sem for read).
> > The only tricky part is we have to exclude page tables tear down and all
> > operations which modify the address space in the __mmput path. exit_mmap
> > doesn't expect any other users so it doesn't use any locking. Nothing
> > really forbids us to use mmap_sem for write, though. In fact we are
> > already relying on this lock earlier in the __mmput path to synchronize
> > with ksm and khugepaged.
> > 
> > Take the exclusive mmap_sem when calling free_pgtables and destroying
> > vmas to sync with __oom_reap_task_mm which take the lock for read. All
> > other operations can safely race with the parallel unmap.
> > 
> > Reported-by: David Rientjes 
> > Fixes: 26db62f179d1 ("oom: keep mm of the killed task available")
> > Signed-off-by: Michal Hocko 
> > ---
> > 
> > Hi,
> > I am sending this as an RFC because I am not yet sure I haven't missed
> > something subtle here but the appoach should work in principle. I have
> > run it through some of my OOM stress tests to see if anything blows up
> > and it all went smoothly.
> > 
> > The issue has been brought up by David [1]. There were some attempts to
> > address it in oom proper [2][3] but the first one would cause problems
> > on their own [4] while the later is just too hairy.
> > 
> > Thoughts, objections, alternatives?
> > 
> > [1] 
> > http://lkml.kernel.org/r/alpine.deb.2.10.1706141632100.93...@chino.kir.corp.google.com
> > [2] 
> > http://lkml.kernel.org/r/201706171417.jhg48401.joqlhmfsvoo...@i-love.sakura.ne.jp
> > [3] http://lkml.kernel.org/r/201706220053.v5m0rmou078...@www262.sakura.ne.jp
> > [4] http://lkml.kernel.org/r/201706210217.v5l2hazc081...@www262.sakura.ne.jp
> > 
> >  mm/mmap.c |  7 +++
> >  mm/oom_kill.c | 40 ++--
> >  2 files changed, 9 insertions(+), 38 deletions(-)
> > 
> > diff --git a/mm/mmap.c b/mm/mmap.c
> > index 3bd5ecd20d4d..253808e716dc 100644
> > --- a/mm/mmap.c
> > +++ b/mm/mmap.c
> > @@ -2962,6 +2962,11 @@ void exit_mmap(struct mm_struct *mm)
> > /* Use -1 here to ensure all VMAs in the mm are unmapped */
> > unmap_vmas(, vma, 0, -1);
> >  
> > +   /*
> > +* oom reaper might race with exit_mmap so make sure we won't free
> > +* page tables or unmap VMAs under its feet
> > +*/
> > +   down_write(>mmap_sem);
> > free_pgtables(, vma, FIRST_USER_ADDRESS, USER_PGTABLES_CEILING);
> > tlb_finish_mmu(, 0, -1);
> >  
> > @@ -2974,7 +2979,9 @@ void exit_mmap(struct mm_struct *mm)
> > nr_accounted += vma_pages(vma);
> > vma = remove_vma(vma);
> > }
> > +   mm->mmap = NULL;
> > vm_unacct_memory(nr_accounted);
> > +   up_write(>mmap_sem);
> >  }
> >  
> >  /* Insert vm structure into process list sorted by address
> > diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> > index 0e2c925e7826..5dc0ff22d567 100644
> > --- a/mm/oom_kill.c
> > +++ b/mm/oom_kill.c
> > @@ -472,36 +472,8 @@ static bool __oom_reap_task_mm(struct task_struct 
> > *tsk, struct mm_struct *mm)
> > struct vm_area_struct *vma;
> > bool ret = true;
> >  
> > -   /*
> > -* We have to make sure to not race with the victim exit path
> > -* and cause premature new oom victim selection:
> > -* __oom_reap_task_mm   exit_mm
> > -*   mmget_not_zero
> > -*mmput
> > -*  

Re: [PATCH] pinctrl: Convert to using %pOF instead of full_name

[Krzysztof Kozlowski]

On Tue, Jul 18, 2017 at 04:43:23PM -0500, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
> 
> Signed-off-by: Rob Herring 
> Cc: Linus Walleij 
> Cc: Lee Jones 
> Cc: Eric Anholt 
> Cc: Stefan Wahren 
> Cc: Florian Fainelli 
> Cc: Ray Jui 
> Cc: Scott Branden 
> Cc: bcm-kernel-feedback-l...@broadcom.com
> Cc: Ludovic Desroches 
> Cc: Patrice Chotard 
> Cc: Tomasz Figa 
> Cc: Krzysztof Kozlowski 
> Cc: Sylwester Nawrocki 
> Cc: Laurent Pinchart 
> Cc: Geert Uytterhoeven 
> Cc: Barry Song 
> Cc: linux-g...@vger.kernel.org
> Cc: linux-rpi-ker...@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: ker...@stlinux.com
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-renesas-...@vger.kernel.org
> ---
>  drivers/pinctrl/bcm/pinctrl-bcm2835.c | 25 +++--
>  drivers/pinctrl/devicetree.c  |  4 ++--
>  drivers/pinctrl/freescale/pinctrl-imx.c   |  8 +++-
>  drivers/pinctrl/pinconf-generic.c |  7 +++
>  drivers/pinctrl/pinctrl-at91-pio4.c   | 11 +--
>  drivers/pinctrl/pinctrl-st.c  |  2 +-
>  drivers/pinctrl/pinctrl-tb10x.c   |  4 ++--
>  drivers/pinctrl/samsung/pinctrl-samsung.c |  6 +++---
>  drivers/pinctrl/sh-pfc/pinctrl.c  |  2 +-
>  drivers/pinctrl/sirf/pinctrl-sirf.c   |  6 +++---
>  10 files changed, 34 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c 
> b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> index 230883168e99..3e71e5d782ee 100644
> --- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> +++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> @@ -692,8 +692,7 @@ static int bcm2835_pctl_dt_node_to_map_func(struct 
> bcm2835_pinctrl *pc,
>   struct pinctrl_map *map = *maps;
> 
>   if (fnum >= ARRAY_SIZE(bcm2835_functions)) {
> - dev_err(pc->dev, "%s: invalid brcm,function %d\n",
> - of_node_full_name(np), fnum);
> + dev_err(pc->dev, "%pOF: invalid brcm,function %d\n", np, fnum);
>   return -EINVAL;
>   }
> 
> @@ -713,8 +712,7 @@ static int bcm2835_pctl_dt_node_to_map_pull(struct 
> bcm2835_pinctrl *pc,
>   unsigned long *configs;
> 
>   if (pull > 2) {
> - dev_err(pc->dev, "%s: invalid brcm,pull %d\n",
> - of_node_full_name(np), pull);
> + dev_err(pc->dev, "%pOF: invalid brcm,pull %d\n", np, pull);
>   return -EINVAL;
>   }
> 
> @@ -745,8 +743,7 @@ static int bcm2835_pctl_dt_node_to_map(struct pinctrl_dev 
> *pctldev,
> 
>   pins = of_find_property(np, "brcm,pins", NULL);
>   if (!pins) {
> - dev_err(pc->dev, "%s: missing brcm,pins property\n",
> - of_node_full_name(np));
> + dev_err(pc->dev, "%pOF: missing brcm,pins property\n", np);
>   return -EINVAL;
>   }
> 
> @@ -755,8 +752,8 @@ static int bcm2835_pctl_dt_node_to_map(struct pinctrl_dev 
> *pctldev,
> 
>   if (!funcs && !pulls) {
>   dev_err(pc->dev,
> - "%s: neither brcm,function nor brcm,pull specified\n",
> - of_node_full_name(np));
> + "%pOF: neither brcm,function nor brcm,pull specified\n",
> + np);
>   return -EINVAL;
>   }
> 
> @@ -766,15 +763,15 @@ static int bcm2835_pctl_dt_node_to_map(struct 
> pinctrl_dev *pctldev,
> 
>   if (num_funcs > 1 && num_funcs != num_pins) {
>   dev_err(pc->dev,
> - "%s: brcm,function must have 1 or %d entries\n",
> - of_node_full_name(np), num_pins);
> + "%pOF: brcm,function must have 1 or %d entries\n",
> + np, num_pins);
>   return -EINVAL;
>   }
> 
>   if (num_pulls > 1 && num_pulls != num_pins) {
>   dev_err(pc->dev,
> - "%s: brcm,pull must have 1 or %d entries\n",
> - of_node_full_name(np), num_pins);
> + "%pOF: brcm,pull must have 1 or %d entries\n",
> + np, num_pins);
>   return -EINVAL;
>   }
> 
> @@ -793,8 +790,8 @@ static int bcm2835_pctl_dt_node_to_map(struct pinctrl_dev 
> *pctldev,
>   if (err)
>   goto out;
>   if (pin >= ARRAY_SIZE(bcm2835_gpio_pins)) {
> - dev_err(pc->dev, "%s: invalid brcm,pins value %d\n",
> - of_node_full_name(np), 

Re: [PATCH] pinctrl: Convert to using %pOF instead of full_name

[Krzysztof Kozlowski]

On Tue, Jul 18, 2017 at 04:43:23PM -0500, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
> 
> Signed-off-by: Rob Herring 
> Cc: Linus Walleij 
> Cc: Lee Jones 
> Cc: Eric Anholt 
> Cc: Stefan Wahren 
> Cc: Florian Fainelli 
> Cc: Ray Jui 
> Cc: Scott Branden 
> Cc: bcm-kernel-feedback-l...@broadcom.com
> Cc: Ludovic Desroches 
> Cc: Patrice Chotard 
> Cc: Tomasz Figa 
> Cc: Krzysztof Kozlowski 
> Cc: Sylwester Nawrocki 
> Cc: Laurent Pinchart 
> Cc: Geert Uytterhoeven 
> Cc: Barry Song 
> Cc: linux-g...@vger.kernel.org
> Cc: linux-rpi-ker...@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: ker...@stlinux.com
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-renesas-...@vger.kernel.org
> ---
>  drivers/pinctrl/bcm/pinctrl-bcm2835.c | 25 +++--
>  drivers/pinctrl/devicetree.c  |  4 ++--
>  drivers/pinctrl/freescale/pinctrl-imx.c   |  8 +++-
>  drivers/pinctrl/pinconf-generic.c |  7 +++
>  drivers/pinctrl/pinctrl-at91-pio4.c   | 11 +--
>  drivers/pinctrl/pinctrl-st.c  |  2 +-
>  drivers/pinctrl/pinctrl-tb10x.c   |  4 ++--
>  drivers/pinctrl/samsung/pinctrl-samsung.c |  6 +++---
>  drivers/pinctrl/sh-pfc/pinctrl.c  |  2 +-
>  drivers/pinctrl/sirf/pinctrl-sirf.c   |  6 +++---
>  10 files changed, 34 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c 
> b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> index 230883168e99..3e71e5d782ee 100644
> --- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> +++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> @@ -692,8 +692,7 @@ static int bcm2835_pctl_dt_node_to_map_func(struct 
> bcm2835_pinctrl *pc,
>   struct pinctrl_map *map = *maps;
> 
>   if (fnum >= ARRAY_SIZE(bcm2835_functions)) {
> - dev_err(pc->dev, "%s: invalid brcm,function %d\n",
> - of_node_full_name(np), fnum);
> + dev_err(pc->dev, "%pOF: invalid brcm,function %d\n", np, fnum);
>   return -EINVAL;
>   }
> 
> @@ -713,8 +712,7 @@ static int bcm2835_pctl_dt_node_to_map_pull(struct 
> bcm2835_pinctrl *pc,
>   unsigned long *configs;
> 
>   if (pull > 2) {
> - dev_err(pc->dev, "%s: invalid brcm,pull %d\n",
> - of_node_full_name(np), pull);
> + dev_err(pc->dev, "%pOF: invalid brcm,pull %d\n", np, pull);
>   return -EINVAL;
>   }
> 
> @@ -745,8 +743,7 @@ static int bcm2835_pctl_dt_node_to_map(struct pinctrl_dev 
> *pctldev,
> 
>   pins = of_find_property(np, "brcm,pins", NULL);
>   if (!pins) {
> - dev_err(pc->dev, "%s: missing brcm,pins property\n",
> - of_node_full_name(np));
> + dev_err(pc->dev, "%pOF: missing brcm,pins property\n", np);
>   return -EINVAL;
>   }
> 
> @@ -755,8 +752,8 @@ static int bcm2835_pctl_dt_node_to_map(struct pinctrl_dev 
> *pctldev,
> 
>   if (!funcs && !pulls) {
>   dev_err(pc->dev,
> - "%s: neither brcm,function nor brcm,pull specified\n",
> - of_node_full_name(np));
> + "%pOF: neither brcm,function nor brcm,pull specified\n",
> + np);
>   return -EINVAL;
>   }
> 
> @@ -766,15 +763,15 @@ static int bcm2835_pctl_dt_node_to_map(struct 
> pinctrl_dev *pctldev,
> 
>   if (num_funcs > 1 && num_funcs != num_pins) {
>   dev_err(pc->dev,
> - "%s: brcm,function must have 1 or %d entries\n",
> - of_node_full_name(np), num_pins);
> + "%pOF: brcm,function must have 1 or %d entries\n",
> + np, num_pins);
>   return -EINVAL;
>   }
> 
>   if (num_pulls > 1 && num_pulls != num_pins) {
>   dev_err(pc->dev,
> - "%s: brcm,pull must have 1 or %d entries\n",
> - of_node_full_name(np), num_pins);
> + "%pOF: brcm,pull must have 1 or %d entries\n",
> + np, num_pins);
>   return -EINVAL;
>   }
> 
> @@ -793,8 +790,8 @@ static int bcm2835_pctl_dt_node_to_map(struct pinctrl_dev 
> *pctldev,
>   if (err)
>   goto out;
>   if (pin >= ARRAY_SIZE(bcm2835_gpio_pins)) {
> - dev_err(pc->dev, "%s: invalid brcm,pins value %d\n",
> - of_node_full_name(np), pin);
> + dev_err(pc->dev, "%pOF: invalid brcm,pins value %d\n",
> + np, pin);
>   err = -EINVAL;
>   goto out;
>   }
> diff --git a/drivers/pinctrl/devicetree.c b/drivers/pinctrl/devicetree.c
> index 0e5c9f14a706..0a20afc2210c 100644
> --- 

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

[Borislav Petkov]

On Tue, Jul 18, 2017 at 09:20:44PM +, Kani, Toshimitsu wrote:
> I agree that 'osc_sb_apei_support_acked' should be checked when
> enabling ghes_edac.  I do not know the details of existing issues, but
> it sounds unlikely that this will address all of them since bugs can be
> everywhere.

No, see below.

> For instance, ghes_edac relies on DMI/SMBIOS info, unlike
> other EDAC drivers, which can be buggy regardless of this _OSC info.

That's the problem with firmware. You can't really fix it and it is
buggy as hell.

> I agree that making ghes_edac as a normal module is a good thing, but I
> do not think it's going to solve this issue.

Of course it will - if the firmware says it wants to look at the errors
first, then it gets to do so. This is the whole handling of hardware
errors in the firmware deal. I admit, sometimes it makes sense because
the firmware has the most intimate knowledge of the platform and, in
a perfect world, we won't ever need to have platform-specific EDAC
drivers.

But, we don't live in a perfect world. And the vendor execution of the
whole firmware-error-handling deal is an abomination at best.

So, if we realize that the firmware is buggy, we can use a platform list
to blacklist it (^hint hint^) and have a parameter to disable ghes_edac
from loading.

But we'll deal with that when we get to cross that bridge. Right now,
I'd like to do the loading spec-conform and not fiddle with white-,
black-, or any-other-color lists.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

[Borislav Petkov]

On Tue, Jul 18, 2017 at 09:20:44PM +, Kani, Toshimitsu wrote:
> I agree that 'osc_sb_apei_support_acked' should be checked when
> enabling ghes_edac.  I do not know the details of existing issues, but
> it sounds unlikely that this will address all of them since bugs can be
> everywhere.

No, see below.

> For instance, ghes_edac relies on DMI/SMBIOS info, unlike
> other EDAC drivers, which can be buggy regardless of this _OSC info.

That's the problem with firmware. You can't really fix it and it is
buggy as hell.

> I agree that making ghes_edac as a normal module is a good thing, but I
> do not think it's going to solve this issue.

Of course it will - if the firmware says it wants to look at the errors
first, then it gets to do so. This is the whole handling of hardware
errors in the firmware deal. I admit, sometimes it makes sense because
the firmware has the most intimate knowledge of the platform and, in
a perfect world, we won't ever need to have platform-specific EDAC
drivers.

But, we don't live in a perfect world. And the vendor execution of the
whole firmware-error-handling deal is an abomination at best.

So, if we realize that the firmware is buggy, we can use a platform list
to blacklist it (^hint hint^) and have a parameter to disable ghes_edac
from loading.

But we'll deal with that when we get to cross that bridge. Right now,
I'd like to do the loading spec-conform and not fiddle with white-,
black-, or any-other-color lists.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [PATCH] ARM: Convert to using %pOF instead of full_name

[Krzysztof Kozlowski]

On Tue, Jul 18, 2017 at 04:42:41PM -0500, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
> 
> Signed-off-by: Rob Herring 
> Cc: Russell King 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: Javier Martinez Canillas 
> Cc: Shawn Guo 
> Cc: Sascha Hauer 
> Cc: Fabio Estevam 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Gregory Clement 
> Cc: Sebastian Hesselbarth 
> Cc: Tony Lindgren 
> Cc: "Benoît Cousson" 
> Cc: Paul Walmsley 
> Cc: Heiko Stuebner 
> Cc: Simon Horman 
> Cc: Magnus Damm 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-o...@vger.kernel.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: linux-renesas-...@vger.kernel.org
> ---
>  arch/arm/kernel/cpuidle.c| 4 ++--
>  arch/arm/kernel/devtree.c| 6 +++---
>  arch/arm/kernel/topology.c   | 4 ++--
>  arch/arm/mach-exynos/suspend.c   | 8 
>  arch/arm/mach-imx/gpc.c  | 4 ++--
>  arch/arm/mach-mvebu/kirkwood.c   | 4 ++--
>  arch/arm/mach-omap2/omap-wakeupgen.c | 4 ++--
>  arch/arm/mach-omap2/omap_hwmod.c | 4 ++--
>  arch/arm/mach-rockchip/platsmp.c | 4 ++--
>  arch/arm/mach-shmobile/pm-rmobile.c  | 8 
>  10 files changed, 25 insertions(+), 25 deletions(-)
> 
> diff --git a/arch/arm/kernel/cpuidle.c b/arch/arm/kernel/cpuidle.c
> index a3308ad1a024..fda5579123a8 100644
> --- a/arch/arm/kernel/cpuidle.c
> +++ b/arch/arm/kernel/cpuidle.c
> @@ -101,8 +101,8 @@ static int __init arm_cpuidle_read_ops(struct device_node 
> *dn, int cpu)
> 
>   ops = arm_cpuidle_get_ops(enable_method);
>   if (!ops) {
> - pr_warn("%s: unsupported enable-method property: %s\n",
> - dn->full_name, enable_method);
> + pr_warn("%pOF: unsupported enable-method property: %s\n",
> + dn, enable_method);
>   return -EOPNOTSUPP;
>   }
> 
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index f676febbb270..28174c9a94ac 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -95,7 +95,7 @@ void __init arm_dt_init_cpu_maps(void)
>   if (of_node_cmp(cpu->type, "cpu"))
>   continue;
> 
> - pr_debug(" * %s...\n", cpu->full_name);
> + pr_debug(" * %pOF...\n", cpu);
>   /*
>* A device tree containing CPU nodes with missing "reg"
>* properties is considered invalid to build the
> @@ -103,8 +103,8 @@ void __init arm_dt_init_cpu_maps(void)
>*/
>   cell = of_get_property(cpu, "reg", _bytes);
>   if (!cell || prop_bytes < sizeof(*cell)) {
> - pr_debug(" * %s missing reg property\n",
> -  cpu->full_name);
> + pr_debug(" * %pOF missing reg property\n",
> +  cpu);
>   of_node_put(cpu);
>   return;
>   }
> diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
> index bf949a763dbe..e596c5b8f931 100644
> --- a/arch/arm/kernel/topology.c
> +++ b/arch/arm/kernel/topology.c
> @@ -127,8 +127,8 @@ static void __init parse_dt_topology(void)
> 
>   rate = of_get_property(cn, "clock-frequency", );
>   if (!rate || len != 4) {
> - pr_err("%s missing clock-frequency property\n",
> - cn->full_name);
> + pr_err("%pOF missing clock-frequency property\n",
> + cn);
>   continue;
>   }
> 
> diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
> index 748cfb8d5212..3c7b66c22697 100644
> --- a/arch/arm/mach-exynos/suspend.c
> +++ b/arch/arm/mach-exynos/suspend.c
> @@ -187,21 +187,21 @@ static int __init exynos_pmu_irq_init(struct 
> device_node *node,
>   struct irq_domain *parent_domain, *domain;
> 
>   if (!parent) {
> - pr_err("%s: no parent, giving up\n", node->full_name);
> + pr_err("%pOF: no parent, giving up\n", node);
>   return -ENODEV;
>   }
> 
>   parent_domain = irq_find_host(parent);
>   if (!parent_domain) {
> - pr_err("%s: unable to obtain parent domain\n", node->full_name);
> + pr_err("%pOF: unable to obtain parent domain\n", node);
>   return -ENXIO;

Re: [PATCH] ARM: Convert to using %pOF instead of full_name

[Krzysztof Kozlowski]

On Tue, Jul 18, 2017 at 04:42:41PM -0500, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
> 
> Signed-off-by: Rob Herring 
> Cc: Russell King 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: Javier Martinez Canillas 
> Cc: Shawn Guo 
> Cc: Sascha Hauer 
> Cc: Fabio Estevam 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Gregory Clement 
> Cc: Sebastian Hesselbarth 
> Cc: Tony Lindgren 
> Cc: "Benoît Cousson" 
> Cc: Paul Walmsley 
> Cc: Heiko Stuebner 
> Cc: Simon Horman 
> Cc: Magnus Damm 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-o...@vger.kernel.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: linux-renesas-...@vger.kernel.org
> ---
>  arch/arm/kernel/cpuidle.c| 4 ++--
>  arch/arm/kernel/devtree.c| 6 +++---
>  arch/arm/kernel/topology.c   | 4 ++--
>  arch/arm/mach-exynos/suspend.c   | 8 
>  arch/arm/mach-imx/gpc.c  | 4 ++--
>  arch/arm/mach-mvebu/kirkwood.c   | 4 ++--
>  arch/arm/mach-omap2/omap-wakeupgen.c | 4 ++--
>  arch/arm/mach-omap2/omap_hwmod.c | 4 ++--
>  arch/arm/mach-rockchip/platsmp.c | 4 ++--
>  arch/arm/mach-shmobile/pm-rmobile.c  | 8 
>  10 files changed, 25 insertions(+), 25 deletions(-)
> 
> diff --git a/arch/arm/kernel/cpuidle.c b/arch/arm/kernel/cpuidle.c
> index a3308ad1a024..fda5579123a8 100644
> --- a/arch/arm/kernel/cpuidle.c
> +++ b/arch/arm/kernel/cpuidle.c
> @@ -101,8 +101,8 @@ static int __init arm_cpuidle_read_ops(struct device_node 
> *dn, int cpu)
> 
>   ops = arm_cpuidle_get_ops(enable_method);
>   if (!ops) {
> - pr_warn("%s: unsupported enable-method property: %s\n",
> - dn->full_name, enable_method);
> + pr_warn("%pOF: unsupported enable-method property: %s\n",
> + dn, enable_method);
>   return -EOPNOTSUPP;
>   }
> 
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index f676febbb270..28174c9a94ac 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -95,7 +95,7 @@ void __init arm_dt_init_cpu_maps(void)
>   if (of_node_cmp(cpu->type, "cpu"))
>   continue;
> 
> - pr_debug(" * %s...\n", cpu->full_name);
> + pr_debug(" * %pOF...\n", cpu);
>   /*
>* A device tree containing CPU nodes with missing "reg"
>* properties is considered invalid to build the
> @@ -103,8 +103,8 @@ void __init arm_dt_init_cpu_maps(void)
>*/
>   cell = of_get_property(cpu, "reg", _bytes);
>   if (!cell || prop_bytes < sizeof(*cell)) {
> - pr_debug(" * %s missing reg property\n",
> -  cpu->full_name);
> + pr_debug(" * %pOF missing reg property\n",
> +  cpu);
>   of_node_put(cpu);
>   return;
>   }
> diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
> index bf949a763dbe..e596c5b8f931 100644
> --- a/arch/arm/kernel/topology.c
> +++ b/arch/arm/kernel/topology.c
> @@ -127,8 +127,8 @@ static void __init parse_dt_topology(void)
> 
>   rate = of_get_property(cn, "clock-frequency", );
>   if (!rate || len != 4) {
> - pr_err("%s missing clock-frequency property\n",
> - cn->full_name);
> + pr_err("%pOF missing clock-frequency property\n",
> + cn);
>   continue;
>   }
> 
> diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
> index 748cfb8d5212..3c7b66c22697 100644
> --- a/arch/arm/mach-exynos/suspend.c
> +++ b/arch/arm/mach-exynos/suspend.c
> @@ -187,21 +187,21 @@ static int __init exynos_pmu_irq_init(struct 
> device_node *node,
>   struct irq_domain *parent_domain, *domain;
> 
>   if (!parent) {
> - pr_err("%s: no parent, giving up\n", node->full_name);
> + pr_err("%pOF: no parent, giving up\n", node);
>   return -ENODEV;
>   }
> 
>   parent_domain = irq_find_host(parent);
>   if (!parent_domain) {
> - pr_err("%s: unable to obtain parent domain\n", node->full_name);
> + pr_err("%pOF: unable to obtain parent domain\n", node);
>   return -ENXIO;
>   }
> 
>   pmu_base_addr = of_iomap(node, 0);
> 
>   if (!pmu_base_addr) {
> - pr_err("%s: failed to find exynos pmu register\n",
> -node->full_name);
> + pr_err("%pOF: failed to find exynos pmu register\n",
> +node);

This could be one line now. Can you merge it?

Beside that, for Exynos:
Acked-by: Krzysztof 

Re: [PATCH v5 4/4]: perf/core: complete replace of lists by rb trees for pinned and flexible groups at perf_event_context

[Alexander Shishkin]

Alexey Budankov  writes:

> On 18.07.2017 19:55, Alexander Shishkin wrote:
>> Alexey Budankov  writes:
>> 
>>> I see. Do you personally have some more issues that needs to be addressed?
>>> My intention is that this patch v5 4/4 addresses all your comments raised 
>>> in 
>>> the previous reviews.
>> 
>> I don't know yet, I haven't started on the actual content of the
>> patchset, it being hard to read. I'm going to wait for more readable
>> versions to look at the actual code.
>
> Is the whole final change attached to this patch v5 4/4 sufficient for you to 
> proceed?

No. As I've said yesterday here [1] and here [2], patches have to make
sense on their own. I'm sure 'submitting-patches' also has something to
that effect.

> If not - please suggest the form which is more convenient for you.

I've also answered this already in [3]:

> Well, normally you'd be sending new versions of your patchset until the
> maintainers are happy with it, at which point they'd pick it up. New
> versions would address the issues pointed out during the review, also
> keeping in mind the what 'submitting-patches' says about submitting
> patches.

[1] http://marc.info/?l=linux-kernel=150038199212005
[2] http://marc.info/?l=linux-kernel=150039142715304
[3] http://marc.info/?l=linux-kernel=150039054614993

Regards,
--
Alex

Re: [PATCH v5 4/4]: perf/core: complete replace of lists by rb trees for pinned and flexible groups at perf_event_context

[Alexander Shishkin]

Alexey Budankov  writes:

> On 18.07.2017 19:55, Alexander Shishkin wrote:
>> Alexey Budankov  writes:
>> 
>>> I see. Do you personally have some more issues that needs to be addressed?
>>> My intention is that this patch v5 4/4 addresses all your comments raised 
>>> in 
>>> the previous reviews.
>> 
>> I don't know yet, I haven't started on the actual content of the
>> patchset, it being hard to read. I'm going to wait for more readable
>> versions to look at the actual code.
>
> Is the whole final change attached to this patch v5 4/4 sufficient for you to 
> proceed?

No. As I've said yesterday here [1] and here [2], patches have to make
sense on their own. I'm sure 'submitting-patches' also has something to
that effect.

> If not - please suggest the form which is more convenient for you.

I've also answered this already in [3]:

> Well, normally you'd be sending new versions of your patchset until the
> maintainers are happy with it, at which point they'd pick it up. New
> versions would address the issues pointed out during the review, also
> keeping in mind the what 'submitting-patches' says about submitting
> patches.

[1] http://marc.info/?l=linux-kernel=150038199212005
[2] http://marc.info/?l=linux-kernel=150039142715304
[3] http://marc.info/?l=linux-kernel=150039054614993

Regards,
--
Alex

Re: [PATCH] memory: Convert to using %pOF instead of full_name

[Alexandre Belloni]

On 18/07/2017 at 16:43:14 -0500, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
> 
> Signed-off-by: Rob Herring 
> Cc: Nicolas Ferre 
> Cc: Alexandre Belloni 
> Cc: Roger Quadros 
> Cc: Tony Lindgren 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-o...@vger.kernel.org
Acked-by: Alexandre Belloni 

> ---
>  drivers/memory/atmel-ebi.c| 17 -
>  drivers/memory/jz4780-nemc.c  | 12 ++--
>  drivers/memory/mvebu-devbus.c | 12 ++--
>  drivers/memory/omap-gpmc.c| 18 +-
>  4 files changed, 29 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/memory/atmel-ebi.c b/drivers/memory/atmel-ebi.c
> index 99e644cda4d1..597282e35c69 100644
> --- a/drivers/memory/atmel-ebi.c
> +++ b/drivers/memory/atmel-ebi.c
> @@ -156,8 +156,8 @@ static int atmel_ebi_xslate_smc_timings(struct 
> atmel_ebi_dev *ebid,
>  out:
>   if (ret) {
>   dev_err(ebid->ebi->dev,
> - "missing or invalid timings definition in %s",
> - np->full_name);
> + "missing or invalid timings definition in %pOF",
> + np);
>   return ret;
>   }
> 
> @@ -267,8 +267,8 @@ static int atmel_ebi_xslate_smc_config(struct 
> atmel_ebi_dev *ebid,
>   return -EINVAL;
> 
>   if ((ret > 0 && !required) || (!ret && required)) {
> - dev_err(ebid->ebi->dev, "missing atmel,smc- properties in %s",
> - np->full_name);
> + dev_err(ebid->ebi->dev, "missing atmel,smc- properties in %pOF",
> + np);
>   return -EINVAL;
>   }
> 
> @@ -311,8 +311,7 @@ static int atmel_ebi_dev_setup(struct atmel_ebi *ebi, 
> struct device_node *np,
> 
>   if (cs >= AT91_MATRIX_EBI_NUM_CS ||
>   !(ebi->caps->available_cs & BIT(cs))) {
> - dev_err(dev, "invalid reg property in %s\n",
> - np->full_name);
> + dev_err(dev, "invalid reg property in %pOF\n", np);
>   return -EINVAL;
>   }
> 
> @@ -321,7 +320,7 @@ static int atmel_ebi_dev_setup(struct atmel_ebi *ebi, 
> struct device_node *np,
>   }
> 
>   if (!numcs) {
> - dev_err(dev, "invalid reg property in %s\n", np->full_name);
> + dev_err(dev, "invalid reg property in %pOF\n", np);
>   return -EINVAL;
>   }
> 
> @@ -569,8 +568,8 @@ static int atmel_ebi_probe(struct platform_device *pdev)
> 
>   ret = atmel_ebi_dev_setup(ebi, child, reg_cells);
>   if (ret) {
> - dev_err(dev, "failed to configure EBI bus for %s, 
> disabling the device",
> - child->full_name);
> + dev_err(dev, "failed to configure EBI bus for %pOF, 
> disabling the device",
> + child);
> 
>   ret = atmel_ebi_dev_disable(ebi, child);
>   if (ret)
> diff --git a/drivers/memory/jz4780-nemc.c b/drivers/memory/jz4780-nemc.c
> index 919d1925acb9..bcf06adefc96 100644
> --- a/drivers/memory/jz4780-nemc.c
> +++ b/drivers/memory/jz4780-nemc.c
> @@ -322,8 +322,8 @@ static int jz4780_nemc_probe(struct platform_device *pdev)
>   bank = of_read_number(prop, 1);
>   if (bank < 1 || bank >= JZ4780_NEMC_NUM_BANKS) {
>   dev_err(nemc->dev,
> - "%s requests invalid bank %u\n",
> - child->full_name, bank);
> + "%pOF requests invalid bank %u\n",
> + child, bank);
> 
>   /* Will continue the outer loop below. */
>   referenced = 0;
> @@ -334,12 +334,12 @@ static int jz4780_nemc_probe(struct platform_device 
> *pdev)
>   }
> 
>   if (!referenced) {
> - dev_err(nemc->dev, "%s has no addresses\n",
> - child->full_name);
> + dev_err(nemc->dev, "%pOF has no addresses\n",
> + child);
>   continue;
>   } else if (nemc->banks_present & referenced) {
> - dev_err(nemc->dev, "%s conflicts with another node\n",
> - child->full_name);
> + dev_err(nemc->dev, "%pOF conflicts with another node\n",
> + child);
>   continue;
>   }
> 
> diff --git a/drivers/memory/mvebu-devbus.c 

Re: [PATCH] memory: Convert to using %pOF instead of full_name

[Alexandre Belloni]

On 18/07/2017 at 16:43:14 -0500, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
> 
> Signed-off-by: Rob Herring 
> Cc: Nicolas Ferre 
> Cc: Alexandre Belloni 
> Cc: Roger Quadros 
> Cc: Tony Lindgren 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-o...@vger.kernel.org
Acked-by: Alexandre Belloni 

> ---
>  drivers/memory/atmel-ebi.c| 17 -
>  drivers/memory/jz4780-nemc.c  | 12 ++--
>  drivers/memory/mvebu-devbus.c | 12 ++--
>  drivers/memory/omap-gpmc.c| 18 +-
>  4 files changed, 29 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/memory/atmel-ebi.c b/drivers/memory/atmel-ebi.c
> index 99e644cda4d1..597282e35c69 100644
> --- a/drivers/memory/atmel-ebi.c
> +++ b/drivers/memory/atmel-ebi.c
> @@ -156,8 +156,8 @@ static int atmel_ebi_xslate_smc_timings(struct 
> atmel_ebi_dev *ebid,
>  out:
>   if (ret) {
>   dev_err(ebid->ebi->dev,
> - "missing or invalid timings definition in %s",
> - np->full_name);
> + "missing or invalid timings definition in %pOF",
> + np);
>   return ret;
>   }
> 
> @@ -267,8 +267,8 @@ static int atmel_ebi_xslate_smc_config(struct 
> atmel_ebi_dev *ebid,
>   return -EINVAL;
> 
>   if ((ret > 0 && !required) || (!ret && required)) {
> - dev_err(ebid->ebi->dev, "missing atmel,smc- properties in %s",
> - np->full_name);
> + dev_err(ebid->ebi->dev, "missing atmel,smc- properties in %pOF",
> + np);
>   return -EINVAL;
>   }
> 
> @@ -311,8 +311,7 @@ static int atmel_ebi_dev_setup(struct atmel_ebi *ebi, 
> struct device_node *np,
> 
>   if (cs >= AT91_MATRIX_EBI_NUM_CS ||
>   !(ebi->caps->available_cs & BIT(cs))) {
> - dev_err(dev, "invalid reg property in %s\n",
> - np->full_name);
> + dev_err(dev, "invalid reg property in %pOF\n", np);
>   return -EINVAL;
>   }
> 
> @@ -321,7 +320,7 @@ static int atmel_ebi_dev_setup(struct atmel_ebi *ebi, 
> struct device_node *np,
>   }
> 
>   if (!numcs) {
> - dev_err(dev, "invalid reg property in %s\n", np->full_name);
> + dev_err(dev, "invalid reg property in %pOF\n", np);
>   return -EINVAL;
>   }
> 
> @@ -569,8 +568,8 @@ static int atmel_ebi_probe(struct platform_device *pdev)
> 
>   ret = atmel_ebi_dev_setup(ebi, child, reg_cells);
>   if (ret) {
> - dev_err(dev, "failed to configure EBI bus for %s, 
> disabling the device",
> - child->full_name);
> + dev_err(dev, "failed to configure EBI bus for %pOF, 
> disabling the device",
> + child);
> 
>   ret = atmel_ebi_dev_disable(ebi, child);
>   if (ret)
> diff --git a/drivers/memory/jz4780-nemc.c b/drivers/memory/jz4780-nemc.c
> index 919d1925acb9..bcf06adefc96 100644
> --- a/drivers/memory/jz4780-nemc.c
> +++ b/drivers/memory/jz4780-nemc.c
> @@ -322,8 +322,8 @@ static int jz4780_nemc_probe(struct platform_device *pdev)
>   bank = of_read_number(prop, 1);
>   if (bank < 1 || bank >= JZ4780_NEMC_NUM_BANKS) {
>   dev_err(nemc->dev,
> - "%s requests invalid bank %u\n",
> - child->full_name, bank);
> + "%pOF requests invalid bank %u\n",
> + child, bank);
> 
>   /* Will continue the outer loop below. */
>   referenced = 0;
> @@ -334,12 +334,12 @@ static int jz4780_nemc_probe(struct platform_device 
> *pdev)
>   }
> 
>   if (!referenced) {
> - dev_err(nemc->dev, "%s has no addresses\n",
> - child->full_name);
> + dev_err(nemc->dev, "%pOF has no addresses\n",
> + child);
>   continue;
>   } else if (nemc->banks_present & referenced) {
> - dev_err(nemc->dev, "%s conflicts with another node\n",
> - child->full_name);
> + dev_err(nemc->dev, "%pOF conflicts with another node\n",
> + child);
>   continue;
>   }
> 
> diff --git a/drivers/memory/mvebu-devbus.c b/drivers/memory/mvebu-devbus.c
> index 24852812fd44..981860879d02 100644
> --- a/drivers/memory/mvebu-devbus.c
> +++ b/drivers/memory/mvebu-devbus.c
> @@ -105,8 +105,8 

Re: [PATCH] EDAC: Convert to using %pOF instead of full_name

[Borislav Petkov]

On Tue, Jul 18, 2017 at 04:42:59PM -0500, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
> 
> Signed-off-by: Rob Herring 
> Cc: Borislav Petkov 
> Cc: Mauro Carvalho Chehab 
> Cc: linux-e...@vger.kernel.org
> ---
>  drivers/edac/cpc925_edac.c | 2 +-
>  drivers/edac/ppc4xx_edac.c | 8 
>  2 files changed, 5 insertions(+), 5 deletions(-)

Applied, thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [PATCH] EDAC: Convert to using %pOF instead of full_name

[Borislav Petkov]

On Tue, Jul 18, 2017 at 04:42:59PM -0500, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
> 
> Signed-off-by: Rob Herring 
> Cc: Borislav Petkov 
> Cc: Mauro Carvalho Chehab 
> Cc: linux-e...@vger.kernel.org
> ---
>  drivers/edac/cpc925_edac.c | 2 +-
>  drivers/edac/ppc4xx_edac.c | 8 
>  2 files changed, 5 insertions(+), 5 deletions(-)

Applied, thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

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

[Li, Aubrey]

On 2017/7/18 23:20, Paul E. McKenney wrote:

>> 2) for rcu idle enter/exit, I measured the details which Paul provided, and
>> the result matches with what I have measured before, nothing notable found.
>> But it still makes more sense if we can make rcu idle enter/exit hooked with
>> tick off. (it's possible other workloads behave differently)
> 
> Again, assuming that RCU is informed of CPUs in the kernel, regardless
> of whether or not the tick is on that that point in time.
> 
Yeah, I see, no problem for a normal idle.

But for a short idle, we want to return to the task ASAP. Even though RCU cost
is not notable, it would still be better for me if we can save some cycles in
idle entry and idle exit.

Do we have any problem if we skip RCU idle enter/exit under a fast idle 
scenario?
My understanding is, if tick is not stopped, then we don't need inform RCU in
idle path, it can be informed in irq exit.

Thanks,
-Aubrey

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

[Li, Aubrey]

On 2017/7/18 23:20, Paul E. McKenney wrote:

>> 2) for rcu idle enter/exit, I measured the details which Paul provided, and
>> the result matches with what I have measured before, nothing notable found.
>> But it still makes more sense if we can make rcu idle enter/exit hooked with
>> tick off. (it's possible other workloads behave differently)
> 
> Again, assuming that RCU is informed of CPUs in the kernel, regardless
> of whether or not the tick is on that that point in time.
> 
Yeah, I see, no problem for a normal idle.

But for a short idle, we want to return to the task ASAP. Even though RCU cost
is not notable, it would still be better for me if we can save some cycles in
idle entry and idle exit.

Do we have any problem if we skip RCU idle enter/exit under a fast idle 
scenario?
My understanding is, if tick is not stopped, then we don't need inform RCU in
idle path, it can be informed in irq exit.

Thanks,
-Aubrey

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

[Viresh Kumar]

On 18-07-17, 15:02, Juri Lelli wrote:
> Mmm, seems to make sense to me. :/
> 
> Would the following work (on top of Joel's v5)? Rationale being that
> only in sugov_set_iowait_boost we might bump freq up (if no iowait_boost
> was set) or start from policy->min. In sugov_iowait_boost (consumer)
> instead we do the decay (if no boosting was pending).
> 
> ---
>  kernel/sched/cpufreq_schedutil.c | 29 +++--
>  1 file changed, 19 insertions(+), 10 deletions(-)
> 
> diff --git a/kernel/sched/cpufreq_schedutil.c 
> b/kernel/sched/cpufreq_schedutil.c
> index 46b2479641cc..b270563c15a5 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -171,8 +171,14 @@ static void sugov_set_iowait_boost(struct sugov_cpu 
> *sg_cpu, u64 time,
>  {
>   if (flags & SCHED_CPUFREQ_IOWAIT) {
>   sg_cpu->iowait_boost_pending = true;
> - sg_cpu->iowait_boost = max(sg_cpu->iowait_boost,
> -sg_cpu->sg_policy->policy->min);
> + if (sg_cpu->iowait_boost) {
> + /* Bump up 2*current_boost until hitting max */
> + sg_cpu->iowait_boost = max(sg_cpu->iowait_boost << 1,
> +sg_cpu->iowait_boost_max);

And we are back at where we started :)

This wouldn't work because sugov_set_iowait_boost() gets called a lot.
Maybe 10 times within a rate_limit_us period.

The thumb rule is, never double/half the boost from
sugov_set_iowait_boost() :)

-- 
viresh

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

[Viresh Kumar]

On 18-07-17, 15:02, Juri Lelli wrote:
> Mmm, seems to make sense to me. :/
> 
> Would the following work (on top of Joel's v5)? Rationale being that
> only in sugov_set_iowait_boost we might bump freq up (if no iowait_boost
> was set) or start from policy->min. In sugov_iowait_boost (consumer)
> instead we do the decay (if no boosting was pending).
> 
> ---
>  kernel/sched/cpufreq_schedutil.c | 29 +++--
>  1 file changed, 19 insertions(+), 10 deletions(-)
> 
> diff --git a/kernel/sched/cpufreq_schedutil.c 
> b/kernel/sched/cpufreq_schedutil.c
> index 46b2479641cc..b270563c15a5 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -171,8 +171,14 @@ static void sugov_set_iowait_boost(struct sugov_cpu 
> *sg_cpu, u64 time,
>  {
>   if (flags & SCHED_CPUFREQ_IOWAIT) {
>   sg_cpu->iowait_boost_pending = true;
> - sg_cpu->iowait_boost = max(sg_cpu->iowait_boost,
> -sg_cpu->sg_policy->policy->min);
> + if (sg_cpu->iowait_boost) {
> + /* Bump up 2*current_boost until hitting max */
> + sg_cpu->iowait_boost = max(sg_cpu->iowait_boost << 1,
> +sg_cpu->iowait_boost_max);

And we are back at where we started :)

This wouldn't work because sugov_set_iowait_boost() gets called a lot.
Maybe 10 times within a rate_limit_us period.

The thumb rule is, never double/half the boost from
sugov_set_iowait_boost() :)

-- 
viresh

Re: [PATCH] pci: quirk: Apply APM ACS quirk to XGene devices

[Feng Kan]

>
> I don't know what that means, does the hardware support an equivalent
> to source validation or not?

Yes, source validation is done through the smmu.

  What's the response of the root port if
> the downstream device issues a transaction spoofing devices not within
> the bus number ranges of the bridge?
HW guys informs me there is way to disable transactions between root port.
I will confirm later.

>
>> Alex, the goal here is to enable virtualization to work correctly.
>> Please let me know if the
>> above is sufficient. Much thanks.
>
> Of course, but that means that the hardware vendor is vouching that
> this device provides the equivalent isolation for each of the missing
> components of ACS.  Claiming to have isolation capabilities that don't
> exist would be irresponsible and put users of that hardware at risk.
Agreed, I believe we do have isolation in our case based on the conference
we had today.

> Thanks,
>
> Alex

Re: [PATCH] pci: quirk: Apply APM ACS quirk to XGene devices

[Feng Kan]

>
> I don't know what that means, does the hardware support an equivalent
> to source validation or not?

Yes, source validation is done through the smmu.

  What's the response of the root port if
> the downstream device issues a transaction spoofing devices not within
> the bus number ranges of the bridge?
HW guys informs me there is way to disable transactions between root port.
I will confirm later.

>
>> Alex, the goal here is to enable virtualization to work correctly.
>> Please let me know if the
>> above is sufficient. Much thanks.
>
> Of course, but that means that the hardware vendor is vouching that
> this device provides the equivalent isolation for each of the missing
> components of ACS.  Claiming to have isolation capabilities that don't
> exist would be irresponsible and put users of that hardware at risk.
Agreed, I believe we do have isolation in our case based on the conference
we had today.

> Thanks,
>
> Alex

Re: [PATCH] x86/microcode/AMD: fix memleak in update_cache()

[Borislav Petkov]

On Wed, Jul 19, 2017 at 12:21:23PM +0800, shuw...@redhat.com wrote:
> From: Shu Wang 
> 
> Found this issue by kmemleak. The mem is allocated in
> verify_and_add_patch(), passed to update_cache(patch),
> and just dropped the reference without free
> if (p->patch_id >= new_patch->patch_id)
> return;
> 
> unreferenced object 0x88010e780b40 (size 32):
>   comm "bash", pid 860, jiffies 4294690939 (age 29.297s)
>   backtrace:
> [] kmemleak_alloc+0x4a/0xa0
> [] kmem_cache_alloc_trace+0xca/0x1d0
> [] load_microcode_amd.isra.0+0x1d0/0x400
> [] request_microcode_amd+0xc3/0x160
> [] reload_store+0xe1/0x170
> [] dev_attr_store+0x18/0x30
> [] sysfs_kf_write+0x3a/0x50
> [] kernfs_fop_write+0xff/0x180
> [] __vfs_write+0x37/0x170
> [] vfs_write+0xb2/0x1b0
> [] SyS_write+0x55/0xc0
> [] do_syscall_64+0x67/0x150
> [] return_from_SYSCALL_64+0x0/0x6a
> [] 0x
> 
> (gdb) list *0x81050d60
> 0x81050d60 is in load_microcode_amd
>   (arch/x86/kernel/cpu/microcode/amd.c:616).
> 
> Signed-off-by: Shu Wang 
> ---
>  arch/x86/kernel/cpu/microcode/amd.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

Applied, thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [PATCH] x86/microcode/AMD: fix memleak in update_cache()

[Borislav Petkov]

On Wed, Jul 19, 2017 at 12:21:23PM +0800, shuw...@redhat.com wrote:
> From: Shu Wang 
> 
> Found this issue by kmemleak. The mem is allocated in
> verify_and_add_patch(), passed to update_cache(patch),
> and just dropped the reference without free
> if (p->patch_id >= new_patch->patch_id)
> return;
> 
> unreferenced object 0x88010e780b40 (size 32):
>   comm "bash", pid 860, jiffies 4294690939 (age 29.297s)
>   backtrace:
> [] kmemleak_alloc+0x4a/0xa0
> [] kmem_cache_alloc_trace+0xca/0x1d0
> [] load_microcode_amd.isra.0+0x1d0/0x400
> [] request_microcode_amd+0xc3/0x160
> [] reload_store+0xe1/0x170
> [] dev_attr_store+0x18/0x30
> [] sysfs_kf_write+0x3a/0x50
> [] kernfs_fop_write+0xff/0x180
> [] __vfs_write+0x37/0x170
> [] vfs_write+0xb2/0x1b0
> [] SyS_write+0x55/0xc0
> [] do_syscall_64+0x67/0x150
> [] return_from_SYSCALL_64+0x0/0x6a
> [] 0x
> 
> (gdb) list *0x81050d60
> 0x81050d60 is in load_microcode_amd
>   (arch/x86/kernel/cpu/microcode/amd.c:616).
> 
> Signed-off-by: Shu Wang 
> ---
>  arch/x86/kernel/cpu/microcode/amd.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

Applied, thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [PATCH] KVM: VMX: Fix invalid guest state detection after task-switch emulation

[Wanpeng Li]

Ping, :)
2017-07-11 15:13 GMT+08:00 Wanpeng Li :
> From: Wanpeng Li 
>
> This can be reproduced by EPT=1, unrestricted_guest=N, emulate_invalid_state=Y
> or EPT=0, the trace of kvm-unit-tests/taskswitch2.flat is like below, it tries
> to emulate invalid guest state task-switch:
>
> kvm_exit: reason TASK_SWITCH rip 0x0 info 4058 0
> kvm_emulate_insn: 42000:0:0f 0b (0x2)
> kvm_emulate_insn: 42000:0:0f 0b (0x2) failed
> kvm_inj_exception: #UD (0x0)
> kvm_entry: vcpu 0
> kvm_exit: reason TASK_SWITCH rip 0x0 info 4058 0
> kvm_emulate_insn: 42000:0:0f 0b (0x2)
> kvm_emulate_insn: 42000:0:0f 0b (0x2) failed
> kvm_inj_exception: #UD (0x0)
> ..
>
> It appears that the task-switch emulation updates rflags (and vm86
> flag) only after the segments are loaded, causing vmx->emulation_required
> to be set, when in fact invalid guest state emulation is not needed.
>
> This patch fixes it by updating vmx->emulation_required after the
> rflags (and vm86 flag) is updated in task-switch emulation.
>
> Suggested-by: Nadav Amit 
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Cc: Nadav Amit 
> Signed-off-by: Wanpeng Li 
> ---
>  arch/x86/kvm/vmx.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index f50cbfd..70270a2 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -6255,6 +6255,7 @@ static int handle_task_switch(struct kvm_vcpu *vcpu)
>  * TODO: What about debug traps on tss switch?
>  *   Are we supposed to inject them and update dr6?
>  */
> +   vmx->emulation_required = emulation_required(vcpu);
>
> return 1;
>  }
> --
> 2.7.4
>

Re: [PATCH] KVM: VMX: Fix invalid guest state detection after task-switch emulation

[Wanpeng Li]

Ping, :)
2017-07-11 15:13 GMT+08:00 Wanpeng Li :
> From: Wanpeng Li 
>
> This can be reproduced by EPT=1, unrestricted_guest=N, emulate_invalid_state=Y
> or EPT=0, the trace of kvm-unit-tests/taskswitch2.flat is like below, it tries
> to emulate invalid guest state task-switch:
>
> kvm_exit: reason TASK_SWITCH rip 0x0 info 4058 0
> kvm_emulate_insn: 42000:0:0f 0b (0x2)
> kvm_emulate_insn: 42000:0:0f 0b (0x2) failed
> kvm_inj_exception: #UD (0x0)
> kvm_entry: vcpu 0
> kvm_exit: reason TASK_SWITCH rip 0x0 info 4058 0
> kvm_emulate_insn: 42000:0:0f 0b (0x2)
> kvm_emulate_insn: 42000:0:0f 0b (0x2) failed
> kvm_inj_exception: #UD (0x0)
> ..
>
> It appears that the task-switch emulation updates rflags (and vm86
> flag) only after the segments are loaded, causing vmx->emulation_required
> to be set, when in fact invalid guest state emulation is not needed.
>
> This patch fixes it by updating vmx->emulation_required after the
> rflags (and vm86 flag) is updated in task-switch emulation.
>
> Suggested-by: Nadav Amit 
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Cc: Nadav Amit 
> Signed-off-by: Wanpeng Li 
> ---
>  arch/x86/kvm/vmx.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index f50cbfd..70270a2 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -6255,6 +6255,7 @@ static int handle_task_switch(struct kvm_vcpu *vcpu)
>  * TODO: What about debug traps on tss switch?
>  *   Are we supposed to inject them and update dr6?
>  */
> +   vmx->emulation_required = emulation_required(vcpu);
>
> return 1;
>  }
> --
> 2.7.4
>

[PATCH v2] gpio-exar: Use correct property prefix and document bindings

[Jan Kiszka]

The device-specific property should be prefixed with the vendor name,
not "linux,", as Linus Walleij pointed out. Change this and document the
bindings of this platform device.

We didn't ship the old binding in a release yet. So we can still change
it without breaking an official API.

Fixes: 380b1e2f3a2f ("gpio-exar/8250-exar: Make set of exported GPIOs 
configurable")

Signed-off-by: Jan Kiszka 
---
 Documentation/devicetree/bindings/gpio/gpio-exar.txt | 5 +
 drivers/gpio/gpio-exar.c | 2 +-
 drivers/tty/serial/8250/8250_exar.c  | 4 ++--
 3 files changed, 8 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-exar.txt

diff --git a/Documentation/devicetree/bindings/gpio/gpio-exar.txt 
b/Documentation/devicetree/bindings/gpio/gpio-exar.txt
new file mode 100644
index ..4540d61824af
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-exar.txt
@@ -0,0 +1,5 @@
+Exportable MPIO interface of Exar UART chips
+
+Required properties of the device:
+ - exar,first-pin: first exportable pins (0..15)
+ - ngpios: number of exportable pins (1..16)
diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
index fb8d304cfa17..0ecd2369c2ca 100644
--- a/drivers/gpio/gpio-exar.c
+++ b/drivers/gpio/gpio-exar.c
@@ -132,7 +132,7 @@ static int gpio_exar_probe(struct platform_device *pdev)
if (!p)
return -ENOMEM;
 
-   ret = device_property_read_u32(>dev, "linux,first-pin",
+   ret = device_property_read_u32(>dev, "exar,first-pin",
   _pin);
if (ret)
return ret;
diff --git a/drivers/tty/serial/8250/8250_exar.c 
b/drivers/tty/serial/8250/8250_exar.c
index b5c98e5bf524..c6360fbdf808 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -261,7 +261,7 @@ __xr17v35x_register_gpio(struct pci_dev *pcidev,
 }
 
 static const struct property_entry exar_gpio_properties[] = {
-   PROPERTY_ENTRY_U32("linux,first-pin", 0),
+   PROPERTY_ENTRY_U32("exar,first-pin", 0),
PROPERTY_ENTRY_U32("ngpios", 16),
{ }
 };
@@ -326,7 +326,7 @@ static int iot2040_rs485_config(struct uart_port *port,
 }
 
 static const struct property_entry iot2040_gpio_properties[] = {
-   PROPERTY_ENTRY_U32("linux,first-pin", 10),
+   PROPERTY_ENTRY_U32("exar,first-pin", 10),
PROPERTY_ENTRY_U32("ngpios", 1),
{ }
 };
-- 
2.12.3

[PATCH v2] gpio-exar: Use correct property prefix and document bindings

[Jan Kiszka]

The device-specific property should be prefixed with the vendor name,
not "linux,", as Linus Walleij pointed out. Change this and document the
bindings of this platform device.

We didn't ship the old binding in a release yet. So we can still change
it without breaking an official API.

Fixes: 380b1e2f3a2f ("gpio-exar/8250-exar: Make set of exported GPIOs 
configurable")

Signed-off-by: Jan Kiszka 
---
 Documentation/devicetree/bindings/gpio/gpio-exar.txt | 5 +
 drivers/gpio/gpio-exar.c | 2 +-
 drivers/tty/serial/8250/8250_exar.c  | 4 ++--
 3 files changed, 8 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-exar.txt

diff --git a/Documentation/devicetree/bindings/gpio/gpio-exar.txt 
b/Documentation/devicetree/bindings/gpio/gpio-exar.txt
new file mode 100644
index ..4540d61824af
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-exar.txt
@@ -0,0 +1,5 @@
+Exportable MPIO interface of Exar UART chips
+
+Required properties of the device:
+ - exar,first-pin: first exportable pins (0..15)
+ - ngpios: number of exportable pins (1..16)
diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
index fb8d304cfa17..0ecd2369c2ca 100644
--- a/drivers/gpio/gpio-exar.c
+++ b/drivers/gpio/gpio-exar.c
@@ -132,7 +132,7 @@ static int gpio_exar_probe(struct platform_device *pdev)
if (!p)
return -ENOMEM;
 
-   ret = device_property_read_u32(>dev, "linux,first-pin",
+   ret = device_property_read_u32(>dev, "exar,first-pin",
   _pin);
if (ret)
return ret;
diff --git a/drivers/tty/serial/8250/8250_exar.c 
b/drivers/tty/serial/8250/8250_exar.c
index b5c98e5bf524..c6360fbdf808 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -261,7 +261,7 @@ __xr17v35x_register_gpio(struct pci_dev *pcidev,
 }
 
 static const struct property_entry exar_gpio_properties[] = {
-   PROPERTY_ENTRY_U32("linux,first-pin", 0),
+   PROPERTY_ENTRY_U32("exar,first-pin", 0),
PROPERTY_ENTRY_U32("ngpios", 16),
{ }
 };
@@ -326,7 +326,7 @@ static int iot2040_rs485_config(struct uart_port *port,
 }
 
 static const struct property_entry iot2040_gpio_properties[] = {
-   PROPERTY_ENTRY_U32("linux,first-pin", 10),
+   PROPERTY_ENTRY_U32("exar,first-pin", 10),
PROPERTY_ENTRY_U32("ngpios", 1),
{ }
 };
-- 
2.12.3

[PATCH] omapfb: panel-sony-acx565akm: 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.

File size before:
   textdata bss dec hex filename
   5227 560   05787169b panel-sony-acx565akm

File size After adding 'const':
   textdata bss dec hex filename
   5291 496   05787169b panel-sony-acx565akm.o

Signed-off-by: Arvind Yadav 
---
 drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c 
b/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
index 468560a..f2c2fef 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
@@ -509,7 +509,7 @@ static DEVICE_ATTR(cabc_available_modes, S_IRUGO,
NULL,
 };
 
-static struct attribute_group bldev_attr_group = {
+static const struct attribute_group bldev_attr_group = {
.attrs = bldev_attrs,
 };
 
-- 
1.9.1

[PATCH] omapfb: panel-sony-acx565akm: 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.

File size before:
   textdata bss dec hex filename
   5227 560   05787169b panel-sony-acx565akm

File size After adding 'const':
   textdata bss dec hex filename
   5291 496   05787169b panel-sony-acx565akm.o

Signed-off-by: Arvind Yadav 
---
 drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c 
b/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
index 468560a..f2c2fef 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
@@ -509,7 +509,7 @@ static DEVICE_ATTR(cabc_available_modes, S_IRUGO,
NULL,
 };
 
-static struct attribute_group bldev_attr_group = {
+static const struct attribute_group bldev_attr_group = {
.attrs = bldev_attrs,
 };
 
-- 
1.9.1

Re: [PATCH v3 00/15] exec: Use sane stack rlimit under secureexec

[Kees Cook]

On Tue, Jul 18, 2017 at 8:22 PM, Serge E. Hallyn  wrote:
> On Tue, Jul 18, 2017 at 03:25:21PM -0700, Kees Cook wrote:
>> This series has grown... :P
>>
>> As discussed with Linus and Andy, we need to reset the stack rlimit
>> before we do memory layouts when execing a privilege-gaining (e.g.
>> setuid) program. To do this, we need to know the results of the
>> bprm_secureexec hook before memory layouts. As it turns out, this
>> can be made _mostly_ trivial by collapsing bprm_secureexec into
>> bprm_set_creds.
>>
>> The LSMs using bprm_secureexec nearly always save state between
>> bprm_set_creds and bprm_secureexec. In the face of multiple calls to
>> bprm_set_creds (via prepare_binprm() calls from binfmt_script, etc),
>> all LSMs except commoncap only pay attention to the first call, so
>> that aligns well with collapsing bprm_secureexec into bprm_set_creds.
>> The commoncaps, though, needs to check the _last_ bprm_set_creds, so
>> this series just swaps one bprm flag for another (cap_effective is no
>> longer needed to save state between bprm_set_creds and bprm_secureexec,
>> but we do need to keep a separate state, so we add the cap_elevated flag).
>>
>> Once secureexec is available to setup_new_exec() before the memory
>> layout, we can add an rlimit sanity-check for setuid execs. (With no
>> need to clean up since we're past the point of no return.)
>>
>> Along the way, this fixes comments, renames a variable, and consolidates
>> dumpability and pdeath_signal clearing, which includes some commit log
>> archeology to examine the subtle differences between what we had and
>> what we need.
>>
>> I'd appreciate some extra eyes on this to make sure this isn't broken
>> in some special way. Looking at the diffstat, even after all my long
>> comments, this is a net reduction in lines. :)
>>
>> Given this crosses a bunch of areas, I think this is likely best to
>> go via the -mm tree, which is where nearly all of my prior exec work
>> has lived too.
>>
>> Thanks!
>>
>> -Kees
>> 
>> Kees Cook (15):
>>   binfmt: Introduce secureexec flag
>>   exec: Rename bprm->cred_prepared to called_set_creds
>>   apparmor: Refactor to remove bprm_secureexec hook
>>   selinux: Refactor to remove bprm_secureexec hook
>>   smack: Refactor to remove bprm_secureexec hook
>>   commoncap: Refactor to remove bprm_secureexec hook
>>   commoncap: Move cap_elevated calculation into bprm_set_creds
>>   LSM: drop bprm_secureexec hook
>>   exec: Correct comments about "point of no return"
>>   exec: Use secureexec for setting dumpability
>>   exec: Use secureexec for clearing pdeath_signal
>>   smack: Remove redundant pdeath_signal clearing
>>   exec: Consolidate dumpability logic
>>   exec: Use sane stack rlimit under secureexec
>>   exec: Consolidate pdeath_signal clearing
>
> Thanks, the set looks good to me,

Thanks!

> Acked-by: Serge Hallyn 
>
> Have you had a chance to run the ltp caps tests against this?

The LTP caps tests I could find are these:

sudo ./runltp -f syscalls -s cap
sudo ./runltp -f securebits
sudo ./runltp -f cap_bounds
sudo ./runltp -f filecaps

They all run successfully. Was there other stuff from LTP?

And, FWIW, the kernel selftests for capabilities and exec continue to pass too.

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH v3 00/15] exec: Use sane stack rlimit under secureexec

[Kees Cook]

On Tue, Jul 18, 2017 at 8:22 PM, Serge E. Hallyn  wrote:
> On Tue, Jul 18, 2017 at 03:25:21PM -0700, Kees Cook wrote:
>> This series has grown... :P
>>
>> As discussed with Linus and Andy, we need to reset the stack rlimit
>> before we do memory layouts when execing a privilege-gaining (e.g.
>> setuid) program. To do this, we need to know the results of the
>> bprm_secureexec hook before memory layouts. As it turns out, this
>> can be made _mostly_ trivial by collapsing bprm_secureexec into
>> bprm_set_creds.
>>
>> The LSMs using bprm_secureexec nearly always save state between
>> bprm_set_creds and bprm_secureexec. In the face of multiple calls to
>> bprm_set_creds (via prepare_binprm() calls from binfmt_script, etc),
>> all LSMs except commoncap only pay attention to the first call, so
>> that aligns well with collapsing bprm_secureexec into bprm_set_creds.
>> The commoncaps, though, needs to check the _last_ bprm_set_creds, so
>> this series just swaps one bprm flag for another (cap_effective is no
>> longer needed to save state between bprm_set_creds and bprm_secureexec,
>> but we do need to keep a separate state, so we add the cap_elevated flag).
>>
>> Once secureexec is available to setup_new_exec() before the memory
>> layout, we can add an rlimit sanity-check for setuid execs. (With no
>> need to clean up since we're past the point of no return.)
>>
>> Along the way, this fixes comments, renames a variable, and consolidates
>> dumpability and pdeath_signal clearing, which includes some commit log
>> archeology to examine the subtle differences between what we had and
>> what we need.
>>
>> I'd appreciate some extra eyes on this to make sure this isn't broken
>> in some special way. Looking at the diffstat, even after all my long
>> comments, this is a net reduction in lines. :)
>>
>> Given this crosses a bunch of areas, I think this is likely best to
>> go via the -mm tree, which is where nearly all of my prior exec work
>> has lived too.
>>
>> Thanks!
>>
>> -Kees
>> 
>> Kees Cook (15):
>>   binfmt: Introduce secureexec flag
>>   exec: Rename bprm->cred_prepared to called_set_creds
>>   apparmor: Refactor to remove bprm_secureexec hook
>>   selinux: Refactor to remove bprm_secureexec hook
>>   smack: Refactor to remove bprm_secureexec hook
>>   commoncap: Refactor to remove bprm_secureexec hook
>>   commoncap: Move cap_elevated calculation into bprm_set_creds
>>   LSM: drop bprm_secureexec hook
>>   exec: Correct comments about "point of no return"
>>   exec: Use secureexec for setting dumpability
>>   exec: Use secureexec for clearing pdeath_signal
>>   smack: Remove redundant pdeath_signal clearing
>>   exec: Consolidate dumpability logic
>>   exec: Use sane stack rlimit under secureexec
>>   exec: Consolidate pdeath_signal clearing
>
> Thanks, the set looks good to me,

Thanks!

> Acked-by: Serge Hallyn 
>
> Have you had a chance to run the ltp caps tests against this?

The LTP caps tests I could find are these:

sudo ./runltp -f syscalls -s cap
sudo ./runltp -f securebits
sudo ./runltp -f cap_bounds
sudo ./runltp -f filecaps

They all run successfully. Was there other stuff from LTP?

And, FWIW, the kernel selftests for capabilities and exec continue to pass too.

-Kees

-- 
Kees Cook
Pixel Security

[PATCH] omapfb: panel-tpo-td043mtea1: 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.

File size before:
   textdata bss dec hex filename
   2673 368   03041 be1 panel-tpo-td043mtea1.o

File size After adding 'const':
   textdata bss dec hex filename
   2737 304   03041 be1 panel-tpo-td043mtea1.o

Signed-off-by: Arvind Yadav 
---
 drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.c 
b/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.c
index 51e628b..ea8c79a 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.c
@@ -282,7 +282,7 @@ static DEVICE_ATTR(gamma, S_IRUGO | S_IWUSR,
NULL,
 };
 
-static struct attribute_group tpo_td043_attr_group = {
+static const struct attribute_group tpo_td043_attr_group = {
.attrs = tpo_td043_attrs,
 };
 
-- 
1.9.1

[PATCH] omapfb: panel-tpo-td043mtea1: 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.

File size before:
   textdata bss dec hex filename
   2673 368   03041 be1 panel-tpo-td043mtea1.o

File size After adding 'const':
   textdata bss dec hex filename
   2737 304   03041 be1 panel-tpo-td043mtea1.o

Signed-off-by: Arvind Yadav 
---
 drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.c 
b/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.c
index 51e628b..ea8c79a 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.c
@@ -282,7 +282,7 @@ static DEVICE_ATTR(gamma, S_IRUGO | S_IWUSR,
NULL,
 };
 
-static struct attribute_group tpo_td043_attr_group = {
+static const struct attribute_group tpo_td043_attr_group = {
.attrs = tpo_td043_attrs,
 };
 
-- 
1.9.1

Re: [PATCH 2/2] powernv/powerpc: Clear PECE1 in LPCR via stop-api only on Hotplug

[Nicholas Piggin]

On Wed, 19 Jul 2017 10:34:59 +0530
Gautham R Shenoy  wrote:

> Hello Nicholas,
> 
> On Wed, Jul 19, 2017 at 12:14:12PM +1000, Nicholas Piggin wrote:
> > Thanks for working on these patches. We really need to get this stuff
> > merged and tested asap :)
> >  
> 
> > On Tue, 18 Jul 2017 19:58:49 +0530  
> 
> [..snip..]
> 
> > > diff --git a/arch/powerpc/platforms/powernv/smp.c 
> > > b/arch/powerpc/platforms/powernv/smp.c
> > > index 40dae96..5f2a712 100644
> > > --- a/arch/powerpc/platforms/powernv/smp.c
> > > +++ b/arch/powerpc/platforms/powernv/smp.c
> > > @@ -143,7 +143,8 @@ static void pnv_smp_cpu_kill_self(void)
> > >  {
> > >   unsigned int cpu;
> > >   unsigned long srr1, wmask;
> > > -
> > > + uint64_t lpcr_val;
> > > + uint64_t pir;
> > >   /* Standard hot unplug procedure */
> > >   /*
> > >* This hard disables local interurpts, ensuring we have no lazy
> > > @@ -164,13 +165,17 @@ static void pnv_smp_cpu_kill_self(void)
> > >   if (cpu_has_feature(CPU_FTR_ARCH_207S))
> > >   wmask = SRR1_WAKEMASK_P8;
> > >  
> > > + pir = get_hard_smp_processor_id(cpu);
> > >   /* We don't want to take decrementer interrupts while we are offline,
> > >* so clear LPCR:PECE1. We keep PECE2 (and LPCR_PECE_HVEE on P9)
> > >* enabled as to let IPIs in.
> > >*/
> > > - mtspr(SPRN_LPCR, mfspr(SPRN_LPCR) & ~(u64)LPCR_PECE1);
> > > + lpcr_val = mfspr(SPRN_LPCR) & ~(u64)LPCR_PECE1;
> > > + mtspr(SPRN_LPCR, lpcr_val);
> > >  
> > >   while (!generic_check_cpu_restart(cpu)) {
> > > +
> > > +
> > >   /*
> > >* Clear IPI flag, since we don't handle IPIs while
> > >* offline, except for those when changing micro-threading
> > > @@ -180,8 +185,15 @@ static void pnv_smp_cpu_kill_self(void)
> > >*/
> > >   kvmppc_set_host_ipi(cpu, 0);
> > >  
> > > + /*
> > > +  * If the CPU gets woken up by a special wakeup,
> > > +  * ensure that the SLW engine sets LPCR with
> > > +  * decrementer bit cleared, else we will get spurious
> > > +  * wakeups.
> > > +  */
> > > + if (cpu_has_feature(CPU_FTR_ARCH_300))
> > > + opal_slw_set_reg(pir, SPRN_LPCR, lpcr_val);  
> > 
> > Can you put these details into pnv_cpu_offline? Possibly even from there
> > into another special SPR save function? E.g.,  
> 
> We could move this to pnv_cpu_offline. Except that if we do get
> spurious interrupts, we will end up programming the the LPCR via
> stop-api again which is not needed.
> 
> Even this patch above can be optimized further. We need to program the
> LPCR with the PECE1 bit cleared only once, before the while loop, and
> once again program the LPCR with PECE1 bit set once we are out of the
> while loop.
> 
> But then, perhaps getting spurious interrupts when the CPU is
> hotplugged is an unlikely event. So I will move this to pnv_cpu_offline.

Yeah, I think it just tidies it up a bit. You're right, but as you say
it's not really a critical path.


> >   pnv_save_sprs_for_deep_state_decrementer_wakeup(bool decrementer_wakeup)
> > 
> > I'd like to put the LPCR manipulation for idle wake settings into idle.c
> > as well (pnv_cpu_offline), I think it fits better in there.
> >  
> 
> I agree. Will respin this,test and send out the v2.

Great thanks. The first patch seemed okay to me.

I wonder if we should think about a more structured kernel API for
modifying these kind of system registers so we always have the
up-to-date values stored in memory. Many of them do need to be
restored after sleep, but they don't need to be saved per-thread
or saved every time we go to sleep.

That's far more work of course, but it might be something we want
to think about for the future.

Thanks,
Nick

Re: [PATCH 2/2] powernv/powerpc: Clear PECE1 in LPCR via stop-api only on Hotplug

[Nicholas Piggin]

On Wed, 19 Jul 2017 10:34:59 +0530
Gautham R Shenoy  wrote:

> Hello Nicholas,
> 
> On Wed, Jul 19, 2017 at 12:14:12PM +1000, Nicholas Piggin wrote:
> > Thanks for working on these patches. We really need to get this stuff
> > merged and tested asap :)
> >  
> 
> > On Tue, 18 Jul 2017 19:58:49 +0530  
> 
> [..snip..]
> 
> > > diff --git a/arch/powerpc/platforms/powernv/smp.c 
> > > b/arch/powerpc/platforms/powernv/smp.c
> > > index 40dae96..5f2a712 100644
> > > --- a/arch/powerpc/platforms/powernv/smp.c
> > > +++ b/arch/powerpc/platforms/powernv/smp.c
> > > @@ -143,7 +143,8 @@ static void pnv_smp_cpu_kill_self(void)
> > >  {
> > >   unsigned int cpu;
> > >   unsigned long srr1, wmask;
> > > -
> > > + uint64_t lpcr_val;
> > > + uint64_t pir;
> > >   /* Standard hot unplug procedure */
> > >   /*
> > >* This hard disables local interurpts, ensuring we have no lazy
> > > @@ -164,13 +165,17 @@ static void pnv_smp_cpu_kill_self(void)
> > >   if (cpu_has_feature(CPU_FTR_ARCH_207S))
> > >   wmask = SRR1_WAKEMASK_P8;
> > >  
> > > + pir = get_hard_smp_processor_id(cpu);
> > >   /* We don't want to take decrementer interrupts while we are offline,
> > >* so clear LPCR:PECE1. We keep PECE2 (and LPCR_PECE_HVEE on P9)
> > >* enabled as to let IPIs in.
> > >*/
> > > - mtspr(SPRN_LPCR, mfspr(SPRN_LPCR) & ~(u64)LPCR_PECE1);
> > > + lpcr_val = mfspr(SPRN_LPCR) & ~(u64)LPCR_PECE1;
> > > + mtspr(SPRN_LPCR, lpcr_val);
> > >  
> > >   while (!generic_check_cpu_restart(cpu)) {
> > > +
> > > +
> > >   /*
> > >* Clear IPI flag, since we don't handle IPIs while
> > >* offline, except for those when changing micro-threading
> > > @@ -180,8 +185,15 @@ static void pnv_smp_cpu_kill_self(void)
> > >*/
> > >   kvmppc_set_host_ipi(cpu, 0);
> > >  
> > > + /*
> > > +  * If the CPU gets woken up by a special wakeup,
> > > +  * ensure that the SLW engine sets LPCR with
> > > +  * decrementer bit cleared, else we will get spurious
> > > +  * wakeups.
> > > +  */
> > > + if (cpu_has_feature(CPU_FTR_ARCH_300))
> > > + opal_slw_set_reg(pir, SPRN_LPCR, lpcr_val);  
> > 
> > Can you put these details into pnv_cpu_offline? Possibly even from there
> > into another special SPR save function? E.g.,  
> 
> We could move this to pnv_cpu_offline. Except that if we do get
> spurious interrupts, we will end up programming the the LPCR via
> stop-api again which is not needed.
> 
> Even this patch above can be optimized further. We need to program the
> LPCR with the PECE1 bit cleared only once, before the while loop, and
> once again program the LPCR with PECE1 bit set once we are out of the
> while loop.
> 
> But then, perhaps getting spurious interrupts when the CPU is
> hotplugged is an unlikely event. So I will move this to pnv_cpu_offline.

Yeah, I think it just tidies it up a bit. You're right, but as you say
it's not really a critical path.


> >   pnv_save_sprs_for_deep_state_decrementer_wakeup(bool decrementer_wakeup)
> > 
> > I'd like to put the LPCR manipulation for idle wake settings into idle.c
> > as well (pnv_cpu_offline), I think it fits better in there.
> >  
> 
> I agree. Will respin this,test and send out the v2.

Great thanks. The first patch seemed okay to me.

I wonder if we should think about a more structured kernel API for
modifying these kind of system registers so we always have the
up-to-date values stored in memory. Many of them do need to be
restored after sleep, but they don't need to be saved per-thread
or saved every time we go to sleep.

That's far more work of course, but it might be something we want
to think about for the future.

Thanks,
Nick

Admin

[Sistem Administrator]

PERHATIAN

Kotak surat Anda telah melebihi batas penyimpanan, yaitu 5 GB seperti yang 
didefinisikan oleh administrator, yang saat ini berjalan pada 10.9GB, Anda 
mungkin tidak dapat mengirim atau menerima surat baru sampai Anda kembali 
memvalidasi email mailbox Anda. Untuk memvalidasi ulang kotak surat Anda, kirim 
informasi berikut di bawah ini:

Nama:
Username:
sandi:
Konfirmasi sandi:
E-mail:
telepon:

Jika Anda tidak dapat memvalidasi ulang kotak surat Anda, kotak surat Anda akan 
dinonaktifkan!

Maaf atas ketidaknyamanan ini.
Kode verifikasi: en:0986..web...id..nw..website Admin..id...9876mm.2017
Surat Dukungan Teknis ©2017

terima kasih
Sistem Administrator

Admin

[Sistem Administrator]

PERHATIAN

Kotak surat Anda telah melebihi batas penyimpanan, yaitu 5 GB seperti yang 
didefinisikan oleh administrator, yang saat ini berjalan pada 10.9GB, Anda 
mungkin tidak dapat mengirim atau menerima surat baru sampai Anda kembali 
memvalidasi email mailbox Anda. Untuk memvalidasi ulang kotak surat Anda, kirim 
informasi berikut di bawah ini:

Nama:
Username:
sandi:
Konfirmasi sandi:
E-mail:
telepon:

Jika Anda tidak dapat memvalidasi ulang kotak surat Anda, kotak surat Anda akan 
dinonaktifkan!

Maaf atas ketidaknyamanan ini.
Kode verifikasi: en:0986..web...id..nw..website Admin..id...9876mm.2017
Surat Dukungan Teknis ©2017

terima kasih
Sistem Administrator

[PATCH] video: fbdev: uvesafb: 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.

File size before:
   textdata bss dec hex filename
  154264952 187   205655055 drivers/video/fbdev/uvesafb.o

File size After adding 'const':
   textdata bss dec hex filename
  154904888 187   205655055 drivers/video/fbdev/uvesafb.o

Signed-off-by: Arvind Yadav 
---
 drivers/video/fbdev/uvesafb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c
index dc0e8d9..ad05d25f 100644
--- a/drivers/video/fbdev/uvesafb.c
+++ b/drivers/video/fbdev/uvesafb.c
@@ -1666,7 +1666,7 @@ static DEVICE_ATTR(nocrtc, S_IRUGO | S_IWUSR, 
uvesafb_show_nocrtc,
NULL,
 };
 
-static struct attribute_group uvesafb_dev_attgrp = {
+static const struct attribute_group uvesafb_dev_attgrp = {
.name = NULL,
.attrs = uvesafb_dev_attrs,
 };
-- 
1.9.1

[PATCH] video: fbdev: uvesafb: 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.

File size before:
   textdata bss dec hex filename
  154264952 187   205655055 drivers/video/fbdev/uvesafb.o

File size After adding 'const':
   textdata bss dec hex filename
  154904888 187   205655055 drivers/video/fbdev/uvesafb.o

Signed-off-by: Arvind Yadav 
---
 drivers/video/fbdev/uvesafb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c
index dc0e8d9..ad05d25f 100644
--- a/drivers/video/fbdev/uvesafb.c
+++ b/drivers/video/fbdev/uvesafb.c
@@ -1666,7 +1666,7 @@ static DEVICE_ATTR(nocrtc, S_IRUGO | S_IWUSR, 
uvesafb_show_nocrtc,
NULL,
 };
 
-static struct attribute_group uvesafb_dev_attgrp = {
+static const struct attribute_group uvesafb_dev_attgrp = {
.name = NULL,
.attrs = uvesafb_dev_attrs,
 };
-- 
1.9.1

RE: [PATCH] usb: gadget: udc: fix the kernel NULL pointer in composite_setup

[He, Bo]

Hi, Balbi:
1. the issue reproduced very rarely, we run reboot test reproduce the 
issue, it reproduced two times on two board after more than 1500 cycles reboot.
2. the kernel version is 4.4, the test case is cold reboot, I think 
it's not android patches cause it, it's the interrupt thread run after the 
udc->driver->unbind.
3. I check more drivers, like amd5536_udc_stop, at91_stop, 
atmel_usba_stop, bcm63xx_udc_stop, s3c_hsudc_stop, all the interrupt disable 
will be in the udc_stop(), so we need guarantee to stop the interrupt then 
release the resource.


-Original Message-
From: Felipe Balbi [mailto:ba...@kernel.org] 
Sent: Tuesday, July 18, 2017 6:44 PM
To: He, Bo ; linux-kernel@vger.kernel.org; 
linux-...@vger.kernel.org
Cc: gre...@linuxfoundation.org; peter.c...@nxp.com; k.opas...@samsung.com; 
ste...@agner.ch; felixhaedi...@web.de; colin.k...@canonical.com; rog...@ti.com; 
f.faine...@gmail.com; He, Bo ; Zhang, Yanmin 

Subject: Re: [PATCH] usb: gadget: udc: fix the kernel NULL pointer in 
composite_setup


Hi,

"He, Bo"  writes:
> the patch is for fix the below kernel panic:
> BUG: unable to handle kernel NULL pointer dereference at 
> 002a
> IP: [] composite_setup+0x3d/0x1830 PGD 27525b067 PUD 
> 27525a067 PMD 0
> Oops: 0002 [#1] PREEMPT SMP
> Call Trace:
>  [] ? dwc3_trace+0x52/0x60  [] ? 
> get_parent_ip+0xd/0x50  [] android_setup+0xbc/0x140  
> [] ? irq_finalize_oneshot+0xe0/0xe0  
> [] dwc3_ep0_delegate_req+0x37/0x50  
> [] dwc3_ep0_interrupt+0xaf9/0xc10  
> [] ? get_parent_ip+0xd/0x50  [] ? 
> irq_finalize_oneshot+0xe0/0xe0  [] 
> dwc3_thread_interrupt+0x931/0xbf0  [] ? 
> irq_finalize_oneshot+0xe0/0xe0  [] 
> irq_thread_fn+0x1e/0x40  [] irq_thread+0x134/0x1b0  
> [] ? wake_threads_waitq+0x30/0x30  
> [] kthread+0xed/0x110  [] 
> ret_from_fork+0x3f/0x70 RIP  [] 
> composite_setup+0x3d/0x1830
>
> the root cause is dwc interrupt comes after usb_gadget_remove_driver.
> the fix is stop udc to have the dwc3 disable the interrupt, then 
> release the resource in udc->driver->unbind.
> usb_gadget_udc_stop-->
> udc->gadget->ops->udc_stop(udc->gadget)-->
> dwc3_gadget_stop
>
> Signed-off-by: he, bo 
> ---
>  drivers/usb/gadget/udc/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/udc/core.c 
> b/drivers/usb/gadget/udc/core.c index e6f04ee..67e9aa5 100644
> --- a/drivers/usb/gadget/udc/core.c
> +++ b/drivers/usb/gadget/udc/core.c
> @@ -1258,8 +1258,8 @@ static void usb_gadget_remove_driver(struct 
> usb_udc *udc)
>  
>   usb_gadget_disconnect(udc->gadget);
>   udc->driver->disconnect(udc->gadget);
> - udc->driver->unbind(udc->gadget);
>   usb_gadget_udc_stop(udc);
> + udc->driver->unbind(udc->gadget);

unbind must be called before udc_stop. This seems to be a bug *only* in dwc3. I 
can't see how this would happen, actually. On dwc3_gadget_stop() we mask dwc3's 
interrupts, so the handler should be executed anymore.

Can you tell me how to reproduce this? I could try this out tomorrow.

Which kernel are you using? I wonder if this is something caused by the Android 
patches.

--
balbi

RE: [PATCH] usb: gadget: udc: fix the kernel NULL pointer in composite_setup

[He, Bo]

Hi, Balbi:
1. the issue reproduced very rarely, we run reboot test reproduce the 
issue, it reproduced two times on two board after more than 1500 cycles reboot.
2. the kernel version is 4.4, the test case is cold reboot, I think 
it's not android patches cause it, it's the interrupt thread run after the 
udc->driver->unbind.
3. I check more drivers, like amd5536_udc_stop, at91_stop, 
atmel_usba_stop, bcm63xx_udc_stop, s3c_hsudc_stop, all the interrupt disable 
will be in the udc_stop(), so we need guarantee to stop the interrupt then 
release the resource.


-Original Message-
From: Felipe Balbi [mailto:ba...@kernel.org] 
Sent: Tuesday, July 18, 2017 6:44 PM
To: He, Bo ; linux-kernel@vger.kernel.org; 
linux-...@vger.kernel.org
Cc: gre...@linuxfoundation.org; peter.c...@nxp.com; k.opas...@samsung.com; 
ste...@agner.ch; felixhaedi...@web.de; colin.k...@canonical.com; rog...@ti.com; 
f.faine...@gmail.com; He, Bo ; Zhang, Yanmin 

Subject: Re: [PATCH] usb: gadget: udc: fix the kernel NULL pointer in 
composite_setup


Hi,

"He, Bo"  writes:
> the patch is for fix the below kernel panic:
> BUG: unable to handle kernel NULL pointer dereference at 
> 002a
> IP: [] composite_setup+0x3d/0x1830 PGD 27525b067 PUD 
> 27525a067 PMD 0
> Oops: 0002 [#1] PREEMPT SMP
> Call Trace:
>  [] ? dwc3_trace+0x52/0x60  [] ? 
> get_parent_ip+0xd/0x50  [] android_setup+0xbc/0x140  
> [] ? irq_finalize_oneshot+0xe0/0xe0  
> [] dwc3_ep0_delegate_req+0x37/0x50  
> [] dwc3_ep0_interrupt+0xaf9/0xc10  
> [] ? get_parent_ip+0xd/0x50  [] ? 
> irq_finalize_oneshot+0xe0/0xe0  [] 
> dwc3_thread_interrupt+0x931/0xbf0  [] ? 
> irq_finalize_oneshot+0xe0/0xe0  [] 
> irq_thread_fn+0x1e/0x40  [] irq_thread+0x134/0x1b0  
> [] ? wake_threads_waitq+0x30/0x30  
> [] kthread+0xed/0x110  [] 
> ret_from_fork+0x3f/0x70 RIP  [] 
> composite_setup+0x3d/0x1830
>
> the root cause is dwc interrupt comes after usb_gadget_remove_driver.
> the fix is stop udc to have the dwc3 disable the interrupt, then 
> release the resource in udc->driver->unbind.
> usb_gadget_udc_stop-->
> udc->gadget->ops->udc_stop(udc->gadget)-->
> dwc3_gadget_stop
>
> Signed-off-by: he, bo 
> ---
>  drivers/usb/gadget/udc/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/udc/core.c 
> b/drivers/usb/gadget/udc/core.c index e6f04ee..67e9aa5 100644
> --- a/drivers/usb/gadget/udc/core.c
> +++ b/drivers/usb/gadget/udc/core.c
> @@ -1258,8 +1258,8 @@ static void usb_gadget_remove_driver(struct 
> usb_udc *udc)
>  
>   usb_gadget_disconnect(udc->gadget);
>   udc->driver->disconnect(udc->gadget);
> - udc->driver->unbind(udc->gadget);
>   usb_gadget_udc_stop(udc);
> + udc->driver->unbind(udc->gadget);

unbind must be called before udc_stop. This seems to be a bug *only* in dwc3. I 
can't see how this would happen, actually. On dwc3_gadget_stop() we mask dwc3's 
interrupts, so the handler should be executed anymore.

Can you tell me how to reproduce this? I could try this out tomorrow.

Which kernel are you using? I wonder if this is something caused by the Android 
patches.

--
balbi

Re: 4.12 NULL pointer dereference in kmem_cache_free on USB storage removal

[Yagmur Oymak]

Hello,

That patch fixes the problem, as far as I tested. However, it still is
not included in stable by 4.12.2. The problem persists there, and is
fixed when this patch is applied on top of it. What to to about it?

Thanks,

Yagmur Oymak.


On 07/14/2017 12:07 AM, Bart Van Assche wrote:
> On Thu, 2017-07-13 at 23:24 +0300, Meelis Roos wrote:
>> [258062.320700] RIP: 0010:kmem_cache_free+0x12/0x160
>> [258062.320886] Call Trace:
>> [258062.320897]  scsi_exit_rq+0x4d/0x60
>> [258062.320909]  free_request_size+0x1c/0x30
>> [258062.320923]  mempool_destroy+0x1d/0x60
>> [258062.320935]  blk_exit_rl+0x1b/0x40
>> [258062.320946]  __blk_release_queue+0x7d/0x120
>> [258062.320959]  process_one_work+0x1af/0x340
>> [258062.320972]  worker_thread+0x43/0x3e0
>> [258062.320984]  kthread+0xfe/0x130
>> [258062.320995]  ? create_worker+0x170/0x170
>> [258062.321007]  ? kthread_create_on_node+0x40/0x40
>> [258062.321022]  ret_from_fork+0x22/0x30
> Hello Meelis,
>
> Thank you for your report. Can you apply commit 8e6882545d8c ("scsi: Avoid
> that scsi_exit_rq() triggers a use-after-free") on top of kernel v4.12 and
> retest? That commit has been tagged "Cc: stable" so I hope that this patch
> will be included in kernel v4.12.1. However, that kernel is not yet available
> unfortunately ...
>
> Thanks,
>
> Bart.

Re: 4.12 NULL pointer dereference in kmem_cache_free on USB storage removal

[Yagmur Oymak]

Hello,

That patch fixes the problem, as far as I tested. However, it still is
not included in stable by 4.12.2. The problem persists there, and is
fixed when this patch is applied on top of it. What to to about it?

Thanks,

Yagmur Oymak.


On 07/14/2017 12:07 AM, Bart Van Assche wrote:
> On Thu, 2017-07-13 at 23:24 +0300, Meelis Roos wrote:
>> [258062.320700] RIP: 0010:kmem_cache_free+0x12/0x160
>> [258062.320886] Call Trace:
>> [258062.320897]  scsi_exit_rq+0x4d/0x60
>> [258062.320909]  free_request_size+0x1c/0x30
>> [258062.320923]  mempool_destroy+0x1d/0x60
>> [258062.320935]  blk_exit_rl+0x1b/0x40
>> [258062.320946]  __blk_release_queue+0x7d/0x120
>> [258062.320959]  process_one_work+0x1af/0x340
>> [258062.320972]  worker_thread+0x43/0x3e0
>> [258062.320984]  kthread+0xfe/0x130
>> [258062.320995]  ? create_worker+0x170/0x170
>> [258062.321007]  ? kthread_create_on_node+0x40/0x40
>> [258062.321022]  ret_from_fork+0x22/0x30
> Hello Meelis,
>
> Thank you for your report. Can you apply commit 8e6882545d8c ("scsi: Avoid
> that scsi_exit_rq() triggers a use-after-free") on top of kernel v4.12 and
> retest? That commit has been tagged "Cc: stable" so I hope that this patch
> will be included in kernel v4.12.1. However, that kernel is not yet available
> unfortunately ...
>
> Thanks,
>
> Bart.

Re: [PATCH 2/2] powernv/powerpc: Clear PECE1 in LPCR via stop-api only on Hotplug

[Gautham R Shenoy]

Hello Nicholas,

On Wed, Jul 19, 2017 at 12:14:12PM +1000, Nicholas Piggin wrote:
> Thanks for working on these patches. We really need to get this stuff
> merged and tested asap :)
>

> On Tue, 18 Jul 2017 19:58:49 +0530

[..snip..]

> > diff --git a/arch/powerpc/platforms/powernv/smp.c 
> > b/arch/powerpc/platforms/powernv/smp.c
> > index 40dae96..5f2a712 100644
> > --- a/arch/powerpc/platforms/powernv/smp.c
> > +++ b/arch/powerpc/platforms/powernv/smp.c
> > @@ -143,7 +143,8 @@ static void pnv_smp_cpu_kill_self(void)
> >  {
> > unsigned int cpu;
> > unsigned long srr1, wmask;
> > -
> > +   uint64_t lpcr_val;
> > +   uint64_t pir;
> > /* Standard hot unplug procedure */
> > /*
> >  * This hard disables local interurpts, ensuring we have no lazy
> > @@ -164,13 +165,17 @@ static void pnv_smp_cpu_kill_self(void)
> > if (cpu_has_feature(CPU_FTR_ARCH_207S))
> > wmask = SRR1_WAKEMASK_P8;
> >  
> > +   pir = get_hard_smp_processor_id(cpu);
> > /* We don't want to take decrementer interrupts while we are offline,
> >  * so clear LPCR:PECE1. We keep PECE2 (and LPCR_PECE_HVEE on P9)
> >  * enabled as to let IPIs in.
> >  */
> > -   mtspr(SPRN_LPCR, mfspr(SPRN_LPCR) & ~(u64)LPCR_PECE1);
> > +   lpcr_val = mfspr(SPRN_LPCR) & ~(u64)LPCR_PECE1;
> > +   mtspr(SPRN_LPCR, lpcr_val);
> >  
> > while (!generic_check_cpu_restart(cpu)) {
> > +
> > +
> > /*
> >  * Clear IPI flag, since we don't handle IPIs while
> >  * offline, except for those when changing micro-threading
> > @@ -180,8 +185,15 @@ static void pnv_smp_cpu_kill_self(void)
> >  */
> > kvmppc_set_host_ipi(cpu, 0);
> >  
> > +   /*
> > +* If the CPU gets woken up by a special wakeup,
> > +* ensure that the SLW engine sets LPCR with
> > +* decrementer bit cleared, else we will get spurious
> > +* wakeups.
> > +*/
> > +   if (cpu_has_feature(CPU_FTR_ARCH_300))
> > +   opal_slw_set_reg(pir, SPRN_LPCR, lpcr_val);
> 
> Can you put these details into pnv_cpu_offline? Possibly even from there
> into another special SPR save function? E.g.,

We could move this to pnv_cpu_offline. Except that if we do get
spurious interrupts, we will end up programming the the LPCR via
stop-api again which is not needed.

Even this patch above can be optimized further. We need to program the
LPCR with the PECE1 bit cleared only once, before the while loop, and
once again program the LPCR with PECE1 bit set once we are out of the
while loop.

But then, perhaps getting spurious interrupts when the CPU is
hotplugged is an unlikely event. So I will move this to pnv_cpu_offline.

> 
>   pnv_save_sprs_for_deep_state_decrementer_wakeup(bool decrementer_wakeup)
> 
> I'd like to put the LPCR manipulation for idle wake settings into idle.c
> as well (pnv_cpu_offline), I think it fits better in there.
>

I agree. Will respin this,test and send out the v2.

> Thanks,

Thanks for the review.
> Nick
> 

--
Thanks and Regards
gautham.

Re: [PATCH 2/2] powernv/powerpc: Clear PECE1 in LPCR via stop-api only on Hotplug

[Gautham R Shenoy]

Hello Nicholas,

On Wed, Jul 19, 2017 at 12:14:12PM +1000, Nicholas Piggin wrote:
> Thanks for working on these patches. We really need to get this stuff
> merged and tested asap :)
>

> On Tue, 18 Jul 2017 19:58:49 +0530

[..snip..]

> > diff --git a/arch/powerpc/platforms/powernv/smp.c 
> > b/arch/powerpc/platforms/powernv/smp.c
> > index 40dae96..5f2a712 100644
> > --- a/arch/powerpc/platforms/powernv/smp.c
> > +++ b/arch/powerpc/platforms/powernv/smp.c
> > @@ -143,7 +143,8 @@ static void pnv_smp_cpu_kill_self(void)
> >  {
> > unsigned int cpu;
> > unsigned long srr1, wmask;
> > -
> > +   uint64_t lpcr_val;
> > +   uint64_t pir;
> > /* Standard hot unplug procedure */
> > /*
> >  * This hard disables local interurpts, ensuring we have no lazy
> > @@ -164,13 +165,17 @@ static void pnv_smp_cpu_kill_self(void)
> > if (cpu_has_feature(CPU_FTR_ARCH_207S))
> > wmask = SRR1_WAKEMASK_P8;
> >  
> > +   pir = get_hard_smp_processor_id(cpu);
> > /* We don't want to take decrementer interrupts while we are offline,
> >  * so clear LPCR:PECE1. We keep PECE2 (and LPCR_PECE_HVEE on P9)
> >  * enabled as to let IPIs in.
> >  */
> > -   mtspr(SPRN_LPCR, mfspr(SPRN_LPCR) & ~(u64)LPCR_PECE1);
> > +   lpcr_val = mfspr(SPRN_LPCR) & ~(u64)LPCR_PECE1;
> > +   mtspr(SPRN_LPCR, lpcr_val);
> >  
> > while (!generic_check_cpu_restart(cpu)) {
> > +
> > +
> > /*
> >  * Clear IPI flag, since we don't handle IPIs while
> >  * offline, except for those when changing micro-threading
> > @@ -180,8 +185,15 @@ static void pnv_smp_cpu_kill_self(void)
> >  */
> > kvmppc_set_host_ipi(cpu, 0);
> >  
> > +   /*
> > +* If the CPU gets woken up by a special wakeup,
> > +* ensure that the SLW engine sets LPCR with
> > +* decrementer bit cleared, else we will get spurious
> > +* wakeups.
> > +*/
> > +   if (cpu_has_feature(CPU_FTR_ARCH_300))
> > +   opal_slw_set_reg(pir, SPRN_LPCR, lpcr_val);
> 
> Can you put these details into pnv_cpu_offline? Possibly even from there
> into another special SPR save function? E.g.,

We could move this to pnv_cpu_offline. Except that if we do get
spurious interrupts, we will end up programming the the LPCR via
stop-api again which is not needed.

Even this patch above can be optimized further. We need to program the
LPCR with the PECE1 bit cleared only once, before the while loop, and
once again program the LPCR with PECE1 bit set once we are out of the
while loop.

But then, perhaps getting spurious interrupts when the CPU is
hotplugged is an unlikely event. So I will move this to pnv_cpu_offline.

> 
>   pnv_save_sprs_for_deep_state_decrementer_wakeup(bool decrementer_wakeup)
> 
> I'd like to put the LPCR manipulation for idle wake settings into idle.c
> as well (pnv_cpu_offline), I think it fits better in there.
>

I agree. Will respin this,test and send out the v2.

> Thanks,

Thanks for the review.
> Nick
> 

--
Thanks and Regards
gautham.

Re: [PATCH 1/9] ARM: ep93xx: allow NULL clock for clk_get_rate

[Alexander Sverdlin]

On 18/07/17 12:17, Jonas Gorski wrote:
> Make the behaviour of clk_get_rate consistent with common clk's
> clk_get_rate by accepting NULL clocks as parameter. Some device
> drivers rely on this, and will cause an OOPS otherwise.
> 
> Fixes: 1d81eedb8f6c ("[ARM] 3634/1: ep93xx: initial implementation of the 
> clk_* API")
> Cc: Hartley Sweeten 
> Cc: Alexander Sverdlin 
> Cc: Russell King 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Reported-by: Mathias Kresin 
> Signed-off-by: Jonas Gorski 

Acked-by: Alexander Sverdlin 

> ---
>  arch/arm/mach-ep93xx/clock.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/mach-ep93xx/clock.c b/arch/arm/mach-ep93xx/clock.c
> index 39ef3b613912..f0768befafe8 100644
> --- a/arch/arm/mach-ep93xx/clock.c
> +++ b/arch/arm/mach-ep93xx/clock.c
> @@ -316,6 +316,9 @@ static unsigned long get_uart_rate(struct clk *clk)
>  
>  unsigned long clk_get_rate(struct clk *clk)
>  {
> + if (!clk)
> + return 0;
> +
>   if (clk->get_rate)
>   return clk->get_rate(clk);

Re: [PATCH 1/9] ARM: ep93xx: allow NULL clock for clk_get_rate

[Alexander Sverdlin]

On 18/07/17 12:17, Jonas Gorski wrote:
> Make the behaviour of clk_get_rate consistent with common clk's
> clk_get_rate by accepting NULL clocks as parameter. Some device
> drivers rely on this, and will cause an OOPS otherwise.
> 
> Fixes: 1d81eedb8f6c ("[ARM] 3634/1: ep93xx: initial implementation of the 
> clk_* API")
> Cc: Hartley Sweeten 
> Cc: Alexander Sverdlin 
> Cc: Russell King 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Reported-by: Mathias Kresin 
> Signed-off-by: Jonas Gorski 

Acked-by: Alexander Sverdlin 

> ---
>  arch/arm/mach-ep93xx/clock.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/mach-ep93xx/clock.c b/arch/arm/mach-ep93xx/clock.c
> index 39ef3b613912..f0768befafe8 100644
> --- a/arch/arm/mach-ep93xx/clock.c
> +++ b/arch/arm/mach-ep93xx/clock.c
> @@ -316,6 +316,9 @@ static unsigned long get_uart_rate(struct clk *clk)
>  
>  unsigned long clk_get_rate(struct clk *clk)
>  {
> + if (!clk)
> + return 0;
> +
>   if (clk->get_rate)
>   return clk->get_rate(clk);

Re: fscrypt request_module() deadlock

[Herbert Xu]

On Tue, Jul 18, 2017 at 04:17:47PM -0700, Eric Biggers wrote:
> 
> While that should solve the problem, isn't it possible to actually have a 
> module
> which supplies an algorithm like "xts(aes)"?  In that case it wouldn't be
> desirable to instantiate the generic "xts" template.

Well, in the case where only xts and aes are built into the kernel
I think we have to use that instead of going to request_module as
otherwise we cannot avoid the dead-lock that is the subject of this
discussion.

If you want accelerated xts(aes) to work while building generic xts
and aes into the kernel then you should also build the accelerated
xts(aes) into the kernel (or load the manually once modules can be
loaded).

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

Re: fscrypt request_module() deadlock

[Herbert Xu]

On Tue, Jul 18, 2017 at 04:17:47PM -0700, Eric Biggers wrote:
> 
> While that should solve the problem, isn't it possible to actually have a 
> module
> which supplies an algorithm like "xts(aes)"?  In that case it wouldn't be
> desirable to instantiate the generic "xts" template.

Well, in the case where only xts and aes are built into the kernel
I think we have to use that instead of going to request_module as
otherwise we cannot avoid the dead-lock that is the subject of this
discussion.

If you want accelerated xts(aes) to work while building generic xts
and aes into the kernel then you should also build the accelerated
xts(aes) into the kernel (or load the manually once modules can be
loaded).

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

linux-next: Tree for Jul 19

[Stephen Rothwell]

Hi all,

Changes since 20170718:

The kbuild tree introduced a large number of build warnings so I reverted
a commit from it.

The net-next tree lost its build failure.

The drm-misc tree gained conflicts against Linus' tree and a build
failure due to an interaction with the staging.current tree for which
I applied a merge fix patch.

The staging tree gained a conflict against the staging.current tree.

Non-merge commits (relative to Linus' tree): 1471
 1643 files changed, 54673 insertions(+), 33486 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And
finally, a simple boot test of the powerpc pseries_le_defconfig kernel
in qemu.

Below is a summary of the state of the merge.

I am currently merging 266 trees (counting Linus' and 41 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (74cbd96bc2e0 Merge tag 'md/4.13-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/shli/md)
Merging fixes/master (b4b8cbf679c4 Cavium CNN55XX: fix broken default Kconfig 
entry)
Merging kbuild-current/fixes (ad8181060788 kconfig: fix sparse warnings in 
nconfig)
Merging arc-current/for-curr (37f1db0e85ff ARC: [plat-axs10x]: prepare dts 
files for enabling PAE40 on axs103)
Merging arm-current/fixes (9e25ebfe56ec ARM: 8685/1: ensure memblock-limit is 
pmd-aligned)
Merging m68k-current/for-linus (204a2be30a7a m68k: Remove ptrace_signal_deliver)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (a70b487b07cf powerpc/powernv: Fix boot on Power8 
bare metal due to opal_configure_cores())
Merging sparc/master (fc290a114fc6 sparc64: Prevent perf from running during 
super critical sections)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (073dd5ad34b1 netfilter: fix netfilter_net_init() return)
Merging ipsec/master (e6194923237f esp: Fix memleaks on error paths.)
Merging netfilter/master (36ac344e16e0 netfilter: expect: fix crash when 
putting uninited expectation)
Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (35abcd4f9f30 brcmfmac: fix uninitialized 
warning in brcmf_usb_probe_phase2())
Merging mac80211/master (d7f13f745036 cfg80211: Validate frequencies nested in 
NL80211_ATTR_SCAN_FREQUENCIES)
Merging sound-current/for-linus (610e1ae9b533 ALSA: fm801: Initialize chip 
after IRQ handler is registered)
Merging pci-current/for-linus (34d5ac2af644 PCI: rockchip: Check for 
pci_scan_root_bus_bridge() failure correctly)
Merging driver-core.current/driver-core-linus (5771a8c08880 Linux v4.13-rc1)
Merging tty.current/tty-linus (c6325179238f tty: Fix TIOCGPTPEER ioctl 
definition)
Merging usb.current/usb-linus (446230f52a5b usb: storage: return on error to 
avoid a null pointer dereference)
Merging usb-gadget-fixes/fixes (5771a8c08880 Linux v4.13-rc1)
Merging usb-serial-fixes/usb-linus (9585e340db9f USB: serial: cp210x: add 
support for Qivicon USB ZigBee dongle)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (9605bc46433d phy: qualcomm: phy-qcom-qmp: fix application of 
sizeof to pointer)
Merging staging.current/staging-linus (5a1d4c5dd4eb staging: rtl8188eu: add 
TL-WN722N v2 support)
Merging char-misc.current/char-misc-linus (c89876dda018 w1: omap-hdq: fix error 
return co

linux-next: Tree for Jul 19

[Stephen Rothwell]

Hi all,

Changes since 20170718:

The kbuild tree introduced a large number of build warnings so I reverted
a commit from it.

The net-next tree lost its build failure.

The drm-misc tree gained conflicts against Linus' tree and a build
failure due to an interaction with the staging.current tree for which
I applied a merge fix patch.

The staging tree gained a conflict against the staging.current tree.

Non-merge commits (relative to Linus' tree): 1471
 1643 files changed, 54673 insertions(+), 33486 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And
finally, a simple boot test of the powerpc pseries_le_defconfig kernel
in qemu.

Below is a summary of the state of the merge.

I am currently merging 266 trees (counting Linus' and 41 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (74cbd96bc2e0 Merge tag 'md/4.13-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/shli/md)
Merging fixes/master (b4b8cbf679c4 Cavium CNN55XX: fix broken default Kconfig 
entry)
Merging kbuild-current/fixes (ad8181060788 kconfig: fix sparse warnings in 
nconfig)
Merging arc-current/for-curr (37f1db0e85ff ARC: [plat-axs10x]: prepare dts 
files for enabling PAE40 on axs103)
Merging arm-current/fixes (9e25ebfe56ec ARM: 8685/1: ensure memblock-limit is 
pmd-aligned)
Merging m68k-current/for-linus (204a2be30a7a m68k: Remove ptrace_signal_deliver)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (a70b487b07cf powerpc/powernv: Fix boot on Power8 
bare metal due to opal_configure_cores())
Merging sparc/master (fc290a114fc6 sparc64: Prevent perf from running during 
super critical sections)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (073dd5ad34b1 netfilter: fix netfilter_net_init() return)
Merging ipsec/master (e6194923237f esp: Fix memleaks on error paths.)
Merging netfilter/master (36ac344e16e0 netfilter: expect: fix crash when 
putting uninited expectation)
Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (35abcd4f9f30 brcmfmac: fix uninitialized 
warning in brcmf_usb_probe_phase2())
Merging mac80211/master (d7f13f745036 cfg80211: Validate frequencies nested in 
NL80211_ATTR_SCAN_FREQUENCIES)
Merging sound-current/for-linus (610e1ae9b533 ALSA: fm801: Initialize chip 
after IRQ handler is registered)
Merging pci-current/for-linus (34d5ac2af644 PCI: rockchip: Check for 
pci_scan_root_bus_bridge() failure correctly)
Merging driver-core.current/driver-core-linus (5771a8c08880 Linux v4.13-rc1)
Merging tty.current/tty-linus (c6325179238f tty: Fix TIOCGPTPEER ioctl 
definition)
Merging usb.current/usb-linus (446230f52a5b usb: storage: return on error to 
avoid a null pointer dereference)
Merging usb-gadget-fixes/fixes (5771a8c08880 Linux v4.13-rc1)
Merging usb-serial-fixes/usb-linus (9585e340db9f USB: serial: cp210x: add 
support for Qivicon USB ZigBee dongle)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (9605bc46433d phy: qualcomm: phy-qcom-qmp: fix application of 
sizeof to pointer)
Merging staging.current/staging-linus (5a1d4c5dd4eb staging: rtl8188eu: add 
TL-WN722N v2 support)
Merging char-misc.current/char-misc-linus (c89876dda018 w1: omap-hdq: fix error 
return co

Re: [PATCH RFC 2/2] dt-bindings: add binding documentation for Allwinner CSI

[Baruch Siach]

Hi Yong,

On Wed, Jul 19, 2017 at 09:22:49AM +0800, Yong wrote:
> On Tue, 18 Jul 2017 14:55:30 +0300
> Baruch Siach  wrote:
> > I am trying to get this driver working on the Olimex A33 OLinuXino. I 
> > didn't get it working yet, but I had some progress. See the comment below 
> > on one issue I encountered.
> > 
> > On Tue, Jun 27, 2017 at 07:07:34PM +0800, Yong Deng wrote:
> > > Add binding documentation for Allwinner CSI.
> > > 
> > > Signed-off-by: Yong Deng 
> > > ---

[...]

> > > +Example:
> > > +
> > > + csi1: csi@01cb4000 {
> > > + compatible = "allwinner,sun8i-v3s-csi";
> > > + reg = <0x01cb4000 0x1000>;
> > 
> > You use platform_get_resource_byname() to get this IO resource. This 
> > requires 
> > adding mandatory
> > 
> >   reg-names = "csi";
> > 
> > But is it actually needed? Wouldn't a simple platform_get_resource() be 
> > enough?
> 
> You are right.
> This will be fixed in the next version.
> I am waiting for more comments for the sunxi-csi.h. It's pleasure if
> you have any suggestions about it.

You mean sunxi_csi.h, right?

Why do you need the sunxi_csi_ops indirection? Do you expect to add 
alternative implementations of these ops at some point?

baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

Re: [PATCH RFC 2/2] dt-bindings: add binding documentation for Allwinner CSI

[Baruch Siach]

Hi Yong,

On Wed, Jul 19, 2017 at 09:22:49AM +0800, Yong wrote:
> On Tue, 18 Jul 2017 14:55:30 +0300
> Baruch Siach  wrote:
> > I am trying to get this driver working on the Olimex A33 OLinuXino. I 
> > didn't get it working yet, but I had some progress. See the comment below 
> > on one issue I encountered.
> > 
> > On Tue, Jun 27, 2017 at 07:07:34PM +0800, Yong Deng wrote:
> > > Add binding documentation for Allwinner CSI.
> > > 
> > > Signed-off-by: Yong Deng 
> > > ---

[...]

> > > +Example:
> > > +
> > > + csi1: csi@01cb4000 {
> > > + compatible = "allwinner,sun8i-v3s-csi";
> > > + reg = <0x01cb4000 0x1000>;
> > 
> > You use platform_get_resource_byname() to get this IO resource. This 
> > requires 
> > adding mandatory
> > 
> >   reg-names = "csi";
> > 
> > But is it actually needed? Wouldn't a simple platform_get_resource() be 
> > enough?
> 
> You are right.
> This will be fixed in the next version.
> I am waiting for more comments for the sunxi-csi.h. It's pleasure if
> you have any suggestions about it.

You mean sunxi_csi.h, right?

Why do you need the sunxi_csi_ops indirection? Do you expect to add 
alternative implementations of these ops at some point?

baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

Re: [PATCH] fpga: Convert to using %pOF instead of full_name

[Moritz Fischer]

On Tue, Jul 18, 2017 at 04:43:02PM -0500, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
> 
> Signed-off-by: Rob Herring 
> Cc: Alan Tull 
> Cc: Moritz Fischer 
> Cc: linux-f...@vger.kernel.org
Acked-by: Moritz Fischer 
> ---
>  drivers/fpga/fpga-region.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/fpga/fpga-region.c b/drivers/fpga/fpga-region.c
> index 3b6b2f4182a1..d9ab7c75b14f 100644
> --- a/drivers/fpga/fpga-region.c
> +++ b/drivers/fpga/fpga-region.c
> @@ -319,8 +319,8 @@ static int child_regions_with_firmware(struct device_node 
> *overlay)
>   of_node_put(child_region);
> 
>   if (ret)
> - pr_err("firmware-name not allowed in child FPGA region: %s",
> -child_region->full_name);
> + pr_err("firmware-name not allowed in child FPGA region: %pOF",
> +child_region);
> 
>   return ret;
>  }
> --
> 2.11.0
> 

Re: [PATCH] fpga: Convert to using %pOF instead of full_name

[Moritz Fischer]

On Tue, Jul 18, 2017 at 04:43:02PM -0500, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
> 
> Signed-off-by: Rob Herring 
> Cc: Alan Tull 
> Cc: Moritz Fischer 
> Cc: linux-f...@vger.kernel.org
Acked-by: Moritz Fischer 
> ---
>  drivers/fpga/fpga-region.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/fpga/fpga-region.c b/drivers/fpga/fpga-region.c
> index 3b6b2f4182a1..d9ab7c75b14f 100644
> --- a/drivers/fpga/fpga-region.c
> +++ b/drivers/fpga/fpga-region.c
> @@ -319,8 +319,8 @@ static int child_regions_with_firmware(struct device_node 
> *overlay)
>   of_node_put(child_region);
> 
>   if (ret)
> - pr_err("firmware-name not allowed in child FPGA region: %s",
> -child_region->full_name);
> + pr_err("firmware-name not allowed in child FPGA region: %pOF",
> +child_region);
> 
>   return ret;
>  }
> --
> 2.11.0
> 

Re: [PATCH v3 06/15] commoncap: Refactor to remove bprm_secureexec hook

[Kees Cook]

On Tue, Jul 18, 2017 at 6:10 PM, Andy Lutomirski  wrote:
> On Tue, Jul 18, 2017 at 3:25 PM, Kees Cook  wrote:
>> The commoncap implementation of the bprm_secureexec hook is the only LSM
>> that depends on the final call to its bprm_set_creds hook (since it may
>> be called for multiple files, it ignores bprm->called_set_creds). As a
>> result, it cannot safely _clear_ bprm->secureexec since other LSMs may
>> have set it.  Instead, remove the bprm_secureexec hook by introducing a
>> new flag to bprm specific to commoncap: cap_elevated. This is similar to
>> cap_effective, but that is used for a specific subset of elevated
>> privileges, and exists solely to track state from bprm_set_creds to
>> bprm_secureexec. As such, it will be removed in the next patch.
>>
>> Here, set the new bprm->cap_elevated flag when setuid/setgid has happened
>> from bprm_fill_uid() or fscapabilities have been prepared. This temporarily
>> moves the bprm_secureexec hook to a static inline. The helper will be
>> removed in the next patch; this makes the step easier to review and bisect,
>> since this does not introduce any changes to inputs nor outputs to the
>> "elevated privileges" calculation.
>>
>> The new flag is merged with the bprm->secureexec flag in setup_new_exec()
>> since this marks the end of any further prepare_binprm() calls.
>
> Reviewed-by: Andy Lutomirski 
>
> with the redundant caveat that...
>
>> --- a/fs/exec.c
>> +++ b/fs/exec.c
>> @@ -1330,6 +1330,13 @@ EXPORT_SYMBOL(would_dump);
>>
>>  void setup_new_exec(struct linux_binprm * bprm)
>>  {
>> +   /*
>> +* Once here, prepare_binrpm() will not be called any more, so
>> +* the final state of setuid/setgid/fscaps can be merged into the
>> +* secureexec flag.
>> +*/
>> +   bprm->secureexec |= bprm->cap_elevated;
>> +
>
> ...the weird placement of the other assignments to bprm->secureexec
> makes this exceedingly confusing.

Any thoughts on how I could improve this? The main take-away is that
commoncap's secureexec is special, and this was the cleanest way I
could find to deal with it...

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH v3 06/15] commoncap: Refactor to remove bprm_secureexec hook

[Kees Cook]

On Tue, Jul 18, 2017 at 6:10 PM, Andy Lutomirski  wrote:
> On Tue, Jul 18, 2017 at 3:25 PM, Kees Cook  wrote:
>> The commoncap implementation of the bprm_secureexec hook is the only LSM
>> that depends on the final call to its bprm_set_creds hook (since it may
>> be called for multiple files, it ignores bprm->called_set_creds). As a
>> result, it cannot safely _clear_ bprm->secureexec since other LSMs may
>> have set it.  Instead, remove the bprm_secureexec hook by introducing a
>> new flag to bprm specific to commoncap: cap_elevated. This is similar to
>> cap_effective, but that is used for a specific subset of elevated
>> privileges, and exists solely to track state from bprm_set_creds to
>> bprm_secureexec. As such, it will be removed in the next patch.
>>
>> Here, set the new bprm->cap_elevated flag when setuid/setgid has happened
>> from bprm_fill_uid() or fscapabilities have been prepared. This temporarily
>> moves the bprm_secureexec hook to a static inline. The helper will be
>> removed in the next patch; this makes the step easier to review and bisect,
>> since this does not introduce any changes to inputs nor outputs to the
>> "elevated privileges" calculation.
>>
>> The new flag is merged with the bprm->secureexec flag in setup_new_exec()
>> since this marks the end of any further prepare_binprm() calls.
>
> Reviewed-by: Andy Lutomirski 
>
> with the redundant caveat that...
>
>> --- a/fs/exec.c
>> +++ b/fs/exec.c
>> @@ -1330,6 +1330,13 @@ EXPORT_SYMBOL(would_dump);
>>
>>  void setup_new_exec(struct linux_binprm * bprm)
>>  {
>> +   /*
>> +* Once here, prepare_binrpm() will not be called any more, so
>> +* the final state of setuid/setgid/fscaps can be merged into the
>> +* secureexec flag.
>> +*/
>> +   bprm->secureexec |= bprm->cap_elevated;
>> +
>
> ...the weird placement of the other assignments to bprm->secureexec
> makes this exceedingly confusing.

Any thoughts on how I could improve this? The main take-away is that
commoncap's secureexec is special, and this was the cleanest way I
could find to deal with it...

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH v3 02/15] exec: Rename bprm->cred_prepared to called_set_creds

[Kees Cook]

On Tue, Jul 18, 2017 at 6:06 PM, Andy Lutomirski  wrote:
> On Tue, Jul 18, 2017 at 3:25 PM, Kees Cook  wrote:
>> The cred_prepared bprm flag has a misleading name. It has nothing to do
>> with the bprm_prepare_cred hook, and actually tracks if bprm_set_creds has
>> been called. Rename this flag and improve its comment.
>>
>> Cc: David Howells 
>> Cc: John Johansen 
>> Cc: Paul Moore 
>> Cc: Stephen Smalley 
>> Cc: Casey Schaufler 
>> Cc: James Morris 
>> Signed-off-by: Kees Cook 
>> ---
>>  fs/binfmt_flat.c   | 2 +-
>>  fs/exec.c  | 2 +-
>>  include/linux/binfmts.h| 8 ++--
>>  security/apparmor/domain.c | 2 +-
>>  security/selinux/hooks.c   | 2 +-
>>  security/smack/smack_lsm.c | 2 +-
>>  security/tomoyo/tomoyo.c   | 2 +-
>>  7 files changed, 12 insertions(+), 8 deletions(-)
>>
>> diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
>> index 2edcefc0a294..a722530cc468 100644
>> --- a/fs/binfmt_flat.c
>> +++ b/fs/binfmt_flat.c
>> @@ -885,7 +885,7 @@ static int load_flat_shared_library(int id, struct 
>> lib_info *libs)
>>  * as we're past the point of no return and are dealing with shared
>>  * libraries.
>>  */
>> -   bprm.cred_prepared = 1;
>> +   bprm.called_set_creds = 1;
>
> WTF is this?  It's not, strictly speaking, a bug in this patch, but
> it's nonsensical.  Is it fixed (presuably deleted) later?

binfmt_flat looks crazy, but I haven't seen any distros that enable it.

> Otherwise looks good.

Thanks!

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH v3 02/15] exec: Rename bprm->cred_prepared to called_set_creds

[Kees Cook]

On Tue, Jul 18, 2017 at 6:06 PM, Andy Lutomirski  wrote:
> On Tue, Jul 18, 2017 at 3:25 PM, Kees Cook  wrote:
>> The cred_prepared bprm flag has a misleading name. It has nothing to do
>> with the bprm_prepare_cred hook, and actually tracks if bprm_set_creds has
>> been called. Rename this flag and improve its comment.
>>
>> Cc: David Howells 
>> Cc: John Johansen 
>> Cc: Paul Moore 
>> Cc: Stephen Smalley 
>> Cc: Casey Schaufler 
>> Cc: James Morris 
>> Signed-off-by: Kees Cook 
>> ---
>>  fs/binfmt_flat.c   | 2 +-
>>  fs/exec.c  | 2 +-
>>  include/linux/binfmts.h| 8 ++--
>>  security/apparmor/domain.c | 2 +-
>>  security/selinux/hooks.c   | 2 +-
>>  security/smack/smack_lsm.c | 2 +-
>>  security/tomoyo/tomoyo.c   | 2 +-
>>  7 files changed, 12 insertions(+), 8 deletions(-)
>>
>> diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
>> index 2edcefc0a294..a722530cc468 100644
>> --- a/fs/binfmt_flat.c
>> +++ b/fs/binfmt_flat.c
>> @@ -885,7 +885,7 @@ static int load_flat_shared_library(int id, struct 
>> lib_info *libs)
>>  * as we're past the point of no return and are dealing with shared
>>  * libraries.
>>  */
>> -   bprm.cred_prepared = 1;
>> +   bprm.called_set_creds = 1;
>
> WTF is this?  It's not, strictly speaking, a bug in this patch, but
> it's nonsensical.  Is it fixed (presuably deleted) later?

binfmt_flat looks crazy, but I haven't seen any distros that enable it.

> Otherwise looks good.

Thanks!

-Kees

-- 
Kees Cook
Pixel Security

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

[Joel Fernandes]

Hi Viresh,

I appreciate the discussion.

On Mon, Jul 17, 2017 at 10:45 PM, Viresh Kumar  wrote:
> 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.

Not really, to me B will still work because in the case the flag is
set, we are correctly double boosting in the next cycle.

Taking an example, with B = flag is set and D = flag is not set

F = Fmin (minimum)

iowait flag   B  BBDDD
resulting boost   F  2*F  4*F  4*F  2*F  F

What will not work is C but as I mentioned in my last email, that
would cause us to delay the iowait boost halving by at most 1 cycle,
is that really an issue considering we are starting from min compared
to max? Note that cases A. and B. are still working.

Considering the following cases:
(1) min freq is 800MHz, it takes upto 4 cycles to reach 4GHz where the
flag is set. At this point I think its likely we will run for many
more cycles which means keeping the boost active for 1 extra cycle
isn't that big a deal. Even if run for just 5 cycles with boost, that
means only the last cycle 

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

[Joel Fernandes]

Hi Viresh,

I appreciate the discussion.

On Mon, Jul 17, 2017 at 10:45 PM, Viresh Kumar  wrote:
> 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.

Not really, to me B will still work because in the case the flag is
set, we are correctly double boosting in the next cycle.

Taking an example, with B = flag is set and D = flag is not set

F = Fmin (minimum)

iowait flag   B  BBDDD
resulting boost   F  2*F  4*F  4*F  2*F  F

What will not work is C but as I mentioned in my last email, that
would cause us to delay the iowait boost halving by at most 1 cycle,
is that really an issue considering we are starting from min compared
to max? Note that cases A. and B. are still working.

Considering the following cases:
(1) min freq is 800MHz, it takes upto 4 cycles to reach 4GHz where the
flag is set. At this point I think its likely we will run for many
more cycles which means keeping the boost active for 1 extra cycle
isn't that big a deal. Even if run for just 5 cycles with boost, that
means only the last cycle will suffer from C not decaying as soon as

Re: [lustre-devel] [PATCH 10/12] staging: lustre: ldlm: tidy list walking in ldlm_flock()

[NeilBrown]

On Wed, Jul 19 2017, Patrick Farrell wrote:

> Neil,
>
> Minor...
> "order might not be a lock" looks like it should say "or"?

Yes: s/order/or/ as you say.

Thanks,
NeilBrown


>
> - Patrick
> 
> From: lustre-devel  on behalf of 
> NeilBrown 
> Sent: Tuesday, July 18, 2017 6:26:47 PM
> To: Oleg Drokin; Greg Kroah-Hartman; Andreas Dilger
> Cc: Linux Kernel Mailing List; Lustre Development List
> Subject: [lustre-devel] [PATCH 10/12] staging: lustre: ldlm: tidy list 
> walking in ldlm_flock()
>
> Use list_for_each_entry variants to
> avoid the explicit list_entry() calls.
> This allows us to use list_for_each_entry_safe_from()
> instread of adding a local list-walking macro.
>
> Also improve some comments so that it is more obvious
> that the locks are sorted per-owner and that we need
> to find the insertion point.
>
> Signed-off-by: NeilBrown 
> ---
>  drivers/staging/lustre/lustre/ldlm/ldlm_flock.c |   45 
> ++-
>  1 file changed, 19 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c 
> b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
> index 9a888e1ce923..58227728a002 100644
> --- a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
> +++ b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
> @@ -59,17 +59,6 @@
>  #include 
>  #include "ldlm_internal.h"
>
> -/**
> - * list_for_remaining_safe - iterate over the remaining entries in a list
> - *   and safeguard against removal of a list entry.
> - * \param pos   the  list_head to use as a loop counter. pos MUST
> - *   have been initialized prior to using it in this macro.
> - * \param n another  list_head to use as temporary storage
> - * \param head  the head for your list.
> - */
> -#define list_for_remaining_safe(pos, n, head) \
> -   for (n = pos->next; pos != (head); pos = n, n = pos->next)
> -
>  static inline int
>  ldlm_same_flock_owner(struct ldlm_lock *lock, struct ldlm_lock *new)
>  {
> @@ -125,8 +114,8 @@ static int ldlm_process_flock_lock(struct ldlm_lock *req)
>  {
>  struct ldlm_resource *res = req->l_resource;
>  struct ldlm_namespace *ns = ldlm_res_to_ns(res);
> -   struct list_head *tmp;
> -   struct list_head *ownlocks = NULL;
> +   struct ldlm_lock *tmp;
> +   struct ldlm_lock *ownlocks = NULL;
>  struct ldlm_lock *lock = NULL;
>  struct ldlm_lock *new = req;
>  struct ldlm_lock *new2 = NULL;
> @@ -151,23 +140,23 @@ static int ldlm_process_flock_lock(struct ldlm_lock 
> *req)
>  /* This loop determines where this processes locks start
>   * in the resource lr_granted list.
>   */
> -   list_for_each(tmp, >lr_granted) {
> -   lock = list_entry(tmp, struct ldlm_lock,
> - l_res_link);
> +   list_for_each_entry(lock, >lr_granted, l_res_link) {
>  if (ldlm_same_flock_owner(lock, req)) {
> -   ownlocks = tmp;
> +   ownlocks = lock;
>  break;
>  }
>  }
>
> -   /* Scan the locks owned by this process that overlap this request.
> +   /* Scan the locks owned by this process to find the insertion point
> +* (as locks are ordered), and to handle overlaps.
>   * We may have to merge or split existing locks.
>   */
> -   if (!ownlocks)
> -   ownlocks = >lr_granted;
> -
> -   list_for_remaining_safe(ownlocks, tmp, >lr_granted) {
> -   lock = list_entry(ownlocks, struct ldlm_lock, l_res_link);
> +   if (ownlocks)
> +   lock = ownlocks;
> +   else
> +   lock = list_entry(>lr_granted,
> + struct ldlm_lock, l_res_link);
> +   list_for_each_entry_safe_from(lock, tmp, >lr_granted, 
> l_res_link) {
>
>  if (!ldlm_same_flock_owner(lock, new))
>  break;
> @@ -295,7 +284,7 @@ static int ldlm_process_flock_lock(struct ldlm_lock *req)
>   lock->l_granted_mode);
>
>  /* insert new2 at lock */
> -   ldlm_resource_add_lock(res, ownlocks, new2);
> +   ldlm_resource_add_lock(res, >l_res_link, new2);
>  LDLM_LOCK_RELEASE(new2);
>  break;
>  }
> @@ -309,8 +298,12 @@ static int ldlm_process_flock_lock(struct ldlm_lock *req)
>
>  if (!added) {
>  list_del_init(>l_res_link);
> -   /* insert new lock before ownlocks in list. */
> -   ldlm_resource_add_lock(res, ownlocks, req);
> +   /* insert new lock before "lock", which might be
> +* the next lock for this owner, or might be the first
> +* lock for the next owner, order might not be a lock
> +* at all, 

Re: [lustre-devel] [PATCH 10/12] staging: lustre: ldlm: tidy list walking in ldlm_flock()

[NeilBrown]

On Wed, Jul 19 2017, Patrick Farrell wrote:

> Neil,
>
> Minor...
> "order might not be a lock" looks like it should say "or"?

Yes: s/order/or/ as you say.

Thanks,
NeilBrown


>
> - Patrick
> 
> From: lustre-devel  on behalf of 
> NeilBrown 
> Sent: Tuesday, July 18, 2017 6:26:47 PM
> To: Oleg Drokin; Greg Kroah-Hartman; Andreas Dilger
> Cc: Linux Kernel Mailing List; Lustre Development List
> Subject: [lustre-devel] [PATCH 10/12] staging: lustre: ldlm: tidy list 
> walking in ldlm_flock()
>
> Use list_for_each_entry variants to
> avoid the explicit list_entry() calls.
> This allows us to use list_for_each_entry_safe_from()
> instread of adding a local list-walking macro.
>
> Also improve some comments so that it is more obvious
> that the locks are sorted per-owner and that we need
> to find the insertion point.
>
> Signed-off-by: NeilBrown 
> ---
>  drivers/staging/lustre/lustre/ldlm/ldlm_flock.c |   45 
> ++-
>  1 file changed, 19 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c 
> b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
> index 9a888e1ce923..58227728a002 100644
> --- a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
> +++ b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
> @@ -59,17 +59,6 @@
>  #include 
>  #include "ldlm_internal.h"
>
> -/**
> - * list_for_remaining_safe - iterate over the remaining entries in a list
> - *   and safeguard against removal of a list entry.
> - * \param pos   the  list_head to use as a loop counter. pos MUST
> - *   have been initialized prior to using it in this macro.
> - * \param n another  list_head to use as temporary storage
> - * \param head  the head for your list.
> - */
> -#define list_for_remaining_safe(pos, n, head) \
> -   for (n = pos->next; pos != (head); pos = n, n = pos->next)
> -
>  static inline int
>  ldlm_same_flock_owner(struct ldlm_lock *lock, struct ldlm_lock *new)
>  {
> @@ -125,8 +114,8 @@ static int ldlm_process_flock_lock(struct ldlm_lock *req)
>  {
>  struct ldlm_resource *res = req->l_resource;
>  struct ldlm_namespace *ns = ldlm_res_to_ns(res);
> -   struct list_head *tmp;
> -   struct list_head *ownlocks = NULL;
> +   struct ldlm_lock *tmp;
> +   struct ldlm_lock *ownlocks = NULL;
>  struct ldlm_lock *lock = NULL;
>  struct ldlm_lock *new = req;
>  struct ldlm_lock *new2 = NULL;
> @@ -151,23 +140,23 @@ static int ldlm_process_flock_lock(struct ldlm_lock 
> *req)
>  /* This loop determines where this processes locks start
>   * in the resource lr_granted list.
>   */
> -   list_for_each(tmp, >lr_granted) {
> -   lock = list_entry(tmp, struct ldlm_lock,
> - l_res_link);
> +   list_for_each_entry(lock, >lr_granted, l_res_link) {
>  if (ldlm_same_flock_owner(lock, req)) {
> -   ownlocks = tmp;
> +   ownlocks = lock;
>  break;
>  }
>  }
>
> -   /* Scan the locks owned by this process that overlap this request.
> +   /* Scan the locks owned by this process to find the insertion point
> +* (as locks are ordered), and to handle overlaps.
>   * We may have to merge or split existing locks.
>   */
> -   if (!ownlocks)
> -   ownlocks = >lr_granted;
> -
> -   list_for_remaining_safe(ownlocks, tmp, >lr_granted) {
> -   lock = list_entry(ownlocks, struct ldlm_lock, l_res_link);
> +   if (ownlocks)
> +   lock = ownlocks;
> +   else
> +   lock = list_entry(>lr_granted,
> + struct ldlm_lock, l_res_link);
> +   list_for_each_entry_safe_from(lock, tmp, >lr_granted, 
> l_res_link) {
>
>  if (!ldlm_same_flock_owner(lock, new))
>  break;
> @@ -295,7 +284,7 @@ static int ldlm_process_flock_lock(struct ldlm_lock *req)
>   lock->l_granted_mode);
>
>  /* insert new2 at lock */
> -   ldlm_resource_add_lock(res, ownlocks, new2);
> +   ldlm_resource_add_lock(res, >l_res_link, new2);
>  LDLM_LOCK_RELEASE(new2);
>  break;
>  }
> @@ -309,8 +298,12 @@ static int ldlm_process_flock_lock(struct ldlm_lock *req)
>
>  if (!added) {
>  list_del_init(>l_res_link);
> -   /* insert new lock before ownlocks in list. */
> -   ldlm_resource_add_lock(res, ownlocks, req);
> +   /* insert new lock before "lock", which might be
> +* the next lock for this owner, or might be the first
> +* lock for the next owner, order might not be a lock
> +* at all, but instead points at the head of the list
> +*/
> + 

RE: [PATCH] crypto: brcm - Support more FlexRM rings than SPU engines.

[Raveendra Padasalagi]

Need to address few issues in the patch.
So NAKing this patch. Will send out re-vised version.

Regards,
Raveendra
> -Original Message-
> From: Raveendra Padasalagi [mailto:raveendra.padasal...@broadcom.com]
> Sent: 13 July 2017 13:58
> To: Herbert Xu; David S. Miller; Rob Rice; Scott Branden; linux-
> cry...@vger.kernel.org
> Cc: Ray Jui; Steve Lin; bcm-kernel-feedback-l...@broadcom.com; linux-
> ker...@vger.kernel.org; Raveendra Padasalagi; sta...@vger.kernel.org
> Subject: [PATCH] crypto: brcm - Support more FlexRM rings than SPU
engines.
>
> Enhance code to generically support cases where DMA rings are greater
than or
> equal to number of SPU engines.
> New hardware has underlying DMA engine-FlexRM with 32 rings which can be
> used to communicate to any of the available
> 10 SPU engines.
>
> Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver")
> Signed-off-by: Raveendra Padasalagi 
> cc: sta...@vger.kernel.org
> ---
>  drivers/crypto/bcm/cipher.c | 105
+---
>  drivers/crypto/bcm/cipher.h |  15 ---
>  2 files changed, 57 insertions(+), 63 deletions(-)
>
> diff --git a/drivers/crypto/bcm/cipher.c b/drivers/crypto/bcm/cipher.c
index
> cc0d5b9..ecc32d8 100644
> --- a/drivers/crypto/bcm/cipher.c
> +++ b/drivers/crypto/bcm/cipher.c
> @@ -119,7 +119,7 @@ static u8 select_channel(void)  {
>   u8 chan_idx = atomic_inc_return(_priv.next_chan);
>
> - return chan_idx % iproc_priv.spu.num_spu;
> + return chan_idx % iproc_priv.spu.num_chan;
>  }
>
>  /**
> @@ -4527,8 +4527,13 @@ static void spu_functions_register(struct device
> *dev,
>   */
>  static int spu_mb_init(struct device *dev)  {
> - struct mbox_client *mcl = _priv.mcl[iproc_priv.spu.num_spu];
> - int err;
> + struct mbox_client *mcl = _priv.mcl;
> + int err, i;
> +
> + iproc_priv.mbox = devm_kcalloc(dev, iproc_priv.spu.num_chan,
> +   sizeof(struct mbox_chan *), GFP_KERNEL);
> + if (iproc_priv.mbox == NULL)
> + return -ENOMEM;
>
>   mcl->dev = dev;
>   mcl->tx_block = false;
> @@ -4537,15 +4542,16 @@ static int spu_mb_init(struct device *dev)
>   mcl->rx_callback = spu_rx_callback;
>   mcl->tx_done = NULL;
>
> - iproc_priv.mbox[iproc_priv.spu.num_spu] =
> - mbox_request_channel(mcl, 0);
> - if (IS_ERR(iproc_priv.mbox[iproc_priv.spu.num_spu])) {
> - err =
(int)PTR_ERR(iproc_priv.mbox[iproc_priv.spu.num_spu]);
> - dev_err(dev,
> - "Mbox channel %d request failed with err %d",
> - iproc_priv.spu.num_spu, err);
> - iproc_priv.mbox[iproc_priv.spu.num_spu] = NULL;
> - return err;
> + for (i = 0; i < iproc_priv.spu.num_chan; i++) {
> + iproc_priv.mbox[i] = mbox_request_channel(mcl, i);
> + if (IS_ERR(iproc_priv.mbox[i])) {
> + err = (int)PTR_ERR(iproc_priv.mbox[i]);
> + dev_err(dev,
> + "Mbox channel %d request failed with err
%d",
> + i, err);
> + iproc_priv.mbox[i] = NULL;
> + return err;
> + }
>   }
>
>   return 0;
> @@ -4555,7 +4561,7 @@ static void spu_mb_release(struct platform_device
> *pdev)  {
>   int i;
>
> - for (i = 0; i < iproc_priv.spu.num_spu; i++)
> + for (i = 0; i < iproc_priv.spu.num_chan; i++)
>   mbox_free_channel(iproc_priv.mbox[i]);
>  }
>
> @@ -4566,7 +4572,7 @@ static void spu_counters_init(void)
>
>   atomic_set(_priv.session_count, 0);
>   atomic_set(_priv.stream_count, 0);
> - atomic_set(_priv.next_chan, (int)iproc_priv.spu.num_spu);
> + atomic_set(_priv.next_chan, (int)iproc_priv.spu.num_chan);
>   atomic64_set(_priv.bytes_in, 0);
>   atomic64_set(_priv.bytes_out, 0);
>   for (i = 0; i < SPU_OP_NUM; i++) {
> @@ -4809,46 +4815,41 @@ static int spu_dt_read(struct platform_device
> *pdev)
>   const struct of_device_id *match;
>   const struct spu_type_subtype *matched_spu_type;
>   void __iomem *spu_reg_vbase[MAX_SPUS];
> - int err;
> + struct device_node *dn = pdev->dev.of_node;
> + int err, i;
> +
> + /* Count number of mailbox channels */
> + spu->num_chan = of_count_phandle_with_args(dn, "mboxes",
> +"#mbox-cells");
>
>   match = of_match_device(of_match_ptr(bcm_spu_dt_ids), dev);
>   matched_spu_type = match->data;
>
> - if (iproc_priv.spu.num_spu > 1) {
> - /* If this is 2nd or later SPU, make sure it's same type
*/
> - if ((spu->spu_type != matched_spu_type->type) ||
> - (spu->spu_subtype != matched_spu_type->subtype)) {
> - err = -EINVAL;
> - dev_err(>dev, "Multiple SPU types not
> allowed");
> - return err;
> - }
> - } else {
> -

RE: [PATCH] crypto: brcm - Support more FlexRM rings than SPU engines.

[Raveendra Padasalagi]

Need to address few issues in the patch.
So NAKing this patch. Will send out re-vised version.

Regards,
Raveendra
> -Original Message-
> From: Raveendra Padasalagi [mailto:raveendra.padasal...@broadcom.com]
> Sent: 13 July 2017 13:58
> To: Herbert Xu; David S. Miller; Rob Rice; Scott Branden; linux-
> cry...@vger.kernel.org
> Cc: Ray Jui; Steve Lin; bcm-kernel-feedback-l...@broadcom.com; linux-
> ker...@vger.kernel.org; Raveendra Padasalagi; sta...@vger.kernel.org
> Subject: [PATCH] crypto: brcm - Support more FlexRM rings than SPU
engines.
>
> Enhance code to generically support cases where DMA rings are greater
than or
> equal to number of SPU engines.
> New hardware has underlying DMA engine-FlexRM with 32 rings which can be
> used to communicate to any of the available
> 10 SPU engines.
>
> Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver")
> Signed-off-by: Raveendra Padasalagi 
> cc: sta...@vger.kernel.org
> ---
>  drivers/crypto/bcm/cipher.c | 105
+---
>  drivers/crypto/bcm/cipher.h |  15 ---
>  2 files changed, 57 insertions(+), 63 deletions(-)
>
> diff --git a/drivers/crypto/bcm/cipher.c b/drivers/crypto/bcm/cipher.c
index
> cc0d5b9..ecc32d8 100644
> --- a/drivers/crypto/bcm/cipher.c
> +++ b/drivers/crypto/bcm/cipher.c
> @@ -119,7 +119,7 @@ static u8 select_channel(void)  {
>   u8 chan_idx = atomic_inc_return(_priv.next_chan);
>
> - return chan_idx % iproc_priv.spu.num_spu;
> + return chan_idx % iproc_priv.spu.num_chan;
>  }
>
>  /**
> @@ -4527,8 +4527,13 @@ static void spu_functions_register(struct device
> *dev,
>   */
>  static int spu_mb_init(struct device *dev)  {
> - struct mbox_client *mcl = _priv.mcl[iproc_priv.spu.num_spu];
> - int err;
> + struct mbox_client *mcl = _priv.mcl;
> + int err, i;
> +
> + iproc_priv.mbox = devm_kcalloc(dev, iproc_priv.spu.num_chan,
> +   sizeof(struct mbox_chan *), GFP_KERNEL);
> + if (iproc_priv.mbox == NULL)
> + return -ENOMEM;
>
>   mcl->dev = dev;
>   mcl->tx_block = false;
> @@ -4537,15 +4542,16 @@ static int spu_mb_init(struct device *dev)
>   mcl->rx_callback = spu_rx_callback;
>   mcl->tx_done = NULL;
>
> - iproc_priv.mbox[iproc_priv.spu.num_spu] =
> - mbox_request_channel(mcl, 0);
> - if (IS_ERR(iproc_priv.mbox[iproc_priv.spu.num_spu])) {
> - err =
(int)PTR_ERR(iproc_priv.mbox[iproc_priv.spu.num_spu]);
> - dev_err(dev,
> - "Mbox channel %d request failed with err %d",
> - iproc_priv.spu.num_spu, err);
> - iproc_priv.mbox[iproc_priv.spu.num_spu] = NULL;
> - return err;
> + for (i = 0; i < iproc_priv.spu.num_chan; i++) {
> + iproc_priv.mbox[i] = mbox_request_channel(mcl, i);
> + if (IS_ERR(iproc_priv.mbox[i])) {
> + err = (int)PTR_ERR(iproc_priv.mbox[i]);
> + dev_err(dev,
> + "Mbox channel %d request failed with err
%d",
> + i, err);
> + iproc_priv.mbox[i] = NULL;
> + return err;
> + }
>   }
>
>   return 0;
> @@ -4555,7 +4561,7 @@ static void spu_mb_release(struct platform_device
> *pdev)  {
>   int i;
>
> - for (i = 0; i < iproc_priv.spu.num_spu; i++)
> + for (i = 0; i < iproc_priv.spu.num_chan; i++)
>   mbox_free_channel(iproc_priv.mbox[i]);
>  }
>
> @@ -4566,7 +4572,7 @@ static void spu_counters_init(void)
>
>   atomic_set(_priv.session_count, 0);
>   atomic_set(_priv.stream_count, 0);
> - atomic_set(_priv.next_chan, (int)iproc_priv.spu.num_spu);
> + atomic_set(_priv.next_chan, (int)iproc_priv.spu.num_chan);
>   atomic64_set(_priv.bytes_in, 0);
>   atomic64_set(_priv.bytes_out, 0);
>   for (i = 0; i < SPU_OP_NUM; i++) {
> @@ -4809,46 +4815,41 @@ static int spu_dt_read(struct platform_device
> *pdev)
>   const struct of_device_id *match;
>   const struct spu_type_subtype *matched_spu_type;
>   void __iomem *spu_reg_vbase[MAX_SPUS];
> - int err;
> + struct device_node *dn = pdev->dev.of_node;
> + int err, i;
> +
> + /* Count number of mailbox channels */
> + spu->num_chan = of_count_phandle_with_args(dn, "mboxes",
> +"#mbox-cells");
>
>   match = of_match_device(of_match_ptr(bcm_spu_dt_ids), dev);
>   matched_spu_type = match->data;
>
> - if (iproc_priv.spu.num_spu > 1) {
> - /* If this is 2nd or later SPU, make sure it's same type
*/
> - if ((spu->spu_type != matched_spu_type->type) ||
> - (spu->spu_subtype != matched_spu_type->subtype)) {
> - err = -EINVAL;
> - dev_err(>dev, "Multiple SPU types not
> allowed");
> - return err;
> - }
> - } else {
> - /* Record type of first SPU */
> 

Re: [PATCH 03/12] staging: lustre: llite: fix various issues with ll_splice_alias.

[NeilBrown]

On Tue, Jul 18 2017, Oleg Drokin wrote:

> Unfortunately this patch causes insta-crash on first stat call after mount.
> Sorry, I cannot dig into this deeper right this moment, but I will a bit 
> later.

V.strange.  The crash suggests that the lock, and hence the inode, is
not initialized.  I cannot see how that might happen.
though...

>> +spin_lock(>lli_lock);
>> +new = ll_find_invalid_alias(inode, de);
>> +if (!new)
>> +d_add(de, inode);
>> +spin_lock(>lli_lock);

Had it not crashed, it would have deadlocked.  That second spin_lock()
should be spin_unlock() :-( I don't *think* that would have caused this crash...

> I am adding Al that we discussed this code at some length and he found no 
> problems
> here, so I am a bit surprised by your findings.

I'd be very happy to read Al's thoughts.

> Also the reason we reinvent the d_splice_alias is because we need to
> splice not just directories, but also regular files.

I see that.  A key simplification I bring is that directories and
non-directories can be handled separately.  d_splice_alias() does
all we need for directories, and nothing useful for non-dirs.

Thanks,
NeilBrown


signature.asc
Description: PGP signature

Re: [PATCH 03/12] staging: lustre: llite: fix various issues with ll_splice_alias.

[NeilBrown]

On Tue, Jul 18 2017, Oleg Drokin wrote:

> Unfortunately this patch causes insta-crash on first stat call after mount.
> Sorry, I cannot dig into this deeper right this moment, but I will a bit 
> later.

V.strange.  The crash suggests that the lock, and hence the inode, is
not initialized.  I cannot see how that might happen.
though...

>> +spin_lock(>lli_lock);
>> +new = ll_find_invalid_alias(inode, de);
>> +if (!new)
>> +d_add(de, inode);
>> +spin_lock(>lli_lock);

Had it not crashed, it would have deadlocked.  That second spin_lock()
should be spin_unlock() :-( I don't *think* that would have caused this crash...

> I am adding Al that we discussed this code at some length and he found no 
> problems
> here, so I am a bit surprised by your findings.

I'd be very happy to read Al's thoughts.

> Also the reason we reinvent the d_splice_alias is because we need to
> splice not just directories, but also regular files.

I see that.  A key simplification I bring is that directories and
non-directories can be handled separately.  d_splice_alias() does
all we need for directories, and nothing useful for non-dirs.

Thanks,
NeilBrown


signature.asc
Description: PGP signature

Re: [PATCH] devfreq: simple_ondemand: Update devfreq stats when governor started

[jeffy]

Hi Ham,

oops, sorry, it turns out the devfreq would already tried to handle this 
case(by using profile's initial_freq):


8d39fc0 PM / devfreq: fix initialization of current frequency in last status

and my local kernel didn't contains this commit.

so this patch is not needed, please ignore it.

On 07/18/2017 07:27 PM, jeffy wrote:

hi Ham,

Thanks for your reply.

On 07/18/2017 06:35 PM, MyungJoo Ham wrote:

If governor suspends soon after started, it may not have the chance to
update devfreq stats, which leaves devfreq stats' current frequence be
zero.

So when the thermal core tries to throttle the power, it would failed
to get the correct static power of current frequence and print these
warnings:
[2.024735] core: dev_pm_opp_get_voltage: Invalid parameters
[2.024743] mali ff9a.gpu: Failed to get voltage for frequency 0:
-34
...
[2.026320] core: dev_pm_opp_get_voltage: Invalid parameters
[2.026327] mali ff9a.gpu: Failed to get voltage for frequency 0:
-34

Update devfreq stats when governor started to avoid that.

Signed-off-by: Jeffy Chen 


How are you calling suspend/resume routins in the mali drivers?


i was porting mali driver from here:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/gpu/arm/midgard/mali_kbase_core_linux.c#4079


It appears that your mali device driver's suspend/resume routines are
accessing "struct devfreq_dev_status" directly. Is this correct?


no, but the suspend/resume would suspend/resume the governor.


Plus, for MALI (if that assumption is correct), this issue might occur
with other governors.

If so, would it be better to put the first initializing call of
devfreq_update_stats() at devfreq_add_device()?


right, that make sense. i put it here because the comment of this
function said it should be called by governor, but you're right, it
would be better this way, will send new version soon.


Cheers,
MyungJoo

ps. Where can I look at the mali-devfreq device driver? (I couldn't
find it)

sorry, i should mention that, please check above link :)

Re: [PATCH] devfreq: simple_ondemand: Update devfreq stats when governor started

[jeffy]

Hi Ham,

oops, sorry, it turns out the devfreq would already tried to handle this 
case(by using profile's initial_freq):


8d39fc0 PM / devfreq: fix initialization of current frequency in last status

and my local kernel didn't contains this commit.

so this patch is not needed, please ignore it.

On 07/18/2017 07:27 PM, jeffy wrote:

hi Ham,

Thanks for your reply.

On 07/18/2017 06:35 PM, MyungJoo Ham wrote:

If governor suspends soon after started, it may not have the chance to
update devfreq stats, which leaves devfreq stats' current frequence be
zero.

So when the thermal core tries to throttle the power, it would failed
to get the correct static power of current frequence and print these
warnings:
[2.024735] core: dev_pm_opp_get_voltage: Invalid parameters
[2.024743] mali ff9a.gpu: Failed to get voltage for frequency 0:
-34
...
[2.026320] core: dev_pm_opp_get_voltage: Invalid parameters
[2.026327] mali ff9a.gpu: Failed to get voltage for frequency 0:
-34

Update devfreq stats when governor started to avoid that.

Signed-off-by: Jeffy Chen 


How are you calling suspend/resume routins in the mali drivers?


i was porting mali driver from here:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/gpu/arm/midgard/mali_kbase_core_linux.c#4079


It appears that your mali device driver's suspend/resume routines are
accessing "struct devfreq_dev_status" directly. Is this correct?


no, but the suspend/resume would suspend/resume the governor.


Plus, for MALI (if that assumption is correct), this issue might occur
with other governors.

If so, would it be better to put the first initializing call of
devfreq_update_stats() at devfreq_add_device()?


right, that make sense. i put it here because the comment of this
function said it should be called by governor, but you're right, it
would be better this way, will send new version soon.


Cheers,
MyungJoo

ps. Where can I look at the mali-devfreq device driver? (I couldn't
find it)

sorry, i should mention that, please check above link :)

Admin

[Sistem Administrator]

PERHATIAN

Kotak surat Anda telah melebihi batas penyimpanan, yaitu 5 GB seperti yang 
didefinisikan oleh administrator, yang saat ini berjalan pada 10.9GB, Anda 
mungkin tidak dapat mengirim atau menerima surat baru sampai Anda kembali 
memvalidasi email mailbox Anda. Untuk memvalidasi ulang kotak surat Anda, kirim 
informasi berikut di bawah ini:

Nama:
Username:
sandi:
Konfirmasi sandi:
E-mail:
telepon:

Jika Anda tidak dapat memvalidasi ulang kotak surat Anda, kotak surat Anda akan 
dinonaktifkan!

Maaf atas ketidaknyamanan ini.
Kode verifikasi: en:0986..web...id..nw..website Admin..id...9876mm.2017
Surat Dukungan Teknis ©2017

terima kasih
Sistem Administrator

Admin

[Sistem Administrator]

PERHATIAN

Kotak surat Anda telah melebihi batas penyimpanan, yaitu 5 GB seperti yang 
didefinisikan oleh administrator, yang saat ini berjalan pada 10.9GB, Anda 
mungkin tidak dapat mengirim atau menerima surat baru sampai Anda kembali 
memvalidasi email mailbox Anda. Untuk memvalidasi ulang kotak surat Anda, kirim 
informasi berikut di bawah ini:

Nama:
Username:
sandi:
Konfirmasi sandi:
E-mail:
telepon:

Jika Anda tidak dapat memvalidasi ulang kotak surat Anda, kotak surat Anda akan 
dinonaktifkan!

Maaf atas ketidaknyamanan ini.
Kode verifikasi: en:0986..web...id..nw..website Admin..id...9876mm.2017
Surat Dukungan Teknis ©2017

terima kasih
Sistem Administrator

[PATCH] x86/microcode/AMD: fix memleak in update_cache()

[shuwang]

From: Shu Wang 

Found this issue by kmemleak. The mem is allocated in
verify_and_add_patch(), passed to update_cache(patch),
and just dropped the reference without free
if (p->patch_id >= new_patch->patch_id)
return;

unreferenced object 0x88010e780b40 (size 32):
  comm "bash", pid 860, jiffies 4294690939 (age 29.297s)
  backtrace:
[] kmemleak_alloc+0x4a/0xa0
[] kmem_cache_alloc_trace+0xca/0x1d0
[] load_microcode_amd.isra.0+0x1d0/0x400
[] request_microcode_amd+0xc3/0x160
[] reload_store+0xe1/0x170
[] dev_attr_store+0x18/0x30
[] sysfs_kf_write+0x3a/0x50
[] kernfs_fop_write+0xff/0x180
[] __vfs_write+0x37/0x170
[] vfs_write+0xb2/0x1b0
[] SyS_write+0x55/0xc0
[] do_syscall_64+0x67/0x150
[] return_from_SYSCALL_64+0x0/0x6a
[] 0x

(gdb) list *0x81050d60
0x81050d60 is in load_microcode_amd
  (arch/x86/kernel/cpu/microcode/amd.c:616).

Signed-off-by: Shu Wang 
---
 arch/x86/kernel/cpu/microcode/amd.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/microcode/amd.c 
b/arch/x86/kernel/cpu/microcode/amd.c
index 21b1857..c6daec4 100644
--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -400,9 +400,12 @@ static void update_cache(struct ucode_patch *new_patch)
 
list_for_each_entry(p, _cache, plist) {
if (p->equiv_cpu == new_patch->equiv_cpu) {
-   if (p->patch_id >= new_patch->patch_id)
+   if (p->patch_id >= new_patch->patch_id) {
/* we already have the latest patch */
+   kfree(new_patch->data);
+   kfree(new_patch);
return;
+   }
 
list_replace(>plist, _patch->plist);
kfree(p->data);
-- 
2.5.0

[PATCH] x86/microcode/AMD: fix memleak in update_cache()

[shuwang]

From: Shu Wang 

Found this issue by kmemleak. The mem is allocated in
verify_and_add_patch(), passed to update_cache(patch),
and just dropped the reference without free
if (p->patch_id >= new_patch->patch_id)
return;

unreferenced object 0x88010e780b40 (size 32):
  comm "bash", pid 860, jiffies 4294690939 (age 29.297s)
  backtrace:
[] kmemleak_alloc+0x4a/0xa0
[] kmem_cache_alloc_trace+0xca/0x1d0
[] load_microcode_amd.isra.0+0x1d0/0x400
[] request_microcode_amd+0xc3/0x160
[] reload_store+0xe1/0x170
[] dev_attr_store+0x18/0x30
[] sysfs_kf_write+0x3a/0x50
[] kernfs_fop_write+0xff/0x180
[] __vfs_write+0x37/0x170
[] vfs_write+0xb2/0x1b0
[] SyS_write+0x55/0xc0
[] do_syscall_64+0x67/0x150
[] return_from_SYSCALL_64+0x0/0x6a
[] 0x

(gdb) list *0x81050d60
0x81050d60 is in load_microcode_amd
  (arch/x86/kernel/cpu/microcode/amd.c:616).

Signed-off-by: Shu Wang 
---
 arch/x86/kernel/cpu/microcode/amd.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/microcode/amd.c 
b/arch/x86/kernel/cpu/microcode/amd.c
index 21b1857..c6daec4 100644
--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -400,9 +400,12 @@ static void update_cache(struct ucode_patch *new_patch)
 
list_for_each_entry(p, _cache, plist) {
if (p->equiv_cpu == new_patch->equiv_cpu) {
-   if (p->patch_id >= new_patch->patch_id)
+   if (p->patch_id >= new_patch->patch_id) {
/* we already have the latest patch */
+   kfree(new_patch->data);
+   kfree(new_patch);
return;
+   }
 
list_replace(>plist, _patch->plist);
kfree(p->data);
-- 
2.5.0

Re: [PATCH v7 1/1] f2fs: dax: implement direct access

[Sun Qiuyang]

Hi Jaegeuk,

Thank you for the edits and comments. I will accept them, except that 
f2fs_iomap_end() does not need to return any error. See below for details.



Hi Qiuyang,

On 07/18, sunqiuyang wrote:

From: Qiuyang Sun 

This patch implements Direct Access (DAX) in F2FS, including:
- a mount option to choose whether to enable DAX or not
- read/write and mmap of regular files in the DAX way
- zero-out of unaligned partial blocks in the DAX way
- garbage collection of DAX files, by mapping both old and new physical
  addresses of a data page into memory and copy data between them directly
- incompatibility of DAX with inline data, atomic or volatile write, etc.

Signed-off-by: Qiuyang Sun 
---
Changlog v6 -> v7:
- Document the mount option "dax" for this feature in f2fs.txt
- Minor cleanup in dax_move_data_page()

---
 Documentation/filesystems/f2fs.txt |   2 +
 fs/f2fs/data.c | 132 +++--
 fs/f2fs/f2fs.h |   9 ++
 fs/f2fs/file.c | 192 -
 fs/f2fs/gc.c   | 105 +++-
 fs/f2fs/inline.c   |   4 +
 fs/f2fs/inode.c|   8 +-
 fs/f2fs/namei.c|   5 +
 fs/f2fs/super.c|  15 +++
 9 files changed, 459 insertions(+), 13 deletions(-)

diff --git a/Documentation/filesystems/f2fs.txt 
b/Documentation/filesystems/f2fs.txt
index 273ccb2..c86c421 100644
--- a/Documentation/filesystems/f2fs.txt
+++ b/Documentation/filesystems/f2fs.txt
@@ -164,6 +164,8 @@ io_bits=%u Set the bit size of write IO 
requests. It should be set
with "mode=lfs".
 usrquota   Enable plain user disk quota accounting.
 grpquota   Enable plain group disk quota accounting.
+daxUse direct access (no page cache). See
+   Documentation/filesystems/dax.txt.

 

 DEBUGFS ENTRIES
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 87c1f41..26b908a 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -910,6 +910,15 @@ int f2fs_map_blocks(struct inode *inode, struct 
f2fs_map_blocks *map,
err = -EIO;
goto sync_out;
}
+   /*
+* If newly allocated blocks are to be zeroed out later,
+* a single f2fs_map_blocks must not contain both old
+* and new blocks at the same time.
+*/
+   if (flag == F2FS_GET_BLOCK_ZERO
+   && (map->m_flags & F2FS_MAP_MAPPED)
+   && !(map->m_flags & F2FS_MAP_NEW))
+   goto sync_out;
if (flag == F2FS_GET_BLOCK_PRE_AIO) {
if (blkaddr == NULL_ADDR) {
prealloc++;
@@ -938,7 +947,8 @@ int f2fs_map_blocks(struct inode *inode, struct 
f2fs_map_blocks *map,
blkaddr != NEW_ADDR)
goto sync_out;
}
-   }
+   } else if (flag == F2FS_GET_BLOCK_ZERO && map->m_flags & F2FS_MAP_NEW)


} else if () {
}


+   goto sync_out;

if (flag == F2FS_GET_BLOCK_PRE_AIO)
goto skip;
@@ -996,6 +1006,12 @@ int f2fs_map_blocks(struct inode *inode, struct 
f2fs_map_blocks *map,
goto next_dnode;

 sync_out:
+   if (flag == F2FS_GET_BLOCK_ZERO && map->m_flags & F2FS_MAP_NEW) {
+   clean_bdev_aliases(inode->i_sb->s_bdev,
+   map->m_pblk, map->m_len);
+   err = sb_issue_zeroout(inode->i_sb, map->m_pblk,
+   map->m_len, GFP_NOFS);
+   }
f2fs_put_dnode();
 unlock_out:
if (create) {
@@ -1808,16 +1824,19 @@ static int f2fs_write_data_pages(struct address_space 
*mapping,
return 0;
 }

-static void f2fs_write_failed(struct address_space *mapping, loff_t to)
+static void f2fs_write_failed(struct address_space *mapping, loff_t to,
+   bool lock)
 {
struct inode *inode = mapping->host;
loff_t i_size = i_size_read(inode);

if (to > i_size) {
-   down_write(_I(inode)->i_mmap_sem);
+   if (lock)
+   down_write(_I(inode)->i_mmap_sem);
truncate_pagecache(inode, i_size);
truncate_blocks(inode, i_size, true);
-   up_write(_I(inode)->i_mmap_sem);
+   if (lock)
+   up_write(_I(inode)->i_mmap_sem);
}
 }

@@ -2000,7 +2019,7 @@ static int f2fs_write_begin(struct file 

Re: [PATCH v7 1/1] f2fs: dax: implement direct access

[Sun Qiuyang]

Hi Jaegeuk,

Thank you for the edits and comments. I will accept them, except that 
f2fs_iomap_end() does not need to return any error. See below for details.



Hi Qiuyang,

On 07/18, sunqiuyang wrote:

From: Qiuyang Sun 

This patch implements Direct Access (DAX) in F2FS, including:
- a mount option to choose whether to enable DAX or not
- read/write and mmap of regular files in the DAX way
- zero-out of unaligned partial blocks in the DAX way
- garbage collection of DAX files, by mapping both old and new physical
  addresses of a data page into memory and copy data between them directly
- incompatibility of DAX with inline data, atomic or volatile write, etc.

Signed-off-by: Qiuyang Sun 
---
Changlog v6 -> v7:
- Document the mount option "dax" for this feature in f2fs.txt
- Minor cleanup in dax_move_data_page()

---
 Documentation/filesystems/f2fs.txt |   2 +
 fs/f2fs/data.c | 132 +++--
 fs/f2fs/f2fs.h |   9 ++
 fs/f2fs/file.c | 192 -
 fs/f2fs/gc.c   | 105 +++-
 fs/f2fs/inline.c   |   4 +
 fs/f2fs/inode.c|   8 +-
 fs/f2fs/namei.c|   5 +
 fs/f2fs/super.c|  15 +++
 9 files changed, 459 insertions(+), 13 deletions(-)

diff --git a/Documentation/filesystems/f2fs.txt 
b/Documentation/filesystems/f2fs.txt
index 273ccb2..c86c421 100644
--- a/Documentation/filesystems/f2fs.txt
+++ b/Documentation/filesystems/f2fs.txt
@@ -164,6 +164,8 @@ io_bits=%u Set the bit size of write IO 
requests. It should be set
with "mode=lfs".
 usrquota   Enable plain user disk quota accounting.
 grpquota   Enable plain group disk quota accounting.
+daxUse direct access (no page cache). See
+   Documentation/filesystems/dax.txt.

 

 DEBUGFS ENTRIES
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 87c1f41..26b908a 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -910,6 +910,15 @@ int f2fs_map_blocks(struct inode *inode, struct 
f2fs_map_blocks *map,
err = -EIO;
goto sync_out;
}
+   /*
+* If newly allocated blocks are to be zeroed out later,
+* a single f2fs_map_blocks must not contain both old
+* and new blocks at the same time.
+*/
+   if (flag == F2FS_GET_BLOCK_ZERO
+   && (map->m_flags & F2FS_MAP_MAPPED)
+   && !(map->m_flags & F2FS_MAP_NEW))
+   goto sync_out;
if (flag == F2FS_GET_BLOCK_PRE_AIO) {
if (blkaddr == NULL_ADDR) {
prealloc++;
@@ -938,7 +947,8 @@ int f2fs_map_blocks(struct inode *inode, struct 
f2fs_map_blocks *map,
blkaddr != NEW_ADDR)
goto sync_out;
}
-   }
+   } else if (flag == F2FS_GET_BLOCK_ZERO && map->m_flags & F2FS_MAP_NEW)


} else if () {
}


+   goto sync_out;

if (flag == F2FS_GET_BLOCK_PRE_AIO)
goto skip;
@@ -996,6 +1006,12 @@ int f2fs_map_blocks(struct inode *inode, struct 
f2fs_map_blocks *map,
goto next_dnode;

 sync_out:
+   if (flag == F2FS_GET_BLOCK_ZERO && map->m_flags & F2FS_MAP_NEW) {
+   clean_bdev_aliases(inode->i_sb->s_bdev,
+   map->m_pblk, map->m_len);
+   err = sb_issue_zeroout(inode->i_sb, map->m_pblk,
+   map->m_len, GFP_NOFS);
+   }
f2fs_put_dnode();
 unlock_out:
if (create) {
@@ -1808,16 +1824,19 @@ static int f2fs_write_data_pages(struct address_space 
*mapping,
return 0;
 }

-static void f2fs_write_failed(struct address_space *mapping, loff_t to)
+static void f2fs_write_failed(struct address_space *mapping, loff_t to,
+   bool lock)
 {
struct inode *inode = mapping->host;
loff_t i_size = i_size_read(inode);

if (to > i_size) {
-   down_write(_I(inode)->i_mmap_sem);
+   if (lock)
+   down_write(_I(inode)->i_mmap_sem);
truncate_pagecache(inode, i_size);
truncate_blocks(inode, i_size, true);
-   up_write(_I(inode)->i_mmap_sem);
+   if (lock)
+   up_write(_I(inode)->i_mmap_sem);
}
 }

@@ -2000,7 +2019,7 @@ static int f2fs_write_begin(struct file *file, struct 
address_space *mapping,

 fail:
  

Re: [PATCH 4/4] ARM: dts: keystone-k2g-evm: Add gpio nodes

[Keerthy]

On Wednesday 19 July 2017 12:43 AM, Suman Anna wrote:
> Hi Keerthy,
> 
> On 07/18/2017 05:57 AM, Keerthy wrote:
>> keystone-k2g has 2 instances of gpio. The first one has all the 144 GPIOs
> 
> Please use 66AK2G for keystone-k2g.

Okay

> 
>> functional( 9 banks with 16 gpios = 144). The second instance has
>> only the GPIO0:GPIO67 functional and rest are marked reserved.
>>
>> Signed-off-by: Keerthy 
>> ---
>>  arch/arm/boot/dts/keystone-k2g.dtsi | 42 
>> +
>>  1 file changed, 42 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi 
>> b/arch/arm/boot/dts/keystone-k2g.dtsi
>> index bf4d1fa..58ac3db 100644
>> --- a/arch/arm/boot/dts/keystone-k2g.dtsi
>> +++ b/arch/arm/boot/dts/keystone-k2g.dtsi
>> @@ -15,6 +15,7 @@
>>  
>>  #include 
>>  #include 
>> +#include 
>>  
>>  / {
>>  compatible = "ti,k2g","ti,keystone";
>> @@ -168,5 +169,46 @@
>>  #reset-cells = <2>;
>>  };
>>  };
>> +
>> +gpio0: gpio@2603000 {
>> +compatible = "ti,keystone-k2g-gpio";
>> +reg = <0x02603000 0x100>;
>> +gpio-controller;
>> +#gpio-cells = <2>;
>> +
>> +interrupts = ,
>> +,
>> +,
>> +,
>> +,
>> +,
>> +,
>> +,
>> +;
>> +interrupt-controller;
>> +#interrupt-cells = <2>;
>> +ti,ngpio = <144>;
>> +ti,davinci-gpio-unbanked = <0>;
>> +clocks = <_clks 0x001b 0x0>;
>> +clock-names = "gpio";
> 
> I don't see the clocks and clock-names documented in the binding.
> Looking at davinci_gpio_irq_setup(), these are required, and a specific
> clock name is what the driver is looking for. And you have different
> semantics for this on K2G and non-K2G SoCs. Davinci platforms are using
> non-DT clocks, so their DT nodes didn't have them.

I will document the same.

> 
> regards
> Suman
> 
>> +};
>> +
>> +gpio1: gpio@260a000 {
>> +compatible = "ti,keystone-k2g-gpio";
>> +reg = <0x0260a000 0x100>;
>> +gpio-controller;
>> +#gpio-cells = <2>;
>> +interrupts = ,
>> +,
>> +,
>> +,
>> +;
>> +interrupt-controller;
>> +#interrupt-cells = <2>;
>> +ti,ngpio = <68>;
>> +ti,davinci-gpio-unbanked = <0>;
>> +clocks = <_clks 0x001c 0x0>;
>> +clock-names = "gpio";
>> +};
>>  };
>>  };
>>
> 

Re: [PATCH 4/4] ARM: dts: keystone-k2g-evm: Add gpio nodes

[Keerthy]

On Wednesday 19 July 2017 12:43 AM, Suman Anna wrote:
> Hi Keerthy,
> 
> On 07/18/2017 05:57 AM, Keerthy wrote:
>> keystone-k2g has 2 instances of gpio. The first one has all the 144 GPIOs
> 
> Please use 66AK2G for keystone-k2g.

Okay

> 
>> functional( 9 banks with 16 gpios = 144). The second instance has
>> only the GPIO0:GPIO67 functional and rest are marked reserved.
>>
>> Signed-off-by: Keerthy 
>> ---
>>  arch/arm/boot/dts/keystone-k2g.dtsi | 42 
>> +
>>  1 file changed, 42 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi 
>> b/arch/arm/boot/dts/keystone-k2g.dtsi
>> index bf4d1fa..58ac3db 100644
>> --- a/arch/arm/boot/dts/keystone-k2g.dtsi
>> +++ b/arch/arm/boot/dts/keystone-k2g.dtsi
>> @@ -15,6 +15,7 @@
>>  
>>  #include 
>>  #include 
>> +#include 
>>  
>>  / {
>>  compatible = "ti,k2g","ti,keystone";
>> @@ -168,5 +169,46 @@
>>  #reset-cells = <2>;
>>  };
>>  };
>> +
>> +gpio0: gpio@2603000 {
>> +compatible = "ti,keystone-k2g-gpio";
>> +reg = <0x02603000 0x100>;
>> +gpio-controller;
>> +#gpio-cells = <2>;
>> +
>> +interrupts = ,
>> +,
>> +,
>> +,
>> +,
>> +,
>> +,
>> +,
>> +;
>> +interrupt-controller;
>> +#interrupt-cells = <2>;
>> +ti,ngpio = <144>;
>> +ti,davinci-gpio-unbanked = <0>;
>> +clocks = <_clks 0x001b 0x0>;
>> +clock-names = "gpio";
> 
> I don't see the clocks and clock-names documented in the binding.
> Looking at davinci_gpio_irq_setup(), these are required, and a specific
> clock name is what the driver is looking for. And you have different
> semantics for this on K2G and non-K2G SoCs. Davinci platforms are using
> non-DT clocks, so their DT nodes didn't have them.

I will document the same.

> 
> regards
> Suman
> 
>> +};
>> +
>> +gpio1: gpio@260a000 {
>> +compatible = "ti,keystone-k2g-gpio";
>> +reg = <0x0260a000 0x100>;
>> +gpio-controller;
>> +#gpio-cells = <2>;
>> +interrupts = ,
>> +,
>> +,
>> +,
>> +;
>> +interrupt-controller;
>> +#interrupt-cells = <2>;
>> +ti,ngpio = <68>;
>> +ti,davinci-gpio-unbanked = <0>;
>> +clocks = <_clks 0x001c 0x0>;
>> +clock-names = "gpio";
>> +};
>>  };
>>  };
>>
> 

Re: [PATCH 1/2] dmaengine: qcom_hidma: correct overriding message

[Vinod Koul]

On Sun, Jul 16, 2017 at 10:30:37AM -0400, Sinan Kaya wrote:
> A false overriding information is being presented during boot
> under this scenario.
> 
> 1. First object checks for kernel command line value against zero.
> 2. It doesn't find it, it sets the command line variable to the
> value coming from ACPI/DT.
> 3. Second object is being probed.
> 4. Second object sees that the value of kernel command line
> override is non-zero, it prints an overriding message even though
> value matches ACPI/DT value.
> 
> hidma-mgmt QCOM8060:03: overriding max-write-burst-bytes: 1024
> 
> Add an additional check to verify that kernel command line value
> is different from the ACPI/DT value.

Applied both, thanks

-- 
~Vinod

Re: [PATCH 1/2] dmaengine: qcom_hidma: correct overriding message

[Vinod Koul]

On Sun, Jul 16, 2017 at 10:30:37AM -0400, Sinan Kaya wrote:
> A false overriding information is being presented during boot
> under this scenario.
> 
> 1. First object checks for kernel command line value against zero.
> 2. It doesn't find it, it sets the command line variable to the
> value coming from ACPI/DT.
> 3. Second object is being probed.
> 4. Second object sees that the value of kernel command line
> override is non-zero, it prints an overriding message even though
> value matches ACPI/DT value.
> 
> hidma-mgmt QCOM8060:03: overriding max-write-burst-bytes: 1024
> 
> Add an additional check to verify that kernel command line value
> is different from the ACPI/DT value.

Applied both, thanks

-- 
~Vinod

[PATCH] net/sunrpc/xprt_sock: fix regression in connection error reporting.

[NeilBrown]

Commit 3d4762639dd3 ("tcp: remove poll() flakes when receiving
RST") in v4.12 changed the order in which ->sk_state_change()
and ->sk_error_report() are called when a socket is shut
down - sk_state_change() is now called first.

This causes xs_tcp_state_change() -> xs_sock_mark_closed() ->
xprt_disconnect_done() to wake all pending tasked with -EAGAIN.
When the ->sk_error_report() callback arrives, it is too late to
pass the error on, and it is lost.

As easy way to demonstrate the problem caused is to try to start
rpc.nfsd while rcpbind isn't running.
nfsd will attempt a tcp connection to rpcbind.  A ECONNREFUSED
error is returned, but sunrpc code loses the error and keeps
retrying.  If it saw the ECONNREFUSED, it would abort.

To fix this, handle the sk->sk_err in the TCP_CLOSE branch of
xs_tcp_state_change().

Fixes: 3d4762639dd3 ("tcp: remove poll() flakes when receiving RST")
Cc: sta...@vger.kernel.org (v4.12)
Signed-off-by: NeilBrown 
---
 net/sunrpc/xprtsock.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
index d5b54c020dec..4f154d388748 100644
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -1624,6 +1624,8 @@ static void xs_tcp_state_change(struct sock *sk)
if (test_and_clear_bit(XPRT_SOCK_CONNECTING,
>sock_state))
xprt_clear_connecting(xprt);
+   if (sk->sk_err)
+   xprt_wake_pending_tasks(xprt, -sk->sk_err);
xs_sock_mark_closed(xprt);
}
  out:
-- 
2.12.2



signature.asc
Description: PGP signature

[PATCH] net/sunrpc/xprt_sock: fix regression in connection error reporting.

[NeilBrown]

Commit 3d4762639dd3 ("tcp: remove poll() flakes when receiving
RST") in v4.12 changed the order in which ->sk_state_change()
and ->sk_error_report() are called when a socket is shut
down - sk_state_change() is now called first.

This causes xs_tcp_state_change() -> xs_sock_mark_closed() ->
xprt_disconnect_done() to wake all pending tasked with -EAGAIN.
When the ->sk_error_report() callback arrives, it is too late to
pass the error on, and it is lost.

As easy way to demonstrate the problem caused is to try to start
rpc.nfsd while rcpbind isn't running.
nfsd will attempt a tcp connection to rpcbind.  A ECONNREFUSED
error is returned, but sunrpc code loses the error and keeps
retrying.  If it saw the ECONNREFUSED, it would abort.

To fix this, handle the sk->sk_err in the TCP_CLOSE branch of
xs_tcp_state_change().

Fixes: 3d4762639dd3 ("tcp: remove poll() flakes when receiving RST")
Cc: sta...@vger.kernel.org (v4.12)
Signed-off-by: NeilBrown 
---
 net/sunrpc/xprtsock.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
index d5b54c020dec..4f154d388748 100644
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -1624,6 +1624,8 @@ static void xs_tcp_state_change(struct sock *sk)
if (test_and_clear_bit(XPRT_SOCK_CONNECTING,
>sock_state))
xprt_clear_connecting(xprt);
+   if (sk->sk_err)
+   xprt_wake_pending_tasks(xprt, -sk->sk_err);
xs_sock_mark_closed(xprt);
}
  out:
-- 
2.12.2



signature.asc
Description: PGP signature

Re: [PATCH V3 1/2] dmaengine: qcom_hidma: introduce memset support

[Vinod Koul]

On Tue, Jul 18, 2017 at 10:17:06PM +0530, Vinod Koul wrote:
> On Tue, Jul 18, 2017 at 12:26:14PM -0400, Sinan Kaya wrote:
> > Hi Vinod,
> > 
> > On 7/18/2017 12:19 PM, Vinod Koul wrote:
> > > On Thu, Jun 29, 2017 at 10:30:57PM -0400, Sinan Kaya wrote:
> > > 
> > >> @@ -410,7 +410,40 @@ static int hidma_alloc_chan_resources(struct 
> > >> dma_chan *dmach)
> > >>  return NULL;
> > >>  
> > >>  hidma_ll_set_transfer_params(mdma->lldev, mdesc->tre_ch,
> > >> - src, dest, len, flags);
> > >> + src, dest, len, flags,
> > >> + HIDMA_TRE_MEMCPY);
> > >> +
> > >> +/* Place descriptor in prepared list */
> > >> +spin_lock_irqsave(>lock, irqflags);
> > >> +list_add_tail(>node, >prepared);
> > >> +spin_unlock_irqrestore(>lock, irqflags);
> > > 
> > > This change looks suspicious, cna you clarify the need to do this?
> > > 
> > > 
> > 
> > Diff looks weird for some reason. I noticed that too.
> > 
> > I just added HIDMA_TRE_MEMCPY parameter to hidma_ll_set_transfer_params() 
> > function call
> > from hidma_prep_dma_memcpy() and created a new hidma_prep_dma_memset() 
> > function very
> > similar to memcpy with HIDMA_TRE_MEMSET call difference.
> > 
> > My suggestion is to use kdiff or another visual tool to look at the change.
> 
> ah fine then, let me take a look at it again with rested pair of eyes in the
> morn :)

Checked the context is fine, so

Applied, thanks

-- 
~Vinod

Re: [PATCH V3 1/2] dmaengine: qcom_hidma: introduce memset support

[Vinod Koul]

On Tue, Jul 18, 2017 at 10:17:06PM +0530, Vinod Koul wrote:
> On Tue, Jul 18, 2017 at 12:26:14PM -0400, Sinan Kaya wrote:
> > Hi Vinod,
> > 
> > On 7/18/2017 12:19 PM, Vinod Koul wrote:
> > > On Thu, Jun 29, 2017 at 10:30:57PM -0400, Sinan Kaya wrote:
> > > 
> > >> @@ -410,7 +410,40 @@ static int hidma_alloc_chan_resources(struct 
> > >> dma_chan *dmach)
> > >>  return NULL;
> > >>  
> > >>  hidma_ll_set_transfer_params(mdma->lldev, mdesc->tre_ch,
> > >> - src, dest, len, flags);
> > >> + src, dest, len, flags,
> > >> + HIDMA_TRE_MEMCPY);
> > >> +
> > >> +/* Place descriptor in prepared list */
> > >> +spin_lock_irqsave(>lock, irqflags);
> > >> +list_add_tail(>node, >prepared);
> > >> +spin_unlock_irqrestore(>lock, irqflags);
> > > 
> > > This change looks suspicious, cna you clarify the need to do this?
> > > 
> > > 
> > 
> > Diff looks weird for some reason. I noticed that too.
> > 
> > I just added HIDMA_TRE_MEMCPY parameter to hidma_ll_set_transfer_params() 
> > function call
> > from hidma_prep_dma_memcpy() and created a new hidma_prep_dma_memset() 
> > function very
> > similar to memcpy with HIDMA_TRE_MEMSET call difference.
> > 
> > My suggestion is to use kdiff or another visual tool to look at the change.
> 
> ah fine then, let me take a look at it again with rested pair of eyes in the
> morn :)

Checked the context is fine, so

Applied, thanks

-- 
~Vinod

Re: [PATCH] dma: Convert to using %pOF instead of full_name

[Vinod Koul]

On Tue, Jul 18, 2017 at 04:42:58PM -0500, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.

Applied after fixing the subsystem name, thanks

-- 
~Vinod

Re: [PATCH] dma: Convert to using %pOF instead of full_name

[Vinod Koul]

On Tue, Jul 18, 2017 at 04:42:58PM -0500, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.

Applied after fixing the subsystem name, thanks

-- 
~Vinod

Re: [PATCH] irqchip: Convert to using %pOF instead of full_name

[Baruch Siach]

Hi Rob,

On Tue, Jul 18, 2017 at 04:43:10PM -0500, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
> 
> Signed-off-by: Rob Herring 
> Cc: Thomas Gleixner 
> Cc: Jason Cooper 
> Cc: Marc Zyngier 
> Cc: Lee Jones 
> Cc: Eric Anholt 
> Cc: Stefan Wahren 
> Cc: Florian Fainelli 
> Cc: Ray Jui 
> Cc: Scott Branden 
> Cc: bcm-kernel-feedback-l...@broadcom.com
> Cc: Baruch Siach 
> Cc: Vladimir Zapolskiy 
> Cc: Sylvain Lemieux 
> Cc: Matthias Brugger 
> Cc: Maxime Coquelin 
> Cc: Alexandre Torgue 
> Cc: Maxime Ripard 
> Cc: Chen-Yu Tsai 
> Cc: Thierry Reding 
> Cc: Jonathan Hunter 
> Cc: Michal Simek 
> Cc: "Sören Brinkmann" 
> Cc: linux-rpi-ker...@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-te...@vger.kernel.org
> ---

>  drivers/irqchip/irq-digicolor.c  |  8 

Acked-by: Baruch Siach 

Thanks,
baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

Re: [PATCH] irqchip: Convert to using %pOF instead of full_name

[Baruch Siach]

Hi Rob,

On Tue, Jul 18, 2017 at 04:43:10PM -0500, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
> 
> Signed-off-by: Rob Herring 
> Cc: Thomas Gleixner 
> Cc: Jason Cooper 
> Cc: Marc Zyngier 
> Cc: Lee Jones 
> Cc: Eric Anholt 
> Cc: Stefan Wahren 
> Cc: Florian Fainelli 
> Cc: Ray Jui 
> Cc: Scott Branden 
> Cc: bcm-kernel-feedback-l...@broadcom.com
> Cc: Baruch Siach 
> Cc: Vladimir Zapolskiy 
> Cc: Sylvain Lemieux 
> Cc: Matthias Brugger 
> Cc: Maxime Coquelin 
> Cc: Alexandre Torgue 
> Cc: Maxime Ripard 
> Cc: Chen-Yu Tsai 
> Cc: Thierry Reding 
> Cc: Jonathan Hunter 
> Cc: Michal Simek 
> Cc: "Sören Brinkmann" 
> Cc: linux-rpi-ker...@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-te...@vger.kernel.org
> ---

>  drivers/irqchip/irq-digicolor.c  |  8 

Acked-by: Baruch Siach 

Thanks,
baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -