On 4/11/22 6:40 PM, Hans de Goede wrote: > Hi, > > On 4/11/22 15:37, Rafael J. Wysocki wrote: >> On Mon, Apr 11, 2022 at 3:26 PM Hans de Goede <hdegoede@xxxxxxxxxx> wrote: >>> >>> Hi, >>> >>> On 4/7/22 14:35, Muhammad Usama Anjum wrote: >>>> From: Enric Balletbo i Serra <enric.balletbo@xxxxxxxxxxxxx> >>>> >>>> The x86 Chromebooks have ChromeOS ACPI device. This driver attaches to >>>> the ChromeOS ACPI device and exports the values reported by ACPI in a >>>> sysfs directory. This data isn't present in ACPI tables when read >>>> through ACPI tools, hence a driver is needed to do it. The driver gets >>>> data from firmware using ACPI component of the kernel. The ACPI values >>>> are presented in string form (numbers as decimal values) or binary >>>> blobs, and can be accessed as the contents of the appropriate read only >>>> files in the standard ACPI device's sysfs directory tree. This data is >>>> consumed by the ChromeOS user space. >>>> >>>> Cc: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx> >>>> Cc: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> >>>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@xxxxxxxxxxxxx> >>>> Signed-off-by: Muhammad Usama Anjum <usama.anjum@xxxxxxxxxxxxx> >>> >>> >>> Thanks overall this looks pretty good to me. The only remark which >>> I have is that I would like to see the Kconfig symbol changed >>> from CONFIG_ACPI_CHROMEOS to CONFIG_CHROMEOS_ACPI to match the >>> filename. >>> I'll rename in next version. >>> CONFIG_ACPI_CHROMEOS to me suggests that this is an ACPI subsystem >>> Kconfig option which, with the driver living under >>> drivers/platform/x86 it is not. >>> >>> There is no need to send a new version for this, if you agree >>> with the change let me know and I can change this while merging >>> the driver. >>> >>> Rafael, before I merge this do you have any (more) remarks >>> about this driver? >> >> I'm not sure why it has to be an acpi_driver. >> >> I think that the generic enumeration code creates a platform device >> for this ACPI device object, so why can't it bind to that platform >> device? >> >> Generally speaking, IMV we should avoid adding drivers binding >> directly to ACPI device objects, because that is confusing (it is kind >> of like binding directly to an of_node) and it should be entirely >> avoidable. > > Ah I missed that, good point. > > Muhammad can you give turning this into a platform driver a try please? > > Note this will change all the sysfs attribute paths from: > > /sys/bus/acpi/devices/GGL0001:00/... > > to: > > /sys/bus/platform/devices/GGL0001:00/... > > and the ABI documentation should be updated accordingly. > Thank you for comments and directions. They mean a lot. I'll make the changes in next version. > Regards, > > Hans > > > -- Muhammad Usama Anjum
