Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751861AbdH3PYC (ORCPT ); Wed, 30 Aug 2017 11:24:02 -0400 Received: from mx08-00178001.pphosted.com ([91.207.212.93]:37826 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751469AbdH3PYB (ORCPT ); Wed, 30 Aug 2017 11:24:01 -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> <20170830150249.5sofmjz3n2skzucq@sirena.org.uk> From: Fabrice Gasnier Message-ID: <8777c604-e16c-4359-095d-b3bd6efab5e0@st.com> Date: Wed, 30 Aug 2017 17:23:26 +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: <20170830150249.5sofmjz3n2skzucq@sirena.org.uk> Content-Type: text/plain; charset="windows-1252" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.75.127.50] X-ClientProxiedBy: SFHDAG3NODE2.st.com (10.75.127.8) To SFHDAG5NODE3.st.com (10.75.127.15) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-08-30_06:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 869 Lines: 28 On 08/30/2017 05:02 PM, Mark Brown wrote: > On Wed, Aug 30, 2017 at 11:11:24AM +0200, Fabrice Gasnier wrote: >> On 08/29/2017 08:57 PM, Mark Brown wrote: >>> On Mon, Aug 28, 2017 at 02:58:52PM +0200, Fabrice Gasnier wrote: > >>>> +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 ? > > No, that's not OK - just let deferred probe handle it. The same thing > applies to all regulator usage. > Hi Mark, Ok, I'll update this in v2 as well. Thanks, Fabrice