On Thu, Jun 07, 2018 at 10:28:59AM -0600, Alex Williamson wrote:
> On Thu, 7 Jun 2018 18:06:26 +0200
> Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote:
>
> > Hi,
> >
> > > left it in a state that we're not recovering from. For root complex
> > > integrated endpoints, if there's no FLR or even PM reset available,
> > > you're out of luck unless you can come up with a device specific
> > > reset.
> >
> > Should be doable, ehci has a controller reset bit in the command
> > register (xhci too btw).
> >
> > Typically doing a reset is one of the first things a driver does on
> > initialization though. So I'm not fully sure such a reset quirk would
> > improve the situation ...
>
> Do SeaBIOS/edk2 drivers make use of those resets as well? It seems like
> when I've seen trouble with assigned USB devices, it's often at the VM
> BIOS. In any case, if there are USB specific standards here, we should
> hook them in through pci_dev_specific_reset() in the host kernel. I
> imagine we'd try to prioritize these lower than a PCI FLR, but
> certainly better than nothing. Thanks,
Hmm, the comment above pci_dev_specific_reset sound like it is
specifically for cases where linux hasn't a driver which can do the
reset ...
anyway, this should work (untested):
static int reset_ehci_dev(struct pci_dev *dev, int probe)
{
void __iomem *mmio;
unsigned long timeout;
u32 opregs, cmd;
if (probe)
return 0;
mmio = pci_iomap(dev, 0, 0);
if (!mmio)
return -ENOMEM;
opregs = ioread8(mmio);
cmd = EHCI_CMD_RESET;
iowrite32(cmd, mmio + opregs);
timeout = jiffies + msecs_to_jiffies(250);
do {
cmd = ioread32(mmio + opregs);
if ((cmd & EHCI_CMD_RESET) == 0)
goto reset_complete;
msleep(10);
} while (time_before(jiffies, timeout));
pci_warn(dev, "timeout during reset\n");
reset_complete:
pci_iounmap(dev, mmio);
return 0;
}
cheers,
Gerd
