All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Leonid Bloch <lb.workbox@gmail.com>
Cc: "Michael S . Tsirkin" <mst@redhat.com>,
	Ani Sinha <anisinha@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Eduardo Habkost <ehabkost@redhat.com>,
	Eric Blake <eblake@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	Dmitry Fleytman <dmitry.fleytman@gmail.com>,
	qemu-devel@nongnu.org
Subject: Re: [PATCH v3 1/4] hw/acpi: Support extended GPE handling for additional ACPI devices
Date: Thu, 4 Sep 2025 15:21:50 +0200	[thread overview]
Message-ID: <20250904152150.4e7a1127@fedora> (raw)
In-Reply-To: <20250827220054.37268-2-lb.workbox@gmail.com>

On Thu, 28 Aug 2025 01:00:47 +0300
Leonid Bloch <lb.workbox@gmail.com> wrote:

> This patch extends the GPE (General Purpose Event) handling to support
> the maximum number of interrupts available based on the machine's GPE
> register length, rather than being limited to the first 8 bits.
> 
> This change is needed to support additional ACPI devices that will be
> introduced in subsequent patches (Battery, AC adapter, and button devices).
> These new devices require GPE event bits beyond the first 8, which were
> previously not being properly handled by the event sending and SCI
> (System Control Interrupt) update mechanisms.
> 
> The actual number of available GPE interrupts varies by machine type:
> - PIIX4: GPE_LEN = 4 (32 bits total across status and enable registers)
> - ICH9: ICH9_PMIO_GPE0_LEN = 16 (128 bits total)
> 
> The patch modifies:
> - acpi_send_gpe_event(): Now properly propagates status bits across all
>   available GPE registers based on the machine's gpe.len value
> - acpi_update_sci(): Checks all GPE registers for pending interrupts,
>   not just the first byte
> 
> Note: A future enhancement could refactor the GPE handling to use the
> bitmap API from bitops.h instead of the current manual bit manipulation,
> which would provide a cleaner interface for these operations.
> 
> Signed-off-by: Leonid Bloch <lb.workbox@gmail.com>
> ---

add after this line a per patch changelog,
describing  what has changed.

>  hw/acpi/core.c | 17 +++++++++++++++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/acpi/core.c b/hw/acpi/core.c
> index 58f8964e13..3240ec185e 100644
> --- a/hw/acpi/core.c
> +++ b/hw/acpi/core.c
> @@ -729,19 +729,32 @@ uint32_t acpi_gpe_ioport_readb(ACPIREGS *ar, uint32_t addr)
>  void acpi_send_gpe_event(ACPIREGS *ar, qemu_irq irq,
>                           AcpiEventStatusBits status)
>  {
> -    ar->gpe.sts[0] |= status;
> +    int i;
> +    AcpiEventStatusBits st = status;
> +
> +    for (i = 0; i < ar->gpe.len / 2; i++) {
> +        ar->gpe.sts[i] |= st;
> +        st >>= TYPE_WIDTH(ar->gpe.sts[0]);
> +    }
> +
>      acpi_update_sci(ar, irq);
>  }
>  
>  void acpi_update_sci(ACPIREGS *regs, qemu_irq irq)
>  {
>      int sci_level, pm1a_sts;
> +    bool gpe_sci = false;
> +    int i;
>  
>      pm1a_sts = acpi_pm1_evt_get_sts(regs);
>  
> +    for (i = 0; i < regs->gpe.len / 2; i++) {
                    ^^^^^^^^^^^^^^^^^^^^
           vvvv 
> +        gpe_sci = gpe_sci || !!(regs->gpe.sts[i] & regs->gpe.en[i]);
            once we decided to generate sci there is no need to scan array further
            so drop 'gpe_sci ||' and break the loop in the condition above

> +    }
> +
>      sci_level = ((pm1a_sts &
>                    regs->pm1.evt.en & ACPI_BITMASK_PM1_COMMON_ENABLED) != 0) ||
> -                ((regs->gpe.sts[0] & regs->gpe.en[0]) != 0);
> +                gpe_sci;
>  
>      qemu_set_irq(irq, sci_level);
>  



  reply	other threads:[~2025-09-04 13:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-27 22:00 [PATCH v3 0/4] Introduce a battery, AC adapter, and lid button Leonid Bloch
2025-08-27 22:00 ` [PATCH v3 1/4] hw/acpi: Support extended GPE handling for additional ACPI devices Leonid Bloch
2025-09-04 13:21   ` Igor Mammedov [this message]
2025-08-27 22:00 ` [PATCH v3 2/4] hw/acpi: Introduce the QEMU Battery Leonid Bloch
2025-09-04 12:54   ` Igor Mammedov
2025-10-23 19:37   ` Denis V. Lunev
2025-10-23 20:58   ` Eric Blake
2025-08-27 22:00 ` [PATCH v3 3/4] hw/acpi: Introduce the QEMU AC adapter Leonid Bloch
2025-10-23 21:05   ` Eric Blake
2025-08-27 22:00 ` [PATCH v3 4/4] hw/acpi: Introduce the QEMU lid button Leonid Bloch
2025-09-04 12:41 ` [PATCH v3 0/4] Introduce a battery, AC adapter, and " Igor Mammedov

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=20250904152150.4e7a1127@fedora \
    --to=imammedo@redhat.com \
    --cc=anisinha@redhat.com \
    --cc=armbru@redhat.com \
    --cc=dmitry.fleytman@gmail.com \
    --cc=eblake@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=lb.workbox@gmail.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    /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.