]> git.ipfire.org Git - thirdparty/openembedded/openembedded-core-contrib.git/commitdiff
linux-yocto/5.15: fix ppc boot
authorBruce Ashfield <bruce.ashfield@gmail.com>
Thu, 28 Apr 2022 13:47:54 +0000 (09:47 -0400)
committerRichard Purdie <richard.purdie@linuxfoundation.org>
Sun, 1 May 2022 20:55:58 +0000 (21:55 +0100)
The 5.15-stable series pulled in the following commit:

   commit c894ac44786cfed383a6c6b20c1bfb12eb96018a
   Author: Thomas Zimmermann <tzimmermann@suse.de>
   Date:   Tue Jan 25 10:12:18 2022 +0100

    fbdev: Hot-unplug firmware fb devices on forced removal

    commit 27599aacbaefcbf2af7b06b0029459bbf682000d upstream.

    Hot-unplug all firmware-framebuffer devices as part of removing
    them via remove_conflicting_framebuffers() et al. Releases all
    memory regions to be acquired by native drivers.

    Firmware, such as EFI, install a framebuffer while posting the
    computer. After removing the firmware-framebuffer device from fbdev,
    a native driver takes over the hardware and the firmware framebuffer
    becomes invalid.

    Firmware-framebuffer drivers, specifically simplefb, don't release
    their device from Linux' device hierarchy. It still owns the firmware
    framebuffer and blocks the native drivers from loading. This has been
    observed in the vmwgfx driver. [1]

    Initiating a device removal (i.e., hot unplug) as part of
    remove_conflicting_framebuffers() removes the underlying device and
    returns the memory range to the system.

    [1] https://lore.kernel.org/dri-devel/20220117180359.18114-1-zack@kde.org/

    v2:
            * rename variable 'dev' to 'device' (Javier)

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reported-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
CC: stable@vger.kernel.org # v5.11+
Link: https://patchwork.freedesktop.org/patch/msgid/20220125091222.21457-2-tzimmermann@suse.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
And this is causing qemuppc to panic during boot when manipulating
the fbdev.

Reverting it fixes the problem, and won't cause issues for other
platforms, so we revert it.

Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
meta/recipes-kernel/linux/linux-yocto_5.15.bb

index bba1200fe7e41561a8535c65207f15409dce25e5..d7250ca4d54e65895fc0569fd07f0bc70e5246e9 100644 (file)
@@ -11,8 +11,8 @@ python () {
         raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "85ebb3e98ee184fad92eedd79f006df9809f01ff"
-SRCREV_meta ?= "645b337371e7e080e71f7d7f2435326242451a95"
+SRCREV_machine ?= "ec729d37e4036fe80d0294684aa779c091466307"
+SRCREV_meta ?= "71a82e181708bc619684cc9f1eea01ec2595c2ff"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
            git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.15;destsuffix=${KMETA}"
index 27373660c7c23e830a58a0d51d955161e3c06fd0..2de1be9e46d76bd533ef6cad63f7d220ba9fe83a 100644 (file)
@@ -14,8 +14,8 @@ DEPENDS += "openssl-native util-linux-native"
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "41f36834f2236bd22ab8c33ad1908da029bef79d"
-SRCREV_meta ?= "645b337371e7e080e71f7d7f2435326242451a95"
+SRCREV_machine ?= "9f43f6966b7ef3cc76c465e1f53fe353740155df"
+SRCREV_meta ?= "71a82e181708bc619684cc9f1eea01ec2595c2ff"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
index 62b16e4f9e294ee6f0c36a147e5e353597816771..83e484693b800499080d59083b7fe129eff62c02 100644 (file)
@@ -13,17 +13,17 @@ KBRANCH:qemux86  ?= "v5.15/standard/base"
 KBRANCH:qemux86-64 ?= "v5.15/standard/base"
 KBRANCH:qemumips64 ?= "v5.15/standard/mti-malta64"
 
-SRCREV_machine:qemuarm ?= "8f765250a60ba7a94935709d4d0f0edffd366990"
-SRCREV_machine:qemuarm64 ?= "35a6bda405ab207447b0e088b71fd8a9dab566e4"
-SRCREV_machine:qemumips ?= "d413054d21fe14e8111ee2396e07b4c15e0a2e77"
-SRCREV_machine:qemuppc ?= "33bdc98e5f267d7715cc1eb6d9c461616c05555b"
-SRCREV_machine:qemuriscv64 ?= "7ba4cb36fd4f3da81698b3e519e763aaa142659f"
-SRCREV_machine:qemuriscv32 ?= "7ba4cb36fd4f3da81698b3e519e763aaa142659f"
-SRCREV_machine:qemux86 ?= "7ba4cb36fd4f3da81698b3e519e763aaa142659f"
-SRCREV_machine:qemux86-64 ?= "7ba4cb36fd4f3da81698b3e519e763aaa142659f"
-SRCREV_machine:qemumips64 ?= "19d4c0deafc3b5359ab9af9d092a36feee0d891b"
-SRCREV_machine ?= "7ba4cb36fd4f3da81698b3e519e763aaa142659f"
-SRCREV_meta ?= "645b337371e7e080e71f7d7f2435326242451a95"
+SRCREV_machine:qemuarm ?= "5c287562703770d5e466893c53bb9fca16b16fe8"
+SRCREV_machine:qemuarm64 ?= "158f38930aa53b07009980cf417fbcddea58807d"
+SRCREV_machine:qemumips ?= "2ebd4e128f3f0ad1bff5677f593a545053f9ff91"
+SRCREV_machine:qemuppc ?= "566f4e67a086fbdeb17ebe3b7537f9f345001cd0"
+SRCREV_machine:qemuriscv64 ?= "4e7122625996261d870160dfd2096108742f1009"
+SRCREV_machine:qemuriscv32 ?= "4e7122625996261d870160dfd2096108742f1009"
+SRCREV_machine:qemux86 ?= "4e7122625996261d870160dfd2096108742f1009"
+SRCREV_machine:qemux86-64 ?= "4e7122625996261d870160dfd2096108742f1009"
+SRCREV_machine:qemumips64 ?= "2aafd732abb0b9011e2041c7c5c9ab3f475dedd1"
+SRCREV_machine ?= "4e7122625996261d870160dfd2096108742f1009"
+SRCREV_meta ?= "71a82e181708bc619684cc9f1eea01ec2595c2ff"
 
 # set your preferred provider of linux-yocto to 'linux-yocto-upstream', and you'll
 # get the <version>/base branch, which is pure upstream -stable, and the same