* [PATCH v1 1/3] ACPI: EC: Do not return result from advance_transaction()
2022-02-04 17:37 [PATCH v1 0/3] ACPI: EC: Simplifications and cleanups Rafael J. Wysocki
@ 2022-02-04 17:40 ` Rafael J. Wysocki
2022-02-04 17:40 ` [PATCH v1 2/3] ACPI: EC: Reduce indentation level in acpi_ec_submit_event() Rafael J. Wysocki
2022-02-04 17:43 ` [PATCH v1 3/3] ACPI: EC: Rearrange code " Rafael J. Wysocki
2 siblings, 0 replies; 4+ messages in thread
From: Rafael J. Wysocki @ 2022-02-04 17:40 UTC (permalink / raw)
To: Linux ACPI; +Cc: LKML
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Notice that the if the event state is EC_EVENT_READY, the event
handling work cannot be pending, so it is not necessary to check
the return value of queue_work() in acpi_ec_submit_event().
Moreover, whether or not there is any EC work pending at the
moment can always be checked by looking at the events_in_progress
and queries_in_progress counters, so acpi_ec_submit_event() and
consequently advance_transaction() need not return results.
Accordingly, make acpi_ec_dispatch_gpe() always use the counters
mentioned above (for first_ec) to check if there is any pending EC
work to flush and turn both acpi_ec_submit_event() and
advance_transaction() into void functions (again, because they were
void functions in the past).
While at it, add a clarifying comment about the acpi_ec_mask_events()
call in advance_transaction().
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
drivers/acpi/ec.c | 38 +++++++++++++++++++-------------------
1 file changed, 19 insertions(+), 19 deletions(-)
Index: linux-pm/drivers/acpi/ec.c
===================================================================
--- linux-pm.orig/drivers/acpi/ec.c
+++ linux-pm/drivers/acpi/ec.c
@@ -168,7 +168,7 @@ struct acpi_ec_query {
};
static int acpi_ec_submit_query(struct acpi_ec *ec);
-static bool advance_transaction(struct acpi_ec *ec, bool interrupt);
+static void advance_transaction(struct acpi_ec *ec, bool interrupt);
static void acpi_ec_event_handler(struct work_struct *work);
struct acpi_ec *first_ec;
@@ -441,11 +441,15 @@ static bool acpi_ec_submit_flushable_req
return true;
}
-static bool acpi_ec_submit_event(struct acpi_ec *ec)
+static void acpi_ec_submit_event(struct acpi_ec *ec)
{
+ /*
+ * It is safe to mask the events here, because acpi_ec_close_event()
+ * will run at least once after this.
+ */
acpi_ec_mask_events(ec);
if (!acpi_ec_event_enabled(ec))
- return false;
+ return;
if (ec->event_state == EC_EVENT_READY) {
ec_dbg_evt("Command(%s) submitted/blocked",
@@ -460,17 +464,11 @@ static bool acpi_ec_submit_event(struct
* queue up the event work to start the same loop again.
*/
if (ec->events_to_process++ > 0)
- return true;
+ return;
ec->events_in_progress++;
- return queue_work(ec_wq, &ec->work);
+ queue_work(ec_wq, &ec->work);
}
-
- /*
- * The event handling work has not been completed yet, so it needs to be
- * flushed.
- */
- return true;
}
static void acpi_ec_complete_event(struct acpi_ec *ec)
@@ -655,11 +653,10 @@ static void acpi_ec_spurious_interrupt(s
acpi_ec_mask_events(ec);
}
-static bool advance_transaction(struct acpi_ec *ec, bool interrupt)
+static void advance_transaction(struct acpi_ec *ec, bool interrupt)
{
struct transaction *t = ec->curr;
bool wakeup = false;
- bool ret = false;
u8 status;
ec_dbg_stm("%s (%d)", interrupt ? "IRQ" : "TASK", smp_processor_id());
@@ -724,12 +721,10 @@ static bool advance_transaction(struct a
out:
if (status & ACPI_EC_FLAG_SCI)
- ret = acpi_ec_submit_event(ec);
+ acpi_ec_submit_event(ec);
if (wakeup && interrupt)
wake_up(&ec->wait);
-
- return ret;
}
static void start_transaction(struct acpi_ec *ec)
@@ -2051,6 +2046,11 @@ void acpi_ec_set_gpe_wake_mask(u8 action
acpi_set_gpe_wake_mask(NULL, first_ec->gpe, action);
}
+static bool acpi_ec_work_in_progress(struct acpi_ec *ec)
+{
+ return ec->events_in_progress + ec->queries_in_progress > 0;
+}
+
bool acpi_ec_dispatch_gpe(void)
{
bool work_in_progress = false;
@@ -2084,7 +2084,8 @@ bool acpi_ec_dispatch_gpe(void)
if (acpi_ec_gpe_status_set(first_ec)) {
pm_pr_dbg("ACPI EC GPE status set\n");
- work_in_progress = advance_transaction(first_ec, false);
+ advance_transaction(first_ec, false);
+ work_in_progress = acpi_ec_work_in_progress(first_ec);
}
spin_unlock_irq(&first_ec->lock);
@@ -2102,8 +2103,7 @@ bool acpi_ec_dispatch_gpe(void)
spin_lock_irq(&first_ec->lock);
- work_in_progress = first_ec->events_in_progress +
- first_ec->queries_in_progress > 0;
+ work_in_progress = acpi_ec_work_in_progress(first_ec);
spin_unlock_irq(&first_ec->lock);
} while (work_in_progress && !pm_wakeup_pending());
^ permalink raw reply [flat|nested] 4+ messages in thread* [PATCH v1 2/3] ACPI: EC: Reduce indentation level in acpi_ec_submit_event()
2022-02-04 17:37 [PATCH v1 0/3] ACPI: EC: Simplifications and cleanups Rafael J. Wysocki
2022-02-04 17:40 ` [PATCH v1 1/3] ACPI: EC: Do not return result from advance_transaction() Rafael J. Wysocki
@ 2022-02-04 17:40 ` Rafael J. Wysocki
2022-02-04 17:43 ` [PATCH v1 3/3] ACPI: EC: Rearrange code " Rafael J. Wysocki
2 siblings, 0 replies; 4+ messages in thread
From: Rafael J. Wysocki @ 2022-02-04 17:40 UTC (permalink / raw)
To: Linux ACPI; +Cc: LKML
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The indentation level in acpi_ec_submit_event() can be reduced, so
do that and while at it fix a typo in the comment affected by that
change.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
drivers/acpi/ec.c | 33 +++++++++++++++++----------------
1 file changed, 17 insertions(+), 16 deletions(-)
Index: linux-pm/drivers/acpi/ec.c
===================================================================
--- linux-pm.orig/drivers/acpi/ec.c
+++ linux-pm/drivers/acpi/ec.c
@@ -451,24 +451,25 @@ static void acpi_ec_submit_event(struct
if (!acpi_ec_event_enabled(ec))
return;
- if (ec->event_state == EC_EVENT_READY) {
- ec_dbg_evt("Command(%s) submitted/blocked",
- acpi_ec_cmd_string(ACPI_EC_COMMAND_QUERY));
+ if (ec->event_state != EC_EVENT_READY)
+ return;
+
+ ec_dbg_evt("Command(%s) submitted/blocked",
+ acpi_ec_cmd_string(ACPI_EC_COMMAND_QUERY));
- ec->event_state = EC_EVENT_IN_PROGRESS;
- /*
- * If events_to_process is greqter than 0 at this point, the
- * while () loop in acpi_ec_event_handler() is still running
- * and incrementing events_to_process will cause it to invoke
- * acpi_ec_submit_query() once more, so it is not necessary to
- * queue up the event work to start the same loop again.
- */
- if (ec->events_to_process++ > 0)
- return;
+ ec->event_state = EC_EVENT_IN_PROGRESS;
+ /*
+ * If events_to_process is greater than 0 at this point, the while ()
+ * loop in acpi_ec_event_handler() is still running and incrementing
+ * events_to_process will cause it to invoke acpi_ec_submit_query() once
+ * more, so it is not necessary to queue up the event work to start the
+ * same loop again.
+ */
+ if (ec->events_to_process++ > 0)
+ return;
- ec->events_in_progress++;
- queue_work(ec_wq, &ec->work);
- }
+ ec->events_in_progress++;
+ queue_work(ec_wq, &ec->work);
}
static void acpi_ec_complete_event(struct acpi_ec *ec)
^ permalink raw reply [flat|nested] 4+ messages in thread