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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <YnzfzRhGwtO9RtNi@kroah.com>
Date:   Thu, 12 May 2022 12:22:05 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:     Muhammad Usama Anjum <usama.anjum@...labora.com>,
        "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>,
        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

On Thu, May 12, 2022 at 03:10:20AM -0700, Dmitry Torokhov wrote:
> 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?

I really really do not like dynamically created groups as it's more
complex and fragile.  This is much simpler code overall.

thanks,

greg k-h