- Apr 13, 2022
-
-
Marek Vasut authored
The mode parsing is currently implemented in three steps: of_get_display_timing() - DT panel-timing to struct display_timing videomode_from_timing() - struct display_timing to struct videomode drm_display_mode_from_videomode() - struct videomode to struct drm_display_mode Replace all that with simple of_get_drm_panel_display_mode() call, which already populates struct drm_display_mode and then duplicate that mode in panel_lvds_get_modes() each time, since the mode does not change. Nice bonus is the bus_flags parsed by of_get_drm_panel_display_mode() out of panel-timing DT node, which is used in subsequent patch to fix handling of 'de-active' DT property. Tested-by:
Christoph Niedermaier <cniedermaier@dh-electronics.com> Signed-off-by:
Marek Vasut <marex@denx.de> Cc: Christoph Niedermaier <cniedermaier@dh-electronics.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Dmitry Osipenko <digetx@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> To: dri-devel@lists.freedesktop.org Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220401162154.295152-1-marex@denx.de
-
Marek Vasut authored
To make debugging easier, convert driver to regmap. Implement read and write regmap tables for known registers, keep all known register readable and mark those which are obviously read-only as not writeable. Use common I2C regmap for the I2C configuration, implement custom regmap bus for DSI configuration. The later is mandatory as this chip requires one extra byte set to read access length between register address and data. Signed-off-by:
Mark Brown <broonie@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220403171004.368464-1-marex@denx.de
-
Christian König authored
Update the kerneldoc for the members as well. Signed-off-by:
Christian König <christian.koenig@amd.com> Fixes: b0e2c9ea ("drm/ttm: allow bulk moves for all domains") Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220413091242.638413-1-christian.koenig@amd.com
-
Matthew Auld authored
It looks like we still need to call dma_fence_put() on the man->move, otherwise we just end up leaking it, leading to fireworks later. v2(Daniel): - Simplify the function tail Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5689 Fixes: 8bb31587 ("drm/ttm: remove bo->moving") Cc: Christian König <christian.koenig@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Reviewed-by:
-
Changcheng Deng authored
Use min() in order to make code cleaner. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Changcheng Deng <deng.changcheng@zte.com.cn> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Helge Deller <deller@gmx.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220209084810.1561184-1-deng.changcheng@zte.com.cn
-
- Apr 12, 2022
-
-
Matthew Auld authored
If we hit the sync case, like when skipping clearing for kernel internal objects, or when falling back to cpu clearing, like in i915, we end up trying to add a NULL fence, but with some recent changes in this area this now just results in NULL deref in dma_resv_add_fence: <1>[ 5.466383] BUG: kernel NULL pointer dereference, address: 0000000000000008 <1>[ 5.466384] #PF: supervisor read access in kernel mode <1>[ 5.466385] #PF: error_code(0x0000) - not-present page <6>[ 5.466386] PGD 0 P4D 0 <4>[ 5.466387] Oops: 0000 [#1] PREEMPT SMP NOPTI <4>[ 5.466389] CPU: 5 PID: 267 Comm: modprobe Not tainted 5.18.0-rc2-CI-CI_DRM_11481+ #1 <4>[ 5.466391] RIP: 0010:dma_resv_add_fence+0x63/0x260 <4>[ 5.466395] Code: 38 85 c0 0f 84 df 01 00 00 0f 88 e8 01 00 00 83 c0 01 0f 88 df 01 00 00 8b 05 35 89 10 01 49 8d 5e 68 85 c0 0f 85 45 01 00 00 <48> 8b 45 08 48 3d c0 a5 0a 82 0f 84 5c 01 00 00 48 3d 60 a5 0a 82 <4>[ 5.466396] RSP: 0018:ffffc90000e974f8 EFLAGS: 00010202 <4>[ 5.466397] RAX: 0000000000000001 RBX: ffff888123e88b28 RCX: 00000000ffffffff <4>[ 5.466398] RDX: 0000000000000001 RSI: ffffffff822e4f50 RDI: ffffffff8233f087 <4>[ 5.466399] RBP: 0000000000000000 R08: ffff8881313dbc80 R09: 0000000000000001 <4>[ 5.466399] R10: 0000000000000001 R11: 00000000da354294 R12: 0000000000000000 <4>[ 5.466400] R13: ffff88810927dc58 R14: ffff888123e88ac0 R15: ffff88810a88d600 <4>[ 5.466401] FS: 00007f5fa1193540(0000) GS:ffff88845d880000(0000) knlGS:0000000000000000 <4>[ 5.466402] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 5.466402] CR2: 0000000000000008 CR3: 0000000106dd6003 CR4: 00000000003706e0 <4>[ 5.466403] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4>[ 5.466404] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 <4>[ 5.466404] Call Trace: <4>[ 5.466405] <TASK> <4>[ 5.466406] ttm_bo_move_accel_cleanup+0x62/0x270 [ttm] <4>[ 5.466411] ? i915_rsgt_from_buddy_resource+0x185/0x1e0 [i915] <4>[ 5.466529] i915_ttm_move+0xfd/0x430 [i915] <4>[ 5.466833] ? dma_resv_reserve_fences+0x4e/0x320 <4>[ 5.466836] ? ttm_bo_add_move_fence.constprop.20+0xf7/0x140 [ttm] <4>[ 5.466841] ttm_bo_handle_move_mem+0xa1/0x140 [ttm] <4>[ 5.466845] ttm_bo_validate+0xee/0x160 [ttm] <4>[ 5.466849] __i915_ttm_get_pages+0x4f/0x210 [i915] <4>[ 5.466976] i915_ttm_get_pages+0xad/0x140 [i915] <4>[ 5.467094] ____i915_gem_object_get_pages+0x32/0xf0 [i915] <4>[ 5.467210] __i915_gem_object_get_pages+0x89/0xa0 [i915] <4>[ 5.467323] i915_vma_get_pages+0x114/0x1d0 [i915] <4>[ 5.467446] i915_vma_pin_ww+0xd3/0xa90 [i915] <4>[ 5.467570] i915_vma_pin.constprop.10+0x119/0x1b0 [i915] <4>[ 5.467700] ? __mutex_unlock_slowpath+0x3e/0x2b0 <4>[ 5.467704] intel_alloc_initial_plane_obj.isra.6+0x1a9/0x390 [i915] <4>[ 5.467833] intel_crtc_initial_plane_config+0x83/0x340 [i915] In the ttm_bo_move_sync_cleanup() case it seems we only really care about calling ttm_bo_wait_free_node(), so let's instead just call that directly. Signed-off-by:
-
Ville Syrjälä authored
struct drm_display_mode embeds a list head, so overwriting the full struct with another one will corrupt the list (if the destination mode is on a list). Use drm_mode_copy() instead which explicitly preserves the list head of the destination mode. Even if we know the destination mode is not on any list using drm_mode_copy() seems decent as it sets a good example. Bad examples of not using it might eventually get copied into code where preserving the list head actually matters. Obviously one case not covered here is when the mode itself is embedded in a larger structure and the whole structure is copied. But if we are careful when copying into modes embedded in structures I think we can be a little more reassured that bogus list heads haven't been propagated in. @is_mode_copy@ @@ drm_mode_copy(...) { ... } @depends on !is_mode_copy@ struct drm_display_mode *mode; expression E, S; @@ ( - *mode = E + drm_mode_copy(mode, &E) | - memcpy(mode, E, S) + drm_mode_copy(mode, E) ) @depends on !is_mode_copy@ struct drm_display_mode mode; expression E; @@ ( - mode = E + drm_mode_copy(&mode, &E) | - memcpy(&mode, E, S) + drm_mode_copy(&mode, E) ) @@ struct drm_display_mode *mode; @@ - &*mode + mode Signed-off-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218100403.7028-23-ville.syrjala@linux.intel.com Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com>
-
Ville Syrjälä authored
Initialize on-stack modes with drm_mode_init() to guarantee no stack garbage in the list head, or that we aren't copying over another mode's list head. Based on the following cocci script, with manual fixups: @decl@ identifier M; expression E; @@ - struct drm_display_mode M = E; + struct drm_display_mode M; @@ identifier decl.M; expression decl.E; statement S, S1; @@ struct drm_display_mode M; ... when != S + drm_mode_init(&M, &E); + S1 @@ expression decl.E; @@ - &*E + E Signed-off-by:
-
Jiasheng Jiang authored
The return value of kzalloc() needs to be checked. To avoid use of null pointer '&state->base' in case of the failure of alloc. Fixes: 99665d07 ("drm: mali-dp: add malidp_crtc_state struct") Signed-off-by:
Jiasheng Jiang <jiasheng@iscas.ac.cn> Reviewed-by:
Brian Starkey <brian.starkey@arm.com> Signed-off-by:
Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211214100837.46912-1-jiasheng@iscas.ac.cn
-
Robin Murphy authored
iommu_get_domain_for_dev() is already perfectly happy to return NULL if the given device has no IOMMU. Drop the unnecessary check. Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
-
Liviu Dudau authored
If drm_universal_plane_init() fails early we jump to the common cleanup code that calls komeda_plane_destroy() which in turn could access the uninitalised drm_plane and crash. Return early if an error is detected without going through the common code. Reported-by:
Steven Price <steven.price@arm.com> Reviewed-by:
-
Zhou Qingyang authored
In komeda_plane_add(), komeda_get_layer_fourcc_list() is assigned to formats and used in drm_universal_plane_init(). drm_universal_plane_init() passes formats to __drm_universal_plane_init(). __drm_universal_plane_init() further passes formats to memcpy() as src parameter, which could lead to an undefined behavior bug on failure of komeda_get_layer_fourcc_list(). Fix this bug by adding a check of formats. This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_DRM_KOMEDA=m show no new warnings, and our static analyzer no longer warns about this code. Fixes: 61f1c4a8 ("drm/komeda: Attach komeda_dev to DRM-KMS") Signed-off-by:
Zhou Qingyang <zhou1615@umn.edu> Signed-off-by:
-
- Apr 11, 2022
-
-
Paul Boddie authored
A specialisation of the generic Synopsys HDMI driver is employed for JZ4780 HDMI support. This requires a new driver, plus device tree and configuration modifications. Here we add Kconfig DRM_INGENIC_DW_HDMI, Makefile and driver code. Note that there is no hpd-gpio installed on the CI20 board HDMI connector. Hence there is no hpd detection by the connector driver and we have to enable polling in the dw-hdmi core driver. For that we need to set .poll_enabled but that struct component can only be accessed by core code. Hence we use the public setter function drm_kms_helper_hotplug_event() introduced before. Also note that we disable Color Space Conversion since it is not working on jz4780. Signed-off-by:
Paul Boddie <paul@boddie.org.uk> Signed-off-by:
Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by:
H. Nikolaus Schaller <hns@goldelico.com> Reviewed-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/e5cdf9cd44bde52cce379cc830f2d6117ea15c32.1649330171.git.hns@goldelico.com
-
Paul Cercueil authored
The .atomic_get_input_bus_fmts() callback of our top bridge should return the possible input formats for a given output format. If the requested output format is not supported, then NULL should be returned, otherwise the bus format negociation will end with a bus format that the encoder does not support. Signed-off-by:
-
H. Nikolaus Schaller authored
"hdmi-connector.yaml" bindings defines an optional property "ddc-en-gpios" for a single gpio to enable DDC operation. Usually this controls +5V power on the HDMI connector. This +5V may also be needed for HPD. This was not reflected in code but is needed to make the CI20 board work. Now, the driver activates the ddc gpio after probe and deactivates after remove so it is "almost on". But only if this driver is loaded (and not e.g. blacklisted as module). Signed-off-by:
-
Christian König authored
That should have been max, not min. Signed-off-by:
-
Arunpravin Paneer Selvam authored
Add a simple check to reject any size not aligned to the min_page_size. when size is not aligned to min_page_size, driver module should handle in their own way either to round_up() the size value to min_page_size or just to enable WARN_ON(). If we dont handle the alignment properly, we may hit the following bug, Unigine Heaven has allocation requests for example required pages are 257 and alignment request is 256. To allocate the left over 1 page, continues the iteration to find the order value which is 0 and when it compares with min_order = 8, triggers the BUG_ON(order < min_order). v2: add more commit description v3: remove WARN_ON() Signed-off-by:
Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Suggested-by:
-
- Apr 08, 2022
-
-
Maxime Ripard authored
When debugging, finding out what muxing decisions were made and what the actual core clock rate is is always useful, so let's add some more messages. Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Acked-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20220328153659.2382206-7-maxime@cerno.tech
-
Maxime Ripard authored
The documentation explicitly states we must prevent the output 2 and 3 from feeding from the same HVS channel. Let's add a warning to make some noise if we ever find ourselves in such a case. Signed-off-by:
-
Maxime Ripard authored
We use the channel from our vc4_crtc_state structure in multiple places, let's store it in a local variable to make it cleaner. Signed-off-by:
-
Maxime Ripard authored
If we use a format that has padding instead of the alpha component (such as XRGB8888), it appears that the Transposer will fill the padding to 0, disregarding what was stored in the input buffer padding. This leads to issues with IGT, since it will set the padding to 0xff, but will then compare the CRC of the two frames which will thus fail. Another nice side effect is that it is now possible to just use the buffer as ARGB. Fixes: 008095e0 ("drm/vc4: Add support for the transposer block") Signed-off-by:
-
Maxime Ripard authored
The TXP_VSTART_AT_EOF will generate a second VSTART signal to the HVS. However, the HVS waits for VSTART to enable the FIFO and will thus start filling the FIFO before the start of the frame. This leads to corruption at the beginning of the first frame, and content from the previous frame at the beginning of the next frames. Since one VSTART is enough, let's get rid of it. Fixes: 008095e0 ("drm/vc4: Add support for the transposer block") Signed-off-by:
-
Maxime Ripard authored
By default, the HVS driver will force the HVS output 3 to be muxed to the HVS channel 2. However, the Transposer can only be assigned to the HVS channel 2, so whenever we try to use the writeback connector, we'll mux its associated output (Output 2) to the channel 2. This leads to both the output 2 and 3 feeding from the same channel, which is explicitly discouraged in the documentation. In order to avoid this, let's reset all the output muxes to their reset value. Fixes: 87ebcd42 ("drm/vc4: crtc: Assign output to channel automatically") Signed-off-by:
-
Matthew Auld authored
All of CI is just failing with the following, which prevents loading of the module: i915 0000:03:00.0: [drm] *ERROR* Scratch setup failed Best guess is that this comes from the pin_map() for the scratch page, which does an i915_gem_object_wait_moving_fence() somewhere. It looks like this now calls into dma_resv_wait_timeout() which can return the remaining timeout, leading to the caller thinking this is an error. v2(Lucas): handle ret == 0 Fixes: 1d7f5e6c ("drm/i915: drop bo->moving dependency") Signed-off-by: -
Arunpravin Paneer Selvam authored
- Switch to drm buddy allocator - Add resource cursor support for drm buddy v2(Matthew Auld): - replace spinlock with mutex as we call kmem_cache_zalloc (..., GFP_KERNEL) in drm_buddy_alloc() function - lock drm_buddy_block_trim() function as it calls mark_free/mark_split are all globally visible v3(Matthew Auld): - remove trim method error handling as we address the failure case at drm_buddy_block_trim() function v4: - fix warnings reported by kernel test robot <lkp@intel.com> v5: - fix merge conflict issue v6: - fix warnings reported by kernel test robot <lkp@intel.com> v7: - remove DRM_BUDDY_RANGE_ALLOCATION flag usage v8: - keep DRM_BUDDY_RANGE_ALLOCATION flag usage - resolve conflicts created by drm/amdgpu: remove VRAM accounting v2 v9(Christian): - merged the below patch - drm/amdgpu: move vram inline functions into a header - rename label name as fallback - move struct amdgpu_vram_mgr to amdgpu_vram_mgr.h - remove unnecessary flags from struct amdgpu_vram_reservation - rewrite block NULL check condition - change else style as per coding standard - rewrite the node max size - add a helper function to fetch the first entry from the list v10(Christian): - rename amdgpu_get_node() function name as amdgpu_vram_mgr_first_block v11: - if size is not aligned with min_page_size, enable is_contiguous flag, therefore, the size round up to the power of two and trimmed to the original size. v12: - rename the function names having prefix as amdgpu_vram_mgr_*() - modify the round_up() logic conforming to contiguous flag enablement or if size is not aligned to min_block_size - modify the trim logic - rename node as block wherever applicable Signed-off-by: -
Matthew Auld authored
I guess this was missed in the conversion or something. Fixes: 7bc80a54 ("dma-buf: add enum dma_resv_usage v4") Signed-off-by:
-
- Apr 07, 2022
-
-
Daniel Vetter authored
Accessing the one in fbmem.c without taking the right locks is a bad idea. Instead maintain our own private copy, which is fully protected by console_lock() (like everything else in fbcon.c). That copy is serialized through fbcon_fb_registered/unregistered() calls. Also this means we do not need to hold a full fb_info reference, which is nice because doing so would mean a refcount loop between the console and the fb_info. But it's also not nice since it means console_lock() must be held absolutely everywhere. Well strictly speaking we could still try to do some refcounting games again by calling get_fb_info before we drop the console_lock. But things will get tricky. Acked-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Claudio Suarez <cssk@net-c.es> Cc: Du Cheng <ducheng2@gmail.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220405210335.3434130-18-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
There's a bunch of confusions going on here: - The deferred fbcon setup notifier should only be cleaned up from fb_console_exit(), to be symmetric with fb_console_init() - We also need to make sure we don't race with the work, which means temporarily dropping the console lock (or we can deadlock) - That also means no point in clearing deferred_takeover, we are unloading everything anyway. - Finally rename fbcon_exit to fbcon_release_all and move it, since that's what's it doing when being called from consw->con_deinit through fbcon_deinit. To answer a question from Sam just quoting my own reply: > We loose the call to fbcon_release_all() here [in fb_console_exit()]. > We have part of the old fbcon_exit() above, but miss the release parts. Ah yes that's the entire point of this change. The release_all in the fbcon exit path was only needed when fbcon was a separate module indepedent from core fb.ko. Which means it was possible to unload fbcon while having fbdev drivers registered. But since we've merged them that has become impossible, so by the time the fb.ko module can be unloaded, there's guaranteed to be no fbdev drivers left. And hence removing them is pointless. v2: Explain the why better (Sam) Acked-by:
-
Daniel Vetter authored
con2fb_release_oldinfo() has a bunch more kfree() calls than fbcon_exit(), but since kfree() on NULL is harmless doing that in both places should be ok. This is also a bit more symmetric now again with fbcon_open also allocating the fbcon_ops structure. Acked-by:
-
Daniel Vetter authored
Ideally console_lock becomes an implementation detail of fbcon.c and doesn't show up anywhere in fbmem.c. We're still pretty far from that, but at least the register/unregister code is there now. With this the do_fb_ioctl() handler is the only code in fbmem.c still calling console_lock(). Acked-by:
-
Daniel Vetter authored
This shouldn't be a problem in practice since until we've actually taken over the console there's nothing we've registered with the console/vt subsystem, so the exit/unbind path that check this can't do the wrong thing. But it's confusing, so fix it by moving it a tad later. Acked-by:
-
Daniel Vetter authored
Now we get to the real motiviation, because fbmem.c insists that that's the right lock for these. Ofc fbcon.c has a lot more places where it probably should call lock_fb_info(). But looking at fbmem.c at least most of these seem to be protected by console_lock() too, which is probably what papers over any issues. Note that this means we're shuffling around a bit the locking sections for some of the console takeover and unbind paths, but not all: - console binding/unbinding from the console layer never with lock_fb_info - unbind (as opposed to unlink) never bother with lock_fb_info Also the real serialization against set_par and set_pan are still doing by wrapping the entire ioctl code in console_lock(). So this shuffling shouldn't be worse than what we had from a "can you trigger races?" pov, but it's at least clearer. Acked-by:
-
Daniel Vetter authored
No idea why con2fb_acquire_newinfo() initializes much less than fbcon_startup(), but so be it. From a quick look most of the un-initialized stuff should be fairly harmless, but who knows. Note that the error handling for the con2fb_acquire_newinfo() failure case was very strange: Callers updated con2fb_map to the new value before calling this function, but upon error con2fb_acquire_newinfo reset it to the old value. Since I removed the call to fbcon_release anyway that strange error path was sticking out like a sore thumb, hence I removed it. Which also allows us to remove the oldidx parameter from that function. v2: Explain what's going on with oldidx and error paths (Sam) v3: Drop unused variable (0day) v4: Rebased over bisect fix in previous patch, unchagend end result. Acked-by: Sam Ravnborg <sam@ravnborg.org> (v2) Acked-by:
-
Daniel Vetter authored
It doesn't ever fail anymore. Acked-by:
-
Daniel Vetter authored
There's two minor behaviour changes in here: - in error paths we now consistently call fb_ops->fb_release - fb_release really can't fail (fbmem.c ignores it too) and there's no reasonable cleanup we can do anyway. Note that everything in fbcon.c is protected by the big console_lock() lock (especially all the global variables), so the minor changes in ordering of setup/cleanup do not matter. v2: Explain a bit better why this is all correct (Sam) Acked-by:
-
Daniel Vetter authored
It was only used by fbcon, and that now switched to its own, private work. Acked-by:
-
Daniel Vetter authored
It's only one flag and slightly tidier code. Acked-by:
-
Daniel Vetter authored
Allows us to delete a bunch of hand-rolled stuff using a timer plus a separate work). Also to simplify the code we initialize the cursor_work completely when we allocate the fbcon_ops structure, instead of trying to cope with console re-initialization. The motiviation here is that fbcon code stops using the fb_info.queue, which helps with locking issues around cleanup and all that in a later patch. Also note that this allows us to ditch the hand-rolled work cleanup in fbcon_exit - we already call fbcon_del_cursor_timer, which takes care of everything. Plus this was racy anyway. v2: - Only INIT_DELAYED_WORK when kzalloc succeeded (Tetsuo) - Explain that we replace both the timer and a work with the combined delayed_work (Javier) Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Acked-by:
-
Daniel Vetter authored
fb_set_var requires we hold the fb_info lock. Or at least this now matches what the ioctl does ... Note that ps3fb and sh_mobile_lcdcfb are busted in different ways here, but I will not fix them up. Also in practice this isn't a big deal, because really variable fbdev state is actually protected by console_lock (because fbcon just doesn't bother with lock_fb_info() at all), and lock_fb_info protecting anything is really just a neat lie. But that's a much bigger fish to fry. Acked-by:
-
Daniel Vetter authored
Before commit 6104c370 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Aug 1 17:32:07 2017 +0200 fbcon: Make fbcon a built-time depency for fbdev it was possible to load fbcon and fbdev drivers in any order, which means that fbcon init had to handle the case where fbdev drivers where already registered. This is no longer possible, hence delete that code. Note that the exit case is a bit more complex and will be done in a separate patch. Since I had to audit the entire fbcon load code I also spotted a wrong function name in a comment in fbcon_startup(), which this patch also fixes. v2: Explain why we also fix the comment (Sam) Acked-by:
-
