mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kim Phillips <kim.phillips@linaro.org>
To: stuart.yoder@freescale.com
Cc: gregkh@linuxfoundation.org, kvm@vger.kernel.org,
	jan.kiszka@siemens.com, will.deacon@arm.com, mhocko@suse.cz,
	bhelgaas@google.com, Varun.Sethi@freescale.com,
	kvmarm@lists.cs.columbia.edu, rafael.j.wysocki@intel.com,
	linux@roeck-us.net, d.kasatkin@samsung.com, tj@kernel.org,
	alex.williamson@redhat.com, scottwood@freescale.com,
	tech@virtualopensystems.com, toshi.kani@hp.com,
	linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
	joe@perches.com, kim.phillips@freescale.com
Subject: Re: mechanism to allow a driver to bind to any device
Date: Mon, 31 Mar 2014 17:32:18 -0500	[thread overview]
Message-ID: <20140331173218.d12bc3ca7773139a09822dfc@linaro.org> (raw)
In-Reply-To: <c6a10ce9bfd84287b5c5aa3809987b2b@DM2PR03MB352.namprd03.prod.outlook.com>

On Mon, 31 Mar 2014 20:23:36 +0000
Stuart Yoder <stuart.yoder@freescale.com> wrote:

> > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > Sent: Monday, March 31, 2014 2:47 PM
> > 
> > On Mon, Mar 31, 2014 at 06:47:51PM +0000, Stuart Yoder wrote:
> > > I also, was at the point where I thought we should perhaps just
> > > go with current mechanisms and implement new_id for the platform
> > > bus...but Greg's recent response is 'platform devices suck' and it
> > sounds
> > > like he would reject a new_id patch for the platform bus.  So it kind
> > > of feels like we are stuck.
> > 
> > ids mean nothing in the platform device model, so having a new_id file
> > for them makes no sense.
> 
> They don't have IDs like PCI, but platform drivers have to match on
> something.  Platform device match tables are based on compatible strings.
> 
> Example from Freescale DMA driver:
>   static const struct of_device_id fsldma_of_ids[] = {
>         { .compatible = "fsl,elo3-dma", },
>         { .compatible = "fsl,eloplus-dma", },
>         { .compatible = "fsl,elo-dma", },
>         {}
>   };
> 
> The process of unbinding, setting a new_id, and binding to vfio would work
> just like PCI:
> 
>    echo ffe101300.dma > /sys/bus/platform/devices/ffe101300.dma/driver/unbind
>    echo fsl,eloplus-dma > /sys/bus/platform/drivers/vfio-platform/new_id

In platform device land, we don't want to pursue the
new_id/match-by-compatible methodology: we know exactly which specific
device (not device types) we want bound to which driver, so we just
want to be able to simply:

echo fff51000.ethernet | sudo tee -a /sys/bus/platform/devices/fff51000.ethernet/driver/unbind
echo fff51000.ethernet | sudo tee -a /sys/bus/platform/drivers/vfio-platform/bind

and not get involved with how PCI "doesn't simply do that," independent
of autoprobe/hotplug.

Kim

  parent reply	other threads:[~2014-03-31 22:32 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-08 17:29 [RFC PATCH v4 00/10] VFIO support for platform devices Antonios Motakis
2014-02-08 17:29 ` [RFC PATCH v4 01/10] driver core: export driver_probe_device() Antonios Motakis
2014-02-14 22:27   ` Greg KH
     [not found]     ` <ba7597fd8c9f4d91bbccfb42e31a165e@DM2PR03MB352.namprd03.prod.outlook.com>
     [not found]       ` <20140215024725.GA2542@kroah.com>
     [not found]         ` <7043e1edd9974de590dcb392cd8aff14@DM2PR03MB352.namprd03.prod.outlook.com>
     [not found]           ` <20140215173348.GA8056@kroah.com>
     [not found]             ` <b6374a0f30194969ba4622ff2f58ae65@DM2PR03MB352.namprd03.prod.outlook.com>
     [not found]               ` <20140220224337.GA20097@kroah.com>
     [not found]                 ` <54cd150235ba4954becdd12f725c5ebd@DM2PR03MB352.namprd03.prod.outlook.com>
     [not found]                   ` <20140326144025.GA18387@phenom.dumpdata.com>
     [not found]                     ` <D45FC8F2-7807-4BBB-A253-8EFCD091D6BD@suse.de>
     [not found]                       ` <1395850862.632.247.camel@ul30vt.home>
     [not found]                         ` <1395871761.632.316.camel@ul30vt.home>
2014-03-31 18:47                           ` mechanism to allow a driver to bind to any device Stuart Yoder
     [not found]                             ` <20140331194705.GA13014@kroah.com>
     [not found]                               ` <c6a10ce9bfd84287b5c5aa3809987b2b@DM2PR03MB352.namprd03.prod.outlook.com>
2014-03-31 22:32                                 ` Kim Phillips [this message]
     [not found]                           ` <20140328165809.GA12659@phenom.dumpdata.com>
     [not found]                             ` <1396026623.4502.34.camel@ul30vt.home>
2014-03-31 22:36                               ` Kim Phillips
2014-03-31 23:52                                 ` Alex Williamson
2014-02-08 17:29 ` [RFC PATCH v4 02/10] VFIO_IOMMU_TYPE1: Introduce the VFIO_DMA_MAP_FLAG_EXEC flag Antonios Motakis
2014-02-10 20:04   ` Alex Williamson
2014-02-08 17:29 ` [RFC PATCH v4 03/10] VFIO_IOMMU_TYPE1: workaround to build for platform devices Antonios Motakis
2014-02-08 17:29 ` [RFC PATCH v4 04/10] VFIO_PLATFORM: Initial skeleton of VFIO support " Antonios Motakis
2014-02-08 17:29 ` [RFC PATCH v4 05/10] VFIO_PLATFORM: Return info for device and its memory mapped IO regions Antonios Motakis
2014-02-10 22:32   ` Alex Williamson
2014-02-08 17:29 ` [RFC PATCH v4 06/10] VFIO_PLATFORM: Read and write support for the device fd Antonios Motakis
2014-02-10 22:45   ` Alex Williamson
2014-02-10 23:12     ` Scott Wood
2014-02-10 23:20       ` Alex Williamson
2014-02-08 17:29 ` [RFC PATCH v4 07/10] VFIO_PLATFORM: Support MMAP of MMIO regions Antonios Motakis
2014-02-08 17:29 ` [RFC PATCH v4 08/10] VFIO_PLATFORM: Return IRQ info Antonios Motakis
2014-02-08 17:29 ` [RFC PATCH v4 09/10] VFIO_PLATFORM: Initial interrupts support Antonios Motakis
2014-02-08 17:29 ` [RFC PATCH v4 10/10] VFIO_PLATFORM: Support for maskable and automasked interrupts Antonios Motakis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140331173218.d12bc3ca7773139a09822dfc@linaro.org \
    --to=kim.phillips@linaro.org \
    --cc=Varun.Sethi@freescale.com \
    --cc=alex.williamson@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=d.kasatkin@samsung.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jan.kiszka@siemens.com \
    --cc=joe@perches.com \
    --cc=kim.phillips@freescale.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=mhocko@suse.cz \
    --cc=rafael.j.wysocki@intel.com \
    --cc=scottwood@freescale.com \
    --cc=stuart.yoder@freescale.com \
    --cc=tech@virtualopensystems.com \
    --cc=tj@kernel.org \
    --cc=toshi.kani@hp.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®