All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Richter <robert.richter@amd.com>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Yinghai Lu <yhlu.kernel@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
	LKML <linux-kernel@vger.kernel.org>,
	Andi Kleen <andi@firstfloor.org>
Subject: Re: [PATCH] x86: Add PCI extended config space access for AMD Barcelona
Date: Mon, 2 Jun 2008 16:19:29 +0200	[thread overview]
Message-ID: <20080602141928.GH23679@erda.amd.com> (raw)
In-Reply-To: <20080528120253.26fcdb9d@infradead.org>

Arjan,

On 28.05.08 12:02:53, Arjan van de Ven wrote:
> Comment 1:
> Can we make the 256/4096 thing conditional on actually having the
> feature somehow? (while not making the code TOO ugly)

In the first version I had 2 functions also. The patch have had lots
of duplicate code or inline functions. Since the conditional check is
already in raw_pci_* I decided to not implement an additional check
and use only one function.

int raw_pci_read(unsigned int domain, unsigned int bus, unsigned int devfn,
                                                int reg, int len, u32 *val)
{
	if (reg < 256 && raw_pci_ops)
	   return raw_pci_ops->read(domain, bus, devfn, reg, len, val);
	   if (raw_pci_ext_ops)
	      return raw_pci_ext_ops->read(domain, bus, devfn, reg, len, val);
	      return -EINVAL;
}

That leaves as a difference to the basic access is the shift left of
bits 8:11 in the PCI_CONF1_ADDRESS macro. Functional the new macro is
the same and the overhead for this is small. So I see keeping all code
in one function as the best solution.

> Comment 2: 
> The cpu_has_XXX is a bit dubious; while it's dependent on your cpu
> model right now, I'm a bit hesitant to consider a PCI feature something
> that belongs in the cpu_has_XXX namespace. (Yes I know PCI is moving
> into the cpu package, but on a logical level it seems just the wrong
> place).
> Do we need a platform_has_XXX namespace for things like this?

An alternative implementation would be here to use a check something
like pci_probe & PCI_HAS_EXT_CFG. If needed, I will send an updated
patch.

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center
email: robert.richter@amd.com


  reply	other threads:[~2008-06-02 14:19 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-23 12:46 Enable mmconf access to PCI ECS for all AMD fam10h systems Robert Richter
2008-05-23 17:57 ` Yinghai Lu
2008-05-23 18:18   ` Arjan van de Ven
2008-05-23 19:06     ` Yinghai Lu
2008-05-26 18:06     ` Robert Richter
2007-09-03  8:17       ` [PATCH] x86: Add PCI extended config space access for AMD Barcelona Robert Richter
2008-05-28 19:02         ` Arjan van de Ven
2008-06-02 14:19           ` Robert Richter [this message]
2008-06-03  2:35             ` Arjan van de Ven
2008-06-03  7:25               ` Robert Richter
2008-06-12 18:19                 ` [PATCH 1/2] x86/pci: Renaming k8-bus_64.c to amd_bus.c Robert Richter
2008-06-12 19:51                   ` Yinghai Lu
2008-06-13 12:47                     ` Robert Richter
2008-06-18  7:46                   ` Ingo Molnar
2008-06-19 16:02                   ` Robert Richter
2008-06-12 18:19                 ` [PATCH 2/2] x86: Move PCI IO ECS code to x86/pci Robert Richter
2008-06-12 19:50                   ` Yinghai Lu
2008-06-13 16:19                     ` Robert Richter
2008-06-13 17:02                   ` Glauber Costa
2008-06-13 18:16                     ` Robert Richter
2008-06-13 18:26                       ` Glauber Costa
2008-06-18  7:51                       ` Ingo Molnar
2008-06-18  7:47                   ` Ingo Molnar
2008-06-02  9:09         ` [PATCH] x86: Add PCI extended config space access for AMD Barcelona Ingo Molnar
2008-06-02 13:56           ` Robert Richter
2008-06-02 20:31         ` Yinghai Lu
2008-06-03  7:35           ` Robert Richter

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=20080602141928.GH23679@erda.amd.com \
    --to=robert.richter@amd.com \
    --cc=andi@firstfloor.org \
    --cc=arjan@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=yhlu.kernel@gmail.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.