* Re: [PATCH] tty: n_gsm: fix NULL deref of gsm->dlci[0] in control message handlers
From: Weiming Shi @ 2026-06-12 14:19 UTC (permalink / raw)
To: Greg Kroah-Hartman, Weiming Shi
Cc: Jiri Slaby, Daniel Starke, linux-kernel, linux-serial, Xiang Mei
In-Reply-To: <2026061101-hanky-uninstall-da53@gregkh>
On Fri Jun 12, 2026 at 2:50 AM CST, Greg Kroah-Hartman wrote:
> On Thu, Jun 11, 2026 at 11:32:18AM -0700, Weiming Shi wrote:
>> gsm_control_command() and gsm_control_reply() load gsm->dlci[0] and
>> immediately dereference dlci->ftype without checking it for NULL.
>>
>> On the receive path, gsm_queue() validates that gsm->dlci[0] is non-NULL
>> and DLCI_OPEN before invoking the control handler, but the value is not
>> held across that check: the receive worker runs from flush_to_ldisc()
>> without taking gsm->mutex, while a concurrent GSMIOC_SETCONF ioctl can
>> enter gsm_cleanup_mux(), which takes gsm->mutex, releases gsm->dlci[0]
>> and sets it to NULL. If the mux is torn down between gsm_queue()'s check
>> and the re-load inside gsm_control_command()/gsm_control_reply(), the
>> handler dereferences a NULL dlci.
>>
>> A peer that drives DLCI 0 control frames (e.g. CMD_TEST) while the mux
>> owner reconfigures the line discipline can therefore crash the kernel
>> (line numbers from decode_stacktrace.sh against the crashing build):
>>
>> Oops: general protection fault, probably for non-canonical address
>> KASAN: null-ptr-deref in range [0x0000000000000208-0x000000000000020f]
>> RIP: 0010:gsm_control_reply (drivers/tty/n_gsm.c:1497)
>> Call Trace:
>> gsm_dlci_command (drivers/tty/n_gsm.c:2482)
>> gsm_queue.part.0 (drivers/tty/n_gsm.c:2852)
>> gsm0_receive (drivers/tty/n_gsm.c:2972)
>> gsmld_receive_buf (drivers/tty/n_gsm.c:3629)
>> tty_ldisc_receive_buf (drivers/tty/tty_buffer.c:391)
>> tty_port_default_receive_buf (drivers/tty/tty_port.c:39)
>> flush_to_ldisc (drivers/tty/tty_buffer.c:495)
>> process_one_work
>> worker_thread
>> kthread
>>
>> The other callers of these helpers (the keep-alive and negotiation timer
>> paths) already guard the gsm->dlci[0] access; only the receive path is
>> unguarded. The CMD_CLD handler in the same switch already checks the
>> loaded dlci for NULL for the very same reason. Bail out early when
>> gsm->dlci[0] has been cleared instead of dereferencing it.
>>
>> Triggering this requires CAP_NET_ADMIN to attach the n_gsm line
>> discipline (gsmld_open() uses capable(), not ns_capable()), so it is a
>> local denial of service for a privileged mux owner racing its own
>> control channel; harden the handlers regardless.
>>
>> Fixes: 5767712668b8 ("tty: n_gsm: cleanup gsm_control_command and gsm_control_reply")
>> Reported-by: Xiang Mei <xmei5@asu.edu>
>> Assisted-by: Claude:claude-opus-4-8
>> Signed-off-by: Weiming Shi <bestswngs@gmail.com>
>> ---
>> drivers/tty/n_gsm.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
>> index 214abeb89aaa..860cfb91d510 100644
>> --- a/drivers/tty/n_gsm.c
>> +++ b/drivers/tty/n_gsm.c
>> @@ -1457,6 +1457,9 @@ static int gsm_control_command(struct gsm_mux *gsm, int cmd, const u8 *data,
>> struct gsm_msg *msg;
>> struct gsm_dlci *dlci = gsm->dlci[0];
>>
>> + if (!dlci)
>> + return -EINVAL;
>
> What precents dlci from being NULL right after you check this?
>
> thanks,
>
> greg k-h
Hi greg,
I'm sorry for taking so long to respond.
After a closer look I think your review is correct.
The real problem is that the receive path touches gsm->dlci[] with no
lock. The teardown side holds gsm->mutex while it releases and frees the
dlci, but the receive worker does not: gsm_queue() loads
dlci = gsm->dlci[address] while it is still valid and passes it down
through dlci->data() to gsm_control_command()/gsm_control_reply(), which
also re-read gsm->dlci[0] and dereference dlci->ftype.
Meanwhile GSMIOC_SETCONF -> gsm_cleanup_mux() takes gsm->mutex, closes
DLCI0 and drops its reference via gsm_dlci_release(); the final
tty_port_put() runs the gsm_dlci_free() destructor, which clears the slot
and frees the object:
```
dlci->gsm->dlci[dlci->addr] = NULL;
kfree(dlci);
```
If that happens while the worker is still in the dispatch above, it ends
up dereferencing the freed dlci. I can reproduce this as a use-after-free:
```
[ 997.227486][ T46] BUG: KASAN: slab-use-after-free in gsm_control_reply.isra.0 (drivers/tty/n_gsm.c:1162 drivers/tty/n_gsm.c:1494)
[ 997.229052][ T46] Read of size 8 at addr ffff888029ae9000 by task kworker/u16:2/46
[ 997.230517][ T46]
[ 997.230952][ T46] CPU: 1 UID: 0 PID: 46 Comm: kworker/u16:2 Not tainted 7.1.0-rc7 #1 PREEMPT(full)
[ 997.230958][ T46] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-4
[ 997.230961][ T46] Workqueue: events_unbound flush_to_ldisc
[ 997.230969][ T46] Call Trace:
[ 997.230972][ T46] <TASK>
[ 997.230974][ T46] dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)
[ 997.230990][ T46] print_report (mm/kasan/report.c:378 mm/kasan/report.c:482)
[ 997.231008][ T46] kasan_report (mm/kasan/report.c:595)
[ 997.231016][ T46] gsm_control_reply.isra.0 (drivers/tty/n_gsm.c:1162 drivers/tty/n_gsm.c:1494)
[ 997.231020][ T46] gsm_dlci_command (drivers/tty/n_gsm.c:1873 drivers/tty/n_gsm.c:2477)
[ 997.231036][ T46] gsmld_receive_buf (drivers/tty/n_gsm.c:3616)
[ 997.231044][ T46] tty_ldisc_receive_buf (drivers/tty/tty_buffer.c:398)
[ 997.231052][ T46] tty_port_default_receive_buf (drivers/tty/tty_port.c:37)
[ 997.231056][ T46] flush_to_ldisc (drivers/tty/tty_buffer.c:452 drivers/tty/tty_buffer.c:502)
[ 997.231066][ T46] process_one_work (kernel/workqueue.c:3314)
[ 997.231082][ T46] worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478)
[ 997.231091][ T46] kthread (kernel/kthread.c:436)
[ 997.231103][ T46] ret_from_fork (arch/x86/kernel/process.c:158)
[ 997.231120][ T46] ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
[ 997.231128][ T46] </TASK>
[ 997.231130][ T46]
[ 997.267905][ T46] Allocated by task 5110:
[ 997.268716][ T46] kasan_save_stack (mm/kasan/common.c:57)
[ 997.269595][ T46] kasan_save_track (mm/kasan/common.c:78)
[ 997.270483][ T46] __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415)
[ 997.271353][ T46] gsm_dlci_alloc (./include/linux/slab.h:950 ./include/linux/slab.h:1188 drivers/tty/n_gsm.c:2648)
[ 997.272203][ T46] gsm_activate_mux (drivers/tty/n_gsm.c:3189)
[ 997.273109][ T46] gsmld_ioctl (drivers/tty/n_gsm.c:3443 drivers/tty/n_gsm.c:3846)
[ 997.273981][ T46] tty_ioctl (drivers/tty/tty_io.c:2801)
[ 997.274789][ T46] __x64_sys_ioctl (fs/ioctl.c:51 fs/ioctl.c:597 fs/ioctl.c:583 fs/ioctl.c:583)
[ 997.275682][ T46] do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
[ 997.276544][ T46] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
[ 997.277658][ T46]
[ 997.278108][ T46] Freed by task 5110:
[ 997.278865][ T46] kasan_save_stack (mm/kasan/common.c:57)
[ 997.279740][ T46] kasan_save_track (mm/kasan/common.c:78)
[ 997.280615][ T46] kasan_save_free_info (mm/kasan/generic.c:584)
[ 997.281554][ T46] __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285)
[ 997.282435][ T46] kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566)
[ 997.283159][ T46] gsm_cleanup_mux (drivers/tty/n_gsm.c:2711 drivers/tty/n_gsm.c:2744 drivers/tty/n_gsm.c:3161)
[ 997.284050][ T46] gsmld_ioctl (drivers/tty/n_gsm.c:3415 drivers/tty/n_gsm.c:3846)
[ 997.284928][ T46] tty_ioctl (drivers/tty/tty_io.c:2801)
[ 997.285746][ T46] __x64_sys_ioctl (fs/ioctl.c:51 fs/ioctl.c:597 fs/ioctl.c:583 fs/ioctl.c:583)
[ 997.286653][ T46] do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
[ 997.287526][ T46] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
[ 997.288639][ T46]
```
The NULL deref I reported is the same unguarded access on the same
path, just hitting the window after the slot is already cleared. Either
way a NULL check in the handlers can't fix it, since in the UAF case dlci
isn't NULL.
I think the fix should serialize the receive side against
gsm_cleanup_mux() instead of checking in the handlers. Two ways I can see:
1. take gsm->mutex around the dlci lookup and dispatch in gsm_queue(), or
2. pin the dlci across the dispatch using its existing tty_port ref
(dlci_get/dlci_put), so gsm_dlci_free() can't run while it's in use.
Do you have a preference, or is there a pattern in n_gsm you'd rather I
use? I'll respin v2 once I know which way to go.
And I'll send the reproducer and the config to trigger it in a separate mail.
Thanks,
Weiming
^ permalink raw reply
* Re: [PATCH] tty: serial: core: fix NULL pointer deref in uart_resume_port()
From: Greg Kroah-Hartman @ 2026-06-12 10:01 UTC (permalink / raw)
To: Weiming Shi; +Cc: Jiri Slaby, linux-kernel, linux-serial, Xiang Mei
In-Reply-To: <20260608165223.70148-1-bestswngs@gmail.com>
On Mon, Jun 08, 2026 at 09:52:17AM -0700, Weiming Shi wrote:
> uart_resume_port() looks up the tty device child with device_find_child()
> and passes the result straight to device_may_wakeup(). device_find_child()
> returns NULL when the port has no matching tty device child,
How can that happen in a real system? Have you triggered this before,
if so, what hardware does it?
> and
> device_may_wakeup() dereferences dev->power.can_wakeup, so a NULL tty_dev
> faults. uart_suspend_port() already guards the same call with
> "tty_dev && device_may_wakeup(tty_dev)"; the resume path does not.
>
> Oops: general protection fault, probably for non-canonical address
> KASAN: null-ptr-deref in range [0x148-0x14f]
> RIP: 0010:uart_resume_port (pm_wakeup.h:84 serial_core.c:2477)
> serial_pnp_resume (8250/8250_pnp.c:522)
> pnp_bus_resume (drivers/pnp/driver.c:234)
Is this a real oops, or a made up one?
> Mirror the NULL guard from uart_suspend_port(). put_device(tty_dev)
> already tolerates a NULL argument, so only the device_may_wakeup() call
> needs the check; the non-NULL path is unchanged.
>
> Fixes: b3b708fa2780 ("wake up from a serial port")
> Reported-by: Xiang Mei <xmei5@asu.edu>
Where was this reported?
Why isn't this cc: stable? And why hasn't anyone tripped over it in the
past 19 years?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v4] serial: 8250: fix use-after-free in IRQ chain handling
From: Greg Kroah-Hartman @ 2026-06-12 9:49 UTC (permalink / raw)
To: Qiliang Yuan
Cc: Jiri Slaby, Anton Vorontsov, Alan Cox, linux-kernel, linux-serial,
Wang Zhaolong
In-Reply-To: <20260529-bug-221579-8250-shared-irq-race-v4-1-cfda63b4420f@gmail.com>
On Fri, May 29, 2026 at 04:23:34PM +0800, Qiliang Yuan wrote:
> serial_unlink_irq_chain() holds hash_mutex and calls free_irq() + kfree(i)
> when it sees an empty port list. serial_link_irq_chain() released
> hash_mutex after serial_get_or_create_irq_info() but before acquiring
> i->lock. This gap allowed a concurrent unlink to observe list_empty()
> as true while a new port was still being added, free i, and trigger a
> use-after-free.
>
> Dropping hash_mutex before request_irq() completes also allows another
> port sharing the same IRQ to join the chain and run the shared-IRQ THRE
> test while IRQ startup is still in progress, which can also trigger the
> "Unbalanced enable for IRQ" warning (kernel/irq/manage.c:774) because
> irq_shutdown() in the premature free_irq() path increments desc->depth,
> breaking the disable_irq/enable_irq pairing in serial8250_THRE_test().
>
> Fix by pulling hash_mutex into serial_link_irq_chain() and holding it
> across the first request_irq() completion (including the error path)
> so that no concurrent unlink or second-port join can race with IRQ
> setup or cleanup.
> serial_unlink_irq_chain() already holds hash_mutex throughout, so the
> race window is closed.
What real systems causes this to happen? How are you triggering this
warning to happen? How was this tested?
>
> Fixes: 768aec0b5bcc ("serial: 8250: fix shared interrupts issues with SMP and RT kernels")
> Reported-by: Wang Zhaolong <wangzhaolong@fnnas.com>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221579
> Signed-off-by: Qiliang Yuan <realwujing@gmail.com>
> ---
> V3 -> V4:
> - Move cleanup under hash_mutex on request_irq() failure to prevent a
> second port from joining the chain before the irq_info is cleaned up.
> - Fix inaccurate description of irq_shutdown() in commit message.
>
> V2 -> V3:
> - Hold hash_mutex across the first request_irq() completion to prevent a
> second port from joining the chain and running the shared-IRQ THRE test
> while IRQ startup is still in progress.
>
> V1 -> V2:
> - Add Reported-by tag from Wang Zhaolong.
>
> v3: https://lore.kernel.org/r/20260529-bug-221579-8250-shared-irq-race-v3-1-fe4d430862a9@gmail.com
> v2: https://lore.kernel.org/r/20260528-bug-221579-8250-shared-irq-race-v2-1-06531202e54d@gmail.com
> v1: https://lore.kernel.org/r/20260528-bug-221579-8250-shared-irq-race-v1-1-30980cca02f3@gmail.com
> ---
> drivers/tty/serial/8250/8250_core.c | 55 ++++++++++++++++++++++++++++---------
> 1 file changed, 42 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
> index a428e88938eb7..70d5acfa591bf 100644
> --- a/drivers/tty/serial/8250/8250_core.c
> +++ b/drivers/tty/serial/8250/8250_core.c
> @@ -134,7 +134,7 @@ static struct irq_info *serial_get_or_create_irq_info(const struct uart_8250_por
> {
> struct irq_info *i;
>
> - guard(mutex)(&hash_mutex);
> + lockdep_assert_held(&hash_mutex);
Shouldn't the function be marked as requiring this lock to be held?
Just putting in this lockdep_assert will not catch the static analysis
tools :(
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v6 6/9] dt-bindings: connector: m2: Add M.2 1620 LGA soldered down connector
From: Dmitry Baryshkov @ 2026-06-12 7:50 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Stephan Gerhold, Mark Pearson, Rob Herring, Manivannan Sadhasivam,
Greg KH, Jiri Slaby, Nathan Chancellor, Nicolas Schier,
Hans de Goede, Ilpo Järvinen, Derek J . Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Andy Shevchenko,
Bartosz Golaszewski, linux-serial, linux-kernel, linux-kbuild,
platform-driver-x86@vger.kernel.org, linux-pci, devicetree,
linux-arm-msm, linux-bluetooth, linux-pm,
linux-acpi@vger.kernel.org
In-Reply-To: <eftahohsx3bbvmgxuciofjjcrybnsm2qc752hwyt65rb2uwaon@h32nh5fcpo7p>
On Wed, Jun 10, 2026 at 06:44:59PM +0200, Manivannan Sadhasivam wrote:
> On Tue, Mar 31, 2026 at 06:29:51PM +0200, Stephan Gerhold wrote:
> > On Wed, Mar 25, 2026 at 05:36:08PM +0530, Manivannan Sadhasivam wrote:
> > > On Mon, Mar 23, 2026 at 01:23:07PM -0400, Mark Pearson wrote:
> > > > On Mon, Mar 23, 2026, at 12:52 PM, Manivannan Sadhasivam wrote:
> > > > > On Mon, Mar 23, 2026 at 06:45:15PM +0200, Dmitry Baryshkov wrote:
> > > > >> On Mon, Mar 23, 2026 at 09:26:04PM +0530, Manivannan Sadhasivam wrote:
> > > > >> > On Mon, Mar 23, 2026 at 05:14:30PM +0200, Dmitry Baryshkov wrote:
> > > > >> > > On Mon, Mar 23, 2026 at 07:14:25PM +0530, Manivannan Sadhasivam wrote:
> > > > >> > > > On Mon, Mar 23, 2026 at 08:39:55AM -0500, Rob Herring wrote:
> > > > >> > > > > On Mon, Mar 23, 2026 at 7:16 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > >> > > > > >
> > > > >> > > > > > On Sun, Mar 22, 2026 at 06:37:13PM -0500, Rob Herring wrote:
> > > > >> > > > > > > On Tue, Mar 17, 2026 at 09:59:56AM +0530, Manivannan Sadhasivam wrote:
> > > > >> > > > > > > > Lenovo Thinkpad T14s is found to have a soldered down version of M.2 1620
> > > > >> > > > > > > > LGA connector. Though, there is no 1620 LGA form factor defined in the M.2
> > > > >> > > > > > > > spec, it looks very similar to the M.2 Key E connector. So add the
> > > > >> > > > > > > > "pcie-m2-1620-lga-connector" compatible with "pcie-m2-e-connector" fallback
> > > > >> > > > > > > > to reuse the Key E binding.
> > > > >> > > > > > >
> > > > >> > > > > > > What is LGA?
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > > > Land Grid Array
> > > > >> > > > > >
> > > > >> > > > > > > If not in the spec, is it really something generic?
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > > > Good question. Yes and No! LGA is not something that Lenovo only uses. Other
> > > > >> > > > > > vendors may also use this form factor. PCIe connectors are full of innovation as
> > > > >> > > > > > the spec gives room for hardware designers to be as innovative as possible to
> > > > >> > > > > > save the BOM cost.
> > > > >> > > > >
> > > > >> > > > > innovation == incompatible changes
> > > > >> > > > >
> > > > >> > > >
> > > > >> > > > Yes, I was trying to sound nice :)
> > > > >> > > >
> > > > >> > > > > > This is why I do not want to make it Lenovo specific. But if you prefer that, I
> > > > >> > > > > > can name it as "lenovo,pcie-m2-1620-lga-connector".
> > > > >> > > > >
> > > > >> > > > > Depends if you think that s/w needs to know the differences. Hard to
> > > > >> > > > > say with a sample size of 1.
> > > > >> > > > >
> > > > >> > > >
> > > > >> > > > Sure. Will add the 'lenovo' prefix then.
> > > > >> > >
> > > > >> > > Is it really Lenovo? Or is it some other module vendor, whose LGAs are
> > > > >> > > being used by Lenovo?
> > > > >> > >
> > > > >> > > I remember that DB820c also used some kind of a module for the WiFi card
> > > > >> > > (which might be M.2 compatible or might not, I can't find exact docs at
> > > > >> > > this point).
> > > > >> > >
> > > > >> >
> > > > >> > I don't know. These kind of designs might be reused by several vendors. But
> > > > >> > considering that we should not make it generic, I'd go with Lenovo as that's
> > > > >> > the only vendor we know as of now.
> > > > >>
> > > > >> ... and later we learn that other vendors use the same idea /pinout,
> > > > >> then nothing stops us from still telling that it's a
> > > > >> "lenovo,pcie-m2-something-lga".
> > > > >>
> > > > >
> > > > > How do you possibly know whether a single vendor has introduced this form factor
> > > > > or reused by multiple ones? Atleast, I don't have access to such a source to
> > > > > confirm.
> > > > >
> > > > I've not really been following this thread/patchset in detail; but want me to try and check with the T14s platform team if this device is specifically made for us (Lenovo) or not?
> > > > I doubt it is - we just don't do that usually, but I can go and ask the question if it will help resolve this (with the caveat that it could hold up the review for a bit and I may not be able to get a straight answer)
> > > >
> > >
> > > I can drop this specific patch in the meantime.
> > >
> > > > My vote (for what little it's worth) would be to make it non-Lenovo specific. Then when the same part causes issues on another vendors platform I won't get asked questions about why Lenovo is breaking <other vendor> :)
> > > >
> > >
> > > Even if Lenovo prefix is used, it won't break other vendors. Just that we will
> > > end up adding more compatibles.
> > >
> > > Anyhow, I'll wait for your reply and drop this patch for next revision.
> > >
> >
> > If you need a vendor prefix, I think "qcom," would be more appropriate
> > than Lenovo. This form factor is used by most vendors for recent
> > soldered Qualcomm-based wireless cards, not just Lenovo:
> >
> > - Dell XPS 13 9345 has exactly the same soldered M.2 card, I assume
> > there are several other vendors as well.
> >
> > - https://www.sparklan.com/product/wnsq-290be/ is a third-party
> > (Qualcomm-based) M.2 LGA 1620 card, in the block diagram the
> > pinout is called "QM.2 1620 LGA 168pin".
> >
> > - If you press F9 while booting the ThinkPad T14s, you should get to a
> > screen with "Regulatory Information". For the T14s, this screen says
> > "Contains FCC ID: J9C-QCNCM825". This is the WiFi/BT module in the
> > soldered form factor. If you look that up on the FCC website, the
> > applicant for this module is "Qualcomm Technologies, Inc.". This
> > seems to be some kind of "modular certification" that vendors can
> > reuse/adapt without going through the whole process again.
> >
> > Perhaps you should ask around inside Qualcomm? :-)
> >
>
> Sorry for getting back after this long. I did ask around, but our HW folks are
> saying that Qcom is not the first one to use LGA M.2 modules. They claim that
> other vendors also do that.
I think, the idea was that there is no single standard for LGA modules
(please correct me if I'm wrong, I haven't checked the latest PCIe
standards).
>
> But for this specific card, it should be fine to use the 'qcom' prefix as
> apparently the module was supplied by Qcom.
>
> I'll submit the bindings patch together with DTS change for T14s.
>
> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்
--
With best wishes
Dmitry
^ permalink raw reply
* 8250_dw system pause due to IRQ load
From: Craig McQueen @ 2026-06-12 5:38 UTC (permalink / raw)
To: linux-serial@vger.kernel.org
I have a Rockchip RK3328 based embedded Linux system, using the 8250_dw driver (device tree "snps,dw-apb-uart") for serial console and other serial ports. I'm using Yocto scarthgap with kernel v6.6.123.
It is talking to a microprocessor via a serial protocol at 921600 bps. Multiple times per hour, I see the serial protocol TX pause for 100 to 4500 ms. Usually the whole Linux system pauses during this time (realtime and monotonic clocks don't tick). mpstat shows high irq load. /proc/interrupts shows the 8250_dw interrupt count is going significantly higher during this time.
I'm also seeing complete system lock-ups occur every 1 to 72 hours, with no diagnostic information shown in the kernel serial console output.
Are there any known issues with the 8250_dw interrupt handler causing high CPU load, that I should try backporting to kernel v6.6?
I've written some kernel drivers, but I have no experience debugging interrupt handler issues, especially when it's an issue that prevents the kernel doing console output. I would appreciate any advice on kernel facilities that are suitable to debug this type of bug.
--
Craig McQueen
^ permalink raw reply
* Re: [PATCH] tty: n_gsm: fix NULL deref of gsm->dlci[0] in control message handlers
From: Greg Kroah-Hartman @ 2026-06-11 18:50 UTC (permalink / raw)
To: Weiming Shi
Cc: Jiri Slaby, Daniel Starke, linux-kernel, linux-serial, Xiang Mei
In-Reply-To: <20260611183217.2488508-2-bestswngs@gmail.com>
On Thu, Jun 11, 2026 at 11:32:18AM -0700, Weiming Shi wrote:
> gsm_control_command() and gsm_control_reply() load gsm->dlci[0] and
> immediately dereference dlci->ftype without checking it for NULL.
>
> On the receive path, gsm_queue() validates that gsm->dlci[0] is non-NULL
> and DLCI_OPEN before invoking the control handler, but the value is not
> held across that check: the receive worker runs from flush_to_ldisc()
> without taking gsm->mutex, while a concurrent GSMIOC_SETCONF ioctl can
> enter gsm_cleanup_mux(), which takes gsm->mutex, releases gsm->dlci[0]
> and sets it to NULL. If the mux is torn down between gsm_queue()'s check
> and the re-load inside gsm_control_command()/gsm_control_reply(), the
> handler dereferences a NULL dlci.
>
> A peer that drives DLCI 0 control frames (e.g. CMD_TEST) while the mux
> owner reconfigures the line discipline can therefore crash the kernel
> (line numbers from decode_stacktrace.sh against the crashing build):
>
> Oops: general protection fault, probably for non-canonical address
> KASAN: null-ptr-deref in range [0x0000000000000208-0x000000000000020f]
> RIP: 0010:gsm_control_reply (drivers/tty/n_gsm.c:1497)
> Call Trace:
> gsm_dlci_command (drivers/tty/n_gsm.c:2482)
> gsm_queue.part.0 (drivers/tty/n_gsm.c:2852)
> gsm0_receive (drivers/tty/n_gsm.c:2972)
> gsmld_receive_buf (drivers/tty/n_gsm.c:3629)
> tty_ldisc_receive_buf (drivers/tty/tty_buffer.c:391)
> tty_port_default_receive_buf (drivers/tty/tty_port.c:39)
> flush_to_ldisc (drivers/tty/tty_buffer.c:495)
> process_one_work
> worker_thread
> kthread
>
> The other callers of these helpers (the keep-alive and negotiation timer
> paths) already guard the gsm->dlci[0] access; only the receive path is
> unguarded. The CMD_CLD handler in the same switch already checks the
> loaded dlci for NULL for the very same reason. Bail out early when
> gsm->dlci[0] has been cleared instead of dereferencing it.
>
> Triggering this requires CAP_NET_ADMIN to attach the n_gsm line
> discipline (gsmld_open() uses capable(), not ns_capable()), so it is a
> local denial of service for a privileged mux owner racing its own
> control channel; harden the handlers regardless.
>
> Fixes: 5767712668b8 ("tty: n_gsm: cleanup gsm_control_command and gsm_control_reply")
> Reported-by: Xiang Mei <xmei5@asu.edu>
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Weiming Shi <bestswngs@gmail.com>
> ---
> drivers/tty/n_gsm.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
> index 214abeb89aaa..860cfb91d510 100644
> --- a/drivers/tty/n_gsm.c
> +++ b/drivers/tty/n_gsm.c
> @@ -1457,6 +1457,9 @@ static int gsm_control_command(struct gsm_mux *gsm, int cmd, const u8 *data,
> struct gsm_msg *msg;
> struct gsm_dlci *dlci = gsm->dlci[0];
>
> + if (!dlci)
> + return -EINVAL;
What precents dlci from being NULL right after you check this?
thanks,
greg k-h
^ permalink raw reply
* [PATCH] tty: n_gsm: fix NULL deref of gsm->dlci[0] in control message handlers
From: Weiming Shi @ 2026-06-11 18:32 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: Daniel Starke, linux-kernel, linux-serial, Xiang Mei, Weiming Shi
gsm_control_command() and gsm_control_reply() load gsm->dlci[0] and
immediately dereference dlci->ftype without checking it for NULL.
On the receive path, gsm_queue() validates that gsm->dlci[0] is non-NULL
and DLCI_OPEN before invoking the control handler, but the value is not
held across that check: the receive worker runs from flush_to_ldisc()
without taking gsm->mutex, while a concurrent GSMIOC_SETCONF ioctl can
enter gsm_cleanup_mux(), which takes gsm->mutex, releases gsm->dlci[0]
and sets it to NULL. If the mux is torn down between gsm_queue()'s check
and the re-load inside gsm_control_command()/gsm_control_reply(), the
handler dereferences a NULL dlci.
A peer that drives DLCI 0 control frames (e.g. CMD_TEST) while the mux
owner reconfigures the line discipline can therefore crash the kernel
(line numbers from decode_stacktrace.sh against the crashing build):
Oops: general protection fault, probably for non-canonical address
KASAN: null-ptr-deref in range [0x0000000000000208-0x000000000000020f]
RIP: 0010:gsm_control_reply (drivers/tty/n_gsm.c:1497)
Call Trace:
gsm_dlci_command (drivers/tty/n_gsm.c:2482)
gsm_queue.part.0 (drivers/tty/n_gsm.c:2852)
gsm0_receive (drivers/tty/n_gsm.c:2972)
gsmld_receive_buf (drivers/tty/n_gsm.c:3629)
tty_ldisc_receive_buf (drivers/tty/tty_buffer.c:391)
tty_port_default_receive_buf (drivers/tty/tty_port.c:39)
flush_to_ldisc (drivers/tty/tty_buffer.c:495)
process_one_work
worker_thread
kthread
The other callers of these helpers (the keep-alive and negotiation timer
paths) already guard the gsm->dlci[0] access; only the receive path is
unguarded. The CMD_CLD handler in the same switch already checks the
loaded dlci for NULL for the very same reason. Bail out early when
gsm->dlci[0] has been cleared instead of dereferencing it.
Triggering this requires CAP_NET_ADMIN to attach the n_gsm line
discipline (gsmld_open() uses capable(), not ns_capable()), so it is a
local denial of service for a privileged mux owner racing its own
control channel; harden the handlers regardless.
Fixes: 5767712668b8 ("tty: n_gsm: cleanup gsm_control_command and gsm_control_reply")
Reported-by: Xiang Mei <xmei5@asu.edu>
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
---
drivers/tty/n_gsm.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index 214abeb89aaa..860cfb91d510 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -1457,6 +1457,9 @@ static int gsm_control_command(struct gsm_mux *gsm, int cmd, const u8 *data,
struct gsm_msg *msg;
struct gsm_dlci *dlci = gsm->dlci[0];
+ if (!dlci)
+ return -EINVAL;
+
msg = gsm_data_alloc(gsm, 0, dlen + 2, dlci->ftype);
if (msg == NULL)
return -ENOMEM;
@@ -1485,6 +1488,9 @@ static void gsm_control_reply(struct gsm_mux *gsm, int cmd, const u8 *data,
struct gsm_msg *msg;
struct gsm_dlci *dlci = gsm->dlci[0];
+ if (!dlci)
+ return;
+
msg = gsm_data_alloc(gsm, 0, dlen + 2, dlci->ftype);
if (msg == NULL)
return;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 0/3] tty: serial: Add Cortina-Access UART driver and platform support
From: Arnd Bergmann @ 2026-06-11 8:35 UTC (permalink / raw)
To: Jason Li, Jason Li, Greg Kroah-Hartman, Jiri Slaby
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Catalin Marinas,
Will Deacon, linux-serial@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <JH0PR01MB5777B84BE8D9987329ABA54BA21B2@JH0PR01MB5777.apcprd01.prod.exchangelabs.com>
On Thu, Jun 11, 2026, at 07:27, Jason Li wrote:
> Hi Arnd,
>
> Your memory is truly amazing; you even remember a submission from a few
> years ago.
No, I just looked up your previous submissions when I saw the new one,
lore.kernel.org never forgets anything ;-)
> Yes, we expect actual end-user products based on these SoCs, and our
> intention is to provide complete upstream support over time. The UART
> driver and DTS support submitted in this series are the first step in
> that effort.
>
> Cortina-System and Cortina-Access are now totally different company.
> Current aarch64 chipset are totally different with legacy gemini
> processor.
> Realtek has many business unit, different BU may have upstream plan but
> they are individual.
> Although Cortina-Access is a wholly-owned subsidiary of Realtek, our
> product development is entirely independent.
Thanks for the information. Please make sure to add something along
these into the changeset text for the initial arm64 patch, along
with a brief description of what type of chip this is
Arnd
^ permalink raw reply
* RE: [PATCH 0/3] tty: serial: Add Cortina-Access UART driver and platform support
From: Jason Li @ 2026-06-11 5:27 UTC (permalink / raw)
To: Arnd Bergmann, Jason Li, Greg Kroah-Hartman, Jiri Slaby
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Catalin Marinas,
Will Deacon, linux-serial@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <7dcc8386-a0e0-4c79-a9f7-f63188bb997e@app.fastmail.com>
Hi Arnd,
Your memory is truly amazing; you even remember a submission from a few years ago.
Since the last sumbission was drop so I though restart a new one this time.
OK, I'll review all feedback and fix them for the next V6 submission.
Yes, we expect actual end-user products based on these SoCs, and our intention is to provide complete upstream support over time. The UART driver and DTS support submitted in this series are the first step in that effort.
Cortina-System and Cortina-Access are now totally different company.
Current aarch64 chipset are totally different with legacy gemini processor.
Realtek has many business unit, different BU may have upstream plan but they are individual.
Although Cortina-Access is a wholly-owned subsidiary of Realtek, our product development is entirely independent.
Thanks,
Jason
> -----Original Message-----
> From: Arnd Bergmann <arnd@arndb.de>
> Sent: Wednesday, June 10, 2026 8:51 PM
> To: Jason Li <jason.lee651024@gmail.com>; Jason Li
> <jason.li@cortina-access.com>; Greg Kroah-Hartman
> <gregkh@linuxfoundation.org>; Jiri Slaby <jirislaby@kernel.org>
> Cc: Rob Herring <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>;
> Conor Dooley <conor+dt@kernel.org>; Catalin Marinas
> <catalin.marinas@arm.com>; Will Deacon <will@kernel.org>;
> linux-serial@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 0/3] tty: serial: Add Cortina-Access UART driver and
> platform support
>
> External mail :
> This email originated from outside the organization. Do not reply, click links, or
> open attachments unless you recognize the sender and know the content is
> safe.
>
> On Wed, Jun 10, 2026, at 13:28, Jason Li wrote:
> > This series adds Linux kernel support for the UART controller
> > integrated in Cortina-Access SoCs, with CA8289 (Venus) as the first supported
> device.
>
> Hi Jason,
>
> Thanks a lot for your submission!
>
> I'm glad to see Cortina Access is getting back to upstreaming this support, I see
> that you first tries this in 2021 but didn't get very far at the time. The last
> submission was v4, so it would make sense to cound this one as v5 and
> continue with v6 next time.
>
> You have already received a number of comments, so I'll skip looking at the
> details for the moment and let you work through them.
>
> Regarding how to split up the patch series between uart and soc, I think
> sending them together during the review phase as you do here makes sense,
> but as they are loosely coupled, I think we will likely merge them separately.
> For simplicity, I would then just put the MAINTAINERS entry and the bindings
> for the vendor and board into the series for the soc tree.
>
> It would also help me if you could add some more context about the SoC into
> the patch description for the patch that adds the arm64 platform, in particular:
>
> - is this the only one you are planning to upstream at this
> point, or do you already have plans for other SoCs in this
> family?
>
> - do you expect to see full support for actual end-user
> products using these chips?
>
> - is there any shared lineage with the cortina-systems
> (storlink/storm, now marvell) gemini 32-bit chips that we
> already support, or with any of the Realtek SoCs that
> are also being upstreamed now?
>
> Arnd
^ permalink raw reply
* RE: [PATCH 1/3] dt-bindings: serial: Add binding for Cortina-Access UART
From: Jason Li @ 2026-06-11 5:26 UTC (permalink / raw)
To: Krzysztof Kozlowski, Jason Li, Greg Kroah-Hartman, Jiri Slaby
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Catalin Marinas,
Will Deacon, Arnd Bergmann, linux-serial@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <021d5cb7-51bf-4221-8b58-0e8a777cb97c@kernel.org>
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: Wednesday, June 10, 2026 7:51 PM
> To: Jason Li <jason.lee651024@gmail.com>; Jason Li
> <jason.li@cortina-access.com>; Greg Kroah-Hartman
> <gregkh@linuxfoundation.org>; Jiri Slaby <jirislaby@kernel.org>
> Cc: Rob Herring <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>;
> Conor Dooley <conor+dt@kernel.org>; Catalin Marinas
> <catalin.marinas@arm.com>; Will Deacon <will@kernel.org>; Arnd Bergmann
> <arnd@arndb.de>; linux-serial@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/3] dt-bindings: serial: Add binding for Cortina-Access
> UART
>
> External mail :
> This email originated from outside the organization. Do not reply, click links, or
> open attachments unless you recognize the sender and know the content is
> safe.
>
> On 10/06/2026 13:28, Jason Li wrote:
> > +
> > +allOf:
> > + - $ref: serial.yaml#
> > +
> > +properties:
> > + compatible:
> > + const: cortina-access,serial
>
> Aren't writing bindings very clear about that? Please, take your time to read
> through the docs, so we will not need to repeat basic guidance. It is
> documented there on purpose.
>
Appreciate for your time on reviewing.
>
> Best regards,
> Krzysztof
Thanks,
Jason
^ permalink raw reply
* RE: [PATCH 3/3] arm64: dts: cortina-access: Add DTS for CA8289 SoC and Venus board
From: Jason Li @ 2026-06-11 5:26 UTC (permalink / raw)
To: Krzysztof Kozlowski, Jason Li, Greg Kroah-Hartman, Jiri Slaby
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Catalin Marinas,
Will Deacon, Arnd Bergmann, linux-serial@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <2fd7077e-1180-47eb-9d13-5a570b0959a4@kernel.org>
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: Wednesday, June 10, 2026 7:50 PM
> To: Jason Li <jason.lee651024@gmail.com>; Jason Li
> <jason.li@cortina-access.com>; Greg Kroah-Hartman
> <gregkh@linuxfoundation.org>; Jiri Slaby <jirislaby@kernel.org>
> Cc: Rob Herring <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>;
> Conor Dooley <conor+dt@kernel.org>; Catalin Marinas
> <catalin.marinas@arm.com>; Will Deacon <will@kernel.org>; Arnd Bergmann
> <arnd@arndb.de>; linux-serial@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 3/3] arm64: dts: cortina-access: Add DTS for CA8289 SoC
> and Venus board
>
> External mail :
> This email originated from outside the organization. Do not reply, click links, or
> open attachments unless you recognize the sender and know the content is
> safe.
>
> On 10/06/2026 13:28, Jason Li wrote:
> > Add SoC DTSI for the Cortina-Access CA8289 (Venus) and a board DTS for
> > the Venus engineering board. The description covers the minimum set of
> > hardware nodes needed to boot a kernel with an INITRD rootfs: CPUs,
> > GIC, timer, PSCI, fixed clock and UART.
> >
> > Signed-off-by: Jason Li <jason.li@cortina-access.com>
> > Assisted-by: Claude:claude-opus-4-8
>
> SoB should be the last tag.
>
> Also, it does not match From field.
>
> > ---
> > MAINTAINERS | 1 +
> > arch/arm64/Kconfig.platforms | 10 ++
> > arch/arm64/boot/dts/Makefile | 1 +
> > arch/arm64/boot/dts/cortina-access/Makefile | 2 +
> > .../dts/cortina-access/ca8289-engboard.dts | 31 +++++
> > .../boot/dts/cortina-access/ca8289-soc.dtsi | 118 ++++++++++++++++++
> > 6 files changed, 163 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/cortina-access/Makefile
> > create mode 100644
> > arch/arm64/boot/dts/cortina-access/ca8289-engboard.dts
> > create mode 100644 arch/arm64/boot/dts/cortina-access/ca8289-soc.dtsi
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS index
> > 515d89d96472..ebfdb9c267cc 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -2826,6 +2826,7 @@ L: linux-arm-kernel@lists.infradead.org
> (moderated for non-subscribers)
> > S: Maintained
> > F: Documentation/devicetree/bindings/arm/cortina-access.yaml
> > F: Documentation/devicetree/bindings/serial/cortina-access,serial.yaml
> > +F: arch/arm64/boot/dts/cortina-access/
> >
> > ARM/CORTINA SYSTEMS GEMINI ARM ARCHITECTURE
> > M: Hans Ulli Kroll <ulli.kroll@googlemail.com>
> > diff --git a/arch/arm64/Kconfig.platforms
> > b/arch/arm64/Kconfig.platforms index dc995a732117..ba6dda0660c3
> 100644
> > --- a/arch/arm64/Kconfig.platforms
> > +++ b/arch/arm64/Kconfig.platforms
> > @@ -134,6 +134,16 @@ config ARCH_CIX
> > This enables support for the Cixtech SoC family,
> > like P1(sky1).
> >
> > +config ARCH_CORTINA_ACCESS
> > + bool "Cortina-Access SoC Family"
> > + select GPIOLIB
> > + select PINCTRL
> > + help
> > + This enables support for Cortina-Access SoCs. The family
> > + includes ARMv8-based devices targeting networking and access
> > + applications.
> > + If you have a Cortina-Access board, say Y here.
> > +
> > config ARCH_EXYNOS
> > bool "Samsung Exynos SoC family"
> > select COMMON_CLK_SAMSUNG
> > diff --git a/arch/arm64/boot/dts/Makefile
> > b/arch/arm64/boot/dts/Makefile index 98ec8f1b76e4..a599f525fb9a 100644
> > --- a/arch/arm64/boot/dts/Makefile
> > +++ b/arch/arm64/boot/dts/Makefile
> > @@ -16,6 +16,7 @@ subdir-y += broadcom subdir-y += bst subdir-y +=
> > cavium subdir-y += cix
> > +subdir-y += cortina-access
> > subdir-y += exynos
> > subdir-y += freescale
> > subdir-y += hisilicon
> > diff --git a/arch/arm64/boot/dts/cortina-access/Makefile
> > b/arch/arm64/boot/dts/cortina-access/Makefile
> > new file mode 100644
> > index 000000000000..554893f381fe
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/cortina-access/Makefile
> > @@ -0,0 +1,2 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +dtb-$(CONFIG_ARCH_CORTINA_ACCESS) += ca8289-engboard.dtb
> > diff --git a/arch/arm64/boot/dts/cortina-access/ca8289-engboard.dts
> > b/arch/arm64/boot/dts/cortina-access/ca8289-engboard.dts
> > new file mode 100644
> > index 000000000000..c8289a0f8269
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/cortina-access/ca8289-engboard.dts
> > @@ -0,0 +1,31 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * dts file for Cortina Access Venus Engineering Board
> > + *
> > + * Copyright (C) 2026, Cortina Access Inc.
> > + *
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "ca8289-soc.dtsi"
> > +
> > +/ {
> > + model = "Cortina Access Venus Engineering Board";
> > + compatible = "cortina-access,ca8289-engboard";
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + aliases {
> > + serial0 = &uart0;
> > + };
> > +
> > + chosen {
> > + stdout-path = "serial0:115200n8";
> > + };
> > +
> > + memory@0 { /* 512MB */
> > + device_type = "memory";
> > + reg = <0x00000000 0x00000000 0x0 0x20000000>;
> > + };
> > +};
> > diff --git a/arch/arm64/boot/dts/cortina-access/ca8289-soc.dtsi
> > b/arch/arm64/boot/dts/cortina-access/ca8289-soc.dtsi
> > new file mode 100644
> > index 000000000000..8e7ffcf4ccab
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/cortina-access/ca8289-soc.dtsi
> > @@ -0,0 +1,118 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * dts file for Cortina Access CA8289 SoC
> > + *
> > + * Copyright (C) 2026, Cortina Access Inc.
> > + */
> > +
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > +#include <dt-bindings/interrupt-controller/irq.h>
> > +
> > +/ {
> > + cpus {
> > + #address-cells = <2>;
> > + #size-cells = <0>;
> > +
> > + cpu0: cpu@0 {
> > + compatible = "arm,cortex-a55", "arm,armv8";
> > + device_type = "cpu";
> > + reg = <0x0 0x0>;
> > + enable-method = "psci";
> > + };
>
> Missing blank lines. Look at existing code how this is supposed to look like.
OK
> > + cpu1: cpu@100 {
> > + compatible = "arm,cortex-a55", "arm,armv8";
> > + device_type = "cpu";
> > + reg = <0x0 0x100>;
> > + enable-method = "psci";
> > + };
> > + cpu2: cpu@200 {
> > + compatible = "arm,cortex-a55", "arm,armv8";
> > + device_type = "cpu";
> > + reg = <0x0 0x200>;
> > + enable-method = "psci";
> > + };
> > + cpu3: cpu@300 {
> > + compatible = "arm,cortex-a55", "arm,armv8";
> > + device_type = "cpu";
> > + reg = <0x0 0x300>;
> > + enable-method = "psci";
> > + };
> > + cpu-map {
> > + cluster0 {
> > + core0 {
> > + cpu = <&cpu0>;
> > + };
> > + core1 {
> > + cpu = <&cpu1>;
> > + };
> > + core2 {
> > + cpu = <&cpu2>;
> > + };
> > + core3 {
> > + cpu = <&cpu3>;
> > + };
> > + };
> > + };
> > + };
> > +
> > + psci {
> > + compatible = "arm,psci-0.2";
> > + method = "smc";
> > + };
> > +
> > + gic: interrupt-controller@4f8000000 {
>
> And now you repeat basic mistakes:
> 1. Pointed out by W=1 dtbs_check build
> 2. Fixed long time in every source
> 3. Explicitly documented in writing bindings and DTS coding style
I'll revisit document and use dtbs_check to check that.
>
> > + compatible = "arm,gic-v3";
> > + #interrupt-cells = <3>;
> > + interrupt-controller;
> > + #redistributor-regions = <1>;
> > + reg = <0x00000004 0xF8000000 0 0x10000>,
> > + <0x00000004 0xF8040000 0 0x80000>;
>
> Read DTS coding style.
>
> > + };
> > +
> > + apb_pclk: apb-pclk {
>
> Nope, drop entire node.
>
> > + compatible = "fixed-clock";
> > + #clock-cells = <0>;
> > + clock-frequency = <125000000>;
> > + };
> > +
> > + reserved-memory {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > +
> > + /* TrustZone reserved region; must not be mapped by the
> kernel */
> > + tz_pool: tz-buffer@f000000 {
> > + reg = <0x0 0x0F000000 0x0 0x1000000>;
> > + no-map;
> > + };
> > + };
> > +
> > + /* See
> Documentation/devicetree/bindings/timer/arm,arch_timer.yaml */
> > + timer {
> > + compatible = "arm,armv8-timer";
> > + interrupt-parent = <&gic>;
> > + interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
> > + <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
> > + <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
> > + <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
> > + clock-frequency = <25000000>;
> > + };
> > +
> > + uart0: serial@f4329188 {
> > + device_type = "serial";
> > + compatible = "cortina-access,serial";
> > + reg = <0x00000000 0xf4329188 0x0 0x30>;
>
> This is AI slop. Whatever Claude convinced you to do, it is nothing like
> upstream kernel source.
>
> Best regards,
> Krzysztof
Thanks,
Jason
^ permalink raw reply
* RE: [PATCH 1/3] dt-bindings: serial: Add binding for Cortina-Access UART
From: Jason Li @ 2026-06-11 5:25 UTC (permalink / raw)
To: Krzysztof Kozlowski, Jason Li, Greg Kroah-Hartman, Jiri Slaby
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Catalin Marinas,
Will Deacon, Arnd Bergmann, linux-serial@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <068a7ba8-5b1e-46e3-9388-ba288163eb10@kernel.org>
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: Wednesday, June 10, 2026 7:47 PM
> To: Jason Li <jason.lee651024@gmail.com>; Jason Li
> <jason.li@cortina-access.com>; Greg Kroah-Hartman
> <gregkh@linuxfoundation.org>; Jiri Slaby <jirislaby@kernel.org>
> Cc: Rob Herring <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>;
> Conor Dooley <conor+dt@kernel.org>; Catalin Marinas
> <catalin.marinas@arm.com>; Will Deacon <will@kernel.org>; Arnd Bergmann
> <arnd@arndb.de>; linux-serial@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/3] dt-bindings: serial: Add binding for Cortina-Access
> UART
>
> External mail :
> This email originated from outside the organization. Do not reply, click links, or
> open attachments unless you recognize the sender and know the content is
> safe.
>
> On 10/06/2026 13:28, Jason Li wrote:
> > Add DT binding schema for the Cortina-Access UART controller.
> > This IP is integrated into most CAXXXX SoC family members.
> >
> > Also add the vendor prefix for Cortina Access, Inc. and the top-level
> > ARM board binding document for the CA8289 (Venus) SoC.
> >
> > Signed-off-by: Jason Li <jason.li@cortina-access.com>
> > Assisted-by: Claude:claude-opus-4-8
> > ---
> > .../bindings/arm/cortina-access.yaml | 29 ++++++++++++
> > .../serial/cortina-access,serial.yaml | 46 +++++++++++++++++++
> > .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> > MAINTAINERS | 7 +++
>
> This is somehow complete mess. serial and arm together?
>
> Please carefully read submitting patches (both documents!) and don't send
> AI-assisted slop.
>
> You must not combine independent works together.
>
>
Thank you, I'll separate patch for different yaml
> > 4 files changed, 84 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/arm/cortina-access.yaml
> > create mode 100644
> > Documentation/devicetree/bindings/serial/cortina-access,serial.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/arm/cortina-access.yaml
> > b/Documentation/devicetree/bindings/arm/cortina-access.yaml
> > new file mode 100644
> > index 000000000000..ec0320ed0c0b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/cortina-access.yaml
> > @@ -0,0 +1,29 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/arm/cortina-access.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Cortina-Access SoC boards
> > +
> > +maintainers:
> > + - Jason Li <jason.li@cortina-access.com>
> > +
> > +description:
> > + Boards based on Cortina-Access ARMv8 SoCs targeting networking and
> > + access applications.
> > +
> > +properties:
> > + $nodename:
> > + const: /
> > + compatible:
> > + oneOf:
> > + - description: Cortina-Access CA8289 (Venus) engineering board
> > + const: cortina-access,ca8289-engboard
> > +
> > + - description: Cortina-Access CA8289 (Venus) reference board
> > + const: cortina-access,ca8289-refboard
>
>
> Where is the SoC? This looks like very poor contribution. If you opened any
> existing recent board binding you would see it is done differently.
>
Thanks, I'll refer more exist examples to fix.
> Best regards,
> Krzysztof
Thanks,
Jason
^ permalink raw reply
* [PATCHv3 5/6] serial: mxs-auart: clamp RX DMA count to buffer size
From: Rosen Penev @ 2026-06-11 3:38 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Jiri Slaby, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
open list:TTY LAYER AND SERIAL DRIVERS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20260611033856.6476-1-rosenp@gmail.com>
In dma_rx_callback(), the RX count from the hardware status register
(AUART_STAT_RXCOUNT_MASK = 0xffff) is passed directly to
tty_insert_flip_string() without any bounds check. Since rx_dma_buf
is allocated with UART_XMIT_SIZE (4096 bytes), a hardware fault or
compromised peripheral reporting a count larger than 4096 would cause
an out-of-bounds read, potentially leaking kernel memory.
Clamp the count to UART_XMIT_SIZE before use.
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/tty/serial/mxs-auart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index e2b656638ab3..fe48a372d022 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -823,7 +823,7 @@ static void dma_rx_callback(void *arg)
stat &= ~(AUART_STAT_OERR | AUART_STAT_BERR |
AUART_STAT_PERR | AUART_STAT_FERR);
- count = stat & AUART_STAT_RXCOUNT_MASK;
+ count = min_t(u32, stat & AUART_STAT_RXCOUNT_MASK, UART_XMIT_SIZE);
tty_insert_flip_string(port, s->rx_dma_buf, count);
mxs_write(stat, s, REG_STAT);
--
2.54.0
^ permalink raw reply related
* [PATCHv3 6/6] serial: mxs-auart: terminate DMA before releasing channels in exit
From: Rosen Penev @ 2026-06-11 3:38 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Jiri Slaby, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
open list:TTY LAYER AND SERIAL DRIVERS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20260611033856.6476-1-rosenp@gmail.com>
mxs_auart_dma_exit_channel() calls dma_release_channel() and then
kfree() on the DMA buffers without first terminating any in-flight
transfers. If an asynchronous DMA transfer completes after the buffers
have been freed, the callback will access freed memory.
Call dmaengine_terminate_sync() on each channel before releasing it
to safely abort pending transfers.
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/tty/serial/mxs-auart.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index fe48a372d022..ec2c60dd0f52 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -872,10 +872,12 @@ static int mxs_auart_dma_prep_rx(struct mxs_auart_port *s)
static void mxs_auart_dma_exit_channel(struct mxs_auart_port *s)
{
if (s->tx_dma_chan) {
+ dmaengine_terminate_sync(s->tx_dma_chan);
dma_release_channel(s->tx_dma_chan);
s->tx_dma_chan = NULL;
}
if (s->rx_dma_chan) {
+ dmaengine_terminate_sync(s->rx_dma_chan);
dma_release_channel(s->rx_dma_chan);
s->rx_dma_chan = NULL;
}
--
2.54.0
^ permalink raw reply related
* [PATCHv3 4/6] serial: mxs-auart: fix IRQ registration ordering and manage console clock
From: Rosen Penev @ 2026-06-11 3:38 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Jiri Slaby, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
open list:TTY LAYER AND SERIAL DRIVERS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20260611033856.6476-1-rosenp@gmail.com>
Move the main UART IRQ registration after uart_add_one_port so that
s->port.state and s->port.lock are initialized before the interrupt
handler can run. Mask all UART interrupts before adding the port to
prevent spurious IRQs left by the bootloader.
After probe succeeds, disable the module clock for non-console ports
since startup will re-enable it on port open. For console ports, keep
the clock prepared so auart_console_write() can safely call
clk_enable() from atomic context.
Guard the IRQ handler and get_mctrl with clk_enable/clk_disable since
GPIO IRQs and serial-core status queries can fire while the clock is
disabled for non-console ports.
In remove, disable the clock for console ports to balance the enable
done in probe, preventing a clock leak on unbind.
Assisted-by: opencode:big-pickle
---
drivers/tty/serial/mxs-auart.c | 49 +++++++++++++++++++++++++++-------
1 file changed, 39 insertions(+), 10 deletions(-)
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index 4499e3206e85..e2b656638ab3 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -738,9 +738,13 @@ static u32 mxs_auart_modem_status(struct mxs_auart_port *s, u32 mctrl)
static u32 mxs_auart_get_mctrl(struct uart_port *u)
{
struct mxs_auart_port *s = to_auart_port(u);
- u32 stat = mxs_read(s, REG_STAT);
+ u32 stat;
u32 mctrl = 0;
+ clk_enable(s->clk);
+ stat = mxs_read(s, REG_STAT);
+ clk_disable(s->clk);
+
if (stat & AUART_STAT_CTS)
mctrl |= TIOCM_CTS;
@@ -1079,6 +1083,7 @@ static irqreturn_t mxs_auart_irq_handle(int irq, void *context)
struct mxs_auart_port *s = context;
u32 mctrl_temp = s->mctrl_prev;
+ clk_enable(s->clk);
uart_port_lock(&s->port);
stat = mxs_read(s, REG_STAT);
@@ -1118,6 +1123,7 @@ static irqreturn_t mxs_auart_irq_handle(int irq, void *context)
}
uart_port_unlock(&s->port);
+ clk_disable(s->clk);
return IRQ_HANDLED;
}
@@ -1603,10 +1609,6 @@ static int mxs_auart_probe(struct platform_device *pdev)
}
s->port.irq = irq;
- ret = devm_request_irq(&pdev->dev, irq, mxs_auart_irq_handle, 0,
- dev_name(&pdev->dev), s);
- if (ret)
- goto out_disable_clk;
platform_set_drvdata(pdev, s);
@@ -1627,9 +1629,28 @@ static int mxs_auart_probe(struct platform_device *pdev)
mxs_auart_reset_deassert(s);
+ /* Mask all UART interrupts to prevent spurious IRQs from bootloader */
+ mxs_write(0, s, REG_INTR);
+
ret = uart_add_one_port(&auart_driver, &s->port);
- if (ret)
- goto out_free_qpio_irq;
+ if (ret) {
+ auart_port[s->port.line] = NULL;
+ goto out_disable_clk;
+ }
+
+ /*
+ * Request the main IRQ after uart_add_one_port so that
+ * s->port.state and s->port.lock are initialized before
+ * the handler can run in response to a bootloader-left
+ * interrupt.
+ */
+ ret = devm_request_irq(&pdev->dev, irq, mxs_auart_irq_handle, 0,
+ dev_name(&pdev->dev), s);
+ if (ret) {
+ uart_remove_one_port(&auart_driver, &s->port);
+ auart_port[s->port.line] = NULL;
+ goto out_disable_clk;
+ }
/* ASM9260 don't have version reg */
if (is_asm9260_auart(s)) {
@@ -1641,10 +1662,16 @@ static int mxs_auart_probe(struct platform_device *pdev)
(version >> 16) & 0xff, version & 0xffff);
}
- return 0;
+ /*
+ * Disable clock -- startup will re-enable when the port is opened.
+ * For the console port the clock must stay prepared so that
+ * auart_console_write() can safely call clk_enable() from
+ * atomic context.
+ */
+ if (!uart_console(&s->port))
+ clk_disable_unprepare(s->clk);
-out_free_qpio_irq:
- auart_port[s->port.line] = NULL;
+ return 0;
out_disable_clk:
clk_disable_unprepare(s->clk);
@@ -1657,6 +1684,8 @@ static void mxs_auart_remove(struct platform_device *pdev)
uart_remove_one_port(&auart_driver, &s->port);
auart_port[s->port.line] = NULL;
+ if (uart_console(&s->port))
+ clk_disable_unprepare(s->clk);
}
static struct platform_driver mxs_auart_driver = {
--
2.54.0
^ permalink raw reply related
* [PATCHv3 3/6] serial: mxs-auart: use devm resources for iomem and GPIO IRQs
From: Rosen Penev @ 2026-06-11 3:38 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Jiri Slaby, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
open list:TTY LAYER AND SERIAL DRIVERS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20260611033856.6476-1-rosenp@gmail.com>
Replace platform_get_resource + ioremap with
devm_platform_get_and_ioremap_resource and convert GPIO IRQ
request_irq/free_irq to devm_request_irq. This eliminates the
mxs_auart_free_gpio_irq function and its call sites, and the
out_iounmap error label. Simplify the remove function accordingly.
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/tty/serial/mxs-auart.c | 53 +++++++---------------------------
1 file changed, 11 insertions(+), 42 deletions(-)
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index aa59a48bfad7..4499e3206e85 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -1517,15 +1517,6 @@ static int mxs_auart_init_gpios(struct mxs_auart_port *s, struct device *dev)
return 0;
}
-static void mxs_auart_free_gpio_irq(struct mxs_auart_port *s)
-{
- enum mctrl_gpio_idx i;
-
- for (i = 0; i < UART_GPIO_MAX; i++)
- if (s->gpio_irq[i] >= 0)
- free_irq(s->gpio_irq[i], s);
-}
-
static int mxs_auart_request_gpio_irq(struct mxs_auart_port *s)
{
int *irq = s->gpio_irq;
@@ -1537,21 +1528,13 @@ static int mxs_auart_request_gpio_irq(struct mxs_auart_port *s)
continue;
irq_set_status_flags(irq[i], IRQ_NOAUTOEN);
- err = request_irq(irq[i], mxs_auart_irq_handle,
- IRQ_TYPE_EDGE_BOTH, dev_name(s->dev), s);
+ err = devm_request_irq(s->dev, irq[i], mxs_auart_irq_handle,
+ IRQ_TYPE_EDGE_BOTH, dev_name(s->dev), s);
if (err)
dev_err(s->dev, "%s - Can't get %d irq\n",
__func__, irq[i]);
}
- /*
- * If something went wrong, rollback.
- * Be careful: i may be unsigned.
- */
- while (err && (i-- > 0))
- if (irq[i] >= 0)
- free_irq(irq[i], s);
-
return err;
}
@@ -1596,18 +1579,12 @@ static int mxs_auart_probe(struct platform_device *pdev)
if (ret)
return ret;
- r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!r) {
- ret = -ENXIO;
+ s->port.membase = devm_platform_get_and_ioremap_resource(pdev, 0, &r);
+ if (IS_ERR(s->port.membase)) {
+ ret = PTR_ERR(s->port.membase);
goto out_disable_clk;
}
-
s->port.mapbase = r->start;
- s->port.membase = ioremap(r->start, resource_size(r));
- if (!s->port.membase) {
- ret = -ENOMEM;
- goto out_disable_clk;
- }
s->port.ops = &mxs_auart_ops;
s->port.iotype = UPIO_MEM;
s->port.fifosize = MXS_AUART_FIFO_SIZE;
@@ -1622,21 +1599,21 @@ static int mxs_auart_probe(struct platform_device *pdev)
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
ret = irq;
- goto out_iounmap;
+ goto out_disable_clk;
}
s->port.irq = irq;
ret = devm_request_irq(&pdev->dev, irq, mxs_auart_irq_handle, 0,
dev_name(&pdev->dev), s);
if (ret)
- goto out_iounmap;
+ goto out_disable_clk;
platform_set_drvdata(pdev, s);
ret = mxs_auart_init_gpios(s, &pdev->dev);
if (ret) {
dev_err(&pdev->dev, "Failed to initialize GPIOs.\n");
- goto out_iounmap;
+ goto out_disable_clk;
}
/*
@@ -1644,7 +1621,7 @@ static int mxs_auart_probe(struct platform_device *pdev)
*/
ret = mxs_auart_request_gpio_irq(s);
if (ret)
- goto out_iounmap;
+ goto out_disable_clk;
auart_port[s->port.line] = s;
@@ -1667,11 +1644,7 @@ static int mxs_auart_probe(struct platform_device *pdev)
return 0;
out_free_qpio_irq:
- mxs_auart_free_gpio_irq(s);
- auart_port[pdev->id] = NULL;
-
-out_iounmap:
- iounmap(s->port.membase);
+ auart_port[s->port.line] = NULL;
out_disable_clk:
clk_disable_unprepare(s->clk);
@@ -1683,11 +1656,7 @@ static void mxs_auart_remove(struct platform_device *pdev)
struct mxs_auart_port *s = platform_get_drvdata(pdev);
uart_remove_one_port(&auart_driver, &s->port);
- auart_port[pdev->id] = NULL;
- mxs_auart_free_gpio_irq(s);
- iounmap(s->port.membase);
- if (is_asm9260_auart(s))
- clk_disable_unprepare(s->clk);
+ auart_port[s->port.line] = NULL;
}
static struct platform_driver mxs_auart_driver = {
--
2.54.0
^ permalink raw reply related
* [PATCHv3 2/6] serial: mxs-auart: rework clock handling in mxs_get_clks and probe
From: Rosen Penev @ 2026-06-11 3:38 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Jiri Slaby, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
open list:TTY LAYER AND SERIAL DRIVERS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20260611033856.6476-1-rosenp@gmail.com>
Use devm_clk_get_enabled for the AHB clock so its enable/disable
lifetime is managed by the driver model. Move the mod clock
(clk) prepare_enable out of mxs_get_clks and into probe so that
clk_set_rate is called while the clock is still disabled, avoiding
CLK_SET_RATE_GATE failures. Clean up the error labels accordingly.
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/tty/serial/mxs-auart.c | 47 ++++++++++++----------------------
1 file changed, 17 insertions(+), 30 deletions(-)
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index de97c0f74e7d..aa59a48bfad7 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -1470,34 +1470,22 @@ static int mxs_get_clks(struct mxs_auart_port *s,
return PTR_ERR(s->clk);
}
- s->clk_ahb = devm_clk_get(s->dev, "ahb");
+ s->clk_ahb = devm_clk_get_enabled(s->dev, "ahb");
if (IS_ERR(s->clk_ahb)) {
dev_err(s->dev, "Failed to get \"ahb\" clk\n");
return PTR_ERR(s->clk_ahb);
}
- err = clk_prepare_enable(s->clk_ahb);
- if (err) {
- dev_err(s->dev, "Failed to enable ahb_clk!\n");
- return err;
- }
-
+ /*
+ * Set mod clock rate while it is still disabled so
+ * CLK_SET_RATE_GATE does not cause clk_set_rate to fail.
+ * The mod clock will be enabled in mxs_auart_startup()
+ * and in probe after mxs_get_clks returns.
+ */
err = clk_set_rate(s->clk, clk_get_rate(s->clk_ahb));
- if (err) {
+ if (err)
dev_err(s->dev, "Failed to set rate!\n");
- goto disable_clk_ahb;
- }
- err = clk_prepare_enable(s->clk);
- if (err) {
- dev_err(s->dev, "Failed to enable clk!\n");
- goto disable_clk_ahb;
- }
-
- return 0;
-
-disable_clk_ahb:
- clk_disable_unprepare(s->clk_ahb);
return err;
}
@@ -1604,17 +1592,21 @@ static int mxs_auart_probe(struct platform_device *pdev)
if (ret)
return ret;
+ ret = clk_prepare_enable(s->clk);
+ if (ret)
+ return ret;
+
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!r) {
ret = -ENXIO;
- goto out_disable_clks;
+ goto out_disable_clk;
}
s->port.mapbase = r->start;
s->port.membase = ioremap(r->start, resource_size(r));
if (!s->port.membase) {
ret = -ENOMEM;
- goto out_disable_clks;
+ goto out_disable_clk;
}
s->port.ops = &mxs_auart_ops;
s->port.iotype = UPIO_MEM;
@@ -1681,11 +1673,8 @@ static int mxs_auart_probe(struct platform_device *pdev)
out_iounmap:
iounmap(s->port.membase);
-out_disable_clks:
- if (is_asm9260_auart(s)) {
- clk_disable_unprepare(s->clk);
- clk_disable_unprepare(s->clk_ahb);
- }
+out_disable_clk:
+ clk_disable_unprepare(s->clk);
return ret;
}
@@ -1697,10 +1686,8 @@ static void mxs_auart_remove(struct platform_device *pdev)
auart_port[pdev->id] = NULL;
mxs_auart_free_gpio_irq(s);
iounmap(s->port.membase);
- if (is_asm9260_auart(s)) {
+ if (is_asm9260_auart(s))
clk_disable_unprepare(s->clk);
- clk_disable_unprepare(s->clk_ahb);
- }
}
static struct platform_driver mxs_auart_driver = {
--
2.54.0
^ permalink raw reply related
* [PATCHv3 1/6] serial: mxs-auart: fix cast type for of_device_get_match_data
From: Rosen Penev @ 2026-06-11 3:38 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Jiri Slaby, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
open list:TTY LAYER AND SERIAL DRIVERS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20260611033856.6476-1-rosenp@gmail.com>
of_device_get_match_data returns const void*. Cast to unsigned long to
avoid implicit integer truncation warnings. All the data parameters are
correct anyway.
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/tty/serial/mxs-auart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index 697318dbb146..de97c0f74e7d 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -1598,7 +1598,7 @@ static int mxs_auart_probe(struct platform_device *pdev)
return -EINVAL;
}
- s->devtype = (enum mxs_auart_type)of_device_get_match_data(&pdev->dev);
+ s->devtype = (unsigned long)of_device_get_match_data(&pdev->dev);
ret = mxs_get_clks(s, pdev);
if (ret)
--
2.54.0
^ permalink raw reply related
* [PATCHv3 0/6] serial: mxs-auart: devm conversion, clock rework, and IRQ ordering fixes
From: Rosen Penev @ 2026-06-11 3:38 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Jiri Slaby, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
open list:TTY LAYER AND SERIAL DRIVERS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
This series cleans up the mxs-auart driver by converting to devm-managed
resources, fixing clock prepare/enable ordering, and addressing IRQ
registration races.
Patch 1 fixes compilation on 64-bit build with W=1
Patch 2 reworks the clock handling to use devm_clk_get_enabled and
reorders clk_prepare_enable after clk_set_rate to avoid
CLK_SET_RATE_GATE failures.
Patch 3 converts iomem mapping and GPIO IRQ requests to devm,
removing the manual cleanup paths.
Patch 4 moves the main UART IRQ registration after uart_add_one_port
so the port state is initialized before the handler can run, and
manages the module clock for console vs non-console ports correctly.
v3: two more sashiko fixes
v2: split off of_device_get_match_data change.
Rosen Penev (6):
serial: mxs-auart: fix cast type for of_device_get_match_data
serial: mxs-auart: rework clock handling in mxs_get_clks and probe
serial: mxs-auart: use devm resources for iomem and GPIO IRQs
serial: mxs-auart: fix IRQ registration ordering and manage console
clock
serial: mxs-auart: clamp RX DMA count to buffer size
serial: mxs-auart: terminate DMA before releasing channels in exit
drivers/tty/serial/mxs-auart.c | 145 +++++++++++++++------------------
1 file changed, 66 insertions(+), 79 deletions(-)
--
2.54.0
^ permalink raw reply
* Re: [PATCH 2/3] tty: serial: Add UART driver for Cortina-Access platform
From: Randy Dunlap @ 2026-06-10 22:49 UTC (permalink / raw)
To: Jason Li, jason.li, Greg Kroah-Hartman, Jiri Slaby
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Catalin Marinas,
Will Deacon, Arnd Bergmann, linux-serial, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20260610112821.3030099-4-jason.li@cortina-access.com>
On 6/10/26 4:28 AM, Jason Li wrote:
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index cf7dba473b20..99a1c9308395 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -1592,6 +1592,27 @@ config SERIAL_NUVOTON_MA35D1_CONSOLE
> but you can alter that using a kernel command line option such as
> "console=ttyNVTx".
>
> +config SERIAL_CORTINA_ACCESS
> + tristate "Cortina-Access serial port support"
> + depends on OF
> + select SERIAL_CORE
> + help
> + This driver is for the Cortina-Access SoC UART, present in the
> + CA8289 (Venus) and related CAXXXX family of SoCs. If you have a
> + machine based on the Cortina-Access SoC and wish to use the serial
> + port, say 'Y' here. Otherwise, say 'N'.
It could also be 'm' since the kconfig symbol is tristate.
> +
> +config SERIAL_CORTINA_ACCESS_CONSOLE
> + bool "Console on Cortina-Access serial port"
> + depends on SERIAL_CORTINA_ACCESS=y
> + select SERIAL_CORE_CONSOLE
> + select SERIAL_EARLYCON
> + help
> + Say 'Y' here if you wish to use the Cortina-Access UART as the system
> + console (the device which receives all kernel messages and warnings
> + and which allows logins in single user mode).
> + /dev/ttyS* is the default device node.
> +
> endmenu
--
~Randy
^ permalink raw reply
* Re: [PATCH 04/11] treewide: Convert struct kernel_param_ops initializers to DEFINE_KERNEL_PARAM_OPS
From: jim.cromie @ 2026-06-10 21:06 UTC (permalink / raw)
To: Petr Pavlu
Cc: Kees Cook, Luis Chamberlain, Pengpeng Hou, Richard Weinberger,
Anton Ivanov, Johannes Berg, Rafael J. Wysocki, Len Brown,
Corey Minyard, Gabriel Somlo, Michael S. Tsirkin, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, David Airlie,
Simona Vetter, Bart Van Assche, Jason Gunthorpe, Leon Romanovsky,
Laurent Pinchart, Hans de Goede, Mauro Carvalho Chehab,
Bjorn Helgaas, Hannes Reinecke, James E.J. Bottomley,
Martin K. Petersen, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Greg Kroah-Hartman, Jiri Slaby, Alan Stern, Jason Wang, Xuan Zhuo,
Eugenio Pérez, Jason Baron, Tiwei Bie, Benjamin Berg,
Ilpo Järvinen, David E. Box, Maciej W. Rozycki,
Srinivas Pandruvada, Peter Zijlstra, Heiko Carstens,
Vasily Gorbik, Sean Christopherson, Paolo Bonzini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vinod Koul, Frank Li, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Alexander Potapenko, Marco Elver, Dmitry Vyukov,
Andrew Morton, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, Andy Shevchenko, Georgia Garcia, kvm, dmaengine,
linux-modules, kasan-dev, linux-mm, apparmor,
linux-security-module, linux-um, linux-acpi, openipmi-developer,
qemu-devel, intel-gfx, dri-devel, linux-rdma, linux-media,
linux-pci, linux-scsi, linux-pm, linuxppc-dev, linux-serial,
linux-usb, usb-storage, virtualization, linux-kernel, linux-arch,
netdev, linux-fsdevel, linux-hardening
In-Reply-To: <da358ae1-91b4-4a16-ac76-ffab99c230b9@suse.com>
On Mon, May 25, 2026 at 7:35 AM Petr Pavlu <petr.pavlu@suse.com> wrote:
>
> On 5/21/26 3:33 PM, Kees Cook wrote:
> > Using Coccinelle, rewrite every struct kernel_param_ops initializer that
> > sets .get into a DEFINE_KERNEL_PARAM_OPS-family macro invocation,
> > for example:
> >
> > @@
> > declarer name DEFINE_KERNEL_PARAM_OPS;
> > identifier OPS;
> > expression SET, GET;
> > @@
> > - const struct kernel_param_ops OPS = {
> > - .set = SET,
> > - .get = GET,
> > - };
> > + DEFINE_KERNEL_PARAM_OPS(OPS, SET, GET);
> >
> > Using the macro for initialization means future changes can manipulate
> > the struct layout and callback prototypes without having to change every
> > initializer.
>
> Nit: For consistency, I suggest also converting the few remaining
> kernel_param_ops instances that specify only .set and no .get, such as
> simdisk_param_ops_filename.
>
> --
> Thanks,
> Petr
for the dynamic-debug changes
Reviewed-by: Jim Cromie <jim.cromie@gmail.com>
^ permalink raw reply
* Re: [PATCH] ARM: footbridge: convert to sparse IRQs
From: Dmitry Torokhov @ 2026-06-10 17:03 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: Arnd Bergmann, linux-arm-kernel, linux-input, linux-serial,
Russell King, Greg Kroah-Hartman, Jiri Slaby, Russell King,
Linus Walleij, Kees Cook, Nathan Chancellor,
Sebastian Andrzej Siewior, Steven Rostedt, Thomas Weißschuh,
Peter Zijlstra
In-Reply-To: <CADkSEUhh1NdOMTHVsErhqzyCpDGFA-FkNFaWp94e9LnB3njxqw@mail.gmail.com>
On Mon, Jun 08, 2026 at 10:13:50AM -0700, Ethan Nelson-Moore wrote:
> Hi, Arnd,
>
> On Mon, Jun 8, 2026 at 10:11 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > I think this is correct, as footbridge is the only one that selects
> > CONFIG_ARCH_MIGHT_HAVE_PC_SERIO and defines I8042_KBD_IRQ on arm.
>
> I came to the same conclusion.
I see. In this case:
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> # for input
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v6 6/9] dt-bindings: connector: m2: Add M.2 1620 LGA soldered down connector
From: Manivannan Sadhasivam @ 2026-06-10 16:44 UTC (permalink / raw)
To: Stephan Gerhold
Cc: Mark Pearson, Dmitry Baryshkov, Rob Herring,
Manivannan Sadhasivam, Greg KH, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen,
Derek J . Clark, Krzysztof Kozlowski, Conor Dooley,
Marcel Holtmann, Luiz Augusto von Dentz, Bartosz Golaszewski,
Andy Shevchenko, Bartosz Golaszewski, linux-serial, linux-kernel,
linux-kbuild, platform-driver-x86@vger.kernel.org, linux-pci,
devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
linux-acpi@vger.kernel.org
In-Reply-To: <acv2f1qbqu4PlSL1@linaro.org>
On Tue, Mar 31, 2026 at 06:29:51PM +0200, Stephan Gerhold wrote:
> On Wed, Mar 25, 2026 at 05:36:08PM +0530, Manivannan Sadhasivam wrote:
> > On Mon, Mar 23, 2026 at 01:23:07PM -0400, Mark Pearson wrote:
> > > On Mon, Mar 23, 2026, at 12:52 PM, Manivannan Sadhasivam wrote:
> > > > On Mon, Mar 23, 2026 at 06:45:15PM +0200, Dmitry Baryshkov wrote:
> > > >> On Mon, Mar 23, 2026 at 09:26:04PM +0530, Manivannan Sadhasivam wrote:
> > > >> > On Mon, Mar 23, 2026 at 05:14:30PM +0200, Dmitry Baryshkov wrote:
> > > >> > > On Mon, Mar 23, 2026 at 07:14:25PM +0530, Manivannan Sadhasivam wrote:
> > > >> > > > On Mon, Mar 23, 2026 at 08:39:55AM -0500, Rob Herring wrote:
> > > >> > > > > On Mon, Mar 23, 2026 at 7:16 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > >> > > > > >
> > > >> > > > > > On Sun, Mar 22, 2026 at 06:37:13PM -0500, Rob Herring wrote:
> > > >> > > > > > > On Tue, Mar 17, 2026 at 09:59:56AM +0530, Manivannan Sadhasivam wrote:
> > > >> > > > > > > > Lenovo Thinkpad T14s is found to have a soldered down version of M.2 1620
> > > >> > > > > > > > LGA connector. Though, there is no 1620 LGA form factor defined in the M.2
> > > >> > > > > > > > spec, it looks very similar to the M.2 Key E connector. So add the
> > > >> > > > > > > > "pcie-m2-1620-lga-connector" compatible with "pcie-m2-e-connector" fallback
> > > >> > > > > > > > to reuse the Key E binding.
> > > >> > > > > > >
> > > >> > > > > > > What is LGA?
> > > >> > > > > > >
> > > >> > > > > >
> > > >> > > > > > Land Grid Array
> > > >> > > > > >
> > > >> > > > > > > If not in the spec, is it really something generic?
> > > >> > > > > > >
> > > >> > > > > >
> > > >> > > > > > Good question. Yes and No! LGA is not something that Lenovo only uses. Other
> > > >> > > > > > vendors may also use this form factor. PCIe connectors are full of innovation as
> > > >> > > > > > the spec gives room for hardware designers to be as innovative as possible to
> > > >> > > > > > save the BOM cost.
> > > >> > > > >
> > > >> > > > > innovation == incompatible changes
> > > >> > > > >
> > > >> > > >
> > > >> > > > Yes, I was trying to sound nice :)
> > > >> > > >
> > > >> > > > > > This is why I do not want to make it Lenovo specific. But if you prefer that, I
> > > >> > > > > > can name it as "lenovo,pcie-m2-1620-lga-connector".
> > > >> > > > >
> > > >> > > > > Depends if you think that s/w needs to know the differences. Hard to
> > > >> > > > > say with a sample size of 1.
> > > >> > > > >
> > > >> > > >
> > > >> > > > Sure. Will add the 'lenovo' prefix then.
> > > >> > >
> > > >> > > Is it really Lenovo? Or is it some other module vendor, whose LGAs are
> > > >> > > being used by Lenovo?
> > > >> > >
> > > >> > > I remember that DB820c also used some kind of a module for the WiFi card
> > > >> > > (which might be M.2 compatible or might not, I can't find exact docs at
> > > >> > > this point).
> > > >> > >
> > > >> >
> > > >> > I don't know. These kind of designs might be reused by several vendors. But
> > > >> > considering that we should not make it generic, I'd go with Lenovo as that's
> > > >> > the only vendor we know as of now.
> > > >>
> > > >> ... and later we learn that other vendors use the same idea /pinout,
> > > >> then nothing stops us from still telling that it's a
> > > >> "lenovo,pcie-m2-something-lga".
> > > >>
> > > >
> > > > How do you possibly know whether a single vendor has introduced this form factor
> > > > or reused by multiple ones? Atleast, I don't have access to such a source to
> > > > confirm.
> > > >
> > > I've not really been following this thread/patchset in detail; but want me to try and check with the T14s platform team if this device is specifically made for us (Lenovo) or not?
> > > I doubt it is - we just don't do that usually, but I can go and ask the question if it will help resolve this (with the caveat that it could hold up the review for a bit and I may not be able to get a straight answer)
> > >
> >
> > I can drop this specific patch in the meantime.
> >
> > > My vote (for what little it's worth) would be to make it non-Lenovo specific. Then when the same part causes issues on another vendors platform I won't get asked questions about why Lenovo is breaking <other vendor> :)
> > >
> >
> > Even if Lenovo prefix is used, it won't break other vendors. Just that we will
> > end up adding more compatibles.
> >
> > Anyhow, I'll wait for your reply and drop this patch for next revision.
> >
>
> If you need a vendor prefix, I think "qcom," would be more appropriate
> than Lenovo. This form factor is used by most vendors for recent
> soldered Qualcomm-based wireless cards, not just Lenovo:
>
> - Dell XPS 13 9345 has exactly the same soldered M.2 card, I assume
> there are several other vendors as well.
>
> - https://www.sparklan.com/product/wnsq-290be/ is a third-party
> (Qualcomm-based) M.2 LGA 1620 card, in the block diagram the
> pinout is called "QM.2 1620 LGA 168pin".
>
> - If you press F9 while booting the ThinkPad T14s, you should get to a
> screen with "Regulatory Information". For the T14s, this screen says
> "Contains FCC ID: J9C-QCNCM825". This is the WiFi/BT module in the
> soldered form factor. If you look that up on the FCC website, the
> applicant for this module is "Qualcomm Technologies, Inc.". This
> seems to be some kind of "modular certification" that vendors can
> reuse/adapt without going through the whole process again.
>
> Perhaps you should ask around inside Qualcomm? :-)
>
Sorry for getting back after this long. I did ask around, but our HW folks are
saying that Qcom is not the first one to use LGA M.2 modules. They claim that
other vendors also do that.
But for this specific card, it should be fine to use the 'qcom' prefix as
apparently the module was supplied by Qcom.
I'll submit the bindings patch together with DTS change for T14s.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH 0/3] tty: serial: Add Cortina-Access UART driver and platform support
From: Arnd Bergmann @ 2026-06-10 12:50 UTC (permalink / raw)
To: Jason Li, jason.li, Greg Kroah-Hartman, Jiri Slaby
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Catalin Marinas,
Will Deacon, linux-serial, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20260610112821.3030099-2-jason.li@cortina-access.com>
On Wed, Jun 10, 2026, at 13:28, Jason Li wrote:
> This series adds Linux kernel support for the UART controller integrated
> in Cortina-Access SoCs, with CA8289 (Venus) as the first supported device.
Hi Jason,
Thanks a lot for your submission!
I'm glad to see Cortina Access is getting back to upstreaming
this support, I see that you first tries this in 2021 but
didn't get very far at the time. The last submission was v4,
so it would make sense to cound this one as v5 and continue
with v6 next time.
You have already received a number of comments, so I'll skip
looking at the details for the moment and let you work through
them.
Regarding how to split up the patch series between uart and
soc, I think sending them together during the review phase
as you do here makes sense, but as they are loosely coupled,
I think we will likely merge them separately. For simplicity,
I would then just put the MAINTAINERS entry and the bindings
for the vendor and board into the series for the soc tree.
It would also help me if you could add some more context about
the SoC into the patch description for the patch that adds
the arm64 platform, in particular:
- is this the only one you are planning to upstream at this
point, or do you already have plans for other SoCs in this
family?
- do you expect to see full support for actual end-user
products using these chips?
- is there any shared lineage with the cortina-systems
(storlink/storm, now marvell) gemini 32-bit chips that we
already support, or with any of the Realtek SoCs that
are also being upstreamed now?
Arnd
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: serial: Add binding for Cortina-Access UART
From: Krzysztof Kozlowski @ 2026-06-10 11:51 UTC (permalink / raw)
To: Jason Li, jason.li, Greg Kroah-Hartman, Jiri Slaby
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Catalin Marinas,
Will Deacon, Arnd Bergmann, linux-serial, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20260610112821.3030099-3-jason.li@cortina-access.com>
On 10/06/2026 13:28, Jason Li wrote:
> +
> +allOf:
> + - $ref: serial.yaml#
> +
> +properties:
> + compatible:
> + const: cortina-access,serial
Aren't writing bindings very clear about that? Please, take your time to
read through the docs, so we will not need to repeat basic guidance. It
is documented there on purpose.
Best regards,
Krzysztof
^ 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