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: Fri, 16 Jan 2026 12:41:04 +0100	[thread overview]
Message-ID: <87h5sl3hv3.ffs@tglx> (raw)
In-Reply-To: <b2eb7f70-8ee9-43f6-b086-f0c17b1f9e39@picoheart.com>

On Fri, Jan 16 2026 at 14:16, Yicong Yang wrote:
> On 1/15/26 9:28 PM, Thomas Gleixner wrote:
>> 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 :)
>> 
> sure I'll wait a bit to see if there's further comment before sending out
> next version.

Btw, there is a reason that this is on the default work queue. See

     commit dc612486c919 ("ACPI: scan: Fix device object rescan in
                           acpi_scan_clear_dep()")

for details. So this needs some more thought.

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: Fri, 16 Jan 2026 12:41:04 +0100	[thread overview]
Message-ID: <87h5sl3hv3.ffs@tglx> (raw)
In-Reply-To: <b2eb7f70-8ee9-43f6-b086-f0c17b1f9e39@picoheart.com>

On Fri, Jan 16 2026 at 14:16, Yicong Yang wrote:
> On 1/15/26 9:28 PM, Thomas Gleixner wrote:
>> 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 :)
>> 
> sure I'll wait a bit to see if there's further comment before sending out
> next version.

Btw, there is a reason that this is on the default work queue. See

     commit dc612486c919 ("ACPI: scan: Fix device object rescan in
                           acpi_scan_clear_dep()")

for details. So this needs some more thought.

Thanks,

        tglx

  reply	other threads:[~2026-01-16 11:41 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
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 [this message]
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=87h5sl3hv3.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.