* Re: [PATCH] firmware: imx: sm-misc: Add NULL check for kmalloc in syslog_show
From: Frank.Li @ 2026-06-29 20:41 UTC (permalink / raw)
To: s.hauer, imx, linux-kernel, kernel, festevam, peng.fan, shawnguo,
krzysztof.kozlowski, linux-arm-kernel, Li Jun
Cc: Frank Li
In-Reply-To: <20260610003814.75493-1-lijun01@kylinos.cn>
From: Frank Li <Frank.Li@nxp.com>
On Wed, 10 Jun 2026 08:38:14 +0800, Li Jun wrote:
> Add a proper NULL check for the kmalloc() return value in syslog_show().
> If memory allocation fails, syslog would be NULL and passing it to
> misc_syslog() could lead to a NULL pointer dereference.
Applied, thanks!
[1/1] firmware: imx: sm-misc: Add NULL check for kmalloc in syslog_show
commit: 4cf26bc2e7e099c86127d63ed7272753da45737e
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: (subset) [PATCH v5 0/2] media: nxp: imx8-isi: Add virtual channel and frame descriptor support
From: Laurent Pinchart @ 2026-06-29 20:23 UTC (permalink / raw)
To: Frank.Li
Cc: Mauro Carvalho Chehab, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Guoniu Zhou, Frank Li, Aisheng Dong, linux-media,
imx, linux-arm-kernel, linux-kernel, Guoniu Zhou
In-Reply-To: <178276214766.2429861.1950641421457268519.b4-ty@b4>
On Mon, Jun 29, 2026 at 03:42:31PM -0400, Frank.Li@oss.nxp.com wrote:
> From: Frank Li <Frank.Li@nxp.com>
>
>
> On Thu, 21 May 2026 17:10:03 +0800, Guoniu Zhou wrote:
> > This patch series enhances the i.MX ISI driver's with virtual channel
> > support and adds frame descriptor capabilities to the crossbar subdevice.
>
> Applied, thanks!
>
> [1/2] media: imx8-isi: crossbar: Add get_frame_desc operation
> commit: 3e15a3510908c990ee352aa206d5f9c23d4b216e
Is this a mistake ? Patch 1/2 has no R-b tag, and you're not listed as
maintainer for this driver.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v6 1/4] dt-bindings: arm: fsl: add TQMa8MPxS board
From: Frank.Li @ 2026-06-29 20:21 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Geert Uytterhoeven,
Magnus Damm, Shawn Guo, Alexander Stein
Cc: Frank Li, Paul Gerber, devicetree, linux-kernel, imx,
linux-arm-kernel, linux, linux-renesas-soc, Conor Dooley
In-Reply-To: <20260625051449.2560197-1-alexander.stein@ew.tq-group.com>
From: Frank Li <Frank.Li@nxp.com>
On Thu, 25 Jun 2026 07:14:44 +0200, Alexander Stein wrote:
> TQMa8MPxS is a SOM family using NXP i.MX8MP CPU family.
> MB-SMARC-2 is an evaluation mainbord for this SOM
>
> The SOM needs a mainboard, therefore we provide two compatibles here:
>
> "tq,imx8mp-<SOM>" for the module and
> "tq,imx8mp-<SOM>-<SBC>"
>
> [...]
Applied, thanks!
[1/4] dt-bindings: arm: fsl: add TQMa8MPxS board
commit: 4596f1624bf3abdc7782fbca0385bc0a8afb3d51
[2/4] arm64: dts: freescale: add initial device tree for TQMa8MPQS with i.MX8MP
commit: 6f0c003f0ddbfde3a311d350d2b3c1c38ac95dd4
[3/4] arm64: dts: freescale: add LVDS overlays for TQMa8MPxS
commit: 0d8c74f493e941ff61ce4dcfee75f2891bd44454
[4/4] arm64: dts: freescale: Add dual-channel LVDS overlay for TQMa8MPxS
commit: 3ee55e19db02d25d7c1155c3a6ab954aacfc55c5
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v4 1/4] dt-bindings: arm: fsl: add TQMa8MPxS board
From: Frank.Li @ 2026-06-29 20:21 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Geert Uytterhoeven,
Magnus Damm, Shawn Guo, Alexander Stein
Cc: Frank Li, Paul Gerber, devicetree, linux-kernel, imx,
linux-arm-kernel, linux, linux-renesas-soc, Conor Dooley
In-Reply-To: <20260603093621.2504490-1-alexander.stein@ew.tq-group.com>
From: Frank Li <Frank.Li@nxp.com>
On Wed, 03 Jun 2026 11:36:06 +0200, Alexander Stein wrote:
> TQMa8MPxS is a SOM family using NXP i.MX8MP CPU family.
> MB-SMARC-2 is an evaluation mainbord for this SOM
>
> The SOM needs a mainboard, therefore we provide two compatibles here:
>
> "tq,imx8mp-<SOM>" for the module and
> "tq,imx8mp-<SOM>-<SBC>"
>
> [...]
Applied, thanks!
[1/4] dt-bindings: arm: fsl: add TQMa8MPxS board
commit: 4596f1624bf3abdc7782fbca0385bc0a8afb3d51
[2/4] arm64: dts: freescale: add initial device tree for TQMa8MPQS with i.MX8MP
commit: 6f0c003f0ddbfde3a311d350d2b3c1c38ac95dd4
[3/4] arm64: dts: freescale: add LVDS overlays for TQMa8MPxS
commit: 0d8c74f493e941ff61ce4dcfee75f2891bd44454
[4/4] arm64: dts: freescale: Add dual-channel LVDS overlay for TQMa8MPxS
commit: 3ee55e19db02d25d7c1155c3a6ab954aacfc55c5
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: fsl: add TQMa8MPxS board
From: Frank.Li @ 2026-06-29 20:21 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Geert Uytterhoeven,
Magnus Damm, Shawn Guo, Alexander Stein
Cc: Frank Li, Paul Gerber, devicetree, linux-kernel, imx,
linux-arm-kernel, linux, linux-renesas-soc
In-Reply-To: <20260505063346.1799500-1-alexander.stein@ew.tq-group.com>
From: Frank Li <Frank.Li@nxp.com>
On Tue, 05 May 2026 08:33:43 +0200, Alexander Stein wrote:
> TQMa8MPxS is a SOM family using NXP i.MX8MP CPU family.
> MB-SMARC-2 is an evaluation mainbord for this SOM
>
> The SOM needs a mainboard, therefore we provide two compatibles here:
>
> "tq,imx8mp-<SOM>" for the module and
> "tq,imx8mp-<SOM>-<SBC>"
>
> [...]
Applied, thanks!
[1/2] dt-bindings: arm: fsl: add TQMa8MPxS board
commit: 4596f1624bf3abdc7782fbca0385bc0a8afb3d51
[2/2] arm64: dts: freescale: add initial device tree for TQMa8MPQS with i.MX8MP
commit: 6f0c003f0ddbfde3a311d350d2b3c1c38ac95dd4
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH] ARM: OMAP2+: Fix a reference leak bug in omap_hwmod_fix_mpu_rt_idx()
From: Kevin Hilman @ 2026-06-29 20:19 UTC (permalink / raw)
To: paul, aaro.koskinen, andreas, rogerq, tony, linux, Haoxiang Li
Cc: linux-omap, linux-arm-kernel, linux-kernel, stable
In-Reply-To: <20260623072534.1997680-1-haoxiang_li2024@163.com>
On Tue, 23 Jun 2026 15:25:34 +0800, Haoxiang Li wrote:
> omap_hwmod_fix_mpu_rt_idx() gets the first child node with
> of_get_next_child(), which returns a node with its reference count
> incremented. The function uses the child node to translate the MPU
> runtime register resource, but never drops the reference afterwards.
>
> Add the missing of_node_put() after of_address_to_resource().
>
> [...]
Applied, thanks!
[1/1] ARM: OMAP2+: Fix a reference leak bug in omap_hwmod_fix_mpu_rt_idx()
(no commit info)
Best regards,
--
Kevin Hilman (TI) <khilman@baylibre.com>
^ permalink raw reply
* Re: [PATCH] ARM: omap2plus_defconfig: enable things required by iwd
From: Kevin Hilman @ 2026-06-29 20:19 UTC (permalink / raw)
To: aaro.koskinen, rogerq, tony, linux, linux-omap, linux-arm-kernel,
linux-kernel, Andreas Kemnade
In-Reply-To: <20260616175152.1373709-1-andreas@kemnade.info>
On Tue, 16 Jun 2026 19:51:52 +0200, Andreas Kemnade wrote:
> Several crypto related things are missing for opreation of iwd, turn
> them on according to the list being printed out.
>
> :~# /usr/libexec/iwd &
> :~# No HMAC(SHA1) support found
> No HMAC(MD5) support found
> No CMAC(AES) support found
> No HMAC(SHA256) support not found
> No HMAC(SHA512) support found, certain TLS connections might fail
> DES support not found
> AES support not found
> No CBC(DES3_EDE) support found, certain TLS connections might fail
> No CBC(AES) support found, WPS will not be available
> No Diffie-Hellman support found, WPS will not be available
> The following options are missing in the kernel:
> CONFIG_CRYPTO_USER_API_HASH
> CONFIG_CRYPTO_USER_API_SKCIPHER
> CONFIG_KEY_DH_OPERATIONS
> CONFIG_CRYPTO_ECB
> CONFIG_CRYPTO_MD5
> CONFIG_CRYPTO_CBC
> CONFIG_CRYPTO_SHA256
> CONFIG_CRYPTO_AES
> CONFIG_CRYPTO_DES
> CONFIG_CRYPTO_CMAC
> CONFIG_CRYPTO_HMAC
> CONFIG_CRYPTO_SHA512
> CONFIG_CRYPTO_SHA1
>
> [...]
Applied, thanks!
[1/1] ARM: omap2plus_defconfig: enable things required by iwd
commit: 118c9c57c9a4b28209489521da229b58b43458ec
Best regards,
--
Kevin Hilman (TI) <khilman@baylibre.com>
^ permalink raw reply
* Re: [PATCH] ARM: dts: ti: Fix typos in comments
From: Kevin Hilman @ 2026-06-29 20:19 UTC (permalink / raw)
To: Bartosz Golaszewski, Tony Lindgren, Aaro Koskinen,
Andreas Kemnade, Roger Quadros, Vidhu Sarwal
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-omap,
linux-arm-kernel, devicetree, linux-kernel, skhan
In-Reply-To: <20260626111720.56688-1-vidhu.linux@gmail.com>
On Fri, 26 Jun 2026 16:47:20 +0530, Vidhu Sarwal wrote:
> Fix comment typos found with codespell across DaVinci and OMAP
> board files:
>
> limitaion -> limitation
> swithes -> switches
> converstion -> conversion
> differnet -> different
>
> [...]
Applied, thanks!
[1/1] ARM: dts: ti: Fix typos in comments
commit: 21e741f3922c40305d9225c7a3b2557e5d926cd4
Best regards,
--
Kevin Hilman (TI) <khilman@baylibre.com>
^ permalink raw reply
* Re: (subset) [PATCH v3 0/3] dt-bindings: mfd: syscon: Tighten checks
From: Kevin Hilman @ 2026-06-29 20:19 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Jacky Huang,
Shan-Chun Hung, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
Aaro Koskinen, Andreas Kemnade, Roger Quadros, Tony Lindgren,
Krzysztof Kozlowski
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
linux-renesas-soc, linux-rockchip, linux-omap
In-Reply-To: <20260608-n-dt-bindings-simple-bus-syscon-v3-0-4eba9ec1212a@oss.qualcomm.com>
On Mon, 08 Jun 2026 22:44:23 +0200, Krzysztof Kozlowski wrote:
> Changes in v3:
> - Drop patch #2:
> dt-bindings: mfd: syscon: Drop unneeded case for syscon + simple-mfd
> - Bump dtschema requirement
> - Link to v2: https://patch.msgid.link/20260608-n-dt-bindings-simple-bus-syscon-v2-0-0203e6c249dc@oss.qualcomm.com
>
> Changes in v2:
> 1. New patches #2 and #3
> 1. Add missing part of patch #1, thus not adding Rob's Ack.
> https://lore.kernel.org/all/20260531110404.12768-3-krzysztof.kozlowski@oss.qualcomm.com/
>
> [...]
Applied, thanks!
[3/3] ARM: dts: ti: Add specific compatibles for SCM conf nodes
commit: 68f994ec51e279e63c8fc40c1bfa8add4b708111
Best regards,
--
Kevin Hilman (TI) <khilman@baylibre.com>
^ permalink raw reply
* Re: [REGRESSION] mainline/master: Apalis iMX6 no longer boots
From: Frank Li @ 2026-06-29 20:18 UTC (permalink / raw)
To: Leonardo Costa
Cc: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
leonardo.costa, devicetree, imx, linux-arm-kernel, linux-kernel,
regressions
In-Reply-To: <20260629143439.361560-1-leoreis.costa@gmail.com>
On Mon, Jun 29, 2026 at 11:34:32AM -0300, Leonardo Costa wrote:
> Hello,
>
> We are seeing a regression on Apalis iMX6 where the kernel doesn't boot in the
> newest v7.2-rc1 (it was working before, in v7.1). The device tree being used is the imx6q-apalis-eval.dtb. The kernel
> configuration used is the one shown below:
>
> https://gist.github.com/lcosta37/53efdb2fb6e6e0fc05437c7e53b47737
>
> The kernel logs stop almost immediately as the board starts to boot, and I
> don't notice any difference in the logs that points to the cause.
>
> Is this known? We are seeing this behavior on all Apalis iMX6 modules, though
> we don't see it on Colibri iMX6, so it is not SoC-specific.
Can you help bisect to locate which commit cause this problem?
Frank
>
> Logs from v7.2-rc1 (not working, printing stops after the last line pasted
> here):
>
> [ 0.000000] Booting Linux on physical CPU 0x0
> [ 0.000000] Linux version 7.2.0-rc1-0.0.0-devel (oe-user@oe-host) (arm-tdx-linux-gnueabi-gcc (GCC) 16.1.0, GNU ld (GNU Binutils) 2.46.1) #1 SMP PREEMPT Sun Jun 28 19:01:31 UTC 2026
> [ 0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d
> [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> [ 0.000000] OF: fdt: Machine model: Toradex Apalis iMX6Q/D Module on Apalis Evaluation Board
> [ 0.000000] Memory policy: Data cache writealloc
> [ 0.000000] cma: Reserved 256 MiB at 0x40000000
> [ 0.000000] OF: reserved mem: Reserved memory: No reserved-memory node in the DT
> [ 0.000000] Zone ranges:
> [ 0.000000] Normal [mem 0x0000000010000000-0x000000003fffffff]
> [ 0.000000] HighMem [mem 0x0000000040000000-0x000000004fffffff]
> [ 0.000000] Movable zone start for each node
> [ 0.000000] Early memory node ranges
> [ 0.000000] node 0: [mem 0x0000000010000000-0x000000004fffffff]
> [ 0.000000] Initmem setup node 0 [mem 0x0000000010000000-0x000000004fffffff]
> [ 0.000000] percpu: Embedded 15 pages/cpu s28684 r8192 d24564 u61440
> [ 0.000000] Kernel command line: root=PARTUUID=adb2cea1-02 ro rootwait console=tty1 console=ttymxc0,115200
> [ 0.000000] printk: log buffer data + meta data: 131072 + 409600 = 540672 bytes
> [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
> [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
> [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 262144
> [ 0.000000] mem auto-init: stack:all(zero), heap alloc:off, heap free:off
> [ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
> [ 0.000000] rcu: Preemptible hierarchical RCU implementation.
> [ 0.000000] rcu: RCU event tracing is enabled.
> [ 0.000000] Trampoline variant of Tasks RCU enabled.
> [ 0.000000] Tracing variant of Tasks RCU enabled.
> [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
> [ 0.000000] RCU Tasks: Setting shift to 2 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=4.
> [ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
> [ 0.000000] L2C-310 errata 752271 769419 enabled
> [ 0.000000] L2C-310 enabling early BRESP for Cortex-A9
> [ 0.000000] L2C-310 full line of zeros enabled for Cortex-A9
> [ 0.000000] L2C-310 ID prefetch enabled, offset 16 lines
>
>
> Logs from v7.1 (working) (full logs here: https://paste.debian.net/hidden/0f65ae5f)
>
> [ 0.000000] Booting Linux on physical CPU 0x0
> [ 0.000000] Linux version 7.1.0-0.0.0-devel (oe-user@oe-host) (arm-tdx-linux-gnueabi-gcc (GCC) 16.1.0, GNU ld (GNU Binutils) 2.46.1) #1 SMP PREEMPT Wed Jun 24 01:36:41 UTC 2026
> [ 0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d
> [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> [ 0.000000] OF: fdt: Machine model: Toradex Apalis iMX6Q/D Module on Apalis Evaluation Board
> [ 0.000000] Memory policy: Data cache writealloc
> [ 0.000000] cma: Reserved 256 MiB at 0x40000000
> [ 0.000000] OF: reserved mem: Reserved memory: No reserved-memory node in the DT
> [ 0.000000] Zone ranges:
> [ 0.000000] Normal [mem 0x0000000010000000-0x000000003fffffff]
> [ 0.000000] HighMem [mem 0x0000000040000000-0x000000004fffffff]
> [ 0.000000] Movable zone start for each node
> [ 0.000000] Early memory node ranges
> [ 0.000000] node 0: [mem 0x0000000010000000-0x000000004fffffff]
> [ 0.000000] Initmem setup node 0 [mem 0x0000000010000000-0x000000004fffffff]
> [ 0.000000] percpu: Embedded 15 pages/cpu s28684 r8192 d24564 u61440
> [ 0.000000] pcpu-alloc: s28684 r8192 d24564 u61440 alloc=15*4096
> [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
> [ 0.000000] Kernel command line: root=PARTUUID=4ce4ba92-02 ro rootwait console=tty1 console=ttymxc0,115200
> [ 0.000000] printk: log buffer data + meta data: 131072 + 409600 = 540672 bytes
> [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
> [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
> [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 262144
> [ 0.000000] mem auto-init: stack:all(zero), heap alloc:off, heap free:off
> [ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
> [ 0.000000] rcu: Preemptible hierarchical RCU implementation.
> [ 0.000000] rcu: RCU event tracing is enabled.
> [ 0.000000] Trampoline variant of Tasks RCU enabled.
> [ 0.000000] Tracing variant of Tasks RCU enabled.
> [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
> [ 0.000000] RCU Tasks: Setting shift to 2 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=4.
> [ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
> [ 0.000000] L2C-310 errata 752271 769419 enabled
> [ 0.000000] L2C-310 enabling early BRESP for Cortex-A9
> [ 0.000000] L2C-310 full line of zeros enabled for Cortex-A9
> [ 0.000000] L2C-310 ID prefetch enabled, offset 16 lines
> [ 0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
> [ 0.000000] L2C-310 cache controller enabled, 16 ways, 1024 kB
> [ 0.000000] L2C-310: CACHE_ID 0x410000c7, AUX_CTRL 0x76470001
> [ 0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention.
> [ 0.000000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
> [ 0.000000] Switching to timer-based delay loop, resolution 333ns
> [ 0.000001] sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 715827882841ns
> [ 0.000018] clocksource: mxc_timer1: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 637086815595 ns
> [ 0.001910] Console: colour dummy device 80x30
> [ 0.001926] printk: legacy console [tty1] enabled
> [ 0.002519] Calibrating delay loop (skipped), value calculated using timer frequency.. 6.00 BogoMIPS (lpj=30000)
> [ 0.002561] CPU: Testing write buffer coherency: ok
> [ 0.002627] CPU0: Spectre v2: using BPIALL workaround
> [ 0.002650] pid_max: default: 32768 minimum: 301
> [ 0.002989] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
> [ 0.003038] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
> [ 0.003430] VFS: Finished mounting rootfs on nullfs
> [ 0.004538] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
> [ 0.006552] Setting up static identity map for 0x10100000 - 0x10100060
> [ 0.006835] rcu: Hierarchical SRCU implementation.
> [ 0.006864] rcu: Max phase no-delay instances is 1000.
> [ 0.007320] Timer migration: 1 hierarchy levels; 8 children per group; 1 crossnode level
> [ 0.008854] smp: Bringing up secondary CPUs ...
> [ 0.010035] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
> [ 0.010218] CPU1: Spectre v2: using BPIALL workaround
> [ 0.011412] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
> [ 0.011581] CPU2: Spectre v2: using BPIALL workaround
> [ 0.012747] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
> [ 0.012917] CPU3: Spectre v2: using BPIALL workaround
> [ 0.013109] smp: Brought up 1 node, 4 CPUs
> ...
>
^ permalink raw reply
* Re: [PATCH v1 1/3] clk: clocking-wizard: fix clock difference detection
From: Brian Masney @ 2026-06-29 20:12 UTC (permalink / raw)
To: Colin Foster
Cc: linux-kernel, linux-arm-kernel, linux-clk, Shubhrajyoti Datta,
Michal Simek, Stephen Boyd, Michael Turquette
In-Reply-To: <20260506200555.2558434-2-colin.foster@in-advantage.com>
Hi Colin,
On Wed, May 06, 2026 at 03:05:53PM -0500, Colin Foster wrote:
> The diff calculation didn't take into account rollover. As such, a
> target clock frequency below the requested rate would not be considered.
>
> Before this change, bogus diffs would be used to determine the closest
> possible clock:
>
> 8<--------
> clk-wizard-test: requesting 133312500 Hz on output 0 (clock NOT enabled)
> *** Clock wizard - Matching for rate 133312500 parent rate 99999000
> m = 33, d = 1, o = 25, freq = 131998680, diff = 18446744073708237796
> m = 34, d = 1, o = 26, freq = 130767923, diff = 18446744073707007039
> m = 35, d = 1, o = 26, freq = 134614038, diff = 1301538
> m = 36, d = 1, o = 27, freq = 133332000, diff = 19500
> 8<--------
>
> After this change:
>
> 8<--------
> clk-wizard-test: requesting 133312500 Hz on output 0 (clock NOT enabled)
> *** Clock wizard - Matching for rate 133312500 parent rate 99999000
> m = 33, d = 1, o = 25, freq = 131998680, diff = 1313820
> m = 35, d = 1, o = 26, freq = 134614038, diff = 1301538
> m = 36, d = 1, o = 27, freq = 133332000, diff = 19500
> 8<--------
>
> Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
> ---
> drivers/clk/xilinx/clk-xlnx-clock-wizard.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/xilinx/clk-xlnx-clock-wizard.c b/drivers/clk/xilinx/clk-xlnx-clock-wizard.c
> index 032a688840d8..88b47b8cc387 100644
> --- a/drivers/clk/xilinx/clk-xlnx-clock-wizard.c
> +++ b/drivers/clk/xilinx/clk-xlnx-clock-wizard.c
> @@ -408,7 +408,7 @@ static int clk_wzrd_get_divisors(struct clk_hw *hw, unsigned long rate,
> if (o < omin || o > omax)
> continue;
> freq = DIV_ROUND_CLOSEST_ULL(vco_freq, o);
> - diff = freq - rate;
> + diff = abs(freq - rate);
>
> if (diff < best_diff) {
> printk("m = %d, d = %d, o = %d, freq = %llu, diff = %llu", m, d, o, freq, diff);
Stephen didn't pick this up last development cycle and I'm assembling a
pull for him. This doesn't apply to upstream. Please post a new
version that applies cleanly.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/xilinx/clk-xlnx-clock-wizard.c#n341
Brian
^ permalink raw reply
* Re: [PATCH 0/2] ARM: imx: fix device_node refcount leaks in src.c
From: Frank.Li @ 2026-06-29 19:59 UTC (permalink / raw)
To: Shawn Guo, Weigang He
Cc: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260610050625.2229221-1-geoffreyhe2@gmail.com>
From: Frank Li <Frank.Li@nxp.com>
On Wed, 10 Jun 2026 15:06:23 +1000, Weigang He wrote:
> arch/arm/mach-imx/src.c leaks the device_node references taken by
> of_find_compatible_node() in two __init functions: imx_src_init() leaks
> the "fsl,imx51-src" node, and imx7_src_init() leaks the "fsl,imx7d-src"
> and "fsl,imx7d-gpc" nodes (the first one twice, because np is reused for
> the second lookup without a put). of_iomap() does not take ownership of
> the node, so these are one-shot device_node refcount leaks per boot.
>
> [...]
Applied, thanks!
[1/2] ARM: imx: fix device_node refcount leak in imx_src_init()
commit: 936407c3563ac745cbbb9953c0cf2472128a22f4
[2/2] ARM: imx: fix device_node refcount leaks in imx7_src_init()
commit: 3de939b2ac843d56d88e2ab1e1b1f667cba9e1d4
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v14 4/5] gpio: rpmsg: add generic rpmsg GPIO driver
From: Andrew Davis @ 2026-06-29 19:22 UTC (permalink / raw)
To: Shenwei Wang (OSS), Linus Walleij, Bartosz Golaszewski,
Jonathan Corbet, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Mathieu Poirier, Frank Li, Sascha Hauer
Cc: Shuah Khan, linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Pengutronix Kernel Team,
Fabio Estevam, Shenwei Wang, Peng Fan, devicetree@vger.kernel.org,
linux-remoteproc@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, dl-linux-imx,
Arnaud POULIQUEN, b-padhi@ti.com, Andrew Lunn,
Bartosz Golaszewski
In-Reply-To: <DB8PR04MB712990DF9806BBCF36B1076DC8E82@DB8PR04MB7129.eurprd04.prod.outlook.com>
On 6/29/26 1:26 PM, Shenwei Wang (OSS) wrote:
>
>
>> -----Original Message-----
>> From: Andrew Davis <afd@ti.com>
>> Sent: Thursday, June 25, 2026 3:32 PM
>
> ...
>> Subject: Re: [PATCH v14 4/5] gpio: rpmsg: add generic rpmsg GPIO driver
>>> + Say yes here to support the generic GPIO functions over the RPMSG
>>> + bus. Currently supported devices: i.MX7ULP, i.MX8ULP, i.MX8x, and
>>> + i.MX9x.
>>
>> The support would depend on if the right firmware is loaded/running on the given
>> remote core. Also if you want to make this generic, then any vendor should be
>> able to make a firmware that implements this protocol and make use of this
>> driver.
>> Suggest dropping this NXP specific device list.
>>
>
> Agree.
>
>>> +
>>> + If unsure, say N.
>>> +
>>> +endmenu
>>> +
>>> menu "SPI GPIO expanders"
>>> depends on SPI_MASTER
>>>
>>> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile index
>>> b267598b517d..ee75c0e65b8b 100644
>>> --- a/drivers/gpio/Makefile
>>> +++ b/drivers/gpio/Makefile
>>> @@ -157,6 +157,7 @@ obj-$(CONFIG_GPIO_RDC321X) += gpio-
>
> ...
>>> +
>>> +static int rpmsg_gpio_channel_probe(struct rpmsg_device *rpdev) {
>>> + struct device *dev = &rpdev->dev;
>>> + struct device_node *np;
>>> + const char *rproc_name;
>>> + int idx;
>>> +
>>> + idx = rpmsg_get_gpio_index(rpdev->id.name, CHAN_NAME_PREFIX);
>>> + if (idx < 0)
>>> + return -EINVAL;
>>> +
>>> + if (!dev->of_node) {
>>> + np = rpmsg_get_channel_ofnode(rpdev, GPIO_COMPAT_STR, idx);
>>> + if (!np)
>>> + return -ENODEV;
>>
>> This seems to imply that DT nodes are required. RPMSG is a discoverable bus
>> with a nameservice that can bind/probe new devices. While then optionally
>> binding to a DT node when available so sub-devices can be described in DT is fine,
>> I don't see why it should be required.
>>
>
> First, a GPIO node typically acts as a provider for other devices.
Not necessarily, there is a userspace API for interacting with GPIOs.
And there are ways to get/attach GPIO lines to other devices without DT.
> Second, by requiring a DT node, we can ensure that only explicitly enabled GPIO resources are managed and accessible.
Not sure I follow here, you have a firmware that provides GPIOs to Linux,
Linux should register those with the GPIO framework. Not sure why DT
is required to be involved. Some systems don't do DT, but they have
firmware and GPIOs.
I'm not saying if the system does use DT and has a node specifically
for this firmware/gpio then we shouldn't bind to that and use it,
just questioning making that "required".
Andrew
>
>>> +static struct rpmsg_driver rpmsg_gpio_channel_client = {
>>> + .callback = rpmsg_gpio_channel_callback,
>>> + .id_table = rpmsg_gpio_channel_id_table,
>>> + .probe = rpmsg_gpio_channel_probe,
>>> + .drv = {
>>> + .name = KBUILD_MODNAME,
>>> + .of_match_table = rpmsg_gpio_dt_ids,
>>
>> Does this line actually do anything anymore? Maybe it did when this was a
>> platform_driver, but this is a rpmsg_driver and will probe though .id_table
>> matches.
>>
>
> Yes, it can be removed because the driver will find the dt node on its own.
>
> Thanks,
> Shenwei
>
>> Andrew
>>
>>> + },
>>> +};
>>> +module_rpmsg_driver(rpmsg_gpio_channel_client);
>>> +
>>> +MODULE_AUTHOR("Shenwei Wang <shenwei.wang@nxp.com>");
>>> +MODULE_DESCRIPTION("generic rpmsg gpio driver");
>>> +MODULE_LICENSE("GPL");
>>
>
^ permalink raw reply
* Re: (subset) [PATCH v5 0/2] media: nxp: imx8-isi: Add virtual channel and frame descriptor support
From: Frank.Li @ 2026-06-29 19:42 UTC (permalink / raw)
To: Laurent Pinchart, Mauro Carvalho Chehab, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Guoniu Zhou
Cc: Frank Li, Aisheng Dong, linux-media, imx, linux-arm-kernel,
linux-kernel, Guoniu Zhou
In-Reply-To: <20260521-isi_vc-v5-0-a38eb4fcd58e@oss.nxp.com>
From: Frank Li <Frank.Li@nxp.com>
On Thu, 21 May 2026 17:10:03 +0800, Guoniu Zhou wrote:
> This patch series enhances the i.MX ISI driver's with virtual channel
> support and adds frame descriptor capabilities to the crossbar subdevice.
Applied, thanks!
[1/2] media: imx8-isi: crossbar: Add get_frame_desc operation
commit: 3e15a3510908c990ee352aa206d5f9c23d4b216e
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v2] media: dt-bindings: nxp,imx8mq-mipi-csi2: Fix example endpoint label typo
From: Frank.Li @ 2026-06-29 19:31 UTC (permalink / raw)
To: Robby Cai, Martin Kepplinger-Novakovic, Martin Kepplinger,
Rui Miguel Silva, Purism Kernel Team, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Laurent Pinchart
Cc: Frank Li, imx, linux-media, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260519113824.91533-1-laurent.pinchart@ideasonboard.com>
From: Frank Li <Frank.Li@nxp.com>
On Tue, 19 May 2026 13:38:23 +0200, Laurent Pinchart wrote:
> The example in imx8mq-mipi-csi2.yaml uses imx8mm_mipi_csi_{in,out}
> endpoint labels, which is confusing for an i.MX8MQ binding. The labels
> could be removed as they are not functionally required in the example,
> but they have a documentation purpose that brings value to the reader.
> Rename them mipi_csi_{in,out} to avoid the confusion.
>
>
> [...]
Applied, thanks!
[1/1] media: dt-bindings: nxp,imx8mq-mipi-csi2: Fix example endpoint label typo
commit: 733394c59684b8d16c5e4d26d6bf021a3a2d4bed
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: (subset) [PATCH v5 00/14] arm64: dts: imx8mp-var-som-symphony: align DTS with hardware revision
From: Frank.Li @ 2026-06-29 19:27 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel, Stefano Radaelli
Cc: Frank Li, pierluigi.p, Stefano Radaelli, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
In-Reply-To: <cover.1780929317.git.stefano.r@variscite.com>
From: Frank Li <Frank.Li@nxp.com>
On Mon, 08 Jun 2026 16:41:01 +0200, Stefano Radaelli wrote:
> This series updates the i.MX8MP VAR-SOM and Symphony device trees to
> better align them with the current hardware configuration.
>
> It adds the missing board peripherals and completes the related pinctrl,
> GPIO and bus configuration.
>
> v4->v5:
> - Add the SION (Software Input On) bit for the I2C recovery pins
> - Remove regulator-always-on and duplicated vddio node
>
> [...]
Applied, thanks!
[06/14] arm64: dts: imx8mp-var-som-symphony: enable PCIe
commit: dd7858bbdfa84beddf7d08bb82eacc8010221493
[07/14] arm64: dts: imx8mp-var-som-symphony: add HDMI support
commit: dfee5fefc3ecd29794c79b3f5284d759cfdc869e
[08/14] arm64: dts: imx8mp-var-som-symphony: add capacitive touchscreen
commit: 6651fb350bff74652edf8fdd2193ad33d69a968d
[09/14] arm64: dts: imx8mp-var-som-symphony: enable ECSPI2
commit: c0cb98e3230fd5959bb8075e059fef60d0477698
[10/14] arm64: dts: imx8mp-var-som-symphony: keep RGB_SEL low
commit: a062ace84151ca83d39e6470c0a23c51c0d343df
[11/14] arm64: dts: imx8mp-var-som-symphony: enable PWM1
commit: 2558c810a6d28614a8b076123762ff53f4acef5e
[12/14] arm64: dts: imx8mp-var-som-symphony: enable CAN
commit: 8d7fc066c18a99cd95226a660f4ddcf353d91bd8
[13/14] arm64: dts: imx8mp-var-som-symphony: add second Ethernet port
commit: 0bfd9e56f4868b66bdafed6a9f867629899bc199
[14/14] arm64: dts: freescale: imx8mp-var-som: add I2C1 bus recovery GPIOs
commit: 417b121ab93cd5a0929a663b9dc5da5595e290d3
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: (subset) [PATCH V3 0/8] PCI: imx6: Integrate pwrctrl API and update device trees
From: Frank Li @ 2026-06-29 19:07 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, s.hauer, kernel, festevam, lpieralisi,
kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach,
Sherry Sun (OSS)
Cc: Frank Li, imx, linux-pci, linux-arm-kernel, devicetree,
linux-kernel, sherry.sun
In-Reply-To: <178274988899.2274593.17371952702316181859.b4-ty@b4>
On Mon, Jun 29, 2026 at 12:18:15PM -0400, Frank.Li@oss.nxp.com wrote:
> From: Frank Li <Frank.Li@nxp.com>
>
>
> On Wed, 20 May 2026 16:48:56 +0800, Sherry Sun (OSS) wrote:
> > From: Sherry Sun <sherry.sun@nxp.com>
> >
> > This series integrates the PCI pwrctrl framework into the pci-imx6
> > driver and updates i.MX EVK board device trees to support it.
> >
> > Patches 2-8 update device trees for i.MX EVK boards which maintained
> > by NXP to move power supply properties from the PCIe controller node
> > to the Root Port child node, which is required for pwrctrl framework.
> > Affected boards:
> > - i.MX6Q/DL SABRESD
> > - i.MX6SX SDB
> > - i.MX8MM EVK
> > - i.MX8MP EVK
> > - i.MX8MQ EVK
> > - i.MX8DXL/QM/QXP EVK
> > - i.MX95 15x15/19x19 EVK
> >
> > [...]
>
> Applied, thanks!
>
> [2/8] arm: dts: imx6qdl-sabresd: Move power supply property to Root Port node
> commit: 6ae623838bba6b1d7dab2164bd12a166eae670b7
> [3/8] arm: dts: imx6sx-sdb: Move power supply property to Root Port node
> commit: 090ca78c5f5b8b475d51d729a7b79c5b7d8bbc47
Patches dropped since CHECK_DTBS warnings.
Frank
>
> Best regards,
> --
> Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v3 4/8] arm64: dts: qcom: shikra: Add Adreno SMMU node
From: Akhil P Oommen @ 2026-06-29 18:40 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Bibek Kumar Patro, linux-arm-msm, dri-devel, freedreno,
devicetree, linux-kernel, linux-arm-kernel, iommu, Imran Shaik,
Komal Bajaj, Rob Clark, Sean Paul, Konrad Dybcio,
Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang, Marijn Suijten,
David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Will Deacon, Robin Murphy, Joerg Roedel (AMD), Bjorn Andersson
In-Reply-To: <3ac0279b-105c-403a-90e8-822c28a6dcfc@oss.qualcomm.com>
On 6/29/2026 2:16 PM, Konrad Dybcio wrote:
> On 6/28/26 8:23 PM, Akhil P Oommen wrote:
>> From: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>>
>> Add the Adreno GPU IOMMU (adreno_smmu) node for the Shikra SoC.
>>
>> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
>> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
>
> Drop the sign-offs that don't apply (presumably applied as part
> of shuffling around the handlers of the patch in the in-flight
> tree OR missing c-d-b)
Ack. Thanks.
-Akhil.
>
>> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
>> ---
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
> Konrad
^ permalink raw reply
* RE: [PATCH v14 4/5] gpio: rpmsg: add generic rpmsg GPIO driver
From: Shenwei Wang (OSS) @ 2026-06-29 18:26 UTC (permalink / raw)
To: Andrew Davis, Linus Walleij, Bartosz Golaszewski, Jonathan Corbet,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Mathieu Poirier, Frank Li, Sascha Hauer
Cc: Shuah Khan, linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Pengutronix Kernel Team,
Fabio Estevam, Shenwei Wang, Peng Fan, devicetree@vger.kernel.org,
linux-remoteproc@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, dl-linux-imx,
Arnaud POULIQUEN, b-padhi@ti.com, Andrew Lunn,
Bartosz Golaszewski
In-Reply-To: <655ef1d6-08fd-43a9-8507-c2d478c058d8@ti.com>
> -----Original Message-----
> From: Andrew Davis <afd@ti.com>
> Sent: Thursday, June 25, 2026 3:32 PM
...
> Subject: Re: [PATCH v14 4/5] gpio: rpmsg: add generic rpmsg GPIO driver
> > + Say yes here to support the generic GPIO functions over the RPMSG
> > + bus. Currently supported devices: i.MX7ULP, i.MX8ULP, i.MX8x, and
> > + i.MX9x.
>
> The support would depend on if the right firmware is loaded/running on the given
> remote core. Also if you want to make this generic, then any vendor should be
> able to make a firmware that implements this protocol and make use of this
> driver.
> Suggest dropping this NXP specific device list.
>
Agree.
> > +
> > + If unsure, say N.
> > +
> > +endmenu
> > +
> > menu "SPI GPIO expanders"
> > depends on SPI_MASTER
> >
> > diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile index
> > b267598b517d..ee75c0e65b8b 100644
> > --- a/drivers/gpio/Makefile
> > +++ b/drivers/gpio/Makefile
> > @@ -157,6 +157,7 @@ obj-$(CONFIG_GPIO_RDC321X) += gpio-
...
> > +
> > +static int rpmsg_gpio_channel_probe(struct rpmsg_device *rpdev) {
> > + struct device *dev = &rpdev->dev;
> > + struct device_node *np;
> > + const char *rproc_name;
> > + int idx;
> > +
> > + idx = rpmsg_get_gpio_index(rpdev->id.name, CHAN_NAME_PREFIX);
> > + if (idx < 0)
> > + return -EINVAL;
> > +
> > + if (!dev->of_node) {
> > + np = rpmsg_get_channel_ofnode(rpdev, GPIO_COMPAT_STR, idx);
> > + if (!np)
> > + return -ENODEV;
>
> This seems to imply that DT nodes are required. RPMSG is a discoverable bus
> with a nameservice that can bind/probe new devices. While then optionally
> binding to a DT node when available so sub-devices can be described in DT is fine,
> I don't see why it should be required.
>
First, a GPIO node typically acts as a provider for other devices.
Second, by requiring a DT node, we can ensure that only explicitly enabled GPIO resources are managed and accessible.
> > +static struct rpmsg_driver rpmsg_gpio_channel_client = {
> > + .callback = rpmsg_gpio_channel_callback,
> > + .id_table = rpmsg_gpio_channel_id_table,
> > + .probe = rpmsg_gpio_channel_probe,
> > + .drv = {
> > + .name = KBUILD_MODNAME,
> > + .of_match_table = rpmsg_gpio_dt_ids,
>
> Does this line actually do anything anymore? Maybe it did when this was a
> platform_driver, but this is a rpmsg_driver and will probe though .id_table
> matches.
>
Yes, it can be removed because the driver will find the dt node on its own.
Thanks,
Shenwei
> Andrew
>
> > + },
> > +};
> > +module_rpmsg_driver(rpmsg_gpio_channel_client);
> > +
> > +MODULE_AUTHOR("Shenwei Wang <shenwei.wang@nxp.com>");
> > +MODULE_DESCRIPTION("generic rpmsg gpio driver");
> > +MODULE_LICENSE("GPL");
>
^ permalink raw reply
* Re: [PATCH v5 06/14] arm64: dts: imx8mp-var-som-symphony: enable PCIe
From: Frank Li @ 2026-06-29 18:25 UTC (permalink / raw)
To: Stefano Radaelli
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
In-Reply-To: <akKf_akO7IZ2ltHd@Lord-Beerus.station>
On Mon, Jun 29, 2026 at 06:40:29PM +0200, Stefano Radaelli wrote:
> Hi Frank,
>
> On Mon, Jun 29, 2026 at 12:30:09PM -0400, Frank Li wrote:
> >
> > You have to provide all clocks, otherwise, whole clocks and clock-names will
> > by overwrite with one clock "ref".
> >
> > suppose CHECK_DTBS should report warning about clocks items.
> >
> > Frank
> >
>
> thanks for checking.
>
> In this case the SoC dtsi does not provide any clocks or clock-names for
> the PCIe PHY node, so this is not overriding an existing clock list. It
> only adds the external reference clock used by the board.
>
> This follows the same pattern used by the i.MX8MP EVK, where the PCIe
> PHY node only provides the external "ref" clock together with
> fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>.
>
> This is also why CHECK_DTBS does not report any warnings for this node.
Oh! I missed think it is pcie node.
Frank
>
> $: sed -n '/^&pcie_phy {/,/^};/p' arch/arm64/boot/dts/freescale/imx8mp-evk.dts
> &pcie_phy {
> fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
> clocks = <&pcie0_refclk>;
> clock-names = "ref";
> status = "okay";
> };
>
> Thanks,
> Stefano
^ permalink raw reply
* Re: [PATCH v1 0/2] arm64: dts: imx8mm-var-som-symphony: minor board updates
From: Frank.Li @ 2026-06-29 18:20 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel, Stefano Radaelli
Cc: Frank Li, pierluigi.p, Stefano Radaelli, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
In-Reply-To: <cover.1780527068.git.stefano.r@variscite.com>
From: Frank Li <Frank.Li@nxp.com>
On Thu, 04 Jun 2026 00:53:58 +0200, Stefano Radaelli wrote:
> This series contains minor updates for the Variscite Symphony carrier
> board based on the current hardware configuration.
>
> It updates the RGB_SEL handling and marks the relevant input devices as
> wakeup sources.
>
> Stefano Radaelli (2):
> arm64: dts: imx8mm-var-som-symphony: add wakeup sources
> arm64: dts: imx8mm-var-som-symphony: keep RGB_SEL low
>
> [...]
Applied, thanks!
[1/2] arm64: dts: imx8mm-var-som-symphony: add wakeup sources
commit: b376fc7db933785a5a89446ed0748ebb7709c1c6
[2/2] arm64: dts: imx8mm-var-som-symphony: keep RGB_SEL low
commit: 7294b6214493075806a032227691781a2df94fc9
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v3 0/2] regulator: Rework i2c_device_id initialisation
From: Mark Brown @ 2026-06-29 18:10 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Liam Girdwood, Laurent Pinchart, Woodrow Douglass, linux-kernel,
Michael Hennerich, Support Opensource, Ivaylo Ivanov,
Claudiu Beznea, Saravanan Sekar, Matthias Brugger,
AngeloGioacchino Del Regno, Jagan Teki, Icenowy Zheng,
linux-arm-kernel, linux-mediatek
In-Reply-To: <cover.1781888370.git.u.kleine-koenig@baylibre.com>
[-- Attachment #1: Type: text/plain, Size: 430 bytes --]
On Fri, Jun 19, 2026 at 07:17:07PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> Hello,
>
> v2 is available at https://lore.kernel.org/lkml/cover.1779184320.git.u.kleine-koenig@baylibre.com .
>
> The only change is that I rebased to next-20260619 and dropped the
> adaptions to the of_regulator_match arrays that Laurent pointed out to
> not belong into this patch set.
This needs rebasing against current code.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2] MAINTAINERS: Update Xilinx AMS driver maintainers
From: Jonathan Cameron @ 2026-06-29 18:08 UTC (permalink / raw)
To: Michal Simek
Cc: Sai Krishna Potthuri, Conall O'Griofa, linux-iio,
linux-arm-kernel, linux-kernel
In-Reply-To: <0e4fc27a-9bef-4a78-9cc8-4d9c69c87773@amd.com>
On Mon, 29 Jun 2026 16:10:42 +0200
Michal Simek <michal.simek@amd.com> wrote:
> On 6/29/26 16:06, Sai Krishna Potthuri wrote:
> > Salih Erim is no longer with AMD to maintain the Xilinx AMS driver.
> > Replace Salih Erim with Sai Krishna Potthuri in the Xilinx AMS driver
> > MAINTAINERS entry for continued development and maintenance of the driver.
> >
> > Signed-off-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
> > ---
> > v2:
> > - Replaced Salih Erim with Sai Krishna Potthuri.
> >
> > MAINTAINERS | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 6b4560681b51..d8591066f182 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -29458,7 +29458,7 @@ F: include/uapi/linux/dqblk_xfs.h
> > F: include/uapi/linux/fsmap.h
> >
> > XILINX AMS DRIVER
> > -M: Salih Erim <salih.erim@amd.com>
> > +M: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
> > M: Conall O'Griofa <conall.ogriofa@amd.com>
> > L: linux-iio@vger.kernel.org
> > S: Maintained
>
> Acked-by: Michal Simek <michal.simek@amd.com>
Applied. I also picked up Conall's tag from v1
Thanks for taking over Sai and thanks to Salih for work
on this driver in the past.
Jonathan
>
> Thanks,
> Michal
^ permalink raw reply
* Re: [PATCH] arm64: Clarify ARM64_WORKAROUND_REPEAT_TLBI semantics
From: Vladimir Murzin @ 2026-06-29 18:05 UTC (permalink / raw)
To: Mark Rutland, linux-arm-kernel; +Cc: catalin.marinas, will
In-Reply-To: <20260629100953.385435-1-mark.rutland@arm.com>
Hi Mark,
On 6/29/26 11:09, Mark Rutland wrote:
> Will notes that the ARM64_WORKAROUND_REPEAT_TLBI name is potentially
> misleading, and that it would be nice to rename that and add some
> documentation. See:
>
> https://lore.kernel.org/linux-arm-kernel/ajKn_Pt50CmOUrsP@willie-the-truck/
>
> To that end, I've renamed the Kconfig symbol and hwcap from:
>
> [CONFIG_]ARM64_WORKAROUND_REPEAT_TLBI
>
> ... to:
>
> [CONFIG_]ARM64_WORKAROUND_REPEAT_TLBI_SYNC
>
> ... and I've added some rationale alongside the Kconfig. As the Kconfig
> symbol isn't user selectable, the usual 'help' section won't appear in
> menuconfig, so I've added this as a comment.
>
Although it won't appear in menuconfig, 3rd party tools that
index config symbols may still consume the help section.
I'm not sure how much we care about such tools...
Cheers
Vladimir
^ permalink raw reply
* Re: [PATCH v2 05/13] KVM: arm64: Detect (via ACPI) and initialize HACDBSIRQ
From: Oliver Upton @ 2026-06-29 17:22 UTC (permalink / raw)
To: Leonardo Bras
Cc: Catalin Marinas, Will Deacon, Marc Zyngier, Joey Gouly,
Steffen Eiden, Suzuki K Poulose, Zenghui Yu, Rafael J. Wysocki,
Len Brown, Saket Dumbre, Paolo Bonzini, Jonathan Cameron,
Chengwen Feng, Kees Cook, Mikołaj Lenczewski, James Morse,
Zeng Heng, mrigendrachaubey, Thomas Huth, Ryan Roberts,
Yeoreum Yun, Mark Brown, Kevin Brodsky, James Clark, Fuad Tabba,
Raghavendra Rao Ananta, Lorenzo Pieralisi, Sascha Bischoff,
Anshuman Khandual, Tian Zheng, linux-arm-kernel, linux-kernel,
kvmarm, linux-acpi, acpica-devel, kvm
In-Reply-To: <20260629111820.1873540-6-leo.bras@arm.com>
On Mon, Jun 29, 2026 at 12:17:53PM +0100, Leonardo Bras wrote:
> Find via ACPI [1] the Id for HACDBSIRQ, initialize it as a per-cpu IRQ
> and make sure any cpu able to run virtualization has it active.
>
> Introduce a per-cpu structure used by the HACDBSIRQ handler to keep track
> of entries size and the status of HACDBS. Size is used to detect end of
> processing in case the number of entries being processed is different of
> the supported entries size.
>
> Status may look easily replaceable by checking HACDBS registers now, but
> will make the OFF/IDLE detection easier in next patches.
>
> Signed-off-by: Leonardo Bras <leo.bras@arm.com>
>
> [1] https://github.com/tianocore/edk2/issues/12409
Reference the ACPI specification instead please. Any link you want to
include in a changelog should use the Link: footer, the linkage to the
inline citation will be obvious.
If we need to initialize the IRQ I'd really like to see device tree
bindings for HACDBSIRQ as well. Pretty much any system us plebs can get
our hands on is gonna be DT anyway.
> +static irqreturn_t hacdbsirq_handler(int irq, void *pcpu)
> +{
> + u64 cons = read_sysreg_s(SYS_HACDBSCONS_EL2);
> + unsigned long err = FIELD_GET(HACDBSCONS_EL2_ERR_REASON, cons);
> +
> + switch (err) {
> + case HACDBSCONS_EL2_ERR_REASON_NOF:
> + this_cpu_write(hacdbs_pcp.status, HACDBS_IDLE);
> + break;
> + case HACDBSCONS_EL2_ERR_REASON_IPAHACF:
> + /* When size not a power of two >= 4k, exit with reserved TTLW */
> + int index = FIELD_GET(HACDBSCONS_EL2_INDEX, cons);
> +
> + if (index >= this_cpu_read(hacdbs_pcp.size)) {
> + this_cpu_write(hacdbs_pcp.status, HACDBS_IDLE);
> + break;
> + }
> + fallthrough;
> + case HACDBSCONS_EL2_ERR_REASON_STRUCTF:
> + case HACDBSCONS_EL2_ERR_REASON_IPAF:
> + this_cpu_write(hacdbs_pcp.status, HACDBS_ERROR);
> + break;
> + }
> +
> + return IRQ_HANDLED;
> +}
I have a pretty extreme distaste for creating a state machine between
the callsite and the IRQ handler. The callsite should poll HACDBS for
completion. The thread has nothing better to do anyway.
Thanks,
Oliver
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox