summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-06-10HID: Intel-thc-hid: Intel-quicki2c: Add driver data supportEven Xu
This patch defines driver data structure and adds it into QuickI2C device structure. Changes PCI ID table to use PCI_DEVICE_DATA() to pass platform specific driver data into driver, let driver has capability to enable different hardware features according to different platform driver data. Signed-off-by: Even Xu <even.xu@intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-06-10HID: Intel-thc-hid: Intel-quicki2c: Refine code commentsEven Xu
Align capitalization of the first characters for all code comments and refine some descriptions. Signed-off-by: Even Xu <even.xu@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-06-10HID: Intel-thc-hid: Intel-thc: Introduce interrupt delay controlEven Xu
This patch adds support for a new feature, named "Interrupt Delay", allowing driver to set a specific delay time for next interrupt detection. It gives driver a capability to control THC waiting time for the next interrupt, to reduce the likelihood of spurious readings. APIs added: - thc_i2c_set_rx_int_delay(): Set I2C Rx input interrupt delay value - thc_i2c_rx_int_delay_enable(): Enable or disable I2C Rx interrupt delay As this interrupt delay feature is only applicable to RxDMA and must remain disabled during SWDMA operations, it also involves a change in SWDMA code to record the max input size control feature state before SWDMA and restore the state after SWDMA. Signed-off-by: Even Xu <even.xu@intel.com> Tested-by: Chong Han <chong.han@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-06-10HID: Intel-thc-hid: Intel-thc: Introduce max input size controlEven Xu
This patch adds support for a new feature, named "Max Input Size Control", allowing driver to set a maximum input size for RxDMA. This enhancement aims to prevent RxDMA buffer overruns caused by data corruption on the I2C bus, thereby improving overall system stability. APIs added: - thc_i2c_set_rx_max_size(): Set the maximum input size for I2C RxDMA. - thc_i2c_rx_max_size_enable(): Enable or disable the max input size control. As this max input size control feature is only applicable to RxDMA and must remain disabled during SWDMA operations, it also involves a change in SWDMA code to record the max input size control feature state before SWDMA and restore the state after SWDMA. Signed-off-by: Even Xu <even.xu@intel.com> Tested-by: Chong Han <chong.han@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-06-10HID: Intel-thc-hid: Intel-thc: Refine code commentsEven Xu
Align capitalization of the first characters for THC structure definition comments in header files. Signed-off-by: Even Xu <even.xu@intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-06-10HID: Intel-thc-hid: Intel-thc: Add thc_dma_content into kernel docEven Xu
Convert thc_dma_content structure comments format into kernel doc format, let it can be included into kernel doc. Signed-off-by: Even Xu <even.xu@intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-06-10HID: nintendo: avoid bluetooth suspend/resume stallsDaniel J. Ogorchock
Ensure we don't stall or panic the kernel when using bluetooth-connected controllers. This was reported as an issue on android devices using kernel 6.6 due to the resume hook which had been added for usb joycons. First, set a new state value to JOYCON_CTLR_STATE_SUSPENDED in a newly-added nintendo_hid_suspend. This makes sure we will not stall out the kernel waiting for input reports during led classdev suspend. The stalls could happen if connectivity is unreliable or lost to the controller prior to suspend. Second, since we lose connectivity during suspend, do not try joycon_init() for bluetooth controllers in the nintendo_hid_resume path. Tested via multiple suspend/resume flows when using the controller both in USB and bluetooth modes. Signed-off-by: Daniel J. Ogorchock <djogorchock@gmail.com> Reviewed-by: Silvan Jegen <s.jegen@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-06-10HID: wacom: fix kobject reference count leakQasim Ijaz
When sysfs_create_files() fails in wacom_initialize_remotes() the error is returned and the cleanup action will not have been registered yet. As a result the kobject???s refcount is never dropped, so the kobject can never be freed leading to a reference leak. Fix this by calling kobject_put() before returning. Fixes: 83e6b40e2de6 ("HID: wacom: EKR: have the wacom resources dynamically allocated") Acked-by: Ping Cheng <ping.cheng@wacom.com> Cc: stable@vger.kernel.org Signed-off-by: Qasim Ijaz <qasdev00@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-06-10HID: wacom: fix memory leak on sysfs attribute creation failureQasim Ijaz
When sysfs_create_files() fails during wacom_initialize_remotes() the fifo buffer is not freed leading to a memory leak. Fix this by calling kfifo_free() before returning. Fixes: 83e6b40e2de6 ("HID: wacom: EKR: have the wacom resources dynamically allocated") Reviewed-by: Ping Cheng <ping.cheng@wacom.com> Cc: stable@vger.kernel.org Signed-off-by: Qasim Ijaz <qasdev00@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-06-10HID: wacom: fix memory leak on kobject creation failureQasim Ijaz
During wacom_initialize_remotes() a fifo buffer is allocated with kfifo_alloc() and later a cleanup action is registered during devm_add_action_or_reset() to clean it up. However if the code fails to create a kobject and register it with sysfs the code simply returns -ENOMEM before the cleanup action is registered leading to a memory leak. Fix this by ensuring the fifo is freed when the kobject creation and registration process fails. Fixes: 83e6b40e2de6 ("HID: wacom: EKR: have the wacom resources dynamically allocated") Reviewed-by: Ping Cheng <ping.cheng@wacom.com> Cc: stable@vger.kernel.org Signed-off-by: Qasim Ijaz <qasdev00@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-06-10intel_idle: Update arguments of mwait_idle_with_hints()Uros Bizjak
Commit a17b37a3f416 ("x86/idle: Change arguments of mwait_idle_with_hints() to u32") changed the type of arguments of mwait_idle_with_hints() from unsigned long to u32. Change the type of variables in the call to mwait_idle_with_hints() to unsigned int to follow the change. Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Reviewed-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Link: https://patch.msgid.link/20250609063528.48715-1-ubizjak@gmail.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-06-10ACPI: resource: Use IRQ override on MACHENIKE 16PWentao Guan
Use ACPI IRQ override on MACHENIKE laptop to make the internal keyboard work. Add a new entry to the irq1_edge_low_force_override structure, similar to the existing ones. Link: https://bbs.deepin.org.cn/zh/post/287628 Signed-off-by: Wentao Guan <guanwentao@uniontech.com> Link: https://patch.msgid.link/20250603122059.1072790-1-guanwentao@uniontech.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-06-10ACPI: EC: Ignore ECDT tables with an invalid ID stringArmin Wolf
On the MSI Modern 14 C5M the ECDT table contains invalid data: UID : 00000000 GPE Number : 00 /* Invalid, 03 would be correct */ Namepath : "" /* Invalid, "\_SB.PCI0.SBRG.EC" would * be correct */ This slows down the EC access as the wrong GPE event is used for communication. Additionally the ID string is invalid. Ignore such faulty ECDT tables by verifying that the ID string has a valid format. Tested-by: glpnk@proton.me Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20250529235310.540530-1-W_Armin@gmx.de Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-06-10ACPI: CPPC: Fix NULL pointer dereference when nosmp is usedYunhui Cui
With nosmp in cmdline, other CPUs are not brought up, leaving their cpc_desc_ptr NULL. CPU0's iteration via for_each_possible_cpu() dereferences these NULL pointers, causing panic. Panic backtrace: [ 0.401123] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000b8 ... [ 0.403255] [<ffffffff809a5818>] cppc_allow_fast_switch+0x6a/0xd4 ... Kernel panic - not syncing: Attempted to kill init! Fixes: 3cc30dd00a58 ("cpufreq: CPPC: Enable fast_switch") Reported-by: Xu Lu <luxu.kernel@bytedance.com> Signed-off-by: Yunhui Cui <cuiyunhui@bytedance.com> Link: https://patch.msgid.link/20250604023036.99553-1-cuiyunhui@bytedance.com [ rjw: New subject ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-06-10ACPI: PAD: Update arguments of mwait_idle_with_hints()Uros Bizjak
Commit a17b37a3f416 ("x86/idle: Change arguments of mwait_idle_with_hints() to u32") changed the type of arguments of mwait_idle_with_hints() from unsigned long to u32. Change the type of variables in the call to mwait_idle_with_hints() to unsigned int to follow the change. Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Link: https://patch.msgid.link/20250609064235.49146-1-ubizjak@gmail.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-06-10clk: qcom: camcc-x1e80100: Move PLL & clk configuration to really probeJagadeesh Kona
Camera PLLs on X1E80100 require both MMCX and MXC rails to be kept ON to configure the PLLs properly. Hence move runtime power management, PLL configuration and enabling critical clocks to qcom_cc_really_probe() which ensures all required power domains are in enabled state before configuring the PLLs or enabling the clocks. Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # Dell Inspiron Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> Link: https://lore.kernel.org/r/20250530-videocc-pll-multi-pd-voting-v5-12-02303b3a582d@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-10clk: qcom: camcc-sm8650: Move PLL & clk configuration to really probeJagadeesh Kona
Camera PLLs on SM8650 require both MMCX and MXC rails to be kept ON to configure the PLLs properly. Hence move runtime power management, PLL configuration and enabling critical clocks to qcom_cc_really_probe() which ensures all required power domains are in enabled state before configuring the PLLs or enabling the clocks. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20250530-videocc-pll-multi-pd-voting-v5-11-02303b3a582d@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-10clk: qcom: camcc-sm8550: Move PLL & clk configuration to really probeJagadeesh Kona
Camera PLLs on SM8550 require both MMCX and MXC rails to be kept ON to configure the PLLs properly. Hence move runtime power management, PLL configuration and enabling critical clocks to qcom_cc_really_probe() which ensures all required power domains are in enabled state before configuring the PLLs or enabling the clocks. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20250530-videocc-pll-multi-pd-voting-v5-10-02303b3a582d@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-10clk: qcom: camcc-sm8450: Move PLL & clk configuration to really probeJagadeesh Kona
Camera PLLs on SM8450/SM8475 require both MMCX and MXC rails to be kept ON to configure the PLLs properly. Hence move runtime power management, PLL configuration and enable critical clocks to qcom_cc_really_probe() which ensures all required power domains are in enabled state before configuring the PLLs or enabling the clocks. This change also removes the modelling for cam_cc_gdsc_clk and keeps it always ON from probe since using CLK_IS_CRITICAL will prevent the clock controller associated power domains from collapsing due to clock framework invoking clk_pm_runtime_get() during prepare. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20250530-videocc-pll-multi-pd-voting-v5-9-02303b3a582d@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-10clk: qcom: videocc-sm8550: Move PLL & clk configuration to really probeJagadeesh Kona
Video PLLs on SM8550/SM8650 require both MMCX and MXC rails to be kept ON to configure the PLLs properly. Hence move runtime power management, PLL configuration and enable critical clocks to qcom_cc_really_probe() which ensures all required power domains are in enabled state before configuring the PLLs or enabling the clocks. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250530-videocc-pll-multi-pd-voting-v5-8-02303b3a582d@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-10clk: qcom: videocc-sm8450: Move PLL & clk configuration to really probeJagadeesh Kona
Video PLLs on SM8450/SM8475 require both MMCX and MXC rails to be kept ON to configure the PLLs properly. Hence move runtime power management, PLL configuration and enable critical clocks to qcom_cc_really_probe() which ensures all required power domains are in enabled state before configuring the PLLs or enabling the clocks. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> Link: https://lore.kernel.org/r/20250530-videocc-pll-multi-pd-voting-v5-7-02303b3a582d@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-10clk: qcom: common: Add support to configure clk regs in qcom_cc_really_probeJagadeesh Kona
Add support to configure PLLS and clk registers in qcom_cc_really_probe(). This ensures all required power domains are enabled and kept ON by runtime PM code in qcom_cc_really_probe() before configuring the PLLS or clock registers. Add support for qcom_cc_driver_data struct to maintain the clock controllers PLLs and CBCRs data, and a pointer of it can be stored in clock descriptor structure. If any clock controller driver requires to program some additional misc register settings, it can register the clk_regs_configure() callback in the driver data. Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250530-videocc-pll-multi-pd-voting-v5-6-02303b3a582d@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-10clk: qcom: common: Handle runtime power management in qcom_cc_really_probeJagadeesh Kona
Add support for runtime power management in qcom_cc_really_probe() to commonize it across all the clock controllers. The runtime power management is not required for all clock controllers, hence handle the rpm based on use_rpm flag in clock controller descriptor. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> Link: https://lore.kernel.org/r/20250530-videocc-pll-multi-pd-voting-v5-5-02303b3a582d@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-10clk: qcom: clk-alpha-pll: Add support for common PLL configuration functionTaniya Das
To properly configure the PLLs on recent chipsets, it often requires more than one power domain to be kept ON. The support to enable multiple power domains is being added in qcom_cc_really_probe() and PLLs should be configured post all the required power domains are enabled. Hence integrate PLL configuration into clk_alpha_pll structure and add support for qcom_clk_alpha_pll_configure() function which can be called from qcom_cc_really_probe() to configure the clock controller PLLs after all required power domains are enabled. Signed-off-by: Taniya Das <quic_tdas@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> Link: https://lore.kernel.org/r/20250530-videocc-pll-multi-pd-voting-v5-4-02303b3a582d@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-10ACPI: APEI: EINJ: Do not fail einj_init() on faux_device_create() failureDan Williams
CXL has a symbol dependency on einj_core.ko, so if einj_init() fails then cxl_core.ko fails to load. Prior to the faux_device_create() conversion, einj_probe() failures were tracked by the einj_initialized flag without failing einj_init(). Revert to that behavior and always succeed einj_init() given there is no way, and no pressing need, to discern faux device-create vs device-probe failures. This situation arose because CXL knows proper kernel named objects to trigger errors against, but acpi-einj knows how to perform the error injection. The injection mechanism is shared with non-CXL use cases. The result is CXL now has a module dependency on einj-core.ko, and init/probe failures are handled at runtime. Fixes: 6cb9441bfe8d ("ACPI: APEI: EINJ: Transition to the faux device interface") Signed-off-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Ben Cheatham <benjamin.cheatham@amd.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/20250607033228.1475625-4-dan.j.williams@intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-06-10driver core: faux: Quiet probe failuresDan Williams
The acpi-einj conversion to faux_device_create() leads to a noisy error message when the error injection facility is disabled. Quiet the error as CXL error injection via ACPI expects the module to stay loaded even if the error injection facility is disabled. This situation arose because CXL knows proper kernel named objects to trigger errors against, but acpi-einj knows how to perform the error injection. The injection mechanism is shared with non-CXL use cases. The result is CXL now has a module dependency on einj-core.ko, and init/probe failures are handled at runtime. Fixes: 6cb9441bfe8d ("ACPI: APEI: EINJ: Transition to the faux device interface") Signed-off-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/20250607033228.1475625-3-dan.j.williams@intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-06-10driver core: faux: Suppress bind attributesDan Williams
faux_device_create() is almost a suitable candidate to replace platform_driver_probe() if not for the fact that faux_device_create() supports dynamic attach/detach of the driver. Drop the bind attributes with the expectation that simple faux devices can always assume that the device is permanently bound at create, and only unbound at 'destroy'. The acpi-einj driver depends on static bind. Fixes: 6cb9441bfe8d ("ACPI: APEI: EINJ: Transition to the faux device interface") Signed-off-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/20250607033228.1475625-2-dan.j.williams@intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-06-10efi: Drop preprocessor directives from zboot.ldsVitaly Kuznetsov
Older versions of `ld` don't seem to support preprocessor directives in linker scripts, e.g. on RHEL9's ld-2.35.2-63.el9 the build fails with: ld:./drivers/firmware/efi/libstub/zboot.lds:32: ignoring invalid character `#' in expression ld:./drivers/firmware/efi/libstub/zboot.lds:33: syntax error We don't seem to need these '#ifdef', no empty .sbat section is created when CONFIG_EFI_SBAT_FILE="": # objdump -h arch/arm64/boot/vmlinuz.efi arch/arm64/boot/vmlinuz.efi: file format pei-aarch64-little Sections: Idx Name Size VMA LMA File off Algn 0 .text 00b94000 0000000000001000 0000000000001000 00001000 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 00000200 0000000000b95000 0000000000b95000 00b95000 2**2 CONTENTS, ALLOC, LOAD, DATA Fixes: 0f9a1739dd0e ("efi: zboot specific mechanism for embedding SBAT section") Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-06-10e1000: Move cancel_work_sync to avoid deadlockJoe Damato
Previously, e1000_down called cancel_work_sync for the e1000 reset task (via e1000_down_and_stop), which takes RTNL. As reported by users and syzbot, a deadlock is possible in the following scenario: CPU 0: - RTNL is held - e1000_close - e1000_down - cancel_work_sync (cancel / wait for e1000_reset_task()) CPU 1: - process_one_work - e1000_reset_task - take RTNL To remedy this, avoid calling cancel_work_sync from e1000_down (e1000_reset_task does nothing if the device is down anyway). Instead, call cancel_work_sync for e1000_reset_task when the device is being removed. Fixes: e400c7444d84 ("e1000: Hold RTNL when e1000_down can be called") Reported-by: syzbot+846bb38dc67fe62cc733@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/683837bf.a00a0220.52848.0003.GAE@google.com/ Reported-by: John <john.cs.hey@gmail.com> Closes: https://lore.kernel.org/netdev/CAP=Rh=OEsn4y_2LvkO3UtDWurKcGPnZ_NPSXK=FbgygNXL37Sw@mail.gmail.com/ Signed-off-by: Joe Damato <jdamato@fastly.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Acked-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-06-10ice/ptp: fix crosstimestamp reportingAnton Nadezhdin
Set use_nsecs=true as timestamp is reported in ns. Lack of this result in smaller timestamp error window which cause error during phc2sys execution on E825 NICs: phc2sys[1768.256]: ioctl PTP_SYS_OFFSET_PRECISE: Invalid argument This problem was introduced in the cited commit which omitted setting use_nsecs to true when converting the ice driver to use convert_base_to_cs(). Testing hints (ethX is PF netdev): phc2sys -s ethX -c CLOCK_REALTIME -O 37 -m phc2sys[1769.256]: CLOCK_REALTIME phc offset -5 s0 freq -0 delay 0 Fixes: d4bea547ebb57 ("ice/ptp: Remove convert_art_to_tsc()") Signed-off-by: Anton Nadezhdin <anton.nadezhdin@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-06-10iavf: fix reset_task for early reset eventAhmed Zaki
If a reset event is received from the PF early in the init cycle, the state machine hangs for about 25 seconds. Reproducer: echo 1 > /sys/class/net/$PF0/device/sriov_numvfs ip link set dev $PF0 vf 0 mac $NEW_MAC The log shows: [792.620416] ice 0000:5e:00.0: Enabling 1 VFs [792.738812] iavf 0000:5e:01.0: enabling device (0000 -> 0002) [792.744182] ice 0000:5e:00.0: Enabling 1 VFs with 17 vectors and 16 queues per VF [792.839964] ice 0000:5e:00.0: Setting MAC 52:54:00:00:00:11 on VF 0. VF driver will be reinitialized [813.389684] iavf 0000:5e:01.0: Failed to communicate with PF; waiting before retry [818.635918] iavf 0000:5e:01.0: Hardware came out of reset. Attempting reinit. [818.766273] iavf 0000:5e:01.0: Multiqueue Enabled: Queue pair count = 16 Fix it by scheduling the reset task and making the reset task capable of resetting early in the init cycle. Fixes: ef8693eb90ae3 ("i40evf: refactor reset handling") Signed-off-by: Ahmed Zaki <ahmed.zaki@intel.com> Tested-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Signed-off-by: Marcin Szycik <marcin.szycik@linux.intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-06-10i40e: retry VFLR handling if there is ongoing VF resetRobert Malz
When a VFLR interrupt is received during a VF reset initiated from a different source, the VFLR may be not fully handled. This can leave the VF in an undefined state. To address this, set the I40E_VFLR_EVENT_PENDING bit again during VFLR handling if the reset is not yet complete. This ensures the driver will properly complete the VF reset in such scenarios. Fixes: 52424f974bc5 ("i40e: Fix VF hang when reset is triggered on another VF") Signed-off-by: Robert Malz <robert.malz@canonical.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-06-10i40e: return false from i40e_reset_vf if reset is in progressRobert Malz
The function i40e_vc_reset_vf attempts, up to 20 times, to handle a VF reset request, using the return value of i40e_reset_vf as an indicator of whether the reset was successfully triggered. Currently, i40e_reset_vf always returns true, which causes new reset requests to be ignored if a different VF reset is already in progress. This patch updates the return value of i40e_reset_vf to reflect when another VF reset is in progress, allowing the caller to properly use the retry mechanism. Fixes: 52424f974bc5 ("i40e: Fix VF hang when reset is triggered on another VF") Signed-off-by: Robert Malz <robert.malz@canonical.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-06-10drm/xe: Reorder 'Get pages failed' messageMatthew Brost
Print the error from get pages failing, not the cast to -ENODATA. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>> Link: https://lore.kernel.org/r/20250610045649.3149801-1-matthew.brost@intel.com
2025-06-10pinctrl: cirrus: madera-core: Use devm_pinctrl_register_mappings()Thomas Richard
Use devm_pinctrl_register_mappings(), so the mappings are automatically unregistered by the core. If pinctrl_enable() failed during the probe, pinctrl_mappings were not freed. Now it is done by the core. Fixes: 218d72a77b0b ("pinctrl: madera: Add driver for Cirrus Logic Madera codecs") Signed-off-by: Thomas Richard <thomas.richard@bootlin.com> Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/20250609-pinctrl-madera-devm-pinctrl-register-mappings-v1-1-ba2c2822cf6c@bootlin.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-06-10pinctrl: sunxi: dt: Consider pin base when calculating bank number from pinChen-Yu Tsai
In prepare_function_table() when the pinctrl function table IRQ entries are generated, the pin bank is calculated from the absolute pin number; however the IRQ bank mux array is indexed from the first pin bank of the controller. For R_PIO controllers, this means the absolute pin bank is way off from the relative pin bank used for array indexing. Correct this by taking into account the pin base of the controller. Fixes: f5e2cd34b12f ("pinctrl: sunxi: allow reading mux values from DT") Signed-off-by: Chen-Yu Tsai <wens@csie.org> Link: https://lore.kernel.org/20250607135203.2085226-1-wens@kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-06-10ata: pata_cs5536: fix build on 32-bit UMLJohannes Berg
On 32-bit ARCH=um, CONFIG_X86_32 is still defined, so it doesn't indicate building on real X86 machines. There's no MSR on UML though, so add a check for CONFIG_X86. Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Link: https://lore.kernel.org/r/20250606090110.15784-2-johannes@sipsolutions.net Signed-off-by: Niklas Cassel <cassel@kernel.org>
2025-06-10drm/meson: fix more rounding issues with 59.94Hz modesMartin Blumenstingl
Commit 1017560164b6 ("drm/meson: use unsigned long long / Hz for frequency types") attempts to resolve video playback using 59.94Hz. using YUV420 by changing the clock calculation to use Hz instead of kHz (thus yielding more precision). The basic calculation itself is correct, however the comparisions in meson_vclk_vic_supported_freq() and meson_vclk_setup() don't work anymore for 59.94Hz modes (using the freq * 1000 / 1001 logic). For example, drm/edid specifies a 593407kHz clock for 3840x2160@59.94Hz. With the mentioend commit we convert this to Hz. Then meson_vclk tries to find a matchig "params" entry (as the clock setup code currently only supports specific frequencies) by taking the venc_freq from the params and calculating the "alt frequency" (used for the 59.94Hz modes) from it, which is: (594000000Hz * 1000) / 1001 = 593406593Hz Similar calculation is applied to the phy_freq (TMDS clock), which is 10 times the pixel clock. Implement a new meson_vclk_freqs_are_matching_param() function whose purpose is to compare if the requested and calculated frequencies. They may not match exactly (for the reasons mentioned above). Allow the clocks to deviate slightly to make the 59.94Hz modes again. Fixes: 1017560164b6 ("drm/meson: use unsigned long long / Hz for frequency types") Reported-by: Christian Hewitt <christianshewitt@gmail.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250609202751.962208-1-martin.blumenstingl@googlemail.com
2025-06-10drm/meson: use vclk_freq instead of pixel_freq in debug printMartin Blumenstingl
meson_vclk_vic_supported_freq() has a debug print which includes the pixel freq. However, within the whole function the pixel freq is irrelevant, other than checking the end of the params array. Switch to printing the vclk_freq which is being compared / matched against the inputs to the function to avoid confusion when analyzing error reports from users. Fixes: e5fab2ec9ca4 ("drm/meson: vclk: add support for YUV420 setup") Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250606221031.3419353-1-martin.blumenstingl@googlemail.com
2025-06-10drm/meson: fix debug log statement when setting the HDMI clocksMartin Blumenstingl
The "phy" and "vclk" frequency labels were swapped, making it more difficult to debug driver errors. Swap the label order to make them match with the actual frequencies printed to correct this. Fixes: e5fab2ec9ca4 ("drm/meson: vclk: add support for YUV420 setup") Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250606203729.3311592-1-martin.blumenstingl@googlemail.com
2025-06-10pinctrl: meson: support amlogic S6/S7/S7D SoCXianwei Zhao
In some Amlogic SoCs, to save register space or due to some abnormal arrangements, two sets of pins share one mux register. A group starting from pin0 is the main pin group, which acquires the register address through DTS and has management permissions, but the register bit offset is undetermined. Another GPIO group as a subordinate group. Some pins mux use share register and bit offset from bit0 . But this group do not have register management permissions. This submission implements this situation. Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com> Link: https://lore.kernel.org/20250527-s6-s7-pinctrl-v3-3-44f6a0451519@amlogic.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-06-10pinctrl: meson: a4: remove special data processingXianwei Zhao
According to the data specifications of Amlogic's existing SoCs, the function register offset and the bit offset are the same value among various chips. Therefore, general processing can be carried out without the need for private data modification. Drop special data processing. Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com> Link: https://lore.kernel.org/20250527-s6-s7-pinctrl-v3-2-44f6a0451519@amlogic.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-06-10drm/panel: ilitek-ili9881c: Add configuration for 7" Raspberry Pi 720x1280Marek Vasut
Add configuration for the 7" Raspberry Pi 720x1280 DSI panel based on ili9881. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250608142908.54121-3-marek.vasut+renesas@mailbox.org
2025-06-10drm/panel: ilitek-ili9881c: Allow configuration of the number of lanesMarek Vasut
Not all panels use all 4 data lanes, so allow configuration based on the compatible string. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250608142908.54121-2-marek.vasut+renesas@mailbox.org
2025-06-10drm/panel: st7701: Add Winstar wf40eswaa6mnn0 panel supportStefan Eichenberger
The Winstar wf40eswaa6mnn0 panel is a square 4.0" TFT LCD with a resolution of 480x480 pixels. This panel is driven by the Sitronix ST7701 controller and uses a MIPI DSI interface. The settings are based on the panel's datasheet and the init sequence provided by Winstar. It was tested on a Verdin iMX8MP from Toradex with a Carrier Board providing a MIPI DSI interface. Signed-off-by: Stefan Eichenberger <eichest@gmail.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250606114644.105371-2-eichest@gmail.com
2025-06-10ata: libata-acpi: Do not assume 40 wire cable if no devices are enabledTasos Sahanidis
On at least an ASRock 990FX Extreme 4 with a VIA VT6330, the devices have not yet been enabled by the first time ata_acpi_cbl_80wire() is called. This means that the ata_for_each_dev loop is never entered, and a 40 wire cable is assumed. The VIA controller on this board does not report the cable in the PCI config space, thus having to fall back to ACPI even though no SATA bridge is present. The _GTM values are correctly reported by the firmware through ACPI, which has already set up faster transfer modes, but due to the above the controller is forced down to a maximum of UDMA/33. Resolve this by modifying ata_acpi_cbl_80wire() to directly return the cable type. First, an unknown cable is assumed which preserves the mode set by the firmware, and then on subsequent calls when the devices have been enabled, an 80 wire cable is correctly detected. Since the function now directly returns the cable type, it is renamed to ata_acpi_cbl_pata_type(). Signed-off-by: Tasos Sahanidis <tasos@tasossah.com> Link: https://lore.kernel.org/r/20250519085945.1399466-1-tasos@tasossah.com Signed-off-by: Niklas Cassel <cassel@kernel.org>
2025-06-10drm/panel: visionox-rm69299: support the variant found in the SHIFT6mqCaleb Connolly
Add support for another variant of the rm69299 panel. This panel is 1080x2160 and is found in the shift-axolotl (SHIFT6mq). Signed-off-by: Caleb Connolly <caleb@connolly.tech> [narmstrong: moved to panel_desc] Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250509-topic-misc-shift6-panel-v2-6-c2c2d52abd51@linaro.org
2025-06-10drm/panel: visionox-rm69299: switch to devm_regulator_bulk_get_const()Neil Armstrong
Switch to devm_regulator_bulk_get_const() to move the supply data to const. Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250509-topic-misc-shift6-panel-v2-4-c2c2d52abd51@linaro.org
2025-06-10drm/panel: visionox-rm69299: switch to _multi variantsNeil Armstrong
Switch to the DSI _multi variants to simplify error handling. Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250509-topic-misc-shift6-panel-v2-3-c2c2d52abd51@linaro.org
2025-06-10drm/panel: visionox-rm69299: add plumbing to support panel variantsNeil Armstrong
In order to support a panel variant, add plumbing code to pass init sequence and mode as compatible data. Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250509-topic-misc-shift6-panel-v2-2-c2c2d52abd51@linaro.org