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

[PATCH AUTOSEL 5.15 01/15] KVM: s390: Don't use %pK through tracepoints

by Sasha Levin

From: Thomas Weißschuh <thomas.weissschuh(a)linutronix.de> [ Upstream commit 6c9567e0850be2f0f94ab64fa6512413fd1a1eb1 ] Restricted pointers ("%pK") are not meant to be used through TP_format(). It can unintentionally expose security sensitive, raw pointer values. Use regular pointer formatting instead. Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c70704… Signed-off-by: Thomas Weißschuh <thomas.weissschuh(a)linutronix.de> Reviewed-by: Michael Mueller <mimu(a)linux.ibm.com> Link: https://lore.kernel.org/r/20250217-restricted-pointers-s390-v1-1-0e4ace75d8… Signed-off-by: Janosch Frank <frankja(a)linux.ibm.com> Message-ID: <20250217-restricted-pointers-s390-v1-1-0e4ace75d8aa(a)linutronix.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/s390/kvm/trace-s390.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/s390/kvm/trace-s390.h b/arch/s390/kvm/trace-s390.h index 6f0209d45164f..9c5f546a2e1a3 100644 --- a/arch/s390/kvm/trace-s390.h +++ b/arch/s390/kvm/trace-s390.h @@ -56,7 +56,7 @@ TRACE_EVENT(kvm_s390_create_vcpu, __entry->sie_block = sie_block; ), - TP_printk("create cpu %d at 0x%pK, sie block at 0x%pK", + TP_printk("create cpu %d at 0x%p, sie block at 0x%p", __entry->id, __entry->vcpu, __entry->sie_block) ); @@ -255,7 +255,7 @@ TRACE_EVENT(kvm_s390_enable_css, __entry->kvm = kvm; ), - TP_printk("enabling channel I/O support (kvm @ %pK)\n", + TP_printk("enabling channel I/O support (kvm @ %p)\n", __entry->kvm) ); -- 2.39.5

1 day, 20 hours

1
14
0 0

[PATCH AUTOSEL 6.12 01/30] KVM: s390: Don't use %pK through tracepoints

by Sasha Levin

From: Thomas Weißschuh <thomas.weissschuh(a)linutronix.de> [ Upstream commit 6c9567e0850be2f0f94ab64fa6512413fd1a1eb1 ] Restricted pointers ("%pK") are not meant to be used through TP_format(). It can unintentionally expose security sensitive, raw pointer values. Use regular pointer formatting instead. Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c70704… Signed-off-by: Thomas Weißschuh <thomas.weissschuh(a)linutronix.de> Reviewed-by: Michael Mueller <mimu(a)linux.ibm.com> Link: https://lore.kernel.org/r/20250217-restricted-pointers-s390-v1-1-0e4ace75d8… Signed-off-by: Janosch Frank <frankja(a)linux.ibm.com> Message-ID: <20250217-restricted-pointers-s390-v1-1-0e4ace75d8aa(a)linutronix.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/s390/kvm/trace-s390.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/s390/kvm/trace-s390.h b/arch/s390/kvm/trace-s390.h index 9ac92dbf680db..9e28f165c114c 100644 --- a/arch/s390/kvm/trace-s390.h +++ b/arch/s390/kvm/trace-s390.h @@ -56,7 +56,7 @@ TRACE_EVENT(kvm_s390_create_vcpu, __entry->sie_block = sie_block; ), - TP_printk("create cpu %d at 0x%pK, sie block at 0x%pK", + TP_printk("create cpu %d at 0x%p, sie block at 0x%p", __entry->id, __entry->vcpu, __entry->sie_block) ); @@ -255,7 +255,7 @@ TRACE_EVENT(kvm_s390_enable_css, __entry->kvm = kvm; ), - TP_printk("enabling channel I/O support (kvm @ %pK)\n", + TP_printk("enabling channel I/O support (kvm @ %p)\n", __entry->kvm) ); -- 2.39.5

1 day, 20 hours

2
30
0 0

[PATCH AUTOSEL 6.1 01/17] KVM: s390: Don't use %pK through tracepoints

by Sasha Levin

From: Thomas Weißschuh <thomas.weissschuh(a)linutronix.de> [ Upstream commit 6c9567e0850be2f0f94ab64fa6512413fd1a1eb1 ] Restricted pointers ("%pK") are not meant to be used through TP_format(). It can unintentionally expose security sensitive, raw pointer values. Use regular pointer formatting instead. Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c70704… Signed-off-by: Thomas Weißschuh <thomas.weissschuh(a)linutronix.de> Reviewed-by: Michael Mueller <mimu(a)linux.ibm.com> Link: https://lore.kernel.org/r/20250217-restricted-pointers-s390-v1-1-0e4ace75d8… Signed-off-by: Janosch Frank <frankja(a)linux.ibm.com> Message-ID: <20250217-restricted-pointers-s390-v1-1-0e4ace75d8aa(a)linutronix.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/s390/kvm/trace-s390.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/s390/kvm/trace-s390.h b/arch/s390/kvm/trace-s390.h index 6f0209d45164f..9c5f546a2e1a3 100644 --- a/arch/s390/kvm/trace-s390.h +++ b/arch/s390/kvm/trace-s390.h @@ -56,7 +56,7 @@ TRACE_EVENT(kvm_s390_create_vcpu, __entry->sie_block = sie_block; ), - TP_printk("create cpu %d at 0x%pK, sie block at 0x%pK", + TP_printk("create cpu %d at 0x%p, sie block at 0x%p", __entry->id, __entry->vcpu, __entry->sie_block) ); @@ -255,7 +255,7 @@ TRACE_EVENT(kvm_s390_enable_css, __entry->kvm = kvm; ), - TP_printk("enabling channel I/O support (kvm @ %pK)\n", + TP_printk("enabling channel I/O support (kvm @ %p)\n", __entry->kvm) ); -- 2.39.5

1 day, 20 hours

1
16
0 0

[PATCH AUTOSEL 6.6 01/24] KVM: s390: Don't use %pK through tracepoints

by Sasha Levin

From: Thomas Weißschuh <thomas.weissschuh(a)linutronix.de> [ Upstream commit 6c9567e0850be2f0f94ab64fa6512413fd1a1eb1 ] Restricted pointers ("%pK") are not meant to be used through TP_format(). It can unintentionally expose security sensitive, raw pointer values. Use regular pointer formatting instead. Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c70704… Signed-off-by: Thomas Weißschuh <thomas.weissschuh(a)linutronix.de> Reviewed-by: Michael Mueller <mimu(a)linux.ibm.com> Link: https://lore.kernel.org/r/20250217-restricted-pointers-s390-v1-1-0e4ace75d8… Signed-off-by: Janosch Frank <frankja(a)linux.ibm.com> Message-ID: <20250217-restricted-pointers-s390-v1-1-0e4ace75d8aa(a)linutronix.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/s390/kvm/trace-s390.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/s390/kvm/trace-s390.h b/arch/s390/kvm/trace-s390.h index 6f0209d45164f..9c5f546a2e1a3 100644 --- a/arch/s390/kvm/trace-s390.h +++ b/arch/s390/kvm/trace-s390.h @@ -56,7 +56,7 @@ TRACE_EVENT(kvm_s390_create_vcpu, __entry->sie_block = sie_block; ), - TP_printk("create cpu %d at 0x%pK, sie block at 0x%pK", + TP_printk("create cpu %d at 0x%p, sie block at 0x%p", __entry->id, __entry->vcpu, __entry->sie_block) ); @@ -255,7 +255,7 @@ TRACE_EVENT(kvm_s390_enable_css, __entry->kvm = kvm; ), - TP_printk("enabling channel I/O support (kvm @ %pK)\n", + TP_printk("enabling channel I/O support (kvm @ %p)\n", __entry->kvm) ); -- 2.39.5

1 day, 20 hours

1
23
0 0

[PATCH net 2/2] amd-xgbe: Fix to ensure dependent features are toggled with RX checksum offload

by Vishal Badole

According to the XGMAC specification, enabling features such as Layer 3 and Layer 4 Packet Filtering, Split Header, Receive Side Scaling (RSS), and Virtualized Network support automatically selects the IPC Full Checksum Offload Engine on the receive side. When RX checksum offload is disabled, these dependent features must also be disabled to prevent abnormal behavior caused by mismatched feature dependencies. Ensure that toggling RX checksum offload (disabling or enabling) properly disables or enables all dependent features, maintaining consistent and expected behavior in the network device. Cc: stable(a)vger.kernel.org Fixes: c5aa9e3b8156 ("amd-xgbe: Initial AMD 10GbE platform driver") Signed-off-by: Vishal Badole <Vishal.Badole(a)amd.com> --- drivers/net/ethernet/amd/xgbe/xgbe-dev.c | 8 ++++++-- drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 19 +++++++++++++++++-- 2 files changed, 23 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-dev.c b/drivers/net/ethernet/amd/xgbe/xgbe-dev.c index 429c5e1444d8..48a474337d96 100644 --- a/drivers/net/ethernet/amd/xgbe/xgbe-dev.c +++ b/drivers/net/ethernet/amd/xgbe/xgbe-dev.c @@ -3764,8 +3764,12 @@ static int xgbe_init(struct xgbe_prv_data *pdata) xgbe_config_tx_coalesce(pdata); xgbe_config_rx_buffer_size(pdata); xgbe_config_tso_mode(pdata); - xgbe_config_sph_mode(pdata); - xgbe_config_rss(pdata); + + if (pdata->netdev->features & NETIF_F_RXCSUM) { + xgbe_config_sph_mode(pdata); + xgbe_config_rss(pdata); + } + desc_if->wrapper_tx_desc_init(pdata); desc_if->wrapper_rx_desc_init(pdata); xgbe_enable_dma_interrupts(pdata); diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c index f249f89fec38..0146af7f93cd 100755 --- a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c +++ b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c @@ -2267,6 +2267,16 @@ static netdev_features_t xgbe_fix_features(struct net_device *netdev, } } + if (features & NETIF_F_RXCSUM) { + netdev_notice(netdev, + "forcing receive hashing on\n"); + features |= NETIF_F_RXHASH; + } else { + netdev_notice(netdev, + "forcing receive hashing off\n"); + features &= ~NETIF_F_RXHASH; + } + return features; } @@ -2290,10 +2300,15 @@ static int xgbe_set_features(struct net_device *netdev, if (ret) return ret; - if ((features & NETIF_F_RXCSUM) && !rxcsum) + if ((features & NETIF_F_RXCSUM) && !rxcsum) { + hw_if->enable_sph(pdata); + hw_if->enable_vxlan(pdata); hw_if->enable_rx_csum(pdata); - else if (!(features & NETIF_F_RXCSUM) && rxcsum) + } else if (!(features & NETIF_F_RXCSUM) && rxcsum) { + hw_if->disable_sph(pdata); + hw_if->disable_vxlan(pdata); hw_if->disable_rx_csum(pdata); + } if ((features & NETIF_F_HW_VLAN_CTAG_RX) && !rxvlan) hw_if->enable_rx_vlan_stripping(pdata); -- 2.34.1

1 day, 21 hours

1
0
0 0

[PATCH v2 1/7] arm64: dts: ti: j721e-sk: Add DT nodes for power regulators

by Yemike Abhilash Chandra

Add device tree nodes for two power regulators on the J721E SK board. vsys_5v0: A fixed regulator representing the 5V supply output from the LM61460 and vdd_sd_dv: A GPIO-controlled TLV71033 regulator. J721E-SK schematics: https://www.ti.com/lit/zip/sprr438 Fixes: 1bfda92a3a36 ("arm64: dts: ti: Add support for J721E SK") Cc: stable(a)vger.kernel.org Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra(a)ti.com> --- arch/arm64/boot/dts/ti/k3-j721e-sk.dts | 31 ++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/arch/arm64/boot/dts/ti/k3-j721e-sk.dts b/arch/arm64/boot/dts/ti/k3-j721e-sk.dts index 440ef57be294..4965957e6545 100644 --- a/arch/arm64/boot/dts/ti/k3-j721e-sk.dts +++ b/arch/arm64/boot/dts/ti/k3-j721e-sk.dts @@ -184,6 +184,17 @@ vsys_3v3: fixedregulator-vsys3v3 { regulator-boot-on; }; + vsys_5v0: fixedregulator-vsys5v0 { + /* Output of LM61460 */ + compatible = "regulator-fixed"; + regulator-name = "vsys_5v0"; + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <5000000>; + vin-supply = <&vusb_main>; + regulator-always-on; + regulator-boot-on; + }; + vdd_mmc1: fixedregulator-sd { compatible = "regulator-fixed"; pinctrl-names = "default"; @@ -211,6 +222,20 @@ vdd_sd_dv_alt: gpio-regulator-tps659411 { <3300000 0x1>; }; + vdd_sd_dv: gpio-regulator-TLV71033 { + compatible = "regulator-gpio"; + pinctrl-names = "default"; + pinctrl-0 = <&vdd_sd_dv_pins_default>; + regulator-name = "tlv71033"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + vin-supply = <&vsys_5v0>; + gpios = <&main_gpio0 118 GPIO_ACTIVE_HIGH>; + states = <1800000 0x0>, + <3300000 0x1>; + }; + transceiver1: can-phy1 { compatible = "ti,tcan1042"; #phy-cells = <0>; @@ -613,6 +638,12 @@ J721E_WKUP_IOPAD(0xd4, PIN_OUTPUT, 7) /* (G26) WKUP_GPIO0_9 */ >; }; + vdd_sd_dv_pins_default: vdd-sd-dv-default-pins { + pinctrl-single,pins = < + J721E_IOPAD(0x1dc, PIN_INPUT, 7) /* (Y1) SPI1_CLK.GPIO0_118 */ + >; + }; + wkup_uart0_pins_default: wkup-uart0-default-pins { pinctrl-single,pins = < J721E_WKUP_IOPAD(0xa0, PIN_INPUT, 0) /* (J29) WKUP_UART0_RXD */ -- 2.34.1

1 day, 21 hours

3
3
0 0

BUG: perf hardware breakpoint pc value mismatch

by liaochen (A)

Hi all, We found the following issue with Linux v6.12-rc7 on KunPeng920 platform. A very low frequency problem of pc value mismatch occurs when using perf hardware breakpoints to trigger a signal handler and comparing pc from u_context with its desired value. Attached please find the reproducer for this issue. It applies perf events to set a hardware breakpoint to an address while binding a signal to the perf event fd. When stepping into the breakpoint address, the signal handler compares pc value copied from signal ucontext with the real breakpoint address and see if there is a mismatch. While looking into the flow of execution: // normal flow of exe: a.out-19844 [038] d... 8763.348609: hw_breakpoint_control: perf user addr: 400c6c, bp addr: 400c6c, ops: 0 // breakpoint exception: a.out-19844 [038] d... 8763.348611: do_debug_exception: ec: 0, pc: 400c6c, pstate: 20001000 a.out-19844 [038] d... 8763.348611: breakpoint_handler: perf bp read: 400c6c // send signal: a.out-19844 [038] d.h. 8763.348613: send_sigio_to_task <-send_sigio a.out-19844 [038] d.h. 8763.348614: <stack trace> => send_sigio_to_task => send_sigio => kill_fasync_rcu => kill_fasync => perf_event_wakeup => perf_pending_event => irq_work_single => irq_work_run_list => irq_work_run => do_handle_IPI => ipi_handler => handle_percpu_devid_fasteoi_ipi => __handle_domain_irq => gic_handle_irq => el0_irq_naked a.out-19844 [038] d.h. 8763.348614: send_sigio_to_task: step in with signum 38 a.out-19844 [038] d.h. 8763.348615: send_sigio_to_task: will do_send_sig_info 38 // kernel signal handling: a.out-19844 [038] .... 8763.348616: do_notify_resume: thread_flags 2097665, _TIF_SIGPENDING 1, _TIF_NOTIFY_SIGNAL40 a.out-19844 [038] .... 8763.348617: setup_sigframe: restore sig: 400c6c // single step exception: a.out-19844 [038] d... 8763.348619: do_debug_exception: ec: 1, pc: 400988, pstate: 20001000 a.out-19844 [038] d... 8763.348621: hw_breakpoint_control: perf user addr: 400c6c, bp addr: 400c6c, ops: 1 // abnormal flow of exe: a.out-19844 [084] d... 8763.782103: hw_breakpoint_control: perf user addr: 400c6c, bp addr: 400c6c, ops: 0 // breakpoint exception: a.out-19844 [084] d... 8763.782104: do_debug_exception: ec: 0, pc: 400c6c, pstate: 20001000 // single step exception: a.out-19844 [084] d... 8763.782105: breakpoint_handler: perf bp read: 400c6c a.out-19844 [084] d... 8763.782107: do_debug_exception: ec: 1, pc: 400c70, pstate: 20001000 // send signal: a.out-19844 [084] d.h. 8763.782108: send_sigio_to_task <-send_sigio a.out-19844 [084] d.h. 8763.782109: <stack trace> => send_sigio_to_task => send_sigio => kill_fasync_rcu => kill_fasync => perf_event_wakeup => perf_pending_event => irq_work_single => irq_work_run_list => irq_work_run => do_handle_IPI => ipi_handler => handle_percpu_devid_fasteoi_ipi => __handle_domain_irq => gic_handle_irq => el0_irq_naked a.out-19844 [084] d.h. 8763.782110: send_sigio_to_task: step in with signum 38 a.out-19844 [084] d.h. 8763.782110: send_sigio_to_task: will do_send_sig_info 38 // kernel signal handling: a.out-19844 [084] .... 8763.782111: do_notify_resume: thread_flags 513, _TIF_SIGPENDING 1, _TIF_NOTIFY_SIGNAL40 a.out-19844 [084] .... 8763.782113: setup_sigframe: restore sig: 400c70 a.out-19844 [084] d... 8763.782115: hw_breakpoint_control: perf user addr: 400c6c, bp addr: 400c6c, ops: 1 Kernel sends this signal to task through pushing a perf_pending_event (which sends the signal) in irq_work_queue then triggering an IPI to let kernel handle this pended task. seems that when mismatch occurs, the IPI does not preempt the breakpoint exception it should preempt, causing no pending signals to be handled. In this way, there is no pending signals in do_notify_resume and kernel will not set up signal frame with correct pc value. Thanks, Chen

1 day, 21 hours

1
0
0 0

[PATCH v2 4/7] arm64: dts: ti: k3-j721e-sk: Add requiried voltage supplies for IMX219

by Yemike Abhilash Chandra

The device tree overlay for the IMX219 sensor requires three voltage supplies to be defined: VANA (analog), VDIG (digital core), and VDDL (digital I/O). Add the corresponding voltage supply definitions to avoid dtbs_check warnings. Fixes: f767eb918096 ("arm64: dts: ti: k3-j721e-sk: Add overlay for IMX219") Cc: stable(a)vger.kernel.org Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra(a)ti.com> --- .../dts/ti/k3-j721e-sk-csi2-dual-imx219.dtso | 33 +++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/arch/arm64/boot/dts/ti/k3-j721e-sk-csi2-dual-imx219.dtso b/arch/arm64/boot/dts/ti/k3-j721e-sk-csi2-dual-imx219.dtso index 4a395d1209c8..4eb3cffab032 100644 --- a/arch/arm64/boot/dts/ti/k3-j721e-sk-csi2-dual-imx219.dtso +++ b/arch/arm64/boot/dts/ti/k3-j721e-sk-csi2-dual-imx219.dtso @@ -19,6 +19,33 @@ clk_imx219_fixed: imx219-xclk { #clock-cells = <0>; clock-frequency = <24000000>; }; + + reg_2p8v: regulator-2p8v { + compatible = "regulator-fixed"; + regulator-name = "2P8V"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + vin-supply = <&vdd_sd_dv>; + regulator-always-on; + }; + + reg_1p8v: regulator-1p8v { + compatible = "regulator-fixed"; + regulator-name = "1P8V"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + vin-supply = <&vdd_sd_dv>; + regulator-always-on; + }; + + reg_1p2v: regulator-1p2v { + compatible = "regulator-fixed"; + regulator-name = "1P2V"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + vin-supply = <&vdd_sd_dv>; + regulator-always-on; + }; }; &csi_mux { @@ -34,6 +61,9 @@ imx219_0: imx219-0@10 { reg = <0x10>; clocks = <&clk_imx219_fixed>; + VANA-supply = <&reg_2p8v>; + VDIG-supply = <&reg_1p8v>; + VDDL-supply = <&reg_1p2v>; port { csi2_cam0: endpoint { @@ -55,6 +85,9 @@ imx219_1: imx219-1@10 { reg = <0x10>; clocks = <&clk_imx219_fixed>; + VANA-supply = <&reg_2p8v>; + VDIG-supply = <&reg_1p8v>; + VDDL-supply = <&reg_1p2v>; port { csi2_cam1: endpoint { -- 2.34.1

1 day, 22 hours

2
2
0 0

[PATCH] rust: kasan/kbuild: fix missing flags on first build

by Miguel Ojeda

If KASAN is enabled, and one runs in a clean repository e.g.: make LLVM=1 prepare make LLVM=1 prepare Then the Rust code gets rebuilt, which should not happen. The reason is some of the LLVM KASAN `rustc` flags are added in the second run: -Cllvm-args=-asan-instrumentation-with-call-threshold=10000 -Cllvm-args=-asan-stack=0 -Cllvm-args=-asan-globals=1 -Cllvm-args=-asan-kernel-mem-intrinsic-prefix=1 Further runs do not rebuild Rust because the flags do not change anymore. Rebuilding like that in the second run is bad, even if this just happens with KASAN enabled, but missing flags in the first one is even worse. The root issue is that we pass, for some architectures and for the moment, a generated `target.json` file. That file is not ready by the time `rustc` gets called for the flag test, and thus the flag test fails just because the file is not available, e.g.: $ ... --target=./scripts/target.json ... -Cllvm-args=... error: target file "./scripts/target.json" does not exist There are a few approaches we could take here to solve this. For instance, we could ensure that every time that the config is rebuilt, we regenerate the file and recompute the flags. Or we could use the LLVM version to check for these flags, instead of testing the flag (which may have other advantages, such as allowing us to detect renames on the LLVM side). However, it may be easier than that: `rustc` is aware of the `-Cllvm-args` regardless of the `--target` (e.g. I checked that the list printed is the same, plus that I can check for these flags even if I pass a completely unrelated target), and thus we can just eliminate the dependency completely. Thus filter out the target. This does mean that `rustc-option` cannot be used to test a flag that requires the right target, but we don't have other users yet, it is a minimal change and we want to get rid of custom targets in the future. We could only filter in the case `target.json` is used, to make it work in more cases, but then it would be harder to notice that it may not work in a couple architectures. Cc: Matthew Maurer <mmaurer(a)google.com> Cc: Sami Tolvanen <samitolvanen(a)google.com> Cc: stable(a)vger.kernel.org Fixes: e3117404b411 ("kbuild: rust: Enable KASAN support") Signed-off-by: Miguel Ojeda <ojeda(a)kernel.org> --- By the way, I noticed that we are not getting `asan-instrument-allocas` enabled in neither C nor Rust -- upstream LLVM renamed it in commit 8176ee9b5dda ("[asan] Rename asan-instrument-allocas -> asan-instrument-dynamic-allocas")). But it happened a very long time ago (9 years ago), and the addition in the kernel is fairly old too, in 342061ee4ef3 ("kasan: support alloca() poisoning"). I assume it should either be renamed or removed? Happy to send a patch if so. scripts/Makefile.compiler | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/Makefile.compiler b/scripts/Makefile.compiler index 8956587b8547..7ed7f92a7daa 100644 --- a/scripts/Makefile.compiler +++ b/scripts/Makefile.compiler @@ -80,7 +80,7 @@ ld-option = $(call try-run, $(LD) $(KBUILD_LDFLAGS) $(1) -v,$(1),$(2),$(3)) # TODO: remove RUSTC_BOOTSTRAP=1 when we raise the minimum GNU Make version to 4.4 __rustc-option = $(call try-run,\ echo '#![allow(missing_docs)]#![feature(no_core)]#![no_core]' | RUSTC_BOOTSTRAP=1\ - $(1) --sysroot=/dev/null $(filter-out --sysroot=/dev/null,$(2)) $(3)\ + $(1) --sysroot=/dev/null $(filter-out --sysroot=/dev/null --target=%,$(2)) $(3)\ --crate-type=rlib --out-dir=$(TMPOUT) --emit=obj=- - >/dev/null,$(3),$(4)) # rustc-option base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8 -- 2.49.0

1 day, 22 hours

4
4
0 0

[PATCH v1 1/2] platform/x86: int3472: add hpd pin support

by Dongcheng Yan

Typically HDMI to MIPI CSI-2 bridges have a pin to signal image data is being received. On the host side this is wired to a GPIO for polling or interrupts. This includes the Lontium HDMI to MIPI CSI-2 bridges lt6911uxe and lt6911uxc. The GPIO "hpd" is used already by other HDMI to CSI-2 bridges, use it here as well. Signed-off-by: Dongcheng Yan <dongcheng.yan(a)intel.com> --- drivers/platform/x86/intel/int3472/common.h | 1 + drivers/platform/x86/intel/int3472/discrete.c | 6 ++++++ 2 files changed, 7 insertions(+) diff --git a/drivers/platform/x86/intel/int3472/common.h b/drivers/platform/x86/intel/int3472/common.h index 145dec66df64..db4cd3720e24 100644 --- a/drivers/platform/x86/intel/int3472/common.h +++ b/drivers/platform/x86/intel/int3472/common.h @@ -22,6 +22,7 @@ #define INT3472_GPIO_TYPE_POWER_ENABLE 0x0b #define INT3472_GPIO_TYPE_CLK_ENABLE 0x0c #define INT3472_GPIO_TYPE_PRIVACY_LED 0x0d +#define INT3472_GPIO_TYPE_HOTPLUG_DETECT 0x13 #define INT3472_PDEV_MAX_NAME_LEN 23 #define INT3472_MAX_SENSOR_GPIOS 3 diff --git a/drivers/platform/x86/intel/int3472/discrete.c b/drivers/platform/x86/intel/int3472/discrete.c index 30ff8f3ea1f5..28d41b1b3809 100644 --- a/drivers/platform/x86/intel/int3472/discrete.c +++ b/drivers/platform/x86/intel/int3472/discrete.c @@ -186,6 +186,10 @@ static void int3472_get_con_id_and_polarity(struct acpi_device *adev, u8 *type, *con_id = "privacy-led"; *gpio_flags = GPIO_ACTIVE_HIGH; break; + case INT3472_GPIO_TYPE_HOTPLUG_DETECT: + *con_id = "hpd"; + *gpio_flags = GPIO_LOOKUP_FLAGS_DEFAULT; + break; case INT3472_GPIO_TYPE_POWER_ENABLE: *con_id = "power-enable"; *gpio_flags = GPIO_ACTIVE_HIGH; @@ -212,6 +216,7 @@ static void int3472_get_con_id_and_polarity(struct acpi_device *adev, u8 *type, * 0x0b Power enable * 0x0c Clock enable * 0x0d Privacy LED + * 0x13 Hotplug detect * * There are some known platform specific quirks where that does not quite * hold up; for example where a pin with type 0x01 (Power down) is mapped to @@ -281,6 +286,7 @@ static int skl_int3472_handle_gpio_resources(struct acpi_resource *ares, switch (type) { case INT3472_GPIO_TYPE_RESET: case INT3472_GPIO_TYPE_POWERDOWN: + case INT3472_GPIO_TYPE_HOTPLUG_DETECT: ret = skl_int3472_map_gpio_to_sensor(int3472, agpio, con_id, gpio_flags); if (ret) err_msg = "Failed to map GPIO pin to sensor\n"; base-commit: 01c6df60d5d4ae00cd5c1648818744838bba7763 -- 2.34.1

1 day, 22 hours

6
12
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror