- 25 Jan, 2022 1 commit
-
-
Manasi Navare authored
In case of a modeset where a mode gets split across multiple CRTCs in the driver specific implementation (bigjoiner in i915) we wrongly count the affected CRTCs based on the drm_crtc_mask and indicate the stolen CRTC as an affected CRTC in atomic_check_only(). This triggers a warning since affected CRTCs doent match requested CRTC. To fix this in such bigjoiner configurations, we should only increment affected crtcs if that CRTC is enabled in UAPI not if it is just used internally in the driver to split the mode. v3: Add the same uapi crtc_state->enable check in requested crtc calc (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Simon Ser <contact@emersion.fr> Cc: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Cc: Daniel Stone <daniels@collabora.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v5.11+ Fixes: 919c2299 ("drm/i915: Enable bigjoiner") Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211004115913.23889-1-manasi.d.navare@intel.com
-
- 14 Jan, 2022 1 commit
-
-
Johannes Berg authored
Even if it's probably not really useful, it can get selected by e.g. randconfig builds, and then failing to compile is an annoyance. Unfortunately, it's hard to fix in Kconfig, since DRM_TTM is selected by many things that don't really depend on any specific architecture, and just depend on PCI (which is indeed now available in ARCH=um via simulation/emulation). Fix this in the code instead by just ifdef'ing the relevant two lines that depend on "real X86". Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211220111519.a4c8c6eff702.Ie4cf4e68698f6a9f546b83379bc52c266504424f@changeid
-
- 13 Jan, 2022 1 commit
-
-
Weizhao Ouyang authored
Fix cma_heap_buffer mutex locking critical section to protect vmap_cnt and vaddr. Fixes: a5d2d29e ("dma-buf: heaps: Move heap-helper logic into the cma_heap implementation") Signed-off-by:
Weizhao Ouyang <o451686892@gmail.com> Acked-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220104073545.124244-1-o451686892@gmail.com
-
- 12 Jan, 2022 1 commit
-
-
Javier Martinez Canillas authored
The vga16fb framebuffer driver only supports Enhanced Graphics Adapter (EGA) and Video Graphics Array (VGA) 16 color graphic cards. But it doesn't check if the adapter is one of those or if a VGA16 mode is used. This means that the driver will be probed even if a VESA BIOS Extensions (VBE) or Graphics Output Protocol (GOP) interface is used. This issue has been present for a long time but it was only exposed by commit d391c582 ("drivers/firmware: move x86 Generic System Framebuffers support") since the platform device registration to match the {vesa,efi}fb drivers is done later as a consequence of that change. All non-x86 architectures though treat orig_video_isVGA as a boolean so only do the supported video mode check for x86 and not for other arches. Link: https://bugzilla.kernel.org/show_bug.cgi?id=215001 Fixes: d391c582 ("drivers/firmware: move x86 Generic System Framebuffers support") Reported-by:
Kris Karas <bugs-a21@moonlit-rail.com> Cc: <stable@vger.kernel.org> # 5.15.x Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Tested-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220110095625.278836-3-javierm@redhat.com
-
- 11 Jan, 2022 1 commit
-
-
Miaoqian Lin authored
The reference taken by 'of_find_device_by_node()' must be released when not needed anymore. Add the corresponding 'put_device()' in the error handling path. Fixes: 9bf37977 ("drm/sun4i: dw-hdmi: Make HDMI PHY into a platform device") Signed-off-by:
Miaoqian Lin <linmq006@gmail.com> Signed-off-by:
-
- 03 Jan, 2022 2 commits
-
-
Alexander Stein authored
This is used in meson-gx and meson-g12. Add the property to the binding. This fixes the dtschema warning: hdmi-tx@c883a000: 'sound-name-prefix' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by:
Alexander Stein <alexander.stein@mailbox.org> Fixes: 376bf52d ("dt-bindings: display: amlogic, meson-dw-hdmi: convert to yaml") Acked-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
Alexander Stein authored
This property was already mentioned in the old textual bindings amlogic,meson-vpu.txt, but got dropped during conversion. Adding it back similar to amlogic,gx-vdec.yaml. Fixes: 6b9ebf1e ("dt-bindings: display: amlogic, meson-vpu: convert to yaml") Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
-
- 21 Dec, 2021 1 commit
-
-
Christian König authored
Always waiting for the exclusive fence resulted on some performance regressions. So try to wait for the shared fences first, then the exclusive fence should always be signaled already. v2: fix incorrectly placed "(", add some comment why we do this. Signed-off-by:Christian König <christian.koenig@amd.com> Tested-by:
Stefan Fritsch <sf@sfritsch.de> Tested-by:
Dan Moulding <dmoulding@me.com> Acked-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
- 17 Dec, 2021 1 commit
-
-
Christian König authored
bo->tbo.resource can now be NULL. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211210083927.1754-1-christian.koenig@amd.com
-
- 14 Dec, 2021 1 commit
-
-
Jiasheng Jiang authored
The return value of kzalloc() needs to be checked. To avoid use of null pointer '&ast_state->base' in case of the failure of alloc. Fixes: f0adbc38 ("drm/ast: Allocate initial CRTC state of the correct size") Signed-off-by:
Jiasheng Jiang <jiasheng@iscas.ac.cn> Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20211214014126.2211535-1-jiasheng@iscas.ac.cn
-
- 13 Dec, 2021 1 commit
-
-
Alejandro Concepcion-Rodriguez authored
Pixel clock has to be set in kHz. Signed-off-by:
Alejandro Concepcion-Rodriguez <asconcepcion@acoro.eu> Fixes: 11e8f5fd ("drm: Add simpledrm driver") Signed-off-by:
-
- 09 Dec, 2021 1 commit
-
-
Javier Martinez Canillas authored
This reverts commit b3484d2b. That change attempted to improve the DRM drivers fbdev emulation device names to avoid having confusing names like "simpledrmdrmfb" in /proc/fb. But unfortunately, there are user-space programs such as pm-utils that match against the fbdev names and so broke after the mentioned commit. Since the names in /proc/fb are used by tools that consider it an uAPI, let's restore the old names even when this lead to silly names like the one mentioned above. Fixes: b3484d2b ("drm/fb-helper: improve DRM fbdev emulation device names") Reported-by:
Johannes Stezenbach <js@sig21.net> Signed-off-by:
-
- 08 Dec, 2021 1 commit
-
-
Bas Nieuwenhuizen authored
dma_fence_chain_find_seqno only ever returns the top fence in the chain or an unsignalled fence. Hence if we request a seqno that is already signalled it returns a NULL fence. Some callers are not prepared to handle this, like the syncobj transfer functions for example. This behavior is "new" with timeline syncobj and it looks like not all callers were updated. To fix this behavior make sure that a successful drm_sync_find_fence always returns a non-NULL fence. v2: Move the fix to drm_syncobj_find_fence from the transfer functions. Fixes: ea569910 ("drm/syncobj: add transition iotcls between binary and timeline v2") Cc: stable@vger.kernel.org Signed-off-by:Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by:
-
- 03 Dec, 2021 1 commit
-
-
Christian König authored
Commit 7120a447 ("drm/ttm: Double check mem_type of BO while eviction") made ttm_bo_evict_swapout_allowable() function actually check the placement, but we always used a dummy placement in ttm_bo_swapout. Fix this by using the real placement instead. Signed-off-by:
Pan, Xinhui <Xinhui.Pan@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211202103828.44573-1-christian.koenig@amd.com
-
- 01 Dec, 2021 1 commit
-
-
Guangming authored
For previous version, it uses 'sg_table.nent's to traverse sg_table in pages free flow. However, 'sg_table.nents' is reassigned in 'dma_map_sg', it means the number of created entries in the DMA adderess space. So, use 'sg_table.nents' in pages free flow will case some pages can't be freed. Here we should use sg_table.orig_nents to free pages memory, but use the sgtable helper 'for each_sgtable_sg'(, instead of the previous rather common helper 'for_each_sg' which maybe cause memory leak) is much better. Fixes: d963ab0f ("dma-buf: system_heap: Allocate higher order pages if available") Signed-off-by:
Guangming <Guangming.Cao@mediatek.com> Reviewed-by:
Robin Murphy <robin.murphy@arm.com> Cc: <stable@vger.kernel.org> # 5.11.* Reviewed-by:
-
- 29 Nov, 2021 8 commits
-
-
Maxime Ripard authored
Our current code is supposed to serialise the commits by waiting for all the drm_crtc_commits associated to the previous HVS state. However, assuming we have two CRTCs running and being configured and we configure each one alternately, we end up in a situation where we're not waiting at all. Indeed, starting with a state (state 0) where both CRTCs are running, and doing a commit (state 1) on the first CRTC (CRTC 0), we'll associate its commit to its assigned FIFO in vc4_hvs_state. If we get a new commit (state 2), this time affecting the second CRTC (CRTC 1), the DRM core will allow both commits to execute in parallel (assuming they don't have any share resources). Our code in vc4_atomic_commit_tail is supposed to make sure we only get one commit at a time and serialised by order of submission. It does so by using for_each_old_crtc_in_state, making sure that the CRTC has a FIFO assigned, is used, and has a commit pending. If it does, then we'll wait for the commit before going forward. During the transition from state 0 to state 1, as our old CRTC state we get the CRTC 0 state 0, its commit, we wait for it, everything works fine. During the transition from state 1 to state 2 though, the use of for_each_old_crtc_in_state is wrong. Indeed, while the code assumes it's returning the state of the CRTC in the old state (so CRTC 0 state 1), it actually returns the old state of the CRTC affected by the current commit, so CRTC 0 state 0 since it wasn't part of state 1. Due to this, if we alternate between the configuration of CRTC 0 and CRTC 1, we never actually wait for anything since we should be waiting on the other every time, but it never is affected by the previous commit. Change the logic to, at every commit, look at every FIFO in the previous HVS state, and if it's in use and has a commit associated to it, wait for that commit. Fixes: 9ec03d7f ("drm/vc4: kms: Wait on previous FIFO users before a commit") Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Tested-by:
Jian-Hong Pan <jhp@endlessos.org> Link: https://lore.kernel.org/r/20211117094527.146275-7-maxime@cerno.tech
-
Maxime Ripard authored
Our HVS global state, when duplicated, will also copy the pointer to the drm_crtc_commit (and increase the reference count) for each FIFO if the pointer is not NULL. However, our atomic_setup function will overwrite that pointer without putting the reference back leading to a memory leak. Since the commit is only relevant during the atomic commit process, it doesn't make sense to duplicate the reference to the commit anyway. Let's remove it. Fixes: 9ec03d7f ("drm/vc4: kms: Wait on previous FIFO users before a commit") Signed-off-by:
-
Maxime Ripard authored
Commit 9ec03d7f ("drm/vc4: kms: Wait on previous FIFO users before a commit") introduced a wait on the previous commit done on a given HVS FIFO. However, we never cleared that pointer once done. Since drm_crtc_commit_put can free the drm_crtc_commit structure directly if we were the last user, this means that it can lead to a use-after free if we were to duplicate the state, and that stale pointer would even be copied to the new state. Set the pointer to NULL once we're done with the wait so that we don't carry over a pointer to a free'd structure. Fixes: 9ec03d7f ("drm/vc4: kms: Wait on previous FIFO users before a commit") Signed-off-by:
-
Maxime Ripard authored
Commit 9ec03d7f ("drm/vc4: kms: Wait on previous FIFO users before a commit") introduced a global state for the HVS, with each FIFO storing the current CRTC commit so that we can properly synchronize commits. However, the refcounting was off and we thus ended up leaking the drm_crtc_commit structure every commit. Add a drm_crtc_commit_put to prevent the leakage. Fixes: 9ec03d7f ("drm/vc4: kms: Wait on previous FIFO users before a commit") Signed-off-by:
-
Maxime Ripard authored
The HVS global state functions return an error pointer, but in most cases we check if it's NULL, possibly resulting in an invalid pointer dereference. Fixes: 9ec03d7f ("drm/vc4: kms: Wait on previous FIFO users before a commit") Signed-off-by:
-
Maxime Ripard authored
Several DRM/KMS atomic commits can run in parallel if they affect different CRTC. These commits share the global HVS state, so we have some code to make sure we run commits in sequence. This synchronization code is one of the first thing that runs in vc4_atomic_commit_tail(). Another constraints we have is that we need to make sure the HVS clock gets a boost during the commit. That code relies on clk_set_min_rate and will remove the old minimum and set a new one. We also need another, temporary, minimum for the duration of the commit. The algorithm is thus to set a temporary minimum, drop the previous one, do the commit, and finally set the minimum for the current mode. However, the part that sets the temporary minimum and drops the older one runs before the commit synchronization code. Thus, under the proper conditions, we can end up mixing up the minimums and ending up with the wrong one for our current step. To avoid it, let's move the clock setup in the protected section. Fixes: d7d96c00 ("drm/vc4: hvs: Boost the core clock during modeset") Signed-off-by:
-
Gurchetan Singh authored
With the use of dummy events, we can drop virtgpu specific behavior. Fixes: cd7f5ca3 ("drm/virtio: implement context init: add virtio_gpu_fence_event") Reported-by:
Gurchetan Singh <gurchetansingh@chromium.org> Reviewed-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Gurchetan Singh authored
The current virtgpu implementation of poll(..) drops events when VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK is enabled (otherwise it's like a normal DRM driver). This is because paravirtualized userspaces receives responses in a buffer of type BLOB_MEM_GUEST, not by read(..). To be in line with other DRM drivers and avoid specialized behavior, it is possible to define a dummy event for virtgpu. Paravirtualized userspace will now have to call read(..) on the DRM fd to receive the dummy event. Fixes: b1079043 ("drm/virtgpu api: create context init feature") Reported-by:
-
- 23 Nov, 2021 1 commit
-
-
Mohammed Gamal authored
The Hyper-V DRM driver tries to free MMIO region on removing the device regardless of VM type, while Gen1 VMs don't use MMIO and hence causing the kernel to crash on a NULL pointer dereference. Fix this by making deallocating MMIO only on Gen2 machines and implement removal for Gen1 Fixes: 76c56a5a ("drm/hyperv: Add DRM driver for hyperv synthetic video device") Signed-off-by:
Mohammed Gamal <mgamal@redhat.com> Reviewed-by:
Deepak Rawat <drawat.floss@gmail.com> Signed-off-by:
-
- 19 Nov, 2021 2 commits
-
-
Joel Stanley authored
Before the drm driver had support for this file there was a driver that exposed the contents of the vga password register to userspace. It would present the entire register instead of interpreting it. The drm implementation chose to mask of the lower bit, without explaining why. This breaks the existing userspace, which is looking for 0xa8 in the lower byte. Change our implementation to expose the entire register. Fixes: 696029eb ("drm/aspeed: Add sysfs for output settings") Reported-by:
Oskar Senft <osk@google.com> Signed-off-by:
Joel Stanley <joel@jms.id.au> Reviewed-by:
Jeremy Kerr <jk@codeconstruct.com.au> Tested-by:
-
Dan Carpenter authored
The ->gem_create_object() functions are supposed to return NULL if there is an error. None of the callers expect error pointers so returing one will lead to an Oops. See drm_gem_vram_create(), for example. Fixes: c826a6e1 ("drm/vc4: Add a BO cache.") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
- 18 Nov, 2021 2 commits
-
-
Dan Carpenter authored
The nvkm_acr_lsfw_add() function never returns NULL. It returns error pointers on error. Fixes: 22dcda45 ("drm/nouveau/acr: implement new subdev to replace "secure boot"") Signed-off-by:
Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211118111314.GB1147@kili
-
Ben Skeggs authored
I've got HW now, appears to work as expected so far. Signed-off-by:
-
- 17 Nov, 2021 2 commits
-
-
Javier Martinez Canillas authored
The efifb and simplefb drivers just render to a pre-allocated frame buffer and rely on the display hardware being initialized before the kernel boots. But if another driver already probed correctly and registered a fbdev, the generic drivers shouldn't be probed since an actual driver for the display hardware is already present. This is more likely to occur after commit d391c582 ("drivers/firmware: move x86 Generic System Framebuffers support") since the "efi-framebuffer" and "simple-framebuffer" platform devices are registered at a later time. Link: https://lore.kernel.org/r/20211110200253.rfudkt3edbd3nsyj@lahvuun/ Fixes: d391c582 ("drivers/firmware: move x86 Generic System Framebuffers support") Reported-by:
Ilya Trukhanov <lahvuun@gmail.com> Cc: <stable@vger.kernel.org> # 5.15.x Signed-off-by:
-
Rob Clark authored
drm_sched_job_add_dependency() could drop the last ref, so we need to do the dma_fence_get() first. Cc: Christian König <christian.koenig@amd.com> Fixes: 9c2ba265 ("drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2") Signed-off-by:
Rob Clark <robdclark@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211116155545.473311-1-robdclark@gmail.comReviewed-by:
Amit Pundir <amit.pundir@linaro.org> Signed-off-by:
-
- 16 Nov, 2021 2 commits
-
-
Christian König authored
Trivial fix since we now need to grab a reference to the fence we have added. Previously the dma_resv function where doing that for us. Signed-off-by:
Nicolas Frattaroli <frattaroli.nicolas@gmail.com> References: https://lore.kernel.org/dri-devel/2023306.UmlnhvANQh@archbook/Tested-by:
Yassine Oudjana <y.oudjana@protonmail.com>
-
Maxime Ripard authored
We need -rc1 to address a breakage in drm/scheduler affecting panfrost. Signed-off-by:
-
- 15 Nov, 2021 2 commits
-
-
Julian Braha authored
When PHY_SUN6I_MIPI_DPHY is selected, and RESET_CONTROLLER is not selected, Kbuild gives the following warning: WARNING: unmet direct dependencies detected for PHY_SUN6I_MIPI_DPHY Depends on [n]: (ARCH_SUNXI [=n] || COMPILE_TEST [=y]) && HAS_IOMEM [=y] && COMMON_CLK [=y] && RESET_CONTROLLER [=n] Selected by [y]: - DRM_SUN6I_DSI [=y] && HAS_IOMEM [=y] && DRM_SUN4I [=y] This is because DRM_SUN6I_DSI selects PHY_SUN6I_MIPI_DPHY without selecting or depending on RESET_CONTROLLER, despite PHY_SUN6I_MIPI_DPHY depending on RESET_CONTROLLER. These unmet dependency bugs were detected by Kismet, a static analysis tool for Kconfig. Please advise if this is not the appropriate solution. v2: Fixed indentation to match the rest of the file. Signed-off-by:
Julian Braha <julianbraha@gmail.com> Acked-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by:
-
Thomas Zimmermann authored
The GEM CMA helpers allocate non-coherent (i.e., cached) backing storage with dma_alloc_noncoherent(), but release it with dma_free_wc(). Fix this with a call to dma_free_noncoherent(). Writecombining storage is still released with dma_free_wc(). Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v5.14+ Link: https://patchwork.freedesktop.org/patch/msgid/20210708175146.10618-1-tzimmermann@suse.de
-
- 14 Nov, 2021 6 commits
-
-
Linus Torvalds authored
-
Gustavo A. R. Silva authored
Add Kconfig support for -Wimplicit-fallthrough for both GCC and Clang. The compiler option is under configuration CC_IMPLICIT_FALLTHROUGH, which is enabled by default. Special thanks to Nathan Chancellor who fixed the Clang bug[1][2]. This bugfix only appears in Clang 14.0.0, so older versions still contain the bug and -Wimplicit-fallthrough won't be enabled for them, for now. This concludes a long journey and now we are finally getting rid of the unintentional fallthrough bug-class in the kernel, entirely. :) Link: https://github.com/llvm/llvm-project/commit/9ed4a94d6451046a51ef393cd62f00710820a7e8 [1] Link: https://bugs.llvm.org/show_bug.cgi?id=51094 [2] Link: https://github.com/KSPP/linux/issues/115 Link: https://github.com/ClangBuiltLinux/linux/issues/236Co-developed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by:
Nathan Chancellor <nathan@kernel.org> Tested-by:
-
git://git.kernel.org/pub/scm/fs/xfs/xfs-linuxLinus Torvalds authored
Pull xfs cleanups from Darrick Wong: "The most 'exciting' aspect of this branch is that the xfsprogs maintainer and I have worked through the last of the code discrepancies between kernel and userspace libxfs such that there are no code differences between the two except for #includes. IOWs, diff suffices to demonstrate that the userspace tools behave the same as the kernel, and kernel-only bits are clearly marked in the /kernel/ source code instead of just the userspace source. Summary: - Clean up open-coded swap() calls. - A little bit of #ifdef golf to complete the reunification of the kernel and userspace libxfs source code" * tag 'xfs-5.16-merge-5' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: xfs: sync xfs_btree_split macros with userspace libxfs xfs: #ifdef out perag code for userspace xfs: use swap() to make dabtree code cleaner -
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linuxLinus Torvalds authored
Pull more parisc fixes from Helge Deller: "Fix a build error in stracktrace.c, fix resolving of addresses to function names in backtraces, fix single-stepping in assembly code and flush userspace pte's when using set_pte_at()" * tag 'for-5.16/parisc-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc/entry: fix trace test in syscall exit path parisc: Flush kernel data mapping in set_pte_at() when installing pte for user page parisc: Fix implicit declaration of function '__kernel_text_address' parisc: Fix backtrace to always include init funtion names
-
git://git.libc.org/linux-shLinus Torvalds authored
Pull arch/sh updates from Rich Felker. * tag 'sh-for-5.16' of git://git.libc.org/linux-sh: sh: pgtable-3level: Fix cast to pointer from integer of different size sh: fix READ/WRITE redefinition warnings sh: define __BIG_ENDIAN for math-emu sh: math-emu: drop unused functions sh: fix kconfig unmet dependency warning for FRAME_POINTER sh: Cleanup about SPARSE_IRQ sh: kdump: add some attribute to function maple: fix wrong return value of maple_bus_init(). sh: boot: avoid unneeded rebuilds under arch/sh/boot/compressed/ sh: boot: add intermediate vmlinux.bin* to targets instead of extra-y sh: boards: Fix the cacography in irq.c sh: check return code of request_irq sh: fix trivial misannotations
-
git://git.armlinux.org.uk/~rmk/linux-armLinus Torvalds authored
Pull ARM fixes from Russell King: - Fix early_iounmap - Drop cc-option fallbacks for architecture selection * tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm: ARM: 9156/1: drop cc-option fallbacks for architecture selection ARM: 9155/1: fix early early_iounmap()
-
