linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Robert Richter <rric@kernel.org>
To: Myron Stowe <myron.stowe@redhat.com>
Cc: bhelgaas@google.com, linux-pci@vger.kernel.org,
	suravee.suthikulpanit@amd.com, aravind.gopalakrishnan@amd.com,
	kim.naru@amd.com, andreas.herrmann3@amd.com,
	daniel@numascale.com, tglx@linutronix.de, mingo@redhat.com,
	hpa@zytor.com, x86@kernel.org, bp@suse.de, sp@numascale.com,
	linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/5] x86/PCI: Support additional MMIO range capabilities
Date: Tue, 29 Apr 2014 19:17:20 +0200	[thread overview]
Message-ID: <20140429171720.GL32718@rric.localhost> (raw)
In-Reply-To: <20140419025323.2408.88764.stgit@amt.stowe>

In addition to Boris I have the following:

On 18.04.14 20:53:23, Myron Stowe wrote:
> +#define AMD_PCIE_CF8(bus, dev, fn, reg) \
> +			(0x80000000 | \
> +			((reg & 0xF00) << 16) | \
> +			((bus & 0xF) << 16) | \
> +			((dev & 0x1F) << 11) | \
> +			((fn & 0x7) << 8) | \
> +			((reg & 0xFC)))

Make this a static function.

> +/* This version of read_pci_config allows reading registers in the ECS area */
> +static inline int _amd_read_pci_config(u8 bus, u8 slot, u8 fn, u32 offset)

No need to inline this, no need for a single tailing underscore.

> +{
> +	u32 value;
> +
> +	if ((!amd_early_ecs_enabled) && (offset > 0xFF))
> +		return -1;
> +
> +	outl(AMD_PCIE_CF8(bus, slot, fn, offset), 0xcf8);
> +	value = inl(0xcfc);
> +
> +	return value;

This design is broken. The return type does not match the functions
return value and you can't do error checking as -1 can be a value too.

Why reinventing this new instead of trying to reuse functions in
arch/x86/pci/direct.c/early.c or so?

Would an access via mmconfig space at this early stage possible? If so
this code could be skipped as we wouln't need it for fam10h (no early
access needed) nor fam15h or newer (mmconfig available).

> +}
> +
>  static struct pci_root_info __init *find_pci_root_info(int node, int link)
>  {
>  	struct pci_root_info *info;
> @@ -48,6 +81,9 @@ static struct pci_root_info __init *find_pci_root_info(int node, int link)
>  		if (info->node == node && info->link == link)
>  			return info;
>  
> +	pr_warn("AMD-Bus: WARNING: Failed to find root info for node %#x, link %#x\n",
> +		node, link);

As there might be (virtual) systems where this case is valid, I
wouldn't print anything here. We should only print things that exist
or error/warnings.

-Robert

> +
>  	return NULL;
>  }
>  
> @@ -118,6 +154,12 @@ static int __init early_fill_mp_bus_info(void)
>  
>  	pr_debug("Found AMD hostbridge at %x:%x.0\n", bus, slot);

  parent reply	other threads:[~2014-04-29 17:17 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-05 21:06 [PATCH 0/3] amd/pci: Add AMD hostbridge supports for newer AMD systems suravee.suthikulpanit
2014-03-05 21:06 ` [PATCH 1/3] amd/pci: Add supports for generic AMD hostbridges suravee.suthikulpanit
2014-03-05 21:06 ` [PATCH 2/3] amd/pci: Support additional MMIO ranges capabilities suravee.suthikulpanit
2014-03-20 17:33   ` Bjorn Helgaas
2014-03-05 21:06 ` [PATCH 3/3] amd/pci: Miscellaneous code clean up for early_fillup_mp_bus_info suravee.suthikulpanit
2014-03-05 21:24 ` [PATCH 0/3] amd/pci: Add AMD hostbridge supports for newer AMD systems Bjorn Helgaas
2014-03-06  2:13   ` Suravee Suthikulanit
2014-03-06  6:30     ` Suravee Suthikulpanit
2014-03-06 17:40       ` Bjorn Helgaas
2014-03-06 20:03         ` Suravee Suthikulpanit
2014-03-11 18:12           ` Bjorn Helgaas
2014-03-12 21:13             ` Bjorn Helgaas
2014-03-13  1:30               ` Myron Stowe
2014-03-14  2:06               ` Suravee Suthikulpanit
2014-03-17 17:18                 ` Bjorn Helgaas
2014-03-20 17:42                   ` Bjorn Helgaas
2014-04-19  2:53 ` [PATCH v2 0/5] x86/PCI: Add AMD hostbridge support " Myron Stowe
2014-04-19  2:53   ` [PATCH v2 1/5] x86/PCI: Add support for generic AMD hostbridges Myron Stowe
2014-04-19 11:31     ` Borislav Petkov
2014-04-28 21:10       ` Myron Stowe
2014-04-19  2:53   ` [PATCH v2 2/5] x86/PCI: Support additional MMIO range capabilities Myron Stowe
2014-04-19 13:52     ` Borislav Petkov
2014-04-20  7:59       ` Borislav Petkov
2014-04-25 22:24         ` Myron Stowe
2014-04-26  9:10           ` Borislav Petkov
2014-04-28 20:50             ` Bjorn Helgaas
2014-04-28 21:40               ` Borislav Petkov
2014-04-29  7:33                 ` Andreas Herrmann
2014-04-29 10:20                   ` Borislav Petkov
2014-04-29 13:07                     ` Steffen Persvold
2014-04-29 15:16                     ` Suravee Suthikulanit
2014-04-29 19:14                       ` Borislav Petkov
2014-04-29 21:40                         ` Myron Stowe
2014-04-30  7:00                           ` Robert Richter
2014-04-30  7:50                             ` Suravee Suthikulpanit
2014-04-30  9:51                               ` Robert Richter
2014-04-30 23:03                             ` Myron Stowe
2014-04-29 11:19                   ` Robert Richter
2014-04-29  7:06               ` Jan Beulich
2014-04-29  3:04           ` Suravee Suthikulanit
2014-04-28 21:19       ` Myron Stowe
2014-04-29  2:47         ` Suravee Suthikulanit
2014-04-29 17:17     ` Robert Richter [this message]
2014-04-30  6:41     ` Robert Richter
2014-04-19  2:53   ` [PATCH v2 3/5] x86/PCI: Miscellaneous code clean up for early_fillup_mp_bus_info Myron Stowe
2014-04-20  8:02     ` Borislav Petkov
2014-04-28 21:21       ` Myron Stowe
2014-04-19  2:53   ` [PATCH v2 4/5] ACPI/PCI: Warn if we have to "guess" host bridge node information Myron Stowe
2014-04-20 10:21     ` Borislav Petkov
2014-04-28 21:24       ` Myron Stowe
2014-04-29 19:16         ` Borislav Petkov
2014-04-19  2:53   ` [PATCH v2 5/5] PCI: Remove redundant 'quirk_amd_nb_node' Myron Stowe
2014-04-20 10:54     ` Borislav Petkov
2014-04-20 13:44       ` Myron Stowe
2014-04-21 16:53         ` Daniel J Blueman
2014-04-29  2:02           ` Suravee Suthikulanit
2014-04-29 19:29             ` Bjorn Helgaas
2014-04-28 21:28       ` Myron Stowe

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=20140429171720.GL32718@rric.localhost \
    --to=rric@kernel.org \
    --cc=andreas.herrmann3@amd.com \
    --cc=aravind.gopalakrishnan@amd.com \
    --cc=bhelgaas@google.com \
    --cc=bp@suse.de \
    --cc=daniel@numascale.com \
    --cc=hpa@zytor.com \
    --cc=kim.naru@amd.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=myron.stowe@redhat.com \
    --cc=sp@numascale.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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).