From: Ray Jui <rjui@broadcom.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Marc Zyngier <marc.zyngier@arm.com>,
Hauke Mehrtens <hauke@hauke-m.de>, <linux-kernel@vger.kernel.org>,
<bcm-kernel-feedback-list@broadcom.com>,
<linux-pci@vger.kernel.org>
Subject: Re: [PATCH v4 2/5] PCI: iproc: Add PAXC interface support
Date: Fri, 27 Nov 2015 12:56:05 -0800 [thread overview]
Message-ID: <5658C365.5080209@broadcom.com> (raw)
In-Reply-To: <2502233.oJMLi3GpfH@wuerfel>
Hi Arnd,
On 11/27/2015 12:22 PM, Arnd Bergmann wrote:
> On Friday 27 November 2015 09:37:45 Ray Jui wrote:
>>
>> +static const struct of_device_id iproc_pcie_of_match_table[] = {
>> + {
>> + .compatible = "brcm,iproc-pcie",
>> + .data = (int *)IPROC_PCIE_PAXB,
>> + }, {
>> + .compatible = "brcm,iproc-pcie-paxc",
>> + .data = (int *)IPROC_PCIE_PAXC,
>> + },
>> + { /* sentinel */ }
>> +};
>> +MODULE_DEVICE_TABLE(of, iproc_pcie_of_match_table);
>
> You seem to only need the identifiers in order to set a single
> pointer, so just point to that array directly.
Not just a single pointer. This sets the iProc PCIe interface type,
which is an enum. Based on the interface type, both the iProc PCIe core
driver and the iProc PCIe MSI driver can 1) load the correct set of
register offsets; 2) skip/invoke some of the link detection, controller
reset related behaviors; 3) setting up the correct number of MSI event
queue regions and MSI address regions.
> Alternatively,
> do the more common thing and point to a structure of function
> pointers and have different implementations of the low-level
> access functions there.
I thought about replacing the reset and link check functions in
pcie-iproc.c with callbacks but felt it has not reached the point where
we need callbacks to completely differentiate the operations. I'm hoping
to wait until I see the next revision of PAXC (PAXC v2) implementation
in the next-gen iProc SoC to make the call....
Note even with the callback approach, it would not change much of the
pcie-iproc-platform.c here, which still needs to pass in just the
interface information but no more than that. Main reason being the core
driver and MSI drivers are used by both the platform driver and BCMA
driver, and I do not want to duplicate the callback implementation at
the bus driver level.
>
> Arnd
>
Thanks,
Ray
next prev parent reply other threads:[~2015-11-27 20:56 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-27 17:37 [PATCH v4 0/5] Add iProc PCIe PAXC and MSI support Ray Jui
2015-11-27 17:37 ` [PATCH v4 1/5] PCI: iproc: Update iProc PCIe device tree binding Ray Jui
2015-11-27 17:37 ` [PATCH v4 2/5] PCI: iproc: Add PAXC interface support Ray Jui
2015-11-27 20:22 ` Arnd Bergmann
2015-11-27 20:56 ` Ray Jui [this message]
2015-11-27 21:11 ` Arnd Bergmann
2015-11-27 21:18 ` Ray Jui
2015-11-27 17:37 ` [PATCH v4 3/5] PCI: iproc: Add iProc PCIe MSI device tree binding Ray Jui
2015-11-27 17:37 ` [PATCH v4 4/5] PCI: iproc: Add iProc PCIe MSI support Ray Jui
2015-12-02 14:30 ` Hauke Mehrtens
2015-12-02 17:19 ` Ray Jui
2015-11-27 17:37 ` [PATCH v4 5/5] ARM: dts: Enable MSI support for Broadcom Cygnus Ray Jui
2015-12-02 17:23 ` [PATCH v4 0/5] Add iProc PCIe PAXC and MSI support Ray Jui
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=5658C365.5080209@broadcom.com \
--to=rjui@broadcom.com \
--cc=arnd@arndb.de \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=bhelgaas@google.com \
--cc=hauke@hauke-m.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=marc.zyngier@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 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).