April 2024 - Linux-stable-mirror

[PATCH 5.15/5.10/5.4/4.19 0/1] pppoe: Fix memory leak in pppoe_sendmsg()

by Gavrilov Ilia

syzbot reports a memory leak in pppoe_sendmsg in 5.15, 5.10, 5.4 and 4.19 stable releases. The problem has been fixed by the following patch which can be cleanly applied to the 5.15, 5.10, 5.4 and 4.19 branches. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller Gavrilov Ilia (1): pppoe: Fix memory leak in pppoe_sendmsg() drivers/net/ppp/pppoe.c | 23 +++++++++-------------- 1 file changed, 9 insertions(+), 14 deletions(-) -- 2.39.2

1 year

1
1
0 0

[PATCH 5.10.y 1/1] mailbox: imx: fix suspend failue

by Daisuke Mizobuchi

When an interrupt occurs, it always wakes up. Suspend fails as follows: armadillo:~# echo mem > /sys/power/state [ 2614.602432] PM: suspend entry (deep) [ 2614.610640] Filesystems sync: 0.004 seconds [ 2614.618016] Freezing user space processes ... (elapsed 0.001 seconds) done. [ 2614.626555] OOM killer disabled. [ 2614.629792] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 2614.638456] printk: Suspending console(s) (use no_console_suspend to debug) [ 2614.649504] PM: Some devices failed to suspend, or early wake event detected [ 2614.730103] PM: resume devices took 0.080 seconds [ 2614.741924] OOM killer enabled. [ 2614.745073] Restarting tasks ... done. [ 2614.754532] PM: suspend exit ash: write error: Resource busy armadillo:~# Upstream is correct, so it seems to be a mistake in cheery-pick. Cc: <stable(a)vger.kernel.org> Fixes: a16f5ae8ade1 ("mailbox: imx: fix wakeup failure from freeze mode") Signed-off-by: Daisuke Mizobuchi <mizo(a)atmark-techno.com> --- drivers/mailbox/imx-mailbox.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c index c5663398c6b7..28f5450e4130 100644 --- a/drivers/mailbox/imx-mailbox.c +++ b/drivers/mailbox/imx-mailbox.c @@ -331,8 +331,6 @@ static int imx_mu_startup(struct mbox_chan *chan) break; } - priv->suspend = true; - return 0; } @@ -550,8 +548,6 @@ static int imx_mu_probe(struct platform_device *pdev) clk_disable_unprepare(priv->clk); - priv->suspend = false; - return 0; disable_runtime_pm: @@ -614,6 +610,8 @@ static int __maybe_unused imx_mu_suspend_noirq(struct device *dev) if (!priv->clk) priv->xcr = imx_mu_read(priv, priv->dcfg->xCR); + priv->suspend = true; + return 0; } @@ -632,6 +630,8 @@ static int __maybe_unused imx_mu_resume_noirq(struct device *dev) if (!imx_mu_read(priv, priv->dcfg->xCR) && !priv->clk) imx_mu_write(priv, priv->xcr, priv->dcfg->xCR); + priv->suspend = false; + return 0; } -- 2.30.2

1 year

3
2
0 0

[PATCH 4.19.y v4 0/2] Double-free bug discovery on testing trigger-field-variable-support.tc

by George Guo

1) About v4-0001-tracing-Remove-hist-trigger-synth_var_refs.patch: The reason I am backporting this patch is that no one found the double-free bug at that time, then later the code was removed on upstream, but 4.19-stable has the bug. This is tested via "./ftracetest test.d/trigger/inter-event/ trigger-field-variable-support.tc" ================================================================== BUG: KASAN: use-after-free in destroy_hist_field+0x115/0x140 Read of size 4 at addr ffff888012e95318 by task ftracetest/1858 CPU: 1 PID: 1858 Comm: ftracetest Kdump: loaded Tainted: GE 4.19.90-89 #24 Source Version: Unknown Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0 Call Trace: dump_stack+0xcb/0x10b print_address_description.cold+0x54/0x249 kasan_report_error.cold+0x63/0xab ? destroy_hist_field+0x115/0x140 __asan_report_load4_noabort+0x8d/0xa0 ? destroy_hist_field+0x115/0x140 destroy_hist_field+0x115/0x140 destroy_hist_data+0x4e4/0x9a0 event_hist_trigger_free+0x212/0x2f0 ? update_cond_flag+0x128/0x170 ? event_hist_trigger_func+0x2880/0x2880 hist_unregister_trigger+0x2f2/0x4f0 event_hist_trigger_func+0x168c/0x2880 ? tracing_map_read_var_once+0xd0/0xd0 ? create_key_field+0x520/0x520 ? __mutex_lock_slowpath+0x10/0x10 event_trigger_write+0x2f4/0x490 ? trigger_start+0x180/0x180 ? __fget_light+0x369/0x5d0 ? count_memcg_event_mm+0x104/0x2b0 ? trigger_start+0x180/0x180 __vfs_write+0x81/0x100 vfs_write+0x1e1/0x540 ksys_write+0x12a/0x290 ? __ia32_sys_read+0xb0/0xb0 ? __close_fd+0x1d3/0x280 do_syscall_64+0xe3/0x2d0 entry_SYSCALL_64_after_hwframe+0x5c/0xc1 RIP: 0033:0x7efdd342ee04 Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 48 8d 05 39 34 0c 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5 RSP: 002b:00007ffda01f5e08 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00000000000000b4 RCX: 00007efdd342ee04 RDX: 00000000000000b4 RSI: 000055c5b41b1e90 RDI: 0000000000000001 RBP: 000055c5b41b1e90 R08: 000000000000000a R09: 0000000000000000 R10: 000000000000000a R11: 0000000000000246 R12: 00007efdd34ed5c0 R13: 00000000000000b4 R14: 00007efdd34ed7c0 R15: 00000000000000b4 ================================================================== 2) About v4-0002-tracing-Use-var_refs-for-hist-trigger-reference-c.patch: Only v4-0001-tracing-Remove-hist-trigger-synth_var_refs.patch will lead to compilation errors: ../kernel/trace/trace_events_hist.c: In function ��find_var_ref��: ../kernel/trace/trace_events_hist.c:1364:36: error: ��struct hist_trigger_data�� has no member named ��n_synth_var_refs��; did you mean ��n_var_refs��? 1364 | for (i = 0; i < hist_data->n_synth_var_refs; i++) { | ^~~~~~~~~~~~~~~~ | n_var_refs ../kernel/trace/trace_events_hist.c:1365:41: error: ��struct hist_trigger_data�� has no member named ��synth_var_refs��; did you mean ��n_var_refs��? 1365 | hist_field = hist_data->synth_var_refs[i]; | ^~~~~~~~~~~~~~ | n_var_refs Tom Zanussi (2): tracing: Remove hist trigger synth_var_refs tracing: Use var_refs[] for hist trigger reference checking kernel/trace/trace_events_hist.c | 86 ++++---------------------------- 1 file changed, 11 insertions(+), 75 deletions(-) -- 2.34.1

1 year

2
4
0 0

[PATCH 4.14-openela 049/190] usb: musb: fix MUSB_QUIRK_B_DISCONNECT_99 handling

by Sasha Levin

From: Thomas Petazzoni <thomas.petazzoni(a)bootlin.com> [ Upstream commit b65ba0c362be665192381cc59e3ac3ef6f0dd1e1 ] In commit 92af4fc6ec33 ("usb: musb: Fix suspend with devices connected for a64"), the logic to support the MUSB_QUIRK_B_DISCONNECT_99 quirk was modified to only conditionally schedule the musb->irq_work delayed work. This commit badly breaks ECM Gadget on AM335X. Indeed, with this commit, one can observe massive packet loss: $ ping 192.168.0.100 ... 15 packets transmitted, 3 received, 80% packet loss, time 14316ms Reverting this commit brings back a properly functioning ECM Gadget. An analysis of the commit seems to indicate that a mistake was made: the previous code was not falling through into the MUSB_QUIRK_B_INVALID_VBUS_91, but now it is, unless the condition is taken. Changing the logic to be as it was before the problematic commit *and* only conditionally scheduling musb->irq_work resolves the regression: $ ping 192.168.0.100 ... 64 packets transmitted, 64 received, 0% packet loss, time 64475ms Fixes: 92af4fc6ec33 ("usb: musb: Fix suspend with devices connected for a64") Cc: stable(a)vger.kernel.org Tested-by: Alexandre Belloni <alexandre.belloni(a)bootlin.com> Tested-by: Drew Fustini <drew(a)beagleboard.org> Acked-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni(a)bootlin.com> Link: https://lore.kernel.org/r/20210528140446.278076-1-thomas.petazzoni@bootlin.… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/usb/musb/musb_core.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index 9ed604ddbb585..580f4c12eada3 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -1869,9 +1869,8 @@ static void musb_pm_runtime_check_session(struct musb *musb) schedule_delayed_work(&musb->irq_work, msecs_to_jiffies(1000)); musb->quirk_retries--; - break; } - /* fall through */ + break; case MUSB_QUIRK_B_INVALID_VBUS_91: if (musb->quirk_retries && !musb->flush_irq_work) { musb_dbg(musb, -- 2.43.0

1 year

1
0
0 0

[PATCH 4.14-openela 046/190] ksmbd: fix wrong name of SMB2_CREATE_ALLOCATION_SIZE

by Sasha Levin

From: Namjae Jeon <linkinjeon(a)kernel.org> [ Upstream commit 13736654481198e519059d4a2e2e3b20fa9fdb3e ] MS confirm that "AISi" name of SMB2_CREATE_ALLOCATION_SIZE in MS-SMB2 specification is a typo. cifs/ksmbd have been using this wrong name from MS-SMB2. It should be "AlSi". Also It will cause problem when running smb2.create.open test in smbtorture against ksmbd. Cc: stable(a)vger.kernel.org Fixes: 12197a7fdda9 ("Clarify SMB2/SMB3 create context and add missing ones") Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> Reviewed-by: Paulo Alcantara (SUSE) <pc(a)manguebit.com> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- fs/cifs/smb2pdu.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/cifs/smb2pdu.h b/fs/cifs/smb2pdu.h index 407425d31b2eb..9ba9412c392f1 100644 --- a/fs/cifs/smb2pdu.h +++ b/fs/cifs/smb2pdu.h @@ -485,7 +485,7 @@ struct smb2_tree_disconnect_rsp { #define SMB2_CREATE_SD_BUFFER "SecD" /* security descriptor */ #define SMB2_CREATE_DURABLE_HANDLE_REQUEST "DHnQ" #define SMB2_CREATE_DURABLE_HANDLE_RECONNECT "DHnC" -#define SMB2_CREATE_ALLOCATION_SIZE "AISi" +#define SMB2_CREATE_ALLOCATION_SIZE "AlSi" #define SMB2_CREATE_QUERY_MAXIMAL_ACCESS_REQUEST "MxAc" #define SMB2_CREATE_TIMEWARP_REQUEST "TWrp" #define SMB2_CREATE_QUERY_ON_DISK_ID "QFid" -- 2.43.0

1 year

1
0
0 0

[PATCH 4.14-openela 045/190] PCI: keystone: Don't discard .probe() callback

by Sasha Levin

From: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> [ Upstream commit 7994db905c0fd692cf04c527585f08a91b560144 ] The __init annotation makes the ks_pcie_probe() function disappear after booting completes. However a device can also be bound later. In that case, we try to call ks_pcie_probe(), but the backing memory is likely already overwritten. The right thing to do is do always have the probe callback available. Note that the (wrong) __refdata annotation prevented this issue to be noticed by modpost. Fixes: 0c4ffcfe1fbc ("PCI: keystone: Add TI Keystone PCIe driver") Link: https://lore.kernel.org/r/20231001170254.2506508-5-u.kleine-koenig@pengutro… Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Cc: stable(a)vger.kernel.org Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/pci/dwc/pci-keystone.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/pci/dwc/pci-keystone.c b/drivers/pci/dwc/pci-keystone.c index 54fe75fd46b9d..6696d3999bffc 100644 --- a/drivers/pci/dwc/pci-keystone.c +++ b/drivers/pci/dwc/pci-keystone.c @@ -388,7 +388,7 @@ static int ks_pcie_remove(struct platform_device *pdev) return 0; } -static int __init ks_pcie_probe(struct platform_device *pdev) +static int ks_pcie_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; struct dw_pcie *pci; @@ -455,7 +455,7 @@ static int __init ks_pcie_probe(struct platform_device *pdev) return ret; } -static struct platform_driver ks_pcie_driver __refdata = { +static struct platform_driver ks_pcie_driver = { .probe = ks_pcie_probe, .remove = ks_pcie_remove, .driver = { -- 2.43.0

1 year

1
0
0 0

[PATCH 4.14-openela 044/190] PCI: keystone: Don't discard .remove() callback

by Sasha Levin

From: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> [ Upstream commit 200bddbb3f5202bbce96444fdc416305de14f547 ] With CONFIG_PCIE_KEYSTONE=y and ks_pcie_remove() marked with __exit, the function is discarded from the driver. In this case a bound device can still get unbound, e.g via sysfs. Then no cleanup code is run resulting in resource leaks or worse. The right thing to do is do always have the remove callback available. Note that this driver cannot be compiled as a module, so ks_pcie_remove() was always discarded before this change and modpost couldn't warn about this issue. Furthermore the __ref annotation also prevents a warning. Fixes: 0c4ffcfe1fbc ("PCI: keystone: Add TI Keystone PCIe driver") Link: https://lore.kernel.org/r/20231001170254.2506508-4-u.kleine-koenig@pengutro… Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Cc: stable(a)vger.kernel.org Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/pci/dwc/pci-keystone.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/pci/dwc/pci-keystone.c b/drivers/pci/dwc/pci-keystone.c index 3ea8288c16053..54fe75fd46b9d 100644 --- a/drivers/pci/dwc/pci-keystone.c +++ b/drivers/pci/dwc/pci-keystone.c @@ -379,7 +379,7 @@ static const struct dw_pcie_ops dw_pcie_ops = { .link_up = ks_dw_pcie_link_up, }; -static int __exit ks_pcie_remove(struct platform_device *pdev) +static int ks_pcie_remove(struct platform_device *pdev) { struct keystone_pcie *ks_pcie = platform_get_drvdata(pdev); @@ -457,7 +457,7 @@ static int __init ks_pcie_probe(struct platform_device *pdev) static struct platform_driver ks_pcie_driver __refdata = { .probe = ks_pcie_probe, - .remove = __exit_p(ks_pcie_remove), + .remove = ks_pcie_remove, .driver = { .name = "keystone-pcie", .of_match_table = of_match_ptr(ks_pcie_of_match), -- 2.43.0

1 year

1
0
0 0

[PATCH 4.14-openela 034/190] ASoC: cs42l51: fix driver to properly autoload with automatic module loading

by Sasha Levin

From: Thomas Petazzoni <thomas.petazzoni(a)bootlin.com> [ Upstream commit e51df4f81b02bcdd828a04de7c1eb6a92988b61e ] In commit 2cb1e0259f50 ("ASoC: cs42l51: re-hook of_match_table pointer"), 9 years ago, some random guy fixed the cs42l51 after it was split into a core part and an I2C part to properly match based on a Device Tree compatible string. However, the fix in this commit is wrong: the MODULE_DEVICE_TABLE(of, ....) is in the core part of the driver, not the I2C part. Therefore, automatic module loading based on module.alias, based on matching with the DT compatible string, loads the core part of the driver, but not the I2C part. And threfore, the i2c_driver is not registered, and the codec is not known to the system, nor matched with a DT node with the corresponding compatible string. In order to fix that, we move the MODULE_DEVICE_TABLE(of, ...) into the I2C part of the driver. The cs42l51_of_match[] array is also moved as well, as it is not possible to have this definition in one file, and the MODULE_DEVICE_TABLE(of, ...) invocation in another file, due to how MODULE_DEVICE_TABLE works. Thanks to this commit, the I2C part of the driver now properly autoloads, and thanks to its dependency on the core part, the core part gets autoloaded as well, resulting in a functional sound card without having to manually load kernel modules. Fixes: 2cb1e0259f50 ("ASoC: cs42l51: re-hook of_match_table pointer") Cc: stable(a)vger.kernel.org Signed-off-by: Thomas Petazzoni <thomas.petazzoni(a)bootlin.com> Link: https://lore.kernel.org/r/20230713112112.778576-1-thomas.petazzoni@bootlin.… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/codecs/cs42l51-i2c.c | 6 ++++++ sound/soc/codecs/cs42l51.c | 7 ------- sound/soc/codecs/cs42l51.h | 1 - 3 files changed, 6 insertions(+), 8 deletions(-) diff --git a/sound/soc/codecs/cs42l51-i2c.c b/sound/soc/codecs/cs42l51-i2c.c index 9bad478474fa3..5614378557d0c 100644 --- a/sound/soc/codecs/cs42l51-i2c.c +++ b/sound/soc/codecs/cs42l51-i2c.c @@ -23,6 +23,12 @@ static struct i2c_device_id cs42l51_i2c_id[] = { }; MODULE_DEVICE_TABLE(i2c, cs42l51_i2c_id); +const struct of_device_id cs42l51_of_match[] = { + { .compatible = "cirrus,cs42l51", }, + { } +}; +MODULE_DEVICE_TABLE(of, cs42l51_of_match); + static int cs42l51_i2c_probe(struct i2c_client *i2c, const struct i2c_device_id *id) { diff --git a/sound/soc/codecs/cs42l51.c b/sound/soc/codecs/cs42l51.c index f8072f1897d4c..b9de9836f2f4c 100644 --- a/sound/soc/codecs/cs42l51.c +++ b/sound/soc/codecs/cs42l51.c @@ -562,13 +562,6 @@ int cs42l51_probe(struct device *dev, struct regmap *regmap) } EXPORT_SYMBOL_GPL(cs42l51_probe); -const struct of_device_id cs42l51_of_match[] = { - { .compatible = "cirrus,cs42l51", }, - { } -}; -MODULE_DEVICE_TABLE(of, cs42l51_of_match); -EXPORT_SYMBOL_GPL(cs42l51_of_match); - MODULE_AUTHOR("Arnaud Patard <arnaud.patard(a)rtp-net.org>"); MODULE_DESCRIPTION("Cirrus Logic CS42L51 ALSA SoC Codec Driver"); MODULE_LICENSE("GPL"); diff --git a/sound/soc/codecs/cs42l51.h b/sound/soc/codecs/cs42l51.h index 0ca805492ac4b..8c55bf384bc65 100644 --- a/sound/soc/codecs/cs42l51.h +++ b/sound/soc/codecs/cs42l51.h @@ -22,7 +22,6 @@ struct device; extern const struct regmap_config cs42l51_regmap; int cs42l51_probe(struct device *dev, struct regmap *regmap); -extern const struct of_device_id cs42l51_of_match[]; #define CS42L51_CHIP_ID 0x1B #define CS42L51_CHIP_REV_A 0x00 -- 2.43.0

1 year

1
0
0 0

[PATCH 4.14-openela 033/190] PCI: qcom: Disable write access to read only registers for IP v2.3.3

by Sasha Levin

From: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> [ Upstream commit a33d700e8eea76c62120cb3dbf5e01328f18319a ] In the post init sequence of v2.9.0, write access to read only registers are not disabled after updating the registers. Fix it by disabling the access after register update. Link: https://lore.kernel.org/r/20230619150408.8468-2-manivannan.sadhasivam@linar… Fixes: 5d76117f070d ("PCI: qcom: Add support for IPQ8074 PCIe controller") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/pci/dwc/pcie-qcom.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/pci/dwc/pcie-qcom.c b/drivers/pci/dwc/pcie-qcom.c index fe710f83e59bc..431bc0e4d3eec 100644 --- a/drivers/pci/dwc/pcie-qcom.c +++ b/drivers/pci/dwc/pcie-qcom.c @@ -730,6 +730,8 @@ static int qcom_pcie_get_resources_2_4_0(struct qcom_pcie *pcie) if (IS_ERR(res->phy_ahb_reset)) return PTR_ERR(res->phy_ahb_reset); + dw_pcie_dbi_ro_wr_dis(pci); + return 0; } -- 2.43.0

1 year

1
0
0 0

[PATCH 4.14-openela 032/190] pinctrl: amd: Only use special debounce behavior for GPIO 0

by Sasha Levin

From: Mario Limonciello <mario.limonciello(a)amd.com> [ Upstream commit 0d5ace1a07f7e846d0f6d972af60d05515599d0b ] It's uncommon to use debounce on any other pin, but technically we should only set debounce to 0 when working off GPIO0. Cc: stable(a)vger.kernel.org Tested-by: Jan Visser <starquake(a)linuxeverywhere.org> Fixes: 968ab9261627 ("pinctrl: amd: Detect internal GPIO0 debounce handling") Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com> Link: https://lore.kernel.org/r/20230705133005.577-2-mario.limonciello@amd.com Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/pinctrl/pinctrl-amd.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/pinctrl/pinctrl-amd.c b/drivers/pinctrl/pinctrl-amd.c index 41f12fa15143c..693137e0574fd 100644 --- a/drivers/pinctrl/pinctrl-amd.c +++ b/drivers/pinctrl/pinctrl-amd.c @@ -116,9 +116,11 @@ static int amd_gpio_set_debounce(struct gpio_chip *gc, unsigned offset, raw_spin_lock_irqsave(&gpio_dev->lock, flags); /* Use special handling for Pin0 debounce */ - pin_reg = readl(gpio_dev->base + WAKE_INT_MASTER_REG); - if (pin_reg & INTERNAL_GPIO0_DEBOUNCE) - debounce = 0; + if (offset == 0) { + pin_reg = readl(gpio_dev->base + WAKE_INT_MASTER_REG); + if (pin_reg & INTERNAL_GPIO0_DEBOUNCE) + debounce = 0; + } pin_reg = readl(gpio_dev->base + offset * 4); -- 2.43.0

1 year

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2024