From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6E722C433F5 for ; Thu, 14 Apr 2022 09:07:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241519AbiDNJKK (ORCPT ); Thu, 14 Apr 2022 05:10:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42950 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241325AbiDNJKH (ORCPT ); Thu, 14 Apr 2022 05:10:07 -0400 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [46.235.227.227]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A7B7E6D962; Thu, 14 Apr 2022 02:07:43 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: usama.anjum) with ESMTPSA id 148F51F4778C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1649927262; bh=SGjdvm2jxn/wrvUxD5fVBXM2K5YNhQcQ079/GSOHMTM=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=m1VxcuIEimr1pL6AXUPBpixE9KfydqWy+Yvf7QNvQCWgfZo4BqCHbv/VeS0fgkaK7 1ce043sto+XbA7wCsuXlYMm46Pjr3b0K6ijEEEcnMa6OIa5IhG6naZZ0B0mS1aC/qL 2ufKmOPdsV2BBhhBlrzCxZjPMf+FDyA8YmhcGALPXXotqpUQEmZcuWAtJiz6ZUdJAy Uh0QoNEw2Z//xRPlNnYNYWhQ9ZlX6/aPt4WMKtsKe5/fejMMQn6EujuyDQtbjSCmqE Lzbad2vaSYyKkCJMUe1hKffhFCSqfhhPys50gVT1hhVV6JWn0OCVD5fngPfWivyCTN jgs2mwU7cXpgQ== Message-ID: Date: Thu, 14 Apr 2022 14:07:30 +0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Cc: usama.anjum@collabora.com, Len Brown , Mark Gross , Collabora Kernel ML , Guenter Roeck , Benson Leung , Dmitry Torokhov , Gwendal Grignou , vbendeb@chromium.org, Andy Shevchenko , Ayman Bagabas , Benjamin Tissoires , =?UTF-8?Q?Bla=c5=be_Hrastnik?= , Darren Hart , Dmitry Torokhov , Greg Kroah-Hartman , Jeremy Soller , Mattias Jacobsson <2pi@mok.nu>, Mauro Carvalho Chehab , Rajat Jain , Srinivas Pandruvada , Platform Driver , Linux Kernel Mailing List , ACPI Devel Maling List , "Rafael J . Wysocki" , Enric Balletbo i Serra Subject: Re: [PATCH RESEND v6] platform: x86: Add ChromeOS ACPI device driver Content-Language: en-US To: Hans de Goede , "Rafael J. Wysocki" References: <708fb1ec-4e57-7a1d-b0a0-a3a10b3cacf3@redhat.com> From: Muhammad Usama Anjum In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 wrote: >>> >>> Hi, >>> >>> On 4/7/22 14:35, Muhammad Usama Anjum wrote: >>>> From: Enric Balletbo i Serra >>>> >>>> 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 >>>> Cc: Dmitry Torokhov >>>> Signed-off-by: Enric Balletbo i Serra >>>> Signed-off-by: Muhammad Usama Anjum >>> >>> >>> 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