From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rafael J. Wysocki" Subject: Re: [PATCH v3 1/5] ACPI / bus: Return error code from __acpi_match_device() in one case Date: Thu, 8 Feb 2018 16:14:31 +0100 Message-ID: References: <20180207145610.88434-1-andriy.shevchenko@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from mail-oi0-f45.google.com ([209.85.218.45]:45632 "EHLO mail-oi0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750847AbeBHPOc (ORCPT ); Thu, 8 Feb 2018 10:14:32 -0500 In-Reply-To: <20180207145610.88434-1-andriy.shevchenko@linux.intel.com> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Andy Shevchenko Cc: dmaengine , "Rafael J . Wysocki" , ACPI Devel Maling List , Mika Westerberg , Sinan Kaya , Sakari Ailus , Vinod Koul On Wed, Feb 7, 2018 at 3:56 PM, Andy Shevchenko wrote: > Instead of playing tricks with last invalid entry, > return simple -ENODATA error code cast to pointer. > > It would be good for future in case caller passes NULL pointer for > ID table. Moreover, caller can check the code to be sure what happened > inside callee. > > Fixes: 2b9c698efa58 ("ACPI / scan: Take the PRP0001 position in the list of IDs into account") I still don't think the Fixes: tag here is valid (the code works as is AFAICS), but I could drop it when applying the patch just fine. :-) That said, see below. > Cc: Sinan Kaya > Cc: Sakari Ailus > Cc: Vinod Koul > Signed-off-by: Andy Shevchenko > --- > drivers/acpi/bus.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c > index 58239abb0a72..761286e50067 100644 > --- a/drivers/acpi/bus.c > +++ b/drivers/acpi/bus.c > @@ -769,7 +769,7 @@ static const struct acpi_device_id *__acpi_match_device( > */ > if (!strcmp(ACPI_DT_NAMESPACE_HID, hwid->id) > && acpi_of_match_device(device, of_ids)) > - return id; > + return ERR_PTR(-ENODATA); Doesn't the comment above need to be updated? Also the return value here means "success", so why is an error the right choice? > } > return NULL; > } > -- Overall, this really looks like a preparation for a future patch, so why not just say that straight away in the changelog?