July 2025 - Linux-stable-mirror

[for-linus][PATCH 2/2] tracing: Add down_write(trace_event_sem) when adding trace event

by Steven Rostedt

From: Steven Rostedt <rostedt(a)goodmis.org> When a module is loaded, it adds trace events defined by the module. It may also need to modify the modules trace printk formats to replace enum names with their values. If two modules are loaded at the same time, the adding of the event to the ftrace_events list can corrupt the walking of the list in the code that is modifying the printk format strings and crash the kernel. The addition of the event should take the trace_event_sem for write while it adds the new event. Also add a lockdep_assert_held() on that semaphore in __trace_add_event_dirs() as it iterates the list. Cc: stable(a)vger.kernel.org Cc: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Acked-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> Link: https://lore.kernel.org/20250718223158.799bfc0c@batman.local.home Reported-by: Fusheng Huang(黄富生) <Fusheng.Huang(a)luxshare-ict.com> Closes: https://lore.kernel.org/all/20250717105007.46ccd18f@batman.local.home/ Fixes: 110bf2b764eb6 ("tracing: add protection around module events unload") Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> --- kernel/trace/trace_events.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c index 120531268abf..d01e5c910ce1 100644 --- a/kernel/trace/trace_events.c +++ b/kernel/trace/trace_events.c @@ -3136,7 +3136,10 @@ __register_event(struct trace_event_call *call, struct module *mod) if (ret < 0) return ret; + down_write(&trace_event_sem); list_add(&call->list, &ftrace_events); + up_write(&trace_event_sem); + if (call->flags & TRACE_EVENT_FL_DYNAMIC) atomic_set(&call->refcnt, 0); else @@ -3750,6 +3753,8 @@ __trace_add_event_dirs(struct trace_array *tr) struct trace_event_call *call; int ret; + lockdep_assert_held(&trace_event_sem); + list_for_each_entry(call, &ftrace_events, list) { ret = __trace_add_new_event(call, tr); if (ret < 0) -- 2.47.2

1 week, 2 days

1
0
0 0

[for-linus][PATCH 1/2] tracing/osnoise: Fix crash in timerlat_dump_stack()

by Steven Rostedt

From: Tomas Glozar <tglozar(a)redhat.com> We have observed kernel panics when using timerlat with stack saving, with the following dmesg output: memcpy: detected buffer overflow: 88 byte write of buffer size 0 WARNING: CPU: 2 PID: 8153 at lib/string_helpers.c:1032 __fortify_report+0x55/0xa0 CPU: 2 UID: 0 PID: 8153 Comm: timerlatu/2 Kdump: loaded Not tainted 6.15.3-200.fc42.x86_64 #1 PREEMPT(lazy) Call Trace: <TASK> ? trace_buffer_lock_reserve+0x2a/0x60 __fortify_panic+0xd/0xf __timerlat_dump_stack.cold+0xd/0xd timerlat_dump_stack.part.0+0x47/0x80 timerlat_fd_read+0x36d/0x390 vfs_read+0xe2/0x390 ? syscall_exit_to_user_mode+0x1d5/0x210 ksys_read+0x73/0xe0 do_syscall_64+0x7b/0x160 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e __timerlat_dump_stack() constructs the ftrace stack entry like this: struct stack_entry *entry; ... memcpy(&entry->caller, fstack->calls, size); entry->size = fstack->nr_entries; Since commit e7186af7fb26 ("tracing: Add back FORTIFY_SOURCE logic to kernel_stack event structure"), struct stack_entry marks its caller field with __counted_by(size). At the time of the memcpy, entry->size contains garbage from the ringbuffer, which under some circumstances is zero, triggering a kernel panic by buffer overflow. Populate the size field before the memcpy so that the out-of-bounds check knows the correct size. This is analogous to __ftrace_trace_stack(). Cc: stable(a)vger.kernel.org Cc: John Kacur <jkacur(a)redhat.com> Cc: Luis Goncalves <lgoncalv(a)redhat.com> Cc: Attila Fazekas <afazekas(a)redhat.com> Link: https://lore.kernel.org/20250716143601.7313-1-tglozar@redhat.com Fixes: e7186af7fb26 ("tracing: Add back FORTIFY_SOURCE logic to kernel_stack event structure") Signed-off-by: Tomas Glozar <tglozar(a)redhat.com> Acked-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> --- kernel/trace/trace_osnoise.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/trace_osnoise.c b/kernel/trace/trace_osnoise.c index 6819b93309ce..fd259da0aa64 100644 --- a/kernel/trace/trace_osnoise.c +++ b/kernel/trace/trace_osnoise.c @@ -637,8 +637,8 @@ __timerlat_dump_stack(struct trace_buffer *buffer, struct trace_stack *fstack, u entry = ring_buffer_event_data(event); - memcpy(&entry->caller, fstack->calls, size); entry->size = fstack->nr_entries; + memcpy(&entry->caller, fstack->calls, size); trace_buffer_unlock_commit_nostack(buffer, event); } -- 2.47.2

1 week, 2 days

1
0
0 0

[PATCH v2] arm64: dts: apple: t8012-j132: Include touchbar framebuffer node

by Nick Chan

Apple T2 MacBookPro15,2 (j132) has a touchbar so include the framebuffer node. Cc: stable(a)vger.kernel.org Fixes: 4efbcb623e9bc ("arm64: dts: apple: Add T2 devices") Signed-off-by: Nick Chan <towinchenmi(a)gmail.com> --- Changes in v2: - CC stable list in Sign-off area. No content change. --- arch/arm64/boot/dts/apple/t8012-j132.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/apple/t8012-j132.dts b/arch/arm64/boot/dts/apple/t8012-j132.dts index 778a69be18dd81ab49076fb39ca4bc82f551e40f..7dcac51703ff60e0a6ef0929572a70adb65b580f 100644 --- a/arch/arm64/boot/dts/apple/t8012-j132.dts +++ b/arch/arm64/boot/dts/apple/t8012-j132.dts @@ -7,6 +7,7 @@ /dts-v1/; #include "t8012-jxxx.dtsi" +#include "t8012-touchbar.dtsi" / { model = "Apple T2 MacBookPro15,2 (j132)"; --- base-commit: e04c78d86a9699d136910cfc0bdcf01087e3267e change-id: 20250620-j132-fb-d7d5687d370d Best regards, -- Nick Chan <towinchenmi(a)gmail.com>

1 week, 2 days

2
1
0 0

[PATCH v3] char: xillybus: Fix error handling in xillybus_init_chrdev()

by Ma Ke

Use cdev_del() instead of direct kobject_put() when cdev_add() fails. This aligns with standard kernel practice and maintains consistency within the driver's own error paths. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 8cb5d216ab33 ("char: xillybus: Move class-related functions to new xillybus_class.c") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- Changes in v3: - modified the patch description, centralized cdev cleanup through standard API and maintained symmetry with driver's existing error handling; Changes in v2: - modified the patch as suggestions to avoid UAF. --- drivers/char/xillybus/xillybus_class.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/char/xillybus/xillybus_class.c b/drivers/char/xillybus/xillybus_class.c index c92a628e389e..e79cf9a0caa4 100644 --- a/drivers/char/xillybus/xillybus_class.c +++ b/drivers/char/xillybus/xillybus_class.c @@ -103,8 +103,7 @@ int xillybus_init_chrdev(struct device *dev, unit->num_nodes); if (rc) { dev_err(dev, "Failed to add cdev.\n"); - /* kobject_put() is normally done by cdev_del() */ - kobject_put(&unit->cdev->kobj); + cdev_del(unit->cdev); goto unregister_chrdev; } @@ -157,8 +156,6 @@ int xillybus_init_chrdev(struct device *dev, device_destroy(&xillybus_class, MKDEV(unit->major, i + unit->lowest_minor)); - cdev_del(unit->cdev); - unregister_chrdev: unregister_chrdev_region(MKDEV(unit->major, unit->lowest_minor), unit->num_nodes); -- 2.25.1

1 week, 2 days

2
1
0 0

[PATCH] arm64: dts: qcom: qcm2290: Disable USB SS bus instances in park mode

by Konrad Dybcio

From: Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com> 2290 was found in the field to also require this quirk, as long & high-bandwidth workloads (e.g. USB ethernet) are consistently able to crash the controller otherwise. The same change has been made for a number of SoCs in [1], but QCM2290 somehow escaped the list (even though the very closely related SM6115 was there). Upon a controller crash, the log would read: xhci-hcd.12.auto: xHCI host not responding to stop endpoint command xhci-hcd.12.auto: xHCI host controller not responding, assume dead xhci-hcd.12.auto: HC died; cleaning up Add snps,parkmode-disable-ss-quirk to the DWC3 instance in order to prevent the aforementioned breakage. [1] https://lore.kernel.org/all/20240704152848.3380602-1-quic_kriskura@quicinc.… Cc: stable(a)vger.kernel.org Reported-by: Rob Clark <robin.clark(a)oss.qualcomm.com> Fixes: a64a0192b70c ("arm64: dts: qcom: Add initial QCM2290 device tree") Signed-off-by: Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com> --- arch/arm64/boot/dts/qcom/qcm2290.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/qcom/qcm2290.dtsi b/arch/arm64/boot/dts/qcom/qcm2290.dtsi index fa24b77a31a7504020390522fabb0b783d897366..6b7070dad3df946649660eac1d087c0e8b6fe26d 100644 --- a/arch/arm64/boot/dts/qcom/qcm2290.dtsi +++ b/arch/arm64/boot/dts/qcom/qcm2290.dtsi @@ -1454,6 +1454,7 @@ usb_dwc3: usb@4e00000 { snps,has-lpm-erratum; snps,hird-threshold = /bits/ 8 <0x10>; snps,usb3_lpm_capable; + snps,parkmode-disable-ss-quirk; maximum-speed = "super-speed"; dr_mode = "otg"; usb-role-switch; --- base-commit: 26ffb3d6f02cd0935fb9fa3db897767beee1cb2a change-id: 20250708-topic-2290_usb-6632f12e5cd6 Best regards, -- Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com>

1 week, 2 days

2
1
0 0

[PATCH v2] usb: dwc3: qcom: Don't leave BCR asserted

by Krishna Kurapati

Leaving the USB BCR asserted prevents the associated GDSC to turn on. This blocks any subsequent attempts of probing the device, e.g. after a probe deferral, with the following showing in the log: [ 1.332226] usb30_prim_gdsc status stuck at 'off' Leave the BCR deasserted when exiting the driver to avoid this issue. Cc: stable(a)vger.kernel.org Fixes: a4333c3a6ba9 ("usb: dwc3: Add Qualcomm DWC3 glue driver") Acked-by: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> Reviewed-by: Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com> Signed-off-by: Krishna Kurapati <krishna.kurapati(a)oss.qualcomm.com> --- Changes in v2: Added Fixes tag and CC'd stable. Link to v1: https://lore.kernel.org/all/20250604060019.2174029-1-krishna.kurapati@oss.q… drivers/usb/dwc3/dwc3-qcom.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c index 7334de85ad10..ca7e1c02773a 100644 --- a/drivers/usb/dwc3/dwc3-qcom.c +++ b/drivers/usb/dwc3/dwc3-qcom.c @@ -680,12 +680,12 @@ static int dwc3_qcom_probe(struct platform_device *pdev) ret = reset_control_deassert(qcom->resets); if (ret) { dev_err(&pdev->dev, "failed to deassert resets, err=%d\n", ret); - goto reset_assert; + return ret; } ret = clk_bulk_prepare_enable(qcom->num_clocks, qcom->clks); if (ret < 0) - goto reset_assert; + return ret; r = platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!r) { @@ -755,8 +755,6 @@ static int dwc3_qcom_probe(struct platform_device *pdev) dwc3_core_remove(&qcom->dwc); clk_disable: clk_bulk_disable_unprepare(qcom->num_clocks, qcom->clks); -reset_assert: - reset_control_assert(qcom->resets); return ret; } @@ -771,7 +769,6 @@ static void dwc3_qcom_remove(struct platform_device *pdev) clk_bulk_disable_unprepare(qcom->num_clocks, qcom->clks); dwc3_qcom_interconnect_exit(qcom); - reset_control_assert(qcom->resets); } static int dwc3_qcom_pm_suspend(struct device *dev) -- 2.34.1

1 week, 2 days

2
1
0 0

[PATCH v2] Revert "arm64: dts: lx2160a: add pinmux and i2c gpio to support bus recovery"

by Josua Mayer

This reverts commit 8a1365c7bbc122bd843096f0008d259e7a8afc61. The commit in questions most notably breaks SD-Card on SolidRun LX2162A Clearfog by corrupting the pinmux in dynamic configuration area for non-i2c pins without pinmux node. It is further expected that it breaks SD Card-Detect, as well as CAN, DSPI and GPIOs on any board based on LX2160 SoC. Background: The LX2160 SoC is configured at power-on from RCW (Reset Configuration Word) typically located in the first 4k of boot media. This blob configures various clock rates and pin functions. The pinmux for i2c specifically is part of configuration words RCWSR12, RCWSR13 and RCWSR14 size 32 bit each. These values are accessible at read-only addresses 0x01e0012c following. For runtime (re-)configuration the SoC has a dynamic configuration area where alternative settings can be applied. The counterparts of RCWSR[12-14] can be overridden at 0x70010012c following. The commit in question used this area to switch i2c pins between i2c and gpio function at runtime using the pinctrl-single driver - which reads a 32-bit value, makes particular changes by bitmask and writes back the new value. SolidRun have observed that if the dynamic configuration is read first (before a write), it reads as zero regardless the initial values set by RCW. After the first write consecutive reads reflect the written value. Because multiple pins are configured from a single 32-bit value, this causes unintentional change of all bits (except those for i2c) being set to zero when the pinctrl driver applies the first configuration. See below a short list of which functions RCWSR12 alone controls: LX2162-CF RCWSR12: 0b0000100000000000 0000000000000110 IIC2_PMUX ||| ||| || | ||| |||XXX : I2C/GPIO/CD-WP IIC3_PMUX ||| ||| || | ||| XXX : I2C/GPIO/CAN/EVT IIC4_PMUX ||| ||| || | |||XXX||| : I2C/GPIO/CAN/EVT IIC5_PMUX ||| ||| || | XXX ||| : I2C/GPIO/SDHC-CLK IIC6_PMUX ||| ||| || |XXX||| ||| : I2C/GPIO/SDHC-CLK XSPI1_A_DATA74_PMUX ||| ||| XX X ||| ||| : XSPI/GPIO XSPI1_A_DATA30_PMUX ||| |||XXX|| | ||| ||| : XSPI/GPIO XSPI1_A_BASE_PMUX ||| XXX || | ||| ||| : XSPI/GPIO SDHC1_BASE_PMUX |||XXX||| || | ||| ||| : SDHC/GPIO/SPI SDHC1_DIR_PMUX XXX ||| || | ||| ||| : SDHC/GPIO/SPI RESERVED XX||| ||| || | ||| ||| : On LX2162A Clearfog the initial (ant intended) value is 0x08000006 - enabling card-detect on IIC2_PMUX and some LEDs on SDHC1_DIR_PMUX. Everything else is intentional zero (enabling I2C & XSPI). By reading zero from dynamic configuration area, the commit in question changes IIC2_PMUX to value 0 (I2C function), and SDHC1_DIR_PMUX to 0 (SDHC data direction function) - breaking card-detect and led gpios. This issue should affect any board based on LX2160 SoC that is using the same or earlier versions of NXP bootloader as SolidRun have tested, in particular: LSDK-21.08 and LS-5.15.71-2.2.0. Whether NXP added some extra initialisation in the bootloader on later releases was not investigated. However bootloader upgrade should not be necessary to run a newer Linux kernel. To work around this issue it is possible to explicitly define ALL pins controlled by any 32-bit value so that gradually after processing all pinctrl nodes the correct value is reached on all bits. This is a large task that should be done carefully on a per-board basis and not globally through the SoC dtsi. Therefore the commit in question is reverted. Fixes: 8a1365c7bbc1 ("arm64: dts: lx2160a: add pinmux and i2c gpio to support bus recovery") Cc: stable(a)vger.kernel.org Signed-off-by: Josua Mayer <josua(a)solid-run.com> --- Changes in v2: - changed to revert problematic commit, workaround is large effort - Link to v1: https://lore.kernel.org/r/f32c5525-3162-4acd-880c-99fc46d3a63d@solid-run.com --- arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 106 ------------------------- 1 file changed, 106 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi index c9541403bcd8..eb1b4e607e2b 100644 --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi @@ -749,10 +749,6 @@ i2c0: i2c@2000000 { clock-names = "ipg"; clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL QORIQ_CLK_PLL_DIV(16)>; - pinctrl-names = "default", "gpio"; - pinctrl-0 = <&i2c0_scl>; - pinctrl-1 = <&i2c0_scl_gpio>; - scl-gpios = <&gpio0 3 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; status = "disabled"; }; @@ -765,10 +761,6 @@ i2c1: i2c@2010000 { clock-names = "ipg"; clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL QORIQ_CLK_PLL_DIV(16)>; - pinctrl-names = "default", "gpio"; - pinctrl-0 = <&i2c1_scl>; - pinctrl-1 = <&i2c1_scl_gpio>; - scl-gpios = <&gpio0 31 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; status = "disabled"; }; @@ -781,10 +773,6 @@ i2c2: i2c@2020000 { clock-names = "ipg"; clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL QORIQ_CLK_PLL_DIV(16)>; - pinctrl-names = "default", "gpio"; - pinctrl-0 = <&i2c2_scl>; - pinctrl-1 = <&i2c2_scl_gpio>; - scl-gpios = <&gpio0 29 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; status = "disabled"; }; @@ -797,10 +785,6 @@ i2c3: i2c@2030000 { clock-names = "ipg"; clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL QORIQ_CLK_PLL_DIV(16)>; - pinctrl-names = "default", "gpio"; - pinctrl-0 = <&i2c3_scl>; - pinctrl-1 = <&i2c3_scl_gpio>; - scl-gpios = <&gpio0 27 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; status = "disabled"; }; @@ -813,10 +797,6 @@ i2c4: i2c@2040000 { clock-names = "ipg"; clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL QORIQ_CLK_PLL_DIV(16)>; - pinctrl-names = "default", "gpio"; - pinctrl-0 = <&i2c4_scl>; - pinctrl-1 = <&i2c4_scl_gpio>; - scl-gpios = <&gpio0 25 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; status = "disabled"; }; @@ -829,10 +809,6 @@ i2c5: i2c@2050000 { clock-names = "ipg"; clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL QORIQ_CLK_PLL_DIV(16)>; - pinctrl-names = "default", "gpio"; - pinctrl-0 = <&i2c5_scl>; - pinctrl-1 = <&i2c5_scl_gpio>; - scl-gpios = <&gpio0 23 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; status = "disabled"; }; @@ -845,10 +821,6 @@ i2c6: i2c@2060000 { clock-names = "ipg"; clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL QORIQ_CLK_PLL_DIV(16)>; - pinctrl-names = "default", "gpio"; - pinctrl-0 = <&i2c6_scl>; - pinctrl-1 = <&i2c6_scl_gpio>; - scl-gpios = <&gpio1 16 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; status = "disabled"; }; @@ -861,10 +833,6 @@ i2c7: i2c@2070000 { clock-names = "ipg"; clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL QORIQ_CLK_PLL_DIV(16)>; - pinctrl-names = "default", "gpio"; - pinctrl-0 = <&i2c7_scl>; - pinctrl-1 = <&i2c7_scl_gpio>; - scl-gpios = <&gpio1 18 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; status = "disabled"; }; @@ -1700,80 +1668,6 @@ pcs18: ethernet-phy@0 { }; }; - pinmux_i2crv: pinmux@70010012c { - compatible = "pinctrl-single"; - reg = <0x00000007 0x0010012c 0x0 0xc>; - #address-cells = <1>; - #size-cells = <0>; - pinctrl-single,bit-per-mux; - pinctrl-single,register-width = <32>; - pinctrl-single,function-mask = <0x7>; - - i2c1_scl: i2c1-scl-pins { - pinctrl-single,bits = <0x0 0 0x7>; - }; - - i2c1_scl_gpio: i2c1-scl-gpio-pins { - pinctrl-single,bits = <0x0 0x1 0x7>; - }; - - i2c2_scl: i2c2-scl-pins { - pinctrl-single,bits = <0x0 0 (0x7 << 3)>; - }; - - i2c2_scl_gpio: i2c2-scl-gpio-pins { - pinctrl-single,bits = <0x0 (0x1 << 3) (0x7 << 3)>; - }; - - i2c3_scl: i2c3-scl-pins { - pinctrl-single,bits = <0x0 0 (0x7 << 6)>; - }; - - i2c3_scl_gpio: i2c3-scl-gpio-pins { - pinctrl-single,bits = <0x0 (0x1 << 6) (0x7 << 6)>; - }; - - i2c4_scl: i2c4-scl-pins { - pinctrl-single,bits = <0x0 0 (0x7 << 9)>; - }; - - i2c4_scl_gpio: i2c4-scl-gpio-pins { - pinctrl-single,bits = <0x0 (0x1 << 9) (0x7 << 9)>; - }; - - i2c5_scl: i2c5-scl-pins { - pinctrl-single,bits = <0x0 0 (0x7 << 12)>; - }; - - i2c5_scl_gpio: i2c5-scl-gpio-pins { - pinctrl-single,bits = <0x0 (0x1 << 12) (0x7 << 12)>; - }; - - i2c6_scl: i2c6-scl-pins { - pinctrl-single,bits = <0x4 0x2 0x7>; - }; - - i2c6_scl_gpio: i2c6-scl-gpio-pins { - pinctrl-single,bits = <0x4 0x1 0x7>; - }; - - i2c7_scl: i2c7-scl-pins { - pinctrl-single,bits = <0x4 0x2 0x7>; - }; - - i2c7_scl_gpio: i2c7-scl-gpio-pins { - pinctrl-single,bits = <0x4 0x1 0x7>; - }; - - i2c0_scl: i2c0-scl-pins { - pinctrl-single,bits = <0x8 0 (0x7 << 10)>; - }; - - i2c0_scl_gpio: i2c0-scl-gpio-pins { - pinctrl-single,bits = <0x8 (0x1 << 10) (0x7 << 10)>; - }; - }; - fsl_mc: fsl-mc@80c000000 { compatible = "fsl,qoriq-mc"; reg = <0x00000008 0x0c000000 0 0x40>, --- base-commit: 19272b37aa4f83ca52bdf9c16d5d81bdd1354494 change-id: 20250710-lx2160-sd-cd-00bf38ae169e Best regards, -- Josua Mayer <josua(a)solid-run.com>

1 week, 2 days

2
2
0 0

[PATCH 1/4] dt-bindings: arm64: mediatek: add mt8395-evk-ufs board

by Macpaul Lin

Add a compatible string for the MediaTek mt8395-evk-ufs board. This board is the origin Genio 1200 EVK already mounted two main storages, one is eMMC, and the other is UFS. The system automatically prioritizes between eMMC and UFS via BROM detection, so user could not use both storage types simultaneously. As a result, mt8395-evk-ufs must be treated as a separate board. Signed-off-by: Macpaul Lin <macpaul.lin(a)mediatek.com> --- Documentation/devicetree/bindings/arm/mediatek.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml index a7e0a72f6e4c..cf8af943ab08 100644 --- a/Documentation/devicetree/bindings/arm/mediatek.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml @@ -437,6 +437,7 @@ properties: - enum: - kontron,3-5-sbc-i1200 - mediatek,mt8395-evk + - mediatek,mt8395-evk-ufs - radxa,nio-12l - const: mediatek,mt8395 - const: mediatek,mt8195 -- 2.45.2

1 week, 2 days

3
7
0 0

patch "iio: adc: ad7173: fix calibration channel" 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 iio: adc: ad7173: fix calibration channel 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 1d9a21ffb43b6fd326ead98f0d0afd6d104b739a Mon Sep 17 00:00:00 2001 From: David Lechner <dlechner(a)baylibre.com> Date: Tue, 8 Jul 2025 20:38:33 -0500 Subject: iio: adc: ad7173: fix calibration channel MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fix the channel index values passed to ad_sd_calibrate() in ad7173_calibrate_all(). ad7173_calibrate_all() expects these values to be that of the CHANNELx register assigned to the channel, not the datasheet INPUTx number of the channel. The incorrect values were causing register writes to fail for some channels because they set the WEN bit that must always be 0 for register access and set the R/W bit to read instead of write. For other channels, the channel number was just wrong because the CHANNELx registers are generally assigned in reverse order and so almost never match the INPUTx numbers. Fixes: 031bdc8aee01 ("iio: adc: ad7173: add calibration support") Signed-off-by: David Lechner <dlechner(a)baylibre.com> Reviewed-by: Nuno Sá <nuno.sa(a)analog.com> Link: https://patch.msgid.link/20250708-iio-adc-ad7313-fix-calibration-channel-v1… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/ad7173.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/iio/adc/ad7173.c b/drivers/iio/adc/ad7173.c index 1f9e91a2e3f9..2173455c0169 100644 --- a/drivers/iio/adc/ad7173.c +++ b/drivers/iio/adc/ad7173.c @@ -391,13 +391,12 @@ static int ad7173_calibrate_all(struct ad7173_state *st, struct iio_dev *indio_d if (indio_dev->channels[i].type != IIO_VOLTAGE) continue; - ret = ad_sd_calibrate(&st->sd, AD7173_MODE_CAL_INT_ZERO, st->channels[i].ain); + ret = ad_sd_calibrate(&st->sd, AD7173_MODE_CAL_INT_ZERO, i); if (ret < 0) return ret; if (st->info->has_internal_fs_calibration) { - ret = ad_sd_calibrate(&st->sd, AD7173_MODE_CAL_INT_FULL, - st->channels[i].ain); + ret = ad_sd_calibrate(&st->sd, AD7173_MODE_CAL_INT_FULL, i); if (ret < 0) return ret; } -- 2.50.1

1 week, 2 days

1
0
0 0

patch "iio: adc: ad7173: fix setting ODR in probe" 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 iio: adc: ad7173: fix setting ODR in probe 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 6fa908abd19cc35c205f343b79c67ff38dbc9b76 Mon Sep 17 00:00:00 2001 From: David Lechner <dlechner(a)baylibre.com> Date: Thu, 10 Jul 2025 15:43:40 -0500 Subject: iio: adc: ad7173: fix setting ODR in probe Fix the setting of the ODR register value in the probe function for AD7177. The AD7177 chip has a different ODR value after reset than the other chips (0x7 vs. 0x0) and 0 is a reserved value on that chip. The driver already has this information available in odr_start_value and uses it when checking valid values when writing to the sampling_frequency attribute, but failed to set the correct initial value in the probe function. Fixes: 37ae8381ccda ("iio: adc: ad7173: add support for additional models") Signed-off-by: David Lechner <dlechner(a)baylibre.com> Link: https://patch.msgid.link/20250710-iio-adc-ad7173-fix-setting-odr-in-probe-v… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/ad7173.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/iio/adc/ad7173.c b/drivers/iio/adc/ad7173.c index 2173455c0169..4413207be28f 100644 --- a/drivers/iio/adc/ad7173.c +++ b/drivers/iio/adc/ad7173.c @@ -1589,6 +1589,7 @@ static int ad7173_fw_parse_channel_config(struct iio_dev *indio_dev) chan_st_priv->cfg.bipolar = false; chan_st_priv->cfg.input_buf = st->info->has_input_buf; chan_st_priv->cfg.ref_sel = AD7173_SETUP_REF_SEL_INT_REF; + chan_st_priv->cfg.odr = st->info->odr_start_value; chan_st_priv->cfg.openwire_comp_chan = -1; st->adc_mode |= AD7173_ADC_MODE_REF_EN; if (st->info->data_reg_only_16bit) @@ -1655,7 +1656,7 @@ static int ad7173_fw_parse_channel_config(struct iio_dev *indio_dev) chan->scan_index = chan_index; chan->channel = ain[0]; chan_st_priv->cfg.input_buf = st->info->has_input_buf; - chan_st_priv->cfg.odr = 0; + chan_st_priv->cfg.odr = st->info->odr_start_value; chan_st_priv->cfg.openwire_comp_chan = -1; chan_st_priv->cfg.bipolar = fwnode_property_read_bool(child, "bipolar"); -- 2.50.1

1 week, 2 days

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2025