On Fri, 27 Mar 2020 13:45:01 +0100 Cornelia Huck <cohuck@xxxxxxxxxx> wrote: > For subchannels, we currently delay the initial ADD uevent to a > point in time controlled by the driver bound to it (this is to > avoid a storm of useless uevents for I/O subchannels that do not > have an operational device behind it and will get deregistered > again, which are potentially a lot on LPARs.) > > If we unbind from the io_subchannel driver and rebind again later, > we'll get a duplicate ADD uevent -- not a common workflow, but might > happen e.g. when you use a device in the host, then pass it to a > guest via vfio-ccw, and then want to use it in the host again. Fixed > by the first patch. > > The vfio_ccw subchannel driver did not generate any ADD uevent at > all -- currently not a problem, as every I/O subchannel will have been > bound to the io_subchannel driver before, but let's fix this anyway > (second patch). > > [As an aside, setting driver_override via a udev rule does not work > as expected, due to the uevent delaying -- a specified driver_override > works as designed, but userspace won't get the ADD uevent until after > the io_subchannel driver has been bound to the device already... we > may want to rethink this whole uevent mechanism for subchannels later, > but I don't think it's too pressing an issue.] > > Probably easiest for both patches to go via the s390 arch maintainers. Friendly ping. Anyone taking these? > > Cornelia Huck (2): > s390/cio: avoid duplicated 'ADD' uevents > s390/cio: generate delayed uevent for vfio-ccw subchannels > > drivers/s390/cio/device.c | 13 +++++++++---- > drivers/s390/cio/vfio_ccw_drv.c | 5 +++++ > 2 files changed, 14 insertions(+), 4 deletions(-) >
