linux-kernel - Re: [PATCH 4/8] regulator: hi6421v600-regulator: move it from staging

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20201117142523.GD5142@sirena.org.uk>
Date:   Tue, 17 Nov 2020 14:25:24 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
Cc:     linuxarm@...wei.com, mauro.chehab@...wei.com,
        John Stultz <john.stultz@...aro.org>,
        Manivannan Sadhasivam <mani@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mayulong <mayulong1@...wei.com>,
        YueHaibing <yuehaibing@...wei.com>, devel@...verdev.osuosl.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/8] regulator: hi6421v600-regulator: move it from staging

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

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)