Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751514AbdH3JMJ (ORCPT ); Wed, 30 Aug 2017 05:12:09 -0400 Received: from mx07-00178001.pphosted.com ([62.209.51.94]:29116 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751319AbdH3JMI (ORCPT ); Wed, 30 Aug 2017 05:12:08 -0400 Subject: Re: [RESEND PATCH 2/3] regulator: Add support for stm32-vrefbuf To: Mark Brown CC: , , , , , , , , References: <1503925133-30722-1-git-send-email-fabrice.gasnier@st.com> <1503925133-30722-3-git-send-email-fabrice.gasnier@st.com> <20170829185719.h5fxvzmxbysyxwml@sirena.org.uk> From: Fabrice Gasnier Message-ID: Date: Wed, 30 Aug 2017 11:11:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170829185719.h5fxvzmxbysyxwml@sirena.org.uk> Content-Type: text/plain; charset="windows-1252" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.75.127.48] X-ClientProxiedBy: SFHDAG4NODE1.st.com (10.75.127.10) To SFHDAG5NODE3.st.com (10.75.127.15) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-08-30_04:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 984 Lines: 36 On 08/29/2017 08:57 PM, Mark Brown wrote: > On Mon, Aug 28, 2017 at 02:58:52PM +0200, Fabrice Gasnier wrote: > >> + ret = clk_prepare_enable(priv->clk); >> + if (ret) { >> + dev_err(&pdev->dev, "clk prepare failed\n"); > > If you're printing an error include the error code, it'll help users > figure out what went wrong. Hi Mark, Thanks for reviewing, I'll add it in v2. > >> + dev_info(&pdev->dev, "STM32 VREFBUF initialized\n"); > > This is just noise, remove it. I'll remove it in v2. > >> +static int __init stm32_vrefbuf_init(void) >> +{ >> + return platform_driver_register(&stm32_vrefbuf_driver); >> +} >> +subsys_initcall(stm32_vrefbuf_init); > > Why is this at subsys_initcall()? > Several consumers depend on it when it's being used, among which: STM32 internal ADC and DAC, but also external components. Purpose is to ensure it's ready before these drivers gets probed, instead of being deferred. Is it ok to keep it ? Please let me know, Best Regards, Fabrice