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: 753fb2ee0934 ("bpf: sockmap, add msg_peek tests to test_sockmap") Fixes: 16edddfe3c5d ("selftests/bpf: test_sockmap, check test failure") Acked-by: John Fastabend <john.fastabend@gmail.com> Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com> Link: https://lore.kernel.org/r/20241012203731.1248619-2-zijianzhang@bytedance.com Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
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.
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:
Libbpf pre-1.0 had a legacy logic of allowing singular non-annotated
(i.e., not having explicit SEC() annotation) function to be treated as
sole entry BPF program (unless there were other explicit entry
programs).
This behavior was dropped during libbpf 1.0 transition period (unless
LIBBPF_STRICT_SEC_NAME flag was unset in libbpf_mode). When 1.0 was
released and all the legacy behavior was removed, the bug slipped
through leaving this legacy behavior around.
Fix this for good, as it actually causes very confusing behavior if BPF
object file only has subprograms, but no entry programs.
As the same condition was checked in inner and outer if statements.
The code never reaches the inner else statement.
Fix this by removing the logically dead inner else statement.
Refactor IPC send and receive functions to allow correct
handling of operations that should not trigger a recovery process.
Expose ivpu_send_receive_internal(), which is now utilized by the D0i3
entry, DCT initialization, and HWS initialization functions.
These functions have been modified to return error codes gracefully,
rather than initiating recovery.
The updated functions are invoked within ivpu_probe() and ivpu_resume(),
ensuring that any errors encountered during these stages result in a proper
teardown or shutdown sequence. The previous approach of triggering recovery
within these functions could lead to a race condition, potentially causing
undefined behavior and kernel crashes due to null pointer dereferences.
Fixes: 45e45362e095 ("accel/ivpu: Introduce ivpu_ipc_send_receive_active()") Signed-off-by: Karol Wachowski <karol.wachowski@intel.com> Reviewed-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240930195322.461209-23-jacek.lawrynowicz@linux.intel.com Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
sym_is_subprog() is incorrectly rejecting relocations against *weak*
global subprogs. Fix that by realizing that STB_WEAK is also a global
function.
While it seems like verifier doesn't support taking an address of
non-static subprog right now, it's still best to fix support for it on
libbpf side, otherwise users will get a very confusing error during BPF
skeleton generation or static linking due to misinterpreted relocation:
libbpf: prog 'handle_tp': bad map relo against 'foo' in section '.text'
Error: failed to open BPF object file: Relocation failed
It's clearly not a map relocation, but is treated and reported as such
without this fix.
Commit 24c5ed3ddf27 ("drm/vc4: Introduce generation number enum")
incorrectly swapped a check of hvs->vc4->is_vc5 to
hvs->vc4->gen == VC4_GEN_4 in vc4_hvs_lut_load, hence breaking
loading the gamma look up table on Pi0-3.
Correct that conditional.
Fixes: 24c5ed3ddf27 ("drm/vc4: Introduce generation number enum") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Closes: https://lore.kernel.org/dri-devel/37051126-3921-4afe-a936-5f828bff5752@samsung.com/ Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241008-drm-vc4-fixes-v1-3-9d0396ca9f42@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
Commit 52efe364d196 ("drm/vc4: hvs: Don't write gamma luts on 2711")
added a return path to vc4_hvs_lut_load that had called
drm_dev_enter, but not drm_dev_exit.
Ensure we call drm_dev_exit.
Fixes: 52efe364d196 ("drm/vc4: hvs: Don't write gamma luts on 2711") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Closes: https://lore.kernel.org/dri-devel/37051126-3921-4afe-a936-5f828bff5752@samsung.com/ Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241008-drm-vc4-fixes-v1-1-9d0396ca9f42@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
With the introduction of the BCM2712 support, we will get yet another
generation of display engine to support.
The binary check of whether it's VC5 or not thus doesn't work anymore,
especially since some parts of the driver will have changed with BCM2711,
and some others with BCM2712.
Let's introduce an enum to store the generation the driver is running
on, which should provide more flexibility.
The ice_vc_cfg_qs_msg() function is used to configure VF queues in response
to a VIRTCHNL_OP_CONFIG_VSI_QUEUES command.
The virtchnl command contains an array of queue pair data for configuring
Tx and Rx queues. This data includes a queue ID. When configuring the
queues, the driver generally uses this queue ID to determine which Tx and
Rx ring to program. However, a handful of places use the index into the
queue pair data from the VF. While most VF implementations appear to send
this data in order, it is not mandated by the virtchnl and it is not
verified that the queue pair data comes in order.
Fix the driver to consistently use the q_idx field instead of the 'i'
iterator value when accessing the rings. For the Rx case, introduce a local
ring variable to keep lines short.
Currently, wiphy_verify_combinations() fails for the multi-radio per wiphy
due to the condition check on new global interface combination that DFS
only works on one channel. In a multi-radio scenario, new global interface
combination encompasses the capabilities of all radio combinations, so it
supports more than one channel with DFS. For multi-radio per wiphy,
interface combination verification needs to be performed for radio specific
interface combinations. This is necessary as the new global interface
combination combines the capabilities of all radio combinations.
Fixes: a01b1e9f9955 ("wifi: mac80211: add support for DFS with multiple radios") Signed-off-by: Karthikeyan Periyasamy <quic_periyasa@quicinc.com> Link: https://patch.msgid.link/20240917140239.886083-1-quic_periyasa@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
Including the network_helpers.h header in tests can lead to the following
build error:
./network_helpers.h: In function ‘csum_tcpudp_magic’:
./network_helpers.h:116:14: error: implicit declaration of function \
‘htons’ [-Werror=implicit-function-declaration]
116 | s += htons(proto + len);
The error is avoided in many cases thanks to some other headers included
earlier and bringing in arpa/inet.h (ie: test_progs.h).
Make sure that test_progs build success does not depend on header ordering
by adding the missing header include in network_helpers.h
Currently, mem_ce and mem iomem addresses are used to calculate the
CE offset address. mem_ce is initialized with mem address, and for
targets where ce_remap is needed, mem_ce is remapped to a new address
space during AHB probe.
For targets such as WCN6750 in which CE address space is same as WCSS
address space (i.e. "ce_remap" hw_param is set to false), mem_ce and
mem iomem addresses are same. In the initial SRNG setup for such targets,
the CE offset address and hence CE register base addresses are
calculated correctly in ath11k_hal_srng_init() as both mem and mem_ce
are initialized with same iomem address.
Later, after the firmware download, mem is initialized with BAR address
received in qmi_wlanfw_device_info_resp_msg_v01 QMI message, while mem_ce
is not updated.
After initial setup success, during Subsystem Restart (SSR), as part
of reinitialization, ath11k_hal_srng_init() will be called again,
and CE offset address will be calculated incorrectly this time as mem_ce
address was not updated. Due to the incorrect CE offset address,
APPS accesses an invalid CE register address which leads to improper
behavior in firmware after SSR is triggered.
To fix the above issue, update mem_ce to mem iomem address in
ath11k_qmi_request_device_info() for targets which do not support
ce_remap feature.
Signed-off-by: Balaji Pothunoori <quic_bpothuno@quicinc.com> Fixes: b42b3678c91f ("wifi: ath11k: remap ce register space for IPQ5018") Link: https://patch.msgid.link/20240927095825.22317-1-quic_bpothuno@quicinc.com Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
test_progs uses glibc specific functions backtrace() and
backtrace_symbols_fd() to print backtrace in case of SIGSEGV.
Recent commit (see fixes) updated test_progs.c to define stub versions
of the same functions with attriubte "weak" in order to allow linking
test_progs against musl libc. Unfortunately this broke the backtrace
handling for glibc builds.
As it turns out, glibc defines backtrace() and backtrace_symbols_fd()
as weak:
netns_new()/netns_free() create/delete network namespaces. They support the
option '-m' of test_progs to start/stop traffic monitor for the network
namespace being created for matched tests.
Acked-by: Stanislav Fomichev <sdf@fomichev.me> Signed-off-by: Kui-Feng Lee <thinker.li@gmail.com> Link: https://lore.kernel.org/r/20240815053254.470944-4-thinker.li@gmail.com Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
Stable-dep-of: 5bf1557e3d6a ("selftests/bpf: Fix backtrace printing for selftests crashes") Signed-off-by: Sasha Levin <sashal@kernel.org>
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.
A previous patch addressed a fortified-memcpy warning on older compilers,
but there is still a warning on gcc-14 in some configurations:
In file included from include/linux/string.h:390,
from drivers/net/wireless/ath/ath12k/wow.c:7:
drivers/net/wireless/ath/ath12k/wow.c: In function 'ath12k_wow_convert_8023_to_80211.isra':
include/linux/fortify-string.h:114:33: error: '__builtin_memcpy' accessing 18446744073709551610 or more bytes at offsets 0 and 0 overlaps 9223372036854775797 bytes at offset -9223372036854775803 [-Werror=restrict]
include/linux/fortify-string.h:679:26: note: in expansion of macro '__fortify_memcpy_chk'
679 | #define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \
| ^~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/ath/ath12k/wow.c:199:25: note: in expansion of macro 'memcpy'
199 | memcpy(pat + a3_ofs - pkt_ofs,
| ^~~~~~
Address this the same way as the other two, using size_add().
Fixes: b49991d83bba ("wifi: ath12k: fix build vs old compiler") Fixes: 4a3c212eee0e ("wifi: ath12k: add basic WoW functionalities") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241004095420.637091-1-arnd@kernel.org Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
During ath12k module removal, in ath12k_core_deinit(),
ath12k_mac_destroy() un-registers ah->hw from mac80211 and frees
the ah->hw as well as all the ar's in it. After this
ath12k_core_soc_destroy()-> ath12k_dp_free()-> ath12k_dp_cc_cleanup()
tries to access one of the freed ar's from pending skb.
This is because during mac destroy, driver failed to flush few
data packets, which were accessed later in ath12k_dp_cc_cleanup()
and freed, but using ar from the packet led to this use-after-free.
BUG: KASAN: use-after-free in ath12k_dp_cc_cleanup.part.0+0x5e2/0xd40 [ath12k]
Write of size 4 at addr ffff888150bd3514 by task modprobe/8926
CPU: 0 UID: 0 PID: 8926 Comm: modprobe Not tainted
6.11.0-rc2-wt-ath+ #1746
Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS
HNKBLi70.86A.0067.2021.0528.1339 05/28/2021
Commit 24de1b7b231c ("wifi: ath12k: fix flush failure in recovery
scenarios") added the change to decrement the pending packets count
in case of recovery which make sense as ah->hw as well all
ar's in it are intact during recovery, but during core deinit there
is no use in decrementing packets count or waking up the empty waitq
as the module is going to be removed also ar's from pending skb's
can't be used and the packets should just be released back.
To fix this, avoid accessing ar from skb->cb when driver is being
unregistered.
This is caused by lost memory during early init phase. First time driver
is removed, memory is freed but when second time the driver is inserted,
VBIOS dmub is not active, since the PSP policy is to retain the driver
loaded version on subsequent warm boots. Hence, communication with VBIOS
DMUB fails.
Fix this by aborting further communication with vbios dmub and release
the memory immediately.
Fixes: f59549c7e705 ("drm/amd/display: free bo used for dmub bounding box") Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
In STA+AP concurrent mode, performing a scan operation on one vif
temporarily stops beacons on the other. When the scan is completed,
beacons are enabled again with BSS_CHANGED_BEACON_ENABLED.
We can observe that no beacons are being sent when just
rtl8xxxu_start_tx_beacon() is being called.
Thus, also perform update_beacon_work in order to restore beaconing.
The arguments got swapped by commit 986ae3c2a8df ("dlm: fix race between
final callback and remove") fixing this now.
Fixes: 986ae3c2a8df ("dlm: fix race between final callback and remove") Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
Object linking output data uses the default ELF_T_BYTE type for '.symtab'
section data, which disables any libelf-based translation. Explicitly set
the ELF_T_SYM type for output to restore libelf's byte-order conversion,
noting that input '.symtab' data is already correctly translated.
Referenced commit broke the logic of resetting expected_attach_type to
zero for allowed program types if kernel doesn't yet support such field.
We do need to overwrite and preserve expected_attach_type for
multi-uprobe though, but that can be done explicitly in
libbpf_prepare_prog_load().
Fixes: 5902da6d8a52 ("libbpf: Add uprobe multi link support to bpf_program__attach_usdt") Suggested-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Tao Chen <chen.dylane@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20240925153012.212866-1-chen.dylane@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
The bridge might miss the display change events when it's powered off.
This happens when a user changes the external monitor when the system
is suspended and the embedded controller doesn't not wake AP up.
It's also observed that one DP-to-HDMI bridge doesn't work correctly
when there is no EDID read after it is powered on.
Drop the cache to force an EDID read after system resume to fix this.
Fixes: 11feaef69d0c ("drm/bridge: it6505: Add caching for EDID") Signed-off-by: Pin-yen Lin <treapking@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240926092931.3870342-3-treapking@chromium.org Signed-off-by: Sasha Levin <sashal@kernel.org>
The bridge might miss the display change events when it's powered off.
This happens when a user changes the external monitor when the system
is suspended and the embedded controller doesn't not wake AP up.
It's also observed that one DP-to-HDMI bridge doesn't work correctly
when there is no EDID read after it is powered on.
Drop the cache to force an EDID read after system resume to fix this.
Fixes: 8bdfc5dae4e3 ("drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP") Signed-off-by: Pin-yen Lin <treapking@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240926092931.3870342-2-treapking@chromium.org Signed-off-by: Sasha Levin <sashal@kernel.org>
The DT bindings deprecated the "hp-det-gpio" and "mic-det-gpio"
properties in favor of "hp-det-gpios" and "mic-det-gpios", but the
driver was never updated to support the latter.
Even before, there existed users of "hp-det-gpios" and "mic-det-gpios".
While this may have been handled fine by the ASoC core, this was missed
by the Freescale-specific part.
Fixes: 4189b54220e5af15 ("ASoC: dt-bindings: fsl-asoc-card: convert to YAML") Fixes: 40ba2eda0a7b727f ("arm64: dts: imx8mm-nitrogen-r2: add audio") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://patch.msgid.link/dbcb5bfea005a468ec6dc38374fe6d02bc693c22.1727438777.git.geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
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.
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.
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.
EXTERNAL_REG_INTERNAL_OFFSET/EXTERNAL_REG_WRITE_ADDR should be used in
pairs. If an external register shouldn't be written, both packets
shouldn't be sent.
Fixes: a78b48146972 ("drm/amdgpu: Skip PCTL0_MMHUB_DEEPSLEEP_IB write in jpegv4.0.3 under SRIOV") Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Acked-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
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.
The commit introducing the Frida display started to write the
SETVCMOFF registers unconditionally, and some (not all!) Hydis
display seem to be affected by ghosting after the commit.
Make SETVCMOFF optional and only send these commands on the
Frida display for now.
Reported-by: Stefan Hansson <newbyte@postmarketos.org> Fixes: 219a1f49094f ("drm/panel: nt35510: support FRIDA FRD400B25025-A-CTK") Acked-by: Jessica Zhang <quic_jesszhan@quicinc.com> Tested-by: Stefan Hansson <newbyte@postmarketos.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240908-fix-nt35510-v2-1-d4834b9cdb9b@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
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: 47b1be5c0f4e ("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: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
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: 9021c317b770 ("drm/imx: Add initial support for DCSS on iMX8MQ") Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-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: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
Because MAX_PAGE_ORDER, kmalloc can max alloc 4096 * (1 << 10), 4MB
memory, each array entry is pointer(8byte), so can save 524288 pages(2GB).
Further more, costly order(order 3) may not be guaranteed that it can be
applied for, due to fragmentation.
This patch change udmabuf array use kvmalloc_array, this can fallback
alloc into vmalloc, which can guarantee allocation for any size and does
not affect the performance of kmalloc allocations.
Signed-off-by: Huan Yang <link@vivo.com> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240918025238.2957823-3-link@vivo.com
Stable-dep-of: 18d7de823b71 ("udmabuf: fix vmap_udmabuf error page set") Signed-off-by: Sasha Levin <sashal@kernel.org>
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: 853402a00823 ("mwifiex: Enable WoWLAN for both sdio and pcie") Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Acked-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: Sasha Levin <sashal@kernel.org>
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.
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: 3cbd0c587b12 ("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: Sasha Levin <sashal@kernel.org>
drivers/gpu/drm/omapdrm/dss/base.c:176 omapdss_device_disconnect() error: we previously assumed 'src' could be null (see line 169)
This code is mostly from a time when omapdrm had its own display device
model. I can't honestly remember the details, and I don't think it's
worth digging in deeply into that for a legacy driver.
However, it looks like we only call omapdss_device_disconnect() and
omapdss_device_connect() with NULL as the src parameter. We can thus
drop the src parameter from both functions, and fix the smatch warning.
I don't think omapdss_device_disconnect() ever gets NULL for the dst
parameter (if it did, we'd crash soon after returning from the
function), but I have kept the !dst check, just in case, but I added a
WARN_ON() there.
Also, if the dst parameter can be NULL, we can't always get the struct
dss_device pointer from dst->dss (which is only used for a debug print).
To make sure we can't hit that issue, do it similarly to the
omapdss_device_connect() function: add 'struct dss_device *dss' as the
first parameter, so that we always have it regardless of the dst.
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: fb9987d0f748 ("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: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20240909103855.68006-1-aha310510@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
When factoring out __vc4_hvs_stop_channel, the logic got inverted from
if (condition)
// stop channel
to
if (condition)
goto out
//stop channel
out:
and also changed the exact register writes used to stop the channel.
Correct the logic so that the channel is actually stopped, and revert
to the original register writes.
The debug function to display the dlists didn't reset next_entry_start
when starting each display, so resulting in not stopping the
list at the correct place.
Trying to read /sys/kernel/debug/dri/1/hdmi1_regs
when the hdmi is disconnected results in a fatal system hang.
This is due to the pm suspend code disabling the dvp clock.
That is just a gate of the 108MHz clock in DVP_HT_RPI_MISC_CONFIG,
which results in accesses hanging AXI bus.
Protect against this.
Fixes: 25eb441d55d4 ("drm/vc4: hdmi: Add all the vc5 HDMI registers into the debugfs dumps") Signed-off-by: Dom Cobley <popcornmix@gmail.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-17-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
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:
I missed this open-coded kref_get() while trying to debug a refcount
bug, so let's use the helper function here to avoid that waste of time
again in the future.
When an error occurs in sysfs show callback, we should return the errno
directly instead of formatting it as the result, which produces
meaningless output and doesn't inform the userspace of the error.
Fixes: 468f96bfa3a0 ("platform/x86: panasonic-laptop: Add support for battery charging threshold (eco mode)") Fixes: d5a81d8e864b ("platform/x86: panasonic-laptop: Add support for optical driver power in Y and W series") Signed-off-by: Yao Zi <ziyao@disroot.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20241118064637.61832-3-ziyao@disroot.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
And the issue seems to be that the corresponding devres group is not
allocated. Normally, devres_open_group() is called from
__hid_device_probe() but Hyper-V HID driver overrides 'hid_dev->driver'
with 'mousevsc_hid_driver' stub and basically re-implements
__hid_device_probe() by calling hid_parse() and hid_hw_start() but not
devres_open_group(). hid_device_probe() does not call __hid_device_probe()
for it. Later, when the driver is removed, hid_device_remove() calls
devres_release_group() as it doesn't check whether hdev->driver was
initially overridden or not.
The issue seems to be related to the commit 62c68e7cee33 ("HID: ensure
timely release of driver-allocated resources") but the commit itself seems
to be correct.
Fix the issue by dropping the 'hid_dev->driver' override and using
hid_register_driver()/hid_unregister_driver() instead. Alternatively, it
would have been possible to rely on the default handling but
HID_CONNECT_DEFAULT implies HID_CONNECT_HIDRAW and it doesn't seem to work
for mousevsc as-is.
Correct the audio name for the Indiedroid Nova from
rockchip,es8388-codec to rockchip,es8388. This name change corrects a
kernel log error of "ASoC: driver name too long 'rockchip,es8388-codec'
-> 'rockchip_es8388'".
Fixes: 3900160e164b ("arm64: dts: rockchip: Add Indiedroid Nova board") Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Link: https://lore.kernel.org/r/20241031150505.967909-2-macroalpha82@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
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: a49d25364dfb ("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: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
Some PWM hardwares (e.g. MC33XS2410) cannot implement a zero duty cycle
but can instead disable the hardware which also results in a constant
inactive output.
There are some checks (enabled with CONFIG_PWM_DEBUG) to help
implementing a driver without violating the normal rounding rules. Make
them less strict to let above described hardware pass without warning.
DMA ops are a helper for architectures and not for drivers to override the
DMA implementation. Driver should not override the DMA implementation.
This patch removes the dma_ops override from auxiliary device and adds
driver-internal helpers that use the actual DMA mapping APIs.
Fixes: 9163d83573e4 ("media: intel/ipu6: add IPU6 DMA mapping API and MMU table") Signed-off-by: Bingbu Cao <bingbu.cao@intel.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
[Sakari Ailus: Fix the commit message a little.] Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Sasha Levin <sashal@kernel.org>
Fix printing DMA and physical address printing on 32-bit platforms, by
using correct types. Also cast DMA_BIT_MASK() result to dma_addr_t to make
Clang happy.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Bingbu Cao <bingbu.cao@intel.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Stable-dep-of: daabc5c64703 ("media: ipu6: not override the dma_ops of device in driver") Signed-off-by: Sasha Levin <sashal@kernel.org>
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).
Fixes: 8cb7cf56c9fe ("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: Sasha Levin <sashal@kernel.org>
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: 1d3f08687d76 ("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: Sasha Levin <sashal@kernel.org>
alloc_buffer() allocates and initializes (with random data) a
buffer of requested size. The initialization starts from the beginning
of the allocated buffer and incrementally assigns sizeof(uint64_t) random
data to each cache line. The initialization uses the size of the
buffer to control the initialization flow, decrementing the amount of
buffer needing to be initialized after each iteration.
The size of the buffer is stored in an unsigned (size_t) variable s64
and the test "s64 > 0" is used to decide if initialization is complete.
The problem is that decrementing the buffer size may wrap around
if the buffer size is not divisible by "CL_SIZE / sizeof(uint64_t)"
resulting in the "s64 > 0" test being true and memory beyond the buffer
"initialized".
Use a signed value for the buffer size to support all buffer sizes.
Fixes: a2561b12fe39 ("selftests/resctrl: Add built in benchmark") 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: Sasha Levin <sashal@kernel.org>
By default the MBM test uses the "fill_buf" benchmark to keep reading
from a buffer with size DEFAULT_SPAN while measuring memory bandwidth.
User space can provide an alternate benchmark or amend the size of
the buffer "fill_buf" should use.
Analysis of the MBM measurements do not require that a buffer be used
and thus do not require knowing the size of the buffer if it was used
during testing. Even so, the buffer size is printed as informational
as part of the MBM test results. What is printed as buffer size is
hardcoded as DEFAULT_SPAN, even if the test relied on another benchmark
(that may or may not use a buffer) or if user space amended the buffer
size.
Ensure that accurate buffer size is printed when using "fill_buf"
benchmark and omit the buffer size information if another benchmark
is used.
When the fixed regulators for the LCD panel and DP bridge were added,
their supplies were not modeled in. These, except for the 1.0V supply,
are just load switches, and need and have a supply.
Add the supplies for each of the fixed regulators.
Some of the regulator supplies for the MIPI-DPI-to-DP bridge and their
associated nodes are incorrectly named. In particular, the 1.0V supply
was modeled as a 1.2V supply.
Fix all the incorrect names, and also fix the voltage of the 1.0V
regulator.
Fix DTBS check errors for 'mt6358codec' and 'mt6358regulator':
Error message is:
pmic: 'mt6358codec' and 'mt6358regulator' does not match any of the
regexes: 'pinctrl-[0-9]+'.
Rename these two device node to generic 'audio-codec' and 'regulators'.
Fixes: 9f8872221674 ("arm64: dts: mt6358: add PMIC MT6358 related nodes") Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com> Link: https://lore.kernel.org/r/20241029064647.13370-1-macpaul.lin@mediatek.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
Add support for the ADC on MT6357/8/9 and keep it default enabled
as this IP is always present on those PMICs.
Users may use different IIO channels depending on board-specific
routing.
Fix the issue where both 'output-low' and 'output-high' exist under GPIO
hog nodes (rst_usb_hub_hog and sel_usb_hub_hog) when applying device
tree overlays. Since /delete-property/ is not supported in the overlays,
setting 'output-low' results in both properties being present. The
workaround is to disable these hogs and create new ones with 'output-low'
as needed.
Fix below CHECK_DTBS warning:
arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl-mba8mx-usbotg.dtb: sel-usb-hub-hog:
{'output-low': True, 'gpio-hog': True, 'gpios': [[1, 0]], 'output-high': True, 'phandle': 108, '$nodename': ['sel-usb-hub-hog']}
is valid under each of {'required': ['output-low']}, {'required': ['output-high']
Fixes: 3f6fc30abebc ("arm64: dts: imx8mn: tqma8mqnl-mba8mx: Add USB DR overlay") Signed-off-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
"#sound-dai-cells" is required if the board is using "simple-card".
However, the HiHope board uses "audio-graph", thus remove the unneeded
`#sound-dai-cells`.
Commit 9e72606cd2db ("arm64: dts: renesas: #sound-dai-cells is used when
simple-card") updated the comment regarding usage of "#sound-dai-cells"
in the SoC DTSI but missed to remove "#sound-dai-cells" from board DTS
files.
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
A shift-out-of-bounds issue was identified by UBSAN in the
tegra_qspi_fill_tx_fifo_from_client_txbuf() function.
UBSAN: shift-out-of-bounds in drivers/spi/spi-tegra210-quad.c:345:27
shift exponent 32 is too large for 32-bit type 'u32' (aka 'unsigned int')
Call trace:
tegra_qspi_start_cpu_based_transfer
The problem arises when shifting the contents of tx_buf left by 8 times
the value of i, which can exceed 4 and result in an exponent larger than
32 bits.
Resolve this by restrict the value of i to be less than 4, preventing
the shift operation from overflowing.
Signed-off-by: Breno Leitao <leitao@debian.org> Fixes: 921fc1838fb0 ("spi: tegra210-quad: Add support for Tegra210 QSPI controller") Link: https://patch.msgid.link/20241004125400.1791089-1-leitao@debian.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
__pa() is only intended to be used for linear map addresses and using
it for initial_boot_params which is in fixmap for arm64 will give an
incorrect value. Hence save the physical address when it is known at
boot time when calling early_init_dt_scan for arm64 and use it at kexec
time instead of converting the virtual address using __pa().
Note that arm64 doesn't need the FDT region reserved in the DT as the
kernel explicitly reserves the passed in FDT. Therefore, only a debug
warning is fixed with this change.
Reported-by: Breno Leitao <leitao@debian.org> Suggested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Usama Arif <usamaarif642@gmail.com> Fixes: ac10be5cdbfa ("arm64: Use common of_kexec_alloc_and_setup_fdt()") Link: https://lore.kernel.org/r/20241023171426.452688-1-usamaarif642@gmail.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
Both drivers use I/O port accesses without declaring a dependency on
CONFIG_HAS_IOPORT. For sbc8360_wdt this causes a compile error on UML
once inb()/outb() helpers become conditional.
For sbc7240_wdt this causes no such errors with UML because this driver
depends on both x86_32 and !UML. Nevertheless add HAS_IOPORT as
a dependency for both drivers to be explicit and drop the !UML
dependency for sbc7240_wdt as it is now redundant since UML implies no
HAS_IOPORT.
The clock IDs for multiple MCSPI instances across wakeup domain
in J721s2 are incorrect when compared with documentation [1]. Fix the
clock IDs to their appropriate values.
The clock IDs for multiple MCSPI instances across wakeup domain
in J721e are incorrect when compared with documentation [1]. Fix
the clock ids to their appropriate values.
The clock IDs for multiple MCSPI instances across wakeup as
well as main domain in J7200 are incorrect when compared with
documentation [1]. This results in kernel crashes when the said
instances are enabled. Fix the clock ids to their appropriate
values.
Commit 0d0a0b441346 ("arm64: dts: ti: k3-j7200: fix main pinmux
range") split the main_pmx0 into two nodes: main_pmx0 and main_pmx1
due to a non-addressable region, but incorrectly represented the
ranges. As a result, the memory map for the pinctrl is incorrect. Fix
this by introducing the correct ranges.
The ranges are taken from the J7200 TRM [1] (Table 5-695. CTRL_MMR0
Registers).
Padconfig starting addresses and ranges:
- 0 to 66: 0x11c000, 0x10c
- 68: 0x11c110, 0x004
- 71 to 73: 0x11c11c, 0x00c
- 89 to 90: 0x11c164, 0x008
The datasheet [2] doesn't contain PADCONFIG63 (Table 6-106. Pin
Multiplexing), but the pin is necessary for enabling the MMC1 CLKLP
pad loopback and should be included in the pinmux register map.
Due to the change in pinmux node addresses, change the pinmux node for
the USB0_DRVVBUS pin to main_pmx2. The offset has not changed since the
new main_pmx2 node has the same base address and range as the original
main_pmx1 node. All other pinmuxing done within J7200 dts or dtso files
only uses main_pmx0 which has not changed.
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.
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: 166091b1894d ("[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: Sasha Levin <sashal@kernel.org>
The 'enable-active-low' property is not a valid, because it is the
default behaviour of the fixed regulator.
Only 'enable-active-high' is valid, and when this property is absent
the fixed regulator will act as active low by default.
Both the rk3588-orange-pi-5 and the Wolfvision pf5 io expander overlay
smuggled those enable-active-low properties in, so remove them to
make dtbscheck happier.
This driver uses various OF-specific functions and depends on phandle
parsing. There's no reason to make it available to non-OF systems so add
a relevant dependency switch to its Kconfig entry.
Fixes: 2f1630f437df ("power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets") Link: https://lore.kernel.org/r/20241004130449.51725-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
The rk808-regulator driver supports multiple PMIC variants from the Rockckip
RK80x and RK81x series, but the DVS GPIOs are supported on the RK808 variant
only, according to the DT bindings [1][2][3][4][5][6] and the datasheets for
the supported PMIC variants. [7][8][9][10][11][12]
Thus, change the probe path so the "dvs-gpios" property is checked for and
its value possibly used only when the handled PMIC variant is RK808. There's
no point in doing that on the other PMIC variants, because they don't support
the DVS GPIOs, and it goes against the DT bindings to allow a possible out-
of-place "dvs-gpios" property to actually be handled in the driver.
This eliminates the following messages, emitted when the "dvs-gpios" property
isn't found in the DT, from the kernel log on boards that actually don't use
the RK808 variant, which may have provided a source of confusion:
rk808-regulator rk808-regulator.2.auto: there is no dvs0 gpio
rk808-regulator rk808-regulator.2.auto: there is no dvs1 gpio
Furthermore, demote these kernel messages to debug messages, because they are
useful during the board bringup phase only. Emitting them afterwards, on the
boards that use the RK808 variant, but actually don't use the DVS0/1 GPIOs,
clutters the kernel log a bit, while they provide no value and may actually
cause false impression that some PMIC-related issues are present.
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 04f8ef5643bc
("cgroup: Fix memory leak caused by missing cgroup_bpf_offline"), which
has been reverted.
Fixes: 2b0d3d3e4fcf ("percpu_ref: reduce memory footprint of percpu_ref in fast path") Fixes: 4bfc0bb2c60e ("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: Sasha Levin <sashal@kernel.org>
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.
The RT5682i and RT5682s drivers describe two DAIs: AIF1 supports both
playback and capture, while AIF2 supports capture only.
Cherry doesn't specify which DAI to use. Although this doesn't cause
real issues because AIF1 happens to be the first DAI, it should be
corrected:
codec@1a: #sound-dai-cells: 1 was expected
Update #sound-dai-cells to 1 and adjust DAI link usages accordingly.
Fixes: 87728e3ccf35 ("arm64: dts: mediatek: mt8195-cherry: Specify sound DAI links and routing") Signed-off-by: Fei Shao <fshao@chromium.org> Link: https://lore.kernel.org/r/20241021114318.1358681-1-fshao@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
The T-PHY controller at 0x11e40000 controls two underlying USB2 and USB3
PHY ports. The USB3 port works normally just like the others, so there's
no point in disabling it separately. Otherwise, board DTs would have to
enable both the T-PHY controller and one of its sub-nodes in particular,
which is slightly redundant and confusing.
Remove the status line in the u3port1 node, so it's ready to be used
once the T-PHY controller is enabled.
Fixes: 9461e0caac9e ("arm64: dts: Add MediaTek MT8188 dts and evaluation board and Makefile") Signed-off-by: Fei Shao <fshao@chromium.org> Link: https://lore.kernel.org/r/20241021081311.543625-1-fshao@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
projects / thirdparty / kernel / stable.git / log
