On Mon, May 5, 2014 at 7:46 AM, Jason Cooper <jason@xxxxxxxxxxxxxx> wrote:
> Greg,
>
> + Bjorn Helgaas
>
> On Wed, Apr 30, 2014 at 05:41:43PM -0700, gregkh@xxxxxxxxxxxxxxxxxxx wrote:
>>
>> The patch below does not apply to the 3.14-stable tree.
>> If someone wants it applied there, or to any other stable or longterm
>> tree, then please email the backport, including the original git commit
>> id to <stable@xxxxxxxxxxxxxxx>.
>
> Please disregard for v3.14.y. It looks as though Bjorn Helgaas
> committed it as:
>
> 322a8e91844f PCI: mvebu: Use Device ID and revision from underlying endpoint
>
> which has been in since v3.14-rc4. The commit you found, below
> (a760d2fb2c70) has only been in since v3.15-rc1.
>
> That's why it didn't apply.
>
> I'm not sure what I f'd up here. There's no way it could've been
> applied twice without throwing the error Greg saw and I saw.
>
> Bjorn, did I send you something wrongly?
I don't think so, but I might have messed it up by the way I applied
it. Here's what I think I did:
- applied this change to my pci/host-mvebu branch
- cherry-picked it to my for-linus branch
- asked Linus to pull it as pci-v3.14-fixes-1 after the v3.14 merge window
- added other changes to pci/host-mvebu
- merged pci/host-mvebu to my "next" branch
- asked Linus to pull "next" as pci-v3.15-changes during v3.15 merge window
So the same commit was in both pull requests (pci-v3.14-fixes-1 and
pci-v3.15-changes).
Maybe my git workflow is broken? I'm open to suggestions for improvements.
>> ------------------ original commit in Linus's tree ------------------
>>
>> From a760d2fb2c700469f2578f980e30423bcba316ac Mon Sep 17 00:00:00 2001
>> From: Andrew Lunn <andrew@xxxxxxx>
>> Date: Wed, 5 Feb 2014 11:55:49 +0100
>> Subject: [PATCH] PCI: mvebu: Use Device ID and revision from underlying
>> endpoint
>>
>> Marvell SoCs place the SoC number into the PCIe endpoint device ID. The
>> SoC stepping is placed into the PCIe revision. The old plat-orion PCIe
>> driver allowed this information to be seen in user space with a simple
>> lspci command.
>>
>> The new driver places a virtual PCI-PCI bridge on top of these endpoints.
>> It has its own hard coded PCI device ID. Thus it is no longer possible to
>> see what the SoC is using lspci.
>>
>> When initializing the PCI-PCI bridge, set its device ID and revision from
>> the underlying endpoint, thus restoring this functionality. Debian would
>> like to use this in order to aid installing the correct DTB file.
>>
>> Fixes: 45361a4fe4464 ("pci: PCIe driver for Marvell Armada 370/XP systems")
>> Signed-off-by: Andrew Lunn <andrew@xxxxxxx>
>> Signed-off-by: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
>> Acked-by: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
>> Acked-by: Jason Cooper <jason@xxxxxxxxxxxxxx>
>> Cc: stable@xxxxxxxxxxxxxxx # v3.11+
>>
>> diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
>> index 13478ecd4113..0e79665afd44 100644
>> --- a/drivers/pci/host/pci-mvebu.c
>> +++ b/drivers/pci/host/pci-mvebu.c
>> @@ -60,14 +60,6 @@
>> #define PCIE_DEBUG_CTRL 0x1a60
>> #define PCIE_DEBUG_SOFT_RESET BIT(20)
>>
>> -/*
>> - * This product ID is registered by Marvell, and used when the Marvell
>> - * SoC is not the root complex, but an endpoint on the PCIe bus. It is
>> - * therefore safe to re-use this PCI ID for our emulated PCI-to-PCI
>> - * bridge.
>> - */
>> -#define MARVELL_EMULATED_PCI_PCI_BRIDGE_ID 0x7846
>> -
>> /* PCI configuration space of a PCI-to-PCI bridge */
>> struct mvebu_sw_pci_bridge {
>> u16 vendor;
>> @@ -388,7 +380,8 @@ static void mvebu_sw_pci_bridge_init(struct mvebu_pcie_port *port)
>>
>> bridge->class = PCI_CLASS_BRIDGE_PCI;
>> bridge->vendor = PCI_VENDOR_ID_MARVELL;
>> - bridge->device = MARVELL_EMULATED_PCI_PCI_BRIDGE_ID;
>> + bridge->device = mvebu_readl(port, PCIE_DEV_ID_OFF) >> 16;
>> + bridge->revision = mvebu_readl(port, PCIE_DEV_REV_OFF) & 0xff;
>> bridge->header_type = PCI_HEADER_TYPE_BRIDGE;
>> bridge->cache_line_size = 0x10;
>>
>>
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html