Select Git revision
Search by author
- Any Author
- authors
-
72162444 72162444 gaochangning
-
Aakash Dave aakash.dave
-
Aaron Kim akim
-
Aaron Kloc akloc
-
Aaron Lan aaron.lan
-
Aaron Nabil aaronna
-
Aaron Pohle aaron.pohle
-
Abbott Chung chung.abbott
-
Abdallah Omar abdallah_omar
-
Abdessamii Chalbi abdessamii.chalbi
-
Abdul Hussain Sirajudeen abdul.hussain
-
Abdullah Alghamdi a.alghamdi
-
Abdullah Elmarghany abdullah_elmarghany
-
Abel Fang abel_fang
-
Abel Vesa
abel.vesa
-
Abhijeet Badurkar abhijeet.badurkar
-
Abhijit Adsule adsule
-
Abhijit Murthy abhijit
-
Abhi Khanal akhanal
-
Abhilash Sahoo abhilashsahoo
- Dec 14, 2024
-
-
Christina Jacob authored
[ Upstream commit 84c4f9ca ] CGX block supports forward error correction modes baseR and RS. This patch adds support to set encoding mode and to read corrected/uncorrected block counters Adds new mailbox handlers set_fec to configure encoding modes and fec_stats to read counters and also increase mbox timeout to accomdate firmware command response timeout. Along with new CGX_CMD_SET_FEC command add other commands to sync with kernel enum list with firmware. Signed-off-by:
Christina Jacob <cjacob@marvell.com> Signed-off-by:
Sunil Goutham <sgoutham@marvell.com> Signed-off-by:
Hariprasad Kelam <hkelam@marvell.com> Reviewed-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Stable-dep-of: e26f8eac ("octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.c") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Subbaraya Sundeep authored
[ Upstream commit 8bcf5ced ] CGX links are followed by LBK links but number of CGX and LBK links varies between platforms. Hence get the number of links present in hardware from AF and use it to calculate LBK link number. Signed-off-by:
Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by:
Rakesh Babu <rsaladi2@marvell.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Stable-dep-of: e26f8eac ("octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.c") Signed-off-by:
-
Subbaraya Sundeep authored
[ Upstream commit a84cdcea ] This patch puts together all mailbox changes for 98xx silicon: Attach -> Modify resource attach mailbox handler to request LFs from a block address out of multiple blocks of same type. If a PF/VF need LFs from two blocks of same type then attach mbox should be called twice. Example: struct rsrc_attach *attach; .. Allocate memory for message .. attach->cptlfs = 3; /* 3 LFs from CPT0 */ .. Send message .. .. Allocate memory for message .. attach->modify = 1; attach->cpt_blkaddr = BLKADDR_CPT1; attach->cptlfs = 2; /* 2 LFs from CPT1 */ .. Send message .. Detach -> Update detach mailbox and its handler to detach resources from CPT1 and NIX1 blocks. MSIX -> Updated the MSIX mailbox and its handler to return MSIX offsets for the new block CPT1. Free resources -> Update free_rsrc mailbox and its handler to return the free resources count of new blocks NIX1 and CPT1 Links -> Number of CGX,LBK and SDP links may vary between platforms. For example, in 98xx number of CGX and LBK links are more than 96xx. Hence the info about number of links present in hardware is useful for consumers to request link configuration properly. This patch sends this info in nix_lf_alloc_rsp. Signed-off-by:
-
Matthias Schiffer authored
[ Upstream commit ffcde9e4 ] The PIXCLK needs to be enabled in SCFG before accessing certain DCU registers, or the access will hang. For simplicity, the PIXCLK is enabled unconditionally, resulting in increased power consumption. Signed-off-by:
Matthias Schiffer <matthias.schiffer@tq-group.com> Signed-off-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Fixes: 109eee2f ("drm/layerscape: Add Freescale DCU DRM driver") Acked-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240926055552.1632448-2-alexander.stein@ew.tq-group.com Signed-off-by:
-
Thomas Zimmermann authored
[ Upstream commit 03ac16e5 ] Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers don't benefit from using it. DRM IRQ callbacks are now being called directly or inlined. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210803090704.32152-5-tzimmermann@suse.de Stable-dep-of: ffcde9e4 ("drm: fsl-dcu: enable PIXCLK on LS1021A") Signed-off-by:
-
Alper Nebi Yasak authored
[ Upstream commit d241a139 ] Replace one-element array with a flexible-array member in `struct mwifiex_ie_types_wildcard_ssid_params` to fix the following warning on a MT8173 Chromebook (mt8173-elm-hana): [ 356.775250] ------------[ cut here ]------------ [ 356.784543] memcpy: detected field-spanning write (size 6) of single field "wildcard_ssid_tlv->ssid" at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1) [ 356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex] The "(size 6)" above is exactly the length of the SSID of the network this device was connected to. The source of the warning looks like: ssid_len = user_scan_in->ssid_list[i].ssid_len; [...] memcpy(wildcard_ssid_tlv->ssid, user_scan_in->ssid_list[i].ssid, ssid_len); There is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this struct, but it already didn't account for the size of the one-element array, so it doesn't need to be changed. Fixes: 5e6e3a92 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Signed-off-by:
Alper Nebi Yasak <alpernebiyasak@gmail.com> Acked-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241007222301.24154-1-alpernebiyasak@gmail.com Signed-off-by:
-
Zijian Zhang authored
[ Upstream commit b29e231d ] txmsg_redir in "Test pull + redirect" case of test_txmsg_pull should be 1 instead of 0. Fixes: 328aa08a ("bpf: Selftests, break down test_sockmap into subtests") Acked-by:
John Fastabend <john.fastabend@gmail.com> Signed-off-by:
Zijian Zhang <zijianzhang@bytedance.com> Link: https://lore.kernel.org/r/20241012203731.1248619-3-zijianzhang@bytedance.com Signed-off-by:
Martin KaFai Lau <martin.lau@kernel.org> Signed-off-by:
-
Zijian Zhang authored
[ Upstream commit ee9b352c ] Function msg_verify_data should have context of bytes_cnt and k instead of assuming they are zero. Otherwise, test_sockmap with data integrity test will report some errors. I also fix the logic related to size and index j 1/ 6 sockmap::txmsg test passthrough:FAIL 2/ 6 sockmap::txmsg test redirect:FAIL 7/12 sockmap::txmsg test apply:FAIL 10/11 sockmap::txmsg test push_data:FAIL 11/17 sockmap::txmsg test pull-data:FAIL 12/ 9 sockmap::txmsg test pop-data:FAIL 13/ 1 sockmap::txmsg test push/pop data:FAIL ... Pass: 24 Fail: 52 After applying this patch, some of the errors are solved, but for push, pull and pop, we may need more fixes to msg_verify_data, added a TODO 10/11 sockmap::txmsg test push_data:FAIL 11/17 sockmap::txmsg test pull-data:FAIL 12/ 9 sockmap::txmsg test pop-data:FAIL ... Pass: 37 Fail: 15 Besides, added a custom errno EDATAINTEGRITY for msg_verify_data, we shall not ignore the error in txmsg_cork case. Fixes: 753fb2ee ("bpf: sockmap, add msg_peek tests to test_sockmap") Fixes: 16edddfe ("selftests/bpf: test_sockmap, check test failure") Acked-by:
-
Tomi Valkeinen authored
[ Upstream commit 2d343723 ] When a display controller driver uses DRM_BRIDGE_ATTACH_NO_CONNECTOR, tc358767 will behave properly and skip the creation of the connector. However, tc_get_display_props(), which is used to find out about the DP monitor and link, is only called from two places: .atomic_enable() and tc_connector_get_modes(). The latter is only used when tc358767 creates its own connector, i.e. when DRM_BRIDGE_ATTACH_NO_CONNECTOR is _not_ set. Thus, the driver never finds out the link properties before get_edid() is called. With num_lanes of 0 and link_rate of 0 there are not many valid modes... Fix this by adding tc_get_display_props() call at the beginning of get_edid(), so that we have up to date information before looking at the modes. Reported-by:
Jan Kiszka <jan.kiszka@siemens.com> Closes: https://lore.kernel.org/all/24282420-b4dd-45b3-bb1c-fc37fe4a8205@siemens.com/ Fixes: de5e6c02 ("drm/bridge: tc358767: add drm_panel_bridge support") Reviewed-by:
Aradhya Bhatia <a-bhatia1@ti.com> Tested-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231108-tc358767-v2-2-25c5f70a2159@ideasonboard.com Signed-off-by:
-
Hangbin Liu authored
[ Upstream commit 2cf567f4 ] The current code only copies the address for the in path, leaving the out path address set to 0. This patch corrects the issue by copying the addresses for both the in and out paths. Before this patch: # cat /sys/kernel/debug/netdevsim/netdevsim0/ports/0/ipsec SA count=2 tx=20 sa[0] tx ipaddr=0.0.0.0 sa[0] spi=0x00000100 proto=0x32 salt=0x0adecc3a crypt=1 sa[0] key=0x3167608a ca4f1397 43565909 941fa627 sa[1] rx ipaddr=192.168.0.1 sa[1] spi=0x00000101 proto=0x32 salt=0x0adecc3a crypt=1 sa[1] key=0x3167608a ca4f1397 43565909 941fa627 After this patch: = cat /sys/kernel/debug/netdevsim/netdevsim0/ports/0/ipsec SA count=2 tx=20 sa[0] tx ipaddr=192.168.0.2 sa[0] spi=0x00000100 proto=0x32 salt=0x0adecc3a crypt=1 sa[0] key=0x3167608a ca4f1397 43565909 941fa627 sa[1] rx ipaddr=192.168.0.1 sa[1] spi=0x00000101 proto=0x32 salt=0x0adecc3a crypt=1 sa[1] key=0x3167608a ca4f1397 43565909 941fa627 Fixes: 7699353d ("netdevsim: add ipsec offload testing") Reviewed-by:
Simon Horman <horms@kernel.org> Signed-off-by:
Hangbin Liu <liuhangbin@gmail.com> Link: https://patch.msgid.link/20241010040027.21440-3-liuhangbin@gmail.com Signed-off-by:
-
Leon Romanovsky authored
[ Upstream commit 55e2f83a ] Make sure that netdevsim relies on direction and not on flags. Reviewed-by:
Raed Salem <raeds@nvidia.com> Signed-off-by:
Leon Romanovsky <leonro@nvidia.com> Acked-by:
Steffen Klassert <steffen.klassert@secunet.com> Stable-dep-of: 2cf567f4 ("netdevsim: copy addresses for both in and out paths") Signed-off-by:
-
Leon Romanovsky authored
[ Upstream commit 482db2f1 ] XFRM state doesn't need anything from flags except to understand direction, so store it separately. For future patches, such change will allow us to reuse xfrm_dev_offload for policy offload too, which has three possible directions instead of two. Reviewed-by:
-
Leon Romanovsky authored
[ Upstream commit 87e0a94e ] The struct xfrm_state_offload has all fields needed to hold information for offloaded policies too. In order to do not create new struct with same fields, let's rename existing one and reuse it later. Reviewed-by:
-
Yuan Chen authored
[ Upstream commit 4236f114 ] During the xdp_adjust_tail test, probabilistic failure occurs and SKB package is discarded by the kernel. After checking the issues by tracking SKB package, it is identified that they were caused by checksum errors. Refer to checksum of the arch/arm64/include/asm/checksum.h for fixing. v2: Based on Alexei Starovoitov's suggestions, it is necessary to keep the code implementation consistent. Fixes: c6ffd1ff (bpf: add bpf_xdp_adjust_tail sample prog) Signed-off-by:
Yuan Chen <chenyuan@kylinos.cn> Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20240930024115.52841-1-chenyuan_fl@163.com Signed-off-by:
-
Macpaul Lin authored
[ Upstream commit 4649cbd9 ] Some fix and updates in the following items: 1. examples: Update generic node name to 'audio-codec' to comply with the coming change in 'mt6359.dtsi'. This change is necessary to fix the dtbs_check error: pmic: 'mt6359codec' does not match any of the regexes: 'pinctrl-[0-9]+' 2. mediatek,dmic-mode: After inspecting the .dts and .dtsi files using 'mt6359-codec', it was discovered that the definitions of 'two wires' and 'one wire' are inverted compared to the DT schema. For example, the following boards using MT6359 PMIC: - mt8192-asurada.dtsi - mt8195-cherry.dtsi These boards use the same definitions of 'dmic-mode' as other boards using MT6358 PMIC. The meaning of '0' or '1' has been noted as comments in the device trees. Upon examining the code in [1] and [2], it was confirmed that the definitions of 'dmic-mode' are consistent between "MT6359 PMIC" and "MT6358 PMIC". Therefore, the DT Schema should be correct as is. References: [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/codecs/mt6358.c#n1875 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/codecs/mt6359.c#L1515 Fixes: 539237d1 ("dt-bindings: mediatek: mt6359: add codec document") Signed-off-by:
Jiaxin Yu <jiaxin.yu@mediatek.com> Signed-off-by:
Macpaul Lin <macpaul.lin@mediatek.com> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patch.msgid.link/20240930075451.14196-1-macpaul.lin@mediatek.com Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Shengjiu Wang authored
[ Upstream commit 06df673d ] The last parameter 1 means BIT(0), which should be the correct BIT(X). Fixes: 47a70e6f ("ASoC: Add MICFIL SoC Digital Audio Interface driver.") Signed-off-by:
Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by:
Daniel Baluta <daniel.baluta@nxp.com> Link: https://patch.msgid.link/1727424031-19551-2-git-send-email-shengjiu.wang@nxp.com Signed-off-by:
-
Sascha Hauer authored
[ Upstream commit 17f2142b ] Use GENMASK along with FIELD_PREP and FIELD_GET to access bitfields in registers to straighten register access and to drop a lot of defines. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Acked-by:
Shengjiu Wang <shengjiu.wang@gmail.com> Link: https://lore.kernel.org/r/20220414162249.3934543-6-s.hauer@pengutronix.de Signed-off-by:
-
Sascha Hauer authored
[ Upstream commit bd2cffd1 ] No need to have defines for the mask of single bits. Also shift is unused. Drop all these unnecessary defines. Signed-off-by:
-
Sascha Hauer authored
[ Upstream commit c808e277 ] in get_pdm_clk() REG_MICFIL_CTRL2 is read twice. Drop second read. Signed-off-by:
-
Igor Prusov authored
[ Upstream commit 5d9e6d6f ] Add vendor prefix for NeoFidelity, Inc Signed-off-by:
Igor Prusov <ivprusov@salutedevices.com> Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20240925-ntp-amps-8918-8835-v3-1-e2459a8191a6@salutedevices.com Signed-off-by:
-
Baochen Qiang authored
[ Upstream commit 52db16ec ] In supported_vht_mcs_rate_nss2, the rate for MCS9 & VHT20 is defined as {1560, 1733}, this does not align with firmware's definition and therefore fails the verification in ath10k_mac_get_rate_flags_vht(): invalid vht params rate 1730 100kbps nss 2 mcs 9 and: invalid vht params rate 1920 100kbps nss 2 mcs 9 Change it to {1730, 1920} to align with firmware to fix the issue. Since ath10k_hw_params::supports_peer_stats_info is enabled only for QCA6174, this change does not affect other chips. Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00309-QCARMSWPZ-1 Fixes: 3344b99d ("ath10k: add bitrate parse for peer stats info") Reported-by:
Paul Menzel <pmenzel@molgen.mpg.de> Closes: https://lore.kernel.org/lkml/fba24cd3-4a1e-4072-8585-8402272788ff@molgen.mpg.de/ Signed-off-by:
Baochen Qiang <quic_bqiang@quicinc.com> Acked-by:
Jeff Johnson <quic_jjohnson@quicinc.com> Tested-by: Paul Menzel <pmenzel@molgen.mpg.de> # Dell XPS 13 9360 Signed-off-by:
Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20240711020344.98040-3-quic_bqiang@quicinc.com Signed-off-by:
-
Baochen Qiang authored
[ Upstream commit d50886b2 ] In supported_vht_mcs_rate_nss1, the rate for MCS9 & VHT20 is defined as {780, 867}, this does not align with firmware's definition and therefore fails the verification in ath10k_mac_get_rate_flags_vht(): invalid vht params rate 960 100kbps nss 1 mcs 9 Change it to {865, 960} to align with firmware, so this issue could be fixed. Since ath10k_hw_params::supports_peer_stats_info is enabled only for QCA6174, this change does not affect other chips. Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00309-QCARMSWPZ-1 Fixes: 3344b99d ("ath10k: add bitrate parse for peer stats info") Reported-by:
-
Maíra Canal authored
[ Upstream commit cf1becb7 ] We must first flush the MMU cache and then, flush the TLB, not the other way around. Currently, we can see a race condition between the MMU cache and the TLB when running multiple rendering processes at the same time. This is evidenced by MMU errors triggered by the IRQ. Fix the MMU flush order by flushing the MMU cache and then the TLB. Also, in order to address the race condition, wait for the MMU cache flush to finish before starting the TLB flush. Fixes: 57692c94 ("drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+") Signed-off-by:
Maíra Canal <mcanal@igalia.com> Reviewed-by:
Iago Toral Quiroga <itoral@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240923141348.2422499-2-mcanal@igalia.com Signed-off-by:
-
Jinjie Ruan authored
[ Upstream commit 40004709 ] disable_irq() after request_irq() still has a time gap in which interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will disable IRQ auto-enable when request IRQ. Fixes: 47b1be5c ("staging: imx/drm: request irq only after adding the crtc") Reviewed-by:
Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by:
Philipp Zabel <p.zabel@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240912083020.3720233-4-ruanjinjie@huawei.com Signed-off-by:
-
Jinjie Ruan authored
[ Upstream commit 1af01e14 ] disable_irq() after request_irq() still has a time gap in which interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will disable IRQ auto-enable when request IRQ. Fixes: 9021c317 ("drm/imx: Add initial support for DCSS on iMX8MQ") Signed-off-by:
Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240912083020.3720233-2-ruanjinjie@huawei.com [DB: fixed the subject] Signed-off-by:
-
Jinjie Ruan authored
[ Upstream commit 9a98dd48 ] disable_irq() after request_irq() still has a time gap in which interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will disable IRQ auto-enable when request IRQ. Fixes: 853402a0 ("mwifiex: Enable WoWLAN for both sdio and pcie") Signed-off-by:
-
Jinjie Ruan authored
[ Upstream commit bcd1371b ] disable_irq() after request_irq() still has a time gap in which interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will disable IRQ auto-enable when request IRQ. Fixes: cd8d3d32 ("p54spi: p54spi driver") Signed-off-by:
-
Tomi Valkeinen authored
[ Upstream commit e6a1c403 ] omap_gem_new_dmabuf() creates the new gem object, and then takes and holds the omap_obj->lock for the rest of the function. This has two issues: - omap_gem_free_object(), which is called in the error paths, also takes the same lock, leading to deadlock - Even if the above wouldn't happen, in the error cases omap_gem_new_dmabuf() still unlocks omap_obj->lock, even after the omap_obj has already been freed. Furthermore, I don't think there's any reason to take the lock at all, as the object was just created and not yet shared with anyone else. To fix all this, drop taking the lock. Fixes: 3cbd0c58 ("drm/omap: gem: Replace struct_mutex usage with omap_obj private lock") Reported-by:
Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/all/511b99d7-aade-4f92-bd3e-63163a13d617@stanley.mountain/ Reviewed-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by:
-
Jeongjun Park authored
[ Upstream commit 86195936 ] I found the following bug in my fuzzer: UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htc_hst.c:26:51 index 255 is out of range for type 'htc_endpoint [22]' CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: events request_firmware_work_func Call Trace: <TASK> dump_stack_lvl+0x180/0x1b0 __ubsan_handle_out_of_bounds+0xd4/0x130 htc_issue_send.constprop.0+0x20c/0x230 ? _raw_spin_unlock_irqrestore+0x3c/0x70 ath9k_wmi_cmd+0x41d/0x610 ? mark_held_locks+0x9f/0xe0 ... Since this bug has been confirmed to be caused by insufficient verification of conn_rsp_epid, I think it would be appropriate to add a range check for conn_rsp_epid to htc_connect_service() to prevent the bug from occurring. Fixes: fb9987d0 ("ath9k_htc: Support for AR9271 chipset.") Signed-off-by:
Jeongjun Park <aha310510@gmail.com> Acked-by:
Toke Høiland-Jørgensen <toke@toke.dk> Signed-off-by:
-
Andy Shevchenko authored
[ Upstream commit 53bd7c1c ] The INTERVAL_TREE_DEFINE() uncoditionally provides a bunch of helper functions which in some cases may be not used. This, in particular, prevents kernel builds with clang, `make W=1` and CONFIG_WERROR=y: .../drm/drm_mm.c:152:1: error: unused function 'drm_mm_interval_tree_insert' [-Werror,-Wunused-function] 152 | INTERVAL_TREE_DEFINE(struct drm_mm_node, rb, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 153 | u64, __subtree_last, | ~~~~~~~~~~~~~~~~~~~~ 154 | START, LAST, static inline, drm_mm_interval_tree) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fix this by marking drm_mm_interval_tree*() functions with __maybe_unused. See also commit 6863f564 ("kbuild: allow Clang to find unused static inline functions for W=1 build"). Fixes: 202b52b7 ("drm: Track drm_mm nodes with an interval tree") Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240829154640.1120050-1-andriy.shevchenko@linux.intel.com Signed-off-by:
-
Li Huafei authored
[ Upstream commit ed61c591 ] In ia_css_3a_statistics_allocate(), there is no check on the allocation result of the rgby_data memory. If rgby_data is not successfully allocated, it may trigger the assert(host_stats->rgby_data) assertion in ia_css_s3a_hmem_decode(). Adding a check to fix this potential issue. Fixes: a49d2536 ("staging/atomisp: Add support for the Intel IPU v2") Signed-off-by:
Li Huafei <lihuafei1@huawei.com> Reviewed-by:
Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20241104145051.3088231-1-lihuafei1@huawei.com Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by:
-
Mauro Carvalho Chehab authored
[ Upstream commit 63705da3 ] This is not defined anywhere, so, solve the ifdefs, getting rid of them. Signed-off-by:
-
Luo Qiu authored
[ Upstream commit 109aa654 ] Fix a kernel crash with the below call trace when the SCPI firmware returns OPP count of zero. dvfs_info.opp_count may be zero on some platforms during the reboot test, and the kernel will crash after dereferencing the pointer to kcalloc(info->count, sizeof(*opp), GFP_KERNEL). | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 | Mem abort info: | ESR = 0x96000004 | Exception class = DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | Data abort info: | ISV = 0, ISS = 0x00000004 | CM = 0, WnR = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000faefa08c | [0000000000000028] pgd=0000000000000000 | Internal error: Oops: 96000004 [#1] SMP | scpi-hwmon: probe of PHYT000D:00 failed with error -110 | Process systemd-udevd (pid: 1701, stack limit = 0x00000000aaede86c) | CPU: 2 PID: 1701 Comm: systemd-udevd Not tainted 4.19.90+ #1 | Hardware name: PHYTIUM LTD Phytium FT2000/4/Phytium FT2000/4, BIOS | pstate: 60000005 (nZCv daif -PAN -UAO) | pc : scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | lr : clk_register+0x438/0x720 | Call trace: | scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | devm_clk_hw_register+0x50/0xa0 | scpi_clk_ops_init.isra.2+0xa0/0x138 [clk_scpi] | scpi_clocks_probe+0x528/0x70c [clk_scpi] | platform_drv_probe+0x58/0xa8 | really_probe+0x260/0x3d0 | driver_probe_device+0x12c/0x148 | device_driver_attach+0x74/0x98 | __driver_attach+0xb4/0xe8 | bus_for_each_dev+0x88/0xe0 | driver_attach+0x30/0x40 | bus_add_driver+0x178/0x2b0 | driver_register+0x64/0x118 | __platform_driver_register+0x54/0x60 | scpi_clocks_driver_init+0x24/0x1000 [clk_scpi] | do_one_initcall+0x54/0x220 | do_init_module+0x54/0x1c8 | load_module+0x14a4/0x1668 | __se_sys_finit_module+0xf8/0x110 | __arm64_sys_finit_module+0x24/0x30 | el0_svc_common+0x78/0x170 | el0_svc_handler+0x38/0x78 | el0_svc+0x8/0x340 | Code: 937d7c00 a94153f3 a8c27bfd f9400421 (b8606820) | ---[ end trace 06feb22469d89fa8 ]--- | Kernel panic - not syncing: Fatal exception | SMP: stopping secondary CPUs | Kernel Offset: disabled | CPU features: 0x10,a0002008 | Memory Limit: none Fixes: 8cb7cf56 ("firmware: add support for ARM System Control and Power Interface(SCPI) protocol") Signed-off-by:
Luo Qiu <luoqiu@kylinsec.com.cn> Message-Id: <55A2F7A784391686+20241101032115.275977-1-luoqiu@kylinsec.com.cn> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com> Signed-off-by:
-
Reinette Chatre authored
[ Upstream commit 48ed4e79 ] The MBM and MBA tests need to discover the event and umask with which to configure the performance event used to measure read memory bandwidth. This is done by parsing the /sys/bus/event_source/devices/uncore_imc_<imc instance>/events/cas_count_read file for each iMC instance that contains the formatted output: "event=<event>,umask=<umask>" Parsing of cas_count_read contents is done by initializing an array of MAX_TOKENS elements with tokens (deliminated by "=,") from this file. Remove the unnecessary append of a delimiter to the string needing to be parsed. Per the strtok() man page: "delimiter bytes at the start or end of the string are ignored". This has no impact on the token placement within the array. After initialization, the actual event and umask is determined by parsing the tokens directly following the "event" and "umask" tokens respectively. Iterating through the array up to index "i < MAX_TOKENS" but then accessing index "i + 1" risks array overrun during the final iteration. Avoid array overrun by ensuring that the index used within for loop will always be valid. Fixes: 1d3f0868 ("selftests/resctrl: Read memory bandwidth from perf IMC counter and from resctrl file system") Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Reviewed-by:
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by:
Shuah Khan <skhan@linuxfoundation.org> Signed-off-by:
-
Andy Shevchenko authored
[ Upstream commit 953e5494 ] Lockdep gives a false positive splat as it can't distinguish the lock which is taken by different IRQ descriptors from different IRQ chips that are organized in a way of a hierarchy: ====================================================== WARNING: possible circular locking dependency detected 6.12.0-rc5-next-20241101-00148-g9fabf8160b53 #562 Tainted: G W ------------------------------------------------------ modprobe/141 is trying to acquire lock: ffff899446947868 (intel_soc_pmic_bxtwc:502:(&bxtwc_regmap_config)->lock){+.+.}-{4:4}, at: regmap_update_bits_base+0x33/0x90 but task is already holding lock: ffff899446947c68 (&d->lock){+.+.}-{4:4}, at: __setup_irq+0x682/0x790 which lock already depends on the new lock. -> #3 (&d->lock){+.+.}-{4:4}: -> #2 (&desc->request_mutex){+.+.}-{4:4}: -> #1 (ipclock){+.+.}-{4:4}: -> #0 (intel_soc_pmic_bxtwc:502:(&bxtwc_regmap_config)->lock){+.+.}-{4:4}: Chain exists of: intel_soc_pmic_bxtwc:502:(&bxtwc_regmap_config)->lock --> &desc->request_mutex --> &d->lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&d->lock); lock(&desc->request_mutex); lock(&d->lock); lock(intel_soc_pmic_bxtwc:502:(&bxtwc_regmap_config)->lock); *** DEADLOCK *** 3 locks held by modprobe/141: #0: ffff8994419368f8 (&dev->mutex){....}-{4:4}, at: __driver_attach+0xf6/0x250 #1: ffff89944690b250 (&desc->request_mutex){+.+.}-{4:4}, at: __setup_irq+0x1a2/0x790 #2: ffff899446947c68 (&d->lock){+.+.}-{4:4}, at: __setup_irq+0x682/0x790 Set a lockdep class when we map the IRQ so that it doesn't warn about a lockdep bug that doesn't exist. Fixes: 4af8be67 ("regmap: Convert regmap_irq to use irq_domain") Signed-off-by:
-
Zhang Zekun authored
[ Upstream commit afc2331e ] of_parse_phandle_with_args() needs to call of_node_put() to decrement the refcount of args.np. So, Add the missing of_node_put() in the loop. Fixes: efa5c01c ("soc: ti: ti_sci_pm_domains: switch to use multiple genpds instead of one") Signed-off-by:
Zhang Zekun <zhangzekun11@huawei.com> Reviewed-by:
Dhruva Gole <d-gole@ti.com> Message-ID: <20241024030442.119506-2-zhangzekun11@huawei.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Andre Przywara authored
[ Upstream commit dd36ad71 ] The DCDC5 voltage rail in the X-Powers AXP809 PMIC has a resolution of 50mV, so the currently enforced limits of 1.475 and 1.525 volts cannot be set, when the existing regulator value is beyond this range. This will lead to the whole regulator driver to give up and fail probing, which in turn will hang the system, as essential devices depend on the PMIC. In this case a bug in U-Boot set the voltage to 1.75V (meant for DCDC4), and the AXP driver's attempt to correct this lead to this error: ================== [ 4.447653] axp20x-rsb sunxi-rsb-3a3: AXP20X driver loaded [ 4.450066] vcc-dram: Bringing 1750000uV into 1575000-1575000uV [ 4.460272] vcc-dram: failed to apply 1575000-1575000uV constraint: -EINVAL [ 4.474788] axp20x-regulator axp20x-regulator.0: Failed to register dcdc5 [ 4.482276] axp20x-regulator axp20x-regulator.0: probe with driver axp20x-regulator failed with error -22 ================== Set the limits to values that can be programmed, so any correction will be successful. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Fixes: 1e1dea72 ("ARM: dts: sun9i: cubieboard4: Add AXP809 PMIC device node and regulators") Link: https://patch.msgid.link/20241007222916.19013-1-andre.przywara@arm.com Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
-
Clark Wang authored
[ Upstream commit a25351e4 ] Implement workaround for ERR051198 (https://www.nxp.com/docs/en/errata/IMX8MN_0N14Y.pdf ) PWM output may not function correctly if the FIFO is empty when a new SAR value is programmed. Description: When the PWM FIFO is empty, a new value programmed to the PWM Sample register (PWM_PWMSAR) will be directly applied even if the current timer period has not expired. If the new SAMPLE value programmed in the PWM_PWMSAR register is less than the previous value, and the PWM counter register (PWM_PWMCNR) that contains the current COUNT value is greater than the new programmed SAMPLE value, the current period will not flip the level. This may result in an output pulse with a duty cycle of 100%. Workaround: Program the current SAMPLE value in the PWM_PWMSAR register before updating the new duty cycle to the SAMPLE value in the PWM_PWMSAR register. This will ensure that the new SAMPLE value is modified during a non-empty FIFO, and can be successfully updated after the period expires. Write the old SAR value before updating the new duty cycle to SAR. This avoids writing the new value into an empty FIFO. This only resolves the issue when the PWM period is longer than 2us (or <500kHz) because write register is not quick enough when PWM period is very short. Reproduce steps: cd /sys/class/pwm/pwmchip1/pwm0 echo 2000000000 > period # It is easy to observe by using long period echo 1000000000 > duty_cycle echo 1 > enable echo 8000 > duty_cycle # One full high pulse will be seen by scope Fixes: 166091b1 ("[ARM] MXC: add pwm driver for i.MX SoCs") Reviewed-by:
Jun Li <jun.li@nxp.com> Signed-off-by:
Clark Wang <xiaoning.wang@nxp.com> Signed-off-by:
Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20241008194123.1943141-1-Frank.Li@nxp.com Signed-off-by:
Uwe Kleine-König <ukleinek@kernel.org> Signed-off-by:
-
Chen Ridong authored
[ Upstream commit 2190df6c ] Only cgroup v2 can be attached by bpf programs, so this patch introduces that cgroup_bpf_inherit and cgroup_bpf_offline can only be called in cgroup v2, and this can fix the memleak mentioned by commit 04f8ef56 ("cgroup: Fix memory leak caused by missing cgroup_bpf_offline"), which has been reverted. Fixes: 2b0d3d3e ("percpu_ref: reduce memory footprint of percpu_ref in fast path") Fixes: 4bfc0bb2 ("bpf: decouple the lifetime of cgroup_bpf from cgroup itself") Link: https://lore.kernel.org/cgroups/aka2hk5jsel5zomucpwlxsej6iwnfw4qu5jkrmjhyfhesjlfdw@46zxhg5bdnr7/ Signed-off-by:
Chen Ridong <chenridong@huawei.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Chen Ridong authored
[ Upstream commit feb301c6 ] This reverts commit 04f8ef56. Only cgroup v2 can be attached by cgroup by BPF programs. Revert this commit and cgroup_bpf_inherit and cgroup_bpf_offline won't be called in cgroup v1. The memory leak issue will be fixed with next patch. Fixes: 04f8ef56 ("cgroup: Fix memory leak caused by missing cgroup_bpf_offline") Link: https://lore.kernel.org/cgroups/aka2hk5jsel5zomucpwlxsej6iwnfw4qu5jkrmjhyfhesjlfdw@46zxhg5bdnr7/ Signed-off-by:
-
