lkml.org 
[lkml]   [2022]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2022-05-12 12:22    [W:0.163 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site