Hi, Roger Quadros writes: >>>> Stefan Agner writes: >>> >>>>> According to the device tree bindings the vcc-supply is optional. >>> >>> This is nonsense unless the device can work without this supply. Given >>> that the supply is called VCC that doesn't seem entirely likely. >> >> Afaik it is kind of a generic device tree binding, I guess the physical >> device can have various appearances and properties... >> >> A quick survey showed several device trees which do not specify >> vcc-supply... >> >> That said, I checked the device at hand, and it actually has a USB PHY >> power supply inputs, but the device tree does not model them. >> >>>>> + nop->vcc = devm_regulator_get_optional(dev, "vcc"); >>>>> if (IS_ERR(nop->vcc)) { >>>>> dev_dbg(dev, "Error getting vcc regulator: %ld\n", >>>>> PTR_ERR(nop->vcc)); >>>>> - if (needs_vcc) >>>>> - return -EPROBE_DEFER; >>>>> + if (needs_vcc || PTR_ERR(nop->vcc) == -EPROBE_DEFER) >>>>> + return PTR_ERR(nop->vcc); >>> >>>> does this look okay from a regulator API perspective? >>> >>> That's how to use _get_optional() but it's really unusual that you >>> should be using _get_optional(). >> >> Despite the above findings, I still think it is the right thing to do as >> long as we specify vcc-supply to be optional. >> > > I think the right behaviour would be that if vcc-supply is specified > in the DT then failure to get that supply is a serious failure and > probe should fail. > > So the correct fix would be to call devm_regulator_get() only if > needs_vcc is true. The way it is, AFAICT, regulator fwk will return a dummy regulator for cases where supply isn't in DT. -- balbi