On Mon, Apr 06, 2020 at 01:54:41PM +0200, Cornelia Huck wrote: > 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? I've just applied them, thank you!
