On Tue, Nov 17, 2020 at 09:08:22AM +0100, Mauro Carvalho Chehab wrote: > Mark Brown <broonie@xxxxxxxxxx> 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:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
