linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Xu Yilun <yilun.xu@intel.com>
To: Tom Rix <trix@redhat.com>
Cc: mdf@kernel.org, linux-fpga@vger.kernel.org,
	linux-kernel@vger.kernel.org, lgoncalv@redhat.com
Subject: Re: [PATCH v2 1/4] fpga: dfl: change data type of feature id to u16
Date: Fri, 31 Jul 2020 15:48:37 +0800	[thread overview]
Message-ID: <20200731074837.GE1781@yilunxu-OptiPlex-7050> (raw)
In-Reply-To: <316f86d4-7bba-f0c7-3dde-794df80d32e7@redhat.com>

On Sat, Jul 25, 2020 at 06:29:53AM -0700, Tom Rix wrote:
> It would be good if the variable or element for the feature id had a consistent name.
> 
> 
> > @@ -197,7 +197,7 @@ int dfl_fpga_check_port_id(struct platform_device *pdev, void *pport_id);
> >   * @id: unique dfl private feature id.
> >   */
> >  struct dfl_feature_id {
> > -	u64 id;
> > +	u16 id;
> >  };
> 
> Is this structure needed ?
> 
> Here is how it could be changed to 
> 
> struct dfl_feature_driver {
> 
> -    const dfl_feature_id *
> 
> +    const u16 *id_table;

This structure is to represent an id type, which is used to match
fme/port owned features. It could be extended if some feature drivers
needs driver_data.

Actually I see some example of device_ids with similar structure, like:

  struct mips_cdmm_device_id {
  	__u8	type;
  };

  struct tee_client_device_id {
	uuid_t uuid;
  };


Thanks,
Yilun.

> 
> ...
> 
> Tom
> 
> 
> >  
> >  /**
> > @@ -240,7 +240,7 @@ struct dfl_feature_irq_ctx {
> >   */
> >  struct dfl_feature {
> >  	struct platform_device *dev;
> > -	u64 id;
> > +	u16 id;
> >  	int resource_index;
> >  	void __iomem *ioaddr;
> >  	struct dfl_feature_irq_ctx *irq_ctx;
> > @@ -371,7 +371,7 @@ struct platform_device *dfl_fpga_inode_to_feature_dev(struct inode *inode)
> >  	   (feature) < (pdata)->features + (pdata)->num; (feature)++)
> >  
> >  static inline
> > -struct dfl_feature *dfl_get_feature_by_id(struct device *dev, u64 id)
> > +struct dfl_feature *dfl_get_feature_by_id(struct device *dev, u16 id)
> >  {
> >  	struct dfl_feature_platform_data *pdata = dev_get_platdata(dev);
> >  	struct dfl_feature *feature;
> > @@ -384,7 +384,7 @@ struct dfl_feature *dfl_get_feature_by_id(struct device *dev, u64 id)
> >  }
> >  
> >  static inline
> > -void __iomem *dfl_get_feature_ioaddr_by_id(struct device *dev, u64 id)
> > +void __iomem *dfl_get_feature_ioaddr_by_id(struct device *dev, u16 id)
> >  {
> >  	struct dfl_feature *feature = dfl_get_feature_by_id(dev, id);
> >  
> > @@ -395,7 +395,7 @@ void __iomem *dfl_get_feature_ioaddr_by_id(struct device *dev, u64 id)
> >  	return NULL;
> >  }
> >  
> > -static inline bool is_dfl_feature_present(struct device *dev, u64 id)
> > +static inline bool is_dfl_feature_present(struct device *dev, u16 id)
> >  {
> >  	return !!dfl_get_feature_ioaddr_by_id(dev, id);
> >  }

  reply	other threads:[~2020-07-31  7:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-24  2:09 [PATCH v2 0/4] Modularization of DFL private feature drivers Xu Yilun
2020-07-24  2:09 ` [PATCH v2 1/4] fpga: dfl: change data type of feature id to u16 Xu Yilun
2020-07-25 13:29   ` Tom Rix
2020-07-31  7:48     ` Xu Yilun [this message]
2020-08-01 15:40       ` Tom Rix
2020-07-24  2:09 ` [PATCH v2 2/4] fpga: dfl: map feature mmio resources in their own feature drivers Xu Yilun
2020-08-01 15:43   ` Tom Rix
2020-07-24  2:09 ` [PATCH v2 3/4] fpga: dfl: create a dfl bus type to support DFL devices Xu Yilun
2020-08-01 15:47   ` Tom Rix
2020-07-24  2:09 ` [PATCH v2 4/4] fpga: dfl: add support for N3000 nios private feature Xu Yilun
2020-07-25 14:53   ` Tom Rix
2020-07-31  8:56     ` Xu Yilun
2020-08-01 15:35       ` Tom Rix
2020-07-24  3:03 ` [PATCH v2 0/4] Modularization of DFL private feature drivers Randy Dunlap
2020-07-24  3:30   ` Xu Yilun

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=20200731074837.GE1781@yilunxu-OptiPlex-7050 \
    --to=yilun.xu@intel.com \
    --cc=lgoncalv@redhat.com \
    --cc=linux-fpga@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mdf@kernel.org \
    --cc=trix@redhat.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).