[Why]
To debug when p-state is being blocked and avoid PMFW hangs when
it does occur.
[How]
Re-use the DCN10 hardware sequencer by adding a new interface for
verifying p-state high on the hubbub. The interface is mostly the
same as the DCN10 interface, but the bit definitions have changed for
the debug bus.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Eric Yang <Eric.Yang2@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
So apply the quirk, and make it the last one since it's an LED quirk.
Fixes: 07bcab93946c ("ALSA: hda/realtek: Add support for HP Laptops") Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Link: https://lore.kernel.org/r/20220324062159.241313-1-kai.heng.feng@canonical.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit ce18f905a500879e86ca998963a55f99d413a462) Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
drm/amdgpu: Ensure HDA function is suspended before ASIC reset
BugLink: https://bugs.launchpad.net/bugs/1968475
DP/HDMI audio on AMD PRO VII stops working after S3:
[ 149.450391] amdgpu 0000:63:00.0: amdgpu: MODE1 reset
[ 149.450395] amdgpu 0000:63:00.0: amdgpu: GPU mode1 reset
[ 149.450494] amdgpu 0000:63:00.0: amdgpu: GPU psp mode1 reset
[ 149.983693] snd_hda_intel 0000:63:00.1: refused to change power state from D0 to D3hot
[ 150.003439] amdgpu 0000:63:00.0: refused to change power state from D0 to D3hot
...
[ 155.432975] snd_hda_intel 0000:63:00.1: CORB reset timeout#2, CORBRP = 65535
The offending commit is daf8de0874ab5b ("drm/amdgpu: always reset the asic in
suspend (v2)"). Commit 34452ac3038a7 ("drm/amdgpu: don't use BACO for
reset in S3 ") doesn't help, so the issue is something different.
Assuming that to make HDA resume to D0 fully realized, it needs to be
successfully put to D3 first. And this guesswork proves working, by
moving amdgpu_asic_reset() to noirq callback, so it's called after HDA
function is in D3.
Fixes: daf8de0874ab5b ("drm/amdgpu: always reset the asic in suspend (v2)") Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 9e051720f9d37ef6f878a6106478c82fb9b375d1 linux-next) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit eac4c54bf7f17fb4681b85e5fe383b74d6261a2b) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1967116
Fix the following warning by not allocating driver's event handling worker
queue with WQ_MEM_RECLAIM flag enabled:
workqueue: WQ_MEM_RECLAIM
mpi3mr_fwevt_worker [mpi3mr] is flushing !WQ_MEM_RECLAIM events
Link: https://lore.kernel.org/r/20220218180515.27455-1-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 334ae6459aa38acf95ca43ae7fb7941b19556e16 linux-next) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Link: https://lore.kernel.org/r/20220210095817.22828-10-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 22754f7fbb4030eb2d5e73c2a2db63637ed1d105 linux-next) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Link: https://lore.kernel.org/r/20220210095817.22828-8-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 21401408ddebf4abdb556d3760603f3516f6fff0 linux-next) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Sreekanth Reddy [Thu, 10 Feb 2022 09:58:13 +0000 (15:28 +0530)]
scsi: mpi3mr: Fix cmnd getting marked as in use forever
BugLink: https://bugs.launchpad.net/bugs/1967116
When a driver command which requires the driver to issue a follow up
command using the same command frame is outstanding and a soft reset
operation occurs, then that driver command frame is getting marked as in
use permanently and won't be reused again.
Clear the driver command frames while flushing out the outstanding commands
and avoid issuing any new requests using these command frames while soft
reset is going on.
Link: https://lore.kernel.org/r/20220210095817.22828-6-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit b3911ab3a76e216cd97c6fdc05132e57c3e6941c linux-next) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Sreekanth Reddy [Thu, 10 Feb 2022 09:58:12 +0000 (15:28 +0530)]
scsi: mpi3mr: Fix hibernation issue
BugLink: https://bugs.launchpad.net/bugs/1967116
Hibernation operation fails when it is issued for second time. This is
because the driver is trying to release the IOC's PCI resources after
setting power state to D3.
Set the IOC's power state to D3 only after releasing the IOC's PCI
resources.
Link: https://lore.kernel.org/r/20220210095817.22828-5-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 191a3ef586344acc35ba5619d6225858250aaee5 linux-next) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Link: https://lore.kernel.org/r/20220210095817.22828-4-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 04b27e538d509f4b8947343bdf6b1421dc721f14 linux-next) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Link: https://lore.kernel.org/r/20220210095817.22828-3-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 6d211f1d2635d3c6285b9b69523380d03ad876ce linux-next) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Sreekanth Reddy [Thu, 10 Feb 2022 09:58:09 +0000 (15:28 +0530)]
scsi: mpi3mr: Fix deadlock while canceling the fw event
BugLink: https://bugs.launchpad.net/bugs/1967116
During controller reset, the driver tries to flush all the pending firmware
event works from worker queue that are queued prior to the reset. However,
if any work is waiting for device addition/removal operation to be
completed at the SML, then a deadlock is observed. This is due to the
controller reset waiting for the device addition/removal to be completed
and the device/addition removal is waiting for the controller reset to be
completed.
To limit this deadlock, continue with the controller reset handling without
canceling the work which is waiting for device addition/removal operation
to complete at SML.
Link: https://lore.kernel.org/r/20220210095817.22828-2-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 580e6742205efe6b0bfa5a6a6079f509d99168e0 linux-next) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
drivers/scsi/mpi3mr/mpi3mr_fw.c:2188: warning: Function parameter or
member 'reason_code' not described in 'mpi3mr_check_rh_fault_ioc'
drivers/scsi/mpi3mr/mpi3mr_fw.c:3650: warning: Excess function parameter
'init_type' description in 'mpi3mr_init_ioc'
drivers/scsi/mpi3mr/mpi3mr_fw.c:4177: warning: bad line
Link: https://lore.kernel.org/r/20211231082350.19315-1-yang.lee@linux.alibaba.com Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 3bb3c24e268ab64305eec670be253eef2238b013) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Link: https://lore.kernel.org/r/20211224175240.1348942-1-colin.i.king@gmail.com Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 5867b8569e6480d3926b0508ee896532c59fde32) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Link: https://lore.kernel.org/r/20211220141159.16117-26-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit c77b1f8a8faeeba43c694d9d09d0b25a4f52cf37) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Sreekanth Reddy [Mon, 20 Dec 2021 14:11:57 +0000 (19:41 +0530)]
scsi: mpi3mr: Enhanced Task Management Support Reply handling
BugLink: https://bugs.launchpad.net/bugs/1967116
Enhance driver to consider MPI3_IOCSTATUS_SCSI_IOC_TERMINATED as a success
for TMs issued by it and check the pending I/Os to decide the success or
failure of the task management requests instead of just considering the
MPI3_IOCSTATUS_SCSI_IOC_TERMINATED as a failure of the task management
request.
Link: https://lore.kernel.org/r/20211220141159.16117-24-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit a91603a5d504a81b5760aa4e25a46676a41395fc) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Link: https://lore.kernel.org/r/20211220141159.16117-23-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit c86651345ca55be6670faffa4aba104616461243) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
This feature is disabled in the driver by default. To enable the feature, a
module parameter "poll_queues" has to be set with the desired number of
polling queues.
When the feature is enabled, the driver reserves a certain number of
operational queue pairs for the poll_queues either from the available queue
pairs or creates additional queue pairs based on the operational queue
availability.
The Polling queues will have corresponding IRQ and ISR functions as similar
to default queues. However, the IRQ line is disabled by the driver for
poll_queues.
Link: https://lore.kernel.org/r/20211220141159.16117-22-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit afd3a5793fe2a217513bc5eb2228a5ca8e8b556a) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Use vendor id & device id macro definitions from MPI3 headers.
Link: https://lore.kernel.org/r/20211220141159.16117-21-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 95cca8d5542a4cde0d3dd685f4108295ca28b63d) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Sreekanth Reddy [Mon, 20 Dec 2021 14:11:53 +0000 (19:41 +0530)]
scsi: mpi3mr: Support Prepare for Reset event
BugLink: https://bugs.launchpad.net/bugs/1967116
The IOC sends a Prepare for Reset Event to the host to prepare for a Soft
Reset. This event data has two reason codes:
1. Start - The host is expected to gracefully quiesce all I/O within
approximately 1 second.
2. Abort - The IOC is requesting to abort a previous Prepare for Reset
Event request. Normal I/O may be resumed.
Link: https://lore.kernel.org/r/20211220141159.16117-20-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 78b76a0768ef8a25ab92a28da4ac9a74db762c47) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Link: https://lore.kernel.org/r/20211220141159.16117-19-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit c1af985d27da2d530c22604644e9025810f57d7c) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1967116
Enhance driver to gracefully handle discrepancies in certain key data sizes
between firmware update operations as mentioned below:
- The driver displays an error message and marks the controller as
unrecoverable if the firmware reports ReplyFrameSize that is greater
than the current ReplyFrameSize.
- If the firmware reports ReplyFrameSize greater than the current
ReplyFrameSize then the driver uses the current ReplyFrameSize while
copying the reply messages.
- The driver displays an error message and marks the controller as
unrecoverable if the firmware reports MaxOperationalReplyQueues less
than the currently allocated operational reply queues count.
- If the firmware reports MaxOperationalReplyQueues that is greater than
the currently allocated operational reply queue count then the driver
ignores the new increased value and uses the previously allocated number
of operational queues only.
- If the firmware reports MaxDevHandle greater than the previously used
MaxDevHandle value after a reset then the driver re-allocates the
'device remove pending bitmap' buffer with the newer size using
krealloc().
Link: https://lore.kernel.org/r/20211220141159.16117-18-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit c5758fc72b9256aae85f5565f5715a3798d337e0) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Sreekanth Reddy [Mon, 20 Dec 2021 14:11:50 +0000 (19:41 +0530)]
scsi: mpi3mr: Detect async reset that occurred in firmware
BugLink: https://bugs.launchpad.net/bugs/1967116
Detect asynchronous reset that occurred in the firmware by polling for
reset history bit of IOC status register is set and if that bit is set,
then the driver waits for the controller to become ready and then
re-initializes the controller.
Also reduce the time driver is waiting for the controller to acknowledge
the reset action after issuing a specific reset action to the
controller. The wait time is reduced from 510 seconds to 30 seconds. If the
controller didn't acknowledge a specific reset action within the time
interval then the driver marks the controller as unrecoverable instead of
retrying two more times prior to giving up.
Link: https://lore.kernel.org/r/20211220141159.16117-17-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit b64845a7d4039ab9667bafff9d7bb59365f17c0f) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Link: https://lore.kernel.org/r/20211220141159.16117-16-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit c0b00a931e5e5fc143ed5563389ef72e40de9814) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Sreekanth Reddy [Mon, 20 Dec 2021 14:11:48 +0000 (19:41 +0530)]
scsi: mpi3mr: Handle offline FW activation in graceful manner
BugLink: https://bugs.launchpad.net/bugs/1967116
Currently the driver marks the controller as unrecoverable if there is an
asynchronous reset or fault during the initialization, reinitialization
post reset, and OS resume.
Enhance driver to retry the initialization, re-initialization, and resume
sequences for a maximum of 3 times if the controller became faulty or
asynchronously reset due to a firmware activation during the initialization
sequence.
Link: https://lore.kernel.org/r/20211220141159.16117-15-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit fe6db615156573d3f6a37564b8a590cb03bbaf25) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Link: https://lore.kernel.org/r/20211220141159.16117-14-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 59bd9cfe3fa07234e34cc2406e97481b3398c2d6) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Sreekanth Reddy [Mon, 20 Dec 2021 14:11:46 +0000 (19:41 +0530)]
scsi: mpi3mr: Code refactor of IOC init - part1
BugLink: https://bugs.launchpad.net/bugs/1967116
Separate out reply and sense buffer allocation and initialization into two
routines and call only initialization routine while issuing the IOC Init
request message.
Also move out the event enable logic to a separate function.
Link: https://lore.kernel.org/r/20211220141159.16117-13-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit e3605f65ef69f399aaade423f19f6db6eb3c11cb) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Sreekanth Reddy [Mon, 20 Dec 2021 14:11:45 +0000 (19:41 +0530)]
scsi: mpi3mr: Fault IOC when internal command gets timeout
BugLink: https://bugs.launchpad.net/bugs/1967116
Save snapdump and fault the controller with the given reason code if it is
already not in the fault or not in asynchronous reset. This ensures that
soft reset is issued from the watchdog thread. This will also be used to
handle initialization time faults/resets/timeout as in those cases
immediate soft reset invocation is not required.
Link: https://lore.kernel.org/r/20211220141159.16117-12-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit a6856cc4507be044497fcde48aa3d33e900cbc45) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Link: https://lore.kernel.org/r/20211220141159.16117-11-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 2ac794baaec97c70faf17b56fba4adefd6b7ba3a) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
- On B0 boards, if the parameter list length is greater than 24 and not a
16-byte multiple, then truncate the parameter list length to a 16-byte
multiple.
- On A0 boards, if the parameter list length is greater than block
descriptor data length + 8, then truncate the parameter list length to
block descriptor data length + 8 value.
Link: https://lore.kernel.org/r/20211220141159.16117-10-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 13fd7b1555b6c1121c0f823bbfa3ee36e178df44) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
- Enable 16 device removal handshake processing in parallel in the device
removal handshake infrastructure.
Link: https://lore.kernel.org/r/20211220141159.16117-9-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 4f08b9637f639fed9c36fde4e238274c47ca5f53) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Sreekanth Reddy [Mon, 20 Dec 2021 14:11:41 +0000 (19:41 +0530)]
scsi: mpi3mr: Do access status validation before adding devices
BugLink: https://bugs.launchpad.net/bugs/1967116
Add validation for various access statuses prior to exposing attached
target device to the operating system.
Link: https://lore.kernel.org/r/20211220141159.16117-8-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit ba68779a518d9ebe734c1fca9f5e199826723b5b) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Sreekanth Reddy [Mon, 20 Dec 2021 14:11:40 +0000 (19:41 +0530)]
scsi: mpi3mr: Add support for PCIe Managed Switch SES device
BugLink: https://bugs.launchpad.net/bugs/1967116
The SAS4 Controller firmware exposes the SES devices in Managed PCIe Switch
as a PCIe Device Type SCSI Device
(MPI3_DEVICE0_PCIE_DEVICE_INFO_TYPE_SCSI_DEVICE).
Driver is enhanced to handle this device type by:
- Exposing the device to the upper layers and
- Not updating any hardware sectors & virtual boundary settings as these
settings are needed only for NVMe devices.
Link: https://lore.kernel.org/r/20211220141159.16117-7-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 17d6b9cf89cfdb5a52298bb4abe7f1621f92ba93) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Link: https://lore.kernel.org/r/20211220141159.16117-6-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit ec5ebd2c14a9123c0a8e2ae29202adf0ac242565) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Link: https://lore.kernel.org/r/20211220141159.16117-5-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit d00ff7c31195e2f5098b2c034f547a83c30b8adb) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Sreekanth Reddy [Mon, 20 Dec 2021 14:11:37 +0000 (19:41 +0530)]
scsi: mpi3mr: Don't reset IOC if cmnds flush with reset status
BugLink: https://bugs.launchpad.net/bugs/1967116
Don't issue the soft reset if internal commands are flushed out with reset
status. Soft reset needs to be issued only if commands are really timed
out.
Link: https://lore.kernel.org/r/20211220141159.16117-4-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit fbaa9aa48bb43a021847195704c10908ded3c2ba) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Link: https://lore.kernel.org/r/20211220141159.16117-3-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit a83ec831b24a8142e0871544b19ee5671607588e) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Link: https://lore.kernel.org/r/20211220141159.16117-2-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 9cf0666f34b1991d73db8b19dc53387724aaefae) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Dan Carpenter [Wed, 13 Oct 2021 08:30:05 +0000 (11:30 +0300)]
scsi: mpi3mr: Use scnprintf() instead of snprintf()
BugLink: https://bugs.launchpad.net/bugs/1967116
I intended to move from snprintf() to scnprintf() in the previous patch but
I messed up and did not do that. The result of my bug is that it this
function could trigger a WARN() if the buffer is too large.
Link: https://lore.kernel.org/r/20211013083005.GA8592@kili Fixes: 76a4f7cc5973 ("scsi: mpi3mr: Clean up mpi3mr_print_ioc_info()") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 30e99f05f8b19b8274f3666afb70c9cc686ec65c) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
If we change from scnprintf() to snprintf() that lets us remove the if
bytes_wrote < sizeof(protocol) checks. Also, we can use bytes_wrote ? ","
: "" to print the comma and remove the separate if statement and the
"is_string_nonempty" variable.
[mkp: a few formatting cleanups and s/wrote/written/]
Link: https://lore.kernel.org/r/20210916132605.GF25094@kili Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 76a4f7cc5973608556c68ac1da60d29c4a6c1d30) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
cpufreq: amd-pstate: Fix Kconfig dependencies for AMD P-State
BugLink: https://bugs.launchpad.net/bugs/1956509
The AMD P-State driver is based on ACPI CPPC function, so ACPI should be
dependence of this driver in the kernel config.
In file included from ../drivers/cpufreq/amd-pstate.c:40:0:
../include/acpi/processor.h:226:2: error: unknown type name ‘phys_cpuid_t’
phys_cpuid_t phys_id; /* CPU hardware ID such as APIC ID for x86 */
^~~~~~~~~~~~
../include/acpi/processor.h:355:1: error: unknown type name ‘phys_cpuid_t’; did you mean ‘phys_addr_t’?
phys_cpuid_t acpi_get_phys_id(acpi_handle, int type, u32 acpi_id);
^~~~~~~~~~~~
phys_addr_t
CC drivers/rtc/rtc-rv3029c2.o
../include/acpi/processor.h:356:1: error: unknown type name ‘phys_cpuid_t’; did you mean ‘phys_addr_t’?
phys_cpuid_t acpi_map_madt_entry(u32 acpi_id);
^~~~~~~~~~~~
phys_addr_t
../include/acpi/processor.h:357:20: error: unknown type name ‘phys_cpuid_t’; did you mean ‘phys_addr_t’?
int acpi_map_cpuid(phys_cpuid_t phys_id, u32 acpi_id);
^~~~~~~~~~~~
phys_addr_t
See https://lore.kernel.org/lkml/20e286d4-25d7-fb6e-31a1-4349c805aae3@infradead.org/.
Reported-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Huang Rui <ray.huang@amd.com>
[ rjw: Subject edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit a2e6840b37b45d04e095c47f961211b7697cb063) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1956509
Add the description of @req and @boost_supported in struct amd_cpudata
kernel-doc comment to remove warnings found by running scripts/kernel-doc,
which is caused by using 'make W=1'.
drivers/cpufreq/amd-pstate.c:104: warning: Function parameter or member
'req' not described in 'amd_cpudata'
drivers/cpufreq/amd-pstate.c:104: warning: Function parameter or member
'boost_supported' not described in 'amd_cpudata'
Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Acked-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit bdc4fd3d48e7e97dd7efc14affe384280e197071) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1956509
I will continue to add new feature and processor support, optimize the
performance, and handle the issues for AMD P-State driver.
Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(backported from commit 38fec059bb69793f38cfa7a671d4bdbfe2a647aa) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit c22760885fd6f7161fabde8e7db63d7f085b125a) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 3ad7fde16a04aa70df8a59cba99e225ef9adf42f) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit ec4e3326a95507ea96fbad21b9472f5ba25500a7) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 41271016dfa4a08487bf2862f817edc9070489d1) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 60e10f896dbf6d78f912e4972081bd4119131376) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
cpufreq: amd-pstate: Introduce the support for the processors with shared memory solution
BugLink: https://bugs.launchpad.net/bugs/1956509
In some of Zen2 and Zen3 based processors, they are using the shared
memory that exposed from ACPI SBIOS. In this kind of the processors,
there is no MSR support, so we add acpi cppc function as the backend for
them.
It is using a module param (shared_mem) to enable related processors
manually. We will enable this by default once we address performance
issue on this solution.
Signed-off-by: Jinzhou Su <Jinzhou.Su@amd.com> Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit e059c184da47e92c6236f26b0fdaf9e92f0d55b5) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
cpufreq: amd-pstate: Add fast switch function for AMD P-State
BugLink: https://bugs.launchpad.net/bugs/1956509
Introduce the fast switch function for AMD P-State on the AMD processors
which support the full MSR register control. It's able to decrease the
latency on interrupt context.
Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 1d215f0319c20662b701692a2fafc7b3b8a58ae1) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
cpufreq: amd-pstate: Introduce a new AMD P-State driver to support future processors
BugLink: https://bugs.launchpad.net/bugs/1956509
AMD P-State is the AMD CPU performance scaling driver that introduces a
new CPU frequency control mechanism on AMD Zen based CPU series in Linux
kernel. The new mechanism is based on Collaborative processor
performance control (CPPC) which is finer grain frequency management
than legacy ACPI hardware P-States. Current AMD CPU platforms are using
the ACPI P-states driver to manage CPU frequency and clocks with
switching only in 3 P-states. AMD P-State is to replace the ACPI
P-states controls, allows a flexible, low-latency interface for the
Linux kernel to directly communicate the performance hints to hardware.
AMD P-State leverages the Linux kernel governors such as *schedutil*,
*ondemand*, etc. to manage the performance hints which are provided by CPPC
hardware functionality. The first version for AMD P-State is to support one
of the Zen3 processors, and we will support more in future after we verify
the hardware and SBIOS functionalities.
There are two types of hardware implementations for AMD P-State: one is full
MSR support and another is shared memory support. It can use
X86_FEATURE_CPPC feature flag to distinguish the different types.
Using the new AMD P-State method + kernel governors (*schedutil*,
*ondemand*, ...) to manage the frequency update is the most appropriate
bridge between AMD Zen based hardware processor and Linux kernel, the
processor is able to adjust to the most efficiency frequency according to
the kernel scheduler loading.
Please check the detailed CPU feature and MSR register description in
Processor Programming Reference (PPR) for AMD Family 19h Model 51h,
Revision A1 Processors:
Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit ec437d71db77a181227bf6d0ac9d4a80e58ecf0f) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Jinzhou Su [Fri, 8 Apr 2022 02:38:26 +0000 (10:38 +0800)]
ACPI: CPPC: Add CPPC enable register function
BugLink: https://bugs.launchpad.net/bugs/1956509
Add a new function to enable CPPC feature. This function
will write Continuous Performance Control package
EnableRegister field on the processor.
CPPC EnableRegister register described in section 8.4.7.1 of ACPI 6.4:
This element is optional. If supported, contains a resource descriptor
with a single Register() descriptor that describes a register to which
OSPM writes a One to enable CPPC on this processor. Before this register
is set, the processor will be controlled by legacy mechanisms (ACPI
Pstates, firmware, etc.).
This register will be used for AMD processors to enable AMD P-State
function instead of legacy ACPI P-States.
Signed-off-by: Jinzhou Su <Jinzhou.Su@amd.com> Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit fb0b00af04d083770d6e2762b2838357519f7d2d) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Steven Noonan [Fri, 8 Apr 2022 02:38:25 +0000 (10:38 +0800)]
ACPI: CPPC: Implement support for SystemIO registers
BugLink: https://bugs.launchpad.net/bugs/1956509
According to the ACPI v6.2 (and later) specification, SystemIO can be
used for _CPC registers. This teaches cppc_acpi how to handle such
registers.
This patch was tested using the amd_pstate driver on my Zephyrus G15
(model GA503QS) using the current version 410 BIOS, which uses
a SystemIO register for the HighestPerformance element in _CPC.
Signed-off-by: Steven Noonan <steven@valvesoftware.com> Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit a2c8f92bea5f8f1a87fc3caf063d67876dbf5d47) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1956509
AMD CPPC (Collaborative Processor Performance Control) function uses MSR
registers to manage the performance hints. So add the MSR register macro
here.
Signed-off-by: Huang Rui <ray.huang@amd.com> Acked-by: Borislav Petkov <bp@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 89aa94b4a218339b08f052a28c55322d5a13fc9e) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
This feature flag will be used on the following AMD P-State driver. The
AMD P-State driver has two approaches to implement the frequency control
behavior. That depends on the CPU hardware implementation. One is "Full
MSR Support" and another is "Shared Memory Support". The feature flag
indicates the current processors with "Full MSR Support".
Acked-by: Borislav Petkov <bp@suse.de> Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit d341db8f48ea43314f489921962c7f8f4ec27239) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
PCI/ACPI: Allow D3 only if Root Port can signal and wake from D3
BugLink: https://bugs.launchpad.net/bugs/1962349
acpi_pci_bridge_d3(dev) returns "true" if "dev" is a hotplug bridge that
can handle hotplug events while in D3. Previously this meant either:
- "dev" has a _PS0 or _PR0 method (acpi_pci_power_manageable()), or
- The Root Port above "dev" has a _DSD with a "HotPlugSupportInD3"
property with value 1.
This did not consider _PRW, which tells us about wakeup GPEs (ACPI v6.4,
sec 7.3.13). Without a wakeup GPE, from an ACPI perspective the Root Port
has no way of generating wakeup signals, so hotplug events will be lost if
we use D3.
Similarly, it did not consider _S0W, which tells us the deepest D-state
from which a device can wake itself (sec 7.3.20). If _S0W tells us the
device cannot wake from D3, hotplug events will again be lost if we use D3.
Some platforms, e.g., AMD Yellow Carp, supply "HotPlugSupportInD3" without
_PRW or with an _S0W that says the Root Port cannot wake from D3. On those
platforms, we previously put bridges in D3hot, hotplug events were lost,
and hotplugged devices would not be recognized without manually rescanning.
Allow bridges to be put in D3 only if the Root Port can generate wakeup
GPEs (wakeup.flags.valid), it can wake from D3 (_S0W), AND it has the
"HotPlugSupportInD3" property.
Neither Windows 10 nor Windows 11 puts the bridge in D3 when the firmware
is configured this way, and this change aligns the handling of the
situation to be the same.
thunderbolt: Do not make DROM read success compulsory
BugLink: https://bugs.launchpad.net/bugs/1962349
The USB4 specification doesn't make any requirements that reading
a device router's DROM is needed for the operation of the device.
Other connection manager solutions don't necessarily read it or gate
the usability of the device on whether it was read.
So make failures when reading the DROM show warnings but not
fail the initialization of the router.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
(cherry picked from commit 6915812bbd109787ebdb865561dc9164d4b01f56 linux-next) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Normally upon resume the UID is re-read to confirm it's the same
device connected.
* If the DROM read failed during init but then succeeded during
resume it could either be a new device or faulty device
* If the DROM read failed during init and also failed during resume
it might be a different device plugged in all together.
Detect this situation and prevent re-using the same configuration in
these cirucmstances.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
(cherry picked from commit a283de3ec646f19b09f3c8e4c8f57c0e017c9b2b linux-next) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
thunderbolt: Retry DROM reads for more failure scenarios
BugLink: https://bugs.launchpad.net/bugs/1962349
Currently DROM reads are only retried in the case that parsing failed.
However if the size or CRC fails, then there should also be a retry.
This helps with reading the DROM on TBT3 devices connected to AMD
Yellow Carp which will sometimes fail on the first attempt.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
(cherry picked from commit e87491a9fd4e33eaf18ef69d8295bb07b31452b2 linux-next) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
The following script can be used to trigger the issue:
#!/bin/bash
cat > test.py << EOF
import sys
f = open("/proc/self/maps")
for l in f.readlines():
if "python" not in l:
continue
print(l)
s = l.split()
start, end = s[0].split("-")
fname = s[-1]
print(start, end, fname)
break
else:
sys.exit(1)
Thanks to Andrei Vagin for the reproducer and investigation of this problem.
Cc: Andrei Vagin <avagin@gmail.com> Cc: Adrian Reber <areber@redhat.com> Cc: Christian Brauner <christian.brauner@ubuntu.com> Cc: Stefan Bader <stefan.bader@canonical.com> Cc: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Fixes: d24b8a5 ("UBUNTU: SAUCE: overlayfs: allow with shiftfs as underlay") Signed-off-by: Alexander Mikhalitsyn <alexander@mihalicyn.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
[small refactoring to add the dependency of AUFS for vma->vm_prfile] Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Except for several differences, the STEv2 is identical to STEv1, so for
most callbacks the STEv2 context struct will call STEv1 functions.
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
(cherry picked from commit 6862c787c7e88df490675ed781dc9052dba88a56) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Dima Chumak [Sun, 21 Nov 2021 21:45:12 +0000 (23:45 +0200)]
net/mlx5: Introduce software defined steering capabilities
BugLink: https://bugs.launchpad.net/bugs/1966194
There are two different internal steering modes, abstracted from the
rest of the driver. In order to keep upper layer of the driver agnostic
to the differences in capabilities of the steering modes, this patch
introduces mlx5_fs_get_capabilities() API to check if a certain software
defined capability is supported. It differs from the capabilities
exposed by the hardware, as it takes into account the flow steering mode
(SMFS/DMFS) currently enabled.
This implementation supports only two capability flags:
They map to DR_ACTION_STATE_PUSH_VLAN and DR_ACTION_STATE_POP_VLAN
actions, implemented in SW steering earlier in commit f5e22be534e0
("net/mlx5: DR, Split modify VLAN state to separate pop/push states").
Which enables using of pop/push vlan without restrictions, e.g. doing
vlan pop on TX and RX, compared to FW steering that supports only vlan
pop on RX and push on TX.
Other capabilities can be added in the future.
Signed-off-by: Dima Chumak <dchumak@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
(backported from commit 8348b71ccd921d0bff21b6f480ecc1e3a5033359)
[ dannf: minor context adjustments in fs_cmd.* ] Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
net/mlx5: DR, Refactor ste_ctx handling for STE v0/1
BugLink: https://bugs.launchpad.net/bugs/1966194
As preparation for supporting ConnectX-7, this patches changes handling
of ste_ctx handling for existing STE v0 and V1:
- each context is now a static struct, and it has a corresponding getter
- v0 and v1 were extended to contain the fields that are required for
integrating STEv2.
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
(cherry picked from commit 638a07f1090ea79fa6720b4d0265c6f8206f0c1b) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
net/mlx5: DR, Rename action modify fields to reflect naming in HW spec
BugLink: https://bugs.launchpad.net/bugs/1966194
As preparation for supporting ConnectX-7, rename action modify fields
steering registers from arbitrary names to the names that reflect the
corresponding naming and location of the steering registers in HW.
These registers mapping has changed in ConnectX-7, so the renaming allows
to keep track of their mapping better.
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
(cherry picked from commit 75a3926ca6a434651d4086a8a9152c1da7d7852e) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
net/mlx5: DR, Fix handling of different actions on the same STE in STEv1
BugLink: https://bugs.launchpad.net/bugs/1966194
Fix handling of various conditions in set_actions_rx/tx that check
whether different actions can be on the same STE.
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
(cherry picked from commit bdc3ab5795a6466f3fb2aa54198081e0d9c0b64c) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
(cherry picked from commit 11659ef8d28efb7e7b8011815f188de31d6647dd) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Muhammad Sammar <muhammads@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
(cherry picked from commit 5c422bfad2fbab96381273e50c7084465199501d) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
BUG: KASAN: slab-out-of-bounds in mlx5_cmd_dr_create_fte+0x18ee/0x1e70
This patch fixes the issue by both increasing the allocated buffers to
accommodate for the needed actions and by checking the number of actions
to prevent this issue when a rule with too many actions is provided.
Fixes: 1ffd498901c1 ("net/mlx5: DR, Increase supported num of actions to 32") Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
(cherry picked from commit 0aec12d97b2036af0946e3d582144739860ac07b) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
net/mlx5: Set SMFS as a default steering mode if device supports it
BugLink: https://bugs.launchpad.net/bugs/1966194
Set SMFS (SW-managed flow steering) as a default steering mode
instead of DMFS (device-managed flow steering)
In SMFS, the driver writes the STEs (Steering Table Entries) directly
to the device's ICM, which allows for a higher rule insertion rate
than through using FW command interface, as it is done in DMFS.
SMFS/DMFS steering modes can be configured through devlink param
'flow_steering_mode'. The possible values are 'smfs' or 'dmfs'.
The desired 'flow_steering_mode' param value should be set before
enabling switchdev mode.
Example:
# devlink dev param set pci/0000:05:00.0 name flow_steering_mode smfs
# devlink dev eswitch set pci/0000:05:00.0 mode switchdev
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
(cherry picked from commit aa36c94853b2bcc4953e065c462deb1ade7f55be) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
net/mlx5: DR, Ignore modify TTL if device doesn't support it
BugLink: https://bugs.launchpad.net/bugs/1966194
When modifying TTL, packet's csum has to be recalculated.
Due to HW issue in ConnectX-5, csum recalculation for modify TTL
is supported through a work-around that is specifically enabled
by configuration.
If the work-around isn't enabled, ignore the modify TTL action
rather than adding an unsupported action.
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
(cherry picked from commit 4ff725e1d4adfd313bc9767523fc8d6e90d50f9c) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
net/mlx5: DR, Improve steering for empty or RX/TX-only matchers
BugLink: https://bugs.launchpad.net/bugs/1966194
Every matcher has RX and TX paths. When a new matcher is created, its RX
and TX start/end anchors are connected to the respective RX and TX anchors
of the previous and next matchers.
This creates a potential performance issue: when a certain rule is added
to a matcher, in many cases it is RX or TX only rule, which may create a
long chain of RX/TX-only paths w/o the actual rules.
This patch aims to handle this issue.
RX and TX matchers are now handled separately: matcher connection in the
matchers chain is split into two separate lists: RX only and TX only.
when a new matcher is created, it is initially created 'detached' - its
RX/TX members are not inserted into the table's matcher list.
When an actual rule is added, only its appropriate RX or TX nic matchers
are then added to the table's nic matchers list and inserted into its
place in the chain of matchers.
I.e., if the rule that is being added is an RX-only rule, only the RX
part of the matcher will be connected to the chain, while TX part of the
matcher remains detached and doesn't prolong the TX chain of the matchers.
Same goes for rule deletion: when the last RX/TX rule of the nic matcher
is destroyed, the nic matcher is removed from its list.
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
(cherry picked from commit cc2295cd54e4832108831fd0a119bc4e0d5f8d50) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Muhammad Sammar <muhammads@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
(cherry picked from commit f59464e257bdbd4df6df9a4505d7858a0baf6cf7) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Muhammad Sammar [Sun, 5 Sep 2021 14:07:49 +0000 (17:07 +0300)]
net/mlx5: DR, Support matching on tunnel headers 0 and 1
BugLink: https://bugs.launchpad.net/bugs/1966194
Tunnel headers are generic encapsulation headers, applies for all
tunneling protocols identified by the device native parser or by the
programmable parser, this support will enable raw matching headers 0 and 1.
Signed-off-by: Muhammad Sammar <muhammads@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
(cherry picked from commit 09753babaf464177b5998c7ebb25d495c4811833) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Muhammad Sammar <muhammads@nvidia.com>
(cherry picked from commit 8c2b4fee9c4bb541ff027da0d906081f5363b182) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Muhammad Sammar <muhammads@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
(cherry picked from commit 0f2a6c3b9219bdf497750258cd2ad513f0056b42) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Paul Blakey <paulb@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
(cherry picked from commit b54128275ef86dd699fcb23d7e6df21f251dc038) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
(cherry picked from commit e3a0f40b2f90de86c1603126a5ad137d9677f605) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Muhammad Sammar [Wed, 9 Dec 2020 11:40:50 +0000 (13:40 +0200)]
net/mlx5: DR, Add support for dumping steering info
BugLink: https://bugs.launchpad.net/bugs/1966194
Extend mlx5 debugfs support to present Software Steering resources:
dr_domain including it's tables, matchers and rules.
The interface is read-only. While dump is being presented, new steering
rules cannot be inserted/deleted.
The steering information is dumped in the CSV form with the following
format:
Changes in V2:
- Reduce temp hex buffer size and avoid unnecessary memset
- Use bin2hex() instead of DIY loop
- Don't check debugfs functions return values
Signed-off-by: Muhammad Sammar <muhammads@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
(cherry picked from commit 9222f0b27da22579bea02cd2f1bc87beced2ef8d) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Muhammad Sammar <muhammads@nvidia.com>
(cherry picked from commit 7766c9b922febe18b4eb124eb731dd9a1ec71373) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1966194
Allow only legal values for flex parser ID - values from 0 to 7.
For other values skip the parser, and as a result the matcher creation
will fail for using invalid flex parser ID.
Signed-off-by: Hamdan Igbaria <hamdani@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
(cherry picked from commit 89cdba3224f07703e2272212db131cabe152979e) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
net/mlx5: DR, Rename list field in matcher struct to list_node
BugLink: https://bugs.launchpad.net/bugs/1966194
In dr_types structs, some list fields are list heads, and some
are just list nodes that are stored on the other structs' lists.
Rename the appropriate list field to reflect this distinction.
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
(cherry picked from commit 08fac109f7bb5e12ae14def56b3ad57ce67cd9fe) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
net/mlx5: DR, Remove unused struct member in matcher
BugLink: https://bugs.launchpad.net/bugs/1966194 Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
(cherry picked from commit 32e9bd58530720d9a78d051ac6743ae0ffcb7531) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
(cherry picked from commit c3fb0e280b4cdbf382f59eb6b276e4c6047bc219) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1966194
The error code of nic matcher init functions wasn't checked.
This patch improves the matcher init function and fix error flow bug:
the handling of match parameter is moved into a separate function
and error flow is simplified.
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
(cherry picked from commit 84dfac39c61fde04126e23723138128b50cd036f) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
net/mlx5: DR, Fix check for unsupported fields in match param
BugLink: https://bugs.launchpad.net/bugs/1966194
The existing loop doesn't cast the buffer while scanning it, which
results in out-of-bounds read and failure to create the matcher.
Fixes: 941f19798a11 ("net/mlx5: DR, Add check for unsupported fields in match param") Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
(cherry picked from commit 455832d49666e1765acf812be79710b9f84a8cbf) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
net/mlx5: DR, Fix querying eswitch manager vport for ECPF
BugLink: https://bugs.launchpad.net/bugs/1966194
On BlueField the E-Switch manager is the ECPF (vport 0xFFFE), but when
querying capabilities of ECPF eswitch manager, need to query vport 0
with other_vport = 0.
Fixes: 9091b821aaa4 ("net/mlx5: DR, Handle eswitch manager and uplink vports separately") Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
(cherry picked from commit 624bf42c2e3930acca9fcfc340b2fa38e712da84) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
net/mlx5: DR, Handle eswitch manager and uplink vports separately
BugLink: https://bugs.launchpad.net/bugs/1966194
When querying eswitch manager vport capabilities as "other = 1",
we encounter a FW compatibility issue with older FW versions.
To maintain backward compatibility, eswitch manager vport should
be queried as "other = 0" vport both for ECPF and non-ECPF cases.
This patch fixes these queries and improves the code readability
by handling eswitch manager and uplink vports separately, avoiding
the excessive 'if' conditions. Also, uplink caps are stored similar
to esw manager and not as part of xarray.
Fixes: dd4acb2a0954 ("net/mlx5: DR, Add missing query for vport 0") Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
(cherry picked from commit 9091b821aaa4c2d107ca8f97c32baefcb1e7e40d) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Maor Gottlieb [Tue, 3 Aug 2021 07:04:41 +0000 (10:04 +0300)]
net/mlx5: Introduce new uplink destination type
BugLink: https://bugs.launchpad.net/bugs/1966194
The uplink destination type should be used in rules to steer the
packet to the uplink when the device is in steering based LAG mode.
Signed-off-by: Maor Gottlieb <maorg@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
(cherry picked from commit 58a606dba708f114e7f412b5c3024027e8a73e34) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Muhammad Sammar [Mon, 5 Jul 2021 12:39:38 +0000 (15:39 +0300)]
net/mlx5: DR, Add check for unsupported fields in match param
BugLink: https://bugs.launchpad.net/bugs/1966194
When a matcher is being built, we "consume" (clear) mask fields one by one,
and to verify that we do support all the required fields we check if the
whole mask was consumed, else the matching request includes unsupported
fields.
Signed-off-by: Muhammad Sammar <muhammads@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
(cherry picked from commit 941f19798a11c46c6700cf0ff6f1d810a491b63b) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
(cherry picked from commit 98576013bf2831d7208e598043889db8c2d3665c) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
(cherry picked from commit 515ce2ffa62175d5442302a72553a14e5165441e) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1966194
Move all the vport capabilities to a separate struct and store vport caps
in XArray: SFs vport numbers will not come in the same range as VF vports,
so the existing implementation of vport capabilities as a fixed size array
is not suitable here.
XArray is a perfect fit: it is efficient when the indices used are densely
clustered. In addition to being a perfect fit as a dynamic data structure,
XArray also provides locking - it uses RCU and an internal spinlock to
synchronise access, so no additional protection needed.
Now except for the eswitch manager vport, all other vports (including the
uplink vport) are handled in the same way: when a new go-to-vport action
is added, this vport's caps are loaded from the xarray. If it is the first
time for this particular vport number, then its capabilities are queried
from FW and filled in into the appropriate entry.
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Muhammad Sammar <muhammads@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
(cherry picked from commit 11a45def2e197532c46aa908dedd52bc1ee378a2) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
net/mlx5: DR, Support csum recalculation flow table on SFs
BugLink: https://bugs.launchpad.net/bugs/1966194
Implement csum recalculation flow tables in XAarray instead of a fixed
array, thus adding support for csum recalc table on any valid vport
number, which enables this support for SFs.
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Muhammad Sammar <muhammads@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
(cherry picked from commit c0e90fc2ccaa8d7b9a781f5bc4287084b855138e) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
net/mlx5: DR, Align error messages for failure to obtain vport caps
BugLink: https://bugs.launchpad.net/bugs/1966194
Print similar error messages when an invalid vport number is
provided during action creation and during STEv0/1 creation.
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Muhammad Sammar <muhammads@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
(cherry picked from commit ee1887fb7cdd1b516ec94f71df41c4cc862836cd) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1966194
Currently, vport 0 capabilities are not set.
To fix this, we now querying both eswitch manager and vport 0.
Eswitch manager has an access to all the vports - for eswitch manager PF, all
vports can be referred as other vports. The exception is embedded CPU mode,
where there is vport 0 of ECPF and the PF vport 0.
Here is how vport are queried:
For Connect-X5/6:
PF vport (0) and vports 1..n: vport number, other = true
esw_manager is vport 0 (PF)
For BlueField (in embedded CPU mode):
ECPF vport: vport = 0, other = false
PF vport (0) and 1..n: vport number, other = true
esw_manager = vport 0 (ECPF)
Also, note that there's no need for other_vport function parameter
in dr_domain_query_vport - this value is now deduced locally in the
function.
Signed-off-by: Yuval Avnery <yuvalav@mellanox.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Muhammad Sammar <muhammads@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
(cherry picked from commit dd4acb2a0954a6ac9941f0dc3a690b49565c9ec3) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
net/mlx5: DR, Replace local WIRE_PORT macro with the existing MLX5_VPORT_UPLINK
BugLink: https://bugs.launchpad.net/bugs/1966194
SW steering defines its own macro for uplink vport number.
Replace this macro with an already existing mlx5 macro.
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
(cherry picked from commit 7ae8ac9a582088c85154970982766617c9ebf8dc) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
projects / mirror_ubuntu-jammy-kernel.git / log