search for: device_link

...l remove need to bother with dt bindings etc. That's handled by the firmware drivers and IOMMU layer, there shouldn't be any special treatment at the virtio layer. In general removal of an IOMMU needs to be done after removal of all endpoints connected to it, which should be described using device_link from the driver core. DT or ACPI is only used to tell drivers where to find resources, and to describe the DMA topology. Thanks, Jean

...l remove need to bother with dt bindings etc. That's handled by the firmware drivers and IOMMU layer, there shouldn't be any special treatment at the virtio layer. In general removal of an IOMMU needs to be done after removal of all endpoints connected to it, which should be described using device_link from the driver core. DT or ACPI is only used to tell drivers where to find resources, and to describe the DMA topology. Thanks, Jean

...-524,14 +524,13 @@ static bool qcom_iommu_capable(enum iommu_cap cap) } } -static int qcom_iommu_add_device(struct device *dev) +static struct iommu_device *qcom_iommu_probe_device(struct device *dev) { struct qcom_iommu_dev *qcom_iommu = to_iommu(dev); - struct iommu_group *group; struct device_link *link; if (!qcom_iommu) - return -ENODEV; + return ERR_PTR(-ENODEV); /* * Establish the link between iommu and master, so that the @@ -542,28 +541,19 @@ static int qcom_iommu_add_device(struct device *dev) if (!link) { dev_err(qcom_iommu->dev, "Unable to create device link...

...her with dt bindings etc. > That's handled by the firmware drivers and IOMMU layer, there shouldn't > be any special treatment at the virtio layer. In general removal of an > IOMMU needs to be done after removal of all endpoints connected to it, > which should be described using device_link from the driver core. DT or > ACPI is only used to tell drivers where to find resources, and to > describe the DMA topology. > > Thanks, > Jean My point was virtio mmio isn't widely used outside of ARM. Rather than try to make everyone use it, IMHO it's better to start with...

...p deferring probe in of_iommu > * Move IOMMU OF tables to .rodata > * Create a static virtio-iommu stub that declares the virtio-iommu OF > table entry. The build system doesn't pick up IOMMU_OF_DECLARE when > done from an object destined to be built as module :( > * Create a device_link between endpoint and IOMMU, to ensure that > removing the IOMMU driver also unbinds the endpoint driver. Putting > this in IOMMU core seems like a better approach since even when not > built as module, unbinding an IOMMU device via sysfs will cause > crashes. > > With thi...

...PM, it also guarantees that on system sleep, the HDA controller suspends before the GPU and resumes after the GPU, and on system shutdown the HDA controller's ->shutdown hook is executed before the one of the GPU. It is a complete solution. Using this functionality is as simple as calling device_link_add(), which results in a dmesg entry like this: pci 0000:01:00.1: Linked as a consumer to 0000:01:00.0 The code for the GPU-governed audio power management can thus be removed (except where it's still needed for legacy manual power control). The device link is added in a PCI quirk r...

...hat > on system sleep, the HDA controller suspends before the GPU and resumes > after the GPU, and on system shutdown the HDA controller's ->shutdown > hook is executed before the one of the GPU. It is a complete solution. > > Using this functionality is as simple as calling device_link_add(), > which results in a dmesg entry like this: > > pci 0000:01:00.1: Linked as a consumer to 0000:01:00.0 > > The code for the GPU-governed audio power management can thus be removed > (except where it's still needed for legacy manual power control). > > T...

Modernize vga_switcheroo by using a "device link" to enforce a runtime PM dependency from an HDA controller to the GPU it's integrated into. Remove thereby obsoleted code and fix a bunch of bugs. Device links were introduced in v4.10. Users might see a small power saving if the discrete GPU is in use and its HDA controller is not, because the HDA controller is now allowed to runtime

...rivers * Don't give up deferring probe in of_iommu * Move IOMMU OF tables to .rodata * Create a static virtio-iommu stub that declares the virtio-iommu OF table entry. The build system doesn't pick up IOMMU_OF_DECLARE when done from an object destined to be built as module :( * Create a device_link between endpoint and IOMMU, to ensure that removing the IOMMU driver also unbinds the endpoint driver. Putting this in IOMMU core seems like a better approach since even when not built as module, unbinding an IOMMU device via sysfs will cause crashes. With this, as long as virtio-mmio isn&...

...rivers * Don't give up deferring probe in of_iommu * Move IOMMU OF tables to .rodata * Create a static virtio-iommu stub that declares the virtio-iommu OF table entry. The build system doesn't pick up IOMMU_OF_DECLARE when done from an object destined to be built as module :( * Create a device_link between endpoint and IOMMU, to ensure that removing the IOMMU driver also unbinds the endpoint driver. Putting this in IOMMU core seems like a better approach since even when not built as module, unbinding an IOMMU device via sysfs will cause crashes. With this, as long as virtio-mmio isn&...

Modernize vga_switcheroo by using a device link to enforce a runtime PM dependency from an HDA controller to the GPU it's integrated into, v2. Changes since v1: - Replace patch [1/7] to use pci_save_state() / pci_restore_state() for consistency between runtime PM code path of bound and unbound devices. (Rafael, Bjorn) - Patch [5/7]: Drop an unnecessary initialization. (Bjorn) Rephrase

Hi, here is a patch-set to rename iommu_param to dev_iommu and establish it as a struct for generic per-device iommu-data. Also move the iommu_fwspec pointer from struct device into dev_iommu to have less iommu-related pointers in struct device. The bigger part of this patch-set moves the iommu_priv pointer from struct iommu_fwspec to dev_iommu, making is usable for iommu-drivers which do not

Hi, here is the second version of this patch-set. The first version with some more introductory text can be found here: https://lore.kernel.org/lkml/20200407183742.4344-1-joro at 8bytes.org/ Changes v1->v2: * Rebased to v5.7-rc1 * Re-wrote the arm-smmu changes as suggested by Robin Murphy * Re-worked the Exynos patches to hopefully not break the driver anymore * Fixed a missing

Hi, here is the second version of this patch-set. The first version with some more introductory text can be found here: https://lore.kernel.org/lkml/20200407183742.4344-1-joro at 8bytes.org/ Changes v1->v2: * Rebased to v5.7-rc1 * Re-wrote the arm-smmu changes as suggested by Robin Murphy * Re-worked the Exynos patches to hopefully not break the driver anymore * Fixed a missing

Hi, here is the third version of this patch-set. Older versions can be found here: v1: https://lore.kernel.org/lkml/20200407183742.4344-1-joro at 8bytes.org/ (Has some more introductory text) v2: https://lore.kernel.org/lkml/20200414131542.25608-1-joro at 8bytes.org/ Changes v2 -> v3: * Rebased v5.7-rc3 * Added a missing iommu_group_put() as reported by Lu Baolu. * Added a

...de (during bus probing) first adds all devices to their respective IOMMU group before it determines the default domain type and then allocates it for the group. It turned out that this required to remove the calls of iommu_group_get_for_dev() from the IOMMU drivers. While at it, the calls to iommu_device_link()/unlink() where also moved out of the drivers, which required a different interface than add_device()/remove_device(). The result is the new probe_device()/release_device() interface, where the driver just does its own setup and then returns the iommu_device which belongs to the device being probe...

...de (during bus probing) first adds all devices to their respective IOMMU group before it determines the default domain type and then allocates it for the group. It turned out that this required to remove the calls of iommu_group_get_for_dev() from the IOMMU drivers. While at it, the calls to iommu_device_link()/unlink() where also moved out of the drivers, which required a different interface than add_device()/remove_device(). The result is the new probe_device()/release_device() interface, where the driver just does its own setup and then returns the iommu_device which belongs to the device being probe...