public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: sean.wang@mediatek.com (Sean Wang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/5] nvmem: mtk-efuse: use stack for nvmem_config instead of malloc'ing it
Date: Thu, 21 Sep 2017 00:32:39 +0800	[thread overview]
Message-ID: <1505925159.17049.12.camel@mtkswgap22> (raw)
In-Reply-To: <1505134864-11975-3-git-send-email-yamada.masahiro@socionext.com>

Hi, Masahiro

For maintainability, I felt it's better if we use the same way to
register nvmem as that most drivers does under nvmem usually using
static structure. Otherwise, they should also be changed to use the
one-time data in stack to avoid extra bytes to keep them.

	Sean


On Mon, 2017-09-11 at 22:01 +0900, Masahiro Yamada wrote:
> nvmem_register() copies all the members of nvmem_config to
> nvmem_device.  So, nvmem_config is one-time use data during
> probing.  There is no point to keep it until the driver detach.
> Using stack should be no problem because nvmem_config is pretty
> small.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
> 
>  drivers/nvmem/mtk-efuse.c | 24 ++++++++++--------------
>  1 file changed, 10 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/nvmem/mtk-efuse.c b/drivers/nvmem/mtk-efuse.c
> index 32fd572..fa7a0f6 100644
> --- a/drivers/nvmem/mtk-efuse.c
> +++ b/drivers/nvmem/mtk-efuse.c
> @@ -49,7 +49,7 @@ static int mtk_efuse_probe(struct platform_device *pdev)
>  	struct device *dev = &pdev->dev;
>  	struct resource *res;
>  	struct nvmem_device *nvmem;
> -	struct nvmem_config *econfig;
> +	struct nvmem_config econfig = {};
>  	void __iomem *base;
>  
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> @@ -57,19 +57,15 @@ static int mtk_efuse_probe(struct platform_device *pdev)
>  	if (IS_ERR(base))
>  		return PTR_ERR(base);
>  
> -	econfig = devm_kzalloc(dev, sizeof(*econfig), GFP_KERNEL);
> -	if (!econfig)
> -		return -ENOMEM;
> -
> -	econfig->stride = 4;
> -	econfig->word_size = 4;
> -	econfig->reg_read = mtk_reg_read;
> -	econfig->reg_write = mtk_reg_write;
> -	econfig->size = resource_size(res);
> -	econfig->priv = base;
> -	econfig->dev = dev;
> -	econfig->owner = THIS_MODULE;
> -	nvmem = nvmem_register(econfig);
> +	econfig.stride = 4;
> +	econfig.word_size = 4;
> +	econfig.reg_read = mtk_reg_read;
> +	econfig.reg_write = mtk_reg_write;
> +	econfig.size = resource_size(res);
> +	econfig.priv = base;
> +	econfig.dev = dev;
> +	econfig.owner = THIS_MODULE;
> +	nvmem = nvmem_register(&econfig);
>  	if (IS_ERR(nvmem))
>  		return PTR_ERR(nvmem);
>  

  reply	other threads:[~2017-09-20 16:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-11 13:00 [PATCH 0/5] nvmem: some cleanups and sparse warning fixes Masahiro Yamada
2017-09-11 13:01 ` [PATCH 2/5] nvmem: mtk-efuse: use stack for nvmem_config instead of malloc'ing it Masahiro Yamada
2017-09-20 16:32   ` Sean Wang [this message]
2017-09-21  2:09     ` Masahiro Yamada
2017-09-22  3:59       ` Sean Wang
2017-09-11 13:01 ` [PATCH 3/5] nvmem: mtk-efuse: fix different address space warnings of sparse Masahiro Yamada
2017-09-20 16:19   ` Sean Wang
2017-09-11 13:01 ` [PATCH 5/5] nvmem: set nvmem->owner to nvmem->dev->driver->owner if unset Masahiro Yamada
2017-09-20 10:02 ` [PATCH 0/5] nvmem: some cleanups and sparse warning fixes Masahiro Yamada

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1505925159.17049.12.camel@mtkswgap22 \
    --to=sean.wang@mediatek.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox