| Message ID | 1380650281-16175-1-git-send-email-jgunthorpe@obsidianresearch.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Dear Jason Gunthorpe, On Tue, 1 Oct 2013 11:58:00 -0600, Jason Gunthorpe wrote: > Otherwise hotplugging the PEX doesn't work at all since the driver > detects the link state at probe time. Simply replacing the two tests > of haslink with a register read is enough to fix it. > > Tested on kirkwood with repeated plug/unplug of the link partner. > > Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[+cc Seungwon] On Tue, Oct 1, 2013 at 11:58 AM, Jason Gunthorpe <jgunthorpe@obsidianresearch.com> wrote: > Otherwise hotplugging the PEX doesn't work at all since the driver > detects the link state at probe time. Simply replacing the two tests > of haslink with a register read is enough to fix it. > > Tested on kirkwood with repeated plug/unplug of the link partner. > > Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Last I heard (Sep 26), you had some mvebu changes in your tree already, Jason, so I was assuming you'd handle pci-mvebu.c changes, at least for the v3.13 merge window. But you marked this "resend"; does that mean you're waiting for me to do something with it? I see the following mvebu patches in patchwork: PCI: mvebu: Dynamically detect if the PEX link is up to enable hot plug PCI: mvebu - Support a bridge with no IO port window PCI: mvebu: add I/O access wrappers Let me know if I need to do anything with any of them. Bjorn > --- > drivers/pci/host/pci-mvebu.c | 16 ++-------------- > 1 file changed, 2 insertions(+), 14 deletions(-) > > diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c > index 729d5a1..f2d61f5 100644 > --- a/drivers/pci/host/pci-mvebu.c > +++ b/drivers/pci/host/pci-mvebu.c > @@ -115,7 +115,6 @@ struct mvebu_pcie_port { > char *name; > void __iomem *base; > spinlock_t conf_lock; > - int haslink; > u32 port; > u32 lane; > int devfn; > @@ -552,7 +551,7 @@ static int mvebu_pcie_wr_conf(struct pci_bus *bus, u32 devfn, > if (bus->number == 0) > return mvebu_sw_pci_bridge_write(port, where, size, val); > > - if (!port->haslink) > + if (!mvebu_pcie_link_up(port)) > return PCIBIOS_DEVICE_NOT_FOUND; > > /* > @@ -594,7 +593,7 @@ static int mvebu_pcie_rd_conf(struct pci_bus *bus, u32 devfn, int where, > if (bus->number == 0) > return mvebu_sw_pci_bridge_read(port, where, size, val); > > - if (!port->haslink) { > + if (!mvebu_pcie_link_up(port)) { > *val = 0xffffffff; > return PCIBIOS_DEVICE_NOT_FOUND; > } > @@ -883,22 +882,11 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev) > > mvebu_pcie_set_local_dev_nr(port, 1); > > - if (mvebu_pcie_link_up(port)) { > - port->haslink = 1; > - dev_info(&pdev->dev, "PCIe%d.%d: link up\n", > - port->port, port->lane); > - } else { > - port->haslink = 0; > - dev_info(&pdev->dev, "PCIe%d.%d: link down\n", > - port->port, port->lane); > - } > - > port->clk = of_clk_get_by_name(child, NULL); > if (IS_ERR(port->clk)) { > dev_err(&pdev->dev, "PCIe%d.%d: cannot get clock\n", > port->port, port->lane); > iounmap(port->base); > - port->haslink = 0; > continue; > } > > -- > 1.8.1.2 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Oct 07, 2013 at 04:28:52PM -0600, Bjorn Helgaas wrote: > [+cc Seungwon] > > On Tue, Oct 1, 2013 at 11:58 AM, Jason Gunthorpe > <jgunthorpe@obsidianresearch.com> wrote: > > Otherwise hotplugging the PEX doesn't work at all since the driver > > detects the link state at probe time. Simply replacing the two tests > > of haslink with a register read is enough to fix it. > > > > Tested on kirkwood with repeated plug/unplug of the link partner. > > > > Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> > > Last I heard (Sep 26), you had some mvebu changes in your tree > already, Jason, so I was assuming you'd handle pci-mvebu.c changes, at > least for the v3.13 merge window. But you marked this "resend"; does > that mean you're waiting for me to do something with it? Are you thinking of Jason C.? He is handling much of the mvebu stuff. Hopefully Jason C. can clarify which route these patches should take to hit the 3.13 merge window. This was reposted at the request of Thomas, IIRC. > PCI: mvebu - Support a bridge with no IO port window This one is broken, I have yet to fix it still. > PCI: mvebu: add I/O access wrappers This isn't one of mine .. Regards, Jason
On Mon, Oct 7, 2013 at 4:40 PM, Jason Gunthorpe <jgunthorpe@obsidianresearch.com> wrote: > On Mon, Oct 07, 2013 at 04:28:52PM -0600, Bjorn Helgaas wrote: >> [+cc Seungwon] >> >> On Tue, Oct 1, 2013 at 11:58 AM, Jason Gunthorpe >> <jgunthorpe@obsidianresearch.com> wrote: >> > Otherwise hotplugging the PEX doesn't work at all since the driver >> > detects the link state at probe time. Simply replacing the two tests >> > of haslink with a register read is enough to fix it. >> > >> > Tested on kirkwood with repeated plug/unplug of the link partner. >> > >> > Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> >> >> Last I heard (Sep 26), you had some mvebu changes in your tree >> already, Jason, so I was assuming you'd handle pci-mvebu.c changes, at >> least for the v3.13 merge window. But you marked this "resend"; does >> that mean you're waiting for me to do something with it? > > Are you thinking of Jason C.? He is handling much of the mvebu stuff. Oops, sorry, yep, indeed I meant Jason C. Sorry about confusing you guys :) > Hopefully Jason C. can clarify which route these patches should take > to hit the 3.13 merge window. > > This was reposted at the request of Thomas, IIRC. > >> PCI: mvebu - Support a bridge with no IO port window > > This one is broken, I have yet to fix it still. > >> PCI: mvebu: add I/O access wrappers > > This isn't one of mine .. That's Seungwon's. I just wanted to collect all the mvebu patches from the PCI patchwork. Bjorn
Dear Bjorn Helgaas, On Mon, 7 Oct 2013 16:28:52 -0600, Bjorn Helgaas wrote: > I see the following mvebu patches in patchwork: > > PCI: mvebu: Dynamically detect if the PEX link is up to enable hot plug This one got my Acked-by, see <20131003144457.4131aea3@skate>. > PCI: mvebu - Support a bridge with no IO port window This one has issues, as I reported to Jason Gunthorpe. > PCI: mvebu: add I/O access wrappers I need to test this one. Jason Cooper will confirm, but my understanding is that for the 3.13, he wanted to merge all the pci-mvebu patches, because he already has MSI related changes (that span PCI and irqchip drivers). Of course, if you agree with this. But indeed, this means that Jason C. should also take care of all other pci-mvebu patches :) Jason C, do not hesitate to ping me if you need testing/confirmation on some pci-mvebu patches I might have overlooked. Thanks, Thomas
On Mon, Oct 07, 2013 at 04:28:52PM -0600, Bjorn Helgaas wrote: > [+cc Seungwon] > > On Tue, Oct 1, 2013 at 11:58 AM, Jason Gunthorpe > <jgunthorpe@obsidianresearch.com> wrote: > > Otherwise hotplugging the PEX doesn't work at all since the driver > > detects the link state at probe time. Simply replacing the two tests > > of haslink with a register read is enough to fix it. > > > > Tested on kirkwood with repeated plug/unplug of the link partner. > > > > Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> > > Last I heard (Sep 26), you had some mvebu changes in your tree > already, Jason, so I was assuming you'd handle pci-mvebu.c changes, at > least for the v3.13 merge window. But you marked this "resend"; That's correct. I somehow missed these two and I asked JasonG to resend them to me. > does that mean you're waiting for me to do something with it? Nope, It means I'm looking for a slice of time to get caught up :-P > I see the following mvebu patches in patchwork: > > PCI: mvebu: Dynamically detect if the PEX link is up to enable hot plug > PCI: mvebu - Support a bridge with no IO port window > PCI: mvebu: add I/O access wrappers > > Let me know if I need to do anything with any of them. I always appreciate an extra set of eyes ;-) Hopefully, after v3.13, we can get back to normal wrt patches going through proper trees. thx, Jason.
On Tue, Oct 01, 2013 at 11:58:00AM -0600, Jason Gunthorpe wrote: > Otherwise hotplugging the PEX doesn't work at all since the driver > detects the link state at probe time. Simply replacing the two tests > of haslink with a register read is enough to fix it. > > Tested on kirkwood with repeated plug/unplug of the link partner. > > Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> > --- > drivers/pci/host/pci-mvebu.c | 16 ++-------------- > 1 file changed, 2 insertions(+), 14 deletions(-) Applied to mvebu/drivers with Thomas' Ack and Tested-by. thx, Jason.
diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c index 729d5a1..f2d61f5 100644 --- a/drivers/pci/host/pci-mvebu.c +++ b/drivers/pci/host/pci-mvebu.c @@ -115,7 +115,6 @@ struct mvebu_pcie_port { char *name; void __iomem *base; spinlock_t conf_lock; - int haslink; u32 port; u32 lane; int devfn; @@ -552,7 +551,7 @@ static int mvebu_pcie_wr_conf(struct pci_bus *bus, u32 devfn, if (bus->number == 0) return mvebu_sw_pci_bridge_write(port, where, size, val); - if (!port->haslink) + if (!mvebu_pcie_link_up(port)) return PCIBIOS_DEVICE_NOT_FOUND; /* @@ -594,7 +593,7 @@ static int mvebu_pcie_rd_conf(struct pci_bus *bus, u32 devfn, int where, if (bus->number == 0) return mvebu_sw_pci_bridge_read(port, where, size, val); - if (!port->haslink) { + if (!mvebu_pcie_link_up(port)) { *val = 0xffffffff; return PCIBIOS_DEVICE_NOT_FOUND; } @@ -883,22 +882,11 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev) mvebu_pcie_set_local_dev_nr(port, 1); - if (mvebu_pcie_link_up(port)) { - port->haslink = 1; - dev_info(&pdev->dev, "PCIe%d.%d: link up\n", - port->port, port->lane); - } else { - port->haslink = 0; - dev_info(&pdev->dev, "PCIe%d.%d: link down\n", - port->port, port->lane); - } - port->clk = of_clk_get_by_name(child, NULL); if (IS_ERR(port->clk)) { dev_err(&pdev->dev, "PCIe%d.%d: cannot get clock\n", port->port, port->lane); iounmap(port->base); - port->haslink = 0; continue; }
Otherwise hotplugging the PEX doesn't work at all since the driver detects the link state at probe time. Simply replacing the two tests of haslink with a register read is enough to fix it. Tested on kirkwood with repeated plug/unplug of the link partner. Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> --- drivers/pci/host/pci-mvebu.c | 16 ++-------------- 1 file changed, 2 insertions(+), 14 deletions(-)