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
