dt-bindings: remoteproc: qcom,smd-edge: define re-usable schema for smd-edge
'smd-edge' property appears in multiple bindings, so split it into one
place which can be re-used. This reduces code duplication and adds
strict schema matching for smd-edge nodes (instead of just
"type:object").
dt-bindings: remoteproc: qcom,glink-edge: define re-usable schema for glink-edge
'glink-edge' property appears in multiple bindings, so split it into one
place which can be re-used. This reduces code duplication and adds
strict schema matching for glink-edge nodes (instead of just
"type:object").
And in release_reference() we dereference vma->vm to get to the
vm gt pointer, leading to a use-after free.
However, __i915_vm_release() grabs the vm->mutex so the vm won't be
destroyed before vma->vm->mutex is released, so extract the gt pointer
under the vm->mutex to avoid the vma->vm dereference in
release_references().
v2: Fix a typo in the commit message (Andi Shyti)
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5944 Fixes: e1a7ab4fca0c ("drm/i915: Remove the vm open count") Cc: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Acked-by: Nirmoy Das <nirmoy.das@intel.con> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220620123659.381772-1-thomas.hellstrom@linux.intel.com
(cherry picked from commit 1926a6b75954fc1a8b44d10bd0c67db957b78cf7) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
drm/i915/guc: ADL-N should use the same GuC FW as ADL-S
The only difference between the ADL S and P GuC FWs is the HWConfig
support. ADL-N does not support HWConfig, so we should use the same
binary as ADL-S, otherwise the GuC might attempt to fetch a config
table that does not exist. ADL-N is internally identified as an ADL-P,
so we need to special-case it in the FW selection code.
Fixes: 7e28d0b26759 ("drm/i915/adl-n: Enable ADL-N platform") Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Tejas Upadhyay <tejas.upadhyay@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220621233005.3952293-1-daniele.ceraolospurio@intel.com
(cherry picked from commit 971e4a9781742aaad1587e25fd5582b2dd595ef8) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Hangyu Hua [Fri, 24 Jun 2022 13:04:06 +0000 (06:04 -0700)]
drm/i915: fix a possible refcount leak in intel_dp_add_mst_connector()
If drm_connector_init fails, intel_connector_free will be called to take
care of proper free. So it is necessary to drop the refcount of port
before intel_connector_free.
Jakub Kicinski [Thu, 7 Jul 2022 03:04:09 +0000 (20:04 -0700)]
Merge branch 'wireguard-patches-for-5-19-rc6'
Jason A. Donenfeld says:
====================
wireguard patches for 5.19-rc6
1) A few small fixups to the selftests, per usual. Of particular note is
a fix for a test flake that occurred on especially fast systems that
boot in less than a second.
2) An addition during this cycle of some s390 crypto interacted with the
way wireguard selects dependencies, resulting in linker errors
reported by the kernel test robot. So Vladis sent in a patch for
that, which also required a small preparatory fix moving some Kconfig
symbols around.
====================
Select the new implementation of CHACHA20 for S390 when available.
It is faster than the generic software implementation, but also prevents
some linker errors in certain situations.
crypto: s390 - do not depend on CRYPTO_HW for SIMD implementations
Various accelerated software implementation Kconfig values for S390 were
mistakenly placed into drivers/crypto/Kconfig, even though they're
mainly just SIMD code and live in arch/s390/crypto/ like usual. This
gives them the very unusual dependency on CRYPTO_HW, which leads to
problems elsewhere.
This patch fixes the issue by moving the Kconfig values for non-hardware
drivers into the usual place in crypto/Kconfig.
Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
These selftests are used for much more extensive changes than just the
wireguard source files. So always call the kernel's build file, which
will do something or nothing after checking the whole tree, per usual.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Not all platforms have an RTC, and rather than trying to force one into
each, it's much easier to just set a fixed time. This is necessary
because WireGuard's latest handshakes parameter is returned in wallclock
time, and if the system time isn't set, and the system is really fast,
then this returns 0, which trips the test.
Turning this on requires setting CONFIG_COMPAT_32BIT_TIME=y, as musl
doesn't support settimeofday without it.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
66e4c8d95008 ("net: warn if transport header was not set") added
a check that triggers a warning in r8169, see [0].
The commit referenced in the Fixes tag refers to the change from
which the patch applies cleanly, there's nothing wrong with this
commit. It seems the actual issue (not bug, because the warning
is harmless here) was introduced with bdfa4ed68187
("r8169: use Giant Send").
net: rose: fix UAF bug caused by rose_t0timer_expiry
There are UAF bugs caused by rose_t0timer_expiry(). The
root cause is that del_timer() could not stop the timer
handler that is running and there is no synchronization.
One of the race conditions is shown below:
The rose_neigh is deallocated in position [1] and use in
position [2].
The crash trace triggered by POC is like below:
BUG: KASAN: use-after-free in expire_timers+0x144/0x320
Write of size 8 at addr ffff888009b19658 by task swapper/0/0
...
Call Trace:
<IRQ>
dump_stack_lvl+0xbf/0xee
print_address_description+0x7b/0x440
print_report+0x101/0x230
? expire_timers+0x144/0x320
kasan_report+0xed/0x120
? expire_timers+0x144/0x320
expire_timers+0x144/0x320
__run_timers+0x3ff/0x4d0
run_timer_softirq+0x41/0x80
__do_softirq+0x233/0x544
...
This patch changes rose_stop_ftimer() and rose_stop_t0timer()
in rose_remove_neigh() to del_timer_sync() in order that the
timer handler could be finished before the resources such as
rose_neigh and so on are deallocated. As a result, the UAF
bugs could be mitigated.
Johan Hovold [Tue, 5 Jul 2022 11:40:29 +0000 (13:40 +0200)]
arm64: dts: qcom: sm8450: drop UFS PHY clock-cells
The QMP UFS PHY provides more than one symbol clock and would need an
index to differentiate the clocks, but none of this is described by the
binding currently.
Drop the incorrect '#clock-cells' property for now.
Johan Hovold [Tue, 5 Jul 2022 11:40:28 +0000 (13:40 +0200)]
arm64: dts: qcom: sm8250: drop UFS PHY clock-cells
The QMP UFS PHY provides more than one symbol clock and would need an
index to differentiate the clocks, but none of this is described by the
binding currently.
Drop the incorrect '#clock-cells' property for now.
Johan Hovold [Tue, 5 Jul 2022 11:40:27 +0000 (13:40 +0200)]
arm64: dts: qcom: sc8280xp: drop UFS PHY clock-cells
The QMP UFS PHY provides more than one symbol clock and would need an
index to differentiate the clocks, but none of this is described by the
binding currently.
Drop the incorrect '#clock-cells' property for now.
The commit in question caused my sc7280-herobrine-herobrine-r1 board
not to boot anymore. This shouldn't be too surprising since the driver
is relying on the name "cqhci".
The issue seems to be that someone decided to change the names of
things when the binding moved from .txt to .yaml. We should go back to
the names that the bindings have historically specified.
For some history, see commit d3392339cae9 ("mmc: cqhci: Update cqhci
memory ioresource name") and commit d79100c91ae5 ("dt-bindings: mmc:
sdhci-msm: Add CQE reg map").
Mimi Zohar [Thu, 30 Jun 2022 15:23:38 +0000 (11:23 -0400)]
ima: fix violation measurement list record
Although the violation digest in the IMA measurement list is always
zeroes, the size of the digest should be based on the hash algorithm.
Until recently the hash algorithm was hard coded to sha1. Fix the
violation digest size included in the IMA measurement list.
This is just a cosmetic change which should not affect attestation.
Reported-by: Stefan Berger <stefanb@linux.ibm.com> Fixes: 09091c44cb73 ("ima: use IMA default hash algorithm for integrity violations") Tested-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
arm64: dts: qcom: sc7280: use constants for gpucc clocks and power-domains
To ease merging of bindings and dts files, the constants were replaced
with numeric values. Change them back to defined constants.
While we are at it, fix the indentation of these clocks properties to
follow established guidelines.
Robert Marko [Mon, 4 Jul 2022 14:35:54 +0000 (16:35 +0200)]
arm64: dts: qcom: ipq8074: add reset to SDHCI
Add reset to SDHCI controller so it can be reset to avoid timeout issues
after software reset due to bootloader set configuration.
Signed-off-by: Robert Marko <robimarko@gmail.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220704143554.1180927-2-robimarko@gmail.com
Add device node for CPU-memory BWMON device (bandwidth monitoring) on
SDM845 measuring bandwidth between CPU (gladiator_noc) and Last Level
Cache (memnoc). Usage of this BWMON allows to remove fixed bandwidth
votes from cpufreq (CPU nodes) thus achieve high memory throughput even
with lower CPU frequencies.
Robert Marko [Mon, 4 Jul 2022 11:33:18 +0000 (13:33 +0200)]
arm64: dts: qcom: ipq8074: move ARMv8 timer out of SoC node
The ARM timer is usually considered not part of SoC node, just like
other ARM designed blocks (PMU, PSCI). This fixes dtbs_check warning:
arch/arm64/boot/dts/qcom/ipq8072-ax9000.dtb: soc: timer: {'compatible': ['arm,armv8-timer'], 'interrupts': [[1, 2, 3848], [1, 3, 3848], [1, 4, 3848], [1, 1, 3848]]} should not be valid under {'type': 'object'}
From schema: dtschema/schemas/simple-bus.yaml
Signed-off-by: Robert Marko <robimarko@gmail.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
[bjorn: Moved node after "soc" for alphabetical ordering] Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220704113318.623102-1-robimarko@gmail.com
Abel Vesa [Thu, 30 Jun 2022 10:14:03 +0000 (13:14 +0300)]
arm64: dts: qcom: sdm845: Switch PSCI cpu idle states from PC to OSI
Switch from the flat PC idle states of sdm845 to OSI hierarchical idle
states. The exceptions are the cheza plaftorms, which need to remain with
PC idle states. So in order allow all the other platforms to switch,
while cheza platforms to remain the same, replace the PC idle states with
the OSI ones in the main SDM845 dtsi, and then override the inherited OSI
states with PC ones, delete inherited psci cpus nodes, domain idle states
and power domain properties.
Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Tested-by: Steev Klimaszewski <steev@kali.org> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220630101403.1888541-1-abel.vesa@linaro.org
Anton Bambura [Sun, 26 Jun 2022 16:45:38 +0000 (12:45 -0400)]
arm64: dts: qcom: add device tree for LG G7 and LG V35
Adds initial support for the LG G7 (judyln) and
LG V35 (judyp) phones.
Currently supported features:
- Display via simplefb (panel driver is WIP)
- Keys
- Micro SD card
- Modem (not tested much, but initialises)
- UFS (crashes during intensive workloads, may need quirks)
- USB in peripheral mode
Notable missing features:
- Enabling WiFi causes a remoteproc crash, so it's disabled here.
Needs to be debugged - ideas welcome!
Signed-off-by: Anton Bambura <jenneron@protonmail.com> Signed-off-by: Stefan Hansson <newbie13xd@gmail.com> Tested-by: Gregari Ivanov <llamashere@posteo.de> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220626164536.16011-2-newbie13xd@gmail.com
Dmitry Baryshkov [Mon, 20 Jun 2022 07:19:34 +0000 (10:19 +0300)]
arm64: dts: qcom: msm8996: correct #clock-cells for QMP PHY nodes
The commit 82d61e19fccb ("arm64: dts: qcom: msm8996: Move '#clock-cells'
to QMP PHY child node") moved the '#clock-cells' properties to the child
nodes. However it missed the fact that the property must have been set
to <0> (as all pipe clocks use of_clk_hw_simple_get as the xlate
function. Also the mentioned commit didn't add '#clock-cells' properties
to second and third PCIe PHY nodes. Correct both these mistakes:
- Set '#clock-cells' to <0>,
- Add the property to pciephy_1 and pciephy_2 nodes.
Dylan Van Assche [Thu, 12 May 2022 05:44:39 +0000 (07:44 +0200)]
arm64: dts: qcom: sdm845-shift-axolotl: Enable pmi9889 LPG LED
Enables the RGB notification LED on the SHIFT 6mq (sdm845-shift-axolotl)
with the Qualcomm Light Pulse Generator bindings by Bjorn Andersson [1].
Patches are merged in for-next branch of linux-leds.
Tested these changes on the SHIFT 6mq.
drm: rcar-du: Lift z-pos restriction on primary plane for Gen3
There's no reason to require the primary plane to always be at the
bottom of the stack, as the VSP supports arbitrary ordering of planes,
and the KMS API doesn't have such a requirement either. Lift the
restriction.
As the primary plane can now be positioned arbitrarily, enable control
of its alpha channel as well.
As per R-Car-Gen3_Common_OPC_Customer_Notifications_V30.1.pdf,
unexpected image output(such as incorrect colors or planes being
invisible) can happen on the below conditions, as PnALPHAR register
is not initialized by reset.
When alpha blending (PpMRm.PpSPIM=0b101) is performed and:
•two Planes are enabled on any DUn (n=0,1,2,3)
oDSPRn= 0x0000 0031 or 0x0000 0013
•or DU0 and DU1 is used for display at the same time
oDSPR0= 0x0000 0001 and DSPR1= 0x0000 0003
oDSPR0= 0x0000 0003 and DSPR1= 0x0000 0001
•or DU2 and DU3(H3 Only) is used for display at the same time
oDSPR2= 0x0000 0001 and DSPR3= 0x0000 0003
oDSPR2= 0x0000 0003 and DSPR3= 0x0000 0001
This patch set PnALPHAR register to 0 to avoid this issue.
drm: rcar-du: Drop file name from comment header blocks
The comment blocks at the beginning of each file have a one-line
summary description of the file that includes the file name. While the
description is useful, the file name only creates opportunities for
mistakes (as seen in rcar_du_vsp.c) without any added value. Drop it.
Alex Deucher [Tue, 21 Jun 2022 14:10:37 +0000 (10:10 -0400)]
drm/amdgpu/display: disable prefer_shadow for generic fb helpers
Seems to break hibernation. Disable for now until we can root
cause it.
Fixes: 087451f372bf ("drm/amdgpu: use generic fb helpers instead of setting up AMD own's.")
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=216119 Acked-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alex Deucher [Tue, 21 Jun 2022 14:04:55 +0000 (10:04 -0400)]
drm/amdgpu: keep fbdev buffers pinned during suspend
Was dropped when we converted to the generic helpers.
Fixes: 087451f372bf ("drm/amdgpu: use generic fb helpers instead of setting up AMD own's.") Acked-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Rob Clark [Sat, 25 Jun 2022 22:54:36 +0000 (15:54 -0700)]
drm/msm: Switch to pfn mappings
I'm not entirely sure why we were using VM_MIXEDMAP. These are never
CoW mappings. Let's switch to be more consistent with what other
drivers and the GEM shmem helpers do.
Rob Clark [Mon, 13 Jun 2022 18:20:30 +0000 (11:20 -0700)]
drm/msm/adreno: Defer enabling runpm until hw_init()
To avoid preventing the display from coming up before the rootfs is
mounted, without resorting to packing fw in the initrd, the GPU has
this limbo state where the device is probed, but we aren't ready to
start sending commands to it. This is particularly problematic for
a6xx, since the GMU (which requires fw to be loaded) is the one that
is controlling the power/clk/icc votes.
So defer enabling runpm until we are ready to call gpu->hw_init(),
as that is a point where we know we have all the needed fw and are
ready to start sending commands to the coproc's.
Rob Clark [Mon, 13 Jun 2022 20:50:32 +0000 (13:50 -0700)]
drm/msm/gem: Drop obj lock in msm_gem_free_object()
The only reason we grabbed the lock was to satisfy a bunch of places
that WARN_ON() if called without the lock held. But this angers lockdep
which doesn't realize no one else can be holding the lock by the time we
end up destroying the object (and sees what would otherwise be a locking
inversion between reservation_ww_class_mutex and fs_reclaim).
Dmitry Baryshkov [Fri, 17 Jun 2022 23:24:33 +0000 (02:24 +0300)]
drm/msm/dp: rename second dp_display_enable()'s argument
To follow up recent changes, rename (and change type of) second
dp_display_enable()'s argument from generic u32 data to bool
force_link_train, which is later passed to dp_ctrl_on_stream().
Rob Clark [Wed, 29 Jun 2022 21:19:16 +0000 (14:19 -0700)]
drm/msm/gpu: Add GEM debug label to devcore
When trying to understand an iova fault devcore, once you figure out
which buffer we accessed beyond the end of, it is useful to see the
buffer's debug label.
Rob Clark [Wed, 29 Jun 2022 21:19:15 +0000 (14:19 -0700)]
drm/msm/gpu: Capture all BO addr+size in devcore
It is useful to know what buffers userspace thinks are associated with
the submit, even if we don't care to capture their content. This brings
things more inline with $debugfs/rd cmdstream dumping.
Dmitry Baryshkov [Thu, 16 Jun 2022 08:11:06 +0000 (11:11 +0300)]
drm/msm: switch msm_kms_init_aspace() to use device_iommu_mapped()
Change msm_kms_init_aspace() to use generic function
device_iommu_mapped() instead of the fwnode-specific interface
dev_iommu_fwspec_get(). While we are at it, stop referencing
platform_bus_type directly and use the bus of the IOMMU device.
Suggested-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/489703/ Link: https://lore.kernel.org/r/20220616081106.350262-6-dmitry.baryshkov@linaro.org Signed-off-by: Rob Clark <robdclark@chromium.org>
Dmitry Baryshkov [Thu, 16 Jun 2022 08:11:04 +0000 (11:11 +0300)]
drm/msm: Stop using iommu_present()
Even if some IOMMU has registered itself on the platform "bus", that
doesn't necessarily mean it provides translation for the device we
care about. Replace iommu_present() with a more appropriate check.
On Qualcomm platforms the IOMMU can be specified either for the MDP/DPU
device or for its parent MDSS device depending on the actual platform.
Check both of them, since that is how both DPU and MDP5 drivers work.
Co-developed-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/489699/ Link: https://lore.kernel.org/r/20220616081106.350262-4-dmitry.baryshkov@linaro.org Signed-off-by: Rob Clark <robdclark@chromium.org>
There are build warnings here which break the normal
build due to -Werror. Ratheesh was nice enough to quickly
follow up with fixes but didn't hit all the warnings I
see on GCC 12 so to unlock net-next from taking patches
let get this series out for now.
soc: ti: pruss: Enable support for PRUSS-M subsystem on K3 AM62x SoCs
The K3 AM62x family of SoC has one PRUSS-M instance and it has two
Programmable Real-Time Units (PRU0 and PRU1). This does not support
Industrial Communications Subsystem features like Ethernet.
The existing pruss platform driver has been updated to support this
through a new AM62x specific compatible.
TX doorbells may be postponed, because sometimes the driver knows that
another packet follows (for example, when xmit_more is true, or when a
MPWQE session is closed before transmitting a packet).
However, the DMA mapping may fail for the next packet, in which case a
new WQE is not posted, the doorbell isn't updated either, and the
transmission of the previous packet will be delayed indefinitely.
This commit fixes the described rare error flow by posting a NOP and
ringing the doorbell on errors to flush all the previous packets. The
MPWQE session is closed before that. DMA mapping in the MPWQE flow is
moved to the beginning of mlx5e_sq_xmit_mpwqe, because empty sessions
are not allowed. Stop room always has enough space for a NOP, because
the actual TX WQE is not posted.
Gal Pressman [Mon, 27 Jun 2022 12:05:53 +0000 (15:05 +0300)]
net/mlx5e: Fix capability check for updating vnic env counters
The existing capability check for vnic env counters only checks for
receive steering discards, although we need the counters update for the
exposed internal queue oob counter as well. This could result in the
latter counter not being updated correctly when the receive steering
discards counter is not supported.
Fix that by checking whether any counter is supported instead of only
the steering counter capability.
Fixes: 0cfafd4b4ddf ("net/mlx5e: Add device out of buffer counter") Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Roi Dayan [Tue, 21 Jun 2022 07:43:55 +0000 (10:43 +0300)]
net/mlx5e: CT: Use own workqueue instead of mlx5e priv
Allocate a ct priv workqueue instead of using mlx5e priv one
so flushing will only be of related CT entries.
Also move flushing of the workqueue before rhashtable destroy
otherwise entries won't be valid.
Fixes: b069e14fff46 ("net/mlx5e: CT: Fix queued up restore put() executing after relevant ft release") Signed-off-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Oz Shlomo <ozsh@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Liu, Changcheng [Fri, 27 May 2022 08:49:14 +0000 (16:49 +0800)]
net/mlx5: Lag, correct get the port select mode str
mode & mode_flags is updated at the end of mlx5_activate_lag which
may not reflect the actual mode as shown in below logic:
mlx5_activate_lag(struct mlx5_lag *ldev,
|-- unsigned long flags = 0;
|-- err = mlx5_lag_set_flags(ldev, mode, tracker, shared_fdb, &flags);
|-- err = mlx5_create_lag(ldev, tracker, mode, flags);
|-- mlx5_get_str_port_sel_mode(ldev);
|-- ldev->mode = mode;
|-- ldev->mode_flags = flags;
Use mode & flag as parameters to get port select mode info.
Fixes: 94db33177819 ("net/mlx5: Support multiport eswitch mode") Signed-off-by: Liu, Changcheng <jerrliu@nvidia.com> Reviewed-by: Eli Cohen <elic@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Paul Blakey [Wed, 22 Jun 2022 10:11:18 +0000 (13:11 +0300)]
net/mlx5e: Fix enabling sriov while tc nic rules are offloaded
There is a total of four 4M entries flow tables. In sriov disabled
mode, ct, ct_nat and post_act take three of them. When adding the
first tc nic rule in this mode, it will take another 4M table
for the tc <chain,prio> table. If user then enables sriov, the legacy
flow table tries to take another 4M and fails, and so enablement fails.
To fix that, have legacy fdb take the next available maximum
size from the fs ft pool.
Fixes: 4a98544d1827 ("net/mlx5: Move chains ft pool to be used by all firmware steering") Signed-off-by: Paul Blakey <paulb@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Mark Bloch [Tue, 24 May 2022 09:08:10 +0000 (12:08 +0300)]
net/mlx5: Lag, decouple FDB selection and shared FDB
Multiport eswitch is required to use native FDB selection instead of
affinity, This was achieved by passing the shared_fdb flag down
the HW lag creation path. While it did accomplish the goal of setting
FDB selection mode to native, it had the side effect of also
creating a shared FDB configuration.
This created a few issues:
- TC rules are inserted into a non active FDB, which means traffic isn't
offloaded as all traffic will reach only a single FDB.
- All wire traffic is treated as if a single physical port received it; while
this is true for a bond configuration, this shouldn't be the case for
multiport eswitch.
Create a new flag MLX5_LAG_MODE_FLAG_FDB_SEL_MODE_NATIVE
to indicate what FDB selection mode should be used.
Fixes: 94db33177819 ("net/mlx5: Support multiport eswitch mode") Signed-off-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Eli Cohen <elic@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
zonefs: Call page_address() on page acquired with GFP_KERNEL flag
zonefs_read_super() acquires a page with alloc_page(GFP_KERNEL). That
page cannot come from ZONE_HIGHMEM, thus there's no need to map it with
kmap().
Therefore, use a plain page_address() on that page.
Suggested-by: Ira Weiny <ira.weiny@intel.com> Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Ard Biesheuvel [Thu, 30 Jun 2022 15:46:54 +0000 (16:46 +0100)]
ARM: 9214/1: alignment: advance IT state after emulating Thumb instruction
After emulating a misaligned load or store issued in Thumb mode, we have
to advance the IT state by hand, or it will get out of sync with the
actual instruction stream, which means we'll end up applying the wrong
condition code to subsequent instructions. This might corrupt the
program state rather catastrophically.
So borrow the it_advance() helper from the probing code, and use it on
CPSR if the emulated instruction is Thumb.
Cc: <stable@vger.kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Dmitry Osipenko [Tue, 28 Jun 2022 07:55:45 +0000 (08:55 +0100)]
ARM: 9213/1: Print message about disabled Spectre workarounds only once
Print the message about disabled Spectre workarounds only once. The
message is printed each time CPU goes out from idling state on NVIDIA
Tegra boards, causing storm in KMSG that makes system unusable.
Cc: stable@vger.kernel.org Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Zhen Lei [Mon, 13 Jun 2022 14:05:41 +0000 (15:05 +0100)]
ARM: 9210/1: Mark the FDT_FIXED sections as shareable
commit 7a1be318f579 ("ARM: 9012/1: move device tree mapping out of linear
region") use FDT_FIXED_BASE to map the whole FDT_FIXED_SIZE memory area
which contains fdt. But it only reserves the exact physical memory that
fdt occupied. Unfortunately, this mapping is non-shareable. An illegal or
speculative read access can bring the RAM content from non-fdt zone into
cache, PIPT makes it to be hit by subsequently read access through
shareable mapping(such as linear mapping), and the cache consistency
between cores is lost due to non-shareable property.
1. CoreA read <non-fdt> through MT_ROM mapping, the old data is loaded
into the cache.
2. CoreB write <non-fdt> to update data through linear mapping. CoreA
received the notification to invalid the corresponding cachelines, but
the property non-shareable makes it to be ignored.
3. CoreA read <non-fdt> through linear mapping, cache hit, the old data
is read.
To eliminate this risk, add a new memory type MT_MEMORY_RO. Compared to
MT_ROM, it is shareable and non-executable.
The faulty list node to be deleted is a local variable, its address is c0ecbf74. The dumped stack shows that 'prev' = c0ecbf74, but its value
before lib/list_debug.c:53 is c08410dc. A large amount of printing results
in swapping out the cacheline containing the old data(MT_ROM mapping is
read only, so the cacheline cannot be dirty), and the subsequent dump
operation obtains new data from the DDR.
Fixes: 7a1be318f579 ("ARM: 9012/1: move device tree mapping out of linear region") Suggested-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>