[PATCH 1/2] gpio: tps68470: Allow building as module

[PATCH 1/2] gpio: tps68470: Allow building as module

[Hans de Goede]

The gpio-tps68470 driver binds to a tps68470-gpio platform-device which
itself gets instantiated by a special MFD driver from
drivers/platform/x86/intel/int3472/tps68470.c

This MFD driver itself can be build as a module, so it makes no sense to
force the gpio-tps68470 driver to always be builtin.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/gpio/Kconfig         | 6 +-----
 drivers/gpio/gpio-tps68470.c | 6 +++++-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 60d9374c72c0..3ac5860e0aeb 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -1393,7 +1393,7 @@ config GPIO_TPS65912
 	  This driver supports TPS65912 GPIO chip.
 
 config GPIO_TPS68470
-	bool "TPS68470 GPIO"
+	tristate "TPS68470 GPIO"
 	depends on INTEL_SKL_INT3472
 	help
 	  Select this option to enable GPIO driver for the TPS68470
@@ -1403,10 +1403,6 @@ config GPIO_TPS68470
 	  input or output as appropriate, the sensor related GPIOs
 	  are "output only" GPIOs.
 
-	  This driver config is bool, as the GPIO functionality
-	  of the TPS68470 must be available before dependent
-	  drivers are loaded.
-
 config GPIO_TQMX86
 	tristate "TQ-Systems QTMX86 GPIO"
 	depends on MFD_TQMX86 || COMPILE_TEST
diff --git a/drivers/gpio/gpio-tps68470.c b/drivers/gpio/gpio-tps68470.c
index 423b7bc30ae8..ce12c5a54fd4 100644
--- a/drivers/gpio/gpio-tps68470.c
+++ b/drivers/gpio/gpio-tps68470.c
@@ -155,4 +155,8 @@ static struct platform_driver tps68470_gpio_driver = {
 	.probe = tps68470_gpio_probe,
 };
 
-builtin_platform_driver(tps68470_gpio_driver)
+module_platform_driver(tps68470_gpio_driver);
+
+MODULE_ALIAS("platform:tps68470-gpio");
+MODULE_DESCRIPTION("GPIO driver for TPS68470 PMIC");
+MODULE_LICENSE("GPL v2");
-- 
2.33.1

[PATCH 2/2] gpio: crystalcove: Set IRQ domain bus token to DOMAIN_BUS_WIRED

[Hans de Goede]

For the CRC PMIC we end up with multiple irq-domains with the same fwnode.
One for the irqchip which demultiplexes the actual PMIC interrupt into
interrupts for the various cells (known as the level 1 interrupts);

And 2 more for the irqchips which are part of the crystal_cove_gpio
and crystal_cove_charger cells.

This leads to the following error being printed when
CONFIG_GENERIC_IRQ_DEBUGFS is enabled:
 debugfs: File '\_SB.I2C7.PMIC' in directory 'domains' already present!

Set the bus token of the main IRQ domain to DOMAIN_BUS_WIRED to avoid
this error, this also allows irq_find_matching_fwspec() to find the
right domain if necessary.

Note all 3 domain registering drivers need to set the IRQ domain bus token.
This is necessary because the IRQ domain code defaults to creating
the debugfs dir with just the fwnode name and then renames it when
the bus token is set. So each one starts with the same default name and
all 3 must be given a different name to avoid problems when one of the
other drivers loads and starts with the same default name.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/gpio/gpio-crystalcove.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-crystalcove.c b/drivers/gpio/gpio-crystalcove.c
index 5a909f3c79e8..b55c74a5e064 100644
--- a/drivers/gpio/gpio-crystalcove.c
+++ b/drivers/gpio/gpio-crystalcove.c
@@ -370,7 +370,14 @@ static int crystalcove_gpio_probe(struct platform_device *pdev)
 		return retval;
 	}
 
-	return devm_gpiochip_add_data(&pdev->dev, &cg->chip, cg);
+	retval = devm_gpiochip_add_data(&pdev->dev, &cg->chip, cg);
+	if (retval)
+		return retval;
+
+	/* Distuingish IRQ domain from others sharing (MFD) the same fwnode */
+	irq_domain_update_bus_token(cg->chip.irq.domain, DOMAIN_BUS_WIRED);
+
+	return 0;
 }
 
 static struct platform_driver crystalcove_gpio_driver = {
-- 
2.33.1

Re: [PATCH 1/2] gpio: tps68470: Allow building as module

[Andy Shevchenko]

On Sat, Dec 25, 2021 at 2:00 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> The gpio-tps68470 driver binds to a tps68470-gpio platform-device which
> itself gets instantiated by a special MFD driver from
> drivers/platform/x86/intel/int3472/tps68470.c
>
> This MFD driver itself can be build as a module, so it makes no sense to

built

> force the gpio-tps68470 driver to always be builtin.

built-in

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
(see one minor comment below)

> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
>  drivers/gpio/Kconfig         | 6 +-----
>  drivers/gpio/gpio-tps68470.c | 6 +++++-
>  2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 60d9374c72c0..3ac5860e0aeb 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -1393,7 +1393,7 @@ config GPIO_TPS65912
>           This driver supports TPS65912 GPIO chip.
>
>  config GPIO_TPS68470
> -       bool "TPS68470 GPIO"
> +       tristate "TPS68470 GPIO"
>         depends on INTEL_SKL_INT3472
>         help
>           Select this option to enable GPIO driver for the TPS68470
> @@ -1403,10 +1403,6 @@ config GPIO_TPS68470
>           input or output as appropriate, the sensor related GPIOs
>           are "output only" GPIOs.
>
> -         This driver config is bool, as the GPIO functionality
> -         of the TPS68470 must be available before dependent
> -         drivers are loaded.
> -
>  config GPIO_TQMX86
>         tristate "TQ-Systems QTMX86 GPIO"
>         depends on MFD_TQMX86 || COMPILE_TEST
> diff --git a/drivers/gpio/gpio-tps68470.c b/drivers/gpio/gpio-tps68470.c
> index 423b7bc30ae8..ce12c5a54fd4 100644
> --- a/drivers/gpio/gpio-tps68470.c
> +++ b/drivers/gpio/gpio-tps68470.c
> @@ -155,4 +155,8 @@ static struct platform_driver tps68470_gpio_driver = {
>         .probe = tps68470_gpio_probe,
>  };

>

You may remove this blank line.

> -builtin_platform_driver(tps68470_gpio_driver)
> +module_platform_driver(tps68470_gpio_driver);
> +
> +MODULE_ALIAS("platform:tps68470-gpio");
> +MODULE_DESCRIPTION("GPIO driver for TPS68470 PMIC");
> +MODULE_LICENSE("GPL v2");
> --
> 2.33.1
>


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 2/2] gpio: crystalcove: Set IRQ domain bus token to DOMAIN_BUS_WIRED

[Andy Shevchenko]

On Sat, Dec 25, 2021 at 2:00 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> For the CRC PMIC we end up with multiple irq-domains with the same fwnode.
> One for the irqchip which demultiplexes the actual PMIC interrupt into
> interrupts for the various cells (known as the level 1 interrupts);
>
> And 2 more for the irqchips which are part of the crystal_cove_gpio
> and crystal_cove_charger cells.
>
> This leads to the following error being printed when
> CONFIG_GENERIC_IRQ_DEBUGFS is enabled:
>  debugfs: File '\_SB.I2C7.PMIC' in directory 'domains' already present!
>
> Set the bus token of the main IRQ domain to DOMAIN_BUS_WIRED to avoid
> this error, this also allows irq_find_matching_fwspec() to find the
> right domain if necessary.
>
> Note all 3 domain registering drivers need to set the IRQ domain bus token.
> This is necessary because the IRQ domain code defaults to creating
> the debugfs dir with just the fwnode name and then renames it when
> the bus token is set. So each one starts with the same default name and
> all 3 must be given a different name to avoid problems when one of the
> other drivers loads and starts with the same default name.

Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>

> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
>  drivers/gpio/gpio-crystalcove.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-crystalcove.c b/drivers/gpio/gpio-crystalcove.c
> index 5a909f3c79e8..b55c74a5e064 100644
> --- a/drivers/gpio/gpio-crystalcove.c
> +++ b/drivers/gpio/gpio-crystalcove.c
> @@ -370,7 +370,14 @@ static int crystalcove_gpio_probe(struct platform_device *pdev)
>                 return retval;
>         }
>
> -       return devm_gpiochip_add_data(&pdev->dev, &cg->chip, cg);
> +       retval = devm_gpiochip_add_data(&pdev->dev, &cg->chip, cg);
> +       if (retval)
> +               return retval;
> +
> +       /* Distuingish IRQ domain from others sharing (MFD) the same fwnode */
> +       irq_domain_update_bus_token(cg->chip.irq.domain, DOMAIN_BUS_WIRED);
> +
> +       return 0;
>  }
>
>  static struct platform_driver crystalcove_gpio_driver = {
> --
> 2.33.1
>


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 1/2] gpio: tps68470: Allow building as module

[Andy Shevchenko]

On Sat, Dec 25, 2021 at 04:41:58PM +0200, Andy Shevchenko wrote:
> On Sat, Dec 25, 2021 at 2:00 PM Hans de Goede <hdegoede@redhat.com> wrote:
> >
> > The gpio-tps68470 driver binds to a tps68470-gpio platform-device which
> > itself gets instantiated by a special MFD driver from
> > drivers/platform/x86/intel/int3472/tps68470.c
> >
> > This MFD driver itself can be build as a module, so it makes no sense to
> 
> built
> 
> > force the gpio-tps68470 driver to always be builtin.
> 
> built-in
> 
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> (see one minor comment below)

I don't see the next version, in any case it's too far from the beginning of
the v5.16 cycle and I gave my tags so Bart may (or may not :-) apply them. If
it's okay to be v5.18 material, I'll take a new version sent after v5.17-rc1.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 1/2] gpio: tps68470: Allow building as module

[Hans de Goede]

Hi,

On 1/4/22 15:08, Andy Shevchenko wrote:
> On Sat, Dec 25, 2021 at 04:41:58PM +0200, Andy Shevchenko wrote:
>> On Sat, Dec 25, 2021 at 2:00 PM Hans de Goede <hdegoede@redhat.com> wrote:
>>>
>>> The gpio-tps68470 driver binds to a tps68470-gpio platform-device which
>>> itself gets instantiated by a special MFD driver from
>>> drivers/platform/x86/intel/int3472/tps68470.c
>>>
>>> This MFD driver itself can be build as a module, so it makes no sense to
>>
>> built
>>
>>> force the gpio-tps68470 driver to always be builtin.
>>
>> built-in
>>
>> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
>> (see one minor comment below)
> 
> I don't see the next version, in any case it's too far from the beginning of
> the v5.16 cycle and I gave my tags so Bart may (or may not :-) apply them. If
> it's okay to be v5.18 material, I'll take a new version sent after v5.17-rc1.

It is fine for this to go into v5.18, thank you for your review. I'll send
a new version addressing your comments.

Regards,

Hans