linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: thomas.petazzoni@free-electrons.com (Thomas Petazzoni)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/4] pci: mvebu: emulate an empty capability list
Date: Wed, 22 May 2013 16:55:29 +0200	[thread overview]
Message-ID: <20130522165529.64174e06@skate> (raw)
In-Reply-To: <CAErSpo6gFf9ou-VtZ=F0+1GqcSoPS_dDMGphhgv=8mD602=BRA@mail.gmail.com>

Dear Bjorn Helgaas,

On Wed, 22 May 2013 08:39:03 -0600, Bjorn Helgaas wrote:

> > emulation to emulate an empty capability list. It might be later
> > extended to expose things like the PCI Express Capability header, but
> > an empty capability list is sufficient for now.
> >
> > lspci -v now shows the much nicer:
> >
> >   Capabilities: [40] #00 [0000]
> 
> It'd be even better if you could make the Capabilities List bit in the
> Device Status register be zero.  Then lspci wouldn't even try to read
> the Capabilities Pointer at 0x34, and you wouldn't have to deal with
> reads of 0x40.

The Device Status register is emulated with an initial value of zero.
Then, whenever the Linux PCI core writes into it, those writes are
preserved. So to me, it looks like the Linux PCI core might be setting
this Capabilities List bit, and later re-reads it and finds it to be
set to 1.

Should this bit be emulated as a read-only bit (it's not made explicit
for this particular bit in the PCI-to-PCI bridge specification that I
have in front of me) ? Or even the entire Device Status register ?

Thanks for your comments!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

  reply	other threads:[~2013-05-22 14:55 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-22 13:12 [PATCH 0/4] Marvell PCIe driver improvements Thomas Petazzoni
2013-05-22 13:12 ` [PATCH 1/4] pci: mvebu: no longer fake the slot location of downstream devices Thomas Petazzoni
2013-05-22 13:12 ` [PATCH 2/4] pci: mvebu: allow the enumeration of devices beyond physical bridges Thomas Petazzoni
2013-05-22 14:31   ` Bjorn Helgaas
2013-05-22 13:12 ` [PATCH 3/4] pci: mvebu: emulate an empty capability list Thomas Petazzoni
2013-05-22 14:39   ` Bjorn Helgaas
2013-05-22 14:55     ` Thomas Petazzoni [this message]
2013-05-22 13:12 ` [PATCH 4/4] pci: mvebu: fix the emulation of the status register Thomas Petazzoni
2013-05-22 14:49   ` Bjorn Helgaas
2013-05-22 13:43 ` [PATCH 0/4] Marvell PCIe driver improvements Jason Cooper
2013-05-22 15:09   ` Gregory CLEMENT
2013-05-22 15:18     ` Jason Cooper
2013-05-23  0:13 ` Willy Tarreau
2013-05-23  6:35   ` Thomas Petazzoni
2013-05-23  6:52     ` Willy Tarreau
2013-05-23 16:46   ` Jason Gunthorpe
2013-05-23 18:57     ` Thomas Petazzoni

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=20130522165529.64174e06@skate \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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).