summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-08-14ASoC: fsl: merge DAI call back functions into opsKuninori Morimoto
ALSA SoC merges DAI call backs into .ops. This patch merge these into one. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87jzu5b0ue.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-08-14ASoC: bcm: merge DAI call back functions into opsKuninori Morimoto
ALSA SoC merges DAI call backs into .ops. This patch merge these into one. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87leelb0uk.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-08-14ASoC: pxa: merge DAI call back functions into opsKuninori Morimoto
ALSA SoC merges DAI call backs into .ops. This patch merge these into one. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87msz1b0uq.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-08-14ASoC: dwc: merge DAI call back functions into opsKuninori Morimoto
ALSA SoC merges DAI call backs into .ops. This patch merge these into one. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Maxim Kochetkov <fido_max@inbox.ru> Link: https://lore.kernel.org/r/87o7jhb0v4.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-08-14ASoC: amd: merge DAI call back functions into opsKuninori Morimoto
ALSA SoC merges DAI call backs into .ops. This patch merge these into one. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87pm3xb0va.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-08-14ASoC: adi: merge DAI call back functions into opsKuninori Morimoto
ALSA SoC merges DAI call backs into .ops. This patch merge these into one. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87r0odb0vg.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-08-14ASoC: adi: merge DAI call back functions into opsKuninori Morimoto
ALSA SoC merges DAI call backs into .ops. This patch merge these into one. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87sf8tb0vp.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-08-14ASoC: ti: merge DAI call back functions into opsKuninori Morimoto
ALSA SoC merges DAI call backs into .ops. This patch merge these into one. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87ttt9b0vw.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-08-14ASoC: soc-dai.h: merge DAI call back functions into opsKuninori Morimoto
snd_soc_dai_driver has .ops for call back functions (A), but it also has other call back functions (B). It is duplicated and confusable. struct snd_soc_dai_driver { ... ^ int (*probe)(...); | int (*remove)(...); (B) int (*compress_new)(...); | int (*pcm_new)(...); v ... (A) const struct snd_soc_dai_ops *ops; ... } This patch merges (B) into (A). Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87v8dpb0w6.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-08-14macintosh/ams: mark ams_init() staticArnd Bergmann
This is the module init function, which by definition is used only locally, so mark it static to avoid a warning: drivers/macintosh/ams/ams-core.c:179:12: error: no previous prototype for 'ams_init' [-Werror=missing-prototypes] Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230810141947.1236730-7-arnd@kernel.org
2023-08-14powerpc/pseries: PLPKS: undo kernel-doc comment notationRandy Dunlap
Don't use kernel-doc "/**" comment format for non-kernel-doc comments. This prevents a kernel-doc warning: arch/powerpc/platforms/pseries/plpks.c:186: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Label is combination of label attributes + name. Fixes: 2454a7af0f2a ("powerpc/pseries: define driver for Platform KeyStore") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> Link: lore.kernel.org/r/202308040430.GxmPAnwZ-lkp@intel.com Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230810000740.23756-1-rdunlap@infradead.org
2023-08-14powerpc/radix: Move some functions into #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLEChristophe Leroy
With skiboot_defconfig, Clang reports: CC arch/powerpc/mm/book3s64/radix_tlb.o arch/powerpc/mm/book3s64/radix_tlb.c:419:20: error: unused function '_tlbie_pid_lpid' [-Werror,-Wunused-function] static inline void _tlbie_pid_lpid(unsigned long pid, unsigned long lpid, ^ arch/powerpc/mm/book3s64/radix_tlb.c:663:20: error: unused function '_tlbie_va_range_lpid' [-Werror,-Wunused-function] static inline void _tlbie_va_range_lpid(unsigned long start, unsigned long end, ^ This is because those functions are only called from functions enclosed in a #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE Move below functions inside that #ifdef * __tlbie_pid_lpid(unsigned long pid, * __tlbie_va_lpid(unsigned long va, unsigned long pid, * fixup_tlbie_pid_lpid(unsigned long pid, unsigned long lpid) * _tlbie_pid_lpid(unsigned long pid, unsigned long lpid, * fixup_tlbie_va_range_lpid(unsigned long va, * __tlbie_va_range_lpid(unsigned long start, unsigned long end, * _tlbie_va_range_lpid(unsigned long start, unsigned long end, Fixes: f0c6fbbb9050 ("KVM: PPC: Book3S HV: Add support for H_RPT_INVALIDATE") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202307260802.Mjr99P5O-lkp@intel.com/ Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/3d72efd39f986ee939d068af69fdce28bd600766.1691568093.git.christophe.leroy@csgroup.eu
2023-08-14powerpc: xmon: remove unused variablesArnd Bergmann
Randconfig testing with W=1 showed up these warnings that I'd like to enable by default: arch/powerpc/xmon/xmon.c: In function 'dump_tlb_book3e': arch/powerpc/xmon/xmon.c:3833:42: error: variable 'lrat' set but not used [-Werror=unused-but-set-variable] 3833 | int i, tlb, ntlbs, pidsz, lpidsz, rasz, lrat = 0; | ^~~~ arch/powerpc/xmon/xmon.c:3831:23: error: variable 'lpidmask' set but not used [-Werror=unused-but-set-variable] 3831 | u32 mmucfg, pidmask, lpidmask; | ^~~~~~~~ arch/powerpc/xmon/xmon.c:3831:14: error: variable 'pidmask' set but not used [-Werror=unused-but-set-variable] 3831 | u32 mmucfg, pidmask, lpidmask; | ^~~~~~~ Just remove these as they have been unused since the code was added in 2010. Fixes: 03247157f7391 ("powerpc/book3e: Add TLB dump in xmon for Book3E") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230809131024.2039647-2-arnd@kernel.org
2023-08-14powerpc: mark more local variables as volatileArnd Bergmann
A while ago I created a2305e3de8193 ("powerpc: mark local variables around longjmp as volatile") in order to allow building powerpc with -Wextra enabled on gcc-11. I tried this again with gcc-13 and found two more of the same issues, presumably based on slightly different optimization paths being taken here: arch/powerpc/xmon/xmon.c:3306:27: error: variable 'mm' might be clobbered by 'longjmp' or 'vfork' [-Werror=clobbered] arch/powerpc/kexec/crash.c:353:22: error: variable 'i' might be clobbered by 'longjmp' or 'vfork' [-Werror=clobbered] I checked a bunch of randconfigs and found only these two, so just address them the same way as the others. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230809131024.2039647-1-arnd@kernel.org
2023-08-14powerpc/pmac32: enable serial options by default in defconfigYuan Tan
Serial is a critical feature for logging and debuging, and the other architectures enable serial by default. Let's enable CONFIG_SERIAL_PMACZILOG and CONFIG_SERIAL_PMACZILOG_CONSOLE by default. Signed-off-by: Yuan Tan <tanyuan@tinylab.org> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/bb7b5f9958b3e3a20f6573ff7ce7c5dc566e7e32.1690982937.git.tanyuan@tinylab.org
2023-08-14Merge branch 'topic/cpu-smt' into nextMichael Ellerman
Merge SMT changes we are sharing with the tip tree.
2023-08-14Merge branch 'devel-stable' into for-nextRussell King (Oracle)
2023-08-14ARM: 9318/1: locomo: move kernel-doc to prevent warningsRandy Dunlap
Move the kernel-doc comments for locomo_probe() to immediately before that function instead of before __locomo_probe() to prevent kernel-doc warnings. Adjust the documented function parameters and make the return values compatible with ReST by adding bullets to them. Add more possible return values to the list. Prevents these warnings: arch/arm/common/locomo.c:368: warning: Function parameter or member 'me' not described in '__locomo_probe' arch/arm/common/locomo.c:368: warning: Function parameter or member 'mem' not described in '__locomo_probe' arch/arm/common/locomo.c:368: warning: Function parameter or member 'irq' not described in '__locomo_probe' arch/arm/common/locomo.c:368: warning: expecting prototype for locomo_probe(). Prototype was for __locomo_probe() instead Link: lore.kernel.org/r/202308050851.zAvHe6y7-lkp@intel.com Fixes: 5eb6e280432d ("ARM: 9289/1: Allow pre-ARMv5 builds with ld.lld 16.0.0 and newer") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Nathan Chancellor <nathan@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Cc: patches@armlinux.org.uk Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2023-08-14ARM: 9317/1: kexec: Make smp stop calls asynchronousMårten Lindahl
If a panic is triggered by a hrtimer interrupt all online cpus will be notified and set offline. But as highlighted by commit 19dbdcb8039c ("smp: Warn on function calls from softirq context") this call should not be made synchronous with disabled interrupts: softdog: Initiating panic Kernel panic - not syncing: Software Watchdog Timer expired WARNING: CPU: 1 PID: 0 at kernel/smp.c:753 smp_call_function_many_cond unwind_backtrace: show_stack dump_stack_lvl __warn warn_slowpath_fmt smp_call_function_many_cond smp_call_function crash_smp_send_stop.part.0 machine_crash_shutdown __crash_kexec panic softdog_fire __hrtimer_run_queues hrtimer_interrupt Make the smp call for machine_crash_nonpanic_core() asynchronous. Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2023-08-14ARM: 9316/1: hw_breakpoint: fix single-stepping when using bpf_overflow_handlerTomislav Novak
Arm platforms use is_default_overflow_handler() to determine if the hw_breakpoint code should single-step over the breakpoint trigger or let the custom handler deal with it. Since bpf_overflow_handler() currently isn't recognized as a default handler, attaching a BPF program to a PERF_TYPE_BREAKPOINT event causes it to keep firing (the instruction triggering the data abort exception is never skipped). For example: # bpftrace -e 'watchpoint:0x10000:4:w { print("hit") }' -c ./test Attaching 1 probe... hit hit [...] ^C (./test performs a single 4-byte store to 0x10000) This patch replaces the check with uses_default_overflow_handler(), which accounts for the bpf_overflow_handler() case by also testing if one of the perf_event_output functions gets invoked indirectly, via orig_default_handler. Link: https://lore.kernel.org/linux-arm-kernel/20220923203644.2731604-1-tnovak@fb.com/ Signed-off-by: Tomislav Novak <tnovak@fb.com> Tested-by: Samuel Gosselin <sgosselin@google.com> # arm64 Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2023-08-14drm:rcar-du: Enable ABGR and XBGR formatsDamian Hobson-Garcia
These formats are used by Android so having them available allows the DU to be used for composition operations. Signed-off-by: Damian Hobson-Garcia <dhobsong@igel.co.jp> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2023-08-14drm: rcar-du: Add more formats to DRM_MODE_BLEND_PIXEL_NONE supportDamian Hobson-Garcia
Add additional pixel formats for which blending is disabled when DRM_MODE_BLEND_PIXEL_NONE is set. Refactor the fourcc selection into a separate function to handle the increased number of formats. Signed-off-by: Damian Hobson-Garcia <dhobsong@igel.co.jp> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2023-08-14drm/renesas: Convert to devm_platform_ioremap_resource()Yangtao Li
Use devm_platform_ioremap_resource() to simplify code. Signed-off-by: Yangtao Li <frank.li@vivo.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2023-08-14drm: rcar-du: Use dev_err_probe() to record cause of KMS init errorsLaurent Pinchart
The (large) rcar_du_modeset_init() function can fail for many reasons, two of two involving probe deferral. Use dev_err_probe() in those code paths to record the cause of the probe deferral, in order to help debugging probe issues. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
2023-08-14drm: rcar-du: Replace DRM_INFO() with drm_info()Laurent Pinchart
drm_info() adds proper context to the kernel log message, as it receives the drm_device pointer. It is thus preferred over DRM_INFO(). Replace the latter with the former. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
2023-08-14arm64: dts: agilex5: add initial support for Intel Agilex5 SoCFPGANiravkumar L Rabara
Add the initial device tree files for Intel Agilex5 SoCFPGA platform. Reviewed-by: Dinh Nguyen <dinguyen@kernel.org> Signed-off-by: Niravkumar L Rabara <niravkumar.l.rabara@intel.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2023-08-14ARM: dts: am335x-bone-common: Add vcc-supply for on-board eepromShengyu Qu
The on-board eeprom on beaglebone series has a power supply from VDD_3V3A, add that to dts to reduce dummy regulator warning. Signed-off-by: Shengyu Qu <wiagn233@outlook.com> Message-ID: <TY3P286MB2611CDC84604B11570B4A8D2980FA@TY3P286MB2611.JPNP286.PROD.OUTLOOK.COM> Signed-off-by: Tony Lindgren <tony@atomide.com>
2023-08-14ARM: dts: am335x-bone-common: Add GPIO PHY reset on revision C3 boardShengyu Qu
This patch adds ethernet PHY reset GPIO config for Beaglebone Black series boards with revision C3. This fixes a random phy startup failure bug discussed at [1]. The GPIO pin used for reset is not used on older revisions, so it is ok to apply to all board revisions. The reset timing was discussed and tested at [2]. [1] https://forum.digikey.com/t/ethernet-device-is-not-detecting-on-ubuntu-20-04-lts-on-bbg/19948 [2] https://forum.beagleboard.org/t/recognizing-a-beaglebone-black-rev-c3-board/31249/ Signed-off-by: Robert Nelson <robertcnelson@gmail.com> Signed-off-by: Shengyu Qu <wiagn233@outlook.com> Message-ID: <TY3P286MB26113797A3B2EC7E0348BBB2980FA@TY3P286MB2611.JPNP286.PROD.OUTLOOK.COM> Signed-off-by: Tony Lindgren <tony@atomide.com>
2023-08-14selftests: mirror_gre_changes: Tighten up the TTL test matchPetr Machata
This test verifies whether the encapsulated packets have the correct configured TTL. It does so by sending ICMP packets through the test topology and mirroring them to a gretap netdevice. On a busy host however, more than just the test ICMP packets may end up flowing through the topology, get mirrored, and counted. This leads to potential spurious failures as the test observes much more mirrored packets than the sent test packets, and assumes a bug. Fix this by tightening up the mirror action match. Change it from matchall to a flower classifier matching on ICMP packets specifically. Fixes: 45315673e0c5 ("selftests: forwarding: Test changes in mirror-to-gretap") Signed-off-by: Petr Machata <petrm@nvidia.com> Tested-by: Mirsad Todorovac <mirsad.todorovac@alu.unizg.hr> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-08-14clk: imx: pll14xx: dynamically configure PLL for 393216000/361267200HzAhmad Fatoum
Since commit b09c68dc57c9 ("clk: imx: pll14xx: Support dynamic rates"), the driver has the ability to dynamically compute PLL parameters to approximate the requested rates. This is not always used, because the logic is as follows: - Check if the target rate is hardcoded in the frequency table - Check if varying only kdiv is possible, so switch over is glitch free - Compute rate dynamically by iterating over pdiv range If we skip the frequency table for the 1443x PLL, we find that the computed values differ to the hardcoded ones. This can be valid if the hardcoded values guarantee for example an earlier lock-in or if the divisors are chosen, so that other important rates are more likely to be reached glitch-free. For rates (393216000 and 361267200, this doesn't seem to be the case: They are only approximated by existing parameters (393215995 and 361267196 Hz, respectively) and they aren't reachable glitch-free from other hardcoded frequencies. Dropping them from the table allows us to lock-in to these frequencies exactly. This is immediately noticeable because they are the assigned-clock-rates for IMX8MN_AUDIO_PLL1 and IMX8MN_AUDIO_PLL2, respectively and a look into clk_summary so far showed that they were a few Hz short of the target: imx8mn-board:~# grep audio_pll[12]_out /sys/kernel/debug/clk/clk_summary audio_pll2_out 0 0 0 361267196 0 0 50000 N audio_pll1_out 1 1 0 393215995 0 0 50000 Y and afterwards: imx8mn-board:~# grep audio_pll[12]_out /sys/kernel/debug/clk/clk_summary audio_pll2_out 0 0 0 361267200 0 0 50000 N audio_pll1_out 1 1 0 393216000 0 0 50000 Y This change is equivalent to adding following hardcoded values: /* rate mdiv pdiv sdiv kdiv */ PLL_1443X_RATE(393216000, 655, 5, 3, 23593), PLL_1443X_RATE(361267200, 497, 33, 0, -16882), Fixes: 053a4ffe2988 ("clk: imx: imx8mm: fix audio pll setting") Cc: stable@vger.kernel.org # v5.18+ Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Link: https://lore.kernel.org/r/20230807084744.1184791-2-m.felsch@pengutronix.de Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
2023-08-14clk: imx: pll14xx: align pdiv with reference manualMarco Felsch
The PLL14xx hardware can be found on i.MX8M{M,N,P} SoCs and always come with a 6-bit pre-divider. Neither the reference manuals nor the datasheets of these SoCs do mention any restrictions. Furthermore the current code doesn't respect the restrictions from the comment too. Therefore drop the restriction and align the max pre-divider (pdiv) value to 63 to get more accurate frequencies. Fixes: b09c68dc57c9 ("clk: imx: pll14xx: Support dynamic rates") Cc: stable@vger.kernel.org Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Adam Ford <aford173@gmail.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Acked-by: Sascha Hauer <s.hauer@pengutronix.de> Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Link: https://lore.kernel.org/r/20230807084744.1184791-1-m.felsch@pengutronix.de Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
2023-08-14clk: imx: composite-8m: fix clock pauses when set_rate would be a no-opAhmad Fatoum
Reconfiguring the clock divider to the exact same value is observed on an i.MX8MN to often cause a longer than usual clock pause, probably because the divider restarts counting whenever the register is rewritten. This issue doesn't show up normally, because the clock framework will take care to not call set_rate when the clock rate is the same. However, when we reconfigure an upstream clock, the common code will call set_rate with the newly calculated rate on all children, e.g.: - sai5 is running normally and divides Audio PLL out by 16. - Audio PLL rate is increased by 32Hz (glitch-free kdiv change) - rates for children are recalculated and rates are set recursively - imx8m_clk_composite_divider_set_rate(sai5) is called with 32/16 = 2Hz more - imx8m_clk_composite_divider_set_rate computes same divider as before - divider register is written, so it restarts counting from zero and MCLK is briefly paused, so instead of e.g. 40ns, MCLK is low for 120ns. Some external clock consumers can be upset by such unexpected clock pauses, so let's make sure we only rewrite the divider value when the value to be written is actually different. Fixes: d3ff9728134e ("clk: imx: Add imx composite clock") Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Reviewed-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20230807082201.2332746-1-a.fatoum@pengutronix.de Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
2023-08-14x86/retpoline,kprobes: Skip optprobe check for indirect jumps with ↵Petr Pavlu
retpolines and IBT The kprobes optimization check can_optimize() calls insn_is_indirect_jump() to detect indirect jump instructions in a target function. If any is found, creating an optprobe is disallowed in the function because the jump could be from a jump table and could potentially land in the middle of the target optprobe. With retpolines, insn_is_indirect_jump() additionally looks for calls to indirect thunks which the compiler potentially used to replace original jumps. This extra check is however unnecessary because jump tables are disabled when the kernel is built with retpolines. The same is currently the case with IBT. Based on this observation, remove the logic to look for calls to indirect thunks and skip the check for indirect jumps altogether if the kernel is built with retpolines or IBT. Remove subsequently the symbols __indirect_thunk_start and __indirect_thunk_end which are no longer needed. Dropping this logic indirectly fixes a problem where the range [__indirect_thunk_start, __indirect_thunk_end] wrongly included also the return thunk. It caused that machines which used the return thunk as a mitigation and didn't have it patched by any alternative ended up not being able to use optprobes in any regular function. Fixes: 0b53c374b9ef ("x86/retpoline: Use -mfunction-return") Suggested-by: Peter Zijlstra (Intel) <peterz@infradead.org> Suggested-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Petr Pavlu <petr.pavlu@suse.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Link: https://lore.kernel.org/r/20230711091952.27944-3-petr.pavlu@suse.com
2023-08-14x86/retpoline,kprobes: Fix position of thunk sections with CONFIG_LTO_CLANGPetr Pavlu
The linker script arch/x86/kernel/vmlinux.lds.S matches the thunk sections ".text.__x86.*" from arch/x86/lib/retpoline.S as follows: .text { [...] TEXT_TEXT [...] __indirect_thunk_start = .; *(.text.__x86.*) __indirect_thunk_end = .; [...] } Macro TEXT_TEXT references TEXT_MAIN which normally expands to only ".text". However, with CONFIG_LTO_CLANG, TEXT_MAIN becomes ".text .text.[0-9a-zA-Z_]*" which wrongly matches also the thunk sections. The output layout is then different than expected. For instance, the currently defined range [__indirect_thunk_start, __indirect_thunk_end] becomes empty. Prevent the problem by using ".." as the first separator, for example, ".text..__x86.indirect_thunk". This pattern is utilized by other explicit section names which start with one of the standard prefixes, such as ".text" or ".data", and that need to be individually selected in the linker script. [ nathan: Fix conflicts with SRSO and fold in fix issue brought up by Andrew Cooper in post-review: https://lore.kernel.org/20230803230323.1478869-1-andrew.cooper3@citrix.com ] Fixes: dc5723b02e52 ("kbuild: add support for Clang LTO") Signed-off-by: Petr Pavlu <petr.pavlu@suse.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230711091952.27944-2-petr.pavlu@suse.com
2023-08-14clk: imx25: make __mx25_clocks_init return voidMartin Kaiser
The __mx25_clocks_init function always returns 0 and its only caller does not check the return value. Let's remove it. Signed-off-by: Martin Kaiser <martin@kaiser.cx> Reviewed-by: Fabio Estevam <festevam@gmail.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20230802184046.153394-3-martin@kaiser.cx Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
2023-08-14clk: imx25: print silicon revision during initMartin Kaiser
Print the imx25 silicon revision when the clocks are initialised. Use the same mechanism as for imx27, i.e. call mx25_revision. This function is unused at the moment. Signed-off-by: Martin Kaiser <martin@kaiser.cx> Reviewed-by: Fabio Estevam <festevam@gmail.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20230802184046.153394-2-martin@kaiser.cx Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
2023-08-14dt-bindings: clocks: imx8mp: make sai4 a dummy clockMarco Felsch
The hardware don't have a SAI4 instance so remove the define. Use a comment to keep it as reference and to avoid confusion. Fixes: 108869144739 ("dt-bindings: imx: Add clock binding doc for i.MX8MP") Acked-by: Stephen Boyd <sboyd@kernel.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Link: https://lore.kernel.org/r/20230731142150.3186650-2-m.felsch@pengutronix.de Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
2023-08-14clk: imx8mp: fix sai4 clockMarco Felsch
The reference manual don't mention a SAI4 hardware block. This would be clock slice 78 which is skipped (TRM, page 237). Remove any reference to this clock to align the driver with the reality. Fixes: 9c140d992676 ("clk: imx: Add support for i.MX8MP clock driver") Acked-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Link: https://lore.kernel.org/r/20230731142150.3186650-1-m.felsch@pengutronix.de Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
2023-08-14clk: imx: imx8ulp: update SPLL2 typePeng Fan
The SPLL2 on iMX8ULP is different with other frac PLLs, it can support VCO from 650Mhz to 1Ghz. Following the changes to pllv4, use the new type IMX_PLLV4_IMX8ULP_1GHZ. Fixes: c43a801a5789 ("clk: imx: Add clock driver for imx8ulp") Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20230625123340.4067536-2-peng.fan@oss.nxp.com Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
2023-08-14clk: imx: pllv4: Fix SPLL2 MULT rangeYe Li
The SPLL2 on iMX8ULP is different with other frac PLLs, it can support VCO from 650Mhz to 1Ghz. According to RM, the MULT is using a range from 27 to 54, not some fixed values. If using current PLL implementation, some clock rate can't be supported. Fix the issue by adding new type for the SPLL2 and use MULT range to replace MULT table Fixes: 5f0601c47c33 ("clk: imx: Update the pllv4 to support imx8ulp") Reviewed-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Jacky Bai <ping.bai@nxp.com> Signed-off-by: Ye Li <ye.li@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20230625123340.4067536-1-peng.fan@oss.nxp.com Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
2023-08-14x86/srso: Disable the mitigation on unaffected configurationsBorislav Petkov (AMD)
Skip the srso cmd line parsing which is not needed on Zen1/2 with SMT disabled and with the proper microcode applied (latter should be the case anyway) as those are not affected. Fixes: 5a15d8348881 ("x86/srso: Tie SBPB bit setting to microcode patch detection") Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230813104517.3346-1-bp@alien8.de
2023-08-14clk: imx: imx8: add audio clock mux driverShengjiu Wang
The Audio Clock Mux (ACM) is a collection of control registers and multiplexers that are used to route the audio source clocks to the audio peripherals. Each audio peripheral has its dedicated audio clock mux (which differ based on usage) and control register. Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/1690260984-25744-3-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
2023-08-14dt-bindings: clock: fsl,imx8-acm: Add audio clock mux supportShengjiu Wang
Add the clock dt-binding file for Audio Clock Mux. which is the IP for i.MX8QM, i.MX8QXP, i.MX8DXL. Add the clockid for clocks in header file. The Audio Clock Mux is binded with all the audio IP and audio clocks in the subsystem, so need to list the power domain of related clocks and IPs. Each clock and IP has a power domain, so there are so many power domains. Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/1690260984-25744-2-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
2023-08-14clk: imx: clk-imx8qxp-lpcg: Convert to devm_platform_ioremap_resource()Yangtao Li
Use devm_platform_ioremap_resource() to simplify code. Signed-off-by: Yangtao Li <frank.li@vivo.com> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20230705065313.67043-8-frank.li@vivo.com Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
2023-08-14x86/CPU/AMD: Fix the DIV(0) initial fix attemptBorislav Petkov (AMD)
Initially, it was thought that doing an innocuous division in the #DE handler would take care to prevent any leaking of old data from the divider but by the time the fault is raised, the speculation has already advanced too far and such data could already have been used by younger operations. Therefore, do the innocuous division on every exit to userspace so that userspace doesn't see any potentially old data from integer divisions in kernel space. Do the same before VMRUN too, to protect host data from leaking into the guest too. Fixes: 77245f1c3c64 ("x86/CPU/AMD: Do not leak quotient data after a division by 0") Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: <stable@kernel.org> Link: https://lore.kernel.org/r/20230811213824.10025-1-bp@alien8.de
2023-08-14x86/retpoline: Don't clobber RFLAGS during srso_safe_ret()Sean Christopherson
Use LEA instead of ADD when adjusting %rsp in srso_safe_ret{,_alias}() so as to avoid clobbering flags. Drop one of the INT3 instructions to account for the LEA consuming one more byte than the ADD. KVM's emulator makes indirect calls into a jump table of sorts, where the destination of each call is a small blob of code that performs fast emulation by executing the target instruction with fixed operands. E.g. to emulate ADC, fastop() invokes adcb_al_dl(): adcb_al_dl: <+0>: adc %dl,%al <+2>: jmp <__x86_return_thunk> A major motivation for doing fast emulation is to leverage the CPU to handle consumption and manipulation of arithmetic flags, i.e. RFLAGS is both an input and output to the target of the call. fastop() collects the RFLAGS result by pushing RFLAGS onto the stack and popping them back into a variable (held in %rdi in this case): asm("push %[flags]; popf; " CALL_NOSPEC " ; pushf; pop %[flags]\n" <+71>: mov 0xc0(%r8),%rdx <+78>: mov 0x100(%r8),%rcx <+85>: push %rdi <+86>: popf <+87>: call *%rsi <+89>: nop <+90>: nop <+91>: nop <+92>: pushf <+93>: pop %rdi and then propagating the arithmetic flags into the vCPU's emulator state: ctxt->eflags = (ctxt->eflags & ~EFLAGS_MASK) | (flags & EFLAGS_MASK); <+64>: and $0xfffffffffffff72a,%r9 <+94>: and $0x8d5,%edi <+109>: or %rdi,%r9 <+122>: mov %r9,0x10(%r8) The failures can be most easily reproduced by running the "emulator" test in KVM-Unit-Tests. If you're feeling a bit of deja vu, see commit b63f20a778c8 ("x86/retpoline: Don't clobber RFLAGS during CALL_NOSPEC on i386"). In addition, this breaks booting of clang-compiled guest on a gcc-compiled host where the host contains the %rsp-modifying SRSO mitigations. [ bp: Massage commit message, extend, remove addresses. ] Fixes: fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation") Closes: https://lore.kernel.org/all/de474347-122d-54cd-eabf-9dcc95ab9eae@amd.com Reported-by: Srikanth Aithal <sraithal@amd.com> Reported-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Tested-by: Nathan Chancellor <nathan@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/20230810013334.GA5354@dev-arch.thelio-3990X/ Link: https://lore.kernel.org/r/20230811155255.250835-1-seanjc@google.com
2023-08-14MAINTAINERS: remove OXNAS entryNeil Armstrong
Due to lack of maintenance and stall of development for a few years now, and since no new features will ever be added upstream, remove MAINTAINERS entry for OXNAS files. Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Daniel Golle <daniel@makrotopia.org> Acked-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20230814-topic-oxnas-upstream-remove-v3-3-e2ba579a49d3@linaro.org Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2023-08-14dt-bindings: interrupt-controller: arm,versatile-fpga-irq: mark oxnas ↵Neil Armstrong
compatible as deprecated Due to lack of maintenance and stall of development for a few years now, and since no new features will ever be added upstream, mark the OX810 and OX820 IRQ compatible as deprecated. Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Daniel Golle <daniel@makrotopia.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230814-topic-oxnas-upstream-remove-v3-2-e2ba579a49d3@linaro.org Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2023-08-14irqchip: irq-versatile-fpga: remove obsolete oxnas compatibleNeil Armstrong
Due to lack of maintenance and stall of development for a few years now, and since no new features will ever be added upstream, remove support for OX810 and OX820 IRQ controller. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Daniel Golle <daniel@makrotopia.org> Acked-by: Marc Zyngier <maz@kernel.org> Acked-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20230814-topic-oxnas-upstream-remove-v3-1-e2ba579a49d3@linaro.org Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2023-08-14Merge back system-wide sleep material for v6.6.Rafael J. Wysocki