Hello. On 15-03-2013 4:25, Kuninori Morimoto wrote:
0xAAAA0000 =========== EHCI ---------- 0xAAAA0094 PHY 0xAAAA009C PHY ---------- EHCI 0xAAAA0400 ========== ... 0xAAAA0800 ---------- PHY 0xAAAA0900 ----------
This driver couldn't probe if it used "request_mem_region()"
Fair enough. I must say, though. That's a peculiar register mapping ;-)
Not peculiar enough to not be able to overcome it. Those registers at 0xAAAA009[4C] are not really PHY related, they control EHCI internal buffering. They probably shouldn't have been a part of this driver even...
I'm not sure what is the best solution.
I suspect that these registers should be intialized as a part of ehci-platform driver's power_on() platform callback.
I had same opinion before, and of course I agree your opinion. But, not in power_on() callback. I guess you need to create new callback (for init), since power_on() and ioremap() timing
if (pdata->power_on) { err = pdata->power_on(dev); if (err < 0) return err; } ... hcd->regs = devm_ioremap_resource(&dev->dev, res_mem); if (IS_ERR(hcd->regs)) { err = PTR_ERR(hcd->regs); goto err_put_hcd; } # init() here ? if (pdata->init) err = pdata->init(dev, hcd->regs);
Yes, that would have been more handy. I'm just not sure if it will be acceptable to community.
WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html