From: Halil Pasic <pasic@linux.ibm.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: Vineeth Vijayan <vneethv@linux.ibm.com>,
Vineeth Vijayan <vneethv@linux.vnet.ibm.com>,
oberpar@linux.ibm.com, linux-s390@vger.kernel.org,
farman@linux.ibm.com, fiuczy@linux.ibm.com
Subject: Re: [RFC 1/1] s390/cio: Remove uevent-suppress from css driver
Date: Mon, 21 Dec 2020 17:51:17 +0100 [thread overview]
Message-ID: <20201221175117.2c5f5fcb.pasic@linux.ibm.com> (raw)
In-Reply-To: <20201221164634.11cd3813.cohuck@redhat.com>
On Mon, 21 Dec 2020 16:46:34 +0100
Cornelia Huck <cohuck@redhat.com> wrote:
> On Sat, 19 Dec 2020 07:33:16 +0100
> Halil Pasic <pasic@linux.ibm.com> wrote:
>
> > I finally came around to test this. In my experience driverctl works for
> > subchannels and vfio_ccw without this patch, and continues to work with
> > it. I found the code in driverctl that does the unbind and the implicit
> > bind (via drivers_probe after after driver_override was set).
> >
> > So now I have to ask, how exactly was the original problem diagnosed?
> >
> > In https://marc.info/?l=linux-s390&m=158591045732735&w=2 there is a
> > paragraph like:
> >
> > """
> > So while there's definitely a good reason for wanting to delay uevents,
> > it is also introducing problems. One is udev rules for subchannels that
> > are supposed to do something before a driver binds (e.g. setting
> > driver_override to bind an I/O subchannel to vfio_ccw instead of
> > io_subchannel) are not effective, as the ADD uevent will only be
> > generated when the io_subchannel driver is already done with doing all
> > setup. Another one is that only the ADD uevent is generated after
> > uevent suppression is lifted; any other uevents that might have been
> > generated are lost.
> > """
> >
> > This is not how driverclt works! I.e. it deals with the situation that
> > the I/O subchannel was already bound to the io_subchannel driver at
> > the time the udev rule installed by driverctl activates (via the
> > mechanism I described above).
>
> That's... weird. It definitely did not work on the LPAR I initially
> tried it out on!
>
I think Boris told me some weeks ago that it didn't work for him either.
I will check with him after the winter sleep.
> However, I think removing the suppression still looks like a good idea:
> we still have the "any uevent other than ADD will have been lost"
> problem.
>
I agree. I didn't look into the details, in general I think removing
quirks specific to 390 (when possible) is a good thing.
Regards,
Halil
next prev parent reply other threads:[~2020-12-21 16:52 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-24 9:34 [RFC 0/1] Remove uevent suppression logic from css driver Vineeth Vijayan
2020-11-24 9:34 ` [RFC 1/1] s390/cio: Remove uevent-suppress " Vineeth Vijayan
2020-11-24 13:02 ` Cornelia Huck
2020-11-25 9:40 ` Vineeth Vijayan
2020-12-07 8:09 ` Vineeth Vijayan
2020-12-08 17:30 ` Cornelia Huck
2020-12-09 12:52 ` Halil Pasic
2020-12-15 18:13 ` Cornelia Huck
2020-12-19 6:33 ` Halil Pasic
2020-12-21 15:46 ` Cornelia Huck
2020-12-21 16:51 ` Halil Pasic [this message]
2021-01-14 13:03 ` Boris Fiuczynski
2021-01-19 11:47 ` Halil Pasic
2021-01-19 11:59 ` Cornelia Huck
2021-01-19 12:18 ` Vineeth Vijayan
[not found] ` <89146a87-371a-f148-057b-d3b7ce0cc21e@linux.ibm.com>
[not found] ` <20201216130710.5aa6a933.cohuck@redhat.com>
2020-12-19 7:20 ` Halil Pasic
2020-12-21 15:52 ` Cornelia Huck
2020-12-21 17:23 ` Halil Pasic
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=20201221175117.2c5f5fcb.pasic@linux.ibm.com \
--to=pasic@linux.ibm.com \
--cc=cohuck@redhat.com \
--cc=farman@linux.ibm.com \
--cc=fiuczy@linux.ibm.com \
--cc=linux-s390@vger.kernel.org \
--cc=oberpar@linux.ibm.com \
--cc=vneethv@linux.ibm.com \
--cc=vneethv@linux.vnet.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