From: "Sean O. Stalley" <sean.stalley@intel.com>
To: David Daney <ddaney@caviumnetworks.com>
Cc: David Daney <ddaney.cavm@gmail.com>, Martin Mares <mj@ucw.cz>,
Bjorn Helgaas <bhelgaas@google.com>,
linux-pci@vger.kernel.org, David Daney <david.daney@cavium.com>
Subject: Re: [PATCH] Add lspci support for Enhanced Allocation Capability.
Date: Mon, 14 Dec 2015 11:07:21 -0800 [thread overview]
Message-ID: <20151214190720.GA2944@sean.stalley.intel.com> (raw)
In-Reply-To: <566B78B6.4070109@caviumnetworks.com>
On Fri, Dec 11, 2015 at 05:30:30PM -0800, David Daney wrote:
> On 12/11/2015 05:13 PM, Sean O. Stalley wrote:
> >Thanks for doing this. I tried it out & everything worked well for me.
> >Only a couple things:
> >
> >The memory regions described by EA also show up before the EA Capability
> >and appear as virtual, ex:
> > Region 0: [virtual] Memory at 80000000 ...
>
> We are just dumping out the config space. lspci doesn't really know
> where the kernel gets the reported BAR values.
>
> I don't think we want to suppress the dumping of the BARs, or the
> kernel's interpretation thereof.
That's a good point. I guess we should keep dumping the BARs.
I still think we should change the [virtual] flag though.
lspci assumes that if the OS reports a region and configspace doesn't,
that the region came from an SR-IOV entry.
Before EA, this was a safe assumption. Now regions can come from EA entries,
we can't assume that a region with no BAR is always virtual.
Also, I just noticed that show_size() assumes power-of-2 sizes for regions.
It doesn't look like it will display some EA-supported sizes correctly
(Ex: 1110 bytes would get truncated and show up as " [size=1K]").
> >I don't think we want these regions to be flagged as virtual.
> >I think this happens because lspci can't read/write to the BAR region,
> >and so it assumes it's looking at a VF.
> >
> >The rest of my gripes are minor syntax stuff. see inline.
> >
> >Thanks again,
> >Sean
> >
> >On Fri, Dec 11, 2015 at 02:27:25PM -0800, David Daney wrote:
> >>From: David Daney <david.daney@cavium.com>
> >>
> [...]
> >>--- a/ls-caps.c
> >>+++ b/ls-caps.c
> >>@@ -1254,6 +1254,145 @@ cap_sata_hba(struct device *d, int where, int cap)
> >> printf(" BAR??%d\n", bar);
> >> }
> >>
> [...]
> >>+static void cap_ea(struct device *d, int where, int cap)
> >>+{
> >>+ unsigned int entry;
> >>+ int entry_base = where + 4;
> >>+ unsigned int num_entries = BITS((unsigned int)cap, 0, 6);
> >>+ u8 htype = get_conf_byte(d, PCI_HEADER_TYPE) & 0x7f;
> >>+
> >>+ printf("Enhanced Allocation: Num Entries=%u", num_entries);
> >CamelCase.
>
> Those are the names from the specification, I would like to keep
> them in some form. As noted below, it may be desirable to squash it
> to "NumEntries"
Agreed. see below.
> >>+ if (htype == PCI_HEADER_TYPE_BRIDGE) {
> >>+ byte fixed_sub, fixed_sec;
> >>+
> >>+ entry_base += 4;
> >>+ if (!config_fetch(d, where + 4, 2)) {
> >>+ printf("\n");
> >>+ return;
> >>+ }
> >>+ fixed_sec = get_conf_byte(d, where + 4);
> >>+ fixed_sub = get_conf_byte(d, where + 4);
> >>+ printf(", secondary=%d, subordinate=%d", fixed_sec, fixed_sub);
> >>+ }
> >>+ printf("\n");
> >>+ if (verbose < 2)
> >>+ return;
> >>+
> >>+ for (entry = 0; entry < num_entries; entry++) {
> >>+ int max_offset_high_pos, has_base_high, has_max_offset_high;
> >>+ u32 entry_header;
> >>+ u32 base, max_offset;
> >>+ unsigned int es, bei, pp, sp, e, w;
> >>+
> >>+ if (!config_fetch(d, entry_base, 4))
> >>+ return;
> >>+ entry_header = get_conf_long(d, entry_base);
> >>+ es = BITS(entry_header, 0, 3);
> >>+ bei = BITS(entry_header, 4, 4);
> >>+ pp = BITS(entry_header, 8, 8);
> >>+ sp = BITS(entry_header, 16, 8);
> >>+ w = BITS(entry_header, 30, 1);
> >>+ e = BITS(entry_header, 31, 1);
> >>+ if (!config_fetch(d, entry_base + 4, es * 4))
> >>+ return;
> >>+ printf("\t\tEntry-%u: Enable%c Writable%c, Entry Size=%u\n", entry,
> >I would change this line to:
> > printf("\t\tEntry %u: Enable%c Writable%c, EntrySize=%u\n", ...);
>
> We could do that. I would let others decide if squashing "Entry
> Size" to "EntrySize" is desirable.
Sounds good. Lets see what others want.
I don't care too much either way,
I just thought CamelCase would make EA stuff slightly easier to grep.
> > Changes: ^ ^
> > "-" after Entry to a " " (to match the "Region %i" used for BARs)
> > make EntrySize CamelCase (to match the other fields in lspci)
> [...]
> >>+ printf("\n");
> >>+ printf("\t\t\t Primary Properties (PP): %s\n", cap_ea_property(pp));
> >>+ printf("\t\t\t Secondary Properties (SP): %s\n", cap_ea_property(sp));
> >"PP" & "SP" are probably sufficient, I don't think we need to write the whole thing out.
> >
> >Also, for the case where the Primary property is valid, can we hide the Secondary property if it is 0xFF?
> >My concern is that people may read the "entry unavailable for use" line as a warning and think something is wrong.
> >Maybe it would be better to make it say "Secondary Properties (SP): Not Present", or something similar.
> >
>
> That is a good point. I will try something like that.
>
> >>+
> >>+ base = get_conf_long(d, entry_base + 4);
> >>+ has_base_high = ((base & 2) != 0);
> >>+ base &= ~3;
> >>+
> >>+ max_offset = get_conf_long(d, entry_base + 8);
> >>+ has_max_offset_high = ((max_offset & 2) != 0);
> >>+ max_offset |= 3;
> >>+ max_offset_high_pos = entry_base + 12;
> >>+
> >>+ printf("\t\t\t Base: ");
> >>+ if (has_base_high) {
> >>+ u32 base_high = get_conf_long(d, entry_base + 12);
> >>+
> >>+ printf("%x", base_high);
> >>+ max_offset_high_pos += 4;
> >>+ }
> >>+ printf("%08x\n", base);
> >>+
> >>+ printf("\t\t\t Max Offset: ");
> >CamelCase.
>
> Again, I am trying to match the wording of the specification.
> Although in this case I think I got it wrong. It should probably be
> squashed to "MaxOffset'
>
> [...]
>
> Thanks for reviewing it.
>
> David Daney
>
next prev parent reply other threads:[~2015-12-14 19:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-11 22:27 [PATCH] Add lspci support for Enhanced Allocation Capability David Daney
2015-12-12 1:13 ` Sean O. Stalley
2015-12-12 1:30 ` David Daney
2015-12-14 19:07 ` Sean O. Stalley [this message]
2015-12-12 1:18 ` David Daney
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=20151214190720.GA2944@sean.stalley.intel.com \
--to=sean.stalley@intel.com \
--cc=bhelgaas@google.com \
--cc=david.daney@cavium.com \
--cc=ddaney.cavm@gmail.com \
--cc=ddaney@caviumnetworks.com \
--cc=linux-pci@vger.kernel.org \
--cc=mj@ucw.cz \
/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).