[lkml]   [2020]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v3 05/18] dmaengine: idxd: add IMS support in base driver
On Wed, Sep 30 2020 at 15:51, Jason Gunthorpe wrote:

> On Wed, Sep 30, 2020 at 08:47:00PM +0200, Thomas Gleixner wrote:
>> > + pci_read_config_dword(pdev, SIOVCAP(dvsec), &val32);
>> > + if ((val32 & 0x1) && idxd->hw.gen_cap.max_ims_mult) {
>> > + idxd->ims_size = idxd->hw.gen_cap.max_ims_mult * 256ULL;
>> > + dev_dbg(dev, "IMS size: %u\n", idxd->ims_size);
>> > + set_bit(IDXD_FLAG_SIOV_SUPPORTED, &idxd->flags);
>> > + dev_dbg(&pdev->dev, "IMS supported for device\n");
>> > + return;
>> > + }
>> > +
>> > + dev_dbg(&pdev->dev, "SIOV unsupported for device\n");
>> It's really hard to find the code inside all of this dev_dbg()
>> noise. But why is this capability check done in this driver? Is this
>> capability stuff really IDXD specific or is the next device which
>> supports this going to copy and pasta the above?
> It is the weirdest thing, IMHO. Intel defined a dvsec cap in their
> SIOV cookbook, but as far as I can see it serves no purpose at
> all.

Why am I not surprised?

> Last time I asked I got some unclear mumbling about "OEMs".

See above.

But it reads the IMS storage array size out of this capability, so it
looks like it has some value.

> I expect you'll see all Intel drivers copying this code.

Just to set the expectations straight:

1) Has this capability stuff any value aside of being mentioned in
the SIOV cookbook?

2) If it has no value, then just remove the mess

3) If it has value then this wants to go to the PCI core and fill in
some SIOV specific data structure when PCI evaluates the
capabilities. Or at least have a generic function which can be
called by the magic SIOV capable drivers.



 \ /
  Last update: 2020-09-30 23:49    [W:0.067 / U:19.680 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site