Justin Tee <justintee8345@gmail.com> says:
Update lpfc to revision 14.4.0.10
This patch set contains bug fixes related to diagnostic log messaging,
driver initialization and removal, updates to mailbox command handling,
and string modifications for obsolete adapter model descriptions.
The patches were cut against Martin's 6.17/scsi-queue tree.
Link: https://lore.kernel.org/r/20250618192138.124116-1-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Obsolete adapters' model description strings are updated to indicate that
they are no longer supported. End-of-life adapters will still remain
probed by the lpfc driver based on PCI id.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20250618192138.124116-12-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The CQ_CREATE_SET mailbox command's bitfields are updated. Rename the
cqe_cnt and separate high/low bitfield names to help resolve confusion
between two similar bitfield definitions. Corresponding usages of the
newly defined bitfields are updated as well.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20250618192138.124116-11-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Move clearing of HBA_SETUP flag out of lpfc_sli_brdrestart_s4 and before
lpfc_sli4_queue_unset. lpfc_sli4_queue_unset kfrees phba queues, so
clear the HBA_SETUP atomic flag to signal that the phba struct is no
longer initialized.
Also, add a check for the HBA_SETUP flag in the lpfc_sli4_io_xri_aborted
routine before dereferencing the ELS WQ.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20250618192138.124116-10-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
For SLI3, the HBA_SETUP flag is never set so the lpfc_dev_loss_tmo_callbk
always early returns. Add a phba->sli_rev check for SLI4 mode so that
the SLI3 path can flow through the original dev_loss_tmo worker thread
design to lpfc_dev_loss_tmo_handler instead of early return.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20250618192138.124116-9-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Port wide initialization flags FLOGI_ISSUED and RHBA_CMPL make more sense
to be cleared upon a link down event rather than waiting for a link up
event. By moving clearing of these initializatin flags to a link down
handler, future confusion on the state of initialization is avoided.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20250618192138.124116-8-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
There are unnecessary checks on an HBA's interface type and family before
erroring out a failed lpfc_get_sli4_parameters mailbox command. Simplify
the error handling by logging a message and proceeding to memory free
labels.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20250618192138.124116-7-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
If an FDMI request completes with local reject status and the request is
not retryable, there's no need to parse an FDMI response payload. Insert
an early return statement for such cases.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20250618192138.124116-6-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
During rmmod, all ndlp objects are cleaned up and marked with the
NLP_DROPPED flag indicating that an ndlp object is currently being
released. Thus, if an RSCN is received during driver unload, then
walking the fc_nodes list to process the RSCN is unnecessary because the
ndlp objects are very shortly going to be released.
In the lpfc_rscn_recovery_check routine, early return if the driver is in
the middle of unloading by checking for the FC_UNLOADING flag.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20250618192138.124116-5-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
If a call to lpfc_sli4_read_rev() from lpfc_sli4_hba_setup() fails, the
resultant cleanup routine lpfc_sli4_vport_delete_fcp_xri_aborted() may
occur before sli4_hba.hdwqs are allocated. This may result in a null
pointer dereference when attempting to take the abts_io_buf_list_lock for
the first hardware queue. Fix by adding a null ptr check on
phba->sli4_hba.hdwq and early return because this situation means there
must have been an error during port initialization.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20250618192138.124116-4-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Initialization parameters for trace rings used in debugfs are sometimes
automatically adjusted. This patch corrects and updates the
corresponding log messages.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20250618192138.124116-3-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Unsupported and rejected CT MIB request log messages are changed to
KERN_WARNING level. Also, remove extra space in log message.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20250618192138.124116-2-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
With the ATA error model, an NCQ command failure always triggers an abort
(termination) of all NCQ commands queued on the device. In such case, the
SAT or the host must handle the failed command according to the command
sense data and immediately retry all other NCQ commands that were aborted
due to the failed NCQ command.
For SAS HBAs controlled by the mpt3sas driver, NCQ command aborts are not
handled by the HBA SAT and sent back to the host, with an ioc log
information equal to 0x31080000 (IOC_LOGINFO_PREFIX_PL with the PL code
PL_LOGINFO_CODE_SATA_NCQ_FAIL_ALL_CMDS_AFTR_ERR). The function
_scsih_io_done() always forces a retry of commands terminated with the
status MPI2_IOCSTATUS_SCSI_IOC_TERMINATED using the SCSI result
DID_SOFT_ERROR, regardless of the log_info for the command. This
correctly forces the retry of collateral NCQ abort commands, but with the
retry counter for the command being incremented. If a command to an ATA
device is subject to too many retries due to other NCQ commands failing
(e.g. read commands trying to access unreadable sectors), the collateral
NCQ abort commands may be terminated with an error as they run out of
retries. This violates the SAT specification and causes hard-to-debug
command errors.
Solve this issue by modifying the handling of the
MPI2_IOCSTATUS_SCSI_IOC_TERMINATED status to check if a command is for an
ATA device and if the command loginfo indicates an NCQ collateral
abort. If that is the case, force the command retry using the SCSI result
DID_IMM_RETRY to avoid incrementing the command retry count.
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Link: https://lore.kernel.org/r/20250606052747.742998-3-dlemoal@kernel.org
Tested-by: Yafang Shao <laoar.shao@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
With the ATA error model, an NCQ command failure always triggers an abort
(termination) of all NCQ commands queued on the device. In such case, the
SAT or the host must handle the failed command according to the command
sense data and immediately retry all other NCQ commands that were aborted
due to the failed NCQ command.
For SAS HBAs controlled by the mpi3mr driver, NCQ command aborts are not
handled by the HBA SAT and sent back to the host, with an ioc log
information equal to 0x31080000 (IOC_LOGINFO_PREFIX_PL with the PL code
PL_LOGINFO_CODE_SATA_NCQ_FAIL_ALL_CMDS_AFTR_ERR). The function
mpi3mr_process_op_reply_desc() always forces a retry of commands
terminated with the status MPI3_IOCSTATUS_SCSI_IOC_TERMINATED using the
SCSI result DID_SOFT_ERROR, regardless of the ioc_loginfo for the
command. This correctly forces the retry of collateral NCQ abort
commands, but with the retry counter for the command being incremented.
If a command to an ATA device is subject to too many retries due to other
NCQ commands failing (e.g. read commands trying to access unreadable
sectors), the collateral NCQ abort commands may be terminated with an
error as they run out of retries. This violates the SAT specification and
causes hard-to-debug command errors.
Solve this issue by modifying the handling of the
MPI3_IOCSTATUS_SCSI_IOC_TERMINATED status to check if a command is for an
ATA device and if the command ioc_loginfo indicates an NCQ collateral
abort. If that is the case, force the command retry using the SCSI result
DID_IMM_RETRY to avoid incrementing the command retry count.
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Link: https://lore.kernel.org/r/20250606052747.742998-2-dlemoal@kernel.org
Tested-by: Yafang Shao <laoar.shao@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This change frees resources after an error is detected.
Signed-off-by: Francisco Gutierrez <frankramirez@google.com>
Link: https://lore.kernel.org/r/20250617210443.989058-1-frankramirez@google.com
Acked-by: Jack Wang <jinpu.wang@ionos.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Previously, the response buffer (ucd_rsp_ptr) was cleared in multiple
UPIU preparation functions. Do it once.
Signed-off-by: Avri Altman <avri.altman@sandisk.com>
Link: https://lore.kernel.org/r/20250617095611.89229-2-avri.altman@sandisk.com
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
In the past %pK was preferable to %p as it would not leak raw pointer
values into the kernel log. Since commit ad67b74d24 ("printk: hash
addresses printed with %p") the regular %p has been improved to avoid
this issue. Furthermore, restricted pointers ("%pK") were never meant to
be used through printk(). They can still unintentionally leak raw
pointers or acquire sleeping locks in atomic contexts.
Switch to the regular pointer formatting which is safer and easier to
reason about.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Link: https://lore.kernel.org/r/20250611-restricted-pointers-scsi-v1-1-fe31bfbc4910@linutronix.de
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
scsi_add_lun() tests the device vendor string of SCSI devices to detect
if a SCSI device is in fact an ATA device, in order to correctly handle
SATL power management. The function scsi_cdl_enable() also requires
knowing if a SCSI device is an ATA device to control the state of the
device CDL feature but this function does that by testing for the
presence of the VPD page 89h (ATA INFORMATION page).
sd_read_write_same() also has a similar test.
Simplify these different methods by adding the is_ata field to struct
scsi_device to remember that a SCSI device is in fact an ATA one based
on the device vendor name test. This field can also allow low level
SCSI host adapter drivers to take special actions for ATA devices
(e.g. to better handle ATA NCQ errors).
With this, simplify scsi_cdl_enable() and sd_read_write_same().
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Link: https://lore.kernel.org/r/20250611093421.2901633-1-dlemoal@kernel.org
Reviewed-by: Igor Pylypiv <ipylypiv@google.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
With W=1, gcc complains correctly:
mpt3sas_ctl.c: In function ‘mpt3sas_send_mctp_passthru_req’:
mpt3sas_ctl.c:2917:29: error: variable ‘mpi_reply’ set but not used [-Werror=unused-but-set-variable]
2917 | MPI2DefaultReply_t *mpi_reply;
| ^~~~~~~~~
Drop the unused assignment and variable.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://lore.kernel.org/r/20250606-mpt3sas-v1-1-906ffe49fb6b@linaro.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
By default the scsi_dispatch_cmd_error() return value is displayed in
decimal:
kworker/3:1H-183 [003] .... 51.035474: scsi_dispatch_cmd_error: host_no=0 channel=0 id=0 lun=4 data_sgl=1 prot_sgl=0 prot_op=SCSI_PROT_NORMAL cmnd=(READ_10 lba=3907214 txlen=1 protect=0 raw=28 00 00 3b 9e 8e 00 00 01 00) rtn=4181
However, these numbers are not particularly helpful wrt. debugging
errors. Especially since the kernel code consistently uses the following
defines in hexadecimal:
SCSI_MLQUEUE_HOST_BUSY 0x1055
SCSI_MLQUEUE_DEVICE_BUSY 0x1056
SCSI_MLQUEUE_EH_RETRY 0x1057
SCSI_MLQUEUE_TARGET_BUSY 0x1058
Switch to using the string form of these values in the trace output:
dd-1059 [007] ..... 31.689529: scsi_dispatch_cmd_error: host_no=0 channel=0 id=0 lun=4 data_sgl=65 prot_sgl=0 prot_op=SCSI_PROT_NORMAL driver_tag=23 scheduler_tag=117 cmnd=(READ_10 lba=0 txlen=128 protect=0 raw=28 00 00 00 00 00 00 00 80 00) rtn=SCSI_MLQUEUE_DEVICE_BUSY
Signed-off-by: Kassey Li <quic_yingangl@quicinc.com>
Link: https://lore.kernel.org/r/20250521011711.1983625-1-quic_yingangl@quicinc.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Follow JESD220G, support HID(Host Initiated Defragmentation) through
sysfs, the relevant sysfs nodes are as follows:
1. analysis_trigger
2. defrag_trigger
3. fragmented_size
4. defrag_size
5. progress_ratio
6. state
The detailed definition of the six nodes can be found in the sysfs
documentation.
HID's execution policy is given to user-space.
Signed-off-by: Huan Tang <tanghuan@vivo.com>
Signed-off-by: Wenxing Cheng <wenxing.cheng@vivo.com>
Link: https://lore.kernel.org/r/20250523064604.800-1-tanghuan@vivo.com
Suggested-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
Reviewed-by: Bean Huo <huobean@gmail.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Yangtao Li <frank.li@vivo.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This patch updates the scsi_fc_transport.rst documentation by replacing
the outdated << To Be Supplied >> placeholder under the "FC Remote Ports
(rports)" section with a detailed explanation of remote port
functionality in the Fibre Channel (FC) transport class.
The new documentation covers:
- What rports are and their role in FC-based SCSI communication
- Their representation in sysfs (/sys/class/fc_remote_ports/)
- Common sysfs attributes such as (port_id, port_name, node_name, and
port_state).
- Their typical lifecycle (creation and removal)
- Guidance for driver developers on using fc_remote_port_add() and
fc_remote_port_delete()
This change improves the completeness and usefulness of the FC transport
documentation for developers and users interacting with Fibre Channel
drivers in the Linux SCSI subsystem
Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
Link: https://lore.kernel.org/r/20250607162304.1765430-1-alok.a.tiwari@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The function fcoe_select_cpu() is just used to distribute incoming skbs
which start a new FC command sequence. But the network stack already
received (and processed) that skb, and there is a _really_ good chance
that all subsequent skbs for this sequence will be handled with the same
CPU. So we should just use the CPU on which this skb was allocated on and
save ourselves some overhead due to pointless scheduling.
Signed-off-by: Hannes Reinecke <hare@kernel.org>
Link: https://lore.kernel.org/r/20250605062014.105302-1-hare@kernel.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The renaming to the timer_*() namespace was delayed due massive conflicts
against Linux-next. Now that everything is upstream finish the conversion.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCgAxFiEEQp8+kY+LLUocC4bMphj1TA10mKEFAmhFOY0THHRnbHhAbGlu
dXRyb25peC5kZQAKCRCmGPVMDXSYoRw8D/9ii/hq8jKguupde3UNVsdqICggO7bY
8PIY8FjZB2z3ALGOML9Pf1yystwnz1wbda9UhgGkKGj2iWvG0wWiN56J6FpksuIn
08poxMXUsLu7Wu6DaQkQrDwJ2Wu4EMefsxf6YtY/dGLLe553Bh5FHBLr75PO3d1j
AZNjGXysowzBBr//oSQuP8/MTVXd9KWvPSFPMn9oJZlkFVUbB0a6imjy10tDFC5s
uLUXwyPhsJvU6lj+B41H1hTNIoTBZexJgRgl1PhuNrN/5FLcUAPUVKbyLo+cCrqt
iB8WRw7fJu2CaKnSfRIWmi4kSeUP2d4H8oC/W4xymQtzvKNW6l0RIETg40FYqDAs
wucMBc5FmLzOBnUyoWDpn34NxOND5sHWd42yPHpxowmLWIZ2wAbSR/AHGA9vkmXa
Ksh8elyTR3swO9PRalrSsg3vM8KhH2RBXDotVFKBGmkay4WkW0TzTyjVDVZd1+bH
XxGO4PZWOXYcoQ840ocb1UMHdfEZivuaWrY4j5HWzsK/3No5f9ECJ9Dd5p/u6Ju7
FDmhrhovqKgLGnqo3MBmOeI1zSBsQuqPpRxUG1/gHVl4CYFwhcOU8pk0064ZSN9Q
RasjoJEghSlwKf4FEHJN9Z3+izoMntZGB3aUG+MXfxbBNJkHmO8/Tb4AwVQ6HyhT
+xF2fwKHwHyIbw==
=jJaU
-----END PGP SIGNATURE-----
Merge tag 'timers-cleanups-2025-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull timer cleanup from Thomas Gleixner:
"The delayed from_timer() API cleanup:
The renaming to the timer_*() namespace was delayed due massive
conflicts against Linux-next. Now that everything is upstream finish
the conversion"
* tag 'timers-cleanups-2025-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
treewide, timers: Rename from_timer() to timer_container_of()
- Cure IO bitmap inconsistencies
A failed fork cleans up all resources of the newly created thread via
exit_thread(). exit_thread() invokes io_bitmap_exit() which does the IO
bitmap cleanups, which unfortunately assume that the cleanup is related
to the current task, which is obviously bogus. Make it work correctly
- A lockdep fix in the resctrl code removed the clearing of the command
buffer in two places, which keeps stale error messages around. Bring
them back.
- Remove unused trace events
-----BEGIN PGP SIGNATURE-----
iQJHBAABCgAxFiEEQp8+kY+LLUocC4bMphj1TA10mKEFAmhFO0MTHHRnbHhAbGlu
dXRyb25peC5kZQAKCRCmGPVMDXSYoZYqEADAB+3WsgT9WZlGfksOgcL05uD0sGKP
mrGkrVuyGLQaMK+Vv7F3Vll0khe3nMJ1DzOOdmejerzEi2yb7CaZHIT1esujVHAk
kieR/D7t5zUvPislBSUxgsmNjqwoCDAwe5vKTSM0p20T7CWkenAzCcA4cUFQfGWo
2TqJWLDgdlvOk6qnaUTm0tzGjeYD9PegoUEyz5wgrf+YjsiKIWJLRbDMb3tXsOpy
La2vh2APV6Tt/PMalQiedQdi3VAf5yD+3HpvlXJ6b1BhJy3iPO6iMQPp1kwsKFjm
dzFT0IqM7lOERjMbhhnntLWe9z0vyezwIEj6dPlCf6MG8lTJ3io0bWJ2LwQEzt3q
RkFJO7wc7QqJoIGsZARGREA99Zkh6/qTh8QovbjpHWoQBrMIZ9mxw9gJ6QR/vjNa
dVhIEi4mOBNw+bq4BmYExC8j60qpGBrEi+lJrGWZoEBWHqhUY3I38DU1oH97mn/s
qL1iZo1TOGyxGuHIN79fKWduEpY+tyvhLxB2zW5m9+B26XRXZBec1lZ+qfIpPo/f
ZuWIbNYsKKPgpHZLSb21RJ/ost+sTr4iEb3XuguP+YAxfjOVJR7CAhsfWRTDNhPS
wGiyPAGmdbQrx/2Wn4vZnznOm/OH4aQX5cxbNR8TPknHJzYRmIY3VTDjDr8Xqxx+
R4/IRQOmcJ0Q/Q==
=x7j0
-----END PGP SIGNATURE-----
Merge tag 'x86-urgent-2025-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Thomas Gleixner:
"A small set of x86 fixes:
- Cure IO bitmap inconsistencies
A failed fork cleans up all resources of the newly created thread
via exit_thread(). exit_thread() invokes io_bitmap_exit() which
does the IO bitmap cleanups, which unfortunately assume that the
cleanup is related to the current task, which is obviously bogus.
Make it work correctly
- A lockdep fix in the resctrl code removed the clearing of the
command buffer in two places, which keeps stale error messages
around. Bring them back.
- Remove unused trace events"
* tag 'x86-urgent-2025-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
fs/resctrl: Restore the rdt_last_cmd_clear() calls after acquiring rdtgroup_mutex
x86/iopl: Cure TIF_IO_BITMAP inconsistencies
x86/fpu: Remove unused trace events
Add initial DMR support, which required smarter RAPL probe
Fix AMD MSR RAPL energy reporting
Add RAPL power limit configuration output
Minor fixes
Signed-off-by: Len Brown <len.brown@intel.com>
For the RAPL package energy status counter, Intel and AMD share the same
perf_subsys and perf_name, but with different MSR addresses.
Both rapl_counter_arch_infos[0] and rapl_counter_arch_infos[1] are
introduced to describe this counter for different Vendors.
As a result, the perf counter is probed twice, and causes a failure in
in get_rapl_counters() because expected_read_size and actual_read_size
don't match.
Fix the problem by skipping the already probed counter.
Note, this is not a perfect fix. For example, if different
vendors/platforms use the same MSR value for different purpose, the code
can be fooled when it probes a rapl_counter_arch_infos[] entry that does
not belong to the running Vendor/Platform.
In a long run, better to put rapl_counter_arch_infos[] into the
platform_features so that this becomes Vendor/Platform specific.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
platform_features->rapl_msrs describes the RAPL MSRs supported. While
RAPL Perf counters can be exposed from different kernel backend drivers,
e.g. RAPL MSR I/F driver, or RAPL TPMI I/F driver.
Thus, turbostat should first blindly probe all the available RAPL Perf
counters, and falls back to the RAPL MSR counters if they are listed in
platform_features->rapl_msrs.
With this, platforms that don't have RAPL MSRs can clear the
platform_features->rapl_msrs bits and use RAPL Perf counters only.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Increase the code readability by moving the no_perf/no_msr flag and the
cai->perf_name/cai->msr sanity checks into the counter probe functions.
No functional change.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
probe_rapl_msr() is reused for probing RAPL MSR counters, cstate MSR
counters and MPERF/APERF/SMI MSR counters, thus its name is misleading.
Similar to add_perf_counter(), introduce add_msr_counter() to probe a
counter via MSR. Introduce wrapper function add_rapl_msr_counter() at
the same time to add extra check for Zero return value for specified
RAPL counters.
No functional change intended.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
As the only caller of add_msr_perf_counter_(), add_msr_perf_counter()
just gives extra debug output on top. There is no need to keep both
functions.
Remove add_msr_perf_counter_() and move all the logic to
add_msr_perf_counter().
No functional change.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
As the only caller of add_cstate_perf_counter_(),
add_cstate_perf_counter() just gives extra debug output on top. There is
no need to keep both functions.
Remove add_cstate_perf_counter_() and move all the logic to
add_cstate_perf_counter().
No functional change.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
As the only caller of add_rapl_perf_counter_(), add_rapl_perf_counter()
just gives extra debug output on top. There is no need to keep both
functions.
Remove add_rapl_perf_counter_() and move all the logic to
add_rapl_perf_counter().
No functional change.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Quit early for unsupported RAPL counters.
No functional change.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
rapl_joules bit should always be checked even if
platform_features->rapl_msrs is not set or no_msr flag is used.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
commit 05a2f07db8 ("tools/power turbostat: read RAPL counters via
perf") that adds support to read RAPL counters via perf defines the
notion of a RAPL domain_id which is set to physical_core_id on
platforms which support per_core_rapl counters (Eg: AMD processors
Family 17h onwards) and is set to the physical_package_id on all the
other platforms.
However, the physical_core_id is only unique within a package and on
platforms with multiple packages more than one core can have the same
physical_core_id and thus the same domain_id. (For eg, the first cores
of each package have the physical_core_id = 0). This results in all
these cores with the same physical_core_id using the same entry in the
rapl_counter_info_perdomain[]. Since rapl_perf_init() skips the
perf-initialization for cores whose domain_ids have already been
visited, cores that have the same physical_core_id always read the
perf file corresponding to the physical_core_id of the first package
and thus the package-energy is incorrectly reported to be the same
value for different packages.
Note: This issue only arises when RAPL counters are read via perf and
not when they are read via MSRs since in the latter case the MSRs are
read separately on each core.
Fix this issue by associating each CPU with rapl_core_id which is
unique across all the packages in the system.
Fixes: 05a2f07db8 ("tools/power turbostat: read RAPL counters via perf")
Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Fix typo in the currently unused RAPL_GFX_ALL macro definition.
Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
It uses /dev/msrN device paths on Android instead of /dev/cpu/N/msr,
updates error messages and permission checks to reflect the Android
device path, and wraps platform-specific code with #if defined(ANDROID)
to ensure correct behavior on both Android and non-Android systems.
These changes improve compatibility and usability of turbostat on
Android devices.
Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The MSR offset calculations for fixed performance counters are stored at
the wrong index in the configuration array causing the general purpose
counter MSR offset to be overwritten, so both the general purpose and the
fixed counters offsets are incorrect. Correct the array index calculation
to fix that.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCgAxFiEEQp8+kY+LLUocC4bMphj1TA10mKEFAmhFOSQTHHRnbHhAbGlu
dXRyb25peC5kZQAKCRCmGPVMDXSYoSGFD/0WsH6ri5lu7ClOvZY0/IynV8mWsqmZ
PHEzdU+htBMPnOKQAlhPvy91G8yLHlIkyATup0t3P4uRzWu0hHShuZvl30HL8pg2
XlbPgGS3ZPekRLH1V3R+xCFVucs6IYv3Et/slbt8gWYjgXD82jZYbJRZSfYhGGKI
kKpHPi+zsFLGeel2RUunUCqAM04Z2+/p2sIbFmYfSHtsi422dOsqjIsZQfYUO+hD
oDVyhAlpmGV5+kww/kOS7+9tneLVOhxFyPxBn/6f6gT4yKuqAoHkp82tMKvqkZPt
xvx+ruajzZotaZiVJm4Wvi6rb9RPOKBy9EDvk77jeVmncescnShx6yRmdJLPT9DC
VRjPikrWnTo8yg3N0N5QoAUEWuVOCHpSWR4dbVLiTNjHlQSr2n8hrI4I4L1AwLgJ
r0HwKLXZzYzLI8YBmg1CD5V5gnW8eOE2R2yfzpxIiefyzZHJ4pAT5KgOTggT3c9X
lyoqOSMwfmH2elh4quZbfOPg7/bWRxb1Cx6HLslySYPUudDSP/W/KEIKFsApEC/v
u7okDC/EGbiyyfJxa7G9Hl66Aer74SWo/hRND6RqffNk3heQ3xvkpk7W4K/lJV3m
OA5AXsDBx0IacoaINrZ5HX5PLS9VoKCiSJXG3k/LNV15rLB5Ohco+/mf6ce0gRG2
5p0JHuUlDc8PKA==
=P3Rq
-----END PGP SIGNATURE-----
Merge tag 'perf-urgent-2025-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 perf fix from Thomas Gleixner:
"A single fix for the x86 performance counters on Intel CPUs:
The MSR offset calculations for fixed performance counters are stored
at the wrong index in the configuration array causing the general
purpose counter MSR offset to be overwritten, so both the general
purpose and the fixed counters offsets are incorrect.
Correct the array index calculation to fix that"
* tag 'perf-urgent-2025-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf/x86/intel: Fix incorrect MSR index calculations in intel_pmu_config_acr()
The conversion to per device MSI domains created a MSI domain with size 1
instead of sizing it to the maximum possible number of MSI interrupts for
the device. This "worked" as the subsequent allocations resized the
domain, but the recent change to move the prepare() call into the domain
creation path broke this works by chance mechanism. Size the domain
properly at creation time.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCgAxFiEEQp8+kY+LLUocC4bMphj1TA10mKEFAmhFOE0THHRnbHhAbGlu
dXRyb25peC5kZQAKCRCmGPVMDXSYoYfnEACmXJTgWGKPwu8mnGH0hV0NxRMSeMbB
vg3mAkFkeKoKADm7oElRrQbdnwmVIvUcMnmFrQBItBnIlsPBVVC+lxxjTeCS6oFf
gB46SzwBv/IqYK+0M1kw+umyF4oaxXjwR498OV0AmQBLZ0344sJXVbKKqR7KFoB8
xypGMPN5IkCw13ApgdHINmMohSajLiQLOnAMyxYQ+cR61de/zcwaOuuv/xgg2NRW
Eu4RPlXcQq1KSETP60jYTkuXMPvtzD1okvewv6/m6DNj9YJxbKoDaCVP/8O6fqDi
XsGUiQXmAA+4GgyTqYLqpKlQ1qsbgrj0nIyDRp3npdq/WzOWp1zlCZJ7CrIurDme
KEtDdEJocgnJ0kOxwJBJUD6FKm8CnyvWIzDzldA+OfDcOfs3CSejfpDS/UfYweUI
dFCbznumypnioUbtXDCpG4mqB/jN4ccv6TdGMxM/9FOdzJqGY06EAyh6qppfxGen
QecnAzCml3RXzbBf8my5h3k0wcjOdljAVBT/l1isPWkZLSSUgg7M9wFkeF0O43eO
Y+AbYu6N1Axe6IWdrbvcyPfiTvjMBl7iD7ovrRrVLCMfKqXxjnmJBLcQzLhmWBJ5
A/4P2+oSpunvwjf7NMQXCYCH4ma8xyk6HkHS3BGsdHCIBMmrKpV2ViaXr728lmw6
uJoArqvYpmDXZQ==
=G1bH
-----END PGP SIGNATURE-----
Merge tag 'irq-urgent-2025-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull irq fix from Thomas Gleixner:
"A single fix for the PCI/MSI code:
The conversion to per device MSI domains created a MSI domain with
size 1 instead of sizing it to the maximum possible number of MSI
interrupts for the device. This "worked" as the subsequent allocations
resized the domain, but the recent change to move the prepare() call
into the domain creation path broke this works by chance mechanism.
Size the domain properly at creation time"
* tag 'irq-urgent-2025-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
PCI/MSI: Size device MSI domain with the maximum number of vectors
