summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-12-04drm/bridge: migrate bridge_chains to per-encoder fileDmitry Baryshkov3-49/+37
Instead of having a single file with all bridge chains, list bridges under a corresponding per-encoder debugfs directory. While we are at it, also slightly improve the formatting of the bridge data: split a single line entry into multiple lines, include the symbol name of the bridge funcs and add the textual representation of the bridge ops. Example of the listing: $ cat /sys/kernel/debug/dri/0/encoder-0/bridges bridge[0]: dsi_mgr_bridge_funcs type: [0] Unknown ops: [0] bridge[1]: lt9611uxc_bridge_funcs type: [11] HDMI-A OF: /soc@0/geniqup@9c0000/i2c@994000/hdmi-bridge@2b:lontium,lt9611uxc ops: [7] detect edid hpd Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231203115315.1306124-3-dmitry.baryshkov@linaro.org
2023-12-04drm/encoder: register per-encoder debugfs dirDmitry Baryshkov4-1/+54
Each of connectors and CRTCs used by the DRM device provides debugfs directory, which is used by several standard debugfs files and can further be extended by the driver. Add such generic debugfs directories for encoder. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231203115315.1306124-2-dmitry.baryshkov@linaro.org
2023-12-04usb: typec: qcom-pmic-typec: switch to DRM_AUX_HPD_BRIDGEDmitry Baryshkov2-35/+7
Use the freshly defined DRM_AUX_HPD_BRIDGE instead of open-coding the same functionality for the DRM bridge chain termination. Acked-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231203114333.1305826-7-dmitry.baryshkov@linaro.org
2023-12-04soc: qcom: pmic-glink: switch to DRM_AUX_HPD_BRIDGEDmitry Baryshkov2-24/+10
Use the freshly defined DRM_AUX_HPD_BRIDGE instead of open-coding the same functionality for the DRM bridge chain termination. Reviewed-by: Bjorn Andersson <andersson@kernel.org> Acked-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231203114333.1305826-6-dmitry.baryshkov@linaro.org
2023-12-04drm/bridge: implement generic DP HPD bridgeDmitry Baryshkov4-0/+190
Several USB-C controllers implement a pretty simple DRM bridge which implements just the HPD notification operations. Add special helper for creating such simple bridges. Acked-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231203114333.1305826-5-dmitry.baryshkov@linaro.org
2023-12-04usb: typec: nb7vpq904m: switch to DRM_AUX_BRIDGEDmitry Baryshkov2-43/+3
Switch to using the new DRM_AUX_BRIDGE helper to create the transparent DRM bridge device instead of handcoding corresponding functionality. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231203114333.1305826-4-dmitry.baryshkov@linaro.org
2023-12-04phy: qcom: qmp-combo: switch to DRM_AUX_BRIDGEDmitry Baryshkov2-43/+3
Switch to using the new DRM_AUX_BRIDGE helper to create the transparent DRM bridge device instead of handcoding corresponding functionality. Acked-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231203114333.1305826-3-dmitry.baryshkov@linaro.org
2023-12-04drm/bridge: add transparent bridge helperDmitry Baryshkov4-0/+169
Define a helper for creating simple transparent bridges which serve the only purpose of linking devices into the bridge chain up to the last bridge representing the connector. This is especially useful for DP/USB-C bridge chains, which can span across several devices, but do not require any additional functionality from the intermediate bridges. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231203114333.1305826-2-dmitry.baryshkov@linaro.org
2023-12-04MAINTAINERS: Document Imagination PowerVR driver patches go via drm-miscFrank Binns1-0/+1
This is the tree used by nearly all other DRM drivers, so use it for the PowerVR driver as well. Signed-off-by: Frank Binns <frank.binns@imgtec.com> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231204132847.1307340-1-frank.binns@imgtec.com
2023-12-04usb: typec: class: fix typec_altmode_put_partner to put plugsRD Babiera1-2/+3
When typec_altmode_put_partner is called by a plug altmode upon release, the port altmode the plug belongs to will not remove its reference to the plug. The check to see if the altmode being released evaluates against the released altmode's partner instead of the calling altmode itself, so change adev in typec_altmode_put_partner to properly refer to the altmode being released. typec_altmode_set_partner is not run for port altmodes, so also add a check in typec_altmode_release to prevent typec_altmode_put_partner() calls on port altmode release. Fixes: 8a37d87d72f0 ("usb: typec: Bus type for alternate modes") Cc: stable@vger.kernel.org Signed-off-by: RD Babiera <rdbabiera@google.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20231129192349.1773623-2-rdbabiera@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04USB: gadget: core: adjust uevent timing on gadget unbindRoy Luo1-2/+2
The KOBJ_CHANGE uevent is sent before gadget unbind is actually executed, resulting in inaccurate uevent emitted at incorrect timing (the uevent would have USB_UDC_DRIVER variable set while it would soon be removed). Move the KOBJ_CHANGE uevent to the end of the unbind function so that uevent is sent only after the change has been made. Fixes: 2ccea03a8f7e ("usb: gadget: introduce UDC Class") Cc: stable@vger.kernel.org Signed-off-by: Roy Luo <royluo@google.com> Link: https://lore.kernel.org/r/20231128221756.2591158-1-royluo@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04drm/bridge: nxp-ptn3460: fix i2c_master_send() error checkingDan Carpenter1-5/+5
The i2c_master_send/recv() functions return negative error codes or the number of bytes that were able to be sent/received. This code has two problems. 1) Instead of checking if all the bytes were sent or received, it checks that at least one byte was sent or received. 2) If there was a partial send/receive then we should return a negative error code but this code returns success. Fixes: a9fe713d7d45 ("drm/bridge: Add PTN3460 bridge driver") Cc: stable@vger.kernel.org Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/0cdc2dce-ca89-451a-9774-1482ab2f4762@moroto.mountain
2023-12-04platform/mellanox: Check devm_hwmon_device_register_with_groups() return valueKunwu Chan1-0/+2
devm_hwmon_device_register_with_groups() returns an error pointer upon failure. Check its return value for errors. Compile-tested only. Fixes: 1a218d312e65 ("platform/mellanox: mlxbf-pmc: Add Mellanox BlueField PMC driver") Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Suggested-by: Vadim Pasternak <vadimp@nvidia.com> Signed-off-by: Kunwu Chan <chentao@kylinos.cn> Reviewed-by: Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20231201055447.2356001-1-chentao@kylinos.cn [ij: split the change into two] Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-12-04platform/mellanox: Add null pointer checks for devm_kasprintf()Kunwu Chan1-0/+12
devm_kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Compile-tested only. Fixes: 1a218d312e65 ("platform/mellanox: mlxbf-pmc: Add Mellanox BlueField PMC driver") Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Suggested-by: Vadim Pasternak <vadimp@nvidia.com> Signed-off-by: Kunwu Chan <chentao@kylinos.cn> Reviewed-by: Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20231201055447.2356001-1-chentao@kylinos.cn [ij: split the change into two] Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-12-04ASoC: wm_adsp: fix memleak in wm_adsp_buffer_populateDinghao Liu1-2/+6
When wm_adsp_buffer_read() fails, we should free buf->regions. Otherwise, the callers of wm_adsp_buffer_populate() will directly free buf on failure, which makes buf->regions a leaked memory. Fixes: a792af69b08f ("ASoC: wm_adsp: Refactor compress stream initialisation") Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20231204074158.12026-1-dinghao.liu@zju.edu.cn Signed-off-by: Mark Brown <broonie@kernel.org>
2023-12-04ASoC: da7219: Support low DC impedance headsetDavid Rau1-1/+1
Change the default MIC detection impedance threshold to 200ohm to support low mic DC impedance headset. Signed-off-by: David Rau <David.Rau.opensource@dm.renesas.com> Link: https://lore.kernel.org/r/20231201042933.26392-1-David.Rau.opensource@dm.renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-12-04ASoC: amd: acp: Add support for a new Huawei Matebook laptopMarian Postevca1-0/+14
This commit adds support for Huawei MateBook D16 2021 with Ryzen 4600H in driver acp3x-es83xx. Signed-off-by: Marian Postevca <posteuca@mutex.one> Link: https://lore.kernel.org/r/20231202223001.8025-1-posteuca@mutex.one Signed-off-by: Mark Brown <broonie@kernel.org>
2023-12-04drm/bridge: lt8912b: Add power suppliesStefan Eichenberger1-0/+30
Add supplies to the driver that can be used to turn the Lontium lt8912b on and off. It can have up to 7 independent supplies, we add them all and enable/disable them with bulk_enable/disable. Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231115121338.22959-4-francesco@dolcini.it
2023-12-04dt-bindings: display: bridge: lt8912b: Add power suppliesStefan Eichenberger1-0/+21
Add Lontium lt8912b power supplies. Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231115121338.22959-3-francesco@dolcini.it
2023-12-04drm/bridge: lt8912b: Add suspend/resume supportStefan Eichenberger1-0/+28
Add support for suspend and resume. The lt8912b will power off when going into suspend and power on when resuming. Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231115121338.22959-2-francesco@dolcini.it
2023-12-04mlxbf-bootctl: correctly identify secure boot with development keysDavid Thompson1-13/+26
The secure boot state of the BlueField SoC is represented by two bits: 0 = production state 1 = secure boot enabled 2 = non-secure (secure boot disabled) 3 = RMA state There is also a single bit to indicate whether production keys or development keys are being used when secure boot is enabled. This single bit (specified by MLXBF_BOOTCTL_SB_DEV_MASK) only has meaning if secure boot state equals 1 (secure boot enabled). The secure boot states are as follows: - “GA secured” is when secure boot is enabled with official production keys. - “Secured (development)” is when secure boot is enabled with development keys. Without this fix “GA Secured” is displayed on development cards which is misleading. This patch updates the logic in "lifecycle_state_show()" to handle the case where the SoC is configured for secure boot and is using development keys. Fixes: 79e29cb8fbc5c ("platform/mellanox: Add bootctl driver for Mellanox BlueField Soc") Reviewed-by: Khalil Blaiech <kblaiech@nvidia.com> Signed-off-by: David Thompson <davthompson@nvidia.com> Link: https://lore.kernel.org/r/20231130183515.17214-1-davthompson@nvidia.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-12-04regmap: fix bogus error on regcache_sync successMatthias Reichl1-2/+1
Since commit 0ec7731655de ("regmap: Ensure range selector registers are updated after cache sync") opening pcm512x based soundcards fail with EINVAL and dmesg shows sync cache and pm_runtime_get errors: [ 228.794676] pcm512x 1-004c: Failed to sync cache: -22 [ 228.794740] pcm512x 1-004c: ASoC: error at snd_soc_pcm_component_pm_runtime_get on pcm512x.1-004c: -22 This is caused by the cache check result leaking out into the regcache_sync return value. Fix this by making the check local-only, as the comment above the regcache_read call states a non-zero return value means there's nothing to do so the return value should not be altered. Fixes: 0ec7731655de ("regmap: Ensure range selector registers are updated after cache sync") Cc: stable@vger.kernel.org Signed-off-by: Matthias Reichl <hias@horus.com> Link: https://lore.kernel.org/r/20231203222216.96547-1-hias@horus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-12-04firmware: arm_scmi: Fix possible frequency truncation when using level ↵Sudeep Holla1-5/+7
indexing mode The multiplier is already promoted to unsigned long, however the frequency calculations done when using level indexing mode doesn't use the multiplier computed. It instead hardcodes the multiplier value of 1000 at all the usage sites. Clean that up by assigning the multiplier value of 1000 when using the perf level indexing mode and update the frequency calculations to use the multiplier instead. It should fix the possible frequency truncation for all the values greater than or equal to 4GHz on 64-bit machines. Fixes: 31c7c1397a33 ("firmware: arm_scmi: Add v3.2 perf level indexing mode support") Reported-by: Sibi Sankar <quic_sibis@quicinc.com> Closes: https://lore.kernel.org/all/20231129065748.19871-3-quic_sibis@quicinc.com/ Cc: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20231130204343.503076-2-sudeep.holla@arm.com Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-12-04firmware: arm_scmi: Fix frequency truncation by promoting multiplier typeSudeep Holla1-3/+3
Fix the possible frequency truncation for all values equal to or greater 4GHz on 64bit machines by updating the multiplier 'mult_factor' to 'unsigned long' type. It is also possible that the multiplier itself can be greater than or equal to 2^32. So we need to also fix the equation computing the value of the multiplier. Fixes: a9e3fbfaa0ff ("firmware: arm_scmi: add initial support for performance protocol") Reported-by: Sibi Sankar <quic_sibis@quicinc.com> Closes: https://lore.kernel.org/all/20231129065748.19871-3-quic_sibis@quicinc.com/ Cc: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20231130204343.503076-1-sudeep.holla@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-12-04r8152: Add RTL8152_INACCESSIBLE to r8153_aldps_en()Douglas Anderson1-0/+2
Delay loops in r8152 should break out if RTL8152_INACCESSIBLE is set so that they don't delay too long if the device becomes inaccessible. Add the break to the loop in r8153_aldps_en(). Fixes: 4214cc550bf9 ("r8152: check if disabling ALDPS is finished") Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-04r8152: Add RTL8152_INACCESSIBLE to r8153_pre_firmware_1()Douglas Anderson1-0/+2
Delay loops in r8152 should break out if RTL8152_INACCESSIBLE is set so that they don't delay too long if the device becomes inaccessible. Add the break to the loop in r8153_pre_firmware_1(). Fixes: 9370f2d05a2a ("r8152: support request_firmware for RTL8153") Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-04r8152: Add RTL8152_INACCESSIBLE to r8156b_wait_loading_flash()Douglas Anderson1-0/+2
Delay loops in r8152 should break out if RTL8152_INACCESSIBLE is set so that they don't delay too long if the device becomes inaccessible. Add the break to the loop in r8156b_wait_loading_flash(). Fixes: 195aae321c82 ("r8152: support new chips") Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-04r8152: Add RTL8152_INACCESSIBLE checks to more loopsDouglas Anderson1-0/+8
Previous commits added checks for RTL8152_INACCESSIBLE in the loops in the driver. There are still a few more that keep tripping the driver up in error cases and make things take longer than they should. Add those in. All the loops that are part of this commit existed in some form or another since the r8152 driver was first introduced, though RTL8152_INACCESSIBLE was known as RTL8152_UNPLUG before commit 715f67f33af4 ("r8152: Rename RTL8152_UNPLUG to RTL8152_INACCESSIBLE") Fixes: ac718b69301c ("net/usb: new driver for RTL8152") Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-04r8152: Hold the rtnl_lock for all of resetDouglas Anderson1-6/+7
As of commit d9962b0d4202 ("r8152: Block future register access if register access fails") there is a race condition that can happen between the USB device reset thread and napi_enable() (not) getting called during rtl8152_open(). Specifically: * While rtl8152_open() is running we get a register access error that's _not_ -ENODEV and queue up a USB reset. * rtl8152_open() exits before calling napi_enable() due to any reason (including usb_submit_urb() returning an error). In that case: * Since the USB reset is perform in a separate thread asynchronously, it can run at anytime USB device lock is not held - even before rtl8152_open() has exited with an error and caused __dev_open() to clear the __LINK_STATE_START bit. * The rtl8152_pre_reset() will notice that the netif_running() returns true (since __LINK_STATE_START wasn't cleared) so it won't exit early. * rtl8152_pre_reset() will then hang in napi_disable() because napi_enable() was never called. We can fix the race by making sure that the r8152 reset routines don't run at the same time as we're opening the device. Specifically we need the reset routines in their entirety rely on the return value of netif_running(). The only way to reliably depend on that is for them to hold the rntl_lock() mutex for the duration of reset. Grabbing the rntl_lock() mutex for the duration of reset seems like a long time, but reset is not expected to be common and the rtnl_lock() mutex is already held for long durations since the core grabs it around the open/close calls. Fixes: d9962b0d4202 ("r8152: Block future register access if register access fails") Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-04drm/display/dp: Add the remaining Square PHY patterns DPCD register definitionsKhaled Almahallawy1-0/+3
DP2.1 Specs added new DPCDs definitions for square pattern configs[1] These new definitions are used for UHBR Source Transmitter Equalizations tests[2]. Add the 3 new values for square pattern. v2: rebase [1]: DP2.1 Specs - 2.12.3.6.5 Square Pattern [2]: DP2.1 PHY CTS specs - 4.3 UHBR Source Transmitter Equalization Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Lee Shawn C <shawn.c.lee@intel.com> Signed-off-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231130231510.221143-1-khaled.almahallawy@intel.com
2023-12-04drm/i915/display: Don't use "proxy" headersAndy Shevchenko1-1/+1
The driver uses math.h and not util_macros.h. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231129140129.699767-1-andriy.shevchenko@linux.intel.com
2023-12-04drm/i915/syncmap: squelch a sparse warningJani Nikula1-1/+1
The code is fine, really, but tweak it to get rid of the sparse warning: drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231129173506.1194437-1-jani.nikula@intel.com
2023-12-04drm/qxl: remove unused declarationheminhong1-7/+0
Some functions are never used by the driver, removing the functions declaration, it can be reducing program size, and improving code readability and maintainability. Signed-off-by: heminhong <heminhong@kylinos.cn> Link: https://lore.kernel.org/r/20231110055031.57360-1-heminhong@kylinos.cn Signed-off-by: Maxime Ripard <mripard@kernel.org>
2023-12-04drm/drv: propagate errors from drm_modeset_register_all()Dmitry Baryshkov1-2/+8
In case the drm_modeset_register_all() function fails, its error code will be ignored. Instead make the drm_dev_register() bail out in case of such an error. Fixes: 79190ea2658a ("drm: Add callbacks for late registering") Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231202225552.1283638-1-dmitry.baryshkov@linaro.org
2023-12-04drm/imagination: Removed unused function to_pvr_vm_gpuva()Donald Robson1-6/+0
This function is now unused, hence it causes a compiler warning. drivers/gpu/drm/imagination/pvr_vm.c:112:22: warning: unused function 'to_pvr_vm_gpuva' [-Wunused-function] 112 | struct pvr_vm_gpuva *to_pvr_vm_gpuva(struct drm_gpuva *gpuva) | ^ Remove the function for now. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202311242159.hh8MWiAm-lkp@intel.com/ Fixes: ff5f643de0bf ("drm/imagination: Add GEM and VM related code") Signed-off-by: Donald Robson <donald.robson@imgtec.com> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231130160017.259902-5-donald.robson@imgtec.com
2023-12-04drm/imagination: pvr_gpuvm_free() now staticDonald Robson1-1/+1
The function below is used only within this source file, but is not static. drivers/gpu/drm/imagination/pvr_vm.c:542:6: error: no previous prototype for 'pvr_gpuvm_free' [-Werror=missing-prototypes] 542 | void pvr_gpuvm_free(struct drm_gpuvm *gpuvm) Make it static. Reported-by: Arnd Bergmann <arnd@arndb.de> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202311242159.hh8MWiAm-lkp@intel.com/ Fixes: ff5f643de0bf ("drm/imagination: Add GEM and VM related code") Signed-off-by: Donald Robson <donald.robson@imgtec.com> Link: https://lore.kernel.org/r/20231130160017.259902-4-donald.robson@imgtec.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2023-12-04drm/imagination: pvr_device_process_active_queues now staticDonald Robson1-1/+1
The function below is used only within this source file, but is not static. >> drivers/gpu/drm/imagination/pvr_device.c:129:6: warning: no previous prototype for function 'pvr_device_process_active_queues' [-Wmissing-prototypes] 129 | void pvr_device_process_active_queues(struct pvr_device *pvr_dev) | ^ drivers/gpu/drm/imagination/pvr_device.c:129:1: note: declare 'static' if the function is not intended to be used outside of this translation unit 129 | void pvr_device_process_active_queues(struct pvr_device *pvr_dev) | ^ | static 1 warning generated. Make it static. Reported-by: Arnd Bergmann <arnd@arndb.de> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202311250632.giVEx7MU-lkp@intel.com/ Fixes: eaf01ee5ba28 ("drm/imagination: Implement job submission and scheduling") Signed-off-by: Donald Robson <donald.robson@imgtec.com> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231130160017.259902-3-donald.robson@imgtec.com
2023-12-04drm/imagination: Fixed missing header in pvr_fw_metaDonald Robson1-0/+1
A missing header causes the compiler to warn that the function below is not forward declared. >> drivers/gpu/drm/imagination/pvr_fw_meta.c:33:1: warning: no previous prototype for function 'pvr_meta_cr_read32' [-Wmissing-prototypes] 33 | pvr_meta_cr_read32(struct pvr_device *pvr_dev, u32 reg_addr, u32 *reg_value_out) | ^ drivers/gpu/drm/imagination/pvr_fw_meta.c:32:1: note: declare 'static' if the function is not intended to be used outside of this translation unit 32 | int | ^ | static 1 warning generated. Include the correct header. Reported-by: Arnd Bergmann <arnd@arndb.de> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202311250226.Da2yiSKp-lkp@intel.com/ Fixes: cc1aeedb98ad ("drm/imagination: Implement firmware infrastructure and META FW support") Signed-off-by: Donald Robson <donald.robson@imgtec.com> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231130160017.259902-2-donald.robson@imgtec.com
2023-12-04drm/imagination: Fixed warning due to implicit cast to boolDonald Robson1-1/+2
This line appears to confuse the compiler and had been noticed previously in clang-tidy output. There isn't anything fundamentally wrong that I can see. I suspect that it just looks like a mistake - hence the first note. By making the second operand an actual bool result, const correctness can be preserved while silencing the warning. >> drivers/gpu/drm/imagination/pvr_device_info.c:230:47: warning: use of logical '&&' with constant operand [-Wconstant-logical-operand] 230 | } else if (features_size == mapping_max_size && (mapping_max & 63)) { | ^ ~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/imagination/pvr_device_info.c:230:47: note: use '&' for a bitwise operation 230 | } else if (features_size == mapping_max_size && (mapping_max & 63)) { | ^~ | & drivers/gpu/drm/imagination/pvr_device_info.c:230:47: note: remove constant to silence this warning 230 | } else if (features_size == mapping_max_size && (mapping_max & 63)) { | ~^~~~~~~~~~~~~~~~~~~~~ 1 warning generated. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202311241752.3iLyyFcA-lkp@intel.com/ Fixes: f99f5f3ea7ef ("drm/imagination: Add GPU ID parsing and firmware loading") Signed-off-by: Donald Robson <donald.robson@imgtec.com> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231130160017.259902-1-donald.robson@imgtec.com
2023-12-04drm/test: add a test suite for GEM objects backed by shmemMarco Pagani3-1/+386
This patch introduces an initial KUnit test suite for GEM objects backed by shmem buffers. Suggested-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Marco Pagani <marpagan@redhat.com> v5: - using __drm_kunit_helper_alloc_drm_device() to avoid local struct v4: - Add missing MMU dependency for DRM_GEM_SHMEM_HELPER (kernel test robot) v3: - Explicitly cast pointers in the helpers - Removed unused pointer to parent dev in struct fake_dev - Test entries reordering in Kconfig and Makefile sent as a separate patch v2: - Improved description of test cases - Cleaner error handling using KUnit actions - Alphabetical order in Kconfig and Makefile Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231130171417.74162-1-marpagan@redhat.com
2023-12-04greybus: gb-beagleplay: Ensure le for values in transportAyush Singh1-4/+5
Ensure that the following values are little-endian: - header->pad (which is used for cport_id) - header->size Fixes: ec558bbfea67 ("greybus: Add BeaglePlay Linux Driver") Reported-by: kernel test robot <yujie.liu@intel.com> Closes: https://lore.kernel.org/r/202311072329.Xogj7hGW-lkp@intel.com/ Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com> Link: https://lore.kernel.org/r/20231203075312.255233-1-ayushdevel1325@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04greybus: BeaglePlay driver needs CRC_CCITTRandy Dunlap1-0/+1
The gb-beagleplay driver uses crc_ccitt(), so it should select CRC_CCITT to make sure that the function is available. Fixes these build errors: s390-linux-ld: drivers/greybus/gb-beagleplay.o: in function `hdlc_append_tx_u8': gb-beagleplay.c:(.text+0x2c0): undefined reference to `crc_ccitt' s390-linux-ld: drivers/greybus/gb-beagleplay.o: in function `hdlc_rx_frame': gb-beagleplay.c:(.text+0x6a0): undefined reference to `crc_ccitt' Fixes: ec558bbfea67 ("greybus: Add BeaglePlay Linux Driver") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Ayush Singh <ayushdevel1325@gmail.com> Cc: Johan Hovold <johan@kernel.org> Cc: Alex Elder <elder@kernel.org> Cc: greybus-dev@lists.linaro.org Link: https://lore.kernel.org/r/20231031040909.21201-1-rdunlap@infradead.org Reviewed-by: Ayush Singh <ayushdevel1325@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04Revert "debugfs: annotate debugfs handlers vs. removal with lockdep"Johannes Berg3-23/+0
This reverts commit f4acfcd4deb1 ("debugfs: annotate debugfs handlers vs. removal with lockdep"), it appears to have false positives and really shouldn't have been in the -rc series with the fixes anyway. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Link: https://lore.kernel.org/r/20231202114936.fd55431ab160.I911aa53abeeca138126f690d383a89b13eb05667@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04Merge 6.7-rc4 into char-misc-linusGreg Kroah-Hartman320-1606/+3639
We need 6.7-rc4 in here as we need to revert one of the debugfs changes that came in that release through the wireless tree. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-04drm/i915/display: Split i915 specific code away from intel_fb.cJouni Högander4-63/+127
We are preparing for Xe driver. Backing object implementation is differing between i915 and Xe. Split i915 specific code into separate source file built only for i915. v9: - Use ERR_CAST v8: - return original error code from intel_fb_bo_lookup_valid_bo on failure v7: - drop #include <drm/drm_plane.h> - s/user_mode_cmd/mode_cmd/ - Use passed i915 pointer instead of to_i915(obj->base.dev) v6: Add missing intel_fb_bo.[ch] v5: - Keep drm_any_plane_has_format check in intel_fb.c - Use mode_cmd instead of user_mode_cmd for intel_fb_bo_lookup_valid_bo v4: Move drm_any_plane_has_format check into intel_fb_bo.c v3: Fix failure handling in intel_framebuffer_init v2: Couple of fixes to error value handling Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231203114840.841311-5-jouni.hogander@intel.com
2023-12-04drm/i915/display: Handle invalid fb_modifier in intel_fb_modifier_to_tilingJouni Högander1-1/+8
Lookup_modifier is returning INTEL_PLANE_CAP_TILING_4 on invalid fb_modifier value. Use lookup_modifier_or_null in intel_fb_modifier_to_tiling and return I915_TILING_NONE in case lookup_modifier_or_null returns null. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231203114840.841311-4-jouni.hogander@intel.com
2023-12-04drm/i915/display: Convert intel_fb_modifier_to_tiling as non-staticJouni Högander2-20/+22
We are about to split i915 specific code from intel_fb.c. Convert intel_fb_modifier_to_tiling as non-static to allow calling it from split code. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231203114840.841311-3-jouni.hogander@intel.com
2023-12-04drm/i915/display: use intel_bo_to_drm_bo in intel_fb.cJouni Högander1-6/+6
We are preparing for Xe driver. I915 and Xe object implementation are differing. Do not use i915_gem_object->base directly. Instead use intel_bo_to_drm_bo. Also use drm_gem_object_put instead of i915_gem_object_put. This should be ok as i915_gem_object_put is really just doing __drm_gem_object_put. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231203114840.841311-2-jouni.hogander@intel.com
2023-12-04io_uring: fix mutex_unlock with unreferenced ctxPavel Begunkov1-6/+3
Callers of mutex_unlock() have to make sure that the mutex stays alive for the whole duration of the function call. For io_uring that means that the following pattern is not valid unless we ensure that the context outlives the mutex_unlock() call. mutex_lock(&ctx->uring_lock); req_put(req); // typically via io_req_task_submit() mutex_unlock(&ctx->uring_lock); Most contexts are fine: io-wq pins requests, syscalls hold the file, task works are taking ctx references and so on. However, the task work fallback path doesn't follow the rule. Cc: <stable@vger.kernel.org> Fixes: 04fc6c802d ("io_uring: save ctx put/get for task_work submit") Reported-by: Jann Horn <jannh@google.com> Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://lore.kernel.org/io-uring/CAG48ez3xSoYb+45f1RLtktROJrpiDQ1otNvdR+YLQf7m+Krj5Q@mail.gmail.com/ Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-12-03drm: remove drm_bridge_hpd_disable() from drm_bridge_connector_destroy()Abhinav Kumar1-6/+0
drm_bridge_hpd_enable()/drm_bridge_hpd_disable() callbacks call into the respective driver's hpd_enable()/hpd_disable() ops. These ops control the HPD enable/disable logic which in some cases like MSM can be a dedicate hardware block to control the HPD. During probe_defer cases, a connector can be initialized and then later destroyed till the probe is retried. During connector destroy in these cases, the hpd_disable() callback gets called without a corresponding hpd_enable() leading to an unbalanced state potentially causing even a crash. This can be avoided by the respective drivers maintaining their own state logic to ensure that a hpd_disable() without a corresponding hpd_enable() just returns without doing anything. However, to have a generic fix it would be better to avoid the hpd_disable() callback from the connector destroy path and let the hpd_enable() / hpd_disable() balance be maintained by the corresponding drm_bridge_connector_enable_hpd() / drm_bridge_connector_disable_hpd() APIs which should get called by drm_kms_helper_disable_hpd(). changes in v2: - minor change in commit text (Dmitry) Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230919174813.26958-1-quic_abhinavk@quicinc.com
generated by cgit v1.2.3 (git 2.39.0) at 2025-10-02 11:43:51 +0300