On Wed, Oct 27 2021, Vineeth Vijayan <vneethv@xxxxxxxxxxxxx> wrote:
> 'commit fa1a8c23eb7d ("s390: cio: Delay uevents for subchannels")'
> introduced the uevent suppression of subchannels. Even though there
> are reasons for wanting to delay the uevent, it also introduces
> problems. As part of cleaning-up the css driver,this patch removes
> the uevent-suppress logic. The ADD uevent will be generated when
> there is a valid subchannel and not after finding the associated
> device. Removing the uevent suppress logic also introduces a new BIND
> uevent associated to the channel-subsystem.
Hm, I'd probably put that a bit differently:
commit fa1a8c23eb7d ("s390: cio: Delay uevents for subchannels")
introduced suppression of uevents for a subchannel until after it is
clear that the subchannel would not be unregistered again
immediately. This was done to avoid uevents being generated for I/O
subchannels with no valid device, which can happen on LPAR.
However, this also has some drawbacks: All subchannel drivers need to
manually remove the uevent suppression and generate an ADD uevent as
soon as they are sure that the subchannel will stay around. This misses
out on all uevents that are not the initial ADD uevent that would be
generated while uevents are suppressed; for example, all subchannels
were missing the BIND uevent.
As uevents being generated even for I/O subchannels without an
operational device turned out to be not as bad as missing uevents and
complicating the code flow, let's remove uevent suppression for
subchannels.
>
> Signed-off-by: Vineeth Vijayan <vneethv@xxxxxxxxxxxxx>
> ---
> drivers/s390/cio/chsc_sch.c | 5 -----
> drivers/s390/cio/css.c | 19 -------------------
> drivers/s390/cio/device.c | 18 ------------------
> drivers/s390/cio/eadm_sch.c | 5 -----
> drivers/s390/cio/vfio_ccw_drv.c | 5 -----
> 5 files changed, 52 deletions(-)
Patch looks sane to me, but I'll have to rely on your testing :)
