linux-kernel - Re: [PATCH v12] platform/chrome: 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]

Message-ID: <YnzdDMPR3qZ1waJW@google.com>
Date:   Thu, 12 May 2022 03:10:20 -0700
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Muhammad Usama Anjum <usama.anjum@...labora.com>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>,
        Hans de Goede <hdegoede@...hat.com>,
        Mark Gross <markgross@...nel.org>,
        Benson Leung <bleung@...omium.org>,
        Enric Balletbo i Serra <eballetbo@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Collabora Kernel ML <kernel@...labora.com>,
        groeck@...omium.org, dtor@...omium.org, gwendal@...omium.org,
        vbendeb@...omium.org, 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>,
        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-x86@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-acpi@...r.kernel.org,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
        chrome-platform@...ts.linux.dev
Subject: Re: [PATCH v12] platform/chrome: Add ChromeOS ACPI device driver

Hi Muhammad,

On Thu, May 12, 2022 at 10:34:29AM +0500, Muhammad Usama Anjum wrote:
> +static int chromeos_acpi_device_probe(struct platform_device *pdev)
> +{
> +	chromeos_acpi_gpio_groups = get_gpio_pkg_num(&pdev->dev);
> +
> +	/*
> +	 * If the platform has more GPIO attribute groups than the number of
> +	 * groups this driver supports, give out a warning message.
> +	 */
> +	if (chromeos_acpi_gpio_groups > ARRAY_SIZE(chromeos_acpi_all_groups) - 2)
> +		dev_warn(&pdev->dev, "Only %zu GPIO attr groups supported by the driver out of total %u.\n",
> +			 ARRAY_SIZE(chromeos_acpi_all_groups) - 2, chromeos_acpi_gpio_groups);

I know that we can bikeshed this until dawn of time, but we are dealing
here with data coming from the system firmware and a singleton device,
so it should be all available pretty early in boot sequence. I
understand we want to solve the "race" even though it is purely
theoretical, but we should be able to figure out what gpios are
supported and construct the groups array(s) before registering the
platform driver. Or do we see that runtime costs of constricting groups
dynamically outweigh space wasted by unused groups?

Thanks.

-- 
Dmitry