From: Cornelia Huck We often have the situation that we register a subchannel and start device recognition, only to find out that the device is not usable after all, which triggers an unregister of the subchannel. This often happens on hundreds of subchannels on a LPAR, leading to a storm of events which aren't of any use. Therefore, use uevent_suppress to delay the KOBJ_ADD uevent for a subchannel until we know that its ccw_device is to be registered. Signed-off-by: Cornelia Huck Cc: Greg K-H Cc: Kay Sievers Cc: Eric Rannaud Cc: Heiko Carstens Signed-off-by: Andrew Morton --- drivers/s390/cio/css.c | 9 +++++++++ drivers/s390/cio/device.c | 6 ++++++ 2 files changed, 15 insertions(+) diff -puN drivers/s390/cio/css.c~s390-cio-delay-uevents-for-subchannels drivers/s390/cio/css.c --- a/drivers/s390/cio/css.c~s390-cio-delay-uevents-for-subchannels +++ a/drivers/s390/cio/css.c @@ -135,6 +135,15 @@ css_register_subchannel(struct subchanne sch->dev.bus = &css_bus_type; sch->dev.release = &css_subchannel_release; sch->dev.groups = subch_attr_groups; + /* + * We don't want to generate uevents for I/O subchannels that don't + * have a working ccw device behind them since they will be + * unregistered before they can be used anyway, so we delay the add + * uevent until after device recognition was successful. + */ + if (!cio_is_console(sch->schid)) + /* Console is special, no need to suppress. */ + sch->dev.uevent_suppress = 1; css_get_ssd_info(sch); diff -puN drivers/s390/cio/device.c~s390-cio-delay-uevents-for-subchannels drivers/s390/cio/device.c --- a/drivers/s390/cio/device.c~s390-cio-delay-uevents-for-subchannels +++ a/drivers/s390/cio/device.c @@ -888,6 +888,12 @@ io_subchannel_register(struct work_struc } goto out; } + /* + * Now we know this subchannel will stay, we can throw + * our delayed uevent. + */ + sch->dev.uevent_suppress = 0; + kobject_uevent(&sch->dev.kobj, KOBJ_ADD); /* make it known to the system */ ret = ccw_device_register(cdev); if (ret) { _