summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2025-05-16idpf: add mailbox access to read PTP clock timeMilena Olech5-0/+164
When the access to read PTP clock is specified as mailbox, the driver needs to send virtchnl message to perform PTP actions. Message is sent using idpf_mbq_opc_send_msg_to_peer_drv mailbox opcode, with the parameters received during PTP capabilities negotiation. Add functions to recognize PTP messages, move them to dedicated secondary mailbox, read the PTP clock time and cross timestamp using mailbox messages. Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Milena Olech <milena.olech@intel.com> Tested-by: Samuel Salin <Samuel.salin@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-05-16idpf: negotiate PTP capabilities and get PTP clockMilena Olech7-0/+354
PTP capabilities are negotiated using virtchnl command. Add get capabilities function, direct access to read the PTP clock. Set initial PTP capabilities exposed to the stack. Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Milena Olech <milena.olech@intel.com> Tested-by: Willem de Bruijn <willemb@google.com> Tested-by: Mina Almasry <almasrymina@google.com> Tested-by: Samuel Salin <Samuel.salin@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-05-16idpf: move virtchnl structures to the header fileMilena Olech2-84/+86
Move virtchnl structures to the header file to expose them for the PTP virtchnl file. Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Milena Olech <milena.olech@intel.com> Tested-by: Mina Almasry <almasrymina@google.com> Tested-by: Samuel Salin <Samuel.salin@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-05-16virtchnl: add PTP virtchnl definitionsMilena Olech1-0/+302
PTP capabilities are negotiated using virtchnl commands. There are two available modes of the PTP support: direct and mailbox. When the direct access to PTP resources is negotiated, virtchnl messages returns a set of registers that allow read/write directly. When the mailbox access to PTP resources is negotiated, virtchnl messages are used to access PTP clock and to read the timestamp values. Virtchnl API covers both modes and exposes a set of PTP capabilities. Using virtchnl API, the driver recognizes also HW abilities - maximum adjustment of the clock and the basic increment value. Additionally, API allows to configure the secondary mailbox, dedicated exclusively for PTP purposes. Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Milena Olech <milena.olech@intel.com> Tested-by: Mina Almasry <almasrymina@google.com> Tested-by: Samuel Salin <Samuel.salin@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-05-16idpf: add initial PTP supportMilena Olech7-1/+140
PTP feature is supported if the VIRTCHNL2_CAP_PTP is negotiated during the capabilities recognition. Initial PTP support includes PTP initialization and registration of the clock. Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Reviewed-by: Willem de Bruijn <willemb@google.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Milena Olech <milena.olech@intel.com> Tested-by: Mina Almasry <almasrymina@google.com> Tested-by: Samuel Salin <Samuel.salin@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-05-16idpf: change the method for mailbox workqueue allocationMilena Olech1-3/+2
Since workqueues are created per CPU, the works scheduled to this workqueues are run on the CPU they were assigned. It may result in overloaded CPU that is not able to handle virtchnl messages in relatively short time. Allocating workqueue with WQ_UNBOUND and WQ_HIGHPRI flags allows scheduler to queue virtchl messages on less loaded CPUs, what eliminates delays. Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Milena Olech <milena.olech@intel.com> Tested-by: Samuel Salin <Samuel.salin@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-05-16Merge tag 'sound-6.15-rc7' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "A handful small fixes. The only significant change is the fix for MIDI 2.0 UMP handling in ALSA sequencer, but as MIDI 2.0 stuff is still new and rarely used, the impact should be pretty limited. Other than that, quirks for USB-audio and a few cosmetic fixes and changes in drivers that should be safe to apply" * tag 'sound-6.15-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: usb-audio: Add sample rate quirk for Microdia JP001 USB Camera ALSA: es1968: Add error handling for snd_pcm_hw_constraint_pow2() ALSA: sh: SND_AICA should depend on SH_DMA_API ALSA: usb-audio: Add sample rate quirk for Audioengine D1 ALSA: ump: Fix a typo of snd_ump_stream_msg_device_info ALSA/hda: intel-sdw-acpi: Correct sdw_intel_acpi_scan() function parameter ALSA: seq: Fix delivery of UMP events to group ports
2025-05-16mtd: spinand: esmt: fix id code for F50D1G41LBGeorge Moussalem1-1/+1
Upon detecting the ID for the ESMT F50D1G41LB chip, the fifth byte returned is always 0x00 instead of the expected JEDEC continuation code of 0x7f. This causes detection to fail: [ 0.304399] spi-nand spi0.0: unknown raw ID c8117f7f00 [ 0.508943] spi-nand: probe of spi0.0 failed with error -524 So let's revert back to the 4 byte ID code for this chip specifically. Fixes: 4bd14b2fd8a8 ("mtd: spinand: esmt: Extend IDs to 5 bytes") Signed-off-by: George Moussalem <george.moussalem@outlook.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2025-05-16mtd: rawnand: brcmnand: remove unused parametersÁlvaro Fernández Rojas1-18/+6
last_cmd and last_byte are now unused brcmnand_host members. last_addr is only written and never read so we can remove it too. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: William Zhang <william.zhang@broadcom.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2025-05-16perf/arm-cmn: Initialise cmn->cpu earlierRobin Murphy1-1/+1
For all the complexity of handling affinity for CPU hotplug, what we've apparently managed to overlook is that arm_cmn_init_irqs() has in fact always been setting the *initial* affinity of all IRQs to CPU 0, not the CPU we subsequently choose for event scheduling. Oh dear. Cc: stable@vger.kernel.org Fixes: 0ba64770a2f2 ("perf: Add Arm CMN-600 PMU driver") Signed-off-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Link: https://lore.kernel.org/r/b12fccba6b5b4d2674944f59e4daad91cd63420b.1747069914.git.robin.murphy@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2025-05-16ACPI: thermal: Execute _SCP before reading trip pointsArmin Wolf1-4/+6
As specified in section 11.4.13 of the ACPI specification the operating system is required to evaluate the _ACx and _PSV objects after executing the _SCP control method. Move the execution of the _SCP control method before the invocation of acpi_thermal_get_trip_points() to avoid missing updates to the _ACx and _PSV objects. Fixes: b09872a652d3 ("ACPI: thermal: Fold acpi_thermal_get_info() into its caller") Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20250410165456.4173-3-W_Armin@gmx.de Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-05-16ACPI: OSI: Stop advertising support for "3.0 _SCP Extensions"Armin Wolf1-1/+0
As specified in section 5.7.2 of the ACPI specification the feature group string "3.0 _SCP Extensions" implies that the operating system evaluates the _SCP control method with additional parameters. However the ACPI thermal driver evaluates the _SCP control method without those additional parameters, conflicting with the above feature group string advertised to the firmware thru _OSI. Stop advertising support for this feature string to avoid confusing the ACPI firmware. Fixes: e5f660ebef68 ("ACPI / osi: Collect _OSI handling into one single file") Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20250410165456.4173-2-W_Armin@gmx.de Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-05-16iommu: Clear the freelist after iommu_put_pages_list()Jason Gunthorpe2-1/+5
The commit below reworked how iommu_put_pages_list() worked to not do list_del() on every entry. This was done expecting all the callers to already re-init the list so doing a per-item deletion is not efficient. It was missed that fq_ring_free_locked() re-uses its list after calling iommu_put_pages_list() and so the leftover list reaches free'd struct pages and will crash or WARN/BUG/etc. Reinit the list to empty in fq_ring_free_locked() after calling iommu_put_pages_list(). Audit to see if any other callers of iommu_put_pages_list() need the list to be empty: - iommu_dma_free_fq_single() and iommu_dma_free_fq_percpu() immediately frees the memory - iommu_v1_map_pages(), v1_free_pgtable(), domain_exit(), riscv_iommu_map_pages() uses a stack variable which goes out of scope - intel_iommu_tlb_sync() uses a gather in a iotlb_sync() callback, the caller re-inits the gather Fixes: 13f43d7cf3e0 ("iommu/pages: Formalize the freelist API") Reported-by: Borah, Chaitanya Kumar <chaitanya.kumar.borah@intel.com> Closes: https://lore.kernel.org/r/SJ1PR11MB61292CE72D7BE06B8810021CB997A@SJ1PR11MB6129.namprd11.prod.outlook.com Tested-by: Borah, Chaitanya Kumar <chaitanya.kumar.borah@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/0-v1-7d4dfa6140f7+11f04-iommu_freelist_init_jgg@nvidia.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2025-05-16clocksource/drivers/renesas-ostm: Unconditionally enable reprobe supportLad Prabhakar1-3/+1
Previously, the OSTM driver's platform probe path was only enabled for selected SoCs (e.g., RZ/G2L and RZ/V2H) due to issues on RZ/Ax (ARM32) SoCs, which encountered IRQ conflicts like: /soc/timer@e803b000: used for clock events genirq: Flags mismatch irq 16. 00215201 (timer@e803c000) vs. 00215201 (timer@e803c000) Failed to request irq 16 for /soc/timer@e803c000 renesas_ostm e803c000.timer: probe with driver renesas_ostm failed with error -16 These issues have since been resolved by commit 37385c0772a4 ("clocksource/drivers/renesas-ostm: Avoid reprobe after successful early probe"), which prevents reprobe on successfully initialized early timers. With this fix in place, there is no longer a need to restrict platform probing based on SoC-specific configs. This change unconditionally enables reprobe support for all SoCs, simplifying the logic and avoiding the need to update the configuration for every new Renesas SoC with OSTM. Additionally, the `ostm_of_table` is now marked with `__maybe_unused` to fix a build warning when `CONFIG_OF` is disabled. RZ/A1 and RZ/A2 remain unaffected with this change. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20250515182207.329176-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-05-16dm-mpath: Don't grab work_mutex while probing pathsBenjamin Marzinski1-40/+78
Grabbing the work_mutex keeps probe_active_paths() from running at the same time as multipath_message(). The only messages that could interfere with probing the paths are "disable_group", "enable_group", and "switch_group". These messages could force multipath to pick a new pathgroup while probe_active_paths() was probing the current pathgroup. If the multipath device has a hardware handler, and it switches active pathgroups while there is outstanding IO to a path device, it's possible that IO to the path will fail, even if the path would be usable if it was in the active pathgroup. To avoid this, do not clear the current pathgroup for the *_group messages while probe_active_paths() is running. Instead set a flag, and probe_active_paths() will clear the current pathgroup when it finishes probing the paths. For this to work correctly, multipath needs to check current_pg before next_pg in choose_pgpath(), but before this patch next_pg was only ever set when current_pg was cleared, so this doesn't change the current behavior when paths aren't being probed. Even with this change, it is still possible to switch pathgroups while the probe is running, but only if all the paths have failed, and the probe function will skip them as well in this case. If multiple DM_MPATH_PROBE_PATHS requests are received at once, there is no point in repeatedly issuing test IOs. Instead, the later probes should wait for the current probe to complete. If current pathgroup is still the same as the one that was just checked, the other probes should skip probing and just check the number of valid paths. Finally, probing the paths should quit early if the multipath device is trying to suspend, instead of continuing to issue test IOs, delaying the suspend. While this patch will not change the behavior of existing multipath users which don't use the DM_MPATH_PROBE_PATHS ioctl, when that ioctl is used, the behavior of the "disable_group", "enable_group", and "switch_group" messages can change subtly. When these messages return, the next IO to the multipath device will no longer be guaranteed to choose a new pathgroup. Instead, choosing a new pathgroup could be delayed by an in-progress DM_MPATH_PROBE_PATHS ioctl. The userspace multipath tools make no assumptions about what will happen to IOs after sending these messages, so this change will not effect already released versions of them, even if the DM_MPATH_PROBE_PATHS ioctl is run alongside them. Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2025-05-16spi: spi-qpic-snand: extend FIELD_PREP() macro usageGabor Juhos1-7/+7
Large part of the code uses the FIELD_PREP() macro already to construct values to be written to hardware registers. Change the code to use also the macro for more registers of which the corresponding bitmasks are defined already. This makes the code more readable. It also syncs the affected codes with their counterparts in the 'qcom_nandc' driver, so it makes it easier to spot the differences between the two implementations. No functional changes intended. Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Reviewed-by: Md Sadre Alam <quic_mdalam@quicinc.com> Link: https://patch.msgid.link/20250515-qpic-snand-use-bitmasks-v1-2-11729aeae73b@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-16spi: spi-qpic-snand: use CW_PER_PAGE_MASK bitmaskGabor Juhos1-15/+16
Change the code to use the already defined CW_PER_PAGE_MASK bitmask along with the FIELD_PREP() macro instead of using magic values. This makes the code more readable. It also syncs the affected codes with their counterparts in the 'qcom_nandc' driver, so it makes it easier to spot the differences between the two implementations. No functional changes intended. Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Reviewed-by: Md Sadre Alam <quic_mdalam@quicinc.com> Link: https://patch.msgid.link/20250515-qpic-snand-use-bitmasks-v1-1-11729aeae73b@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-16thermal/drivers/airoha: Fix spelling mistakeChristian Marangi1-5/+5
Fix various spelling mistake in airoha_thermal_setup_monitor() and define. Reported-by: Alok Tiwari <alok.a.tiwari@oracle.com> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20250514213919.2321490-1-ansuelsmth@gmail.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-05-16thermal/drivers/qcom/tsens: Add support for IPQ5018 tsensSricharan Ramabadhran3-0/+20
IPQ5018 has tsens IP V1.0, 5 sensors of which 4 are in use and 1 interrupt. The IP does not have a RPM, hence use init routine for tsens v1.0 without RPM which does not early enable. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Sricharan Ramabadhran <quic_srichara@quicinc.com> Signed-off-by: George Moussalem <george.moussalem@outlook.com> Link: https://lore.kernel.org/r/DS7PR19MB8883BD0E36C08DD1D03CE1CB9DCC2@DS7PR19MB8883.namprd19.prod.outlook.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-05-16thermal/drivers/qcom/tsens: Add support for tsens v1 without RPMGeorge Moussalem3-4/+59
Adding generic support for SoCs with tsens v1.0 IP with no RPM. Due to lack of RPM, tsens has to be reset and enabled in the driver init. SoCs can have support for more sensors than those which will actually be enabled. As such, init will only enable those explicitly added to the hw_ids array. Co-developed-by: Sricharan Ramabadhran <quic_srichara@quicinc.com> Signed-off-by: Sricharan Ramabadhran <quic_srichara@quicinc.com> Signed-off-by: George Moussalem <george.moussalem@outlook.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/DS7PR19MB8883C5D7974C7735E23923769DCC2@DS7PR19MB8883.namprd19.prod.outlook.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-05-16thermal/drivers/qcom/tsens: Update conditions to strictly evaluate for IP v2+George Moussalem1-5/+5
TSENS v2.0+ leverage features not available to prior versions such as updated interrupts init routine, masked interrupts, and watchdog. Currently, the checks in place evaluate whether the IP version is greater than v1 which invalidates when updates to v1 or v1 minor versions are implemented. As such, update the conditional statements to strictly evaluate whether the version is greater than or equal to v2 (inclusive). Signed-off-by: George Moussalem <george.moussalem@outlook.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Amit Kucheria <amitk@kernel.org> Link: https://lore.kernel.org/r/DS7PR19MB8883434CAA053648E22AA8AC9DCC2@DS7PR19MB8883.namprd19.prod.outlook.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-05-16thermal/drivers: Add support for Airoha EN7581 thermal sensorChristian Marangi3-0/+499
Add support for Airoha EN7581 thermal sensor. This provide support for reading the CPU or SoC Package sensor and to setup trip points for hot and critical condition. An interrupt is fired to react on this and doesn't require passive poll to read the temperature. The thermal regs provide a way to read the ADC value from an external register placed in the Chip SCU regs. Monitor will read this value and fire an interrupt if the trip condition configured is reached. The Thermal Trip and Interrupt logic is conceptually similar to Mediatek LVTS Thermal but differ in register mapping and actual function/bug workaround. The implementation only share some register names but from functionality observation it's very different and used only for the basic function of periodically poll the temp and trip the interrupt. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20250511185003.3754495-2-ansuelsmth@gmail.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-05-16thermal/drivers/mediatek/lvts: Remove unused lvts_debugfs_exitArnd Bergmann1-2/+0
When debugfs is disabled, the function has no reference any more: drivers/thermal/mediatek/lvts_thermal.c:266:13: error: 'lvts_debugfs_exit' defined but not used [-Werror=unused-function] 266 | static void lvts_debugfs_exit(struct lvts_domain *lvts_td) { } | ^~~~~~~~~~~~~~~~~ Fixes: ef280c17a840 ("thermal/drivers/mediatek/lvts: Fix debugfs unregister on failure") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20250505052502.1812867-1-arnd@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-05-16thermal/drivers/mediatek/lvts: Fix debugfs unregister on failureAngeloGioacchino Del Regno1-8/+8
When running the probe function for this driver, the function lvts_debugfs_init() gets called in lvts_domain_init() which, in turn, gets called in lvts_probe() before registering threaded interrupt handlers. Even though it's unlikely, the last call may fail and, if it does, there's nothing removing the already created debugfs folder and files. In order to fix that, instead of calling the lvts debugfs cleanup function upon failure, register a devm action that will take care of calling that upon failure or driver removal. Since devm was used, also delete the call to lvts_debugfs_exit() in the lvts_remove() callback, as now that's done automatically. Fixes: f5f633b18234 ("thermal/drivers/mediatek: Add the Low Voltage Thermal Sensor driver") Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20250402083852.20624-1-angelogioacchino.delregno@collabora.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-05-16thermal/drivers/amlogic: Rename Uptat to uptat to follow kernel coding styleEnrique Isidoro Vazquez Ramos1-8/+8
The variable Uptat uses CamelCase, which violates the kernel's coding style that mandates snake_case for variable names. This is a purely cosmetic change with no functional impact. Compilation tested with: - checkpatch.pl --strict passed (no new warnings/errors). Signed-off-by: Enrique Isidoro Vazquez Ramos <kike.correo99.f@gmail.com> Link: https://lore.kernel.org/r/Z-MEZNMLUmj75uxN@debian.debian Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-05-16thermal/drivers/bcm2835: Use %pC instead of %pCnLuca Ceresoli1-1/+1
The %pC and %pCn printk format specifiers produce the exact same string. In preparation for removing %pCn, use %pC. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://lore.kernel.org/r/20250311-vsprintf-pcn-v2-1-0af40fc7dee4@bootlin.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-05-16thermal/drivers/hisi: Do not enable by default during compile testingKrzysztof Kozlowski1-1/+1
Enabling the compile test should not cause automatic enabling of all drivers, but only allow to choose to compile them. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://lore.kernel.org/r/20250417074638.81329-1-krzysztof.kozlowski@linaro.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-05-16clocksource/drivers: Add EcoNet Timer HPT driverCaleb James DeLisle3-0/+225
Introduce a clocksource driver for the so-called high-precision timer (HPT) in the EcoNet EN751221 and EN751627 MIPS SoCs. It's a 32 bit upward-counting one-shot timer which relies on the crystal so it is unaffected by CPU power mode. On MIPS 34K devices (single core) there is one timer, and on 1004K devices (dual core) there are two. Each timer has two sets of count/compare registers so that there is one for each of the VPEs on the core. Because each core has 2 VPEs, register selection takes the CPU number / 2 for the timer corrisponding to the core, then CPU number % 2 for the register corrisponding to the VPE. These timers use a percpu-devid IRQ to route interrupts to the VPE which set the event. Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr> Link: https://lore.kernel.org/r/20250507134500.390547-3-cjd@cjdns.fr Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-05-16clocksource/drivers/timer-tegra186: Remove unused bitsrobelin1-9/+0
The intention to keep the unsed if(0) block is gone now. Remove them for clean codes. Signed-off-by: robelin <robelin@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20250507044311.3751033-4-robelin@nvidia.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-05-16clocksource/drivers/timer-tegra186: Fix watchdog self-pingingPohsun Su1-27/+0
This change removes watchdog self-pinging behavior. The timer irq handler is triggered due to the 1st expiration, the handler disables and enables watchdog but also implicitly clears the expiration count so the count can only be 0 or 1. Since this watchdog supports opened, configured, or pinged by systemd, We remove this behavior or the watchdog may not bark when systemd crashes since the 5th expiration never comes. Signed-off-by: Pohsun Su <pohsuns@nvidia.com> Signed-off-by: Robert Lin <robelin@nvidia.com> Link: https://lore.kernel.org/r/20250507044311.3751033-3-robelin@nvidia.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-05-16clocksource/drivers/timer-tegra186: Add WDIOC_GETTIMELEFT supportPohsun Su1-1/+63
This change adds support for WDIOC_GETTIMELEFT so userspace programs can get the number of seconds before system reset by the watchdog timer via ioctl. Signed-off-by: Pohsun Su <pohsuns@nvidia.com> Signed-off-by: Robert Lin <robelin@nvidia.com> Link: https://lore.kernel.org/r/20250507044311.3751033-2-robelin@nvidia.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-05-16clocksource/drivers/atmel_tcb: Fix kconfig dependencyArnd Bergmann1-2/+2
Build-testing this driver on arm without CONFIG_OF produces a warning: drivers/clocksource/timer-atmel-tcb.c:368:34: error: 'atmel_tcb_of_match' defined but not used [-Werror=unused-const-variable=] 368 | static const struct of_device_id atmel_tcb_of_match[] = { | ^~~~~~~~~~~~~~~~~~ Change the dependency to require CONFIG_OF for build testing to avoid the warning. Testing remains possible on all architectures as CONFIG_OF is user-selectable. Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Claudiu Beznea <claudiu.beznea@tuxon.dev> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20250409155313.1096915-1-arnd@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-05-16clocksource/drivers/nxp-timer: Add the System Timer Module for the s32gx ↵Daniel Lezcano3-0/+504
platforms STM supports commonly required system and application software timing functions. STM includes a 32-bit count-up timer and four 32-bit compare channels with a separate interrupt source for each channel. The timer is driven by the STM module clock divided by an 8-bit prescale value (1 to 256). STM has the following features: • One 32-bit count-up timer with an 8-bit prescaler • Four 32-bit compare channels • An independent interrupt source for each channel • Ability to stop the timer in Debug mode The s32g platform is declined into two versions, the s32g2 and the s32g3. The former has a STM block with 8 timers and the latter has 12 timers. The platform is designed to have one usable STM instance per core on the system which is composed of 3 x Cortex-M3 + 4 Cortex-A53 for the s32g2 and 3 x Cortex-M3 + 8 Cortex-A53 for the s32g3. There is a special STM instance called STM_TS which is dedicated to the timestamp. The 7th STM instance STM_07 is directly tied to the STM_TS which means it is not usable as a clockevent. The driver instantiate each STM described in the device tree as a clocksource and a clockevent conforming to the reference manual even if the Linux system does not use all of the clocksource. Each clockevent will have a cpumask set for a specific CPU. Given the counter is shared between the clocksource and the clockevent, the STM module can not be disabled by one or another so the refcounting mechanism is used to stop the counter when it reaches zero and to start it when it is one. The suspend and resume relies on the refcount to stop the module. As the device tree will have multiple STM entries, the driver can be probed in parallel with the async option but it is not enabled yet. However, the driver code takes care of preventing a race by putting a lock to protect the number of STM instances global variable which means it is ready to support the option when enough testing will be done with the underlying time framework. Cc: Ghennadi Procopciuc <ghennadi.procopciuc@oss.nxp.com> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Cc: Thomas Fossati <thomas.fossati@linaro.org> Suggested-by: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com> Link: https://lore.kernel.org/r/20250417151623.121109-3-daniel.lezcano@linaro.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-05-16Merge tag 'rtw-next-2025-05-16' of https://github.com/pkshih/rtwJohannes Berg85-682/+3740
Ping-Ke Shih says: ================== rtw-next patches for v6.16 Some fixes and refinements across drivers, and regular development of MLO and STA + P2P concurrency. Major changes are listed below. rtw88: * improve throughput for RTL8814AU rtw89: * support MLO * improve user experience for STA + P2P concurrency * dynamic antenna gain (DAG) with different power by antenna * load SAR tables from ACPI ================== Link: https://patch.msgid.link/17e74675-70cc-43d7-a797-afb937030d34@RTEXMBS04.realtek.com.tw/ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-05-16iommu/vt-d: Change dmar_ats_supported() to return booleanWei Wang1-9/+10
According to "Function return values and names" in coding-style.rst, the dmar_ats_supported() function should return a boolean instead of an integer. Also, rename "ret" to "supported" to be more straightforward. Signed-off-by: Wei Wang <wei.w.wang@intel.com> Reviewed-by: Yi Liu <yi.l.liu@intel.com> Link: https://lore.kernel.org/r/20250509140021.4029303-3-wei.w.wang@intel.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2025-05-16iommu/vt-d: Eliminate pci_physfn() in dmar_find_matched_satc_unit()Wei Wang1-1/+0
The function dmar_find_matched_satc_unit() contains a duplicate call to pci_physfn(). This call is unnecessary as pci_physfn() has already been invoked by the caller. Removing the redundant call simplifies the code and improves efficiency a bit. Signed-off-by: Wei Wang <wei.w.wang@intel.com> Link: https://lore.kernel.org/r/20250509140021.4029303-2-wei.w.wang@intel.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2025-05-16iommu/vt-d: Replace spin_lock with mutex to protect domain idaLu Baolu3-8/+7
The domain ID allocator is currently protected by a spin_lock. However, ida_alloc_range can potentially block if it needs to allocate memory to grow its internal structures. Replace the spin_lock with a mutex which allows sleep on block. Thus, the memory allocation flags can be updated from GFP_ATOMIC to GFP_KERNEL to allow blocking memory allocations if necessary. Introduce a new mutex, did_lock, specifically for protecting the domain ida. The existing spinlock will remain for protecting other intel_iommu fields. Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20250430021135.2370244-3-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2025-05-16iommu/vt-d: Use ida to manage domain idLu Baolu3-68/+34
Switch the intel iommu driver to use the ida mechanism for managing domain IDs, replacing the previous fixed-size bitmap. The previous approach allocated a bitmap large enough to cover the maximum number of domain IDs supported by the hardware, regardless of the actual number of domains in use. This led to unnecessary memory consumption, especially on systems supporting a large number of iommu units but only utilizing a small number of domain IDs. The ida allocator dynamically manages the allocation and freeing of integer IDs, only consuming memory for the IDs that are currently in use. This significantly optimizes memory usage compared to the fixed-size bitmap. Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20250430021135.2370244-2-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2025-05-16iommu/vt-d: Restore WO permissions on second-level paging entriesJason Gunthorpe1-2/+1
VT-D HW can do WO permissions on the second-stage but not the first-stage page table formats. The commit eea53c581688 ("iommu/vt-d: Remove WO permissions on second-level paging entries") wanted to make this uniform for VT-D by disabling the support for WO permissions in the second-stage. This isn't consistent with how other drivers are working. Instead if the underlying HW can support WO, it should. For instance AMD already supports WO on its second stage (v1) format and not its first (v2). If WO support needs to be discoverable it should be done through an iommu_domain capability flag. Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/0-v1-c26553717e90+65f-iommu_vtd_ss_wo_jgg@nvidia.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2025-05-16iommu/amd: Allow matching ACPI HID devices without matching UIDsMario Limonciello1-5/+28
A BIOS upgrade has changed the IVRS DTE UID for a device that no longer matches the UID in the SSDT. In this case there is only one ACPI device on the system with that _HID but the _UID mismatch. IVRS: ``` Subtable Type : F0 [Device Entry: ACPI HID Named Device] Device ID : 0060 Data Setting (decoded below) : 40 INITPass : 0 EIntPass : 0 NMIPass : 0 Reserved : 0 System MGMT : 0 LINT0 Pass : 1 LINT1 Pass : 0 ACPI HID : "MSFT0201" ACPI CID : 0000000000000000 UID Format : 02 UID Length : 09 UID : "\_SB.MHSP" ``` SSDT: ``` Device (MHSP) { Name (_ADR, Zero) // _ADR: Address Name (_HID, "MSFT0201") // _HID: Hardware ID Name (_UID, One) // _UID: Unique ID ``` To handle this case; while enumerating ACPI devices in get_acpihid_device_id() count the number of matching ACPI devices with a matching _HID. If there is exactly one _HID match then accept it even if the UID doesn't match. Other operating systems allow this, but the current IVRS spec leaves some ambiguity whether to allow or disallow it. This should be clarified in future revisions of the spec. Output 'Firmware Bug' for this case to encourage it to be solved in the BIOS. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Link: https://lore.kernel.org/r/20250512173129.1274275-1-superm1@kernel.org Signed-off-by: Joerg Roedel <jroedel@suse.de>
2025-05-16iommu: make inclusion of arm/arm-smmu-v3 directory conditionalRolf Eike Beer2-2/+3
Nothing in there is active if CONFIG_ARM_SMMU_V3 is not enabled, so the whole directory can depend on that switch as well. Fixes: e86d1aa8b60f ("iommu/arm-smmu: Move Arm SMMU drivers into their own subdirectory") Signed-off-by: Rolf Eike Beer <eb@emlix.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/2434059.NG923GbCHz@devpool92.emlix.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2025-05-16iommu: make inclusion of riscv directory conditionalRolf Eike Beer2-2/+3
Nothing in there is active if CONFIG_RISCV_IOMMU is not enabled, so the whole directory can depend on that switch as well. Fixes: 5c0ebbd3c6c6 ("iommu/riscv: Add RISC-V IOMMU platform device driver") Signed-off-by: Rolf Eike Beer <eb@emlix.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/2235451.Icojqenx9y@devpool92.emlix.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2025-05-16iommu: make inclusion of amd directory conditionalRolf Eike Beer2-2/+3
Nothing in there is active if CONFIG_AMD_IOMMU is not enabled, so the whole directory can depend on that switch as well. Fixes: cbe94c6e1a7d ("iommu/amd: Move Kconfig and Makefile bits down into amd directory") Signed-off-by: Rolf Eike Beer <eb@emlix.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/1894970.atdPhlSkOF@devpool92.emlix.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2025-05-16iommu: make inclusion of intel directory conditionalRolf Eike Beer2-6/+4
Nothing in there is active if CONFIG_INTEL_IOMMU is not enabled, so the whole directory can depend on that switch as well. Fixes: ab65ba57e3ac ("iommu/vt-d: Move Kconfig and Makefile bits down into intel directory") Signed-off-by: Rolf Eike Beer <eb@emlix.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/3818749.MHq7AAxBmi@devpool92.emlix.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2025-05-16iommu: remove duplicate selection of DMAR_TABLERolf Eike Beer1-1/+0
This is already done in intel/Kconfig. Fixes: 70bad345e622 ("iommu: Fix compilation without CONFIG_IOMMU_INTEL") Signed-off-by: Rolf Eike Beer <eb@emlix.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/2232605.Mh6RI2rZIc@devpool92.emlix.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2025-05-16iommu/fsl_pamu: remove trailing space after \nColin Ian King1-1/+1
There is an extraenous space after \n in a pr_debug message. Remove it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20250430151853.923614-1-colin.i.king@gmail.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2025-05-16Merge tag 'drm-xe-fixes-2025-05-15-1' of ↵Dave Airlie22-73/+358
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Core Changes: - Add timeslicing and allocation restriction for SVM Driver Changes: - Fix shrinker debugfs name - Add HW workaround to Xe2 - Fix SVM when mixing GPU and CPU atomics - Fix per client engine utilization due to active contexts not saving timestamp with lite restore enabled. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/qil4scyn6ucnt43u5ju64bi7r7n5r36k4pz5rsh2maz7isle6g@lac3jpsjrrvs
2025-05-16net: stmmac: convert to ndo_hwtstamp_get() and ndo_hwtstamp_set()Vladimir Oltean2-44/+42
New timestamping API was introduced in commit 66f7223039c0 ("net: add NDOs for configuring hardware timestamping") from kernel v6.6. It is time to convert the stmmac driver to the new API, so that timestamping configuration can be removed from the ndo_eth_ioctl() path completely. The existing timestamping calls are guarded by netif_running(). For stmmac_hwtstamp_get() that is probably unnecessary, since no hardware access is performed. But for stmmac_hwtstamp_set() I've preserved it, since at least some IPs probably need pm_runtime_resume_and_get() to access registers, which is otherwise called by __stmmac_open(). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20250514143249.1808377-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-16wifi: rtw89: fix firmware scan delay unit for WiFi 6 chipsChin-Yen Lee1-1/+1
The scan delay unit of firmware command for WiFi 6 chips is microsecond, but is wrong set now and lead to abnormal work for net-detect. Correct the unit to avoid the error. Fixes: e99dd80c8a18 ("wifi: rtw89: wow: add delay option for net-detect") Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250513125203.6858-1-pkshih@realtek.com
2025-05-16wifi: rtw88: fix the 'para' buffer size to avoid reading out of boundsAlexey Kodanev1-1/+1
Set the size to 6 instead of 2, since 'para' array is passed to 'rtw_fw_bt_wifi_control(rtwdev, para[0], &para[1])', which reads 5 bytes: void rtw_fw_bt_wifi_control(struct rtw_dev *rtwdev, u8 op_code, u8 *data) { ... SET_BT_WIFI_CONTROL_DATA1(h2c_pkt, *data); SET_BT_WIFI_CONTROL_DATA2(h2c_pkt, *(data + 1)); ... SET_BT_WIFI_CONTROL_DATA5(h2c_pkt, *(data + 4)); Detected using the static analysis tool - Svace. Fixes: 4136214f7c46 ("rtw88: add BT co-existence support") Signed-off-by: Alexey Kodanev <aleksei.kodanev@bell-sw.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250513121304.124141-1-aleksei.kodanev@bell-sw.com