[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20201005164557.GA157831@epycbox.lan>
Date: Mon, 5 Oct 2020 09:45:57 -0700
From: Moritz Fischer <mdf@...nel.org>
To: "Wu, Hao" <hao.wu@...el.com>
Cc: Moritz Fischer <mdf@...nel.org>,
"linux-fpga@...r.kernel.org" <linux-fpga@...r.kernel.org>,
"trix@...hat.com" <trix@...hat.com>,
"michal.simek@...inx.com" <michal.simek@...inx.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"Weight, Russell H" <russell.h.weight@...el.com>,
"Gerlach, Matthew" <matthew.gerlach@...el.com>
Subject: Re: [PATCH 01/10] fpga: fpga-mgr: Add devm_fpga_mgr_register() API
Hi Hao,
On Mon, Oct 05, 2020 at 05:18:40AM +0000, Wu, Hao wrote:
> > Subject: [PATCH 01/10] fpga: fpga-mgr: Add devm_fpga_mgr_register() API
> >
> > Add a devm_fpga_mgr_register() API that can be used to register a FPGA
> > Manager that was created using devm_fpga_mgr_create().
> >
> > Introduce a struct fpga_mgr_devres that makes the devres
> > allocation a little bit more readable and gets reused for
> > devm_fpga_mgr_create() devm_fpga_mgr_register().
> >
> > Signed-off-by: Moritz Fischer <mdf@...nel.org>
> > ---
> > drivers/fpga/fpga-mgr.c | 76 ++++++++++++++++++++++++++++++-----
> > include/linux/fpga/fpga-mgr.h | 2 +
> > 2 files changed, 68 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
> > index f38bab01432e..774ac98fb69c 100644
> > --- a/drivers/fpga/fpga-mgr.c
> > +++ b/drivers/fpga/fpga-mgr.c
> > @@ -21,6 +21,10 @@
> > static DEFINE_IDA(fpga_mgr_ida);
> > static struct class *fpga_mgr_class;
> >
> > +struct fpga_mgr_devres {
> > + struct fpga_manager *mgr;
> > +};
> > +
> > /**
> > * fpga_image_info_alloc - Allocate a FPGA image info struct
> > * @dev: owning device
> > @@ -651,21 +655,21 @@ struct fpga_manager
> > *devm_fpga_mgr_create(struct device *dev, const char *name,
> > const struct fpga_manager_ops
> > *mops,
> > void *priv)
> > {
> > - struct fpga_manager **ptr, *mgr;
> > + struct fpga_mgr_devres *dr;
> >
> > - ptr = devres_alloc(devm_fpga_mgr_release, sizeof(*ptr),
> > GFP_KERNEL);
> > - if (!ptr)
> > + dr = devres_alloc(devm_fpga_mgr_release, sizeof(*dr), GFP_KERNEL);
>
> Should we update devm_fpga_mgr_release function to use fpga_mgr_devres as well?
Yes!
>
> > + if (!dr)
> > return NULL;
> >
> > - mgr = fpga_mgr_create(dev, name, mops, priv);
> > - if (!mgr) {
> > - devres_free(ptr);
> > - } else {
> > - *ptr = mgr;
> > - devres_add(dev, ptr);
> > + dr->mgr = fpga_mgr_create(dev, name, mops, priv);
> > + if (!dr->mgr) {
> > + devres_free(dr);
> > + return NULL;
> > }
> >
> > - return mgr;
> > + devres_add(dev, dr);
> > +
> > + return dr->mgr;
> > }
> > EXPORT_SYMBOL_GPL(devm_fpga_mgr_create);
> >
> > @@ -722,6 +726,58 @@ void fpga_mgr_unregister(struct fpga_manager
> > *mgr)
> > }
> > EXPORT_SYMBOL_GPL(fpga_mgr_unregister);
> >
> > +static int fpga_mgr_devres_match(struct device *dev, void *priv,
>
> Maybe it's better to use "res" instead of "priv" which matches the
> dr_match_t, and also devm_fpga_mgr_release function.
Can do.
>
> > + void *match_data)
> > +{
> > + struct fpga_mgr_devres *dr = priv;
> > +
> > + return match_data == dr->mgr;
> > +}
> > +
> > +static void devm_fpga_mgr_unregister(struct device *dev, void *priv)
> > +{
>
> Same.
Ditto.
>
> > + struct fpga_mgr_devres *dr = priv;
> > +
> > + fpga_mgr_unregister(dr->mgr);
> > +}
> > +
> > +/**
> > + * devm_fpga_mgr_register - resource managed variant of
> > fpga_mgr_register()
> > + * @dev: managing device for this FPGA manager
> > + * @mgr: fpga manager struct
> > + *
> > + * This is the devres variant of fpga_mgr_register() for which the unregister
> > + * function will be called automatically when the managing device is
> > detached.
> > + */
> > +int devm_fpga_mgr_register(struct device *dev, struct fpga_manager *mgr)
> > +{
> > + struct fpga_mgr_devres *dr;
> > + int err;
> > +
> > + /* Make sure that the struct fpga_manager * that is passed in is
> > + * managed itself.
> > + */
>
> Should we use the same style for code comments here,
> I see other places in this file are using style like
Can do.
>
> /*
> * ......
> */
>
> Thanks
> Hao
Thanks,
Moritz
Powered by blists - more mailing lists