All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@kernel.org>
To: Yicong Yang <yang.yicong@picoheart.com>,
	Anup Patel <apatel@ventanamicro.com>
Cc: yang.yicong@picoheart.com, anup@brainfault.org, pjw@kernel.org,
	palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
	geshijian@picoheart.com, weidong.wd@picoheart.com,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Danilo Krummrich <dakr@kernel.org>
Subject: Re: [PATCH] irqchip/riscv-aplic: Register the driver prior to device creation
Date: Thu, 15 Jan 2026 14:28:29 +0100	[thread overview]
Message-ID: <87y0lz2ef6.ffs@tglx> (raw)
In-Reply-To: <e30ee004-64f9-4003-8907-c407a76fc244@picoheart.com>

On Thu, Jan 15 2026 at 16:31, Yicong Yang wrote:
> so based on above, if we use async_wq (with async_schedule* APIs) in
> acpi_scan_clear_dep_queue() for creating these devices, the issue
> could be solved since we're sure to have these devices before entering
> userspace, since the barrier of async_synchronize_full(). This should be
> a solution with a conceptual support and I did a quick test on our
> platform it solves the issue.

Sounds about right to me. The drivers core and ACPI folks might have
opinions though :)

> As for the order of console_on_rootfs()/async_synchronize_full(),
> though our issue is not directly caused by it, it will cause the
> same issue (by the console open time the async probing maybe not
> finised) theoretically and needs to be fixed, is it?

Yes, that should move past the synchronization point.

Thanks,

        tglx


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Thomas Gleixner <tglx@kernel.org>
To: Yicong Yang <yang.yicong@picoheart.com>,
	Anup Patel <apatel@ventanamicro.com>
Cc: yang.yicong@picoheart.com, anup@brainfault.org, pjw@kernel.org,
	palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
	geshijian@picoheart.com, weidong.wd@picoheart.com,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Danilo Krummrich <dakr@kernel.org>
Subject: Re: [PATCH] irqchip/riscv-aplic: Register the driver prior to device creation
Date: Thu, 15 Jan 2026 14:28:29 +0100	[thread overview]
Message-ID: <87y0lz2ef6.ffs@tglx> (raw)
In-Reply-To: <e30ee004-64f9-4003-8907-c407a76fc244@picoheart.com>

On Thu, Jan 15 2026 at 16:31, Yicong Yang wrote:
> so based on above, if we use async_wq (with async_schedule* APIs) in
> acpi_scan_clear_dep_queue() for creating these devices, the issue
> could be solved since we're sure to have these devices before entering
> userspace, since the barrier of async_synchronize_full(). This should be
> a solution with a conceptual support and I did a quick test on our
> platform it solves the issue.

Sounds about right to me. The drivers core and ACPI folks might have
opinions though :)

> As for the order of console_on_rootfs()/async_synchronize_full(),
> though our issue is not directly caused by it, it will cause the
> same issue (by the console open time the async probing maybe not
> finised) theoretically and needs to be fixed, is it?

Yes, that should move past the synchronization point.

Thanks,

        tglx


  reply	other threads:[~2026-01-15 13:28 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-14  6:37 [PATCH] irqchip/riscv-aplic: Register the driver prior to device creation Yicong Yang
2026-01-14  6:37 ` Yicong Yang
2026-01-14  8:57 ` Anup Patel
2026-01-14  8:57   ` Anup Patel
2026-01-14 11:48   ` Yicong Yang
2026-01-14 11:48     ` Yicong Yang
2026-01-14 19:50     ` Thomas Gleixner
2026-01-14 19:50       ` Thomas Gleixner
2026-01-15  8:31       ` Yicong Yang
2026-01-15  8:31         ` Yicong Yang
2026-01-15 13:28         ` Thomas Gleixner [this message]
2026-01-15 13:28           ` Thomas Gleixner
2026-01-16  6:16           ` Yicong Yang
2026-01-16  6:16             ` Yicong Yang
2026-01-16 11:41             ` Thomas Gleixner
2026-01-16 11:41               ` Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y0lz2ef6.ffs@tglx \
    --to=tglx@kernel.org \
    --cc=alex@ghiti.fr \
    --cc=anup@brainfault.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=apatel@ventanamicro.com \
    --cc=dakr@kernel.org \
    --cc=geshijian@picoheart.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=pjw@kernel.org \
    --cc=rafael@kernel.org \
    --cc=weidong.wd@picoheart.com \
    --cc=yang.yicong@picoheart.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.