All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sinan Kaya <okaya@codeaurora.org>
To: Eric Auger <eric.auger@linaro.org>,
	kvm@vger.kernel.org, timur@codeaurora.org, cov@codeaurora.org,
	jcm@redhat.com
Cc: shankerd@codeaurora.org, vikrams@codeaurora.org,
	marc.zyngier@arm.com, mark.rutland@arm.com,
	devicetree@vger.kernel.org, vinod.koul@intel.com,
	agross@codeaurora.org, linux-arm-msm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Baptiste Reynal <b.reynal@virtualopensystems.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Arnd Bergmann <arnd@arndb.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] vfio, platform: add support for ACPI while detecting the reset driver
Date: Thu, 10 Mar 2016 12:13:28 -0500	[thread overview]
Message-ID: <56E1AB38.8020702@codeaurora.org> (raw)
In-Reply-To: <56E14858.9050401@linaro.org>

On 3/10/2016 5:11 AM, Eric Auger wrote:
> Hi Sinan,
> On 03/08/2016 04:33 PM, Sinan Kaya wrote:
>> The  code is using the compatible DT string to associate a reset driver with
>> the actual device itself. The compatible string does not exist on ACPI
>> based systems. HID is the unique identifier for a device driver instead.
>> The change allows a driver to register with DT compatible string or ACPI
>> HID and then match the object with one of these conditions.
>>
>> Rules for loading the reset driver are as follow:
>> - ACPI HID needs match for ACPI systems
>> - DT compat needs to match for OF systems
>>
>> Tested-by: Eric Auger <eric.auger@linaro.org> (device tree only)
>> Tested-by: Shanker Donthineni <shankerd@codeaurora.org> (ACPI only)
>> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>> ---
>>  .../vfio/platform/reset/vfio_platform_amdxgbe.c    |   4 +-
>>  .../platform/reset/vfio_platform_calxedaxgmac.c    |   4 +-
>>  drivers/vfio/platform/vfio_platform_common.c       | 112 +++++++++++++++++----
>>  drivers/vfio/platform/vfio_platform_private.h      |  43 ++++----
>>  4 files changed, 125 insertions(+), 38 deletions(-)
>>
>> diff --git a/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c b/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c
>> index d4030d0..170dcf5 100644
>> --- a/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c
>> +++ b/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c
>> @@ -119,7 +119,9 @@ int vfio_platform_amdxgbe_reset(struct vfio_platform_device *vdev)
>>  	return 0;
>>  }
>>  
>> -module_vfio_reset_handler("amd,xgbe-seattle-v1a", vfio_platform_amdxgbe_reset);
>> +module_vfio_reset_handler("amd,xgbe-seattle-v1a", NULL,
>> +			  vfio_platform_amdxgbe_reset);
>> +VFIO_PLATFORM_MODULE_ALIAS("amd,xgbe-seattle-v1a");
> Looks the other overridden MODULE_ALIAS have a naming like
> MODULE_ALIAS_something? what about MODULE_ALIAS_VFIO_PLATFORM_RESET?
> not very compact but maybe closer to what it stands for.

alright, I'll follow that.

>>  
>>  MODULE_VERSION("0.1");
>>  MODULE_LICENSE("GPL v2");
>> diff --git a/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c b/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
>> index e3d3d94..635c6e0 100644
>> --- a/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
>> +++ b/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
>> @@ -77,7 +77,9 @@ int vfio_platform_calxedaxgmac_reset(struct vfio_platform_device *vdev)
>>  	return 0;
>>  }
>>  
>> -module_vfio_reset_handler("calxeda,hb-xgmac", vfio_platform_calxedaxgmac_reset);
>> +module_vfio_reset_handler("calxeda,hb-xgmac", NULL,
>> +			  vfio_platform_calxedaxgmac_reset);
>> +VFIO_PLATFORM_MODULE_ALIAS("calxeda,hb-xgmac");
>>  
>>  MODULE_VERSION(DRIVER_VERSION);
>>  MODULE_LICENSE("GPL v2");
>> diff --git a/drivers/vfio/platform/vfio_platform_common.c b/drivers/vfio/platform/vfio_platform_common.c
>> index 418cdd9..c758e72 100644
>> --- a/drivers/vfio/platform/vfio_platform_common.c
>> +++ b/drivers/vfio/platform/vfio_platform_common.c
>> @@ -13,6 +13,7 @@
>>   */
>>  
>>  #include <linux/device.h>
>> +#include <linux/acpi.h>
>>  #include <linux/iommu.h>
>>  #include <linux/module.h>
>>  #include <linux/mutex.h>
>> @@ -31,14 +32,22 @@ static LIST_HEAD(reset_list);
>>  static DEFINE_MUTEX(driver_lock);
>>  
>>  static vfio_platform_reset_fn_t vfio_platform_lookup_reset(const char *compat,
>> -					struct module **module)
>> +				  const char *acpihid, struct module **module)
>>  {
>>  	struct vfio_platform_reset_node *iter;
>>  	vfio_platform_reset_fn_t reset_fn = NULL;
>>  
>>  	mutex_lock(&driver_lock);
>>  	list_for_each_entry(iter, &reset_list, link) {
>> -		if (!strcmp(iter->compat, compat) &&
>> +		if (acpihid && iter->acpihid &&
>> +		    !strcmp(iter->acpihid, acpihid) &&
>> +			try_module_get(iter->owner)) {
>> +			*module = iter->owner;
>> +			reset_fn = iter->reset;
>> +			break;
>> +		}
>> +		if (compat && iter->compat &&
>> +		    !strcmp(iter->compat, compat) &&
>>  			try_module_get(iter->owner)) {
>>  			*module = iter->owner;
>>  			reset_fn = iter->reset;
>> @@ -49,15 +58,30 @@ static vfio_platform_reset_fn_t vfio_platform_lookup_reset(const char *compat,
>>  	return reset_fn;
>>  }
>>  
>> -static void vfio_platform_get_reset(struct vfio_platform_device *vdev)
>> +static int vfio_platform_get_reset(struct vfio_platform_device *vdev)
> What is the point returning a value here? See my comment at the end.

I was trying to do some error handling here. If a driver does not have a
reset implementation, we are letting it go right now. 

I think we need to make reset driver a requirement. Mark Rutland reminded me 
that I need a reset driver. 

I did not think about it during implementation and I have not seen any 
warnings like you said.

>>  {
>> -	vdev->reset = vfio_platform_lookup_reset(vdev->compat,
>> -						&vdev->reset_module);
>> -	if (!vdev->reset) {
>> -		request_module("vfio-reset:%s", vdev->compat);
>> -		vdev->reset = vfio_platform_lookup_reset(vdev->compat,
>> -							 &vdev->reset_module);
>> -	}


>>  
>> -	vfio_platform_get_reset(vdev);
>> +	ret = vfio_platform_get_reset(vdev);
>> +	if (ret) {
>> +		iommu_group_put(group);
>> +		return ret;
>> +	}
> This change is not related to your commit message. Also here you change
> the use model of VFIO platform and forbid any usage if no reset module
> is available, right? I don't think this is something we discussed and I
> think it removes some flexibility. Currently a warning is emitted in
> case we don't have a reset function.

Well, I haven't seen that warning during testing. I was trying to be more 
proactive.

I'm fine removing these checks but not having a reset driver needs a really
big warning here.

> 
> Best Regards
> 
> Eric
>>  



-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

WARNING: multiple messages have this Message-ID (diff)
From: okaya@codeaurora.org (Sinan Kaya)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] vfio, platform: add support for ACPI while detecting the reset driver
Date: Thu, 10 Mar 2016 12:13:28 -0500	[thread overview]
Message-ID: <56E1AB38.8020702@codeaurora.org> (raw)
In-Reply-To: <56E14858.9050401@linaro.org>

On 3/10/2016 5:11 AM, Eric Auger wrote:
> Hi Sinan,
> On 03/08/2016 04:33 PM, Sinan Kaya wrote:
>> The  code is using the compatible DT string to associate a reset driver with
>> the actual device itself. The compatible string does not exist on ACPI
>> based systems. HID is the unique identifier for a device driver instead.
>> The change allows a driver to register with DT compatible string or ACPI
>> HID and then match the object with one of these conditions.
>>
>> Rules for loading the reset driver are as follow:
>> - ACPI HID needs match for ACPI systems
>> - DT compat needs to match for OF systems
>>
>> Tested-by: Eric Auger <eric.auger@linaro.org> (device tree only)
>> Tested-by: Shanker Donthineni <shankerd@codeaurora.org> (ACPI only)
>> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>> ---
>>  .../vfio/platform/reset/vfio_platform_amdxgbe.c    |   4 +-
>>  .../platform/reset/vfio_platform_calxedaxgmac.c    |   4 +-
>>  drivers/vfio/platform/vfio_platform_common.c       | 112 +++++++++++++++++----
>>  drivers/vfio/platform/vfio_platform_private.h      |  43 ++++----
>>  4 files changed, 125 insertions(+), 38 deletions(-)
>>
>> diff --git a/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c b/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c
>> index d4030d0..170dcf5 100644
>> --- a/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c
>> +++ b/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c
>> @@ -119,7 +119,9 @@ int vfio_platform_amdxgbe_reset(struct vfio_platform_device *vdev)
>>  	return 0;
>>  }
>>  
>> -module_vfio_reset_handler("amd,xgbe-seattle-v1a", vfio_platform_amdxgbe_reset);
>> +module_vfio_reset_handler("amd,xgbe-seattle-v1a", NULL,
>> +			  vfio_platform_amdxgbe_reset);
>> +VFIO_PLATFORM_MODULE_ALIAS("amd,xgbe-seattle-v1a");
> Looks the other overridden MODULE_ALIAS have a naming like
> MODULE_ALIAS_something? what about MODULE_ALIAS_VFIO_PLATFORM_RESET?
> not very compact but maybe closer to what it stands for.

alright, I'll follow that.

>>  
>>  MODULE_VERSION("0.1");
>>  MODULE_LICENSE("GPL v2");
>> diff --git a/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c b/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
>> index e3d3d94..635c6e0 100644
>> --- a/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
>> +++ b/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
>> @@ -77,7 +77,9 @@ int vfio_platform_calxedaxgmac_reset(struct vfio_platform_device *vdev)
>>  	return 0;
>>  }
>>  
>> -module_vfio_reset_handler("calxeda,hb-xgmac", vfio_platform_calxedaxgmac_reset);
>> +module_vfio_reset_handler("calxeda,hb-xgmac", NULL,
>> +			  vfio_platform_calxedaxgmac_reset);
>> +VFIO_PLATFORM_MODULE_ALIAS("calxeda,hb-xgmac");
>>  
>>  MODULE_VERSION(DRIVER_VERSION);
>>  MODULE_LICENSE("GPL v2");
>> diff --git a/drivers/vfio/platform/vfio_platform_common.c b/drivers/vfio/platform/vfio_platform_common.c
>> index 418cdd9..c758e72 100644
>> --- a/drivers/vfio/platform/vfio_platform_common.c
>> +++ b/drivers/vfio/platform/vfio_platform_common.c
>> @@ -13,6 +13,7 @@
>>   */
>>  
>>  #include <linux/device.h>
>> +#include <linux/acpi.h>
>>  #include <linux/iommu.h>
>>  #include <linux/module.h>
>>  #include <linux/mutex.h>
>> @@ -31,14 +32,22 @@ static LIST_HEAD(reset_list);
>>  static DEFINE_MUTEX(driver_lock);
>>  
>>  static vfio_platform_reset_fn_t vfio_platform_lookup_reset(const char *compat,
>> -					struct module **module)
>> +				  const char *acpihid, struct module **module)
>>  {
>>  	struct vfio_platform_reset_node *iter;
>>  	vfio_platform_reset_fn_t reset_fn = NULL;
>>  
>>  	mutex_lock(&driver_lock);
>>  	list_for_each_entry(iter, &reset_list, link) {
>> -		if (!strcmp(iter->compat, compat) &&
>> +		if (acpihid && iter->acpihid &&
>> +		    !strcmp(iter->acpihid, acpihid) &&
>> +			try_module_get(iter->owner)) {
>> +			*module = iter->owner;
>> +			reset_fn = iter->reset;
>> +			break;
>> +		}
>> +		if (compat && iter->compat &&
>> +		    !strcmp(iter->compat, compat) &&
>>  			try_module_get(iter->owner)) {
>>  			*module = iter->owner;
>>  			reset_fn = iter->reset;
>> @@ -49,15 +58,30 @@ static vfio_platform_reset_fn_t vfio_platform_lookup_reset(const char *compat,
>>  	return reset_fn;
>>  }
>>  
>> -static void vfio_platform_get_reset(struct vfio_platform_device *vdev)
>> +static int vfio_platform_get_reset(struct vfio_platform_device *vdev)
> What is the point returning a value here? See my comment at the end.

I was trying to do some error handling here. If a driver does not have a
reset implementation, we are letting it go right now. 

I think we need to make reset driver a requirement. Mark Rutland reminded me 
that I need a reset driver. 

I did not think about it during implementation and I have not seen any 
warnings like you said.

>>  {
>> -	vdev->reset = vfio_platform_lookup_reset(vdev->compat,
>> -						&vdev->reset_module);
>> -	if (!vdev->reset) {
>> -		request_module("vfio-reset:%s", vdev->compat);
>> -		vdev->reset = vfio_platform_lookup_reset(vdev->compat,
>> -							 &vdev->reset_module);
>> -	}


>>  
>> -	vfio_platform_get_reset(vdev);
>> +	ret = vfio_platform_get_reset(vdev);
>> +	if (ret) {
>> +		iommu_group_put(group);
>> +		return ret;
>> +	}
> This change is not related to your commit message. Also here you change
> the use model of VFIO platform and forbid any usage if no reset module
> is available, right? I don't think this is something we discussed and I
> think it removes some flexibility. Currently a warning is emitted in
> case we don't have a reset function.

Well, I haven't seen that warning during testing. I was trying to be more 
proactive.

I'm fine removing these checks but not having a reset driver needs a really
big warning here.

> 
> Best Regards
> 
> Eric
>>  



-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

  reply	other threads:[~2016-03-10 17:13 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-08 15:33 [PATCH 1/2] vfio, platform: add support for ACPI while detecting the reset driver Sinan Kaya
2016-03-08 15:33 ` Sinan Kaya
2016-03-08 15:33 ` [PATCH 2/2] vfio, platform: add QTI HIDMA " Sinan Kaya
2016-03-08 15:33   ` Sinan Kaya
2016-03-08 15:37 ` [PATCH 1/2] vfio, platform: add support for ACPI while detecting the " Sinan Kaya
2016-03-08 15:37   ` Sinan Kaya
     [not found]   ` <56DEF1BE.8010701-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-03-10  7:58     ` Dan Carpenter
2016-03-10  7:58       ` Dan Carpenter
2016-03-10  7:58       ` Dan Carpenter
2016-03-10 17:00       ` Sinan Kaya
2016-03-10 17:00         ` Sinan Kaya
2016-03-10 17:00         ` Sinan Kaya
2016-03-10 10:11 ` Eric Auger
2016-03-10 10:11   ` Eric Auger
2016-03-10 17:13   ` Sinan Kaya [this message]
2016-03-10 17:13     ` Sinan Kaya
2016-03-11  3:48     ` Eric Auger
2016-03-11  3:48       ` Eric Auger
2016-03-11 16:09       ` Sinan Kaya
2016-03-11 16:09         ` Sinan Kaya
     [not found]     ` <56E1AB38.8020702-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-03-11  4:05       ` Marc Zyngier
2016-03-11  4:05         ` Marc Zyngier
2016-03-11  4:05         ` Marc Zyngier
2016-03-11  4:05         ` Marc Zyngier

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=56E1AB38.8020702@codeaurora.org \
    --to=okaya@codeaurora.org \
    --cc=agross@codeaurora.org \
    --cc=alex.williamson@redhat.com \
    --cc=arnd@arndb.de \
    --cc=b.reynal@virtualopensystems.com \
    --cc=cov@codeaurora.org \
    --cc=dan.carpenter@oracle.com \
    --cc=devicetree@vger.kernel.org \
    --cc=eric.auger@linaro.org \
    --cc=jcm@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=shankerd@codeaurora.org \
    --cc=timur@codeaurora.org \
    --cc=vikrams@codeaurora.org \
    --cc=vinod.koul@intel.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.