From: Cornelia Huck <cohuck@redhat.com>
To: Pierre Morel <pmorel@linux.ibm.com>
Cc: borntraeger@de.ibm.com, alex.williamson@redhat.com,
linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
kvm@vger.kernel.org, frankja@linux.ibm.com,
akrowiak@linux.ibm.com, pasic@linux.ibm.com, david@redhat.com,
schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com,
freude@linux.ibm.com, mimu@linux.ibm.com
Subject: Re: [PATCH v3 1/9] s390: vfio_ap: link the vfio_ap devices to the vfio_ap bus subsystem
Date: Thu, 14 Feb 2019 17:57:30 +0100 [thread overview]
Message-ID: <20190214175730.4ab609ae.cohuck@redhat.com> (raw)
In-Reply-To: <9403117a-04a6-8f69-2a61-f96d35a59555@linux.ibm.com>
On Thu, 14 Feb 2019 16:47:30 +0100
Pierre Morel <pmorel@linux.ibm.com> wrote:
> On 14/02/2019 15:54, Cornelia Huck wrote:
> > On Thu, 14 Feb 2019 14:51:01 +0100
> > Pierre Morel <pmorel@linux.ibm.com> wrote:
> >> +++ b/drivers/s390/crypto/vfio_ap_drv.c
> >> @@ -24,8 +24,9 @@ MODULE_LICENSE("GPL v2");
> >>
> >> static struct ap_driver vfio_ap_drv;
> >>
> >> -static struct device_type vfio_ap_dev_type = {
> >> - .name = VFIO_AP_DEV_TYPE_NAME,
> >> +struct matrix_driver {
> >> + struct device_driver drv;
> >> + int device_count;
> >
> > This counter basically ensures that at most one device may bind with
> > this driver... you'd still have that device on the bus, though.
>
> yes, this is what is wanted: this driver can only support one device.
> May be another matrix driver can support one or more other devices.
>
> I should update comment message my be.
>
> >
> >> };
> >>
> >> struct ap_matrix_dev *matrix_dev;
>
> >>
> >> - matrix_dev->device.type = &vfio_ap_dev_type;
> >> dev_set_name(&matrix_dev->device, "%s", VFIO_AP_DEV_NAME);
> >> matrix_dev->device.parent = root_device;
> >> + matrix_dev->device.bus = &matrix_bus;
> >> matrix_dev->device.release = vfio_ap_matrix_dev_release;
> >> - matrix_dev->device.driver = &vfio_ap_drv.driver;
> >> + matrix_dev->vfio_ap_drv = &vfio_ap_drv;
> >
> > Can't you get that structure through matrix_dev->device.driver instead
> > when you need it in the function below?
>
> Not anymore.
> We have two different drivers and devices
> matrix_drv <-> matrix_dev
> and
> vfio_ap_drv <-> ap_devices
>
> The driver behind the matrix_dev->dev->driver is matrix_drv
> what is needed here is vfio_ap_drv.
Wait, we had tacked a driver for ap devices unto a matrix device, which
is not on the ap bus? Maybe that's what trips libudev?
(And reading further in the current code, it seems we clear that
structure _after_ the matrix device had been setup, so how can that
even work? Where am I confused?)
>
> >
> >>
> >> ret = device_register(&matrix_dev->device);
> >> if (ret)
> >> goto matrix_reg_err;
> >>
> >> + ret = driver_register(&matrix_driver.drv);
> >> + if (ret)
> >> + goto matrix_drv_err;
> >> +
> >
> > As you already have several structures that can be registered exactly
> > once (the root device, the bus, the driver, ...), you can already be
> > sure that there's only one device on the bus, can't you?
>
> hum, no I don't think so, no device can register before this module is
> loaded, but what does prevent a device to register later from another
> module?
Not unless you export the interface, I guess.
next prev parent reply other threads:[~2019-02-14 16:57 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-14 13:51 [PATCH v3 0/9] [RFC] vfio: ap: ioctl definitions for AP Queue Interrupt Control Pierre Morel
2019-02-14 13:51 ` [PATCH v3 1/9] s390: vfio_ap: link the vfio_ap devices to the vfio_ap bus subsystem Pierre Morel
2019-02-14 14:54 ` Cornelia Huck
2019-02-14 15:05 ` Christian Borntraeger
2019-02-14 15:40 ` Cornelia Huck
2019-02-14 17:12 ` Tony Krowiak
2019-02-14 17:35 ` Pierre Morel
2019-02-14 15:47 ` Pierre Morel
2019-02-14 16:57 ` Cornelia Huck [this message]
2019-02-14 17:36 ` Pierre Morel
2019-02-14 18:30 ` Tony Krowiak
2019-02-15 9:11 ` Cornelia Huck
2019-02-15 21:59 ` Tony Krowiak
2019-02-18 12:01 ` Cornelia Huck
2019-02-18 16:35 ` Tony Krowiak
2019-02-18 16:57 ` Cornelia Huck
2019-02-19 22:27 ` Tony Krowiak
2019-02-20 9:05 ` Cornelia Huck
2019-02-14 15:01 ` Christian Borntraeger
2019-02-14 15:09 ` Pierre Morel
2019-02-14 13:51 ` [PATCH v3 2/9] s390: ap: kvm: setting a hook for PQAP instructions Pierre Morel
2019-02-14 15:54 ` Cornelia Huck
2019-02-14 16:45 ` Pierre Morel
2019-02-15 9:26 ` Cornelia Huck
2019-02-15 9:55 ` Pierre Morel
2019-02-15 22:02 ` Tony Krowiak
2019-02-18 18:29 ` Pierre Morel
2019-02-18 22:42 ` Cornelia Huck
2019-02-19 19:50 ` Pierre Morel
2019-02-19 22:36 ` Tony Krowiak
2019-02-21 12:40 ` Pierre Morel
2019-02-19 22:50 ` Tony Krowiak
2019-02-14 13:51 ` [PATCH v3 3/9] s390: ap: new vfio_ap_queue structure Pierre Morel
2019-02-15 9:37 ` Cornelia Huck
2019-02-15 9:58 ` Pierre Morel
2019-02-14 13:51 ` [PATCH v3 4/9] s390: ap: tools to find a queue with a specific APQN Pierre Morel
2019-02-15 9:49 ` Cornelia Huck
2019-02-15 10:10 ` Pierre Morel
2019-02-15 10:24 ` Cornelia Huck
2019-02-15 22:13 ` Tony Krowiak
2019-02-18 12:21 ` Cornelia Huck
2019-02-18 18:32 ` Pierre Morel
2019-02-22 15:04 ` Tony Krowiak
2019-02-14 13:51 ` [PATCH v3 5/9] s390: ap: tools to associate a queue to a matrix Pierre Morel
2019-02-15 22:30 ` Tony Krowiak
2019-02-18 18:36 ` Pierre Morel
2019-02-14 13:51 ` [PATCH v3 6/9] vfio: ap: register IOMMU VFIO notifier Pierre Morel
2019-02-15 22:55 ` Tony Krowiak
2019-02-19 9:59 ` Halil Pasic
2019-02-19 19:04 ` Pierre Morel
2019-02-19 21:33 ` Tony Krowiak
2019-02-19 18:51 ` Pierre Morel
2019-02-14 13:51 ` [PATCH v3 7/9] s390: ap: implement PAPQ AQIC interception in kernel Pierre Morel
2019-02-15 23:11 ` Tony Krowiak
2019-02-19 19:16 ` Pierre Morel
2019-02-20 11:54 ` Halil Pasic
2019-02-21 12:50 ` Pierre Morel
2019-02-14 13:51 ` [PATCH v3 8/9] s390: ap: Cleanup on removing the AP device Pierre Morel
2019-02-15 23:29 ` Tony Krowiak
2019-02-19 19:29 ` Pierre Morel
2019-02-15 23:36 ` Tony Krowiak
2019-02-19 19:41 ` Pierre Morel
2019-02-14 13:51 ` [PATCH v3 9/9] s390: ap: kvm: add AP Queue Interruption Control facility Pierre Morel
2019-02-14 20:33 ` [PATCH v3 0/9] [RFC] vfio: ap: ioctl definitions for AP Queue Interrupt Control Tony Krowiak
2019-02-15 8:44 ` Pierre Morel
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=20190214175730.4ab609ae.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=akrowiak@linux.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=david@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=freude@linux.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mimu@linux.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=pmorel@linux.ibm.com \
--cc=schwidefsky@de.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.