mirror of
https://github.com/FEX-Emu/linux.git
synced 2024-12-27 20:07:09 +00:00
7e8ac87a44
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/267 Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> |
||
---|---|---|
.. | ||
Kconfig | ||
Makefile | ||
of.c | ||
phy-ab8500-usb.c | ||
phy-am335x-control.c | ||
phy-am335x-control.h | ||
phy-am335x.c | ||
phy-fsl-usb.c | ||
phy-fsl-usb.h | ||
phy-generic.c | ||
phy-generic.h | ||
phy-gpio-vbus-usb.c | ||
phy-isp1301-omap.c | ||
phy-isp1301.c | ||
phy-keystone.c | ||
phy-msm-usb.c | ||
phy-mv-usb.c | ||
phy-mv-usb.h | ||
phy-mxs-usb.c | ||
phy-omap-otg.c | ||
phy-qcom-8x16-usb.c | ||
phy-tahvo.c | ||
phy-tegra-usb.c | ||
phy-twl6030-usb.c | ||
phy-ulpi-viewport.c | ||
phy-ulpi.c | ||
phy.c |