4.14-stable patches

added patches:
	backlight-pwm_bl-improve-bootloader-kernel-device-handover.patch
	clk-kirkwood-fix-a-clocking-boot-regression.patch
	fbmem-don-t-allow-too-huge-resolutions.patch

diff --git a/queue-4.14/backlight-pwm_bl-improve-bootloader-kernel-device-handover.patch b/queue-4.14/backlight-pwm_bl-improve-bootloader-kernel-device-handover.patch
new file mode 100644 (file)
index 0000000..161fc40
--- /dev/null
+++ b/queue-4.14/backlight-pwm_bl-improve-bootloader-kernel-device-handover.patch
@@ -0,0 +1,114 @@
+From 79fad92f2e596f5a8dd085788a24f540263ef887 Mon Sep 17 00:00:00 2001
+From: Daniel Thompson <daniel.thompson@linaro.org>
+Date: Thu, 22 Jul 2021 15:46:23 +0100
+Subject: backlight: pwm_bl: Improve bootloader/kernel device handover
+
+From: Daniel Thompson <daniel.thompson@linaro.org>
+
+commit 79fad92f2e596f5a8dd085788a24f540263ef887 upstream.
+
+Currently there are (at least) two problems in the way pwm_bl starts
+managing the enable_gpio pin. Both occur when the backlight is initially
+off and the driver finds the pin not already in output mode and, as a
+result, unconditionally switches it to output-mode and asserts the signal.
+
+Problem 1: This could cause the backlight to flicker since, at this stage
+in driver initialisation, we have no idea what the PWM and regulator are
+doing (an unconfigured PWM could easily "rest" at 100% duty cycle).
+
+Problem 2: This will cause us not to correctly honour the
+post_pwm_on_delay (which also risks flickers).
+
+Fix this by moving the code to configure the GPIO output mode until after
+we have examines the handover state. That allows us to initialize
+enable_gpio to off if the backlight is currently off and on if the
+backlight is on.
+
+Cc: stable@vger.kernel.org
+Reported-by: Marek Vasut <marex@denx.de>
+Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
+Acked-by: Marek Vasut <marex@denx.de>
+Tested-by: Marek Vasut <marex@denx.de>
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/video/backlight/pwm_bl.c |   54 ++++++++++++++++++++-------------------
+ 1 file changed, 28 insertions(+), 26 deletions(-)
+
+--- a/drivers/video/backlight/pwm_bl.c
++++ b/drivers/video/backlight/pwm_bl.c
+@@ -199,6 +199,33 @@ static int pwm_backlight_parse_dt(struct
+ static int pwm_backlight_initial_power_state(const struct pwm_bl_data *pb)
+ {
+       struct device_node *node = pb->dev->of_node;
++      bool active = true;
++
++      /*
++       * If the enable GPIO is present, observable (either as input
++       * or output) and off then the backlight is not currently active.
++       * */
++      if (pb->enable_gpio && gpiod_get_value_cansleep(pb->enable_gpio) == 0)
++              active = false;
++
++      if (!regulator_is_enabled(pb->power_supply))
++              active = false;
++
++      if (!pwm_is_enabled(pb->pwm))
++              active = false;
++
++      /*
++       * Synchronize the enable_gpio with the observed state of the
++       * hardware.
++       */
++      if (pb->enable_gpio)
++              gpiod_direction_output(pb->enable_gpio, active);
++
++      /*
++       * Do not change pb->enabled here! pb->enabled essentially
++       * tells us if we own one of the regulator's use counts and
++       * right now we do not.
++       */
+ 
+       /* Not booted with device tree or no phandle link to the node */
+       if (!node || !node->phandle)
+@@ -210,20 +237,7 @@ static int pwm_backlight_initial_power_s
+        * assume that another driver will enable the backlight at the
+        * appropriate time. Therefore, if it is disabled, keep it so.
+        */
+-
+-      /* if the enable GPIO is disabled, do not enable the backlight */
+-      if (pb->enable_gpio && gpiod_get_value_cansleep(pb->enable_gpio) == 0)
+-              return FB_BLANK_POWERDOWN;
+-
+-      /* The regulator is disabled, do not enable the backlight */
+-      if (!regulator_is_enabled(pb->power_supply))
+-              return FB_BLANK_POWERDOWN;
+-
+-      /* The PWM is disabled, keep it like this */
+-      if (!pwm_is_enabled(pb->pwm))
+-              return FB_BLANK_POWERDOWN;
+-
+-      return FB_BLANK_UNBLANK;
++      return active ? FB_BLANK_UNBLANK: FB_BLANK_POWERDOWN;
+ }
+ 
+ static int pwm_backlight_probe(struct platform_device *pdev)
+@@ -300,18 +314,6 @@ static int pwm_backlight_probe(struct pl
+               pb->enable_gpio = gpio_to_desc(data->enable_gpio);
+       }
+ 
+-      /*
+-       * If the GPIO is not known to be already configured as output, that
+-       * is, if gpiod_get_direction returns either 1 or -EINVAL, change the
+-       * direction to output and set the GPIO as active.
+-       * Do not force the GPIO to active when it was already output as it
+-       * could cause backlight flickering or we would enable the backlight too
+-       * early. Leave the decision of the initial backlight state for later.
+-       */
+-      if (pb->enable_gpio &&
+-          gpiod_get_direction(pb->enable_gpio) != 0)
+-              gpiod_direction_output(pb->enable_gpio, 1);
+-
+       pb->power_supply = devm_regulator_get(&pdev->dev, "power");
+       if (IS_ERR(pb->power_supply)) {
+               ret = PTR_ERR(pb->power_supply);

diff --git a/queue-4.14/clk-kirkwood-fix-a-clocking-boot-regression.patch b/queue-4.14/clk-kirkwood-fix-a-clocking-boot-regression.patch
new file mode 100644 (file)
index 0000000..37c2e21
--- /dev/null
+++ b/queue-4.14/clk-kirkwood-fix-a-clocking-boot-regression.patch
@@ -0,0 +1,63 @@
+From aaedb9e00e5400220a8871180d23a83e67f29f63 Mon Sep 17 00:00:00 2001
+From: Linus Walleij <linus.walleij@linaro.org>
+Date: Sun, 15 Aug 2021 01:55:14 +0200
+Subject: clk: kirkwood: Fix a clocking boot regression
+
+From: Linus Walleij <linus.walleij@linaro.org>
+
+commit aaedb9e00e5400220a8871180d23a83e67f29f63 upstream.
+
+Since a few kernel releases the Pogoplug 4 has crashed like this
+during boot:
+
+Unable to handle kernel NULL pointer dereference at virtual address 00000002
+(...)
+[<c04116ec>] (strlen) from [<c00ead80>] (kstrdup+0x1c/0x4c)
+[<c00ead80>] (kstrdup) from [<c04591d8>] (__clk_register+0x44/0x37c)
+[<c04591d8>] (__clk_register) from [<c04595ec>] (clk_hw_register+0x20/0x44)
+[<c04595ec>] (clk_hw_register) from [<c045bfa8>] (__clk_hw_register_mux+0x198/0x1e4)
+[<c045bfa8>] (__clk_hw_register_mux) from [<c045c050>] (clk_register_mux_table+0x5c/0x6c)
+[<c045c050>] (clk_register_mux_table) from [<c0acf3e0>] (kirkwood_clk_muxing_setup.constprop.0+0x13c/0x1ac)
+[<c0acf3e0>] (kirkwood_clk_muxing_setup.constprop.0) from [<c0aceae0>] (of_clk_init+0x12c/0x214)
+[<c0aceae0>] (of_clk_init) from [<c0ab576c>] (time_init+0x20/0x2c)
+[<c0ab576c>] (time_init) from [<c0ab3d18>] (start_kernel+0x3dc/0x56c)
+[<c0ab3d18>] (start_kernel) from [<00000000>] (0x0)
+Code: e3130020 1afffffb e12fff1e c08a1078 (e5d03000)
+
+This is because the "powersave" mux clock 0 was provided in an unterminated
+array, which is required by the loop in the driver:
+
+        /* Count, allocate, and register clock muxes */
+        for (n = 0; desc[n].name;)
+                n++;
+
+Here n will go out of bounds and then call clk_register_mux() on random
+memory contents after the mux clock.
+
+Fix this by terminating the array with a blank entry.
+
+Fixes: 105299381d87 ("cpufreq: kirkwood: use the powersave multiplexer")
+Cc: stable@vger.kernel.org
+Cc: Andrew Lunn <andrew@lunn.ch>
+Cc: Chris Packham <chris.packham@alliedtelesis.co.nz>
+Cc: Gregory CLEMENT <gregory.clement@bootlin.com>
+Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Link: https://lore.kernel.org/r/20210814235514.403426-1-linus.walleij@linaro.org
+Reviewed-by: Andrew Lunn <andrew@lunn.ch>
+Signed-off-by: Stephen Boyd <sboyd@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/clk/mvebu/kirkwood.c |    1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/clk/mvebu/kirkwood.c
++++ b/drivers/clk/mvebu/kirkwood.c
+@@ -254,6 +254,7 @@ static const char *powersave_parents[] =
+ static const struct clk_muxing_soc_desc kirkwood_mux_desc[] __initconst = {
+       { "powersave", powersave_parents, ARRAY_SIZE(powersave_parents),
+               11, 1, 0 },
++      { }
+ };
+ 
+ static struct clk *clk_muxing_get_src(

diff --git a/queue-4.14/fbmem-don-t-allow-too-huge-resolutions.patch b/queue-4.14/fbmem-don-t-allow-too-huge-resolutions.patch
new file mode 100644 (file)
index 0000000..bc9459d
--- /dev/null
+++ b/queue-4.14/fbmem-don-t-allow-too-huge-resolutions.patch
@@ -0,0 +1,64 @@
+From 8c28051cdcbe9dfcec6bd0a4709d67a09df6edae Mon Sep 17 00:00:00 2001
+From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
+Date: Wed, 8 Sep 2021 19:27:49 +0900
+Subject: fbmem: don't allow too huge resolutions
+
+From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
+
+commit 8c28051cdcbe9dfcec6bd0a4709d67a09df6edae upstream.
+
+syzbot is reporting page fault at vga16fb_fillrect() [1], for
+vga16fb_check_var() is failing to detect multiplication overflow.
+
+  if (vxres * vyres > maxmem) {
+    vyres = maxmem / vxres;
+    if (vyres < yres)
+      return -ENOMEM;
+  }
+
+Since no module would accept too huge resolutions where multiplication
+overflow happens, let's reject in the common path.
+
+Link: https://syzkaller.appspot.com/bug?extid=04168c8063cfdde1db5e [1]
+Reported-by: syzbot <syzbot+04168c8063cfdde1db5e@syzkaller.appspotmail.com>
+Debugged-by: Randy Dunlap <rdunlap@infradead.org>
+Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Cc: stable@vger.kernel.org
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Link: https://patchwork.freedesktop.org/patch/msgid/185175d6-227a-7b55-433d-b070929b262c@i-love.sakura.ne.jp
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/video/fbdev/core/fbmem.c |    7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/video/fbdev/core/fbmem.c
++++ b/drivers/video/fbdev/core/fbmem.c
+@@ -34,6 +34,7 @@
+ #include <linux/fb.h>
+ #include <linux/fbcon.h>
+ #include <linux/mem_encrypt.h>
++#include <linux/overflow.h>
+ 
+ #include <asm/fb.h>
+ 
+@@ -983,6 +984,7 @@ fb_set_var(struct fb_info *info, struct
+       if ((var->activate & FB_ACTIVATE_FORCE) ||
+           memcmp(&info->var, var, sizeof(struct fb_var_screeninfo))) {
+               u32 activate = var->activate;
++              u32 unused;
+ 
+               /* When using FOURCC mode, make sure the red, green, blue and
+                * transp fields are set to 0.
+@@ -1007,6 +1009,11 @@ fb_set_var(struct fb_info *info, struct
+               if (var->xres < 8 || var->yres < 8)
+                       return -EINVAL;
+ 
++              /* Too huge resolution causes multiplication overflow. */
++              if (check_mul_overflow(var->xres, var->yres, &unused) ||
++                  check_mul_overflow(var->xres_virtual, var->yres_virtual, &unused))
++                      return -EINVAL;
++
+               ret = info->fbops->fb_check_var(var, info);
+ 
+               if (ret)

diff --git a/queue-4.14/series b/queue-4.14/series
index 1f309930b2e4f8313e90a358860eeb3f90a21902..ffe952ac8c9a201e712e52da69424daab9febf48 100644 (file)
--- a/queue-4.14/series
+++ b/queue-4.14/series
@@ -95,3 +95,6 @@ tty-fix-data-race-between-tiocsti-and-flush_to_ldisc.patch
 x86-resctrl-fix-a-maybe-uninitialized-build-warning-treated-as-error.patch
 kvm-x86-update-vcpu-s-hv_clock-before-back-to-guest-when-tsc_offset-is-adjusted.patch
 ima-remove-wmissing-prototypes-warning.patch
+backlight-pwm_bl-improve-bootloader-kernel-device-handover.patch
+clk-kirkwood-fix-a-clocking-boot-regression.patch
+fbmem-don-t-allow-too-huge-resolutions.patch