search for: plat_dev

...u16 dev_id = pci_dev_id(pdev); + + return pci_domain_nr(pdev->bus) == id->segment && + dev_id >= id->bdf_start && + dev_id <= id->bdf_end; + } else if (id->type == VIRT_TOPO_DEV_TYPE_MMIO && + dev_is_platform(dev)) { + struct platform_device *plat_dev = to_platform_device(dev); + struct resource *mem; + + mem = platform_get_resource(plat_dev, IORESOURCE_MEM, 0); + if (!mem) + return false; + return mem->start == id->base; + } + return false; +} + +static const struct iommu_ops *virt_iommu_setup(struct device *dev) +{ + struct iommu_f...

...t; + > + return pci_domain_nr(pdev->bus) == id->segment && > + dev_id >= id->bdf_start && > + dev_id <= id->bdf_end; > + } else if (id->type == VIRT_TOPO_DEV_TYPE_MMIO && > + dev_is_platform(dev)) { > + struct platform_device *plat_dev = to_platform_device(dev); > + struct resource *mem; > + > + mem = platform_get_resource(plat_dev, IORESOURCE_MEM, 0); > + if (!mem) > + return false; > + return mem->start == id->base; > + } > + return false; > +} > + > +static const struct iommu_ops *v...

Add a topology description to the virtio-iommu driver and enable x86 platforms. Since [v2] we have made some progress on adding ACPI support for virtio-iommu, which is the preferred boot method on x86. It will be a new vendor-agnostic table describing para-virtual topologies in a minimal format. However some platforms don't use either ACPI or DT for booting (for example microvm), and will

Add a topology description to the virtio-iommu driver and enable x86 platforms. Since [v2] we have made some progress on adding ACPI support for virtio-iommu, which is the preferred boot method on x86. It will be a new vendor-agnostic table describing para-virtual topologies in a minimal format. However some platforms don't use either ACPI or DT for booting (for example microvm), and will

...r. */ device_add_disk(NULL, disk, NULL); *l = lo; return lo->lo_number; diff --git a/drivers/block/mg_disk.c b/drivers/block/mg_disk.c index 48c67f6..81f289a 100644 --- a/drivers/block/mg_disk.c +++ b/drivers/block/mg_disk.c @@ -1006,6 +1006,7 @@ static int mg_probe(struct platform_device *plat_dev) set_capacity(host->gd, host->n_sectors); + /* FIXME: handle error. */ device_add_disk(NULL, host->gd, NULL); return err; diff --git a/drivers/block/mtip32xx/mtip32xx.c b/drivers/block/mtip32xx/mtip32xx.c index 504c549..83dc3dc 100644 --- a/drivers/block/mtip32xx/mtip32xx.c +++...

This is an attempt to fix the issue that some disks' sysfs attributes are not ready at the time its KOBJ_ADD event is sent. The symptom is during device hotplug, udev may fail to find certain attributes, such as serial or wwn, of the disk. As a result the /dev/disk/by-id entries are not created. The cause is device_add_disk emits the uevent before returning, and the callers have to create

This is an attempt to fix the issue that some disks' sysfs attributes are not ready at the time its KOBJ_ADD event is sent. The symptom is during device hotplug, udev may fail to find certain attributes, such as serial or wwn, of the disk. As a result the /dev/disk/by-id entries are not created. The cause is device_add_disk emits the uevent before returning, and the callers have to create

The race condition is noticed between disk_add() and disk attributes, on virtio-blk hotplug. Userspace listens to the KOBJ_ADD uevent generated in add_disk(). At that point we haven't created the serial attribute file, therefore depending on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get created. As pointed out by Christoph Hellwig in the specific fix [1], virtio-blk

The race condition is noticed between disk_add() and disk attributes, on virtio-blk hotplug. Userspace listens to the KOBJ_ADD uevent generated in add_disk(). At that point we haven't created the serial attribute file, therefore depending on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get created. As pointed out by Christoph Hellwig in the specific fix [1], virtio-blk