summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-12-31riscv: dts: microchip: fix memory node unit address for icicleConor Dooley1-1/+1
[ Upstream commit d6105a8b7c160a73ae04054c8921eba80a294146 ] Evidently I forgot to update the unit address for the 38-bit cached memory node when I changed the address in the reg property.. Update it to match. Fixes: 6c1193301791 ("riscv: dts: microchip: update memory configuration for v2022.10") Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31firmware: ti_sci: Fix polled mode during system suspendGeorgi Vlaev1-3/+2
[ Upstream commit b13b2c3e0e4d0854228b5217fa34e145f3ace8ac ] Commit b9e8a7d950ff ("firmware: ti_sci: Switch transport to polled mode during system suspend") uses read_poll_timeout_atomic() macro in ti_sci_do_xfer() to wait for completion when the system is suspending. The break condition of the macro is set to "true" which will cause it break immediately when evaluated, likely before the TISCI xfer is completed, and always return 0. We want to poll here until "done_state == true". 1) Change the break condition of read_poll_timeout_atomic() to the bool variable "done_state". 2) The read_poll_timeout_atomic() returns 0 if the break condition is met or -ETIMEDOUT if not. Since our break condition has changed to "done_state", we also don't have to check for "!done_state" when evaluating the return value. Fixes: b9e8a7d950ff ("firmware: ti_sci: Switch transport to polled mode during system suspend") Signed-off-by: Georgi Vlaev <g-vlaev@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20221021185704.181316-1-g-vlaev@ti.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31drivers: soc: ti: knav_qmss_queue: Mark knav_acc_firmwares as staticChen Jiahao1-1/+1
[ Upstream commit adf85adc2a7199b41e7a4da083bd17274a3d6969 ] There is a sparse warning shown below: drivers/soc/ti/knav_qmss_queue.c:70:12: warning: symbol 'knav_acc_firmwares' was not declared. Should it be static? Since 'knav_acc_firmwares' is only called within knav_qmss_queue.c, mark it as static to fix the warning. Fixes: 96ee19becc3b ("soc: ti: add firmware file name as part of the driver") Signed-off-by: Chen Jiahao <chenjiahao16@huawei.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20221019153212.72350-1-chenjiahao16@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31ARM: dts: stm32: Fix AV96 WLAN regulator gpio propertyMarek Vasut1-1/+1
[ Upstream commit d5d577e3d50713ad11d98dbdaa48bb494346c26d ] The WLAN regulator uses 'gpios' property instead of 'gpio' to specify regulator enable GPIO. While the former is also currently handled by the Linux kernel regulator-fixed driver, the later is the correct one per DT bindings. Update the DT to use the later. Fixes: 7dd5cbba42c93 ("ARM: dts: stm32: Enable WiFi on AV96") Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31ARM: dts: stm32: Drop stm32mp15xc.dtsi from Avenger96Marek Vasut1-1/+0
[ Upstream commit 3b835f1b8acef53c8882b25f40f48d7f5982c938 ] The Avenger96 is populated with STM32MP157A DHCOR SoM, drop the stm32mp15xc.dtsi which should only be included in DTs of devices which are populated with STM32MP15xC/F SoC as the stm32mp15xc.dtsi enables CRYP block not present in the STM32MP15xA/D SoC . Fixes: 7e76f82acd9e1 ("ARM: dts: stm32: Split Avenger96 into DHCOR SoM and Avenger96 board") Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31objtool, kcsan: Add volatile read/write instrumentation to whitelistMarco Elver1-0/+10
[ Upstream commit 63646fcba5bb4b59a19031c21913f94e46a3d0d4 ] Adds KCSAN's volatile instrumentation to objtool's uaccess whitelist. Recent kernel change have shown that this was missing from the uaccess whitelist (since the first upstreamed version of KCSAN): mm/gup.o: warning: objtool: fault_in_readable+0x101: call to __tsan_volatile_write1() with UACCESS enabled Fixes: 75d75b7a4d54 ("kcsan: Support distinguishing volatile accesses") Signed-off-by: Marco Elver <elver@google.com> Reviewed-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31memory: renesas-rpc-if: Clear HS bit during hardware initializationCong Dang1-0/+3
[ Upstream commit 5192481f908e576be42bd39ec12979b79e11f7e0 ] According to the datasheet, HS bit should be specified to 1 when using DMA transfer. As DMA transfer is not supported, it should be cleared to 0. Previously, the driver relied on the HS bit being cleared by prior firmware but this is not always the case. Fix this by ensuring the bit is cleared during hardware initialization. Fixes: ca7d8b980b67 ("memory: add Renesas RPC-IF driver") Signed-off-by: Cong Dang <cong.dang.xn@renesas.com> Signed-off-by: Hai Pham <hai.pham.ud@renesas.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/08d9fb10b3051decebf871267a6e2e7cb2d4faf9.1665583089.git.geert+renesas@glider.be Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31arm64: dts: fsd: fix drive strength values as per FSD HW UMPadmanabhan Rajanbabu1-13/+13
[ Upstream commit 21f6546e8bf68a847601e2710378e2224bf49704 ] Drive strength values used for HSI2C, SPI and UART are not reflecting the default values recommended by FSD HW UM. Fixes: 684dac402f21 ("arm64: dts: fsd: Add initial pinctrl support") Signed-off-by: Padmanabhan Rajanbabu <p.rajanbabu@samsung.com> Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Link: https://lore.kernel.org/r/20221013104024.50179-3-p.rajanbabu@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31arm64: dts: fsd: fix drive strength macros as per FSD HW UMPadmanabhan Rajanbabu2-7/+7
[ Upstream commit 574d6c59daefb51729b0640465f007f6c9600358 ] Drive strength macros defined for FSD platform is not reflecting actual names and values as per HW UM. FSD SoC pinctrl has following four levels of drive-strength and their corresponding values: Level-1 <-> 0 Level-2 <-> 1 Level-4 <-> 2 Level-6 <-> 3 The commit 684dac402f21 ("arm64: dts: fsd: Add initial pinctrl support") used drive strength macros defined for Exynos4 SoC family. For some IPs the macros values of Exynos4 matched and worked well, but Exynos4 SoC family drive-strength (names and values) is not exactly matching with FSD SoC. Fix the drive strength macros to reflect actual names and values given in FSD HW UM. Fixes: 684dac402f21 ("arm64: dts: fsd: Add initial pinctrl support") Signed-off-by: Padmanabhan Rajanbabu <p.rajanbabu@samsung.com> Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Link: https://lore.kernel.org/r/20221013104024.50179-2-p.rajanbabu@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31arm64: dts: qcom: msm8916: Drop MSS fallback compatibleStephan Gerhold1-1/+1
[ Upstream commit ff02ac621634e82c0c34d02a79d402ae700cdfd0 ] MSM8916 was originally using the "qcom,q6v5-pil" compatible for the MSS remoteproc. Later it was decided to use SoC-specific compatibles instead, so "qcom,msm8916-mss-pil" is now the preferred compatible. Commit 60a05ed059a0 ("arm64: dts: qcom: msm8916: Add MSM8916-specific compatibles to SCM/MSS") updated the MSM8916 device tree to make use of the new compatible but still kept the old "qcom,q6v5-pil" as fallback. This is inconsistent with other SoCs and conflicts with the description in the binding documentation (which says that only one compatible should be present). Also, it has no functional advantage since older kernels could not handle this DT anyway (e.g. "power-domains" in the MSS node is only supported by kernels that also support "qcom,msm8916-mss-pil"). Make this consistent with other SoCs by using only the "qcom,msm8916-mss-pil" compatible. Fixes: 60a05ed059a0 ("arm64: dts: qcom: msm8916: Add MSM8916-specific compatibles to SCM/MSS") Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220718140344.1831731-2-stephan.gerhold@kernkonzept.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31arm64: dts: qcom: sdm845-cheza: fix AP suspend pin biasKrzysztof Kozlowski1-2/+2
[ Upstream commit 9bce41fab14da8f21027dc9847535ef5e22cbe8b ] There is no "bias-no-pull" property. Assume intentions were disabling bias. Fixes: 79e7739f7b87 ("arm64: dts: qcom: sdm845-cheza: add initial cheza dt") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221010114417.29859-3-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31arm64: dts: qcom: sdm630: fix UART1 pin biasKrzysztof Kozlowski1-1/+1
[ Upstream commit 780f836fe071a9e8703fe6a05ae00129acf83391 ] There is no "bias-no-pull" property. Assume intentions were disabling bias. Fixes: b190fb010664 ("arm64: dts: qcom: sdm630: Add sdm630 dts file") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221010114417.29859-1-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31ARM: dts: qcom: apq8064: fix coresight compatibleLuca Weiss1-1/+1
[ Upstream commit a42b1ee868361f1cb0492f1bdaefb43e0751e468 ] There's a typo missing the arm, prefix of arm,coresight-etb10. Fix it to make devicetree validation happier. Signed-off-by: Luca Weiss <luca@z3ntu.xyz> Fixes: 7a5c275fd821 ("ARM: dts: qcom: Add apq8064 CoreSight components") Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221013190657.48499-3-luca@z3ntu.xyz Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31arm64: dts: qcom: msm8996: fix GPU OPP tableDmitry Baryshkov1-5/+5
[ Upstream commit 0d440d811e6e2f37093e54db55bc27fe66678170 ] Fix Adreno OPP table according to the msm-3.18. Enable 624 MHz for the speed bin 3 and 560 MHz for bins 2 and 3. Fixes: 69cc3114ab0f ("arm64: dts: Add Adreno GPU definitions") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220724140421.1933004-7-dmitry.baryshkov@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31arm64: dts: qcom: msm8996: fix supported-hw in cpufreq OPP tablesDmitry Baryshkov1-9/+29
[ Upstream commit 0154caaa2b748e7414a4ec3c6ee60e8f483b2d4f ] Adjust MSM8996 cpufreq tables according to tables in msm-3.18. Some of the frequencies are not supported on speed bins other than 0. Also other speed bins support intermediate topmost frequencies, not supported on speed bin 0. Implement all these differencies. Fixes: 90173a954a22 ("arm64: dts: qcom: msm8996: Add CPU opps") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220724140421.1933004-5-dmitry.baryshkov@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31arm64: dts: qcom: msm8996: Add MSM8996 Pro supportYassine Oudjana2-41/+307
[ Upstream commit 8898c9748a872866f8c2973e719b26bf7c6ab64e ] Qualcomm MSM8996 Pro is a variant of MSM8996 with higher frequencies supported both on CPU and GPU. There are other minor hardware differencies in the CPU and GPU regulators and bus fabrics. However this results in significant differences between 8996 and 8996 Pro CPU OPP tables. Judging from msm-3.18 there are only few common frequencies supported by both msm8996 and msm8996pro. Rather than hacking the tables for msm8996, split msm8996pro support into a separate file. Later this would allow having additional customizations for the CBF, CPR, retulators, etc. [DB: dropped all non-CPU-OPP changes] Fixes: 90173a954a22 ("arm64: dts: qcom: msm8996: Add CPU opps") Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com> [DB: Realigned supported-hw to keep compat with current cpufreq driver] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220724140421.1933004-3-dmitry.baryshkov@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31arm64: dts: qcom: sdm845-xiaomi-polaris: fix codec pin conf nameKrzysztof Kozlowski1-1/+1
[ Upstream commit 58c4a0b6f4bdf8c3c2b4aad7f980e4019cc0fc83 ] Fix typo in the codec's pin name to be configured. Mismatched name caused the pin configuration to be ignored. Fixes: be497abe19bf ("arm64: dts: qcom: Add support for Xiaomi Mi Mix2s") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Tested-by: Molly Sophia <mollysophia379@gmail.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220930192039.240486-3-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31arm64: dts: qcom: sm8250-sony-xperia-edo: fix touchscreen bias-disableKrzysztof Kozlowski1-1/+1
[ Upstream commit 7ff4a646fae3697b039c6b684786a1e309e8445c ] The property to disable bias is "bias-disable". Fixes: e76c7e1f15fe ("arm64: dts: qcom: sm8250-edo: Add Samsung touchscreen") Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220930192954.242546-3-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31arm64: dts: qcom: ipq6018-cp01-c1: use BLSPI1 pinsKrzysztof Kozlowski1-0/+2
[ Upstream commit 4871d3c38893c8a585e3e96364b7fb91cda8322e ] When BLSPI1 (originally SPI0, later renamed in commit f82c48d46852 ("arm64: dts: qcom: ipq6018: correct QUP peripheral labels")) was added, the device node lacked respective pin configuration assignment. Fixes: 5bf635621245 ("arm64: dts: ipq6018: Add a few device nodes") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221006124659.217540-2-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31arm64: dts: renesas: r8a779g0: Fix HSCIF0 "brg_int" clockGeert Uytterhoeven1-1/+1
[ Upstream commit a4290d407aa9fd174d8053878783d466d3124e38 ] As serial communication requires a clock signal, the High Speed Serial Communication Interfaces with FIFO (HSCIF) are clocked by a clock that is not affected by Spread Spectrum or Fractional Multiplication. Hence change the clock input for the HSCIF0 Baud Rate Generator internal clock from the S0D3_PER clock to the SASYNCPERD1 clock (which has the same clock rate), cfr. R-Car V4H Hardware User's Manual rev. 0.54. Fixes: 987da486d84a5643 ("arm64: dts: renesas: Add Renesas R8A779G0 SoC support") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/a5bd4148f92806f7c8e577d383370f810315f586.1665155947.git.geert+renesas@glider.be Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31usb: musb: remove extra check in musb_gadget_vbus_drawIvaylo Dimitrov1-2/+0
[ Upstream commit ecec4b20d29c3d6922dafe7d2555254a454272d2 ] The checks for musb->xceiv and musb->xceiv->set_power duplicate those in usb_phy_set_power(), so there is no need of them. Moreover, not calling usb_phy_set_power() results in usb_phy_set_charger_current() not being called, so current USB config max current is not propagated through USB charger framework and charger drivers may try to draw more current than allowed or possible. Fix that by removing those extra checks and calling usb_phy_set_power() directly. Tested on Motorola Droid4 and Nokia N900 Fixes: a9081a008f84 ("usb: phy: Add USB charger support") Cc: stable <stable@kernel.org> Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> Link: https://lore.kernel.org/r/1669400475-4762-1-git-send-email-ivo.g.dimitrov.75@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31MIPS: DTS: CI20: fix reset line polarity of the ethernet controllerDmitry Torokhov1-1/+1
commit ca637c0ece144ce62ec8ef75dc127bcccd4f442a upstream. The reset line is called PWRST#, annotated as "active low" in the binding documentation, and is driven low and then high by the driver to reset the chip. However in device tree for CI20 board it was incorrectly marked as "active high". Fix it. Because (as far as I know) the ci20.dts is always built in the kernel I elected not to also add a quirk to gpiolib to force the polarity there. Fixes: db49ca38579d ("net: davicom: dm9000: switch to using gpiod API") Reported-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21Linux 6.1.1v6.1.1Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20221219182943.395169070@linuxfoundation.org Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Bagas Sanjaya <bagasdotme@gmail.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Rudi Heitbaum <rudi@heitbaum.com> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Allen Pais <apais@linux.microsoft.com> Tested-by: Slade Watkins <srw@sladewatkins.net> Tested-by: Justin M. Forbes <jforbes@fedoraproject.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21KEYS: encrypted: fix key instantiation with user-provided dataNikolaus Voss2-4/+5
commit 5adedd42245af0860ebda8fe0949f24f5204c1b1 upstream. Commit cd3bc044af48 ("KEYS: encrypted: Instantiate key with user-provided decrypted data") added key instantiation with user provided decrypted data. The user data is hex-ascii-encoded but was just memcpy'ed to the binary buffer. Fix this to use hex2bin instead. Old keys created from user provided decrypted data saved with "keyctl pipe" are still valid, however if the key is recreated from decrypted data the old key must be converted to the correct format. This can be done with a small shell script, e.g.: BROKENKEY=abcdefABCDEF1234567890aaaaaaaaaa NEWKEY=$(echo -ne $BROKENKEY | xxd -p -c32) keyctl add user masterkey "$(cat masterkey.bin)" @u keyctl add encrypted testkey "new user:masterkey 32 $NEWKEY" @u However, NEWKEY is still broken: If for BROKENKEY 32 bytes were specified, a brute force attacker knowing the key properties would only need to try at most 2^(16*8) keys, as if the key was only 16 bytes long. The security issue is a result of the combination of limiting the input range to hex-ascii and using memcpy() instead of hex2bin(). It could have been fixed either by allowing binary input or using hex2bin() (and doubling the ascii input key length). This patch implements the latter. The corresponding test for the Linux Test Project ltp has also been fixed (see link below). Fixes: cd3bc044af48 ("KEYS: encrypted: Instantiate key with user-provided decrypted data") Cc: stable@kernel.org Link: https://lore.kernel.org/ltp/20221006081709.92303897@mail.steuer-voss.de/ Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Nikolaus Voss <nikolaus.voss@haag-streit.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21cifs: fix oops during encryptionPaulo Alcantara4-79/+140
commit f7f291e14dde32a07b1f0aa06921d28f875a7b54 upstream. When running xfstests against Azure the following oops occurred on an arm64 system Unable to handle kernel write to read-only memory at virtual address ffff0001221cf000 Mem abort info: ESR = 0x9600004f EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x0f: level 3 permission fault Data abort info: ISV = 0, ISS = 0x0000004f CM = 0, WnR = 1 swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000294f3000 [ffff0001221cf000] pgd=18000001ffff8003, p4d=18000001ffff8003, pud=18000001ff82e003, pmd=18000001ff71d003, pte=00600001221cf787 Internal error: Oops: 9600004f [#1] PREEMPT SMP ... pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) pc : __memcpy+0x40/0x230 lr : scatterwalk_copychunks+0xe0/0x200 sp : ffff800014e92de0 x29: ffff800014e92de0 x28: ffff000114f9de80 x27: 0000000000000008 x26: 0000000000000008 x25: ffff800014e92e78 x24: 0000000000000008 x23: 0000000000000001 x22: 0000040000000000 x21: ffff000000000000 x20: 0000000000000001 x19: ffff0001037c4488 x18: 0000000000000014 x17: 235e1c0d6efa9661 x16: a435f9576b6edd6c x15: 0000000000000058 x14: 0000000000000001 x13: 0000000000000008 x12: ffff000114f2e590 x11: ffffffffffffffff x10: 0000040000000000 x9 : ffff8000105c3580 x8 : 2e9413b10000001a x7 : 534b4410fb86b005 x6 : 534b4410fb86b005 x5 : ffff0001221cf008 x4 : ffff0001037c4490 x3 : 0000000000000001 x2 : 0000000000000008 x1 : ffff0001037c4488 x0 : ffff0001221cf000 Call trace: __memcpy+0x40/0x230 scatterwalk_map_and_copy+0x98/0x100 crypto_ccm_encrypt+0x150/0x180 crypto_aead_encrypt+0x2c/0x40 crypt_message+0x750/0x880 smb3_init_transform_rq+0x298/0x340 smb_send_rqst.part.11+0xd8/0x180 smb_send_rqst+0x3c/0x100 compound_send_recv+0x534/0xbc0 smb2_query_info_compound+0x32c/0x440 smb2_set_ea+0x438/0x4c0 cifs_xattr_set+0x5d4/0x7c0 This is because in scatterwalk_copychunks(), we attempted to write to a buffer (@sign) that was allocated in the stack (vmalloc area) by crypt_message() and thus accessing its remaining 8 (x2) bytes ended up crossing a page boundary. To simply fix it, we could just pass @sign kmalloc'd from crypt_message() and then we're done. Luckily, we don't seem to pass any other vmalloc'd buffers in smb_rqst::rq_iov... Instead, let's map the correct pages and offsets from vmalloc buffers as well in cifs_sg_set_buf() and then avoiding such oopses. Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz> Cc: stable@vger.kernel.org Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21usb: dwc3: pci: Update PCIe device ID for USB3 controller on CPU sub-system ↵Shruthi Sanil1-1/+1
for Raptor Lake commit f05f80f217bf52443a2582bca19fd78188333f25 upstream. The device ID 0xa70e is defined for the USB3 device controller in the CPU sub-system of Raptor Lake platform. Hence updating the ID accordingly. Fixes: bad0d1d726ac ("usb: dwc3: pci: Add support for Intel Raptor Lake") Cc: stable <stable@kernel.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Shruthi Sanil <shruthi.sanil@intel.com> Link: https://lore.kernel.org/r/20221125105327.27945-1-shruthi.sanil@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21usb: typec: ucsi: Resume in separate workHeikki Krogerus2-4/+14
commit e0dced9c7d4763fd97c86a13902d135f03cc42eb upstream. It can take more than one second to check each connector when the system is resumed. So if you have, say, eight connectors, it may take eight seconds for ucsi_resume() to finish. That's a bit too much. This will modify ucsi_resume() so that it schedules a work where the interface is actually resumed instead of checking the connectors directly. The connections will also be checked in separate tasks which are queued for each connector separately. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216706 Fixes: 99f6d4361113 ("usb: typec: ucsi: Check the connection on resume") Cc: <stable@vger.kernel.org> Reported-by: Todd Brandt <todd.e.brandt@intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20221123093021.25981-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21igb: Initialize mailbox message for VF resetTony Nguyen1-1/+1
commit de5dc44370fbd6b46bd7f1a1e00369be54a041c8 upstream. When a MAC address is not assigned to the VF, that portion of the message sent to the VF is not set. The memory, however, is allocated from the stack meaning that information may be leaked to the VM. Initialize the message buffer to 0 so that no information is passed to the VM in this case. Fixes: 6ddbc4cf1f4d ("igb: Indicate failure on vf reset for empty mac address") Reported-by: Akihiko Odaki <akihiko.odaki@daynix.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Link: https://lore.kernel.org/r/20221212190031.3983342-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21staging: r8188eu: fix led register settingsMartin Kaiser1-23/+2
commit 12c6223fc1804fd9295dc50d358294539b4a4184 upstream. Using an InterTech DMG-02 dongle, the led remains on when the system goes into standby mode. After wakeup, it's no longer possible to control the led. It turned out that the register settings to enable or disable the led were not correct. They worked for some dongles like the Edimax V2 but not for others like the InterTech DMG-02. This patch fixes the register settings. Bit 3 in the led_cfg2 register controls the led status, bit 5 must always be set to be able to control the led, bit 6 has no influence on the led. Setting the mac_pinmux_cfg register is not necessary. These settings were tested with Edimax V2 and InterTech DMG-02. Cc: stable@vger.kernel.org Fixes: 8cd574e6af54 ("staging: r8188eu: introduce new hal dir for RTL8188eu driver") Suggested-by: Michael Straube <straube.linux@gmail.com> Signed-off-by: Martin Kaiser <martin@kaiser.cx> Tested-by: Michael Straube <straube.linux@gmail.com> # InterTech DMG-02, Tested-by: Philipp Hortmann <philipp.g.hortmann@gmail.com> # Edimax N150 Link: https://lore.kernel.org/r/20221015151115.232095-2-martin@kaiser.cx Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21xhci: Apply XHCI_RESET_TO_DEFAULT quirk to ADL-NReka Norman1-1/+3
commit fed70b61ef2c0aed54456db3d485b215f6cc3209 upstream. ADL-N systems have the same issue as ADL-P, where a large boot firmware delay is seen if USB ports are left in U3 at shutdown. So apply the XHCI_RESET_TO_DEFAULT quirk to ADL-N as well. This patch depends on commit 34cd2db408d5 ("xhci: Add quirk to reset host back to default state at shutdown"). The issue it fixes is a ~20s boot time delay when booting from S5. It affects ADL-N devices, and ADL-N support was added starting from v5.16. Cc: stable@vger.kernel.org Signed-off-by: Reka Norman <rekanorman@chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20221130091944.2171610-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21ALSA: hda/realtek: fix mute/micmute LEDs for a HP ProBookAndy Chi1-0/+2
commit 1d8025ec722d5e011f9299c46274eb21fb54a428 upstream. There is a HP ProBook which using ALC236 codec and need the ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF quirk to make mute LED and micmute LED work. Signed-off-by: Andy Chi <andy.chi@canonical.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20221128022849.13759-1-andy.chi@canonical.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21USB: serial: f81534: fix division by zero on line-speed changeJohan Hovold1-5/+7
commit 188c9c2e0c7f4ae864113f80c40bafb394062271 upstream. The driver leaves the line speed unchanged in case a requested speed is not supported. Make sure to handle the case where the current speed is B0 (hangup) without dividing by zero when determining the clock source. Fixes: 3aacac02f385 ("USB: serial: f81534: add high baud rate support") Cc: stable@vger.kernel.org # 4.16 Cc: Ji-Ze Hong (Peter Hong) <hpeter@gmail.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21USB: serial: f81232: fix division by zero on line-speed changeJohan Hovold1-5/+7
commit a08ca6ebafe615c9028c53fc4c9e6c9b2b1f2888 upstream. The driver leaves the line speed unchanged in case a requested speed is not supported. Make sure to handle the case where the current speed is B0 (hangup) without dividing by zero when determining the clock source. Fixes: 268ddb5e9b62 ("USB: serial: f81232: add high baud rate support") Cc: stable@vger.kernel.org # 5.2 Cc: Ji-Ze Hong (Peter Hong) <hpeter@gmail.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21USB: serial: cp210x: add Kamstrup RF sniffer PIDsBruno Thomsen1-0/+2
commit e88906b169ebcb8046e8f0ad76edd09ab41cfdfe upstream. The RF sniffers are based on cp210x where the RF frontends are based on a different USB stack. RF sniffers can analyze packets meta data including power level and perform packet injection. Can be used to perform RF frontend self-test when connected to a concentrator, ex. arch/arm/boot/dts/imx7d-flex-concentrator.dts Signed-off-by: Bruno Thomsen <bruno.thomsen@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21USB: serial: option: add Quectel EM05-G modemDuke Xin1-0/+3
commit f0052d7a1edb3d8921b4e154aa8c46c4845b3714 upstream. The EM05-G modem has 2 USB configurations that are configurable via the AT command AT+QCFG="usbnet",[ 0 | 2 ] which make the modem enumerate with the following interfaces, respectively: "RMNET" : AT + DIAG + NMEA + Modem + QMI "MBIM" : MBIM + AT + DIAG + NMEA + Modem The detailed description of the USB configuration for each mode as follows: RMNET Mode -------------- T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 21 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0311 Rev= 3.18 S: Manufacturer=Quectel S: Product=Quectel EM05-G C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=89(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms MBIM Mode -------------- T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 16 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0311 Rev= 3.18 S: Manufacturer=Quectel S: Product=Quectel EM05-G C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00 I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=89(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: Duke Xin <duke_xinanwen@163.com> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21usb: gadget: uvc: Prevent buffer overflow in setup handlerSzymon Heidrich1-2/+3
commit 4c92670b16727365699fe4b19ed32013bab2c107 upstream. Setup function uvc_function_setup permits control transfer requests with up to 64 bytes of payload (UVC_MAX_REQUEST_SIZE), data stage handler for OUT transfer uses memcpy to copy req->actual bytes to uvc_event->data.data array of size 60. This may result in an overflow of 4 bytes. Fixes: cdda479f15cd ("USB gadget: video class function driver") Cc: stable <stable@kernel.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Signed-off-by: Szymon Heidrich <szymon.heidrich@gmail.com> Link: https://lore.kernel.org/r/20221206141301.51305-1-szymon.heidrich@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21udf: Fix extending file within last blockJan Kara1-15/+17
commit 1f3868f06855c97a4954c99b36f3fc9eb8f60326 upstream. When extending file within last block it can happen that the extent is already rounded to the blocksize and thus contains the offset we want to grow up to. In such case we would mistakenly expand the last extent and make it one block longer than it should be, exposing unallocated block in a file and causing data corruption. Fix the problem by properly detecting this case and bailing out. CC: stable@vger.kernel.org Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21udf: Do not bother looking for prealloc extents if i_lenExtents matches i_sizeJan Kara1-1/+2
commit 6ad53f0f71c52871202a7bf096feb2c59db33fc5 upstream. If rounded block-rounded i_lenExtents matches block rounded i_size, there are no preallocation extents. Do not bother walking extent linked list. CC: stable@vger.kernel.org Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21udf: Fix preallocation discarding at indirect extent boundaryJan Kara1-32/+13
commit cfe4c1b25dd6d2f056afc00b7c98bcb3dd0b1fc3 upstream. When preallocation extent is the first one in the extent block, the code would corrupt extent tree header instead. Fix the problem and use udf_delete_aext() for deleting extent to avoid some code duplication. CC: stable@vger.kernel.org Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21udf: Discard preallocation before extending file with a holeJan Kara1-28/+18
commit 16d0556568148bdcaa45d077cac9f8f7077cf70a upstream. When extending file with a hole, we tried to preserve existing preallocation for the file. However that is not very useful and complicates code because the previous extent may need to be rounded to block boundary as well (which we forgot to do thus causing data corruption for sequence like: xfs_io -f -c "pwrite 0x75e63 11008" -c "truncate 0x7b24b" \ -c "truncate 0xabaa3" -c "pwrite 0xac70b 22954" \ -c "pwrite 0x93a43 11358" -c "pwrite 0xb8e65 52211" file with 512-byte block size. Just discard preallocation before extending file to simplify things and also fix this data corruption. CC: stable@vger.kernel.org Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21irqchip/ls-extirq: Fix endianness detectionSean Anderson1-1/+1
commit 3ae977d0e4e3a2a2ccc912ca2d20c9430508ecdd upstream. parent is the interrupt parent, not the parent of node. Use node->parent. This fixes endianness detection on big-endian platforms. Fixes: 1b00adce8afd ("irqchip/ls-extirq: Fix invalid wait context by avoiding to use regmap") Signed-off-by: Sean Anderson <sean.anderson@seco.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20221201212807.616191-1-sean.anderson@seco.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21mips: ralink: mt7621: do not use kzalloc too earlyJohn Thomson1-5/+9
commit 7c18b64bba3bcad1be94b404f47b94a04b91ce79 upstream. With CONFIG_SLUB=y, following commit 6edf2576a6cc ("mm/slub: enable debugging memory wasting of kmalloc") mt7621 failed to boot very early, without showing any console messages. This exposed the pre-existing bug of mt7621.c using kzalloc before normal memory management was available. Prior to this slub change, there existed the unintended protection against "kmem_cache *s" being NULL as slab_pre_alloc_hook() happened to return NULL and bailed out of slab_alloc_node(). This allowed mt7621 prom_soc_init to fail in the soc_dev_init kzalloc, but continue booting without the SOC_BUS driver device registered. Console output from a DEBUG_ZBOOT vmlinuz kernel loading, with mm/slub modified to warn on kmem_cache zero or null: zimage at: 80B842A0 810B4BC0 Uncompressing Linux at load address 80001000 Copy device tree to address 80B80EE0 Now, booting the kernel... [ 0.000000] Linux version 6.1.0-rc3+ (john@john) (mipsel-buildroot-linux-gnu-gcc.br_real (Buildroot 2021.11-4428-g6b6741b) 12.2.0, GNU ld (GNU Binutils) 2.39) #73 SMP Wed Nov 2 05:10:01 AEST 2022 [ 0.000000] ------------[ cut here ]------------ [ 0.000000] WARNING: CPU: 0 PID: 0 at mm/slub.c:3416 kmem_cache_alloc+0x5a4/0x5e8 [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.1.0-rc3+ #73 [ 0.000000] Stack : 810fff78 80084d98 00000000 00000004 00000000 00000000 80889d04 80c90000 [ 0.000000] 80920000 807bd328 8089d368 80923bd3 00000000 00000001 80889cb0 00000000 [ 0.000000] 00000000 00000000 807bd328 8084bcb1 00000002 00000002 00000001 6d6f4320 [ 0.000000] 00000000 80c97d3d 80c97d68 fffffffc 807bd328 00000000 00000000 00000000 [ 0.000000] 00000000 a0000000 80910000 8110a0b4 00000000 00000020 80010000 80010000 [ 0.000000] ... [ 0.000000] Call Trace: [ 0.000000] [<80008260>] show_stack+0x28/0xf0 [ 0.000000] [<8070c958>] dump_stack_lvl+0x60/0x80 [ 0.000000] [<8002e184>] __warn+0xc4/0xf8 [ 0.000000] [<8002e210>] warn_slowpath_fmt+0x58/0xa4 [ 0.000000] [<801c0fac>] kmem_cache_alloc+0x5a4/0x5e8 [ 0.000000] [<8092856c>] prom_soc_init+0x1fc/0x2b4 [ 0.000000] [<80928060>] prom_init+0x44/0xf0 [ 0.000000] [<80929214>] setup_arch+0x4c/0x6a8 [ 0.000000] [<809257e0>] start_kernel+0x88/0x7c0 [ 0.000000] [ 0.000000] ---[ end trace 0000000000000000 ]--- [ 0.000000] SoC Type: MediaTek MT7621 ver:1 eco:3 [ 0.000000] printk: bootconsole [early0] enabled Allowing soc_device_register to work exposed oops in the mt7621 phy pci, and pci controller drivers from soc_device_match_attr, due to missing sentinels in the quirks tables. These were fixed with: commit 819b885cd886 ("phy: ralink: mt7621-pci: add sentinel to quirks table") not yet applied ("PCI: mt7621: add sentinel to quirks table") Link: https://lore.kernel.org/linux-mm/becf2ac3-2a90-4f3a-96d9-a70f67c66e4a@app.fastmail.com/ Fixes: 71b9b5e0130d ("MIPS: ralink: mt7621: introduce 'soc_device' initialization") Signed-off-by: John Thomson <git@johnthomson.fastmail.com.au> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21mips: ralink: mt7621: soc queries and tests as functionsJohn Thomson1-25/+61
commit b4767d4c072583dec987225b6fe3f5524a735f42 upstream. Move the SoC register value queries and tests to specific functions, to remove repetition of logic No functional changes intended Signed-off-by: John Thomson <git@johnthomson.fastmail.com.au> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21mips: ralink: mt7621: define MT7621_SYSC_BASE with __iomemJohn Thomson2-5/+6
commit a2cab953b4c077cc02878d424466d3a6eac32aaf upstream. So that MT7621_SYSC_BASE can be used later in multiple functions without needing to repeat this __iomem declaration each time Signed-off-by: John Thomson <git@johnthomson.fastmail.com.au> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21PCI: mt7621: Add sentinel to quirks tableJohn Thomson1-1/+2
commit 19098934f910b4d47cb30251dd39ffa57bef9523 upstream. Current driver is missing a sentinel in the struct soc_device_attribute array, which causes an oops when assessed by the soc_device_match(mt7621_pcie_quirks_match) call. This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attr was fixed to register the SOC as a device, in: commit 7c18b64bba3b ("mips: ralink: mt7621: do not use kzalloc too early") Fix it by adding the required sentinel. Link: https://lore.kernel.org/lkml/26ebbed1-0fe9-4af9-8466-65f841d0b382@app.fastmail.com Link: https://lore.kernel.org/r/20221205204645.301301-1-git@johnthomson.fastmail.com.au Fixes: b483b4e4d3f6 ("staging: mt7621-pci: add quirks for 'E2' revision using 'soc_device_attribute'") Signed-off-by: John Thomson <git@johnthomson.fastmail.com.au> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Acked-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21libbpf: Fix uninitialized warning in btf_dump_dump_type_dataDavid Michael1-1/+1
commit dfd0afbf151d85411b371e841f62b81ee5d1ca54 upstream. GCC 11.3.0 fails to compile btf_dump.c due to the following error, which seems to originate in btf_dump_struct_data where the returned value would be uninitialized if btf_vlen returns zero. btf_dump.c: In function ‘btf_dump_dump_type_data’: btf_dump.c:2363:12: error: ‘err’ may be used uninitialized in this function [-Werror=maybe-uninitialized] 2363 | if (err < 0) | ^ Fixes: 920d16af9b42 ("libbpf: BTF dumper support for typed data") Signed-off-by: David Michael <fedora.dm0@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Stanislav Fomichev <sdf@google.com> Acked-by: Alan Maguire <alan.maguire@oracle.com> Link: https://lore.kernel.org/bpf/87zgcu60hq.fsf@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-21x86/vdso: Conditionally export __vdso_sgx_enter_enclave()Nathan Chancellor1-0/+2
commit 45be2ad007a9c6bea70249c4cf3e4905afe4caeb upstream. Recently, ld.lld moved from '--undefined-version' to '--no-undefined-version' as the default, which breaks building the vDSO when CONFIG_X86_SGX is not set: ld.lld: error: version script assignment of 'LINUX_2.6' to symbol '__vdso_sgx_enter_enclave' failed: symbol not defined __vdso_sgx_enter_enclave is only included in the vDSO when CONFIG_X86_SGX is set. Only export it if it will be present in the final object, which clears up the error. Fixes: 8466436952017 ("x86/vdso: Implement a vDSO for Intel SGX enclave call") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Link: https://github.com/ClangBuiltLinux/linux/issues/1756 Link: https://lore.kernel.org/r/20221109000306.1407357-1-nathan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-12Linux 6.1v6.1Linus Torvalds1-1/+1
2022-12-11Merge tag 'iommu-fix-v6.1-rc8' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu Pull iommu fix from Joerg Roedel: - Fix device mask to catch all affected devices in the recently added quirk for QAT devices in the Intel VT-d driver. * tag 'iommu-fix-v6.1-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: iommu/vt-d: Fix buggy QAT device mask
2022-12-11Merge tag 'mm-hotfixes-stable-2022-12-10-1' of ↵Linus Torvalds7-19/+29
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull misc fixes from Andrew Morton: "Nine hotfixes. Six for MM, three for other areas. Four of these patches address post-6.0 issues" * tag 'mm-hotfixes-stable-2022-12-10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: memcg: fix possible use-after-free in memcg_write_event_control() MAINTAINERS: update Muchun Song's email mm/gup: fix gup_pud_range() for dax mmap: fix do_brk_flags() modifying obviously incorrect VMAs mm/swap: fix SWP_PFN_BITS with CONFIG_PHYS_ADDR_T_64BIT on 32bit tmpfs: fix data loss from failed fallocate kselftests: cgroup: update kmem test precision tolerance mm: do not BUG_ON missing brk mapping, because userspace can unmap it mailmap: update Matti Vaittinen's email address
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-29 02:46:50 +0300