> From: Eric Farman <farman@xxxxxxxxxxxxx>
> Sent: Thursday, August 18, 2022 9:24 PM
>
> On Thu, 2022-08-18 at 06:53 +0000, Tian, Kevin wrote:
> > Hi, Eric,
> >
> > > From: Eric Farman
> > > Sent: Tuesday, July 26, 2022 11:37 PM
> > >
> > > --- a/drivers/s390/cio/vfio_ccw_private.h
> > > +++ b/drivers/s390/cio/vfio_ccw_private.h
> > > @@ -111,6 +111,10 @@ struct vfio_ccw_private {
> > > struct eventfd_ctx *req_trigger;
> > > struct work_struct io_work;
> > > struct work_struct crw_work;
> > > +
> > > + struct mdev_parent parent;
> > > + struct mdev_type mdev_type;
> > > + struct mdev_type *mdev_types[1];
> > > } __aligned(8);
> > >
> >
> > IMHO creating a separate structure to encapsulate parent related
> > information is far cleaner than mixing both mdev and parent into
> > one structure.
> >
> > mdev and parent have different life cycles. mdev is between
> > mdev probe/remove while parent is between css probe/remove.
>
> I don't disagree with any of that. My point with the suggested patch
> was a way to get this working without disrupting the cio's subchannel
> (which is used for many non-mdev things).
ok
>
> Un-mixing the mdev from the parent stuff wouldn't be impossible, but
> requires consideration I haven't had the bandwidth to do (which is why
> the cleanup you reference below was dropped from later versions of that
> series [3]).
>
Could you help take a look at [1] which introduces a workaround for ccw
so struct device can be introduced to vfio_device now instead of being
blocked by this un-mixing task?
[1] https://lore.kernel.org/lkml/20220827171037.30297-14-kevin.tian@xxxxxxxxx/
