* Eduardo Valentin <eduardo.valentin@xxxxxx> [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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
