[PATCH 1/3] i2c: i2c-mux-gpio: Use devm_kzalloc instead of kzalloc

Jean Delvare khali at linux-fr.org
Sat Sep 22 09:09:05 EDT 2012


On Fri, 21 Sep 2012 17:32:12 +0200, Maxime Ripard wrote:
> Use the devm_kzalloc managed function to stripdown the error and remove
> code.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> ---
>  drivers/i2c/muxes/i2c-mux-gpio.c |   14 +++++---------
>  1 file changed, 5 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/i2c/muxes/i2c-mux-gpio.c b/drivers/i2c/muxes/i2c-mux-gpio.c
> index 68b1f8e..fbc400b 100644
> --- a/drivers/i2c/muxes/i2c-mux-gpio.c
> +++ b/drivers/i2c/muxes/i2c-mux-gpio.c
> @@ -71,7 +71,7 @@ static int __devinit i2c_mux_gpio_probe(struct platform_device *pdev)
>  		return -ENODEV;
>  	}
>  
> -	mux = kzalloc(sizeof(*mux), GFP_KERNEL);
> +	mux = devm_kzalloc(&pdev->dev, sizeof(*mux), GFP_KERNEL);
>  	if (!mux) {
>  		ret = -ENOMEM;
>  		goto alloc_failed;
> @@ -79,11 +79,12 @@ static int __devinit i2c_mux_gpio_probe(struct platform_device *pdev)
>  
>  	mux->parent = parent;
>  	mux->data = *pdata;
> -	mux->adap = kzalloc(sizeof(struct i2c_adapter *) * pdata->n_values,
> -			    GFP_KERNEL);
> +	mux->adap = devm_kzalloc(&pdev->dev,
> +				sizeof(struct i2c_adapter *) * pdata->n_values,
> +				GFP_KERNEL);

Alignment is off by one here.

>  	if (!mux->adap) {
>  		ret = -ENOMEM;
> -		goto alloc_failed2;
> +		goto alloc_failed;
>  	}
>  
>  	if (pdata->idle != I2C_MUX_GPIO_NO_IDLE) {
> @@ -128,9 +129,6 @@ add_adapter_failed:
>  err_request_gpio:
>  	for (; i > 0; i--)
>  		gpio_free(pdata->gpios[i - 1]);
> -	kfree(mux->adap);
> -alloc_failed2:
> -	kfree(mux);
>  alloc_failed:
>  	i2c_put_adapter(parent);
>  
> @@ -150,8 +148,6 @@ static int __devexit i2c_mux_gpio_remove(struct platform_device *pdev)
>  
>  	platform_set_drvdata(pdev, NULL);
>  	i2c_put_adapter(mux->parent);
> -	kfree(mux->adap);
> -	kfree(mux);
>  
>  	return 0;
>  }

Other than this it looks OK.

Acked-by: Jean Delvare <khali at linux-fr.org>

I don't know a thing about DT and ARM so I won't review the following
patches of this series. For this reason I will not pick this one in my
tree either, to avoid inter-tree dependencies.

-- 
Jean Delvare



More information about the linux-arm-kernel mailing list