[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH V2] Xen/pciback: Implement PCI slot or bus reset with 'do_flr' SysFS attribute
>>> On 29.11.17 at 16:37, <govinda.tatti@xxxxxxxxxx> wrote: > On 11/9/2017 2:49 AM, Jan Beulich wrote: >>>>> On 09.11.17 at 00:06, <Govinda.Tatti@xxxxxxxxxx> wrote: >>> +static int pcistub_reset_dev(struct pci_dev *dev) >>> +{ >>> + struct xen_pcibk_dev_data *dev_data; >>> + bool slot = false, bus = false; >>> + struct pcistub_args arg = {}; >>> + >>> + if (!dev) >>> + return -EINVAL; >>> + >>> + dev_dbg(&dev->dev, "[%s]\n", __func__); >>> + >>> + if (!pci_probe_reset_slot(dev->slot)) >>> + slot = true; >>> + else if ((!pci_probe_reset_bus(dev->bus)) && >>> + (!pci_is_root_bus(dev->bus))) >>> + bus = true; >>> + >>> + if (!bus && !slot) >>> + return -EOPNOTSUPP; >>> + >>> + /* >>> + * Make sure all devices on this bus are owned by the >>> + * PCI backend so that we can safely reset the whole bus. >>> + */ >> Is that really the case when you mean to do a slot reset? It was for >> a reason that I had asked about a missing "else" in v1 review, >> rather than questioning the conditional around the logic. > > In the case of bus or slot reset, our goal is to reset connected PCIe > fabric/card/endpoint. > The connected card/endpoint can be multi-function device. So, same > walk-through and checking > is needed irrespective of type of reset being used. I don't follow: The scope of other devices/functions possibly affected by a reset depends on the type of reset, doesn't it? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |