On Wed, 31 Aug 2016, Charles Keepax wrote:
> There are some cases in arizona_dev_init, such as where we don't
> recognise the chip ID, in which we head to the error path without
> setting a sensible error code in ret. This would lead to the chip
> silently failing probe, as it would still return 0. Fix this up by
> adding appropriate sets of the return value.
>
> Whilst adding these update the existing paths that do return an error
> when the chip is not recognised to use ENODEV, which seems like a better
> fit.
>
> Signed-off-by: Charles Keepax <ckee...@opensource.wolfsonmicro.com>
> ---
>
> Changes since v1:
> - Update return codes to use ENODEV rather than EINVAL.
>
> Thanks,
> Charles
>
> drivers/mfd/arizona-core.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
Applied, thanks.
> diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
> index e4f97b3..cdbb8a2 100644
> --- a/drivers/mfd/arizona-core.c
> +++ b/drivers/mfd/arizona-core.c
> @@ -1035,7 +1035,7 @@ int arizona_dev_init(struct arizona *arizona)
> default:
> dev_err(arizona->dev, "Unknown device type %d\n",
> arizona->type);
> - return -EINVAL;
> + return -ENODEV;
> }
>
> /* Mark DCVDD as external, LDO1 driver will clear if internal */
> @@ -1121,6 +1121,7 @@ int arizona_dev_init(struct arizona *arizona)
> break;
> default:
> dev_err(arizona->dev, "Unknown device ID: %x\n", reg);
> + ret = -ENODEV;
> goto err_reset;
> }
>
> @@ -1280,12 +1281,14 @@ int arizona_dev_init(struct arizona *arizona)
> break;
> default:
> dev_err(arizona->dev, "Unknown device ID %x\n", reg);
> + ret = -ENODEV;
> goto err_reset;
> }
>
> if (!subdevs) {
> dev_err(arizona->dev,
> "No kernel support for device ID %x\n", reg);
> + ret = -ENODEV;
> goto err_reset;
> }
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
