Re: [PATCH RFC 2/2] soc: Add a basic ACPI generic driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux