summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-04-03dt-bindings: timer: narrow regex for unit address to hex numbersKrzysztof Kozlowski
Regular expression used to match the unit address part should not allow non-hex numbers. Expect at least one hex digit as well. Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240325104833.33372-2-krzysztof.kozlowski@linaro.org Signed-off-by: Rob Herring <robh@kernel.org>
2024-04-03dt-bindings: soc: fsl: narrow regex for unit address to hex numbersKrzysztof Kozlowski
Regular expression used to match the unit address part should not allow non-hex numbers. Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240325104833.33372-1-krzysztof.kozlowski@linaro.org Signed-off-by: Rob Herring <robh@kernel.org>
2024-04-03dt-bindings: remoteproc: ti,davinci: remove unstable remarkKrzysztof Kozlowski
TI Davinci remoteproc bindings were marked as work-in-progress / unstable in 2017 in commit ae67b8007816 ("dt-bindings: remoteproc: Add bindings for Davinci DSP processors"). Almost seven years is enough, so drop the "unstable" remark and expect usual ABI rules. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20240224091236.10146-3-krzysztof.kozlowski@linaro.org Signed-off-by: Rob Herring <robh@kernel.org>
2024-04-03dt-bindings: clock: ti: remove unstable remarkKrzysztof Kozlowski
Several TI SoC clock bindings were marked as work-in-progress / unstable between 2013-2016, for example in commit f60b1ea5ea7a ("CLK: TI: add support for gate clock"). It was enough of time to consider them stable and expect usual ABI rules. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Stephen Boyd <sboyd@kernel.org> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20240224091236.10146-2-krzysztof.kozlowski@linaro.org Signed-off-by: Rob Herring <robh@kernel.org>
2024-04-03dt-bindings: clock: keystone: remove unstable remarkKrzysztof Kozlowski
Keystone clock controller bindings were marked as work-in-progress / unstable in 2013 in commit b9e0d40c0d83 ("clk: keystone: add Keystone PLL clock driver") and commit 7affe5685c96 ("clk: keystone: Add gate control clock driver") Almost eleven years is enough, so drop the "unstable" remark and expect usual ABI rules. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Stephen Boyd <sboyd@kernel.org> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20240224091236.10146-1-krzysztof.kozlowski@linaro.org Signed-off-by: Rob Herring <robh@kernel.org>
2024-04-03s390/entry: align system call table on 8 bytesSumanth Korikkar
Align system call table on 8 bytes. With sys_call_table entry size of 8 bytes that eliminates the possibility of a system call pointer crossing cache line boundary. Cc: stable@kernel.org Suggested-by: Ulrich Weigand <ulrich.weigand@de.ibm.com> Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2024-04-03s390/pai: fix sampling event removal for PMU device driverThomas Richter
In case of a sampling event, the PAI PMU device drivers need a reference to this event. Currently to PMU device driver reference is removed when a sampling event is destroyed. This may lead to situations where the reference of the PMU device driver is removed while being used by a different sampling event. Reset the event reference pointer of the PMU device driver when a sampling event is deleted and before the next one might be added. Fixes: 39d62336f5c1 ("s390/pai: add support for cryptography counters") Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Acked-by: Sumanth Korikkar <sumanthk@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2024-04-03s390/preempt: mark all functions __always_inlineIlya Leoshkevich
preempt_count-related functions are quite ubiquitous and may be called by noinstr ones, introducing unwanted instrumentation. Here is one example call chain: irqentry_nmi_enter() # noinstr lockdep_hardirqs_enabled() this_cpu_read() __pcpu_size_call_return() this_cpu_read_*() this_cpu_generic_read() __this_cpu_generic_read_nopreempt() preempt_disable_notrace() __preempt_count_inc() __preempt_count_add() They are very small, so there are no significant downsides to force-inlining them. Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Link: https://lore.kernel.org/r/20240320230007.4782-3-iii@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2024-04-03s390/atomic: mark all functions __always_inlineIlya Leoshkevich
Atomic functions are quite ubiquitous and may be called by noinstr ones, introducing unwanted instrumentation. They are very small, so there are no significant downsides to force-inlining them. Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Link: https://lore.kernel.org/r/20240320230007.4782-2-iii@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2024-04-03s390/mm: fix NULL pointer dereferenceHeiko Carstens
The recently added check to figure out if a fault happened on gmap ASCE dereferences the gmap pointer in lowcore without checking that it is not NULL. For all non-KVM processes the pointer is NULL, so that some value from lowcore will be read. With the current layouts of struct gmap and struct lowcore the read value (aka ASCE) is zero, so that this doesn't lead to any observable bug; at least currently. Fix this by adding the missing NULL pointer check. Fixes: 64c3431808bd ("s390/entry: compare gmap asce to determine guest/host fault") Acked-by: Sven Schnelle <svens@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2024-04-03ASoC: SOF: imx: remove imx8_*_clocks APILaurentiu Mihalcea
Since the i.MX drivers no longer use the imx8_*_clocks API this can be removed. Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://msgid.link/r/20240328221201.24722-3-laurentiumihalcea111@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-03ASoC: SOF: imx: drop usage of the imx8_*_clocks APILaurentiu Mihalcea
Currently, the driver has to keep track of all the clocks it uses via an array of "struct clk_bulk_data", which doesn't scale well and is unnecessary. As such, replace the usage of the imx8_*_clocks with "devm_clk_bulk_get_all()" and friends. Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://msgid.link/r/20240328221201.24722-2-laurentiumihalcea111@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-03ASoC: codecs: rk3308: depend on ARM64 || COMPILE_TESTLuca Ceresoli
This codec is only known to exist in the RK3308 ARM64 SoC, so depend on it except for compile test cases. Note that the driver won't probe without CONFIG_OF, but ARM64 selects OF already so it is not needed. Suggested-by: Mark Brown <broonie@kernel.org> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://msgid.link/r/20240403-rk3308-audio-codec-fix-warning-v2-2-816bae4c1dc5@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-03ASoC: codecs: rk3308: fix "defined but not used" warning on !OFLuca Ceresoli
Building with CONFIG_OF=n triggers: warning: 'rk3308_codec_of_match' defined but not used [-Wunused-const-variable=] warning: unused variable 'rk3308_codec_of_match' [-Wunused-const-variable] Even though OF is needed for probing, fix by declaring as __maybe_unused to still allow building on non-OF configurations for build testing. Fixes: 9fdd7b45da18 ("arm64: defconfig: enable Rockchip RK3308 internal audio codec driver") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202403271905.BYbGJiPi-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202403271907.0z0uuG5I-lkp@intel.com/ Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://msgid.link/r/20240403-rk3308-audio-codec-fix-warning-v2-1-816bae4c1dc5@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-03gpiolib: Fix triggering "kobject: 'gpiochipX' is not initialized, yet" ↵Hans de Goede
kobject_get() errors When a gpiochip gets added by loading a module, then another driver may be waiting for that gpiochip to load on the deferred-probe list. If the deferred-probe for the consumer of gpiochip then triggers between the gpiodev_add_to_list_unlocked() calls which makes gpio_device_find() see the chip and the gpiochip_setup_dev() later then gpio_device_find() does a kobject_get() on an uninitialized kobject since the kobject is initialized by gpiochip_setup_dev() calling device_initialize(): arizona spi-10WM5102:00: cannot find GPIO chip arizona, deferring arizona spi-10WM5102:00: cannot find GPIO chip arizona, deferring ------------[ cut here ]------------ kobject: 'gpiochip5' (00000000241466f2): is not initialized, yet kobject_get() is being called. WARNING: CPU: 3 PID: 42 at lib/kobject.c:640 kobject_get+0x43/0x70 Call Trace: kobject_get gpio_device_find gpiod_find_and_request gpiod_get snd_byt_wm5102_mc_probe Not only is the device not initialized yet, but when the gpio-device is added to the list things like the irqchip also have not been initialized yet. So gpio_device_find() should really ignore the gpio-device until gpiochip_add_data_with_key() is fully done. Add a device_is_registered() check to gpio_device_find() to ignore gpio-devices on the list which are not yet fully initialized. Fixes: aab5c6f20023 ("gpio: set device type for GPIO chips") Suggested-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> [Bartosz: fix a typo in commit message] Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-04-03ASoC: SOF: Intel: mtl: Correct the mtl_dsp_dump outputPeter Ujfalusi
The ROM/firmware state handling has changed between CAVS and ACE architecture: CAVS: ROM and firmware uses the SRAM window for the state and status/error code reporting ACE: ROM code is using two registers to report the state and error while the firmware is using the SRAM window to report states and status/error codes. Use the generic hda_dsp_get_state() to decode ROM state and error codes and print out the firmware state and status/error code only if the SRAM window is accessible - the firmware is booted and the Status readout is not 0xffffffff. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Link: https://msgid.link/r/20240403105210.17949-8-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-03ASoC: SOF: Intel: hda-dsp/mtl: Add support for ACE ROM state codesPeter Ujfalusi
The ROM state codes differ between CAVS and ACE architecture, there is a slight overlap. Add the ACE related state defines to mtl.h, introduce new table and use it on case the function is called when running on ACE architecture. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Link: https://msgid.link/r/20240403105210.17949-7-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-03ASoC: SOF: Intel: mtl: Implement firmware boot state checkPeter Ujfalusi
With the corrected rom_status_reg values we can now add a check for target boot status for firmware booting. With the check now we can identify failed firmware boots (IMR boots) and we can use the fallback to purge boot the DSP. Fixes: 064520e8aeaa ("ASoC: SOF: Intel: Add support for MeteorLake (MTL)") Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Link: https://msgid.link/r/20240403105210.17949-6-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-03ASoC: SOF: Intel: mtl: Disable interrupts when firmware boot failedPeter Ujfalusi
In case of error during the firmware boot we need to disable the interrupts which were enabled as part of the boot sequence. Fixes: 064520e8aeaa ("ASoC: SOF: Intel: Add support for MeteorLake (MTL)") Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Link: https://msgid.link/r/20240403105210.17949-5-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-03ASoC: SOF: Intel: lnl: Correct rom_status_regPeter Ujfalusi
ACE2 architecture changed the place where the ROM updates the status code from the shared SRAM window (and HFFLGP1QW0 in ACE1) to HFDSC register for the status and HFDEC (HFDSC + 4) for the error code. The rom_status_reg is not used on LNL because it was wrongly assigned based on older platform convention (SRAM window) and it was giving inconsistent readings. Add new header file for lnl specific register definitions. Fixes: 64a63d9914a5 ("ASoC: SOF: Intel: LNL: Add support for Lunarlake platform") Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Link: https://msgid.link/r/20240403105210.17949-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-03ASoC: SOF: Intel: mtl: Correct rom_status_regPeter Ujfalusi
ACE1 architecture changed the place where the ROM updates the status code from the shared SRAM window to HFFLGP1QW0 register for the status and HFFLGP1QW0 + 4 for the error code. The rom_status_reg is not used on MTL because it was wrongly assigned based on older platform convention (SRAM window) and it was giving inconsistent readings. Fixes: 064520e8aeaa ("ASoC: SOF: Intel: Add support for MeteorLake (MTL)") Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Link: https://msgid.link/r/20240403105210.17949-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-03ASoC: SOF: Intel: hda: Create debugfs file to force a clean DSP bootPeter Ujfalusi
When IMR boot is supported on a platform it is always going to be used to boot the DSP unless some catastrophic event happens. There is no way for a developer to force a clean DSP boot without removing and re-inserting the modules. Create a 'skip_imr_boot' debugfs file which can be used to force the next DSP boot as clean (prune) boot. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240403105210.17949-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-03net: bcmgenet: Reset RBUF on first openPhil Elwell
If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: https://github.com/raspberrypi/linux/issues/3850 See: https://github.com/raspberrypi/firmware/issues/1882 Signed-off-by: Phil Elwell <phil@raspberrypi.com> Signed-off-by: Maarten Vanraes <maarten@rmail.be> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-04-03ASoC: Intel: avs: rt5682: Constify card_headset_pinsAmadeusz Sławiński
card_headset_pins is never modified, mark it const. Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Link: https://msgid.link/r/20240403093145.3375857-11-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-03ASoC: Intel: avs: rt5663: Constify card_headset_pinsAmadeusz Sławiński
card_headset_pins is never modified, mark it const. Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Link: https://msgid.link/r/20240403093145.3375857-10-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-03ASoC: Intel: avs: rt298: Constify card_headset_pinsAmadeusz Sławiński
card_headset_pins is never modified, mark it const. Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Link: https://msgid.link/r/20240403093145.3375857-9-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-03ASoC: Intel: avs: rt286: Constify card_headset_pinsAmadeusz Sławiński
card_headset_pins is never modified, mark it const. Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Link: https://msgid.link/r/20240403093145.3375857-8-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-03ASoC: Intel: avs: rt274: Constify card_headset_pinsAmadeusz Sławiński
card_headset_pins is never modified, mark it const. Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Link: https://msgid.link/r/20240403093145.3375857-7-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-03ASoC: Intel: avs: nau8825: Constify card_headset_pinsAmadeusz Sławiński
card_headset_pins is never modified, mark it const. Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Link: https://msgid.link/r/20240403093145.3375857-6-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-03ASoC: Intel: avs: es8336: Constify card_headset_pinsAmadeusz Sławiński
card_headset_pins is never modified, mark it const. Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Link: https://msgid.link/r/20240403093145.3375857-5-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-03ASoC: Intel: avs: hdaudio: Constify probing_linkAmadeusz Sławiński
probing_link is passed to devm_kmemdup, and is never modified, may as well mark it const. Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Link: https://msgid.link/r/20240403093145.3375857-4-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-03ASoC: Intel: avs: Use devm_kstrdup_constAmadeusz Sławiński
FW name is constant and we just duplicate it, use const variant of devm_kstrdup to possibly save a bit of memory. Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Link: https://msgid.link/r/20240403093145.3375857-3-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-03ASoC: Intel: avs: hdaudio: Use devm_kstrdup_constAmadeusz Sławiński
HDA codec name is constant and we just duplicate it, use const variant of devm_kstrdup to possibly save a bit of memory. Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Link: https://msgid.link/r/20240403093145.3375857-2-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-03spi: mchp-pci1xxx: Fix a possible null pointer dereference in pci1xxx_spi_probeHuai-Yuan Liu
In function pci1xxxx_spi_probe, there is a potential null pointer that may be caused by a failed memory allocation by the function devm_kzalloc. Hence, a null pointer check needs to be added to prevent null pointer dereferencing later in the code. To fix this issue, spi_bus->spi_int[iter] should be checked. The memory allocated by devm_kzalloc will be automatically released, so just directly return -ENOMEM without worrying about memory leaks. Fixes: 1cc0cbea7167 ("spi: microchip: pci1xxxx: Add driver for SPI controller of PCI1XXXX PCIe switch") Signed-off-by: Huai-Yuan Liu <qq810974084@gmail.com> Link: https://msgid.link/r/20240403014221.969801-1-qq810974084@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-03spi: spi-fsl-lpspi: remove redundant spi_controller_put callCarlos Song
devm_spi_alloc_controller will allocate an SPI controller and automatically release a reference on it when dev is unbound from its driver. It doesn't need to call spi_controller_put explicitly to put the reference when lpspi driver failed initialization. Fixes: 2ae0ab0143fc ("spi: lpspi: Avoid potential use-after-free in probe()") Signed-off-by: Carlos Song <carlos.song@nxp.com> Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Link: https://msgid.link/r/20240403084029.2000544-1-carlos.song@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-04-03ASoC: rsnd: reg cleanupMark Brown
Merge series from Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>: These are Renesas Sound driver cleanups for Gen3/Gen4.
2024-04-03octeontx2-af: Add array index checkAleksandr Mishin
In rvu_map_cgx_lmac_pf() the 'iter', which is used as an array index, can reach value (up to 14) that exceed the size (MAX_LMAC_COUNT = 8) of the array. Fix this bug by adding 'iter' value check. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 91c6945ea1f9 ("octeontx2-af: cn10k: Add RPM MAC support") Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-04-03perf/x86/intel/ds: Don't clear ->pebs_data_cfg for the last PEBS eventKan Liang
The MSR_PEBS_DATA_CFG MSR register is used to configure which data groups should be generated into a PEBS record, and it's shared among all counters. If there are different configurations among counters, perf combines all the configurations. The first perf command as below requires a complete PEBS record (including memory info, GPRs, XMMs, and LBRs). The second perf command only requires a basic group. However, after the second perf command is running, the MSR_PEBS_DATA_CFG register is cleared. Only a basic group is generated in a PEBS record, which is wrong. The required information for the first perf command is missed. $ perf record --intr-regs=AX,SP,XMM0 -a -C 8 -b -W -d -c 100000003 -o /dev/null -e cpu/event=0xd0,umask=0x81/upp & $ sleep 5 $ perf record --per-thread -c 1 -e cycles:pp --no-timestamp --no-tid taskset -c 8 ./noploop 1000 The first PEBS event is a system-wide PEBS event. The second PEBS event is a per-thread event. When the thread is scheduled out, the intel_pmu_pebs_del() function is invoked to update the PEBS state. Since the system-wide event is still available, the cpuc->n_pebs is 1. The cpuc->pebs_data_cfg is cleared. The data configuration for the system-wide PEBS event is lost. The (cpuc->n_pebs == 1) check was introduced in commit: b6a32f023fcc ("perf/x86: Fix PEBS threshold initialization") At that time, it indeed didn't hurt whether the state was updated during the removal, because only the threshold is updated. The calculation of the threshold takes the last PEBS event into account. However, since commit: b752ea0c28e3 ("perf/x86/intel/ds: Flush PEBS DS when changing PEBS_DATA_CFG") we delay the threshold update, and clear the PEBS data config, which triggers the bug. The PEBS data config update scope should not be shrunk during removal. [ mingo: Improved the changelog & comments. ] Fixes: b752ea0c28e3 ("perf/x86/intel/ds: Flush PEBS DS when changing PEBS_DATA_CFG") Reported-by: Stephane Eranian <eranian@google.com> Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240401133320.703971-1-kan.liang@linux.intel.com
2024-04-03x86/resctrl: Fix uninitialized memory read when last CPU of domain goes offlineReinette Chatre
Tony encountered this OOPS when the last CPU of a domain goes offline while running a kernel built with CONFIG_NO_HZ_FULL: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 Oops: 0000 [#1] PREEMPT SMP NOPTI ... RIP: 0010:__find_nth_andnot_bit+0x66/0x110 ... Call Trace: <TASK> ? __die() ? page_fault_oops() ? exc_page_fault() ? asm_exc_page_fault() cpumask_any_housekeeping() mbm_setup_overflow_handler() resctrl_offline_cpu() resctrl_arch_offline_cpu() cpuhp_invoke_callback() cpuhp_thread_fun() smpboot_thread_fn() kthread() ret_from_fork() ret_from_fork_asm() </TASK> The NULL pointer dereference is encountered while searching for another online CPU in the domain (of which there are none) that can be used to run the MBM overflow handler. Because the kernel is configured with CONFIG_NO_HZ_FULL the search for another CPU (in its effort to prefer those CPUs that aren't marked nohz_full) consults the mask representing the nohz_full CPUs, tick_nohz_full_mask. On a kernel with CONFIG_CPUMASK_OFFSTACK=y tick_nohz_full_mask is not allocated unless the kernel is booted with the "nohz_full=" parameter and because of that any access to tick_nohz_full_mask needs to be guarded with tick_nohz_full_enabled(). Replace the IS_ENABLED(CONFIG_NO_HZ_FULL) with tick_nohz_full_enabled(). The latter ensures tick_nohz_full_mask can be accessed safely and can be used whether kernel is built with CONFIG_NO_HZ_FULL enabled or not. [ Use Ingo's suggestion that combines the two NO_HZ checks into one. ] Fixes: a4846aaf3945 ("x86/resctrl: Add cpumask_any_housekeeping() for limbo/overflow") Reported-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Babu Moger <babu.moger@amd.com> Link: https://lore.kernel.org/r/ff8dfc8d3dcb04b236d523d1e0de13d2ef585223.1711993956.git.reinette.chatre@intel.com Closes: https://lore.kernel.org/lkml/ZgIFT5gZgIQ9A9G7@agluck-desk3/
2024-04-02Merge tag 'selinux-pr-20240402' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux Pull selinux fix from Paul Moore: "A single patch for SELinux to fix a problem where we could potentially dereference an error pointer if we failed to successfully mount selinuxfs" * tag 'selinux-pr-20240402' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux: selinux: avoid dereference of garbage after mount failure
2024-04-02MAINTAINERS: mlx5: Add Tariq ToukanTariq Toukan
Add myself as mlx5 core and EN maintainer. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Acked-by: Saeed Mahameed <saeedm@nvidia.com> Link: https://lore.kernel.org/r/20240401184347.53884-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-02ipv6: Fix infinite recursion in fib6_dump_done().Kuniyuki Iwashima
syzkaller reported infinite recursive calls of fib6_dump_done() during netlink socket destruction. [1] From the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then the response was generated. The following recvmmsg() resumed the dump for IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due to the fault injection. [0] 12:01:34 executing program 3: r0 = socket$nl_route(0x10, 0x3, 0x0) sendmsg$nl_route(r0, ... snip ...) recvmmsg(r0, ... snip ...) (fail_nth: 8) Here, fib6_dump_done() was set to nlk_sk(sk)->cb.done, and the next call of inet6_dump_fib() set it to nlk_sk(sk)->cb.args[3]. syzkaller stopped receiving the response halfway through, and finally netlink_sock_destruct() called nlk_sk(sk)->cb.done(). fib6_dump_done() calls fib6_dump_end() and nlk_sk(sk)->cb.done() if it is still not NULL. fib6_dump_end() rewrites nlk_sk(sk)->cb.done() by nlk_sk(sk)->cb.args[3], but it has the same function, not NULL, calling itself recursively and hitting the stack guard page. To avoid the issue, let's set the destructor after kzalloc(). [0]: FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 CPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:117) should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153) should_failslab (mm/slub.c:3733) kmalloc_trace (mm/slub.c:3748 mm/slub.c:3827 mm/slub.c:3992) inet6_dump_fib (./include/linux/slab.h:628 ./include/linux/slab.h:749 net/ipv6/ip6_fib.c:662) rtnl_dump_all (net/core/rtnetlink.c:4029) netlink_dump (net/netlink/af_netlink.c:2269) netlink_recvmsg (net/netlink/af_netlink.c:1988) ____sys_recvmsg (net/socket.c:1046 net/socket.c:2801) ___sys_recvmsg (net/socket.c:2846) do_recvmmsg (net/socket.c:2943) __x64_sys_recvmmsg (net/socket.c:3041 net/socket.c:3034 net/socket.c:3034) [1]: BUG: TASK stack guard page was hit at 00000000f2fa9af1 (stack is 00000000b7912430..000000009a436beb) stack guard page: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: events netlink_sock_destruct_work RIP: 0010:fib6_dump_done (net/ipv6/ip6_fib.c:570) Code: 3c 24 e8 f3 e9 51 fd e9 28 fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 41 57 41 56 41 55 41 54 55 48 89 fd <53> 48 8d 5d 60 e8 b6 4d 07 fd 48 89 da 48 b8 00 00 00 00 00 fc ff RSP: 0018:ffffc9000d980000 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3 RDX: ffff8881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358 RBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000224 R12: 0000000000000000 R13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68 FS: 0000000000000000(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000d97fff8 CR3: 0000000102309002 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <#DF> </#DF> <TASK> fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) ... fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) netlink_sock_destruct (net/netlink/af_netlink.c:401) __sk_destruct (net/core/sock.c:2177 (discriminator 2)) sk_destruct (net/core/sock.c:2224) __sk_free (net/core/sock.c:2235) sk_free (net/core/sock.c:2246) process_one_work (kernel/workqueue.c:3259) worker_thread (kernel/workqueue.c:3329 kernel/workqueue.c:3416) kthread (kernel/kthread.c:388) ret_from_fork (arch/x86/kernel/process.c:153) ret_from_fork_asm (arch/x86/entry/entry_64.S:256) Modules linked in: Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzkaller <syzkaller@googlegroups.com> Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20240401211003.25274-1-kuniyu@amazon.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-02r8169: fix issue caused by buggy BIOS on certain boards with RTL8168dHeiner Kallweit
On some boards with this chip version the BIOS is buggy and misses to reset the PHY page selector. This results in the PHY ID read accessing registers on a different page, returning a more or less random value. Fix this by resetting the page selector first. Fixes: f1e911d5d0df ("r8169: add basic phylib support") Cc: stable@vger.kernel.org Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/64f2055e-98b8-45ec-8568-665e3d54d4e6@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-02io_uring/kbuf: hold io_buffer_list reference over mmapJens Axboe
If we look up the kbuf, ensure that it doesn't get unregistered until after we're done with it. Since we're inside mmap, we cannot safely use the io_uring lock. Rely on the fact that we can lookup the buffer list under RCU now and grab a reference to it, preventing it from being unregistered until we're done with it. The lookup returns the io_buffer_list directly with it referenced. Cc: stable@vger.kernel.org # v6.4+ Fixes: 5cf4f52e6d8a ("io_uring: free io_buffer_list entries via RCU") Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-04-02io_uring/kbuf: protect io_buffer_list teardown with a referenceJens Axboe
No functional changes in this patch, just in preparation for being able to keep the buffer list alive outside of the ctx->uring_lock. Cc: stable@vger.kernel.org # v6.4+ Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-04-02io_uring/kbuf: get rid of bl->is_readyJens Axboe
Now that xarray is being exclusively used for the buffer_list lookup, this check is no longer needed. Get rid of it and the is_ready member. Cc: stable@vger.kernel.org # v6.4+ Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-04-02io_uring/kbuf: get rid of lower BGID listsJens Axboe
Just rely on the xarray for any kind of bgid. This simplifies things, and it really doesn't bring us much, if anything. Cc: stable@vger.kernel.org # v6.4+ Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-04-02vsock/virtio: fix packet delivery to tap deviceMarco Pinna
Commit 82dfb540aeb2 ("VSOCK: Add virtio vsock vsockmon hooks") added virtio_transport_deliver_tap_pkt() for handing packets to the vsockmon device. However, in virtio_transport_send_pkt_work(), the function is called before actually sending the packet (i.e. before placing it in the virtqueue with virtqueue_add_sgs() and checking whether it returned successfully). Queuing the packet in the virtqueue can fail even multiple times. However, in virtio_transport_deliver_tap_pkt() we deliver the packet to the monitoring tap interface only the first time we call it. This certainly avoids seeing the same packet replicated multiple times in the monitoring interface, but it can show the packet sent with the wrong timestamp or even before we succeed to queue it in the virtqueue. Move virtio_transport_deliver_tap_pkt() after calling virtqueue_add_sgs() and making sure it returned successfully. Fixes: 82dfb540aeb2 ("VSOCK: Add virtio vsock vsockmon hooks") Cc: stable@vge.kernel.org Signed-off-by: Marco Pinna <marco.pinn95@gmail.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Link: https://lore.kernel.org/r/20240329161259.411751-1-marco.pinn95@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-02ax25: fix use-after-free bugs caused by ax25_ds_del_timerDuoming Zhou
When the ax25 device is detaching, the ax25_dev_device_down() calls ax25_ds_del_timer() to cleanup the slave_timer. When the timer handler is running, the ax25_ds_del_timer() that calls del_timer() in it will return directly. As a result, the use-after-free bugs could happen, one of the scenarios is shown below: (Thread 1) | (Thread 2) | ax25_ds_timeout() ax25_dev_device_down() | ax25_ds_del_timer() | del_timer() | ax25_dev_put() //FREE | | ax25_dev-> //USE In order to mitigate bugs, when the device is detaching, use timer_shutdown_sync() to stop the timer. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Duoming Zhou <duoming@zju.edu.cn> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20240329015023.9223-1-duoming@zju.edu.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-02bcachefs: ratelimit informational fsck errorsKent Overstreet
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>