| Age | Commit message (Collapse) | Author |
|---|
|
Replace the per-controller irq_of_parse_and_map() call with
platform_get_irq_optional(). The controller IRQ is optional when absent
and the driver falls back to per-channel IRQs. The corresponding
irq_dispose_mapping() calls in the probe error path and remove function
are removed.
Moved before anything else in order to handle -EPROBE_DEFER and to avoid
doing extra work. Simplifies the if statements as well.
Assisted-by: LLM
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260911220439.177474-1-rosenp@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Validate the PCC shared memory signature when setting up an SCMI PCC
channel.
Reject channels whose shared memory signature does not encode
PCC_SIGNATURE combined with the PCC subspace ID, so misconfigured
firmware is caught before the transport starts using the shared memory
region.
Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
Link: https://patch.msgid.link/20260915-acpi_scmi_pcc-v5-9-298579e9f359@kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
|
|
Unlike Device Tree, the ACPI SCMI namespace device does not provide
child fwnodes to represent each protocol. Iterate over the non-BASE
entries in scmi_dsd_info_list to initialize their protocol devices and
transport channels. The BASE channel and device are handled by the
common setup path.
Let the transport channel-availability and SCMI protocol implementation
checks decide which of the known protocols are usable on the platform.
Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
Link: https://patch.msgid.link/20260915-acpi_scmi_pcc-v5-8-298579e9f359@kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
|
|
Add an SCMI transport for ACPI-described systems using PCCT PCC
subspaces through the Linux PCC mailbox layer.
Parse the SCMI Device Properties _DSD packages defined by Arm document
111115A v1.0, sections 2.2.1.1, 2.2.2.1 and 2.2.3. Map transport
UIDs to PCC subspaces for common and protocol-exclusive A2P and P2A
channels, validate the mappings, and cache them for channel setup.
Support the Powercap and System Telemetry protocol properties and add
the System Telemetry protocol ID. Implement PCC channel management,
message framing, shared-memory bounds validation, and response and
notification delivery.
Add the corresponding Kconfig, module and ARML0001 ACPI matching
plumbing.
Link: https://patch.msgid.link/20260915-acpi_scmi_pcc-v5-7-298579e9f359@kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
|
|
Move the protocol validation and device creation logic in scmi_probe()
into a reusable scmi_device_check_create() helper.
The helper centralizes checks for the protocol ID range, implementation
availability and duplicate activation before invoking
scmi_create_protocol_devices(). This preserves the existing behavior
while allowing the logic to be reused by the ACPI path, where protocol
child fwnodes are absent.
No functional change intended.
Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
Link: https://patch.msgid.link/20260915-acpi_scmi_pcc-v5-6-298579e9f359@kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
|
|
Pass the protocol ID to the transport chan_available() callback so a
transport can distinguish channels associated with different protocols
when they share the same firmware node. This is required by the ACPI PCC
transport to resolve protocol-exclusive PCC subspaces.
Update all transport implementations for the new callback signature.
Existing transports ignore the protocol ID, so there is no functional
change.
Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
Link: https://patch.msgid.link/20260915-acpi_scmi_pcc-v5-5-298579e9f359@kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
|
|
scmi_debugfs_common_setup() uses the "compatible" property to
populate the debugfs transport type string. ACPI-described SCMI
devices do not provide that DT property, so the string remains
NULL and debugfs setup falls through the allocation failure path.
Check the property lookup result and use the ACPI HID as the
fallback transport type when an ACPI companion is present.
All supported DT SCMI platforms are expected to provide "compatible",
so the non-ACPI fallback is not needed for normal DT operation. Keep
the explicit "unknown" fallback anyway to avoid passing NULL to
kstrdup() if that assumption is ever violated.
Link: https://patch.msgid.link/20260915-acpi_scmi_pcc-v5-4-298579e9f359@kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
|
|
Switch SCMI core plumbing from struct device_node * to struct
fwnode_handle * so the core can describe SCMI instances and protocols using
firmware nodes rather than OF nodes directly.
This change:
- Replaces core OF property lookups with fwnode_property_*() helpers.
- Plumbs fwnode through the SCMI device creation and channel setup paths.
- Updates transport ->chan_available() callbacks to take a fwnode.
- Stores per-protocol child fwnodes in info->active_protocols so the core
can later locate the descriptor for a given protocol ID.
- Updates mailbox/optee/smc/virtio transports to accept fwnodes and map
back to OF nodes where their existing parsing remains DT-specific.
DT-only transports such as mailbox, OP-TEE and SMC still parse DT
properties by mapping the fwnode back to an OF node. On non-DT systems
these transports report no channel available.
This is a mechanical step towards firmware-node neutrality and prepares the
SCMI core for non-DT transports, such as an ACPI/PCC transport. DT users
continue to work unchanged; no non-DT transport is enabled by this patch.
Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
Link: https://patch.msgid.link/20260915-acpi_scmi_pcc-v5-3-298579e9f359@kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
|
|
Extend the SCMI transport driver helper to support ACPI-based systems.
Introduce an internal helper macro that accepts both OF and ACPI match
tables, and expose two wrappers:
- DEFINE_SCMI_TRANSPORT_DRIVER(...) for DT/OF transports
- DEFINE_SCMI_ACPI_TRANSPORT_DRIVER(...) for ACPI transports
For ACPI, set the generated platform_driver .acpi_match_table via
ACPI_PTR(). The ACPI wrapper relies on the firmware-node propagation
provided by the preceding change so fwnode lookups on the spawned
platform device see the correct firmware description.
Keep existing DT users unchanged while allowing transports to be probed
using struct acpi_device_id tables on ACPI platforms.
Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
Link: https://patch.msgid.link/20260915-acpi_scmi_pcc-v5-2-298579e9f359@kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
|
|
The SCMI transport probe helper creates a platform device for the SCMI
core. device_set_of_node_from_dev() propagates the supplier's OF node,
but leaves generated devices for non-DT transports without a firmware
node.
Use platform_device_set_of_node_from_dev() for devicetree suppliers so
the shared OF node is referenced and marked as reused. For all other
suppliers, use platform_device_set_fwnode() so ACPI and other firmware
nodes are propagated with a reference that platform_device_release()
can balance.
Link: https://patch.msgid.link/20260915-acpi_scmi_pcc-v5-1-298579e9f359@kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
|
|
dma_get_slave_channel() can return NULL when acquiring a channel fails,
for example if fsl_edma_alloc_chan_resources() cannot request an IRQ.
fsl_edma3_xlate() dereferences that return value to update privatecnt.
Acquire and check the channel before publishing its source ID and
request parameters. A NULL-only check after the existing source-ID
assignment would leave the failed request marked as in use, causing
fsl_edma_srcid_in_use() to reject a subsequent request for that source.
The channel resource-allocation callback does not consume these request
parameters, so set them only after acquisition succeeds. The existing
scoped mutex release and successful-channel return are preserved.
Detected by static analysis and reviewed with AI-assisted source auditing.
Assisted-by: LLM
Signed-off-by: Slavin Liu <bolin.liu@seu.edu.cn>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260911060902.94153-1-bolin.liu@seu.edu.cn
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Add tasklet_kill() in fsl_dma_chan_remove() to prevent a race where the
tasklet is scheduled by the IRQ handler and runs after the channel has been
freed.
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260910202846.48941-1-rosenp@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
virtio_spi_transfer_one() puts spi->bits_per_word into the request
header, so a transfer that sets its own word size reaches the backend
with the device default instead. The SPI core has already copied that
default into xfer->bits_per_word when the transfer leaves it at zero,
the same way it does for xfer->speed_hz, which this function already
uses.
Per-transfer word sizes are ordinary SPI usage. mipi_dbi, for one, sends
a 9-bit command and reads the reply as 8-bit data in the same message.
With a 16-bit device default, a one-byte transfer asking for 8 bits goes
out as a partial 16-bit word, which the backend may reject.
Fixes: f98cabe3f6cf ("SPI: Add virtio SPI driver")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Hao-Qun Huang <alvinhuang0603@gmail.com>
Link: https://patch.msgid.link/20260913032049.11209.alvinhuang0603@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Currently, there are generally two types of DPHY for Rockchip. One is
the DPHY used by RK3288/RK3399, whose timing is described by Table A-3
High-Speed Transition Times in the databook. The other is the DPHY used
by PX30 and its successors. If its timing is still described using
RK3288/RK3399, it may not perform correctly on some DSI panel.
Add dphy_get_timing for different D-PHY types to adapt to timing
differences. The configuration details are as follows:
- RK3288/RK3399: Select the corresponding entry from the timing table based
on the data rate.
- PX30 and later platforms: Use a fixed timing configuration.
Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260914013331.108-3-kernel@airkyi.com
|
|
Different chips have varying support for the maximum bit rate per lane.
Add calculation for the maximum per lane bit rate for various chip
platforms.
Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260914013331.108-2-kernel@airkyi.com
|
|
Fix kernel-doc warnings where the documented parameter names
(@chan) no longer match the actual function signatures (@dchan),
and add the missing @cookie and @txstate parameters to
fsl_tx_status.
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260910202453.47887-1-rosenp@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The three prep functions write the first word of the command descriptor
block (cdb32) with a plain u32 assignment, while every other CDB/CF
descriptor field is written with cpu_to_be32(). The RAID Engine expects
big-endian descriptors, so the plain assignment produces a corrupted CDB
on little-endian hosts. Use cpu_to_be32() for cdb32 to match the
surrounding code.
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260910194324.33697-1-rosenp@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
In mmp_pdma_prep_slave_sg(), for_each_sg() iterates the scatterlist
putting each entry into 'sg', but the entry length is read from 'sgl'
(the list head) instead of 'sg' (the current entry):
for_each_sg(sgl, sg, sg_len, i) {
addr = sg_dma_address(sg);
avail = sg_dma_len(sgl); /* should be 'sg' */
Consequently 'avail' is always the length of the first entry. For
multi-sg lists this causes out-of-bounds reads when a later entry is
shorter than the first, and silent data loss when it is longer.
Single-sg or uniformly-sized lists happen to mask the issue.
Fixes: c8acd6aa6bed3 ("dmaengine: mmp-pdma support")
Signed-off-by: Baineng Shou <shoubaineng@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260910021652.1296640-1-shoubaineng@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
If request_irq() succeeds but a later step (self-test or device
registration) fails, the error path at err_free_irq frees the IRQ
but does not kill the tasklet. A previously scheduled tasklet can
still run after the channel is freed, accessing freed memory.
Add tasklet_kill() after free_irq() on the error path.
Fixes: ff7b04796d98 ("dmaengine: DMA engine driver for Marvell XOR engine")
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260909234601.101883-1-rosenp@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The current dma_chan structure contains both "device" and "dev". So
chan->device->dev refers to the DMA engine device.
chan->dev->device refers to the per-channel device instance.
Their similar naming makes the distinction unclear and increases reader
confusion.
Add union dma_chan::chan_dev to make its purpose explicit and clearly
identify it as the per-channel device. After all user switch to chan_dev,
union and dma_chan::dev will be removed.
Update the kernel-doc accordingly. Besides its sysfs usage, the per-channel
device is also used by some DMA engine drivers for IOMMU mapping and
therefore deserves a more accurate description.
No functional change intended.
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260909-dma-chan_dev-rename-v4-4-d8fb6892a70f@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Add a new helper function (dmaengine|vchan)_chan_dev() to access the DMA
channel device embedded in struct dma_chan_dev (chan->dev->device). This
provides a cleaner API instead of open-coding &chan->dev->device throughout
the drivers.
Replay private chan2dev() and dchan2dev() with this new common APIs in
indivial DMA engine drivers.
Prepare rename dma_chan::dev field.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260909-dma-chan_dev-rename-v4-3-d8fb6892a70f@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Use the existing dma_chan_name() helper to obtain the per-channel device
name instead of open-coding: dev_name(chan->dev->device) /
dev_name(chan2dev()).
Simplify the code, improve consistency and reduce line wrapping where
possible.
No functional change intended.
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Reviewed-by: Amelie Delaunay <amelie.delaunay@foss.st.com> # For STM32
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260909-dma-chan_dev-rename-v4-2-d8fb6892a70f@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Introduce vchan_chan_name() to obtain the DMA channel device name.
Use a dedicated helper instead of directly accessing dma_chan::dev
so callers remain unaffected by an upcoming rename of the struct member.
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Reviewed-by: Amelie Delaunay <amelie.delaunay@foss.st.com> # For STM32
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260909-dma-chan_dev-rename-v4-1-d8fb6892a70f@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
HDMA supports configurable DMA channel register space
separation which ranges from 256B to 32KB. Current implementation
supports 256B as default for DMA channel register space.
CPM6 supports the selection of channel register space via VSEC.
The default value for channel register space for CPM6 is 512B.
Updated the functions and methods to calculate the DMA channel
registers base address as per the selected channel separation
available as part of 'ch_space_sz'. Removed the unused function
__dw_regs() and structs, namely dw_hdma_v0_ch and dw_hdma_v0_regs.
Signed-off-by: Devendra K Verma <devverma@amd.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260907101213.1917064-3-devverma@amd.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
As per, 'Designware Cores PCI Express DM Controller - Reference
Manual', section 3.2.34.3, VSEC for DEVICE INFORMATION supports
the channel separation mechanisms. Basically, the HDMA IP allows
the user to configure the separation between DMA channel
registers and retrieve it via the VSEC capability mentioned
above.
HDMA IP supports the channel register space separation from
256B to 32KB. Default supported size is 256B.
Signed-off-by: Devendra K Verma <devverma@amd.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260907101213.1917064-2-devverma@amd.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
|
|
Many Remoteproc drivers, including K3, can and are built for compile
testing. The WKUP_M3, Keystone, and DA8xx can be also, enable this here.
Doing this exposes a compile warning on 64bit platforms as size_t changes
size, use the correct printf format specifier for size_t.
We cannot compile test for OMAP_REMOTEPROC due to dependency on OMAP
clock framework. But while here fix up the Kconfig help text which claims
this driver only works for OMAP4, when it really works across several
OMAP-class devices.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Beleswar Padhi <b-padhi@ti.com>
Tested-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://lore.kernel.org/r/20260904195634.2275867-3-afd@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
The type of message sent using omap-mailbox is always u32. The definition
of mbox_msg_t is uintptr_t which is wrong as that type changes based on
the architecture (32bit vs 64bit). Make the type fixed to u32.
This then means we need to fix the helper macro omap_mbox_message so it
doesn't cast to u32 twice. What this macro should be doing is converting
from the message type returned from the mailbox framework into the
omap-mailbox type. When fixing this we should add a macro for the other
direction (from omap-mailbox type to something that can be used with
mbox_send_message).
After these changes, make use of the new macros as appropriate.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Beleswar Padhi <b-padhi@ti.com>
Tested-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://lore.kernel.org/r/20260904195634.2275867-2-afd@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
The header ti_k3_common.h uses several definitions in headers it does not
include itself, this makes users of this header responsible for including
the right headers first. Instead include what we need here. Then go and
remove some headers that we do not use from the K3 Remoteproc drivers.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Beleswar Padhi <b-padhi@ti.com>
Tested-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://lore.kernel.org/r/20260904195634.2275867-1-afd@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
CXL r4.0 §8.2.4.20.12 ("Committing Decoder Programming") and §14.13.10
("CXL HDM Decoder Zero Size Commit") permit committing an HDM decoder
with size 0. BIOS may commit and lock such decoders so the OS cannot
program regions through them, this is a design choice rather than a spec
requirement.
The kernel rejected these with -ENXIO during port enumeration and
aborted the whole port, so affected systems showed nothing under "cxl
list".
Treat empty decoders as first class reservations. Back them with a
separately allocated resource, since the resource tree cannot represent
an empty range, and keep the skip and hdm_end accounting intact. Exclude
empty decoders from region assembly and avoid zero-length poison queries.
Suggested-by: Dan Williams <djbw@kernel.org>
Signed-off-by: Vishal Aslot <vaslot@nvidia.com>
Signed-off-by: Richard Cheng <icheng@nvidia.com>
Reviewed-by: Dan Williams <djbw@kernel.org>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Link: https://patch.msgid.link/20260914090858.19181-3-icheng@nvidia.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
|
|
"rc" carries both an error code and the loop control
signal for device_for_each_child(), so returning it bare is misleading,
the early guards mean "keep walking", not "no error". Zeroing "rc" to
forgive an -EFAULT on a RAM partition adds to that by discarding what
the device actually returned.
Return a literal 0 where the walk should continue, and test the
forgiven case directly instead of rewriting "rc". Give that test a
name, poison_efault_forgiven(), so cxl_get_poison_unmapped() and
poison_by_decoder() spell the same rule the same way. No functional
change.
Suggested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Richard Cheng <icheng@nvidia.com>
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Link: https://patch.msgid.link/20260914090858.19181-2-icheng@nvidia.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
|
|
rproc_trace_read() (in remoteproc_debugfs.c) prints the name of a
trace buffer whose device address could not be resolved, but nothing
ever assigns trace_mem.name, so that the diagnostics always prints
an empty string:
Trace not available
Copy the generated "trace%d" name into the memory entry, so the
diagnostics identifies the buffer failed to translate.
Fixes: a987e6b91a5a ("remoteproc: fix trace buffer va initialization")
Assisted-by: Claude-Code:glm-5.3
Signed-off-by: Yonghao Zhang <hyz3367@gmail.com>
Link: https://lore.kernel.org/r/20260911081810.740028-1-hyz3367@gmail.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
The documentation of the 'coredump' sysfs entry still advertises a
"default" configuration option and describes it as the default value
of the entry. Both date back to before the option was renamed to
"enabled" and the default configuration was changed to "disabled".
Update the comment to describe the three options the store callback
actually accepts, "disabled", "enabled" and "inline", along with the
real default value, and fix the coredump_show() comment which wrongly
claims the configuration is exposed via debugfs.
Assisted-by: Claude-Code:glm-5.3
Signed-off-by: Yonghao Zhang <hyz3367@gmail.com>
Link: https://lore.kernel.org/r/20260911030944.1645477-1-hyz3367@gmail.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
|
|
This pointer, which is part of struct rogue_fwif_tracebuf_space (a FW
interface structure), was initialised but never used to access the FW
trace buffer - only the source pointer in the initialisation being
removed is used.
Signed-off-by: Alexandru Dadu <alexandru.dadu@imgtec.com>
Reviewed-by: Luigi Santivetti <luigi.santivetti@imgtec.com>
Link: https://patch.msgid.link/20260910-b4-avoid-init-of-unused-fw-trace-buffer-pointer-v1-2-7e10274384c2@imgtec.com
Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
|
|
There's one FW object attached to KCCB usage (the return buffer) that is
separately initialised in pvr_fw_init(). Move this initialisation to
pvr_kccb_init() alongside the initialisation of rest of the members of
struct pvr_device->kccb.
Signed-off-by: Matt Coster <matt.coster@imgtec.com>
Signed-off-by: Alexandru Dadu <alexandru.dadu@imgtec.com>
Reviewed-by: Alessio Belle <alessio.belle@imgtec.com>
Link: https://patch.msgid.link/20260910-b4-avoid-init-of-unused-fw-trace-buffer-pointer-v1-1-7e10274384c2@imgtec.com
Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
|
|
While the MIPS firmware virtual memory context is created and destroyed
from within the MIPS firmware init and fini callbacks, the META and
RISC-V firmware contexts are created and destroyed from within blocks
right before or after those callbacks.
Match the logic for all firmware processors by moving those blocks to
the META and RISC-V init and fini callbacks.
Reviewed-by: Brajesh Gupta <brajesh.gupta@imgtec.com>
Signed-off-by: Alexandru Dadu <alexandru.dadu@imgtec.com>
Link: https://patch.msgid.link/20260915-b4-upstream-manage-fw-vm-context-from-init-and-fini-v2-1-c9cb43667143@imgtec.com
Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
|
|
The same is already done by the ccb_ctrl_init() callback.
Reviewed-by: Brajesh Gupta <brajesh.gupta@imgtec.com>
Signed-off-by: Alexandru Dadu <alexandru.dadu@imgtec.com>
Link: https://patch.msgid.link/20260915-b4-upstream-remove-duplicate-ccb-control-init-v2-1-ba0a6ae63a20@imgtec.com
Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
|
|
Move FWCORE_* macros to pvr_rogue_cr_defs.h where they should have been
from the beginning.
Signed-off-by: Matt Coster <matt.coster@imgtec.com>
Signed-off-by: Alexandru Dadu <alexandru.dadu@imgtec.com>
Reviewed-by: Alessio Belle <alessio.belle@imgtec.com>
Link: https://patch.msgid.link/20260810-b4-unify-repeated-reg-defs-and-move-fwcore-macros-v2-2-991ae813fd88@imgtec.com
Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
|
|
Some register definitions are annotated as "Register group: X, with N
repeats". The only difference between all the N copies of those definitions
is the register addresses which can be unified into a BASE/OFFSET pair.
Typical usage patterns of these repeated registers do not involve
hardcoding individual instances, so using any specific defines is
semantically incorrect.
Signed-off-by: Matt Coster <matt.coster@imgtec.com>
Signed-off-by: Alexandru Dadu <alexandru.dadu@imgtec.com>
Reviewed-by: Alessio Belle <alessio.belle@imgtec.com>
Link: https://patch.msgid.link/20260810-b4-unify-repeated-reg-defs-and-move-fwcore-macros-v2-1-991ae813fd88@imgtec.com
Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
|
|
For completeness, OR in the CACHED flags when we're not ORing in the
UNCACHED counterparts. One of these is probably zero, but (a) it isn't
evident just by reading these lines, and (b) the compiler will make it
disappear in that case.
Signed-off-by: Matt Coster <matt.coster@imgtec.com>
Signed-off-by: Alexandru Dadu <alexandru.dadu@imgtec.com>
Reviewed-by: Alessio Belle <alessio.belle@imgtec.com>
Link: https://patch.msgid.link/20260914-b4-cached-flag-on-meta-fw-v2-1-160b0e4e160f@imgtec.com
Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
|
|
drm_atomic_commit() calls drm_atomic_check_only() internally. Calling
drm_atomic_check_only() explicitly before the commit leaves the state
marked as checked and triggers drm_WARN_ON(state->checked) when the
commit checks the state again.
Remove the redundant explicit checks.
Fixes: 7436a87db99d ("drm/tests: hdmi: check the infoframes behaviour")
Cc: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Mika Penttilä <mpenttil@redhat.com>
Link: https://patch.msgid.link/20260914040723.2593700-1-mpenttil@redhat.com
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
Commit 2bcec01cf105 ("drm/amdgpu_dm: Convert to atomic_create_state")
converted dm_test_plane_create_state_initializes_state() to call
amdgpu_dm_plane_drm_plane_create_state(), which returns a struct
drm_plane_state pointer stored in a new plane_state variable.
However, the merge conflict resolution kept the old declaration
(struct dm_plane_state *old_state) instead of replacing it with
struct drm_plane_state *plane_state, leaving an unused variable with
the wrong type.
Fix the declaration to match what the conversion intended.
Fixes: 2bcec01cf105 ("drm/amdgpu_dm: Convert to atomic_create_state")
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20260915101251.1711103-1-mripard@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
The comment above the count_cells() call reads "Cound address cells"
where it should read "Count address cells", which is what the call below
it does.
Comment only, no functional change.
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Link: https://patch.msgid.link/20260909123501.215711-1-hemanth.selam@gmail.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
|
|
Replace the remaining kmalloc_array instance with kmalloc_objs.
Signed-off-by: Lalit Shankar Chowdhury <lalitshankarch@gmail.com>
Link: https://patch.msgid.link/20260910155846.79513-1-lalitshankarch@gmail.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Clock provider should not be using the consumer interface.
In other words, a provider should not be dealing with struct clk.
This change targets occurrences for which the provider uses the
consumer interface and corresponding clk_hw interface exist.
Reviewed-by: Brian Masney <bmasney@redhat.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260724-clk-provider-simple-clean-v2-7-56f306156d25@baylibre.com
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
|
|
brcmf_bss_connect_done() receives the firmware event in @e but discards it
on the failure path. Every failed connect is reported to cfg80211 as
WLAN_STATUS_AUTH_TIMEOUT (16), whatever the firmware actually said, so
userspace only ever sees:
wlan0: CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00 status_code=16
The all-zero BSSID comes from the same place: conn_params is memset to
zero and profile->bssid has not been filled in when the station never
associated.
status_code=16 therefore carries no information about the cause. It is not
an AP response and it does not mean "authentication timed out" - it is the
only failure value this driver can produce. This is a recurring source of
confusion: [1] has been open since 2023 with more than twenty follow-ups
and no explanation of the code, and covers BCM4345/6, BCM43430 and
CYW43455 across several kernel versions. It supersedes [2], filed against
the firmware repository a day earlier and closed in favour of it.
The firmware's own status (BRCMF_E_STATUS_*) is more specific - FAIL,
TIMEOUT, NO_NETWORKS, ABORT and so on - and it is already in hand. Log it
so the cause can be narrowed down without rebuilding the kernel.
bphy_err() is used rather than brcmf_dbg() or brcmf_info(): it is the form
the rest of this file uses, and of the three it is the only one that is
both visible in a distribution kernel and bounded. brcmf_dbg(CONN)
expands to no_printk() unless CONFIG_BRCMDBG is set, which is what makes
the reports in [1] and [2] impossible to act on - the people hitting this
run stock kernels. brcmf_info() expands to a plain pr_info() in a
non-debug build and is not rate limited, and wpa_supplicant retries the
association every few seconds, so it would flood the log. bphy_err() is
guarded by net_ratelimit() there, so a station retrying against an
unreachable AP prints at most a few lines per second.
All three fields are printed because only some of them are meaningful on
each path into the failure branch. brcmf_is_nonetwork() keys off @status,
so that is the useful field for a join that never associated - the case in
[1]. brcmf_is_linkdown() keys off @event_code and @flags and does not look
at @status at all, so @status can read 0 there; on those events it is
@reason which carries the 802.11 reason code, as the mapping in
brcmf_map_fw_linkdown_reason() shows. Printing the three together lets
the reader tell which path was taken instead of guessing from one number.
The status reported to cfg80211 is left alone; changing it would alter what
userspace sees.
[1] https://github.com/RPi-Distro/firmware-nonfree/issues/38
[2] https://github.com/raspberrypi/firmware/issues/1829
Assisted-by: Claude:claude-opus-5
Signed-off-by: Ryohei Hashimoto <laurel.medalist12@gmail.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20260913165526.4426-1-laurel.medalist12@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Advertise NL80211_EXT_FEATURE_FAST_ROAM_OFFLOAD only when firmware
reports FBT or OKC support. That lets userspace provide PMK material for
firmware fast roaming without enabling the path on devices that cannot
complete the offloaded roam.
Assisted-by: GitHub-Copilot-CLI:gpt-5.5
Signed-off-by: Carella Chen <carella.chen@infineon.com>
Signed-off-by: Jason Huang <jason.huang2@infineon.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20260911065656.1269623-6-Jason.Huang2@infineon.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Firmware can complete FT or OKC roaming before the driver reports the
connect or roam event to cfg80211. Detect those successful offloaded
cases when the profile uses firmware 1X or roaming offload and the
association request carries PMK cache state, FT is in use, or OKC is
enabled.
After reporting the connect or roam event, call cfg80211_port_authorized()
so nl80211 emits the dedicated NL80211_CMD_PORT_AUTHORIZED event instead
of reusing the reserved NL80211_ATTR_PORT_AUTHORIZED flag in CONNECT/ROAM
notifications.
Assisted-by: GitHub-Copilot-CLI:gpt-5.5
Signed-off-by: Darren Li <hsin-hung.li@cypress.com>
Signed-off-by: Chung-Hsien Hsu <Chung-Hsien.Hsu@infineon.com>
Signed-off-by: Chi-hsien Lin <chi-hsien.lin@cypress.com>
Signed-off-by: Carella Chen <carella.chen@infineon.com>
Signed-off-by: Jason Huang <jason.huang2@infineon.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20260911065656.1269623-5-Jason.Huang2@infineon.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
FT and OKC roaming offload need PMK material in firmware even when
the initial 802.1X exchange is handled by userspace. Add a roaming
firmware-supplicant profile state for those connections and allow PMK
configuration while firmware FT or OKC state is active.
Program the OKC PMK through the okc_info_pmk iovar before setting the
regular PMK when firmware reports OKC state. Only select the roaming
firmware-supplicant state when firmware advertises FBT or OKC support;
devices without those capabilities keep the profile in the userspace
supplicant state and do not issue roaming-offload specific iovars on
every connect.
For FT-PSK with firmware supplicant support, keep the profile in the
PSK firmware-supplicant state.
Assisted-by: GitHub-Copilot-CLI:gpt-5.5
Signed-off-by: Darren Li <hsin-hung.li@cypress.com>
Signed-off-by: Chung-Hsien Hsu <Chung-Hsien.Hsu@infineon.com>
Signed-off-by: Chi-hsien Lin <chi-hsien.lin@cypress.com>
Co-developed-by: Carella Chen <carella.chen@infineon.com>
Signed-off-by: Carella Chen <carella.chen@infineon.com>
Co-developed-by: Shelley Yang <shelley.yang@infineon.com>
Signed-off-by: Shelley Yang <shelley.yang@infineon.com>
Signed-off-by: Jason Huang <jason.huang2@infineon.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20260911065656.1269623-4-Jason.Huang2@infineon.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
