> -----Original Message----- > From: Wu, Hao <hao.wu@xxxxxxxxx> > Sent: Monday, April 18, 2022 9:56 AM > To: Zhang, Tianfei <tianfei.zhang@xxxxxxxxx>; Xu, Yilun <yilun.xu@xxxxxxxxx> > Cc: trix@xxxxxxxxxx; mdf@xxxxxxxxxx; linux-fpga@xxxxxxxxxxxxxxx; Matthew > Gerlach <matthew.gerlach@xxxxxxxxxxxxxxx> > Subject: RE: [PATCH v1] fpga: dfl: Allow Port to be linked to FME's DFL > > > > -----Original Message----- > > > From: Xu, Yilun <yilun.xu@xxxxxxxxx> > > > Sent: Sunday, April 17, 2022 12:18 AM > > > To: Zhang, Tianfei <tianfei.zhang@xxxxxxxxx> > > > Cc: Wu, Hao <hao.wu@xxxxxxxxx>; trix@xxxxxxxxxx; mdf@xxxxxxxxxx; > > > linux- fpga@xxxxxxxxxxxxxxx; Matthew Gerlach > > > <matthew.gerlach@xxxxxxxxxxxxxxx> > > > Subject: Re: [PATCH v1] fpga: dfl: Allow Port to be linked to FME's > > > DFL > > > > > > On Wed, Apr 13, 2022 at 05:15:19AM -0400, Tianfei Zhang wrote: > > > > From: Matthew Gerlach <matthew.gerlach@xxxxxxxxxxxxxxx> > > > > > > > > Currently we use PORTn_OFFSET to locate PORT DFLs, and PORT DFLs > > > > are not connected FME DFL. But for some cases (e.g. Intel Open > > > > FPGA Stack device), PORT DFLs are connected to FME DFL directly, > > > > so we don't need to search PORT DFLs via PORTn_OFFSET again. If > > > > BAR value of PORTn_OFFSET is 0x7 > > > > (FME_PORT_OFST_BAR_SKIP) then driver will skip searching the DFL > > > > for that port. > > > > > > > > Link: > > > > https://lore.kernel.org/linux-fpga/20220316070814.1916017-2-tianfe > > > > i.zh > > > > ang@xxxxxxxxx/ > > > > Signed-off-by: Matthew Gerlach <matthew.gerlach@xxxxxxxxxxxxxxx> > > > > Signed-off-by: Tianfei Zhang <tianfei.zhang@xxxxxxxxx> > > > > --- > > > > drivers/fpga/dfl-pci.c | 7 +++++++ > > > > drivers/fpga/dfl.h | 1 + > > > > 2 files changed, 8 insertions(+) > > > > > > > > diff --git a/drivers/fpga/dfl-pci.c b/drivers/fpga/dfl-pci.c index > > > > 717ac9715970..6347f31058f0 100644 > > > > --- a/drivers/fpga/dfl-pci.c > > > > +++ b/drivers/fpga/dfl-pci.c > > > > @@ -259,6 +259,13 @@ static int find_dfls_by_default(struct > > > > pci_dev > > *pcidev, > > > > */ > > > > bar = FIELD_GET(FME_PORT_OFST_BAR_ID, v); > > > > offset = FIELD_GET(FME_PORT_OFST_DFH_OFST, v); > > > > + if (bar >= PCI_STD_NUM_BARS || > > > > + bar == FME_PORT_OFST_BAR_SKIP) { > > > > > > Seems the second judgement will never be triggered? > > > > The value is overlap, but there are different meaning, " bar >= > > PCI_STD_NUM_BARS" means that the bar was invalid during the PCIe spec, > > "bar == FME_PORT_OFST_BAR_SKIP" means that the HW tell us that the SW > > should skip searching the DFL for the port. > > So first case is a HW bug we should return error, and second case is a valid case > to skip searching DFL, right? Yes, if "bar >= PCI_STD_NUM_BARS" return error is better. > > > > > > > > > Thanks > > > Yilun > > > > > > > + dev_dbg(&pcidev->dev, "skipping search DFL > > > for port %d on BAR %d\n", > > > > + i, bar); > > > > + continue; > > > > + } > > > > + > > > > start = pci_resource_start(pcidev, bar) + offset; > > > > len = pci_resource_len(pcidev, bar) - offset; > > > > > > > > diff --git a/drivers/fpga/dfl.h b/drivers/fpga/dfl.h index > > > > 53572c7aced0..e0f0abfbeb8c 100644 > > > > --- a/drivers/fpga/dfl.h > > > > +++ b/drivers/fpga/dfl.h > > > > @@ -91,6 +91,7 @@ > > > > #define FME_HDR_PORT_OFST(n) (0x38 + ((n) * 0x8)) > > > > #define FME_HDR_BITSTREAM_ID 0x60 > > > > #define FME_HDR_BITSTREAM_MD 0x68 > > > > +#define FME_PORT_OFST_BAR_SKIP 7 > > > > > > > > /* FME Fab Capability Register Bitfield */ > > > > #define FME_CAP_FABRIC_VERID GENMASK_ULL(7, 0) /* Fabric > > > version ID */ > > > > -- > > > > 2.26.2
