commit a2be37eedb52ea26938fa4cc9de1ff84963c57ad upstream.

All the functions operating on the 'handle' pointer are claiming it is a
pointer to const thus they should not modify the handle.  In fact that's
a false statement, because first thing these functions do is drop the
cast to const with container_of:

  struct acpm_info *acpm = handle_to_acpm_info(handle);

And with such cast the handle is easily writable with simple:

  acpm->handle.ops.pmic_ops.read_reg = NULL;

The code is not correct logically, either, because functions like
acpm_get_by_node() and acpm_handle_put() are meant to modify the handle
reference counting, thus they must modify the handle.  Modification here
happens anyway, even if the reference counting is stored in the
container which the handle is part of.

The code does not have actual visible bug, but incorrect 'const'
annotations could lead to incorrect compiler decisions.

Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver")
Cc: stable@vger.kernel.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260224104203.42950-2-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5cd28bd28c8ce426b56ce4230dbd17537181d5ad upstream.

The native driver takes over the framebuffer aperture by removing the
system- framebuffer platform device. Afterwards the pointer in drvdata
is dangling. Remove the entire logic around drvdata and let the kernel's
aperture helpers handle this. The platform device depends on the native
hardware device instead of the coreboot device anyway.

When commit 851b4c14532d ("firmware: coreboot: Add coreboot framebuffer
driver") added the coreboot framebuffer code, the kernel did not support
device-based aperture management. Instead native driviers only removed
the conflicting fbdev device. At that point, unregistering the framebuffer
device most likely worked correctly. It was definitely broken after
commit d9702b2a2171 ("fbdev/simplefb: Do not use struct
fb_info.apertures"). So take this commit for the Fixes tag. Earlier
releases might work depending on the native hardware driver.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: d9702b2a2171 ("fbdev/simplefb: Do not use struct fb_info.apertures")
Acked-by: Tzung-Bi Shih <tzungbi@kernel.org>
Acked-by: Julius Werner <jwerner@chromium.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Hans de Goede <hansg@kernel.org>
Cc: linux-fbdev@vger.kernel.org
Cc: <stable@vger.kernel.org> # v6.3+
Link: https://patch.msgid.link/20260217155836.96267-2-tzimmermann@suse.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f3850d399de3b6142b02315227ef9e772ed0c302 upstream.

Remove the flag IORESOURCE_BUSY flag from coreboot's framebuffer
resource. It prevents simpledrm from successfully requesting the
range for its own use; resulting in errors such as

[    2.775430] simple-framebuffer simple-framebuffer.0: [drm] could not acquire memory region [mem 0x80000000-0x80407fff flags 0x80000200]

As with other uses of simple-framebuffer, the simple-framebuffer
device should only declare it's I/O resources, but not actively use
them.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: 851b4c14532d ("firmware: coreboot: Add coreboot framebuffer driver")
Acked-by: Tzung-Bi Shih <tzungbi@kernel.org>
Acked-by: Julius Werner <jwerner@chromium.org>
Cc: Samuel Holland <samuel@sholland.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tzung-Bi Shih <tzungbi@kernel.org>
Cc: Brian Norris <briannorris@chromium.org>
Cc: Julius Werner <jwerner@chromium.org>
Cc: chrome-platform@lists.linux.dev
Cc: <stable@vger.kernel.org> # v4.18+
Link: https://patch.msgid.link/20260217155836.96267-3-tzimmermann@suse.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Pull EFI fix from Ard Biesheuvel:
 "Fix an incorrect preprocessor conditional that may result in duplicate
  instances of sysfb_primary_display on x86"

* tag 'efi-fixes-for-v7.0-4' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi:
  firmware: efi: Never declare sysfb_primary_display on x86

Pull pmdomain fixes from Ulf Hansson:

 - imx: Prevent hang at power down for imx8mp-blk-ctrl

 - thead: Fix buffer overflow for TH1520 AON driver

 - Change Ulf Hansson's email

* tag 'pmdomain-v7.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm:
  MAINTAINERS, mailmap: Change Ulf Hansson's email
  pmdomain: imx8mp-blk-ctrl: Keep the NOC_HDCP clock enabled
  firmware: thead: Fix buffer overflow and use standard endian macros

The x86 architecture comes with its own instance of the global
state variable sysfb_primary_display. Never declare it in the EFI
subsystem. Fix the test for CONFIG_FIRMWARE_EDID accordingly.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: e65ca1646311 ("efi: export sysfb_primary_display for EDID")
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

Pull SoC fixes from Arnd Bergmann:
 "The largest part here are devicetree fixes for Qualcomm, and NXP i.MX,
  addressing a few regressions and incorrect settings in board and SoC
  pecific dts files.

  The largest single commits are a revert of a cleanup patch for i.MX
  that caused regressions for the NAND flash controller and a fixup for
  an incomplete cleanup of the PCIe controller on Qualcomm platforms
  that broke because the state was left incompatible with both the old
  and new behavior.

  On the Rockchips, Hisilicon, Renesas, Allwinner and AT91 platforms,
  only a single simple dts bugfix each was added since the last round of
  fixes.

  On the SoC specific device drivers, everything is relatively harmless:
  three reset controller driver fixes, a compatibility for fix ASpeed
  soc ID, and error handling fixes for Qualcomm and Microchip. One
  regression fix on Qualcomm addresses a problem with a previous fix for
  DisplayPort alt mode"

* tag 'soc-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (32 commits)
  arm64: dts: qcom: hamoa: Fix incomplete Root Port property migration
  dt-bindings: display/msm: qcm2290-mdss: Fix missing ranges in example
  firmware: microchip: fail auto-update probe if no flash found
  arm64: dts: renesas: sparrow-hawk: Reserve first 128 MiB of DRAM
  arm64: dts: qcom: agatti: Fix IOMMU DT properties
  dt-bindings: media: venus: Fix iommus property
  dt-bindings: display: msm: qcm2290-mdss: Fix iommus property
  arm64: dts: allwinner: sun55i: Fix r-spi DMA
  reset: spacemit: k3: Decouple composite reset lines
  reset: gpio: fix double free in reset_add_gpio_aux_device() error path
  ARM: dts: microchip: sam9x7: fix gpio-lines count for pioB
  arm64: dts: hisilicon: hi3798cv200: Add missing dma-ranges
  arm64: dts: hisilicon: poplar: Correct PCIe reset GPIO polarity
  reset: rzg2l-usbphy-ctrl: Fix malformed MODULE_AUTHOR string
  soc: microchip: mpfs-mss-top-sysreg: Fix resource leak on driver unbind
  soc: microchip: mpfs-control-scb: Fix resource leak on driver unbind
  soc: qcom: pmic_glink_altmode: Fix TBT->SAFE->!TBT transition
  arm64: dts: qcom: monaco: Reserve full Gunyah metadata region
  arm64: dts: imx8mq-librem5: Bump BUCK1 suspend voltage up to 0.85V
  Revert "arm64: dts: imx8mq-librem5: Set the DVS voltages lower"
  ...

RISC-V soc fixes for v7.0-rc6

Microchip:
More resource leak fixes for unlikely scenarios, and a change to the
auto-update "firmware" driver to prevent it probing on systems with
engineering silicon where it cannot be used.

Signed-off-by: Conor Dooley <conor.dooley@microchip.com>

* tag 'riscv-soc-fixes-for-v7.0-rc6' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/conor/linux:
  firmware: microchip: fail auto-update probe if no flash found
  soc: microchip: mpfs-mss-top-sysreg: Fix resource leak on driver unbind
  soc: microchip: mpfs-control-scb: Fix resource leak on driver unbind

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>

Addresses two issues in the TH1520 AON firmware protocol driver:

1. Fix a potential buffer overflow where the code used unsafe pointer
   arithmetic to access the 'mode' field through the 'resource' pointer
   with an offset. This was flagged by Smatch static checker as:
   "buffer overflow 'data' 2 <= 3"

2. Replace custom RPC_SET_BE* and RPC_GET_BE* macros with standard
   kernel endianness conversion macros (cpu_to_be16, etc.) for better
   portability and maintainability.

The functionality was re-tested with the GPU power-up sequence,
confirming the GPU powers up correctly and the driver probes
successfully.

[   12.702370] powervr ffef400000.gpu: [drm] loaded firmware
powervr/rogue_36.52.104.182_v1.fw
[   12.711043] powervr ffef400000.gpu: [drm] FW version v1.0 (build
6645434 OS)
[   12.719787] [drm] Initialized powervr 1.0.0 for ffef400000.gpu on
minor 0

Fixes: e4b3cbd840e5 ("firmware: thead: Add AON firmware protocol driver")
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/all/17a0ccce-060b-4b9d-a3c4-8d5d5823b1c9@stanley.mountain/
Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com>
Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
Acked-by: Drew Fustini <fustini@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

There's no point letting the driver probe if there is no flash, as
trying to do a firmware upload will fail. Move the code that attempts
to get the flash from firmware upload to probe, and let it emit a
message to users stating why auto-update is not supported.
The code currently could have a problem if there's a flash in
devicetree, but the system controller driver fails to get a pointer to
it from the mtd subsystem, which will cause
mpfs_sys_controller_get_flash() to return an error. Check for errors and
null, instead of just null, in the new clause.

CC: stable@vger.kernel.org
Fixes: ec5b0f1193ad4 ("firmware: microchip: add PolarFire SoC Auto Update support")
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>