From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v7 11/22] PCI: mvebu: Adapt to the new device tree layout
Date: Tue, 09 Jul 2013 13:07:26 -0600 [thread overview]
Message-ID: <51DC5F6E.2080304@wwwdotorg.org> (raw)
In-Reply-To: <20130709182026.GJ11908@titan.lakedaemon.net>
On 07/09/2013 12:20 PM, Jason Cooper wrote:
> Bjorn,
>
> On Tue, Jul 09, 2013 at 01:41:13PM -0300, Ezequiel Garcia wrote:
>> From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>>
>> The new device tree layout encodes the window's target ID and attribute
>> in the PCIe controller node's ranges property. This allows to parse
>> such entries to obtain such information and use the recently introduced
>> MBus API to create the windows, instead of using the current name based
>> scheme.
>>
>> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>> ---
>> .../devicetree/bindings/pci/mvebu-pci.txt | 145 ++++++++++++++++-----
>> drivers/pci/host/pci-mvebu.c | 113 +++++++++++-----
>> 2 files changed, 193 insertions(+), 65 deletions(-)
>
> After my conversation with tglx a few days ago [1], I'm even more
> inclined to push patches like this to the correct maintainers. However,
> looking at how this patch fits into the series, it may be better if we
> take it through mvebu/arm-soc with your Ack.
>
> It depends on the patches before it, and the patches after it depend on
> it. Unless I'm reading this wrong, I would have a branch that you would
> pull and base this patch on, which I would then pull and base the rest
> of the series on. Reshuffling the series to alleviate this wouldn't work
> in this case. :-/
My experience has been:
The create-a-topic-branch-and-merge-it-multiple-places process is more
useful when you've got a series that does:
1) Create some new common infra-structure.
2) Something that uses the new infra-structure.
... and you expect that other patches will come along (or already exist)
that use the new common infra-structure too; we'll call those (3). This
applies especially when (2) and (3) will want to go in through different
trees.
Then, you'd typically create a topic branch for (1) above, and merge
that both wherever (2) and (3) will be applied.
For simpler cases, acks are much more common.
next prev parent reply other threads:[~2013-07-09 19:07 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-09 16:41 [PATCH v7 00/22] MBus DT binding: The return of PCIe Ezequiel Garcia
2013-07-09 16:41 ` [PATCH v7 01/22] memory: mvebu-devbus: Remove address decoding window workaround Ezequiel Garcia
2013-07-09 16:41 ` [PATCH v7 02/22] bus: mvebu-mbus: Add new API for window creation Ezequiel Garcia
2013-07-09 16:41 ` [PATCH v7 03/22] ARM: kirkwood: Move to ID based MBus " Ezequiel Garcia
2013-07-09 16:41 ` [PATCH v7 04/22] ARM: mv78xx0: Move to ID based " Ezequiel Garcia
2013-07-09 16:41 ` [PATCH v7 05/22] ARM: orion5x: " Ezequiel Garcia
2013-07-09 16:41 ` [PATCH v7 06/22] ARM: dove: " Ezequiel Garcia
2013-07-09 16:41 ` [PATCH v7 07/22] bus: mvebu-mbus: Factor out initialization details Ezequiel Garcia
2013-07-09 16:41 ` [PATCH v7 08/22] bus: mvebu-mbus: Introduce device tree binding Ezequiel Garcia
2013-07-09 16:41 ` [PATCH v7 09/22] bus: mvebu-mbus: Add static window allocation to the DT binding Ezequiel Garcia
2013-07-09 16:41 ` [PATCH v7 10/22] bus: mvebu-mbus: Add new API for the PCIe memory and IO aperture Ezequiel Garcia
2013-07-09 16:41 ` [PATCH v7 11/22] PCI: mvebu: Adapt to the new device tree layout Ezequiel Garcia
2013-07-09 18:20 ` Jason Cooper
2013-07-09 18:50 ` Bjorn Helgaas
2013-07-09 18:54 ` Jason Cooper
2013-07-09 20:22 ` Ezequiel Garcia
2013-07-09 19:07 ` Stephen Warren [this message]
2013-07-09 16:41 ` [PATCH v7 12/22] bus: mvebu-mbus: Remove the no longer used name-based API Ezequiel Garcia
2013-07-09 16:41 ` [PATCH v7 13/22] bus: mvebu-mbus: Remove name -> target, attribute mapping tables Ezequiel Garcia
2013-07-09 16:41 ` [PATCH v7 14/22] bus: mvebu-mbus: Update main description Ezequiel Garcia
2013-07-09 16:41 ` [PATCH v7 15/22] bus: mvebu-mbus: Factorize Armada 370/XP data structures Ezequiel Garcia
2013-07-09 16:41 ` [PATCH v7 16/22] ARM: mvebu: Remove the harcoded BootROM window allocation Ezequiel Garcia
2013-07-09 16:41 ` [PATCH v7 17/22] ARM: mvebu: Initialize MBus using the DT binding Ezequiel Garcia
2013-07-09 16:41 ` [PATCH v7 18/22] ARM: mvebu: Use the preprocessor on Armada 370/XP device tree files Ezequiel Garcia
2013-07-09 16:41 ` [PATCH v7 19/22] ARM: mvebu: Add MBus to Armada 370/XP device tree Ezequiel Garcia
2013-07-09 16:41 ` [PATCH v7 20/22] ARM: mvebu: Add BootROM " Ezequiel Garcia
2013-07-09 16:41 ` [PATCH v7 21/22] ARM: mvebu: Relocate Armada 370/XP DeviceBus device tree nodes Ezequiel Garcia
2013-07-09 16:41 ` [PATCH v7 22/22] ARM: mvebu: Relocate Armada 370/XP PCIe " Ezequiel Garcia
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=51DC5F6E.2080304@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--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