On Wed, 25 Mar 2020 22:09:40 -0400 Eric Farman <farman@xxxxxxxxxxxxx> wrote: > On 3/24/20 11:58 AM, Cornelia Huck wrote: > > On Fri, 14 Feb 2020 11:35:21 -0500 > > Eric Farman <farman@xxxxxxxxxxxxx> wrote: > > > >> On 2/14/20 7:11 AM, Cornelia Huck wrote: > >>> On Thu, 6 Feb 2020 22:38:18 +0100 > >>> Eric Farman <farman@xxxxxxxxxxxxx> wrote: > >>>> + case CHP_ONLINE: > >>>> + /* Path became available */ > >>>> + sch->lpm |= mask & sch->opm; > >>> > >>> If I'm not mistaken, this patch introduces the first usage of sch->opm > >>> in the vfio-ccw code. > >> > >> Correct. > >> > >>> Are we missing something? > >> > >> Maybe? :) > >> > >>> Or am I missing > >>> something? :) > >>> > >> > >> Since it's only used in this code, for acting as a step between > >> vary/config off/on, maybe this only needs to be dealing with the lpm > >> field itself? > > > > Ok, I went over this again and also looked at what the standard I/O > > subchannel driver does, and I think this is fine, as the lpm basically > > factors in the opm already. (Will need to keep this in mind for the > > following patches.) > > Just to make sure I don't misunderstand, when you say "I think this is > fine" ... Do you mean keeping the opm field within vfio-ccw, as this > patch does? Or removing it, and only adjusting the lpm within vfio-ccw, > as I suggested in my response just above? I meant the code change done in this patch: We update the lpm whenever the opm is changed, and use the lpm. I'd like to keep the opm separate, just so that we are clear where each value comes from.
