On 3/26/20 2:47 AM, Cornelia Huck wrote: > 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. > Great. Thanks for that clarification.
