From: slash.tmp@free.fr (Mason)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 2/2] PCI: Add tango PCIe host bridge support
Date: Sun, 9 Apr 2017 15:09:42 +0200 [thread overview]
Message-ID: <b10928a1-7f74-2dee-678f-4cadc9f7f44b@free.fr> (raw)
In-Reply-To: <65114e62-7458-b6f7-327c-f07a5096a452@sigmadesigns.com>
On 29/03/2017 13:34, Marc Gonzalez wrote:
> + /*
> + * QUIRK #1
> + * Reads in configuration space outside devfn 0 return garbage.
> + */
> + if (devfn != 0) {
> + *val = ~0; /* Is this required even if we return an error? */
> + return PCIBIOS_FUNC_NOT_SUPPORTED; /* Error seems appropriate */
> + }
AFAICT, the relevant caller is:
bool pci_bus_read_dev_vendor_id(struct pci_bus *bus, int devfn, u32 *l,
int crs_timeout)
if (pci_bus_read_config_dword(bus, devfn, PCI_VENDOR_ID, l))
return false;
Therefore, I believe updating *val is unnecessary.
What matters is returning an error when appropriate.
PCIBIOS_FUNC_NOT_SUPPORTED fits my purpose.
> +
> + /*
> + * QUIRK #2
> + * The root complex advertizes a fake BAR, which is used to filter
> + * bus-to-system requests. Hide it from Linux.
> + */
> + if (where == PCI_BASE_ADDRESS_0 && bus->number == 0) {
> + *val = 0; /* 0 or ~0 to hide the BAR from Linux? */
> + return PCIBIOS_SUCCESSFUL; /* Should we return error or success? */
> + }
AFAICT, the relevant caller is:
int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type,
struct resource *res, unsigned int pos)
u32 l, sz, mask;
pci_read_config_dword(dev, pos, &l);
pci_write_config_dword(dev, pos, l | mask);
pci_read_config_dword(dev, pos, &sz);
pci_write_config_dword(dev, pos, l);
Several things are note-worthy:
1) __pci_read_base() ignores the config accessors return value.
Of the existing PCIBIOS errors, none seem to be a good fit for
my use-case (hiding a non-standard BAR).
Tangent:
Maybe I should set dev->non_compliant_bars = true; instead
of messing around in the accessor...
I would likely set the flag in a PCI_FIXUP_EARLY function.
/* Early fixups, before probing the BARs */
1b) Perhaps a generic error could be added to the PCIBIOS_*
error family, to signal that the requested operation was not
completed, and *val remains unchanged.
=> Maybe PCIBIOS_FAILURE or PCIBIOS_NOP ?
2) Some drivers are not aware that *val needs to be updated
for BAR accesses.
e.g. drivers/pci/host/pcie-altera.c
if altera_pcie_hide_rc_bar() is true, 'l' and 'sz' are not updated,
and therefore contain garbage (uninitialized stack variables).
I think we should apply the following trivial patch.
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -175,7 +175,7 @@ static inline unsigned long decode_bar(struct pci_dev *dev, u32 bar)
int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type,
struct resource *res, unsigned int pos)
{
- u32 l, sz, mask;
+ u32 l = 0, sz = 0, mask;
u64 l64, sz64, mask64;
u16 orig_cmd;
struct pci_bus_region region, inverted_region;
Regards.
next prev parent reply other threads:[~2017-04-09 13:09 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-29 11:11 [PATCH v3 0/2] Tango PCIe controller support Marc Gonzalez
2017-03-29 11:29 ` [PATCH v3 1/2] PCI: Add tango MSI " Marc Gonzalez
2017-03-29 12:29 ` Marc Zyngier
2017-03-29 13:16 ` Mason
2017-03-29 15:50 ` Mason
2017-03-29 11:34 ` [PATCH v3 2/2] PCI: Add tango PCIe host bridge support Marc Gonzalez
2017-03-29 12:19 ` Robin Murphy
2017-03-29 12:53 ` Mason
2017-03-29 14:33 ` Robin Murphy
2017-03-29 14:38 ` David Laight
2017-03-30 12:09 ` kbuild test robot
2017-04-03 14:51 ` Rob Herring
2017-04-09 13:09 ` Mason [this message]
2017-03-30 20:56 ` [PATCH v3 0/2] Tango PCIe controller support Mason
2017-03-31 22:05 ` Mason
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=b10928a1-7f74-2dee-678f-4cadc9f7f44b@free.fr \
--to=slash.tmp@free.fr \
--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