All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Auger <eric.auger@linaro.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: thomas.lendacky@amd.com, kvm@vger.kernel.org, patches@linaro.org,
	linux-kernel@vger.kernel.org,
	Alex Williamson <alex.williamson@redhat.com>,
	suravee.suthikulpanit@amd.com, eric.auger@st.com,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] VFIO: platform: AMD xgbe reset module
Date: Fri, 16 Oct 2015 15:56:03 +0200	[thread overview]
Message-ID: <562101F3.6050601@linaro.org> (raw)
In-Reply-To: <3768580.4oTvTNW7Bh@wuerfel>

Hi Arnd,
On 10/16/2015 03:26 PM, Arnd Bergmann wrote:
> On Friday 16 October 2015 15:06:45 Eric Auger wrote:
> 
>>  I've since forgotten his answer, but the fact that
>>> __symbol_get() is only defined for modules makes it moot, we either need
>>> to make symbol_get() work or define __symbol_get() for non-module
>>> builds.
>> I currently don't see any solution for any of those. The only solution I
>> can see is someone registers the reset function pointer to vfio.
>>
>> I think we could keep the existing reset modules, do the request_module
>> from VFIO, using their module name registered in the lookup table. But
>> instead of having the reset function in the look-up table we would have
>> the reset modules register their reset function pointer to VFIO. I think
>> this could work around the symbol_get issue.
>>
>> This still leaves the layer violation argument though.
>>
>> Assuming this works, would that be an acceptable solution, although I
>> acknowledge this does not perfectly fit into the driver model?
> 
> I think it's possible to avoid the layering violation that way too,
> by loading the module based on the compatible string, with a module_alias.
> 
> static void vfio_platform_get_reset(struct vfio_platform_device *vdev,
>                                     struct device *dev)
> {
>         const char *compat;
>         int (*reset)(struct vfio_platform_device *);
>         int ret, i;
> 	char modname[256];
> 
>         ret = device_property_read_string(dev, "compatible", &compat);
>         if (ret)
>                 return;
> 
> 	reset = vfio_platform_lookup_reset(compat);
> 	if (!reset) {
> 		snprintf(modname, "vfio-reset:%s", compat);
> 		request_module(modname);
> 		reset = vfio_platform_lookup_reset(compat);
> 	}
> 
> 	vdev->reset = reset;
> }
> 
> ---
> 
> #define module_vfio_reset_handler(compat, reset)			\
> MODULE_ALIAS("vfio_reset" compat);					\
> static int reset ## _module_init(void)					\
> {									\
> 	return vfio_reset_register(THIS_MODULE, compat, &reset);	\
> }
> 
> I think that solution is good enough, as it avoids most of the
> problems with the current implementation but is a simple enough change.

That looks a good perspective. Thanks for the hint! Let's code now ;-)

Best Regards

Eric


> 
> 	Arnd
> 

WARNING: multiple messages have this Message-ID (diff)
From: eric.auger@linaro.org (Eric Auger)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] VFIO: platform: AMD xgbe reset module
Date: Fri, 16 Oct 2015 15:56:03 +0200	[thread overview]
Message-ID: <562101F3.6050601@linaro.org> (raw)
In-Reply-To: <3768580.4oTvTNW7Bh@wuerfel>

Hi Arnd,
On 10/16/2015 03:26 PM, Arnd Bergmann wrote:
> On Friday 16 October 2015 15:06:45 Eric Auger wrote:
> 
>>  I've since forgotten his answer, but the fact that
>>> __symbol_get() is only defined for modules makes it moot, we either need
>>> to make symbol_get() work or define __symbol_get() for non-module
>>> builds.
>> I currently don't see any solution for any of those. The only solution I
>> can see is someone registers the reset function pointer to vfio.
>>
>> I think we could keep the existing reset modules, do the request_module
>> from VFIO, using their module name registered in the lookup table. But
>> instead of having the reset function in the look-up table we would have
>> the reset modules register their reset function pointer to VFIO. I think
>> this could work around the symbol_get issue.
>>
>> This still leaves the layer violation argument though.
>>
>> Assuming this works, would that be an acceptable solution, although I
>> acknowledge this does not perfectly fit into the driver model?
> 
> I think it's possible to avoid the layering violation that way too,
> by loading the module based on the compatible string, with a module_alias.
> 
> static void vfio_platform_get_reset(struct vfio_platform_device *vdev,
>                                     struct device *dev)
> {
>         const char *compat;
>         int (*reset)(struct vfio_platform_device *);
>         int ret, i;
> 	char modname[256];
> 
>         ret = device_property_read_string(dev, "compatible", &compat);
>         if (ret)
>                 return;
> 
> 	reset = vfio_platform_lookup_reset(compat);
> 	if (!reset) {
> 		snprintf(modname, "vfio-reset:%s", compat);
> 		request_module(modname);
> 		reset = vfio_platform_lookup_reset(compat);
> 	}
> 
> 	vdev->reset = reset;
> }
> 
> ---
> 
> #define module_vfio_reset_handler(compat, reset)			\
> MODULE_ALIAS("vfio_reset" compat);					\
> static int reset ## _module_init(void)					\
> {									\
> 	return vfio_reset_register(THIS_MODULE, compat, &reset);	\
> }
> 
> I think that solution is good enough, as it avoids most of the
> problems with the current implementation but is a simple enough change.

That looks a good perspective. Thanks for the hint! Let's code now ;-)

Best Regards

Eric


> 
> 	Arnd
> 

WARNING: multiple messages have this Message-ID (diff)
From: Eric Auger <eric.auger@linaro.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Alex Williamson <alex.williamson@redhat.com>,
	Christoffer Dall <christoffer.dall@linaro.org>,
	linux-arm-kernel@lists.infradead.org, eric.auger@st.com,
	b.reynal@virtualopensystems.com, kvmarm@lists.cs.columbia.edu,
	kvm@vger.kernel.org, thomas.lendacky@amd.com, patches@linaro.org,
	suravee.suthikulpanit@amd.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] VFIO: platform: AMD xgbe reset module
Date: Fri, 16 Oct 2015 15:56:03 +0200	[thread overview]
Message-ID: <562101F3.6050601@linaro.org> (raw)
In-Reply-To: <3768580.4oTvTNW7Bh@wuerfel>

Hi Arnd,
On 10/16/2015 03:26 PM, Arnd Bergmann wrote:
> On Friday 16 October 2015 15:06:45 Eric Auger wrote:
> 
>>  I've since forgotten his answer, but the fact that
>>> __symbol_get() is only defined for modules makes it moot, we either need
>>> to make symbol_get() work or define __symbol_get() for non-module
>>> builds.
>> I currently don't see any solution for any of those. The only solution I
>> can see is someone registers the reset function pointer to vfio.
>>
>> I think we could keep the existing reset modules, do the request_module
>> from VFIO, using their module name registered in the lookup table. But
>> instead of having the reset function in the look-up table we would have
>> the reset modules register their reset function pointer to VFIO. I think
>> this could work around the symbol_get issue.
>>
>> This still leaves the layer violation argument though.
>>
>> Assuming this works, would that be an acceptable solution, although I
>> acknowledge this does not perfectly fit into the driver model?
> 
> I think it's possible to avoid the layering violation that way too,
> by loading the module based on the compatible string, with a module_alias.
> 
> static void vfio_platform_get_reset(struct vfio_platform_device *vdev,
>                                     struct device *dev)
> {
>         const char *compat;
>         int (*reset)(struct vfio_platform_device *);
>         int ret, i;
> 	char modname[256];
> 
>         ret = device_property_read_string(dev, "compatible", &compat);
>         if (ret)
>                 return;
> 
> 	reset = vfio_platform_lookup_reset(compat);
> 	if (!reset) {
> 		snprintf(modname, "vfio-reset:%s", compat);
> 		request_module(modname);
> 		reset = vfio_platform_lookup_reset(compat);
> 	}
> 
> 	vdev->reset = reset;
> }
> 
> ---
> 
> #define module_vfio_reset_handler(compat, reset)			\
> MODULE_ALIAS("vfio_reset" compat);					\
> static int reset ## _module_init(void)					\
> {									\
> 	return vfio_reset_register(THIS_MODULE, compat, &reset);	\
> }
> 
> I think that solution is good enough, as it avoids most of the
> problems with the current implementation but is a simple enough change.

That looks a good perspective. Thanks for the hint! Let's code now ;-)

Best Regards

Eric


> 
> 	Arnd
> 


  reply	other threads:[~2015-10-16 13:53 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-14 15:33 [PATCH] VFIO: platform: AMD xgbe reset module Eric Auger
2015-10-14 15:33 ` Eric Auger
2015-10-14 15:33 ` Eric Auger
2015-10-14 15:38 ` Arnd Bergmann
2015-10-14 15:38   ` Arnd Bergmann
2015-10-15  8:08   ` Eric Auger
2015-10-15  8:08     ` Eric Auger
2015-10-15  8:08     ` Eric Auger
2015-10-15 11:21     ` Arnd Bergmann
2015-10-15 11:21       ` Arnd Bergmann
2015-10-15 11:21       ` Arnd Bergmann
2015-10-15 12:12       ` Christoffer Dall
2015-10-15 12:12         ` Christoffer Dall
2015-10-15 13:59         ` Arnd Bergmann
2015-10-15 13:59           ` Arnd Bergmann
2015-10-15 13:59           ` Arnd Bergmann
2015-10-15 14:46           ` Eric Auger
2015-10-15 14:46             ` Eric Auger
2015-10-15 14:46             ` Eric Auger
2015-10-15 14:55             ` Arnd Bergmann
2015-10-15 14:55               ` Arnd Bergmann
2015-10-15 14:55               ` Arnd Bergmann
2015-10-15 15:03               ` Christoffer Dall
2015-10-15 15:03                 ` Christoffer Dall
2015-10-15 15:49                 ` Arnd Bergmann
2015-10-15 15:49                   ` Arnd Bergmann
2015-10-15 15:49                   ` Arnd Bergmann
2015-10-15 16:35                   ` Christoffer Dall
2015-10-15 16:35                     ` Christoffer Dall
2015-10-15 16:53             ` Alex Williamson
2015-10-15 16:53               ` Alex Williamson
2015-10-15 16:53               ` Alex Williamson
2015-10-15 19:42               ` Christoffer Dall
2015-10-15 19:42                 ` Christoffer Dall
2015-10-15 19:42                 ` Christoffer Dall
2015-10-15 20:26                 ` Alex Williamson
2015-10-15 20:26                   ` Alex Williamson
2015-10-15 20:26                   ` Alex Williamson
2015-10-16 13:06               ` Eric Auger
2015-10-16 13:06                 ` Eric Auger
2015-10-16 13:06                 ` Eric Auger
2015-10-16 13:26                 ` Arnd Bergmann
2015-10-16 13:26                   ` Arnd Bergmann
2015-10-16 13:26                   ` Arnd Bergmann
2015-10-16 13:56                   ` Eric Auger [this message]
2015-10-16 13:56                     ` Eric Auger
2015-10-16 13:56                     ` Eric Auger
2015-10-15 14:20         ` Eric Auger
2015-10-15 14:20           ` Eric Auger
2015-10-15 14:20           ` Eric Auger
2015-10-15 14:28           ` Arnd Bergmann
2015-10-15 14:28             ` Arnd Bergmann
2015-10-15 14:28             ` Arnd Bergmann

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=562101F3.6050601@linaro.org \
    --to=eric.auger@linaro.org \
    --cc=alex.williamson@redhat.com \
    --cc=arnd@arndb.de \
    --cc=eric.auger@st.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patches@linaro.org \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=thomas.lendacky@amd.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.