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
-
-
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:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Steffen Klassert <steffen.klassert@secunet.com> Stable-dep-of: 2cf567f4 ("netdevsim: copy addresses for both in and out paths") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
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:
David S. Miller <davem@davemloft.net> Signed-off-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:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-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:
Brian Norris <briannorris@chromium.org> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20240910124314.698896-3-ruanjinjie@huawei.com 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:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240806-omapdrm-misc-fixes-v1-3-15d31aea0831@ideasonboard.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:
-
Chen-Yu Tsai authored
[ Upstream commit f766fae0 ] The Hana device has a second source option trackpad, but it is missing its regulator supply. It only works because the regulator is marked as always-on. Add the regulator supply, but leave out the post-power-on delay. Instead, document the post-power-on delay along with the reason for not adding it in a comment. Fixes: 689b937b ("arm64: dts: mediatek: add mt8173 elm and hana board") Signed-off-by:
Chen-Yu Tsai <wenst@chromium.org> Reviewed-by:
-
Hsin-Te Yuan authored
[ Upstream commit e9c60c34 ] The address of eeprom should be 50. Fixes: cd894e27 ("arm64: dts: mt8183: Add krane-sku176 board") Signed-off-by:
Hsin-Te Yuan <yuanhsinte@chromium.org> Reviewed-by:
Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20240909-eeprom-v1-1-1ed2bc5064f4@chromium.org Signed-off-by:
-
Gregory Price authored
[ Upstream commit e6d654e9 ] A prior bugfix that fixes a signed/unsigned error causes another signed unsigned error. A situation where log_tbl->size is invalid can cause the size passed to memblock_reserve to become negative. log_size from the main event log is an unsigned int, and the code reduces to the following u64 value = (int)unsigned_value; This results in sign extension, and the value sent to memblock_reserve becomes effectively negative. Fixes: be59d57f ("efi/tpm: Fix sanity check of unsigned tbl_size being less than zero") Signed-off-by:
Gregory Price <gourry@gourry.net> Reviewed-by:
Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Signed-off-by:
-
Bartosz Golaszewski authored
[ Upstream commit 328bda09 ] GCC 13 complains about the truncated output of snprintf(): drivers/mmc/host/mmc_spi.c: In function ‘mmc_spi_response_get’: drivers/mmc/host/mmc_spi.c:227:64: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation=] 227 | snprintf(tag, sizeof(tag), " ... CMD%d response SPI_%s", | ^ drivers/mmc/host/mmc_spi.c:227:9: note: ‘snprintf’ output between 26 and 43 bytes into a destination of size 32 227 | snprintf(tag, sizeof(tag), " ... CMD%d response SPI_%s", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 228 | cmd->opcode, maptype(cmd)); Drop it and fold the string it generates into the only place where it's emitted - the dev_dbg() call at the end of the function. Fixes: 15a0580c ("mmc_spi host driver") Suggested-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20241008160134.69934-1-brgl@bgdev.pl Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit 78261cb0 ] This loop is supposed to break if the frequency returned from clk_round_rate() is the same as on the previous iteration. However, that check doesn't make sense on the first iteration through the loop. It leads to reading before the start of these->clk_perf_tbl[] array. Fixes: eddac5af ("soc: qcom: Add GENI based QUP Wrapper driver") Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Signed-off-by:
-
Jinjie Ruan authored
[ Upstream commit 16a0a692 ] If request_irq() fails in sr_late_init(), there is no need to enable the irq, and if it succeeds, 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: 1279ba59 ("OMAP3+: SR: disable interrupt by default") Signed-off-by:
Kevin Hilman <khilman@baylibre.com> Signed-off-by:
-
Jinjie Ruan authored
[ Upstream commit 003c7e01 ] 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: 9728fb3c ("spi: lpspi: disable lpspi module irq in DMA mode") Signed-off-by:
-
Alexander Stein authored
[ Upstream commit d5786c88 ] Having no DMA is not an error. The simplest reason is not having it configured. SPI will still be usable, so raise a warning instead to get still some attention. Signed-off-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Link: https://lore.kernel.org/r/20230531072850.739021-1-alexander.stein@ew.tq-group.com Signed-off-by:
-
Mark Brown authored
[ Upstream commit 0309f714 ] The sp804 is currently only user selectable if COMPILE_TEST, this was done by commit dfc82faa ("clocksource/drivers/sp804: Add COMPILE_TEST to CONFIG_ARM_TIMER_SP804") in order to avoid it being spuriously offered on platforms that won't have the hardware since it's generally only seen on Arm based platforms. This config is overly restrictive, while platforms that rely on the SP804 do select it in their Kconfig there are others such as the Arm fast models which have a SP804 available but currently unused by Linux. Relax the dependency to allow it to be user selectable on arm and arm64 to avoid surprises and in case someone comes up with a use for extra timer hardware. Fixes: dfc82faa ("clocksource/drivers/sp804: Add COMPILE_TEST to CONFIG_ARM_TIMER_SP804") Reported-by:
Ross Burton <ross.burton@arm.com> Reviewed-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 2f4574dd ] This option is now synonymous with CONFIG_HAVE_CLK, so use the latter globally. Any out-of-tree platform ports that still use a private clk_get()/clk_put() implementation should move to CONFIG_COMMON_CLK. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Stable-dep-of: 0309f714 ("clocksource/drivers:sp804: Make user selectable") Signed-off-by:
-
