[PATCH 0/9] drivers: Transition to the faux device interface

[PATCH 0/9] drivers: Transition to the faux device interface

[Sudeep Holla]

Recently when debugging why one of the scmi platform device was not
showing up under /sys/devices/platform/firmware:scmi instead was
appearing directly under /sys/devices/platform, I noticed the new
faux interface /sys/devices/faux.

Looking through the discussion and the background, I got excited and
took the opportunity to clear all the platform devices under
/sys/devices/platform on the Arm Juno/FVP platforms that are really
faux devices. Only the platform devices created for the device nodes
from the DT remain under /sys/devices/platform after these changes.

All the patches are independent of each other.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
Greg Kroah-Hartman (1):
      regulator: dummy: convert to use the faux device interface

Sudeep Holla (8):
      cpuidle: psci: Transition to the faux device interface
      hwrng: arm-smccc-trng - transition to the faux device interface
      efi: Remove redundant creation of the "efivars" platform device
      rtc: efi: Transition to the faux device interface
      virt: efi_secret: Transition to the faux device interface
      ASoC: soc-utils: Transition to the faux device interface
      net: phy: fixed_phy: transition to the faux device interface
      ACPI: APEI: EINJ: Transition to the faux device interface

 drivers/acpi/apei/einj-core.c             | 32 +++++++++---------------
 drivers/char/hw_random/arm_smccc_trng.c   | 40 +++++++++++++++++++++---------
 drivers/cpuidle/cpuidle-psci.c            | 26 +++++++-------------
 drivers/firmware/efi/efi.c                | 10 --------
 drivers/firmware/smccc/smccc.c            | 21 ----------------
 drivers/net/phy/fixed_phy.c               | 16 ++++++------
 drivers/regulator/dummy.c                 | 37 +++++++---------------------
 drivers/rtc/rtc-efi.c                     | 31 ++++++++++++++++-------
 drivers/virt/coco/efi_secret/efi_secret.c | 41 ++++++++++++++++++-------------
 sound/soc/soc-utils.c                     | 34 +++++++++----------------
 10 files changed, 124 insertions(+), 164 deletions(-)
---
base-commit: 80e54e84911a923c40d7bee33a34c1b4be148d7a
change-id: 20250315-plat2faux_dev-8c28b35be96a
-- 
Regards,
Sudeep

[PATCH 1/9] cpuidle: psci: Transition to the faux device interface

[Sudeep Holla]

The PSCI cpuidle driver does not require the creation of a platform
device. Originally, this approach was chosen for simplicity when the
driver was first implemented.

With the introduction of the lightweight faux device interface, we now
have a more appropriate alternative. Migrate the driver to utilize the
faux bus, given that the platform device it previously created was not
a real one anyway. This will simplify the code, reducing its footprint
while maintaining functionality.

Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: linux-pm@vger.kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/cpuidle/cpuidle-psci.c | 26 +++++++++-----------------
 1 file changed, 9 insertions(+), 17 deletions(-)

diff --git a/drivers/cpuidle/cpuidle-psci.c b/drivers/cpuidle/cpuidle-psci.c
index 2562dc001fc1de69732ef28f383d2809262a3d96..3e38f712dab3785d5caa8d103fd0146156005921 100644
--- a/drivers/cpuidle/cpuidle-psci.c
+++ b/drivers/cpuidle/cpuidle-psci.c
@@ -16,7 +16,7 @@
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/of.h>
-#include <linux/platform_device.h>
+#include <linux/device/faux.h>
 #include <linux/psci.h>
 #include <linux/pm_domain.h>
 #include <linux/pm_runtime.h>
@@ -404,14 +404,14 @@ static int psci_idle_init_cpu(struct device *dev, int cpu)
  * to register cpuidle driver then rollback to cancel all CPUs
  * registration.
  */
-static int psci_cpuidle_probe(struct platform_device *pdev)
+static int psci_cpuidle_probe(struct faux_device *fdev)
 {
 	int cpu, ret;
 	struct cpuidle_driver *drv;
 	struct cpuidle_device *dev;
 
 	for_each_possible_cpu(cpu) {
-		ret = psci_idle_init_cpu(&pdev->dev, cpu);
+		ret = psci_idle_init_cpu(&fdev->dev, cpu);
 		if (ret)
 			goto out_fail;
 	}
@@ -431,26 +431,18 @@ static int psci_cpuidle_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static struct platform_driver psci_cpuidle_driver = {
+static struct faux_device_ops psci_cpuidle_ops = {
 	.probe = psci_cpuidle_probe,
-	.driver = {
-		.name = "psci-cpuidle",
-	},
 };
 
 static int __init psci_idle_init(void)
 {
-	struct platform_device *pdev;
-	int ret;
+	struct faux_device *fdev;
 
-	ret = platform_driver_register(&psci_cpuidle_driver);
-	if (ret)
-		return ret;
-
-	pdev = platform_device_register_simple("psci-cpuidle", -1, NULL, 0);
-	if (IS_ERR(pdev)) {
-		platform_driver_unregister(&psci_cpuidle_driver);
-		return PTR_ERR(pdev);
+	fdev = faux_device_create("psci-cpuidle", NULL, &psci_cpuidle_ops);
+	if (!fdev) {
+		pr_err("Failed to create psci-cpuidle device\n");
+		return -ENODEV;
 	}
 
 	return 0;

-- 
2.34.1

[PATCH 2/9] hwrng: arm-smccc-trng - transition to the faux device interface

[Sudeep Holla]

The Arm SMCCC based true random number generator driver does not require
the creation of a platform device/driver. Originally, this approach was
chosen for simplicity when the driver was first implemented.

With the introduction of the lightweight faux device interface, we now
have a more appropriate alternative. Migrate the driver to utilize the
faux bus, given that the platform device it previously created was not
a real one anyway. This will simplify the code, reducing its footprint
while maintaining functionality.

Cc: Andre Przywara <andre.przywara@arm.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/char/hw_random/arm_smccc_trng.c | 40 ++++++++++++++++++++++++---------
 drivers/firmware/smccc/smccc.c          | 21 -----------------
 2 files changed, 29 insertions(+), 32 deletions(-)

diff --git a/drivers/char/hw_random/arm_smccc_trng.c b/drivers/char/hw_random/arm_smccc_trng.c
index dcb8e7f37f25c6b39f76050369b9f324b7fb2e33..2ceab17f6360baaee999a23f3d7370b7b5b7d246 100644
--- a/drivers/char/hw_random/arm_smccc_trng.c
+++ b/drivers/char/hw_random/arm_smccc_trng.c
@@ -16,9 +16,11 @@
 #include <linux/device.h>
 #include <linux/hw_random.h>
 #include <linux/module.h>
-#include <linux/platform_device.h>
+#include <linux/device/faux.h>
 #include <linux/arm-smccc.h>
 
+#include <asm/archrandom.h>
+
 #ifdef CONFIG_ARM64
 #define ARM_SMCCC_TRNG_RND	ARM_SMCCC_TRNG_RND64
 #define MAX_BITS_PER_CALL	(3 * 64UL)
@@ -33,6 +35,8 @@
 #define SMCCC_RET_TRNG_INVALID_PARAMETER	-2
 #define SMCCC_RET_TRNG_NO_ENTROPY		-3
 
+bool __ro_after_init smccc_trng_available;
+
 static int copy_from_registers(char *buf, struct arm_smccc_res *res,
 			       size_t bytes)
 {
@@ -94,29 +98,43 @@ static int smccc_trng_read(struct hwrng *rng, void *data, size_t max, bool wait)
 	return copied;
 }
 
-static int smccc_trng_probe(struct platform_device *pdev)
+static int smccc_trng_probe(struct faux_device *fdev)
 {
 	struct hwrng *trng;
 
-	trng = devm_kzalloc(&pdev->dev, sizeof(*trng), GFP_KERNEL);
+	trng = devm_kzalloc(&fdev->dev, sizeof(*trng), GFP_KERNEL);
 	if (!trng)
 		return -ENOMEM;
 
 	trng->name = "smccc_trng";
 	trng->read = smccc_trng_read;
 
-	return devm_hwrng_register(&pdev->dev, trng);
+	return devm_hwrng_register(&fdev->dev, trng);
 }
 
-static struct platform_driver smccc_trng_driver = {
-	.driver = {
-		.name		= "smccc_trng",
-	},
-	.probe		= smccc_trng_probe,
+static struct faux_device_ops smccc_trng_ops = {
+	.probe = smccc_trng_probe,
 };
-module_platform_driver(smccc_trng_driver);
 
-MODULE_ALIAS("platform:smccc_trng");
+static int __init smccc_trng_init(void)
+{
+	struct faux_device *fdev;
+
+	smccc_trng_available = smccc_probe_trng();
+	if (!smccc_trng_available)
+		return 0;
+
+	fdev = faux_device_create("smccc_trng", NULL, &smccc_trng_ops);
+	if (!fdev) {
+		pr_err("smccc_trng: could not create the device\n");
+		return -ENODEV;
+	}
+
+	return 0;
+}
+device_initcall(smccc_trng_init);
+
+MODULE_ALIAS("faux:smccc_trng");
 MODULE_AUTHOR("Andre Przywara");
 MODULE_DESCRIPTION("Arm SMCCC TRNG firmware interface support");
 MODULE_LICENSE("GPL");
diff --git a/drivers/firmware/smccc/smccc.c b/drivers/firmware/smccc/smccc.c
index a74600d9f2d72a5aa0096004f53088c255927a43..0fcd175a53eeaa957d06071b3b26f4c3a3c7116e 100644
--- a/drivers/firmware/smccc/smccc.c
+++ b/drivers/firmware/smccc/smccc.c
@@ -9,13 +9,10 @@
 #include <linux/init.h>
 #include <linux/arm-smccc.h>
 #include <linux/kernel.h>
-#include <linux/platform_device.h>
-#include <asm/archrandom.h>
 
 static u32 smccc_version = ARM_SMCCC_VERSION_1_0;
 static enum arm_smccc_conduit smccc_conduit = SMCCC_CONDUIT_NONE;
 
-bool __ro_after_init smccc_trng_available = false;
 s32 __ro_after_init smccc_soc_id_version = SMCCC_RET_NOT_SUPPORTED;
 s32 __ro_after_init smccc_soc_id_revision = SMCCC_RET_NOT_SUPPORTED;
 
@@ -26,8 +23,6 @@ void __init arm_smccc_version_init(u32 version, enum arm_smccc_conduit conduit)
 	smccc_version = version;
 	smccc_conduit = conduit;
 
-	smccc_trng_available = smccc_probe_trng();
-
 	if ((smccc_version >= ARM_SMCCC_VERSION_1_2) &&
 	    (smccc_conduit != SMCCC_CONDUIT_NONE)) {
 		arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
@@ -66,19 +61,3 @@ s32 arm_smccc_get_soc_id_revision(void)
 	return smccc_soc_id_revision;
 }
 EXPORT_SYMBOL_GPL(arm_smccc_get_soc_id_revision);
-
-static int __init smccc_devices_init(void)
-{
-	struct platform_device *pdev;
-
-	if (smccc_trng_available) {
-		pdev = platform_device_register_simple("smccc_trng", -1,
-						       NULL, 0);
-		if (IS_ERR(pdev))
-			pr_err("smccc_trng: could not register device: %ld\n",
-			       PTR_ERR(pdev));
-	}
-
-	return 0;
-}
-device_initcall(smccc_devices_init);

-- 
2.34.1

[PATCH 3/9] efi: Remove redundant creation of the "efivars" platform device

[Sudeep Holla]

The "efivars" platform device is created but never tracked or used,
as there is no driver associated with it. Since this device serves
no functional purpose, removing its creation without affecting any
functionality.

Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-efi@vger.kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/firmware/efi/efi.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 7309394b8fc98cf7a3424af209b752f0251c8c89..eec173cb1f398d3b4f28b42c917e50e1728dc277 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -446,7 +446,6 @@ static int __init efisubsys_init(void)
 		error = efivar_ssdt_load();
 		if (error)
 			pr_err("efi: failed to load SSDT, error %d.\n", error);
-		platform_device_register_simple("efivars", 0, NULL, 0);
 	}
 
 	BLOCKING_INIT_NOTIFIER_HEAD(&efivar_ops_nh);

-- 
2.34.1

[PATCH 4/9] rtc: efi: Transition to the faux device interface

[Sudeep Holla]

The EFI RTC driver does not require the creation of a platform device.
Originally, this approach was chosen for simplicity when the driver was
first implemented.

With the introduction of the lightweight faux device interface, we now
have a more appropriate alternative. Migrate the driver to utilize the
faux bus, given that the platform device it previously created was not
a real one anyway. This will simplify the code, reducing its footprint
while maintaining functionality.

Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: linux-rtc@vger.kernel.org
Cc: linux-efi@vger.kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/firmware/efi/efi.c |  3 ---
 drivers/rtc/rtc-efi.c      | 31 ++++++++++++++++++++++---------
 2 files changed, 22 insertions(+), 12 deletions(-)

diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index eec173cb1f398d3b4f28b42c917e50e1728dc277..18deb2d212ce6944927f5e3a9a40bb6754e7ffa9 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -427,9 +427,6 @@ static int __init efisubsys_init(void)
 		}
 	}
 
-	if (efi_rt_services_supported(EFI_RT_SUPPORTED_TIME_SERVICES))
-		platform_device_register_simple("rtc-efi", 0, NULL, 0);
-
 	/* We register the efi directory at /sys/firmware/efi */
 	efi_kobj = kobject_create_and_add("efi", firmware_kobj);
 	if (!efi_kobj) {
diff --git a/drivers/rtc/rtc-efi.c b/drivers/rtc/rtc-efi.c
index fa8bf82df9488e7d1c23c058b4a3032dde74bc6e..3d21a470e8ff9777c5eeb991f3aa9170f6351930 100644
--- a/drivers/rtc/rtc-efi.c
+++ b/drivers/rtc/rtc-efi.c
@@ -14,7 +14,7 @@
 #include <linux/module.h>
 #include <linux/stringify.h>
 #include <linux/time.h>
-#include <linux/platform_device.h>
+#include <linux/device/faux.h>
 #include <linux/rtc.h>
 #include <linux/efi.h>
 
@@ -254,7 +254,7 @@ static const struct rtc_class_ops efi_rtc_ops = {
 	.proc		= efi_procfs,
 };
 
-static int __init efi_rtc_probe(struct platform_device *dev)
+static int __init efi_rtc_probe(struct faux_device *dev)
 {
 	struct rtc_device *rtc;
 	efi_time_t eft;
@@ -268,7 +268,7 @@ static int __init efi_rtc_probe(struct platform_device *dev)
 	if (IS_ERR(rtc))
 		return PTR_ERR(rtc);
 
-	platform_set_drvdata(dev, rtc);
+	faux_device_set_drvdata(dev, rtc);
 
 	rtc->ops = &efi_rtc_ops;
 	clear_bit(RTC_FEATURE_UPDATE_INTERRUPT, rtc->features);
@@ -282,15 +282,28 @@ static int __init efi_rtc_probe(struct platform_device *dev)
 	return devm_rtc_register_device(rtc);
 }
 
-static struct platform_driver efi_rtc_driver = {
-	.driver = {
-		.name = "rtc-efi",
-	},
+static struct faux_device_ops efi_rtc_fdev_ops = {
+	.probe = efi_rtc_probe,
 };
 
-module_platform_driver_probe(efi_rtc_driver, efi_rtc_probe);
+static int __init rtc_efi_init(void)
+{
+	struct faux_device *fdev;
+
+	if (!efi_rt_services_supported(EFI_RT_SUPPORTED_TIME_SERVICES))
+		return 0;
+
+	fdev = faux_device_create("rtc-efi", NULL, &efi_rtc_fdev_ops);
+	if (!fdev) {
+		pr_err("rtc-efi: could not create the device\n");
+		return -ENODEV;
+	}
+
+	return 0;
+}
+device_initcall(rtc_efi_init);
 
 MODULE_AUTHOR("dann frazier <dannf@dannf.org>");
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("EFI RTC driver");
-MODULE_ALIAS("platform:rtc-efi");
+MODULE_ALIAS("faux:rtc-efi");

-- 
2.34.1

[PATCH 5/9] virt: efi_secret: Transition to the faux device interface

[Sudeep Holla]

The EFI secret area driver does not require the creation of a platform
device. Originally, this approach was chosen for simplicity when the
driver was first implemented.

With the introduction of the lightweight faux device interface, we now
have a more appropriate alternative. Migrate the driver to utilize the
faux bus, given that the platform device it previously created was not
a real one anyway. This will simplify the code, reducing its footprint
while maintaining functionality.

Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-efi@vger.kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/firmware/efi/efi.c                |  6 -----
 drivers/virt/coco/efi_secret/efi_secret.c | 41 ++++++++++++++++++-------------
 2 files changed, 24 insertions(+), 23 deletions(-)

diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 18deb2d212ce6944927f5e3a9a40bb6754e7ffa9..4654a88d4e12f354a891118edf9001755285c69a 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -24,7 +24,6 @@
 #include <linux/initrd.h>
 #include <linux/io.h>
 #include <linux/kexec.h>
-#include <linux/platform_device.h>
 #include <linux/random.h>
 #include <linux/reboot.h>
 #include <linux/slab.h>
@@ -464,11 +463,6 @@ static int __init efisubsys_init(void)
 	if (efi_enabled(EFI_DBG) && efi_enabled(EFI_PRESERVE_BS_REGIONS))
 		efi_debugfs_init();
 
-#ifdef CONFIG_EFI_COCO_SECRET
-	if (efi.coco_secret != EFI_INVALID_TABLE_ADDR)
-		platform_device_register_simple("efi_secret", 0, NULL, 0);
-#endif
-
 	return 0;
 
 err_remove_group:
diff --git a/drivers/virt/coco/efi_secret/efi_secret.c b/drivers/virt/coco/efi_secret/efi_secret.c
index 1864f9f80617e082feb574a15327949972c8cc1e..4ba1a9f3b8a90981795d296d0a8dfdc9edb22966 100644
--- a/drivers/virt/coco/efi_secret/efi_secret.c
+++ b/drivers/virt/coco/efi_secret/efi_secret.c
@@ -16,7 +16,7 @@
  * is the GUID of the secret entry, and its content is the secret data.
  */
 
-#include <linux/platform_device.h>
+#include <linux/device/faux.h>
 #include <linux/seq_file.h>
 #include <linux/fs.h>
 #include <linux/kernel.h>
@@ -152,17 +152,12 @@ static const struct inode_operations efi_secret_dir_inode_operations = {
 	.unlink         = efi_secret_unlink,
 };
 
-static int efi_secret_map_area(struct platform_device *dev)
+static int efi_secret_map_area(struct faux_device *dev)
 {
 	int ret;
 	struct efi_secret *s = efi_secret_get();
 	struct linux_efi_coco_secret_area *secret_area;
 
-	if (efi.coco_secret == EFI_INVALID_TABLE_ADDR) {
-		dev_err(&dev->dev, "Secret area address is not available\n");
-		return -EINVAL;
-	}
-
 	secret_area = memremap(efi.coco_secret, sizeof(*secret_area), MEMREMAP_WB);
 	if (secret_area == NULL) {
 		dev_err(&dev->dev, "Could not map secret area EFI config entry\n");
@@ -191,7 +186,7 @@ static int efi_secret_map_area(struct platform_device *dev)
 	return ret;
 }
 
-static void efi_secret_securityfs_teardown(struct platform_device *dev)
+static void efi_secret_securityfs_teardown(struct faux_device *dev)
 {
 	struct efi_secret *s = efi_secret_get();
 	int i;
@@ -210,7 +205,7 @@ static void efi_secret_securityfs_teardown(struct platform_device *dev)
 	dev_dbg(&dev->dev, "Removed securityfs entries\n");
 }
 
-static int efi_secret_securityfs_setup(struct platform_device *dev)
+static int efi_secret_securityfs_setup(struct faux_device *dev)
 {
 	struct efi_secret *s = efi_secret_get();
 	int ret = 0, i = 0, bytes_left;
@@ -307,7 +302,7 @@ static void efi_secret_unmap_area(void)
 	}
 }
 
-static int efi_secret_probe(struct platform_device *dev)
+static int efi_secret_probe(struct faux_device *dev)
 {
 	int ret;
 
@@ -326,23 +321,35 @@ static int efi_secret_probe(struct platform_device *dev)
 	return ret;
 }
 
-static void efi_secret_remove(struct platform_device *dev)
+static void efi_secret_remove(struct faux_device *dev)
 {
 	efi_secret_securityfs_teardown(dev);
 	efi_secret_unmap_area();
 }
 
-static struct platform_driver efi_secret_driver = {
+static struct faux_device_ops efi_secret_ops = {
 	.probe = efi_secret_probe,
 	.remove = efi_secret_remove,
-	.driver = {
-		.name = "efi_secret",
-	},
 };
 
-module_platform_driver(efi_secret_driver);
+static int __init efi_secret_init(void)
+{
+	struct faux_device *fdev;
+
+	if (efi.coco_secret == EFI_INVALID_TABLE_ADDR)
+		return 0;
+
+	fdev = faux_device_create("efi_secret", NULL, &efi_secret_ops);
+	if (!fdev) {
+		pr_err("efi_secret: could not create the device\n");
+		return -ENODEV;
+	}
+
+	return 0;
+}
+device_initcall(efi_secret_init);
 
 MODULE_DESCRIPTION("Confidential computing EFI secret area access");
 MODULE_AUTHOR("IBM");
 MODULE_LICENSE("GPL");
-MODULE_ALIAS("platform:efi_secret");
+MODULE_ALIAS("faux:efi_secret");

-- 
2.34.1

[PATCH 6/9] ASoC: soc-utils: Transition to the faux device interface

[Sudeep Holla]

The ASoC soc-utils driver does not require the creation of a platform
device. Originally, this approach was chosen for simplicity when the
driver was first implemented.

With the introduction of the lightweight faux device interface, we now
have a more appropriate alternative. Migrate the driver to utilize the
faux bus, given that the platform device it previously created was not
a real one anyway. This will simplify the code, reducing its footprint
while maintaining functionality.

Cc: Mark Brown <broonie@kernel.org>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: linux-sound@vger.kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 sound/soc/soc-utils.c | 34 ++++++++++++----------------------
 1 file changed, 12 insertions(+), 22 deletions(-)

diff --git a/sound/soc/soc-utils.c b/sound/soc/soc-utils.c
index aa93e77ac937b0255c5dfa519207693fb560a6d6..a795c21756f79411cf59e209133db9f88edeb44c 100644
--- a/sound/soc/soc-utils.c
+++ b/sound/soc/soc-utils.c
@@ -7,7 +7,7 @@
 // Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
 //         Liam Girdwood <lrg@slimlogic.co.uk>
 
-#include <linux/platform_device.h>
+#include <linux/device/faux.h>
 #include <linux/export.h>
 #include <linux/math.h>
 #include <sound/core.h>
@@ -235,48 +235,38 @@ struct snd_soc_dai_link_component snd_soc_dummy_dlc = {
 };
 EXPORT_SYMBOL_GPL(snd_soc_dummy_dlc);
 
-static int snd_soc_dummy_probe(struct platform_device *pdev)
+static int snd_soc_dummy_probe(struct faux_device *fdev)
 {
 	int ret;
 
-	ret = devm_snd_soc_register_component(&pdev->dev,
+	ret = devm_snd_soc_register_component(&fdev->dev,
 					      &dummy_codec, &dummy_dai, 1);
 	if (ret < 0)
 		return ret;
 
-	ret = devm_snd_soc_register_component(&pdev->dev, &dummy_platform,
+	ret = devm_snd_soc_register_component(&fdev->dev, &dummy_platform,
 					      NULL, 0);
 
 	return ret;
 }
 
-static struct platform_driver soc_dummy_driver = {
-	.driver = {
-		.name = "snd-soc-dummy",
-	},
+static struct faux_device_ops soc_dummy_ops = {
 	.probe = snd_soc_dummy_probe,
 };
 
-static struct platform_device *soc_dummy_dev;
+static struct faux_device *soc_dummy_dev;
 
 int __init snd_soc_util_init(void)
 {
-	int ret;
-
-	soc_dummy_dev =
-		platform_device_register_simple("snd-soc-dummy", -1, NULL, 0);
-	if (IS_ERR(soc_dummy_dev))
-		return PTR_ERR(soc_dummy_dev);
+	soc_dummy_dev = faux_device_create("snd-soc-dummy", NULL,
+					   &soc_dummy_ops);
+	if (!soc_dummy_dev)
+		return -ENODEV;
 
-	ret = platform_driver_register(&soc_dummy_driver);
-	if (ret != 0)
-		platform_device_unregister(soc_dummy_dev);
-
-	return ret;
+	return 0;
 }
 
 void snd_soc_util_exit(void)
 {
-	platform_driver_unregister(&soc_dummy_driver);
-	platform_device_unregister(soc_dummy_dev);
+	faux_device_destroy(soc_dummy_dev);
 }

-- 
2.34.1

[PATCH 7/9] net: phy: fixed_phy: transition to the faux device interface

[Sudeep Holla]

The net fixed phy driver does not require the creation of a platform
device. Originally, this approach was chosen for simplicity when the
driver was first implemented.

With the introduction of the lightweight faux device interface, we now
have a more appropriate alternative. Migrate the driver to utilize the
faux bus, given that the platform device it previously created was not
a real one anyway. This will simplify the code, reducing its footprint
while maintaining functionality.

Cc: Andrew Lunn <andrew@lunn.ch>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/net/phy/fixed_phy.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/net/phy/fixed_phy.c b/drivers/net/phy/fixed_phy.c
index aef739c20ac4d5a271465a677a85ef7c18cfce70..ee7831a9849b3728ca9c541da35d17e089985da2 100644
--- a/drivers/net/phy/fixed_phy.c
+++ b/drivers/net/phy/fixed_phy.c
@@ -10,7 +10,7 @@
 
 #include <linux/kernel.h>
 #include <linux/module.h>
-#include <linux/platform_device.h>
+#include <linux/device/faux.h>
 #include <linux/list.h>
 #include <linux/mii.h>
 #include <linux/phy.h>
@@ -40,7 +40,7 @@ struct fixed_phy {
 	struct gpio_desc *link_gpiod;
 };
 
-static struct platform_device *pdev;
+static struct faux_device *fdev;
 static struct fixed_mdio_bus platform_fmb = {
 	.phys = LIST_HEAD_INIT(platform_fmb.phys),
 };
@@ -337,9 +337,9 @@ static int __init fixed_mdio_bus_init(void)
 	struct fixed_mdio_bus *fmb = &platform_fmb;
 	int ret;
 
-	pdev = platform_device_register_simple("Fixed MDIO bus", 0, NULL, 0);
-	if (IS_ERR(pdev))
-		return PTR_ERR(pdev);
+	fdev = faux_device_create("Fixed MDIO bus", NULL, NULL);
+	if (!fdev)
+		return -ENODEV;
 
 	fmb->mii_bus = mdiobus_alloc();
 	if (fmb->mii_bus == NULL) {
@@ -350,7 +350,7 @@ static int __init fixed_mdio_bus_init(void)
 	snprintf(fmb->mii_bus->id, MII_BUS_ID_SIZE, "fixed-0");
 	fmb->mii_bus->name = "Fixed MDIO Bus";
 	fmb->mii_bus->priv = fmb;
-	fmb->mii_bus->parent = &pdev->dev;
+	fmb->mii_bus->parent = &fdev->dev;
 	fmb->mii_bus->read = &fixed_mdio_read;
 	fmb->mii_bus->write = &fixed_mdio_write;
 	fmb->mii_bus->phy_mask = ~0;
@@ -364,7 +364,7 @@ static int __init fixed_mdio_bus_init(void)
 err_mdiobus_alloc:
 	mdiobus_free(fmb->mii_bus);
 err_mdiobus_reg:
-	platform_device_unregister(pdev);
+	faux_device_destroy(fdev);
 	return ret;
 }
 module_init(fixed_mdio_bus_init);
@@ -376,7 +376,7 @@ static void __exit fixed_mdio_bus_exit(void)
 
 	mdiobus_unregister(fmb->mii_bus);
 	mdiobus_free(fmb->mii_bus);
-	platform_device_unregister(pdev);
+	faux_device_destroy(fdev);
 
 	list_for_each_entry_safe(fp, tmp, &fmb->phys, node) {
 		list_del(&fp->node);

-- 
2.34.1

[PATCH 8/9] ACPI: APEI: EINJ: Transition to the faux device interface

[Sudeep Holla]

The APEI error injection driver does not require the creation of a
platform device. Originally, this approach was chosen for simplicity
when the driver was first implemented.

With the introduction of the lightweight faux device interface, we now
have a more appropriate alternative. Migrate the driver to utilize the
faux bus, given that the platform device it previously created was not
a real one anyway. This will simplify the code, reducing its footprint
while maintaining functionality.

Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: linux-acpi@vger.kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/acpi/apei/einj-core.c | 32 +++++++++++---------------------
 1 file changed, 11 insertions(+), 21 deletions(-)

diff --git a/drivers/acpi/apei/einj-core.c b/drivers/acpi/apei/einj-core.c
index 04731a5b01faaba534bad853d0acc4c8a873a53b..7ff334422899e757de918107202507dd171d61da 100644
--- a/drivers/acpi/apei/einj-core.c
+++ b/drivers/acpi/apei/einj-core.c
@@ -21,7 +21,7 @@
 #include <linux/nmi.h>
 #include <linux/delay.h>
 #include <linux/mm.h>
-#include <linux/platform_device.h>
+#include <linux/device/faux.h>
 #include <linux/unaligned.h>
 
 #include "apei-internal.h"
@@ -749,7 +749,7 @@ static int einj_check_table(struct acpi_table_einj *einj_tab)
 	return 0;
 }
 
-static int __init einj_probe(struct platform_device *pdev)
+static int __init einj_probe(struct faux_device *fdev)
 {
 	int rc;
 	acpi_status status;
@@ -851,7 +851,7 @@ static int __init einj_probe(struct platform_device *pdev)
 	return rc;
 }
 
-static void __exit einj_remove(struct platform_device *pdev)
+static void __exit einj_remove(struct faux_device *fdev)
 {
 	struct apei_exec_context ctx;
 
@@ -872,34 +872,25 @@ static void __exit einj_remove(struct platform_device *pdev)
 	acpi_put_table((struct acpi_table_header *)einj_tab);
 }
 
-static struct platform_device *einj_dev;
+static struct faux_device *einj_dev;
 /*
  * einj_remove() lives in .exit.text. For drivers registered via
  * platform_driver_probe() this is ok because they cannot get unbound at
  * runtime. So mark the driver struct with __refdata to prevent modpost
  * triggering a section mismatch warning.
  */
-static struct platform_driver einj_driver __refdata = {
+static struct faux_device_ops einj_device_ops __refdata = {
+	.probe = einj_probe,
 	.remove = __exit_p(einj_remove),
-	.driver = {
-		.name = "acpi-einj",
-	},
 };
 
 static int __init einj_init(void)
 {
-	struct platform_device_info einj_dev_info = {
-		.name = "acpi-einj",
-		.id = -1,
-	};
-	int rc;
-
-	einj_dev = platform_device_register_full(&einj_dev_info);
-	if (IS_ERR(einj_dev))
-		return PTR_ERR(einj_dev);
+	einj_dev = faux_device_create("acpi-einj", NULL, &einj_device_ops);
+	if (!einj_dev)
+		return -ENODEV;
 
-	rc = platform_driver_probe(&einj_driver, einj_probe);
-	einj_initialized = rc == 0;
+	einj_initialized = true;
 
 	return 0;
 }
@@ -907,9 +898,8 @@ static int __init einj_init(void)
 static void __exit einj_exit(void)
 {
 	if (einj_initialized)
-		platform_driver_unregister(&einj_driver);
+		faux_device_destroy(einj_dev);
 
-	platform_device_unregister(einj_dev);
 }
 
 module_init(einj_init);

-- 
2.34.1

[PATCH 9/9] regulator: dummy: convert to use the faux device interface

[Sudeep Holla]

From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The dummy regulator driver does not need to create a platform device, it
only did so because it was simple to do.  Change it over to use the
faux bus instead as this is NOT a real platform device, and it makes
the code even smaller than before.

Reviewed-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Message-Id: <2025021027-outclass-stress-59dd@gregkh>
(sudeep.holla: Made dummy_regulator_driver static)
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/regulator/dummy.c | 37 +++++++++----------------------------
 1 file changed, 9 insertions(+), 28 deletions(-)

diff --git a/drivers/regulator/dummy.c b/drivers/regulator/dummy.c
index 5b9b9e4e762d52151847bb1880377d51b04eeb9d..c3e416fd3c3e29d54278eb65600ab79d828edbde 100644
--- a/drivers/regulator/dummy.c
+++ b/drivers/regulator/dummy.c
@@ -13,7 +13,7 @@
 
 #include <linux/err.h>
 #include <linux/export.h>
-#include <linux/platform_device.h>
+#include <linux/device/faux.h>
 #include <linux/regulator/driver.h>
 #include <linux/regulator/machine.h>
 
@@ -37,15 +37,15 @@ static const struct regulator_desc dummy_desc = {
 	.ops = &dummy_ops,
 };
 
-static int dummy_regulator_probe(struct platform_device *pdev)
+static int dummy_regulator_probe(struct faux_device *fdev)
 {
 	struct regulator_config config = { };
 	int ret;
 
-	config.dev = &pdev->dev;
+	config.dev = &fdev->dev;
 	config.init_data = &dummy_initdata;
 
-	dummy_regulator_rdev = devm_regulator_register(&pdev->dev, &dummy_desc,
+	dummy_regulator_rdev = devm_regulator_register(&fdev->dev, &dummy_desc,
 						       &config);
 	if (IS_ERR(dummy_regulator_rdev)) {
 		ret = PTR_ERR(dummy_regulator_rdev);
@@ -56,36 +56,17 @@ static int dummy_regulator_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static struct platform_driver dummy_regulator_driver = {
-	.probe		= dummy_regulator_probe,
-	.driver		= {
-		.name		= "reg-dummy",
-		.probe_type	= PROBE_PREFER_ASYNCHRONOUS,
-	},
+static struct faux_device_ops dummy_regulator_driver = {
+	.probe = dummy_regulator_probe,
 };
 
-static struct platform_device *dummy_pdev;
+static struct faux_device *dummy_fdev;
 
 void __init regulator_dummy_init(void)
 {
-	int ret;
-
-	dummy_pdev = platform_device_alloc("reg-dummy", -1);
-	if (!dummy_pdev) {
+	dummy_fdev = faux_device_create("reg-dummy", NULL, &dummy_regulator_driver);
+	if (!dummy_fdev) {
 		pr_err("Failed to allocate dummy regulator device\n");
 		return;
 	}
-
-	ret = platform_device_add(dummy_pdev);
-	if (ret != 0) {
-		pr_err("Failed to register dummy regulator device: %d\n", ret);
-		platform_device_put(dummy_pdev);
-		return;
-	}
-
-	ret = platform_driver_register(&dummy_regulator_driver);
-	if (ret != 0) {
-		pr_err("Failed to register dummy regulator driver: %d\n", ret);
-		platform_device_unregister(dummy_pdev);
-	}
 }

-- 
2.34.1

Re: [PATCH 9/9] regulator: dummy: convert to use the faux device interface

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 449 bytes --]

On Mon, Mar 17, 2025 at 10:13:21AM +0000, Sudeep Holla wrote:
> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> The dummy regulator driver does not need to create a platform device, it
> only did so because it was simple to do.  Change it over to use the
> faux bus instead as this is NOT a real platform device, and it makes
> the code even smaller than before.

This is already in Greg's tree isn't it, what's going on here?  

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 9/9] regulator: dummy: convert to use the faux device interface

[Sudeep Holla]

On Mon, Mar 17, 2025 at 10:24:11AM +0000, Mark Brown wrote:
> On Mon, Mar 17, 2025 at 10:13:21AM +0000, Sudeep Holla wrote:
> > From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > 
> > The dummy regulator driver does not need to create a platform device, it
> > only did so because it was simple to do.  Change it over to use the
> > faux bus instead as this is NOT a real platform device, and it makes
> > the code even smaller than before.
> 
> This is already in Greg's tree isn't it, what's going on here? 

Sorry if it is already queued. I just checked against linux-next and
posted it as part of this series as I needed it as well to remove all
the "faux" devices under /sys/devices/platform.

I may be missing to check some other branch Greg has queued perhaps.

-- 
Regards,
Sudeep

Re: [PATCH 7/9] net: phy: fixed_phy: transition to the faux device interface

[Andrew Lunn]

On Mon, Mar 17, 2025 at 10:13:19AM +0000, Sudeep Holla wrote:
> The net fixed phy driver does not require the creation of a platform
> device. Originally, this approach was chosen for simplicity when the
> driver was first implemented.
> 
> With the introduction of the lightweight faux device interface, we now
> have a more appropriate alternative. Migrate the driver to utilize the
> faux bus, given that the platform device it previously created was not
> a real one anyway. This will simplify the code, reducing its footprint
> while maintaining functionality.
> 
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: netdev@vger.kernel.org
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  drivers/net/phy/fixed_phy.c | 16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)

8 insertions, 8 deletions. How does this reduce its footprint?

Seems like pointless churn to me. Unless there is a real advantage to
faux bus you are not enumerating in your commit message.

	Andrew

Re: [PATCH 9/9] regulator: dummy: convert to use the faux device interface

[Greg Kroah-Hartman]

On Mon, Mar 17, 2025 at 10:13:21AM +0000, Sudeep Holla wrote:
> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Why are you resending my patch back to me?

> The dummy regulator driver does not need to create a platform device, it
> only did so because it was simple to do.  Change it over to use the
> faux bus instead as this is NOT a real platform device, and it makes
> the code even smaller than before.
> 
> Reviewed-by: Mark Brown <broonie@kernel.org>
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Message-Id: <2025021027-outclass-stress-59dd@gregkh>
> (sudeep.holla: Made dummy_regulator_driver static)

So this is a new version?

And as was pointed out, this is already in my tree, and there's a
conflict in linux-next with it.

confused,

greg k-h

Re: [PATCH 7/9] net: phy: fixed_phy: transition to the faux device interface

[Greg Kroah-Hartman]

On Mon, Mar 17, 2025 at 01:29:31PM +0100, Andrew Lunn wrote:
> On Mon, Mar 17, 2025 at 10:13:19AM +0000, Sudeep Holla wrote:
> > The net fixed phy driver does not require the creation of a platform
> > device. Originally, this approach was chosen for simplicity when the
> > driver was first implemented.
> > 
> > With the introduction of the lightweight faux device interface, we now
> > have a more appropriate alternative. Migrate the driver to utilize the
> > faux bus, given that the platform device it previously created was not
> > a real one anyway. This will simplify the code, reducing its footprint
> > while maintaining functionality.
> > 
> > Cc: Andrew Lunn <andrew@lunn.ch>
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Cc: netdev@vger.kernel.org
> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> > ---
> >  drivers/net/phy/fixed_phy.c | 16 ++++++++--------
> >  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> 8 insertions, 8 deletions. How does this reduce its footprint?
> 
> Seems like pointless churn to me. Unless there is a real advantage to
> faux bus you are not enumerating in your commit message.

It stops the abuse of using a platform device for something that is NOT
a platform device.  This file should have never used a platform device
for this in the first place, and this change is fixing that design bug.

thanks,

greg k-h

Re: [PATCH 0/9] drivers: Transition to the faux device interface

[Greg Kroah-Hartman]

On Mon, Mar 17, 2025 at 10:13:12AM +0000, Sudeep Holla wrote:
> Recently when debugging why one of the scmi platform device was not
> showing up under /sys/devices/platform/firmware:scmi instead was
> appearing directly under /sys/devices/platform, I noticed the new
> faux interface /sys/devices/faux.
> 
> Looking through the discussion and the background, I got excited and
> took the opportunity to clear all the platform devices under
> /sys/devices/platform on the Arm Juno/FVP platforms that are really
> faux devices. Only the platform devices created for the device nodes
> from the DT remain under /sys/devices/platform after these changes.
> 
> All the patches are independent of each other.

That's great, but you need to send these all independently to each
subsystem as needed.  Having it all in one series doesn't work for any
of the maintainers of any of the subsystems.

And I'm glad to see this work happening, thanks for doing that!

greg k-h

Re: [PATCH 2/9] hwrng: arm-smccc-trng - transition to the faux device interface

[Greg Kroah-Hartman]

On Mon, Mar 17, 2025 at 10:13:14AM +0000, Sudeep Holla wrote:
> +MODULE_ALIAS("faux:smccc_trng");

Why do you need a branch new alias you just made up?  Please don't add
that for these types of devices, that's not going to work at all (just
like the platform alias really doesn't work well.

thanks,

greg k-h

Re: [PATCH 5/9] virt: efi_secret: Transition to the faux device interface

[Greg Kroah-Hartman]

On Mon, Mar 17, 2025 at 10:13:17AM +0000, Sudeep Holla wrote:
>  MODULE_DESCRIPTION("Confidential computing EFI secret area access");
>  MODULE_AUTHOR("IBM");
>  MODULE_LICENSE("GPL");
> -MODULE_ALIAS("platform:efi_secret");
> +MODULE_ALIAS("faux:efi_secret");

Again, no need for a module alias anymore.

Re: [PATCH 4/9] rtc: efi: Transition to the faux device interface

[Greg Kroah-Hartman]

On Mon, Mar 17, 2025 at 10:13:16AM +0000, Sudeep Holla wrote:
> The EFI RTC driver does not require the creation of a platform device.
> Originally, this approach was chosen for simplicity when the driver was
> first implemented.
> 
> With the introduction of the lightweight faux device interface, we now
> have a more appropriate alternative. Migrate the driver to utilize the
> faux bus, given that the platform device it previously created was not
> a real one anyway. This will simplify the code, reducing its footprint
> while maintaining functionality.
> 
> Cc: Ard Biesheuvel <ardb@kernel.org>
> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Cc: linux-rtc@vger.kernel.org
> Cc: linux-efi@vger.kernel.org
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  drivers/firmware/efi/efi.c |  3 ---
>  drivers/rtc/rtc-efi.c      | 31 ++++++++++++++++++++++---------
>  2 files changed, 22 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index eec173cb1f398d3b4f28b42c917e50e1728dc277..18deb2d212ce6944927f5e3a9a40bb6754e7ffa9 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -427,9 +427,6 @@ static int __init efisubsys_init(void)
>  		}
>  	}
>  
> -	if (efi_rt_services_supported(EFI_RT_SUPPORTED_TIME_SERVICES))
> -		platform_device_register_simple("rtc-efi", 0, NULL, 0);
> -
>  	/* We register the efi directory at /sys/firmware/efi */
>  	efi_kobj = kobject_create_and_add("efi", firmware_kobj);
>  	if (!efi_kobj) {
> diff --git a/drivers/rtc/rtc-efi.c b/drivers/rtc/rtc-efi.c
> index fa8bf82df9488e7d1c23c058b4a3032dde74bc6e..3d21a470e8ff9777c5eeb991f3aa9170f6351930 100644
> --- a/drivers/rtc/rtc-efi.c
> +++ b/drivers/rtc/rtc-efi.c
> @@ -14,7 +14,7 @@
>  #include <linux/module.h>
>  #include <linux/stringify.h>
>  #include <linux/time.h>
> -#include <linux/platform_device.h>
> +#include <linux/device/faux.h>
>  #include <linux/rtc.h>
>  #include <linux/efi.h>
>  
> @@ -254,7 +254,7 @@ static const struct rtc_class_ops efi_rtc_ops = {
>  	.proc		= efi_procfs,
>  };
>  
> -static int __init efi_rtc_probe(struct platform_device *dev)
> +static int __init efi_rtc_probe(struct faux_device *dev)
>  {
>  	struct rtc_device *rtc;
>  	efi_time_t eft;
> @@ -268,7 +268,7 @@ static int __init efi_rtc_probe(struct platform_device *dev)
>  	if (IS_ERR(rtc))
>  		return PTR_ERR(rtc);
>  
> -	platform_set_drvdata(dev, rtc);
> +	faux_device_set_drvdata(dev, rtc);
>  
>  	rtc->ops = &efi_rtc_ops;
>  	clear_bit(RTC_FEATURE_UPDATE_INTERRUPT, rtc->features);
> @@ -282,15 +282,28 @@ static int __init efi_rtc_probe(struct platform_device *dev)
>  	return devm_rtc_register_device(rtc);
>  }
>  
> -static struct platform_driver efi_rtc_driver = {
> -	.driver = {
> -		.name = "rtc-efi",
> -	},
> +static struct faux_device_ops efi_rtc_fdev_ops = {
> +	.probe = efi_rtc_probe,
>  };
>  
> -module_platform_driver_probe(efi_rtc_driver, efi_rtc_probe);
> +static int __init rtc_efi_init(void)
> +{
> +	struct faux_device *fdev;
> +
> +	if (!efi_rt_services_supported(EFI_RT_SUPPORTED_TIME_SERVICES))
> +		return 0;
> +
> +	fdev = faux_device_create("rtc-efi", NULL, &efi_rtc_fdev_ops);
> +	if (!fdev) {
> +		pr_err("rtc-efi: could not create the device\n");
> +		return -ENODEV;
> +	}
> +
> +	return 0;
> +}
> +device_initcall(rtc_efi_init);
>  
>  MODULE_AUTHOR("dann frazier <dannf@dannf.org>");
>  MODULE_LICENSE("GPL");
>  MODULE_DESCRIPTION("EFI RTC driver");
> -MODULE_ALIAS("platform:rtc-efi");
> +MODULE_ALIAS("faux:rtc-efi");

No alias please.

Re: [PATCH 4/9] rtc: efi: Transition to the faux device interface

[Sudeep Holla]

On Mon, Mar 17, 2025 at 02:07:00PM +0100, Greg Kroah-Hartman wrote:
> On Mon, Mar 17, 2025 at 10:13:16AM +0000, Sudeep Holla wrote:
> > The EFI RTC driver does not require the creation of a platform device.
> > Originally, this approach was chosen for simplicity when the driver was
> > first implemented.
> > 
> > With the introduction of the lightweight faux device interface, we now
> > have a more appropriate alternative. Migrate the driver to utilize the
> > faux bus, given that the platform device it previously created was not
> > a real one anyway. This will simplify the code, reducing its footprint
> > while maintaining functionality.
> > 
> > Cc: Ard Biesheuvel <ardb@kernel.org>
> > Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
> > Cc: linux-rtc@vger.kernel.org
> > Cc: linux-efi@vger.kernel.org
> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> > ---
> >  drivers/firmware/efi/efi.c |  3 ---
> >  drivers/rtc/rtc-efi.c      | 31 ++++++++++++++++++++++---------
> >  2 files changed, 22 insertions(+), 12 deletions(-)
> > 

[...]

> > -MODULE_ALIAS("platform:rtc-efi");
> > +MODULE_ALIAS("faux:rtc-efi");
> 
> No alias please.

Thanks for the review, will drop all the alias.

-- 
Regards,
Sudeep

Re: [PATCH 9/9] regulator: dummy: convert to use the faux device interface

[Sudeep Holla]

On Mon, Mar 17, 2025 at 02:00:04PM +0100, Greg Kroah-Hartman wrote:
> On Mon, Mar 17, 2025 at 10:13:21AM +0000, Sudeep Holla wrote:
> > From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> Why are you resending my patch back to me?
> 
> > The dummy regulator driver does not need to create a platform device, it
> > only did so because it was simple to do.  Change it over to use the
> > faux bus instead as this is NOT a real platform device, and it makes
> > the code even smaller than before.
> > 
> > Reviewed-by: Mark Brown <broonie@kernel.org>
> > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Message-Id: <2025021027-outclass-stress-59dd@gregkh>
> > (sudeep.holla: Made dummy_regulator_driver static)
> 
> So this is a new version?
> 

Not really, I pulled your patch as I needed that as well to clean out
all faux device out of platform. I just made dummy_regulator_driver
static back again as compiler was warning. Definitely nothing new.
I will drop it when posting v2. You can probably fix up to make
dummy_regulator_driver static.

> And as was pointed out, this is already in my tree, and there's a
> conflict in linux-next with it.
> 

Ah may be I missed to pull the updated next. I see I was still on
next-20250311. Sorry for that.

-- 
Regards,
Sudeep

Re: [PATCH 7/9] net: phy: fixed_phy: transition to the faux device interface

[Sudeep Holla]

On Mon, Mar 17, 2025 at 01:29:31PM +0100, Andrew Lunn wrote:
> On Mon, Mar 17, 2025 at 10:13:19AM +0000, Sudeep Holla wrote:
> > The net fixed phy driver does not require the creation of a platform
> > device. Originally, this approach was chosen for simplicity when the
> > driver was first implemented.
> > 
> > With the introduction of the lightweight faux device interface, we now
> > have a more appropriate alternative. Migrate the driver to utilize the
> > faux bus, given that the platform device it previously created was not
> > a real one anyway. This will simplify the code, reducing its footprint
> > while maintaining functionality.
> > 
> > Cc: Andrew Lunn <andrew@lunn.ch>
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Cc: netdev@vger.kernel.org
> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> > ---
> >  drivers/net/phy/fixed_phy.c | 16 ++++++++--------
> >  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> 8 insertions, 8 deletions. How does this reduce its footprint?
>

I meant the use of struct faux_device vs struct platform_device. Yes
it is not a big deal.

> Seems like pointless churn to me. Unless there is a real advantage to
> faux bus you are not enumerating in your commit message.
> 

Greg has answered that, so will skip.

-- 
Regards,
Sudeep

Re: [PATCH 0/9] drivers: Transition to the faux device interface

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 275 bytes --]

On Mon, Mar 17, 2025 at 10:13:12AM +0000, Sudeep Holla wrote:

> All the patches are independent of each other.

If that's the case don't send them in a series, it makes things more
complicated to apply and the CCs cause more mail.  Split independent
things up by subsystem.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 2/9] hwrng: arm-smccc-trng - transition to the faux device interface

[Sudeep Holla]

On Mon, Mar 17, 2025 at 02:04:27PM +0100, Greg Kroah-Hartman wrote:
> On Mon, Mar 17, 2025 at 10:13:14AM +0000, Sudeep Holla wrote:
> > +MODULE_ALIAS("faux:smccc_trng");
> 
> Why do you need a branch new alias you just made up?  Please don't add
> that for these types of devices, that's not going to work at all (just
> like the platform alias really doesn't work well.
> 

Sure I will drop all of those alias. One question I have if the idea of
creating a macro for this is good or bad ? I need this initial condition
flag to make use of such a macro, so I didn't go for it, but it does
remove some boiler-plate code.

Let me know what do you think of it ?

Regards,
Sudeep

-->8 
diff --git i/include/linux/device/faux.h w/include/linux/device/faux.h
index 9f43c0e46aa4..8af3eaef281a 100644
--- i/include/linux/device/faux.h
+++ w/include/linux/device/faux.h
@@ -66,4 +66,30 @@ static inline void faux_device_set_drvdata(struct faux_device *faux_dev, void *d
 	dev_set_drvdata(&faux_dev->dev, data);
 }
 
+#define module_faux_driver(name, tag, init_cond)			\
+static struct faux_device_ops tag##_ops = {				\
+	.probe = tag##_probe,						\
+	.remove = tag##_remove,						\
+};									\
+									\
+static struct faux_device *tag##_dev;					\
+									\
+static int __init tag##_init(void)					\
+{									\
+	if (!(init_cond))						\
+		return 0;						\
+	tag##_dev = faux_device_create(name, NULL, &tag##_ops);		\
+	if (!tag##_dev)							\
+		return -ENODEV;						\
+									\
+	return 0;							\
+}									\
+module_init(tag##_init);						\
+									\
+static void __exit tag##_exit(void)					\
+{									\
+	faux_device_destroy(tag##_dev);					\
+}									\
+module_exit(tag##_exit);						\
+
 #endif /* _FAUX_DEVICE_H_ */

Re: [PATCH 9/9] regulator: dummy: convert to use the faux device interface

[Greg Kroah-Hartman]

On Mon, Mar 17, 2025 at 02:13:49PM +0000, Sudeep Holla wrote:
> On Mon, Mar 17, 2025 at 02:00:04PM +0100, Greg Kroah-Hartman wrote:
> > On Mon, Mar 17, 2025 at 10:13:21AM +0000, Sudeep Holla wrote:
> > > From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > 
> > Why are you resending my patch back to me?
> > 
> > > The dummy regulator driver does not need to create a platform device, it
> > > only did so because it was simple to do.  Change it over to use the
> > > faux bus instead as this is NOT a real platform device, and it makes
> > > the code even smaller than before.
> > > 
> > > Reviewed-by: Mark Brown <broonie@kernel.org>
> > > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Message-Id: <2025021027-outclass-stress-59dd@gregkh>
> > > (sudeep.holla: Made dummy_regulator_driver static)
> > 
> > So this is a new version?
> > 
> 
> Not really, I pulled your patch as I needed that as well to clean out
> all faux device out of platform. I just made dummy_regulator_driver
> static back again as compiler was warning. Definitely nothing new.
> I will drop it when posting v2. You can probably fix up to make
> dummy_regulator_driver static.

My tree can't be rebased, can you just send a patch to make that change
instead?

thanks,

greg k-h

Re: [PATCH 0/9] drivers: Transition to the faux device interface

[Sudeep Holla]

On Mon, Mar 17, 2025 at 02:01:55PM +0100, Greg Kroah-Hartman wrote:
> On Mon, Mar 17, 2025 at 10:13:12AM +0000, Sudeep Holla wrote:
> > Recently when debugging why one of the scmi platform device was not
> > showing up under /sys/devices/platform/firmware:scmi instead was
> > appearing directly under /sys/devices/platform, I noticed the new
> > faux interface /sys/devices/faux.
> > 
> > Looking through the discussion and the background, I got excited and
> > took the opportunity to clear all the platform devices under
> > /sys/devices/platform on the Arm Juno/FVP platforms that are really
> > faux devices. Only the platform devices created for the device nodes
> > from the DT remain under /sys/devices/platform after these changes.
> > 
> > All the patches are independent of each other.
> 
> That's great, but you need to send these all independently to each
> subsystem as needed.  Having it all in one series doesn't work for any
> of the maintainers of any of the subsystems.
> 

Sure I can do that. I initially had idea of creating a macro that made
all of them depend on the macro but later dropped as I wanted to check
if that is good or a bad idea. I just asked you in the thread 2/9.

> And I'm glad to see this work happening, thanks for doing that!
> 

Thanks for adding faux interface!

-- 
Regards,
Sudeep

Re: [PATCH 2/9] hwrng: arm-smccc-trng - transition to the faux device interface

[Greg Kroah-Hartman]

On Mon, Mar 17, 2025 at 02:22:45PM +0000, Sudeep Holla wrote:
> On Mon, Mar 17, 2025 at 02:04:27PM +0100, Greg Kroah-Hartman wrote:
> > On Mon, Mar 17, 2025 at 10:13:14AM +0000, Sudeep Holla wrote:
> > > +MODULE_ALIAS("faux:smccc_trng");
> > 
> > Why do you need a branch new alias you just made up?  Please don't add
> > that for these types of devices, that's not going to work at all (just
> > like the platform alias really doesn't work well.
> > 
> 
> Sure I will drop all of those alias. One question I have if the idea of
> creating a macro for this is good or bad ? I need this initial condition
> flag to make use of such a macro, so I didn't go for it, but it does
> remove some boiler-plate code.
> 
> Let me know what do you think of it ?
> 
> Regards,
> Sudeep
> 
> -->8 
> diff --git i/include/linux/device/faux.h w/include/linux/device/faux.h
> index 9f43c0e46aa4..8af3eaef281a 100644
> --- i/include/linux/device/faux.h
> +++ w/include/linux/device/faux.h
> @@ -66,4 +66,30 @@ static inline void faux_device_set_drvdata(struct faux_device *faux_dev, void *d
>  	dev_set_drvdata(&faux_dev->dev, data);
>  }
>  
> +#define module_faux_driver(name, tag, init_cond)			\
> +static struct faux_device_ops tag##_ops = {				\
> +	.probe = tag##_probe,						\
> +	.remove = tag##_remove,						\
> +};									\
> +									\
> +static struct faux_device *tag##_dev;					\
> +									\
> +static int __init tag##_init(void)					\
> +{									\
> +	if (!(init_cond))						\
> +		return 0;						\
> +	tag##_dev = faux_device_create(name, NULL, &tag##_ops);		\
> +	if (!tag##_dev)							\
> +		return -ENODEV;						\
> +									\
> +	return 0;							\
> +}									\
> +module_init(tag##_init);						\
> +									\
> +static void __exit tag##_exit(void)					\
> +{									\
> +	faux_device_destroy(tag##_dev);					\
> +}									\
> +module_exit(tag##_exit);						\

Yes, I see that some of your changes could be moved to use this, so I
think it is worth it.

But why can't you use module_driver() here?  Ah, that init_cond?  And
the device.  Hm, why not put the init_cond in the probe callback?  That
should make this macro simpler.

And don't use "tag", that's an odd term here, just copy what
module_driver() does instead please.

thanks,

greg k-h

Re: [PATCH 9/9] regulator: dummy: convert to use the faux device interface

[Sudeep Holla]

On Mon, Mar 17, 2025 at 03:26:00PM +0100, Greg Kroah-Hartman wrote:
> On Mon, Mar 17, 2025 at 02:13:49PM +0000, Sudeep Holla wrote:
> > On Mon, Mar 17, 2025 at 02:00:04PM +0100, Greg Kroah-Hartman wrote:
> > > On Mon, Mar 17, 2025 at 10:13:21AM +0000, Sudeep Holla wrote:
> > > > From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > 
> > > Why are you resending my patch back to me?
> > > 
> > > > The dummy regulator driver does not need to create a platform device, it
> > > > only did so because it was simple to do.  Change it over to use the
> > > > faux bus instead as this is NOT a real platform device, and it makes
> > > > the code even smaller than before.
> > > > 
> > > > Reviewed-by: Mark Brown <broonie@kernel.org>
> > > > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > Message-Id: <2025021027-outclass-stress-59dd@gregkh>
> > > > (sudeep.holla: Made dummy_regulator_driver static)
> > > 
> > > So this is a new version?
> > > 
> > 
> > Not really, I pulled your patch as I needed that as well to clean out
> > all faux device out of platform. I just made dummy_regulator_driver
> > static back again as compiler was warning. Definitely nothing new.
> > I will drop it when posting v2. You can probably fix up to make
> > dummy_regulator_driver static.
> 
> My tree can't be rebased, can you just send a patch to make that change
> instead?
> 

Sure, will do that.

-- 
Regards,
Sudeep

Re: [PATCH 2/9] hwrng: arm-smccc-trng - transition to the faux device interface

[Sudeep Holla]

On Mon, Mar 17, 2025 at 03:30:15PM +0100, Greg Kroah-Hartman wrote:
> On Mon, Mar 17, 2025 at 02:22:45PM +0000, Sudeep Holla wrote:
> > On Mon, Mar 17, 2025 at 02:04:27PM +0100, Greg Kroah-Hartman wrote:
> > > On Mon, Mar 17, 2025 at 10:13:14AM +0000, Sudeep Holla wrote:
> > > > +MODULE_ALIAS("faux:smccc_trng");
> > > 
> > > Why do you need a branch new alias you just made up?  Please don't add
> > > that for these types of devices, that's not going to work at all (just
> > > like the platform alias really doesn't work well.
> > > 
> > 
> > Sure I will drop all of those alias. One question I have if the idea of
> > creating a macro for this is good or bad ? I need this initial condition
> > flag to make use of such a macro, so I didn't go for it, but it does
> > remove some boiler-plate code.
> > 
> > Let me know what do you think of it ?
> > 
> > Regards,
> > Sudeep
> > 
> > -->8 
> > diff --git i/include/linux/device/faux.h w/include/linux/device/faux.h
> > index 9f43c0e46aa4..8af3eaef281a 100644
> > --- i/include/linux/device/faux.h
> > +++ w/include/linux/device/faux.h
> > @@ -66,4 +66,30 @@ static inline void faux_device_set_drvdata(struct faux_device *faux_dev, void *d
> >  	dev_set_drvdata(&faux_dev->dev, data);
> >  }
> >  
> > +#define module_faux_driver(name, tag, init_cond)			\
> > +static struct faux_device_ops tag##_ops = {				\
> > +	.probe = tag##_probe,						\
> > +	.remove = tag##_remove,						\
> > +};									\
> > +									\
> > +static struct faux_device *tag##_dev;					\
> > +									\
> > +static int __init tag##_init(void)					\
> > +{									\
> > +	if (!(init_cond))						\
> > +		return 0;						\
> > +	tag##_dev = faux_device_create(name, NULL, &tag##_ops);		\
> > +	if (!tag##_dev)							\
> > +		return -ENODEV;						\
> > +									\
> > +	return 0;							\
> > +}									\
> > +module_init(tag##_init);						\
> > +									\
> > +static void __exit tag##_exit(void)					\
> > +{									\
> > +	faux_device_destroy(tag##_dev);					\
> > +}									\
> > +module_exit(tag##_exit);						\
> 
> Yes, I see that some of your changes could be moved to use this, so I
> think it is worth it.
> 
> But why can't you use module_driver() here?  Ah, that init_cond?  And
> the device.  Hm, why not put the init_cond in the probe callback?  That
> should make this macro simpler.
> 

I tried to keep the creation of the device itself conditional the way
it is today. Deferring the check to probe means the device gets created
unconditionally but won't be probed which is fine I guess. I was thinking
that device shouldn't show up on the bus if the condition is not met to
match the current scenario. I might be overthinking there.

> And don't use "tag", that's an odd term here, just copy what
> module_driver() does instead please.
> 

Sure, I will not use it. It was just a name that came to my mind.

Also creating the macro builds the dependency. Do you prefer to push the
changes as is and the macro in one release and make use of the macro later.

-- 
Regards,
Sudeep

Re: [PATCH 2/9] hwrng: arm-smccc-trng - transition to the faux device interface

[Greg Kroah-Hartman]

On Mon, Mar 17, 2025 at 02:43:21PM +0000, Sudeep Holla wrote:
> On Mon, Mar 17, 2025 at 03:30:15PM +0100, Greg Kroah-Hartman wrote:
> > On Mon, Mar 17, 2025 at 02:22:45PM +0000, Sudeep Holla wrote:
> > > On Mon, Mar 17, 2025 at 02:04:27PM +0100, Greg Kroah-Hartman wrote:
> > > > On Mon, Mar 17, 2025 at 10:13:14AM +0000, Sudeep Holla wrote:
> > > > > +MODULE_ALIAS("faux:smccc_trng");
> > > > 
> > > > Why do you need a branch new alias you just made up?  Please don't add
> > > > that for these types of devices, that's not going to work at all (just
> > > > like the platform alias really doesn't work well.
> > > > 
> > > 
> > > Sure I will drop all of those alias. One question I have if the idea of
> > > creating a macro for this is good or bad ? I need this initial condition
> > > flag to make use of such a macro, so I didn't go for it, but it does
> > > remove some boiler-plate code.
> > > 
> > > Let me know what do you think of it ?
> > > 
> > > Regards,
> > > Sudeep
> > > 
> > > -->8 
> > > diff --git i/include/linux/device/faux.h w/include/linux/device/faux.h
> > > index 9f43c0e46aa4..8af3eaef281a 100644
> > > --- i/include/linux/device/faux.h
> > > +++ w/include/linux/device/faux.h
> > > @@ -66,4 +66,30 @@ static inline void faux_device_set_drvdata(struct faux_device *faux_dev, void *d
> > >  	dev_set_drvdata(&faux_dev->dev, data);
> > >  }
> > >  
> > > +#define module_faux_driver(name, tag, init_cond)			\
> > > +static struct faux_device_ops tag##_ops = {				\
> > > +	.probe = tag##_probe,						\
> > > +	.remove = tag##_remove,						\
> > > +};									\
> > > +									\
> > > +static struct faux_device *tag##_dev;					\
> > > +									\
> > > +static int __init tag##_init(void)					\
> > > +{									\
> > > +	if (!(init_cond))						\
> > > +		return 0;						\
> > > +	tag##_dev = faux_device_create(name, NULL, &tag##_ops);		\
> > > +	if (!tag##_dev)							\
> > > +		return -ENODEV;						\
> > > +									\
> > > +	return 0;							\
> > > +}									\
> > > +module_init(tag##_init);						\
> > > +									\
> > > +static void __exit tag##_exit(void)					\
> > > +{									\
> > > +	faux_device_destroy(tag##_dev);					\
> > > +}									\
> > > +module_exit(tag##_exit);						\
> > 
> > Yes, I see that some of your changes could be moved to use this, so I
> > think it is worth it.
> > 
> > But why can't you use module_driver() here?  Ah, that init_cond?  And
> > the device.  Hm, why not put the init_cond in the probe callback?  That
> > should make this macro simpler.
> > 
> 
> I tried to keep the creation of the device itself conditional the way
> it is today. Deferring the check to probe means the device gets created
> unconditionally but won't be probed which is fine I guess. I was thinking
> that device shouldn't show up on the bus if the condition is not met to
> match the current scenario. I might be overthinking there.

It will not show up anywhere if the probe call fails.

> > And don't use "tag", that's an odd term here, just copy what
> > module_driver() does instead please.
> > 
> 
> Sure, I will not use it. It was just a name that came to my mind.
> 
> Also creating the macro builds the dependency. Do you prefer to push the
> changes as is and the macro in one release and make use of the macro later.

Let's see a series that adds the macro and uses it and we can figure it
out from there.  If the macro is sane, I can just take that now for
6.15-rc1 and then you can send the others to the different subsystems
after that shows up.

thanks,

greg k-h

Re: [PATCH 2/9] hwrng: arm-smccc-trng - transition to the faux device interface

[Sudeep Holla]

On Mon, Mar 17, 2025 at 05:46:46PM +0100, Greg Kroah-Hartman wrote:
> On Mon, Mar 17, 2025 at 02:43:21PM +0000, Sudeep Holla wrote:
> > On Mon, Mar 17, 2025 at 03:30:15PM +0100, Greg Kroah-Hartman wrote:
> > > On Mon, Mar 17, 2025 at 02:22:45PM +0000, Sudeep Holla wrote:
> > > > On Mon, Mar 17, 2025 at 02:04:27PM +0100, Greg Kroah-Hartman wrote:
> > > > > On Mon, Mar 17, 2025 at 10:13:14AM +0000, Sudeep Holla wrote:
> > > > > > +MODULE_ALIAS("faux:smccc_trng");
> > > > > 
> > > > > Why do you need a branch new alias you just made up?  Please don't add
> > > > > that for these types of devices, that's not going to work at all (just
> > > > > like the platform alias really doesn't work well.
> > > > > 
> > > > 
> > > > Sure I will drop all of those alias. One question I have if the idea of
> > > > creating a macro for this is good or bad ? I need this initial condition
> > > > flag to make use of such a macro, so I didn't go for it, but it does
> > > > remove some boiler-plate code.
> > > > 
> > > > Let me know what do you think of it ?
> > > > 
> > > > Regards,
> > > > Sudeep
> > > > 
> > > > -->8 
> > > > diff --git i/include/linux/device/faux.h w/include/linux/device/faux.h
> > > > index 9f43c0e46aa4..8af3eaef281a 100644
> > > > --- i/include/linux/device/faux.h
> > > > +++ w/include/linux/device/faux.h
> > > > @@ -66,4 +66,30 @@ static inline void faux_device_set_drvdata(struct faux_device *faux_dev, void *d
> > > >  	dev_set_drvdata(&faux_dev->dev, data);
> > > >  }
> > > >  
> > > > +#define module_faux_driver(name, tag, init_cond)			\
> > > > +static struct faux_device_ops tag##_ops = {				\
> > > > +	.probe = tag##_probe,						\
> > > > +	.remove = tag##_remove,						\
> > > > +};									\
> > > > +									\
> > > > +static struct faux_device *tag##_dev;					\
> > > > +									\
> > > > +static int __init tag##_init(void)					\
> > > > +{									\
> > > > +	if (!(init_cond))						\
> > > > +		return 0;						\
> > > > +	tag##_dev = faux_device_create(name, NULL, &tag##_ops);		\
> > > > +	if (!tag##_dev)							\
> > > > +		return -ENODEV;						\
> > > > +									\
> > > > +	return 0;							\
> > > > +}									\
> > > > +module_init(tag##_init);						\
> > > > +									\
> > > > +static void __exit tag##_exit(void)					\
> > > > +{									\
> > > > +	faux_device_destroy(tag##_dev);					\
> > > > +}									\
> > > > +module_exit(tag##_exit);						\
> > > 
> > > Yes, I see that some of your changes could be moved to use this, so I
> > > think it is worth it.
> > > 
> > > But why can't you use module_driver() here?  Ah, that init_cond?  And
> > > the device.  Hm, why not put the init_cond in the probe callback?  That
> > > should make this macro simpler.
> > > 
> > 
> > I tried to keep the creation of the device itself conditional the way
> > it is today. Deferring the check to probe means the device gets created
> > unconditionally but won't be probed which is fine I guess. I was thinking
> > that device shouldn't show up on the bus if the condition is not met to
> > match the current scenario. I might be overthinking there.
> 
> It will not show up anywhere if the probe call fails.

Ah, nice. I somehow didn't realise that. Thanks for that info.

> 
> > > And don't use "tag", that's an odd term here, just copy what
> > > module_driver() does instead please.
> > > 
> > 
> > Sure, I will not use it. It was just a name that came to my mind.
> > 
> > Also creating the macro builds the dependency. Do you prefer to push the
> > changes as is and the macro in one release and make use of the macro later.
> 
> Let's see a series that adds the macro and uses it and we can figure it
> out from there.  If the macro is sane, I can just take that now for
> 6.15-rc1 and then you can send the others to the different subsystems
> after that shows up.
> 

Sure, thanks again.

-- 
Regards,
Sudeep

Re: [PATCH 3/9] efi: Remove redundant creation of the "efivars" platform device

[Ard Biesheuvel]

On Mon, 17 Mar 2025 at 11:13, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> The "efivars" platform device is created but never tracked or used,
> as there is no driver associated with it. Since this device serves
> no functional purpose, removing its creation without affecting any
> functionality.
>
> Cc: Ard Biesheuvel <ardb@kernel.org>
> Cc: linux-efi@vger.kernel.org
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  drivers/firmware/efi/efi.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index 7309394b8fc98cf7a3424af209b752f0251c8c89..eec173cb1f398d3b4f28b42c917e50e1728dc277 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -446,7 +446,6 @@ static int __init efisubsys_init(void)
>                 error = efivar_ssdt_load();
>                 if (error)
>                         pr_err("efi: failed to load SSDT, error %d.\n", error);
> -               platform_device_register_simple("efivars", 0, NULL, 0);
>         }
>
>         BLOCKING_INIT_NOTIFIER_HEAD(&efivar_ops_nh);
>

IIRC the efi-pstore module autoloads based on this platform device

Re: [PATCH 3/9] efi: Remove redundant creation of the "efivars" platform device

[Sudeep Holla]

On Mon, Mar 17, 2025 at 06:06:24PM +0100, Ard Biesheuvel wrote:
> On Mon, 17 Mar 2025 at 11:13, Sudeep Holla <sudeep.holla@arm.com> wrote:
> >
> > The "efivars" platform device is created but never tracked or used,
> > as there is no driver associated with it. Since this device serves
> > no functional purpose, removing its creation without affecting any
> > functionality.
> >
> > Cc: Ard Biesheuvel <ardb@kernel.org>
> > Cc: linux-efi@vger.kernel.org
> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> > ---
> >  drivers/firmware/efi/efi.c | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> > index 7309394b8fc98cf7a3424af209b752f0251c8c89..eec173cb1f398d3b4f28b42c917e50e1728dc277 100644
> > --- a/drivers/firmware/efi/efi.c
> > +++ b/drivers/firmware/efi/efi.c
> > @@ -446,7 +446,6 @@ static int __init efisubsys_init(void)
> >                 error = efivar_ssdt_load();
> >                 if (error)
> >                         pr_err("efi: failed to load SSDT, error %d.\n", error);
> > -               platform_device_register_simple("efivars", 0, NULL, 0);
> >         }
> >
> >         BLOCKING_INIT_NOTIFIER_HEAD(&efivar_ops_nh);
> >
>
> IIRC the efi-pstore module autoloads based on this platform device

Indeed I see now, thanks. My bad grep skills didn't work well to catch
this. I will update accordingly.

-- 
Regards,
Sudeep

Re: (subset) [PATCH 0/9] drivers: Transition to the faux device interface

[Mark Brown]

On Mon, 17 Mar 2025 10:13:12 +0000, Sudeep Holla wrote:
> Recently when debugging why one of the scmi platform device was not
> showing up under /sys/devices/platform/firmware:scmi instead was
> appearing directly under /sys/devices/platform, I noticed the new
> faux interface /sys/devices/faux.
> 
> Looking through the discussion and the background, I got excited and
> took the opportunity to clear all the platform devices under
> /sys/devices/platform on the Arm Juno/FVP platforms that are really
> faux devices. Only the platform devices created for the device nodes
> from the DT remain under /sys/devices/platform after these changes.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[6/9] ASoC: soc-utils: Transition to the faux device interface
      commit: 18abb3797f1ceca97a705aa1c14cbec5c6fcab79

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

Re: [PATCH 1/9] cpuidle: psci: Transition to the faux device interface

[Rafael J. Wysocki]

On Mon, Mar 17, 2025 at 11:13 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> The PSCI cpuidle driver does not require the creation of a platform
> device. Originally, this approach was chosen for simplicity when the
> driver was first implemented.
>
> With the introduction of the lightweight faux device interface, we now
> have a more appropriate alternative. Migrate the driver to utilize the
> faux bus, given that the platform device it previously created was not
> a real one anyway. This will simplify the code, reducing its footprint
> while maintaining functionality.
>
> Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
> Cc: linux-pm@vger.kernel.org
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>

Do you want me to pick up this one?

> ---
>  drivers/cpuidle/cpuidle-psci.c | 26 +++++++++-----------------
>  1 file changed, 9 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/cpuidle/cpuidle-psci.c b/drivers/cpuidle/cpuidle-psci.c
> index 2562dc001fc1de69732ef28f383d2809262a3d96..3e38f712dab3785d5caa8d103fd0146156005921 100644
> --- a/drivers/cpuidle/cpuidle-psci.c
> +++ b/drivers/cpuidle/cpuidle-psci.c
> @@ -16,7 +16,7 @@
>  #include <linux/kernel.h>
>  #include <linux/module.h>
>  #include <linux/of.h>
> -#include <linux/platform_device.h>
> +#include <linux/device/faux.h>
>  #include <linux/psci.h>
>  #include <linux/pm_domain.h>
>  #include <linux/pm_runtime.h>
> @@ -404,14 +404,14 @@ static int psci_idle_init_cpu(struct device *dev, int cpu)
>   * to register cpuidle driver then rollback to cancel all CPUs
>   * registration.
>   */
> -static int psci_cpuidle_probe(struct platform_device *pdev)
> +static int psci_cpuidle_probe(struct faux_device *fdev)
>  {
>         int cpu, ret;
>         struct cpuidle_driver *drv;
>         struct cpuidle_device *dev;
>
>         for_each_possible_cpu(cpu) {
> -               ret = psci_idle_init_cpu(&pdev->dev, cpu);
> +               ret = psci_idle_init_cpu(&fdev->dev, cpu);
>                 if (ret)
>                         goto out_fail;
>         }
> @@ -431,26 +431,18 @@ static int psci_cpuidle_probe(struct platform_device *pdev)
>         return ret;
>  }
>
> -static struct platform_driver psci_cpuidle_driver = {
> +static struct faux_device_ops psci_cpuidle_ops = {
>         .probe = psci_cpuidle_probe,
> -       .driver = {
> -               .name = "psci-cpuidle",
> -       },
>  };
>
>  static int __init psci_idle_init(void)
>  {
> -       struct platform_device *pdev;
> -       int ret;
> +       struct faux_device *fdev;
>
> -       ret = platform_driver_register(&psci_cpuidle_driver);
> -       if (ret)
> -               return ret;
> -
> -       pdev = platform_device_register_simple("psci-cpuidle", -1, NULL, 0);
> -       if (IS_ERR(pdev)) {
> -               platform_driver_unregister(&psci_cpuidle_driver);
> -               return PTR_ERR(pdev);
> +       fdev = faux_device_create("psci-cpuidle", NULL, &psci_cpuidle_ops);
> +       if (!fdev) {
> +               pr_err("Failed to create psci-cpuidle device\n");
> +               return -ENODEV;
>         }
>
>         return 0;
>
> --
> 2.34.1
>

Re: [PATCH 1/9] cpuidle: psci: Transition to the faux device interface

[Sudeep Holla]

On Wed, Apr 09, 2025 at 08:03:32PM +0200, Rafael J. Wysocki wrote:
> On Mon, Mar 17, 2025 at 11:13 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
> >
> > The PSCI cpuidle driver does not require the creation of a platform
> > device. Originally, this approach was chosen for simplicity when the
> > driver was first implemented.
> >
> > With the introduction of the lightweight faux device interface, we now
> > have a more appropriate alternative. Migrate the driver to utilize the
> > faux bus, given that the platform device it previously created was not
> > a real one anyway. This will simplify the code, reducing its footprint
> > while maintaining functionality.
> >
> > Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
> > Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> > Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
> > Cc: linux-pm@vger.kernel.org
> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> 
> Do you want me to pick up this one?
> 

Yes you can pick this up.

Just checked again, this is v1 and correct version.

-- 
Regards,
Sudeep

Re: [PATCH 1/9] cpuidle: psci: Transition to the faux device interface

[Rafael J. Wysocki]

On Wed, Apr 9, 2025 at 9:18 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> On Wed, Apr 09, 2025 at 08:03:32PM +0200, Rafael J. Wysocki wrote:
> > On Mon, Mar 17, 2025 at 11:13 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
> > >
> > > The PSCI cpuidle driver does not require the creation of a platform
> > > device. Originally, this approach was chosen for simplicity when the
> > > driver was first implemented.
> > >
> > > With the introduction of the lightweight faux device interface, we now
> > > have a more appropriate alternative. Migrate the driver to utilize the
> > > faux bus, given that the platform device it previously created was not
> > > a real one anyway. This will simplify the code, reducing its footprint
> > > while maintaining functionality.
> > >
> > > Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
> > > Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> > > Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
> > > Cc: linux-pm@vger.kernel.org
> > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> >
> > Do you want me to pick up this one?
> >
>
> Yes you can pick this up.
>
> Just checked again, this is v1 and correct version.

Applied as 6.16 material, thanks!

Re: [PATCH 8/9] ACPI: APEI: EINJ: Transition to the faux device interface

[Dan Williams]

[ add linux-cxl ]

Sudeep Holla wrote:
> The APEI error injection driver does not require the creation of a
> platform device. Originally, this approach was chosen for simplicity
> when the driver was first implemented.
> 
> With the introduction of the lightweight faux device interface, we now
> have a more appropriate alternative. Migrate the driver to utilize the
> faux bus, given that the platform device it previously created was not
> a real one anyway. This will simplify the code, reducing its footprint
> while maintaining functionality.
> 
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: linux-acpi@vger.kernel.org
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  drivers/acpi/apei/einj-core.c | 32 +++++++++++---------------------
>  1 file changed, 11 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/acpi/apei/einj-core.c b/drivers/acpi/apei/einj-core.c
> index 04731a5b01faaba534bad853d0acc4c8a873a53b..7ff334422899e757de918107202507dd171d61da 100644
> --- a/drivers/acpi/apei/einj-core.c
> +++ b/drivers/acpi/apei/einj-core.c
[..]
>  static int __init einj_init(void)
>  {
> -	struct platform_device_info einj_dev_info = {
> -		.name = "acpi-einj",
> -		.id = -1,
> -	};
> -	int rc;
> -
> -	einj_dev = platform_device_register_full(&einj_dev_info);
> -	if (IS_ERR(einj_dev))
> -		return PTR_ERR(einj_dev);
> +	einj_dev = faux_device_create("acpi-einj", NULL, &einj_device_ops);
> +	if (!einj_dev)
> +		return -ENODEV;
>  
> -	rc = platform_driver_probe(&einj_driver, einj_probe);
> -	einj_initialized = rc == 0;
> +	einj_initialized = true;

git bisect says this change breaks CXL subsystem initialization. This
patch seems to not understand the semantic guarantees of
platform_driver_probe().

CXL init now fails with:

    faux acpi-einj: probe did not succeed, tearing down the device

...which will fire on the majority of CXL systems because EINJ is optional.

However, failure to probe is not a module load condition failure because
the CXL subsystem still needs access to the symbols even on systems
where the EINJ facility is disabled. In other words CXL has a module
dependency on einj.ko, but all of its entry points into that module
first check einj_initialized. So part of the fix is:

diff --git a/drivers/acpi/apei/einj-core.c b/drivers/acpi/apei/einj-core.c
index fea11a35eea3..9b041415a9d0 100644
--- a/drivers/acpi/apei/einj-core.c
+++ b/drivers/acpi/apei/einj-core.c
@@ -883,19 +883,16 @@ static int __init einj_init(void)
        }
 
        einj_dev = faux_device_create("acpi-einj", NULL, &einj_device_ops);
-       if (!einj_dev)
-               return -ENODEV;
 
-       einj_initialized = true;
+       if (einj_dev)
+               einj_initialized = true;
 
        return 0;
 }
 
 static void __exit einj_exit(void)
 {
-       if (einj_initialized)
-               faux_device_destroy(einj_dev);
-
+       faux_device_destroy(einj_dev);
 }
 
 module_init(einj_init);

However, that is not sufficient because faux_device_create() unlike
platform_driver_probe() does not suppress bind attributes which means
that einj_initialized result is not stable. I.e. somebody can unbind the
faux_driver from any faux_device at any time.

I think it is reasonable for faux_devices to only have one chance to
call ->probe() at create time:

diff --git a/drivers/base/faux.c b/drivers/base/faux.c
index 9054d346bd7f..934da77ca48b 100644
--- a/drivers/base/faux.c
+++ b/drivers/base/faux.c
@@ -86,6 +86,7 @@ static struct device_driver faux_driver = {
        .name           = "faux_driver",
        .bus            = &faux_bus_type,
        .probe_type     = PROBE_FORCE_SYNCHRONOUS,
+       .suppress_bind_attrs = true,
 };
 
 static void faux_device_release(struct device *dev)

Unless that global change is acceptable I do not think
faux_device_create() is a suitable replacement for
platform_driver_probe().

Lastly, for cases where probe failure are ok the dev_err() is too noisy,
so another change to make it behave like platform_driver_probe() would
be:

diff --git a/drivers/base/faux.c b/drivers/base/faux.c
index 9054d346bd7f..f5fbda0a9a44 100644
--- a/drivers/base/faux.c
+++ b/drivers/base/faux.c
@@ -169,7 +170,7 @@ struct faux_device *faux_device_create_with_groups(const char *name,
         * successful is almost impossible to determine by the caller.
         */
        if (!dev->driver) {
-               dev_err(dev, "probe did not succeed, tearing down the device\n");
+               dev_dbg(dev, "probe did not succeed, tearing down the device\n");
                faux_device_destroy(faux_dev);
                faux_dev = NULL;
        }

Greg, if you are ok with suppress_bind_attrs = true for faux devices I will
wrap the above into a 3 patch series to fix the regression.