From: Tom Rix <trix@redhat.com>
To: Xu Yilun <yilun.xu@intel.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: Sat, 1 Aug 2020 08:40:54 -0700 [thread overview]
Message-ID: <1d8198f3-10d6-118c-f767-cef88fa871c6@redhat.com> (raw)
In-Reply-To: <20200731074837.GE1781@yilunxu-OptiPlex-7050>
On 7/31/20 12:48 AM, Xu Yilun wrote:
> 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;
> };
>
Ok.
Reviewed-by: Tom Rix <trix@redhat.com>
> 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);
>>> }
next prev parent reply other threads:[~2020-08-01 15:41 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
2020-08-01 15:40 ` Tom Rix [this message]
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=1d8198f3-10d6-118c-f767-cef88fa871c6@redhat.com \
--to=trix@redhat.com \
--cc=lgoncalv@redhat.com \
--cc=linux-fpga@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mdf@kernel.org \
--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).