On Tue, 15 Jun 2021 15:35:09 +0200 Christoph Hellwig <hch@xxxxxx> wrote: > This is my alternative take on this series from Jason: > > https://lore.kernel.org/dri-devel/87czsszi9i.fsf@xxxxxxxxxx/T/ > > The mdev/vfio parts are exactly the same, but this solves the driver core > changes for the direct probing without the in/out flag that Greg hated, > which cause a little more work, but probably make the result better. > > Original decription from Jason below: > > The mdev bus's core part for managing the lifecycle of devices is mostly > as one would expect for a driver core bus subsystem. > > However instead of having a normal 'struct device_driver' and binding the > actual mdev drivers through the standard driver core mechanisms it open > codes this with the struct mdev_parent_ops and provides a single driver > that shims between the VFIO core's struct vfio_device and the actual > device driver. > > Instead, allow mdev drivers implement an actual struct mdev_driver and > directly call vfio_register_group_dev() in the probe() function for the > mdev. Arrange to bind the created mdev_device to the mdev_driver that is > provided by the end driver. > > The actual execution flow doesn't change much, eg what was > parent_ops->create is now device_driver->probe and it is called at almost > the exact same time - except under the normal control of the driver core. > > Ultimately converting all the drivers unlocks a fair number of additional > VFIO simplifications and cleanups. Looks like we need an update to Documentation/driver-api/vfio-mediated-device.rst to go along with this. Also, if we're preserving compatibility with the "legacy" mdev_parent_ops callbacks without deprecating them, does it really make sense to convert every one of the sample drivers to this new direct registration? Thanks, Alex _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
