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. 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(-) -- 2.21.1
