From: "Matt Carlson" <mcarlson@broadcom.com>
To: "Ben Hutchings" <bhutchings@solarflare.com>
Cc: "Matthew Carlson" <mcarlson@broadcom.com>,
"Stephen Hemminger" <shemminger@vyatta.com>,
"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"andy@greyhouse.net" <andy@greyhouse.net>,
"Michael Chan" <mchan@broadcom.com>
Subject: Re: [PATCH 1/7] pci: Add PCI LRDT tag size and section size
Date: Thu, 25 Feb 2010 11:48:28 -0800 [thread overview]
Message-ID: <20100225194828.GA6309@xw6200.broadcom.net> (raw)
In-Reply-To: <1267126561.2107.13.camel@achroite.uk.solarflarecom.com>
On Thu, Feb 25, 2010 at 11:36:01AM -0800, Ben Hutchings wrote:
> On Thu, 2010-02-25 at 11:11 -0800, Matt Carlson wrote:
> > On Thu, Feb 25, 2010 at 10:53:45AM -0800, Stephen Hemminger wrote:
> [...]
> > > Shouldn't the function take the pci resource not just the register.
> >
> > The functions are designed to operate on a buffer of VPD data, not from
> > the hardware directly.
> >
> > > And finally, how common is this or is it just something unique to your hw.
> >
> > The VPD area is defined by the PCI specs, in the section noted in the
> > comment above. The definitions and functions introduced in this patchset
> > should be usable by any driver. I stopped short of modifying other
> > drivers, but I certainly could have.
> >
> > However, there are two approaches taken as to how the VPD data is
> > extracted and used. Drivers like tg3 and bnx2 load the VPD data into
> > a buffer and operate on that. Other drivers like niu navigate the VPD
> > by loading a dword at a time. This API would cover the former
> > implementation which I've only found to be used by the tg3 and bnx2
> > drivers so far.
>
> VPD *access* can be done generically through pci_read_vpd() and
> pci_write_vpd(), which use struct pci_vpd_ops. Currently the only
> implementation of pci_vpd_ops is for standard PCI 2.2 VPD. Other
> implementations could be provided for PCI 2.1 VPD or non-standard access
> methods.
>
> VPD *parsing* is currently left to user-space (lspci etc.) and to a few
> drivers that need it for some reason.
>
> I notice that bnx2 and tg3 are not using pci_read_vpd(). Presumably
> this is an optimisation?
The tg3 driver does use pci_read_vpd() for those cases where
(magic != TG3_EEPROM_MAGIC). But yes, it is an optimization.
prev parent reply other threads:[~2010-02-25 19:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-25 18:19 [PATCH 1/7] pci: Add PCI LRDT tag size and section size Matt Carlson
2010-02-25 18:53 ` Stephen Hemminger
2010-02-25 19:11 ` Matt Carlson
2010-02-25 19:36 ` Ben Hutchings
2010-02-25 19:48 ` Matt Carlson [this message]
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=20100225194828.GA6309@xw6200.broadcom.net \
--to=mcarlson@broadcom.com \
--cc=andy@greyhouse.net \
--cc=bhutchings@solarflare.com \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-pci@vger.kernel.org \
--cc=mchan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=shemminger@vyatta.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.