| Message ID | 1376911241-27720-2-git-send-email-Julia.Lawall@lip6.fr (mailing list archive) |
|---|---|
| State | New, archived |
| Delegated to: | Bjorn Helgaas |
| Headers | show |
On Mon, Aug 19, 2013 at 01:20:35PM +0200, Julia Lawall wrote: > From: Julia Lawall <Julia.Lawall@lip6.fr> > > Use devm_ioremap_resource instead of devm_request_and_ioremap. > > This was done using the semantic patch > scripts/coccinelle/api/devm_ioremap_resource.cocci > > Error-handling code was manually removed from the associated calls to > platform_get_resource. > > Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> > > --- > The first block of modified code is followed by a call to > devm_request_mem_region for pcie->cs with no associated ioremap. Should > ioremap be used in this case as well? No. The pcie->cs resource is 256 MiB so it's challenging to map it at once. Furthermore it requires a non-linear mapping so we do it on demand. > drivers/pci/host/pci-tegra.c | 29 +++++++++-------------------- > 1 file changed, 9 insertions(+), 20 deletions(-) Tested-by: Thierry Reding <treding@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Bjorn, how do you want to handle patches to the Tegra PCIe driver in the future? Do you want me to prepare a branch and pull from that or would you rather just take simple patches? Thierry
On Mon, 19 Aug 2013, Thierry Reding wrote: > On Mon, Aug 19, 2013 at 01:20:35PM +0200, Julia Lawall wrote: > > From: Julia Lawall <Julia.Lawall@lip6.fr> > > > > Use devm_ioremap_resource instead of devm_request_and_ioremap. > > > > This was done using the semantic patch > > scripts/coccinelle/api/devm_ioremap_resource.cocci > > > > Error-handling code was manually removed from the associated calls to > > platform_get_resource. > > > > Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> > > > > --- > > The first block of modified code is followed by a call to > > devm_request_mem_region for pcie->cs with no associated ioremap. Should > > ioremap be used in this case as well? > > No. The pcie->cs resource is 256 MiB so it's challenging to map it at > once. Furthermore it requires a non-linear mapping so we do it on > demand. OK, thanks for the explanation. Is the comment, though, a little misleading, since the mapping is not done here? /* request and remap configuration space */ julia -- 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, Aug 19, 2013 at 02:07:54PM +0200, Julia Lawall wrote: > > > On Mon, 19 Aug 2013, Thierry Reding wrote: > > > On Mon, Aug 19, 2013 at 01:20:35PM +0200, Julia Lawall wrote: > > > From: Julia Lawall <Julia.Lawall@lip6.fr> > > > > > > Use devm_ioremap_resource instead of devm_request_and_ioremap. > > > > > > This was done using the semantic patch > > > scripts/coccinelle/api/devm_ioremap_resource.cocci > > > > > > Error-handling code was manually removed from the associated calls to > > > platform_get_resource. > > > > > > Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> > > > > > > --- > > > The first block of modified code is followed by a call to > > > devm_request_mem_region for pcie->cs with no associated ioremap. Should > > > ioremap be used in this case as well? > > > > No. The pcie->cs resource is 256 MiB so it's challenging to map it at > > once. Furthermore it requires a non-linear mapping so we do it on > > demand. > > OK, thanks for the explanation. Is the comment, though, a little > misleading, since the mapping is not done here? > > /* request and remap configuration space */ Yes, that's misleading. Given that it doesn't really add anything useful information either, perhaps I should just remove it. Thanks, Thierry
On Mon, 19 Aug 2013, Thierry Reding wrote: > On Mon, Aug 19, 2013 at 02:07:54PM +0200, Julia Lawall wrote: > > > > > > On Mon, 19 Aug 2013, Thierry Reding wrote: > > > > > On Mon, Aug 19, 2013 at 01:20:35PM +0200, Julia Lawall wrote: > > > > From: Julia Lawall <Julia.Lawall@lip6.fr> > > > > > > > > Use devm_ioremap_resource instead of devm_request_and_ioremap. > > > > > > > > This was done using the semantic patch > > > > scripts/coccinelle/api/devm_ioremap_resource.cocci > > > > > > > > Error-handling code was manually removed from the associated calls to > > > > platform_get_resource. > > > > > > > > Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> > > > > > > > > --- > > > > The first block of modified code is followed by a call to > > > > devm_request_mem_region for pcie->cs with no associated ioremap. Should > > > > ioremap be used in this case as well? > > > > > > No. The pcie->cs resource is 256 MiB so it's challenging to map it at > > > once. Furthermore it requires a non-linear mapping so we do it on > > > demand. > > > > OK, thanks for the explanation. Is the comment, though, a little > > misleading, since the mapping is not done here? > > > > /* request and remap configuration space */ > > Yes, that's misleading. Given that it doesn't really add anything useful > information either, perhaps I should just remove it. OK, or maybe something like /* request configuration space, but remap later, on demand */ To make it clear that something different is intended than the devm_ioremap_resources that come just before.. julia -- 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, Aug 19, 2013 at 02:15:39PM +0200, Julia Lawall wrote: > > > On Mon, 19 Aug 2013, Thierry Reding wrote: > > > On Mon, Aug 19, 2013 at 02:07:54PM +0200, Julia Lawall wrote: > > > > > > > > > On Mon, 19 Aug 2013, Thierry Reding wrote: > > > > > > > On Mon, Aug 19, 2013 at 01:20:35PM +0200, Julia Lawall wrote: > > > > > From: Julia Lawall <Julia.Lawall@lip6.fr> > > > > > > > > > > Use devm_ioremap_resource instead of devm_request_and_ioremap. > > > > > > > > > > This was done using the semantic patch > > > > > scripts/coccinelle/api/devm_ioremap_resource.cocci > > > > > > > > > > Error-handling code was manually removed from the associated calls to > > > > > platform_get_resource. > > > > > > > > > > Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> > > > > > > > > > > --- > > > > > The first block of modified code is followed by a call to > > > > > devm_request_mem_region for pcie->cs with no associated ioremap. Should > > > > > ioremap be used in this case as well? > > > > > > > > No. The pcie->cs resource is 256 MiB so it's challenging to map it at > > > > once. Furthermore it requires a non-linear mapping so we do it on > > > > demand. > > > > > > OK, thanks for the explanation. Is the comment, though, a little > > > misleading, since the mapping is not done here? > > > > > > /* request and remap configuration space */ > > > > Yes, that's misleading. Given that it doesn't really add anything useful > > information either, perhaps I should just remove it. > > OK, or maybe something like > > /* request configuration space, but remap later, on demand */ > > To make it clear that something different is intended than the > devm_ioremap_resources that come just before.. Yes, that works for me too. Can you respin the patch with the comment updated and my Acked-by and Tested-by so Bjorn can pick it up? Thierry
On Mon, Aug 19, 2013 at 6:02 AM, Thierry Reding <thierry.reding@gmail.com> wrote: > Bjorn, how do you want to handle patches to the Tegra PCIe driver in the > future? Do you want me to prepare a branch and pull from that or would > you rather just take simple patches? I'm in the habit of applying patches from email, so that's easy for me. But a branch would be OK, too. Bjorn -- 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, Aug 19, 2013 at 02:04:24PM -0600, Bjorn Helgaas wrote: > On Mon, Aug 19, 2013 at 6:02 AM, Thierry Reding > <thierry.reding@gmail.com> wrote: > > > Bjorn, how do you want to handle patches to the Tegra PCIe driver in the > > future? Do you want me to prepare a branch and pull from that or would > > you rather just take simple patches? > > I'm in the habit of applying patches from email, so that's easy for > me. But a branch would be OK, too. Patches work for me too. Is this cleanup patch something that you'd be comfortable with applying after 3.12-rc1 or would you rather defer it to 3.13? Thierry
On Mon, Aug 19, 2013 at 2:12 PM, Thierry Reding <thierry.reding@gmail.com> wrote: > On Mon, Aug 19, 2013 at 02:04:24PM -0600, Bjorn Helgaas wrote: >> On Mon, Aug 19, 2013 at 6:02 AM, Thierry Reding >> <thierry.reding@gmail.com> wrote: >> >> > Bjorn, how do you want to handle patches to the Tegra PCIe driver in the >> > future? Do you want me to prepare a branch and pull from that or would >> > you rather just take simple patches? >> >> I'm in the habit of applying patches from email, so that's easy for >> me. But a branch would be OK, too. > > Patches work for me too. Is this cleanup patch something that you'd be > comfortable with applying after 3.12-rc1 or would you rather defer it to > 3.13? I'm not really sure how we should manage drivers/pci/host/*. Those files are mostly arch code, and I'm not sure it's useful for me to be in the middle of managing them. I assume Stephen or somebody has a tree with the pci-tegra.c stuff that's in -next right now; it seems like it'd be simplest to just add this patch there and merge in during the v3.12 merge window. Bjorn -- 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 08/19/2013 01:33 PM, Thierry Reding wrote: > On Mon, Aug 19, 2013 at 02:15:39PM +0200, Julia Lawall wrote: >> >> >> On Mon, 19 Aug 2013, Thierry Reding wrote: >> >>> On Mon, Aug 19, 2013 at 02:07:54PM +0200, Julia Lawall wrote: >>>> >>>> >>>> On Mon, 19 Aug 2013, Thierry Reding wrote: >>>> >>>>> On Mon, Aug 19, 2013 at 01:20:35PM +0200, Julia Lawall >>>>> wrote: >>>>>> From: Julia Lawall <Julia.Lawall@lip6.fr> >>>>>> >>>>>> Use devm_ioremap_resource instead of >>>>>> devm_request_and_ioremap. >>>>>> >>>>>> This was done using the semantic patch >>>>>> scripts/coccinelle/api/devm_ioremap_resource.cocci >>>>>> >>>>>> Error-handling code was manually removed from the >>>>>> associated calls to platform_get_resource. >>>>>> >>>>>> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> >>>>>> >>>>>> --- The first block of modified code is followed by a >>>>>> call to devm_request_mem_region for pcie->cs with no >>>>>> associated ioremap. Should ioremap be used in this case >>>>>> as well? >>>>> >>>>> No. The pcie->cs resource is 256 MiB so it's challenging to >>>>> map it at once. Furthermore it requires a non-linear >>>>> mapping so we do it on demand. >>>> >>>> OK, thanks for the explanation. Is the comment, though, a >>>> little misleading, since the mapping is not done here? >>>> >>>> /* request and remap configuration space */ >>> >>> Yes, that's misleading. Given that it doesn't really add >>> anything useful information either, perhaps I should just >>> remove it. >> >> OK, or maybe something like >> >> /* request configuration space, but remap later, on demand */ >> >> To make it clear that something different is intended than the >> devm_ioremap_resources that come just before.. > > Yes, that works for me too. Can you respin the patch with the > comment updated and my Acked-by and Tested-by so Bjorn can pick it > up? Just a note though: Since the Tegra PCIe driver is only being added in v3.12-rc1, and that add is happening in the Tegra/arm-soc tree, Bjorn won't be able to accept the patch until after v3.12-rc1. Perhaps the arm-soc tree could take the patch before then though... -- 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, Aug 19, 2013 at 02:49:07PM -0600, Bjorn Helgaas wrote: > On Mon, Aug 19, 2013 at 2:12 PM, Thierry Reding > <thierry.reding@gmail.com> wrote: > > On Mon, Aug 19, 2013 at 02:04:24PM -0600, Bjorn Helgaas wrote: > >> On Mon, Aug 19, 2013 at 6:02 AM, Thierry Reding > >> <thierry.reding@gmail.com> wrote: > >> > >> > Bjorn, how do you want to handle patches to the Tegra PCIe driver in the > >> > future? Do you want me to prepare a branch and pull from that or would > >> > you rather just take simple patches? > >> > >> I'm in the habit of applying patches from email, so that's easy for > >> me. But a branch would be OK, too. > > > > Patches work for me too. Is this cleanup patch something that you'd be > > comfortable with applying after 3.12-rc1 or would you rather defer it to > > 3.13? > > I'm not really sure how we should manage drivers/pci/host/*. Those > files are mostly arch code, and I'm not sure it's useful for me to be > in the middle of managing them. > > I assume Stephen or somebody has a tree with the pci-tegra.c stuff > that's in -next right now; it seems like it'd be simplest to just add > this patch there and merge in during the v3.12 merge window. If Stephen's fine with it I suppose we could take pci-tegra.c driver changes through the Tegra tree. But I think it'd be good if we could still Cc you on patches so you're aware of what we're doing (that is the same for all drivers drivers/pci/host/*). And we're going to need your Acked-by on the patches as well. Thierry
On 08/27/2013 02:14 AM, Thierry Reding wrote: > On Mon, Aug 19, 2013 at 02:49:07PM -0600, Bjorn Helgaas wrote: >> On Mon, Aug 19, 2013 at 2:12 PM, Thierry Reding >> <thierry.reding@gmail.com> wrote: >>> On Mon, Aug 19, 2013 at 02:04:24PM -0600, Bjorn Helgaas wrote: >>>> On Mon, Aug 19, 2013 at 6:02 AM, Thierry Reding >>>> <thierry.reding@gmail.com> wrote: >>>> >>>>> Bjorn, how do you want to handle patches to the Tegra PCIe >>>>> driver in the future? Do you want me to prepare a branch >>>>> and pull from that or would you rather just take simple >>>>> patches? >>>> >>>> I'm in the habit of applying patches from email, so that's >>>> easy for me. But a branch would be OK, too. >>> >>> Patches work for me too. Is this cleanup patch something that >>> you'd be comfortable with applying after 3.12-rc1 or would you >>> rather defer it to 3.13? >> >> I'm not really sure how we should manage drivers/pci/host/*. >> Those files are mostly arch code, and I'm not sure it's useful >> for me to be in the middle of managing them. >> >> I assume Stephen or somebody has a tree with the pci-tegra.c >> stuff that's in -next right now; it seems like it'd be simplest >> to just add this patch there and merge in during the v3.12 merge >> window. > > If Stephen's fine with it I suppose we could take pci-tegra.c > driver changes through the Tegra tree. But I think it'd be good if > we could still Cc you on patches so you're aware of what we're > doing (that is the same for all drivers drivers/pci/host/*). And > we're going to need your Acked-by on the patches as well. I can push Tegra PCIe patches through the arm-soc tree before 3.12-rc1, but after that point, I think it's best if they go through the PCIe tree, unless there's some cross-subsystem dependency for a specific patch, and with the new PCIe driver, that's less likely. -- 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 Tue, Aug 27, 2013 at 10:11 AM, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 08/27/2013 02:14 AM, Thierry Reding wrote: >> On Mon, Aug 19, 2013 at 02:49:07PM -0600, Bjorn Helgaas wrote: >>> On Mon, Aug 19, 2013 at 2:12 PM, Thierry Reding >>> <thierry.reding@gmail.com> wrote: >>>> On Mon, Aug 19, 2013 at 02:04:24PM -0600, Bjorn Helgaas wrote: >>>>> On Mon, Aug 19, 2013 at 6:02 AM, Thierry Reding >>>>> <thierry.reding@gmail.com> wrote: >>>>> >>>>>> Bjorn, how do you want to handle patches to the Tegra PCIe >>>>>> driver in the future? Do you want me to prepare a branch >>>>>> and pull from that or would you rather just take simple >>>>>> patches? >>>>> >>>>> I'm in the habit of applying patches from email, so that's >>>>> easy for me. But a branch would be OK, too. >>>> >>>> Patches work for me too. Is this cleanup patch something that >>>> you'd be comfortable with applying after 3.12-rc1 or would you >>>> rather defer it to 3.13? >>> >>> I'm not really sure how we should manage drivers/pci/host/*. >>> Those files are mostly arch code, and I'm not sure it's useful >>> for me to be in the middle of managing them. >>> >>> I assume Stephen or somebody has a tree with the pci-tegra.c >>> stuff that's in -next right now; it seems like it'd be simplest >>> to just add this patch there and merge in during the v3.12 merge >>> window. >> >> If Stephen's fine with it I suppose we could take pci-tegra.c >> driver changes through the Tegra tree. But I think it'd be good if >> we could still Cc you on patches so you're aware of what we're >> doing (that is the same for all drivers drivers/pci/host/*). And >> we're going to need your Acked-by on the patches as well. I think you have my Acked-by for this case already (from Aug 20). And feel free to copy me on anything you like; my delete key works well :) > I can push Tegra PCIe patches through the arm-soc tree before > 3.12-rc1, but after that point, I think it's best if they go through > the PCIe tree, unless there's some cross-subsystem dependency for a > specific patch, and with the new PCIe driver, that's less likely. I'm OK with merging things through my tree. It just seemed like there was a lot of recent Tegra activity that included a few Tegra PCI changes, and no benefit to trying to split the PCI stuff from the non-PCI stuff. Hopefully it will calm down, because I don't have time to be in the middle of major Tegra stuff. Bjorn -- 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 Tue, Aug 27, 2013 at 12:03 PM, Bjorn Helgaas <bhelgaas@google.com> wrote: >> On 08/27/2013 02:14 AM, Thierry Reding wrote: >>> If Stephen's fine with it I suppose we could take pci-tegra.c >>> driver changes through the Tegra tree. But I think it'd be good if >>> we could still Cc you on patches so you're aware of what we're >>> doing (that is the same for all drivers drivers/pci/host/*). And >>> we're going to need your Acked-by on the patches as well. > > I think you have my Acked-by for this case already (from Aug 20). And > feel free to copy me on anything you like; my delete key works well :) I didn't mean for this to sound like "I'll just delete any email you send me"; I intended more like "feel free to copy me and if it's something I'm interested or knowledgeable about, I'll try to help and if not, it's easy for me to ignore it." Bjorn -- 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 Wed, Aug 28, 2013 at 07:02:16AM -0600, Bjorn Helgaas wrote: > On Tue, Aug 27, 2013 at 12:03 PM, Bjorn Helgaas <bhelgaas@google.com> wrote: > >> On 08/27/2013 02:14 AM, Thierry Reding wrote: > > >>> If Stephen's fine with it I suppose we could take pci-tegra.c > >>> driver changes through the Tegra tree. But I think it'd be good if > >>> we could still Cc you on patches so you're aware of what we're > >>> doing (that is the same for all drivers drivers/pci/host/*). And > >>> we're going to need your Acked-by on the patches as well. > > > > I think you have my Acked-by for this case already (from Aug 20). And > > feel free to copy me on anything you like; my delete key works well :) > > I didn't mean for this to sound like "I'll just delete any email you > send me"; I intended more like "feel free to copy me and if it's > something I'm interested or knowledgeable about, I'll try to help and > if not, it's easy for me to ignore it." That's exactly the way I understood it. =) Thierry
On Tue, Aug 27, 2013 at 12:03:01PM -0600, Bjorn Helgaas wrote: > On Tue, Aug 27, 2013 at 10:11 AM, Stephen Warren <swarren@wwwdotorg.org> wrote: > > On 08/27/2013 02:14 AM, Thierry Reding wrote: > >> On Mon, Aug 19, 2013 at 02:49:07PM -0600, Bjorn Helgaas wrote: > >>> On Mon, Aug 19, 2013 at 2:12 PM, Thierry Reding > >>> <thierry.reding@gmail.com> wrote: > >>>> On Mon, Aug 19, 2013 at 02:04:24PM -0600, Bjorn Helgaas wrote: > >>>>> On Mon, Aug 19, 2013 at 6:02 AM, Thierry Reding > >>>>> <thierry.reding@gmail.com> wrote: > >>>>> > >>>>>> Bjorn, how do you want to handle patches to the Tegra PCIe > >>>>>> driver in the future? Do you want me to prepare a branch > >>>>>> and pull from that or would you rather just take simple > >>>>>> patches? > >>>>> > >>>>> I'm in the habit of applying patches from email, so that's > >>>>> easy for me. But a branch would be OK, too. > >>>> > >>>> Patches work for me too. Is this cleanup patch something that > >>>> you'd be comfortable with applying after 3.12-rc1 or would you > >>>> rather defer it to 3.13? > >>> > >>> I'm not really sure how we should manage drivers/pci/host/*. > >>> Those files are mostly arch code, and I'm not sure it's useful > >>> for me to be in the middle of managing them. > >>> > >>> I assume Stephen or somebody has a tree with the pci-tegra.c > >>> stuff that's in -next right now; it seems like it'd be simplest > >>> to just add this patch there and merge in during the v3.12 merge > >>> window. > >> > >> If Stephen's fine with it I suppose we could take pci-tegra.c > >> driver changes through the Tegra tree. But I think it'd be good if > >> we could still Cc you on patches so you're aware of what we're > >> doing (that is the same for all drivers drivers/pci/host/*). And > >> we're going to need your Acked-by on the patches as well. > > I think you have my Acked-by for this case already (from Aug 20). And > feel free to copy me on anything you like; my delete key works well :) > > > I can push Tegra PCIe patches through the arm-soc tree before > > 3.12-rc1, but after that point, I think it's best if they go through > > the PCIe tree, unless there's some cross-subsystem dependency for a > > specific patch, and with the new PCIe driver, that's less likely. > > I'm OK with merging things through my tree. It just seemed like there > was a lot of recent Tegra activity that included a few Tegra PCI > changes, and no benefit to trying to split the PCI stuff from the > non-PCI stuff. Hopefully it will calm down, because I don't have time > to be in the middle of major Tegra stuff. Yes, I think it will calm down. The difficulty this time around was that there were various dependencies across multiple trees that needed to be coordinated. As Stephen already mentioned, part of the reason to move the driver out of arch/arm/mach-tegra was to make it stand on its own. Thierry
diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c index 7356741..db2ddc5 100644 --- a/drivers/pci/host/pci-tegra.c +++ b/drivers/pci/host/pci-tegra.c @@ -1031,28 +1031,17 @@ static int tegra_pcie_get_resources(struct tegra_pcie *pcie) return err; } - /* request and remap controller registers */ pads = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pads"); - if (!pads) { - err = -EADDRNOTAVAIL; + pcie->pads = devm_ioremap_resource(&pdev->dev, pads); + if (IS_ERR(pcie->pads)) { + err = PTR_ERR(pcie->pads); goto poweroff; } afi = platform_get_resource_byname(pdev, IORESOURCE_MEM, "afi"); - if (!afi) { - err = -EADDRNOTAVAIL; - goto poweroff; - } - - pcie->pads = devm_request_and_ioremap(&pdev->dev, pads); - if (!pcie->pads) { - err = -EADDRNOTAVAIL; - goto poweroff; - } - - pcie->afi = devm_request_and_ioremap(&pdev->dev, afi); - if (!pcie->afi) { - err = -EADDRNOTAVAIL; + pcie->afi = devm_ioremap_resource(&pdev->dev, afi); + if (IS_ERR(pcie->afi)) { + err = PTR_ERR(pcie->afi); goto poweroff; } @@ -1492,9 +1481,9 @@ static int tegra_pcie_parse_dt(struct tegra_pcie *pcie) rp->lanes = value; rp->pcie = pcie; - rp->base = devm_request_and_ioremap(pcie->dev, &rp->regs); - if (!rp->base) - return -EADDRNOTAVAIL; + rp->base = devm_ioremap_resource(pcie->dev, &rp->regs); + if (IS_ERR(rp->base)) + return PTR_ERR(rp->base); list_add_tail(&rp->list, &pcie->ports); }