Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp3791231ybl; Mon, 13 Jan 2020 02:42:27 -0800 (PST) X-Google-Smtp-Source: APXvYqxTQ6gVR/lWr9EEUg47AHiIF6goBxbk/3w8MqMoPqIsT+dg+DcVG/8nYkDk1/VfvOm/Exuo X-Received: by 2002:aca:1c1a:: with SMTP id c26mr12459020oic.75.1578912147830; Mon, 13 Jan 2020 02:42:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578912147; cv=none; d=google.com; s=arc-20160816; b=K1QKOmG3ZDSEet4vvi6Gau6KmQtFpbPEAa4bwTHCo58aFk76i2ONuxfbGC7jWej6ID WLXg3lAwnLDyE+zwRTPKN224eb/aOsYxvbYOy3EnzYDBAT/is4B7eBpeWvVTHPf9SjI7 lqe73TtQ5mMzTWSFUoaPEvEUCVgUMI7Ex5rjgaT+K7Qmo3ALACxY2Lyah+mXuE7zuGHs C1vkFrM18OM8BZSAB1KOcxvJDNA8vv25s3zM2uM3PH2KrYfGjCQXnUSBKH3ABuNhENbj Tj6D9zIhKyQY/a7y6qpdYs3YzS0bQIxMUKoUkR7Nggi4nF0PqrhvbXiczTxpt2HNZ4D2 jUZg== 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; bh=6jcup08EYfdIWJkOanS1mKfEl62Vehirifel7nrZFi8=; b=h3w+OeNnVEpNwl3g6/XkjE5lOMu0tzN3ByBrtAKp0IF+j/KjUIoMRebBU+fpnEzdZu 1ewRRRvV+IvyJJSsq/Uti3zasvFTrAZ6O+KUVeDv+LPZ/97+v3yfvUCzyCr8RCUoYYfk ds8TSMoCcgR/FctpectSYsU0hPuAJeO07rVb6p4jABCNseXZdG8jSA2WT34k+b82IRIQ yBTP+jTU2XbP1VvdCnnA8Wm0On3OJ8ODjgEYY6WQ2bgLXDShTd61Lz5f4mnjokjnCw/K UYjFDdPKfJ1AKGNvdOo/hI3PkBmhYODs2bEGKBSURcZKaM4Kz6vkrooESyaU58TZzwQt PzFA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=Twb97kuz; 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 i12si4375387oto.230.2020.01.13.02.42.15; Mon, 13 Jan 2020 02:42:27 -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=@linaro.org header.s=google header.b=Twb97kuz; 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 S1726435AbgAMKlX (ORCPT + 99 others); Mon, 13 Jan 2020 05:41:23 -0500 Received: from mail-wm1-f68.google.com ([209.85.128.68]:55967 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725992AbgAMKlX (ORCPT ); Mon, 13 Jan 2020 05:41:23 -0500 Received: by mail-wm1-f68.google.com with SMTP id q9so9054083wmj.5 for ; Mon, 13 Jan 2020 02:41:22 -0800 (PST) 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=6jcup08EYfdIWJkOanS1mKfEl62Vehirifel7nrZFi8=; b=Twb97kuznKKWouAzZb6gfEs94jiWvVsrpQlqIlnqGPt1ci4uSIoG4CHcBwtASDnsQE zZyISJxTEMvvvG7LA0UcN9H44LxfCB273dB+3PaIkVQO3lEicu0eGVE5OF7kuatWEF9w WIPChvLGCkSxTIEeNln8JWyIbxU918XHophnLmzWhy7xjbW/YWCoisbzOZo+nU8y9KzP eRUDH5p8LTe2iYLOtn7+3vBKRWx5O6YDsxdBPmVWhOaAFzvvw8kz5K3p6YJhPAXVAQfh kmZc7uLTxQSGNKIkWwa/P05WLQ/BEqZTJIlvCmRc1jEsgKmgHjdvbs6v6atk109YCV3b GiYg== 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=6jcup08EYfdIWJkOanS1mKfEl62Vehirifel7nrZFi8=; b=ccaBMIIPEFV76O0Y94NrYg6O/YDJGNs6GOdqABAbZEAiI4cE0Y8Yvw/utwEB9lBeG8 87gjaLin/rPBJrIjuuzL1jzG87UROfXc6XQux7xODSrC1r+5bPQ7s4y16m73wXBC54V6 lABiN23LKdnDEWf/JFdwG8kTFtyo1NTwvmuzRjKP4x0rNMbW+JOfjWAkGlNtl63m7wOv pPjMnkRtLv+3GRoDrQlwiaAqpZoi/2pptXZcrgjdvZajmshMA876Aymm7rpVgBejQq4S tokUNZB7UlAy2rcVUkcHbbtejzC85XeSbxUNrd7h3N47ZH2EcS1NQonnQ5e9z86S6+98 YVpg== X-Gm-Message-State: APjAAAWCCGZHSPQea/HTslJUhu53yQyDKEM8TSAg96KgeQRAK6e338GS 4hmovz6DFx+XnOM3qONcopyclA== X-Received: by 2002:a05:600c:2283:: with SMTP id 3mr19680976wmf.100.1578912081445; Mon, 13 Jan 2020 02:41:21 -0800 (PST) Received: from dell ([95.147.198.95]) by smtp.gmail.com with ESMTPSA id f1sm14642899wmc.45.2020.01.13.02.41.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Jan 2020 02:41:20 -0800 (PST) Date: Mon, 13 Jan 2020 10:41:41 +0000 From: Lee Jones To: Charles Keepax Cc: linux-kernel@vger.kernel.org, patches@opensource.cirrus.com Subject: Re: [PATCH 1/2] mfd: madera: Allow more time for hardware reset Message-ID: <20200113104141.GC5414@dell> References: <20200106102834.31301-1-ckeepax@opensource.cirrus.com> <20200107142742.GN14821@dell> <20200108084640.GI10451@ediswmail.ad.cirrus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200108084640.GI10451@ediswmail.ad.cirrus.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 08 Jan 2020, Charles Keepax wrote: > On Tue, Jan 07, 2020 at 02:27:42PM +0000, Lee Jones wrote: > > On Mon, 06 Jan 2020, Charles Keepax wrote: > > > > > Both manual and power on resets have a brief period where the chip will > > > not be accessible immediately afterwards. Extend the time allowed for > > > this from a minimum of 1mS to 2mS based on newer evaluation of the > > > hardware and ensure this reset happens in all reset conditions. Whilst > > > making the change also remove the redundant NULL checks in the reset > > > functions as the GPIO functions already check for this. > > > > > > Signed-off-by: Charles Keepax > > > --- > > > drivers/mfd/madera-core.c | 18 ++++++++++-------- > > > 1 file changed, 10 insertions(+), 8 deletions(-) > > > > > > diff --git a/drivers/mfd/madera-core.c b/drivers/mfd/madera-core.c > > > index a8cfadc1fc01e..f41ce408259fb 100644 > > > --- a/drivers/mfd/madera-core.c > > > +++ b/drivers/mfd/madera-core.c > > > @@ -238,6 +238,11 @@ static int madera_wait_for_boot(struct madera *madera) > > > return ret; > > > } > > > > > > +static inline void madera_reset_delay(void) > > > +{ > > > + usleep_range(2000, 3000); > > > +} > > > > Hmm ... We usually shy away from abstraction for the sake of > > abstraction. What's preventing you from using the preferred method of > > simply calling the abstracted function from each of the call-sites? > > > > I could understand (a little) if you needed to frequently change these > > values, since changing them in once place is obviously simpler than > > changing them in 3, but even then it's marginal. > > > > I don't mind manually inline it, we don't plan on changing the > values very often certainly. It really was just to avoid future > bugs if someone adds a new place that needs the delay or does > indeed change the delay. Would you mind if I used a define for > the time instead, if I am manually inlining? That keeps the same > single place to update, but without the extra function. That would be my preference, yes. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog