Messages in this thread | | | From | Uros Bizjak <> | Date | Wed, 22 Mar 2023 21:34:16 +0100 | Subject | Re: [PATCH v2] x86/ACPI/boot: Improve __acpi_acquire_global_lock |
| |
On Wed, Mar 22, 2023 at 7:34 PM Dave Hansen <dave.hansen@intel.com> wrote: > > On 3/22/23 11:24, Rafael J. Wysocki wrote: > > Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > or please let me know if you want me to pick this up (in which case it > > will require an ACK from one of the x86 maintainers). > > I'll pull it into x86/acpi. I'm kinda shocked the compiler is so > clueless, but this makes the C code more readable anyway. Win/win, I guess.
Please note that the return form __acpi_{acquire,release}_global_lock is actually used as bool:
acenv.h:
int __acpi_acquire_global_lock(unsigned int *lock); int __acpi_release_global_lock(unsigned int *lock);
#define ACPI_ACQUIRE_GLOBAL_LOCK(facs, Acq) \ ((Acq) = __acpi_acquire_global_lock(&facs->global_lock))
#define ACPI_RELEASE_GLOBAL_LOCK(facs, Acq) \ ((Acq) = __acpi_release_global_lock(&facs->global_lock))
evglock.c:
acpi_status acpi_ev_acquire_global_lock(u16 timeout) { ... u8 acquired = FALSE; ... ACPI_ACQUIRE_GLOBAL_LOCK(acpi_gbl_FACS, acquired); if (acquired) ... }
acpi_status acpi_ev_release_global_lock(void) { u8 pending = FALSE; ... ACPI_RELEASE_GLOBAL_LOCK(acpi_gbl_FACS, pending); if (pending) ... }
These functions are also defined for ia64, so I didn't want to change the return value. But ia64 is going to be retired, and this opens the optimization opportunity.
Uros.
| |