| Age | Commit message (Collapse) | Author |
|---|
|
Add new bsg interface to issue MPI passthrough sub command to validate
the new flash firmware image partition.
Signed-off-by: Manish Rangankar <mrangankar@marvell.com>
Signed-off-by: Nilesh Javali <njavali@marvell.com>
Reviewed-by: Himanshu Madhani <hmadhani2024@gmail.com>
Link: https://patch.msgid.link/20251210101604.431868-6-njavali@marvell.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
FC firmware does not come online during on-the-fly upgrade i.e. on soft
reset. To limit Load flash firmware, i.e. MBC 3 changes, validate MCU
signature before executing MBC 03h
Signed-off-by: Manish Rangankar <mrangankar@marvell.com>
Signed-off-by: Nilesh Javali <njavali@marvell.com>
Reviewed-by: Himanshu Madhani <hmadhani2024@gmail.com>
Link: https://patch.msgid.link/20251210101604.431868-5-njavali@marvell.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
For 28xxx adaptor Load flash firmware mailbox load the operational
firmware from flash, and also validate the checksum. Driver does not
need to load the operational firmware anymore, but it still need to read
fwdt from flash to build and allocate firmware dump template. Remove
request_firmware() support for 28xxx adapter.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202512031128.XsuvzBv1-lkp@intel.com/
Signed-off-by: Manish Rangankar <mrangankar@marvell.com>
Signed-off-by: Nilesh Javali <njavali@marvell.com>
Reviewed-by: Himanshu Madhani <hmadhani2024@gmail.com>
Link: https://patch.msgid.link/20251210101604.431868-4-njavali@marvell.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Incorrect speed info is shown in driver logs for 64G SFP. Add support
for 64G SFP speed as per SFF-8472 specification.
Signed-off-by: Manish Rangankar <mrangankar@marvell.com>
Signed-off-by: Nilesh Javali <njavali@marvell.com>
Reviewed-by: Himanshu Madhani <hmadhani2024@gmail.com>
Link: https://patch.msgid.link/20251210101604.431868-3-njavali@marvell.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Print additional information about the speed while displaying SFP
information.
Signed-off-by: Himanshu Madhani <hmadhani@marvell.com>
Signed-off-by: Nilesh Javali <njavali@marvell.com>
Reviewed-by: Himanshu Madhani <hmadhani2024@gmail.com>
Link: https://patch.msgid.link/20251210101604.431868-2-njavali@marvell.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
If UFS resume fails, the event history is updated in ufshcd_resume(), but
there is no code anywhere to record UFS suspend. Therefore, add code to
record UFS suspend error event history.
Fixes: dd11376b9f1b ("scsi: ufs: Split the drivers/scsi/ufs directory")
Cc: stable@vger.kernel.org
Signed-off-by: Seunghwan Baek <sh8267.baek@samsung.com>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
Link: https://patch.msgid.link/20251210063854.1483899-2-sh8267.baek@samsung.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Multiple functions in the SCSI core accept an 'int reason' argument.
The 'int' type of these arguments doesn't make it clear what values are
acceptable for these arguments. Document which values are supported for
these arguments by introducing the enumeration type scsi_qc_status. 'qc'
in the type name stands for 'queuecommand' since the values passed as
the 'reason' argument are the .queuecommand() return values.
Cc: John Garry <john.g.garry@oracle.com>
Cc: Hannes Reinecke <hare@suse.de>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/20251113181730.1109331-1-bvanassche@acm.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
recovery"
Ranjan Kumar <ranjan.kumar@broadcom.com> says:
This patch series enhances the mpt3sas driver’s device bring-up,
readiness detection, and event recovery mechanisms to improve
robustness in environments with slow-responding or transient SAS/PCIe
devices.
The series introduces optional control over issuing TEST UNIT READY
(TUR) commands during device unblocking, configurable retry limits,
and a mechanism to requeue firmware topology events when devices are
temporarily busy. Together, these updates reduce discovery failures
and improve recovery reliability following firmware or link events.
Link: https://patch.msgid.link/20251113153712.31850-1-ranjan.kumar@broadcom.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Fix W=1 compilation warnings.
Signed-off-by: Ranjan Kumar <ranjan.kumar@broadcom.com>
Link: https://patch.msgid.link/20251113153712.31850-7-ranjan.kumar@broadcom.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Add a new module parameter "command_retry_count" to control the number
of retries during device discovery and readiness checks, improving
reliability for slow or transient SAS/PCIe devices.
Signed-off-by: Ranjan Kumar <ranjan.kumar@broadcom.com>
Link: https://patch.msgid.link/20251113153712.31850-6-ranjan.kumar@broadcom.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Add support to requeue SAS/PCIe topology change events when devices are
busy or not ready. Introduce delayed work with retry counters so events
are retried instead of dropped, improving device discovery by retrying
transient failures instead of dropping events.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202510311720.NiDwRLwp-lkp@intel.com/
Signed-off-by: Ranjan Kumar <ranjan.kumar@broadcom.com>
Link: https://patch.msgid.link/20251113153712.31850-5-ranjan.kumar@broadcom.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Introduce a new module parameter "issue_scsi_cmd_to_bringup_drive"
(default=1) which allows overriding the driver's behavior of issuing
SCSI TEST_UNIT_READY/START_UNIT commands to bring devices to READY state
during unblock.
Improve device discovery and I/O unblocking reliability by adding
robust device readiness checks and separate callback handling for
discovery I/O. This introduces new helper routines for SCSI command
execution and readiness determination, ensuring smoother recovery and
initialization for slow or transient devices.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202510310924.crvtELzs-lkp@intel.com/
Signed-off-by: Ranjan Kumar <ranjan.kumar@broadcom.com>
Link: https://patch.msgid.link/20251113153712.31850-4-ranjan.kumar@broadcom.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Add a "no_turs" flag to _scsih_ublock_io_all_device() to optionally skip
TEST UNIT READY (TUR) checks while unblocking devices. This is used
after broadcast events where sending TURs is not required.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202510310216.gerpzbxP-lkp@intel.com/
Signed-off-by: Ranjan Kumar <ranjan.kumar@broadcom.com>
Link: https://patch.msgid.link/20251113153712.31850-2-ranjan.kumar@broadcom.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Justin Tee <justintee8345@gmail.com> says:
Update lpfc to revision 14.4.0.13
This patch set introduces reporting encryption information for Fibre
Channel HBAs.
First, the scsi_transport_fc layer is updated to include a new
fc_encryption_info attribute that is added to struct fc_rport.
Supporting sysfs and LLDD templates are provided.
Then, the lpfc driver is updated to utilize the new templates for
reporting encrypted fibre channel connections to upper layer.
The patches were cut against Martin's 6.19/scsi-queue tree.
Link: https://patch.msgid.link/20251211001659.138635-1-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Update lpfc version to 14.4.0.13
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://patch.msgid.link/20251211001659.138635-4-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Support logging encryption events in both point-to-point and fabric
topologies. A new LOG_ENCRYPTION flag is defined for reporting
encryption related events for HBAs that support the FEDIF feature.
Encryption information is stored in each NDLP object, which is
determined during the discovery stage after PLOGI completes.
For reporting encryption information to upper layers, the
.get_fc_rport_enc_info routine is implemented in lpfc_get_enc_info().
This allows encryption status to be reported through fc_remote_ports
sysfs. Debugfs is also updated to report encryption information for all
NDLP objects.
Signed-off-by: Sarah Catania <sarah.catania@broadcom.com>
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://patch.msgid.link/20251211001659.138635-3-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Introduce a new structure for reporting an encrypted session over an
fc_rport. The encryption group is added as an attribute in struct
fc_rport and reports information in fc_encryption_info. This structure
contains a status member variable, which stores a bit value indicating
an encrypted session.
Signed-off-by: Sarah Catania <sarah.catania@broadcom.com>
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://patch.msgid.link/20251211001659.138635-2-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
The function opencodes for_each_set_bit_wrap(). Use it, and while there
switch from goto-driven codeflow to more high-level constructions.
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
Reviewed-by: Justin Tee <justin.tee@broadcom.com>
Link: https://patch.msgid.link/20251205235808.358258-1-yury.norov@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
The scp pointer cannot be NULL, as it is evaluated from container_of()
and pointer offsets (so remove the check in sdebug_q_cmd_complete()).
Signed-off-by: John Garry <john.g.garry@oracle.com>
Link: https://patch.msgid.link/20251113133645.2898748-4-john.g.garry@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
sdebug_defer.defer_t
Using READ/WRITE_ONCE() means that the read or write is not torn by the
compiler.
READ/WRITE_ONCE() is always used when accessing sdebug_defer.defer_t.
However, we also guard the access in a spinlock when accessing that
member, and spinlock already guarantees no tearing, so stop using
READ/WRITE_ONCE().
Signed-off-by: John Garry <john.g.garry@oracle.com>
Link: https://patch.msgid.link/20251113133645.2898748-3-john.g.garry@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
The driver defines as follows pr_fmt:
#define pr_fmt(fmt) KBUILD_MODNAME ":%s: " fmt, __func__
...meaning that we already get the function name added in any debug
statements.
Remove using of __func__ in debug logs to avoid the duplication.
For instances of where the function name was being printed, add some
verbose comment to avoid using "" (which would be a bit silly).
It would be nicer to stop using pr_fmt(), but that would mean rewriting
approx 100 debug statements to have a sensible and clear message.
Signed-off-by: John Garry <john.g.garry@oracle.com>
Link: https://patch.msgid.link/20251113133645.2898748-2-john.g.garry@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
A race condition was found in sg_proc_debug_helper(). It was observed on
a system using an IBM LTO-9 SAS Tape Drive (ULTRIUM-TD9) and monitoring
/proc/scsi/sg/debug every second. A very large elapsed time would
sometimes appear. This is caused by two race conditions.
We reproduced the issue with an IBM ULTRIUM-HH9 tape drive on an x86_64
architecture. A patched kernel was built, and the race condition could
not be observed anymore after the application of this patch. A
reproducer C program utilising the scsi_debug module was also built by
Changhui Zhong and can be viewed here:
https://github.com/MichaelRabek/linux-tests/blob/master/drivers/scsi/sg/sg_race_trigger.c
The first race happens between the reading of hp->duration in
sg_proc_debug_helper() and request completion in sg_rq_end_io(). The
hp->duration member variable may hold either of two types of
information:
#1 - The start time of the request. This value is present while
the request is not yet finished.
#2 - The total execution time of the request (end_time - start_time).
If sg_proc_debug_helper() executes *after* the value of hp->duration was
changed from #1 to #2, but *before* srp->done is set to 1 in
sg_rq_end_io(), a fresh timestamp is taken in the else branch, and the
elapsed time (value type #2) is subtracted from a timestamp, which
cannot yield a valid elapsed time (which is a type #2 value as well).
To fix this issue, the value of hp->duration must change under the
protection of the sfp->rq_list_lock in sg_rq_end_io(). Since
sg_proc_debug_helper() takes this read lock, the change to srp->done and
srp->header.duration will happen atomically from the perspective of
sg_proc_debug_helper() and the race condition is thus eliminated.
The second race condition happens between sg_proc_debug_helper() and
sg_new_write(). Even though hp->duration is set to the current time
stamp in sg_add_request() under the write lock's protection, it gets
overwritten by a call to get_sg_io_hdr(), which calls copy_from_user()
to copy struct sg_io_hdr from userspace into kernel space. hp->duration
is set to the start time again in sg_common_write(). If
sg_proc_debug_helper() is called between these two calls, an arbitrary
value set by userspace (usually zero) is used to compute the elapsed
time.
To fix this issue, hp->duration must be set to the current timestamp
again after get_sg_io_hdr() returns successfully. A small race window
still exists between get_sg_io_hdr() and setting hp->duration, but this
window is only a few instructions wide and does not result in observable
issues in practice, as confirmed by testing.
Additionally, we fix the format specifier from %d to %u for printing
unsigned int values in sg_proc_debug_helper().
Signed-off-by: Michal Rábek <mrabek@redhat.com>
Suggested-by: Tomas Henzl <thenzl@redhat.com>
Tested-by: Changhui Zhong <czhong@redhat.com>
Reviewed-by: Ewan D. Milne <emilne@redhat.com>
Reviewed-by: John Meneghini <jmeneghi@redhat.com>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Link: https://patch.msgid.link/20251212160900.64924-1-mrabek@redhat.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
The driver was not reading the MAX_REQ_PER_REPLY_QUEUE_LIMIT IOCFacts
flag, so the reply-queue-full handling was never enabled, even on
firmware that supports it. Reading this flag enables the feature and
prevents reply queue overflow.
Fixes: f08b24d82749 ("scsi: mpi3mr: Avoid reply queue full condition")
Cc: stable@vger.kernel.org
Signed-off-by: Chandrakanth Patil <chandrakanth.patil@broadcom.com>
Link: https://patch.msgid.link/20251211002929.22071-1-chandrakanth.patil@broadcom.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Currently, ufshcd_mcq_enable_esi() manually implements a
read-modify-write sequence using ufshcd_readl() and ufshcd_writel().
It also utilizes a hardcoded magic number (0x2) for the enable bit.
Use ufshcd_rmwl() helper, replace the magic number with the
ESI_ENABLE macro to improve code readability.
No functional change intended.
Signed-off-by: vamshi gajjela <vamshigajjela@google.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/20251211133227.4159394-1-vamshigajjela@google.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
The atomic write enable module param is "atomic_wr", and not
"atomic_write", so fix the module param description.
Fixes: 84f3a3c01d70 ("scsi: scsi_debug: Atomic write support")
Signed-off-by: John Garry <john.g.garry@oracle.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/20251211100651.9056-1-john.g.garry@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Add emulation for REPORT IDENTIFYING INFORMATION command using the
configfs file 'pd_text_id_info' in target core module. The configfs file
is created in /sys/kernel/config/target/core/<backend type>/
<backing_store_name>/wwn/.
An emulation function, spc_emulate_report_id_info(), is defined to
return the identification string based on the contents of
'pd_text_id_info'.
The details of the REPORT IDENTIFYING INFORMATION command is defined in
section 6.32 of SPC4.
[mkp: checkpatch tweaks]
Signed-off-by: Gulam Mohamed <gulam.mohamed@oracle.com>
Reviewed-by: John Garry <john.g.garry@oracle.com>
Link: https://patch.msgid.link/20251201110716.227588-1-gulam.mohamed@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
If the CM ID is destroyed while the CM event for multicast creating is
still queued the cancel_work_sync() will prevent the work from running
which also prevents destroying the ah_attr. This leaks a refcount and
triggers a WARN:
GID entry ref leak for dev syz1 index 2 ref=573
WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 release_gid_table drivers/infiniband/core/cache.c:806 [inline]
WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 gid_table_release_one+0x284/0x3cc drivers/infiniband/core/cache.c:886
Destroy the ah_attr after canceling the work, it is safe to call this
twice.
Link: https://patch.msgid.link/r/0-v1-4285d070a6b2+20a-rdma_mc_gid_leak_syz_jgg@nvidia.com
Cc: stable@vger.kernel.org
Fixes: fe454dc31e84 ("RDMA/ucma: Fix use-after-free bug in ucma_create_uevent")
Reported-by: syzbot+b0da83a6c0e2e2bddbd4@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/68232e7b.050a0220.f2294.09f6.GAE@google.com
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
|
|
The netlink response for RDMA_NL_LS_OP_IP_RESOLVE should always have a
LS_NLA_TYPE_DGID attribute, it is invalid if it does not.
Use the nl parsing logic properly and call nla_parse_deprecated() to fill
the nlattrs array and then directly index that array to get the data for
the DGID. Just fail if it is NULL.
Remove the for loop searching for the nla, and squash the validation and
parsing into one function.
Fixes an uninitialized read from the stack triggered by userspace if it
does not provide the DGID to a kernel initiated RDMA_NL_LS_OP_IP_RESOLVE
query.
BUG: KMSAN: uninit-value in hex_byte_pack include/linux/hex.h:13 [inline]
BUG: KMSAN: uninit-value in ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490
hex_byte_pack include/linux/hex.h:13 [inline]
ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490
ip6_addr_string+0x18a/0x3e0 lib/vsprintf.c:1509
ip_addr_string+0x245/0xee0 lib/vsprintf.c:1633
pointer+0xc09/0x1bd0 lib/vsprintf.c:2542
vsnprintf+0xf8a/0x1bd0 lib/vsprintf.c:2930
vprintk_store+0x3ae/0x1530 kernel/printk/printk.c:2279
vprintk_emit+0x307/0xcd0 kernel/printk/printk.c:2426
vprintk_default+0x3f/0x50 kernel/printk/printk.c:2465
vprintk+0x36/0x50 kernel/printk/printk_safe.c:82
_printk+0x17e/0x1b0 kernel/printk/printk.c:2475
ib_nl_process_good_ip_rsep drivers/infiniband/core/addr.c:128 [inline]
ib_nl_handle_ip_res_resp+0x963/0x9d0 drivers/infiniband/core/addr.c:141
rdma_nl_rcv_msg drivers/infiniband/core/netlink.c:-1 [inline]
rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline]
rdma_nl_rcv+0xefa/0x11c0 drivers/infiniband/core/netlink.c:259
netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]
netlink_unicast+0xf04/0x12b0 net/netlink/af_netlink.c:1346
netlink_sendmsg+0x10b3/0x1250 net/netlink/af_netlink.c:1896
sock_sendmsg_nosec net/socket.c:714 [inline]
__sock_sendmsg+0x333/0x3d0 net/socket.c:729
____sys_sendmsg+0x7e0/0xd80 net/socket.c:2617
___sys_sendmsg+0x271/0x3b0 net/socket.c:2671
__sys_sendmsg+0x1aa/0x300 net/socket.c:2703
__compat_sys_sendmsg net/compat.c:346 [inline]
__do_compat_sys_sendmsg net/compat.c:353 [inline]
__se_compat_sys_sendmsg net/compat.c:350 [inline]
__ia32_compat_sys_sendmsg+0xa4/0x100 net/compat.c:350
ia32_sys_call+0x3f6c/0x4310 arch/x86/include/generated/asm/syscalls_32.h:371
do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]
__do_fast_syscall_32+0xb0/0x150 arch/x86/entry/syscall_32.c:306
do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331
do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:3
Link: https://patch.msgid.link/r/0-v1-3fbaef094271+2cf-rdma_op_ip_rslv_syz_jgg@nvidia.com
Cc: stable@vger.kernel.org
Fixes: ae43f8286730 ("IB/core: Add IP to GID netlink offload")
Reported-by: syzbot+938fcd548c303fe33c1a@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/r/68dc3dac.a00a0220.102ee.004f.GAE@google.com
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
|
|
Reports can be written out to the OA buffer using ways other than periodic
sampling. These include mmio trigger and context switches. To support these
use cases, when periodic sampling is not enabled,
OAG_OAGLBCTXCTRL_COUNTER_RESUME must be set.
Fixes: 1db9a9dc90ae ("drm/xe/oa: OA stream initialization (OAG)")
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Link: https://patch.msgid.link/20251205212613.826224-4-ashutosh.dixit@intel.com
|
|
Whitelist OAMERT registers to enable userspace to execute MMIO triggers on
OAMERT units. Registers are whitelisted for compute and copy class engines.
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Link: https://patch.msgid.link/20251205212613.826224-3-ashutosh.dixit@intel.com
|
|
A MERT OA unit is available in the SoC on some platforms. Add support
for this OA unit and expose it to userspace. The MERT OA unit does not
have any HW engines attached, but is otherwise similar to an OAM unit.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Link: https://patch.msgid.link/20251205212613.826224-2-ashutosh.dixit@intel.com
|
|
This is needed to access EFI variables from Linux.
Signed-off-by: Ettore Chimenti <ettore.chimenti@linaro.org>
Signed-off-by: Georg Gottleuber <ggo@tuxedocomputers.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20251204155212.230058-7-ggo@tuxedocomputers.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Fail the driver probe if the region can't be mapped
Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>
Fixes: 20bb6c9de1b7 ("soc: qcom: smem: map only partitions used by local HOST")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20251209074610.3751781-1-jorge.ramirez@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Apart from runtime PM, there is nothing in common between i2c_dw_xfer()
and amd_i2c_dw_xfer_quirk(), so give AMD NAVI controller its own algorithm
instead of calling the quirk from i2c_dw_xfer().
Add runtime PM handling to amd_i2c_dw_xfer_quirk() and a dedicated
i2c_algorithm for AMD NAVI controllers. The adapter algorithm is set
during probe based on the device model.
This way we avoid checking for the device model at the start of every
transfer.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Benoît Monin <benoit.monin@bootlin.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/20251126-i2c-dw-v4-4-b0654598e7c5@bootlin.com
|
|
Reorder the of_device_id structures so that they are in alphabetical
order. Also drop the unneeded inner trailing comma in the
"snps,designware-i2c" struct.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Benoît Monin <benoit.monin@bootlin.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/20251126-i2c-dw-v4-3-b0654598e7c5@bootlin.com
|
|
Optimize the i2c_dw_read() function by reading the message flags only
once per message, rather than for every byte.
The message flags are accessed both in the outer loop and the inner loop,
so move the declaration of the local flags variable to the outer loop.
The message index is only modified by the outer loop, so reading the
flags in the inner loop was always getting the same value.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Benoît Monin <benoit.monin@bootlin.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/20251126-i2c-dw-v4-2-b0654598e7c5@bootlin.com
|
|
Add SMBus PCI IDs on Intel Nova Lake-S.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/20251124132816.470599-1-heikki.krogerus@linux.intel.com
|
|
'i2c_types' is an enum, thus cast of pointer on 64-bit compile test with
clang and W=1 causes:
i2c-rcar.c:1144:18: error: cast to smaller integer type 'enum rcar_i2c_type' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
One of the discussions in 2023 on LKML suggested warning is not suitable
for kernel. Nothing changed in this regard since that time, so assume
the warning will stay and we want to have warnings-free builds.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/20251126182257.157439-6-krzysztof.kozlowski@oss.qualcomm.com
|
|
'i2c_types' is an enum, thus cast of pointer on 64-bit compile test with
clang and W=1 causes:
i2c-pxa.c:1269:15: error: cast to smaller integer type 'enum pxa_i2c_types' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
One of the discussions in 2023 on LKML suggested warning is not suitable
for kernel. Nothing changed in this regard since that time, so assume
the warning will stay and we want to have warnings-free builds.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/20251126182257.157439-5-krzysztof.kozlowski@oss.qualcomm.com
|
|
'type' is an enum, thus cast of pointer on 64-bit compile test with
clang and W=1 causes:
i2c-bcm-iproc.c:1102:3: error: cast to smaller integer type 'enum bcm_iproc_i2c_type' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
One of the discussions in 2023 on LKML suggested warning is not suitable
for kernel. Nothing changed in this regard since that time, so assume
the warning will stay and we want to have warnings-free builds.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/20251126182257.157439-4-krzysztof.kozlowski@oss.qualcomm.com
|
|
This was apparently accounted for in dt-bindings, but never made its
way into the driver.
Fix it for SC8280XP and its VDD_GFX-less cousin, SA8540P.
Fixes: f68f1cb3437d ("soc: qcom: rpmhpd: add sc8280xp & sa8540p rpmh power-domains")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20251202-topic-8280_mxc-v2-2-46cdf47a829e@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add system cache table(SCT) and configs for Glymur SoC
Updated the list of usecase id's to enable additional clients for Glymur
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20251211-glymur_llcc_enablement-v3-2-43457b354b0d@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
The resource name may include an address suffix, for example:
rsc-table@1fff8000.
To handle such cases, use strstarts() instead of strcmp() when checking
for "rsc-table".
Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Fixes: 67a7bc7f0358 ("remoteproc: Use of_reserved_mem_region_* functions for "memory-region"")
Link: https://lore.kernel.org/r/20251208233302.684139-1-shenwei.wang@nxp.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Now that "system" devices are represented as platform devices, they
are not claimed by the PNP ACPI scan handler any more and platform
devices can be created for ACPI device objects listing "system"
device IDs as their compatible device IDs.
Accordingly, it should not be necessary any more to add device IDs
to acpi_nonpnp_device_ids[], so drop it.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/3587570.QJadu78ljV@rafael.j.wysocki
|
|
Now that "system" devices are represented as platform devices, they
are not claimed by the PNP ACPI scan handler any more and the Intel
virtual button array platform devices should be created by the ACPI
core, so the driver does not need to attempt to create a platform
device by itself.
Accordingly, make it stop doing so.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/8661724.NyiUUSuA9g@rafael.j.wysocki
|
|
Now that "system" devices are represented as platform devices, they
are not claimed by the PNP ACPI scan handler any more and the Intel
HID platform devices should be created by the ACPI core, so the
driver does not need to attempt to create a platform device by
itself.
Accordingly, make it stop doing so.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/6115868.MhkbZ0Pkbq@rafael.j.wysocki
|
|
There is a long-standing problem with ACPI device enumeration that
if the given device has a compatible ID which is one of the generic
system resource device IDs (PNP0C01 and PNP0C02), it will be claimed
by the PNP scan handler and it will not be represented as a platform
device, so it cannot be handled by a platform driver.
Drivers have been working around this issue by "manually" creating
platform devices that they can bind to (see the Intel HID driver for
one example) or adding their device IDs to acpi_nonpnp_device_ids[].
None of the above is particularly clean though and the only reason why
the PNP0C01 and PNP0C02 device IDs are present in acpi_pnp_device_ids[]
is to allow the legacy PNP system driver to bind to those devices and
reserve their resources so they are not used going forward.
Obviously, to address this problem PNP0C01 and PNP0C02 need to be
dropped from acpi_pnp_device_ids[], but doing so without making any
other changes would be problematic because the ACPI core would then
create platform devices for the generic system resource device objects
and that would not work on all systems for two reasons. First, the
PNP system driver explicitly avoids reserving I/O resources below the
"standard PC hardware" boundary, 0x100, to avoid conflicts in that range
(one possible case when this may happen is when the CMOS RTC driver is
involved), but the platform device creation code does not do that.
Second, there may be resource conflicts between the "system" devices and
the other devices in the system, possibly including conflicts with PCI
BARs. Registering the PNP system driver via fs_initcall() helps to
manage those conflicts, even though it does not make them go away.
Resource conflicts during the registration of "motherboard resources"
that occur after PCI has claimed BARs are harmless as a rule and do
not need to be addressed in any specific way.
To overcome the issues mentioned above, use the observation that it
is not actually necessary to create any device objects in addition
to struct acpi_device ones in order to reserve the "system" device
resources because that can be done directly in the ACPI device
enumeration code.
Namely, modify acpi_default_enumeration() to add the given ACPI device
object to a special "system devices" list if its _HID is either PNP0C01
or PNP0C02 without creating a platform device for it. Next, add a new
special acpi_scan_claim_resources() function that will be run via
fs_initcall() and will walk that list and reserve resources for each
device in it along the lines of what the PNP system driver does.
Having made the above changes, drop PNP0C01 and PNP0C02 from
acpi_pnp_device_ids[] which will allow platform devices to be created
for ACPI device objects whose _CID lists contain PNP0C01 or PNP0C02,
but the _HID is not in acpi_pnp_device_ids[].
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
[ rjw: Drop a leftover comment and add a new one elsewhere ]
Link: https://patch.msgid.link/9550709.CDJkKcVGEf@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Pass character "0" rather than NULL terminator to properly format
queue restoration SMI events. Currently, the NULL terminator precedes
the newline character that is intended to delineate separate events
in the SMI event buffer, which can break userspace parsers.
Signed-off-by: Brian Kocoloski <brian.kocoloski@amd.com>
Reviewed-by: Philip Yang <Philip.Yang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 6e7143e5e6e21f9d5572e0390f7089e6d53edf3c)
|
|
User-configured SCLK(GPU core clock)frequencies were not persisting
across S0ix suspend/resume cycles on smu v14 hardware.
The issue occurred because of the code resetting clock frequency
to zero during resume.
This patch addresses the problem by:
- Preserving user-configured values in driver and sets the
clock frequency across resume
- Preserved settings are sent to the hardware during resume
Signed-off-by: mythilam <mythilam@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 20ba98326f4c69e6bf8d1f42942ece485a675b27)
|
|
Avoid a possible UAF in GPU recovery due to a race between
the sched timeout callback and the tdr work queue.
The gpu recovery function calls drm_sched_stop() and
later drm_sched_start(). drm_sched_start() restarts
the tdr queue which will eventually free the job. If
the tdr queue frees the job before time out callback
completes, the job will be freed and we'll get a UAF
when accessing the pasid. Cache it early to avoid the
UAF.
Example KASAN trace:
[ 493.058141] BUG: KASAN: slab-use-after-free in amdgpu_device_gpu_recover+0x968/0x990 [amdgpu]
[ 493.067530] Read of size 4 at addr ffff88b0ce3f794c by task kworker/u128:1/323
[ 493.074892]
[ 493.076485] CPU: 9 UID: 0 PID: 323 Comm: kworker/u128:1 Tainted: G E 6.16.0-1289896.2.zuul.bf4f11df81c1410bbe901c4373305a31 #1 PREEMPT(voluntary)
[ 493.076493] Tainted: [E]=UNSIGNED_MODULE
[ 493.076495] Hardware name: TYAN B8021G88V2HR-2T/S8021GM2NR-2T, BIOS V1.03.B10 04/01/2019
[ 493.076500] Workqueue: amdgpu-reset-dev drm_sched_job_timedout [gpu_sched]
[ 493.076512] Call Trace:
[ 493.076515] <TASK>
[ 493.076518] dump_stack_lvl+0x64/0x80
[ 493.076529] print_report+0xce/0x630
[ 493.076536] ? _raw_spin_lock_irqsave+0x86/0xd0
[ 493.076541] ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 493.076545] ? amdgpu_device_gpu_recover+0x968/0x990 [amdgpu]
[ 493.077253] kasan_report+0xb8/0xf0
[ 493.077258] ? amdgpu_device_gpu_recover+0x968/0x990 [amdgpu]
[ 493.077965] amdgpu_device_gpu_recover+0x968/0x990 [amdgpu]
[ 493.078672] ? __pfx_amdgpu_device_gpu_recover+0x10/0x10 [amdgpu]
[ 493.079378] ? amdgpu_coredump+0x1fd/0x4c0 [amdgpu]
[ 493.080111] amdgpu_job_timedout+0x642/0x1400 [amdgpu]
[ 493.080903] ? pick_task_fair+0x24e/0x330
[ 493.080910] ? __pfx_amdgpu_job_timedout+0x10/0x10 [amdgpu]
[ 493.081702] ? _raw_spin_lock+0x75/0xc0
[ 493.081708] ? __pfx__raw_spin_lock+0x10/0x10
[ 493.081712] drm_sched_job_timedout+0x1b0/0x4b0 [gpu_sched]
[ 493.081721] ? __pfx__raw_spin_lock_irq+0x10/0x10
[ 493.081725] process_one_work+0x679/0xff0
[ 493.081732] worker_thread+0x6ce/0xfd0
[ 493.081736] ? __pfx_worker_thread+0x10/0x10
[ 493.081739] kthread+0x376/0x730
[ 493.081744] ? __pfx_kthread+0x10/0x10
[ 493.081748] ? __pfx__raw_spin_lock_irq+0x10/0x10
[ 493.081751] ? __pfx_kthread+0x10/0x10
[ 493.081755] ret_from_fork+0x247/0x330
[ 493.081761] ? __pfx_kthread+0x10/0x10
[ 493.081764] ret_from_fork_asm+0x1a/0x30
[ 493.081771] </TASK>
Fixes: a72002cb181f ("drm/amdgpu: Make use of drm_wedge_task_info")
Link: https://github.com/HansKristian-Work/vkd3d-proton/pull/2670
Cc: SRINIVASAN.SHANMUGAM@amd.com
Cc: vitaly.prosyak@amd.com
Cc: christian.koenig@amd.com
Suggested-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 20880a3fd5dd7bca1a079534cf6596bda92e107d)
|
