Hi,
On Wed, Sep 05, 2012 at 12:31:50PM -0700, Sarah Sharp wrote:
> On Wed, Sep 05, 2012 at 08:34:26AM +0300, Felipe Balbi wrote:
> > From: Moiz Sonasath <m-sonasath@xxxxxx>
> >
> > For non PCI-based stacks, this function call
> > usb_disable_xhci_ports(to_pci_dev(hcd->self.controller));
> > made from xhci_shutdown is not applicable.
> >
> > Ideally, we wouldn't have any PCI-specific code on
> > a generic driver such as the xHCI stack, but it looks
> > like we should just stub usb_disable_xhci_ports() out
> > for non-PCI devices.
>
> Oops, sorry about breaking non-PCI builds! I've already gotten a
> different bug fix for the same commit that broke it, so I probably
> shouldn't have rushed to push it before I left for vacation. :(
no problem. This is the kind of "issue" which having xhci.c split to its
own platform_device/platform_driver with PCI/OMAP/Exynos/etc glues as a
parent device would solve.
The core driver would only care about struct device * and all the bus
glue specific details could be either implemented through the PM
framework (which guarantees parent's suspend will only be called after
all children are suspended) and, for non-PM stuff, with something such
as:
static int usb_pci_disable_ports(struct device *child)
{
struct pci_glue *glue = dev_get_drvdata(child->parent);
if (!glue)
bail();
pci_write_config_dword(glue->pci, USB_INTEL_USB3_PSSEN, 0x0);
pci_write_config_dword(glue->pci, USB_INTEL_XUSB2PR, 0x0);
return 0;
}
static struct xhci_bus_glue_ops xhci_pci_ops = {
.disable_ports = usb_pci_disable_ports,
[ ... ]
};
then pass that as platform_data to xhci.c's device, and something like
below on a header:
static inline int usb_disable_xhci_ports(struct xhci_hcd *xhci)
{
if (!xhci || !xhci->ops || !xhci->ops->disable_ports)
return 0;
return xhci->ops->disable_ports(xhci->dev);
}
I know Alan will hate me for saying this, though, but that's life, I
guess :-D
--
balbi
Attachment:
signature.asc
Description: Digital signature
