[PATCH -next] ACPI/IORT: Fix the error return code in iort_add_smmu_platform_device()

[PATCH -next] ACPI/IORT: Fix the error return code in iort_add_smmu_platform_device()

[Wei Yongjun]

From: Wei Yongjun <weiyongjun1@huawei.com>

The error return code PTR_ERR(pdev) is always 0 since pdev is
equal to 0 in this error handling case.

Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
 drivers/acpi/arm64/iort.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index e0d2e6e..655407a 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -828,7 +828,7 @@ static int __init iort_add_smmu_platform_device(struct acpi_iort_node *node)
 
 	pdev = platform_device_alloc(ops->name, PLATFORM_DEVID_AUTO);
 	if (!pdev)
-		return PTR_ERR(pdev);
+		return -ENOMEM;
 
 	count = ops->iommu_count_resources(node);

Re: [PATCH -next] ACPI/IORT: Fix the error return code in iort_add_smmu_platform_device()

[Lorenzo Pieralisi]

On Sun, Feb 05, 2017 at 03:45:59PM +0000, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
> 
> The error return code PTR_ERR(pdev) is always 0 since pdev is
> equal to 0 in this error handling case.
> 
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
>  drivers/acpi/arm64/iort.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

It has been reported twice already:

https://patchwork.kernel.org/patch/9521003/

Rafael, do you expect me to send you a pull request with IORT fixes ?

I can't see Dan's patch in linux-acpi patchwork anymore, and there
is another fix pending:

https://patchwork.kernel.org/patch/9507041/

Please let me know how you want to handle them.

Thanks !
Lorenzo

> 
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index e0d2e6e..655407a 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -828,7 +828,7 @@ static int __init iort_add_smmu_platform_device(struct acpi_iort_node *node)
>  
>  	pdev = platform_device_alloc(ops->name, PLATFORM_DEVID_AUTO);
>  	if (!pdev)
> -		return PTR_ERR(pdev);
> +		return -ENOMEM;
>  
>  	count = ops->iommu_count_resources(node);

Re: [PATCH -next] ACPI/IORT: Fix the error return code in iort_add_smmu_platform_device()

[Rafael J. Wysocki]

On Monday, February 06, 2017 10:04:11 AM Lorenzo Pieralisi wrote:
> On Sun, Feb 05, 2017 at 03:45:59PM +0000, Wei Yongjun wrote:
> > From: Wei Yongjun <weiyongjun1@huawei.com>
> > 
> > The error return code PTR_ERR(pdev) is always 0 since pdev is
> > equal to 0 in this error handling case.
> > 
> > Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> > ---
> >  drivers/acpi/arm64/iort.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> It has been reported twice already:
> 
> https://patchwork.kernel.org/patch/9521003/
> 
> Rafael, do you expect me to send you a pull request with IORT fixes ?
> 
> I can't see Dan's patch in linux-acpi patchwork anymore, and there
> is another fix pending:
> 
> https://patchwork.kernel.org/patch/9507041/
> 
> Please let me know how you want to handle them.

I wasn't sure about who was the target maintainer to be honest.

I'd prefer ARM64-specific material to go in via the ARM64 tree, if that's possible.

Thanks,
Rafael

Re: [PATCH -next] ACPI/IORT: Fix the error return code in iort_add_smmu_platform_device()

[Lorenzo Pieralisi]

[+ Catalin, Will]

On Mon, Feb 06, 2017 at 12:41:12PM +0100, Rafael J. Wysocki wrote:
> On Monday, February 06, 2017 10:04:11 AM Lorenzo Pieralisi wrote:
> > On Sun, Feb 05, 2017 at 03:45:59PM +0000, Wei Yongjun wrote:
> > > From: Wei Yongjun <weiyongjun1@huawei.com>
> > > 
> > > The error return code PTR_ERR(pdev) is always 0 since pdev is
> > > equal to 0 in this error handling case.
> > > 
> > > Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> > > ---
> > >  drivers/acpi/arm64/iort.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > It has been reported twice already:
> > 
> > https://patchwork.kernel.org/patch/9521003/
> > 
> > Rafael, do you expect me to send you a pull request with IORT fixes ?
> > 
> > I can't see Dan's patch in linux-acpi patchwork anymore, and there
> > is another fix pending:
> > 
> > https://patchwork.kernel.org/patch/9507041/
> > 
> > Please let me know how you want to handle them.
> 
> I wasn't sure about who was the target maintainer to be honest.
> 
> I'd prefer ARM64-specific material to go in via the ARM64 tree, if
> that's possible.

I CC'ed Catalin and Will so that we can sort this out, I took for
granted that ACPI changes would go via the ACPI tree even if they
are ARM64 specific, I am not sure it makes much sense for them to
go via the arm64 arch tree, anyway it is something to be decided
because the two fixes above have already missed -rc* and I have to
know which way patches should go from now onwards.

Thanks,
Lorenzo

Re: [PATCH -next] ACPI/IORT: Fix the error return code in iort_add_smmu_platform_device()

[Rafael J. Wysocki]

On Monday, February 06, 2017 12:07:33 PM Lorenzo Pieralisi wrote:
> [+ Catalin, Will]
> 
> On Mon, Feb 06, 2017 at 12:41:12PM +0100, Rafael J. Wysocki wrote:
> > On Monday, February 06, 2017 10:04:11 AM Lorenzo Pieralisi wrote:
> > > On Sun, Feb 05, 2017 at 03:45:59PM +0000, Wei Yongjun wrote:
> > > > From: Wei Yongjun <weiyongjun1@huawei.com>
> > > > 
> > > > The error return code PTR_ERR(pdev) is always 0 since pdev is
> > > > equal to 0 in this error handling case.
> > > > 
> > > > Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> > > > ---
> > > >  drivers/acpi/arm64/iort.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > It has been reported twice already:
> > > 
> > > https://patchwork.kernel.org/patch/9521003/
> > > 
> > > Rafael, do you expect me to send you a pull request with IORT fixes ?
> > > 
> > > I can't see Dan's patch in linux-acpi patchwork anymore, and there
> > > is another fix pending:
> > > 
> > > https://patchwork.kernel.org/patch/9507041/
> > > 
> > > Please let me know how you want to handle them.
> > 
> > I wasn't sure about who was the target maintainer to be honest.
> > 
> > I'd prefer ARM64-specific material to go in via the ARM64 tree, if
> > that's possible.
> 
> I CC'ed Catalin and Will so that we can sort this out, I took for
> granted that ACPI changes would go via the ACPI tree even if they
> are ARM64 specific, I am not sure it makes much sense for them to
> go via the arm64 arch tree, anyway it is something to be decided
> because the two fixes above have already missed -rc* and I have to
> know which way patches should go from now onwards.

On x86 the arch-specific ACPI changes go in via the arch tree as a rule, FWIW,
but also I'm sufficiently familiar with x86 (I think) to route them via the ACPI
tree with enough confidence.

Quite honestly, my ARM64 knowledge is not sufficient to decide whether or not
the changes actually make sense, so I would request an ACK from the ARM64
maintainers before taking those changes anyway.

Thanks,
Rafael

Re: [PATCH -next] ACPI/IORT: Fix the error return code in iort_add_smmu_platform_device()

[Will Deacon]

On Mon, Feb 06, 2017 at 12:07:33PM +0000, Lorenzo Pieralisi wrote:
> On Mon, Feb 06, 2017 at 12:41:12PM +0100, Rafael J. Wysocki wrote:
> > On Monday, February 06, 2017 10:04:11 AM Lorenzo Pieralisi wrote:
> > > On Sun, Feb 05, 2017 at 03:45:59PM +0000, Wei Yongjun wrote:
> > > > From: Wei Yongjun <weiyongjun1@huawei.com>
> > > > 
> > > > The error return code PTR_ERR(pdev) is always 0 since pdev is
> > > > equal to 0 in this error handling case.
> > > > 
> > > > Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> > > > ---
> > > >  drivers/acpi/arm64/iort.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > It has been reported twice already:
> > > 
> > > https://patchwork.kernel.org/patch/9521003/
> > > 
> > > Rafael, do you expect me to send you a pull request with IORT fixes ?
> > > 
> > > I can't see Dan's patch in linux-acpi patchwork anymore, and there
> > > is another fix pending:
> > > 
> > > https://patchwork.kernel.org/patch/9507041/
> > > 
> > > Please let me know how you want to handle them.
> > 
> > I wasn't sure about who was the target maintainer to be honest.
> > 
> > I'd prefer ARM64-specific material to go in via the ARM64 tree, if
> > that's possible.
> 
> I CC'ed Catalin and Will so that we can sort this out, I took for
> granted that ACPI changes would go via the ACPI tree even if they
> are ARM64 specific, I am not sure it makes much sense for them to
> go via the arm64 arch tree, anyway it is something to be decided
> because the two fixes above have already missed -rc* and I have to
> know which way patches should go from now onwards.

I have no problem taking arm64 ACPI patches via arm64 if that's what
Rafael prefers. However, I won't proactively pick them up like I do for
other arm64 patches, so please send me a pull request when you have stuff
that you want merged.

Will