linux-kernel - Re: [PATCH RESEND v6] platform: x86: Add ChromeOS ACPI device driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 11 Apr 2022 15:40:58 +0200
From:   Hans de Goede <hdegoede@...hat.com>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     Muhammad Usama Anjum <usama.anjum@...labora.com>,
        Len Brown <lenb@...nel.org>, Mark Gross <markgross@...nel.org>,
        Collabora Kernel ML <kernel@...labora.com>,
        Guenter Roeck <groeck@...omium.org>,
        Benson Leung <bleung@...omium.org>,
        Dmitry Torokhov <dtor@...omium.org>,
        Gwendal Grignou <gwendal@...omium.org>, vbendeb@...omium.org,
        Andy Shevchenko <andy@...radead.org>,
        Ayman Bagabas <ayman.bagabas@...il.com>,
        Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        Blaž Hrastnik <blaz@...n.io>,
        Darren Hart <dvhart@...radead.org>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jeremy Soller <jeremy@...tem76.com>,
        Mattias Jacobsson <2pi@....nu>,
        Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
        Rajat Jain <rajatja@...gle.com>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
        Enric Balletbo i Serra <eballetbo@...il.com>
Subject: Re: [PATCH RESEND v6] platform: x86: Add ChromeOS ACPI device driver

Hi,

On 4/11/22 15:37, Rafael J. Wysocki wrote:
> On Mon, Apr 11, 2022 at 3:26 PM Hans de Goede <hdegoede@...hat.com> wrote:
>>
>> Hi,
>>
>> On 4/7/22 14:35, Muhammad Usama Anjum wrote:
>>> From: Enric Balletbo i Serra <enric.balletbo@...labora.com>
>>>
>>> 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@...el.com>
>>> Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>
>>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@...labora.com>
>>> Signed-off-by: Muhammad Usama Anjum <usama.anjum@...labora.com>
>>
>>
>> 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.
>>
>> 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.

Regards,

Hans