- Linux-stable-mirror - lists.linaro.org

patch "misc: rtsx: set correct pcr_ops for rts522A" added to char-misc-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled misc: rtsx: set correct pcr_ops for rts522A to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From 10cea23b6aae15e8324f4101d785687f2c514fe5 Mon Sep 17 00:00:00 2001 From: YueHaibing <yuehaibing(a)huawei.com> Date: Thu, 26 Mar 2020 11:26:18 +0800 Subject: misc: rtsx: set correct pcr_ops for rts522A rts522a should use rts522a_pcr_ops, which is diffrent with rts5227 in phy/hw init setting. Fixes: ce6a5acc9387 ("mfd: rtsx: Add support for rts522A") Signed-off-by: YueHaibing <yuehaibing(a)huawei.com> Cc: stable <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20200326032618.20472-1-yuehaibing@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/misc/cardreader/rts5227.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/misc/cardreader/rts5227.c b/drivers/misc/cardreader/rts5227.c index 423fecc19fc4..3a9467aaa435 100644 --- a/drivers/misc/cardreader/rts5227.c +++ b/drivers/misc/cardreader/rts5227.c @@ -394,6 +394,7 @@ static const struct pcr_ops rts522a_pcr_ops = { void rts522a_init_params(struct rtsx_pcr *pcr) { rts5227_init_params(pcr); + pcr->ops = &rts522a_pcr_ops; pcr->tx_initial_phase = SET_CLOCK_PHASE(20, 20, 11); pcr->reg_pm_ctrl3 = RTS522A_PM_CTRL3; -- 2.26.0

5 years, 9 months

1
0
0 0

patch "mei: me: add cedar fork device ids" added to char-misc-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mei: me: add cedar fork device ids to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From 99397d33b763dc554d118aaa38cc5abc6ce985de Mon Sep 17 00:00:00 2001 From: Alexander Usyskin <alexander.usyskin(a)intel.com> Date: Tue, 24 Mar 2020 23:07:30 +0200 Subject: mei: me: add cedar fork device ids Add Cedar Fork (CDF) device ids, those belongs to the cannon point family. Cc: <stable(a)vger.kernel.org> Signed-off-by: Alexander Usyskin <alexander.usyskin(a)intel.com> Signed-off-by: Tomas Winkler <tomas.winkler(a)intel.com> Link: https://lore.kernel.org/r/20200324210730.17672-1-tomas.winkler@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/misc/mei/hw-me-regs.h | 2 ++ drivers/misc/mei/pci-me.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/drivers/misc/mei/hw-me-regs.h b/drivers/misc/mei/hw-me-regs.h index d2359aed79ae..9392934e3a06 100644 --- a/drivers/misc/mei/hw-me-regs.h +++ b/drivers/misc/mei/hw-me-regs.h @@ -87,6 +87,8 @@ #define MEI_DEV_ID_CMP_H 0x06e0 /* Comet Lake H */ #define MEI_DEV_ID_CMP_H_3 0x06e4 /* Comet Lake H 3 (iTouch) */ +#define MEI_DEV_ID_CDF 0x18D3 /* Cedar Fork */ + #define MEI_DEV_ID_ICP_LP 0x34E0 /* Ice Lake Point LP */ #define MEI_DEV_ID_JSP_N 0x4DE0 /* Jasper Lake Point N */ diff --git a/drivers/misc/mei/pci-me.c b/drivers/misc/mei/pci-me.c index ebdc2d6f8ddb..3d21c38e2dbb 100644 --- a/drivers/misc/mei/pci-me.c +++ b/drivers/misc/mei/pci-me.c @@ -102,6 +102,8 @@ static const struct pci_device_id mei_me_pci_tbl[] = { {MEI_PCI_DEVICE(MEI_DEV_ID_MCC, MEI_ME_PCH15_CFG)}, {MEI_PCI_DEVICE(MEI_DEV_ID_MCC_4, MEI_ME_PCH8_CFG)}, + {MEI_PCI_DEVICE(MEI_DEV_ID_CDF, MEI_ME_PCH8_CFG)}, + /* required last entry */ {0, } }; -- 2.26.0

5 years, 9 months

1
0
0 0

patch "coresight: do not use the BIT() macro in the UAPI header" added to char-misc-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled coresight: do not use the BIT() macro in the UAPI header to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From 9b6eaaf3db5e5888df7bca7fed7752a90f7fd871 Mon Sep 17 00:00:00 2001 From: Eugene Syromiatnikov <esyr(a)redhat.com> Date: Tue, 24 Mar 2020 05:22:13 +0100 Subject: coresight: do not use the BIT() macro in the UAPI header The BIT() macro definition is not available for the UAPI headers (moreover, it can be defined differently in the user space); replace its usage with the _BITUL() macro that is defined in <linux/const.h>. Fixes: 237483aa5cf4 ("coresight: stm: adding driver for CoreSight STM component") Signed-off-by: Eugene Syromiatnikov <esyr(a)redhat.com> Cc: stable <stable(a)vger.kernel.org> Reviewed-by: Mathieu Poirier <mathieu.poirier(a)linaro.org> Link: https://lore.kernel.org/r/20200324042213.GA10452@asgard.redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/uapi/linux/coresight-stm.h | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/include/uapi/linux/coresight-stm.h b/include/uapi/linux/coresight-stm.h index aac550a52f80..8847dbf24151 100644 --- a/include/uapi/linux/coresight-stm.h +++ b/include/uapi/linux/coresight-stm.h @@ -2,8 +2,10 @@ #ifndef __UAPI_CORESIGHT_STM_H_ #define __UAPI_CORESIGHT_STM_H_ -#define STM_FLAG_TIMESTAMPED BIT(3) -#define STM_FLAG_GUARANTEED BIT(7) +#include <linux/const.h> + +#define STM_FLAG_TIMESTAMPED _BITUL(3) +#define STM_FLAG_GUARANTEED _BITUL(7) /* * The CoreSight STM supports guaranteed and invariant timing -- 2.26.0

5 years, 9 months

1
0
0 0

[PATCH V2] x86/Hyper-V: Fix hv sched clock function return wrong time unit

by Tianyu Lan

From: Yubo Xie <yuboxie(a)microsoft.com> sched clock callback should return time with nano second as unit but current hv callback returns time with 100ns. Fix it. Cc: stable(a)vger.kernel.org Signed-off-by: Yubo Xie <yuboxie(a)microsoft.com> Signed-off-by: Tianyu Lan <Tianyu.Lan(a)microsoft.com> Fixes: bd00cd52d5be ("clocksource/drivers/hyperv: Add Hyper-V specific sched clock function") --- Change since v1: Update fix commit number in change log. --- drivers/clocksource/hyperv_timer.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/clocksource/hyperv_timer.c b/drivers/clocksource/hyperv_timer.c index 9d808d595ca8..662ed978fa24 100644 --- a/drivers/clocksource/hyperv_timer.c +++ b/drivers/clocksource/hyperv_timer.c @@ -343,7 +343,8 @@ static u64 notrace read_hv_clock_tsc_cs(struct clocksource *arg) static u64 read_hv_sched_clock_tsc(void) { - return read_hv_clock_tsc() - hv_sched_clock_offset; + return (read_hv_clock_tsc() - hv_sched_clock_offset) + * (NSEC_PER_SEC / HV_CLOCK_HZ); } static void suspend_hv_clock_tsc(struct clocksource *arg) @@ -398,7 +399,8 @@ static u64 notrace read_hv_clock_msr_cs(struct clocksource *arg) static u64 read_hv_sched_clock_msr(void) { - return read_hv_clock_msr() - hv_sched_clock_offset; + return (read_hv_clock_msr() - hv_sched_clock_offset) + * (NSEC_PER_SEC / HV_CLOCK_HZ); } static struct clocksource hyperv_cs_msr = { -- 2.14.5

5 years, 9 months

5
5
0 0

FAILED: patch "[PATCH] Input: raydium_i2c_ts - fix error codes in" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 32cf3a610c35cb21e3157f4bbf29d89960e30a36 Mon Sep 17 00:00:00 2001 From: Dan Carpenter <dan.carpenter(a)oracle.com> Date: Fri, 6 Mar 2020 11:50:51 -0800 Subject: [PATCH] Input: raydium_i2c_ts - fix error codes in raydium_i2c_boot_trigger() These functions are supposed to return negative error codes but instead it returns true on failure and false on success. The error codes are eventually propagated back to user space. Fixes: 48a2b783483b ("Input: add Raydium I2C touchscreen driver") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Link: https://lore.kernel.org/r/20200303101306.4potflz7na2nn3od@kili.mountain Cc: stable(a)vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> diff --git a/drivers/input/touchscreen/raydium_i2c_ts.c b/drivers/input/touchscreen/raydium_i2c_ts.c index 6ed9f22e6401..fe245439adee 100644 --- a/drivers/input/touchscreen/raydium_i2c_ts.c +++ b/drivers/input/touchscreen/raydium_i2c_ts.c @@ -432,7 +432,7 @@ static int raydium_i2c_write_object(struct i2c_client *client, return 0; } -static bool raydium_i2c_boot_trigger(struct i2c_client *client) +static int raydium_i2c_boot_trigger(struct i2c_client *client) { static const u8 cmd[7][6] = { { 0x08, 0x0C, 0x09, 0x00, 0x50, 0xD7 }, @@ -457,10 +457,10 @@ static bool raydium_i2c_boot_trigger(struct i2c_client *client) } } - return false; + return 0; } -static bool raydium_i2c_fw_trigger(struct i2c_client *client) +static int raydium_i2c_fw_trigger(struct i2c_client *client) { static const u8 cmd[5][11] = { { 0, 0x09, 0x71, 0x0C, 0x09, 0x00, 0x50, 0xD7, 0, 0, 0 }, @@ -483,7 +483,7 @@ static bool raydium_i2c_fw_trigger(struct i2c_client *client) } } - return false; + return 0; } static int raydium_i2c_check_path(struct i2c_client *client)

5 years, 9 months

1
0
0 0

[git:media_tree/master] media: venus: firmware: Ignore secure call error on first resume

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: venus: firmware: Ignore secure call error on first resume Author: Stanimir Varbanov <stanimir.varbanov(a)linaro.org> Date: Wed Mar 4 11:09:49 2020 +0100 With the latest cleanup in qcom scm driver the secure monitor call for setting the remote processor state returns EINVAL when it is called for the first time and after another scm call auth_and_reset. The error returned from scm call could be ignored because the state transition is already done in auth_and_reset. Acked-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> Signed-off-by: Stanimir Varbanov <stanimir.varbanov(a)linaro.org> Cc: stable(a)vger.kernel.org Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> drivers/media/platform/qcom/venus/firmware.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) --- diff --git a/drivers/media/platform/qcom/venus/firmware.c b/drivers/media/platform/qcom/venus/firmware.c index de6812fb55f4..8801a6a7543d 100644 --- a/drivers/media/platform/qcom/venus/firmware.c +++ b/drivers/media/platform/qcom/venus/firmware.c @@ -44,8 +44,14 @@ static void venus_reset_cpu(struct venus_core *core) int venus_set_hw_state(struct venus_core *core, bool resume) { - if (core->use_tz) - return qcom_scm_set_remote_state(resume, 0); + int ret; + + if (core->use_tz) { + ret = qcom_scm_set_remote_state(resume, 0); + if (resume && ret == -EINVAL) + ret = 0; + return ret; + } if (resume) venus_reset_cpu(core);

5 years, 9 months

1
0
0 0

Patches for v4.14.y

by Guenter Roeck

Hi, Please consider applying the following patches to v4.14.y. The following patches were found to be missing in v4.14.y by the ChromeOS missing patch robot. The patches meet the following criteria. - The patch includes a Fixes: tag - The patch referenced in the Fixes: tag has been applied to v4.14.y - The patch has not been applied to v4.14.y All patches have been applied to v4.14.y and chromeos-4.14. Resulting images have been build- and runtime-tested on real hardware with chromeos-4.14 and with virtual hardware on kerneltests.org. Upstream commit 76fc52bd07d3 ("arm64: ptrace: map SPSR_ELx<->PSR for compat tasks") Fixes: 7206dc93a58fb764 ("arm64: Expose Arm v8.4 features") in v4.14.y: 053cdffad3dd Upstream commit 25dc2c80cfa3 ("arm64: compat: map SPSR_ELx<->PSR for signals") Fixes: 7206dc93a58fb764 ("arm64: Expose Arm v8.4 features") in v4.14.y: 053cdffad3dd Upstream commit 93a64ee71d10 ("MAINTAINERS: Remove deleted file from futex file pattern") Fixes: 04e7712f4460 ("y2038: futex: Move compat implementation into futex.c") in v4.14.y: 0c08f1da992d Notes: Also applies to v4.19.y. This is an example for a patch which isn't really necessary (it doesn't fix a bug, only an entry in the the MAINTAINERS file), but automation won't be able to know that. Please let me know what to do with similar patches in the future. Upstream commit 074376ac0e1d ("ftrace/x86: Anotate text_mutex split between ftrace_arch_code_modify_post_process() and ftrace_arch_code_modify_prepare()") Fixes: 39611265edc1a ("ftrace/x86: Add a comment to why we take text_mutex in ftrace_arch_code_modify_prepare()") Fixes: d5b844a2cf507 ("ftrace/x86: Remove possible deadlock between register_kprobe() and ftrace_run_update_code()") in v4.14.y: 0c0b54770189 (upstream d5b844a2cf507) Notes: Also applies to v4.19.y. Thanks, Guenter

5 years, 9 months

2
1
0 0

Stable request: iwlwifi: mvm: fix non-ACPI function

by Jason Andryuk

From: Johannes Berg <johannes.berg(a)intel.com> commit 7937fd3227055892e169f4b34d21157e57d919e2 upstream. The code now compiles without ACPI, but there's a warning since iwl_mvm_get_ppag_table() isn't used, and iwl_mvm_ppag_init() must not unconditionally fail but return success instead. Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com> Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org> [Drop hunk removing iwl_mvm_get_ppag_table() since it doesn't exist in 5.4] Signed-off-by: Jason Andryuk <jandryuk(a)gmail.com> --- A 5.4 kernel can't "up" an iwlwifi interface when CONFIG_ACPI=n. `wpa_supplicant` or `ip link set wlan0 up` return "No such file or directory". The non-acpi stub iwl_mvm_ppag_init() always returns -ENOENT which means iwl_mvm_up() always fails. Backporting the commit lets iwl_mvm_up() succeed. drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c index c59cbb8cbdd7..c54fe6650018 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c @@ -1181,7 +1181,7 @@ int iwl_mvm_ppag_send_cmd(struct iwl_mvm *mvm) static int iwl_mvm_ppag_init(struct iwl_mvm *mvm) { - return -ENOENT; + return 0; } #endif /* CONFIG_ACPI */ -- 2.25.1

5 years, 9 months

2
2
0 0

[PATCH v2] powerpc: Make setjmp/longjmp signature standard

by Clement Courbet

Declaring setjmp()/longjmp() as taking longs makes the signature non-standard, and makes clang complain. In the past, this has been worked around by adding -ffreestanding to the compile flags. The implementation looks like it only ever propagates the value (in longjmp) or sets it to 1 (in setjmp), and we only call longjmp with integer parameters. This allows removing -ffreestanding from the compilation flags. Context: https://lore.kernel.org/patchwork/patch/1214060 https://lore.kernel.org/patchwork/patch/1216174 Signed-off-by: Clement Courbet <courbet(a)google.com> Reviewed-by: Nathan Chancellor <natechancellor(a)gmail.com> Tested-by: Nathan Chancellor <natechancellor(a)gmail.com> --- v2: Use and array type as suggested by Segher Boessenkool Cc: stable(a)vger.kernel.org # v4.14+ Fixes: c9029ef9c957 ("powerpc: Avoid clang warnings around setjmp and longjmp") --- arch/powerpc/include/asm/setjmp.h | 6 ++++-- arch/powerpc/kexec/Makefile | 3 --- arch/powerpc/xmon/Makefile | 3 --- 3 files changed, 4 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/include/asm/setjmp.h b/arch/powerpc/include/asm/setjmp.h index e9f81bb3f83b..f798e80e4106 100644 --- a/arch/powerpc/include/asm/setjmp.h +++ b/arch/powerpc/include/asm/setjmp.h @@ -7,7 +7,9 @@ #define JMP_BUF_LEN 23 -extern long setjmp(long *) __attribute__((returns_twice)); -extern void longjmp(long *, long) __attribute__((noreturn)); +typedef long jmp_buf[JMP_BUF_LEN]; + +extern int setjmp(jmp_buf env) __attribute__((returns_twice)); +extern void longjmp(jmp_buf env, int val) __attribute__((noreturn)); #endif /* _ASM_POWERPC_SETJMP_H */ diff --git a/arch/powerpc/kexec/Makefile b/arch/powerpc/kexec/Makefile index 378f6108a414..86380c69f5ce 100644 --- a/arch/powerpc/kexec/Makefile +++ b/arch/powerpc/kexec/Makefile @@ -3,9 +3,6 @@ # Makefile for the linux kernel. # -# Avoid clang warnings around longjmp/setjmp declarations -CFLAGS_crash.o += -ffreestanding - obj-y += core.o crash.o core_$(BITS).o obj-$(CONFIG_PPC32) += relocate_32.o diff --git a/arch/powerpc/xmon/Makefile b/arch/powerpc/xmon/Makefile index c3842dbeb1b7..6f9cccea54f3 100644 --- a/arch/powerpc/xmon/Makefile +++ b/arch/powerpc/xmon/Makefile @@ -1,9 +1,6 @@ # SPDX-License-Identifier: GPL-2.0 # Makefile for xmon -# Avoid clang warnings around longjmp/setjmp declarations -subdir-ccflags-y := -ffreestanding - GCOV_PROFILE := n KCOV_INSTRUMENT := n UBSAN_SANITIZE := n -- 2.26.0.rc2.310.g2932bb562d-goog

5 years, 9 months

2
1
0 0

[PATCH 2/3] ALSA: hda/realtek - Set principled PC Beep configuration for ALC256

by Thomas Hebb

The Realtek PC Beep Hidden Register[1] is currently set by patch_realtek.c in two different places: In alc_fill_eapd_coef(), it's set to the value 0x5757, corresponding to non-beep input on 1Ah and no 1Ah loopback to either headphones or speakers. (Although, curiously, the loopback amp is still enabled.) This write was added fairly recently by commit e3743f431143 ("ALSA: hda/realtek - Dell headphone has noise on unmute for ALC236") and is a safe default. However, it happens in the wrong place: alc_fill_eapd_coef() runs on module load and cold boot but not on S3 resume, meaning the register loses its value after suspend. Conversely, in alc256_init(), the register is updated to unset bit 13 (disable speaker loopback) and set bit 5 (set non-beep input on 1Ah). Although this write does run on S3 resume, it's not quite enough to fix up the register's default value of 0x3717. What's missing is a set of bit 14 to disable headphone loopback. Without that, we end up with a feedback loop where the headphone jack is being driven by amplified samples of itself[2]. This change eliminates the write in alc_fill_eapd_coef() and replaces the update in alc256_init() with a write of the fixed value 0x4727. This value ought to have the same behavior as 0x5757--disabling all PC Beep routing that isn't part of the HDA node graph--but it has two differences: 1. To enable non-beep input on 1Ah, the `b` field is set to 1, like the previous code in alc256_init() used, instead of 2, like the value written by alc_fill_eapd_coef() used. My testing shows these two values to behave identically, but, in case there is a difference, a bitwise update of the register seems like a more reliable source of truth than a magic number written without explanation. 2. Loopback amplification is disabled (unset L and R bits) because no loopback path is in use. Affects the ALC255, ALC256, ALC257, ALC235, and ALC236 codecs. [1] Newly documented in Documentation/sound/hd-audio/realtek-pc-beep.rst [2] Setting the "Headphone Mic Boost" control from userspace changes this feedback loop and has been a widely-shared workaround for headphone noise on laptops like the Dell XPS 13 9350. This commit eliminates the feedback loop and makes the workaround unnecessary. Fixes: e3743f431143 ("ALSA: hda/realtek - Dell headphone has noise on unmute for ALC236") Cc: stable(a)vger.kernel.org Signed-off-by: Thomas Hebb <tommyhebb(a)gmail.com> --- sound/pci/hda/patch_realtek.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 63e1a56f705b..024dd61a788b 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -367,7 +367,9 @@ static void alc_fill_eapd_coef(struct hda_codec *codec) case 0x10ec0215: case 0x10ec0233: case 0x10ec0235: + case 0x10ec0236: case 0x10ec0255: + case 0x10ec0256: case 0x10ec0257: case 0x10ec0282: case 0x10ec0283: @@ -379,11 +381,6 @@ static void alc_fill_eapd_coef(struct hda_codec *codec) case 0x10ec0300: alc_update_coef_idx(codec, 0x10, 1<<9, 0); break; - case 0x10ec0236: - case 0x10ec0256: - alc_write_coef_idx(codec, 0x36, 0x5757); - alc_update_coef_idx(codec, 0x10, 1<<9, 0); - break; case 0x10ec0275: alc_update_coef_idx(codec, 0xe, 0, 1<<0); break; @@ -3269,7 +3266,13 @@ static void alc256_init(struct hda_codec *codec) alc_update_coefex_idx(codec, 0x57, 0x04, 0x0007, 0x4); /* Hight power */ alc_update_coefex_idx(codec, 0x53, 0x02, 0x8000, 1 << 15); /* Clear bit */ alc_update_coefex_idx(codec, 0x53, 0x02, 0x8000, 0 << 15); - alc_update_coef_idx(codec, 0x36, 1 << 13, 1 << 5); /* Switch pcbeep path to Line in path*/ + /* + * Expose headphone mic (or possibly Line In on some machines) instead + * of PC Beep on 1Ah, and disable 1Ah loopback for all outputs. See + * Documentation/sound/hd-audio/realtek-pc-beep.rst for details of + * this register. + */ + alc_write_coef_idx(codec, 0x36, 0x4727); } static void alc256_shutup(struct hda_codec *codec) -- 2.25.2

5 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror