Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp591520imm; Tue, 5 Jun 2018 00:54:09 -0700 (PDT) X-Google-Smtp-Source: ADUXVKL4r36zkEV3pxzgji83afYNJrKfzESyaKkNFzognp/mVg/6o96FU3N93kqavyTIAKyxLQdD X-Received: by 2002:a63:65c2:: with SMTP id z185-v6mr18330013pgb.163.1528185249543; Tue, 05 Jun 2018 00:54:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528185249; cv=none; d=google.com; s=arc-20160816; b=neBce6hgsA9kJvJk79x5kXAsbpSCaK+YmO8TVApvHD3Z7KIGqBxjl7AcsyTrCobo3V XNRdHxMzR3pKndTrCL6IjymiJcPHjPKotYRwtSWWWuAnktaB0Y/hVpXv1+VZRynvawlC Aaxp2fEfGQfDDGf4z7mfTmvfV+IS8ZXFub7dT8OP1AJ1X9liOLRD/knUnxEYa8Yeaprz oIcN1KH8retmuoxGu8C6NxDEsy/bmNfvvmVMYKF5/T2Xsa/WVgiiZ6XyoNp6zmw2BxSp 8Pswxsa6RqjtSJvEsnv4fvhknjWOrSAQe4KHA6tgNWkMYv7XQK9MLMlImo7Y64Bbt26h PeAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=lUiVWPK91N/EyjRb402wAIhKuOAEDGlFpsx04VE3GJc=; b=XvpONPsLP5XV6j7IzcNuUFCuc+g8RHEw/8Vll4O/Dtpr9bWeu683Iz+dkxKWD2oC0U XlJ0pk7HyxTuATLv8RoklipwxZ5U0KrVyKmsCpzMx8gHWdaDQ2V1ggBkcuIpugCdaXkm JrVkf57bNw8uTmCJTLh9sYrPAe2VwjgLWCJhzoEG3MlWRhiD5mmBxmdmsKI7udVi6TAu GHibXD+AjpKMMoDcDWazLmtJ/v6sZ7o9t/ToKiiHzt6cH0+58tdWRO59ljBm+B0bSGAi vGXwSD2t/dzSVPZt78emoe3pbv7d30nQh9/RvYO7/oT8q3Qp5ZwWoHAAzNrH3jUoE1WM KprQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=PxTwgSL6; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 68-v6si47778358pfq.172.2018.06.05.00.53.54; Tue, 05 Jun 2018 00:54:09 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=PxTwgSL6; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751816AbeFEHx0 (ORCPT + 99 others); Tue, 5 Jun 2018 03:53:26 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:33043 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751563AbeFEHxY (ORCPT ); Tue, 5 Jun 2018 03:53:24 -0400 Received: by mail-wm0-f66.google.com with SMTP id z6-v6so16676660wma.0 for ; Tue, 05 Jun 2018 00:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=lUiVWPK91N/EyjRb402wAIhKuOAEDGlFpsx04VE3GJc=; b=PxTwgSL61Y5O2Vypd1RzM0ADpkevd/wsAV8/at/cp319pFGIbgs41I6g7WNIh9Bv5K CWtTI/t/ZXmhkjLHV7qT2SXkYIbWM5EYCkKSgJokZ1jRrXUuGyQPdxuD+tzjPQ/Ol71K Wrq2a0C5+H2tskgpqcTTb6MRtF1AS3ZXCh69E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=lUiVWPK91N/EyjRb402wAIhKuOAEDGlFpsx04VE3GJc=; b=lWjkTBe/wbxUfQgmeLgrDa2r3O7n0ijiPmuHIMMEdJWU1r+T8zaZGx8wrOA7r8isn3 uR/qbDSJZb5FbMXQeBJ7Q0YgA8VUQWdb+uBf/QwlyJKNEM9m1QjpBUgl5kAyqDXhQ0PZ 65kqvvMAqhLEGr2AiBTVkwbRmzNKOOErbVIaTLxrGd4jg+9siIgX7Y+vzRYtie3W6V2l 3VVkwsCl5ufBRP8GXEXvZWYmolpBVW7EIpAnGdtOqibi7FWTgsf7wh+Z76K9GgK2rP8J +I9Tl+4BkBWmGPVa+Ma9snS7eyDXuJuLWGdBgGqhVSv3ob1PWgTLWx4bMwLH9eCirHI4 PRSA== X-Gm-Message-State: APt69E0mi+vF2K+SaE2rtrm4VI4UUkkAREi+CuTb362aVkBHKPEIWLzo PPf1X51+ta1pxX1LxReh/0NeYQ== X-Received: by 2002:a1c:8012:: with SMTP id b18-v6mr10489276wmd.13.1528185203480; Tue, 05 Jun 2018 00:53:23 -0700 (PDT) Received: from dell ([2.31.167.232]) by smtp.gmail.com with ESMTPSA id 69-v6sm991595wmi.29.2018.06.05.00.53.22 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 05 Jun 2018 00:53:22 -0700 (PDT) Date: Tue, 5 Jun 2018 08:53:21 +0100 From: Lee Jones To: Marek Vasut Cc: linux-kernel@vger.kernel.org, Marek Vasut , Geert Uytterhoeven , Mark Brown , Steve Twiss , Wolfram Sang , linux-renesas-soc@vger.kernel.org Subject: Re: [PATCH v3 08/10] mfd: da9063: Register RTC only on DA9063L Message-ID: <20180605075321.GM21163@dell> References: <20180602101155.26375-1-marek.vasut+renesas@gmail.com> <20180602101155.26375-8-marek.vasut+renesas@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180602101155.26375-8-marek.vasut+renesas@gmail.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 02 Jun 2018, Marek Vasut wrote: > The DA9063L does not contain RTC block, unlike the full DA9063. > Split the RTC block into separate mfd cell and register it only > on DA9063. > > Signed-off-by: Marek Vasut > Cc: Geert Uytterhoeven > Cc: Lee Jones > Cc: Mark Brown > Cc: Steve Twiss > Cc: Wolfram Sang > Cc: linux-renesas-soc@vger.kernel.org > --- > V2: No change > V3: Rework of mfd: da9063: Disallow RTC on DA9063L > --- > drivers/mfd/da9063-core.c | 30 +++++++++++++++++++++++------- > 1 file changed, 23 insertions(+), 7 deletions(-) > > diff --git a/drivers/mfd/da9063-core.c b/drivers/mfd/da9063-core.c > index eebca3442cf3..b05910c797af 100644 > --- a/drivers/mfd/da9063-core.c > +++ b/drivers/mfd/da9063-core.c > @@ -76,7 +76,7 @@ static struct resource da9063_hwmon_resources[] = { > }; > > > -static const struct mfd_cell da9063_devs[] = { > +static const struct mfd_cell da9063_common_devs[] = { > { > .name = DA9063_DRVNAME_REGULATORS, Appreciate that these are historical, but these device name defines make me shudder. They only serve to act as an obfuscation layer when debugging at platform level. Please consider getting rid of them. > .num_resources = ARRAY_SIZE(da9063_regulators_resources), > @@ -100,15 +100,19 @@ static const struct mfd_cell da9063_devs[] = { > .resources = da9063_onkey_resources, > .of_compatible = "dlg,da9063-onkey", > }, > + { > + .name = DA9063_DRVNAME_VIBRATION, > + }, Place this on a single line please. { .name = DA9063_DRVNAME_VIBRATION }, > +}; > + > +/* Only present on DA9063 , not on DA9063L */ > +static const struct mfd_cell da9063_devs[] = { > { > .name = DA9063_DRVNAME_RTC, > .num_resources = ARRAY_SIZE(da9063_rtc_resources), > .resources = da9063_rtc_resources, > .of_compatible = "dlg,da9063-rtc", > }, > - { > - .name = DA9063_DRVNAME_VIBRATION, > - }, > }; > > static int da9063_clear_fault_log(struct da9063 *da9063) > @@ -225,16 +229,28 @@ int da9063_device_init(struct da9063 *da9063, unsigned int irq) > > da9063->irq_base = regmap_irq_chip_get_base(da9063->regmap_irq); > > - ret = mfd_add_devices(da9063->dev, -1, da9063_devs, > - ARRAY_SIZE(da9063_devs), NULL, da9063->irq_base, > - NULL); > + ret = mfd_add_devices(da9063->dev, -1, da9063_common_devs, Please consider updating the -1's in this file with the appropriate define in a separate patch. > + ARRAY_SIZE(da9063_common_devs), > + NULL, da9063->irq_base, NULL); > if (ret) { > dev_err(da9063->dev, "Cannot add MFD cells\n"); > goto err_irq_exit; > } > > + if (da9063->type == PMIC_TYPE_DA9063) { > + ret = mfd_add_devices(da9063->dev, -1, da9063_devs, > + ARRAY_SIZE(da9063_devs), > + NULL, da9063->irq_base, NULL); > + if (ret) { > + dev_err(da9063->dev, "Cannot add MFD cells\n"); Better to be more general here. "Failed to add child devices" or such. Users don't tend to care about MFD cells. > + goto err_mfd_cleanup; > + } > + } > + > return ret; > > +err_mfd_cleanup: > + mfd_remove_devices(da9063->dev); Any reason why you can't use devm_*? > err_irq_exit: > da9063_irq_exit(da9063); > return ret; -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog