~vicamo/hwe-next/+git/intermediate-kernel:bug-1950282/support-mediatek-t7xx-wwan/unstable

Last commit made on 2022-07-13
Get this branch:
git clone -b bug-1950282/support-mediatek-t7xx-wwan/unstable https://git.launchpad.net/~vicamo/hwe-next/+git/intermediate-kernel
Only You-Sheng Yang can upload to this branch. If you are You-Sheng Yang please log in for upload directions.

Branch information

Name:
bug-1950282/support-mediatek-t7xx-wwan/unstable
Repository:
lp:~vicamo/hwe-next/+git/intermediate-kernel

Recent commits

cd34315... by Haijun Liu <email address hidden>

UBUNTU: SAUCE: net: wwan: t7xx: Add AP CLDMA and GNSS port

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

The t7xx device contains two Cross Layer DMA (CLDMA) interfaces to
communicate with AP and Modem processors respectively. So far only
MD-CLDMA was being used, this patch enables AP-CLDMA and the GNSS
port which requires such channel.

GNSS AT control port allows Modem Manager to control GPS for:
- Start/Stop GNSS sessions,
- Configuration commands to support Assisted GNSS positioning
- Crash & reboot (notifications when resetting device (AP) & host)
- Settings to Enable/Disable GNSS solution
- Geofencing

Rename small Application Processor (sAP) to AP.

Signed-off-by: Haijun Liu <email address hidden>
Co-developed-by: Madhusmita Sahu <email address hidden>
Signed-off-by: Madhusmita Sahu <email address hidden>
Signed-off-by: Moises Veleta <email address hidden>

Change log in v2:
- Add to commit message renaming sAP to AP
- Add to commit message GNSS AT port info
- Lowercase X in constant prefix
- Add GNSS AT comment in static port file
Reviewed-by: Ilpo Järvinen <email address hidden>
Reviewed-by: M Chetan Kumar <email address hidden>
(cherry picked from commit
https://patchwork.kernel.<email address hidden>/)
Signed-off-by: You-Sheng Yang (vicamo) <email address hidden>

2576f23... by Imre Deak <email address hidden>

drm/dp/mst: Read the extended DPCD capabilities during system resume

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

The WD22TB4 Thunderbolt dock at least will revert its DP_MAX_LINK_RATE
from HBR3 to HBR2 after system suspend/resume if the DP_DP13_DPCD_REV
registers are not read subsequently also as required.

Fix this by reading DP_DP13_DPCD_REV registers as well, matching what is
done during connector detection. While at it also fix up the same call
in drm_dp_mst_dump_topology().

Cc: Lyude Paul <email address hidden>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5292
Signed-off-by: Imre Deak <email address hidden>
Reviewed-by: Jani Nikula <email address hidden>
Reviewed-by: Lyude Paul <email address hidden>
Ref: https://patchwork.freedesktop.org/patch/489424/?series=105101&rev=1
Signed-off-by: Koba Ko <email address hidden>

715fe91... by Pavel Skripkin <email address hidden>

UBUNTU: SAUCE: ath9k: fix use-after-free in ath9k_hif_usb_rx_cb

Syzbot reported use-after-free Read in ath9k_hif_usb_rx_cb() [0]. The
problem was in incorrect htc_handle->drv_priv initialization.

Probable call trace which can trigger use-after-free:

ath9k_htc_probe_device()
  /* htc_handle->drv_priv = priv; */
  ath9k_htc_wait_for_target() <--- Failed
  ieee80211_free_hw() <--- priv pointer is freed

<IRQ>
...
ath9k_hif_usb_rx_cb()
  ath9k_hif_usb_rx_stream()
   RX_STAT_INC() <--- htc_handle->drv_priv access

In order to not add fancy protection for drv_priv we can move
htc_handle->drv_priv initialization at the end of the
ath9k_htc_probe_device() and add helper macro to make
all *_STAT_* macros NULL safe, since syzbot has reported related NULL
deref in that macros [1]

Link: https://syzkaller.appspot.com/bug?id=6ead44e37afb6866ac0c7dd121b4ce07cb665f60 [0]
Link: https://syzkaller.appspot.com/bug?id=b8101ffcec107c0567a0cd8acbbacec91e9ee8de [1]
Fixes: fb9987d0f748 ("ath9k_htc: Support for AR9271 chipset.")
Reported-and-tested-by: <email address hidden>
Reported-and-tested-by: <email address hidden>
Signed-off-by: Pavel Skripkin <email address hidden>
Acked-by: Toke Høiland-Jørgensen <email address hidden>
Signed-off-by: Kalle Valo <email address hidden>
Link: https://lore.kernel.org/r/d57bbedc857950659bfacac0ab48790c1eda00c8<email address hidden>
(cherry picked from commit 0ac4827f78c7ffe8eef074bc010e7e34bc22f533 ath.git)
CVE-2022-1679
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>

1819b20... by Deren Wu

UBUNTU: SAUCE: mt76: mt7921: fix command timeout in AP stop period

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

Due to AP stop improperly, mt7921 driver would face random command timeout
by chip fw problem. Migrate AP start/stop process to .start_ap/.stop_ap and
congiure BSS network settings in both hooks.

The new flow is shown below.
* AP start
    .start_ap()
      configure BSS network resource
      set BSS to connected state
    .bss_info_changed()
      enable fw beacon offload

* AP stop
    .bss_info_changed()
      disable fw beacon offload (skip this command)
    .stop_ap()
      set BSS to disconnected state (beacon offload disabled automatically)
      destroy BSS network resource

Fixes: 116c69603b01 ("mt76: mt7921: Add AP mode support")
Signed-off-by: Sean Wang <email address hidden>
Signed-off-by: Deren Wu <email address hidden>
(cherry picked from https://patchwork.kernel.org/project/linux-wireless/patch/<email address hidden>/)
Signed-off-by: You-Sheng Yang (vicamo) <email address hidden>

9751ef8... by Deren Wu

UBUNTU: SAUCE: mt76: mt7921: not support beacon offload disable command

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

Beacon disable flow would be handled in bss stop handler automatically.
Force return -EOPNOTSUPP in disable case.

Fixes: 116c69603b01 ("mt76: mt7921: Add AP mode support")
Reviewed-by: Sean Wang <email address hidden>
Signed-off-by: Deren Wu <email address hidden>
(cherry picked from https://patchwork.kernel.org/project/linux-mediatek/patch/<email address hidden>/)
Signed-off-by: Chris Chiu <email address hidden>

37770a7... by You-Sheng Yang

UBUNTU: SAUCE: vmd: fixup bridge ASPM by driver name instead

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

Additional VMD bridge IDs needed for new Alder Lake platforms, but
actually there is no a complete list for them. Here we match bridge
devices if they're directly attached to a VMD controller instead.

Signed-off-by: You-Sheng Yang <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>

d636c3f... by Kai-Heng Feng

UBUNTU: SAUCE: PCI/ASPM: Enable LTR for endpoints behind VMD

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

In addition to ASPM, LTR also needs to be programmed with a reasonable
value to let PCIe link reaches L1.2.

For now, program a hardcoded value that is used under Windows.

While at it, consolidate ASPM and LTR enabling logic to share a same pci
device table.

Signed-off-by: Kai-Heng Feng <email address hidden>
Signed-off-by: Seth Forshee <email address hidden>

814e0e4... by Kai-Heng Feng

UBUNTU: SAUCE: PCI/ASPM: Enable ASPM for links under VMD domain

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

New Intel laptops with VMD cannot reach deeper power saving state,
renders very short battery time.

As BIOS may not be able to program the config space for devices under
VMD domain, ASPM needs to be programmed manually by software. This is
also the case under Windows.

The VMD controller itself is a root complex integrated endpoint that
doesn't have ASPM capability, so we can't propagate the ASPM settings to
devices under it. Hence, simply apply ASPM_STATE_ALL to the links under
VMD domain, unsupported states will be cleared out anyway.

Signed-off-by: Kai-Heng Feng <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Seth Forshee <email address hidden>

a7677fe... by You-Sheng Yang

UBUNTU: [Config] enable X86_AMD_PSTATE as built-in on amd64

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

X86_AMD_PSTATE must be a built-in module so that it may take take
precedence over acpi-cpufreq.

Signed-off-by: You-Sheng Yang <email address hidden>

4dc709b... by Andrea Righi

UBUNTU: Ubuntu-unstable-5.19.0-6.6

Signed-off-by: Andrea Righi <email address hidden>