From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 108A9C5519F for ; Tue, 17 Nov 2020 14:26:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A8062221FC for ; Tue, 17 Nov 2020 14:26:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="X9BdSDn1" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728881AbgKQOZq (ORCPT ); Tue, 17 Nov 2020 09:25:46 -0500 Received: from mail.kernel.org ([198.145.29.99]:58094 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728441AbgKQOZp (ORCPT ); Tue, 17 Nov 2020 09:25:45 -0500 Received: from localhost (fw-tnat.cambridge.arm.com [217.140.96.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4B186221FC; Tue, 17 Nov 2020 14:25:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1605623143; bh=56cvIXZlMxNuswpAfZ65Rr7eBSVJPUrqGNADm+IBwWs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=X9BdSDn1bCJJol0UpEdN286Nb4foJ7ftIK5rvFKwynYpMD2vR5eXxJZ8LXq5yRmF1 wW0D7R7GgU8OkKiVi0tBjbMFIFiAazNCpyOSXm/i3LgAIK009QEUrg6Ybpc/GFlBAE elsGhNTGmjSze8G/XncgGS77mVgin3Ry78Ib7kqM= Date: Tue, 17 Nov 2020 14:25:24 +0000 From: Mark Brown To: Mauro Carvalho Chehab Cc: linuxarm@huawei.com, mauro.chehab@huawei.com, John Stultz , Manivannan Sadhasivam , Greg Kroah-Hartman , Liam Girdwood , Mayulong , YueHaibing , devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 4/8] regulator: hi6421v600-regulator: move it from staging Message-ID: <20201117142523.GD5142@sirena.org.uk> References: <471362653f22a8748202c55babd2b462056a5797.1605530560.git.mchehab+huawei@kernel.org> <20201116183833.GC4739@sirena.org.uk> <20201117090724.4ade833a@coco.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="n/aVsWSeQ4JHkrmm" Content-Disposition: inline In-Reply-To: <20201117090724.4ade833a@coco.lan> X-Cookie: Pause for storage relocation. User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --n/aVsWSeQ4JHkrmm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 17, 2020 at 09:08:22AM +0100, Mauro Carvalho Chehab wrote: > Mark Brown escreveu: > > This probe code looks very different to other regulator drivers, this > > alone should have been a warning that the driver needs some substantial > > refactoring here. As indicated information about what regulators are > > present on devices and their properties should be in the driver not the > > DT, the driver should just be able to register them unconditionally and > > use of_match and regulators_node to allow the core to find any > > constraints that are provided by the platform. > The setup for MFD/regulator is different than almost all other > regulator drivers currently upstreamed[1].=20 It really shouldn't be doing anything unusual. > It means that, for the regulator driver to work, two drivers > should be probed first: the SPMI bus controller driver > (hisi-spmi-controller.c) and the SPMI bus client driver, which is > at the MFD driver(hi6421-spmi-pmic.c). > Only after having both probed, the regulator driver can be > probed. This is totally fine and very common for drivers in general, a combination of probe deferral and fw_devlink exists to sort this stuff out. > Also, as all the communication between the PM chip > and the SoC happens via a single serial bus, there's no > sense on probing the regulators in parallel. > That's mainly the reason why I opted to serialize the probe > inside hi6421v600-regulator.c.=20 I can't think of a regulator driver that doesn't have an entirly serialized probe routine, that's not the issue. The issue is that almost nothing that the probe routine is doing is done by other regulator drivers. --n/aVsWSeQ4JHkrmm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl+z3VMACgkQJNaLcl1U h9AIlwf9GtLYXFKKGNEQWjdf/Itfjnh8gyQP+5GihjpkiYch3YtDrIDWxsjxEfPD /MtvxLPT52m1NP/del1x35eLeqyJTsNKHLB+GAzcV7DKUxmbXJUeE130hFt0SO9J d8nWU69yRROMIdqZ5F3CI3nfGtLa7eYn+aDEVihW3MItIeORc7M1VdvPHR4Rlh88 MZvJ/PQodMtkPiuVB4kGN8jDTcXyiUMPu95cuvly7iwCzcYWAasBvZ3zkXoee98a 38W5FEMxjqDvRhRz+ivnolxRemKjtFS5z7YuBCWmpmUrp/LT0QNXrKhZh1qJNHPL wcX3dQ3Zbmq9qFWjHn4nCh5WuUtXwQ== =pWHl -----END PGP SIGNATURE----- --n/aVsWSeQ4JHkrmm--