linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: linuxarm@huawei.com, mauro.chehab@huawei.com,
	John Stultz <john.stultz@linaro.org>,
	Manivannan Sadhasivam <mani@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mayulong <mayulong1@huawei.com>,
	YueHaibing <yuehaibing@huawei.com>,
	devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/8] regulator: hi6421v600-regulator: move it from staging
Date: Tue, 17 Nov 2020 14:25:24 +0000	[thread overview]
Message-ID: <20201117142523.GD5142@sirena.org.uk> (raw)
In-Reply-To: <20201117090724.4ade833a@coco.lan>

[-- Attachment #1: Type: text/plain, Size: 1723 bytes --]

On Tue, Nov 17, 2020 at 09:08:22AM +0100, Mauro Carvalho Chehab wrote:
> Mark Brown <broonie@kernel.org> 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]. 

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. 

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2020-11-17 14:26 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-16 12:59 [PATCH 0/8] Move Hikey 970 USB support out of staging and add DT Mauro Carvalho Chehab
2020-11-16 12:59 ` [PATCH 1/8] phy: phy-hi3670-usb3: move driver from staging into phy Mauro Carvalho Chehab
2020-11-16 15:31   ` Rob Herring
2020-11-17  6:55     ` Mauro Carvalho Chehab
2020-11-17  9:51       ` Vinod Koul
2020-11-16 15:31   ` Rob Herring
2020-11-30 10:30   ` Vinod Koul
2020-11-16 12:59 ` [PATCH 2/8] spmi: hi6421-spmi-pmic: move driver from staging Mauro Carvalho Chehab
2020-11-16 15:32   ` Rob Herring
2020-11-16 12:59 ` [PATCH 3/8] mfd: " Mauro Carvalho Chehab
2020-11-16 15:32   ` Rob Herring
2020-11-16 12:59 ` [PATCH 4/8] regulator: hi6421v600-regulator: move it " Mauro Carvalho Chehab
2020-11-16 18:38   ` Mark Brown
2020-11-17  8:08     ` Mauro Carvalho Chehab
2020-11-17 14:25       ` Mark Brown [this message]
2020-11-17  8:38     ` Mauro Carvalho Chehab
2020-11-17 15:10       ` Mark Brown
2020-11-16 12:59 ` [PATCH 5/8] arm64: dts: hisilicon: hi3670.dtsi: add I2C settings Mauro Carvalho Chehab
2020-11-16 12:59 ` [PATCH 6/8] arm64: dts: hikey970-pinctrl.dtsi: add missing pinctrl settings Mauro Carvalho Chehab
2020-11-16 12:59 ` [PATCH 7/8] dts: hisilicon: add support for USB3 on Hikey 970 Mauro Carvalho Chehab
2020-11-16 12:59 ` [PATCH 8/8] dts: hisilicon: add support for the PMIC found " Mauro Carvalho Chehab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201117142523.GD5142@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=john.stultz@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=mani@kernel.org \
    --cc=mauro.chehab@huawei.com \
    --cc=mayulong1@huawei.com \
    --cc=mchehab+huawei@kernel.org \
    --cc=yuehaibing@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).