From patchwork Tue Apr 1 23:52:12 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: kim-phillips X-Patchwork-Id: 27588 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-ob0-f198.google.com (mail-ob0-f198.google.com [209.85.214.198]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id 7A9E420341 for ; Tue, 1 Apr 2014 23:52:30 +0000 (UTC) Received: by mail-ob0-f198.google.com with SMTP id wn1sf37620686obc.5 for ; Tue, 01 Apr 2014 16:52:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:delivered-to:date:from:to:cc:subject:message-id :in-reply-to:references:mime-version:sender:precedence:list-id :x-original-sender:x-original-authentication-results:mailing-list :list-post:list-help:list-archive:list-unsubscribe:content-type :content-transfer-encoding; bh=VTigKJ20kHo9ET69ffoGWZVD6ETnRomvERcxXuNeH9k=; b=d1dzsWeN+dLJADYEKiJc9mVPdeL70srKnt5u/NQ70KirTsgEQjVXUgxMkoyFgB9XQc /jBmdr24r509i+8TPB+3waw+LU63D50LosQOFklfWEZKgTEFHonJWP1mVnjbB4j2g78g kGK0HfY5zVVhKSiaNtFZctIfIiaTZ2t1V6lfViLMtgcsPjn1UIHR5hLIPVHSq9VVjSGW AzuTzpMXc7X0dOt2Qmr3J5YISgUjyLyPasDvmideRsxdtUX03LnEugLIUCvh/N77UGTk vhNt0JeZ4NkJfGdxDMK1LFZBY3NbE4LtAOWq8NeyxSm97cBLSG6RIECCM2/kamSRjN1D g4/w== X-Gm-Message-State: ALoCoQnio84kHvFN30gAVcNX8Ir1EoJkrj5CNOEmoCMahvQL+grqiH6t88lSm+Zzv3+VA5Dnd6ET X-Received: by 10.42.75.10 with SMTP id y10mr2064221icj.19.1396396349709; Tue, 01 Apr 2014 16:52:29 -0700 (PDT) X-BeenThere: patchwork-forward@linaro.org Received: by 10.140.84.103 with SMTP id k94ls165945qgd.93.gmail; Tue, 01 Apr 2014 16:52:29 -0700 (PDT) X-Received: by 10.52.128.231 with SMTP id nr7mr26594641vdb.17.1396396349585; Tue, 01 Apr 2014 16:52:29 -0700 (PDT) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by mx.google.com with ESMTPS id tz5si72546vdc.7.2014.04.01.16.52.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Apr 2014 16:52:29 -0700 (PDT) Received-SPF: neutral (google.com: 209.85.220.176 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) client-ip=209.85.220.176; Received: by mail-vc0-f176.google.com with SMTP id lc6so10497279vcb.7 for ; Tue, 01 Apr 2014 16:52:29 -0700 (PDT) X-Received: by 10.52.134.202 with SMTP id pm10mr5595vdb.55.1396396349303; Tue, 01 Apr 2014 16:52:29 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.220.12.8 with SMTP id v8csp278558vcv; Tue, 1 Apr 2014 16:52:28 -0700 (PDT) X-Received: by 10.68.191.200 with SMTP id ha8mr34142334pbc.66.1396396348324; Tue, 01 Apr 2014 16:52:28 -0700 (PDT) Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id ep2si90908pbb.117.2014.04.01.16.52.27; Tue, 01 Apr 2014 16:52:27 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754513AbaDAXwS (ORCPT + 27 others); Tue, 1 Apr 2014 19:52:18 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:47671 "EHLO mail-ob0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753236AbaDAXwP (ORCPT ); Tue, 1 Apr 2014 19:52:15 -0400 Received: by mail-ob0-f173.google.com with SMTP id gq1so11990112obb.32 for ; Tue, 01 Apr 2014 16:52:15 -0700 (PDT) X-Received: by 10.60.51.69 with SMTP id i5mr30964634oeo.17.1396396334836; Tue, 01 Apr 2014 16:52:14 -0700 (PDT) Received: from ntel (gate-tx3.freescale.com. [192.88.168.1]) by mx.google.com with ESMTPSA id w9sm893279oeo.4.2014.04.01.16.52.13 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Apr 2014 16:52:14 -0700 (PDT) Date: Tue, 1 Apr 2014 18:52:12 -0500 From: Kim Phillips To: alex.williamson@redhat.com Cc: gregkh@linuxfoundation.org, stuart.yoder@freescale.com, kvm@vger.kernel.org, jan.kiszka@siemens.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, mhocko@suse.cz, bhelgaas@google.com, Varun.Sethi@freescale.com, kvmarm@lists.cs.columbia.edu, rafael.j.wysocki@intel.com, agraf@suse.de, linux-pci@vger.kernel.org, linux@roeck-us.net, konrad.wilk@oracle.com, d.kasatkin@samsung.com, tj@kernel.org, scottwood@freescale.com, a.motakis@virtualopensystems.com, tech@virtualopensystems.com, Bharat.Bhushan@freescale.com, toshi.kani@hp.com, a.rigo@virtualopensystems.com, iommu@lists.linux-foundation.org, joe@perches.com, christoffer.dall@linaro.org, kim.phillips@freescale.com Subject: Re: [RFC PATCH] PCI: Introduce new device binding path using pci_dev.driver_override Message-Id: <20140401185212.7229f2c114c7e95089f00e90@linaro.org> In-Reply-To: <20140401161851.18815.31108.stgit@bling.home> References: <20140401161851.18815.31108.stgit@bling.home> X-Mailer: Sylpheed 3.4.0beta5 (GTK+ 2.24.20; x86_64-pc-linux-gnu) Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: list List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: kim.phillips@linaro.org X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 209.85.220.176 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , On Tue, 01 Apr 2014 10:28:54 -0600 Alex Williamson wrote: > The driver_override field allows us to specify the driver for a device > rather than relying on the driver to provide a positive match of the > device. This shortcuts the existing process of looking up the vendor > and device ID, adding them to the driver new_id, binding the device, > then removing the ID, but it also provides a couple advantages. > > First, the above process allows the driver to bind to any device > matching the new_id for the window where it's enabled. This is often > not desired, such as the case of trying to bind a single device to a > meta driver like pci-stub or vfio-pci. Using driver_override we can > do this deterministically using: > > echo pci-stub > /sys/bus/pci/devices/0000:03:00.0/driver_override > echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind > echo 0000:03:00.0 > /sys/bus/pci/drivers_probe > > Previously we could not invoke drivers_probe after adding a device > to new_id for a driver as we get non-deterministic behavior whether > the driver we intend or the standard driver will claim the device. > Now it becomes a deterministic process, only the driver matching > driver_override will probe the device. > > To return the device to the standard driver, we simply clear the > driver_override and reprobe the device, ex: > > echo > /sys/bus/pci/devices/0000:03:00.0/preferred_driver > echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind > echo 0000:03:00.0 > /sys/bus/pci/drivers_probe > > Another advantage to this approach is that we can specify a driver > override to force a specific binding or prevent any binding. For > instance when an IOMMU group is exposed to userspace through VFIO > we require that all devices within that group are owned by VFIO. > However, devices can be hot-added into an IOMMU group, in which case > we want to prevent the device from binding to any driver (preferred > driver = "none") or perhaps have it automatically bind to vfio-pci. > With driver_override it's a simple matter for this field to be set > internally when the device is first discovered to prevent driver > matches. > > Signed-off-by: Alex Williamson > --- > > Apologies for the exceptionally long cc list, this is a follow-up to > Stuart's "Subject: mechanism to allow a driver to bind to any device" > thread. This is effectively a v2 of the proof-of-concept patch I > posted in that thread. This version changes to use a dummy id struct > to return on an "override" match, which removes the collateral damage > and greatly simplifies the patch. This feels fairly well baked for > PCI and I would expect that platform drivers could do a similar > implementation. From there perhaps we can discuss whether there's > any advantage to placing driver_override on struct device. The logic > for incorporating it into the match still needs to happen per bus > driver, so it might only contribute to consistency of the show/store > sysfs attributes to move it up to struct device. Please comment. Sounds like Greg likes this approach more than {drv,dev}_sysfs_only. The diff below is the result of duplicating and converting this patch for platform devices, and, indeed, binding a device to the vfio-platform driver succeeds with: 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 However, it's almost pure duplication modulo the bus match code. The only other place I can see where to put the common bus check is drivers/base/base.h:driver_match_device(), which I'm guessing is off-limits? So should we leave this as per-bus code, and somehow refactor driver_override_{show,store}? Kim --- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ diff --git a/drivers/base/platform.c b/drivers/base/platform.c index bc78848..621c5bd2 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -22,6 +22,7 @@ #include #include #include +#include #include "base.h" #include "power/power.h" @@ -693,8 +694,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'; + + if (strlen(driver_override)) { + pdev->driver_override = driver_override; + } else { + kfree(driver_override); + pdev->driver_override = NULL; + } + + kfree(old); + + return count; +} + +static ssize_t driver_override_show(struct device *dev, + struct device_attribute *attr, char *buf) +{ + struct platform_device *pdev = to_platform_device(dev); + + return sprintf(buf, "%s\n", pdev->driver_override); +} +static DEVICE_ATTR_RW(driver_override); + + static struct attribute *platform_dev_attrs[] = { &dev_attr_modalias.attr, + &dev_attr_driver_override.attr, NULL, }; ATTRIBUTE_GROUPS(platform_dev); @@ -750,6 +792,10 @@ static int platform_match(struct device *dev, struct device_driver *drv) struct platform_device *pdev = to_platform_device(dev); struct platform_driver *pdrv = to_platform_driver(drv); + /* When driver_override is set, only bind to the matching driver */ + if (pdev->driver_override) + return !strcmp(pdev->driver_override, drv->name); + /* Attempt an OF style match first */ if (of_driver_match_device(dev, drv)) return 1; diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h index 16f6654..7ffe809 100644 --- a/include/linux/platform_device.h +++ b/include/linux/platform_device.h @@ -28,6 +28,7 @@ struct platform_device { struct resource *resource; const struct platform_device_id *id_entry; + char *driver_override; /* Driver name to force a match */ /* MFD cell pointer */ struct mfd_cell *mfd_cell;