On Thu, Oct 17, 2019 at 05:01:26PM +0200, Marek Vasut wrote:
[...]
> > Again, just handling the first N dma-ranges entries and ignoring the
> > rest is not 'configure the controller correctly'.
>
> It's the best effort thing to do. It's well possible the next generation
> of the controller will
[+RobH, Robin]
On Wed, Oct 16, 2019 at 05:29:50PM +0200, Marek Vasut wrote:
[...]
> >> The firmware provides all the ranges which are available and usable,
> >> that's the hardware description and that should be in the DT.
> >
> > If the HW (given that those dma-ranges are declared for the PCI
On Wed, Oct 16, 2019 at 05:10:02PM +0200, Marek Vasut wrote:
> On 10/16/19 5:00 PM, Lorenzo Pieralisi wrote:
> > On Fri, Aug 09, 2019 at 07:57:40PM +0200, Marek Vasut wrote:
> >> From: Marek Vasut
> >>
> >> In case the "dma-ranges" DT property con
cribing DMA'able ranges all bets are
off.
I would not merge this specific patch but let me know what you think.
Thanks,
Lorenzo
> Signed-off-by: Marek Vasut
> Cc: Geert Uytterhoeven
> Cc: Lorenzo Pieralisi
> Cc: Wolfram Sang
> Cc: linux-renesas-soc@vger.kernel.org
> To:
On Thu, Sep 05, 2019 at 04:05:28PM +0100, Andrew Murray wrote:
> Remove unnecessary header include (../pci.h) since it doesn't
> provide any needed symbols.
>
> Signed-off-by: Andrew Murray
> ---
> drivers/pci/controller/pcie-rcar.c | 2 --
> 1 file changed, 2 deletions(-)
Applied to pci/rcar,
On Fri, Oct 11, 2019 at 01:50:32PM +0900, Yoshihiro Shimoda wrote:
> According to the R-Car Gen2/3 manual, the bit 0 of MACCTLR register
> should be written to 0 before enabling PCIETCTLR.CFINIT because
> the bit 0 is set to 1 on reset. To avoid unexpected behaviors from
> this incorrect setting, t
On Fri, Aug 16, 2019 at 12:59:51PM +0200, Marek Vasut wrote:
> On 8/16/19 12:52 PM, Lorenzo Pieralisi wrote:
> > On Fri, Aug 09, 2019 at 07:57:39PM +0200, marek.va...@gmail.com wrote:
> >> From: Marek Vasut
> >>
> >> Since the $idx variable valu
this patch
improves robustness but I do not think it is fixing anything.
Lorenzo
> Fix this by moving the $idx value check to the beginning of the loop.
>
> Signed-off-by: Marek Vasut
> Cc: Geert Uytterhoeven
> Cc: Lorenzo Pieralisi
> Cc: Wolfram Sang
> Cc: linux-renesas
On Mon, Jul 29, 2019 at 09:44:52AM +0200, Geert Uytterhoeven wrote:
> Hi Eugniu,
>
> CC cpuidle people
>
> On Fri, Jul 26, 2019 at 11:47 AM Eugeniu Rosca wrote:
> > On Fri, Jul 26, 2019 at 11:13:29AM +0200, Rosca, Eugeniu (ADITG/ESM1) wrote:
> > [..]
> > > The culprit BSP commits are:
> > > http
On Fri, Jun 07, 2019 at 08:03:36AM +0100, Biju Das wrote:
> Add PCIe support for the RZ/G2M (a.k.a. R8A774A1).
>
> Signed-off-by: Biju Das
> ---
> Documentation/devicetree/bindings/pci/rcar-pci.txt | 1 +
> 1 file changed, 1 insertion(+)
Applied to pci/rcar for v5.3, thanks.
Lorenzo
> diff --
On Wed, Jun 12, 2019 at 01:46:29PM +0200, Simon Horman wrote:
> On Fri, Jun 07, 2019 at 08:03:36AM +0100, Biju Das wrote:
> > Add PCIe support for the RZ/G2M (a.k.a. R8A774A1).
> >
> > Signed-off-by: Biju Das
>
> Reviewed-by: Simon Horman
Should I pick this up and send it via the PCI tree ?
J
On Thu, Apr 04, 2019 at 05:48:36PM +0200, Marek Vasut wrote:
> On 4/4/19 11:28 AM, Lorenzo Pieralisi wrote:
> > On Tue, Apr 02, 2019 at 03:33:07AM +0200, marek.va...@gmail.com wrote:
> >> From: Marek Vasut
> >>
> >> The MSI message address in the RC address
On Tue, Apr 02, 2019 at 03:33:07AM +0200, marek.va...@gmail.com wrote:
> From: Marek Vasut
>
> The MSI message address in the RC address space can be 64 bit. The
> R-Car PCIe RC supports such a 64bit MSI message address as well.
> The code currently uses virt_to_phys(__get_free_pages()) to obtain
On Sun, Mar 17, 2019 at 10:34:45AM +0100, Wolfram Sang wrote:
> sparse rightfully says:
> drivers/pci/controller/pcie-rcar.c:741:30: warning: symbol 'irq' shadows an
> earlier one
>
> It doesn't affect the current code. But fix it now to avoid future
> surprises and for good coding style.
>
> Si
On Mon, Mar 25, 2019 at 12:40:56PM +0100, marek.va...@gmail.com wrote:
> From: Marek Vasut
>
> Replace macros using constants with BIT()s instead, no functional change.
>
> Signed-off-by: Marek Vasut
> Cc: Geert Uytterhoeven
> Cc: Phil Edworthy
> Cc: Simon Horman
> Cc: Wolfram Sang
> Cc: li
On Thu, Mar 28, 2019 at 09:02:00AM +0100, Geert Uytterhoeven wrote:
> Hi Marek,
>
> On Thu, Mar 28, 2019 at 4:19 AM Marek Vasut wrote:
> > On 3/27/19 1:22 PM, Geert Uytterhoeven wrote:
> > > On Wed, Mar 27, 2019 at 12:30 PM Simon Horman wrote:
> > >> On Mon, Mar 25, 2019 at 12:41:01PM +0100, mar
trickle back anyway through the
stable mechanism, I just queued it as a fix since that's how it
qualifies.
So postponing it to v5.2 is fine by me, just let me know how it is best
to handle it.
Thanks,
Lorenzo
> Bjorn
>
> > Signed-off-by: Kazufumi Ikeda
> > Signed-off-by: Ga
On Mon, Mar 25, 2019 at 12:40:56PM +0100, marek.va...@gmail.com wrote:
> From: Marek Vasut
>
> Replace macros using constants with BIT()s instead, no functional change.
>
> Signed-off-by: Marek Vasut
> Cc: Geert Uytterhoeven
> Cc: Phil Edworthy
> Cc: Simon Horman
> Cc: Wolfram Sang
> Cc: li
Signed-off-by: Marek Vasut
> [lorenzo.pieral...@arm.com: reformatted commit log]
> Signed-off-by: Lorenzo Pieralisi
> Reviewed-by: Simon Horman
> Acked-by: Wolfram Sang
> Cc: sta...@vger.kernel.org
> Cc: Geert Uytterhoeven
> Cc: Phil Edworthy
> Cc: Simon Horman
> Cc
On Sun, Feb 17, 2019 at 02:24:41PM +0100, marek.va...@gmail.com wrote:
> From: Kazufumi Ikeda
>
> Reestablish the PCIe link very early in the resume process in case it
> went down to prevent PCI accesses from hanging the bus. Such accesses
> can happen early in the PCI resume process, in the resu
On Sun, Feb 17, 2019 at 02:24:41PM +0100, marek.va...@gmail.com wrote:
> From: Kazufumi Ikeda
>
> Reestablish the PCIe link very early in the resume process in case it
> went down to prevent PCI accesses from hanging the bus. Such accesses
Hi Marek, Kazufumi,
Apologies for the delay.
Just as a
On Fri, Mar 22, 2019 at 01:09:13PM +0100, Marek Vasut wrote:
> On 3/22/19 12:31 PM, Lorenzo Pieralisi wrote:
> > On Sun, Feb 17, 2019 at 02:24:41PM +0100, marek.va...@gmail.com wrote:
> >> From: Kazufumi Ikeda
> >>
> >> Reestablish the PCIe link very ea
On Fri, Mar 08, 2019 at 11:17:38AM -0600, Bjorn Helgaas wrote:
[...]
> > >> +static int rcar_pcie_resume_noirq(struct device *dev)
> > >> +{
> > >> +struct rcar_pcie *pcie = dev_get_drvdata(dev);
> > >> +
> > >> +if (rcar_pci_read_reg(pcie, PMSR) &&
> > >> +!(rcar_pci_
On Tue, Dec 18, 2018 at 12:02:42PM +, Fabrizio Castro wrote:
> Add PCIe support for the RZ/G2E (a.k.a. R8A774C0).
>
> Signed-off-by: Fabrizio Castro
> Reviewed-by: Geert Uytterhoeven
> ---
> v1->v2:
> * Dropped change to the description of "phys" optional property according
> to Geert's co
On Tue, Dec 18, 2018 at 12:02:42PM +, Fabrizio Castro wrote:
> Add PCIe support for the RZ/G2E (a.k.a. R8A774C0).
>
> Signed-off-by: Fabrizio Castro
> Reviewed-by: Geert Uytterhoeven
> ---
> v1->v2:
> * Dropped change to the description of "phys" optional property according
> to Geert's co
On Mon, Oct 08, 2018 at 09:34:45AM +0200, Simon Horman wrote:
> On Thu, Oct 04, 2018 at 05:07:47PM +0100, Biju Das wrote:
> > Add support for r8a7744. The Renesas RZ/G1N (R8A7744) PCIe controller
> > is identical to the R-Car Gen2 family.
> >
> > Signed-off-by: Biju Das
> > Reviewed-by: Chris Pat
On Sat, Sep 22, 2018 at 05:02:52PM +0200, Marek Vasut wrote:
> From: Tho Vu
>
> Document the R-Car E3 (R8A77990) SoC in the R-Car PCIe bindings.
>
> Signed-off-by: Tho Vu
> Signed-off-by: Kazuya Mizuguchi
> Signed-off-by: Marek Vasut
> Cc: Geert Uytterhoeven
>
On Tue, May 22, 2018 at 12:05:14AM +0200, Marek Vasut wrote:
> From: Phil Edworthy
>
> The PCIe DMA controller on RCar Gen2 and earlier is on 32bit bus,
> so limit the DMA range to 32bit.
>
> Signed-off-by: Phil Edworthy
> Signed-off-by: Marek Vasut
> Cc: Arnd Bergmann
> Cc: Geert Uytterhoeve
On Tue, Aug 21, 2018 at 08:58:38AM +, Phil Edworthy wrote:
> Hi Lorenzo,
>
> On 20 August 2018 15:48 Lorenzo Pieralisi wrote:
> > On Mon, Aug 20, 2018 at 01:44:48PM +, Phil Edworthy wrote:
> >
> > [...]
> >
> > > However, both before and af
On Mon, Aug 20, 2018 at 01:44:48PM +, Phil Edworthy wrote:
[...]
> However, both before and after this patch, the RP does not transition L1
> when the endpoints change to L1.
> This patch only transitions the RP to L1 during accessing a card's
> config registers, if the RP is not in L1 link s
On Wed, Jun 13, 2018 at 12:25:59PM -0500, Bjorn Helgaas wrote:
> Putting this workaround in the config accessor makes sense to me
> because in this situation the endpoint thinks it's in L1 and it won't
> receive TLPs for config accesses. Apparently forcing the RP to L1
> completes the L1 entry,
a1a91a9a4 ("arm64: smp: remove cpu and numa topology
> information when hotplugging out CPU")
> Reported-by: Geert Uytterhoeven
> Tested-by: Geert Uytterhoeven
> Cc: Mark Rutland
> Cc: Lorenzo Pieralisi
> Signed-off-by: Sudeep Holla
> ---
> drivers/firmware/
a1a91a9a4 ("arm64: smp: remove cpu and numa topology
> information when hotplugging out CPU")
> Reported-by: Geert Uytterhoeven
> Tested-by: Geert Uytterhoeven
> Cc: Mark Rutland
> Cc: Lorenzo Pieralisi
> Signed-off-by: Sudeep Holla
> ---
> drivers/firmware/psci
On Sun, Jul 15, 2018 at 07:00:21PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> Here's a set of 8 patches against the 'pci/controller-fixes' branch of Lorenzo
> Pieralisi's 'pci.git' repo. They are the fixes for the PCI I/O space page
> leaks
> (and the kernel BUG caused by them on deferred probe);
On Mon, Jul 02, 2018 at 01:08:45PM +0200, Geert Uytterhoeven wrote:
> Hi Lorenzo,
>
> On Mon, Jul 2, 2018 at 12:31 PM Lorenzo Pieralisi
> wrote:
> > On Sat, Jun 30, 2018 at 01:37:18PM +0300, Sergei Shtylyov wrote:
> > > On 6/28/2018 5:26 PM, Lorenzo Pieralisi wrote:
On Sat, Jun 30, 2018 at 01:37:18PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> On 6/28/2018 5:26 PM, Lorenzo Pieralisi wrote:
>
> >>>When testing the R-Car PCIe driver on the Condor board, I noticed that iff
> >>>I left the PCIe PHY driver disable
Reported-by: Geert Uytterhoeven
> Cc: Geert Uytterhoeven
> Cc: Lorenzo Pieralisi
> Cc: Phil Edworthy
> Cc: Simon Horman
> Cc: Wolfram Sang
> Cc: linux-renesas-soc@vger.kernel.org
> Fixes: 517ca93a7159 ("PCI: rcar: Add R-Car gen3 PHY support")
> ---
> drive
h starts the PHY, yet has no counterpart in the failpath.
> Add that counterpart.
>
> Signed-off-by: Marek Vasut
> Cc: Geert Uytterhoeven
> Cc: Lorenzo Pieralisi
> Cc: Phil Edworthy
> Cc: Simon Horman
> Cc: Wolfram Sang
> Cc: linux-renesas-soc@vger.kernel.org
>
On Thu, Jun 28, 2018 at 08:22:59AM -0500, Bjorn Helgaas wrote:
> On Wed, Jun 20, 2018 at 08:51:37PM +0300, Sergei Shtylyov wrote:
> > When testing the R-Car PCIe driver on the Condor board, I noticed that iff
> > I left the PCIe PHY driver disabled, the kernel crashed with this BUG:
> >
> > [
On Wed, Jun 13, 2018 at 12:25:59PM -0500, Bjorn Helgaas wrote:
> On Wed, Jun 13, 2018 at 04:52:52PM +0100, Lorenzo Pieralisi wrote:
> > On Wed, Jun 13, 2018 at 08:53:08AM -0500, Bjorn Helgaas wrote:
> > > On Wed, Jun 13, 2018 at 01:54:51AM +0200, Marek Vasut wrote:
> > &g
On Wed, Jun 13, 2018 at 08:53:08AM -0500, Bjorn Helgaas wrote:
> On Wed, Jun 13, 2018 at 01:54:51AM +0200, Marek Vasut wrote:
> > On 06/11/2018 03:59 PM, Bjorn Helgaas wrote:
> > > On Sun, Jun 10, 2018 at 03:57:10PM +0200, Marek Vasut wrote:
> > >> On 11/17/2017 06:
fline for two weeks so it is possible that
what's in pci/rcar at present will be what gets into v4.18, apologies,
that's all I can do.
Lorenzo
> Signed-off-by: Marek Vasut
> Cc: Geert Uytterhoeven
> Cc: Lorenzo Pieralisi
> Cc: Phil Edworthy
> Cc: Simon Horman
> Cc: Wolfram Sang
> Cc: linux-renesas-soc@vger.kernel.org
>
> --
> 2.16.2
>
On Fri, May 25, 2018 at 11:39:08AM +0200, Geert Uytterhoeven wrote:
> Hi Lorenzo,
>
> On Fri, May 25, 2018 at 11:35 AM, Lorenzo Pieralisi
> wrote:
> > Can I retain your review tags on this series so that I can queue
> > the patches ? I already added them apart from the la
ailpath
>
> drivers/pci/host/pcie-rcar.c | 82
> +++-
> 1 file changed, 66 insertions(+), 16 deletions(-)
>
> Signed-off-by: Marek Vasut
> Cc: Geert Uytterhoeven
> Cc: Lorenzo Pieralisi
> Cc: Phil Edworthy
> Cc: Simon Horman
> Cc: Wolfram Sang
> Cc: linux-renesas-soc@vger.kernel.org
>
> --
> 2.16.2
>
On Tue, May 22, 2018 at 02:24:20PM +0200, Marek Vasut wrote:
> The data link active signal usually takes ~20 uSec to be asserted,
> poll the bit more often to avoid useless delays in this function.
> Use udelay() instead of usleep() for such a small delay as suggested
> by the timer documentation a
On Thu, May 24, 2018 at 09:24:27AM +0200, Marek Vasut wrote:
> On 05/23/2018 11:56 PM, Bjorn Helgaas wrote:
> > On Wed, May 23, 2018 at 07:05:06PM +0200, Marek Vasut wrote:
> >> On 05/23/2018 06:17 PM, Lorenzo Pieralisi wrote:
> >>> On Mon, May 21, 2018 at 03:11
On Mon, May 21, 2018 at 03:11:20PM +0200, Marek Vasut wrote:
> The function name is just too confusing, rename it, no functional change.
> Rename the function to rcar_pcie_alloc_and_parse_pci_resource_list() as
> it's matching failpath function is pci_free_resource_list() so the names
> align much
On Mon, May 21, 2018 at 01:08:36PM +0200, Marek Vasut wrote:
> On 05/14/2018 05:49 PM, Lorenzo Pieralisi wrote:
> > On Mon, May 14, 2018 at 05:32:04PM +0200, Marek Vasut wrote:
> >> On 05/01/2018 12:55 PM, Lorenzo Pieralisi wrote:
> >>> On Fri, Apr 13, 2018 at 02:48:
On Mon, May 14, 2018 at 05:32:04PM +0200, Marek Vasut wrote:
> On 05/01/2018 12:55 PM, Lorenzo Pieralisi wrote:
> > On Fri, Apr 13, 2018 at 02:48:19PM +0200, Simon Horman wrote:
> >> On Tue, Apr 10, 2018 at 06:17:04PM +0200, Marek Vasut wrote:
> >>> On 04/10/2018 05:2
On Wed, Apr 25, 2018 at 06:21:25PM +0300, Vladimir Zapolskiy wrote:
> The non-functional change removes a custom function to parse and
> allocate PCI resources in favour of pci_parse_request_of_pci_ranges().
>
> Signed-off-by: Vladimir Zapolskiy
> ---
> drivers/pci/host/pcie-rcar.c | 42 +---
On Thu, May 03, 2018 at 10:32:41PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> Here's a set of 5 patches against the 'pci/rcar' branch of Lorenzo Pieralisi's
> 'pci.git' repo. These are the changes needed for better R-Car gen3 support
> (namely for R8A77980 support) plus some PCIe driver re-factori
On Thu, May 03, 2018 at 06:26:43PM +0300, Sergei Shtylyov wrote:
> On 05/01/2018 01:57 PM, Lorenzo Pieralisi wrote:
>
> >>> Hello!
> >>>
> >>> Here's a set of 5 patches against the 'pci/rcar' branch of Lorenzo
> >>> Pieralisi&
On Tue, May 01, 2018 at 07:55:53AM +0200, Simon Horman wrote:
> On Sun, Apr 08, 2018 at 08:57:13PM +0300, Sergei Shtylyov wrote:
> > Hello!
> >
> > Here's a set of 5 patches against the 'pci/rcar' branch of Lorenzo
> > Pieralisi's
> > 'pci.git' repo. These are the changes needed for better R-Car
On Fri, Apr 13, 2018 at 02:48:19PM +0200, Simon Horman wrote:
> On Tue, Apr 10, 2018 at 06:17:04PM +0200, Marek Vasut wrote:
> > On 04/10/2018 05:28 PM, Geert Uytterhoeven wrote:
>
> ...
>
> > >>> rcar_pcie_get_resources() is called while the device is
> > >>> runtime-enabled/resumed,
> > >>> pci
On Tue, May 01, 2018 at 07:53:19AM +0200, Simon Horman wrote:
> On Sun, Apr 08, 2018 at 08:04:31PM +0200, Marek Vasut wrote:
> > This patch replaces the (1 << n) with BIT(n) and cleans up whitespace,
> > no functional change.
> >
> > Signed-off-by: Marek Vasut
> > Cc: Geert Uytterhoeven
> > Cc:
Hi Marek,
On Sun, Mar 18, 2018 at 11:52:52AM +0100, Marek Vasut wrote:
> The data link active signal usually takes ~20 uSec to be asserted,
> poll the bit more often to avoid useless delays in this function.
>
> Signed-off-by: Marek Vasut
> Cc: Geert Uytterhoeven
> Cc: Phil Edworthy
> Cc: Simo
On Fri, Apr 13, 2018 at 02:48:19PM +0200, Simon Horman wrote:
> On Tue, Apr 10, 2018 at 06:17:04PM +0200, Marek Vasut wrote:
> > On 04/10/2018 05:28 PM, Geert Uytterhoeven wrote:
>
> ...
>
> > >>> rcar_pcie_get_resources() is called while the device is
> > >>> runtime-enabled/resumed,
> > >>> pci
On Wed, Mar 07, 2018 at 09:34:29AM +0100, Julia Lawall wrote:
> From: Fengguang Wu
>
> Remove unneeded semicolon.
>
> Generated by: scripts/coccinelle/misc/semicolon.cocci
>
> Signed-off-by: Fengguang Wu
> Signed-off-by: Julia Lawall
> ---
>
> tree: https://git.kernel.org/pub/scm/linux/ke
Hi Marek,
On Fri, Nov 10, 2017 at 10:54:11PM +0100, Marek Vasut wrote:
> From: Dien Pham
>
> The controller clock can be switched off during suspend/resume,
> let runtime PM take care of that.
>
> Signed-off-by: Dien Pham
> Signed-off-by: Hien Dang
> Signed-off-by: Marek Vasut
> Cc: Geert Uy
On Tue, Nov 14, 2017 at 09:59:03AM +, Biju Das wrote:
> Add support for r8a7743. The Renesas RZ/G1M(R8A7743)PCIe controller
> is identical to the R-Car Gen2 family.
>
> No driver change is needed due to the fallback compatible value
> "renesas,pcie-rcar-gen2".
> Adding the SoC-specific compati
On Fri, Feb 23, 2018 at 12:29:49PM +, Colin King wrote:
> From: Colin Ian King
>
> Bit pattern RCAR_PCI_INT_SIGRETABORT is being bit-wise or'd twice;
> remove the redundant 2nd RCAR_PCI_INT_SIGRETABORT.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/pci/host/pci-rcar-gen2.c | 1 -
> 1 f
On Thu, Dec 07, 2017 at 11:15:20AM +0100, Geert Uytterhoeven wrote:
> rcar_pcie_parse_request_of_pci_ranges() can fail and return an error
> code, but this is not checked nor handled.
>
> Fix this by adding the missing error handling.
>
> Fixes: 5d2917d469faab72 ("PCI: rcar: Convert to DT resourc
On Tue, Dec 12, 2017 at 11:16:58AM -0600, Bjorn Helgaas wrote:
> On Thu, Dec 07, 2017 at 11:15:18AM +0100, Geert Uytterhoeven wrote:
> > Hi Simon, Lorenzo, Bjorn,
> >
> > This patch series fixes two issues in the error path for the R-Car PCIe
> > host bridge driver.
> >
> > The first issue is
CI: rcar: Convert to DT resource parsing API")
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/pci/host/pcie-rcar.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
Acked-by: Lorenzo Pieralisi
> diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
all to pci_free_resource_list() up, and update the
> label name accordingly.
>
> Fixes: ddd535f1ea3eb27e ("PCI: rcar: Fix memory leak when no PCIe card is
> inserted")
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/pci/host/pcie-rcar.c | 8 ++++
> 1 f
Hi Marek,
On Fri, Nov 10, 2017 at 10:58:42PM +0100, Marek Vasut wrote:
> From: Phil Edworthy
>
> Most PCIe host controllers support L0s and L1 power states via ASPM.
> The R-Car hardware only supports L0s, so when the system suspends and
> resumes we have to manually handle L1.
> When the system
On Wed, Oct 11, 2017 at 10:03:01AM +0200, Geert Uytterhoeven wrote:
> PSCI support may be disabled at build time (by configuration) or at
> run-time (PSCI firmware not present). While CONFIG_ARM_PSCI_FW can be
> used to check for build time enablement, there is currently no simple
> way to check i
rt PCI scan API to
pci_scan_root_bus_bridge()") converted PCI root bus scan API
to the new pci_scan_root_bus_bridge() API; in the process
some error paths were not updated correctly which may
cause memory leaks.
Fix the driver error exit path reinstating the previous
correct error exit b
merging Matt's code, that was my point, but I need to have another
thorough look myself before commenting any further.
Thanks,
Lorenzo
> I'll take another look at it.
>
> > > -Original Message-
> > > From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
>
Hi Phil,
On Fri, Jul 08, 2016 at 12:49:55PM +0100, Phil Edworthy wrote:
> Hi Bjorn,
>
> I've marked this as RFC as I guess there might be a better way to do
> this, but I'm not sure how. I would appreciate your thoughts on this.
There is a more generic solution to this issue, that has been
hangi
On Mon, Jun 20, 2016 at 09:56:45AM -0700, Tyler Baker wrote:
> Hi Bjorn,
>
> On 6 June 2016 at 16:06, Bjorn Helgaas wrote:
> > Previously we allocated the PCI resource list in
> > gen_pci_parse_request_of_pci_ranges(), but if we had an error, we freed it
> > on error in gen_pci_init().
> >
> > Re
71 matches
Mail list logo