From: Arnd Bergmann <arnd@arndb.de>
To: Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org,
bhelgaas@google.com, jgunthorpe@obsidianresearch.com,
sthokal@xilinx.com
Subject: Re: [PATCH v7 4/4] PCI: Generic Configuration Access Mechanism support
Date: Fri, 23 May 2014 21:22:18 +0200 [thread overview]
Message-ID: <201405232122.18995.arnd@arndb.de> (raw)
In-Reply-To: <1400863915-24135-5-git-send-email-will.deacon@arm.com>
On Friday 23 May 2014, Will Deacon wrote:
> +static void __iomem *pci_cfg_map_bus_ecam(struct pci_bus *bus,
> + unsigned int devfn,
> + int where)
> +{
> + struct pci_sys_data *sys = bus->sysdata;
> + struct pci_cfg_windows *cfg = sys->private_data;
> + resource_size_t idx = bus->number - cfg->bus_range.start;
> +
> + return cfg->win[idx] + ((devfn << PCI_CFG_ECAM_DEV_NUM) | where);
> +}
I just noticed that this function makes the code rather non-generic, because
struct pci_sys_data is the ARM specific structure that doesn't exist elsewhere,
and sys->private_data wouldn't typically point to struct pci_cfg_windows on
anything other than your generic PCI host.
I'd say let's drop this for now. I know it was my idea to do it like this,
but it seems it's more complex than I had hoped to get this right, and
I'd really prefer to merge the other three patches for 3.16 if possible.
We can factor it out later if we get more users.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v7 4/4] PCI: Generic Configuration Access Mechanism support
Date: Fri, 23 May 2014 21:22:18 +0200 [thread overview]
Message-ID: <201405232122.18995.arnd@arndb.de> (raw)
In-Reply-To: <1400863915-24135-5-git-send-email-will.deacon@arm.com>
On Friday 23 May 2014, Will Deacon wrote:
> +static void __iomem *pci_cfg_map_bus_ecam(struct pci_bus *bus,
> + unsigned int devfn,
> + int where)
> +{
> + struct pci_sys_data *sys = bus->sysdata;
> + struct pci_cfg_windows *cfg = sys->private_data;
> + resource_size_t idx = bus->number - cfg->bus_range.start;
> +
> + return cfg->win[idx] + ((devfn << PCI_CFG_ECAM_DEV_NUM) | where);
> +}
I just noticed that this function makes the code rather non-generic, because
struct pci_sys_data is the ARM specific structure that doesn't exist elsewhere,
and sys->private_data wouldn't typically point to struct pci_cfg_windows on
anything other than your generic PCI host.
I'd say let's drop this for now. I know it was my idea to do it like this,
but it seems it's more complex than I had hoped to get this right, and
I'd really prefer to merge the other three patches for 3.16 if possible.
We can factor it out later if we get more users.
Arnd
next prev parent reply other threads:[~2014-05-23 19:23 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-23 16:51 [PATCH v7 0/4] Support for Generic PCI Host Controller Will Deacon
2014-05-23 16:51 ` Will Deacon
2014-05-23 16:51 ` [PATCH v7 1/4] ARM: kconfig: allow PCI support to be selected with ARCH_MULTIPLATFORM Will Deacon
2014-05-23 16:51 ` Will Deacon
2014-05-23 16:51 ` [PATCH v7 2/4] PCI: ARM: add support for generic PCI host controller Will Deacon
2014-05-23 16:51 ` Will Deacon
2014-05-23 16:51 ` [PATCH v7 3/4] MAINTAINERS: add entry for generic PCI host controller driver Will Deacon
2014-05-23 16:51 ` Will Deacon
2014-05-23 16:51 ` [PATCH v7 4/4] PCI: Generic Configuration Access Mechanism support Will Deacon
2014-05-23 16:51 ` Will Deacon
2014-05-23 19:22 ` Arnd Bergmann [this message]
2014-05-23 19:22 ` Arnd Bergmann
2014-05-25 10:48 ` Will Deacon
2014-05-25 10:48 ` Will Deacon
2014-05-23 19:19 ` [PATCH v7 0/4] Support for Generic PCI Host Controller Arnd Bergmann
2014-05-23 19:19 ` Arnd Bergmann
2014-05-25 10:43 ` Will Deacon
2014-05-25 10:43 ` Will Deacon
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=201405232122.18995.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=jgunthorpe@obsidianresearch.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=sthokal@xilinx.com \
--cc=will.deacon@arm.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.