lwn.git/drivers/gpu/drm/sti/sti_dvo.c, branch docs-fixes

drm/sti: dvo: convert to devm_drm_bridge_alloc() API

2025-05-21T11:40:09+00:00

This is the new API for allocating DRM bridges. This driver allocates the DRM bridge separately from the main driver private struct, which prevents using the new devm_drm_bridge_alloc() API. Simplify the code by replacing the struct drm_bridge pointer with an embedded struct drm_bridge inside the private struct, to make use of the new API with the same code flow. Acked-by: Maxime Ripard Link: https://lore.kernel.org/r/20250509-drm-bridge-convert-to-alloc-api-v3-16-b8bc1f16d7aa@bootlin.com Signed-off-by: Luca Ceresoli

drm/sti: move to devm_platform_ioremap_resource() usage

2025-03-10T20:25:26+00:00

Replace platform_get_resource/_byname + devm_ioremap with just devm_platform_ioremap_resource() Used Coccinelle to do this change. SmPl patch: @rule@ identifier res; expression ioremap; identifier pdev; constant mem; expression name; @@ -struct resource *res; ... -res = platform_get_resource_byname(pdev,mem,name); <... -if (!res) { -... -} ...> -ioremap = devm_ioremap(...); +ioremap = devm_platform_ioremap_resource_byname(pdev,name); and @rule_2@ identifier res; expression ioremap; identifier pdev; @@ -struct resource *res; ... -res = platform_get_resource(pdev,...); <... -if (!res) { -... -} ...> -ioremap = devm_ioremap(...); +ioremap = devm_platform_ioremap_resource(pdev,0); v2: Fix compilation error. v3: Handle returns properly since the new API return error pointers and not NULL Cc: Raphael Gallais-Pou Cc: Alain Volmat Reviewed-by: Maxime Ripard (v2) Acked-by: Raphael Gallais-Pou (v2) Signed-off-by: Anusha Srivatsa Link: https://patchwork.freedesktop.org/patch/640854/?series=144073&rev=5

drm/connector: make mode_valid take a const struct drm_display_mode

2025-01-07T10:45:19+00:00

The mode_valid() callbacks of drm_encoder, drm_crtc and drm_bridge take a const struct drm_display_mode argument. Change the mode_valid callback of drm_connector to also take a const argument. Acked-by: Jani Nikula Reviewed-by: Liviu Dudau Reviewed-by: Raphael Gallais-Pou Reviewed-by: Laurent Pinchart Reviewed-by: Lyude Paul Reviewed-by: Maxime Ripard Reviewed-by: Thomas Zimmermann Reviewed-by: Harry Wentland Link: https://patchwork.freedesktop.org/patch/msgid/20241214-drm-connector-mode-valid-const-v2-5-4f9498a4c822@linaro.org Signed-off-by: Dmitry Baryshkov

Get rid of 'remove_new' relic from platform driver struct

2024-12-01T23:12:43+00:00

The continual trickle of small conversion patches is grating on me, and is really not helping. Just get rid of the 'remove_new' member function, which is just an alias for the plain 'remove', and had a comment to that effect: /* * .remove_new() is a relic from a prototype conversion of .remove(). * New drivers are supposed to implement .remove(). Once all drivers are * converted to not use .remove_new any more, it will be dropped. */ This was just a tree-wide 'sed' script that replaced '.remove_new' with '.remove', with some care taken to turn a subsequent tab into two tabs to make things line up. I did do some minimal manual whitespace adjustment for places that used spaces to line things up. Then I just removed the old (sic) .remove_new member function, and this is the end result. No more unnecessary conversion noise. Signed-off-by: Linus Torvalds

drm/sti: dvo: drop driver owner assignment

2024-07-05T11:18:33+00:00

Core in platform_driver_register() already sets the .owner, so driver does not need to. Whatever is set here will be anyway overwritten by main driver calling platform_driver_register(). Signed-off-by: Krzysztof Kozlowski Acked-by: Alain Volmat Link: https://patchwork.freedesktop.org/patch/msgid/20240330203831.87003-1-krzysztof.kozlowski@linaro.org Signed-off-by: Maxime Ripard

drm/sti: Include linux/io.h for devm_ioremap()

2024-05-28T18:43:34+00:00

Include linux/io.h for devm_ioremap(). When built on x86_64 w/ COMPILE_TEST=y: ../drivers/gpu/drm/sti/sti_dvo.c:531:21: error: implicit declaration of function ‘devm_ioremap’ [-Werror=implicit-function-declaration] 531 | dvo->regs = devm_ioremap(dev, res->start, | ^~~~~~~~~~~~ ../drivers/gpu/drm/sti/sti_dvo.c:531:19: error: assignment to ‘void *’ from ‘int’ makes pointer from integer without a cast [-Werror=int-conversion] 531 | dvo->regs = devm_ioremap(dev, res->start, | ^ Cc: Alain Volmat Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20240408170426.9285-7-ville.syrjala@linux.intel.com Acked-by: Alain Volmat

drm/sti: Convert to platform remove callback returning void

2023-06-08T16:04:12+00:00

The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert the sti drm drivers from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König Acked-by: Alain Volmat Signed-off-by: Douglas Anderson Link: https://patchwork.freedesktop.org/patch/msgid/20230507162616.1368908-42-u.kleine-koenig@pengutronix.de

drm/sti: Drop of_gpio header

2023-04-22T21:58:42+00:00

This driver includes the deprecated OF GPIO header yet fail to use symbols from it, so drop this include. Cc: Alain Volmat Signed-off-by: Maíra Canal Acked-by: Alain Volmat Link: https://patchwork.freedesktop.org/patch/msgid/20220812205746.609107-5-mairacanal@riseup.net

Merge tag 'hardening-v6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

2022-12-14T20:20:00+00:00

Pull kernel hardening updates from Kees Cook: - Convert flexible array members, fix -Wstringop-overflow warnings, and fix KCFI function type mismatches that went ignored by maintainers (Gustavo A. R. Silva, Nathan Chancellor, Kees Cook) - Remove the remaining side-effect users of ksize() by converting dma-buf, btrfs, and coredump to using kmalloc_size_roundup(), add more __alloc_size attributes, and introduce full testing of all allocator functions. Finally remove the ksize() side-effect so that each allocation-aware checker can finally behave without exceptions - Introduce oops_limit (default 10,000) and warn_limit (default off) to provide greater granularity of control for panic_on_oops and panic_on_warn (Jann Horn, Kees Cook) - Introduce overflows_type() and castable_to_type() helpers for cleaner overflow checking - Improve code generation for strscpy() and update str*() kern-doc - Convert strscpy and sigphash tests to KUnit, and expand memcpy tests - Always use a non-NULL argument for prepare_kernel_cred() - Disable structleak plugin in FORTIFY KUnit test (Anders Roxell) - Adjust orphan linker section checking to respect CONFIG_WERROR (Xin Li) - Make sure siginfo is cleared for forced SIGKILL (haifeng.xu) - Fix um vs FORTIFY warnings for always-NULL arguments * tag 'hardening-v6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: (31 commits) ksmbd: replace one-element arrays with flexible-array members hpet: Replace one-element array with flexible-array member um: virt-pci: Avoid GCC non-NULL warning signal: Initialize the info in ksignal lib: fortify_kunit: build without structleak plugin panic: Expose "warn_count" to sysfs panic: Introduce warn_limit panic: Consolidate open-coded panic_on_warn checks exit: Allow oops_limit to be disabled exit: Expose "oops_count" to sysfs exit: Put an upper limit on how often we can oops panic: Separate sysctl logic from CONFIG_SMP mm/pgtable: Fix multiple -Wstringop-overflow warnings mm: Make ksize() a reporting-only function kunit/fortify: Validate __alloc_size attribute results drm/sti: Fix return type of sti_{dvo,hda,hdmi}_connector_mode_valid() drm/fsl-dcu: Fix return type of fsl_dcu_drm_connector_mode_valid() driver core: Add __alloc_size hint to devm allocators overflow: Introduce overflows_type() and castable_to_type() coredump: Proactively round up to kmalloc bucket size ...

drm/sti: Fix return type of sti_{dvo,hda,hdmi}_connector_mode_valid()

2022-11-18T17:17:13+00:00

With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals: drivers/gpu/drm/sti/sti_hda.c:637:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict] .mode_valid = sti_hda_connector_mode_valid, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/sti/sti_dvo.c:376:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict] .mode_valid = sti_dvo_connector_mode_valid, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/sti/sti_hdmi.c:1035:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict] .mode_valid = sti_hdmi_connector_mode_valid, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ->mode_valid() in 'struct drm_connector_helper_funcs' expects a return type of 'enum drm_mode_status', not 'int'. Adjust the return type of sti_{dvo,hda,hdmi}_connector_mode_valid() to match the prototype's to resolve the warning and CFI failure. Link: https://github.com/ClangBuiltLinux/linux/issues/1750 Signed-off-by: Nathan Chancellor Reviewed-by: Kees Cook Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20221102155623.3042869-1-nathan@kernel.org