~nathan-sweetman/ubuntu/+source/linux/+git/jammy:master-prep

Last commit made on 2022-08-26
Get this branch:
git clone -b master-prep https://git.launchpad.net/~nathan-sweetman/ubuntu/+source/linux/+git/jammy
Only Nathan Sweetman can upload to this branch. If you are Nathan Sweetman please log in for upload directions.

Branch merges

Branch information

Recent commits

941bdeb... by Stefan Bader

UBUNTU: Ubuntu-5.15.0-48.54

Signed-off-by: Stefan Bader <email address hidden>

b03ce09... by Stefan Bader

UBUNTU: link-to-tracker: update tracking bug

BugLink: https://bugs.launchpad.net/bugs/1987775
Properties: no-test-build
Signed-off-by: Stefan Bader <email address hidden>

ad0f2ad... by AceLan Kao

UBUNTU: SAUCE: whitelist platforms that needs save/restore ASPM L1SS for suspend/resume

BugLink: https://bugs.launchpad.net/bugs/1980829

Add a DMI quirk for the previous commit
"PCI/ASPM: Save/restore L1SS Capability for suspend/resume"
The DMI quirk lists the platforms that needs this patch, and also
applied the concept of the below commit to not call
pcie_aspm_pm_state_change() if the platform is listed in the whitelist
https://patchwork.ozlabs.org<email address hidden>/

v2.
   1. added the missing null terminator at the end of the quirk
   2. changed the DMI match for LENOVO to its DMI_BIOS_VERSION

Signed-off-by: Chia-Lin Kao (AceLan) <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Kai-Heng Feng <email address hidden>
Acked-by: Aaron Ma <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>

218afb8... by Vidya Sagar <email address hidden>

UBUNTU: SAUCE: PCI/ASPM: Save/restore L1SS Capability for suspend/resume

BugLink: https://bugs.launchpad.net/bugs/1980829

Previously ASPM L1 Substates control registers (CTL1 and CTL2) weren't
saved and restored during suspend/resume leading to L1 Substates
configuration being lost post-resume.

Save the L1 Substates control registers so that the configuration is
retained post-resume.

Signed-off-by: Vidya Sagar <email address hidden>
Tested-by: Abhishek Sahu <email address hidden>

(cherry picked from commit https://patchwork.<email address hidden>/)
Signed-off-by: Chia-Lin Kao (AceLan) <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Kai-Heng Feng <email address hidden>
Acked-by: Aaron Ma <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>

abedf8a... by =?utf-8?q?Jouni_H=C3=B6gander?= <email address hidden>

UBUNTU: SAUCE: drm/i915: Use luminance range calculated during edid parsing

BugLink: https://bugs.launchpad.net/bugs/1978986

Instead of using fixed 0 - 512 range use luminance range calculated
as a part of edid parsing. As a backup fall back to static 0 - 512.

v3: Clean-ups suggested by Jani Nikula
v2: Use values calculated during edid parsing

Cc: Lyude Paul <email address hidden>
Cc: Mika Kahola <email address hidden>
Cc: Jani Nikula <email address hidden>
Cc: Manasi Navare <email address hidden>
Signed-off-by: Jouni Högander <email address hidden>
Signed-off-by: Jani Nikula <email address hidden>
Link: https://patchwork.freedesktop<email address hidden>

(cherry picked from commit 3bd86801c84f66b4abedde4078e5237937b7576b https://anongit.freedesktop.org/git/drm/drm-misc.git drm-misc-next)
Signed-off-by: Aaron Ma <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>

f0244f6... by =?utf-8?q?Jouni_H=C3=B6gander?= <email address hidden>

UBUNTU: SAUCE: drm/amdgpu_dm: Rely on split out luminance calculation function

BugLink: https://bugs.launchpad.net/bugs/1978986

Luminance range calculation was split out into drm_edid.c and is now
part of edid parsing. Rely on values calculated during edid parsing and
use these for caps->aux_max_input_signal and caps->aux_min_input_signal.

v2: Use values calculated during edid parsing

Cc: Roman Li <email address hidden>
Cc: Rodrigo Siqueira <email address hidden>
Cc: Harry Wentland <email address hidden>
Cc: Lyude Paul <email address hidden>
Cc: Mika Kahola <email address hidden>
Cc: Jani Nikula <email address hidden>
Cc: Manasi Navare <email address hidden>
Signed-off-by: Jouni Högander <email address hidden>
Acked-by: Alex Deucher <email address hidden>
Signed-off-by: Jani Nikula <email address hidden>
Link: https://patchwork.freedesktop<email address hidden>

(cherry picked from commit a61bb3422e8d6ec002dbe288356470540eb5662c https://anongit.freedesktop.org/git/drm/drm-misc.git drm-misc-next)
Signed-off-by: Aaron Ma <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>

2a6a037... by =?utf-8?q?Jouni_H=C3=B6gander?= <email address hidden>

UBUNTU: SAUCE: drm: New function to get luminance range based on static hdr metadata

BugLink: https://bugs.launchpad.net/bugs/1978986

Split luminance min/max calculation using static hdr metadata from
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:update_connector_ext_caps
into drm/drm_edid.c and use it during edid parsing. Calculated range is
stored into connector->display_info->luminance_range.

Add new data structure (drm_luminance_range_inf) to store luminance range
calculated using data from EDID's static hdr metadata block. Add this new
struct as a part of drm_display_info struct.

v3: Squashed adding drm_luminance_range_info patch here
v2: Calculate range during edid parsing

Cc: Roman Li <email address hidden>
Cc: Rodrigo Siqueira <email address hidden>
Cc: Harry Wentland <email address hidden>
Cc: Lyude Paul <email address hidden>
Cc: Mika Kahola <email address hidden>
Cc: Jani Nikula <email address hidden>
Cc: Manasi Navare <email address hidden>
Signed-off-by: Jouni Högander <email address hidden>
Signed-off-by: Jani Nikula <email address hidden>
Link: https://patchwork.freedesktop<email address hidden>

(backported from commit 82068edeb5090b6f999457483623b39b6546ef74 https://anongit.freedesktop.org/git/drm/drm-misc.git drm-misc-next)
[ aaron.ma: context adjustments ]
Signed-off-by: Aaron Ma <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>

68d2f94... by Ariel Levkovich <email address hidden>

net/mlx5e: TC, fix decap fallback to uplink when int port not supported

BugLink: https://bugs.launchpad.net/bugs/1983498

When resolving the decap route device for a tunnel decap rule,
the result may be an OVS internal port device.

Prior to adding the support for internal port offload, such case
would result in using the uplink as the default decap route device
which allowed devices that can't support internal port offload
to offload this decap rule.

This behavior got broken by adding the internal port offload which
will fail in case the device can't support internal port offload.

To restore the old behavior, use the uplink device as the decap
route as before when internal port offload is not supported.

Fixes: b16eb3c81fe2 ("net/mlx5: Support internal port as decap route device")
Signed-off-by: Ariel Levkovich <email address hidden>
Reviewed-by: Maor Dickman <email address hidden>
Signed-off-by: Saeed Mahameed <email address hidden>
(cherry picked from commit e3fdc71bcb6ffe1d4870a89252ba296a9558e294)
Signed-off-by: Zachary Tahenakos <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>

d089f2b... by Ariel Levkovich <email address hidden>

net/mlx5e: Fix wrong source vport matching on tunnel rule

BugLink: https://bugs.launchpad.net/bugs/1983498

When OVS internal port is the vtep device, the first decap
rule is matching on the internal port's vport metadata value
and then changes the metadata to be the uplink's value.

Therefore, following rules on the tunnel, in chain > 0, should
avoid matching on internal port metadata and use the uplink
vport metadata instead.

Select the uplink's metadata value for the source vport match
in case the rule is in chain greater than zero, even if the tunnel
route device is internal port.

Fixes: 166f431ec6be ("net/mlx5e: Add indirect tc offload of ovs internal port")
Signed-off-by: Ariel Levkovich <email address hidden>
Reviewed-by: Maor Dickman <email address hidden>
Signed-off-by: Saeed Mahameed <email address hidden>
(cherry picked from commit cb0d54cbf94866b48a73e10a73a55655f808cc7c)
Signed-off-by: Zachary Tahenakos <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>

cb6900b... by Roi Dayan

net/mlx5e: Avoid implicit modify hdr for decap drop rule

BugLink: https://bugs.launchpad.net/bugs/1983498

Currently the driver adds implicit modify hdr action for
decap rules on tunnel devices if the port is an ovs port.
This is also done if the action is drop and makes the modify
hdr redundant and also the FW doesn't support it and will generate
a syndrome.

kernel: mlx5_core 0000:08:00.0: mlx5_cmd_check:777:(pid 102063): SET_FLOW_TABLE_ENTRY(0x936) op_mod(0x0) failed, status bad parameter(0x3), syndrome (0x8708c3)

Fix it by adding the implicit modify hdr only for fwd actions.

Fixes: b16eb3c81fe2 ("net/mlx5: Support internal port as decap route device")
Fixes: 077cdda764c7 ("net/mlx5e: TC, Fix memory leak with rules with internal port")
Signed-off-by: Roi Dayan <email address hidden>
Reviewed-by: Ariel Levkovich <email address hidden>
Signed-off-by: Saeed Mahameed <email address hidden>
(cherry picked from commit 5b209d1a22afabfb7d644abb10510c5713a3e569)
Signed-off-by: Zachary Tahenakos <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>