Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3432812imu; Fri, 18 Jan 2019 10:15:47 -0800 (PST) X-Google-Smtp-Source: ALg8bN6Hv9auF+dK/cUSWrGfdCbLc9u4SBEX+xY2W7NvhtTjnoiz5yszXxJCHPEBfg6q8lcrztwC X-Received: by 2002:a63:7154:: with SMTP id b20mr18662642pgn.342.1547835347873; Fri, 18 Jan 2019 10:15:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547835347; cv=none; d=google.com; s=arc-20160816; b=XPco5+9uokSOfQOgo2Fz79DSA4GNbqdCQT/jzHsWYxfd2bm1GO56NJkz+Lm5H0ajVS WiHQ4sD41HASiHYBgT1tS7FTQfCWKfob8En+dSHEp6saCqbqGFX8MMoObOlMzLH6ju11 SceOrbqFPzwfQItPz2R82QQI63LYLpjbwSiwQ5V9mVWvGdRnvnWdK/khP/00vmkBSioW qEzGvTbnTSQ8/JoaYUcsgdWJJELnRgrSrqSu438mOlFKoH/zL5riLtpuhO4JOvlpkqOZ 6pioDBeJl4DppN1PYdksMWoEvp8Z13McS4ToQIVBboC3uBl3c3V6Xfoo2F/1mITMoEHu I+eQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=50tTcE0fuv+y66xoAmFC9tV2dL8ySToAWd3FTLnwSjE=; b=BF2SmSGCSM5RtPE2Uq1pVQvLltYC2dOF0vBZdFiwmBC/dck/dl5UDj3jc6BhCgfkvZ Kg+ZC3CW5hV//otlz1EJSybgUHYQOx6dZNZoiZ0IFgPsdh/EKmF1i827QhsQyMcM31JB LGNRlZ5atyufm3gcTZX1FhvgKHd3OhxQ+4TCu1LUpY54m9gPLRPVgDWxnAAfIklZ/cKa fVAU+X2IYj6qAlNqScCXidoWmgDB+z/B9PNeJ0mAMGRct8rGpRkrglr0OvYFb8mWfDAq Src3GZUb1UFiII2hZRJUDEe4FY9L84+I0L6DaVPqWB/vXRH8xPhJqgJBGjaHVhBMhkcC OBDQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@baylibre-com.20150623.gappssmtp.com header.s=20150623 header.b=jsgyobrd; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j10si4866681pll.179.2019.01.18.10.15.22; Fri, 18 Jan 2019 10:15:47 -0800 (PST) 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=@baylibre-com.20150623.gappssmtp.com header.s=20150623 header.b=jsgyobrd; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728970AbfARSNv (ORCPT + 99 others); Fri, 18 Jan 2019 13:13:51 -0500 Received: from mail-ot1-f65.google.com ([209.85.210.65]:38308 "EHLO mail-ot1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728818AbfARSNu (ORCPT ); Fri, 18 Jan 2019 13:13:50 -0500 Received: by mail-ot1-f65.google.com with SMTP id e12so15202480otl.5 for ; Fri, 18 Jan 2019 10:13:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=50tTcE0fuv+y66xoAmFC9tV2dL8ySToAWd3FTLnwSjE=; b=jsgyobrdU4BXohSCqb6qabVgjeP7kBbUolKAgqEnHpo9dfp/dIFNummRc+nOkLeEaI qVX6vfpDy4sCjaVSJL7khpk/mbTLzt1K2Pwbm53Mh7/BbETTBgOCbRmCXhVuAnvl5CR6 EOr1CyhpC/Q3GlvbdA9yJkd0214I4nerQZxyU261MwbT8pq1meBs6bhZzRsgQqZPhJIT wAch7R95q4S/BqaMydgCKH81ezesJLgDyGKD7c0k99bwp2c2CqkgVpNEq4P3Ahwqims0 Q2vO+gsdW/v5Tu2F9NaEUKc2BFKTzUnnon6yDqq0loWbdW1ly0VfECDev2bFIK9FCWri +EAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=50tTcE0fuv+y66xoAmFC9tV2dL8ySToAWd3FTLnwSjE=; b=LFxrghvDP3gAvDUstOOyGhrH9V7D1IM4E0m5mUW09Jwpg085Fld/IOa017MwW3z/Ae v3+rnPWaqTNcy5mRPWtQ1XjKeeVuLYE7xNIlInUyqQoP1tRRFgpg5LkEya4Irl3tVK84 khbI0fvloiTftmOlnv4CxWIHZLNRsz218h3s3XOEWlQpifwnl72Wo0o2UxbvpUZOWxvQ NB1e5P31rDmI60CkC1KZXt3lEhol28b94AnPH4ThQsifXJk7ksjjfDjl3OzSJvbONgB8 9e1meyXGXwzajM2f8lLq/M2xvUdnT/1p0En2JxwG8/ES1G2AKu2IuPkGn5hYX8s1Ptd4 7Ccg== X-Gm-Message-State: AJcUukfJItEX/raaMlwlTmzno8EOZLkmVtTBYpv0jyAUsq0ehNNCnQcE U/0mj5H2OI7En9fmwwEHxP/n06T6eTcYzSZG2ti46Q== X-Received: by 2002:a9d:4595:: with SMTP id x21mr11945644ote.234.1547835230003; Fri, 18 Jan 2019 10:13:50 -0800 (PST) MIME-Version: 1.0 References: <20190118134244.22253-1-brgl@bgdev.pl> <20190118134244.22253-9-brgl@bgdev.pl> <20190118180148.GD6260@sirena.org.uk> In-Reply-To: <20190118180148.GD6260@sirena.org.uk> From: Bartosz Golaszewski Date: Fri, 18 Jan 2019 19:13:38 +0100 Message-ID: Subject: Re: [PATCH 08/13] regulator: max77650: add regulator support To: Mark Brown Cc: Bartosz Golaszewski , Rob Herring , Mark Rutland , Linus Walleij , Dmitry Torokhov , Jacek Anaszewski , Pavel Machek , Lee Jones , Sebastian Reichel , Liam Girdwood , Greg Kroah-Hartman , LKML , linux-gpio , linux-devicetree , linux-input@vger.kernel.org, linux-leds@vger.kernel.org, linux-pm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org pt., 18 sty 2019 o 19:01 Mark Brown napisa=C5=82(a): > > On Fri, Jan 18, 2019 at 02:42:39PM +0100, Bartosz Golaszewski wrote: > > > Add regulator support for max77650. We support all four variants of thi= s > > PMIC including non-linear voltage table for max77651 SBB1 rail. > > Looks good, the ramping stuff might be a candidate for core (TBH I was > sure we'd got that implemented already but we don't seem to) but that > can be done later and the more complex one with non-linear steps does > feel like it might have to stay in the driver anyway. > > A couple of small nits: > > > +++ b/drivers/regulator/max77650-regulator.c > > @@ -0,0 +1,537 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright (C) 2018 BayLibre SAS > > + * Author: Bartosz Golaszewski > > Please make the entire header C++ style so it looks more intentional. > Seems like there are more files in the kernel source using the mixed comment style for the SPDX identifier and I also prefer it over C++ only. Would you mind if it stayed that way? > > + for_each_child_of_node(dev->of_node, child) { > > + if (!of_node_name_eq(child, rdesc->desc.name)) > > + continue; > > + > > + init_data =3D of_get_regulator_init_data(dev, chi= ld, > > + &rdesc->de= sc); > > + if (!init_data) > > + return -ENOMEM; > > + > > + config.of_node =3D child; > > + config.init_data =3D init_data; > > + } > > You don't need to do this, the core will do it for you (it will actually > still do it even with the above, it'll only fall back to using > config->init_data if it's own lookup fails). I added this loop specifically because the core would not pick up the init data from DT. What did I miss (some specific variable to assign)? I just noticed some other drivers do the same and thought it's the right thing to do. Thanks, Bart