diff mbox series

[v1,4/5] rtc: rtc-cmos: Rename ACPI-related functions

Message ID 8155359.T7Z3S40VBb@kreacher
State Superseded
Headers show
Series [v1,1/5] rtc: rtc-cmos: Call cmos_wake_setup() from cmos_do_probe() | expand

Commit Message

Rafael J. Wysocki Nov. 7, 2022, 8:01 p.m. UTC
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

The names of rtc_wake_setup() and cmos_wake_setup() don't indicate
that these functions are ACPI-related, which is the case, and the
former doesn't really reflect the role of the function.

Rename them to acpi_rtc_event_setup() and cmos_acpi_wake_setup(),
respectively, to address this shortcoming.

No intentional functional impact.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/rtc/rtc-cmos.c |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

Comments

Rafael J. Wysocki Nov. 8, 2022, 2:43 p.m. UTC | #1
On Mon, Nov 7, 2022 at 10:22 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, Nov 07, 2022 at 09:01:50PM +0100, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >
> > The names of rtc_wake_setup() and cmos_wake_setup() don't indicate
> > that these functions are ACPI-related, which is the case, and the
> > former doesn't really reflect the role of the function.
> >
> > Rename them to acpi_rtc_event_setup() and cmos_acpi_wake_setup(),
> > respectively, to address this shortcoming.
>
> Hmm... I'm not sure I understand why in one case acpi is a prefix and
> in the other is kinda mid-suffix?

Because the former installs an ACPI RTC fixed event handler and the
latter populates the cmos_rtc data structure in the ACPI case.

Maybe it would be better to call the latter cmos_wake_setup_acpi().
diff mbox series

Patch

Index: linux-pm/drivers/rtc/rtc-cmos.c
===================================================================
--- linux-pm.orig/drivers/rtc/rtc-cmos.c
+++ linux-pm/drivers/rtc/rtc-cmos.c
@@ -784,7 +784,7 @@  static u32 rtc_handler(void *context)
 	return ACPI_INTERRUPT_HANDLED;
 }
 
-static void rtc_wake_setup(struct device *dev)
+static void acpi_rtc_event_setup(struct device *dev)
 {
 	if (acpi_disabled)
 		return;
@@ -828,7 +828,7 @@  static void use_acpi_alarm_quirks(void)
 static inline void use_acpi_alarm_quirks(void) { }
 #endif
 
-static void cmos_wake_setup(struct device *dev)
+static void cmos_acpi_wake_setup(struct device *dev)
 {
 	if (acpi_disabled)
 		return;
@@ -880,11 +880,11 @@  static void cmos_check_acpi_rtc_status(s
 
 #else /* !CONFIG_ACPI */
 
-static inline void rtc_wake_setup(struct device *dev)
+static inline void acpi_rtc_event_setup(struct device *dev)
 {
 }
 
-static inline void cmos_wake_setup(struct device *dev)
+static inline void cmos_acpi_wake_setup(struct device *dev)
 {
 }
 
@@ -986,7 +986,7 @@  cmos_do_probe(struct device *dev, struct
 			cmos_rtc.wake_off = info->wake_off;
 		}
 	} else {
-		cmos_wake_setup(dev);
+		cmos_acpi_wake_setup(dev);
 	}
 
 	if (cmos_rtc.day_alrm >= 128)
@@ -1091,7 +1091,7 @@  cmos_do_probe(struct device *dev, struct
 	 * the ACPI RTC fixed event.
 	 */
 	if (!info)
-		rtc_wake_setup(dev);
+		acpi_rtc_event_setup(dev);
 
 	dev_info(dev, "%s%s, %d bytes nvram%s\n",
 		 !is_valid_irq(rtc_irq) ? "no alarms" :