public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Vineeth Vijayan <vneethv@linux.ibm.com>, linux-s390@vger.kernel.org
Cc: oberpar@linux.ibm.com, vneethv@linux.ibm.com
Subject: Re: [PATCH] s390/cio: remove uevent suppress from cio driver
Date: Tue, 02 Nov 2021 16:42:52 +0100	[thread overview]
Message-ID: <87ilxabm2r.fsf@redhat.com> (raw)
In-Reply-To: <20211027085059.544736-2-vneethv@linux.ibm.com>

On Wed, Oct 27 2021, Vineeth Vijayan <vneethv@linux.ibm.com> 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@linux.ibm.com>
> ---
>  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 :)


  reply	other threads:[~2021-11-02 15:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-27  8:50 [RFC v2 0/1]s390/cio: remove uevent suppress from cio driver Vineeth Vijayan
2021-10-27  8:50 ` [PATCH] s390/cio: " Vineeth Vijayan
2021-11-02 15:42   ` Cornelia Huck [this message]
2021-11-02 15:31 ` [RFC v2 0/1]s390/cio: " Cornelia Huck
2021-11-03 13:17   ` Vineeth Vijayan
2021-11-03 15:41     ` Cornelia Huck
2021-11-05 14:11       ` Vineeth Vijayan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ilxabm2r.fsf@redhat.com \
    --to=cohuck@redhat.com \
    --cc=linux-s390@vger.kernel.org \
    --cc=oberpar@linux.ibm.com \
    --cc=vneethv@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox