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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
