Message-ID: <BE8371DA886269458E0220A16DC1F8277E156640@SHSMSX104.ccr.corp.intel.com>
Date:   Sun, 18 Feb 2018 02:15:18 +0000
From:   "Wu, Hao" <hao.wu@...el.com>
To:     Moritz Fischer <mdf@...nel.org>
CC:     Alan Tull <atull@...nel.org>,
        "linux-fpga@...r.kernel.org" <linux-fpga@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
        "Kang, Luwei" <luwei.kang@...el.com>,
        "Zhang, Yi Z" <yi.z.zhang@...el.com>,
        Xiao Guangrong <guangrong.xiao@...ux.intel.com>,
        "Whisonant, Tim" <tim.whisonant@...el.com>,
        "Luebbers, Enno" <enno.luebbers@...el.com>,
        "Rao, Shiva" <shiva.rao@...el.com>,
        "Rauer, Christopher" <christopher.rauer@...el.com>
Subject: RE: [PATCH v4 07/24] fpga: dfl: add feature device infrastructure

> On Thu, Feb 15, 2018 at 10:05:20AM +0000, Wu, Hao wrote:
> > > On Wed, Feb 14, 2018 at 3:03 PM, Moritz Fischer <mdf@...nel.org> wrote:
> > >
> > > Hi Moritz,
> > >
> > > > HI Hao,
> > > >
> >
> > Hi Alan and Moritz
> >
> > Thanks a lot for the code review and comments.
> >
> > > > On Tue, Feb 13, 2018 at 05:24:36PM +0800, Wu Hao wrote:
> > > >> From: Xiao Guangrong <guangrong.xiao@...ux.intel.com>
> > > >>
> > > >> This patch abstracts the common operations of the sub features, and
> defines
> > > >> the feature_ops data structure, including init, uinit and ioctl function
> > > >> pointers. And this patch adds some common helper functions for FME and
> > > AFU
> > > >> drivers, e.g feature_dev_use_begin/end which are used to ensure
> exclusive
> > > >> usage of the feature device file.
> > > >>
> > > >> Signed-off-by: Tim Whisonant <tim.whisonant@...el.com>
> > > >> Signed-off-by: Enno Luebbers <enno.luebbers@...el.com>
> > > >> Signed-off-by: Shiva Rao <shiva.rao@...el.com>
> > > >> Signed-off-by: Christopher Rauer <christopher.rauer@...el.com>
> > > >> Signed-off-by: Kang Luwei <luwei.kang@...el.com>
> > > >> Signed-off-by: Zhang Yi <yi.z.zhang@...el.com>
> > > >> Signed-off-by: Xiao Guangrong <guangrong.xiao@...ux.intel.com>
> > > >> Signed-off-by: Wu Hao <hao.wu@...el.com>
> > > >> ---
> > > >> v2: rebased
> > > >> v3: use const for feature_ops.
> > > >>     replace pci related function.
> > > >> v4: rebase and add more comments in code.
> > > >> ---
> > > >>  drivers/fpga/dfl.c | 59 +++++++++++++++++++++++++++++++++++++
> > > >>  drivers/fpga/dfl.h | 85
> > > +++++++++++++++++++++++++++++++++++++++++++++++++++++-
> > > >>  2 files changed, 143 insertions(+), 1 deletion(-)
> > > >>
> > > >> diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
> > > >> index 38dc819..c0aad87 100644
> > > >> --- a/drivers/fpga/dfl.c
> > > >> +++ b/drivers/fpga/dfl.c
> > > >> @@ -74,6 +74,65 @@ static enum fpga_id_type
> feature_dev_id_type(struct
> > > platform_device *pdev)
> > > >>       return FPGA_ID_MAX;
> > > >>  }
> > > >>
> > > >> +void fpga_dev_feature_uinit(struct platform_device *pdev)
> > > >> +{
> > > >> +     struct feature *feature;
> > > >> +     struct feature_platform_data *pdata = dev_get_platdata(&pdev-
> >dev);
> > > > See comment below w.r.t ordering declarations. Not a must for sure.
> > > >> +
> > > >> +     fpga_dev_for_each_feature(pdata, feature)
> > > >> +             if (feature->ops) {
> > > >> +                     feature->ops->uinit(pdev, feature);
> > > >> +                     feature->ops = NULL;
> > > >> +             }
> > > >> +}
> > > >> +EXPORT_SYMBOL_GPL(fpga_dev_feature_uinit);
> > > >> +
> > > >> +static int
> > > >> +feature_instance_init(struct platform_device *pdev,
> > > >> +                   struct feature_platform_data *pdata,
> > > >> +                   struct feature *feature, struct feature_driver *drv)
> > > >> +{
> > > >> +     int ret;
> > > >> +
> > > >> +     WARN_ON(!feature->ioaddr);
> > > >
> > > > Not sure I understand correctly, is the !feature->ioaddr a use-case that
> > > > happens? If not just return early.
> >
> > Actually this should never happen (init a feature without mapped mmio
> > resource address). If this warning is seen, that means there should be
> > critical issues somewhere in driver enumeration code. But sure, I can just
> > use if () return instead. : )
> >
> > > >> +
> > > >> +     ret = drv->ops->init(pdev, feature);
> > > >> +     if (ret)
> > > >> +             return ret;
> > > >> +
> > > >> +     feature->ops = drv->ops;
> > > >> +
> > > >> +     return ret;
> > > >> +}
> > > >> +
> > > >> +int fpga_dev_feature_init(struct platform_device *pdev,
> > > >> +                       struct feature_driver *feature_drvs)
> > > >> +{
> > > >> +     struct feature *feature;
> > > >> +     struct feature_driver *drv = feature_drvs;
> > > >> +     struct feature_platform_data *pdata = dev_get_platdata(&pdev-
> >dev);
> > > >> +     int ret;
> > > > We don't have clear guidelines here, but some subsystems want reverse
> > > > X-Mas tree declarations.
> > >
> > > Sounds good!  I agree.
> >
> > Do you mean we should reverse fpga_xxx definitions? If yes, then I can update
> > the code to use fpga_dfl_xxx or dfl_xxx instead. : )
> 
> More a stylistic thing, in the sense that you'd have the longest line
> first:
> 
> +     struct feature_platform_data *pdata = dev_get_platdata(&pdev->dev);
> +     struct feature_driver *drv = feature_drvs;
> +     struct feature *feature;
> +     int ret;
> 
> Instead of:
> 
> +     struct feature *feature;
> +     struct feature_driver *drv = feature_drvs;
> +     struct feature_platform_data *pdata = dev_get_platdata(&pdev->dev);
> +     int ret;
> 
> as I said not a big deal, some subsystems want you to do this, I don't
> think we made that a strict rule so far, but it makes it visually more
> pleasing ;-)

Oh.. I see. Thanks for the suggestion, I will update the patch for this.

Hao

> 
> Moritz

Powered by blists - more mailing lists