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
