May 2024 - Linux-stable-mirror

by Namhyung Kim

Hello, On Fri, Feb 2, 2024 at 3:29 PM Namhyung Kim <namhyung(a)gmail.com> wrote: > > Hello, > > Please queue up these commits for 6.1-stable: > > * commit: 4fb54994b2360ab5029ee3a959161f6fe6bbb349 > ("perf unwind-libunwind: Fix base address for .eh_frame") > > * commit: c966d23a351a33f8a977fd7efbb6f467132f7383 > ("perf unwind-libdw: Handle JIT-generated DSOs properly") > > They are needed to support JIT code in the perf tools. > I think there will be some conflicts, I will send backports soon. Have you received my backport patches? I'm wondering if they're missing or have other problems. Thanks, Namhyung

1 year, 2 months

2
3
0 0

[PATCH AUTOSEL 6.8 01/52] ASoC: Intel: bytcr_rt5640: Apply Asus T100TA quirk to Asus T100TAM too

by Sasha Levin

From: Hans de Goede <hdegoede(a)redhat.com> [ Upstream commit e50729d742ec364895f1c389c32315984a987aa5 ] The Asus T100TA quirk has been using an exact match on a product-name of "T100TA" but there are also T100TAM variants with a slightly higher clocked CPU and a metal backside which need the same quirk. Sort the existing T100TA (stereo speakers) below the more specific T100TAF (mono speaker) quirk and switch from exact matching to substring matching so that the T100TA quirk will also match on the T100TAM models. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Link: https://msgid.link/r/20240407191559.21596-1-hdegoede@redhat.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/intel/boards/bytcr_rt5640.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/sound/soc/intel/boards/bytcr_rt5640.c b/sound/soc/intel/boards/bytcr_rt5640.c index 05f38d1f7d824..b41a1147f1c34 100644 --- a/sound/soc/intel/boards/bytcr_rt5640.c +++ b/sound/soc/intel/boards/bytcr_rt5640.c @@ -636,28 +636,30 @@ static const struct dmi_system_id byt_rt5640_quirk_table[] = { BYT_RT5640_USE_AMCR0F28), }, { + /* Asus T100TAF, unlike other T100TA* models this one has a mono speaker */ .matches = { DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), - DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100TA"), + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100TAF"), }, .driver_data = (void *)(BYT_RT5640_IN1_MAP | BYT_RT5640_JD_SRC_JD2_IN4N | BYT_RT5640_OVCD_TH_2000UA | BYT_RT5640_OVCD_SF_0P75 | + BYT_RT5640_MONO_SPEAKER | + BYT_RT5640_DIFF_MIC | + BYT_RT5640_SSP0_AIF2 | BYT_RT5640_MCLK_EN), }, { + /* Asus T100TA and T100TAM, must come after T100TAF (mono spk) match */ .matches = { - DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), - DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100TAF"), + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), + DMI_MATCH(DMI_PRODUCT_NAME, "T100TA"), }, .driver_data = (void *)(BYT_RT5640_IN1_MAP | BYT_RT5640_JD_SRC_JD2_IN4N | BYT_RT5640_OVCD_TH_2000UA | BYT_RT5640_OVCD_SF_0P75 | - BYT_RT5640_MONO_SPEAKER | - BYT_RT5640_DIFF_MIC | - BYT_RT5640_SSP0_AIF2 | BYT_RT5640_MCLK_EN), }, { -- 2.43.0

1 year, 2 months

3
54
0 0

filtering stable patches in lore queries

by Jason A. Donenfeld

Hi, Greg and Sasha add the "X-stable: review" to their patch bombs, with the intention that people will be able to filter these out should they desire to do so. For example, I usually want all threads that match code I care about, but I don't regularly want to see thousand-patch stable series. So this header is helpful. However, I'm not able to formulate a query for lore (to pass to `lei q`) that will match on negating it. The idea would be to exclude the thread if the parent has this header. It looks like public inbox might only index on some headers, but can't generically search all? I'm not sure how it works, but queries only seem to half way work when searching for that header. In the meantime, I've been using this ugly bash script, which gets the job done, but means I have to download everything locally first: #!/bin/bash PWD="${BASH_SOURCE[0]}" PWD="${PWD%/*}" set -e cd "$PWD" echo "[+] Syncing new mail" >&2 lei up "$PWD" echo "[+] Cleaning up stable patch bombs" >&2 mapfile -d $'\0' -t parents < <(grep -F -x -Z -r -l 'X-stable: review' cur tmp new) { [[ -f stable-message-ids ]] && cat stable-message-ids [[ ${#parents[@]} -gt 0 ]] && sed -n 's/^Message-ID: <$.*$>$/\1/p' "${parents[@]}" } | sort -u > stable-message-ids.new mv stable-message-ids.new stable-message-ids [[ -s stable-message-ids ]] || exit 0 mapfile -d $'\0' -t children < <(grep -F -Z -r -l -f - cur tmp new < stable-message-ids) total=$(( ${#parents[@]} + ${#children[@]} )) [[ $total -gt 0 ]] || exit 0 echo "# rm <...$total messages...>" >&2 rm -f "${parents[@]}" "${children[@]}" This results in something like: zx2c4@thinkpad ~/Projects/lkml $ ./update.bash [+] Syncing new mail # https://lore.kernel.org/all/ limiting ... # /usr/bin/curl -gSf -s -d '' https://lore.kernel.org/all/?x=m&t=1&q=(... [+] Cleaning up stable patch bombs # rm <...24593 messages...> It works, but it'd be nice to not even download these messages in the first place. Since I'm deleting message I don't want, I have to keep track of the message IDs of those deleted messages with the stable header in case replies come in later. That's some book keeping, sheesh! Any thoughts on this workflow? Jason

1 year, 2 months

3
5
0 0

[bisected]: Games crash with 6.9rc-5+/6.8.9+/6.6.30+

by Christian Heusel

Hello, I am reporting this to the regressions mailing list since it has popped up in the [Arch Linux Bugtracker][0]. It was also [already reported][1] to the relevant DRM subsystem, but is not tracked here yet. The issue has been bisected to the following commit by someone on Gitlab: a6ff969fe9cb ("drm/amdgpu: fix visible VRAM handling during faults") The DRM maintainers have said that this could be something that just worked by chance in the past: [Comment 1][2] > Christian König (@ckoenig) > Mhm, no idea of hand. But it could be that this is actually an > intended result. > > Previously we didn't correctly checked if the requirements of an > application regarding CPU accessible VRAM were meet. Now we return an > error if things potentially won't work instead of crashing later on. > > Can you provide the output of 'sudo cat > /sys/kernel/debug/dri/0/amdgpu_vram_mm' just before running the game? [Comment 2][3] > Damian Marcin Szymański (@AngryPenguinPL): > @superm1 @ckoenig If you can't fix it before stable 6.9 can we get it > reverted for now? > > Christian König (@ckoenig): > @AngryPenguinPL no, this is an important bug fix which even needs to > be backported to older kernels. All in all this seems to be a rather tricky situation (especially judging if this is actually a regression or not), so maybe getting some input from the stable or regression team on how to handle this well would be good! (I'll add that I can give no direct input on the issue itself, see this as a forward / cc type of Email.) Cheers, Chris [0]: https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues/47 [1]: https://gitlab.freedesktop.org/drm/amd/-/issues/3343 [2]: https://gitlab.freedesktop.org/drm/amd/-/issues/3343#note_2389471 [3]: https://gitlab.freedesktop.org/drm/amd/-/issues/3343#note_2400933 #regzbot introduced: a6ff969fe9cb #regzbot link: https://gitlab.freedesktop.org/drm/amd/-/issues/3343 #regzbot title: drm/amdgpu: Games crash if above 4g decoding/resize bar is disabled or not supported

1 year, 2 months

3
4
0 0

[PATCH v4 1/2] powerpc64/bpf: fix tail calls for PCREL addressing

by Hari Bathini

With PCREL addressing, there is no kernel TOC. So, it is not setup in prologue when PCREL addressing is used. But the number of instructions to skip on a tail call was not adjusted accordingly. That resulted in not so obvious failures while using tailcalls. 'tailcalls' selftest crashed the system with the below call trace: bpf_test_run+0xe8/0x3cc (unreliable) bpf_prog_test_run_skb+0x348/0x778 __sys_bpf+0xb04/0x2b00 sys_bpf+0x28/0x38 system_call_exception+0x168/0x340 system_call_vectored_common+0x15c/0x2ec Also, as bpf programs are always module addresses and a bpf helper in general is a core kernel text address, using PC relative addressing often fails with "out of range of pcrel address" error. Switch to using kernel base for relative addressing to handle this better. Fixes: 7e3a68be42e1 ("powerpc/64: vmlinux support building with PCREL addresing") Cc: stable(a)vger.kernel.org Signed-off-by: Hari Bathini <hbathini(a)linux.ibm.com> --- * Changes in v4: - Fix out of range errors by switching to kernelbase instead of PC for relative addressing. * Changes in v3: - New patch to fix tailcall issues with PCREL addressing. arch/powerpc/net/bpf_jit_comp64.c | 30 ++++++++++++++++-------------- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/arch/powerpc/net/bpf_jit_comp64.c b/arch/powerpc/net/bpf_jit_comp64.c index 79f23974a320..4de08e35e284 100644 --- a/arch/powerpc/net/bpf_jit_comp64.c +++ b/arch/powerpc/net/bpf_jit_comp64.c @@ -202,7 +202,8 @@ void bpf_jit_build_epilogue(u32 *image, struct codegen_context *ctx) EMIT(PPC_RAW_BLR()); } -static int bpf_jit_emit_func_call_hlp(u32 *image, struct codegen_context *ctx, u64 func) +static int +bpf_jit_emit_func_call_hlp(u32 *image, u32 *fimage, struct codegen_context *ctx, u64 func) { unsigned long func_addr = func ? ppc_function_entry((void *)func) : 0; long reladdr; @@ -211,19 +212,20 @@ static int bpf_jit_emit_func_call_hlp(u32 *image, struct codegen_context *ctx, u return -EINVAL; if (IS_ENABLED(CONFIG_PPC_KERNEL_PCREL)) { - reladdr = func_addr - CTX_NIA(ctx); + reladdr = func_addr - local_paca->kernelbase; if (reladdr >= (long)SZ_8G || reladdr < -(long)SZ_8G) { - pr_err("eBPF: address of %ps out of range of pcrel address.\n", - (void *)func); + pr_err("eBPF: address of %ps out of range of 34-bit relative address.\n", + (void *)func); return -ERANGE; } - /* pla r12,addr */ - EMIT(PPC_PREFIX_MLS | __PPC_PRFX_R(1) | IMM_H18(reladdr)); - EMIT(PPC_INST_PADDI | ___PPC_RT(_R12) | IMM_L(reladdr)); - EMIT(PPC_RAW_MTCTR(_R12)); - EMIT(PPC_RAW_BCTR()); - + EMIT(PPC_RAW_LD(_R12, _R13, offsetof(struct paca_struct, kernelbase))); + /* Align for subsequent prefix instruction */ + if (!IS_ALIGNED((unsigned long)fimage + CTX_NIA(ctx), 8)) + EMIT(PPC_RAW_NOP()); + /* paddi r12,r12,addr */ + EMIT(PPC_PREFIX_MLS | __PPC_PRFX_R(0) | IMM_H18(reladdr)); + EMIT(PPC_INST_PADDI | ___PPC_RT(_R12) | ___PPC_RA(_R12) | IMM_L(reladdr)); } else { reladdr = func_addr - kernel_toc_addr(); if (reladdr > 0x7FFFFFFF || reladdr < -(0x80000000L)) { @@ -233,9 +235,9 @@ static int bpf_jit_emit_func_call_hlp(u32 *image, struct codegen_context *ctx, u EMIT(PPC_RAW_ADDIS(_R12, _R2, PPC_HA(reladdr))); EMIT(PPC_RAW_ADDI(_R12, _R12, PPC_LO(reladdr))); - EMIT(PPC_RAW_MTCTR(_R12)); - EMIT(PPC_RAW_BCTRL()); } + EMIT(PPC_RAW_MTCTR(_R12)); + EMIT(PPC_RAW_BCTRL()); return 0; } @@ -285,7 +287,7 @@ static int bpf_jit_emit_tail_call(u32 *image, struct codegen_context *ctx, u32 o int b2p_index = bpf_to_ppc(BPF_REG_3); int bpf_tailcall_prologue_size = 8; - if (IS_ENABLED(CONFIG_PPC64_ELF_ABI_V2)) + if (!IS_ENABLED(CONFIG_PPC_KERNEL_PCREL) && IS_ENABLED(CONFIG_PPC64_ELF_ABI_V2)) bpf_tailcall_prologue_size += 4; /* skip past the toc load */ /* @@ -993,7 +995,7 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, u32 *fimage, struct code return ret; if (func_addr_fixed) - ret = bpf_jit_emit_func_call_hlp(image, ctx, func_addr); + ret = bpf_jit_emit_func_call_hlp(image, fimage, ctx, func_addr); else ret = bpf_jit_emit_func_call_rel(image, fimage, ctx, func_addr); -- 2.44.0

1 year, 2 months

3
2
0 0

[PATCH AUTOSEL 5.4 1/8] fs/9p: only translate RWX permissions for plain 9P2000

by Sasha Levin

From: Joakim Sindholt <opensource(a)zhasha.com> [ Upstream commit cd25e15e57e68a6b18dc9323047fe9c68b99290b ] Garbage in plain 9P2000's perm bits is allowed through, which causes it to be able to set (among others) the suid bit. This was presumably not the intent since the unix extended bits are handled explicitly and conditionally on .u. Signed-off-by: Joakim Sindholt <opensource(a)zhasha.com> Signed-off-by: Eric Van Hensbergen <ericvh(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- fs/9p/vfs_inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/9p/vfs_inode.c b/fs/9p/vfs_inode.c index b82423a72f685..b1107b424bf64 100644 --- a/fs/9p/vfs_inode.c +++ b/fs/9p/vfs_inode.c @@ -86,7 +86,7 @@ static int p9mode2perm(struct v9fs_session_info *v9ses, int res; int mode = stat->mode; - res = mode & S_IALLUGO; + res = mode & 0777; /* S_IRWXUGO */ if (v9fs_proto_dotu(v9ses)) { if ((mode & P9_DMSETUID) == P9_DMSETUID) res |= S_ISUID; -- 2.43.0

1 year, 2 months

2
9
0 0

Issue with Ubuntu 22.04 Kernel Update

by Mandar Deshpande

Hi, I hope this message finds you well. I'm reaching out regarding an issue I've encountered with my Ubuntu 22.04 installation. Up until kernel version linux-image-5.15.0-84-generic, my laptop has been running smoothly. However, after updating to subsequent kernels, including the latest one, linux-image-5.15.0-106-generic, I've been experiencing a significant problem. Upon completion of the boot process, the screen becomes non-responsive and distorted, rendering the system unusable. I've attached a picture for reference. As of now, I've reverted to using linux-image-5.15.0-84-generic to maintain functionality. I would greatly appreciate any guidance or assistance you can provide in resolving this issue. If you're aware of a solution or troubleshooting steps, please do share them with me. Thank you for your time and assistance. Best regards, Mandar

1 year, 2 months

2
1
0 0

[PATCH 1/2] mtd: rawnand: Fix the nand_read_data_op() early check

by Miquel Raynal

The nand_read_data_op() operation, which only consists in DATA_IN cycles, is sadly not supported by all controllers despite being very basic. The core, for some time, supposed all drivers would support it. An improvement to this situation for supporting more constrained controller added a check to verify if the operation was supported before attempting it by running the function with the check_only boolean set first, and then possibly falling back to another (possibly slightly less optimized) alternative. An even newer addition moved that check very early and probe time, in order to perform the check only once. The content of the operation was not so important, as long as the controller driver would tell whether such operation on the NAND bus would be possible or not. In practice, no buffer was provided (no fake buffer or whatever) as it is anyway not relevant for the "check_only" condition. Unfortunately, early in the function, there is an if statement verifying that the input parameters are right for normal use, making the early check always unsuccessful. Fixes: 9f820fc0651c ("mtd: rawnand: Check the data only read pattern only once") Cc: stable(a)vger.kernel.org Reported-by: Alexander Dahl <ada(a)thorsis.com> Closes: https://lore.kernel.org/linux-mtd/20240306-shaky-bunion-d28b65ea97d7@thorsi… Reported-by: Steven Seeger <steven.seeger(a)flightsystems.net> Closes: https://lore.kernel.org/linux-mtd/DM6PR05MB4506554457CF95191A670BDEF7062@DM… Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com> --- drivers/mtd/nand/raw/nand_base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c index acd137dd0957..248e654ecefd 100644 --- a/drivers/mtd/nand/raw/nand_base.c +++ b/drivers/mtd/nand/raw/nand_base.c @@ -2173,7 +2173,7 @@ EXPORT_SYMBOL_GPL(nand_reset_op); int nand_read_data_op(struct nand_chip *chip, void *buf, unsigned int len, bool force_8bit, bool check_only) { - if (!len || !buf) + if (!len || (!check_only && !buf)) return -EINVAL; if (nand_has_exec_op(chip)) { -- 2.40.1

1 year, 2 months

2
1
0 0

[PATCH net] mptcp: only allow set existing scheduler for net.mptcp.scheduler

by Matthieu Baerts (NGI0)

From: Gregory Detal <gregory.detal(a)gmail.com> The current behavior is to accept any strings as inputs, this results in an inconsistent result where an unexisting scheduler can be set: # sysctl -w net.mptcp.scheduler=notdefault net.mptcp.scheduler = notdefault This patch changes this behavior by checking for existing scheduler before accepting the input. Fixes: e3b2870b6d22 ("mptcp: add a new sysctl scheduler") Cc: stable(a)vger.kernel.org Signed-off-by: Gregory Detal <gregory.detal(a)gmail.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Tested-by: Geliang Tang <geliang(a)kernel.org> Reviewed-by: Mat Martineau <martineau(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> --- net/mptcp/ctrl.c | 39 ++++++++++++++++++++++++++++++++++++++- 1 file changed, 38 insertions(+), 1 deletion(-) diff --git a/net/mptcp/ctrl.c b/net/mptcp/ctrl.c index 13fe0748dde8..2963ba84e2ee 100644 --- a/net/mptcp/ctrl.c +++ b/net/mptcp/ctrl.c @@ -96,6 +96,43 @@ static void mptcp_pernet_set_defaults(struct mptcp_pernet *pernet) } #ifdef CONFIG_SYSCTL +static int mptcp_set_scheduler(const struct net *net, const char *name) +{ + struct mptcp_pernet *pernet = mptcp_get_pernet(net); + struct mptcp_sched_ops *sched; + int ret = 0; + + rcu_read_lock(); + sched = mptcp_sched_find(name); + if (sched) + strscpy(pernet->scheduler, name, MPTCP_SCHED_NAME_MAX); + else + ret = -ENOENT; + rcu_read_unlock(); + + return ret; +} + +static int proc_scheduler(struct ctl_table *ctl, int write, + void *buffer, size_t *lenp, loff_t *ppos) +{ + const struct net *net = current->nsproxy->net_ns; + char val[MPTCP_SCHED_NAME_MAX]; + struct ctl_table tbl = { + .data = val, + .maxlen = MPTCP_SCHED_NAME_MAX, + }; + int ret; + + strscpy(val, mptcp_get_scheduler(net), MPTCP_SCHED_NAME_MAX); + + ret = proc_dostring(&tbl, write, buffer, lenp, ppos); + if (write && ret == 0) + ret = mptcp_set_scheduler(net, val); + + return ret; +} + static struct ctl_table mptcp_sysctl_table[] = { { .procname = "enabled", @@ -148,7 +185,7 @@ static struct ctl_table mptcp_sysctl_table[] = { .procname = "scheduler", .maxlen = MPTCP_SCHED_NAME_MAX, .mode = 0644, - .proc_handler = proc_dostring, + .proc_handler = proc_scheduler, }, { .procname = "close_timeout", --- base-commit: a26ff37e624d12e28077e5b24d2b264f62764ad6 change-id: 20240506-upstream-net-20240506-mptcp-sched-exist-6a1b91872a32 Best regards, -- Matthieu Baerts (NGI0) <matttbe(a)kernel.org>

1 year, 2 months

2
1
0 0

[PATCH AUTOSEL 6.6 01/43] ASoC: Intel: bytcr_rt5640: Apply Asus T100TA quirk to Asus T100TAM too

by Sasha Levin

From: Hans de Goede <hdegoede(a)redhat.com> [ Upstream commit e50729d742ec364895f1c389c32315984a987aa5 ] The Asus T100TA quirk has been using an exact match on a product-name of "T100TA" but there are also T100TAM variants with a slightly higher clocked CPU and a metal backside which need the same quirk. Sort the existing T100TA (stereo speakers) below the more specific T100TAF (mono speaker) quirk and switch from exact matching to substring matching so that the T100TA quirk will also match on the T100TAM models. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Link: https://msgid.link/r/20240407191559.21596-1-hdegoede@redhat.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/intel/boards/bytcr_rt5640.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/sound/soc/intel/boards/bytcr_rt5640.c b/sound/soc/intel/boards/bytcr_rt5640.c index e609249cc38d5..651408c6f399d 100644 --- a/sound/soc/intel/boards/bytcr_rt5640.c +++ b/sound/soc/intel/boards/bytcr_rt5640.c @@ -636,28 +636,30 @@ static const struct dmi_system_id byt_rt5640_quirk_table[] = { BYT_RT5640_USE_AMCR0F28), }, { + /* Asus T100TAF, unlike other T100TA* models this one has a mono speaker */ .matches = { DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), - DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100TA"), + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100TAF"), }, .driver_data = (void *)(BYT_RT5640_IN1_MAP | BYT_RT5640_JD_SRC_JD2_IN4N | BYT_RT5640_OVCD_TH_2000UA | BYT_RT5640_OVCD_SF_0P75 | + BYT_RT5640_MONO_SPEAKER | + BYT_RT5640_DIFF_MIC | + BYT_RT5640_SSP0_AIF2 | BYT_RT5640_MCLK_EN), }, { + /* Asus T100TA and T100TAM, must come after T100TAF (mono spk) match */ .matches = { - DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), - DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100TAF"), + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), + DMI_MATCH(DMI_PRODUCT_NAME, "T100TA"), }, .driver_data = (void *)(BYT_RT5640_IN1_MAP | BYT_RT5640_JD_SRC_JD2_IN4N | BYT_RT5640_OVCD_TH_2000UA | BYT_RT5640_OVCD_SF_0P75 | - BYT_RT5640_MONO_SPEAKER | - BYT_RT5640_DIFF_MIC | - BYT_RT5640_SSP0_AIF2 | BYT_RT5640_MCLK_EN), }, { -- 2.43.0

1 year, 2 months

2
43
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2024