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>
BugLink: https://bugs.launchpad.net/bugs/1966194
According to the HW spec, vport number is a 16-bit value.
Fix vport usage all over the code to u16 data type.
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 f9f93bd55ca6b41eb4c297748e0014147921c295) 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>
Hui Wang [Fri, 18 Mar 2022 04:22:31 +0000 (12:22 +0800)]
UBUNTU: [Config] Add cirruslogic side codec support
BugLink: https://bugs.launchpad.net/bugs/1965496 Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Lucas Tanure [Fri, 21 Jan 2022 17:24:31 +0000 (17:24 +0000)]
ACPI / scan: Create platform device for CS35L41
BugLink: https://bugs.launchpad.net/bugs/1965496
The ACPI device with CSC3551 or CLSA0100 are sound cards
with multiple instances of CS35L41 connected by I2C or SPI
to the main CPU.
We add an ID to the ignore_serial_bus_ids list to enumerate
all I2C or SPI devices correctly.
The same IDs are also added into serial-multi-instantiate
so that the driver can correctly enumerate the ACPI.
Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com> Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220121172431.6876-10-sbinding@opensource.cirrus.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit d9c01c530cc5e3b6d5bdfeae12c3d0f33fae7498) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com> Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20220121172431.6876-9-sbinding@opensource.cirrus.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
(backported from commit 07bcab93946cd9980f8eafe89afe991cd918acb0) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Some peripherals can have either a I2C or a SPI connection
to the host (but not both) but use the same HID for both
types. So it is not possible to use the HID to determine
whether it is I2C or SPI. The driver must check the node
to see if it contains I2cSerialBus or SpiSerialBus entries.
For backwards-compatibility with the existing nodes I2C is
checked first and if such entries are found ONLY I2C devices
are created. Since some existing nodes that were already
handled by this driver could also contain unrelated
SpiSerialBus nodes that were previously ignored, and this
preserves that behavior. If there is ever a need to handle
a node where both I2C and SPI devices must be instantiated
this can be added in future.
BugLink: https://bugs.launchpad.net/bugs/1965496
Reorganize I2C functions to accommodate SPI support
Split the probe and factor out parts of the code
that will be used in the SPI support
Also switched from strlcpy() to strscpy()
Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com> Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220121172431.6876-7-sbinding@opensource.cirrus.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit 35a36cbb7b1ce7596fc03962f7ce261b2e908d1f) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com> Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220121172431.6876-6-sbinding@opensource.cirrus.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit 5e63b2ea3dfbab9307e197004a3c5ee4e1442582) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Stefan Binding [Fri, 21 Jan 2022 17:24:26 +0000 (17:24 +0000)]
spi: Add API to count spi acpi resources
BugLink: https://bugs.launchpad.net/bugs/1965496
Some ACPI nodes may have more than one Spi Resource.
To be able to handle these case, its necessary to have
a way of counting these resources.
Stefan Binding [Fri, 21 Jan 2022 17:24:25 +0000 (17:24 +0000)]
spi: Support selection of the index of the ACPI Spi Resource before alloc
BugLink: https://bugs.launchpad.net/bugs/1965496
If a node contains more than one SPI resource it may be necessary to
use an index to select which one you want to allocate a spi device for.
The above commit was added to prevent the tipd driver from loading
in devices which have INT3515 ACPI nodes since high CPU load was
reported in these devices due to interrupt flood. Now that the issue
of interrupt flood in the tipd driver is fixed, re-enable the creation
of platform device for INT3515 ACPI nodes.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Saranya Gopal <saranya.gopal@intel.com> Link: https://lore.kernel.org/r/20211020022620.21012-3-saranya.gopal@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 6e4d56db30a5feb83ba233a68841ba79483e7731) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
ALSA: hda/realtek: fix speakers and micmute on HP 855 G8
BugLink: https://bugs.launchpad.net/bugs/1965496
There are several PCI ids associated with HP EliteBook 855 G8 Notebook
PC. Commit 0e68c4b11f1e6 ("ALSA: hda/realtek: fix mute/micmute LEDs for
HP 855 G8") covers 0x103c:0x8896, while this commit covers 0x103c:0x8895
which needs some additional work on top of the quirk from 0e68c4b11f1e6.
Note that the device can boot up with working speakers and micmute LED
without this patch, but the success rate would be quite low (order of
16 working boots across 709 boots) at least for the built-in drivers
scenario. This also means that there are some timing issues during early
boot and this patch is a workaround.
With this patch applied speakers and headphones are consistenly working,
as well as mute/micmute LEDs and the internal microphone.
Uwe Kleine-König [Mon, 17 Jan 2022 22:00:55 +0000 (23:00 +0100)]
ALSA: hda: cs35l41: Make cs35l41_hda_remove() return void
BugLink: https://bugs.launchpad.net/bugs/1965496
Up to now cs35l41_hda_remove() returns zero unconditionally. Make it
return void instead which makes it easier to see in the callers that
there is no error to handle.
Also the return value of i2c and spi remove callbacks is ignored anyway.
Lucas Tanure [Mon, 17 Jan 2022 16:08:29 +0000 (16:08 +0000)]
ALSA: hda: cs35l41: Make use of the helper function dev_err_probe()
BugLink: https://bugs.launchpad.net/bugs/1965496
When possible use dev_err_probe help to properly deal with the
PROBE_DEFER error, the benefit is that DEFER issue will be logged
in the devices_deferred debugfs file.
Using dev_err_probe() can reduce code size, and the error value
gets printed.
Fixes: f517ba4924ad ("ASoC: cs35l41: Add support for hibernate memory retention mode") Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220117160830.709403-2-tanureal@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 6e4320d8ecbc8711209b3075f2d896667006fa37) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1965496
regmap_register_patch can't be used to apply the probe sequence as a
patch is already registers with the regmap by
cs35l41_register_errata_patch and only a single patch can be attached to
a single regmap. The driver doesn't currently rely on a cache sync to
re-apply this probe sequence so simply switch it to a multi write.
Fixes: 7b2f3eb492da ("ALSA: hda: cs35l41: Add support for CS35L41 in HDA systems") Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220117160830.709403-1-tanureal@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 2cb52046d186863e16ac82850c0e225462e493f1) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Fixes: 7b2f3eb492da ("ALSA: hda: cs35l41: Add support for CS35L41 in HDA systems") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20220111072232.GG11243@kili Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 10b1a5a99c6ac42be7a490676aec626fba28b048) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Charles Keepax [Fri, 7 Jan 2022 16:06:36 +0000 (16:06 +0000)]
ASoC: cs35l41: Add support for hibernate memory retention mode
BugLink: https://bugs.launchpad.net/bugs/1965496
The cs35l41 supports a low power DSP memory retention mode. Add support
for entering this mode when then device is not in use.
Co-authored-by: David Rhodes <david.rhodes@cirrus.com> Signed-off-by: David Rhodes <david.rhodes@cirrus.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220107160636.6555-3-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
(backported from commit f517ba4924ad026f2583553db02f3c8bc69de88b) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Charles Keepax [Fri, 7 Jan 2022 16:06:35 +0000 (16:06 +0000)]
ASoC: cs35l41: Update handling of test key registers
BugLink: https://bugs.launchpad.net/bugs/1965496
In preparation for the addition of PM runtime support move the test
key out of the register patches themselves. This is necessary to
allow the test key to be held during cache synchronisation, which is
required by the OTP settings which were unpacked from the device and
written by the driver.
Also whilst at it, the driver uses a mixture of accessing the test key
register by name and by address, consistently use the name.
Charles Keepax [Wed, 5 Jan 2022 11:30:22 +0000 (11:30 +0000)]
ASoC: cs35l41: Correct handling of some registers in the cache
BugLink: https://bugs.launchpad.net/bugs/1965496
It makes no sense to cache the test/user key registers, since they
require values written at specific times, mark them volatile. It is
probably best if they can't be accessed from user-space either, so
mark them precious as well.
The interrupt force, edge, polarity and debounce are all settings
applied to the IRQ rather than status bits and as such should not be
volatile.
The OTP trim values will require re-application in the event of a
cache sync and as such should not be volatile. The OTPID however
should be volatile.
The DSP scratch registers are used to read back an error/debug code
from the DSP on shutdown, as such these should be marked volatile.
Finally, add some missing defaults, add TST_FS_MON0, and allow the
DSP core control register to be cached.
Charles Keepax [Wed, 5 Jan 2022 11:30:21 +0000 (11:30 +0000)]
ASoC: cs35l41: Correct DSP power down
BugLink: https://bugs.launchpad.net/bugs/1965496
The wm_adsp_event should be called before the early_event on power
down, event stops the core running and early_event then powers down
the core. Additionally, the core should only be stopped if it was
actually running in the first place.
Charles Keepax [Wed, 5 Jan 2022 11:30:20 +0000 (11:30 +0000)]
ASoC: cs35l41: Remove incorrect comment
BugLink: https://bugs.launchpad.net/bugs/1965496
The IRQ is not used for the PDN_DONE bit, this is polled during the DAPM
sequence, remove the misleading comment.
Lucas Tanure [Fri, 17 Dec 2021 11:57:02 +0000 (11:57 +0000)]
ASoC: cs35l41: Create shared function for errata patches
BugLink: https://bugs.launchpad.net/bugs/1965496
ASoC and HDA systems require the same errata patches, so
move it to the shared code using a function the correctly
applies the patches by revision
Also, move CS35L41_DSP1_CCM_CORE_CTRL write to errata
patch function as is required to be written at boot,
but not in regmap_register_patch sequence as will affect
waking up from hibernation
Lucas Tanure [Fri, 17 Dec 2021 11:57:01 +0000 (11:57 +0000)]
ASoC: cs35l41: Move power initializations to reg_sequence
BugLink: https://bugs.launchpad.net/bugs/1965496
ASoC and HDA systems for all revisions of CS35L41 will benefit
from having this initialization, so add it to reg_sequence of
each revision
By moving to reg_sequence all gains are set to zero. And boost,
monitoring parts, and class D amplifier are disabled.
Lucas Tanure [Fri, 17 Dec 2021 11:56:59 +0000 (11:56 +0000)]
ASoC: cs35l41: Convert tables to shared source code
BugLink: https://bugs.launchpad.net/bugs/1965496
To support CS35L41 in HDA systems the HDA driver
for CS35L41 would have to duplicate some functions
that already exist on ASoC driver
So instead of duplicate the code, use the new lib
source as a shared resource for both ASoC and HDA
Also, change the way CONFIG_SND_SOC_CS35L41 is
selected, as reported by Intel Kernel test robot,
it is possible to build SND_SOC_CS35L41_SPI/I2C
without the main driver, which would lead to build
failures.
Fixes: a5e0091d62ab ("ASoC: cs35l41: Fix link problem") Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com> Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/r/20211201180004.1402156-2-tanureal@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 0695ad92fe1a0bb7697eb92c6a145a73c5ab0e24) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Lucas Tanure [Thu, 25 Nov 2021 14:35:01 +0000 (14:35 +0000)]
ASoC: cs35l41: Fix link problem
BugLink: https://bugs.launchpad.net/bugs/1965496
Can't link I2C and SPI to the same binary, better
to move CS35L41 to 3 modules approach.
And instead of exposing cs35l41_reg, volatile_reg,
readable_reg and precious_reg arrays, move
cs35l41_regmap_i2c/spi to new module and expose it.
Lucas Tanure [Tue, 23 Nov 2021 16:31:39 +0000 (16:31 +0000)]
ASoC: cs35l41: Set the max SPI speed for the whole device
BugLink: https://bugs.launchpad.net/bugs/1965496
Higher speeds are only supported when PLL is enabled, but
the current driver doesn't enable PLL outside of stream
use cases, so better to set the lowest SPI speed accepted
by the entire device.
Move the current frequency set to the spi sub-driver so
the whole device can benefit from that speed.
spi-max-frequency property could be used, but ACPI systems don't
support it, so by setting it in the spi sub-driver probe
both Device Trees and ACPI systems are supported.
Charles Keepax [Fri, 29 Oct 2021 21:40:27 +0000 (16:40 -0500)]
ASoC: cs35l41: Change monitor widgets to siggens
BugLink: https://bugs.launchpad.net/bugs/1965496
Currently the internal monitor sources are input widgets, which means
if the card is set to fully routed these will not enable unless connected
to something in the machine driver. However, all these are internal
monitor signals so it makes no sense to connect them to something in the
machine driver. As such switch them to siggen widgets which will have
the same behaviour except not require external linkage on a fully routed
card.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: David Rhodes <drhodes@opensource.cirrus.com> Link: https://lore.kernel.org/r/20211029214028.401284-1-drhodes@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit a2697972b9369c41afea8a928c30ac5b7f28d292) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Uwe Kleine-König [Wed, 20 Oct 2021 13:24:16 +0000 (15:24 +0200)]
ASoC: cs35l41: Make cs35l41_remove() return void
BugLink: https://bugs.launchpad.net/bugs/1965496
Up to now cs35l41_remove() returns zero unconditionally. Make it
return void instead which makes it easier to see in the callers that
there is no error to handle.
Also the return value of i2c, platform and spi remove callbacks is
ignored anyway.
Fixes: c2f14cc2bcdd ("ASoC: cs35l41: Fix use of an uninitialised variable") Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20210916082346.12001-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit c6d1fa6c8f663bd49bfe7a20eccb0dc7e43db63a) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com>
Charles Keepax [Tue, 14 Sep 2021 14:13:48 +0000 (15:13 +0100)]
ASoC: cs35l41: Fixup the error messages
BugLink: https://bugs.launchpad.net/bugs/1965496
It is not idiomatic for ASoC to print the function name in the error
messages, however it is expected to show the return code. Update the
error messages to follow these conventions.
Charles Keepax [Tue, 14 Sep 2021 14:13:47 +0000 (15:13 +0100)]
ASoC: cs35l41: Don't overwrite returned error code
BugLink: https://bugs.launchpad.net/bugs/1965496
In multiple places the driver overwrites the error code returned with
a static error code, this is not helpful for debugging. Update to pass
the error codes straight through.
Charles Keepax [Tue, 14 Sep 2021 14:13:46 +0000 (15:13 +0100)]
ASoC: cs35l41: Combine adjacent register writes
BugLink: https://bugs.launchpad.net/bugs/1965496
cs35l41 is often connected over I2C which is a very slow bus, as such
timings can be greatly improved combining writes where acceptable.
Update several points where the driver does multiple register writes
when a single one would suffice.
projects / mirror_ubuntu-jammy-kernel.git / log