Hi Olof,
Based on everything I've seen so far, this should go under drivers/acpi instead.
soc drivers seem to live in drivers/soc (non-arm32, anyway), so I
decided on this location. But drivers/acpi would also seem reasonable now.
We don't want drivers/soc to be too much of a catch-all -- it is meant
for some of the glue pieces that don't have good homes elsewhere.
Unfortunately, the slope is slippery and we've already gone down it a
bit, but I think we can fairly clearly declare that this kind of
cross-soc material is likely not the right home for it -- especially
when drivers/acpi is a good fit in this case.
ok
diff --git a/drivers/soc/acpi_generic.c b/drivers/soc/acpi_generic.c
new file mode 100644
index 000000000000..34a1f5f8e063
--- /dev/null
+++ b/drivers/soc/acpi_generic.c
@@ -0,0 +1,102 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) John Garry, john.garry@xxxxxxxxxx
+ */
+
+#define pr_fmt(fmt) "SOC ACPI GENERIC: " fmt
+
+#include <linux/acpi.h>
+#include <linux/sys_soc.h>
+
[...]
Hmm, this doesn't look like much of a driver to me. This looks like
the export of an attribute to userspace, and should probably be done
by ACPI core instead of creating an empty driver for it.
OK, but I'm thinking that having a soc driver can be useful as it is
common to DT, and so userspace only has to check a single location. And
the soc driver can also cover multiple-chip systems without have to
reinvent that code for ACPI core. And it saves adding a new ABI.
While having a single location could be convenient, the actual data
read/written would be different (I'm guessing).
Without doubt we would have different data sometimes between ACPI and DT
FW..
And it is not ideal that the soc_id sysfs file could have different
contents for the same SoC, depending on ACPI or DT.
We also already have a supposed standard way of figuring out what SoC
we're on (toplevel compatible for the DT).
From checking some soc drivers, there is a distinction between how
soc_id and machine is evaluated: machine comes from DT model, which
looks standard; however soc_id seems to have different methods of
evaluate, like sometimes reading some system id register (I'm checking
exynos-chipid.c there).
We're just looking for soc_id. But, as before, it would probably be
different between ACPI and DT, so not ideal.
So no matter what, I think
userspace will need to handle two ways of probing this.
That should not be a big problem.
Thanks,
John
