[1/2] drivers: provide devm_platform_ioremap_resource()

From: Bartosz Golaszewski <bgolaszewski@baylibre.com>

There are currently 1200+ instances of using platform_get_resource()
and devm_ioremap_resource() together in the kernel tree.

This patch wraps these two calls in a single helper. Thanks to that
we don't have to declare a local variable for struct resource * and can
omit the redundant argument for resource type. We also have one
function call less.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
 drivers/base/platform.c         | 18 ++++++++++++++++++
 include/linux/platform_device.h |  3 +++
 2 files changed, 21 insertions(+)

On Fri, Feb 15, 2019 at 4:25 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:

> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> There are currently 1200+ instances of using platform_get_resource()
> and devm_ioremap_resource() together in the kernel tree.
>
> This patch wraps these two calls in a single helper. Thanks to that
> we don't have to declare a local variable for struct resource * and can
> omit the redundant argument for resource type. We also have one
> function call less.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

This makes a lot of sense. I think Andy can confirm the value, he
knows a lot about good helpers.

I'd need Greg's ACK on this before merging through GPIO.

Can we make a script or coccinelle thing to fix them all when this
is applied?

Yours,
Linus Walleij

On Fri, Feb 15, 2019 at 04:25:06PM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> 
> There are currently 1200+ instances of using platform_get_resource()
> and devm_ioremap_resource() together in the kernel tree.
> 
> This patch wraps these two calls in a single helper. Thanks to that
> we don't have to declare a local variable for struct resource * and can
> omit the redundant argument for resource type. We also have one
> function call less.
> 
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
>  drivers/base/platform.c         | 18 ++++++++++++++++++
>  include/linux/platform_device.h |  3 +++
>  2 files changed, 21 insertions(+)
> 
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 1c958eb33ef4..14400a63cc81 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -79,6 +79,24 @@ struct resource *platform_get_resource(struct platform_device *dev,
>  }
>  EXPORT_SYMBOL_GPL(platform_get_resource);
>  
> +/**
> + * devm_platform_ioremap_resource - call devm_ioremap_resource() for a platform
> + *				    device
> + *
> + * @pdev: platform device to use both for memory resource lookup as well as
> + *        resource managemend
> + * @index: resource index
> + */
> +void __iomem *devm_platform_ioremap_resource(struct platform_device *pdev,
> +					     unsigned int index)
> +{
> +	struct resource *res;
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, index);
> +	return devm_ioremap_resource(&pdev->dev, res);
> +}
> +EXPORT_SYMBOL(devm_platform_ioremap_resource);

functions in drivers/base/* should be EXPORT_SYMBOL_GPL() please.

thanks,

greg k-h

śr., 20 lut 2019 o 10:57 Linus Walleij <linus.walleij@linaro.org> napisał(a):
>
> On Fri, Feb 15, 2019 at 4:25 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> >
> > There are currently 1200+ instances of using platform_get_resource()
> > and devm_ioremap_resource() together in the kernel tree.
> >
> > This patch wraps these two calls in a single helper. Thanks to that
> > we don't have to declare a local variable for struct resource * and can
> > omit the redundant argument for resource type. We also have one
> > function call less.
> >
> > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> This makes a lot of sense. I think Andy can confirm the value, he
> knows a lot about good helpers.
>
> I'd need Greg's ACK on this before merging through GPIO.
>
> Can we make a script or coccinelle thing to fix them all when this
> is applied?
>

Yes, it's on my list (and also a chance to learn first hand how to
work with coccinelle), but we first need this function upstream. I'll
resend a v2 with the EXPORT_SYMBOL fixed.

Bart