- 28 Jul, 2021 5 commits
-
-
Desmond Cheong Zhi Xi authored
Inside drm_is_current_master, using the outer drm_device.master_mutex to protect reads of drm_file.master makes the function prone to creating lock hierarchy inversions. Instead, we can use the drm_file.master_lookup_lock that sits at the bottom of the lock hierarchy. Reported-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com> Reviewed-by:
-
Zack Rusin authored
To let the userspace recognize that it's running on top of a vmwgfx that supports mks-stat ioctls we need to bump the version number. Signed-off-by:
Zack Rusin <zackr@vmware.com> Reviewed-by:
Martin Krastev <krastevm@vmware.com> Reviewed-by:
Neha Bhende <bhenden@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210723165153.113198-4-zackr@vmware.com
-
Zack Rusin authored
The code was trying to keep a strict limit on the amount of mob memory that was used in the guest by making it match the host settings. There's technically no reason to do that (guests can certainly use more than the host can have resident in renderers at the same time). In particular this is problematic because our userspace is not great at handling OOM conditions and running out of MOB space results in GL apps crashing, e.g. gnome-shell likes to allocate huge surfaces (~61MB for the desktop on 2560x1600 with two workspaces) and running out of memory there means that the gnome-shell crashes on startup taking us back to the login and resulting in a system where one can not login in graphically anymore. Instead of letting the userspace crash we can extend available MOB space, we just don't want to use all of the RAM for graphics, so we're going to limit it to half of RAM. With the addition of some extra logging this should make the "guest has been configured with not enough graphics memory" errors a lot easier to diagnose in cases where the automatic expansion of MOB space fails. Signed-off-by:
-
Zack Rusin authored
The code was using the old DRM logging functions, which made it hard to figure out what was coming from vmwgfx. The newer logging helpers include the driver name in the logs and make it explicit which driver they're coming from. This allows us to standardize our logging a bit and clean it up in the process. vmwgfx is a little special because technically the hardware it's running on can be anything from the last 12 years or so which is why we need to include capabilities in the logs in the first place or otherwise we'd have no way of knowing what were the capabilities of the platform the guest was running in. Signed-off-by:
-
Zack Rusin authored
The macro has been accounting for DRM_COMMAND_BASE for a long time now so there's no reason to still be duplicating it. Plus we were leaving the name undefined which meant that all the DRM ioctl warnings/errors were always listing "null" ioctl at the culprit. This fixes the undefined ioctl name and removes duplicated code. Signed-off-by:
-
- 27 Jul, 2021 21 commits
-
-
Rajkumar Subbiah authored
Commit 2f015ec6 ("drm/dp_mst: Add sideband down request tracing + selftests") added some debug code for sideband message tracing. But it seems to have unintentionally changed the behavior on sideband message failure. It catches and returns failure only if DRM_UT_DP is enabled. Otherwise it ignores the error code and returns success. So on an MST unplug, the caller is unaware that the clear payload message failed and ends up waiting for 4 seconds for the response. Fixes the issue by returning the proper error code. Changes in V2: -- Revise commit text as review comment -- add Fixes text Changes in V3: -- remove "unlikely" optimization Fixes: 2f015ec6 ("drm/dp_mst: Add sideband down request tracing + selftests") Cc: <stable@vger.kernel.org> # v5.5+ Signed-off-by:
Rajkumar Subbiah <rsubbia@codeaurora.org> Signed-off-by:
Kuogee Hsieh <khsieh@codeaurora.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Marek Vasut authored
Make sure the FIFO_CLEAR bit is latched in when configuring the controller, so that the FIFO is really cleared. And then clear the FIFO_CLEAR bit, since it is not self-clearing. Fixes: 45d59d70 ("drm: Add new driver for MXSFB controller") Signed-off-by:
Marek Vasut <marex@denx.de> Cc: Daniel Abrecht <public@danielabrecht.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Stefan Agner <stefan@agner.ch> Reviewed-by:
Jagan Teki <jagan@amarulasolutions.com> Tested-by: Jagan Teki <jagan@amarulasolutions.com> # i.Core MX8MM Acked-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210620224946.189524-1-marex@denx.de
-
Marek Vasut authored
In case there is a bridge connected to the LCDIF, use bus_format from the bridge, otherwise behave as before and use bus_format from the connector. This way, even if there are multiple bridges in the display pipeline, the LCDIF will use the correct format. Reviewed-by:
-
Marek Vasut authored
In case the DRAM is under high load, the MXSFB FIFO might underflow and that causes visible artifacts. This could be triggered on i.MX8MM using e.g. "$ memtester 128M" on a device with 1920x1080 panel. The first "Stuck Address" test of the memtester will completely corrupt the image on the panel and leave the MXSFB FIFO in odd state. To avoid this underflow, increase number of outstanding requests to DRAM from 2 to 16, which is the maximum. This mitigates the issue and it can no longer be triggered. Fixes: 45d59d70 ("drm: Add new driver for MXSFB controller") Signed-off-by:
-
Marek Vasut authored
There is some sort of corner case behavior of the controller, which could rarely be triggered at least on i.MX6SX connected to 800x480 DPI panel and i.MX8MM connected to DPI->DSI->LVDS bridged 1920x1080 panel (and likely on other setups too), where the image on the panel shifts to the right and wraps around. This happens either when the controller is enabled on boot or even later during run time. The condition does not correct itself automatically, i.e. the display image remains shifted. It seems this problem is known and is due to sporadic underflows of the LCDIF FIFO. While the LCDIF IP does have underflow/overflow IRQs, neither of the IRQs trigger and neither IRQ status bit is asserted when this condition occurs. All known revisions of the LCDIF IP have CTRL1 RECOVER_ON_UNDERFLOW bit, which is described in the reference manual since i.MX23 as " Set this bit to enable the LCDIF block to recover in the next field/frame if there was an underflow in the current field/frame. " Enable this bit to mitigate the sporadic underflows. Fixes: 45d59d70 ("drm: Add new driver for MXSFB controller") Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Geert Uytterhoeven authored
Cache the column and page ranges, to avoid doing unneeded I2C transfers when the values haven't changed. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Acked-by:
-
Geert Uytterhoeven authored
Currently, each screen update triggers an I2C transfer of all screen data, up to 1 KiB of data for a 128x64 display, which takes at least 20 ms in Fast mode. Reduce the amount of transferred data by only updating the rectangle that changed. Remove the calls to ssd1307fb_set_col_range() and ssd1307fb_set_page_range() during initialization, as ssd1307fb_update_rect() now takes care of that. Note that for now the optimized operation is only used for fillrect, copyarea, and imageblit, which are used by fbcon. Signed-off-by:
-
Geert Uytterhoeven authored
Extract the code to set the column and page ranges into two helper functions. Signed-off-by:
-
Geert Uytterhoeven authored
Simplify the nested loops to handle conversion from linear frame buffer to ssd1307 page layout: 1. Move last page handling one level up, as the value of "m" is the same inside a page, 2. array->data[] is filled linearly, so there is no need to recalculate array_idx over and over again; a simple increment is sufficient. Signed-off-by: -
Geert Uytterhoeven authored
Make ssd1307fb_update_display() return an error code, so callers that can handle failures can propagate it. Signed-off-by:
-
Simon Ser authored
Since there's no struct to attach the docs to, document the IOCTL definition. Signed-off-by:
Simon Ser <contact@emersion.fr> Reviewed-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by:
-
Simon Ser authored
We already have logging for ADDFB2. Add some logging for RMFB as well. This can be handy when trying to find out why a CRTC gets magically disabled. v2: make log message more explicit, add log messages to drm_framebuffer_remove (Daniel) Signed-off-by:
-
Maarten Lankhorst authored
Required bump from v5.13-rc3 to v5.14-rc3, and to pick up sysfb compilation fixes. Signed-off-by:Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Daniel Vetter authored
We're trying to have a fairly strict split between core functionality that defines the uapi, including the docs, and the helper functions to implement it. Move drm_plane_enable_fb_damage_clips and associated kerneldoc into drm_plane from drm_damage_helper.c to fix this. Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210723083457.696939-3-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
There's two stages of manual upload/invalidate displays: - just handling dirtyfb and uploading the entire fb all the time - looking at damage clips In the latter case we support it through fbdev emulation (with fb_defio), atomic property, and with the dirtfy clip rects. Make sure at least the atomic property is set up as the main official interface for this. Ideally we'd also check that drm_atomic_helper_dirtyfb() is used and that fbdev defio is set up, but that's quite a bit harder to do. Ideas very much welcome. From a cursor audit drivers seem to be getting this right mostly, but better to make sure. At least no one is bypassing the accessor function. v2: - use drm_warn_once with a meaningful warning string (José) - don't splat in the atomic check code for everyone (intel-gfx-ci) Reviewed-by: José Roberto de Souza <jose.souza@intel.com> (v1) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Daniel Vetter authored
It's not used. Drivers should instead use the helpers anyway. Currently both vbox and i915 hand-roll this and it's not the greatest. vbox looks buggy, and i915 does a bit much that helpers would take care of I think. Also improve the kerneldocs while we're at it. Reviewed-by:
-
Jose Maria Casanova Crespo authored
s/Exporting/Importing Fixes: 805dc614 ("drm/prime: Update docs") Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Jose Maria Casanova Crespo <jmcasanova@igalia.com> Signed-off-by:
-
Jagan Teki authored
Finding panel_or_bridge might vary based on associated DSI devices like DSI panel, bridge, and I2C based DSI bridge. 1. DSI panels and bridges will invoke the host attach from probe in order to find the panel_or_bridge. chipone_probe() dw_mipi_dsi_host_attach().start dw_mipi_dsi_panel_or_bridge() ...found the panel_or_bridge... ltdc_encoder_init().start dw_mipi_dsi_bridge_attach().start dw_mipi_dsi_host_attach().start chipone_attach(). start chipone_attach(). done dw_mipi_dsi_host_attach().done dw_mipi_dsi_bridge_attach(). done ltdc_encoder_init().done 2. I2C based DSI bridge will invoke the drm_bridge_attach from bridge attach in order to find the panel_or_bridge. ltdc_encoder_init().start dw_mipi_dsi_bridge_attach().start dw_mipi_dsi_panel_or_bridge() ...found the panel_or_bridge... dw_mipi_dsi_host_attach().start sn65dsi83_attach(). start sn65dsi83_attach(). done dw_mipi_dsi_host_attach().done dw_mipi_dsi_bridge_attach(). done ltdc_encoder_init().done So, invoke the panel_or_bridge from host attach and bridge attach in order to find all possible DSI devices. Signed-off-by:Yannick Fertre <yannick.fertre@foss.st.com> Reviewed-by:
Robert Foss <robert.foss@linaro.org> Tested-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Randy Dunlap authored
When # CONFIG_EFI is not set, there are 2 definitions of sysfb_apply_efi_quirks(). The stub from sysfb.h should be used and the __init function from sysfb_efi.c should not be used. ../drivers/firmware/efi/sysfb_efi.c:337:13: error: redefinition of ‘sysfb_apply_efi_quirks’ __init void sysfb_apply_efi_quirks(struct platform_device *pd) ^~~~~~~~~~~~~~~~~~~~~~ In file included from ../drivers/firmware/efi/sysfb_efi.c:26:0: ../include/linux/sysfb.h:65:20: note: previous definition of ‘sysfb_apply_efi_quirks’ was here static inline void sysfb_apply_efi_quirks(struct platform_device *pd) ^~~~~~~~~~~~~~~~~~~~~~ Reviewed-by:Javier Martinez Canillas <javierm@redhat.com> Fixes: 8633ef82 ("drivers/firmware: consolidate EFI framebuffer setup for all arches") Acked-by:
Ard Biesheuvel <ardb@kernel.org> Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: linux-efi@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Mark Brown <broonie@kernel.org> Cc: linux-next@vger.kernel.org Signed-off-by:
-
Javier Martinez Canillas authored
The Generic System Framebuffers support is built when the COMPILE_TEST option is enabled. But this wrongly assumes that all the architectures declare a struct screen_info. This is true for most architectures, but at least the following do not: arc, m68k, microblaze, openrisc, parisc and s390. By attempting to make this compile testeable on all architectures, it leads to linking errors as reported by the kernel test robot for parisc: All errors (new ones prefixed by >>): hppa-linux-ld: drivers/firmware/sysfb.o: in function `sysfb_init': (.init.text+0x24): undefined reference to `screen_info' >> hppa-linux-ld: (.init.text+0x28): undefined reference to `screen_info' To prevent these errors only allow sysfb to be built on systems that are going to need it, which are x86 BIOS and EFI. The EFI Kconfig symbol is used instead of (ARM || ARM64 || RISC) because some of these architectures only declare a struct screen_info if EFI is enabled. And also, because the SYSFB code is only used for EFI on these architectures. For !EFI the "simple-framebuffer" device is registered by OF when parsing the Device Tree Blob (if a DT node for this was defined). Fixes: d391c582 ("drivers/firmware: move x86 Generic System Framebuffers support") Reported-by:kernel test robot <lkp@intel.com> Signed-off-by:
-
Nicolas Boichat authored
Many of the DSI flags have names opposite to their actual effects, e.g. MIPI_DSI_MODE_EOT_PACKET means that EoT packets will actually be disabled. Fix this by including _NO_ in the flag names, e.g. MIPI_DSI_MODE_NO_EOT_PACKET. Signed-off-by:
Nicolas Boichat <drinkcat@chromium.org> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Andrzej Hajda <andrzej.hajda@samsung.com> Reviewed-by: Xin Ji <xji@analogixsemi.com> # anx7625.c Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> # msm/dsi Signed-off-by:
-
- 26 Jul, 2021 8 commits
-
-
Alexander Sverdlin authored
Use clk_prepare_enable()/clk_disable_unprepare() in preparation for switch to Common Clock Framework. Signed-off-by:
Alexander Sverdlin <alexander.sverdlin@gmail.com> Signed-off-by:
Nikita Shubin <nikita.shubin@maquefel.me> Signed-off-by:
-
Artjom Vejsel authored
Add vendor prefix for Shenzhen QiShenglong Industrialist Co., Ltd. QiShenglong is a Chinese manufacturer of handheld gaming consoles, most of which run (very old) versions of Linux. QiShenglong is known as Hamy. Signed-off-by:
Artjom Vejsel <akawolf0@gmail.com> Signed-off-by:
-
Bjorn Andersson authored
Add definition of the AUO B133HAN05.4 13.3" FHD panel and the B140HAN06.4 14.0" FHD panel. Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
Bjorn Andersson authored
Add bindings for the two AUO panels B133HAN05 and B140HAN06, both 1920x1080 panels with 16.7M colors, first being 13.3" and the latter 14.0". Signed-off-by:
-
Zheyu Ma authored
The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of 'pixclock', it may cause divide error. Fix this by checking whether 'pixclock' is zero first. The following log reveals it: [ 33.396850] divide error: 0000 [#1] PREEMPT SMP KASAN PTI [ 33.396864] CPU: 5 PID: 11754 Comm: i740 Not tainted 5.14.0-rc2-00513-gac532c9bbcfb-dirty #222 [ 33.396883] RIP: 0010:riva_load_video_mode+0x417/0xf70 [ 33.396969] Call Trace: [ 33.396973] ? debug_smp_processor_id+0x1c/0x20 [ 33.396984] ? tick_nohz_tick_stopped+0x1a/0x90 [ 33.396996] ? rivafb_copyarea+0x3c0/0x3c0 [ 33.397003] ? wake_up_klogd.part.0+0x99/0xd0 [ 33.397014] ? vprintk_emit+0x110/0x4b0 [ 33.397024] ? vprintk_default+0x26/0x30 [ 33.397033] ? vprintk+0x9c/0x1f0 [ 33.397041] ? printk+0xba/0xed [ 33.397054] ? record_print_text.cold+0x16/0x16 [ 33.397063] ? __kasan_check_read+0x11/0x20 [ 33.397074] ? profile_tick+0xc0/0x100 [ 33.397084] ? __sanitizer_cov_trace_const_cmp4+0x24/0x80 [ 33.397094] ? riva_set_rop_solid+0x2a0/0x2a0 [ 33.397102] rivafb_set_par+0xbe/0x610 [ 33.397111] ? riva_set_rop_solid+0x2a0/0x2a0 [ 33.397119] fb_set_var+0x5bf/0xeb0 [ 33.397127] ? fb_blank+0x1a0/0x1a0 [ 33.397134] ? lock_acquire+0x1ef/0x530 [ 33.397143] ? lock_release+0x810/0x810 [ 33.397151] ? lock_is_held_type+0x100/0x140 [ 33.397159] ? ___might_sleep+0x1ee/0x2d0 [ 33.397170] ? __mutex_lock+0x620/0x1190 [ 33.397180] ? trace_hardirqs_on+0x6a/0x1c0 [ 33.397190] do_fb_ioctl+0x31e/0x700 Signed-off-by:
Zheyu Ma <zheyuma97@gmail.com> Signed-off-by:
-
Zheyu Ma authored
The userspace program could pass any values to the driver through ioctl() interface. if the driver doesn't check the value of 'pixclock', it may cause divide error because the value of 'lineclock' and 'frameclock' will be zero. Fix this by checking whether 'pixclock' is zero in kyrofb_check_var(). The following log reveals it: [ 103.073930] divide error: 0000 [#1] PREEMPT SMP KASAN PTI [ 103.073942] CPU: 4 PID: 12483 Comm: syz-executor Not tainted 5.14.0-rc2-00478-g2734d6c1-dirty #118 [ 103.073959] RIP: 0010:kyrofb_set_par+0x316/0xc80 [ 103.074045] Call Trace: [ 103.074048] ? ___might_sleep+0x1ee/0x2d0 [ 103.074060] ? kyrofb_ioctl+0x330/0x330 [ 103.074069] fb_set_var+0x5bf/0xeb0 [ 103.074078] ? fb_blank+0x1a0/0x1a0 [ 103.074085] ? lock_acquire+0x3bd/0x530 [ 103.074094] ? lock_release+0x810/0x810 [ 103.074103] ? ___might_sleep+0x1ee/0x2d0 [ 103.074114] ? __mutex_lock+0x620/0x1190 [ 103.074126] ? trace_hardirqs_on+0x6a/0x1c0 [ 103.074137] do_fb_ioctl+0x31e/0x700 [ 103.074144] ? fb_getput_cmap+0x280/0x280 [ 103.074152] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074162] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074171] ? __sanitizer_cov_trace_switch+0x67/0xf0 [ 103.074181] ? __sanitizer_cov_trace_const_cmp2+0x20/0x80 [ 103.074191] ? do_vfs_ioctl+0x14b/0x16c0 [ 103.074199] ? vfs_fileattr_set+0xb60/0xb60 [ 103.074207] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074216] ? lock_release+0x483/0x810 [ 103.074224] ? __fget_files+0x217/0x3d0 [ 103.074234] ? __fget_files+0x239/0x3d0 [ 103.074243] ? do_fb_ioctl+0x700/0x700 [ 103.074250] fb_ioctl+0xe6/0x130 Signed-off-by:
-
Zheyu Ma authored
The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of 'pixclock', it may cause divide error. Fix this by checking whether 'pixclock' is zero first. The following log reveals it: [ 43.861711] divide error: 0000 [#1] PREEMPT SMP KASAN PTI [ 43.861737] CPU: 2 PID: 11764 Comm: i740 Not tainted 5.14.0-rc2-00513-gac532c9bbcfb-dirty #224 [ 43.861756] RIP: 0010:asiliantfb_check_var+0x4e/0x730 [ 43.861843] Call Trace: [ 43.861848] ? asiliantfb_remove+0x190/0x190 [ 43.861858] fb_set_var+0x2e4/0xeb0 [ 43.861866] ? fb_blank+0x1a0/0x1a0 [ 43.861873] ? lock_acquire+0x1ef/0x530 [ 43.861884] ? lock_release+0x810/0x810 [ 43.861892] ? lock_is_held_type+0x100/0x140 [ 43.861903] ? ___might_sleep+0x1ee/0x2d0 [ 43.861914] ? __mutex_lock+0x620/0x1190 [ 43.861921] ? do_fb_ioctl+0x313/0x700 [ 43.861929] ? mutex_lock_io_nested+0xfa0/0xfa0 [ 43.861936] ? __this_cpu_preempt_check+0x1d/0x30 [ 43.861944] ? _raw_spin_unlock_irqrestore+0x46/0x60 [ 43.861952] ? lockdep_hardirqs_on+0x59/0x100 [ 43.861959] ? _raw_spin_unlock_irqrestore+0x46/0x60 [ 43.861967] ? trace_hardirqs_on+0x6a/0x1c0 [ 43.861978] do_fb_ioctl+0x31e/0x700 Signed-off-by:
-
Simon Ser authored
When a property has the type DRM_MODE_PROP_BITMASK, the value field stores a bitshift, not a bitmask, which can be surprising. Signed-off-by:
-
- 25 Jul, 2021 6 commits
-
-
Dave Airlie authored
Linux 5.14-rc3 Daniel said we should pull the nouveau fix from fixes in here, probably a good plan. Signed-off-by:Dave Airlie <airlied@redhat.com>
-
Linus Torvalds authored
-
Alyssa Rosenzweig authored
Like many free software projects, freedesktop.org issued a non-binding recommendation for projects to migrate from Freenode to OFTC [1]. As such, freedesktop.org entries in the MAINTAINERS file are out-of-date as the respective channels have moved. Update the file to point to the right network. v2: Correct typo in commit message pointed out by Lukas and Jonathan. Add Hector's ack. v3: Add acks. [1] https://lists.freedesktop.org/archives/dri-devel/2021-May/307605.htmlSigned-off-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io> Acked-by:
Hector Martin <marcan@marcan.st> Acked-by:
Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210725150007.2818-2-alyssa@rosenzweig.io
-
Alyssa Rosenzweig authored
Like many free software projects, Nouveau recently moved from Freenode to OFTC. Update the reference. v3: Add acks. Signed-off-by:
-
Linus Torvalds authored
gcc doesn't care, but clang quite reasonably pointed out that the recent commit e9ba16e6 ("smpboot: Mark idle_init() as __always_inlined to work around aggressive compiler un-inlining") did some really odd things: kernel/smpboot.c:50:20: warning: duplicate 'inline' declaration specifier [-Wduplicate-decl-specifier] static inline void __always_inline idle_init(unsigned int cpu) ^ which not only has that duplicate inlining specifier, but the new __always_inline was put in the wrong place of the function definition. We put the storage class specifiers (ie things like "static" and "extern") first, and the type information after that. And while the compiler may not care, we put the inline specifier before the types. So it should be just static __always_inline void idle_init(unsigned int cpu) instead. Cc: Ingo Molnar <mingo@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linuxLinus Torvalds authored
Pull powerpc fixes from Michael Ellerman: - Fix guest to host memory corruption in H_RTAS due to missing nargs check. - Fix guest triggerable host crashes due to bad handling of nested guest TM state. - Fix possible crashes due to incorrect reference counting in kvm_arch_vcpu_ioctl(). - Two commits fixing some regressions in KVM transactional memory handling introduced by the recent rework of the KVM code. Thanks to Nicholas Piggin, Alexey Kardashevskiy, and Michael Neuling. * tag 'powerpc-5.14-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: KVM: PPC: Book3S HV Nested: Sanitise H_ENTER_NESTED TM state KVM: PPC: Book3S: Fix H_RTAS rets buffer overflow KVM: PPC: Fix kvm_arch_vcpu_ioctl vcpu_load leak KVM: PPC: Book3S: Fix CONFIG_TRANSACTIONAL_MEM=n crash KVM: PPC: Book3S HV P9: Fix guest TM support
-
