- 20 Apr, 2023 6 commits
-
-
Thomas Zimmermann authored
Replace the architecture's fbdev helpers with the generic ones from <asm-generic/fb.h>. No functional changes. v2: * use default implementation for fb_pgprotect() (Arnd) Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Cc: Huacai Chen <chenhuacai@kernel.org> Cc: WANG Xuerui <kernel@xen0n.name> Acked-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Helge Deller <deller@gmx.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230417125651.25126-7-tzimmermann@suse.de
-
Thomas Zimmermann authored
Replace the architecture's fb_is_primary_device() with the generic one from <asm-generic/fb.h>. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Replace the architecture's fbdev helpers with the generic ones from <asm-generic/fb.h>. No functional changes. v2: * use default implementation for fb_pgprotect() (Arnd) Signed-off-by:
-
Thomas Zimmermann authored
Replace the architecture's fbdev helpers with the generic ones from <asm-generic/fb.h>. No functional changes. v2: * use default implementation for fb_pgprotect() (Arnd) Signed-off-by:
-
Thomas Zimmermann authored
Replace the architecture's fbdev helpers with the generic ones from <asm-generic/fb.h>. On arc, pgprot_writecombine() and pgprot_noncached() are the same; hence no functional changes. v3: * use default implementation for fb_pgprotect() (Arnd) Signed-off-by:
-
Thomas Zimmermann authored
Generic implementations of fb_pgprotect() and fb_is_primary_device() have been in the source code for a long time. Prepare the header file to make use of them. Improve the code by using an inline function for fb_pgprotect() and by removing include statements. The default mode set by fb_pgprotect() is now writecombine, which is what most platforms want. Symbols are protected by preprocessor guards. Architectures that provide a symbol need to define a preprocessor token of the same name and value. Otherwise the header file will provide a generic implementation. This pattern has been taken from <asm/io.h>. v3: * include the correct header files v2: * use writecombine mappings by default (Arnd) Signed-off-by:
-
- 19 Apr, 2023 2 commits
-
-
Maíra Canal authored
Currently, drm_gem_fb_create() doesn't check if the pixel format is supported, which can lead to the acceptance of invalid pixel formats e.g. the acceptance of invalid modifiers. Therefore, add a check for valid formats on drm_gem_fb_create(). Note that this check is only valid for atomic drivers, because, for non-atomic drivers, checking drm_any_plane_has_format() is not possible since the format list for the primary plane is fake, and we'd therefore reject valid formats. Adding this check to drm_gem_fb_create() will guarantee that the igt@kms_addfb_basic@addfb25-bad-modifier IGT test passes for drivers using this callback. This commit is a recapture of a series sent a while ago. Initially, I sent a patch [1] similar to this one in which I introduced the format check to drm_gem_fb_create(). Based on the feedback on the patch, I placed the check inside framebuffer_check() [2] so that it wouldn't be needed to hit any driver-specific code path when the check fails. Therefore, we could remove the check from the specific drivers (i915, amdgpu, and vmwgfx). But, with some new feedback, it was shown that introducing this check inside framebuffer_check() is problematic for the i915 driver [3]. For the i915 driver, in the legacy case, in which we don't get the modifier from the userspace, i915's fb_create hook computes the right modifier, which isn't necessarily linear. Therefore, if we check the modifier before that point, we might get wrong answers. So, I kept the check inside the i915 driver and removed the check from amdgpu and vmwgfx [4]. But, this yet hasn't solved the i915 problem [5]. As we cannot add the check inside framebuffer_check() without affecting the i915 behavior, this commit went back to the original patch. This way we can guarantee a more uniform behavior from the drivers that use the drm_gem_fb_create() callback. [1] https://lore.kernel.org/dri-devel/20230103125322.855089-1-mcanal@igalia.com/T/ [2] https://lore.kernel.org/dri-devel/20230109105807.18172-1-mcanal@igalia.com/T/ [3] https://lore.kernel.org/dri-devel/Y8AAdW2y7zN7DCUZ@intel.com/ [4] https://lore.kernel.org/dri-devel/20230113112743.188486-1-mcanal@igalia.com/T/ [5] https://lore.kernel.org/dri-devel/Y8FXWvEhO7GCRKVJ@intel.com/Signed-off-by:
Maíra Canal <mcanal@igalia.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Maíra Canal <mairacanal@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20230412142923.136707-1-mcanal@igalia.com
-
Danilo Krummrich authored
It already happend a few times that patches slipped through which implemented access to an entity through a job that was already removed from the entities queue. Since jobs and entities might have different lifecycles, this can potentially cause UAF bugs. In order to make it obvious that a jobs entity pointer shouldn't be accessed after drm_sched_entity_pop_job() was called successfully, set the jobs entity pointer to NULL once the job is removed from the entity queue. Moreover, debugging a potential NULL pointer dereference is way easier than potentially corrupted memory through a UAF. Signed-off-by:
Danilo Krummrich <dakr@redhat.com> Link: https://lore.kernel.org/r/20230418100453.4433-1-dakr@redhat.comReviewed-by:
Luben Tuikov <luben.tuikov@amd.com> Signed-off-by:
-
- 17 Apr, 2023 14 commits
-
-
Markus Elfring authored
The address of a data structure member was determined before a corresponding null pointer check in the implementation of the functions “nvkm_fanpwm_create” and “nvkm_fantog_create”. Thus avoid the risk for undefined behaviour by moving the assignment for the data structure member “fan” behind two null pointer checks. This issue was detected by using the Coccinelle software. Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Reviewed-by:
Karol Herbst <kherbst@redhat.com> Signed-off-by:
-
Markus Elfring authored
The variable “pbus” was read only once in the implementation of the function “nvkm_pcie_set_link”. Thus move the usage of an expression into a parameter for a function call. Signed-off-by:
-
Markus Elfring authored
The address of a data structure member was determined before a corresponding null pointer check in the implementation of the function “nvkm_pcie_set_link”. Thus avoid the risk for undefined behaviour by moving the assignment for the variable “subdev” behind some condition checks. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Markus Elfring authored
The address of a data structure member was determined before a corresponding null pointer check in the implementation of the function “nvkm_pstate_new”. Thus avoid the risk for undefined behaviour by moving the assignment for the variable “cstate” behind the null pointer check. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Markus Elfring authored
drm/nouveau/bios/power_budget: Move an expression into a macro call parameter in nvbios_power_budget_header() The address of a data structure member was determined before a corresponding null pointer check in the implementation of the function “nvbios_power_budget_header”. Thus avoid the risk for undefined behaviour by moving the usage of an expression into a parameter for a macro call in one if branch. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Markus Elfring authored
Five strings which did not contain a data format specification should be put into a sequence. Thus use the corresponding function “seq_puts”. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Markus Elfring authored
A single character (line break) should be put into a sequence. Thus use the corresponding function “seq_putc”. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Markus Elfring authored
drm/nouveau/debugfs: Move a variable assignment behind a null pointer check in nouveau_debugfs_pstate_get() The address of a data structure member was determined before a corresponding null pointer check in the implementation of the function “nouveau_debugfs_pstate_get”. Thus avoid the risk for undefined behaviour by moving the assignment for the variable “ctrl” behind the null pointer check. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Markus Elfring authored
drm/nouveau/debugfs: Move an expression into a function call parameter in nouveau_debugfs_pstate_set() The address of a data structure member was determined before a corresponding null pointer check in the implementation of the function “nouveau_debugfs_pstate_set”. Thus avoid the risk for undefined behaviour by moving the usage of an expression into a parameter for a function call at the end. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Konrad Dybcio authored
Some Lenovo J606F tablets come with a 2K (2000x1200) 60Hz 11" 5:3 video mode display. Add support for these panels. Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Jianhua Lu <lujianhua000@gmail.com> Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230412-topic-lenovopanel-v3-4-bcf9ba4de46f@linaro.org
-
Konrad Dybcio authored
Some bright vendors mount their display panels upside down. Add the required pieces to allow for accounting for that. Reviewed-by:
-
Konrad Dybcio authored
This chip supports controlling the backlight via DCS commands, on at least some panels. Add support for doing so. Note this may only concern the NT36523*W* variant. Nobody knows, really, there's no docs. Reviewed-by:
-
Konrad Dybcio authored
Some Lenovo J606F tablets come with a 2K (2000x1200) 60Hz 11" 5:3 video mode display. Document it and allow rotation while at it (Lenovo mounted it upside down!). Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Sui Jingfeng authored
The dma_resv_wait_timeout() function return a value greater than zero on success. Signed-off-by:
Sui Jingfeng <suijingfeng@loongson.cn> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
- 16 Apr, 2023 10 commits
-
-
Thomas Zimmermann authored
Backmerging drm-next to sync with msm tree. Resolves a conflict between aperture-helper changes and msm's use of those interfaces. Signed-off-by: -
Thomas Zimmermann authored
The hardware for gma500 is different from the rest, as it uses stolen framebuffer memory that is not available via PCI BAR. The regular PCI removal helper cannot detect the framebuffer, while the non-PCI helper misses possible conflicting VGA devices (i.e., a framebuffer or text console). Gma500 therefore calls both helpers to catch all cases. It's confusing as it implies that there's something about the PCI device that requires ownership management. The relationship between the PCI device and the VGA devices is non-obvious. At worst, readers might assume that calling two functions for clearing aperture ownership is a bug in the driver. Hence, move the PCI removal helper's code for VGA functionality into a separate function and call this function from gma500. Documents the purpose of each call to aperture helpers. The change contains comments and example code form the discussion at [1]. v5: * fix grammar in gma500 comment (Javier) Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230406132109.32050-10-tzimmermann@suse.de
-
Daniel Vetter authored
vga_default_device really is supposed to cover all corners, at least for x86. Additionally checking for rom shadowing should be redundant, because the bios/fw only does that for the boot vga device. If this turns out to be wrong, then most likely that's a special case which should be added to the vgaarb code, not replicated all over. Patch motived by changes to the aperture helpers, which also have this open code in a bunch of places, and which are all removed in a clean-up series. This function here is just for selecting the default fbdev device for fbcon, but I figured for consistency it might be good to throw this patch in on top. Note that the shadow rom check predates vgaarb, which was only wired up in commit 88674088 ("x86: Use vga_default_device() when determining whether an fb is primary"). That patch doesn't explain why we still fall back to the shadow rom check. v4: - fix commit message style (i.e., commit 1234 ("...")) - fix Daniel's S-o-b address v5: - add back an S-o-b tag with Daniel's Intel address Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
-
Daniel Vetter authored
Instead of calling aperture_remove_conflicting_devices() to remove the conflicting devices, just call to aperture_detach_devices() to detach the device that matches the same PCI BAR / aperture range. Since the former is just a wrapper of the latter plus a sysfb_disable() call, and now that's done in this function but only for the primary devices. This fixes a regression introduced by commit ee7a69aa ("fbdev: Disable sysfb device registration when removing conflicting FBs"), where we remove the sysfb when loading a driver for an unrelated pci device, resulting in the user losing their efifb console or similar. Note that in practice this only is a problem with the nvidia blob, because that's the only gpu driver people might install which does not come with an fbdev driver of it's own. For everyone else the real gpu driver will restore a working console. Also note that in the referenced bug there's confusion that this same bug also happens on amdgpu. But that was just another amdgpu specific regression, which just happened to happen at roughly the same time and with the same user-observable symptoms. That bug is fixed now, see https://bugzilla.kernel.org/show_bug.cgi?id=216331#c15 Note that we should not have any such issues on non-pci multi-gpu issues, because I could only find two such cases: - SoC with some external panel over spi or similar. These panel drivers do not use drm_aperture_remove_conflicting_framebuffers(), so no problem. - vga+mga, which is a direct console driver and entirely bypasses all this. For the above reasons the cc: stable is just notionally, this patch will need a backport and that's up to nvidia if they care enough. v2: - Explain a bit better why other multi-gpu that aren't pci shouldn't have any issues with making all this fully pci specific. v3 - polish commit message (Javier) v4: - Fix commit message style (i.e., commit 1234 ("...")) - fix Daniel's S-o-b address v5: - add back an S-o-b tag with Daniel's Intel address Fixes: ee7a69aa ("fbdev: Disable sysfb device registration when removing conflicting FBs") Tested-by:
Aaron Plattner <aplattner@nvidia.com> Reviewed-by:
-
Daniel Vetter authored
With the preceding patches it's become defunct. Also I'm about to add a different boolean argument, so it's better to keep the confusion down to the absolute minimum. v2: Since the hypervfb patch got droppped (it's only a pci device for gen1 vm, not for gen2) there is one leftover user in an actual driver left to touch. v4: - fixes to commit message - fix Daniel's S-o-b address v5: - add back an S-o-b tag with Daniel's Intel address Signed-off-by:
-
Daniel Vetter authored
A few reasons for this: - It's really the only one where this matters. I tried looking around, and I didn't find any non-pci vga-compatible controllers for x86 (since that's the only platform where we had this until a few patches ago), where a driver participating in the aperture claim dance would interfere. - I also don't expect that any future bus anytime soon will not just look like pci towards the OS, that's been the case for like 25+ years by now for practically everything (even non non-x86). - Also it's a bit funny if we have one part of the vga removal in the pci function, and the other in the generic one. v2: Rebase. v4: - fix Daniel's S-o-b address v5: - add back an S-o-b tag with Daniel's Intel address Signed-off-by:
-
Daniel Vetter authored
Otherwise it's a bit silly, and we might throw out the driver for the screen the user is actually looking at. I haven't found a bug report for this case yet, but we did get bug reports for the analog case where we're throwing out the efifb driver. v2: Flip the check around to make it clear it's a special case for kicking out the vgacon driver only (Thomas) v4: - fixes to commit message - fix Daniel's S-o-b address v5: - add back an S-o-b tag with Daniel's Intel address Link: https://bugzilla.kernel.org/show_bug.cgi?id=216303Signed-off-by:
-
Daniel Vetter authored
Only really pci devices have a business setting this - it's for figuring out whether the legacy vga stuff should be nuked too. And with the preceding two patches those are all using the pci version of this. Which means for all other callers primary == false and we can remove it now. v2: - Reorder to avoid compile fail (Thomas) - Include gma500, which retained it's called to the non-pci version. v4: - fix Daniel's S-o-b address v5: - add back an S-o-b tag with Daniel's Intel address Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Acked-by:
Thierry Reding <treding@nvidia.com> Reviewed-by:
-
Daniel Vetter authored
Since vgaarb has been promoted to be a core piece of the pci subsystem we don't have to open code random guesses anymore, we actually know this in a platform agnostic way, and there's no need for an x86 specific hack. See also commit 1d38fe6e ("PCI/VGA: Move vgaarb to drivers/pci") This should not result in any functional change, and the non-x86 multi-gpu pci systems are probably rare enough to not matter (I don't know of any tbh). But it's a nice cleanup, so let's do it. There's been a few questions on previous iterations on dri-devel and irc: - fb_is_primary_device() seems to be yet another implementation of this theme, and at least on x86 it checks for both vga_default_device OR rom shadowing. There shouldn't ever be a case where rom shadowing gives any additional hints about the boot vga device, but if there is then the default vga selection in vgaarb should probably be fixed. And not special-case checks replicated all over. - Thomas also brought up that on most !x86 systems fb_is_primary_device() returns 0, except on sparc/parisc. But these 2 special cases are about platform specific devices and not pci, so shouldn't have any interactions. - Furthermore fb_is_primary_device() is a bit a red herring since it's only used to select the right fbdev driver for fbcon, and not for the fw handover dance which the aperture helpers handle. At least for x86 we might want to look into unifying them, but that's a separate thing. v2: Extend commit message trying to summarize various discussions. v4: - make the test for the primary device easier to read (Javier) - fix commit message style (i.e., commit 1234 ("...")) - fix Daniel's S-o-b address v5: - add back an S-o-b tag with Daniel's Intel address Signed-off-by:
-
Daniel Vetter authored
This one nukes all framebuffers, which is a bit much. In reality gma500 is igpu and never shipped with anything discrete, so there should not be any difference. v2: Unfortunately the framebuffer sits outside of the pci bars for gma500, and so only using the pci helpers won't be enough. Otoh if we only use non-pci helper, then we don't get the vga handling, and subsequent refactoring to untangle these special cases won't work. It's not pretty, but the simplest fix (since gma500 really is the only quirky pci driver like this we have) is to just have both calls. v4: - fix Daniel's S-o-b address v5: - add back an S-o-b tag with Daniel's Intel address Signed-off-by:
-
- 15 Apr, 2023 1 commit
-
-
Dan Carpenter authored
The devm_drm_dev_alloc() function returns error pointers. It never returns NULL. Fix the check. Fixes: c87e859c ("drm/imx/lcdc: Implement DRM driver for imx25") Signed-off-by:
Dan Carpenter <error27@gmail.com> Reviewed-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
- 14 Apr, 2023 2 commits
-
-
Fabio Estevam authored
i.MX6SX has a single LVDS port and share a similar LDB_CTRL register layout with i.MX8MP and i.MX93. There is no LVDS CTRL register on the i.MX6SX, so only write to this register on the appropriate SoCs. Add support for the i.MX6SX LDB. Tested on a imx6sx-sdb board with a Hannstar HSD100PXN1 LVDS panel and also on a custom i.MX6SX-based board. Signed-off-by:
Fabio Estevam <festevam@denx.de> Reviewed-by:
Marek Vasut <marex@denx.de> Signed-off-by:
-
Fabio Estevam authored
i.MX6SX has a single LVDS port and share a similar LDB_CTRL register layout with i.MX8MP and i.MX93. Signed-off-by:
-
- 13 Apr, 2023 1 commit
-
-
Daniel Vetter authored
Merge tag 'drm-intel-next-fixes-2023-04-13' of git://anongit.freedesktop.org/drm/drm-intel into drm-next Just one Cc:stable fix for sampler indirect state in bindless heap. Signed-off-by:
-
- 12 Apr, 2023 4 commits
-
-
git://anongit.freedesktop.org/drm/drm-miscDaniel Vetter authored
drm-misc-next for v6.4-rc1: Cross-subsystem Changes: - Convert MIPI DSIM bridge dt to yaml. Core Changes: - Fix UAF race in drm scheduler. Driver Changes: - Add primary plane positioning support to VKMS. - Convert omapdrm fbdev emulation to in-kernel client. - Assorted small fixes to vkms, vc4, nouveau, vmwgfx. Signed-off-by:
-
Maíra Canal authored
Use drmm_mode_config_init() instead of drm_mode_config_init(), as it allows us to assure that the resource will be properly cleaned. Signed-off-by:
-
Maíra Canal authored
Use drmm_crtc_init_with_planes() instead of drm_crtc_init_with_planes() to get rid of the explicit destroy hook in struct drm_crtc_funcs. Signed-off-by:
-
Daniel Vetter authored
Otherwise core changes don't get noticed by the right people. I noticed this because a patch set from Jagan Teki seems to have fallen through the cracks. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Acked-by:
Jagan Teki <jagan@amarulasolutions.com> [narmstrong: fixed ordering & Daniel's SoB] Signed-off-by:
-
