Author: Dominique Martinet <[email protected]> Date: Wed May 3 16:49:26 2023 +0900 9p: virtio: fix unlikely null pointer deref in handle_rerror [ Upstream commit 13ade4ac5c28e8a014fa85278f5a4270b215f906 ] handle_rerror can dereference the pages pointer, but it is not necessarily set for small payloads. In practice these should be filtered out by the size check, but might as well double-check explicitly. This fixes the following scan-build warnings: net/9p/trans_virtio.c:401:24: warning: Dereference of null pointer [core.NullDereference] memcpy_from_page(to, *pages++, offs, n); ^~~~~~~~ net/9p/trans_virtio.c:406:23: warning: Dereference of null pointer (loaded from variable 'pages') [core.NullDereference] memcpy_from_page(to, *pages, offs, size); ^~~~~~ Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Dominique Martinet <[email protected]> Signed-off-by: Eric Van Hensbergen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dominique Martinet <[email protected]> Date: Wed May 3 16:49:27 2023 +0900 9p: virtio: make sure 'offs' is initialized in zc_request [ Upstream commit 4a73edab69d3a6623f03817fe950a2d9585f80e4 ] Similarly to the previous patch: offs can be used in handle_rerrors without initializing on small payloads; in this case handle_rerrors will not use it because of the size check, but it doesn't hurt to make sure it is zero to please scan-build. This fixes the following warning: net/9p/trans_virtio.c:539:3: warning: 3rd function call argument is an uninitialized value [core.CallAndMessage] handle_rerror(req, in_hdr_len, offs, in_pages); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Dominique Martinet <[email protected]> Signed-off-by: Eric Van Hensbergen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mario Limonciello <[email protected]> Date: Fri Aug 18 14:40:04 2023 -0500 ACPI: x86: s2idle: Fix a logic error parsing AMD constraints table [ Upstream commit 9cc8cd086f05d9a01026c65c98da88561e9c619e ] The constraints table should be resetting the `list` object after running through all of `info_obj` iterations. This adjusts whitespace as well as less code will now be included with each loop. This fixes a functional problem is fixed where a badly formed package in the inner loop may have incorrect data. Fixes: 146f1ed852a8 ("ACPI: PM: s2idle: Add AMD support to handle _DSM") Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mario Limonciello <[email protected]> Date: Fri Aug 18 14:40:02 2023 -0500 ACPI: x86: s2idle: Post-increment variables when getting constraints [ Upstream commit 3c6b1212d20bbbffcad5709ab0f2d5ed9b5859a8 ] When code uses a pre-increment it makes the reader question "why". In the constraint fetching code there is no reason for the variables to be pre-incremented so adjust to post-increment. No intended functional changes. Reviewed-by: Kuppuswamy Sathyanarayanan <[email protected]> Suggested-by: Bjorn Helgaas <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Stable-dep-of: 9cc8cd086f05 ("ACPI: x86: s2idle: Fix a logic error parsing AMD constraints table") Signed-off-by: Sasha Levin <[email protected]>
Author: Su Hui <[email protected]> Date: Wed Aug 23 10:52:13 2023 +0800 ALSA: ac97: Fix possible error value of *rac97 [ Upstream commit 67de40c9df94037769967ba28c7d951afb45b7fb ] Before committing 79597c8bf64c, *rac97 always be NULL if there is an error. When error happens, make sure *rac97 is NULL is safer. For examble, in snd_vortex_mixer(): err = snd_ac97_mixer(pbus, &ac97, &vortex->codec); vortex->isquad = ((vortex->codec == NULL) ? 0 : (vortex->codec->ext_id&0x80)); If error happened but vortex->codec isn't NULL, this may cause some problems. Move the judgement order to be clearer and better. Fixes: 79597c8bf64c ("ALSA: ac97: Fix possible NULL dereference in snd_ac97_mixer") Suggested-by: Christophe JAILLET <[email protected]> Acked-by: Christophe JAILLET <[email protected]> Signed-off-by: Su Hui <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vitaly Rodionov <[email protected]> Date: Mon Sep 4 17:00:33 2023 +0100 ALSA: hda/cirrus: Fix broken audio on hardware with two CS42L42 codecs. commit 99bf5b0baac941176a6a3d5cef7705b29808de34 upstream. Recently in v6.3-rc1 there was a change affecting behaviour of hrtimers (commit 0c52310f260014d95c1310364379772cb74cf82d) and causing few issues on platforms with two CS42L42 codecs. Canonical/Dell has reported an issue with Vostro-3910. We need to increase this value by 15ms. Link: https://bugs.launchpad.net/somerville/+bug/2031060 Fixes: 9fb9fa18fb50 ("ALSA: hda/cirrus: Add extra 10 ms delay to allow PLL settle and lock.") Signed-off-by: Vitaly Rodionov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Stefan Binding <[email protected]> Date: Fri Aug 11 13:30:44 2023 +0100 ALSA: hda/cs8409: Support new Dell Dolphin Variants [ Upstream commit 7c761166399bedfc89c928bef8015546d85a9099 ] Add 4 new Dell Dolphin Systems, same configuration as older systems. Signed-off-by: Stefan Binding <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Tue Aug 29 15:43:44 2023 +0200 ALSA: pcm: Fix missing fixup call in compat hw_refine ioctl commit 358040e3807754944dbddf948a23c6d914297ed7 upstream. The update of rate_num/den and msbits were factored out to fixup_unreferenced_params() function to be called explicitly after the hw_refine or hw_params procedure. It's called from snd_pcm_hw_refine_user(), but it's forgotten in the PCM compat ioctl. This ended up with the incomplete rate_num/den and msbits parameters when 32bit compat ioctl is used. This patch adds the missing call in snd_pcm_ioctl_hw_params_compat(). Reported-by: [email protected] Fixes: f9a076bff053 ("ALSA: pcm: calculate non-mask/non-interval parameters always when possible") Reviewed-by: Takashi Sakamoto <[email protected]> Reviewed-by: Jaroslav Kysela <[email protected]> Cc: <s[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Tue Jul 25 11:20:57 2023 +0200 ALSA: usb-audio: Add quirk for Microsoft Modern Wireless Headset [ Upstream commit 3da435063777f8d861ba5a165344e3f75f839357 ] Microsoft Modern Wireless Headset (appearing on the host as "Microsoft USB Link") has a playback and a capture mixer volume/switch, but they are fairly broken. The descriptor reports wrong dB ranges for playback, and the capture volume/switch don't influence on the actual recording at all. Moreover, there seem instabilities in the connection, and at best, we should disable the runtime PM. So this ended up with a quirk entry for: - Correct the playback dB range; I picked up some reasonable values but it's a guess work - Disable the capture mixer; it's completely useless and confuses PA/PW - Suppress get-sample-rate, apply the delay for message handling, and suppress the auto-suspend The behavior of the wheel control on the headset is somehow flaky, too, but it's an issue of HID. Link: https://bugzilla.suse.com/show_bug.cgi?id=1207129 Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jussi Laako <[email protected]> Date: Wed Jul 26 19:56:45 2023 +0300 ALSA: usb-audio: Update for native DSD support quirks [ Upstream commit f7fea075edfa085c25eb34c44ceacf3602537f98 ] Maintenance patch for native DSD support. Remove incorrect T+A device quirks. Move set of device quirks to vendor quirks. Add set of missing device and vendor quirks. Signed-off-by: Jussi Laako <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peng Fan <[email protected]> Date: Mon Aug 21 10:39:27 2023 +0800 amba: bus: fix refcount leak [ Upstream commit e312cbdc11305568554a9e18a2ea5c2492c183f3 ] commit 5de1540b7bc4 ("drivers/amba: create devices from device tree") increases the refcount of of_node, but not releases it in amba_device_release, so there is refcount leak. By using of_node_put to avoid refcount leak. Fixes: 5de1540b7bc4 ("drivers/amba: create devices from device tree") Signed-off-by: Peng Fan <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mark Brown <[email protected]> Date: Mon Jul 31 14:58:48 2023 +0100 arm64/fpsimd: Only provide the length to cpufeature for xCR registers [ Upstream commit 01948b09edc3fecf8486c57c2d2fb8b80886f3d0 ] For both SVE and SME we abuse the generic register field comparison support in the cpufeature code as part of our detection of unsupported variations in the vector lengths available to PEs, reporting the maximum vector lengths via ZCR_EL1.LEN and SMCR_EL1.LEN. Since these are configuration registers rather than identification registers the assumptions the cpufeature code makes about how unknown bitfields behave are invalid, leading to warnings when SME features like FA64 are enabled and we hotplug a CPU: CPU features: SANITY CHECK: Unexpected variation in SYS_SMCR_EL1. Boot CPU: 0x0000000000000f, CPU3: 0x0000008000000f CPU features: Unsupported CPU feature variation detected. SVE has no controls other than the vector length so is not yet impacted but the same issue will apply there if any are defined. Since the only field we are interested in having the cpufeature code handle is the length field and we use a custom read function to obtain the value we can avoid these warnings by filtering out all other bits when we return the register value, if we're doing that we don't need to bother reading the register at all and can simply use the RDVL/RDSVL value we were filling in instead. Fixes: 2e0f2478ea37 ("arm64/sve: Probe SVE capabilities and usable vector lengths") FixeS: b42990d3bf77 ("arm64/sme: Identify supported SME vector lengths at boot") Signed-off-by: Mark Brown <[email protected]> Reviewed-by: Catalin Marinas <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christophe JAILLET <[email protected]> Date: Mon Jul 17 19:55:05 2023 +0200 arm64/ptrace: Clean up error handling path in sve_set_common() [ Upstream commit 5f69ca4229c7d8e23f238174827ee7aa49b0bcb2 ] All error handling paths go to 'out', except this one. Be consistent and also branch to 'out' here. Fixes: e12310a0d30f ("arm64/sme: Implement ptrace support for streaming mode SVE registers") Signed-off-by: Christophe JAILLET <[email protected]> Reviewed-by: Mark Brown <[email protected]> Reviewed-by: Anshuman Khandual <[email protected]> Link: https://lore.kernel.org/r/aa61301ed2dfd079b74b37f7fede5f179ac3087a.1689616473.git.christophe.jaillet@wanadoo.fr Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Will Deacon <[email protected]> Date: Thu Sep 7 09:54:11 2023 +0100 arm64: csum: Fix OoB access in IP checksum code for negative lengths commit 8bd795fedb8450ecbef18eeadbd23ed8fc7630f5 upstream. Although commit c2c24edb1d9c ("arm64: csum: Fix pathological zero-length calls") added an early return for zero-length input, syzkaller has popped up with an example of a _negative_ length which causes an undefined shift and an out-of-bounds read: | BUG: KASAN: slab-out-of-bounds in do_csum+0x44/0x254 arch/arm64/lib/csum.c:39 | Read of size 4294966928 at addr ffff0000d7ac0170 by task syz-executor412/5975 | | CPU: 0 PID: 5975 Comm: syz-executor412 Not tainted 6.4.0-rc4-syzkaller-g908f31f2a05b #0 | Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023 | Call trace: | dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:233 | show_stack+0x2c/0x44 arch/arm64/kernel/stacktrace.c:240 | __dump_stack lib/dump_stack.c:88 [inline] | dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106 | print_address_description mm/kasan/report.c:351 [inline] | print_report+0x174/0x514 mm/kasan/report.c:462 | kasan_report+0xd4/0x130 mm/kasan/report.c:572 | kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:187 | __kasan_check_read+0x20/0x30 mm/kasan/shadow.c:31 | do_csum+0x44/0x254 arch/arm64/lib/csum.c:39 | csum_partial+0x30/0x58 lib/checksum.c:128 | gso_make_checksum include/linux/skbuff.h:4928 [inline] | __udp_gso_segment+0xaf4/0x1bc4 net/ipv4/udp_offload.c:332 | udp6_ufo_fragment+0x540/0xca0 net/ipv6/udp_offload.c:47 | ipv6_gso_segment+0x5cc/0x1760 net/ipv6/ip6_offload.c:119 | skb_mac_gso_segment+0x2b4/0x5b0 net/core/gro.c:141 | __skb_gso_segment+0x250/0x3d0 net/core/dev.c:3401 | skb_gso_segment include/linux/netdevice.h:4859 [inline] | validate_xmit_skb+0x364/0xdbc net/core/dev.c:3659 | validate_xmit_skb_list+0x94/0x130 net/core/dev.c:3709 | sch_direct_xmit+0xe8/0x548 net/sched/sch_generic.c:327 | __dev_xmit_skb net/core/dev.c:3805 [inline] | __dev_queue_xmit+0x147c/0x3318 net/core/dev.c:4210 | dev_queue_xmit include/linux/netdevice.h:3085 [inline] | packet_xmit+0x6c/0x318 net/packet/af_packet.c:276 | packet_snd net/packet/af_packet.c:3081 [inline] | packet_sendmsg+0x376c/0x4c98 net/packet/af_packet.c:3113 | sock_sendmsg_nosec net/socket.c:724 [inline] | sock_sendmsg net/socket.c:747 [inline] | __sys_sendto+0x3b4/0x538 net/socket.c:2144 Extend the early return to reject negative lengths as well, aligning our implementation with the generic code in lib/checksum.c Cc: Robin Murphy <[email protected]> Fixes: 5777eaed566a ("arm64: Implement optimised checksum routine") Reported-by: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Laurent Pinchart <[email protected]> Date: Mon Apr 24 12:51:24 2023 +0300 arm64: defconfig: Drop CONFIG_VIDEO_IMX_MEDIA [ Upstream commit 0ca2fbab99b12bb81fceaafe5495c00d76789a37 ] CONFIG_VIDEO_IMX_MEDIA isn't needed on arm64 platforms since commit 9f257f502c2e ("media: imx: Unstage the imx7-media-csi driver") which moved the last arm64 driver depending on that Kconfig symbol out of staging. Drop it from the arm64 defconfig. Fixes: 9f257f502c2e ("media: imx: Unstage the imx7-media-csi driver") Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Mon Jun 19 15:54:04 2023 +0300 arm64: defconfig: enable Qualcomm MSM8996 Global Clock Controller as built-in [ Upstream commit dc015a3a6d6986c41a7bd12fb205a282f685e328 ] The commit 8f680c287445 ("arm64: defconfig: Switch msm8996 clk drivers to module") switched CONFIG_MSM_MMCC_8996 to module, which also resulted in CONFIG_MSM_GCC_8996 being switched to module. This breaks useful bootflow for Qualcomm MSM8996 / APQ8096 platforms, because the serial is not enabled anymore until the GCC module is loaded. Reported-by: Rob Clark <[email protected]> Fixes: 8f680c287445 ("arm64: defconfig: Switch msm8996 clk drivers to module") Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marco Felsch <[email protected]> Date: Wed Aug 9 09:10:23 2023 +0200 arm64: dts: imx8mp-debix: remove unused fec pinctrl node [ Upstream commit 574e4099d787c2eb41a43f14c453e422515bf658 ] The SoM A uses the EQOS ethernet interface and not the FEC, so drop the interface pinctrl node from the device tree. Fixes: c86d350aae68 ("arm64: dts: Add device tree for the Debix Model A Board") Signed-off-by: Marco Felsch <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bryan O'Donoghue <[email protected]> Date: Sat Aug 12 00:47:33 2023 +0100 arm64: dts: qcom: apq8016-sbc: Fix ov5640 regulator supply names [ Upstream commit 43a684580819e7f35b6cb38236be63c4cba26ef4 ] The ov5640 driver expects DOVDD, AVDD and DVDD as regulator supply names. The ov5640 has depended on these names since the driver was committed upstream in 2017. Similarly apq8016-sbc.dtsi has had completely different regulator names since its own initial commit in 2020. Perhaps the regulators were left on in previous 410c bootloaders. In any case today on 6.5 we won't switch on the ov5640 without correctly naming the regulators. Fixes: 39e0ce6cd1bf ("arm64: dts: qcom: apq8016-sbc: Add CCI/Sensor nodes") Signed-off-by: Bryan O'Donoghue <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bryan O'Donoghue <[email protected]> Date: Sat Aug 12 00:47:36 2023 +0100 arm64: dts: qcom: apq8016-sbc: Rename ov5640 enable-gpios to powerdown-gpios [ Upstream commit 4facccb44a82129195878750eed8f9890091c1b8 ] There are two control lines controlled by GPIO going into ov5640 - Reset - Powerdown The driver and yaml expect "reset-gpios" and "powerdown-gpios" there has never been an "enable-gpios". Fixes: 39e0ce6cd1bf ("arm64: dts: qcom: apq8016-sbc: Add CCI/Sensor nodes") Signed-off-by: Bryan O'Donoghue <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Sat Jun 17 19:15:28 2023 +0200 arm64: dts: qcom: msm8916-l8150: correct light sensor VDDIO supply [ Upstream commit 6a541eaa6e8e5283efb993ae7a947bede8d01fa5 ] liteon,ltr559 light sensor takes VDDIO, not VIO, supply: msm8916-longcheer-l8150.dtb: light-sensor@23: 'vio-supply' does not match any of the regexes: 'pinctrl-[0-9]+' Fixes: 3016af34ef8d ("arm64: dts: qcom: msm8916-longcheer-l8150: Add light and proximity sensor") Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Nikita Travkin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: André Apitzsch <[email protected]> Date: Wed May 17 08:32:31 2023 +0200 arm64: dts: qcom: msm8916-longcheer-l8910: Add front flash LED [ Upstream commit 5d8d9330921770fb953e8e749bbd049ac0fae988 ] l8910 uses OCP8110 flash LED driver. Add it to the device tree. Tested-by: Stephan Gerhold <[email protected]> Signed-off-by: André Apitzsch <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Stable-dep-of: 4facccb44a82 ("arm64: dts: qcom: apq8016-sbc: Rename ov5640 enable-gpios to powerdown-gpios") Signed-off-by: Sasha Levin <[email protected]>
Author: Stephan Gerhold <[email protected]> Date: Wed May 17 20:48:46 2023 +0200 arm64: dts: qcom: msm8916: Define regulator constraints next to usage [ Upstream commit b0a8f16ae4a0eb423122256691849b3ebc64efc2 ] Right now each MSM8916 device has a huge block of regulator constraints with allowed voltages for each regulator. For lack of better documentation these voltages are often copied as-is from the vendor device tree, without much extra thought. Unfortunately, the voltages in the vendor device trees are often misleading or even wrong, e.g. because: - There is a large voltage range allowed and the actual voltage is only set somewhere hidden in some messy vendor driver. This is often the case for pm8916_{l14,l15,l16} because they have a broad range of 1.8-3.3V by default. - The voltage is actually wrong but thanks to the voltage constraints in the RPM firmware it still ends up applying the correct voltage. To have proper regulator constraints it is important to review them in context of the usage. The current setup in the MSM8916 device trees makes this quite hard because each device duplicates the standard voltages for components of the SoC and mixes those with minor device-specific additions and dummy voltages for completely unused regulators. The actual usage of the regulators for the SoC components is in msm8916-pm8916.dtsi, so it can and should also define the related voltage constraints. These are not board-specific but defined in the APQ8016E/PM8916 Device Specification. The board DT can then focus on describing the actual board-specific regulators, which makes it much easier to review and spot potential mistakes there. Note that this commit does not make any functional change. All used regulators still have the same regulator constraints as before. Unused regulators do not have regulator constraints anymore because most of these were too broad or even entirely wrong. They should be added back with proper voltage constraints when there is an actual usage. Signed-off-by: Stephan Gerhold <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Stable-dep-of: 4facccb44a82 ("arm64: dts: qcom: apq8016-sbc: Rename ov5640 enable-gpios to powerdown-gpios") Signed-off-by: Sasha Levin <[email protected]>
Author: Stephan Gerhold <[email protected]> Date: Wed May 17 20:48:43 2023 +0200 arm64: dts: qcom: msm8916: Disable audio codecs by default [ Upstream commit a5cf21b14666c42912327c7bece38711f6e0d708 ] Not every device has something connected to the digital audio codec in MSM8916 and/or the analog audio codec in PM8916. Disable those by default so the hardware is only powered up when necessary. Signed-off-by: Stephan Gerhold <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Stable-dep-of: 4facccb44a82 ("arm64: dts: qcom: apq8016-sbc: Rename ov5640 enable-gpios to powerdown-gpios") Signed-off-by: Sasha Levin <[email protected]>
Author: Stephan Gerhold <[email protected]> Date: Wed May 17 20:48:42 2023 +0200 arm64: dts: qcom: msm8916: Fix regulator constraints [ Upstream commit 355750828c5519c88de6ac0d09202d2a7e5892c5 ] The regulator constraints for most MSM8916 devices (except DB410c) were originally taken from Qualcomm's msm-3.10 vendor device tree (for lack of better documentation). Unfortunately it turns out that Qualcomm's voltages are slightly off as well and do not match the voltage constraints applied by the RPM firmware. This means that we sometimes request a specific voltage but the RPM firmware actually applies a much lower or higher voltage. This is particularly critical for pm8916_l11 which is used as SD card VMMC regulator: The SD card can choose a voltage from the current range of 1.8 - 2.95V. If it chooses to run at 1.8V we pretend that this is fine but the RPM firmware will still silently end up configuring 2.95V. This can be easily reproduced with a multimeter or by checking the SPMI hardware registers of the regulator. Fix this by making the voltages match the actual "specified range" in the PM8916 Device Specification which is enforced by the RPM firmware. Signed-off-by: Stephan Gerhold <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Stable-dep-of: 4facccb44a82 ("arm64: dts: qcom: apq8016-sbc: Rename ov5640 enable-gpios to powerdown-gpios") Signed-off-by: Sasha Levin <[email protected]>
Author: Stephan Gerhold <[email protected]> Date: Mon May 29 14:46:58 2023 +0200 arm64: dts: qcom: msm8916: Rename &msmgpio -> &tlmm [ Upstream commit 41e22c2ff38eaea777f1158071539e659aa7980d ] MSM8916 is the only ARM64 Qualcomm SoC that is still using the old &msmgpio name. Change this to &tlmm to avoid confusion. Note that the node ordering does not change because the MSM8916 device trees have pinctrl separated at the bottom (similar to sc7180). Signed-off-by: Stephan Gerhold <[email protected]> Reviewed-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Stable-dep-of: 4facccb44a82 ("arm64: dts: qcom: apq8016-sbc: Rename ov5640 enable-gpios to powerdown-gpios") Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Thu Jul 20 13:53:31 2023 +0200 arm64: dts: qcom: msm8996-gemini: fix touchscreen VIO supply [ Upstream commit 21fc24ee9c5943732c9ae538766c9be93d70d936 ] According to bindings and Linux driver, there is no VDDA but VIO supply. Fixes: 4ac46b3682c5 ("arm64: dts: qcom: msm8996: xiaomi-gemini: Add support for Xiaomi Mi 5") Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Tue Jun 27 18:24:27 2023 +0200 arm64: dts: qcom: msm8996: Add missing interrupt to the USB2 controller [ Upstream commit 36541089c4733355ed844c67eebd0c3936953454 ] The interrupt line was previously not described. Take care of that. Fixes: 1e39255ed29d ("arm64: dts: msm8996: Add device node for qcom,dwc3") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David Wronek <[email protected]> Date: Sat Aug 5 15:09:37 2023 +0200 arm64: dts: qcom: msm8996: Fix dsi1 interrupts [ Upstream commit bd3b4ac11845b428996cfd2c7b8302ba6a07340d ] Fix IRQ flags mismatch which was keeping dsi1 from probing by changing interrupts = <4> to interrupts = <5>. Fixes: 2752bb7d9b58 ("arm64: dts: qcom: msm8996: add second DSI interface") Signed-off-by: David Wronek <[email protected]> Acked-by: Yassine Oudjana <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Wed Aug 9 21:20:25 2023 +0200 arm64: dts: qcom: msm8998: Add missing power domain to MMSS SMMU [ Upstream commit 7f828f3207142351750e9545527341425187de7b ] The MMSS SMMU has its own power domain. Attach it so that we can drop the "keep it always-on" hack. Fixes: 05ce21b54423 ("arm64: dts: qcom: msm8998: Configure the multimedia subsystem iommu") Reviewed-by: Jeffrey Hugo <[email protected]> Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Wed Aug 9 21:20:24 2023 +0200 arm64: dts: qcom: msm8998: Drop bus clock reference from MMSS SMMU [ Upstream commit a3ce236364b82688ca4c7605f63c4efd68e9589c ] The MMSS SMMU has been abusingly consuming the exposed RPM interconnect clock. Drop it. Fixes: 05ce21b54423 ("arm64: dts: qcom: msm8998: Configure the multimedia subsystem iommu") Reviewed-by: Jeffrey Hugo <[email protected]> Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Mon Jun 26 22:00:25 2023 +0200 arm64: dts: qcom: pm6150l: Add missing short interrupt [ Upstream commit 7e1f024ef0d1da456f61d00f01dc3287ede915b3 ] Add the missing short interrupt. This fixes the schema warning: wled@d800: interrupt-names: ['ovp'] is too short Fixes: fe508ced49dd ("arm64: dts: qcom: pm6150l: Add wled node") Signed-off-by: Konrad Dybcio <[email protected]> Reviewed-by: Luca Weiss <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Mon Jun 26 22:00:26 2023 +0200 arm64: dts: qcom: pm660l: Add missing short interrupt [ Upstream commit 9a4ac09db3c7413e334b4abd6b2f6de8930dd781 ] Add the missing short interrupt. This fixes the schema warning: wled@d800: interrupt-names: ['ovp'] is too short Fixes: 7b56a804e58b ("arm64: dts: qcom: pm660l: Add WLED support") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Fri Jul 7 15:30:21 2023 +0300 arm64: dts: qcom: pm8350: fix thermal zone name [ Upstream commit 64f19c06f704846db5e4885ca63c689d9bef5723 ] The name of the thermal zone in pm8350.dtsi (pm8350c-thermal) conflicts with the thermal zone in pm8350c.dtsi. Rename the thermal zone according to the chip name. Fixes: 7a79b95f4288 ("arm64: dts: qcom: pm8350: add temp sensor and thermal zone config") Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Fri Jul 7 15:30:22 2023 +0300 arm64: dts: qcom: pm8350b: fix thermal zone name [ Upstream commit aad41d9e6c44dfe299cddab97528a5333f17bdfe ] The name of the thermal zone in pm8350b.dtsi (pm8350c-thermal) conflicts with the thermal zone in pm8350c.dtsi. Rename the thermal zone according to the chip name. Fixes: 5c1399299d9d ("arm64: dts: qcom: pm8350b: add temp sensor and thermal zone config") Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Mon Jun 26 22:00:27 2023 +0200 arm64: dts: qcom: pmi8950: Add missing OVP interrupt [ Upstream commit 4d77b639531fd85b84a7079c3369908dfaddf8b2 ] Add the missing OVP interrupt. This fixes the schema warning: wled@d800: interrupt-names: ['short'] is too short Fixes: 0d97fdf380b4 ("arm64: dts: qcom: Add configuration for PMI8950 peripheral") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Mon Jun 26 22:00:28 2023 +0200 arm64: dts: qcom: pmi8994: Add missing OVP interrupt [ Upstream commit 8db94432690371b1736e9a2566a9b3d8a73d5a97 ] Add the missing OVP interrupt. This fixes the schema warning: wled@d800: interrupt-names: ['short'] is too short Fixes: 37aa540cbd30 ("arm64: dts: qcom: pmi8994: Add WLED node") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Fri Jul 7 15:30:24 2023 +0300 arm64: dts: qcom: pmk8350: fix ADC-TM compatible string [ Upstream commit 435a73d7377ceb29c1a22d2711dd85c831b40c45 ] The commit b2de43136058 ("arm64: dts: qcom: pmk8350: Add peripherals for pmk8350") for the ADC TM (thermal monitoring device) have used the compatible string from the vendor kernel ("qcom,adc-tm7"). Use the proper compatible string that is defined in the upstream kernel ("qcom,spmi-adc-tm5-gen2"). Fixes: b2de43136058 ("arm64: dts: qcom: pmk8350: Add peripherals for pmk8350") Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Fri Jul 7 15:30:23 2023 +0300 arm64: dts: qcom: pmr735b: fix thermal zone name [ Upstream commit 99f8cf491d546cd668236f573c7d846d3e94f2d6 ] The name of the thermal zone in pmr735b.dtsi (pmr735a-thermal) conflicts with the thermal zone in pmr735a.dtsi. Rename the thermal zone according to the chip name. Fixes: 6f3426b3dea4 ("arm64: dts: qcom: pmr735b: add temp sensor and thermal zone config") Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bjorn Andersson <[email protected]> Date: Tue Jun 20 13:39:14 2023 -0700 arm64: dts: qcom: sc8280xp-crd: Correct vreg_misc_3p3 GPIO [ Upstream commit 9566b5271f68bdf6e69b7c511850e3fb75cd18be ] The vreg_misc_3p3 regulator is controlled by PMC8280_1 GPIO 2, not 1, on the CRD. Fixes: ccd3517faf18 ("arm64: dts: qcom: sc8280xp: Add reference device") Signed-off-by: Bjorn Andersson <[email protected]> Reviewed-by: Johan Hovold <[email protected]> Tested-by: Johan Hovold <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Thu Aug 3 15:05:26 2023 +0200 arm64: dts: qcom: sc8280xp-x13s: Unreserve NC pins [ Upstream commit 7868ed0144b33903e16a50485775f669c109e41a ] Pins 83-86 and 158-160 are NC, so there's no point in keeping them reserved. Take care of that. Fixes: 32c231385ed4 ("arm64: dts: qcom: sc8280xp: add Lenovo Thinkpad X13s devicetree") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Thu Jun 22 17:56:16 2023 +0200 arm64: dts: qcom: sc8280xp: Add missing SCM interconnect [ Upstream commit 0a69ccf20b0837db857abfc94d7e3bacf1cb771b ] The SCM interconnect path was missing. Add it. Fixes: 152d1faf1e2f ("arm64: dts: qcom: add SC8280XP platform") Signed-off-by: Konrad Dybcio <[email protected]> Reviewed-by: Johan Hovold <[email protected]> Tested-by: Johan Hovold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Tue Jun 27 19:27:50 2023 +0200 arm64: dts: qcom: sdm845-tama: Set serial indices and stdout-path [ Upstream commit 9acc60c3e2d449243e4c2126e3b56f1c4f7fd3bc ] UART6 is used for debug (routed via uSD pins) and UART9 is connected to the bluetooth chip. Set indexed aliases to make the GENI UART driver happy and route serial traffic through the debug uart by default. Fixes: 30a7f99befc6 ("arm64: dts: qcom: Add support for SONY Xperia XZ2 / XZ2C / XZ3 (Tama platform)") Signed-off-by: Konrad Dybcio <[email protected]> Reviewed-by: Marijn Suijten <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Manivannan Sadhasivam <[email protected]> Date: Thu Jul 20 11:10:48 2023 +0530 arm64: dts: qcom: sdm845: Add missing RPMh power domain to GCC [ Upstream commit 4b6ea15c0a1122422b44bf6c47a3c22fc8d46777 ] GCC and it's GDSCs are under the RPMh CX power domain. So let's add the missing RPMh power domain to the GCC node. Fixes: 6d4cf750d03a ("arm64: dts: sdm845: Add minimal dts/dtsi files for sdm845 SoC and MTP") Reviewed-by: Konrad Dybcio <[email protected]> Co-developed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Manivannan Sadhasivam <[email protected]> Date: Thu Jul 20 11:10:49 2023 +0530 arm64: dts: qcom: sdm845: Fix the min frequency of "ice_core_clk" [ Upstream commit bbbef6e24bc4493602df68b052f6f48d48e3184a ] Minimum frequency of the "ice_core_clk" should be 75MHz as specified in the downstream vendor devicetree. So fix it! https://git.codelinaro.org/clo/la/kernel/msm-4.9/-/blob/LA.UM.7.3.r1-09300-sdm845.0/arch/arm64/boot/dts/qcom/sdm845.dtsi Fixes: 433f9a57298f ("arm64: dts: sdm845: add Inline Crypto Engine registers and clock") Signed-off-by: Manivannan Sadhasivam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Wed Jun 14 13:35:37 2023 +0200 arm64: dts: qcom: sm6350: Fix ZAP region [ Upstream commit 44bcded2be4fe9b9d0b6e48075c9947b75c0af63 ] The previous ZAP region definition was wrong. Fix it. Note this is not a device-specific fixup, but a fixup to the generic PIL load address. Fixes: 5f82b9cda61e ("arm64: dts: qcom: Add SM6350 device tree") Signed-off-by: Konrad Dybcio <[email protected]> Reviewed-by: Luca Weiss <[email protected]> Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zeyan Li <[email protected]> Date: Thu Jul 27 10:53:21 2023 +0800 arm64: dts: qcom: sm8150: Fix the I2C7 interrupt [ Upstream commit f9568d22ce06192a7e14bda3a29dc216659554ff ] I2C6 and I2C7 use the same interrupts, which is incorrect. In the downstream kernel, I2C7 has interrupts of 608 instead of 607. Fixes: 81bee6953b58 ("arm64: dts: qcom: sm8150: add i2c nodes") Signed-off-by: Zeyan Li <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/SY7P282MB378712225CBCEA95FE71554DB201A@SY7P282MB3787.AUSP282.PROD.OUTLOOK.COM Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Mon Jun 12 06:16:23 2023 +0300 arm64: dts: qcom: sm8150: use proper DSI PHY compatible [ Upstream commit 3091e5820a367f3368132f57e0a9ba6d545da15d ] The DSI PHY on the Qualcomm SM8150 platform requires platform-specific handling. Use the proper SoC-specific compatible string for the DSI PHYs. Reported-by: Degdag Mohamed <[email protected]> Fixes: 2ef3bb17c45c ("arm64: dts: qcom: sm8150: Add DISPCC node") Cc: Konrad Dybcio <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Marijn Suijten <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Tue Jun 20 13:05:35 2023 +0200 arm64: dts: qcom: sm8250-edo: Add GPIO line names for PMIC GPIOs [ Upstream commit 6b8a63350752c6a5e4b54f2de6174084652cd3cd ] Sony ever so graciously provides GPIO line names in their downstream kernel (though sometimes they are not 100% accurate and you can judge that by simply looking at them and with what drivers they are used). Add these to the PDX203&206 DTSIs to better document the hardware. Diff between 203 and 206: pm8009_gpios < "CAM_PWR_LD_EN", > "NC", pm8150_gpios < "NC", > "G_ASSIST_N", < "WLC_EN_N", /* GPIO_10 */ > "NC", /* GPIO_10 */ Which is due to 5 II having an additional Google Assistant hardware button and 1 II having a wireless charger & different camera wiring to accommodate the additional 3D iToF sensor. Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Stable-dep-of: a422c6a91a66 ("arm64: dts: qcom: sm8250-edo: Rectify gpio-keys") Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Tue Jun 20 13:05:34 2023 +0200 arm64: dts: qcom: sm8250-edo: Add gpio line names for TLMM [ Upstream commit 40b398beabdfe0e9088b13976e56b1dc706fe851 ] Sony ever so graciously provides GPIO line names in their downstream kernel (though sometimes they are not 100% accurate and you can judge that by simply looking at them and with what drivers they are used). Add these to the PDX203&206 DTSIs to better document the hardware. Diff between 203 and 206: < "CAM_PWR_A_CS", > "FRONTC_PWR_EN", < "CAM4_MCLK", < "TOF_RST_N", > "NC", > "NC", < "WLC_I2C_SDA", < "WLC_I2C_SCL", /* GPIO_120 */ > "NC", > "NC", < "WLC_INT_N", > "NC", Which makes sense, as 203 has a 3D iToF, slightly different camera power wiring and WLC (WireLess Charging). Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Stable-dep-of: a422c6a91a66 ("arm64: dts: qcom: sm8250-edo: Rectify gpio-keys") Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Tue Jun 20 13:05:37 2023 +0200 arm64: dts: qcom: sm8250-edo: Rectify gpio-keys [ Upstream commit a422c6a91a667b309ca1a6c08b30dbfcf7d4e866 ] Set up the corresponding GPIOs properly and add the leftover hardware buttons to mark this piece of the puzzle complete. Fixes: 46e14907c716 ("arm64: dts: qcom: sm8250-edo: Add hardware keys") Reviewed-by: Marijn Suijten <[email protected]> Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Tue Jul 11 08:30:11 2023 +0200 arm64: dts: qcom: sm8250-sony-xperia: correct GPIO keys wakeup again [ Upstream commit b8fbeea0253211d97c579eae787274633d3eaf0d ] gpio-keys,wakeup is a deprecated property: m8250-sony-xperia-edo-pdx206.dtb: gpio-keys: key-camera-focus: Unevaluated properties are not allowed ('gpio-key,wakeup' was unexpected) Fixes: a422c6a91a66 ("arm64: dts: qcom: sm8250-edo: Rectify gpio-keys") Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vincent Guittot <[email protected]> Date: Thu Jun 15 17:48:52 2023 +0200 arm64: dts: qcom: sm8250: correct dynamic power coefficients [ Upstream commit 775a5283c25d160b2a1359018c447bc518096547 ] sm8250 faces the same problem with its Energy Model as sdm845. The energy cost of LITTLE cores is reported to be higher than medium or big cores EM computes the energy with formula: energy = OPP's cost / maximum cpu capacity * utilization On v6.4-rc6 we have: max capacity of CPU0 = 284 capacity of CPU0's OPP(1612800 Hz) = 253 cost of CPU0's OPP(1612800 Hz) = 191704 max capacity of CPU4 = 871 capacity of CPU4's OPP(710400 Hz) = 255 cost of CPU4's OPP(710400 Hz) = 343217 Both OPPs have almost the same compute capacity but the estimated energy per unit of utilization will be estimated to: energy CPU0 = 191704 / 284 * 1 = 675 energy CPU4 = 343217 / 871 * 1 = 394 EM estimates that little CPU0 will consume 71% more than medium CPU4 for the same compute capacity. According to [1], little consumes 25% less than medium core for Coremark benchmark at those OPPs for the same duration. Set the dynamic-power-coefficient of CPU0-3 to 105 to fix the energy model for little CPUs. [1] https://github.com/kdrag0n/freqbench/tree/master/results/sm8250/k30s Fixes: 6aabed5526ee ("arm64: dts: qcom: sm8250: Add CPU capacities and energy model") Signed-off-by: Vincent Guittot <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Tue Jul 4 14:23:17 2023 +0200 arm64: dts: qcom: sm8250: Mark PCIe hosts as DMA coherent [ Upstream commit 339d38a436f30d0f874815eafc7de2257346bf26 ] The PCIe hosts on SM8250 are cache-coherent. Mark them as such. Fixes: e53bdfc00977 ("arm64: dts: qcom: sm8250: Add PCIe support") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Wed Jul 5 15:36:23 2023 +0200 arm64: dts: qcom: sm8350: Add missing LMH interrupts to cpufreq [ Upstream commit 951151c2bb548e0f6b2c40ab4c48675f5342c914 ] Add the missing interrupts that communicate the hardware-managed throttling to Linux. Fixes: ccbb3abb23a5 ("arm64: dts: qcom: sm8350: Add cpufreq node") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Wed Jul 5 15:36:22 2023 +0200 arm64: dts: qcom: sm8350: Fix CPU idle state residency times [ Upstream commit 91ce3693e2fb685f31d39605a5ad1fbd940804da ] The present values look to have been copypasted from 8150 or 8180. Fix that. Fixes: 07ddb302811e ("arm64: dts: qcom: sm8350: Add CPU topology and idle-states") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Thu Jul 6 18:35:37 2023 +0200 arm64: dts: qcom: sm8350: Use proper CPU compatibles [ Upstream commit 4390730cc12af25f7c997f477795f5f4200149c0 ] The Kryo names (once again) turned out to be fake. The CPUs report: 0x412fd050 (CA55 r2p0) (0 - 3) 0x411fd410 (CA78 r1p1) (4 - 6) 0x411fd440 (CX1 r1p1) (7) Use the compatibles that reflect that. Fixes: b7e8f433a673 ("arm64: dts: qcom: Add basic devicetree support for SM8350 SoC") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Fri Jul 7 15:30:25 2023 +0300 arm64: dts: qcom: sm8450-hdk: remove pmr735b PMIC inclusion [ Upstream commit 701b59db773730a914f1778cf2dd05e3a05c2c69 ] The 8450-HDK doesn't use PMR735B PMIC. Drop its inclusion to remove the warning during the HDK bootup. Fixes: 30464456a1ea ("arm64: dts: qcom: sm8450-hdk: add pmic files") Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Abel Vesa <[email protected]> Date: Tue Aug 1 12:52:46 2023 +0300 arm64: dts: qcom: sm8550-mtp: Add missing supply for L1B regulator [ Upstream commit 2c9e45dfeed126488aa73e7b82b3576c4c6f1036 ] Even though currently there is no consumer for L1B, add the supply for it anyway. Fixes: 71342fb91eae ("arm64: dts: qcom: Add base SM8550 MTP dts") Signed-off-by: Abel Vesa <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Fri Jul 7 08:33:35 2023 +0200 arm64: dts: rockchip: correct wifi interrupt flag in Box Demo [ Upstream commit 2d6f7e3938a7aba154c8e8afaddc8b7f1e0a1b56 ] GPIO_ACTIVE_x flags are not correct in the context of interrupt flags. These are simple defines so they could be used in DTS but they will not have the same meaning: GPIO_ACTIVE_HIGH = 0 = IRQ_TYPE_NONE. Correct the interrupt flags, assuming the author of the code wanted same logical behavior behind the name "ACTIVE_xxx", this is: ACTIVE_HIGH => IRQ_TYPE_LEVEL_HIGH Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Fri Jul 7 08:33:33 2023 +0200 arm64: dts: rockchip: correct wifi interrupt flag in eaidk-610 [ Upstream commit 8183bb7e291b7818f49ea39687c2fafa01a46e27 ] GPIO_ACTIVE_x flags are not correct in the context of interrupt flags. These are simple defines so they could be used in DTS but they will not have the same meaning: GPIO_ACTIVE_HIGH = 0 = IRQ_TYPE_NONE. Correct the interrupt flags, assuming the author of the code wanted same logical behavior behind the name "ACTIVE_xxx", this is: ACTIVE_HIGH => IRQ_TYPE_LEVEL_HIGH Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Fri Jul 7 08:33:34 2023 +0200 arm64: dts: rockchip: correct wifi interrupt flag in Rock Pi 4B [ Upstream commit cfa12c32b96fd5b12f77d880d6a1ddd2a502756e ] GPIO_ACTIVE_x flags are not correct in the context of interrupt flags. These are simple defines so they could be used in DTS but they will not have the same meaning: GPIO_ACTIVE_HIGH = 0 = IRQ_TYPE_NONE. Correct the interrupt flags, assuming the author of the code wanted same logical behavior behind the name "ACTIVE_xxx", this is: ACTIVE_HIGH => IRQ_TYPE_LEVEL_HIGH Signed-off-by: Krzysztof Kozlowski <[email protected]> Tested-by: Christopher Obbard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jonas Karlman <[email protected]> Date: Mon Jul 24 14:52:16 2023 +0000 arm64: dts: rockchip: Enable SATA on Radxa E25 [ Upstream commit 2bdfe84fbd57a4ed9fd65a67210442559ce078f0 ] The M.2 KEY B port can be used for WWAN USB2 modules or SATA drives. Enable sata1 node to fix use of SATA drives on the M.2 slot. Fixes: 2bf2f4d9f673 ("arm64: dts: rockchip: Add Radxa CM3I E25") Signed-off-by: Jonas Karlman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jonas Karlman <[email protected]> Date: Mon Jul 24 14:52:16 2023 +0000 arm64: dts: rockchip: Fix PCIe regulators on Radxa E25 [ Upstream commit a87852e37f782257ebc57cc44a0d3fbf806471f6 ] Despite its name, the regulator vcc3v3_pcie30x1 has nothing to do with pcie30x1. Instead, it supply power to VBAT1-5 on the M.2 KEY B port as seen on page 8 of the schematic [1]. pcie30x1 is used for the mini PCIe slot, and as seen on page 9 the vcc3v3_minipcie regulator is instead related to pcie30x1. The M.2 KEY B port can be used for WWAN USB2 modules or SATA drives. Use correct regulator vcc3v3_minipcie for pcie30x1. [1] https://dl.radxa.com/cm3p/e25/radxa-e25-v1.4-sch.pdf Fixes: 2bf2f4d9f673 ("arm64: dts: rockchip: Add Radxa CM3I E25") Signed-off-by: Jonas Karlman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Aradhya Bhatia <[email protected]> Date: Wed Aug 9 14:15:54 2023 +0530 arm64: dts: ti: k3-am62x-sk-common: Update main-i2c1 frequency [ Upstream commit 73387da70f9c26b6fba4f62371d013cce14663d9 ] The Display Data Channel (DDC) transactions between an HDMI transmitter (SIL9022A in this case) and an HDMI monitor, occur at a maximum of 100KHz. That's the maximum supported frequency within DDC standards. While the SIL9022A can transact with the core at 400KHz, it needs to drop the frequency to 100KHz when communicating with the monitor, otherwise, the i2c controller times out and shows warning like this. [ 985.773431] omap_i2c 20010000.i2c: controller timed out That feature, however, has not been enabled in the SIL9022 driver. Since, dropping the frequency doesn't affect any other devices on the bus, drop the main-i2c1 frequency from 400KHz to 100KHz. Fixes: a841581451af ("arm64: dts: ti: Refractor AM625 SK dts") Signed-off-by: Aradhya Bhatia <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Apelete Seketeli <[email protected]> Date: Thu Aug 10 01:16:22 2023 +0530 arm64: dts: ti: k3-j784s4: Fix interrupt ranges for wkup & main gpio [ Upstream commit 05a1f130101e7a49ff1e8734939facd43596ea26 ] This patch fixes the interrupt range for wakeup and main domain gpio interrupt routers. They were wrongly subtracted by 32 instead of following what is defined in the interrupt map in the TRM (Table 9-35). Link: http://www.ti.com/lit/pdf/spruj52 Fixes: 4664ebd8346a ("arm64: dts: ti: Add initial support for J784S4 SoC") Signed-off-by: Apelete Seketeli <[email protected]> Signed-off-by: Esteban Blanc <[email protected]> Signed-off-by: Jai Luthra <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Qi Zheng <[email protected]> Date: Thu Aug 10 09:32:41 2023 +0000 arm64: mm: use ptep_clear() instead of pte_clear() in clear_flush() [ Upstream commit 00de2c9f26b15f1a6f2af516dd8ec5f8d28189b7 ] In clear_flush(), the original pte may be a present entry, so we should use ptep_clear() to let page_table_check track the pte clearing operation, otherwise it may cause false positive in subsequent set_pte_at(). Link: https://lkml.kernel.org/r/[email protected] Fixes: 42b2547137f5 ("arm64/mm: enable ARCH_SUPPORTS_PAGE_TABLE_CHECK") Signed-off-by: Qi Zheng <[email protected]> Acked-by: Will Deacon <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Kefeng Wang <[email protected]> Cc: Muchun Song <[email protected]> Cc: Pasha Tatashin <[email protected]> Cc: Qi Zheng <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: D Scott Phillips <[email protected]> Date: Mon Jun 26 17:29:39 2023 -0700 arm64: sdei: abort running SDEI handlers during crash commit 5cd474e57368f0957c343bb21e309cf82826b1ef upstream. Interrupts are blocked in SDEI context, per the SDEI spec: "The client interrupts cannot preempt the event handler." If we crashed in the SDEI handler-running context (as with ACPI's AGDI) then we need to clean up the SDEI state before proceeding to the crash kernel so that the crash kernel can have working interrupts. Track the active SDEI handler per-cpu so that we can COMPLETE_AND_RESUME the handler, discarding the interrupted context. Fixes: f5df26961853 ("arm64: kernel: Add arch-specific SDEI entry code and CPU masking") Signed-off-by: D Scott Phillips <[email protected]> Cc: [email protected] Reviewed-by: James Morse <[email protected]> Tested-by: Mihai Carabas <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jon Hunter <[email protected]> Date: Mon Jul 3 12:36:17 2023 +0100 arm64: tegra: Fix HSUART for Jetson AGX Orin [ Upstream commit 861dbb2b15b1049113887fb95e856f7123eea0cc ] After commit 71de0a054d0e ("arm64: tegra: Drop serial clock-names and reset-names") was applied, the HSUART failed to probe and the following error is seen: serial-tegra 3100000.serial: Couldn't get the reset serial-tegra: probe of 3100000.serial failed with error -2 Commit 71de0a054d0e ("arm64: tegra: Drop serial clock-names and reset-names") is correct because the "reset-names" property is not needed for 8250 UARTs. However, the "reset-names" is required for the HSUART and should have been populated as part of commit ff578db7b693 ("arm64: tegra: Enable UART instance on 40-pin header") that enabled the HSUART for Jetson AGX Orin. Fix this by populating the "reset-names" property for the HSUART on Jetson AGX Orin. Fixes: ff578db7b693 ("arm64: tegra: Enable UART instance on 40-pin header") Signed-off-by: Jon Hunter <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Diogo Ivo <[email protected]> Date: Fri Jul 14 11:10:17 2023 +0100 arm64: tegra: Fix HSUART for Smaug [ Upstream commit 590bfe51838f6345a6a3288507661dc9b7208464 ] After commit 71de0a054d0e ("arm64: tegra: Drop serial clock-names and reset-names") was applied, the HSUART failed to probe and the following error is seen: serial-tegra 70006300.serial: Couldn't get the reset serial-tegra: probe of 70006300.serial failed with error -2 Commit 71de0a054d0e ("arm64: tegra: Drop serial clock-names and reset-names") is correct because the "reset-names" property is not needed for 8250 UARTs. However, the "reset-names" is required for the HSUART and should have been populated as part of commit a63c0cd83720c ("arm64: dts: tegra: smaug: Add Bluetooth node") that enabled the HSUART for the Pixel C. Fix this by populating the "reset-names" property for the HSUART on the Pixel C. Fixes: a63c0cd83720 ("arm64: dts: tegra: smaug: Add Bluetooth node") Signed-off-by: Diogo Ivo <[email protected]> Reviewed-by: Jon Hunter <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rob Herring <[email protected]> Date: Tue May 2 12:25:29 2023 -0500 ARM: dts: Add .dts files missing from the build [ Upstream commit 86684c2481b6e6a46c2282acee13554e34e66071 ] Comparing .dts files to built .dtb files yielded a few .dts files which are never built. Add them to the build. Signed-off-by: Rob Herring <[email protected]> Stable-dep-of: 92632115fb57 ("samples/bpf: fix bio latency check with tracepoint") Signed-off-by: Sasha Levin <[email protected]>
Author: Rafał Miłecki <[email protected]> Date: Fri Jul 7 13:40:03 2023 +0200 ARM: dts: BCM53573: Add cells sizes to PCIe node [ Upstream commit 3392ef368d9b04622fe758b1079b512664b6110a ] This fixes: arch/arm/boot/dts/broadcom/bcm47189-luxul-xap-1440.dtb: pcie@2000: '#address-cells' is a required property From schema: /lib/python3.10/site-packages/dtschema/schemas/pci/pci-bus.yaml arch/arm/boot/dts/broadcom/bcm47189-luxul-xap-1440.dtb: pcie@2000: '#size-cells' is a required property From schema: /lib/python3.10/site-packages/dtschema/schemas/pci/pci-bus.yaml Two properties that need to be added later are "device_type" and "ranges". Adding "device_type" on its own causes a new warning and the value of "ranges" needs to be determined yet. Signed-off-by: Rafał Miłecki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rafał Miłecki <[email protected]> Date: Fri Jul 7 13:40:01 2023 +0200 ARM: dts: BCM53573: Drop nonexistent "default-off" LED trigger [ Upstream commit be7e1e5b0f67c58ec4be0a54db23b6a4fa6e2116 ] There is no such trigger documented or implemented in Linux. It was a copy & paste mistake. This fixes: arch/arm/boot/dts/broadcom/bcm47189-luxul-xap-1440.dtb: leds: led-wlan:linux,default-trigger: 'oneOf' conditional failed, one must be fixed: 'default-off' is not one of ['backlight', 'default-on', 'heartbeat', 'disk-activity', 'disk-read', 'disk-write', 'timer', 'pattern', 'audio-micmute', 'audio-mute', 'bluetooth-power', 'flash', 'kbd-capslock', 'mtd', 'nand-disk', 'none', 'torch', 'usb-gadget', 'usb-host', 'usbport'] 'default-off' does not match '^cpu[0-9]*$' 'default-off' does not match '^hci[0-9]+-power$' 'default-off' does not match '^mmc[0-9]+$' 'default-off' does not match '^phy[0-9]+tx$' From schema: Documentation/devicetree/bindings/leds/leds-gpio.yaml Signed-off-by: Rafał Miłecki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rafał Miłecki <[email protected]> Date: Fri Jul 7 13:40:02 2023 +0200 ARM: dts: BCM53573: Drop nonexistent #usb-cells [ Upstream commit 05d2c3d552b8c92fc397377d9d1112fc58e2cd59 ] Such property simply doesn't exist (is not documented or used anywhere). This fixes: arch/arm/boot/dts/broadcom/bcm47189-luxul-xap-1440.dtb: usb@d000: Unevaluated properties are not allowed ('#usb-cells' was unexpected) From schema: Documentation/devicetree/bindings/usb/generic-ohci.yaml Signed-off-by: Rafał Miłecki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rafał Miłecki <[email protected]> Date: Thu Jul 13 13:11:45 2023 +0200 ARM: dts: BCM53573: Fix Ethernet info for Luxul devices [ Upstream commit 44ad8207806973f4e4f7d870fff36cc01f494250 ] Both Luxul's XAP devices (XAP-810 and XAP-1440) are access points that use a non-default design. They don't include switch but have a single Ethernet port and BCM54210E PHY connected to the Ethernet controller's MDIO bus. Support for those devices regressed due to two changes: 1. Describing MDIO bus with switch After commit 9fb90ae6cae7 ("ARM: dts: BCM53573: Describe on-SoC BCM53125 rev 4 switch") Linux stopped probing for MDIO devices. 2. Dropping hardcoded BCM54210E delays In commit fea7fda7f50a ("net: phy: broadcom: Fix RGMII delays configuration for BCM54210E") support for other PHY modes was added but that requires a proper "phy-mode" value in DT. Both above changes are correct (they don't need to be reverted or anything) but they need this fix for DT data to be correct and for Linux to work properly. Fixes: 9fb90ae6cae7 ("ARM: dts: BCM53573: Describe on-SoC BCM53125 rev 4 switch") Signed-off-by: Rafał Miłecki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rafał Miłecki <[email protected]> Date: Sun Jul 23 21:54:14 2023 +0200 ARM: dts: BCM53573: Fix Tenda AC9 switch CPU port [ Upstream commit 7141209db9c335ab261a17933809a3e660ebdc12 ] Primary Ethernet interface is connected to the port 8 (not 5). Fixes: 64612828628c ("ARM: dts: BCM53573: Add Tenda AC9 switch ports") Signed-off-by: Rafał Miłecki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rafał Miłecki <[email protected]> Date: Fri Jul 7 13:40:04 2023 +0200 ARM: dts: BCM53573: Use updated "spi-gpio" binding properties [ Upstream commit 2c0fd6b3d0778ceab40205315ccef74568490f17 ] Switch away from deprecated properties. This fixes: arch/arm/boot/dts/broadcom/bcm947189acdbmr.dtb: spi: gpio-sck: False schema does not allow [[3, 21, 0]] From schema: Documentation/devicetree/bindings/spi/spi-gpio.yaml arch/arm/boot/dts/broadcom/bcm947189acdbmr.dtb: spi: gpio-miso: False schema does not allow [[3, 22, 0]] From schema: Documentation/devicetree/bindings/spi/spi-gpio.yaml arch/arm/boot/dts/broadcom/bcm947189acdbmr.dtb: spi: gpio-mosi: False schema does not allow [[3, 23, 0]] From schema: Documentation/devicetree/bindings/spi/spi-gpio.yaml arch/arm/boot/dts/broadcom/bcm947189acdbmr.dtb: spi: 'sck-gpios' is a required property From schema: Documentation/devicetree/bindings/spi/spi-gpio.yaml arch/arm/boot/dts/broadcom/bcm947189acdbmr.dtb: spi: Unevaluated properties are not allowed ('gpio-miso', 'gpio-mosi', 'gpio-sck' were unexpected) From schema: Documentation/devicetree/bindings/spi/spi-gpio.yaml Signed-off-by: Rafał Miłecki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lin Yujun <[email protected]> Date: Fri Aug 11 09:00:06 2023 +0200 ARM: dts: integrator: fix PCI bus dtc warnings [ Upstream commit 42ff49a1967af71772b264009659ce181f7d2d2a ] An warning is reported when allmodconfig is used to compile the kernel of the ARM architecture: arch/arm/boot/dts/arm/integratorap.dts:161.22-206.4: Warning (pci_bridge): /pciv3@62000000: node name is not "pci" or "pcie" Change the node name to pci to clear the build warning. Signed-off-by: Lin Yujun <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Robert Marko <[email protected]> Date: Fri Aug 11 13:01:16 2023 +0200 ARM: dts: qcom: ipq4019: correct SDHCI XO clock [ Upstream commit b5ed7a5c1fdb3981713f7b637b72aa390c3db036 ] Using GCC_DCD_XO_CLK as the XO clock for SDHCI controller is not correct, it seems that I somehow made a mistake of passing it instead of the fixed XO clock. Fixes: 04b3b72b5b8f ("ARM: dts: qcom: ipq4019: Add SDHCI controller node") Signed-off-by: Robert Marko <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rohit Agarwal <[email protected]> Date: Mon Aug 7 19:08:51 2023 +0530 ARM: dts: qcom: sdx65-mtp: Update the pmic used in sdx65 [ Upstream commit f636d6c356b339b0d29eed025f8bf9efcb6eb274 ] Update the pmic used in sdx65 platform to pm7250b. Fixes: 26380f298b2b (ARM: dts: qcom: sdx65-mtp: Add pmk8350b and pm8150b pmic) Signed-off-by: Rohit Agarwal <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Fri Apr 21 11:57:21 2023 +0200 ARM: dts: s5pv210: add dummy 5V regulator for backlight on SMDKv210 [ Upstream commit b77904ba177a9c67b6dbc3637fdf1faa22df6e5c ] Backlight is supplied by DC5V regulator. The DTS has no PMIC node, so just add a regulator-fixed to solve it and fix dtbs_check warning: s5pv210-smdkv210.dtb: backlight: 'power-supply' is a required property Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Stable-dep-of: 982655cb0e7f ("ARM: dts: samsung: s5pv210-smdkv210: correct ethernet reg addresses (split)") Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Thu Jul 13 17:29:25 2023 +0200 ARM: dts: samsung: s3c6410-mini6410: correct ethernet reg addresses (split) [ Upstream commit cf0cb2af6a18f28b84f9f1416bff50ca60d6e98a ] The davicom,dm9000 Ethernet Controller accepts two reg addresses. Fixes: a43736deb47d ("ARM: dts: Add dts file for S3C6410-based Mini6410 board") Reviewed-by: Alim Akhtar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Thu Jul 13 17:29:26 2023 +0200 ARM: dts: samsung: s5pv210-smdkv210: correct ethernet reg addresses (split) [ Upstream commit 982655cb0e7f18934d7532c32366e574ad61dbd7 ] The davicom,dm9000 Ethernet Controller accepts two reg addresses. Fixes: b672b27d232e ("ARM: dts: Add Device tree for s5pc110/s5pv210 boards") Reviewed-by: Alim Akhtar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marek Vasut <[email protected]> Date: Tue Jul 11 15:09:07 2023 +0200 ARM: dts: stm32: Add missing detach mailbox for DHCOM SoM [ Upstream commit deb7edbc27a6ec4d8f5edfd8519b7ed13cbd2a52 ] Add missing "detach" mailbox to this board to permit the CPU to inform the remote processor on a detach. This signal allows the remote processor firmware to stop IPC communication and to reinitialize the resources for a re-attach. Without this mailbox, detach is not possible and kernel log contains the following warning to, so make sure all the STM32MP15xx platform DTs are in sync regarding the mailboxes to fix the detach issue and the warning: " stm32-rproc 10000000.m4: mbox_request_channel_byname() could not locate channel named "detach" " Fixes: 6257dfc1c412 ("ARM: dts: stm32: Add coprocessor detach mbox on stm32mp15x-dkx boards") Signed-off-by: Marek Vasut <[email protected]> Signed-off-by: Alexandre Torgue <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marek Vasut <[email protected]> Date: Tue Jul 11 15:11:21 2023 +0200 ARM: dts: stm32: Add missing detach mailbox for DHCOR SoM [ Upstream commit 2f38de940f072db369edd3e6e8d82bb8f42c5c9b ] Add missing "detach" mailbox to this board to permit the CPU to inform the remote processor on a detach. This signal allows the remote processor firmware to stop IPC communication and to reinitialize the resources for a re-attach. Without this mailbox, detach is not possible and kernel log contains the following warning to, so make sure all the STM32MP15xx platform DTs are in sync regarding the mailboxes to fix the detach issue and the warning: " stm32-rproc 10000000.m4: mbox_request_channel_byname() could not locate channel named "detach" " Fixes: 6257dfc1c412 ("ARM: dts: stm32: Add coprocessor detach mbox on stm32mp15x-dkx boards") Signed-off-by: Marek Vasut <[email protected]> Signed-off-by: Alexandre Torgue <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marek Vasut <[email protected]> Date: Thu May 18 03:12:42 2023 +0200 ARM: dts: stm32: Add missing detach mailbox for emtrion emSBC-Argon [ Upstream commit 0ee0ef38aa9f75f21b51f729dd42b2e932515188 ] Add missing "detach" mailbox to this board to permit the CPU to inform the remote processor on a detach. This signal allows the remote processor firmware to stop IPC communication and to reinitialize the resources for a re-attach. Without this mailbox, detach is not possible and kernel log contains the following warning to, so make sure all the STM32MP15xx platform DTs are in sync regarding the mailboxes to fix the detach issue and the warning: " stm32-rproc 10000000.m4: mbox_request_channel_byname() could not locate channel named "detach" " Fixes: 6257dfc1c412 ("ARM: dts: stm32: Add coprocessor detach mbox on stm32mp15x-dkx boards") Signed-off-by: Marek Vasut <[email protected]> Signed-off-by: Alexandre Torgue <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marek Vasut <[email protected]> Date: Thu May 18 03:12:43 2023 +0200 ARM: dts: stm32: Add missing detach mailbox for Odyssey SoM [ Upstream commit 966f04a89d77548e673de2c400abe0b2cf5c15db ] Add missing "detach" mailbox to this board to permit the CPU to inform the remote processor on a detach. This signal allows the remote processor firmware to stop IPC communication and to reinitialize the resources for a re-attach. Without this mailbox, detach is not possible and kernel log contains the following warning to, so make sure all the STM32MP15xx platform DTs are in sync regarding the mailboxes to fix the detach issue and the warning: " stm32-rproc 10000000.m4: mbox_request_channel_byname() could not locate channel named "detach" " Fixes: 6257dfc1c412 ("ARM: dts: stm32: Add coprocessor detach mbox on stm32mp15x-dkx boards") Signed-off-by: Marek Vasut <[email protected]> Signed-off-by: Alexandre Torgue <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Olivier Moysan <[email protected]> Date: Tue May 30 14:45:34 2023 +0200 ARM: dts: stm32: adopt generic iio bindings for adc channels on emstamp-argon [ Upstream commit c46e9b6cc98245f7264a8d15394d1f95d433abec ] Use STM32 ADC generic bindings instead of legacy bindings on emtrion GmbH Argon boards. The STM32 ADC specific binding to declare channels has been deprecated, hence adopt the generic IIO channels bindings, instead. The STM32MP151 device tree now exposes internal channels using the generic binding. This makes the change mandatory here to avoid a mixed use of legacy and generic binding, which is not supported by the driver. Signed-off-by: Olivier Moysan <[email protected]> Signed-off-by: Alexandre Torgue <[email protected]> Stable-dep-of: 0ee0ef38aa9f ("ARM: dts: stm32: Add missing detach mailbox for emtrion emSBC-Argon") Signed-off-by: Sasha Levin <[email protected]>
Author: Marek Vasut <[email protected]> Date: Tue May 30 14:45:37 2023 +0200 ARM: dts: stm32: Update to generic ADC channel binding on DHSOM systems [ Upstream commit 9bcfc3cdc903485a52c6f471f4ae96a41fa51803 ] The generic ADC channel binding is recommended over legacy one, update the DT to the modern binding. No functional change. For further details, see commit which adds the generic binding to STM32 ADC binding document: '664b9879f56e ("dt-bindings: iio: stm32-adc: add generic channel binding")' Signed-off-by: Marek Vasut <[email protected]> Signed-off-by: Alexandre Torgue <[email protected]> Stable-dep-of: deb7edbc27a6 ("ARM: dts: stm32: Add missing detach mailbox for DHCOM SoM") Signed-off-by: Sasha Levin <[email protected]>
Author: Gustavo A. R. Silva <[email protected]> Date: Wed Jun 7 22:12:11 2023 -0600 ARM: OMAP2+: Fix -Warray-bounds warning in _pwrdm_state_switch() commit 847fb80cc01a54bc827b02547bb8743bdb59ddab upstream. If function pwrdm_read_prev_pwrst() returns -EINVAL, we will end up accessing array pwrdm->state_counter through negative index -22. This is wrong and the compiler is legitimately warning us about this potential problem. Fix this by sanity checking the value stored in variable _prev_ before accessing array pwrdm->state_counter. Address the following -Warray-bounds warning: arch/arm/mach-omap2/powerdomain.c:178:45: warning: array subscript -22 is below array bounds of 'unsigned int[4]' [-Warray-bounds] Link: https://github.com/KSPP/linux/issues/307 Fixes: ba20bb126940 ("OMAP: PM counter infrastructure.") Cc: [email protected] Reported-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/lkml/20230607050639.LzbPn%[email protected]/ Signed-off-by: Gustavo A. R. Silva <[email protected]> Message-ID: <ZIFVGwImU3kpaGeH@work> Acked-by: Ard Biesheuvel <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kees Cook <[email protected]> Date: Thu Aug 10 12:54:18 2023 -0700 ARM: ptrace: Restore syscall restart tracing [ Upstream commit cf007647475b5090819c5fe8da771073145c7334 ] Since commit 4e57a4ddf6b0 ("ARM: 9107/1: syscall: always store thread_info->abi_syscall"), the seccomp selftests "syscall_restart" has been broken. This was caused by the restart syscall not being stored to "abi_syscall" during restart setup before branching to the "local_restart" label. Tracers would see the wrong syscall, and scno would get overwritten while returning from the TIF_WORK path. Add the missing store. Cc: Russell King <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Lecopzer Chen <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: [email protected] Fixes: 4e57a4ddf6b0 ("ARM: 9107/1: syscall: always store thread_info->abi_syscall") Reviewed-by: Arnd Bergmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kees Cook <[email protected]> Date: Thu Aug 10 12:54:19 2023 -0700 ARM: ptrace: Restore syscall skipping for tracers [ Upstream commit 4697b5848bd933f68ebd04836362c8de0cacaf71 ] Since commit 4e57a4ddf6b0 ("ARM: 9107/1: syscall: always store thread_info->abi_syscall"), the seccomp selftests "syscall_errno" and "syscall_faked" have been broken. Both seccomp and PTRACE depend on using the special value of "-1" for skipping syscalls. This value wasn't working because it was getting masked by __NR_SYSCALL_MASK in both PTRACE_SET_SYSCALL and get_syscall_nr(). Explicitly test for -1 in PTRACE_SET_SYSCALL and get_syscall_nr(), leaving it exposed when present, allowing tracers to skip syscalls again. Cc: Russell King <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Lecopzer Chen <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: [email protected] Fixes: 4e57a4ddf6b0 ("ARM: 9107/1: syscall: always store thread_info->abi_syscall") Reviewed-by: Arnd Bergmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kees Cook <keescoo[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Guiting Shen <[email protected]> Date: Sat Jul 15 11:06:20 2023 +0800 ASoC: atmel: Fix the 8K sample parameter in I2SC master [ Upstream commit f85739c0b2b0d98a32f5ca4fcc5501d2b76df4f6 ] The 8K sample parameter of 12.288Mhz main system bus clock doesn't work because the I2SC_MR.IMCKDIV must not be 0 according to the sama5d2 series datasheet(I2SC Mode Register of Register Summary). So use the 6.144Mhz instead of 12.288Mhz to support 8K sample. Signed-off-by: Guiting Shen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Edgar <[email protected]> Date: Wed Jul 19 13:47:22 2023 +0800 ASoc: codecs: ES8316: Fix DMIC config [ Upstream commit d20d35d1ad62c6cca36368c1e8f29335a068659e ] According to the datasheet, the DMIC config should be changed to { 0, 2 ,3 } Signed-off-by: Edgar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Simon Trimmer <[email protected]> Date: Thu Aug 17 12:27:12 2023 +0100 ASoC: cs35l56: Add an ACPI match table [ Upstream commit e8500a70270334b9abad72fea504ef38a2952274 ] An ACPI ID has been allocated for CS35L56 ASoC devices so that they can be instantiated from ACPI Device entries. Signed-off-by: Simon Trimmer <[email protected]> Signed-off-by: Richard Fitzgerald <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Phil Elwell <[email protected]> Date: Wed Jun 21 16:32:29 2023 +0100 ASoC: cs43130: Fix numerator/denominator mixup [ Upstream commit a9e7c964cea4fb1541cc81a11d1b2fd135f4cf38 ] In converting to using the standard u16_fract type, commit [1] made the obvious mistake and failed to take account of the difference in numerator and denominator ordering, breaking all uses of the cs43130 codec. Fix it. [1] commit e14bd35ef446 ("ASoC: cs43130: Re-use generic struct u16_fract") Fixes: e14bd35ef446 ("ASoC: cs43130: Re-use generic struct u16_fract") Signed-off-by: Phil Elwell <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Acked-by: Charles Keepax <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmytro Maluka <[email protected]> Date: Mon Jul 17 21:37:37 2023 +0200 ASoC: da7219: Check for failure reading AAD IRQ events [ Upstream commit f0691dc16206f21b13c464434366e2cd632b8ed7 ] When handling an AAD interrupt, if IRQ events read failed (for example, due to i2c "Transfer while suspended" failure, i.e. when attempting to read it while DA7219 is suspended, which may happen due to a spurious AAD interrupt), the events array contains garbage uninitialized values. So instead of trying to interprete those values and doing any actions based on them (potentially resulting in misbehavior, e.g. reporting bogus events), refuse to handle the interrupt. Signed-off-by: Dmytro Maluka <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmytro Maluka <[email protected]> Date: Mon Jul 17 21:37:36 2023 +0200 ASoC: da7219: Flush pending AAD IRQ when suspending [ Upstream commit 91e292917dad64ab8d1d5ca2ab3069ad9dac6f72 ] da7219_aad_suspend() disables jack detection, which should prevent generating new interrupts by DA7219 while suspended. However, there is a theoretical possibility that there is a pending interrupt generated just before suspending DA7219 and not handled yet, so the IRQ handler may still run after DA7219 is suspended. To prevent that, wait until the pending IRQ handling is done. This patch arose as an attempt to fix the following I2C failure occurring sometimes during system suspend or resume: [ 355.876211] i2c_designware i2c_designware.3: Transfer while suspended [ 355.876245] WARNING: CPU: 2 PID: 3576 at drivers/i2c/busses/i2c-designware-master.c:570 i2c_dw_xfer+0x411/0x440 ... [ 355.876462] Call Trace: [ 355.876468] <TASK> [ 355.876475] ? update_load_avg+0x1b3/0x615 [ 355.876484] __i2c_transfer+0x101/0x1d8 [ 355.876494] i2c_transfer+0x74/0x10d [ 355.876504] regmap_i2c_read+0x6a/0x9c [ 355.876513] _regmap_raw_read+0x179/0x223 [ 355.876521] regmap_raw_read+0x1e1/0x28e [ 355.876527] regmap_bulk_read+0x17d/0x1ba [ 355.876532] ? __wake_up+0xed/0x1bb [ 355.876542] da7219_aad_irq_thread+0x54/0x2c9 [snd_soc_da7219 5fb8ebb2179cf2fea29af090f3145d68ed8e2184] [ 355.876556] irq_thread+0x13c/0x231 [ 355.876563] ? irq_forced_thread_fn+0x5f/0x5f [ 355.876570] ? irq_thread_fn+0x4d/0x4d [ 355.876576] kthread+0x13a/0x152 [ 355.876581] ? synchronize_irq+0xc3/0xc3 [ 355.876587] ? kthread_blkcg+0x31/0x31 [ 355.876592] ret_from_fork+0x1f/0x30 [ 355.876601] </TASK> which indicates that the AAD IRQ handler is unexpectedly running when DA7219 is suspended, and as a result, is trying to read data from DA7219 over I2C and is hitting the I2C driver "Transfer while suspended" failure. However, with this patch the above failure is still reproducible. So this patch does not fix any real observed issue so far, but at least is useful for confirming that the above issue is not caused by a pending IRQ but rather looks like a DA7219 hardware issue with an IRQ unexpectedly generated after jack detection is already disabled. Signed-off-by: Dmytro Maluka <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Herve Codina <[email protected]> Date: Wed Jul 26 18:16:20 2023 +0200 ASoC: fsl: fsl_qmc_audio: Fix snd_pcm_format_t values handling [ Upstream commit 5befe22b3eebd07b334b2917f6d14ce7ee4c8404 ] Running sparse on fsl_qmc_audio (make C=1) raises the following warnings: fsl_qmc_audio.c:387:26: warning: restricted snd_pcm_format_t degrades to integer fsl_qmc_audio.c:389:59: warning: incorrect type in argument 1 (different base types) fsl_qmc_audio.c:389:59: expected restricted snd_pcm_format_t [usertype] format fsl_qmc_audio.c:389:59: got unsigned int [assigned] i fsl_qmc_audio.c:564:26: warning: restricted snd_pcm_format_t degrades to integer fsl_qmc_audio.c:569:50: warning: incorrect type in argument 1 (different base types) fsl_qmc_audio.c:569:50: expected restricted snd_pcm_format_t [usertype] format fsl_qmc_audio.c:569:50: got int [assigned] i fsl_qmc_audio.c:573:62: warning: incorrect type in argument 1 (different base types) fsl_qmc_audio.c:573:62: expected restricted snd_pcm_format_t [usertype] format fsl_qmc_audio.c:573:62: got int [assigned] i These warnings are due to snd_pcm_format_t values handling done in the driver. Some macros and functions exist to handle safely these values. Use dedicated macros and functions to remove these warnings. Fixes: 075c7125b11c ("ASoC: fsl: Add support for QMC audio") Signed-off-by: Herve Codina <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Edson Juliano Drosdeck <[email protected]> Date: Wed Jul 19 17:02:41 2023 -0300 ASoC: nau8821: Add DMI quirk mechanism for active-high jack-detect [ Upstream commit 1bc40efdaf4a0ccfdb10a1c8e4b458f4764e8e5f ] Add a quirk mechanism to allow specifying that active-high jack-detection should be used on platforms where this info is not available in devicetree. And add an entry for the Positivo CW14Q01P-V2 to the DMI table, so that jack-detection will work properly on this laptop. Signed-off-by: Edson Juliano Drosdeck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shuming Fan <[email protected]> Date: Fri Aug 11 17:38:22 2023 +0800 ASoC: rt1308-sdw: fix random louder sound [ Upstream commit 37aba3190891d4de189bd5192ee95220e295f34d ] This patch uses a vendor register to check whether the system hibernated ever. The driver will only set the preset when the driver brings up or the system hibernated. It will avoid the unknown issue that makes the speaker output louder and can't control the volume. Signed-off-by: Shuming Fan <[email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Shuming Fan <[email protected]> Date: Fri Jul 21 17:06:43 2023 +0800 ASoC: rt5682-sdw: fix for JD event handling in ClockStop Mode0 [ Upstream commit 02fb23d72720df2b6be3f29fc5787ca018eb92c3 ] When the system suspends, peripheral Imp-defined interrupt is disabled. When system level resume is invoked, the peripheral Imp-defined interrupts should be enabled to handle JD events. Signed-off-by: Shuming Fan <[email protected]> Reported-by: Vijendar Mukunda <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shuming Fan <[email protected]> Date: Fri Jul 21 17:07:11 2023 +0800 ASoC: rt711-sdca: fix for JD event handling in ClockStop Mode0 [ Upstream commit 23adeb7056acd4fd866969f4afb91441776cc4f5 ] When the system suspends, peripheral SDCA interrupts are disabled. When system level resume is invoked, the peripheral SDCA interrupts should be enabled to handle JD events. Enable SDCA interrupts in resume sequence when ClockStop Mode0 is applied. Signed-off-by: Shuming Fan <[email protected]> Reported-by: Vijendar Mukunda <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shuming Fan <[email protected]> Date: Fri Jul 21 17:06:54 2023 +0800 ASoC: rt711: fix for JD event handling in ClockStop Mode0 [ Upstream commit b69de265bd0e877015a00fbba453ef72af162e0f ] When the system suspends, peripheral Imp-defined interrupt is disabled. When system level resume is invoked, the peripheral Imp-defined interrupts should be enabled to handle JD events. Signed-off-by: Shuming Fan <[email protected]> Reported-by: Vijendar Mukunda <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shuming Fan <[email protected]> Date: Fri Jul 21 17:07:21 2023 +0800 ASoC: rt712-sdca: fix for JD event handling in ClockStop Mode0 [ Upstream commit 7a8735c1551e489351172d0da96128f6f8b52b2d ] When the system suspends, peripheral SDCA interrupts are disabled. When system level resume is invoked, the peripheral SDCA interrupts should be enabled to handle JD events. Enable SDCA interrupts in resume sequence when ClockStop Mode0 is applied. Signed-off-by: Shuming Fan <[email protected]> Reported-by: Vijendar Mukunda <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: yixuanjiang <[email protected]> Date: Mon Jun 19 11:31:27 2023 +0800 ASoC: soc-compress: Fix deadlock in soc_compr_open_fe [ Upstream commit 2222214749a9969e09454b9ba7febfdfb09c1c8d ] Modify the error handling flow by release lock. The require mutex will keep holding if open fail. Fixes: aa9ff6a4955f ("ASoC: soc-compress: Reposition and add pcm_mutex") Signed-off-by: yixuanjiang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vijendar Mukunda <[email protected]> Date: Wed Aug 23 13:03:39 2023 +0530 ASoC: SOF: amd: clear dsp to host interrupt status [ Upstream commit 38592ae6dc9f84b7a994c43de2136b8115ca30f6 ] DSP_SW_INTR_STAT_OFFSET is a common interrupt register which will be accessed by both ACP firmware and driver. This register contains register bits corresponds to host to dsp interrupts and vice versa. when dsp to host interrupt is reported, only clear dsp to host interrupt bit in DSP_SW_INTR_STAT_OFFSET. Fixes: 2e7c6652f9b8 ("ASoC: SOF: amd: Fix for handling spurious interrupts from DSP") Signed-off-by: Vijendar Mukunda <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pierre-Louis Bossart <[email protected]> Date: Mon Aug 7 16:09:41 2023 -0500 ASoC: SOF: Intel: fix u16/32 confusion in LSDIID [ Upstream commit 7a52d7062e02af4a479da24b40cfd76b54c0cd6c ] Likely a combination of copy-paste and test coverage problem. Oops. Fixes: 87a6ddc0cf1c ("ASoC: SOF: Intel: hda-mlink: program SoundWire LSDIID registers") Signed-off-by: Pierre-Louis Bossart <[email protected]> Reviewed-by: Bard Liao <[email protected]> Reviewed-by: Rander Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pierre-Louis Bossart <[email protected]> Date: Mon Aug 7 16:09:40 2023 -0500 ASoC: SOF: Intel: hda-mlink: fix off-by-one error [ Upstream commit 7075b0c91b3cd5d32b4ac7403f771a3253d3fbf6 ] The HCHAN parameter should be the highest channel number, not the channel count. While we're at it, handle LCHAN with the dual __ffs helper. Fixes: ccc2f0c1b6b6 ("ASoC: SOF: Intel: hda-mlink: add helper to program SoundWire PCMSyCM registers") Signed-off-by: Pierre-Louis Bossart <[email protected]> Reviewed-by: Bard Liao <[email protected]> Reviewed-by: Rander Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Randy Dunlap <[email protected]> Date: Fri Jun 30 21:48:36 2023 -0700 ASoC: stac9766: fix build errors with REGMAP_AC97 [ Upstream commit c70064b96f509daa78f57992aeabcf274fb2fed4 ] Select REGMAP_AC97 to fix these build errors: ERROR: modpost: "regmap_ac97_default_volatile" [sound/soc/codecs/snd-soc-stac9766.ko] undefined! ERROR: modpost: "__regmap_init_ac97" [sound/soc/codecs/snd-soc-stac9766.ko] undefined! Fixes: 6bbf787bb70c ("ASoC: stac9766: Convert to regmap") Signed-off-by: Randy Dunlap <[email protected]> Cc: Lars-Peter Clausen <[email protected]> Cc: Mark Brown <[email protected]> Cc: Liam Girdwood <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Minjie Du <[email protected]> Date: Tue Jul 25 11:06:25 2023 +0800 ata: pata_arasan_cf: Use dev_err_probe() instead dev_err() in data_xfer() [ Upstream commit 4139f992c49356391fb086c0c8ce51f66c26d623 ] It is possible for dma_request_chan() to return EPROBE_DEFER, which means acdev->host->dev is not ready yet. At this point dev_err() will have no output. Use dev_err_probe() instead. Signed-off-by: Minjie Du <[email protected]> Acked-by: Viresh Kumar <[email protected]> Reviewed-by: Sergey Shtylyov <[email protected]> Signed-off-by: Damien Le Moal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gaosheng Cui <[email protected]> Date: Tue Aug 8 20:14:35 2023 +0800 audit: fix possible soft lockup in __audit_inode_child() [ Upstream commit b59bc6e37237e37eadf50cd5de369e913f524463 ] Tracefs or debugfs maybe cause hundreds to thousands of PATH records, too many PATH records maybe cause soft lockup. For example: 1. CONFIG_KASAN=y && CONFIG_PREEMPTION=n 2. auditctl -a exit,always -S open -k key 3. sysctl -w kernel.watchdog_thresh=5 4. mkdir /sys/kernel/debug/tracing/instances/test There may be a soft lockup as follows: watchdog: BUG: soft lockup - CPU#45 stuck for 7s! [mkdir:15498] Kernel panic - not syncing: softlockup: hung tasks Call trace: dump_backtrace+0x0/0x30c show_stack+0x20/0x30 dump_stack+0x11c/0x174 panic+0x27c/0x494 watchdog_timer_fn+0x2bc/0x390 __run_hrtimer+0x148/0x4fc __hrtimer_run_queues+0x154/0x210 hrtimer_interrupt+0x2c4/0x760 arch_timer_handler_phys+0x48/0x60 handle_percpu_devid_irq+0xe0/0x340 __handle_domain_irq+0xbc/0x130 gic_handle_irq+0x78/0x460 el1_irq+0xb8/0x140 __audit_inode_child+0x240/0x7bc tracefs_create_file+0x1b8/0x2a0 trace_create_file+0x18/0x50 event_create_dir+0x204/0x30c __trace_add_new_event+0xac/0x100 event_trace_add_tracer+0xa0/0x130 trace_array_create_dir+0x60/0x140 trace_array_create+0x1e0/0x370 instance_mkdir+0x90/0xd0 tracefs_syscall_mkdir+0x68/0xa0 vfs_mkdir+0x21c/0x34c do_mkdirat+0x1b4/0x1d4 __arm64_sys_mkdirat+0x4c/0x60 el0_svc_common.constprop.0+0xa8/0x240 do_el0_svc+0x8c/0xc0 el0_svc+0x20/0x30 el0_sync_handler+0xb0/0xb4 el0_sync+0x160/0x180 Therefore, we add cond_resched() to __audit_inode_child() to fix it. Fixes: 5195d8e217a7 ("audit: dynamically allocate audit_names when not enough space is in the names array") Signed-off-by: Gaosheng Cui <[email protected]> Signed-off-by: Paul Moore <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Zimmermann <[email protected]> Date: Tue Jun 13 13:06:36 2023 +0200 backlight/bd6107: Compare against struct fb_info.device commit 992bdddaabfba19bdc77c1c7a4977b2aa41ec891 upstream. Struct bd6107_platform_data refers to a platform device within the Linux device hierarchy. The test in bd6107_backlight_check_fb() compares it against the fbdev device in struct fb_info.dev, which is different. Fix the test by comparing to struct fb_info.device. Fixes a bug in the backlight driver and prepares fbdev for making struct fb_info.dev optional. v2: * move renames into separate patch (Javier, Sam, Michael) Fixes: 67b43e590415 ("backlight: Add ROHM BD6107 backlight driver") Signed-off-by: Thomas Zimmermann <[email protected]> Cc: Laurent Pinchart <[email protected]> Cc: Lee Jones <[email protected]> Cc: Daniel Thompson <[email protected]> Cc: Jingoo Han <[email protected]> Cc: [email protected] Cc: <[email protected]> # v3.12+ Reviewed-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Reviewed-by: Daniel Thompson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Zimmermann <[email protected]> Date: Tue Jun 13 13:06:38 2023 +0200 backlight/gpio_backlight: Compare against struct fb_info.device commit 7b91d017f77c1bda56f27c2f4bbb70de7c6eca08 upstream. Struct gpio_backlight_platform_data refers to a platform device within the Linux device hierarchy. The test in gpio_backlight_check_fb() compares it against the fbdev device in struct fb_info.dev, which is different. Fix the test by comparing to struct fb_info.device. Fixes a bug in the backlight driver and prepares fbdev for making struct fb_info.dev optional. v2: * move renames into separate patch (Javier, Sam, Michael) Signed-off-by: Thomas Zimmermann <[email protected]> Fixes: 8b770e3c9824 ("backlight: Add GPIO-based backlight driver") Cc: Laurent Pinchart <[email protected]> Cc: Rich Felker <[email protected]> Cc: John Paul Adrian Glaubitz <[email protected]> Cc: Lee Jones <[email protected]> Cc: Daniel Thompson <[email protected]> Cc: Jingoo Han <[email protected]> Cc: [email protected] Cc: [email protected] Cc: <[email protected]> # v3.12+ Reviewed-by: Sam Ravnborg <[email protected]> Reviewed-by: Daniel Thompson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Zimmermann <[email protected]> Date: Tue Jun 13 13:06:40 2023 +0200 backlight/lv5207lp: Compare against struct fb_info.device commit 1ca8819320fd84e7d95b04e7668efc5f9fe9fa5c upstream. Struct lv5207lp_platform_data refers to a platform device within the Linux device hierarchy. The test in lv5207lp_backlight_check_fb() compares it against the fbdev device in struct fb_info.dev, which is different. Fix the test by comparing to struct fb_info.device. Fixes a bug in the backlight driver and prepares fbdev for making struct fb_info.dev optional. v2: * move renames into separate patch (Javier, Sam, Michael) Fixes: 82e5c40d88f9 ("backlight: Add Sanyo LV5207LP backlight driver") Signed-off-by: Thomas Zimmermann <[email protected]> Cc: Laurent Pinchart <[email protected]> Cc: Yoshinori Sato <[email protected]> Cc: Rich Felker <[email protected]> Cc: John Paul Adrian Glaubitz <[email protected]> Cc: Lee Jones <[email protected]> Cc: Daniel Thompson <[email protected]> Cc: Jingoo Han <[email protected]> Cc: [email protected] Cc: [email protected] Cc: <[email protected]> # v3.12+ Reviewed-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Reviewed-by: Daniel Thompson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tejun Heo <[email protected]> Date: Wed Aug 16 09:56:23 2023 -1000 blk-cgroup: Fix NULL deref caused by blkg_policy_data being installed before init [ Upstream commit ec14a87ee1999b19d8b7ed0fa95fea80644624ae ] blk-iocost sometimes causes the following crash: BUG: kernel NULL pointer dereference, address: 00000000000000e0 ... RIP: 0010:_raw_spin_lock+0x17/0x30 Code: be 01 02 00 00 e8 79 38 39 ff 31 d2 89 d0 5d c3 0f 1f 00 0f 1f 44 00 00 55 48 89 e5 65 ff 05 48 d0 34 7e b9 01 00 00 00 31 c0 <f0> 0f b1 0f 75 02 5d c3 89 c6 e8 ea 04 00 00 5d c3 0f 1f 84 00 00 RSP: 0018:ffffc900023b3d40 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 00000000000000e0 RCX: 0000000000000001 RDX: ffffc900023b3d20 RSI: ffffc900023b3cf0 RDI: 00000000000000e0 RBP: ffffc900023b3d40 R08: ffffc900023b3c10 R09: 0000000000000003 R10: 0000000000000064 R11: 000000000000000a R12: ffff888102337000 R13: fffffffffffffff2 R14: ffff88810af408c8 R15: ffff8881070c3600 FS: 00007faaaf364fc0(0000) GS:ffff88842fdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000e0 CR3: 00000001097b1000 CR4: 0000000000350ea0 Call Trace: <TASK> ioc_weight_write+0x13d/0x410 cgroup_file_write+0x7a/0x130 kernfs_fop_write_iter+0xf5/0x170 vfs_write+0x298/0x370 ksys_write+0x5f/0xb0 __x64_sys_write+0x1b/0x20 do_syscall_64+0x3d/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 This happens because iocg->ioc is NULL. The field is initialized by ioc_pd_init() and never cleared. The NULL deref is caused by blkcg_activate_policy() installing blkg_policy_data before initializing it. blkcg_activate_policy() was doing the following: 1. Allocate pd's for all existing blkg's and install them in blkg->pd[]. 2. Initialize all pd's. 3. Online all pd's. blkcg_activate_policy() only grabs the queue_lock and may release and re-acquire the lock as allocation may need to sleep. ioc_weight_write() grabs blkcg->lock and iterates all its blkg's. The two can race and if ioc_weight_write() runs during #1 or between #1 and #2, it can encounter a pd which is not initialized yet, leading to crash. The crash can be reproduced with the following script: #!/bin/bash echo +io > /sys/fs/cgroup/cgroup.subtree_control systemd-run --unit touch-sda --scope dd if=/dev/sda of=/dev/null bs=1M count=1 iflag=direct echo 100 > /sys/fs/cgroup/system.slice/io.weight bash -c "echo '8:0 enable=1' > /sys/fs/cgroup/io.cost.qos" & sleep .2 echo 100 > /sys/fs/cgroup/system.slice/io.weight with the following patch applied: > diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c > index fc49be622e05..38d671d5e10c 100644 > --- a/block/blk-cgroup.c > +++ b/block/blk-cgroup.c > @@ -1553,6 +1553,12 @@ int blkcg_activate_policy(struct gendisk *disk, const struct blkcg_policy *pol) > pd->online = false; > } > > + if (system_state == SYSTEM_RUNNING) { > + spin_unlock_irq(&q->queue_lock); > + ssleep(1); > + spin_lock_irq(&q->queue_lock); > + } > + > /* all allocated, init in the same order */ > if (pol->pd_init_fn) > list_for_each_entry_reverse(blkg, &q->blkg_list, q_node) I don't see a reason why all pd's should be allocated, initialized and onlined together. The only ordering requirement is that parent blkgs to be initialized and onlined before children, which is guaranteed from the walking order. Let's fix the bug by allocating, initializing and onlining pd for each blkg and holding blkcg->lock over initialization and onlining. This ensures that an installed blkg is always fully initialized and onlined removing the the race window. Signed-off-by: Tejun Heo <[email protected]> Reported-by: Breno Leitao <[email protected]> Fixes: 9d179b865449 ("blkcg: Fix multiple bugs in blkcg_activate_policy()") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhiguo Niu <[email protected]> Date: Thu Aug 3 19:12:42 2023 +0800 block/mq-deadline: use correct way to throttling write requests [ Upstream commit d47f9717e5cfd0dd8c0ba2ecfa47c38d140f1bb6 ] The original formula was inaccurate: dd->async_depth = max(1UL, 3 * q->nr_requests / 4); For write requests, when we assign a tags from sched_tags, data->shallow_depth will be passed to sbitmap_find_bit, see the following code: nr = sbitmap_find_bit_in_word(&sb->map[index], min_t (unsigned int, __map_depth(sb, index), depth), alloc_hint, wrap); The smaller of data->shallow_depth and __map_depth(sb, index) will be used as the maximum range when allocating bits. For a mmc device (one hw queue, deadline I/O scheduler): q->nr_requests = sched_tags = 128, so according to the previous calculation method, dd->async_depth = data->shallow_depth = 96, and the platform is 64bits with 8 cpus, sched_tags.bitmap_tags.sb.shift=5, sb.maps[]=32/32/32/32, 32 is smaller than 96, whether it is a read or a write I/O, tags can be allocated to the maximum range each time, which has not throttling effect. In addition, refer to the methods of bfg/kyber I/O scheduler, limit ratiois are calculated base on sched_tags.bitmap_tags.sb.shift. This patch can throttle write requests really. Fixes: 07757588e507 ("block/mq-deadline: Reserve 25% of scheduler tags for synchronous requests") Signed-off-by: Zhiguo Niu <[email protected]> Reviewed-by: Bart Van Assche <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christoph Hellwig <[email protected]> Date: Fri Jul 7 11:42:38 2023 +0200 block: cleanup queue_wc_store [ Upstream commit c4e21bcd0f9d01f9c5d6c52007f5541871a5b1de ] Get rid of the local queue_wc_store variable and handling setting and clearing the QUEUE_FLAG_WC flag diretly instead the if / else if. Signed-off-by: Christoph Hellwig <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Stable-dep-of: 43c9835b144c ("block: don't allow enabling a cache on devices that don't support it") Signed-off-by: Sasha Levin <[email protected]>
Author: Li Lingfeng <[email protected]> Date: Thu Aug 31 15:59:00 2023 +0800 block: don't add or resize partition on the disk with GENHD_FL_NO_PART commit 1a721de8489fa559ff4471f73c58bb74ac5580d3 upstream. Commit a33df75c6328 ("block: use an xarray for disk->part_tbl") remove disk_expand_part_tbl() in add_partition(), which means all kinds of devices will support extended dynamic `dev_t`. However, some devices with GENHD_FL_NO_PART are not expected to add or resize partition. Fix this by adding check of GENHD_FL_NO_PART before add or resize partition. Fixes: a33df75c6328 ("block: use an xarray for disk->part_tbl") Signed-off-by: Li Lingfeng <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christoph Hellwig <[email protected]> Date: Fri Jul 7 11:42:39 2023 +0200 block: don't allow enabling a cache on devices that don't support it [ Upstream commit 43c9835b144c7ce29efe142d662529662a9eb376 ] Currently the write_cache attribute allows enabling the QUEUE_FLAG_WC flag on devices that never claimed the capability. Fix that by adding a QUEUE_FLAG_HW_WC flag that is set by blk_queue_write_cache and guards re-enabling the cache through sysfs. Note that any rescan that calls blk_queue_write_cache will still re-enable the write cache as in the current code. Fixes: 93e9d8e836cb ("block: add ability to flag write back caching on a device") Signed-off-by: Christoph Hellwig <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Max Chou <[email protected]> Date: Mon Aug 7 19:42:59 2023 +0800 Bluetooth: btrtl: Load FW v2 otherwise FW v1 for RTL8852C commit bd003fb338afee97c76f13c3e9144a7e4ad37179 upstream. In this commit, prefer to load FW v2 if available. Fallback to FW v1 otherwise. This behavior is only for RTL8852C. Fixes: 9a24ce5e29b1 ("Bluetooth: btrtl: Firmware format v2 support") Cc: [email protected] Suggested-by: Juerg Haefliger <[email protected]> Tested-by: Hilda Wu <[email protected]> Signed-off-by: Max Chou <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> [juergh: Adjusted context due to missing .hw_info struct element] Signed-off-by: Juerg Haefliger <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jinjie Ruan <[email protected]> Date: Wed Aug 23 11:46:37 2023 +0800 Bluetooth: btusb: Do not call kfree_skb() under spin_lock_irqsave() [ Upstream commit 2a05334d7f91ff189692089c05fc48cc1d8204de ] It is not allowed to call kfree_skb() from hardware interrupt context or with hardware interrupts being disabled. So replace kfree_skb() with dev_kfree_skb_irq() under spin_lock_irqsave(). Compile tested only. Fixes: baac6276c0a9 ("Bluetooth: btusb: handle mSBC audio over USB Endpoints") Signed-off-by: Jinjie Ruan <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Min Li <[email protected]> Date: Mon Aug 7 19:07:41 2023 +0800 Bluetooth: Fix potential use-after-free when clear keys [ Upstream commit 3673952cf0c6cf81b06c66a0b788abeeb02ff3ae ] Similar to commit c5d2b6fa26b5 ("Bluetooth: Fix use-after-free in hci_remove_ltk/hci_remove_irk"). We can not access k after kfree_rcu() call. Fixes: d7d41682efc2 ("Bluetooth: Fix Suspicious RCU usage warnings") Signed-off-by: Min Li <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luiz Augusto von Dentz <[email protected]> Date: Tue Aug 22 12:02:03 2023 -0700 Bluetooth: HCI: Introduce HCI_QUIRK_BROKEN_LE_CODED [ Upstream commit 253f3399f4c09ce6f4e67350f839be0361b4d5ff ] This introduces HCI_QUIRK_BROKEN_LE_CODED which is used to indicate that LE Coded PHY shall not be used, it is then set for some Intel models that claim to support it but when used causes many problems. Cc: [email protected] # 6.4.y+ Link: https://github.com/bluez/bluez/issues/577 Link: https://github.com/bluez/bluez/issues/582 Link: https://lore.kernel.org/linux-bluetooth/CABBYNZKco-v7wkjHHexxQbgwwSz-S=GZ=dZKbRE1qxT1h4fFbQ@mail.gmail.com/T/# Fixes: 288c90224eec ("Bluetooth: Enable all supported LE PHY by default") Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luiz Augusto von Dentz <[email protected]> Date: Wed Jun 28 12:15:53 2023 -0700 Bluetooth: hci_conn: Always allocate unique handles [ Upstream commit 9f78191cc9f1b34c2e2afd7b554a83bf034092dd ] This attempts to always allocate a unique handle for connections so they can be properly aborted by the likes of hci_abort_conn, so this uses the invalid range as a pool of unset handles that way if userspace is trying to create multiple connections at once each will be given a unique handle which will be considered unset. Signed-off-by: Luiz Augusto von Dentz <[email protected]> Stable-dep-of: 66dee21524d9 ("Bluetooth: hci_event: drop only unbound CIS if Set CIG Parameters fails") Signed-off-by: Sasha Levin <[email protected]>
Author: Luiz Augusto von Dentz <[email protected]> Date: Mon Jun 26 17:25:06 2023 -0700 Bluetooth: hci_conn: Consolidate code for aborting connections [ Upstream commit a13f316e90fdb1fb6df6582e845aa9b3270f3581 ] This consolidates code for aborting connections using hci_cmd_sync_queue so it is synchronized with other threads, but because of the fact that some commands may block the cmd_sync_queue while waiting specific events this attempt to cancel those requests by using hci_cmd_sync_cancel. Signed-off-by: Luiz Augusto von Dentz <[email protected]> Stable-dep-of: 94d9ba9f9888 ("Bluetooth: hci_sync: Fix UAF in hci_disconnect_all_sync") Signed-off-by: Sasha Levin <[email protected]>
Author: Pauli Virtanen <[email protected]> Date: Sat Aug 19 16:33:36 2023 +0300 Bluetooth: hci_conn: fail SCO/ISO via hci_conn_failed if ACL gone early [ Upstream commit 3344d318337d9dca928fd448e966557ec5063f85 ] Not calling hci_(dis)connect_cfm before deleting conn referred to by a socket generally results to use-after-free. When cleaning up SCO connections when the parent ACL is deleted too early, use hci_conn_failed to do the connection cleanup properly. We also need to clean up ISO connections in a similar situation when connecting has started but LE Create CIS is not yet sent, so do it too here. Fixes: ca1fd42e7dbf ("Bluetooth: Fix potential double free caused by hci_conn_unlink") Reported-by: [email protected] Closes: https://lore.kernel.org/linux-bluetooth/[email protected]/ Signed-off-by: Pauli Virtanen <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luiz Augusto von Dentz <[email protected]> Date: Fri Aug 4 14:54:09 2023 -0700 Bluetooth: hci_conn: Fix hci_le_set_cig_params [ Upstream commit a091289218202bc09d9b9caa8afcde1018584aec ] When running with concurrent task only one CIS was being assigned so this attempts to rework the way the PDU is constructed so it is handled later at the callback instead of in place. Fixes: 26afbd826ee3 ("Bluetooth: Add initial implementation of CIS connections") Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luiz Augusto von Dentz <[email protected]> Date: Thu Aug 3 16:41:34 2023 -0700 Bluetooth: hci_conn: Fix not allowing valid CIS ID [ Upstream commit f2f84a70f9d0c9a3263194ca9d82e7bc6027d356 ] Only the number of CIS shall be limited to 0x1f, the CIS ID in the other hand is up to 0xef. Fixes: 26afbd826ee3 ("Bluetooth: Add initial implementation of CIS connections") Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jiapeng Chong <[email protected]> Date: Sun Jun 25 16:45:13 2023 +0800 Bluetooth: hci_conn: Use kmemdup() to replace kzalloc + memcpy [ Upstream commit 5b6d345d1b65d67624349e5de22227492c637576 ] Use kmemdup rather than duplicating its implementation. ./net/bluetooth/hci_conn.c:1880:7-14: WARNING opportunity for kmemdup. Reported-by: Abaci Robot <[email protected]> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5597 Signed-off-by: Jiapeng Chong <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: a09128921820 ("Bluetooth: hci_conn: Fix hci_le_set_cig_params") Signed-off-by: Sasha Levin <[email protected]>
Author: Pauli Virtanen <[email protected]> Date: Sat Aug 5 19:08:41 2023 +0300 Bluetooth: hci_event: drop only unbound CIS if Set CIG Parameters fails [ Upstream commit 66dee21524d9ac6461ec3052652b7bc0603ee0c5 ] When user tries to connect a new CIS when its CIG is not configurable, that connection shall fail, but pre-existing connections shall not be affected. However, currently hci_cc_le_set_cig_params deletes all CIS of the CIG on error so it doesn't work, even though controller shall not change CIG/CIS configuration if the command fails. Fix by failing on command error only the connections that are not yet bound, so that we keep the previous CIS configuration like the controller does. Fixes: 26afbd826ee3 ("Bluetooth: Add initial implementation of CIS connections") Signed-off-by: Pauli Virtanen <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luiz Augusto von Dentz <[email protected]> Date: Tue Jun 20 15:41:11 2023 -0700 Bluetooth: hci_event: Fix parsing of CIS Established Event [ Upstream commit 2be22f1941d5f661aa8043261d1bae5b6696c749 ] The ISO Interval on CIS Established Event uses 1.25 ms slots: BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 4, Part E page 2304: Time = N * 1.25 ms In addition to that this always update the QoS settings based on CIS Established Event. Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: 7f74563e6140 ("Bluetooth: ISO: do not emit new LE Create CIS if previous is pending") Signed-off-by: Sasha Levin <[email protected]>
Author: Manish Mandlik <[email protected]> Date: Fri Aug 4 11:14:45 2023 -0700 Bluetooth: hci_sync: Avoid use-after-free in dbg for hci_add_adv_monitor() [ Upstream commit a2bcd2b63271a93a695fabbfbf459c603d956d48 ] KSAN reports use-after-free in hci_add_adv_monitor(). While adding an adv monitor, hci_add_adv_monitor() calls -> msft_add_monitor_pattern() calls -> msft_add_monitor_sync() calls -> msft_le_monitor_advertisement_cb() calls in an error case -> hci_free_adv_monitor() which frees the *moniter. This is referenced by bt_dev_dbg() in hci_add_adv_monitor(). Fix the bt_dev_dbg() by using handle instead of monitor->handle. Fixes: b747a83690c8 ("Bluetooth: hci_sync: Refactor add Adv Monitor") Signed-off-by: Manish Mandlik <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Douglas Anderson <[email protected]> Date: Fri Jun 30 15:33:15 2023 -0700 Bluetooth: hci_sync: Don't double print name in add/remove adv_monitor [ Upstream commit 6f55eea116ba3646fb5fbb31de703f8cf79d8214 ] The hci_add_adv_monitor() hci_remove_adv_monitor() functions call bt_dev_dbg() to print some debug statements. The bt_dev_dbg() macro automatically adds in the device's name. That means that we shouldn't include the name in the bt_dev_dbg() calls. Suggested-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Stable-dep-of: a2bcd2b63271 ("Bluetooth: hci_sync: Avoid use-after-free in dbg for hci_add_adv_monitor()") Signed-off-by: Sasha Levin <[email protected]>
Author: Luiz Augusto von Dentz <[email protected]> Date: Wed Aug 9 16:49:33 2023 -0700 Bluetooth: hci_sync: Fix UAF in hci_disconnect_all_sync [ Upstream commit 94d9ba9f9888b748d4abd2aa1547af56ae85f772 ] Use-after-free can occur in hci_disconnect_all_sync if a connection is deleted by concurrent processing of a controller event. To prevent this the code now tries to iterate over the list backwards to ensure the links are cleanup before its parents, also it no longer relies on a cursor, instead it always uses the last element since hci_abort_conn_sync is guaranteed to call hci_conn_del. UAF crash log: ================================================================== BUG: KASAN: slab-use-after-free in hci_set_powered_sync (net/bluetooth/hci_sync.c:5424) [bluetooth] Read of size 8 at addr ffff888009d9c000 by task kworker/u9:0/124 CPU: 0 PID: 124 Comm: kworker/u9:0 Tainted: G W 6.5.0-rc1+ #10 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 Workqueue: hci0 hci_cmd_sync_work [bluetooth] Call Trace: <TASK> dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0xdd/0x160 ? hci_set_powered_sync+0x2c9/0x4a0 [bluetooth] kasan_report+0xa6/0xe0 ? hci_set_powered_sync+0x2c9/0x4a0 [bluetooth] ? __pfx_set_powered_sync+0x10/0x10 [bluetooth] hci_set_powered_sync+0x2c9/0x4a0 [bluetooth] ? __pfx_hci_set_powered_sync+0x10/0x10 [bluetooth] ? __pfx_lock_release+0x10/0x10 ? __pfx_set_powered_sync+0x10/0x10 [bluetooth] hci_cmd_sync_work+0x137/0x220 [bluetooth] process_one_work+0x526/0x9d0 ? __pfx_process_one_work+0x10/0x10 ? __pfx_do_raw_spin_lock+0x10/0x10 ? mark_held_locks+0x1a/0x90 worker_thread+0x92/0x630 ? __pfx_worker_thread+0x10/0x10 kthread+0x196/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 </TASK> Allocated by task 1782: kasan_save_stack+0x33/0x60 kasan_set_track+0x25/0x30 __kasan_kmalloc+0x8f/0xa0 hci_conn_add+0xa5/0xa80 [bluetooth] hci_bind_cis+0x881/0x9b0 [bluetooth] iso_connect_cis+0x121/0x520 [bluetooth] iso_sock_connect+0x3f6/0x790 [bluetooth] __sys_connect+0x109/0x130 __x64_sys_connect+0x40/0x50 do_syscall_64+0x60/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 695: kasan_save_stack+0x33/0x60 kasan_set_track+0x25/0x30 kasan_save_free_info+0x2b/0x50 __kasan_slab_free+0x10a/0x180 __kmem_cache_free+0x14d/0x2e0 device_release+0x5d/0xf0 kobject_put+0xdf/0x270 hci_disconn_complete_evt+0x274/0x3a0 [bluetooth] hci_event_packet+0x579/0x7e0 [bluetooth] hci_rx_work+0x287/0xaa0 [bluetooth] process_one_work+0x526/0x9d0 worker_thread+0x92/0x630 kthread+0x196/0x1e0 ret_from_fork+0x2c/0x50 ================================================================== Fixes: 182ee45da083 ("Bluetooth: hci_sync: Rework hci_suspend_notifier") Signed-off-by: Pauli Virtanen <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luiz Augusto von Dentz <[email protected]> Date: Thu Aug 3 11:04:51 2023 -0700 Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync [ Upstream commit 5af1f84ed13a416297ab9ced7537f4d5ae7f329a ] Connections may be cleanup while waiting for the commands to complete so this attempts to check if the connection handle remains valid in case of errors that would lead to call hci_conn_failed: BUG: KASAN: slab-use-after-free in hci_conn_failed+0x1f/0x160 Read of size 8 at addr ffff888001376958 by task kworker/u3:0/52 CPU: 0 PID: 52 Comm: kworker/u3:0 Not tainted 6.5.0-rc1-00527-g2dfe76d58d3a #5615 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: <TASK> dump_stack_lvl+0x1d/0x70 print_report+0xce/0x620 ? __virt_addr_valid+0xd4/0x150 ? hci_conn_failed+0x1f/0x160 kasan_report+0xd1/0x100 ? hci_conn_failed+0x1f/0x160 hci_conn_failed+0x1f/0x160 hci_abort_conn_sync+0x237/0x360 Signed-off-by: Luiz Augusto von Dentz <[email protected]> Stable-dep-of: 94d9ba9f9888 ("Bluetooth: hci_sync: Fix UAF in hci_disconnect_all_sync") Signed-off-by: Sasha Levin <[email protected]>
Author: Iulia Tanasescu <[email protected]> Date: Tue May 30 17:21:59 2023 +0300 Bluetooth: ISO: Add support for connecting multiple BISes [ Upstream commit a0bfde167b506423111ddb8cd71930497a40fc54 ] It is required for some configurations to have multiple BISes as part of the same BIG. Similar to the flow implemented for unicast, DEFER_SETUP will also be used to bind multiple BISes for the same BIG, before starting Periodic Advertising and creating the BIG. The user will have to open a new socket for each BIS. By setting the BT_DEFER_SETUP socket option and calling connect, a new connection will be added for the BIG and advertising handle set by the socket QoS parameters. Since all BISes will be bound for the same BIG and advertising handle, the socket QoS options and base parameters should match for all connections. By calling connect on a socket that does not have the BT_DEFER_SETUP option set, periodic advertising will be started and the BIG will be created, with a BIS for each previously bound connection. Since a BIG cannot be reconfigured with additional BISes after creation, no more connections can be bound for the BIG after the start periodic advertising and create BIG commands have been queued. The bis_cleanup function has also been updated, so that the advertising set and the BIG will not be terminated unless there are no more bound or connected BISes. The HCI_CONN_BIG_CREATED connection flag has been added to indicate that the BIG has been successfully created. This flag is checked at bis_cleanup, so that the BIG is only terminated if the HCI_LE_Create_BIG_Complete has been received. This implementation has been tested on hardware, using the "isotest" tool with an additional command line option, to specify the number of BISes to create as part of the desired BIG: tools/isotest -i hci0 -s 00:00:00:00:00:00 -N 2 -G 1 -T 1 The btmon log shows that a BIG containing 2 BISes has been created: < HCI Command: LE Create Broadcast Isochronous Group (0x08|0x0068) plen 31 Handle: 0x01 Advertising Handle: 0x01 Number of BIS: 2 SDU Interval: 10000 us (0x002710) Maximum SDU size: 40 Maximum Latency: 10 ms (0x000a) RTN: 0x02 PHY: LE 2M (0x02) Packing: Sequential (0x00) Framing: Unframed (0x00) Encryption: 0x00 Broadcast Code: 00000000000000000000000000000000 > HCI Event: Command Status (0x0f) plen 4 LE Create Broadcast Isochronous Group (0x08|0x0068) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 23 LE Broadcast Isochronous Group Complete (0x1b) Status: Success (0x00) Handle: 0x01 BIG Synchronization Delay: 1974 us (0x0007b6) Transport Latency: 1974 us (0x0007b6) PHY: LE 2M (0x02) NSE: 3 BN: 1 PTO: 1 IRC: 3 Maximum PDU: 40 ISO Interval: 10.00 msec (0x0008) Connection Handle #0: 10 Connection Handle #1: 11 < HCI Command: LE Setup Isochronous Data Path (0x08|0x006e) plen 13 Handle: 10 Data Path Direction: Input (Host to Controller) (0x00) Data Path: HCI (0x00) Coding Format: Transparent (0x03) Company Codec ID: Ericsson Technology Licensing (0) Vendor Codec ID: 0 Controller Delay: 0 us (0x000000) Codec Configuration Length: 0 Codec Configuration: > HCI Event: Command Complete (0x0e) plen 6 LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 Status: Success (0x00) Handle: 10 < HCI Command: LE Setup Isochronous Data Path (0x08|0x006e) plen 13 Handle: 11 Data Path Direction: Input (Host to Controller) (0x00) Data Path: HCI (0x00) Coding Format: Transparent (0x03) Company Codec ID: Ericsson Technology Licensing (0) Vendor Codec ID: 0 Controller Delay: 0 us (0x000000) Codec Configuration Length: 0 Codec Configuration: > HCI Event: Command Complete (0x0e) plen 6 LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 Status: Success (0x00) Handle: 11 < ISO Data TX: Handle 10 flags 0x02 dlen 44 < ISO Data TX: Handle 11 flags 0x02 dlen 44 > HCI Event: Number of Completed Packets (0x13) plen 5 Num handles: 1 Handle: 10 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 Num handles: 1 Handle: 11 Count: 1 Signed-off-by: Iulia Tanasescu <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Stable-dep-of: 7f74563e6140 ("Bluetooth: ISO: do not emit new LE Create CIS if previous is pending") Signed-off-by: Sasha Levin <[email protected]>
Author: Pauli Virtanen <[email protected]> Date: Thu Jun 1 09:34:46 2023 +0300 Bluetooth: ISO: do not emit new LE Create CIS if previous is pending [ Upstream commit 7f74563e6140e42b4ffae62adbef7a65967a3f98 ] LE Create CIS command shall not be sent before all CIS Established events from its previous invocation have been processed. Currently it is sent via hci_sync but that only waits for the first event, but there can be multiple. Make it wait for all events, and simplify the CIS creation as follows: Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been sent for the connection but it is not yet completed. Make BT_CONNECT state to mean the connection wants Create CIS. On events after which new Create CIS may need to be sent, send it if possible and some connections need it. These events are: hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis, hci_le_cis_estabilished_evt. The Create CIS status/completion events shall queue new Create CIS only if at least one of the connections transitions away from BT_CONNECT, so that we don't loop if controller is sending bogus events. This fixes sending multiple CIS Create for the same CIS in the "ISO AC 6(i) - Success" BlueZ test case: < HCI Command: LE Create Co.. (0x08|0x0064) plen 9 #129 [hci0] Number of CIS: 2 CIS Handle: 257 ACL Handle: 42 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 #130 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 29 #131 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 257 ... < HCI Command: LE Setup Is.. (0x08|0x006e) plen 13 #132 [hci0] ... > HCI Event: Command Complete (0x0e) plen 6 #133 [hci0] LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 ... < HCI Command: LE Create Co.. (0x08|0x0064) plen 5 #134 [hci0] Number of CIS: 1 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 #135 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: ACL Connection Already Exists (0x0b) > HCI Event: LE Meta Event (0x3e) plen 29 #136 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 258 ... Fixes: c09b80be6ffc ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED") Signed-off-by: Pauli Virtanen <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luiz Augusto von Dentz <[email protected]> Date: Thu Aug 3 14:41:46 2023 -0700 Bluetooth: ISO: Fix not checking for valid CIG/CIS IDs [ Upstream commit b7f923b1ef6a2e76013089d30c9552257056360a ] Valid range of CIG/CIS are 0x00 to 0xEF, so this checks they are properly checked before attempting to use HCI_OP_LE_SET_CIG_PARAMS. Fixes: ccf74f2390d6 ("Bluetooth: Add BTPROTO_ISO socket type") Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Iulia Tanasescu <[email protected]> Date: Mon Jul 3 10:02:38 2023 +0300 Bluetooth: ISO: Notify user space about failed bis connections [ Upstream commit f777d88278170410b06a1f6633f3b9375a4ddd6b ] Some use cases require the user to be informed if BIG synchronization fails. This commit makes it so that even if the BIG sync established event arrives with error status, a new hconn is added for each BIS, and the iso layer is notified about the failed connections. Unsuccesful bis connections will be marked using the HCI_CONN_BIG_SYNC_FAILED flag. From the iso layer, the POLLERR event is triggered on the newly allocated bis sockets, before adding them to the accept list of the parent socket. From user space, a new fd for each failed bis connection will be obtained by calling accept. The user should check for the POLLERR event on the new socket, to determine if the connection was successful or not. The HCI_CONN_BIG_SYNC flag has been added to mark whether the BIG sync has been successfully established. This flag is checked at bis cleanup, so the HCI LE BIG Terminate Sync command is only issued if needed. The BT_SK_BIG_SYNC flag indicates if BIG create sync has been called for a listening socket, to avoid issuing the command everytime a BIGInfo advertising report is received. Signed-off-by: Iulia Tanasescu <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Stable-dep-of: 94d9ba9f9888 ("Bluetooth: hci_sync: Fix UAF in hci_disconnect_all_sync") Signed-off-by: Sasha Levin <[email protected]>
Author: Hilda Wu <[email protected]> Date: Wed Jun 21 18:00:31 2023 +0800 Bluetooth: msft: Extended monitor tracking by address filter [ Upstream commit 9e14606d8f38ea52a38c27692a9c1513c987a5da ] Since limited tracking device per condition, this feature is to support tracking multiple devices concurrently. When a pattern monitor detects the device, this feature issues an address monitor for tracking that device. Let pattern monitor can keep monitor new devices. This feature adds an address filter when receiving a LE monitor device event which monitor handle is for a pattern, and the controller started monitoring the device. And this feature also has cancelled the monitor advertisement from address filters when receiving a LE monitor device event when the controller stopped monitoring the device specified by an address and monitor handle. Below is an example to know the feature adds the address filter. //Add MSFT pattern monitor < HCI Command: Vendor (0x3f|0x00f0) plen 14 #142 [hci0] 55.552420 03 b8 a4 03 ff 01 01 06 09 05 5f 52 45 46 .........._REF > HCI Event: Command Complete (0x0e) plen 6 #143 [hci0] 55.653960 Vendor (0x3f|0x00f0) ncmd 2 Status: Success (0x00) 03 00 //Got event from the pattern monitor > HCI Event: Vendor (0xff) plen 18 #148 [hci0] 58.384953 23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8 #yT3w..h....).'. 00 01 .. //Add MSFT address monitor (Sample address: B8:27:EB:29:C1:FB) < HCI Command: Vendor (0x3f|0x00f0) plen 13 #149 [hci0] 58.385067 03 b8 a4 03 ff 04 00 fb c1 29 eb 27 b8 .........).'. //Report to userspace about found device (ADV Monitor Device Found) @ MGMT Event: Unknown (0x002f) plen 38 {0x0003} [hci0] 58.680042 01 00 fb c1 29 eb 27 b8 01 ce 00 00 00 00 16 00 ....).'......... 0a 09 4b 45 59 42 44 5f 52 45 46 02 01 06 03 19 ..KEYBD_REF..... c1 03 03 03 12 18 ...... //Got event from address monitor > HCI Event: Vendor (0xff) plen 18 #152 [hci0] 58.672956 23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8 #yT3w..h....).'. 01 01 Signed-off-by: Alex Lu <[email protected]> Signed-off-by: Hilda Wu <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Stable-dep-of: 253f3399f4c0 ("Bluetooth: HCI: Introduce HCI_QUIRK_BROKEN_LE_CODED") Signed-off-by: Sasha Levin <[email protected]>
Author: Yuanjun Gong <[email protected]> Date: Wed Jul 26 21:30:00 2023 +0800 Bluetooth: nokia: fix value check in nokia_bluetooth_serdev_probe() [ Upstream commit e8b5aed31355072faac8092ead4938ddec3111fd ] in nokia_bluetooth_serdev_probe(), check the return value of clk_prepare_enable() and return the error code if clk_prepare_enable() returns an unexpected value. Fixes: 7bb318680e86 ("Bluetooth: add nokia driver") Signed-off-by: Yuanjun Gong <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yafang Shao <[email protected]> Date: Sun Jul 9 02:56:25 2023 +0000 bpf: Clear the probe_addr for uprobe [ Upstream commit 5125e757e62f6c1d5478db4c2b61a744060ddf3f ] To avoid returning uninitialized or random values when querying the file descriptor (fd) and accessing probe_addr, it is necessary to clear the variable prior to its use. Fixes: 41bdc4b40ed6 ("bpf: introduce bpf subcommand BPF_TASK_FD_QUERY") Signed-off-by: Yafang Shao <[email protected]> Acked-by: Yonghong Song <[email protected]> Acked-by: Jiri Olsa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yonghong Song <[email protected]> Date: Mon Aug 21 22:00:53 2023 -0700 bpf: Fix a bpf_kptr_xchg() issue with local kptr [ Upstream commit ab6c637ad0276e42f8acabcbc64932a6d346dab3 ] When reviewing local percpu kptr support, Alexei discovered a bug wherea bpf_kptr_xchg() may succeed even if the map value kptr type and locally allocated obj type do not match ([1]). Missed struct btf_id comparison is the reason for the bug. This patch added such struct btf_id comparison and will flag verification failure if types do not match. [1] https://lore.kernel.org/bpf/20230819002907.io3iphmnuk43xblu@macbook-pro-8.dhcp.thefacebook.com/#t Reported-by: Alexei Starovoitov <[email protected]> Fixes: 738c96d5e2e3 ("bpf: Allow local kptrs to be exchanged via bpf_kptr_xchg") Signed-off-by: Yonghong Song <[email protected]> Acked-by: Kumar Kartikeya Dwivedi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yafang Shao <[email protected]> Date: Thu Jul 13 02:56:39 2023 +0000 bpf: Fix an error around PTR_UNTRUSTED [ Upstream commit 7ce4dc3e4a9d954c8a1fb483c7a527e9b060b860 ] Per discussion with Alexei, the PTR_UNTRUSTED flag should not been cleared when we start to walk a new struct, because the struct in question may be a struct nested in a union. We should also check and set this flag before we walk its each member, in case itself is a union. We will clear this flag if the field is BTF_TYPE_SAFE_RCU_OR_NULL. Fixes: 6fcd486b3a0a ("bpf: Refactor RCU enforcement in the verifier.") Signed-off-by: Yafang Shao <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yafang Shao <[email protected]> Date: Thu Jul 13 02:56:41 2023 +0000 bpf: Fix an error in verifying a field in a union [ Upstream commit 33937607efa050d9e237e0c4ac4ada02d961c466 ] We are utilizing BPF LSM to monitor BPF operations within our container environment. When we add support for raw_tracepoint, it hits below error. ; (const void *)attr->raw_tracepoint.name); 27: (79) r3 = *(u64 *)(r2 +0) access beyond the end of member map_type (mend:4) in struct (anon) with off 0 size 8 It can be reproduced with below BPF prog. SEC("lsm/bpf") int BPF_PROG(bpf_audit, int cmd, union bpf_attr *attr, unsigned int size) { switch (cmd) { case BPF_RAW_TRACEPOINT_OPEN: bpf_printk("raw_tracepoint is %s", attr->raw_tracepoint.name); break; default: break; } return 0; } The reason is that when accessing a field in a union, such as bpf_attr, if the field is located within a nested struct that is not the first member of the union, it can result in incorrect field verification. union bpf_attr { struct { __u32 map_type; <<<< Actually it will find that field. __u32 key_size; __u32 value_size; ... }; ... struct { __u64 name; <<<< We want to verify this field. __u32 prog_fd; } raw_tracepoint; }; Considering the potential deep nesting levels, finding a perfect solution to address this issue has proven challenging. Therefore, I propose a solution where we simply skip the verification process if the field in question is located within a union. Fixes: 7e3617a72df3 ("bpf: Add array support to btf_struct_access") Signed-off-by: Yafang Shao <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kui-Feng Lee <[email protected]> Date: Thu Aug 3 16:12:06 2023 -0700 bpf: fix bpf_dynptr_slice() to stop return an ERR_PTR. [ Upstream commit 5426700e6841bf72e652e34b5cec68eadf442435 ] Verify if the pointer obtained from bpf_xdp_pointer() is either an error or NULL before returning it. The function bpf_dynptr_slice() mistakenly returned an ERR_PTR. Instead of solely checking for NULL, it should also verify if the pointer returned by bpf_xdp_pointer() is an error or NULL. Reported-by: Dan Carpenter <[email protected]> Closes: https://lore.kernel.org/bpf/[email protected]/ Fixes: 66e3a13e7c2c ("bpf: Add bpf_dynptr_slice and bpf_dynptr_slice_rdwr") Suggested-by: Alexei Starovoitov <[email protected]> Signed-off-by: Kui-Feng Lee <[email protected]> Acked-by: Yonghong Song <yonghong.so[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin KaFai Lau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kumar Kartikeya Dwivedi <[email protected]> Date: Tue Aug 22 23:21:39 2023 +0530 bpf: Fix check_func_arg_reg_off bug for graph root/node [ Upstream commit 6785b2edf48c6b1c3ea61fe3b0d2e02b8fbf90c0 ] The commit being fixed introduced a hunk into check_func_arg_reg_off that bypasses reg->off == 0 enforcement when offset points to a graph node or root. This might possibly be done for treating bpf_rbtree_remove and others as KF_RELEASE and then later check correct reg->off in helper argument checks. But this is not the case, those helpers are already not KF_RELEASE and permit non-zero reg->off and verify it later to match the subobject in BTF type. However, this logic leads to bpf_obj_drop permitting free of register arguments with non-zero offset when they point to a graph root or node within them, which is not ok. For instance: struct foo { int i; int j; struct bpf_rb_node node; }; struct foo *f = bpf_obj_new(typeof(*f)); if (!f) ... bpf_obj_drop(f); // OK bpf_obj_drop(&f->i); // still ok from verifier PoV bpf_obj_drop(&f->node); // Not OK, but permitted right now Fix this by dropping the whole part of code altogether. Fixes: 6a3cd3318ff6 ("bpf: Migrate release_on_unlock logic to non-owning ref semantics") Signed-off-by: Kumar Kartikeya Dwivedi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yafang Shao <[email protected]> Date: Wed Aug 23 02:07:02 2023 +0000 bpf: Fix issue in verifying allow_ptr_leaks commit d75e30dddf73449bc2d10bb8e2f1a2c446bc67a2 upstream. After we converted the capabilities of our networking-bpf program from cap_sys_admin to cap_net_admin+cap_bpf, our networking-bpf program failed to start. Because it failed the bpf verifier, and the error log is "R3 pointer comparison prohibited". A simple reproducer as follows, SEC("cls-ingress") int ingress(struct __sk_buff *skb) { struct iphdr *iph = (void *)(long)skb->data + sizeof(struct ethhdr); if ((long)(iph + 1) > (long)skb->data_end) return TC_ACT_STOLEN; return TC_ACT_OK; } Per discussion with Yonghong and Alexei [1], comparison of two packet pointers is not a pointer leak. This patch fixes it. Our local kernel is 6.1.y and we expect this fix to be backported to 6.1.y, so stable is CCed. [1]. https://lore.kernel.org/bpf/CAADnVQ+Nmspr7Si+pxWn8zkE7hX-7s93ugwC+94aXSy4uQ9vBg@mail.gmail.com/ Suggested-by: Yonghong Song <[email protected]> Suggested-by: Alexei Starovoitov <[email protected]> Signed-off-by: Yafang Shao <[email protected]> Acked-by: Eduard Zingerman <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lorenz Bauer <[email protected]> Date: Thu Jul 20 17:30:06 2023 +0200 bpf: reject unhashed sockets in bpf_sk_assign [ Upstream commit 67312adc96b5a585970d03b62412847afe2c6b01 ] The semantics for bpf_sk_assign are as follows: sk = some_lookup_func() bpf_sk_assign(skb, sk) bpf_sk_release(sk) That is, the sk is not consumed by bpf_sk_assign. The function therefore needs to make sure that sk lives long enough to be consumed from __inet_lookup_skb. The path through the stack for a TCPv4 packet is roughly: netif_receive_skb_core: takes RCU read lock __netif_receive_skb_core: sch_handle_ingress: tcf_classify: bpf_sk_assign() deliver_ptype_list_skb: deliver_skb: ip_packet_type->func == ip_rcv: ip_rcv_core: ip_rcv_finish_core: dst_input: ip_local_deliver: ip_local_deliver_finish: ip_protocol_deliver_rcu: tcp_v4_rcv: __inet_lookup_skb: skb_steal_sock The existing helper takes advantage of the fact that everything happens in the same RCU critical section: for sockets with SOCK_RCU_FREE set bpf_sk_assign never takes a reference. skb_steal_sock then checks SOCK_RCU_FREE again and does sock_put if necessary. This approach assumes that SOCK_RCU_FREE is never set on a sk between bpf_sk_assign and skb_steal_sock, but this invariant is violated by unhashed UDP sockets. A new UDP socket is created in TCP_CLOSE state but without SOCK_RCU_FREE set. That flag is only added in udp_lib_get_port() which happens when a socket is bound. When bpf_sk_assign was added it wasn't possible to access unhashed UDP sockets from BPF, so this wasn't a problem. This changed in commit 0c48eefae712 ("sock_map: Lift socket state restriction for datagram sockets"), but the helper wasn't adjusted accordingly. The following sequence of events will therefore lead to a refcount leak: 1. Add socket(AF_INET, SOCK_DGRAM) to a sockmap. 2. Pull socket out of sockmap and bpf_sk_assign it. Since SOCK_RCU_FREE is not set we increment the refcount. 3. bind() or connect() the socket, setting SOCK_RCU_FREE. 4. skb_steal_sock will now set refcounted = false due to SOCK_RCU_FREE. 5. tcp_v4_rcv() skips sock_put(). Fix the problem by rejecting unhashed sockets in bpf_sk_assign(). This matches the behaviour of __inet_lookup_skb which is ultimately the goal of bpf_sk_assign(). Fixes: cf7fbe660f2d ("bpf: Add socket assign support") Cc: Joe Stringer <[email protected]> Signed-off-by: Lorenz Bauer <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin KaFai Lau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Lobakin <[email protected]> Date: Fri Jul 7 10:54:23 2023 +0100 bpftool: Define a local bpf_perf_link to fix accessing its fields [ Upstream commit 67a43462ee2405c94e985a747bdcb8e3a0d66203 ] When building bpftool with !CONFIG_PERF_EVENTS: skeleton/pid_iter.bpf.c:47:14: error: incomplete definition of type 'struct bpf_perf_link' perf_link = container_of(link, struct bpf_perf_link, link); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ tools/bpf/bpftool/bootstrap/libbpf/include/bpf/bpf_helpers.h:74:22: note: expanded from macro 'container_of' ((type *)(__mptr - offsetof(type, member))); \ ^~~~~~~~~~~~~~~~~~~~~~ tools/bpf/bpftool/bootstrap/libbpf/include/bpf/bpf_helpers.h:68:60: note: expanded from macro 'offsetof' #define offsetof(TYPE, MEMBER) ((unsigned long)&((TYPE *)0)->MEMBER) ~~~~~~~~~~~^ skeleton/pid_iter.bpf.c:44:9: note: forward declaration of 'struct bpf_perf_link' struct bpf_perf_link *perf_link; ^ &bpf_perf_link is being defined and used only under the ifdef. Define struct bpf_perf_link___local with the `preserve_access_index` attribute inside the pid_iter BPF prog to allow compiling on any configs. CO-RE will substitute it with the real struct bpf_perf_link accesses later on. container_of() uses offsetof(), which does the necessary CO-RE relocation if the field is specified with `preserve_access_index` - as is the case for struct bpf_perf_link___local. Fixes: cbdaf71f7e65 ("bpftool: Add bpf_cookie to link output") Suggested-by: Andrii Nakryiko <[email protected]> Signed-off-by: Alexander Lobakin <[email protected]> Signed-off-by: Quentin Monnet <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Lobakin <[email protected]> Date: Fri Jul 7 10:54:25 2023 +0100 bpftool: Use a local bpf_perf_event_value to fix accessing its fields [ Upstream commit 658ac06801315b739774a15796ff06913ef5cad5 ] Fix the following error when building bpftool: CLANG profiler.bpf.o CLANG pid_iter.bpf.o skeleton/profiler.bpf.c:18:21: error: invalid application of 'sizeof' to an incomplete type 'struct bpf_perf_event_value' __uint(value_size, sizeof(struct bpf_perf_event_value)); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ tools/bpf/bpftool/bootstrap/libbpf/include/bpf/bpf_helpers.h:13:39: note: expanded from macro '__uint' tools/bpf/bpftool/bootstrap/libbpf/include/bpf/bpf_helper_defs.h:7:8: note: forward declaration of 'struct bpf_perf_event_value' struct bpf_perf_event_value; ^ struct bpf_perf_event_value is being used in the kernel only when CONFIG_BPF_EVENTS is enabled, so it misses a BTF entry then. Define struct bpf_perf_event_value___local with the `preserve_access_index` attribute inside the pid_iter BPF prog to allow compiling on any configs. It is a full mirror of a UAPI structure, so is compatible both with and w/o CO-RE. bpf_perf_event_read_value() requires a pointer of the original type, so a cast is needed. Fixes: 47c09d6a9f67 ("bpftool: Introduce "prog profile" command") Suggested-by: Andrii Nakryiko <[email protected]> Signed-off-by: Alexander Lobakin <[email protected]> Signed-off-by: Quentin Monnet <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Quentin Monnet <[email protected]> Date: Fri Jul 7 10:54:24 2023 +0100 bpftool: Use a local copy of BPF_LINK_TYPE_PERF_EVENT in pid_iter.bpf.c [ Upstream commit 44ba7b30e84fb40da2295e85a6d209e199fdc977 ] In order to allow the BPF program in bpftool's pid_iter.bpf.c to compile correctly on hosts where vmlinux.h does not define BPF_LINK_TYPE_PERF_EVENT (running kernel versions lower than 5.15, for example), define and use a local copy of the enum value. This requires LLVM 12 or newer to build the BPF program. Fixes: cbdaf71f7e65 ("bpftool: Add bpf_cookie to link output") Signed-off-by: Quentin Monnet <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Lobakin <[email protected]> Date: Fri Jul 7 10:54:22 2023 +0100 bpftool: use a local copy of perf_event to fix accessing :: Bpf_cookie [ Upstream commit 4cbeeb0dc02f8ac7b975b2ab0080ace53d43d62a ] When CONFIG_PERF_EVENTS is not set, struct perf_event remains empty. However, the structure is being used by bpftool indirectly via BTF. This leads to: skeleton/pid_iter.bpf.c:49:30: error: no member named 'bpf_cookie' in 'struct perf_event' return BPF_CORE_READ(event, bpf_cookie); ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~ ... skeleton/pid_iter.bpf.c:49:9: error: returning 'void' from a function with incompatible result type '__u64' (aka 'unsigned long long') return BPF_CORE_READ(event, bpf_cookie); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Tools and samples can't use any CONFIG_ definitions, so the fields used there should always be present. Define struct perf_event___local with the `preserve_access_index` attribute inside the pid_iter BPF prog to allow compiling on any configs. CO-RE will substitute it with the real struct perf_event accesses later on. Fixes: cbdaf71f7e65 ("bpftool: Add bpf_cookie to link output") Suggested-by: Andrii Nakryiko <[email protected]> Signed-off-by: Alexander Lobakin <[email protected]> Signed-off-by: Quentin Monnet <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Artem Chernyshev <[email protected]> Date: Tue Aug 15 00:00:30 2023 +0300 broadcom: b44: Use b44_writephy() return value [ Upstream commit 9944d203fa63721b87eee84a89f7275dc3d25c05 ] Return result of b44_writephy() instead of zero to deal with possible error. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Artem Chernyshev <[email protected]> Reviewed-by: Leon Romanovsky <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tony Lindgren <[email protected]> Date: Fri Aug 4 13:38:01 2023 +0300 bus: ti-sysc: Fix build warning for 64-bit build [ Upstream commit e1e1e9bb9d943ec690670a609a5f660ca10eaf85 ] Fix "warning: cast from pointer to integer of different size" on 64-bit builds. Note that this is a cosmetic fix at this point as the driver is not yet used for 64-bit systems. Fixes: feaa8baee82a ("bus: ti-sysc: Implement SoC revision handling") Reviewed-by: Dhruva Gole <[email protected]> Reviewed-by: Nishanth Menon <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tony Lindgren <[email protected]> Date: Tue Aug 15 08:49:05 2023 +0300 bus: ti-sysc: Fix cast to enum warning [ Upstream commit de44bf2f7683347f75690ef6cf61a1d5ba8f0891 ] Fix warning for "cast to smaller integer type 'enum sysc_soc' from 'const void *'". Cc: Nishanth Menon <[email protected]> Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Fixes: e1e1e9bb9d94 ("bus: ti-sysc: Fix build warning for 64-bit build") Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marc Kleine-Budde <[email protected]> Date: Tue Jul 4 11:23:37 2023 +0200 can: gs_usb: gs_usb_receive_bulk_callback(): count RX overflow errors also in case of OOM [ Upstream commit 6c8bc15f02b85bc8f47074110d8fd8caf7a1e42d ] In case of an RX overflow error from the CAN controller and an OOM where no skb can be allocated, the error counters are not incremented. Fix this by first incrementing the error counters and then allocate the skb. Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Markus Schneider-Pargmann <[email protected]> Date: Fri Jul 28 16:19:19 2023 +0200 can: tcan4x5x: Remove reserved register 0x814 from writable table [ Upstream commit fbe534f7bf213d485b0ed5362b24a41bf3e18803 ] The mentioned register is not writable. It is reserved and should not be written. Fixes: 39dbb21b6a29 ("can: tcan4x5x: Specify separate read/write ranges") Signed-off-by: Markus Schneider-Pargmann <[email protected]> Reviewed-by: Michal Kubiak <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Waiman Long <[email protected]> Date: Tue Jun 27 10:35:00 2023 -0400 cgroup/cpuset: Inherit parent's load balance state in v2 [ Upstream commit c8c926200c55454101f072a4b16c9ff5b8c9e56f ] Since commit f28e22441f35 ("cgroup/cpuset: Add a new isolated cpus.partition type"), the CS_SCHED_LOAD_BALANCE bit of a v2 cpuset can be on or off. The child cpusets of a partition root must have the same setting as its parent or it may screw up the rebuilding of sched domains. Fix this problem by making sure the a child v2 cpuset will follows its parent cpuset load balance state unless the child cpuset is a new partition root itself. Fixes: f28e22441f35 ("cgroup/cpuset: Add a new isolated cpus.partition type") Signed-off-by: Waiman Long <[email protected]> Signed-off-by: Tejun Heo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Winston Wen <[email protected]> Date: Mon Jul 24 10:10:57 2023 +0800 cifs: fix charset issue in reconnection [ Upstream commit a43f95fdd39490f7b156fd126f1e90ec2d5553f1 ] We need to specify charset, like "iocharset=utf-8", in mount options for Chinese path if the nls_default don't support it, such as iso8859-1, the default value for CONFIG_NLS_DEFAULT. But now in reconnection the nls_default is used, instead of the one we specified and used in mount, and this can lead to mount failure. Signed-off-by: Winston Wen <[email protected]> Reviewed-by: Paulo Alcantara <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Baoquan He <[email protected]> Date: Fri Jul 7 21:58:51 2023 +0800 clk: fixed-mmio: make COMMON_CLK_FIXED_MMIO depend on HAS_IOMEM [ Upstream commit e7dd44f4f3166db45248414f5df8f615392de47a ] On s390 systems (aka mainframes), it has classic channel devices for networking and permanent storage that are currently even more common than PCI devices. Hence it could have a fully functional s390 kernel with CONFIG_PCI=n, then the relevant iomem mapping functions [including ioremap(), devm_ioremap(), etc.] are not available. Here let COMMON_CLK_FIXED_MMIO depend on HAS_IOMEM so that it won't be built to cause below compiling error if PCI is unset: ------ ld: drivers/clk/clk-fixed-mmio.o: in function `fixed_mmio_clk_setup': clk-fixed-mmio.c:(.text+0x5e): undefined reference to `of_iomap' ld: clk-fixed-mmio.c:(.text+0xba): undefined reference to `iounmap' ------ Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Baoquan He <[email protected]> Cc: Michael Turquette <[email protected]> Cc: Stephen Boyd <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marco Felsch <[email protected]> Date: Mon Jul 31 16:21:49 2023 +0200 clk: imx8mp: fix sai4 clock [ Upstream commit c30f600f1f41dcf5ef0fb02e9a201f9b2e8f31bd ] 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 <[email protected]> Signed-off-by: Marco Felsch <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abel Vesa <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ahmad Fatoum <[email protected]> Date: Mon Aug 7 10:22:00 2023 +0200 clk: imx: composite-8m: fix clock pauses when set_rate would be a no-op [ Upstream commit 4dd432d985ef258e3bc436e568fba4b987b59171 ] 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 <[email protected]> Reviewed-by: Peng Fan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abel Vesa <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peng Fan <[email protected]> Date: Sun Jun 25 20:33:40 2023 +0800 clk: imx: imx8ulp: update SPLL2 type [ Upstream commit 7653a59be8af043adc4c09473975a860e6055ff9 ] 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 <[email protected]> Reviewed-by: Abel Vesa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abel Vesa <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ye Li <[email protected]> Date: Sun Jun 25 20:33:39 2023 +0800 clk: imx: pllv4: Fix SPLL2 MULT range [ Upstream commit 3f0cdb945471f1abd1cf4d172190e9c489c5052a ] 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 <[email protected]> Reviewed-by: Jacky Bai <[email protected]> Signed-off-by: Ye Li <[email protected]> Signed-off-by: Peng Fan <[email protected]> Reviewed-by: Abel Vesa <[email protected]> Link: https://lore.kernel.org/r/2023062512334[email protected] Signed-off-by: Abel Vesa <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Tue Jul 25 10:51:56 2023 +0200 clk: qcom: dispcc-sc8280xp: Use ret registers on GDSCs [ Upstream commit 20e1d75bc043c5ec1fd8f5169fde17db89eb11c3 ] The DISP_CC GDSCs have not been instructed to use the ret registers. Fix that. Fixes: 4a66e76fdb6d ("clk: qcom: Add SC8280XP display clock controller") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Imran Shaik <[email protected]> Date: Thu Aug 3 16:27:36 2023 +0530 clk: qcom: gcc-qdu1000: Fix clkref clocks handling [ Upstream commit 2524dae5cd453ca39e8ba1b95c2755a8a2d94059 ] Update the GCC clkref clock's halt_check to BRANCH_HALT, as it's status bit is not inverted in the latest hardware version of QDU1000 and QRU1000 SoCs. While at it, fix the gcc clkref clock ops as well. Fixes: 1c9efb0bc040 ("clk: qcom: Add QDU1000 and QRU1000 GCC support") Signed-off-by: Imran Shaik <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Imran Shaik <[email protected]> Date: Thu Aug 3 16:27:35 2023 +0530 clk: qcom: gcc-qdu1000: Fix gcc_pcie_0_pipe_clk_src clock handling [ Upstream commit b311f5d3c4749259043a9a458a8db07915210142 ] Fix the gcc pcie pipe clock handling as per the clk_regmap_phy_mux_ops implementation to let the clock framework automatically park the clock at XO when the clock is switched off and restore the parent when the clock is switched on. Fixes: 1c9efb0bc040 ("clk: qcom: Add QDU1000 and QRU1000 GCC support") Co-developed-by: Taniya Das <[email protected]> Signed-off-by: Taniya Das <[email protected]> Signed-off-by: Imran Shaik <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Imran Shaik <[email protected]> Date: Thu Aug 3 16:27:37 2023 +0530 clk: qcom: gcc-qdu1000: Register gcc_gpll1_out_even clock [ Upstream commit 06d71fa10f2e507444c6759328a6c19d38eab788 ] gcc_gpll1_out_even clock is referenced as a parent, but not registered with the clock framework. Hence add support to register the same. Fixes: 1c9efb0bc040 ("clk: qcom: Add QDU1000 and QRU1000 GCC support") Signed-off-by: Imran Shaik <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David Wronek <[email protected]> Date: Sun Jul 23 21:05:02 2023 +0200 clk: qcom: gcc-sc7180: Fix up gcc_sdcc2_apps_clk_src [ Upstream commit fd0b5ba87ad5709f0fd3d2bc4b7870494a75f96a ] Set .flags = CLK_OPS_PARENT_ENABLE to fix "gcc_sdcc2_apps_clk_src: rcg didn't update its configuration" error. Fixes: 17269568f726 ("clk: qcom: Add Global Clock controller (GCC) driver for SC7180") Signed-off-by: David Wronek <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Mon Jun 26 19:48:06 2023 +0200 clk: qcom: gcc-sc8280xp: Add missing GDSC flags [ Upstream commit 2fd02de27054576a4a8c89302e2f77122c55e957 ] All of the 8280's GCC GDSCs can and should use the retain registers so as not to lose their state when entering lower power modes. Fixes: d65d005f9a6c ("clk: qcom: add sc8280xp GCC driver") Signed-off-by: Konrad Dybcio <[email protected]> Acked-by: Manivannan Sadhasivam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Mon Jun 26 19:48:08 2023 +0200 clk: qcom: gcc-sc8280xp: Add missing GDSCs [ Upstream commit 4712eb7ff85bd3dd09c6668b8de4080e02b3eea9 ] There are 10 more GDSCs that we've not been caring about, and by extension (and perhaps even more importantly), not putting to sleep. Add them. Fixes: d65d005f9a6c ("clk: qcom: add sc8280xp GCC driver") Signed-off-by: Konrad Dybcio <[email protected]> Acked-by: Manivannan Sadhasivam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luca Weiss <[email protected]> Date: Fri Aug 4 16:09:30 2023 +0200 clk: qcom: gcc-sm6350: Fix gcc_sdcc2_apps_clk_src [ Upstream commit df04d166d1f346dbf740bbea64a3bed3e7f14c8d ] GPLL7 is not on by default, which causes a "gcc_sdcc2_apps_clk_src: rcg didn't update its configuration" error when booting. Set .flags = CLK_OPS_PARENT_ENABLE to fix the error. Fixes: 131abae905df ("clk: qcom: Add SM6350 GCC driver") Signed-off-by: Luca Weiss <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Danila Tikhonov <[email protected]> Date: Fri Jun 30 22:19:44 2023 +0300 clk: qcom: gcc-sm7150: Add CLK_OPS_PARENT_ENABLE to sdcc2 rcg [ Upstream commit ff19022b9112d6bbd7c117c83e944cb21b438e91 ] Set .flags = CLK_OPS_PARENT_ENABLE to fix "gcc_sdcc2_apps_clk_src: rcg didn't update its configuration" error. Fixes: a808d58ddf29 ("clk: qcom: Add Global Clock Controller (GCC) driver for SM7150") Signed-off-by: Danila Tikhonov <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Patrick Whewell <[email protected]> Date: Wed Aug 2 14:04:00 2023 -0700 clk: qcom: gcc-sm8250: Fix gcc_sdcc2_apps_clk_src [ Upstream commit 783cb693828ce487cf0bc6ad16cbcf2caae6f8d9 ] GPLL9 is not on by default, which causes a "gcc_sdcc2_apps_clk_src: rcg didn't update its configuration" error when booting. Set .flags = CLK_OPS_PARENT_ENABLE to fix the error. Fixes: 3e5770921a88 ("clk: qcom: gcc: Add global clock controller driver for SM8250") Reviewed-by: Konrad Dybcio <[email protected]> Reviewed-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Patrick Whewell <[email protected]> Reviewed-by: Vinod Koul <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Fri Aug 11 19:35:53 2023 +0200 clk: qcom: gcc-sm8450: Use floor ops for SDCC RCGs [ Upstream commit a27ac3806b0a0e6954fb5967223b8635242e5b8f ] Use the floor ops to prevent warnings like this at suspend exit and boot: mmc0: Card appears overclocked; req 800000 Hz, actual 25000000 Hz Fixes: db0c944ee92b ("clk: qcom: Add clock driver for SM8450") Signed-off-by: Konrad Dybcio <[email protected]> Reviewed-by: Vinod Koul <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Wed Jun 14 13:35:33 2023 +0200 clk: qcom: gpucc-sm6350: Fix clock source names [ Upstream commit 743913b343a3ec2510fe3c0dfaff03d049659922 ] fw_name for GCC inputs didn't match the bindings. Fix it. Fixes: 013804a727a0 ("clk: qcom: Add GPU clock controller driver for SM6350") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Wed Jun 14 13:35:32 2023 +0200 clk: qcom: gpucc-sm6350: Introduce index-based clk lookup [ Upstream commit f6f89d194e4ddcfe197ac8a05ed4161f642a5c68 ] Add the nowadays-prefered and marginally faster way of looking up parent clocks in the device tree. It also allows for clock-names-independent operation, so long as the order (which is enforced by schema) is kept. Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Stable-dep-of: 743913b343a3 ("clk: qcom: gpucc-sm6350: Fix clock source names") Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Fri Jul 28 09:57:38 2023 +0200 clk: qcom: reset: Use the correct type of sleep/delay based on length [ Upstream commit 181b66ee7cdd824797fc99b53bec29cf5630a04f ] Use the fsleep() helper that (based on the length of the delay, see: [1]) chooses the correct sleep/delay functions. [1] https://www.kernel.org/doc/Documentation/timers/timers-howto.txt Fixes: 2cb8a39b6781 ("clk: qcom: reset: Allow specifying custom reset delay") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alibek Omarov <[email protected]> Date: Wed Jun 14 16:47:50 2023 +0300 clk: rockchip: rk3568: Fix PLL rate setting for 78.75MHz [ Upstream commit dafebd0f9a4f56b10d7fbda0bff1f540d16a2ea4 ] PLL rate on RK356x is calculated through the simple formula: ((24000000 / _refdiv) * _fbdiv) / (_postdiv1 * _postdiv2) The PLL rate setting for 78.75MHz seems to be copied from 96MHz so this patch fixes it and configures it properly. Signed-off-by: Alibek Omarov <[email protected]> Fixes: 842f4cb72639 ("clk: rockchip: Add more PLL rates for rk3568") Reviewed-by: Sascha Hauer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhang Jianhua <[email protected]> Date: Sat Jul 22 15:31:07 2023 +0000 clk: sunxi-ng: Modify mismatched function name [ Upstream commit 075d9ca5b4e17f84fd1c744a405e69ec743be7f0 ] No functional modification involved. drivers/clk/sunxi-ng/ccu_mmc_timing.c:54: warning: expecting prototype for sunxi_ccu_set_mmc_timing_mode(). Prototype was for sunxi_ccu_get_mmc_timing_mode() instead Fixes: f6f64ed868d3 ("clk: sunxi-ng: Add interface to query or configure MMC timing modes.") Signed-off-by: Zhang Jianhua <[email protected]> Reviewed-by: Randy Dunlap <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jernej Skrabec <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Paul E. McKenney <[email protected]> Date: Wed Jun 7 11:59:49 2023 -0700 clocksource: Handle negative skews in "skew is too large" messages [ Upstream commit e40806e9bcf8aaa86dbf0d484e7cf3cfa09cb86c ] The nanosecond-to-millisecond skew computation uses unsigned arithmetic, which produces user-unfriendly large positive numbers for negative skews. Therefore, use signed arithmetic for this computation in order to preserve the negativity. Reported-by: Chris Bainbridge <[email protected]> Reported-by: Feng Tang <[email protected]> Fixes: dd029269947a ("clocksource: Improve "skew is too large" messages") Reviewed-by: Feng Tang <[email protected]> Tested-by: Chris Bainbridge <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ruidong Tian <[email protected]> Date: Fri Aug 4 16:15:14 2023 +0800 coresight: tmc: Explicit type conversions to prevent integer overflow [ Upstream commit fd380097cdb305582b7a1f9476391330299d2c59 ] Perf cs_etm session executed unexpectedly when AUX buffer > 1G. perf record -C 0 -m ,2G -e cs_etm// -- <workload> [ perf record: Captured and wrote 2.615 MB perf.data ] Perf only collect about 2M perf data rather than 2G. This is becasuse the operation, "nr_pages << PAGE_SHIFT", in coresight tmc driver, will overflow when nr_pages >= 0x80000(correspond to 1G AUX buffer). The overflow cause buffer allocation to fail, and TMC driver will alloc minimal buffer size(1M). You can just get about 2M perf data(1M AUX buffer + perf data header) at least. Explicit convert nr_pages to 64 bit to avoid overflow. Fixes: 22f429f19c41 ("coresight: etm-perf: Add support for ETR backend") Fixes: 99443ea19e8b ("coresight: Add generic TMC sg table framework") Fixes: 2e499bbc1a92 ("coresight: tmc: implementing TMC-ETF AUX space API") Signed-off-by: Ruidong Tian <[email protected]> Reviewed-by: James Clark <[email protected]> Signed-off-by: Suzuki K Poulose <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Junhao He <[email protected]> Date: Fri Aug 18 16:40:52 2023 +0800 coresight: trbe: Fix TRBE potential sleep in atomic context [ Upstream commit c0a232f1e19e378c5c4e5973a996392942c80090 ] smp_call_function_single() will allocate an IPI interrupt vector to the target processor and send a function call request to the interrupt vector. After the target processor receives the IPI interrupt, it will execute arm_trbe_remove_coresight_cpu() call request in the interrupt handler. According to the device_unregister() stack information, if other process is useing the device, the down_write() may sleep, and trigger deadlocks or unexpected errors. arm_trbe_remove_coresight_cpu coresight_unregister device_unregister device_del kobject_del __kobject_del sysfs_remove_dir kernfs_remove down_write ---------> it may sleep Add a helper arm_trbe_disable_cpu() to disable TRBE precpu irq and reset per TRBE. Simply call arm_trbe_remove_coresight_cpu() directly without useing the smp_call_function_single(), which is the same as registering the TRBE coresight device. Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver") Signed-off-by: Junhao He <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Remove duplicate cpumask checks during removal ] Signed-off-by: Suzuki K Poulose <[email protected]> [ v3 - Remove the operation of assigning NULL to cpudata->drvdata ] Signed-off-by: Suzuki K Poulose <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Gleixner <[email protected]> Date: Wed Aug 23 10:47:02 2023 +0200 cpu/hotplug: Prevent self deadlock on CPU hot-unplug commit 2b8272ff4a70b866106ae13c36be7ecbef5d5da2 upstream. Xiongfeng reported and debugged a self deadlock of the task which initiates and controls a CPU hot-unplug operation vs. the CFS bandwidth timer. CPU1 CPU2 T1 sets cfs_quota starts hrtimer cfs_bandwidth 'period_timer' T1 is migrated to CPU2 T1 initiates offlining of CPU1 Hotplug operation starts ... 'period_timer' expires and is re-enqueued on CPU1 ... take_cpu_down() CPU1 shuts down and does not handle timers anymore. They have to be migrated in the post dead hotplug steps by the control task. T1 runs the post dead offline operation T1 is scheduled out T1 waits for 'period_timer' to expire T1 waits there forever if it is scheduled out before it can execute the hrtimer offline callback hrtimers_dead_cpu(). Cure this by delegating the hotplug control operation to a worker thread on an online CPU. This takes the initiating user space task, which might be affected by the bandwidth timer, completely out of the picture. Reported-by: Xiongfeng Wang <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Yu Liao <[email protected]> Acked-by: Vincent Guittot <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/lkml/[email protected] Link: https://lore.kernel.org/r/87h6oqdq0i.ffs@tglx Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Swapnil Sapkal <[email protected]> Date: Fri Aug 18 11:44:52 2023 +0000 cpufreq: amd-pstate-ut: Fix kernel panic when loading the driver [ Upstream commit 60dd283804479c4a52f995b713f448e2cd65b8c8 ] After loading the amd-pstate-ut driver, amd_pstate_ut_check_perf() and amd_pstate_ut_check_freq() use cpufreq_cpu_get() to get the policy of the CPU and mark it as busy. In these functions, cpufreq_cpu_put() should be used to release the policy, but it is not, so any other entity trying to access the policy is blocked indefinitely. One such scenario is when amd_pstate mode is changed, leading to the following splat: [ 1332.103727] INFO: task bash:2929 blocked for more than 120 seconds. [ 1332.110001] Not tainted 6.5.0-rc2-amd-pstate-ut #5 [ 1332.115315] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1332.123140] task:bash state:D stack:0 pid:2929 ppid:2873 flags:0x00004006 [ 1332.123143] Call Trace: [ 1332.123145] <TASK> [ 1332.123148] __schedule+0x3c1/0x16a0 [ 1332.123154] ? _raw_read_lock_irqsave+0x2d/0x70 [ 1332.123157] schedule+0x6f/0x110 [ 1332.123160] schedule_timeout+0x14f/0x160 [ 1332.123162] ? preempt_count_add+0x86/0xd0 [ 1332.123165] __wait_for_common+0x92/0x190 [ 1332.123168] ? __pfx_schedule_timeout+0x10/0x10 [ 1332.123170] wait_for_completion+0x28/0x30 [ 1332.123173] cpufreq_policy_put_kobj+0x4d/0x90 [ 1332.123177] cpufreq_policy_free+0x157/0x1d0 [ 1332.123178] ? preempt_count_add+0x58/0xd0 [ 1332.123180] cpufreq_remove_dev+0xb6/0x100 [ 1332.123182] subsys_interface_unregister+0x114/0x120 [ 1332.123185] ? preempt_count_add+0x58/0xd0 [ 1332.123187] ? __pfx_amd_pstate_change_driver_mode+0x10/0x10 [ 1332.123190] cpufreq_unregister_driver+0x3b/0xd0 [ 1332.123192] amd_pstate_change_driver_mode+0x1e/0x50 [ 1332.123194] store_status+0xe9/0x180 [ 1332.123197] dev_attr_store+0x1b/0x30 [ 1332.123199] sysfs_kf_write+0x42/0x50 [ 1332.123202] kernfs_fop_write_iter+0x143/0x1d0 [ 1332.123204] vfs_write+0x2df/0x400 [ 1332.123208] ksys_write+0x6b/0xf0 [ 1332.123210] __x64_sys_write+0x1d/0x30 [ 1332.123213] do_syscall_64+0x60/0x90 [ 1332.123216] ? fpregs_assert_state_consistent+0x2e/0x50 [ 1332.123219] ? exit_to_user_mode_prepare+0x49/0x1a0 [ 1332.123223] ? irqentry_exit_to_user_mode+0xd/0x20 [ 1332.123225] ? irqentry_exit+0x3f/0x50 [ 1332.123226] ? exc_page_fault+0x8e/0x190 [ 1332.123228] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 1332.123232] RIP: 0033:0x7fa74c514a37 [ 1332.123234] RSP: 002b:00007ffe31dd0788 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 1332.123238] RAX: ffffffffffffffda RBX: 0000000000000008 RCX: 00007fa74c514a37 [ 1332.123239] RDX: 0000000000000008 RSI: 000055e27c447aa0 RDI: 0000000000000001 [ 1332.123241] RBP: 000055e27c447aa0 R08: 00007fa74c5d1460 R09: 000000007fffffff [ 1332.123242] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000008 [ 1332.123244] R13: 00007fa74c61a780 R14: 00007fa74c616600 R15: 00007fa74c615a00 [ 1332.123247] </TASK> Fix this by calling cpufreq_cpu_put() wherever necessary. Fixes: 14eb1c96e3a3 ("cpufreq: amd-pstate: Add test module for amd-pstate driver") Reviewed-by: Mario Limonciello <[email protected]> Reviewed-by: Meng Li <[email protected]> Reviewed-by: Wyes Karny <[email protected]> Suggested-by: Wyes Karny <[email protected]> Signed-off-by: Swapnil Sapkal <[email protected]> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Swapnil Sapkal <[email protected]> Date: Fri Aug 18 11:44:51 2023 +0000 cpufreq: amd-pstate-ut: Remove module parameter access [ Upstream commit 8d6e5e8268e89979d86501dbb8385ce2e6154de1 ] In amd-pstate-ut, shared memory-based systems call get_shared_mem() as part of amd_pstate_ut_check_enabled() function. This function was written when CONFIG_X86_AMD_PSTATE was tristate config and amd_pstate can be built as a module. Currently CONFIG_X86_AMD_PSTATE is a boolean config and module parameter shared_mem is removed. But amd-pstate-ut code still accesses this module parameter. Remove those accesses. Fixes: 456ca88d8a52 ("cpufreq: amd-pstate: change amd-pstate driver to be built-in type") Reviewed-by: Mario Limonciello <[email protected]> Reviewed-by: Meng Li <[email protected]> Reviewed-by: Wyes Karny <[email protected]> Suggested-by: Wyes Karny <[email protected]> Signed-off-by: Swapnil Sapkal <[email protected]> [ rjw: Subject edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gustavo A. R. Silva <[email protected]> Date: Mon Jul 31 21:15:48 2023 -0600 cpufreq: brcmstb-avs-cpufreq: Fix -Warray-bounds bug commit e520d0b6be950ce3738cf4b9bd3b392be818f1dc upstream. Allocate extra space for terminating element at: drivers/cpufreq/brcmstb-avs-cpufreq.c: 449 table[i].frequency = CPUFREQ_TABLE_END; and add code comment to make this clear. This fixes the following -Warray-bounds warning seen after building ARM with multi_v7_defconfig (GCC 13): In function 'brcm_avs_get_freq_table', inlined from 'brcm_avs_cpufreq_init' at drivers/cpufreq/brcmstb-avs-cpufreq.c:623:15: drivers/cpufreq/brcmstb-avs-cpufreq.c:449:28: warning: array subscript 5 is outside array bounds of 'void[60]' [-Warray-bounds=] 449 | table[i].frequency = CPUFREQ_TABLE_END; In file included from include/linux/node.h:18, from include/linux/cpu.h:17, from include/linux/cpufreq.h:12, from drivers/cpufreq/brcmstb-avs-cpufreq.c:44: In function 'devm_kmalloc_array', inlined from 'devm_kcalloc' at include/linux/device.h:328:9, inlined from 'brcm_avs_get_freq_table' at drivers/cpufreq/brcmstb-avs-cpufreq.c:437:10, inlined from 'brcm_avs_cpufreq_init' at drivers/cpufreq/brcmstb-avs-cpufreq.c:623:15: include/linux/device.h:323:16: note: at offset 60 into object of size 60 allocated by 'devm_kmalloc' 323 | return devm_kmalloc(dev, bytes, flags); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -Warray-bounds. Link: https://github.com/KSPP/linux/issues/324 Fixes: de322e085995 ("cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs") Cc: [email protected] Signed-off-by: Gustavo A. R. Silva <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Liao Chang <[email protected]> Date: Tue Aug 29 07:03:18 2023 +0000 cpufreq: Fix the race condition while updating the transition_task of policy [ Upstream commit 61bfbf7951ba561dcbdd5357702d3cbc2d447812 ] The field 'transition_task' of policy structure is used to track the task which is performing the frequency transition. Using this field to print a warning once detect a case where the same task is calling _begin() again before completing the preivous frequency transition via the _end(). However, there is a potential race condition in _end() and _begin() APIs while updating the field 'transition_task' of policy, the scenario is depicted below: Task A Task B /* 1st freq transition */ Invoke _begin() { ... ... } /* 2nd freq transition */ Invoke _begin() { ... //waiting for A to ... //clear ... //transition_ongoing ... //in _end() for ... //the 1st transition | Change the frequency | | Invoke _end() { | ... | ... | transition_ongoing = false; V transition_ongoing = true; transition_task = current; transition_task = NULL; ... //A overwrites the task ... //performing the transition ... //result in error warning. } To fix this race condition, the transition_lock of policy structure is now acquired before updating policy structure in _end() API. Which ensure that only one task can update the 'transition_task' field at a time. Link: https://lore.kernel.org/all/[email protected]/ Fixes: ca654dc3a93d ("cpufreq: Catch double invocations of cpufreq_freq_transition_begin/end") Signed-off-by: Liao Chang <[email protected]> Acked-by: Viresh Kumar <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Doug Smythies <[email protected]> Date: Sun Aug 20 13:46:49 2023 -0700 cpufreq: intel_pstate: set stale CPU frequency to minimum commit d51847acb018d83186e4af67bc93f9a00a8644f7 upstream. The intel_pstate CPU frequency scaling driver does not use policy->cur and it is 0. When the CPU frequency is outdated arch_freq_get_on_cpu() will default to the nominal clock frequency when its call to cpufreq_quick_getpolicy_cur returns the never updated 0. Thus, the listed frequency might be outside of currently set limits. Some users are complaining about the high reported frequency, albeit stale, when their system is idle and/or it is above the reduced maximum they have set. This patch will maintain policy_cur for the intel_pstate driver at the current minimum CPU frequency. Reported-by: Yang Jie <[email protected]> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217597 Signed-off-by: Doug Smythies <[email protected]> [ rjw: White space damage fixes and comment adjustment ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Keyon Jie <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Liao Chang <[email protected]> Date: Sat Aug 26 09:51:13 2023 +0000 cpufreq: powernow-k8: Use related_cpus instead of cpus in driver.exit() [ Upstream commit 03997da042dac73c69e60d91942c727c76828b65 ] Since the 'cpus' field of policy structure will become empty in the cpufreq core API, it is better to use 'related_cpus' in the exit() callback of driver. Fixes: c3274763bfc3 ("cpufreq: powernow-k8: Initialize per-cpu data-structures properly") Signed-off-by: Liao Chang <[email protected]> Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sumit Gupta <[email protected]> Date: Fri Aug 25 16:49:20 2023 +0530 cpufreq: tegra194: add online/offline hooks [ Upstream commit a3aa97be69a7cc14ddc2bb0add0b9c51cb74bf83 ] Implement the light-weight tear down and bring up helpers to reduce the amount of work to do on CPU offline/online operation. This change helps to make the hotplugging paths much faster. Suggested-by: Viresh Kumar <[email protected]> Signed-off-by: Sumit Gupta <[email protected]> Link: https://lore.kernel.org/lkml/20230816033402.3abmugb5goypvllm@vireshk-i7/ [ Viresh: Fixed rebase conflict ] Signed-off-by: Viresh Kumar <[email protected]> Stable-dep-of: de0e85b29edf ("cpufreq: tegra194: remove opp table in exit hook") Signed-off-by: Sasha Levin <[email protected]>
Author: Sumit Gupta <[email protected]> Date: Fri Aug 25 16:46:17 2023 +0530 cpufreq: tegra194: remove opp table in exit hook [ Upstream commit de0e85b29edfc68046d587c7d67bbd2bdc31b73f ] Add exit hook and remove OPP table when the device gets unregistered. This will fix the error messages when the CPU FREQ driver module is removed and then re-inserted. It also fixes these messages while onlining the first CPU from a policy whose all CPU's were previously offlined. debugfs: File 'cpu5' in directory 'opp' already present! debugfs: File 'cpu6' in directory 'opp' already present! debugfs: File 'cpu7' in directory 'opp' already present! Fixes: f41e1442ac5b ("cpufreq: tegra194: add OPP support and set bandwidth") Signed-off-by: Sumit Gupta <[email protected]> [ Viresh: Dropped irrelevant change from it ] Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rafael J. Wysocki <[email protected]> Date: Mon Jul 31 20:56:35 2023 +0200 cpuidle: teo: Update idle duration estimate when choosing shallower state [ Upstream commit 3f0b0966b30982e843950b170b7a9ddfd8094428 ] The TEO governor takes CPU utilization into account by refining idle state selection when the utilization is above a certain threshold. This is done by choosing an idle state shallower than the previously selected one. However, when doing this, the idle duration estimate needs to be adjusted so as to prevent the scheduler tick from being stopped when the candidate idle state is shallow, which may lead to excessive energy usage if the CPU is not woken up quickly enough going forward. Moreover, if the scheduler tick has been stopped already and the new idle duration estimate is too small, the replacement candidate state cannot be used. Modify the relevant code to take the above observations into account. Fixes: 9ce0f7c4bc64 ("cpuidle: teo: Introduce util-awareness") Link: https://lore.kernel.org/linux-pm/CAJZ5v0jJxHj65r2HXBTd3wfbZtsg=_StzwO1kA5STDnaPe_dWA@mail.gmail.com Signed-off-by: Rafael J. Wysocki <[email protected]> Reviewed-and-tested-by: Kajetan Puchalski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Frederick Lawler <[email protected]> Date: Tue Aug 1 08:57:09 2023 -0500 crypto: af_alg - Decrement struct key.usage in alg_set_by_key_serial() commit 6b4b53ca0b7300ba2af98a49dbce22054bf034fe upstream. Calls to lookup_user_key() require a corresponding key_put() to decrement the usage counter. Once it reaches zero, we schedule key GC. Therefore decrement struct key.usage in alg_set_by_key_serial(). Fixes: 7984ceb134bf ("crypto: af_alg - Support symmetric encryption via keyring keys") Cc: <[email protected]> Signed-off-by: Frederick Lawler <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Herbert Xu <[email protected]> Date: Thu Aug 3 17:59:28 2023 +0800 crypto: api - Use work queue in crypto_destroy_instance [ Upstream commit 9ae4577bc077a7e32c3c7d442c95bc76865c0f17 ] The function crypto_drop_spawn expects to be called in process context. However, when an instance is unregistered while it still has active users, the last user may cause the instance to be freed in atomic context. Fix this by delaying the freeing to a work queue. Fixes: 6bfd48096ff8 ("[CRYPTO] api: Added spawns") Reported-by: Florent Revest <[email protected]> Reported-by: [email protected] Reported-by: [email protected] Signed-off-by: Herbert Xu <[email protected]> Tested-by: Florent Revest <[email protected]> Acked-by: Florent Revest <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gaurav Jain <[email protected]> Date: Tue Aug 8 12:55:25 2023 +0200 crypto: caam - fix unchecked return value error [ Upstream commit e30685204711a6be40dec2622606950ccd37dafe ] error: Unchecked return value (CHECKED_RETURN) check_return: Calling sg_miter_next without checking return value fix: added check if(!sg_miter_next) Fixes: 8a2a0dd35f2e ("crypto: caam - strip input zeros from RSA input buffer") Signed-off-by: Gaurav Jain <[email protected]> Signed-off-by: Meenakshi Aggarwal <[email protected]> Reviewed-by: Gaurav Jain <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Giovanni Cabiddu <[email protected]> Date: Thu Jun 22 10:26:35 2023 +0100 crypto: qat - change value of default idle filter [ Upstream commit 0f942bdfe9d463be3073301519492f8d53c6b2d5 ] The power management configuration of 4xxx devices is too aggressive and in some conditions the device might be prematurely put to a low power state. Increase the idle filter value to prevent that. In future, this will be set by firmware. Fixes: e5745f34113b ("crypto: qat - enable power management for QAT GEN4") Signed-off-by: Giovanni Cabiddu <[email protected]> Reviewed-by: Damian Muszynski <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Bourgoin <[email protected]> Date: Thu Jul 13 17:15:15 2023 +0200 crypto: stm32 - fix loop iterating through scatterlist for DMA commit d9c83f71eeceed2cb54bb78be84f2d4055fd9a1f upstream. We were reading the length of the scatterlist sg after copying value of tsg inside. So we are using the size of the previous scatterlist and for the first one we are using an unitialised value. Fix this by copying tsg in sg[0] before reading the size. Fixes : 8a1012d3f2ab ("crypto: stm32 - Support for STM32 HASH module") Cc: [email protected] Signed-off-by: Thomas Bourgoin <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Bourgoin <[email protected]> Date: Thu Jul 13 17:15:17 2023 +0200 crypto: stm32 - fix MDMAT condition commit a4adfbc2544933ac12e7fbd50708290265546dbc upstream. If IP has MDMAT support, set or reset the bit MDMAT in Control Register. Fixes: b56403a25af7 ("crypto: stm32/hash - Support Ux500 hash") Cc: [email protected] Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Thomas Bourgoin <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Uwe Kleine-König <[email protected]> Date: Mon Jul 31 18:54:54 2023 +0200 crypto: stm32 - Properly handle pm_runtime_get failing [ Upstream commit aec48805163338f8413118796c1dd035661b9140 ] If pm_runtime_get() (disguised as pm_runtime_resume_and_get()) fails, this means the clk wasn't prepared and enabled. Returning early in this case however is wrong as then the following resource frees are skipped and this is never catched up. So do all the cleanups but clk_disable_unprepare(). Also don't emit a warning, as stm32_hash_runtime_resume() already emitted one. Note that the return value of stm32_hash_remove() is mostly ignored by the device core. The only effect of returning zero instead of an error value is to suppress another warning in platform_remove(). So return 0 even if pm_runtime_resume_and_get() failed. Fixes: 8b4d566de6a5 ("crypto: stm32/hash - Add power management support") Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Suman Ghosh <[email protected]> Date: Thu Aug 24 13:40:32 2023 +0530 cteonxt2-pf: Fix backpressure config for multiple PFC priorities to work simultaneously [ Upstream commit 597d0ec0e4ca6a912affea4cc94df08959e9ec74 ] MAC (CGX or RPM) asserts backpressure at TL3 or TL2 node of the egress hierarchical scheduler tree depending on link level config done. If there are multiple PFC priorities enabled at a time and for all such flows to backoff, each priority will have to assert backpressure at different TL3/TL2 scheduler nodes and these flows will need to submit egress pkts to these nodes. Current PFC configuration has an issue where in only one backpressure scheduler node is being allocated which is resulting in only one PFC priority to work. This patch fixes this issue. Fixes: 99c969a83d82 ("octeontx2-pf: Add egress PFC support") Signed-off-by: Suman Ghosh <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jann Horn <[email protected]> Date: Fri Aug 25 15:32:41 2023 +0200 dccp: Fix out of bounds access in DCCP error handler commit 977ad86c2a1bcaf58f01ab98df5cc145083c489c upstream. There was a previous attempt to fix an out-of-bounds access in the DCCP error handlers, but that fix assumed that the error handlers only want to access the first 8 bytes of the DCCP header. Actually, they also look at the DCCP sequence number, which is stored beyond 8 bytes, so an explicit pskb_may_pull() is required. Fixes: 6706a97fec96 ("dccp: fix out of bound access in dccp_v4_err()") Fixes: 1aa9d1a0e7ee ("ipv6: dccp: fix out of bound access in dccp_v6_err()") Cc: [email protected] Signed-off-by: Jann Horn <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alexander Aring <[email protected]> Date: Thu Aug 24 16:51:42 2023 -0400 dlm: fix plock lookup when using multiple lockspaces commit 7c53e847ff5e97f033fdd31f71949807633d506b upstream. All posix lock ops, for all lockspaces (gfs2 file systems) are sent to userspace (dlm_controld) through a single misc device. The dlm_controld daemon reads the ops from the misc device and sends them to other cluster nodes using separate, per-lockspace cluster api communication channels. The ops for a single lockspace are ordered at this level, so that the results are received in the same sequence that the requests were sent. When the results are sent back to the kernel via the misc device, they are again funneled through the single misc device for all lockspaces. When the dlm code in the kernel processes the results from the misc device, these results will be returned in the same sequence that the requests were sent, on a per-lockspace basis. A recent change in this request/reply matching code missed the "per-lockspace" check (fsid comparison) when matching request and reply, so replies could be incorrectly matched to requests from other lockspaces. Cc: [email protected] Reported-by: Barry Marson <[email protected]> Fixes: 57e2c2f2d94c ("fs: dlm: fix mismatch of plock results from userspace") Signed-off-by: Alexander Aring <[email protected]> Signed-off-by: David Teigland <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Rob Clark <[email protected]> Date: Mon Jul 24 07:49:41 2023 -0700 dma-buf/sync_file: Fix docs syntax [ Upstream commit 05d56d8079d510a2994039470f65bea85f0075ee ] Fixes the warning: include/uapi/linux/sync_file.h:77: warning: Function parameter or member 'num_fences' not described in 'sync_file_info' Fixes: 2d75c88fefb2 ("staging/android: refactor SYNC IOCTLs") Signed-off-by: Rob Clark <[email protected]> Reviewed-by: Randy Dunlap <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Fenghua Yu <[email protected]> Date: Thu Aug 10 18:26:34 2023 -0700 dmaengine: idxd: Allow ATS disable update only for configurable devices [ Upstream commit 0056a7f07b0a63e6cee815a789eabba6f3a710f0 ] ATS disable status in a WQ is read-only if the device is not configurable. This change ensures that the ATS disable attribute can be modified via sysfs only on configurable devices. Fixes: 92de5fa2dc39 ("dmaengine: idxd: add ATS disable knob for work queues") Signed-off-by: Fenghua Yu <[email protected]> Reviewed-by: Dave Jiang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Fenghua Yu <[email protected]> Date: Wed Jul 12 10:44:36 2023 -0700 dmaengine: idxd: Expose ATS disable knob only when WQ ATS is supported [ Upstream commit 62b41b656666d2d35890124df5ef0881fe6d6769 ] WQ Advanced Translation Service (ATS) can be controlled only when WQ ATS is supported. The sysfs ATS disable knob should be visible only when the features is supported. Signed-off-by: Fenghua Yu <[email protected]> Reviewed-by: Dave Jiang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Stable-dep-of: 0056a7f07b0a ("dmaengine: idxd: Allow ATS disable update only for configurable devices") Signed-off-by: Sasha Levin <[email protected]>
Author: Fenghua Yu <[email protected]> Date: Thu Aug 10 18:26:35 2023 -0700 dmaengine: idxd: Fix issues with PRS disable sysfs knob [ Upstream commit 8cae66574398326134a41513b419e00ad4e380ca ] There are two issues in the current PRS disable sysfs store function wq_prs_disable_store(): 1. Since PRS disable knob is invisible if PRS disable is not supported in WQ, it's redundant to check PRS support again in the store function again. Remove the redundant PRS support check. 2. Since PRS disable is read-only when the device is not configurable, PRS disable cannot be changed on the device. Add device configurable check in the store function. Fixes: f2dc327131b5 ("dmaengine: idxd: add per wq PRS disable") Signed-off-by: Fenghua Yu <[email protected]> Reviewed-by: Dave Jiang <[email protected]> Link: https://lore.kernel.org/r/202308110126[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rex Zhang <[email protected]> Date: Wed Jun 14 14:27:06 2023 +0800 dmaengine: idxd: Modify the dependence of attribute pasid_enabled [ Upstream commit 50c5e6f41d5ad7c731c31135a30d0e4f0e4fea26 ] Kernel PASID and user PASID are separately enabled. User needs to know the user PASID enabling status to decide how to use IDXD device in user space. This is done via the attribute /sys/bus/dsa/devices/dsa0/pasid_enabled. It's unnecessary for user to know the kernel PASID enabling status because user won't use the kernel PASID. But instead of showing the user PASID enabling status, the attribute shows the kernel PASID enabling status. Fix the issue by showing the user PASID enabling status in the attribute. Fixes: 42a1b73852c4 ("dmaengine: idxd: Separate user and kernel pasid enabling") Signed-off-by: Rex Zhang <[email protected]> Acked-by: Fenghua Yu <[email protected]> Acked-by: Dave Jiang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Fenghua Yu <[email protected]> Date: Wed Jul 12 10:44:35 2023 -0700 dmaengine: idxd: Simplify WQ attribute visibility checks [ Upstream commit 97b1185fe54c8ce94104e3c7fa4ee0bbedd85920 ] The functions that check if WQ attributes are invisible are almost duplicate. Define a helper to simplify these functions and future WQ attribute visibility checks as well. Signed-off-by: Fenghua Yu <[email protected]> Reviewed-by: Dave Jiang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Stable-dep-of: 0056a7f07b0a ("dmaengine: idxd: Allow ATS disable update only for configurable devices") Signed-off-by: Sasha Levin <[email protected]>
Author: ruanjinjie <[email protected]> Date: Mon Jul 24 14:41:08 2023 +0000 dmaengine: ste_dma40: Add missing IRQ check in d40_probe [ Upstream commit c05ce6907b3d6e148b70f0bb5eafd61dcef1ddc1 ] Check for the return value of platform_get_irq(): if no interrupt is specified, it wouldn't make sense to call request_irq(). Fixes: 8d318a50b3d7 ("DMAENGINE: Support for ST-Ericssons DMA40 block v3") Signed-off-by: Ruan Jinjie <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Randy Dunlap <[email protected]> Date: Sun Jul 9 22:23:05 2023 -0700 docs: ABI: fix spelling/grammar in SBEFIFO timeout interface [ Upstream commit 2cd9ec2a51474d4c0b4d2a061f2de7da34eff476 ] Correct spelling problems as identified by codespell. Correct one grammar error. Fixes: 9a93de620e0a ("docs: ABI: testing: Document the SBEFIFO timeout interface") Signed-off-by: Randy Dunlap <[email protected]> Cc: Eddie James <[email protected]> Cc: Joel Stanley <[email protected]> Link: https://lore.kernel.org/r/20230710052305.29611-1[email protected] Signed-off-by: Joel Stanley <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jason Gunthorpe <[email protected]> Date: Mon Jul 24 14:40:46 2023 -0300 driver core: Call dma_cleanup() on the test_remove path [ Upstream commit f429378a9bf84d79a7e2cae05d2e3384cf7d68ba ] When test_remove is enabled really_probe() does not properly pair dma_configure() with dma_remove(), it will end up calling dma_configure() twice. This corrupts the owner_cnt and renders the group unusable with VFIO/etc. Add the missing cleanup before going back to re_probe. Fixes: 25f3bcfc54bc ("driver core: Add dma_cleanup callback in bus_type") Reported-by: Zenghui Yu <[email protected]> Tested-by: Zenghui Yu <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Jason Gunthorpe <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Link: https://lore.kernel.org/r/0-v2[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Tue Jul 18 10:03:49 2023 +0300 driver core: test_async: fix an error code [ Upstream commit 22d2381bbd70a5853c2ee77522f4965139672db9 ] The test_platform_device_register_node() function should return error pointers instead of NULL. That is what the callers are expecting. Fixes: 57ea974fb871 ("driver core: Rewrite test_async_driver_probe to cover serialization and NUMA affinity") Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David Gow <[email protected]> Date: Thu Jul 20 14:45:09 2023 +0200 drivers: base: Free devm resources when unregistering a device [ Upstream commit 699fb50d99039a50e7494de644f96c889279aca3 ] In the current code, devres_release_all() only gets called if the device has a bus and has been probed. This leads to issues when using bus-less or driver-less devices where the device might never get freed if a managed resource holds a reference to the device. This is happening in the DRM framework for example. We should thus call devres_release_all() in the device_del() function to make sure that the device-managed actions are properly executed when the device is unregistered, even if it has neither a bus nor a driver. This is effectively the same change than commit 2f8d16a996da ("devres: release resources on device_del()") that got reverted by commit a525a3ddeaca ("driver core: free devres in device_release") over memory leaks concerns. This patch effectively combines the two commits mentioned above to release the resources both on device_del() and device_release() and get the best of both worlds. Fixes: a525a3ddeaca ("driver core: free devres in device_release") Signed-off-by: David Gow <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/20230720-kunit-devm-inconsistencies-test-v3-3-6aa7e074f373@kernel.org Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Minjie Du <[email protected]> Date: Wed Jul 12 18:22:46 2023 +0800 drivers: clk: keystone: Fix parameter judgment in _of_pll_clk_init() [ Upstream commit a995c50db887ef97f3160775aef7d772635a6f6e ] The function clk_register_pll() may return NULL or an ERR_PTR. Don't treat an ERR_PTR as valid. Signed-off-by: Minjie Du <[email protected]> Link: https://lore.kernel.org/r/[email protected] Fixes: b9e0d40c0d83 ("clk: keystone: add Keystone PLL clock driver") [[email protected]: Reword commit text] Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Maciej S. Szmigiero <[email protected]> Date: Wed Aug 9 20:40:18 2023 +0200 Drivers: hv: vmbus: Don't dereference ACPI root object handle [ Upstream commit 78e04bbff849b51b56f5925b1945db2c6e128b61 ] Since the commit referenced in the Fixes: tag below the VMBus client driver is walking the ACPI namespace up from the VMBus ACPI device to the ACPI namespace root object trying to find Hyper-V MMIO ranges. However, if it is not able to find them it ends trying to walk resources of the ACPI namespace root object itself. This object has all-ones handle, which causes a NULL pointer dereference in the ACPI code (from dereferencing this pointer with an offset). This in turn causes an oops on boot with VMBus host implementations that do not provide Hyper-V MMIO ranges in their VMBus ACPI device or its ancestors. The QEMU VMBus implementation is an example of such implementation. I guess providing these ranges is optional, since all tested Windows versions seem to be able to use VMBus devices without them. Fix this by explicitly terminating the lookup at the ACPI namespace root object. Note that Linux guests under KVM/QEMU do not use the Hyper-V PV interface by default - they only do so if the KVM PV interface is missing or disabled. Example stack trace of such oops: [ 3.710827] ? __die+0x1f/0x60 [ 3.715030] ? page_fault_oops+0x159/0x460 [ 3.716008] ? exc_page_fault+0x73/0x170 [ 3.716959] ? asm_exc_page_fault+0x22/0x30 [ 3.717957] ? acpi_ns_lookup+0x7a/0x4b0 [ 3.718898] ? acpi_ns_internalize_name+0x79/0xc0 [ 3.720018] acpi_ns_get_node_unlocked+0xb5/0xe0 [ 3.721120] ? acpi_ns_check_object_type+0xfe/0x200 [ 3.722285] ? acpi_rs_convert_aml_to_resource+0x37/0x6e0 [ 3.723559] ? down_timeout+0x3a/0x60 [ 3.724455] ? acpi_ns_get_node+0x3a/0x60 [ 3.725412] acpi_ns_get_node+0x3a/0x60 [ 3.726335] acpi_ns_evaluate+0x1c3/0x2c0 [ 3.727295] acpi_ut_evaluate_object+0x64/0x1b0 [ 3.728400] acpi_rs_get_method_data+0x2b/0x70 [ 3.729476] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus] [ 3.730940] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus] [ 3.732411] acpi_walk_resources+0x78/0xd0 [ 3.733398] vmbus_platform_driver_probe+0x9f/0x1d0 [hv_vmbus] [ 3.734802] platform_probe+0x3d/0x90 [ 3.735684] really_probe+0x19b/0x400 [ 3.736570] ? __device_attach_driver+0x100/0x100 [ 3.737697] __driver_probe_device+0x78/0x160 [ 3.738746] driver_probe_device+0x1f/0x90 [ 3.739743] __driver_attach+0xc2/0x1b0 [ 3.740671] bus_for_each_dev+0x70/0xc0 [ 3.741601] bus_add_driver+0x10e/0x210 [ 3.742527] driver_register+0x55/0xf0 [ 3.744412] ? 0xffffffffc039a000 [ 3.745207] hv_acpi_init+0x3c/0x1000 [hv_vmbus] Fixes: 7f163a6fd957 ("drivers:hv: Modify hv_vmbus to search for all MMIO ranges available.") Signed-off-by: Maciej S. Szmigiero <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Signed-off-by: Wei Liu <[email protected]> Link: https://lore.kernel.org/r/fd8e64ceeecfd1d95ff49021080cf699e88dbbde.1691606267.git.maciej.szmigiero@oracle.com Signed-off-by: Sasha Levin <[email protected]>
Author: Dongliang Mu <[email protected]> Date: Mon Feb 27 18:24:08 2023 +0800 drivers: usb: smsusb: fix error handling code in smsusb_init_device [ Upstream commit b9c7141f384097fa4fa67d2f72e5731d628aef7c ] The previous commit 4b208f8b561f ("[media] siano: register media controller earlier")moves siano_media_device_register before smscore_register_device, and adds corresponding error handling code if smscore_register_device fails. However, it misses the following error handling code of smsusb_init_device. Fix this by moving error handling code at the end of smsusb_init_device and adding a goto statement in the following error handling parts. Fixes: 4b208f8b561f ("[media] siano: register media controller earlier") Signed-off-by: Dongliang Mu <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Fudong Wang <[email protected]> Date: Fri Aug 11 08:24:59 2023 +0800 drm/amd/display: Add smu write msg id fail retry process commit 72105dcfa3d12b5af49311f857e3490baa225135 upstream. A benchmark stress test (12-40 machines x 48hours) found that DCN315 has cases where DC writes to an indirect register to set the smu clock msg id, but when we go to read the same indirect register the returned msg id doesn't match with what we just set it to. So, to fix this retry the write until the register's value matches with the requested value. Cc: [email protected] # 6.1+ Fixes: f94903996140 ("drm/amd/display: Add DCN315 CLK_MGR") Reviewed-by: Charlene Liu <[email protected]> Acked-by: Hamza Mahfooz <[email protected]> Signed-off-by: Fudong Wang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Wesley Chalmers <[email protected]> Date: Thu Nov 3 22:29:31 2022 -0400 drm/amd/display: Do not set drr on pipe commit [ Upstream commit e101bf95ea87ccc03ac2f48dfc0757c6364ff3c7 ] [WHY] Writing to DRR registers such as OTG_V_TOTAL_MIN on the same frame as a pipe commit can cause underflow. [HOW] Move DMUB p-state delegate into optimze_bandwidth; enabling FAMS sets optimized_required. This change expects that Freesync requests are blocked when optimized_required is true. Reviewed-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Wesley Chalmers <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hamza Mahfooz <[email protected]> Date: Fri Aug 4 11:13:04 2023 -0400 drm/amd/display: ensure async flips are only accepted for fast updates commit a7c0cad0dc060bb77e9c9d235d68441b0fc69507 upstream. We should be checking to see if async flips are supported in amdgpu_dm_atomic_check() (i.e. not dm_crtc_helper_atomic_check()). Also, async flipping isn't supported if a plane's framebuffer changes memory domains during an atomic commit. So, move the check from dm_crtc_helper_atomic_check() to amdgpu_dm_atomic_check() and check if the memory domain has changed in amdgpu_dm_atomic_check(). Cc: [email protected] Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2733 Fixes: c1e18c44dc7f ("drm/amd/display: only accept async flips for fast updates") Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Hamza Mahfooz <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: Mario Limonciello <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Leo Chen <[email protected]> Date: Wed Jul 12 16:50:15 2023 -0400 drm/amd/display: Exit idle optimizations before attempt to access PHY [ Upstream commit de612738e9771bd66aeb20044486c457c512f684 ] [Why & How] DMUB may hang when powering down pixel clocks due to no dprefclk. It is fixed by exiting idle optimization before the attempt to access PHY. Reviewed-by: Nicholas Kazlauskas <[email protected]> Acked-by: Alex Hung <[email protected]> Signed-off-by: Leo Chen <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: George Shen <[email protected]> Date: Tue Jul 11 13:22:36 2023 -0400 drm/amd/display: Guard DCN31 PHYD32CLK logic against chip family [ Upstream commit 25b054c3c89cb6a7106a7982f0f70e83d0797dab ] [Why] Current yellow carp B0 PHYD32CLK logic is incorrectly applied to other ASICs. [How] Add guard to check chip family is yellow carp before applying logic. Reviewed-by: Hansen Dsouza <[email protected]> Acked-by: Alex Hung <[email protected]> Signed-off-by: George Shen <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hamza Mahfooz <[email protected]> Date: Tue Aug 22 12:31:09 2023 -0400 drm/amd/display: register edp_backlight_control() for DCN301 commit 1611917f39bee1abfc01501238db8ac19649042d upstream. As made mention of in commit 099303e9a9bd ("drm/amd/display: eDP intermittent black screen during PnP"), we need to turn off the display's backlight before powering off an eDP display. Not doing so will result in undefined behaviour according to the eDP spec. So, set DCN301's edp_backlight_control() function pointer to dce110_edp_backlight_control(). Cc: [email protected] Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2765 Fixes: 9c75891feef0 ("drm/amd/display: rework recent update PHY state commit") Suggested-by: Swapnil Patel <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Hamza Mahfooz <hamza.mahf[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lijo Lazar <[email protected]> Date: Thu Aug 10 16:10:03 2023 +0530 drm/amd/pm: Fix temperature unit of SMU v13.0.6 [ Upstream commit 8d036427f0042a91136e6f19a39542eedec4e96c ] Temperature needs to be reported in millidegree Celsius. Signed-off-by: Lijo Lazar <[email protected]> Reviewed-by: Yang Wang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yang Wang <[email protected]> Date: Tue Aug 1 16:53:23 2023 +0800 drm/amd/pm: fix variable dereferenced issue in amdgpu_device_attr_create() [ Upstream commit 25e6373a5b8efc623443f2699d2b929bf3067d76 ] - fix variable ('attr') dereferenced issue. - using condition check instead of BUG_ON(). Fixes: 4e01847c38f7 ("drm/amdgpu: optimize amdgpu device attribute code") Cc: Dan Carpenter <[email protected]> Signed-off-by: Yang Wang <[email protected]> Reviewed-by: Kenneth Feng <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jane Jian <[email protected]> Date: Thu Jul 20 18:08:07 2023 +0800 drm/amd/smu: use AverageGfxclkFrequency* to replace previous GFX Curr Clock [ Upstream commit 4a37c55b859a69f429bfa7fab4fc43ee470b60ed ] Report current GFX clock also from average clock value as the original CurrClock data is not valid/accurate any more as per FW team Signed-off-by: Jane Jian <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnd Bergmann <[email protected]> Date: Fri Jul 7 13:11:51 2023 +0200 drm/amdgpu: avoid integer overflow warning in amdgpu_device_resize_fb_bar() [ Upstream commit 822130b5e8834ab30ad410cf19a582e5014b9a85 ] On 32-bit architectures comparing a resource against a value larger than U32_MAX can cause a warning: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1344:18: error: result of comparison of constant 4294967296 with expression of type 'resource_size_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare] res->start > 0x100000000ull) ~~~~~~~~~~ ^ ~~~~~~~~~~~~~~ As gcc does not warn about this in dead code, add an IS_ENABLED() check at the start of the function. This will always return success but not actually resize the BAR on 32-bit architectures without high memory, which is exactly what we want here, as the driver can fall back to bank switching the VRAM access. Fixes: 31b8adab3247 ("drm/amdgpu: require a root bus window above 4GB for BAR resize") Reviewed-by: Christian König <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lijo Lazar <[email protected]> Date: Tue Jul 25 19:11:54 2023 +0530 drm/amdgpu: Match against exact bootloader status [ Upstream commit d3de41ee5febe5c2d9989fe9810bce2bb54a3a8e ] On PSP v13.x ASICs, boot loader will set only the MSB to 1 and clear the least significant bits for any command submission. Hence match against the exact register value, otherwise a register value of all 0xFFs also could falsely indicate that boot loader is ready. Also, from PSP v13.0.6 and newer, bits[7:0] will be used to indicate command error status. Signed-off-by: Lijo Lazar <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Srinivasan Shanmugam <[email protected]> Date: Sun Jul 23 12:29:14 2023 +0530 drm/amdgpu: Update min() to min_t() in 'amdgpu_info_ioctl' [ Upstream commit a0cc8e1512ad72c9f97cdcb76d42715730adaf62 ] Fixes the following: WARNING: min() should probably be min_t(size_t, size, sizeof(ip)) + ret = copy_to_user(out, &ip, min((size_t)size, sizeof(ip))); And other style fixes: WARNING: Prefer 'unsigned int' to bare use of 'unsigned' WARNING: Missing a blank line after declarations Cc: Christian König <[email protected]> Cc: Alex Deucher <[email protected]> Signed-off-by: Srinivasan Shanmugam <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ilpo Järvinen <[email protected]> Date: Mon Jul 17 15:04:57 2023 +0300 drm/amdgpu: Use RMW accessors for changing LNKCTL [ Upstream commit ce7d88110b9ed5f33fe79ea6d4ed049fb0e57bce ] Don't assume that only the driver would be accessing LNKCTL. ASPM policy changes can trigger write to LNKCTL outside of driver's control. And in the case of upstream bridge, the driver does not even own the device it's changing the registers for. Use RMW capability accessors which do proper locking to avoid losing concurrent updates to the register value. Suggested-by: Lukas Wunner <[email protected]> Fixes: a2e73f56fa62 ("drm/amdgpu: Add support for CIK parts") Fixes: 62a37553414a ("drm/amdgpu: add si implementation v10") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Geert Uytterhoeven <[email protected]> Date: Mon Jul 17 15:25:40 2023 +0200 drm/armada: Fix off-by-one error in armada_overlay_get_property() [ Upstream commit 5f0d984053f74983a287100a9519b2fabb785fb5 ] As ffs() returns one more than the index of the first bit set (zero means no bits set), the color key mode value is shifted one position too much. Fix this by using FIELD_GET() instead. Fixes: c96103b6c49ff9a8 ("drm/armada: move colorkey properties into overlay plane state") Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Russell King (Oracle) <[email protected]> Signed-off-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/a4d779d954a7515ddbbf31cb0f0d8184c0e7c879.1689600265.git.geert+renesas@glider.be Signed-off-by: Sasha Levin <[email protected]>
Author: Jocelyn Falempe <[email protected]> Date: Thu Jul 13 15:41:31 2023 +0200 drm/ast: report connection status on Display Port. [ Upstream commit f81bb0ac7872893241319ea82504956676ef02fd ] Aspeed always report the display port as "connected", because it doesn't set a .detect_ctx callback. Fix this by providing the proper detect callback for astdp and dp501. This also fixes the following regression: Since commit fae7d186403e ("drm/probe-helper: Default to 640x480 if no EDID on DP") The default resolution is now 640x480 when no monitor is connected. But Aspeed graphics is mostly used in servers, where no monitor is attached. This also affects the remote BMC resolution to 640x480, which is inconvenient, and breaks the anaconda installer. v2: Add .detect callback to the dp/dp501 connector (Jani Nikula) v3: Use .detect_ctx callback, and refactors (Thomas Zimmermann) Add a BMC virtual connector v4: Better indent detect_ctx() functions (Thomas Zimmermann) v5: Enable polling of the dp and dp501 connector status (Thomas Zimmermann) v6: Change check order in ast_astdp_is_connected (Jammy Huang) Fixes: fae7d186403e ("drm/probe-helper: Default to 640x480 if no EDID on DP") Signed-off-by: Jocelyn Falempe <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Chen-Yu Tsai <[email protected]> Date: Mon Jul 10 17:09:27 2023 +0800 drm/bridge: anx7625: Use common macros for DP power sequencing commands [ Upstream commit 2ba776f903cb7157e80b5f314fb0b4faf6ea6958 ] The DRM DP code has macros for the DP power sequencing commands. Use them in the anx7625 driver instead of raw numbers. Fixes: 548b512e144f ("drm/bridge: anx7625: send DPCD command to downstream") Fixes: 27f26359de9b ("drm/bridge: anx7625: Set downstream sink into normal status") Signed-off-by: Chen-Yu Tsai <[email protected]> Reviewed-by: NÃcolas F. R. A. Prado <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Chen-Yu Tsai <[email protected]> Date: Mon Jul 10 17:12:01 2023 +0800 drm/bridge: anx7625: Use common macros for HDCP capabilities [ Upstream commit 41639b3a8b0f1f194dfe0577d99db70613f78626 ] The DRM DP code has macros for the DP HDCP capabilities. Use them in the anx7625 driver instead of raw numbers. Fixes: cd1637c7e480 ("drm/bridge: anx7625: add HDCP support") Suggested-by: NÃcolas F. R. A. Prado <[email protected]> Signed-off-by: Chen-Yu Tsai <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Marek Vasut <[email protected]> Date: Thu Jun 15 17:28:17 2023 +0200 drm/bridge: tc358764: Fix debug print parameter order [ Upstream commit 7f947be02aab5b154427cb5b0fffe858fc387b02 ] The debug print parameters were swapped in the output and they were printed as decimal values, both the hardware address and the value. Update the debug print to print the parameters in correct order, and use hexadecimal print for both address and value. Fixes: f38b7cca6d0e ("drm/bridge: tc358764: Add DSI to LVDS bridge driver") Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Lucas Stach <[email protected]> Date: Fri Apr 14 16:38:10 2023 +0200 drm/etnaviv: fix dumping of active MMU context [ Upstream commit 20faf2005ec85fa1a6acc9a74ff27de667f90576 ] gpu->mmu_context is the MMU context of the last job in the HW queue, which isn't necessarily the same as the context from the bad job. Dump the MMU context from the scheduler determined bad submit to make it work as intended. Fixes: 17e4660ae3d7 ("drm/etnaviv: implement per-process address spaces on MMUv2") Signed-off-by: Lucas Stach <[email protected]> Reviewed-by: Christian Gmeiner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sui Jingfeng <[email protected]> Date: Sun Jul 9 18:05:14 2023 +0800 drm/hyperv: Fix a compilation issue because of not including screen_info.h [ Upstream commit 8d1077cf2e43b15fefd76ebec2b71541eb27ef2c ] Fixes the following build errors on arm64: drivers/video/fbdev/hyperv_fb.c: In function 'hvfb_getmem': >> drivers/video/fbdev/hyperv_fb.c:1033:24: error: 'screen_info' undeclared (first use in this function) 1033 | base = screen_info.lfb_base; | ^~~~~~~~~~~ drivers/video/fbdev/hyperv_fb.c:1033:24: note: each undeclared identifier is reported only once for each function it appears in >> drivers/gpu/drm/hyperv/hyperv_drm_drv.c:75:54: error: 'screen_info' undeclared (first use in this function) 75 | drm_aperture_remove_conflicting_framebuffers(screen_info.lfb_base, | ^~~~~~~~~~~ drivers/gpu/drm/hyperv/hyperv_drm_drv.c:75:54: note: each undeclared identifier is reported only once for each function it appears in Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Fixes: 81d2393485f0 ("fbdev/hyperv-fb: Do not set struct fb_info.apertures") Fixes: 8b0d13545b09 ("efi: Do not include <linux/screen_info.h> from EFI header") Signed-off-by: Sui Jingfeng <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Jason-JH.Lin <[email protected]> Date: Fri Jul 14 17:49:06 2023 +0800 drm/mediatek: Add cnt checking for coverity issue [ Upstream commit d761b9450e31e5abd212f0085d424ed32760de5a ] CERT-C Characters and Strings (CERT STR31-C) all_drm_priv[cnt] evaluates to an address that could be at negative offset of an array. In mtk_drm_get_all_drm_priv(): Guarantee that storage for strings has sufficient space for character data and the null terminator. So change cnt to unsigned int and check its max value. Fixes: 1ef7ed48356c ("drm/mediatek: Modify mediatek-drm for mt8195 multi mmsys support") Signed-off-by: Jason-JH.Lin <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: CK Hu <[email protected]> Reviewed-by: Alexandre Mergnat <[email protected]> Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/ Signed-off-by: Chun-Kuang Hu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: AngeloGioacchino Del Regno <[email protected]> Date: Tue Jul 25 09:32:24 2023 +0200 drm/mediatek: dp: Add missing error checks in mtk_dp_parse_capabilities [ Upstream commit cfc146137a9f12e883ba64bc496b6da4d23f26d5 ] If reading the RX capabilities fails the training pattern will be set wrongly: add error checking for drm_dp_read_dpcd_caps() and return if anything went wrong with it. While at it, also add a less critical error check when writing to clear the ESI0 IRQ vector. Fixes: f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort driver") Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Tested-by: Chen-Yu Tsai <[email protected]> Reviewed-by: Alexandre Mergnat <[email protected]> Reviewed-by: CK Hu <[email protected]> Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/ Signed-off-by: Chun-Kuang Hu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sui Jingfeng <[email protected]> Date: Thu Jul 6 21:40:00 2023 +0800 drm/mediatek: Fix potential memory leak if vmap() fail [ Upstream commit 379091e0f6d179d1a084c65de90fa44583b14a70 ] Also return -ENOMEM if such a failure happens, the implement should take responsibility for the error handling. Fixes: 3df64d7b0a4f ("drm/mediatek: Implement gem prime vmap/vunmap function") Reviewed-by: Matthias Brugger <[email protected]> Reviewed-by: Alexandre Mergnat <[email protected]> Signed-off-by: Sui Jingfeng <[email protected]> Reviewed-by: CK Hu <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/ Signed-off-by: Chun-Kuang Hu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nancy.Lin <[email protected]> Date: Thu Aug 3 17:48:43 2023 +0800 drm/mediatek: Fix uninitialized symbol [ Upstream commit 63ee9438f2aeffb2d1b2df2599c168ca08d35025 ] Fix Smatch static checker warning -Fix uninitialized symbol comp_pdev in mtk_ddp_comp_init. Fixes: 0d9eee9118b7 ("drm/mediatek: Add drm ovl_adaptor sub driver for MT8195") Signed-off-by: Nancy.Lin <[email protected]> Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/ Signed-off-by: Chun-Kuang Hu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jason-JH.Lin <[email protected]> Date: Wed Jun 21 15:54:21 2023 +0800 drm/mediatek: Fix void-pointer-to-enum-cast warning [ Upstream commit 89cba955f879b1c6a9a71f67c8fb92ea8f5dfdc4 ] 1. Fix build warning message in mtk_disp_ovl_adaptor.c >> drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c:415:10: warning: cast to smaller integer type 'enum mtk_ovl_adaptor_comp_type' from 'const void *' [-Wvoid-pointer-to-enum-cast] type = (enum mtk_ovl_adaptor_comp_type)of_id->data; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 warning generated. 2. Also fix the same warning message in mtk_drm_drv.c >> drivers/gpu/drm/mediatek/mtk_drm_drv.c:832:15: warning: cast to smaller integer type 'enum mtk_ddp_comp_type' from 'const void *' [-Wvoid-pointer-to-enum-cast] comp_type = (enum mtk_ddp_comp_type)of_id->data; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 warning generated. Signed-off-by: Jason-JH.Lin <[email protected]> Fixes: 453c3364632a ("drm/mediatek: Add ovl_adaptor support for MT8195") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Reviewed-by: CK Hu <[email protected]> Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/ Signed-off-by: Chun-Kuang Hu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jason-JH.Lin <[email protected]> Date: Fri Jul 14 17:49:05 2023 +0800 drm/mediatek: Remove freeing not dynamic allocated memory [ Upstream commit 27b9e2ea3f2757da26bb8280e46f7fdbb1acb219 ] Fixing the coverity issue of: mtk_drm_cmdq_pkt_destroy frees address of mtk_crtc->cmdq_handle So remove the free function. Fixes: 7627122fd1c0 ("drm/mediatek: Add cmdq_handle in mtk_crtc") Signed-off-by: Jason-JH.Lin <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: CK Hu <[email protected]> Reviewed-by: Alexandre Mergnat <[email protected]> Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/ Signed-off-by: Chun-Kuang Hu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Fabio Estevam <[email protected]> Date: Tue Jun 20 20:23:19 2023 -0300 drm/msm/a2xx: Call adreno_gpu_init() earlier [ Upstream commit db07ce5da8b26bfeaf437a676ae49bd3bb1eace6 ] The adreno_is_a20x() and adreno_is_a225() functions rely on the GPU revision, but such information is retrieved inside adreno_gpu_init(), which is called afterwards. Fix this problem by caling adreno_gpu_init() earlier, so that the GPU information revision is available when adreno_is_a20x() and adreno_is_a225() run. Tested on a imx53-qsb board. Fixes: 21af872cd8c6 ("drm/msm/adreno: add a2xx") Signed-off-by: Fabio Estevam <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/543456/ Signed-off-by: Rob Clark <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rob Clark <[email protected]> Date: Thu Aug 3 10:34:28 2023 -0700 drm/msm/a6xx: Fix GMU lockdep splat [ Upstream commit 3136a0f83519076edfbc14be65f286785434189a ] For normal GPU devfreq, we need to acquire the GMU lock while already holding devfreq locks. But in the teardown path, we were calling dev_pm_domain_detach() while already holding the GMU lock, resulting in this lockdep splat: ====================================================== WARNING: possible circular locking dependency detected 6.4.3-debug+ #3 Not tainted ------------------------------------------------------ ring0/391 is trying to acquire lock: ffffff80a025c078 (&devfreq->lock){+.+.}-{3:3}, at: qos_notifier_call+0x30/0x74 but task is already holding lock: ffffff809b8c1ce8 (&(c->notifiers)->rwsem){++++}-{3:3}, at: blocking_notifier_call_chain+0x34/0x78 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 (&(c->notifiers)->rwsem){++++}-{3:3}: down_write+0x58/0x74 __blocking_notifier_chain_register+0x64/0x84 blocking_notifier_chain_register+0x1c/0x28 freq_qos_add_notifier+0x5c/0x7c dev_pm_qos_add_notifier+0xd4/0xf0 devfreq_add_device+0x42c/0x560 devm_devfreq_add_device+0x6c/0xb8 msm_devfreq_init+0xa8/0x16c [msm] msm_gpu_init+0x368/0x54c [msm] adreno_gpu_init+0x248/0x2b0 [msm] a6xx_gpu_init+0x2d0/0x384 [msm] adreno_bind+0x264/0x2bc [msm] component_bind_all+0x124/0x1f4 msm_drm_bind+0x2d0/0x5f4 [msm] try_to_bring_up_aggregate_device+0x88/0x1a4 __component_add+0xd4/0x128 component_add+0x1c/0x28 dp_display_probe+0x37c/0x3c0 [msm] platform_probe+0x70/0xc0 really_probe+0x148/0x280 __driver_probe_device+0xfc/0x114 driver_probe_device+0x44/0x100 __device_attach_driver+0x64/0xdc bus_for_each_drv+0xb0/0xd8 __device_attach+0xe4/0x140 device_initial_probe+0x1c/0x28 bus_probe_device+0x44/0xb0 deferred_probe_work_func+0xb0/0xc8 process_one_work+0x288/0x3d8 worker_thread+0x1f0/0x260 kthread+0xf0/0x100 ret_from_fork+0x10/0x20 -> #3 (dev_pm_qos_mtx){+.+.}-{3:3}: __mutex_lock+0xc8/0x388 mutex_lock_nested+0x2c/0x38 dev_pm_qos_remove_notifier+0x3c/0xc8 genpd_remove_device+0x40/0x11c genpd_dev_pm_detach+0x88/0x130 dev_pm_domain_detach+0x2c/0x3c a6xx_gmu_remove+0x44/0xdc [msm] a6xx_destroy+0x7c/0xa4 [msm] adreno_unbind+0x50/0x64 [msm] component_unbind+0x44/0x64 component_unbind_all+0xb4/0xbc msm_drm_uninit.isra.0+0x124/0x17c [msm] msm_drm_bind+0x340/0x5f4 [msm] try_to_bring_up_aggregate_device+0x88/0x1a4 __component_add+0xd4/0x128 component_add+0x1c/0x28 dp_display_probe+0x37c/0x3c0 [msm] platform_probe+0x70/0xc0 really_probe+0x148/0x280 __driver_probe_device+0xfc/0x114 driver_probe_device+0x44/0x100 __device_attach_driver+0x64/0xdc bus_for_each_drv+0xb0/0xd8 __device_attach+0xe4/0x140 device_initial_probe+0x1c/0x28 bus_probe_device+0x44/0xb0 deferred_probe_work_func+0xb0/0xc8 process_one_work+0x288/0x3d8 worker_thread+0x1f0/0x260 kthread+0xf0/0x100 ret_from_fork+0x10/0x20 -> #2 (&a6xx_gpu->gmu.lock){+.+.}-{3:3}: __mutex_lock+0xc8/0x388 mutex_lock_nested+0x2c/0x38 a6xx_gpu_set_freq+0x38/0x64 [msm] msm_devfreq_target+0x170/0x18c [msm] devfreq_set_target+0x90/0x1e4 devfreq_update_target+0xb4/0xf0 update_devfreq+0x1c/0x28 devfreq_monitor+0x3c/0x10c process_one_work+0x288/0x3d8 worker_thread+0x1f0/0x260 kthread+0xf0/0x100 ret_from_fork+0x10/0x20 -> #1 (&df->lock){+.+.}-{3:3}: __mutex_lock+0xc8/0x388 mutex_lock_nested+0x2c/0x38 msm_devfreq_get_dev_status+0x4c/0x104 [msm] devfreq_simple_ondemand_func+0x5c/0x128 devfreq_update_target+0x68/0xf0 update_devfreq+0x1c/0x28 devfreq_monitor+0x3c/0x10c process_one_work+0x288/0x3d8 worker_thread+0x1f0/0x260 kthread+0xf0/0x100 ret_from_fork+0x10/0x20 -> #0 (&devfreq->lock){+.+.}-{3:3}: __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 __mutex_lock+0xc8/0x388 mutex_lock_nested+0x2c/0x38 qos_notifier_call+0x30/0x74 qos_min_notifier_call+0x1c/0x28 notifier_call_chain+0xf4/0x114 blocking_notifier_call_chain+0x4c/0x78 pm_qos_update_target+0x184/0x190 freq_qos_apply+0x4c/0x64 apply_constraint+0xf8/0xfc __dev_pm_qos_update_request+0x138/0x164 dev_pm_qos_update_request+0x44/0x68 msm_devfreq_boost+0x40/0x70 [msm] msm_devfreq_active+0xc0/0xf0 [msm] msm_gpu_submit+0xc8/0x12c [msm] msm_job_run+0x88/0x128 [msm] drm_sched_main+0x240/0x324 [gpu_sched] kthread+0xf0/0x100 ret_from_fork+0x10/0x20 other info that might help us debug this: Chain exists of: &devfreq->lock --> dev_pm_qos_mtx --> &(c->notifiers)->rwsem Possible unsafe locking scenario: CPU0 CPU1 ---- ---- rlock(&(c->notifiers)->rwsem); lock(dev_pm_qos_mtx); lock(&(c->notifiers)->rwsem); lock(&devfreq->lock); *** DEADLOCK *** 4 locks held by ring0/391: #0: ffffff809c811170 (&gpu->lock){+.+.}-{3:3}, at: msm_job_run+0x7c/0x128 [msm] #1: ffffff809c811208 (&gpu->active_lock){+.+.}-{3:3}, at: msm_gpu_submit+0xa8/0x12c [msm] #2: ffffffecbbb46600 (dev_pm_qos_mtx){+.+.}-{3:3}, at: dev_pm_qos_update_request+0x38/0x68 #3: ffffff809b8c1ce8 (&(c->notifiers)->rwsem){++++}-{3:3}, at: blocking_notifier_call_chain+0x34/0x78 stack backtrace: CPU: 6 PID: 391 Comm: ring0 Not tainted 6.4.3debug+ #3 Hardware name: Google Villager (rev1+) with LTE (DT) Call trace: dump_backtrace+0xb4/0xf0 show_stack+0x20/0x30 dump_stack_lvl+0x60/0x84 dump_stack+0x18/0x24 print_circular_bug+0x1cc/0x234 check_noncircular+0x78/0xac __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 __mutex_lock+0xc8/0x388 mutex_lock_nested+0x2c/0x38 qos_notifier_call+0x30/0x74 qos_min_notifier_call+0x1c/0x28 notifier_call_chain+0xf4/0x114 blocking_notifier_call_chain+0x4c/0x78 pm_qos_update_target+0x184/0x190 freq_qos_apply+0x4c/0x64 apply_constraint+0xf8/0xfc __dev_pm_qos_update_request+0x138/0x164 dev_pm_qos_update_request+0x44/0x68 msm_devfreq_boost+0x40/0x70 [msm] msm_devfreq_active+0xc0/0xf0 [msm] msm_gpu_submit+0xc8/0x12c [msm] msm_job_run+0x88/0x128 [msm] drm_sched_main+0x240/0x324 [gpu_sched] kthread+0xf0/0x100 ret_from_fork+0x10/0x20 Fix this by only synchronizing access to gmu->initialized. Fixes: 4cd15a3e8b36 ("drm/msm/a6xx: Make GPU destroy a bit safer") Cc: Douglas Anderson <[email protected]> Signed-off-by: Rob Clark <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/551171/ Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Fri Apr 21 01:25:57 2023 +0300 drm/msm/dpu: drop the regdma configuration [ Upstream commit 078f766e165097c03629cc1a8f7e1a7b7ec0e79b ] The regdma is currently not used by the current driver. We have no way to practically verify that the regdma is described correctly. Drop it now. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Marijn Suijten <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/533148/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Stable-dep-of: 42d0d253ed03 ("drm/msm/dpu: increase memtype count to 16 for sm8550") Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Wed Aug 2 13:04:19 2023 +0300 drm/msm/dpu: fix the irq index in dpu_encoder_phys_wb_wait_for_commit_done [ Upstream commit d93cf453f51da168f4410ba73656f1e862096973 ] Since commit 1e7ac595fa46 ("drm/msm/dpu: pass irq to dpu_encoder_helper_wait_for_irq()") the dpu_encoder_phys_wb_wait_for_commit_done expects the IRQ index rather than the IRQ index in phys_enc->intr table, however writeback got the older invocation in place. This was unnoticed for several releases, but now it's time to fix it. Fixes: d7d0e73f7de3 ("drm/msm/dpu: introduce the dpu_encoder_phys_* for writeback") Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/550924/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Jonathan Marek <[email protected]> Date: Wed Aug 2 09:48:53 2023 -0400 drm/msm/dpu: increase memtype count to 16 for sm8550 [ Upstream commit 42d0d253ed03b961c325ff756eec0480cb4adc6b ] sm8550 has 16 vbif clients. This fixes the extra 2 clients (DMA4/DMA5) not having their memtype initialized. This fixes DMA4/DMA5 planes not displaying correctly. Fixes: efcd0107727c ("drm/msm/dpu: add support for SM8550") Signed-off-by: Jonathan Marek <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Tested-by: Neil Armstrong <[email protected]> # on SM8550-QRD Patchwork: https://patchwork.freedesktop.org/patch/550968/ Link: https://lore.kernel.org/r/[email protected] [DB: fixed the Fixes tag] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Vetter <[email protected]> Date: Thu Aug 3 22:45:21 2023 +0200 drm/msm/mdp5: Don't leak some plane state [ Upstream commit fd0ad3b2365c1c58aa5a761c18efc4817193beb6 ] Apparently no one noticed that mdp5 plane states leak like a sieve ever since we introduced plane_state->commit refcount a few years ago in 21a01abbe32a ("drm/atomic: Fix freeing connector/plane state too early by tracking commits, v3.") Fix it by using the right helpers. Fixes: 21a01abbe32a ("drm/atomic: Fix freeing connector/plane state too early by tracking commits, v3.") Cc: Maarten Lankhorst <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Rob Clark <[email protected]> Cc: Abhinav Kumar <[email protected]> Cc: Dmitry Baryshkov <[email protected]> Cc: [email protected] Cc: [email protected] Reported-and-tested-by: [email protected] Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]> Reviewed-by: Rob Clark <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/551236/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ryan McCann <[email protected]> Date: Fri Jul 7 18:24:40 2023 -0700 drm/msm: Update dev core dump to not print backwards [ Upstream commit 903705111d863ed8ccf73465da77d232fc422ec1 ] Device core dump add block method adds hardware blocks to dumping queue with stack behavior which causes the hardware blocks to be printed in reverse order. Change the addition to dumping queue data structure from "list_add" to "list_add_tail" for FIFO queue behavior. Fixes: 98659487b845 ("drm/msm: add support to take dpu snapshot") Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Signed-off-by: Ryan McCann <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/546200/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marek Vasut <[email protected]> Date: Sun Jul 9 15:49:14 2023 +0200 drm/panel: simple: Add missing connector type and pixel format for AUO T215HVN01 [ Upstream commit 7a675a8fa598edb29a664a91adb80f0340649f6f ] The connector type and pixel format are missing for this panel, add them to prevent various drivers from failing to determine either of those parameters. Fixes: 7ee933a1d5c4 ("drm/panel: simple: Add support for AUO T215HVN01") Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Ilpo Järvinen <[email protected]> Date: Mon Jul 17 15:04:58 2023 +0300 drm/radeon: Use RMW accessors for changing LNKCTL [ Upstream commit 7189576e8a829130192b33c5b64e8a475369c776 ] Don't assume that only the driver would be accessing LNKCTL. ASPM policy changes can trigger write to LNKCTL outside of driver's control. And in the case of upstream bridge, the driver does not even own the device it's changing the registers for. Use RMW capability accessors which do proper locking to avoid losing concurrent updates to the register value. Suggested-by: Lukas Wunner <[email protected]> Fixes: 8a7cd27679d0 ("drm/radeon/cik: add support for pcie gen1/2/3 switching") Fixes: b9d305dfb66c ("drm/radeon: implement pcie gen2/3 support for SI") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Geert Uytterhoeven <[email protected]> Date: Thu Mar 17 09:18:30 2022 +0100 drm/repaper: Reduce temporary buffer size in repaper_fb_dirty() [ Upstream commit fedf429e071f6dbbe7a69dfc342492e037692018 ] As the temporary buffer is no longer used to store 8-bit grayscale data, its size can be reduced to the size needed to store the monochrome bitmap data. Fixes: 24c6bedefbe71de9 ("drm/repaper: Use format helper for xrgb8888 to monochrome conversion") Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Yangtao Li <[email protected]> Date: Mon Jul 10 11:23:49 2023 +0800 drm/tegra: dpaux: Fix incorrect return value of platform_get_irq [ Upstream commit 2a1ca44b654346cadfc538c4fb32eecd8daf3140 ] When platform_get_irq fails, we should return dpaux->irq instead of -ENXIO. Fixes: 6b6b604215c6 ("drm/tegra: Add eDP support") Signed-off-by: Yangtao Li <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Bogdan Togorean <[email protected]> Date: Wed Jul 19 09:01:43 2023 +0300 drm: adv7511: Fix low refresh rate register for ADV7533/5 [ Upstream commit d281eeaa4de2636ff0c8e6ae387bb07b50e5fcbb ] For ADV7533 and ADV7535 low refresh rate is selected using bits [3:2] of 0x4a main register. So depending on ADV model write 0xfb or 0x4a register. Fixes: 2437e7cd88e8 ("drm/bridge: adv7533: Initial support for ADV7533") Reviewed-by: Robert Foss <[email protected]> Reviewed-by: Nuno Sa <[email protected]> Signed-off-by: Bogdan Togorean <[email protected]> Signed-off-by: Alexandru Ardelean <[email protected]> Reviewed-by: Frieder Schrempf <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Ondrej Jirman <[email protected]> Date: Sun Jun 18 00:48:25 2023 +0200 drm: bridge: dw-mipi-dsi: Fix enable/disable of DSI controller [ Upstream commit 05aa61334592adb230749ff465b103ee10e63936 ] Before this patch, booting to Linux VT and doing a simple: echo 2 > /sys/class/graphics/fb0/blank echo 0 > /sys/class/graphics/fb0/blank would result in failures to re-enable the panel. Mode set callback is called only once during boot in this scenario, while calls to enable/disable callbacks are balanced afterwards. The driver doesn't work unless userspace calls modeset before enabling the CRTC/connector. This patch moves enabling of the DSI host from mode_set into pre_enable callback, and removes some old hacks where this bridge driver is directly calling into other bridge driver's callbacks. pre_enable_prev_first flag is set on the panel's bridge so that panel drivers will get their prepare function called between DSI host's pre_enable and enable callbacks, so that they get a chance to perform panel setup while DSI host is already enabled in command mode. Otherwise panel's prepare would be called before DSI host is enabled, and any DSI communication used in prepare callback would fail. With all these changes, the enable/disable sequence is now well balanced, and host's and panel's callbacks are called in proper order documented in the drm_panel API documentation without needing the old hacks. (Mainly that panel->prepare is called when DSI host is ready to allow the panel driver to send DSI commands and vice versa during disable.) Tested on Pinephone Pro. Trace of the callbacks follows. Before: [ 1.253882] dw-mipi-dsi-rockchip ff960000.dsi: mode_set [ 1.290732] panel-himax-hx8394 ff960000.dsi.0: prepare [ 1.475576] dw-mipi-dsi-rockchip ff960000.dsi: enable [ 1.475593] panel-himax-hx8394 ff960000.dsi.0: enable echo 2 > /sys/class/graphics/fb0/blank [ 13.722799] panel-himax-hx8394 ff960000.dsi.0: disable [ 13.774502] dw-mipi-dsi-rockchip ff960000.dsi: post_disable [ 13.774526] panel-himax-hx8394 ff960000.dsi.0: unprepare echo 0 > /sys/class/graphics/fb0/blank [ 17.735796] panel-himax-hx8394 ff960000.dsi.0: prepare [ 17.923522] dw-mipi-dsi-rockchip ff960000.dsi: enable [ 17.923540] panel-himax-hx8394 ff960000.dsi.0: enable [ 17.944330] dw-mipi-dsi-rockchip ff960000.dsi: failed to write command FIFO [ 17.944335] panel-himax-hx8394 ff960000.dsi.0: sending command 0xb9 failed: -110 [ 17.944340] panel-himax-hx8394 ff960000.dsi.0: Panel init sequence failed: -110 echo 2 > /sys/class/graphics/fb0/blank [ 431.148583] panel-himax-hx8394 ff960000.dsi.0: disable [ 431.169259] dw-mipi-dsi-rockchip ff960000.dsi: failed to write command FIFO [ 431.169268] panel-himax-hx8394 ff960000.dsi.0: Failed to enter sleep mode: -110 [ 431.169282] dw-mipi-dsi-rockchip ff960000.dsi: post_disable [ 431.169316] panel-himax-hx8394 ff960000.dsi.0: unprepare [ 431.169357] pclk_mipi_dsi0 already disabled echo 0 > /sys/class/graphics/fb0/blank [ 432.796851] panel-himax-hx8394 ff960000.dsi.0: prepare [ 432.981537] dw-mipi-dsi-rockchip ff960000.dsi: enable [ 432.981568] panel-himax-hx8394 ff960000.dsi.0: enable [ 433.002290] dw-mipi-dsi-rockchip ff960000.dsi: failed to write command FIFO [ 433.002299] panel-himax-hx8394 ff960000.dsi.0: sending command 0xb9 failed: -110 [ 433.002312] panel-himax-hx8394 ff960000.dsi.0: Panel init sequence failed: -110 ----------------------------------------------------------------------- After: [ 1.248372] dw-mipi-dsi-rockchip ff960000.dsi: mode_set [ 1.248704] dw-mipi-dsi-rockchip ff960000.dsi: pre_enable [ 1.285377] panel-himax-hx8394 ff960000.dsi.0: prepare [ 1.468392] dw-mipi-dsi-rockchip ff960000.dsi: enable [ 1.468421] panel-himax-hx8394 ff960000.dsi.0: enable echo 2 > /sys/class/graphics/fb0/blank [ 16.210357] panel-himax-hx8394 ff960000.dsi.0: disable [ 16.261315] dw-mipi-dsi-rockchip ff960000.dsi: post_disable [ 16.261339] panel-himax-hx8394 ff960000.dsi.0: unprepare echo 0 > /sys/class/graphics/fb0/blank [ 19.161453] dw-mipi-dsi-rockchip ff960000.dsi: pre_enable [ 19.197869] panel-himax-hx8394 ff960000.dsi.0: prepare [ 19.382141] dw-mipi-dsi-rockchip ff960000.dsi: enable [ 19.382158] panel-himax-hx8394 ff960000.dsi.0: enable (But depends on functionality intorduced in Linux 6.3, so this patch will not build on older kernels when applied to older stable branches.) Fixes: 46fc51546d44 ("drm/bridge/synopsys: Add MIPI DSI host controller bridge") Signed-off-by: Ondrej Jirman <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Jiasheng Jiang <[email protected]> Date: Wed Jun 7 10:05:29 2023 +0800 drm: xlnx: zynqmp_dpsub: Add missing check for dma_set_mask [ Upstream commit 1832fba7f9780aff67c96ad30f397c2d76141833 ] Add check for dma_set_mask() and return the error if it fails. Fixes: d76271d22694 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort Subsystem") Signed-off-by: Jiasheng Jiang <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Mon Jun 26 19:48:07 2023 +0200 dt-bindings: clock: qcom,gcc-sc8280xp: Add missing GDSCs [ Upstream commit 9eba4db02a88e7a810aabd70f7a6960f184f391f ] There are 10 more GDSCs that we've not been caring about, and by extension (and perhaps even more importantly), not putting to sleep. Add them. Fixes: a66a82f2a55e ("dt-bindings: clock: Add Qualcomm SC8280XP GCC bindings") Acked-by: Rob Herring <[email protected]> Signed-off-by: Konrad Dybcio <[email protected]> Acked-by: Manivannan Sadhasivam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Imran Shaik <[email protected]> Date: Thu Aug 3 16:27:34 2023 +0530 dt-bindings: clock: Update GCC clocks for QDU1000 and QRU1000 SoCs [ Upstream commit df873243b2398a082d34a006bebe0e0ed7538f5c ] Add support for GCC_GPLL1_OUT_EVEN and GCC_DDRSS_ECPRI_GSI_CLK clock bindings for QDU1000 and QRU1000 SoCs. While at it, update the maintainers list. Signed-off-by: Imran Shaik <[email protected]> Acked-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Stable-dep-of: 06d71fa10f2e ("clk: qcom: gcc-qdu1000: Register gcc_gpll1_out_even clock") Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Thu Jul 20 10:01:40 2023 +0200 dt-bindings: extcon: maxim,max77843: restrict connector properties [ Upstream commit fb2c3f72e819254d8c76de95917e5f9ff232586c ] Do not allow any other properties in connector child, except what usb-connector.yaml evaluates. Fixes: 9729cad0278b ("dt-bindings: extcon: maxim,max77843: Add MAX77843 bindings") Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Qiuxu Zhuo <[email protected]> Date: Mon Jul 10 09:32:32 2023 +0800 EDAC/i10nm: Skip the absent memory controllers [ Upstream commit c545f5e412250555bd4e717d062b117f20bab418 ] Some Sapphire Rapids workstations' absent memory controllers still appear as PCIe devices that fool the i10nm_edac driver and result in "shift exponent -66 is negative" call traces from skx_get_dimm_info(). Skip the absent memory controllers to avoid the call traces. Reported-by: Kai-Heng Feng <[email protected]> Closes: https://lore.kernel.org/linux-edac/CAAd53p41Ku1m1rapeqb1xtD+kKuk+BaUW=dumuoF0ZO3GhFjFA@mail.gmail.com/T/#m5de16dce60a8c836ec235868c7c16e3fefad0cc2 Tested-by: Kai-Heng Feng <[email protected]> Reported-by: Koba Ko <[email protected]> Closes: https://lore.kernel.org/linux-edac/SA1PR11MB71305B71CCCC3D9305835202892AA@SA1PR11MB7130.namprd11.prod.outlook.com/T/#t Tested-by: Koba Ko <[email protected]> Fixes: d4dc89d069aa ("EDAC, i10nm: Add a driver for Intel 10nm server processors") Signed-off-by: Qiuxu Zhuo <[email protected]> Signed-off-by: Tony Luck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Qiuxu Zhuo <[email protected]> Date: Tue Jul 25 16:04:27 2023 +0800 EDAC/igen6: Fix the issue of no error events [ Upstream commit ce53ad81ed36c24aff075f94474adecfabfcf239 ] Current igen6_edac checks for pending errors before the registration of the error handler. However, there is a possibility that the error occurs during the registration process, leading to unhandled pending errors and no future error events. This issue can be reproduced by repeatedly injecting errors during the loading of the igen6_edac. Fix this issue by moving the pending error handler after the registration of the error handler, ensuring that no pending errors are left unhandled. Fixes: 10590a9d4f23 ("EDAC/igen6: Add EDAC driver for Intel client SoCs using IBECC") Reported-by: Ee Wey Lim <[email protected]> Tested-by: Ee Wey Lim <[email protected]> Signed-off-by: Qiuxu Zhuo <[email protected]> Signed-off-by: Tony Luck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Yuanjun Gong <[email protected]> Date: Thu Jul 20 22:42:08 2023 +0800 ethernet: atheros: fix return value check in atl1c_tso_csum() [ Upstream commit 8d01da0a1db237c44c92859ce3612df7af8d3a53 ] in atl1c_tso_csum, it should check the return value of pskb_trim(), and return an error code if an unexpected value is returned by pskb_trim(). Signed-off-by: Yuanjun Gong <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wen Yang <[email protected]> Date: Sun Jul 9 14:54:51 2023 +0800 eventfd: prevent underflow for eventfd semaphores [ Upstream commit 758b492047816a3158d027e9fca660bc5bcf20bf ] For eventfd with flag EFD_SEMAPHORE, when its ctx->count is 0, calling eventfd_ctx_do_read will cause ctx->count to overflow to ULLONG_MAX. An underflow can happen with EFD_SEMAPHORE eventfds in at least the following three subsystems: (1) virt/kvm/eventfd.c (2) drivers/vfio/virqfd.c (3) drivers/virt/acrn/irqfd.c where (2) and (3) are just modeled after (1). An eventfd must be specified for use with the KVM_IRQFD ioctl(). This can also be an EFD_SEMAPHORE eventfd. When the eventfd count is zero or has been decremented to zero an underflow can be triggered when the irqfd is shut down by raising the KVM_IRQFD_FLAG_DEASSIGN flag in the KVM_IRQFD ioctl(): // ctx->count == 0 kvm_vm_ioctl() -> kvm_irqfd() -> kvm_irqfd_deassign() -> irqfd_deactivate() -> irqfd_shutdown() -> eventfd_ctx_remove_wait_queue(&cnt) -> eventfd_ctx_do_read(&cnt) Userspace polling on the eventfd wouldn't notice the underflow because 1 is always returned as the value from eventfd_read() while ctx->count would've underflowed. It's not a huge deal because this should only be happening when the irqfd is shutdown but we should still fix it and avoid the spurious wakeup. Fixes: cb289d6244a3 ("eventfd - allow atomic read and waitqueue remove") Signed-off-by: Wen Yang <[email protected]> Cc: Alexander Viro <[email protected]> Cc: Jens Axboe <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Dylan Yudaken <[email protected]> Cc: David Woodhouse <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: [email protected] Cc: [email protected] Message-Id: <[email protected]> [brauner: rewrite commit message and add explanation how this underflow can happen] Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kemeng Shi <[email protected]> Date: Tue Aug 1 22:31:56 2023 +0800 ext4: avoid potential data overflow in next_linear_group [ Upstream commit 60c672b7f2d1e5dd1774f2399b355c9314e709f8 ] ngroups is ext4_group_t (unsigned int) while next_linear_group treat it in int. If ngroups is bigger than max number described by int, it will be treat as a negative number. Then "return group + 1 >= ngroups ? 0 : group + 1;" may keep returning 0. Switch int to ext4_group_t in next_linear_group to fix the overflow. Fixes: 196e402adf2e ("ext4: improve cr 0 / cr 1 group scanning") Signed-off-by: Kemeng Shi <[email protected]> Reviewed-by: Ritesh Harjani (IBM) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kemeng Shi <[email protected]> Date: Tue Aug 1 22:31:55 2023 +0800 ext4: correct grp validation in ext4_mb_good_group [ Upstream commit a9ce5993a0f5c0887c8a1b4ffa3b8046fbcfdc93 ] Group corruption check will access memory of grp and will trigger kernel crash if grp is NULL. So do NULL check before corruption check. Fixes: 5354b2af3406 ("ext4: allow ext4_get_group_info() to fail") Signed-off-by: Kemeng Shi <[email protected]> Reviewed-by: Ritesh Harjani (IBM) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhihao Cheng <[email protected]> Date: Wed Jun 28 21:20:11 2023 +0800 ext4: fix unttached inode after power cut with orphan file feature enabled [ Upstream commit 1524773425ae8113b0b782886366e68656b34e53 ] Running generic/475(filesystem consistent tests after power cut) could easily trigger unattached inode error while doing fsck: Unattached zero-length inode 39405. Clear? no Unattached inode 39405 Connect to /lost+found? no Above inconsistence is caused by following process: P1 P2 ext4_create inode = ext4_new_inode_start_handle // itable records nlink=1 ext4_add_nondir err = ext4_add_entry // ENOSPC ext4_append ext4_bread ext4_getblk ext4_map_blocks // returns ENOSPC drop_nlink(inode) // won't be updated into disk inode ext4_orphan_add(handle, inode) ext4_orphan_file_add ext4_journal_stop(handle) jbd2_journal_commit_transaction // commit success >> power cut << ext4_fill_super ext4_load_and_init_journal // itable records nlink=1 ext4_orphan_cleanup ext4_process_orphan if (inode->i_nlink) // true, inode won't be deleted Then, allocated inode will be reserved on disk and corresponds to no dentries, so e2fsck reports 'unattached inode' problem. The problem won't happen if orphan file feature is disabled, because ext4_orphan_add() will update disk inode in orphan list mode. There are several places not updating disk inode while putting inode into orphan area, such as ext4_add_nondir(), ext4_symlink() and whiteout in ext4_rename(). Fix it by updating inode into disk in all error branches of these places. Link: https://bugzilla.kernel.org/show_bug.cgi?id=217605 Fixes: 02f310fcf47f ("ext4: Speedup ext4 orphan inode handling") Signed-off-by: Zhihao Cheng <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnd Bergmann <[email protected]> Date: Fri Aug 4 15:28:49 2023 +0200 extcon: cht_wc: add POWER_SUPPLY dependency [ Upstream commit d20a3a8a32e3fa564ff25da860c5fc1a97642dfe ] The driver fails to link when CONFIG_POWER_SUPPLY is disabled: x86_64-linux-ld: vmlinux.o: in function `cht_wc_extcon_psy_get_prop': extcon-intel-cht-wc.c:(.text+0x15ccda7): undefined reference to `power_supply_get_drvdata' x86_64-linux-ld: vmlinux.o: in function `cht_wc_extcon_pwrsrc_event': extcon-intel-cht-wc.c:(.text+0x15cd3e9): undefined reference to `power_supply_changed' x86_64-linux-ld: vmlinux.o: in function `cht_wc_extcon_probe': extcon-intel-cht-wc.c:(.text+0x15cd596): undefined reference to `devm_power_supply_register' It should be possible to change the driver to not require this at compile time and still provide other functions, but adding a hard Kconfig dependency does not seem to have any practical downsides and is simpler since the option is normally enabled anyway. Fixes: 66e31186cd2aa ("extcon: intel-cht-wc: Add support for registering a power_supply class-device") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Randy Dunlap <[email protected]> Date: Sun Jul 9 22:23:24 2023 -0700 f2fs: fix spelling in ABI documentation [ Upstream commit c709d099a0d2befa2b16c249ef8df722b43e6c28 ] Correct spelling problems as identified by codespell. Fixes: 9e615dbba41e ("f2fs: add missing description for ipu_policy node") Fixes: b2e4a2b300e5 ("f2fs: expose discard related parameters in sysfs") Fixes: 846ae671ad36 ("f2fs: expose extension_list sysfs entry") Signed-off-by: Randy Dunlap <[email protected]> Cc: Jaegeuk Kim <[email protected]> Cc: Chao Yu <[email protected]> Cc: [email protected] Cc: Yangtao Li <[email protected]> Cc: Konstantin Vyshetsky <[email protected]> Reviewed-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chao Yu <[email protected]> Date: Tue Aug 8 08:59:49 2023 +0800 f2fs: fix to account cp stats correctly [ Upstream commit eb61c2cca2eb2110cc7b61a7bc15b3850977a778 ] cp_foreground_calls sysfs entry shows total CP call count rather than foreground CP call count, fix it. Fixes: fc7100ea2a52 ("f2fs: Add f2fs stats to sysfs") Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chao Yu <[email protected]> Date: Tue Aug 8 08:59:48 2023 +0800 f2fs: fix to account gc stats correctly [ Upstream commit 9bf1dcbdfdc8892d9cfeaeab02519c0ecf17fe51 ] As reported, status debugfs entry shows inconsistent GC stats as below: GC calls: 6008 (BG: 6161) - data segments : 3053 (BG: 3053) - node segments : 2955 (BG: 2955) Total GC calls is larger than BGGC calls, the reason is: - f2fs_stat_info.call_count accounts total migrated section count by f2fs_gc() - f2fs_stat_info.bg_gc accounts total call times of f2fs_gc() from background gc_thread Another issue is gc_foreground_calls sysfs entry shows total GC call count rather than FGGC call count. This patch changes as below for fix: - account GC calls and migrated segment count separately - support to account migrated section count if it enables large section mode - fix to show correct value in gc_foreground_calls sysfs entry Fixes: fc7100ea2a52 ("f2fs: Add f2fs stats to sysfs") Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chao Yu <[email protected]> Date: Thu Jul 6 10:06:14 2023 +0800 f2fs: fix to avoid mmap vs set_compress_option case [ Upstream commit b5ab3276eb69cacf44ecfb11b2bfab73096ff4e4 ] Compression option in inode should not be changed after they have been used, however, it may happen in below race case: Thread A Thread B - f2fs_ioc_set_compress_option - check f2fs_is_mmap_file() - check get_dirty_pages() - check F2FS_HAS_BLOCKS() - f2fs_file_mmap - set_inode_flag(FI_MMAP_FILE) - fault - do_page_mkwrite - f2fs_vm_page_mkwrite - f2fs_get_block_locked - fault_dirty_shared_page - set_page_dirty - update i_compress_algorithm - update i_log_cluster_size - update i_cluster_size Avoid such race condition by covering f2fs_file_mmap() w/ i_sem lock, meanwhile add mmap file check condition in f2fs_may_compress() as well. Fixes: e1e8debec656 ("f2fs: add F2FS_IOC_SET_COMPRESS_OPTION ioctl") Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chao Yu <[email protected]> Date: Sun May 28 15:47:12 2023 +0800 f2fs: fix to drop all dirty meta/node pages during umount() [ Upstream commit 20872584b8c0b006c007da9588a272c9e28d2e18 ] For cp error case, there will be dirty meta/node pages remained after f2fs_write_checkpoint() in f2fs_put_super(), drop them explicitly, and do sanity check on reference count of dirty pages and inflight IOs. Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Stable-dep-of: eb61c2cca2eb ("f2fs: fix to account cp stats correctly") Signed-off-by: Sasha Levin <[email protected]>
Author: Chunhai Guo <[email protected]> Date: Thu Aug 3 22:28:42 2023 +0800 f2fs: Only lfs mode is allowed with zoned block device feature [ Upstream commit 2bd4df8fcbc72f58ce3c62ed021ab291ca42de0b ] Now f2fs support four block allocation modes: lfs, adaptive, fragment:segment, fragment:block. Only lfs mode is allowed with zoned block device feature. Fixes: 6691d940b0e0 ("f2fs: introduce fragment allocation mode mount option") Signed-off-by: Chunhai Guo <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yangtao Li <[email protected]> Date: Sat May 6 23:16:03 2023 +0800 f2fs: refactor struct f2fs_attr macro [ Upstream commit 6201c478dedcf7c50361b23b5c4d4f41a68921ac ] This patch provides a large number of variants of F2FS_RW_ATTR and F2FS_RO_ATTR macros, reducing the number of parameters required to initialize the f2fs_attr structure. Reported-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Yangtao Li <[email protected]> Reviewed-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Stable-dep-of: 9bf1dcbdfdc8 ("f2fs: fix to account gc stats correctly") Signed-off-by: Sasha Levin <[email protected]>
Author: Zhu Wang <[email protected]> Date: Thu Aug 3 15:10:06 2023 +0800 fbdev: goldfishfb: Do not check 0 for platform_get_irq() [ Upstream commit 0650d5098f8b6b232cd5ea0e15437fc38f7d63ba ] Since platform_get_irq() never returned zero, so it need not to check whether it returned zero, and we use the return error code of platform_get_irq() to replace the current return error code. Please refer to the commit a85a6c86c25b ("driver core: platform: Clarify that IRQ 0 is invalid") to get that platform_get_irq() never returned zero. Signed-off-by: Zhu Wang <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vlad Karpovich <[email protected]> Date: Tue Aug 15 12:29:08 2023 -0500 firmware: cs_dsp: Fix new control name check [ Upstream commit 7ac1102b227b36550452b663fd39ab1c09378a95 ] Before adding a new FW control, its name is checked against existing controls list. But the string length in strncmp used to compare controls names is taken from the list, so if beginnings of the controls are matching, then the new control is not created. For example, if CAL_R control already exists, CAL_R_SELECTED is not created. The fix is to compare string lengths as well. Fixes: 6477960755fb ("ASoC: wm_adsp: Move check for control existence") Signed-off-by: Vlad Karpovich <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhang Shurong <[email protected]> Date: Sat Jul 15 22:13:38 2023 +0800 firmware: meson_sm: fix to avoid potential NULL pointer dereference [ Upstream commit f2ed165619c16577c02b703a114a1f6b52026df4 ] of_match_device() may fail and returns a NULL pointer. Fix this by checking the return value of of_match_device. Fixes: 8cde3c2153e8 ("firmware: meson_sm: Rework driver as a proper platform driver") Signed-off-by: Zhang Shurong <zhang_s[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Neil Armstrong <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nishanth Menon <[email protected]> Date: Tue Jun 20 08:03:29 2023 -0500 firmware: ti_sci: Use system_state to determine polling [ Upstream commit 9225bcdedf16297a346082e7d23b0e8434aa98ed ] Commit b9e8a7d950ff ("firmware: ti_sci: Switch transport to polled mode during system suspend") aims to resolve issues with tisci operations during system suspend operation. However, the system may enter a no_irq stage in various other usage modes, including power-off and restart. To determine if polling mode is appropriate, use the system_state instead. While at this, drop the unused is_suspending state variable and related helpers. Fixes: b9e8a7d950ff ("firmware: ti_sci: Switch transport to polled mode during system suspend") Reported-by: Francesco Dolcini <[email protected]> Reported-by: Wadim Egorov <[email protected]> Tested-by: Francesco Dolcini <france[email protected]> # Toradex Verdin AM62 Link: https://lore.kernel.org/r/[email protected] Closes: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Nishanth Menon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Winston Wen <[email protected]> Date: Mon Jul 24 10:10:56 2023 +0800 fs/nls: make load_nls() take a const parameter [ Upstream commit c1ed39ec116272935528ca9b348b8ee79b0791da ] load_nls() take a char * parameter, use it to find nls module in list or construct the module name to load it. This change make load_nls() take a const parameter, so we don't need do some cast like this: ses->local_nls = load_nls((char *)ctx->local_nls->charset); Suggested-by: Stephen Rothwell <[email protected]> Signed-off-by: Winston Wen <[email protected]> Reviewed-by: Paulo Alcantara <[email protected]> Reviewed-by: Christian Brauner <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wang Ming <[email protected]> Date: Thu Jul 13 20:05:42 2023 +0800 fs: Fix error checking for d_hash_and_lookup() [ Upstream commit 0d5a4f8f775ff990142cdc810a84eae078589d27 ] The d_hash_and_lookup() function returns error pointers or NULL. Most incorrect error checks were fixed, but the one in int path_pts() was forgotten. Fixes: eedf265aa003 ("devpts: Make each mount of devpts an independent filesystem.") Signed-off-by: Wang Ming <[email protected]> Message-Id: <[email protected]> Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Su Hui <[email protected]> Date: Fri Aug 4 09:26:57 2023 +0800 fs: lockd: avoid possible wrong NULL parameter [ Upstream commit de8d38cf44bac43e83bad28357ba84784c412752 ] clang's static analysis warning: fs/lockd/mon.c: line 293, column 2: Null pointer passed as 2nd argument to memory copy function. Assuming 'hostname' is NULL and calling 'nsm_create_handle()', this will pass NULL as 2nd argument to memory copy function 'memcpy()'. So return NULL if 'hostname' is invalid. Fixes: 77a3ef33e2de ("NSM: More clean up of nsm_get_handle()") Signed-off-by: Su Hui <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Artem Chernyshev <[email protected]> Date: Thu Aug 3 17:54:17 2023 +0300 fs: ocfs2: namei: check return value of ocfs2_add_entry() [ Upstream commit 6b72e5f9e79360fce4f2be7fe81159fbdf4256a5 ] Process result of ocfs2_add_entry() in case we have an error value. Found by Linux Verification Center (linuxtesting.org) with SVACE. Link: https://lkml.kernel.org/r/[email protected] Fixes: ccd979bdbce9 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem") Signed-off-by: Artem Chernyshev <[email protected]> Reviewed-by: Joseph Qi <[email protected]> Cc: Artem Chernyshev <[email protected]> Cc: Joel Becker <[email protected]> Cc: Kurt Hackel <[email protected]> Cc: Mark Fasheh <[email protected]> Cc: Junxiao Bi <[email protected]> Cc: Changwei Ge <[email protected]> Cc: Gang He <[email protected]> Cc: Jun Piao <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eddie James <[email protected]> Date: Mon Jun 12 14:56:50 2023 -0500 fsi: aspeed: Reset master errors after CFAM reset [ Upstream commit 52300909f4670ac552bfeb33c1355b896eac8c06 ] It has been observed that sometimes the FSI master will return all 0xffs after a CFAM has been taken out of reset, without presenting any error. Resetting the FSI master errors resolves the issue. Fixes: 4a851d714ead ("fsi: aspeed: Support CFAM reset GPIO") Signed-off-by: Eddie James <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joel Stanley <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Biggers <[email protected]> Date: Tue Aug 1 21:03:53 2023 -0700 fsverity: skip PKCS#7 parser when keyring is empty commit 919dc320956ea353a7fb2d84265195ad5ef525ac upstream. If an fsverity builtin signature is given for a file but the ".fs-verity" keyring is empty, there's no real reason to run the PKCS#7 parser. Skip this to avoid the PKCS#7 attack surface when builtin signature support is configured into the kernel but is not being used. This is a hardening improvement, not a fix per se, but I've added Fixes and Cc stable to get it out to more users. Fixes: 432434c9f8e1 ("fs-verity: support builtin file signatures") Cc: [email protected] Reviewed-by: Jarkko Sakkinen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bartosz Golaszewski <[email protected]> Date: Fri Aug 11 21:30:34 2023 +0200 gpiolib: fix reference leaks when removing GPIO chips still in use [ Upstream commit 3386fb86ecdef0d39ee3306aea8ec290e61b934f ] After we remove a GPIO chip that still has some requested descriptors, gpiod_free_commit() will fail and we will never put the references to the GPIO device and the owning module in gpiod_free(). Rework this function to: - not warn on desc == NULL as this is a use-case on which most free functions silently return - put the references to desc->gdev and desc->gdev->owner unconditionally so that the release callback actually gets called when the remaining references are dropped by external GPIO users Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Illia Ostapyshyn <[email protected]> Date: Tue Jun 13 17:26:00 2023 +0200 HID: input: Support devices sending Eraser without Invert [ Upstream commit 276e14e6c3993317257e1787e93b7166fbc30905 ] Some digitizers (notably XP-Pen Artist 24) do not report the Invert usage when erasing. This causes the device to be permanently stuck with the BTN_TOOL_RUBBER tool after sending Eraser, as Invert is the only usage that can release the tool. In this state, Touch and Inrange are no longer reported to userspace, rendering the pen unusable. Prior to commit 87562fcd1342 ("HID: input: remove the need for HID_QUIRK_INVERT"), BTN_TOOL_RUBBER was never set and Eraser events were simply translated into BTN_TOUCH without causing an inconsistent state. Introduce HID_QUIRK_NOINVERT for such digitizers and detect them during hidinput_configure_usage(). This quirk causes the tool to be released as soon as Eraser is reported as not set. Set BTN_TOOL_RUBBER in input->keybit when mapping Eraser. Fixes: 87562fcd1342 ("HID: input: remove the need for HID_QUIRK_INVERT") Co-developed-by: Nils Fuhler <[email protected]> Signed-off-by: Nils Fuhler <[email protected]> Signed-off-by: Illia Ostapyshyn <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nikita Zhandarovich <[email protected]> Date: Tue Jun 13 03:16:35 2023 -0700 HID: logitech-dj: Fix error handling in logi_dj_recv_switch_to_dj_mode() [ Upstream commit 6f20d3261265885f6a6be4cda49d7019728760e0 ] Presently, if a call to logi_dj_recv_send_report() fails, we do not learn about the error until after sending short HID_OUTPUT_REPORT with hid_hw_raw_request(). To handle this somewhat unlikely issue, return on error in logi_dj_recv_send_report() (minding ugly sleep workaround) and take into account the result of hid_hw_raw_request(). Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. Fixes: 6a9ddc897883 ("HID: logitech-dj: enable notifications on connect/disconnect") Signed-off-by: Nikita Zhandarovich <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Benjamin Tissoires <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Benjamin Tissoires <[email protected]> Date: Wed Jul 12 17:02:34 2023 +0200 HID: logitech-hidpp: rework one more time the retries attempts commit 60165ab774cb0c509680a73cf826d0e158454653 upstream. Extract the internal code inside a helper function, fix the initialization of the parameters used in the helper function (`hidpp->answer_available` was not reset and `*response` wasn't either), and use a `do {...} while();` loop. Fixes: 586e8fede795 ("HID: logitech-hidpp: Retry commands when device is busy") Cc: [email protected] Reviewed-by: Bastien Nocera <[email protected]> Signed-off-by: Benjamin Tissoires <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Benjamin Tissoires <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Rahul Rameshbabu <[email protected]> Date: Thu Aug 24 06:14:33 2023 +0000 HID: multitouch: Correct devm device reference for hidinput input_dev name [ Upstream commit 4794394635293a3e74591351fff469cea7ad15a2 ] Reference the HID device rather than the input device for the devm allocation of the input_dev name. Referencing the input_dev would lead to a use-after-free when the input_dev was unregistered and subsequently fires a uevent that depends on the name. At the point of firing the uevent, the name would be freed by devres management. Use devm_kasprintf to simplify the logic for allocating memory and formatting the input_dev name string. Reported-by: Maxime Ripard <[email protected]> Closes: https://lore.kernel.org/linux-input/ZOZIZCND+L0P1wJc@penguin/T/#m443f3dce92520f74b6cf6ffa8653f9c92643d4ae Fixes: c08d46aa805b ("HID: multitouch: devm conversion") Suggested-by: Maxime Ripard <[email protected]> Suggested-by: Dmitry Torokhov <[email protected]> Signed-off-by: Rahul Rameshbabu <[email protected]> Reviewed-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Benjamin Tissoires <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rahul Rameshbabu <[email protected]> Date: Thu Aug 24 06:14:17 2023 +0000 HID: uclogic: Correct devm device reference for hidinput input_dev name [ Upstream commit dd613a4e45f8d35f49a63a2064e5308fa5619e29 ] Reference the HID device rather than the input device for the devm allocation of the input_dev name. Referencing the input_dev would lead to a use-after-free when the input_dev was unregistered and subsequently fires a uevent that depends on the name. At the point of firing the uevent, the name would be freed by devres management. Use devm_kasprintf to simplify the logic for allocating memory and formatting the input_dev name string. Reported-by: [email protected] Closes: https://lore.kernel.org/linux-input/ZOZIZCND+L0P1wJc@penguin/T/ Reported-by: Maxime Ripard <[email protected]> Closes: https://lore.kernel.org/linux-input/ZOZIZCND+L0P1wJc@penguin/T/#m443f3dce92520f74b6cf6ffa8653f9c92643d4ae Fixes: cce2dbdf258e ("HID: uclogic: name the input nodes based on their tool") Suggested-by: Maxime Ripard <[email protected]> Suggested-by: Dmitry Torokhov <[email protected]> Signed-off-by: Rahul Rameshbabu <[email protected]> Reviewed-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Benjamin Tissoires <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Biju Das <[email protected]> Date: Thu Aug 24 21:44:54 2023 +0100 hwmon: (tmp513) Fix the channel number in tmp51x_is_visible() [ Upstream commit d103337e38e7e64c3d915029e947b1cb0b512737 ] The supported channels for this driver are {0..3}. Fix the incorrect channel in tmp51x_is_visible(). Reported-by: Guenter Roeck <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Fixes: 59dfa75e5d82 ("hwmon: Add driver for Texas Instruments TMP512/513 sensor chips.") Signed-off-by: Biju Das <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Florian Fainelli <[email protected]> Date: Thu Aug 10 12:22:08 2023 -0700 hwrng: iproc-rng200 - Implement suspend and resume calls [ Upstream commit 8e03dd62e5be811efbf0cbeba47e79e793519105 ] Chips such as BCM7278 support system wide suspend/resume which will cause the HWRNG block to lose its state and reset to its power on reset register values. We need to cleanup and re-initialize the HWRNG for it to be functional coming out of a system suspend cycle. Fixes: c3577f6100ca ("hwrng: iproc-rng200 - Add support for BCM7278") Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Martin Kaiser <[email protected]> Date: Sun Jul 2 19:35:02 2023 +0200 hwrng: nomadik - keep clock enabled while hwrng is registered [ Upstream commit 039980de89dc9dd757418d6f296e4126cc3f86c3 ] The nomadik driver uses devres to register itself with the hwrng core, the driver will be unregistered from hwrng when its device goes out of scope. This happens after the driver's remove function is called. However, nomadik's clock is disabled in the remove function. There's a short timeframe where nomadik is still registered with the hwrng core although its clock is disabled. I suppose the clock must be active to access the hardware and serve requests from the hwrng core. Switch to devm_clk_get_enabled and let devres disable the clock and unregister the hwrng. This avoids the race condition. Fixes: 3e75241be808 ("hwrng: drivers - Use device-managed registration API") Signed-off-by: Martin Kaiser <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Martin Kaiser <[email protected]> Date: Tue Jul 4 19:32:01 2023 +0200 hwrng: pic32 - use devm_clk_get_enabled [ Upstream commit 6755ad74aac0fb1c79b14724feb81b2f6ff25847 ] Use devm_clk_get_enabled in the pic32 driver. Ensure that the clock is enabled as long as the driver is registered with the hwrng core. Fixes: 7ea39973d1e5 ("hwrng: pic32 - Use device-managed registration API") Signed-off-by: Martin Kaiser <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Carlos Song <[email protected]> Date: Wed Jul 26 17:22:38 2023 +0800 i2c: imx-lpi2c: return -EINVAL when i2c peripheral clk doesn't work [ Upstream commit b610c4bbd153c2cde548db48559e170905d7c369 ] On MX8X platforms, the default clock rate is 0 if without explicit clock setting in dts nodes. I2c can't work when i2c peripheral clk rate is 0. Add a i2c peripheral clk rate check before configuring the clock register. When i2c peripheral clk rate is 0 and directly return -EINVAL. Signed-off-by: Carlos Song <[email protected]> Acked-by: Dong Aisheng <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Frank Li <[email protected]> Date: Thu Aug 31 10:13:24 2023 -0400 i3c: master: svc: fix probe failure when no i3c device exist commit 6e13d6528be2f7e801af63c8153b87293f25d736 upstream. I3C masters are expected to support hot-join. This means at initialization time we might not yet discover any device and this should not be treated as a fatal error. During the DAA procedure which happens at probe time, if no device has joined, all CCC will be NACKed (from a bus perspective). This leads to an early return with an error code which fails the probe of the master. Let's avoid this by just telling the core through an I3C_ERROR_M2 return command code that no device was discovered, which is a valid situation. This way the master will no longer bail out and fail to probe for a wrong reason. Cc: [email protected] Fixes: dd3c52846d59 ("i3c: master: svc: Add Silvaco I3C master driver") Signed-off-by: Frank Li <[email protected]> Acked-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Xiang Yang <[email protected]> Date: Fri Aug 4 10:25:25 2023 +0800 IB/uverbs: Fix an potential error pointer dereference [ Upstream commit 26b7d1a27167e7adf75b150755e05d2bc123ce55 ] smatch reports the warning below: drivers/infiniband/core/uverbs_std_types_counters.c:110 ib_uverbs_handler_UVERBS_METHOD_COUNTERS_READ() error: 'uattr' dereferencing possible ERR_PTR() The return value of uattr maybe ERR_PTR(-ENOENT), fix this by checking the value of uattr before using it. Fixes: ebb6796bd397 ("IB/uverbs: Add read counters support") Signed-off-by: Xiang Yang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jacob Keller <[email protected]> Date: Wed Aug 23 08:18:14 2023 -0700 ice: avoid executing commands on other ports when driving sync [ Upstream commit 0aacec49c29e7c5b1487e859b0c0a42388c34092 ] The ice hardware has a synchronization mechanism used to drive the simultaneous application of commands on both PHY ports and the source timer in the MAC. When issuing a sync via ice_ptp_exec_tmr_cmd(), the hardware will simultaneously apply the commands programmed for the main timer and each PHY port. Neither the main timer command register, nor the PHY port command registers auto clear on command execution. During the execution of a timer command intended for a single port on E822 devices, such as those used to configure a PHY during link up, the driver is not correctly clearing the previous commands. This results in unintentionally executing the last programmed command on the main timer and other PHY ports whenever performing reconfiguration on E822 ports after link up. This results in unintended side effects on other timers, depending on what command was previously programmed. To fix this, the driver must ensure that the main timer and all other PHY ports are properly initialized to perform no action. The enumeration for timer commands does not include an enumeration value for doing nothing. Introduce ICE_PTP_NOP for this purpose. When writing a timer command to hardware, leave the command bits set to zero which indicates that no operation should be performed on that port. Modify ice_ptp_one_port_cmd() to always initialize all ports. For all ports other than the one being configured, write their timer command register to ICE_PTP_NOP. This ensures that no side effect happens on the timer command. To fix this for the PHY ports, modify ice_ptp_one_port_cmd() to always initialize all other ports to ICE_PTP_NOP. This ensures that no side effects happen on the other ports. Call ice_ptp_src_cmd() with a command value if ICE_PTP_NOP in ice_sync_phy_timer_e822() and ice_start_phy_timer_e822(). With both of these changes, the driver should no longer execute a stale command on the main timer or another PHY port when reconfiguring one of the PHY ports after link up. Fixes: 3a7496234d17 ("ice: implement basic E822 PTP support") Signed-off-by: Siddaraju DH <[email protected]> Signed-off-by: Jacob Keller <[email protected]> Tested-by: Sunitha Mekala <[email protected]> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Przemek Kitszel <[email protected]> Date: Tue Aug 8 17:54:15 2023 -0400 ice: ice_aq_check_events: fix off-by-one check when filling buffer [ Upstream commit e1e8a142c43336e3d25bfa1cb3a4ae7d00875c48 ] Allow task's event buffer to be filled also in the case that it's size is exactly the size of the message. Fixes: d69ea414c9b4 ("ice: implement device flash update via devlink") Reviewed-by: Jacob Keller <[email protected]> Signed-off-by: Przemek Kitszel <[email protected]> Reviewed-by: Simon Horman <[email protected]> Tested-by: Pucha Himasekhar Reddy <[email protected]> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Baoquan He <[email protected]> Date: Fri Jul 7 21:58:45 2023 +0800 idmaengine: make FSL_EDMA and INTEL_IDMA64 depends on HAS_IOMEM [ Upstream commit b1e213a9e31c20206f111ec664afcf31cbfe0dbb ] On s390 systems (aka mainframes), it has classic channel devices for networking and permanent storage that are currently even more common than PCI devices. Hence it could have a fully functional s390 kernel with CONFIG_PCI=n, then the relevant iomem mapping functions [including ioremap(), devm_ioremap(), etc.] are not available. Here let FSL_EDMA and INTEL_IDMA64 depend on HAS_IOMEM so that it won't be built to cause below compiling error if PCI is unset. -------- ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/fsl-edma.ko] undefined! ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/idma64.ko] undefined! -------- Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Baoquan He <[email protected]> Cc: Vinod Koul <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Radoslaw Tyl <[email protected]> Date: Thu Aug 24 13:46:19 2023 -0700 igb: set max size RX buffer when store bad packet is enabled commit bb5ed01cd2428cd25b1c88a3a9cba87055eb289f upstream. Increase the RX buffer size to 3K when the SBP bit is on. The size of the RX buffer determines the number of pages allocated which may not be sufficient for receive frames larger than the set MTU size. Cc: [email protected] Fixes: 89eaefb61dc9 ("igb: Support RX-ALL feature flag.") Reported-by: Manfred Rudigier <[email protected]> Signed-off-by: Radoslaw Tyl <[email protected]> Tested-by: Arpana Arland <[email protected]> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Tue Sep 5 04:23:38 2023 +0000 igmp: limit igmpv3_newpack() packet size to IP_MAX_MTU commit c3b704d4a4a265660e665df51b129e8425216ed1 upstream. This is a follow up of commit 915d975b2ffa ("net: deal with integer overflows in kmalloc_reserve()") based on David Laight feedback. Back in 2010, I failed to realize malicious users could set dev->mtu to arbitrary values. This mtu has been since limited to 0x7fffffff but regardless of how big dev->mtu is, it makes no sense for igmpv3_newpack() to allocate more than IP_MAX_MTU and risk various skb fields overflows. Fixes: 57e1ab6eaddc ("igmp: refine skb allocations") Link: https://lore.kernel.org/netdev/[email protected]/ Signed-off-by: Eric Dumazet <[email protected]> Reported-by: David Laight <[email protected]> Cc: Kyle Zeng <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Biju Das <[email protected]> Date: Tue Jul 25 18:16:23 2023 +0100 iio: accel: adxl313: Fix adxl313_i2c_id[] table [ Upstream commit f636554c4cd1c644109cc525900a056495b86cc9 ] The .driver_data in adxl313_i2c_id[] for adxl312 and adxl314 is wrong. Fix this issue by adding corresponding adxl31x_chip_info data. Reported-by: Jonathan Cameron <[email protected]> Closes: https://lore.kernel.org/all/20230722172832.04ad7738@jic23-huawei Fixes: a7a1c60bc4c9 ("drivers: iio: accel: adxl312 and adxl314 support") Signed-off-by: Biju Das <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nayna Jain <[email protected]> Date: Tue Jul 11 12:44:47 2023 -0400 ima: Remove deprecated IMA_TRUSTED_KEYRING Kconfig [ Upstream commit 5087fd9e80e539d2163accd045b73da64de7de95 ] Time to remove "IMA_TRUSTED_KEYRING". Fixes: f4dc37785e9b ("integrity: define '.evm' as a builtin 'trusted' keyring") # v4.5+ Signed-off-by: Nayna Jain <[email protected]> Signed-off-by: Mimi Zohar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Werner Sembach <[email protected]> Date: Wed Jul 12 11:56:51 2023 -0700 Input: i8042 - add quirk for TUXEDO Gemini 17 Gen1/Clevo PD70PN commit eb09074bdb05ffd6bfe77f8b4a41b76ef78c997b upstream. The touchpad of this device is both connected via PS/2 and i2c. This causes strange behavior when both driver fight for control. The easy fix is to prevent the PS/2 driver from accessing the mouse port as the full feature set of the touchpad is only supported in the i2c interface anyway. The strange behavior in this case is, that when an external screen is connected and the notebook is closed, the pointer on the external screen is moving to the lower right corner. When the notebook is opened again, this movement stops, but the touchpad clicks are unresponsive afterwards until reboot. Signed-off-by: Werner Sembach <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Sat Aug 12 01:16:15 2023 +0200 interconnect: qcom: bcm-voter: Improve enable_mask handling [ Upstream commit a1f4170dec440f023601d57e49227b784074d218 ] We don't need all the complex arithmetic for BCMs utilizing enable_mask, as all we need to do is to determine whether there's any user (or keepalive) asking for it to be on. Separate the logic for such BCMs for a small speed boost. Suggested-by: Bjorn Andersson <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]> Stable-dep-of: 1a70ca71547b ("interconnect: qcom: bcm-voter: Use enable_maks for keepalive voting") Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Sat Aug 12 01:16:16 2023 +0200 interconnect: qcom: bcm-voter: Use enable_maks for keepalive voting [ Upstream commit 1a70ca71547be051769f0628aa09717694f508f0 ] BCMs with an enable_mask expect to only have that specific value written to them. The current implementation only works by miracle for BCMs with enable mask == BIT(0), as the minimal vote we've been using so far just so happens to be equal to that. Use the correct value with keepalive voting. Fixes: d8630f050d3f ("interconnect: qcom: Add support for mask-based BCMs") Reported-by: Bjorn Andersson <[email protected]> Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Mon Jul 24 12:49:22 2023 +0200 interconnect: qcom: qcm2290: Enable sync state [ Upstream commit 4e048e9b7a160f7112069c0ec2947be15f3e8154 ] Enable the generic .sync_state callback to ensure there are no outstanding votes that would waste power. Generally one would need a bunch of interface clocks to access the QoS registers when trying to go over all possible nodes during sync_state, but QCM2290 surprisingly does not seem to require any such handling. Fixes: 1a14b1ac3935 ("interconnect: qcom: Add QCM2290 driver support") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Fri Aug 11 19:34:57 2023 +0200 interconnect: qcom: sm8450: Enable sync_state [ Upstream commit 16862f1b2110eca6330e5be6d804e1a08e06a202 ] Enable sync_state on sm8450 so that the interconnect votes actually mean anything and aren't just pinned to INT_MAX. Fixes: fafc114a468e ("interconnect: qcom: Add SM8450 interconnect provider driver") Signed-off-by: Konrad Dybcio <[email protected]> Reviewed-by: Vinod Koul <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jens Axboe <[email protected]> Date: Sun Aug 13 11:05:36 2023 -0600 io_uring/sqpoll: fix io-wq affinity when IORING_SETUP_SQPOLL is used commit ebdfefc09c6de7897962769bd3e63a2ff443ebf5 upstream. If we setup the ring with SQPOLL, then that polling thread has its own io-wq setup. This means that if the application uses IORING_REGISTER_IOWQ_AFF to set the io-wq affinity, we should not be setting it for the invoking task, but rather the sqpoll task. Add an sqpoll helper that parks the thread and updates the affinity, and use that one if we're using SQPOLL. Fixes: fe76421d1da1 ("io_uring: allow user configurable IO thread CPU affinity") Cc: [email protected] # 5.10+ Link: https://github.com/axboe/liburing/discussions/884 Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pavel Begunkov <[email protected]> Date: Wed Aug 9 16:20:21 2023 +0100 io_uring: break iopolling on signal commit dc314886cb3d0e4ab2858003e8de2917f8a3ccbd upstream. Don't keep spinning iopoll with a signal set. It'll eventually return back, e.g. by virtue of need_resched(), but it's not a nice user experience. Cc: [email protected] Fixes: def596e9557c9 ("io_uring: support for IO polling") Signed-off-by: Pavel Begunkov <[email protected]> Link: https://lore.kernel.org/r/eeba551e82cad12af30c3220125eb6cb244cc94c.1691594339.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pavel Begunkov <[email protected]> Date: Thu Sep 7 13:50:07 2023 +0100 io_uring: break out of iowq iopoll on teardown commit 45500dc4e01c167ee063f3dcc22f51ced5b2b1e9 upstream. io-wq will retry iopoll even when it failed with -EAGAIN. If that races with task exit, which sets TIF_NOTIFY_SIGNAL for all its workers, such workers might potentially infinitely spin retrying iopoll again and again and each time failing on some allocation / waiting / etc. Don't keep spinning if io-wq is dying. Fixes: 561fb04a6a225 ("io_uring: replace workqueue usage with io-wq") Cc: [email protected] Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Gabriel Krisman Bertazi <[email protected]> Date: Mon Aug 28 19:42:49 2023 -0400 io_uring: Don't set affinity on a dying sqpoll thread commit bd6fc5da4c51107e1e0cec4a3a07963d1dae2c84 upstream. Syzbot reported a null-ptr-deref of sqd->thread inside io_sqpoll_wq_cpu_affinity. It turns out the sqd->thread can go away from under us during io_uring_register, in case the process gets a fatal signal during io_uring_register. It is not particularly hard to hit the race, and while I am not sure this is the exact case hit by syzbot, it solves it. Finally, checking ->thread is enough to close the race because we locked sqd while "parking" the thread, thus preventing it from going away. I reproduced it fairly consistently with a program that does: int main(void) { ... io_uring_queue_init(RING_LEN, &ring1, IORING_SETUP_SQPOLL); while (1) { io_uring_register_iowq_aff(ring, 1, &mask); } } Executed in a loop with timeout to trigger SIGTERM: while true; do timeout 1 /a.out ; done This will hit the following BUG() in very few attempts. BUG: kernel NULL pointer dereference, address: 00000000000007a8 PGD 800000010e949067 P4D 800000010e949067 PUD 10e46e067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 15715 Comm: dead-sqpoll Not tainted 6.5.0-rc7-next-20230825-g193296236fa0-dirty #23 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:io_sqpoll_wq_cpu_affinity+0x27/0x70 Code: 90 90 90 0f 1f 44 00 00 55 53 48 8b 9f 98 03 00 00 48 85 db 74 4f 48 89 df 48 89 f5 e8 e2 f8 ff ff 48 8b 43 38 48 85 c0 74 22 <48> 8b b8 a8 07 00 00 48 89 ee e8 ba b1 00 00 48 89 df 89 c5 e8 70 RSP: 0018:ffffb04040ea7e70 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff93c010749e40 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ffffffffa7653331 RDI: 00000000ffffffff RBP: ffffb04040ea7eb8 R08: 0000000000000000 R09: c0000000ffffdfff R10: ffff93c01141b600 R11: ffffb04040ea7d18 R12: ffff93c00ea74840 R13: 0000000000000011 R14: 0000000000000000 R15: ffff93c00ea74800 FS: 00007fb7c276ab80(0000) GS:ffff93c36f200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000007a8 CR3: 0000000111634003 CR4: 0000000000370ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __die_body+0x1a/0x60 ? page_fault_oops+0x154/0x440 ? do_user_addr_fault+0x174/0x7b0 ? exc_page_fault+0x63/0x140 ? asm_exc_page_fault+0x22/0x30 ? io_sqpoll_wq_cpu_affinity+0x27/0x70 __io_register_iowq_aff+0x2b/0x60 __io_uring_register+0x614/0xa70 __x64_sys_io_uring_register+0xaa/0x1a0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7fb7c226fec9 Code: 2e 00 b8 ca 00 00 00 0f 05 eb a5 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 97 7f 2d 00 f7 d8 64 89 01 48 RSP: 002b:00007ffe2c0674f8 EFLAGS: 00000246 ORIG_RAX: 00000000000001ab RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb7c226fec9 RDX: 00007ffe2c067530 RSI: 0000000000000011 RDI: 0000000000000003 RBP: 00007ffe2c0675d0 R08: 00007ffe2c067550 R09: 00007ffe2c067550 R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffe2c067750 R14: 0000000000000000 R15: 0000000000000000 </TASK> Modules linked in: CR2: 00000000000007a8 ---[ end trace 0000000000000000 ]--- Reported-by: [email protected] Fixes: ebdfefc09c6d ("io_uring/sqpoll: fix io-wq affinity when IORING_SETUP_SQPOLL is used") Signed-off-by: Gabriel Krisman Bertazi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pavel Begunkov <[email protected]> Date: Wed Aug 9 13:21:41 2023 +0100 io_uring: fix drain stalls by invalid SQE [ Upstream commit cfdbaa3a291d6fd2cb4a1a70d74e63b4abc2f5ec ] cq_extra is protected by ->completion_lock, which io_get_sqe() misses. The bug is harmless as it doesn't happen in real life, requires invalid SQ index array and racing with submission, and only messes up the userspace, i.e. stall requests execution but will be cleaned up on ring destruction. Fixes: 15641e427070f ("io_uring: don't cache number of dropped SQEs") Signed-off-by: Pavel Begunkov <[email protected]> Link: https://lore.kernel.org/r/66096d54651b1a60534bb2023f2947f09f50ef73.1691538547.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pavel Begunkov <[email protected]> Date: Wed Aug 9 13:22:16 2023 +0100 io_uring: fix false positive KASAN warnings commit 569f5308e54352a12181cc0185f848024c5443e8 upstream. io_req_local_work_add() peeks into the work list, which can be executed in the meanwhile. It's completely fine without KASAN as we're in an RCU read section and it's SLAB_TYPESAFE_BY_RCU. With KASAN though it may trigger a false positive warning because internal io_uring caches are sanitised. Remove sanitisation from the io_uring request cache for now. Cc: [email protected] Fixes: 8751d15426a31 ("io_uring: reduce scheduling due to tw") Signed-off-by: Pavel Begunkov <[email protected]> Link: https://lore.kernel.org/r/c6fbf7a82a341e66a0007c76eefd9d57f2d3ba51.1691541473.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Matthew Wilcox (Oracle) <[email protected]> Date: Fri Jun 2 18:09:11 2023 -0400 iomap: Remove large folio handling in iomap_invalidate_folio() [ Upstream commit a221ab717c43147f728d93513923ba3528f861bf ] We do not need to release the iomap_page in iomap_invalidate_folio() to allow the folio to be split. The splitting code will call ->release_folio() if there is still per-fs private data attached to the folio. At that point, we will check if the folio is still dirty and decline to release the iomap_page. It is possible to trigger the warning in perfectly legitimate circumstances (eg if a disk read fails, we do a partial write to the folio, then we truncate the folio), which will cause those writes to be lost. Fixes: 60d8231089f0 ("iomap: Support large folios in invalidatepage") Signed-off-by: Matthew Wilcox (Oracle) <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Marcovitch <[email protected]> Date: Fri Jun 9 10:51:45 2023 +0000 iommu/amd/iommu_v2: Fix pasid_state refcount dec hit 0 warning on pasid unbind [ Upstream commit 534103bcd52ca9c1fecbc70e717b4a538dc4ded8 ] When unbinding pasid - a race condition exists vs outstanding page faults. To prevent this, the pasid_state object contains a refcount. * set to 1 on pasid bind * incremented on each ppr notification start * decremented on each ppr notification done * decremented on pasid unbind Since refcount_dec assumes that refcount will never reach 0: the current implementation causes the following to be invoked on pasid unbind: REFCOUNT_WARN("decrement hit 0; leaking memory") Fix this issue by changing refcount_dec to refcount_dec_and_test to explicitly handle refcount=1. Fixes: 8bc54824da4e ("iommu/amd: Convert from atomic_t to refcount_t on pasid_state->count") Signed-off-by: Daniel Marcovitch <[email protected]> Signed-off-by: Vasant Hegde <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chengci.Xu <[email protected]> Date: Fri Jun 2 17:02:22 2023 +0800 iommu/mediatek: Fix two IOMMU share pagetable issue [ Upstream commit cf69ef46dbd980a0b1c956d668e066a73e0acd0f ] Prepare for mt8188 to fix a two IOMMU HWs share pagetable issue. We have two MM IOMMU HWs in mt8188, one is VPP-IOMMU, the other is VDO-IOMMU. The 2 MM IOMMU HWs share pagetable don't work in this case: a) VPP-IOMMU probe firstly. b) VDO-IOMMU probe. c) The master for VDO-IOMMU probe (means frstdata is vpp-iommu). d) The master in another domain probe. No matter it is vdo or vpp. Then it still create a new pagetable in step d). The problem is "frstdata->bank[0]->m4u_dom" was not initialized. Then when d) enter, it still create a new one. In this patch, we create a new variable "share_dom" for this share pgtable case, it should be helpful for readable. and put all the share pgtable logic in the mtk_iommu_domain_finalise. In mt8195, the master of VPP-IOMMU probes before than VDO-IOMMU from its dtsi node sequence, we don't see this issue in it. Prepare for mt8188. Fixes: 645b87c190c9 ("iommu/mediatek: Fix 2 HW sharing pgtable issue") Signed-off-by: Chengci.Xu <[email protected]> Signed-off-by: Yong Wu <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Alexandre Mergnat <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: AngeloGioacchino Del Regno <[email protected]> Date: Thu Jun 22 11:27:39 2023 +0200 iommu/qcom: Disable and reset context bank before programming [ Upstream commit 9f3fef23d9b5a858a6e6d5f478bb1b6b76265e76 ] Writing the new TTBRs, TCRs and MAIRs on a previously enabled context bank may trigger a context fault, resulting in firmware driven AP resets: change the domain initialization programming sequence to disable the context bank(s) and to also clear the related fault address (CB_FAR) and fault status (CB_FSR) registers before writing new values to TTBR0/1, TCR/TCR2, MAIR0/1. Fixes: 0ae349a0f33f ("iommu/qcom: Add qcom_iommu") Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/20230622092742.74819-4-angelogioacchino.del[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jason Gunthorpe <[email protected]> Date: Mon Jul 24 14:36:05 2023 -0300 iommu/sprd: Add missing force_aperture [ Upstream commit d48a51286c698f7fe8efc688f23a532f4fe9a904 ] force_aperture was intended to false only by GART drivers that have an identity translation outside the aperture. This does not describe sprd, so add the missing 'force_aperture = true'. Fixes: b23e4fc4e3fa ("iommu: add Unisoc IOMMU basic driver") Signed-off-by: Jason Gunthorpe <[email protected]> Acked-by: Chunyan Zhang <[email protected]> Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yanfei Xu <[email protected]> Date: Wed Aug 9 20:48:04 2023 +0800 iommu/vt-d: Fix to flush cache of PASID directory table [ Upstream commit 8a3b8e63f8371c1247b7aa24ff9c5312f1a6948b ] Even the PCI devices don't support pasid capability, PASID table is mandatory for a PCI device in scalable mode. However flushing cache of pasid directory table for these devices are not taken after pasid table is allocated as the "size" of table is zero. Fix it by calculating the size by page order. Found this when reading the code, no real problem encountered for now. Fixes: 194b3348bdbb ("iommu/vt-d: Fix PASID directory pointer coherency") Suggested-by: Lu Baolu <[email protected]> Signed-off-by: Yanfei Xu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lu Baolu <[email protected]> Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhu Wang <[email protected]> Date: Mon Jul 31 19:27:58 2023 +0800 iommu: Remove kernel-doc warnings [ Upstream commit 6b7867b5b8a6b14c487bf04a693ab424c7a8718d ] Remove kernel-doc warnings: drivers/iommu/iommu.c:3261: warning: Function parameter or member 'group' not described in 'iommu_group_release_dma_owner' drivers/iommu/iommu.c:3261: warning: Excess function parameter 'dev' description in 'iommu_group_release_dma_owner' drivers/iommu/iommu.c:3275: warning: Function parameter or member 'dev' not described in 'iommu_device_release_dma_owner' drivers/iommu/iommu.c:3275: warning: Excess function parameter 'group' description in 'iommu_device_release_dma_owner' Signed-off-by: Zhu Wang <[email protected]> Fixes: 89395ccedbc1 ("iommu: Add device-centric DMA ownership interfaces") Reviewed-by: Jason Gunthorpe <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jonas Karlman <[email protected]> Date: Sat Jun 17 18:25:45 2023 +0000 iommu: rockchip: Fix directory table address encoding [ Upstream commit 6df63b7ebdaf5fcd75dceedf6967d0761e56eca1 ] The physical address to the directory table is currently encoded using the following bit layout for IOMMU v2. 31:12 - Address bit 31:0 11: 4 - Address bit 39:32 This is also the bit layout used by the vendor kernel. However, testing has shown that addresses to the directory/page tables and memory pages are all encoded using the same bit layout. IOMMU v1: 31:12 - Address bit 31:0 IOMMU v2: 31:12 - Address bit 31:0 11: 8 - Address bit 35:32 7: 4 - Address bit 39:36 Change to use the mk_dtentries ops to encode the directory table address correctly. The value written to DTE_ADDR may include the valid bit set, a bit that is ignored and DTE_ADDR reg read it back as 0. This also update the bit layout comment for the page address and the number of nybbles that are read back for DTE_ADDR comment. These changes render the dte_addr_phys and dma_addr_dte ops unused and is removed. Fixes: 227014b33f62 ("iommu: rockchip: Add internal ops to handle variants") Fixes: c55356c534aa ("iommu: rockchip: Add support for iommu v2") Fixes: c987b65a574f ("iommu/rockchip: Fix physical address decoding") Signed-off-by: Jonas Karlman <[email protected]> Reviewed-by: Robin Murphy <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jason Gunthorpe <[email protected]> Date: Mon Jul 17 15:12:07 2023 -0300 iommufd: Fix locking around hwpt allocation [ Upstream commit 31422dff187b243c58f3a97d16bbe9e9ada639fe ] Due to the auto_domains mechanism the ioas->mutex must be held until the hwpt is completely setup by iommufd_object_abort_and_destroy() or iommufd_object_finalize(). This prevents a concurrent iommufd_device_auto_get_domain() from seeing an incompletely initialized object through the ioas->hwpt_list. To make this more consistent move the unlock until after finalize. Fixes: e8d57210035b ("iommufd: Add kAPI toward external drivers for physical devices") Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Kevin Tian <[email protected]> Tested-by: Nicolin Chen <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David Howells <[email protected]> Date: Fri Sep 8 17:03:20 2023 +0100 iov_iter: Fix iov_iter_extract_pages() with zero-sized entries commit f741bd7178c95abd7aeac5a9d933ee542f9a5509 upstream. iov_iter_extract_pages() doesn't correctly handle skipping over initial zero-length entries in ITER_KVEC and ITER_BVEC-type iterators. The problem is that it accidentally reduces maxsize to 0 when it skipping and thus runs to the end of the array and returns 0. Fix this by sticking the calculated size-to-copy in a new variable rather than back in maxsize. Fixes: 7d58fe731028 ("iov_iter: Add a function to extract a page list from an iterator") Signed-off-by: David Howells <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Jens Axboe <[email protected]> Cc: Al Viro <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: John Hubbard <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jiasheng Jiang <[email protected]> Date: Mon Jun 19 17:28:02 2023 +0800 ipmi:ssif: Add check for kstrdup [ Upstream commit c5586d0f711e9744d0cade39b0c4a2d116a333ca ] Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference. Fixes: c4436c9149c5 ("ipmi_ssif: avoid registering duplicate ssif interface") Signed-off-by: Jiasheng Jiang <[email protected]> Message-Id: <[email protected]> Signed-off-by: Corey Minyard <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Corey Minyard <[email protected]> Date: Mon Jun 19 11:43:33 2023 -0500 ipmi:ssif: Fix a memory leak when scanning for an adapter [ Upstream commit b8d72e32e1453d37ee5c8a219f24e7eeadc471ef ] The adapter scan ssif_info_find() sets info->adapter_name if the adapter info came from SMBIOS, as it's not set in that case. However, this function can be called more than once, and it will leak the adapter name if it had already been set. So check for NULL before setting it. Fixes: c4436c9149c5 ("ipmi_ssif: avoid registering duplicate ssif interface") Signed-off-by: Corey Minyard <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yi Yang <[email protected]> Date: Thu Jun 29 20:33:28 2023 +0800 ipmi_si: fix a memleak in try_smi_init() commit 6cf1a126de2992b4efe1c3c4d398f8de4aed6e3f upstream. Kmemleak reported the following leak info in try_smi_init(): unreferenced object 0xffff00018ecf9400 (size 1024): comm "modprobe", pid 2707763, jiffies 4300851415 (age 773.308s) backtrace: [<000000004ca5b312>] __kmalloc+0x4b8/0x7b0 [<00000000953b1072>] try_smi_init+0x148/0x5dc [ipmi_si] [<000000006460d325>] 0xffff800081b10148 [<0000000039206ea5>] do_one_initcall+0x64/0x2a4 [<00000000601399ce>] do_init_module+0x50/0x300 [<000000003c12ba3c>] load_module+0x7a8/0x9e0 [<00000000c246fffe>] __se_sys_init_module+0x104/0x180 [<00000000eea99093>] __arm64_sys_init_module+0x24/0x30 [<0000000021b1ef87>] el0_svc_common.constprop.0+0x94/0x250 [<0000000070f4f8b7>] do_el0_svc+0x48/0xe0 [<000000005a05337f>] el0_svc+0x24/0x3c [<000000005eb248d6>] el0_sync_handler+0x160/0x164 [<0000000030a59039>] el0_sync+0x160/0x180 The problem was that when an error occurred before handlers registration and after allocating `new_smi->si_sm`, the variable wouldn't be freed in the error handling afterwards since `shutdown_smi()` hadn't been registered yet. Fix it by adding a `kfree()` in the error handling path in `try_smi_init()`. Cc: [email protected] # 4.19+ Fixes: 7960f18a5647 ("ipmi_si: Convert over to a shutdown handler") Signed-off-by: Yi Yang <[email protected]> Co-developed-by: GONG, Ruiqi <[email protected]> Signed-off-by: GONG, Ruiqi <[email protected]> Message-Id: <[email protected]> Signed-off-by: Corey Minyard <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bibo Mao <[email protected]> Date: Fri Aug 11 17:58:04 2023 +0800 irqchip/loongson-eiointc: Fix return value checking of eiointc_index [ Upstream commit 2e99b73afde18853754c5fae8e8d1a66fe5e3f64 ] Return value of function eiointc_index is int, however it is converted into uint32_t and then compared smaller than zero, this will cause logic problem. Fixes: dd281e1a1a93 ("irqchip: Add Loongson Extended I/O interrupt controller support") Signed-off-by: Bibo Mao <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Alexei Filippov <[email protected]> Date: Sat Aug 19 20:32:16 2023 +0300 jfs: validate max amount of blocks before allocation. [ Upstream commit 0225e10972fa809728b8d4c1bd2772b3ec3fdb57 ] The lack of checking bmp->db_max_freebud in extBalloc() can lead to shift out of bounds, so this patch prevents undefined behavior, because bmp->db_max_freebud == -1 only if there is no free space. Signed-off-by: Aleksei Filippov <[email protected]> Signed-off-by: Dave Kleikamp <[email protected]> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-and-tested-by: [email protected] Closes: https://syzkaller.appspot.com/bug?id=01abadbd6ae6a08b1f1987aa61554c6b3ac19ff2 Signed-off-by: Sasha Levin <[email protected]>
Author: Miguel Ojeda <[email protected]> Date: Fri Jun 16 02:16:25 2023 +0200 kbuild: rust_is_available: add check for `bindgen` invocation [ Upstream commit 52cae7f28ed6c3992489f16bb355f5b623f0912e ] `scripts/rust_is_available.sh` calls `bindgen` with a special header in order to check whether the `libclang` version in use is suitable. However, the invocation itself may fail if, for instance, `bindgen` cannot locate `libclang`. This is fine for Kconfig (since the script will still fail and therefore disable Rust as it should), but it is pretty confusing for users of the `rustavailable` target given the error will be unrelated: ./scripts/rust_is_available.sh: 21: arithmetic expression: expecting primary: "100000 * + 100 * + " make: *** [Makefile:1816: rustavailable] Error 2 Instead, run the `bindgen` invocation independently in a previous step, saving its output and return code. If it fails, then show the user a proper error message. Otherwise, continue as usual with the saved output. Since the previous patch we show a reference to the docs, and the docs now explain how `bindgen` looks for `libclang`, thus the error message can leverage the documentation, avoiding duplication here (and making users aware of the setup guide in the documentation). Reported-by: Nick Desaulniers <[email protected]> Link: https://lore.kernel.org/rust-for-linux/CAKwvOdm5JT4wbdQQYuW+RT07rCi6whGBM2iUAyg8A1CmLXG6Nw@mail.gmail.com/ Reported-by: François Valenduc <[email protected]> Closes: https://github.com/Rust-for-Linux/linux/issues/934 Reported-by: Alexandru Radovici <[email protected]> Closes: https://github.com/Rust-for-Linux/linux/pull/921 Reported-by: Matthew Leach <[email protected]> Closes: https://lore.kernel.org/rust-for-linux/[email protected]/ Fixes: 78521f3399ab ("scripts: add `rust_is_available.sh`") Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Reviewed-by: Masahiro Yamada <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miguel Ojeda <[email protected]> Date: Fri Jun 16 02:16:27 2023 +0200 kbuild: rust_is_available: fix confusion when a version appears in the path [ Upstream commit 9eb7e20e0c5cd069457845f965b3e8a7d736ecb7 ] `bindgen`'s output for `libclang`'s version check contains paths, which in turn may contain strings that look like version numbers [1][2]: .../6.1.0-dev/.../rust_is_available_bindgen_libclang.h:2:9: warning: clang version 11.1.0 [-W#pragma-messages], err: false which the script will pick up as the version instead of the latter. It is also the case that versions may appear after the actual version (e.g. distribution's version text), which was the reason behind `head` [3]: .../rust-is-available-bindgen-libclang.h:2:9: warning: clang version 13.0.0 (Fedora 13.0.0-3.fc35) [-W#pragma-messages], err: false Thus instead ask for a match after the `clang version` string. Reported-by: Jordan Isaacs <[email protected]> Closes: https://github.com/Rust-for-Linux/linux/issues/942 [1] Reported-by: "Ethan D. Twardy" <[email protected]> Closes: https://lore.kernel.org/rust-for-linux/[email protected]/ [2] Reported-by: Tiago Lam <[email protected]> Closes: https://github.com/Rust-for-Linux/linux/pull/789 [3] Fixes: 78521f3399ab ("scripts: add `rust_is_available.sh`") Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Reviewed-by: Ethan Twardy <[email protected]> Tested-by: Ethan Twardy <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Russell Currey <[email protected]> Date: Fri Jun 16 02:16:22 2023 +0200 kbuild: rust_is_available: fix version check when CC has multiple arguments [ Upstream commit dee3a6b819c96fc8b1907577f585fd66f5c0fefe ] rust_is_available.sh uses cc-version.sh to identify which C compiler is in use, as scripts/Kconfig.include does. cc-version.sh isn't designed to be able to handle multiple arguments in one variable, i.e. "ccache clang". Its invocation in rust_is_available.sh quotes "$CC", which makes $1 == "ccache clang" instead of the intended $1 == ccache & $2 == clang. cc-version.sh could also be changed to handle having "ccache clang" as one argument, but it only has the one consumer upstream, making it simpler to fix the caller here. Signed-off-by: Russell Currey <[email protected]> Fixes: 78521f3399ab ("scripts: add `rust_is_available.sh`") Link: https://github.com/Rust-for-Linux/linux/pull/873 [ Reworded title prefix and reflow line to 75 columns. ] Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Masahiro Yamada <[email protected]> Date: Fri Jun 16 02:16:21 2023 +0200 kbuild: rust_is_available: remove -v option [ Upstream commit d824d2f98565e7c4cb1b862c230198fbe1a968be ] The -v option is passed when this script is invoked from Makefile, but not when invoked from Kconfig. As you can see in scripts/Kconfig.include, the 'success' macro suppresses stdout and stderr anyway, so this script does not need to be quiet. Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Miguel Ojeda <[email protected]> Tested-by: Miguel Ojeda <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Reworded prefix to match the others in the patch series. ] Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]> Stable-dep-of: dee3a6b819c9 ("kbuild: rust_is_available: fix version check when CC has multiple arguments") Signed-off-by: Sasha Levin <[email protected]>
Author: Arnd Bergmann <[email protected]> Date: Mon Jul 24 14:18:16 2023 +0200 kernfs: add stub helper for kernfs_generic_poll() [ Upstream commit 79038a99445f69c5d28494dd4f8c6f0509f65b2e ] In some randconfig builds, kernfs ends up being disabled, so there is no prototype for kernfs_generic_poll() In file included from kernel/sched/build_utility.c:97: kernel/sched/psi.c:1479:3: error: implicit declaration of function 'kernfs_generic_poll' is invalid in C99 [-Werror,-Wimplicit-function-declaration] kernfs_generic_poll(t->of, wait); ^ Add a stub helper for it, as we have it for other kernfs functions. Fixes: aff037078ecae ("sched/psi: use kernfs polling functions for PSI trigger polling") Fixes: 147e1a97c4a0b ("fs: kernfs: add poll file operation") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Chengming Zhou <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Masami Hiramatsu (Google) <[email protected]> Date: Tue Jul 11 10:50:47 2023 +0900 kprobes: Prohibit probing on CFI preamble symbol [ Upstream commit de02f2ac5d8cfb311f44f2bf144cc20002f1fbbd ] Do not allow to probe on "__cfi_" or "__pfx_" started symbol, because those are used for CFI and not executed. Probing it will break the CFI. Link: https://lore.kernel.org/all/168904024679.116016.18089228029322008512.stgit@devnote2/ Signed-off-by: Masami Hiramatsu (Google) <[email protected]> Reviewed-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Namjae Jeon <[email protected]> Date: Sun Jul 23 15:27:37 2023 +0900 ksmbd: fix out of bounds in init_smb2_rsp_hdr() [ Upstream commit 536bb492d39bb6c080c92f31e8a55fe9934f452b ] If client send smb2 negotiate request and then send smb1 negotiate request, init_smb2_rsp_hdr is called for smb1 negotiate request since need_neg is set to false. This patch ignore smb1 packets after ->need_neg is set to false. Reported-by: [email protected] # ZDI-CAN-21541 Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Namjae Jeon <[email protected]> Date: Sat Jul 22 00:09:28 2023 +0900 ksmbd: fix out of bounds in smb3_decrypt_req() [ Upstream commit dc318846f3dd54574a36ae97fc8d8b75dd7cdb1e ] smb3_decrypt_req() validate if pdu_length is smaller than smb2_transform_hdr size. Reported-by: [email protected] # ZDI-CAN-21589 Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wang Ming <[email protected]> Date: Tue Jul 4 15:40:47 2023 +0800 ksmbd: Fix unsigned expression compared with zero [ Upstream commit 0266a2f791294e0b4ba36f4a1d89b8615ea3cac0 ] The return value of the ksmbd_vfs_getcasexattr() is signed. However, the return value is being assigned to an unsigned variable and subsequently recasted, causing warnings. Use a signed type. Signed-off-by: Wang Ming <[email protected]> Acked-by: Tom Talpey <[email protected]> Acked-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Sasha Levin <[email protected]>
Author: Namjae Jeon <[email protected]> Date: Sun Jul 23 15:22:33 2023 +0900 ksmbd: no response from compound read [ Upstream commit e202a1e8634b186da38cbbff85382ea2b9e297cf ] ksmbd doesn't support compound read. If client send read-read in compound to ksmbd, there can be memory leak from read buffer. Windows and linux clients doesn't send it to server yet. For now, No response from compound read. compound read will be supported soon. Reported-by: [email protected] # ZDI-CAN-21587, ZDI-CAN-21588 Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Namjae Jeon <[email protected]> Date: Sun Jul 23 15:21:11 2023 +0900 ksmbd: validate session id and tree id in compound request [ Upstream commit 3df0411e132ee74a87aa13142dfd2b190275332e ] `smb2_get_msg()` in smb2_get_ksmbd_tcon() and smb2_check_user_session() will always return the first request smb2 header in a compound request. if `SMB2_TREE_CONNECT_HE` is the first command in compound request, will return 0, i.e. The tree id check is skipped. This patch use ksmbd_req_buf_next() to get current command in compound. Reported-by: [email protected] # ZDI-CAN-21506 Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Torokhov <[email protected]> Date: Fri Jul 14 15:45:32 2023 -0700 kvm/vfio: ensure kvg instance stays around in kvm_vfio_group_add() [ Upstream commit 9e0f4f2918c2ff145d3dedee862d9919a6ed5812 ] kvm_vfio_group_add() creates kvg instance, links it to kv->group_list, and calls kvm_vfio_file_set_kvm() with kvg->file as an argument after dropping kv->lock. If we race group addition and deletion calls, kvg instance may get freed by the time we get around to calling kvm_vfio_file_set_kvm(). Previous iterations of the code did not reference kvg->file outside of the critical section, but used a temporary variable. Still, they had similar problem of the file reference being owned by kvg structure and potential for kvm_vfio_group_del() dropping it before kvm_vfio_group_add() had a chance to complete. Fix this by moving call to kvm_vfio_file_set_kvm() under the protection of kv->lock. We already call it while holding the same lock when vfio group is being deleted, so it should be safe here as well. Fixes: 2fc1bec15883 ("kvm: set/clear kvm to/from vfio_group when group add/delete") Reviewed-by: Alex Williamson <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yi Liu <[email protected]> Date: Tue Jul 18 06:55:29 2023 -0700 kvm/vfio: Prepare for accepting vfio device fd [ Upstream commit 2f99073a722beef5f74f3b0f32bda227ba3df1e0 ] This renames kvm_vfio_group related helpers to prepare for accepting vfio device fd. No functional change is intended. Reviewed-by: Kevin Tian <[email protected]> Reviewed-by: Eric Auger <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Tested-by: Terrence Xu <[email protected]> Tested-by: Nicolin Chen <[email protected]> Tested-by: Matthew Rosato <[email protected]> Tested-by: Yanting Jiang <[email protected]> Tested-by: Shameer Kolothum <[email protected]> Tested-by: Zhenzhong Duan <[email protected]> Signed-off-by: Yi Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]> Stable-dep-of: 9e0f4f2918c2 ("kvm/vfio: ensure kvg instance stays around in kvm_vfio_group_add()") Signed-off-by: Sasha Levin <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Thu Jun 1 17:58:59 2023 -0700 KVM: x86/mmu: Add "never" option to allow sticky disabling of nx_huge_pages commit 0b210faf337314e4bc88e796218bc70c72a51209 upstream. Add a "never" option to the nx_huge_pages module param to allow userspace to do a one-way hard disabling of the mitigation, and don't create the per-VM recovery threads when the mitigation is hard disabled. Letting userspace pinky swear that userspace doesn't want to enable NX mitigation (without reloading KVM) allows certain use cases to avoid the latency problems associated with spawning a kthread for each VM. E.g. in FaaS use cases, the guest kernel is trusted and the host may create 100+ VMs per logical CPU, which can result in 100ms+ latencies when a burst of VMs is created. Reported-by: Li RongQing <[email protected]> Closes: https://lore.kernel.org/all/[email protected] Cc: Yong He <[email protected]> Cc: Robert Hoo <[email protected]> Cc: Kai Huang <[email protected]> Reviewed-by: Robert Hoo <[email protected]> Acked-by: Kai Huang <[email protected]> Tested-by: Luiz Capitulino <[email protected]> Reviewed-by: Li RongQing <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Luiz Capitulino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Marek Behún <[email protected]> Date: Tue Aug 1 17:16:23 2023 +0200 leds: Fix BUG_ON check for LED_COLOR_ID_MULTI that is always false [ Upstream commit c3f853184bed04105682383c2971798c572226b5 ] At the time we call BUG_ON(props.color == LED_COLOR_ID_MULTI); the props variable is still initialized to zero. Call the BUG_ON only after we parse fwnode into props. Fixes: 77dce3a22e89 ("leds: disallow /sys/class/leds/*:multi:* for now") Signed-off-by: Marek Behún <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marek Behún <[email protected]> Date: Tue Aug 1 14:49:31 2023 +0200 leds: multicolor: Use rounded division when calculating color components [ Upstream commit 065d099f1be58187e6629273c50b948a02b7e1bf ] Given channel intensity, LED brightness and max LED brightness, the multicolor LED framework helper led_mc_calc_color_components() computes the color channel brightness as chan_brightness = brightness * chan_intensity / max_brightness Consider the situation when (brightness, intensity, max_brightness) is for example (16, 15, 255), then chan_brightness is computed to 0 although the fractional divison would give 0.94, which should be rounded to 1. Use DIV_ROUND_CLOSEST here for the division to give more realistic component computation: chan_brightness = DIV_ROUND_CLOSEST(brightness * chan_intensity, max_brightness) Fixes: 55d5d3b46b08 ("leds: multicolor: Introduce a multicolor class definition") Signed-off-by: Marek Behún <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Tue Jul 11 09:13:34 2023 +0300 leds: pwm: Fix error code in led_pwm_create_fwnode() [ Upstream commit cadb2de2a7fd9e955381307de3eddfcc386c208e ] Negative -EINVAL was intended, not positive EINVAL. Fix it. Fixes: 95138e01275e ("leds: pwm: Make error handling more robust") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marek Behún <[email protected]> Date: Wed Aug 2 11:07:53 2023 +0200 leds: trigger: tty: Do not use LED_ON/OFF constants, use led_blink_set_oneshot instead [ Upstream commit 730094577e0c37e1bc40be37cbd41f71b0a8a2a4 ] The tty LED trigger uses the obsolete LED_ON & LED_OFF constants when setting LED brightness. This is bad because the LED_ON constant is equal to 1, and so when activating the tty LED trigger on a LED class device with max_brightness greater than 1, the LED is dimmer than it can be (when max_brightness is 255, the LED is very dimm indeed; some devices translate 1/255 to 0, so the LED is OFF all the time). Instead of directly setting brightness to a specific value, use the led_blink_set_oneshot() function from LED core to configure the blink. This function takes the current configured brightness as blink brightness if not zero, and max brightness otherwise. This also changes the behavior of the TTY LED trigger. Previously if rx/tx stats kept changing, the LED was ON all the time they kept changing. With this patch the LED will blink on TTY activity. Fixes: fd4a641ac88f ("leds: trigger: implement a tty trigger") Signed-off-by: Marek Behún <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Andrii Nakryiko <[email protected]> Date: Mon Jul 10 19:41:50 2023 -0700 libbpf: Fix realloc API handling in zero-sized edge cases [ Upstream commit 8a0260dbf6553c969248b6530cafadac46562f47 ] realloc() and reallocarray() can either return NULL or a special non-NULL pointer, if their size argument is zero. This requires a bit more care to handle NULL-as-valid-result situation differently from NULL-as-error case. This has caused real issues before ([0]), and just recently bit again in production when performing bpf_program__attach_usdt(). This patch fixes 4 places that do or potentially could suffer from this mishandling of NULL, including the reported USDT-related one. There are many other places where realloc()/reallocarray() is used and NULL is always treated as an error value, but all those have guarantees that their size is always non-zero, so those spot don't need any extra handling. [0] d08ab82f59d5 ("libbpf: Fix double-free when linker processes empty sections") Fixes: 999783c8bbda ("libbpf: Wire up spec management and other arch-independent USDT logic") Fixes: b63b3c490eee ("libbpf: Add bpf_program__set_insns function") Fixes: 697f104db8a6 ("libbpf: Support custom SEC() handlers") Fixes: b12688267280 ("libbpf: Change the order of data and text relocations.") Signed-off-by: Andrii Nakryiko <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Andrii Nakryiko <[email protected]> Date: Fri Jul 7 16:11:56 2023 -0700 libbpf: only reset sec_def handler when necessary [ Upstream commit c628747cc8800cf6d33d09f7f42c8b6f91e64dc7 ] Don't reset recorded sec_def handler unconditionally on bpf_program__set_type(). There are two situations where this is wrong. First, if the program type didn't actually change. In that case original SEC handler should work just fine. Second, catch-all custom SEC handler is supposed to work with any BPF program type and SEC() annotation, so it also doesn't make sense to reset that. This patch fixes both issues. This was reported recently in the context of breaking perf tool, which uses custom catch-all handler for fancy BPF prologue generation logic. This patch should fix the issue. [0] https://lore.kernel.org/linux-perf-users/[email protected]/ Fixes: d6e6286a12e7 ("libbpf: disassociate section handler on explicit bpf_program__set_type() call") Reported-by: Ravi Bangoria <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Acked-by: Stanislav Fomichev <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Wed Sep 13 09:48:45 2023 +0200 Linux 6.4.16 Link: https://lore.kernel.org/r/[email protected] Tested-by: Shuah Khan <[email protected]> Tested-by: Bagas Sanjaya <[email protected]> Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Sudip Mukherjee <[email protected]> Tested-by: Justin M. Forbes <[email protected]> Tested-by: Conor Dooley <[email protected]> Tested-by: Jon Hunter <[email protected]> Tested-by: Florian Fainelli <[email protected]> Tested-by: Guenter Roeck <[email protected]> Tested-by: Ron Economos <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Uros Bizjak <[email protected]> Date: Sat Jul 8 11:00:36 2023 +0200 locking/arch: Avoid variable shadowing in local_try_cmpxchg() [ Upstream commit d6b45484c130f4095313ae3edeb4aae662c12fb1 ] Several architectures define arch_try_local_cmpxchg macro using internal temporary variables named ___old, __old or _old. Remove temporary varible in local_try_cmpxchg to avoid variable shadowing. No functional change intended. Fixes: d994f2c8e241 ("locking/arch: Wire up local_try_cmpxchg()") Closes: https://lore.kernel.org/lkml/CAFGhKbyxtuk=LoW-E3yLXgcmR93m+Dfo5-u9oQA_YC5Fcy_t9g@mail.gmail.com/ Reported-by: Charlemagne Lasse <[email protected]> Signed-off-by: Uros Bizjak <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Huacai Chen <[email protected]> Date: Sat Aug 26 22:21:57 2023 +0800 LoongArch: Ensure FP/SIMD registers in the core dump file is up to date [ Upstream commit 656f9aec07dba7c61d469727494a5d1b18d0bef4 ] This is a port of commit 379eb01c21795edb4c ("riscv: Ensure the value of FP registers in the core dump file is up to date"). The values of FP/SIMD registers in the core dump file come from the thread.fpu. However, kernel saves the FP/SIMD registers only before scheduling out the process. If no process switch happens during the exception handling, kernel will not have a chance to save the latest values of FP/SIMD registers. So it may cause their values in the core dump file incorrect. To solve this problem, force fpr_get()/simd_get() to save the FP/SIMD registers into the thread.fpu if the target task equals the current task. Cc: [email protected] Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhihong Dong <[email protected]> Date: Fri Jul 28 10:30:42 2023 +0800 LoongArch: Fix CMDLINE_EXTEND and CMDLINE_BOOTLOADER handling [ Upstream commit 83da30d73b86ab5898fb84f8b49c11557c3fcc67 ] On FDT systems these command line processing are already taken care of by early_init_dt_scan_chosen(). Add similar handling to the ACPI (non- FDT) code path to allow these config options to work for ACPI (non-FDT) systems too. Signed-off-by: Zhihong Dong <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hongchen Zhang <[email protected]> Date: Wed Sep 6 22:53:09 2023 +0800 LoongArch: mm: Add p?d_leaf() definitions commit 303be4b33562a5b689261ced1616bf16ad49efa7 upstream. When I do LTP test, LTP test case ksm06 caused panic at break_ksm_pmd_entry -> pmd_leaf (Huge page table but False) -> pte_present (panic) The reason is pmd_leaf() is not defined, So like commit 501b81046701 ("mips: mm: add p?d_leaf() definitions") add p?d_leaf() definition for LoongArch. Fixes: 09cfefb7fa70 ("LoongArch: Add memory management") Cc: [email protected] Acked-by: David Hildenbrand <[email protected]> Signed-off-by: Hongchen Zhang <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Huacai Chen <[email protected]> Date: Fri Jul 28 10:30:42 2023 +0800 LoongArch: Only fiddle with CHECKFLAGS if `need-compiler' [ Upstream commit 54c2c9df083fe1d4a9df54d9876f32582ce6d77a ] This is a port of commit 4fe4a6374c4db9ae2b ("MIPS: Only fiddle with CHECKFLAGS if `need-compiler'") to LoongArch. We have originally guarded fiddling with CHECKFLAGS in our arch Makefile by checking for the CONFIG_LOONGARCH variable, not set for targets such as `distclean', etc. that neither include `.config' nor use the compiler. Starting from commit 805b2e1d427aab4 ("kbuild: include Makefile.compiler only when compiler is needed") we have had a generic `need-compiler' variable explicitly telling us if the compiler will be used and thus its capabilities need to be checked and expressed in the form of compilation flags. If this variable is not set, then `make' functions such as `cc-option' are undefined, causing all kinds of weirdness to happen if we expect specific results to be returned. It doesn't cause problems on LoongArch now. But as a guard we replace the check for CONFIG_LOONGARCH with one for `need-compiler' instead, so as to prevent the compiler from being ever called for CHECKFLAGS when not needed. Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yan Zhai <[email protected]> Date: Thu Aug 17 19:58:14 2023 -0700 lwt: Check LWTUNNEL_XMIT_CONTINUE strictly [ Upstream commit a171fbec88a2c730b108c7147ac5e7b2f5a02b47 ] LWTUNNEL_XMIT_CONTINUE is implicitly assumed in ip(6)_finish_output2, such that any positive return value from a xmit hook could cause unexpected continue behavior, despite that related skb may have been freed. This could be error-prone for future xmit hook ops. One of the possible errors is to return statuses of dst_output directly. To make the code safer, redefine LWTUNNEL_XMIT_CONTINUE value to distinguish from dst_output statuses and check the continue condition explicitly. Fixes: 3a0af8fd61f9 ("bpf: BPF for lightweight tunnel infrastructure") Suggested-by: Dan Carpenter <[email protected]> Signed-off-by: Yan Zhai <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/96b939b85eda00e8df4f7c080f770970a4c5f698.1692326837.git.yan@cloudflare.com Signed-off-by: Sasha Levin <[email protected]>
Author: Yan Zhai <[email protected]> Date: Thu Aug 17 19:58:11 2023 -0700 lwt: Fix return values of BPF xmit ops [ Upstream commit 29b22badb7a84b783e3a4fffca16f7768fb31205 ] BPF encap ops can return different types of positive values, such like NET_RX_DROP, NET_XMIT_CN, NETDEV_TX_BUSY, and so on, from function skb_do_redirect and bpf_lwt_xmit_reroute. At the xmit hook, such return values would be treated implicitly as LWTUNNEL_XMIT_CONTINUE in ip(6)_finish_output2. When this happens, skbs that have been freed would continue to the neighbor subsystem, causing use-after-free bug and kernel crashes. To fix the incorrect behavior, skb_do_redirect return values can be simply discarded, the same as tc-egress behavior. On the other hand, bpf_lwt_xmit_reroute returns useful errors to local senders, e.g. PMTU information. Thus convert its return values to avoid the conflict with LWTUNNEL_XMIT_CONTINUE. Fixes: 3a0af8fd61f9 ("bpf: BPF for lightweight tunnel infrastructure") Reported-by: Jordan Griege <[email protected]> Suggested-by: Martin KaFai Lau <[email protected]> Suggested-by: Stanislav Fomichev <[email protected]> Signed-off-by: Yan Zhai <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/0d2b878186cfe215fec6b45769c1cd0591d3628d.1692326837.git.yan@cloudflare.com Signed-off-by: Sasha Levin <[email protected]>
Author: Ben Hutchings <[email protected]> Date: Fri Jun 16 17:36:10 2023 +0200 m68k: Fix invalid .section syntax [ Upstream commit 922a9bd138101e3e5718f0f4d40dba68ef89bb43 ] gas supports several different forms for .section for ELF targets, including: .section NAME [, "FLAGS"[, @TYPE[,FLAG_SPECIFIC_ARGUMENTS]]] and: .section "NAME"[, #FLAGS...] In several places we use a mix of these two forms: .section NAME, #FLAGS... A current development snapshot of binutils (2.40.50.20230611) treats this mixed syntax as an error. Change to consistently use: .section NAME, "FLAGS" as is used elsewhere in the kernel. Link: https://buildd.debian.org/status/fetch.php?pkg=linux&arch=m68k&ver=6.4%7Erc6-1%7Eexp1&stamp=1686907300&raw=1 Signed-off-by: Ben Hutchings <[email protected]> Tested-by: Jan-Benedict Glaw <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnd Bergmann <[email protected]> Date: Fri Jun 23 17:24:00 2023 +0200 mac80211: make ieee80211_tx_info padding explicit [ Upstream commit a7a2ef0c4b3efbd7d6f3fabd87dbbc0b3f2de5af ] While looking at a bug, I got rather confused by the layout of the 'status' field in ieee80211_tx_info. Apparently, the intention is that status_driver_data[] is used for driver specific data, and fills up the size of the union to 40 bytes, just like the other ones. This is indeed what actually happens, but only because of the combination of two mistakes: - "void *status_driver_data[18 / sizeof(void *)];" is intended to be 18 bytes long but is actually two bytes shorter because of rounding-down in the division, to a multiple of the pointer size (4 bytes or 8 bytes). - The other fields combined are intended to be 22 bytes long, but are actually 24 bytes because of padding in front of the unaligned tx_time member, and in front of the pointer array. The two mistakes cancel out. so the size ends up fine, but it seems more helpful to make this explicit, by having a multiple of 8 bytes in the size calculation and explicitly describing the padding. Fixes: ea5907db2a9cc ("mac80211: fix struct ieee80211_tx_info size") Fixes: 02219b3abca59 ("mac80211: add WMM admission control support") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yu Kuai <[email protected]> Date: Thu Jul 6 16:37:27 2023 +0800 md/md-bitmap: hold 'reconfig_mutex' in backlog_store() [ Upstream commit 44abfa6a95df425c0660d56043020b67e6d93ab8 ] Several reasons why 'reconfig_mutex' should be held: 1) rdev_for_each() is not safe to be called without the lock, because rdev can be removed concurrently. 2) mddev_destroy_serial_pool() and mddev_create_serial_pool() should not be called concurrently. 3) mddev_suspend() from mddev_destroy/create_serial_pool() should be protected by the lock. Fixes: 10c92fca636e ("md-bitmap: create and destroy wb_info_pool with the change of backlog") Signed-off-by: Yu Kuai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Song Liu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yu Kuai <[email protected]> Date: Thu Jul 6 16:37:26 2023 +0800 md/md-bitmap: remove unnecessary local variable in backlog_store() [ Upstream commit b4d129640f194ffc4cc64c3e97f98ae944c072e8 ] Local variable is definied first in the beginning of backlog_store(), there is no need to define it again. Fixes: 8c13ab115b57 ("md/bitmap: don't set max_write_behind if there is no write mostly device") Signed-off-by: Yu Kuai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Song Liu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jan Kara <[email protected]> Date: Mon Aug 14 11:27:07 2023 +0200 md/raid0: Factor out helper for mapping and submitting a bio [ Upstream commit af50e20afb401cc203bd2a9ff62ece0ae4976103 ] Factor out helper function for mapping and submitting a bio out of raid0_make_request(). We will use it later for submitting both parts of a split bio. Signed-off-by: Jan Kara <[email protected]> Reviewed-by: Yu Kuai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Song Liu <[email protected]> Stable-dep-of: 319ff40a5427 ("md/raid0: Fix performance regression for large sequential writes") Signed-off-by: Sasha Levin <[email protected]>
Author: Jan Kara <[email protected]> Date: Mon Aug 14 11:27:08 2023 +0200 md/raid0: Fix performance regression for large sequential writes [ Upstream commit 319ff40a542736d67e5bce18635de35d0e7a0bff ] Commit f00d7c85be9e ("md/raid0: fix up bio splitting.") among other things changed how bio that needs to be split is submitted. Before this commit, we have split the bio, mapped and submitted each part. After this commit, we map only the first part of the split bio and submit the second part unmapped. Due to bio sorting in __submit_bio_noacct() this results in the following request ordering: 9,0 18 1181 0.525037895 15995 Q WS 1479315464 + 63392 Split off chunk-sized (1024 sectors) request: 9,0 18 1182 0.629019647 15995 X WS 1479315464 / 1479316488 Request is unaligned to the chunk so it's split in raid0_make_request(). This is the first part mapped and punted to bio_list: 8,0 18 7053 0.629020455 15995 A WS 739921928 + 1016 <- (9,0) 1479315464 Now raid0_make_request() returns, second part is postponed on bio_list. __submit_bio_noacct() resorts the bio_list, mapped request is submitted to the underlying device: 8,0 18 7054 0.629022782 15995 G WS 739921928 + 1016 Now we take another request from the bio_list which is the remainder of the original huge request. Split off another chunk-sized bit from it and the situation repeats: 9,0 18 1183 0.629024499 15995 X WS 1479316488 / 1479317512 8,16 18 6998 0.629025110 15995 A WS 739921928 + 1016 <- (9,0) 1479316488 8,16 18 6999 0.629026728 15995 G WS 739921928 + 1016 ... 9,0 18 1184 0.629032940 15995 X WS 1479317512 / 1479318536 [libnetacq-write] 8,0 18 7059 0.629033294 15995 A WS 739922952 + 1016 <- (9,0) 1479317512 8,0 18 7060 0.629033902 15995 G WS 739922952 + 1016 ... This repeats until we consume the whole original huge request. Now we finally get to processing the second parts of the split off requests (in reverse order): 8,16 18 7181 0.629161384 15995 A WS 739952640 + 8 <- (9,0) 1479377920 8,0 18 7239 0.629162140 15995 A WS 739952640 + 8 <- (9,0) 1479376896 8,16 18 7186 0.629163881 15995 A WS 739951616 + 8 <- (9,0) 1479375872 8,0 18 7242 0.629164421 15995 A WS 739951616 + 8 <- (9,0) 1479374848 ... I guess it is obvious that this IO pattern is extremely inefficient way to perform sequential IO. It also makes bio_list to grow to rather long lengths. Change raid0_make_request() to map both parts of the split bio. Since we know we are provided with at most chunk-sized bios, we will always need to split the incoming bio at most once. Fixes: f00d7c85be9e ("md/raid0: fix up bio splitting.") Signed-off-by: Jan Kara <[email protected]> Reviewed-by: Yu Kuai <yu[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Song Liu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Li Nan <[email protected]> Date: Sat Jul 1 16:05:28 2023 +0800 md/raid10: factor out dereference_rdev_and_rrdev() [ Upstream commit b99f8fd2d91eb734f13098aa1cf337edaca454b7 ] Factor out a helper to get 'rdev' and 'replacement' from config->mirrors. Just to make code cleaner and prepare to fix the bug of io loss while 'replacement' replace 'rdev'. There is no functional change. Signed-off-by: Li Nan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Song Liu <[email protected]> Stable-dep-of: 673643490b9a ("md/raid10: use dereference_rdev_and_rrdev() to get devices") Signed-off-by: Sasha Levin <[email protected]>
Author: Li Nan <[email protected]> Date: Sat Jul 1 16:05:29 2023 +0800 md/raid10: use dereference_rdev_and_rrdev() to get devices [ Upstream commit 673643490b9a0eb3b25633abe604f62b8f63dba1 ] Commit 2ae6aaf76912 ("md/raid10: fix io loss while replacement replace rdev") reads replacement first to prevent io loss. However, there are same issue in wait_blocked_dev() and raid10_handle_discard(), too. Fix it by using dereference_rdev_and_rrdev() to get devices. Fixes: d30588b2731f ("md/raid10: improve raid10 discard request") Fixes: f2e7e269a752 ("md/raid10: pull the code that wait for blocked dev into one function") Signed-off-by: Li Nan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Song Liu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yu Kuai <[email protected]> Date: Sat Jul 8 17:17:27 2023 +0800 md/raid5-cache: fix a deadlock in r5l_exit_log() [ Upstream commit a705b11b358dee677aad80630e7608b2d5f56691 ] Commit b13015af94cf ("md/raid5-cache: Clear conf->log after finishing work") introduce a new problem: // caller hold reconfig_mutex r5l_exit_log flush_work(&log->disable_writeback_work) r5c_disable_writeback_async wait_event /* * conf->log is not NULL, and mddev_trylock() * will fail, wait_event() can never pass. */ conf->log = NULL Fix this problem by setting 'config->log' to NULL before wake_up() as it used to be, so that wait_event() from r5c_disable_writeback_async() can exist. In the meantime, move forward md_unregister_thread() so that null-ptr-deref this commit fixed can still be fixed. Fixes: b13015af94cf ("md/raid5-cache: Clear conf->log after finishing work") Signed-off-by: Yu Kuai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Song Liu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yu Kuai <[email protected]> Date: Tue Aug 8 18:49:12 2023 +0800 md/raid5-cache: fix null-ptr-deref for r5l_flush_stripe_to_raid() [ Upstream commit 0d0bd28c500173bfca78aa840f8f36d261ef1765 ] r5l_flush_stripe_to_raid() will check if the list 'flushing_ios' is empty, and then submit 'flush_bio', however, r5l_log_flush_endio() is clearing the list first and then clear the bio, which will cause null-ptr-deref: T1: submit flush io raid5d handle_active_stripes r5l_flush_stripe_to_raid // list is empty // add 'io_end_ios' to the list bio_init submit_bio // io1 T2: io1 is done r5l_log_flush_endio list_splice_tail_init // clear the list T3: submit new flush io ... r5l_flush_stripe_to_raid // list is empty // add 'io_end_ios' to the list bio_init bio_uninit // clear bio->bi_blkg submit_bio // null-ptr-deref Fix this problem by clearing bio before clearing the list in r5l_log_flush_endio(). Fixes: 0dd00cba99c3 ("raid5-cache: fully initialize flush_bio when needed") Reported-and-tested-by: Corey Hickey <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Yu Kuai <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Song Liu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David Jeffery <[email protected]> Date: Wed Aug 16 14:13:55 2023 -0400 md: raid0: account for split bio in iostat accounting [ Upstream commit cc22b5407e9ca76adb7efeed843146510b1b72a5 ] When a bio is split by md raid0, the newly created bio will not be tracked by md for I/O accounting. Only the portion of I/O still assigned to the original bio which was reduced by the split will be accounted for. This results in md iostat data sometimes showing I/O values far below the actual amount of data being sent through md. md_account_bio() needs to be called for all bio generated by the bio split. A simple example of the issue was generated using a raid0 device on partitions to the same device. Since all raid0 I/O then goes to one device, it makes it easy to see a gap between the md device and its sd storage. Reading an lvm device on top of the md device, the iostat output (some 0 columns and extra devices removed to make the data more compact) was: Device tps kB_read/s kB_wrtn/s kB_dscd/s kB_read md2 0.00 0.00 0.00 0.00 0 sde 0.00 0.00 0.00 0.00 0 md2 1364.00 411496.00 0.00 0.00 411496 sde 1734.00 646144.00 0.00 0.00 646144 md2 1699.00 510680.00 0.00 0.00 510680 sde 2155.00 802784.00 0.00 0.00 802784 md2 803.00 241480.00 0.00 0.00 241480 sde 1016.00 377888.00 0.00 0.00 377888 md2 0.00 0.00 0.00 0.00 0 sde 0.00 0.00 0.00 0.00 0 I/O was generated doing large direct I/O reads (12M) with dd to a linear lvm volume on top of the 4 leg raid0 device. The md2 reads were showing as roughly 2/3 of the reads to the sde device containing all of md2's raid partitions. The sum of reads to sde was 1826816 kB, which was the expected amount as it was the amount read by dd. With the patch, the total reads from md will match the reads from sde and be consistent with the amount of I/O generated. Fixes: 10764815ff47 ("md: add io accounting for raid0 and raid5") Signed-off-by: David Jeffery <[email protected]> Tested-by: Laurence Oberman <lob[email protected]> Reviewed-by: Laurence Oberman <[email protected]> Reviewed-by: Yu Kuai <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Yu Kuai <[email protected]> Date: Wed Jun 28 09:29:31 2023 +0800 md: restore 'noio_flag' for the last mddev_resume() [ Upstream commit e24ed04389f9619e0aaef615a8948633c182a8b0 ] memalloc_noio_save() is called for the first mddev_suspend(), and repeated mddev_suspend() only increase 'suspended'. However, memalloc_noio_restore() is also called for the first mddev_resume(), which means that memory reclaim will be enabled before the last mddev_resume() is called, while the array is still suspended. Fix this problem by restore 'noio_flag' for the last mddev_resume(). Fixes: 78f57ef9d50a ("md: use memalloc scope APIs in mddev_suspend()/mddev_resume()") Signed-off-by: Yu Kuai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Song Liu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Sun Jun 18 20:17:40 2023 +0200 media: ad5820: Drop unsupported ad5823 from i2c_ and of_device_id tables [ Upstream commit f126ff7e4024f6704e6ec0d4137037568708a3c7 ] The supported ad5820 and ad5821 VCMs both use a single 16 bit register which is written by sending 2 bytes with the data directly after sending the i2c-client address. The ad5823 OTOH has a more typical i2c / smbus device setup with multiple 8 bit registers where the first byte send after the i2c-client address is the register address and the actual data only starts from the second byte after the i2c-client address. The ad5823 i2c_ and of_device_id-s was added at the same time as the ad5821 ids with as rationale: """ Some camera modules also refer that AD5823 is a replacement of AD5820: https://download.kamami.com/p564094-OV8865_DS.pdf """ The AD5823 may be an electrical and functional replacement of the AD5820, but from a software pov it is not compatible at all and it is going to need its own driver, drop its id from the ad5820 driver. Fixes: b8bf73136bae ("media: ad5820: Add support for ad5821 and ad5823") Cc: Pavel Machek <[email protected]> Cc: Ricardo Ribalda Delgado <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Ricardo Ribalda <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Qian <[email protected]> Date: Tue Jun 13 17:14:08 2023 +0800 media: amphion: add helper function to get id name [ Upstream commit 12cd8b8ac02525977b2e860a877add10e8ce7468 ] convert numbers into meaningful names, then it can improve the log readability Fixes: 9f599f351e86 ("media: amphion: add vpu core driver") Signed-off-by: Ming Qian <[email protected]> Reviewed-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Qian <[email protected]> Date: Mon Jul 10 15:44:11 2023 +0800 media: amphion: decoder support display delay for all formats [ Upstream commit b69713f502027150ecc08e663fa1804d78b3ef42 ] the firmware only support low latency mode for h264, but firmware will notify an event to driver when one frame is decoded, if V4L2_CID_MPEG_VIDEO_DEC_DISPLAY_DELAY_ENABLE is enabled, and V4L2_CID_MPEG_VIDEO_DEC_DISPLAY_DELAY is set to 0, driver can display the decoded frame immediately. Fixes: ffa331d9bf94 ("media: amphion: decoder implement display delay enable") Signed-off-by: Ming Qian <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Qian <[email protected]> Date: Tue Jul 18 17:50:13 2023 +0800 media: amphion: ensure the bitops don't cross boundaries [ Upstream commit 5bd28eae48589694ff4e5badb03bf75dae695b3f ] the supported_instance_count determine the instance index range, it shouldn't exceed the bits number of instance_mask, otherwise the bitops of instance_mask may cross boundaries Fixes: 9f599f351e86 ("media: amphion: add vpu core driver") Reviewed-by: Nicolas Dufresne <[email protected]> Signed-off-by: Ming Qian <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Qian <[email protected]> Date: Tue Jul 18 17:50:09 2023 +0800 media: amphion: fix CHECKED_RETURN issues reported by coverity [ Upstream commit b237b058adbc7825da9c8f358f1ff3f0467d623a ] calling "vpu_cmd_send/vpu_get_buffer_state/vpu_session_alloc_fs" without checking return value Fixes: 9f599f351e86 ("media: amphion: add vpu core driver") Reviewed-by: Nicolas Dufresne <[email protected]> Signed-off-by: Ming Qian <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Qian <[email protected]> Date: Tue Jul 18 17:50:10 2023 +0800 media: amphion: fix REVERSE_INULL issues reported by coverity [ Upstream commit 79d3bafaecc13bccab1ebbd28a15e669c5a4cdaf ] null-checking of a pointor is suggested before dereferencing it Fixes: 9f599f351e86 ("media: amphion: add vpu core driver") Reviewed-by: Nicolas Dufresne <[email protected]> Signed-off-by: Ming Qian <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Qian <[email protected]> Date: Tue Jul 18 17:50:11 2023 +0800 media: amphion: fix UNINIT issues reported by coverity [ Upstream commit c224d0497a31ea2d173e1ea16af308945bff9037 ] using uninitialized value may introduce risk Fixes: 9f599f351e86 ("media: amphion: add vpu core driver") Reviewed-by: Nicolas Dufresne <[email protected]> Signed-off-by: Ming Qian <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Qian <[email protected]> Date: Tue Jul 18 17:50:12 2023 +0800 media: amphion: fix UNUSED_VALUE issue reported by coverity [ Upstream commit cf6a06354989c41b536be8e094561ee16223cf1f ] assign value '-EINVAL' to ret, but the stored value is overwritten before it can be used Fixes: 9f599f351e86 ("media: amphion: add vpu core driver") Reviewed-by: Nicolas Dufresne <[email protected]> Signed-off-by: Ming Qian <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Qian <[email protected]> Date: Tue Jun 13 15:48:46 2023 +0800 media: amphion: reinit vpu if reqbufs output 0 [ Upstream commit 73e3f09292a0492a3fe0f87a8170a74f12624c5e ] according to v4l2 stateful decoder document 4.5.1.3. State Machine, the state should change from seek to initialization if call VIDIOC_REQBUFS(OUTPUT, 0). so reinit the vpu decoder if reqbufs output 0 Fixes: 6de8d628df6e ("media: amphion: add v4l2 m2m vpu decoder stateful driver") Signed-off-by: Ming Qian <[email protected]> Tested-by: Nicolas Dufresne <[email protected]> Reviewed-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Stein <[email protected]> Date: Tue Jan 31 11:32:44 2023 +0100 media: amphion: use dev_err_probe [ Upstream commit 517f088385e1b8015606143e6212cb30f8714070 ] This simplifies the code and silences -517 error messages. Also the reason is listed in /sys/kernel/debug/devices_deferred. Signed-off-by: Alexander Stein <[email protected]> Reviewed-by: ming_qian <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans Verkuil <[email protected]> Date: Mon Jun 12 15:58:37 2023 +0200 media: cec: core: add adap_nb_transmit_canceled() callback [ Upstream commit da53c36ddd3f118a525a04faa8c47ca471e6c467 ] A potential deadlock was found by Zheng Zhang with a local syzkaller instance. The problem is that when a non-blocking CEC transmit is canceled by calling cec_data_cancel, that in turn can call the high-level received() driver callback, which can call cec_transmit_msg() to transmit a new message. The cec_data_cancel() function is called with the adap->lock mutex held, and cec_transmit_msg() tries to take that same lock. The root cause is that the received() callback can either be used to pass on a received message (and then adap->lock is not held), or to report a canceled transmit (and then adap->lock is held). This is confusing, so create a new low-level adap_nb_transmit_canceled callback that reports back that a non-blocking transmit was canceled. And the received() callback is only called when a message is received, as was the case before commit f9d0ecbf56f4 ("media: cec: correctly pass on reply results") complicated matters. Reported-by: Zheng Zhang <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Fixes: f9d0ecbf56f4 ("media: cec: correctly pass on reply results") Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans Verkuil <[email protected]> Date: Mon Jun 12 15:58:38 2023 +0200 media: cec: core: add adap_unconfigured() callback [ Upstream commit 948a77aaecf202f722cf2264025f9987e5bd5c26 ] The adap_configured() callback was called with the adap->lock mutex held if the 'configured' argument was false, and without the adap->lock mutex held if that argument was true. That was very confusing, and so split this up in a adap_unconfigured() callback and a high-level configured() callback. This also makes it easier to understand when the mutex is held: all low-level adap_* callbacks are called with the mutex held. All other callbacks are called without that mutex held. Signed-off-by: Hans Verkuil <[email protected]> Fixes: f1b57164305d ("media: cec: add optional adap_configured callback") Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniil Dulov <[email protected]> Date: Fri Jun 2 01:55:01 2023 -0700 media: cx24120: Add retval check for cx24120_message_send() [ Upstream commit 96002c0ac824e1773d3f706b1f92e2a9f2988047 ] If cx24120_message_send() returns error, we should keep local struct unchanged. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 5afc9a25be8d ("[media] Add support for TechniSat Skystar S2") Signed-off-by: Daniil Dulov <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniil Dulov <[email protected]> Date: Fri Mar 24 06:38:32 2023 -0700 media: dib7000p: Fix potential division by zero [ Upstream commit a1db7b2c5533fc67e2681eb5efc921a67bc7d5b8 ] Variable loopdiv can be assigned 0, then it is used as a denominator, without checking it for 0. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 713d54a8bd81 ("[media] DiB7090: add support for the dib7090 based") Signed-off-by: Daniil Dulov <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> [hverkuil: (bw != NULL) -> bw] Signed-off-by: Sasha Levin <[email protected]>
Author: Tomi Valkeinen <[email protected]> Date: Thu Jul 20 10:08:28 2023 +0200 media: Documentation: Fix [GS]_ROUTING documentation [ Upstream commit 997a6b01cd97b74684728d5af6511c333f25957d ] Add mention that successful VIDIOC_SUBDEV_G_ROUTING call will update 'num_routes' and remove mention about non-existing streams, which is incorrect. Fixes: ea73eda50813 ("media: Documentation: Add GS_ROUTING documentation") Signed-off-by: Tomi Valkeinen <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christophe JAILLET <[email protected]> Date: Mon May 29 07:58:36 2023 +0200 media: dvb-usb: m920x: Fix a potential memory leak in m920x_i2c_xfer() [ Upstream commit ea9ef6c2e001c5dc94bee35ebd1c8a98621cf7b8 ] 'read' is freed when it is known to be NULL, but not when a read error occurs. Revert the logic to avoid a small leak, should a m920x_read() call fail. Fixes: a2ab06d7c4d6 ("media: m920x: don't use stack on USB reads") Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Fri Sep 8 10:20:36 2023 +0100 media: dvb: symbol fixup for dvb_attach() commit 86495af1171e1feec79faa9b64c05c89f46e41d1 upstream. In commit 9011e49d54dc ("modules: only allow symbol_get of EXPORT_SYMBOL_GPL modules") the use of symbol_get is properly restricted to GPL-only marked symbols. This interacts oddly with the DVB logic which only uses dvb_attach() to load the dvb driver which then uses symbol_get(). Fix this up by properly marking all of the dvb_attach attach symbols as EXPORT_SYMBOL_GPL(). Fixes: 9011e49d54dc ("modules: only allow symbol_get of EXPORT_SYMBOL_GPL modules") Cc: stable <[email protected]> Reported-by: Stefan Lippers-Hollmann <[email protected]> Cc: Mauro Carvalho Chehab <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: [email protected] Cc: [email protected] Acked-by: Luis Chamberlain <[email protected]> Acked-by: Hans Verkuil <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Colin Ian King <[email protected]> Date: Thu Jul 27 19:40:07 2023 +0200 media: go7007: Remove redundant if statement [ Upstream commit f33cb49081da0ec5af0888f8ecbd566bd326eed1 ] The if statement that compares msgs[i].len != 3 is always false because it is in a code block where msg[i].len is equal to 3. The check is redundant and can be removed. As detected by cppcheck static analysis: drivers/media/usb/go7007/go7007-i2c.c:168:20: warning: Opposite inner 'if' condition leads to a dead code block. [oppositeInnerCondition] Link: https://lore.kernel.org/linux-media/[email protected] Fixes: 866b8695d67e ("Staging: add the go7007 video driver") Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sakari Ailus <[email protected]> Date: Thu Jun 15 10:29:07 2023 +0200 media: i2c: Add a camera sensor top level menu commit 7d3c7d2a2914e10bec3b9cdacdadb8e1f65f715a upstream. Select V4L2_FWNODE and VIDEO_V4L2_SUBDEV_API for all sensor drivers. This also adds the options to drivers that don't specifically need them, these are still seldom used drivers using old APIs. The upside is that these should now all compile --- many drivers have had missing dependencies. The "menu" is replaced by selectable "menuconfig" to select the needed V4L2_FWNODE and VIDEO_V4L2_SUBDEV_API options. Also select MEDIA_CONTROLLER which VIDEO_V4L2_SUBDEV_API effectively depends on, and add the I2C dependency to the menu. Reported-by: Hans de Goede <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Cc: [email protected] # for >= 6.1 Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sakari Ailus <[email protected]> Date: Sat Jul 29 20:59:25 2023 +0200 media: i2c: ccs: Check rules is non-NULL commit 607bcc4213d998d051541d8f10b5bbb7d546c0be upstream. Fix the following smatch warning: drivers/media/i2c/ccs/ccs-data.c:524 ccs_data_parse_rules() warn: address of NULL pointer 'rules' The CCS static data rule parser does not check an if rule has been obtained before checking for other rule types (which depend on the if rule). In practice this means parsing invalid CCS static data could lead to dereferencing a NULL pointer. Reported-by: Hans Verkuil <[email protected]> Fixes: a6b396f410b1 ("media: ccs: Add CCS static data parser library") Cc: [email protected] # for 5.11 and up Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tommaso Merciai <[email protected]> Date: Tue Jun 13 10:07:34 2023 +0200 media: i2c: imx290: drop format param from imx290_ctrl_update [ Upstream commit 9b4e0e7a570d222be5f5e0f914d3c4528eadeeb4 ] The format param actually is not used in imx290_ctrl_update function, let's drop this Fixes: bc35f9a21a55 ("media: i2c: imx290: Fix the pixel rate at 148.5Mpix/s") Signed-off-by: Tommaso Merciai <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jacopo Mondi <[email protected]> Date: Thu Aug 10 15:33:37 2023 +0200 media: i2c: rdacm21: Fix uninitialized value [ Upstream commit 33c7ae8f49e3413c81e879e1fdfcea4c5516e37b ] Fix the following smatch warning: drivers/media/i2c/rdacm21.c:373 ov10640_check_id() error: uninitialized symbol 'val'. Initialize 'val' to 0 in the ov10640_check_id() function. Fixes: 2b821698dc73 ("media: i2c: rdacm21: Power up OV10640 before OV490") Reported-by: Hans Verkuil <[email protected]> Signed-off-by: Jacopo Mondi <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Claudiu Beznea <[email protected]> Date: Thu Jun 15 12:30:30 2023 +0200 media: i2c: tvp5150: check return value of devm_kasprintf() [ Upstream commit 26ce7054d804be73935b9268d6e0ecf2fbbc8aef ] devm_kasprintf() returns a pointer to dynamically allocated memory. Pointer could be NULL in case allocation fails. Check pointer validity. Identified with coccinelle (kmerr.cocci script). Fixes: 0556f1d580d4 ("media: tvp5150: add input source selection of_graph support") Signed-off-by: Claudiu Beznea <[email protected]> Reviewed-by: Marco Felsch <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Qian <[email protected]> Date: Tue May 30 09:16:30 2023 +0200 media: imx-jpeg: Support to assign slot for encoder/decoder [ Upstream commit 53ebeea50599c1ed05277d7a57e331a34e6d6a82 ] imx jpeg encoder and decoder support 4 slots each, aim to support some virtualization scenarios. driver should only enable one slot one time. but due to some hardware issue, only slot 0 can be enabled in imx8q platform, and they may be fixed in imx9 platform. Signed-off-by: Ming Qian <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Wed Jul 5 23:29:54 2023 +0200 media: ipu-bridge: Do not use on stack memory for software_node.name field [ Upstream commit 11e0a7c8e04ee5f406f2baa27761746cbedcfa11 ] Commit 567f97bd381f ("media: ipu3-cio2: support multiple sensors and VCMs with same HID") introduced an on stack vcm_name and then uses this for the name field of the software_node struct used for the vcm. But the software_node struct is much longer lived then the current stack-frame, so this is no good. Instead extend the ipu_node_names struct with an extra field to store the vcm software_node name and use that. Note this also changes the length of the allocated buffer from ACPI_ID_LEN + 4 to 16. the name is filled with "<ipu_vcm_types[x]>-%u" where ipu_vcm_types[x] is not an ACPI_ID. The maximum length of the strings in the ipu_vcm_types[] array is 11 + 5 bytes for "-255\0" means 16 bytes are needed in the worst case scenario. Fixes: 567f97bd381f ("media: ipu3-cio2: support multiple sensors and VCMs with same HID") Cc: Bingbu Cao <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Reviewed-by: Daniel Scally <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Wed Jul 5 23:29:53 2023 +0200 media: ipu-bridge: Fix null pointer deref on SSDB/PLD parsing warnings [ Upstream commit 284be5693163343e1cf17c03917eecd1d6681bcf ] When ipu_bridge_parse_rotation() and ipu_bridge_parse_orientation() run sensor->adev is not set yet. So if either of the dev_warn() calls about unknown values are hit this will lead to a NULL pointer deref. Set sensor->adev earlier, with a borrowed ref to avoid making unrolling on errors harder, to fix this. Fixes: 485aa3df0dff ("media: ipu3-cio2: Parse sensor orientation and rotation") Cc: Fabian Wüthrich <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Daniel Scally <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnd Bergmann <[email protected]> Date: Thu Jul 27 14:22:58 2023 +0200 media: ipu3-cio2: allow ipu_bridge to be a module again commit 2545a2c02ba1da9cfb9ec218623c71b00eb4a555 upstream. This code was previously part of the VIDEO_IPU3_CIO2 driver, which could be built-in or a loadable module, but after the move it turned into a builtin-only driver. This fails to link when the I2C subsystem is a module: x86_64-linux-ld: drivers/media/pci/intel/ipu-bridge.o: in function `ipu_bridge_unregister_sensors': ipu-bridge.c:(.text+0x50): undefined reference to `i2c_unregister_device' x86_64-linux-ld: drivers/media/pci/intel/ipu-bridge.o: in function `ipu_bridge_init': ipu-bridge.c:(.text+0x9c9): undefined reference to `i2c_acpi_new_device_by_fwnode' In general, drivers should not have to be built-in, so change the option to a tristate with the corresponding dependency. This in turn opens a new problem with the dependency, as the IPU bridge can be a loadable module while the ipu3 driver itself is built-in, producing a new link failure: 86_64-linux-ld: drivers/media/pci/intel/ipu3/ipu3-cio2.o: in function `cio2_pci_probe': ipu3-cio2.c:(.text+0x197e): undefined reference to `ipu_bridge_init' In order to fix this, restore the old Kconfig option that controlled the ipu bridge driver before it was split out, but make it select a hidden symbol that now corresponds to the bridge driver. When other drivers get added that share ipu-bridge, this should cover all corner cases, and allow any combination of them to be built-in or modular. Link: https://lore.kernel.org/linux-media/[email protected] Fixes: 881ca25978c6 ("media: ipu3-cio2: rename cio2 bridge to ipu bridge and move out of ipu3")' Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bingbu Cao <[email protected]> Date: Thu May 18 12:05:21 2023 +0200 media: ipu3-cio2: rename cio2 bridge to ipu bridge and move out of ipu3 [ Upstream commit 881ca25978c6f536a00205daa8b2452edd057ff9 ] cio2 bridge was involved along with IPU3. However, in fact all Intel IPUs besides IPU3 CIO2 need this bridge driver. This patch move bridge driver out of ipu3 directory and rename as ipu-bridge. Then it can be worked with IPU3 and other Intel IPUs. Signed-off-by: Bingbu Cao <[email protected]> Reviewed-by: Daniel Scally <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Stable-dep-of: 11e0a7c8e04e ("media: ipu-bridge: Do not use on stack memory for software_node.name field") Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Wed Jun 14 16:05:39 2023 +0300 media: mediatek: vcodec: fix potential double free [ Upstream commit be40f524b6edac4fb9a98ef79620fd9b9497a998 ] The "lat_buf->private_data" needs to be set to NULL to prevent a double free. How this would happen is if vdec_msg_queue_init() failed twice in a row and on the second time it failed earlier than on the first time. The vdec_msg_queue_init() function has a loop which does: for (i = 0; i < NUM_BUFFER_COUNT; i++) { Each iteration initializes one element in the msg_queue->lat_buf[] array and then the clean up function vdec_msg_queue_deinit() frees each element of the msg_queue->lat_buf[] array. This clean up code relies on the assumption that every element is either initialized or zeroed. Leaving a freed pointer which is non-zero breaks the assumption. Fixes: b199fe46f35c ("media: mtk-vcodec: Add msg queue feature for lat and core architecture") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Wed Jun 14 16:06:47 2023 +0300 media: mediatek: vcodec: fix resource leaks in vdec_msg_queue_init() [ Upstream commit cf10b0bb503c974ba049d6f888b21178be20a962 ] If we encounter any error in the vdec_msg_queue_init() then we need to set "msg_queue->wdma_addr.size = 0;". Normally, this is done inside the vdec_msg_queue_deinit() function. However, if the first call to allocate &msg_queue->wdma_addr fails, then the vdec_msg_queue_deinit() function is a no-op. For that situation, just set the size to zero explicitly and return. There were two other error paths which did not clean up before returning. Change those error paths to goto mem_alloc_err. Fixes: b199fe46f35c ("media: mtk-vcodec: Add msg queue feature for lat and core architecture") Fixes: 2f5d0aef37c6 ("media: mediatek: vcodec: support stateless AV1 decoder") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Irui Wang <[email protected]> Date: Wed Jul 5 17:14:41 2023 +0800 media: mediatek: vcodec: Return NULL if no vdec_fb is found [ Upstream commit dfa2d6e07432270330ae191f50a0e70636a4cd2b ] "fb_use_list" is used to store used or referenced frame buffers for vp9 stateful decoder. "NULL" should be returned when getting target frame buffer failed from "fb_use_list", not a random unexpected one. Fixes: f77e89854b3e ("[media] vcodec: mediatek: Add Mediatek VP9 Video Decoder Driver") Signed-off-by: Irui Wang <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zheng Wang <[email protected]> Date: Fri Jul 7 17:24:14 2023 +0800 media: mtk-jpeg: Fix use after free bug due to uncanceled work [ Upstream commit c677d7ae83141d390d1253abebafa49c962afb52 ] In mtk_jpeg_probe, &jpeg->job_timeout_work is bound with mtk_jpeg_job_timeout_work. Then mtk_jpeg_dec_device_run and mtk_jpeg_enc_device_run may be called to start the work. If we remove the module which will call mtk_jpeg_remove to make cleanup, there may be a unfinished work. The possible sequence is as follows, which will cause a typical UAF bug. Fix it by canceling the work before cleanup in the mtk_jpeg_remove CPU0 CPU1 |mtk_jpeg_job_timeout_work mtk_jpeg_remove | v4l2_m2m_release | kfree(m2m_dev); | | | v4l2_m2m_get_curr_priv | m2m_dev->curr_ctx //use Fixes: b2f0d2724ba4 ("[media] vcodec: mediatek: Add Mediatek JPEG Decoder Driver") Signed-off-by: Zheng Wang <[email protected]> Reviewed-by: Alexandre Mergnat <[email protected]> Reviewed-by: Chen-Yu Tsai <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yang Yingliang <[email protected]> Date: Tue Jul 25 21:00:24 2023 +0800 media: nxp: Fix wrong return pointer check in mxc_isi_crossbar_init() commit 4b60db99babad0254129ddc58e0927ffa9e93e35 upstream. It should check 'xbar->inputs', when allocate memory for it. Cc: [email protected] Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver") Signed-off-by: Yang Yingliang <[email protected]> Reviewed-by: Fabio Estevam <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Hans de Goede <[email protected]> Date: Thu Aug 3 11:33:21 2023 +0200 media: ov2680: Add ov2680_fill_format() helper function [ Upstream commit 6d6849b2203f3244b575ba01d3e41ee19aa2cadf ] Add a ov2680_fill_format() helper function and use this everywhere were a v4l2_mbus_framefmt struct needs to be filled in so that the driver always fills it consistently. This is a preparation patch for fixing ov2680_set_fmt() which == V4L2_SUBDEV_FORMAT_TRY calls not properly filling in the passed in v4l2_mbus_framefmt struct. Note that for ov2680_init_cfg() this now simply always fills the try_fmt struct of the passed in sd_state. This is correct because ov2680_init_cfg() is never called with a NULL sd_state so the old sd_state check is not necessary. Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver") Acked-by: Rui Miguel Silva <[email protected]> Reviewed-by: Daniel Scally <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Thu Aug 3 11:33:20 2023 +0200 media: ov2680: Don't take the lock for try_fmt calls [ Upstream commit e521b9cc1a49de677f4fc65909ce4877fbf7b113 ] On ov2680_set_fmt() calls with format->which == V4L2_SUBDEV_FORMAT_TRY, ov2680_set_fmt() does not talk to the sensor. So in this case there is no need to lock the sensor->lock mutex or to check that the sensor is streaming. Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver") Acked-by: Rui Miguel Silva <[email protected]> Reviewed-by: Daniel Scally <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Thu Aug 3 11:33:17 2023 +0200 media: ov2680: Fix ov2680_bayer_order() [ Upstream commit 50a7bad4e0a37d7018ab6fe843dd84bc6b2ecf72 ] The index into ov2680_hv_flip_bayer_order[] should be 0-3, but ov2680_bayer_order() was using 0 + BIT(2) + (BIT(2) << 1) as max index, while the intention was to use: 0 + 1 + 2 as max index. Fix the index calculation in ov2680_bayer_order(), while at it also just use the ctrl values rather then reading them back using a slow i2c-read transaction. This also allows making the function void, since there now are no more i2c-reads to error check. Note the check for the ctrls being NULL is there to allow adding an ov2680_fill_format() helper later, which will call ov2680_set_bayer_order() during probe() before the ctrls are created. [Sakari Ailus: Change all users of ov2680_set_bayer_order() here] Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver") Reviewed-by: Daniel Scally <[email protected]> Acked-by: Rui Miguel Silva <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Thu Aug 3 11:33:22 2023 +0200 media: ov2680: Fix ov2680_set_fmt() which == V4L2_SUBDEV_FORMAT_TRY not working [ Upstream commit c0e97a4b4f20639f74cd5809b42ba6cbf9736a7d ] ov2680_set_fmt() which == V4L2_SUBDEV_FORMAT_TRY was getting the try_fmt v4l2_mbus_framefmt struct from the passed in sd_state and then storing the contents of that into the return by reference format->format struct. While the right thing to do would be filling format->format based on the just looked up mode and then store the results of that in sd_state->pads[0].try_fmt . Before the previous change introducing ov2680_fill_format() this resulted in ov2680_set_fmt() which == V4L2_SUBDEV_FORMAT_TRY always returning the zero-ed out sd_state->pads[0].try_fmt in format->format breaking callers using this. After the introduction of ov2680_fill_format() which at least initializes sd_state->pads[0].try_fmt properly, format->format is now always being filled with the default 800x600 mode set by ov2680_init_cfg() independent of the actual requested mode. Move the filling of format->format with ov2680_fill_format() to before the if (which == V4L2_SUBDEV_FORMAT_TRY) and then store the filled in format->format in sd_state->pads[0].try_fmt to fix this. Note this removes the fmt local variable because IMHO having a local variable which points to a sub-struct of one of the function arguments just leads to confusion when reading the code. Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver") Acked-by: Rui Miguel Silva <[email protected]> Reviewed-by: Daniel Scally <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Thu Aug 3 11:33:23 2023 +0200 media: ov2680: Fix regulators being left enabled on ov2680_power_on() errors [ Upstream commit 84b4bd7e0d98166aa32fd470e672721190492eae ] When the ov2680_power_on() "sensor soft reset failed" path is hit during probe() the WARN() about putting an enabled regulator at drivers/regulator/core.c:2398 triggers 3 times (once for each regulator), filling dmesg with backtraces. Fix this by properly disabling the regulators on ov2680_power_on() errors. Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver") Reviewed-by: Daniel Scally <[email protected]> Acked-by: Rui Miguel Silva <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Thu Aug 3 11:33:18 2023 +0200 media: ov2680: Fix vflip / hflip set functions [ Upstream commit d5d08ad330c9ccebc5e066fda815423a290f48b0 ] ov2680_vflip_disable() / ov2680_hflip_disable() pass BIT(0) instead of 0 as value to ov2680_mod_reg(). While fixing this also: 1. Stop having separate enable/disable functions for hflip / vflip 2. Move the is_streaming check, which is unique to hflip / vflip into the ov2680_set_?flip() functions. for a nice code cleanup. Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver") Reviewed-by: Daniel Scally <[email protected]> Acked-by: Rui Miguel Silva <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Thu Aug 3 11:33:16 2023 +0200 media: ov2680: Remove auto-gain and auto-exposure controls [ Upstream commit 7b5a42e6ae71927359ea67a2c22570ba97fa4059 ] Quoting the OV2680 datasheet: "3.2 exposure and gain control In the OV2680, the exposure time and gain are set manually from an external controller. The OV2680 supports manual gain and exposure control only for normal applications, no auto mode." And indeed testing with the atomisp_ov2680 fork of ov2680.c has shown that auto-exposure and auto-gain do not work. Note that the code setting the auto-exposure flag was broken, callers of ov2680_exposure_set() were directly passing !!ctrls->auto_exp->val as "bool auto_exp" value, but ctrls->auto_exp is a menu control with: enum v4l2_exposure_auto_type { V4L2_EXPOSURE_AUTO = 0, V4L2_EXPOSURE_MANUAL = 1, ... So instead of passing !!ctrls->auto_exp->val they should have been passing ctrls->auto_exp->val == V4L2_EXPOSURE_AUTO, iow the passed value was inverted of what it should have been. Also remove ov2680_g_volatile_ctrl() since without auto support the gain and exposure controls are not volatile. This also fixes the control values not being properly applied in ov2680_mode_set(). The 800x600 mode register-list also sets gain, exposure and vflip overriding the last set ctrl values. ov2680_mode_set() does call ov2680_gain_set() and ov2680_exposure_set() but did this before writing the mode register-list, so these values would still be overridden by the mode register-list. Add a v4l2_ctrl_handler_setup() call after writing the mode register-list to restore all ctrl values. Also remove the ctrls->gain->is_new check from ov2680_gain_set() so that the gain always gets restored properly. Last since ov2680_mode_set() now calls v4l2_ctrl_handler_setup(), remove the v4l2_ctrl_handler_setup() call after ov2680_mode_restore() since ov2680_mode_restore() calls ov2680_mode_set(). Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver") Reviewed-by: Daniel Scally <[email protected]> Acked-by: Rui Miguel Silva <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Thu Aug 3 11:33:19 2023 +0200 media: ov2680: Remove VIDEO_V4L2_SUBDEV_API ifdef-s [ Upstream commit 49c282d5a8c5f4d1d9088622bec792294c716010 ] VIDEO_V4L2_SUBDEV_API is now automatically selected in Kconfig for all sensor drivers. Remove the ifdef CONFIG_VIDEO_V4L2_SUBDEV_API checks. This is a preparation patch for fixing ov2680_set_fmt() which == V4L2_SUBDEV_FORMAT_TRY calls not properly filling in the passed in v4l2_mbus_framefmt struct. Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver") Reviewed-by: Daniel Scally <[email protected]> Acked-by: Rui Miguel Silva <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marek Vasut <[email protected]> Date: Wed Aug 2 16:47:25 2023 +0200 media: ov5640: Enable MIPI interface in ov5640_set_power_mipi() [ Upstream commit 98cb72d3b9c5e03b10fa993752ecfcbd9c572d8c ] Set OV5640_REG_IO_MIPI_CTRL00 bit 2 to 1 instead of 0, since 1 means MIPI CSI2 interface, while 0 means CPI parallel interface. In the ov5640_set_power_mipi() the interface should obviously be set to MIPI CSI2 since this functions is used to power up the sensor when operated in MIPI CSI2 mode. The sensor should not be in CPI mode in that case. This fixes a corner case where capturing the first frame on i.MX8MN with CSI/ISI resulted in corrupted frame. Fixes: aa4bb8b8838f ("media: ov5640: Re-work MIPI startup sequence") Reviewed-by: Jacopo Mondi <[email protected]> Tested-by: Jacopo Mondi <[email protected]> # [Test on imx6q] Signed-off-by: Marek Vasut <[email protected]> Tested-by: Jai Luthra <[email protected]> # [Test on bplay, sk-am62] Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marek Vasut <[email protected]> Date: Tue Jul 25 00:21:16 2023 +0200 media: ov5640: Fix initial RESETB state and annotate timings [ Upstream commit a210df337c5f5c2cd82f36c9dbb154ec63365c80 ] The initial state of RESETB input signal of OV5640 should be asserted, i.e. the sensor should be in reset. This is not the case, make it so. Since the subsequent assertion of RESETB signal is no longer necessary and the timing of the power sequencing could be slightly adjusted, add annotations to the delays which match OV5640 datasheet rev. 2.03, both: figure 2-3 power up timing with internal DVDD figure 2-4 power up timing with external DVDD source The 5..10ms delay between PWDN assertion and RESETB assertion is not even documented in the power sequencing diagram, and with this reset fix, it is no longer even necessary. Fixes: 19a81c1426c1 ("[media] add Omnivision OV5640 sensor driver") Reported-by: Jacopo Mondi <[email protected]> Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Jacopo Mondi <[email protected]> Tested-by: Jai Luthra <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Guoniu.zhou <[email protected]> Date: Mon Jun 12 04:43:40 2023 +0200 media: ov5640: fix low resolution image abnormal issue [ Upstream commit a828002f38c5ee49d3f0c0e64c0f0caa1aec8dc2 ] OV5640 will output abnormal image data when work at low resolution (320x240, 176x144 and 160x120) after switching from high resolution, such as 1080P, the time interval between high and low switching must be less than 1000ms in order to OV5640 don't enter suspend state during the time. The reason is by 0x3824 value don't restore to initialize value when do resolution switching. In high resolution setting array, 0x3824 is set to 0x04, but low resolution setting array remove 0x3824 in commit db15c1957a2d ("media: ov5640: Remove duplicated mode settings"). So when do resolution switching from high to low, such as 1080P to 320x240, and the time interval is less than auto suspend delay time which means global initialize setting array will not be loaded, the output image data are abnormal. Hence move 0x3824 from ov5640_init_setting[] table to ov5640_setting_low_res[] table and also move 0x4407 0x460b, 0x460c to avoid same issue. Fixes: db15c1957a2d ("media: ov5640: Remove duplicated mode settings") Signed-off-by: Guoniu.zhou <[email protected]> Reviewed-by: Jacopo Mondi <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nikolay Burykin <[email protected]> Date: Tue Jan 10 10:09:00 2023 +0100 media: pci: cx23885: fix error handling for cx23885 ATSC boards [ Upstream commit 4aaa96b59df5fac41ba891969df6b092061ea9d7 ] After having been assigned to NULL value at cx23885-dvb.c:1202, pointer '0' is dereferenced at cx23885-dvb.c:2469. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Nikolay Burykin <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Antipov <[email protected]> Date: Tue Jun 6 06:38:15 2023 +0200 media: pulse8-cec: handle possible ping error [ Upstream commit 92cbf865ea2e0f2997ff97815c6db182eb23df1b ] Handle (and warn about) possible error waiting for MSGCODE_PING result. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Dmitry Antipov <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Benjamin Gaignard <[email protected]> Date: Mon Jul 17 17:06:11 2023 +0200 media: rkvdec: increase max supported height for H.264 [ Upstream commit f000e6ca2d60fefd02a180a57df2c4162fa0c1b7 ] After testing it is possible for the hardware to decode H264 bistream with a height up to 2560. Signed-off-by: Benjamin Gaignard <[email protected]> Fixes: cd33c830448ba ("media: rkvdec: Add the rkvdec driver") Reviewed-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christophe JAILLET <[email protected]> Date: Wed Jun 14 20:31:05 2023 +0200 media: v4l2-core: Fix a potential resource leak in v4l2_fwnode_parse_link() [ Upstream commit d7b13edd4cb4bfa335b6008ab867ac28582d3e5c ] If fwnode_graph_get_remote_endpoint() fails, 'fwnode' is known to be NULL, so fwnode_handle_put() is a no-op. Release the reference taken from a previous fwnode_graph_get_port_parent() call instead. Also handle fwnode_graph_get_port_parent() failures. In order to fix these issues, add an error handling path to the function and the needed gotos. Fixes: ca50c197bd96 ("[media] v4l: fwnode: Support generic fwnode for parsing standardised properties") Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Tue May 30 14:30:35 2023 +0200 media: venus: hfi_venus: Only consider sys_idle_indicator on V1 [ Upstream commit 6283e4834c69fa93a108efa18c6aa09c7e626f49 ] As per information from Qualcomm [1], this property is not really supported beyond msm8916 (HFI V1) and some newer HFI versions really dislike receiving it, going as far as crashing the device. Only consider toggling it (via the module option) on HFIV1. While at it, get rid of the global static variable (which defaulted to zero) which was never explicitly assigned to for V1. Note: [1] is a reply to the actual message in question, as lore did not properly receive some of the emails.. [1] https://lore.kernel.org/lkml/[email protected]/ Fixes: 7ed9e0b3393c ("media: venus: hfi, vdec: v6 Add IS_V6() to existing IS_V4() if locations") Signed-off-by: Konrad Dybcio <[email protected]> Signed-off-by: Stanimir Varbanov <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Tue May 30 14:30:36 2023 +0200 media: venus: hfi_venus: Write to VIDC_CTRL_INIT after unmasking interrupts commit d74e481609808330b4625b3691cf01e1f56e255e upstream. The startup procedure shouldn't be started with interrupts masked, as that may entail silent failures. Kick off initialization only after the interrupts are unmasked. Cc: [email protected] # v4.12+ Fixes: d96d3f30c0f2 ("[media] media: venus: hfi: add Venus HFI files") Signed-off-by: Konrad Dybcio <[email protected]> Signed-off-by: Stanimir Varbanov <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Michael Tretter <[email protected]> Date: Thu Jul 6 09:15:10 2023 +0200 media: verisilicon: Fix TRY_FMT on encoder OUTPUT [ Upstream commit b3b4c9d3cb3bf8725a3ded26f7042b1a37f25333 ] Commit f100ce3bbd6a ("media: verisilicon: Fix crash when probing encoder") removed vpu_fmt from hantro_try_fmt(), since it was initialized from vpu_dst_fmt, which may not be initialized, when TRY_FMT is called. It was replaced by fmt, which is found using the pixelformat. For the encoder, this changed the fmt to contain the raw format instead of the coded format. The format constraints as of fmt->frmsize are only valid for the coded format and are 0 for the raw formats. Therefore, the size of a encoder OUTPUT device is constrained to 0 and the v4l2-compliance tests for G_FMT, TRY_FMT, and SET_FMT fail. Bring back vpu_fmt to use the coded format on an encoder OUTPUT device, but initialize it using the currently set pixelformat on dst_fmt, which is the coded format on an encoder. Fixes: f100ce3bbd6a ("media: verisilicon: Fix crash when probing encoder") Signed-off-by: Michael Tretter <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Aleksa Sarai <[email protected]> Date: Mon Aug 14 18:40:58 2023 +1000 memfd: do not -EACCES old memfd_create() users with vm.memfd_noexec=2 [ Upstream commit 202e14222fadb246dfdf182e67de1518e86a1e20 ] Given the difficulty of auditing all of userspace to figure out whether every memfd_create() user has switched to passing MFD_EXEC and MFD_NOEXEC_SEAL flags, it seems far less distruptive to make it possible for older programs that don't make use of executable memfds to run under vm.memfd_noexec=2. Otherwise, a small dependency change can result in spurious errors. For programs that don't use executable memfds, passing MFD_NOEXEC_SEAL is functionally a no-op and thus having the same In addition, every failure under vm.memfd_noexec=2 needs to print to the kernel log so that userspace can figure out where the error came from. The concerns about pr_warn_ratelimited() spam that caused the switch to pr_warn_once()[1,2] do not apply to the vm.memfd_noexec=2 case. This is a user-visible API change, but as it allows programs to do something that would be blocked before, and the sysctl itself was broken and recently released, it seems unlikely this will cause any issues. [1]: https://lore.kernel.org/Y5yS8wCnuYGLHMj4@x1n/ [2]: https://lore.kernel.org/202212161233.85C9783FB@keescook/ Link: https://lkml.kernel.org/r/[email protected] Fixes: 105ff5339f49 ("mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC") Signed-off-by: Aleksa Sarai <[email protected]> Cc: Dominique Martinet <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Daniel Verkamp <[email protected]> Cc: Jeff Xu <[email protected]> Cc: Kees Cook <[email protected]> Cc: Shuah Khan <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Aleksa Sarai <[email protected]> Date: Mon Aug 14 18:40:59 2023 +1000 memfd: improve userspace warnings for missing exec-related flags [ Upstream commit 434ed3350f57c03a9654fe0619755cc137a58935 ] In order to incentivise userspace to switch to passing MFD_EXEC and MFD_NOEXEC_SEAL, we need to provide a warning on each attempt to call memfd_create() without the new flags. pr_warn_once() is not useful because on most systems the one warning is burned up during the boot process (on my system, systemd does this within the first second of boot) and thus userspace will in practice never see the warnings to push them to switch to the new flags. The original patchset[1] used pr_warn_ratelimited(), however there were concerns about the degree of spam in the kernel log[2,3]. The resulting inability to detect every case was flagged as an issue at the time[4]. While we could come up with an alternative rate-limiting scheme such as only outputting the message if vm.memfd_noexec has been modified, or only outputting the message once for a given task, these alternatives have downsides that don't make sense given how low-stakes a single kernel warning message is. Switching to pr_info_ratelimited() instead should be fine -- it's possible some monitoring tool will be unhappy with a stream of warning-level messages but there's already plenty of info-level message spam in dmesg. [1]: https://lore.kernel.org/[email protected]/ [2]: https://lore.kernel.org/202212161233.85C9783FB@keescook/ [3]: https://lore.kernel.org/Y5yS8wCnuYGLHMj4@x1n/ [4]: https://lore.kernel.org/[email protected]/ Link: https://lkml.kernel.org/r/[email protected] Fixes: 105ff5339f49 ("mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC") Signed-off-by: Aleksa Sarai <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Daniel Verkamp <[email protected]> Cc: Dominique Martinet <[email protected]> Cc: Kees Cook <[email protected]> Cc: Shuah Khan <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ekansh Gupta <[email protected]> Date: Fri Aug 11 12:56:43 2023 +0100 misc: fastrpc: Pass proper scm arguments for static process init commit fe6518d547fc52ba74201018dc9aeb364072ac78 upstream. Memory is allocated for dynamic loading when audio daemon is trying to attach to audioPD on DSP side. This memory is allocated from reserved CMA memory region and needs ownership assignment to new VMID in order to use it from audioPD. In the current implementation, arguments are not correctly passed to the scm call which might result in failure of dynamic loading on audioPD. Added changes to pass correct arguments during daemon attach request. Fixes: 0871561055e6 ("misc: fastrpc: Add support for audiopd") Cc: stable <[email protected]> Tested-by: Ekansh Gupta <[email protected]> Signed-off-by: Ekansh Gupta <[email protected]> Signed-off-by: Srinivas Kandagatla <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Vadim Pasternak <[email protected]> Date: Thu Aug 24 15:43:10 2023 +0200 mlxsw: core_hwmon: Adjust module label names based on MTCAP sensor counter [ Upstream commit 3fc134a07438055fc93ce1bbacf2702ddd09500c ] Transceiver module temperature sensors are indexed after ASIC and platform sensors. The current label printing method does not take this into account and simply prints the index of the transceiver module sensor. On new systems that have platform sensors this results in incorrect (shifted) transceiver module labels being printed: $ sensors [...] front panel 002: +37.0°C (crit = +70.0°C, emerg = +75.0°C) front panel 003: +47.0°C (crit = +70.0°C, emerg = +75.0°C) [...] Fix by taking the sensor count into account. After the fix: $ sensors [...] front panel 001: +37.0°C (crit = +70.0°C, emerg = +75.0°C) front panel 002: +47.0°C (crit = +70.0°C, emerg = +75.0°C) [...] Fixes: a53779de6a0e ("mlxsw: core: Add QSFP module temperature label attribute to hwmon") Signed-off-by: Vadim Pasternak <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Signed-off-by: Petr Machata <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vadim Pasternak <[email protected]> Date: Thu Aug 24 15:43:08 2023 +0200 mlxsw: i2c: Fix chunk size setting in output mailbox buffer [ Upstream commit 146c7c330507c0384bf29d567186632bfe975927 ] The driver reads commands output from the output mailbox. If the size of the output mailbox is not a multiple of the transaction / block size, then the driver will not issue enough read transactions to read the entire output, which can result in driver initialization errors. Fix by determining the number of transactions using DIV_ROUND_UP(). Fixes: 3029a693beda ("mlxsw: i2c: Allow flexible setting of I2C transactions size") Signed-off-by: Vadim Pasternak <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Signed-off-by: Petr Machata <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vadim Pasternak <[email protected]> Date: Thu Aug 24 15:43:09 2023 +0200 mlxsw: i2c: Limit single transaction buffer size [ Upstream commit d7248f1cc835bd80e936dc5b2d94b149bdd0077d ] Maximum size of buffer is obtained from underlying I2C adapter and in case adapter allows I2C transaction buffer size greater than 100 bytes, transaction will fail due to firmware limitation. As a result driver will fail initialization. Limit the maximum size of transaction buffer by 100 bytes to fit to firmware. Remove unnecessary calculation: max_t(u16, MLXSW_I2C_BLK_DEF, quirk_size). This condition can not happened. Fixes: 3029a693beda ("mlxsw: i2c: Allow flexible setting of I2C transactions size") Signed-off-by: Vadim Pasternak <[email protected]> Reviewed-by: Petr Machata <[email protected]> Signed-off-by: Petr Machata <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jeff Xu <[email protected]> Date: Wed Jul 5 06:33:14 2023 +0000 mm/memfd: sysctl: fix MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED [ Upstream commit 72de259130229412ca49871e70ffaf17dc9fba98 ] Patch series "mm/memfd: fix sysctl MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED", v2. When sysctl vm.memfd_noexec is 2 (MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED), memfd_create(.., MFD_EXEC) should fail. This complies with how MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED is defined - "memfd_create() without MFD_NOEXEC_SEAL will be rejected" Thanks to Dominique Martinet <[email protected]> who reported the bug. see [1] for context. [1] https://lore.kernel.org/linux-mm/CABi2SkXUX_QqTQ10Yx9bBUGpN1wByOi_=gZU6WEy5a8MaQY3Jw@mail.gmail.com/T/ This patch (of 2): When vm.memfd_noexec is 2 (MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED), memfd_create(.., MFD_EXEC) should fail. This complies with how MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED is defined - "memfd_create() without MFD_NOEXEC_SEAL will be rejected" Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Fixes: 105ff5339f49 ("mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC") Reported-by: Dominique Martinet <[email protected]> Closes: https://lore.kernel.org/linux-mm/CABi2SkXUX_QqTQ10Yx9bBUGpN1wByOi_=gZU6WEy5a8MaQY3Jw@mail.gmail.com/T/ Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Jeff Xu <[email protected]> Cc: Daniel Verkamp <[email protected]> Cc: Dmitry Torokhov <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: Jann Horn <[email protected]> Cc: Jorge Lucangeli Obes <[email protected]> Cc: Kees Cook <[email protected]> Cc: Shuah Khan <[email protected]> Cc: Mike Kravetz <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Stable-dep-of: 202e14222fad ("memfd: do not -EACCES old memfd_create() users with vm.memfd_noexec=2") Signed-off-by: Sasha Levin <[email protected]>
Author: Joel Fernandes (Google) <[email protected]> Date: Mon Sep 4 18:08:04 2023 +0000 mm/vmalloc: add a safer version of find_vm_area() for debug commit 0818e739b5c061b0251c30152380600fb9b84c0c upstream. It is unsafe to dump vmalloc area information when trying to do so from some contexts. Add a safer trylock version of the same function to do a best-effort VMA finding and use it from vmalloc_dump_obj(). [applied test robot feedback on unused function fix.] [applied Uladzislau feedback on locking.] Link: https://lkml.kernel.org/r/[email protected] Fixes: 98f180837a89 ("mm: Make mem_dump_obj() handle vmalloc() memory") Signed-off-by: Joel Fernandes (Google) <[email protected]> Reviewed-by: Uladzislau Rezki (Sony) <[email protected]> Reported-by: Zhen Lei <[email protected]> Cc: Paul E. McKenney <[email protected]> Cc: Zqiang <[email protected]> Cc: <[email protected]> Cc: Matthew Wilcox (Oracle) <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Wolfram Sang <[email protected]> Date: Wed Jul 12 16:00:11 2023 +0200 mmc: renesas_sdhi: register irqs before registering controller commit 74f45de394d979cc7770271f92fafa53e1ed3119 upstream. IRQs should be ready to serve when we call mmc_add_host() via tmio_mmc_host_probe(). To achieve that, ensure that all irqs are masked before registering the handlers. Signed-off-by: Wolfram Sang <[email protected]> Tested-by: Biju Das <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Tested-by: Geert Uytterhoeven <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: William Zhang <[email protected]> Date: Thu Jul 6 11:29:09 2023 -0700 mtd: rawnand: brcmnand: Fix mtd oobsize [ Upstream commit 60177390fa061c62d156f4a546e3efd90df3c183 ] brcmnand controller can only access the flash spare area up to certain bytes based on the ECC level. It can be less than the actual flash spare area size. For example, for many NAND chip supporting ECC BCH-8, it has 226 bytes spare area. But controller can only uses 218 bytes. So brcmand driver overrides the mtd oobsize with the controller's accessible spare area size. When the nand base driver utilizes the nand_device object, it resets the oobsize back to the actual flash spare aprea size from nand_memory_organization structure and controller may not able to access all the oob area as mtd advises. This change fixes the issue by overriding the oobsize in the nand_memory_organization structure to the controller's accessible spare area size. Fixes: a7ab085d7c16 ("mtd: rawnand: Initialize the nand_device object") Signed-off-by: William Zhang <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Yi Yang <[email protected]> Date: Thu Aug 17 19:58:39 2023 +0800 mtd: rawnand: fsmc: handle clk prepare error in fsmc_nand_resume() [ Upstream commit a5a88125d00612586e941ae13e7fcf36ba8f18a7 ] In fsmc_nand_resume(), the return value of clk_prepare_enable() should be checked since it might fail. Fixes: e25da1c07dfb ("mtd: fsmc_nand: Add clk_{un}prepare() support") Signed-off-by: Yi Yang <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Hsin-Yi Wang <[email protected]> Date: Fri Aug 18 14:42:23 2023 +0800 mtd: spi-nor: Check bus width while setting QE bit [ Upstream commit f01d8155a92e33cdaa85d20bfbe6c441907b3c1f ] spi_nor_write_16bit_sr_and_check() should also check if bus width is 4 before setting QE bit. Fixes: 39d1e3340c73 ("mtd: spi-nor: Fix clearing of QE bit on lock()/unlock()") Suggested-by: Michael Walle <[email protected]> Suggested-by: Tudor Ambarus <[email protected]> Signed-off-by: Hsin-Yi Wang <[email protected]> Reviewed-by: Michael Walle <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Tudor Ambarus <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kalesh Singh <[email protected]> Date: Tue Aug 1 19:56:02 2023 -0700 Multi-gen LRU: fix per-zone reclaim commit 669281ee7ef731fb5204df9d948669bf32a5e68d upstream. MGLRU has a LRU list for each zone for each type (anon/file) in each generation: long nr_pages[MAX_NR_GENS][ANON_AND_FILE][MAX_NR_ZONES]; The min_seq (oldest generation) can progress independently for each type but the max_seq (youngest generation) is shared for both anon and file. This is to maintain a common frame of reference. In order for eviction to advance the min_seq of a type, all the per-zone lists in the oldest generation of that type must be empty. The eviction logic only considers pages from eligible zones for eviction or promotion. scan_folios() { ... for (zone = sc->reclaim_idx; zone >= 0; zone--) { ... sort_folio(); // Promote ... isolate_folio(); // Evict } ... } Consider the system has the movable zone configured and default 4 generations. The current state of the system is as shown below (only illustrating one type for simplicity): Type: ANON Zone DMA32 Normal Movable Device Gen 0 0 0 4GB 0 Gen 1 0 1GB 1MB 0 Gen 2 1MB 4GB 1MB 0 Gen 3 1MB 1MB 1MB 0 Now consider there is a GFP_KERNEL allocation request (eligible zone index <= Normal), evict_folios() will return without doing any work since there are no pages to scan in the eligible zones of the oldest generation. Reclaim won't make progress until triggered from a ZONE_MOVABLE allocation request; which may not happen soon if there is a lot of free memory in the movable zone. This can lead to OOM kills, although there is 1GB pages in the Normal zone of Gen 1 that we have not yet tried to reclaim. This issue is not seen in the conventional active/inactive LRU since there are no per-zone lists. If there are no (not enough) folios to scan in the eligible zones, move folios from ineligible zone (zone_index > reclaim_index) to the next generation. This allows for the progression of min_seq and reclaiming from the next generation (Gen 1). Qualcomm, Mediatek and raspberrypi [1] discovered this issue independently. [1] https://github.com/raspberrypi/linux/issues/5395 Link: https://lkml.kernel.org/r/[email protected] Fixes: ac35a4902374 ("mm: multi-gen LRU: minimal implementation") Signed-off-by: Kalesh Singh <[email protected]> Reported-by: Charan Teja Kalla <[email protected]> Reported-by: Lecopzer Chen <[email protected]> Tested-by: AngeloGioacchino Del Regno <[email protected]> [mediatek] Tested-by: Charan Teja Kalla <[email protected]> Cc: Yu Zhao <[email protected]> Cc: Barry Song <[email protected]> Cc: Brian Geffon <[email protected]> Cc: Jan Alexander Steffens (heftig) <[email protected]> Cc: Matthias Brugger <[email protected]> Cc: Oleksandr Natalenko <[email protected]> Cc: Qi Zheng <[email protected]> Cc: Steven Barrett <[email protected]> Cc: Suleiman Souhlal <[email protected]> Cc: Suren Baghdasaryan <[email protected]> Cc: Aneesh Kumar K V <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Abel Wu <[email protected]> Date: Mon Aug 14 15:09:11 2023 +0800 net-memcg: Fix scope of sockmem pressure indicators [ Upstream commit ac8a52962164a50e693fa021d3564d7745b83a7f ] Now there are two indicators of socket memory pressure sit inside struct mem_cgroup, socket_pressure and tcpmem_pressure, indicating memory reclaim pressure in memcg->memory and ->tcpmem respectively. When in legacy mode (cgroupv1), the socket memory is charged into ->tcpmem which is independent of ->memory, so socket_pressure has nothing to do with socket's pressure at all. Things could be worse by taking socket_pressure into consideration in legacy mode, as a pressure in ->memory can lead to premature reclamation/throttling in socket. While for the default mode (cgroupv2), the socket memory is charged into ->memory, and ->tcpmem/->tcpmem_pressure are simply not used. So {socket,tcpmem}_pressure are only used in default/legacy mode respectively for indicating socket memory pressure. This patch fixes the pieces of code that make mixed use of both. Fixes: 8e8ae645249b ("mm: memcontrol: hook up vmpressure to socket pressure") Signed-off-by: Abel Wu <[email protected]> Acked-by: Shakeel Butt <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rahul Rameshbabu <[email protected]> Date: Mon Aug 21 16:05:54 2023 -0700 net/mlx5: Dynamic cyclecounter shift calculation for PTP free running clock [ Upstream commit 84a58e60038fa0366006977dba85eae16b2e3d78 ] Use a dynamic calculation to determine the shift value for the internal timer cyclecounter that will lead to the highest precision frequency adjustments. Previously used a constant for the shift value assuming all devices supported by the driver had a nominal frequency of 1GHz. However, there are devices that operate at different frequencies. The previous shift value constant would break the PHC functionality for those devices. Reported-by: Vadim Fedorenko <[email protected]> Closes: https://lore.kernel.org/netdev/[email protected]/ Fixes: 6a4010927562 ("net/mlx5: Update cyclecounter shift value to improve ptp free running mode precision") Signed-off-by: Rahul Rameshbabu <[email protected]> Tested-by: Vadim Fedorenko <[email protected]> Reviewed-by: Jacob Keller <[email protected]> Reviewed-by: Simon Horman <[email protected]> Acked-by: Saeed Mahameed <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ilpo Järvinen <[email protected]> Date: Mon Jul 17 15:04:59 2023 +0300 net/mlx5: Use RMW accessors for changing LNKCTL [ Upstream commit 30de872537bda526664d7a20b646adfb3e7ce6e6 ] Don't assume that only the driver would be accessing LNKCTL of the upstream bridge. ASPM policy changes can trigger write to LNKCTL outside of driver's control. Use RMW capability accessors which do proper locking to avoid losing concurrent updates to the register value. Suggested-by: Lukas Wunner <[email protected]> Fixes: eabe8e5e88f5 ("net/mlx5: Handle sync reset now event") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Moshe Shemesh <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Budimir Markovic <[email protected]> Date: Thu Aug 24 01:49:05 2023 -0700 net/sched: sch_hfsc: Ensure inner classes have fsc curve [ Upstream commit b3d26c5702c7d6c45456326e56d2ccf3f103e60f ] HFSC assumes that inner classes have an fsc curve, but it is currently possible for classes without an fsc curve to become parents. This leads to bugs including a use-after-free. Don't allow non-root classes without HFSC_FSC to become parents. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Budimir Markovic <[email protected]> Signed-off-by: Budimir Markovic <[email protected]> Acked-by: Jamal Hadi Salim <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Sat Aug 19 04:06:46 2023 +0000 net: annotate data-races around sk->sk_lingertime [ Upstream commit bc1fb82ae11753c5dec53c667a055dc37796dbd2 ] sk_getsockopt() runs locklessly. This means sk->sk_lingertime can be read while other threads are changing its value. Other reads also happen without socket lock being held, and must be annotated. Remove preprocessor logic using BITS_PER_LONG, compilers are smart enough to figure this by themselves. v2: fixed a clang W=1 (-Wtautological-constant-out-of-range-compare) warning (Jakub) Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Fri Jul 28 15:03:12 2023 +0000 net: annotate data-races around sk->sk_{rcv|snd}timeo [ Upstream commit 285975dd674258ccb33e77a1803e8f2015e67105 ] sk_getsockopt() runs without locks, we must add annotations to sk->sk_rcvtimeo and sk->sk_sndtimeo. In the future we might allow fetching these fields before we lock the socket in TCP fast path. Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jinjie Ruan <[email protected]> Date: Thu Aug 24 14:43:36 2023 +0800 net: arcnet: Do not call kfree_skb() under local_irq_disable() [ Upstream commit 786c96e92fb9e854cb8b0cb7399bb2fb28e15c4b ] It is not allowed to call kfree_skb() from hardware interrupt context or with hardware interrupts being disabled. So replace kfree_skb() with dev_kfree_skb_irq() under local_irq_disable(). Compile tested only. Fixes: 05fcd31cc472 ("arcnet: add err_skb package for package status feedback") Signed-off-by: Jinjie Ruan <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jordan Rife <[email protected]> Date: Mon Aug 21 16:45:23 2023 -0500 net: Avoid address overwrite in kernel_connect commit 0bdf399342c5acbd817c9098b6c7ed21f1974312 upstream. BPF programs that run on connect can rewrite the connect address. For the connect system call this isn't a problem, because a copy of the address is made when it is moved into kernel space. However, kernel_connect simply passes through the address it is given, so the caller may observe its address value unexpectedly change. A practical example where this is problematic is where NFS is combined with a system such as Cilium which implements BPF-based load balancing. A common pattern in software-defined storage systems is to have an NFS mount that connects to a persistent virtual IP which in turn maps to an ephemeral server IP. This is usually done to achieve high availability: if your server goes down you can quickly spin up a replacement and remap the virtual IP to that endpoint. With BPF-based load balancing, mounts will forget the virtual IP address when the address rewrite occurs because a pointer to the only copy of that address is passed down the stack. Server failover then breaks, because clients have forgotten the virtual IP address. Reconnects fail and mounts remain broken. This patch was tested by setting up a scenario like this and ensuring that NFS reconnects worked after applying the patch. Signed-off-by: Jordan Rife <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Thu Aug 31 18:37:50 2023 +0000 net: deal with integer overflows in kmalloc_reserve() commit 915d975b2ffa58a14bfcf16fafe00c41315949ff upstream. Blamed commit changed: ptr = kmalloc(size); if (ptr) size = ksize(ptr); to: size = kmalloc_size_roundup(size); ptr = kmalloc(size); This allowed various crash as reported by syzbot [1] and Kyle Zeng. Problem is that if @size is bigger than 0x80000001, kmalloc_size_roundup(size) returns 2^32. kmalloc_reserve() uses a 32bit variable (obj_size), so 2^32 is truncated to 0. kmalloc(0) returns ZERO_SIZE_PTR which is not handled by skb allocations. Following trace can be triggered if a netdev->mtu is set close to 0x7fffffff We might in the future limit netdev->mtu to more sensible limit (like KMALLOC_MAX_SIZE). This patch is based on a syzbot report, and also a report and tentative fix from Kyle Zeng. [1] BUG: KASAN: user-memory-access in __build_skb_around net/core/skbuff.c:294 [inline] BUG: KASAN: user-memory-access in __alloc_skb+0x3c4/0x6e8 net/core/skbuff.c:527 Write of size 32 at addr 00000000fffffd10 by task syz-executor.4/22554 CPU: 1 PID: 22554 Comm: syz-executor.4 Not tainted 6.1.39-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/03/2023 Call trace: dump_backtrace+0x1c8/0x1f4 arch/arm64/kernel/stacktrace.c:279 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:286 __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x120/0x1a0 lib/dump_stack.c:106 print_report+0xe4/0x4b4 mm/kasan/report.c:398 kasan_report+0x150/0x1ac mm/kasan/report.c:495 kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189 memset+0x40/0x70 mm/kasan/shadow.c:44 __build_skb_around net/core/skbuff.c:294 [inline] __alloc_skb+0x3c4/0x6e8 net/core/skbuff.c:527 alloc_skb include/linux/skbuff.h:1316 [inline] igmpv3_newpack+0x104/0x1088 net/ipv4/igmp.c:359 add_grec+0x81c/0x1124 net/ipv4/igmp.c:534 igmpv3_send_cr net/ipv4/igmp.c:667 [inline] igmp_ifc_timer_expire+0x1b0/0x1008 net/ipv4/igmp.c:810 call_timer_fn+0x1c0/0x9f0 kernel/time/timer.c:1474 expire_timers kernel/time/timer.c:1519 [inline] __run_timers+0x54c/0x710 kernel/time/timer.c:1790 run_timer_softirq+0x28/0x4c kernel/time/timer.c:1803 _stext+0x380/0xfbc ____do_softirq+0x14/0x20 arch/arm64/kernel/irq.c:79 call_on_irq_stack+0x24/0x4c arch/arm64/kernel/entry.S:891 do_softirq_own_stack+0x20/0x2c arch/arm64/kernel/irq.c:84 invoke_softirq kernel/softirq.c:437 [inline] __irq_exit_rcu+0x1c0/0x4cc kernel/softirq.c:683 irq_exit_rcu+0x14/0x78 kernel/softirq.c:695 el0_interrupt+0x7c/0x2e0 arch/arm64/kernel/entry-common.c:717 __el0_irq_handler_common+0x18/0x24 arch/arm64/kernel/entry-common.c:724 el0t_64_irq_handler+0x10/0x1c arch/arm64/kernel/entry-common.c:729 el0t_64_irq+0x1a0/0x1a4 arch/arm64/kernel/entry.S:584 Fixes: 12d6c1d3a2ad ("skbuff: Proactively round up to kmalloc bucket size") Reported-by: syzbot <[email protected]> Reported-by: Kyle Zeng <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Cc: Kees Cook <[email protected]> Cc: Vlastimil Babka <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lukasz Majewski <[email protected]> Date: Thu Jul 27 10:13:42 2023 +0200 net: dsa: microchip: KSZ9477 register regmap alignment to 32 bit boundaries [ Upstream commit 8d7ae22ae9f8c8a4407f8e993df64440bdbd0cee ] The commit (SHA1: 5c844d57aa7894154e49cf2fc648bfe2f1aefc1c) provided code to apply "Module 6: Certain PHY registers must be written as pairs instead of singly" errata for KSZ9477 as this chip for certain PHY registers (0xN120 to 0xN13F, N=1,2,3,4,5) must be accesses as 32 bit words instead of 16 or 8 bit access. Otherwise, adjacent registers (no matter if reserved or not) are overwritten with 0x0. Without this patch some registers (e.g. 0x113c or 0x1134) required for 32 bit access are out of valid regmap ranges. As a result, following error is observed and KSZ9477 is not properly configured: ksz-switch spi1.0: can't rmw 32bit reg 0x113c: -EIO ksz-switch spi1.0: can't rmw 32bit reg 0x1134: -EIO ksz-switch spi1.0 lan1 (uninitialized): failed to connect to PHY: -EIO ksz-switch spi1.0 lan1 (uninitialized): error -5 setting up PHY for tree 0, switch 0, port 0 The solution is to modify regmap_reg_range to allow accesses with 4 bytes boundaries. Signed-off-by: Lukasz Majewski <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nicolas Dichtel <[email protected]> Date: Wed Aug 23 15:41:02 2023 +0200 net: handle ARPHRD_PPP in dev_is_mac_header_xmit() commit a4f39c9f14a634e4cd35fcd338c239d11fcc73fc upstream. The goal is to support a bpf_redirect() from an ethernet device (ingress) to a ppp device (egress). The l2 header is added automatically by the ppp driver, thus the ethernet header should be removed. CC: [email protected] Fixes: 27b29f63058d ("bpf: add bpf_redirect() helper") Signed-off-by: Nicolas Dichtel <[email protected]> Tested-by: Siwar Zitouni <[email protected]> Reviewed-by: Guillaume Nault <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Hao Lan <[email protected]> Date: Thu Jul 20 10:05:08 2023 +0800 net: hns3: add tm flush when setting tm [ Upstream commit 6d2336120aa6e1a8a64fa5d6ee5c3f3d0809fe9b ] When the tm module is configured with traffic, traffic may be abnormal. This patch fixes this problem. Before the tm module is configured, traffic processing should be stopped. After the tm module is configured, traffic processing is enabled. Signed-off-by: Hao Lan <[email protected]> Signed-off-by: Jijie Shao <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jijie Shao <[email protected]> Date: Tue Aug 15 14:06:41 2023 +0800 net: hns3: fix wrong rpu tln reg issue [ Upstream commit 36122201eeaefd78547def9681aa5d83b5a00b6a ] In the original RPU query command, the status register values of multiple RPU tunnels are accumulated by default, which is unreasonable. This patch Fix it by querying the specified tunnel ID. The tunnel number of the device can be obtained from firmware during initialization. Fixes: ddb54554fa51 ("net: hns3: add DFX registers information for ethtool -d") Signed-off-by: Jijie Shao <[email protected]> Reviewed-by: Leon Romanovsky <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jijie Shao <[email protected]> Date: Tue Aug 15 14:06:38 2023 +0800 net: hns3: move dump regs function to a separate file [ Upstream commit 939ccd107ffcade20c9c7055a2e7ae0fd724fb72 ] The dump register function is being refactored. The first step in refactoring is put the dump regs function into a separate file. Signed-off-by: Jijie Shao <[email protected]> Reviewed-by: Leon Romanovsky <[email protected]> Signed-off-by: David S. Miller <[email protected]> Stable-dep-of: 36122201eeae ("net: hns3: fix wrong rpu tln reg issue") Signed-off-by: Sasha Levin <[email protected]>
Author: Jian Shen <[email protected]> Date: Mon Aug 7 19:34:49 2023 +0800 net: hns3: restore user pause configure when disable autoneg [ Upstream commit 15159ec0c831b565820c2de05114ea1b4cf07681 ] Restore the mac pause state to user configuration when autoneg is disabled Signed-off-by: Jian Shen <[email protected]> Signed-off-by: Peiyang Wang <[email protected]> Signed-off-by: Jijie Shao <[email protected]> Reviewed-by: Leon Romanovsky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jijie Shao <[email protected]> Date: Tue Aug 15 14:06:39 2023 +0800 net: hns3: Support tlv in regs data for HNS3 PF driver [ Upstream commit d8634b7c3f62d265fc2ecf29286aa9c5b78f969f ] The dump register function is being refactored. The second step in refactoring is to support tlv info in regs data for HNS3 PF driver. Currently, if we use "ethtool -d" to dump regs value, the output is as follows: offset1: 00 01 02 03 04 05 ... offset2：10 11 12 13 14 15 ... ...... We can't get the value of a register directly. This patch deletes the original separator information and add tag_len_value information in regs data. ethtool can parse register data in key-value format by -d command. a patch will be added to the ethtool to parse regs data in the following format: reg1 : value2 reg2 : value2 ...... Signed-off-by: Jijie Shao <[email protected]> Reviewed-by: Leon Romanovsky <[email protected]> Signed-off-by: David S. Miller <[email protected]> Stable-dep-of: 36122201eeae ("net: hns3: fix wrong rpu tln reg issue") Signed-off-by: Sasha Levin <[email protected]>
Author: Ruan Jinjie <[email protected]> Date: Fri Aug 18 13:05:04 2023 +0800 net: lan966x: Fix return value check for vcap_get_rule() [ Upstream commit ab104318f63997113b0ce7ac288e51359925ed79 ] As Simon Horman suggests, update vcap_get_rule() to always return an ERR_PTR() and update the error detection conditions to use IS_ERR(), so use IS_ERR() to fix the return value issue. Fixes: 72df3489fb10 ("net: lan966x: Add ptp trap rules") Signed-off-by: Ruan Jinjie <[email protected]> Suggested-by: Simon Horman <[email protected]> Reviewed-by: Leon Romanovsky <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Josua Mayer <[email protected]> Date: Fri Aug 18 13:05:56 2023 +0200 net: sfp: handle 100G/25G active optical cables in sfp_parse_support [ Upstream commit db1a6ad77c180efc7242d7204b9a0c72c8a5a1bb ] Handle extended compliance code 0x1 (SFF8024_ECC_100G_25GAUI_C2M_AOC) for active optical cables supporting 25G and 100G speeds. Since the specification makes no statement about transmitter range, and as the specific sfp module that had been tested features only 2m fiber - short-range (SR) modes are selected. The 100G speed is irrelevant because it would require multiple fibers / multiple SFP28 modules combined under one netdev. sfp-bus.c only handles a single module per netdev, so only 25Gbps modes are selected. sfp_parse_support already handles SFF8024_ECC_100GBASE_SR4_25GBASE_SR with compatible properties, however that entry is a contradiction in itself since with SFP(28) 100GBASE_SR4 is impossible - that would likely be a mode for qsfp modules only. Add a case for SFF8024_ECC_100G_25GAUI_C2M_AOC selecting 25gbase-r interface mode and 25000baseSR link mode. Also enforce SFP28 bitrate limits on the values read from sfp eeprom as requested by Russell King. Tested with fs.com S28-AO02 AOC SFP28 module. Signed-off-by: Josua Mayer <[email protected]> Reviewed-by: Russell King (Oracle) <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Menglong Dong <[email protected]> Date: Fri Aug 11 10:55:29 2023 +0800 net: tcp: fix unexcepted socket die when snd_wnd is 0 [ Upstream commit e89688e3e97868451a5d05b38a9d2633d6785cd4 ] In tcp_retransmit_timer(), a window shrunk connection will be regarded as timeout if 'tcp_jiffies32 - tp->rcv_tstamp > TCP_RTO_MAX'. This is not right all the time. The retransmits will become zero-window probes in tcp_retransmit_timer() if the 'snd_wnd==0'. Therefore, the icsk->icsk_rto will come up to TCP_RTO_MAX sooner or later. However, the timer can be delayed and be triggered after 122877ms, not TCP_RTO_MAX, as I tested. Therefore, 'tcp_jiffies32 - tp->rcv_tstamp > TCP_RTO_MAX' is always true once the RTO come up to TCP_RTO_MAX, and the socket will die. Fix this by replacing the 'tcp_jiffies32' with '(u32)icsk->icsk_timeout', which is exact the timestamp of the timeout. However, "tp->rcv_tstamp" can restart from idle, then tp->rcv_tstamp could already be a long time (minutes or hours) in the past even on the first RTO. So we double check the timeout with the duration of the retransmission. Meanwhile, making "2 * TCP_RTO_MAX" as the timeout to avoid the socket dying too soon. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Link: https://lore.kernel.org/netdev/CADxym3YyMiO+zMD4zj03YPM3FBi-1LHi6gSD2XT8pyAMM096pg@mail.gmail.com/ Signed-off-by: Menglong Dong <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Martin Kohn <[email protected]> Date: Thu Jul 27 20:00:43 2023 +0000 net: usb: qmi_wwan: add Quectel EM05GV2 [ Upstream commit d4480c9bb9258db9ddf2e632f6ef81e96b41089c ] Add support for Quectel EM05GV2 (G=global) with vendor ID 0x2c7c and product ID 0x030e Enabling DTR on this modem was necessary to ensure stable operation. Patch for usb: serial: option: is also in progress. T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=030e Rev= 3.18 S: Manufacturer=Quectel S: Product=Quectel EM05-G C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 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#= 1 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#= 3 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#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan 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 Signed-off-by: Martin Kohn <[email protected]> Link: https://lore.kernel.org/r/AM0PR04MB57648219DE893EE04FA6CC759701A@AM0PR04MB5764.eurprd04.prod.outlook.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <[email protected]>
Author: Kyle Zeng <[email protected]> Date: Tue Sep 5 15:04:09 2023 -0700 netfilter: ipset: add the missing IP_SET_HASH_WITH_NET0 macro for ip_set_hash_netportnet.c commit 050d91c03b28ca479df13dfb02bcd2c60dd6a878 upstream. The missing IP_SET_HASH_WITH_NET0 macro in ip_set_hash_netportnet can lead to the use of wrong `CIDR_POS(c)` for calculating array offsets, which can lead to integer underflow. As a result, it leads to slab out-of-bound access. This patch adds back the IP_SET_HASH_WITH_NET0 macro to ip_set_hash_netportnet to address the issue. Fixes: 886503f34d63 ("netfilter: ipset: actually allow allowable CIDR 0 in hash:net,port,net") Suggested-by: Jozsef Kadlecsik <[email protected]> Signed-off-by: Kyle Zeng <[email protected]> Acked-by: Jozsef Kadlecsik <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Xiao Liang <[email protected]> Date: Fri Aug 25 13:33:27 2023 +0800 netfilter: nft_exthdr: Fix non-linear header modification commit 28427f368f0e08d504ed06e74bc7cc79d6d06511 upstream. Fix skb_ensure_writable() size. Don't use nft_tcp_header_pointer() to make it explicit that pointers point to the packet (not local buffer). Fixes: 99d1712bc41c ("netfilter: exthdr: tcp option set support") Fixes: 7890cbea66e7 ("netfilter: exthdr: add support for tcp option removal") Cc: [email protected] Signed-off-by: Xiao Liang <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Wander Lairson Costa <[email protected]> Date: Mon Aug 28 19:12:55 2023 -0300 netfilter: xt_sctp: validate the flag_info count commit e99476497687ef9e850748fe6d232264f30bc8f9 upstream. sctp_mt_check doesn't validate the flag_count field. An attacker can take advantage of that to trigger a OOB read and leak memory information. Add the field validation in the checkentry function. Fixes: 2e4e6a17af35 ("[NETFILTER] x_tables: Abstraction layer for {ip,ip6,arp}_tables") Cc: [email protected] Reported-by: Lucas Leong <[email protected]> Signed-off-by: Wander Lairson Costa <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Wander Lairson Costa <[email protected]> Date: Mon Aug 28 10:21:07 2023 -0300 netfilter: xt_u32: validate user space input commit 69c5d284f67089b4750d28ff6ac6f52ec224b330 upstream. The xt_u32 module doesn't validate the fields in the xt_u32 structure. An attacker may take advantage of this to trigger an OOB read by setting the size fields with a value beyond the arrays boundaries. Add a checkentry function to validate the structure. This was originally reported by the ZDI project (ZDI-CAN-18408). Fixes: 1b50b8a371e9 ("[NETFILTER]: Add u32 match") Cc: [email protected] Signed-off-by: Wander Lairson Costa <wande[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kuniyuki Iwashima <[email protected]> Date: Thu Aug 24 09:50:59 2023 -0700 netrom: Deny concurrent connect(). [ Upstream commit c2f8fd7949603efb03908e05abbf7726748c8de3 ] syzkaller reported null-ptr-deref [0] related to AF_NETROM. This is another self-accept issue from the strace log. [1] syz-executor creates an AF_NETROM socket and calls connect(), which is blocked at that time. Then, sk->sk_state is TCP_SYN_SENT and sock->state is SS_CONNECTING. [pid 5059] socket(AF_NETROM, SOCK_SEQPACKET, 0) = 4 [pid 5059] connect(4, {sa_family=AF_NETROM, sa_data="..." <unfinished ...> Another thread calls connect() concurrently, which finally fails with -EINVAL. However, the problem here is the socket state is reset even while the first connect() is blocked. [pid 5060] connect(4, NULL, 0 <unfinished ...> [pid 5060] <... connect resumed>) = -1 EINVAL (Invalid argument) As sk->state is TCP_CLOSE and sock->state is SS_UNCONNECTED, the following listen() succeeds. Then, the first connect() looks up itself as a listener and puts skb into the queue with skb->sk itself. As a result, the next accept() gets another FD of itself as 3, and the first connect() finishes. [pid 5060] listen(4, 0 <unfinished ...> [pid 5060] <... listen resumed>) = 0 [pid 5060] accept(4, NULL, NULL <unfinished ...> [pid 5060] <... accept resumed>) = 3 [pid 5059] <... connect resumed>) = 0 Then, accept4() is called but blocked, which causes the general protection fault later. [pid 5059] accept4(4, NULL, 0x20000400, SOCK_NONBLOCK <unfinished ...> After that, another self-accept occurs by accept() and writev(). [pid 5060] accept(4, NULL, NULL <unfinished ...> [pid 5061] writev(3, [{iov_base=...}] <unfinished ...> [pid 5061] <... writev resumed>) = 99 [pid 5060] <... accept resumed>) = 6 Finally, the leader thread close()s all FDs. Since the three FDs reference the same socket, nr_release() does the cleanup for it three times, and the remaining accept4() causes the following fault. [pid 5058] close(3) = 0 [pid 5058] close(4) = 0 [pid 5058] close(5) = -1 EBADF (Bad file descriptor) [pid 5058] close(6) = 0 [pid 5058] <... exit_group resumed>) = ? [ 83.456055][ T5059] general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN To avoid the issue, we need to return an error for connect() if another connect() is in progress, as done in __inet_stream_connect(). [0]: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 0 PID: 5059 Comm: syz-executor.0 Not tainted 6.5.0-rc5-syzkaller-00194-gace0ab3a4b54 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023 RIP: 0010:__lock_acquire+0x109/0x5de0 kernel/locking/lockdep.c:5012 Code: 45 85 c9 0f 84 cc 0e 00 00 44 8b 05 11 6e 23 0b 45 85 c0 0f 84 be 0d 00 00 48 ba 00 00 00 00 00 fc ff df 4c 89 d1 48 c1 e9 03 <80> 3c 11 00 0f 85 e8 40 00 00 49 81 3a a0 69 48 90 0f 84 96 0d 00 RSP: 0018:ffffc90003d6f9e0 EFLAGS: 00010006 RAX: ffff8880244c8000 RBX: 1ffff920007adf6c RCX: 0000000000000003 RDX: dffffc0000000000 RSI: 0000000000000000 RDI: 0000000000000018 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000018 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f51d519a6c0(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f51d5158d58 CR3: 000000002943f000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> lock_acquire kernel/locking/lockdep.c:5761 [inline] lock_acquire+0x1ae/0x510 kernel/locking/lockdep.c:5726 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x3a/0x50 kernel/locking/spinlock.c:162 prepare_to_wait+0x47/0x380 kernel/sched/wait.c:269 nr_accept+0x20d/0x650 net/netrom/af_netrom.c:798 do_accept+0x3a6/0x570 net/socket.c:1872 __sys_accept4_file net/socket.c:1913 [inline] __sys_accept4+0x99/0x120 net/socket.c:1943 __do_sys_accept4 net/socket.c:1954 [inline] __se_sys_accept4 net/socket.c:1951 [inline] __x64_sys_accept4+0x96/0x100 net/socket.c:1951 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f51d447cae9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f51d519a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000120 RAX: ffffffffffffffda RBX: 00007f51d459bf80 RCX: 00007f51d447cae9 RDX: 0000000020000400 RSI: 0000000000000000 RDI: 0000000000000004 RBP: 00007f51d44c847a R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000800 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007f51d459bf80 R15: 00007ffc25c34e48 </TASK> Link: https://syzkaller.appspot.com/text?tag=CrashLog&x=152cdb63a80000 [1] Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=666c97e4686410e79649 Signed-off-by: Kuniyuki Iwashima <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Mon Jul 24 11:08:46 2023 +0300 nfs/blocklayout: Use the passed in gfp flags [ Upstream commit 08b45fcb2d4675f6182fe0edc0d8b1fe604051fa ] This allocation should use the passed in GFP_ flags instead of GFP_KERNEL. One places where this matters is in filelayout_pg_init_write() which uses GFP_NOFS as the allocation flags. Fixes: 5c83746a0cf2 ("pnfs/blocklayout: in-kernel GETDEVICEINFO XDR parsing") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Christoph Hellwig <[email protect