Evan Quan [Wed, 6 Apr 2022 21:44:44 +0000 (17:44 -0400)]
drm/amd/pm: enable SCPM support for SMU
With SCPM enabled, the pptable used will be signed. It cannot
be used directly by driver. To get the raw pptable, we need to
rely on the combo pptable(and its revelant SMU message).
Also, the pptable transferring(to SMU) will be performed by PSP.
Some SMU messages will be not available to driver any more.
Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Evan Quan [Thu, 31 Mar 2022 22:10:35 +0000 (18:10 -0400)]
drm/amd/pm: move bootup values retrieving to ->sw_init
Firsrt of all, the operations involved is to interact with
VBIOS. They are fully supported at ->sw_init phase.
Secondly, the new mechanism to upload pptable to SMU is
introduced. With the new mechanism, the pptable transferring
has to be via PSP. That requires the pptable ucode(and necessary
bootupp values retrieving) must be ready before ->hw_init phase of PSP.
Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alice Wong [Thu, 28 Apr 2022 01:03:54 +0000 (21:03 -0400)]
drm/amdgpu/psp: deallocate memory when psp_load_fw failed
psp_load_fw failure would cause memory leak for psp tmr and psp ring
because psp_hw_init is not called as psp block is not fully initialized.
Clean up psp tmr and psp ring when psp_load_fw fail by calling
psp_free_shared_bufs and psp_ring_destroy.
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alice Wong <shiwei.wong@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
On Sienna Cichild, not all platforms use PMFW based fan control
(ex: fanless systems). On such ASICs fan control by PMFW will be
disabled in PPTable. Disable hwmon knobs for fan control also as
it is not possible to report or control fan speed on such platforms
through driver.
v3: FeaturesToRun casted as uint64_t
Signed-off-by: Elena Sakhnovitch <elena.sakhnovitch@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alex Deucher [Thu, 21 Apr 2022 05:21:52 +0000 (01:21 -0400)]
drm/amdgpu/psp: move PSP memory alloc from hw_init to sw_init
Memory allocations should be done in sw_init. hw_init should
just be hardware programming needed to initialize the IP block.
This is how most other IP blocks work. Move the GPU memory
allocations from psp hw_init to psp sw_init and move the memory
free to sw_fini. This also fixes a potential GPU memory leak
if psp hw_init fails.
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Philip Yang [Fri, 29 Apr 2022 00:17:38 +0000 (20:17 -0400)]
drm/amdgpu: Free user pages if kvmalloc_array fails
To cleanup the BOs of bo_list which have got user pages.
Signed-off-by: Philip Yang <Philip.Yang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/smu: Increace dpm level count only for smu v13.0.2
Only V13.0.2 on SMU v13 will get 0 based max level from fw and
increment by one, other ASIC will not need for this.
V2: replace the asic_type check with ip versioning check.
Harry Wentland [Tue, 19 Apr 2022 17:03:12 +0000 (13:03 -0400)]
drm/amd/display: Avoid reading audio pattern past AUDIO_CHANNELS_COUNT
A faulty receiver might report an erroneous channel count. We
should guard against reading beyond AUDIO_CHANNELS_COUNT as
that would overflow the dpcd_pattern_period array.
Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Robin Murphy [Wed, 4 May 2022 12:39:58 +0000 (13:39 +0100)]
iommu: Make sysfs robust for non-API groups
Groups created by VFIO backends outside the core IOMMU API should never
be passed directly into the API itself, however they still expose their
standard sysfs attributes, so we can still stumble across them that way.
Take care to consider those cases before jumping into our normal
assumptions of a fully-initialised core API group.
Fixes: 3f6634d997db ("iommu: Use right way to retrieve iommu_ops") Reported-by: Jan Stancek <jstancek@redhat.com> Tested-by: Jan Stancek <jstancek@redhat.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/86ada41986988511a8424e84746dfe9ba7f87573.1651667683.git.robin.murphy@arm.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
Marc Zyngier [Tue, 5 Apr 2022 18:23:27 +0000 (19:23 +0100)]
KVM: arm64: vgic-v3: Advertise GICR_CTLR.{IR, CES} as a new GICD_IIDR revision
Since adversising GICR_CTLR.{IC,CES} is directly observable from
a guest, we need to make it selectable from userspace.
For that, bump the default GICD_IIDR revision and let userspace
downgrade it to the previous default. For GICv2, the two distributor
revisions are strictly equivalent.
Since GICv4.1, it has become legal for an implementation to advertise
GICR_{INVLPIR,INVALLR,SYNCR} while having an ITS, allowing for a more
efficient invalidation scheme (no guest command queue contention when
multiple CPUs are generating invalidations).
Provide the invalidation registers as a primitive to their ITS
counterpart. Note that we don't advertise them to the guest yet
(the architecture allows an implementation to do this).
Marc Zyngier [Tue, 5 Apr 2022 18:23:25 +0000 (19:23 +0100)]
KVM: arm64: vgic-v3: Expose GICR_CTLR.RWP when disabling LPIs
When disabling LPIs, a guest needs to poll GICR_CTLR.RWP in order
to be sure that the write has taken effect. We so far reported it
as 0, as we didn't advertise that LPIs could be turned off the
first place.
Start tracking this state during which LPIs are being disabled,
and expose the 'in progress' state via the RWP bit.
We also take this opportunity to disallow enabling LPIs and programming
GICR_{PEND,PROP}BASER while LPI disabling is in progress, as allowed by
the architecture (UNPRED behaviour).
We don't advertise the feature to the guest yet (which is allowed by
the architecture).
As reported by Alan, the CFI (Call Frame Information) in the VDSO time
routines is incorrect since commit ce7d8056e38b ("powerpc/vdso: Prepare
for switching VDSO to generic C implementation.").
DWARF has a concept called the CFA (Canonical Frame Address), which on
powerpc is calculated as an offset from the stack pointer (r1). That
means when the stack pointer is changed there must be a corresponding
CFI directive to update the calculation of the CFA.
The current code is missing those directives for the changes to r1,
which prevents gdb from being able to generate a backtrace from inside
VDSO functions, eg:
Breakpoint 1, 0x00007ffff7f804dc in __kernel_clock_gettime ()
(gdb) bt
#0 0x00007ffff7f804dc in __kernel_clock_gettime ()
#1 0x00007ffff7d8872c in clock_gettime@@GLIBC_2.17 () from /lib64/libc.so.6
#2 0x00007fffffffd960 in ?? ()
#3 0x00007ffff7d8872c in clock_gettime@@GLIBC_2.17 () from /lib64/libc.so.6
Backtrace stopped: frame did not save the PC
Alan helpfully describes some rules for correctly maintaining the CFI information:
1) Every adjustment to the current frame address reg (ie. r1) must be
described, and exactly at the instruction where r1 changes. Why?
Because stack unwinding might want to access previous frames.
2) If a function changes LR or any non-volatile register, the save
location for those regs must be given. The CFI can be at any
instruction after the saves up to the point that the reg is
changed.
(Exception: LR save should be described before a bl. not after)
3) If asychronous unwind info is needed then restores of LR and
non-volatile regs must also be described. The CFI can be at any
instruction after the reg is restored up to the point where the
save location is (potentially) trashed.
Fix the inability to backtrace by adding CFI directives describing the
changes to r1, ie. satisfying rule 1.
Also change the information for LR to point to the copy saved on the
stack, not the value in r0 that will be overwritten by the function
call.
Finally, add CFI directives describing the save/restore of r2.
With the fix gdb can correctly back trace and navigate up and down the stack:
Breakpoint 1, 0x00007ffff7f804dc in __kernel_clock_gettime ()
(gdb) bt
#0 0x00007ffff7f804dc in __kernel_clock_gettime ()
#1 0x00007ffff7d8872c in clock_gettime@@GLIBC_2.17 () from /lib64/libc.so.6
#2 0x0000000100015b60 in gettime ()
#3 0x000000010000c8bc in print_long_format ()
#4 0x000000010000d180 in print_current_files ()
#5 0x00000001000054ac in main ()
(gdb) up
#1 0x00007ffff7d8872c in clock_gettime@@GLIBC_2.17 () from /lib64/libc.so.6
(gdb)
#2 0x0000000100015b60 in gettime ()
(gdb)
#3 0x000000010000c8bc in print_long_format ()
(gdb)
#4 0x000000010000d180 in print_current_files ()
(gdb)
#5 0x00000001000054ac in main ()
(gdb)
Initial frame selected; you cannot go up.
(gdb) down
#4 0x000000010000d180 in print_current_files ()
(gdb)
#3 0x000000010000c8bc in print_long_format ()
(gdb)
#2 0x0000000100015b60 in gettime ()
(gdb)
#1 0x00007ffff7d8872c in clock_gettime@@GLIBC_2.17 () from /lib64/libc.so.6
(gdb)
#0 0x00007ffff7f804dc in __kernel_clock_gettime ()
(gdb)
Fixes: ce7d8056e38b ("powerpc/vdso: Prepare for switching VDSO to generic C implementation.") Cc: stable@vger.kernel.org # v5.11+ Reported-by: Alan Modra <amodra@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org> Link: https://lore.kernel.org/r/20220502125010.1319370-1-mpe@ellerman.id.au
Lucas Stach [Wed, 4 May 2022 09:02:29 +0000 (11:02 +0200)]
drm/etnaviv: avoid cleaning up sched_job when submit succeeded
While the labels may mislead the casual reader, the tail of the function
etnaviv_ioctl_gem_submit is always executed, as a lot of the structures
set up in this function need to be cleaned up regardless of whether the
submit succeeded or failed.
An exception is the newly added drm_sched_job_cleanup, which must only
be called when the submit failed before handing the job to the
scheduler.
Andy Yan [Fri, 22 Apr 2022 07:28:39 +0000 (09:28 +0200)]
drm/rockchip: Add VOP2 driver
The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568.
It replaces the VOP unit found in the older Rockchip SoCs.
This driver has been derived from the downstream Rockchip Kernel and
heavily modified:
- All nonstandard DRM properties have been removed
- dropped struct vop2_plane_state and pass around less data between
functions
- Dropped all DRM_FORMAT_* not known on upstream
- rework register access to get rid of excessively used macros
- Drop all waiting for framesyncs
The driver is tested with HDMI and MIPI-DSI display on a RK3568-EVB
board. Overlay support is tested with the modetest utility. AFBC support
on the cluster windows is tested with weston-simple-dmabuf-egl on
weston using the (yet to be upstreamed) panfrost driver support.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Co-Developed-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Tested-by: Michael Riesch <michael.riesch@wolfvision.net>
[dt-binding-header:] Acked-by: Rob Herring <robh@kernel.org>
[moved dt-binding header from dt-nodes patch to here
and made checkpatch --strict happier] Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220422072841.2206452-23-s.hauer@pengutronix.de
Current port description doesn't cover all possible cases. It currently
expects one single port with two endpoints.
When the HDMI connector is described in the device tree there can be two
ports, first one going to the VOP and the second one going to the connector.
Also on SoCs which only have a single VOP there will be only one
endpoint instead of two.
This patch addresses both issues. With this there can either be a single
port ("port") , or two of them ("port@0", "port@1") when the connector
is also in the device tree. Also the first or only port can either have
one endpoint ("endpoint") for single VOP SoCs or two ("endpoint@0",
"endpoint@1") for dual VOP SoCs.
dt-bindings: display: rockchip: Add binding for VOP2
The VOP2 is found on newer Rockchip SoCs like the rk3568 or the rk3566.
The binding differs slightly from the existing VOP binding, so add a new
binding file for it.
Haren Myneni [Sat, 19 Mar 2022 09:28:09 +0000 (02:28 -0700)]
powerpc/pseries/vas: Use QoS credits from the userspace
The user can change the QoS credits dynamically with the
management console interface which notifies OS with sysfs. After
returning from the OS interface successfully, the management
console updates the hypervisor. Since the VAS capabilities in
the hypervisor is not updated when the OS gets the update,
the kernel is using the old total credits value from the
hypervisor. Fix this issue by using the new QoS credits
from the userspace instead of depending on VAS capabilities
from the hypervisor.
YueHaibing [Wed, 16 Mar 2022 10:42:39 +0000 (18:42 +0800)]
powerpc/eeh: Remove unused inline functions
pseries_eeh_init_edev() is used exclusively in eeh_pseries.c, make it
static and remove unused inline function.
pseries_eeh_init_edev_recursive() is only called from files build wich
CONFIG_HOTPLUG_PCI_RPA which depends on CONFIG_PSERIES and CONFIG_EEH,
so can remove the unused inline version.
Damien Le Moal [Wed, 20 Apr 2022 00:57:18 +0000 (09:57 +0900)]
block: null_blk: Improve device creation with configfs
Currently, the directory name used to create a nullb device through
sysfs is not used as the device name, potentially causing headaches for
users if devices are already created through the modprobe operation
withe the nr_device module parameter not set to 0. E.g. a user can do
"mkdir /sys/kernel/config/nullb/nullb0" to create a nullb device even
though /dev/nullb0 was already created by modprobe. In this case, the
configfs nullb device will be named nullb1, causing confusion for the
user.
Simplify this by using the configfs directory name as the nullb device
name, always, unless another nullb device is already using the same
name. E.g. if modprobe created nullb0, then:
To implement this, the function null_find_dev_by_name() is added to
check for the existence of a nullb device with the name used for a new
configfs device directory. nullb_group_make_item() uses this new
function to check if the directory name can be used as the disk name.
Finally, null_add_dev() is modified to use the device config item name
as the disk name for a new nullb device created using configfs.
The naming of devices created though modprobe remains unchanged.
Of note is that it is possible for a user to create through configfs a
nullb device with the same name as an existing device. E.g.
$ mkdir /sys/kernel/config/nullb/null
will successfully create the nullb device named "null" but this block
device will however not appear under /dev/ since /dev/null already
exists.
Damien Le Moal [Wed, 20 Apr 2022 00:57:17 +0000 (09:57 +0900)]
block: null_blk: Cleanup messages
Use the pr_fmt() macro to prefix all null_blk pr_xxx() messages with
"null_blk:" to clarify which module is printing the messages. Also add
a pr_info() message in null_add_dev() to print the name of a newly
created disk.
Damien Le Moal [Wed, 20 Apr 2022 00:57:16 +0000 (09:57 +0900)]
block: null_blk: Cleanup device creation and deletion
Introduce the null_create_dev() and null_destroy_dev() helper functions
to respectivel create nullb devices on modprobe and destroy them on
rmmod. The null_destroy_dev() helper avoids duplicated code in the
null_init() and null_exit() functions for deleting devices.
Use bdev_discard_alignment to calculate the correct discard alignment
offset even for partitions instead of just looking at the queue limit.
Also switch to use bdev_discard_granularity to get rid of the last direct
queue reference in xen_blkbk_discard.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Link: https://lore.kernel.org/r/20220418045314.360785-12-hch@lst.de
[axboe: fold in 'q' removal as it's now unused] Signed-off-by: Jens Axboe <axboe@kernel.dk>
Michal Orzel [Tue, 26 Apr 2022 07:06:03 +0000 (09:06 +0200)]
arm64: cputype: Avoid overflow using MIDR_IMPLEMENTOR_MASK
Value of macro MIDR_IMPLEMENTOR_MASK exceeds the range of integer
and can lead to overflow. Currently there is no issue as it is used
in expressions implicitly casting it to u32. To avoid possible
problems, fix the macro.
It is possibe that probe failure issue happens when the device
and its child_device's probe happens at the same time.
In coresight_make_links, has_conns_grp is true for parent, but
has_conns_grp is false for child device as has_conns_grp is set
to true in coresight_create_conns_sysfs_group. The probe of parent
device will fail at this condition. Add has_conns_grp check for
child device before make the links and make the process from
device_register to connection_create be atomic to avoid this
probe failure issue.
Cc: stable@vger.kernel.org Suggested-by: Suzuki K Poulose <suzuki.poulose@arm.com> Suggested-by: Mike Leach <mike.leach@linaro.org> Signed-off-by: Mao Jinlong <quic_jinlmao@quicinc.com> Link: https://lore.kernel.org/r/20220309142206.15632-1-quic_jinlmao@quicinc.com
[ Added Cc stable ] Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Johannes Berg [Thu, 14 Apr 2022 12:04:03 +0000 (14:04 +0200)]
nl80211: rework internal_flags usage
Since internal_flags is only 8 bits, we can only have one
more internal flag. However, we can obviously never use all
of possible the combinations, in fact, we only use 14 of
them (including no flags).
Since we want more flags for MLO (multi-link operation) in
the future, refactor the code to use a flags selector, so
wrap all of the .internal_flags assignments in a IFLAGS()
macro which selects the combination according to the pre-
defined list of combinations.
When we need a new combination, we'll have to add it, but
again we will never use all possible combinations.
mmc: sdhci-msm: Reset GCC_SDCC_BCR register for SDHC
Reset GCC_SDCC_BCR register before every fresh initilazation. This will
reset whole SDHC-msm controller, clears the previous power control
states and avoids, software reset timeout issues as below.
Johannes Berg [Thu, 14 Apr 2022 12:04:02 +0000 (14:04 +0200)]
nl80211: don't hold RTNL in color change request
It's not necessary to hold the RTNL across color change
requests, since all the inner locking needs only the
wiphy mutex which we already hold as well.
Johannes Berg [Tue, 12 Apr 2022 20:09:59 +0000 (22:09 +0200)]
cfg80211: remove cfg80211_get_chan_state()
We haven't used this function for years, since commit c781944b71f8
("cfg80211: Remove unused cfg80211_can_use_iftype_chan()") which
itself removed a function unused since commit 97dc94f1d933
("cfg80211: remove channel_switch combination check"), almost eight
years ago.
Also remove the now unused enum cfg80211_chan_mode and some struct
members that were only used for this function.
Since Qualcomm device-trees already use SoC specific compatibles for
describing the 'sdhci-msm' nodes, it makes sense to add the support for the
same in the driver as well.
Keep the old deprecated compatible strings still in the driver, to ensure
backward compatibility with older device-trees.
David S. Miller [Wed, 4 May 2022 10:21:33 +0000 (11:21 +0100)]
Merge branch 'mlxsw-updates'
Ido Schimmel says:
====================
mlxsw: Various updates
Patches #1-#3 add missing topology diagrams in selftests and perform
small cleanups.
Patches #4-#5 make small adjustments in QoS configuration. See detailed
description in the commit messages.
Patches #6-#8 reduce the number of background EMAD transactions. The
driver periodically queries the device (via EMAD transactions) about
updates that cannot happen in certain situations. This can negatively
impact the latency of time critical transactions, as the device is busy
processing other transactions.
Before:
# perf stat -a -e devlink:devlink_hwmsg -- sleep 10
Ido Schimmel [Wed, 4 May 2022 06:29:09 +0000 (09:29 +0300)]
mlxsw: spectrum_router: Only query neighbour activity when necessary
The driver periodically queries the device for activity of neighbour
entries in order to report it to the kernel's neighbour table.
Avoid unnecessary activity query when no neighbours are installed. Use
an atomic variable to track the number of neighbours, as it is read
without any locks.
Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel [Wed, 4 May 2022 06:29:08 +0000 (09:29 +0300)]
mlxsw: spectrum_switchdev: Only query FDB notifications when necessary
The driver periodically queries the device for FDB notifications (e.g.,
learned, aged-out) in order to update the bridge driver. These
notifications can only be generated when bridges are offloaded to the
device.
Avoid unnecessary queries by starting to query upon installation of the
first bridge and stop querying upon removal of the last bridge.
Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Petr Machata [Wed, 4 May 2022 06:29:06 +0000 (09:29 +0300)]
mlxsw: Treat LLDP packets as control
When trapping packets for on-CPU processing, Spectrum machines
differentiate between control and non-control traps. Traffic trapped
through non-control traps is treated as data and kept in shared buffer in
pools 0-4. Traffic trapped through control traps is kept in the dedicated
control buffer 9. The advantage of marking traps as control is that
pressure in the data plane does not prevent the control traffic to be
processed.
When the LLDP trap was introduced, it was marked as a control trap. But
then in commit aed4b5721143 ("mlxsw: spectrum: PTP: Hook into packet
receive path"), PTP traps were introduced. Because Ethernet-encapsulated
PTP packets look to the Spectrum-1 ASIC as LLDP traffic and are trapped
under the LLDP trap, this trap was reconfigured as non-control, in sync
with the PTP traps.
There is however no requirement that PTP traffic be handled as data.
Besides, the usual encapsulation for PTP traffic is UDP, not bare Ethernet,
and that is in deployments that even need PTP, which is far less common
than LLDP. This is reflected by the default policer, which was not bumped
up to the 19Kpps / 24Kpps that is the expected load of a PTP-enabled
Spectrum-1 switch.
Marking of LLDP trap as non-control was therefore probably misguided. In
this patch, change it back to control.
Reported-by: Maksym Yaremchuk <maksymy@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Petr Machata [Wed, 4 May 2022 06:29:05 +0000 (09:29 +0300)]
mlxsw: spectrum_dcb: Do not warn about priority changes
The idea behind the warnings is that the user would get warned in case when
more than one priority is configured for a given DSCP value on a netdevice.
The warning is currently wrong, because dcb_ieee_getapp_mask() returns
the first matching entry, not all of them, and the warning will then claim
that some priority is "current", when in fact it is not.
But more importantly, the warning is misleading in general. Consider the
following commands:
# dcb app flush dev swp19 dscp-prio
# dcb app add dev swp19 dscp-prio 24:3
# dcb app replace dev swp19 dscp-prio 24:2
The last command will issue the following warning:
mlxsw_spectrum3 0000:07:00.0 swp19: Ignoring new priority 2 for DSCP 24 in favor of current value of 3
The reason is that the "replace" command works by first adding the new
value, and then removing all old values. This is the only way to make the
replacement without causing the traffic to be prioritized to whatever the
chip defaults to. The warning is issued in response to adding the new
priority, and then no warning is shown when the old priority is removed.
The upshot is that the canonical way to change traffic prioritization
always produces a warning about ignoring the new priority, but what gets
configured is in fact what the user intended.
An option to just emit warning every time that the prioritization changes
just to make it clear that it happened is obviously unsatisfactory.
Therefore, in this patch, remove the warnings.
Reported-by: Maksym Yaremchuk <maksymy@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Petr Machata [Wed, 4 May 2022 06:29:04 +0000 (09:29 +0300)]
selftests: router.sh: Add a diagram
It is customary for selftests to have a comment with a topology diagram,
which serves to illustrate the situation in which the test is done. This
selftest lacks it. Add it.
Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Petr Machata [Wed, 4 May 2022 06:29:03 +0000 (09:29 +0300)]
selftests: router_vid_1: Add a diagram, fix coding style
It is customary for selftests to have a comment with a topology diagram,
which serves to illustrate the situation in which the test is done. This
selftest lacks it. Add it.
While at it, fix the list of tests so that the test names are enumerated
one at a line.
Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Petr Machata [Wed, 4 May 2022 06:29:02 +0000 (09:29 +0300)]
selftests: mlxsw: bail_on_lldpad before installing the cleanup trap
A number of mlxsw-specific QoS tests use manual QoS DCB management. As
such, they need to make sure lldpad is not running, because it would
override the configuration the test has applied using other tools. To that
end, these selftests invoke the bail_on_lldpad() helper, which terminates
the selftest if th lldpad is running.
Some of these tests however first install the bash exit trap, which invokes
a cleanup() at the test exit. If bail_on_lldpad() has terminated the script
even before the setup part was run, the cleanup part will be very confused.
Therefore make sure bail_on_lldpad() is invoked before the cleanup is
registered.
While there are still edge cases where the user terminates the script
before the setup was fully done, this takes care of a common situation
where the cleanup would be invoked in an inconsistent state.
Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Wed, 4 May 2022 10:18:08 +0000 (11:18 +0100)]
Merge branch 'sfc-Siena-subdir'
Martin Habets says:
====================
sfc: Move Siena into a separate subdirectory
The Siena NICs (SFN5000 and SFN6000 series) went EOL in November 2021.
Most of these adapters have been remove from our test labs, and testing
has been reduced to a minimum.
This patch series creates a separate kernel module for the Siena architecture,
analogous to what was done for Falcon some years ago.
This reduces our maintenance for the sfc.ko module, and allows us to
enhance the EF10 and EF100 drivers without the risk of breaking Siena NICs.
After this series further enhancements are needed to differentiate the
new kernel module from sfc.ko, and the Siena code can be removed from sfc.ko.
Thes will be posted as a small follow-up series.
The Siena module is not built by default, but can be enabled
using Kconfig option SFC_SIENA. This will create module sfc-siena.ko.
Patches
Patch 1 disables the Siena code in the sfc.ko module.
Patches 2-6 establish the code base for the Siena driver.
Patches 7-12 ensure the allyesconfig build succeeds.
Patch 13 adds the basic Siena module.
I do not expect patch 2 through 5 to be reviewed, they are FYI only.
No checkpatch issues were resolved as part of these, but they
were fixed in the subsequent patches.
Testing
Various build tests were done such as allyesconfig, W=1 and sparse.
The new sfc-siena.ko and sfc.ko modules were tested on a machine with both
these NICs in them, and several tests were run on both drivers.
Martin
---
v3:
- Fix build errors after rebase.
v2:
- Split up patch that copies existing files.
- Only copy a subset of mcdi_pcol.h.
- Use --find-copies-harder as suggested by Benjamin Poirier.
- Merge several patches for the allyesconfig build into larger ones.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
projects / people / ms / linux.git / log
