From: eric.auger@linaro.org (Eric Auger)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 3/4] VFIO: platform: populate the reset function on probe
Date: Thu, 11 Jun 2015 11:37:54 +0200 [thread overview]
Message-ID: <557956F2.5060206@linaro.org> (raw)
In-Reply-To: <1433949053.4927.167.camel@redhat.com>
Hi Alex,
On 06/10/2015 05:10 PM, Alex Williamson wrote:
> On Wed, 2015-06-10 at 13:44 +0200, Eric Auger wrote:
>> On 06/09/2015 08:26 PM, Alex Williamson wrote:
>>> On Fri, 2015-06-05 at 17:06 +0200, Eric Auger wrote:
>>>> The reset function lookup happens on vfio-platform probe. The reset
>>>> module load is requested and a reference to the function symbol is
>>>> hold. The reference is released on vfio-platform remove.
>>>>
>>>> Signed-off-by: Eric Auger <eric.auger@linaro.org>
>>>>
>>>> ---
>>>>
>>>> v1 -> v2:
>>>> - [get,put]_reset now is called once on probe/remove
>>>> - use request_module to automatically load the reset module that
>>>> matches the compatibility string
>>>> - lookup table is used instead of list
>>>> - remove registration mechanism: reset function name is stored in the
>>>> lookup table.
>>>> - use device_property_read_string instead of
>>>> device_property_read_string_array
>>>> ---
>>>> drivers/vfio/platform/vfio_platform_common.c | 48 +++++++++++++++++++++++++++-
>>>> 1 file changed, 47 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/vfio/platform/vfio_platform_common.c b/drivers/vfio/platform/vfio_platform_common.c
>>>> index 995929b..d474d6a 100644
>>>> --- a/drivers/vfio/platform/vfio_platform_common.c
>>>> +++ b/drivers/vfio/platform/vfio_platform_common.c
>>>> @@ -31,6 +31,47 @@ static const struct vfio_platform_reset_combo reset_lookup_table[] = {
>>>> },
>>>> };
>>>>
>>>> +static int vfio_platform_get_reset(struct vfio_platform_device *vdev,
>>>> + struct device *dev)
>>>> +{
>>>> + const char *compat;
>>>> + const struct vfio_platform_reset_combo *iter = reset_lookup_table;
>>>> + int (*reset)(struct vfio_platform_device *);
>>>> + int ret;
>>>> +
>>>> + vdev->type = VFIO_PLATFORM_RESET_TYPE_MAX;
>>>> + ret = device_property_read_string(dev, "compatible", &compat);
>>>> + if (ret)
>>>> + return ret;
>>>> +
>>>> + while (iter->type < VFIO_PLATFORM_RESET_TYPE_MAX) {
>>>> + if (!strcmp(iter->compat, compat)) {
>>>> + request_module(iter->module_name);
>>>> + reset = __symbol_get(iter->reset_function_name);
>>>
>>> symbol_get() appears to be the more robust and dominant interface for
>>> this, why use __symbol_get()?
>> I used this because it takes a const char * as an argument and this is
>> what I use as a datatype for storing the reset function name. Symbol_get
>> is provided with the symbol directly? It is also used
>> drivers/mtd/chips/gen_probe.c.
>
> But symbol_get() is just some macro wrappers around __symbol_get() that
> handles tool chains that precede symbols with underscores. I don't
> really know if that's still a concern, but are you sure it doesn't work?
I confirm it doesn't work due the (typeof(&x)) which in my case matches
a const char *.
drivers/vfio/platform/vfio_platform_common.c:45:10: warning: assignment
from incompatible pointer type [enabled by default]
reset = symbol_get(
#define symbol_get(x) ((typeof(&x))(__symbol_get(VMLINUX_SYMBOL_STR(x))))
Best Regards
Eric
>
>>>
>>>> + if (reset) {
>>>> + vdev->type = iter->type;
>>>> + vdev->reset = reset;
>>>> + return 0;
>>>> + }
>>>> + }
>>>> + iter++;
>>>> + }
>>>> + return -1;
>>>
>>> -ENODEV seems preferable to -1, but shouldn't this really be a void
>>> function?
>> yes indeed
>>>
>>>> +}
>>>> +
>>>> +static void vfio_platform_put_reset(struct vfio_platform_device *vdev)
>>>> +{
>>>> + const struct vfio_platform_reset_combo *iter = reset_lookup_table;
>>>> +
>>>> + while (iter->type < VFIO_PLATFORM_RESET_TYPE_MAX) {
>>>> + if (iter->type == vdev->type) {
>>>
>>> Again, I don't see the value in storing the enum, since the table is
>>> static, it could just as easily be the array index and avoid this loop,
>>> but we can avoid it anyway with symbol_put_addr().
>> yes you're definitively right!
>>
>> Thanks
>>
>> Eric
>>>
>>>> + __symbol_put(iter->reset_function_name);
>>>> + return;
>>>> + }
>>>> + iter++;
>>>> + }
>>>> +}
>>>> +
>>>> static int vfio_platform_regions_init(struct vfio_platform_device *vdev)
>>>> {
>>>> int cnt = 0, i;
>>>> @@ -519,6 +560,8 @@ int vfio_platform_probe_common(struct vfio_platform_device *vdev,
>>>> return ret;
>>>> }
>>>>
>>>> + vfio_platform_get_reset(vdev, dev);
>>>> +
>>>> mutex_init(&vdev->igate);
>>>>
>>>> return 0;
>>>> @@ -530,8 +573,11 @@ struct vfio_platform_device *vfio_platform_remove_common(struct device *dev)
>>>> struct vfio_platform_device *vdev;
>>>>
>>>> vdev = vfio_del_group_dev(dev);
>>>> - if (vdev)
>>>> +
>>>> + if (vdev) {
>>>> + vfio_platform_put_reset(vdev);
>>>> iommu_group_put(dev->iommu_group);
>>>> + }
>>>>
>>>> return vdev;
>>>> }
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>>
>
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Eric Auger <eric.auger@linaro.org>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: b.reynal@virtualopensystems.com, patches@linaro.org,
linux-kernel@vger.kernel.org, agraf@suse.de,
linux-arm-kernel@lists.infradead.org, eric.auger@st.com,
christoffer.dall@linaro.org
Subject: Re: [PATCH v2 3/4] VFIO: platform: populate the reset function on probe
Date: Thu, 11 Jun 2015 11:37:54 +0200 [thread overview]
Message-ID: <557956F2.5060206@linaro.org> (raw)
In-Reply-To: <1433949053.4927.167.camel@redhat.com>
Hi Alex,
On 06/10/2015 05:10 PM, Alex Williamson wrote:
> On Wed, 2015-06-10 at 13:44 +0200, Eric Auger wrote:
>> On 06/09/2015 08:26 PM, Alex Williamson wrote:
>>> On Fri, 2015-06-05 at 17:06 +0200, Eric Auger wrote:
>>>> The reset function lookup happens on vfio-platform probe. The reset
>>>> module load is requested and a reference to the function symbol is
>>>> hold. The reference is released on vfio-platform remove.
>>>>
>>>> Signed-off-by: Eric Auger <eric.auger@linaro.org>
>>>>
>>>> ---
>>>>
>>>> v1 -> v2:
>>>> - [get,put]_reset now is called once on probe/remove
>>>> - use request_module to automatically load the reset module that
>>>> matches the compatibility string
>>>> - lookup table is used instead of list
>>>> - remove registration mechanism: reset function name is stored in the
>>>> lookup table.
>>>> - use device_property_read_string instead of
>>>> device_property_read_string_array
>>>> ---
>>>> drivers/vfio/platform/vfio_platform_common.c | 48 +++++++++++++++++++++++++++-
>>>> 1 file changed, 47 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/vfio/platform/vfio_platform_common.c b/drivers/vfio/platform/vfio_platform_common.c
>>>> index 995929b..d474d6a 100644
>>>> --- a/drivers/vfio/platform/vfio_platform_common.c
>>>> +++ b/drivers/vfio/platform/vfio_platform_common.c
>>>> @@ -31,6 +31,47 @@ static const struct vfio_platform_reset_combo reset_lookup_table[] = {
>>>> },
>>>> };
>>>>
>>>> +static int vfio_platform_get_reset(struct vfio_platform_device *vdev,
>>>> + struct device *dev)
>>>> +{
>>>> + const char *compat;
>>>> + const struct vfio_platform_reset_combo *iter = reset_lookup_table;
>>>> + int (*reset)(struct vfio_platform_device *);
>>>> + int ret;
>>>> +
>>>> + vdev->type = VFIO_PLATFORM_RESET_TYPE_MAX;
>>>> + ret = device_property_read_string(dev, "compatible", &compat);
>>>> + if (ret)
>>>> + return ret;
>>>> +
>>>> + while (iter->type < VFIO_PLATFORM_RESET_TYPE_MAX) {
>>>> + if (!strcmp(iter->compat, compat)) {
>>>> + request_module(iter->module_name);
>>>> + reset = __symbol_get(iter->reset_function_name);
>>>
>>> symbol_get() appears to be the more robust and dominant interface for
>>> this, why use __symbol_get()?
>> I used this because it takes a const char * as an argument and this is
>> what I use as a datatype for storing the reset function name. Symbol_get
>> is provided with the symbol directly? It is also used
>> drivers/mtd/chips/gen_probe.c.
>
> But symbol_get() is just some macro wrappers around __symbol_get() that
> handles tool chains that precede symbols with underscores. I don't
> really know if that's still a concern, but are you sure it doesn't work?
I confirm it doesn't work due the (typeof(&x)) which in my case matches
a const char *.
drivers/vfio/platform/vfio_platform_common.c:45:10: warning: assignment
from incompatible pointer type [enabled by default]
reset = symbol_get(
#define symbol_get(x) ((typeof(&x))(__symbol_get(VMLINUX_SYMBOL_STR(x))))
Best Regards
Eric
>
>>>
>>>> + if (reset) {
>>>> + vdev->type = iter->type;
>>>> + vdev->reset = reset;
>>>> + return 0;
>>>> + }
>>>> + }
>>>> + iter++;
>>>> + }
>>>> + return -1;
>>>
>>> -ENODEV seems preferable to -1, but shouldn't this really be a void
>>> function?
>> yes indeed
>>>
>>>> +}
>>>> +
>>>> +static void vfio_platform_put_reset(struct vfio_platform_device *vdev)
>>>> +{
>>>> + const struct vfio_platform_reset_combo *iter = reset_lookup_table;
>>>> +
>>>> + while (iter->type < VFIO_PLATFORM_RESET_TYPE_MAX) {
>>>> + if (iter->type == vdev->type) {
>>>
>>> Again, I don't see the value in storing the enum, since the table is
>>> static, it could just as easily be the array index and avoid this loop,
>>> but we can avoid it anyway with symbol_put_addr().
>> yes you're definitively right!
>>
>> Thanks
>>
>> Eric
>>>
>>>> + __symbol_put(iter->reset_function_name);
>>>> + return;
>>>> + }
>>>> + iter++;
>>>> + }
>>>> +}
>>>> +
>>>> static int vfio_platform_regions_init(struct vfio_platform_device *vdev)
>>>> {
>>>> int cnt = 0, i;
>>>> @@ -519,6 +560,8 @@ int vfio_platform_probe_common(struct vfio_platform_device *vdev,
>>>> return ret;
>>>> }
>>>>
>>>> + vfio_platform_get_reset(vdev, dev);
>>>> +
>>>> mutex_init(&vdev->igate);
>>>>
>>>> return 0;
>>>> @@ -530,8 +573,11 @@ struct vfio_platform_device *vfio_platform_remove_common(struct device *dev)
>>>> struct vfio_platform_device *vdev;
>>>>
>>>> vdev = vfio_del_group_dev(dev);
>>>> - if (vdev)
>>>> +
>>>> + if (vdev) {
>>>> + vfio_platform_put_reset(vdev);
>>>> iommu_group_put(dev->iommu_group);
>>>> + }
>>>>
>>>> return vdev;
>>>> }
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>>
>
>
>
next prev parent reply other threads:[~2015-06-11 9:37 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-05 15:06 [PATCH v2 0/4] VFIO platform reset Eric Auger
2015-06-05 15:06 ` Eric Auger
2015-06-05 15:06 ` [PATCH v2 1/4] VFIO: platform: add reset struct and lookup table Eric Auger
2015-06-05 15:06 ` Eric Auger
2015-06-09 18:26 ` Alex Williamson
2015-06-09 18:26 ` Alex Williamson
2015-06-10 11:45 ` Eric Auger
2015-06-10 11:45 ` Eric Auger
2015-06-05 15:06 ` [PATCH v2 2/4] VFIO: platform: add reset callback Eric Auger
2015-06-05 15:06 ` Eric Auger
2015-06-05 15:06 ` [PATCH v2 3/4] VFIO: platform: populate the reset function on probe Eric Auger
2015-06-05 15:06 ` Eric Auger
2015-06-09 18:26 ` Alex Williamson
2015-06-09 18:26 ` Alex Williamson
2015-06-10 11:44 ` Eric Auger
2015-06-10 11:44 ` Eric Auger
2015-06-10 15:10 ` Alex Williamson
2015-06-10 15:10 ` Alex Williamson
2015-06-10 15:13 ` Eric Auger
2015-06-10 15:13 ` Eric Auger
2015-06-11 9:37 ` Eric Auger [this message]
2015-06-11 9:37 ` Eric Auger
2015-06-05 15:06 ` [PATCH v2 4/4] VFIO: platform: Calxeda xgmac reset module Eric Auger
2015-06-05 15:06 ` Eric Auger
2015-06-06 12:57 ` Paul Bolle
2015-06-06 12:57 ` Paul Bolle
2015-06-08 8:02 ` Eric Auger
2015-06-08 8:02 ` Eric Auger
2015-06-05 18:05 ` [PATCH v2 0/4] VFIO platform reset Rob Herring
2015-06-05 18:05 ` Rob Herring
2015-06-05 21:14 ` Scott Wood
2015-06-05 21:14 ` Scott Wood
2015-06-08 7:51 ` Eric Auger
2015-06-08 7:51 ` Eric Auger
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=557956F2.5060206@linaro.org \
--to=eric.auger@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
/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.