[PATCH v2 1/2] ACPI: TAD: introduce acpi_has_rtc()

[PATCH v2 1/2] ACPI: TAD: introduce acpi_has_rtc()

[Hamza Mahfooz]

The same RTC may also be accessible by other means, like the EFI
GetTime() and SetTime() runtime services used by rtc-efi, which are best
avoided if there is a native ACPI interface to the RTC.

To allow other RTC drivers to stand down in that case, add an exported
helper, acpi_has_rtc(), that returns true if there is a TAD the driver
will register an RTC class device for.

The helper looks for a platform device matching the driver's ID table
whose _GCP indicates real time support, like acpi_tad_probe() checks,
instead of checking whether the driver has bound to such a device, so
that callers need not depend on the order in which drivers are probed.

Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
---
v1: https://lore.kernel.org/r/20261022211304.2285792-1-hamzamahfooz@linux.microsoft.com/
v2:
- Rename acpi_tad_rtc_available() to acpi_has_rtc(), move it to within
  acpi-tad (which allows us to simplify it quite a bit) and declare it
  in linux/acpi.h. (Ard)
- Add acpi_disabled check. (Ard)
---
 drivers/acpi/acpi_tad.c | 38 ++++++++++++++++++++++++++++++++++++++
 include/linux/acpi.h    |  6 ++++++
 2 files changed, 44 insertions(+)

diff --git a/drivers/acpi/acpi_tad.c b/drivers/acpi/acpi_tad.c
index 45459a4ca..eea4d2123 100644
--- a/drivers/acpi/acpi_tad.c
+++ b/drivers/acpi/acpi_tad.c
@@ -899,6 +899,44 @@ static const struct acpi_device_id acpi_tad_ids[] = {
 	{}
 };
 
+static int acpi_tad_rtc_match(struct device *dev, const void *data)
+{
+	unsigned long long caps;
+	acpi_status status;
+
+	if (!acpi_match_device(acpi_tad_ids, dev))
+		return 0;
+
+	status = acpi_evaluate_integer(ACPI_HANDLE(dev), "_GCP", NULL, &caps);
+
+	return ACPI_SUCCESS(status) && (caps & ACPI_TAD_RT);
+}
+
+/**
+ * acpi_has_rtc - Check if the RTC should be driven via the ACPI TAD
+ *
+ * Check if there is a TAD implementing the real time methods that this driver
+ * will register an RTC class device for.
+ *
+ * Return: %true if the RTC should be driven via the ACPI TAD, %false otherwise.
+ */
+bool acpi_has_rtc(void)
+{
+	struct device *dev;
+
+	if (acpi_disabled || !IS_ENABLED(CONFIG_RTC_CLASS))
+		return false;
+
+	dev = bus_find_device(&platform_bus_type, NULL, NULL,
+			      acpi_tad_rtc_match);
+	if (!dev)
+		return false;
+
+	put_device(dev);
+	return true;
+}
+EXPORT_SYMBOL_GPL(acpi_has_rtc);
+
 static struct platform_driver acpi_tad_driver = {
 	.driver = {
 		.name = "acpi-tad",
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 9d3f039eb..636e5218c 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -1548,6 +1548,12 @@ extern bool acpi_has_watchdog(void);
 static inline bool acpi_has_watchdog(void) { return false; }
 #endif
 
+#if IS_REACHABLE(CONFIG_ACPI_TAD)
+bool acpi_has_rtc(void);
+#else
+static inline bool acpi_has_rtc(void) { return false; }
+#endif
+
 #ifdef CONFIG_ACPI_SPCR_TABLE
 extern bool qdf2400_e44_present;
 int acpi_parse_spcr(bool enable_earlycon, bool enable_console);
-- 
2.56.0

[PATCH v2 2/2] rtc: efi: defer to the ACPI TAD if it can drive the RTC

[Hamza Mahfooz]

EFI runtime services are best avoided where possible, and ACPI defines a
standard interface to the RTC in the form of the Time and Alarm Device
(TAD), which the acpi-tad driver has been exposing as an RTC class
device since commit 8a1e7f4b1764 ("ACPI: TAD: Add RTC class device
interface").

So, make rtc-efi decline to probe, before calling GetTime(), if
acpi_has_rtc() says that the RTC can be driven via the TAD.

Also, to ensure that acpi_has_rtc() is always reachable from rtc-efi
when ACPI is enabled, make RTC_DRV_EFI depend on ACPI_TAD.

Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
---
v1: https://lore.kernel.org/all/20261022211304.2285792-2-hamzamahfooz@linux.microsoft.com/
v2:
- Make rtc-efi decline to probe instead of not registering the device in
  efisubsys_init(). (Ard)
- Make RTC_DRV_EFI depend on !ACPI || ACPI_TAD. (Ard)
---
 drivers/rtc/Kconfig   | 4 ++++
 drivers/rtc/rtc-efi.c | 4 ++++
 2 files changed, 8 insertions(+)

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 1e863f1d3..26f057f52 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1262,10 +1262,14 @@ config RTC_DRV_DA9063
 config RTC_DRV_EFI
 	tristate "EFI RTC"
 	depends on EFI && !X86
+	depends on !ACPI || ACPI_TAD
 	help
 	  If you say yes here you will get support for the EFI
 	  Real Time Clock.
 
+	  On ACPI systems, the ACPI Time and Alarm Device (TAD) driver
+	  is used instead of this one if the TAD can drive the RTC.
+
 	  This driver can also be built as a module. If so, the module
 	  will be called rtc-efi.
 
diff --git a/drivers/rtc/rtc-efi.c b/drivers/rtc/rtc-efi.c
index a8c18ebc5..de4821c9b 100644
--- a/drivers/rtc/rtc-efi.c
+++ b/drivers/rtc/rtc-efi.c
@@ -10,6 +10,7 @@
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
+#include <linux/acpi.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/stringify.h>
@@ -252,6 +253,9 @@ static int __init efi_rtc_probe(struct platform_device *dev)
 	efi_time_cap_t cap;
 	efi_bool_t enabled, pending;
 
+	if (acpi_has_rtc())
+		return -ENODEV;
+
 	/* First check if the RTC is usable */
 	if (efi.get_time(&eft, &cap) != EFI_SUCCESS)
 		return -ENODEV;
-- 
2.56.0

Re: [PATCH v2 2/2] rtc: efi: defer to the ACPI TAD if it can drive the RTC

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] rtc: efi: ACPI_TAD dependency disables RTC_DRV_EFI in arm64 defconfig
--

commit 43949693bace16600c49e8c7dd525850e1286516
Author: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>

rtc: efi: defer to the ACPI TAD if it can drive the RTC

This commit updates efi_rtc_probe() in drivers/rtc/rtc-efi.c to return
-ENODEV when acpi_has_rtc() is true, and makes RTC_DRV_EFI depend on
!ACPI || ACPI_TAD.

> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index 1e863f1d36fd5..26f057f52ce59 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -1262,10 +1262,14 @@ config RTC_DRV_DA9063
>  config RTC_DRV_EFI
>  	tristate "EFI RTC"
>  	depends on EFI && !X86
> +	depends on !ACPI || ACPI_TAD

[Severity: High]
Does adding "depends on !ACPI || ACPI_TAD" here cause CONFIG_RTC_DRV_EFI=y
to be silently dropped in arch/arm64/configs/defconfig (and existing
configurations with CONFIG_ACPI=y and CONFIG_ACPI_TAD=n)?

In drivers/acpi/Kconfig, ACPI_TAD has no default and depends on SYSFS and
PM_SLEEP:

config ACPI_TAD
	tristate "ACPI Time and Alarm (TAD) Device Support"
	depends on SYSFS && PM_SLEEP

In arch/arm64/configs/defconfig, CONFIG_ACPI=y and CONFIG_RTC_DRV_EFI=y are
enabled without setting CONFIG_ACPI_TAD, so this dependency causes Kconfig
to drop CONFIG_RTC_DRV_EFI while leaving CONFIG_ACPI_TAD disabled,
resulting in neither rtc-efi nor acpi-tad being built. It also prevents
enabling CONFIG_RTC_DRV_EFI when CONFIG_ACPI=y and CONFIG_PM_SLEEP=n (or
CONFIG_SYSFS=n).

Since include/linux/acpi.h already provides an inline stub for
acpi_has_rtc() when !IS_REACHABLE(CONFIG_ACPI_TAD):

#if IS_REACHABLE(CONFIG_ACPI_TAD)
bool acpi_has_rtc(void);
#else
static inline bool acpi_has_rtc(void) { return false; }
#endif

should this use "depends on ACPI_TAD || !ACPI_TAD" instead to avoid the
CONFIG_RTC_DRV_EFI=y and CONFIG_ACPI_TAD=m reachability mismatch, or if
ACPI_TAD is meant to be required whenever ACPI is enabled, should ACPI_TAD
and defconfig be updated accordingly?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261023212218.2568858-1-hamzamahfooz@linux.microsoft.com?part=2

Re: [PATCH v2 1/2] ACPI: TAD: introduce acpi_has_rtc()

[sashiko-bot]

> The same RTC may also be accessible by other means, like the EFI
> GetTime() and SetTime() runtime services used by rtc-efi, which are best
> avoided if there is a native ACPI interface to the RTC.
> 
> To allow other RTC drivers to stand down in that case, add an exported
> helper, acpi_has_rtc(), that returns true if there is a TAD the driver
> will register an RTC class device for.
> 
> The helper looks for a platform device matching the driver's ID table
> whose _GCP indicates real time support, like acpi_tad_probe() checks,
> instead of checking whether the driver has bound to such a device, so
> that callers need not depend on the order in which drivers are probed.
> 
> Suggested-by: Ard Biesheuvel <ardb@kernel.org>
> Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261023212218.2568858-1-hamzamahfooz@linux.microsoft.com?part=1