--- /dev/null
+From 3265cc3ec52e75fc8daf189954cebda27ad26b2e Mon Sep 17 00:00:00 2001
+From: Aubrey Li <aubrey.li@intel.com>
+Date: Wed, 8 Sep 2021 18:55:45 +0800
+Subject: ACPI: PRM: Find PRMT table before parsing it
+
+From: Aubrey Li <aubrey.li@intel.com>
+
+commit 3265cc3ec52e75fc8daf189954cebda27ad26b2e upstream.
+
+Find and verify PRMT before parsing it, which eliminates a
+warning on machines without PRMT:
+
+ [ 7.197173] ACPI: PRMT not present
+
+Fixes: cefc7ca46235 ("ACPI: PRM: implement OperationRegion handler for the PlatformRtMechanism subtype")
+Signed-off-by: Aubrey Li <aubrey.li@linux.intel.com>
+Tested-by: Paul Menzel <pmenzel@molgen.mpg.de>
+Cc: 5.14+ <stable@vger.kernel.org> # 5.14+
+[ rjw: Subject and changelog edits ]
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/prmt.c | 10 +++++++++-
+ 1 file changed, 9 insertions(+), 1 deletion(-)
+
+--- a/drivers/acpi/prmt.c
++++ b/drivers/acpi/prmt.c
+@@ -288,10 +288,18 @@ invalid_guid:
+
+ void __init init_prmt(void)
+ {
++ struct acpi_table_header *tbl;
+ acpi_status status;
+- int mc = acpi_table_parse_entries(ACPI_SIG_PRMT, sizeof(struct acpi_table_prmt) +
++ int mc;
++
++ status = acpi_get_table(ACPI_SIG_PRMT, 0, &tbl);
++ if (ACPI_FAILURE(status))
++ return;
++
++ mc = acpi_table_parse_entries(ACPI_SIG_PRMT, sizeof(struct acpi_table_prmt) +
+ sizeof (struct acpi_table_prmt_header),
+ 0, acpi_parse_prmt, 0);
++ acpi_put_table(tbl);
+ /*
+ * Return immediately if PRMT table is not present or no PRM module found.
+ */
--- /dev/null
+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
+@@ -409,6 +409,33 @@ static bool pwm_backlight_is_linear(stru
+ 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)
+@@ -420,20 +447,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)
+@@ -486,18 +500,6 @@ static int pwm_backlight_probe(struct pl
+ goto err_alloc;
+ }
+
+- /*
+- * 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);
--- /dev/null
+From 903bd067faa837fddb6e5c8b740c3374dc582f04 Mon Sep 17 00:00:00 2001
+From: Julio Faracco <jcfaracco@gmail.com>
+Date: Sun, 5 Sep 2021 00:54:38 +0900
+Subject: bootconfig: Fix missing return check of xbc_node_compose_key function
+
+From: Julio Faracco <jcfaracco@gmail.com>
+
+commit 903bd067faa837fddb6e5c8b740c3374dc582f04 upstream.
+
+The function `xbc_show_list should` handle the keys during the
+composition. Even the errors returned by the compose function. Instead
+of removing the `ret` variable, it should save the value and show the
+exact error. This missing variable is causing a compilation issue also.
+
+Link: https://lkml.kernel.org/r/163077087861.222577.12884543474750968146.stgit@devnote2
+
+Fixes: e5efaeb8a8f5 ("bootconfig: Support mixing a value and subkeys under a key")
+Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
+Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/bootconfig/main.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/tools/bootconfig/main.c
++++ b/tools/bootconfig/main.c
+@@ -111,9 +111,11 @@ static void xbc_show_list(void)
+ char key[XBC_KEYLEN_MAX];
+ struct xbc_node *leaf;
+ const char *val;
++ int ret;
+
+ xbc_for_each_key_value(leaf, val) {
+- if (xbc_node_compose_key(leaf, key, XBC_KEYLEN_MAX) < 0) {
++ ret = xbc_node_compose_key(leaf, key, XBC_KEYLEN_MAX);
++ if (ret < 0) {
+ fprintf(stderr, "Failed to compose key %d\n", ret);
+ break;
+ }
--- /dev/null
+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
+@@ -265,6 +265,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(
--- /dev/null
+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 | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/video/fbdev/core/fbmem.c
++++ b/drivers/video/fbdev/core/fbmem.c
+@@ -962,6 +962,7 @@ fb_set_var(struct fb_info *info, struct
+ struct fb_var_screeninfo old_var;
+ struct fb_videomode mode;
+ struct fb_event event;
++ u32 unused;
+
+ if (var->activate & FB_ACTIVATE_INV_MODE) {
+ struct fb_videomode mode1, mode2;
+@@ -1008,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)
--- /dev/null
+From c42813b71a06a2ff4a155aa87ac609feeab76cf3 Mon Sep 17 00:00:00 2001
+From: Helge Deller <deller@gmx.de>
+Date: Thu, 2 Sep 2021 23:24:42 +0200
+Subject: parisc: Fix unaligned-access crash in bootloader
+
+From: Helge Deller <deller@gmx.de>
+
+commit c42813b71a06a2ff4a155aa87ac609feeab76cf3 upstream.
+
+Kernel v5.14 has various changes to optimize unaligned memory accesses,
+e.g. commit 0652035a5794 ("asm-generic: unaligned: remove byteshift helpers").
+
+Those changes triggered an unalignment-exception and thus crashed the
+bootloader on parisc because the unaligned "output_len" variable now suddenly
+was read word-wise while it was read byte-wise in the past.
+
+Fix this issue by declaring the external output_len variable as char which then
+forces the compiler to generate byte-accesses.
+
+Signed-off-by: Helge Deller <deller@gmx.de>
+Cc: Arnd Bergmann <arnd@kernel.org>
+Cc: John David Anglin <dave.anglin@bell.net>
+Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162
+Fixes: 8c031ba63f8f ("parisc: Unbreak bootloader due to gcc-7 optimizations")
+Fixes: 0652035a5794 ("asm-generic: unaligned: remove byteshift helpers")
+Cc: <stable@vger.kernel.org> # v5.14+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/parisc/boot/compressed/misc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/parisc/boot/compressed/misc.c
++++ b/arch/parisc/boot/compressed/misc.c
+@@ -26,7 +26,7 @@
+ extern char input_data[];
+ extern int input_len;
+ /* output_len is inserted by the linker possibly at an unaligned address */
+-extern __le32 output_len __aligned(1);
++extern char output_len;
+ extern char _text, _end;
+ extern char _bss, _ebss;
+ extern char _startcode_end;
--- /dev/null
+From 9660dcbe0d9186976917c94bce4e69dbd8d7a974 Mon Sep 17 00:00:00 2001
+From: Niklas Schnelle <schnelle@linux.ibm.com>
+Date: Wed, 8 Sep 2021 10:18:48 +0200
+Subject: RDMA/mlx5: Fix number of allocated XLT entries
+
+From: Niklas Schnelle <schnelle@linux.ibm.com>
+
+commit 9660dcbe0d9186976917c94bce4e69dbd8d7a974 upstream.
+
+In commit 8010d74b9965b ("RDMA/mlx5: Split the WR setup out of
+mlx5_ib_update_xlt()") the allocation logic was split out of
+mlx5_ib_update_xlt() and the logic was changed to enable better OOM
+handling. Sadly this change introduced a miscalculation of the number of
+entries that were actually allocated when under memory pressure where it
+can actually become 0 which on s390 lets dma_map_single() fail.
+
+It can also lead to corruption of the free pages list when the wrong
+number of entries is used in the calculation of sg->length which is used
+as argument for free_pages().
+
+Fix this by using the allocation size instead of misusing get_order(size).
+
+Cc: stable@vger.kernel.org
+Fixes: 8010d74b9965 ("RDMA/mlx5: Split the WR setup out of mlx5_ib_update_xlt()")
+Link: https://lore.kernel.org/r/20210908081849.7948-1-schnelle@linux.ibm.com
+Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/hw/mlx5/mr.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/infiniband/hw/mlx5/mr.c
++++ b/drivers/infiniband/hw/mlx5/mr.c
+@@ -1024,7 +1024,7 @@ static void *mlx5_ib_alloc_xlt(size_t *n
+
+ if (size > MLX5_SPARE_UMR_CHUNK) {
+ size = MLX5_SPARE_UMR_CHUNK;
+- *nents = get_order(size) / ent_size;
++ *nents = size / ent_size;
+ res = (void *)__get_free_pages(gfp_mask | __GFP_NOWARN,
+ get_order(size));
+ if (res)
fuse-wait-for-writepages-in-syncfs.patch
ima-remove-wmissing-prototypes-warning.patch
ima-remove-the-dependency-on-crypto_md5.patch
+fbmem-don-t-allow-too-huge-resolutions.patch
+acpi-prm-find-prmt-table-before-parsing-it.patch
+rdma-mlx5-fix-number-of-allocated-xlt-entries.patch
+bootconfig-fix-missing-return-check-of-xbc_node_compose_key-function.patch
+backlight-pwm_bl-improve-bootloader-kernel-device-handover.patch
+parisc-fix-unaligned-access-crash-in-bootloader.patch
+clk-kirkwood-fix-a-clocking-boot-regression.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
