mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Ben Hutchings <bhutchings@solarflare.com>
Cc: Matthew Wilcox <matthew@wil.cx>,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH 0/2] PCI 2.1 VPD support
Date: Mon, 16 Jun 2008 16:13:31 -0700	[thread overview]
Message-ID: <200806161613.31410.jbarnes@virtuousgeek.org> (raw)
In-Reply-To: <20080613212743.GZ11300@solarflare.com>

On Friday, June 13, 2008 2:27 pm Ben Hutchings wrote:
> PCI 2.1 specifies a way to provide VPD in the expansion ROM.  This patch
> series exposes that in the same way as PCI 2.2 VPD.
>
> I do not have any production devices with VPD in ROM so I reflashed a NIC
> with an image including it.  This code should be tested against some
> production ROMs since I may have misinterpreted the specification both
> when reading and writing!

I'll have to dig around to see if I can find any here for testing.

> There are two remaining aspects of this that I'm not quite happy about:
>
> 1. I understand that the expansion ROM may share a decoder with BAR 0,
> which makes expansion ROM access dangerous when a driver is loaded.  The
> sysfs "rom" attribute must be specifically read-enabled by writing to it,
> which I assume is intended to protect against this.  Perhaps
> pci_vpd_pci21_read() should test pdev->rom_attr_enabled?

Right, that can get a little ugly...  In the case of 2.1 VPD, it does make 
sense to require that the ROM be enabled before poking at it, and is 
definitely safer.

> 2. PCI resource allocation may fail during pci_scan_device() and
> therefore I could not insert the call to pci_vpd_pci21_init() there.
> Instead I added it to pci_create_sysfs_dev_files() - but I don't really
> think this function should be probing.  Is there a better place to add
> the call?

Well, one thing we could do is try to either use the allocated ROM or assign 
it later on, then cache the VPD data.  That way we wouldn't have to worry 
about accessing it with the rom enabled later on.  But that would eat up 
memory.

You could also just make the pci_vpd_pci21_init a device_initcall so it can 
fill in the dev->vpd before the PCI sysfs late_initcall.  Or we could just 
stuff it into pci_init in the same loop that calls the final fixups.

Other than that, things look pretty good to me.  I'd definitely like to get 
this tested on at least one PCI 2.1 device w/VPD before pushing though.  You 
know what they say about untested code. :)

Thanks,
Jesse

      reply	other threads:[~2008-06-16 23:13 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-13 21:27 Ben Hutchings
2008-06-16 23:13 ` Jesse Barnes [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=200806161613.31410.jbarnes@virtuousgeek.org \
    --to=jbarnes@virtuousgeek.org \
    --cc=bhutchings@solarflare.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=matthew@wil.cx \
    /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

all inboxes | Powered by JetHome®