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>
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>
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>
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>
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>
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>
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
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
'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
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
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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
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
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
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
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
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>
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>
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>
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>
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>
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>
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>
Depmod reports a cyclic dependency between modules sparx5-switch.ko and
lan969x-switch.ko:
depmod: ERROR: Cycle detected: lan969x_switch -> sparx5_switch -> lan969x_switch
depmod: ERROR: Found 2 modules in dependency cycles!
make[2]: *** [scripts/Makefile.modinst:132: depmod] Error 1
make: *** [Makefile:224: __sub-make] Error 2
This makes sense, as they both require symbols from each other.
Fix this by compiling lan969x support into the sparx5-switch.ko module.
In order to do this, in a sensible way, we move the lan969x/ dir into
the sparx5/ dir and do some code cleanup of code that is no longer
required.
After this patch, depmod will no longer complain, as lan969x support is
compiled into the sparx5-swicth.ko module, and can no longer be compiled
as a standalone module.
Fixes: 98a0111960 ("net: sparx5: add compatible string for lan969x")
Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Setting spi_transfer->effective_speed_hz in transfer_one_message so that
SPI client driver can use it.
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Link: https://patch.msgid.link/20241209111316.4767-1-wahrenst@gmx.net
Signed-off-by: Mark Brown <broonie@kernel.org>
Add check for the return value of clk_enable() to catch the potential
error.
Fixes: c618a90dca ("spi: zynq-qspi: Drop GPIO header")
Signed-off-by: Mingwei Zheng <zmw12306@gmail.com>
Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
Link: https://patch.msgid.link/20241207015206.3689364-1-zmw12306@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The few functions are using different approaches on how to check for
the type of firmware node. Unify them to use a modern way of it.
With that in place it becomes obvious that no need to have independent
conditionals when they are dependent and hence the code generation can
be improved a little bit (clang-18, x86_64):
add/remove: 0/0 grow/shrink: 2/2 up/down: 16/-46 (-30)
Total: Before=49801, After=49771, chg -0.06%
Meanwhile no functional changes intended.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20241208195635.1271656-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
