From: Bjorn Helgaas <helgaas@kernel.org>
To: "Zytaruk, Kelly" <Kelly.Zytaruk@amd.com>
Cc: "bhelgaas@google.com" <bhelgaas@google.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Alex Williamson <alex.williamson@redhat.com>,
Yu Zhao <yuzhao@google.com>
Subject: Re: [PATCH] PCI: Support SRIOV on Legacy EndPoint device
Date: Fri, 5 Feb 2016 10:59:55 -0600 [thread overview]
Message-ID: <20160205165955.GA31904@localhost> (raw)
In-Reply-To: <CY1PR12MB026259439AA9689B7326F4B5FED20@CY1PR12MB0262.namprd12.prod.outlook.com>
On Fri, Feb 05, 2016 at 04:50:11PM +0000, Zytaruk, Kelly wrote:
>
>
> > -----Original Message-----
> > From: Bjorn Helgaas [mailto:helgaas@kernel.org]
> > Sent: Friday, February 05, 2016 11:47 AM
> > To: Zytaruk, Kelly
> > Cc: bhelgaas@google.com; linux-pci@vger.kernel.org; linux-
> > kernel@vger.kernel.org; Alex Williamson; Yu Zhao
> > Subject: Re: [PATCH] PCI: Support SRIOV on Legacy EndPoint device
> >
> > On Thu, Feb 04, 2016 at 04:21:08PM +0000, Zytaruk, Kelly wrote:
> > > > -----Original Message-----
> > > > From: Bjorn Helgaas [mailto:helgaas@kernel.org]
> > > > Sent: Thursday, February 04, 2016 10:14 AM
> > > > To: Zytaruk, Kelly
> > > > Cc: bhelgaas@google.com; linux-pci@vger.kernel.org; linux-
> > > > kernel@vger.kernel.org; Alex Williamson; Yu Zhao
> > > > Subject: Re: [PATCH] PCI: Support SRIOV on Legacy EndPoint device
> > > >
> > > > [+cc Alex, Yu (participants in previous discussion)]
> > > >
> > > > Hi Kelly,
> > > >
> > > > On Thu, Feb 04, 2016 at 09:48:26AM -0500, Kelly Zytaruk wrote:
> > > > > Some AMD GPUs have hardware support for grapics SRIOV.
> > > > > If the GPU has a display output then the GPU needs to support
> > > > > Legacy VGA
> > > > operation.
> > > > > If CLASS_CODE = VGA then the device should have a Port Type =
> > > > > Legacy
> > > > EndPoint.
> > > > > Therefore in order to enable SRIOV on a GPU with a display output
> > > > LEGACY_END_POINT is supported as a valid Port Type.
> > > > >
> > > > > Signed-off-by: Kelly Zytaruk <kelly.zytaruk@amd.com>
> > > >
> > > > We had an interesting discussion about this two years ago:
> > > >
> > http://lkml.kernel.org/r/B756807489D6244883AC0B799A6EEC15EAB2E8@stor
> > > > e
> > > > xdag02.amd.com
> > >
> > > Unfortunately 2 years ago I couldn't complete your request as it would
> > > have disclosed Information about an unannounced technology that we
> > > were working on. We have recently made that technology public and I
> > > can now send you the requested information.
> >
> > > > Please include a reference to that discussion in your changelog. In
> > > > that discussion, I also asked for some details (dmesg and lspci
> > > > info) that motivate the change, so please collect and add a reference to
> > them as well.
> > >
> > > The information that you ask for is included below. I have
> > > abbreviated it so that this does not become a huge email. I can send
> > > full logs if you want them.
> >
> > Can you open a bugzilla at http://bugzilla.kernel.org and attach the full logs
> > there? Then we can include the URL in your patch changelog.
>
> I have never worked with bugzilla before but I will check it out. So you
> want me to take the bugzilla URL and paste it into the comments of my
> patch? Or is this something that you will do?
Put it in the bugzilla drivers/PCI category. Let me know if you have
any bugzilla troubles. It should be pretty self-explanatory. Please
attach the files rather than pasting them in the text box.
If you could include the bugzilla URL in the changelog of a revised
patch, that would be great.
> > > > It's not clear to me why we check the device type at all. If
> > > > there's no spec restriction on the types of devices that can have an
> > > > SR-IOV capability, we should consider removing the test altogether
> > > > (Alex mentioned this possiblity in the earlier discussion).
> > >
> > > I am as well not clear why the check is in there. I would be just as
> > > happy either adding TYPE_LEG_END or removing the check all together.
> > > I don't know what the side effects of removing the check would be. I
> > > don't have any sriov devices other than a graphics card to test with
> > > so I wouldn't be able to test other scenarios.
> >
> > If we don't have a reason to do the check, I think we should just remove it
> > altogether.
>
> So instead of my proposed change do you want me to just remove the check
> completely and submit a patch for that?
Please.
Bjorn
next prev parent reply other threads:[~2016-02-05 16:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-04 14:48 [PATCH] PCI: Support SRIOV on Legacy EndPoint device Kelly Zytaruk
2016-02-04 15:14 ` Bjorn Helgaas
2016-02-04 16:21 ` Zytaruk, Kelly
2016-02-05 16:46 ` Bjorn Helgaas
2016-02-05 16:50 ` Zytaruk, Kelly
2016-02-05 16:59 ` Bjorn Helgaas [this message]
-- strict thread matches above, loose matches on Subject: below --
2016-02-04 15:08 Zytaruk, Kelly
2016-02-09 18:08 kelly.zytaruk
2016-02-29 18:00 ` Bjorn Helgaas
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=20160205165955.GA31904@localhost \
--to=helgaas@kernel.org \
--cc=Kelly.Zytaruk@amd.com \
--cc=alex.williamson@redhat.com \
--cc=bhelgaas@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=yuzhao@google.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).