| Age | Commit message (Collapse) | Author |
|---|
|
Locking is disabled in the regmap config as this driver uses its own
lock. This means that all calls to regmap functions (read or write) must
hold the i2c_lock. The function pca953x_irq_bus_sync_unlock() did not do
this, and it was therefore possible that multiple threads could cause an
incorrect register to be read/written.
A previous patch partly fixed this, but only protected the write to the
interrupt mask register, and not the read from the direction register.
Fixes: bfc6444b57dc ("gpio: pca953x: fix pca953x_irq_bus_sync_unlock race")
Cc: stable@vger.kernel.org
Signed-off-by: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz>
Link: https://patch.msgid.link/20260709045116.2304246-1-mark.tomlinson@alliedtelesis.co.nz
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
|
|
__destroy_component_cfg() adds each RIS mbwu_state object to the MPAM
garbage list when destroying component configuration.
However, mbwu_state is allocated per RIS and only for RISes with MBWU
monitors. A component can therefore have comp->cfg allocated while some
RISes still have ris->mbwu_state set to NULL.
Passing a NULL mbwu_state to add_to_garbage() dereferences the NULL
pointer inside the macro.
Skip RISes that do not have an mbwu_state object before adding them to
the garbage list.
Fixes: 41e8a14950e1 ("arm_mpam: Track bandwidth counter state for power management")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Reviewed-by: Ben Horgan <ben.horgan@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
|
|
MPAMCFG_MBW_PBM is written from cfg if cfg has the MBW partition feature.
It is reset when cfg does not have the MBW partition feature.
But the register handling is reversed. This may cause an incorrect
register setting. For example, during an MPAM reset, reset_cfg is
empty (no MBW partition feature set), and cfg->mbw_pbm is 0. Instead of
resetting MPAMCFG_MBW_PBM to all 1's, the current logic will set it to
cfg->mbw_pbm, which is 0.
Fix the issue by swapping the if/else branches.
Fixes: a1cb6577f575 ("arm_mpam: Reset when feature configuration bit unset")
Reported-by: Matt Ochs <mochs@nvidia.com>
Signed-off-by: Fenghua Yu <fenghuay@nvidia.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Ben Horgan <ben.horgan@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
|
|
GuC exec queue destruction can run asynchronously. If the final device
put happens from a destroy worker, drmm cleanup can end up draining
the same workqueue and deadlock.
Hold a drm_device reference for the queue lifetime and drop it after
queue teardown completes. This keeps drmm cleanup from running while
async destroy work is still pending.
Move GuC destroy work to a module-lifetime Xe workqueue and flush it
on PCI remove so hot-unbind/rebind still waits for pending destroy work.
With queue-held device refs, guc_submit_sw_fini() cannot run with live
GuC IDs. Replace the fini wait with an assertion and remove the unused
fini_wq.
v2:
- Rebase
v3:
- Switch to queue-lifetime drm_dev_get()/drm_dev_put() model. (Matt)
- Queue async teardown on system_dfl_wq instead of xe->destroy_wq. (Matt)
- Drop separate deferred drm_dev_put worker.
- Remove stale drain_workqueue(xe->destroy_wq) from guc_submit_sw_fini().
v4:
- Replace the guc_submit_sw_fini() wait with an assertion and remove
the now-unused fini_wq. (sashiko)
v5:
- Move destroy work to a module-lifetime Xe workqueue instead of
system_dfl_wq. (Matt)
- Flush the module-lifetime destroy workqueue during PCI remove to
preserve the old device-remove wait semantics.
v6:
- Keep SVM pagemap destroy work on the per-device destroy_wq to avoid
letting it outlive the xe_device/drm_device. (Sashiko)
- Use WQ_MEM_RECLAIM for xe->destroy_wq because SVM pagemap destroy work
can be queued from the reclaim path.
v7:
- Drop the per-device xe->destroy_wq and use the module-level destroy WQ
for SVM pagemap destroy as well. (Matt)
- Rename xe_exec_queue_destroy_wq_*() helpers to xe_destroy_wq_*()
helpers because the WQ is no longer exec-queue specific. (Matt)
v8:
- Rebase.
v9:
- Keep SVM pagemap destroy work on the per-device WQ_MEM_RECLAIM
destroy_wq because it can be queued from reclaim and embeds
the dev_pagemap used by devres teardown. (Sashiko)
- Keep the module-level destroy WQ GuC-only and drop WQ_MEM_RECLAIM
from it.
- Update the module-WQ kdoc to document the GuC/SVM split.
v10:
- Keep xe->destroy_wq per-cpu while adding WQ_MEM_RECLAIM to fix the
workqueue allocation warning.
v11:
- Drop the SVM pagemap destroy comment as it was revision-specific.
(Thomas)
v12:
- Rebase.
Fixes: 2d2be279f1ca ("drm/xe: fix UAF around queue destruction")
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Cc: Tejas Upadhyay <tejas.upadhyay@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Arvind Yadav <arvind.yadav@intel.com>
Link: https://patch.msgid.link/20260716062624.211396-1-arvind.yadav@intel.com
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
|
|
Priority partitioning is not supported other than to set the per-PARTID
defaults in MPAMCFG_PRI, INTPRI and DSPRI, to the highest priority. When 0
is the lowest priority, all ones is the highest priority. However, these
values are calculated with an extra higher bit set.
Luckily, there is still no chance of setting functional bits incorrectly.
When the priority widths are maximal, this is ensured as the fields have
width 16 and a u16 holds the value for each field. When the widths are
smaller, the higher order bits beyond the advertised widths,
MPAMF_PRI_IDR.DSPRI_WD and MPAMF_PRI_IDR.INTPRI_WD, in the priority fields
INTPRI and DSPRI are not used to calculate the priority. It is not
specified whether these higher order bits are RAZ/WI or Res0 and so it is
desirable not to set them to avoid the chance of misleading reads.
Correct the priority reset values.
Fixes: 880df85d8673 ("arm_mpam: Probe and reset the rest of the features")
Signed-off-by: Ben Horgan <ben.horgan@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
|
|
As pointed out by sashiko bot in [0], recent proposed changes to
dma_max_mapping_size() may affect the driver.
While the issue reported may be a false positive, Robin pointed out some
other DMA-related issues in the driver which are addressed here:
- the DMA max mapping size is irrelevant for the programmed IO mode of
operation
- we should not call dma_max_mapping_size() on the MMC host platform
device, but rather the DMA engine device
In addition, it's better to use the device returned from
dmaengine_get_dma_device() for dma_umap_sg() and dma_unmap_sg(), and not
reference the DMA channel device directly.
[0] https://lore.kernel.org/linux-scsi/d82926fe-4557-401d-ae58-4302fef5657c@oracle.com/#t
Signed-off-by: John Garry <john.g.garry@oracle.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
To make the spi driver operable with SWAP_IO_SPACE config
enabled, replace all instances of readl/writel with their
__raw variants. Otherwise readl/writel will do a byte swap
which this driver does not intend to do.
Tested-by: Carlo Szelinsky <github@szelinsky.de>
Signed-off-by: Rustam Adilov <adilov@disroot.org>
Link: https://patch.msgid.link/20260711083411.45836-1-adilov@disroot.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The mcp16502_probe() currently uses dev_err() for logging errors.
However, functions like devm_regmap_init_i2c, devm_gpiod_get_optional
and devm_regulator_register can return -EPROBE_DEFER. Using dev_err()
in these situations can cause unnecessary error spam in dmesg.
As a result, convert to dev_err_probe(). It also simplifies the print
and return operations into single statement. The 'ret' variable is no
longer required and has been removed.
Originally detected by Coccinelle with this warning "Consider using
%pe to print PTR_ERR()"
Compile-tested only.
Signed-off-by: Ninad Naik <ninadnaik07@gmail.com>
Link: https://patch.msgid.link/20260714192228.1639768-1-ninadnaik07@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Refactor the rohm-bd7182x7 MFD driver to use software nodes for
instantiating the gpio-keys child device, replacing the old
platform_data mechanism.
The power key's properties are now defined using software nodes and
property entries. The IRQ is passed as a resource attached to the
platform device.
This will allow dropping support for using platform data for configuring
gpio-keys in the future.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://patch.msgid.link/20260611-rohm-software-nodes-v5-2-0244664a3b65@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Refactor the rohm-bd71828 MFD driver to use software nodes for
instantiating the gpio-keys child device, replacing the old
platform_data mechanism.
The power key's properties are now defined using software nodes and
property entries. The IRQ is passed as a resource attached to the
platform device.
This will allow dropping support for using platform data for configuring
gpio-keys in the future.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://patch.msgid.link/20260611-rohm-software-nodes-v5-1-0244664a3b65@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
This adds:
- misc_parameters_6, containing a few fields for matching PSP headers.
As this is the last misc_parameters field defined, retire the old
optimization added in commit [1] to not touch the reserved part.
- PSP decap action.
- PSP SPI header field pointer.
[1] commit 667cb65ae5ad ("net/mlx5: Don't store reserved part in FTEs
and FGs")
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260713084320.1015240-3-tariqt@nvidia.com
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
esw_manager_vport_number{,_valid} and merged_eswitch were read through a
separate mlx5_ifc_esw_cap_bits struct, but these bits live in the
e-switch capability that mlx5_ifc_e_switch_cap_bits already describes
(both overlay the same QUERY_HCA_CAP op_mod 0x9 output).
Add esw_manager_vport_number{,_valid} to mlx5_ifc_e_switch_cap_bits at
the same offsets, drop the redundant mlx5_ifc_esw_cap_bits and its
hca_cap_union member, and switch the only user (hws/cmd.c) to
capability.e_switch_cap.
Signed-off-by: Shay Drory <shayd@nvidia.com>
Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260713084320.1015240-2-tariqt@nvidia.com
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
Remove unneeded 'ret' variables in ssd130x_fb_blit_rect(),
ssd132x_fb_blit_rect(), and ssd133x_fb_blit_rect() functions.
These functions initialize ret to 0 and return it unchanged,
so return 0 directly instead.
Fixes: 2258f03989af ("drm/solomon: Move calls to drm_gem_fb_end_cpu*()")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202606301409.I0ctsf41-lkp@intel.com/
Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20260709-fix-ssd130x-v1-1-1272cb3dc85e@gmail.com
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
|
|
The Kconfig entry for ARCH_R8A78000 contains both "default y if
ARCH_RENESAS" and "default ARCH_RENESAS", which are sort-of duplicates.
Drop the latter, to restore consistency with the other ARM64 entries.
Fixes: 5284d0b09d1bdc69 ("soc: renesas: Identify R-Car X5H")
Reported-by: Marek Vasut <marek.vasut@mailbox.org>
Closes: https://lore.kernel.org/a069d50d-030d-4189-ae9d-37f989829da4@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Duy Nguyen <duy.nguyen.rh@renesas.com>
Link: https://patch.msgid.link/64de6e95719a6dec7412cf7e917a42749e738b99.1783593775.git.geert+renesas@glider.be
|
|
Following the sale of PEAK-System France by HMS-Networks, this update is
intended to change all my @hms-networks.com email addresses to my new
@peak-system.fr address.
Signed-off-by: Stéphane Grosjean <s.grosjean@peak-system.fr>
Link: https://patch.msgid.link/20260410124251.40506-1-stephane.grosjean@free.fr
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
Use the correct struct names (i.e., correct typos).
Use the struct keyword for structs as required.
Prevents 5 warnings:
Warning: drivers/soundwire/bus.h:86 expecting prototype for struct
sdw_btp_section. Prototype was for struct sdw_bpt_section instead
Warning: drivers/soundwire/bus.h:100 expecting prototype for struct
sdw_btp_msg. Prototype was for struct sdw_bpt_msg instead
Warning: drivers/soundwire/bus.h:125 cannot understand function prototype:
'struct sdw_port_runtime'
Warning: drivers/soundwire/bus.h:144 cannot understand function prototype:
'struct sdw_slave_runtime'
Warning: drivers/soundwire/bus.h:165 cannot understand function prototype:
'struct sdw_master_runtime'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://patch.msgid.link/20260715030719.757781-1-rdunlap@infradead.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The scheduler keeps a pointer to the timeline name, but q->name
is freed with the exec queue while scheduler fences can still
reference it.
Store the name in struct xe_guc_exec_queue so it shares
the scheduler's RCU-deferred lifetime.
Fixes: 6bd90e700b42 ("drm/xe: Make dma-fences compliant with the safe access rules")
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Arvind Yadav <arvind.yadav@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Acked-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260714064402.2457257-1-arvind.yadav@intel.com
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
|
|
For a multi-queue group secondary, guc_exec_queue_suspend_wait() (and its
blocking variant) only waited on the primary's suspend, on the assumption
that the secondary's suspend is synchronous. It is not: the secondary's
suspend rides the sched-message worker (short-circuited, no GuC round-trip)
and completes asynchronously. When the primary was already suspended the
forward is a refcount-only transition that queues no new primary SUSPEND
and leaves the primary's suspend_pending clear, so the wait returned
immediately while the secondary's own suspend was still in flight. A
subsequent resume() then tripped the secondary's !suspend_pending assert.
Wait for the secondary's own suspend to complete before waiting on the
primary. On a timeout, ban the queue (which tears down the group) rather
than leave it with suspend_pending set - otherwise the preempt-fence and
hw-engine-group resume paths would resume it and hit the assert.
Factor the per-queue wait into guc_exec_queue_wait_suspend_done() and share
the orchestration between suspend_wait() and suspend_wait_blocking() via
guc_exec_queue_suspend_wait_common().
Assisted-by: Github-Copilot:Claude-opus-4.8
Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260716045815.2315470-2-niranjana.vishwanathapura@intel.com
|
|
The fault injection code was scattered: the GT reset
hook lived in xe_gt.h as an inline function with its own global
variable, the CSC hook had a separate global in xe_hw_error.c with
an extern declaration, and each was individually registered in
xe_debugfs.c. Adding a new error type meant editing many files and
copy-pasting the same boilerplate.
Debugfs interface (under /sys/kernel/debug/dri/0/):
- fail_gt_reset - GT reset failure
- inject_csc_hw_error - CSC firmware error
Signed-off-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
Reviewed-by: Riana Tauro <riana.tauro@intel.com>
Link: https://patch.msgid.link/20260715085159.424040-2-mallesh.koujalagi@intel.com
Signed-off-by: Riana Tauro <riana.tauro@intel.com>
|
|
Switch ipa client driver over to generic PAS TZ APIs. Generic PAS TZ
service allows to support multiple TZ implementation backends like QTEE
based SCM PAS service, OP-TEE based PAS service and any further future TZ
backend service.
Reviewed-by: Alex Elder <elder@riscstar.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Acked-by: Alex Elder <elder@riscstar.com>
Link: https://lore.kernel.org/r/20260702115835.167602-12-sumit.garg@kernel.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Enable runtime PM for the controller so the common GCC probe path resumes
the attached domain while registering clocks, resets and GDSCs.
This lets GDSC consumers propagate their votes through the GCC provider to
the CX parent domain.
Fixes: efe504300a17 ("clk: qcom: gcc: Add support for Global Clock Controller")
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260715-glymur-fix-gcc-cx-scaling-v3-2-72eb5adad156@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Commit 833740a2333c ("platform/chrome: sensorhub: Bound the EC-reported
sensor number") evaluated the `sensor_num` against the bounds limit even
for timestamp events. A timestamp event typically has a `sensor_num` of
0xff [1], causing the driver to flag it as invalid and skip to the next
event.
As a result, we'd see a flooding of "Invalid sensor number 255 from EC"
warning logs and these timestamp events were being dropped.
Move the bounds-check into cros_ec_sensor_ring_process_event() and
evaluate it only after standalone timestamp events have already been
processed and returned early.
[1] https://crrev.com/219ca6ef82ba266da788b673ee4ad50bd3ea1285/common/motion_sense_fifo.c#427
Fixes: 833740a2333c ("platform/chrome: sensorhub: Bound the EC-reported sensor number")
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20260715024454.4127571-1-tzungbi@kernel.org
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
The `Fsp` instance was only used in the Hopper+ boot path, and
consequently built locally (and immediately dropped) in it.
This worked well as a temporary measure, but the FSP is a GPU
sub-device, so its lifetime should match the GPU rather than a single
boot invocation.
It will also be needed in other parts of the driver, for instance vGPU.
Thus, create the `Fsp` instance in the `Gpu` constructor and store it
there, passing it to the GSP boot as a mutable reference using
`GspBootContext`. This makes the `Fsp` available even after the GSP is
booted.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-13-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
`Falcon` instances retain references tied to the lifetime of the bound
GPU. `GspBootContext` currently uses that same lifetime for its own
borrows of the `Falcon` instances and other references.
But these lifetimes are independent: the references captured by a
`Falcon` remain valid for the GPU lifetime, while the context only
borrows the `Falcon` for the duration of a boot or unload operation.
This distinction is hidden for shared references by covariance, but
cannot be ignored anymore if the context carries mutable references to
GPU subdevices, as will happen for the `Fsp` and the `Falcon`s.
Thus, give `GspBootContext` separate lifetimes for its subdevice borrows
and the GPU resources captured by those subdevices, and update its users
accordingly.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-12-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
We want to move the `Fsp` instance into `Gpu`, which will require
passing it as a mutable reference in `GspBootContext`, since
`Fsp::boot_fmc` is a mutable method. In order to use the mutable
references it contains, `GspBootContext` must also be mutable.
We will also follow up by making some methods of the `Falcon`s mutable,
which also requires passing them as mutable references.
Thus, make the `GspBootContext` passed to `Gsp::boot` and `Gsp::unload`
mutable, and pass mutable references to it to the GSP boot HAL methods.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-11-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
Add a local `Device` reference created from the `pci::Device` in the
`Gpu` constructor to avoid repeatedly calling `as_ref`.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-10-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
The files to give the `ModInfoBuilder` depend on the chipset; this is
HAL information, so move it there. Doing so lets us remove the
`uses_fsp` and `needs_fwsec_bootloader` ad-hoc methods of `Chipset`.
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-9-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
By being in the TU102 HAL, we already know that the GSP boot method is
the SEC2 Booter, so the only variable is whether the FWSEC bootloader is
used or not. Since `Chipset` also includes the variants that boot FSP,
querying it for that information introduces a potential code path (a
chipset that boots via FSP) that the current code doesn't handle.
Turn the use of the FWSEC bootloader into a property of the `Tu102` HAL,
and give GA102+ chipsets their own instance with that property set to
`false`. This removes the invalid code path and the only use of
`Chipset` is now to load the correct firmware files.
This also removes some uses of the `Chipset::needs_fwsec_bootloader`
method and prepares the ground for removing it.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-8-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
Turn the `run_fwsec_frts` function into a method of `Tu102`. A following
patch will turn the "use FWSEC bootloader" property into a flag of the
TU102 HAL itself, and making this a method will allow the code to access
it instead of querying `Chipset`.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-7-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
The construction of the unload bundle is currently a bit convoluted and
could be done in one function instead of two.
Additionally, turn that function into a method of `Tu102`. A following
patch will turn the "use FWSEC bootloader" property into a flag of the
TU102 HAL itself, and making this a method will allow the code to access
it instead of querying `Chipset`.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-6-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
The warning emitted when the unload bundle cannot be constructed is
valid regardless of the boot method, but it was local to `Tu102`. Move
it to `Gsp::boot` so it applies to all boot methods.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-5-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
`GspBootContext` contains the resources required to boot the GSP. As it
turns out, this is also the context required for unloading it.
Reflect that fact by replacing the arguments of `Gsp::unload` and
`UnloadBundle::run` with the `GspBootContext`. This symmetry between
`Gsp::boot` and `Gsp::unload` will also be convenient when we want to
make these methods generic over the boot context corresponding to the
boot method used.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-4-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
When adding the GSP unload capability, we introduced `BootUnloadGuard`
to automatically call `Gsp::unload` whenever an error occurred during
the boot process, in order to try to reset the GSP to a valid state.
This approach is not well-suited to the errors that may occur in HALs:
by definition, an error occurring in the HAL means that the GSP is not
booted; yet the first thing that `Gsp::unload` does is queue a shutdown
message to the GSP, which will inevitably result in a timeout when done
from a HAL.
Furthermore, `BootUnloadGuard` is problematic because it holds
additional references to the boot context, notably the `Falcon`s. These
extra references stand in the way of making some of the `Falcon`'s
methods mutable, since those methods would require exclusive access. As
this behavior is only needed in one place, introducing dedicated types
for it is distracting and unnecessary.
Thus, remove `BootUnloadGuard` and adopt a two-level error handling
strategy:
- HALs are free to handle their errors as they see fit (most likely, by
running their unload bundle if it is ready by the time of the error),
- `Gsp::boot` uses a `ScopeGuard` that runs `Gsp::unload`, since the
GSP should be up and running by the time `GspHal::boot` has returned.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-3-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
The sequence is currently stored in the `GspSequencer` even though its
lifetime is limited to `GspSequencer::run`. This object-oriented design
does not play well with the borrow-checker, as `GspSequencer::iter`
borrows the `GspSequencer`, which makes it difficult to introduce
mutable references in `GspBootContext`, as we want to do in order to
make the `Falcon` references mutable.
Thus, store the sequence locally in `GspSequencer::run`, and move
iterator creation to `GspSeqIter::new` so it no longer needs to borrow
the whole `GspSequencer`.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-2-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
`GspBootContext` contains all the resources currently carried by
`GspSequencerParams`, so replace the latter with the former for better
integration with the boot process and less code.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-1-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
Commit 267ec4d7223a ("loop: fix partition scan race between udev and
loop_reread_partitions()") stopped disk_force_media_change() from
setting GD_NEED_PART_SCAN because loop devices with LO_FLAGS_PARTSCAN
rescan partitions explicitly. However, partitions can also be added
manually with BLKPG while LO_FLAGS_PARTSCAN is clear.
When such a loop device is detached, __loop_clr_fd() skips
bdev_disk_changed(). Without GD_NEED_PART_SCAN, reopening the unbound
device no longer performs the previous lazy cleanup, leaving dead
partition devices behind. A subsequent LOOP_CONFIGURE can then fail its
partition scan with -EBUSY, as seen in blktests loop/009 after loop/008.
Call bdev_disk_changed() unconditionally during __loop_clr_fd(). The
disk capacity is already zero and the release path holds open_mutex, so
this drops all partitions without rescanning the detached backing file.
The new blktests loop/013 case covers this sequence by adding a partition
with BLKPG without LO_FLAGS_PARTSCAN, detaching the loop device, and
checking that the partition is gone when the device is reopened.
Fixes: 267ec4d7223a ("loop: fix partition scan race between udev and loop_reread_partitions()")
Reported-by: kernel test robot <oliver.sang@intel.com>
Closes: https://lore.kernel.org/oe-lkp/202607150754.b660f5b9-lkp@intel.com
Signed-off-by: Daan De Meyer <daan@amutable.com>
Link: https://patch.msgid.link/20260715-b4-loop-partition-cleanup-v1-1-b9f59910cd1e@amutable.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
In preparation for removing the strlcat() API[1], replace its five
uses with a small append helper built on strnlen() and strscpy().
The five calls append device name fragments to a basename buffer
that grows in place across the setup functions. The helper takes
the same arguments as strlcat() and writes the same bytes, including
when a fragment is truncated.
Link: https://github.com/KSPP/linux/issues/370 [1]
Signed-off-by: Ian Bridges <icb@fastmail.org>
Link: https://patch.msgid.link/albg4Rv7QxvLJD05@dev
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
The driver currently sets only the overflow interrupt enable bit
(OVR_FLOW_IEN) in the configuration register, leaving the overflow
mode bit (OVR_FLOW_M) at its default value of 0.
According to the TCA8418 datasheet (SCPS215G, Section 8.6.4.1
"Overflow Errata - Description"), both OVR_FLOW_M (Bit_5) and
OVR_FLOW_IEN (Bit_3) must be set high for the overflow interrupt
to be generated. If only OVR_FLOW_IEN is set, FIFO overflow events
are silently lost without notifying the host.
Fix this by setting OVR_FLOW_M alongside OVR_FLOW_IEN in the
configuration register.
Signed-off-by: Zhian Liang <liangzhan5dev@gmail.com>
Link: https://patch.msgid.link/20260529013900.43854-1-liangzhan5dev@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes
Arm SCMI/FF-A fixes for v7.2
Fix two runtime issues in the SCMI framework. Use full 64-bit division
when rounding range-based clock rates, avoiding divisor truncation and
a possible divide-by-zero on 32-bit systems. Rate-limit notification
queue-full warnings emitted from interrupt context to prevent printk
floods and prolonged system stalls during notification bursts. Also
correct a grammar error in the ARM_SCMI_POWER_CONTROL Kconfig help
text.
Fix the FF-A driver RX/TX buffer sizing logic to respect the maximum
buffer size advertised by firmware, while retaining compatibility with
older implementations that may reject PAGE_SIZE-rounded buffers.
Also fix a NULL pointer dereference in ffa_partition_info_get() by
rejecting NULL UUID strings before passing them to uuid_parse().
* tag 'scmi-ffa-fixes-7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_scmi: Rate-limit queue-full warnings in IRQ context
firmware: arm_scmi: Use 64-bit division for clock rate rounding
firmware: arm_scmi: Grammar s/may needed/may be needed/
firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get()
firmware: arm_ffa: Respect firmware advertised RX/TX buffer size limits
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
xe_pt_update_ops_init() fails to reset current_op to 0. On the
vm_bind path, ops_execute() calls xe_pt_update_ops_prepare() inside
the xe_validation_guard() / drm_exec_until_all_locked() loop. When
that loop retries due to lock contention or OOM eviction
(drm_exec_retry_on_contention() / xe_validation_retry_on_oom()),
xe_pt_update_ops_prepare() runs again on the same vops, and each
call to bind_op_prepare() increments current_op without resetting it.
After N retries current_op exceeds the array size allocated by
xe_vma_ops_alloc(), causing an out-of-bounds write into
SLUB-poisoned memory and a subsequent UAF crash in
xe_migrate_update_pgtables_cpu() when reading the corrupted pt_op->bind.
Also reset needs_svm_lock and needs_invalidation which are derived in
the same prepare pass and would otherwise cause wrong migrate ops
selection and redundant TLB invalidation on retry.
Fix this by resetting current_op, needs_svm_lock and needs_invalidation
in xe_pt_update_ops_init().
v2 (Matt):
- Add details in commit message.
- Add Fixes tag and Cc to stable@vger.kernel.org
Fixes: e8babb280b5e ("drm/xe: Convert multiple bind ops into single job")
Suggested-by: Matthew Auld <matthew.auld@intel.com>
Cc: stable@vger.kernel.org
Assisted-by: GitHub-Copilot:claude-sonnet-4.6
Signed-off-by: Zongyao Bai <zongyao.bai@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260714232433.2737533-1-zongyao.bai@intel.com
|
|
tc_aux_transfer() clamps an AUX read to the payload limit:
size_t size = min_t(size_t, DP_AUX_MAX_PAYLOAD_BYTES - 1, msg->size);
After the transfer it replaces size with the byte count the controller
reports in AUX_BYTES:
if (size)
size = FIELD_GET(AUX_BYTES, auxstatus);
AUX_BYTES is GENMASK(15, 8), so it can be up to 255. Nothing clamps it
back to the request. tc_aux_read_data() reads that many bytes into the
16-byte auxrdata stack buffer, then copies them into the caller buffer. A
reported count of 255 makes the read run to 256 bytes and overruns both.
The controller should never report more than it was asked to transfer, so
this is defense in depth rather than a live hole. The reported count is
only lightly trusted, and the check is cheap. Clamp it back to the request,
the same way ti-sn65dsi86 does in commit aca58eac52b8 ("drm/bridge:
ti-sn65dsi86: Never store more than msg->size bytes in AUX xfer").
Fixes: 12dfe7c4d9c5 ("drm/bridge: tc358767: Use reported AUX transfer size")
Co-developed-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
Signed-off-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patch.msgid.link/20260701064440.1541418-1-maoyixie.tju@gmail.com
|
|
Starting on LNL the WOPCM size is 8MB instead of 4, so we need to avoid
using the [0, 8MB) range of the GGTT as that can be unaccessible from
the microcontrollers.
Note that the proper long-term fix here is to read the WOPCM size from
the HW, but that is a more serious rework that would be difficult to
backport, so we can do that as a follow-up.
Fixes: 9c57bc08652a ("drm/xe/lnl: Drop force_probe requirement")
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Shuicheng Lin <shuicheng.lin@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
Link: https://patch.msgid.link/20260713221758.3285744-2-daniele.ceraolospurio@intel.com
|
|
Just like we did in iwlmvm, we also need to clear the mld state when the
firmware was killed because of the device being powered off during
suspend.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20260714165826.ff1c9e05e0a9.I8df8d4a0384065fd2a32cf258339be77084c55bd@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
If the device was powered off during suspend, we need to reload the
firmware in resume which also means that we need to reconfigure it.
It could be tempting to just set IWL_MVM_STATUS_HW_RESTART_REQUESTED
but that would leave IWL_MVM_STATUS_IN_HW_RESTART set forever since that
recovery is not managed by mac80211.
Just call iwl_mvm_restart_cleanup() from device_powered_off().
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20260714165826.dc33533ac962.I6d7cca9c4e5643a477eae1d0a4f5fc83a10d0ee7@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
The smart fifo is a feature in the firmware configured by the driver.
The driver keeps a state to remember what was the last configuration
sent to the firmware. Obviously, if the firmware stops, we need to
reconfigure the smart fifo. Since we didn't reset that state upon
firmware stop, we thought the firmware is already properly
configured and we didn't send the smart fifo configuration command
as part of the init sequence.
Reset the smart fifo state in iwl_mvm_stop_device() so that we
will properly send the command during the init that will come
later.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20260714165826.7d3c5efe2d1a.I16b23c328a677257257f695fa6f439e41fbcd081@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
Add support for LARI_CONFIG_CHANGE version 14 and populate
the newly added BIOS-related fields in the command payload.
Extend the version 14 command layout with UHB extension, puncturing and
WBEM metadata fields, update command-size handling for version negotiation,
and wire the new data into the LARI configuration flow. Track WBEM and
puncturing source/revision in fw runtime, set them when loading ACPI or
UEFI tables, and pass the headers to firmware. Update send conditions,
debug traces, and related documentation/comments to match the new format.
Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Link: https://patch.msgid.link/20260714165826.c73d2fbebbfe.I93af7c456f04ef10d03646a43aaeb1858ecdc36d@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
LARI_CONFIG_CHANGE command version 13 and above accepts raw DSM
values by default in firmware, so FW_ACCEPTS_RAW_DSM_TABLE should
not gate DSM bitmap handling for these versions.
Set has_raw_dsm_capa based on command version (version 13 and above
is true) with TLV fallback for older command versions. Also update TLV
kernel-doc to mark this capability obsolete for LARI command
version 13 and above.
Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Reviewed-by: Avinash Bhatt <avinash.bhatt@intel.com>
Link: https://patch.msgid.link/20260714165826.12c8b407e115.I6809041f1eb52b7fafe9172ca3e47323d43cc30a@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
Avoid indexing txq arrays and queue-used bitmaps with an
invalid queue ID by adding an early bounds check in
iwl_trans_pcie_txq_enable().
Assisted-by: GitHubCopilot:gpt-5.3-codex
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20260714165826.273be072f5ff.I0d6c36a4c06bdbb4655164c7792da32b6143731e@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
Check D3_END_NOTIFICATION payload length before reading notif->flags.
On short payloads, mark notif handling as failed.
Avoid out-of-bounds reads from malformed notifications.
Assisted-by: GitHubCopilot:gpt-5.3-codex
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20260714165826.db2df8b6b6bb.I6163bbdf433379bf1dbf9eb46fb9562892217bd7@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
