* Re: [PATCH v3 6/7] ARM: dts: aspeed: g6: Change vuart compatible string for ast2600
From: Grégoire Layet @ 2026-06-24 13:44 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt, andrew, jacky_chou, yh_chung, ninad,
anirudhsriniv, linux-serial, linux-aspeed, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260624-copper-albatross-of-youth-6abae8@quoll>
Hi Krzysztof,
> Please start testing your patches. This for sure fails tests.
>
> It does not look like you tested the DTS against bindings. Please run
> 'make dtbs_check W=1' (see
> Documentation/devicetree/bindings/writing-schema.rst or
> https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
> for instructions).
> Maybe you need to update your dtschema and yamllint. Don't rely on
> distro packages for dtschema and be sure you are using the latest
> released dtschema.
You are right, I had tested my patches but wrongly. It is indeed failling.
I'm very sorry for that. Thank's for taking the time to explain.
Best regards,
Grégoire
^ permalink raw reply
* Re: [PATCH v3 1/7] dt-bindings: serial: 8250: aspeed: add compatible string for ast2600
From: Grégoire Layet @ 2026-06-24 12:48 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt, andrew, jacky_chou, yh_chung, ninad,
anirudhsriniv, linux-serial, linux-aspeed, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260624-realistic-spiked-parrot-db1d9c@quoll>
Hi Krzysztof,
> Do not attach (thread) your patchsets to some other threads (unrelated
> or older versions). This buries them deep in the mailbox and might
> interfere with applying entire sets. See also:
> https://elixir.bootlin.com/linux/v6.16-rc2/source/Documentation/process/submitting-patches.rst#L830
Oh okay sorry I missed this information. Thank's for letting me know !
> This should be oneOf (by convention and actually more accurate meaning).
Acknowledged
> More important, where is documenting of the actual compatible?
Yes, you are right, I missed it. Will be added in v4.
Best regards,
Grégoire
^ permalink raw reply
* Re: [PATCH v3 2/7] dt-bindings: serial: 8250: aspeed: add aspeed,vuart-over-pci bool prop
From: Grégoire Layet @ 2026-06-24 12:48 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt, andrew, jacky_chou, yh_chung, ninad,
anirudhsriniv, linux-serial, linux-aspeed, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260624-original-vigorous-mayfly-dfceac@quoll>
Hi Krzysztof,
> What does that mean? How UART can be accessible over PCI bus?
It's a Virtual UART. Internally, it's two FIFOs accessible via
8250-compatible register sets on both ends.
There is 4 Virtuals UARTs on the LPC bus of the AST2600 and 2 of them
are bridged over the PCI bus.
So, from the host, you can access the 8250 register set on the PCI bus.
> > + aspeed,vuart-over-pci:
> > + type: boolean
> > + default: false
>
> There is no such syntax. Please do not introduce own style. Instead,
> look at other files how this is done.
Ack. I will remove 'default: false' for the v4.
> > + description: |
>
> Do not need '|' unless you need to preserve formatting.
Acknowledged
Best regards,
Grégoire
^ permalink raw reply
* Re: [PATCH next] drivers/tty/serial/kgdboc: Use strscpy() to copy strings into arrays
From: Daniel Thompson @ 2026-06-24 10:33 UTC (permalink / raw)
To: david.laight.linux
Cc: Kees Cook, linux-hardening, kgdb-bugreport, linux-kernel,
linux-serial, Arnd Bergmann, Greg Kroah-Hartman, Jason Wessel,
Jiri Slaby
In-Reply-To: <20260608095523.2606-10-david.laight.linux@gmail.com>
On Mon, Jun 08, 2026 at 10:54:54AM +0100, david.laight.linux@gmail.com wrote:
> From: David Laight <david.laight.linux@gmail.com>
>
> Replacing strcpy() with strscpy() ensures that overflow of the target
> buffer cannot happen.
>
> Signed-off-by: David Laight <david.laight.linux@gmail.com>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Daniel.
^ permalink raw reply
* Re: [PATCH v5] serial: 8250: fix use-after-free in IRQ chain handling
From: Jing Wu @ 2026-06-24 8:43 UTC (permalink / raw)
To: jirislaby
Cc: gregkh, avorontsov, alan, linux-kernel, linux-serial,
wangzhaolong
In-Reply-To: <b7c51606-e95a-4a15-9aff-d0c293ebe986@kernel.org>
From: Qiliang Yuan <realwujing@gmail.com>
On Wed, Jun 24, 2026 at 05:31:59AM +0200, Jiri Slaby wrote:
> So what is the reason to switch from guards to manual locking?
Scope-based guards release the lock at the end of the enclosing block,
but the fix requires hash_mutex to be held across request_irq() and
released at different exit points:
1. IS_ERR(i) -- release hash_mutex and return error.
2. Already in chain -- release i->lock, release hash_mutex, return 0.
3. First port, request_irq() fails -- cleanup under hash_mutex, then
release it and return error.
4. First port, request_irq() succeeds -- release hash_mutex, return 0.
These paths span different nesting levels and early returns, so scope
guards cannot express the required lock lifecycle. The same applies to
i->lock: it must be dropped before calling request_irq() (cannot hold a
spinlock while sleeping), but hash_mutex must remain held across the
call, which also breaks the guard model.
Thanks,
Qiliang
^ permalink raw reply
* Re: [PATCH v3 6/7] ARM: dts: aspeed: g6: Change vuart compatible string for ast2600
From: Krzysztof Kozlowski @ 2026-06-24 7:19 UTC (permalink / raw)
To: Grégoire Layet
Cc: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt, andrew, jacky_chou, yh_chung, ninad,
anirudhsriniv, linux-serial, linux-aspeed, linux-arm-kernel,
linux-kernel
In-Reply-To: <30aedaa9ffd5ba2d763d8802a07b77ef2d5bfcf0.1782224060.git.gregoire.layet@9elements.com>
On Tue, Jun 23, 2026 at 02:25:44PM +0000, Grégoire Layet wrote:
> Use the ast2600 compatible string.
> This makes it more precise and enables specific ast2600 properties.
> Still use the ast2500 compatible string as a fallback.
>
> Signed-off-by: Grégoire Layet <gregoire.layet@9elements.com>
> ---
> arch/arm/boot/dts/aspeed/aspeed-g6.dtsi | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> index 56bb3b0444f7..7c02633f2bd6 100644
> --- a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> +++ b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> @@ -707,7 +707,7 @@ emmc: sdhci@1e750100 {
> };
>
> vuart1: serial@1e787000 {
> - compatible = "aspeed,ast2500-vuart";
> + compatible = "aspeed,ast2600-vuart", "aspeed,ast2500-vuart";
Please start testing your patches. This for sure fails tests.
It does not look like you tested the DTS against bindings. Please run
'make dtbs_check W=1' (see
Documentation/devicetree/bindings/writing-schema.rst or
https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
for instructions).
Maybe you need to update your dtschema and yamllint. Don't rely on
distro packages for dtschema and be sure you are using the latest
released dtschema.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 2/7] dt-bindings: serial: 8250: aspeed: add aspeed,vuart-over-pci bool prop
From: Krzysztof Kozlowski @ 2026-06-24 7:17 UTC (permalink / raw)
To: Grégoire Layet
Cc: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt, andrew, jacky_chou, yh_chung, ninad,
anirudhsriniv, linux-serial, linux-aspeed, linux-arm-kernel,
linux-kernel
In-Reply-To: <73b2bd81ce70814612e6d3cb689c3296de742aaf.1782224059.git.gregoire.layet@9elements.com>
On Tue, Jun 23, 2026 at 02:25:40PM +0000, Grégoire Layet wrote:
> The ASPEED AST2600 has 2 VUART accessible over PCI.
What does that mean? How UART can be accessible over PCI bus?
> This boolean can be set to specify if the VUART is used over PCI.
>
> Signed-off-by: Grégoire Layet <gregoire.layet@9elements.com>
> ---
> .../devicetree/bindings/serial/8250.yaml | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
> index 3cbd0f532e15..b03797f4674d 100644
> --- a/Documentation/devicetree/bindings/serial/8250.yaml
> +++ b/Documentation/devicetree/bindings/serial/8250.yaml
> @@ -26,6 +26,14 @@ allOf:
> anyOf:
> - const: aspeed,ast2500-vuart
> - const: aspeed,ast2600-vuart
> + - if:
> + anyOf:
> + - required:
> + - aspeed,vuart-over-pci
> + then:
> + properties:
> + compatible:
> + const: aspeed,ast2600-vuart
> - if:
> properties:
> compatible:
> @@ -312,6 +320,13 @@ properties:
> polarity (IRQ_TYPE_LEVEL_LOW or IRQ_TYPE_LEVEL_HIGH). Only
> applicable to aspeed,ast2500-vuart and aspeed,ast2600-vuart.
>
> + aspeed,vuart-over-pci:
> + type: boolean
> + default: false
There is no such syntax. Please do not introduce own style. Instead,
look at other files how this is done.
> + description: |
Do not need '|' unless you need to preserve formatting.
> + Enable the VUART over the BMC PCI device. Only applicable to
> + aspeed,ast2600-vuart.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/7] dt-bindings: serial: 8250: aspeed: add compatible string for ast2600
From: Krzysztof Kozlowski @ 2026-06-24 7:15 UTC (permalink / raw)
To: Grégoire Layet
Cc: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt, andrew, jacky_chou, yh_chung, ninad,
anirudhsriniv, linux-serial, linux-aspeed, linux-arm-kernel,
linux-kernel
In-Reply-To: <80d983887dfdfc7e70a6db95f8cb95b7312f3044.1782224059.git.gregoire.layet@9elements.com>
On Tue, Jun 23, 2026 at 02:25:39PM +0000, Grégoire Layet wrote:
> The ast2600 was using the ast2500 vuart compatible string.
> This change makes it possible to have ast2600-specific properties.
>
> Signed-off-by: Grégoire Layet <gregoire.layet@9elements.com>
Do not attach (thread) your patchsets to some other threads (unrelated
or older versions). This buries them deep in the mailbox and might
interfere with applying entire sets. See also:
https://elixir.bootlin.com/linux/v6.16-rc2/source/Documentation/process/submitting-patches.rst#L830
> ---
> .../devicetree/bindings/serial/8250.yaml | 20 +++++++++++--------
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
> index bb7b9c87a807..3cbd0f532e15 100644
> --- a/Documentation/devicetree/bindings/serial/8250.yaml
> +++ b/Documentation/devicetree/bindings/serial/8250.yaml
> @@ -23,7 +23,9 @@ allOf:
> then:
> properties:
> compatible:
> - const: aspeed,ast2500-vuart
> + anyOf:
This should be oneOf (by convention and actually more accurate meaning).
> + - const: aspeed,ast2500-vuart
> + - const: aspeed,ast2600-vuart
> - if:
> properties:
> compatible:
> @@ -287,17 +289,19 @@ properties:
> aspeed,sirq-polarity-sense:
> $ref: /schemas/types.yaml#/definitions/phandle-array
> description: |
> - Phandle to aspeed,ast2500-scu compatible syscon alongside register
> - offset and bit number to identify how the SIRQ polarity should be
> - configured. One possible data source is the LPC/eSPI mode bit. Only
> - applicable to aspeed,ast2500-vuart.
> + Phandle to aspeed,ast2500-scu or aspeed,ast2600-scu compatible syscon
> + alongside register offset and bit number to identify how the SIRQ
> + polarity should be configured. One possible data source is the LPC/eSPI
> + mode bit. Only applicable to aspeed,ast2500-vuart and
> + aspeed,ast2600-vuart.
> deprecated: true
>
> aspeed,lpc-io-reg:
> $ref: /schemas/types.yaml#/definitions/uint32-array
> maxItems: 1
> description: |
> - The VUART LPC address. Only applicable to aspeed,ast2500-vuart.
> + The VUART LPC address. Only applicable to aspeed,ast2500-vuart and
> + aspeed,ast2600-vuart.
>
> aspeed,lpc-interrupts:
> $ref: /schemas/types.yaml#/definitions/uint32-array
> @@ -305,8 +309,8 @@ properties:
> maxItems: 2
> description: |
> A 2-cell property describing the VUART SIRQ number and SIRQ
> - polarity (IRQ_TYPE_LEVEL_LOW or IRQ_TYPE_LEVEL_HIGH). Only
> - applicable to aspeed,ast2500-vuart.
> + polarity (IRQ_TYPE_LEVEL_LOW or IRQ_TYPE_LEVEL_HIGH). Only
> + applicable to aspeed,ast2500-vuart and aspeed,ast2600-vuart.
>
More important, where is documenting of the actual compatible?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5] serial: 8250: fix use-after-free in IRQ chain handling
From: Jiri Slaby @ 2026-06-24 3:31 UTC (permalink / raw)
To: Qiliang Yuan, Greg Kroah-Hartman, Anton Vorontsov, Alan Cox
Cc: linux-kernel, linux-serial, Wang Zhaolong
In-Reply-To: <20260624-bug-221579-8250-shared-irq-race-v5-1-15d841f89e1e@gmail.com>
On 24. 06. 26, 3:21, 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.
>
> 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>
> ---
> V4 -> V5:
> - Add __must_hold(&hash_mutex) annotation to
> serial_get_or_create_irq_info() for static analysis.
>
> 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.
>
> v4: https://lore.kernel.org/r/20260529-bug-221579-8250-shared-irq-race-v4-1-cfda63b4420f@gmail.com
> 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 | 56 ++++++++++++++++++++++++++++---------
> 1 file changed, 43 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
> index a428e88938eb7..a86505c3dcb67 100644
> --- a/drivers/tty/serial/8250/8250_core.c
> +++ b/drivers/tty/serial/8250/8250_core.c
> @@ -131,10 +131,11 @@ static void serial_do_unlink(struct irq_info *i, struct uart_8250_port *up)
> * - allocate a new one, add it to the hashtable and return it.
> */
> static struct irq_info *serial_get_or_create_irq_info(const struct uart_8250_port *up)
> + __must_hold(&hash_mutex)
> {
> struct irq_info *i;
>
> - guard(mutex)(&hash_mutex);
> + lockdep_assert_held(&hash_mutex);
>
> hash_for_each_possible(irq_lists, i, node, up->port.irq)
> if (i->irq == up->port.irq)
> @@ -151,31 +152,60 @@ static struct irq_info *serial_get_or_create_irq_info(const struct uart_8250_por
> return i;
> }
>
> +/*
> + * serial_link_irq_chain() hooks the given 8250 port into the IRQ chain.
> + *
> + * hash_mutex must be held from the hash lookup through the first
> + * request_irq() completion. Dropping it earlier allows a concurrent
> + * serial_unlink_irq_chain() to race in after i->head is published but
> + * before the IRQ is fully set up — another port sharing the IRQ can then
> + * join the chain and run the shared-IRQ THRE test while IRQ startup is
> + * still in progress, triggering an "Unbalanced enable for IRQ" warning
> + * in kernel/irq/manage.c.
> + */
> static int serial_link_irq_chain(struct uart_8250_port *up)
> {
> struct irq_info *i;
> int ret;
>
> + mutex_lock(&hash_mutex);
> +
> i = serial_get_or_create_irq_info(up);
> - if (IS_ERR(i))
> + if (IS_ERR(i)) {
> + mutex_unlock(&hash_mutex);
> return PTR_ERR(i);
> + }
>
> - scoped_guard(spinlock_irq, &i->lock) {
> - if (i->head) {
> - list_add(&up->list, i->head);
> -
> - return 0;
> - }
> + /*
> + * Serialise against the list manipulation in the interrupt handler
> + * and in serial_unlink_irq_chain(). hash_mutex is still held which
> + * prevents serial_unlink_irq_chain() from entering and freeing the
> + * irq_info until the first request_irq() completes.
> + */
> + spin_lock_irq(&i->lock);
> + if (i->head) {
> + list_add(&up->list, i->head);
> + spin_unlock_irq(&i->lock);
> + mutex_unlock(&hash_mutex);
So what is the reason to switch from guards to manual locking?
>
> - INIT_LIST_HEAD(&up->list);
> - i->head = &up->list;
> + return 0;
> }
>
> - ret = request_irq(up->port.irq, serial8250_interrupt, up->port.irqflags, up->port.name, i);
> - if (ret < 0)
> + INIT_LIST_HEAD(&up->list);
> + i->head = &up->list;
> + spin_unlock_irq(&i->lock);
> +
> + ret = request_irq(up->port.irq, serial8250_interrupt,
> + up->port.irqflags, up->port.name, i);
> + if (ret < 0) {
> serial_do_unlink(i, up);
> + mutex_unlock(&hash_mutex);
> + return ret;
> + }
>
> - return ret;
> + mutex_unlock(&hash_mutex);
> +
> + return 0;
> }
>
> static void serial_unlink_irq_chain(struct uart_8250_port *up)
>
> ---
> base-commit: eb3f4b7426cfd2b79d65b7d37155480b32259a11
> change-id: 20260528-bug-221579-8250-shared-irq-race-581e4900a178
>
> Best regards,
--
js
suse labs
^ permalink raw reply
* Re: [PATCH] serial: 8250: serialize shared IRQ startup
From: Wang Zhaolong @ 2026-06-24 2:49 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Ilpo Järvinen, Xin Zhao,
Andy Shevchenko, Kees Cook, Ingo Molnar, Bing Fan, Guanbing Huang,
linux-kernel, linux-serial
Cc: stable
In-Reply-To: <20260527092052.2086342-1-wangzhaolong@fnnas.com>
On Wed, May 27, 2026 at 05:20:51PM +0800, Wang Zhaolong wrote:
> Concurrent startup of two 8250 ports sharing the same IRQ can trigger an
> IRQ core warning:
>
> Unbalanced enable for IRQ 3
> WARNING: CPU: 0 PID: 580 at kernel/irq/manage.c:774 __enable_irq+0x3b/0x60
> Call Trace:
> enable_irq+0x8d/0x120
> serial8250_do_startup+0x80d/0xa80
> uart_port_startup+0x13d/0x440
> uart_port_activate+0x5b/0xb0
> tty_port_open+0xa1/0x120
> uart_open+0x1e/0x30
> tty_open+0x140/0x7a0
>
> The second port can then run the shared-IRQ startup test while the IRQ core
> is still enabling the line for the first port. The local
> disable_irq_nosync()/enable_irq() pair is balanced, but the interleaving can
> still unbalance the IRQ core disable depth.
>
> That makes the QEMU legacy serial ports enter the shared-IRQ THRE test path:
>
> serial8250_do_startup()
> if (port->irqflags & IRQF_SHARED)
> disable_irq_nosync(port->irq)
> ...
> if (port->irqflags & IRQF_SHARED)
> enable_irq(port->irq)
>
> One possible interleaving is:
>
> CPU0, ttyS1 CPU1, ttyS3
>
> serial_link_irq_chain()
> hash_add(i)
> i->head = &ttyS1
> request_irq()
> serial_link_irq_chain()
> find i in irq_lists
> list_add(&ttyS3, i->head)
> serial8250_do_startup()
> disable_irq_nosync(irq)
> irq_startup()
> desc->depth = 0
> enable_irq(irq)
> WARN: Unbalanced enable for IRQ 3
>
> Keep hash_mutex held in serial_link_irq_chain() until the first request_irq()
> has completed. This prevents another 8250 port sharing the IRQ from joining
> the chain and running the THRE test while the IRQ core is still starting the
> interrupt.
>
> This was reproduced in QEMU with ttyS1 and ttyS3 sharing IRQ 3. With this
> change, 100000 synchronized open/close iterations on /dev/ttyS1 and /dev/ttyS3
> completed without the warning.
>
> Fixes: 64c79dfbc458 ("serial: 8250_pnp: Support configurable reg shift property")
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221579
> Cc: stable@vger.kernel.org # 6.10+
> Assisted-by: Codex:gpt-5
> Signed-off-by: Wang Zhaolong <wangzhaolong@fnnas.com>
> ---
> drivers/tty/serial/8250/8250_core.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
> index a428e88938eb..64eed4dc343f 100644
> --- a/drivers/tty/serial/8250/8250_core.c
> +++ b/drivers/tty/serial/8250/8250_core.c
> @@ -132,12 +132,10 @@ static void serial_do_unlink(struct irq_info *i, struct uart_8250_port *up)
> */
> static struct irq_info *serial_get_or_create_irq_info(const struct uart_8250_port *up)
> {
> struct irq_info *i;
>
> - guard(mutex)(&hash_mutex);
> -
> hash_for_each_possible(irq_lists, i, node, up->port.irq)
> if (i->irq == up->port.irq)
> return i;
>
> i = kzalloc_obj(*i);
> @@ -154,10 +152,12 @@ static struct irq_info *serial_get_or_create_irq_info(const struct uart_8250_por
> static int serial_link_irq_chain(struct uart_8250_port *up)
> {
> struct irq_info *i;
> int ret;
>
> + guard(mutex)(&hash_mutex);
> +
> i = serial_get_or_create_irq_info(up);
> if (IS_ERR(i))
> return PTR_ERR(i);
>
> scoped_guard(spinlock_irq, &i->lock) {
> @@ -169,10 +169,15 @@ static int serial_link_irq_chain(struct uart_8250_port *up)
>
> INIT_LIST_HEAD(&up->list);
> i->head = &up->list;
> }
>
> + /*
> + * Keep the shared-IRQ chain locked until the first handler is installed.
> + * Otherwise another UART can join early and run startup IRQ masking while
> + * the IRQ core is still enabling the line, unbalancing the disable depth.
> + */
> ret = request_irq(up->port.irq, serial8250_interrupt, up->port.irqflags, up->port.name, i);
> if (ret < 0)
> serial_do_unlink(i, up);
>
> return ret;
> --
> 2.54.0
Hi Maintainers,
Friendly ping on this patch.
This is a clean and simple one-line relocation fix for the shared IRQ race condition.
I noticed there is another ongoing thread attempting to address the same bug with a
much more complex approach, but it seems to miss the regression test cases.
Could you please take a look at this simpler alternative when you have time? Any
feedback or reviews would be highly appreciated.
Thanks,
Wang
^ permalink raw reply
* [PATCH v5] serial: 8250: fix use-after-free in IRQ chain handling
From: Qiliang Yuan @ 2026-06-24 1:21 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Anton Vorontsov, Alan Cox
Cc: linux-kernel, linux-serial, Wang Zhaolong, Qiliang Yuan
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.
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>
---
V4 -> V5:
- Add __must_hold(&hash_mutex) annotation to
serial_get_or_create_irq_info() for static analysis.
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.
v4: https://lore.kernel.org/r/20260529-bug-221579-8250-shared-irq-race-v4-1-cfda63b4420f@gmail.com
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 | 56 ++++++++++++++++++++++++++++---------
1 file changed, 43 insertions(+), 13 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
index a428e88938eb7..a86505c3dcb67 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -131,10 +131,11 @@ static void serial_do_unlink(struct irq_info *i, struct uart_8250_port *up)
* - allocate a new one, add it to the hashtable and return it.
*/
static struct irq_info *serial_get_or_create_irq_info(const struct uart_8250_port *up)
+ __must_hold(&hash_mutex)
{
struct irq_info *i;
- guard(mutex)(&hash_mutex);
+ lockdep_assert_held(&hash_mutex);
hash_for_each_possible(irq_lists, i, node, up->port.irq)
if (i->irq == up->port.irq)
@@ -151,31 +152,60 @@ static struct irq_info *serial_get_or_create_irq_info(const struct uart_8250_por
return i;
}
+/*
+ * serial_link_irq_chain() hooks the given 8250 port into the IRQ chain.
+ *
+ * hash_mutex must be held from the hash lookup through the first
+ * request_irq() completion. Dropping it earlier allows a concurrent
+ * serial_unlink_irq_chain() to race in after i->head is published but
+ * before the IRQ is fully set up — another port sharing the IRQ can then
+ * join the chain and run the shared-IRQ THRE test while IRQ startup is
+ * still in progress, triggering an "Unbalanced enable for IRQ" warning
+ * in kernel/irq/manage.c.
+ */
static int serial_link_irq_chain(struct uart_8250_port *up)
{
struct irq_info *i;
int ret;
+ mutex_lock(&hash_mutex);
+
i = serial_get_or_create_irq_info(up);
- if (IS_ERR(i))
+ if (IS_ERR(i)) {
+ mutex_unlock(&hash_mutex);
return PTR_ERR(i);
+ }
- scoped_guard(spinlock_irq, &i->lock) {
- if (i->head) {
- list_add(&up->list, i->head);
-
- return 0;
- }
+ /*
+ * Serialise against the list manipulation in the interrupt handler
+ * and in serial_unlink_irq_chain(). hash_mutex is still held which
+ * prevents serial_unlink_irq_chain() from entering and freeing the
+ * irq_info until the first request_irq() completes.
+ */
+ spin_lock_irq(&i->lock);
+ if (i->head) {
+ list_add(&up->list, i->head);
+ spin_unlock_irq(&i->lock);
+ mutex_unlock(&hash_mutex);
- INIT_LIST_HEAD(&up->list);
- i->head = &up->list;
+ return 0;
}
- ret = request_irq(up->port.irq, serial8250_interrupt, up->port.irqflags, up->port.name, i);
- if (ret < 0)
+ INIT_LIST_HEAD(&up->list);
+ i->head = &up->list;
+ spin_unlock_irq(&i->lock);
+
+ ret = request_irq(up->port.irq, serial8250_interrupt,
+ up->port.irqflags, up->port.name, i);
+ if (ret < 0) {
serial_do_unlink(i, up);
+ mutex_unlock(&hash_mutex);
+ return ret;
+ }
- return ret;
+ mutex_unlock(&hash_mutex);
+
+ return 0;
}
static void serial_unlink_irq_chain(struct uart_8250_port *up)
---
base-commit: eb3f4b7426cfd2b79d65b7d37155480b32259a11
change-id: 20260528-bug-221579-8250-shared-irq-race-581e4900a178
Best regards,
--
Jing Wu <realwujing@gmail.com>
^ permalink raw reply related
* Re: [PATCH v2 2/2] dt-bindings: Drop incorrect usage of double '::'
From: Andi Shyti @ 2026-06-23 20:26 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-arm-msm, devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc, linux-clk, dri-devel, freedreno, linux-i2c,
linux-pm, linux-leds, linux-media, linux-mmc, linux-phy,
linux-gpio, linux-renesas-soc, linux-serial, linux-sound,
linux-usb
In-Reply-To: <20260623054842.21831-4-krzysztof.kozlowski@oss.qualcomm.com>
Hi Krzysztof,
On Tue, Jun 23, 2026 at 07:48:44AM +0200, Krzysztof Kozlowski wrote:
> There is no use of double colon '::' in YAML. OTOH, the literal style
> block, e.g. using '|' treats all characters as content [1] therefore
> single use of ':' in descriptions is perfectly fine, whenever '|' is
> used.
>
> Cleanup existing code, so the confusing style won't be re-used in new
> contributions.
>
> Link: https://yaml.org/spec/1.2.2/#literal-style [1]
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Acked-by: Alim Akhtar <alim.akhtar@samsung.com>
> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> Acked-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> Acked-by: Mark Brown <broonie@kernel.org>
> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> # renesas
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Acked-by: Andi Shyti <andi.shyti@kernel.org>
Thanks,
Andi
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: clock: Drop incorrect usage of double '::'
From: Andi Shyti @ 2026-06-23 20:26 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-arm-msm, devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc, linux-clk, dri-devel, freedreno, linux-i2c,
linux-pm, linux-leds, linux-media, linux-mmc, linux-phy,
linux-gpio, linux-renesas-soc, linux-serial, linux-sound,
linux-usb
In-Reply-To: <20260623054842.21831-3-krzysztof.kozlowski@oss.qualcomm.com>
Hi Krzysztof,
On Tue, Jun 23, 2026 at 07:48:43AM +0200, Krzysztof Kozlowski wrote:
> There is no use of double colon '::' in YAML. OTOH, the literal style
> block, e.g. using '|' treats all characters as content [1] therefore
> single use of ':' in descriptions is perfectly fine, whenever '|' is
> used.
>
> Cleanup existing code, so the confusing style won't be re-used in new
> contributions.
>
> Link: https://yaml.org/spec/1.2.2/#literal-style [1]
> Acked-by: Alim Akhtar <alim.akhtar@samsung.com>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Acked-by: Andi Shyti <andi.shyti@kernel.org>
Thanks,
Andi
^ permalink raw reply
* Re: [PATCH 2/2] serial: sc16is7xx: set TX FIFO trigger level to half FIFO to prevent underruns
From: David Laight @ 2026-06-23 18:42 UTC (permalink / raw)
To: Paul Mbewe
Cc: linux-serial, linux-kernel, gregkh, jirislaby, hvilleneuve,
stable, tobias.gannert, joachim.knorr
In-Reply-To: <20260623171328.153735-1-paultyson.mbewe@ziehl-abegg.de>
On Tue, 23 Jun 2026 19:13:28 +0200
Paul Mbewe <paultyson.mbewe@ziehl-abegg.de> wrote:
> Hi David,
>
> On the test system, the relevant threads already run with RT priority:
>
> irq/134-spi2.0 SCHED_FIFO priority 50
> sc16is7xx SCHED_FIFO priority 50
>
> So this is not caused by the IRQ thread running as a normal SCHED_OTHER
> task. That does not remove all latency sources, of course; on this
> single-core SPI system the threaded IRQ can still be affected by other
> RT/kernel activity, IRQ/preemption-disabled sections, SPI transfer time,
> or lock contention.
>
> I agree, changing the TX trigger from 8 to 32 free spaces reduces the
> per-interrupt time-to-empty margin. With an 8-space trigger the FIFO
> still contains 56 bytes when THRI asserts, while with a 32-space trigger
> it contains 32 bytes. So the v1 commit message is misleading when it
> describes this as increasing the refill window.
>
> The observed effect is instead that the 8-space trigger causes many
> small TX refill events. Each event has roughly the same cost, as you
> said. If the handler runs in time, it can catch up by seeing more than
> 8 free spaces and writing more data. The failure happens when one event
> is delayed long enough for the FIFO to drain.
>
> Using a 32-space trigger reduces the number of refill events and the
> associated IRQ/SPI load. It also reduces the chance that one delayed
> event lets the FIFO drain completely. On the tested setup this reduced
> irq/134-spi2.0 CPU usage from about 15-17% to about 5%, sys CPU from
> about 51-61% to about 19-28%, and load average from about 2.0-2.2 to
> about 0.65-1.3. With that change, the observed TX gaps disappeared.
Even with those figures (and the cpu % differences seem reasonable)
I still don't see why it stops the underruns.
An interesting exercise would be to call to ftrace_stop() when the
tx fifo is unexpectedly nearly empty.
Then enable all the ftrace scheduler and interrupt events (they don't
normally slow things down that much) and run the test with ftrace enabled.
When the trace gets stopped (you can just 'cat tracing_on' to find out
when it has been stopped) just 'less trace' to see what happened.
I think that will show that the isr thread is scheduled but doesn't
run for a while because something else is 'hogging' the cpu.
I've used this set of events - seemed to be useful.
Clear old events
echo >set_event
System call entry and exit:
echo 'syscalls:*' >>set_event
IRQ entry and exit:
echo irq:irq_handler_entry irq:irq_handler_exit >>set_event
echo irq:softirq_entry irq:softirq_exit >>set_event
Scheduler process switch events:
echo sched:sched_switch >>set_event
echo sched:sched_wakeup sched:sched_wakeup_new >>set_event
echo sched:sched_migrate_task >>set_event
David
>
> So I agree the commit message should be reworked to describe this as
> reducing TX refill events and IRQ/SPI load, not as increasing the
> per-interrupt latency margin.
>
> If changing the default trigger globally is considered too broad, I can
> also look at making the TX trigger configurable or limiting the change to
> SPI-backed devices.
>
> Thanks
> Paul
>
> _______________________________________
>
> ZIEHL-ABEGG
>
> Executive Board: Joachim Ley (Chairman), Marco Altherr, Wolfgang Mayer
> Supervisory Board: Dennis Ziehl (Chairman)
>
> Court of Registry: District Court Stuttgart HRB 746188
> Company Seat: Künzelsau, Germany
>
> Der Inhalt dieser E-Mail und/oder jegliche Anhänge können vertrauliche Mitteilungen enthalten und sind ausschließlich für den bezeichneten Adressaten bestimmt.
> Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein sollten, so beachten Sie bitte, dass jede Form der Kenntnisnahme, Veröffentlichung,
> Vervielfältigung oder Weitergabe des Inhalts dieser E-Mail einschließlich Anhängen unzulässig ist.
> Wir bitten Sie, sich in diesem Fall mit dem Absender der E-Mail in Verbindung zu setzen.
>
> The content of this e-mail and/or attachments may contain confidential information and is intended solely for the named recipient.
> If you are not the intended recipient of this e-mail or on its distribution list, please note that any type of disclosure, publication,
> copying or distribution of the content of this e-mail including attachments is strictly forbidden.
> In this case, we would kindly ask you to notify the sender of the e-mail.
^ permalink raw reply
* Re: [PATCH 2/2] serial: sc16is7xx: set TX FIFO trigger level to half FIFO to prevent underruns
From: Paul Mbewe @ 2026-06-23 17:13 UTC (permalink / raw)
To: david.laight.linux
Cc: linux-serial, linux-kernel, gregkh, jirislaby, hvilleneuve,
stable, tobias.gannert, joachim.knorr, Paul Mbewe
In-Reply-To: <20260623160759.506f456e@pumpkin>
Hi David,
On the test system, the relevant threads already run with RT priority:
irq/134-spi2.0 SCHED_FIFO priority 50
sc16is7xx SCHED_FIFO priority 50
So this is not caused by the IRQ thread running as a normal SCHED_OTHER
task. That does not remove all latency sources, of course; on this
single-core SPI system the threaded IRQ can still be affected by other
RT/kernel activity, IRQ/preemption-disabled sections, SPI transfer time,
or lock contention.
I agree, changing the TX trigger from 8 to 32 free spaces reduces the
per-interrupt time-to-empty margin. With an 8-space trigger the FIFO
still contains 56 bytes when THRI asserts, while with a 32-space trigger
it contains 32 bytes. So the v1 commit message is misleading when it
describes this as increasing the refill window.
The observed effect is instead that the 8-space trigger causes many
small TX refill events. Each event has roughly the same cost, as you
said. If the handler runs in time, it can catch up by seeing more than
8 free spaces and writing more data. The failure happens when one event
is delayed long enough for the FIFO to drain.
Using a 32-space trigger reduces the number of refill events and the
associated IRQ/SPI load. It also reduces the chance that one delayed
event lets the FIFO drain completely. On the tested setup this reduced
irq/134-spi2.0 CPU usage from about 15-17% to about 5%, sys CPU from
about 51-61% to about 19-28%, and load average from about 2.0-2.2 to
about 0.65-1.3. With that change, the observed TX gaps disappeared.
So I agree the commit message should be reworked to describe this as
reducing TX refill events and IRQ/SPI load, not as increasing the
per-interrupt latency margin.
If changing the default trigger globally is considered too broad, I can
also look at making the TX trigger configurable or limiting the change to
SPI-backed devices.
Thanks
Paul
^ permalink raw reply
* Re: [PATCH] tty: serial: pch_uart: add check for pci_get_slot()
From: Andy Shevchenko @ 2026-06-23 16:03 UTC (permalink / raw)
To: Haoxiang Li
Cc: gregkh, jirislaby, fourier.thomas, 2426767509, kees, linux-kernel,
linux-serial, stable
In-Reply-To: <20260623140539.2272473-1-haoxiang_li2024@163.com>
On Tue, Jun 23, 2026 at 10:05:39PM +0800, Haoxiang Li wrote:
> Add check for pci_get_slot() to prevent a potetial
> null pointer dereference in pch_request_dma().
Not that it's quite possible, but probably you found this due to AI review
which might have considered some cases of manual binding a PCI device to any
PCI driver.
Given that is the case, I'm fine with the change.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 2/2] serial: sc16is7xx: set TX FIFO trigger level to half FIFO to prevent underruns
From: David Laight @ 2026-06-23 15:07 UTC (permalink / raw)
To: Paul Mbewe
Cc: linux-serial, linux-kernel, gregkh, jirislaby, hvilleneuve,
stable, tobias.gannert, joachim.knorr
In-Reply-To: <20260623140155.13258-1-paultyson.mbewe@ziehl-abegg.de>
On Tue, 23 Jun 2026 16:01:55 +0200
Paul Mbewe <paultyson.mbewe@ziehl-abegg.de> wrote:
> Hi David,
>
> Thanks for the detailed review.
>
> According to the SC16IS7xx datasheet, the TX trigger level is defined
> in terms of free FIFO spaces, not remaining data. So with the default
> configuration (FCR[5:4] = 00), the THRI interrupt fires when the FIFO
> has 8 free entries, i.e. when it still contains 56 bytes.
>
> While this in theory leaves enough data in the FIFO, in practice the
> system has to service many small refill cycles (~8 bytes per interrupt).
> On slow SPI hosts, each cycle involves threaded interrupt handling and
> multiple SPI transactions, and the cumulative latency plus scheduling
> jitter can exceed the available margin between refills under load.
But that cost/time is much the same regardless of the trigger level.
Changing the level from 8 to 32 significantly reduces the allowable
latency.
> Increasing the trigger level to 32 free spaces reduces the number of
> refill cycles significantly (from ~8 per FIFO load to ~2), and increases
> the amount of data written per cycle. This reduces scheduling pressure
> and, in practice, avoids the FIFO draining to empty between bursts.
But shouldn't it should all catch up.
The isr thread should start finding more than 8 bytes space in the fifo,
write enough bytes to fill it and the next interrupt should happen about
8 byte times after the previous one finishes.
That does rely on nothing 'going wrong' between the hardware interrupt
and the isr thread.
What priority does the isr thread run at?
If it isn't running at an RT priority then the scheduler might decide
to reduce its priority which could easily generate what you are seeing.
I'll agree that changing the threshold reduces system load - so should
give extra time for 'other work'.
But I don't really see why it be the correct way to stop underruns.
David
>
> The current commit message focuses too much on the "refill window" and
> does not explain this aspect clearly. I can rephrase it to better
> describe the interaction between trigger level, refill granularity and
> system latency.
>
> Thanks,
> Paul
>
> _______________________________________
>
> ZIEHL-ABEGG
>
> Executive Board: Joachim Ley (Chairman), Marco Altherr, Wolfgang Mayer
> Supervisory Board: Dennis Ziehl (Chairman)
>
> Court of Registry: District Court Stuttgart HRB 746188
> Company Seat: Künzelsau, Germany
>
> Der Inhalt dieser E-Mail und/oder jegliche Anhänge können vertrauliche Mitteilungen enthalten und sind ausschließlich für den bezeichneten Adressaten bestimmt.
> Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein sollten, so beachten Sie bitte, dass jede Form der Kenntnisnahme, Veröffentlichung,
> Vervielfältigung oder Weitergabe des Inhalts dieser E-Mail einschließlich Anhängen unzulässig ist.
> Wir bitten Sie, sich in diesem Fall mit dem Absender der E-Mail in Verbindung zu setzen.
>
> The content of this e-mail and/or attachments may contain confidential information and is intended solely for the named recipient.
> If you are not the intended recipient of this e-mail or on its distribution list, please note that any type of disclosure, publication,
> copying or distribution of the content of this e-mail including attachments is strictly forbidden.
> In this case, we would kindly ask you to notify the sender of the e-mail.
^ permalink raw reply
* Re: [PATCH v4] serial: 8250: fix use-after-free in IRQ chain handling
From: Jing Wu @ 2026-06-23 14:32 UTC (permalink / raw)
To: gregkh
Cc: jirislaby, avorontsov, alan, linux-kernel, linux-serial,
wangzhaolong
In-Reply-To: <2026061213-blinker-portable-a198@gregkh>
From: Qiliang Yuan <realwujing@gmail.com>
On Fri, Jun 12, 2026 at 11:49:51AM +0200, Greg Kroah-Hartman wrote:
> What real systems causes this to happen? How are you triggering this
> warning to happen? How was this tested?
The original report is Bugzilla #221579 from Wang Zhaolong. The bug
triggers on systems with multiple 8250 serial ports sharing an IRQ
(e.g. NAS-like devices). It can be reproduced by probing/removing
8250 serial ports that share an IRQ. Wang confirmed off-list that v3
fixes the reproducer on his setup.
> 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 :(
Agreed, will add __must_hold(&hash_mutex) in v5.
Thanks,
Qiliang
^ permalink raw reply
* [PATCH v3 7/7] ARM: dts: aspeed: g6: add aspeed,vuart-over-pci prop to vuart3 and 4
From: Grégoire Layet @ 2026-06-23 14:25 UTC (permalink / raw)
To: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt
Cc: andrew, jacky_chou, yh_chung, ninad, anirudhsriniv, linux-serial,
linux-aspeed, linux-arm-kernel, linux-kernel, Grégoire Layet
In-Reply-To: <cover.1782224059.git.gregoire.layet@9elements.com>
The VUART 3 and 4 are VUART over PCI.
This flag indicates this information.
Signed-off-by: Grégoire Layet <gregoire.layet@9elements.com>
---
arch/arm/boot/dts/aspeed/aspeed-g6.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
index 7c02633f2bd6..2a19463b4c21 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
+++ b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
@@ -723,6 +723,7 @@ vuart3: serial@1e787800 {
interrupts = <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&syscon ASPEED_CLK_APB2>;
no-loopback-test;
+ aspeed,vuart-over-pci;
status = "disabled";
};
@@ -743,6 +744,7 @@ vuart4: serial@1e788800 {
interrupts = <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&syscon ASPEED_CLK_APB2>;
no-loopback-test;
+ aspeed,vuart-over-pci;
status = "disabled";
};
--
2.54.0
^ permalink raw reply related
* [PATCH v3 6/7] ARM: dts: aspeed: g6: Change vuart compatible string for ast2600
From: Grégoire Layet @ 2026-06-23 14:25 UTC (permalink / raw)
To: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt
Cc: andrew, jacky_chou, yh_chung, ninad, anirudhsriniv, linux-serial,
linux-aspeed, linux-arm-kernel, linux-kernel, Grégoire Layet
In-Reply-To: <cover.1782224059.git.gregoire.layet@9elements.com>
Use the ast2600 compatible string.
This makes it more precise and enables specific ast2600 properties.
Still use the ast2500 compatible string as a fallback.
Signed-off-by: Grégoire Layet <gregoire.layet@9elements.com>
---
arch/arm/boot/dts/aspeed/aspeed-g6.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
index 56bb3b0444f7..7c02633f2bd6 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
+++ b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
@@ -707,7 +707,7 @@ emmc: sdhci@1e750100 {
};
vuart1: serial@1e787000 {
- compatible = "aspeed,ast2500-vuart";
+ compatible = "aspeed,ast2600-vuart", "aspeed,ast2500-vuart";
reg = <0x1e787000 0x40>;
reg-shift = <2>;
interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>;
@@ -717,7 +717,7 @@ vuart1: serial@1e787000 {
};
vuart3: serial@1e787800 {
- compatible = "aspeed,ast2500-vuart";
+ compatible = "aspeed,ast2600-vuart", "aspeed,ast2500-vuart";
reg = <0x1e787800 0x40>;
reg-shift = <2>;
interrupts = <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>;
@@ -727,7 +727,7 @@ vuart3: serial@1e787800 {
};
vuart2: serial@1e788000 {
- compatible = "aspeed,ast2500-vuart";
+ compatible = "aspeed,ast2600-vuart", "aspeed,ast2500-vuart";
reg = <0x1e788000 0x40>;
reg-shift = <2>;
interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
@@ -737,7 +737,7 @@ vuart2: serial@1e788000 {
};
vuart4: serial@1e788800 {
- compatible = "aspeed,ast2500-vuart";
+ compatible = "aspeed,ast2600-vuart", "aspeed,ast2500-vuart";
reg = <0x1e788800 0x40>;
reg-shift = <2>;
interrupts = <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>;
--
2.54.0
^ permalink raw reply related
* [PATCH v3 5/7] soc: aspeed: add host-side PCIe BMC device driver
From: Grégoire Layet @ 2026-06-23 14:25 UTC (permalink / raw)
To: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt
Cc: andrew, jacky_chou, yh_chung, ninad, anirudhsriniv, linux-serial,
linux-aspeed, linux-arm-kernel, linux-kernel, Grégoire Layet
In-Reply-To: <cover.1782224059.git.gregoire.layet@9elements.com>
Add support for VUART over PCIe between BMC and host.
This add host side driver.
This only support the AST2600.
Taken from ASPEED 6.18 Kernel SDK and trimmed down.
The host can't detect the VUART adresses, they are forced
at 0x3f8 and 0x2f8, similar from the initial ASPEED driver.
The MSI vector index has been changed for the VUART2 from 15 to 17.
The index 15 used in the initial driver was not working.
Data path in both direction is tested on both VUART.
Signed-off-by: Jacky Chou <jacky_chou@aspeedtech.com>
Signed-off-by: aspeedyh <yh_chung@aspeedtech.com>
Signed-off-by: Grégoire Layet <gregoire.layet@9elements.com>
Tested-by: Grégoire Layet <gregoire.layet@9elements.com>
---
drivers/soc/aspeed/Kconfig | 8 +
drivers/soc/aspeed/Makefile | 1 +
drivers/soc/aspeed/aspeed-host-bmc-dev.c | 183 +++++++++++++++++++++++
3 files changed, 192 insertions(+)
create mode 100644 drivers/soc/aspeed/aspeed-host-bmc-dev.c
diff --git a/drivers/soc/aspeed/Kconfig b/drivers/soc/aspeed/Kconfig
index 63a656449a1a..ebd023b10701 100644
--- a/drivers/soc/aspeed/Kconfig
+++ b/drivers/soc/aspeed/Kconfig
@@ -4,6 +4,14 @@ if ARCH_ASPEED || COMPILE_TEST
menu "ASPEED SoC drivers"
+config ASPEED_HOST_BMC_DEV
+ tristate "ASPEED Host BMC Device"
+ depends on PCI
+ depends on SERIAL_8250
+ help
+ Enable support for the ASPEED AST2600 BMC Device on the Host.
+ This configure the PCIe and setup two 8250 compatible VUART ports.
+
config ASPEED_LPC_CTRL
tristate "ASPEED LPC firmware cycle control"
select REGMAP
diff --git a/drivers/soc/aspeed/Makefile b/drivers/soc/aspeed/Makefile
index b35d74592964..c515e163eab7 100644
--- a/drivers/soc/aspeed/Makefile
+++ b/drivers/soc/aspeed/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_ASPEED_HOST_BMC_DEV) += aspeed-host-bmc-dev.o
obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
obj-$(CONFIG_ASPEED_LPC_SNOOP) += aspeed-lpc-snoop.o
obj-$(CONFIG_ASPEED_UART_ROUTING) += aspeed-uart-routing.o
diff --git a/drivers/soc/aspeed/aspeed-host-bmc-dev.c b/drivers/soc/aspeed/aspeed-host-bmc-dev.c
new file mode 100644
index 000000000000..3160b6aedb5b
--- /dev/null
+++ b/drivers/soc/aspeed/aspeed-host-bmc-dev.c
@@ -0,0 +1,183 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+// Copyright (C) ASPEED Technology Inc.
+
+#include <linux/init.h>
+#include <linux/version.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/pci.h>
+#include <linux/serial_core.h>
+#include <linux/serial_8250.h>
+
+#define BMC_MULTI_MSI 32
+#define PCI_BMC_DEVICE_ID 0x2402
+
+#define DRIVER_NAME "aspeed-host-bmc-dev"
+
+enum aspeed_platform_id {
+ ASPEED,
+};
+
+static int vuart_msi_index[2] = { 16, 17 };
+static int vuart_port_addr[2] = {0x3f8, 0x2f8};
+
+struct aspeed_pci_bmc_dev {
+ struct device *dev;
+ kernel_ulong_t driver_data;
+ int id;
+
+ unsigned long message_bar_base;
+
+ struct uart_8250_port uart[2];
+ int uart_line[2];
+
+ int *msi_idx_table;
+};
+
+static void aspeed_pci_setup_irq_resource(struct pci_dev *pdev)
+{
+ struct aspeed_pci_bmc_dev *pci_bmc_dev = pci_get_drvdata(pdev);
+
+ pci_bmc_dev->msi_idx_table = vuart_msi_index;
+
+ if (pci_alloc_irq_vectors(pdev, 1, BMC_MULTI_MSI, PCI_IRQ_INTX | PCI_IRQ_MSI) <= 1)
+ /* If pci_alloc fail, set all msi index to the first vector */
+ memset(pci_bmc_dev->msi_idx_table, 0, sizeof(vuart_msi_index));
+}
+
+static int aspeed_pci_bmc_device_setup_vuart(struct pci_dev *pdev, int idx)
+{
+ struct aspeed_pci_bmc_dev *pci_bmc_dev = pci_get_drvdata(pdev);
+ struct device *dev = &pdev->dev;
+ struct uart_8250_port *uart = &pci_bmc_dev->uart[idx];
+ u16 vuart_ioport;
+ int ret;
+
+ /* Assign the line to non-exist device before everything is setup */
+ pci_bmc_dev->uart_line[idx] = -ENOENT;
+
+ vuart_ioport = vuart_port_addr[idx];
+ /* ASPEED BMC device shift adresses by 2 to the left */
+ vuart_ioport = vuart_ioport << 2;
+
+ uart->port.flags = UPF_SKIP_TEST | UPF_BOOT_AUTOCONF | UPF_SHARE_IRQ;
+ uart->port.uartclk = 115200 * 16;
+ uart->port.irq = pci_irq_vector(pdev, pci_bmc_dev->msi_idx_table[idx]);
+ uart->port.dev = dev;
+ uart->port.iotype = UPIO_MEM32;
+ uart->port.iobase = 0;
+ uart->port.mapbase = pci_bmc_dev->message_bar_base + vuart_ioport;
+ uart->port.membase = 0;
+ uart->port.type = PORT_16550A;
+ uart->port.flags |= (UPF_IOREMAP | UPF_FIXED_PORT | UPF_FIXED_TYPE);
+ uart->port.regshift = 2;
+
+ ret = serial8250_register_8250_port(&pci_bmc_dev->uart[idx]);
+ if (ret < 0) {
+ dev_err_probe(dev, ret, "Can't setup PCIe VUART%d\n", idx);
+ return ret;
+ }
+
+ pci_bmc_dev->uart_line[idx] = ret;
+
+ return 0;
+}
+
+static void aspeed_pci_host_bmc_device_release_vuart(struct pci_dev *pdev, int idx)
+{
+ struct aspeed_pci_bmc_dev *pci_bmc_dev = pci_get_drvdata(pdev);
+
+ if (pci_bmc_dev->uart_line[idx] >= 0)
+ serial8250_unregister_port(pci_bmc_dev->uart_line[idx]);
+}
+
+static int aspeed_pci_host_setup(struct pci_dev *pdev)
+{
+ struct aspeed_pci_bmc_dev *pci_bmc_dev = pci_get_drvdata(pdev);
+ int rc = 0;
+
+ pci_bmc_dev->message_bar_base = pci_resource_start(pdev, 1);
+
+ if (pdev->revision == 0x27) {
+ pr_err("AST2700 detected but not supported");
+ return -ENODEV;
+ }
+
+ rc = aspeed_pci_bmc_device_setup_vuart(pdev, 0);
+ if (rc)
+ return rc;
+
+ rc = aspeed_pci_bmc_device_setup_vuart(pdev, 1);
+ if (rc)
+ goto out_freeVUART1;
+
+ return 0;
+
+out_freeVUART1:
+ aspeed_pci_host_bmc_device_release_vuart(pdev, 0);
+
+ return rc;
+}
+
+static int aspeed_pci_host_bmc_device_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
+{
+ struct aspeed_pci_bmc_dev *pci_bmc_dev;
+ int rc = 0;
+
+ pci_bmc_dev = devm_kzalloc(&pdev->dev, sizeof(*pci_bmc_dev), GFP_KERNEL);
+ if (!pci_bmc_dev)
+ return -ENOMEM;
+
+ rc = pci_enable_device(pdev);
+ if (rc) {
+ dev_err(&pdev->dev, "pci_enable_device() returned error %d\n", rc);
+ return rc;
+ }
+
+ pci_set_master(pdev);
+ pci_set_drvdata(pdev, pci_bmc_dev);
+
+ aspeed_pci_setup_irq_resource(pdev);
+
+ /* Setup BMC PCI device */
+ rc = aspeed_pci_host_setup(pdev);
+ if (rc) {
+ dev_err(&pdev->dev, "ASPEED PCIe Host device returned error %d\n", rc);
+ pci_free_irq_vectors(pdev);
+ pci_disable_device(pdev);
+ return rc;
+ }
+
+ return 0;
+}
+
+static void aspeed_pci_host_bmc_device_remove(struct pci_dev *pdev)
+{
+ aspeed_pci_host_bmc_device_release_vuart(pdev, 0);
+ aspeed_pci_host_bmc_device_release_vuart(pdev, 1);
+
+ pci_free_irq_vectors(pdev);
+ pci_disable_device(pdev);
+}
+
+static struct pci_device_id aspeed_host_bmc_dev_pci_ids[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_ASPEED, PCI_BMC_DEVICE_ID), .class = 0xFF0000, .class_mask = 0xFFFF00,
+ .driver_data = ASPEED },
+ { 0 }
+};
+
+MODULE_DEVICE_TABLE(pci, aspeed_host_bmc_dev_pci_ids);
+
+static struct pci_driver aspeed_host_bmc_dev_driver = {
+ .name = DRIVER_NAME,
+ .id_table = aspeed_host_bmc_dev_pci_ids,
+ .probe = aspeed_pci_host_bmc_device_probe,
+ .remove = aspeed_pci_host_bmc_device_remove,
+};
+
+module_driver(aspeed_host_bmc_dev_driver, pci_register_driver, pci_unregister_driver);
+
+MODULE_AUTHOR("Ryan Chen <ryan_chen@aspeedtech.com>");
+MODULE_DESCRIPTION("ASPEED Host BMC DEVICE Driver");
+MODULE_LICENSE("GPL");
--
2.54.0
^ permalink raw reply related
* [PATCH v3 4/7] serial: 8250_aspeed_vuart: add VUART over PCI
From: Grégoire Layet @ 2026-06-23 14:25 UTC (permalink / raw)
To: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt
Cc: andrew, jacky_chou, yh_chung, ninad, anirudhsriniv, linux-serial,
linux-aspeed, linux-arm-kernel, linux-kernel, Grégoire Layet
In-Reply-To: <cover.1782224059.git.gregoire.layet@9elements.com>
This patch enables the VUART over PCI possible for the AST2600. This is
only activated if the 'aspeed,vuart-over-pci' property flag is set on an
'ast2600-vuart' compatible node.
The AST2600 has 2 VUART that are usable over PCI. These are the VUART3
and VUART4 in the 'apseed-g6.dtsi'.
This code sets the BMC PCI device enables
bits, sets the PCI class code to MFD device and configures MSI interrupts.
There is no disable function. Removing this driver should not disable
the BMC PCI device, as other drivers could use it.
However, if all the drivers using it are removed, the
BMC PCI device will still be activated, which is not ideal. Realistically though, this is not a
use case for a BMC, the drivers will never be removed.
This is useful on PCIe BMC expansion cards that use the AST2600, such as the
ASUS Kommando IPMI Expansion Card.
Registers initialisation taken from ASPEED 6.18 Kernel SDK.
Return code checks were added to each register write.
The code has been simplified and macros have been added.
The ASPEED_SCUC24 regmap update is missing a macro for 'BIT(14)'. I was
unable to determine the purpose of this bit. In the AST2600 A3
datasheet it is marked as 'reserved'. It is only used on the other
revision. As I only have the AST2600A3, I was unable to try this code
path.
Signed-off-by: Jacky Chou <jacky_chou@aspeedtech.com>
Signed-off-by: aspeedyh <yh_chung@aspeedtech.com>
Signed-off-by: Grégoire Layet <gregoire.layet@9elements.com>
Tested-by: Grégoire Layet <gregoire.layet@9elements.com>
---
drivers/tty/serial/8250/8250_aspeed_vuart.c | 86 +++++++++++++++++++++
1 file changed, 86 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c b/drivers/tty/serial/8250/8250_aspeed_vuart.c
index 6afa2f4057e1..e204e26fa173 100644
--- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
+++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
@@ -32,6 +32,27 @@
#define ASPEED_VUART_DEFAULT_SIRQ 4
#define ASPEED_VUART_DEFAULT_SIRQ_POLARITY IRQ_TYPE_LEVEL_LOW
+#define ASPEED_SCU_SILICON_REVISION_ID 0x04
+#define AST2600A3_REVISION_ID 0x05030303
+
+#define ASPEED_SCUC24 0xC24
+#define ASPEED_SCUC24_MSI_ROUTING_MASK GENMASK(11, 10)
+#define ASPEED_SCUC24_MSI_ROUTING_PCIe2LPC_PCIDEV1 (0x2 << 10)
+#define ASPEED_SCUC24_PCIDEV1_INTX_MSI_HOST2BMC_EN BIT(18)
+#define ASPEED_SCUC24_PCIDEV1_INTX_MSI_SCU560_EN BIT(17)
+
+
+#define ASPEED_SCU_PCIE_CONF_CTRL 0xC20
+#define SCU_PCIE_CONF_BMC_DEV_EN BIT(8)
+#define SCU_PCIE_CONF_BMC_DEV_EN_MMIO BIT(9)
+#define SCU_PCIE_CONF_BMC_DEV_EN_MSI BIT(11)
+#define SCU_PCIE_CONF_BMC_DEV_EN_IRQ BIT(13)
+#define SCU_PCIE_CONF_BMC_DEV_EN_PCIE_BUS_MASTER BIT(14)
+#define SCU_PCIE_CONF_BMC_DEV_EN_E2L BIT(15)
+#define SCU_PCIE_CONF_BMC_DEV_EN_LPC_DECODE BIT(21)
+
+#define ASPEED_SCU_BMC_DEV_CLASS 0xC68
+
struct aspeed_vuart {
struct device *dev;
int line;
@@ -412,6 +433,62 @@ static int aspeed_vuart_map_irq_polarity(u32 dt)
}
}
+static int aspeed_ast2600_vuart_over_pci_set_enabled(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ u32 silicon_revision_id;
+ struct regmap *scu;
+ int rc;
+
+ u32 pcie_config_ctl = SCU_PCIE_CONF_BMC_DEV_EN_IRQ |
+ SCU_PCIE_CONF_BMC_DEV_EN_MMIO |
+ SCU_PCIE_CONF_BMC_DEV_EN_MSI |
+ SCU_PCIE_CONF_BMC_DEV_EN_PCIE_BUS_MASTER |
+ SCU_PCIE_CONF_BMC_DEV_EN_E2L |
+ SCU_PCIE_CONF_BMC_DEV_EN_LPC_DECODE |
+ SCU_PCIE_CONF_BMC_DEV_EN;
+
+ scu = syscon_regmap_lookup_by_phandle(dev->of_node, "clocks");
+ if (IS_ERR(scu)) {
+ dev_err(&pdev->dev, "failed to find SCU regmap\n");
+ return PTR_ERR(scu);
+ }
+
+ /* update class code to be an MFD device */
+ if (regmap_write(scu, ASPEED_SCU_BMC_DEV_CLASS, 0xff000000)) {
+ dev_err(dev, "could not set PCI class code\n");
+ return -EIO;
+ }
+
+ if (regmap_update_bits(scu, ASPEED_SCU_PCIE_CONF_CTRL,
+ pcie_config_ctl, pcie_config_ctl)) {
+ dev_err(dev, "could not set PCIe configuration\n");
+ return -EIO;
+ }
+
+ if (regmap_read(scu, ASPEED_SCU_SILICON_REVISION_ID, &silicon_revision_id)) {
+ dev_err(dev, "could not read silicon revision\n");
+ return -EIO;
+ }
+
+ if (silicon_revision_id == AST2600A3_REVISION_ID)
+ rc = regmap_update_bits(scu, ASPEED_SCUC24,
+ ASPEED_SCUC24_PCIDEV1_INTX_MSI_HOST2BMC_EN | ASPEED_SCUC24_MSI_ROUTING_MASK,
+ ASPEED_SCUC24_PCIDEV1_INTX_MSI_HOST2BMC_EN | ASPEED_SCUC24_MSI_ROUTING_PCIe2LPC_PCIDEV1);
+ else
+ rc = regmap_update_bits(scu, ASPEED_SCUC24,
+ /* The bit 14 is reserved in the Datasheet, so we can't say what it does. This revision has not been tested */
+ ASPEED_SCUC24_PCIDEV1_INTX_MSI_SCU560_EN | BIT(14) | ASPEED_SCUC24_MSI_ROUTING_MASK,
+ ASPEED_SCUC24_PCIDEV1_INTX_MSI_SCU560_EN | BIT(14) | ASPEED_SCUC24_MSI_ROUTING_PCIe2LPC_PCIDEV1);
+ if (rc) {
+ dev_err(dev, "could not set PCI device 1 MSI interrupt routing\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
+
static int aspeed_vuart_probe(struct platform_device *pdev)
{
struct of_phandle_args sirq_polarity_sense_args;
@@ -540,6 +617,15 @@ static int aspeed_vuart_probe(struct platform_device *pdev)
aspeed_vuart_set_host_tx_discard(vuart, true);
platform_set_drvdata(pdev, vuart);
+ if (of_device_is_compatible(dev->of_node, "aspeed,ast2600-vuart") &&
+ of_property_read_bool(dev->of_node, "aspeed,vuart-over-pci")) {
+ rc = aspeed_ast2600_vuart_over_pci_set_enabled(pdev);
+ if (rc) {
+ dev_err(dev, "could not enable VUART over PCI\n");
+ return rc;
+ }
+ }
+
return 0;
err_sysfs_remove:
--
2.54.0
^ permalink raw reply related
* [PATCH v3 3/7] serial: 8250_aspeed_vuart: add aspeed,ast2600-vuart compatible string
From: Grégoire Layet @ 2026-06-23 14:25 UTC (permalink / raw)
To: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt
Cc: andrew, jacky_chou, yh_chung, ninad, anirudhsriniv, linux-serial,
linux-aspeed, linux-arm-kernel, linux-kernel, Grégoire Layet
In-Reply-To: <cover.1782224059.git.gregoire.layet@9elements.com>
Makes the driver compatible with the ast2600-vuart.
This enables specific configuration for the AST2600.
Signed-off-by: Grégoire Layet <gregoire.layet@9elements.com>
---
drivers/tty/serial/8250/8250_aspeed_vuart.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c b/drivers/tty/serial/8250/8250_aspeed_vuart.c
index 26fc0464f1cc..6afa2f4057e1 100644
--- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
+++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
@@ -560,6 +560,7 @@ static void aspeed_vuart_remove(struct platform_device *pdev)
static const struct of_device_id aspeed_vuart_table[] = {
{ .compatible = "aspeed,ast2400-vuart" },
{ .compatible = "aspeed,ast2500-vuart" },
+ { .compatible = "aspeed,ast2600-vuart" },
{ },
};
MODULE_DEVICE_TABLE(of, aspeed_vuart_table);
--
2.54.0
^ permalink raw reply related
* [PATCH v3 2/7] dt-bindings: serial: 8250: aspeed: add aspeed,vuart-over-pci bool prop
From: Grégoire Layet @ 2026-06-23 14:25 UTC (permalink / raw)
To: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt
Cc: andrew, jacky_chou, yh_chung, ninad, anirudhsriniv, linux-serial,
linux-aspeed, linux-arm-kernel, linux-kernel, Grégoire Layet
In-Reply-To: <cover.1782224059.git.gregoire.layet@9elements.com>
The ASPEED AST2600 has 2 VUART accessible over PCI.
This boolean can be set to specify if the VUART is used over PCI.
Signed-off-by: Grégoire Layet <gregoire.layet@9elements.com>
---
.../devicetree/bindings/serial/8250.yaml | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
index 3cbd0f532e15..b03797f4674d 100644
--- a/Documentation/devicetree/bindings/serial/8250.yaml
+++ b/Documentation/devicetree/bindings/serial/8250.yaml
@@ -26,6 +26,14 @@ allOf:
anyOf:
- const: aspeed,ast2500-vuart
- const: aspeed,ast2600-vuart
+ - if:
+ anyOf:
+ - required:
+ - aspeed,vuart-over-pci
+ then:
+ properties:
+ compatible:
+ const: aspeed,ast2600-vuart
- if:
properties:
compatible:
@@ -312,6 +320,13 @@ properties:
polarity (IRQ_TYPE_LEVEL_LOW or IRQ_TYPE_LEVEL_HIGH). Only
applicable to aspeed,ast2500-vuart and aspeed,ast2600-vuart.
+ aspeed,vuart-over-pci:
+ type: boolean
+ default: false
+ description: |
+ Enable the VUART over the BMC PCI device. Only applicable to
+ aspeed,ast2600-vuart.
+
required:
- reg
- interrupts
--
2.54.0
^ permalink raw reply related
* [PATCH v3 1/7] dt-bindings: serial: 8250: aspeed: add compatible string for ast2600
From: Grégoire Layet @ 2026-06-23 14:25 UTC (permalink / raw)
To: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt
Cc: andrew, jacky_chou, yh_chung, ninad, anirudhsriniv, linux-serial,
linux-aspeed, linux-arm-kernel, linux-kernel, Grégoire Layet
In-Reply-To: <cover.1782224059.git.gregoire.layet@9elements.com>
The ast2600 was using the ast2500 vuart compatible string.
This change makes it possible to have ast2600-specific properties.
Signed-off-by: Grégoire Layet <gregoire.layet@9elements.com>
---
.../devicetree/bindings/serial/8250.yaml | 20 +++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
index bb7b9c87a807..3cbd0f532e15 100644
--- a/Documentation/devicetree/bindings/serial/8250.yaml
+++ b/Documentation/devicetree/bindings/serial/8250.yaml
@@ -23,7 +23,9 @@ allOf:
then:
properties:
compatible:
- const: aspeed,ast2500-vuart
+ anyOf:
+ - const: aspeed,ast2500-vuart
+ - const: aspeed,ast2600-vuart
- if:
properties:
compatible:
@@ -287,17 +289,19 @@ properties:
aspeed,sirq-polarity-sense:
$ref: /schemas/types.yaml#/definitions/phandle-array
description: |
- Phandle to aspeed,ast2500-scu compatible syscon alongside register
- offset and bit number to identify how the SIRQ polarity should be
- configured. One possible data source is the LPC/eSPI mode bit. Only
- applicable to aspeed,ast2500-vuart.
+ Phandle to aspeed,ast2500-scu or aspeed,ast2600-scu compatible syscon
+ alongside register offset and bit number to identify how the SIRQ
+ polarity should be configured. One possible data source is the LPC/eSPI
+ mode bit. Only applicable to aspeed,ast2500-vuart and
+ aspeed,ast2600-vuart.
deprecated: true
aspeed,lpc-io-reg:
$ref: /schemas/types.yaml#/definitions/uint32-array
maxItems: 1
description: |
- The VUART LPC address. Only applicable to aspeed,ast2500-vuart.
+ The VUART LPC address. Only applicable to aspeed,ast2500-vuart and
+ aspeed,ast2600-vuart.
aspeed,lpc-interrupts:
$ref: /schemas/types.yaml#/definitions/uint32-array
@@ -305,8 +309,8 @@ properties:
maxItems: 2
description: |
A 2-cell property describing the VUART SIRQ number and SIRQ
- polarity (IRQ_TYPE_LEVEL_LOW or IRQ_TYPE_LEVEL_HIGH). Only
- applicable to aspeed,ast2500-vuart.
+ polarity (IRQ_TYPE_LEVEL_LOW or IRQ_TYPE_LEVEL_HIGH). Only
+ applicable to aspeed,ast2500-vuart and aspeed,ast2600-vuart.
required:
- reg
--
2.54.0
^ permalink raw reply related
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