Commit graph

1,385,397 commits

Author SHA1 Message Date
Linus Torvalds
e4c995f92b - Make sure the PEBS buffer is drained before reconfiguring the hardware
- Add Arrow Lake U support
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEzv7L6UO9uDPlPSfHEsHwGGHeVUoFAmdWwkMACgkQEsHwGGHe
 VUo6Kg//eYVDupSP5cNXm2oxD5AInuVbZyDxZcuQK2ru8H/X0Jp2y1nQV43e1nfj
 27iA7mc1qRSZju1GMQium21zXLjMx0+/J97y0I8uSr06l8u32zotWt8CbWDtUR5m
 0yt0jeUC1rEpZuYnJMMEZL9hVapEpZSkIIkV0jggnEPIxzeNu+zAeS9ONIJEHDR+
 UYxsgsTBj0hHIBVf/3AMVtxg6SldNLoPYh2yJxeoc4PNCKkEaXuTuxdZjWGUK3Fq
 mK1Dken+YFT4G2sxv7kRMUjUtbFjy1dZ3DvkolxFS6eSbylD4Bava5zbS52Nh7PC
 9tE0hPk5GA0bCNMPRdOqBWesc9VLvLjQrBh/qWIh9dIrjDmg7EpnAWerKt5RFlVy
 AHTicA99OY5LAUasenucFqx2C6I8yw+03oLKIFYyYEtoSxI+sGq+gT9SWuEQh1u2
 GnUgneZ1+z0WhYg4aU1/6nnN0vhzqJ3+BKasOd7D/ZnrrOpahDTD05pQrO3ET8rq
 YbIXOykh3t9A5sxOcgwZSodKcOfc4B96Zf7P2Tn8s8j5JSK3aBSZrWgvdQ18FfwU
 Ne3Ylw/or+xT2T+x3KBSzouvQidCqMVz2gjMX/yHdeS5dY1Tt6zlymZQnhkHDvGd
 2ljueYBUtbpkraB3pd0aLi2O116p1UAV7Y2ks+823oJBW+rcqp8=
 =X7zT
 -----END PGP SIGNATURE-----

Merge tag 'perf_urgent_for_v6.13_rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Pull x86 perf fixes from Borislav Petkov:

 - Make sure the PEBS buffer is drained before reconfiguring the
   hardware

 - Add Arrow Lake U support

* tag 'perf_urgent_for_v6.13_rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf/x86/intel/ds: Unconditionally drain PEBS DS when changing PEBS_DATA_CFG
  perf/x86/intel: Add Arrow Lake U support
2024-12-09 10:31:35 -08:00
Linus Torvalds
df9e2102de - Remove wrong enqueueing of a task for a later wakeup when a task blocks on
a RT mutex
 
 - Do not setup a new deadline entity on a boosted task as that has happened
   already
 
 - Update preempt= kernel command line param
 
 - Prevent needless softirqd wakeups in the idle task's context
 
 - Detect the case where the idle load balancer CPU becomes busy and avoid
   unnecessary load balancing invocation
 
 - Remove an unnecessary load balancing need_resched() call in nohz_csd_func()
 
 - Allow for raising of SCHED_SOFTIRQ softirq type on RT but retain the warning
   to catch any other cases
 
 - Remove a wrong warning when a cpuset update makes the task affinity no
   longer a subset of the cpuset
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEzv7L6UO9uDPlPSfHEsHwGGHeVUoFAmdWvHYACgkQEsHwGGHe
 VUrJ6g//eEwmHpa9+at3UvXrVlcYQmZsQpgL2ksjVE0n4KXFeUavwCR4h6SJzvcD
 RDF9AyDuPAoCqy5DhL5wTXPG/4AnnISqAEkoP7h7YO76P7ks6+HD7t31pCF/uqCH
 yqS4vc1RJ6yW8otcCpR7rOPEQ49Klqc1KTFTNAFLc6MNEb/SVH5Ih+wFL5Mj/W3I
 UkBEtUy1oR2Q4QPhJ+0sr0LAI1AwjykdbkWzOhs6D1kPaRqdV4Atgc2fwioLIvhO
 s++lev9BmGx02dmrRWRmIBL9S9ycSLT1qx28sbzlS+PZMGYqOnImVOW5+EPr+ovK
 fILc0m8sLD6GyZHIPgeIT2+DqSvDTQOGQwXyUYmoarI+BWGGSz6iZGn4RrZHMRQo
 cpqYV9z7F2t3X1hPfhrH+40BXJeMMX+wd4ahXNA44QD6Bf7I+zPUfsrfnrR4BwV7
 qpXhBzXOuZrgOKolIwJmHIxyLtd79idYccGvjIME5rwj8eBg0J7zmjzoVewqUXsb
 F9ualvq6twxUIdD4XiClpi+E16Z2Ot3PplNIohosVrUDRDUgvTBbTuDZnUuOkXbb
 wV26XKuYKQYfx5UfJBSYL3DCfCttkKCVrPX2oiqw6PKNXw9BM8BQIux+XQH2jvIg
 wOPqZWZf2VIoQJU2N+twc/BAIRAF7CNr/ioTJlXQ1hsOIlTp3kk=
 =XLf1
 -----END PGP SIGNATURE-----

Merge tag 'sched_urgent_for_v6.13_rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Pull scheduler fixes from Borislav Petkov:

 - Remove wrong enqueueing of a task for a later wakeup when a task
   blocks on a RT mutex

 - Do not setup a new deadline entity on a boosted task as that has
   happened already

 - Update preempt= kernel command line param

 - Prevent needless softirqd wakeups in the idle task's context

 - Detect the case where the idle load balancer CPU becomes busy and
   avoid unnecessary load balancing invocation

 - Remove an unnecessary load balancing need_resched() call in
   nohz_csd_func()

 - Allow for raising of SCHED_SOFTIRQ softirq type on RT but retain the
   warning to catch any other cases

 - Remove a wrong warning when a cpuset update makes the task affinity
   no longer a subset of the cpuset

* tag 'sched_urgent_for_v6.13_rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  locking: rtmutex: Fix wake_q logic in task_blocks_on_rt_mutex
  sched/deadline: Fix warning in migrate_enable for boosted tasks
  sched/core: Update kernel boot parameters for LAZY preempt.
  sched/core: Prevent wakeup of ksoftirqd during idle load balance
  sched/fair: Check idle_cpu() before need_resched() to detect ilb CPU turning busy
  sched/core: Remove the unnecessary need_resched() check in nohz_csd_func()
  softirq: Allow raising SCHED_SOFTIRQ from SMP-call-function on RT kernel
  sched: fix warning in sched_setaffinity
  sched/deadline: Fix replenish_dl_new_period dl_server condition
2024-12-09 10:28:55 -08:00
Damien Le Moal
aeb6893761 x86: Fix build regression with CONFIG_KEXEC_JUMP enabled
Build 6.13-rc12 for x86_64 with gcc 14.2.1 fails with the error:

  ld: vmlinux.o: in function `virtual_mapped':
  linux/arch/x86/kernel/relocate_kernel_64.S:249:(.text+0x5915b): undefined reference to `saved_context_gdt_desc'

when CONFIG_KEXEC_JUMP is enabled.

This was introduced by commit 07fa619f2a ("x86/kexec: Restore GDT on
return from ::preserve_context kexec") which introduced a use of
saved_context_gdt_desc without a declaration for it.

Fix that by including asm/asm-offsets.h where saved_context_gdt_desc
is defined (indirectly in include/generated/asm-offsets.h which
asm/asm-offsets.h includes).

Fixes: 07fa619f2a ("x86/kexec: Restore GDT on return from ::preserve_context kexec")
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
Acked-by: David Woodhouse <dwmw@amazon.co.uk>
Closes: https://lore.kernel.org/oe-kbuild-all/202411270006.ZyyzpYf8-lkp@intel.com/
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-12-09 10:13:28 -08:00
Linus Torvalds
32913f3482 futex: fix user access on powerpc
The powerpc user access code is special, and unlike other architectures
distinguishes between user access for reading and writing.

And commit 43a43faf53 ("futex: improve user space accesses") messed
that up.  It went undetected elsewhere, but caused ppc32 to fail early
during boot, because the user access had been started with
user_read_access_begin(), but then finished off with just a plain
"user_access_end()".

Note that the address-masking user access helpers don't even have that
read-vs-write distinction, so if powerpc ever wants to do address
masking tricks, we'll have to do some extra work for it.

[ Make sure to also do it for the EFAULT case, as pointed out by
  Christophe Leroy ]

Reported-by: Andreas Schwab <schwab@linux-m68k.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Link: https://lore.kernel.org/all/87bjxl6b0i.fsf@igel.home/
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-12-09 10:00:25 -08:00
Mykyta Yatsenko
82c1f13de3 selftests/bpf: Add more stats into veristat
Extend veristat to collect and print more stats, namely:
  - program size in instructions
  - jited program size in bytes
  - program type
  - attach type
  - stack depth

Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20241209130455.94592-1-mykyta.yatsenko5@gmail.com
2024-12-09 09:57:51 -08:00
Marek Vasut
41e12cebd9 ARM: dts: stm32: Sort M24256E write-lockable page in DH STM32MP13xx DHCOR SoM DT
Move the M24256E write-lockable page subnode after RTC subnode in
DH STM32MP13xx DHCOR SoM DT to keep the list of nodes sorted by I2C
address. No functional change.

Fixes: 3f2e7d1673 ("ARM: dts: stm32: Describe M24256E write-lockable page in DH STM32MP13xx DHCOR SoM DT")
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-12-09 18:38:08 +01:00
Marek Vasut
a4422a9183 ARM: dts: stm32: Increase CPU core voltage on STM32MP13xx DHCOR SoM
The STM32MP13xx DHCOR DHSBC is populated with STM32MP13xx part capable
of 1 GHz operation, increase the CPU core voltage to 1.35 V to make
sure the SoC is stable even if the blobs unconditionally force the CPU
to 1 GHz operation.

It is not possible to make use of CPUfreq on the STM32MP13xx because
the SCMI protocol 0x13 is not implemented by upstream OpTee-OS which
is the SCMI provider.

Fixes: 6331bddce6 ("ARM: dts: stm32: Add support for STM32MP13xx DHCOR SoM and DHSBC board")
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-12-09 18:38:08 +01:00
Marek Vasut
73317d3271 ARM: dts: stm32: Deduplicate serial aliases and chosen node for STM32MP15xx DHCOM SoM
Deduplicate /aliases { serialN = ... } and /chosen node into
stm32mp15xx-dhcom-som.dtsi , since the content is identical
on all carrier boards using the STM32MP15xx DHCOM SoM. No
functional change.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-12-09 18:37:41 +01:00
Mirsad Todorovac
cb57c75098
drm/xe: fix the ERR_PTR() returned on failure to allocate tiny pt
Running coccinelle spatch gave the following warning:

./drivers/gpu/drm/xe/tests/xe_migrate.c:226:5-11: inconsistent IS_ERR
and PTR_ERR on line 228.

The code reports PTR_ERR(pt) when IS_ERR(tiny) is checked:

→ 211  pt = xe_bo_create_pin_map(xe, tile, m->q->vm, XE_PAGE_SIZE,
  212                            ttm_bo_type_kernel,
  213                            XE_BO_FLAG_VRAM_IF_DGFX(tile) |
  214                            XE_BO_FLAG_PINNED);
  215  if (IS_ERR(pt)) {
  216          KUNIT_FAIL(test, "Failed to allocate fake pt: %li\n",
  217                     PTR_ERR(pt));
  218          goto free_big;
  219  }
  220
  221  tiny = xe_bo_create_pin_map(xe, tile, m->q->vm,
→ 222                              2 * SZ_4K,
  223                              ttm_bo_type_kernel,
  224                              XE_BO_FLAG_VRAM_IF_DGFX(tile) |
  225                              XE_BO_FLAG_PINNED);
→ 226  if (IS_ERR(tiny)) {
→ 227          KUNIT_FAIL(test, "Failed to allocate fake pt: %li\n",
→ 228                     PTR_ERR(pt));
  229          goto free_pt;
  230  }

Now, the IS_ERR(tiny) and the corresponding PTR_ERR(pt) do not match.

Returning PTR_ERR(tiny), as the last failed function call, seems logical.

Fixes: dd08ebf6c3 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Signed-off-by: Mirsad Todorovac <mtodorovac69@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241121212057.1526634-2-mtodorovac69@gmail.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-12-09 11:47:17 -05:00
Christian Bruel
0df076d35c arm64: dts: st: Enable COMBOPHY on the stm32mp257f-ev1 board
Enable the COMBOPHY with external pad clock on stm32mp257f-ev1
board, to be used for the PCIe clock provider.

Signed-off-by: Christian Bruel <christian.bruel@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-12-09 17:19:55 +01:00
Christian Bruel
486f87a868 arm64: dts: st: Add combophy node on stm32mp251
Add support for COMBOPHY which is used either by the USB3 and PCIe
controller.
USB3 or PCIe mode is done with phy_set_mode().
PCIe internal reference clock can be generated from the internal clock
source or optionnaly from an external 100Mhz pad.

Signed-off-by: Christian Bruel <christian.bruel@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-12-09 17:19:55 +01:00
Olivier Moysan
7c7abd1bf4 arm64: dts: st: add spdifrx support on stm32mp251
Add S/PDIFRX support to STM32MP25 SoC family.

Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-12-09 17:16:27 +01:00
Olivier Moysan
bf26d75a95 arm64: dts: st: add sai support on stm32mp251
Add SAI support to STM32MP25 SoC family.

Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-12-09 17:05:29 +01:00
Olivier Moysan
279f8c8d30 arm64: dts: st: add i2s support to stm32mp251
Add I2S support to STM32MP25 SoCs.

Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2024-12-09 17:05:29 +01:00
Pin-yen Lin
f143cece43 wifi: mwifiex: decrease timeout waiting for host sleep from 10s to 5s
In commit 52250cbee7 ("mwifiex: use timeout variant for
wait_event_interruptible") it was noted that sometimes we seemed
to miss the signal that our host sleep settings took effect. A
10 second timeout was added to the code to make sure we didn't
hang forever waiting. It appears that this problem still exists
and we hit the timeout sometimes for Chromebooks in the field.

Recently on ChromeOS we've started setting the DPM watchdog
to trip if full system suspend takes over 10 seconds. Given
the timeout in the original patch, obviously we're hitting
the DPM watchdog before mwifiex gets a chance to timeout.

While we could increase the DPM watchdog in ChromeOS to avoid
this problem, it's probably better to simply decrease the
timeout. Any time we're waiting several seconds for the
firmware to respond it's likely that the firmware won't ever
respond. With that in mind, decrease the timeout in mwifiex
from 10 seconds to 5 seconds.

Suggested-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Pin-yen Lin <treapking@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20241127105709.4014302-1-treapking@chromium.org
2024-12-09 17:59:45 +02:00
Renjaya Raga Zenta
aba23b0a6a wifi: brcmfmac: fix brcmf_vif_clear_mgmt_ies when stopping AP
This removes the following error log when stopping AP:

ieee80211 phy0: brcmf_vif_set_mgmt_ie: vndr ie set error : -52

It happened if:

1) previously wlan interface was in station mode (wpa_supplicant) and
   connected to a hotspot
2) then started AP mode (hostapd)
3) and then stopped AP mode.

The error happened when it tried to clear BRCMF_VNDR_IE_PRBREQ_FLAG.
This flag is not set in `brcmf_config_ap_mgmt_ie`, but
BRCMF_VNDR_IE_ASSOCRSP_FLAG is set instead.

Signed-off-by: Renjaya Raga Zenta <ragazenta@gmail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20241121-brcmfmac-v1-1-02fc3fb427c2@gmail.com
2024-12-09 17:59:13 +02:00
Christophe JAILLET
01e767d6f7 wifi: wlcore: testmode: Constify strutc nla_policy
'struct nla_policy' is not modified in this driver.

Constifying this structure moves some data to a read-only section, so
increase overall security, especially when the structure holds some
function pointers.

On a x86_64, with allmodconfig:
Before:
======
   text	   data	    bss	    dec	    hex	filename
   5062	    528	      0	   5590	   15d6	drivers/net/wireless/ti/wlcore/testmode.o

After:
=====
   text	   data	    bss	    dec	    hex	filename
   5178	    404	      0	   5582	   15ce	drivers/net/wireless/ti/wlcore/testmode.o

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/78810e3ebb74ddbd3a4538f182bf1143b89baba7.1731332414.git.christophe.jaillet@wanadoo.fr
2024-12-09 17:58:43 +02:00
Norbert van Bolhuis
52e8726d67 wifi: brcmfmac: fix scatter-gather handling by detecting end of sg list
The scatter-gather handling uses a pre-allocated list (with nents entries).
If the driver runs out of sg entries it will result in an oops. Let's detect
this instead and make the SDIO block transfer fail.

Signed-off-by: Norbert van Bolhuis <nvbolhuis@gmail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20241108125609.107016-1-nvbolhuis@gmail.com
2024-12-09 17:58:19 +02:00
Gowthami Thiagarajan
5fcccba118 perf/marvell: Odyssey LLC-TAD performance monitor support
Each TAD provides eight 64-bit counters for monitoring
cache behavior.The driver always configures the same counter for
all the TADs. The user would end up effectively reserving one of
eight counters in every TAD to look across all TADs.
The occurrences of events are aggregated and presented to the user
at the end of running the workload. The driver does not provide a
way for the user to partition TADs so that different TADs are used for
different applications.

The performance events reflect various internal or interface activities.
By combining the values from multiple performance counters, cache
performance can be measured in terms such as: cache miss rate, cache
allocations, interface retry rate, internal resource occupancy, etc.

Each supported counter's event and formatting information is exposed
to sysfs at /sys/devices/tad/. Use perf tool stat command to measure
the pmu events. For instance:

perf stat -e tad_hit_ltg,tad_hit_dtg <workload>

Signed-off-by: Gowthami Thiagarajan <gthiagarajan@marvell.com>
Link: https://lore.kernel.org/r/20241108040619.753343-6-gthiagarajan@marvell.com
Signed-off-by: Will Deacon <will@kernel.org>
2024-12-09 15:57:49 +00:00
Gowthami Thiagarajan
59731e231c perf/marvell: Refactor to extract platform data
Refactor the Marvell TAD PMU driver to add versioning to the
existing driver.

Make no functional changes, the behavior and performance
of the driver remain unchanged.

Signed-off-by: Gowthami Thiagarajan <gthiagarajan@marvell.com>
Link: https://lore.kernel.org/r/20241108040619.753343-5-gthiagarajan@marvell.com
Signed-off-by: Will Deacon <will@kernel.org>
2024-12-09 15:57:44 +00:00
Gowthami Thiagarajan
d950c381dc perf/marvell: Odyssey DDR Performance monitor support
Odyssey DRAM Subsystem supports eight counters for monitoring performance
and software can program those counters to monitor any of the defined
performance events. Supported performance events include those counted
at the interface between the DDR controller and the PHY, interface between
the DDR Controller and the CHI interconnect, or within the DDR Controller.

Additionally DSS also supports two fixed performance event counters, one
for ddr reads and the other for ddr writes.

Signed-off-by: Gowthami Thiagarajan <gthiagarajan@marvell.com>
Link: https://lore.kernel.org/r/20241108040619.753343-4-gthiagarajan@marvell.com
Signed-off-by: Will Deacon <will@kernel.org>
2024-12-09 15:57:39 +00:00
Gowthami Thiagarajan
0045de7e87 perf/marvell: Refactor to extract PMU operations
Introduce a refactor to the Marvell DDR PMU driver to extract
PMU operations ("pmu ops") from the existing driver.

Reviewed-by: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Signed-off-by: Gowthami Thiagarajan <gthiagarajan@marvell.com>
Link: https://lore.kernel.org/r/20241108040619.753343-3-gthiagarajan@marvell.com
Signed-off-by: Will Deacon <will@kernel.org>
2024-12-09 15:57:34 +00:00
Gowthami Thiagarajan
349f77e109 perf/marvell: Refactor to extract platform data
Introduce a refactor to the Marvell DDR pmu driver to extract platform
data ("pdata") from the existing driver. Prepare for the upcoming
support of the next version of the Performance Monitoring Unit (PMU) in
this driver.

Make no functional changes, this refactor solely improves code
organization and prepares for future enhancements.

While at it, fix a typo.

Signed-off-by: Gowthami Thiagarajan <gthiagarajan@marvell.com>
Link: https://lore.kernel.org/r/20241108040619.753343-2-gthiagarajan@marvell.com
Signed-off-by: Will Deacon <will@kernel.org>
2024-12-09 15:57:17 +00:00
Ilkka Koskinen
8632306e09 Documentation: dwc_pcie_pmu: Fix the mnemonics and eventid
Fix the event id and type in the example. In addition, the recent fix,
which addressed the mnemonics with mixed case, didn't fix the document.
Match the names with the driver.

Signed-off-by: Ilkka Koskinen <ilkka@os.amperecomputing.com>
Reviewed-by: Shuai Xue <xueshuai@linux.alibaba.com>
Link: https://lore.kernel.org/r/20241205061914.5568-3-ilkka@os.amperecomputing.com
Signed-off-by: Will Deacon <will@kernel.org>
2024-12-09 15:45:21 +00:00
Ilkka Koskinen
e64c22cc2e perf/dwc_pcie: Fix the event numbers
According to Databook, L1 aux is event number 0x08 and
TX L0s and RX L0S is 0x09. Fix the event numbers for the
two events.

Signed-off-by: Ilkka Koskinen <ilkka@os.amperecomputing.com>
Reviewed-by: Shuai Xue <xueshuai@linux.alibaba.com>
Link: https://lore.kernel.org/r/20241205061914.5568-2-ilkka@os.amperecomputing.com
Signed-off-by: Will Deacon <will@kernel.org>
2024-12-09 15:45:21 +00:00
Maarten Lankhorst
33f029af89 Merge remote-tracking branch 'drm/drm-next' into drm-misc-next
The v6.13-rc2 release included a bunch of breaking changes,
specifically the MODULE_IMPORT_NS commit.

Backmerge in order to fix them before the next pull-request.

Include the fix from Stephen Roswell.

Caused by commit

  25c3fd1183 ("drm/virtio: Add a helper to map and note the dma addrs and lengths")

Interacting with commit

  cdd30ebb1b ("module: Convert symbol namespace to string literal")

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Link: https://patchwork.freedesktop.org/patch/msgid/20241209121717.2abe8026@canb.auug.org.au
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2024-12-09 16:35:21 +01:00
Besar Wicaksono
bce61d5c57 perf: arm_cspmu: nvidia: monitor all ports by default
Some NVIDIA PMUs like the NVLINK-C2C, CNVLINK, and PCIE PMU provide
port filtering. If the port filter is set to zero, the counter of
these PMUs will not capture any event. To avoid meaningless
experiment, the driver sets the port filter value to a default
non-zero value.

Signed-off-by: Besar Wicaksono <bwicaksono@nvidia.com>
Link: https://lore.kernel.org/r/20241031142118.1865965-5-bwicaksono@nvidia.com
Signed-off-by: Will Deacon <will@kernel.org>
2024-12-09 15:07:49 +00:00
Besar Wicaksono
ca26df4b10 perf: arm_cspmu: nvidia: enable NVLINK-C2C port filtering
Enable NVLINK-C2C port filtering to distinguish traffic from
different GPUs connected to NVLINK-C2C.

Signed-off-by: Besar Wicaksono <bwicaksono@nvidia.com>
Link: https://lore.kernel.org/r/20241031142118.1865965-4-bwicaksono@nvidia.com
Signed-off-by: Will Deacon <will@kernel.org>
2024-12-09 15:07:49 +00:00
Besar Wicaksono
5f7cd0dc98 perf: arm_cspmu: nvidia: fix sysfs path in the kernel doc
Fix typos to the sysfs path referenced by NVIDIA
uncore pmu kernel doc.

Signed-off-by: Besar Wicaksono <bwicaksono@nvidia.com>
Link: https://lore.kernel.org/r/20241031142118.1865965-3-bwicaksono@nvidia.com
Signed-off-by: Will Deacon <will@kernel.org>
2024-12-09 15:07:49 +00:00
Besar Wicaksono
ac4c52956f perf: arm_cspmu: nvidia: remove unsupported SCF events
Remove unsupported events under SCF PMU.

Signed-off-by: Besar Wicaksono <bwicaksono@nvidia.com>
Link: https://lore.kernel.org/r/20241031142118.1865965-2-bwicaksono@nvidia.com
Signed-off-by: Will Deacon <will@kernel.org>
2024-12-09 15:07:49 +00:00
Arnd Bergmann
c9bc45b346 Arm SCMI fix for v6.13
Fix for the build issue in the ASoC driver with the SCMI support by
 enforcing the link-time dependency if IMX_SCMI_MISC_DRV is a loadable
 module but not if that is disabled.
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmdRitUACgkQAEG6vDF+
 4pgzfg/9FGA2lpOMFwon/aoZKggqiKYUnXdHi/iwW8razUopYe95l7EO7OWgVzk8
 aOA5TctGvCXvz6gyu8nmj+tHhzm0ds1mzoqj7s1D83AhIqbPpD6UHXlErhrt9613
 v8+od4IKSvd3zJS80swpj/pu9Cei4orNeLvLasAL3R4z0oN5kiV3W16AKpmVbNjO
 371XweVPaXaLTfj05Tm1PCOpsyC4N0gCE+U59QXoOltZOXNxQUjf7iM5W0wKSHNj
 1mZgNPjbQVKMUvi1VupOlAfwuYic6D2q+Nl0zq1sz8RVylRxFHF6qYtpAfn6K6NT
 KYQRAbU1QxaDC8LV4cVz+rTvA2TeV1qBMY8QlCqVdCJV6JLQmNQcZqPNaD1D9PZS
 L31fOSOloImg0khmm3GxRgGH4K7bcF/jcoVgLsgWQMGclPuQH+bC61V7UT905/DF
 xOyIcZEVILl8wHYn7uTKpzWEqlCIXffdvA7eo7S1a1U7LrjiZ3Lj4P+bD/M+fcQi
 Wjh6/SJ2ncexTH8huasmwM0J9L3p2bWhUGPwkxNeEvAO+CEdD+kMA2rAmm2xF+n8
 HqWF6TULBuTCD7SpLOwcXLLyp8N5IxgWwVQdWWgkHsWVTx49osCBbndj/T9frf7V
 MXnBI9e3OYrP5xcyR0M5XMGgB3rYKy0ApAly9uoOmE49iCjI0rc=
 =QBF6
 -----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmdXByQACgkQYKtH/8kJ
 UidBng/9G+4AG8z2ElPYNaz3oZmKCJ0usWsumwWdcwKfuezFW34T55F6nSkKjESv
 zNSv4gpvBwojVkZS05CF/Rds4chSwmG9dYs5Roz9lulUxpXuos8BrNSy1RWzET8Y
 fuDImYIsJhjQZEPk/4nEj1m5bYwiDoxRe0TFimcR3OX2+TjkKIoBEkD3uKbn4YSU
 UOGOvr6DCX0P0GKfjZTYqZsDvelxDn1+0f4WcWCv5sdZvgztUSj/lNRKH+kCyPQ4
 KidRJNjekhOGhDxy4qKrmSiry3FWtdhWiDaqSFQVFL4ftAEca7Sdk8xvylNjmj4K
 bWbx7/e6uwEGC+IKKKJbe4c3HiL5JW8HthvBZUsUcPQNK1pDWyHyH+y1oa0Ad9t6
 2t4PcRLvLImv5F6Dp3+6MBHGN3dleXg4ujHEOrlLK0jaFa+v0KoR9StJxx2QThcn
 EiqdhO+htLFNOzq9A0gY5oTH8h7nph4iY2tuQzaJoLmrXOz9yiI58wCaFoyU2/ba
 Vwdwx7XcKkYTlOyV/k1ev+w+J/aU2N2igghp8Qfgmhr3I25MVeZvEXiApFDHJvDM
 x7nprVFHlT+cBcCa/idLDmNQwynYrrtfxa992mjFzDZ8eEC04q4WKmPbZpC9R8rs
 GCoQ3awMb0/M0MiZf7sGqC0fe+C4fWTa2iTqPqpCFTag99a28Gk=
 =B7MA
 -----END PGP SIGNATURE-----

Merge tag 'scmi-fix-6.13' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes

Arm SCMI fix for v6.13

Fix for the build issue in the ASoC driver with the SCMI support by
enforcing the link-time dependency if IMX_SCMI_MISC_DRV is a loadable
module but not if that is disabled.

* tag 'scmi-fix-6.13' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
  firmware: arm_scmi: Fix i.MX build dependency

Link: https://lore.kernel.org/r/20241205114348.708618-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-12-09 16:05:07 +01:00
Arnd Bergmann
90386e1ba4 Armv8 Juno fix for v6.13
Just a single fix updating the PCIe bus address range to accommodate
 the full ECAM window of 256MB available on most of the recent versions
 of RevC FVP models.
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmdRh6oACgkQAEG6vDF+
 4piVWQ/6Akpv99sbqwa401L43kwdCnmubRXxO+IPFVPVAsVUPTO9OCPfohSixlAy
 JXgIW1lusN//J1y4UFIfMjcqCdUA0itFJHsWIYCLzwoaHo/B/IRZps0eTNiY1WF9
 XZMEgkb9/6ccd8TAa66L88AIjr/VZQpDSqoVJ2Pe8txckjJDlftwRro/KJmuU6go
 /2rqfeNIgN2rRiqlPpMcsz3BktCcQ2hYOu1tGpX6zPr4fBg1epX/Zi5WiUZjm0RR
 VWqP+R5anf9iXpC37Wek51/ixEXm2I9NFYSTg1LNU/tI1xqGwReE8dLxmHHOJoWW
 bcGApJhwV8CQEgm0JzeKz62Qi/l4LbDGfU2irajtuwG6F2rF/2LD6U+EMsHLrqDN
 SnNedBSE7bclTEZv02X5SZfKf20LQbaTtMo74Y/uEoERd9/nVKR4bj28ZPc4olm8
 klNQqpITlyJZ2xcLx1qs7kx9MK2ztYPmyzXHco7jByRDhfr0mWojXUfeEgWjnLQT
 0xpicb31f+ewhLeKE9zC0RT2z15Sz7z49aXsbU43LxkneLNLBbJbyi3fOlTiSVqd
 BzjoQOKwzrBg0dz4H3yqEV17/9kSrtFOWnEtf3eS7j/wFI/VbvgIgtKHHEbBLWhR
 w8QShUzOWReI78lazjYEV6ZXPD2q0PZWhgHDWyNjW6uvrLoM/9o=
 =j1a9
 -----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmdXBxEACgkQYKtH/8kJ
 Uicc7A/8C0ACMtnzT/bx28j5XHofkhoq8VaCmdbX3H04r/EMKXypChO2I3R56FPx
 ydX8HefAdkiQOgGVdcHrZ+x8/vyCCXxSRqyjgb+Yt+GGzse6TN952Oz8NptCkW74
 5v917V7Am9E0va1U9E1rpIhU+eCT6JzoD5xXK1d+0g52koZE4JtAv9DdS3Jjm/VV
 3GpcdLsSdG1csrkhKVnApSsY/Q6Tv3+G9olJ7qWY1NnWU916JZD/fJRL2wTL60id
 uHr6ja0dqAo6A0+ztbEkhnv3ccOaPwDG9a/gORhDQf/TvLE7Ef/qAzHmUF8cJCv5
 x2SHKL7lRyIb3Nn7RNq1PptPZw8FyCLprvuhrlDHa5LWO1Thj1iAlKrvJMTqYihy
 dzOKcRNZVmL9tX0xHW4RMDyl+P1rqsUhJOT5+/OWZRWPYV0AcwF0aquGqvrdaRR+
 30uX+KQ+otLzbKkyUtKOKGlhUWwg8zIXFCjO1TqhBUgxrzZLnY5aFmqNGB1IkA5A
 QmQH+oFWxktiEBjZ6KnCDUwEsDbfuT9l0+qhuVLXFDwBV2XShIZQYewrrymBYeA8
 I+I5hd4J+9zsVKLU3+Nj/+GavD0M4bGdF46NRWixheGga4La2MkCNNMC6dLqm8f1
 UQIlLu7LQ67xUDvqIdbyI8iUnyIsJhMpgTD/AglmUsRqBVIJKgY=
 =enl+
 -----END PGP SIGNATURE-----

Merge tag 'juno-fix-6.13' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes

Armv8 Juno fix for v6.13

Just a single fix updating the PCIe bus address range to accommodate
the full ECAM window of 256MB available on most of the recent versions
of RevC FVP models.

* tag 'juno-fix-6.13' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
  arm64: dts: fvp: Update PCIe bus-range property

Link: https://lore.kernel.org/r/20241205114302.708433-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-12-09 16:04:48 +01:00
Rodrigo Vivi
bc89328075
Merge drm/drm-next into drm-xe-next
Catch up with -rc2 and fixing namespace conflict issue caused by
commit cdd30ebb1b ("module: Convert symbol namespace to string literal")
and commit 0c45e76fcc ("drm/xe/vsec: Support BMG devices")

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-12-09 09:59:47 -05:00
Andrii Nakryiko
02c56362a7 uprobes: Guard against kmemdup() failing in dup_return_instance()
If kmemdup() failed to alloc memory, don't proceed with extra_consumers
copy.

Fixes: e62f2d492728 ("uprobes: Simplify session consumer tracking")
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20241206183436.968068-1-andrii@kernel.org
2024-12-09 15:50:32 +01:00
Namhyung Kim
d29e744c71 perf/x86: Relax privilege filter restriction on AMD IBS
While IBS is available for per-thread profiling, still regular users
cannot open an event due to the default paranoid setting (2) which
doesn't allow unprivileged users to get kernel samples.  That means
it needs to set exclude_kernel bit in the attribute but IBS driver
would reject it since it has PERF_PMU_CAP_NO_EXCLUDE.  This is not what
we want and I've been getting requests to fix this issue.

This should be done in the hardware, but until we get the HW fix we may
allow exclude_{kernel,user,hv} in the attribute and silently drop the
samples in the PMU IRQ handler.  It won't guarantee the sampling
frequency or even it'd miss some with fixed period too.  Not ideal,
but that'd still be helpful to regular users.

To minimize the confusion, let's add 'swfilt' bit to attr.config2 which
is exposed in the sysfs format directory so that users can figure out
if the kernel support the privilege filters by software.

  $ perf record -e ibs_op/swfilt=1/u true

This uses perf_exclude_event() which checks regs->cs.  But it should be
fine because set_linear_ip() also updates the CS according to the RIP
provided by IBS.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Tested-by: Ravi Bangoria <ravi.bangoria@amd.com>
Reviewed-by: Ravi Bangoria <ravi.bangoria@amd.com>
Link: https://lore.kernel.org/r/20241203180441.1634709-3-namhyung@kernel.org
2024-12-09 15:50:32 +01:00
Namhyung Kim
6057b90ecc perf/core: Export perf_exclude_event()
While at it, rename the same function in s390 cpum_sf PMU.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Tested-by: Ravi Bangoria <ravi.bangoria@amd.com>
Reviewed-by: Ravi Bangoria <ravi.bangoria@amd.com>
Acked-by: Thomas Richter <tmricht@linux.ibm.com>
Link: https://lore.kernel.org/r/20241203180441.1634709-2-namhyung@kernel.org
2024-12-09 15:50:31 +01:00
Andrii Nakryiko
8622e45b5d uprobes: Reuse return_instances between multiple uretprobes within task
Instead of constantly allocating and freeing very short-lived
struct return_instance, reuse it as much as possible within current
task. For that, store a linked list of reusable return_instances within
current->utask.

The only complication is that ri_timer() might be still processing such
return_instance. And so while the main uretprobe processing logic might
be already done with return_instance and would be OK to immediately
reuse it for the next uretprobe instance, it's not correct to
unconditionally reuse it just like that.

Instead we make sure that ri_timer() can't possibly be processing it by
using seqcount_t, with ri_timer() being "a writer", while
free_ret_instance() being "a reader". If, after we unlink return
instance from utask->return_instances list, we know that ri_timer()
hasn't gotten to processing utask->return_instances yet, then we can be
sure that immediate return_instance reuse is OK, and so we put it
onto utask->ri_pool for future (potentially, almost immediate) reuse.

This change shows improvements both in single CPU performance (by
avoiding relatively expensive kmalloc/free combon) and in terms of
multi-CPU scalability, where you can see that per-CPU throughput doesn't
decline as steeply with increased number of CPUs (which were previously
attributed to kmalloc()/free() through profiling):

	BASELINE (latest perf/core)
	===========================
	uretprobe-nop         ( 1 cpus):    1.898 ± 0.002M/s  (  1.898M/s/cpu)
	uretprobe-nop         ( 2 cpus):    3.574 ± 0.011M/s  (  1.787M/s/cpu)
	uretprobe-nop         ( 3 cpus):    5.279 ± 0.066M/s  (  1.760M/s/cpu)
	uretprobe-nop         ( 4 cpus):    6.824 ± 0.047M/s  (  1.706M/s/cpu)
	uretprobe-nop         ( 5 cpus):    8.339 ± 0.060M/s  (  1.668M/s/cpu)
	uretprobe-nop         ( 6 cpus):    9.812 ± 0.047M/s  (  1.635M/s/cpu)
	uretprobe-nop         ( 7 cpus):   11.030 ± 0.048M/s  (  1.576M/s/cpu)
	uretprobe-nop         ( 8 cpus):   12.453 ± 0.126M/s  (  1.557M/s/cpu)
	uretprobe-nop         (10 cpus):   14.838 ± 0.044M/s  (  1.484M/s/cpu)
	uretprobe-nop         (12 cpus):   17.092 ± 0.115M/s  (  1.424M/s/cpu)
	uretprobe-nop         (14 cpus):   19.576 ± 0.022M/s  (  1.398M/s/cpu)
	uretprobe-nop         (16 cpus):   22.264 ± 0.015M/s  (  1.391M/s/cpu)
	uretprobe-nop         (24 cpus):   33.534 ± 0.078M/s  (  1.397M/s/cpu)
	uretprobe-nop         (32 cpus):   43.262 ± 0.127M/s  (  1.352M/s/cpu)
	uretprobe-nop         (40 cpus):   53.252 ± 0.080M/s  (  1.331M/s/cpu)
	uretprobe-nop         (48 cpus):   55.778 ± 0.045M/s  (  1.162M/s/cpu)
	uretprobe-nop         (56 cpus):   56.850 ± 0.227M/s  (  1.015M/s/cpu)
	uretprobe-nop         (64 cpus):   62.005 ± 0.077M/s  (  0.969M/s/cpu)
	uretprobe-nop         (72 cpus):   66.445 ± 0.236M/s  (  0.923M/s/cpu)
	uretprobe-nop         (80 cpus):   68.353 ± 0.180M/s  (  0.854M/s/cpu)

	THIS PATCHSET (on top of latest perf/core)
	==========================================
	uretprobe-nop         ( 1 cpus):    2.253 ± 0.004M/s  (  2.253M/s/cpu)
	uretprobe-nop         ( 2 cpus):    4.281 ± 0.003M/s  (  2.140M/s/cpu)
	uretprobe-nop         ( 3 cpus):    6.389 ± 0.027M/s  (  2.130M/s/cpu)
	uretprobe-nop         ( 4 cpus):    8.328 ± 0.005M/s  (  2.082M/s/cpu)
	uretprobe-nop         ( 5 cpus):   10.353 ± 0.001M/s  (  2.071M/s/cpu)
	uretprobe-nop         ( 6 cpus):   12.513 ± 0.010M/s  (  2.086M/s/cpu)
	uretprobe-nop         ( 7 cpus):   14.525 ± 0.017M/s  (  2.075M/s/cpu)
	uretprobe-nop         ( 8 cpus):   15.633 ± 0.013M/s  (  1.954M/s/cpu)
	uretprobe-nop         (10 cpus):   19.532 ± 0.011M/s  (  1.953M/s/cpu)
	uretprobe-nop         (12 cpus):   21.405 ± 0.009M/s  (  1.784M/s/cpu)
	uretprobe-nop         (14 cpus):   24.857 ± 0.020M/s  (  1.776M/s/cpu)
	uretprobe-nop         (16 cpus):   26.466 ± 0.018M/s  (  1.654M/s/cpu)
	uretprobe-nop         (24 cpus):   40.513 ± 0.222M/s  (  1.688M/s/cpu)
	uretprobe-nop         (32 cpus):   54.180 ± 0.074M/s  (  1.693M/s/cpu)
	uretprobe-nop         (40 cpus):   66.100 ± 0.082M/s  (  1.652M/s/cpu)
	uretprobe-nop         (48 cpus):   70.544 ± 0.068M/s  (  1.470M/s/cpu)
	uretprobe-nop         (56 cpus):   74.494 ± 0.055M/s  (  1.330M/s/cpu)
	uretprobe-nop         (64 cpus):   79.317 ± 0.029M/s  (  1.239M/s/cpu)
	uretprobe-nop         (72 cpus):   84.875 ± 0.020M/s  (  1.179M/s/cpu)
	uretprobe-nop         (80 cpus):   92.318 ± 0.224M/s  (  1.154M/s/cpu)

For reference, with uprobe-nop we hit the following throughput:

	uprobe-nop            (80 cpus):  143.485 ± 0.035M/s  (  1.794M/s/cpu)

So now uretprobe stays a bit closer to that performance.

Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Link: https://lore.kernel.org/r/20241206002417.3295533-5-andrii@kernel.org
2024-12-09 15:50:30 +01:00
Andrii Nakryiko
0cf981de76 uprobes: Ensure return_instance is detached from the list before freeing
Ensure that by the time we call free_ret_instance() to clean up an
instance of struct return_instance it isn't reachable from
utask->return_instances anymore.

free_ret_instance() is called in a few different situations, all but one
of which already are fine w.r.t. return_instance visibility:

  - uprobe_free_utask() guarantees that ri_timer() won't be called
    (through timer_delete_sync() call), and so there is no need to
    unlink anything, because entire utask is being freed;
  - uprobe_handle_trampoline() is already unlinking to-be-freed
    return_instance with rcu_assign_pointer() before calling
    free_ret_instance().

Only cleanup_return_instances() violates this property, which so far is
not causing problems due to RCU-delayed freeing of return_instance,
which we'll change in the next patch. So make sure we unlink
return_instance before passing it into free_ret_instance(), as otherwise
reuse will be unsafe.

Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Link: https://lore.kernel.org/r/20241206002417.3295533-4-andrii@kernel.org
2024-12-09 15:50:29 +01:00
Andrii Nakryiko
636666a1c7 uprobes: Decouple return_instance list traversal and freeing
free_ret_instance() has two unrelated responsibilities: actually
cleaning up return_instance's resources and freeing memory, and also
helping with utask->return_instances list traversal by returning the
next alive pointer.

There is no reason why these two aspects have to be mixed together, so
turn free_ret_instance() into void-returning function and make callers
do list traversal on their own.

We'll use this simplification in the next patch that will guarantee that
to-be-freed return_instance isn't reachable from utask->return_instances
list.

Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Link: https://lore.kernel.org/r/20241206002417.3295533-3-andrii@kernel.org
2024-12-09 15:50:26 +01:00
Andrii Nakryiko
2ff913ab3f uprobes: Simplify session consumer tracking
In practice, each return_instance will typically contain either zero or
one return_consumer, depending on whether it has any uprobe session
consumer attached or not. It's highly unlikely that more than one uprobe
session consumers will be attached to any given uprobe, so there is no
need to optimize for that case. But the way we currently do memory
allocation and accounting is by pre-allocating the space for 4 session
consumers in contiguous block of memory next to struct return_instance
fixed part. This is unnecessarily wasteful.

This patch changes this to keep struct return_instance fixed-sized with one
pre-allocated return_consumer, while (in a highly unlikely scenario)
allowing for more session consumers in a separate dynamically
allocated and reallocated array.

We also simplify accounting a bit by not maintaining a separate
temporary capacity for consumers array, and, instead, relying on
krealloc() to be a no-op if underlying memory can accommodate a slightly
bigger allocation (but again, it's very uncommon scenario to even have
to do this reallocation).

All this gets rid of ri_size(), simplifies push_consumer() and removes
confusing ri->consumers_cnt re-assignment, while containing this
singular preallocated consumer logic contained within a few simple
preexisting helpers.

Having fixed-sized struct return_instance simplifies and speeds up
return_instance reuse that we ultimately add later in this patch set,
see follow up patches.

Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Link: https://lore.kernel.org/r/20241206002417.3295533-2-andrii@kernel.org
2024-12-09 15:50:23 +01:00
Jani Nikula
82c54741fc drm/i915/pps: include panel power cycle delay in debugfs
The debugfs contains all the other timings except panel power cycle
delay. Add it for completeness.

Tested-by: Paul Menzel <pmenzel@molgen.mpg.de> # Dell XPS 13 9360
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241205123720.3278727-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-12-09 16:28:08 +02:00
Jani Nikula
34e025972c drm/i915/pps: debug log the remaining power cycle delay to wait
While pps_init_delays() debug logs the power cycle delay, also debug log
the actual remaining time to wait in wait_panel_power_cycle().

Note that this still isn't the full picture; the power sequencer may
still wait after this one.

Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13007
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Tested-by: Paul Menzel <pmenzel@molgen.mpg.de> # Dell XPS 13
Link: https://patchwork.freedesktop.org/patch/msgid/20241204160048.2774419-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-12-09 16:27:09 +02:00
Marcus Cooper
6e750d3ec7
ASoC: sun4i-spdif: Add working 24bit audio support
24 bit audio file can be detected by the alsa driver as S32_LE.
Add this format to what is supported and change the DMA address
width.

Signed-off-by: Marcus Cooper <codekipper@gmail.com>
Link: https://patch.msgid.link/20241111165600.57219-4-codekipper@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2024-12-09 14:07:58 +00:00
Marcus Cooper
80ac12ffb3
ASoC: sun4i-spdif: Always set the valid data to be the MSB
This doesn't affect 16bit formats and allows us to properly run
24bit formats.

Signed-off-by: Marcus Cooper <codekipper@gmail.com>
Link: https://patch.msgid.link/20241111165600.57219-3-codekipper@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2024-12-09 14:07:57 +00:00
George Lander
0a2319308d
ASoC: sun4i-spdif: Add clock multiplier settings
There have been intermittent issues with the SPDIF output on H3
and H2+ devices which has been fixed by setting the s_clk to 4
times the audio pll.
Add a quirk for the clock multiplier as not every supported SoC
requires it. Without the multiplier, the audio at normal sampling
rates was distorted and did not play at higher sampling rates.

Fixes: 1bd92af877 ("ASoC: sun4i-spdif: Add support for the H3 SoC")
Signed-off-by: George Lander <lander@jagmn.com>
Signed-off-by: Marcus Cooper <codekipper@gmail.com>
Link: https://patch.msgid.link/20241111165600.57219-2-codekipper@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2024-12-09 14:07:56 +00:00
David S. Miller
b4906787d4 Merge branch 'net-sparx5-lan969x-fixes'
Daniel Machon says:

====================
net: sparx5: misc fixes for sparx5 and lan969x

This series fixes various issues in the Sparx5 and lan969x drivers. Most
of the fixes are for new issues introduced by the recent series adding
lan969x switch support in the Sparx5 driver.

Most notable is patch 1/5 that moves the lan969x dir into the sparx5
dir, in order to address a cyclic dependency issue reported by depmod,
when installing modules. Details are in the commit descriptions.

To: Andrew Lunn <andrew+netdev@lunn.ch>
To: David S. Miller <davem@davemloft.net>
To: Eric Dumazet <edumazet@google.com>
To: Jakub Kicinski <kuba@kernel.org>
To: Paolo Abeni <pabeni@redhat.com>
To: Lars Povlsen <lars.povlsen@microchip.com>
To: Steen Hegelund <Steen.Hegelund@microchip.com>
To: UNGLinuxDriver@microchip.com
To: Richard Cochran <richardcochran@gmail.com>
To: Bjarni Jonasson <bjarni.jonasson@microchip.com>
To: jensemil.schulzostergaard@microchip.com
To: horatiu.vultur@microchip.com
To: arnd@arndb.de
To: jacob.e.keller@intel.com
To: Parthiban.Veerasooran@microchip.com
Cc: Calvin Owens <calvin@wbinvd.org>
Cc: Muhammad Usama Anjum <Usama.Anjum@collabora.com>
Cc: linux-kernel@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
====================

Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2024-12-09 13:30:17 +00:00
Daniel Machon
ddd7ba0060 net: sparx5: fix the maximum frame length register
On port initialization, we configure the maximum frame length accepted
by the receive module associated with the port. This value is currently
written to the MAX_LEN field of the DEV10G_MAC_ENA_CFG register, when in
fact, it should be written to the DEV10G_MAC_MAXLEN_CFG register. Fix
this.

Fixes: 946e7fd505 ("net: sparx5: add port module support")
Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2024-12-09 13:30:17 +00:00
Daniel Machon
e4d505fda6 net: sparx5: fix default value of monitor ports
When doing port mirroring, the physical port to send the frame to, is
written to the FRMC_PORT_VAL field of the QFWD_FRAME_COPY_CFG register.
This field is 7 bits wide on sparx5 and 6 bits wide on lan969x, and has
a default value of 65 and 30, respectively (the number of front ports).

On mirror deletion, we set the default value of the monitor port to
65 for this field, in case no more ports exists for the mirror. Needless
to say, this will not fit the 6 bits on lan969x.

Fix this by correctly using the n_ports constant instead.

Fixes: 3f9e46347a ("net: sparx5: use SPX5_CONST for constants which already have a symbol")
Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2024-12-09 13:30:16 +00:00
Daniel Machon
f004f2e535 net: sparx5: fix FDMA performance issue
The FDMA handler is responsible for scheduling a NAPI poll, which will
eventually fetch RX packets from the FDMA queue. Currently, the FDMA
handler is run in a threaded context. For some reason, this kills
performance.  Admittedly, I did not do a thorough investigation to see
exactly what causes the issue, however, I noticed that in the other
driver utilizing the same FDMA engine, we run the FDMA handler in hard
IRQ context.

Fix this performance issue, by  running the FDMA handler in hard IRQ
context, not deferring any work to a thread.

Prior to this change, the RX UDP performance was:

Interval           Transfer     Bitrate         Jitter
0.00-10.20  sec    44.6 MBytes  36.7 Mbits/sec  0.027 ms

After this change, the rx UDP performance is:

Interval           Transfer     Bitrate         Jitter
0.00-9.12   sec    1.01 GBytes  953 Mbits/sec   0.020 ms

Fixes: 10615907e9 ("net: sparx5: switchdev: adding frame DMA functionality")
Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2024-12-09 13:30:16 +00:00
Daniel Machon
aa5fc88984 net: lan969x: fix the use of spin_lock in PTP handler
We are mixing the use of spin_lock() and spin_lock_irqsave() functions
in the PTP handler of lan969x. Fix this by correctly using the _irqsave
variants.

Fixes: 24fe835417 ("net: lan969x: add PTP handler function")
Signed-off-by: Daniel Machon <daniel.machon@microchip.com>

[1]: https://lore.kernel.org/netdev/20241024-sparx5-lan969x-switch-driver-2-v2-10-a0b5fae88a0f@microchip.com/

Signed-off-by: David S. Miller <davem@davemloft.net>
2024-12-09 13:30:16 +00:00