Hi,
On Mon, Sep 05, 2011 at 04:05:01PM +0200, Sebastian Andrzej Siewior wrote:
> I don't think how ehci_platform_ops would fit in here unless it is a
> copy of of ehci_hc_driver. For the phy suspend it is a parent/child
you missed the point. As I already pointed out, we can have something
like below:
struct ehci_platform_ops {
int (*reset)(struct device *child);
int (*map)(struct device *child, struct urb *urb);
int (*unmap)(struct device *child, struct urb *urb);
...
};
then, let's say ehci-tegra populates that... on ehci_probe()
(ehci-hcd.c::probe), we could have:
...
ehci->ops = pdev->dev.platform_data;
...
then on ehci_reset() (this is the one which actually goes to hc_driver)
...
/*
* if this pointer is valid, it means arch code wants to handle it
* differently
*/
if (ehci->ops->reset)
return ehci->ops->reset(ehci->dev);
/* otherwise we can use the generic version */
return ehci_generic_reset(ehci);
...
similarly on map and unmap:
...
if (ehci->ops->map)
return ehci->ops->map(ehci->dev, urb);
return ehci_generic_map(ehci, urb);
...
See that ehci-tegra, would only pass the fields which it needs and if
the pointer is NULL the default/generic implementations are used,
because it's assumed that this particular architecture doesn't need
anything different from what the standard says.
--
balbi
Attachment:
signature.asc
Description: Digital signature
