summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-01-07i2c: keba: drop check because i2c_unregister_device() is NULL safeWolfram Sang
No need to check the argument of i2c_unregister_device() because the function itself does it. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2025-01-07PCI/bwctrl: Fix NULL pointer deref on unbind and bindLukas Wunner
The interrupt handler for bandwidth notifications, pcie_bwnotif_irq(), dereferences a "data" pointer. On unbind, that pointer is set to NULL by pcie_bwnotif_remove(). However the interrupt handler may still be invoked afterwards and will dereference that NULL pointer. That's because the interrupt is requested using a devm_*() helper and the driver core releases devm_*() resources *after* calling ->remove(). pcie_bwnotif_remove() does clear the Link Bandwidth Management Interrupt Enable and Link Autonomous Bandwidth Interrupt Enable bits in the Link Control Register, but that won't prevent execution of pcie_bwnotif_irq(): The interrupt for bandwidth notifications may be shared with AER, DPC, PME, and hotplug. So pcie_bwnotif_irq() may be executed as long as the interrupt is requested. There's a similar race on bind: pcie_bwnotif_probe() requests the interrupt when the "data" pointer still points to NULL. A NULL pointer deref may thus likewise occur if AER, DPC, PME or hotplug raise an interrupt in-between the bandwidth controller's call to devm_request_irq() and assignment of the "data" pointer. Drop the devm_*() usage and reorder requesting of the interrupt to fix the issue. While at it, drop a stray but harmless no_free_ptr() invocation when assigning the "data" pointer in pcie_bwnotif_probe(). Ilpo points out that the locking on unbind and bind needs to be symmetric, so move the call to pcie_bwnotif_disable() inside the critical section protected by pcie_bwctrl_setspeed_rwsem and pcie_bwctrl_lbms_rwsem. Evert reports a hang on shutdown of an ASUS ROG Strix SCAR 17 G733PYV. The issue is no longer reproducible with the present commit. Evert found that attaching a USB-C monitor prevented the hang. The machine contains an ASMedia USB 3.2 controller below a hotplug-capable Root Port. So one possible explanation is that the controller gets hot-removed on shutdown unless something is connected. And the ensuing hotplug interrupt occurs exactly when the bandwidth controller is unregistering. The precise cause could not be determined because the screen had already turned black when the hang occurred. Link: https://lore.kernel.org/r/ae2b02c9cfbefff475b6e132b0aa962aaccbd7b2.1736162539.git.lukas@wunner.de Fixes: 665745f27487 ("PCI/bwctrl: Re-add BW notification portdrv as PCIe BW controller") Reported-by: Evert Vorster <evorster@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219629 Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Evert Vorster <evorster@gmail.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-01-07regmap: sdw-mbq: Add support for SDCA deferred controlsCharles Keepax
The SDCA specification allows for controls to be deferred. In the case of a deferred control the device will return COMMAND_IGNORED to the 8-bit operation that would cause the value to commit. Which is the final 8-bits on a write, or the first 8-bits on a read. In the case of receiving a defer, the regmap will poll the SDCA function busy bit, after which the transaction will be retried, returning an error if the function busy does not clear within a chip specific timeout. Since this is common SDCA functionality which is the 99% use-case for MBQs it makes sense to incorporate this functionality into the register map. If no MBQ configuration is specified, the behaviour will default to the existing behaviour. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250107154408.814455-5-ckeepax@opensource.cirrus.com Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-07regmap: sdw-mbq: Add support for further MBQ register sizesCharles Keepax
SoundWire MBQ register maps typically contain a variety of register sizes, which doesn't map ideally to the regmap abstraction which expects register maps to have a consistent size. Currently the MBQ register map only allows 16-bit registers to be defined, however this leads to complex CODEC driver implementations with an 8-bit register map and a 16-bit MBQ, every control will then have a custom get and put handler that allows them to access different register maps. Further more 32-bit MBQ quantities are not currently supported. Add support for additional MBQ sizes and to avoid the complexity of multiple register maps treat the val_size as a maximum size for the register map. Within the regmap use an ancillary callback to determine how many bytes to actually read/write to the hardware for a specific register. In the case that no callback is defined the behaviour defaults back to the existing behaviour of a fixed size register map. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250107154408.814455-4-ckeepax@opensource.cirrus.com Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-07eth: fbnic: Revert "eth: fbnic: Add hardware monitoring support via HWMON ↵Su Hui
interface" There is a garbage value problem in fbnic_mac_get_sensor_asic(). 'fw_cmpl' is uninitialized which makes 'sensor' and '*val' to be stored garbage value. Revert commit d85ebade02e8 ("eth: fbnic: Add hardware monitoring support via HWMON interface") to avoid this problem. Fixes: d85ebade02e8 ("eth: fbnic: Add hardware monitoring support via HWMON interface") Signed-off-by: Su Hui <suhui@nfschina.com> Suggested-by: Jakub Kicinski <kuba@kernel.org> Suggested-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Link: https://patch.msgid.link/20250106023647.47756-1-suhui@nfschina.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-07clk: clocking-wizard: calculate dividers fractional partsShubhrajyoti Datta
Calculate dividers fractional parts to optimally modulate output frequency. Clocking wizard supports having multiplier m and divisors d and o. Currently the fractional parts of m and o are not utilised. For the pixel clock usecases a higher accuracy is needed.. Adding support for m and o to have fractional values. Co-developed-by: Anatoliy Klymenko <anatoliy.klymenko@amd.com> Signed-off-by: Anatoliy Klymenko <anatoliy.klymenko@amd.com> Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com> Tested-by: Anatoliy Klymenko <anatoliy.klymenko@amd.com> Link: https://lore.kernel.org/r/20250106082937.29555-1-shubhrajyoti.datta@amd.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2025-01-07Merge tag 'renesas-clk-for-v6.14-tag2' of ↵Stephen Boyd
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into clk-renesas Pull Renesas clk driver updates from Geert Uytterhoeven: - Add support for the RZ/G3E (R9A09G047) SoC - Add Module Stop (MSTOP) support on RZ/V2H - Add Image Signal Processor helper block (FCPVX and VSPX) clocks on R-Car V4H SoC - Add System Controller (SYS) reset and Generic Interrupt Controller (GIC) clock and reset entries on RZ/V2H * tag 'renesas-clk-for-v6.14-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers: dt-bindings: clock: renesas,r9a08g045-vbattb: Fix include guard clk: renesas: r9a09g057: Add clock and reset entries for GIC clk: renesas: r9a09g057: Add reset entry for SYS clk: renesas: r8a779g0: Add VSPX clocks clk: renesas: r8a779g0: Add FCPVX clocks clk: renesas: r9a09g047: Add I2C clocks/resets clk: renesas: r9a09g047: Add CA55 core clocks clk: renesas: rzv2h: Add support for RZ/G3E SoC clk: renesas: rzv2h: Add MSTOP support dt-bindings: clock: renesas: Document RZ/G3E SoC CPG dt-bindings: soc: renesas: Document RZ/G3E SMARC SoM and Carrier-II EVK dt-bindings: soc: renesas: Document Renesas RZ/G3E SoC variants
2025-01-07thermal: of: fix OF node leak in of_thermal_zone_find()Joe Hattori
of_thermal_zone_find() calls of_parse_phandle_with_args(), but does not release the OF node reference obtained by it. Add a of_node_put() call when the call is successful. Fixes: 3fd6d6e2b4e8 ("thermal/of: Rework the thermal device tree initialization") Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp> Link: https://patch.msgid.link/20241224031809.950461-1-joe@pf.is.s.u-tokyo.ac.jp [ rjw: Changelog edit ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-01-07ACPI: resource: acpi_dev_irq_override(): Check DMI match lastHans de Goede
acpi_dev_irq_override() gets called approx. 30 times during boot (15 legacy IRQs * 2 override_table entries). Of these 30 calls at max 1 will match the non DMI checks done by acpi_dev_irq_override(). The dmi_check_system() check is by far the most expensive check done by acpi_dev_irq_override(), make this call the last check done by acpi_dev_irq_override() so that it will be called at max 1 time instead of 30 times. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://patch.msgid.link/20241228165253.42584-1-hdegoede@redhat.com [ rjw: Subject edit ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-01-07ACPI: resource: Add TongFang GM5HG0A to irq1_edge_low_force_override[]Hans de Goede
The TongFang GM5HG0A is a TongFang barebone design which is sold under various brand names. The ACPI IRQ override for the keyboard IRQ must be used on these AMD Zen laptops in order for the IRQ to work. At least on the SKIKK Vanaheim variant the DMI product- and board-name strings have been replaced by the OEM with "Vanaheim" so checking that board-name contains "GM5HG0A" as is usually done for TongFang barebones quirks does not work. The DMI OEM strings do contain "GM5HG0A". I have looked at the dmidecode for a few other TongFang devices and the TongFang code-name string being in the OEM strings seems to be something which is consistently true. Add a quirk checking one of the DMI_OEM_STRING(s) is "GM5HG0A" in the hope that this will work for other OEM versions of the "GM5HG0A" too. Link: https://www.skikk.eu/en/laptops/vanaheim-15-rtx-4060 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219614 Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patch.msgid.link/20241228164845.42381-1-hdegoede@redhat.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-01-07ACPI: resource: Add Asus Vivobook X1504VAP to irq1_level_low_skip_override[]Hans de Goede
Like the Vivobook X1704VAP the X1504VAP has its keyboard IRQ (1) described as ActiveLow in the DSDT, which the kernel overrides to EdgeHigh which breaks the keyboard. Add the X1504VAP to the irq1_level_low_skip_override[] quirk table to fix this. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219224 Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patch.msgid.link/20241220181352.25974-1-hdegoede@redhat.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-01-07ACPI: tables: Use string choice helpersSunil V L
Use str_enabled_disabled string helpers for better readability and to fix cocci warning. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/r/202501010947.0e3GVHNa-lkp@intel.com/ Reported-by: Julia Lawall <julia.lawall@inria.fr> Closes: https://lore.kernel.org/r/202501010947.0e3GVHNa-lkp@intel.com/ Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Link: https://patch.msgid.link/20250103035122.50315-1-sunilvl@ventanamicro.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-01-07drm/i915/display: convert global state to struct intel_displayJani Nikula
Going forward, struct intel_display is the main display device structure. Convert intel_global_state.[ch] to it. This allows us to make intel_pmdemand.c completely independent of i915_drv.h. Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/2b5e743b285a86a59ee87085727847c758c8d552.1735662324.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-01-07drm/i915/pmdemand: convert to struct intel_displayJani Nikula
Going forward, struct intel_display is the main display device structure. Convert pmdemand to it. Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c1d92e9490013d5aba50fc1d1ebc0ee18e82cf7e.1735662324.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-01-07drm/i915/pmdemand: make struct intel_pmdemand_state opaqueJani Nikula
Only intel_pmdemand.c should look inside the struct intel_pmdemand_state. Indeed, this is already the case. Finish the job and make struct intel_pmdemand_state opaque, preventing any direct pokes at the guts of it in the future. Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/bc5f418785ecd51454761e9a55f21340470a92e3.1735662324.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-01-07drm/i915/pmdemand: convert to_intel_pmdemand_state() to a functionJani Nikula
In preparation for making struct intel_pmdemand_state an opaque type, convert to_intel_pmdemand_state() to a function. Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/10324781f9f7eae5a92506aaa7a40403efd345dd.1735662324.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-01-07drivers/perf: hisi: Set correct IRQ affinity for PMUs with no associationYicong Yang
For PMUs with no association, the hisi_pmu->on_cpu is initialized according to the NUMA locality but use a wrong CPU for the interrupt affinity. The CPU selected from cpumask_local_spread() can be different from the CPU by the cpuhp callback. Fix this by setting the IRQ affinity to hisi_pmu->on_cpu. Fixes: 6cd137088fdf ("drivers/perf: hisi: Refactor the detection of associated CPUs") Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20241223125134.57885-1-yangyicong@huawei.com Signed-off-by: Will Deacon <will@kernel.org>
2025-01-07clk: qcom: gcc-sdm845: Add general purpose clock opsDzmitry Sankouski
SDM845 has "General Purpose" clocks that can be muxed to SoC pins to clock various external devices. Those clocks may be used as e.g. PWM sources for external peripherals. GPCLK can in theory have arbitrary value depending on the use case, so the concept of frequency tables, used in rcg2 clock driver, is not efficient, because it allows only defined frequencies. Introduce clk_rcg2_gp_ops, which automatically calculate clock mnd values for arbitrary clock rate. The calculation done as follows: - upon determine rate request, we calculate m/n/pre_div as follows: - find parent(from our client's assigned-clock-parent) rate - find scaled rates by dividing rates on its greatest common divisor - assign requested scaled rate to m - factorize scaled parent rate, put multipliers to n till max value (determined by mnd_width) - validate calculated values with *_width: - if doesn't fit, delete divisor and multiplier by 2 until fit - return determined rate Limitations: - The driver doesn't select a parent clock (it may be selected by client in device tree with assigned-clocks, assigned-clock-parents properties) Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com> Link: https://lore.kernel.org/r/20241118-starqltechn_integration_upstream-v8-3-ac8e36a3aa65@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-01-07clk: qcom: clk-rcg2: split __clk_rcg2_configure functionDzmitry Sankouski
__clk_rcg2_configure function does 2 things - configures parent and mnd values. In order to be able to add new clock options, we should split. Move __clk_rcg2_configure logic on 2 functions: - __clk_rcg2_configure_parent which configures clock parent - __clk_rcg2_configure_mnd which configures mnd values __clk_rcg2_configure delegates to mentioned functions. Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com> Link: https://lore.kernel.org/r/20241118-starqltechn_integration_upstream-v8-2-ac8e36a3aa65@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-01-07clk: qcom: clk-rcg2: document calc_rate functionDzmitry Sankouski
Update calc_rate docs to reflect, that pre_div is not pure divisor, but a register value, and requires conversion. Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com> Link: https://lore.kernel.org/r/20241118-starqltechn_integration_upstream-v8-1-ac8e36a3aa65@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-01-07hwmon: (pmbus/adm1275) add adm1273 supportJohn Erasmus Mari Geronimo
Add support for adm1273 which is similar to adm1275 and other chips of the series. Signed-off-by: John Erasmus Mari Geronimo <johnerasmusmari.geronimo@analog.com> Link: https://lore.kernel.org/r/20250106131740.305988-3-johnerasmusmari.geronimo@analog.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-01-07igc: return early when failing to read EECD registerEn-Wei Wu
When booting with a dock connected, the igc driver may get stuck for ~40 seconds if PCIe link is lost during initialization. This happens because the driver access device after EECD register reads return all F's, indicating failed reads. Consequently, hw->hw_addr is set to NULL, which impacts subsequent rd32() reads. This leads to the driver hanging in igc_get_hw_semaphore_i225(), as the invalid hw->hw_addr prevents retrieving the expected value. To address this, a validation check and a corresponding return value catch is added for the EECD register read result. If all F's are returned, indicating PCIe link loss, the driver will return -ENXIO immediately. This avoids the 40-second hang and significantly improves boot time when using a dock with an igc NIC. Log before the patch: [ 0.911913] igc 0000:70:00.0: enabling device (0000 -> 0002) [ 0.912386] igc 0000:70:00.0: PTM enabled, 4ns granularity [ 1.571098] igc 0000:70:00.0 (unnamed net_device) (uninitialized): PCIe link lost, device now detached [ 43.449095] igc_get_hw_semaphore_i225: igc 0000:70:00.0 (unnamed net_device) (uninitialized): Driver can't access device - SMBI bit is set. [ 43.449186] igc 0000:70:00.0: probe with driver igc failed with error -13 [ 46.345701] igc 0000:70:00.0: enabling device (0000 -> 0002) [ 46.345777] igc 0000:70:00.0: PTM enabled, 4ns granularity Log after the patch: [ 1.031000] igc 0000:70:00.0: enabling device (0000 -> 0002) [ 1.032097] igc 0000:70:00.0: PTM enabled, 4ns granularity [ 1.642291] igc 0000:70:00.0 (unnamed net_device) (uninitialized): PCIe link lost, device now detached [ 5.480490] igc 0000:70:00.0: enabling device (0000 -> 0002) [ 5.480516] igc 0000:70:00.0: PTM enabled, 4ns granularity Fixes: ab4056126813 ("igc: Add NVM support") Cc: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Signed-off-by: En-Wei Wu <en-wei.wu@canonical.com> Reviewed-by: Vitaly Lifshits <vitaly.lifshits@intel.com> Tested-by: Mor Bar-Gabay <morx.bar.gabay@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-01-07ice: fix incorrect PHY settings for 100 GB/sPrzemyslaw Korba
ptp4l application reports too high offset when ran on E823 device with a 100GB/s link. Those values cannot go under 100ns, like in a working case when using 100 GB/s cable. This is due to incorrect frequency settings on the PHY clocks for 100 GB/s speed. Changes are introduced to align with the internal hardware documentation, and correctly initialize frequency in PHY clocks with the frequency values that are in our HW spec. To reproduce the issue run ptp4l as a Time Receiver on E823 device, and observe the offset, which will never approach values seen in the PTP working case. Reproduction output: ptp4l -i enp137s0f3 -m -2 -s -f /etc/ptp4l_8275.conf ptp4l[5278.775]: master offset 12470 s2 freq +41288 path delay -3002 ptp4l[5278.837]: master offset 10525 s2 freq +39202 path delay -3002 ptp4l[5278.900]: master offset -24840 s2 freq -20130 path delay -3002 ptp4l[5278.963]: master offset 10597 s2 freq +37908 path delay -3002 ptp4l[5279.025]: master offset 8883 s2 freq +36031 path delay -3002 ptp4l[5279.088]: master offset 7267 s2 freq +34151 path delay -3002 ptp4l[5279.150]: master offset 5771 s2 freq +32316 path delay -3002 ptp4l[5279.213]: master offset 4388 s2 freq +30526 path delay -3002 ptp4l[5279.275]: master offset -30434 s2 freq -28485 path delay -3002 ptp4l[5279.338]: master offset -28041 s2 freq -27412 path delay -3002 ptp4l[5279.400]: master offset 7870 s2 freq +31118 path delay -3002 Fixes: 3a7496234d17 ("ice: implement basic E822 PTP support") Reviewed-by: Milena Olech <milena.olech@intel.com> Signed-off-by: Przemyslaw Korba <przemyslaw.korba@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-01-07ice: fix max values for dpll pin phase adjustArkadiusz Kubalewski
Mask admin command returned max phase adjust value for both input and output pins. Only 31 bits are relevant, last released data sheet wrongly points that 32 bits are valid - see [1] 3.2.6.4.1 Get CCU Capabilities Command for reference. Fix of the datasheet itself is in progress. Fix the min/max assignment logic, previously the value was wrongly considered as negative value due to most significant bit being set. Example of previous broken behavior: $ ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/dpll.yaml \ --do pin-get --json '{"id":1}'| grep phase-adjust 'phase-adjust': 0, 'phase-adjust-max': 16723, 'phase-adjust-min': -16723, Correct behavior with the fix: $ ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/dpll.yaml \ --do pin-get --json '{"id":1}'| grep phase-adjust 'phase-adjust': 0, 'phase-adjust-max': 2147466925, 'phase-adjust-min': -2147466925, [1] https://cdrdv2.intel.com/v1/dl/getContent/613875?explicitVersion=true Fixes: 90e1c90750d7 ("ice: dpll: implement phase related callbacks") Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-01-07topology: Keep the cpumask unchanged when printing cpumapLi Huafei
During fuzz testing, the following warning was discovered: different return values (15 and 11) from vsnprintf("%*pbl ", ...) test:keyward is WARNING in kvasprintf WARNING: CPU: 55 PID: 1168477 at lib/kasprintf.c:30 kvasprintf+0x121/0x130 Call Trace: kvasprintf+0x121/0x130 kasprintf+0xa6/0xe0 bitmap_print_to_buf+0x89/0x100 core_siblings_list_read+0x7e/0xb0 kernfs_file_read_iter+0x15b/0x270 new_sync_read+0x153/0x260 vfs_read+0x215/0x290 ksys_read+0xb9/0x160 do_syscall_64+0x56/0x100 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The call trace shows that kvasprintf() reported this warning during the printing of core_siblings_list. kvasprintf() has several steps: (1) First, calculate the length of the resulting formatted string. (2) Allocate a buffer based on the returned length. (3) Then, perform the actual string formatting. (4) Check whether the lengths of the formatted strings returned in steps (1) and (2) are consistent. If the core_cpumask is modified between steps (1) and (3), the lengths obtained in these two steps may not match. Indeed our test includes cpu hotplugging, which should modify core_cpumask while printing. To fix this issue, cache the cpumask into a temporary variable before calling cpumap_print_{list, cpumask}_to_buf(), to keep it unchanged during the printing process. Fixes: bb9ec13d156e ("topology: use bin_attribute to break the size limitation of cpumap ABI") Cc: stable <stable@kernel.org> Signed-off-by: Li Huafei <lihuafei1@huawei.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20241114110141.94725-1-lihuafei1@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-07drm/i915/dp: compute config for 128b/132b SST w/o DSCJani Nikula
Enable basic 128b/132b SST functionality without compression. Reuse intel_dp_mtp_tu_compute_config() to figure out the TU after we've determined we need to use an UHBR rate. It's slightly complicated as the M/N computation is done in different places in MST and SST paths, so we need to avoid trashing the values later for UHBR. If uncompressed UHBR fails, we drop to compressed non-UHBR, which is quite likely to fail as well. We still lack 128b/132b SST+DSC. We need mst_master_transcoder also for 128b/132b SST. Use cpu_transcoder directly. Enhanced framing is "don't care" for 128b/132b link. v2: mst_master_transcoder, enhanced framing (Imre) Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/084e4e05bf25a5dd396dd391014943d42b11c88d.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/ddi: disable trancoder port select for 128b/132b SSTJani Nikula
128b/1232b SST will have mst_master_transcoder set and matching cpu_transcoder. Ensure disable also for 128b/132b SST. Reviewed-by: Imre Deak <imre.deak@intel.com> Co-developed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/eaf705b3490d828ba33e85f40a7794d58de7c5ad.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/ddi: handle 128b/132b SST in intel_ddi_read_func_ctl()Jani Nikula
We'll only ever get here in MST mode from MST stream encoders; the primary encoder's ->get_config() won't be called when we've detected it's MST. v2: Read mst_master_transcoder in 128b/132b SST path (Imre) Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/436854c0bb6ab5c14c3d3837694ea60ac2fbaba2.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/ddi: start distinguishing 128b/132b SST and MST at state readoutJani Nikula
We'll want to distinguish 128b/132b SST and MST modes at state readout. There's a catch, though. From the hardware perspective, 128b/132b SST and MST programming are pretty much the same. And we can't really ask the sink at this point. If we have more than one transcoder in 128b/132b mode associated with the port, we can safely assume it's MST. But for MST with only a single stream enabled, we are pretty much out of luck. Let's fall back to looking at the software state, i.e. intel_dp->is_mst. It should be fine for the state checker, but for hardware takeover at probe, we'll have to trust the GOP has only enabled SST. TODO: Not sure how this *or* our current code handles 128b/132b enabled by GOP. Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/119a773a0d4d74ad204435e462f8d12cb0ea4128.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/ddi: enable ACT handling for 128b/132b SSTJani Nikula
Add ACT handling for 128b/132b SST enable/disable. This is preparation for enabling 128b/132b SST. This path is not reachable yet. v2: - Check for !is_hdmi (Imre) - Add disable sequence (Imre) Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b0226471f9445d988917cee49dbbd93a1493f3c7.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/ddi: initialize 128b/132b SST DP2 VFREQ registersJani Nikula
Write the DP2 specific VFREQ registers. This is preparation for enabling 128b/132b SST. This path is not reachable yet. v2: Check for !is_hdmi (Imre) Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/7d90547e9ce01642b722efca0bf81cadb754e790.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/ddi: write payload for 128b/132b SSTJani Nikula
Write the payload allocation table for 128b/132b SST. Use VCPID 1 and start from slot 0, with dp_m_n.tu slots. This is preparation for enabling 128b/132b SST. This path is not reachable yet. Indeed, we don't yet compute TU for 128b/132b SST. v2: Handle drm_dp_dpcd_write_payload() failures (Imre) v3: Include drm_dp_helper.h (kernel test robot) Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250107095414.1244286-1-jani.nikula@intel.com
2025-01-07drm/i915/ddi: 128b/132b SST also needs DP_TP_CTL_MODE_MSTJani Nikula
It's not very clearly specified, and the hardware bit is ill-named, but 128b/132b SST also needs the MST mode set in the DP_TP_CTL register. This is preparation for enabling 128b/132b SST. This path is not reachable yet. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b29fbba8c979a8bab2bf03088610fe408faaf704.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/ddi: enable 128b/132b TRANS_DDI_FUNC_CTL mode for UHBR SSTJani Nikula
128b/132b SST needs 128b/132b mode enabled in the TRANS_DDI_FUNC_CTL register. This is preparation for enabling 128b/132b SST. This path is not reachable yet. v2: Use the MST path instead of SST to also set transport select (Imre) Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/122ebeadf4bf0870fc26b7d12abdff88f4be8799.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/mst: adapt intel_dp_mtp_tu_compute_config() for 128b/132b SSTJani Nikula
Handle 128b/132b SST in intel_dp_mtp_tu_compute_config(). The remote bandwidth overhead and time slot allocation are only relevant for MST; SST only needs the local bandwidth and a check that 64 slots isn't exceeded. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b59c94b0aac2c073b0306c0a0040b26330f94260.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/mst: split out a helper for figuring out the TUJani Nikula
Extract intel_dp_mtp_tu_compute_config() for figuring out the TU. Move the link configuration and mst state access to the callers. This will be easier to adapt to 128b/132b SST. v2: Don't add SST stuff here yet Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c3ea8370c9bd3cdc579159e68a63f4ed2fadc66a.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/mst: remove crtc_state->pbnJani Nikula
The crtc_state->pbn member is only used as a temporary variable within mst_stream_find_vcpi_slots_for_bpp(). Remove it as unnecessary. Suggested-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/726aaadbd425057dfd854e42417bcf8d69b769d3.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/mst: change return value of mst_stream_find_vcpi_slots_for_bpp()Jani Nikula
The callers of mst_stream_find_vcpi_slots_for_bpp() don't need the returned slots for anything. On the contrary, they need to jump through hoops to just distinguish between success and failure. Just return 0 instead of slots from mst_stream_find_vcpi_slots_for_bpp() for success, and simplify the callers. There's a pointless ret local variable that we can drop in the process. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/7b3671a548c893b1bb62151d41f90bb8ce842ccc.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/mst: drop connector parameter from intel_dp_mst_compute_m_n()Jani Nikula
intel_dp_mst_compute_m_n() doesn't need the connector. Remove the parameter. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/eec2e9a2e2dc3d166ac94bb9de691246a14d3945.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/mst: drop connector parameter from intel_dp_mst_bw_overhead()Jani Nikula
intel_dp_mst_bw_overhead() doesn't need the connector. Remove the parameter. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e1379aca0748e392d8a232135b823deec783e829.1735912293.git.jani.nikula@intel.com
2025-01-07drm/mst: remove mgr parameter and debug logging from drm_dp_get_vc_payload_bw()Jani Nikula
The struct drm_dp_mst_topology_mgr *mgr parameter is only used for debug logging in case the passed in link rate or lane count are zero. There's no further error checking as such, and the function returns 0. There should be no case where the parameters are zero. The returned value is generally used as a divisor, and if we were hitting this, we'd be seeing division by zero. Just remove the debug logging altogether, along with the mgr parameter, so that the function can be used in non-MST contexts without the topology manager. v2: Also remove drm_dp_mst_helper_tests_init as unnecessary (Imre) Cc: Imre Deak <imre.deak@intel.com> Cc: Lyude Paul <lyude@redhat.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Acked-by: Maxime Ripard <mripard@kernel.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/72d77e7a7fe69c784e9df048b7e6f250fd7599e4.1735912293.git.jani.nikula@intel.com
2025-01-07clk: qcom: gcc-x1e80100: Do not turn off usb_2 controller GDSCAbel Vesa
Allowing the usb_2 controller GDSC to be turned off during system suspend renders the controller unable to resume. So use PWRSTS_RET_ON instead in order to make sure this the GDSC doesn't go down. Fixes: 161b7c401f4b ("clk: qcom: Add Global Clock controller (GCC) driver for X1E80100") Cc: stable@vger.kernel.org # 6.8 Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20250107-x1e80100-clk-gcc-fix-usb2-gdsc-pwrsts-v1-1-e15d1a5e7d80@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-01-07Merge drm/drm-next into drm-intel-nextJani Nikula
Backmerge to get the DRM DP payload and ACT helpers to drm-intel-next. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-01-07nvmet: handle rw's limited retry flagGuixin Liu
In some scenarios, some multipath software setup places the REQ_FAILFAST_DEV flag on I/O to prevent retries and immediately switch to other paths for issuing I/O commands. This will reflect on the NVMe read and write commands with the limited retry flag. However, the current NVMe target side does not handle the limited retry flag, and the target's underlying driver still retries the I/O. This will result in the I/O not being quickly switched to other paths, ultimately leading to increased I/O latency. When the nvme target receive an rw command with limited retry flag, handle it in block backend by setting the REQ_FAILFAST_DEV flag to bio. Signed-off-by: Guixin Liu <kanie@linux.alibaba.com> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Keith Busch <kbusch@kernel.org>
2025-01-07clk: renesas: r9a09g057: Add clock and reset entries for GICLad Prabhakar
Add clock and reset entries for GIC. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250102181839.352599-7-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-01-07clk: renesas: r9a09g057: Add reset entry for SYSLad Prabhakar
Add the missing reset entry for the `SYS` module in the clock driver. The corresponding core clock entry for `SYS` is already present. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250102181839.352599-6-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-01-07clk: renesas: r8a779g0: Add VSPX clocksJacopo Mondi
Add the VSPX modules clock for Renesas R-Car V4H (R8A779G0) SoC. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Link: https://lore.kernel.org/20241220-rcar-v4h-vspx-v4-3-7dc1812585ad@ideasonboard.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-01-07clk: renesas: r8a779g0: Add FCPVX clocksJacopo Mondi
Add the FCPVX modules clock for Renesas R-Car V4H (R8A779G0) SoC. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Link: https://lore.kernel.org/20241220-rcar-v4h-vspx-v4-1-7dc1812585ad@ideasonboard.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-01-07clk: renesas: r9a09g047: Add I2C clocks/resetsBiju Das
Add I2C{0..8} clock and reset entries. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20241216120029.143944-3-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-01-07clk: renesas: r9a09g047: Add CA55 core clocksBiju Das
Add CA55 core clocks which are derived from PLLCA55. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/20241213123550.289193-4-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
generated by cgit (git 2.34.1) at 2025-09-16 19:00:00 +0000