Message ID | 20170205154559.31664-1-weiyj.lk@gmail.com (mailing list archive) |
---|---|
State | Not Applicable, archived |
Headers | show |
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); -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[+ 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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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);