search for: driver_override

...;>> Rethink about this. If we don't specify any ID, the binding won't work. >>> We can bind manually. It's not really for production anyway, so >>> not a big deal imho. >> >> I think you mean doing it via "new_id", right. > I really meant driver_override. This is what people have been using > with pci-stub for years now. Do you want me to implement "driver_overrid" in this series, or a NULL id_table is sufficient? > >>>> How about using a dedicated subsystem vendor id for this? >>>> >>>> Than...

...;>> Rethink about this. If we don't specify any ID, the binding won't work. >>> We can bind manually. It's not really for production anyway, so >>> not a big deal imho. >> >> I think you mean doing it via "new_id", right. > I really meant driver_override. This is what people have been using > with pci-stub for years now. Do you want me to implement "driver_overrid" in this series, or a NULL id_table is sufficient? > >>>> How about using a dedicated subsystem vendor id for this? >>>> >>>> Than...

...we don't specify any ID, the binding won't work. > > > > We can bind manually. It's not really for production anyway, so > > > > not a big deal imho. > > > > > > I think you mean doing it via "new_id", right. > > I really meant driver_override. This is what people have been using > > with pci-stub for years now. > > > Do you want me to implement "driver_overrid" in this series, or a NULL > id_table is sufficient? Doesn't the pci subsystem create driver_override for all devices on the pci bus? > &g...

...this. If we don't specify any ID, the binding won't work. >>>>> We can bind manually. It's not really for production anyway, so >>>>> not a big deal imho. >>>> I think you mean doing it via "new_id", right. >>> I really meant driver_override. This is what people have been using >>> with pci-stub for years now. >> >> Do you want me to implement "driver_overrid" in this series, or a NULL >> id_table is sufficient? > > Doesn't the pci subsystem create driver_override for all devices > on t...

...this. If we don't specify any ID, the binding won't work. >>>>> We can bind manually. It's not really for production anyway, so >>>>> not a big deal imho. >>>> I think you mean doing it via "new_id", right. >>> I really meant driver_override. This is what people have been using >>> with pci-stub for years now. >> >> Do you want me to implement "driver_overrid" in this series, or a NULL >> id_table is sufficient? > > Doesn't the pci subsystem create driver_override for all devices > on t...

On 2020/6/7 ??9:51, Michael S. Tsirkin wrote: > On Fri, Jun 05, 2020 at 04:54:17PM +0800, Jason Wang wrote: >> On 2020/6/2 ??3:08, Jason Wang wrote: >>>>> +static const struct pci_device_id vp_vdpa_id_table[] = { >>>>> +??? { PCI_DEVICE(PCI_VENDOR_ID_REDHAT_QUMRANET, PCI_ANY_ID) }, >>>>> +??? { 0 } >>>>> +}; >>>> This

On 2020/6/7 ??9:51, Michael S. Tsirkin wrote: > On Fri, Jun 05, 2020 at 04:54:17PM +0800, Jason Wang wrote: >> On 2020/6/2 ??3:08, Jason Wang wrote: >>>>> +static const struct pci_device_id vp_vdpa_id_table[] = { >>>>> +??? { PCI_DEVICE(PCI_VENDOR_ID_REDHAT_QUMRANET, PCI_ANY_ID) }, >>>>> +??? { 0 } >>>>> +}; >>>> This

...000" ATTRS{status}=="0x00000007" ATTRS{vendor}=="0x554d4551" looking at parent device '/devices/platform/a003e00.virtio_mmio': KERNELS=="a003e00.virtio_mmio" SUBSYSTEMS=="platform" DRIVERS=="virtio-mmio" ATTRS{driver_override}=="(null)" looking at parent device '/devices/platform': KERNELS=="platform" SUBSYSTEMS=="" DRIVERS=="" Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org...

...000" ATTRS{status}=="0x00000007" ATTRS{vendor}=="0x554d4551" looking at parent device '/devices/platform/a003e00.virtio_mmio': KERNELS=="a003e00.virtio_mmio" SUBSYSTEMS=="platform" DRIVERS=="virtio-mmio" ATTRS{driver_override}=="(null)" looking at parent device '/devices/platform': KERNELS=="platform" SUBSYSTEMS=="" DRIVERS=="" Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org...

...0000:00:03.0': KERNELS=="0000:00:03.0" SUBSYSTEMS=="pci" DRIVERS=="virtio-pci" ATTRS{irq}=="11" ATTRS{subsystem_vendor}=="0x1af4" ATTRS{broken_parity_status}=="0" ATTRS{class}=="0x000000" ATTRS{driver_override}=="(null)" ATTRS{consistent_dma_mask_bits}=="64" ATTRS{dma_mask_bits}=="64" ATTRS{local_cpus}=="3" ATTRS{device}=="0x1004" ATTRS{enable}=="1" ATTRS{msi_bus}=="" ATTRS{local_cpulist}=="0-1"...

...> > > > Rethink about this. If we don't specify any ID, the binding won't work. > > We can bind manually. It's not really for production anyway, so > > not a big deal imho. > > > I think you mean doing it via "new_id", right. I really meant driver_override. This is what people have been using with pci-stub for years now. > > > > > > How about using a dedicated subsystem vendor id for this? > > > > > > Thanks > > If virtio vendor id is used then standard driver is expected > > to bind, right? Maybe u...

...0x00000007" > ATTRS{vendor}=="0x554d4551" > > looking at parent device '/devices/platform/a003e00.virtio_mmio': > KERNELS=="a003e00.virtio_mmio" > SUBSYSTEMS=="platform" > DRIVERS=="virtio-mmio" > ATTRS{driver_override}=="(null)" Since I can't do that on my box, would you be so kind to run ls -l /dev/disk/by-path If it returns ids like virtio-pci-a003e00.virtio_mmio[-partn] my suggested patch should be OK for ARM in that it will produce ids in the format platform-a003e00.virtio_mmio[-partn] &gt...

On Tue, Feb 28, 2017 at 09:47:42AM +0100, Viktor Mihajlovski wrote: > >>>> One could argue about back-level compatibility, but virtio by-path > >>>> naming has changed multiple times. We have seen virtio-pci-virtio<n> > >>>> (not predictable), pci-<busid> and virtio-pci-<busid> already. It > >>>> might be a good time now

On Tue, Feb 28, 2017 at 09:47:42AM +0100, Viktor Mihajlovski wrote: > >>>> One could argue about back-level compatibility, but virtio by-path > >>>> naming has changed multiple times. We have seen virtio-pci-virtio<n> > >>>> (not predictable), pci-<busid> and virtio-pci-<busid> already. It > >>>> might be a good time now

...enable > local_cpus? numa_node? reset????? resource0_wc? subsystem ?uevent > class???????????????? d3cold_allowed??????????? driver?????????? irq > modalias??? physfn???? resource?? resource3???? subsystem_device ?vendor > config??????????????? device??????????????????? driver_override local_cpulist > msi_bus???? power????? resource0? resource3_wc subsystem_vendor > > >> If bound to xen-pciback, it vf should also appear in the output of 'xl >> pci-assignable-list'. > > Before starting the VM, it's there: > > [root at xengfs1f ~]...

...S{vendor}=="0x554d4551" > > > > looking at parent device '/devices/platform/a003e00.virtio_mmio': > > KERNELS=="a003e00.virtio_mmio" > > SUBSYSTEMS=="platform" > > DRIVERS=="virtio-mmio" > > ATTRS{driver_override}=="(null)" > Since I can't do that on my box, would you be so kind to run > ls -l /dev/disk/by-path > If it returns ids like > virtio-pci-a003e00.virtio_mmio[-partn] > my suggested patch should be OK for ARM in that it will produce ids in > the format > platf...

...S{vendor}=="0x554d4551" > > > > looking at parent device '/devices/platform/a003e00.virtio_mmio': > > KERNELS=="a003e00.virtio_mmio" > > SUBSYSTEMS=="platform" > > DRIVERS=="virtio-mmio" > > ATTRS{driver_override}=="(null)" > Since I can't do that on my box, would you be so kind to run > ls -l /dev/disk/by-path > If it returns ids like > virtio-pci-a003e00.virtio_mmio[-partn] > my suggested patch should be OK for ARM in that it will produce ids in > the format > platf...

On Fri, Apr 24, 2020 at 4:35 PM Peter Crowther <peter.crowther@melandra.com> wrote: > > On Fri, 24 Apr 2020 at 21:10, Mauricio Tavares <raubvogel@gmail.com> wrote: >> >> Let's say I have libvirt >> >> [root@vmhost2 ~]# virsh version >> [...] >> >> Running hypervisor: QEMU 2.12.0 >> [root@vmhost2 ~]# >> [...] > > When

...meter or member 'max_uV_step' not described in 'regulation_constraints' include/linux/regulator/driver.h:223: warning: Function parameter or member 'resume' not described in 'regulator_ops' include/linux/spi/spi.h:190: warning: Function parameter or member 'driver_override' not described in 'spi_device' fs/direct-io.c:258: warning: Excess function parameter 'offset' description in 'dio_complete' fs/libfs.c:496: warning: Excess function parameter 'available' description in 'simple_write_end' fs/posix_acl.c:647: warn...