<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/firmware/google, branch linux-6.6.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>firmware: google: framebuffer: Do not unregister platform device</title>
<updated>2026-05-17T15:13:49+00:00</updated>
<author>
<name>Thomas Zimmermann</name>
<email>tzimmermann@suse.de</email>
</author>
<published>2026-05-05T12:01:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=401a49b7f26ede8b83eb14936ea97a4ee0068ce7'/>
<id>401a49b7f26ede8b83eb14936ea97a4ee0068ce7</id>
<content type='text'>
[ Upstream commit 5cd28bd28c8ce426b56ce4230dbd17537181d5ad ]

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 &lt;tzimmermann@suse.de&gt;
Fixes: d9702b2a2171 ("fbdev/simplefb: Do not use struct fb_info.apertures")
Acked-by: Tzung-Bi Shih &lt;tzungbi@kernel.org&gt;
Acked-by: Julius Werner &lt;jwerner@chromium.org&gt;
Cc: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Cc: Javier Martinez Canillas &lt;javierm@redhat.com&gt;
Cc: Hans de Goede &lt;hansg@kernel.org&gt;
Cc: linux-fbdev@vger.kernel.org
Cc: &lt;stable@vger.kernel.org&gt; # v6.3+
Link: https://patch.msgid.link/20260217155836.96267-2-tzimmermann@suse.de
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 5cd28bd28c8ce426b56ce4230dbd17537181d5ad ]

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 &lt;tzimmermann@suse.de&gt;
Fixes: d9702b2a2171 ("fbdev/simplefb: Do not use struct fb_info.apertures")
Acked-by: Tzung-Bi Shih &lt;tzungbi@kernel.org&gt;
Acked-by: Julius Werner &lt;jwerner@chromium.org&gt;
Cc: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Cc: Javier Martinez Canillas &lt;javierm@redhat.com&gt;
Cc: Hans de Goede &lt;hansg@kernel.org&gt;
Cc: linux-fbdev@vger.kernel.org
Cc: &lt;stable@vger.kernel.org&gt; # v6.3+
Link: https://patch.msgid.link/20260217155836.96267-2-tzimmermann@suse.de
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>firmware: google: framebuffer: Do not mark framebuffer as busy</title>
<updated>2026-05-17T15:13:26+00:00</updated>
<author>
<name>Thomas Zimmermann</name>
<email>tzimmermann@suse.de</email>
</author>
<published>2026-02-17T15:56:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d0b27c41aa09406d0c8f315af332b003559dffd6'/>
<id>d0b27c41aa09406d0c8f315af332b003559dffd6</id>
<content type='text'>
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 &lt;tzimmermann@suse.de&gt;
Fixes: 851b4c14532d ("firmware: coreboot: Add coreboot framebuffer driver")
Acked-by: Tzung-Bi Shih &lt;tzungbi@kernel.org&gt;
Acked-by: Julius Werner &lt;jwerner@chromium.org&gt;
Cc: Samuel Holland &lt;samuel@sholland.org&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Tzung-Bi Shih &lt;tzungbi@kernel.org&gt;
Cc: Brian Norris &lt;briannorris@chromium.org&gt;
Cc: Julius Werner &lt;jwerner@chromium.org&gt;
Cc: chrome-platform@lists.linux.dev
Cc: &lt;stable@vger.kernel.org&gt; # v4.18+
Link: https://patch.msgid.link/20260217155836.96267-3-tzimmermann@suse.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;tzimmermann@suse.de&gt;
Fixes: 851b4c14532d ("firmware: coreboot: Add coreboot framebuffer driver")
Acked-by: Tzung-Bi Shih &lt;tzungbi@kernel.org&gt;
Acked-by: Julius Werner &lt;jwerner@chromium.org&gt;
Cc: Samuel Holland &lt;samuel@sholland.org&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Tzung-Bi Shih &lt;tzungbi@kernel.org&gt;
Cc: Brian Norris &lt;briannorris@chromium.org&gt;
Cc: Julius Werner &lt;jwerner@chromium.org&gt;
Cc: chrome-platform@lists.linux.dev
Cc: &lt;stable@vger.kernel.org&gt; # v4.18+
Link: https://patch.msgid.link/20260217155836.96267-3-tzimmermann@suse.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>firmware: google: Unregister driver_info on failure</title>
<updated>2024-12-09T09:31:47+00:00</updated>
<author>
<name>Yuan Can</name>
<email>yuancan@huawei.com</email>
</author>
<published>2024-10-15T13:13:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bba6cba4dab25516654519a27391eb9c1596f609'/>
<id>bba6cba4dab25516654519a27391eb9c1596f609</id>
<content type='text'>
[ Upstream commit 32b0901e141f6d4cf49d820b53eb09b88b1f72f7 ]

When platform_device_register_full() returns error, the gsmi_init() returns
without unregister gsmi_driver_info, fix by add missing
platform_driver_unregister() when platform_device_register_full() failed.

Fixes: 8942b2d5094b ("gsmi: Add GSMI commands to log S0ix info")
Signed-off-by: Yuan Can &lt;yuancan@huawei.com&gt;
Acked-by: Brian Norris &lt;briannorris@chromium.org&gt;
Link: https://lore.kernel.org/r/20241015131344.20272-1-yuancan@huawei.com
Signed-off-by: Tzung-Bi Shih &lt;tzungbi@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 32b0901e141f6d4cf49d820b53eb09b88b1f72f7 ]

When platform_device_register_full() returns error, the gsmi_init() returns
without unregister gsmi_driver_info, fix by add missing
platform_driver_unregister() when platform_device_register_full() failed.

Fixes: 8942b2d5094b ("gsmi: Add GSMI commands to log S0ix info")
Signed-off-by: Yuan Can &lt;yuancan@huawei.com&gt;
Acked-by: Brian Norris &lt;briannorris@chromium.org&gt;
Link: https://lore.kernel.org/r/20241015131344.20272-1-yuancan@huawei.com
Signed-off-by: Tzung-Bi Shih &lt;tzungbi@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>firmware: coreboot: framebuffer: Allow building with simpledrm</title>
<updated>2023-08-04T14:31:32+00:00</updated>
<author>
<name>Alper Nebi Yasak</name>
<email>alpernebiyasak@gmail.com</email>
</author>
<published>2023-07-25T17:43:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=dff054e691dae97f177c82cda21918ca0ef974f3'/>
<id>dff054e691dae97f177c82cda21918ca0ef974f3</id>
<content type='text'>
The coreboot framebuffer driver registers a "simple-framebuffer" device
based on the information from the firmware, after checking that it's
compatible with the formats listed in simplefb.h. It was added before
simpledrm, and its Kconfig marked as dependent on the simplefb driver.

The simpledrm driver can also handle "simple-framebuffer" devices and
the coreboot framebuffer works fine with it on a 'Lick' Chromebook.
Allow building the coreboot framebuffer driver with simpledrm as well.

Signed-off-by: Alper Nebi Yasak &lt;alpernebiyasak@gmail.com&gt;
Reviewed-by: Brian Norris &lt;briannorris@chromium.org&gt;
Link: https://lore.kernel.org/r/20230725174334.887485-1-alpernebiyasak@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The coreboot framebuffer driver registers a "simple-framebuffer" device
based on the information from the firmware, after checking that it's
compatible with the formats listed in simplefb.h. It was added before
simpledrm, and its Kconfig marked as dependent on the simplefb driver.

The simpledrm driver can also handle "simple-framebuffer" devices and
the coreboot framebuffer works fine with it on a 'Lick' Chromebook.
Allow building the coreboot framebuffer driver with simpledrm as well.

Signed-off-by: Alper Nebi Yasak &lt;alpernebiyasak@gmail.com&gt;
Reviewed-by: Brian Norris &lt;briannorris@chromium.org&gt;
Link: https://lore.kernel.org/r/20230725174334.887485-1-alpernebiyasak@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'char-misc-6.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc</title>
<updated>2023-02-24T20:47:33+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2023-02-24T20:47:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=693fed981eb9bf6e70bfda66bb872e2bb8155671'/>
<id>693fed981eb9bf6e70bfda66bb872e2bb8155671</id>
<content type='text'>
Pull char/misc and other driver subsystem updates from Greg KH:
 "Here is the large set of driver changes for char/misc drivers and
  other smaller driver subsystems that flow through this git tree.

  Included in here are:

   - New IIO drivers and features and improvments in that subsystem

   - New hwtracing drivers and additions to that subsystem

   - lots of interconnect changes and new drivers as that subsystem
     seems under very active development recently. This required also
     merging in the icc subsystem changes through this tree.

   - FPGA driver updates

   - counter subsystem and driver updates

   - MHI driver updates

   - nvmem driver updates

   - documentation updates

   - Other smaller driver updates and fixes, full details in the
     shortlog

  All of these have been in linux-next for a while with no reported
  problems"

* tag 'char-misc-6.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (223 commits)
  scripts/tags.sh: fix incompatibility with PCRE2
  firmware: coreboot: Remove GOOGLE_COREBOOT_TABLE_ACPI/OF Kconfig entries
  mei: lower the log level for non-fatal failed messages
  mei: bus: disallow driver match while dismantling device
  misc: vmw_balloon: fix memory leak with using debugfs_lookup()
  nvmem: stm32: fix OPTEE dependency
  dt-bindings: nvmem: qfprom: add IPQ8074 compatible
  nvmem: qcom-spmi-sdam: register at device init time
  nvmem: rave-sp-eeprm: fix kernel-doc bad line warning
  nvmem: stm32: detect bsec pta presence for STM32MP15x
  nvmem: stm32: add OP-TEE support for STM32MP13x
  nvmem: core: use nvmem_add_one_cell() in nvmem_add_cells_from_of()
  nvmem: core: add nvmem_add_one_cell()
  nvmem: core: drop the removal of the cells in nvmem_add_cells()
  nvmem: core: move struct nvmem_cell_info to nvmem-provider.h
  nvmem: core: add an index parameter to the cell
  of: property: add #nvmem-cell-cells property
  of: property: make #.*-cells optional for simple props
  of: base: add of_parse_phandle_with_optional_args()
  net: add helper eth_addr_add()
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull char/misc and other driver subsystem updates from Greg KH:
 "Here is the large set of driver changes for char/misc drivers and
  other smaller driver subsystems that flow through this git tree.

  Included in here are:

   - New IIO drivers and features and improvments in that subsystem

   - New hwtracing drivers and additions to that subsystem

   - lots of interconnect changes and new drivers as that subsystem
     seems under very active development recently. This required also
     merging in the icc subsystem changes through this tree.

   - FPGA driver updates

   - counter subsystem and driver updates

   - MHI driver updates

   - nvmem driver updates

   - documentation updates

   - Other smaller driver updates and fixes, full details in the
     shortlog

  All of these have been in linux-next for a while with no reported
  problems"

* tag 'char-misc-6.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (223 commits)
  scripts/tags.sh: fix incompatibility with PCRE2
  firmware: coreboot: Remove GOOGLE_COREBOOT_TABLE_ACPI/OF Kconfig entries
  mei: lower the log level for non-fatal failed messages
  mei: bus: disallow driver match while dismantling device
  misc: vmw_balloon: fix memory leak with using debugfs_lookup()
  nvmem: stm32: fix OPTEE dependency
  dt-bindings: nvmem: qfprom: add IPQ8074 compatible
  nvmem: qcom-spmi-sdam: register at device init time
  nvmem: rave-sp-eeprm: fix kernel-doc bad line warning
  nvmem: stm32: detect bsec pta presence for STM32MP15x
  nvmem: stm32: add OP-TEE support for STM32MP13x
  nvmem: core: use nvmem_add_one_cell() in nvmem_add_cells_from_of()
  nvmem: core: add nvmem_add_one_cell()
  nvmem: core: drop the removal of the cells in nvmem_add_cells()
  nvmem: core: move struct nvmem_cell_info to nvmem-provider.h
  nvmem: core: add an index parameter to the cell
  of: property: add #nvmem-cell-cells property
  of: property: make #.*-cells optional for simple props
  of: base: add of_parse_phandle_with_optional_args()
  net: add helper eth_addr_add()
  ...
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'efi-next-for-v6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi</title>
<updated>2023-02-23T22:41:48+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2023-02-23T22:41:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=06e1a81c4806d0b7f75f9d742ebf410718244e03'/>
<id>06e1a81c4806d0b7f75f9d742ebf410718244e03</id>
<content type='text'>
Pull EFI updates from Ard Biesheuvel:
 "A healthy mix of EFI contributions this time:

   - Performance tweaks for efifb earlycon (Andy)

   - Preparatory refactoring and cleanup work in the efivar layer, which
     is needed to accommodate the Snapdragon arm64 laptops that expose
     their EFI variable store via a TEE secure world API (Johan)

   - Enhancements to the EFI memory map handling so that Xen dom0 can
     safely access EFI configuration tables (Demi Marie)

   - Wire up the newly introduced IBT/BTI flag in the EFI memory
     attributes table, so that firmware that is generated with ENDBR/BTI
     landing pads will be mapped with enforcement enabled

   - Clean up how we check and print the EFI revision exposed by the
     firmware

   - Incorporate EFI memory attributes protocol definition and wire it
     up in the EFI zboot code (Evgeniy)

     This ensures that these images can execute under new and stricter
     rules regarding the default memory permissions for EFI page
     allocations (More work is in progress here)

   - CPER header cleanup (Dan Williams)

   - Use a raw spinlock to protect the EFI runtime services stack on
     arm64 to ensure the correct semantics under -rt (Pierre)

   - EFI framebuffer quirk for Lenovo Ideapad (Darrell)"

* tag 'efi-next-for-v6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: (24 commits)
  firmware/efi sysfb_efi: Add quirk for Lenovo IdeaPad Duet 3
  arm64: efi: Make efi_rt_lock a raw_spinlock
  efi: Add mixed-mode thunk recipe for GetMemoryAttributes
  efi: x86: Wire up IBT annotation in memory attributes table
  efi: arm64: Wire up BTI annotation in memory attributes table
  efi: Discover BTI support in runtime services regions
  efi/cper, cxl: Remove cxl_err.h
  efi: Use standard format for printing the EFI revision
  efi: Drop minimum EFI version check at boot
  efi: zboot: Use EFI protocol to remap code/data with the right attributes
  efi/libstub: Add memory attribute protocol definitions
  efi: efivars: prevent double registration
  efi: verify that variable services are supported
  efivarfs: always register filesystem
  efi: efivars: add efivars printk prefix
  efi: Warn if trying to reserve memory under Xen
  efi: Actually enable the ESRT under Xen
  efi: Apply allowlist to EFI configuration tables when running under Xen
  efi: xen: Implement memory descriptor lookup based on hypercall
  efi: memmap: Disregard bogus entries instead of returning them
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull EFI updates from Ard Biesheuvel:
 "A healthy mix of EFI contributions this time:

   - Performance tweaks for efifb earlycon (Andy)

   - Preparatory refactoring and cleanup work in the efivar layer, which
     is needed to accommodate the Snapdragon arm64 laptops that expose
     their EFI variable store via a TEE secure world API (Johan)

   - Enhancements to the EFI memory map handling so that Xen dom0 can
     safely access EFI configuration tables (Demi Marie)

   - Wire up the newly introduced IBT/BTI flag in the EFI memory
     attributes table, so that firmware that is generated with ENDBR/BTI
     landing pads will be mapped with enforcement enabled

   - Clean up how we check and print the EFI revision exposed by the
     firmware

   - Incorporate EFI memory attributes protocol definition and wire it
     up in the EFI zboot code (Evgeniy)

     This ensures that these images can execute under new and stricter
     rules regarding the default memory permissions for EFI page
     allocations (More work is in progress here)

   - CPER header cleanup (Dan Williams)

   - Use a raw spinlock to protect the EFI runtime services stack on
     arm64 to ensure the correct semantics under -rt (Pierre)

   - EFI framebuffer quirk for Lenovo Ideapad (Darrell)"

* tag 'efi-next-for-v6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: (24 commits)
  firmware/efi sysfb_efi: Add quirk for Lenovo IdeaPad Duet 3
  arm64: efi: Make efi_rt_lock a raw_spinlock
  efi: Add mixed-mode thunk recipe for GetMemoryAttributes
  efi: x86: Wire up IBT annotation in memory attributes table
  efi: arm64: Wire up BTI annotation in memory attributes table
  efi: Discover BTI support in runtime services regions
  efi/cper, cxl: Remove cxl_err.h
  efi: Use standard format for printing the EFI revision
  efi: Drop minimum EFI version check at boot
  efi: zboot: Use EFI protocol to remap code/data with the right attributes
  efi/libstub: Add memory attribute protocol definitions
  efi: efivars: prevent double registration
  efi: verify that variable services are supported
  efivarfs: always register filesystem
  efi: efivars: add efivars printk prefix
  efi: Warn if trying to reserve memory under Xen
  efi: Actually enable the ESRT under Xen
  efi: Apply allowlist to EFI configuration tables when running under Xen
  efi: xen: Implement memory descriptor lookup based on hypercall
  efi: memmap: Disregard bogus entries instead of returning them
  ...
</pre>
</div>
</content>
</entry>
<entry>
<title>firmware: coreboot: Remove GOOGLE_COREBOOT_TABLE_ACPI/OF Kconfig entries</title>
<updated>2023-02-09T08:24:48+00:00</updated>
<author>
<name>Douglas Anderson</name>
<email>dianders@chromium.org</email>
</author>
<published>2023-02-07T16:12:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e42af72223fdd0a4eca49e1bb904856710fdd46c'/>
<id>e42af72223fdd0a4eca49e1bb904856710fdd46c</id>
<content type='text'>
Ever since commit a28aad66da8b ("firmware: coreboot: Collapse platform
drivers into bus core") the Kconfig entries GOOGLE_COREBOOT_TABLE_OF
and GOOGLE_COREBOOT_TABLE_ACPI have been dead. They have no "help"
text and thus aren't user choosable. They also aren't "select"ed by
anything. They also control the compilation of no code.

Let's remove them.

Fixes: a28aad66da8b ("firmware: coreboot: Collapse platform drivers into bus core")
Signed-off-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Reviewed-by: Guenter Roeck &lt;groeck@chromium.org&gt;
Reviewed-by: Jack Rosenthal &lt;jrosenth@chromium.org&gt;
Acked-by: Stephen Boyd &lt;swboyd@chromium.org&gt;
Link: https://lore.kernel.org/r/20230207081130.1.I657776750156793721efa247ce6293445137bc8a@changeid
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Ever since commit a28aad66da8b ("firmware: coreboot: Collapse platform
drivers into bus core") the Kconfig entries GOOGLE_COREBOOT_TABLE_OF
and GOOGLE_COREBOOT_TABLE_ACPI have been dead. They have no "help"
text and thus aren't user choosable. They also aren't "select"ed by
anything. They also control the compilation of no code.

Let's remove them.

Fixes: a28aad66da8b ("firmware: coreboot: Collapse platform drivers into bus core")
Signed-off-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Reviewed-by: Guenter Roeck &lt;groeck@chromium.org&gt;
Reviewed-by: Jack Rosenthal &lt;jrosenth@chromium.org&gt;
Acked-by: Stephen Boyd &lt;swboyd@chromium.org&gt;
Link: https://lore.kernel.org/r/20230207081130.1.I657776750156793721efa247ce6293445137bc8a@changeid
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>firmware: coreboot: framebuffer: Ignore reserved pixel color bits</title>
<updated>2023-01-31T12:02:46+00:00</updated>
<author>
<name>Alper Nebi Yasak</name>
<email>alpernebiyasak@gmail.com</email>
</author>
<published>2023-01-22T19:04:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e6acaf25cba14661211bb72181c35dd13b24f5b3'/>
<id>e6acaf25cba14661211bb72181c35dd13b24f5b3</id>
<content type='text'>
The coreboot framebuffer doesn't support transparency, its 'reserved'
bit field is merely padding for byte/word alignment of pixel colors [1].
When trying to match the framebuffer to a simplefb format, the kernel
driver unnecessarily requires the format's transparency bit field to
exactly match this padding, even if the former is zero-width.

Due to a coreboot bug [2] (fixed upstream), some boards misreport the
reserved field's size as equal to its position (0x18 for both on a
'Lick' Chromebook), and the driver fails to probe where it would have
otherwise worked fine with e.g. the a8r8g8b8 or x8r8g8b8 formats.

Remove the transparency comparison with reserved bits. When the
bits-per-pixel and other color components match, transparency will
already be in a subset of the reserved field. Not forcing it to match
reserved bits allows the driver to work on the boards which misreport
the reserved field. It also enables using simplefb formats that don't
have transparency bits, although this doesn't currently happen due to
format support and ordering in linux/platform_data/simplefb.h.

[1] https://review.coreboot.org/plugins/gitiles/coreboot/+/4.19/src/commonlib/include/commonlib/coreboot_tables.h#255
[2] https://review.coreboot.org/plugins/gitiles/coreboot/+/4.13/src/drivers/intel/fsp2_0/graphics.c#82

Signed-off-by: Alper Nebi Yasak &lt;alpernebiyasak@gmail.com&gt;
Link: https://lore.kernel.org/r/20230122190433.195941-1-alpernebiyasak@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The coreboot framebuffer doesn't support transparency, its 'reserved'
bit field is merely padding for byte/word alignment of pixel colors [1].
When trying to match the framebuffer to a simplefb format, the kernel
driver unnecessarily requires the format's transparency bit field to
exactly match this padding, even if the former is zero-width.

Due to a coreboot bug [2] (fixed upstream), some boards misreport the
reserved field's size as equal to its position (0x18 for both on a
'Lick' Chromebook), and the driver fails to probe where it would have
otherwise worked fine with e.g. the a8r8g8b8 or x8r8g8b8 formats.

Remove the transparency comparison with reserved bits. When the
bits-per-pixel and other color components match, transparency will
already be in a subset of the reserved field. Not forcing it to match
reserved bits allows the driver to work on the boards which misreport
the reserved field. It also enables using simplefb formats that don't
have transparency bits, although this doesn't currently happen due to
format support and ordering in linux/platform_data/simplefb.h.

[1] https://review.coreboot.org/plugins/gitiles/coreboot/+/4.19/src/commonlib/include/commonlib/coreboot_tables.h#255
[2] https://review.coreboot.org/plugins/gitiles/coreboot/+/4.13/src/drivers/intel/fsp2_0/graphics.c#82

Signed-off-by: Alper Nebi Yasak &lt;alpernebiyasak@gmail.com&gt;
Link: https://lore.kernel.org/r/20230122190433.195941-1-alpernebiyasak@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>gsmi: fix null-deref in gsmi_get_variable</title>
<updated>2023-01-20T12:23:42+00:00</updated>
<author>
<name>Khazhismel Kumykov</name>
<email>khazhy@chromium.org</email>
</author>
<published>2023-01-18T01:02:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a769b05eeed7accc4019a1ed9799dd72067f1ce8'/>
<id>a769b05eeed7accc4019a1ed9799dd72067f1ce8</id>
<content type='text'>
We can get EFI variables without fetching the attribute, so we must
allow for that in gsmi.

commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore
access layer") added a new get_variable call with attr=NULL, which
triggers panic in gsmi.

Fixes: 74c5b31c6618 ("driver: Google EFI SMI")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Khazhismel Kumykov &lt;khazhy@google.com&gt;
Link: https://lore.kernel.org/r/20230118010212.1268474-1-khazhy@google.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We can get EFI variables without fetching the attribute, so we must
allow for that in gsmi.

commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore
access layer") added a new get_variable call with attr=NULL, which
triggers panic in gsmi.

Fixes: 74c5b31c6618 ("driver: Google EFI SMI")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Khazhismel Kumykov &lt;khazhy@google.com&gt;
Link: https://lore.kernel.org/r/20230118010212.1268474-1-khazhy@google.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi: efivars: drop kobject from efivars_register()</title>
<updated>2023-01-17T15:14:36+00:00</updated>
<author>
<name>Johan Hovold</name>
<email>johan+linaro@kernel.org</email>
</author>
<published>2023-01-17T12:43:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ade7fd908d710d0ab865c273df782c75528636ef'/>
<id>ade7fd908d710d0ab865c273df782c75528636ef</id>
<content type='text'>
Since commit 0f5b2c69a4cb ("efi: vars: Remove deprecated 'efivars' sysfs
interface") and the removal of the sysfs interface there are no users of
the efivars kobject.

Drop the kobject argument from efivars_register() and add a new
efivar_is_available() helper in favour of the old efivars_kobject().

Note that the new helper uses the prefix 'efivar' (i.e. without an 's')
for consistency with efivar_supports_writes() and the rest of the
interface (except the registration functions).

For the benefit of drivers with optional EFI support, also provide a
dummy implementation of efivar_is_available().

Signed-off-by: Johan Hovold &lt;johan+linaro@kernel.org&gt;
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Since commit 0f5b2c69a4cb ("efi: vars: Remove deprecated 'efivars' sysfs
interface") and the removal of the sysfs interface there are no users of
the efivars kobject.

Drop the kobject argument from efivars_register() and add a new
efivar_is_available() helper in favour of the old efivars_kobject().

Note that the new helper uses the prefix 'efivar' (i.e. without an 's')
for consistency with efivar_supports_writes() and the rest of the
interface (except the registration functions).

For the benefit of drivers with optional EFI support, also provide a
dummy implementation of efivar_is_available().

Signed-off-by: Johan Hovold &lt;johan+linaro@kernel.org&gt;
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
