On 04/04/2014 06:35 PM, Kim Phillips wrote:
Needed by platform device drivers, such as the vfio-platform driver [1],
in order to bypass the existing OF, ACPI, id_table and name string matches,
and successfully be able to be bound to any device, like so:

echo vfio-platform > /sys/bus/platform/devices/fff51000.ethernet/driver_override
echo fff51000.ethernet > 
/sys/bus/platform/devices/fff51000.ethernet/driver/unbind
echo fff51000.ethernet > /sys/bus/platform/drivers_probe

This mimics "PCI: Introduce new device binding path using
pci_dev.driver_override" [2], which is an interface enhancement
for more deterministic PCI device binding, e.g., when in the
presence of hotplug.

[1] http://lkml.iu.edu/hypermail/linux/kernel/1402.1/00177.html
[2] http://thread.gmane.org/gmane.linux.kernel.iommu/4605

Signed-off-by: Kim Phillips <kim.phill...@freescale.com>
---
if this looks ok, should it be included in the next version of the
vfio-platform submission series, like last time ([1] above)?

  Documentation/ABI/testing/sysfs-bus-platform | 17 ++++++++++
  drivers/base/platform.c                      | 46 ++++++++++++++++++++++++++++
  include/linux/platform_device.h              |  1 +
  3 files changed, 64 insertions(+)
  create mode 100644 Documentation/ABI/testing/sysfs-bus-platform

diff --git a/Documentation/ABI/testing/sysfs-bus-platform 
b/Documentation/ABI/testing/sysfs-bus-platform
new file mode 100644
index 0000000..6b14a6a
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-platform
@@ -0,0 +1,17 @@
+What:          /sys/bus/platform/devices/.../driver_override
+Date:          April 2014
+Contact:       Kim Phillips <kim.phill...@freescale.com>
+Description:
+               This file allows the driver for a device to be specified
+               which will override standard OF, ACPI, ID table, and name
+               matching.  When specified, only a driver with a name matching
+               the value written to driver_override will have an opportunity
+               to bind to the device.  The override may be cleared by
+               writing an empty string (ex. echo > driver_override), returning
+               the device to standard matching rules binding.  Writing to
+               driver_override does not automatically unbind the device from
+               its current driver or make any attempt to automatically load
+               the specified driver name.  If no driver with a matching name
+               is currently loaded in the kernel, no match will be found.
+               This also allows devices to opt-out of driver binding using
+               a driver_override name such as "none".
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index e714709..ded1db1 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -22,6 +22,7 @@
  #include <linux/pm_runtime.h>
  #include <linux/idr.h>
  #include <linux/acpi.h>
+#include <linux/limits.h>

  #include "base.h"
  #include "power/power.h"
@@ -690,8 +691,49 @@ static ssize_t modalias_show(struct device *dev, struct 
device_attribute *a,
  }
  static DEVICE_ATTR_RO(modalias);

+static ssize_t driver_override_store(struct device *dev,
+                                    struct device_attribute *attr,
+                                    const char *buf, size_t count)
+{
+       struct platform_device *pdev = to_platform_device(dev);
+       char *driver_override, *old = pdev->driver_override;
+
+       if (count > PATH_MAX)
+               return -EINVAL;
+
+       driver_override = kstrndup(buf, count, GFP_KERNEL);
+       if (!driver_override)
+               return -ENOMEM;
+
+       while (strlen(driver_override) &&
+              driver_override[strlen(driver_override) - 1] == '\n')
+               driver_override[strlen(driver_override) - 1] = '\0';
+

Seems to me that something like

        cp = strchr(driver_override, '\n');
        if (cp)
                *cp = '\0';

would be much simpler.

Guenter

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Reply via email to