> -----Original Message-----
> From: Greg KH [mailto:[email protected]]
> Sent: Monday, March 31, 2014 2:47 PM
> To: Yoder Stuart-B08248
> Cc: Alex Williamson; Alexander Graf; [email protected];
> [email protected]; [email protected];
> [email protected]; Michal Hocko; Wood Scott-B07421; Sethi
> Varun-B16395; [email protected]; Rafael J. Wysocki; Guenter
> Roeck; Dmitry Kasatkin; Tejun Heo; Bjorn Helgaas; Antonios Motakis;
> [email protected]; Toshi Kani; [email protected];
> [email protected]; Joe Perches;
> [email protected]
> Subject: Re: mechanism to allow a driver to bind to any device
>
> 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
Thanks,
Stuart
_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu
