On Mon, Nov 18, 2019 at 08:24:28AM -0600, Bjorn Helgaas wrote:
> On Mon, Nov 18, 2019 at 11:59:30AM +0000, Mark Brown wrote:
> > On Sat, Nov 16, 2019 at 12:54:20PM +0000, Robin Murphy wrote:
> > > Null checks are both cheaper and more readable than having !IS_ERR()
> > > splattered everywhere.
> >
> > > - if (IS_ERR(rockchip->vpcie3v3))
> > > + if (!rockchip->vpcie3v3)
> > > return;
> > >
> > > /*
> > > @@ -611,6 +611,7 @@ static int rockchip_pcie_parse_host_dt(struct rockchip_pcie *rockchip)
> > > if (PTR_ERR(rockchip->vpcie12v) != -ENODEV)
> > > return PTR_ERR(rockchip->vpcie12v);
> > > dev_info(dev, "no vpcie12v regulator found\n");
> > > + rockchip->vpcie12v = NULL;
> >
> > According to the API NULL is a valid regulator. We don't currently
> > actually do this but it's storing up surprises if you treat it as
> > invalid.
>
> I don't know anything about the regulator API, but the fact that NULL
> can be a valid regulator is itself a little surprising :)
if (rockchip->vpcie3v3 == NULL) is true the driver would currently
panic the kernel AFAICS.
rockchip_pcie_set_power_limit()
->regulator_get_current_limit(NULL)
-> _regulator_get_current_limit(NULL)
-> regulator_lock(NULL)
-> regulator_lock_nested(NULL, NULL)
-> ww_mutex_trylock(&NULL->mutex)
Also, by making NULL a valid regulator, it means that regulators
(ie pointers) with default values are valid whether we call
devm_regulator_get* or not. I understand this patch can be dropped
but that per-se does not make this driver code any more robust AFAICS.
Lorenzo
