> -----Original Message-----
> From: Wu, Hao <hao.wu@xxxxxxxxx>
> Sent: Thursday, March 17, 2022 4:26 PM
> To: Zhang, Tianfei <tianfei.zhang@xxxxxxxxx>; trix@xxxxxxxxxx;
> mdf@xxxxxxxxxx; Xu, Yilun <yilun.xu@xxxxxxxxx>; linux-fpga@xxxxxxxxxxxxxxx;
> linux-doc@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> rdunlap@xxxxxxxxxxxxx
> Cc: corbet@xxxxxxx; Matthew Gerlach <matthew.gerlach@xxxxxxxxxxxxxxx>
> Subject: RE: [PATCH v6 2/6] fpga: dfl: tracking port conntected with AFU
>
> > -----Original Message-----
> > From: Zhang, Tianfei <tianfei.zhang@xxxxxxxxx>
> > Sent: Wednesday, March 16, 2022 3:08 PM
> > To: Wu, Hao <hao.wu@xxxxxxxxx>; trix@xxxxxxxxxx; mdf@xxxxxxxxxx; Xu,
> > Yilun <yilun.xu@xxxxxxxxx>; linux-fpga@xxxxxxxxxxxxxxx;
> > linux-doc@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> > rdunlap@xxxxxxxxxxxxx
> > Cc: corbet@xxxxxxx; Zhang, Tianfei <tianfei.zhang@xxxxxxxxx>; Matthew
> > Gerlach <matthew.gerlach@xxxxxxxxxxxxxxx>
> > Subject: [PATCH v6 2/6] fpga: dfl: tracking port conntected with AFU
> >
>
> "conntected" -> "connected"
>
> > From: Tianfei zhang <tianfei.zhang@xxxxxxxxx>
> >
> > Introducing flags in dfl_fpga_cdev to track extensions or new features
> > discovered during DFL enumeration. It uses some lowest bits of flags
> > to track the port status which the AFU was connected to port device or
> > not. In legacy model, the AFU was connected to Port device, but in
> > "multiple VFs per PR slot" model, the AFU or PR slot without connected
> > to Port device directly.
>
> It's "Port with AFU vs "Port without AFU", so why we have this flag in container
> device not for each port device?
I think this is a global flag during the DFL enumeration.
After the DFL enumeration, we can know that the Port connected with AFU or not.
> and probably you need to describe why we need this flag.
The next patch will use those flags for VF creation.
> What I am thinking is
> that port driver can use this flag to decide if afu related interface will be visible
> or not...does it make more sense to have this flag for port device itself?
The different between "port with AFU" and "port without AFU" was that the AFU MMIO space add into
AFU driver or not. In "port without AFU" case, we cannot access the AFU via mmap API. But for both cases,
we still can access the port device by "/dev/dfl-port.h" device nodes.
The flag was used for VF creation. If we want to put the flag in port device, I think it only can add the flag in port device's dfl_feature_platform_data,
but I don't think this is a good idea.
>
>
> >
> > Signed-off-by: Matthew Gerlach <matthew.gerlach@xxxxxxxxxxxxxxx>
> > Signed-off-by: Tianfei zhang <tianfei.zhang@xxxxxxxxx>
> > ---
> > drivers/fpga/dfl.c | 11 ++++++++++-
> > drivers/fpga/dfl.h | 12 ++++++++++++
> > 2 files changed, 22 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c index
> > 599bb21d86af..712c53363fda 100644
> > --- a/drivers/fpga/dfl.c
> > +++ b/drivers/fpga/dfl.c
> > @@ -1124,8 +1124,10 @@ static void build_info_complete(struct
> > build_feature_devs_info *binfo) static int parse_feature_fiu(struct
> > build_feature_devs_info *binfo,
> > resource_size_t ofst)
> > {
> > + struct dfl_fpga_cdev *cdev = binfo->cdev;
> > int ret = 0;
> > u32 offset;
> > + u32 port;
> > u16 id;
> > u64 v;
> >
> > @@ -1160,8 +1162,15 @@ static int parse_feature_fiu(struct
> > build_feature_devs_info *binfo,
> > v = readq(binfo->ioaddr + NEXT_AFU);
> >
> > offset = FIELD_GET(NEXT_AFU_NEXT_DFH_OFST, v);
> > - if (offset)
> > + if (offset) {
> > + if (dfh_id_to_type(id) == PORT_ID) {
> > + port = FIELD_GET(PORT_CAP_PORT_NUM,
> > + readq(binfo->ioaddr +
> > PORT_HDR_CAP));
> > + cdev->flags |= dfl_feat_port_connect_afu(port);
> > + }
> > +
> > return parse_feature_afu(binfo, offset);
> > + }
> >
> > dev_dbg(binfo->dev, "No AFUs detected on FIU %d\n", id);
> >
> > diff --git a/drivers/fpga/dfl.h b/drivers/fpga/dfl.h index
> > 1fd493e82dd8..bc56b7e8c01b 100644
> > --- a/drivers/fpga/dfl.h
> > +++ b/drivers/fpga/dfl.h
> > @@ -461,6 +461,16 @@ int dfl_fpga_enum_info_add_irq(struct
> > dfl_fpga_enum_info *info,
> > unsigned int nr_irqs, int *irq_table); void
> > dfl_fpga_enum_info_free(struct dfl_fpga_enum_info *info);
> >
> > +/*
> > + * Bitfields in flags of dfl_fpga_cdev.
> > + *
> > + * 0 - (DFL_PORT_CONNECT_BITS -1): AFU was connected with Port device.
> > + * DFL_PORT_CONNECT_BITS - 63: reserved.
> > + */
> > +#define dfl_feat_port_connect_afu(port) (BIT_ULL(port)) #define
> > +DFL_PORT_CONNECT_BITS MAX_DFL_FPGA_PORT_NUM #define
> > +DFL_FEAT_PORT_CONNECT_MASK ((1UL <<
> > (DFL_PORT_CONNECT_BITS)) - 1)
> > +
> > /**
> > * struct dfl_fpga_cdev - container device of DFL based FPGA
> > *
> > @@ -470,6 +480,7 @@ void dfl_fpga_enum_info_free(struct
> > dfl_fpga_enum_info *info);
> > * @lock: mutex lock to protect the port device list.
> > * @port_dev_list: list of all port feature devices under this container device.
> > * @released_port_num: released port number under this container device.
> > + * @flags: extensions discovered during DFL enumeration.
> > */
> > struct dfl_fpga_cdev {
> > struct device *parent;
> > @@ -478,6 +489,7 @@ struct dfl_fpga_cdev {
> > struct mutex lock;
> > struct list_head port_dev_list;
> > int released_port_num;
> > + u64 flags;
> > };
> >
> > struct dfl_fpga_cdev *
> > --
> > 2.26.2
