| Age | Commit message (Collapse) | Author |
|---|
|
Add a pci_warn() to __resource_resize_store(), so that BAR resize failures
are visible to the user, which can help troubleshoot any potential resource
resize issues.
While at it, rename the resource_resize_is_visible() to
resource_resize_attr_is_visible() along with the corresponding group
variable to align with the naming convention used by the resource attribute
groups.
Also, change the order of pci_dev_groups[] such that the resize group is
now located alongside the other resource groups.
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Link: https://patch.msgid.link/20260508043543.217179-9-kwilczynski@kernel.org
|
|
Currently, the PCI resource files (resourceN, resourceN_wc) are dynamically
created by pci_create_sysfs_dev_files(), called from both
pci_bus_add_device() and the pci_sysfs_init() late_initcall, with only a
sysfs_initialized flag for synchronisation. This has caused warnings and
boot panics when both paths race on the same device, e.g.:
sysfs: cannot create duplicate filename '/devices/pci0000:3c/0000:3c:01.0/0000:3e:00.2/resource2'
This is especially likely on Devicetree-based platforms, where the PCI host
controllers are platform drivers that probe via the driver model, which can
happen during or after the late_initcall. As such, pci_bus_add_device()
and pci_sysfs_init() are more likely to overlap.
Convert to static const attributes with three attribute groups (I/O, UC,
WC), each with an .is_bin_visible() callback that checks resource flags,
BAR length, and non_mappable_bars. A .bin_size() callback provides
pci_resource_len() to the kernfs node for correct stat and lseek behaviour.
As part of this conversion:
- Rename pci_read_resource_io() and pci_write_resource_io() to
pci_read_resource() and pci_write_resource() since the callbacks are no
longer I/O-specific in the static attribute context.
- Update __resource_resize_store() to use sysfs_create_groups() and
sysfs_remove_groups(), which re-evaluates visibility and runs the
.bin_size() callback for the static resource attribute groups.
- Remove pci_create_resource_files(), pci_remove_resource_files(), and
pci_create_attr() which are no longer needed.
- Move the __weak stubs outside the #if guard so they remain available
for callers converted in subsequent commits.
Platforms that do not define the HAVE_PCI_MMAP macro or the
ARCH_GENERIC_PCI_MMAP_RESOURCE macro, such as Alpha architecture,
continue using their platform-specific resource file creation.
For reference, the dynamic creation dates back to the pre-Git era:
https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/drivers/pci/pci-sysfs.c?id=42298be0eeb5ae98453b3374c36161b05a46c5dc
The write-combine support was added in commit 45aec1ae72fc ("x86: PAT
export resource_wc in pci sysfs").
Many other reports mentioned in the cover letter (first Link: below).
Link: https://lore.kernel.org/r/20260508043543.217179-1-kwilczynski@kernel.org/
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=215515
Closes: https://github.com/openwrt/openwrt/issues/17143
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Link: https://patch.msgid.link/20260508043543.217179-8-kwilczynski@kernel.org
|
|
pci_proc_attach_device() creates procfs entries for PCI devices and is
called from pci_bus_add_device(). It lazily creates the per-bus procfs
directory (bus->procdir) via proc_mkdir() on first use, and returns early
if proc_initialized is not yet set.
On x86 with ACPI, PCI enumeration occurs at subsys_initcall, before
pci_proc_init() sets proc_initialized at device_initcall. The
for_each_pci_dev() loop in pci_proc_init() then creates procfs entries for
these already-enumerated devices, but runs without holding
pci_rescan_remove_lock.
On ARM64 with devicetree, PCI host bridges probe at device_initcall. With
async probing enabled, pci_bus_add_device() can run concurrently with
pci_proc_init(), and both may call pci_proc_attach_device() for the same
device or for different devices on the same bus. As pci_host_probe() holds
pci_rescan_remove_lock while pci_proc_init() does not, there is no
serialisation between the two paths.
When two threads concurrently call pci_proc_attach_device() for devices on
the same bus, both observe bus->procdir as NULL and both call proc_mkdir().
The proc filesystem serialises directory creation internally, so only one
caller succeeds. The other results in a warning like:
proc_dir_entry '000c:00/00.0' already registered
The caller receives NULL (duplicate entry) and unconditionally stores it to
bus->procdir, corrupting the valid pointer set by the first caller.
Serialise access to proc_initialized, proc_bus_pci_dir, bus->procdir and
dev->procent with a new mutex local to drivers/pci/proc.c, and store the
created entries to bus->procdir and dev->procent only on success, so a
failed creation can never overwrite a valid pointer.
Additionally, wrap the for_each_pci_dev() loop in pci_proc_init() with
pci_lock_rescan_remove() to serialise against concurrent PCI bus
operations, add an early return in pci_proc_attach_device() when
dev->procent is already set to make the function idempotent, and clear
bus->procdir in pci_proc_detach_bus() to prevent use of a dangling pointer
after proc_remove().
Reported-by: Shuan He <heshuan@bytedance.com>
Closes: https://lore.kernel.org/linux-pci/20250702155112.40124-2-heshuan@bytedance.com/
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20260611150543.511422-1-kwilczynski@kernel.org
|
|
Replace the unconditional msleep(100) with the common helper
pci_host_common_link_train_delay(). The helper only waits when
max_link_speed > 2, as required by PCIe r6.0 sec 6.6.1.
This avoids unnecessary delay for Gen1/Gen2 links while retaining
the mandatory 100 ms for higher speeds.
Signed-off-by: Hans Zhang <18255117159@163.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260518004246.1384532-8-18255117159@163.com
|
|
The MediaTek Gen3 PCIe host driver lacks the required 100 ms delay after
link training completes for speeds > 5.0 GT/s, as specified in PCIe r6.0
sec 6.6.1.
The driver already stores max_link_speed (from the device tree). After
mtk_pcie_startup_port() successfully brings up the link, call
pci_host_common_link_train_delay() to comply with the specification.
Signed-off-by: Hans Zhang <18255117159@163.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260518004246.1384532-7-18255117159@163.com
|
|
The Aardvark PCIe controller driver waits for the link to come up but
does not implement the mandatory 100 ms delay after link training
completes for speeds greater than 5.0 GT/s (PCIe r6.0 sec 6.6.1).
The driver already maintains a 'link_gen' field that holds the negotiated
link speed. Use it together with pci_host_common_link_train_delay() to
insert the required delay immediately after confirming that the link
is up.
Signed-off-by: Hans Zhang <18255117159@163.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260518004246.1384532-6-18255117159@163.com
|
|
The DWC driver already implements the 100 ms delay required by PCIe
r6.0 sec 6.6.1 by checking pci->max_link_speed and calling msleep(100).
Replace the open-coded msleep() with the new common helper
pci_host_common_link_train_delay() to reduce code duplication and
improve maintainability. No functional change intended.
Signed-off-by: Hans Zhang <18255117159@163.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260518004246.1384532-5-18255117159@163.com
|
|
The Cadence HPA (High Performance Architecture IP) specific link setup
function cdns_pcie_hpa_host_link_setup() waits for the link to come up
but does not implement the required 100 ms delay after link training
completes for speeds > 5.0 GT/s (PCIe r6.0 sec 6.6.1).
Add a call to pci_host_common_link_train_delay() immediately after the
link is confirmed to be up, using the max_link_speed field. Also, in the
HPA host setup function, read the device tree property "max-link-speed"
to initialize max_link_speed if not already set by a glue driver.
This ensures compliance for HPA-based platforms.
Signed-off-by: Hans Zhang <18255117159@163.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
[bhelgaas: driver tag "cadence: HPA:" -> "cadence-hpa:"]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260518004246.1384532-4-18255117159@163.com
|
|
If 64-bit read operations are unstable, use tile-based WARN message
to provide more details on which tile this was observed.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patch.msgid.link/20260622132342.19600-7-michal.wajdeczko@intel.com
|
|
We initialized all remote tiles' xe_mmio structures with a new size
of 4MiB and offsets of 16MiB without sanity checks to see if mapped
GTTMMADR_BAR was actually at least that size.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patch.msgid.link/20260622132342.19600-6-michal.wajdeczko@intel.com
|
|
The pointer zeroing is not required, as we check xe->mmio.regs to
test if code is not trying to access MMIO after a driver unwind.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patch.msgid.link/20260622132342.19600-5-michal.wajdeczko@intel.com
|
|
We initialized the root tile's xe_mmio structure with a new size
of 4MiB without sanity checks to see if mapped GTTMMADR_BAR was
actually at least that size. Check BAR size against first 16MiB,
which is expected minimum BAR size for the one-tile platforms.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patch.msgid.link/20260622132342.19600-4-michal.wajdeczko@intel.com
|
|
This will allow us to simplify our custom release action where we
will keep only zeroing of the xe->mmio.regs as we still rely on it
all checks during all xe_mmio operations. While around, add missing
kernel-doc for the function and update the error message.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patch.msgid.link/20260622132342.19600-3-michal.wajdeczko@intel.com
|
|
We shouldn't access device registers after the device was unplugged
or the MMIO bar (GTTMMADR) was unmapped. Instead of relying on the
NPD splat due to zeroed tile->mmio.regs, which might be unreliable
anyway as not all xe_mmio structs are using that directly, add an
explicit check during all xe_mmio read/write operations to test if
xe->mmio.regs are still mapped and safely abort with WARN if not.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patch.msgid.link/20260622132342.19600-2-michal.wajdeczko@intel.com
|
|
pci_resource_alignment() is a bit on the complex side to have in a header
so put it into setup-res.c.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260429122617.7324-10-ilpo.jarvinen@linux.intel.com
|
|
pci_resource_alignment() calculates resource alignment and should not alter
its input structs. Make its input parameters const.
It requires making also pci_cardbus_resource_alignment() input const.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260429122617.7324-9-ilpo.jarvinen@linux.intel.com
|
|
pci_sriov_resource_alignment() inputs struct pci_dev which it should not
need to alter to calculate alignment.
Make pci_dev pci_sriov_resource_alignment() inputs const. It requires
making pci_iov_resource_size() input const as well.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260429122617.7324-8-ilpo.jarvinen@linux.intel.com
|
|
__pci_bridge_assign_resources() inputs const pci_dev *bridge, but then
immediately casts const away to pass the bridge to
pdev_assign_resources_sorted().
As pdev_assign_resources_sorted() performs assignment of resources, it
is not possible to make its input parameter to const. Neither of the
__pci_bridge_assign_resources() callers requires the bridge parameter
to be const.
Thus, simply remove the out of place cast and convert the input parameter
to non-const.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260429122617.7324-5-ilpo.jarvinen@linux.intel.com
|
|
Callers of __pci_bridge_assign_resources() and __pci_bus_assign_resources()
perform WARN_ON_ONCE(list_empty(add_list))) checks to sanity check that all
optional sizes were processed (and removed) from the list. The empty list
sanity check is duplicated code so the more appropriate place for it would
be inside the called function.
Placing the empty list check into __pci_bus_assign_resources() also ensures
all callsites do perform the sanity check which currently is not the case
when being called from enable_slot(). This inconsistency was noted by
Sashiko though only inside its in depth log but not flagged as a real
problem, possibly because this is only a sanity check that should never
fire. Nonetheless, this sanity check has been very useful to catch problems
early in the past so it's good to do it consistently everywhere.
As __pci_bus_assign_resources() is a recursive function, it needs to be
renamed to __pci_bus_assign_resources_one() to only perform the empty list
check at the end of processing the entire hierarchy in
__pci_bus_assign_resources().
Suggested-by: sashiko.dev # Sanity check missing from enable_slot()
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260429122617.7324-4-ilpo.jarvinen@linux.intel.com
|
|
The resource fitting algorithm uses different names from the list holding
the optional sizes: added, add_head, add_list, and realloc_head. 'add_list'
sounds the most natural and some of the related variables also use 'add'
such as 'add_size'.
To reduce variation, rename 'added' and 'add_head' to 'add_list'. Also
rename some 'realloc_head' cases selectively to 'add_list'.
While it would be nice to rename every 'realloc_head' to 'add_list' for
consistency, it might create a backport headache with all the work going
into this algorithm that may need to be eventually backported. Thus, it's
better to leave 'realloc_head' as is for now.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260429122617.7324-3-ilpo.jarvinen@linux.intel.com
|
|
Implement .db_vector_count() and .db_vector_mask() so NTB core/clients can
map doorbell events to per-vector work.
Report vectors as 0..(db_count - 2) (skipping the unused slot) and return
BIT_ULL(db_vector) for the corresponding doorbell bit. Use
ntb_epf_db_vector_count() for bounds checks in ntb_epf_db_vector_mask(), so
the same lower-bound guard is applied before building the bitmask.
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://patch.msgid.link/20260513024923.451765-13-den@valinux.co.jp
|
|
The EPF driver currently stores the incoming doorbell as a vector number
(irq_no + 1) in db_val and db_clear() clears all bits unconditionally.
This breaks db_read()/db_clear() semantics when multiple doorbells are
used.
Store doorbells as a bitmask (BIT_ULL(vector)) and make
db_clear(db_bits) clear only the specified bits. Use atomic64 operations
as db_val is updated from interrupt context.
Once db_val is stored as a bitmask, the ISR's doorbell vector is used
not only for ntb_db_event(), but also as the bit index for BIT_ULL().
The existing ISR derives that vector by subtracting pci_irq_vector(pdev,
0) from the Linux IRQ number passed to the handler, but Linux IRQ
numbers are not guaranteed to be contiguous.
Pass per-vector context as request_irq() dev_id instead, so the ISR gets
the device vector directly.
Validate the doorbell vector before updating db_val or calling
ntb_db_event(), so an unexpected vector cannot create an invalid shift
or be reported to NTB clients.
While at it, read and validate mw_count before requesting interrupt
vectors. An unsupported memory-window count does not need IRQs, and
failing before ntb_epf_init_isr() keeps the probe error path simple.
Fixes: 812ce2f8d14e ("NTB: Add support for EPF PCI Non-Transparent Bridge")
Suggested-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260513024923.451765-12-den@valinux.co.jp
|
|
ntb_db_event() expects the vector number to be relative to the first
doorbell vector starting at 0.
Vector 0 is reserved for link events in the EPF driver, so doorbells
start at vector 1. However, both supported peers (ntb_hw_epf with
pci-epf-ntb, and pci-epf-vntb) have historically skipped vector 1 and
started doorbells at vector 2.
Pass (irq_no - 2) to ntb_db_event() so doorbells are reported as 0..N-1.
If irq_no == 1 is ever observed, warn and ignore it, since the slot is
reserved in the legacy layout and reporting it as DB#0 would collide with
the real DB#0 slot.
Fixes: 812ce2f8d14e ("NTB: Add support for EPF PCI Non-Transparent Bridge")
Suggested-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260513024923.451765-11-den@valinux.co.jp
|
|
ndev->db_count includes an unused doorbell slot due to the legacy extra
offset in the peer doorbell path. db_valid_mask must cover only the real
doorbell bits and exclude the unused slot.
Set db_valid_mask to BIT_ULL(db_count - 1) - 1.
Fixes: 812ce2f8d14e ("NTB: Add support for EPF PCI Non-Transparent Bridge")
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://patch.msgid.link/20260513024923.451765-10-den@valinux.co.jp
|
|
ntb_epf_peer_db_set() uses ffs(db_bits) to select a doorbell to ring.
ffs() returns a 1-based bit index (bit 0 -> 1).
Entry 0 is reserved for link events, so doorbell bit 0 must map to entry
1. However, since the initial commit 812ce2f8d14e ("NTB: Add support for
EPF PCI Non-Transparent Bridge"), the implementation has been adding an
extra +1, ending up using entry 2 for bit 0. Fixing the extra increment
would break interoperability with peers running older kernels.
Keep the legacy behavior and document the offset and the resulting slot
layout to avoid confusion when enabling per-db-vector handling.
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260513024923.451765-9-den@valinux.co.jp
|
|
Implement .db_vector_count() and .db_vector_mask() so NTB core/clients can
map doorbell events to per-vector work and avoid the thundering-herd
behavior.
pci-epf-vntb reserves two slots in db_count: slot 0 for link events and
slot 1 which is historically unused. Therefore the number of doorbell
vectors is (db_count - 2).
Report vectors as 0..N-1 and return BIT_ULL(db_vector) for the
corresponding doorbell bit. Build db_valid_mask from a validated vector
count so out-of-range db_count values cannot create invalid shifts.
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260513024923.451765-8-den@valinux.co.jp
|
|
A severe livelock and subsequent Hung Task panic were observed in the
i2c-i801 driver during concurrent Fuzzing. The crash is caused by an
unconditional hardware register cleanup in the error handling path of
i801_access().
When i801_check_pre() fails (e.g., returning -EBUSY because the SMBus
controller is actively used by BIOS/ACPI), the kernel does not actually
acquire the hardware ownership. However, the code jumps to the 'out'
label and executes:
iowrite8(SMBHSTSTS_INUSE_STS | STATUS_FLAGS, SMBHSTSTS(priv));
This forcefully clears the INUSE_STS lock and resets the hardware status
flags without owning the controller. Doing so interrupts ongoing BIOS/ACPI
transactions and totally corrupts the SMBus hardware state machine.
Consequently, all subsequent i801_access() calls fail at the pre-check
stage, triggering an endless stream of "SMBus is busy, can't use it!"
error logs. Over a slow serial console, this printk flood monopolizes
the CPU (Console Livelock), starving other processes trying to acquire
the mmap_lock down_read semaphore, ultimately triggering the hung task
watchdog.
Fix this by moving the 'out' label below the hardware register cleanup.
If i801_check_pre() fails, we safely bypass the iowrite8() and only
release the software locks (pm_runtime and mutex), strictly adhering to
the rule of not releasing resources that were never acquired.
Fixes: 1f760b87e54c ("i2c: i801: Call i801_check_pre() from i801_access()")
Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
Cc: <stable@vger.kernel.org> # v6.3+
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/20260512093534.348655-1-w15303746062@163.com
|
|
In pci-epf-vntb, db_count represents the total number of doorbell slots
exposed to the peer, including:
- slot #0 reserved for link events, and
- slot #1 historically unused (kept for compatibility).
Only the remaining slots correspond to actual doorbell bits. The current
db_valid_mask() exposes all slots as valid doorbells.
Limit db_valid_mask() to the real doorbell bits by returning
BIT_ULL(db_count - 2) - 1, and guard against db_count < 2.
Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP")
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260513024923.451765-7-den@valinux.co.jp
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86
Pull x86 platform driver updates from Ilpo Järvinen:
- amd/hfi: Add support for dynamic ranking tables (version 3)
- amd/pmc:
- Add PMC driver support for AMD 1Ah M80H SoC
- Delay suspend for some Lenovo Laptops to avoid keyboard and lid
switch problems after s2idle
- arm64: qcom-hamoa-ec: Add Hamoa/Purwa/Glymur EC driver
- asus-armoury: add support for G614PR, GA402NJ, GA403UM, and FX608JPR
- asus-wmi: add keystone dongle support
- dell-dw5826e: Add reset driver for DW5826e
- dell-laptop: Fix rollback path
- hp-wmi:
- Add support for Omen 16-ap0xxx (board ID 8D26) and board ID 8B2F
- intel-hid:
- Add HP ProBook x360 440 G1 5 button array support
- Prevent racing ACPI notify handlers
- intel/pmc:
- Add Nova Lake support
- Rate-limit LTR scale-factor warning
- intel-uncore-freq:
- Expose instance ID in the sysfs
- Fix current_freq_khz after CPU hotplug
- intel/vsec: Restore BAR fallback for header walk
- ISST: Restore SST-PP control to all domains
- lenovo-wmi-*:
- Add more CPU tunable attributes
- Add GPU tunable attributes
- Add WMI battery charge limiting
- oxpec: add support for OneXPlayer Super X
- sel3350-platform: Retain LED state on load and unload
- surface: SAM: Add support for Surface Pro 12in
- uniwill-laptop: Add support for battery charge modes
- tools/power/x86/intel-speed-select: Harden daemon pidfile open
- Major refactoring efforts:
- ACPI driver to platform driver conversion
- Converting drivers to use the improved WMI API
- Miscellaneous cleanups / refactoring / improvements
* tag 'platform-drivers-x86-v7.2-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: (115 commits)
platform/x86/intel/pmc: Add NVL PCI IDs for SSRAM telemetry discovery
platform/x86/intel/pmc/ssram: Make PMT registration optional
platform/x86/intel/pmc/ssram: Add ACPI discovery scaffolding
platform/x86/intel/pmc/ssram: Switch to static array with per-index probe state
platform/x86/intel/pmc/ssram: Refactor DEVID/PWRMBASE extraction into helper
platform/x86/intel/pmc/ssram: Add PCI platform data
platform/x86/intel/pmc/ssram: Rename probe and PCI ID table for consistency
platform/x86/intel/pmc: Add ACPI PWRM telemetry driver for Nova Lake S
platform/x86/intel/pmc: Add PMC SSRAM Kconfig description
platform/x86/intel/pmt: Unify header fetch and add ACPI source
platform/x86/intel/pmt: Cache the telemetry discovery header
platform/x86/intel/pmt: Pass discovery index instead of resource
platform/x86/intel/pmt/telemetry: Move overlap check to post-decode hook
platform/x86/intel/pmt/crashlog: Split init into pre-decode
platform/x86/intel/pmt: Add pre/post decode hooks around header parsing
modpost: Handle malformed WMI GUID strings
platform/wmi: Make sysfs attributes const
platform/wmi: Make wmi_bus_class const
hwmon: (dell-smm) Use new buffer-based WMI API
platform/x86: dell-ddv: Use new buffer-based WMI API
...
|
|
At first glance the harmless cleanup of the driver does nothing bad.
However, as the operator precedence list states the '*' (multiplication)
and '/' division operators have order 5 with left-to-right associativity
the *= has order 17 and associativity right-to-left. It wouldn't be
a problem to replace
foo = foo * HZ / 1000000;
with
foo *= HZ / 1000000;
if HZ constant is in Hertz. The problem is that in the Linux kernel HZ is
defined in jiffy units, which is order of magnitude smaller than a million.
That's why operator precedence has a crucial role here. Fix the regression
by reverting pre-optimized calculations.
Fixes: be40a3ae719f ("i2c: mpc: Use of_property_read_u32 instead of of_get_property")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: <stable@vger.kernel.org> # v6.4+
Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/20260618144934.3249950-1-andriy.shevchenko@linux.intel.com
|
|
Pull NVMe fixes from Keith:
"- Apple A11 quirk for sharing tags across admin and IO queues (Nick)
- Target fix for short AUTH_RECEIVE buffers (Michael)
- Target fix for SQ refcount leak (Wentao)
- Target RDMA handling inline data with nonzero offset (Bryam)
- Target TCP fix handling the TCP_CLOSING state (Maurizio)
- FC abort fixes in early initialization (Mohamed)
- Controller device teardown fixes (Maurizio, John)
- Allocate the target ana_state with the port (Rosen)
- Quieten sparse and sysfs symbol warnings (John)"
* tag 'nvme-7.2-2026-06-23' of git://git.infradead.org/nvme:
nvmet-tcp: handle TCP_CLOSING state in nvmet_tcp_state_change
nvmet-auth: reject short AUTH_RECEIVE buffers
nvme-fc: Do not cancel requests in io target before it is initialized
nvme: make nvme_add_ns{_head}_cdev return void
nvme: make some sysfs diagnostic structures static
nvmet-rdma: handle inline data with a nonzero offset
nvme: target: allocate ana_state with port
nvme: fix crash and memory leak during invalid cdev teardown
nvmet: fix refcount leak in nvmet_sq_create()
nvme: quieten sparse warning in valid LBA size check
nvme-apple: Prevent shared tags across queues on Apple A11
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox
Pull mailbox updates from Jassi Brar:
"Core:
- add debugfs support for used channels
- fix resource leak on startup failure
- propagate tx error codes
- clarify blocking mode thread support
Drivers:
- exynos: remove unused register definitions
- imx: refactor IRQ handlers, migrate to devm helpers, and other
minor improvements
- mpfs: fix syscon presence check in inbox ISR
- mtk-adsp: fix use-after-free during device teardown
- qcom: add dt-bindings for QCOM Maili, Hawi, Shikra APCS, and Nord
CPUCP platform support"
* tag 'mailbox-v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox: (23 commits)
mailbox: imx: Don't force-thread the primary handler
mailbox: imx: Move the RXDB part of the mailbox into the threaded handler
mailbox: imx: Move the RX part of the mailbox into the threaded handler
mailbox: imx: Start splitting the IRQ handler in primary and threaded handler
mailbox: imx: Use channel index instead of zero in imx_mu_specific_rx()
mailbox: imx: use devm_of_platform_populate()
mailbox: imx: Use devm_pm_runtime_enable()
mailbox: imx: Add a channel shutdown field
mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()
dt-bindings: mailbox: qcom: Add IPCC support for Maili Platform
mailbox: add list of used channels to debugfs
mailbox: don't free the channel if the startup callback failed
mailbox: Make mbox_send_message() return error code when tx fails
mailbox: Clarify multi-thread is not supported in blocking mode
mailbox: mtk-adsp: fix UAF during device teardown
mailbox: qcom: Unify user-visible "Qualcomm" name
mailbox: exynos: Drop unused register definitions
dt-bindings: mailbox: qcom: Add IPCC support for Hawi Platform
dt-bindings: mailbox: qcom,cpucp-mbox: Add Hawi compatible
dt-bindings: mailbox: qcom: Add Shikra APCS compatible
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd
Pull tpm updates from Jarkko Sakkinen:
"Only bug fixes"
* tag 'for-next-tpm-7.2-rc1-fixed' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd:
tpm: fix event_size output in tpm1_binary_bios_measurements_show
tpm: tpm_crb_ffa: revert defered_probed when tpm_crb_ffa is built-in
tpm: tpm2-sessions: wait for async KPP completion in tpm_buf_append_salt
tpm: tpm_tis: Add settle time for some TPMs
tpm: tpm_tis: store entire did_vid
tpm_crb: Check ACPI_COMPANION() against NULL during probe
tpm: tpm_tis_spi: Use wait_woken() in wait_for_tmp_stat()
tpm: Initialize name_size_alg for non-NULL name in tpm_buf_append_name()
tpm: restore timeout for key creation commands
tpm: svsm: constify tpm_chip_ops
|
|
Commit 76934e495cdc ("cpuidle: Add sanity check for exit latency and
target residency") had added a check to prevent the exit latency of an
idle state from exceeding its target residency that later was limited to
printing a warning message in that case in commit 4bf944f3fcb6 ("cpuidle:
Warn instead of bailing out if target residency check fails").
However, a thorough code inspection with that in mind leads to the
conclusion that actually there are no assumptions in cpuidle regarding
the relationship between the exit latency and target residency of a
given idle state. It is generally assumed that the idle states table
provided by a cpuidle driver will be sorted by both the target residency
and exit latency in ascending order, but that's a different matter.
Accordingly, drop the check in question along with the message printed
when it triggers and the inaccurate comment preceding it.
Fixes: 4bf944f3fcb6 ("cpuidle: Warn instead of bailing out if target residency check fails")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Christian Loehle <christian.loehle@arm.com>
[ rjw: Subject fixup ]
Link: https://patch.msgid.link/3444162.aeNJFYEL58@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
As SoundWire devices tend to enumerate on the bus after probe, drivers
frequently need to wait for the device to initialise from common driver
code. The common system is to split drivers into a core module and then
a module for each communication bus. These two facts tend to cause
Kconfig issues, the issue tends to be when SOUNDWIRE=m and DRIVER_I2C=y,
this usually selects DRIVER=y. The driver code then wants to call
sdw_slave_wait_for_init(), but this results in calling a module function
from built in code. A depends on SOUNDWIRE | !SOUNDWIRE could be added to
the end driver but this seems slightly off as it adds a lot of counter
intuitive depends.
A simpler solution is to make sdw_slave_wait_for_init() a static inline
function. As part of doing this add a check for the slave device being
NULL acknowledging that this is likely called from code that is shared
between control buses. It does require dropping the call to
sdw_show_ping_status() but this can be added back in end drivers that
used it originally.
Currently this is causing rand config issues on RT5682 and will soon
also cause similar problems on cs42l43.
Acked-by: Vinod Koul <vkoul@kernel.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260623101814.24044-2-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
In davinci_gpio_irq_setup(), after successfully creating an IRQ domain
with irq_domain_create_legacy(), a subsequent devm_kzalloc() failure
in the bank loop causes the function to return -ENOMEM without
removing the IRQ domain.
Unlike devm-managed resources, irq_domain_create_legacy() does not
auto-clean up on probe failure, so the domain is leaked.
Fix by calling irq_domain_remove() before returning on allocation
failure.
Fixes: b5cf3fd827d2 ("gpio: davinci: Redesign driver to accommodate ngpios in one gpio chip")
Signed-off-by: Qingshuang Fu <fuqingshuang@kylinos.cn>
Link: https://patch.msgid.link/20260623023106.117229-1-fffsqian@163.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
tegra_gpio_direction_input() and tegra_gpio_direction_output() already
program the GPIO controller direction registers directly. The additional
pinctrl_gpio_direction_input/output() calls do not add a Tegra pinctrl
operation, because the Tegra pinmux ops provide GPIO request/free
handling but no gpio_set_direction hook.
The extra call still enters the pinctrl core and takes pctldev->mutex.
Shared GPIO users can call the direction path while holding their
per-line spinlock, so this otherwise redundant pinctrl direction call can
sleep in an atomic context.
This was found by our static analysis tool and then confirmed by manual
review of tegra_gpio_probe(), the Tegra GPIO direction callbacks and the
Tegra pinctrl ops. The reviewed path has a default non-sleeping
struct gpio_chip while the direction callback still enters the pinctrl
mutex path.
A directed runtime validation kept the same non-sleeping chip registration
and drove:
gpio_shared_proxy_direction_output()
gpiod_direction_output_raw_commit()
tegra_gpio_direction_output()
pinctrl_gpio_direction_output()
Lockdep reported a sleep-in-atomic warning with the shared GPIO spinlock
held and pinctrl_get_device_gpio_range() plus tegra_gpio_direction_output()
on the stack.
Do not mark the whole chip as can_sleep to paper over this: can_sleep
describes whether get()/set() may sleep, and Tegra value access is MMIO.
Remove the redundant pinctrl direction calls and keep pinctrl involvement
in the existing request/free path.
Fixes: 11da90541283 ("gpio: tegra: Fix offset of pinctrl calls")
Cc: stable@vger.kernel.org
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
Link: https://patch.msgid.link/20260619152439.1239561-1-runyu.xiao@seu.edu.cn
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
Add missing Spectre mitigation for userspace controlled parallel
submission slot.
Discovered using AI-assisted static analysis confirmed by Intel
Product Security.
Reported-by: Martin Hodo <martin.hodo@intel.com>
Fixes: e5e32171a2cf ("drm/i915/guc: Connect UAPI to GuC multi-lrc interface")
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Tvrtko Ursulin <tursulin@ursulin.net>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Cc: <stable@vger.kernel.org> # v5.16+
Link: https://patch.msgid.link/20260622132539.165558-1-joonas.lahtinen@linux.intel.com
(cherry picked from commit 15b9353deff3cf72331c387780de3cf9c316b643)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
Store tiling function pointer in struct intel_panic instead of struct
intel_framebuffer, and store struct intel_panic pointer instead of
struct intel_framebuffer pointer in struct drm_scanout_buffer private
member.
To make this happen, pass the tiling function pointer to panic setup
hook, and initialize sb->private in the hook for clarity.
This allows us to drop the dependency on struct intel_framebuffer from
i915 and xe panic code.
Note: It would be less verbose to have a typedef for the tiling function
pointer. However, there isn't a nice location for it that wouldn't also
increase header interdependencies.
Cc: Jocelyn Falempe <jfalempe@redhat.com>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/d97abae79db3437c617cd4cb6193ba017b3a8d78.1780394867.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Drop the dependency on intel_fb_bo() and intel_fb.h by storing the fb bo
passed in the setup hook to struct intel_panic.
Cc: Jocelyn Falempe <jfalempe@redhat.com>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/735c3f18212207db63d71364d6a8569480c81b42.1780394867.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Start reducing i915 and xe core dependency on struct intel_framebuffer
by passing the fb obj from display.
Cc: Jocelyn Falempe <jfalempe@redhat.com>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/840c4ccaced5f1c82277285938287776c8cdf513.1780394867.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
The extra layer in the panic hooks is useless. Remove it.
Cc: Jocelyn Falempe <jfalempe@redhat.com>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/69a776c2951b3d1f81d8eb3870cbc7fda4d1c6e0.1780394867.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Having two small files for panic handling is a bit too much. Merge
i915_panic.c into i915_gem_panic.c. This is just code movement, cleanups
will follow.
Cc: Jocelyn Falempe <jfalempe@redhat.com>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/4c294d6402e003040b934d94a0b14bd42704e21f.1780394867.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
The panic handling is a bit special and isolated part of
i915_gem_pages.c. Split it out to i915_gem_panic.[ch].
Cc: Jocelyn Falempe <jfalempe@redhat.com>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/f2093946e723aa27e856987d13692eb0308a4d85.1780394867.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Add missing Spectre mitigation for userspace controlled parallel
submission slot.
Discovered using AI-assisted static analysis confirmed by Intel
Product Security.
Reported-by: Martin Hodo <martin.hodo@intel.com>
Fixes: e5e32171a2cf ("drm/i915/guc: Connect UAPI to GuC multi-lrc interface")
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Tvrtko Ursulin <tursulin@ursulin.net>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Cc: <stable@vger.kernel.org> # v5.16+
Link: https://patch.msgid.link/20260622132539.165558-1-joonas.lahtinen@linux.intel.com
|
|
The driver explicitly sets the .driver_data member of struct
platform_device_id to zero without relying on that value. Drop these
unused assignments.
While touching this array unify spacing and usage of commas and use
named initializers for .name.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
CAP1114 is a 14-channel capacitive touch sensor with 11 LED outputs
and hardware reset support.
The CAP1114 uses two control registers for LED output management and
requires two button status registers for touch input state reporting.
By default, channels CS8~CS14 operate as a single grouped block.
Set the corresponding register enable bit to enable these channels as
independent touch inputs. Note these channels share the input threshold
of the eighth entry, causing num_sensor_thresholds to differ from
num_channels.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
Link: https://patch.msgid.link/20260617150318.753148-11-jerrysteve1101@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
Check of_property_present() before parsing microchip,calib-sensitivity
and microchip,signal-guard, so that models which do not support these
properties (e.g. CAP1114) skip the parsing entirely.
This prevents a potential buffer overflow in calib_sensitivities[8] and
signal_guard_inputs_mask when a model with more than 8 channels
(CAP1114 has 14) would otherwise call of_property_read_u32_array()
with num_channels as the element count.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
Link: https://patch.msgid.link/20260617150318.753148-9-jerrysteve1101@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
Extend cap11xx_hw_model structure to support CAP1114 with
different register offsets and hardware characteristics:
- led_output_control_reg_base: different address on CAP1114
- sensor_input_reg_base: different address on CAP1114
- num_sensor_thresholds: separate value from num_channels for CAP1114
- has_repeat_en: repeat enable support, disabled by default on CAP1114
Include linux/bits.h, update the register operations related to LEDs.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
Link: https://patch.msgid.link/20260617150318.753148-8-jerrysteve1101@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
Some CAP11xx devices (CAP1126/CAP1188) have a dedicated RESET pin.
Add hardware reset operation to improve device reliability and
ensure proper initialization on probe.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
Link: https://patch.msgid.link/20260617150318.753148-7-jerrysteve1101@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
