* Eduardo Valentin <[email protected]> [120525 01:31]: > +int omap4_usb_phy_power(struct device *dev, int on) > +{ > + u32 val; > + int ret; > + > + if (on) { > + ret = omap_control_readl(dev, CONTROL_DEV_CONF, &val); > + if (!ret && (val & PHY_PD)) { > + ret = omap_control_writel(dev, ~PHY_PD, > + CONTROL_DEV_CONF); > + /* XXX: add proper documentation for this delay */ > + mdelay(200); > + } > + } else { > + ret = omap_control_writel(dev, PHY_PD, CONTROL_DEV_CONF); > + } > + > + return ret; > +} > +EXPORT_SYMBOL_GPL(omap4_usb_phy_power);
I'm not quite convinced that we should export omap_control_read/write to drivers. If there's a clear register area this USB phy driver can manage, then ioremaping it separately makes sense. If it's just one register, then exporting something like omap_control_usb_phy_set() might be better for ensuring that drivers don't mess up things for other drivers. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
