From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E4316187FEE for ; Fri, 23 Aug 2024 13:56:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724421373; cv=none; b=kC28aSvW28uvhgqofFvSNZ3aTk9uiYcx4Sr63r5I0/1fU6Hduh/SMjKCX8euBAlZqbabhfLJX1Rg6koSrhae3wnTDpNubKYecgeSyl4k5Sva8yo61XcZ5tJA8+ihbYiGIvta1ijU4Z9qEvYqg+H+vQDRAjxnIxdpyGTOHV507kI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724421373; c=relaxed/simple; bh=gndjyeqaytEaKYf1kOK8jLLgaJjwQwTw8djDulGw++U=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=cx70Gp3+U1l1RIOo5JpDHWGAjLHHsdTaPvwJ/ftzhn4gr0UBg5W/FJag2lFoRYWzHlEjwBFURg25GoXe1A755xDg831G4EVsENfejGWS3VFTQ/FynUpapoyHL9xmP3mqdi1BAcdWbujkv9KskTS3iYAHmWLw0fqgyokWcynE3dk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=SlscKqwL; arc=none smtp.client-ip=192.198.163.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="SlscKqwL" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1724421371; x=1755957371; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=gndjyeqaytEaKYf1kOK8jLLgaJjwQwTw8djDulGw++U=; b=SlscKqwLOOt8l5zp0kClc41kBZxJOTAPktaUZXAIhIMjiAcsKYz7ouG7 MF5Hgumq1x0l9V35r1fqO1WdetBVa9sgbDhDRd6XVhakYL4J6b8zDl0zr G9aeCfcly2cEVfFdAUe8S/plhTpnMCKm6vaigHoJwmcklTSVto6gpC7N+ VqUjJAcq7gnR/IFmQiKihtHEjxYxoIukTitEfhFm2ZepXOZgUMPoX19so uHCfOrMkL23RaDYLXC3+orLmifJjb4OBz4HFwRboafFIGFL7ugli4K6/X tb/vBq1sF6xjBTnz05dApFB2I61jhJVOAYYQ2y6VXGHPCVrdb7by+qnmF w==; X-CSE-ConnectionGUID: +AZXnsb+QoeH7CYAUueQuA== X-CSE-MsgGUID: ODhORNmVQqe8zjrcvstB/w== X-IronPort-AV: E=McAfee;i="6700,10204,11172"; a="33513417" X-IronPort-AV: E=Sophos;i="6.10,170,1719903600"; d="scan'208";a="33513417" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Aug 2024 06:56:10 -0700 X-CSE-ConnectionGUID: qYpLNdWxRbOic97zRlbH/g== X-CSE-MsgGUID: M4YCAqa4Q1u89Ebl/F3u5g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,170,1719903600"; d="scan'208";a="62104859" Received: from smile.fi.intel.com ([10.237.72.54]) by orviesa006.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Aug 2024 06:56:07 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.98) (envelope-from ) id 1shUln-00000000oMz-1Rih; Fri, 23 Aug 2024 16:56:03 +0300 Date: Fri, 23 Aug 2024 16:56:03 +0300 From: Andy Shevchenko To: Chen-Yu Tsai Cc: Rob Herring , Saravana Kannan , Matthias Brugger , AngeloGioacchino Del Regno , Wolfram Sang , Benson Leung , Tzung-Bi Shih , Mark Brown , Liam Girdwood , chrome-platform@lists.linux.dev, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, Douglas Anderson , Johan Hovold , Jiri Kosina , linux-i2c@vger.kernel.org Subject: Re: [PATCH v5 07/10] i2c: of-prober: Add regulator support Message-ID: References: <20240822092006.3134096-1-wenst@chromium.org> <20240822092006.3134096-8-wenst@chromium.org> Precedence: bulk X-Mailing-List: chrome-platform@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo On Fri, Aug 23, 2024 at 05:35:59PM +0800, Chen-Yu Tsai wrote: > On Thu, Aug 22, 2024 at 10:09 PM Andy Shevchenko > wrote: > > On Thu, Aug 22, 2024 at 05:20:00PM +0800, Chen-Yu Tsai wrote: ... > > Hmm... why not > > > > static int i2c_of_probe_get_res(struct device *dev, struct device_node *node, > > struct i2c_of_probe_data *data) > > { > > struct property *prop; > > int ret; > > > > ret = i2c_of_probe_get_regulator(dev, node, data); > > if (ret < 0) { > > i2c_of_probe_free_res(data); > > return dev_err_probe(dev, ret, "Failed to get regulator supplies from %pOF\n", node); > > } > > > > return 0; > > } > > That would be more churn in the next patch, which introduces another > error condition requiring the same cleanup. OK! ... > > > + /* largest post-power-on pre-reset-deassert delay seen among drivers */ > > > + msleep(500); > > > > How would we monitor if any [new] driver wants to use bigger timeout? > > The assumption is that the person doing the integration should test for > this. This prober doesn't get called everywhere. It needs a driver to > call it, and that driver is written by someone for some specific platform. > Maybe I should explicitly spell that out in the function description? > Or even make it a parameter? > > Also, having an arbitrarily large number here doesn't help platforms that > want to minimize boot time. On that front I'm also thinking about whether > it is possible to do a handover to the actual driver so that the latter > doesn't have to go through the whole power sequence again. Yeah, I think the best effort is to have a parameter. -- With Best Regards, Andy Shevchenko