From: Russ Weight <russell.h.weight@intel.com>
To: Tom Rix <trix@redhat.com>, mdf@kernel.org, linux-fpga@vger.kernel.org
Cc: lgoncalv@redhat.com, yilun.xu@intel.com, hao.wu@intel.com,
matthew.gerlach@intel.com, richard.gong@intel.com
Subject: Re: [PATCH v3 1/3] fpga: mgr: Use standard dev_release for class driver
Date: Tue, 25 May 2021 09:51:35 -0700 [thread overview]
Message-ID: <cf4bb8d9-6953-ecf6-30a5-8556e5d40959@intel.com> (raw)
In-Reply-To: <353d1753-070d-38fc-dfc6-7020aea32c5d@redhat.com>
Hi Tom,
On 5/24/21 1:16 PM, Tom Rix wrote:
> Russ,
>
> I think the signature fpga_mgr_register, should change to
>
> int fpga_mgr_register(struct device *, const struct fpga_mager_ops *mops, void *priv);
>
> I'll explain below ..
>
> On 5/24/21 11:50 AM, Russ Weight wrote:
>> The FPGA manager class driver data structure is being treated as a
>> managed resource instead of using standard dev_release call-back
>> to release the class data structure. This change removes the
>> managed resource code for the freeing of the class data structure
>> and combines the create() and register() functions into a single
>> register() function.
>>
>> The devm_fpga_mgr_register() function is retained.
>>
>> Signed-off-by: Russ Weight <russell.h.weight@intel.com>
>> ---
>> v3:
>> - Cleaned up comment header for fpga_mgr_register()
>> - Fix error return on ida_simple_get() failure
>> v2:
>> - Restored devm_fpga_mgr_register() functionality, adapted for the combined
>> create/register functionality.
>> - All previous callers of devm_fpga_mgr_register() will continue to call
>> devm_fpga_mgr_register().
>> - replaced unnecessary ternary operators in return statements with standard
>> if conditions.
>> ---
>> drivers/fpga/altera-cvp.c | 12 +--
>> drivers/fpga/altera-pr-ip-core.c | 8 +-
>> drivers/fpga/altera-ps-spi.c | 10 +-
>> drivers/fpga/dfl-fme-mgr.c | 10 +-
>> drivers/fpga/fpga-mgr.c | 163 ++++++++-----------------------
>> drivers/fpga/ice40-spi.c | 10 +-
>> drivers/fpga/machxo2-spi.c | 10 +-
>> drivers/fpga/socfpga-a10.c | 16 ++-
>> drivers/fpga/socfpga.c | 10 +-
>> drivers/fpga/stratix10-soc.c | 15 +--
>> drivers/fpga/ts73xx-fpga.c | 10 +-
>> drivers/fpga/xilinx-spi.c | 12 +--
>> drivers/fpga/zynq-fpga.c | 16 ++-
>> drivers/fpga/zynqmp-fpga.c | 10 +-
>> include/linux/fpga/fpga-mgr.h | 17 ++--
>> 15 files changed, 112 insertions(+), 217 deletions(-)
>>
>> diff --git a/drivers/fpga/altera-cvp.c b/drivers/fpga/altera-cvp.c
>> index 4e0edb60bfba..b61020ceb0a1 100644
>> --- a/drivers/fpga/altera-cvp.c
>> +++ b/drivers/fpga/altera-cvp.c
>> @@ -652,19 +652,15 @@ static int altera_cvp_probe(struct pci_dev *pdev,
>> snprintf(conf->mgr_name, sizeof(conf->mgr_name), "%s @%s",
>> ALTERA_CVP_MGR_NAME, pci_name(pdev));
>> - mgr = devm_fpga_mgr_create(&pdev->dev, conf->mgr_name,
>> - &altera_cvp_ops, conf);
>> - if (!mgr) {
>> - ret = -ENOMEM;
>> + mgr = fpga_mgr_register(&pdev->dev, conf->mgr_name,
>> + &altera_cvp_ops, conf);
>> + if (IS_ERR(mgr)) {
>> + ret = PTR_ERR(mgr);
>> goto err_unmap;
>> }
>> pci_set_drvdata(pdev, mgr);
>
> This is a wrapper around
>
> dev_set_drvdata()
>
>> - ret = fpga_mgr_register(mgr);
>> - if (ret)
>> - goto err_unmap;
>> -
>> return 0;
>> err_unmap:
>> diff --git a/drivers/fpga/altera-pr-ip-core.c b/drivers/fpga/altera-pr-ip-core.c
>> index 5b130c4d9882..0980e134cc43 100644
>> --- a/drivers/fpga/altera-pr-ip-core.c
>> +++ b/drivers/fpga/altera-pr-ip-core.c
>> @@ -191,11 +191,11 @@ int alt_pr_register(struct device *dev, void __iomem *reg_base)
>> (val & ALT_PR_CSR_STATUS_MSK) >> ALT_PR_CSR_STATUS_SFT,
>> (int)(val & ALT_PR_CSR_PR_START));
>> - mgr = devm_fpga_mgr_create(dev, dev_name(dev), &alt_pr_ops, priv);
> using the name of the device
>> - if (!mgr)
>> - return -ENOMEM;
>> + mgr = devm_fpga_mgr_register(dev, dev_name(dev), &alt_pr_ops, priv);
>> + if (IS_ERR(mgr))
>> + return PTR_ERR(mgr);
> mgr is unused
>> - return devm_fpga_mgr_register(dev, mgr);
>> + return 0;
>> }
>> EXPORT_SYMBOL_GPL(alt_pr_register);
>> diff --git a/drivers/fpga/altera-ps-spi.c b/drivers/fpga/altera-ps-spi.c
>> index 23bfd4d1ad0f..d3f77b0312b2 100644
>> --- a/drivers/fpga/altera-ps-spi.c
>> +++ b/drivers/fpga/altera-ps-spi.c
>> @@ -302,12 +302,12 @@ static int altera_ps_probe(struct spi_device *spi)
>> snprintf(conf->mgr_name, sizeof(conf->mgr_name), "%s %s",
>> dev_driver_string(&spi->dev), dev_name(&spi->dev));
> a combo of devices name, is that really necessary ?
I would like to limit the scope of this patch to address:
(1) a populated dev_release function
(2) combining the device_initialize() and device_add() calls into single call
to device_register()
Changing the name or removing the sysfs name file could have implications for
users who expect it to be there or, worse yet, have a script that looks for it.
I think these could be done in a separate patch if needed.
>> - mgr = devm_fpga_mgr_create(&spi->dev, conf->mgr_name,
>> - &altera_ps_ops, conf);
>> - if (!mgr)
>> - return -ENOMEM;
>> + mgr = devm_fpga_mgr_register(&spi->dev, conf->mgr_name,
>> + &altera_ps_ops, conf);
>> + if (IS_ERR(mgr))
>> + return PTR_ERR(mgr);
> mgr is unused
>> - return devm_fpga_mgr_register(&spi->dev, mgr);
>> + return 0;
>> }
>> static const struct spi_device_id altera_ps_spi_ids[] = {
>> diff --git a/drivers/fpga/dfl-fme-mgr.c b/drivers/fpga/dfl-fme-mgr.c
>> index d5861d13b306..d71eba817b3b 100644
>> --- a/drivers/fpga/dfl-fme-mgr.c
>> +++ b/drivers/fpga/dfl-fme-mgr.c
>> @@ -308,14 +308,14 @@ static int fme_mgr_probe(struct platform_device *pdev)
>> fme_mgr_get_compat_id(priv->ioaddr, compat_id);
>> - mgr = devm_fpga_mgr_create(dev, "DFL FME FPGA Manager",
>> - &fme_mgr_ops, priv);
>> - if (!mgr)
>> - return -ENOMEM;
>> + mgr = devm_fpga_mgr_register(dev, "DFL FME FPGA Manager",
>> + &fme_mgr_ops, priv);
> drv name is 'dfl-fme-mgr', is this close enough ?
>> + if (IS_ERR(mgr))
>> + return PTR_ERR(mgr);
>> mgr->compat_id = compat_id;
>> - return devm_fpga_mgr_register(dev, mgr);
>> + return 0;
>> }
>> static struct platform_driver fme_mgr_driver = {
>> diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
>> index b85bc47c91a9..22f0dd5c2834 100644
>> --- a/drivers/fpga/fpga-mgr.c
>> +++ b/drivers/fpga/fpga-mgr.c
>> @@ -550,20 +550,20 @@ void fpga_mgr_unlock(struct fpga_manager *mgr)
>> EXPORT_SYMBOL_GPL(fpga_mgr_unlock);
>> /**
>> - * fpga_mgr_create - create and initialize a FPGA manager struct
>> + * fpga_mgr_register - create and register a FPGA Manager device
>> * @dev: fpga manager device from pdev
>
> nit, space or tab after ':' ? this is inconsistent everywhere.
>
>
>> * @name: fpga manager name
>> * @mops: pointer to structure of fpga manager ops
>> * @priv: fpga manager private data
>> *
>> - * The caller of this function is responsible for freeing the struct with
>> - * fpga_mgr_free(). Using devm_fpga_mgr_create() instead is recommended.
>> + * The caller of this function is responsible for calling fpga_mgr_unregister().
>> + * Using devm_fpga_mgr_register instead is recommended.
>> *
>> - * Return: pointer to struct fpga_manager or NULL
>> + * Returns a struct fpga_manager pointer on success, or ERR_PTR() on error.
>> */
>> -struct fpga_manager *fpga_mgr_create(struct device *dev, const char *name,
>> - const struct fpga_manager_ops *mops,
>> - void *priv)
>> +struct fpga_manager *
>> +fpga_mgr_register(struct device *dev, const char *name,
>> + const struct fpga_manager_ops *mops, void *priv)
>> {
>> struct fpga_manager *mgr;
>> int id, ret;
>> @@ -572,21 +572,23 @@ struct fpga_manager *fpga_mgr_create(struct device *dev, const char *name,
>> !mops->write_init || (!mops->write && !mops->write_sg) ||
>> (mops->write && mops->write_sg)) {
>> dev_err(dev, "Attempt to register without fpga_manager_ops\n");
>> - return NULL;
>> + return ERR_PTR(-EINVAL);
>
> return -EINVAL;
>
> And similar
>
> The user's error checking is simplified to an int check.
>
> The clunky ERR_PTR()/PTR_ERR() can be removed
>
>> }
>> if (!name || !strlen(name)) {
>> dev_err(dev, "Attempt to register with no name!\n");
>> - return NULL;
>> + return ERR_PTR(-EINVAL);
>> }
>> mgr = kzalloc(sizeof(*mgr), GFP_KERNEL);
>> if (!mgr)
>> - return NULL;
>> + return ERR_PTR(-ENOMEM);
>> id = ida_simple_get(&fpga_mgr_ida, 0, 0, GFP_KERNEL);
>> - if (id < 0)
>> + if (id < 0) {
>> + ret = id;
>> goto error_kfree;
>> + }
>> mutex_init(&mgr->ref_mutex);
>> @@ -594,7 +596,6 @@ struct fpga_manager *fpga_mgr_create(struct device *dev, const char *name,
>
> Just use the device name, do not give the user an option and simplify the calling parameters.
>
> mgr->name = dev_name(dev)
>
>> mgr->mops = mops;
>> mgr->priv = priv;
>> - device_initialize(&mgr->dev);
>> mgr->dev.class = fpga_mgr_class;
>> mgr->dev.groups = mops->groups;
>> mgr->dev.parent = dev;
>> @@ -605,84 +606,6 @@ struct fpga_manager *fpga_mgr_create(struct device *dev, const char *name,
>> if (ret)
>> goto error_device;
>>
>
> The only use of returned mgr seems to be a variant of setting the dev->driver_data = mgr
>
> so just make it the default and don't pass back the ptr.
>
> dev_set_drvdata(dev, mgr);
I also noticed that in most cases the return pointer is not used. I get what
you are saying - it would be a nice simplification if the pointer did not need
to be returned.
However, I believe we are talking about modifying the driver_data for the
parent of the class driver, right? And the parent driver could spawn
multiple class drivers, or sub drivers. Having one of those sub-drivers control
the contents of it's driver-data doesn't feel right. It seems like the parent
driver should have exclusive control over this pointer.
I'm curious what others think...
- Russ
>
> return 0;
>
>
> Tom
>
>
next prev parent reply other threads:[~2021-05-25 16:51 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-24 18:50 [PATCH v3 0/3] fpga: Use standard class dev_release function Russ Weight
2021-05-24 18:50 ` [PATCH v3 1/3] fpga: mgr: Use standard dev_release for class driver Russ Weight
2021-05-24 20:16 ` Tom Rix
2021-05-25 16:51 ` Russ Weight [this message]
2021-05-28 14:46 ` Xu Yilun
2021-05-24 22:39 ` Moritz Fischer
2021-05-24 23:07 ` Russ Weight
2021-05-25 17:39 ` Russ Weight
2021-05-25 19:00 ` Tom Rix
2021-05-28 15:41 ` Xu Yilun
2021-05-28 17:26 ` Russ Weight
2021-05-24 18:50 ` [PATCH v3 2/3] fpga: bridge: " Russ Weight
2021-05-28 15:51 ` Xu Yilun
2021-05-24 18:50 ` [PATCH v3 3/3] fpga: region: " Russ Weight
2021-05-28 16:10 ` Xu Yilun
2021-05-28 17:43 ` Russ Weight
2021-05-24 18:52 ` [PATCH v3 0/3] fpga: Use standard class dev_release function Russ Weight
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=cf4bb8d9-6953-ecf6-30a5-8556e5d40959@intel.com \
--to=russell.h.weight@intel.com \
--cc=hao.wu@intel.com \
--cc=lgoncalv@redhat.com \
--cc=linux-fpga@vger.kernel.org \
--cc=matthew.gerlach@intel.com \
--cc=mdf@kernel.org \
--cc=richard.gong@intel.com \
--cc=trix@redhat.com \
--cc=yilun.xu@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).