Received: by 2002:ac0:aa62:0:0:0:0:0 with SMTP id w31-v6csp564448ima; Wed, 24 Oct 2018 05:57:18 -0700 (PDT) X-Google-Smtp-Source: AJdET5fKLBPxsnPWmsHD/1qUKoav5Ks7Z4AwGFx0/z5BP1KQmGG1Hh2hd6q4fTijpRme0m8P/RP1 X-Received: by 2002:a17:902:e193:: with SMTP id cd19-v6mr2450809plb.262.1540385837977; Wed, 24 Oct 2018 05:57:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540385837; cv=none; d=google.com; s=arc-20160816; b=thIL57Sla7Rifjag7mEMsN0N5ZCcEKymFq9/MWpNPQZ0FTok6TTghqNqT1LebsJMyM +YtOXx4ZQY/hlyfcEndRHkqiXewQdPNYUJIW8wx4Eu6dhe5/QAdOifClFbp2Fh85IF5s HdBHdk5awKBq0z8d/Ug/vwsh+IMBpj8e32SXl7tnP2cLSsp0/EYSCK6l/phoHw0++lmT 8p2t2Ly4VDIob9/nInCNYUkptc7xJMgOvekfvk7TBxP3AeTKFHaV2EN7Pf8kGYv1kemH 9vChW1eCEPJoLpzGQOJ1zGKLVCtqymTtuZ2wgYKBLDOPi831MsKlnYSRyH1se0Wvc7+K JQkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :content-id:user-agent:content-language:accept-language:in-reply-to :references:message-id:date:thread-index:thread-topic:subject:cc:to :from; bh=g/yRYosuhLCxNiJ4uzNxfKRDqiw9L9F5bVKQqFXHjyY=; b=S2aFsMKOHIyACqT8/TGXGYqF6ZivmwSN7KLM4BwpqVPwfnHZpyJdn88ltH/lPxlAQg l41MECLT2u87VQBPxH8VwFpWTpC67oq5JRQUNfSIRZXwY2Y7b+1xFQ4TXHPT2+tWebFM zk9/IUuNepKgLr1TxgJa2fdSEmuyD+VRx/9dOTojG2vuW9sXQ+gF7HVt4i9eVfksQhTO O77DPOAcz/xOoJO/AElTGXVBU+u5H7znKelKP2tHqCATrqSgvO25QBr8Fl91NfyLL1Za qBLZiQC2jdmDkG0Ma1kKCfiU8pGgmpyVFcggIh1NocC7eI9NtxgSu8Si66RWC+IDt27+ nMyQ== ARC-Authentication-Results: i=1; mx.google.com; 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 a16-v6si4422081pgw.187.2018.10.24.05.57.02; Wed, 24 Oct 2018 05:57:17 -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; 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 S1727546AbeJXVXP convert rfc822-to-8bit (ORCPT + 99 others); Wed, 24 Oct 2018 17:23:15 -0400 Received: from mx08-00178001.pphosted.com ([91.207.212.93]:44713 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727177AbeJXVXP (ORCPT ); Wed, 24 Oct 2018 17:23:15 -0400 Received: from pps.filterd (m0046661.ppops.net [127.0.0.1]) by mx08-.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id w9OCmovq030620; Wed, 24 Oct 2018 14:54:48 +0200 Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx08-00178001.pphosted.com with ESMTP id 2nan9y23q4-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Oct 2018 14:54:48 +0200 Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 6169F3A; Wed, 24 Oct 2018 12:54:47 +0000 (GMT) Received: from Webmail-eu.st.com (sfhdag6node1.st.com [10.75.127.16]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 314F64713; Wed, 24 Oct 2018 12:54:47 +0000 (GMT) Received: from SFHDAG6NODE2.st.com (10.75.127.17) by SFHDAG6NODE1.st.com (10.75.127.16) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 24 Oct 2018 14:54:46 +0200 Received: from SFHDAG6NODE2.st.com ([fe80::a56f:c186:bab7:13d6]) by SFHDAG6NODE2.st.com ([fe80::a56f:c186:bab7:13d6%20]) with mapi id 15.00.1347.000; Wed, 24 Oct 2018 14:54:46 +0200 From: Pascal PAILLET-LME To: Mark Brown CC: "dmitry.torokhov@gmail.com" , "robh+dt@kernel.org" , "mark.rutland@arm.com" , "lee.jones@linaro.org" , "lgirdwood@gmail.com" , "wim@linux-watchdog.org" , "linux@roeck-us.net" , "linux-input@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-watchdog@vger.kernel.org" , "benjamin.gaignard@linaro.org" , "eballetbo@gmail.com" Subject: Re: [PATCH v4 4/8] regulator: stpmic1: add stpmic1 regulator driver Thread-Topic: [PATCH v4 4/8] regulator: stpmic1: add stpmic1 regulator driver Thread-Index: AQHUZsFCff0rP/nvtUWEQ9H/MMA/OQ== Date: Wed, 24 Oct 2018 12:54:46 +0000 Message-ID: <5BD06B96.3080809@st.com> References: <1539853324-29051-1-git-send-email-p.paillet@st.com> <1539853324-29051-5-git-send-email-p.paillet@st.com> <20181019115015.GC5895@sirena.org.uk> In-Reply-To: <20181019115015.GC5895@sirena.org.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.75.127.50] Content-Type: text/plain; charset="Windows-1252" Content-ID: <25C03AB68B403D46ADF5E95C06741A59@st.com> Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-10-24_05:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Mark, Le 10/19/2018 01:50 PM, Mark Brown a ?crit : > On Thu, Oct 18, 2018 at 09:02:12AM +0000, Pascal PAILLET-LME wrote: > >> + for (i = 0; i < ARRAY_SIZE(stpmic1_regulator_cfgs); i++) { >> + /* Parse DT & find regulators to register */ >> + init_data = stpmic1_regulators_matches[i].init_data; >> + if (init_data) >> + init_data->regulator_init = &stpmic1_regulator_parse_dt; >> + >> + rdev = stpmic1_regulator_register(pdev, i, init_data, regul); >> + if (IS_ERR(rdev)) >> + return PTR_ERR(rdev); > This looks mostly good, the only big thing is this - the default is to > just unconditionally register all the regulators that exist rather than > only those that are configured on that particular platform. This is a > bit simpler and means that all the readback of the configuration for the > unconfigured regulators is available for diagnostics. Is there a reason > not to do that? I'm sorry, I'm not sure to understand. Would you prefer to not register regulators that are not described in the device-tree ? In that case I could add: if (!init_data) continue; This would permit to keep some regulators unmodified by the kernel. This can be useful because we have some regulators configured by boot loaders (for the DDR at least) and it would be more simple to not handle them in the kernel. best regards, pascal