• Arnd Bergmann's avatar
    usb: phy: qcom-8x16: fix regulator API abuse · 7e8ac87a
    Arnd Bergmann authored
    gcc warns about the use of regulators in phy_8x16_probe:
    
        drivers/usb/phy/phy-qcom-8x16-usb.c: In function 'phy_8x16_probe':
        drivers/usb/phy/phy-qcom-8x16-usb.c:284:13: error: 'regs[0].consumer' may be used uninitialized in this function [-Werror=maybe-uninitialized]
        drivers/usb/phy/phy-qcom-8x16-usb.c:285:13: error: 'regs[1].consumer' may be used uninitialized in this function [-Werror=maybe-uninitialized]
        drivers/usb/phy/phy-qcom-8x16-usb.c:286:12: error: 'regs[2].consumer' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    
    According to Mark Brown, this is the result of various abuses
    of the PHY interfaces [1], so let's fix the driver instead.
    
    This puts the regulator bulk data into the device structure so it
    gets properly initialized and lets us call regulator_bulk_enable()
    and regulator_bulk_disable() rather than open-coding them.
    
    Setting the voltages the way the driver does is rather pointless
    because for each regulator there is only one valid voltage
    range, so that can just get set up in the DT. As there doesn't
    seem to be any user of the newly added driver yet, we can simply
    make sure the DTs are setting this up right when they get added.
    
    I'm also fixing the handling of regulator_bulk_enable() failure.
    Right now, the driver just ignores any failure, which doesn't make
    sense, so I'm changing it to loudly complain (in case we actually
    had a bug here) and error out.
    
    Doing a fly-by review of the driver, I notice a couple of other
    problems that I'm not addressing here:
    
    - It really should not have been written as a USB PHY driver, but
      instead should use the PHY subsystem.
    
    - The DT compatible string does not follow the usual conventions,
      and it should have a proper identifier in it rather than a wildcard.
    
    - The example in the devicetree binding lists a register address
      that is the same as the actual EHCI host controller in the SoC
      as well as the otg-snps and the ci-hdrc device, which indicates
      that these are probably not even distinct devices (or all but
      one of them are wrong), and if more than one of them tries to
      request the resources correctly, they fail.
    
    [1] https://lkml.org/lkml/2016/1/26/267Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
    Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
    7e8ac87a
phy-qcom-8x16-usb.c 9.74 KB